Please read the Important Notice and Warnings at the end of this document 7.1 www.infineon.com 2026-01-20 public Security Target Lite 1 M9900/M9905/M9906 with optional ACL Software Libraries 2 According to Common Criteria CC2022 EAL5 augmented (EAL5+) 3 4 5 6 Version: 7.1 7 Date: 2026-01-20 8 2 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Table of Content 1 Security Target Introduction (ASE_INT) ............................................................................... 4 1.1 Security Target and Target of Evaluation Reference ..........................................................................4 1.2 Target of Evaluation overview............................................................................................................7 2 Target of Evaluation Introduction.......................................................................................10 2.1 Definition of the TOE........................................................................................................................10 2.1.1 Major security functions of the TOE ............................................................................................ 11 2.1.2 Not part of the TOE Security Functionality.................................................................................. 11 2.2 Hardware of the TOE........................................................................................................................ 11 2.3 Firmware of the TOE ........................................................................................................................15 2.4 Optional software of the TOE...........................................................................................................15 2.5 Interfaces of the TOE........................................................................................................................16 2.6 Guidance documentation ................................................................................................................. 17 2.7 Forms of delivery.............................................................................................................................. 17 2.8 Production sites................................................................................................................................18 2.9 TOE Configuration ...........................................................................................................................18 2.10 TOE initialization with Customer Software.......................................................................................19 3 Conformance Claims (ASE_CCL) .........................................................................................20 3.1 CC Conformance Claim.....................................................................................................................20 3.2 PP Claim...........................................................................................................................................20 3.3 Package Claim..................................................................................................................................20 3.4 Conformance Rationale....................................................................................................................21 4 Security Problem Definition (ASE_SPD) ..............................................................................24 4.1 Threats.............................................................................................................................................24 4.1.1 Additional Threat due to TOE specific Functionality....................................................................24 4.1.2 Assets regarding the Threats.......................................................................................................25 4.2 Organizational Security Policies .......................................................................................................26 4.2.1 Augmented Organizational Security Policy .................................................................................26 4.3 Assumptions.....................................................................................................................................27 5 Security objectives (ASE_OBJ)............................................................................................28 5.1 Security objectives for the TOE ........................................................................................................28 5.2 Security Objectives for the Security IC Embedded Software and operational Environment (OE) .....29 5.3 Security Objectives Rationale...........................................................................................................30 6 Extended Component Definition (ASE_ECD)........................................................................31 6.1 “Subset TOE security testing (FPT_TST)”.........................................................................................31 6.2 Definition of FPT_TST.2 ...................................................................................................................31 6.3 TSF self test (FPT_TST) ....................................................................................................................32 7 Security Requirements (ASE_REQ) .....................................................................................33 7.1 FAU_SAS..........................................................................................................................................34 7.2 FPT_TST.2........................................................................................................................................34 7.3 FCS_RNG .........................................................................................................................................35 7.4 Limited Capabilities and Limited Availability....................................................................................36 7.5 Memory access control.....................................................................................................................36 7.6 Support of Cipher Schemes..............................................................................................................40 7.6.1 Triple-DES Operation..................................................................................................................40 7.6.2 AES Operation.............................................................................................................................41 7.6.3 Elliptic Curve DSA (ECDSA) operation.........................................................................................41 7.6.4 Elliptic Curve (EC) key generation................................................................................................42 7.6.5 Elliptic Curve Diffie-Hellman (ECDH) key agreement ..................................................................42 7.7 Data Integrity and confidentiality.....................................................................................................43 3 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 7.8 TOE Security Assurance Requirements ............................................................................................44 7.8.1 Refinements................................................................................................................................45 7.9 Security Requirements Rationale .....................................................................................................45 7.9.1 Rationale for the Security Functional Requirements....................................................................45 7.9.1.1 Dependencies of Security Functional Requirements...............................................................47 7.9.2 Rationale of the Assurance Requirements ...................................................................................49 8 TOE Summary Specification (ASE_TSS) ..............................................................................51 8.1 SF_DPM: Device Phase Management...............................................................................................51 8.2 SF_PS: Protection against Snooping ................................................................................................52 8.3 SF_PMA: Protection against Modifying Attacks...............................................................................53 8.4 SF_PLA: Protection against Logical Attacks.....................................................................................54 8.5 SF_CS: Cryptographic Support.........................................................................................................55 8.5.1 3DES encryption..........................................................................................................................55 8.5.2 AES encryption............................................................................................................................55 8.5.1 Elliptic Curves..............................................................................................................................55 8.5.1.1 Signature Generation .............................................................................................................55 8.5.1.2 Asymmetric Key Generation...................................................................................................56 8.5.1.3 Asymmetric Key Agreement ..................................................................................................56 8.5.2 Asymmetric Base Library.............................................................................................................56 8.5.3 TRNG...........................................................................................................................................56 8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality...........................57 8.7 Security Requirements are internally Consistent..............................................................................57 9 References........................................................................................................................59 10 Hash values ......................................................................................................................60 11 List of Abbreviations..........................................................................................................61 12 Glossary ...........................................................................................................................63 Revision History .................................................................................................................................64 4 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1 SecurityTarget Introduction (ASE_INT) 1 1.1 SecurityTarget andTarget of Evaluation Reference 2 The title of this document is: Security Target Lite M9900/M9905/M9906 with optional ACL Software 3 Libraries 4 The name of the TOE on the CC certificate is: 5 “Infineon Technologies Security Controller) M9900 A22/C22/D22, M9905 A11, M9906 A11 with optional 6 ACL v2.07.003 and v2.09.002” 7 The Target of Evaluation (TOE) comprises the Infineon Technologies Smart Card IC (Security 8 Controller) M9900 A22/C22/D22, M9905 A11 and M9906 A11 with optional ACL v2.07.003 and 9 v2.09.002 10 The Security Target is based on the Protection Profile BSI-CC-PP-0084-2014[PP]. 11 The ST built in compliance to CC:2022. 12 Table 1 Identification 13 Type Version Date Title/Registration/Explainantion Security Target Method of identification is done by version, date and title Security Target 7.1 2026-01- 20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries TOE Hardware Method of identification is done by reading of GCIM M9900 A22, C22, D22 See Remark 1 M9900 with Firmware Identifier 80001141 and Firmware Identifier 80001142 M9905 A11 M9905 with Firmware Identifier 80001151 M9906 A11 M9906 with Firmware Identifier 80001150 Libraries (optional) Method of identification is done by hash values NRG Management 01.03.0927 Management of NRG cards 1 NRG Reader 01.02.0800 NRG reader mode support 1 ACL 2.07.003 Cl97-LIB-base.lib Cl97-LIB-ecc.lib 1 Not part of TSF 5 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Type Version Date Title/Registration/Explainantion 2.09.002 ACL97-Crypto2304T-L90-base.lib ACL97-Crypto2304T-L90-ecc.lib Hardware Guidance Documentation Method of identification is done by version, date and title General Guidance Revision 3.0 2019-08- 28 32-bit Security Controller M9900 Hardware Reference Manual Edition 2020-04-15 Update 2025-06-06 2020-04-15 M9900 Security Guidelines User´s Manual DDI 0403E.e 2021 ARMv7-M Architecture Reference Manual, ARM DDI ARM DDI 0403E.e N (ID021621), ARM Limited, 2021 5.9 2024-11-25 SLE97 security controllers Programmer's Reference Manual SLCx7_DFP Document release reference: Z8F80731571-A Edition 2014-08- 10a 2014-08-10 SLE97 / SLC14 Family Production and Personalization User´s Manual Errata sheet 4.1 2019-09- 24 M9900 Errata Sheet 3.1 2019-09-05 M9905 M9906 Errata Sheet Library Guidance Documentation (optional) Method of identification is done by version, date and title ACL Guidance 2.07.003 2024-08- 26 CL97 Asymmetric Crypto Library for Crypto@2304T RSA / ECC / Toolbox, User Interface 2.09.002 2024-06-27 ACL97-Crypto2304T-L90 Asymmetric Crypto Library for Crypto@2304T RSA / ECC / Toolbox, User interface manual CC documents Method of indentification is done by version, date and title PP 1.0 2014-01-13 Security IC Platform Protection Profile BSI-PP-0084- 2014 6 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Type Version Date Title/Registration/Explainantion CC CC:2022 Revision 1 2022-11 Security Evaluation Part 1: CCMB-2022-11-001 Part 2: CCMB-2022-11-002 Part 3: CCMB-2022-11-003 Part 4: CCMB-2022-11-004 Part 5: CCMB-2022-11-005 1 This TOE is represented by a number of various products. They all differentiate by different mask sets 2 with slight - neither functional nor security relevant - modifications, various configuration possibilities, 3 done either by Infineon settings during production or, after delivery, by means of blocking at customer 4 premises. Despite these variation possibilities, all products are derived from the same hardware design 5 results, the M9900 A22, M9905 A11 and M9906 A11. 6 The TOE can be identified with the Generic Chip Identification Mode (GCIM). The M-number hardware 7 is identified by the bytes 05 and 06, which are the first two bytes of the chip identification number, 8 having for the M9900 always the hexadecimal value of 0x0007, for the M9905 the value 0x0010 and for 9 the M9906 the value 0x0011, The design step, firmware identifier, mask identifier, temperature range 10 and system frequency are also included in the GCIM. Additionally the customer can read the 11 configuration area as defined in the SLE97 Programmer´s Reference Manual [11]. 12 Remark 1: 13 The derivatives of the TOE produced in the factory Dresden with the additional top layer on board 14 (WLP, WLB) are managed with an own design step. These derivatives output a C22 in the GCIM for the 15 WLP derivative and a D22 for the WLB derivative, which is always linked to the A22 design step. The 16 C22 and D22 design step is only outputted at the derivatives with the additional top layer. All other 17 identification options, i.e. the various metal option identifiers of the GCIM remain unchanged. 18 All products are identical with respect to module design and layout, but may include further package 19 options require flexibility in design and could also depend on user requirements. In these cases one or 20 more additional metal layer are added on top of one of the TOE mask set. These additional metal 21 layers, it could also be more than one, just reroute the pads. Therefore, this last rerouting on top does 22 not change the function of the TOE itself and is depending on the package only. These top metal layers 23 are flexible in design, could depend also on user requirements and are of course not relevant for the 24 security of the TOE. For these reasons, the metal layers are out the scope of the certification and do not 25 belong to the TOE. Of course, in all cases passivation and isolation coating is applied on top of the last 26 layers carrying wires. 27 Despite all these options and the resulting flexibility, all differences are comparable to the scenario 28 where for example someone takes a piece of wire and reconnects the pads of the TOE using a soldering 29 bolt. This does not change anything on the TOE security or security policy. 30 To each of the TOE relevant optional different mask set variants, an individual value is assigned, which 31 is part of the data output of the Generic Chip Identification Mode (GCIM). By that the various hardware 32 mask sets can be clearly identified and differentiated by the GCIM output. The interpretation of the 33 output GCIM data is clearly explained in the user guidance, Hardware Reference Manual [7]. 34 There are no other differences between the mask sets the TOE is produced with, and all these changes 35 have no impact on the TOEs security policies and related functions. Details are explained in the user 36 guidance Hardware Reference Manual [7] and in the Errata Sheet1 [12]. 37 In addition to these hardware differences, the BPU feature allows a maximum of configuration 38 possibilities defined by the customer order following the market needs. A detailed description of the 39 TOE configuration possibilities is given in chapter 2.9. 40 41 7 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1.2 Target of Evaluation overview 1 The TOE comprises the Infineon Technologies AG security controller M9900/M9905/M9906 with 2 optional ACL Software Libraries . 3 The Toolbox libraries are additionally supporting software which is out of scope of this certification. 4 The Toolbox libraries do not provide cryptographic support or additional security functionality as they 5 provide only the following basic long integer arithmetic and modular functions in software, supported 6 by the cryptographic coprocessor: Addition, subtraction, division, multiplication, comparison, 7 reduction, modular addition, modular subtraction, modular multiplication, modular inversion and 8 modular exponentiation. No security relevant policy, mechanism or function is supported. The toolbox 9 library is deemed for software developers as support for simplified implementation of long integer and 10 modular arithmetic operations. 11 The TOE is a member of the Infineon Technologies AG security controller family SLE97 meeting high 12 requirements in terms of performance and security. The SLE97 family has been developed with a 13 modular concept and different memory configurations, sets of peripherals and interfaces as well as 14 different security features to satisfy market requirements. A summary product description is given in 15 this Security Target (ST). 16 The TOE offers all functions that are both required and useful in security systems, and integrated 17 peripherals that are typically needed in chipcard applications, such as information security, 18 identification, access control, GSM and UMTS projects, electronic banking, digital signature and multi- 19 application cards, ID cards, transportation and e-purse applications. 20 The TOE implements a dedicated security 32-bit RISC CPU designed on the basis of the ARMv7M 21 architecture designed in 90 nm CMOS technology. The integrated peripherals combine enhanced 22 performance and optimized power consumption for a minimized die size to make the SLE97 controllers 23 ideal for chipcard applications. The TOE offers a wide range of peripherals, including a UART (using the 24 ISO interface), four timers, two watchdogs, a CRC module, a true RNG (TRNG), coprocessors for 25 symmetric (e.g. DES, AES) and asymmetric (e.g. EC) cryptographic algorithms. Additionally, a range of 26 communication interfaces, such as GPIO, I2C, SWP, USB, SSC/SPI and NRG interface are offered to 27 provide maximum flexibility in terms of simultaneous communication ability. 28 The TOE provides a real 32-bit CPU-architecture and is compatible to the ARMv7-M instruction set 29 architecture. The major components of the core system are the 32-bit CPU as a variant of the ARM 30 Secure Core SC300, the Cache system, the Memory Protection Unit and the Memory 31 Encryption/Decryption Unit. The TOE implements a full 32-bit addressing with up to 4 GByte linear 32 addressable memory space, a simple scalable memory management concept and a scalable stack size. 33 The flexible memory concept is built on the non volatile memory, respectively SOLID FLASH™ NVM1 . 34 For the SOLID FLASH™ NVM the Unified Channel Programming (UCP) memory technology is used. 35 The TOE provides the low-level firmware components Boot Software (BOS) and Resource 36 Management System (RMS) and the high-level firmware Flash Loader (FL) and NRG software. 37 The NRG software includes the NRG operating system and additionally the optional library 38 Management of NRG cards (version 01.03.0927) and the optional library NRG Reader Mode Support 39 (01.02.0800). The Management of NRG cards provides an API for the management and generation of 40 NRG cards. The optional NRG reader mode support library (01.02.0800) enables an access to external 41 NRG cards. 42 1 SOLID FLASH™ is an Infineon Trade Mark and stands for the Infineon EEPROM working as Flash memory. The abbreviation NVM is short for Non Volatile Memory. 8 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public NRG software is not part of the TSF and does not implement any Security Functional Requirement. 1 The RMS firmware providing some functionality via an API to the Smartcard Embedded Software 2 contains for example SOLID FLASH™ NVM service routines and functionality for the tearing save write 3 into the SOLID FLASH™ NVM. The BOS firmware (BOS-V1 and BOS-V2) is used for test purposes 4 during start-up and the FL allows downloading of user software to the NVM during the manufacturing 5 process. The BOS is implemented in a separated Test-ROM being part of the TOE. For the M9900 two 6 different versions of the BOS are provided (BOS-V1 and BOS-V2). The version BOS-V1 (Firmware 7 Identifier 80001141, 80001150, 80001151) executes the UMSLC test during the startup phase; the 8 version BOS-V2 (Firmware Identifier 80001142) does not execute the UMSLC test during the startup 9 phase to short the time duration of the startup phase. The derivate M9906 with Firmware Identifier 10 80001150 includes the feature “hardening” and the derivate M9905 with Firmware Identifier 80001151 11 includes the features “hardening” and the “Burn-In Test”. The feature “hardening” analyzing a random 12 SOLID FLASHTM NVM page after every regular program operation for written bits that are losing their 13 charge, and, in this very unlikely case, the page is rewritten. The “Burn-In Test” during production is 14 used to stress the chip in a high temperature, high internal voltage and active operation for a certain 15 time and filtering out defect parts to get a low failure rate. The derivatives M9905 and M9906 are 16 qualified for an extended temperature range from -40°C to +105°C. 17 The two cryptographic co-processors serve the need of modern cryptography: The symmetric co- 18 processor (SCP) combines both AES and Triple-DES with dual-key or triple-key hardware acceleration. 19 The Asymmetric Crypto Co-processor, called Crypto2304T in the following, supports Elliptic Curve (EC) 20 cryptography with high performance. 21 A True Random Number Generator (TRNG) specially designed for smart card applications is 22 implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31 and 23 produces genuine random numbers which then can be used internally or by the user software. 24 The software part of the TOE consists of the cryptographic libraries for EC and athe Base libraries. If an 25 EC library is part of the shipment, the corresponding asymmetric Base library is automatically included. 26 The EC library is used to provide a high-level interface to Elliptic Curve cryptography implemented on 27 the hardware component Crypto2304T and includes countermeasures against SPA, DPA and DFA 28 attacks. The routines are used for ECDSA signature generation, ECDSA signature verification, ECDSA 29 key generation and Elliptic Curve Diffie-Hellman key agreement. The EC library is delivered as object 30 code. The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key 31 lengths of 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are numerous other curve 32 types, being also secure in terms of side channel attacks on this TOE, which can the user optionally add 33 in the composition certification process. 34 The asymmetric Base library provides the low-level interface to the asymmetric cryptographic 35 coprocessor and API functions for data share handling. 36 9 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public To fulfill the high security standards for smartcards today and also in the future, this TOE utilizes an 1 integral security concept comprising countermeasure mechanisms specially designed against possible 2 attack scenarios. The TOE provides a robust set of sensors for the purpose of monitoring proper chip 3 operating conditions and detecting fault attack scenarios. The sensors are complemented with digital 4 error detection mechanisms such as parities, error detection codes and instruction stream signatures. 5 Probing and forcing attacks will be counteracted by the security optimized wiring approach, 6 implemented by an Infineon-specific shielding combined with secure wiring of security critical signals, 7 partly masking of security critical signals and by encryption of all memories inside the chip (RAM, ROM, 8 NVM). A decentralized alarm propagation and system deactivation principle is implemented, further 9 decreasing the risk of manipulating and tampering. Additionally, an online check of the security 10 mechanisms is available by using the User Mode Security Life Control (UMSLC). Side-channel attacks 11 (e.g. Timing Attack, SPA, DPA, EMA) are typically defeated using a combination of hardware and 12 software mechanisms, for this the TOE provides several supporting features e.g. trash register writes 13 and instruction interrupt prevention. The Instruction Stream Signature Checking (ISS) is a powerful 14 countermeasure against fault attacks that try to manipulate the execution sequence of the instruction 15 stream. All executed instructions are hashed in the CPUs signature register and the hardware 16 automatically checks the fitting of the values. 17 In this security target the TOE is described and a summary specification is given. The security 18 environment of the TOE during its different phases of the lifecycle is defined. The assets are identified 19 which have to be protected through the security policy. The threats against these assets are described. 20 The security objectives and the security policy are defined, as well as the security requirements. These 21 security requirements are built up of the security functional requirements as part of the security policy 22 and the security assurance requirements. These are the steps during the evaluation and certification 23 showing that the TOE meets the targeted requirements. In addition, the functionality of the TOE 24 matching the requirements is described. 25 The assets, threats, security objectives and the security functional requirements are defined in this 26 Security Target and in [PP] and are referenced here. These requirements build up a minimal standard 27 common for all Smartcards. 28 The security functions are defined here in the security target as property of this specific TOE. Here it is 29 shown how this specific TOE fulfils the requirements for the standard defined in the Protection Profile 30 [PP]. 31 The TOE uses also Special Function Registers SFR. These SFR registers are used for general purposes 32 and chip configuration. These registers are located in the SOLID FLASH™ NVM as configuration area 33 page. 34 A shielding algorithm finishes the upper layers above security critical signals and wires, finally providing 35 the so called “security optimized wiring”. 36 The TOE with its integrated security features meets the requirements of all smart card applications 37 such as information integrity, access control, mobile telephone and identification, as well as uses in 38 electronic funds transfer and healthcare systems. 39 To sum up, the TOE is a powerful smart card IC with a large amount of memory and special peripheral 40 devices with improved performance, optimized power consumption, at minimal chip size while 41 implementing high security. 42 10 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 2 Target of Evaluation Introduction 1 The TOE description helps to understand the specific security environment and the security policy. In 2 this context the assets, threats, security objectives and security functional requirements can be 3 employed. The following is a more detailed description of the TOE than in [PP] as it belongs to the 4 specific TOE. 5 6 2.1 Definition of theTOE 7 The TOE comprises three parts: 8  Hardware of the smart card security controller including all configurations and derivatives 9  Associated firmware, software and optional software 10  Guidance Documents. 11 The hardware configuration options and configuration methods are described in the chapters 1.1 and 12 2.9. The second part of this TOE includes the associated firmware and software required for operation. 13 The TOE can be delivered in various configurations, achieved by means of blocking and depending on 14 the customer order. 15 The documents as described in section 2.6 and listed in Table 1, are supplied as user guidance. All 16 product derivatives of this TOE, including all configuration possibilities differentiated by the GCIM data 17 and the configuration information output, are manufactured by Infineon Technologies AG. In the 18 following descriptions, the term “manufacturer” stands short for Infineon Technologies AG, the 19 manufacturer of the TOE. The Smartcard Embedded Software respectively user software is not part of 20 the TOE. In any case the user is able to clearly identify the TOE hardware, its configuration and proof 21 the validity of the certificate independently, meaning without involving the manufacturer. The various 22 blocking options, as well as the means used for the blocking, are done during the manufacturing 23 process or at user premises. Entirely all means of blocking and the blocking of the involved firmware 24 respectively software parts, used at Infineon Technologies AG and/or the user premises, are subject of 25 the evaluation. All resulting configurations of a TOE derivative are subject of the certificate. All 26 resulting configurations are either at the predefined limits or within the predefined configuration 27 ranges. 28 One or more additional metal layer may be added on top of one of the TOE mask sets. These additional 29 metal layer(s) just reroute the pads. Therefore, this last rerouting on top does not change the function 30 of the TOE itself; it depends on the package only, and is not relevant for the security of the TOE. For 31 these reasons, the metal layers are out of the scope of the certification and do not belong to the TOE. 32 Of course, in all cases passivation and isolation coating is applied on top of the last layers carrying 33 wires. 34 A shielding algorithm finishes the upper layers above security critical signals and wires, finally providing 35 the so called “security optimized wiring”. 36 The firmware used for the TOE internal testing and TOE operation and the cryptographic EC and base 37 libraries are part of the TOE and therefore part of the certification. The documents as described in 38 chapter 2.6 are supplied as user guidance. BPU functionality is part of the TOE but is not in the 39 certification scope. 40 The term Smartcard Embedded Software is used in the following for all operating systems and 41 applications stored and executed on the TOE. The TOE is the platform for the Smartcard Embedded 42 Software. The Smartcard Embedded Software itself is not part of the TOE. The TOE does not require 43 any non-TOE hardware/software/firmware. 44 11 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 2.1.1 Major security functions of theTOE 1 The major security functions of the TOE are: 2  Memory Protection Unit 3  Memory Encryption/Decryption Unit 4  Sensors for the purpose of monitoring proper chip operating conditions and detecting fault attack 5 scenarios complemented with digital error detection mechanisms such as parities, error detection 6 codes and instruction stream signatures 7  Security optimized wiring for protection of security critical signals 8  Instruction Stream Signature Checking (ISS) as a countermeasure against fault attacks that try to 9 manipulate the execution sequence of the instruction stream 10  Symmetric cryptographic coprocessor supporting AES and 3DES 11  Crypto2304T, an asymmetric crypto coprocessor together with the libraries supporting EC 12 (optional) 13  Cryptographic libraries for EC computations (optional) 14  A true random number generator, which can be used as a security service to the user and for 15 internal purposes 16  17 2.1.2 Not part of theTOE Security Functionality 18 Not part of the certification are 19  the Smartcard Embedded Software respectively user software (not part of the TOE), 20  the piece of software running at user premises and collecting the BPU receipts coming from the 21 TOE. This BPU software part is the commercially deemed part of the BPU software, not running on 22 the TOE, but allowing refunding the customer, based on the collected user blocking information. 23 The receipt from each blocked TOE is collected by this software – chip by chip. 24  25  Not part of the TSF are 26  The NRG software 27  The CRC module 28  The parts Toolbox and RSA of the ACL libraries 29  All other delivered libraries which do not have a security claim in this ST. 30 2.2 Hardware of theTOE 31 The hardware part of the TOE (see Figure 2) as defined in [PP] is comprised of: 32 Core System 33  32-bit CPU implementation of ARM Secure Core SC300 based on ARMv7-M Instruction set 34 architecture including the Instruction Stream Signature Checking (ISS) 35  CACHE for code and data buffering 36  Memory Encryption/Decryption Unit (MED) and Error Detection Unit 37  Memory Protection Unit (MPU) 38  Nested Vectored Interrupt Controller (NVIC) 39 40 Interfaces 41 12 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  Universal Asynchronous Receiver/Transmitter (UART) 1  Single-Wire Protocol (SWP) with NRG interface 2  Inter Integrated Circuit (I2C) interface 3  General Purpose Input Output (GPIO) 4  Synchronous Serial Communication (SSC) which provides the 5 Serial Peripheral Interface (SPI) 6  Universal Serial Bus (USB) interface 7  Standard ISO Interface (PAD) 8 9 Memories 10  Read-Only Memory (ROM, for internal firmware) 11  Random Access Memory (RAM) 12  SOLID FLASH™ NVM memory (NVM) 13 Note that the TOE has implemented a SOLID FLASH™ NVM memory module. Parts of this memory 14 module are configured to work as an EEPROM. 15 16 Peripherals 17  True Random Number Generator (TRNG) 18  System Module (SYS) 19  Clock Unit (CLK) 20 21 Coprocessors 22  Crypto2304T co-processor for asymmetric algorithms (Crypto, optional) 23  Symmetric Crypto co-processor for 3DES and AES 24  25 Analog Module (ANA) 26  Glitch Sensor 27  Temperature Sensor 28  Backside Light Detector 29  User Mode Security Life Control (UMSLC) 30 31 Buses 32  Memory Bus 33  Peripheral Bus 34 35 36 13 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Figure 1 Core with CPU, MED, MPU NVIC, ISS and Cache ROM RAM NVM Crypto 2304T SCP CRC Memory Bus SYS TRNG CLK Peripheral Bus ANA ISO I2C SSC GPIO EXF SWP UART T&W USB 1 Core Core System ROM Read Only Memory 2 NVM SOLID FLASH™ NVM RAM Random Access Memory 3 CLK Clock Unit SYS System Module 4 Crypto Crypto2304T SCP Symmetric Crypto Processor 5 CRC Cyclic Redundancy Check TRNG True Random Number Generator 6 T&W Timer and Watchdog UART UART 7 I2C Inter Integrated Circuit GPIO General Purpose IO 8 SSC Synchronous Serial Communication SWP Single Wire Protocol 9 USB Universal Serial Bus ANA Analog Units 10 ISO Standard Interface ISO Standard ISO Interface 11 EXF External Flash-memory (not available) 12 13 Figure 2 Block diagram of the M990X products (TOE parts are filled with light green, interface 14 parts are filled in light blue) 15 16 The TOE consists of smart card ICs (Security Controllers) meeting high requirements in terms of 17 performance and security. They are manufactured by Infineon Technologies AG in a 90 nm CMOS- 18 technology (L90). This TOE is intended to be used in smart cards for particularly security-relevant 19 applications and for its previous use as developing platform for smart card operating systems according 20 to the lifecycle model from [PP] 21 The term Smartcard Embedded Software is used in the following for all operating systems and 22 applications stored and executed on the TOE. The TOE is the platform for the Smartcard Embedded 23 Software. The Smartcard Embedded Software itself is not part of the TOE. 24 14 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The TOE consists of a core system, memories, co-processors, security peripherals, control logic and 1 peripherals. The major components of the core system are the 32-bit CPU (Central Processing Unit), the 2 MPU (Memory Protection Unit), the MED (Memory Encryption/Decryption Unit), the Nested Vectored 3 Interrupt Controller (NVIC), the Instruction Stream Signature Checking (ISS) and the Cache system. The 4 TOE contains the co-processors for EC (Crypto2304T) and DES/AES (SCP) processing, a CRC module 5 and the true random number generator, four timers and two watchdog timers and several external 6 interface services. All data of the memory block is encrypted, RAM and ROM are equipped with an error 7 detection code (EDC) and the SOLID FLASH™ NVM is equipped in addition with an error correction 8 code (ECC). 9 The memories are connected to the Core with the Memory Bus and the peripherals are connected with 10 the Peripheral Bus. 11 The Analog Modules (ANA) serve for operation within the specified range and manage the alarms. A set 12 of sensors (temperature sensor, backside light detector, glitch sensor) is used to detect excessive 13 deviations from the specified operational range and serve for robustness of the TOE and the UMSLC 14 function can be used to test the alarm lines. 15 The CPU is compatible with the instruction set of the ARMv7_M architecture. Despite its compatibility 16 the CPU implementation is entirely proprietary and not standard. 17 The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED). The 18 memory model of the TOE provides two distinct, independent levels. Additionally, up to eight regions 19 can be defined with different access rights controlled by the Memory Protection Unit (MPU). Errors in 20 RAM and ROM are automatically detected (EDC, Error Detection Code), in terms of the SOLID 21 FLASH™ NVM errors are detected and 1-Bit-errors are also corrected (ECC, Error Correction Code). 22 The controller of this TOE stores both code and data in a linear 4-GByte memory space, allowing direct 23 access without the need to swap memory segments in and out of memory using a memory protection 24 unit. 25 The CACHE is a high-speed memory-buffer located between the CPU and the main memories holding a 26 copy of some of the memory contents to enable access, which is considerably faster than retrieving the 27 information from the main memory. In addition to its fast access speed, the CACHE also consumes less 28 power than the main memories. The CACHE is equipped with an integrity check to verify the contents 29 of the cache memories. 30 A True Random Number Generator (TRNG) specially designed for smart card applications is 31 implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31 and 32 produces genuine random numbers which then can be used internally or by the user software. 33 The implemented sleep mode logic (clock stop mode per ISO/IEC 7816-3) is used to reduce the overall 34 power consumption. The timers permit easy implementation of communication protocols such as T=1 35 and all other time-critical operations. The UART-controlled I/O interface allows the smart card 36 controller and the terminal interface to be operated independently. 37 The Clock Unit (CLKU) supplies the clocks for all components of the TOE. It generates the system clock 38 and an approximately 1MHz clock for the timers. The 1MHz clock is derived from an internal oscillator, 39 while the system clock may either be based on the internal oscillator clock (internal clock mode) or on 40 an external clock (external clock mode). Additionally, a sleep mode is available. When operating in the 41 internal clock mode the system frequency can be configured by the user software combined with the 42 current limitation functionality. In the external clock mode, the clock is derived from the external clock 43 and a parameter with the range of 1 to 8. The system frequency may be 1 up to 8 times the externally 44 applied frequency but is of course limited to the maximum system frequency and can be combined with 45 the current limitation function. 46 15 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Two co-processors for cryptographic operations are implemented on the TOE. The Crypto2304T for 1 calculation of asymmetric algorithms and the Symmetric Cryptographic Processor (SCP) for dual-key or 2 triple-key triple-DES and AES calculations. These co-processors are especially designed for smart card 3 applications with respect to the security and power consumption. The SCP module computes the 4 complete DES algorithm within a few clock cycles and is especially designed to counter attacks like 5 DPA, EMA and DFA. The Crypto2304T module provides basic functions for the implementation of EC 6 cryptographic libraries. 7 Note that this TOE can be delivered with Crypto2304T co-processor accessible or blocked. The blocking 8 depends on the customer demands prior to the production of the hardware. No accessibility of the 9 deselected cryptographic co-processors is without impact on any other security policy of the TOE; it is 10 exactly equivalent to the situation where the user decides just not to use the cryptographic co- 11 processors. 12 The cyclic redundancy check (CRC) module is a 16-bit checksum generator, which is not part of the TSF 13 and therefore shall not be used for security-critical data. The TOE includes two timer modules each 14 with two 16-bit general purpose timers. The timer module can be used also as watchdog timer to 15 monitor system operation for possible timeouts and to check the correct order of operation. 16 An Interface Management module, located in the System Module (SYS), provides the TOE with the 17 possibility to maintain two or more data interfaces simultaneously. The TOE is provided with, 18 dependent on the configuration, different peripherals and interfaces as the Universal Serial Bus (USB), 19 the SWP Slave Peripheral (SWP), the Synchronous Serial Communication (SSC), which provides the 20 serial Peripheral Interface (SPI), the GPIO module (GPIO), the Inter-Integrated Cirquit Module (I2C) and 21 the Standard ISO Interface (PAD) to satisfy the different market requirements. 22 23 2.3 Firmware of theTOE 24 The entire firmware of the TOE consists of different parts: 25 The BOS (Boot Software) and the RMS (Resource Management System) compose the TOE firmware 26 stored in the ROM and the patches hereof in the SOLID FLASH™ NVM. All mandatory functions for 27 start-up and internal testing (BOS) are protected by a dedicated hardware firewall. Additionally two 28 levels are provided, the privileged level and the non-privilege level, both are protected by a hardwired 29 Memory Protection Unit (MPU) setting. 30 The UMSLC test includes the features “hardening” and the “Burn-In Test”. The feature “hardening” 31 analyzing a random SOLID FLASHTM NVM page after every regular program operation for written bits 32 that are losing their charge, and, in this very unlikely case, the page is rewritten. The “Burn-In Test” 33 during production is used to stress the chip in a high temperature, high internal voltage and active 34 operation for a certain time and filtering out defect parts to get a low failure rate. The TOE is qualified 35 for an extended temperature range from -40°C to +105°C. 36 The UMSLC Test is performed automatically at startup for BOS-V1 and must be manually triggered by 37 the user application for BOS-V2. 38 The RMS is accessible in privileged level only. The FL (Flash Loader) allows downloading of user 39 software to the NVM during the manufacturing process and can be completely deactivated. 40 41 2.4 Optional software of theTOE 42 43 The optional software part of the TOE consists of the cryptographic libraries EC and asymmetric Base 44 libreries. 45 16 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The EC library is used to provide a high level interface to Elliptic Curve cryptography and includes 1 countermeasures against SPA, DPA and DFA attacks. The routines are used for ECDSA signature 2 generation, ECDSA key generation and Elliptic Curve Diffie-Hellman key agreement. The EC library is 3 delivered as object code and integrated in this way into the user software. The certification covers the 4 standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of 224, 233, 256, 283, 320, 5 384, 409, 512 or 521 Bits. Note that there are numerous other curve types, being also secure in terms of 6 side channel attacks on this TOE, which can the user optionally add in the composition certification 7 process. 8 The Asymmetric Base library provides the low level interface to the asymmetric cryptographic 9 coprocessor for the ECC cryptographic libraries and has no user available interface. The Base and ECC 10 library can optionally be delivered in the alternative versions: 11  The version v2.07.003 12  The version v2.09.002 13 14 Table 2 Chip and optional 15 software delivery matrix 16 Chip Waferfab Toplayer Firmware-ID M9900 A22 Dresden none 80001141 (BOS-V1) 80001142 (BOS-V2) M9900 C22 Dresden WLP 80001141 (BOS-V1) 80001142 (BOS-V2) M9000 D22 Dresden WLB 80001141 (BOS-V1) 80001142 (BOS-V2) M9905 A11 Dresden none 80001151 (BOS-V1) M9906 A11 Dresden none 80001150 (BOS-V1) 17 2.5 Interfaces of theTOE 18  The physical interface of the TOE to the external environment is the entire surface of the IC. 19  The electrical interface of the TOE to the external environment is constituted by the pads of the 20 chip: 21 − The five ISO 7816 pads consist particularly of the contacted RES, I/O, CLK lines and supply lines 22 VCC and GND. The contact based communication is according to ISO 7816/ETSI/EMV. 23 The I2C communication can be driven via the ISO 7816 pads. In this case no other communication 24 using the ISO 7816 pads is possible. 25 − The GPIO interface consists of 4 pads which can be individually configured and combined. 26 27 − Also the I2C and the SSC/SPI communication can be exclusively driven via the GPIO pads. In this 28 case no other communication using the GPIO pads is possible. 29 − The USB interface is built out of two dedicated pads for data communication and two pads used 30 from the ISO 7816 interface supplying power and ground. 31 − The SWP interface is built out of one pad to support the SWP slave functionality. 32  The data-oriented I/O interface to the TOE is formed by the I/O pad. 33  The interface to the firmware is constituted by special registers used for hardware configuration and 34 control (Special Function Registers, SFR). 35 17 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  The interface of the TOE to the operating system is constituted on one hand by the RMS routine 1 calls and on the other by the instruction set of the TOE. 2  The interface of the TOE to the test routines is formed by the BOS test routine call, i.e. entry to test 3 mode (OS-TM entry). 4  The interface to the EC calculations is defined by the EC library (optionally). 5 2.6 Guidance documentation 6 The guidance documentation is listed in Table 1 7 2.7 Forms of delivery 8 The TOE can be delivered in form of bare dies, in form of plain wafers, in form of complete modules 9 (wire bond module M4.x, provided as single chip wire bond or as stacked wire bond), or in one of the 10 following an IC cases: MFC5.8 (FCOS), PG-VQFN-8-1, PG-VQFN-32-13 (SMD) and P-M2M4.7-8-1. In any 11 case the testing of the TOE is finished and the extended test features are removed. From a security 12 policy point of view the different forms of delivery do not have any impact. 13 The delivery can therefore be at the end of phase 3 or at the end of phase 4 which can also include pre- 14 personalization steps according to PP [PP]. 15 The delivery to the software developer (phase 2  phase 1) is handled by downloading via SecureX 16 portal. It contains the documentation as described above and the development and debugging tools. 17 Part of the software delivery could also be the Flash Loader program, provided by Infineon 18 Technologies, running on the TOE and receiving via the UART interface the transmitted information of 19 the user software to be loaded into the SOLID FLASH™ NVM memory. The download is only possible 20 after successful authentication. In addition, the user can permanently block further use of the Flash 21 Loader. Whether the Flash Loader program is present or not depends on the procurement order. 22 Table 3 TOE deliveries: forms and methods 23 TOE Component Delivered Format Delivery Method Comment M990X hardware See text above Customer chooses delivery method. This ST describes under which circumstances transport protection is provided by the TOE. All Firmware – – Stored on the delivered hardware. All software libraries ARM Library File (object code) Secured download1 – All User Guidance documents Personalized PDF Secured download – 24 The TOE is identified by the components as described in the physical scope in chapter 2.2. 25  The Hardware version, design step and Firmware version shall be read out from the chip by the 26 Generic Chip Identification Mode (GCIM) and compared against the correct versions. The procedure 27 how to read that data is described in the Programmers Reference Manual. The correct versions are 28 listed in chapter 2.3 29 1 Secured download is a way of delivery of documentation and TOE related software using a secure ishare connected to Infineon customer portal. The TOE user needs a DMZ Account to login (authenticate) via the Internet. 18 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  The correct library versions shall be verified by the corresponding hash values as defined in chapter 1 10. 2  The user guidance documents shall be compared to the versions listed in chapter 2.6 3 4 2.8 Production sites 5 The silicon of the design is produced in Dresden. 6 The delivery measures are described in the ALC_DVS aspect. 7 8 Table 4 Production site in chip identification 9 Production Site Chip Identification Dresden, Germany byte number 13 (Fab number): 02H 10 11 2.9 TOE Configuration 12 The TOE hardware offers different configuration options, which a customer can choose. The 13 mechanism to choose a configuration can be done by the following methods: 14 1. by product selection or dialog-based in Tools, 15 2. via Bill-per-Use (BpU) and Flash Loader (FL), 16 The degree of freedom for configuring the TOE is predefined by Infineon Technologies AG. The list of 17 TOE configurations is given in the confidential ST. 18 19 Besides fix TOE configurations, which can be ordered as usual, this TOE implements optionally the so 20 called Bill-Per-Use (BPU) ability. This solution enables the customer to tailor the product on his own to 21 the required configuration by blocking parts of the chip on demand into the final configuration at his 22 own premises, without further delivery or involving support by Infineon Technology AG. Customers, 23 who are intended to use this feature receive the TOE in a predefined configuration including the Flash 24 Loader software, enhanced with the BPU blocking software. The blocking information is part of a chip 25 configuration area and can be modified by customers using specific APDUs. Once a final blocking is 26 done, further modifications are disabled. 27 The BPU software part is only present on the products which have been ordered with the BPU option. In 28 all other cases this software is not present on the product. 29 Additionally the user can choose between different firmware BOS versions and optional software 30 libraries. 31 For the M9900 derivative the user can choose the TOE with the BOS firmware in the version BOS-V1 or 32 BOS-V2. 33 34 The NRG libraries are not part of this certification. 35 36 The hardware of this TOE can be delivered with the following configuration options: 37  both crypto co-processors accessible 38  with a blocked Crypto2304T 39 In the case the Crypto2304T is blocked, no EC computation supported by hardware is possible. No 40 accessibility of the deselected cryptographic co-processors is without impact on any other security 41 policy of the TOE; it is exactly equivalent to the situation where the user decides just not to use the 42 cryptographic co-processors. 43 19 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The TOE can be delivered with the following optional libraries 1  ECC 2  Asymmetric Base library for ECC 3 4 In case of deselecting one or several of these libraries the TOE does not provide the respective 5 functionality. 6 7 2.10 TOE initialization with Customer Software 8 Beside the various TOE configurations further possibilities of how the user inputs his software on the 9 TOE are in place. This provides a maximum of flexibility and for this an overview is given in the 10 following table: 11 12 Table 5 Options to implement user software at Infineon production premises 13 1 The user or/and a subcontractor downloads the software into the SOLID FLASH™ NVM memory on his own. Infineon Technologies AG has not received user software and there are no user data in the ROM. The Flash Loader can be activated or reactivated by the user or subcontractor to download his software in the SOLID FLASH™ NVM memory. 2 The user provides software for the download into the SOLID FLASH™ NVM memory to Infineon Technologies AG. The software is downloaded to the SOLID FLASH™ NVM memory during chip production. There are no user data in the ROM. The Flash Loader is deactivated. 3 The user provides software for the download into the SOLID FLASH™ NVM memory to Infineon Technologies AG. The software is downloaded to the SOLID FLASH™ NVM memory during chip production. There are no user data in the ROM The Flash Loader is blocked afterwards but can be activated or reactivated by the user or subcontractor to download his software in the SOLID FLASH™ NVM memory. Precondition is that the user has provided an own reactivation procedure in software prior to chip production to Infineon Technologies AG. 14 The Generic Chip Identification Mode (GCIM) data of the TOE allows a unique identification of each 15 TOE and provides several detailed production information. The Chip Identification Mode data is 16 accessible by a non-ISO reset or can be read directly from the configuration area located at the NVM by 17 the user operating system. The SLE97 Hardware Reference Manual [HRM] gives a detailed description 18 of the GCIM data. 19 20 20 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 3 Conformance Claims (ASE_CCL) 1 3.1 CC Conformance Claim 2 This Security Target (ST) and the TOE claim conformance to Common Criteria version CC:2022, part 1 3 [CC-1], part 2 [CC-2], part 3 [CC-3] part 4 [CC-4]and part 5 [CC-5]. 4 Conformance of this ST is claimed for: 5 Common Criteria part 2 extended and Common Criteria part 3 conformant. 6 3.2 PP Claim 7 This Security Target is in strict conformance to the 8 Security IC Platform Protection Profile [PP]. 9 The Security IC Platform Protection Profile is registered and certified by the Bundesamt für Sicherheit 10 in der Informationstechnik1 (BSI) under the reference BSI-PP-0084-2014, Version 1.0, 11 dated 2014-01-13. 12 The security assurance requirements of the TOE are according to the Security IC Platform Protection 13 Profile [PP]. They are all drawn from [CC-3]. 14 Table 6 The augmentations of the PP [PP] are listed below.Augmentations of the 15 assurance level of the TOE 16 Assurance Class Assurance components Description Lifecycle support ALC_DVS.2 Sufficiency of security measures Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability analysis 17 3.3 Package Claim 18 This Security Target does not claim conformance to a package of the PP [PP]. 19 The assurance level for the TOE is EAL5 augmented with the components ALC_DVS.2 and AVA_VAN.5. 20 21 22 1 Bundesamt für Sicherheit in der Informationstechnik (BSI) is the German Federal Office for Information Security 21 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 3.4 Conformance Rationale 1 This security target claims strict conformance only to one PP, the PP [PP]. 2 The Target of Evaluation (TOE) is a typical security IC as defined in PP chapter 1.2.2 comprising: 3  the circuitry of the IC (hardware including the physical memories), 4  configuration data, initialisation data related to the IC Dedicated Software and the behaviour of the 5 security functionality 6  the IC Dedicated Software with the parts 7  the IC Dedicated Test Software, 8  the IC Dedicated Support Software. 9 The TOE is designed, produced and/or generated by the TOE Manufacturer. 10 Security Problem Definition: 11 Following the PP [PP], the security problem definition is enhanced by adding two additional threats, an 12 organization security policy and an augmented assumption. Including these add-ons, the security 13 problem definition of this security target is consistent with the statement of the security problem 14 definition in the PP [PP], as the security target claimed strict conformance to the PP [PP]. 15 Conformance Rationale: 16 The augmented organizational security policy P.Add-Functions, coming from the additional security 17 functionality of the cryptographic libraries, the threat T-Masquerade.TOE and the threat memory 18 access violation, due to specific TOE memory access control functionality, have been added. These 19 add-ons have no impact on the conformance statements regarding CC [CC-1] and PP [PP], with 20 following rationale: 21 The security target remains conformant to CC part 2 [CC-2], as the possibility to introduce additional 22 restrictions is given. 23 The security target fulfils the strict conformance claim of the PP [PP] due to the application notes 5, 6 24 and 7 which apply here. By those notes the addition of further security functions and security services 25 are covered, even without deriving particular security functionality from a threat but from a policy. 26 Due to additional security functionality, one coming from the cryptographic libraries - O.Add- 27 Functions, the memory access control - O.Mem-Access, and the hash additional security objectives 28 have been introduced. These add-ons have no impact on the conformance statements regarding CC 29 [CC-1] and PP [PP], with following rational: 30 The security target remains conformant to CC part 2 [CC-2], as the possibility to introduce additional 31 restrictions is given. 32 The security target fulfils the strict conformance of the PP [PP] due to the application note 9 applying 33 here. This note allows the definition of high-level security goals due to further functions or services 34 provided to the Security IC Embedded Software. 35 Therefore, the security objectives of this security target are consistent with the statement of the 36 security objectives in the PP [PP], as the security target claimed strict conformance to the PP [PP]. 37 38 All security functional requirements defined in the PP [PP] are included and completely defined in this 39 ST. The security functional requirements listed in the following are all taken from Common Criteria part 40 2 [CC-2] and additionally included and completely defined in this ST: 41 22 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  FDP_ACC.1 “Subset access control” 1  FDP_ACF.1 “Security attribute based access control” 2  FMT_MSA.1 “Management of security attributes” 3  FMT_MSA.3 “Static attribute initialisation” 4  FMT_SMF.1“Specification of Management functions” 5  FCS_COP.1 “Cryptographic support” 6  FCS_CKM.1 “Cryptographic key generation” 7 The security functional requirement 8  FPT_TST.2 “Subset TOE security testing“ (Requirement from [CC-2]) 9 is included and completely defined in this ST, section 6. 10 All assignments and selections of the security functional requirements are done in the [PP] and in this 11 security target in section 7. 12 The Assurance Requirements of the TOE obtain the Evaluation Assurance Level 5 augmented with the 13 assurance components ALC_DVS.2 and AVA_VAN.5 for the TOE. 14  15  With CC:2022 several SFR changes are introduced. Due to this ST claiming conformance to CC:2022 16  and [PP], rationales are provided that these changes do not affect the conformance claim to [PP]: 17  18  FCS_COP.1: for this SFR dependencies are changed in CC:2022. FCS_CKM.4 is removed and 19 instead FCS_CKM.6 added. Further FCS_CKM.5 is added for key derivation as an alternative. 20  FCS_CKM.1: for this SFR dependencies are changed in CC:2022. Additionally, to FCS_CKM.2 and 21 FCS_COP.1, one further SFR is introduced as alternative: FCS_CKM.5. This SFR targets key 22 derivation, subsequent to FCS_CKM.1. In CC:2022 key derivation would have been part of 23 FCS_CKM.1 and thus conformancy to [PP] can still be claimed. FCS_CKM.4 is removed and instead 24 FCS_CKM.6 added. All other dependencies (i.e. FCS_RNG.1 or FCS_RBG.1) are in addition to the 25 already existing ones, i.e. add stricter requirements. 26  FCS_CKM.6 replaces FCS_CKM.4 and adds further requirements on the timing of key destruction. 27 As an alternative dependency to FCS_CKM.1, FCS_CKM.5 (key derivation) can be used. As 28 FCS_CKM.5 is neither used within [PP] nor within this ST, it has no relevance in this context. 29  FCS_RNG.1: this SFR is taken from [CC-2] rather than [PP]. 30  FMT_LIM.1 and FMT_LIM.2 are taken from [CC-2] rather than [PP]. There is a slightly different 31 phrasing (i.e. removing redundancy from FMT_LIM.1) and availability and capability policy 32 mentioned in both SFR’s. The meaning though is the same and therefore conformancy can still be 33 claimed. 34  FDP_SDC.1: this SFR is taken from [CC-2] rather than [PP]; An assignment from [PP] is changed to 35 a selection [CC-2], which means the requirement is more stringent and thus can be considered a 36 subset of the requirement from [PP]. 37 Further with CC:2022 some SAR changes were introduced. Rationales are provided that these changes 38 do not affect the conformance claim to [PP]: 39  ASE_CCL.1: for CC:2022 several extensions were introduced (e.g. exact conformance to PP), which 40 add to the already existing assurance requirements. No relaxation was introduced. 41  ASE_INT.1: introduction of multi-assurance in combination with PP-configuration: not relevant for 42 [PP] 43  ASE_REQ.2: extended for multi assurance: not relevant for [PP] 44 23 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  AVA_VAN.5: extension about third party components introduced. No relaxation was introduced. 1  ALC_TAT.1: extension with guidance on the minimum content for an implementation standards 2 description and rules with ADV_COMP.1. No relaxation was introduced. 3 4 24 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 4 Security Problem Definition (ASE_SPD) 1 The content of the PP [PP] applies to this chapter completely. 2 4.1 Threats 3 The threats are directed against the assets and/or the security functions of the TOE. For example, 4 certain attacks are only one step towards a disclosure of assets while others may directly lead to a 5 compromise of the application security. The more detailed description of specific attacks is given later 6 on in the process of evaluation and certification. An overview on attacks is given in PP [PP] section 3.2. 7 The threats to security are defined and described in PP [PP] section 3.2. 8 Table 7 Threats according PP [PP] 9 Threat Description T.Phys-Manipulation Physical Manipulation T.Phys-Probing Physical Probing T.Malfunction Malfunction due to Environmental Stress T.Leak-Inherent Inherent Information Leakage T.Leak-Forced Forced Information Leakage T.Abuse-Func Abuse of Functionality T.RND Deficiency of Random Numbers 4.1.1 AdditionalThreat due toTOE specific Functionality 10 The additional functionality of introducing sophisticated privilege levels and access control allows the 11 secure separation between the operation system(s) and applications, the secure downloading of 12 applications after personalization and enables multitasking by separating memory areas and 13 performing access controls between different applications. Due to this additional functionality “area 14 based memory access control” a new threat is introduced. 15 The Smartcard Embedded Software is responsible for its User Data according to the assumption 16 “Treatment of User Data (A.Resp-Appl)”. However, the Smartcard Embedded Software may comprise 17 different parts, for instance an operating system and one or more applications. In this case, such parts 18 may accidentally or deliberately access data (including code) of other parts, which may result in a 19 security violation. 20 The TOE shall avert the threat “Memory Access Violation (T.Mem-Access)” as specified below. 21 T.Mem-Access Memory Access Violation 22 Parts of the Smartcard Embedded Software may cause security violations by accidentally or 23 deliberately accessing restricted data (which may include code) or privilege levels. Any restrictions are 24 defined by the security policy of the specific application context and must be implemented by the 25 Smartcard Embedded Software. 26 T.Masquerade_TOE Masquerade of the TOE 27 An attacker may threaten the property being a genuine TOE by producing a chip which is not a genuine 28 TOE but wrongly identifying itself as genuine TOE sample. This threat has been additionally introduced 29 because the chip can be delivered without an User OS doing the identification. 30 25 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Table 8 Additional threats due to TOE specific functions and augmentations 1 T.Mem-Access Memory Access Violation T.Masquerade_TOE Masquerade of the TOE 2 Note for T.Masquerade_TOE: 3 The TOE does not provide transport protection. Therefore, this threat does not map to 4 O.Authentication and OE.TOE_Auth as in [PP] and the packages Package “Authentication of the 5 Security IC” is not claimed. Instead, the treat must be completely handled by the Operative 6 Environment and therefore the objective to the environment OE.SecureDelivery is defined in this ST. 7 8 9 4.1.2 Assets regarding theThreats 10 The primary assets concern the User Data which includes the user data as well as program code 11 (Security IC Embedded Software) stored and in operation and the provided security services. These 12 assets have to be protected while being executed and or processed and on the other hand, when the 13 TOE is not in operation. 14 This leads to four primary assets with its related security concerns: 15  SC1 Integrity of user data of the Composite TOE 16  SC2 confidentiality of user data of the Composite TOE being stored in the TOE’s protected memory 17 areasSC3 Correct operation of the security services provided by the TOE for the Security IC 18 Embedded Software, 19  SC4 deficiency of random numbers 20 SC4 is an additional security service provided by this TOE which is the availability of random numbers. 21 These random numbers are generated either by a true random number or a deterministic random 22 number generator or by both, when a true random number is used as seed for the deterministic random 23 number generator. Note that the generation of random numbers is a requirement of the PP [PP]. 24 To be able to protect the listed assets the TOE shall protect its security functionality as well. Therefore 25 critical information about the TOE shall be protected. Critical information includes: 26  logical design data, physical design data, IC Dedicated Software, and configuration data 27  Initialisation Data and Pre-personalisation Data, specific development aids, test and 28 characterisation related data, material for software development support, and reticles. 29 The information and material produced and/or processed by the TOE Manufacturer in the TOE 30 development and production environment (Phases 2 up to TOE Delivery) can be grouped as follows: 31  logical design data, 32  physical design data, 33  IC Dedicated Software, Security IC Embedded Software, Initialisation Data and Pre-personalisation 34 Data, 35  specific development aids, 36  test and characterisation related data, 37  material for software development support, and 38  reticles and products in any form 39 26 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public as long as they are generated, stored, or processed by the TOE Manufacturer. 1 For details see PP [PP] section 3.1. 2 4.2 Organizational Security Policies 3 The TOE has to be protected during the first phases of their lifecycle (phases 2 up to TOE delivery which 4 can be after phase 3 or phase 4). Later on each variant of the TOE has to protect itself. The 5 organizational security policy covers this aspect. 6 P.Process-TOE Protection during TOE Development and Production 7 An accurate identification must be established for the TOE. This requires that each instantiation of the 8 TOE carries this unique identification. 9 The organizational security policies are defined and described in PP [PP] section 3.3. Due to the 10 augmentations of PP [PP] an additional policy is introduced and described in the next chapter. 11 Table 9 Organizational Security Policies according PP [PP] 12 P.Process-TOE Indentification during TOE Development and Production 4.2.1 Augmented Organizational Security Policy 13 Due to the augmentations of the PP [PP] an additional policy is introduced. 14 The TOE provides specific security functionality, which can be used by the Smartcard Embedded 15 Software. In the following specific security functionality is listed which is not derived from threats 16 identified for the TOE’s environment because it can only be decided in the context of the smartcard 17 application, against which threats the Smartcard Embedded Software will use the specific security 18 functionality. 19 The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality 20 (P.Add-Functions)” as specified below. 21 P.Add-Functions Additional Specific Security Functionality 22 The TOE shall provide the following specific security functionality to the Smartcard Embedded 23 Software: 24  Advanced Encryption Standard (AES) 25  Triple Data Encryption Standard (3DES) 26  Elliptic Curve Cryptography (EC) 27 28 Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case the 29 Crypto2304T is blocked, no ECC computation supported by hardware is possible. The ECC 30 functionality has then to be removed from this policy. 31 Note:The TOE can also be delivered with the optional ECC library. The optional ECC library needs an 32 accessible Crypto2304T. If the optional ECC library is not delivered then ECC functionality has to be 33 removed from this policy. 34 27 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 4.3 Assumptions 1 The TOE assumptions on the operational environment are defined and described in PP [PP] section 3.4. 2 The assumptions concern the phases where the TOE has left the chip manufacturer. 3 4 A.Process-Sec-IC Protection during Packaging, Finishing and Personalization: 5 It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to 6 delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its 7 manufacturing and test data (to prevent any possible copy, modification, retention, theft or 8 unauthorised use). 9 A.Resp-Appl Treatment of User Data: 10 All user data of the Composite TOE are owned by Security IC Embedded Software. Therefore, it must 11 be assumed that security relevant user data of the Composite TOE (especially cryptographic keys) are 12 treated by the Security IC Embedded Software as defined for its specific application context. 13 The support of cipher schemas needs to make an additional assumption. 14 Table 10 Assumption according PP [PP] 15 A.Process-Sec-IC Protection during Packaging, Finishing and Personalization A.Resp-Appl Treatment of User Data 16 17 28 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 5 Security objectives (ASE_OBJ) 1 This section shows the subjects and objects where are relevant to the TOE. 2 A short overview is given in the following. 3 The user has the following standard high-level security goals related to the assets: 4  SG1 maintain the integrity of User Data and of the Security IC Embedded Software 5  SG2 maintain the confidentiality of User Data and of the Security IC Embedded Software 6  SG3 maintain the correct operation of the security services provided by the TOE for the Security IC 7 Embedded Software 8  SG4 provision of random numbers. 9 5.1 Security objectives for theTOE 10 The security objectives of the TOE are defined and described in PP [PP] section 4.1. 11 12 Table 11 Objectives for the TOE according to PP [PP] 13 O.Phys-Manipulation Protection against Physical Manipulation O.Phys-Probing Protection against Physical Probing O.Malfunction Protection against Malfunction O.Leak-Inherent Protection against Inherent Information Leakage O.Leak-Forced Protection against Forced Information Leakage O.Abuse-Func Protection against Abuse of Functionality O.Identification TOE Identification O.RND Random Numbers 14 The TOE provides “Additional Specific Security Functionality (O.Add-Functions)” as specified below. 15 O.Add-Functions : Additional Specific Security Functionality 16 The TOE must provide the following specific security functionality to the Smartcard Embedded 17 Software: 18  Advanced Encryption Standard (AES) 19  Triple Data Encryption Standard (3DES) 20  Elliptic Curve Cryptography (EC) (optional) 21 The hardware of this TOE can be delivered with the following configuration options: 22  both crypto co-processors accessible 23  with a blocked Crypto2304T 24 In the case the Crypto2304T is blocked, no EC computations supported by hardware are possible. 25 The optional security relevant software part of the TOE consists of the following optional libraries: 26  EC Cryptographic Library 27 28 The TOE shall provide “Area based Memory Access Control (O.Mem-Access)” as specified below. 29 29 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public O.Mem-Access: Area based Memory Access Control 1 The TOE must provide the Smartcard Embedded Software with the capability to define restricted 2 access memory areas. The TOE must then enforce the partitioning of such memory areas so that access 3 of software to memory areas and privilege levels is controlled as required, for example, in a multi- 4 application environment. 5 Table 12 Additional objectives due to TOE specific functions and augmentations 6 O.Add-Functions Additional specific security functionality O.Mem-Access Area based Memory Access Control 5.2 Security Objectives for the Security IC Embedded Software and 7 operational Environment (OE) 8 The security objectives for the Security IC Embedded Software and operational Environment of the 9 TOE are defined and described in PP [PP]. 10 Table 13 Objectives for the OE according to PP [PP] 11 OE.Resp-Appl Treatment of User Data OE.Process-Sec-IC Protection during composite product manufacturing 12 This ST further defines the objectives for the environment OE.Secure_Delivery as specified below. 13 OE.Secure_Delivery: 14 The TOE does not provide transport protection. Therefore, technical and / or organisational security 15 procedures (e.g. a custom mutual authentication mechanism or a security transport) should be put in 16 place by the customer to secure the personalized TOE during delivery as required by the security needs 17 of the loaded IC Embedded Software. 18 19 The table below lists the security objectives for the environment in the life cycle phases. 20 Table 14 Security objectives for the environment 21 Phase 1 OE.Resp-Appl Treatment of User Data Phase 5 – 6 optional Phase 4 OE.Process-Sec-IC Protection during composite product manufacturing Phase 3, 4 OE.Secure_Delivery The TOE does not provide transport protection. Therefore, technical and / or organisational security procedures (e.g. a custom mutual authentication mechanism or a security transport) should be put in place by the customer to secure the personalized TOE during delivery as required by the security needs of the loaded IC Embedded Software. 22 30 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 5.3 Security Objectives Rationale 1 The security objectives rationale of the TOE are defined and described in PP [PP] section 4.4. 2 The table below describes the rationale for organizational security policy and threats which are added 3 in this ST. 4 Table 15 Security Objective Rationale 5 Threats or Organisational Security Policy Security Objective P.Add-Functions O.Add-Functions T.Mem-Access O.Mem-Access T.Masquerade_TOE OE.Secure_Delivery The justification related to the security objective “Additional Specific Security Functionality 6 (O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the 7 same specific security functionality as required by P.Add-Functions; the organizational security policy is 8 covered by the objective. 9 Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys- 10 Manipulation and O.Leak-Forced define how to implement the specific security functionality required 11 by P.Add-Functions. (Note that these objectives support that the specific security functionality is 12 provided in a secure way as expected from P.Add-Functions.) Especially O.Leak-Inherent and O.Leak- 13 Forced refer to the protection of confidential data (User Data or TSF data) in general. User Data are also 14 processed by the specific security functionality required by P.Add-Functions. 15 Compared to the PP [PP] an enhancement regarding memory area protection has been established. 16 The clear definition of privilege levels for operated software establishes the clear separation of different 17 restricted memory areas for running the firmware, downloading and/or running the operating system 18 and to establish a clear separation between different applications. Nevertheless, it is also possible to 19 define a shared memory section where separated applications may exchange defined data. The 20 privilege levels clearly define by using a hierarchical model the access right from one level to the other. 21 These measures ensure that the threat T.Mem-Access is clearly covered by the security objective 22 O.Mem-Access. 23 The justification of the additional policy and the additional assumption show that they do not 24 contradict to the rationale already given in the Protection Profile for the assumptions, policy and 25 threats defined there. 26 The objective OE.Secure_Delivery is defined to require transport protection by the environment as the 27 TOE does not provide this objective. 28 29 31 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 6 Extended Component Definition (ASE_ECD) 1 There are four extended components defined and described for the TOE: 2  the family FAU_SAS at the class FAU Security Audit 3  the component FPT_TST.2 at the class FPT Protection of the TSF 4 The extended component FAU_SAS is defined and described in PP [PP] section 5. The component 5 FPT_TST.2 is defined in the following sections. 6 6.1 “SubsetTOE security testing (FPT_TST)” 7 The security is strongly dependent on the correct operation of the security functions. Therefore, the 8 TOE shall support that particular security functions or mechanisms are tested in the operational phase 9 (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the TOE or is done 10 automatically and continuously. 11 Part 2 of the Common Criteria provides the security functional component “TSF testing (FPT_TST.1)”. 12 The component FPT_TST.1 provides the ability to test the TSF’s correct operation. 13 For the user it is important to know which security functions or mechanisms can be tested. The 14 functional component FPT_TST.1 does not mandate to explicitly specify the security functions being 15 tested. In addition, FPT_TST.1 requires verification of the integrity of TSF data and of the stored TSF 16 executable code which might violate the security policy. Therefore, the functional component ”Subset 17 TOE security testing (FPT_TST.2)” of the family TSF self test has been newly created. This component 18 allows that particular parts of the security mechanisms and functions provided by the TOE are tested. 19 6.2 Definition of FPT_TST.2 20 The functional component “Subset TOE security testing (FPT_TST.2)” has been newly created 21 (Common Criteria Part 2 extended). This component allows that particular parts of the security 22 mechanisms and functions provided by the TOE can be tested after TOE Delivery or are tested 23 automatically and continuously during normal operation transparent for the user. 24 This security functional component is used instead of the functional component FPT_TST.1 from 25 Common Criteria Part 2. For the user it is important to know which security functions or mechanisms 26 can be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security 27 functions being tested. In addition, FPT_TST.1 requires verifying the integrity of TSF data and stored 28 TSF executable code which might violate the security policy. 29 The functional component “Subset TOE testing (FPT_TST.2)” is specified as follows (Common Criteria 30 Part 2 extended). 31 32 32 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 6.3 TSF self test (FPT_TST) 1 Family Behavior The Family Behavior is defined in [CC-2] section 15.17.1 2 Component leveling 3 FPT_TST TSF self test 1 2 4 FPT_TST.1 The component FPT_TST.1 is defined in [CC-2] section 15.17.1. 5 FPT_TST.2 Subset TOE security testing, provides the ability to test the correct operation of 6 particular security functions or mechanisms. These tests may be performed at start- 7 up, periodically, at the request of the authorized user, or when other conditions are 8 met. It also provides the ability to verify the integrity of TSF data and executable code. 9 Management: FPT_TST.2 10 The following actions could be considered for the management functions in FMT: 11 management of the conditions under which subset TSF self testing occurs, such as 12 during initial start-up, regular interval or under specified conditions management of 13 the time of the interval appropriate. 14 Audit: FPT_TST.2 15 There are no auditable events foreseen. 16 FPT_TST.2 Subset TOE testing 17 Hierarchical to: No other components. 18 Dependencies: No dependencies 19 FPT_TST.2.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically 20 during normal operation, at the request of the authorized user, and/or at the conditions 21 [assignment: conditions under which self test should occur]] to demonstrate the correct 22 operation of [assignment: functions and/or mechanisms]. 23 24 33 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 7 Security Requirements (ASE_REQ) 1 For this section the PP [PP] section 6 can be applied completely. 2 The security functional requirements (SFR) for the TOE are defined and described in the PP [PP] section 3 6.1 and in the following description. 4 The Table 16 provides an overview of the functional security requirements of the TOE, defined in PP 5 [PP] section 6.1. In the last column it is marked if the requirement is refined. The refinements are also 6 valid for this ST. 7 Table 16 Security functional requirements defined in PP [PP] 8 Security Functional Requirement Refined in PP [PP] FRU_FLT.2 Limited fault tolerance Yes FPT_FLS.1 Failure with preservation of secure state Yes FAU_SAS.1 Audit storage No FPT_PHP.3 Resistance to physical attack Yes FDP_ITT.1 Basic internal transfer protection Yes FPT_ITT.1 Basic internal TSF data transfer protection Yes FDP_IFC.1 Subset information flow control No FDP_SDI.2 Stored data integrity monitoring and action No 9 Table 17 provides an overview of all SFRs which are taken from the CC standard [CC-2]. They replace 10 the corresponding SFRs from PP [PP]. 11 Table 17 Security functional requirements defined in CC [CC-2] 12 Security Functional Requirement FMT_LIM.1 Limited capabilities FMT_LIM.2 Limited availability FCS_RNG.1 Random number generation FDP_SDC.1 Stored data confidentiality 13 14 The Table 18 provides an overview about the augmented security functional requirements, which are 15 added additional to the TOE and defined in this ST. All requirements are taken from Common Criteria 16 Part 2 [CC-2], with the exception of the requirement FPT_TST.2, which is defined in this ST completely. 17 18 Table 18 Augmented security functional requirements 19 Security Functional Requirement FPT_TST.2 Subset TOE security testing FDP_ACC.1 Subset access control FDP_ACF.1 Security attribute based access control FMT_MSA.1 Management of security attributes FMT_MSA.3 Static attribute initialization FMT_SMF.1 Specification of Management functions 34 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public FCS_COP.1 Cryptographic support FCS_CKM.1 Cryptographic key generation 1 All assignments and selections of the security functional requirements of the TOE are done in PP [PP] 2 and in the following description. 3 The above marked extended components FMT_LIM.1 and FMT_LIM.2 are introduced in PP [PP] to 4 define the IT security functional requirements of the TOE as an additional family (FMT_LIM) of the 5 Class FMT (Security Management). This family describes the functional requirements for the Test 6 Features of the TOE. The new functional requirements were defined in the class FMT because this class 7 addresses the management of functions of the TSF. 8 The additional component FAU.SAS is introduced to define the security functional requirements of the 9 TOE of the Class FAU (Security Audit). This family describes the functional requirements for the storage 10 of audit data and is described in the next chapter. 11 The requirement FPT_TST.2 is the subset of TOE testing and originated in [CC-2]. This requirement is 12 given as the correct operation of the security functions is essential. The TOE provides mechanisms to 13 cover this requirement by the smartcard embedded software and/or by the TOE itself. 14 7.1 FAU_SAS 15 To define the security functional requirements of the TOE an additional family (FAU_SAS) of the Class 16 FAU (Security Audit) is defined here. This family describes the functional requirements for the storage 17 of audit data. It has a more general approach than FAU_GEN, because it does not necessarily require 18 the data to be generated by the TOE itself and because it does not give specific details of the content of 19 the audit records. 20 The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common Criteria 21 Part 2 extended). 22 23 FAU_SAS.1 Audit Storage 24 Hierarchical to: No other components 25 Dependencies: No dependencies. 26 FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the capability 27 to store the Initialization Data and/or Pre-personalization Data and/or 28 supplements of the Security IC Embedded Software in the not changeable 29 configuration page area and non-volatile memory. 30 7.2 FPT_TST.2 31 The security is strongly dependent on the correct operation of the security functions. Therefore, the 32 TOE shall support that particular security functions or mechanisms are tested in the operational phase 33 (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the TOE. 34 The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below (Common 35 Criteria Part 2 extended). 36 37 FPT_TST.2 Subset TOE testing 38 Hierarchical to: No other components 39 35 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Dependencies: No dependencies 1 FPT_TST.2.1 The TSF shall run a suite of self tests at the request of the authorized user to 2 demonstrate the correct operation of the alarm lines and/or the environmental 3 sensor mechanisms 4 7.3 FCS_RNG 5 To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the 6 class FCS (cryptographic support) is defined in [CC-2]. 7 8 FCS_RNG.1 Random Number Generation 9 Hierarchical to: No other components 10 Dependencies: No dependencies 11 FCS_RNG.1 Random numbers generation Class PTG.2 according to [CC-2] 12 FCS_RNG.1.1 The TSF shall provide a physical1 random number generator that implements: 13 PTG.2.1 A: total failure test detects a total failure of entropy source 14 immediately when the RNG has started. When a total failure is detected, no 15 random numbers will be output. 16 PTG.2.2 : If a total failure of the entropy source occurs while the RNG is 17 being operated, the RNG prevents the output of any internal random number 18 that depends on some raw random numbers that have been generated after the 19 total failure of the entropy source. 20 21 PTG.2.3: The online test shall detect non-tolerable statistical defects of the 22 rawrandom number sequence (i) immediately when the RNG has started, and 23 (ii) while the RNG is being operated. The TSF must not output any random 24 numbers before the power-up online test has finished successfully or when a 25 defect has been detected. 26 PTG.2.4 :The online test procedure shall be effective to detect non- 27 tolerable weaknesses of the random numbers soon. 28 29 PTG.2.5 :The online test procedure checks the quality of the raw random num 30 ber sequence. It is triggered continuously. The online test is suitable for 31 detecting non-tolerable statistical defects of the statistical properties of the raw 32 random numbers within an acceptable period of time.2 33 34 FCS_RNG.1.2 The TSF shall provide numbers in the format 8- or 16-bit3 that meet 35 PTG.2.6: Test procedure A, as defined in [RNG] does not distinguish the internal 36 random numbers from output sequences of an ideal RNG. 37 1 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] 2 [assignment: list of security capabilities] 3 [selection: bits, octets of bits, numbers [assignment: format of the numbers]] 36 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public PTG.2.7: The average Shannon entropy per internal random bit exceeds 0.997.1 1 7.4 Limited Capabilities and Limited Availability 2 The SFR’s FMT_LIM.1 and FMT_LIM.2 from [PP] are adapted due to CC:2022. 3 FMT_LIM.1 Limited Capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2: Limited availability FMT_LIM.1.1 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 attacks2 . 4 FMT_LIM.2 Limited availability Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities. 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 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 attacks3 . 7.5 Memory access control 5 Usage of multiple applications in one Smartcard often requires code and data separation in order to 6 prevent that one application can access code and/or data of another application. For this reason the 7 TOE provides Area based Memory Access Control. The underlying Memory Protection Unit (MPU) is 8 documented in section 4 of the [HRM]. 9 The security service being provided is described in the Security Function Policy (SFP) Memory Access 10 Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)” requires that 11 this policy is in place and defines the scope where it applies. The security functional requirement 12 “Security attribute based access control (FDP_ACF.1)” defines security attribute usage and 13 characteristics of policies. It describes the rules for the function that implements the Security Function 14 Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or not is taken 15 based upon attributes allocated to the software. The Smartcard Embedded Software defines the 16 attributes and memory areas. The corresponding permission control information is evaluated “on-the- 17 fly” by the hardware so that access is granted/effective or denied/inoperable. 18 1 [assignment: a defined quality metric] 2 [assignment: Limited capability and availability policy] 3 [assignment: Limited capability and availability policy] 37 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The security functional requirement “Static attribute initialisation (FMT_MSA.3)” ensures that the 1 default values of security attributes are appropriately either permissive or restrictive in nature. 2 Alternative values can be specified by any subject provided that the Memory Access Control Policy 3 allows that. This is described by the security functional requirement “Management of security 4 attributes (FMT_MSA.1)”. The attributes are determined during TOE manufacturing (FMT_MSA.3) or 5 set at run-time (FMT_MSA.1). 6 From TOE’s point of view the different roles in the Smartcard Embedded Software can be distinguished 7 according to the memory based access control. However the definition of the roles belongs to the user 8 software. 9 The following Security Function Policy (SFP) Memory Access Control Policy is defined for the 10 requirement “Security attribute based access control (FDP_ACF.1)”: 11 12 Memory Access Control Policy 13 The TOE shall support the standard ARMv7 Protected Memory System Architecture model. 14 The MPU provides full support for: 15  Protection regions. 16  Overlapping protection regions, with ascending region priority: 17 − Region 7 = highest priority. 18 − Region 0 = lowest priority. 19  Access permissions. 20  MPU mismatches and permission violations invoke the programmable-priority MemManage fault 21 handler. 22 The MPU can be used to: 23  Enforce privilege rules, preventing user applications from corrupting operating system data. 24  Separate processes, blocking the active task from accessing other tasks’ data. 25  Enforce access rules, allowing memory regions to be defined as read-only or detecting unexpected 26 memory accesses. 27 28 Subjects, Objects and Operations of the policy 29  Subjects: privilege or non-privilege level of the ARM processor 30  Objects: memory/code addresses 31  Operations: Read a/o write a/o execute access 32 33 Attributes of the policy: 34  MPU enable/disable bit. 35  8 regions with the following attributes 36 − A unique priority 37 − The enable bit 38 − the start address and size 39 − an access matrix which defines if an Operation of a Subject to an Object lying in the region is 40 allowed or denied 41  The default region with the following security attribute: 42 − A bit which defines if an Operation for the Subject (privilege level) is allowed or if no Operation is 43 allowed for any Subject. 44 38 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1 Roles of the policy: 2 The roles correspond 1-1 to the subjects. 3 4 Properties of the policy: 5  If an address is contained in multiple enabled regions, then the region with the highest priority 6 defines the access rights. 7  If an address is contained in no region then the default region defines the access rights. 8  The region defining the access rights checks in the access matrix if the Subject has access to the 9 Object with respect to the desired Operation. In case the access is denied the MPU throws an access 10 violation exception. 11 12 The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below. 13 14 FDP_ACC.1 Subset access control 15 Hierarchical to: No other components. 16 Dependencies: FDP_ACF.1 Security attribute based access control 17 FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all Subjects, all 18 Objects and all Operations. 19 20 21 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified 22 below. 23 24 FDP_ACF.1 Security attribute based access control 25 Hierarchical to: No other components. 26 Dependencies: FDP_ACC.1 Subset access control 27 FMT_MSA.3 Static attribute 28 FDP_ACF.1.1 The TSF shall enforce the Memory Access Control Policy to objects based on 29 the following: As specified in the definition of the memory access control policy. 30 31 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among 32 controlled subjects and controlled objects is allowed: 33 As specified in the definition of the memory access control policy. 34 35 FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the 36 following additional rules: none. 37 38 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the 39 following additional rules: none. 40 41 42 The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below. 43 44 FMT_MSA.3 Static attribute initialization 45 46 Hierarchical to: No other components. 47 48 39 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Dependencies: FMT_MSA.1 Management of security attributes 1 FMT_SMR.1 security roles 2 3 FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide restrictive1 4 default values for security attributes that are used to enforce the SFP. 5 6 FMT_MSA.3.2 The TSF shall allow the privilege level to specify alternative initial values to 7 override the default values when an object or information is created. 8 9 10 The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified 11 below: 12 13 FMT_MSA.1 Management of security attributes 14 15 Hierarchical to: No other components. 16 17 Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow 18 control] 19 FMT_SMF.1 Specification of management functions 20 FMT_SMR.1 Security roles 21 22 FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability to 23 modify2 the security attributes which are defined in the Memory Access Control 24 Policy3 to the privilege level4 . 25 The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as 26 specified below: 27 28 FMT_SMF.1 Specification of management functions 29 30 Hierarchical to: No other components 31 32 Dependencies: No dependencies 33 34 FMT_SMF.1.1 The TSF shall be capable of performing the following security management 35 functions: The privilege level shall be able to access the configuration registers 36 of the MPU. 37 38 1 The static definition of the access rules is documented in [HRM] 2 [selection: change_default, query, modify, delete, [assignment: other operations]] 3 [assignment: list of security attributes] 4 [assignment: list of security attributes] 40 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 7.6 Support of Cipher Schemes 1 The following additional specific security functionality is implemented in the TOE: 2 FCS_COP.1 Cryptographic operation requires a cryptographic operation to be performed in accordance 3 with a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and 4 cryptographic key sizes can be based on an assigned standard; dependencies are discussed in Section 5 7.9.1.1. 6 The following additional specific security functionality is implemented in the TOE: 7  Advanced Encryption Standard (AES) 8  Triple Data Encryption Standard (3DES) 9  Elliptic Curve Cryptography (EC)1 10 11 General statements with regard to Elliptic Curves: 12 The EC library is delivered as object code and in this way integrated in the user software. The 13 certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of 14 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are numerous other curve types, 15 being also secure in terms of side channel attacks on this TOE, which the user can optionally add in the 16 composition certification process. 17 18 7.6.1 Triple-DES Operation 19 The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as 20 specified below. 21 FCS_COP.1/DES Cryptographic operation 22 Hierarchical to: No other components. 23 Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 24 FDP_ITC.2 Import of user data with security attributes, or 25 FCS_CKM.1 Cryptographic key generation, or 26 FCS_CKM.5 Cryptographic key derivation] 27 FCS_CKM.6 Timing and event of cryptographic key destruction 28 29 FCS_COP.1.1/DES The TSF shall perform encryption and decryption in accordance with a specified 30 cryptographic algorithm Triple Data Encryption Standard (3DES) in Electronic 31 Codebook Mode (ECB) and in the Cipher Block Chaining Mode (CBC) and 32 cryptographic key sizes of 2 x 56 or 3 x 56 bit that meet the following: [N38A], 33 [N867] 34 35 36 1 In case a user deselects the EC library, the TOE provides basic HW-related routines for EC calculations. For a secure library implementation the user has to implement additional countermeasures. 41 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 7.6.2 AES Operation 1 The AES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as 2 specified below. 3 4 FCS_COP.1/AES Cryptographic operation 5 Hierarchical to: No other components. 6 Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 7 FDP_ITC.2 Import of user data with security attributes, or 8 FCS_CKM.1 Cryptographic key generation or 9 FCS_CKM.5 Cryptographic key derivation] 10 FCS_CKM.6 Timing and event of cryptographic key destruction 11 FCS_COP.1.1/AES The TSF shall perform encryption and decryption in accordance with a 12 specified cryptographic algorithm: Advanced Encryption Standard (AES) in 13 Electronic Codebook Mode (ECB) and in the Cipher Block Chaining Mode (CBC) 14 and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the 15 following: [N197], [N38A] 16 17 7.6.3 Elliptic Curve DSA (ECDSA) operation 18 The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation 19 (FCS_COP.1)” as specified below. 20 21 FCS_COP.1/ECDSA Cryptographic operation 22 Hierarchical to: No other components. 23 Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 24 FDP_ITC.2 Import of user data with security attributes, or 25 FCS_CKM.1 Cryptographic key generation or 26 FCS_CKM.5 Cryptographic key derivation] 27 FCS_CKM.6 Timing and event of cryptographic key destruction 28 FCS_COP.1.1/ECDSA The TSF shall perform signature generation in 29 accordance with a specified cryptographic algorithm ECDSA and cryptographic 30 key sizes 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard: 31 32 Signature Generation: 33 According to section 7.3 in ANSI X9.62 – 2005 34 Not implemented is step d) and e) thereof. 35 The output of step e) has to be provided as input to our function by 36 the caller. 37 Deviation of step c) and f): 38 The jumps to step a) were substituted by a return of 39 the function with an error code, the jumps are emulated by another 40 call to our function. 41 42 43 42 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case the 1 Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR is not 2 applicable. 3 Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the ECC 4 algorithms stated above. If no optional ECC library is available then this SFR is not applicable. 5 6 7.6.4 Elliptic Curve (EC) key generation 7 The key generation for the EC shall meet the requirement “Cryptographic key generation 8 (FCS_CKM.1)” 9 FCS_CKM.1/EC Cryptographic key generation 10 11 Hierarchical to: No other components. 12 Dependencies: [FCS_CKM.2 Cryptographic key distribution, or 13 FCS_CKM.5 Cryptographic key derivation, or 14 FCS_COP.1 Cryptographic operation] 15 [FCS_RBG.1 Random bit generation, or 16 FCS_RNG.1 Generation of random numbers] 17 FCS_CKM.6 Timing and event of cryptographic key destruction 18 19 FCS_CKM.1.1/EC The TSF shall generate cryptographic keys in accordance with a specified 20 cryptographic key generation algorithm Elliptic Curve EC specified in ANSI 21 X9.62-2005 and specified cryptographic key sizes 224, 233, 256, 283, 320, 384, 22 409, 512 or 521 bits that meet the following: 23 24 ECDSA Key Generation: 25 According to the appendix A4.3 in ANSI X9.62-2005 26 the cofactor h is not supported. 27 28 Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case the 29 Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR is not 30 applicable. 31 Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the ECC 32 algorithms stated above. If no optional ECC library is available then this SFR is not applicable. 33 34 7.6.5 Elliptic Curve Diffie-Hellman (ECDH) key agreement 35 The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic 36 operation(FCS_COP.1)” as specified below. 37 38 FCS_COP.1/ECDH Cryptographic operation 39 40 Hierarchical to: No other components. 41 43 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1 Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 2 FDP_ITC.2 Import of user data with security attributes, or 3 FCS_CKM.1 Cryptographic key generation, or 4 FCS_CKM.5 Cryptographic key derivation] 5 FCS_CKM.6 Timing and event of cryptographic key destruction 6 7 FCS_COP.1.1/ECDH The TSF shall perform elliptic curve Diffie-Hellman key agreement in 8 accordance with a specified cryptographic algorithm ECDH and cryptographic 9 key sizes of 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the 10 following: 11 According to section 5.4.1 in ANSI X9.63 – 2001: Unlike section 5.4.1.3 our, 12 implementation not only returns the x-coordinate of the shared secret, but 13 rather the x-coordinate and y-coordinate. 14 15 Note:The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths 16 of 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Other types of elliptic curves can be added by 17 the user during a composite certification process. 18 Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case the 19 Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR is not 20 applicable. 21 Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the ECC 22 algorithms stated above. If no optional ECC library is available then this SFR is not applicable. 23 24 7.7 Data Integrity and confidentiality 25 26 The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as 27 specified below: 28 FDP_SDI.2 Stored data integrity monitoring and action 29 30 Hierarchical to: FDP_SDI.1 stored data integrity monitoring 31 32 Dependencies: No dependencies 33 34 FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for 35 data integrity and one- and/or more-bit-errors on all objects, based on the 36 following attributes: corresponding EDC value for RAM and ROM and error 37 correction ECC for the SOLID FLASH™ NVM. 38 39 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall correct 1 bit errors in the 40 SOLID FLASH™ NVM automatically and inform the user about more bit errors. 41 42 43 The TOE shall meet the requirement “Stored data confidentiality (FDP_SDC.1)” as specified below: 44 45 FDP_SDC.1 Stored data confidentiality 46 44 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1 Hierarchical to: No other components. 2 3 Dependencies: No dependencies 4 5 FDP_SDC.1.1 The TSF shall ensure the confidentiality of all user data1 while it is stored in the 6 any memory2 . 7 8 7.8 TOE Security Assurance Requirements 9 The evaluation assurance level is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5. In the following 10 table, the security assurance requirements are given. The augmentation of the assurance 11 components compared to the Protection Profile [PP] is expressed with bold letters. 12 Table 19 Assurance components 13 Aspect Acronym Description Refinement Development ADV_ARC.1 Security Architecture Description in PP [PP] ADV_FSP.5 Complete semiformal functional specification with additional error information in ST ADV_IMP.1 Implementation representation of the TSF in PP [PP] ADV_INT.2 Well-structured internals in ST ADV_TDS.4 Semi-formal modular design in ST Guidance Documents AGD_OPE.1 Operational user guidance in PP [PP] AGD_PRE.1 Preparative procedures in PP [PP] Life-Cycle Support ALC_CMC.4 Production support, acceptance procedures and automation in PP [PP] ALC_CMS.5 Development tools CM coverage in ST ALC_DEL.1 Delivery procedures in PP [PP] ALC_DVS.2 Sufficiency of security controls in PP [PP] ALC_LCD.1 Developer defined life-cycle process in PP [PP] ALC_TAT.2 Compliance with implementation standards in ST Security Target Evaluation ASE_CCL.1 Conformance claims in PP [PP] ASE_ECD.1 Extended components definition in PP [PP] ASE_INT.1 ST introduction in PP [PP] 1[selection: all user data, the following user data [assignment: list of user data]] 2 [selection: temporary memory, persistent memory, any memory] 45 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public ASE_OBJ.2 Security objectives in PP [PP] ASE_REQ.2 Derived security requirements in PP [PP] ASE_SPD.1 Security problem definition in PP [PP] ASE_TSS.1 TOE summary specification in PP [PP] Tests ATE_COV.2 Analysis of coverage in PP [PP] ATE_DPT.3 Testing: modular design in ST ATE_FUN.1 Functional testing in PP [PP] ATE_IND.2 Independent testing - sample in PP [PP] Vulnerability Assessment AVA_VAN.5 Advanced methodical vulnerability analysis in PP [PP] 7.8.1 Refinements 1 Some refinements are taken unchanged from the PP [PP]. In some cases a clarification is necessary. In 2 Table 19 an overview is given where the refinement is done. 3 Refinements from the PP [PP] have to be discussed here in the Security Target, as the assurance level is 4 increased. 5 Life cycle support (ALC_CMS, ALC_TAT) 6 The refinement from the PP [PP] can be applied even at the chosen assurance level EAL 5 augmented 7 with ALC_CMS.5 and ALC_TAT.2. The assurance package ALC_CMS.4 is extended to ALC_CMS.5 with 8 aspects regarding the configuration control system for the TOE. The assurance package ALC_TAT.1 is 9 extended to ALC_TAT.2 with aspects regarding the implementation standards for the TOE. 10 Development (ADV_FSP) 11 The refinement from the PP [PP] can be applied even at the chosen assurance level EAL 5 augmented 12 with ADV_FSP.5, ADV_TDS.4 and ADV_INT.2. 13 For details of the refinement see PP [PP]. 14 Tests (ATE_DPT.3) 15 The refinement from the PP [PP] can be applied even at the chosen assurance level EAL 5 augmented 16 with ATE_DPT.3. The assurance package ATE_DPT.2 is augmented to ATE_DPT.3 relating to the 17 requirements of the assurance level EAL 5. The refinement is not touched. 18 19 7.9 Security Requirements Rationale 20 7.9.1 Rationale for the Security Functional Requirements 21 The security functional requirements rationale of the TOE are defined and described in PP [PP] section 22 6.3 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, 23 FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1 and FAU_SAS.1. 24 46 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, 1 FMT_SMF.1, FCS_COP.1, FCS_CKM.1and FDP_SDI.2 are defined in the following description: 2 3 Table 20 Rational for additional SFR in the ST 4 Objective TOE Security Functional Requirements O.Add-Functions FCS_COP.1/DES FCS_COP.1/AES FCS_COP.1/ECDSA (optional) FCS_COP.1/ECDH (optional) FCS_CKM.1/EC (optional) O.Phys-Manipulation FPT_TST.2 O.Mem-Access FDP_ACC.1 FDP_ACF.1 FMT_MSA.3 FMT_MSA.1 FMT_SMF.1 5 The table above gives an overview, how the security functional requirements are combined to meet the 6 security objectives. The detailed justification is given in the following: 7 The justification related to the security objective “Additional Specific Security Functionality 8 (O.Add-Functions)” is as follows: 9 The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly requires those 10 functions to be implemented which are demanded by O.Add-Functions. FCS_CKM.1/EC supports the 11 generation of EC keys needed for these cryptographic operations. Therefore, FCS_COP.1/ECDSA, 12 FCS_COP.1/ECDH and FCS_CKM/EC are suitable to meet the security objective. The use of the 13 supporting Base library has no impact on any security functional requirement nor does its use generate 14 additional requirements. 15 The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys- 16 Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement the 17 specific security functionality. However, key-dependent functions could be implemented in the 18 Smartcard Embedded Software. 19 The usage of cryptographic algorithms requires the use of appropriate keys. Otherwise, these 20 cryptographic functions do not provide security. The keys have to be unique with a very high 21 probability, and must have a certain cryptographic strength etc. In case of a key import into the TOE 22 (which is usually after TOE delivery) it has to be ensured that quality and confidentiality are maintained. 23 Keys for 3DES and AES are provided by the environment, the keys for EC algorithms can be provided 24 either by the TOE or the environment. 25 The security functional component Subset TOE security testing (FPT_TST.2) has been newly created 26 (Common Criteria Part 2 extended). This component allows that particular parts of the security 27 mechanisms and functions provided by the TOE can be tested after TOE Delivery. This security 28 functional component is used instead of the functional component FPT_TST.1 from Common Criteria 29 Part 2. For the user it is important to know which security functions or mechanisms can be tested. The 30 functional component FPT_TST.1 does not mandate to explicitly specify the security functions being 31 tested. In addition, FPT_TST.1 requires verification of the integrity of TSF data and stored TSF 32 executable code which might violate the security policy. 33 47 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The tested security enforcing functions are SF_DPM Device Phase Management and SF_PMA 1 Protection against modifying attacks. 2 The security functional requirement FPT_TST.2 will detect attempts to conduce a physical 3 manipulation on the monitoring functions of the TOE. The objective of FPT_TST.2 is O.Phys- 4 Manipulation. The physical manipulation will be tried to overcome security enforcing functions. 5 The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security 6 Function Policy (SFP) “Memory Access Control Policy” exactly require the implementation of an area 7 based memory access control as required by O.Mem-Access. The related TOE security functional 8 requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1 and FMT_SMF.1 cover this security 9 objective. The implementation of these functional requirements is represented by the dedicated 10 privilege level concept. 11 The justification of the security objective and the additional requirements show that they do not 12 contradict to the rationale already given in the Protection Profile for the assumptions, policy and 13 threats defined there. Moreover, these additional security functional requirements cover the 14 requirements by [CC-2] user data protection of chapter 11 which are not refined by the PP [PP]. 15 Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional 16 functions are used as specified and that the User Data processed by these functions are protected as 17 defined for the application context. The TOE only provides the tool to implement the policy defined in 18 the context of the application. 19 20 7.9.1.1 Dependencies of Security Functional Requirements 21 The dependencies of security functional requirements are defined and described in PP [PP] section 22 6.3.2 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3, 23 FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1, FDP_SDC.1, FDP_SDI.2 and FAU_SAS.1. 24 The dependence of security functional requirements for the security functional requirements 25 FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1 26 are defined in the following description. 27 28 Table 21 Dependency 29 Security Functional Requirement Dependencies Fulfilled by security requirements FCS_COP.1/DES FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5 See comment FCS_CKM.6 See comment FCS_COP.1/AES FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5 See comment FCS_CKM.6 See comment FCS_COP.1/ECDSA FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5 FCS_CKM.1/EC FCS_CKM.6 See comment 48 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 1 Comment: 2 The security functional requirement “Cryptographic operation (FCS_COP.1)” met by the TOE, has the 3 following dependencies: 4  FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5 5  FCS_CKM.6 6 The security functional requirement “Cryptographic key management (FCS_CKM.1)” met by TOE, has 7 the following dependencies: 8  FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1 9  FCS_RBG.1 or FCS_RNG.1 10  FCS_CKM.6 11 These requirements all address the appropriate management of cryptographic keys used by the 12 specified cryptographic function and are not part of the PP [PP]. Most requirements concerning key 13 management shall be fulfilled by the environment since the Smartcard Embedded Software is designed 14 for a specific application context and uses the cryptographic functions provided by the TOE. 15 The TOE does not provide functions to generate or destroy AES and TDES keys. Therefore, for the 16 security functional requirement FCS_COP.1/DES, FCS_COP.1/AES, the respective dependencies 17 FCS_CKM.6 and FCS_CKM.1, FCS_CKM.5 or FDP_ITC.1 or FDP_ITC.2 have to be fulfilled by the 18 environment. 19 The TOE does provide functions to generate EC keys. However, the storage of the keys is the 20 responsibility of the embedded software and there is no API function for key destruction. Therefore, for 21 the security functional requirement FCS_COP.1/ECDSA, and FCS_COP.1/ECDH, the respective 22 dependency FCS_CKM.6 has to be fulfilled by the environment. 23 FCS_CKM.1/EC FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1 FCS_COP.1/ECDH FCS_COP.1/ECDSA FCS_RBG.1 or FCS_RNG.1 FCS_RNG.1 FCS_CKM.6 See comment FCS_COP.1/ECDH FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5 FCS_CKM.1/EC FCS_CKM.6 See comment FPT_TST.2 None See comment FDP_ACC.1 FDP_ACF.1 Yes FDP_ACF.1 FDP_ACC.1 FMT_MSA.3 Yes Yes FMT_MSA.3 FMT_MSA.1 FMT_SMR.1 Yes Not required, see comment FMT_MSA.1 FDP_ACC.1 or FDP_IFC.1 FMT_SMR.1 FMT_SMF.1 Yes See comment Yes FMT_SMF.1 None N/A 49 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is 1 considered to be satisfied because the access control specified for the intended TOE is not role-based 2 but enforced for each subject. Therefore, there is no need to identify roles in form of a security 3 functional requirement FMT_SMR.1. 4 End of comment. 5 6 7.9.2 Rationale of the Assurance Requirements 7 The chosen assurance level EAL5 and the augmentation with the requirements ALC_DVS.2 and 8 AVA_VAN.5 were chosen in order to meet the assurance expectations explained in the following 9 paragraphs. In Table 19 the different assurance levels are shown as well as the augmentations. The 10 augmentations are in compliance with the Protection Profile. 11 An assurance level EAL5 with the augmentations ALC_DVS.2 and AVA_VAN.5 are required for this type 12 of TOE since it is intended to defend against highly sophisticated attacks without protective 13 environment. This evaluation assurance package was selected to permit a developer to gain maximum 14 assurance from positive security engineering based on good commercial practices. In order to provide a 15 meaningful level of assurance that the TOE provides an adequate level of defence against such attacks, 16 the evaluators should have access to all information regarding the TOE including the TSF internals, the 17 low level design and source code including the testing of the modular design. Additionally the 18 mandatory technical document “Application of Attack Potential to Smartcards” [JIL] shall be taken as a 19 basis for the vulnerability analysis of the TOE. 20 21 ALC_DVS.2 Sufficiency of security measures 22 Development security is concerned with physical, procedural, personnel and other technical measures 23 that may be used in the development environment to protect the TOE. 24 In the particular case of a Security IC the TOE is developed and produced within a complex and 25 distributed industrial process which must especially be protected. Details about the implementation, 26 (e.g. from design, test and development tools as well as Initialization Data) may make such attacks 27 easier. Therefore, in the case of a Security IC, maintaining the confidentiality of the design is very 28 important. 29 This assurance component is a higher hierarchical component to EAL5 (which only requires 30 ALC_DVS.1). ALC_DVS.2 has no dependencies. 31 32 AVA_VAN.5 Advanced methodical vulnerability analysis 33 Due to the intended use of the TOE, it must be shown to be highly resistant to penetration attacks. This 34 assurance requirement is achieved by the AVA_VAN.5 component. 35 Independent vulnerability analysis is based on highly detailed technical information. The main intent of 36 the evaluator analysis is to determine that the TOE is resistant to penetration attacks performed by an 37 attacker possessing high attack potential. 38 AVA_VAN.5 has dependencies to ADV_ARC.1 “Security architecture description”, ADV_FSP.4 39 “Complete functional specification”, ADV_TDS.3 “Basic modular design”, ADV_IMP.1 “Implementation 40 representation of the TSF”, AGD_OPE.1 “Operational user guidance”, and ATE_DPT.1 “Testing: basic 41 design. 42 50 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public All these dependencies are satisfied by EAL5. 1 It has to be assumed that attackers with high attack potential try to attack Security ICs like smart cards 2 used for digital signature applications or payment systems. Therefore, specifically AVA_VAN.5 was 3 chosen in order to assure that even these attackers cannot successfully attack the TOE. 4 5 51 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 8 TOE Summary Specification (ASE_TSS) 1 The product overview is given in section 2.1. In the following the Security Features are described and 2 the relation to the security functional requirements is shown. 3 The TOE is equipped with the following Security Features to meet the security functional requirements: 4  SF_DPM Device Phase Management 5  SF_PS Protection against Snooping 6  SF_PMA Protection against Modification Attacks 7  SF_PLA Protection against Logical Attacks 8  SF_CS Cryptographic Support 9 10 Application Note 14 in PP requires to define the secure states of the TOE. 11 In the case of a security alarm with security reset, the system starts to execute the BOS. There is no 12 waiting until a power-down or CB reset takes place. In ISO Only mode the BOS stops running and 13 requires an externally-triggered reset. In Multi-Interface mode the BOS continues execution and hands 14 over to the runtime system. 15 The following description of the Security Features is a complete representation of the TSF. 16 8.1 SF_DPM: Device Phase Management 17 The life cycle of the TOE is split-up in several phases. Chip development and production (phase 2, 3, 4) 18 and final use (phase 4-7) is a rough split-up from TOE point of view. These phases are implemented in 19 the TOE as test mode (phase 3) and user mode (phase 4-7). 20 In addition, a chip identification mode exists which is active in all phases. The chip identification data 21 (O.Identification) is stored in a in the not changeable configuration page area and non-volatile memory. 22 In the same area further TOE configuration data is stored. In addition, user initialization data can be 23 stored in the non-volatile memory during the production phase as well. During this first data 24 programming, the TOE is still in the secure environment and in Test Mode. 25 The covered security functional requirement is FAU_SAS.1 “Audit storage”. 26 During start-up of the TOE the decision for one of the operation modes is taken dependent on phase 27 identifiers. The decision of accessing a certain mode is defined as phase entry protection. The phases 28 follow also a defined and protected sequence. The sequence of the phases is protected by means of 29 authentication. 30 The covered security functional requirements are FMT_LIM.1 “Limited capabilities” and FMT_LIM.2 31 “Limited availability”. 32 During the production phase (phase 3 and 4) or after the delivery to the customer (phase 5 or phase 6), 33 the TOE provides the possibility to download a user specific encryption key and user code and data into 34 the empty (erased) SOLID FLASH™ NVM memory area as specified by the associated control 35 information of the Flash Loader software. After finishing the load operation, the Flash Loader can be 36 permanently deactivated, so that no further load operation with the Flash Loader is possible. These 37 procedures are defined as phase operation limitation. 38 The covered security functional requirement is FMT_LIM.2 “Limited availability”. 39 During operation within a phase the accesses to memories are granted by the MPU controlled access 40 rights and related levels. 41 The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1 42 “Security attribute-based access control” and FMT_MSA.1 “Management of security attributes”. 43 52 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public In addition, during each start-up of the TOE the address ranges and access rights are initialized by the 1 Boot Software (BOS) with predefined values. 2 The covered security functional requirement is FMT_MSA.3 “Static attribute initialisation”. 3 The TOE clearly defines access rights and levels in conjunction with the appropriate key management 4 in dependency of the firmware or software to be executed. 5 The covered security functional requirement is FMT_SMF.1 “Specification of Management functions”. 6 Each operation phase is protected by means of authentication and encryption. 7 The covered security functional requirements are FPT_ITT.1 “Basic internal TSF data transfer 8 protection” and FDP_IFC.1 “Subset information flow control”. If any comparison of the authentication 9 code fails a direct security reset is performed. The covered security functional requirements is 10 FPT_FLS.1 (”Failure with preservation of secure state”). 11 The SF_DPM “Device Phase Management” covers the security functional requirements FPT_FLS.1, 12 FAU_SAS.1, FMT_LIM.1, FMT_LIM.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, 13 FPT_ITT.1 and FDP_IFC.1. 14 15 8.2 SF_PS: Protection against Snooping 16 Several mechanisms protect the TOE against snooping the design or the user data during operation 17 and even if it is out of operation (power down). 18 The entire design is kept in a non standard way to prevent attacks using standard analysis methods. 19 Important parts of the chip are especially designed to counter leakage or side channel attacks like 20 DPA/SPA or EMA/DEMA. Therefore, even the physical data gaining is difficult to perform, since timing 21 and current consumption is independent of the processed data. In the design a number of components 22 are automatically synthesized and mixed up to disguise an attacker and to make an analysis more 23 difficult. 24 The covered security functional requirement is FPT_PHP.3 “Resistance to physical attack”. 25 A further protective design method used is secure wiring. All security critical wires have been identified 26 and protected by special routing measures against probing. Additionally the wires are embedded into 27 shield lines and used as normal signal lines for operation of the chip to prevent successful probing. This 28 measurement is called “security optimized wiring”. 29 The covered security functional requirements are FPT_PHP.3 “Resistance to physical attack”, FPT_ITT.1 30 “Basic internal TSF data transfer protection”, FPT_FLS.1 “Failure with preservation of secure state” and 31 FDP_ITT.1 “Basic internal transfer protection”. 32 53 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public All contents of the memories RAM, ROM and SOLID FLASH™ NVM of the TOE are encrypted on chip 1 to protect them against data analysis. In addition the data transferred over the memory bus to and 2 from (bi-directional encryption) the CPU, Co-processor (Crypto2304T and SCP), the special SFRs and 3 the peripheral devices (RNG and Timer) are transported encrypted with an automatically dynamic key 4 change. 5 The encryption of the memory content is done by the MED using a proprietary cryptographic algorithm 6 and a complex key management providing protection against cryptographic analysis attacks. This 7 means that the SOLID FLASH™ NVM, RAM, ROM and the bus are encrypted with module dedicated 8 and dynamic keys. The only key remaining static over the product life cycle is the specific ROM key 9 changing from mask to mask. 10 All security relevant transfer of addresses or data via the peripheral bus is dynamically masked and thus 11 protected against readout and analysis. 12 The function Trash Register Writes can be activated by the user to hide the fact if a register has been 13 written. 14 The covered security functional requirements are FDP_IFC.1 “Subset information flow control“, 15 FPT_PHP.3 “Resistance to physical attack”, FPT_ITT.1 “Basic internal TSF data transfer protection, 16 FPT_FLS.1 “Failure with preservation of secure state” and FDP_ITT.1 “Basic internal transfer 17 protection”, FDP_SDC.1 “Stored data confidentiality”. 18 19 The SF_PS “Protection against Snooping” covers the security functional requirements FPT_PHP.3, 20 FDP_IFC.1, FPT_ITT.1, FPT_FLS.1 and FDP_ITT.1. 21 8.3 SF_PMA: Protection against ModifyingAttacks 22 The TOE is equipped with an error detection code (EDC) for protecting RAM and ROM and an ECC, 23 which is realized in the SOLID FLASH™ NVM. Thus introduced failures are securely detected and, in 24 terms of single bit errors in the SOLID FLASH™ NVM also automatically corrected (FDP_SDI.2). For 25 SOLID FLASH™ NVM in case of more than one bit errors and for RAM in case of any bit errors detected, 26 a security alarm is triggered. 27 In order to prevent accidental bit faults during production in the ROM, over the data stored in ROM an 28 EDC value is calculated (FDP_SDI.2). 29 The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance“, FDP_PHP.3 30 “Resistance to physical attack“, FDP_SDI.2 “Stored data integrity monitoring” and FDP_SDI.2 “Stored 31 data integrity monitoring and action”. 32 If a user tears the card resulting in a power off situation during an SOLID FLASH™ NVM programming 33 operation or if other perturbation is applied, no data or content loss occurs and the TOE restarts power 34 on. The NVM tearing save write functionality covers FDP_SDI.2 “Stored data integrity monitoring” as 35 the new data to be programmed are checked for integrity and correct programming before the page 36 with the old data becomes valid. 37 38 The covered security functional requirement are FPT_PHP.3 “Resistance to physical attack“, since these 39 measures make it difficult to manipulate the write process of the NVM, FPT_FLS.1 “Failure with 40 preservation of secure state“and FDP_SDI.2 “Stored data integrity monitoring and action”. 41 In the case that a physical manipulation or a physical probing attack is detected, the processing of the 42 TOE is immediately stopped and the TOE enters a secure state called security reset. 43 54 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public A shielding algorithm finishes the upper layers above security critical signals and wires, finally providing 1 the so called “security optimized wiring”. 2 3 The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure state”, 4 FPT_PHP.3 “Resistance to physical attack” and FPT_TST.2 “Subset TOE security testing“. 5 As physical effects or manipulative attacks may also address the program flow of the user software, 6 two watchdog timers each with a check point register function are implemented. This feature allows 7 the user to check the correct processing time and the integrity of the program flow of the user 8 software. 9 The Instruction Stream Signature Checking (ISS) calculates a hash about all executed instructions and 10 automatically checks the correctness of this hash value. If the code execution follows an illegal path an 11 alarm is triggered. 12 Another measure against modifying and perturbation respectively differential fault attacks (DFA) is the 13 implementation of backward calculation in the SCP. By this induced errors are discovered. 14 The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure state”, 15 FDP_IFC.1 “Subset information flow control”, FPT_ITT.1 “Basic internal transfer protection”, FDP_ITT.1 16 “Basic internal transfer protection” and FPT_PHP.3 “Resistance to physical attack”. 17 During start up, the TOE performs various configurations and subsystem tests. After the TOE startup 18 has finished, the operating system or application can call the User Mode Security Life Control (UMSLC) 19 test provided by the Resource Management System. The UMSLC checks the alarm lines and/or the 20 different security functions and sensors for correct operation. The test can be triggered by user 21 software during normal operation. As attempts to modify the security features will be detected from 22 the test, the covered security functional requirement is FPT_TST.2 “Subset TOE security testing“. 23 The correct function of the TOE is only given in the specified range of the environmental operating 24 parameters. To prevent an attack exploiting that circumstance the TOE is equipped with a temperature 25 sensor, glitch sensor and backside light detection. The TOE falls into the defined secure state in case of 26 a specified range violation. The defined secure state causes the chip internal reset process. Note that 27 the specified range checking can only work when the TOE is running and can not prevent reverse 28 engineering. 29 The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance” and FPT_FLS.1 30 “Failure with preservation of secure state“. 31 The SF_PMA “Protection against Modifying Attacks” covers the security functional requirements 32 FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1, FPT_TST.2, FDP_SDI.2, FRU_FLT.2 and FPT_FLS.1. 33 34 8.4 SF_PLA: Protection against Logical Attacks 35 The memory model of the TOE provides two distinct, independent levels called the privileged and non- 36 privilege level and the possibility to define up to eight memory regions with different access rights 37 enforced by the Management Protection Unit (MPU). This gives the user software the possibility to 38 define different access rights for the regions 0 to 7 for privilege or non-privilege level. In the case of an 39 access violation the MPU will trigger a trap. The policy of setting up the MPU and specifying the 40 memory ranges for the regions (0 to 7) is defined from the user software. 41 The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1 42 “Security attribute based access control”, FMT_MSA.1 “Management of security attributes”, 43 FMT_MSA.3 “Static attribute initialisation” and FMT_SMF.1 “Specification of Management functions”. 44 55 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public All memories present on the TOE (NVM, ROM, RAM) are encrypted using individual keys assigned by 1 complex key management. In case of security critical error a security alarm is generated and the TOE 2 ends up in a secure state. 3 The covered security functional requirements are FDP_ACF.1 “Security attribute based access control” 4 and FPT_FLS.1 “Failure with preservation of secure state”. 5 The SF_PLA “Protection against Logical Attacks” covers the security functional requirements 6 FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FPT_FLS.1 and FMT_SMF.1. 7 8 8.5 SF_CS: Cryptographic Support 9 The TOE is equipped an asymmetric and a symmetric hardware accelerators to support the standard 10 symmetric and asymmetric cryptographic operations. This security function is introduced to include the 11 cryptographic operation in the scope of the evaluation as the cryptographic function respectively 12 mathematic algorithm itself is not used from the TOE security policy. The components are a co- 13 processor supporting the DES and AES algorithms and a co-processor and software modules to support 14 EC signature generation, ECDH key agreement and EC public key calculation and testing. Additionally 15 the TOE is equipped with a True Random Number Generator for the generation of random numbers. 16 8.5.1 3DES encryption 17 The TOE supports the encryption and decryption in accordance with the specified cryptographic 18 algorithm Triple Data Encryption Standard (3DES) in the Electronic Codebook Mode (ECB), Cipher 19 Block Chaining Mode (CBC) and with cryptographic key sizes of 112 and 168 bit meeting the standard: 20 [N867], [N38A]. 21 The covered security functional requirements are FCS_COP.1/DES. 22 23 8.5.2 AES encryption 24 The TSF supports the encryption and decryption in accordance with the specified cryptographic 25 algorithm Advanced Encryption Standard (AES) ) in the Electronic Codebook Mode (ECB), Cipher Block 26 Chaining Mode (CBC) and cryptographic key sizes of 128 bit or 192 bit or 256 bit according to the 27 standard: [N197], [N38A]. 28 The covered security functional requirement is FCS_COP.1/AES. 29 8.5.1 Elliptic Curves 30 The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of 31 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there exist numerous other curve types, 32 being also secure in terms of side channel attacks on this TOE, which can the user optionally add in the 33 composition certification process. 34 35 8.5.1.1 Signature Generation 36 The TSF shall perform signature generation in accordance with a specified cryptographic algorithm 37 ECDSA and cryptographic key sizes 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the 38 following standard: 39 40 56 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public  According to section 7.3 in ANSI X9.62 – 2005: 1  Not implemented is step d) and e) thereof. 2  The output of step e) has to be provided as input to our function by the caller. 3  Deviation of step c) and f): 4 The jumps to step a) were substituted by a return of the function with an error code, the jumps 5 are emulated by another call to our function. 6 7 The covered security functional requirement is FCS_COP.1/ECDSA. 8 8.5.1.2 Asymmetric Key Generation 9 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation 10 algorithm Elliptic Curve EC specified in ANSI X9.62-1998 and specified cryptographic key sizes 224, 233, 11 256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard: 12 13 ECDSA Key Generation: 14  According to the appendix A4.3 in ANSI X9.62-2005 the cofactor h is not supported. 15 16 The covered security functional requirement is FCS_CKM.1/EC. 17 8.5.1.3 Asymmetric Key Agreement 18 The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance with a specified 19 cryptographic algorithm ECDH and cryptographic key sizes 224, 233, 256, 283, 320, 384, 409, 512 or 521 20 bits that meet the following standard: 21  According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our implementation not only 22 returns the x-coordinate of the shared secret, but rather the x-coordinate and y-coordinate. 23 The covered security functional requirement is FCS_COP.1/ECDH. 24 8.5.2 Asymmetric Base Library 25 The asymmetric Base library provides the low-level interface to the asymmetric cryptographic 26 coprocessor and API functions for data share handling. 27 28 8.5.3 TRNG 29 Random data is essential for cryptography as well as for security mechanisms. The TOE is equipped 30 with a physical True Random Number Generator (TRNG, FCS_RNG.1). The random data can be used 31 from the Smartcard Embedded Software and is also used from the security features of the TOE, like 32 masking. The TRNG implements also self testing features. The TRNG fulfils the requirements from the 33 functionality class PTG.2 of [6]. 34 The covered security functional requirement is FCS_RNG.1 “Quality metric for random numbers”, 35 FPT_PHP.3 “Resistance to physical attack”, FDP_ITT.1 “Basic internal transfer protection”, FPT_ITT.1 36 “Basic internal TSF data transfer protection, FDP_IFC.1 “Subset information flow control“, FPT_TST.2 37 “Subset TOE security testing“ and FPT_FLS.1“Failure with preservation of secure state”. 38 39 57 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public The SF_CS “Cryptographic Support” covers the security functional requirements FCS_COP.1/DES, 1 FCS_COP.1/AES, FCS_COP.1/ECDSA, FCS_COP.1/ECDH, FCS_CKM.1/EC, FPT_PHP.3, FDP_ITT.1, 2 FPT_ITT.1, FPT_FLS.1 ,FCS_RNG.1 and FDP_IFC.1. 3 8.6 Assignment of Security Functional Requirements toTOE’s Security 4 Functionality 5 The justification and overview of the mapping between security functional requirements (SFR) and the 6 TOE’s security functionality (SF) is given in sections the sections above. The results are shown in Table 7 22. The security functional requirements are addressed by at least one relating security feature. 8 The various functional requirements are often covered manifold. As described above the requirements 9 ensure that the TOE is checked for correct operating conditions and if a not correctable failure occurs 10 that a stored secure state is achieved, accompanied by data integrity monitoring and actions to 11 maintain the integrity although failures occurred. An overview is given in following table: 12 Table 22 Mapping of SFR and SF 13 SFR SF_DPM SF_PS SF_PMA SF_PLA SF_CS FAU_SAS.1 X FMT_LIM.1 X FMT_LIM.2 X FDP_ACC.1 X X FDP_ACF.1 X X FPT_PHP.3 X X X FDP_ITT.1 X X X FDP_SDI.2 X FDP_SDC.1 X FDP_IFC.1 X X X X FMT_MSA.1 X X FMT_MSA.3 X X FMT_SMF.1 X X FRU_FLT.2 X FPT_ITT.1 X X X X FPT_TST.2 X FPT_FLS.1 X X X X X FCS_RNG.1 X FCS_COP.1/DES X FCS_COP.1/AES X FCS_COP.1/ECDSA X FCS_COP.1/ECDH X FCS_CKM.1/EC X 14 15 8.7 Security Requirements are internally Consistent 16 For this chapter the PP [PP] section 6.3.4 can be applied completely. 17 58 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public In addition to the discussion in section 6.3 of PP [PP] the security functional requirement FCS_COP.1 is 1 introduced. The security functional requirements required to meet the security objectives O.Leak- 2 Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the 3 cryptographic algorithms implemented according to the security functional requirement FCS_COP.1. 4 Therefore, these security functional requirements support the secure implementation and operation of 5 FCS_COP.1. 6 As disturbing, manipulating during or forcing the results of the test checking the security functions 7 after TOE delivery, this security functional requirement FPT_TST.2 has to be protected. An attacker 8 could aim to switch off or disturb certain sensors or filters and preserve the detection of his 9 manipulation by blocking the correct operation of FPT_TST.2. The security functional requirements 10 required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys- 11 Manipulation and O.Leak-Forced also protect the security functional requirement FPT_TST.2. 12 Therefore, the related security functional requirements support the secure implementation and 13 operation of FPT_TST.2. 14 The requirement FPT_TST.2 allows testing of some security mechanisms by the Smartcard Embedded 15 Software after delivery. In addition, the TOE provides an automated continuous user transparent 16 testing of certain functions. 17 The implemented level concept represents the area based memory access protection enforced by the 18 MPU. As an attacker could attempt to manipulate the privilege level definition as defined and present 19 in the TOE, the functional requirement FDP_ACC.1 and the related other requirements have to be 20 protected themselves. The security functional requirements required to meet the security objectives 21 O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also 22 protect the area based memory access control function implemented according to the security 23 functional requirement described in the security functional requirement FDP_ACC.1 with reference to 24 the Memory Access Control Policy and details given in FDP_ACF.1. Therefore, those security functional 25 requirements support the secure implementation and operation of FDP_ACF.1 with its dependent 26 security functional requirements. 27 59 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 9 References 1 [PP] BSI-CC-PP-0084-2014, Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 2014-01-13 [CC-1] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model; CC:2022 Revision 1, November 2022, CCMB-2022-11-001 [CC-2] Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Requirements; CC:2022 Revision 1, November 2022, CCMB-2022-11-002 [CC-3] Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Requirements; CC:2022 Revision 1, November 2022, CCMB-2022-11-003 [CC-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, CCMB-2022-11-004 [CC-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 [ARM] ARMv7-M Architecture Reference Manual, ARM DDI ARM DDI 0403E.e N (ID021621), ARM Limited, 2021 [RNG] A proposal for: Functionality classes for random number generators, Version 2.0, 18. September 2011 [HRM] SLE97 M9900 Hardware Reference Manual, Revision 3.0, 2019-08-28 [JIL] APPLICATION OF ATTACK POTENTIAL TO SMARTCARDS AND SIMILAR DEVICES Version 1.2, August 2023, European Union Agency for Cybersecurity [AIS31] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS31, Version 4, 2025- 04-11, Bundesamt für Sicherheit in der Informationstechnik [DSS] Federal Information Processing Standards Publication FIPS PUB 186-5, Digital Signature Standard (DSS), 2023-02-03 [ECC] IETF: RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010, http://www.ietf.org/rfc/rfc5639.txt [N867] NIST Special Publication 800-67 – Revision 2 – Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, rev. 2, 2017-11 [N197] U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197 [N38A] National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of Data Encryption Standard, NIST Special Publication 800-38A, Edition 2001 [X962] American National Standard for Financial Services ANS 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 [X963] Financial Services X9.63-2011, Public Key Cryptography for the Financial Services Industry - Key Agreement and Key Transport Using Elliptic Curve Cryptography, 2011-12-21 60 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 10 Hash values 1 In the following tables, the hash signatures of the respective CL97 Crypto Library files are documented. 2 For convenience purposes several hash values are referenced. 3 4 5 Library Hash ACL v2.07.003 Cl97-LIB-base.lib: SHA256=02009f6c7b84b6e3d148dfa761143052720361c14babccc265aa8ce5a22a947a Cl97-LIB-ecc.lib: SHA256=8f72c8ebdad3c99c59e9d115b284e6245122bb9ab38bd93da247c282c1526383 ACL v2.09.002 ACL97-Crypto2304T-L90-base.lib: SHA256=1b93e84247402e585683564ba42859e5f386e9fc4758300946797832300f95cd ACL97-Crypto2304T-L90-ecc.lib: SHA256=6354bada8cd0f395bf212bd56ade39675653a8c2d409673d377da5c150abc134 NRG NRGManagement-01.03.0927-M9900.lib SHA256=95f2ed5f6a3001146c9fef36c539ac2844839af0bacb92e44a2da474e6d5aa8e NRGReader-01.02.0800-M9900.lib SHA256=16848631a68b3094e29790ee34bbb95af208a9985c8e111f46849fffc4ef3385 6 61 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 11 List of Abbreviations 1 2 AES Advanced Encryption Standard 3 AIS31 “Anwendungshinweise und Interpretationen zu ITSEC und CC 4 Funktionalitätsklassen und Evaluationsmethodologie für physikalische 5 Zufallszahlengeneratoren” 6 API Application Programming Interface 7 BOS Boot Software 8 CC Common Criteria 9 CPU Central Processing Unit 10 CRC Cyclic Redundancy Check 11 Crypto2304T Asymmetric Cryptographic Processor 12 CRT Chinese Reminder Theorem 13 DPA Differential Power Analysis 14 DFA Differential Failure Analysis 15 EC Elliptic Curve 16 ECC Error Correction Code 17 EDC Error Detection Code 18 EDU Error Detection Unit 19 GCIM Generic Chip Identification Mode (BOS-CIM) 20 EEPROM Electrically Erasable and Programmable Read Only Memory 21 EMA Electro magnetic analysis 22 HW Hardware 23 IC Integrated Circuit 24 ID Identification 25 IMM Interface Management Module 26 I/O Input/Output 27 MED Memory Encryption and Decryption 28 MPU Memory Protection Unit 29 NRG ISO/IEC14443-3 Type A with CRYPTO1 30 O Objective 31 OS Operating system 32 RAM Random Access Memory 33 RMS Resource Management System 34 RNG Random Number Generator 35 ROM Read Only Memory 36 RSA Rives-Shamir-Adleman Algorithm 37 SCL Symmetric Crypto Library 38 SCP Symmetric Cryptographic Processor 39 62 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public SF Security Feature 1 SFR Special Function Register, as well as Security Functional Requirement 2 SPA Simple power analysis 3 SW Software 4 T Threat 5 TM Test Mode (BOS) 6 TOE Target of Evaluation 7 TRNG True Random Number Generator 8 TSF TOE Security Functionality 9 UART Universal Asynchronous Receiver/Transmitter 10 UM User Mode (BOS) 11 UMSLC User Mode Security Life Control 12 3DES Triple DES Encryption Standard 13 63 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public 12 Glossary 1 2 Boot System Part of the firmware with routines for controlling the operating 3 state and testing the TOE hardware 4 Central Processing Unit Logic circuitry for digital information processing 5 Chip Integrated Circuit] 6 Chip Identification Mode data Data stored in the SOLID FLASH™ NVM containing the chip 7 type, lot number (including the production site), die position on 8 wafer and production week and data stored in the ROM 9 containing the BOS version number 10 Chip Identification Mode Operational status phase of the TOE, in which actions for 11 identifying the individual chip by transmitting the Chip 12 Identification Mode data take place 13 Controller IC with integrated memory, CPU and peripheral devices 14 Crypto2304T Cryptographic coprocessor for asymmetric cryptographic 15 operations 16 Cyclic Redundancy Check Process for calculating checksums for error detection 17 Electrically Erasable and Programmable Read Only Memory (SOLID FLASH™ NVM) 18 Non-volatile memory permitting electrical read and write 19 operations 20 Firmware Part of the software implemented as hardware 21 Hardware Physically present part of a functional system (item) 22 Integrated Circuit Component comprising several electronic circuits 23 implemented in a highly miniaturized device using 24 semiconductor technology 25 Memory Encryption and Decryption 26 Method of encoding/decoding data transfer between CPU and 27 memory 28 Memory Hardware part containing digital information (binary data) 29 Microprocessor CPU with peripherals 30 Non-privilege level Restricted (non Supervisor) mode of the CPU 31 Object Physical or non-physical part of a system which contains 32 information and is acted upon by subjects 33 Operating System Software which implements the basic TOE actions necessary 34 for operation 35 Privilege level Supervisor mode of the CPU 36 Programmable Read Only Memory 37 Non-volatile memory which can be written once and then only 38 permits read operations 39 Random Access Memory Volatile memory which permits write and read operations 40 Random Number Generator Hardware part for generating random numbers 41 64 7.1 2026-01-20 Security Target Lite M9900/M9905/M9906 with optional ACL Software Libraries public Read Only Memory Non-volatile memory which permits read operations only 1 Resource Management System Part of the firmware containing SOLID FLASH™ NVM 2 programming routines, AIS31 testbench etc. 3 Security Mechanism Logic or algorithm which implements a specific security 4 function in hardware or software 5 SCP Symmetric cryptographic coprocessor for symmetric 6 cryptographic operations (3DES, AES). 7 Security Function Part(s) of the TOE used to implement part(s) of the security 8 objectives 9 Security Target Description of the intended state for countering threats 10 Smart Card Plastic card in credit card format with built-in chip 11 Software Information (non-physical part of the system) which is required 12 to implement functionality in conjunction with the hardware 13 (program code) 14 Subject Entity, generally in the form of a person, who performs actions 15 Target of Evaluation Product or system which is being subjected to an evaluation 16 Test Mode Operational status phase of the TOE in which actions to test 17 the TOE hardware take place 18 Threat Action or event that might prejudice security 19 User Person in contact with a TOE who makes use of its 20 operational capability 21 User Mode Operational status phase of the TOE in which actions 22 intended for the user takes place 23 WLB Wafer Level Ballgrid Array 24 WLP Wafer Level Package 25 26 27 Revision History 28 Major changes since the last revision 29 Page or Reference Description 4.9 Version of last recertification 7.1 Final version 30 Other Trademarks All referenced product or service names and trademarks are the property of their respective owners. ifx1owners. Edition 2026-01-20 Published by Infineon Technologies AG 81726 Munich, Germany © 2026 Infineon Technologies AG. All Rights Reserved. Do you have a question about this document? Email: csscustomerservice@infineon.com IMPORTANT NOTICE The information given in this document shall in no event be regarded as a guarantee of conditions or characteristics (“Beschaffenheitsgarantie”). With respect to any examples, hints or any typical values stated herein and/or any information regarding the application of the product, Infineon Technologies hereby disclaims any and all warranties andliabilitiesofanykind,includingwithoutlimitation warranties of non-infringement of intellectual property rights of any third party. In addition, any information given in this document is subject to customer’s compliance with its obligations stated in this document and any applicable legal requirements, norms and standards concerning customer’s products and any use of the product of Infineon Technologies in customer’s applications. The data contained in this document is exclusively intended for technically trained staff. It is the responsibility of customer’s technical departments to evaluate the suitability of the product for the intended application and the completeness of the product information given in this document with respect to such application. For further information on the product, technology, delivery terms and conditions and prices please contact your nearest Infineon Technologies office (www.infineon.com). WARNINGS Due to technical requirements products may contain dangerous substances. For information on the types in question please contact your nearest Infineon Technologies office. Except as otherwise explicitly approved by Infineon Technologies in a written document signed by authorized representatives of Infineon Technologies, Infineon Technologies’ products may not be used in any applications where a failure of the product or any consequences of the use thereof can reasonably be expected to result in personal injury.