Formal Development of a Verifier

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

3
Agenda

• Bytecode Verification issues
• Modelling a bytecode verifier
• Conclusions
• Demo

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

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

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
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
8
PCC The Proof Carrying Code Approach
Additional information containing unification
results on program types
9
Verification Scheme
Proof Generation (PCC)
Code to Verify
Embedded Classical Verifier
Algorithm Complexity
Lightweight Verification
Information Needs
Memory Consumption (EEPROM)
Code Verified
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
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
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

13
Agenda

• Bytecode Verification issues
• Modelling a bytecode verifier
• Conclusions
• Demo

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

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
Memory management
CAP file storage on-card
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

17
Type Verifier (Cont.)

• Concrete model
• Refines the abstract model
• Uses services provided by the interface
• Provides a proved implementation

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

19
(No Transcript)
20
(No Transcript)
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

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)

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

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)

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

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

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

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

29
Agenda

• Bytecode Verification issues
• Modelling a bytecode verifier
• Conclusions
• Demo

30
Comparing the byte code verifier development
metrics with Météor

• Byte code Verifier
• (not yet achieved)
• 58 500 lines of B
• 30 810 POs generated
• Automatically proved 74
• Atelier B 3.6 PR 22

• Météor (achieved)
• Météor A Successful Application of B in a Large
  Project FM99
• 115 000 lines of B
• 27 800 POs generated
• Automatically proved 81
• Atelier B 3.3 (customised)

31
Type Verifier Metrics

• Comparison between classical development and
  formal development
• Based on the type verifier development

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

33
Agenda

• Bytecode Verification issues
• Modelling a bytecode verifier
• Conclusions
• Demo

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

35
Formal Development of a Verifier

• lilian.burdy_at_gemplus.com
• ludovic.casset_at_gemplus.com
• antoine.requet_at_gemplus.com