Printer Friendly

Signing digital documents in hostile environments.

1. Introduction

Digital signature is the key issue of a number of innovative processes involving different components of the economicsocial-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 autograph signature, it is a nonrepudiable proof of both the identity of the provenances of electronic documents and the declaration of what documents themselves represent. 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 E3-high ITSEC standard (ITSEC, 1991) the security lower bound) is a reasonable measure solving in practice the above problem. Indeed, a smart card has to be considered a trusted platform even because it is not realistic to imagine that external attacks might have success. Unfortunately, a smart card is a handicapped computer (Schneier and Shostack, 1999), since it misses I/O devices. As a consequence, the overall digital signature generation process cannot be considered trustworthy 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 untrustworthy. The concrete risk is that, eventually, the PC can obtain a signature from the card on an arbitrarily chosen document, that differs from the one displayed on the screen and actually chosen by the user. Clearly the user might not be aware about the existence of such a signed document, so that the above problem can be considered really very 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 to run other software (a closed machine). Otherwise, in a more realistic case, the digital signature process remains inherently insecure, since PCs cannot be considered trusted platforms. Rivest (2001) suggests that digital signatures should not be considered non-repudiable proofs, but simply plausible evidences. Thus users should have well-defined possibilities of repudiating such signatures.

The problem, well known in the literature (Tygar et al., 1996; Yee and Tygar, 1995; Abadi et al., 1993), 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 at mitigating it are very welcome, since real-life applications using digital signatures both in e-commerce and in e-government are constantly growing, and, consequently, digital signatures should be adequately hardened in order to avoid (pre-built) legal disputes with complex resolution and, more importantly, people diffidence toward this important tool. In this work we propose an innovative approach to contrasting the above described weakness of the current digital signature protocol.

The paper is organized as follows. In the next section we introduce some background notions about the signature generation process and we give the motivations of our work, by introducing the vulnerability of digital signature which we deal with. In Section 3, a detailed description of our approach is presented, by showing that it can be implemented following two different strategies, depending on the security degree we want to guarantee and taking into account efficiency requirements. Section 4 deals with the analysis of robustness of the two techniques presented in the previous section, by identifying a number of attacks and studying how our approaches behave against them. In Section 5, we compare our approach with the state of the art, taking into account several aspects whose importance is mainly related to the practical usage of digital signature. Section 6 gives some detail about the implementation of our techniques by means of Java cards. The experimental validation of our methods as well as the analysis of their performance is given in Section 7. Finally, in Section 8 we draw our conclusions.

2. Background and Motivations

We refer in this paper to strong digital signatures, that is digital signatures based on asymmetric cryptographic techniques and on the usage of a secure external device (like a smart card or a token USB) for the generation process. In this section we briefly recall how the mechanism of digital signature proceeds, without going in depth about cryptographic aspects that are outside the scope of this work.

The first step of the signature generation process is the computation, on the document to sign, of a cryptographic hash function (like SHA-1 (Secure Hash Standard, 2002) or RIPEMD-160 (Dobbertin et al.,1996)). The result is called digest (typically 160 bits) of the document and the properties of hash function guarantee that it can substitute the original document in the signature generation process since the probability of having two distinct documents producing the same digest is very low. Consequently, the problem of finding a document colliding on a digest of another distinct document is unfeasible, 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) and
A: U [right arrow] SS : F U selects a file in SS

B: SS [right arrow] SS sends the hash digest of F to SD
SD : D = H(F)

C: SD [right arrow] SD cyphers D with, U's secret key
SS : {D}[K.sub.s]

Figure 1. The standard signature protocol.


sent to the smart card embedding the private key of an asymmetric cryptographic cipher, typically RSA (Rivest et al., 1978). The smart card then encrypts the digest using RSA 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 (tipically in PKCS#7 format (Kaliski, 1993)). Figure 1 summarizes the message exchange between the user U, the signature software SS, and the signature device SD with the same notation as used for BAN logic (Burrows et al., 1989).

The robustness of RSA (Cramer and Shoup, 1999) (used with enough large keys, typically 1024 bits) and the security used to manage the private key, allow us to give to the digital signature so obtained the power of non-repudiable proof of both identity (guaranteed by a public key X.509 certificate (Polk et al., 1999) granted by a trusted certification authority--included into the PKCS#7 message) of the provenances of the signed document and declaration of what the document itself represents.

Despite the robustness of both hash function and RSA, digital signature suffers from a particular attack allowing an attacker to obtain documents digitally signed by a user without his knowledge (Tygar et al., 1996; Yee and Tygar, 1995; Abadi et al., 1993). This vulnerability arises from the necessity of moving the document digest from the signature software (installed on the user's PC) to the smart card. In this step, the explicit link between the document and its digest is lost. For this reason the smart card does not know which document it is signing, but only its digest.

The general form of the attack is the following: A malware poisons the terminal (typically a PC) where the signature software runs so that each time the user digitally signs a document by enabling the smart card, the malware sends the smart card the digest of another document, maliciously selected (and potentially created) by the attacker, that will be signed by the smart card. Clearly, the above attack can be conducted at different levels (with or without corruption of the operating system or/and the Java Virtual Machine). Clearly, as widely remarked in the literature, no strategy solving the problem at each level can exist, until devices used to sign are the current ones (PC plus smart card). In Section 4, we analyze a set of possible attacks in detail, studying the capability of our technique, presented in the next section, of contrasting them.

3. Our Proposal: The Applet-Based Check

As already introduced, digital signature suffers from a severe vulnerability, directly deriving from the potential untrust worthiness of the platform where the signature generation process runs. In this section we present our solution to the above problem. Basically, the approach consists in computing the digest of the intended document outside the signature software and,
1: U [right arrow] EH-Applet
2: Ell-Applet--JC : D [??] (F) D should be the digest of F
A:U [right arrow] SS:F'
B: SS [right arrow] JC : D' [??] H(F')
3: if D7 [not equal to] D'then JC
[right arrow] SS: [??]

if the two received digests differ, then JC does not produce
the signature

C: else JC [right arrow] JC cyphers D with U's secret keg
SS : {D'}[K.sub.s]

Figure 2. The FHC-based protocol for signature.


checking, on board the smart card, its correspondence to the digest coming from the signature software. The software module generating the digest for the check is a Java applet (in order to meet portability requirements) coming from the smart card (that is a Java smart card instead of a firmware-programmed smart card). The digital signature generation is thus enabled in the smart card provided that the check succeeded.

The above approach can be implemented following two different strategies, depending on the security degree we want to guarantee and taking into account efficiency requirements. The two resulting techniques are:

FHC (Fast Hash Check): The protocol is reported in Figure 2, where U, SS, and JC denote the user, the signature software, and the Java card, respectively. FHC works as follows. The Java card contains an applet, called External Hash Applet (EH Applet, for short) that, at the signature-time, is moved to the PC. Its execution allows the user to select a file, say F (step 1 of Figure 2), and then EH-Applet produces a digest that is sent to the Java card (step 2). Let denote by D the digest received from the Java card that should be the digest of F (we say should be since we allow malicious behaviours due to the attacks described in Section 2). From the signature software (step A) the user selects the intended document F' (in the standard case F and F' coincide--in fact the user could execute some trap by intentionally selecting two distinct documents). At this point the signature software computes a digest and sends it to the Java card (step B). Let denote by D' the digest received from the Java card. Again, D' should be the digest of F'. The Java card generates the signature (i.e., the cryptographic transformation of D') only if D' = D (clearly this test is done on board of the Java card)--steps 3 and C. Observe that steps A, B, and C coincide with those reported in Figure 1.

SHC (Secure Hash Check): The protocol is reported in Figure 3, where U, SS, and JC denote the user, the signature software, and the Java card, respectively. SHC works as follows. The Java card contains two applets, called File Sender Applet (FS-Applet for short) and Internal Hash Applet (IH-Applet for short), respectively. At the signature-time FS-Applet is moved to the PC. Its execution allows the user to select a document, say F (step 1 of Figure 3). Then FS-Applet sends this file to IH-Applet running on the Java card (step 2). Let denote by F' the document received from IH-Applet (again, we use a different symbol since we allow malicious behaviours due to the attacks
1: U [right arrow] FS-Applet U select a file in FS-Applet
2: FS-Applet [right arrow] F' should coincide with F
JC : F [??] F
A:U [right arrow] SS:F
B: SS [right arrow] JC : D = H(F)
3: if [??] [not equal to] H([??])
then JC [right arrow] SS : [??]

if the digest received differs from one obtained from [??],
then JC does not produce the signature

C: JC [right arrow] JC cyphers [??] with U's secret keg
SS : {[??})}[K.sub.s],

Figure 3. The SHC-based protocol for signature.


described in Section 2). The execution of IH-Applet computes the digest D' of F' From the signature software the user selects the intended document, F (step A). Then the signature software computes its digest [??] that is sent to the Java card (step B). Let denote by [??]' the digest received from the Java card. The Java card generates the signature (i.e., the cryptographic transformation of [??] only if D' = D(steps 3 and C). Also in this case steps A, B, and C coincide with those reported in Figure 1.

Observe that in order to implement our proposal, the user is required to run steps 1 and 2 in addition to the standard ones. However, changes do not involve the signature software, whose execution remains that of the standard case (i.e., steps A, B, and C).

Basically, the two techniques differ only on where the digest for the check is computed (on the PC in FHC, on the Java card in SHC). This affects both the efficiency and the security of the approach. In particular, concerning the first aspect, we observe that FHC is significantly slower than SHC (thisjustifies the adjective fast used for FHC). In Section 7, we illustrate in depth this aspect by experimental analysis. The next section deals with the second aspect mentioned above, that is the security of the two techniques.

4. Security Analysis

In this section we describe a set of plausible attacks and we study how the two techniques presented in the previous section contrast them. We will show that SHC is strictly more secure than FHC (from which the adjective secure derives), even though FHC is able to contrast a very realistic class of attacks. In particular, we distinguish five possible attacks. Each attack can be done in two modalities, which we call general and ad-hoc. The modality general means that the malware is not aware about the intended document (the document which the user intends to apply his digital signature to). Therefore, the smart card receives the digest of a maliciously-selected document independently on the document chosen by the user. Differently, the more sophisticated modality ad-hoc, enables the malicious behaviour only whenever the user chooses a particular document (this modality is more sophisticated since cannot be detected by using dummy documents in order to test the correct behaviour of the platform). The five possible attacks are the following:

SSA (Signature-software attacks): The (user-level) signature software is tampered in such a way that, even though the user can correctly select the document he wants to sign, the software computes and sends the digest of another document to the smart card. Here, both the Operating System and the Java Virtual Machine are trusted, while the software is either corrupted or fake (intentionally produced by an hostile part).

JMA (Java Virtual Machine attacks): The Java Security API of the Java Virtual Machine computing digests is tampered in such a way it returns a maliciously-selected digest.

WCA (Weak Communication attacks): This attack is obtained by intercepting the I/O messages (APDU commands) directed toward the smart card containing hash digests. We call these attacks weak because of their relative simplicity in the detection of the victim message (that, for interoperability reasons, has a fixed size, namely 160 bits, and it is included in an APDU message with specific standard form).

SCA (Strong Communication attacks): This attack is obtained by intercepting the I/O messages (APDU commands) directed toward the smart card. We call these attacks strong since they are not limited to a particular type of message (like the previous ones).

UIA (User-Interface attacks): The OS-user interface is tampered in such a way that the feedback to the user about the real selection of documents is falsified.

Let us analyze the capability of FHC and SHC of contrasting the above attacks. First consider FHC. We can easily recognize that FHC fully contrasts SSA-attacks (those based on the signature software compromission) under both the general and ad-hoc modality, exploiting the trusted extra communication channel between the user and the Java card. Now let consider JWA-attacks (tampering the Java Virtual Machine in such a way it returns a maliciously-selected digest). It is easy to show that in this case FHC cannot guarantee security since the digest sent to the Java card can be tampered. However, in case JWA-attacks work under the general modality, there is a possible human check that, exploiting FHC, allows us to detect the attacks. More precisely, if the user, instead of applying the standard signature procedure requiring that the document selected for the signature and the document selected for the check coincide, he intentionally (as a trap) selects two different documents, FHC is able to detect the anomalous behaviour of the platform, since the difference between the two documents is not detected. From now on, we call this human check, manual trap. It is easy to verify that the manual trap does not work in case JWA-attacks operates under the ad-hoc modality. Indeed the anomalous behaviour is enabled only in case of the intended document, thus vanishing the manual trap. Equal considerations can be repeated for WCA-attacks, where the (correct) digest sent from FHC to the Java card can be replaced by a fake one during the I/O communication. Also in case of UIA and SCA attacks, FHC fails. Again the manual trap is successful with both WCA-attacks, UIA-attacks, and SCA-attacks only under the general modality.

Consider now SHC. Obviously it cannot be broken by SSA attacks for the same reasons as FHC. Conversely, both JWA attacks and WCA-attacks are fully contrasted since the check digest is not computed on the potentially tampered PC.

Moreover, there is no possible corruption of the digest during the communication between PC and Java card, since the check-digest is generated and exploited on board the Java card (thus such a sensible communication does not occur). Unfortunately, also SHC can be broken by both SCA-attacks and UIA-attacks, as it can be easily recognized. As it happens for FHC, the classes of attacks which cannot be contrasted (SCA-attacks and UIA-attacks, in this case), can be mitigated only in case they work under the general modality thanks to the manual trap. Indeed, the manual trap allows us to detect the anomalous behaviour of the platform.

We summarize the above considerations in Table 1 where the robustness of the two strategies against the considered attacks under the two modalities (G denotes general and A denotes ad-hoc) is reported. Therein, C and M denote that the attack is contrasted or mitigated, respectively, whereas F denotes that the strategy fails.

Relating with the initial observation of this section, we note that even the least robust method here presented (i.e., FHC) works as a full solution in a restricted (but probable) set of untrustworthy cases (and mitigates the problem in the more general cases). On the other hand, the highest probability of attack concerns just the signature software (not the underlying Java Virtual Machine and Operating System)--thus SSA attacks. Indeed, such attacks could be implemented very simply, with no kernel-level malware, but just by corrupting the behaviour of a user process. Consider that this type of malware could be intentionally installed (or created) by an hostile counterpart on his PC (for example one of the two parts of an agreement), with the purpose of obtaining from the victim a signature on a more advantageous document (different from that displayed to the victim when, using the PC of the attacker, he signs the document). With current (even secure) signature generation devices (software plus smart card), this probable and simple attack would have full success.

5. Comparisons with Other Approaches

In this section we give a quick survey on the major proposals existing in the literature to contrast the problem faced in this paper, and we compare them with our approach. The comparison is done considering four aspects, that are:

1. The usage of extra peripherals (like keyboards, displays, cameras, etc.)--that we call Additional Hardware (AH, for short).

2. The presence of a trusted third party--that we call Third Party (TP, for short).

3. How much the technique is more invasive for the user, than the standard technique--that we call User Load (UL, for short).

4. The impact on the law infrastructure- that we call Impact on Law (IL, for short).

Both AH, TP, and IL are boolean variables, whereas for the qualitative parameter UL we have considered the values low, medium and high.

The first technique we consider is presented by Abadi et al. (1993,1991). Therein the authors propose some authentication protocols, with different compromises between requirement 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. The protocols that guaranties sufficient security require a smart card provided with its own keyboard, display, and clock. Therefore, for this technique AH is yes, TP is no, UL can be evaluated as high (due to the necessity of using of extra peripherals) and no impact on law occurs (i.e., IL is no).

The solution proposed by Clarke et al. (2002) is somewhat similar to the above one, since it requires the user to carry a device equipped with a digital camera, which is connected to the network and that monitors the screen of the untrusted terminal he is using. Obviously, the parameters AH, TP, UL, and IL have the same values as above (i.e., yes, no, high, no, respectively).

Observe that the two negatives values (those of AH and UL) reflect a serious drawback of these techniques that, even if full from the security point of view, appear in fact too complex and unfeasible from a practical point of view.

Stabell-Kulo et al. (1999) presents a solution to how to sign data in a hostile environment that is based on the usage of a verification server together with a substitution table and a onetime pad. This solution is non-satisfactory from the security point of view since a denial-of-service attack to the verification server or its collusion with the attacker can produce a signature on data not intended to be signed. Moreover its realization is slightly awkward. In this case no extra hardware is used (i.e., AH is false), a trusted third party is required (thus, TP is true), the technique can be considered slightly invasive (i.e., UL is low) and no impact is produced on the legal notion of digital signature.

A completely different idea has been followed by some authors, who have proposed to renounce to smart card and to exploit visual cryptography (Naor and Shamir, 1995), a new type of cryptographic scheme which can decode concealed images without any cryptographic computation. For example, Matsumoto (1996) presents human-friendly identification schemes such that a human prover knowing a secret key in his brain is asked a visual question by a machine verifier, who then checks if an answer sent from the prover matches the question with respect to the key. Another example is proposed in the paper of Naor and Pinkas (1997) that suggests a number of transparency-based methods for visual authentication and identification, and gives rigorous analysis of their security. Again, as authentication method, Ateniese et al. (1996) propose a visual cryptography scheme for a set of participants to encode a secret image into many secondary images in such a way that any participant receives one secondary image and only qualified subsets of participants can "visually" recover the secret image, but non-qualified sets of participants have no information, in an information theoretical sense, on the original image. This scheme does not require the participants to perform any cryptographic computation. Unfortunately, these methods can be easily broken by attacker exploiting human interaction too. The above group of techniques, exploiting visual cryptography, can be evaluated jointly, w.r.t. the four parameters considered in this comparison. Indeed, in both cases neither extra hardware or trusted third party is required (i.e., AH is false and TP is false), whereas the user load can be considered very relevant (thus, UL is high). Again, no impact on the legal notion of digital signature derives from the above techniques (i.e., IL is no).

Beside others proposals like Hopper and Blum (2000); Schneier (1999), that are user-side too heavy, the most interesting one is represented by conditional signatures (Berta et al., 2004). They was originally introduced by Lee and Kim (2002) to implement fair exchange of digital signatures, and do not require the card to have a user interface or any special peripheral (like Clarke et al. (2002)), and can be implemented using smart cards existing today. Moreover, they do not require the user to perform cryptographic operations or to memorize cryptographic keys. The core of the proposal in Berta et al. (2004) is to generate, instead of an ordinary signature, a conditional signature such that it is guaranteed that the condition can not become true before a certain amount of time has passed. This should leave time for the user to move to a trusted terminal for checking the signatures generated by the card and to enforce that the conditions of the fake signatures can ever become true. Since this approach requires the smart card to know the current time but most smart cards have no internal clock, it could be acquired from a secure time servers as described in Berta et al. (2003). Moreover, this proposal requires the user to store every signed message, that has to be checked later by means of a trusted terminal. Since it may be in feasible for C to store large message, this problem can be solved by outsourcing the logging function to an external logserver. Therefore, even though the required hardware is the standard one (that is, AH is no), a trusted third party is required (i.e., TP is yes). Moreover, we may evaluate as medium the load for the user (i.e., UL is medium), 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 added to the other weak point concerning the necessity to contact a trusted server to get the current time and a logserver where to save each message (actually, the authors propose also some variants in Berta et al. (2003) trying to overcome the latter weakness). In sum, the technique presents in practice a number of problems, whose solution should not be simple and, more importantly, should have radical impacts, probably not tolerable in a scenario where digital signatures have a significative diffusion and are included in the law system of most countries in a stable and consolidated way.

Consider now our approach (in this case it is meaningless to distinguish between FHC and SHC, since neither security or efficiency features are considered here). Unlike the other techniques, it results that our approach presents the best behaviour w.r.t. all the four considered aspects. Indeed, it does not require extra peripherals (i.e., AH is no), it does not involve any trusted third party (i.e., TP is no), it does not require significative extra procedural charge to the user, since he has just to make one more time the selection of the document to sign (we have evaluated as low the user load) and, importantly, it does not affect the legal notion of digital signature. Moreover, observe that the entire infrastructure currently used for digital signature (signature softwares, certification system, signature check, etc.) is totally preserved with just the introduction of Java cards in place of firm ware programmed smart cards. However, this change is not only tolerated by the current system but also expected (at least in EU), as witnessed by the recent EU technical laws allowing the usage of such a kind of cards, mainly to enable multi service smart-card-based applications. More precisely, thanks to technologic improvements of devices in term of security, some recent kinds of Java cards (Multos, 2008) obtained the ITSEC E6- high certification, definitely above the EU minimum security requirement that is ITSEC E3-high (EU Journal, 1999).

Table 2 summarizes the results obtained by comparing the different techniques, as discusses above.

6. Implementation Issues

In this section we describe the architecture of the system implementing our solution. We start by giving some more detail about Java cards. Every Java card can store and run several Java-card applets allowing thus the implementation of different features carried on the same card. A Java card contains the Java Card Virtual Machine, used to process bytecode, and some native methods implemented in hardware to run complex operations like cryptographic algorithms.

To implement our proposal we designed the three Java card applets described in Section 3 and a fourth one. In particular, the first applet EH-Applet is executed to implement the Fast Hash Check strategy, whereas the second and third applets, FS-Applet and IH-Applet, respectively implement the Secure Hash Check. Finally, we designed a further applet, called RSA Applet that is used in both the strategies to compute the signature.

The system architecture is shown in Figure 4, where we report two modules: the left one contains elements (that are the four applets and the Java Card Virtual Machine) implementing Java card features, the other one includes components (the signature software and the Java Virtual Machine) running on the PC.

EH-Applet allows the user to select a file, then it compute its digest, by exploiting the Java Virtual Machine on the PC, and finally it sends this digest to the Java card, according to the FHC strategy. This digest is finally stored into an internal data structure of the Java card, an array of 20 8-bit elements. In our implementation digests are generated by SHA-1 (Secure Hash Standard, 2002), the most frequently used hash function in the digital signature field.

[FIGURE 4 OMITTED]

However, the use of a different hash function (for example RIPEMD-160 (Dobbertin et al., 1996)) does not requires changes of the system architecture.

Regarding the implementation of the SHC strategy, by means of FS-Applet the user selects the file to sign. Then this applet exploits the Java Virtual Machine to send the file synchronously to IH-Applet running on the Java card. At the end of the transmission IH-Applet produces the digest of the document, that is stored into the Java card. Observe that it is unfeasible a solution requiring that the document is even temporarily stored into the Java card, because of its limited memory capacity. To solve the above problem, our approach relies on a serialization of the hash computation, with a spatial computational cost of about 512 bits, so that SHA-1 is computed incrementally for 512-bit blocks of the file along with its transmission. In particular, the algorithm to compute SHA1 digests initially considers the first 512 bits of the file, splits them into 16 blocks of 32 bits, and each of them is processed 80 many times. This processing consists in resolving boolean expressions (depending on the hash function) obtained on the basis of the value of the bits of each block and the value of a seed. At each iteration, the seed is changed according to the result obtained. This process is iterated until the last block of the file is reached and the last result (that is rounded in some case) gives the digest. Moreover, the hash function provides also some rules to pad the last block in case its size is less than 512 bits.

The last applet, RSA Applet, performs the task of generating the digital signature starting from the digest received from the signature software. The implementation of this applet exploits some native functions of the Java Card Virtual Machine, that implements RSA in a very efficient way. Obviously, before the generation of the signature, this applet checks that the digest previously stored into the internal structure is equal to that one received from the signature software.

The functionality of file transfer from FS-Applet to IH-Applet has been realized by exploiting the APDU protocol (Application Protocol Data Unit) (Deville et al., 2003), a standard protocol for the communication between smart card and reader. It is based on the sending of suitable APDU commands, which the receiver can reply to by APDU responses. The format of APDU commands and responses has been defined by the ISO 78164 standard (ISO 7816-4, 1995) and is reported in Figure

[FIGURE 5 OMITTED]

5. In particular, CLA (having size of 1 byte) specifies a class of commands (as defined by ISO 7816-4), INS (1 byte) denotes the particular command inside this class, P1 (1 byte) and P2 (1 byte) are the parameters of the command, Lc (1 byte) denotes the size of the following DATA field, DATA contains data to be sent to the smart/Java card, and finally Le (1 byte) shows the size in bytes of the possible APDU response. In our implementation we partitioned the file of document whose digest has to be computed by Java card, into a number of blocks, and each block has been transferred to the Java card by means of a single APDU command. We exploited the field DATA to send the blocks of the file, the field CLA and INS to call the suitable applet, and finally the parameter P1 to indicate the conclusion of the file transmission.

Concerning APDU response, Java card sends a response containing in the status word SW, having size of 2 bytes, a response code of 0x9000 to indicate that the file transfer completed successfully. Otherwise SW contains an error code.

7. Experimental Evaluation

Our proposal has been implemented and tested by means of a software emulator of Java cards. We used the CREF (Clanguage java card runtime environment) javacard emulator of Sun Java Card (JCDK, 2008), which is written in the C programming language and simulates a Java card platform reference implementation compliant with the ISO 7816-4 specification (ISO 7816-4, 1995). In order to test the solution, we implemented a further applet for the generation of the public and secret asymmetric keys and a Java application running as signature software on the PC.

Before the simulation, we have to prepare the Java card by loading the applets we designed. For this purpose, such applets have been compiled by Java Sun Compiler (Java Compiler, 2008) that transforms them into bytecode. Then, we used the tool converter of Java Card [TM] Technology (JCDK, 2008) that verifies class files comply with limitations of Java Card language subset and then converts Java classes into a CAP file, a JAR-format file which contains the executable binary representation of the classes. CAP files are processed by an off-card installer, called scripigen, another tool of Java Card'm Technology (JCDK, 2008) that produces a script file containing the sequence of APDU commands necessary to upload the applets to the Java card. Then, the javacard emulator CREF has been run. The command apdutool provided by JCDK (2008) sends the commands stored in the script file to the Java card, which receives the applets to upload. Finally, the Java card is requested to execute the applet for the generation of the public and secret asymmetric keys only just uploaded. Now the Java card is ready to be tested.

The first experiment aims to verify the correct working of the Java card in case of absence of attacks. We sign a document following both the FHC and the SHC strategy, as described in Section 3. At the end of both the procedures, the signature software shows us a success message, stating that the signature generation successfully concluded. The analysis of the emulator log shows the signature value that has been returned to SS by means of an APDU response. We have successfully verified this signature with the public key. This proves the correctness of the applets to generate the signature.

In the second experiment, we simulate the corruption of the signature software in such a way that, whatever file the user selects, the digest sent to the Java card is that one of a document created by an attacker (thus we simulate a Signature Software Attack in the general modality). We repeat the same procedure described above to generate the signature. At the end of the procedure, the emulator log shows that the APDU response given by the Java card to the signature software contains all zeros in the field DATA and an error code in the SW field. Moreover, also the signature software shows a message error that the signature operation failed due to an unknown error. This shows that the Java card does not generate the signature in the case the digest received by the signature software differs from that one computed from the document selected by the user. We obtain the same result also for the ad-hoc SSA attack.

In the next experiment, we use the correct version of the signature software but simulate the corruption of the platform in such a way that whenever a software (both the signature software and the I/O applet) requires to send a digest to the Java card, this digest is replaced by that one of a pregiven (from the attacker) document. First, we study the FHC strategy. As expected, at the end of the signature procedure the log of the javacard emulator reports the signature of the maliciously created document, proving the impossibility for FHC to contrast such an attack. However, as described in Section 4, these attacks running in general modality can be mitigated by the manual trap (i.e. by intentionally selecting two different documents). In such a way, the user selects in the File Sender applet a file different from that one he intends to sign. Differently from the user expectation, the signature software shows a success message, and thus the attacker has been able to obtain the user's signature on a maliciously-selected document. However, because of the abnormal behaviour of the signature software, the user can detect the success of the attack and mitigates its damages.

For the sake of presentation we do not report the result of the further simulations done to analyze the remaining typology of attacks (we recall that we distinguished ten different class of attacks). However such experiments validate the analysis provided in Section 4.

Finally we conclude this section by comparing the running times of the FHC strategy and SHC for different sizes of the document. We recall that the main difference between the two strategies is that the digest of the document is computed on the PC in the FHC strategy, whereas on the Java card in case of SHC strategy. The analysis shows that in the first case the digest computation takes less than 1 s in case of documents smaller than 30 megabytes, whereas the SHC strategy requires about 10 s per megabyte. This suggests the user to prefer the fast approach (FHC) in case of large or numerous documents, provided that the environment does not present a high level of hostility.

8. Conclusions

The importance of encryption-based digital signature is nowadays universally known, due to the revolution that such a mechanism has induced on the role of electronic documents in both public and private organizations. In fact, digital signature represents at the moment the only valid method to give to signed electronic documents probation value at least as traditional documents with autograph signature. The above claim has a full counterpart with the current law system of most countries, so that the process of document dematerialization has been already started relying on the current infrastructures as well as the current juridical regulation, with strong attention towards interoperability common rules. According to the above observations we may realize that any proposal to harden possible vulnerabilities of digital signatures should be conservative w.r.t. the existing infrastructures. Actually, a serious vulnerability occurs, not depending on the algorithms on which digital signature relies, but strictly related to the practical way in which digital signature is implemented. This vulnerability allows an attacker to obtain the signature of a document without any intention of the signature owner. The danger is thus very concrete, especially if we think of a next future where electronic documents will be used in a pervasive way in all economic and administrative negotiations. This work concerns with this aspect, whose full solution would require radical changes of the current system, making this ambition unfeasible. In turn, the approach followed in this paper was to find a practical, feasible, cheap, and efficient technique to mitigate the vulnerability above described. The nice feature of our proposal is that it contrasts significantly possible attacks to digital signature with no change of the current software and legal infrastructure. Moreover, our approach relies on the usage of Java cards instead of firmware programmable smart cards. This can be viewed as a positive point because the attention towards this kind of smart cards is recently growing due 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.

Acknowledgments

The authors are grateful to Massimo Mercuri for the important contribution given in the implementation task.

Received 1 April 2008; Revised and accepted 7 June 2008

References

[1] Abadi M., Burrows M., Kaufman C., Butler W. Lampson (1993). Authentication and delegation with smart-cards. In TACS'91: Selected papers of the conference on Theoretical aspects of computer software, p. 93-113, Amsterdam, The Netherlands, 1993. Elsevier Science Publishers B. V.

[2] Abadi M., Burrows M., Kaufman C., Butler W. Lampson (1991). Authentication and delegation with smart-cards. In Theoretical Aspects of Computer Software, p. 326-345, 1991.

[3] Ateniese G., Blundo C., De Santis A., Stinson D. R. (1996). Constructions and bounds for visual cryptography. In F. M. auf der Heide and B. Monien, editors, 23rd International Colloquium on Automata, Languages and Programming, 1099, p. 416-428, Berlin, 1996. Springer-Verlag.

[4] Berta I. Z., Butty"an L., Vajda I. (2004). Mitigating the untrusted terminal problem using conditional signatures. In ITCC '04: Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC'04) 2, 12, p. 12, Washington, DC, USA, 2004. IEEE Computer Society.

[5] Berta I. Z. Vajda I. (2003). Documents from malicious terminals. In SPIE Microtechnologies for the New Millenium, 2003.

[6] Buccafurri F. Lax G. (2007). Hardening digital signatures against untrusted signature software. In Proceedings of the 2nd IEEE International Conference on Digital Information Management (ICDIM'07), p. 159-164, 2007.

[7] Burrows M., Abadi M., Needham R. (1989). A logic of authentication, from proceedings of the royal society 426 (1871), 1989. In William Stallings, Practical Cryptography for Data Intemetworks, IEEE Computer Society Press, 1996.

[8] Clarke D., Gassend B., Kotwal T., Burnside M., Van Dijk M., Devadas S., Rivest R. (2002). The untrusted computer problem and camera-based authentication. In Proceedings of the First International Conference on Pervasive Computing, volume 2414 of Lecture Notes in Computer Science, p. 114124. Springer- Verlag, 2002.

[9] Cramer R, Victor Shoup V. (1999). Signature schemes based on the strong rsa assumption. In CCS '99: Proceedings of the 6th ACM conference on Computer and communications security, p. 46-51, New York, NY, USA, 1999. ACM Press.

[10] Deville D., Galland A., Grimaud G., Jean S. (2003). Smart card operating systems: Past, present, and future. In Proceedings of the fifth NORDUIUSENIX Conference, 2003.

[11] Dobbertin H., BosselaersA., Preneel B. (1996). RIPEMD160: A strengthened version of RIPEMD. In Fast Software Encryption, p. 71-82, 1996.

[12] EU Journal (1999). EU Directive 1999/93 of the european parliament. Official journal of the european communities, december 13th 1999.

[13] Tygar J. D., Gobioff H. Yee B. (1996). Smart cards in hostile environments. In Proceedings of the 2nd USENIX Workshop on Electronic Commerce, p. 23-28,1996.

[14] Hopper N. J, Blum M. (2000). A secure human-computer authentication scheme, 2000. http://citeseer.ist.psu.edu/article/hopper00secure.html.

[15] ISO 7816-4(1995) ISO 7816-4, Identification Cards, Integrated Circuit(s) Cards with Contacts, Part 4. Int'I Standards Org., 1995.

[16] ITSEC (1991). Information technology security evaluation criteria (ITSEC): Preliminary harmonised criteria. June 1991. Document COM(90) 314, Version 1.2. Commission of the European Communities.

[17] JCDK (2008) Java Card Development Kit for the Java Card. http://java.sun.com/products/javacard/dev kit.html.

[18] Java Compiler (2008). http://java.sun.com/.

[19] Kaliski B. S. (1993) An overview of the PKCS standards. Technical report, 1993, http://citeseer.ist.psu.edu/kaliski91 overview.html.

[20] Lee B, Kim K. (2002). Fair exchange of digital signatures using conditional signature. In Symposium on Cryptography and Information Security, 2002.

[21] Matsumoto T. (1996). Human-computer cryptography: An attempt. I n A CM Conference on Computerand Communications Security, p. 68-75,1996.

[22] Mehta N. V, Sollins K. R. (1998). Expanding and extending the security features of Java. In 7th Usenix Security Symposium, p. 159-172,1998.

[23] MULTOS (2008). The High Security Smart Card OS. http://www.multos.com.

[24] Naor M, Pinkas B. (1997). Visual authentication and identification. Lecture Notes in Computer Science, 1294, 322-333,1997.

[25] Naor M, Shamir A. (1995). Visual cryptography. Lecture Notes in Computer Science, 950, 1-12,1995.

[26] Secure Hash Standard (2002). NIST/NSA, Fips 180-2 secure hash standard (SHS). NIST/NSA, aug 2002.

[27] Polk W., Housely R., Ford W, Solo D. (1999). Internet X.509 Public Key Infrastructure, IETF RFC 2459, Jan. 1999.

[28] Rivest R. L., Shamir A, Adleman L. (1978). A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM, 21(2)120-126,1978.

[29] Rivest R. L. (2001). Issues in cryptography. In Computers, Freedom, and Privacy Conference, 2001.

[30] Schneier B. (1999). The solitaire encryption algorithm, 1999. http://www.counterpane.com/solitaire.htm.

[31] Schneier B, ShostackA. (1999). Breaking up is hard to do: Modelling security threats for smartcards. In Proc. USENIX Workshop Smart Card Technology, 1999.

[32] Stabell-Kulo T., Arild R, Myrvang P. (1999). Providing authentication to messages signed with a smart card in hostile environments. In Proceedings of the USENIX Workshop on Smartcard Technology, 1999.

[33] Yee B, Tygar J. D. (1995). Secure coprocessors in electronic commerce applications. In Proceedings of the first USENIX Workshop on Electronic Commerce, p. 155-170, 1995.

Author Biographies: Francesco Buccafurri is a full professor of computer science at the University "Mediterranea" of Reggio Calabria, Italy. In 1995 he took the PhD degree in computer science at the University of Calabria. In 1995 he was visiting researcher at the Information System Department of the Vienna University of Technology, Austria, where he joined the data base and AI group. His research interests include deductive-databases, knowledge-representation and nonmonotonic reasoning, model checking, information security, data compression, histograms, data streams, agents, P2P systems. He has published several papers in top-level international journals and conference proceedings. He served as a referee for international journals and he was member of conference PCs.

Gianluca Lax is an assistant professor of computer science at the University "Mediterranea" of Reggio Calabria, Italy. In 2005 he took the PhD degree in computer science at the University of Calabria. His research interests include Data Warehousing and OLAP, data streams, P2P Systems, E-Commerce, and digital signature. He is also author of papers published in top-level international journals and international conference proceedings as well as chapters of books.

Francesco Buccafurri *, Gianluca Lax

DIMET Dept., Faculty of Engineering, University of Reggio Calabria, Loc. Feo di Vito, 89122 Reggio Calabria, Italy (bucca, lax) @unirc.it

* Corresponding author

[section] A shorter abridged version of this paper appeared in Proceedings of the second IEEE International Conference on Digital Information Management (ICDIM 2007) (Buccafurri and Lax, 2007).
Table 1. FHC and SHC robustness

Attack SSA JSA WCA SCA UIA

Modality G A G A G A G A G A
FHC C C M F M F M F M F
SHC C C C C C C M F M F

Table 2. Comparison of existing techniques.

 A B C D This paper

Additional Hardware Yes No No No No
Third Party No Yes No Yes No
User Load High Low High Medium Low
Impact on Law No No No Yes No

Legend

 Techniques

A Abadi et al. (1993, 1991); Clarke et al. (2002)
B Stabell-Kulo et al. (1999)
C Naor and Shamir (1995); Matsumoto (1996)
 Naor and Pinkas (1997); Ateniese et al. (1996)
D Berta et al. (2004, 2003)
COPYRIGHT 2009 Digital Information Research Foundation
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2009 Gale, Cengage Learning. All rights reserved.

 
Article Details
Printer friendly Cite/link Email Feedback
Author:Buccafurri, Francesco; Lax, Gianluca
Publication:Journal of Digital Information Management
Article Type:Report
Date:Apr 1, 2009
Words:8121
Previous Article:Biorthogonal matrix dirty paper Coding for information hiding in still images.
Next Article:Distributed Web 2.0 crawling for ontology evolution.
Topics:

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters