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.
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.
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  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.
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  the Italian National Agency for Digital Administration (CNIPA)  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 , which CNIPA is member of.
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 , 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 , where the document format is included as MIME type into the content-hints attributes of the Cryptographic Message Syntax (CMS). 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.