Embed Size (px)
Citation preview
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 SecurityRuhrUniversity Bochum, Germany
2 Sirrix AG security technologiesBochum, Germany
3 Federal Office for Information Security (BSI)Bonn, Germany
Trust 2009International Conference on the Technical and SocioEconomic Aspects of Trusted ComputingOxford, UK, 68 April 2009
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 2
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 3
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 4
RuhR-University Bochum
Marcel Winandy
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
CAPPLSPP
RBACPP
Windows, Linux, Solaris, etc.
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 5
RuhR-University Bochum
Marcel Winandy
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
CAPPLSPP
RBACPP
Windows, Linux, Solaris, etc.
Access Control
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 6
RuhR-University Bochum
Marcel Winandy
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
CAPPLSPP
RBACPP
Windows, Linux, Solaris, etc.
SKPP
Separation Kernels
Access Control
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 7
RuhR-University Bochum
Marcel Winandy
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
CAPPLSPP
RBACPP
Windows, Linux, Solaris, etc.
SKPP
Separation Kernels
Access Control Isolated Execution
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 8
RuhR-University Bochum
Marcel Winandy
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
CAPPLSPP
RBACPP
Windows, Linux, Solaris, etc.
SKPP
Separation Kernels
Access Control Isolated Execution
● Restricted to separation● Includes hardware● No trusted computing functionality
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 9
RuhR-University Bochum
Marcel Winandy
Chair for System Security
In this Talk
Overview of HASKPP – a new protection profile
Modeling trusted computing in HASKPP
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 10
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Goals and Design Principles
High AssuranceSecurity Kernel
Core Security Functionality
Trusted Storage Trusted Boot Trusted Channel
● Goal: Evaluation criteria for security kernels that manage and separate 'compartments'
● PP minimal as possible (allow different implementations)● Prevent 'trivial' realizations from claiming compliance
(Isolation, Access Control) (Trusted computing functionalities)
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 11
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 12
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
Concrete Product
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 13
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
Concrete Product Security Target
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 14
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
Concrete Product Security Target Evaluation
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 15
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
Concrete Product Security Target Evaluation Certification
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 16
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Common Criteria in a Nut Shell
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
Concrete Product Security Target Evaluation Certification
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 17
RuhR-University Bochum
Marcel Winandy
Chair for System Security
TOE Architecture
Compartment CompartmentTrusted
Compartment(optional)
StorageContainer
ExternalEntity
Security Kernel
Hardware(Supports trusted computing functionality)
StorageContainer
CommunicationObject
CommunicationObject TOE
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 18
RuhR-University Bochum
Marcel Winandy
Chair for System Security
TOE Examples
Hypervisorbased Microkernelbased
Virtual Machine Monitor
VirtualMachine
VirtualMachine
VirtualMachine
Comm. objects: virtual networksStorage containers: virtual disks
Microkernel
Comm. objects: IPCStorage containers: disk sectors
Processes
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 19
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 20
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 21
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 22
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 23
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 24
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 25
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 26
RuhR-University Bochum
Marcel Winandy
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)
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 27
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 28
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 29
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Security Functional RequirementsHASKPP
Core SecurityFunctionality
FDP_ACC.2 FDP_RIP.2FDP_ACF.1 FPT_TDC.1FDP_ETC.2 FIA_UAU.1FDP_IFC.2 FIA_UID.1FDP_IFF.1 FIA_UID.2FDP_ITC.2
Access Control &Information Flow Control
FRU_RSA.1
Resource Limitation
FAU_GEN.1 FPT_STM.1FAU_SEL.1
Audit
FIA_ATD.1 FMT_MTD.2FMT_MOF.1 FMT_MTD.3FMT_MSA.1 FMT_REV.1FMT_MSA.2 FMT_SMF.1FMT_MSA.3 FMT_SMR.1FMT_MTD.1
Security Management
Trusted Storage Trusted Boot Trusted Channel
FDP_DAU.1FDP_DAU.3_EXP
Data Authentication
FDP_SDI.1 FDP_RIP.2FDP_UIT.1 FDP_UCT.1
User DataIntegrity & Confidentiality
FPT_ITT.1 FPT_ITT.3FPT_ITI.1
TSF DataIntegrity & Confidentiality
FDP_DAU.3_EXP
Data Authentication
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
FDP_UIT.1 FDP_UCT.1
Data ExchangeIntegrity & Confidentiality
FPT_ITT.1 FPT_ITI.1
TSF DataIntegrity & Confidentiality
FTP_ITC.1 FPT_TDC.1
InterTSF Communication
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
A.HW_OKA.NO_TAMPERA.INTEGRITY_SUPPORTA.REMOTE_TRUST
A.HW_OKA.NO_TAMPERA.BIND
A.HW_OKA.NO_TAMPERA.NO_EVILA.SEPARATION_SUPPORT
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 30
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Security Functional RequirementsHASKPP
Core SecurityFunctionality
FDP_ACC.2 FDP_RIP.2FDP_ACF.1 FPT_TDC.1FDP_ETC.2 FIA_UAU.1FDP_IFC.2 FIA_UID.1FDP_IFF.1 FIA_UID.2FDP_ITC.2
Access Control &Information Flow Control
FRU_RSA.1
Resource Limitation
FAU_GEN.1 FPT_STM.1FAU_SEL.1
Audit
FIA_ATD.1 FMT_MTD.2FMT_MOF.1 FMT_MTD.3FMT_MSA.1 FMT_REV.1FMT_MSA.2 FMT_SMF.1FMT_MSA.3 FMT_SMR.1FMT_MTD.1
Security Management
Trusted Storage Trusted Boot Trusted Channel
FDP_DAU.1FDP_DAU.3_EXP
Data Authentication
FDP_SDI.1 FDP_RIP.2FDP_UIT.1 FDP_UCT.1
User DataIntegrity & Confidentiality
FPT_ITT.1 FPT_ITT.3FPT_ITI.1
TSF DataIntegrity & Confidentiality
FDP_DAU.3_EXP
Data Authentication
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
FDP_UIT.1 FDP_UCT.1
Data ExchangeIntegrity & Confidentiality
FPT_ITT.1 FPT_ITI.1
TSF DataIntegrity & Confidentiality
FTP_ITC.1 FPT_TDC.1
InterTSF Communication
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
A.HW_OKA.NO_TAMPERA.INTEGRITY_SUPPORTA.REMOTE_TRUST
A.HW_OKA.NO_TAMPERA.BIND
A.HW_OKA.NO_TAMPERA.NO_EVILA.SEPARATION_SUPPORT
Security functional requirements for TOE
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 31
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Security Functional RequirementsHASKPP
Core SecurityFunctionality
FDP_ACC.2 FDP_RIP.2FDP_ACF.1 FPT_TDC.1FDP_ETC.2 FIA_UAU.1FDP_IFC.2 FIA_UID.1FDP_IFF.1 FIA_UID.2FDP_ITC.2
Access Control &Information Flow Control
FRU_RSA.1
Resource Limitation
FAU_GEN.1 FPT_STM.1FAU_SEL.1
Audit
FIA_ATD.1 FMT_MTD.2FMT_MOF.1 FMT_MTD.3FMT_MSA.1 FMT_REV.1FMT_MSA.2 FMT_SMF.1FMT_MSA.3 FMT_SMR.1FMT_MTD.1
Security Management
Trusted Storage Trusted Boot Trusted Channel
FDP_DAU.1FDP_DAU.3_EXP
Data Authentication
FDP_SDI.1 FDP_RIP.2FDP_UIT.1 FDP_UCT.1
User DataIntegrity & Confidentiality
FPT_ITT.1 FPT_ITT.3FPT_ITI.1
TSF DataIntegrity & Confidentiality
FDP_DAU.3_EXP
Data Authentication
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
FDP_UIT.1 FDP_UCT.1
Data ExchangeIntegrity & Confidentiality
FPT_ITT.1 FPT_ITI.1
TSF DataIntegrity & Confidentiality
FTP_ITC.1 FPT_TDC.1
InterTSF Communication
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
A.HW_OKA.NO_TAMPERA.INTEGRITY_SUPPORTA.REMOTE_TRUST
A.HW_OKA.NO_TAMPERA.BIND
A.HW_OKA.NO_TAMPERA.NO_EVILA.SEPARATION_SUPPORT
Security functional requirements for TOE
Assumptions for TOE Environment
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 32
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Example: Modeling Trusted Boot
● Secure Boot:Always start in a valid state.If something is wrong, stop.
● Authenticated Boot:Securely store measurement results and start system in any case. I can verify later.
Trusted Boot
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
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)
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 33
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Assumptions for Trusted Boot
Trusted Boot
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
● A.INTEGRITY_SUPPORT:Manipulated security kernel cannot generate false evidence of its own integrity
● A.BIND:Possibility to store data an code such that 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)
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 34
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Security Func. Req's for Trusted Boot
Trusted Boot
FDP_DAU.3_EXP
Data Authentication
FPT_ITI.1 FMT_MTD.3FPT_TST.1
TSF Validation
A.HW_OKA.NO_TAMPERA.BINDA.INTEGRITY_SUPPORT
● Existing SFRs from Common Criteria:– FPT_ITI.1: detect modifications between shutdown and
startup– FPT_TST.1: run self tests when loading compartments
requiring integrity evidence– FMT_MTD.3: accept only secure values for memory
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 35
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 36
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 37
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 38
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Protection Profile Overview
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL1 EAL7)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
Protection Profile
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 39
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Trusted Computing in HASKPP
Target ofEvaluation
(TOE)
Security Problem Definition Threats Assumptions Organizational security policies
Conformance Claim
Security Objectives for TOE
Security Objectives for TOE Environment
Evaluation Assurance Level(EAL5)
SecurityAssuranceRequirements
SecurityFunctionalRequirements
HASK Protection Profile
Trusted Computing support (hardware)
Trusted Computing functionality in software
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 40
RuhR-University Bochum
Marcel Winandy
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
April 7, 2009Trusted Computing Support in HASK-PP (Trust 2009) 41
RuhR-University Bochum
Marcel Winandy
Chair for System Security
Questions?
HASKPP: Protection Profile for a High Assurance Security Kernel
http://www.sirrix.com/media/downloads/54500.pdf
Marcel WinandyRuhrUniversity Bochum
