SHA-1 is gone… and it’s deprecated in PDF 2.0 as well
As we reported yesterday, those in the crypto world are well-aware that Google and others have proven that SHA-1, the venerable cryptographic hash function standard, is dead. The consequences, however, are yet to be determined. Somewhere, it is safe to assume, between very very bad and catastrophic. Among many other potential points of disruption, this recently announced SHA-1 collision attack, as PC World reported, can break code repositories that use the Subversion (SVN) revision control syste … Read moreAs we reported yesterday, those in the crypto world are well-aware that Google and others have proven that SHA-1, the venerable cryptographic hash function standard, is dead. The consequences, however, are yet to be determined. Somewhere, it is safe to assume, between very very bad and catastrophic.
Among many other potential points of disruption, this recently announced SHA-1 collision attack, as PC World reported, can break code repositories that use the Subversion (SVN) revision control system. To prove the point, it seems, the WebKit browser engine repository became corrupted after someone committed two different PDF files with the same SHA-1 hash to it.
The team responsible for uncovering this vulnerability state on their website, SHAttered.io:
- It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.
- For example, by crafting the two colliding PDF files as two rental agreements with different rent, it is possible to trick someone to create a valid signature for a high-rent contract by having him or her sign a low-rent contract.
The could have used a variety of different file-types to make this point, but PDF files, of course, contain more information and benefit from more trust.
What does this have to do with PDF?
The PDF specification up through ISO 32000-1 (PDF 1.7) allowed use of SHA-1 for a variety of hashing functions. However, in PDF 2.0, SHA-1 is formally deprecated for use in digital signatures. This means that a PDF 2.0 writer should not use SHA-1 to make a message digest, and a PDF 2.0 reader may reject signatures that still use SHA-1.
Does this mean that PDFs that were signed using the SHA-1 algorithm in the past suddenly become invalid? In principle, it is now proven that the contents of such a PDF can be changed without invalidating the signature. However, the problem only exists in situations where companies didn't upgrade their document systems to the latest standards.
PDF 2.0 to the rescue!
“For those who are stuck with SHA-1 in their existing repositories of PDF documents, PDF 2.0’s new Document Security Store (DSS) including Validation-Related Information (VRI), as well as a document time-stamp (DTS) signature,” says iText founder Bruno Lowagie. “The document time-stamp signature (subtype ETSI.RFC3161) is an additional signature that should use a more recent hashing algorithm to create the message digest. The procedure of adding a DSS and a document time-stamp should be repeated before the certificate of the last signature that was added expires, or when there are indications that the algorithms that were used, whether the cryptographic hash function or the encryption algorithm, could be jeopardized,” Lowagie said.
What PDF developers can do about it
PDF developers can test their software – and its response to SHA-1 - in the PDF 2.0 context long before it gets to customers. In January, the PDF Association announced two PDF 2.0 interop workshop events in the UK, and USA, to help PDF developers test their PDF 2.0 files or implementations against others.
The death of SHA-1 makes an excellent case for testing new encryption models and circumstances. Billions of PDF files worldwide rely on secure digital signatures, encryption and other features that use hashing to disambiguate documents. PDF 2.0 is an excellent opportunity to negate this risk for PDF users.