PKE PPMike Henry

Santosh Chokhani

Jean PettyEntrust CygnaCom

Entrust CygnaCom

Briefing Contents

Common Criteria BackgroundGoals of PKE PPAssumptionsApproach in Constructing the PPSummary of PackagesPlanned Enhancements

Entrust CygnaCom

Common Criteria: Sponsors

Common to Various Nations: Only charter members shown

Entrust CygnaCom

Common Criteria: Key Concepts

Protection Profile (PP)• Specification of Security Requirements at what level• Implementation and product neutral

Security Target (ST)• Specification of Security Features at what and how level• Implementation and product specific

Target of Evaluation (TOE)ProductsEvaluated against ST

Entrust CygnaCom

Common Criteria Standard: Specification

Part 1IntroductionPP and ST Contents and Formats

Part 2: Security Functional Requirements Select from these for PP and/or ST Can extend the requirements

Part 3: Security Assurance Requirements Select from these for PP and/or ST Can extend the requirements

Entrust CygnaCom

Common Criteria Standards: Other Documents

Common Evaluation Methodology (CEM)• PP Evaluation Standard• ST Evaluation Standard• TOE Evaluation Standard

Guide to Writing PP and ST

Entrust CygnaCom

Common Criteria: Part 2 & Part 3 Hierarchy

……

Part 2 or 3

Class

……....

Family

….

……....

……....

Component

Element

Entrust CygnaCom

Common Criteria: Part 2 (functional) Classes

Audit Comm Crypto UserData Protection

I&A SecurityManagement

PrivacyTSF

Protection

ResourceUtilization

TOEAccess

TrustedPath

Entrust CygnaCom

Common Criteria: Part 3 (assurance) Classes

ConfigurationManagement

VulnerabilityAssessments

Delivery &Operation

GuidanceDocuments

Life-CycleSupport Tests

Development

Note: CC also packages assurance requirements in 7 hierarchicalpackages called Evaluation Assurance Levels (EAL)

Entrust CygnaCom

Common Criteria: PP Contents

Introduction TOE Description

Security Environment

AssumptionsThreats

Organizational Security Policies

Rationale

Security Objectives

drives

Security Requirements

drives

Security objectives for TOESecurity objectives for environment

FunctionalAssurance

Entrust CygnaCom

Common Criteria: Functional Package Contents

drives

Security objectives

Functional Security Requirements

Rationale

Entrust CygnaCom

Common Criteria: Evaluation Model

PP Evaluation (Internal)ST Evaluation

TOE Evaluation

(Internal; Against PPOptional)

(against ST)

Entrust CygnaCom

Project Goals

Develop a tool for security evaluation of broad range (all possible!!!) PKE applications in Marine Corps

– PKI based cryptographic services vary from application to application

– PKE toolkits have varying degree of functionality for certification path validation logic

Accommodate a variety of algorithms– DoD Class 3– Fortezza Class 4– KMI– Future enhancements

Entrust CygnaCom

Assumptions

Need to accommodate COTS products with varying degree of path validation capability

PKI based security mechanisms will vary from application to application

Provide ability to evaluate OCSP and CRL Extend the CC for certification path validation and

other items– Access control components are not appropriate for

certification path validation– Existing CC components not appropriate for CRL and

OCSP response processing

Entrust CygnaCom

Challenge: Balancing Act

Product RealitiesCurrent Implementations

Variety of Solutions

Planned EnhancementsSecurity

Optional Features

Entrust CygnaCom

Challenge: Requirements and Capability

Increasing Security, Functionality, etc.

Examples:

No trust anchor processing……………………….Full trust anchor processingNo policy processing……………………………….Full policy processing

Entrust CygnaCom

Solutions

Use functional packages as neededExample: Policy processing

Use “assignment” operation for SFR to provide

additional granularity (Example: trust anchor processing)

Entrust CygnaCom

Approach

Use functional packages to permit ST author to

select appropriate:– PKI based cryptographic mechanisms

– Certification path validation capability

– Revocation checking

Certification path validation rules– Non-procedural

– Attempt to preserve X.509 input, processing, output

– Policy calculation all in “output”

Entrust CygnaCom

Approach: Environmental Assumptions

Cryptographic Module• Protects private keys• May protect trust anchors• Performs cryptography

Secure Computing and OS• Protects keys and data• Provides audit capability• Protects audit logs• Optional

Entrust CygnaCom

Approach

Use mandatory functional package for PKI

Credentials– Required to accommodate cases where cryptographic

module does not manage trust anchors

– Can be met by application, or

environment

– OS, or

– Cryptographic module

Entrust CygnaCom

Approach

PKI Cryptographic Functional Packages

Path Validation Engine

Public Key Based Cryptographic Services

• Encryption• Authentication• Integrity

Association

Need for

Entrust CygnaCom

Approach: Handling Lack of Current Revocation Information

Ability to specify acceptance of certification

path in case of no revocation information or

old revocation information– Past experience shows that flexibility may be

needed to provide: Configurability

User interaction

Entrust CygnaCom

Functional Packages: Certificate and CRL

Path Validation• Select one from four hierarchical• Selection based on product capability

CRL Processing

OCSP Response Processing

Basic

Full

Full PolicyBasic Policy

Entrust CygnaCom

Functional Packages: Cryptography Related

Sign

Verify

Key Transfer Encryption

Key Transfer Decryption

Key AgreementEncryption

Key AgreementDecryption

PKI Based EntityAuthentication

PKI CredentialManagement

Entrust CygnaCom

Enhancements (made or being made)

PKI Based Entity Authentication Functional Package

Clean up some language and CC dependencies Add trust anchor processing as optional

– Neither X.509 nor PKIX require it– Match issuer and subject DN– Verify signature using subject public key and parameters

(if applicable)– Verify validity period

EKU application note may go away when MS makes changes

Entrust CygnaCom

Enhancements (made or being made)

Optional audit functional package– Optional because many applications may not

support auditing, e.g., e-mail client

– Will cover only PKE specific event

– Will also cover audit review and protection

– Some or all of the requirements may be satisfied by the environment

Entrust CygnaCom

Enhancements (future)

Delta CRL Partitioned CRL (??) Support for SCVP and/or OCSP v2 (??)

Entrust CygnaCom

Questions