Posts Tagged ‘asymmetric cipher

Checking and Signing XML Documents on Java Smart Cards

Smart card assistance for generating digital signatures is current state of the art and best practice. This is mainly due to the fact that smart cards now a days have enough processing power to produce digital signatures for documents by on card resources (processor and memory) only. This way the owner’s private signing key never has to leave the smart card: The signing key is and remains permanently stored in a tamper proof environment. A closer look at the signing process however reveals a still existing major security problem: the problem known as the “what you see is what you sign” problem. Before signing a document the signer usually wants to check the document’s syntactic and semantic correctness.

When compared to the traditional process of signing a paper document with a hand written signature, the difference can easily be identified: In the traditional case, it is relatively easy for the user to assert the correctness, because syntactic and semantic document checking and signature generation are in immediate context. Digitally signing an electronic document is completely different, because checking and signature generation are executed in two different environments, exposing fundamentally different characteristics different with respect to security on the one hand and processor, memory, and display resources on the other hand.

Traditionally, the signing application computes the document’s digest using a one way hash function and sends the result to the smart card. The card encrypts the digest by an asymmetric cipher using the signing key stored on the card. The resulting value is the digital signature of the document. It is sent back to the signing application. The user can neither check the syntactic correctness of the document (in case of XML documents: well formedness, validity) nor the semantic correctness of the document. What really is signed is beyond the user’s control. It might for instance be the digest for a manipulated document. Even if the smart card can be regarded as tamper proof, the terminal (e.g. a PC) and the programs running on it are vulnerable to viruses and Trojan horses. Such evildoers might obviously also affect signing applications and let them produce valid signatures for from the user’s perspective invalid documents. Such incidents invalidate the signing process in total.

We propose an enhanced architecture which performs checking and signing of XML documents on Java smart cards, called JXCS architecture. The basic idea of JXCS is to shift the syntactic validation and hash value generation from the vulnerable PC to the trusted smart card. Syntactic validation imposes the following challenges and opportunities: Challenging is the need of processing XML documents on resource constraint Java smart cards. The opportunity of the approach is the possibility to perform syntactic and even semantic checks on the XML document in a tamper proof environment which improves the security of the signing process.
We propose the need for three major checks on the XML documents to be signed: Well formedness, validity and content acknowledgement using a class 3 card reader. Taken together all three checks can defeat “what you see is what you sign” attacks.

Tags : , , , , , , , , , ,

Execute-Only Memory (XOM)

The XOM approach, which provides memory protection, is based on a complex key management. The main XOM features are: data ciphering, data hashing, data partitioning, interruption and context switching protection. Figure 1.0 and 1.1 give an overview of the XOM architecture and mechanisms. All the security primitives are included in the trusted zone. The only security information which are not in the trusted zone are the session keys. That is why XOM owns a complex key management to guarantee a secure architecture.

Figure 1.0: XOM architecture for write request

Figure 1.1: XOM architecture for read request

In order to guarantee the data confidentiality and integrity, each memory partitionis associated with a session key which is needed to decrypt its content. Encrypted session keys are stored in main memory and can be decrypted using an asymmetric cipher algorithm (RSA in XOM case). Decrypted session keys are stored in the XOM key table (in the secure zone). The private key required for the asymmetric decryption is stored in the secure zone of the architecture (RSA key in Figures 1.0 & 1.1). The algorithm used for the symmetric deciphering is an AES 256 (256 bits key and 256 bits data input). For write requests, a hash value of the data and its address are concatenated with the data before ciphering with AES. The use of the address in the hash value is there to prevent the relocation attacks. When the core produces a cache miss for a read request, the 256 bits read from the memory need to be decrypted (Figure 1.1). Data integrity is ensured by a hash value relying on a MD5 computation. The hash of the deciphered data and its address are compared with deciphered hash value. If the new computed hash value matches with the deciphered one the data is considered secure and can be used by the processor.

In addition, the data stored in cache memory are associated with an identifier or tag in order to guarantee the data partitioning at a cache level. When a task needs to usea data, the task identifier must be the same as the data, in that case it means the task is allowed to access the data. The tag value are provided by the XOM key table which also manages this part.

All the protections added by this solution have a cost. The first one concerns the XOM implementation in an existing OS. A work is necessary on the OS kernel to add the instructions which help for the hardware security primitives use. All this work is transparent for the kernel user. According to the figures from, a real overhead appears in the cache management (cache miss raises from 10 to 40% depending on the application). This raise is mainly due to the information added into the cache to secure the data. Indeed, by adding some data tagging, some space in the cache memory is lost compared with a non protected solution. Moreover, all the security features are bringing some latency in the system to obtain the data in clear (data de/ciphering, hashing, tag checking). Even if these security primitives are done in hardware, the general architecture performances are slowed down. The decryption needs to be done before the integrity checking. These two operations are not done in parallel, so some more latency is added. Some latency is also added to the software execution because of some software security primitive (secure context switching add some specific instruction for example).

The first proposed version of XOM is known to have security holes like noprotection against replay attacks. In, the authors extended the proposition and replaced the AES-based ciphering scheme with a system based on OTP to guarantee protection against replay attacks and also to increase the performances of the system. Concerning the global security level of the XOM architecture, the attack possibilities are fully dependent on the integrity checking capabilities. To succeed, the attacker mustbe able to pass through the integrity checking in order to execute his own program or use his own data. He may exploit some collisions in the hash algorithm used. For example, with MD5 the signature is 128 bits long. If he wishes to attack the system, he needs to find two inputs which will produce the same result with MD5.

Tags : , , , , , , , , , , , , , ,