Smart Cards and Java Card
Total Page:16
File Type:pdf, Size:1020Kb
Outline Background: JavaCard Program Verification • Smart cards and JavaCard Erik Poll LOOP project at Nijmegen: verification of JML-annotated JavaCard programs in PVS University of Nijmegen • a semantics of Java • JML specification language for Java Joint work with • a logic for JML Joachim van den Berg, Cees-Bart Breunesse, Engelbert Hubbers, Bart Jacobs, Hans Meijer, Martijn Oostdijk • JML specifications for the JavaCard API JavaCard Program Verification – p.1/61 JavaCard Program Verification – p.2/61 smart cards Card with a chip providing CPU and memory (ROM, RAM, EEPROM) capable of • storing information (tamper resistant!) • processing information, notably en/de-cryption Smart Cards and Java Card NB private keys never have to leave the card ! Applications • Now: bank card, mobile phone SIM • Future: ID cards, access control for networks, PKI support, access control for networks, . JavaCard Program Verification – p.3/61 JavaCard Program Verification – p.4/61 Old vs new smart cards Java Card Traditional smart cards: Subset of Java for programming smart cards, • one program (or ‘applet’) • without threads, floats, . , very limited API • written in chip-specific machine code extended with • burnt into ROM • persistent and transient objects (EEPROM and RAM) New generation smart cards: • transaction mechanism and increased security: • several applets, written in high level language • standard sandbox + firewall between applets. • compiled to byte code • stored in EEPROM • executed on virtual machine and mini-OS, which hide hardware details JavaCard Program Verification – p.5/61 JavaCard Program Verification – p.6/61 Pros & cons Security issues for smart cards Advantages of new generation smart cards: Like a virus, a malicious applet could exploit weaknesses in • development quicker and cheaper platform or in other applets. • multi-application: several (possibly interacting) • Is (an implementation of) the platform secure ? applets on one smart card • Is a given applet secure/not malicious ? • post-issuance download: adding or deleting applets on a card (cf. downloading applets in web browser, but Increasing demands for security evaluation. controlled with digital signatures, using Visa OP) Common Criteria (CC), the ISO standard for security but additional security threats ! evaluation, distinguishes 7 levels. Current cards are evaluated up to levels 4+5. The highest levels (6+7) require formal verification. JavaCard Program Verification – p.7/61 JavaCard Program Verification – p.8/61 VerifiCard Project Formal methods for JavaCard • EU-sponsered IST-project of 2 smartcard producers and 5 academic research groups in tool-assisted JavaCard is an ideal target for use of formal methods: verification for Java(Card). • Work on • Programs involved are small • formal descriptions of platform (JCVM, byte code • Platform is relatively small and simple verifier) for CC evaluations • Correctness & security are of vital importance • applet verification • non-interference and information-flow properties • Cards are distributed in large numbers • case studies (banking, GSM) provided by industrial • Smart card industry is open to formal methods partners. Potential killer application for formal methods ? But if we can’t even do this . JavaCard Program Verification – p.9/61 JavaCard Program Verification – p.10/61 VerifiCard: Topics VerifiCard: other partners Academic: JavaCard platform applets INRIA Barthe, Bertot France TU Munich Nipkow Germany VM, bytecode Univ. Hagen Poetzsch-Heffter Germany byte abstract interpretation verifier, compiler SICS Dam Sweden code & model checking formalisation Industrial: Gemplus Lanet France API annotation in applet annotation in Schlumberger CP8 Goire France source JML & Hoare-style JML & Hoare-style code verification verification JavaCard Program Verification – p.11/61 JavaCard Program Verification – p.12/61 The LOOP Project Verification of JML-annotated Java(Card) programs based on • a denotational semantics for sequential Java, formalised in PVS The LOOP project • a compiler – the LOOP tool – which translates A.java to A.pvs describing its semantics. • a logic for reasoning about JML, formalised in PVS ie. a shallow embedding of Java and JML in PVS JavaCard Program Verification – p.13/61 JavaCard Program Verification – p.14/61 LOOP tool for Java/JML The LOOP Project: results so far JML-annotated Java class A.java • translation covers essentially all sequential Java • translation of JML under construction, but covers basics. LOOP compiler • case studies: • non-trivial invariant for Java’s Vector class • AID class from JavaCard API meaning of Java class [[A]].pvs with • Purse applet (under development) proof obligations as Hoare sentences • large collection of smaller test examples PVS theorem prover QED JavaCard Program Verification – p.15/61 JavaCard Program Verification – p.16/61 Rest of this talk • Semantics of Java • Java specification language JML • Hoare logic for Java/JML Semantics of Java • JML specifications of JavaCard API JavaCard Program Verification – p.17/61 JavaCard Program Verification – p.18/61 Java Semantics Example: Java control flow Standard denotational semantics of imperative program P : public int arrayProduct(int[] a) f [[ ]] / if (a == null) throw new MyNullPointerException(); S 1 + S if (a.length == 0) return 1; int prod = 1; where S is the state space and 1 = f?g stands for for (int i=0; i < a.length; i++)f nontermination. if (a[i]==0) fprod = 0; break;g ; But: Java has abrupt termination because of if (a[i]==1) continue; prod = prod * a[i]; • exceptions, throw(E) g; • return that exits a method return prod; • break that exits a repetition g • continue that skips remainder of a repetition so the semantics becomes more complicated . JavaCard Program Verification – p.19/61 JavaCard Program Verification – p.20/61 Java semantics: statements Example: composition Semantics of Java statement P : For two statements [[ ]] s1; s2 : S ! 1 + S + StatAbn S / 1 + S + StatAbn the composition is defined as where (s1 ; s2) · x = CASES s1 · x OF f StatAbn = (S × RefType) state with exception object hang 7−! hang +S return j norm(x ) 7−! s2 · x +(S × (1 + String)) break with label j abnorm(a) 7−! abnorm(a) g +(S × (1 + String)) continue with label In this way all Java constructs are translated into PVS. JavaCard Program Verification – p.21/61 JavaCard Program Verification – p.22/61 Java semantics : expressions Example: Addition Semantics of Java expression E e: For two int-expressions [[ ¡ ]] e1; e2 : S ! 1 + S × Int + ExprAbn S / 1 + S × E + ExprAbn addition is defined as (e1+e2) · x = where CASES e1 · x OF f ExprAbn S RefType state with exception object = ( × ) hang 7−! hang j norm(x ; val1) 7−! CASES e2 · x OF f hang 7−! hang j norm(x ; val2) 7−! norm(x ; val1 + val2) j abnorm(a ) 7−! abnorm(a ) g j abnorm(a) 7−! abnorm(a) g JavaCard Program Verification – p.23/61 JavaCard Program Verification – p.24/61 LOOP Java semantics LOOP tool for Java • representation of state space (or object model), Java class A.java mapping references to values • semantics of all Java statements constructs: ; LOOP compiler if (...) f...g else f...g try f...g catch ... finally f...g . • semantics of Java expression constructs: meaning of Java class PVS theories for object model and + , - , . , && , & , . , x = . , . + [[A]].pvs as PVS theory semantics of Java constructs • semantics of classes incl. inheritance: method tables of statements/expression-valued functions, generated by the LOOP tool Together covering essentially all of sequential Java PVS theorem prover JavaCard Program Verification – p.25/61 JavaCard Program Verification – p.26/61 Java Modeling Language JML Specification language by Gary Leavens (Iowa Univ.) for annotating Java programs with • pre- and postconditions cf. Eiffel and • invariants Design by Contract JML • frame conditions (modifiability constraints) • specification-only variables (model variables) • . Pre-, postconditions, and invariants in JML are Java boolean expressions, extended with \forall, \exists, ==>, \old( ), . JavaCard Program Verification – p.27/61 JavaCard Program Verification – p.28/61 JML example JML example class A f class A f int i; int i; //@ invariant 0 <= i && i <= MAX; public void change_i(int j) throws MyException public void change_i(int j) throws MyException f if (j == 0) return ; f if (j == 0) return ; if (i+j > MAX) throw new MyException(); if (i+j > MAX) throw new MyException(); i = i+j; i = i+j; g g JavaCard Program Verification – p.29/61 JavaCard Program Verification – p.30/61 JML example JML example class A f class A f int i; int i; //@ invariant 0 <= i && i <= MAX; //@ invariant 0 <= i && i <= MAX; public void change_i(int j) throws MyException public void change_i(int j) throws MyException /*@ requires j >= 0; /*@ requires j >= 0; ensures i = nold(i)+j; ensures i = nold(i)+j; signals (MyException) i+j > MAX; @*/ @*/ f if (j == 0) return ; f if (j == 0) return ; if (i+j > MAX) throw new MyException(); if (i+j > MAX) throw new MyException(); i = i+j; i = i+j; g g pre- and post-condition “exceptional” postcondition JavaCard Program Verification – p.31/61 JavaCard Program Verification – p.32/61 JML example JML example class A f class A f int i; int i; //@ invariant 0 <= i && i <= MAX; //@ invariant 0 <= i && i <= MAX; public void change_i(int j) throws MyException public void change_i(int j) throws MyException /*@ requires j >= 0; /*@ requires j >= 0; modifiable i; ensures i = nold(i)+j; ensures i = nold(i)+j; signals (MyException) i+j > MAX; signals (MyException) i+j > MAX; @*/ @*/ f if (j == 0) return ; f if