LR00form - Formal Proof of Smart Card Applets Correctness...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Formal Proof of Smart Card Applets Correctness Jean-Louis Lanet 1 and Antoine Requet ² 1 Gemplus Research Group, Av du Pic de Bertagne, 13881 Gémenos Cedex France tel : +33 (0)4 42 36 64 22 - fax : +33 (0)4 42 36 55 55 [email protected] 2 IRIN 3, rue du Maréchal Joffre, BP 34103; 44041 Nantes Cedex 1 [email protected] Abstract : The new Gemplus smart card is based on the Java technology, embedding a virtual machine. The security policy uses mechanisms that are based on Java properties. This language provides segregation between applets. But due to the smart card constraints a byte code verifier can not be embedded. Moreover, in order to maximise the number of applets the byte code must be optimised. The security properties must be guaranteed despite of these optimisations. For this purpose, we propose an original manner to prove the equivalence between the interpreter of the JVM and our Java Card interpreter. It is based on the refinement and proof process of the B formal method. Key Words : Java byte code, security, optimisation, formal specification. 1. Introduction The use of Java for the next generation of smart cards offers the possibility to download executable code. This possibility increases the flexibility to update the contents of a smart card, but raises a risk of loading a hostile applet. Such an applet could access or modify part of the system. In order to ensure a safe execution, several conditions must be verified on the execution environment. Applet properties must be conscientiously checked. Security in a smart card has several aspects. As applets often need to exchange information, some mechanism must be set up in order to avoid unauthorised information flow. Those mechanisms can be implemented within hardware devices (MMU) or in software. Java and its virtual machine provide by themself several properties that can ease the implementation of such a mechanisms. For example, the lack of pointer arithmetic associated with a strong check on the typing prevents an applet from forging an address and from scanning the memory space of the smart card bypassing the execution mechanisms. Such properties are enforced by a byte code verifier. However, due to the size and performance limitation of smart cards, such a verifier cannot be embedded in the card. Alternative ways of ensuring that the executed byte code is valid must be used. A pragmatic approach is to use an off-line verifier, and to digitally sign verified applets. This approach has several advantages,
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
for example, it only requires cryptographic mechanisms to be implemented within the card. Another security aspect is linked to the modification of the Java virtual machine to better suit the smart card constraints. This optimisation allows to reduce the Java byte code size in order to load more applets into the smart card. So, it is necessary to ensure that those optimisations do not weaken the type system, and do not introduce security holes. This is all the more difficult, as it is not possible to use
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/02/2011 for the course SECURITY 2354 taught by Professor Morganjones during the Spring '11 term at Ucla Venezuela.

Page1 / 14

LR00form - Formal Proof of Smart Card Applets Correctness...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online