Copy link to clipboard
Copied
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.
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.
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.
Copy link to clipboard
Copied
First of all, the smartcard certificate is RSA, not ECC.
The EC Public key in the CMS is irrelevant, since its the public key in the cert that is used for validating.
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).
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:
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.
Copy link to clipboard
Copied
First of all, the smartcard certificate is RSA, not ECC.
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).
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.
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 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.