Transcript 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
© 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
© 1999 SPYRUS
A Single Evaluation Standard

Customers want evaluation of products
against a common standard



Benefits vendors



Provides for fair comparison of competing products
Use of evaluated products shows due diligence
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?

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

(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
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
© 1999 SPYRUS
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
© 1999 SPYRUS
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
© 1999 SPYRUS
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
© 1999 SPYRUS
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
© 1999 SPYRUS
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
© 1999 SPYRUS
Level 1

Not resistant to any significant threat




(1 of 2)
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
Level 1

(2 of 2)
Minimal Functional Security Requirements











FAU_GEN.1
FAU_GEN.2
FAU_SAR.1
FAU_SAR.2
FAU_STG.1
FCO_NRO.1
FIA_AFL.1
FIA_UAU.2
FIA_UID.2
FMT_SMR.1
FPT_STM.1
Audit data generation
User identity association
Audit review
Restricted audit review
Protected audit trail storage
Selective proof of origin
Authentication failure handling
User authentication before any action
User identification before any action
Security roles
Reliable time stamps
© 1999 SPYRUS
Level 2

Resists some threats occurring over the
network




(1 of 2)
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
Level 2

(2 of 2)
Increased Functional Security Requirements

Additions to Level 1:










FAU_SEL.1
FDP_ACC.1
FDP_ACF.1
FDP_IFC.1
FDP_IFF.1
FDP_ITT.1
FDP_ITT.3
FMT_MSA.1
FMT_MTD.1
FPT_AMT.1
Selective audit
Subset access control
Security attribute based access control
Subset information flow control
Simple security attributes
Basic internal transfer protection
Integrity monitoring
Management of security attributes
Management of TSF data
Abstract machine testing
© 1999 SPYRUS
Level 3

Resists most threats occurring over the
network, and some threats from malicious
local users




(1 of 2)
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
Level 3

(2 of 2)
Increased Functional Security Requirements

Additions to Level 2:







FAU_SEL.1
FDP_RIP.1
FDP_SDI.1
FDP_DAU.1
FDP_ETC.1
FDP_ITC.1
FTP_TRP.1
Selective audit
Subset residual information protection
Stored data integrity monitoring
Basic data authentication
Export of user data without security attributes
Import of user data without security attributes
Trusted path
© 1999 SPYRUS
Level 4

Resists most threats occurring over the
network and from local users




(1 of 2)
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
Level 4

(2 of 2)
Stringent Functional Requirements

Increased from Level 3:

FDP_ACC.2





Subset information flow control
Full residual information protection
From FDP_RIP.1
FDP_SDI.2
Subset access control
Complete information flow control
From FDP_IFC.1
FDP_RIP.2


From FDP_ACC.1
FDP_IFC.2

Complete access control
Subset residual information protection
Stored data integrity monitoring and action
From FDP_SDI.1
Stored data integrity monitoring
Additions to Level 3:


FMT_MSA.2
FMT_MSA.3
Secure security attributes
Static attribute initialization
© 1999 SPYRUS
Assurance Packages

Based on CC Assurance Packages

Level 1: Low assurance




EAL-4
EAL-4 (no additions or subtractions)
Also recommend ADV_INT.1, Modularity
Level 4: Advanced assurance

EAL-3 -
All of EAL-3 except ALC_DVS.1,
Identification of Security Measures
Level 3: High assurance


EAL-1 plus ATE_FUN.1, Functional Testing
Level 2: Moderate assurance

EAL-1 +
All of EAL-6 except AVA_CCA.2,
Systematic Covert Channel Analysis
© 1999 SPYRUS
EAL-6 -
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
© 1999 SPYRUS
Future 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 Documents

Documents available at:

http://www.spyrus.com/documents/index.html
© 1999 SPYRUS
For more information
(408) 327-1901
Santa Clara, CA
[email protected]
http://www.spyrus.com
© 1999 SPYRUS