• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

Digitaly signed files with EC key are reported to have RSA signature

Community Beginner ,
Mar 02, 2021 Mar 02, 2021

Copy link to clipboard

Copied

After signing a PDF file with a EC (elyptic curve) smartcard the advanced signature properties report the signature algorith to be RSA with PKCS#1v1.5.

 

TOPICS
Security digital signatures and esignatures

Views

1.7K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

This is caused by your signature claiming that it is a RSA signature and an Adobe Reader bug not handling your signature correctly.

In detail:

This is an ASN.1 dump of the SignerInfo object in the embedded CMS container in your signed PDF:

SEQUENCE (6 elem)
  INTEGER 1
  SEQUENCE (2 elem)
    SEQUENCE (4 elem)
      SET (1 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 2.5.4.6 countryName (X.520 DN component)
          PrintableString LT
      SET (1 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 2.5.4.97
          PrintableString 188778315
      SET (1 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 2.5.4.11 organizationalUnitName (X.520 DN component)
          PrintableString Asmens dokumentu israsymo centras prie LR VRM
      SET (1 elem)
        SEQUENCE (2 elem)
          OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
          PrintableString ADIC CA-B TEST
    INTEGER (111 bit) 2176224681163120813205678297452564
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 2.16.840.1.101.3.4.2.1 sha-256 (NIST Algorithm)
    NULL
  [0] (4 elem)
    SEQUENCE (2 elem)
      OBJECT IDENTIFIER 1.2.840.113583.1.1.8 pdfRevocationInfoArchival (Adobe Acrobat security)
      SET (1 elem)
        SEQUENCE (0 elem)
    SEQUENCE (2 elem)
      OBJECT IDENTIFIER 1.2.840.113549.1.9.3 contentType (PKCS #9)
      SET (1 elem)
        OBJECT IDENTIFIER 1.2.840.113549.1.7.1 data (PKCS #7)
    SEQUENCE (2 elem)
      OBJECT IDENTIFIER 1.2.840.113549.1.9.4 messageDigest (PKCS #9)
      SET (1 elem)
        OCTET STRING (32 byte) C021B5D54428E7D1D6966BAFBA97464581D267AE214C562E28EE650A66BAD54E
    SEQUENCE (2 elem)
      OBJECT IDENTIFIER 1.2.840.113549.1.9.16.2.47 signingCertificateV2 (S/MIME Authenticated Attributes)
      SET (1 elem)
        SEQUENCE (2 elem)
          SEQUENCE (1 elem)
            SEQUENCE (2 elem)
              OCTET STRING (32 byte) A1EC43E1795C8273243A7D520D8616004B71A91448F0C38D88649DC5CA30C2F5
              SEQUENCE (2 elem)
                SEQUENCE (1 elem)
                  [4] (1 elem)
                    SEQUENCE (4 elem)
                      SET (1 elem)
                        SEQUENCE (2 elem)
                          OBJECT IDENTIFIER 2.5.4.6 countryName (X.520 DN component)
                          PrintableString LT
                      SET (1 elem)
                        SEQUENCE (2 elem)
                          OBJECT IDENTIFIER 2.5.4.97
                          PrintableString 188778315
                      SET (1 elem)
                        SEQUENCE (2 elem)
                          OBJECT IDENTIFIER 2.5.4.11 organizationalUnitName (X.520 DN component)
                          PrintableString Asmens dokumentu israsymo centras prie LR VRM
                      SET (1 elem)
                        SEQUENCE (2 elem)
                          OBJECT IDENTIFIER 2.5.4.3 commonName (X.520 DN component)
                          PrintableString ADIC CA-B TEST
                INTEGER (111 bit) 2176224681163120813205678297452564
          SEQUENCE (1 elem)
            SEQUENCE (2 elem)
              OBJECT IDENTIFIER 1.3.6.1.4.1.33621.2.5.1
              SEQUENCE (1 elem)
                SEQUENCE (2 elem)
                  OBJECT IDENTIFIER 1.3.6.1.5.5.7.2.1 cps (PKIX policy qualifier)
                  IA5String http://nsctest.vrm.lt/repository
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.113549.1.1.11 sha256WithRSAEncryption (PKCS #1)
    NULL
  OCTET STRING (102 byte) 3064023048BEFEB5299327E3349858F3B92EE5FAB7CB8019F236C7ED06BFE40C746B2…
    SEQUENCE (2 elem)
      INTEGER (383 bit) 1119664554576096107379954238849521365208324057075068871760358942756824…
      INTEGER (382 bit) 5276599885336700163417326428171319340973797005159224308908680809964953…

As you can see, it declares a signing algorithm of sha256WithRSAEncryption! On the other hand the signature value clearly has the form of an ECDSA signature value, a sequence of two integers, which differs from the form of a RSA signature value.

Thus:

A) Strictly speaking your signature is broken and Adobe Reader should tell you so.

B) Furthermore, Adobe Reader blindly displays the declared signing algorithm, not the algorithm it actually uses during signature validation.

Both are serious security issues, a broken signature MUST NOT be repaired under the hood, but even (if for weird compatibility reasons deemed necessary) if one does repair, one MUST communicate the actual signing algorithm plus a note that the signature claims differently.

This represents an attack vector, one can try and use a weaker signature algorithm (an algorithm one probably has broken) and claim a strong signature algorithm.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

That's my point - the signature embeded by Adobe Acrobat Reader has incorrect algorithm identifier. This is not signature display, but rather signature creation problem.

Full disclosure - I am the creator of the minidirver driver used to sign the document and there is no mention of RSA anythere in the source code (only EC signature algorithm is supported by the minidriver).

The oncly conclusion I can draw is that Acrobat Reader, when forming the signature object, incorrectly sets the algorithm identifier.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

As far as Acrobat Reader generating invalid signatures in combination with your driver is concerned, you might want to create a post featuring more details. I have no idea, though, where best to post this, the Acrobat forum probably is not appropriate.

As far as the incorrect reporting of the signature by Adobe Acrobat is concerned, though, your post revealed serious Acrobat issues and should be taken very seriously by Adobe personal here.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

First of all, the smartcard certificate is RSA, not ECC. 

Cert1.jpg

The EC Public key in the CMS is irrelevant, since its the public key in the cert that is used for validating.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

The certificate is indeed signed with a RSA key - that's the key Certificate Authority uses. However, the document is signed not by the Certificate Authority (using RSA key), but the smart card (using EC key).

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

The Smart Card certificate is the last one in the chain, and you can see that it is signed with SHA256 RSA. I don't know why Acrobat didn't complain about the format of the public key, which shows as EC PUBLIC (P-384) instead of RSA (2048 bit), but Acrobat never did extensive certificate format validation. If this were a real ECC certificate it would have an ECC signature algorithm with a curve specifier like this:

cert1ecc.jpg

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

The Smart Card certificate is the last one in the chain, and you can see that it is signed with SHA256 RSA.

Indeed, the end entity certificate is signed with SHA256withRSA. But that is irrelevant for the question at hand.

I don't know why Acrobat didn't complain about the format of the public key, which shows as EC PUBLIC (P-384) instead of RSA (2048 bit), but Acrobat never did extensive certificate format validation.

While indeed Acrobat validation is ignoring many structural issues in signatures and certificates, in this case there is no need for it to complain, the chain is alright.

If this were a real ECC certificate it would have an ECC signature algorithm with a curve specifier like this:

You appear to have the misconseption that certificate chains must be homogeneous in the algorithms used for all signatures involved (certificate signatures and document signatures). This is not the case. You can have a DSS root certificate signing a RSA intermediate CA certificate signing an ECDSA end entity certificate signing the document.

That's why you have to take care and not take the first algorithm you see in the certificate properties and claim that that algorithm will be used in signed documents.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 03, 2021 Mar 03, 2021

Copy link to clipboard

Copied

First of all, the smartcard certificate is RSA, not ECC. 

Cert1.jpg

The EC Public key in the CMS is irrelevant, since its the public key in the cert that is used for validating.


By @margueritek


Your reading of that information is incorrect. Or you completely misunderstand the issue at hand.

 

The question originally was about why Adobe Reader claimed the document signature was signed using RSA while it actually was signed using ECDSA.

And for this it is completely irrelevant how the issuer certificate signed the end entity certificate (which indeed is with RSA as your screenshot shows), instead it is important what one can see in the CMS SignerInfo signature bytes (which are formatted as an ECDSA signature, not a RSA signature, as shown in the ASN.1 dump in my first answer here) and what the nature of  the key pair associated with the end entity certificate is (which is EC as the screen shot of the original poster shows).

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Mar 04, 2021 Mar 04, 2021

Copy link to clipboard

Copied

If the signature was really ECDSA it would have an ECDSA algorithm, which is not shown in your dump. It would also have a curve specifier, which again is not shown in your dump. You might ask where Acrobat would get the algorithm and curve for signing, if not from the final certificate in the chain (the one on the Smart Card). We know it is using the Smart Card certificate because the signature shows as Qualified, and the private key is on a Secure Signature Creation Device (the Smart Card). You need to get a real ECC certificate from ADIC.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Mar 04, 2021 Mar 04, 2021

Copy link to clipboard

Copied

LATEST

If the signature was really ECDSA it would have an ECDSA algorithm, which is not shown in your dump. It would also have a curve specifier, which again is not shown in your dump. 

You apparently forget that this whole question is about a signature container with errors and an erroneous behavior of Acrobat. The error in the signature container exactly is that the signature algorithm claimed in it is wrong.

You might ask where Acrobat would get the algorithm and curve for signing, if not from the final certificate in the chain (the one on the Smart Card).

Indeed, from the end entity certificate. Which, as shown in the OP's original screen shot, contains an EC public key including information on the curve in question. And again, it doesn't matter a bit that its issuer certificate signed the end entity certificate using RSA, so the algorithm of the signature on the certificate you showed in your screen shot is irrelevant.

(Or it should be irrelevant. If Acrobat used that algorithm information as signature algorithm of the document, its bug at hand would be more convoluted than imagined.)

You need to get a real ECC certificate from ADIC.

And here again you simply repeat your claim that the end entity certificate was a somehow unreal ECC certificate. And there again you are mistaken.

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines