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

© 1999 SPYRUS

Common Criteria Protection Common Criteria Protection Profiles for PKI ProductsProfiles for PKI Products

Eric RosenfeldEric Rosenfeld

SPYRUSSPYRUS

8 November 19998 November 1999CACR Information Security WorkshopCACR Information Security Workshop

Third-Party Evaluation CriteriaThird-Party Evaluation Criteria

© 1999 SPYRUS

SPYRUSSPYRUS Project Goal 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

© 1999 SPYRUS

A Single Evaluation StandardA 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”

© 1999 SPYRUS

Why Use Protection Profiles?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

© 1999 SPYRUS

PP Scope Decisions PP Scope Decisions (1 of 4)(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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS

ThreatsThreats

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

© 1999 SPYRUS

IT Security ObjectivesIT 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

© 1999 SPYRUS

SPYRUSSPYRUS Approach 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

© 1999 SPYRUS

Level 1 Level 1 (1 of 2)(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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS


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

© 1999 SPYRUS

Assurance PackagesAssurance 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

© 1999 SPYRUS

StatusStatus

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

© 1999 SPYRUS

Future PlansFuture Plans

Proposing an ANSI X9 New Work Item Register PPs with NIAP (NIST/NSA) once

registration process is developed Gain international acceptance

© 1999 SPYRUS

Getting the DocumentsGetting the Documents

Documents available at: http://www.spyrus.com/documents/index.html

© 1999 SPYRUS

For more informationFor more information

(408) 327-1901(408) 327-1901Santa Clara, CASanta Clara, CA

[email protected]@spyrus.com

http://www.spyrus.comhttp://www.spyrus.com