A Formal Security Model of the Infineon SLE88 Smart Card Memory Management

1. A Formal Security Model of the Infineon SLE88 Smart Card Memory Management David von Oheimb, Volkmar LotzSiemens AG, Corporate Technology, Security {David.von.Oheimb,Volkmar.Lotz}@siemens.com Georg WalterInfineon Technologies AG, Security & Chip Card ICs Georg.Walter@infineon.com

2. 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

3. 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

4. 5 21 0 DP  BPF Address Space 0 SL 1 PSL/HAL 2 OS 3..15 reserved 16..255 regular privileged  EAR 31 23 5 0 VEA PAD DP PT PEA PP VEA Virtual Effective Address PEA Physical Effective Address PT Page Table PP Page Pointer DP Displacement PAD Package Address EAR Effective Access Right BPF Block Protection Field

5. 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

6. Security Requirements • Critical aspects: • shared memory • modification of EAR table • protection achieved by BPF (“fail-safe”?) • port commands (not shown here)

7. Interacting State Machines (ISMs) • state transitions (maybe non-deterministic) • buffered I/O simultaneously on multiple connections • finite trace semantics • modular (hierarchical) parallel composition

8. (generic) ISMs AmbISMs dISMs dAmbISMs Extensions to ISM concepts • Generic ISMs: global/shared state • Dynamic ISMs: changing availability and communication • Ambient ISMs: mobility with constrained communication • Dynamic Ambient ISMs: combination

9. Tool support • 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

10. ISM representation in AutoFocus • System Structure Diagram: Client/Server • State Transition Diagram: working thread

11. Basic ISMs in Isabelle/HOL

12. System Model: SLE88 Memory Formal definition of the virtual address space:

13. System Model: State • Formal definition of the system state: • physical memory • address translation • access control settings • execution state

14. System Model: Inputs and Outputs

15. 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: • vais mapped to a physical address • access is (privileged or) permitted according to EAR table • BPF is consistently assigned (or special access by SL)

16. System Model: Transition Relation (excerpt)

17. Security Properties (1):“Granted Accesses Do Respect EAR Settings” • 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 PT_map VEA PEA WW WR

18. Security Properties (2):“Protection of SL Memory” • 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 • 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)

19. 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

20. Thank you for your attention!Questions?

21. Backup Slides

22. Formal Definition of Basic ISMs

23. Open runs

24. Parallel Runs (Interaction)

25. (Parallel) Composition of ISMs

26. Parallel State Transition Relation

27. 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!