Author: Jean-Pierre KRIMM
CESTI-LETI
Speaker: Axel BONESS
A FIPS 140-2 evaluation could
authorize CC-like tests
ICCC 2005 - TOKYO
CESTI-LETI - ICCC 2005 - TOKYO 2
2005 CESTI-LETI Presentation
A French ITSEF
A part of the LETI (CEA) in Grenoble
Accredited for electronic components and
their embedded software
Performs CC and ITSEC evaluation
CESTI-LETI - ICCC 2005 - TOKYO 3
2005 Context
The World of the Smart Card evaluation:Common Criteria
time spent on specific vulnerability assessment
FIPS 140-2mainly conformance tests
The Common Criteria and FIPS 140-2 are different
abstractness
focus of tests (conformance vs evaluation)
Is this difference due to a particular interpretation ?
CESTI-LETI - ICCC 2005 - TOKYO 4
2005 Presentation Outline
CC evaluation vs FIPS 140-2 validationgeneral presentation
physical security testing
philosophy of tests
Vulnerability assessment in a FIPS 140-2 evaluation: Problems / Solutions
In Practice: a Feasibility Study
The Standard ISO/19790
CESTI-LETI - ICCC 2005 - TOKYO 5
2005 CC Evaluation vs FIPS 140-2 Validation
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
CESTI-LETI - ICCC 2005 - TOKYO 6
2005 Actors
CC Evaluation
Certification Bodies (Certification)
ITSEF (Testing Lab)
Sponsor and Developer
FIPS 140-2 Validation
NIST/CSE (Validate tested cryptographic modules)
CAVP and CMVP (FIPS Approved Algo and
Certification)
CMT Lab (Testing Lab)
Vendor
CESTI-LETI - ICCC 2005 - TOKYO 7
2005 CC Evaluation vs FIPS 140-2 Validation
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
CESTI-LETI - ICCC 2005 - TOKYO 8
2005 Laboratories
ITSEF (CC)
Accredited in each National Scheme by CB
In the French Scheme
COFRAC Accreditation
DCSSI Licensing (either Soft or Hard + ES)
CMT Lab (FIPS 140-2)
Cryptographic Module Testing Laboratories
Accredited by National Voluntary Laboratory
Accreditation Program (NVLAP)
US, Canada and UK
CESTI-LETI - ICCC 2005 - TOKYO 9
2005 CC Evaluation vs FIPS 140-2 Validation
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 10
2005 CC Evaluation vs FIPS 140-2 Validation
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 11
2005 Product under Evaluation
Target Of Evaluation (CC)
An IT product or system and its associated
guidance documentation that is the subject of an
evaluation
Set of hardware, and/or software, and/or firmware
Cryptographic Module (FIPS 140-2)
Set of hardware, and/or software, and/or firmware
Implements a cryptographic algorithm
Contained within a defined boundary
CESTI-LETI - ICCC 2005 - TOKYO 12
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 13
2005 Applicability
IT Product Certified (CC)
French Banking Application
All Software and Hardware which need Security Assurance
Cryptographic Modules Certified (FIPS 140-2)
U.S. Federal organizations must use validated
cryptographic modules
Government of Canada departments are recommended by
CSE to use validated cryptographic modules
Everyone who needs guaranty on standard implementation
CESTI-LETI - ICCC 2005 - TOKYO 14
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
FIPS 140-2CC
Security PolicySecurity TargetDescription
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 15
2005 Product Description
Security Target (CC)Assets and Assumptions
Threats on the Assets
Security Objectives which counter Threats
Security Functional Requirements
Cryptographic Module Security PolicySecurity rules
Roles, Services and Crypto Keys and CSPs
Security Policies (I&A, Access Control, …)
CESTI-LETI - ICCC 2005 - TOKYO 16
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
4 Security Levels7 EALsSecurity Levels
FIPS 140-2CC
Security PolicySecurity TargetDescription
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 17
2005 CC Security Levels
EAL 7
EAL 6
EAL 5
EAL 4
EAL 3
EAL 2
EAL 1
CC
Hierarchically Ordered EAL
each EAL represents more
assurance than all lower EALs
Based on pre-defined assurance
scale
Can be customized
(augmentation)
CESTI-LETI - ICCC 2005 - TOKYO 18
2005 FIPS 140-2 Security Levels
Level 1 is the lowest, Level 4 most stringent
Requirements are primarily cumulative by level
Overall rating is lowest rating in all sections
No customisation allowed
Not Validated
Level
1
Level
2
Level
3
Level
4
Security Spectrum
CESTI-LETI - ICCC 2005 - TOKYO 19
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
4 Security Levels7 EALsSecurity Levels
FIPS 140-2CC
DTRCEMMethodology
Security PolicySecurity TargetDescription
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 20
2005 Methodology
CEM (CC)
CC requirements are refined to Work-Units
Up to EAL 5
Derived Test Requirements (FIPS 140-2)
FIPS 140-2 requirements are refined to Vendor
and Tester Requirements
For all Security Levels
CESTI-LETI - ICCC 2005 - TOKYO 21
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
4 Security Levels7 EALsSecurity Levels
FIPS 140-2CC
ValidationEvaluationPhilosophy
DTRCEMMethodology
Security PolicySecurity TargetDescription
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 22
2005 Philosophy
Evaluation (CC)
Specific Security Assurance Requirements for
Vulnerability Analysis
Penetration Testing through AVA_VLA
Functional vulnerability through ATE_IND
A quotation table exists (cf. JIL for Smart Card)
Validation (FIPS 140-2)
Conformance testing of Cryptographic Module
It is not an evaluation (NO VLA, …)
CESTI-LETI - ICCC 2005 - TOKYO 23
2005 CC Evaluation vs FIPS 140-2 Validation
US and Canadian OrganizationAllApplicability
CMT Lab (NVLAP)ITSEF (CB in each scheme)Laboratories
CMVP, CAVP
CMT Lab
CB
ITSEF
Actors
4 Security Levels7 EALsSecurity Levels
FIPS 140-2CC
Security AreasSARTester Tasks
ValidationEvaluationPhilosophy
DTRCEMMethodology
Security PolicySecurity TargetDescription
Cryptographic ModuleTarget Of EvaluationProduct
Crypto algo validation (CAVP)NonePrerequisite
CESTI-LETI - ICCC 2005 - TOKYO 24
2005 Security Assurance Requirements (CC)
Choose a level of component in following Class
Security Target Evaluation (ASE)
Configuration Management (ACM)
Delivery and Operation (ADO)
Development (ADV)
Guidance Documents (AGD)
Life Cycle Support (ALC)
Tests (ATE)
Vulnerability Assessment (AVA)
CESTI-LETI - ICCC 2005 - TOKYO 25
2005 FIPS 140-2 Security Areas
Cryptographic Module Specification
Cryptographic Module Ports and Interfaces
Roles, Services, and Authentication
Finite State Model
Physical Security
Operational Environment
Cryptographic Key Management
EMI/EMC requirements
Self Tests
Design Assurance
Mitigation of Other Attacks
CESTI-LETI - ICCC 2005 - TOKYO 26
2005 Possible interpretations
a DTR statement is incomplete"Attempt to access (by circumventing the documented protection mechanisms) [...]"
in tester requirements TE03.22.02 and TE07.01.02
2 interpretationsUsing Only: External Interfaces of the Module (Functional Means)
Or going further: Performing Environmental and Physical Testing
CESTI-LETI - ICCC 2005 - TOKYO 27
2005 Environmental and Physical testing
Environmental Testing could beclassical perturbation of commands
timing attack during a calculation
SPA, EMA, DPA, DFA attacks
more to come…
Physical Testing could beprobing
reverse engineering
and so on…
CESTI-LETI - ICCC 2005 - TOKYO 28
2005 Problems and Proposals
Identified Problems
How to quote the attacks ?
How to know if the attack leads to a fail verdict ?
Which quotation for each security level ?
Proposals
Use the CC Smart Card Quotation Table
Map VLA.1 to level 3, VLA.2 to level 4
Allow augmentations to other levels (VLA.3…)
CESTI-LETI - ICCC 2005 - TOKYO 29
2005 A Quotation Table Exists (JIL)Factors Identification Exploitation
Elapsed time
< one hour 0 0
< one day 1 3
< one week 2 4
< one month 3 6
> one month 5 8
Not practical * *
Expertise
Layman 0 0
Proficient 2 2
Expert 5 4
Knowledge of the TOE
Public 0 0
Restricted 2 2
Sensitive 4 3
Critical 6 5
Access to TOE
< 10 samples 0 0
< 100 samples 2 4
> 100 samples 3 6
Not practical * *
Equipment
None 0 0
Standard 1 2
Specialized 3 4
Bespoke 5 6
Range of
values
Resistance to
attacker with attack
potential of:
SOF
rating
0-15 No rating No rating
16-24 Low Basic
25-30 Moderate Medium
31 and above High High
CESTI-LETI - ICCC 2005 - TOKYO 30
2005 A Feasibility Study
Outside FIPS applicability contextEMI/EMC does not apply
"FIPS Approved" has been re-defined
Performed by the CESTI-LETIQ4 2004 - Q1 2005
Sponsored by the DCSSI
The Cryptographic Module = an already certified Java Card FIPS 140-2 level 3
Two PhasesFIPS 140-2 evaluation (adapted security areas)
Capitalisation reports (general, methodology and process)
CESTI-LETI - ICCC 2005 - TOKYO 31
2005 ISO/19790
DCSSI is involved in ISO/19790 standard
The Context of the Feasibility Study Applies
Methodology Report of the Feasibility Study has been used as input
DCSSI proposition is to include some vulnerability assessment analysis and testing
CESTI-LETI - ICCC 2005 - TOKYO 32
2005 Conclusion
CC evaluation and FIPS 140-2 validation are
different but:
We can introduce vulnerability assessment
analysis on Cryptographic Modules
We can use the same Quotation Table
This can lead to a common scheme for the
penetration testing allowing some comparisons
Thank you for your attention
Any questions ?
Speaker: Axel Boness
Author: Jean-Pierre Krimm