1 common criteria vulnerability analysis of cryptographic security mechanisms quang trinh/ james...

1

Common Criteria Common Criteria Vulnerability Analysis of Vulnerability Analysis of Cryptographic Security Cryptographic Security MechanismsMechanisms

Quang Trinh/Quang Trinh/

James ArnoldJames Arnold

26 September 2007

2

Topics

Introduction What is Common Criteria Vulnerability

Analysis? Vulnerability Analysis Approach for

Cryptographic Security Mechanisms FIPS Considerations Conclusions

3

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.

4

Introduction (cont)

• The CC leaves it to each evaluation scheme to provide guidance regarding the handling of strength of cryptographic mechanisms.

5

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.

6

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)

7

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.

8

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.

9

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

10

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.

11

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.

12

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

13


1. Breakdown the cryptographic mechanism into componentsa) Establishment of the cryptographic keys

b) Performing the cryptographic operations

c) Storage of the cryptographic keys and data

d) Destruction of cryptographic keys

14


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.

15


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

16


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

17


1d. Destruction of cryptographic keys– Keys are overwritten

– Keys are not overwritten

18


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

19


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.

20


3. Perform regular Common Criteria vulnerability analysis on the non-cryptographic components– Any potential vulnerabilities not related to cryptographic

strength are within scopeEstablishment 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)

21


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 crypto-analytical 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.

22


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.

23

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.

24

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.

25

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.

26

Contact

Quang TrinhSAIC Accredited Testing & Evaluation Labs

Common Criteria/FIPS Evaluator

[email protected]

James ArnoldSAIC Accredited Testing & Evaluation Labs

AVP/Technical Director

[email protected]

http://www.saic.com/infosec/common-criteria/

1 common criteria vulnerability analysis of cryptographic security mechanisms quang trinh/ james...

Documents

cryptographic strength

cc vulnerability analysis

lab analysis slide

cryptographic standards

vendor analysis verification

cryptographic hash check

basic ava

thirdparty analysis