The default signing algo. has been SHA-256 since 9.1. See the Sig Creation Quick Key at http://www.adobe.com/go/learn_acr_security_en.
I'm unclear about your workflow. Can you send specific steps 1, 2, 3 with the name and version of all the involved components?
- I generate the pdf with a third party library (pdfreactor)
- I create the signing field with a third party library (itext)
- i enable the document signing with adobe livecycle ES server version 8.0 (with the webservice of livecycle reader extension , enabling signing usage rights on my pdf)
- the users downloads this signable pdf
at this step the pdf returned to the client from livecycle reader extension web service is a signable pdf , with correct reader usage rights.
But this pdf contains an adobe sign SIGNED WITH SHA-1.
I suspect that this is the problem.
Could be that if adobe reader detects this sign, continue signing with the SHA-1 digest instead of SHA-256?
If you want i can post to you the pdf , returned from livecycle web service .
Here the details for the adobe internal sign contained into the returned pdf
First, a little background.
When you Reader Enable a document you are creating a special digital signature. That is, the allowable rights are added to an object in the PDF file and then you sign the "rights object" using the digital ID issued to ARE Production V6.1 P16 ID15713. This is to prevent someone from adding extra rights into the "rights object" in order to enable functionality that the document author didn't intend to enable. Like any digital signature it's purpose is two fold; first to test the integrity of the signed data (i.e. was the data tampered with), and second, to test the integrity of the signer (i.e. was the signer's certificate valid at signing time).
When you add in the usage rights (i.e. Reader Enable the PDF file) using the LiveCycle ES server you are get the default digest method from that version of LiveCycle, which was SHA-1. If you update to LiveCycle ES3 you will get SHA-256. LC ES was the equivlent of Acrobat 8, LC ES2 was the equivlent of Acrobat 9, and LC ES3 is the equivlent of Acrobat 10.
Thanks for al those informations, all very clear.
Only the last thing.
Now we change reader extensions with your Adobe LC downloaded as
LC Media/Eval/NFR2 8.0 LNX ESD WWE JBOSS
1.) I cannot bind this product version with ES, ES 2, ES 3 version number. What version does the software above belongs to?
2.) is possible to configure SHA-256 on the software above without upgrading? if true how?
Although I know a bit about the LiveCycle servers, I'm really an Acrobat/Reader specialist. You should post LC server configuration questions to:
Acrobat 9 with WIN7 on my computers uses SHA-1 instead of SHA-256, while installations on XP uses SHA-256. I have two installations on XP and three on WIN7 (five ACROBAT licenses..). A brand new PC bought by a friend of mine last month, with Acrobat X and WIN7 OEM installed, have the same problem. It's over one year I try to fix the problem with my conputers but it seems impossible to fix. To sign documents with SHA.256 I use installations on XP, or other programs for digital sign of pdfs (I. and my co-workers. sign over 2000 file a year). With Adobe and Infocert (the digital sign provider) I only wasted my time in trying to fix the problem, nobody seems to have the idea of why Acrobat don't work with WIN7 and the responsability is always of some other. I was thinking tu buy a new computer, whit WIN 7 and Acrobat X , but (tanks to my friend which made the experiment!), it do not work, the hash algoritm used is SHA-1 in this case, too. This is my experience - very frustrating - whit Acrobat on WIN7.
I fear the users of Acrobat+WIN7 for digital sign of documents in Italy are not so many.
I guarantee you that it's not Acrobat that is preventing you from using SHA-256 provided you have updated to version 9.1 or later. If you are still using version 9.0 then the default is SHA-1. Another possible issue that you may be having is where the digital ID resides that you are using to sign the PDF file. If it's on a hardware device such as a token or smart card it's possible that the device doesn't support SHA-256. I know you said you are getting SHA-256 on XP, but not Win 7, but Win 7 most certainly supports SHA-256. It wasn't introduced into Win XP until SP3, but since you said you are getting SHA-256 on Win XP then you must have updated the OS.
So the question is, where does your digital ID reside?
The acrobat 9 version is update. The problem is teh same with acrobat X + WIN7.
The digital id resides on a smart card.
Moreover, in WIN7 installations if you define a digital id in windows, the digital sign is made using
Evidently, ther is some settings that decide what hash algoritm to use which fails with win7+smart card
from infocamere/infocert. Let alone, we don’t want to change smart card.
But, regrettably, we had an exange with smart card provider and he said
that the smart card is to be changed to a more recent model,
but some of us have recent smart card models , so this appears not beliveable.
All kind of smart card and smart card reader we have, all sign pdf correctely using frre softare like
actalis file protector on the same PC on whic acrobat fails.
Our hardware and driver are correct for using whith sha-256.
The computer brand new of my friend, with WIN7 and acrobat X, and a recent version of smart card
leaves no doubt: the combination of products (WIN7+Acrobat X but also 9+our smart cards + our digital certificates) has a problem in managing signing algorithm.
I'm triyng other solutions for signing pdf (for example actalis file protector).
Thank you for your assistance.
It's the smart card (or more correctly the software on the smart card) that is the bottleneck to getting to SHA-256. Here's what happens:
NOTE: When I say Acrobat I really mean both Acrobat and Reader
• The user initiates the signing operation
• Acrobat asks the user to pick a digital ID
• The user select a digital ID from the drop-down list on the Sign Document dialog and then clicks the Sign button
• Acrobat needs to write the file to disk for security purposes (another issue) and puts up the Save As dialog
• The user selects a file name and save location and Acrobat writes the file to disk and it's at this time two things happen:
o The signature appearance is created so it can be part of the signed data (what you see in the signature field is not the signature, but rather a pictorial representation of the signature)
o A hole is created in the file and filled with zeros as a place holder where the actual signature will be written
• Acrobat computes the digest over the file, excluding the hole filled with zeros. By default Acrobat is using the SHA-256digest method
• Acrobat needs to get the digest encrypted (signed) by the private key associated with the signers digital ID
o If Acrobat has access to the private key it calls on the RSA library to do the encryption,
o If Acrobat doesn't have access to the private key it sends the SHA-256 digest to the software that does have access to the private key... In your case that's the cryptographic software residing on the smart card
• It's up to the cryptographic software to feed the 32 byte SHA-256 digest into its encryption algorithm and have the private key encrypt the digest
• The software on the smart card cannot handle a digest as large as 32-bytes, so it returns an error
• In Acrobat 9.0.0 and earlier once the error message was returned the signing process was aborted and signature did not get created. Starting with version 9.1 if a PKCS#11 (the specification for smart cards) error is returned Acrobat falls back to re-computing the digest using SHA-1 and starts the process again. It's here where the smart card software is getting the 20-byte SHA-1 digest and can get it encrypted using the private key.
• Once the encrypted SHA-1 digest (this is really the digital signature) is computed the smart card sends it back to Acrobat
• Acrobat in turn writes the signature into the hole it created in the PDF file, overwriting the zeros with actual hex values.
And that’s how you get a digital signature based on the SHA-1 digest method. If you absolutely need to use SHA-256 your only option is to get a newer smart card that can handle the larger digest.
interestng explanation for my (scarce) informatic culture, but I don't understand
why, with the same smart card, Acrobat is signing with SHA-256 under windos XP.
I guess the flux you illustrated lack some detail, different from XP to WIN7.
Moreover, other softwares sign with SHA-256 pdf files with our smart cards un windows XP and WIN7.
Evidentely it's a limitation of Acrobat, not solved in version X as I hope.
Consider that many users have their own smart card and you can't ask them to change card
when they have to sign a document for you.
I guess that Adobe don't solved this problem because no much people is using it for digital sign, so it wasn't
interested in doing so.
I offer documents with digital sign for coustomers from many years, but, by now, in my esperience,
few organizations are able to cope with elecronic signed documents.
sorry for the intrusion, but I'm facing exactly the same problem using an Acrobta 9 on WinXp and Win7.
I'm ABSOLUTELY SURE that the smartcard can manage sha256WithRSA signature algos because is also used in quite a lot of processes that involves digital signatures (CADES-BES with SHA256 digests).
I've gone deep into this and also using the registry key settings (that should be already enabled by default):
Acrobat does sign in SHA1 format regardless of the above settings.
I REALLY need to obtain SHA256 signatures from Acrobat.
- There are other settings more than the ones above to check for the signature format?
- How it's possible to control what is happening? There is some log somewhere to check?
Please help me get this straight.
User A signs on Machine A (with Win XP & Acrobat or Reader v9.1 or later) and gets a digital signature that was created using SHA-256
User A signs on Machine B (with Win 7 & Acrobat or Reader v9.1 or later) using the same smart cart (not just the same type of smart card, but the exact same smart card) and gets a digital signature that was created using SHA-1
User A signs on Machine A (with Win XP & Acrobat or Reader v9.1 or later) and gets a digital signature that was created using SHA-256
User B signs on Machine B (with Win 7 & Acrobat or Reader v9.1 or later) using the same type of smart cart, but a different card then User A
Which one of these two scenarios is correct?
Hi Steve, Scenario I is correct.
The same happens with WIN7 and Acrobat X (SHA-1).
Moreover, on both machines user A with the same smart card, with different signing applications (**** from Inforcert, Actalis file protector) use SHA-256 - Actalis produces PKCS#7/CMS files as Acrobat.
Moreover, on WIN7, If i sign the same pdf file with Acrobat and Actalis, the sign with Acrobat is with SHA-1, the one with Actalis is with SHA-256.
My 3 installations un WIN7 are on 3 dell pcs acquired brand new, 2 desktop, 1 laptop, first installation of acrobat software from original disk. I think registers are clean.
I friend of mine bought a month ago a new pc with WIN7 and acrobat X oem, he is in formatics so sure he don't make mistakes:
Same problem: SHA-1.
At the start of the problem (migration from SHA-1 to SHA-256 in Italy), i tried some modifications in win registry on one of the pcs,
and I also tried some suggestions from adobe assistance and smart card/sing provider, with no results.
On win 7, if you define an identity with windows or acrobat, the sign with that identity is with SHA-256! In the same file you can sign with the no smart card
identity with sha-256, and with teh smart card identity with sha-1. Evidentely, when you use the smart card (we tried with 4 different cards) someone tells acrobat to use SHA-1, and this happens only when acrobat is installed on win7, and not on win xp.
Mistery of software.
One of the differences between Win XP and Win 7 is the underlying crypto code. Win XP uses CAPI (cryptographic application program interface) whereas Win 7 uses CNG (cryptographic next generation). I guarantee that CNG supports SHA-256, but I think the problem lies in how the Actalis software interacts with CNG.
One thing to understand is Acrobat (really any code that comes from Adobe) doesn't do any cryptographic operations. Either we rely on the OS, or we use the licensed RSA libraries.
In the case of smart cards, the software on the smart card does it's own cryptographic operation, the question is how does Acrobat talk to the smart card. Acrobat communicates either through the OS (on Windows that would be either CAPI or CNG), or through a PKCS#11 module (dll). If we are using the OS then the OS communicates with the smart card through a CSP (cryptographic service provider). It is possible that Actalis has a different CSP for Win XP and Win 7, and there is something wrong with the Win 7 CSP that is causing it to use SHA-1. What you want to do is to try and eliminate the CSP from the equation by using the PKCS#11 module and removing the pointer to the digital ID on the smart card from the Windows Certificate Store.
I can help you with the steps to do that, but before I do I want to make sure you know which is the Actalis P11 dll.
I Steve, I don't know what Aclis P11 dll is.
But, I don't understand:
I think the problem is not with Actalis software,
Acrobat was signing with SHA-1 before Actalis software or drivers of any kind has been installed on pc.
After the installation of Actalis signing software, Acrobat continues to sign with sha-1,
while Actalis sign the same pdf files with sha-256, so the problem is of Acrobat.
The problem of smart card drivers have been addressed last year with your Andre Valle, when the problem
I regret, but I think it's too difficult and time consuming for me trying to bebug the problem in this way.
I give up.
I'll use other soutions (use other signing software and use acrobat installations on xp).
Instead, I think you should try to use a smart card like those in use in Italy with Adobe on win 7 and verify the problem by yourself.
I repeat: I friend of mine has bought last month a new computer, with win 7 and acrobat X, and, after installation of only those software
and using very common start cards in Italy,
and Acrobat sign with sha-1.
At this point, I think it's your problem, not mine.
I'll not buy Acrobat X with new pcs as I was thinking to do, because the problem is the same.
Thank you for kind assistance.
I don't doubt that a new computer has the same problems because the problem is not with the computer, or the OS, but rather the software the encrypts the document hash (that encryption process is what creates the actual digital signature). Acrobat does not do the encryption, that happens on the smart card. The smart card is returning some sort of error when Acrobat sends the SHA-256 hash to the smart card (via the Win 7 OS and in turn via the Actalis CSP software). This is causing Acrobat to restart the signing process by using a SHA-1 hash and sending that to the smart card. I don't know what the error is, but it must be coming from the smart card back to Acrobat via the CSP to the CNG (Win OS) software.
I'd love it if I could get a test digital ID on the same smart card that you are using along with the same smart card reader. If I could get my hands on that setup we could figure out how what the error message is. If you have any idea how I could procure the digital ID, the card, and the card reader please let me know.
digital sign many of us use is from
Corso Stati Uniti 14b - 35100 Padova - Italy
Tel.: +39 049 8288239
distributed with smart card "carta nazionale dei servizi".
I have some e-mail references of contacts with them i had un september 2011 trying to solve the problem.
In these days I'm very busy, but I think, if you are not able to gather the necessary material,
at an appropriate moment (not in this week), I can start a chat session with yuou, for example by Adove Connectnow,
and give you the control of one of my pcs to "play" directely with it.