Published online: 18 Feb 2015.

Transcription

1 This article was downloaded by: [Gianluca Lax] On: 21 February 2015, At: 09:29 Publisher: Taylor & Francis Informa Ltd Registered in England and Wales Registered Number: Registered office: Mortimer House, Mortimer Street, London W1T 3JH, UK Information Security Journal: A Global Perspective Publication details, including instructions for authors and subscription information: Digital Document Signing: Vulnerabilities and Solutions Gianluca Lax a, Francesco Buccafurri a & Gianluca Caminiti a a University Mediterranea of Reggio Calabria, Reggio Calabria, Italy Published online: 18 Feb Click for updates To cite this article: Gianluca Lax, Francesco Buccafurri & Gianluca Caminiti (2015): Digital Document Signing: Vulnerabilities and Solutions, Information Security Journal: A Global Perspective, DOI: / To link to this article: PLEASE SCROLL DOWN FOR ARTICLE Taylor & Francis makes every effort to ensure the accuracy of all the information (the Content ) contained in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and should be independently verified with primary sources of information. Taylor and Francis shall not be liable for any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of the Content. This article may be used for research, teaching, and private study purposes. Any substantial or systematic reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any form to anyone is expressly forbidden. Terms & Conditions of access and use can be found at

2 Information Security Journal: A Global Perspective, 00:1 14, 2015 Copyright Taylor & Francis Group, LLC ISSN: print / online DOI: / Digital Document Signing: Vulnerabilities and Solutions Downloaded by [Gianluca Lax] at 09:29 21 February 2015 Gianluca Lax, Francesco Buccafurri, and Gianluca Caminiti University Mediterranea of Reggio Calabria, Reggio Calabria, Italy Address correspondence to Gianluca Lax, DIIES, Università di Reggio Calabria, via Graziella, Loc. Feo di Vito, Reggio Calabria, Italy. [email protected] Color versions of one or more of the figures in the article can be found online at com/uiss. ABSTRACT Digital signature is the key issue in a number of innovative processes, such as dematerialization, e-government, e-commerce, and e-banking. Digital signature ensures both the identity of the user and the integrity of the digital document the user signs. However, despite the robustness of the underlying cryptographic primitives, a number of vulnerabilities derive from the radical difference between handwritten signature on papers and signature on digital documents. Indeed, digital documents are not directly observable because humans need a tool to interpret the bits of the document and to represent the corresponding information. The aim of this paper is to focus on the vulnerabilities of digital signature deriving from the unobservability of electronic documents. Possible mechanisms to contrast such vulnerabilities are also proposed, highlighting their positive and negative points under a perspective that does not ignore both practical and regulatory aspects. KEYWORDS attacks, cryptographic message, digital signature, regulation 1. INTRODUCTION Digital signature is the key issue of a number of innovative processes involving different components of the economic-social-administrative system. A large number of contexts (e.g., e-commerce, e-banking) exist where the need of strong authentication of people arises, so that digital signature may be a full solution ensuring both the identity of the user and the integrity of the digital document the user signs. The latter point is probably the most critical, despite the absolute robustness of the cryptographic primitives used to generate and verify digital signatures. Indeed, even though the efforts of technology have successfully reached the goal of making digital signature w.r.t. electronic documents at least what handwritten signature is w.r.t. physical documents, the radical difference between the nature of paper-based and digital documents cannot be eliminated and could result in a number of serious vulnerabilities of the digital signature system. A traditional document consists of text written on a piece of paper, where the text represents the information and the paper represents the physical support where this information is persistently stored. This way there is an unbreakable link between the document content and the storage medium. This is both a weak and a strong point of handwritten signature. The weak point is that the link between the signature and the information contained in the document is not direct. It passes through the storage 1

3 support (i.e., the paper). As a consequence, the signature cannot detect any subsequent addition of text in the document, representing thus a weak proof of integrity of the information approved by the signer. On the other hand, the inseparability of the content from the storage support results in an elementary strong point of handwritten signature, directly deriving from the fact that no complex instrument between the human operator and the document is necessary to generate and verify a signature. Traditional documents satisfy the property of direct observability because they can be interpreted by humans using their senses (viewing and touching the document) mediated only by their capability of understanding the information contained in the document. According to this meaning, digital documents are not similarly observable, in the sense that the bits composing them become meaningful to humans only when correctly interpreted by an application and presented through an analogue physical medium such as a computer screen or a printout. This is a direct consequence of the immateriality of electronic documents and of its machine-level essence, not allowing us to directly observe and understand their content. The nice consequence is that digital signature may be both immaterial and support-independent, like the document content itself, so that it has to be necessarily linked to the bits composing the document, apparently overcoming the weakness of handwritten signature as a proof of integrity. Even though this is technically true, as far as the detection of bit-level modification of signed documents is concerned, it is more weakly satisfied whenever the integrity of the information presented to humans is considered. Indeed, complex instruments are needed not only to view the document but also to sign and verify it. Ensuring the consistency and reliability of these instruments as well as the possible capability of the document bits to produce ambiguous tangible contents is clearly outside the possibility of standard operators. From this point of view, digital signature is inherently weak. A number of vulnerabilities are known, some of them fully contrasted, some others only partially (Hernandez- Ardietaetal.,2013). The aim of this paper is to focus on the vulnerabilities of digital signature caused by its unobservability and on their possible solutions, under a perspective which does not ignore both practical and regulatory aspects. This is the added value of our manuscript to the literature. This paper is structured as follows. Section 2 starts with a brief description of the theoretical background. Section 3 proceeds with the analysis of a number of vulnerabilities of the whole signing mechanism, possibly compromising the nonrepudiation of signed documents, in spite of the unquestioned robustness of the cryptographic mechanisms used in this context. Strong attention toward solutions proposed in the literature to the above drawbacks is also given, highlighting their positive and negative points. Open issues and future trends are finally discussed in section 4, mainly concentrating on the solution of the trade-off between security and usability. 2. THEORETIC BACKGROUND In this section, the basics of digital signature are briefly recalled, without going in depth about cryptographic aspects that are outside the scope of this paper Signature Process The digital document signing mechanism relies on a public key infrastructure, enabling the binding of public keys with user identities by means of a trusted third party, the Certification Authority. Each user owns two keys, a private key and a public one. The private key is kept secret and the public one is made public. The first step of the signature generation process is the computation, on the document to be signed, of a cryptographic hash function, such as SHA-1 (FIPS, 2001), RIPEMD- 160 (Dobbertin, Bosselaers, & Preneel, 1996), or others (Kanso, Yahyaoui, & Almulla, 2012; Akhavan, Samsudin, & Akhshani, 2013). The result is called digest (typically 160 bits wide) of the document. The properties of the hash function guarantee that the digest can substitute the original document in the signature generation process since the probability of having two distinct documents producing the same digest is negligible. Moreover, the problem of finding a document with digest equal to that of another given document is not feasible, so that an attacker cannot corrupt a signed document without the signature detects it. The digest is computed on the PC by the signature software (typically supplied by the certification authority, which is a trusted third party) and sent to the smart card embedding the private key of an asymmetric cryptographic cipher, typically RSA. The smart card is then enabled by the user (typically by inserting a secret PIN) to encrypt the digest with the private key, thus producing the digital signature. It is finally sent from the smart card to the signature software running on the PC in order to produce the cryptographic message. The verification of the signature on a document is done by (1) computing the digest I of the document D, 2 G. Lax et al.

4 (2) computing J as the result of the decryption of the signature with the public key of the subscriber (included in the X.509 certificate, which is another component of the cryptographic message), and (3) checking that the decrypted digest J coincides with the computed digest I. The complete verification has to also check the validity, trustworthiness, and non-revocation of the certificate, but we do not focus on this step since it is not involved in the attacks presented in this paper The Smart Card A smart card is a small hardware device, typically the size of a credit card, embedding integrated circuits and possibly other machine-readable technologies such as bar code, magnetic stripe, and so forth. The integrated circuits implement a low-power central processing unit (CPU) providing general-purpose computing facilities as well as hardware-based encryption algorithms such as 3DES and RSA; a small amount of volatile memory (typically up to 32 Kbytes) used to store temporary data required by computation and authentication tasks; and nonvolatile storage (typically flash memory, up to 256 Kbytes) used to permanently store the chip operating system, the application software, biometric information, encryption keys, and user certificates. The usage of enough secure smart cards the European Union law fixes to the standard ITSEC E3-high the security lower bound (ITSEC, 1991) is a reasonable measure solving in practice the above problem. Thus, a smart card can be considered a trusted platform because it is not realistic to imagine that external attacks might have success. The smart card must be interfaced to a host PC to work properly. Two main interfaces exist: contact and contactless, the former requiring the insertion of the card into a reader and the latter requiring the reader to be in near proximity to the card (typically within 10 centimeters). In both cases, the reader provides power supply to the card and carries out the data exchange tasks between the smart card and the host PC running the digital signature generation/verification software. content types: data, signed data, enveloped data, signed-andenveloped data, digested data,andencrypted data. Thedata content type represents a sequence of bytes. The signed data content type consists of content of any type and encrypted message digests of the content for zero or more signers and it is used to represent digital signatures. The enveloped data content type is intended to represent digital envelopes, combining encrypted data sent to one or more recipients and the information needed by each recipient to decrypt the content (i.e., the contentencryption key). The signed-and-enveloped data content type represents digital envelopes providing data with double encryption, that is, an encryption with a signer s private key followed by an encryption with the content-encryption key. The digested data content type consists of content of any type and a message digest of the content. The encrypted data content type consists of encrypted content of any type. Figure 1 provides a visual schema of signed-andenveloped data, which is the maximum content type. The fields of this content type have the following meanings: version is the syntax version number; recipientinfos is a collection of per-recipient information; each element includes the recipient s certificate (issuerandserialnumber), the key-encryption algorithm and the result of encrypting the content-encryption key with the recipient s public key (encryptedkey); 2.3. Enveloping Signatures The cryptographic message can be encoded in several formats. PKCS#7 (Kaliski, 1998) is a standard defined by RSA describing a general syntax for data to which cryptography may be applied, such as digital signatures and digital envelopes. PKCS#7 supports several different FIGURE 1 A visual schema of signed-and-enveloped data. Digital Document Signing 3

5 digestalgorithms is a collection of the message-digest algorithm identifiers employed by all of the signers and is used to facilitate one-pass signature verification; encryptedcontentinfo is the encrypted content; certificates is a set of PKCS #6 extended certificates and X.509 certificates; crls is a set of certificate-revocation lists; and signerinfos is a collection of per-signer information (e.g., signer s certificate and authenticated and unauthenticated attributes). Any of the content types defined in PKCS#7 can be enveloped for any number of recipients and signed by any number of signers in parallel. The signed-data content type is intended to be used for digital signatures and it constitutes the basis upon the cryptographic message is built. Such a content type consists of (i) a given content of any of the types defined in PKCS#7 and, for each signer, (ii) both an encrypted message digest of the content (i.e., of the document) representing the signer s digital signature on the content and (iii) other signer-specific information (concerning, e.g., certificates and certificate-revocation lists). Additional information can be signed in order to authenticate attributes other than the content, such as the signing time. In detail, the signed-data content type consists of the following information: A list of the message-digest algorithms used by the signers (this information is optional and it is used to make one-pass signature verification easy). The content that is signed. It can have any of the defined content types. An optional set of X.509 certificates and PKCS#6 extended certificates. An optional set of certificate-revocation lists used to determine whether or not the certificates referenced by the above item are hot listed (because, for instance, they have been either revoked or suspended for some reason and thus they are not trustable anymore). A set of per-signer information: The certificate issuer s name and serial number. An identifier specifying the message-digest algorithm (e.g., SHA-1) used by the signer under which the content and authenticated attributes (if any, see the next item) are digested. An optional set of PKCS#9-compliant signed attributes (RSA, 2003) (e.g., the signing time). An identifier specifying the encryption algorithm under which the message digest and the associated information are encrypted with the signer s private key. The result of encrypting the message digest and the associated information with the signer s private key (this information is the signer s digital signature). An optional set of PKCS#9-compliant attributes that are not signed such as countersignatures (i.e., signatures associated with another signature). Besides PKCS#7, other formats for encoding the cryptographic message have been proposed to improve some particular aspect such as security, interoperability, and so forth. These formats are CMS, CAdES, XAdES, and PDF signatures. The Cryptographic Message Syntax (CMS) has been developed by the Internet Engineering Task Force (Housley, 1999) on the basis of PKCS#7 to protect data by encapsulation. The syntax supports digital signatures and encryption, allowing nested encapsulation of digital envelopes, arbitrary attributes to be signed along with the message content (e.g., the signing time), and further attributes to be associated with a signature such as countersignatures. The CMS Advanced Electronic Signatures, or CAdES (Pinkas, Pope, & Ross, 2008), derives from both CMS and Enhanced Security Services for S/MIME (ESS) (Hoffman, 1999), where additional signed and unsigned attributes have been defined to describe information such as the MIME type of the data to be signed (by means of the Content-type attribute), the signing time, and so forth. XML Advanced Electronic Signatures (XAdES) (ETSI, 2006) is based on CAdES, but it uses the syntax of XML. XAdES provides the DataObjectFormat element to describe the encoding format of the signed data (Cruellas Ibarz et al., 2013). Finally, Adobe has introduced a proprietary format for digital signatures to be embedded in PDF documents (Taft et al., 2004), in such a way that the PDF format behaves as a container for both the PDF document to be signed and the information required by digital signatures, that is, the user s certificate, the encrypted digest (both DSA [Locke & Gallagher, 2009] and RSA are supported). Besides the document, other data can be signed, such as a time stamp obtained from a trusted server, a graphic signature, or other information describing the user, the system, and the software application. 4 G. Lax et al.

6 3. VULNERABILITIES OF DIGITAL SIGNATURE In this section, a number of vulnerabilities jeopardizing digital signature are discussed. We consider both attacks arising in the signature generation phase and those depending on the ambiguous presentation of the information content to be signed. For each attack, possible solutions are described and compared Vulnerabilities of the Generation Process This section describes the vulnerability related to the trust mechanism used to generate digital signature which relies on the usage of a smart card to prevent unauthorized accesses to the private key Attacks A smart card is a handicapped computer because it misses I/O devices (Rivest, 2001; Schneier & Shostack, 1999) and has to be interfaced to a PC. As a consequence, the overall digital signature generation process cannot be considered trusted in general because the used PC is potentially untrusted. The concrete risk is that, eventually, the PC can obtain a signature from the smart 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 signed document, so that the above problem can be considered severe. According to Rivest (2001), 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). In this scenario, malware, that is, hidden software that acts on computer files without the knowledge of the user, could be intentionally installed (or created) by an attacker (e.g., one of the two parts of an agreement) on his PC, with the purpose of obtaining from the victim a signature on a document more advantageous for him (i.e., different from that displayed to the victim when, using the attacker s PC, he signs the document). This simple attack would have full success against current (even secure) signature generation devices (software plus smart card) Criterions used to Evaluate Alternatives In this section, we introduce the criterions used to evaluate and compare the solutions to face the vulnerabilities of the generation process. The comparison is done by verifying how much such solutions depend on the following four aspects: 1. the usage of extra peripherals (keyboards, displays, cameras, etc.); 2. the necessity of the presence of a trusted third party; 3. the invasiveness of the solution for the user; and 4. the impact on the law infrastructure. In the next section, we describe each solution and, then, we report a table summarizing the result of the comparison (Table 1) Evaluation of Existing Solutions The problem described in section is complicated and does not admit a complete solution whenever a standard PC is involved in the signature generation process, even though a number of (more or less realistic) approaches aimed to mitigate it have been proposed in the literature. The first technique we discuss is introduced by Abadi et al. (1993), who propose several authentication protocols, with different compromises between requirements and security, to contrast a man-in-the-middle attack trying to obtain the user s secret while he proves his identity to a node of a secure distributed environment. Here the problem of mutual authentication between a user and a node is faced through the use of a smart card with its own keyboard, display, and clock capable of performing publickey encryption. The keyboard and display allow the user to communicate directly with the smart card. The solution proposed by Clarke et al. (2002) issomewhat similar to the previous one because it requires the user to carry a device equipped with a digital camera, which is connected to the network and monitors the screen of the untrusted terminal he is using. The authors propose a method trying to minimize the cost of computation and another which uses a high bandwidth network connection to move the computation cost to a remote proxy server. The main drawback of the above techniques is that they are, from the user side, too heavy so that these solutions appear in fact too complex and impractical. A completely different approach (Naor & Shamir, 1995) proposes to renounce the smart card and to exploit visual cryptography, a new type of cryptographic scheme Digital Document Signing 5

7 TABLE 1 Comparison of the solutions Extra peripherals TTP Invasiveness Law compliance Abadi et al. (1993) Clarke et al. (2002) Naor and Shamir (1995) Berta et al. (2004) Buccafurri and Lax (2007) Downloaded by [Gianluca Lax] at 09:29 21 February 2015 that can decode hidden images without any cryptographic computation. Visual cryptography allows information to be ciphered in such a way that the decryption can be performed by the human visual system without the aid of computers. An application example is presented by Matsumoto (1998), introducing a human-friendly identification scheme such that a human prover knowing a secret key is asked a visual question by a machine verifier. Another example is proposed by Naor and Pinkas (1997), which suggests a number of transparency-based methods for visual authentication and identification and gives rigorous analysis of their security. Unfortunately, these methods can be easily broken by an attacker exploiting human interaction. To detect this kind of attacks, Berta, Buttyan, and Vajda (2004) propose a more realistic solution based on the concept of conditional signatures. Conditional signatures were introduced by Lee and Kim (2002)asamethodforsolving fair exchange problems without expensive cryptographic primitives like verifiable escrows. A conditional signature of a user on a document is composed by the ordinary signature and the description of a condition. If the ordinary signature is correct and the condition is true, then the conditional signature is considered equivalent to the ordinary one. But, if the condition is false, then the signer is not responsible for the document. Intuitively, a conditional signature corresponds to the signer s statement: I signed the document, but if the condition is not true, then my signature on the document is not valid. Berta et al. (2004) present a framework that exploits conditional signatures allowing users to conditionally sign messages on untrusted terminals with the help of their smart cards, review the conditional signatures later in a trusted environment, and revoke the fake ones (or authorize only the valid ones). In particular, the conditional signature is generated in such a way that the condition cannotbecometruebeforeacertainamountoftimehas passed. Thus, the user can meanwhile move to a trusted terminal for checking the signatures generated by the card, and to enforce that the conditions of the fake signatures can never become true. Because this approach requires the smart card to know the current time but most smart cards have no internal clock, the authors propose to acquire it from a secure time servers as described in Berta and Vajda (2003). Moreover, this proposal requires the user to store every signed message, which has to be checked later by means of a trusted terminal. As it may be infeasible for the smart card to store large messages, this problem can be solved by outsourcing the logging function to an external server. The approach presented by Buccafurri and Lax (2007) consists in computing the digest of the intended document outside the signature software and, then, checking, on board the smart card, its correspondence to the digest coming from the signature software. The digital signature generation is thus enabled in the smart card, provided that the check succeeded. The generation of the document digest for the check is done by a software module consisting in a Java applet, thus meeting portability requirements, coming from the smart card. In this case, a Java smart card instead of a firmware-programmed smart card is used. The above approach can be implemented by following two different strategies, named Fast Hash Check (FHC) and Secure Hash Check (SHC), depending on the security degree to be guaranteed and the level of efficiency required. FHC works as follows. The Java card applet, at signature time, is moved to the PC. Its execution allows the user to select the document and then the applet produces the digest that is sent to the Java card that runs the check. The computation of the digest done by the applet running on the PC improves the efficiency of the task. From the security point of view, FHC works as a full solution whenever the signature software is malicious. This is a restricted but probable set of untrustworthy cases since the highest probability of attack concerns just the signature software (not the underlying Java Virtual Machine and operating system). Indeed, such attacks could 6 G. Lax et al.

8 be implemented very simply, with no kernel-level malware, but just by corrupting the behavior of a user process. In the second strategy (SHC), the Java card contains two applets. At signature time, the first applet is moved to the PC and allows the user to select the document to be signed. This document is sent to the card, where the second applet computes the document digest. Because the digest is computed on the Java card, SHC is significantly slower than FHC but allows the detection of a higher number of kinds of attacks. Indeed, SHC cannot be broken by attacks to the signature software for the same reasons as FHC. Conversely, attacks on the Java Virtual machine (in this case the JVM is tampered in such a way it returns a maliciously selected digest) or attacks obtained by intercepting the I/O messages directed towards the smart card containing hash digests are fully contrasted since the check-digest is not computed on the potentially tampered PC Recommendations In this section, we compare, w.r.t. the features introduced in section 3.1.2, the different solutions proposed to face the vulnerabilities of the signature generation process in order to provide suggestions and recommendations about their usage in different scenarios. Concerning the technique presented by Abadi et al. (1993), its hardware requirement is high as well as its invasiveness, due to the necessity of using extra peripherals. Indeed it requires a smart card having its own keyboard, display, and clock. For similar reasons, the solution proposed by Clarke et al. (2002) is also invasive, because it requires the user to carry a device equipped with a digital camera, and has high hardware requirements. The use of visual cryptography (Naor & Shamir, 1995) requires a great effort from the signer, so that its invasiveness is high. The approach based on conditional signatures (Berta et al., 2004) exploits a trusted third party and produces a medium load for the user who has to split the signature task into two phases, delaying the effective conclusion of the procedure at validation-time. The major drawback of this proposal concerns legal aspects. Indeed, according to this approach, digital signatures are not considered as nonrepudiable proofs, at least until a short deadline. This is a relevant weakness, probably not tolerable in the current scenario where digital signatures have a wide diffusion and are included in the law system of most countries in a stable and consolidated way. Concerning the approach presented by Buccafurri and Lax (2007), it gives a full solution in a probable case of untrustworthy, that is, the corruption of the signature software at the user level, mitigating the vulnerability in the general case. Moreover, it relies on the usage of Java cards instead of firmware-only-programmable smart cards. This is a positive point because the attention towards this kind of smart cards is recently growing thanks to their capability of hosting several applications and their correlated suitability to be used for e-activities integrating multiple services on portable, cheap and user-friendly devices. Indeed, the overall merit of the approach is basically that it consists in a practical, feasible, cheap and efficient technique. Finally a major disadvantage is that this approach cannot face all kinds of attacks, for instance in case of an operating system corruption. The above comparisons are summarized in Table Vulnerabilities Based on Dynamic Presentation Digitally signed documents can be affected by a serious weakness related to the possibility for documents of having an ambiguous presentation without invalidating the digital signature. In this section, such a possibility is discussed by presenting two main issues possibly affecting digital documents and then a number of approaches aimed to solve them. The section closes with a discussion of such approaches Attacks The issue of ambiguous presentation of signed documents can arise when the digital document contains dynamic content (e.g., macros or JavaScript). 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 conditioned by the system date, in such a way that, after a given date, the amount is changed. Obviously, in this case the bits of the digital contract do not vary, so that digital signature is not able to detect any modification. However, the effects of the document, in terms of the knowledge they show, do. This issue was originally faced by Kain, Smith, and Asokan (2002), where several possible attacks are discussed. For instance, bypassing time-stamping systems by using documents whose presentation depends on a remote file or a Web URL, and also cheating audits by means of Digital Document Signing 7

9 Downloaded by [Gianluca Lax] at 09:29 21 February 2015 documents where some content results hidden only if viewed by a given user (i.e., the person performing the audit). Moreover, the work presents a taxonomy of possible approaches and document file formats eligible for inserting dynamic contents (e.g., Microsoft Word and Excel, PDF, HTML used in messages, etc.). A different source of ambiguity was proposed by Jøsang, Povey, and Ho (2002), in which the authors show how font substitution can be used to display the same digital document with different meanings on different computers. Basically, the idea is to ad-hoc manipulate a commonlyused font type (e.g., Times New Roman) in order to change the mapping between the set of character codes (typically UNICODE) and the set of corresponding graphic shapes (the so-called glyphs). This way, by typesetting a document using the modified font it is possible to present a content that may change. In fact, if the document is viewed on a PC where such a modified font is missing, then it will be typically substituted by a default font. For instance, if one takes the standard font type Times New Roman and creates a new font type named Times New Roman1 by exchanging the shapes of the characters A, I, c, and e with those of C, a, r, and k, the result is that, using the font type Times New Roman1, when one types Alice he gets Clark and vice versa. Now consider the following scenario (adapted from Jøsang et al., 2002): Clark borrows some money, say $1,000, from Alice. Then, using the above font Times New Roman1, he prepares a Microsoft Word document by typing the following text: On 24 October 2001, Alice borrowed from Clark the sum of $1,000. However, since Clark uses the font Times New Roman1, the software will display the text On 24 October 2001, Clark borrowed from Alice the sum of $1,000, provided that such a font is available. Alice sees the document on Clark s PC and agrees to the displayed content, due to the effect of the altered font type. Hence, the document is digitally signed and copied to Alice as an evidence of the loan. However, if later Alice tries to prove her case and displays the digitally signed document on a different computer (e.g., in front of a law court), the missing font Times New Roman1 is replaced by the font Times New Roman or some other default font, and the original mapping between character codes and glyphs is restored. As a result, the court will reject Alice s evidence. A more subtle attack could be conceived by directly modifying a default MS Word font type, such as the standard Times New Roman and then preparing a document 8 as Clark did in the above example. This way, unless the font Times New Roman is missing on the target PC, no font substitution will be actually performed by the software application, because the font type specified in the document properties will be found and used. However, the malicious intent will be obtained again, because the words Alice and Clark will result swapped when displayed on any host PC different by Clark s. Concerning this type of attack (font substitution), we observe that it is difficult to implement this threat in the real world. Indeed, this attack expects that Alice signs the document using a possibly untrusted computer. As a consequence, when the document is displayed on any other computer, Alice can realizes the real content she signed and has a good chance to prove that this document is fraudulent before the court Criterions used Alternatives to Evaluate In this section, we introduce the criterions used to evaluate and compare the solutions to face the vulnerabilities derived from the dynamic presentation of content. The comparison is done by verifying how much such solutions depend on the following three aspects: the effectiveness of the solution; the feasibility of the solution; and the invasiveness of the solution for the user. In the next section, we describe each solution and, then, we report a table summarizing the result of the comparison (Table 2) Evaluation of Existing Solutions The problem caused by embedded dynamic contents admits many solutions (Alsaid & Mitchell, 2005). TABLE 2 Comparison of the solutions Effectiveness Feasibility Invasiveness Disabling dynamic content Static formats XML Sandbox Parser Visual representation Font hashing G. Lax et al.

10 Solution 1: Disabling dynamic content. According to Spalka, Cremers, and Langweg (2001), dynamic content couldbedisabledinordernottobeharmful.thisisnot a novel security approach because typically any application (e.g., Microsoft Office, Adobe Acrobat) allows users to either enable or disable the macro-instructions contained into a given document. Clearly, although this solution may disarm malicious intent possibly altering the document presentation, it could also make some document useless because some of its features will not work as intended. Hence, an alternative approach is proposed by Spalka et al. (2001), restricting the actions performed by dynamic content instead of completely disabling them. In such a case, the person who is in charge of verifying a digitally signed document should be aware of which actions the dynamic content could perform on the document that would not alter the semantics and then he will be able to disable only those actions. Solution 2: Allowing only static formats. Alsaid and Mitchell (2005) prevent the problem by allowing only a number of given static (i.e., such that dynamic contents are not embeddable) file formats to be digitally signed. For example, plain ASCII files as well as some bitmap picture files (e.g., Microsoft BMP format) and PDF/A are safe since their cannot embed dynamic features, and thus their presentation is fixed. It is worth that technical rules on digital signature usage typically take this problem into account, stating that the signature has not probative value when applied to documents embedding instructions able to modify what they represent or limiting permitted formats; see, for example, the Italian technical rules DPCM 13/01/2004 ( DPCM% _v2.pdf). Solution 3: Exploiting XML. In Alsaid and Mitchell (2005), another solution is proposed that converts the document to be signed to the Extensible Markup Language (XML) format and then signs it by using the XML digital signature processing standard. Then, the dynamic features will be removed to avoid malicious intent and any external reference (e.g., style sheets) will be signed together with the document to guarantee that the viewer will render always the same presentation. Solution 4: Using a sandbox. According to Spalka et al. (2001), a further approach could be building a sandbox (i.e., a sort of virtual machine) around the software application used to sign/verify the digital signature. The idea is to save all the environment parameters that could be exploited by the dynamic contents (e.g., the date/time, the name of the user currently logged in, the IP address of the host machine, the application software parameters) in such a way that whenever the signed document is verified (possibly by another user on another machine), the sandbox sets all these parameters to the saved values, actually cheating the dynamic features, and thus producing always the same presentation. All parameters should be somehow included in the signature of the document so they can be exploited by the sandbox on the receiver s computer. Sandbox software products already exist, although they focus on limiting the capabilities of potentially malicious programs by denying access to resources (i.e., software firewalls, resident anti-malware programs). Spalka et al. (2001) suggest to modify such programs to simulate the environment in which the signing took place. Solution 5: Using a document parser. Another approach to solve the problem is to create digital signature software embedding a suitable document parser that removes the dynamic contents at signing time (Alsaid & Mitchell, 2005). The main drawback of this approach is that the parser should be aware of every possible document format. Even in the case only the most popular formats are supported by the parser, sometime their complete specifications are not available and also often proprietary formats may evolve and thus the parser should be constantly updated. Solution 6: Producing a visual document description. The approach, based on the so-called What You See Is What You Sign (WYSIWYS) concept, was proposed by Scheibelhofer (2001) and works as follows. A presentation of the document to be signed is generated by a suitable transformation. A transformation converts content data of a known format into display data (i.e., data in a welldefined format and language for which a trusted viewer is available, such as a subset of XML). If the signer approves such a presentation, both the original document and all the information concerning the corresponding transformation used to present the document are signed. This ensures that always the same presentation is generated on demand. In Alsaid and Mitchell (2005), another similar approach is discussed that creates a graphical representation (i.e., a bitmap image) of the digital document to be signed and then digitally signs such a representation. If needed, it is also possible to sign the original document and send it with the static image, but this should not be used as a legal reference. Solution 7: Font type hashing. To face the vulnerability due to possible font manipulation and substitution, Jøsang et al. (2002) suggest that a solution is hashing the font type specification of all font types used in the document Digital Document Signing 9

11 to be signed, and including such a hash in the digital signature, and finally forbidding font type substitution by the application (e.g., MS Word) Recommendations In this section, we discuss the solutions presented above by considering the features introduced in section (i.e., effectiveness, feasibility and user-side invasiveness). As for the approaches proposed by Spalka et al. (2001), although they safely avoid any possible effect of malicious code hidden in dynamic contents, they have two main drawbacks. First, in a scenario in which dynamic content is allowed, disabling dynamic contents could reduce the usefulness of documents because some of their features either will not behave as intended or will not work at all. Second, even just restricting the actions performed by dynamic contents instead of completely disabling them is a userside invasive method because the user will be prompted to choose whether an action should be allowed. Finally, a major drawback of this solution is that every viewer should be re-engineered to support the full control of the document dynamic features. Using the approach allowing only safe file formats (Alsaid & Mitchell, 2005) may make only a few formats eligible for digital signature because most digital document formats allow embedding some kind of dynamic content. Thus, this approach may be useful only in those scenarios where all the documents to be signed have no dynamic content features such as JavaScript, macrocode, links to remote files, and so forth. Also, this approach is not a feasible solution due to the many proprietary formats existing and their constant update. The use of XML is problematic because a suitable (i.e., depending on the format of the source document) wrapper should be used for converting the document to be signed into XML and cleaning it from dynamic contents. The sandbox-based solution proposed by Spalka et al. (2001) does not require any modification of the digital signature application software, but it has to face the problem of choosing which parameters should be included into those defining the environment. For example, in case the dynamic content is produced by consulting a remote file or a Web URL, the sandbox should be aware of it and then include also such an external resource into the chosen parameters. This could be performed either by querying the user or by automatic discovery. In the former case, the system could be too much user-side invasive, whereas in the latter it could not correctly discover all the needed parameters. The exploitation of a universal document parser embedded into the signature software (Alsaid & Mitchell, 2005) to filter dynamic contents is not a feasible solution due to the many proprietary formats existing and their constant update. The main disadvantage of the approach proposed by Scheibelhofer (2001), which introduces presentation descriptions to be signed along with the intended document, is that a suitable transformation has to be defined for each file format to be used. However, if the viewer application is trusted, the system could generate a presentation that depends on the capabilities of the device and the user, taking into account the user s knowledge of languages or disabilities. Moreover, it could generate presentations for several devices including personal digital assistants (PDAs), printers, Braille devices, and so forth. The approach presented by Alsaid and Mitchell (2005) exploiting graphic bitmaps to represent the document to be signed, besides limiting the flexibility found in common digital documents (for instance, without suitable OCR features, even a simple copy and paste action on the text represented by the bitmap image could not be possible), has another disadvantage due to the bigger bandwidth typically needed to send the image over the network. Concerning the approach facing the font-substitution issue (Jøsang et al., 2002), signing the hash of the used font specifications, it is a simple, less effective technique because it protects against only this threat. A more effective approach to solve this problem is using the PDF/A format that embeds the fonts used in the document and disables font substitution. The comparisons among the seven solutions discussed above are summarized in Table Vulnerabilities Based on Polymorphic Documents This section describes a vulnerability working on enveloping signatures 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 file formats not embedding dynamic features and hence considered extremely safe (Buccafurri et al., 2008) Attacks The attack is based on the capability of a file of having a static polymorphic behavior, that is, a file at the same time 10 G. Lax et al.

12 including two different contents, with different encodes, each enabled by the application suitable for the respective format. Consider two different file formats, denoted by A and B, such that, A is recognized by a distinguished file header, say H; A includes an end-of-content mechanism, allowing the viewer to detect the portion of the file being processed in order to display the content; B does not require the presence of any header at the beginning of the file; and B permits user comments that are skipped by any viewer of B. Now denote by D the sequence of bits of a given file being digitally signed, assuming that it is compliant with the format A. The attacker must suitably incorporate in D (for instance, by modifying some bytes using a hexadecimal editor) an opening comment command (denoted by OC) compliant with the format B, placing it just after the file header H.CallD the sequence of bits so obtained. Then, the attacker creates a file E, compliant with the format B. Finally, he juxtaposes the bits D, the closing comment B-command (denoted by CC), and the bits E to the file, obtaining thus the polymorphic file F. The result is that the A-viewer shows the information encoded into D (in the A encoding), whereas the B-viewer will present the information encoded into E (in the B encoding). In this sense, the file F is inherently polymorphic, and its ambiguity is activated by the switching between the utilized viewers. Observe that in most operating systems (e.g., Microsoft Windows, Linux/KDE, FreeBSD/KDE, Mac Os X), the viewer type is established by the file extension. Thus, in these cases, the ambiguity is activated just by suitably modifying the file extension. Suppose that in any of the above operating systems the name of F is contract.aaa, where the extension aaa is associated to the format A. The content presented to the user is that displayed by the A-viewer, that is, D. After the application of the digital signature, the file contract.aaa is included into the PKCS#7- compliant cryptographic message, which is a file named contract.aaa.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). If the information about the file type is not stored inside the cryptographic message, then the verification software will be vulnerable w.r.t. the following treat: In case the file contract.aaa.p7m is renamed (either by mistake or maliciously) to contract.bbb.p7m (where bbb is the extension associated to the format B) the digital signature verification process still succeeds on it, but the extracted document will be named contract.bbb. Consequently, the content presented to the user (by the signature verification software) is that displayed by the B- viewer, which is E. Hence, the user has signed the content D, but the receiver will read the content E. The attack succeeds with several formats, such as tiff, pdf, bmp, ps, rtf, doc, html. Among them, the attack on tif and pdf are the most interesting due to their wide diffusion. We describe the attack on the first format. TIFF is an image file format widely supported by scanning, faxing, image-manipulation, word processing and optical character recognition (OCR) applications. TIFF files support many features, such as compression, multipage graphics, and so on. To support such features, it relies on a flexible file structure in such a way that the information about the image is referenced by an Image File Directory (IFD), an array of fields describing the features of the image, (e.g., resolution, number of used colors, compression, image data). Each feature is suitably encoded in a separate IFD entry. Moreover, IFDs are arranged in a linked list, hence in case the file includes multiple images (such as pages of facsimile transmission, or scanned book pages), each is represented by a subfile described by a different IFD. A TIFF file ( developer/en/tiff/tiff6.pdf) begins with a 4-byte header, (either 49492A00 or 4D4D002A, in hexadecimal) specifying the byte order (either little-endian or big-endian, respectively) used to encode numeric values. The header is followed by two bytes representing a pointer to the first IFD. The attacker proceeds as follows: he inserts the opening HTML comment (<!- -) just after these two bytes and then modifies them by increasing the encoded value by 4, in order to take into account the insertion of the 4-byte string <!- -. Clearly, he has to be aware of the byte order (encoded in the header) in order to tamper the file correctly. Then, the attacker finds the IFD entries containing the offsets (with respect to the beginning of the file) of the locations where the bytes representing the actual data of the image (i.e., the pixelmap and the colormap) are stored. Hence, he increases each of these offsets by 4 in order to make them point to the correct locations. This operation has to be iterated for the entries encoding the following Digital Document Signing 11

13 tags StripOffsets, XResolution, YResolution, ColorMap and, in case the image pixels are encoded in more than one location within the file, for all the IDF entries encoding any image data offset. Finally, the attacker concatenates the HTML code containing the malicious content at the end of the tampered file. Consider now the attack on the second format. PDF is a popular file format created by Adobe Systems in 1993 for document exchange and used for representing two-dimensional documents in a way that is independent of the application software, hardware, and operating system. The structure of a PDF file ( devnet/pdf/pdf_reference.html) is the following: Header. The file begins with an ASCII one-line header identifying the version of the PDF specification to which the file conforms. Body. The body contains the document objects included in the file. Xref. A cross-reference table containing pointers and other information about the objects included in the body of the file. Trailer. A closing section, ending with the sequence %%EOF, giving the location of both the cross-reference table and special objects within the body of the file. The attacker behaves as follows: he starts by inspecting the header. It is of the form %PDF-X.Y, thatisa Postscript language comment, that is, an ASCII sequence starting with the symbol % and ending with an End-of- Line (EOL) ASCII code, where the sequence X.Y specifies the version of the PDF format. The attack is not dependent on the version of the PDF file. The attacker embeds the opening HTML comment in a Postscript comment %<!- - (ending with a non-printable EOL character) and inserts it just after the header. In case a PDF file contains binary data, the header should be followed by a Postscript comment line containing at least four bytes, each having a value 128 or greater. In such a case, the comment %<!- - (including the final EOL code) should follow it. This ensures proper behavior of file transfer applications that inspect data near the beginning of a PDF file in order to determine whether to treat the file s contents as text or as binary. Then, the attacker finds the location of the crossreference table by inspecting the tail of the file. There, the Trailer includes two lines just before the end of the file, marked by the sequence %%EOF. The former is the keyword startxref, the latter is the offset (encoded as an ASCII string) of the cross-reference table. The attacker FIGURE 2 The hexadecimal content of the polymorphic file. increases the offset value by 6 (in order to take into account the previous insertion of the opening HTML comment) and then changes all the in-use entries of the cross-reference table by adding 6 to the value encoded by the offset field. This ensures that the PDF viewer will correctly decode the file. Finally, the HTML code containing the malicious content is concatenated to the tampered file. Figure 2 shows the hexadecimal content of the constructed polymorphic file, where the shift of the pdf header is evident Evaluation of Existing Solutions In this section, a discussion on some possible solutions to the attack scheme described above is given. Basically, the first solution is including the MIME Content-type of the document to be signed into the cryptographic message in such a way that the integrity of both the document (the file) and the file format (associating the file with the intended viewer) is guaranteed. Such a value must be included into the PKCS#7 cryptographic message by suitably encoding it into the authenticated attributes. In detail, according to (RSA, 2003), the chosen MIME Content-type value corresponding to the format of the file to be signed should be encoded into the PKCS#9- compliant attribute type allegedcontenttype. Next, both the document digest and such authenticated attributes are encrypted with the signer s private key. Finally, digital signature verification software should be aware of such an additional information in order to check the integrity of both the document and the file format. Hence, if an attacker renames the cryptographic message file, the verification software, by extracting the signed Content-type value, will correctly display the document, thus disarming the attack. In case the cryptographic message is formed according to Cryptographic Message Syntax (CMS) (Housley, 1999), a solution is that the information about the document format (represented by the MIME Content-type value) should be included into the content-hints attributes. 12 G. Lax et al.

14 Such attributes are only intended for encoding optional information (such as the MIME type) defining the document format. In detail, the contenttype field should be set as id-data and the contentdescription should contain the MIME Content-Type header value specifying the intended presentation format (ETSI, 2009). Another solution is a parser-based approach allowing the user to detect patterns that could identify the attack. Theideaistocreateanapplicationabletoparsedocument files in order to check for sequences (i.e., header sequences mismatching with the expected syntax of the document) revealing a possible polymorphic behavior. Hence, the user before actually signing a suspect file would be able to scan it for polymorphic content in a similar way as using antivirus software. In case he finds a polymorphic file, he should be able to either delete it permanently or extract and safely display the hidden content Recommendations In this section, pro and cons of the above approaches are discussed. The first proposal, embedding MIME-type information in the cryptographic message, is effective against any attack based on polymorphic file because it preserves the information about the format of the original document. Conversely, the main disadvantage of the technique is that Certification Authorities should both provide modified digital signature software to support such a new feature and issue updated technical rules about the usage of PKCS#7 as well as the other cryptographic message formats (e.g., CMS). The parser-based approach works without any modification to the current digital signature platform and, thus, would detect polymorphic files included in standard cryptographic messages. However, it would be effective as long as its internal database is updated; that is, it could not face a newly invented attack because it would not include the patterns identifying such an attack. Hence, as it happens for antivirus software, it should be constantly updated. 4. CONCLUSION The importance of encryption-based digital signature is universally known. In fact, digital signature represents the only valid method to give signed electronic documents probative value, at least as traditional documents with handwritten signature. As a consequence, the issue regarding the vulnerabilities of digital signature is particularly important. This paper discusses severe problems affecting the trust mechanism of digital signature as well as the documents being signed, describing possible solutions and relevance and effectiveness of the existing approaches. Despite the large literature showing that a number of vulnerabilities exist, no adequate countermeasure has been adopted in the current real-life applications. We feel that the trend for this issue will be to take the aspect of security into more serious consideration whenever the usage of digital signature will be extended to a relevant portion of people/services. Probably, whenever the common citizen will sign electronic documents frequently, the solution of adopting closed dedicated handheld devices will be the only effective option. A new challenge is then to understand the right degree of application of the above paradigm to solve the trade-off between security and usability. FUNDING This work has been partially supported by the TENACE PRIN Project (no P34XC) funded by the Italian Ministry of Education, University and Research, and by the Program Programma Operativo Nazionale Ricerca e Competitività , Distretto Tecnologico CyberSecurity funded by the Italian Ministry of Education, University and Research. REFERENCES Abadi, M., Burrows, M., Kaufman, C., and Lampson, B. (1993). Authentication and delegation with smart-cards. Science of Computer Programming, 21(2), Akhavan, A., Samsudin, A., and Akhshani, A. (2013). A novel parallel hash function based on 3D chaotic map. EURASIP Journal on Advances in Signal Processing, 2013(1), Alsaid, A., and Mitchell, C.J. (2005). Dynamic content attacks on digital signatures. Information Management & Computer Security, 13(4), Berta, I.Z., and Vajda, I. (2003). Documents from malicious terminals. SPIE Microtechnologies for the New Millennium, Bioengineered and Bioinspired Systems, Maspalomas, Gran Canaria, Canary Islands, Spain; Berta, I.Z., Buttyan, L., and Vajda, I. (2004). Mitigating the untrusted terminal problem using conditional signatures. ITCC 04, p. 12. Buccafurri, F., and Lax, G. (2007). Hardening digital signatures against untrusted signature software. IEEE International Conference on Digital Information Management, pp Buccafurri, F., Caminiti, G., and Lax, G. (2008). The Dalì attack on digital signature. Journal of Information Assurance and Security, Clarke, D., Gassend, B., Kotwal, T., Burnside, M., Van Dijk, M., Devadas, S., and Rivest, R. (2002). The untrusted computer problem and camera-based authentication. Pervasive computing, pp Berlin: Springer. Cruellas Ibarz, J.C., Röck, A., Caccia, A., Funk, A., and Rizzo, L. (2013). ETSI EN Part 1 (Draft): Electronic signatures and infrastructures (ESI); XML Advanced Electronic Signatures (XAdES); Part 1 Core Specification v Digital Document Signing 13

15 Dobbertin, H., Bosselaers, A., and Preneel, B. (1996). RIPEMD-160: A strengthened version of RIPEMD. Fast Software Encryption, ETSI, T. (2009) : Electronic signatures and infrastructures (ESI). CMS Advanced Electronic Signatures (CAdES). ETSI, X. (2006). Advanced electronic signatures (XAdES). ETSI TS, 101, 933. Hernandez-Ardieta, J.L., Gonzalez-Tablas, A.I., de Fuentes, J.M., and Ramos, B. (2013). A taxonomy and survey of attacks on digital signatures. Computers & Security, 64(1), Hoffman, P. (1999). Enhanced security services for S/MIME. IETF RFC Retrieved from Housley, R. (1999). Cryptographic message syntax. RFC Retrieved from ITSEC. (1991). Information technology security evaluation criteria: Preliminary harmonised criteria. Document COM(90) 314, Version 1.2. Jøsang, A., Povey, D., and Ho, A. (2002). What you see is not always what you sign. Proceedings of the Australian UNIX and Open Systems Users Group Conference (AUUG2002), Melbourne, Australia; Kain, K., Smith, S.W., and Asokan, R. (2002). Digital signatures and electronic documents: A cautionary tale. In Advanced communications and multimedia security, pp Springer US. Kaliski, B. (1998). PKCS# 7: Cryptographic message syntax, Version 1.5. RFC Retrieved from Kanso, A., Yahyaoui, H., and Almulla, M. (2012). Keyed hash function based on a chaotic map. Information Sciences, 186(1), Lee, B., and Kim, K. (2002). Fair exchange of digital signatures using conditional signature. Symposium on Cryptography and Information Security, pp Locke, G., and Gallagher, P. (2009). FIPS PUB 186-3: Digital signature standard (DSS). Federal Information Processing Standards Publication. Matsumoto, T. (1998). Human computer cryptography: An attempt. Journal of Computer Security, 6(3), Naor, M., and Shamir, A. (1995). Visual cryptography. In Advances in Cryptology EUROCRYPT 94, pp Berlin: Springer. Naor, M., and Pinkas, B. (1997). Visual authentication and identification. In Advances in Cryptology CRYPTO 97, pp Berlin: Springer. Pinkas, D., Pope, N., and Ross, J. (2008). CMS advanced electronic signatures (CAdES). IETF Request for Comments, Rivest, R. (2001). Issues in cryptography. Computers, Freedom, Privacy 2001 Conference. Retrieved from lcs. mit. edu/ rivest/ Rivest-IssuesInCryptography.pdf RSA, L. (2003). PKCS #9 v2.0 Amendment 1, Technical Report from RSA Laboratories. Retrieved from docs/pca/pkcs/ftp.rsa.com/pkcs-9/pkcs-9v2-0a1d2.pdf Scheibelhofer, K. (2001). Signing XML documents and the concept of what you see is what you sign. Institute for Applied Information Processing and Communications, Graz University of Technology. Schneier, B., and Shostack, A. (1999). Breaking up is hard to do: Modeling security threats for smart cards. In USENIX Workshop on Smart Card Technology. Spalka, A., Cremers, A. B., and Langweg, H. (2001). Protecting the creation of digital signatures with trusted computing platform technology against attacks by trojan horse programs. In Trusted Information, Springer US. Taft, E., Pravetz, J., Zilles, S., and Masinter, L. (2004). The application/pdf media type. Internet Proposed Standard RFC, BIOGRAPHIES Gianluca Lax is an assistant professor of computer science at the University Mediterranea of Reggio Calabria, Italy. In 2005, he earned his PhD in computer science at the University of Calabria. His research interests include data reduction, data streams, user modeling, P2P systems, e-commerce, and information security. He is the author of a number of papers published in top-level international journals and conference proceedings. Francesco Buccafurri is a full professor of computer science at the University Mediterranea of Reggio Calabria, Italy. He received his PhD in computer science in 1995 at the University of Calabria. In 1996, he was visiting researcher at the database and knowledge representation group of Vienna University of Technology. His research interests include deductivedatabases, knowledge-representation and nonmonotonic reasoning, model checking, information security, data compression, data streams, agents, and P2P systems. He has published several papers in top-level international journals and conference proceedings. He serves as a referee for international journals and is a member of a number of conferencepcs.heisassociateeditorofinformation Sciences (Elsevier) and is also included in the editorial board of a number of international journals. He also played the role of PC chair in some international conferences. Gianluca Caminiti holds a PhD, received in March 2006, from the University Mediterranea of Reggio Calabria, Italy. His research interests cover the field of artificial intelligence, including multiagent systems, logic programming, knowledge representation, and nonmonotonic reasoning. 14 G. Lax et al.