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

context

Renato Menicocci, Vittorio Bagini, Franco Guida FUB-OCSI

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 channel analysis and/or fault analysis

2. Current practice for Aspect 1

The enforcement of selected cryptographic algorithms and/or key management techniques– Is specified in SFRs of the FCS class (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/or Threats

– Is usually specified by referring to external documents (e.g., standards and/or lists of approved algorithms)

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)

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)

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)

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

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

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

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

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

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.

Threat 1: 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

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.

Threat 2: Incorrect cryptographic key destruction may cause an inadvertent disclosure of sensitive information.

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)

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 Generator that meet the following: one of the standards defined in Annex C to FIPS 140-2.

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

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)

16. Impact of the cryptography enforcement type on the evaluation (1/2)

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)

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)

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)

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)

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

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)

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)

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

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.

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

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 UnobservabilityFPR_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

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

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

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)

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

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

33. Approach 2 example: details (4/5)

FPT_EMSEC.1 TOE EmanationFPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to [assignment: list of types 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 of types 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 of types 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

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