action coopérative java card 6/28/2015 bull & innovatron patents 1 smart card modeling gemplus...

Action Coopérative Java Card04/18/23Bull & Innovatron Patents

1

Smart Card ModelingSmart Card ModelingGemplus Research LabGemplus Research Lab

Saint Malo, 8-9 July [email protected]


2

OutlineOutline

Motivations The B Method Java Card Mechanisms:

Verifier Interpreter Firewall

Conclusions


3

MotivationsMotivations

Applications are developed by the card provider in a secure environment,

Drawbacks: time consuming costly

Operating System + Application

Chip

Responses Commands


4

Applications developed by the customer or any application provider,

Operating System

Chip

Data

Instructions

Downloadable applications

Dynamically downloaded through a network

Responses Commands

Secure Virtual Machine

Open cards...Open cards...


5

The Java Card specification provides a mechanism to share data between several applets, For example: a purse and a loyalty applet can share

methods and/or objects, Due to the limited resources of the smart cards new

services or libraries will be offered.

A share with B a methodA share with B a method B share with C a methodB share with C a method

JCREJCREApplet Provider CApplet Provider C

Hostile AppletHostile Applet

BufferBuffer

Log.getTransactionLog.getTransaction

Purse AppletPurse Applet

LogLog

Applet Provider AApplet Provider A

Buffer.reSellBuffer.reSell

Loyalty AppletLoyalty Applet

BufferBuffer

Applet Provider BApplet Provider B

...and the sharing mechanism...and the sharing mechanism


6

New security problemsNew security problems

Applications are no more developed under card issuer control, Naïve implementation can ease DPA attacks, Any application provider can introduce a Trojan

Horse in the card, New attacks can arise (denial of services…),

Information can be exchanged between application, Use faulty platform implementation


7

Java Card Security ChainJava Card Security Chain

Java

Car

d

PlatformSecurity

OS

Chip

JC API

JVM

LoaderLinker

Applet Security Policy

Sign/Enc

Verifier

Loader

Vir

tual

Mac

hin

e

App

let

App

let

App

let

.java .class .cap

OP

CM

AppletApplet Applet


8

Two security levelsTwo security levels

Platform security Traditional means, Use of formal methods.

=> Models of the platform security modules Application security

There is a need for a global security policy Flow control (data and/or code sharing) Resources consumption (memory, CPU, method

calls...)

=> Static analysis of applet configurations (part of the CMS)


9

Smart Card ModelingSmart Card Modeling

B Method

Verifier

Interpreter

Firewall


10

The B methodThe B method

A formal Method Based on the mathematical set theory (variables,

sets, relations, etc..), Generation of proof obligations, Theorem prover

Supported by CASE tools (AtelierB, B Toolkit..) Used in industrial applications (RATP Meteor

automatic subway, SNCF TGV Speed train control


11

The B Method - MachineThe B Method - Machine

MACHINE EX_1

VARIABLESx, y, z

INVARIANTSx 0..10 y 0..10 z 0..20

INITIALISATIONx : 0..10 y : 0..10 z : 0..20

OPERATIONOP1 =BEGIN

z := x+yEND

END

GENERATIONOF PROOF

OBLIGATIONS


12

The B Method - Proof ObligationThe B Method - Proof ObligationH1 H2

..

Hn B

INVARIANTS

x 0..10 y 0..10 z 0..20

OPERATION

OP1 =

BEGIN

z := x+ y

END

x 0..10

y 0..10

z 0..20

x+ y 0..20

Generation of a Proof Obligation

EXAMPLE


13

The B Method - RefinementThe B Method - Refinement

ABSTRACTM ACHINE

REFINEM ENT 1

REFINEM ENTn-1

REFINEM ENT n

IM PLEM EN T AT IO N

PROO FOBLIGATIONS

PROO FOBLIGATIONS

PROO FOBLIGATIONS

PROO FOBLIGATIONS

C soure code orADA source code

PROO FOBLIGATION

PROO FOBLIGATION

PROO FOBLIGATION

PROO FOBLIGATION

PROO FOBLIGATION


14


B Method

Verifier

Interpreter

Firewall


15

The Byte Code VerifierThe Byte Code Verifier

The Java byte code is compiled for the Java Virtual Machine.

The Java byte code may be corrupted intentionally or not.

Need to perform checks before its execution by the interpreter: Flow controls Type correctness


16

Flow Control and Flow Control and Type CorrectnessType Correctness

A state is defined by: The pc (program counter) The type stack The type frame

The properties to be checked are Confinement Stack access Initialization Type correctness


17

Our Approach of the ModelOur Approach of the Model

Model a Defensive Machine.

Extract runtime checks by successive refinements.

De-synchronize verification and execution process.

Split the defensive machine in two parts: The verifier The interpreter


18

The ModelThe Model

Machine

DJVM

Refinement 1

DJVMr1

Refinement 2

DJVMr2

Machine

Treechecking

Machine

Interpreter

Implementation

BCV

Machine

Operation

Refinement

Operationr

Implementation

iDJVM

Implementation

Verifier

The Byte Code Verifier The Defensive Machine The Interpreter


19

The Defensive MachineThe Defensive Machine

Performing tests on byte code and then executing it.

ins_push0 = SELECT(methode(apc)=push0)

THEN

IF (apc < size (methode) top_stack < max_stack)

THEN

apc := apc + 1

|| top_stack := top_stack +1

|| types_stacks := types_stacks{top_stack+1 INTEGERS}

ELSE

unchecked:=TRUE

END

END;

No need to perform test on byte code, just executing it.

ins_push0 =

SELECT(methode (apc) = push0 unchecked = FALSE)

THEN

apc := apc + 1

|| top_stack := top_stack +1

|| types_stacks:= types_stacks{top_stack+1INTEGERS}

END;


20

The Freund & Mitchell The Freund & Mitchell Bytecode InstructionsBytecode Instructions

A subset of the Java bytecode language: Inc, Push0, Pop, If L, Istore x, Iload x, Halt, New, Init, Use.

A static semantics and an operational semantics.

A subset sufficient to study object initialization, flow and data-flow controls.


21

Construction of static stacksConstruction of static stacks

The equation to be verified :

pc, type_stack[pc] = { fi(type_stack[i] / i belongs to Preds(pc)},

A fixed point search for each static stack.


22

TypesTypes

The types subset:

The lattice A partial-order A binary operator Meet

TOP

Integers Addri

Addr

Bottom

Bottom


23

ConclusionConclusion

The defensive machine is entirely proved

The integration of the fixed point calculus is proved at 98%.

We proved the soundness of our approach.


24


B Method

Verifier

Interpreter

Firewall


25

Java Card Entire SubsetJava Card Entire Subset

Not taken into account Constant Pool Subroutines verification Exception Heap

Instructions specification according to their properties: Ease the specification Ease the proof (cf. A. Requet)


26

Byte Code PropertiesByte Code Properties

Byte code accessing : The stack (bspush) The frame (sload_0) The program counter (if_scmp_gt, bspush).

OPCODE

OP_PC_NEXT

OP_SINGLE_BRANCH_W

sload_0bspushiconst_1iconst_m1

if_scmp_gtireturn

OP_SINGLE_BRANCH


27

RefinementsRefinements

Machine

DJVM

Refinement 1

Refinement 2Machine

Treechecking

Machine

InterpreterImplementationThe Byte Code

Verifier The Defensive Machine The Interpreter

Refinement 3

Refinement 4

Properties

Method

Control Flow

Frame

Stack


28

RefinementsRefinements

DEFINITIONS succ_pc(x) == x + 1 + parameters_size(BYTE_to_OPCODE(method(x)) ; parameter(x, y) = method(x+y) OPERATIONS op_sinc = SELECT BYTE_to_OPCODE(method(pc)) = IINC_W THEN IF BYTE_to_unsigned(parameter(pc, 1)) 0..max_locals-1

frame_type(BYTE_to_unsigned(parameter(pc, 1))) = int

succ_pc(pc) opcode_locations THEN pc := succ_pc(pc) END END

flow_checked = TRUE => (¡x.(x dom(method) ¾ BYTE_to_OPCODE(method(x)) OP_NEXT) =>x+1+parameters_size(BYTE_to_OPCODE(method(x))) opcode_locations))

(¡x.(x dom(method) ¾ BYTE_to_OPCODE(method(x)) OP_SINGLE) =>x + 1 + BYTE_to_signed(parameter(x,1)) £ opcode_locations)) (¡x.(x dom(method) ¾ BYTE_to_OPCODE(method(x)) OP_SINGLE_W) =>x + 1 + BYTE_to_signed(parameter(x,1), parameter(x,2)) opcode_locations))


29

RefinementsRefinements op_sinc = SELECT frame_checked = TRUE

stack_checked = TRUE flow_checked = TRUE THEN pc := succ_pc(pc) END

frame_value 0..max_locals-1 INT

/* Gluing invariant */dom(frame_type) dom(frame_value)

op_sinc = SELECT frame_checked = TRUE

stack_checked = TRUE flow_checked = TRUE THEN VAR oldfvalue, newfvalue IN oldfvalue := frame_value(parameter(1)) ; newfvalue jah_sadd(oldfvalue, parameter(2)) ; frame_value(parameter(1)) := newfvalue END ; pc := pc + 3 END


30

StatusStatus

All the byte codes are specified

Proof of the properties per byte code sets is possible

Proof Obligation resolution is difficult BUT generic

100% proved until refinement 3


31


B Method

Verifier

Interpreter

Firewall


32

Object SharingObject Sharing

JCREJCRE

JCREJCREEntryEntryPointPoint

ObjectsObjects

FIREWALLFIREWALLFIREWALLFIREWALL

GlobalGlobalArraysArrays

LoyaltyLoyalty

Package YPackage Y

KernelKernel

Package XPackage X

xxextendsextends

ShareableShareable

Applet xApplet x

Applet yApplet y


33

Firewall ModelFirewall Model

Abstract Machine

Concrete Variables

Invariant

Operations

JCRE Specification

Sun.

JavaCardAPI

Sun.

VOP

Visa.

Security PolicyJCRE / Firewall

Byte Code Interpretation

Implementation


34

Security properties : the memory access must conform the security policy: context management objects management (applet, arrays, interfaces…) byte code interpretation

Firewall SpecificationFirewall Specification

Objects

Java Stack

JCRE

Interpreter

Firewall


35

Byte Code InterpretationByte Code Interpretation

Methods access invoke_interface, invoke_static, invoke_virtual

Array access aaload, iaload, baload, …

Context_switch invoke_interface


36

ComponentsComponents


37

Interpreter and FirewallInterpreter and Firewall

Abstract Machine InterpreterSees ContextsConcrete Variables InterpStatus, pcAbstract Variables Current_obj, Current_ctxOperations Treat_bytecode = PRE InterpStatus = OK THEN CHOICE

pc := PC_NEXT (pc) OR

InterpStatus :: STATUS - {OK} END END

Firewall

AccessArray(obj,array) = PRE FireStatus = OK THEN IF

(obj | array) :Access_array THEN

FireStatus := access_denied END END

FireStatus

aaload

Current_objref_array

OKAccess_Denied

Stack


38

Firewall RefinementFirewall Refinement

Specification : ” The acces to an array is allowed if current object is element of the JCRE, or array is global, or array is not a transient clear_on_deselect, and is element

of the current package”

Access_Array = Access_JCRE

Access_global

{Access_Package-Access_Transient_COD}

Access_JCRE : {ObjectContext~ (JCREContext)} ObjectsOnCard

Access_Globals : ObjectsOnCard GlobalArrays

Access_Package : {ObjectContext ; ObjectContext~}

Access_Transients : ObjectsOnCard Transients_COD


39

Firewall ImplementationFirewall Implementation

Access_Array implementation

IF

{curr_obj | array_ref} : Access_JCRE Access_global

{Access_Package-Access_Transient_COD}

IF

ObjectContext (curr_obj) = JCREContext

OR is_global_array (array_ref) = TRUE

OR (same_package (curr_obj, array_ref) = TRUE

and not (is_transient_cod(array) = TRUE))


40


The Firewall is integrated is the virtual machine.

100% proof of the model until the implementation

Optimisation are mandatory on the additional test

Help to understand the relation between the JCRE, the Firewall and the interpreter.


41


B Method

Verifier

Interpreter

Firewall

Conclusion


42


We specified and/or implemented a large part of the virtual machine: the verifier (spec only) the interpreter the firewall the JCRE

The implementations do not fit with smart card constraints

Specification of the VOP module The complete interpreter (sub routine, exception…)


43

PublicationsPublications

Using B Method to Model Protocols by J.-L. Lanet. In Proceeding of the Workshop AFADL 98, Poitiers, Oct. 1998.

Formal Proof of Smart Card Applets Correctness by J.-L. Lanet and A. Requet. In Proceedings of the Third Smart Card Research and Advanced Application Conference (CARDIS'98), Louvain-la-Neuve, Belgium, Sept. 1998.

The use of the B formal method for the design and the validation of the transaction mechanism for smart card application by P. Lartigue and D. Sabatier, FM'99, Toulouse sept. 99

Formal Specification of the Java Bytecode Semantics using the B method, by L. Casset, J.-L. Lanet, ECOOP workshop, Lisbon, Jun. 99

Formal Specification of the Java Byte Code Semantics Coherence for an Embedded System, by L. Casset, J-L. Lanet and G. Mornet, submitted to ASIAN’99, Phuket Dec. 99

Formal Model of the Firewall, by S. Motre, submitted to AFADL 2000, Grenoble, Fev. 00

action coopérative java card 6/28/2015 bull & innovatron patents 1 smart card modeling gemplus...

Documents

action cooprative java

card provider

bull innovatron patents

applet slide

nthe java card specification

card issuer control

b method machine slide

method b share