Quang Trinh/ James Arnold 26 September 2007

1. Common Criteria Vulnerability Analysis of Cryptographic Security Mechanisms Quang Trinh/ James 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.

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 • Breakdown the cryptographic mechanism into components • Analyze each component in order to identify those aspects based in cryptographic strength and those that are not • Perform regular Common Criteria vulnerability analysis any aspects of each component not based in cryptographic strength • Look for well-known or publicly accessible attacks and tools in the public domain for each of the cryptographic components

13. Vulnerability Analysis for Cryptographic Mechanisms • Breakdown the cryptographic mechanism into components • Establishment of the cryptographic keys • Performing the cryptographic operations • Storage of the cryptographic keys and data • Destruction of cryptographic keys

14. 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.

15. 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

16. 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

17. Vulnerability Analysis for Cryptographic Mechanisms 1d. Destruction of cryptographic keys • Keys are overwritten • Keys are not overwritten

18. Vulnerability Analysis for Cryptographic Mechanisms • 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. 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.

20. Vulnerability Analysis for Cryptographic Mechanisms • Perform regular Common Criteria vulnerability analysis on the non-cryptographic components • Any potential vulnerabilities not related to cryptographic strength are within scope

21. 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 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. Vulnerability Analysis for Cryptographic Mechanisms • 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 Trinh SAIC Accredited Testing & Evaluation Labs Common Criteria/FIPS Evaluator Quang.M.Trinh@saic.com James Arnold SAIC Accredited Testing & Evaluation Labs AVP/Technical Director James.L.Arnold.Jr@saic.com http://www.saic.com/infosec/common-criteria/