Print Date: 06.05.02 10:00 Filename: SecurityTarget_105.doc 2002 Infineon Technologies AG. All rights reserved. This document and all information contained therein is considered confidential and proprietary of Infineon technologies AG. The recipient of this document shall not disclose this document or the information contained herein in whole or in part to any third party. Infineon technologies AG reserves the right to change the specification or parts of it without prior notice. Public Infineon Technologies AG Security and Chipcard ICs Evaluation Documentation SLE66CX322P with RSA2048 / m1484 Security Target Version 1.0.5 Date 06-05-2002 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 2/42 Revision History Version Page Subject 0.9 22-02-2002: Initial Version with RSA2048 support, based on Security Target 1.0.1, without RSA2048 support. 0.97 26-03-2002: Comments from TÜViT and BSI 0.98 04-04-2002: Final discussions integrated on workshop 040402 1.0 05-04-2002: Final version 1.0.1 17-04-2002: FCS_CKM.1 added 1.0.2 18-04-2002: Table 11 updated 1.0.3 19-04-2002: Table in 8.2.1 updated 1.0.4 29-04-2002: SEF7 excluded from SOF rating TABLE OF CONTENTS 1 INTRODUCTION ....................................................................................................................................... 5 1.1 SECURITY TARGET IDENTIFICATION........................................................................................................... 5 1.2 SECURITY TARGET OVERVIEW.................................................................................................................. 5 1.3 CC CONFORMANCE ................................................................................................................................. 6 1.4 SECURITY FUNCTIONAL REQUIREMENTS AND AUGMENTATIONS................................................................... 6 2 DESCRIPTION OF THE TARGET OF EVALUATION (TOE) ................................................................... 7 2.1 PRODUCT TYPE ....................................................................................................................................... 7 2.2 SCOPE OF THE TOE................................................................................................................................. 8 2.2.1 Hardware of the TOE ..................................................................................................................... 8 2.2.2 Firmware and software of the TOE ................................................................................................ 9 2.2.3 Guidance documentation ............................................................................................................... 9 2.2.4 Forms of delivery.......................................................................................................................... 10 2.2.5 Production sites............................................................................................................................ 10 3 TOE SECURITY ENVIRONMENT........................................................................................................... 11 3.1 DEFINITION OF ASSETS .......................................................................................................................... 11 3.2 ASSUMPTIONS........................................................................................................................................ 11 3.3 THREATS ............................................................................................................................................... 12 3.4 ORGANISATIONAL SECURITY POLICIES .................................................................................................... 13 3.4.1 Augmented organisational security policy.................................................................................... 13 4 SECURITY OBJECTIVES....................................................................................................................... 14 4.1 SECURITY OBJECTIVES FOR THE TOE ..................................................................................................... 14 4.2 SECURITY OBJECTIVES FOR THE ENVIRONMENT ....................................................................................... 15 4.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)” ..................................................... 15 4.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”........................................................... 15 5 IT SECURITY REQUIREMENTS ............................................................................................................ 17 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 3/42 5.1 TOE SECURITY REQUIREMENTS.............................................................................................................. 17 5.1.1 TOE security functional requirements.......................................................................................... 17 5.1.2 TOE security assurance requirements......................................................................................... 23 5.1.3 Refinements ................................................................................................................................. 24 5.2 SECURITY REQUIREMENTS FOR THE ENVIRONMENT ................................................................................. 25 5.2.1 Security requirements for the IT Environment.............................................................................. 25 5.2.2 Security Requirements for the Non-IT-Environment .................................................................... 25 6 TOE SUMMARY SPECIFICATION ......................................................................................................... 27 6.1 SEF1: OPERATING STATE CHECKING ...................................................................................................... 27 6.2 SEF2: PHASE MANAGEMENT WITH TEST MODE LOCK-OUT........................................................................ 27 6.3 SEF3: PROTECTION AGAINST SNOOPING................................................................................................. 28 6.4 SEF4: DATA ENCRYPTION AND DATA DISGUISING .................................................................................... 28 6.5 SEF5: RANDOM NUMBER GENERATION ................................................................................................... 28 6.6 SEF6: TSF SELF TEST........................................................................................................................... 28 6.7 SEF7: NOTIFICATION OF PHYSICAL ATTACK............................................................................................. 29 6.8 SEF8: MEMORY MANAGEMENT UNIT (MMU) .......................................................................................... 29 6.9 SEF9: CRYPTOGRAPHIC SUPPORT ......................................................................................................... 29 6.10 MAPPING OF SECURITY FUNCTIONAL REQUIREMENTS.......................................................................... 30 6.11 ASSURANCE MEASURES..................................................................................................................... 31 7 PP CLAIMS.............................................................................................................................................. 32 7.1 PP REFERENCE ..................................................................................................................................... 32 7.2 PP TAILORING........................................................................................................................................ 32 7.2.1 FCS_RND .................................................................................................................................... 32 7.2.2 FAU_SAS.1.................................................................................................................................. 32 7.3 PP ADDITIONS........................................................................................................................................ 32 8 RATIONAL............................................................................................................................................... 33 8.1 SECURITY OBJECTIVES RATIONALE......................................................................................................... 33 8.2 SECURITY REQUIREMENTS RATIONALE ................................................................................................... 34 8.2.1 Rationale for the security functional requirements....................................................................... 34 8.2.2 Dependencies of security functional requirements ...................................................................... 36 8.2.3 Rationale for the Assurance Requirements and the Strength of Function Level ......................... 37 8.3 SECURITY REQUIREMENTS ARE MUTUALLY SUPPORTIVE AND INTERNALLY CONSISTENT ........................... 37 9 REFERENCES......................................................................................................................................... 38 9.1 DOCUMENTS AND USER GUIDANCE......................................................................................................... 38 9.2 LITERATURE........................................................................................................................................... 38 9.3 LIST OF ABBREVIATIONS ......................................................................................................................... 38 9.4 GLOSSARY............................................................................................................................................. 39 10 DEFINITION OF THE SECURITY FUNCTIONAL COMPONENT FPT_TST.2 ...................................... 42 List of figures: Figure 1: Block diagram of the SLE66CX322P with RSA2048........................................................ 8 List of tables: Table 1: Identification ..................................................................................................................... 5 Table 2: Production site in chip identification................................................................................ 10 Table 3: Threats to Smartcards according to the Protection Profile.............................................. 12 Table 4: Objectives for Smartcards according to the Protection Profile ........................................ 14 Table 5: Additional objectives due to TOE specific functions and augmentations......................... 14 Table 6: Security objectives for the environment .......................................................................... 15 Table 7: Security functional requirements defined in Smartcard IC Platform Protection Profile .... 22 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 4/42 Table 8: Augmented security functional requirements.................................................................. 23 Table 9: Assurance components .................................................................................................. 23 Table 10: Mapping of SFR and SEF............................................................................................. 30 Table 11: Assurance measures.................................................................................................... 31 Table 12: User guidance .............................................................................................................. 38 Table 13: Protection Profile .......................................................................................................... 38 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 5/42 1 Introduction 1.1 Security Target Identification The Security Target has the revision 1.0.5 and is dated 06-05-2002. The Target of Evaluation (TOE) is a smart card IC (Security Controller), which is named SLE66CX322P with RSA2048, is internally registered under the development code m1484a23 and has the version number a23. The Security Target is based on the Protection Profile Smartcard IC Platform Protection Profile . The Protection Profile and the Security Target are built with Common Criteria V2.1. Table 1: Identification Version number Date Registration Security Target 1.0.5 06-05-2002 Target of Evaluation a23 m1484a23 Smartcard IC Platform Protection Profile 1.0 July 2001 BSI-PP-0002 Common Criteria 2.1 ISO15408 1.2 Security Target Overview The Target of Evaluation (TOE), the SLE66CX322P with RSA2048 chip, is a smart card IC (Security Controller) meeting the highest requirements in terms of performance and security. It is manufactured by Infineon Technologies AG in a 0,22 µm CMOS technology. The IC is intended to be used in smart cards for particularly security-relevant applications. In this security target the TOE (target of evaluation) is described and a summary specification is given. The security environment of the TOE during its different phases of the lifecycle is defined. The assets are identified which have to be protected through the security policy. The threats against these assets are described. The security objectives as the objectives of the security policy are defined as well as the security requirements. The requirements are built up of the security functional requirements as part of the security policy and the security assurance requirements as the steps during the evaluation and certification to show the TOE meets its requirements. The functionality of the TOE to meet the requirements is described. The assets, threats, security objectives and the security functional requirements are defined in the Smartcard Integrated Circuit Platform Protection Profile Smartcard IC Platform Protection Profile and are referenced here. These requirements build up a minimal standard common for all Smartcards. The security enforcing functions are defined here in the security target as property of this specific TOE, the SLE66CX322P with RSA2048. Here it is shown how this specific TOE fulfils the requirements for the standard defined in the Protection Profile. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 6/42 1.3 CC Conformance This security target is conformant to Common Criteria V2.1 (ISO15408) part 2 extended, part 3 conformant and conformant to the Smartcard IC Platform Protection Profile . The assurance level is EAL5 augmented with components ALC_DVS.2, AVA_MSU.3 and AVA_VLA.4. 1.4 Security functional requirements and Augmentations The security requirements of the TOE according to the Smartcard IC Platform Protection Profile are listed in Table 7. The augmented security functional requirements (see Table 8) are listed and described in section 5.1. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 7/42 2 Description of the Target of Evaluation (TOE) The TOE description helps to understand the specific security environment and the security policy. In this context the assets, threats, security objectives and security functional requirements can be employed. The following is a more detailed description of the TOE than in the Smartcard IC Platform Protection Profile as it belongs to the specific TOE. 2.1 Product Type The Target of Evaluation (TOE), the SLE66CX322P with RSA2048 chip, is a smart card IC (Security Controller) meeting the highest requirements in terms of performance and security. It is manufactured by Infineon Technologies AG in a 0,22 µm CMOS technology. The IC is intended to be used in smart cards for particularly security-relevant applications. That is based on its previous use as developing platform for smart card operating systems according to the lifecycle model (in Smartcard IC Platform Protection Profile ). The term user software is used in the following for all operating systems and applications stored and executed on the TOE. The TOE is the platform for the user software. The user software itself is not part of the TOE. The SLE66CX322P with RSA2048 chip is a port of the SLE66CX320P architecture to a smaller production technology and is implemented in the 0,22 µm technology. As a side effect of this porting the most components are unchanged. The IC, whose block diagram is shown in Figure 1, consists of a dedicated microprocessor (CPU) with a MMU (Memory Management Unit), several different memories, security logic, a timer and an interrupt-controlled I/O interface. A RNG (Random Number Generator) and a checksum module (CRC module) are integrated on the chip. The CPU is compatible with the SAB 8051 instruction set and is 6 times faster than the standard processor. It provides additional powerful instructions for smart card applications. The memory comprises 256 bytes of internal RAM (IRAM), 4 kBytes of extended RAM (XRAM), 136 kBytes of user ROM, 8 kByte of test ROM and 32 kBytes of EEPROM. It thus meets the requirements of the new generation of operating systems. The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED). The access rights of the application to the memories can be controlled with the memory management unit (MMU). Security, sleep mode and interrupt logic as well as the RNG are specially designed for smart card applications. The sleep mode logic (clock stop mode per ISO/IEC 7816-3) is used to reduce the overall power consumption. The timer permits easy implementation of communication protocols such as T=1 and all other time-critical operations. The uart-controlled I/O interface allows the smart card and terminal to be operated in parallel. The PLL unit allows to operate the SLE66CX322P with RSA2048 with a multiplication factor over the external clock signal or free running with maximum frequency. The RNG does not supply a pseudorandom number sequence, but instead produces genuine random numbers under all conditions. The checksum module allows simple calculation of checksums per ISO 3309 (16 bit CRC). Two modules for cryptographic operations are implemented on the TOE. The well known ACE (Advanced Crypto Engine) for calculation of asymmetric algorithms like RSA. This module is especially designed for chipcard application with respect to the security and power consumption. The other module is the DDC which provides the DES algorithm and support for elliptic curve (EC) cryptography. This module computes the complete DES algorithm within a few clock cycles. That module is especially designed to counter attacks like DPA or EMA. The software (firmware) required for operating the chip consists of routines for programming the EEPROM from application programs and for online testing of the security enforcing functions. These are stored in a reserved user ROM area. In addition, the chip initialisation routine with Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 8/42 security checks and identification mode as well as test routines for production testing are located in a separate test ROM. The TOE offers a new, improved standard of integrated security features, thereby meeting the requirements of all smart card applications such as information integrity, access control, mobile telephone, as well as uses in electronic funds transfer and healthcare systems. To sum up, the TOE is a powerful smart card IC with a large amount of memory and special peripheral devices with both improved performance and optimised power consumption at minimal chip size. It therefore constitutes the basis for future smart card applications. Address and Data Bus Security Logic CPU with MED, MMU and IRAM 256B CLK RST I/O User- ROM 136 KB XRAM 4 KB RNG Interrupt Module CRC Timer Test- ROM 8 KB Non Volatile Memory 32 KB ROM 16 B PROM 16 B EEPROM 32736 B ACE GND VCC DDC Figure 1: Block diagram of the SLE66CX322P with RSA2048 2.2 Scope of the TOE The TOE comprises the hardware of the smart card security controller, type SLE66CX322P with RSA2048, manufactured by Infineon Technologies AG, and part of the associated firmware required for operation and provided in ROM. The documents described in section 2.2.3 and listed in Annex 9.1 are supplied as a manual. In the following description, the term “manufacturer” is short for Infineon Technologies AG, the manufacturer of the TOE. The user software is not part of the TOE. 2.2.1 Hardware of the TOE The hardware part of the TOE (cf. Figure 1) as defined in Smartcard IC Platform Protection Profile is comprised of: • Security logic (SEC) • Microcontroller type ECO 2000 (CPU) with the subcomponents memory encryption and decryption unit (MED), memory management unit (MMU) and 256 bytes of internal RAM (IRAM) • External memory comprising: − 4 kBytes extended RAM (XRAM) − 136 kBytes user ROM, including the routines for chip management (RMS) − 8 KB test ROM containing the test routines (STS), and − a total of 32 kBytes nonvolatile memory (EEPROM). Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 9/42 • True random number generator (RNG) • Checksum module (CRC) • Interrupt module (INT) • Timer (TIM) • Address and data bus (BUS) • Advanced Crypto Engine (ACE) for long integer modulo calculations, which are used in asymmetric algorithms like RSA • DES accelerator (DDC), used for fast calculations of the DES algorithm and provides EC2 support. 2.2.2 Firmware and software of the TOE The entire firmware of the IC consists of two different parts. The one is the RMS routines for EEPROM programming and security function testing (Resource Management System, IC Dedicated Support Software in Smartcard IC Platform Protection Profile ). The RMS routines are stored from Infineon Technologies AG in a reserved area of the normal user ROM. The other is the STS which consists of test and initialization routines (Self Test Software, IC Dedicated Test Software in Smartcard IC Platform Protection Profile ).The STS routines are stored in the especially protected test ROM and are not accessible for the user software. The software part of the TOE consists of the RSA2048 library. The RSA2048 library is used to provide a high level interface to RSA (Rivest, Shamir, Adleman) cryptography implemented on the hardware component ACE K6. The routines are used for the generation of RSA Key Pairs (RsaKeyGen), the RSA signature verification (RsaVerify), the RSA signature generation (RsaSign) and the RSA modulus recalculation (RsaModulus). The hardware ACE unit provides the basic long number calculations (add, subtract, multiply, square with 1100 bit numbers) with high performance. The RSA2048 library is delivered as source code and in this way integrated in the user software. The above demarcations of the TOE result in the interfaces described below. 2.2.2.1 Interfaces of the TOE • The physical interface of the TOE to the external environment is the entire surface of the IC. • The electrical interface of the TOE to the external environment is constituted by the pads of the chip, particularly the contacted RES, I/O, CLK lines and supply lines VCC and GND. • The data-oriented I/O interface to the TOE is formed by the I/O pad. • The interface to the firmware is constituted by special registers used for hardware configuration and control (Special Function Registers, SFR). • The interface of the TOE to the operating system is constituted on the one hand by the RMS routine calls and on the other by the instruction set of the TOE. • The interface of the TOE to the test routines is formed by the STS test routine call, i.e. entry to test mode (STS-TM entry). • The interface to the RSA calculations is defined from the RSA2048 library interface. 2.2.3 Guidance documentation The guidance documentation consists of the [Databook] which contains the description of all interfaces of the software to the hardware relevant for programming the SLE66CX322P with Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 10/42 RSA2048. In addition programming examples for more specific topics like secure use of cryptography are documented in form of application notes. Finally the certification report will contain an overview of the recommendations to the software developer regarding the secure use of the platform SLE66CX322P with RSA2048. These recommendations are also included in the ordinary documentation. The list of guidance documentation is given in Annex 9.1. 2.2.4 Forms of delivery The SLE66CX322P with RSA2048 can be delivered in form of complete modules or in form of plain wafers. The delivery can therefore be at the end of phase 3 or at the end of phase 4 according to Smartcard IC Platform Protection Profile . Nevertheless in both cases the TOE is finished and the extended test features are removed. In this document are always both cases mentioned to avoid incorrectness but from the security policy point of view the two cases are identical. 2.2.5 Production sites The TOE may be produced in different production sites (listed in Table 2). The chip layout is not changed in this case and also the production testing does not differ. To distinguish the different production sites the chip identification number is coded as shown in Table 2. The exact coding of the chip identification is described in [Databook] section 7. The delivery measures are described in the ALC_DVS aspect. Table 2: Production site in chip identification Production Site Chip Identification (first nibble, hex format) Dresden 2 UMC 4 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 11/42 3 TOE Security Environment For this chapter the Smartcard IC Platform Protection Profile can be applied completely. A summary is given in the following. 3.1 Definition of Assets The primary assets concern the User Data which includes the data as well as program code (Smartcard Embedded Software). This asset has to be protected while being executed and on the other hand when the TOE is not in operation. This leads to the three primary assets • User Data • Smartcard Embedded Software • TOE’s correct operation The specific functions of the TOE introduce additional assets. • the random numbers generated by the TOE The class of secondary assets consists of the following. • logical design data, • physical design data, • IC Dedicated Software, Initialisation Data and Pre-personalisation Data, TSF data • specific development aids, • test and characterisation related data, • material for software development support, and • photomasks and products in any form For details see Smartcard IC Platform Protection Profile section 3.1. 3.2 Assumptions The assumptions defined in the Smartcard IC Platform Protection Profile concern the phases where the TOE has left the chip manufacturer. A.Process-Card Protection during Packaging, Finishing and Personalisation A.Plat-Appl Usage of Hardware Platform A.Resp-Appl Treatment of User Data Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 12/42 The support of cipher schemas needs to make a additional assumption. The developer of the Smartcard Embedded Software must ensure the appropriate “Usage of Key- dependent Functions (A.Key-Function)” while developing this software in Phase 1 as specified below. A.Key-Function Usage of Key-dependent Functions Key-dependent functions (if any) shall be implemented in the Smartcard Embedded Software in a way that they are not susceptible to leakage attacks (as described under T.Leak-Inherent and T.Leak-Forced). Note that here the routines which may compromise keys when being executed are part of the Smartcard Embedded Software. In contrast to this the threats T.Leak-Inherent and T.Leak-Forced address (i) the cryptographic routines which are part of the TOE and (ii) the processing of User Data including cryptographic keys. For details see Smartcard IC Platform Protection Profile section 3.2. 3.3 Threats The threats are directed against the assets. The threat is a general description of “What one wants to do” and might contain several specific attacks (“How one wants to do it”). The more detailed description of specific attacks is given later on in the process of evaluation and certification. An overview on attacks is given in Smartcard IC Platform Protection Profile . Table 3: Threats to Smartcards according to the Protection Profile T.Phys-Manipulation Physical Manipulation T.Phys-Probing Physical Probing T.Malfunction Malfunction due to Environmental Stress T.Leak-Inherent Inherent Information Leakage T.Leak-Forced Forced Information Leakage T.Abuse-Func Abuse of Functionality T.RND Deficiency of Random Numbers For details see Smartcard IC Platform Protection Profile section 3.2. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 13/42 3.4 Organisational Security Policies The SLE66CX322P with RSA2048 has to be protected during the first phases of his lifecycle (phases 2-TOE delivery)1. Later on the TOE has to protect itself. The organisational security policy covers this aspect. P.Process-TOE Protection during TOE Development and Production See Smartcard IC Platform Protection Profile for a detailed description. Due to the augmentations of the Smartcard IC Platform Protection Profile an additional policy is introduced. 3.4.1 Augmented organisational security policy The TOE provides specific security functionality which can be used by the Smartcard Embedded Software. In the following specific security functionality is listed which is not derived from threats identified for the TOE’s environment because it can only be decided in the context of the smartcard application, against which threats the Smartcard Embedded Software will use the specific security functionality. The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality (P.Add-Functions)” as specified below. P.Add-Functions Additional Specific Security Functionality The TOE shall provide the following specific security functionality to the Smartcard Embedded Software: - Area based Memory Access Control - Data Encryption Standard (DES), - Triple Data Encryption Standard (3DES), - Rivest-Shamir-Adleman (RSA), 1 The TOE can be delivered either after phase 3 or after phase 4. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 14/42 4 Security objectives For this chapter the Smartcard IC Platform Protection Profile can be applied completely. Only a short overview is given in the following. 4.1 Security objectives for the TOE See Smartcard IC Platform Protection Profile . Table 4: Objectives for Smartcards according to the Protection Profile O.Phys-Manipulation Protection against Physical Manipulation O.Phys-Probing Protection against Physical Probing O.Malfunction Protection against Malfunction due to Environmental Stress O.Leak-Inherent Protection against Inherent Information Leakage O.Leak-Forced Protection against Forced Information Leakage O.Abuse-Func Protection against Abuse of Functionality O.Identification TOE Identification O.RND Random Numbers The TOE shall provide “Additional Specific Security Functionality (O.Add-Functions)” as specified below. O.Add-Functions Additional Specific Security Functionality The TOE must provide the following specific security functionality to the Smartcard Embedded Software: - Area based Memory Access Control - Data Encryption Standard (DES), - Triple Data Encryption Standard (3DES), - Rivest-Shamir-Adleman (RSA), Table 5: Additional objectives due to TOE specific functions and augmentations O.Add-Functions Additional specific security functionality Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 15/42 4.2 Security objectives for the environment The detailed description of the environmental security objectives is given in the Smartcard IC Platform Protection Profile . The list of objectives is in Table 6. Table 6: Security objectives for the environment Phase 1 OE.Plat-Appl Usage of Hardware Platform OE.Resp-Appl Treatment of User Data Phase 2 up to TOE delivery OE.Process-TOE Protection during TOE Development and Production TOE delivery up to end of phase 6 OE.Process-Card Protection during Packaging, Finishing and Personalisation 4.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)” Regarding the cryptographic services this objective of the environment has to be clarified. The TOE supports cipher schemes as additional specific security functionality. If required the Smartcard Embedded Software shall use these cryptographic services of the TOE and their interface as specified. When key-dependent functions implemented in the Smartcard Embedded Software are just being executed, the Smartcard Embedded Software must provide protection against disclosure of confidential data (User Data) stored and/or processed in the TOE by using the methods described under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information Leakage (T.Leak-Forced)“. Regarding the area based access control this objective of the environment has to be clarified. For the separation of different applications the Smartcard Embedded Software (Operating System) may implement a memory management scheme based upon security mechanisms of the TOE. 4.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)” Regarding the cryptographic services this objective of the environment has to be clarified. By definition cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded Software shall treat these data appropriately, use only proper secret keys (chosen from a large key space) as input for the cryptographic function of the TOE and use keys and functions appropriately in order to ensure the strength of cryptographic operation. This means that keys are treated as confidential as soon as they are generated. The keys must be unique with a very high probability, as well as cryptographically strong. For example, it must be ensured that it is beyond practicality to derive the private key from a public key if asymmetric algorithms are used. If keys are imported into the TOE and/or derived from other keys, quality and Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 16/42 confidentiality must be maintained. This implies that appropriate key management has to be realised in the environment. Regarding the area based access control this objective of the environment has to be clarified. The treatment of User Data is also required when a multi-application operating system is implemented as part of the Smartcard Embedded Software on the TOE. In this case the multi-application operating system should not disclose security relevant user data of one application to another application when it is processed or stored on the TOE. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 17/42 5 IT security requirements For this chapter the Smartcard IC Platform Protection Profile can be applied completely. 5.1 TOE security requirements See Smartcard IC Platform Protection Profile . 5.1.1 TOE security functional requirements The detailed description of the security functional requirements is given in the Smartcard IC Platform Protection Profile . These security functional requirements are listed in Table 7. The additional security functional requirements are listed in Table 8. The necessary assignments are done in section 7.2. The description of the additional security functional requirements is given in the following. 5.1.1.1 Subset TOE security testing (FPT_TST.2) The security is strongly dependent on the correct operation of the security functions. Therefore, the TOE shall support that particular security functions or mechanisms are tested in the operational phase (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the TOE. Part 2 of the Common Criteria provides the security functional component “TSF testing (FPT_TST.1)”. The component FPT_TST.1 provides the ability to test the TSF’s correct operation. For the user it is important to know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions being tested. In addition, FPT_TST.1 requires to verify the integrity of TSF data and stored TSF executable code which might violate the security policy. Therefore, the security functional component Subset TOE security testing (FPT_TST.2) has been newly created. This component allows that particular parts of the security mechanisms and functions provided by the TOE are tested. FPT_TST.2 The security functional component Subset TOE security testing (FPT_TST.2) has been newly created (Common Criteria Part 2 extended). This component allows that particular parts of the security mechanisms and functions provided by the TOE can be tested after TOE Delivery. This security functional component is used instead of the functional component FPT_TST.1 from Common Criteria Part 2. For the user it is important to know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions being tested. In addition, FPT_TST.1 requires to verify the integrity of TSF data and stored TSF executable code which might violate the security policy. The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below (Common Criteria Part 2 extended). Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 18/42 FPT_TST.2 Subset TOE testing Hierarchical to: No other components. FPT_TST.2.1 The TSF shall run a suite of self tests during initial start-up and at the request of the authorised user to demonstrate the correct operation of the mechanisms M1.1, M1.2, M1.5 and M1.6.2 Dependencies: FPT_AMT.1 Abstract machine testing 5.1.1.2 Memory access control Usage of multiple applications in one Smartcard often requires to separate code and data in order to prevent that one application can access code and/or data of another application. To support this the TOE provides Area based Memory Access Control. The security service being provided is described in the Security Function Policy (SFP) Memory Access Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)” requires that this policy is in place and defines the scope were it applies. The security functional requirement “Security attribute based access control (FDP_ACF.1)” defines addresses security attribute usage and characteristics of policies. It describes the rules for the function that implements the Security Function Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or not is taken based upon attributes allocated to the soft- ware. Examples for such attributes are “the memory area where the software is executed from, the memory area where the access is performed to, special information or properties tied to the soft- ware, and/or the operation to be performed” (refer to below). The corresponding permission control information is evaluated so that access is granted/effective or denied/inoperable. The security functional requirement “Static attribute initialisation (FMT_MSA.3)” ensures that the default values of security attributes are appropriately either permissive or restrictive in nature. Alternative values can be specified by any subject provided that the Memory Access Control Policy allows that. This is described by the security functional requirement “Management of security attributes (FMT_MSA.1)”. The attributes are determined during TOE manufacturing (FMT_MSA.3) or set at run-time (FMT_MSA.1). From TOE´s point of view the different roles in the user software can be distinguished according to the memory based access control. However the definition of the roles belongs to the user software. The following Security Function Policy (SFP) Memory Access Control Policy is defined for the requirement “Security attribute based access control (FDP_ACF.1)”: Memory Access Control Policy The TOE shall control read, write, delete, execute accesses of software residing in memory areas on data including code stored in memory areas. The TOE shall restrict the ability to define, to change or at least to finally accept the applied rules (as mentioned in FDP_ACF.1) to software with a specific attribute. The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below. 2 The definition of the mechanisms can be found in the functional specification. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 19/42 FDP_ACC.1 Subset access control Hierarchical to: No other components. FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all subjects (software), all objects (data including code stored in memories) and all the operations defined in the Memory Access Control Policy. Dependencies: FDP_ACF.1 Security attribute based access control The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified below. FDP_ACF.1 Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1 The TSF shall enforce the Memory Access Control Policy to objects based on the memory area where the software is executed from and/or the memory area where the access is performed to and/or the operation to be performed. FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: evaluate the corresponding permission control information before, during or after the access so that accesses to be denied can not be utilised by the subject attempting to perform the operation. FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialisation The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below. FMT_MSA.3 Static attribute initialisation Hierarchical to: No other components. FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide well defined3 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow any subject (provided that the Memory Access Control Policy is enforced and the necessary access is therefore 3 The static definition of the access rules is documented in [Databook] section 5 Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 20/42 allowed) 4 to specify alternative initial values to override the default values when an object or information is created. Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified below: FMT_MSA.1 Management of security attributes Hierarchical to: No other components. FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability to change_default, modify or delete the security attributes permission control information to user software with a specific attribute. Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow control] FMT_SMR.1 Security roles 5.1.1.3 Support of cipher schemas FCS_COP.1 Cryptographic operation requires a cryptographic operation to be performed in accordance with a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and cryptographic key sizes can be based on an assigned standard. The dependencies will be discussed in Section 8.2. The following additional specific security functionality is implemented in the TOE: - Data Encryption Standard (DES), - Triple Data Encryption Standard (3DES), - Rivest-Shamir-Adleman (RSA), DES Operation The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1 Cryptographic operation Hierarchical to: No other components. FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Data Encryption Standard (DES) 4 The user software is intended to set the memory access control policy Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 21/42 and cryptographic key sizes of 56 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. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FMT_MSA.2 Secure security attributes Triple-DES Operation The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1 Cryptographic operation Hierarchical to: No other components. 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 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 Dependencies: [FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FMT_MSA.2 Secure security attributes Rivest-Shamir-Adleman (RSA) operation The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified below. FCS_COP.1 Cryptographic operation Hierarchical to: No other components. FCS_COP.1.1 The TSF shall perform encryption and decryption in accordance with a specified cryptographic algorithm Rivest-Shamir-Adleman (RSA) Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 22/42 and cryptographic key sizes 512-1024 bit5, 1280 bit and 2048 bit that meet the following standards ISO/IEC 9796-1, Annex A, sections A.4 and A.5, and Annex C. Dependencies: [FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FMT_MSA.2 Secure security attributes Rivest-Shamir-Adleman (RSA) key generation The key generation for the RSA shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” FCS_CKM.1 Cryptographic key generation Hierarchical to: No other components. FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm specified in [EESSI] and [ALGO] and specified cryptographic key sizes 512-1024 bit6, 1280 bit and 2048 bit that meet the following standards. ISO/IEC 9796-1, Annex A, sections A.4 and A.5, and Annex C. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FMT_MSA.2 Secure security attributes 5.1.1.4 Overview Table 7: Security functional requirements defined in Smartcard IC Platform Protection Profile Security Functional Requirement FRU_FLT.2 “Limited fault tolerance“ FPT_FLS.1 “Failure with preservation of secure state” FPT_SEP.1 “TSF domain separation” FMT_LIM.1 “Limited capabilities” FMT_LIM.2 “Limited availability” 5 All values between 512 and 1024 bit which can be divided by 8 bit are possible (byte granularity) 6 All values between 512 and 1024 bit which can be divided by 8 bit are possible (byte granularity) Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 23/42 Security Functional Requirement FAU_SAS.1 “Audit storage” FPT_PHP.3 “Resistance to physical attack” FDP_ITT.1 “Basic internal transfer protection” FDP_IFC.1 “Subset information flow control” FPT_ITT.1 “Basic internal TSF data transfer protection” FCS_RND.1 “Quality metric for random numbers” Table 8: Augmented security functional requirements Security Functional Requirement FPT_TST.2 “Subset TOE security testing“ FDP_ACC.1 “Subset access control” FDP_ACF.1 “Security attribute based access control” FMT_MSA.3 “Static attribute initialisation” FMT_MSA.1 “Management of security attributes” FCS_COP.1 “Cryptographic support” FCS_CKM.1 “Cryptographic key generation” 5.1.2 TOE security assurance requirements The evaluation assurance level is EAL 5 augmented. In Table 9 the security assurance requirements are given. The increase of the assurance components compared to the Smartcard IC Platform Protection Profile is expressed with bold letters. The augmentation of the assurance components to level EAL5 is given in italic letters. Table 9: Assurance components Aspect Refinement Configuration ACM_AUT.1 Partial CM automation management ACM_CAP.4 Generation support and acceptance procedures in PP ACM_SCP.3 Development tools CM coverage in ST Delivery and ADO_DEL.2 Detection of modification in PP operation ADO_IGS.1 Installation, generation, and start-up procedures in PP Development ADV_FSP.3 Semiformal functional specification in ST ADV_HLD.3 Semiformal high-level design Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 24/42 ADV_IMP.2 Implementation of the TSF ADV_INT.1 Modularity ADV_LLD.1 Descriptive low-level design ADV_RCR.2 Semiformal correspondence demonstration ADV_SPM.3 Formal TOE security policy model Guidance AGD_ADM.1 Administrator guidance in PP documents AGD_USR.1 User guidance in PP Life cycle ALC_DVS.2 Sufficiency of security measures in PP support ALC_LCD.2 Standardised life-cycle model ALC_TAT.2 Compliance with implementation standards Tests ATE_COV.2 Analysis of coverage in PP ATE_DPT.2 Testing: low-level design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample Vulnerability AVA_CCA.1 Covert channel analysis assessment AVA_MSU.3 Validation of analysis AVA_SOF.1 Strength of TOE security function evaluation AVA_VLA.4 Highly resistant 5.1.3 Refinements Some refinements are taken unchanged from the Smartcard IC Platform Protection Profile . In some cases a clarification is necessary. In Table 9 a overview is given where the refinement is done. Two refinements from the Smartcard IC Platform Protection Profile have to be discussed here in the Security Target, as the assurance level is increased. CM scope (ACM_SCP) The refinement from the Smartcard IC Platform Protection Profile can be applied even at the chosen assurance level EAL 5 augmented with ACM_SCP.3. The assurance package ACM_SCP.2 is extended to ACM_SCP.3 with aspects regarding the development tools. The refinement is not touched. Refinement for CM scope (ACM_SCP) The “TOE implementation representation” within the scope of the CM shall include at least: - logical design data, - physical design data, - IC Dedicated Software, - Smartcard Embedded Software, Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 25/42 - final physical design data necessary to produce the photomasks, and - photomasks. Functional Specification (ADV_FSP) The refinement from the Smartcard IC Platform Protection Profile can be applied even at the chosen assurance level EAL 5 augmented with ADV_FSP.3. The assurance package ADV_FSP.2 is extended to ADV_FSP.3 with aspects regarding the descriptive level. The level is increased from informal to semi formal with informal description The refinement is not touched from this measure. For details of the refinement see Smartcard IC Platform Protection Profile . 5.2 Security requirements for the Environment 5.2.1 Security requirements for the IT Environment See Smartcard IC Platform Protection Profile . 5.2.2 Security Requirements for the Non-IT-Environment In the following security requirements for the Non-IT-Environment are defined. For the development of the Smartcard Embedded Software (in Phase 1) the requirement RE.Phase-1 is valid. RE.Phase-1 Design and Implementation of the Smartcard Embedded Software The developers shall design and implement the Smartcard Embedded Software in such way that it meets the requirements from the following documents: (i) hardware data sheet for the TOE, (ii) TOE application notes, and (iii) findings of the TOE evaluation reports relevant for the Smartcard Embedded Software. The developers shall implement the Smartcard Embedded Software in a way that it protects security relevant User Data (especially cryptographic keys) as required by the security needs of the specific application context. The Smartcard Embedded Software shall meet the requirements “Cipher Schemas (RE.Cipher)” as specified below. RE.Cipher Cipher Schemas The developers of Smartcard Embedded Software must not implement routines in a way which may compromise keys when the routines are executed as part of the Smartcard Embedded Software. Performing functions which access cryptographic keys could allow an attacker to misuse these functions to gather information about the key which is used in the computation of the function. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 26/42 Keys must be kept confidential as soon as they are generated. The keys must be unique with a very high probability, as well as cryptographically strong. For example, it must be ensured that it is not possible to derive the private key from a public key if asymmetric algorithms are used. If keys are imported into the TOE and/or derived from other keys, quality and confidentiality must be maintained. This implies that an appropriate key management has to be realised in the environment. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 27/42 6 TOE summary specification The product overview is given in section 2.1. In the following the security functionality is described and the relation to the security functional requirements is shown. The TOE is equipped with 9 security enforcing functions to meet the security functional requirements. The functions are: SEF1: Operating state checking SEF2: Phase management with test mode lock-out SEF3: Protection against snooping SEF4: Data encryption and data disguising SEF5: Random number generation SEF6: TSF self test SEF7: Notification of physical attack SEF8: Memory Management Unit (MMU) SEF9: Cryptographic support The following description of the security enforcing functions is a complete representation of the TSF. 6.1 SEF1: Operating state checking Correct function of the SLE66CX322P with RSA2048 is only given in the specified range. To prevent an attack exploiting that circumstances it is necessary to detect if the specified range is left. All operating signals are filtered to prevent malfunction. The FRU_FLT.2 “Limited fault tolerance” requirement is satisfied. In addition the operating state is monitored with sensors for the operating voltage, clock signal frequency, temperature and electro magnetic radiation. The TOE falls into the defined secure state in case of a specified range violation7. In addition redundancy checks in specific software parts are used to detect failures and to react accordingly. The FPT_FLS.1 “Failure with preservation of secure state“ requirement is satisfied. The covered security functional requirements are FRU_FLT.2 and FPT_FLS.1. The SEF1 does not use probabilistic or permutational effects. 6.2 SEF2: Phase management with test mode lock-out The life cycle of the TOE is split-up in several phases. Chip development and production (phase 2, 3, 4) and final use (phase 4-7) is a rough split-up from TOE point of view. These phases are implemented in the SLE66CX322P with RSA2048 as test mode (phase 2, 3, 4) and user mode (phase 1, 4-7). In addition a chip identification mode exists which is active in all phases. During start-up of the SLE66CX322P with RSA2048 the decision for the user mode or the test mode is taken dependent on several phase identifiers (phase management). If test mode is the active phase the SLE66CX322P with RSA2048 requests authentication before any action (test mode lock-out). FMT_LIM.1 and FMT_LIM.2 are satisfied. 7 The operating state checking SEF1 can only work when the TOE is running and can not prevent reverse engineering. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 28/42 If the chip identification mode is requested the chip identification data (O.Identification) is reported. FAU_SAS.1 “Audit storage” is satisfied. The phase management is used to provide the separation between the security enforcing functions and the user software. FMT_SEP.1 “TSF domain separation“ is satisfied. The covered security functional requirements are FMT_LIM.1, FMT_LIM.2, FPT_SEP.1 and FAU_SAS.1. The test mode lock-out uses probabilistic or permutational effects and has to be included in the AVA_SOF analysis with SOF high. 6.3 SEF3: Protection against snooping Several mechanisms protect the SLE66CX322P with RSA2048 against snooping the design or the user data during operation and even if it is out of operation (power down). There are topological design measures for disguise, such as the use of the top metal layer with active signals for protecting critical data. The entire design is kept in a non standard way to prevent attacks using standard analysis methods. A Smartcard dedicated CPU with a non public bus protocol is used which makes analysis complicated. The covered security functional requirement is FPT_PHP.3 “Resistance to physical attack“ as these measures make physical analysis difficult. The protection against snooping uses probabilistic or permutational effects and has to be included in the AVA_SOF analysis with SOF high. 6.4 SEF4: Data encryption and data disguising The readout of data can be controlled with the use of encryption. Only the key owner has the possibility to read out data. An attacker can not use the data he has espionaged, because he must break the encryption. The memory contents of the SLE66CX322P with RSA2048 are encrypted on chip to protect against data analysis on stored data as well as on internally transmitted data. To prevent interpretation of leaked information randomness is inserted in the information. An interpretation of the leaked data is not possible as all the data is encrypted. The covered security functional requirements are FDP_ITT.1 “Basic internal transfer protection“ and FPT_ITT.1 “Basic internal TSF data transfer protection“. The encryption covers the data processing policy and FDP_IFC.1 “Subset information flow control“. The SEF4 uses probabilistic or permutational effects and has to be included in the AVA_SOF analysis with SOF high. 6.5 SEF5: Random number generation Random data is essential for cryptography as well as for physical security mechanisms. The SLE66CX322P with RSA2048 is equipped with a true random generator based on physical probabilistic controlled effects. The random data can be used from the user software as well as from the security enforcing functions. The generated numbers are true random due to the construction principle. The covered security functional requirement is FCS_RND.1. 6.6 SEF6: TSF self test The TSF of the SLE66CX322P with RSA2048 has either a hardware controlled self test which can be started from the user software or can be tested directly from the user software. The tested security enforcing function is SEF1, SEF5 and SEF7. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 29/42 As any attempt to modify the sensor devices will be detected from the test, the covered security functional requirement is FPT_TST.2. The TSF self test does not use probabilistic or permutational effects. 6.7 SEF7: Notification of physical attack The entire surface of the SLE66CX322P with RSA2048 is protected with the active shield. Attacks over the surface are detected when the shield lines are cut or get contact. The attempt to use an opened device will be detected. The covered security functional requirement is FPT_PHP.3. The SEF7 “Notification of physical attack” does not use probabilistic or permutational effects. 6.8 SEF8: Memory Management Unit (MMU) The MMU in the SLE66CX322P with RSA2048 gives the user software the possibility to define different access rights for memory areas. In case of a access violation the MMU will generate a non maskable interrupt (NMI). Then a interrupt service routine (ISR) can react on the access violation. The policy of setting up the MMU and specifying the memory ranges is defined from the user software the TOE provides only a well defined initialisation of the MMU which is specific for the TOE but not for the user software. As the TOE provides support for separation of memory areas the covered security functional requirements are FDP_ACC.1, FDP_ACF.1, FMT_MSA.3 and FMT_MSA.1. The SEF8 “Memory Management Unit” does not use probabilistic or permutational effects. 6.9 SEF9: Cryptographic Support The TOE is equipped with several hardware accelerators to support the standard cryptographic operations. This security enforcing function is introduced to include the cryptographic operation in the scope of the evaluation as the cryptographic function itself is not used from the TOE security policy. On the other hand these functions are of special interest for the use of the hardware as platform for the software. The components are a hardware DES encryption unit and a combination of software and hardware unit to support RSA cryptography and RSA key generation. As defined cryptographic operations are provided by the TOE, the covered security functional requirement is FCS_COP.1 and FCS_CKM.1 in case of the RSA key generation. The SEF9 does not use probabilistic or permutational effects. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 30/42 6.10 Mapping of Security Functional Requirements The justification of the mapping between Security Functional Requirements and the Security Enforcing Functions is given in sections 6.1-6.8. The results are shown in Table 10. Table 10: Mapping of SFR and SEF SEF 1 SEF 2 SEF 3 SEF 4 SEF 5 SEF 6 SEF 7 SEF 8 SEF 9 FAU_SAS.1 X FCS_RND.1 X FDP_IFC.1 X FDP_ITT.1 X FMT_LIM.1 X FMT_LIM.2 X FPT_FLS.1 X FPT_ITT.1 X FPT_PHP.3 X X FPT_SEP.1 X FRU_FLT.2 X FPT_TST.2 X FDP_ACC.1 X FDP_ACF.1 X FMT_MSA.3 X FMT_MSA.1 X FCS_COP.1 X FCS_CKM.1 X Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 31/42 6.11 Assurance Measures In Table 11 the TOE specific assurance measures are listed. These measures fulfil the requirements from Table 9. This Security Target is the first document in the course of an evaluation. The exact references (version numbers and date) of the documents are not final during the evaluation of the security target. To avoid an update of the security target at the end of the evaluation the exact references are listed in the configuration list of the evaluation. Table 11: Assurance measures Assurance Assurance Document Security Target ASE Security Target ACM_AUT.1 ACM_CAP.4 Configuration management (ACM) Configuration management ACM_SCP.3 Configuration management scope (ACM_SCP) ADO_DEL.2 Delivery and operation ADO_IGS.1 Delivery (ADO) ADV_FSP.3 Functional Specification (ADV_FSP.3) ADV_HLD.3 High Level Design (ADV_HLD.3) ADV_IMP.2 Implementation (ADV_IMP.2) ADV_INT.1 High Level Design (ADV_HLD.3) Low Level Design K1 SEC (ADV_LLD.1) Low Level Design K2 CPU (ADV_LLD.1) Low Level Design K3 RNG (ADV_LLD.1) Low Level Design K5 EEPROM (ADV_LLD.1) Low Level Design K6 ACE (ADV_LLD.1) Low Level Design K7 BUS (ADV_LLD.1) Low Level Design K10 XRAM (ADV_LLD.1) Low Level Design K11 ROM (ADV_LLD.1) Low Level Design K12 STS (ADV_LLD.1) Low Level Design K13 DDC (ADV_LLD.1) Low Level Design K4, K8, K9, K14, K15 ADV_LLD.1 Low Level Design K16 RSA (ADV_LLD.1) ADV_RCR.2 Representation Correspondance (ADV_RCR.2) Development ADV_SPM.3 LKW model AGD_ADM.1 Guidance documents AGD_USR.1 Documentation (AGD) ALC_DVS.1 ALC_LCD.2 Life cycle support ALC_TAT.2 Life Cycle Support (ALC) ATE_COV.2 ATE_DPT.2 ATE_FUN.1 Tests ATE_IND.2 Test Documentation (ATE) AVA_CCA.1 AVA_MSU.3 AVA_SOF.1 Vulnerability assessment AVA_VLA.4 Vulnerability Assessment (AVA) Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 32/42 7 PP claims 7.1 PP reference This security target is compliant to the Smartcard IC Platform Protection Profile . 7.2 PP tailoring The assignments and selections foreseen in the Smartcard IC Platform Protection Profile are done here. 7.2.1 FCS_RND The random numbers are generated from SEF5. The quality level of the random numbers is defined with the tests T0-T8 of the [AIS31]. FCS_RND.1 Quality metric for random numbers FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet the test criteria specified in tests T0-T8 of [AIS31]. 7.2.2 FAU_SAS.1 The audit storage is created in phase 3 and a change of the audit storage shall not be possible in later phases. The list of authorised users consists therefore only of the chip manufacturer. In the SEF3 a cryptographic function is used to ensure that only the chip manufacturer can access this record if the chip is in phase 3. In later phases the ability to change the audit storage is removed. The audit storage consists of the chiptype, serial number and firmware version. The exact coding is explained in the [Databook], chapter 7. FAU_SAS.1 Audit storage FAU_SAS.1.1 The TSF shall provide test personnel before TOE Delivery with the capability to the Initialisation Data and/or Pre-personalisation Data and/or supplements of the Smartcard Embedded Software in the audit records. 7.3 PP additions Additional objectives and security functional requirements are explicitly mentioned in this security target. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 33/42 8 Rational The rational from the Smartcard IC Platform Protection Profile is used here and it is not changed. The augmentations are designed to be conform to the rational of the Smartcard IC Platform Protection Profile . The necessary extensions to the Smartcard IC Platform Protection Profile rational are given in the following. 8.1 Security Objectives Rationale Assumption, Threat or Organisational Security Policy Security Objective Note P.Add-Functions O.Add-Functions The justification related to the security objective “Additional Specific Security Functionality (O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the same specific security functionality as required by P.Add-Functions, the organisational security policy is covered by the objective. Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys- Manipulation and O.Leak-Forced define how to implement the specific security functionality required by P.Add-Functions. (Note that these objectives support that the specific security functionality is provided in a secure way as expected from P.Add-Functions.) Especially O.Leak- Inherent and O.Leak-Forced refer to the protection of confidential data (User Data or TSF data) in general. User Data are also processed by the specific security functionality required by P.Add-Functions. Compared to Smartcard IC Platform Protection Profile a clarification has been made for the security objective “Usage of Hardware Platform (OE.Plat-Appl)”: If required the Smartcard Embedded Software shall use these cryptographic services of the TOE and their interface as specified. In addition, the Smartcard Embedded Software must implement functions which perform operations on keys (if any) in such a manner that they do not disclose information about confidential data. The non disclosure due to leakage A.Key-Function attacks is included in this objective OE.Plat-Appl. This addition ensures that the assumption A.Plat-Appl is still covered by the objective OE.Plat-Appl although additional functions are being supported according to O.Add-Functions. Compared to Smartcard IC Platform Protection Profile a clarification has been made for the security objective “Treatment of User Data (OE.Resp-Appl)”: By definition cipher or plain text data and cryptographic keys are User Data. So, the Smartcard Embedded Software will protect such data if required and use keys and functions appropriately in order to ensure the strength of cryptographic operation. Quality and confidentiality must be maintained for keys that are imported and/or derived from other keys. This implies that appropriate key management has to be realised in the environment. These measures make sure that the assumption A.Resp-Appl is still covered by the security objective OE.Resp-Appl although additional functions are being supported according to P.Add-Functions. The justification of the additional policy and the additional assumption show that they do not contradict to the rationale already given in the Protection Profile for the assumptions, policy and threats defined there. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 34/42 8.2 Security Requirements Rationale 8.2.1 Rationale for the security functional requirements Objective TOE Security Functional Requirements Security Requirements for the environment O.Add-Functions - FCS_COP.1 „Cryptographic operation“ - FCS_CKM.1 „Cryptographic key generation“ RE.Phase-1 “Design and Implementation of the Smartcard Embedded Software” with RE.Cipher The justification related to the security objective “Additional Specific Security Functionality (O.Add-Functions)” is as follows: The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly require those functions to be implemented which are demanded by O.Add-Functions. Therefore, FCS_COP.1 is suitable to meet the security objective. Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional functions are used as specified and that the User Data processed by these functions are protected as defined for the application context. These issues are addressed by the requirement RE.Phase-1 and more specific by the security functional requirements - [FDP_ITC.1 Import of user data without security attributes or FCS_CKM.1 Cryptographic key generation], - FCS_CKM.4 Cryptographic key destruction, - FMT_MSA.2 Secure security attributes. to be met by the environment. In case of the RSA2048 the TOE provides functionality to cover FCS_CKM.1. The other dependencies FCS_CKM.4 and FMT_MSA.2 must be covered from the environment (the smartcard embedded software) and are addressed by the requirement RE.Cipher. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement the specific security functionality. However, key-dependent functions could be implemented in the Smartcard Embedded Software. In this case RE.Cipher requires that these functions ensure that confidential data (User Data) can not be disclosed while they are just being processed by the Smartcard Embedded Software. Therefore, with respect to the Smartcard Embedded Software the issues addressed by the objectives just mentioned are addressed by the requirement RE.Cipher. The usage of cryptographic algorithms requires to use appropriate keys. Otherwise they do not provide security. The requirement RE.Cipher addresses these specific issues since cryptographic keys and other data are provided by the Smartcard Embedded Software. RE.Cipher requires that keys must be kept confidential. They must be unique with a very high probability, cryptographically strong etc. If keys are imported into the TOE (usually after TOE Delivery), it must be ensured that quality and confidentiality is maintained. Therefore, with respect to the environment the issues addressed (i) by the objectives just mentioned and (ii) implicitly by O.Add-Functions are addressed by the requirement RE.Cipher. The justification of the security objective and the additional requirements (both for the TOE and its environment) show that they do not contradict to the rationale already given in the Protection Profile for the assumptions, policy and threats defined there. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 35/42 FPT_TST.2 The security functional component Subset TOE security testing (FPT_TST.2) has been newly created (Common Criteria Part 2 extended). This component allows that particular parts of the security mechanisms and functions provided by the TOE can be tested after TOE Delivery. This security functional component is used instead of the functional component FPT_TST.1 from Common Criteria Part 2. For the user it is important to know which security functions or mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security functions being tested. In addition, FPT_TST.1 requires to verify the integrity of TSF data and stored TSF executable code which might violate the security policy. The tested security enforcing function is SEF1, SEF5 and SEF7. The security functional requirement FPT_TST.2 will detect any attempt to conduce a physical manipulation. The objective of FPT_TST.2 is O.Phys-Manipulation. The physical manipulation will be done to overcome security enforcing functions. SEF8: Memory Management Unit (MMU) Objective TOE Security Functional Requirements Security Requirements for the environment O.Add-Functions - FDP_ACC.1 “Subset access control” - FDP_ACF.1 “Security attribute based access control” - FMT_MSA.3 “Static attribute initialisation” - FMT_MSA.1 “Management of security attributes” RE.Phase-1 “Design and Implementation of the Smartcard Embedded Software” The justification related to the security objective “Additional Specific Security Functionality (O.Add-Functions)” is as follows: The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security Function Policy (SFP) “Memory Access Control Policy” exactly require to implement an area based memory access control as demanded by O.Add-Functions. Therefore, FDP_ACC.1 with its SFP is suitable to meet the security objective. Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional functions are used as specified and that the User Data processed by these functions are protected as defined for the application context. These issues are addressed by the requirement RE.Phase-1. The TOE only provides the tool to implement the policy defined in the context of the application. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 36/42 8.2.2 Dependencies of security functional requirements Security Functional Requirement Dependencies Fulfilled by security requirements in this PP FCS_COP.1 FCS_CKM.1 Yes FDP_ITC.1 (if not FCS_CKM.1) FCS_CKM.4 FMT_MSA.2 Yes (by the environment) In case of the RSA2048 the TOE provides functionality to cover FCS_CKM.1. The other dependencies FCS_CKM.4 and FMT_MSA.2 must be covered from the environment (the smartcard embedded software) and are addressed by the requirement RE.Cipher. Security Functional Requirement Dependencies Fulfilled by security requirements in this PP FPT_TST.2 FPT_AMT.1 See discussion below The following discussion demonstrates how the dependencies defined by Part 2 of the Common Criteria for the requirement FPT_TST.2 are satisfied. The dependency defined in the Common Criteria is Abstract machine testing (FPT_AMT.1). Part 2 of the Common Criteria explains that „the term ‚underlying abstract machine‘ typically refers to the hardware components upon which the TSF has been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated hardware and software combination behaving as a virtual machine upon which the TSF relies.“ The TOE is already a platform representing the lowest level in a Smartcard. There is no lower or “underlying abstract machine” used by the TOE which can be tested. There is no need to perform testing according to FPT_AMT.1 and the dependency in the requirement FPT_TST.2 is therefore considered to be satisfied. Security Functional Requirement Dependencies Fulfilled by security requirements in this PP FDP_ACC.1 FDP_ACF.1 Yes FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 Yes Yes FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 Yes See discussion below FMT_MSA.1 FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 Yes See discussion below The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is considered to be satisfied because the access control specified for the intended TOE is not role- Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 37/42 based but enforced for each subject. Therefore, there is no need to identify roles in form of an security functional requirement FMT_SMR.1. 8.2.3 Rationale for the Assurance Requirements and the Strength of Function Level The chosen assurance level EAL 5 augmented determines the assurance requirements. In Table 9 the different assurance levels are shown as well as the augmentations. The augmentations are not changed compared to the Protection Profile The assurance level EAL5 and the augmentation with the requirements ALC_DVS.2, AVA_MSU.3, and AVA_VLA.4 were chosen in order to meet assurance expectations. An assurance level of EAL5 is required for this type of TOE since it is intended to defend against highly sophisticated attacks without a protected environment. This evaluation assurance level was selected since it provides even a formal evidence on the conducted vulnerability assessment. In order to provide a meaningful level of assurance that the TOE provides an adequate level of defense against such attacks, the evaluators have access to all information regarding the TOE including the low level design and source code. The rational for the strength of function level from the Smartcard IC Platform Protection Profile is used as the level is not changed. 8.3 Security Requirements are Mutually Supportive and Internally Consistent In addition to the discussion in section 7.3 of the Smartcard IC Platform Protection Profile the security functional requirement FCS_COP.1 is introduced. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys- Manipulation and O.Leak-Forced also protect the cryptographic algorithms implemented according to the security functional requirement FCS_COP.1. Therefore, these security functional requirements support the secure implementation and operation of FCS_COP.1. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the self-test functions implemented according to the security functional requirement FPT_TST.2. Therefore, these security functional requirements support the secure implementation and operation of FPT_TST.2. The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the area based memory access control function implemented according to the security functional requirement described in the security functional requirement FDP_ACC.1 with reference to the Memory Access Control Policy and details given in FDP_ACF.1. Therefore, those security functional requirements support the secure implementation and operation of FDP_ACF.1 with its dependent security functional requirements. Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 38/42 9 References 9.1 Documents and User Guidance Table 12: User guidance [MaskTransfer] SLE 66CX320P Transfer of a ROM Mask from SLE 66CxxS to SLE CX320P 06.01 [AppRNG] Application Note, SLE66CxxxP, Testing the RNG, 09.00 [AppDES] Application Note, SLE66CxxxP, DDES - EC2 07.01 [AppMED] Application Note, SLE66CxxxP, Memory Encryption Decryption 07.00 [AppShield] Application Note, SLE66CxxxP, Using the active shield security feature 01.02 [Status] Status report, List of all avaliable application notes 01.02 [DataBook] Data Book, SLE66CxxxP 12.00 9.2 Literature Table 13: Protection Profile [ProtectionProfile] Smartcard IC Platform Protection Profile BSI-PP-0002; Version 1.0, July 2001 [AIS31] Functionality classes and evaluation methodology for physical random number generators AIS31, Version1, 25.9.2001 [ALGO] Geeignete Kryptoalgorithmen gemäß § 17 (2) SigV, Bundesanzeiger Nr. 213, 11.11.1999 [EESSI] Algorithms and Parameters for Secure Electronic Signatures EESSI-SG, V.1.44 DRAFT, 4.5.2001 9.3 List of abbreviations CC Common Criteria CI Chip Identification mode (STS-CI) CIM Chip Identification Mode (STS-CI), same as CI CPU Central Processing Unit CRC Cyclic Redundancy Check DPA Differential Power Analysis DFA Differential Failure Analysis EEPROM Electrically Erasable and Programmable Read Only Memory EMA Electro magnetic analysis HW Hardware Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 39/42 IC Integrated Circuit ID Identification I/O Input/Output IRAM Internal Random Access Memory ITSEC Information Technology Security Evaluation Criteria M Mechanism MED Memory Encryption and Decryption MMU Memory Management Unit MOVC MOVe Code O Object OS Operating system PLL Phase Locked Loop PROM Programmable Read Only Memory RAM Random Access Memory RMS Resource Management System RNG Random Number Generator ROM Read Only Memory S Subject SF Security function SFR Special Function Register, as well as Security Functional Requirement The specific meaning is given in the context SigG Signature law, see [SigG] SigV Signature regulation, see [SigV] SPA Simple power analysis STS Self Test Software SW Software SO Security objective T Threat TM Test Mode (STS) TOE Target of Evaluation UM User Mode (STS) UMC Production site in Taiwan XRAM eXtended Random Access Memory 9.4 Glossary Application Program/Data Software which implements the actual TOE functionality provided for the user or the data required for that purpose Threat Action or event that might prejudice security Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 40/42 Operating System Software which implements the basic TOE actions necessary for operation Central Processing Unit Logic circuitry for digital information processing Chip → Integrated Circuit Chip Identification Mode Operational status phase of the TOE, in which actions for identifying the individual chip take place Smart Card Plastic card in credit card format with built-in chip Controller IC with integrated memory, CPU and peripheral devices Cyclic Redundancy Check Process for calculating checksums for error detection Electrically Erasable and Programmable Read Only Memory (EEPROM) Nonvolatile memory permitting electrical read and write operations End User Person in contact with a TOE who makes use of its operational capability Firmware Part of the software implemented as hardware Hardware Physically present part of a functional system (item) Integrated Circuit Component comprising several electronic circuits implemented in a highly miniaturized device using semiconductor technology Internal Random Access Memory RAM integrated in the CPU Mechanism Logic or algorithm which implements a specific security function in hardware or software Memory Encryption and Decryption Method of encoding/decoding data transfer between CPU and memory Microcontroller → Controller Microprocessor → CPU Move Code Instruction in the CPU’s instruction set for transferring program memory contents to an internal register Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 41/42 Object Physical or non-physical part of a system which contains information and is acted upon by subjects Programmable Read Only Memory Nonvolatile memory which can be written once and then only permits read operations Random Access Memory Volatile memory which permits write and read operations Random Number Generator Hardware part for generating random numbers Read Only Memory Nonvolatile memory which permits read operations only Resource Management System Part of the firmware containing EEPROM programming routines Self Test Software Part of the firmware with routines for controlling the operating state and testing the TOE hardware Security Function Part(s) of the TOE used to implement part(s) of the security objectives Security Target Description of the intended state for countering threats Software Information (non-physical part of the system) which is required to implement functionality in conjunction with the hardware (program) Memory Hardware part containing digital information (binary data) Subject Entity, generally in the form of a person, who performs actions Target of Evaluation Product or system which is being subjected to an evaluation Test Mode Operational status phase of the TOE in which actions to test the TOE hardware take place User Mode Operational status phase of the TOE in which actions intended for the user take place Public SLE66CX322P with RSA2048 Security Target V1.0.5 Date: 06-05-2002 Page: 42/42 10 Definition of the Security Functional Component FPT_TST.2 The following additions are made to „TSF self test (FPT_TST)“ in Common Criteria: Component levelling FPT_TST TSF self test 1 2 FPT_TST.1 TSF testing, provides the ability to test the TSF’s correct operation. These tests may be performed at start-up, periodically, at the request of the authorised user, or when other conditions are met. It also provides the ability to verify the integrity of TSF data and executable code. FPT_TST.2 Subset TOE security testing, provides the ability to test the correct operation of particular security functions or mechanisms. These tests may be performed at start-up, periodically, at the request of the authorised user, or when other conditions are met. It also provides the ability to verify the integrity of TSF data and executable code. The security functional component family “Subset TOE testing (FPT_TST.2)” is specified as follows. FPT_TST.2 Subset TOE testing Hierarchical to: No other components. FPT_TST.2.1 The TSF shall run a suite of self tests [selection: during initial start- up, periodically during normal operation, at the request of the authorised user, and/or at the conditions [assignment: conditions under which self test should occur] to demonstrate the correct operation of [assignment: functions and/or mechanisms]. Dependencies: FPT_AMT.1 Abstract machine testing