Formal specification of GlobalPlatform Card Security Requirements Date Author Status Keywords

15 December 2004 Santiago Zanella B´eguelin (Everest Project) Final GlobalPlatform, security, specification, formal model, formal methods, B Abstract

This report presents a formal specification of the security and functional requirements for GlobalPlatform cards as defined in [Glo01] and [Glo03]. The formalization is given using the notation of the B-method, which has already been applied in the SmartCard industry with varying degree of success ([Lan98, SL99, LL98, LR98, Lan00, MT00, JLM+ 98, Req00, RCG00]), and which has strong tool support for mathematical reasoning about models, including internal consistency verification. First of all, the notation and fundamentals of the B-method are briefly presented. Then, the architecture of the specification is described and related to the semi-formal specification. Finally, we briefly evaluate the suitability of the model for automating test case generation.

Copyright

c

2004 INRIA. All Rights Reserved

CONTENTS

1

Contents 1 Introduction 1.1 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 GlobalPlatform Specification Compatibility . . . . . . . . . . . . . . . . . . . . . .

2 2 2 3

2 Background 2.1 The B Abstract Machine Notation 2.1.1 Specification structure . . . 2.1.2 Operations . . . . . . . . . 2.1.3 Generalized substitutions . 2.1.4 Operators . . . . . . . . . . 2.2 Tool support . . . . . . . . . . . .

3 3 3 7 7 8 9

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 Architecture

10

4 Interpretation

11

5 Formal proof

16

6 Automated test case generation

17

Copyright

c

2004 INRIA. All Rights Reserved

1.2

Scope

1

Introduction

1.1

2

Acronyms

This document and the formal specification use the following acronyms: Acronym AID APDU API CCMF CLA CSRS CVM DAP ELF EPL GP GPCS

Meaning Application Identifier Application Protocol Data Unit Application Programming Interface Card Content Management Function Instruction class of an APDU command GlobalPlatform Card Security Requirements Specification Version 1.0 Cardholder Verification Method Data Authentication Pattern Executable Load File GlobalPlatform Card Specification 2.1.1 Errata & Precisions List 1.2 GlobalPlatform GlobalPlatform Card Specification (version 2.1.1 if not otherwise stated) Initial Chaining Vector Instruction code of an APDU command Issuer Security Domain Message Authentication Code Open Platform Open Platform Environment Operating System Personal Identification Number Runtime Environment Secure Channel Protocol Security Domain Security Feature Table 1: Acronyms

ICV INS ISD MAC OP OPEN OS PIN RTE SCP SD SF

1.2

Scope

The security requirements for a whole GlobalPlatform card are described in [Glo01], including those for the underlying RTE, OS and Integrated Circuit. That document describes as well the platform assets, threats, security policies and applicable protection profiles. Our work focuses on the security requirements, although functional non-security related requirements are also formalized in some detail. The specification top-level architecture is aimed at emphasizing the mapping from functional requirements to actual protection profiles. These protection profiles are given in [Glo01, Chapter 5], bundled together in groups and referred to as Security Features. In particular, we put the stress on the APDU and GP API interfaces, and choose not to formalize some requirements when it does not add any value over the current semiformal specification and it does not affect the overall specification completeness. In order to avoid adding additional complexity, the model does not deal explicitly with protection against abnormal function interruption (e.g. due to abrupt card withdrawal). However, this is not an issue under the assumption that operations in the specification are executed atomically.

Copyright

c

2004 INRIA. All Rights Reserved

1.3

GlobalPlatform Specification Compatibility

1.3

3

GlobalPlatform Specification Compatibility

This specification is compatible with GlobalPlatform Card Security Requirements Specification Version 1.0 [Glo01], and with GlobalPlatform Card Specification Version 2.1.1 [Glo03]. All available published errata has been incorporated into the model. Note also that some decisions made in the formal specification, that would otherwise seem arbitrary, are actually a result from clarifications and precisions requested to GlobalPlatform.

2 2.1

Background The B Abstract Machine Notation

In this section we present some basic concepts of the B language notation. For further details, the reader is encouraged to refer to [Cle03] or textbooks such as [Abr96] or [Lan96]. 2.1.1

Specification structure

A B specification is composed of a hierarchy of modules classified according to their abstraction level: Abstract Machines, Refinements and Implementations. For a full implementable specification Abstract Machines must be refined down to Implementations (possibly by means of intermediate Refinements), although this is not compulsory for completeness. Modules are formally defined by declaring its state (as a set of variables) and its operations, used to enquire or modify that state. The notation used is based on the predicate calculus and set theory while its semantics is given using an extension of Dijsktra’s weakest precondition calculus. There are some language constructs that are intended to be used exclusively in some abstraction levels. Constructs closer to implementation (e.g. local variable definitions, loops, sequential composition) cannot be used in Abstract Machines, and non-implementable constructs (e.g. nondeterministic choice) cannot be used in implementations. Refinements are somewhere in between: local variable substitutions are allowed in Refinements while loops are not. For the sake of simplicity, rather than using the full expressive power of the B method, we describe our model restricting the clauses and compositional constructs to a subset of those supported. Figure 1 shows the general structure of Abstract Machines within the specification, while Figure 2 show the general structure of Implementations. We do not use intermediate Refinements. In brief, the purpose of each clause in an Abstract Machine is as follows: MACHINE This clause introduces the name of the machine SEES Introduces a link that allows to reference within the component, an abstract machine instance, to access its constituents (sets, constants and variables) without modifying them. SETS Allows the definition of given sets (types). A given set is introduced by its name and an optional enumeration of its values. If the elements of the set are left unspecified it is said to be a deferred set and implicitly assumed to be non-empty and finite. Otherwise, if its values are explicitly enumerated, it is called an enumerated set. Given sets, be they enumerated or deferred, denote independent types. As a consequence, no predicate in the PROPERTIES clause can impose any equality or inclusion relationship among them. Likewise enumerated sets must have distinct elements. DEFINITIONS This clause is used to introduce some rewriting rules. Each definition is introduced by means of an equation using the == operator, where the left hand side is the name of the definition, and the right hand side its body, the expression that replaces the definition name. Definitions are mere macros that are applied to the text of the abstract machine, replacing each occurrence of a definition name with its body. The position of the DEFINITIONS clause within the abstract machine is irrelevant.

Copyright

c

2004 INRIA. All Rights Reserved

2.1

The B Abstract Machine Notation

4

MACHINE M SEES ... SETS ... DEFINITIONS ... CONSTANTS ... PROPERTIES ... VARIABLES ... INVARIANT ... ASSERTIONS ... INITIALISATION ... OPERATIONS ... END Figure 1: General structure of a B Abstract Machine

CONSTANTS Used to define the list of machine constants. Each identifier in the list is declared as data that can be referred to in a read-only way within the operations of the machine. Their type is declared later under the PROPERTIES clause. PROPERTIES Logical properties of given sets and constants are stated in this clause. Its body is a predicate (usually a conjunction of predicates) involving only the machine sets and constants. A typing constraint must be provided for each identifier declared in the CONSTANTS clause, though their particular value is not necessarily determined. VARIABLES Machine variables are listed in this clause. It consists of a list of comma-separated identifiers, declared as denoting writable data within the machine. Every variable must be typed in the INVARIANT clause. INVARIANT Constraints on the variables, including the typing of the variables, are specified in this clause. It consists of a predicate (usually a conjunction of predicates), which may involve the constants, sets and variables previously defined. This predicate must be proved to be established by the INITIALISATION and preserved by the execution of every operation

Copyright

c

2004 INRIA. All Rights Reserved

2.1

The B Abstract Machine Notation

5

IMPLEMENTATION M 1 REFINES M SEES ... IMPORTS ... PROMOTES ... OPERATIONS ... END Figure 2: General structure of a B Implementation

in the machine. ASSERTIONS It is made up of a list of predicates. These predicates are supposed to be deducible from those of the INVARIANT and PROPERTIES clauses. Assertions are incorporated as additional hypotheses in proofs and are helpful for making proofs on the machine easier. INITIALISATION This clause allows the assignment of initial values to the variables of the machine. The assigned values must be proved to be such that the invariant holds. The initialization takes the form of a generalized substitution and as such may be non-deterministic. OPERATIONS This clause is used to declare the operations of the machine. The operations constitute the dynamic part of the B language. The role of an operation is to modify the state of the abstract machine within the limits of the invariant. In fact, after the initialization, the value of the machine variables may only be modified by its operations. The purpose of each clause in an Implementation is as follows: IMPLEMENTATION This clause gives a name to the implementation. REFINES Identifies the component being refined. SEES Introduces a link that allows to reference within the component, an abstract machine instance, to access its constituents (sets, constants and variables) without modifying them. IMPORTS Creates an imported Abstract Machine instance to use its data and operations to implement the module’s own data and operations. PROMOTES Promotes operations from imported machines. It is equivalent to redefining these operations under the OPERATIONS clause. CONCRETE VARIABLES Implementation variables are listed in this clause. It consists of a list of comma-separated identifiers, declared as denoting writable data within the module. Every variable must be typed in the INVARIANT clause. Copyright

c

2004 INRIA. All Rights Reserved

2.1

The B Abstract Machine Notation

6

INVARIANT Constraints on the variables, including the typing of the variables, are specified in this clause. It consists of a predicate (usually a conjunction of predicates), which may involve the constants, sets and variables previously defined. INITIALISATION This clause allows the assignment of initial values to the variables of the implementation. OPERATIONS This clause is used to declare the refined operations. The behavior of refined operations must be an allowable behavior according to the abstract operations. 2.1.2

Operations

An operation is made up of a header an a body. The operation header is an identifier, designing its name, optionally followed by a parenthized comma-separated list of input formal parameters. A list of output parameters may be specified preceding the name of the operation. The body of an operation is a generalized substitution. The input parameters are only accessible in a read-only fashion in the operation body, while the output parameters are writeable. All the input formal parameters must be typed before use. An operation that has input parameters is written using a precondition substitution (PRE . . . THEN . . . END) that types them and possibly expresses other properties that shall hold at the time the operation is executed. When the operation is specified, the assumption is made that the formal input parameters verify the precondition. Formal input parameters cannot be modified in the body of the operation, and therefore they will always verify the precondition in the body of the operation. Figure 3 shows an example of an operation with both input and output parameters. 2.1.3

Generalized substitutions

State transitions in B AMN are specified by means of generalized substitutions. A generalized substitution is an abstract mathematical construct built up from basic substitutions, such as x := e, corresponding to simple assignments to state variables. In this section we describe some of the operators used to build up generalized substitutions. skip This operator denotes a substitution with no effect. The before and after states of this substitution are the same. PRE C THEN S END When condition C holds, this construct must behave like the substitution S, otherwise the behaviour is undefined and it may even not terminate. In our specification this substitution is only used for establishing operation preconditions. An operation may be invoked only if its precondition is satisfied. CHOICE R OR S END This generalized substitution is called bounded choice. It is used to express a non-deterministic choice between two substitutions, it may behave either like R or like S. If an operation is defined using this operator, a corresponding implementation may freely choose to behave either like R or like S. ANY v WHERE C THEN S END This substitution is called unbounded choice, and its underlying idea is to generalize the bounded choice substitution. If S is a substitution depending on a variable (list of variables) v then the unbounded choice describes a new substitution standing for all possible behaviors of S whatever value is given to v satisfying C. The substitution x :∈ S is a shorthand notation for the substitution ANY y WHERE y ∈ S Copyright

c

2004 INRIA. All Rights Reserved

2.1

The B Abstract Machine Notation

7

THEN x := y END. Simultaneous substitution The simultaneous substitution R || S corresponds to the simultaneous execution of R and S. To be well-defined, the set of variables modified in R and the set of variables modified in S must be disjoint. 2.1.4

Operators

In this section we describe some of the mathematical and set-theoretical operators used in the specification. Power set The power set of a set S, P(S), is the set of all subsets of S. Set of relations Let X and Y be sets. A relation of X into Y is a set of couples x 7→ y (or equivalently x,y), where x is an element of X and y is an element of Y. X ↔ Y denotes the set of relations of X into Y, that is to say, the set P(P(X×Y)) where × denotes the usual cartesian product. Sets of functions If X and Y are sets, then • X→ 7 Y denotes the subset of X ↔ Y whose elements are the (partial) functions from X into Y • X → Y denotes the set of total functions from X into Y, that is to say, the set {f | f ∈ X → 7 Y ∧ dom(f) = X} • X 7 Y denotes the set of (partial) injections from X into Y, that is to say, the set {f | f ∈ X→ 7 Y ∧ f−1 ∈ Y → 7 X} Identity relation Given a set S, the identity relation on S is defined as: id(S) = {x,y | x ∈ S ∧ y = x} Inverse relation Let R be a relation such that R ∈ X×Y. Then, R−1 is the inverse of the relation R, that is to say: R−1 = {y,x | y,x ∈ Y×X ∧ x 7→ y ∈ R} Direct product Let R and S be relations such that R ∈ T↔U and S ∈ T↔V, then the direct product of R and S, R ⊗ S, is defined as: R ⊗ S = {x,(y,z) | x,(y,z) ∈ T×(U×V) ∧ x 7→ y ∈ R ∧ x 7→ z ∈ S} Domain and range If R ∈ X ↔ Y, then dom(R) = {x | x ∈ X ∧ ∃ y.(y ∈ Y ∧ x 7→ y ∈ R)} ran(R) = {y | y ∈ Y ∧ ∃ x.(x ∈ X ∧ x 7→ y ∈ R)} Image

Copyright

c

2004 INRIA. All Rights Reserved

2.2

Tool support

8

o1,o2 ← IsGreater(i1, i2) = PRE i1 ∈ NAT ∧ i2 ∈ NAT THEN IF i1 > i2 THEN o1 := TRUE || o2 := i1 ELSE o1 := FALSE || o2 := i2 END Figure 3: Operation with input and output parameters

If R ∈ X ↔ Y and F ⊆ X, then R [F ] = { y | y ∈ Y ∧ ∃ x.(x ∈ F ∧ x 7→ y ∈ R} Domain restriction and antirestriction Let R be a relation such that R ∈ X ↔ Y and F ⊆ X, then F C R = {x,y | x 7→ y ∈ R ∧ x ∈ F}

FC − R = {x,y | x 7→ y ∈ R ∧ x ∈ / F}

Range restriction and antirestriction Let R be a relation such that R ∈ X ↔ Y and F ⊆ Y, then R B F = {x,y | x 7→ y ∈ R ∧ y ∈ F}

RB − F = {x,y | x 7→ y ∈ R ∧ y ∈ / F}

Override Let R and Q be relations such that R ∈ X ↔ Y and Q ∈ X ↔ Y, then QC − − R = {x,y | x,y ∈ X × Y ∧ ((x 7→ y ∈ Q ∧ x ∈ / dom(R)) ∨ x 7→ y ∈ R)} If f is a function and E and F expressions such that E evaluates to an element in the domain of f, then the assignment f(E ) := F is equivalent to the assignment f := f C − − {E 7→ F}.

2.2

Tool support

There exist a number of tools that offer support for the B-method: specification, design, proof, code generation, test case extraction and animation (http://www-lsr.imag.fr/B/b-tools.html). There are currently two commercially available toolkits that support the complete development of systems using the method, the Atelier B tool from ClearSy (http://www.atelierb.societe.com), and the B-Toolkit from B-Core (http://www.b-core.com/btoolkit.html). In the development of this specification we have used the Atelier B toolkit. Among other things, it allows to verify the syntax and typecheck a specification as well to automatically generate the proof obligations that guarantee its consistency. To discharge these obligations Atelier B provides a powerful theorem prover which can be run either in automatic or interactive mode.

Copyright

c

2004 INRIA. All Rights Reserved

3 Architecture

3

9

Architecture

The overall architecture of our specification is aimed at showing the way functional requirements are mapped down to Security Features. Figure 4 shows a view of the specification architecture where arrows represents SEES or IMPORTS links and boxes represent the modules. The execution of an APDU command is only sketched in the Interface Abstract Machine, without any distinction for the different types of commands. The specification becomes richer when the Interface machine is implemented (Interface 1) and the execution of each APDU command is delegated to different operations in the Validation machine. Further detail is then incorporated when implementing the Validation machine using the Process machine, and even more when implementing the Process machine relying on the Security Features machine. The level of detail in each stage depends on how abstract is the representation of the Card state: how many and which variables are used to represent it. Had we chosen to incrementally refine the Interface machine, we would have finished having a single operation representing the execution of every possible APDU command sent to the Card. This operation would have been far way to complex both to understand and to construct, not mentioning the exponential increment in the number of generated proof obligations for each refinement. By using the above described method for refining the initial specification we avoid all these drawbacks and we make the specification simpler to prove and mantain.

    


   

    !    "   

# $ %% #  $%&% 

'(! *) +"  (" % , -$-, .0/213546 ,

Figure 4: Overall specification architecture. An arrow pointing from module M to module N should be read as M SEES|IMPORTS N. Ovals represent Abstract Machines, boxes Implementations. A short description of each module is as follows:

Copyright

c

2004 INRIA. All Rights Reserved

4 Interpretation

10

Shared Data.mch

Includes definitions of sets and constants that need to be shared among different components of the specification. Some of these sets and constants are used as types (e.g. AID , VALID PUT KEY DATA), some are used as configuration parameters for the Card (e.g. MAX LOGICAL CHANNEL, ISD) and others as abstract functions (e.g. hash, select aid)

Interface.mch

Outlines the execution of APDU commands. The state of the Card in this machine is only represented by the set of currently open Logical Channels and therefore, the specification of the execution of APDU commands is specified only with respect to the set of currently open logical channels.

Interface 1.imp

Implementation of the Interface Abstract Machine. Imports the Validation machine. APDU commands are distinguished according to their class and instruction bytes, and further processing is delegated to different operations in the Validation machine.

Validation.mch

Models the validation, dispatching and security processing of APDU commands as well as the behavior upon Card Reset or Power up. Each operation deals with a different type of interaction, a Card Reset, a Power Up event or an specific type of APDU command.

Validation 1.imp

Implementation of the Validation Abstract Machine. The validation and early processing of each APDU command is implemented using the operations available in the Process machine. Once this is done, a final operation is called to actually execute the command.

Process.mch

Security Features that deal with the validation, dispatching and security processing of APDU commands as well as GlobalPlatform API methods are first introduced in this machine. The Card state is extended to represent most of the Card features including registered load files, the CVM and cryptographic keys. The actual processing of APDU commands is specified in detail.

Process 1.imp

Implementation of the Process abstract machine. The operations in the Process machine that represent the actual processing of APDU commands are implemented using only operations in the Security Features machine. This is the last step towards mapping the execution of APDU commands to Security Features.

Security Features.mch

Security Features as defined in the GlobalPlatform Card Security Requirements Specification are represented as operation in this component. A Security Feature might not be represented by exactly one operation, but by a number of operations that deal separately with each case the Security Feature might have to deal with. Table 2: Component description

4

Interpretation

The Security Features are described in Chapter 5 of [Glo01] in terms of attempted operations performed on Objects. The outcome, i.e., whether the attempt succeeds or fails, is decided by a set of rules which are expressed in terms of Security Attributes. All the Security Attributes identified in [Glo01] are stored on-card as (instances of) objects. In the B specification, the objects are defined in term of the variables and constants of the machine as shown partially in Table 3.

Copyright

c

2004 INRIA. All Rights Reserved

4 Interpretation

CSRS Object APDU Buffer[Command] SELECT[Data: Application AID] INSTALL[For Install][Data: Executable Module AID] PUT KEY[Data: Key Attributes] INSTALL[For Load][Data: Load File Data Block Hash] Previous Install Command[Data: Load File Data Block Hash] Previous Install Command[Data: Load File AID] Previous Install Command[Data: SD AID] GP Registry[Card Life Cycle State] GP Registry[Application Life Cycle State] GP Registry[SD Life Cycle State] GP Registry[Associated SD] GP Registry[ISD AID] GP Registry[SD AID]

11

Equivalent B expression(s) operations arguments: CLA, INS, P1, P2, Data, Le select aid(Data) install for install mod aid(Data) put key type(Data), put key length(Data), ... install for load hash(Data) load hash load elf aid load sd aid app life cycle(ISD) app life cycle(aa)

app life cycle(sd) app sd(aa) ISD sd (where sd ∈ applications ∧ sd 7→ pr security domain ∈ app privileges) GP Registry[Application AID] aa (where aa ∈ applications) GP Registry[ELF AID] ee (where ee ∈ executable load files) GP Registry[Executable Module AID] mm (where mm ∈ executable modules) GP Registry[Selected Application] selected application(ch) GP Registry[Application Privilege] app privileges[{aa}] SCP Data[Security Level] security level(ch) CVM[State] cvm state CVM[Value] cvm value CVM[Retry Counter] cvm retry counter CVM[Retry Limit] cvm retry limit Table 3: Mapping of CSRS objects to B expressions.

Navigation trough the execution of an APDU command can be accomplished by navigating through the specification following the implementation path from the Interface Abstract Machine to the Security Features abstract machine. If the process is stopped somewhere in between what one would get is an abstract specification of what the command does. To illustrate this, we can take the same example as in [Glo01], and try to obtain an abstract specification of the execution of an INSTALL[For Install] command issued by the Card Administrator. The reception of an APDU command command is represented by the execution of the APDU operation in Interface, the input parameters being the command fields. Supposing the channel information contained in the CLA byte corresponds to a currently open Logical Channel, the specification says that some status word should be returned and that the set of open Logical Channels might be modified. Taking into account that the Card state in this machine is restricted to the set of open Logical Channels, this is a complete specification of APDU outcome with respect to this representation. sw ← APDU(CLA, INS, P1, P2, Data, Le) = PRE

Copyright

c

2004 INRIA. All Rights Reserved

4 Interpretation

12

CLA ∈ BYTE ∧ INS ∈ BYTE ∧ P1 ∈ BYTE ∧ P2 ∈ BYTE ∧ Data ∈ DATA ∧ Le ∈ BYTE THEN IF channel(CLA) 6∈ open channels THEN IF logical channel aware = TRUE THEN sw := SW ERROR ELSE sw :∈ STATUS WORD END ELSE sw :∈ STATUS WORD || open channels : ( open channels ⊆ LOGICAL CHANNEL ∧ 0 ∈ open channels) END END

We may obtain a more complete specification of the outcome by looking at how the APDU operation is implemented in Interface 1. Note that the correctness of the implementation with respect to the abstract operation may be proved (and indeed it was). sw ← APDU(CLA, INS, P1, P2, Data, Le) = VAR bb IN bb ← IsOpen(channel(CLA)); IF bb = FALSE ∧ logical channel aware = TRUE THEN sw := SW ERROR ELSE VAR sd, ch IN IF bb = FALSE THEN ch := 0 ELSE ch := channel(CLA) END; sd ← IsSDSelected(ch); CASE and(CLA,xFC) OF ... OR x80,x84 THEN CASE INS OF ... OR xE6 THEN IF

Copyright

c

2004 INRIA. All Rights Reserved

4 Interpretation

13

sd = TRUE THEN CASE P1 OF ... OR x0C, x04 THEN sw ← Install For Install(ch, and(CLA,xFC), INS, P1, P2, Data, Le) END END ELSE sw ← Unknown(ch,and(CLA,xFC),INS,P1,P2,Data,Le) END ... ELSE sw ← Unknown(ch,and(CLA,xFC),INS,P1,P2,Data,Le) END END ELSE sw ← Unknown(ch,and(CLA,xFC),INS,P1,P2,Data,Le) END END END END

The implementation relies on some operations from the Validation machine to carry out some tests (IsOpen, IsSDSelected). The class and instruction bytes are then analyzed to determine which operation in Validation have to be called to process the command. As we are assuming that the command is an INSTALL[For Install] sent by the Card Administrator (the ISD is selected on the Logical Channel where the command was sent), the Install For Install operation will be called, stripping the logical channel information from its class byte. sw ← Install For Install(ch, CLA, INS, P1, P2, Data, Le) = PRE ch ∈ open channels ∧ CLA ∈ {x80,x84} ∧ INS = xE6 ∧ P1 ∈ {x0C,x04} ∧ P2 ∈ BYTE ∧ Data ∈ DATA ∧ Le ∈ BYTE ∧ selected(ch) ∈ security domains THEN IF P2 = x00 ∧ Le = x00 ∧ app life cycle (ISD) 6= TERMINATED ∧ (selected (ch) 6= ISD ⇒ app life cycle (ISD) 6= CARD LOCKED ∧ app life cycle (selected (ch)) ∈ {SELECTABLE, PERSONALIZED}) THEN ANY sl, data WHERE sl ⊆ SECURITY LEVEL ∧ data ∈ DATA THEN security level(ch) := sl || IF

Copyright

c

2004 INRIA. All Rights Reserved

5 Formal proof

14

AUTHENTICATED ∈ sl THEN IF data ∈ VALID INSTALL FOR INSTALL DATA THEN sw :∈ STATUS WORD || applications, security domains, app life cycle, default selected :( applications ⊆ AID ∧ security domains ⊆ applications ∧ app life cycle ∈ applications → LIFE CYCLE ∧ selected ∈ open channels → applications ∧ default selected ∈ applications ∧ ISD ∈ security domains) ELSE sw := SW ERROR END ELSE sw := SW ERROR END END ELSE sw := SW ERROR END END

Assuming that the command syntax is correct (P2 = x00 ∧ Le = x00), and that the Card life cycle is not TERMINATED (app life cycle (ISD) 6= TERMINATED) the specification states which variables may be modified but does not determine exactly how they will be modified. Up to this point, we have obtained an abstract description of the functional requirements for an INSTALL[For Install] command issued by the Card Administrator. To obtain a more concrete description, we might continue this process by reviewing the implementation of the Install For Install operation.

5

Formal proof

The B-method semantics allows to mechanically generate the theorems to be proved in order to guarantee that the model is mathematically well-founded. These theorems are usually called proof obligations and they may be classified (partially) as follows: Initialization consistency The initial state of the abstract machine is established by the generalized substitution under the INITIALISATION clause. Assuming the stated properties of constant and sets, the initialization must be proved to establish the machine invariant. Invariant preservation As state transitions in the B language are specified via operations, and state transitions shall not violate the invariant, each operation in the abstract machine is expected to preserve the invariant. This give rise to a number of proof obligations which ensure that every operation in the machine does preserve the invariant. Implementation correctness The implementation of an operation must obey its abstract specification: it might be more restrictive, but it must not allow behaviors that are not allowed by the abstract operation.

Copyright

c

2004 INRIA. All Rights Reserved

6 Automated test case generation

15

For a fully formal development, each one of the proof obligations generated from an specification shall be discharged. Once this is done, it can be assured that every state reachable by the specified system satisfies the invariant. 3,646 proof obligations have been automatically generated from the B specification of the card security requirements. The automatic prover of Atelier B managed to prove 3,230 of them (approximately the 89%), while the rest remain to be proved interactively. Using the interactive theorem prover all the 416 remaining additional proof obligations were discharged. This gives a complete guarantee of the model consistency assuming the correctness of the tool and the underlying theory.

6

Automated test case generation

It is the opinion of the author that the model as it is should be reasonably suitable for automated test case generation, even considering that state-of-the-art tools in this area can generally only deal with single-machine models. Dealing with one module at a time in this particular specification is an efficient way of generating test cases at different levels of abstraction.

References [Abr96]

Jean-Raymond Abrial. The B Book - Assigning Programs to Meanings. Cambridge University Press, August 1996.

[Cle03]

ClearSy. B Language Reference Manual 1.8.5, 2003.

[Glo01]

GlobalPlatform. Card Security Requirements Specification. Version 1.0, May 2001.

[Glo03]

GlobalPlatform. Card Specification. Version 2.1.1, March 2003.

[JLM+ 98] Jacques Julliand, B. Legeard, T. Machicoane, B. Parreaux, and B. Tatibouet. Specification of an integrated circuit card. protocol application using the B method and linear temporal logic. In B’98 : The 2nd International B Conference, pages 273–292, 1998. [Lan96]

Kevin Lano. The B Language and Method: A guide to Practical Formal Development. Springer Verlag London Ltd., 1996.

[Lan98]

Jean-Louis Lanet. Using the B method to model protocols. In AFADL’98, pages 79–90, 1998.

[Lan00]

Jean-Louis Lanet. Are smart cards the ideal domain for applying formal methods? In ZB’2000 – International Conference of B and Z Users, pages 363–374, 2000.

[LL98]

Jean-Louis Lanet and Pierre Lartigue. The use of formal methods for smartcards, a comparison between B and SDL to model the T=1 protocol. In Proceedings of International Workshop on Comparing Systems Specification Techniques, Nantes, March 1998.

[LR98]

Jean-Louis Lanet and Antoine Requet. Formal proof of smart card applets correctness. In Proceedings of the Third Smart Card Research and Advanced Application Conference (CARDIS’98), page ??, Louvain-la-Neuve, (be), September 1998.

[MT00]

St´ephanie Motr´e and Corinne T´eri. Using formal and semi-formal methods for a common criteria evaluation. In Eurosmart, Marseille (France), jun 2000.

Copyright

c

2004 INRIA. All Rights Reserved

REFERENCES

16

[RCG00]

Antoine Requet, Ludovic Casset, and Gilles Grimaud. Application of the B formal method to the proof of a type verification algorithm. In HASE 2000, Albuquerque (NM), November 2000.

[Req00]

Antoine Requet. A B model for ensuring soundness of the Java card virtual machine. In FMICS’2000, Berlin, mar 2000.

[SL99]

Denis Sabatier and Pierre Lartigue. The use of the B formal method for the design and the validation of the transaction mechanism for smart card applications. In Proceedings of FM’99: World Congress on Formal Methods, pages 348–368, 1999.

Copyright

c

2004 INRIA. All Rights Reserved