1 / 35

Formal Development of a Verifier

Formal Development of a Verifier. Lilian Burdy Gemplus Research Lab 28th February 2002. Agenda. Bytecode Verification issues Modelling a bytecode verifier Conclusions Demo. Agenda. Bytecode Verification issues Modelling a bytecode verifier Conclusions Demo.

abrittney
Download Presentation

Formal Development of a Verifier

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formal Development of a Verifier Lilian Burdy Gemplus Research Lab 28th February 2002

  2. Agenda • Bytecode Verification issues • Modelling a bytecode verifier • Conclusions • Demo Title

  3. Agenda • Bytecode Verification issues • Modelling a bytecode verifier • Conclusions • Demo Title

  4. The Java Byte Code Verifier • No violations of memory management • No stack underflows or overflows • Access restrictions are enforced • Methods are called with appropriate arguments of appropriate type • Fields are modified with value of appropriate type • No forged pointers • No illegal data conversions Title

  5. The Java Card Byte Code Verifier Restriction • No unsupported data types • No char, long, double, float • The type int is used only if the JC interpreters supports it • No unsupported Java language features • No threads or multidimensional arrays • Usage of certain Java operation within limited ranges Title

  6. Verification Scheme Code to Verify Embedded Classical Verifier Complexity of the Verification Algorithm Need of Typing Information Complexity in Memory Consumption (ROM, RAM, EEPROM) Code Verified Title

  7. PCC: The Proof Carrying Code Approach Finding solution to a problem is time and resource consuming But, checking that a solution fits the corresponding problem is much more easier Title

  8. The program to verify PCC: The Proof Carrying Code Approach Additional information containing unification results on program types Title

  9. Verification Scheme Proof Generation (PCC) Code to Verify Embedded Classical Verifier Algorithm Complexity Lightweight Verification Information Needs Memory Consumption (EEPROM) Code Verified Title

  10. An Example public class AnExample { public static boolean b; public static void main(String [] argv) { if(b) { int i = 1; } else { Object tmp = new Object(); } int j = 2; } } Title

  11. An Example (Cont) Local Variables String [] String [] String [] String [] int String [] String [] String [] String [] int/\Obj = Top Top int Stack - Bool - int - - UObj UObj UObj Obj - int - Proof - - - - - String[] - - - Top - - .limit stack 2 .limit locals 1 getstatic b ifeq Label1 iconst_1 istore_0 goto Label2 Label1: new java/lang/Object dup invokespecial astore_0 Label2: iconst_2 istore_0 return .end method Title

  12. PCC architecture • Off-card • A « proof » generator that computes additional information • Computation made from a CAP file • Performs type unification • Adds computed information to the code through a custom component • On-card • Structural verification of the CAP file format and contents • A linear typing verification of the code using additional information provided by the outside world • Remaining issues: size of the verifier and size of the additional information Title

  13. Agenda • Bytecode Verification issues • Modelling a bytecode verifier • Conclusions • Demo Title

  14. Architecture of the Verifier • Verifier divided into 3 parts • A structural verifier • Aims to ensure the CAP file format • Provides access to data • A type verifier • Relies on the structural verifier to access data • Ensures that the Java Card typing rules are enforced • Byte code verifier utilities • Provides access to memory • Several utilities shared by the byte code verifier Title

  15. Architecture of the Verifier Type Verifier Typing Rules of the 184 bytecodes Interface Abstract Model of the CAP file Properties and services Structural Verifier Model of the 12 components CAP file storage on-card Memory management Title

  16. Type Verifier • Abstract model • The higher specification returns a boolean • Defines the loop on all the methods • Then, for each method, defines a loop on all the bytecodes • Specifies the typing rules of the 184 different bytecodes • Relies on the interface and the properties describing the CAP file • Help defining the structural verifier Title

  17. Type Verifier (Cont.) • Concrete model • Refines the abstract model • Uses services provided by the interface • Provides a proved implementation Title

  18. Type Verifier: Metrics • Number of components : 34 (including mch, ref and imp) • Number of lines of B: around 20 000 • Number of generated lemmas: around 18 160 POs • Number of unproved lemmas: • automatically proved : 70 % • current project status: • unproved lemma : 125 • percentage proved : 99% • Work Load : 5 mm Title

  19. Title

  20. Title

  21. Structural Verifier • Implements the interface • Specifies internal and external tests • the interface is not sufficient to define the structural verifier • it contains only properties related to the type verifier, not to the byte code interpreter • This verifier relies on the model of the 12 components contained within the CAP file • 11 standard components • 1 custom component Title

  22. Structural Verifier • Internal verifications • Each component is modelled and checked • Provide access to information • Close to the hardware (memory representation) • Not hard to specify, but hard to implement • Proof hard to handle • Bugs are not easily detected by the proof • bugs related with wrong offset when accessing data • tests not implemented (specification issues) • Same result obtained with basic machines (see Class and Descriptor) Title

  23. Structural Verifier (Cont.) • External verifications • Rely on services and properties of internal verifications • Easier to specify and to implement • Proof is also made easier thanks to properties provided by imported machines (internal verifications) • Bugs that are found thanks to the proof • incoherence between components • wrong specification of components • properties missing • services missing Title

  24. Structural Verifier: Metrics • Number of components : 116 (including mch, ref and imp) • Number of lines of B: around 35 000 • Number of generated lemmas: around 11 700 POs • Work Load: 8 mm • Basic Machines: 6 (including the class and the descriptor) Title

  25. Bytecode Verifier Utilities • Contains services shared by the type verifier and the structural verifier • RAM representation • Context machines • Close to the hardware • Use of basic machines Title

  26. Bytecode Verifier Utilities : Metrics • Number of components : 45 (including mch, ref and imp) • Number of lines of B: around 3 500 • Number of generated lemmas: Around 910 POs • Work load: 4 mm • Basic Machines: 7 Title

  27. Bytecode Verifier Integration • Not all implementations performed in B • Use of Basic Machines • File loading and linking • Need to represent • the card memory • packages already present in the card • Work Load: 3 mm Title

  28. C Code Translator • Developed within the G+ Lab • Straight forward conversion into C code • No optimisation • In-lining possible • Use only information available in the converted file • needs to add explicit typing information in the implementation • use typing information to distinguish byte from short and int • No try with the ClearSY C code translator Title

  29. Agenda • Bytecode Verification issues • Modelling a bytecode verifier • Conclusions • Demo Title

  30. Comparing the byte code verifier development metrics with Météor Météor (achieved) Météor: A Successful Application of B in a Large Project FM’99 • 115 000 lines of B • 27 800 POs generated • Automatically proved: 81 % • Atelier B 3.3 (customised) Byte code Verifier (not yet achieved) • 58 500 lines of B • 30 810 POs generated • Automatically proved: 74 % • Atelier B 3.6 PR 22 Title

  31. Type Verifier Metrics • Comparison between “classical” development and formal development • Based on the type verifier development Title

  32. Benefits from using Formal Methods • Provides a complete and unambiguous specification of the byte code verifier • modelling activities help clarify the informal specification • Provides a reference implementation of an on-card byte code verifier • a trusted implementation that conforms to its specification • Provides elements for high level certification • the formal model of the byte code verifier is available Title

  33. Agenda • Bytecode Verification issues • Modelling a bytecode verifier • Conclusions • Demo Title

  34. Demo of the byte code verifier • Demo made on an ATMEL AT90 SC 6464 • The byte code verifier characteristics • Type verifier • complete excepted the jsr and the ret instructions • Structural verifier • most of external tests • internal tests on descriptor components and proof components not complete • Size of the code: 45 kb Title

  35. Formal Development of a Verifier lilian.burdy@gemplus.com ludovic.casset@gemplus.com antoine.requet@gemplus.com

More Related