A new Attack on Digital Signature

 

 

 

Note that in the paper titled "Fortifying the Dalì Attack on Digital Signature" in Proceedings of the International Conference on Security of Information and Networks, (SIN 2009), ACM Press, the authors show how to enhance the attack in such a way that the two involved filetypes are pdf and tiff. These are two file formats widely accepted in the context of e-government activities, which significantly increases both the danger and the plausibility of the Dalì attack.

 

 

Abstract

This paper presents a new attack on digital signature. The results sketched here will be presented at "IEEE International Conference on the Applications of Digital Information and Web Technologies" (http://www.dirf.org/diwt2008/) in August, 2008.

A new

 

Introduction

Digital signature is the key issue of a number of innovative processes involving different components of the economic-social-administrative system. In particular, e-government activities should receive from digital signature a strong hint to enlarge significantly their action and their effectiveness. However, the basic property digital signature has to satisfy is that, at least as handwritten signature, it is a non-repudiable proof of both the identity of the signer of an electronic document and the statement of what such a document represents. As a consequence, every form of vulnerability should be carefully considered in order to understand whether digital signature may represent for electronic documents what handmade signature represents for traditional ones. The most critical point of the digital signature protocol is the secreteness of the private key. This should be guaranteed against even sophisticated attacks, since compromising it could have disastrous consequences. The usage of enough secure smart cards (the EU law fixes to the standard ITSEC E3-high [16] the security lower bound) is a reasonable measure solving in practice the above problem. Indeed, a smart card can be considered a trusted platform even because it is not realistic to imagine that external attacks might have success. Unfortunately, digital signature is not free from serious weaknesses.

The most known weakness is strictly related to the fact that a smart card is a handicapped computer [22], since it misses I/O devices. As a consequence, the overall digital signature generation process cannot be considered trusted in general, since the PC used to generate the digest of the document to sign, which the smart card is (necessarily) interfaced to, is potentially untrusted. The concrete risk is that, eventually, the PC can obtain a signature from the card on an arbitrarily chosen document different from the one displayed on the screen and actually chosen by the user. Clearly the user might not be aware about the existence of the so signed document, so that the above problem can be considered really very severe. According to Rivest [21] there is an intrinsic contrast between having a secure device and having a "reasonable customizable user interface" that supports downloading of applications. In other words, one could think of a very secure digital signature application running on a stand-alone (portable) computer not allowing us to run other software (i.e., a closed machine). Otherwise, in a more realistic case, the digital signature process remains inherently insecure, since PCs cannot be considered trusted platforms. Rivest [21] suggests that digital signature should not be considered as a non-repudiable proof, but simply as a plausible evidence. Thus users should have well-defined possibilities for repudiating such signatures. The problem, well known in the literature [14, 24, 3], is thus very hard, and does not admit a full solution whenever the PC is involved in the signature generation process. However, heuristic solutions aimed to mitigate it have been recently proposed [8, 23, 18, 4, 17, 6, 7]. Another well-known weakness is related to the possibility of documents to embed macro-instructions or executable code (for example, think of macros of Word documents or Javascript code of Pdf documents). The problem is that a document containing instructions is not static, in the sense that the visualization of its content might vary as the variables, which these instructions exploit, change. For example, suppose that a contract includes an amount that is displayed as a result of a macro-instruction that is conditioned by the system date, in such a way that, after a given date, the amount is changed. Hopefully, digital signature should be able to avoid the modification of what a document shows to the user, in order to guarantee the information integrity not only in technical terms, but also from the perspective of the effects that the bits composing digital documents produce. In the above case, for example, clearly the bits of the digital contract do not vary, but their effect, in terms of knowledge they represent, does. Unfortunately, (cryptography-based) digital signature is not able to eliminate this drawback, since it is obtained from just the bits composing the document by transforming it, first by a cryptographic hash function and then by an asymmetric cryptographic algorithm (typically RSA [20]). As a consequence, digital signature is not able to detect the dynamic behavior of the document, and thus its dangerously dynamic legal effect. This vulnerability is well-known, and the general way to contrast it is trivially to force the user to check the document before signing, assuming that he is aware about the tools able to detect and remove possible dangerous instructions in the document. Another suggested way is to restrict allowed document formats to those not supporting the inclusion of instructions, like plain text, image formats, PDF/A [19], etc. Technical rules typically take into account this problem, stating that the signature has not probative value when applied to documents embedding instructions able to modify what they represent (see for example the Italian law [1]).

This paper discusses a very insidious attack, never documented neither in the scientific literature nor in technical/legal/pratictioner environments, whose effects are the same as the inclusion of instructions in digital documents, but operating without the insertion in the tampered document of any instruction, thus not covered by the cases considered by law provisions, and possibly applicable also to those formats (like image ones) considered extremely safe.

The contribution of the paper is thus simple yet net and unquestionably relevant from a practical point of view, since (1) the attack here presented succeeds against the technical infrastructure currently used and widely accepted both from law provisions and from industry standards, and, (2) further, the diffusion of digital signature is rapidly growing.

A witness of the above argumentation is that in [10] the Italian National Agency for Digital Administration (CNIPA) [9] has considered the results presented in this paper very significant, claiming the intention of addressing the problem here discussed in the preparation of the revised technical rules also by submitting our results to the Forum of European Supervisory Authorities for Electronic Signatures [13], which CNIPA is member of.

 

 

The Attack

 The attack relies on the following consideration: Whenever a user applies a digital signature to a document, he is aware about the document meaning because he sees the document as it is shown (typically on the screen of the PC where he applies the signature). Clearly, digital signature operates over the sequence of bits (i.e., the file) which composes the document being digitally signed. However, the meaning of the document depends on the way the document is shown to the user and thus on the software used to decode it. Hence, the information concerning the document type (directly depending on the way the information included into the document is encoded and consequently on the file format and the software able to manage it) is not taken into account throughout the process of digital signature, and thus it is not included inside the cryptographic message.

For instance, assume that a user decides to digitally sign a document file, named picture.bmp. After the application of the digital signature, the file picture.bmp is contained into the PKCS#7-compliant cryptographic message, which is a file named picture.bmp.p7m, because the digital signature software adds the further extension .p7m to the original document filename. Now, if the user extracts the document from the cryptographic message, the original filename is restored by discarding the previously added extension (.p7m). The information about the document filename is not stored inside the cryptographic message. As a consequence, the verification software is not able to detect any modification done to the cryptographic message filename. Hence, in case the file picture.bmp.p7m is renamed (either by mistake or maliciously) to, say, picture.htm.p7m the digital signature verification process still succeeds on it, and eventually the document file is extracted and named picture.htm.

The signature independence of the filename has not so far considered a weakness, according to the basic principle that, concerning the logical link between the document and its signature, the latter has to be mathematically connected just to the bits contained into the document that encode what the document represents and, thus, what the user signs. Unfortunately, the bits alone do not represent any intelligible knowledge unless a way to interpret them is fixed. This could not appear a risk for the digital signature robustness, since it is expected that a sequence of bits that is meaningful under a given format is not such under another one. For example, in the case mentioned above, the bits of picture.bmp, when interpreted as a HTML encoding, do not produce any readable result.

Our attack is based on the falsity of the above statement. In fact, a given sequence of bits could be interpreted under different formats producing dramatically different readable contents.

The above claim is proven by examples, on top of which we construct our attack on digital signature.

 

Consider a bitmap file with extension .bmp representing the image I. By using an hexadecimal editor, being aware about the bitmap format [5], we modify some bytes of the .bmp file by inserting an opening HTML comment (<!--) (that is skipped by any HTML interpreter). Then, we create a suitable HTML file including a given text T. Such a HTML file has to begin with a closing HTML comment (-->). At this point, we append this HTML file to the tampered picture file. The resulting file is correctly opened by a bitmap-viewer that shows the original image I. Whenever we change the filename extension from .bmp to .htm, the file will be opened by the browser showing the text T instead of the image I. This tampering scheme can be applied to many other formats like .pdf, .tif, .ps, .rtf, .doc, etc.

 

In order to be concrete, consider now the following demonstration of attack. Prof. Buccafurri wants to delegate his assistant Mr. Itisjustascientificexample to sign sales contract on behalf of himself with amount below $1,000. Prof. Buccafurri commissions Mr. Itisjustascientificexample to produce the electronic document to sign. In order to avoid the possible insertion of macro-instructions or executable code into the document, Prof. Buccafurri asks his assistant to obtain the document as a scan of a printed document (we consider this case as the least advantageous case w.r.t. the attempts of generating documents having non-static visualization). Mr. Itisjustascientificexample (who is actually an insider), in order to carry out the attack, modifies suitably (i.e., as described above) the bits of the file obtained as a scan.

In detail, just after the two first bytes of the file (encoding the bitmap format), he includes the sequence <!--, as reported in Figure 1.

 

 

Figure 1: Bitmap tampering

 

Moreover, he appends to the current file a closing HTML comment (-->) followed by the HTML code allowing the visualization of the desired (malicious) content. Observe that, in order to contrast the detection of the attack, the the HTML code can be obscured by using escape sequences.

Next, the attacker saves the image as delegation.bmp and sends it to Prof. Buccafurri to be signed. In Figure 2 the file delegation.bmp is shown.

Figure 2: File delegation.bmp

 

 Prof. Buccafurri signs the document producing the cryptographic message in PKCS#7 format, whose filename is delegation.bmp.p7m. Since it has been correctly generated and no alteration has been done, the signature verification of this document clearly succeeds.

Now, the assistant completes the attack simply by changing the filename of the cryptographic message from delegation.bmp.p7m to delegation.htm.p7m. Since the signature verification is done only on the basis of the bit stream included in the PKCS#7 message, which does not contain the message filename, its change does not affect the result of the signature verification. The signed document, as shown by the viewer, is shown in Figure 3.

Figure 3: The result of the attack

 

The document appears dramatically different from the signed one. It contains a text giving the assistant the delegation to sign sales contracts with amount below $100,000, instead of the $1,000 approved by Prof. Buccafurri. Observe that this attack works in every Operating System that recognizes the file type by its extension (like Microsoft Windows, Linux/KDE, FreeBSD/KDE, MacOsX, etc.).

 

Briefly, a possible solution could be the inclusion of the document file name into the PKCS#7 cryptographic message by suitably encoding it into the authenticated attributes. This way, the modification of the document extension is detected during the verification phase.

The solution above is close to the one suggested in [2], where the document format is included as MIME type into the content-hints attributes of the Cryptographic Message Syntax (CMS)[15]. This is done on the basis of the technical specifications and security recommendations given in [2, 11, 12], where the theoretical problem of misunderstanding the format of the signed document is generically considered (with no specific reference to possible concrete attacks). However, the inclusion of just the document format into the PKCS#7 authenticated attributes, does not contrast the attack presented in this paper, since it relies only on the modification of the cryptographic message filename.  

References
[1] Italian technical rules (DPCM 13 gennaio 2004). http://www.cnipa.gov.it/site/_files/DPCM 040113_v2.pdf.
[2] ETSI Technical Specification TS 101 733 V1.7.3., 2007.
[3] M. Abadi, M. Burrows, C. Kaufman, and B. Lampson. Authentication and delegation with smartcards. In TACS’91: Selected papers of the conference on Theoretical aspects of computer software, pages 93–113, Amsterdam, The Netherlands, The Netherlands, 1993. Elsevier Science Publishers.
[4] Istvan Zsolt Berta, Levente Butty, and Istvan Vajda. Mitigating the untrusted terminal problem using conditional signatures. In ITCC ’04: Proceedings of the International Conference on Information Technology: Coding and Computing, Vol. 2, page 12. IEEE Computer Society, 2004.
[5] BMP file format fromWikipedia. http://en.wikipedia.org/wiki/BMP_file_format.
[6] Francesco Buccafurri and Gianluca Lax. Hardening digital signatures against untrusted signature software. In Proceedings of the 2nd IEEE International Conference on Digital Information Management (ICDIM’07), pages 159–164, 2007.
[7] Francesco Buccafurri and Gianluca Lax. Signing digital documents in hostile environments. International  Journal of Internet Technology and Secured Transactions, 2008. ISSN: 1748-5703.
[8] Dwaine Clarke, Blaise Gassend, Thomas Kotwal, Matt Burnside, Marten van Dijk, Srinivas Devadas, and Ronald Rivest. The untrusted computer problem and camera-based authentication. In Proc. of the 1st Int. Conf. on Pervasive Computing, volume 2414 of LNCS, pages 114–124. Springer-Verlag, 2002.
[9] CNIPA. http://www.cnipa.gov.it.
[10] CNIPA. Personal communication, 2008.
[11] European Committee for Standardization. CWA14170 - Security requirements for signature creation applications, 2004.
[12] European Committee for Standardization. CWA14171 - General guidelines for electronic signature verification, 2004.
[13] FESA. http://www.fesa.eu.
[14] H. Gobioff, S. Smith, D. Tygar, and B. Yee. Smart cards in hostile environments. In Proceedings of the 2nd USENIX Workshop on Electronic Commerce, pages 23–28, 1996.
[15] R. Housley. Cryptographic Message Syntax (IETF RFC 3852), Vigil Security, 2004.
[16] ITSEC. Information technology security evaluation criteria: Preliminary harmonised criteria. June 1991. Document COM(90) 314, Version 1.2. EU Commission.
[17] B. Lee and K. Kim. Fair exchange of digital signatures using conditional signature. In Symposium on Cryptography and Information Security, 2002.
[18] T. Matsumoto. Human-computer cryptography: An attempt. In ACM Conference on Computer and Communications Security, pages 68–75, 1996.
[19] PDF/A Competence Center. http://www.pdfa.org.
[20] R. L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM, 21(2):120–126, 1978.
[21] Ronald L. Rivest. Issues in cryptography. In Computers, Freedom, and Privacy Conference, 2001.
[22] B. Schneier and A. Shostack. Breaking up is hard to do: Modelling security threats for smartcards. In Proc. USENIX Workshop Smart Card Technology, 1999.
[23] Tage Stabell-Kulo, Ronny Arild, and Per HaraldMyrvang. Providing authentication to messages signed with a smart card in hostile environments. In Proceedings of the USENIX Workshop on Smartcard Technology, 1999.
[24] Bennett Yee and J. D. Tygar. Secure coprocessors in electronic commerce applications. In Proc. of the first USENIX Workshop on Electronic Commerce, pages 155–170, 1995

Publications:

 

 

Home Page