Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Common Criteria & FIPS 140-2
Fine tuning a CC evaluation in
concurrence with a SFIPS 140-2 validation
&
General Issues
Agenda
o How are the CC
o How is the FIPS 140-2
FIPS 140-2 & CC differences
Handshake FIPS – CC: a convergence modelHandshake FIPS CC: a convergence model
Conclusions
8/30/2009 210 ICCC Norway
Common Criteria
General Issues
o the compliance with the std. is not the
aim itself;
o is a mean to obtain secure products.
FIPS 140-2
o conformance to the standard.
8/30/2009 310 ICCC Norway
We can offer confidence degrees in the
General Issues
We can offer confidence degrees in the
security of a product
How to obtain this confidence?
Security Evaluation.
Conformance Testing.
8/30/2009 410 ICCC Norway
How are the Common Criteria
General Issues
Functionality
Defines the CM security characteristics.
Assurance
C fid d i th f t f
8/30/2009 510 ICCC Norway
Confidence degree in the enforcement of
the security requirements Correctness &
Effectiveness
How is the FIPS 140-2 (I)
General Issues
Security requirements that must be
satisfied by a CM design & implementation
Approved security functions
o cryptographic algorithms
8/30/2009 610 ICCC Norway
o cryptographic key management
o authentication
How is the FIPS 140-2 (II)
General Issues
Assurance: correct implementation &
approved algorithms validation
Four Security Levels (1-4).
Functionality & Assurance go together
8/30/2009 710 ICCC Norway
within the SL hierarchy.
SL are independent of algorithms
validation
How is the FIPS 140-2 (III)
General Issues
CM Specification
CM Port and Interfaces
Roles, Services & Auth.
Finite State Model
Ph i l S it
Operational Environment
Crypto-Key Management
EMI/EMC
Self-Tests
D i A
•8/30/2009 88/30/2009 810 ICCC Norway
Physical Security Design Assurance
Mitigation of Other Attacks
SECURITY POLICY
How is the FIPS 140-2 (IV)
General Issues
Three types of physical embodiments:
o Single-chip
o Multiple-chip Embedded
M lti l hi St d l
•8/30/2009 9
o Multiple-chip Standalone
8/30/2009 910 ICCC Norway
FIPS 140-2 & CC differences
Assurance & Functionality
CC- EAL
o assurance requirements
o independent from functionality
FIPS 140-2 – SL
•8/30/2009 108/30/2009 1010 ICCC Norway
FIPS 140-2 – SL
o functional areas
o related to functionality & assurance
FIPS 140-2 & CC differences
CC- security evaluation
o a security problem is to be resolved.
o penetration tests to determine the
resistance level to attacks
FIPS 140-2 – conformance testing
•8/30/2009 118/30/2009 1110 ICCC Norway
o states a set of security requirements
that are to be fulfilled when developing
a CM
FIPS 140-2 & CC differences
Specific Documentation
CC
o ST, ADV_ARC, ALC_(LCD, DVS, FLR)
FIPS 140-2
o Security Policy EMI/EMC FSM
•8/30/2009 128/30/2009 1210 ICCC Norway
o Security Policy, EMI/EMC, FSM
FIPS 140-2 & CC differences
CC Physical requirements
TSF physical protection (FPT_PHP)
1 2
3
•8/30/2009 138/30/2009 1310 ICCC Norway
FPT_PHP.1 Passive detection of physical attack
FPT_PHP.2 Notification of physical attack
FPT_PHP.3 Resistance to physical attack
FIPS 140-2 & CC differences
FIPS 140-2 Physical requirements
•8/30/2009 148/30/2009 1410 ICCC Norway
Handshake FIPS 140-2 – CC
Cross – references
CC FIPS 140-2
o FCS reqs. claim FIPS compliance
o FIPS External devices in some PP
FIPS 140-2 CC
•8/30/2009 158/30/2009 1510 ICCC Norway
FIPS 140-2 CC
o Operating System from Operational
Environment shall be CC certified
Handshake FIPS 140-33 – CC
Non-invasive attacks.
Side channels: Retrieving secrets through
non-invasive methods
o Timing analysis
o SPA, DPA
•8/30/2009 168/30/2009 1610 ICCC Norway
o SEMA, DEMA
The CM shall be pen-tested for mitigation
these attacks
The model
Docs
FIPS 140-2
Conform.
Testing
CC
Security
Evaluation
PenTest
Site Visit
Testing
Code Inspect
ion
Alg Val
FSM
•8/30/2009 178/30/2009 1710 ICCC Norway
DepthT. EMI
The model
CM security target: SPD
ThThreats
o assets: user information & CSPs
o attacks:
• compromise of sensitive information,
•8/30/2009 188/30/2009 1810 ICCC Norway
• integrity of the executable code,
• physical tampering and perturbations,
• information leakage through side channels
The model
CM security target: SPD
Organizational Policies
o roles
o access control policies
o audit policies
•8/30/2009 198/30/2009 1910 ICCC Norway
o audit policies
Assumptions
The model
CM security target: CM Security objectives
o Protect user information for CIo Protect user information for CI
o I&A of users
o Roles & Access control policy for services
o Audit generation
K t
•8/30/2009 208/30/2009 2010 ICCC Norway
o Key management
o Self tests
o Physical protection & (info leakage prevention)
The model
CM security target: SFRs (I)
•8/30/2009 218/30/2009 2110 ICCC Norway
The model
CM security target: SFRs (II)
•8/30/2009 228/30/2009 2210 ICCC Norway
The model
CM security target: SFRs (III)
•8/30/2009 238/30/2009 2310 ICCC Norway
The model
CM security target: SFRs (IV)
•8/30/2009 248/30/2009 2410 ICCC Norway
The model Developers Evidences
FSP
HLD
LLD
ST
Sec. Interfaces
Subsystems
SECPOL
CM specification
CM ports and interfaces
R l i d th
CC FIPS
Sources/ Hw
drawings
User manual
Instalation manual
Testing
documentation (*)
T&T
Delivery procedures
Modules
Source / HW drawings
Operational guidance
Preparation guidance
Testing documentation
Live cycle
T&T
D li d
Roles, services, and auth.
Finite state model
LLD (HW/SW)
Sources / HW drawings
Operational environment
Cryptographic key management
EMI/EMC
Self-tests
CIs list
Configuration
management
Delivery procedures
Developers security
FLR
CIs list
Config. Management
Security Architecture
Manuals
DEV – programming language
Delivery & Operacion
Configurationmanagement.
CIs list
Mitigation of other attacks
Physical security
Security Mechanisms
(*) Developers do not deliver testing documentation in FIPS validation
The model
Testing the CM
•8/30/2009 268/30/2009 2610 ICCC Norway
The model
Vulnerability analysis & Penetration Tests
CC exclusive activityCC exclusive activity.
Some CC pentest results could be reused:
o anti-tamper enclosures checking
o role based access control bypassing
•8/30/2009 278/30/2009 2710 ICCC Norway
o I&A bypassing
FIPS 140-3 Non intrusive attacks.
The model
Two certs schedulingTwo certs scheduling
•8/30/2009 288/30/2009 2810 ICCC Norway
Conclusions
CC security evaluations & FIPS 140-2
validations common points allow offering thep g
developers a simultaneous process for
certifying their CMs.
FIPS requirements can be expressed as SFRs
following the CC part2 catalogue.
F th d l
•8/30/2009 298/30/2009 2910 ICCC Norway
For the developer:
o Advantages: two certs & cost reduction
o Disadvantages: none.