Your SlideShare is downloading. ×
Modeling Trusted Computing Support in a Protection Profile for High Assurance Security Kernels
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Modeling Trusted Computing Support in a Protection Profile for High Assurance Security Kernels

396
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
396
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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, GermanyTrust 2009International Conference on the Technical and Socio­Economic Aspects of Trusted ComputingOxford, UK, 6­8 April 2009
  • 2. RuhR-University Bochum Chair for System Security Motivation ● Why do we need security kernels? – Standard OSs 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 systemsMarcel 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 dont cover important security aspectsMarcel 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 dont cover important security aspects Windows, Linux, Solaris, etc. LSPP CAPP RBAC­PPMarcel 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 dont cover important security aspects Windows, Linux, Solaris, etc. LSPP CAPP RBAC­PP Access ControlMarcel 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 dont cover important security aspects Windows, Linux, Solaris, etc. Separation Kernels LSPP CAPP SKPP RBAC­PP Access ControlMarcel 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 dont cover important security aspects Windows, Linux, Solaris, etc. Separation Kernels LSPP CAPP SKPP RBAC­PP Access Control Isolated ExecutionMarcel 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 dont 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 ExecutionMarcel 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­PPMarcel 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 complianceMarcel 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 ProfileMarcel 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 ProductMarcel 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 TargetMarcel 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 EvaluationMarcel 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 CertificationMarcel 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 CertificationMarcel 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 sectorsMarcel 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 ProfileMarcel 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 ProfileMarcel 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 environmentMarcel 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 administratorMarcel 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 dataMarcel 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 ProfileMarcel 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 ProfileMarcel 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 ProfileMarcel 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 ProfileMarcel 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_SUPPORTMarcel 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_SUPPORTMarcel 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_SUPPORTMarcel 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. Reqs 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 compartmentsMarcel 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 ProfileMarcel 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 ProfileMarcel 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.1Marcel 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 ProfileMarcel 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 softwareMarcel 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 EAL5Marcel 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.pdfMarcel Winandy Trusted Computing Support in HASK-PP (Trust 2009) April 7, 2009 41