1. RuhR-University Bochum Chair for System Security
Modeling Trusted Computing
Support in a Protection Profile for
High Assurance Security Kernels
Hans Löhr1, Ahmad­Reza Sadeghi1, Christian Stüble2,
Marion Weber3, Marcel Winandy1
1
Chair for System Security
Ruhr­University Bochum, Germany
2
Sirrix AG security technologies
Bochum, Germany
3
Federal Office for Information Security (BSI)
Bonn, Germany
Trust 2009
International Conference on the Technical and Socio­Economic Aspects of Trusted Computing
Oxford, UK, 6­8 April 2009

2. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need security kernels?
– Standard OS's suffer from high complexity
– Security functionality depends on several modules
– Some applications require stronger isolation
● Why do we need trusted computing?
– Software alone cannot protect integrity of itself
– Authenticated secure channels between systems
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 2

3. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 3

4. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Windows, Linux, Solaris, etc.
LSPP
CAPP
RBAC­PP
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 4

5. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Windows, Linux, Solaris, etc.
LSPP
CAPP
RBAC­PP
Access Control
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 5

6. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Windows, Linux, Solaris, etc. Separation Kernels
LSPP
CAPP SKPP
RBAC­PP
Access Control
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 6

7. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Windows, Linux, Solaris, etc. Separation Kernels
LSPP
CAPP SKPP
RBAC­PP
Access Control Isolated Execution
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 7

8. RuhR-University Bochum Chair for System Security
Motivation
● Why do we need a new Protection Profile?
– Abstraction level for end users
– Common Criteria provides framework for evaluation
– Protection Profiles (PPs) define classes of products
with minimum security properties in common
– Existing PPs don't cover important security aspects
Windows, Linux, Solaris, etc. Separation Kernels
LSPP ● Restricted to separation
CAPP SKPP ● Includes hardware
● No trusted computing functionality
RBAC­PP
Access Control Isolated Execution
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 8

9. RuhR-University Bochum Chair for System Security
In this Talk
Overview of HASK­PP – a new protection profile
Modeling trusted computing in HASK­PP
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 9

10. RuhR-University Bochum Chair for System Security
Goals and Design Principles
● Goal: Evaluation criteria for security kernels that manage
and separate 'compartments'
High Assurance
Security Kernel
Core Security
Trusted Storage Trusted Boot Trusted Channel
Functionality
(Isolation, Access Control) (Trusted computing functionalities)
● PP minimal as possible (allow different implementations)
● Prevent 'trivial' realizations from claiming compliance
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 10

11. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 11

12. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Concrete Product
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 12

13. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Concrete Product Security Target
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 13

14. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Concrete Product Security Target Evaluation
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 14

15. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Concrete Product Security Target Evaluation Certification
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 15

16. RuhR-University Bochum Chair for System Security
Common Criteria in a Nut Shell
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Concrete Product Security Target Evaluation Certification
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 16

17. RuhR-University Bochum Chair for System Security
TOE Architecture
Trusted
Compartment Compartment Compartment
(optional)
Communication Communication
External Object Object TOE
Entity
Security Kernel
Storage Storage
Container Container
Hardware
(Supports trusted computing functionality)
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 17

18. RuhR-University Bochum Chair for System Security
TOE Examples
Hypervisor­based Microkernel­based
Processes
Virtual Virtual Virtual
Machine Machine Machine
Virtual Machine Monitor
Microkernel
Comm. objects: virtual networks Comm. objects: IPC
Storage containers: virtual disks Storage containers: disk sectors
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 18

19. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 19

20. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 20

21. RuhR-University Bochum Chair for System Security
Threats
● Unauthorized access to objects
● Unauthorized information flow between subjects
● Manipulation of security kernel
– Replay of older state
– Influencing to generate false evidence of integrity
● Threats against TOE environment
– Installing malicious device drivers
– Starting TOE outside intended environment
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 21

22. RuhR-University Bochum Chair for System Security
Assumptions
● To be Implementation­independent:
assumptions on environment (trusted computing support)
– A.INTEGRITY_SUPPORT: produce evidence of
integrity of the security kernel
– A.BIND: bind TOE data to configuration of TOE
– A.REMOTE_TRUST: remote IT product can generate
evidence of its integrity
● More assumptions for secure operation of TOE
– Separation support, no hardware backdoors, tamper
detection, no evil administrator
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 22

23. RuhR-University Bochum Chair for System Security
Organizational Security Policies
● P.TRUST_POLICY:
– Determine how evidence of integrity is generated
– Define conditions when such evidence is required
 Allow authorized entities to verify the data
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 23

24. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 24

25. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 25

26. RuhR-University Bochum Chair for System Security
Security Objectives
● Security objectives for TOE
– Protection of objects (access control, information flow, etc.)
– Protection of the security kernel (integrity, confidentiality)
● Security objectives for TOE environment
– Secure load e.g. authenticated boot (TPM)
– Secure operation e.g. memory protection (MMU)
– Separation support e.g. protection rings (CPU)
– Integrity support e.g. measurement registers (TPM)
– Remote trust e.g. remote attestation (TPM)
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 26

27. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 27

28. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 28

29. RuhR-University Bochum Chair for System Security
Security Functional Requirements
HASK­PP
Core Security
Trusted Storage Trusted Boot Trusted Channel
Functionality
Access Control & Data Authentication Data Authentication Data Authentication
Information Flow Control
FDP_DAU.1 FDP_DAU.3_EXP FDP_DAU.3_EXP
FDP_ACC.2 FDP_RIP.2 FDP_DAU.3_EXP
FDP_ACF.1 FPT_TDC.1 TSF Validation Data Exchange
FDP_ETC.2 FIA_UAU.1 User Data Integrity & Confidentiality
FPT_ITI.1 FMT_MTD.3
FDP_IFC.2 FIA_UID.1 Integrity & Confidentiality FPT_TST.1 FDP_UIT.1 FDP_UCT.1
FDP_IFF.1 FIA_UID.2 FDP_SDI.1 FDP_RIP.2
FDP_ITC.2 FDP_UIT.1 FDP_UCT.1 TSF Data
A.HW_OK
Integrity & Confidentiality
A.NO_TAMPER
Resource Limitation TSF Data FPT_ITT.1 FPT_ITI.1
A.BIND
FRU_RSA.1 Integrity & Confidentiality A.INTEGRITY_SUPPORT
FPT_ITT.1 FPT_ITT.3 Inter­TSF Communication
Audit FPT_ITI.1 FTP_ITC.1 FPT_TDC.1
FAU_GEN.1 FPT_STM.1
FAU_SEL.1 A.HW_OK A.HW_OK
A.NO_TAMPER A.NO_TAMPER
Security Management A.BIND A.INTEGRITY_SUPPORT
FIA_ATD.1 FMT_MTD.2 A.REMOTE_TRUST
FMT_MOF.1 FMT_MTD.3
FMT_MSA.1 FMT_REV.1
FMT_MSA.2 FMT_SMF.1
FMT_MSA.3 FMT_SMR.1
FMT_MTD.1
A.HW_OK
A.NO_TAMPER
A.NO_EVIL
A.SEPARATION_SUPPORT
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 29

30. RuhR-University Bochum Chair for System Security
Security Functional Requirements
HASK­PP
Core Security
Trusted Storage Trusted Boot Trusted Channel
Functionality
Access Control & Data Authentication Data Authentication Data Authentication
Information Flow Control
FDP_DAU.1 FDP_DAU.3_EXP FDP_DAU.3_EXP
FDP_ACC.2 FDP_RIP.2 FDP_DAU.3_EXP
Data Exchange
FDP_ACF.1
FDP_ETC.2
FPT_TDC.1
FIA_UAU.1
Security functional requirements for TOE
User Data
TSF Validation
Integrity & Confidentiality
FPT_ITI.1 FMT_MTD.3
FDP_IFC.2 FIA_UID.1 Integrity & Confidentiality FPT_TST.1 FDP_UIT.1 FDP_UCT.1
FDP_IFF.1 FIA_UID.2 FDP_SDI.1 FDP_RIP.2
FDP_ITC.2 FDP_UIT.1 FDP_UCT.1 TSF Data
A.HW_OK
Integrity & Confidentiality
A.NO_TAMPER
Resource Limitation TSF Data FPT_ITT.1 FPT_ITI.1
A.BIND
FRU_RSA.1 Integrity & Confidentiality A.INTEGRITY_SUPPORT
FPT_ITT.1 FPT_ITT.3 Inter­TSF Communication
Audit FPT_ITI.1 FTP_ITC.1 FPT_TDC.1
FAU_GEN.1 FPT_STM.1
FAU_SEL.1 A.HW_OK A.HW_OK
A.NO_TAMPER A.NO_TAMPER
Security Management A.BIND A.INTEGRITY_SUPPORT
FIA_ATD.1 FMT_MTD.2 A.REMOTE_TRUST
FMT_MOF.1 FMT_MTD.3
FMT_MSA.1 FMT_REV.1
FMT_MSA.2 FMT_SMF.1
FMT_MSA.3 FMT_SMR.1
FMT_MTD.1
A.HW_OK
A.NO_TAMPER
A.NO_EVIL
A.SEPARATION_SUPPORT
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 30

31. RuhR-University Bochum Chair for System Security
Security Functional Requirements
HASK­PP
Core Security
Trusted Storage Trusted Boot Trusted Channel
Functionality
Access Control & Data Authentication Data Authentication Data Authentication
Information Flow Control
FDP_DAU.1 FDP_DAU.3_EXP FDP_DAU.3_EXP
FDP_ACC.2 FDP_RIP.2 FDP_DAU.3_EXP
Data Exchange
FDP_ACF.1
FDP_ETC.2
FPT_TDC.1
FIA_UAU.1
Security functional requirements for TOE
User Data
TSF Validation
Integrity & Confidentiality
FPT_ITI.1 FMT_MTD.3
FDP_IFC.2 FIA_UID.1 Integrity & Confidentiality FPT_TST.1 FDP_UIT.1 FDP_UCT.1
FDP_IFF.1 FIA_UID.2 FDP_SDI.1 FDP_RIP.2
FDP_ITC.2 FDP_UIT.1 FDP_UCT.1 TSF Data
A.HW_OK
Integrity & Confidentiality
A.NO_TAMPER
Resource Limitation TSF Data FPT_ITT.1 FPT_ITI.1
A.BIND
FRU_RSA.1 Integrity & Confidentiality A.INTEGRITY_SUPPORT
FPT_ITT.1 FPT_ITT.3 Inter­TSF Communication
Audit FPT_ITI.1 FTP_ITC.1 FPT_TDC.1
FAU_GEN.1 FPT_STM.1
FAU_SEL.1 A.HW_OK A.HW_OK
A.NO_TAMPER A.NO_TAMPER
Security Management A.BIND A.INTEGRITY_SUPPORT
FIA_ATD.1 FMT_MTD.2 A.REMOTE_TRUST
FMT_MOF.1 FMT_MTD.3
FMT_MSA.1 FMT_REV.1
FMT_MSA.2 FMT_SMF.1
FMT_MSA.3 FMT_SMR.1
FMT_MTD.1
Assumptions for TOE Environment
A.HW_OK
A.NO_TAMPER
A.NO_EVIL
A.SEPARATION_SUPPORT
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 31

32. RuhR-University Bochum Chair for System Security
Example: Modeling Trusted Boot
Trusted Boot
● Secure Boot:
Data Authentication
Always start in a valid state.
FDP_DAU.3_EXP
TSF Validation
If something is wrong, stop.
FPT_ITI.1 FMT_MTD.3
FPT_TST.1 ● Authenticated Boot:
A.HW_OK
A.NO_TAMPER
A.BIND
Securely store measurement results and
A.INTEGRITY_SUPPORT
start system in any case. I can verify later.
 needs assumptions regarding the operational environment
(bootstrap architecture, secure storage for integrity measurements)
 needs security functionality in the TOE
(validation of security kernel and compartments, generate/verify evidence)
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 32

33. RuhR-University Bochum Chair for System Security
Assumptions for Trusted Boot
Trusted Boot
● A.INTEGRITY_SUPPORT:
Data Authentication
Manipulated security kernel cannot
FDP_DAU.3_EXP
TSF Validation
generate false evidence of its own integrity
FPT_ITI.1 FMT_MTD.3
FPT_TST.1 ● A.BIND:
A.HW_OK
A.NO_TAMPER
A.BIND
Possibility to store data an code such that
A.INTEGRITY_SUPPORT
it can be loaded only if integrity of security
kernel is intact
And, of course, additional assumptions:
­ no hardware backdoors (A.HW_OK)
­ no undetectable tampering of hardware (A.NO_TAMPER)
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 33

34. RuhR-University Bochum Chair for System Security
Security Func. Req's for Trusted Boot
Trusted Boot
● Existing SFRs from Common Criteria:
– FPT_ITI.1: detect modifications between shutdown and
Data Authentication
FDP_DAU.3_EXP startup
TSF Validation – FPT_TST.1: run self tests when loading compartments
FPT_ITI.1 FMT_MTD.3
FPT_TST.1 requiring integrity evidence
A.HW_OK
A.NO_TAMPER
– FMT_MTD.3: accept only secure values for memory
A.BIND
A.INTEGRITY_SUPPORT
and CPU time assigned to compartments
● Additional definition of one SFR:
– FDP_DAU.3_EXP: "controlled data
authentication"
● Generation of evidence of integrity of objects
● Conditions for evidence generation
– Extends 'chain of trust' up to compartments
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 34

35. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 35

36. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 36

37. RuhR-University Bochum Chair for System Security
Security Assurance
● Conformance Claim: CC 3.1 Rev. 2, EAL5
● Evaluation Assurance Level: EAL 5
– Minimal level, because:
● For systems with high value of data
● Isolation requires evaluation of possible covert channels
● Compartments should be able to contain EAL4+ services
(e.g. Windows, Linux systems in virtual machines)
– Sufficient level, because:
● Evaluation should be feasible for commercial products
● Security Assurance Requirements: as in CC 3.1
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 37

38. RuhR-University Bochum Chair for System Security
Protection Profile Overview
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL1 ­ EAL7)
Requirements
Protection Profile
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 38

39. RuhR-University Bochum Chair for System Security
Trusted Computing in HASK­PP
Security Problem Definition Security Objectives for TOE
Security
­ Threats
Functional
­ Assumptions Security Objectives for
Requirements
­ Organizational security policies TOE Environment
Target of
Evaluation
(TOE)
Security
Evaluation Assurance Level
Conformance Claim Assurance
(EAL5)
Requirements
HASK Protection Profile
Trusted Computing support (hardware)
Trusted Computing functionality in software
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 39

40. RuhR-University Bochum Chair for System Security
Summary
● New protection profile for security kernels
● Includes trusted computing functionalities
– Implementation­independent: can be based on
TPM, secure coprocessors, or other technology
– Realized via assumptions on TOE environment
– Extends chain of trust to individual compartments
● Assurance level for products is EAL 5
● HASK­PP itself is certified EAL5
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 40

41. RuhR-University Bochum Chair for System Security
Questions?
Marcel Winandy
Ruhr­University Bochum
marcel.winandy@trust.rub.de
HASK­PP: Protection Profile for a High Assurance Security Kernel
http://www.sirrix.com/media/downloads/54500.pdf
Marcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 41