1 / 24

Common Criteria Protection Profiles for PKI Products

Common Criteria Protection Profiles for PKI Products. Eric Rosenfeld SPYRUS 8 November 1999 CACR Information Security Workshop Third-Party Evaluation Criteria. SPYRUS Project Goal.

mika
Download Presentation

Common Criteria Protection Profiles for PKI Products

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Criteria Protection Profiles for PKI Products Eric Rosenfeld SPYRUS 8 November 1999 CACR Information Security Workshop Third-Party Evaluation Criteria

  2. SPYRUS Project Goal Develop a single security evaluation standard against which all major Certificate Issuing and Management System (CIMS) products and service implementations can be evaluated

  3. A Single Evaluation Standard • Customers want evaluation of products against a common standard • Provides for fair comparison of competing products • Use of evaluated products shows due diligence • Benefits vendors • Lets all compete on a level playing field • Should be usable to evaluate implementations of service providers • Evaluations against “custom criteria” defined in Security Targets (STs) do not allow comparison of “apples to apples”

  4. Why Use Protection Profiles? • Common Criteria (CC) or Blank Sheet of Paper • CC gaining acceptance • CC is flexible enough to cover most PKI issues • Other CC work in PKI area: • Cloud Cover PPs (UK) • SPYRUS PP (Australia) • Entrust STs (US, UK, & Canada) • NIST security requirements (US) • Protection Profiles (PPs) offer best unbiased description of a technology family

  5. PP Scope Decisions (1 of 4) • Functions of a CIMS: • Required: • Registration • Initialization • Certification • Revocation • Optional (although many products implement): • Key generation • Key update • Cross-certification • Certificate revocation notice distribution/publication • Certificate usage

  6. PP Scope Decisions (2 of 4) • System versus Component • A Registration Authority is responsible for assisting in the registration process • How the CIMS functions are divided is left up to the developer of a given CIMS product • For example, key generation may be done by the CA or the RA • The PPs do not reject any partitioning of CIMS functions which result in the security requirements being met • Approach: CA system, because separate CA and RA profiles are not meaningful

  7. PP Scope Decisions (3 of 4) • Operating System and Hardware: In or Out of Target Of Evaluation (TOE)? • Traditionally, TOE included the OS and hardware • This can increase the cost of an evaluation • Use of products developed by other companies means that evaluators may not have access to the required evidence • Approach: Define required OS and hardware features as part of Security Environment/Security Assumptions • Evaluators determine that OS provides required features, by • Reference to an existing evaluation of the OS, or • By examining the required OS features themselves

  8. PP Scope Decisions (4 of 4) • How to Handle Cryptography • CC sections on Cryptography are insufficient • Approach: • Cryptographic module outside of TOE; must be evaluated against FIPS 140-1 or equivalent standard • This allows vendors to get a single evaluation that is covered by the Mutual Recognition Agreement • Cryptographic modules can then be evaluated in each country using the relevant standards • Potentially some cryptographic functions in TOE (e.g., key distribution) • Have to fit in some CC requirements for these functions

  9. Threats • Threat categories: • Threats from the CA • Threats from privileged users of the system (System Administrator) • Threats from the RA • Threats from “incidental bystanders” • Threats from attackers on the network • Threats from malicious subscribers • Threats from developers

  10. IT Security Objectives • IT Security objectives for the TOE and/or its platform: • Identification/Authentication of users • Control of access to CIMS resources • Audit • Object reuse/residual information • Correct operation • TOE health checks • Data confidentiality • Data integrity

  11. SPYRUS Approach • Protection Profiles for Four Levels of Products • Modeled after FIPS 140-1 structure • Increasing Functionality and Assurance Requirements • Designed to meet increasing levels of threat • Level 1: resists no/minimal threats by itself • Level 2: resists some threats over network • Level 3: resists most network threats; some threats from malicious local users • Level 4: resists most threats from network and local users

  12. Level 1 (1 of 2) • Not resistant to any significant threat • Relies entirely on its Operating System and Environment for protection • FIPS 140-1 level 1 cryptographic module • Relatively easy to achieve by developers who document their processes and procedures • Evaluation should be quick, easy, and inexpensive

  13. Level 1 (2 of 2) • Minimal Functional Security Requirements • FAU_GEN.1 Audit data generation • FAU_GEN.2 User identity association • FAU_SAR.1 Audit review • FAU_SAR.2 Restricted audit review • FAU_STG.1 Protected audit trail storage • FCO_NRO.1 Selective proof of origin • FIA_AFL.1 Authentication failure handling • FIA_UAU.2 User authentication before any action • FIA_UID.2 User identification before any action • FMT_SMR.1 Security roles • FPT_STM.1 Reliable time stamps

  14. Level 2 (1 of 2) • Resists some threats occurring over the network • Relies on its OS and Environment for protection from all local threats • FIPS 140-1 level 2 cryptographic module • Achievable by developers today, but with some additional effort • Evaluations should be relatively quick and relatively inexpensive

  15. Level 2 (2 of 2) • Increased Functional Security Requirements • Additions to Level 1: • FAU_SEL.1 Selective audit • FDP_ACC.1 Subset access control • FDP_ACF.1 Security attribute based access control • FDP_IFC.1 Subset information flow control • FDP_IFF.1 Simple security attributes • FDP_ITT.1 Basic internal transfer protection • FDP_ITT.3 Integrity monitoring • FMT_MSA.1 Management of security attributes • FMT_MTD.1 Management of TSF data • FPT_AMT.1 Abstract machine testing

  16. Level 3 (1 of 2) • Resists most threats occurring over the network, and some threats from malicious local users • Relies on OS and Environment for protection from rest of the local threats • FIPS 140-1 level 2 cryptographic module • Difficult today, but achievable in high assurance development environments • Evaluation should be straightforward, but will be more time consuming and more expensive

  17. Level 3 (2 of 2) • Increased Functional Security Requirements • Additions to Level 2: • FAU_SEL.1 Selective audit • FDP_RIP.1 Subset residual information protection • FDP_SDI.1 Stored data integrity monitoring • FDP_DAU.1 Basic data authentication • FDP_ETC.1 Export of user data without security attributes • FDP_ITC.1 Import of user data without security attributes • FTP_TRP.1 Trusted path

  18. Level 4 (1 of 2) • Resists most threats occurring over the network and from local users • Minimal reliance on OS and Environment for protection from local threats • FIPS 140-1 level 3 cryptographic module • Stretch level; probably not achievable today, but may be achievable within five years • Evaluation will be complicated, will take many months, and cost a significant amount

  19. Level 4 (2 of 2) • Stringent Functional Requirements • Increased from Level 3: • FDP_ACC.2 Complete access control • From FDP_ACC.1 Subset access control • FDP_IFC.2 Complete information flow control • From FDP_IFC.1 Subset information flow control • FDP_RIP.2 Full residual information protection • From FDP_RIP.1 Subset residual information protection • FDP_SDI.2 Stored data integrity monitoring and action • From FDP_SDI.1 Stored data integrity monitoring • Additions to Level 3: • FMT_MSA.2 Secure security attributes • FMT_MSA.3 Static attribute initialization

  20. Assurance Packages • Based on CC Assurance Packages • Level 1: Low assurance EAL-1 + • EAL-1 plus ATE_FUN.1, Functional Testing • Level 2: Moderate assurance EAL-3 - • All of EAL-3 except ALC_DVS.1, Identification of Security Measures • Level 3: High assurance EAL-4 • EAL-4 (no additions or subtractions) • Also recommend ADV_INT.1, Modularity • Level 4: Advanced assurance EAL-6 - • All of EAL-6 except AVA_CCA.2, Systematic Covert Channel Analysis

  21. Status • Second draft of PPs completed 15 March 99 • Sent for review to interested parties: • Microsoft • SAIC • Entrust • NIST • NSA • Interaction and feedback • Comments generally positive

  22. Future Plans • Proposing an ANSI X9 New Work Item • Register PPs with NIAP (NIST/NSA) once registration process is developed • Gain international acceptance

  23. Getting the Documents • Documents available at: • http://www.spyrus.com/documents/index.html

  24. For more information (408) 327-1901Santa Clara, CA info@spyrus.com http://www.spyrus.com

More Related