C O R P O R A T E T E C H N O L O G Y Information & Communications Security A Formal Security Model of the Infineon SLE88 Smart Card Memory Management David von Oheimb, Volkmar Lotz Siemens AG, Corporate Technology, Security Georg Walter Infineon Technologies AG, Security & Chip Card ICs

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Context Certification of SLE88 according to Common Criteria EAL5+ Existing LKW security model of SLE 66 [LKW00, vOL02] applies New security functionality for SLE88: Memory Management Unit virtual address space protection mechanisms on both virtual and physical level Intended to achieve security objectives: Restricted memory access Separation of applications, OS, and chip security functionality (SL) Augmenting the LKW model with a separate memory management model suffices

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Overview Context SLE88 Memory Management Overview of functionality Security Objectives Interacting State Machines SLE88 System Model Security Properties Enforcing attribute-based access control Protection of security-critical memory areas Results

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Address Space  EAR DPPAD DP  BPF 0SL 1PSL/HAL 2OS 3..15reserved regular VEA Virtual Effective Address PEAPhysical Effective Address PTPage Table PP Page Pointer VEA PEA DP Displacement PADPackage Address EAREffective Access Right BPFBlock Protection Field PT PP privileged

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Access Control Mechanisms Block Protection Field (BPF) applies to 4-bit blocks of physical addresses Effective Access Rights (EARs) apply to 8-bit blocks of virtual addresses

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Security Requirements Critical aspects: shared memory modification of EAR table protection achieved by BPF (“fail-safe”?) port commands (not shown here)

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March state transitions (maybe non-deterministic) buffered I/O simultaneously on multiple connections finite trace semantics modular (hierarchical) parallel composition Interacting State Machines (ISMs)

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Generic ISMs: global/shared state Dynamic ISMs: changing availability and communication Ambient ISMs: mobility with constrained communication Dynamic Ambient ISMs: combination Extensions to ISM concepts (generic) ISMs AmbISMs dISMs dAmbISMs

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March AutoFocus: CASE tool for graphical specification and simulation syntactic perspective graphical documentation type and consistency checks Isabelle/HOL: powerful interactive theorem prover semantic perspective textual documentation validation and correctness proofs AutoFocus drawing  Quest file  Isabelle theory file Within Isabelle: ism sections  standard HOL definitions Tool support

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March ISM representation in AutoFocus System Structure Diagram: Client/Server State Transition Diagram: working thread

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Basic ISMs in Isabelle/HOL

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March System Model: SLE88 Memory Formal definition of the virtual address space:

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March System Model: State Formal definition of the system state: physical memory address translation access control settings execution state

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March System Model: Inputs and Outputs

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March System Model: Memory Access Auxiliary function for checking access control conditions Request for access mode at virtual address va in state s returns Ok, if: va is mapped to a physical address access is (privileged or) permitted according to EAR table BPF is consistently assigned (or special access by SL)

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March System Model: Transition Relation (excerpt)

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Security Properties (1): “Granted Accesses Do Respect EAR Settings” PT_map PEAVEA WW WR Consistency of EARs: In case of non-injective PT_map, the effective protections is determined by weakest EAR Conflicts are possible Should aliasing be prohibited? Solution: Define consistency requirements on EARs: all WW or all RR Property only holds in case of EAR consistency

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Security Properties (2): “Protection of SL Memory” Required axioms (assumptions): Initial state satisfies requirements on BPF and initial EAR values Benign behaviour of SL (correct setting of BPF values, page table entries, and EAR table entries) Used lemmas (invariants): SL parts of page table and EAR table can only be modified by SL EARs referring to SL are always set in a way that access by non-SL packages is denied For SL memory areas, the BPF tag is always set

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Conclusion Identification: necessary assumptions on initial state and behaviour of SL Analysis: effects of non-injective address mappings Analysis: role of block protection fields (BPF) Proof: security functionality is adequate to satisfy security requirements (on abstract level of specification) Proof: security specification is consistent (with some additional arguments referring to consistency of HOL) Security model satisfies all requirements of ADV_SPM.2 and thus contributes to EAL5 certification Effort: 2 person months

C O R P O R A T E T E C H N O L O G Y Information & Communications Security Thank you for your attention! Questions?

C O R P O R A T E T E C H N O L O G Y Information & Communications Security Backup Slides

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Formal Definition of Basic ISMs

C O R P O R A T E T E C H N O L O G Y Information & Communications Security Open runs

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Parallel Runs (Interaction)

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March (Parallel) Composition of ISMs

C O R P O R A T E T E C H N O L O G Y Information & Communications Security Parallel State Transition Relation

C O R P O R A T E T E C H N O L O G Y © Siemens AG, CT IC 3 Information & Communications Security CASSIS Workshop, Marseille, 13 March Results on BPF Prohibits access of non-SL packages to SL through alternative access paths Allows to grant exclusive access of SL to other memory areas Achieves write protection of SL memory areas in case of traps being delayed Is not a “fail-safe” mechanism in case of inappropriate EARs for SL memory!