One of essential functions of digital signatures is to guarantee the integrity of the signed data. That is achieved by encrypting the data (its checksum) with one of the asymmetric cryptography algorithms. When you make changes to the signed data, the checksum no longer corresponds to the value included in the signature, so the signature can be identified as invalid.
However, in real life, the data to be signed is often far more complicated than plain-text strings. When digitally signing document files, it is only guaranteed that the binary content of the document file is exactly as it was at the time of signing. However, it does not say anything about whether the visual representation or the document contents in the applications displaying these documents is the same.
We are demonstrating a number of ways in which, by using various functions available in .docx and .odt formats, it is possible to create documents whose file contents are unchanged and thus are not raising any doubts about the validity of the digital signature, but in which the actual content displayed to the user may vary.
We would like to emphasise that these examples do not indicate a problem with any one e-signging application but very likely any and all of them. Dynamic content can be included in any document format created by usual office applications and is affecting document signing service providers not only in Latvia, but also throughout Europe and likely the world.
Below, we describe three distinct vectors of this attack. It should be noted that the technical methods involved are not newly identified vulnerabilities; these risks have already been discussed in an era when the role of electronically signed documents in the world economy was relatively small. In our view, it is important to re-examine the risks posed by this vulnerability in 2021, when digital document is more prevalent and potential forgery has more severe implications.
Dynamic OLE objects
OLE (Object Linking & Embedding) objects are a mechanism that allows documents to include links to other documents or embed other documents, such as including a full Microsoft Excel spreadsheet, drawing, etc. in a Microsoft Word text document.
This mechanism makes it possible to include content whose representation depends on a variety of criteria, including content that can vary (possibly also non-deterministically), as it is generated right at the time of displaying of the document.
This can create a digitally signed, verifiable document, such as a contract, with a preview of which contains one text in the e-signing tool, but when you open the document file itself, a different text is shown every time.
Static OLE Object Previews
You can also achieve different representations of the content of a document by using static OLE object content, using the fact that .docx format allows an embedded OLE object, such as a text file, to include the object’s representation as a picture that can be used as an object preview.
The example shows that the text of the document is different when you open the signed document file in eParakstītājs 3.0 and then open the same document in LibreOffice.
Other ways to embed content
It should be noted that the identified vulnerability class is not specific to the applications and tools shown here. A similar way of content manipulation is also possible, for example, in .odt format documents, and using embedded OpenPGP digital signatures or almost any other.
When you open the example document, LibreOffice Writer shows that it contains a picture with numbers and has a valid signature.
When you reopen the same document, its signature is still considered valid, but the lower number appears to be different, and the user’s external IP address appears on the top image row.
Possible solutions
When it comes to signing files other than a document, such as a source code or a photo of an artwork, there is no reason to be concerned because the digital data contained in the file will be signed directly.
If legal documents are to be signed, the most important thing is to sign the correct content (visual representation) of the document, whatever the stored binary data is. Thus, in order to avoid being exposed to fraud, the most secure way to ensure information integrity is to convert the document to its visual representation (images) and to insert these images into a PDF, thusly simulating the printing and scanning of documents. It will guarantee that we sign what we see and what we signed will stay that way. You can safely insert this PDF of images into an EDOC or ASiC container and sign it. Developers can automate this process by introducing appropriate functionality in document signing products.
If this is not possible, we recommend that you opt out of signing .docx, .odt and similar files. Instead, we recommend preparing files in ISO PDF/A-1 format, enclosing them in EDOC or ASiC containers, and signing them. Risks are involved in using the PDF format as well, so we recommend that you use a PDF standard with as little functionality as possible.
Developers can go one step further. To provide safety to the second document signer, we recommend that e-signing software implements algorithms that alert the user if the document already signed by the first signee could potentially contain dynamic content. For example, the type and contents of the document can be analyzed to look for OLE objects, etc. Each of these methods has its own false positive and false negative rates, so the most suitable method should be chosen for each use case.
Electronically signed documents significantly facilitate our daily lives not only during the pandemic but also through the development of new digital services, so it is important to provide sufficient protection for their signature process to guarantee the reliability of electronic signatures and minimize fraud.