Please read the Important Notice and Warnings at the end of this document 6.2
www.infineon.com 2025-07-18
public
Security Target Lite
1
M9905 with optional ACL Software Libraries
2
According to Common Criteria CCEAL5 augmented (EAL5+)
3
4
5
Version: 6.2
6
Date: 2025-07-18
7
2 6.2
2025-07-18
Security Target Lite
M9905 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..................................................................................................................................... 5
2 Target of Evaluation Introduction......................................................................................................................... 9
2.1 Definition of the TOE........................................................................................................................................................ 9
2.1.1 Major security functions of the TOE..................................................................................................................10
2.1.2 Not part of the TOE Security Functionality ....................................................................................................10
2.2 Hardware of the TOE......................................................................................................................................................10
2.3 Firmware of the TOE......................................................................................................................................................14
2.4 Optional software of the TOE .....................................................................................................................................14
2.5 Interfaces of the TOE......................................................................................................................................................15
2.6 Guidance documentation .............................................................................................................................................15
2.7 Forms of delivery.............................................................................................................................................................15
2.8 Production sites ...............................................................................................................................................................16
2.9 TOE Configuration...........................................................................................................................................................17
2.10 TOE initialization with Customer Software..........................................................................................................17
3 Conformance Claims (ASE_CCL)..........................................................................................................................19
3.1 CC Conformance Claim..................................................................................................................................................19
3.2 PP Claim...............................................................................................................................................................................19
3.3 Package Claim ...................................................................................................................................................................19
3.4 Conformance Rationale.................................................................................................................................................20
4 Security Problem Definition (ASE_SPD)............................................................................................................23
4.1 Threats.................................................................................................................................................................................23
4.1.1 Additional Threat due to TOE specific Functionality .................................................................................23
4.1.2 Assets regarding the Threats................................................................................................................................24
4.2 Organizational Security Policies................................................................................................................................25
4.2.1 Augmented Organizational Security Policy....................................................................................................25
4.3 Assumptions......................................................................................................................................................................25
4.3.1 Augmented Assumptions.......................................................................................................................................27
5 Security objectives (ASE_OBJ)..............................................................................................................................28
5.1 Security objectives for the TOE..................................................................................................................................28
5.2 Security Objectives for the development and operational Environment.................................................29
5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”..............................................................30
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”......................................................................30
5.2.3 Clarification of “Protection during Composite product manufacturing (OE.Process-Sec-IC)”.30
5.3 Security Objectives Rationale.....................................................................................................................................30
6 Extended Component Definition (ASE_ECD) ...................................................................................................33
6.1 “Subset TOE security testing (FPT_TST)”..............................................................................................................33
6.2 Definition of FPT_TST.2 ................................................................................................................................................33
6.3 TSF self test (FPT_TST).................................................................................................................................................34
7 Security Requirements (ASE_REQ).....................................................................................................................35
7.1 FAU_SAS...............................................................................................................................................................................36
7.2 FPT_TST.2...........................................................................................................................................................................36
7.3 FCS_RNG..............................................................................................................................................................................37
7.4 Limited Capabilities and Limited Availability......................................................................................................38
7.5 Memory access control..................................................................................................................................................38
7.6 Support of Cipher Schemes .........................................................................................................................................42
7.6.1 Triple-DES Operation ..............................................................................................................................................42
7.6.2 AES Operation.............................................................................................................................................................42
7.6.3 Elliptic Curve DSA (ECDSA) operation.............................................................................................................43
7.6.4 Elliptic Curve (EC) key generation.....................................................................................................................44
3 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
7.6.5 Elliptic Curve Diffie-Hellman (ECDH) key agreement...............................................................................44
7.7 Data Integrity ....................................................................................................................................................................45
7.8 TOE Security Assurance Requirements..................................................................................................................46
7.8.1 Refinements.................................................................................................................................................................47
7.9 Security Requirements Rationale.............................................................................................................................47
7.9.1 Rationale for the Security Functional Requirements.................................................................................47
7.9.1.1 Dependencies of Security Functional Requirements ...........................................................................49
7.9.2 Rationale of the Assurance Requirements......................................................................................................51
8 TOE Summary Specification (ASE_TSS).............................................................................................................53
8.1 SF_DPM: Device Phase Management.......................................................................................................................53
8.2 SF_PS: Protection against Snooping.........................................................................................................................54
8.3 SF_PMA: Protection against Modifying Attacks ..................................................................................................55
8.4 SF_PLA: Protection against Logical Attacks..........................................................................................................56
8.5 SF_CS: Cryptographic Support....................................................................................................................................56
8.5.1 3DES encryption........................................................................................................................................................57
8.5.2 AES encryption...........................................................................................................................................................57
8.5.1 Elliptic Curves.............................................................................................................................................................57
8.5.1.1 Signature Generation.........................................................................................................................................57
8.5.1.2 Asymmetric Key Generation...........................................................................................................................57
8.5.1.3 Asymmetric Key Agreement...........................................................................................................................58
8.5.2 Asymmetric Base Library.......................................................................................................................................58
8.5.3 TRNG...............................................................................................................................................................................58
8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality............................58
8.7 Security Requirements are internally Consistent..............................................................................................59
9 References..................................................................................................................................................................61
10 Hash values................................................................................................................................................................62
11 List of Abbreviations...............................................................................................................................................63
12 Glossary.......................................................................................................................................................................65
Revision History...............................................................................................................................................................................66
4 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1 Security Target Introduction (ASE_INT)
1
1.1 Security Target and Target of Evaluation Reference
2
The title of this document is: Security Target Lite M9905 with optional ACL Software Libraries
3
The name of the TOE on the CC certificate is:
4
“Infineon Technologies Security Controller M9905 A11 with optional ACL v2.07.003 and v2.09.002”
5
The Target of Evaluation (TOE) comprises the Infineon Technologies Smart Card IC (Security
6
Controller) M9905 A11 with optional ACL v2.07.003 and v2.09.002
7
The Security Target is based on the Protection Profile “Smartcard IC Platform Protection Profile”
8
[PP].
9
The ST built in compliance to CC:2022.
10
Table 1 Identification
11
Type Version Date Title/Registration/Explainantion
Security Target
Method of identification is done by version, date and title
Security
Target
6.2 2025-07-
18
Security Target Lite
M9905 with optional ACL Software Libraries
TOE Hardware
Method of identification is done by reading of GCIM
M9905 A11 M9905 with Firmware Identifier 80001151
Libraries (optional)
Method of identification is done by hash values
NRG
Management
01.03.0927 Management of NRG cards
NRG Reader 01.02.0800 NRG reader mode support
ACL 2.07.003 Cl97-LIB-base.lib
Cl97-LIB-ecc.lib
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
5 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Type Version Date Title/Registration/Explainantion
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
M9905
Guidance
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 2007-06-
15
Security IC Platform Protection Profile BSI-PP-
0035
The cert-id BSI-CC-PP-0035-2007 refers to the
corresponding certification report.
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
The TOE can be identified with the Generic Chip Identification Mode (GCIM). The M-number
2
hardware is identified by the bytes 05 and 06, which are the first two bytes of the chip
3
identification number, having for the M9905 the value 0x0010. The design step, firmware identifier,
4
mask identifier, temperature range and system frequency are also included in the GCIM.
5
Additionally the customer can read the configuration area as defined in the SLE97 Programmer´s
6
Reference Manual [11].
7
1.2 Target of Evaluation overview
8
The TOE comprises the Infineon Technologies AG security controller M9905 with optional ACL
9
Software Libraries .
10
The Toolbox libraries are additionally supporting software which is out of scope of this
11
certification.
12
6 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The Toolbox libraries do not provide cryptographic support or additional security functionality as
1
they provide only the following basic long integer arithmetic and modular functions in software,
2
supported by the cryptographic coprocessor: Addition, subtraction, division, multiplication,
3
comparison, reduction, modular addition, modular subtraction, modular multiplication, modular
4
inversion and modular exponentiation. No security relevant policy, mechanism or function is
5
supported. The toolbox library is deemed for software developers as support for simplified
6
implementation of long integer and modular arithmetic operations.
7
The TOE is a member of the Infineon Technologies AG security controller family SLE97 meeting
8
high requirements in terms of performance and security. The SLE97 family has been developed
9
with a modular concept and different memory configurations, sets of peripherals and interfaces as
10
well as different security features to satisfy market requirements. A summary product description
11
is given in this Security Target (ST).
12
The TOE offers all functions that are both required and useful in security systems, and integrated
13
peripherals that are typically needed in chipcard applications, such as information security,
14
identification, access control, GSM and UMTS projects, electronic banking, digital signature and
15
multi-application cards, ID cards, transportation and e-purse applications.
16
The TOE implements a dedicated security 32-bit RISC CPU designed on the basis of the ARMv7M
17
architecture designed in 90 nm CMOS technology. The integrated peripherals combine enhanced
18
performance and optimized power consumption for a minimized die size to make the SLE97
19
controllers ideal for chipcard applications. The TOE offers a wide range of peripherals, including a
20
UART (using the ISO interface), four timers, two watchdogs, a CRC module, a true RNG (TRNG),
21
coprocessors for symmetric (e.g. DES, AES) and asymmetric (e.g. EC) cryptographic algorithms.
22
Additionally, a range of communication interfaces, such as GPIO, I2C, SWP, USB, SSC/SPI and NRG
23
interface are offered to provide maximum flexibility in terms of simultaneous communication
24
ability.
25
The TOE provides a real 32-bit CPU-architecture and is compatible to the ARMv7-M instruction set
26
architecture. The major components of the core system are the 32-bit CPU as a variant of the ARM
27
Secure Core SC300, the Cache system, the Memory Protection Unit and the Memory
28
Encryption/Decryption Unit. The TOE implements a full 32-bit addressing with up to 4 GByte linear
29
addressable memory space, a simple scalable memory management concept and a scalable stack
30
size. The flexible memory concept is built on the non volatile memory, respectively SOLID FLASH™
31
NVM1. For the SOLID FLASH™ NVM the Unified Channel Programming (UCP) memory technology is
32
used.
33
The TOE provides the low-level firmware components Boot Software (BOS) and Resource
34
Management System (RMS) and the high-level firmware Flash Loader (FL) and NRG software.
35
The NRG software includes the NRG operating system and additionally the optional library
36
Management of NRG cards (version 01.03.0927) and the optional library NRG Reader Mode
37
Support (01.02.0800). The Management of NRG cards provides an API for the management and
38
generation of NRG cards. The optional NRG reader mode support library (01.02.0800) enables an
39
access to external NRG cards.
40
NRG software is not part of the TSF and does not implement any Security Functional Requirement.
41
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.
7 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The RMS firmware providing some functionality via an API to the Smartcard Embedded Software
1
contains for example SOLID FLASH™ NVM service routines and functionality for the tearing save
2
write into the SOLID FLASH™ NVM. The BOS firmware is used for test purposes during start-up and
3
the FL allows downloading of user software to the NVM during the manufacturing process. The BOS
4
is implemented in a separate Test-ROM being part of the TOE. The BOS executes the UMSLC test
5
during the startup phase. It also includes the features “hardening” and the “Burn-In Test”. The
6
feature “hardening” analyzing a random SOLID FLASHTM NVM page after every regular program
7
operation for written bits that are losing their charge, and, in this very unlikely case, the page is
8
rewritten. The “Burn-In Test” during production is used to stress the chip in a high temperature,
9
high internal voltage and active operation for a certain time and filtering out defect parts to get a
10
low failure rate. The M9905 is qualified for an extended temperature range from -40°C to +105°C.
11
The two cryptographic co-processors serve the need of modern cryptography: The symmetric co-
12
processor (SCP) combines both AES and Triple-DES with dual-key or triple-key hardware
13
acceleration. The Asymmetric Crypto Co-processor, called Crypto2304T in the following, supports
14
Elliptic Curve (EC) cryptography with high performance.
15
A True Random Number Generator (TRNG) specially designed for smart card applications is
16
implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31
17
and produces genuine random numbers which then can be used internally or by the user software.
18
The software part of the TOE consists of the cryptographic libraries for EC and asymmetric the Base
19
libraries. If an EC library is part of the shipment, the corresponding asymmetric Base library is
20
automatically included.
21
The EC library is used to provide a high-level interface to Elliptic Curve cryptography implemented
22
on the hardware component Crypto2304T and includes countermeasures against SPA, DPA and
23
DFA attacks. The routines are used for ECDSA signature generation, ECDSA signature cerification,
24
ECDSA key generation and Elliptic Curve Diffie-Hellman key agreement. The EC library is delivered
25
as object code. The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves
26
with key lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that
27
there are numerous other curve types, being also secure in terms of side channel attacks on this
28
TOE, which can the user optionally add in the composition certification process.
29
The asymmetric Base library provides the low-level interface to the asymmetric cryptographic
30
coprocessor and has no user available interface. The asymmetric Base library does not provide any
31
security functionality, implements no security mechanisms and does not contribute to a security
32
functional requirement.
33
8 6.2
2025-07-18
Security Target Lite
M9905 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
2
possible attack scenarios. The TOE provides a robust set of sensors for the purpose of monitoring
3
proper chip operating conditions and detecting fault attack scenarios. The sensors are
4
complemented with digital error detection mechanisms such as parities, error detection codes and
5
instruction stream signatures. Probing and forcing attacks will be counteracted by the security
6
optimized wiring approach, implemented by an Infineon-specific shielding combined with secure
7
wiring of security critical signals, partly masking of security critical signals and by encryption of all
8
memories inside the chip (RAM, ROM, NVM). A decentralized alarm propagation and system
9
deactivation principle is implemented, further decreasing the risk of manipulating and tampering.
10
Additionally, an online check of the security mechanisms is available by using the User Mode
11
Security Life Control (UMSLC). Side-channel attacks (e.g. Timing Attack, SPA, DPA, EMA) are
12
typically defeated using a combination of hardware and software mechanisms, for this the TOE
13
provides several supporting features e.g. trash register writes and instruction interrupt prevention.
14
The Instruction Stream Signature Checking (ISS) is a powerful countermeasure against fault attacks
15
that try to manipulate the execution sequence of the instruction stream. All executed instructions
16
are hashed in the CPUs signature register and the hardware automatically checks the fitting of the
17
values.
18
In this security target the TOE is described and a summary specification is given. The security
19
environment of the TOE during its different phases of the lifecycle is defined. The assets are
20
identified which have to be protected through the security policy. The threats against these assets
21
are described. The security objectives and the security policy are defined, as well as the security
22
requirements. These security requirements are built up of the security functional requirements as
23
part of the security policy and the security assurance requirements. These are the steps during the
24
evaluation and certification showing that the TOE meets the targeted requirements. In addition, the
25
functionality of the TOE matching the requirements is described.
26
The assets, threats, security objectives and the security functional requirements are defined in this
27
Security Target and in [PP] and are referenced here. These requirements build up a minimal
28
standard common for all Smartcards.
29
The security functions are defined here in the security target as property of this specific TOE. Here
30
it is shown how this specific TOE fulfils the requirements for the standard defined in the Protection
31
Profile [PP].
32
The TOE uses also Special Function Registers SFR. These SFR registers are used for general
33
purposes and chip configuration. These registers are located in the SOLID FLASH™ NVM as
34
configuration area page.
35
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
36
providing the so called “security optimized wiring”.
37
The TOE with its integrated security features meets the requirements of all smart card applications
38
such as information integrity, access control, mobile telephone and identification, as well as uses in
39
electronic funds transfer and healthcare systems.
40
To sum up, the TOE is a powerful smart card IC with a large amount of memory and special
41
peripheral devices with improved performance, optimized power consumption, at minimal chip
42
size while implementing high security.
43
9 6.2
2025-07-18
Security Target Lite
M9905 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.
2
In 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 the TOE
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
12
and 2.9. The second part of this TOE includes the associated firmware and software required for
13
operation. The TOE can be delivered in various configurations, achieved by means of blocking and
14
depending on 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
17
data and the configuration information output, are manufactured by Infineon Technologies AG. In
18
the 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
20
of the TOE. In any case the user is able to clearly identify the TOE hardware, its configuration and
21
proof the validity of the certificate independently, meaning without involving the manufacturer.
22
The various blocking options, as well as the means used for the blocking, are done during the
23
manufacturing process or at user premises. Entirely all means of blocking and the blocking of the
24
involved firmware respectively software parts, used at Infineon Technologies AG and/or the user
25
premises, are subject of the evaluation. All resulting configurations of a TOE derivative are subject
26
of the certificate. All resulting configurations are either at the predefined limits or within the
27
predefined configuration ranges.
28
One or more additional metal layer may be added on top of one of the TOE mask sets. These
29
additional metal layer(s) just reroute the pads. Therefore, this last rerouting on top does not
30
change the function of the TOE itself; it depends on the package only, and is not relevant for the
31
security of the TOE. For these reasons, the metal layers are out of the scope of the certification and
32
do not belong to the TOE. Of course, in all cases passivation and isolation coating is applied on top
33
of the last layers carrying wires.
34
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
35
providing the so called “security optimized wiring”.
36
The firmware used for the TOE internal testing and TOE operation and the cryptographic EC and
37
base libraries are part of the TOE and therefore part of the certification. The documents as
38
described in chapter 2.6 are supplied as user guidance. BPU functionality is part of the TOE but is
39
not in the 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
10 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
2.1.1 Major security functions of the TOE
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
5
attack scenarios complemented with digital error detection mechanisms such as parities, error
6
detection 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
9
to 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 the TOE 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
22
on the TOE, but allowing refunding the customer, based on the collected user blocking
23
information. 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 the TOE
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
 Universal Asynchronous Receiver/Transmitter (UART)
42
11 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
 Single-Wire Protocol (SWP) with NRG interface
1
 Inter Integrated Circuit (I2C) interface
2
 General Purpose Input Output (GPIO)
3
 Synchronous Serial Communication (SSC) which provides the
4
Serial Peripheral Interface (SPI)
5
 Universal Serial Bus (USB) interface
6
 Standard ISO Interface (PAD)
7
8
Memories
9
 Read-Only Memory (ROM, for internal firmware)
10
 Random Access Memory (RAM)
11
 SOLID FLASH™ NVM memory (NVM)
12
Note that the TOE has implemented a SOLID FLASH™ NVM memory module. Parts of this memory
13
module are configured to work as an EEPROM.
14
15
Peripherals
16
 True Random Number Generator (TRNG)
17
 System Module (SYS)
18
 Clock Unit (CLK)
19
20
Coprocessors
21
 Crypto2304T co-processor for asymmetric algorithms (Crypto, optional)
22
 Symmetric Crypto co-processor for 3DES and AES
23

24
Analog Module (ANA)
25
 Glitch Sensor
26
 Temperature Sensor
27
 Backside Light Detector
28
 User Mode Security Life Control (UMSLC)
29
30
Buses
31
 Memory Bus
32
 Peripheral Bus
33
34
35
12 6.2
2025-07-18
Security Target Lite
M9905 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 M9905 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
20
according 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
13 6.2
2025-07-18
Security Target Lite
M9905 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),
2
the MPU (Memory Protection Unit), the MED (Memory Encryption/Decryption Unit), the Nested
3
Vectored Interrupt Controller (NVIC), the Instruction Stream Signature Checking (ISS) and the
4
Cache system. The TOE contains the co-processors for EC (Crypto2304T) and DES/AES (SCP)
5
processing, a CRC module and the true random number generator, four timers and two watchdog
6
timers and several external interface services. All data of the memory block is encrypted, RAM and
7
ROM are equipped with an error detection code (EDC) and the SOLID FLASH™ NVM is equipped in
8
addition with an error correction code (ECC).
9
The memories are connected to the Core with the Memory Bus and the peripherals are connected
10
with the Peripheral Bus.
11
The Analog Modules (ANA) serve for operation within the specified range and manage the alarms.
12
A set of sensors (temperature sensor, backside light detector, glitch sensor) is used to detect
13
excessive deviations from the specified operational range and serve for robustness of the TOE and
14
the UMSLC 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
16
compatibility the CPU implementation is entirely proprietary and not standard.
17
The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED).
18
The memory model of the TOE provides two distinct, independent levels. Additionally, up to eight
19
regions can be defined with different access rights controlled by the Memory Protection Unit
20
(MPU). Errors in RAM and ROM are automatically detected (EDC, Error Detection Code), in terms of
21
the SOLID FLASH™ NVM errors are detected and 1-Bit-errors are also corrected (ECC, Error
22
Correction Code).
23
The controller of this TOE stores both code and data in a linear 4-GByte memory space, allowing
24
direct access without the need to swap memory segments in and out of memory using a memory
25
protection unit.
26
The CACHE is a high-speed memory-buffer located between the CPU and the main memories
27
holding a copy of some of the memory contents to enable access, which is considerably faster than
28
retrieving the information from the main memory. In addition to its fast access speed, the CACHE
29
also consumes less power than the main memories. The CACHE is equipped with an integrity check
30
to verify the contents of the cache memories.
31
A True Random Number Generator (TRNG) specially designed for smart card applications is
32
implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31
33
and produces genuine random numbers which then can be used internally or by the user software.
34
The implemented sleep mode logic (clock stop mode per ISO/IEC 7816-3) is used to reduce the
35
overall power consumption. The timers permit easy implementation of communication protocols
36
such as T=1 and all other time-critical operations. The UART-controlled I/O interface allows the
37
smart card controller and the terminal interface to be operated independently.
38
The Clock Unit (CLKU) supplies the clocks for all components of the TOE. It generates the system
39
clock and an approximately 1MHz clock for the timers. The 1MHz clock is derived from an internal
40
oscillator, while the system clock may either be based on the internal oscillator clock (internal clock
41
mode) or on an external clock (external clock mode). Additionally, a sleep mode is available. When
42
operating in the internal clock mode the system frequency can be configured by the user software
43
combined with the current limitation functionality. In the external clock mode, the clock is derived
44
from the external clock and a parameter with the range of 1 to 8. The system frequency may be 1 up
45
to 8 times the externally applied frequency but is of course limited to the maximum system
46
frequency and can be combined with the current limitation function.
47
14 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Two co-processors for cryptographic operations are implemented on the TOE. The Crypto2304T
1
for calculation of asymmetric algorithms and the Symmetric Cryptographic Processor (SCP) for
2
dual-key or triple-key triple-DES and AES calculations. These co-processors are especially designed
3
for smart card applications with respect to the security and power consumption. The SCP module
4
computes the complete DES algorithm within a few clock cycles and is especially designed to
5
counter attacks like DPA, EMA and DFA. The Crypto2304T module provides basic functions for the
6
implementation of EC cryptographic libraries.
7
Note that this TOE can be delivered with Crypto2304T co-processor accessible or blocked. The
8
blocking depends on the customer demands prior to the production of the hardware. No
9
accessibility of the deselected cryptographic co-processors is without impact on any other security
10
policy of the TOE; it is exactly equivalent to the situation where the user decides just not to use the
11
cryptographic co-processors.
12
The cyclic redundancy check (CRC) module is a 16-bit checksum generator, which is not part of the
13
TSF and therefore shall not be used for security-critical data. The TOE includes two timer modules
14
each with two 16-bit general purpose timers. The timer module can be used also as watchdog timer
15
to 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
19
(USB), the SWP Slave Peripheral (SWP), the Synchronous Serial Communication (SSC), which
20
provides the serial Peripheral Interface (SPI), the GPIO module (GPIO), the Inter-Integrated Cirquit
21
Module (I2C) and the Standard ISO Interface (PAD) to satisfy the different market requirements.
22
23
2.3 Firmware of the TOE
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
28
two levels are provided, the privileged level and the non-privilege level, both are protected by a
29
hardwired Memory Protection Unit (MPU) setting.
30
The firmware executes the UMSLC test during the startup phase and includes the features
31
“hardening” and the “Burn-In Test”. The feature “hardening” analyzing a random SOLID FLASHTM
32
NVM page after every regular program operation for written bits that are losing their charge, and,
33
in this very unlikely case, the page is rewritten. The “Burn-In Test” during production is used to
34
stress the chip in a high temperature, high internal voltage and active operation for a certain time
35
and filtering out defect parts to get a low failure rate. The TOE is qualified for an extended
36
temperature range from -40°C to +105°C.
37
The RMS is accessible in privileged level only. The FL (Flash Loader) allows downloading of user
38
software to the NVM during the manufacturing process and can be completely deactivated.
39
40
2.4 Optional software of the TOE
41
42
The optional software part of the TOE consists of the cryptographic libraries EC and asymmetric
43
Base libreries.
44
The EC library is used to provide a high level interface to Elliptic Curve cryptography and includes
45
countermeasures against SPA, DPA and DFA attacks. The routines are used for ECDSA signature
46
generation, ECDSA key generation and Elliptic Curve Diffie-Hellman key agreement. The EC library
47
15 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
is delivered as object code and integrated in this way into the user software. The certification
1
covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of 160, 163,
2
192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are numerous other curve
3
types, being also secure in terms of side channel attacks on this TOE, which can the user optionally
4
add in the composition certification process.
5
The Asymmetric Base library provides the low level interface to the asymmetric cryptographic
6
coprocessor for the ECC cryptographic libraries and has no user available interface. It does not
7
support any security relevant policy or function. The Base and ECC library can optionally be
8
delivered in the alternative versions:
9
 The version v2.07.003
10
 The version v2.09.002
11
12
2.5 Interfaces of the TOE
13
 The physical interface of the TOE to the external environment is the entire surface of the IC.
14
 The electrical interface of the TOE to the external environment is constituted by the pads of the
15
chip:
16
− The five ISO 7816 pads consist particularly of the contacted RES, I/O, CLK lines and supply
17
lines VCC and GND. The contact based communication is according to ISO 7816/ETSI/EMV.
18
The I2C communication can be driven via the ISO 7816 pads. In this case no other
19
communication using the ISO 7816 pads is possible.
20
− The GPIO interface consists of 4 pads which can be individually configured and combined.
21
22
− Also the I2C and the SSC/SPI communication can be exclusively driven via the GPIO pads. In
23
this case no other communication using the GPIO pads is possible.
24
− The USB interface is built out of two dedicated pads for data communication and two pads
25
used from the ISO 7816 interface supplying power and ground.
26
− The SWP interface is built out of one pad to support the SWP slave functionality.
27
 The data-oriented I/O interface to the TOE is formed by the I/O pad.
28
 The interface to the firmware is constituted by special registers used for hardware configuration
29
and control (Special Function Registers, SFR).
30
 The interface of the TOE to the operating system is constituted on one hand by the RMS routine
31
calls and on the other by the instruction set of the TOE.
32
 The interface of the TOE to the test routines is formed by the BOS test routine call, i.e. entry to
33
test mode (OS-TM entry).
34
 The interface to the EC calculations is defined by the EC library (optionally).
35
2.6 Guidance documentation
36
The guidance documentation is listed in Table 1
37
2.7 Forms of delivery
38
The TOE can be delivered in form of bare dies, in form of plain wafers, in form of complete modules
39
(wire bond module M4.x, provided as single chip wire bond or as stacked wire bond), or in one of
40
the following an IC cases: MFC5.8 (FCOS), PG-VQFN-8-1, PG-VQFN-32-13 (SMD) and P-M2M4.7-8-
41
1. In any case the testing of the TOE is finished and the extended test features are removed. From a
42
security policy point of view the different forms of delivery do not have any impact.
43
The delivery can therefore be at the end of phase 3 or at the end of phase 4 which can also include
44
pre-personalization steps according to PP [PP].
45
16 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The delivery to the software developer (phase 2  phase 1) is handled by downloading via
1
SecureX portal. It contains the documentation as described above and the development and
2
debugging tools.
3
Part of the software delivery could also be the Flash Loader program, provided by Infineon
4
Technologies, running on the TOE and receiving via the UART interface the transmitted information
5
of the user software to be loaded into the SOLID FLASH™ NVM memory. The download is only
6
possible after successful authentication. In addition, the user can permanently block further use of
7
the Flash Loader. Whether the Flash Loader program is present or not depends on the procurement
8
order.
9
Table 2 TOE deliveries: forms and methods
10
TOE Component Delivered Format Delivery Method Comment
M9905 A11 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 –
11
The TOE is identified by the components as described in the physical scope in chapter 2.2.
12
 The Hardware version, design step and Firmware version shall be read out form the chip by the
13
Generic Chip Identification Mode (GCIM) and compared against the correct versions. The
14
procedure how to read that data is described in the Programmers Reference Manual. The
15
correct versions are listed in chapter 2.3
16
 The correct library versions shall be verified by the corresponding hash values as defined in
17
chapter 10.
18
 The user guidance documents shall be compared to the versions listed in chapter 2.6
19
20
2.8 Production sites
21
The silicon of the design is produced in Dresden.
22
The delivery measures are described in the ALC_DVS aspect.
23
24
Table 3 Production site in chip identification
25
Production Site Chip Identification
Dresden, Germany byte number 13 (Fab number): 02H
26
27
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.
17 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
2.9 TOE Configuration
1
The TOE hardware offers different configuration options, which a customer can choose. The
2
mechanism to choose a configuration can be done by the following methods:
3
1. by product selection or dialog-based in Tools,
4
2. via Bill-per-Use (BpU) and Flash Loader (FL),
5
The degree of freedom for configuring the TOE is predefined by Infineon Technologies AG. The list
6
of TOE configurations is given in the confidential ST.
7
Besides fix TOE configurations, which can be ordered as usual, this TOE implements optionally the
8
so called Bill-Per-Use (BPU) ability. This solution enables the customer to tailor the product on his
9
own to the required configuration by blocking parts of the chip on demand into the final
10
configuration at his own premises, without further delivery or involving support by Infineon
11
Technology AG. Customers, who are intended to use this feature receive the TOE in a predefined
12
configuration including the Flash Loader software, enhanced with the BPU blocking software. The
13
blocking information is part of a chip configuration area and can be modified by customers using
14
specific APDUs. Once a final blocking is done, further modifications are disabled.
15
The BPU software part is only present on the products which have been ordered with the BPU
16
option. In all other cases this software is not present on the product.
17
Additionally the user can choose between different optional software libraries.
18
The user can choose the management of NRG libraries (version 01.03.0927) and/or the NRG reader
19
mode support library (01.02.0800). Please note that the NRG libreries are not part of this
20
certification.
21
22
The hardware of this TOE can be delivered with the following configuration options:
23
 both crypto co-processors accessible
24
 with a blocked Crypto2304T
25
In the case the Crypto2304T is blocked, no EC computation supported by hardware is possible. No
26
accessibility of the deselected cryptographic co-processors is without impact on any other security
27
policy of the TOE; it is exactly equivalent to the situation where the user decides just not to use the
28
cryptographic co-processors.
29
The TOE can be delivered with the following optional libraries
30
 ECC
31
 Asymmetric Base library for ECC
32
33
In case of deselecting one or several of these libraries the TOE does not provide the respective
34
functionality.
35
36
2.10 TOE initialization with Customer Software
37
Beside the various TOE configurations further possibilities of how the user inputs his software on
38
the TOE are in place. This provides a maximum of flexibility and for this an overview is given in the
39
following table:
40
41
Table 4 Options to implement user software at Infineon production premises
42
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
The Flash Loader is deactivated.
18 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Infineon Technologies AG. The software is
downloaded to the SOLID FLASH™ NVM
memory during chip production. There are no
user data in the ROM.
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.
1
The Generic Chip Identification Mode (GCIM) data of the TOE allows a unique identification of each
2
TOE and provides several detailed production information. The Chip Identification Mode data is
3
accessible by a non-ISO reset or can be read directly from the configuration area located at the NVM
4
by the user operating system. The SLE97 Hardware Reference Manual [HRM] gives a detailed
5
description of the GCIM data.
6
19 6.2
2025-07-18
Security Target Lite
M9905 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,
3
part 1 [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
10
Sicherheit in der Informationstechnik1 (BSI) under the reference BSI-PP-0035, Version 1.0, dated
11
15.06.2007.
12
The security assurance requirements of the TOE are according to the Security IC Platform
13
Protection Profile [PP]. They are all drawn from [CC-3].
14
The augmentations of the PP [PP] are listed below.
15
16
Table 5 Augmentations of the assurance level of the TOE
17
Assurance Class Assurance
components
Description
Lifecycle
support
ALC_DVS.2 Sufficiency of security measures
Vulnerability
assessment
AVA_VAN.5 Advanced methodical vulnerability analysis
18
3.3 Package Claim
19
This Security Target does not claim conformance to a package of the PP [PP].
20
The assurance level for the TOE is EAL5 augmented with the components ALC_DVS.2 and
21
AVA_VAN.5.
22
23
24
1 Bundesamt für Sicherheit in der Informationstechnik (BSI) is the German Federal Office for Information Security
20 6.2
2025-07-18
Security Target Lite
M9905 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
5
the 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
12
threats, an organization security policy and an augmented assumption. Including these add-ons, the
13
security problem definition of this security target is consistent with the statement of the security
14
problem 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 augmented assumption A.Key-Function, related to
18
the usage of key-depending function, the threat T-Masquerade.TOE and the threat memory access
19
violation, due to specific TOE memory access control functionality, have been added. These add-ons
20
have no impact on the conformance statements regarding CC [CC-1] and PP [PP], with following
21
rationale:
22
The security target remains conformant to CC part 2 [CC-2], as the possibility to introduce
23
additional restrictions is given.
24
The security target fulfils the strict conformance claim of the PP [PP] due to the application notes 5,
25
6 and 7 which apply here. By those notes the addition of further security functions and security
26
services are covered, even without deriving particular security functionality from a threat but from
27
a policy.
28
Due to additional security functionality, one coming from the cryptographic libraries - O.Add-
29
Functions, the memory access control - O.Mem-Access, and the hash additional security objectives
30
have been introduced. These add-ons have no impact on the conformance statements regarding CC
31
[CC-1] and PP [PP], with following rational:
32
The security target remains conformant to CC part 2 [CC-2], as the possibility to introduce
33
additional restrictions is given.
34
The security target fulfils the strict conformance of the PP [PP] due to the application note 9
35
applying here. This note allows the definition of high-level security goals due to further functions or
36
services provided to the Security IC Embedded Software.
37
Therefore, the security objectives of this security target are consistent with the statement of the
38
security objectives in the PP [PP], as the security target claimed strict conformance to the PP [PP].
39
40
All security functional requirements defined in the PP [PP] are included and completely defined in
41
this ST. The security functional requirements listed in the following are all taken from Common
42
Criteria part 2 [CC-2] and additionally included and completely defined in this ST:
43
21 6.2
2025-07-18
Security Target Lite
M9905 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
 FDP_SDI.1 “Stored data integrity monitoring
8
 FDP_SDI.2 “Stored data integrity monitoring and action
9
The security functional requirement
10
 FPT_TST.2 “Subset TOE security testing“ (Requirement from [CC-2])
11
is included and completely defined in this ST, section 6.
12
All assignments and selections of the security functional requirements are done in the PP [PP] and
13
in this security target in section 7.8.
14
The Assurance Requirements of the TOE obtain the Evaluation Assurance Level 5 augmented with
15
the assurance components ALC_DVS.2 and AVA_VAN.5 for the TOE.
16

17
 With CC:2022 several SFR changes are introduced. Due to this ST claiming conformance to
18
CC:2022 and PP0035 [PP], rationales are provided that these changes do not affect the
19
conformance claim to PP0035:
20
 FCS_COP.1: for this SFR dependencies are changed in CC:2022. FCS_CKM.4 is removed and
21
instead FCS_CKM.6 added. Further FCS_CKM.5 is added for key derivation as an alternative.
22
 FCS_CKM.1: for this SFR dependencies are changed in CC:2022. Additionally, to FCS_CKM.2 and
23
FCS_COP.1, one further SFR is introduced as alternative: FCS_CKM.5. This SFR targets key
24
derivation, subsequent to FCS_CKM.1. In CC:2022 key derivation would have been part of
25
FCS_CKM.1 and thus conformancy to [PP] can still be claimed. FCS_CKM.4 is removed and
26
instead FCS_CKM.6 added. All other dependencies (i.e. FCS_RNG.1 or FCS_RBG.1) are in addition
27
to the already existing ones, i.e. add stricter requirements.
28
 FCS_CKM.6 replaces FCS_CKM.4 and adds further requirements on the timing of key
29
destruction. As an alternative dependency to FCS_CKM.1, FCS_CKM.5 (key derivation) can be
30
used. As FCS_CKM.5 is neither used within [PP] nor within this ST, it has no relevance in this
31
context.
32
 FCS_RNG.1: this SFR is taken from [CC-2] rather than [PP].
33
 FMT_LIM.1 and FMT_LIM.2 are taken from [CC-2] rather than [PP]. There is a slightly different
34
phrasing (i.e. removing redundancy from FMT_LIM.1) and availability and capability policy
35
mentioned in both SFR’s. The meaning though is the same and therefore conformancy can still
36
be claimed.
37
Further with CC:2022 some SAR changes were introduced. Rationales are provided that these
38
changes 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),
40
which 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
42
for [PP]
43
 ASE_REQ.2: extended for multi assurance: not relevant for [PP]
44
 AVA_VAN.5: extension about third party components introduced. No relaxation was introduced.
45
22 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
 ALC_TAT.1: extension with guidance on the minimum content for an implementation standards
1
description and rules with ADV_COMP.1. No relaxation was introduced.
2
3
23 6.2
2025-07-18
Security Target Lite
M9905 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
6
later on in the process of evaluation and certification. An overview on attacks is given in PP [PP]
7
section 3.2.
8
The threats to security are defined and described in PP [PP] section 3.2.
9
Table 6 Threats according PP [PP]
10
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 Additional Threat due to TOE specific Functionality
11
The additional functionality of introducing sophisticated privilege levels and access control allows
12
the secure separation between the operation system(s) and applications, the secure downloading
13
of applications after personalization and enables multitasking by separating memory areas and
14
performing access controls between different applications. Due to this additional functionality
15
“area based memory access control” a new threat is introduced.
16
The Smartcard Embedded Software is responsible for its User Data according to the assumption
17
“Treatment of User Data (A.Resp-Appl)”. However, the Smartcard Embedded Software may
18
comprise different parts, for instance an operating system and one or more applications. In this
19
case, such parts may accidentally or deliberately access data (including code) of other parts, which
20
may result in a security violation.
21
The TOE shall avert the threat “Memory Access Violation (T.Mem-Access)” as specified below.
22
T.Mem-Access Memory Access Violation
23
Parts of the Smartcard Embedded Software may cause security violations by accidentally or
24
deliberately accessing restricted data (which may include code) or privilege levels. Any restrictions
25
are defined by the security policy of the specific application context and must be implemented by
26
the Smartcard Embedded Software.
27
T.Masquerade_TOE Masquerade of the TOE
28
An attacker may threaten the property being a genuine TOE by producing a chip which is not a
29
genuine TOE but wrongly identifying itself as genuine TOE sample. This threat has been
30
additionally introduced because the chip can be delivered without an User OS doing the
31
identification.
32
24 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Table 7 Additional threats due to TOE specific functions and augmentations
1
T.Mem-Access Memory Access Violation
T.Masquerade_TOE Masquerade of the TOE
2
4.1.2 Assets regarding the Threats
3
The primary assets concern the User Data which includes the user data as well as program code
4
(Security IC Embedded Software) stored and in operation and the provided security services. These
5
assets have to be protected while being executed and or processed and on the other hand, when the
6
TOE is not in operation.
7
This leads to four primary assets with its related security concerns:
8
 SC1 Integrity of User Data and of the Security IC Embedded Software (while being
9
executed/processed and while being stored in the TOE’s memories),
10
 SC2 Confidentiality of User Data and of the Security IC Embedded Software (while being
11
processed and while being stored in the TOE’s memories)
12
 SC3 Correct operation of the security services provided by the TOE for the Security IC
13
Embedded Software.
14
 SC4 Continuous availability of random numbers
15
SC4 is an additional security service provided by this TOE which is the availability of random
16
numbers. These random numbers are generated either by a true random number or a deterministic
17
random number generator or by both, when a true random number is used as seed for the
18
deterministic random number generator. Note that the generation of random numbers is a
19
requirement of the PP [PP].
20
To be able to protect the listed assets the TOE shall protect its security functionality as well.
21
Therefore critical information about the TOE shall be protected. Critical information includes:
22
 logical design data, physical design data, IC Dedicated Software, and configuration data
23
 Initialisation Data and Pre-personalisation Data, specific development aids, test and
24
characterisation related data, material for software development support, and reticles.
25
The information and material produced and/or processed by the TOE Manufacturer in the TOE
26
development and production environment (Phases 2 up to TOE Delivery) can be grouped as
27
follows:
28
 logical design data,
29
 physical design data,
30
 IC Dedicated Software, Security IC Embedded Software, Initialisation Data and Pre-
31
personalisation Data,
32
 specific development aids,
33
 test and characterisation related data,
34
 material for software development support, and
35
 reticles and products in any form
36
as long as they are generated, stored, or processed by the TOE Manufacturer.
37
For details see PP [PP] section 3.1.
38
25 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
4.2 Organizational Security Policies
1
The TOE has to be protected during the first phases of their lifecycle (phases 2 up to TOE delivery
2
which can be after phase 3 or phase 4). Later on each variant of the TOE has to protect itself. The
3
organizational security policy covers this aspect.
4
P.Process-TOE Protection during TOE Development and Production
5
An accurate identification must be established for the TOE. This requires that each instantiation of
6
the TOE carries this unique identification.
7
The organizational security policies are defined and described in PP [PP] section 3.3. Due to the
8
augmentations of PP [PP] an additional policy is introduced and described in the next chapter.
9
Table 8 Organizational Security Policies according PP [PP]
10
P.Process-TOE Protection during TOE Development and Production
4.2.1 Augmented Organizational Security Policy
11
Due to the augmentations of the PP [PP] an additional policy is introduced.
12
The TOE provides specific security functionality, which can be used by the Smartcard Embedded
13
Software. In the following specific security functionality is listed which is not derived from threats
14
identified for the TOE’s environment because it can only be decided in the context of the smartcard
15
application, against which threats the Smartcard Embedded Software will use the specific security
16
functionality.
17
The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality
18
(P.Add-Functions)” as specified below.
19
P.Add-Functions Additional Specific Security Functionality
20
The TOE shall provide the following specific security functionality to the Smartcard Embedded
21
Software:
22
 Advanced Encryption Standard (AES)
23
 Triple Data Encryption Standard (3DES)
24
 Elliptic Curve Cryptography (EC)
25
26
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
27
the Crypto2304T is blocked, no ECC computation supported by hardware is possible. The
28
ECC functionality has then to be removed from this policy.
29
Note:The TOE can also be delivered with the optional ECC library. The optional ECC library needs
30
an accessible Crypto2304T. If the optional ECC library is not delivered then ECC functionality
31
has to be removed from this policy.
32
4.3 Assumptions
33
The TOE assumptions on the operational environment are defined and described in PP [PP] section
34
3.4.
35
The assumptions concern the phases where the TOE has left the chip manufacturer.
36
26 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization:
2
It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer
3
up to delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its
4
manufacturing and test data (to prevent any possible copy, modification, retention, theft or
5
unauthorised use).
6
A.Plat-Appl Usage of Hardware Platform:
7
The Security IC Embedded Software is designed so that the requirements from the following
8
documents are met: (i) TOE guidance documents (refer to the Common Criteria assurance class
9
AGD) such as the hardware data sheet, and the hardware application notes, and (ii) findings of the
10
TOE evaluation reports relevant for the Security IC Embedded Software as documented in the
11
certification report.
12
A.Resp-Appl Treatment of User Data:
13
All User Data are owned by Security IC Embedded Software. Therefore, it must be assumed that
14
security relevant User Data (especially cryptographic keys) are treated by the Security IC
15
Embedded Software as defined for its specific application context.
16
The support of cipher schemas needs to make an additional assumption.
17
Table 9 Assumption according PP [PP]
18
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization
A.Plat-Appl Usage of Hardware Platform
A.Resp-Appl Treatment of User Data
19
20
27 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
4.3.1 Augmented Assumptions
1
The developer of the Smartcard Embedded Software must ensure the appropriate “Usage of Key-
2
dependent Functions (A.Key-Function)” while developing this software in Phase 1 as specified
3
below.
4
A.Key-Function Usage of Key-dependent Functions
5
Key-dependent functions (if any) shall be implemented in the Smartcard Embedded Software in a
6
way that they are not susceptible to leakage attacks (as described under T.Leak-Inherent and
7
T.Leak-Forced).
8
Note, that here the routines which may compromise keys when being executed are part of the
9
Smartcard Embedded Software. In contrast to this, the threats T.Leak-Inherent and T.Leak-Forced
10
address (i) the cryptographic routines which are part of the TOE (For details see PP [PP] section
11
3.4.).
12
28 6.2
2025-07-18
Security Target Lite
M9905 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
7
IC Embedded Software
8
 SG4 provision of random numbers.
9
5.1 Security objectives for the TOE
10
The security objectives of the TOE are defined and described in PP [PP] section 4.1.
11
12
Table 10 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
15
below.
16
O.Add-Functions : Additional Specific Security Functionality
17
The TOE must provide the following specific security functionality to the Smartcard Embedded
18
Software:
19
 Advanced Encryption Standard (AES)
20
 Triple Data Encryption Standard (3DES)
21
 Elliptic Curve Cryptography (EC) (optional)
22
The hardware of this TOE can be delivered with the following configuration options:
23
 both crypto co-processors accessible
24
 with a blocked Crypto2304T
25
In the case the Crypto2304T is blocked, no EC computations supported by hardware are possible.
26
The optional security relevant software part of the TOE consists of the following optional libraries:
27
 EC Cryptographic Library
28
29
The TOE shall provide “Area based Memory Access Control (O.Mem-Access)” as specified below.
30
29 6.2
2025-07-18
Security Target Lite
M9905 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
3
access of software to memory areas and privilege levels is controlled as required, for example, in a
4
multi-application environment.
5
Table 11 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 development and operational
7
Environment
8
The security objectives of the TOE are defined and described in PP [PP] section 4.1.
9
Table 12 Objectives for the TOE according to PP [PP]
10
OE.Plat-Appl Usage of Hardware Platform
OE.Resp-Appl Treatment of User Data
OE.Process-Sec-IC Protection during composite product manufacturing
11
This ST further defines the objectives for the environment OE.Secure_Delivery as specified below.
12
OE.Secure_Delivery:
13
The TOE does not provide transport protection. Therefore, technical and / or organisational
14
security procedures (e.g. a custom mutual authentication mechanism or a security transport)
15
should be put in place by the customer to secure the personalized TOE during delivery as required
16
by the security needs of the loaded IC Embedded Software.
17
18
The table below lists the security objectives for the environment in the life cycle phases.
19
Table 13 Security objectives for the environment
20
Phase 1 OE.Plat-Appl Usage of Hardware Platform
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
OE.Prevent-Masquerade
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.
30 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”
1
Regarding the cryptographic services this objective of the environment has to be clarified. The TOE
2
supports cipher schemes as additional specific security functionality. If required the Smartcard
3
Embedded Software shall use these cryptographic services of the TOE and their interface as
4
specified. When key-dependent functions implemented in the Smartcard Embedded Software are
5
just being executed, the Smartcard Embedded Software must provide protection against disclosure
6
of confidential data (User Data) stored and/or processed in the TOE by using the methods
7
described under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information
8
Leakage (T.Leak-Forced)“.
9
The objectives of the environment regarding the memory, software and firmware protection and
10
the SFR and peripheral-access-rights-handling have to be clarified. For the separation of different
11
applications the Smartcard Embedded Software (Operating System) may implement a memory
12
management scheme based upon security functions of the TOE.
13
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”
14
Regarding the cryptographic services this objective of the environment has to be clarified. By
15
definition cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded
16
Software shall treat these data appropriately, use only proper secret keys (chosen from a large key
17
space) as input for the cryptographic function of the TOE and use keys and functions appropriately
18
in order to ensure the strength of cryptographic operation.
19
This means that keys are treated as confidential as soon as they are generated. The keys must be
20
unique with a very high probability, as well as cryptographically strong. For example, it must be
21
ensured that it is beyond practicality to derive the private key from a public key if asymmetric
22
algorithms are used. If keys are imported into the TOE and/or derived from other keys, quality and
23
confidentiality must be maintained. This implies that appropriate key management has to be
24
realized in the environment.
25
Regarding the memory, software and firmware protection and the SFR and peripheral access rights
26
handling these objectives of the environment has to be clarified. The treatment of User Data is also
27
required when a multi-application operating system is implemented as part of the Smartcard
28
Embedded Software on the TOE. In this case the multi-application operating system should not
29
disclose security relevant user data of one application to another application when it is processed
30
or stored on the TOE.
31
5.2.3 Clarification of “Protection during Composite product
32
manufacturing (OE.Process-Sec-IC)”
33
The protection during packaging, finishing and personalization includes also the personalization
34
process (Flash Loader software) and the personalization data (TOE software components) during
35
Phase 4, Phase 5 and Phase 6.
36
5.3 Security Objectives Rationale
37
The security objectives rationale of the TOE are defined and described in PP [PP] section 4.4. For
38
organizational security policy P.Add-Functions, OE.Plat-Appl and OE.Resp-Appl the rationale is
39
given in the following description.
40
Table 14 Security Objective Rationale
41
Assumption, Threat or Organisational
Security Policy
Security Objective
P.Add-Functions O.Add-Functions
31 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
A.Key-Function OE.Plat-Appl
OE.Resp-Appl
T.Mem-Access O.Mem-Access
T.Masquerade_TOE OE.Secure_Delivery
1
The justification related to the security objective “Additional Specific Security Functionality
2
(O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the
3
same specific security functionality as required by P.Add-Functions; the organizational security
4
policy is covered by the objective.
5
Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
6
Manipulation and O.Leak-Forced define how to implement the specific security functionality
7
required by P.Add-Functions. (Note that these objectives support that the specific security
8
functionality is provided in a secure way as expected from P.Add-Functions.) Especially O.Leak-
9
Inherent and O.Leak-Forced refer to the protection of confidential data (User Data or TSF data) in
10
general. User Data are also processed by the specific security functionality required by
11
P.Add-Functions.
12
13
14
15
16
17
18
19
Compared to PP [PP] clarification has been made for the security objective “Usage of Hardware
20
Platform (OE.Plat-Appl)”: If required the Smartcard Embedded Software shall use these
21
cryptographic services of the TOE and their interface as specified. In addition, the Smartcard
22
Embedded Software must implement functions which perform operations on keys (if any) in such a
23
manner that they do not disclose information about confidential data. The non disclosure due to
24
leakage A.Key-Function attacks is included in this objective OE.Plat-Appl. This addition ensures that
25
the assumption A.Plat-Appl is still covered by the objective OE.Plat-Appl although additional
26
functions are being supported according to O.Add-Functions.
27
Compared to the PP [PP] a clarification has been made for the security objective “Treatment of User
28
Data (OE.Resp-Appl)”: By definition cipher or plain text data and cryptographic keys are User Data.
29
So, the Smartcard Embedded Software will protect such data if required and use keys and functions
30
appropriately in order to ensure the strength of cryptographic operation. Quality and
31
confidentiality must be maintained for keys that are imported and/or derived from other keys. This
32
implies that appropriate key management has to be realized in the environment. That is expressed
33
by the assumption A.Key-Function which is covered from OE.Resp-Appl. These measures make sure
34
that the assumption A.Resp-Appl is still covered by the security objective OE.Resp-Appl although
35
additional functions are being supported according to P.Add-Functions.
36
Compared to the PP [PP] an enhancement regarding memory area protection has been established.
37
The clear definition of privilege levels for operated software establishes the clear separation of
38
different restricted memory areas for running the firmware, downloading and/or running the
39
operating system and to establish a clear separation between different applications. Nevertheless, it
40
is also possible to define a shared memory section where separated applications may exchange
41
defined data. The privilege levels clearly define by using a hierarchical model the access right from
42
one level to the other. These measures ensure that the threat T.Mem-Access is clearly covered by
43
the security objective O.Mem-Access.
44
32 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The justification of the additional policy and the additional assumption show that they do not
1
contradict to the rationale already given in the Protection Profile for the assumptions, policy and
2
threats defined there.
3
The objective OE.Secure_Delivery is defined to require transport protection by the environment ias
4
the TOE does not provide this objective.
5
6
33 6.2
2025-07-18
Security Target Lite
M9905 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 “Subset TOE 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
9
phase (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the
10
TOE or is done automatically and continuously.
11
Part 2 of the Common Criteria provides the security functional component “TSF testing
12
(FPT_TST.1)”. 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
17
”Subset TOE security testing (FPT_TST.2)” of the family TSF self test has been newly created. This
18
component allows that particular parts of the security mechanisms and functions provided by the
19
TOE are tested.
20
6.2 Definition of FPT_TST.2
21
The functional component “Subset TOE security testing (FPT_TST.2)” has been newly created
22
(Common Criteria Part 2 extended). This component allows that particular parts of the security
23
mechanisms and functions provided by the TOE can be tested after TOE Delivery or are tested
24
automatically and continuously during normal operation transparent for the user.
25
This security functional component is used instead of the functional component FPT_TST.1 from
26
Common Criteria Part 2. For the user it is important to know which security functions or
27
mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly
28
specify the security functions being tested. In addition, FPT_TST.1 requires verifying the integrity of
29
TSF data and stored TSF executable code which might violate the security policy.
30
The functional component “Subset TOE testing (FPT_TST.2)” is specified as follows (Common
31
Criteria Part 2 extended).
32
33
34 6.2
2025-07-18
Security Target Lite
M9905 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
8
conditions are met. It also provides the ability to verify the integrity of TSF data and
9
executable code.
10
Management: FPT_TST.2
11
The following actions could be considered for the management functions in FMT:
12
management of the conditions under which subset TSF self testing occurs, such as
13
during initial start-up, regular interval or under specified conditions management of
14
the time of the interval appropriate.
15
Audit: FPT_TST.2
16
There are no auditable events foreseen.
17
FPT_TST.2 Subset TOE testing
18
Hierarchical to: No other components.
19
Dependencies: No dependencies
20
FPT_TST.2.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically
21
during normal operation, at the request of the authorized user, and/or at the
22
conditions [assignment: conditions under which self test should occur]] to
23
demonstrate the correct operation of [assignment: functions and/or mechanisms].
24
25
35 6.2
2025-07-18
Security Target Lite
M9905 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]
3
section 6.1 and in the following description.
4
The Table 15 provides an overview of the functional security requirements of the TOE, defined in
5
PP [PP] section 6.1. In the last column it is marked if the requirement is refined. The refinements
6
are also valid for this ST.
7
Table 15 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
9
Table 16 provides an overview of all SFRs which are taken from the CC standard [CC-2]. They
10
replace the corresponding SFRs from PP [PP].
11
Table 16 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 Rndom number generation
13
14
The Table 17 provides an overview about the augmented security functional requirements, which
15
are added additional to the TOE and defined in this ST. All requirements are taken from Common
16
Criteria Part 2 [CC-2], with the exception of the requirement FPT_TST.2, which is defined in this ST
17
completely.
18
19
Table 17 Augmented security functional requirements
20
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
FCS_COP.1 Cryptographic support
FCS_CKM.1 Cryptographic key generation
FDP_SDI.1 Stored data integrity monitoring
36 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
FDP_SDI.2 Stored data integrity monitoring and action
1
All assignments and selections of the security functional requirements of the TOE are done in PP
2
[PP] 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
7
class addresses the management of functions of the TSF.
8
The additional component FAU.SAS is introduced to define the security functional requirements of
9
the TOE of the Class FAU (Security Audit). This family describes the functional requirements for the
10
storage 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
12
is given as the correct operation of the security functions is essential. The TOE provides
13
mechanisms to cover this requirement by the smartcard embedded software and/or by the TOE
14
itself.
15
7.1 FAU_SAS
16
To define the security functional requirements of the TOE an additional family (FAU_SAS) of the
17
Class FAU (Security Audit) is defined here. This family describes the functional requirements for
18
the storage of audit data. It has a more general approach than FAU_GEN, because it does not
19
necessarily require the data to be generated by the TOE itself and because it does not give specific
20
details of the content of the audit records.
21
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common
22
Criteria Part 2 extended).
23
24
FAU_SAS.1 Audit Storage
25
Hierarchical to: No other components
26
Dependencies: No dependencies.
27
FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the
28
capability to store the Initialization Data and/or Pre-personalization Data
29
and/or supplements of the Security IC Embedded Software in the not
30
changeable configuration page area and non-volatile memory.
31
7.2 FPT_TST.2
32
The security is strongly dependent on the correct operation of the security functions. Therefore, the
33
TOE shall support that particular security functions or mechanisms are tested in the operational
34
phase (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the
35
TOE.
36
The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below
37
(Common Criteria Part 2 extended).
38
39
FPT_TST.2 Subset TOE testing
40
Hierarchical to: No other components
41
Dependencies: No dependencies
42
37 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
FPT_TST.2.1 The TSF shall run a suite of self tests at the request of the authorized user to
1
demonstrate the correct operation of the alarm lines and/or the
2
environmental sensor mechanisms
3
7.3 FCS_RNG
4
To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the
5
class FCS (cryptographic support) is defined in [CC-2].
6
7
FCS_RNG.1 Random Number Generation
8
Hierarchical to: No other components
9
Dependencies: No dependencies
10
FCS_RNG.1 Random numbers generation Class PTG.2 according to [CC-2]
11
FCS_RNG.1.1 The TSF shall provide a physical1 random number generator that
12
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
17
is being operated, the RNG prevents the output of any internal random
18
number that depends on some raw random numbers that have been
19
generated after the 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,
23
and (ii) while the RNG is being operated. The TSF must not output any
24
random numbers before the power-up online test has finished successfully
25
or when a 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
30
num ber sequence. It is triggered continuously. The online test is suitable for
31
detecting non-tolerable statistical defects of the statistical properties of the
32
raw 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
36
internal 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]]
38 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
PTG.2.7: The average Shannon entropy per internal random bit exceeds
1
0.997.1
2
7.4 Limited Capabilities and Limited Availability
3
The SFR’s FMT_LIM.1 and FMT_LIM.2 from [PP] are adapted due to CC:2022.
4
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.
5
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
6
Usage of multiple applications in one Smartcard often requires code and data separation in order to
7
prevent that one application can access code and/or data of another application. For this reason the
8
TOE provides Area based Memory Access Control. The underlying Memory Protection Unit (MPU)
9
is documented in section 4 of the [HRM].
10
The security service being provided is described in the Security Function Policy (SFP) Memory
11
Access Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)”
12
requires that this policy is in place and defines the scope where it applies. The security functional
13
requirement “Security attribute based access control (FDP_ACF.1)” defines security attribute usage
14
and characteristics of policies. It describes the rules for the function that implements the Security
15
Function Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or
16
not is taken based upon attributes allocated to the software. The Smartcard Embedded Software
17
defines the attributes and memory areas. The corresponding permission control information is
18
evaluated “on-the-fly” by the hardware so that access is granted/effective or denied/inoperable.
19
1 [assignment: a defined quality metric]
2 [assignment: Limited capability and availability policy]
3 [assignment: Limited capability and availability policy]
39 6.2
2025-07-18
Security Target Lite
M9905 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)
5
or set at run-time (FMT_MSA.1).
6
From TOE’s point of view the different roles in the Smartcard Embedded Software can be
7
distinguished according to the memory based access control. However the definition of the roles
8
belongs to the user 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
21
fault 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
26
unexpected 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
43
Operation is allowed for any Subject.
44
45
Roles of the policy:
46
40 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The roles correspond 1-1 to the subjects.
1
2
Properties of the policy:
3
 If an address is contained in multiple enabled regions, then the region with the highest priority
4
defines the access rights.
5
 If an address is contained in no region then the default region defines the access rights.
6
 The region defining the access rights checks in the access matrix if the Subject has access to the
7
Object with respect to the desired Operation. In case the access is denied the MPU throws an
8
access violation exception.
9
10
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below.
11
12
FDP_ACC.1 Subset access control
13
Hierarchical to: No other components.
14
Dependencies: FDP_ACF.1 Security attribute based access control
15
FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all Subjects, all
16
Objects and all Operations.
17
18
19
The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as
20
specified below.
21
22
FDP_ACF.1 Security attribute based access control
23
Hierarchical to: No other components.
24
Dependencies: FDP_ACC.1 Subset access control
25
FMT_MSA.3 Static attribute
26
FDP_ACF.1.1 The TSF shall enforce the Memory Access Control Policy to objects based on
27
the following: As specified in the definition of the memory access control
28
policy.
29
30
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
31
controlled subjects and controlled objects is allowed:
32
As specified in the definition of the memory access control policy.
33
34
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
35
following additional rules: none.
36
37
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
38
following additional rules: none.
39
40
41
The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified
42
below.
43
44
FMT_MSA.3 Static attribute initialization
45
46
Hierarchical to: No other components.
47
48
Dependencies: FMT_MSA.1 Management of security attributes
49
FMT_SMR.1 security roles
50
41 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1
FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide
2
restrictive1 default values for security attributes that are used to enforce the
3
SFP.
4
5
FMT_MSA.3.2 The TSF shall allow the privilege level to specify alternative initial values to
6
override the default values when an object or information is created.
7
8
9
The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified
10
below:
11
12
FMT_MSA.1 Management of security attributes
13
14
Hierarchical to: No other components.
15
16
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow
17
control]
18
FMT_SMF.1 Specification of management functions
19
FMT_SMR.1 Security roles
20
21
FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability
22
to modify2 the security attributes which are defined in the Memory Access
23
Control Policy3 to the privilege level4.
24
The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as
25
specified below:
26
27
FMT_SMF.1 Specification of management functions
28
29
Hierarchical to: No other components
30
31
Dependencies: No dependencies
32
33
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
34
functions: The privilege level shall be able to access the configuration
35
registers of the MPU.
36
37
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]
42 6.2
2025-07-18
Security Target Lite
M9905 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
3
accordance with a specified algorithm and with a cryptographic key of specified sizes. The specified
4
algorithm and cryptographic key sizes can be based on an assigned standard; dependencies are
5
discussed in Section 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
160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are numerous
15
other curve types, being also secure in terms of side channel attacks on this TOE, which the user can
16
optionally add in the 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)”
20
as 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
30
specified cryptographic algorithm Triple Data Encryption Standard (3DES)
31
in Electronic Codebook Mode (ECB) and in the Cipher Block Chaining Mode
32
(CBC) and cryptographic key sizes of 2 x 56 or 3 x 56 bit that meet the
33
following: [N38A], [N867]
34
35
36
7.6.2 AES Operation
37
The AES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)”
38
as specified below.
39
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.
43 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1
FCS_COP.1/AES Cryptographic operation
2
Hierarchical to: No other components.
3
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
4
FDP_ITC.2 Import of user data with security attributes, or
5
FCS_CKM.1 Cryptographic key generation or
6
FCS_CKM.5 Cryptographic key derivation]
7
FCS_CKM.6 Timing and event of cryptographic key destruction
8
FCS_COP.1.1/AES The TSF shall perform encryption and decryption in accordance with a
9
specified cryptographic algorithm: Advanced Encryption Standard (AES) in
10
Electronic Codebook Mode (ECB) and in the Cipher Block Chaining
11
Mode (CBC) and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet
12
the following: [N197], [N38A]
13
14
7.6.3 Elliptic Curve DSA (ECDSA) operation
15
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation
16
(FCS_COP.1)” as specified below.
17
18
FCS_COP.1/ECDSA Cryptographic operation
19
Hierarchical to: No other components.
20
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
21
FDP_ITC.2 Import of user data with security attributes, or
22
FCS_CKM.1 Cryptographic key generation or
23
FCS_CKM.5 Cryptographic key derivation]
24
FCS_CKM.6 Timing and event of cryptographic key destruction
25
FCS_COP.1.1/ECDSA The TSF shall perform signature generation in
26
accordance with a specified cryptographic algorithm ECDSA and cryptographic
27
key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that
28
meet the following standard:
29
30
Signature Generation:
31
According to section 7.3 in ANSI X9.62 – 2005
32
Not implemented is step d) and e) thereof.
33
The output of step e) has to be provided as input to our function by
34
the caller.
35
Deviation of step c) and f):
36
The jumps to step a) were substituted by a return of
37
the function with an error code, the jumps are emulated by another
38
call to our function.
39
40
41
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
42
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
43
SFR is not applicable.
44
44 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
1
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
2
applicable.
3
4
7.6.4 Elliptic Curve (EC) key generation
5
The key generation for the EC shall meet the requirement “Cryptographic key generation
6
(FCS_CKM.1)”
7
FCS_CKM.1/EC Cryptographic key generation
8
9
Hierarchical to: No other components.
10
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
11
FCS_CKM.5 Cryptographic key derivation, or
12
FCS_COP.1 Cryptographic operation]
13
[FCS_RBG.1 Random bit generation, or
14
FCS_RNG.1 Generation of random numbers]
15
FCS_CKM.6 Timing and event of cryptographic key destruction
16
17
FCS_CKM.1.1/EC The TSF shall generate cryptographic keys in accordance with a specified
18
cryptographic key generation algorithm Elliptic Curve EC specified in ANSI
19
X9.62-2005 and specified cryptographic key sizes 160, 163, 192, 224, 233,
20
256, 283, 320, 384, 409, 512 or 521 bits that meet the following:
21
22
ECDSA Key Generation:
23
According to the appendix A4.3 in ANSI X9.62-2005
24
the cofactor h is not supported.
25
26
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
27
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
28
SFR is not applicable.
29
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
30
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
31
applicable.
32
33
7.6.5 Elliptic Curve Diffie-Hellman (ECDH) key agreement
34
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic
35
operation(FCS_COP.1)” as specified below.
36
37
FCS_COP.1/ECDH Cryptographic operation
38
39
Hierarchical to: No other components.
40
41
45 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
1
FDP_ITC.2 Import of user data with security attributes, or
2
FCS_CKM.1 Cryptographic key generation, or
3
FCS_CKM.5 Cryptographic key derivation]
4
FCS_CKM.6 Timing and event of cryptographic key destruction
5
6
FCS_COP.1.1/ECDH The TSF shall perform elliptic curve Diffie-Hellman key agreement in
7
accordance with a specified cryptographic algorithm ECDH and
8
cryptographic key sizes of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409,
9
512 or 521 bits that meet the following:
10
According to section 5.4.1 in ANSI X9.63 – 2001: Unlike section 5.4.1.3 our,
11
implementation not only returns the x-coordinate of the shared secret, but
12
rather the x-coordinate and y-coordinate.
13
14
Note:The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
15
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Other types of
16
elliptic curves can be added by the user during a composite certification process.
17
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
18
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
19
SFR is not applicable.
20
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
21
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
22
applicable.
23
24
7.7 Data Integrity
25
The TOE shall meet the requirement “Stored data integrity monitoring (FDP_SDI.1)” as specified
26
below:
27
28
FDP_SDI.1 Stored data integrity monitoring
29
30
Hierarchical to: No other components
31
32
Dependencies: No dependencies
33
34
FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the TSF
35
for inconsistencies between stored data and corresponding EDC on all
36
objects, based on the following attributes: EDC value for RAM and ROM and
37
ECC value for the SOLID FLASH™ NVM and verification of stored data in the
38
SOLID FLASH™ NVM.
39
40
The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as
41
specified below:
42
43
FDP_SDI.2 Stored data integrity monitoring and action
44
45
Hierarchical to: FDP_SDI.1 stored data integrity monitoring
46
47
Dependencies: No dependencies
48
46 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF
2
for data integrity and one- and/or more-bit-errors on all objects, based on
3
the following attributes: corresponding EDC value for RAM and ROM and
4
error correction ECC for the SOLID FLASH™ NVM.
5
6
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall correct 1 bit errors in
7
the SOLID FLASH™ NVM automatically and inform the user about more bit
8
errors.
9
10
7.8 TOE Security Assurance Requirements
11
The evaluation assurance level is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5. In the
12
following table, the security assurance requirements are given. The augmentation of the
13
assurance components compared to the Protection Profile [PP] is expressed with bold letters.
14
Table 18 Assurance components
15
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]
ASE_OBJ.2 Security objectives in PP [PP]
ASE_REQ.2 Derived security requirements in PP [PP]
47 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
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.
2
In Table 18 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
4
level is 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
7
augmented with ALC_CMS.5 and ALC_TAT.2. The assurance package ALC_CMS.4 is extended to
8
ALC_CMS.5 with aspects regarding the configuration control system for the TOE. The assurance
9
package ALC_TAT.1 is extended to ALC_TAT.2 with aspects regarding the implementation standards
10
for the TOE.
11
Development (ADV_FSP)
12
The refinement from the PP [PP] can be applied even at the chosen assurance level EAL 5
13
augmented with ADV_FSP.5, ADV_TDS.4 and ADV_INT.2.
14
For details of the refinement see PP [PP].
15
Tests (ATE_DPT.3)
16
The refinement from the PP [PP] can be applied even at the chosen assurance level EAL 5
17
augmented with ATE_DPT.3. The assurance package ATE_DPT.2 is augmented to ATE_DPT.3
18
relating to the requirements of the assurance level EAL 5. The refinement is not touched.
19
20
7.9 Security Requirements Rationale
21
7.9.1 Rationale for the Security Functional Requirements
22
The security functional requirements rationale of the TOE are defined and described in PP [PP]
23
section 6.3 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1,
24
FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1 and FAU_SAS.1.
25
The security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3,
26
FMT_SMF.1, FCS_COP.1, FCS_CKM.1, FDP_SDI.1 and FDP_SDI.2 are defined in the following
27
description:
28
29
48 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Table 19 Rational for additional SFR in the ST
1
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
O.Malfunction FDP_SDI.1
FDP_SDI.2
2
The table above gives an overview, how the security functional requirements are combined to meet
3
the security objectives. The detailed justification is given in the following:
4
The justification related to the security objective “Additional Specific Security Functionality
5
(O.Add-Functions)” is as follows:
6
The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly requires
7
those functions to be implemented which are demanded by O.Add-Functions. FCS_CKM.1/EC
8
supports the generation of EC keys needed for these cryptographic operations. Therefore,
9
FCS_COP.1/ECDSA, FCS_COP.1/ECDH and FCS_CKM/EC are suitable to meet the security objective.
10
The use of the supporting Base library has no impact on any security functional requirement nor
11
does its use generate additional requirements.
12
The security functional requirements required to meet the security objectives O.Leak-Inherent,
13
O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement
14
the specific security functionality. However, key-dependent functions could be implemented in the
15
Smartcard Embedded Software.
16
The usage of cryptographic algorithms requires the use of appropriate keys. Otherwise, these
17
cryptographic functions do not provide security. The keys have to be unique with a very high
18
probability, and must have a certain cryptographic strength etc. In case of a key import into the TOE
19
(which is usually after TOE delivery) it has to be ensured that quality and confidentiality are
20
maintained. Keys for 3DES and AES are provided by the environment, the keys for EC algorithms
21
can be provided either by the TOE or the environment.
22
In this ST the objectives for the environment OE.Plat-Appl and OE.Resp-Appl have been clarified.
23
The Smartcard Embedded Software defines the use of the cryptographic functions FCS_COP.1
24
provided by the TOE. The requirements for the environment FDP_ITC.1, FDP_ITC.2, FCS_CKM.1 and
25
FCS_CKM.6 support an appropriate key management. These security requirements are suitable to
26
meet OE.Resp-Appl.
27
The justification of the security objective and the additional requirements (both for the TOE and its
28
environment) show that they do not contradict the rationale already given in the Protection Profile
29
for the assumptions, policy and threats defined there.
30
49 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The security functional component Subset TOE security testing (FPT_TST.2) has been newly
1
created (Common Criteria Part 2 extended). This component allows that particular parts of the
2
security mechanisms and functions provided by the TOE can be tested after TOE Delivery. This
3
security functional component is used instead of the functional component FPT_TST.1 from
4
Common Criteria Part 2. For the user it is important to know which security functions or
5
mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly
6
specify the security functions being tested. In addition, FPT_TST.1 requires verification of the
7
integrity of TSF data and stored TSF executable code which might violate the security policy.
8
The tested security enforcing functions are SF_DPM Device Phase Management and SF_PMA
9
Protection against modifying attacks.
10
The security functional requirement FPT_TST.2 will detect attempts to conduce a physical
11
manipulation on the monitoring functions of the TOE. The objective of FPT_TST.2 is O.Phys-
12
Manipulation. The physical manipulation will be tried to overcome security enforcing functions.
13
The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security
14
Function Policy (SFP) “Memory Access Control Policy” exactly require the implementation of an
15
area based memory access control as required by O.Mem-Access. The related TOE security
16
functional requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1 and FMT_SMF.1 cover this
17
security objective. The implementation of these functional requirements is represented by the
18
dedicated privilege level concept.
19
The justification of the security objective and the additional requirements show that they do not
20
contradict to the rationale already given in the Protection Profile for the assumptions, policy and
21
threats defined there. Moreover, these additional security functional requirements cover the
22
requirements by [CC-2] user data protection of chapter 11 which are not refined by the PP [PP].
23
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
24
functions are used as specified and that the User Data processed by these functions are protected as
25
defined for the application context. The TOE only provides the tool to implement the policy defined
26
in the context of the application.
27
The justification related to the security objective “Protection against Malfunction due to
28
Environmental Stress (O.Malfunction)” is as follows:
29
The security functional requirement “Stored data integrity monitoring (FDP_SDI.1)” requires the
30
implementation of an Error Detection (EDC) algorithm which detects integrity errors of the data
31
stored in RAM, ROM and SOLID FLASH™ NVM (in the SOLID FLASH™ NVM more bit errors are
32
detected). By this the malfunction of the TOE using corrupt data is prevented. Therefore FDP_SDI.1
33
is suitable to meet the security objective.
34
The security functional requirement “Stored data integrity monitoring and action (FDP_SDI.2)”
35
requires the implementation of an integrity observation and correction which is implemented by
36
the Error Detection (EDC) and Error Correction (ECC) measures. The EDC is present in RAM and
37
ROM of the TOE while the ECC is realized in the SOLID FLASH™ NVM. These measures detect and
38
inform about one and more bit errors. In case of the SOLID FLASH™ NVM 1-bit errors of the data
39
are corrected automatically. By the ECC mechanisms it is prevented that the TOE uses corrupt data.
40
Therefore FDP_SDI.2 is suitable to meet the security objective.
41
42
7.9.1.1 Dependencies of Security Functional Requirements
43
The dependencies of security functional requirements are defined and described in PP [PP] section
44
6.3.2 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1,
45
FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1 and FAU_SAS.1.
46
50 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The dependence of security functional requirements for the security functional requirements
1
FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1,
2
FDP_SDI.1 and FDP_SDI.2 are defined in the following description.
3
4
Table 20 Dependency for cryptographic operation requirement
5
6
Comment:
7
The security functional requirement “Cryptographic operation (FCS_COP.1)” met by the TOE, has
8
the following dependencies:
9
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
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
FDP_SDI.1 None N/A
FDP_SDI.2 None N/A
51 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
 FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.5
1
 FCS_CKM.6
2
The security functional requirement “Cryptographic key management (FCS_CKM.1)” met by TOE,
3
has the following dependencies:
4
 FCS_CKM.2 or FCS_CKM.5 or FCS_COP.1
5
 FCS_RBG.1 or FCS_RNG.1
6
 FCS_CKM.6
7
These requirements all address the appropriate management of cryptographic keys used by the
8
specified cryptographic function and are not part of the PP [PP]. Most requirements concerning key
9
management shall be fulfilled by the environment since the Smartcard Embedded Software is
10
designed for a specific application context and uses the cryptographic functions provided by the
11
TOE.
12
For the security functional requirement FCS_COP.1/DES, FCS_COP.1/AES, the respective
13
dependencies FCS_CKM.6 and FCS_CKM.1, FCS_CKM.5 or FDP_ITC.1 or FDP_ITC.2 have to be fulfilled
14
by the environment.
15
For the security functional requirement FCS_COP.1/ECDSA, and FCS_COP.1/ECDH, the respective
16
dependency FCS_CKM.6 has to be fulfilled by the environment.
17
The security functional requirement FCS_CKM.6 has to be fulfilled by the environment.
18
The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is
19
considered to be satisfied because the access control specified for the intended TOE is not role-
20
based but enforced for each subject. Therefore, there is no need to identify roles in form of a
21
security functional requirement FMT_SMR.1.
22
End of comment.
23
24
7.9.2 Rationale of the Assurance Requirements
25
The chosen assurance level EAL5 and the augmentation with the requirements ALC_DVS.2 and
26
AVA_VAN.5 were chosen in order to meet the assurance expectations explained in the following
27
paragraphs. In Table 18 the different assurance levels are shown as well as the augmentations. The
28
augmentations are in compliance with the Protection Profile.
29
An assurance level EAL5 with the augmentations ALC_DVS.2 and AVA_VAN.5 are required for this
30
type of TOE since it is intended to defend against highly sophisticated attacks without protective
31
environment. This evaluation assurance package was selected to permit a developer to gain
32
maximum assurance from positive security engineering based on good commercial practices. In
33
order to provide a meaningful level of assurance that the TOE provides an adequate level of defence
34
against such attacks, the evaluators should have access to all information regarding the TOE
35
including the TSF internals, the low level design and source code including the testing of the
36
modular design. Additionally the mandatory technical document “Application of Attack Potential to
37
Smartcards” [JIL] shall be taken as a basis for the vulnerability analysis of the TOE.
38
39
ALC_DVS.2 Sufficiency of security measures
40
Development security is concerned with physical, procedural, personnel and other technical
41
measures that may be used in the development environment to protect the TOE.
42
52 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
In the particular case of a Security IC the TOE is developed and produced within a complex and
1
distributed industrial process which must especially be protected. Details about the
2
implementation, (e.g. from design, test and development tools as well as Initialization Data) may
3
make such attacks easier. Therefore, in the case of a Security IC, maintaining the confidentiality of
4
the design is very important.
5
This assurance component is a higher hierarchical component to EAL5 (which only requires
6
ALC_DVS.1). ALC_DVS.2 has no dependencies.
7
8
AVA_VAN.5 Advanced methodical vulnerability analysis
9
Due to the intended use of the TOE, it must be shown to be highly resistant to penetration attacks.
10
This assurance requirement is achieved by the AVA_VAN.5 component.
11
Independent vulnerability analysis is based on highly detailed technical information. The main
12
intent of the evaluator analysis is to determine that the TOE is resistant to penetration attacks
13
performed by an attacker possessing high attack potential.
14
AVA_VAN.5 has dependencies to ADV_ARC.1 “Security architecture description”, ADV_FSP.4
15
“Complete functional specification”, ADV_TDS.3 “Basic modular design”, ADV_IMP.1
16
“Implementation representation of the TSF”, AGD_OPE.1 “Operational user guidance”, and
17
ATE_DPT.1 “Testing: basic design.
18
All these dependencies are satisfied by EAL5.
19
It has to be assumed that attackers with high attack potential try to attack Security ICs like smart
20
cards used for digital signature applications or payment systems. Therefore, specifically AVA_VAN.5
21
was chosen in order to assure that even these attackers cannot successfully attack the TOE.
22
23
53 6.2
2025-07-18
Security Target Lite
M9905 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
2
and the relation to the security functional requirements is shown.
3
The TOE is equipped with the following Security Features to meet the security functional
4
requirements:
5
 SF_DPM Device Phase Management
6
 SF_PS Protection against Snooping
7
 SF_PMA Protection against Modification Attacks
8
 SF_PLA Protection against Logical Attacks
9
 SF_CS Cryptographic Support
10
11
The following description of the Security Features is a complete representation of the TSF.
12
8.1 SF_DPM: Device Phase Management
13
The life cycle of the TOE is split-up in several phases. Chip development and production (phase 2, 3,
14
4) and final use (phase 4-7) is a rough split-up from TOE point of view. These phases are
15
implemented in the TOE as test mode (phase 3) and user mode (phase 4-7).
16
In addition, a chip identification mode exists which is active in all phases. The chip identification
17
data (O.Identification) is stored in a in the not changeable configuration page area and non-volatile
18
memory. In the same area further TOE configuration data is stored. In addition, user initialization
19
data can be stored in the non-volatile memory during the production phase as well. During this first
20
data programming, the TOE is still in the secure environment and in Test Mode.
21
The covered security functional requirement is FAU_SAS.1 “Audit storage”.
22
During start-up of the TOE the decision for one of the operation modes is taken dependent on phase
23
identifiers. The decision of accessing a certain mode is defined as phase entry protection. The
24
phases follow also a defined and protected sequence. The sequence of the phases is protected by
25
means of authentication.
26
The covered security functional requirements are FMT_LIM.1 “Limited capabilities” and FMT_LIM.2
27
“Limited availability”.
28
During the production phase (phase 3 and 4) or after the delivery to the customer (phase 5 or
29
phase 6), the TOE provides the possibility to download a user specific encryption key and user code
30
and data into the empty (erased) SOLID FLASH™ NVM memory area as specified by the associated
31
control information of the Flash Loader software. After finishing the load operation, the Flash
32
Loader can be permanently deactivated, so that no further load operation with the Flash Loader is
33
possible. These procedures are defined as phase operation limitation.
34
The covered security functional requirement is FMT_LIM.2 “Limited availability”.
35
During operation within a phase the accesses to memories are granted by the MPU controlled
36
access rights and related levels.
37
The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1
38
“Security attribute-based access control” and FMT_MSA.1 “Management of security attributes”.
39
In addition, during each start-up of the TOE the address ranges and access rights are initialized by
40
the Boot Software (BOS) with predefined values.
41
The covered security functional requirement is FMT_MSA.3 “Static attribute initialisation”.
42
54 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The TOE clearly defines access rights and levels in conjunction with the appropriate key
1
management in dependency of the firmware or software to be executed.
2
The covered security functional requirement is FMT_SMF.1 “Specification of Management
3
functions”.
4
Each operation phase is protected by means of authentication and encryption.
5
The covered security functional requirements are FPT_ITT.1 “Basic internal TSF data transfer
6
protection” and FDP_IFC.1 “Subset information flow control”. If any comparison of the
7
authentication code fails a direct security reset is performed. The covered security functional
8
requirements is FPT_FLS.1 (”Failure with preservation of secure state”).
9
The SF_DPM “Device Phase Management” covers the security functional requirements FPT_FLS.1,
10
FAU_SAS.1, FMT_LIM.1, FMT_LIM.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1,
11
FPT_ITT.1 and FDP_IFC.1.
12
13
8.2 SF_PS: Protection against Snooping
14
Several mechanisms protect the TOE against snooping the design or the user data during operation
15
and even if it is out of operation (power down).
16
The entire design is kept in a non standard way to prevent attacks using standard analysis methods.
17
Important parts of the chip are especially designed to counter leakage or side channel attacks like
18
DPA/SPA or EMA/DEMA. Therefore, even the physical data gaining is difficult to perform, since
19
timing and current consumption is independent of the processed data. In the design a number of
20
components are automatically synthesized and mixed up to disguise an attacker and to make an
21
analysis more difficult.
22
The covered security functional requirement is FPT_PHP.3 “Resistance to physical attack”.
23
A further protective design method used is secure wiring. All security critical wires have been
24
identified and protected by special routing measures against probing. Additionally the wires are
25
embedded into shield lines and used as normal signal lines for operation of the chip to prevent
26
successful probing. This measurement is called “security optimized wiring”.
27
The covered security functional requirements are FPT_PHP.3 “Resistance to physical attack”,
28
FPT_ITT.1 “Basic internal TSF data transfer protection”, FPT_FLS.1 “Failure with preservation of
29
secure state” and FDP_ITT.1 “Basic internal transfer protection”.
30
All contents of the memories RAM, ROM and SOLID FLASH™ NVM of the TOE are encrypted on chip
31
to protect them against data analysis. In addition the data transferred over the memory bus to and
32
from (bi-directional encryption) the CPU, Co-processor (Crypto2304T and SCP), the special SFRs
33
and the peripheral devices (RNG and Timer) are transported encrypted with an automatically
34
dynamic key change.
35
The encryption of the memory content is done by the MED using a proprietary cryptographic
36
algorithm and a complex key management providing protection against cryptographic analysis
37
attacks. This means that the SOLID FLASH™ NVM, RAM, ROM and the bus are encrypted with
38
module dedicated and dynamic keys. The only key remaining static over the product life cycle is the
39
specific ROM key changing from mask to mask.
40
All security relevant transfer of addresses or data via the peripheral bus is dynamically masked and
41
thus protected against readout and analysis.
42
The function Trash Register Writes can be activated by the user to hide the fact if a register has
43
been written.
44
The covered security functional requirements are FDP_IFC.1 “Subset information flow control“,
45
FPT_PHP.3 “Resistance to physical attack”, FPT_ITT.1 “Basic internal TSF data transfer protection,
46
FPT_FLS.1 “Failure with preservation of secure state” and FDP_ITT.1 “Basic internal transfer
47
protection”.
48
55 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
1
The SF_PS “Protection against Snooping” covers the security functional requirements FPT_PHP.3,
2
FDP_IFC.1, FPT_ITT.1, FPT_FLS.1 and FDP_ITT.1.
3
8.3 SF_PMA: Protection against Modifying Attacks
4
The TOE is equipped with an error detection code (EDC) for protecting RAM and ROM and an ECC,
5
which is realized in the SOLID FLASH™ NVM. Thus introduced failures are securely detected and, in
6
terms of single bit errors in the SOLID FLASH™ NVM also automatically corrected (FDP_SDI.2). For
7
SOLID FLASH™ NVM in case of more than one bit errors and for RAM in case of any bit errors
8
detected, a security alarm is triggered.
9
In order to prevent accidental bit faults during production in the ROM, over the data stored in ROM
10
an EDC value is calculated (FDP_SDI.1).
11
The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance“, FDP_PHP.3
12
“Resistance to physical attack“, FDP_SDI.1 “Stored data integrity monitoring” and FDP_SDI.2 “Stored
13
data integrity monitoring and action”.
14
If a user tears the card resulting in a power off situation during an SOLID FLASH™ NVM
15
programming operation or if other perturbation is applied, no data or content loss occurs and the
16
TOE restarts power on. The NVM tearing save write functionality covers FDP_SDI.1 “Stored data
17
integrity monitoring” as the new data to be programmed are checked for integrity and correct
18
programming before the page with the old data becomes valid.
19
20
The covered security functional requirement are FPT_PHP.3 “Resistance to physical attack“, since
21
these measures make it difficult to manipulate the write process of the NVM, FPT_FLS.1 “Failure
22
with preservation of secure state“and FDP_SDI.1 “Stored data integrity monitoring”.
23
In the case that a physical manipulation or a physical probing attack is detected, the processing of
24
the TOE is immediately stopped and the TOE enters a secure state called security reset.
25
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
26
providing the so called “security optimized wiring”.
27
28
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure
29
state”, FPT_PHP.3 “Resistance to physical attack” and FPT_TST.2 “Subset TOE security testing“.
30
As physical effects or manipulative attacks may also address the program flow of the user software,
31
two watchdog timers each with a check point register function are implemented. This feature
32
allows the user to check the correct processing time and the integrity of the program flow of the
33
user software.
34
The Instruction Stream Signature Checking (ISS) calculates a hash about all executed instructions
35
and automatically checks the correctness of this hash value. If the code execution follows an illegal
36
path an alarm is triggered.
37
Another measure against modifying and perturbation respectively differential fault attacks (DFA) is
38
the implementation of backward calculation in the SCP. By this induced errors are discovered.
39
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure
40
state”, FDP_IFC.1 “Subset information flow control”, FPT_ITT.1 “Basic internal transfer protection”,
41
FDP_ITT.1 “Basic internal transfer protection” and FPT_PHP.3 “Resistance to physical attack”.
42
56 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
During start up, the TOE performs various configurations and subsystem tests. After the TOE
1
startup has finished, the operating system or application can call the User Mode Security Life
2
Control (UMSLC) test provided by the Resource Management System. The UMSLC checks the alarm
3
lines and/or the different security functions and sensors for correct operation. The test can be
4
triggered by user software during normal operation. As attempts to modify the security features
5
will be detected from the test, the covered security functional requirement is FPT_TST.2 “Subset
6
TOE security testing“.
7
The correct function of the TOE is only given in the specified range of the environmental operating
8
parameters. To prevent an attack exploiting that circumstance the TOE is equipped with a
9
temperature sensor, glitch sensor and backside light detection. The TOE falls into the defined
10
secure state in case of a specified range violation. The defined secure state causes the chip internal
11
reset process. Note that the specified range checking can only work when the TOE is running and
12
can not prevent reverse engineering.
13
The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance” and
14
FPT_FLS.1 “Failure with preservation of secure state“.
15
The SF_PMA “Protection against Modifying Attacks” covers the security functional requirements
16
FPT_PHP.3, FDP_IFC.1, FPT_ITT.1, FDP_ITT.1, FPT_TST.2, FDP_SDI.1, FDP_SDI.2, FRU_FLT.2 and
17
FPT_FLS.1.
18
19
8.4 SF_PLA: Protection against Logical Attacks
20
The memory model of the TOE provides two distinct, independent levels called the privileged and
21
non-privilege level and the possibility to define up to eight memory regions with different access
22
rights enforced by the Management Protection Unit (MPU). This gives the user software the
23
possibility to define different access rights for the regions 0 to 7 for privilege or non-privilege level.
24
In the case of an access violation the MPU will trigger a trap. The policy of setting up the MPU and
25
specifying the memory ranges for the regions (0 to 7) is defined from the user software.
26
The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1
27
“Security attribute based access control”, FMT_MSA.1 “Management of security attributes”,
28
FMT_MSA.3 “Static attribute initialisation” and FMT_SMF.1 “Specification of Management
29
functions”.
30
All memories present on the TOE (NVM, ROM, RAM) are encrypted using individual keys assigned
31
by complex key management. In case of security critical error a security alarm is generated and the
32
TOE ends up in a secure state.
33
The covered security functional requirements are FDP_ACF.1 “Security attribute based access
34
control” and FPT_FLS.1 “Failure with preservation of secure state”.
35
The SF_PLA “Protection against Logical Attacks” covers the security functional requirements
36
FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FPT_FLS.1 and FMT_SMF.1.
37
38
8.5 SF_CS: Cryptographic Support
39
The TOE is equipped an asymmetric and a symmetric hardware accelerators to support the
40
standard symmetric and asymmetric cryptographic operations. This security function is introduced
41
to include the cryptographic operation in the scope of the evaluation as the cryptographic function
42
respectively mathematic algorithm itself is not used from the TOE security policy. The components
43
are a co-processor supporting the DES and AES algorithms and a co-processor and software
44
modules to support EC signature generation, ECDH key agreement and EC public key calculation
45
and testing. Additionally the TOE is equipped with a True Random Number Generator for the
46
generation of random numbers.
47
57 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
8.5.1 3DES encryption
1
The TOE supports the encryption and decryption in accordance with the specified cryptographic
2
algorithm Triple Data Encryption Standard (3DES) in the Electronic Codebook Mode (ECB), Cipher
3
Block Chaining Mode (CBC) and with cryptographic key sizes of 112 and 168 bit meeting the
4
standard: [N867], [N38A], [N38B].
5
The covered security functional requirements are FCS_COP.1/DES.
6
7
8.5.2 AES encryption
8
The TSF supports the encryption and decryption in accordance with the specified cryptographic
9
algorithm Advanced Encryption Standard (AES) ) in the Electronic Codebook Mode (ECB), Cipher
10
Block Chaining Mode (CBC) and cryptographic key sizes of 128 bit or 192 bit or 256 bit according
11
to the standard: [N197], [N38A], [N38B].
12
The covered security functional requirement is FCS_COP.1/AES.
13
8.5.1 Elliptic Curves
14
The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
15
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there exist
16
numerous other curve types, being also secure in terms of side channel attacks on this TOE,
17
which can the user optionally add in the composition certification process.
18
19
8.5.1.1 Signature Generation
20
The TSF shall perform signature generation in accordance with a specified cryptographic algorithm
21
ECDSA and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521
22
bits that meet the following standard:
23
24
 According to section 7.3 in ANSI X9.62 – 2005:
25
 Not implemented is step d) and e) thereof.
26
 The output of step e) has to be provided as input to our function by the caller.
27
 Deviation of step c) and f):
28
The jumps to step a) were substituted by a return of the function with an error code, the
29
jumps are emulated by another call to our function.
30
31
The covered security functional requirement is FCS_COP.1/ECDSA.
32
8.5.1.2 Asymmetric Key Generation
33
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
34
generation algorithm Elliptic Curve EC specified in ANSI X9.62-1998 and specified cryptographic
35
key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following
36
standard:
37
38
ECDSA Key Generation:
39
 According to the appendix A4.3 in ANSI X9.62-2005 the cofactor h is not supported.
40
41
58 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The covered security functional requirement is FCS_CKM.1/EC.
1
8.5.1.3 Asymmetric Key Agreement
2
The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance with a specified
3
cryptographic algorithm ECDH and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320,
4
384, 409, 512 or 521 bits that meet the following standard:
5
 According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our implementation not
6
only returns the x-coordinate of the shared secret, but rather the x-coordinate and y-
7
coordinate.
8
3.
9
The covered security functional requirement is FCS_COP.1/ECDH.
10
8.5.2 Asymmetric Base Library
11
The asymmetric Base library provides the low level interface to the asymmetric cryptographic
12
coprocessor and has no user available interface. The asymmetric Base library does not provide
13
any security functionality, implements no security mechanism, and does not provide additional
14
specific security functionality. The asymmetric Base library does not cover security functional
15
requirements.
16
17
8.5.3 TRNG
18
Random data is essential for cryptography as well as for security mechanisms. The TOE is equipped
19
with a physical True Random Number Generator (TRNG, FCS_RNG.1). The random data can be used
20
from the Smartcard Embedded Software and is also used from the security features of the TOE, like
21
masking. The TRNG implements also self testing features. The TRNG fulfils the requirements from
22
the functionality class PTG.2 of [6].
23
The covered security functional requirement is FCS_RNG.1 “Quality metric for random numbers”,
24
FPT_PHP.3 “Resistance to physical attack”, FDP_ITT.1 “Basic internal transfer protection”,
25
FPT_ITT.1 “Basic internal TSF data transfer protection, FDP_IFC.1 “Subset information flow
26
control“, FPT_TST.2 “Subset TOE security testing“ and FPT_FLS.1“Failure with preservation of
27
secure state”.
28
29
The SF_CS “Cryptographic Support” covers the security functional requirements FCS_COP.1/DES,
30
FCS_COP.1/AES, FCS_COP.1/ECDSA, FCS_COP.1/ECDH, FCS_CKM.1/EC, FPT_PHP.3, FDP_ITT.1,
31
FPT_ITT.1, FPT_FLS.1 ,FCS_RNG.1 and FDP_IFC.1.
32
8.6 Assignment of Security Functional Requirements to TOE’s Security
33
Functionality
34
The justification and overview of the mapping between security functional requirements (SFR) and
35
the TOE’s security functionality (SF) is given in sections the sections above. The results are shown
36
in Table 21. The security functional requirements are addressed by at least one relating security
37
feature.
38
The various functional requirements are often covered manifold. As described above the
39
requirements ensure that the TOE is checked for correct operating conditions and if a not
40
correctable failure occurs that a stored secure state is achieved, accompanied by data integrity
41
monitoring and actions to maintain the integrity although failures occurred. An overview is given in
42
following table:
43
59 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
Table 21 Mapping of SFR and SF
1
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.1 X
FDP_SDI.2 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
2
3
8.7 Security Requirements are internally Consistent
4
For this chapter the PP [PP] section 6.3.4 can be applied completely.
5
In addition to the discussion in section 6.3 of PP [PP] the security functional requirement
6
FCS_COP.1 is introduced. The security functional requirements required to meet the security
7
objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-
8
Forced also protect the cryptographic algorithms implemented according to the security functional
9
requirement FCS_COP.1. Therefore, these security functional requirements support the secure
10
implementation and operation of FCS_COP.1.
11
As disturbing, manipulating during or forcing the results of the test checking the security functions
12
after TOE delivery, this security functional requirement FPT_TST.2 has to be protected. An attacker
13
could aim to switch off or disturb certain sensors or filters and preserve the detection of his
14
manipulation by blocking the correct operation of FPT_TST.2. The security functional requirements
15
required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
16
Manipulation and O.Leak-Forced also protect the security functional requirement FPT_TST.2.
17
Therefore, the related security functional requirements support the secure implementation and
18
operation of FPT_TST.2.
19
60 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
The requirement FPT_TST.2 allows testing of some security mechanisms by the Smartcard
1
Embedded Software after delivery. In addition, the TOE provides an automated continuous user
2
transparent testing of certain functions.
3
The implemented level concept represents the area based memory access protection enforced by
4
the MPU. As an attacker could attempt to manipulate the privilege level definition as defined and
5
present in the TOE, the functional requirement FDP_ACC.1 and the related other requirements have
6
to be protected themselves. The security functional requirements required to meet the security
7
objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-
8
Forced also protect the area based memory access control function implemented according to the
9
security functional requirement described in the security functional requirement FDP_ACC.1 with
10
reference to the Memory Access Control Policy and details given in FDP_ACF.1. Therefore, those
11
security functional requirements support the secure implementation and operation of FDP_ACF.1
12
with its dependent security functional requirements.
13
The requirement FDP_SDI.2.1 allows detection of integrity errors of data stored in memory.
14
FDP_SDI.2.2 in addition allows correction of one-bit errors or taking further action. Both meet the
15
security objective O.Malfunction. The requirements FRU_FLT.2, FPT_FLS.1, and FDP_ACC.1 which
16
also meet this objective are independent from FDP_SDI.2 since they deal with the observation of the
17
correct operation of the TOE and not with the memory content directly.
18
61 6.2
2025-07-18
Security Target Lite
M9905 with optional ACL Software Libraries
public
9 References
1
[PP] Security IC Platform Protection Profile, Version 1.0, 15.06.2007, BSI-PP-0035
[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] Joint Interpretation Library, Application of Attack Potential to Smartcards, Version
3.2.1, Fabruary 2024
[ERR] M9905 M9906 Errata Sheet, Rev.3.1, 2019-06-05
[AIS31] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS31, Version 3,
2013-05-15, Bundesamt für Sicherheit in der Informationstechnik
[DSS] NIST: FIPS publication 186-4: Digital Signature Standard (DSS), July 2013
[ECC] IETF: RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and
Curve Generation, March 2010, http://www.ietf.org/rfc/rfc5639.txt
[N867] National Institute of Standards and Technology (NIST), Technology Administration,
U.S. Department of Commerce, NIST Special Publication 800-67, Recommendation for
the Triple Data Encryption Algorithm (TDEA) Block Cipher, Revised January 2012,
Revision 1
[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] American National Standard for Financial Services X9.63-2001, Public Key
Cryptograph for the Financial Services Industry: Key Agreement and Key Transport
Using Elliptic Curve Cryptography, November 20, 2001, American National Standards
Institute
62 6.2
2025-07-18
Security Target Lite
M9905 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
2
documented. 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=8f72c8ebdad3c99c59e9d115b284e6245122bb9ab38bd93da247c282c152638
3
ACL v2.09.002 ACL97-Crypto2304T-L90-base.lib:
SHA256=1b93e84247402e585683564ba42859e5f386e9fc4758300946797832300f95c
d
ACL97-Crypto2304T-L90-ecc.lib:
SHA256=6354bada8cd0f395bf212bd56ade39675653a8c2d409673d377da5c150abc13
4
NRG NRGManagement-01.03.0927-M9900.lib
SHA256=95f2ed5f6a3001146c9fef36c539ac2844839af0bacb92e44a2da474e6d5aa8e
NRGReader-01.02.0800-M9900.lib
SHA256=16848631a68b3094e29790ee34bbb95af208a9985c8e111f46849fffc4ef3385
6
63 6.2
2025-07-18
Security Target Lite
M9905 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
64 6.2
2025-07-18
Security Target Lite
M9905 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
65 6.2
2025-07-18
Security Target Lite
M9905 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
66 6.2
2025-07-18
Security Target Lite
M9905 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
6.2 Final version
30
Other Trademarks
All referenced product or service names and trademarks are the property of their respective owners.
ifx1owners.
Edition 2025-07-18
Published by
Infineon Technologies AG
81726 Munich, Germany
© 2025 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 and liabilities of any kind, including
without limitation 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.