CIU98N70 Secure Element V1.0 Security Target Lite ## Security target Lite of CIU98N70 Secure Element V1.0 Version 1.4 Date 2026-06-05 CEC Huada Electronic Design Co., Ltd. CIU98N70 Secure Element V1.0 Security Target Lite ####### REVISION HISTORY | 1.0 | 2026.02.03: Initial version, derived from full Security Target | |-------|------------------------------------------------------------------| | 1.1 | 2026.02.27: Synchronize revisions with the Security Target | | 1.2 | 2026.03.05: Update reference document versions | | 1.3 | 2026.05.21: Synchronize revisions with the Security Target | | 1.4 | 2026.06.05: Revised based on RDI monitor comments | 2 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### Content | Abbreviation ..................................................................................................................................... 5 | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Glossary ............................................................................................................................................ 6 | | 1 ST INTRODUCTION .................................................................................................................... 9 | | 1.1 ST Reference and TOE Reference ...................................................................................... 9 | | 1.1.1 ST Reference ............................................................................................................ 9 | | 1.1.2 TOE Reference ......................................................................................................... 9 | | 1.2 TOE Overview .................................................................................................................... 9 | | 1.2.1 Introduction .............................................................................................................. 9 | | 1.2.2 TOE usage and major security functionality .......................................................... 10 | | 1.2.3 TOE type ................................................................................................................ 11 | | 1.2.4 Required non-TOE hardware/software/firmware ................................................... 11 | | 1.3 TOE Description ............................................................................................................... 12 | | 1.3.1 Physical Scope of TOE .......................................................................................... 12 | | 1.3.2 Logical Scope of TOE ............................................................................................ 14 | | 1.3.3 TOE Life Cycle ...................................................................................................... 18 | | 2. Conformance Claims................................................................................................................... 19 | | 2.1 CC Conformance Claim .................................................................................................... 19 | | 2.2 PP Claim............................................................................................................................ 20 | | 2.3 Package Claim................................................................................................................... 21 | | 2.4 Conformance Claim Rationale .......................................................................................... 21 | | 3. Security Problem Definition ....................................................................................................... 22 | | 3.1 Description of Assets ........................................................................................................ 22 | | 3.2 Threats ............................................................................................................................... 22 | | 3.3 Organizational Security Policies ....................................................................................... 23 | | 3.4 Assumptions ...................................................................................................................... 24 | | Security Objectives ..................................................................................................................... 24 | | 4. | | 4.1 Security Objectives for the TOE ....................................................................................... 24 | | 4.2 Security Objectives for the Operational Environment ...................................................... 26 4.3 Security Objectives Rationale ........................................................................................... | | 27 | | 5. Extended Components Definition ............................................................................................... 28 | | 6. Security Requirements ................................................................................................................ 28 | | 6.1 Security Functional Requirements for the TOE ................................................................ 29 6.2 Security Assurance Requirements ..................................................................................... 44 | | 6.3 Security Requirements Rationale ...................................................................................... 45 | 3 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | 6.3.1 Rationale for the Security Functional Requirements.............................................. 45 | |----------------------------------------------------------------------------------------------------------------------------------------------------| | 6.3.2 Dependencies of Security Functional Requirements .............................................. 47 | | 6.3.3 Rationale for the Assurance Requirements ............................................................ 50 | | 6.3.4 Security Requirements are Internally Consistent ................................................... 51 | | 7 TOE summary specification ......................................................................................................... 54 | | 7.1 Protection against malfunction .......................................................................................... 54 | | 7.2 Protection against leakage ................................................................................................. 55 | | 7.3 Physical protection ............................................................................................................ 56 | | 7.4 Protection against abuse of functionality .......................................................................... 57 | | 7.5 Random number generator ................................................................................................ 58 | | 7.6 Cryptographic functionality .............................................................................................. 58 | | 7.7 Memory access control ..................................................................................................... 59 | | 8. Bibliography ............................................................................................................................... 60 | | 8.1 Evaluation Documents ...................................................................................................... 60 | | 8.2 Developer Documents ....................................................................................................... 60 | | 8.3 Other Documents .............................................................................................................. 60 | 4 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ##### Abbreviation AES CBC Advanced Encryption Standard Cipher Block Chaining CC Common Criteria CKMU ClocK Management Unit CMS Chip Management System CPU Central Processing Unit CRC Cyclic Redundancy Check DMA Direct Memory Access DES/TDES Data Encryption Standard/Triple Data Encryption Standard DFA Differential Fault Analysis ECB Electronic Codebook ECC Elliptic Curve Cryptography EDC Error Data Check EMMU Enhanced Memory Management Unit TZMU TrustZone Management Unit DTZR DMA TrustZone Register FA Fault Attack FLASH FLASH memory GCM Galois/Counter Mode GPIO General Purpose IO IC Integrated Circuit LD Laser Detector MAC Message Authentication Code MPU Memory Protection Unit PKE Public Key Engine PWMU PoWer Management Unit PP Protection Profile PUF Physical Unclonable Functions RAM Random Access Memory ROM Read-Only Memory RSA Rivest-Shamir-Adleman SFR Security Functional Requirements SCA Side Channel Attack SDL Security Delay Latch ST Security Target SWD Serial Wire Debug SWP Serial Wire Protocol TA Template Attack TOE Target of Evaluation TRNG True Random Number Generator 5 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### AHB2SFR AHB2SFR module executes SFR bus decoding and access control. ####### C4 parity check An integrity check method using CRC-4 algorithm to detect the data integrity error. ####### Debug mode The mode in which debug functions are available. ####### ECDH/ECDSA NIST standard algorithms based on Elliptic Curve Cryptography. ####### EFUSE EFUSE is an Electrical Fuse module which has 8 bits internal nonvolatile one-time programmable EFUSE storage and used for test mode protection. ####### End-user Users of the composite product in phase 7. ####### IC Dedicated Software IC dedicated software which is normally recognized as IC firmware and is developed by IC developer and embedded in a security IC. The IC dedicated software is mainly used for testing purpose (IC dedicated test software) but may provide additional services to facilitate usage of the hardware and/or to provide additional services (IC dedicated support software). ####### NVR NVR is the abbreviation of Nov-Volatile Register, which is implemented by a special block of FLASH. This special block of FLASH will occupy the address space which is invisible by users. ####### SecurCore The ARM CPU family contains a high-performance and highly energy efficient processors in it. ####### Security IC Composition of TOE, the security IC embedded software, user data and package (the security IC carrier). ####### Security IC Embedded Software Security IC embedded software supplies the security IC application and standard ##### Glossary 6 / 61 CIU98N70 Secure Element V1.0 Security Target Lite services and normally is developed other than IC designer. The embedded software is designed in phase 1 and embedded into the security IC in phase 3 or later phases of the security IC product life-cycle. In this document, the Security IC Embedded Software is also referred to as the user program. ####### Security IC Product Integration of security IC and Embedded software is evaluated as composite target of evaluation in sense of supporting document. ####### Sfr-registers Special Function Registers. ####### TOE Delivery The TOE is delivered in form of packaged product after phase 4. ####### Non-user FLASH The area of FLASH that users are not authorized to read or write. ####### RNG1 The hardware module implements the true random number generator. ####### RNG2 The hardware module implements the random number generator only used by the internal chip mechanisms. ####### User FLASH The area of FLASH that users are authorized to read or write. ####### pFlash Technology name defined by SMIC. ####### SCI The interface that is compliant with ISO/IEC 7816 standard. ####### Test mode The mode in which test functions are available. ####### Non-test mode The mode in which test functions are disabled and protected by hardware after the chip is sawed. ####### X25519 X25519 is an elliptic curve based Diffie-Hellmann key exchange algorithm in accordance with the Montgomery curve called Curve25519. 7 / 61 CIU98N70 Secure Element V1.0 Security Target Lite 8 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ### 1 ST INTRODUCTION This introduction chapter contains the following sections: - 1.1 Security Target Reference and TOE Reference - 1.2 TOE Overview - 1.3 TOE Description ### 1.1 ST Reference and TOE Reference #### 1.1.1 ST Reference The Security Target reference is 'Security target of CIU98N70 Secure Element V1.0, v1.4'. #### 1.1.2 TOE Reference The TOE is identified in one configuration named 'CIU98N70 Secure Element V1.0'. All components of the TOE and their respective version numbers are listed in Table 1 and Table 2. ### 1.2 TOE Overview #### 1.2.1 Introduction The TOE is the IC hardware with IC Dedicated Software and documentations which describes the instruction set and the usage [9] [10] [11] [12]. The CIU98N70 is a hardware platform which embeds a Secure Element Subsystem, supported by an integrated NFC Controller Subsystem and Power Management Unit. The TOE is a part (Secure Element Subsystem) of CIU98N70 chip. The main usage of the TOE is for SIM, eSE and eUICC applications. And the scope of the TOE includes the IC hardware and IC dedicated software and Document. The IC dedicated software is constituted of Chip Management System (CMS), Cryptographic and functional library and Lib file API library. CMS implements the functionality of booting process controlling. The Cryptographic and functional library implements the arithmetic functions of RSA (with key length from 1024 bits to 4096 bits), ECC (with ECDH/ECDSA/EC-SDSA/BDH), X25519, AES (with 128 bits, 192 bits and 256 bits key size) and TDES (with 2/3 keys mode) which are stored in Non-user FLASH. The Lib file API library also includes a random number generation function which is in form of Lib file API library files. 9 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The IC hardware is a microcontroller incorporating a central processing unit (CPU), Direct Memory Access (DMA) Controller, instruction/data cache, memories accessible via Enhanced Memory Management Unit (EMMU), TrustZone Management Unit (TZMU), Implementation Defined Attribution Unit (IDAU), cryptographic coprocessors, Random Number Generator (RNG), Physical Unclonable Functions (PUF), sensors, test protection, debug protection, clock/reset/power management units and communication interfaces. The CPU processor is a high-performance and highly energy efficient processor for the use in microcontrollers and embedded applications that require a performance optimized processor for the use in environments where security is an important consideration. On-chip memories are ROM, RAM and FLASH. The FLASH contains non-user FLASH and user FLASH for data and program storage. The whole FLASH consists of memory cells followed by the parity check values for data integrity check. The documentation includes: reference documents [9], [10], [11], [12]. #### 1.2.2 TOE usage and major security functionality Since a security IC is intended to be used in a potential insecure environment, it must provide high security in particular when being used by the embedded software in the SIM, eSE and eUICC applications. Hence the TOE shall maintain ： -  the integrity and the confidentiality of code and data stored in its memories and while processed in the device -  the memory access controlled by memory address and different chip modes -  the integrity, the correct operation and the confidentiality of security functionality provided by the TOE This is ensured by the construction of the TOE and its security functionalities. The TOE consists of one sub-TSF: -  Memory access control policy sub-TSF The TOE provides hardware for implementations of secure applications with: -  32-bit microprocessor CPU with security mechanisms -  Security detectors including temperature detectors, frequency detectors, voltage detectors, glitch detector and light detectors -  Active shielding against physical attacks -  TDES/DES coprocessor (2/3 keys TDES mode) with countermeasures against SCA -  AES coprocessor (with 128 bits, 192 bits and 256 bits key size) with countermeasures against SCA -  Hardware coprocessor PKE which facilitated the RSA, ECC (with 10 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ECDH/ECDSA/EC-SDSA/BDH) and X25519 implementations supporting large integer arithmetic operations of modular multiplication, modular addition, modular subtraction, point addition and point doubling. -  Memory access control enabled by chip modes 、 EMMU 、 TZMU 、 IDAU and DTZR （ Implementation within the DMA ） -  Memory data encryption and address scrambling -  Data integrity check for ROM, RAM and FLASH -  Security-sensitive registers protection -  Bus mask -  RNG1 module serves with a highly reliable true random number generator, which is compliant with PTG.2 class of AIS20/31[2013] [22] -  RNG2 module serves with internal random numbers, which is only used for security mechanism (e.g. masking) -  Test mode protection -  Debug mode protection -  Self-test function -  SDL -  PUF The TOE provides software for implementations of secure applications with: -  CMS is for booting process controlling -  Cryptographic and functional library for the functions of 2/3 key TDES, AES (with 128 bits, 192 bits and 256bits key size), ECC (with ECDH/ECDSA/ECSDSA/BDH), X25519 and private key functions of RSA (with key length from 1024 bits to 4096 bits) in non-user Flash -  Lib file API library for the functions of a highly reliable true random number generation API interface with FA countermeasures cooperating with hardware which is compliant with PTG.2 class of AIS20/31[2013], a deterministic random number generation API with FA countermeasures which is compliant with DRG.3 class of AIS20/31[2013]. #### 1.2.3 TOE type The TOE is CIU98N70 Secure Element V1.0 intended for use as a security IC. #### 1.2.4 Required non-TOE hardware/software/firmware Non-TOE content includes ： -  NFC Controller Subsystem: a near-field communication (NFC) compatible 11 / 61 CIU98N70 Secure Element V1.0 Security Target Lite device that comprises a contactless front-end, which securely communicates with CIU98N70 Secure Element V1.0 via SMB. -  Power Management Unit: controls power cycling of the NFC Controller Subsystem and CIU98N70 Secure Element V1.0. ### 1.3 TOE Description #### 1.3.1 Physical Scope of TOE The CIU98N70 Secure Element V1.0 is manufactured in 40nm pFlash technology, Only 'WLCSP' package form is available. A block diagram of the IC is depicted in Figure 1. Figure 1 : Hardware Blocks of the TOE The scope of the TOE includes the IC hardware and IC Dedicated Software are listed in Table 1. Table 1 : Components of the TOE scope | Type | Name | Release | Form of delivery | |--------|--------|-----------|--------------------| 12 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | IC Hardware | CIU98N70_SE | V1.0 | V1.0 | WLCSP packaged chip | WLCSP packaged chip | |-----------------------|--------------------------------------|--------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Security IC Dedicated | CMS | V1.0 | V1.0 | In non-user FLASH | In non-user FLASH | | Software | Cryptographic and functional library | V1.0 | V1.0 | In non-user FLASH (APIs of RSA, TDES, DES, AES, SHA, ECC (with ECDH/ECDSA/EC-SDSA/BDH), X25519, Chinese domestic cryptographic algorithms, Flash operation and version-get.) | In non-user FLASH (APIs of RSA, TDES, DES, AES, SHA, ECC (with ECDH/ECDSA/EC-SDSA/BDH), X25519, Chinese domestic cryptographic algorithms, Flash operation and version-get.) | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | CIU98N70_RNG.lib | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | CIU98N70_RNG.h | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | HED_API_ChipID.lib | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | HED_API_ChipID.h | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | CIU98N70_NVM_Switc h.lib | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | CIU98N70_NVM_Switc h.h | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | HED_FWAPI_TotalVers ion.lib | | | Lib file API library | V1.0 | V1.0 | Lib file (APIs of random number generation function, Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get) | HED_FWAPI_TotalVers ion.h | The lib files (.lib and .h files) will be delivered as the package with pgp signed and encrypted via Email. The delivery method for the chips is described in section 2.1 of Preparative procedures [10]. The identification data for all TOE components is also described in section 3.2 of Preparative procedures [10]. The scope of the TOE includes Document are listed in Table 2: Table 2 : Common Components of the TOE | Type | Name | Release | Form of delivery | |----------|---------------------------------------------|-----------|-----------------------------| | Document | Operational User Guidance [9] | V1.3 | The PDF Electronic Document | | Document | Preparative procedures [10] | V1.2 | The PDF Electronic Document | | Document | Product Datasheet [11] | V1.2 | The PDF Electronic Document | | Document | Crypto and Function Library User Guide [12] | V1.2 | The PDF Electronic Document | The electronic documents (.pdf files) will be delivered as the package with pgp signed and encrypted via Email. 13 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #### 1.3.2 Logical Scope of TOE ##### 1.3.2.1 Hardware Description The hardware blocks of the TOE are shown in figure 1. The main blocks are described as following: ####### CPU The CPU used in the TOE. ####### DMA controller DMA controller for data transfer from memory to peripheral, peripheral to memory, memory to memory. ####### Memory ROM, SYSRAM, Cache RAM, PKE RAM, MMURAM and FLASH are presented in the TOE. ####### MPU Supported by CPU. ####### EMMU Area and chip mode based memory access control to RAM and FLASH is implemented by EMMU. ####### TZMU TZMU is the TrustZone management units, the responsible for all security configurations of the chip's entire peripherals, RAM, Flash, ROM and DMA master. ####### Coprocessors -  The TDES/DES coprocessor supports TDES and DES operations with ECB mode and CBC mode. TDES supports 2-key/3-key operation with two/three 56-bit keys (key length of 112/168 bits). The TDES/DES coprocessor supports countermeasures against SCA. -  The PKE coprocessor supplies basic arithmetic functions to support the implementation of asymmetric cryptographic algorithms RSA, ECC (with ECDH/ECDSA/EC-SDSA/BDH), X25519, SM9 and SM2 in Cryptographic and functional library. Among which SM2 and SM9 are not covered by SFRs of the TOE. -  The AES coprocessor supports the AES operations with ECB, CBC, CTR and GCM mode. The AES coprocessor supports countermeasures against SCA. -  The Chinese domestic cryptographic coprocessors of SM3, SM4 and ZUC support SM3, SM4 and ZUC operations respectively. These functions are not covered by 14 / 61 CIU98N70 Secure Element V1.0 Security Target Lite SFRs of the TOE. ####### TRNG (RNG1) A highly reliable true random number generator compliant with PTG.2 class of AIS20/31[2013], which consists of a provable physical noise source and well-designed post-processor. ####### Internal random number generator (RNG2) The random number generator is for the internal use of the chip which is invisible by the user. ####### PUF PUF is used for key generation. ####### TEST The test functionalities and test mode protection is implemented in the TEST block. The test mode is protected by the TEST block and not available anymore after phase 4. ####### DEBUG The debug functionalities are implemented in the SWD block and CPU block, and the debug mode protection is implemented in the SEC block. ####### Power (PWMU) The TOE provides 4 power modes for chip power management. ####### SEC Security management module supports the active shielding working and auto-check, detectors auto-check, memory data encryption key and memory address scrambling key refreshing, security features flags management and debug enable control. ####### Reset (RSTMU) System reset management module supports the boot-up sequence and the reset mechanisms of the chip. ####### Clock (CKMU) Chip clock management module supports the configurations for the clock frequency settings of system and coprocessors. ####### Interfaces -  SCI module supports ISO/IEC 7816 Interface and proprietary factory code exporting. -  GPIO 15 / 61 CIU98N70 Secure Element V1.0 Security Target Lite -  I2C -  I3C -  SMB -  SPI ####### Detectors Detectors are for extreme environmental conditions detection. Detectors present the self-test feature. ####### Other major components -  Programmable timers -  Watchdog -  Oscillator (OSC) The TOE can be configured by software using special function registers that influence the hardware behavior of the TOE. The registers shall be set according the corresponding software guidance [9]. For security reasons the data sheet and security guidance will not be published but only delivered to the security IC embedded software developer of the composite product. The TOE supports Test Mode and Non-Test Mode. Test Mode has unlimited access to the hardware components, and is only valid during manufacture. Non-test Mode has restricted access to the hardware components, like CPU, special function registers and the memories. Special function registers for the hardware components control for the Security IC Embedded Software are interrelated to the activities of the CPU, DMA controller, MPU, EMMU, TZMU, IDAU, interrupt control, I/O configuration, FLASH, timers, interfaces and coprocessors. Sensitive registers protection, which is data integrity check, is performed on the sensitive registers. The end-user will receive TOE running in Non-test Mode with disabled test functionality. The disabling of the test functionality is performed after production testing and protected by hardware countermeasures. Debug Mode is a submode under Non-test Mode and has limited access used for debug purpose only. The disabling of the debug functionality is performed after production debugging and protected by hardware countermeasures. ##### 1.3.2.2 Software Description The IC Dedicated Software includes CMS, cryptographic and functional library and Lib file API library. 16 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### CMS CMS is for booting process controlling. The user program which is downloaded during the manufacture will be booted at the end of CMS execution. The download process is disabled when the TOE is delivered. ####### Cryptographic and functional library Cryptographic and functional library includes the functions of TDES, AES, ECC (with ECDH/ECDSA/EC-SDSA/BDH), X25519 and RSA with key length from 1024 bits to 4096 bits. TDES Cryptographic library supports countermeasures against TA, DFA and FA. DES Cryptographic library supports countermeasures against TA, DFA and FA. AES Cryptographic library supports countermeasures against TA, DFA and FA. ECC (with ECDH/ECDSA/EC-SDSA/BDH) Cryptographic library supports countermeasures against SCA, DFA and FA. X25519 Cryptographic library supports countermeasures against SCA, DFA and FA. RSA Cryptographic library supports countermeasures against SCA, DFA and FA. The Common curve parameters supported by ECC function library include: EC_brainpoolP256r1, EC_brainpoolP256t1, EC_brainpoolP320r1, EC_brainpoolP320t1, EC_brainpoolP384r1, EC_brainpoolP384t1, EC_brainpoolP512r1, EC_brainpoolP512t1, EC_nistp256, EC_nistp384, EC_nistp521, EC_SECG_PRIME_256K1, EC_secp224r1, EC_SM2, EC_frp256V1 Cryptographic and functional library also includes the functions of Chinese domestic cryptographic algorithms (with SM2, SM3 and SM4 and SM9 included), but these are not covered by SFRs of the TOE. ####### Lib file API library Lib file API library includes the functions of a highly reliable true random number generation API interface with FA countermeasures cooperating with hardware which is compliant with PTG.2 class of AIS20/31[2013], a deterministic random number generation API with FA countermeasures which is compliant with DRG.3 class of AIS20/31[2013]. Lib file API library also includes the functions of Enhancing Chip Stability Solution, chipID-get and Lib file API library version-get. Although these functions are not covered by the SFRs of the TOE, they are included within the TOE boundary as they constitute components of the deliverable. 17 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #### 1.3.3 TOE Life Cycle The complex development and manufacturing processes of a Composite Product can be separated into seven distinct phases. The phases 2 and 3 of the Composite Product life cycle cover the IC development and production: -  IC Development (Phase 2) - IC design - IC Dedicated Software development -  The IC Manufacturing (Phase 3) - Integration and photomask fabrication - IC production - IC testing - Preparation and pre-personalization if necessary - Embedded software integration · The Composite Product life cycle phase 4 included in the evaluation of the IC: -  The IC Packaging (Phase 4) - Security IC packaging (and testing) - Pre-personalization if necessary In addition, three important stages have to be considered in the Composite Product life cycle: -  Security IC Embedded Software Development (Phase 1) -  The Composite Product personalization and testing stage where the User Data is loaded into the Security IC's memory (Personalization Phase 6) -  The Composite Product usage by its issuers and consumers (Operational Usage Phase 7) which may include loading and other management of applications in the field 18 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Figure 2 : Definition of 'TOE Delivery' and responsible Parties The Security IC Embedded Software is developed outside the TOE development in Phase 1. The TOE is developed in Phase 2, followed by production and embedded software integration in Phase 3. Then the TOE is delivered after phase 4 with IC packaged. The 'Composite Product Manufacturer' includes all roles responsible of the TOE during phase 1 and 6. The CMS loader function is disabled before the delivery of the TOE. ## 2. Conformance Claims This chapter is divided into the following sections: - 2.1 CC Conformance Claim - 2.2 PP Claim - 2.3 Package Claim - 2.4 Conformance Claim Rationale ### 2.1 CC Conformance Claim This Security Target and the TOE claims conformance to CC:2022 of Common Criteria for Information Technology Security Evaluation according to: 19 / 61 CIU98N70 Secure Element V1.0 Security Target Lite -  Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model, CC:2022, Revision 1, November 2022, CCMB2022-11-001 -  Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, CC:2022, Revision 1, November 2022, CCMB-2022-11002 -  Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, CC:2022, Revision 1, November 2022, CCMB-2022-11003 -  Common Criteria for Information Technology Security Evaluation Part 4: Framework for the specification of evaluation methods and activities, CC:2022, Revision 1, November 2022, CCMB-2022-11-004 -  Common Criteria for Information Technology Security Evaluation Part 5: Predefined packages of security requirements, CC:2022, Revision 1, November 2022, CCMB-2022-11-005 -  Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1) , V1.2, 2025-10-15 For the evaluation the following methodology will be used: -  Common Methodology for Information Technology Security Evaluation: Evaluation Methodology, CEM:2022, Revision 1, November 2022, CCMB-202211-006 -  Transition Policy to CC:2022 and CEM:2022, April 20th 2023, CCMC-2023-04001 This Security Target claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security Functional Requirements are defined in chapter 5. ### 2.2 PP Claim This Security Target claims strict conformance to the Protection Profile: -  Security IC Platform Protection Profile, Version 1.0, 13.01.2014, registered and certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0084 The short term for this Protection Profile used in this document is 'BSI-PP-0084' or 'PP'. Since the Security Target claims conformance to this PP, the concepts are used in the same sense. For the definition of terms refer to the BSI-PP-0084, these terms also apply to this Security Target. The TOE provides additional functionality, which is not covered in PP. In accordance with Application Note 4 and 5 of the BSI-PP-0084, this additional functionality is added using the policy 'P.Crypto-Service' (see Section 3.3 of this Security Target for details) and 'T.Unauthorized-Access' (see Section 3.2 of this Security Target for details). 20 / 61 CIU98N70 Secure Element V1.0 Security Target Lite All standard components used by PP are identical between CCv3.1 revision 5 and CC:2022 revision 1. The FCS_RNG.1, FMT_LIM.1, FMT_LIM.2 and FDP_SDC.1 extended components from PP have been replaced with their counterparts from CC:2022 part 2. The wording is similar and therefore the components are equivalent. ### 2.3 Package Claim The Security Target is modularized as a multi-assurance Security Target as detailed in section 2.4. ### 2.4 Conformance Claim Rationale This Security Target claims strict conformance to the Security IC Platform Protection Profile (BSI-PP-0084). The Security Target is modularized as a multi-assurance Security Target. The Security Target claims a global conformance to EAL5 augmented with ADV_IMP.2, ADV_INT.3, ADV_TDS.5, ALC_CMC.5, ALC_DVS.2, ALC_TAT.3, ATE_COV.3, ATE_FUN.2, and AVA_VAN.5, ALC_FLR.2. This Security Target claims conformance to assurance package EAL6 augmented with ALC_FLR.2 for the following sub-TSFs: -  memory access control policy The TOE type defined in this Security Target is security IC which is consistent with the TOE definition in Security IC Platform Protection Profile. All sections of this Security Target, in which security problem definition, objectives and security requirements are defined, clearly state which of these items are taken from PP and which are added in this Security Target. Therefore, this is not repeated here. Moreover, all additionally stated items in this Security Target do not contradict the items included from the BSI-PP-0084 (see the respective sections in this document). The operations done for the SFRs taken from PP are also clearly indicated. 21 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The evaluation assurance level claimed for this target (EAL6+) is shown in section 6.2 to include respectively exceed the requirements claimed by the BSI-PP-0084. These considerations show that the Security Target correctly claims strict conformance to PP. ## 3. Security Problem Definition This Security Target claims conformance to the BSI-PP-0084 'Security IC Protection Profile'. Assets, threats, assumptions and organizational security policies are taken from PP. This chapter lists these assets, threats, assumptions and organizational security policies, and describes extensions to these elements in detail. ### 3.1 Description of Assets The assets of the TOE are all assets described in section 3.1 of 'Security IC Platform Protection Profile'. ### 3.2 Threats Since this Security Target claims strict conformance to the BSI-PP-0084 'Security IC Protection Profile', the threats defined in section 3.2 of PP are valid for this Security Target. The threats defined in PP are listed below in Table 3: Table 3 : Threats defined by the BSI-PP-0084 | Name | Title | |---------------------|-----------------------------------------| | T.Leak-Inherent | Inherent Information Leakage | | T.Phys-Probing | Physical Probing | | T.Malfunction | Malfunction due to Environmental Stress | | T.Phys-Manipulation | Physical Manipulation | | T.Leak-Forced | Forced Information Leakage | | T.Abuse-Func | Abuse of Functionality | | T.RND | Deficiency of Random Numbers | The TOE provides access control to the memories and to hardware resources. The TOE shall avert the threat 'Unauthorized Memory or Hardware Access 22 / 61 CIU98N70 Secure Element V1.0 Security Target Lite (T.Unauthorized-Access)' as specified below. T.Unauthorized-Access Unauthorized Memory or Hardware Access Adverse action: Threat agent: An attacker may try to read, modify or execute code or data stored in restricted memory areas. And or an attacker may try to access or operate hardware resources that are restricted by executing code. Attacker ： malicious embedded software Asset: IC Dedicated Software stored in protected memory areas. Table 4: Additional threats averted by the TOE | Name | Title | |-----------------------|----------------------------------------| | T.Unauthorized-Access | Unauthorized Memory or Hardware Access | ### 3.3 Organizational Security Policies Since this Security Target claims strict conformance to the BSI-PP-0084 'Security IC Protection Profile', the policy P.Process-TOE 'Protection during TOE Development and Production' in PP is applied here as well. In accordance with Application Note 5 in PP there is one additional policy defined in this Security Target as detailed below. The TOE provides specific security functionality, which can be used by the Security IC Embedded Software. In the following, specific security functionality is listed, which is not derived from threats identified for the TOE's environment. It can only be decided in the context of the application against which threats the Security IC Embedded Software will use this specific security functionality. The IC Developer/Manufacturer therefore applies the policies as specified below: P.Crypto-Service Cryptographic services of the TOE The TOE provides secure hardware based cryptographic services for the IC Embedded Software: -  DES/TDES encryption and decryption -  AES encryption and decryption -  private key functions of RSA (with key length from 1024 bits to 4096 bits) -  ECC (with ECDH/ECDSA/EC-SDSA/BDH) -  X25519 23 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ### 3.4 Assumptions Since this Security Target claims strict conformance to the BSI-PP-0084 'Security IC Protection Profile' the assumptions defined in section 3.4 of PP are valid for this Security Target. The following table lists these assumptions. Table 5: Assumptions defined in the BSI-PP-0084 | Name | Title | |------------------|------------------------------------------------------------| | A.Process-Sec-IC | Protection during Packaging, Finishing and Personalization | | A.Resp-Appl | Treatment of User Data | ## 4. Security Objectives This chapter contains the following sections: 'Security Objectives for the TOE', 'Security Objectives for the Operational Environment' and 'Security Objectives Rationale'. ### 4.1 Security Objectives for the TOE The TOE shall provide the following security objectives, which are taken from the BSIPP-0084 'Security IC Protection Profile'. Table 6 : Security objectives defined in the BSI-PP-0084 | Name | Title | |---------------------|-------------------------------------------------| | O.Leak-Inherent | Protection against Inherent Information Leakage | | O.Phys-Probing | Protection against Physical Probing | | O.Malfunction | Protection against Malfunctions | | O.Phys-Manipulation | Protection against Physical Manipulation | | 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 following additional security objectives are defined based on package functionality provided by the TOE as specified below: O.TDES TDES Functionality The TOE shall provide the cryptographic functionality to calculate a Triple DES encryption and decryption to the Security IC Embedded Software. The TOE supports directly the calculation of TDES with up to two/three keys. 24 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Note: The TOE will ensure the confidentiality of the User Data (and especially cryptographic keys) during Triple DES operation. This is supported by O.Leak-Inherent. ###### O.AES AES Functionality The TOE shall provide the cryptographic functionality to calculate a AES encryption and decryption to the Security IC Embedded Software. Note: The TOE will ensure the confidentiality of the User Data (and especially cryptographic keys) during AES operation. This is supported by O.Leak-Inherent. ###### O.RSA RSA functionality The TOE shall provide cryptographic functionality to perform an RSA signature generation and decryption with key lengths from 1024 to 4096 bits to the Security IC Embedded Software. ###### O.ECC ECC functionality The TOE shall provide cryptographic functionality to perform an ECC signature generation and key exchange to the Security IC Embedded Software. ###### O.X25519 X25519 functionality The TOE shall provide cryptographic functionality to perform a Curve25519 based key exchange to the Security IC Embedded Software. Regarding Application Notes 8 and 9 in PP the following additional security objectives are defined based on additional functionality provided by the TOE as specified below: 25 / 61 CIU98N70 Secure Element V1.0 Security Target Lite O.MEM-ACCESS Chip mode and Area based Memory Access Control Access by processor instructions and DMA controller to memory areas is controlled by the TOE. ### 4.2 Security Objectives for the Operational Environment The following security objectives for the operational environment are specified according to the BSI-PP-0084 'Security IC Protection Profile'. Table 7 : Security objectives for the operational environment, taken from PP | Security objective | Description | Applies to phase… | |----------------------|---------------------------------------------------|---------------------------------------| | OE.Process-Sec-IC | Protection during composite product manufacturing | TOE delivery up to the end of phase 6 | | OE.Resp-Appl | Treatment of user data of the Composite TOE | Phase 1 | Appropriate 'Protection during Packaging, Finishing and Personalization (OE.ProcessSec-IC)' must be ensured after TOE Delivery up to the end of Phases 6, as well as during the delivery to Phase 7 as specified below. OE.Process-Sec-IC Protection during composite product manufacturing Security procedures shall be used after TOE Delivery up to delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorized use). The Security IC Embedded Software shall provide 'Treatment of user data of the Composite TOE (OE.Resp-Appl)' as specified below. OE.Resp-Appl Treatment of user data of the Composite TOE Security relevant user data of the Composite TOE (especially cryptographic keys) are treated by the Security IC Embedded Software as required by the security needs of the specific application context. For the specific requirements of OE.Resp-Appl, please refer to Section 1.2 of the Operational User Guidance (AGD_OPE). 26 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ### 4.3 Security Objectives Rationale Section 4.4 in the BSI-PP-0084 'Security IC Protection Profile' provides a rationale how the assumptions, threats, and organizational security policies are addressed by the objectives that are specified in the BSI-PP-0084. Table 8 reproduces the table in section 4.4 of PP. Table 8 : Security Objectives versus Assumptions, Threats or Policies | Assumption, Threat or Organizational Security Policy | Security Objective | Notes | |--------------------------------------------------------|----------------------|------------------------------| | A.Resp-Appl | OE.Resp-Appl | Phase 1 | | P.Process-TOE | O.Identification | Phase 2 - 3 optional Phase 4 | | A.Process-Sec-IC | OE.Process-Sec-IC | Phase 6 optional Phase 4 | | T.Leak-Inherent | O.Leak-Inherent | | | T.Phys-Probing | O.Phys-Probing | | | T.Malfunction | O.Malfunction | | | T.Phys-Manipulation | O.Phys-Manipulation | | | T.Leak-Forced | O.Leak-Forced | | | T.Abuse-Func | O.Abuse-Func | | | T.RND | O.RND | | The following table provides the justification for the additional security objectives. They are in line with the security objectives of the BSI-PP-0084 and supplement these according to the additional threats and organizational security policies. Table 9 provides the justification for the additional security objectives. They are in line with the security objectives of PP and supplement these according to the additional assumptions, threat and organizational security policy. Table 9 : Additional Security Objectives versus Assumptions, Threats or Policies | Assumption, Threat or OSP | Security Objective | Note | |-----------------------------|-----------------------------------|--------| | T.Unauthorized-Access | O.Mem-Access | | | P.Crypto-Service | O.TDES O.AES O.RSA O.ECC O.X25519 | | 27 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The justification of the additional policy, threat and assumption is given in the following description. The justification related to the threat 'Unauthorized Memory or Hardware Access (T.Unauthorized-Access)' is as follows: According to O.Mem-Access the TOE must enforce the partitioning of memory areas so that access to memory areas is controlled. Thereby security violations caused by accidental or deliberate access to restricted data (which may include code) can be prevented (refer to T.Unauthorized-Access). The threat T.Unauthorized-Access is therefore countered if the objective is met. The justification related to the security objectives O.TDES, O.AES, O.RSA, O.ECC and O.X25519 is as follows: Since these objectives require the TOE to implement exactly the same specific security functionality as required by P.Crypto-Service, the organizational security policy is covered by the objectives. The justification of the additional policy and the additional assumptions show that they do not contradict to the rationale already given in the BSI-PP-0084 for the assumptions, policy and threats defined there. ## 5. Extended Components Definition There is one extended family defined and described for the TOE: -  the family FAU_SAS at the class FAU Security Audit The extended component FAU_SAS.1 is defined and described in the BSI-PP-0084 section 5. ## 6. Security Requirements This part of the Security Target defines the detailed security requirements that shall be satisfied by the TOE. The statement of TOE security requirements shall define the functional and assurance security requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. This chapter consists of the sections 'Security Functional Requirements', 'Security Assurance Requirements' and 'Security Requirements Rationale'. The CC allows several operations to be performed on security requirements (on the component level); refinement, selection, assignment, and iteration are defined in paragraph 8.2 of Part 1 of the CC [1]. These operations are used in the PP [8] and in this Security Target, respectively. 28 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The refinement operation is used to add details to requirements, and, thus, further restricts a requirement. Refinements of security requirements are denoted in such a way that added words are in bold text and changed words are crossed out. The selection operation is used to select one or more options provided by the PP [8] or CC in stating a requirement. Selections having been made are denoted as italic text. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignments having been made are denoted by showing as italic text. The iteration operation is used when a component is repeated with varying operations. It is denoted by showing brackets '[ iteration indicator ]' and the iteration indicator within the brackets. ### 6.1 Security Functional Requirements for the TOE The security functional requirements (SFR) for the TOE are defined and described in PP section 6.1 and in the following description. The Table 10 provides an overview of the functional security requirements of the TOE, defined in PP [8] section 6.1. In the last column it is marked if the requirement is refined. The refinements are also valid for this ST. Table 10 : Security functional requirements defined in PP | SFR | Title | Refined in PP | Origin | |-----------|-------------------------------------------|-----------------|----------------------------------------------------------------------------| | FRU_FLT.2 | Limited fault tolerance | Yes | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FPT_FLS.1 | Failure with preservation of secure state | Yes | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FMT_LIM.1 | Limited capabilities | No | Defined in the standard component of CC:2022 and extended component of | 29 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | | | | BSI-PP-0084, updated in CC:2022 | |-----------|---------------------------------------------|-----|--------------------------------------------------------------------------------------------------------| | FMT_LIM.2 | Limited availability | No | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FAU_SAS.1 | Audit storage | No | Only defined in the extended component of BSI-PP-0084 | | FPT_PHP.3 | Resistance to physical attack | Yes | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FDP_SDI.2 | Stored data integrity monitoring and action | No | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FDP_SDC.1 | Stored data confidentiality | No | Defined in the standard component of CC:2022 and extended component of BSI-PP-0084, updated in CC:2022 | | FDP_ITT.1 | Basic internal transfer protection | Yes | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FPT_ITT.1 | Basic internal TSF data transfer protection | Yes | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FDP_IFC.1 | Subset information flow control | No | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | | FCS_RNG.1 | Random number generation | No | Defined in the standard component of CC:2022 and equivalent to BSI-PP-0084 | The above extended component FAU_SAS.1 is introduced in PP to define the IT security functional requirements of the TOE as additional families FAU_SAS of Class FAU. This family describes the functional requirements for the Test Features of the TOE. 30 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The above SFRs are applied entirely to the ST. The application notes from the PP are elaborated below: #######  FRU_FLT.2 The TOE shall meet the requirement 'Limited fault tolerance (FRU_FLT.2)' as specified below. | FRU_FLT.2.1 | Failure with preservation of secure state | |-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FRU_FLT.2.1 | The TSF shall ensure the operation of all the TOE's capabilities when the following failures occur: exposure to operating conditions which are not detected according to the requirement Failure with preservation of secure state (FPT_FLS.1) 1 . | | Refinement: | The term 'failure' above also covers 'circumstances'. The TOE prevents failures for the 'circumstances' defined above. | | Application note: | Environmental conditions include but are not limited to power supply, clock, and other external signals (e.g. reset signal) necessary for the TOE operation. This address Application Note 13 in PP [8]. | #######  FPT_FLS.1 The TOE shall meet the requirement 'Failure with preservation of secure state (FPT_FLS.1)' as specified below. | FPT_FLS.1 | Failure with preservation of secure state | |-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FPT_FLS.1.1 | The TSF shall preserve a secure state when the following types of failures occur: exposure to operating conditions which may not be tolerated according to the requirement Limited fault tolerance (FRU_FLT.2) and where therefore a malfunction could occur 2 . | 31 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Refinement: The term 'failure' above also covers 'circumstances'. The TOE prevents failures for the 'circumstances' defined above. Application note: The failures will cause an alarm signals to be triggered, which will result in a special function register bit to be set and a reset (secure state). This address Application Note 14 in PP [8]. Generation of additional audit data is not defined for 'Limited fault tolerance' (FRU_FLT.2) and 'Failure with preservation of secure state' (FPT_FLS.1). This address Application Note 15 in PP [8]. #######  FMT_LIM.1 The TOE shall meet the requirement 'Limited capabilities (FMT_LIM.1)' as specified below. FMT_LIM.1 Limited capabilities FMT_LIM.1.1 #######  FMT_LIM.2 The TOE shall meet the requirement 'Limited availability (FMT_LIM.2)' as specified below. FMT_LIM.2 Limited availability FMT_LIM.2.1 The TSF shall be designed in a manner that limits its availability so that in conjunction with 'Limited capabilities (FMT_LIM.1)' the following policy is enforced: Deploying 1 [assignment: Limited capability and availability policy ] The TSF shall limit its capabilities so that in conjunction with 'Limited availability (FMT_LIM.2)' the following policy is enforced: Deploying Test Features after TOE Delivery does not allow user data of the Composite TOE to be disclosed or manipulated, TSF data to be disclosed or manipulated, software to be reconstructed and no substantial information about construction of TSF to be gathered which may enable other attacks 1 . 32 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #######  FPT_PHP.3 The TOE shall meet the requirement 'Resistance to physical attack (FPT_PHP.3)' as specified below. FPT_PHP.3 Resistance to physical attack FPT_PHP.3.1 Refinement: The TSF shall resist physical manipulation and physical probing 2 to the TSF 3 by responding automatically such that the SFRs are always enforced. The TSF will implement appropriate mechanisms to continuously counter physical manipulation and physical probing. Due to the nature of these attacks (especially manipulation) the TSF can by no means detect attacks on all of its elements. Therefore, permanent protection against these attacks is required ensuring that security functional requirements are enforced. Hence, 'automatic response' means here (i) assuming that there might be an attack at any time and (ii) countermeasures are provided at any time. Application note: If a physical manipulation or physical probing attack is detected, an alarm will be automatically triggered by the hardware, which will cause the chip to be reset. This address Application Note 19 in PP [8]. All assignments and selections of the security functional requirements of the TOE are done in PP and in the following description. #######  FAU_SAS.1 The TOE shall meet the requirement 'Audit storage (FAU_SAS.1)' as specified below 1 [assignment: Limited capability and availability policy ] 2 [assignment: physical tampering scenarios ] 3 [assignment: list of TSF devices/elements ] Test Features after TOE Delivery does not allow user data of the Composite TOE to be disclosed or manipulated, TSF data to be disclosed or manipulated, software to be reconstructed and no substantial information about construction of TSF to be gathered which may enable other attacks 1 . 33 / 61 CIU98N70 Secure Element V1.0 Security Target Lite (Common Criteria Part 2 extended). FAU_SAS.1 FAU_SAS.1.1 Audit Storage The TSF shall provide the test process before TOE Delivery 1 with the capability to store the Initialization Data and/or Pre-personalization Data and/or supplements of the Security IC Embedded Software 2 in the FLASH 3 #######  FDP_SDI.2 The TOE shall meet the requirement 'Stored data integrity monitoring and action (FDP_SDI.2)' as specified below. | FDP_SDI.2 | Stored data integrity monitoring and action | |---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FDP_SDI.2.1 | The TSF shall monitor user data stored in containers controlled by the TSF for inconsistencies between stored data and corresponding EDC 4 on all objects, based on the following attributes: EDC value for the FLASH and RAM 5 | | FDP_SDI.2.2 | Upon detection of a data integrity error, the TSF shall trigger reset or exception 6 . | | Dependencies: | No dependencies | #######  FDP_SDC.1 The TOE shall meet the requirement 'Stored data confidentiality (FDP_SDC.1)' as specified below. FDP_SDC.1 FDP_SDC.1.1 Stored data confidentiality The TSF shall ensure the confidentiality of all user data 7 . while it is stored in the any memory 8 . 1 [assignment: list of subjects ] 2 [assignment: list of audit information ] 3 [assignment: type of persistent memory ] 4 [assignment: integrity errors ] 5 [assignment: user data attributes ] 6 [assignment: action to be taken ] 7 [selection: all user data, the following user data [assignment: list of user data] ] 8 [selection: temporary memory, persistent memory, any memory ] 34 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #######  FDP_ITT.1 The TOE shall meet the requirement 'Basic internal transfer protection (FDP_ITT.1)' as specified below. | FDP_ITT.1 | Basic internal transfer protection | |-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FDP_ITT.1.1 | The TSF shall enforce the Data Processing Policy 1 to prevent the disclosure 2 of user data when it is transmitted between physically-separated parts of the TOE. | #######  FPT_ITT.1 The TOE shall meet the requirement 'Basic internal TSF data transfer protection (FPT_ITT.1)' as specified below. | FPT_ITT.1 | Basic internal TSF data transfer protection | |-------------|------------------------------------------------------------------------------------------------------------| | FPT_ITT.1.1 | The TSF shall protect TSF data from disclosure 3 when it is transmitted between separate parts of the TOE. | #######  FDP_IFC.1 The TOE shall meet the requirement 'Subset information flow control (FDP_IFC.1)' as specified below. | FDP_IFC.1 | Subset information flow control | |-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FDP_IFC.1.1 | The TSF shall enforce the Data Processing Policy 4 on all confidential data when they are processed or transferred by the TOE or by the Security IC Embedded Software 5 . | #######  FCS_RNG.1 1 [assignment: access control SFP(s) and/or information flow control SFP(s) ] 2 [assignment: disclosure, modification, loss of use ] 3 [assignment: selection: disclosure, modification ] 4 [assignment: information flow control SFP ] 5 [assignment: list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP ] 35 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The TOE shall meet the requirement 'Quality metric for random numbers (FCS_RNG.1)' as specified below (Common Criteria Part 2 extended). ####### FCS_RNG.1[PTG.2] Random number generation (Class PTG.2) Note: The definition of the Security Functional Requirement FCS_RNG.1 has been taken from [7] | FCS_RNG.1.1[PTG.2] | The TSF shall provide a physical 1 random number generator that implements: | |----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | (PTG.2.1) | A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output. | | (PTG.2.2) | If a total failure of the entropy source occurs while the RNG is being operated, the RNG prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source. | | (PTG.2.3) | The online test shall detect non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected. | | (PTG.2.4) | The online test procedure shall be effective to detect non- tolerable weaknesses of the random numbers soon. | | (PTG.2.5) | The online test procedure checks the quality of the raw random number sequence. It is triggered continuously. The online test is suitable for detecting non-tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time 2 . | | FCS_RNG.1.2[PTG.2] | The TSF shall provide octets of bits 3 that meet: | |----------------------|------------------------------------------------------------------------------------------------------------| | (PTG.2.6) | Test procedure A 4 does not distinguish the internal random numbers from output sequences of an ideal RNG. | | (PTG.2.7) | The average Shannon entropy per internal random bit | 36 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### FCS_RNG.1[DRG.3] Random number generation (Class DRG.3) | FCS_RNG.1.1[DRG.3] | The TSF shall provide a deterministic 1 random number generator that implements: | |----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | (DRG.3.1) | If initialized with a random seed using PTRNG of class PTG.2 as random source, the internal state of the RNG shall have 255 bits of entropy. | | (DRG.3.2) | The RNG provides forward secrecy. | | (DRG.3.3) | The RNG provides backward secrecy even if the current internal state is known 2 . | | FCS_RNG.1.2[DRG.3] | The TSF shall provide octets of bits 2 that meet: | | (DRG.3.4) | The RNG initialized with a random seed using PTRNG of class PTG.2 generates output for which [2 40 ] strings of bit length 128 are mutually different with probability [1-2 -49 ]. | | (DRG.3.5) | Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A 3 . | The Table 11 provides an overview about the augmented security functional requirements, which are added additional to the TOE and defined in this ST. All requirements are taken from Common Criteria Part 2 [2]. Table 11: Augmented security functional requirements | SFR | Title | |-----------|-----------------------------------------| | FDP_ACC.1 | Subset access control | | FDP_ACF.1 | Security attribute based access control | | FCS_COP.1 | Cryptographic operation | | FCS_CKM.6 | Cryptographic key destruction | By this, all assignment/selection operations are performed. This Security Target does not perform any other/further operations than stated in the PP [8]. Considering Application Note 12 of the PP [8] in the following paragraphs the additional functions for cryptographic support and access control function are defined. These SFRs are not required by the PP [8]. 1 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 2 [assignment: list of security capabilities] 3 [assignment: a defined quality metric] 37 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### Memory access control The TOE provides Chip mode and 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 where it applies. The security functional requirement 'Security attribute based access control (FDP_ACF.1)' defines 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 chip mode and area based access permission control. The permission control information is evaluated by the hardware so that access is granted or denied. 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 and execute accesses at different chip modes (CMS mode, Non-CMS mode, Debug mode, Non-Debug mode) on data including code stored in memory areas. The Memory Access Control Policy is enforced on the following access ports, which are: CPU access over the bus system and DMA controller access over the bus system. The Memory Control Policy controls access to memories by EMMU 、 IDAU 、 DTZR and TZMU, and all the memory control policies implemented in EMMU 、 IDAU 、 DTZR and TZMU are fixed in hardware. The TOE shall meet the requirement 'Subset access control (FDP_ACC.1)' as specified below. | FDP_ACC.1 | Subset access control | |-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FDP_ACC.1.1 | The TSF shall enforce the Memory Access Control Policy 1 on all subjects: the software and DMA controller, all objects: defined regions in memory and all the operations: read, write, execute defined in the Memory Access Control Policy 2 . | 38 / 61 CIU98N70 Secure Element V1.0 Security Target Lite 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 | |-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | FMT_MSA.3 | Static attribute initialization | | FDP_ACF.1.1 | The TSF shall enforce the Memory Access Control Policy 1 to objects based on the following: all subjects and objects and the attributes ： chip mode, memory range of the accessed object, the EMMU 、 IDAU 、 DTZR and TZMU access permission control to control the access permission 2 . | | 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 chip mode 、 EMMU IDAU 、 DTZR and TZMU access permission control information of the chip mode and memory range of the objects during the access to determine whether the accesses can be granted to perform the operation 3 by the subject. | | FDP_ACF.1.3 | The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none 4 . | | FDP_ACF.1.4 | The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none 5 . | ####### Cryptographic Support 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. 1 [assignment: access control SFP] 2 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] 3 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 4 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 5 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 39 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The following additional specific security functionality is implemented in the TOE: - Triple Data Encryption Standard (TDES) with 112/168 bits key size - Advanced Encryption Standard (AES) - Rivest-Shamir-Adleman (RSA) - Elliptic curve cryptography (ECC) - X25519 #######  TDES Operation The TDES Operation of the TOE shall meet the requirement 'Cryptographic operation (FCS_COP.1)' as specified below. ####### FCS_COP.1[TDES] Cryptographic operation FCS_COP.1.1[TDES] The TSF shall perform encryption and decryption 1 in accordance with a specified cryptographic algorithm TDES in ECB mode, CBC mode 2 and cryptographic key sizes 112/ 168 bit 3 that meet the following NIST SP800-67[19] and NIST SP800-38A[20] 4 . ####### FCS_CKM.6[TDES] Cryptographic key destruction[TDES] FCS_CKM.6.1[TDES] The TSF shall destroy cryptographic keys 5 when no longer needed 6 . FCS_CKM.6.2[TDES] The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method by overwriting the TDES key register with a random number 7 that meets the following: none 8 . #######  AES Operation The AES Operation of the TOE shall meet the requirement 'Cryptographic operation (FCS_COP.1)' as specified below. ####### FCS_COP.1[AES] Cryptographic operation 1 [assignment: list of cryptographic operations ] 2 [assignment: cryptographic algorithm ] 3 [assignment: cryptographic key sizes ] 4 [assignment: list of standards ] 5 [assignment: list of cryptographic keys (including keying material) ] 6 [selection: no longer needed , [assignment: other circumstances for key or keying material destruction ]] 7 [assignment: cryptographic key destruction method] 8 [assignment: list of standards ] 40 / 61 CIU98N70 Secure Element V1.0 Security Target Lite FCS_COP.1.1[AES] The TSF shall perform encryption and decryption 1 in accordance with a specified cryptographic algorithm AES in ECB mode, CBC mode, CTR mode, GCM mode 2 and cryptographic key sizes 128 bit, 192 bit and 256 bit 3 that meet the following FIPS PUB 197 [21] , NIST SP80038A[20] , NIST SP800-38A and NIST SP 800-38D 4 . ####### FCS_CKM.6[AES] Cryptographic key destruction[AES] FCS_CKM.6.1[AES] The TSF shall destroy 5 cryptographic keys when no longer needed 6 . FCS_CKM.6.2[AES] The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method by overwriting the AES key register with a random number 7 that meets the following: none 8 . #######  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[RSA] Cryptographic operation FCS_COP.1.1[RSA] The TSF shall perform signature generation, decryption 9 in accordance with a specified cryptographic algorithm RivestShamir-Adleman (RSA) 10 and cryptographic key sizes from 1024 to 4096 bits 11 that meet the following: RSA standard [18] 12 . Application Notes: The key length is determined by user based on application requirements. User shall assure the security in the application. 1 [assignment: list of cryptographic operations ] 2 [assignment: cryptographic algorithm ] 3 [assignment: cryptographic key sizes ] 4 [assignment: list of standards ] 5 [assignment: list of cryptographic keys (including keying material) ] 6 [selection: no longer needed , [assignment: other circumstances for key or keying material destruction ]] 7 [assignment: cryptographic key destruction method] 8 [assignment: list of standards ] 9 [assignment: list of cryptographic operations ] 10 [assignment: cryptographic algorithm ] 11 [assignment: cryptographic key sizes ] 12 [assignment: list of standards ] 41 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### FCS_CKM.6[RSA] Cryptographic key destruction[RSA] FCS_CKM.6.1[RSA] The TSF shall destroy needed 2 . cryptographic keys 1 when no longer FCS_CKM.6.2[RSA] The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method by overwriting the PKE RAM with a random number and changing the PKE RAM encryption key and address scrambling key 3 that meets the following: none 4 . #######  Elliptic Curve Cryptography (ECC) operation The Modular Arithmetic and Elliptic Curve point Operation of the TOE shall meet the requirement 'Cryptographic operation (FCS_COP.1)' as specified below. ####### FCS_COP.1[ECC] Cryptographic operation FCS_COP.1.1[ECC] Application Notes: The TSF shall perform key exchange, signature generation 5 in accordance with a specified cryptographic algorithm ECDH/ECDSA/EC-SDSA/BDH 6 and cryptographic key sizes from 256 to 521 bits 7 that meet the following: ECC standard [23][24][25][26][27] 8 . The key length is determined by user based on application requirements. User shall assure the security in the application. ####### FCS_CKM.6[ECC] Cryptographic key destruction[ECC] FCS_CKM.6.1[ECC] The TSF shall destroy cryptographic keys 9 when no longer needed 10 . FCS_CKM.6.2[ECC] The TSF shall destroy cryptographic keys and keying material 1 [assignment: list of cryptographic keys (including keying material) ] 2 [selection: no longer needed , [assignment: other circumstances for key or keying material destruction ]] 3 [assignment: cryptographic key destruction method] 4 [assignment: list of standards ] 5 [assignment: list of cryptographic operations ] 6 [assignment: cryptographic algorithm ] 7 [assignment: cryptographic key sizes ] 8 [assignment: list of standards ] 9 [assignment: list of cryptographic keys (including keying material) ] 10 [selection: no longer needed , [assignment: other circumstances for key or keying material destruction ]] 42 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #######  X25519 operation The Modular Arithmetic and Elliptic Curve point Operation of the TOE shall meet the requirement 'Cryptographic operation (FCS_COP.1)' as specified below. ####### FCS_COP.1[X25519] Cryptographic operation FCS_COP.1.1[X25519] Application Notes: ####### FCS_CKM.6[X25519] The TSF shall perform key exchange 3 in accordance with a specified cryptographic algorithm X25519 4 and cryptographic key sizes 255 bits 5 that meet the following: X25519 standard [25] 6 . The key length is determined by user based on application requirements. User shall assure the security in the application. Cryptographic key destruction[X25519] FCS_CKM.6.1[X25519] The TSF shall destroy cryptographic keys 7 when no longer needed 8 . FCS_CKM.6.2[X25519] The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method by overwriting the PKE RAM with a random number and changing the PKE RAM encryption key and address scrambling key 9 that meets the following: none 10 . 1 [assignment: cryptographic key destruction method] 2 [assignment: list of standards ] 3 [assignment: list of cryptographic operations ] 4 [assignment: cryptographic algorithm ] 5 [assignment: cryptographic key sizes ] 6 [assignment: list of standards ] 7 [assignment: list of cryptographic keys (including keying material) ] 8 [selection: no longer needed , [assignment: other circumstances for key or keying material destruction ]] 9 [assignment: cryptographic key destruction method] 10 [assignment: list of standards ] specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method by overwriting the PKE RAM with a random number and changing the PKE RAM encryption key and address scrambling key 1 that meets the following: none 2 . 43 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ### 6.2 Security Assurance Requirements This Security Target is modularized as a multi-assurance ST with a global compliance(EAL5+) and one sub-TSF (EAL6+) for the memory access control policy. The following table lists the global security assurance requirements for the TOE. These security functional requirements are either copied from the Protection Profile BSI-PP-0084 without modifications, or augmented from there, or newly added in this Security Target as indicated in column four of the table. This partly addresses the Protection Profile BSI-PP-0084 Application Note 22. Table 12: Assurance components | Aspect | Acronym | Description | Compared to PP | |--------------------|-----------|---------------------------------------------------------------------------------|---------------------------| | Development | ADV_ARC.1 | Security Architecture design | As in PP | | Development | ADV_FSP.5 | Complete semi-formal functional specification with additional error information | Augmented from PP to EAL6 | | Development | ADV_IMP.2 | Implementation representation | Augmented from PP to EAL6 | | Development | ADV_INT.3 | TSF internals | Added at EAL6 level | | Development | ADV_SPM.1 | Formal TOE security policy model | | | Development | ADV_TDS.5 | TOE design | Augmented from PP to EAL6 | | Guidance | AGD_OPE.1 | Operational user guidance | As in PP | | Documents | AGD_PRE.1 | Preparative procedures | As in PP | | Life-Cycle Support | ALC_CMC.5 | CM capabilities | Augmented from PP to EAL6 | | Life-Cycle Support | ALC_CMS.5 | CM scope | Augmented from PP to EAL6 | | Life-Cycle Support | ALC_DEL.1 | Delivery procedures | As in PP | | Life-Cycle Support | ALC_DVS.2 | Development security | As in PP | | Life-Cycle Support | ALC_LCD.1 | Life-cycle definition | As in PP | | Life-Cycle Support | ALC_TAT.3 | Tools and techniques | Augmented from PP to EAL6 | 44 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | | ALC_FLR.2 | Basic flaw remediation | | |--------------------------|-------------|-------------------------------------------|---------------------------| | Security Target | ASE_CCL.1 | Conformance claims | As in PP | | Evaluation | ASE_ECD.1 | Extended components definition | As in PP | | Evaluation | ASE_INT.1 | ST introduction | As in PP | | Evaluation | ASE_OBJ.2 | Security objectives | As in PP | | Evaluation | ASE_REQ.2 | Derived security requirements | As in PP | | Evaluation | ASE_SPD.1 | Security problem definition | As in PP | | Evaluation | ASE_TSS.1 | TOE summary specification | Augmented from PP to EAL6 | | Tests | ATE_COV.3 | Analysis of coverage | Augmented from PP to EAL6 | | Tests | ATE_DPT.3 | Depth | Augmented from PP to EAL6 | | Tests | ATE_FUN.2 | Functional testing | Augmented from PP to EAL6 | | Tests | ATE_IND.2 | Independent testing - sample | As in PP | | Vulnerability Assessment | AVA_VAN.5 | Advanced methodical vulnerability testing | As in PP | Note: According to section 2 'Conformance Claims ' , the global claimed SAR is EAL5 with all augmentation towards EAL6 except for ADV_SPM. ### 6.3 Security Requirements Rationale #### 6.3.1 Rationale for the Security Functional Requirements The security functional requirements rationale of the TOE are defined and described in PP section 6.3 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, FDP_SDI.2, FDP_SDC.1, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1, and FAU_SAS.1. The security functional requirements FDP_ACC.1, FDP_ACF.1, and FCS_COP.1 are defined in the following description: Table 13: Rational for additional SFR in the ST 45 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | Objective | TOE Security Functional Requirements | |--------------|---------------------------------------------------------------------------------------------------| | O.TDES | - FCS_COP.1[TDES] 'Cryptographic operation' - FCS_CKM.6[TDES] 'Cryptographic Key Destruction' | | O.AES | - FCS_COP.1[AES] 'Cryptographic operation' - FCS_CKM.6[AES] 'Cryptographic Key Destruction' | | O.RSA | - FCS_COP.1[RSA] 'Cryptographic operation' - FCS_CKM.6[RSA] 'Cryptographic Key Destruction' | | O.ECC | - FCS_COP.1[ECC] 'Cryptographic operation' - FCS_CKM.6[ECC] 'Cryptographic Key Destruction' | | O.X25519 | - FCS_COP.1[X25519] 'Cryptographic operation' - FCS_CKM.6[X25519] 'Cryptographic Key Destruction' | | O.Mem-Access | - FDP_ACC.1 'Subset access control' - FDP_ACF.1 'Security attribute based access control'- | The table above gives an overview, how the security functional requirements are combined to meet the security objectives. The detailed justification is given in the following: The security functional requirement(s) 'Cryptographic operation (FCS_COP.1)' exactly requires those functions to be implemented which are demanded by O.TDES , O.AES, O.RSA, O.ECC and O.X25519. Therefore, FCS_COP.1 is suitable to meet the security objective. The usage of cryptographic algorithms requires the use of appropriate keys. Otherwise these cryptographic functions do not provide security. The keys have to be unique with a very high probability, and must have a certain cryptographic strength etc. In case of a key import into the TOE (which is usually after TOE delivery) it has to be ensured that quality and confidentiality are maintained. Keys for TDES and AES are provided by the environment. Keys for RSA, ECC and X25519algorithm can be provided either by the TOE or the environment. 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. The security functional requirement 'Subset access control (FDP_ACC.1)' with the related Security Function Policy (SFP) 'Memory Access Control Policy' exactly require the implementation of an chip modes and area based memory access control as required by O.Mem-Access. The related TOE security functional requirements FDP_ACC.1, FDP_ACF.1 cover this security objective. The implementation of these functional requirements is represented by the dedicated privilege level concept. 46 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The justification of the security objective and the additional requirements show that they do not contradict to the rationale already given in the Protection Profile for the assumptions, policy and threats defined there. Moreover, these additional security functional requirements cover the requirements by CC part 2 user data protection of chapter 11 which are not refined by the BSI-PP-0084. Nevertheless, the developer of the Security IC 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. The TOE only provides the tool to implement the policy defined in the context of the application. #### 6.3.2 Dependencies of Security Functional Requirements The dependences of the following security functional requirements are defined and described in PP: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, FDP_SDI.2, FDP_SDC.1, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1 and FAU_SAS.1. Table 14 below lists the security functional requirements defined in Protection Profile, their dependencies and whether they are satisfied by other security requirements defined in Protection Profile. The text following the table discusses the remaining cases. Table 14: Dependencies of the Security Functional Requirements | Security Functional Requirement | Dependencies | Fulfilled by security requirements in PP | |-----------------------------------|------------------------|--------------------------------------------| | FRU_FLT.2 | FPT_FLS.1 | Yes | | FPT_FLS.1 | None | No dependency | | FMT_LIM.1 | FMT_LIM.2 | Yes | | FMT_LIM.2 | FMT_LIM.1 | Yes | | FAU_SAS.1 | None | No dependency | | FPT_PHP.3 | None | No dependency | | FDP_ITT.1 | FDP_ACC.1 or FDP_IFC.1 | Yes | | FDP_IFC.1 | FDP_IFF.1 | See discussion below | | FPT_ITT.1 | None | No dependency | | FDP_SDC.1 | None | No dependency | | FDP_SDI.2 | None | No dependency | | FCS_RNG.1 | None | No dependency | 47 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Part 2 of the Common Criteria defines the dependency of FDP_IFC.1 (information flow control policy statement) on FDP_IFF.1 (Simple security attributes). The specification of FDP_IFF.1 would not capture the nature of the security functional requirement nor add any detail. As stated in the Data Processing Policy referred to in FDP_IFC.1 there are no attributes necessary. The security functional requirement for the TOE is sufficiently described using FDP_ITT.1 and its Data Processing Policy (FDP_IFC.1). As Table 14 shows, all other dependencies of functional requirements are fulfilled by security requirements defined in Protection Profile. The dependence of security functional requirements for the security functional requirements FDP_ACC.1, FDP_ACF.1, FCS_COP.1 and FDP_SDI.2 are defined in the following description. Table 15 : Dependency for cryptographic operation requirement | Security Requirement | Functional Dependencies | Fulfilled by security requirements | |------------------------|--------------------------------------------------------|--------------------------------------| | FCS_COP.1[TDES] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_COP.1[TDES] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_COP.1[TDES] | FCS_CKM.6 | Yes | | FCS_COP.1[AES] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_COP.1[AES] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_COP.1[AES] | FCS_CKM.6 | Yes | | FCS_COP.1[RSA] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_COP.1[RSA] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_COP.1[RSA] | FCS_CKM.6 | Yes | | FCS_COP.1[ECC] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_COP.1[ECC] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_COP.1[ECC] | FCS_CKM.6 | Yes | | FCS_COP.1[X25519] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_COP.1[X25519] | FDP_ITC.1 or FDP_ITC.2 | See comment 1 | 48 / 61 CIU98N70 Secure Element V1.0 Security Target Lite | | (if not FCS_CKM.1 or FCS_CKM.5) | | |-------------------|--------------------------------------------------------|-----------------------------| | | FCS_CKM.6 | Yes | | FCS_CKM.6[TDES] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_CKM.6[TDES] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_CKM.6[AES] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_CKM.6[AES] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_CKM.6[RSA] | FCS_CKM.1 or FCS_CKM.5 FDP_ITC.1 or FDP_ITC.2 | See comment 1 See comment 1 | | FCS_CKM.6[RSA] | (if not FCS_CKM.1 or FCS_CKM.5) | | | FCS_CKM.6[ECC] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_CKM.6[ECC] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FCS_CKM.6[X25519] | FCS_CKM.1 or FCS_CKM.5 | See comment 1 | | FCS_CKM.6[X25519] | FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1 or FCS_CKM.5) | See comment 1 | | FDP_ACC.1 | FDP_ACF.1 | Yes | | FDP_ACF.1 | FDP_ACC.1 FMT_MSA.3 | Yes See comment 2 | | FDP_SDI.2 | None | N/A | ####### Comment 1: The security functional requirement 'Cryptographic operation (FCS_COP.1)' met by the TOE have the following dependencies: -  [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation, or FCS_CKM.5 Cryptographic key derivation] The respective dependency FCS_CKM.6 is fulfilled by the TOE, for details, please refer to Section 7.6. 49 / 61 CIU98N70 Secure Element V1.0 Security Target Lite These requirements all address the appropriate management of cryptographic keys used by the specified cryptographic function and are not part of the BSI-PP-0084. Most requirements concerning key management shall be fulfilled by the environment since the Security IC Embedded Software is designed for a specific application context and uses the cryptographic functions provided by the TOE. For the security functional requirement FCS_COP.1[TDES], FCS_COP.1[AES], FCS_COP.1[RSA], FCS_COP.1[ECC], FCS_COP.1[X25519], the respective dependencies FCS_CKM.1 and FDP_ITC.1 or FDP_ITC.2 are not considered in this Security Target. This is because the decision on how to import user data and how to generate the keys shall be left to the Security IC Embedded Software. That means that the environment shall meet the requirements FCS_CKM.1 as defined in CC part 2, section 10.2 or shall meet the requirements FDP_ITC.1 or FDP_ITC.2 as defined in CC part 2, section 11.9. End of Comment ####### Comment 2: All security attributes for the Memory Access Control Policy SFP are fixed and require no management or initialization. No objects or information can be created under the SFP, and hence there is no override of associated default values. End of Comment #### 6.3.3 Rationale for the Assurance Requirements The chosen assurance components are based on the underlying PP [8]. The Security Target uses the same augmentations as the PP [8], but chooses a higher assurance level EAL6. The level EAL6 is chosen in order to meet assurance expectations of high security applications. Additionally, the requirement of the PP [8] to choose at least EAL4 is fulfilled. The rationale for the augmentations is the same as in the PP. The assurance level EAL6 is an elaborated pre-defined level of the CC, part 5 [5]. The assurance components in an EAL level are chosen in a way that they build a mutually supportive and complete set of components. The requirements chosen for augmentation do not add any dependencies, which are not already fulfilled for the corresponding requirements contained in EAL 6. Therefore, these components add additional assurance to EAL 6, but the mutual support of the requirements is still guaranteed. Therefore, the augmentation with the requirement ALC_FLR.2 were chosen in order to meet the assurance expectations explained in the following paragraphs. 50 / 61 CIU98N70 Secure Element V1.0 Security Target Lite As stated in the Section 6.3.3 of the PP [8], it has to be assumed that attackers with high attack potential try to attack smartcards used for high security applications. Therefore, specifically A VA_VAN.5 was chosen by the PP [8] in order to assure that even these attackers cannot successfully attack the TOE. In Table 12 the different assurance components are shown as well as the augmentations. #######  ALC_FLR.2 Flaw reporting procedures In order for the developer to be able to act appropriately upon security flaw reports from TOE users, and to know to whom to send corrective fixes, TOE users need to understand how to submit security flaw reports to the developer. Flaw remediation guidance from the developer to the TOE user ensures that TOE users are aware of this important information. #### 6.3.4 Security Requirements are Internally Consistent The discussion of security functional requirements and assurance components in the preceding sections has shown that consistency are given for both groups of requirements. The arguments given for the fact that the assurance components are adequate for the functionality of the TOE also shows that the security functional requirements and assurance requirements support each other and that there are no inconsistencies between these groups. The security functional requirements FDP_SDC.1 and FDP_SDI.2 address the protection of user data in the specified memory areas against compromise and manipulation. The security functional requirement FPT_PHP.3 makes it harder to manipulate data. This protects the primary assets identified in Section 3.1 and other security features or functionality which use these data. Though a manipulation of the TOE (refer to FPT_PHP.3) is not of great value for an attacker in itself, it can be an important step in order to threaten the primary assets identified in Section 3.1. Therefore, the security functional requirement FPT_PHP.3 is not only required to meet the security objective O.Phys-Manipulation. Instead it protects other security features or functions of both the TOE and the Security IC Embedded Software from being bypassed, deactivated or changed. In particular this may pertain to the security features or functions being specified using FDP_ITT.1, FPT_ITT.1, FPT_FLS.1, FMT_LIM.2, FCS_RNG.1, and those implemented in the 51 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### Security IC Embedded Software. A malfunction of TSF (refer to FRU_FLT.2 and FPT_FLS.1) can be an important step in order to threaten the primary assets identified in Section 3.1. Therefore, the security functional requirements FRU_FLT.2 and FPT_FLS.1 are not only required to meet the security objective O.Malfunction. Instead they protect other security features or functions of both the TOE and the Security IC Embedded Software from being bypassed, deactivated or changed. In particular this pertains to the security features or functions being specified using FDP_ITT.1, FPT_ITT.1, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1, and those implemented in the Security IC Embedded Software. In a forced leakage attack the methods described in 'Malfunction due to Environmental Stress' (refer to T.Malfunction) and/or 'Physical Manipulation' (refer to T.PhysManipulation) are used to cause leakage from signals which normally do not contain significant information about secrets. Therefore, in order to avert the disclosure of primary assets identified in Section 3.1 it is important that the security functional requirements averting leakage (FDP_ITT.1, FPT_ITT.1) and those against malfunction (FRU_FLT.2 and FPT_FLS.1) and physical manipulation (FPT_PHP.3) are effective and bind well. The security features and functions against malfunction ensure correct operation of other security functions (refer to above) and help to avert forced leakage themselves in other attack scenarios. The security features and functions against physical manipulation make it harder to manipulate the other security functions (refer to above). Physical probing (refer to FPT_PHP.3) shall directly avert the disclosure of primary assets identified in Section 3.1. In addition, physical probing can be an important step in other attack scenarios if the corresponding security features or functions use secret data. For instance the security functional requirement FMT_LIM.2 may use passwords.Therefore, the security functional requirement FPT_PHP.3 (against probing) help to protect other security features or functions including those being implemented in the Security IC Embedded Software. Details depend on the implementation. Leakage (refer to FDP_ITT.1, FPT_ITT.1) shall directly avert the disclosure of primary assets identified in Section 3.1. In addition, inherent leakage and forced leakage (refer to above) can be an important step in other attack scenarios if the corresponding security features or functions use secret data. For instance the security functional requirement FMT_LIM.2 may use passwords. Therefore, the security functional requirements FDP_ITT.1 and FPT_ITT.1 help to protect other security features or functions implemented in the Security IC Embedded Software (FDP_ITT.1) or provided by the TOE (FPT_ITT.1). Details depend on the implementation. The user data of the Composite TOE are treated as required to meet the requirements defined for the specific application context (refer to Treatment of user data of the Composite TOE (A.Resp-Appl)). However, the TOE may implement additional functions. This can be a risk if their interface cannot completely be controlled by the Security IC Embedded Software. Therefore, the security functional requirements FMT_LIM.1 and FMT_LIM.2 are very important. They ensure that appropriate control is applied to the interface of these functions (limited availability) and that these functions, if being usable, provide limited capabilities only. 52 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The combination of the security functional requirements FMT_LIM.1 and FMT_LIM.2 ensures that (especially after TOE Delivery) these additional functions cannot be abused by an attacker to (i) disclose or manipulate user data of the Composite TOE, (ii) to manipulate (explore, bypass, deactivate or change) security features or services of the TOE or of the Security IC Embedded Software or (iii) to enable other attacks on the assets. Hereby the binding between these two security functional requirements is very important. The security functional requirement Limited Capabilities (FMT_LIM.1) must close gaps which could be left by the control being applied to the function's interface (Limited Availability (FMT_LIM.2)). Note that the security feature or services which limits the availability can be bypassed, deactivated or changed by physical manipulation or a malfunction caused by an attacker. Therefore, if Limited Availability (FMT_LIM.2) is vulnerable, it is important to limit the capabilities of the functions in order to limit the possible benefit for an attacker. The security functional requirement Limited Availability (FMT_LIM.2) must close gaps which could result from the fact that the function's kernel in principle would allow to perform attacks. The TOE must limit the availability of functions which potentially provide the capability to disclose or manipulate user data of the Composite TOE, to manipulate security features or services of the TOE or of the Security IC Embedded Software or to enable other attacks on the assets. Therefore, if an attacker could benefit from using such functions, it is important to limit their availability so that an attacker is not able to use them. No perfect solution to limit the capabilities (FMT_LIM.1) is required if the limited availability (FMT_LIM.2) alone can prevent the abuse of functions. No perfect solution to limit the availability (FMT_LIM.2) is required if the limited capabilities (FMT_LIM.1) alone can prevent the abuse of functions. Therefore, it is correct that both requirements are defined in a way that they together provide sufficient security. It is important to avert malfunctions of TSF and of security functions implemented in the Security IC Embedded Software (refer to above). There are two security functional requirements which ensure that malfunctions can not be caused by exposing the TOE to environmental stress. First it must be ensured that the TOE operates correctly within some limits (Limited fault tolerance (FRU_FLT.2)). Second the TOE must prevent its operation outside these limits (Failure with preservation of secure state (FPT_FLS.1)). Both security functional requirements together prevent malfunctions. The two functional requirements must define the 'limits'. Otherwise there could be some range of operating conditions which is not covered so that malfunctions may occur. Consequently, the security functional requirements Limited fault tolerance (FRU_FLT.2) and Failure with preservation of secure state (FPT_FLS.1) are defined in a way that they together provide sufficient security. 53 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The security functional requirements required to meet the security objectives O.LeakInherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced protect the cryptographic algorithms (FCS_COP.1) and the cryptographic key generations (FCS_CKM.6). Therefore these security functional requirements support the secure implementation and operation of FCS_COP.1 and FCS_CKM.6 Parts of the IC Embedded Software may cause security violations by accidentally or deliberately accessing restricted data (which may include code). In order to avert the memory access violation it is important to the security functional requirement defining the scope where the Memory Access Policy is applied (FDP_ACC.1) and the security functional requirement defining the Memory Access Policy(FDP_ACF.1) #### 7 TOE summary specification This chapter provides information to potential users of the TOE how the TOE satisfies the Security Functional Requirements. In addition to the SFRs the TOE has security mechanisms that add to implement the security policies. ### 7.1 Protection against malfunction Malfunctioning relates to the security functional requirements FRU_FLT.2 and FPT_FLS.1. The TOE meets these SFRs by a group of security measures that guarantee correct operation of the TOE. The TOE maintains its correct functioning by the following security mechanisms: -  Environmental detectors to verify if the environmental conditions are within the specified range -  Detector self-test verifies the correct functioning of the environmental detectors -  Data integrity checking verifies the correctness of the data read from memory and security sensitive registers -  Tests on random number generator data verifies the quality of the generated 54 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ####### random data If one of the detectors or mechanisms detects an alarm event, the TOE will enter reset state or trigger an exception to make sure a secure situation. ####### FPT_FLS.1: Failure with preservation of secure state Failures such as frequency, voltage, temperature, light and power glitch that are out of the special range are detected by TOE's detectors. The failures will cause an alarm signals to be triggered, which will result in a special function register bit to be set and a reset (secure state). Failures tested by self-tests for random number generator will cause an alarm signals to be triggered, which will result in a special function register bit to be set and a reset (secure state). Failures of integrity check are detected by data integrity checking. The failure of integrity check of data reading from NVM will cause an exception. It can be dealt with in exception handler to set the chip into a security state (like reset). The failures of other data will cause an alarm signals to be triggered, which will result in a special function register bit to be set and a reset (secure state). ####### FRU_FLT.2: Limited fault tolerance In order to prevent malfunction, the operation signals (clock, reset, supply voltage) are filtered/regulated. The detectors that prevent noise, glitches and extremely frequency in the external reset or clock pad are implemented as hardware. There is a security-delay-latch in TOE. ### 7.2 Protection against leakage Leakages relate to the security requirements FDP_ITT.1, FDP_IFC.1 and FPT_ITT.1. The TOE meets these SFRs by implementing several measures that provides logical protection against leakage. The TOE prevents information leakage by means of the following security measures: -  Memory encryption -  Address scrambling for memory -  Bus mask -  SCA countermeasures for all secure cryptographic functions -  DFA countermeasures for all secure cryptographic functions ####### FDP_IFC.1: Subset information flow control 55 / 61 CIU98N70 Secure Element V1.0 Security Target Lite To prevent data analysis from information stored in memory as well as information on internally transmitted, memory encryption function is applied. ####### FDP_ITT.1: Basic internal transfer protection The combination of TOE features listed below achieves the effective protection of access to the internal signals. -  Address scrambling for memory -  Memory encryption -  Bus mask -  SCA countermeasures for all secure cryptographic functions -  DFA countermeasures for all secure cryptographic functions ####### FPT_ITT.1: Basic internal TSF data transfer protection The combination of TOE features listed below achieves the effective protection of access to the internal signals. -  Address scrambling for memory -  Memory encryption -  Bus mask -  SCA countermeasures for all secure cryptographic functions -  DFA countermeasures for all secure cryptographic functions ### 7.3 Physical protection Physical manipulation and probing relates to the security requirement FPT_PHP.3, FDP_SDC.1 and FDP_SDI.2. The TOE meets this SFR by implementing security measures that provides physical protection against physical probing and manipulation. The following security measures protect the TOE against physical manipulation and probing: -  Active shielding -  Memory integrity checking -  Memory encryption -  Bus mask If a physical manipulation or physical probing attack is detected, an alarm will be automatically triggered by the hardware, which will cause the chip to be reset. ####### FPT_PHP.3: Resistance to physical attack This requirement focuses on the security features when the active shield is manipulated so that the features prevent the TOE from physical intrusive attacks. The TOE resets once the physical manipulations or physical probing attacks are detected. 56 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Synthesizable processor core with glue logic makes reverse engineering and signal identification unpractical. Memory encryption and bus mask switching prevents memory and address/data buses from probing attacks. ####### FDP_SDC.1: Stored data confidentiality All of the data that stored within memory areas are encrypted, thus the attacker can only get the cipher-text data. The address of the stored data is also be encrypted, so it is very difficult to get the stored data by the attacker. ####### FDP_SDI.2: Stored data integrity monitoring and action The data stored in memory using check algorithm to verify the stored data integrity. ### 7.4 Protection against abuse of functionality Abuse of functionality and identification relates to the security requirements FMT_LIM.1, FMT_LIM.2 and FAU_SAS.1. The TOE meets these SFRs by implementing a complicated test mode control mechanism that prevents abuse of test functionality delivered as part of the TOE. Test functionality is permanently disabled after production by a combination of physical and logical security measures. ####### FAU_SAS.1: Audit storage The manufacturing data written into the non-user FLASH of the TOE are READ ONLY once the TOE is set from test mode to non-test mode. ####### FMT_LIM.1: Limited capabilities The access to the test mode is limited. Furthermore, once the TOE is switched to nontest mode, the test mode is unavailable any more. The access to the debug mode is limited. Furthermore, once the TOE is switched to Non-debug mode, the debug mode is unavailable any more. ####### FMT_LIM.2: Limited availabilities 57 / 61 CIU98N70 Secure Element V1.0 Security Target Lite The access to the test mode is limited. Furthermore, once the TOE is switched to nontest mode, the test mode is unavailable any more. Only under test mode, functional test is able to be conducted. The access to the debug mode is limited. Furthermore, once the TOE is switched to Non-debug mode, the debug mode is unavailable any more. Only under test mode, functional test is able to be conducted. ### 7.5 Random number generator Random numbers relate to the security requirement FCS_RNG.1. The TOE meets this SFR by providing a random number generator. ####### FCS_RNG.1: Random number generation Random number generation algorithm that follows the requirements and the metric of the AIS20/31[2013] Class DRG.3 standard and a True Random Number Generator for AIS20/31[2013] Class PTG.2 Random Number Generator fulfills this requirement. ### 7.6 Cryptographic functionality Cryptographic functionality relates the security requirements FCS_COP.1[TDES], FCS_COP.1[AES], FCS_COP.1[RSA], FCS_COP.1[ECC], FCS_COP.1[X25519], FCS_CKM.6[TDES] , FCS_CKM.6[AES] , FCS_CKM.6[RSA], FCS_CKM.6[ECC] and FCS_CKM.6[X25519]. The TOE meets these SFRs by providing cryptographic functionality by means of a combination of accelerating hardware and IC dedicated support software. ####### FCS_COP.1: Cryptographic operation #######  TDES The TOE provides TDES symmetric algorithm according to the NIST SP800-67[19] and NIST SP800-38A[20] standard. TDES symmetric algorithm is used for the TOE in encrypting and decrypting data. The TDES symmetric algorithm works with 112/168 bits key size. The TOE provides TDES with supporting ECB/CBC mode. #######  AES The TOE provides AES symmetric algorithm according to the FIPS 197[21] and NIST SP800-38A[20] standard. AES symmetric algorithm is used for the TOE in encrypting and decrypting data. The AES symmetric algorithm works with 128/192/256 bits key size. The TOE provides AES with supporting ECB/CBC/CTR/GCM mode. #######  RSA The TSF shall perform signature generation and decryption in accordance with a specified cryptographic algorithm Rivest-Shamir-Adleman (RSA) and cryptographic key sizes from 1024 to 4096 bits that meet the RSA standard [18]. 58 / 61 CIU98N70 Secure Element V1.0 Security Target Lite #######  ECC The TSF shall perform signature generation and key exchange in accordance with a specified cryptographic algorithm ECDH/ECDSA/EC-SDSA/BDH and cryptographic key sizes from 256 to 521 bits that meet the ECC standard [23][24][25][26][27]. #######  X25519 The TSF shall perform key exchange in accordance with a specified cryptographic algorithm x25519 and cryptographic key size is 255 bits that meet the X25519 standard [25]. ####### FCS_CKM.6: Cryptographic key destruction #######  TDES The TOE provides TDES key destruction. The TDES key destruction method is to cover the TDES key register using random number. -  AES The TOE provides AES key destruction. The AES key destruction method is to cover the AES key register using random number. #######  RSA The TOE provides key destruction. The method is to cover the PKE RAM using random number and change the PKE RAM encryption key and address scrambling key. #######  ECC The TOE provides key destruction. The method is to cover the PKE RAM using random number and change the PKE RAM encryption key and address scrambling key. -  X25519 The TOE provides key destruction. The method is to cover the PKE RAM using random number and change the PKE RAM encryption key and address scrambling key. ### 7.7 Memory access control ####### FDP_ACC.1: Subset access control ####### FDP_ACF.1: Security attributes based access control Memory access control is related to these requirements. The EMMU 、 IDAU 、 DTZR and TZMU is responsible for memory access control based on memory address range and chip modes. Invalid access will be denied. 59 / 61 CIU98N70 Secure Element V1.0 Security Target Lite ## 8. Bibliography ### 8.1 Evaluation Documents - [1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model, CC:2022, Revision 1, November 2022, CCMB-2022-11-001 - [2] Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, CC:2022, Revision 1, November 2022, CCMB-2022-11-002 - [3] Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, CC:2022, Revision 1, November 2022, CCMB-2022-11-003 - [4] Common Criteria for Information Technology Security Evaluation Part 4: Framework for the specification of evaluation methods and activities, CC:2022, Revision 1, November 2022, CCMB2022-11-004 - [5] Common Criteria for Information Technology Security Evaluation Part 5: Pre-defined packages of security requirements, CC:2022, Revision 1, November 2022, CCMB-2022-11-005 - [6] Common Methodology for Information Technology Security Evaluation: Evaluation Methodology, CEM:2022, Revision 1, November 2022, CCMB-2022-11-006 - [7] A proposal for: Functionality classes for random number generators, Version 2.0, 18 September 2011 - [8] Security IC Platform Protection Profile, Version 1.0, 13th Jan. 2014, registered and certified by Bundesamt fü r Sicherheit in der Informationstechnik (BSI) under the reference BSI-PP-0084 ### 8.2 Developer Documents - [9] CIU98N70 Secure Element V1.0 Operational User Guidance, version 1.3 - [10] CIU98N70 Secure Element V1.0 Preparative procedures, version 1.2 - [11] CIU98N70 Secure Element V1.0 Product Datasheet, version 1.2 - [12] CIU98N70 Secure Element V1.0 Crypto and Function Library User Guide, version 1.2 ### 8.3 Other Documents - [13] FIPS PUB 46-3 FEDERAL INFORMATION PROCESSING STANDARDS 2. PUBLICATION DATA ENCRYPTION STANDARD (DES) Reaffirmed 1999 October 25 - [14] ISO/IEC 7816-2:1996 Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 2: Dimensions and location of contacts - [15] ISO/IEC 7816-3:1997 Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols - [16] ISO/IEC 14443-3:2001 Identification cards - Contactless integrated circuit(s) cards - 60 / 61 CIU98N70 Secure Element V1.0 Security Target Lite Proximity cards - Part 3: Initialization and anticollision - [17] ISO/IEC 14443-4:2001 Identification cards - Contactless integrated circuit(s) cards - Proximity cards - Part 4: Transmission protocol [18] PKCS #1: RSA Cryptography Standard, RSA Laboratories, Version 2.2, 2012 [19] National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of Commerce, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, NIST SP800-67, Revision 1.1, revised January 2012 [20] National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of Commerce, Recommendation for Block Cipher Modes of Operation, NIST SP80038A, December 2001 [21] U.S. Department of Commerce / National Bureau of Standards, Advanced Encryption Standard (AES), FIPS PUB 197, 2001, November 26. [22] Functionality classes and evaluation methodology for deterministic/physical random number generators, version 3, 15.05.2013, Bundesamt fü r Sicherheit in der Informationstechnik [23] ANSI X9.62-2005: Public Key Cryptography for The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), November 16 2005, American National Standards Institute [24] ANSI X9.63-2011: Public Key Cryptography for The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, December 2011, American National Standards Institute [25] IETF RFC 7748: Elliptic Curves for Security, January 2016, Internet Research Task Force (IRTF) [26] Technical Guideline BSI TR-03111: Elliptic Curve Cryptography, Version 2.10, 1st June 2018, Federal Office for Information Security [27] EMV® Contactless Specifications for Payment Systems, Book E - Contactless Security, Version 1.0, June 2023, EMVCo. - [28] Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), V1.2, 2025-1015 61 / 61