Hi Mario. The SHA256 hashing algorithm is now the most common choice globally for applying digital signatures. In particular for the European Union countries, the new terms of reference are the ETSI standards associated to the new eIDAS Regulation (n.910/2014) on electronic signatures. These standards clearly state that the SHA1 hash algorithm is deprecated and should not be used.
Adobe has been an early adopter of SHA256 for signing PDF documents in Adobe Acrobat: it was introduced in Acrobat 8 (released in 2006) and it's the default option since Acrobat 9.1 (released in 2009). See: Pre-deployment Configuration — Digital Signatures Guide for IT
I assume that your issue in signing with SHA256 in Acrobat is due to some well-known issues with some smart card drivers that are based on Microsoft minidriver templates.
Many of these drivers have been written based on sample code provided by Microsoft that contained some bugs which prevent calling applications (like Acrobat, but also Microsoft Office or any others) to access all the hashing functions provided by the smart card. So when Acrobat polls these drivers on which hashing algorithm they support, the reply does not include SHA256. In such case Acrobat falls down to using SHA1 to make a signature anyways.
So far Adobe has not been able to convince the implementors of such buggy drivers to fix their issue and stop impacting on Acrobat's users (and other software's as well). So the only workaround we can suggest is to use the PKCS#11 smart card drivers instead of the Windows CSP/minidriver. This requires a one-time manual configuration from the Acrobat preferences (see the screenshot and instructions below) but once it is done you'll get your secure and legally binding digital signatures using SHA256 as desired.
Sr. Product Manager Adobe Document Cloud
Instructions to configure a PKCS#11 driver in Adobe Acrobat
First obtain and install the PKCS#11 driver from your smart card provider. It may already come installed with the CSP/minidriver.
- Open the Acrobat preferences (Ctrl+K) then select the "Signatures" category on the left.
- Click on the "More" button besides "Identities &Trusted Certificates".
- In the left column select "PKCS#11 Modules and Tokens"
- Click on "Attach Module" and select the proper *.dll driver file as instructed by your smart card provider.
In a Windows environment normally these drivers are installed in C:\Windows\System32.
- When the driver is loaded, click on its label in the left column (see "bit4id PKCS#11" in this example)
- Insert the smart card in the smart card reader. The smart card name should appear in the right pane.
- Select the smart card and click on Login to import the list of certificates available in the smart card.
A PIN number should be normally provided.
- Once the card is configured you will find the certificates available for signing. The above operations are only required the first time in order to configure the smart card.
thank you for fast support.
The workaround you suggest is the one I did know.
The problem is that it requires the setup for every smart cart used.
In our scenario we have many different people coming in our office for signing, may be once, some documents.
It should be an easy thing to do like to sign in the old way.
We have problems to introduce the use of acrobat reader for signing (if requires a setup fore every smart card to use) instead of the others signing softwares that do not support signing fieds (like arubasign or **** that does not require any setup for different smart cards).
Our goal is the use of the signature field, but it must be easy to do.
We have at home a remote signature system and our software of remote signing supports signing in signature fields, we use it when the signers are all members of our organization.
The problem came when one or more of the signers are not members of our organization.
We did think use of acrobat reader could be the right solution.
There is an alternate solution we could find?
The other problem is to avoid that acrobat reader validate as good a signature done with sha1.
Actually if we open in acrobat reader a file signed with sha1 it is validated as good but for the Italian law it is not.
There is a setup to avoid the validation as good of the signed files using sha1?
unfortunately my instructions were already the workaround.
Let me state it again more clearly: the reason why Acrobat signs with SHA1 instead of SHA256 is a bug in the CSP/minidriver of your smart card which its authors don't want to solve.
Despite the story is known since years now, the impacted CA have always refused to fix the issue.
This is not an Acrobat issue, it is a smart card driver issue. If you try to sign with Microsoft Office you will still be affected by the same bug (and you don't even have the workaround to use the P11 driver).
You can force your documents to require a SHA256 signature, and fail if it cannot be applied. But you can't make SHA1 look invalid, as SHA1 is still perfectly valid. The Italian laws mandates the use of SHA256 but old signatures that have been made before the move to SHA-2 are still valid (especially if they are protected with a timestamp and a LTV profile.
We would appreciate if you could make your CA aware of this conversation, and refrain for considering Acrobat culprit for this bad behavior.
it is clear that the problem is a bug in the CSP/minidriver of the smart cards.
Let me explain what we are trying to do.
Our organization does not have any smart card. All our internal signers have a remote signature certificate.
We are planning to use for our internal document the signature field and our signature software can sign in the existing fields.
The problem is when an external signer has to sign a document and has a smart card or am usb token.
The work around you proposed is working perfectly but it requires a setup for every different smart card has to sign with SHA256.
For this reason it is inapplicable in a our environment; when an external signer came in our office to sign a contract we can't make a special setup for every new smart card.
If the setup of the new PKCS#11 module once done could work for every smart card of the same type (INCARD or OBERTHUR or ATHENA) would be great.
I have request a contact with the PM of our CA even if the problem does not affect our certificates but I think that signature fields are the future and I want to support the diffusion.
And I wish we will use Adobe reader for allow external signers to sign our contract in the right signature field.
Regarding the SHA1 signature I agree with you that the old ones are still valid but only if there is timestamp (for the italian law Marcatura temporale) that can demonstrate one of the following:
1)the signature was done before the 30/06/2011
2) the certificate was issued before the 30/06/2011 and the signature was done in the lifetime of the certificate. Due the lifetime is 3 years it means the last SHA1 signature valid wad done 30/06/2014.
If a signature has been done after 30/06/2014 it must be done with SHA256.
Most of the software used for verify the signature compliant with the Italian law show a warning when the signature doe not respect the actual law.
By law in Italy a software for verifying a signature has to use SHA256 (Art 4 comma 2 Bis Deliberazione CNIPA 45 del 9 novembre 2009 modificata dalla Determinazione Commissariale DIGITPA n.69 del 28 luglio 2010)
If a signature is SHA1 I should have to know in the same way if the document has been modified after the signature. There is problem with the signature for the actual law.
If it is SHA1 I will verify if there is a timestamp or others necessary things in order take a decision.
If I don't have this information then I could make a mistake.
I know there are countries where SHA1 is acceptable but it is not in Italy.
I think that verify a signed document with Adobe reader means do not change the habits of the people.
They usually open a PDF document with Adobe reader so it is easy and fast.
But due we are talking of signature the information shoud be compliant with the law of the country.
If it is not then the people has to verify the signature with an other software that gives an information compliant with the law.
And this could became a waste of time and could transform an easy and fast operation in a long and boring operation.
agreed on everything you say. Adobe products are designed to match this behavior and comply with Italian regulations since long time, and that is also the reason why they are so heavily used.
As we said - and agreed - this bug is in the smart card drivers and it is impacting negatively on our users trying to digitally sign in a regulatory compliant way.
There is nothing we can do to workaround this rather than the suggested PKCS#11 configuration, although I understand that it does not fit well within your specific use case.
Unfortunately there is not such "universal smart card driver" that could be configured once and be able to operate any smart card from different vendors. This is due to the fact that smart card file systems are proprietary and there is no common way to use them with a single driver.
My last recommendation would be to raise the CA sensitivity on this topic. It shouldn't be really a big effort to fix this bug and make everyone happy.
In the meantime we have informed the Italian authorities (AgID) about this to warn the CA about their obligations to provide signature applications that meet the regulatory requirements. In our opinion the smart card driver is part of these applications so it must work properly. Hope this would lead to a positive conclusion.
I have tested the last update for Acrobad reader DC that solves the problem of signing using SHA256.
This is a great improvement for us.
We will restart shortly our program to use signature fields in documents.
Thank you for you support.
Do you think the same patch will be released for Acrobat reader XI?
And do you think the reader will show during verifying if a signature uses SHA1 instead of SHA256?
as you see we have solved this issue by completely skipping the use of the driver in case it is not able to support SHA256.
This should solve the case with every driver, but of course we have been able to test this only with a limited set of signature devices.
This fix is only available in the Continuous builds of Adobe Acrobat DC and Reader DC, as part of our support package to prepare for the compliance to the upcoming eIDAS Regulation (910/2014) in force starting July 1st. This also includes some new features we have added with the latest update like support to Qualified Certificates and Qualified Electronic Signatures, support of PAdES Baseline levels, support of SSCD/QSCD and support of the "source of trust" information.
Some of these features are not planned for Acrobat XI as we wanted to prioritize the release on version DC on time for eIDAS rather than dropping something in favor or backward support.
Acrobat XI and DC have the same system requirements, so it should not be difficult to upgrade.
I have a question related to this.
When I use the Acrobat timestamp function (XI and DC), the timestamp signature is always SHA1 (see image below). The timestamp service that we use is set to respond with SHA256 timestamps, but Acrobat still does the timestamp signature with SHA1. The timestamp provider says this is because Acrobat uses SHA1 by default for backward compatibility. Do you know why Acrobat is using SHA1 for the timestamp signature and how it might be fixed to use SHA256?