Common Criteria Vulnerability Analysis of Cryptographic

Common Criteria
Vulnerability Analysis of
Cryptographic Security Mechanisms
Quang Trinh/
James Arnold
26 September 2007
1
Topics
 Introduction
 What is Common Criteria Vulnerability
Analysis?
 Vulnerability Analysis Approach for
Cryptographic Security Mechanisms
 FIPS Considerations
 Conclusions
2
Introduction
 Common Criteria (CC) version 3.1 specifies five
components, AVA_VAN.1 – AVA_VAN.5, with
increasing vigorous activity requirements based on
the presumed attack potential of attackers from Basic
to High.
–
–
–
–
Basic (AVA_VAN.1 and AVA_VAN.2)
Enhanced-Basic (AVA_VAN.3)
Moderate (AVA_VAN.4)
High (AVA_VAN.5)
 Crypto-analysis is hard and outside the scope of the
Common Criteria.
3
Introduction (cont)
• The CC leaves it to each evaluation scheme to
provide guidance regarding the handling of strength
of cryptographic mechanisms.
4
Introduction (cont)
• In Australian Scheme – Australasian Certification
Authority (ACA) requires that Defence Signals
Directorate (DSD) performs an internal and
independent evaluation of the cryptographic
mechanisms in parallel with the CC product
evaluation performed by the lab.
5
Introduction (cont)
 In the United States – Common Criteria Evaluation
and Validation Scheme (CCEVS): A policy has been
issued allowing that cryptographic mechanisms can
conform to cryptographic standards based on:
• FIPS certification (relied on third-party analysis)
• Vendor affirmed (relied on vendor analysis)
• Verification as part of the TOE evaluation (relied on the lab
analysis)
6
Introduction (cont)
 Problem: Cryptographic mechanisms are sometimes
all but ignored in the context of evaluations, despite
the fact that cryptographic mechanisms may have
elements that are not based in cryptographic strength.
7
Introduction (cont)
 This presentation is intended to identify aspects of
cryptographic mechanisms that may not be based on
cryptographic strength and, hence, are not outside
the scope of the Common Criteria.
 Appropriate and practical approach is offered; in
particular, for addressing cryptographic mechanisms
in the context of performing a vulnerability analysis in
accordance with the Common Criteria.
8
What is CC Vulnerability Analysis?
 In the context of the Common
Criteria, a vulnerability analysis is
an assessment activity to
determine the existence and
exploitability of flaws or
weaknesses in the target of
evaluation (TOE) in the
operational environment.
 The assurance level dictates the
effort and level of expertise spent
on searching for potential
vulnerabilities and performing
penetration test to ascertain if
they are exploitable.
EAL1
VLA_VAN.1
EAL2
EAL3
VLA_VAN.2
EAL4
VLA_VAN.3
EAL5
VLA_VAN.4
EAL6
EAL7
VLA_VAN.5
9
What is CC Vulnerability Analysis? (cont)
 Five generic types of vulnerabilities
– Bypass - With respect to cryptography, disabling the
encryption mechanism using hidden interface, invalid
inputs, or other mean is an example of bypassing the
security mechanism. Another example would be skipping
the cryptographic hash check or digital signature
verification.
– Tamper - With respect to cryptography, modifying the
configuration file so that the product utilized a weaker
encryption algorithm by default is tampering. Another
example would be overflowing the audit trail resulting
in a halt to the cryptographic operations.
10
What is CC Vulnerability Analysis? (cont)
– Misuse – With respect to cryptography, an administrator can
inadvertently stores cryptographic keys in an unprotected location.
Another example would be failure to describe a feature (e.g.,
enable super-user group, interfaces that provide no parameter
checks, etc.) that should be disabled can result in the administrator
accidentally enabling that feature.
– Direct attacks* - For example, if a cryptographic algorithm
utilizes a 48-bit key, then the evaluator can use brute force attack
to determine the key. Such method would not even require
knowledge of the underlying cryptographic algorithm. Another
example would be guessing the weak password that is used to
protect the cryptographic private key.
– Monitoring** - see below
* - Direct attacks reliant upon weakness in cryptographic algorithms (i.e., related to the notion of cryptographic strength) are excluded.
** - Monitoring includes covert channel and side channel attacks resulting in illicit information flow. Guidance for the conduct of covert
channel and side channel analysis should be sought from the evaluation authority. Due to the complex nature of the analysis, this
presentation will exclude monitoring from the scope of the vulnerability analysis.
11
Vulnerability Analysis for Cryptographic Mechanisms

Vulnerability Analysis Approach for Cryptographic Security
Mechanisms
1. Breakdown the cryptographic mechanism into components
2. Analyze each component in order to identify those aspects
based in cryptographic strength and those that are not
3. Perform regular Common Criteria vulnerability analysis any
aspects of each component not based in cryptographic
strength
4. Look for well-known or publicly accessible attacks and tools
in the public domain for each of the cryptographic
components
12
Vulnerability Analysis for Cryptographic Mechanisms
1. Breakdown the cryptographic mechanism into
components
a)
b)
c)
d)
Establishment of the cryptographic keys
Performing the cryptographic operations
Storage of the cryptographic keys and data
Destruction of cryptographic keys
13
Vulnerability Analysis for Cryptographic Mechanisms
1a. Establishment of the cryptographic keys
– Keys can be generated based on random number
generation (RNG)
– Keys can be established using Diffie-Hellman
– Keys can be imported (side channel)
– Keys can be sent using AES key wrap
– Keys can be hard-coded
– Keys can be generated based on user inputs, date and
time, passwords, etc.
14
Vulnerability Analysis for Cryptographic Mechanisms
1b. Performing the cryptographic operations
– Operation can be disabled or enabled
– Operation is performed transparently (no user action
required)
– Operation is not performed transparently (correct user
action required)
• Access to the cryptographic keys
• Data specified to be signed or encrypted
– Improper implementation
15
Vulnerability Analysis for Cryptographic Mechanisms
1c. Storage of the cryptographic keys and data
– Keys/data are stored encrypted
– Keys/data are stored in cleartext but access is
controlled
– Keys/data are stored in cleartext but location is
unknown
– Keys/data are stored in cleartext
16
Vulnerability Analysis for Cryptographic Mechanisms
1d. Destruction of cryptographic keys
– Keys are overwritten
– Keys are not overwritten
17
Vulnerability Analysis for Cryptographic Mechanisms
2. Analyze each component in order to identify
those aspects based in cryptographic
strength and those that are not
– Examine the design documents, perform source code
review, and ask the developer questions
– Determine which parts are based in cryptographic
strength
18
Vulnerability Analysis for Cryptographic Mechanisms
 Determine which parts are based in cryptographic
strength and which are not by asking these questions
• Establishment of the cryptographic keys
–
–
Can the cryptographic key be guessed or brute-forced?
Can the cryptographic key be intercepted during transmission?
• Performing the cryptographic operations
–
–
Can the cryptographic operation be disabled or interrupted?
Can the cryptographic operation be performed incorrectly by user?
• Storage of the cryptographic keys and data
–
Can the cryptographic key be accessed? Without decryption?
• Destruction of the cryptographic keys
–
Can the cryptographic key be accessed after being “destroyed?”
Note: the questions are not meant to be all inclusive .
19
Vulnerability Analysis for Cryptographic Mechanisms
3.
Perform regular Common Criteria vulnerability analysis on the
non-cryptographic components
– Any potential vulnerabilities not related to cryptographic
strength are within scope
Establishment of the cryptographic key
Simply guess keys or other attributes used in
cryptographic operations (Direct Attack)
Performing the cryptographic operations
.
Disable the encryption mode before or during the
operation (Bypass).
Attempt to misconfigure the security setting to use a
weaker algorithm or smaller key size (Misuse).
Storage of the cryptographic keys and data
Modify the cryptographic hash stored in memory
(Tampering)
Destruction of the cryptographic keys
Recover the keys from the disk after key destruction
operation (Bypass)
20
Vulnerability Analysis for Cryptographic Mechanisms
 Vulnerability analysis examples
– While the strength of the DES algorithm is out of
scope, the potential to simply brute-force the key within
the relatively small key range is within scope, since
trying all combination does not require any cryptoanalytical expertise.
– A cryptographic hash example which uses SHA-1 +
secret client ID to detect modification. The
determination of the ID will render this hash useless.
– Sensitive data are cached in page before encryption.
The page with data is freed by OS but not overwritten.
21
Vulnerability Analysis for Cryptographic Mechanisms
4. Look for well-known or publicly accessible attacks
and tools in the public domain for each of the
cryptographic components
–
Any tool that can be downloaded from the Internet that can
exploit a weakness in the cryptographic algorithms is fair
game.
•
•
–
–
For example, WEP password-cracking tool
Also, while the strength of MD5 is out of scope, the fact that a tool can
be readily obtained on the Internet and used to exploit applicable
mechanisms without performing any crypt-analysis is within scope.
The rationale is that using a tool requires no crypto-analysis
skills or even knowledge of the cryptographic algorithm.
Similarly, a well-documented attack is very similar to using a
tool, though the evaluator would need to account for any
additional expertise requirements.
22
FIPS Considerations
 The results of FIPS certifications should generally address
concerns related to the strength of cryptography mechanisms.
– If there is no FIPS or other third-party certification, then
perhaps the relative strength of the mechanism is in doubt.
 However, if a product developer utilizes a FIPS certified
cryptographic mechanism,
– the evaluation team should determine whether it is used in
accordance with its FIPS security policy and, if so,
– should be able to reference that evaluation as evidence to
address applicable aspects of their own evaluation.
•
For example, the FIPS evaluation may have already ensured that key
generation is done appropriately.
23
FIPS Considerations (cont)
 One important to note is that FIPS certificate does not address
non-Approved algorithms (Blowfish, RC4, MD5, etc.).
– If so, these algorithms should be examined as part of the VA
or disabled in the CC evaluated configuration.
 One other important thing is the fact that a cryptographic module
can have algorithms that are not certified.
– For example, a module can have both TDES and AES
where only AES has been certified (algorithm certificate
number #).
 The Vulnerability Analysis Approach for Cryptographic Security
Mechanisms should be applied.
24
Conclusions
 The evaluation teams should apply this or a similar
approach in order to ensure that all TOE security functions
are addressed to the extent possible and required by the
CC.
 It should be generally unacceptable to simply exclude a
cryptographic mechanism from analysis, since even
cryptographic mechanisms have aspects that are not
based on the strength of cryptography.
 It should, however, be acceptable to reference other
cryptographic certifications as they may pertain to aspects
of the CC evaluation so that work is not repeated
unnecessarily.
25
Contact
Quang Trinh
SAIC Accredited Testing & Evaluation Labs
Common Criteria/FIPS Evaluator
[email protected]
James Arnold
SAIC Accredited Testing & Evaluation Labs AVP/Technical
Director
[email protected]
http://www.saic.com/infosec/common-criteria/
26