1 / 35

Current practice in covering some aspects of cryptographic mechanisms in the CC context

Current practice in covering some aspects of cryptographic mechanisms in the CC context. Renato Menicocci, Vittorio Bagini, Franco Guida FUB-OCSI. 1. Introduction.

theodore-todd
Download Presentation

Current practice in covering some aspects of cryptographic mechanisms in the CC context

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Current practice in covering some aspects of cryptographic mechanisms in the CC context Renato Menicocci, Vittorio Bagini, Franco Guida FUB-OCSI

  2. 1. Introduction • Evaluated PPs and STs available on <www.commoncriteriaportal.org> have been analyzed to outline the current practice in taking care of selected aspects of cryptographic mechanisms • Aspect 1: Enforcement of selected cryptographic algorithms and/or key management techniques within FCS requirements • Aspect 2: Coverage of physical attacks based on side channelanalysis and/or fault analysis

  3. 2. Current practice for Aspect 1 • The enforcement of selected cryptographic algorithms and/or key management techniques • Is specified in SFRs of the FCSclass (usually, by appropriate operations such as assignment) • Is possibly determined by specific Security Objectives, which are in turn originated by specific Organizational Security Policies (OSPs)and/orThreats • Is usually specified by referring to external documents (e.g., standards and/or lists of approved algorithms)

  4. 3. Types of enforcement found • Enforcement not explicitly determined by Security Objectives (Type 0) • Enforcement explicitly determined by Security Objectives, in turn originated by • specific OSPs (Type 1) • specific Threats (Type 2) • a combination of specific OSPs and Threats (Type 3)

  5. 4. A Type 0 example • ST-Lite – MICARDO Tachograph Version 1.0 R1.0, 21-06-2006, BSI-DSZ-CC-0358 • In this ST • The used FCS requirements are mapped to one Security Objective, which in turn is originated by two Threats • This Security Objective does not explicitly determine the formulation of the corresponding FCS requirements (as expected, looking at the relevant Threats does not help)

  6. 5. Type 0 example: details (1/2) • Security Objective:The TOE must be able to support secure communication protocols and procedures between the card and the card interface device when required by the application. • This formulation does not explicitly determine the corresponding FCS requirements • Example of corresponding FCS requirement (FCS_COP.1.1-1):The TSF shall perform the explicit signature generation and verification (commands PSO Compute Digital Signature and PSO Verify Digital Signature) in accordance with a specified cryptographic algorithm RSA and cryptographic key sizes of 1024 bits that meet the following: • PKCS#1 (with SHA-1) signature generation/verification scheme. RSA Encryption Standard Version 2.0, October 1998 • SHA-1, FIPS Pub. 180-1, NIST, April 1995 • Tachograph Card specification /TachAn1B/, Appendix 11, chap. 2.2.1 (CSM_003), 2.2.2 (CSM_004), 6.1 (CSM_034) and 6.2 (CSM_035)

  7. 6.Type 0 example: details (2/2) • Threat 1:A successful modification of activity data (addition, deletion, modification) during import or export would be a Threat to the security of the TOE • Threat 2: A successful modification or disclosure of personalisation data during import or export would be a Threat to the security of the TOE • This formulation does not explicitly determine the corresponding FCS requirements

  8. 7. A Type 1 example • Infineon Smart Card IC (Security Controller) SLE88CFX4000P / m8830 Security Target Version 1.1, 20-01-2006, BSI-DSZ-CC-0269 • In this ST • The used FCS requirements are mapped to one Security Objective, which in turn is originated by one OSP (the Security Objective substantially duplicates the OSP) • This Security Objective explicitly determines the formulation of the corresponding FCS requirements

  9. 8.Type 1 example: details (1/2) • Security Objective:The TOE must provide the following specific security functionality to the Smartcard Embedded Software: • Data Encryption Standard (DES), • Triple Data Encryption Standard (3DES), • Rivest-Shamir-Adleman Cryptography (RSA), • Advanced Encryption Standard (AES), • Secure Hash Algorithm (SHA-1). • This formulation explicitly determines the corresponding FCS requirements • Example of corresponding FCS requirement (FCS_COP.1.1): The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Triple Data Encryption Standard (3DES) and cryptographic key sizes of 112 bit or 168 bit, that meet the following standards: U.S. Department of Commerce / National Bureau of Standards Data Encryption Standard (DES), FIPS PUB 46-3, 1999 October 25, keying option 2

  10. 9.Type 1 example: details (2/2) • Security Objective:The TOE must provide the following specific security functionality to the Smartcard Embedded Software: • Data Encryption Standard (DES), • Triple Data Encryption Standard (3DES), • Rivest-Shamir-Adleman Cryptography (RSA), • Advanced Encryption Standard (AES), • Secure Hash Algorithm (SHA-1). • The Security Objective duplicates the corresponding OSP • OSP:The TOE shall provide the following specific security functionality to the Smartcard Embedded Software: • Data Encryption Standard (DES), • Triple Data Encryption Standard (3DES), • Rivest-Shamir-Adleman Cryptography (RSA), • Advanced Encryption Standard (AES), • Secure Hash Algorithm (SHA-1).

  11. 10. Two Type 2 examples • IBM Cryptographic Security Chip for PC Clients manufactured by Atmel (AT90SP0801) Common Criteria Security Target Version 4.4, 01-09-2001, CCEVS-VR-01-0005 • In this ST • The used FCS requirements are mapped either to Security Objective 1, which in turn is originated by Threat 1, or to Security Objective 2, which in turn is originated by Threat 2 • Each Security Objective explicitly determines the formulation of the corresponding FCS requirements

  12. 11. Type 2 example 1: details • Security Objective 1:The TOE must perform cryptographic operations, including RSA digital signature, RSA decryption, and public key generation in accordance with specified algorithms and cryptographic keys of a specified size, in accordance with PKCS-1 and of sufficient size to protect private/public key pairs from deciphering. • This formulation explicitly determines the corresponding FCS requirements • Example of corresponding FCS requirement (FCS_COP.1.1;1):The TSF shall perform digital signature generation in accordance with a specified cryptographic algorithm RSA and cryptographic key sizes 512-1024 bits that meet the following: PKCS-1. • Threat1: Cryptographic algorithms and/or cryptographic key sizes may be insufficient, allowing them to be deciphered by users that are not authorized access to the encrypted data. • Notice that this formulation addresses the sufficiency of the cryptographic algorithms and of their key sizes

  13. 12. Type 2 example 2: details • Security Objective 2:The TOE must perform cryptographic key destruction in accordance with PKCS-1. [Note – Reference to PKCS-1 is a mistake for FIPS 140-1] • This (corrected) formulation explicitly determines the corresponding FCS requirement • Corresponding FCS requirement(FCS_CKM.4.1):The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method zeroization that meets the following: FIPS 140-1, Section 4.8.5, Key Destruction. • Threat2: Incorrect cryptographic key destruction may cause an inadvertent disclosure of sensitive information.

  14. 13. A Type 3 example • U.S. Government Biometric Verification Mode Protection Profile (PP) for Medium Robustness Environments Version 1.0, 15-11-2003, CCEVS-VR-03-0050 • In this PP • The used FCS requirements are mapped either to Security Objective 1, which in turn is originated by one Threat and by OSP 1, or to Security Objective 2, which in turn is originated by one Threat and by OSP 2 • Security Objective 1 explicitly determines the formulation of the corresponding FCS requirements • Security Objective 2 is not shown here because it does not explicitly determine the formulation of the corresponding FCS requirements(Type 0)

  15. 14. Type 3 example: details (1/2) • Security Objective 1:The TOE shall use NIST FIPS 140-2 validated cryptomodules for cryptographic services implementing FIPS-approved security functions and random number generation services used by cryptographic functions. • This formulation explicitly determines the corresponding FCS requirements • Example of corresponding FCS requirement (FCS_CKM.1.1 Refinement): The FIPS-validated cryptomodule shall generate symmetric cryptographic keys using a for all key sizes FIPS-Approved Random Number Generatorthat meet the following: one of the standards defined in Annex C to FIPS 140-2.

  16. 15. Type 3 example: details (2/2) • Threat:An attacker may defeat security functions through a cryptographic attack against the algorithm, through cryptanalysis on encrypted data, or through a brute-force attack and thereby gaining unauthorized authentication • Notice that this formulation explicitly addresses cryptanalytic attacks (brute-force and/or other) • OSP 1:Where the TOE requires FIPS-approved security functions, only NIST FIPS validated cryptography (methods and implementations) are acceptable for key management (i.e.; generation, access, distribution, destruction, handling, and storage of keys) and cryptographic services (i.e.; encryption, decryption, signature, hashing, key distribution, and random number generation services).

  17. 16. Impact of the cryptography enforcement type on the evaluation (1/2) • Correctness analysis – No impact is expected! • Sufficiency analysis – There could be a real impact, especially where • The enforcement of cryptography is originated by Threats* that explicitly address cryptanalytic attacks (brute-force and/or other) (*See previous examples for Type 2 (example 1) and Type 3 enforcements) • And the evaluation process is executed within a scheme scrupulously providing specific guidance in dealing with cryptography [CEM 2.3/3.1] (e.g., for assessing whether Threats explicitly addressing cryptanalytic attacks are sufficiently countered by the corresponding Security Objectives and FCS requirements)

  18. 17. Impact of the cryptography enforcement type on the evaluation (2/2) • Evaluation schemes should require that any significant impact of cryptography enforcement on the evaluation process be recognizable clearly and as broadly as possible (e.g., by specific notifications in certification/validation reports)

  19. 18. Introduction to Aspect 2 • Aspect 2 addresses some of the techniques on which physical attacks against cryptographic devices are based • Side channel analysis (observation attacks in CCDB-2006-04-007 Requirements to perform Integrated Circuit Evaluations) • Fault analysis (perturbation attacks in CCDB-2006-04-007 Requirements to perform Integrated Circuit Evaluations)

  20. 19. Attacks based on side channel analysis • These attacks do not modify the cryptographic device • They aim at recovering sensitive data (e.g., secret and/or private keys) by observing the physical behavior of the cryptographic device • Several analytic techniques are used to recover sensitive data from physical measurements (e.g., execution time and/or power consumption)

  21. 20. Attacks based on fault analysis • These attacks modify the cryptographic device in a transient way (the impact of the induced fault is not permanent) • They aim at recovering sensitive data (e.g., secret and/or private keys) by exploiting the modified operation of the cryptographic device • Transient faults are induced by suitably perturbating the cryptographic device (e.g., by using power glitches and/or electro-magnetic radiation)

  22. 21. Current practice for Aspect 2 • Several approaches are used to take care of side channel attacks (on which we focus in the sequel) • Approach 0: A specific Assumption is defined to have the Environment take care of the problem (no specific Threats for the TOE are defined) • Approach 1: The problem is solved by Standard SFRs • Approach 2: The problem is solved by Extended SFRs • As for fault attacks (not exhaustively treated in the sequel) • Only Approaches 0 and 1 are used • They are usually addressed less explicitly than side channel attacks • They are sometimes addressed jointly with side channel attacks

  23. 22. More on Approach 1 (1/2) • The standard SFRs mapped to Security Objectives addressing side channel attacks come from • Class FDP (User data protection) • Family FDP_IFC (Information flow control policy) • Family FDP_IFF (Information flow control functions) • Family FDP_ITT (Internal TOE transfer) • Class FPR (Privacy) • Family FPR_UNO (Unobservability) • Class FPT (Protection of the TSF) • Family FPT_ITT (Internal TOE TSF data transfer) • Family FPT_PHP (TSF physical protection)

  24. 23. More on Approach 1 (2/2) • 3 different sets of standard SFRs are used to address side channel attacks • FPR_UNO.1 (Unobservability) • FPT_PHP.3 (Resistance to physical attack) • Some subsets of the following set • FDP_IFC.1 (Subset information flow control) • FDP_IFF.3 (Limited illicit information flows) • FDP_IFF.4 (Partial elimination of illicit information flows) • FDP_ITT.1 (Basic internal transfer protection) • FPT_ITT.1 (Basic internal TSF data transfer protection) (notice that the listed FDP requirements depend on FDP_IFC.1)

  25. 24. An Approach 0 example • Trusted Computing Platform Alliance (TCPA) Trusted Platform Module Protection Profile (TPM PP) Version 1.9.7, 01-07-2002, CCEVS-VR-02-0022 • In this PP • The Assumption is made that the Environment counters physical attacks, including the ones based on side channel analysis and fault analysis (no Threats consisting in physical attacks are defined for the TOE) • This Assumption originates a Security Objective for the Environment

  26. 25. Approach 0 example: details • Assumption: The TOE provides tamper evidence only. It provides no protection against physical Threats such as simple power analysis, differential power analysis, external signals, or extreme temperature. Physical protection is assumed to be provided by the Environment. • This formulation addresses side channel attacks (explicitly) and fault attacks (less explicitly) • Security Objective for the Environment:The Environment shall provide an acceptable level of physical security so that the TPM cannot be tampered with or be subject to side channel attacks such as the various forms of power analysis and timing analysis.

  27. 26. An Approach 1 example • Smart Card IC with Multi-Application Secure Platform V2.0, November 2000, PP/0010 • In this PP • A Security Objective for the TOE is defined that explicitly addresses information leakage • The Security Objective is originated by two generic Threats against data confidentiality • The Security Objective is uniquely mapped to FPR_UNO.1

  28. 27. Approach 1 example: details (1/2) • Security Objective:The ES must be designed to avoid interpretations of electrical signals from the hardware part of the TOE. • Threat 1:Unauthorized disclosure of ES, Native-Application, and Loaded-Application TSF Data (such as data protection system, memory partitioning, cryptographic programs and keys). • Threat 2:Unauthorized disclosure of User (application provider and end user) data and TSF data. • The Security Objective explicitly addresses side channel attacks (whereas the threats that originate it do not) • FPR_UNO.1 Unobservability FPR_UNO.1.1 The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation [assignment: list of operations] on [assignment: list of objects] by [assignment: list of protected users and/or subjects]. • No assignment in FPR_UNO.1 is completed by PP/0010

  29. 28. Approach 1 example: details (2/2) • Keycorp MULTOS Common Criteria Public Security Target version 1.0, 26-05-2004, SIM-SP-0212 • This ST is based on (but does not claim conformance to) PP/0010 • Operations in FPR_UNO.1: [assignment: list of users and/or subjects] = any users [assignment: list of operations] = cryptographic operations [assignment: list of objects] = Application Load Certificate, Application Delete Certificate, Application Load Unit, MSM Controls Data and hash digest of the contents of a selected area of MCD’s memory [assignment: list of protected users and/or subjects] = MULTOS • The listed objects are TOE security functions that use cryptographic operations

  30. 29. An Approach 2 example • Protection Profile — Machine Readable Travel Document with ICAO Application and Basic Access Control (MRTD-PP) Version 1.0, 18-08-2005, BSI-PP-0017 • In this PP • A Threat for the TOE is defined that explicitly addresses information leakage • The Threat originates one Security Objective for the TOE, which addresses side channel attacks and other attacks • The side channel part of the Security Objective is mapped to one extended SFR

  31. 30. Approach 2 example: details (1/5) • Threat:An attacker may exploit information which is leaked from the TOE during its usage in order to disclose confidential TSF data. The information leakage may be inherent in the normal operation or caused by the attacker. Leakage may occur through emanations, variations in power consumption, I/O characteristics, clock frequency, or by changes in processing time requirements. This leakage may be interpreted as a covert channel transmission but is more closely related to measurement of operating parameters, which may be derived either from measurements of the contactless interface (emanation) or direct measurements (by contact to the chip still available even for a contactless chip) and can then be related to the specific operation being performed. Examples are the Differential Electromagnetic Analysis (DEMA) and the Differential Power Analysis (DPA). Moreover the attacker may try actively to enforce information leakage by fault injection (e.g. Differential Fault Analysis). • This formulation explicitly addresses side channel attacks together with other attacks (in particular fault attacks)

  32. 31. Approach 2 example: details (2/5) • Security Objective: The TOE must provide protection against disclosure of confidential TSF data stored and/or processed in the MRTD’s chip • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines and • by forcing a malfunction of the TOE and/or • by a physical manipulation of the TOE. Application note: This objective pertains to measurements with subsequent complex signal processing due to normal operation of the TOE or operations enforced by an attacker. Details correspond to an analysis of attack scenarios which is not given here. • This formulation separates side channel attacks (first item in the list) from other aspects

  33. 32. Approach 2 example: details (3/5) • Rationale of the SFRs for the Security Objective: • The security objective OT.Prot_Inf_Leak “Protection against Information Leakage” requires the TOE to protect confidential TSF data stored and/or processed in the MRTD’s chip against disclosure • by measurement and analysis of the shape and amplitude of signals or the time between events found by measuring signals on the electromagnetic field, power consumption, clock, or I/O lines, which is addressed by the SFR FPT_EMSEC.1, • by forcing a malfunction of the TOE, which is addressed by the SFR FPT_FLS.1 and FPT_TST.1, and/or • by a physical manipulation of the TOE, which is addressed by the SFR FPT_PHP.3. • Protection against side channel attacks is provided by the extended SFR FPT_EMSEC.1

  34. 33. Approach 2 example: details (4/5) • FPT_EMSEC.1 TOE Emanation FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list oftypes of TSF data]and [assignment: list of types of user data]. FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users]are unable to use the following interface [assignment: type of connection]to gain access to [assignment: list oftypes of TSF data]and [assignment: list of types of user data]. • To fit into the formulation of this requirement, timing information has to be considered as a type of emission • Operations in FPT_EMSEC.1: [assignment: list oftypes of TSF data] = Personalization Agent Authentication Key [assignment: type of users] = any unauthorized users [assignment: type of connection] = smart card circuit contacts • Assignments of types of emissions and specified limits are not completed

  35. 34. Approach 2 example: details (5/5) • Specification of the Security Target TCOS Passport Version 1.0 Release 2, 16-01-2006,BSI-DSZ-CC-0362 • This ST claims conformance to BSI-PP-0017 • Remaining Operations in FPT_EMSEC.1: [assignment: types of emissions] = power variations, timing variations during command execution [assignment: specified limits] = non-useful information [assignment: list of types of user data] = none • No further explanation is given for the assignments power variations, timing variations and non-useful information

More Related