Please read the Important Notice and Warnings at the end of this document 4.9
www.infineon.com 2024-09-20
public
Security Target Lite
M9900, M9905, M9906
including optional Software Libraries
1
RSA-EC-SCL-HCL-PSL
2
According to Common Criteria CCv3.1 EAL5 augmented (EAL5+)
3
4
5
6
Version: 4.9
7
Date: 2024-09-20
8
2
Security Target Lite
M9900, M9905, M9906
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..................................................................................................................................... 9
2 Target of Evaluation Introduction.......................................................................................................................13
2.1 Definition of the TOE......................................................................................................................................................13
2.1.1 Major security functions of the TOE..................................................................................................................14
2.1.2 Not part of the TOE and not part of the certification..................................................................................14
2.2 Hardware of the TOE......................................................................................................................................................14
2.2.1 Non-TOE parts of the hardware..........................................................................................................................18
2.3 Firmware of the TOE......................................................................................................................................................18
2.4 Optional software of the TOE .....................................................................................................................................19
2.5 Interfaces of the TOE......................................................................................................................................................20
2.6 Guidance documentation .............................................................................................................................................21
2.7 Forms of delivery.............................................................................................................................................................21
2.8 Production sites ...............................................................................................................................................................22
2.9 TOE Configuration...........................................................................................................................................................22
2.10 TOE initialization with Customer Software..........................................................................................................23
3 Conformance Claims (ASE_CCL)..........................................................................................................................25
3.1 CC Conformance Claim..................................................................................................................................................25
3.2 PP Claim...............................................................................................................................................................................25
3.3 Package Claim ...................................................................................................................................................................25
3.4 Conformance Rationale.................................................................................................................................................26
3.5 Application Notes ............................................................................................................................................................27
4 Security Problem Definition (ASE_SPD)............................................................................................................28
4.1 Threats.................................................................................................................................................................................28
4.1.1 Additional Threat due to TOE specific Functionality .................................................................................28
4.1.2 Assets regarding the Threats................................................................................................................................29
4.2 Organizational Security Policies................................................................................................................................29
4.2.1 Augmented Organizational Security Policy....................................................................................................30
4.3 Assumptions......................................................................................................................................................................31
4.3.1 Augmented Assumptions.......................................................................................................................................32
5 Security objectives (ASE_OBJ)..............................................................................................................................33
5.1 Security objectives for the TOE..................................................................................................................................33
5.2 Security Objectives for the development and operational Environment.................................................34
5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”..............................................................34
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”......................................................................35
5.2.3 Clarification of “Protection during Composite product manufacturing (OE.Process-Sec-IC)”.35
5.3 Security Objectives Rationale.....................................................................................................................................35
6 Extended Component Definition (ASE_ECD) ...................................................................................................37
6.1 “Subset TOE security testing (FPT_TST)”..............................................................................................................37
6.2 Definition of FPT_TST.2 ................................................................................................................................................37
6.3 TSF self test (FPT_TST).................................................................................................................................................38
6.4 Family “Generation of Random Numbers (FCS_RNG)”....................................................................................38
6.5 Definition of FCS_RNG.1................................................................................................................................................38
7 Security Requirements (ASE_REQ).....................................................................................................................40
7.1 TOE Security Functional Requirements.................................................................................................................40
7.1.1 Extended Components FCS_RNG.1 and FAU_SAS.1.....................................................................................41
7.1.1.1 FCS_RNG..................................................................................................................................................................41
7.1.1.2 FAU_SAS..................................................................................................................................................................43
7.1.2 Subset of TOE testing...............................................................................................................................................43
7.2 Memory access control..................................................................................................................................................43
3
Security Target Lite
M9900, M9905, M9906
public
7.2.1 Memory Access Control Policy.............................................................................................................................44
7.3 Support of Cipher Schemes .........................................................................................................................................47
7.3.1 Triple-DES Operation ..............................................................................................................................................47
7.3.2 AES Operation.............................................................................................................................................................50
7.3.3 Rivest-Shamir-Adleman (RSA) operation.......................................................................................................53
7.3.4 Elliptic Curve DSA (ECDSA) operation.............................................................................................................55
7.3.5 Elliptic Curve (EC) key generation.....................................................................................................................55
7.3.6 Elliptic Curve Diffie-Hellman (ECDH) key agreement...............................................................................56
7.3.7 Hash function..............................................................................................................................................................57
7.4 Data Integrity ....................................................................................................................................................................58
7.5 TOE Security Assurance Requirements..................................................................................................................59
7.5.1 Refinements.................................................................................................................................................................60
7.6 Security Requirements Rationale.............................................................................................................................61
7.6.1 Rationale for the Security Functional Requirements.................................................................................61
7.6.1.1 Dependencies of Security Functional Requirements ...........................................................................64
7.6.2 Rationale of the Assurance Requirements......................................................................................................67
8 TOE Summary Specification (ASE_TSS).............................................................................................................69
8.1 SF_DPM: Device Phase Management.......................................................................................................................69
8.2 SF_PS: Protection against Snooping.........................................................................................................................70
8.3 SF_PMA: Protection against Modifying Attacks ..................................................................................................71
8.4 SF_PLA: Protection against Logical Attacks..........................................................................................................72
8.5 SF_CS: Cryptographic Support....................................................................................................................................72
8.5.1 3DES encryption........................................................................................................................................................72
8.5.2 3DES MAC.....................................................................................................................................................................73
8.5.3 AES encryption...........................................................................................................................................................73
8.5.4 AES MAC........................................................................................................................................................................73
8.5.5 RSA ..................................................................................................................................................................................74
8.5.5.1 Encryption, Decryption, Signature Generation and Verification.....................................................74
8.5.6 Elliptic Curves.............................................................................................................................................................74
8.5.6.1 Signature Generation and Verification.......................................................................................................74
8.5.6.2 Asymmetric Key Generation...........................................................................................................................75
8.5.6.3 Asymmetric Key Agreement...........................................................................................................................75
8.5.7 Asymmetric Base Library.......................................................................................................................................75
8.5.8 Symmetric Crypto Library (SCL)........................................................................................................................75
8.5.1 Hash Crypto Library (HCL)...................................................................................................................................75
8.5.2 Platform Support Layer (PSL) .............................................................................................................................76
8.5.3 TRNG...............................................................................................................................................................................76
8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality............................76
8.7 Security Requirements are internally Consistent..............................................................................................77
9 References..................................................................................................................................................................79
10 Appendix.....................................................................................................................................................................81
11 List of Abbreviations...............................................................................................................................................86
12 Glossary.......................................................................................................................................................................88
Revision History...............................................................................................................................................................................89
4
Security Target Lite
M9900, M9905, M9906
public
1 Security Target Introduction (ASE_INT)
1
1.1 Security Target and Target of Evaluation Reference
2
The title of this document is:
3
“Confidential Security Target M9900, M9905, M9906 including optional Software Libraries RSA-
4
EC-SCL-HCL-PSL v4.9, 2024-09-20”.
5
The name of the TOE on the CC certificate is:
6
“ Infineon Technologies Smart Card IC (Security Controller) M9900 A22, M9900 C22, M9900 D22,
7
M9900 G11, M9905 A11, M9906 A11 with optional Software Libraries RSA2048, RSA4096, EC,
8
Base, SCL, HCL, and PSL, and with specific IC dedicated software”
9
The Target of Evaluation (TOE) comprises the Infineon Technologies Smart Card IC (Security
10
Controller) M9900, M9905, M9906 with optional RSA v2.05.005/v2.07.003, EC
11
v2.05.005/v2.07.003, SCL v2.01.011/v2.02.010/v2.04.003, PSL v4.00.09/ v4.00.10/v5.00.06 and
12
HCL v1.01.003 libraries with specific IC dedicated software. The design step is A22,G11, C22, D22
13
for the M9900 and A11 for the M9905 and M9906.
14
The Security Target is based on the Protection Profile “Smartcard IC Platform Protection Profile”
15
[1].
16
The Protection Profile and the Security Target are built in compliance with Common Criteria v3.1
17
([2],[3],[4]) .
18
The ST takes into account all relevant current final interpretations.
19
5
Security Target Lite
M9900, M9905, M9906
public
Table 1 Identification
1
Type Version Date Title/Registration/Explainantion
Security Target
Method of identification is done by version, date and title
Security
Target
4.9 2024-09-
20
Security Target Lite
M9900, M9905, M9906
including optional Software Libraries
RSA-EC-SCL-HCL-PSL
TOE Hardware
Method of identification is done by reading of GCIM
M9900 A22, G11,
C22, D22
See
Remark 1
M9900
with Firmware Identifier 80001141
and Firmware Identifier 80001142
and external Flash-memory (optional)
M9905 A11 M9905
with Firmware Identifier 80001151
and external Flash-memory (optional)
M9906 A11 M9906
with Firmware Identifier 80001150
and external Flash-memory (optional)
Libraries (optional)
Method of identification is done by hash values (shown in confidential ST only)
NRG
Management
01.03.0927 Management of NRG cards
NRG Reader 01.02.0800 NRG reader mode support
ACL 2.05.005 RSA2048
RSA4096
EC
Toolbox
2.07.003 RSA2048
RSA4096
EC
Toolbox
SCL 2.01.011 Symmetric Crypto Library
2.02.010 Symmetric Crypto Library
2.04.003 Symmetric Crypto Library
PSL v4 4.00.09 Platform Support Layer
4.00.10 Platform Support Layer
PSL v5 5.00.06 Platform Support Layer
HCL 1.01.003 Hash Crypto Library
FTL 1.01.0008 Flash Translation Layer
6
Security Target Lite
M9900, M9905, M9906
public
Type Version Date Title/Registration/Explainantion
Hardware Guidance Documentation
Method of identification is done by version, date and title
General
Guidance
Revision
3.0
2019-08-
28
SLE97 M9900 Hardware Reference Manual
Edition
2024-09-20
2020-04-
15
M9900 Security Guidelines User´s Manual
ID070218 2018-02-
07
ARMv7-M Architecture Reference Manual, ARM
DDI 0403E.d (ID070218), 2018, ARM Limited
4.4.2 2020-03-
11
SLE97 Programmer´s Reference Manual
Edition
2014-08-
10a
2014-08-
10
SLE97 / SLC14 Family Production and
Personalization User´s Manual
M9900
Guidance
4.1 2019-09-
24
M9900 Errata Sheet
M9905 /
M9906
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.05.005 2024-08-
26
CL97 Asymmetric Crypto Library for
Crypto@2304T
RSA / ECC / Toolbox, User Interface
2.07.003 2024-08-
26
CL97 Asymmetric Crypto Library for
Crypto@2304T
RSA / ECC / Toolbox, User Interface
SCL Guidance 2.01.011 2016-08-
02
SCL97 Symmetric Crypto Library for SCPv3
DES/AES 32-bit Security Controller User
Interface
2.02.010 2016-12-
09
SCL97 Symmetric Crypto Library for SCPv3
DES/AES 32-bit Security Controller User
Interface
2.04.003 2018-05-
22
SCL97-SCP-v3-L90 Symmetric Crypto Library for
SCP-v3 DES / AES 32-bit Security Controller
PSL v4
Guidance
Update
2020-04-14
2016-08-
04
SLI 97 Family PSL Reference Manual User’s
Manual1
1.6 2018-06-
07
PSL Security Guidelines1
1.1 2016-09-
16
Release Notes PSL v4.00.09
1.1 2018-06-
07
Release Notes PSL v4.00.10
1 This applies to version 4.00.09 and 4.00.10 of the PSL
7
Security Target Lite
M9900, M9905, M9906
public
Type Version Date Title/Registration/Explainantion
PSL v5
Guidance
5.5 2020-04-
09
SLx97 Platform Support Layer Library 32-bit
Security Controller Programmer’s Reference
Manual
2.5 2018-07-
06
SLI97 Security Guidelines PSL V5.00.06
1.0 2018-05-
18
Release Notes PSL v5.00.06
HCL Guidance 1.01.003 2018-05-
22
HCL97-CPU-L90 Hash Crypto Library for CPU
SHA
FTL Guidance 1.0 2012-07-
10
SLE 97 Flash Translation Layer User´s Guidance
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 3.1
Revision 5
2017-04 Security Evaluation
Part 1: CCMB-2017-04-001
Part 2: CCMB-2017-04-002
Part 3: CCMB-2017-04-003
1
This TOE is represented by a number of various products. They all differentiate by different mask
2
sets with slight - neither functional nor security relevant - modifications, various configuration
3
possibilities, done either by Infineon settings during production or, after delivery, by means of
4
blocking at customer premises. Despite these variation possibilities, all products are derived from
5
the same hardware design results, the M9900 A22, the M9900 G11, the M9905 A11 and the M9906
6
A11.
7
The TOE can be identified with the Generic Chip Identification Mode (GCIM). The M-number
8
hardware is identified by the bytes 05 and 06, which are the first two bytes of the chip
9
identification number, having for the M9900 always the hexadecimal value of 0x0007, for the
10
M9905 the value 0x0010 and for the M9906 the value 0x0011, the design step, firmware identifier,
11
mask identifier, temperature range and system frequency are also included in the GCIM.
12
Additionally the customer can read the configuration area as defined in the SLE97 Programmer´s
13
Reference Manual [11].
14
Remark 1:
15
The derivatives of the TOE produced in the factory Dresden with the additional top layer on board
16
(WLP, WLB) are managed with an own design step. These derivatives output a C22 in the GCIM for
17
the WLP derivative and a D22 for the WLB derivative, which is always linked to the A22 design
18
step. The C22 and D22 design step is only outputted at the derivatives with the additional top layer.
19
All other identification options, i.e. the various metal option identifiers of the GCIM remain
20
unchanged.
21
The derivatives of the TOE produced in the factory TSMC coming with the additional top layer on
22
board (WLB) are managed with the same design step. These derivatives output a G11 in the GCIM
23
for WLB derivative. All other identification options, i.e. the various metal option identifiers of the
24
GCIM remain unchanged.
25
8
Security Target Lite
M9900, M9905, M9906
public
All products are identical with respect to module design and layout, but may include further
1
package options require flexibility in design and could also depend on user requirements. In these
2
cases one or more additional metal layer are added on top of one of the TOE mask set. These
3
additional metal layers, it could also be more than one, just reroute the pads. Therefore, this last
4
rerouting on top does not change the function of the TOE itself and is depending on the package
5
only. These top metal layers are flexible in design, could depend also on user requirements and are
6
of course not relevant for the security of the TOE. For these reasons, the metal layers are out the
7
scope of the certification and do not belong to the TOE. Of course, in all cases passivation and
8
isolation coating is applied on top of the last layers carrying wires. Further clear declaration and
9
overview is given in chapter 2.1 Definition of the TOE.
10
Despite all these options and the resulting flexibility, all differences are comparable to the scenario
11
where for example someone takes a piece of wire and reconnects the pads of the TOE using a
12
soldering bolt. This does not change anything on the TOE security or security policy.
13
To each of the TOE relevant optional different mask set variants, an individual value is assigned,
14
which is part of the data output of the Generic Chip Identification Mode (GCIM). By that the various
15
hardware mask sets can be clearly identified and differentiated by the GCIM output. The
16
interpretation of the output GCIM data is clearly explained in the user guidance, Hardware
17
Reference Manual [7].
18
There are no other differences between the mask sets the TOE is produced with, and all these
19
changes have no impact on the TOEs security policies and related functions. Details are explained in
20
the user guidance Hardware Reference Manual [7] and in the Errata Sheet1 [12].
21
In addition to these hardware differences, the M9900, M9905, M9906 allows a maximum of
22
configuration possibilities defined by the customer order following the market needs. A detailed
23
description of the TOE configuration possibilities is given in chapter 2.9 TOE Configuration.
24
25
9
Security Target Lite
M9900, M9905, M9906
public
1.2 Target of Evaluation overview
1
The TOE comprises the Infineon Technologies AG security controller M9900, M9905, M9906 with
2
specific IC dedicated software and optional RSA, EC, SCL, PSL, HCL.
3
The Toolbox and Flash Translation Layer (FTL) libraries are additionally supported software which
4
is out of scope of this certification.
5
The Toolbox library does not provide cryptographic support or additional security functionality as
6
it provides only the following basic long integer arithmetic and modular functions in software,
7
supported by the cryptographic coprocessor: Addition, subtraction, division, multiplication,
8
comparison, reduction, modular addition, modular subtraction, modular multiplication, modular
9
inversion and modular exponentiation. No security relevant policy, mechanism or function is
10
supported. The toolbox library is deemed for software developers as support for simplified
11
implementation of long integer and modular arithmetic operations.
12
The Flash Translation Layer (FTL) is the interface to the external Flash-memory and is provided
13
optional to the customer as a binary link library.
14
The TOE is a member of the Infineon Technologies AG security controller family SLE97 meeting
15
high requirements in terms of performance and security. The SLE97 family has been developed
16
with a modular concept and different memory configurations, sets of peripherals and interfaces as
17
well as different security features to satisfy market requirements. A summary product description
18
is given in this Security Target (ST).
19
The TOE offer all functions that are both required and useful in security systems, and integrated
20
peripherals that are typically needed in chipcard applications, such as information security,
21
identification, access control, GSM and UMTS projects, electronic banking, digital signature and
22
multi-application cards, ID cards, transportation and e-purse applications.
23
The TOE implements a dedicated security 32-bit RISC CPU designed on the basis of the ARMv7_M
24
architecture designed in 90 nm CMOS technology. The integrated peripheral combine enhanced
25
performance and optimized power consumption for a minimized die size to make the SLE97
26
controllers ideal for chipcard applications. The TOE offer a wide range of peripherals, including a
27
UART (using the ISO interface), four timers, two watchdogs, a CRC module, a true RNG (TRNG),
28
coprocessors for symmetric (e.g. DES, AES) and asymmetric (e.g. RSA, EC) cryptographic
29
algorithms. Additionally a range of communication interfaces, such as GPIO, I2C, SWP, USB, SSC/SPI
30
and a NRG interface are offered to provide maximum flexibility in terms of simultaneously
31
communication ability.
32
The TOE provides a real 32-bit CPU-architecture and is compatible to the ARMv7-M instruction set
33
architecture. The major components of the core system are the 32-bit CPU as a variant of the ARM
34
Secure Core SC300, the Cache system, the Memory Protection Unit and the Memory
35
Encryption/Decryption Unit. The TOE implements a full 32-bit addressing with up to 4 GByte linear
36
addressable memory space, a simple scalable memory management concept and a scalable stack
37
size. The flexible memory concept is built on the non volatile memory, respectively SOLID FLASH™
38
NVM1. For the SOLID FLASH™ NVM the Unified Channel Programming (UCP) memory technology is
39
used. Additionally an optional external Flash-memory connected via the SPI interface is available.
40
The TOE provides the low-level firmware components Boot Software (BOS) and Resource
41
Management System (RMS) and the high-level firmware Flash Loader (FL) and NRG software.
42
The NRG software includes the NRG operating system and additionally the optional library
43
Management of NRG cards (version 01.03.0927) and the optional library NRG Reader Mode
44
Support (01.02.0800). The Management of NRG cards provides an API for the management and
45
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.
10
Security Target Lite
M9900, M9905, M9906
public
generation of NRG cards. The optional NRG reader mode support library (01.02.0800) enables an
1
access to external NRG cards.
2
NRG software is not part of the TSF and do not implement any Security Functional Requirement.
3
The RMS firmware providing some functionality via an API to the Smartcard Embedded Software
4
contains for example SOLID FLASH™ NVM service routines and functionality for the tearing save
5
write into the SOLID FLASH™ NVM. The BOS firmware (BOS-V1 and BOS-V2) is used for test
6
purposes during start-up and the FL allows downloading of user software to the NVM during the
7
manufacturing process. The BOS is implemented in a separated Test-ROM being part of the TOE.
8
For the M9900 two different versions of the BOS are provided (BOS-V1 and BOS-V2). The version
9
BOS-V1 (Firmware Identifier 80001141, 80001150, 80001151) executes the UMSLC test during the
10
startup phase; the version BOS-V2 (Firmware Identifier 80001142) does not execute the UMSLC
11
test during the startup phase to short the time duration of the startup phase. The derivate M9906
12
with Firmware Identifier 80001150 includes the feature “hardening” and the derivate M9905 with
13
Firmware Identifier 80001151 includes the features “hardening” and the “Burn-In Test”. The
14
feature “hardening” analyzing a random SOLID FLASHTM NVM page after every regular program
15
operation for written bits that are losing their charge, and, in this very unlikely case, the page is
16
rewritten. The “Burn-In Test” during production is used to stress the chip in a high temperature,
17
high internal voltage and active operation for a certain time and filtering out defect parts to get a
18
low failure rate. The derivatives M9905 and M9906 are qualified for an extended temperature
19
range from -40°C to +105°C.
20
The two cryptographic co-processors serve the need of modern cryptography: The symmetric co-
21
processor (SCP) combines both AES and Triple-DES with dual-key or triple-key hardware
22
acceleration. The Asymmetric Crypto Co-processor, called Crypto2304T in the following, supports
23
RSA-2048 bit (4096-bit with CRT) and Elliptic Curve (EC) cryptography with high performance.
24
A True Random Number Generator (TRNG) specially designed for smart card applications is
25
implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31
26
and produces genuine random numbers which then can be used internally or by the user software.
27
The software part of the TOE consists of the cryptographic libraries RSA and EC and asymmetric
28
Base libraries, the optional Symmetric Crypto Libraries (SCL) and Platform Support Layer (PSL)
29
libraries. If a RSA or EC library is part of the shipment, the corresponding asymmetric Base library
30
is automatically included. If the PSL library v4.00.09 or v4.00.10 is part of the shipment, the RSA,
31
EC, Base libraries v2.05.005 and the SCL library v2.01.011 are automatically included. If the PSL
32
library v5.00.06 is part of the shipment, the RSA, EC, Base libraries v2.07.003, the SCL library
33
v2.04.003 and the HCL library v1.01.003 are automatically included.
34
The RSA library is used to provide a high-level interface to RSA (Rivest, Shamir, Adleman)
35
cryptography implemented on the hardware component Crypto2304T and includes
36
countermeasures against SPA, DPA and DFA attacks. The routines are used for RSA signature
37
verification, RSA signature generation and RSA modulus recalculation.The hardware Crypto2304T
38
unit provides the basic long number calculations (add, subtract, multiply, square with 1100 bit
39
numbers) with high performance. The RSA library is delivered as object code. The RSA library can
40
perform RSA operations from 512 to 4096 bits.
41
The EC library is used to provide a high-level interface to Elliptic Curve cryptography implemented
42
on the hardware component Crypto2304T and includes countermeasures against SPA, DPA and
43
DFA attacks. The routines are used for ECDSA signature generation, ECDSA signature cerification,
44
ECDSA key generation and Elliptic Curve Diffie-Hellman key agreement. The EC library is delivered
45
as object code. The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves
46
with key lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that
47
there are numerous other curve types, being also secure in terms of side channel attacks on this
48
TOE, which can the user optionally add in the composition certification process.
49
11
Security Target Lite
M9900, M9905, M9906
public
The asymmetric Base library provides the low level interface to the asymmetric cryptographic
1
coprocessor and has no user available interface. The asymmetric Base library does not provide any
2
security functionality, implements no security mechanisms and does not contribute to a security
3
functional requirement.
4
The Flash Translation Layer Library provides the interface to the external Flash-memory. The Flash
5
Translation Layer Library does not provide any security functionality, implements no security
6
mechanism, and does not contribute to a security functional requirement.
7
The Symmetric Crypto library (SCL) is used to provide a high level interface to DES/3DES and AES
8
symmetric cryptographic operations. It uses the SCP of the underlying hardware but implements
9
also countermeasures against all known weaknesses of the SCP (e.g. dummy calculations and block
10
repetitions). The symmetric crypto library consists of three C-library files Cipher.lib, AES.lib and
11
DES.lib. Those library files will not be distributed individually. Therefore we call those three library
12
files simply the Symmetric Crypto Library (SCL)
13
14
The Hash Cryptographic Library (HCL) provides the hash functions form the SHA-1 and SHA-2
15
family. The hash functions are hardened against SPA template attacks.
16
The Platform Support Layer (PSL) library is used to provide a standardized interface to the
17
hardware by making use of the RSA, ECC, SCL and HCL libraries. The provided interfaces are
18
syntactically similar to Windows NT device driver calls.
19
To fulfill the high security standards for smartcards today and also in the future, this TOE utilizes an
20
integral security concept comprising countermeasure mechanisms specially designed against
21
possible attack scenarios. The TOE provide a robust set of sensors for the purpose of monitoring
22
proper chip operating conditions and detecting fault attack scenarios. The sensors are
23
complemented with digital error detection mechanisms such as parities, error detection codes and
24
instruction stream signatures. Probing and forcing attacks will be counteracted by the security
25
optimized wiring approach, implemented by an Infineon-specific shielding combined with secure
26
wiring of security critical signals, partly masking of security critical signals and by encryption of all
27
memories inside the chip (RAM, ROM, NVM). A decentralized alarm propagation and system
28
deactivation principle is implemented, further decreasing the risk of manipulating and tampering.
29
Additionally, an online check of the security mechanisms is available by using the User Mode
30
Security Life Control (UMSLC). Side-channel attacks (e.g. Timing Attack, SPA, DPA, EMA) are
31
typically defeated using a combination of hardware and software mechanisms, for this the TOE
32
provides several supporting features e.g. trash register writes and instruction interrupt prevention.
33
The Instruction Stream Signature Checking (ISS) is a powerful countermeasure against fault attacks
34
that try to manipulate the execution sequence of the instruction stream. All executed instructions
35
are hashed in the CPUs signature register and the hardware automatically checks the fitting of the
36
values.
37
In this security target the TOE is described and a summary specification is given. The security
38
environment of the TOE during its different phases of the lifecycle is defined. The assets are
39
identified which have to be protected through the security policy. The threats against these assets
40
are described. The security objectives and the security policy are defined, as well as the security
41
requirements. These security requirements are built up of the security functional requirements as
42
part of the security policy and the security assurance requirements. These are the steps during the
43
evaluation and certification showing that the TOE meets the targeted requirements. In addition, the
44
functionality of the TOE matching the requirements is described.
45
The assets, threats, security objectives and the security functional requirements are defined in this
46
Security Target and in [1] and are referenced here. These requirements build up a minimal
47
standard common for all Smartcards.
48
12
Security Target Lite
M9900, M9905, M9906
public
The security functions are defined here in the security target as property of this specific TOE. Here
1
it is shown how this specific TOE fulfils the requirements for the standard defined in the Protection
2
Profile [1].
3
The user software can be implemented in various options depending on the user’s choice and
4
described in chapter 2.9. Thereby the user software can be implemented the NVM or coming
5
without user software. In the latter case, the user downloads his entire software on his own using
6
the Flash Loader software.
7
8
The TOE uses also Special Function Registers SFR. These SFR registers are used for general
9
purposes and chip configuration. These registers are located in the SOLID FLASH™ NVM as
10
configuration area page.
11
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
12
providing the so called “security optimized wiring”.
13
The TOE with its integrated security features meets the requirements of all smart card applications
14
such as information integrity, access control, mobile telephone and identification, as well as uses in
15
electronic funds transfer and healthcare systems.
16
To sum up, the TOE is a powerful smart card IC with a large amount of memory and special
17
peripheral devices with improved performance, optimized power consumption, at minimal chip
18
size while implementing high security.
19
13
Security Target Lite
M9900, M9905, M9906
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 [1] 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
 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. New configurations can occur at any time depending on the user blocking or by
21
different configurations applied by the manufacturer. In any case the user is able to clearly identify
22
the TOE hardware, its configuration and proof the validity of the certificate independently, meaning
23
without involving the manufacturer. The various blocking options, as well as the means used for the
24
blocking, are done during the manufacturing process or at user premises. Entirely all means of
25
blocking and the the blocking involved firmware respectively software parts, used at Infineon
26
Technologies AG and/or the user premises, are subject of the evaluation. All resulting
27
configurations of a TOE derivative are subject of the certificate. All resulting configurations are
28
either at the predefined limits or within the predefined configuration ranges.
29
One or more additional metal layer may be added on top of one of the TOE mask set. These
30
additional metal layers, it could also be more than one, just reroute the pads. Therefore, this last
31
rerouting on top does not change the function of the TOE itself and is depending on the package
32
only, and are not relevant for the security of the TOE. For these reasons, the metal layers are out the
33
scope of the certification and do not belong to the TOE. Of course, in all cases passivation and
34
isolation coating is applied on top of the last layers carrying wires.
35
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
36
providing the so called “security optimized wiring”.
37
38
The firmware used for the TOE internal testing and TOE operation, the firmware and software parts
39
exclusively used for the blocking, the parts of the firmware and software required for cryptographic
40
support are part of the TOE and therefore part of the certification. The documents as described in
41
chapter 2.6 are supplied as user guidance.
42
The term Smartcard Embedded Software is used in the following for all operating systems and
43
applications stored and executed on the TOE. The TOE is the platform for the Smartcard Embedded
44
Software. The Smartcard Embedded Software itself is not part of the TOE. The TOE does not require
45
any non-TOE hardware/software/firmware.
46
14
Security Target Lite
M9900, M9905, M9906
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 (optional)
11
 Crypto2304T, an asymmetric crypto coprocessor supporting RSA and EC (optional)
12
 Cryptographic libraries for RSA and EC computations (optional)
13
 Cryptographic libraries for DES and AES computations (optional)
14
 Hash library for SHA-1 and SHA-2 hash functions (optional)
15
 A true random number generator, which can be used as a security service to the user and for
16
internal purpose
17

18
2.1.2 Not part of the TOE and not part of the certification
19
Not part of the TOE and not part of the certification are
20
 the Smartcard Embedded Software respectively user software, and
21
 the piece of software running at user premises and collecting the BPU receipts coming from the
22
TOE. This BPU software part is the commercially deemed part of the BPU software, not running
23
on the TOE, but allowing refunding the customer, based on the collected user blocking
24
information. The receipt from each blocked TOE is collected by this software – chip by chip.
25
 The NRG software
26
27
2.2 Hardware of the TOE
28
The hardware part of the TOE (see Figure 2) as defined in [1] is comprised of:
29
Core System
30
 32-bit CPU implementation of ARM Secure Core SC300 based on ARMv7-M Instruction set
31
architecture including the Instruction Stream Signature Checking (ISS)
32
 CACHE for code and data buffering
33
 Memory Encryption/Decryption Unit (MED) and Error Detection Unit
34
 Memory Protection Unit (MPU)
35
 Nested Vectored Interrupt Controller (NVIC)
36
37
Interfaces
38
 Universal Asynchronous Receiver/Transmitter (UART)
39
 Single-Wire Protocol (SWP) with NRG interface
40
 Inter Integrated Circuit (I2C) interface
41
 General Purpose Input Output (GPIO)
42
15
Security Target Lite
M9900, M9905, M9906
public
 Synchronous Serial Communication (SSC) which provides the
1
Serial Peripheral Interface (SPI)
2
 Universal Serial Bus (USB) interface
3
 Standard ISO Interface (PAD)
4
5
Memories
6
 Read-Only Memory (ROM, for internal firmware)
7
 Random Access Memory (RAM)
8
 SOLID FLASH™ NVM memory (NVM)
9
Note that the TOE has implemented a SOLID FLASH™ NVM memory module. Parts of this memory
10
module are configured to work as an EEPROM.
11
12
Peripherals
13
 True Random Number Generator (TRNG)
14
 System Module (SYS)
15
 Clock Unit (CLK)
16
17
Coprocessors
18
 Crypto2304T co-processor for asymmetric algorithms like RSA and EC (Crypto, optional)
19
 Symmetric Crypto co-processor for 3DES and AES Standards (SCP, optional)
20

21
Analog Module (ANA)
22
 Glitch Sensor
23
 Temperature Sensor
24
 Backside Light Detector
25
 User Mode Security Life Control (UMSLC)
26
27
Buses
28
 Memory Bus
29
 Peripheral Bus
30
31
32
16
Security Target Lite
M9900, M9905, M9906
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 (optional)
12
13
Figure 2 Block diagram of the M990X products (TOE parts are filled with light green, interface
14
parts are filled in light blue)
15
16
The TOE consists of smart card ICs (Security Controllers) meeting high requirements in terms of
17
performance and security. They are manufactured by Infineon Technologies AG in a 90 nm CMOS-
18
technology (L90). This TOE is intended to be used in smart cards for particularly security-relevant
19
applications and for its previous use as developing platform for smart card operating systems
20
according to the lifecycle model from [1]
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
The TOE consists of a core system, memories, co-processors, security peripherals, control logic and
25
peripherals. The major components of the core system are the 32-bit CPU (Central Processing Unit),
26
the MPU (Memory Protection Unit), the MED (Memory Encryption/Decryption Unit), the Nested
27
Vectored Interrupt Controller (NVIC), the Instruction Stream Signature Checking (ISS) and the
28
17
Security Target Lite
M9900, M9905, M9906
public
Cache system. The TOE contains the co-processors for RSA/EC (Crypto2304T) and DES/AES (SCP)
1
processing, a CRC module and the peripherals random number generator, four timers and two
2
watchdog timers and several external interface services. All data of the memory block is encrypted,
3
RAM and ROM are equipped with an error detection code (EDC) and the SOLID FLASH™ NVM is
4
equipped in addition with an error correction code (ECC).
5
The memories are connected to the Core with the Memory Bus and the peripherals are connected
6
with the Peripheral Bus.
7
The Analog Modules (ANA) serve for operation within the specified range and manage the alarms.
8
A set of sensors (temperature sensor, backside light detector, glitch sensor) is used to detect
9
excessive deviations from the specified operational range and serve for robustness of the TOE and
10
the UMSLC function can be used to test the alarm lines.
11
The CPU is compatible with the instruction set of the ARMv7_M architecture. Despite its
12
compatibility the CPU implementation is entirely proprietary and not standard.
13
The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED).
14
The memory model of the TOE provides two distinct, independent levels. Additionally up to eight
15
regions can be defined with different access rights controlled by the Memory Protection Unit
16
(MPU). Errors in RAM and ROM are automatically detected (EDC, Error Detection Code), in terms of
17
the SOLID FLASH™ NVM errors are detected and 1-Bit-errors are also corrected (ECC, Error
18
Correction Code).
19
The controller of this TOE stores both code and data in a linear 4-GByte memory space, allowing
20
direct access without the need to swap memory segments in and out of memory using a memory
21
protection unit.
22
Additionally an optional external Flash-memory (EXF) connected via the SSC/GPIO interfaces is
23
available. The data stored in the external Flash-memory are not protected as the external Flash-
24
memory is not part of the security functional requirements (SFR) of the TOE and not in the scope of
25
the evaluation.
26
The CACHE is a high-speed memory-buffer located between the CPU and the (external) main
27
memories holding a copy of some of the memory contents to enable access, which is considerably
28
faster than retrieving the information from the main memory. In addition to its fast access speed,
29
the CACHE also consumes less power than the main memories. The CACHE is equipped with a
30
integrity check 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 permits 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
18
Security Target Lite
M9900, M9905, M9906
public
Two co-processors for cryptographic operations are implemented on the TOE. The Crypto2304T
1
for calculation of asymmetric algorithms like RSA and Elliptic Curve (EC) and the Symmetric
2
Cryptographic Processor (SCP) for dual-key or triple-key triple-DES and AES calculations. These co-
3
processors are especially designed for smart card applications with respect to the security and
4
power consumption. The SCP module computes the complete DES algorithm within a few clock
5
cycles and is especially designed to counter attacks like DPA, EMA and DFA. The Crypto2304T
6
module provides basic functions for the implementation of RSA and EC cryptographic libraries.
7
Note that this TOE can be delivered with both crypto co-processors accessible, or with a blocked
8
SCP or with a blocked Crypto2304T, or with both crypto co-processors blocked. The blocking
9
depends on the customer demands prior to the production of the hardware. No accessibility of the
10
deselected cryptographic co-processors is without impact on any other security policy of the TOE; it
11
is exactly equivalent to the situation where the user decides just not to use the cryptographic co-
12
processors.
13
The cyclic redundancy check (CRC) module is a 16-bit checksum generator, which shall not be used
14
for security-critical data. The TOE includes two timer modules each with two 16-bit general
15
purpose timers. The timer module can be used also as watchdog timer to monitor system operation
16
for possible timeouts and to check the correct order of operation.
17
An Interface Management module, located in the System Module (SYS), provides the TOE with the
18
possibility to maintain two or more data interfaces simultaneously. The TOE is provided with,
19
dependent on the configuration, different peripherals and interfaces as the Universal Serial Bus
20
(USB), the SWP Slave Peripheral (SWP), the Synchronous Serial Communication (SSC), which
21
provides the serial Peripheral Interface (SPI), the GPIO module (GPIO), the Inter-Integrated Cirquit
22
Module (I2C) and the Standard ISO Interface (PAD) to satisfy the different market requirements.
23
2.2.1 Non-TOE parts of the hardware
24
The following parts of the hardware are not part of the certification scope.
25
 Checksum module (CRC)
26
 External Flash-memory (EXF, optional)
27

28
29
2.3 Firmware of the TOE
30
The entire firmware and software of the TOE consists of different parts:
31
The BOS (Boot Software) and the RMS (Resource Management System) compose the TOE firmware
32
stored in the ROM and the patches hereof in the SOLID FLASH™ NVM. All mandatory functions for
33
start-up and internal testing (BOS) are protected by a dedicated hardware firewall. Additionally
34
two levels are provided, the privileged level and the non-privilege level, both are protected by a
35
hardwired Memory Protection Unit (MPU) setting. For the TOE two different versions of the BOS
36
are provided (BOS-V1 and BOS-V2). The version BOS-V1 (Firmware Identifier 80001141,
37
80001150, 80001151) executes the UMSLC test during the startup phase, the version BOS-V2
38
(Firmware Identifier 80001142) does not execute the UMSLC test during the startup phase to
39
shorten the time duration of the startup phase. For the M9906 the BOS-V1 version (Firmware
40
Identifier 80001150) includes the feature “hardening” and for the M9905 the BOS-V1 version
41
(Firmware Identifier 80001151) includes the features “hardening” and the “Burn-In Test”. The
42
feature “hardening” analyzing a random SOLID FLASHTM NVM page after every regular program
43
operation for written bits that are losing their charge, and, in this very unlikely case, the page is
44
rewritten. The “Burn-In Test” during production is used to stress the chip in a high temperature,
45
high internal voltage and active operation for a certain time and filtering out defect parts to get a
46
low failure rate. The derivatives M9905 and M9906 are qualified for an extended temperature
47
19
Security Target Lite
M9900, M9905, M9906
public
range from -40°C to +105°C.
1
The RMS is accessible in privileged level only. The FL (Flash Loader) allows downloading of user
2
software to the NVM during the manufacturing process and can be completely deactivated.
3
4
2.4 Optional software of the TOE
5
6
The optional software part of the TOE consists of the cryptographic libraries RSA and EC and
7
asymmetric Base libreries, the optional SCL, the optional Platform Support Library (PSL).
8
The RSA library is used to provide a high-level interface to the RSA cryptography implemented on
9
the hardware component Crypto2304T and includes countermeasures against SPA, DPA and DFA
10
attacks. The routines are used for the RSA signature verification, the RSA signature generation and
11
the RSA modulus recalculation. The module provides the basic long number calculations (add,
12
subtract, multiply, square with 1100-bit numbers) with high performance.
13
The RSA library is delivered as object code and is integrated in this way into the user software. The
14
RSA library can perform RSA operations from 512 to 4096 bits. Depending on the customer’s
15
choice, the TOE can be delivered with the 4096 code portion or with the 2048 code portion only.
16
The 2048 code portion is included in both.
17
Part of the evaluation are the RSA straight operations with key lengths from 1024 bits to 2048 bits,
18
and the RSA CRT operations with key lengths of 1024 bits to 4096 bits. Note that key lengths below
19
1024 bits are not included in the certificate.
20
The EC library is used to provide a high level interface to Elliptic Curve cryptography and includes
21
countermeasures against SPA, DPA and DFA attacks. The routines are used for ECDSA signature
22
generation, ECDSA signature verification, ECDSA key generation and Elliptic Curve Diffie-Hellman
23
key agreement. The EC library is delivered as object code and integrated in this way into the user
24
software. The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with
25
key lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are
26
numerous other curve types, being also secure in terms of side channel attacks on this TOE, which
27
can the user optionally add in the composition certification process.
28
The Asymmetric Base library provides the low level interface to the asymmetric cryptographic
29
coprocessor for the RSA and ECC cryptographic libraries and has no user available interface. It does
30
not support any security relevant policy or function. The Base, ECC and RSA library can optionally
31
be delivered in different versions:
32
 The version v2.05.005 , which is a dependency for the PSL library v 4.00.09 and v4.00.10,
33
 The version v2.07.003 , which is a dependency for the PSL library v5.00.06.
34

35
The Symmetric Crypto library (SCL) is used to provide a high level interface to DES/3DES and AES
36
symmetric cryptographic operations. It uses the SCP of the underlying hardware but implements
37
also countermeasures against all known weaknesses of the SCP (e.g. dummy calculations). The
38
symmetric crypto library consists of three C-library files Cipher.lib, AES.lib and DES.lib. Those
39
library files will not be distributed individually. Therefore we call those three library files simply
40
the Symmetric Crypto Library (SCL). The SCL library can optionally delivered in different versions
41
 The legacy version v2.01.011 for backward compatibility, which is a dependency for the PSL
42
v4.00.09 and v4.00.10,
43
 The legacy version v2.02.010 for backward compatibility,
44
 The most recent version v2.04.003, which is a dependency for the PSL v5.00.06.
45
46
The Hash Cryptographic Library (HCL) provides interfaces to the SHA-1 and SHA-2 family. The HCL
47
library can optionally delivered in version
48
 v1.01.003, which is a dependency for the PSL v5.00.06.
49
50
20
Security Target Lite
M9900, M9905, M9906
public
The Platform Support Layer (PSL) library is used to provide a standardized interface to the
1
hardware, directly or via the RSA, ECC and SCL library. The provided interfaces are syntactically
2
similar to Windows NT device driver calls. The PSL library can optionally be delivered in different
3
versions
4
 v4.00.09,
5
 v4.00.10,
6
 v5.00.06.
7
8
Table 2 Chip and optional
9
software delivery matrix
10
Chip Waferfab Toplayer Firmware-ID RSA/ECC lib SCL PSL HCL
M9900
A22
Dresden none 80001141 (BOS-
V1) 80001142
(BOS-V2)
2.05.005
2.07.003
2.01.011
2.02.010
2.04.003
4.00.09
4.00.10
5.00.06
1.01.003
M9900
C22
Dresden WLP 80001141 (BOS-
V1) 80001142
(BOS-V2)
2.05.005
2.07.003
2.01.011
2.02.010
2.04.003
4.00.09
4.00.10
5.00.06
1.01.003
M9000
D22
Dresden WLB 80001141 (BOS-
V1) 80001142
(BOS-V2)
2.05.005
2.07.003
2.01.011
2.02.010
2.04.003
4.00.09
4.00.10
5.00.06
1.01.003
M9900
G11
TSMC WLB 80001141 (BOS-
V1) 80001142
(BOS-V2)
2.07.003
n.A. n.A. n.A.
M9905
A11
Dresden none 80001151 (BOS-
V1) 2.05.005
2.07.003
2.01.011
2.02.010
2.04.003
4.00.09
4.00.10
5.00.06
1.01.003
M9906
A11
Dresden none 80001150 (BOS-
V1) 2.05.005
2.07.003
2.01.011
2.02.010
2.04.003
4.00.09
4.00.10
5.00.06
1.01.003
11
2.5 Interfaces of the TOE
12
 The physical interface of the TOE to the external environment is the entire surface of the IC.
13
 The electrical interface of the TOE to the external environment is constituted by the pads of the
14
chip:
15
− The five ISO 7816 pads consist particularly of the contacted RES, I/O, CLK lines and supply
16
lines VCC and GND. The contact based communication is according to ISO 7816/ETSI/EMV.
17
The I2C communication can be driven via the ISO 7816 pads. In this case no other
18
communication using the ISO 7816 pads is possible.
19
− The GPIO interface consists of 4 pads which can be individually configured and combined.
20
21
− Also the I2C and the SSC/SPI communication can be exclusively driven via the GPIO pads. In
22
this case no other communication using the GPIO pads is possible.
23
− The USB interface is build out of two dedicated pads for data communication and two pads
24
used from the ISO 7816 interface supplying power and ground.
25
− The SWP interface is build out of one pad to support the SWP slave functionality.
26
 The data-oriented I/O interface to the TOE is formed by the I/O pad.
27
 The interface to the firmware is constituted by special registers used for hardware configuration
28
and control (Special Function Registers, SFR).
29
21
Security Target Lite
M9900, M9905, M9906
public
 The interface of the TOE to the operating system is constituted on one hand by the RMS routine
1
calls and on the other by the instruction set of the TOE.
2
 The interface of the TOE to the test routines is formed by the BOS test routine call, i.e. entry to
3
test mode (OS-TM entry).
4
 The interface to the RSA calculations is defined by the RSA library (optionally).
5
 The interface to the EC calculations is defined by the EC library (optionally).
6
 The interface to the symmetric crypto operations DES/3DES/AES is defined by the SCL library
7
(optionally).
8
 The interface to the PSL library is defined by the PSL Specification (optionally).
9
2.6 Guidance documentation
10
The guidance documentation is listed in Table 1
11
Finally the certification report may contain an overview of the recommendations to the software
12
developer regarding the secure use of the TOE. These recommendations are also included in the
13
ordinary documentation.
14
2.7 Forms of delivery
15
The TOE can be delivered in form of bare dies, in form of plain wafers, in form of complete modules
16
(wire bond module M4.x, provided as single chip wire bond or as stacked wire bond), or in one of
17
the following an IC cases: MFC5.8 (FCOS), PG-VQFN-8-1, PG-VQFN-32-13 (SMD) and P-M2M4.7-8-1
18
(for M9905 and M9906). The form of delivery does not affect the TOE security and it can be
19
delivered in any form, as long as the processes applied and sites involved have been subject of the
20
appropriate audit.
21
The delivery can therefore be at the end of phase 3 or at the end of phase 4 which can also include
22
pre-personalization steps according to PP [1]. Nevertheless in both cases the TOE is finished and
23
the extended test features are removed. In this document are always both cases mentioned to avoid
24
incorrectness but from the security policy point of view the two cases are identical.
25
The delivery to the software developer (phase 2  phase 1) contains the development package and
26
is delivered in form of documentation as described above, data carriers containing the tools and
27
emulators as development and debugging tool.
28
Part of the software delivery could also be the Flash Loader program, provided by Infineon
29
Technologies, running on the TOE and receiving via the UART interface the transmitted information
30
of the user software to be loaded into the SOLID FLASH™ NVM memory. The download is only
31
possible after successful authentication. The user software can also be downloaded in an encrypted
32
way. In addition, the user can permanently block further use of the Flash Loader. Whether the Flash
33
Loader program is present or not depends on the procurement order.
34
Table 3 TOE deliveries: forms and
35
methods
36
TOE Component Delivered Format Delivery Method Comment
M9900
C11/D11/G11/A22
See text above Postal transfer
in cages
All materials are delivered
to distribution centers in
cages, locked.
M9905 A11/M9906
A11
See text above Postal transfer
in cages
All materials are delivered
to distribution centers in
cages, locked.
All Firmware – – Stored on the delivered
hardware.
22
Security Target Lite
M9900, M9905, M9906
public
TOE Component Delivered Format Delivery Method Comment
All software libraries ARM Library File
(object code)
Secured
download1
–
All User Guidance
documents
Personalized PDF Secured
download
–
1
2
2.8 Production sites
3
The silicon of the design A11, A22, C22 and D22 is produced in Dresden.
4
The silicon of the design G11 is produced at TSMC/Taiwan
5
The delivery measures are described in the ALC_DVS aspect.
6
7
Table 4 Production site in chip
8
identification
9
Production Site Chip Identification
Dresden, Germany byte number 13 (Fab number): 02H
TSMC, Taiwan byte number 13 (Fab number): 0AH
10
11
2.9 TOE Configuration
12
This TOE is represented by various configurations called products, which are all derived from the
13
equal hardware design M9900, M9905 and M9906. The same mask is used to produce different
14
products of the TOE. The first metal mask (called the M1 mask) contains the specific information to
15
identify the TOE.
16
The M9900, M9905 and M9906 product offers different configuration options, which a customer
17
can choose. The mechanism to choose a configuration can be done by the following methods:
18
1. by product selection or dialog-based in Tools,
19
2. via Bill-per-Use (BpU) and Flash Loader (FL),
20
The degree of freedom for configuring the TOE is predefined by Infineon Technologies AG. The list
21
of predefined TOE configurations is given, as an example in Table 5 and in the SLE97 Hardware
22
Reference Manual [7], section 18. Additional the Table 5 gives an overview about the maximum
23
configurable memory and frequency sizes of the TOE.
24
All these possible TOE configurations equal and/or within the specified ranges are covered by the
25
certificate.
26
27
For details about the TOE configurations, please see [ST]
28
29
Beside fix TOE configurations, which can be ordered as usual, this TOE implements optionally the
30
so called Bill-Per-Use (BPU) ability. This solution enables the customer to tailor the product on his
31
own to the required configuration by blocking parts of the chip on demand into the final
32
configuration at his own premises, without further delivery or involving support by Infineon
33
Technology AG. Customers, who are intended to use this feature receiving the TOE in a predefined
34
configuration including the Flash Loader software, enhanced with the BPU blocking software. The
35
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.
23
Security Target Lite
M9900, M9905, M9906
public
blocking information is part of a chip configuration area and can be modified by customers using
1
specific APDUs. Once a final blocking is done, further modifications are disabled.
2
The BPU software part is only present on the products which have been ordered with the BPU
3
option. In all other cases this software is not present on the product.
4
Additionally the user can choose between different firmware BOS versions and optional software
5
libraries.
6
For the M9900 derivative the user can choose the TOE with the BOS firmware in the version BOS-
7
V1 or BOS-V2.
8
The user can choose between one of the management of NRG libraries (version 01.03.0927) and the
9
NRG reader mode support library (01.02.0800) or the user can choose only one of the three
10
libraries. Please note that the NRG libreries are not part of this certification.
11
In the case the TOE is equipped with the External Flash memory the user can choose the Flash
12
Translation Layer (V1.01.0008) library.
13
The hardware of this TOE can be delivered with the following configuration options:
14
 both crypto co-processors accessible
15
 with a blocked SCP
16
 with a blocked Crypto2304T
17
 both crypto co-processors blocked
18
In case the SCP is blocked, no AES and 3DES computation supported by hardware is possible. In the
19
case the Crypto2304T is blocked, no RSA and EC computation supported by hardware is possible.
20
No accessibility of the deselected cryptographic co-processors is without impact on any other
21
security policy of the TOE; it is exactly equivalent to the situation where the user decides just not to
22
use the cryptographic co-processors.
23
The TOE can be delivered with the following optional libraries
24
 RSA
25
 ECC
26
 Asymmetric Base library for RSA and ECC
27
 SCL for AES/DES
28
 PSL
29
30
The libraries of this TOE can be delivered according to the following dependencies:
31
 If the PSL library v4.00.09 or 4.00.10 is delivered, the RSA, EC and Base v2.05.005 libraries as
32
well as the SCL v2.01.011 library are automatically part of it.
33
 If the PSL library v5.00.06 is delivered, the RSA, EC and Base v2.07.003 libraries as well as the
34
SCL v2.04.003 library and the HCL library are automatically part of it.
35
36
In case of deselecting one or several of these libraries the TOE does not provide the respective
37
functionality.
38
39
2.10 TOE initialization with Customer Software
40
Beside the various TOE configurations further possibilities of how the user inputs his software on
41
the TOE are in place. This provides a maximum of flexibility and for this an overview is given in the
42
following table:
43
44
Table 5 Options to implement user
45
software at Infineon
46
production premises
47
1 The user or/and a subcontractor downloads
the software into the SOLID FLASH™ NVM
The Flash Loader can be activated or
reactivated by the user or subcontractor to
24
Security Target Lite
M9900, M9905, M9906
public
memory on his own. Infineon Technologies AG
has not received user software and there are
no user data in the ROM.
download his software in the SOLID FLASH™
NVM memory.
2 The user provides software for the download
into the SOLID FLASH™ NVM memory to
Infineon Technologies AG. The software is
downloaded to the SOLID FLASH™ NVM
memory during chip production. There are no
user data in the ROM.
The Flash Loader is deactivated.
3 The user provides software for the download
into the SOLID FLASH™ NVM memory to
Infineon Technologies AG. The software is
downloaded to the SOLID FLASH™ NVM
memory during chip production. There are no
user data in the ROM
The Flash Loader is blocked afterwards but
can be activated or reactivated by the user or
subcontractor to download his software in the
SOLID FLASH™ NVM memory. Precondition is
that the user has provided an own reactivation
procedure in software prior 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 [7] gives a detailed
5
description of the GCIM data.
6
25
Security Target Lite
M9900, M9905, M9906
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 v3.1 part 1
3
[2], part 2 [3] and part 3 [4].
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 [1].
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 [1]. They are all drawn from Part 3 of the Common Criteria version v3.1.
14
The augmentations of the PP [1] are listed below.
15
16
Table 6 Augmentations of the
17
assurance level of the
18
TOE
19
Assurance Class Assurance
components
Description
Life-cycle
support
ALC_DVS.2 Sufficiency of security measures
Vulnerability
assessment
AVA_VAN.5 Advanced methodical vulnerability analysis
20
3.3 Package Claim
21
This Security Target does not claim conformance to a package of the PP [1].
22
The assurance level for the TOE is EAL5 augmented with the components ALC_DVS.2 and
23
AVA_VAN.5.
24
25
26
1 Bundesamt für Sicherheit in der Informationstechnik (BSI) is the German Federal Office for Information Security
26
Security Target Lite
M9900, M9905, M9906
public
3.4 Conformance Rationale
1
This security target claims strict conformance only to one PP, the PP [1].
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 [1], the security problem definition is enhanced by adding an additional threat, an
12
organization security policy and an augmented assumption. Including these add-ons, the security
13
problem definition of this security target is consistent with the statement of the security problem
14
definition in the PP [1], as the security target claimed strict conformance to the PP [1].
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, and the threat memory access violation , due to specific
19
TOE memory access control functionality, have been added. These add-ons have no impact on the
20
conformance statements regarding CC [2] and PP [1], with following rational:
21
The security target remains conformant to CC [2], claim 482 as the possibility to introduce
22
additional restrictions is given.
23
The security target fulfils the strict conformance claim of the PP [1] due to the application notes 5, 6
24
and 7 which apply here. By those notes the addition of further security functions and security
25
services are covered, even without deriving particular security functionality from a threat but from
26
a policy.
27
Due to additional security functionality, one coming from the cryptographic libraries - O.Add-
28
Functions, the memory access control - O.Mem-Access, and the hash additional security objectives
29
have been introduced. These add-ons have no impact on the conformance statements regarding CC
30
[2] and PP [1], with following rational:
31
The security target remains conformant to CC [2], claim 482 as the possibility to introduce
32
additional restrictions is given.
33
The security target fulfils the strict conformance of the PP [1] due to the application note 9 applying
34
here. This note allows the definition of high-level security goals due to further functions or services
35
provided to the Security IC Embedded Software.
36
Therefore, the security objectives of this security target are consistent with the statement of the
37
security objectives in the PP [1], as the security target claimed strict conformance to the PP [1].
38
39
All security functional requirements defined in the PP [1] are included and completely defined in
40
this ST. The security functional requirements listed in the following are all taken from Common
41
Criteria part 2 [3] and additionally included and completely defined in this ST:
42
27
Security Target Lite
M9900, M9905, M9906
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 [3])
11
 FCS_RNG.1 “Generation of Random Numbers”
12
is included and completely defined in this ST, section 6.
13
All assignments and selections of the security functional requirements are done in the PP [1] and in
14
this security target in section 7.5.
15
The Assurance Requirements of the TOE obtain the Evaluation Assurance Level 5 augmented with
16
the assurance components ALC_DVS.2 and AVA_VAN.5 for the TOE.
17
18
3.5 Application Notes
19
The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the Protection
20
Profile [1] according to “Anwendungshinweise und Interpretationen zum Schema (AIS)” [15].
21
28
Security Target Lite
M9900, M9905, M9906
public
4 Security Problem Definition (ASE_SPD)
1
The content of the PP [1] 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 [1]
7
section 3.2.
8
The threats to security are defined and described in PP [1] section 3.2.
9
Table 7 Threats according PP [1]
10
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
Table 8 Additional threats due to
28
TOE specific functions
29
and augmentations
30
T.Mem-Access Memory Access Violation
31
For details see PP [1] section 3.2.
32
29
Security Target Lite
M9900, M9905, M9906
public
4.1.2 Assets regarding the Threats
1
The primary assets concern the User Data which includes the user data as well as program code
2
(Security IC Embedded Software) stored and in operation and the provided security services. These
3
assets have to be protected while being executed and or processed and on the other hand, when the
4
TOE is not in operation.
5
This leads to four primary assets with its related security concerns:
6
 SC1 Integrity of User Data and of the Security IC Embedded Software (while being
7
executed/processed and while being stored in the TOE’s memories),
8
 SC2 Confidentiality of User Data and of the Security IC Embedded Software (while being
9
processed and while being stored in the TOE’s memories)
10
 SC3 Correct operation of the security services provided by the TOE for the Security IC
11
Embedded Software.
12
 SC4 Continuous availability of random numbers
13
SC4 is an additional security service provided by this TOE which is the availability of random
14
numbers. These random numbers are generated either by a true random number or a deterministic
15
random number generator or by both, when a true random number is used as seed for the
16
deterministic random number generator. Note that the generation of random numbers is a
17
requirement of the PP [1].
18
To be able to protect the listed assets the TOE shall protect its security functionality as well.
19
Therefore critical information about the TOE shall be protected. Critical information includes:
20
 logical design data, physical design data, IC Dedicated Software, and configuration data
21
 Initialisation Data and Pre-personalisation Data, specific development aids, test and
22
characterisation related data, material for software development support, and reticles.
23
The information and material produced and/or processed by the TOE Manufacturer in the TOE
24
development and production environment (Phases 2 up to TOE Delivery) can be grouped as
25
follows:
26
 logical design data,
27
 physical design data,
28
 IC Dedicated Software, Security IC Embedded Software, Initialisation Data and Pre-
29
personalisation Data,
30
 specific development aids,
31
 test and characterisation related data,
32
 material for software development support, and
33
 reticles and products in any form
34
as long as they are generated, stored, or processed by the TOE Manufacturer.
35
For details see PP [1] section 3.1.
36
4.2 Organizational Security Policies
37
The TOE has to be protected during the first phases of their lifecycle (phases 2 up to TOE delivery
38
which can be after phase 3 or phase 4). Later on each variant of the TOE has to protect itself. The
39
organizational security policy covers this aspect.
40
P.Process-TOE Protection during TOE Development and Production
41
An accurate identification must be established for the TOE. This requires that each instantiation of
42
the TOE carries this unique identification.
43
30
Security Target Lite
M9900, M9905, M9906
public
The organizational security policies are defined and described in PP [1] section 3.3. Due to the
1
augmentations of PP [1] an additional policy is introduced and described in the next chapter.
2
Table 9 Organizational Security
3
Policies according PP [1]
4
P.Process-TOE Protection during TOE Development and Production
4.2.1 Augmented Organizational Security Policy
5
Due to the augmentations of the PP [1] an additional policy is introduced.
6
The TOE provides specific security functionality, which can be used by the Smartcard Embedded
7
Software. In the following specific security functionality is listed which is not derived from threats
8
identified for the TOE’s environment because it can only be decided in the context of the smartcard
9
application, against which threats the Smartcard Embedded Software will use the specific security
10
functionality.
11
The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality
12
(P.Add-Functions)” as specified below.
13
P.Add-Functions Additional Specific Security Functionality
14
The TOE shall provide the following specific security functionality to the Smartcard Embedded
15
Software:
16
 Advanced Encryption Standard (AES)
17
 Triple Data Encryption Standard (3DES)
18
 Rivest-Shamir-Adleman Cryptography (RSA)
19
 Elliptic Curve Cryptography (EC)
20
 Hash Cryptographic Functions (SHA)
21
22
Note:This TOE can be delivered with the SCP accessible or blocked. The blocking depends on the
23
customer demands prior to the production of the hardware. In case the SCP is blocked, no
24
3DES or AES computation supported by hardware is possible. The 3DES and AES
25
functionality has then to be removed from this policy.
26
Note:The TOE can also be delivered with an optional SCL. Any optional SCL contains AES and
27
3DES algorithms with additional security countermeasures. The optional SCL needs an
28
accessible SCP. The 3DES and AES functionality has then to be removed from this policy.
29
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
30
the Crypto2304T is blocked, no RSA or ECC computation supported by hardware is possible.
31
The RSA and ECC functionality has then to be removed from this policy.
32
Note:The TOE can also be delivered with the optional RSA library. The optional RSA library needs
33
an accessible Crypto2304T. If the optional RSA library is not delivered then RSA
34
functionality has to be removed from this policy.
35
Note:The TOE can also be delivered with the optional ECC library. The optional ECC library needs
36
an accessible Crypto2304T. If the optional ECC library is not delivered then ECC functionality
37
has to be removed from this policy.
38
31
Security Target Lite
M9900, M9905, M9906
public
Note:The TOE can be delivered with the optional HCL library. If the optional HCL library is not
1
delivered then SHA functionality has to be removed from this policy.
2
3
4.3 Assumptions
4
The TOE assumptions on the operational environment are defined and described in PP [1] section
5
3.4.
6
The assumptions concern the phases where the TOE has left the chip manufacturer.
7
8
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization:
9
It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer
10
up to delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its
11
manufacturing and test data (to prevent any possible copy, modification, retention, theft or
12
unauthorised use).
13
14
A.Plat-Appl Usage of Hardware Platform:
15
The Security IC Embedded Software is designed so that the requirements from the following
16
documents are met: (i) TOE guidance documents (refer to the Common Criteria assurance class
17
AGD) such as the hardware data sheet, and the hardware application notes, and (ii) findings of the
18
TOE evaluation reports relevant for the Security IC Embedded Software as documented in the
19
certification report.
20
21
A.Resp-Appl Treatment of User Data:
22
All User Data are owned by Security IC Embedded Software. Therefore, it must be assumed that
23
security relevant User Data (especially cryptographic keys) are treated by the Security IC
24
Embedded Software as defined for its specific application context.
25
26
The support of cipher schemas needs to make an additional assumption.
27
Table 10 Assumption according PP
28
[1]
29
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization
A.Plat-Appl Usage of Hardware Platform
A.Resp-Appl Treatment of User Data
30
31
32
Security Target Lite
M9900, M9905, M9906
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 [1] section
11
3.4.).
12
33
Security Target Lite
M9900, M9905, M9906
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 [1] section 4.1.
11
12
Table 11 Objectives for the TOE
13
according to PP [1]
14
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
15
The TOE provides “Additional Specific Security Functionality (O.Add-Functions)” as specified
16
below.
17
O.Add-Functions : Additional Specific Security Functionality
18
The TOE must optionally provide the following specific security functionality to the Smartcard
19
Embedded Software:
20
 Advanced Encryption Standard (AES)
21
 Triple Data Encryption Standard (3DES)
22
 Rivest-Shamir-Adleman (RSA)
23
 Elliptic Curve Cryptography (EC)
24
 Hash Cryptographic functions (SHA)
25
The hardware of this TOE can be delivered with the following configuration options:
26
 both crypto co-processors accessible
27
 with a blocked SCP
28
 with a blocked Crypto2304T
29
 both crypto co-processors blocked
30
34
Security Target Lite
M9900, M9905, M9906
public
In case the SCP is blocked, no AES and 3DES computations supported by hardware are possible. In
1
the case the Crypto2304T is blocked, no RSA and EC computations supported by hardware are
2
possible.
3
The optional security relevant software part of the TOE consists of the following optional libraries:
4
 RSA Cryptographic Library
5
 EC Cryptographic Library
6
 Symmetric Cryptographic Library (SCL)
7
 Hash cryptographic library (HCL)
8
 Platform Support Library (PSL)
9
10
The TOE shall provide “Area based Memory Access Control (O.Mem-Access)” as specified below.
11
O.Mem-Access: Area based Memory Access Control
12
The TOE must provide the Smartcard Embedded Software with the capability to define restricted
13
access memory areas. The TOE must then enforce the partitioning of such memory areas so that
14
access of software to memory areas and privilege levels is controlled as required, for example, in a
15
multi-application environment.
16
Table 12 Additional objectives due
17
to TOE specific functions
18
and augmentations
19
O.Add-Functions Additional specific security functionality
O.Mem-Access Area based Memory Access Control
5.2 Security Objectives for the development and operational
20
Environment
21
The security objectives for the security IC embedded software development environment and the
22
operational environment is defined in PP [1] section 4.2 and 4.3. The table below lists the security
23
objectives.
24
Table 13 Security objectives for the
25
environment according
26
to PP [1]
27
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
5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”
28
Regarding the cryptographic services this objective of the environment has to be clarified. The TOE
29
supports cipher schemes as additional specific security functionality. If required the Smartcard
30
Embedded Software shall use these cryptographic services of the TOE and their interface as
31
specified. When key-dependent functions implemented in the Smartcard Embedded Software are
32
just being executed, the Smartcard Embedded Software must provide protection against disclosure
33
of confidential data (User Data) stored and/or processed in the TOE by using the methods
34
described under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information
35
Leakage (T.Leak-Forced)“.
36
35
Security Target Lite
M9900, M9905, M9906
public
The objectives of the environment regarding the memory, software and firmware protection and
1
the SFR and peripheral-access-rights-handling have to be clarified. For the separation of different
2
applications the Smartcard Embedded Software (Operating System) may implement a memory
3
management scheme based upon security functions of the TOE.
4
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”
5
Regarding the cryptographic services this objective of the environment has to be clarified. By
6
definition cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded
7
Software shall treat these data appropriately, use only proper secret keys (chosen from a large key
8
space) as input for the cryptographic function of the TOE and use keys and functions appropriately
9
in order to ensure the strength of cryptographic operation.
10
This means that keys are treated as confidential as soon as they are generated. The keys must be
11
unique with a very high probability, as well as cryptographically strong. For example, it must be
12
ensured that it is beyond practicality to derive the private key from a public key if asymmetric
13
algorithms are used. If keys are imported into the TOE and/or derived from other keys, quality and
14
confidentiality must be maintained. This implies that appropriate key management has to be
15
realized in the environment.
16
Regarding the memory, software and firmware protection and the SFR and peripheral access rights
17
handling these objectives of the environment has to be clarified. The treatment of User Data is also
18
required when a multi-application operating system is implemented as part of the Smartcard
19
Embedded Software on the TOE. In this case the multi-application operating system should not
20
disclose security relevant user data of one application to another application when it is processed
21
or stored on the TOE.
22
5.2.3 Clarification of “Protection during Composite product
23
manufacturing (OE.Process-Sec-IC)”
24
The protection during packaging, finishing and personalization includes also the personalization
25
process (Flash Loader software) and the personalization data (TOE software components) during
26
Phase 4, Phase 5 and Phase 6.
27
5.3 Security Objectives Rationale
28
The security objectives rationale of the TOE are defined and described in PP [1] section 4.4. For
29
organizational security policy P.Add-Functions, OE.Plat-Appl and OE.Resp-Appl the rationale is
30
given in the following description.
31
Table 14 Security Objective
32
Rationale
33
Assumption, Threat or Organisational
Security Policy
Security Objective
P.Add-Functions O.Add-Functions
A.Key-Function OE.Plat-Appl
OE.Resp-Appl
T.Mem-Access O.Mem-Access
34
The justification related to the security objective “Additional Specific Security Functionality
35
(O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the
36
same specific security functionality as required by P.Add-Functions; the organizational security
37
policy is covered by the objective.
38
36
Security Target Lite
M9900, M9905, M9906
public
Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
1
Manipulation and O.Leak-Forced define how to implement the specific security functionality
2
required by P.Add-Functions. (Note that these objectives support that the specific security
3
functionality is provided in a secure way as expected from P.Add-Functions.) Especially O.Leak-
4
Inherent and O.Leak-Forced refer to the protection of confidential data (User Data or TSF data) in
5
general. User Data are also processed by the specific security functionality required by
6
P.Add-Functions.
7
Compared to PP [1] clarification has been made for the security objective “Usage of Hardware
8
Platform (OE.Plat-Appl)”: If required the Smartcard Embedded Software shall use these
9
cryptographic services of the TOE and their interface as specified. In addition, the Smartcard
10
Embedded Software must implement functions which perform operations on keys (if any) in such a
11
manner that they do not disclose information about confidential data. The non disclosure due to
12
leakage A.Key-Function attacks is included in this objective OE.Plat-Appl. This addition ensures that
13
the assumption A.Plat-Appl is still covered by the objective OE.Plat-Appl although additional
14
functions are being supported according to O.Add-Functions.
15
Compared to the PP [1] a clarification has been made for the security objective “Treatment of User
16
Data (OE.Resp-Appl)”: By definition cipher or plain text data and cryptographic keys are User Data.
17
So, the Smartcard Embedded Software will protect such data if required and use keys and functions
18
appropriately in order to ensure the strength of cryptographic operation. Quality and
19
confidentiality must be maintained for keys that are imported and/or derived from other keys. This
20
implies that appropriate key management has to be realized in the environment. That is expressed
21
by the assumption A.Key—Function which is covered from OE.Resp–Appl. These measures make
22
sure that the assumption A.Resp-Appl is still covered by the security objective OE.Resp-Appl
23
although additional functions are being supported according to P.Add-Functions.
24
Compared to the PP [1] an enhancement regarding memory area protection has been established.
25
The clear definition of privilege levels for operated software establishes the clear separation of
26
different restricted memory areas for running the firmware, downloading and/or running the
27
operating system and to establish a clear separation between different applications. Nevertheless, it
28
is also possible to define a shared memory section where separated applications may exchange
29
defined data. The privilege levels clearly define by using a hierarchical model the access right from
30
one level to the other. These measures ensure that the threat T.Mem-Access is clearly covered by
31
the security objective O.Mem-Access.
32
The justification of the additional policy and the additional assumption show that they do not
33
contradict to the rationale already given in the Protection Profile for the assumptions, policy and
34
threats defined there.
35
37
Security Target Lite
M9900, M9905, M9906
public
6 Extended Component Definition (ASE_ECD)
1
There are four extended components defined and described for the TOE:
2
 the family FCS_RNG at the class FCS Cryptographic Support
3
 the family FMT_LIM at the class FMT Security Management
4
 the family FAU_SAS at the class FAU Security Audit
5
 the component FPT_TST.2 at the class FPT Protection of the TSF
6
The extended components FMT_LIM and FAU_SAS are defined and described in PP [1] section 5.
7
The components FPT_TST.2 and FCS_RNG are defined in the following sections.
8
6.1 “Subset TOE security testing (FPT_TST)”
9
The security is strongly dependent on the correct operation of the security functions. Therefore, the
10
TOE shall support that particular security functions or mechanisms are tested in the operational
11
phase (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the
12
TOE or is done automatically and continuously.
13
Part 2 of the Common Criteria provides the security functional component “TSF testing
14
(FPT_TST.1)”. The component FPT_TST.1 provides the ability to test the TSF’s correct operation.
15
For the user it is important to know which security functions or mechanisms can be tested. The
16
functional component FPT_TST.1 does not mandate to explicitly specify the security functions being
17
tested. In addition, FPT_TST.1 requires verification of the integrity of TSF data and of the stored TSF
18
executable code which might violate the security policy. Therefore, the functional
19
component”Subset TOE security testing (FPT_TST.2)” of the family TSF self test has been newly
20
created. This component allows that particular parts of the security mechanisms and functions
21
provided by the TOE are tested.
22
6.2 Definition of FPT_TST.2
23
The functional component “Subset TOE security testing (FPT_TST.2)” has been newly created
24
(Common Criteria Part 2 extended). This component allows that particular parts of the security
25
mechanisms and functions provided by the TOE can be tested after TOE Delivery or are tested
26
automatically and continuously during normal operation transparent for the user.
27
This security functional component is used instead of the functional component FPT_TST.1 from
28
Common Criteria Part 2. For the user it is important to know which security functions or
29
mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly
30
specify the security functions being tested. In addition, FPT_TST.1 requires verifying the integrity of
31
TSF data and stored TSF executable code which might violate the security policy.
32
The functional component “Subset TOE testing (FPT_TST.2)” is specified as follows (Common
33
Criteria Part 2 extended).
34
35
38
Security Target Lite
M9900, M9905, M9906
public
6.3 TSF self test (FPT_TST)
1
Family Behavior The Family Behavior is defined in [3] section 15.14 (442, 443).
2
Component leveling
3
FPT_TST TSF self test
1
2
4
FPT_TST.1 The component FPT_TST.1 is defined in [3] section 15.14 (444, 445, 446).
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 conditionsmanagement 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
6.4 Family “Generation of Random Numbers (FCS_RNG)”
26
The component “Generation of Random Numbers (FCS_RNG.1)” has to be newly created according
27
the new version of the “Anwendungshinweise und Interpretationen zum Schema (AIS)” [15]. This
28
security functional component is used instead of the functional component FCS_RNG.1 defined in
29
the protection profile [1].
30
The component “Generation of Random Numbers (FCS_RNG.1)” is specified as follows (Common
31
Criteria Part 2 extended).
32
33
6.5 Definition of FCS_RNG.1
34
This section describes the functional requirements for the generation of random numbers, which
35
may be used as secrets for cryptographic purposes or authentication. The IT security functional
36
requirements for the TOE are defined in an additional family (FCS_RNG) of the Class FCS
37
(Cryptographic support).
38
39
Security Target Lite
M9900, M9905, M9906
public
1
FCS_RNG Generation of random numbers
2
Family Behaviour
3
This family defines quality requirements for the generation of random numbers that are intended
4
to be used for cryptographic purposes.
5
6
Component levelling:
7
FCS_RNG: Generation of random numbers
TSF self test
1
8
9
FCS_RNG.1 Generation of random numbers, requires that the random number generator I
10
mplements defined security capabilities and that the random numbers meet a
11
defined quality metric.
12
Management: FCS_RNG.1
13
There are no management activities foreseen.
14
Audit: FCS_RNG.1
15
There are no actions defined to be auditable.
16
17
FCS_RNG.1 Random number generation
18
Hierarchical to: No other components.
19
Dependencies: No dependencies.
20
FCS_RNG.1.1: The TSF shall provide a [selection: physical, non-physical true, deterministic,
21
hybrid physical, hybrid deterministic] random number generator that imple-
22
ments: [assignment: list of security capabilities].
23
FCS_RNG.1.2: The TSF shall provide random numbers that meet [assignment: a defined
24
quality metric].
25
Note:The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the
26
Protection Profile [1] according to “Anwendungshinweise und Interpretationen zum Schema
27
(AIS)” [15].
28
29
40
Security Target Lite
M9900, M9905, M9906
public
7 Security Requirements (ASE_REQ)
1
For this section the PP [1] section 6 can be applied completely.
2
7.1 TOE Security Functional Requirements
3
The security functional requirements (SFR) for the TOE are defined and described in the PP [1]
4
section 6.1 and in the following description.
5
The Table 15 provides an overview of the functional security requirements of the TOE, defined in
6
the in PP [1] section 6.1. In the last column it is marked if the requirement is refined. The
7
refinements are also valid for this ST.
8
Table 15 Security functional
9
requirements defined in
10
PP [1]
11
Security Functional Requirement Refined in PP [1]
FRU_FLT.2 Limited fault tolerance Yes
FPT_FLS.1 Failure with preservation of secure state Yes
FMT_LIM.1 Limited capabilities No
FMT_LIM.2 Limited availability No
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
12
The Table 16 provides an overview about the augmented security functional requirements, which
13
are added additional to the TOE and defined in this ST. All requirements are taken from Common
14
Criteria Part 2 [3], with the exception of the requirement FPT_TST.2 and FCS_RNG.1, which are
15
defined in this ST completely.
16
17
Table 16 Augmented security
18
functional requirements
19
Security Functional Requirement
FPT_TST.2 Subset TOE security testing
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute based access control
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialization
FMT_SMF.1 Specification of Management functions
FCS_COP.1 Cryptographic support
FCS_CKM.1 Cryptographic key generation
FDP_SDI.1 Stored data integrity monitoring
FDP_SDI.2 Stored data integrity monitoring and action
FCS_RNG.1 Quality metric for random numbers
20
41
Security Target Lite
M9900, M9905, M9906
public
All assignments and selections of the security functional requirements of the TOE are done in PP [1]
1
and in the following description.
2
The above marked extended components FMT_LIM.1 and FMT_LIM.2 are introduced in PP [1] to
3
define the IT security functional requirements of the TOE as an additional family (FMT_LIM) of the
4
Class FMT (Security Management). This family describes the functional requirements for the Test
5
Features of the TOE. The new functional requirements were defined in the class FMT because this
6
class addresses the management of functions of the TSF.
7
The additional component FAU.SAS is introduced to define the security functional requirements of
8
the TOE of the Class FAU (Security Audit). This family describes the functional requirements for the
9
storage of audit data and is described in the next chapter.
10
The requirement FPT_TST.2 is the subset of TOE testing and originated in [3]. This requirement is
11
given as the correct operation of the security functions is essential. The TOE provides mechanisms
12
to cover this requirement by the smartcard embedded software and/or by the TOE itself.
13
7.1.1 Extended Components FCS_RNG.1 and FAU_SAS.1
14
7.1.1.1 FCS_RNG
15
To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the
16
class FCS (cryptographic support) is defined in chapter 6.5. This family describes the functional
17
requirements for random number generation used for cryptographic purposes.
18
19
FCS_RNG.1/HW Random Number Generation
20
Hierarchical to: No other components
21
Dependencies: No dependencies
22
FCS_RNG.1 Random numbers generation Class PTG.2 according to [6]
23
FCS_RNG.1.1 The TSF shall provide a physical random number generator which
24
implements:
25
PTG.2.1 A: total failure test detects a total failure of entropy source
26
immediately when the RNG has started. When a total failure is detected, no
27
random numbers will be output.
28
PTG.2.2 : If a total failure of the entropy source occurs while the RNG
29
is being operated, the RNG prevents the output of any internal random
30
number that depends on some raw random numbers that have been
31
generated after the total failure of the entropy source.
32
33
PTG.2.3: The online test shall detect non-tolerable statistical defects of the
34
rawrandom number sequence (i) immediately when the RNG has started,
35
and (ii) while the RNG is being operated. The TSF must not output any
36
random numbers before the power-up online test has finished successfully
37
or when a defect has been detected.
38
PTG.2.4 :The online test procedure shall be effective to detect non-
39
tolerable weaknesses of the random numbers soon.
40
41
PTG.2.5 :The online test procedure checks the quality of the raw random
42
num ber sequence. It is triggered continuously. The online test is suitable for
43
42
Security Target Lite
M9900, M9905, M9906
public
detecting non-tolerable statistical defects of the statistical properties of the
1
raw random numbers within an acceptable period of time.
2
3
FCS_RNG.1.2 The TSF shall provide numbers in the format 8- or 16-bit that meet
4
PTG.2.6: Test procedure A, as defined in [6] does not distinguish the internal
5
random numbers from output sequences of an ideal RNG.
6
PTG.2.7: The average Shannon entropy per internal random bit exceeds
7
0.997.
8
Note: The functional requirement FCS_RNG.1/HW is a refinement of the FCS_RNG.1 defined in
9
chapter 6.5
10
Note:
11
FCS_RNG.1/PSL Random Number Generation
12
Hierarchical to: No other components
13
Dependencies: No dependencies
14
FCS_RNG.1 Random numbers generation Class PTG.2 according to [6]
15
FCS_RNG.1.1 The TSF shall provide a physical random number generator which
16
implements:
17
PTG.2.1 A: total failure test detects a total failure of entropy source
18
immediately when the RNG has started. When a total failure is detected, no
19
random numbers will be output.
20
PTG.2.2 : If a total failure of the entropy source occurs while the RNG
21
is being operated, the RNG prevents the output of any internal random
22
number that depends on some raw random numbers that have been
23
generated after the total failure of the entropy source.
24
25
PTG.2.3: The online test shall detect non-tolerable statistical defects of the
26
rawrandom number sequence (i) immediately when the RNG has started,
27
and (ii) while the RNG is being operated. The TSF must not output any
28
random numbers before the power-up online test has finished successfully
29
or when a defect has been detected.
30
PTG.2.4 :The online test procedure shall be effective to detect non-
31
tolerable weaknesses of the random numbers soon.
32
33
PTG.2.5 :The online test procedure checks the quality of the raw random
34
num ber sequence. It is triggered continuously. The online test is suitable for
35
detecting non-tolerable statistical defects of the statistical properties of the
36
raw random numbers within an acceptable period of time.
37
38
FCS_RNG.1.2 The TSF shall provide a number n of caller requested bytes (n = 0…232
, 4 | n
39
) , that meet
40
PTG.2.6: Test procedure A, as defined in [6] does not distinguish the internal
41
random numbers from output sequences of an ideal RNG.
42
43
Security Target Lite
M9900, M9905, M9906
public
PTG.2.7: The average Shannon entropy per internal random bit exceeds
1
0.997.
2
Note: The functional requirement FCS_RNG.1/PSL is a refinement of the FCS_RNG.1 defined in
3
chapter 6.5.
4
Note:The TOE can be delivered with the optional PSL library v4.00.10 and v5.00.06. If none of those
5
optional PSL libraries is available then this SFR is not applicable.
6
7.1.1.2 FAU_SAS
7
To define the security functional requirements of the TOE an additional family (FAU_SAS) of the
8
Class FAU (Security Audit) is defined here. This family describes the functional requirements for
9
the storage of audit data. It has a more general approach than FAU_GEN, because it does not
10
necessarily require the data to be generated by the TOE itself and because it does not give specific
11
details of the content of the audit records.
12
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common
13
Criteria Part 2 extended).
14
15
FAU_SAS.1 Audit Storage
16
Hierarchical to: No other components
17
Dependencies: No dependencies.
18
FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the
19
capability to store the Initialization Data and/or Pre-personalization Data
20
and/or supplements of the Security IC Embedded Software in the not
21
changeable configuration page area and non-volatile memory.
22
7.1.2 Subset of TOE testing
23
The security is strongly dependent on the correct operation of the security functions. Therefore, the
24
TOE shall support that particular security functions or mechanisms are tested in the operational
25
phase (Phase 7). The tests can be initiated by the Smartcard Embedded Software and/or by the
26
TOE.
27
The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below
28
(Common Criteria Part 2 extended).
29
30
FPT_TST.2 Subset TOE testing
31
Hierarchical to: No other components
32
Dependencies: No dependencies
33
FPT_TST.2.1 The TSF shall run a suite of self tests at the request of the authorized user to
34
demonstrate the correct operation of the alarm lines and/or the
35
environmental sensor mechanisms
36
7.2 Memory access control
37
Usage of multiple applications in one Smartcard often requires code and data separation in order to
38
prevent that one application can access code and/or data of another application. For this reason the
39
TOE provides Area based Memory Access Control. The underlying Memory Protection Unit (MPU)
40
is documented in section 4 of the [7].
41
44
Security Target Lite
M9900, M9905, M9906
public
The security service being provided is described in the Security Function Policy (SFP) Memory
1
Access Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)”
2
requires that this policy is in place and defines the scope were it applies. The security functional
3
requirement “Security attribute based access control (FDP_ACF.1)” defines security attribute usage
4
and characteristics of policies. It describes the rules for the function that implements the Security
5
Function Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or
6
not is taken based upon attributes allocated to the software. The Smartcard Embedded Software
7
defines the attributes and memory areas. The corresponding permission control information is
8
evaluated “on-the-fly” by the hardware so that access is granted/effective or denied/inoperable.
9
The security functional requirement “Static attribute initialisation (FMT_MSA.3)” ensures that the
10
default values of security attributes are appropriately either permissive or restrictive in nature.
11
Alternative values can be specified by any subject provided that the Memory Access Control Policy
12
allows that. This is described by the security functional requirement “Management of security
13
attributes (FMT_MSA.1)”. The attributes are determined during TOE manufacturing (FMT_MSA.3)
14
or set at run-time (FMT_MSA.1).
15
From TOE’s point of view the different roles in the Smartcard Embedded Software can be
16
distinguished according to the memory based access control. However the definition of the roles
17
belongs to the user software.
18
The following Security Function Policy (SFP) Memory Access Control Policy is defined for the
19
requirement “Security attribute based access control (FDP_ACF.1)”:
20
21
22
7.2.1 Memory Access Control Policy
23
The TOE shall support the standard ARMv7 Protected Memory System Architecture model.
24
The MPU provides full support for:
25
 Protection regions.
26
 Overlapping protection regions, with ascending region priority:
27
− Region 7 = highest priority.
28
− Region 0 = lowest priority.
29
 Access permissions.
30
 MPU mismatches and permission violations invoke the programmable-priority MemManage
31
fault handler.
32
The MPU can be used to:
33
 Enforce privilege rules, preventing user applications from corrupting operating system data.
34
 Separate processes, blocking the active task from accessing other tasks’ data.
35
 Enforce access rules, allowing memory regions to be defined as read-only or detecting
36
unexpected memory accesses.
37
38
Subjects, Objects and Operations of the policy
39
 Subjects: privilege or non-privilege level of the ARM processor
40
 Objects: memory/code addresses
41
 Operations: Read a/o write a/o execute access
42
43
Attributes of the policy:
44
 MPU enable/disable bit.
45
45
Security Target Lite
M9900, M9905, M9906
public
 8 regions with the following attributes
1
− A unique priority
2
− The enable bit
3
− the start address and size
4
− an access matrix which defines if an Operation of a Subject to an Object lying in the region is
5
allowed or denied
6
 The default region with the following security attribute:
7
− A bit which defines if an Operation for the Subject (privilege level) is allowed or if no
8
Operation is allowed for any Subject.
9
10
Roles of the policy:
11
The roles correspond 1-1 to the subjects.
12
13
Properties of the policy:
14
 If an address is contained in multiple enabled regions, then the region with the highest priority
15
defines the access rights.
16
 If an address is contained in no region then the default region defines the access rights.
17
 The region defining the access rights checks in the access matrix if the Subject has access to the
18
Object with respect to the desired Operation. In case the access is denied the MPU throws an
19
access violation exception.
20
21
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below.
22
23
FDP_ACC.1 Subset access control
24
Hierarchical to: No other components.
25
Dependencies: FDP_ACF.1 Security attribute based access control
26
FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all Subjects, all
27
Objects and all Operations.
28
29
30
The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as
31
specified below.
32
33
FDP_ACF.1 Security attribute based access control
34
Hierarchical to: No other components.
35
Dependencies: FDP_ACC.1 Subset access control
36
FMT_MSA.3 Static attribute initialization
37
FDP_ACF.1.1 The TSF shall enforce the Memory Access Control Policy to objects based on
38
the following: As specified in the definition of the memory access control
39
policy .
40
41
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
42
controlled subjects and controlled objects is allowed:
43
As specified in the definition of the memory access control policy.
44
45
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
46
following additional rules: none.
47
48
46
Security Target Lite
M9900, M9905, M9906
public
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the
1
following additional rules: none.
2
3
4
The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified
5
below.
6
7
FMT_MSA.3 Static attribute initialization
8
9
Hierarchical to: No other components.
10
11
Dependencies: FMT_MSA.1 Management of security attributes
12
FMT_SMR.1 security roles
13
14
FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide
15
restrictive1 default values for security attributes that are used to enforce the
16
SFP.
17
18
FMT_MSA.3.2 The TSF shall allow the privilege level to specify alternative initial values to
19
override the default values when an object or information is created.
20
21
22
The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified
23
below:
24
25
FMT_MSA.1 Management of security attributes
26
27
Hierarchical to: No other components.
28
29
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset information flow
30
control]
31
FMT_SMF.1 Specification of management functions
32
FMT_SMR.1 Security roles
33
34
FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability
35
to modify any security attributes2 to the privilege level.
36
37
The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as
38
specified below:
39
40
FMT_SMF.1 Specification of management functions
41
42
Hierarchical to: No other components
43
44
Dependencies: No dependencies
45
46
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
47
functions: The privilege level shall be able to access the configuration
48
registers of the MPU.
49
50
1 The static definition of the access rules is documented in [7]
2 editorially refined
47
Security Target Lite
M9900, M9905, M9906
public
7.3 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.6.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)
10
 Rivest-Shamir-Adleman (RSA)1
11
 Hash functions (SHA-x)
12
13
General statements with regard to Elliptic Curves:
14
The EC library is delivered as object code and in this way integrated in the user software. The
15
certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of
16
160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there are numerous
17
other curve types, being also secure in terms of side channel attacks on this TOE, which the user can
18
optionally add in the composition certification process.
19
20
7.3.1 Triple-DES Operation
21
The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)”
22
as specified below.
23
FCS_COP.1/DES Cryptographic operation
24
Hierarchical to: No other components.
25
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
26
FDP_ITC.2 Import of user data with security attributes, or
27
FCS_CKM.1 Cryptographic key management]
28
FCS_CKM.4 Cryptographic key destruction
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 with cryptographic key sizes of 2 x 56 or 3 x 56 bit that meet the
33
following standards: [N38A], [N867]
34
35
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
36
3DES computation supported by hardware is possible and this SFR is not applicable.
37
38
FCS_COP.1/DES_SCL_1 Cryptographic operation
39
1 In case a user deselects the RSA and/or EC library, the TOE provides basic HW-related routines for
RSA and/or EC calculations. For a secure library implementation the user has to implement additional
countermeasures.
48
Security Target Lite
M9900, M9905, M9906
public
1
Hierarchical to: No other components.
2
3
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
4
Import of user data with security attributes, or
5
FCS_CKM.1 Cryptographic key management]
6
FCS_CKM.4 Cryptographic key destruction
7
8
FCS_COP.1.1/DES_SCL_1 The TSF shall perform encryption and decryption in accordance with
9
a specified cryptographic algorithm Triple Data Encryption Standard (3DES)
10
in Electronic Codebook mode (ECB),the Cipher Block Chaining mode (CBC),
11
Counter mode (CTR) mode and with cryptographic key sizes of 2 x 56 or 3 x
12
56 bit, that meet the following standards: [N867], [N38A]
13
14
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
15
3DES computation supported by hardware is possible and this SFR is not applicable.
16
Note:The TOE can be delivered with an optional SCL library v2.01.011. If this library is not available
17
then this SFR is not applicable.
18
19
FCS_COP.1/DES_SCL_2 Cryptographic operation
20
21
Hierarchical to: No other components.
22
23
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
24
Import of user data with security attributes, or
25
FCS_CKM.1 Cryptographic key management]
26
FCS_CKM.4 Cryptographic key destruction
27
28
FCS_COP.1.1/DES_SCL _2 The TSF shall perform encryption and decryption in accordance with
29
a specified cryptographic algorithm Triple Data Encryption Standard (3DES)
30
in Electronic Codebook mode (ECB),the Cipher Block Chaining mode (CBC),
31
Cipher Feedback mode (CFB) , Counter mode (CTR) mode and with
32
cryptographic key sizes of 2 x 56 or 3 x 56 bit, that meet the following
33
standards: [N867], [N38A]
34
35
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
36
3DES computation supported by hardware is possible and this SFR is not applicable.
37
Note:The TOE can be delivered with the optional SCL library v2.02.01. If this libray is not available
38
then this SFR is not applicable.
39
FCS_COP.1/DES_SCL_3 Cryptographic operation
40
41
Hierarchical to: No other components.
42
43
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
44
Import of user data with security attributes, or
45
FCS_CKM.1 Cryptographic key management]
46
FCS_CKM.4 Cryptographic key destruction
47
48
49
Security Target Lite
M9900, M9905, M9906
public
FCS_COP.1.1/DES_SCL _3 The TSF shall perform encryption and decryption in accordance with
1
a specified cryptographic algorithm Triple Data Encryption Standard (3DES)
2
in Electronic Codebook mode (ECB), the Cipher Block Chaining mode (CBC),
3
Cipher Feedback mode (CFB), Counter mode (CTR), CMAC mode and with
4
cryptographic key sizes of 2 x 56 or 3 x 56 bit, that meet the following
5
standards: [N867], [N38A], [N38B].
6
7
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
8
3DES computation supported by hardware is possible and this SFR is not applicable.
9
Note:The TOE can be delivered with the optional SCL library v2.04.003. If this libray is not available
10
then this SFR is not applicable.
11
12
FCS_COP.1/DES_PSL Cryptographic operation
13
Hierarchical to: No other components.
14
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
15
Import of user data with security attributes, or
16
FCS_CKM.1 Cryptographic key management]
17
FCS_CKM.4 Cryptographic key destruction
18
19
FCS_COP.1.1/DES_PSL The TSF shall perform encryption and decryption in accordance with
20
a specified cryptographic algorithm Triple Data Encryption Standard (3DES)
21
in Electronic Codebook Mode (ECB) and in the Cipher Block Chaining Mode
22
(CBC) and with cryptographic key sizes of 2 x 56 or 3 x 56 bit, that meet the
23
following standards: [N867], [N38A]
24
25
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, then
26
this SFR is not applicable.
27
Note:The TOE can be delivered with an optional PSL library. If no optional PSL library is available
28
then this SFR is not applicable.
29
FCS_COP.1/DES_MAC_PSL Cryptographic operation
30
Hierarchical to: No other components.
31
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
32
Import of user data with security attributes, or
33
FCS_CKM.1 Cryptographic key management]
34
FCS_CKM.4 Cryptographic key destruction
35
36
FCS_COP.1.1/DES_MAC_PSL The TSF shall perform MAC calculation in accordance with a specified
37
cryptographic algorithm Triple Data Encryption Standard (3DES) in CBC
38
MAC mode and cryptographic key sizes of 2 x 56 or 3 x 56 bit that meet the
39
following standards: [N867], [9797] with the following
40
options/modifications:
41
 MAC algorithm 1
42
 Padding must be done by the caller
43
 An Initialization Vector (IV) must be given by the caller
44
50
Security Target Lite
M9900, M9905, M9906
public
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, then
1
this SFR is not applicable.
2
Note:The TOE can be delivered with an optional PSL library. If no optional PSL library is available
3
then this SFR is not applicable.
4
5
7.3.2 AES Operation
6
The AES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)”
7
as specified below.
8
9
FCS_COP.1/AES Cryptographic operation
10
Hierarchical to: No other components.
11
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
12
FDP_ITC.2 Import of user data with security attributes, or
13
FCS_CKM.1 Cryptographic key generation]
14
FCS_CKM.4 Cryptographic key destruction
15
FCS_COP.1.1/AES The TSF shall perform encryption and decryption in accordance with a
16
specified cryptographic algorithm : Advanced Encryption Standard (AES) in
17
Electronic Codebook Mode (ECB) and in the Cipher Block Chaining
18
Mode (CBC) and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet
19
the following standards: [N197], [N38A]
20
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
21
AES computation supported by hardware is possible and this SFR is not applicable.
22
23
FCS_COP.1/AES_SCL_1 Cryptographic operation
24
25
Hierarchical to: No other components.
26
27
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
28
Import of user data with security attributes, or
29
FCS_CKM.1 Cryptographic key generation]
30
FCS_CKM.4 Cryptographic key destruction
31
32
FCS_COP.1.1/AES_SCL_1 The TSF shall perform encryption and decryption in
33
accordance with a specified cryptographic algorithm Advanced Encryption Standard (AES) in
34
Electronic Codebook mode (ECB), Cipher Block Chaining mode (CBC), CTR(counter) mode and
35
cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the following standards: [N197],
36
[N38A]
37
38
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
39
AES computation supported by hardware is possible and this SFR is not applicable.
40
Note:The TOE can be delivered with the optional SCL library v2.01.011. If this libray is not available
41
then this SFR is not applicable.
42
51
Security Target Lite
M9900, M9905, M9906
public
FCS_COP.1/AES_SCL_2 Cryptographic operation
1
2
Hierarchical to: No other components.
3
4
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
5
Import of user data with security attributes, or
6
FCS_CKM.1 Cryptographic key generation]
7
FCS_CKM.4 Cryptographic key destruction
8
9
FCS_COP.1.1/AES_SCL _2 The TSF shall perform encryption and decryption in accordance with
10
a specified cryptographic algorithm Advanced Encryption Standard (AES) in Electronic Codebook
11
mode (ECB), Cipher Block Chaining mode (CBC), Cipher Feedback mode (CFB), CTR(counter) mode
12
and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the following standards:
13
[N197], [N38A],
14
15
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
16
AES computation supported by hardware is possible and this SFR is not applicable.
17
Note:The TOE can be delivered with the optional SCL library v2.02.010. If this libray is not available
18
then this SFR is not applicable.
19
20
FCS_COP.1/AES_SCL_3 Cryptographic operation
21
22
Hierarchical to: No other components.
23
24
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
25
Import of user data with security attributes, or
26
FCS_CKM.1 Cryptographic key generation]
27
FCS_CKM.4 Cryptographic key destruction
28
29
FCS_COP.1.1/AES_SCL_3 The TSF shall perform encryption and decryption in
30
accordance with a specified cryptographic algorithm Advanced Encryption Standard (AES) in
31
Electronic Codebook mode (ECB), Cipher Block Chaining mode (CBC), Cipher Feedback mode
32
(CFB), CTR(counter) mode, CMAC mode and cryptographic key sizes of 128 bit or 192 bit or 256
33
bit that meet the following standards: [N197], [N38A], [N38B]
34
35
Note:This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, no
36
AES computation supported by hardware is possible and this SFR is not applicable.
37
Note:The TOE can be delivered with the optional SCL library v2.04.003. If this libray is not available
38
then this SFR is not applicable.
39
40
FCS_COP.1/AES_PSL Cryptographic operation
41
Hierarchical to: No other components.
42
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
43
FDP_ITC.2 Import of user data with security attributes, or
44
52
Security Target Lite
M9900, M9905, M9906
public
FCS_CKM.1 Cryptographic key generation]
1
FCS_CKM.4 Cryptographic key destruction
2
3
FCS_COP.1.1/AES_PSL The TSF shall perform encryption and decryption in accordance with
4
a specified cryptographic algorithm Advanced Encryption Standard (AES) in
5
Electronic Codebook Mode (ECB) and in the Cipher Block Chaining Mode
6
(CBC) and cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the
7
following standards: [N197], [N38A]
8
9
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, then
10
this SFR is not applicable.
11
Note:The TOE can be delivered with an optional PSL library. If no optional PSL library is available
12
then this SFR is not applicable.
13
FCS_COP.1/AES_MAC_PSL_1 Cryptographic operation
14
15
Hierarchical to: No other components.
16
17
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
18
FDP_ITC.2 Import of user data with security attributes, or
19
FCS_CKM.1 Cryptographic key generation]
20
FCS_CKM.4 Cryptographic key destruction
21
22
FCS_COP.1.1/AES_MAC_PSL_1 The TSF shall perform MAC calculation in accordance with a
23
specified cryptographic algorithm Advanced Encryption Standard (AES) in
24
CBC MAC mode and cryptographic key sizes of 128 bit or 192 bit or 256 bit
25
that meet the following standards: [9797], [N197] with the following
26
options/modifications:
27
 MAC algorithm 1
28
 Padding must be done by the caller
29
 An Initialization Vector (IV) must be given by the caller
30
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, then
31
this SFR is not applicable.
32
Note:The TOE can be delivered with the optional PSL library v4.00.09 and v4.00.10. If none of those
33
optional PSL libraries is available then this SFR is not applicable.
34
35
FCS_COP.1/AES_MAC_PSL_2 Cryptographic operation
36
37
Hierarchical to: No other components.
38
39
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
40
FDP_ITC.2 Import of user data with security attributes, or
41
FCS_CKM.1 Cryptographic key generation]
42
FCS_CKM.4 Cryptographic key destruction
43
44
FCS_COP.1.1/AES_MAC_PSL_2 The TSF shall perform MAC calculation in accordance with a
45
specified cryptographic algorithm Advanced Encryption Standard (AES) in
46
53
Security Target Lite
M9900, M9905, M9906
public
CBC MAC mode and CMAC mode and cryptographic key sizes of 128 bit or
1
192 bit or 256 bit that meet the following standards: [9797], [N197], [N38B]
2
with the following options/modifications:
3
 MAC algorithm 1
4
 Padding must be done by the caller
5
 An Initialization Vector (IV) must be given by the caller
6
Note:The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked, then
7
this SFR is not applicable.
8
Note:The TOE can be delivered with the optional PSL library v5.00.06. If thislibrary is not available
9
than this SFR is not applicable
10
11
7.3.3 Rivest-Shamir-Adleman (RSA) operation
12
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation
13
(FCS_COP.1)” as specified below.
14
15
FCS_COP.1/RSA Cryptographic operation
16
17
Hierarchical to: No other components.
18
19
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
20
FDP_ITC.2 Import of user data with security attributes, or
21
FCS_CKM.1 Cryptographic key generation]
22
FCS_CKM.4 Cryptographic key destruction
23
24
FCS_COP.1.1/RSA The TSF shall perform encryption, decryption, signature generation and
25
verification in accordance with a specified cryptographic algorithm Rivest-
26
Shamir-Adleman (RSA) and cryptographic key sizes of 1024 - 4096 bit that
27
meet the following standards:
28
29
Encryption:
30
According to section 5.1.1 RSAEP in PKCS v2.2,
31
without 5.1.1(1).
32
33
Decryption (with or without CRT):
34
According to section 5.1.2 RSADP in PKCS v2.2
35
for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without
36
5.1.2(2.b)(ii)&(v), without 5.1.2(1), 5.1.2(2.a) only supported up to n <
37
22048
.
38
39
Signature Generation (with or without CRT): According to section 5.2.1
40
RSASP1 in PKCS v2.2
41
for u = 2, i.e., without any (r_i, d_i, t_i), i >2,
42
therefore without 5.2.1(2.b) (ii)&(v), without 5.1.2(1),
43
5.2.1(2.a) only supported up to n < 22048
.
44
45
Signature Verification:
46
According to section 5.2.2 RSAVP1 in PKCS v2.2,
47
without 5.2.2(1).
48
49
54
Security Target Lite
M9900, M9905, M9906
public
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
1
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this
2
SFR is not applicable.
3
Note:The TOE can be delivered with an optional RSA library. Any optional RSA library contains the
4
RSA algorithms stated above. Any optional RSA library needs an accessible Crypto2304T. If no
5
optional RSA library is available then this SFR is not applicable.
6
7
FCS_COP.1/RSA_PSL Cryptographic operation
8
9
Hierarchical to: No other components.
10
11
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
12
FDP_ITC.2 Import of user data with security attributes, or
13
FCS_CKM.1 Cryptographic key generation]
14
FCS_CKM.4 Cryptographic key destruction
15
16
FCS_COP.1.1/RSA_PSL The TSF shall perform encryption, decryption, signature generation
17
and verification in accordance with a specified cryptographic algorithm
18
Rivest-Shamir-Adleman (RSA) and cryptographic key sizes of 1024 - 4096
19
bit that meet the following standards:
20
21
Encryption:
22
According to section 5.1.1 RSAEP in PKCS v2.2,
23
without 5.1.1(1).
24
25
Decryption (with or without CRT):
26
According to section 5.1.2 RSADP in PKCS v2.2
27
for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.1.2(2.b)
28
(ii)&(v), without 5.1.2(1), 5.1.2.(2.a), only supported up to n < 22048
29
30
Signature Generation (with or without CRT): According to section 5.2.1
31
RSASP1 in PKCS v2.2
32
for u = 2, i.e., without any (r_i, d_i, t_i), i >2,
33
therefore without 5.2.1(2.b) (ii)&(v), without 5.2.1(1),
34
5.2.1(2.a) only supported up to n < 22048
35
36
Signature Verification:
37
According to section 5.2.2 RSAVP1 in PKCS v2.2
38
without 5.2.2(1).
39
40
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
41
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this
42
SFR is not applicable.
43
Note:The TOE can be delivered with an optional PSL library. In case no PSL library is available then
44
this SFR is not applicable.
45
46
47
55
Security Target Lite
M9900, M9905, M9906
public
7.3.4 Elliptic Curve DSA (ECDSA) operation
1
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation
2
(FCS_COP.1)” as specified below.
3
4
FCS_COP.1/ECDSA Cryptographic operation
5
Hierarchical to: No other components.
6
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
7
FDP_ITC.2 Import of user data with security attributes, or
8
FCS_CKM.1 Cryptographic key generation]
9
FCS_CKM.4 Cryptographic key destruction
10
FCS_COP.1.1/ECDSA The TSF shall perform signature generation and signature verification in
11
accordance with a specified cryptographic algorithm ECDSA and
12
cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521
13
bits that meet the following standard:
14
15
Signature Generation:
16
According to section 7.3 in ANSI X9.62 – 2005
17
Not implemented is step d) and e) thereof.
18
The output of step e) has to be provided as input to our function by
19
the caller.
20
Deviation of step c) and f):
21
The jumps to step a) were substituted by a return of
22
the function with an error code, the jumps are emulated by another
23
call to our function.
24
25
Signature Verification:
26
According to section 7.4.1 in ANSI X9.62–2005
27
Not implemented is step b) and c) thereof.
28
The output of step c) has to be provided as input to our function by
29
the caller.
30
Deviation of step d):
31
Beside noted calculation, our algorithm adds a random multiple of
32
BasepointerOrder n to the calculated values u1 and u2.
33
34
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
35
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
36
SFR is not applicable.
37
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
38
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
39
applicable.
40
41
42
7.3.5 Elliptic Curve (EC) key generation
43
The key generation for the EC shall meet the requirement “Cryptographic key generation
44
(FCS_CKM.1)”
45
56
Security Target Lite
M9900, M9905, M9906
public
FCS_CKM.1/EC Cryptographic key generation
1
2
Hierarchical to: No other components.
3
Dependencies: FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic
4
operation]
5
FCS_CKM.4 Cryptographic key destruction
6
7
FCS_CKM.1.1/EC The TSF shall generate cryptographic keys in accordance with a specified
8
cryptographic key generation algorithm Elliptic Curve EC specified in ANSI
9
X9.62-2005 and specified cryptographic key sizes 160, 163, 192, 224, 233,
10
256, 283, 320, 384, 409, 512 or 521 bits that meet the following standard:
11
12
ECDSA Key Generation:
13
According to the appendix A4.3 in ANSI X9.62-2005
14
the cofactor h is not supported.
15
16
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
17
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
18
SFR is not applicable.
19
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
20
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
21
applicable.
22
23
7.3.6 Elliptic Curve Diffie-Hellman (ECDH) key agreement
24
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic
25
operation(FCS_COP.1)” as specified below.
26
27
FCS_COP.1/ECDH Cryptographic operation
28
29
Hierarchical to: No other components.
30
31
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
32
FDP_ITC.2 Import of user data with security attributes, or
33
FCS_CKM.1 Cryptographic key generation]
34
FCS_CKM.4 Cryptographic key destruction
35
36
FCS_COP.1.1/ECDH The TSF shall perform elliptic curve Diffie-Hellman key agreement in
37
accordance with a specified cryptographic algorithm ECDH and
38
cryptographic key sizes of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409,
39
512 or 521 bits that meet the following standard:
40
According to section 5.4.1 in ANSI X9.63 – 2001: Unlike section 5.4.1.3 our,
41
implementation not only returns the x-coordinate of the shared secret, but
42
rather the x-coordinate and y-coordinate.
43
44
57
Security Target Lite
M9900, M9905, M9906
public
Note:The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
1
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Other types of
2
elliptic curves can be added by the user during a composite certification process.
3
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
4
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
5
SFR is not applicable.
6
Note:The TOE can be delivered with an optional ECC library. Any optional ECC library contains the
7
ECC algorithms stated above. If no optional ECC library is available then this SFR is not
8
applicable.
9
10
FCS_COP.1/ECDH_PSL Cryptographic operation
11
12
Hierarchical to: No other components.
13
14
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
15
FDP_ITC.2 Import of user data with security attributes, or
16
FCS_CKM.1 Cryptographic key generation]
17
FCS_CKM.4 Cryptographic key destruction
18
19
FCS_COP.1.1/ECDH_PSL The TSF shall perform elliptic curve Diffie-Hellman key agreement in
20
accordance with a specified cryptographic algorithm ECDH and
21
cryptographic key sizes of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409,
22
512 or 521 bits that meet the following standard:
23
According to section 5.4.1 in ANSI X9.63 – 2001: Unlike section 5.4.1.3 our,
24
implementation not only returns the x-coordinate of the shared secret, but
25
rather the x-coordinate and y-coordinate.
26
27
Note:The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
28
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Other types of
29
elliptic curves can be added by the user during a composite certification process.
30
Note:For easy integration of EC functions into the user’s operating system and/or application, the
31
library contains single cryptographic functions respectively primitives which are compliant to
32
the standard. The primitives are referenced above. Therefore, the library supports the user to
33
develop an application representing the standard if required.
34
Note:This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
35
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this
36
SFR is not applicable.
37
Note:The TOE can be delivered with an optional PSL library. Any PSL library contains a special
38
interface to the algorithms stated above.If no optional PSL library is available then this SFR is
39
not applicable.
40
41
7.3.7 Hash function
42
43
58
Security Target Lite
M9900, M9905, M9906
public
The TOE shall meet the requirement “Cryptographic operation – SHA (FCS_COP.1/SHA)” as
1
specified below.
2
3
FCS_COP.1/SHA Cryptographic operation
4
5
Hierarchical to: No other components.
6
7
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
8
FDP_ITC.2 Import of user data with security attributes, or
9
FCS_CKM.1 Cryptographic key generation]
10
FCS_CKM.4 Cryptographic key destruction
11
12
FCS_COP.1.1/ SHA The TSF shall perform hashing in accordance with a specified cryptographic
13
algorithm SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and
14
cryptographic key sizes none that meet the following FIPS 180-4 [SHS].
15
Note:The TOE can be delivered with the optional HCL library. The optional HCL library contains the
16
hash algorithms stated above. If the optional HCLlibrary is not delivered then this SFR is not
17
applicable.
18
Note:This SFR claims countermeasures against SPA template attacks
19
Note:The SHA-1 algorithm shall only be used for session key derivation
20
FCS_COP.1/SHA_PSL Cryptographic operation
21
22
Hierarchical to: No other components.
23
24
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
25
FDP_ITC.2 Import of user data with security attributes, or
26
FCS_CKM.1 Cryptographic key generation]
27
FCS_CKM.4 Cryptographic key destruction
28
29
FCS_COP.1.1/ SHA_PSL The TSF shall perform hashing in accordance with a specified
30
cryptographic algorithm SHA-1, SHA-224, SHA-256, SHA-384, SHA-
31
512 and cryptographic key sizes none that meet the following FIPS
32
180-4 [SHS].
33
Note:The TOE can be delivered with the optional PSL library v5.00.06. If the optional PSL library
34
v5.00.06 is not available then this SFR is not applicable.
35
Note:The SHA-1 algorithm shall only be used for session key derivation
36
37
7.4 Data Integrity
38
The TOE shall meet the requirement “Stored data integrity monitoring (FDP_SDI.1)” as specified
39
below:
40
41
FDP_SDI.1 Stored data integrity monitoring
42
43
Hierarchical to: No other components
44
45
Dependencies: No dependencies
46
59
Security Target Lite
M9900, M9905, M9906
public
1
FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the TSF
2
for inconsistencies between stored data and corresponding EDC on all
3
objects, based on the following attributes: EDC value for RAM and ROM and
4
ECC value for the SOLID FLASH™ NVM and verification of stored data in the
5
SOLID FLASH™ NVM.
6
7
The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as
8
specified below:
9
10
FDP_SDI.2 Stored data integrity monitoring and action
11
12
Hierarchical to: FDP_SDI.1 stored data integrity monitoring
13
14
Dependencies: No dependencies
15
16
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF
17
for data integrity and one- and/or more-bit-errors on all objects, based on
18
the following attributes: corresponding EDC value for RAM and ROM and
19
error correction ECC for the SOLID FLASH™ NVM.
20
21
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall correct 1 bit errors in
22
the SOLID FLASH™ NVM automatically and inform the user about more bit
23
errors.
24
25
7.5 TOE Security Assurance Requirements
26
The evaluation assurance level is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5. In the
27
following table, the security assurance requirements are given. The augmentation of the
28
assurance components compared to the Protection Profile [1] is expressed with bold letters.
29
Table 17 Assurance components
30
Aspect Acronym Description Refinement
Development ADV_ARC.1 Security Architecture Description in PP [1]
ADV_FSP.5 Complete semiformal functional
specification with additional error
information
in ST
ADV_IMP.1 Implementation representation of the
TSF
in PP [1]
ADV_INT.2 Well-structured internals
ADV_TDS.4 Semi-formal modular design
Guidance Documents AGD_OPE.1 Operational user guidance in PP [1]
AGD_PRE.1 Preparative procedures in PP [1]
Life-Cycle Support ALC_CMC.4 Production support, acceptance
procedures and automation
in PP [1]
ALC_CMS.5 Development tools CM coverage in ST
60
Security Target Lite
M9900, M9905, M9906
public
ALC_DEL.1 Delivery procedures in PP [1]
ALC_DVS.2 Sufficiency of security measures in PP [1]
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.2 Compliance with implementation
standards
in ST
Security Target
Evaluation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
Tests ATE_COV.2 Analysis of coverage in PP [1]
ATE_DPT.3 Testing: modular design in ST
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability
Assessment
AVA_VAN.5 Advanced methodical vulnerability
analysis
in PP [1]
7.5.1 Refinements
1
Some refinements are taken unchanged from the PP [1]. In some cases a clarification is necessary.
2
In Table 19 an overview is given where the refinement is done.
3
Two refinements from the PP [1] 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 [1] can be applied even at the chosen assurance level EAL 5 augmented
7
with ALC_CMS.5 and ALC_TAT.2. The assurance package ALC_CMS.4 is extended to ALC_CMS.5 with
8
aspects regarding the configuration control system for the TOE. The assurance package ALC_TAT.1
9
is extended to ALC_TAT.2 with aspects regarding the implementation standards for the TOE. The
10
refinements are not touched.
11
Functional Specification (ADV_FSP)
12
The refinement from the PP [1] can be applied even at the chosen assurance level EAL 5 augmented
13
with ADV_FSP.5. The assurance package ADV_FSP.4 is extended to ADV_FSP.5 with aspects
14
regarding the descriptive level. The level is increased from informal to semi-formal with informal
15
description. The refinement is not touched from this measure.
16
For details of the refinement see PP [1].
17
Tests (ATE_DPT.3)
18
61
Security Target Lite
M9900, M9905, M9906
public
The refinement from the PP [1] can be applied even at the chosen assurance level EAL 5 augmented
1
with ATE_DPT.3. The assurance package ATE_DPT.2 is augmented to ATE_DPT.3 relating to the
2
requirements of the assurance level EAL 5. The refinement is not touched.
3
4
7.6 Security Requirements Rationale
5
7.6.1 Rationale for the Security Functional Requirements
6
The security functional requirements rationale of the TOE are defined and described in PP [1]
7
section 6.3 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1,
8
FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1/HW, FCS_RNG.1/PSL and
9
FAU_SAS.1.
10
The security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3,
11
FMT_SMF.1, FCS_COP.1, FCS_CKM.1, FDP_SDI.1 and FDP_SDI.2 are defined in the following
12
description:
13
14
Table 18 Rational for additional
15
SFR in the ST
16
Objective TOE Security Functional Requirements
O.Add-Functions
(optional)
FCS_COP.1/DES (optional)
FCS_COP.1/DES_SCL_1 (optional)
FCS_COP.1/DES_SCL_2 (optional)
FCS_COP.1/DES_SCL_3 (optional)
FCS_COP.1/DES_PSL (optional)
FCS_COP.1/DES_MAC_PSL (optional)
FCS_COP.1/AES (optional)
FCS_COP.1/AES_SCL_1 (optional)
FCS_COP.1/AES_SCL_2 (optional)
FCS_COP.1/AES_SCL_3 (optional)
FCS_COP.1/AES_PSL (optional)
FCS_COP.1/AES_MAC_PSL_1 (optional)
FCS_COP.1/AES_MAC_PSL_2 (optional)
FCS_COP.1/RSA(optional)
FCS_COP.1/RSA_PSL (optional)
FCS_COP.1/ECDSA (optional)
FCS_COP.1/ECDH (optional)
FCS_COP.1/ECDH_PSL (optional)
FCS_CKM.1/EC (optional)
FCS_COP.1/SHA (optional)
FCS_COP.1/SHA_PSL (optional)
O.Phys-Manipulation FPT_TST.2
O.Mem-Access FDP_ACC.1
FDP_ACF.1
FMT_MSA.3
FMT_MSA.1
62
Security Target Lite
M9900, M9905, M9906
public
FMT_SMF.1
O.Malfunction FDP_SDI.1
FDP_SDI.2
1
The table above gives an overview, how the security functional requirements are combined to meet
2
the security objectives. The detailed justification is given in the following:
3
The justification related to the security objective “Additional Specific Security Functionality
4
(O.Add-Functions)” is as follows:
5
The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly requires
6
those functions to be implemented which are demanded by O.Add-Functions. FCS_CKM.1/EC
7
supports the generation of EC keys needed for this cryptographic operations. Therefore,
8
FCS_COP.1/RSA, FCS_COP.1/RSA_PSL, FCS_COP.1/ECDSA, FCS_COP.1/ECDH, FCS_COP.1/ECDH_PSL
9
and FCS_CKM/EC are suitable to meet the security objective. The use of the supporting Base library
10
has no impact on any security functional requirement nor does its use generate additional
11
requirements.
12
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
13
functions are used as specified and that the User Data processed by these functions are protected as
14
defined for the application context. These issues are addressed by the specific security functional
15
requirements:
16
 [FDP_ITC.1 Import of user data without security attributes or
17
FDP_ITC.2 Import of user data with security attributes or
18
FCS_CKM.1 Cryptographic key generation],
19
 FCS_CKM.4 Cryptographic key destruction.
20
All these requirements have to be fulfilled to support OE.Resp-Appl for FCS_COP.1/DES,
21
FCS_COP.1/DES_SCL_1, FCS_COP.1/DES_SCL_2, FCS_COP.1/DES_SCL_3,FCS_COP.1/DES_PSL,
22
FCS_COP.1/DES_MAC_PSL and for FCS_COP.1/AES, FCS_COP.1/AES_SCL_1, FCS_COP.1/AES_SCL_2,
23
FCS_COP.1/AES_SCL_3, FCS_COP.1, FCS_COP.1/AES_PSL, FCS_COP.1/AES_MAC_PSL_1,
24
FCS_COP.1/AES_MAC_PSL_2. For the FCS_COP.1/RSA, FCS_COP.1/RSA _PSL and FCS_COP.1/ECDSA ,
25
and FCS_COP.1/ECDH, FCS_COP.1/ECDH_PSL and the FCS_CKM.1/EC are optional, since they are
26
fulfilled by the TOE or may be fulfilled by the environment as the user can generate keys externally
27
additionally.
28
The security functional requirements required to meet the security objectives O.Leak-Inherent,
29
O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement
30
the specific security functionality. However, key-dependent functions could be implemented in the
31
Smartcard Embedded Software.
32
The usage of cryptographic algorithms requires the use of appropriate keys. Otherwise these
33
cryptographic functions do not provide security. The keys have to be unique with a very high
34
probability, and must have a certain cryptographic strength etc. In case of a key import into the TOE
35
(which is usually after TOE delivery) it has to be ensured that quality and confidentiality are
36
maintained. Keys for 3DES and AES are provided by the environment, the keys for RSA and EC
37
algorithms can be provided either by the TOE or the environment.
38
In this ST the objectives for the environment OE.Plat-Appl and OE.Resp-Appl have been clarified.
39
The Smartcard Embedded Software defines the use of the cryptographic functions FCS_COP.1
40
provided by the TOE. The requirements for the environment FDP_ITC.1, FDP_ITC.2, FCS_CKM.1 and
41
FCS_CKM.4 support an appropriate key management. These security requirements are suitable to
42
meet OE.Resp-Appl.
43
63
Security Target Lite
M9900, M9905, M9906
public
The justification of the security objective and the additional requirements (both for the TOE and its
1
environment) show that they do not contradict to the rationale already given in the Protection
2
Profile for the assumptions, policy and threats defined there.
3
The security functional component Subset TOE security testing (FPT_TST.2) has been newly
4
created (Common Criteria Part 2 extended). This component allows that particular parts of the
5
security mechanisms and functions provided by the TOE can be tested after TOE Delivery. This
6
security functional component is used instead of the functional component FPT_TST.1 from
7
Common Criteria Part 2. For the user it is important to know which security functions or
8
mechanisms can be tested. The functional component FPT_TST.1 does not mandate to explicitly
9
specify the security functions being tested. In addition, FPT_TST.1 requires verification of the
10
integrity of TSF data and stored TSF executable code which might violate the security policy.
11
The tested security enforcing functions are SF_DPM Device Phase Management and SF_PMA
12
Protection against modifying attacks.
13
The security functional requirement FPT_TST.2 will detect attempts to conduce a physical
14
manipulation on the monitoring functions of the TOE. The objective of FPT_TST.2 is O.Phys-
15
Manipulation. The physical manipulation will be tried to overcome security enforcing functions.
16
The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security
17
Function Policy (SFP) “Memory Access Control Policy” exactly require the implementation of an
18
area based memory access control as required by O.Mem-Access. The related TOE security
19
functional requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1 and FMT_SMF.1 cover this
20
security objective. The implementation of these functional requirements is represented by the
21
dedicated privilege level concept.
22
The justification of the security objective and the additional requirements show that they do not
23
contradict to the rationale already given in the Protection Profile for the assumptions, policy and
24
threats defined there. Moreover, these additional security functional requirements cover the
25
requirements by [3] user data protection of chapter 11 which are not refined by the PP [1].
26
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
27
functions are used as specified and that the User Data processed by these functions are protected as
28
defined for the application context. The TOE only provides the tool to implement the policy defined
29
in the context of the application.
30
The justification related to the security objective “Protection against Malfunction due to
31
Environmental Stress (O.Malfunction)” is as follows:
32
The security functional requirement “Stored data integrity monitoring (FDP_SDI.1)” requires the
33
implementation of an Error Detection (EDC) algorithm which detects integrity errors of the data
34
stored in RAM, ROM and SOLID FLASH™ NVM (in the SOLID FLASH™ NVM more bit errors are
35
detected). By this the malfunction of the TOE using corrupt data is prevented. Therefore FDP_SDI.1
36
is suitable to meet the security objective.
37
The security functional requirement “Stored data integrity monitoring and action (FDP_SDI.2)”
38
requires the implementation of an integrity observation and correction which is implemented by
39
the Error Detection (EDC) and Error Correction (ECC) measures. The EDC is present in RAM and
40
ROM of the TOE while the ECC is realized in the SOLID FLASH™ NVM. These measures detect and
41
inform about one and more bit errors. In case of the SOLID FLASH™ NVM 1 bit errors of the data are
42
corrected automatically. By the ECC mechanisms it is prevented that the TOE uses corrupt data.
43
Therefore FDP_SDI.2 is suitable to meet the security objective.
44
The CC part 2 defines the component FIA_SOS.2, which is similar to FCS_RNG.1, as follows:
45
46
FIA_SOS.2 TSF Generation of secrets
47
64
Security Target Lite
M9900, M9905, M9906
public
Hierarchical to: No other components.
1
Dependencies: No dependencies.
2
FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet
3
[assignment:defined quality metric].
4
FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for
5
[assignment: list of TSF functions].
6
7
The CC part 2, annex G.3 [3], states: “This family defines requirements for mechanisms that enforce
8
defined quality metrics on provided secrets, and generate secrets to satisfy the defined metric“.
9
Even the operation in the element FIA_SOS.2.2 allows listing the TSF functions using the generated
10
secrets. Because all applications discussed in annex G.3 are related to authentication, the
11
component FIA_SOS.2 is also intended for authentication purposes while the term “secret” is not
12
limited to authentication data (cf. CC part 2, paragraphs 39-42).
13
Paragraph 685 in the CC part 2 [3] recommends to use the component FCS_CKM.1 to address
14
random number generation. However, this may hide the nature of the secrets used for key
15
generation and does not allow describing random number generation for other cryptographic
16
methods (e.g., challenges, padding), authentication (e.g., password seeds), or other purposes (e.g.,
17
blinding as a countermeasure against side channel attacks).
18
The component FCS_RNG addresses general RNG, the use of which includes but is not limited to
19
cryptographic mechanisms. FCS_RNG allows specifying requirements for the generation of random
20
numbers including necessary information for the intended use. These details describe the quality of
21
the generated data where other security services rely on. Thus by using FCS_RNG a ST or PP author
22
is able to express a coherent set of SFRs that include or use the generation of random numbers as a
23
security service.
24
25
7.6.1.1 Dependencies of Security Functional Requirements
26
The dependence of security functional requirements are defined and described in PP [1] section
27
6.3.2 for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1,
28
FPT_PHP.3, FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1/HW, FCS_RNG.1/PSL and
29
FAU_SAS.1.
30
The dependence of security functional requirements for the security functional requirements
31
FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1,
32
FDP_SDI.1 and FDP_SDI.2 are defined in the following description.
33
34
Table 19 Dependency for
35
cryptographic operation
36
requirement
37
Security Functional
Requirement
Dependencies Fulfilled by security
requirements
FCS_COP.1/DES
FCS_COP.1/DES_SCL_1
FCS_COP.1/DES_SCL_2
FCS_COP.1/DES_SCL_3
FCS_COP.1/DES_PSL
FCS_COP.1/DES_MAC_PSL
FCS_CKM.1 Yes, see comment
FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1)
FCS_CKM.4
Yes, see comment
65
Security Target Lite
M9900, M9905, M9906
public
1
Note:The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3
2
is considered to be satisfied because the access control specified for the intended TOE is not
3
role-based but enforced for each subject. Therefore, there is no need to identify roles in form
4
of a security functional requirement FMT_SMR.1.
5
Comment: The security functional requirement “Cryptographic operation (FCS_COP.1)” met by the
6
TOE, has the following dependencies:
7
 [FDP_ITC.1 Import of user data without security attributes, or
8
FCS_COP.1/AES
FCS_COP.1/AES_SCL_1
FCS_COP.1/AES_SCL_2
FCS_COP.1/AES_SCL_3
FCS_COP.1/AES_PSL
FCS_COP.1/AES_MAC_PSL_1
FCS_COP.1/AES_MAC_PSL_2
FCS_CKM.1 Yes, see comment
FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1)
FCS_CKM.4
Yes, see comment
FCS_COP.1/RSA
FCS_COP.1/RSA_PSL
FCS_CKM.1 Yes, see comment
FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1)
FCS_CKM.4
Yes, see comment
FCS_COP.1/ECDSA FCS_CKM.1 Yes, see comment
FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1)
FCS_CKM.4
Yes, see comment
FCS_CKM.1/EC FCS_CKM.2 or FCS_COP.1 Yes
FCS_CKM.4 Yes, see comment
FCS_COP.1/ECDH
FCS_COP.1/ECDH_PSL
FCS_CKM.1 Yes, see comment
FDP_ITC.1 or FDP_ITC.2 (if not FCS_CKM.1)
FCS_CKM.4
Yes, see comment
FCS_COP.1/SHA
FCS_COP.1/SHA_PSL
FCS_CKM.1, FDP_ITC.1 or FDP_ITC.2 (if not
FCS_CKM.1), FCS_CKM.4
Not required,
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
66
Security Target Lite
M9900, M9905, M9906
public
 FDP_ITC.2 Import of user data with security attributes]
1
 FCS_CKM.1 Cryptographic key generation
2
 FCS_CKM.4 Cryptographic key destruction.
3
The security functional requirement “Cryptographic key management (FCS_CKM)” met by TOE, has
4
the following dependencies:
5
 [FCS_CKM.2 Cryptographic key distribution, or
6
 FCS_COP.1 Cryptographic operation]
7
 FCS_CKM.4 Cryptographic key destruction.
8
These requirements all address the appropriate management of cryptographic keys used by the
9
specified cryptographic function and are not part of the PP [1]. Most requirements concerning key
10
management shall be fulfilled by the environment since the Smartcard Embedded Software is
11
designed for a specific application context and uses the cryptographic functions provided by the
12
TOE.
13
For the security functional requirement FCS_COP.1/DES, FCS_COP.1/DES_SCL_1,
14
FCS_COP.1/DES_SCL_2, FCS_COP.1/DES_SCL_3,FCS_COP.1/DES_PSL, FCS_COP.1/DES_MAC_PSL and
15
FCS_COP.1/AES, FCS_COP.1/AES_SCL_1, FCS_COP.1/AES_SCL_2, FCS_COP.1/AES_SCL_3,
16
FCS_COP.1/AES_PSL, FCS_COP.1/AES_MAC_PSL_1, FCS_COP.1/AES_MAC_PSL_2 the respective
17
dependencies FCS_CKM.1, FCS_CKM.4 and FDP_ITC.1 or FDP_ITC.2 have to be fulfilled by the
18
environment. That mean, that the environment shall meet the requirements FCS_CKM.1 and
19
FCS_CKM.4 as defined in [3], section 10.1 and shall meet the requirements FDP_ITC.1 or FDP_ITC.2
20
as defined in [3], section 11.7.
21
For the security functional requirement FCS_COP.1/RSA, FCS_COP.1/RSA_PSL, FCS_COP.1/ECDSA,
22
and FCS_COP.1/ECDH, FCS_COP.1/ECDH_PSL, the respective dependencies FCS_CKM.4 and
23
FDP_ITC.1 or FDP_ITC.2 have to be fulfilled by the environment. That mean, that the environment
24
shall meet the requirements FDP_ITC.1 or FDP_ITC.2 as defined in [3], section 11.7.
25
For the security functional requirement FCS_COP.1/RSA, FCS_COP.1/RSA_PSL, FCS_COP.1/ECDSA,
26
and FCS_COP.1/ECDH, the respective dependency FCS_CKM.1 has to be fulfilled by the TOE with the
27
security functional requirement FCS_CKM.1/EC (for FCS_COP.1/ECDSA and FCS_COP.1/ECDH) as
28
defined in section 7.1.4. Additionally the requirement FCS_CKM.1 can be fulfilled by the
29
environment as defined in [3], section 10.1.
30
For the security functional requirement FCS_COP.1/RSA , FCS_CKM.1 has to be fulfilled by the
31
environment.
32
For the security functional requirement FCS_COP.1/ECDH_PSL, the respective dependency
33
FCS_CKM.1 does not apply, because the PSL does not provide a key generation operation for elliptic
34
curves.
35
For the security functional requirement FCS_CKM.1/EC the respective dependency FCS_COP.1 is
36
fulfilled by the TOE. The respective dependency FCS_CKM.4 has to be fulfilled by the environment.
37
That means, the environment shall meet the requirement FCS_CKM.4 as defined in [3], section 10.1.
38
For the security functional requirement FCS_COP.1/SHA and FCS_COP.1/SHA_PSL the respective
39
dependencies are not applicable, because no keys are involved.
40
The cryptographic libraries RSA and EC are delivery options. If one of the libraries RSA, EC are
41
delivered, the asymmetric Base Lib is automatically part of it. Therefore the user may choose a free
42
combination of these libraries. In case of deselecting one or several of these libraries the TOE does
43
not provide the respective functionality Additional Specific Security Functionality Rivest-Shamir-
44
Adleman Cryptography (RSA) and/or Elliptic Curve Cryptography (EC). The asymmetric Base
45
Library is no directly accessible cryptographic library and provides no additional specific security
46
functionality.
47
67
Security Target Lite
M9900, M9905, M9906
public
End of comment.
1
2
7.6.2 Rationale of the Assurance Requirements
3
The chosen assurance level EAL5 and the augmentation with the requirements ALC_DVS.2 and
4
AVA_VAN.5 were chosen in order to meet the assurance expectations explained in the following
5
paragraphs. In Table 17 the different assurance levels are shown as well as the augmentations. The
6
augmentations are in compliance with the Protection Profile.
7
An assurance level EAL5 with the augmentations ALC_DVS.2 and AVA_VAN.5 are required for this
8
type of TOE since it is intended to defend against highly sophisticated attacks without protective
9
environment. This evaluation assurance package was selected to permit a developer to gain
10
maximum assurance from positive security engineering based on good commercial practices. In
11
order to provide a meaningful level of assurance that the TOE provides an adequate level of defence
12
against such attacks, the evaluators should have access to all information regarding the TOE
13
including the TSF internals, the low level design and source code including the testing of the
14
modular design. Additionally the mandatory technical document “Application of Attack Potential to
15
Smartcards” [10] shall be taken as a basis for the vulnerability analysis of the TOE.
16
17
18
ALC_DVS.2 Sufficiency of security measures
19
Development security is concerned with physical, procedural, personnel and other technical
20
measures that may be used in the development environment to protect the TOE.
21
In the particular case of a Security IC the TOE is developed and produced within a complex and
22
distributed industrial process which must especially be protected. Details about the
23
implementation, (e.g. from design, test and development tools as well as Initialization Data) may
24
make such attacks easier. Therefore, in the case of a Security IC, maintaining the confidentiality of
25
the design is very important.
26
This assurance component is a higher hierarchical component to EAL5 (which only requires
27
ALC_DVS.1). ALC_DVS.2 has no dependencies.
28
68
Security Target Lite
M9900, M9905, M9906
public
AVA_VAN.5 Advanced methodical vulnerability analysis
1
Due to the intended use of the TOE, it must be shown to be highly resistant to penetration attacks.
2
This assurance requirement is achieved by the AVA_VAN.5 component.
3
Independent vulnerability analysis is based on highly detailed technical information. The main
4
intent of the evaluator analysis is to determine that the TOE is resistant to penetration attacks
5
performed by an attacker possessing high attack potential.
6
AVA_VAN.5 has dependencies to ADV_ARC.1 “Security architecture description”, ADV_FSP.2
7
“Security enforcing functional specification”, ADV_TDS.3 “Basic modular design”, ADV_IMP.1
8
“Implementation representation of the TSF”, AGD_OPE.1 “Operational user guidance”, and
9
AGD_PRE.1 “Preparative procedures”.
10
All these dependencies are satisfied by EAL5.
11
It has to be assumed that attackers with high attack potential try to attack Security ICs like smart
12
cards used for digital signature applications or payment systems. Therefore, specifically AVA_VAN.5
13
was chosen in order to assure that even these attackers cannot successfully attack the TOE.
14
15
69
Security Target Lite
M9900, M9905, M9906
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 following Security Features to meet the security functional requirements:
4
 SF_DPM Device Phase Management
5
 SF_PS Protection against Snooping
6
 SF_PMA Protection against Modification Attacks
7
 SF_PLA Protection against Logical Attacks
8
 SF_CS Cryptographic Support
9
10
The following description of the Security Features is a complete representation of the TSF.
11
8.1 SF_DPM: Device Phase Management
12
The life cycle of the TOE is split-up in several phases. Chip development and production (phase 2, 3,
13
4) and final use (phase 4-7) is a rough split-up from TOE point of view. These phases are
14
implemented in the TOE as test mode (phase 3) and user mode (phase 4-7).
15
In addition a chip identification mode exists which is active in all phases. The chip identification
16
data (O.Identification) is stored in a in the not changeable configuration page area and non-volatile
17
memory. In the same area further TOE configuration data is stored. In addition, user initialization
18
data can be stored in the non-volatile memory during the production phase as well. During this first
19
data programming, the TOE is still in the secure environment and in Test Mode.
20
The covered security functional requirement is FAU_SAS.1 “Audit storage”.
21
During start-up of the TOE the decision for one of the operation modes is taken dependent on phase
22
identifiers. The decision of accessing a certain mode is defined as phase entry protection. The
23
phases follow also a defined and protected sequence. The sequence of the phases is protected by
24
means of authentication.
25
The covered security functional requirements are FMT_LIM.1 “Limited capabilities” and FMT_LIM.2
26
“Limited availability”.
27
During the production phase (phase 3 and 4) or after the delivery to the customer (phase 5 or
28
phase 6), the TOE provides the possibility to download a user specific encryption key and user code
29
and data into the empty (erased) SOLID FLASH™ NVM memory area as specified by the associated
30
control information of the Flash Loader software. After finishing the load operation, the Flash
31
Loader can be permanently deactivated, so that no further load operation with the Flash Loader is
32
possible. These procedures are defined as phase operation limitation.
33
The covered security functional requirement is FMT_LIM.2 “Limited availability”.
34
During operation within a phase the accesses to memories are granted by the MPU controlled
35
access rights and related levels.
36
The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1
37
“Security attribute based access control” and FMT_MSA.1 “Management of security attributes”.
38
In addition, during each start-up of the TOE the address ranges and access rights are initialized by
39
the Boot Software (BOS) with predefined values.
40
The covered security functional requirement is FMT_MSA.3 “Static attribute initialisation”.
41
The TOE clearly defines access rights and levels in conjunction with the appropriate key
42
management in dependency of the firmware or software to be executed.
43
The covered security functional requirement is FMT_SMF.1 “Specification of Management
44
functions”.
45
70
Security Target Lite
M9900, M9905, M9906
public
Each operation phase is protected by means of authentication and encryption.
1
The covered security functional requirements are FPT_ITT.1 “Basic internal TSF data transfer
2
protection” and FDP_IFC.1 “Subset information flow control”. If any comparison of the
3
authentication code fails a direct security reset is performed. The covered security functional
4
requirements is FPT_FLS.1 (”Failure with preservation of secure state”).
5
The SF_DPM “Device Phase Management” covers the security functional requirements FPT_FLS.1,
6
FAU_SAS.1, FMT_LIM.1, FMT_LIM.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1,
7
FPT_ITT.1 and FDP_IFC.1.
8
9
8.2 SF_PS: Protection against Snooping
10
Several mechanisms protect the TOE against snooping the design or the user data during operation
11
and even if it is out of operation (power down).
12
The entire design is kept in a non standard way to prevent attacks using standard analysis methods.
13
Important parts of the chip are especially designed to counter leakage or side channel attacks like
14
DPA/SPA or EMA/DEMA. Therefore, even the physical data gaining is difficult to perform, since
15
timing and current consumption is independent of the processed data. In the design a number of
16
components are automatically synthesized and mixed up to disguise an attacker and to make an
17
analysis more difficult.
18
The covered security functional requirement is FPT_PHP.3 “Resistance to physical attack”.
19
A further protective design method used is secure wiring. All security critical wires have been
20
identified and protected by special routing measures against probing. Additionally the wires are
21
embedded into shield lines and used as normal signal lines for operation of the chip to prevent
22
successful probing. This measurement is called “security optimized wiring”.
23
The covered security functional requirements are FPT_PHP.3 “Resistance to physical attack”,
24
FPT_ITT.1 “Basic internal TSF data transfer protection”, FPT_FLS.1 “Failure with preservation of
25
secure state” and FDP_ITT.1 “Basic internal transfer protection”.
26
All contents of the memories RAM, ROM and SOLID FLASH™ NVM of the TOE are encrypted on chip
27
to protect them against data analysis. The external Flash-memory is not encrypted and not a part of
28
the security functional requirements.
29
In addition the data transferred over the memory bus to and from (bi-directional encryption) the
30
CPU, Co-processor (Crypto2304T and SCP), the special SFRs and the peripheral devices (CRC, RNG
31
and Timer) are transported encrypted with an automatically dynamic key change.
32
The encryption of the memory content is done by the MED using a proprietary cryptographic
33
algorithm and a complex key management providing protection against cryptographic analysis
34
attacks. This means that the SOLID FLASH™ NVM, RAM, ROM and the bus are encrypted with
35
module dedicated and dynamic keys. The only key remaining static over the product life cycle is the
36
specific ROM key changing from mask to mask.
37
All security relevant transfer of addresses or data via the peripheral bus is dynamically masked and
38
thus protected against readout and analysis.
39
The function Trash Register Writes can be activated by the user to hide the fact if a register has
40
been written.
41
The covered security functional requirements are FDP_IFC.1 “Subset information flow control“,
42
FPT_PHP.3 “Resistance to physical attack”, FPT_ITT.1 “Basic internal TSF data transfer protection,
43
FPT_FLS.1 “Failure with preservation of secure state” and FDP_ITT.1 “Basic internal transfer
44
protection”.
45
46
The SF_PS “Protection against Snooping” covers the security functional requirements FPT_PHP.3,
47
FDP_IFC.1, FPT_ITT.1, FPT_FLS.1 and FDP_ITT.1.
48
71
Security Target Lite
M9900, M9905, M9906
public
8.3 SF_PMA: Protection against Modifying Attacks
1
The TOE is equipped with an error detection code (EDC) for protecting RAM and ROM and an ECC,
2
which is realized in the SOLID FLASH™ NVM. Thus introduced failures are securely detected and, in
3
terms of single bit errors in the SOLID FLASH™ NVM also automatically corrected (FDP_SDI.2). For
4
SOLID FLASH™ NVM in case of more than one bit errors and for RAM in case of any bit errors
5
detected, a security alarm is triggered.
6
In order to prevent accidental bit faults during production in the ROM, over the data stored in ROM
7
an EDC value is calculated (FDP_SDI.1).
8
The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance“, FDP_PHP.3
9
“Resistance to physical attack“, FDP_SDI.1 “Stored data integrity monitoring” and FDP_SDI.2 “Stored
10
data integrity monitoring and action”.
11
If a user tears the card resulting in a power off situation during an SOLID FLASH™ NVM
12
programming operation or if other perturbation is applied, no data or content loss occurs and the
13
TOE restarts power on. The NVM tearing save write functionality covers FDP_SDI.1 “Stored data
14
integrity monitoring” as the new data to be programmed are checked for integrity and correct
15
programming before the page with the old data becomes valid.
16
17
The covered security functional requirement are FPT_PHP.3 “Resistance to physical attack“, since
18
these measures make it difficult to manipulate the write process of the NVM, FPT_FLS.1 “Failure
19
with preservation of secure state“and FDP_SDI.1 “Stored data integrity monitoring”.
20
In the case that a physical manipulation or a physical probing attack is detected, the processing of
21
the TOE is immediately stopped and the TOE enters a secure state called security reset.
22
A shielding algorithm finishes the upper layers above security critical signals and wires, finally
23
providing the so called “security optimized wiring”.
24
25
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure
26
state”, FPT_PHP.3 “Resistance to physical attack” and FPT_TST.2 “Subset TOE security testing“.
27
As physical effects or manipulative attacks may also address the program flow of the user software,
28
two watchdog timers each with a check point register function are implemented. This feature
29
allows the user to check the correct processing time and the integrity of the program flow of the
30
user software.
31
The Instruction Stream Signature Checking (ISS) calculates a hash about all executed instructions
32
and automatically checks the correctness of this hash value. If the code execution follows an illegal
33
path an alarm is triggered.
34
Another measure against modifying and perturbation respectively differential fault attacks (DFA) is
35
the implementation of backward calculation in the SCP. By this induced errors are discovered.
36
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure
37
state”, FDP_IFC.1 “Subset information flow control”, FPT_ITT.1 “Basic internal transfer protection”,
38
FDP_ITT.1 “Basic internal transfer protection” and FPT_PHP.3 “Resistance to physical attack”.
39
During start up, the TOE performs various configurations and subsystem tests. After the TOE
40
startup has finished, the operating system or application can call the User Mode Security Life
41
Control (UMSLC) test provided by the Resource Management System. The UMSLC checks the alarm
42
lines and/or the different security functions and sensors for correct operation. The test can be
43
triggered by user software during normal operation. As attempts to modify the security features
44
will be detected from the test, the covered security functional requirement is FPT_TST.2 “Subset
45
TOE security testing“.
46
72
Security Target Lite
M9900, M9905, M9906
public
The correct function of the TOE is only given in the specified range of the environmental operating
1
parameters. To prevent an attack exploiting that circumstance the TOE is equipped with a
2
temperature sensor, glitch sensor and backside light detection. The TOE falls into the defined
3
secure state in case of a specified range violation. The defined secure state causes the chip internal
4
reset process. Note that the specified range checking can only work when the TOE is running and
5
can not prevent reverse engineering.
6
The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance” and
7
FPT_FLS.1 “Failure with preservation of secure state“.
8
The SF_PMA “Protection against Modifying Attacks” covers the security functional requirements
9
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
10
FPT_FLS.1.
11
12
8.4 SF_PLA: Protection against Logical Attacks
13
The memory model of the TOE provides two distinct, independent levels called the privileged and
14
non-privilege level and the possibility to define up to eight memory regions with different access
15
rights enforced by the Management Protection Unit (MPU). This gives the user software the
16
possibility to define different access rights for the regions 0 to 7 for privilege or non-privilege level.
17
In the case of an access violation the MPU will trigger a trap. The policy of setting up the MPU and
18
specifying the memory ranges for the regions (0 to 7) is defined from the user software.
19
The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1
20
“Security attribute based access control”, FMT_MSA.1 “Management of security attributes”,
21
FMT_MSA.3 “Static attribute initialisation” and FMT_SMF.1 “Specification of Management
22
functions”.
23
All memories present on the TOE (NVM, ROM, RAM) are encrypted using individual keys assigned
24
by complex key management. In case of security critical error a security alarm is generated and the
25
TOE ends up in a secure state.
26
The covered security functional requirements are FDP_ACF.1 “Security attribute based access
27
control” and FPT_FLS.1 “Failure with preservation of secure state”.
28
The SF_PLA “Protection against Logical Attacks” covers the security functional requirements
29
FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FPT_FLS.1 and FMT_SMF.1.
30
31
8.5 SF_CS: Cryptographic Support
32
The TOE is equipped an asymmetric and a symmetric hardware accelerators to support the
33
standard symmetric and asymmetric cryptographic operations. This security function is introduced
34
to include the cryptographic operation in the scope of the evaluation as the cryptographic function
35
respectively mathematic algorithm itself is not used from the TOE security policy. The components
36
are a co-processor supporting the DES and AES algorithms and a co-processor and software
37
modules to support RSA cryptography, EC signature generation and verification, ECDH key
38
agreement and EC public key calculation and testing. Additionally the TOE is equipped with a True
39
Random Number Generator for the generation of random numbers.
40
8.5.1 3DES encryption
41
The TOE supports the encryption and decryption in accordance with the specified cryptographic
42
algorithm Triple Data Encryption Standard (3DES) in the Electronic Codebook Mode (ECB), Cipher
43
Block Chaining Mode (CBC), Cipher Feedback Mode (CFB), Counter Mode (CTR) and CMAC mode
44
and with cryptographic key sizes of 112 and 168 bit meeting the standard: [N867], [N38A], [N38B].
45
73
Security Target Lite
M9900, M9905, M9906
public
The covered security functional requirements are FCS_COP.1/DES, FCS_COP.1/DES_SCL_1,
1
FCS_COP.1/DES_SCL_2, FCS_COP.1/DES_SCL_3, and FCS_COP.1/DES_ PSL
2
3
This SFR is implemented in 3 ways:
4
1. By directly programming the hardware registers of the symmetric coprocessor.
5
2. By using the interface of the optional SCL. This library contains additional countermeasures.
6
3. By using the interface of the optional PSL. This library uses the SCL library to access the
7
symmetric coprocessor.
8
8.5.2 3DES MAC
9
The TSF supports MAC calculation with the cryptographic algorithm Triple Data Encryption
10
Standard (3DES) in CBC MAC mode and cryptographic key sizes of 2 x 56 or 3 x 56 bit according to
11
the standards: [N867], [9797] with the following options/modifications:
12
 MAC algorithm 1
13
 Padding must be done by the caller
14
 An Initialization Vector (IV) must be given by the caller
15
 The covered security functional requirements are FCS_COP.1/DES_MAC_PSL
16
8.5.3 AES encryption
17
The TSF supports the encryption and decryption in accordance with the specified cryptographic
18
algorithm Advanced Encryption Standard (AES) ) in the Electronic Codebook Mode (ECB), Cipher
19
Block Chaining Mode (CBC), Cipher Feedback Mode (CFB), CTR (Counter) Mode and CMAC mode
20
and cryptographic key sizes of 128 bit or 192 bit or 256 bit according to the standard: [N197],
21
[N38A], [N38B].
22
The covered security functional requirement is FCS_COP.1/AES, FCS_COP.1/AES_SCL_1,
23
FCS_COP.1/AES_SCL_2, FCS_COP.1/AES_SCL_3,FCS_COP.1/AES_PSL.
24
This TSF is implemented in 3 ways:
25
1. By directly programming the hardware registers of the symmetric coprocessor.
26
2. By using the interface of the optional SCL. This library contains additional countermeasures.
27
3. By using the interface of the optional PSL. This library uses the SCL library to access the
28
symmetric coprocessor.
29
8.5.4 AES MAC
30
The TSF supports MAC calculation with the cryptographic algorithm Advanced Encryption
31
Standard (AES) in CBC MAC mode and CMAC mode and cryptographic key sizes of 128 bit or 192
32
bit or 256 bit according to the standards: [N197],[N38B], [9797] with the following
33
options/modifications:
34
 MAC algorithm 1
35
 Padding must be done by the caller
36
 An Initialization Vector (IV) must be given by the caller
37
 The covered security functional requirements are FCS_COP.1/AES_MAC_PSL_1,
38
FCS_COP.1/AES_MAC_PSL_2
39
40
74
Security Target Lite
M9900, M9905, M9906
public
8.5.5 RSA
1
8.5.5.1 Encryption, Decryption, Signature Generation and Verification
2
The TSF shall perform encryption and decryption in accordance with a specified cryptographic
3
algorithmRivest-Shamir-Adleman (RSA) and cryptographic key sizes 1024 - 4096 bits that
4
meet the following standards:
5
Encryption:
6
According to section 5.1.1 RSAEP in PKCS v2.2, without 5.1.1(1).
7
Decryption (with or without CRT):
8
According to section 5.1.2 RSADP in PKCS v2.2
9
for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.1.2(2.b) (ii)&(v), without 5.1.2(1),
10
5.1.2(2.a) only supported up to n < 22048.
11
Signature Generation (with or without CRT):
12
According to section 5.2.1 RSASP1 in PKCS v2.2
13
for u = 2, i.e., without any (r_i, d_i, t_i), i >2,
14
therefore without 5.2.1(2.b) (ii)&(v), without 5.2.1(1),
15
5.2.1(2.a) only supported up to n < 22048.
16
Signature Verification:
17
According to section 5.2.2 RSAVP1 in PKCS v2.2,
18
without 5.2.2(1).
19
The covered security functional requirement is FCS_COP.1/RSA, FCS_COP.1/RSA_PSL.
20
8.5.6 Elliptic Curves
21
The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
22
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Note that there exists
23
numerous other curve types, being also secure in terms of side channel attacks on this TOE,
24
which can the user optionally add in the composition certification process.
25
26
8.5.6.1 Signature Generation and Verification
27
The TSF shall perform signature generation and signature verification in accordance with a
28
specified cryptographic algorithm ECDSA and cryptographic key sizes 160, 163, 192, 224, 233, 256,
29
283, 320, 384, 409, 512 or 521 bits that meet the following standard:
30
31
Signature Generation:
32
3. According to section 7.3 in ANSI X9.62 – 2005:
33
Not implemented is step d) and e) thereof.
34
The output of step e) has to be provided as input to our function by the caller.
35
Deviation of step c) and f):
36
The jumps to step a) were substituted by a return of the function with an error code, the jumps
37
are emulated by another call to our function.
38
39
Signature Verification:
40
4. According to section 7.4.1 in ANSI X9.62–2005:
41
Not implemented is step b) and c) thereof.
42
75
Security Target Lite
M9900, M9905, M9906
public
The output of step c) has to be provided as input to our function by the caller.
1
Deviation of step d):
2
Beside noted calculation, our algorithm adds a random multiple of the group order n to the
3
calculated values u1 and u2.
4
5
The covered security functional requirement is FCS_COP.1/ECDSA.
6
8.5.6.2 Asymmetric Key Generation
7
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
8
generation algorithm Elliptic Curve EC specified in ANSI X9.62-1998 and specified cryptographic
9
key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following
10
standard:
11
12
ECDSA Key Generation:
13
5. According to the appendix A4.3 in ANSI X9.62-2005 the cofactor h is not supported.
14
15
The covered security functional requirement is FCS_CKM.1/EC.
16
8.5.6.3 Asymmetric Key Agreement
17
The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance with a specified
18
cryptographic algorithm ECDH and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320,
19
384, 409, 512 or 521 bits that meet the following standard:
20
6. According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our implementation not
21
only returns the x-coordinate of the shared secret, but rather the x-coordinate and y-
22
coordinate.
23
7.
24
The covered security functional requirement is FCS_COP.1/ECDH, FCS_COP.1/ECDH_PSL.
25
8.5.7 Asymmetric Base Library
26
The asymmetric Base library provides the low level interface to the asymmetric cryptographic
27
coprocessor and has no user available interface. The asymmetric Base library does not provide
28
any security functionality, implements no security mechanism, and does not provide additional
29
specific security functionality. The asymmetric Base library does not cover security functional
30
requirements.
31
8.5.8 Symmetric Crypto Library (SCL)
32
The symmetric crypto Library provides an interface to the SCP for AES and 3DES operations.
33
The SCL contains additional software countermeasures to harden the restance against side
34
channel and fault attacks. The SCL consists of three files “AES.lib”, “DES.lib” and “cipher.lib”.
35
Those library files will only distributes together.
36
The covered security functional requirements are FCS_COP.1/DES_SCL_1, FCS_COP.1/DES_SCL_2,
37
FCS_COP.1/DES_SCL_3, FCS_COP.1/AES_SCL_1, FCS_COP.1/AES_SCL_2, FCS_COP.1/AES_SCL_3.
38
8.5.1 Hash Crypto Library (HCL)
39
The hash crypto Library provides an interface to SHA-1 and SHA-2 hash operations. The HCL
40
contains additional software countermeasures to harden the restance against single side
41
76
Security Target Lite
M9900, M9905, M9906
public
channel template attacks. The HCL consists of the files “HCL97-CPU-L90-hash.lib” and “HCL97-
1
CPU-L90-sha.lib”
2
The covered security functional requirements are FCS_COP.1/SHA.
3
4
8.5.2 Platform Support Layer (PSL)
5
The Platform Support Layer (PSL) library is used to provide a standardized interface to the
6
hardware, directly or via the RSA, ECC and SCL lib
7
rary. The provided interfaces are syntactically similar to Windows NT device driver calls. The PSL
8
provides as additional cryptographic operations a MAC calculation with AES and 3DES keys.
9
The covered security functional requirements are FCS_COP.1/DES_PSL, FCS_COP.1/DES_MAC_PSL,
10
FCS_COP.1/AES_PSL, FCS_COP.1/AES_MAC_PSL_1, FCS_COP.1/AES_MAC_PSL_2,
11
FCS_COP.1/RSA_PSL, FCS_COP.1/ECDH_PSL, FCS_COP.1/SHA_PSL, FCS_RNG.1/PSL.
12
13
8.5.3 TRNG
14
Random data is essential for cryptography as well as for security mechanisms. The TOE is equipped
15
with a physical True Random Number Generator (TRNG, FCS_RNG.1/HW and FCS_RNG.1/PSL). The
16
random data can be used from the Smartcard Embedded Software and is also used from the
17
security features of the TOE, like masking. The TRNG implements also self testing features. The
18
TRNG fulfils the requirements from the functionality class PTG.2 of [6].
19
The covered security functional requirement is FCS_RNG.1/HW and FCS_RNG.1/PSL “Quality metric
20
for random numbers”, FPT_PHP.3 “Resistance to physical attack”, FDP_ITT.1 “Basic internal transfer
21
protection”, FPT_ITT.1 “Basic internal TSF data transfer protection, FDP_IFC.1 “Subset information
22
flow control“, FPT_TST.2 “Subset TOE security testing“ and FPT_FLS.1“Failure with preservation of
23
secure state”.
24
25
The SF_CS “Cryptographic Support” covers the security functional requirements FCS_COP.1/DES,
26
FCS_COP.1/DES_SCL_1, FCS_COP.1/DES_SCL_2, FCS_COP.1/DES_SCL_3, FCS_COP.1/DES_PSL,
27
FCS_COP.1/DES_MAC_PSL, FCS_COP.1/AES, FCS_COP.1/AES_SCL_1, FCS_COP.1/AES_SCL_2,
28
FCS_COP.1/AES_SCL_3, FCS_COP.1/AES_PSL, FCS_COP.1/AES_MAC_PSL_1,
29
FCS_COP.1/AES_MAC_PSL_2,FCS_COP.1/RSA, FCS_COP.1/RSA_PSL, FCS_COP.1/ECDSA,
30
FCS_COP.1/ECDH, FCS_COP.1/ECDH_PSL, FCS_CKM.1/EC, FPT_PHP.3, FDP_ITT.1, FPT_ITT.1,
31
FPT_FLS.1 ,FCS_RNG.1/HW and FCS_RNG.1/PSL, 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 20. 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
Table 20 Mapping of SFR and SF
44
SFR SF_DPM SF_PS SF_PMA SF_PLA SF_CS
FAU_SAS.1 X
FMT_LIM.1 X
77
Security Target Lite
M9900, M9905, M9906
public
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/HW X
FCS_RNG.1/PSL X
FCS_COP.1/DES X
FCS_COP.1/DES_SCL_1 X
FCS_COP.1/DES_SCL_2 X
FCS_COP.1/DES_SCL_3 X
FCS_COP.1/DES_PSL X
FCS_COP.1/DES_MAC_PSL X
FCS_COP.1/AES X
FCS_COP.1/AES_SCL_1 X
FCS_COP.1/AES_SCL_2 X
FCS_COP.1/AES_SCL_3 X
FCS_COP.1/AES_PSL X
FCS_COP.1/AES_MAC_PSL_1 X
FCS_COP.1/AES_MAC_PSL_2 X
FCS_COP.1/RSA X
FCS_COP.1/RSA_PSL X
FCS_COP.1/ ECDSA X
FCS_COP.1/ECDH X
FCS_COP.1/ECDH_PSL X
FCS_COP.1/SHA X
FCS_COP.1/SHA_PSL X
FCS_CKM.1/EC X
1
2
8.7 Security Requirements are internally Consistent
3
For this chapter the PP [1] section 6.3.4 can be applied completely.
4
78
Security Target Lite
M9900, M9905, M9906
public
In addition to the discussion in section 6.3 of PP [1] the security functional requirement FCS_COP.1
1
is introduced. The security functional requirements required to meet the security objectives
2
O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also
3
protect the cryptographic algorithms implemented according to the security functional
4
requirement FCS_COP.1. Therefore, these security functional requirements support the secure
5
implementation and operation of FCS_COP.1.
6
As disturbing, manipulating during or forcing the results of the test checking the security functions
7
after TOE delivery, this security functional requirement FPT_TST.2 has to be protected. An attacker
8
could aim to switch off or disturb certain sensors or filters and preserve the detection of his
9
manipulation by blocking the correct operation of FPT_TST.2. The security functional requirements
10
required to meet the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
11
Manipulation and O.Leak-Forced also protect the security functional requirement FPT_TST.2.
12
Therefore, the related security functional requirements support the secure implementation and
13
operation of FPT_TST.2.
14
The requirement FPT_TST.2 allows testing of some security mechanisms by the Smartcard
15
Embedded Software after delivery. In addition, the TOE provides an automated continuous user
16
transparent testing of certain functions.
17
The implemented level concept represents the area based memory access protection enforced by
18
the MPU. As an attacker could attempt to manipulate the privilege level definition as defined and
19
present in the TOE, the functional requirement FDP_ACC.1 and the related other requirements have
20
to be protected themselves. The security functional requirements required to meet the security
21
objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-
22
Forced also protect the area based memory access control function implemented according to the
23
security functional requirement described in the security functional requirement FDP_ACC.1 with
24
reference to the Memory Access Control Policy and details given in FDP_ACF.1. Therefore, those
25
security functional requirements support the secure implementation and operation of FDP_ACF.1
26
with its dependent security functional requirements.
27
The requirement FDP_SDI.2.1 allows detection of integrity errors of data stored in memory.
28
FDP_SDI.2.2 in addition allows correction of one bit errors or taking further action. Both meet the
29
security objective O.Malfunction. The requirements FRU_FLT.2, FPT_FLS.1, and FDP_ACC.1 which
30
also meet this objective are independent from FDP_SDI.2 since they deal with the observation of the
31
correct operation of the TOE and not with the memory content directly.
32
79
Security Target Lite
M9900, M9905, M9906
public
9 References
1
[1] Security IC Platform Protection Profile, Version 1.0, 15.06.2007, BSI-PP-0035
[2] Common Criteria for Information Technology Security Evaluation Part 1: Introduction
and
General Model; Version 3.1 Revision 5, April 2017, CCMB-2017-04-001
[3] Common Criteria for Information Technology Security Evaluation Part 2: Security
Functional Requirements; Version 3.1 Revision 5, April 2017, CCMB-2017-04-002
[4] Common Criteria for Information Technology Security Evaluation Part 3: Security
Assurance Requirements; Version 3.1 Revision 5, September 2017, CCMB-2017-04--
003
[5] ARMv7-M Architecture Reference Manual, ARM DDI 0403D ID021310, 12. February
2010, ARM Limited
[6] A proposal for: Functionality classes for random number generators, Version 2.0, 18.
September 2011
[7] SLE97 M9900 Hardware Reference Manual, Revision 3.0, 2019-08-28
[10] Joint Interpretation Library, Application of Attack Potential to Smartcards, Version 2.9,
January 2013
[11] SLx97 Platform Support Layer Library 32-bit Security Controller Programmer’s
Reference Manual, revision 5.4, 2018-07-06
[12] M9900 Errata Sheet, Rev.4.1, 2019-09-24 and M9905 M9906 Errata Sheet, Rev.3.1,
2019-06-05
[15] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS31, Version 3,
2013-05-15, Bundesamt für Sicherheit in der Informationstechnik
[SHS] NIST: FIPS publication 180-4: Secure Hash Standard (SHS), August 2015
[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
[BSIG] Act on the Federal Office for Information Security (BSI-Gesetz - BSIG) of 14 August
2009, Bundesgesetzblatt I p. 2821
[9797] ISO/IEC 9797-1: 2011
[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
[N38B]
[PKCS]
National Institute of Standards and Technology (NIST), Technology Administration,
U.S. Department of Data Encryption Standard, NIST Special Publication 800-38B,
Edition 2005
PKCS #1: RSA Cryptography Standard, v2.2, October 27, 2012, RSA Laboratories
80
Security Target Lite
M9900, M9905, M9906
public
[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
[ST] Confidential Security Target M9900, M9905, M9906 including optional Software
Libraries RSA-EC-SCL-HCL-PSL, v4.9, 2024-09-20, Infineon Technologies AG
81
Security Target Lite
M9900, M9905, M9906
public
10 Appendix
1
In the following tables, the hash signatures of the respective CL97 Crypto Library files are
2
documented. For convenience purpose several hash values are referenced.
3
4
Table 21 Reference hash values of
5
the FTL V1.01.0008
6
library
7
MD5 5abc1dca 0d92375d 3101a3cd de11faf8
SHA1 0201487a eb93b1a9 b766c02d 43a17c97 fe4c1106
SHA256 0438971c 5845d797 8d176578 b601812d e8d8e663
a09e3dc2 662b0999 7f473ea2
8
9
Table 22 Reference hash values of
10
the CL97 v 2.05.005
11
Crypto libraries
12
Library Hash Value
Cl97-LIB-base.lib:
MD5 8a4a99be8204e99db9f3b409fae756f1
SHA1 dc8911a4ea23924d8dcc05429793e9d0c23504ba
SHA256 1e1e8e4b8d2ca53985e5257626db8b5c7f439b2cc88c35ee
de3a34f521de8530
Cl97-LIB-ecc.lib
MD5 e27681989fd2891e856baa03f7ac7d4a
SHA1 4a36bb058cb193db593b194ad8d6f29491afb996
SHA256 4172c0445e511e90b55f273985d90b4399ff9effb1608f18c
65812f1efbd7453
Cl97-LIB-2k.lib
MD5 17b01b76d3353b3a6710c2ee19f1e8b0
SHA1 0011e3f4678ebecf614796d7ba697eb55ac0870d
SHA256 9dc4c346602ce6a9586ef62d4f1108b60a81e01c0e8753bf
6d4026a5ba6f59d4
Cl97-LIB-4k.lib
MD5 d8c77f9f5a47dd587f219f73c66c82de
SHA1 f2f4169cc2331732d234848cf771c7e73341e4ae
SHA256 ac9866759a32cfca44377a88384a32bd27345cbacf2de30c
4af31aefd4872928
Cl97-LIB-toolbox.lib
MD5 e85484a56c08343a3bfb8bc57a9f3691
SHA1 51e8329a4013f130c4ef31ca6dcd2fb311d7fc6c
SHA256 e383c7934627c6e4638b6e5b6b224913d6fc4e216431bc1
b51301a02b9b6bf25
13
82
Security Target Lite
M9900, M9905, M9906
public
Table 23 Reference hash values of
1
the CL97 v2.07.003
2
Crypto libraries
3
Library Hash Value
Cl97-LIB-base.lib:
MD5 0581debbbc6bf992c1b979bcedb731c5
SHA1 d1afcc8ec1c898774f238568c7d8e159e4dd5f68
SHA256 02009f6c7b84b6e3d148dfa761143052720361c14babccc2
65aa8ce5a22a947a
Cl97-LIB-ecc.lib
MD5 6542752d79576891580c2daa395ef66b
SHA1 097047756b24bf138b384357d6751ea8e33d8dff
SHA256 8f72c8ebdad3c99c59e9d115b284e6245122bb9ab38bd93
da247c282c1526383
Cl97-LIB-2k.lib
MD5 7ab7f68c7eb0e8a0c6ea97c3185d882c
SHA1 0e33b00961cba3d0be34352a6e7d9ddb6e12961e
SHA256 701ecd9bcd4cd828982e7a9db35820c2e4482b98263492b
9072230a352d4d2e8
Cl97-LIB-4k.lib
MD5 f5a36e6b9ff47d877c0e74e823e03d56
SHA1 bbb4fed8e9c37c180417602ac8395130b6c0fea5
SHA256 a8b6654f1302a9766ded5102b0ac6f93795bba1163885c4
4d0209df137b1fb7e
Cl97-LIB-toolbox.lib
MD5 016053d0479897706ccd0638c39fd8f2
SHA1 ef499d2d497a5797e4ebf376b011d3ce41391d3b
SHA256 5efc01016edbfc3e5de35e7c58700a63f1c1bcbea35be277e
7743659587aa22c
4
Table 24 Reference hash values of
5
the SCL97 v2.01.011
6
crypto libraries
7
Scl97-SCP-v3-LIB-
cipher.lib:
MD5 a4c45e84dd9e2f651edf1ffaa077190d
SHA1 4cbda743be21b29de6e826112120ea11a10c2641
SHA256 998ea5e14a36ef20fc6c7c5d6c511adaac8dfa0a411bd2b96
e1cbd9eee3596eb
Scl97-SCP-v3-LIB-des.lib:
MD5 041abd8e8233e1b407d777b2734fbbd6
SHA1 ebfe549e8ac2092f1b03438f2ecb4995839b0c9a
SHA256 784ed8ca5b60ee0ac91df10b6871429a3db77e1166b2142
116f4f0b61258d83d
83
Security Target Lite
M9900, M9905, M9906
public
Scl97-SCP-v3-LIB-aes.lib:
MD5 fd061c43a23c3a256ee2aa89dbfc3d27
SHA1 c3516afe6cf16f635704ebbc751ec2763b8115bd
SHA256 57e6a9100d635d6df05241edb2874e3cbc2006927361ba4
976044f7d996e48ae
Table 25 Reference hash values of
1
the SCL97 v2.02.010
2
crypto libraries
3
Scl97-SCP-v3-LIB-cipher.lib:
MD5 4d8cb3b84d95c386fb87ef6028d56404
SHA1 70f41981bd933db8f603b493c5fb035162e7758e
SHA256 848f57e48083a8b76c1e45de4dc006e3ed9b8bcf08a683d
4d9466b56b924c6d2
Scl97-SCP-v3-LIB-des.lib:
MD5 25b52ec314713ac21e9b3300011f0c6f
SHA1 6ff3713a41413b0fc1badef971c4ff55a6fd5d5b
SHA256 a633636604ab515251370fdfe28007ad2cb3baa190340c
4a3eb88e2fcbf815b7
Scl97-SCP-v3-LIB-aes.lib:
MD5 c8ca2dc013450d67d17d74deaeda79f0
SHA1 6bf7b1e082235ca5c0239ad070214a0337b89a13
SHA256 702653de911da2e3f5baa4ff7ff541a8ee43452dd243937
3d55c876027125598
Table 26 Reference hash values of
4
the SCL97 v2.04.003
5
crypto libraries
6
Scl97-SCP-v3-L90-cipher.lib:
MD5 874995a6f7415d8da60e2afdfb4df5f0
SHA1 5c2b7aaa2b37c4275cdbc118a6abff4b55e02854
SHA256 ee78b3e7317947e1222707f7f1b012cbe6ad2efcaf455efa
40937a64506899ae
Scl97-SCP-v3-L90-mac.lib:
MD5 33d8a4c2a2396eaed10653c92bdfcdc6
SHA1 4597f5b6263a63fc57313e44d3a33f3485c3d14f
SHA256 ce94d6475e327aab96785c206ce08237ce334e174795bd
07e0973d47f0ac8aaa
Scl97-SCP-v3-L90-des.lib:
MD5 9d15777997d613d4ace3c6eae0314b05
SHA1 33e9f042611c9f6056f73d3dd7297b62c09ff705
SHA256 1ee72d08d96ec201fd44f7a5660595f0056961e6c7ddbd5
985f193e01c00284e
Scl97-SCP-v3-L90-aes.lib:
MD5 e5d105c9cacf024c7b7983ea9ae3cc75
84
Security Target Lite
M9900, M9905, M9906
public
SHA1 71608b626dc10d3f0931b3907dbd1bf5eb942d6a
SHA256 92c378ab9bee9f59c399475725015910535c0ff51e63806
7801e93cad7d4717f
Table 27 Reference hash values of
1
the NRG libraries
2
Library/object file Hash Value
NRGManagement-
01.03.0927-M9900.lib
MD5 874e529dabef8419e672c44a94600963
SHA1 9a2cfae606dc562b0d3b2dc6abcad1e11c7829f5
SHA256 95f2ed5f6a3001146c9fef36c539ac2844839af0bacb92e4
4a2da474e6d5aa8e
NRGReader-01.02.0800-
M9900.lib
MD5 5be6e2e9eb0f2a4847f7fc4bacf8126a
SHA1 f0cbc090657fa09d5f23e1f468e95c245f63f6fb
SHA256 16848631a68b3094e29790ee34bbb95af208a9985c8e11
1f46849fffc4ef3385
3
Table 28 PSL library v4.00.09
4
Psl90.lib
MD5 7afa798cca7307789cb0611816f85998
SHA1 52f8e9acc0677c20e4b9826e0ee969e09cf9ef66
SHA256 81a2e6e9b8e8793ab6b1e11c9f11afc3a5debea65a6b1
cd777da7f0fb25d31c8
5
Table 29 PSL library v4.00.10
6
Psl90.lib
MD5 4263eb7321e170d89199593bf915faa5
SHA1 2f46f032e919991d93ea1fae9f9db3f096044d6a
SHA256 9451d17d6876d38b19613241220fdc0574b7d88319d2f
32181b819d34ea3eef7
7
Table 30 PSL library v5.00.06
8
Psl90.lib
MD5 b41ba56c9239124f10a241ed1ac775f3
SHA1 2c3cfc01e66ad307deb43d835db5a4d85a03286f
SHA256 ac256bd880d528b33ffe0594265378d3142b912357ea61
6b5e68a06eecd83572
9
85
Security Target Lite
M9900, M9905, M9906
public
Table 31 HCL library v1.01.003
1
HCL97-CPU-L90-hash.lib
MD5 3d83d1294aa70fdf9b4b3883d617990a
SHA1 44db57a695407da941b351fd909d460fbfa10825
SHA256 3d8712eaf73fe89c83b978c8ba583329df2762086c7b876
7515d3c3ef4560ede
HCL97-CPU-L90-sha.lib
MD5 b76d81c778e8ecb7efd5d20ac8d8f011
SHA1 0bcf346dc501c685616bf4f18ed90ea0640d1699
SHA256 50a0117ae0392a3928735fb9d777dcd5dd551b2c296317
185b50bf2e6c184b79
2
86
Security Target Lite
M9900, M9905, M9906
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
PSL Platform Support Layer
33
RAM Random Access Memory
34
RMS Resource Management System
35
RNG Random Number Generator
36
ROM Read Only Memory
37
RSA Rives-Shamir-Adleman Algorithm
38
SCL Symmetric Crypto Library
39
87
Security Target Lite
M9900, M9905, M9906
public
SCP Symmetric Cryptographic Processor
1
SF Security Feature
2
SFR Special Function Register, as well as Security Functional Requirement
3
SPA Simple power analysis
4
SW Software
5
T Threat
6
TM Test Mode (BOS)
7
TOE Target of Evaluation
8
TRNG True Random Number Generator
9
TSF TOE Security Functionality
10
UART Universal Asynchronous Receiver/Transmitter
11
UM User Mode (BOS)
12
UMSLC User Mode Security Life Control
13
3DES Triple DES Encryption Standard
14
88
Security Target Lite
M9900, M9905, M9906
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 (RSA, Elliptic Curves)
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
89
Security Target Lite
M9900, M9905, M9906
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 of change
4.6 Final version
30
Trademarks of Infineon Technologies AG
AURIX™, C166™, CanPAK™, CIPOS™, CoolGaN™, CoolMOS™, CoolSET™, CoolSiC™, CORECONTROL™, CROSSAVE™, DAVE™, DI-POL™, DrBlade™,
EasyPIM™, EconoBRIDGE™, EconoDUAL™, EconoPACK™, EconoPIM™, EiceDRIVER™, eupec™, FCOS™, HITFET™, HybridPACK™, Infineon™, ISOFACE™,
IsoPACK™,
i-Wafer™, MIPAQ™, ModSTACK™, my-d™, NovalithIC™, OmniTune™, OPTIGA™, OptiMOS™, ORIGA™, POWERCODE™, PRIMARION™, PrimePACK™,
PrimeSTACK™, PROFET™, PRO-SIL™, RASIC™, REAL3™, ReverSave™, SatRIC™, SIEGET™, SIPMOS™, SmartLEWIS™, SOLID FLASH™, SPOC™, TEMPFET™,
thinQ!™, TRENCHSTOP™, TriCore™.
Trademarks updated August 2015
Other Trademarks
All referenced product or service names and trademarks are the property of their respective owners.
ifx1owners.
Edition 2024-09-20
Doc_Number
Published by
Infineon Technologies AG
81726 Munich, Germany
© 2024 Infineon Technologies AG.
All Rights Reserved.
Do you have a question about this
document?
Email: erratum@infineon.com
Document reference
IMPORTANT NOTICE
The information contained in this application note
is given as a hint for the implementation of the
product only and shall in no event be regarded as a
description or warranty of a certain functionality,
condition or quality of the product. Before
implementation of the product, the recipient of this
application note must verify any function and other
technical information given herein in the real
application. 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) with respect to any and all
information given in this application note.
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.
Trademarks of Infineon Technologies AG
µHVIC™, µIPM™, µPFC™, AU-ConvertIR™, AURIX™, C166™, CanPAK™, CIPOS™, CIPURSE™, CoolDP™, CoolGaN™, COOLiR™, CoolMOS™, CoolSET™,
CoolSiC™, DAVE™, DI-POL™, DirectFET™, DrBlade™, EasyPIM™, EconoBRIDGE™, EconoDUAL™, EconoPACK™, EconoPIM™, EiceDRIVER™, eupec™,
FCOS™, GaNpowIR™, HEXFET™, HITFET™, HybridPACK™, iMOTION™, IRAM™, ISOFACE™, IsoPACK™, LEDrivIR™, LITIX™, MIPAQ™, ModSTACK™, my-
d™, NovalithIC™, OPTIGA™, OptiMOS™, ORIGA™, PowIRaudio™, PowIRStage™, PrimePACK™, PrimeSTACK™, PROFET™, PRO-SIL™, RASIC™, REAL3™,
SmartLEWIS™, SOLID FLASH™, SPOC™, StrongIRFET™, SupIRBuck™, TEMPFET™, TRENCHSTOP™, TriCore™, UHVIC™, XHP™, XMC™
Trademarks updated November 2015
Other Trademarks
All referenced product or service names and trademarks are the property of their respective owners.
ifx1owners.
Edition 2024-09-20
ifx1
Published by
Infineon Technologies AG
81726 Munich, Germany
© 2024 Infineon Technologies AG.
All Rights Reserved.
Do you have a question about this
document?
Email: erratum@infineon.com
Document reference
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.