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

2. © 1999 SPYRUS 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. © 1999 SPYRUS A Single Evaluation Standard F Customers want evaluation of products against a common standard ú Provides for fair comparison of competing products ú Use of evaluated products shows due diligence F Benefits vendors ú Lets all compete on a level playing field ú Should be usable to evaluate implementations of service providers F Evaluations against “custom criteria” defined in Security Targets (STs) do not allow comparison of “apples to apples”

4. © 1999 SPYRUS Why Use Protection Profiles? F 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: l Cloud Cover PPs (UK) SPYRUS PP (Australia) l Entrust STs (US, UK, & Canada) l NIST security requirements (US) F Protection Profiles (PPs) offer best unbiased description of a technology family

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

6. © 1999 SPYRUS PP Scope Decisions (2 of 4) F 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 l For example, key generation may be done by the CA or the RA l 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. © 1999 SPYRUS PP Scope Decisions (3 of 4) F Operating System and Hardware: In or Out of Target Of Evaluation (TOE)? ú Traditionally, TOE included the OS and hardware l This can increase the cost of an evaluation l 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 l Reference to an existing evaluation of the OS, or l By examining the required OS features themselves

8. © 1999 SPYRUS PP Scope Decisions (4 of 4) F How to Handle Cryptography ú CC sections on Cryptography are insufficient ú Approach: l 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 l Potentially some cryptographic functions in TOE (e.g., key distribution) l Have to fit in some CC requirements for these functions

9. © 1999 SPYRUS Threats F 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. © 1999 SPYRUS IT Security Objectives F 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. © 1999 SPYRUS SPYRUS Approach F 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 l Level 1: resists no/minimal threats by itself l Level 2: resists some threats over network l Level 3: resists most network threats; some threats from malicious local users l Level 4: resists most threats from network and local users

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

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

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

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

16. © 1999 SPYRUS Level 3 (1 of 2) F 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 F FIPS 140-1 level 2 cryptographic module F Difficult today, but achievable in high assurance development environments F Evaluation should be straightforward, but will be more time consuming and more expensive

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

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

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

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

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

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

23. © 1999 SPYRUS Getting the Documents F Documents available at:  http:// www.spyrus.com/documents/index.html

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