Modeling Trusted Computing Support in a Protection Profile for High Assurance Security Kernels
1. RuhR-University Bochum Chair for System Security
Modeling Trusted Computing
Support in a Protection Profile for
High Assurance Security Kernels
Hans Löhr1, AhmadReza Sadeghi1, Christian Stüble2,
Marion Weber3, Marcel Winandy1
1
Chair for System Security
RuhrUniversity 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 SocioEconomic Aspects of Trusted Computing
Oxford, UK, 68 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
RBACPP
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
RBACPP
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
RBACPP
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
RBACPP
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
RBACPP
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 HASKPP – a new protection profile
Modeling trusted computing in HASKPP
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
Hypervisorbased Microkernelbased
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 Implementationindependent:
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
HASKPP
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 InterTSF 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
HASKPP
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 InterTSF 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
HASKPP
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 InterTSF 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 HASKPP
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
– Implementationindependent: 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
● HASKPP 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
RuhrUniversity Bochum
marcel.winandy@trust.rub.de
HASKPP: 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