Application Note Please read the Important Notice and Warnings at the end of this document Revision 2.7.7
www.infineon.com 2017-07-11
Public
Security Target Lite
M5072
including optional Software Libraries
RSA-EC-SCL
According to Common Criteria CCv3.1 EAL5
augmented (EAL5+)
Version: 2.7.7
Date: 2017-07-11
Author: Jürgen Noller, Rainer Urian
2
Security Target Lite
M5072
Public
1 Security Target Introduction (ASE_INT) .............................................................................4
1.1 Security Target and Target of Evaluation Reference ..............................................................4
1.2 Target of Evaluation overview ................................................................................................8
2 Target of Evaluation Description ......................................................................................11
2.1 Definition of the TOE............................................................................................................11
2.1.1 Hardware of the TOE.......................................................................................................12
2.1.2 Firmware of the TOE .......................................................................................................15
2.1.3 Optional software of the TOE...........................................................................................15
2.1.4 Interfaces of the TOE.......................................................................................................16
2.1.5 Guidance documentation.................................................................................................17
2.1.6 Forms of delivery .............................................................................................................17
2.1.7 Production sites...............................................................................................................18
2.1.8 TOE Configuration...........................................................................................................18
2.1.9 TOE initialization with Customer Software .......................................................................19
3 Conformance Claims (ASE_CCL)......................................................................................21
3.1 CC Conformance Claim .......................................................................................................21
3.2 PP Claim..............................................................................................................................21
3.3 Package Claim.....................................................................................................................21
3.4 Conformance Rationale........................................................................................................22
3.5 Application Notes .................................................................................................................23
4 Security Problem Definition (ASE_SPD)...........................................................................24
4.1 Threats.................................................................................................................................24
4.1.1 Additional Threat due to TOE specific Functionality.........................................................24
4.1.2 Assets regarding the Threats...........................................................................................25
4.2 Organizational Security Policies ...........................................................................................25
4.2.1 Augmented Organizational Security Policy ......................................................................26
4.3 Assumptions.........................................................................................................................26
4.3.1 Augmented Assumptions.................................................................................................28
5 Security objectives (ASE_OBJ).........................................................................................29
5.1 Security objectives for the TOE ............................................................................................29
5.2 Security Objectives for the development and operational Environment ................................30
5.2.1 Clarification of “Usage of Hardware Platform (OE.Plat-Appl)” ..........................................30
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”................................................30
5.2.3 Clarification of “Protection during Composite product manufacturing (OE.Process-Sec-IC)”31
5.3 Security Objectives Rationale...............................................................................................31
6 Extended Component Definition (ASE_ECD) ...................................................................33
6.1 “Subset TOE security testing (FPT_TST)” ............................................................................33
6.2 Definition of FPT_TST.2.......................................................................................................33
6.3 TSF self test (FPT_TST) ......................................................................................................34
6.4 Family “Generation of Random Numbers (FCS_RNG)”........................................................34
6.5 Definition of FCS_RNG.1 .....................................................................................................34
7 Security Requirements (ASE_REQ) ..................................................................................36
7.1 TOE Security Functional Requirements................................................................................36
7.1.1 Extended Components FCS_RNG.1 and FAU_SAS.1.....................................................37
7.1.1.1 FCS_RNG...................................................................................................................37
7.1.1.2 FAU_SAS....................................................................................................................38
7.1.2 Subset of TOE testing......................................................................................................38
7.2 Memory access control ........................................................................................................39
7.2.1 Memory Access Control Policy ........................................................................................39
7.3 Support of Cipher Schemes .................................................................................................43
3
Security Target Lite
M5072
Public
7.3.1 Triple-DES Operation ......................................................................................................45
7.3.2 AES Operation.................................................................................................................46
7.3.3 Rivest-Shamir-Adleman (RSA) operation.........................................................................47
7.3.4 Rivest-Shamir-Adleman (RSA) key generation ................................................................48
7.3.5 Elliptic Curve DSA (ECDSA) operation ............................................................................48
7.3.6 Elliptic Curve (EC) key generation ...................................................................................49
7.3.7 Elliptic Curve Diffie-Hellman (ECDH) key agreement.......................................................50
7.3.8 Data Integrity ...................................................................................................................51
7.4 TOE Security Assurance Requirements ...............................................................................52
7.4.1 Refinements ....................................................................................................................53
7.5 Security Requirements Rationale .........................................................................................53
7.5.1 Rationale for the Security Functional Requirements ........................................................53
7.5.1.1 Dependencies of Security Functional Requirements ...................................................56
7.5.2 Rationale of the Assurance Requirements.......................................................................59
8 TOE Summary Specification (ASE_TSS) ..........................................................................61
8.1 SF_DPM: Device Phase Management .................................................................................61
8.2 SF_PS: Protection against Snooping ...................................................................................62
8.3 SF_PMA: Protection against Modifying Attacks....................................................................63
8.4 SF_PLA: Protection against Logical Attacks.........................................................................64
8.5 SF_CS: Cryptographic Support ............................................................................................64
8.5.1 3DES encryption..............................................................................................................64
8.5.2 AES encryption................................................................................................................65
8.5.3 RSA.................................................................................................................................65
8.5.3.1 Encryption, Decryption, Signature Generation and Verification ...................................65
8.5.3.2 Asymmetric Key Generation........................................................................................66
8.5.4 Elliptic Curves..................................................................................................................66
8.5.4.1 Signature Generation and Verification.........................................................................66
8.5.4.2 Asymmetric Key Generation........................................................................................67
8.5.4.3 Asymmetric Key Agreement........................................................................................68
8.5.5 Toolbox Library................................................................................................................68
8.5.6 Asymmetric Base Library.................................................................................................68
8.5.7 Symmetric Crypto Library (SCL) ......................................................................................68
8.5.8 TRNG ..............................................................................................................................68
8.6 Assignment of Security Functional Requirements to TOE’s Security Functionality ...............69
8.7 Security Requirements are internally Consistent ..................................................................70
9 References..........................................................................................................................71
10 List of Abbreviations..........................................................................................................73
11 Glossary..............................................................................................................................75
Revision History...................................................................................................................................76
4
Security Target Lite
M5072
Public
1 Security Target Introduction (ASE_INT)
1
1.1 Security Target and Target of Evaluation Reference
2
The title of this document is “Security Target Lite”.
3
This Security Target comprises the Infineon Technologies Smart Card IC (Security Controller) M5072
4
with optional RSA v1.03.006/v2.06.003, EC v1.03.006/ v2.06.003, Toolbox v1.03.006/ v2.06.003, SCL
5
v2.02.010 libraries with specific IC dedicated software.
6
The Target of Evaluation (TOE) is an Infineon smart card IC (Security Controller) M5072 including
7
optional software libraries RSA–EC-SCL. The design step is G11.
8
The Security Target is based on the Protection Profile “Smartcard IC Platform Protection Profile” [1].
9
The Protection Profile and the Security Target are built in compliance with Common Criteria v3.1.
10
The ST takes into account all relevant current final interpretations.
11
5
Security Target Lite
M5072
Public
1
Table 1 Identification
2
Type Version Date Registration
Security
Target
2.7.7 2017-07-11 M5072
Target of
Evaluation
G11 M5072
with Firmware Identifier
80001141 or 80001144 or 80001145
and Management of Mifare-compatible Cards
01.03.0927 (optional)
and Management of Mifare-compatible Cards
01.04.1275 (optional)
and Mifare-compatible Reader Mode Support
01.02.0800 (optional)
and RSA2048 V1.03.006 (optional)
and RSA2048 V2.06.003 (optional)
and RSA4096 V1.03.006 (optional)
and RSA4096 V2.06.003 (optional)
and EC V1.03.006 (optional)
and EC V2.06.003 (optional)
and Toolbox V1.03.006 (optional)
and Toolbox V2.06.003 (optional)
and SCL (optional) v2.02.010
and Guidance documentation
Guidance
Documen-
tation
Revision 1.2
ID021310
Rev. 3.2
Edition Aug.
10, 2014
Edition
2017-06-30
Rev.3.0
V1.03.006
with errata
sheet
V2.06.003
with errata
sheet
v2.02.010
2014-04-09
2010-02-12
2015-07-03
2014-08-10
2017-06-30
2016-11-28
2017-05-10
2017-05-10
2016-12-09
SLE97 M5072 Hardware Reference Manual
ARMv7-M Architecture Reference Manual,
ARM DDI 0403D ID021310, ARM Limited
SLE97 Programmer´s Reference Manual
SLE97 / SLC14 Family Production and
Personalization
User´s Manual
M5072 Security Guidelines User´s Manual
M5072 Errata Sheet
SLE97 Asymmetric Crypto Library for
Crypto@2304T
RSA/ECC/Toolbox
User Interface (optional)
CL97 Asymmetric Crypto Library for
Crypto@2304T
6
Security Target Lite
M5072
Public
RSA / ECC / Toolbox User Interface (optional)
SCL97 Symmetric Crypto Library for SCPv3
DES/AES 32-bit Security Controller User Interface
(optional)
Protection
Profile
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.
Common
Criteria
3.1
Revision 4
2012-09 Common Criteria for Information Technology
Security Evaluation
Part 1: Introduction and general model CCMB-
2012-09-001
Part 2: Security functional requirements CCMB-
2012-09-002
Part 3: Security Assurance Components CCMB-
2012-09-003
1
This TOE is represented by a number of various products. They all differentiate by various configuration
2
possibilities, done either by Infineon settings during production or, after delivery, by means of blocking at
3
customer premises. Despite these variation possibilities, all products are derived from the equal
4
hardware design results, the M5072 G11.
5
6
The TOE can be identified with the Generic Chip Identification Mode (GCIM). The M-number hardware is
7
identified by the bytes 05 and 06, which are the first two bytes of the chip identification number, having
8
for M5072 always the hexadecimal value of 0x0015, the design step, firmware identifier, mask identifier,
9
temperature range and system frequency are also included in the GCIM. Additionally the customer can
10
read the configuration area as defined in the SLE97 Programmer´s Reference Manual [11].
11
12
Remark 1:
13
The derivatives of the TOE produced in the factory TSMC coming with the additional top layer on board
14
(WLB) are managed with the same design step. These derivatives output a G11 in the GCIM for WLB
15
derivate. All other identification options, i.e. the various metal option identifiers of the GCIM remain
16
unchanged.
17
All products are identical from module design and layout, but may include further package options
18
require flexibility in design and could also depend on user requirements. In these cases one or more
19
additional metal layer may be added on top of one of the TOE mask set. These additional metal layers,
20
it could also be more than one, just reroute the pads. Therefore, this last rerouting on top does not
21
change the function of the TOE itself and is depending on the package only. These top metal layers are
22
flexible in design, could depend also on user requirements and are of course not relevant for the security
23
of the TOE. For these reasons, the metal layers are out the scope of the certification and do not belong
24
to the TOE. Of course, in all cases passivation and isolation coating is applied on top of the last layers
25
carrying wires. Further clear declaration and overview is given in chapter 2.1 Definition of the TOE.
26
Despite all these options and the resulting flexibility, all differences are comparable to the scenario
27
where for example someone takes a piece of wire and reconnects the pads of the TOE using a soldering
28
bolt. This does not change anything on the TOE security or security policy.
29
To each of the TOE relevant optional different mask set variants, an individual value is assigned, which
30
is part of the data output of the Generic Chip Identification Mode (GCIM). By that the various hardware
31
mask sets can be clearly identified and differentiated by the GCIM output. The interpretation of the
32
output GCIM data is clearly explained in the user guidance, Hardware Reference Manual [7].
33
There are no other differences between the mask sets the TOE is produced with, and all these changes
34
have no impact on the TOEs security policies and related functions. Details are explained in the user
35
guidance SLE97 M5072 Hardware Reference Manual [7] and in the M5072 Errata Sheet [12].
36
7
Security Target Lite
M5072
Public
In addition to these hardware differences, the M5072 allows a maximum of configuration possibilities
1
defined by the customer order following the market needs. A detailed description of the TOE
2
configuration possibilities is given in chapter 2.1.8 TOE Configuration.
3
4
8
Security Target Lite
M5072
Public
1.2 Target of Evaluation overview
1
The TOE comprises the Infineon Technologies AG security controller M5072 with specific IC dedicated
2
software and optional RSA, EC and Toolbox libraries.
3
The TOE is a member of the Infineon Technologies AG security controller family SLE97 meeting high
4
requirements in terms of performance and security. The SLE97 family has been developed with a
5
modular concept and different memory configurations, sets of peripherals and interfaces as well as
6
different security features to satisfy market requirements. A summary product description is given in this
7
Security Target (ST).
8
The TOE offers all functions that are required and useful in security systems, and integrated peripherals
9
that are needed in high-end chipcard applications, such as embedded security, NFC and Mobile
10
Payment.
11
The TOE implements a dedicated security 32-bit RISC CPU designed on the basis of the ARMv7_M
12
architecture designed in 90 nm CMOS technology. The integrated peripheral combine enhanced
13
performance and optimized power consumption for a minimized die size to make the SLE97 controllers
14
ideal for chipcard applications. The TOE offer a wide range of peripherals, including a UART (using the
15
ISO interface), four timers, two watchdogs, a CRC module, a true RNG (TRNG), coprocessors for
16
symmetric (e.g. DES, AES) and asymmetric (e.g. RSA, EC) cryptographic algorithms. Additionally a
17
range of communication interfaces, such as GPIO, I2C, SWP, USB, SSC/SPI and a Mifare-compatible
18
Interface are offered to provide maximum flexibility in terms of simultaneously communication ability.
19
The TOE provides a real 32-bit CPU-architecture and is compatible to the ARMv7-M instruction set
20
architecture. The major components of the core system are the 32-bit CPU as a variant of the ARM
21
Secure Core SC300, the Cache system, the Memory Protection Unit and the Memory
22
Encryption/Decryption Unit. The TOE implements a full 32-bit addressing with up to 4 GByte linear
23
addressable memory space, a simple scalable memory management concept and a scalable stack size.
24
The flexible memory concept is built on the non volatile memory, respectively SOLID FLASH™ NVM1
.
25
For the SOLID FLASH™ NVM the Unified Channel Programming (UCP) memory technology is used.
26
The TOE provides the low-level firmware components Boot Software (BOS) and Resource Management
27
System (RMS) and the high-level firmware Flash Loader (FL) and Mifare-compatible software. The RMS
28
firmware providing some functionality via an API to the Smartcard Embedded Software contains for
29
example SOLID FLASH™ NVM service routines and functionality for the tearing save write into the
30
SOLID FLASH™ NVM. The BOS firmware (BOS-V1 and BOS-V2) is used for test purposes during start-
31
up and the FL allows downloading of user software to the NVM during the manufacturing process. The
32
BOS is implemented in a separated Test-ROM being part of the TOE. For the TOE two different versions
33
of the BOS are provided (BOS-V1 and BOS-V2). The version BOS-V1 (Firmware Identifier 80001141
34
and 80001145) executes the UMSLC test during the startup phase, the version BOS-V2 (Firmware
35
Identifier 80001144) does not execute the UMSLC test during the startup phase to short the time
36
duration of the startup phase. The Mifare-compatible software includes support for the optional
37
Management of Mifare-compatible Cards as well as support to ease the implementation of the optional
38
Mifare-compatible Reader Mode Support functionality.
39
The two cryptographic co-processors serve the need of modern cryptography: The symmetric co-
40
processor (SCP) combines both AES and Triple-DES with dual-key or triple-key hardware acceleration.
41
The Asymmetric Crypto Co-processor, called Crypto2304T in the following, supports RSA-2048 bit
42
(4096-bit with CRT) and Elliptic Curve (EC) cryptography with high performance.
43
A True Random Number Generator (TRNG) specially designed for smart card applications is
44
implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31 and
45
produces genuine random numbers which then can be used internally or by the user software.
46
The software part of the TOE consists of the cryptographic libraries RSA and EC and the supporting
47
Toolbox and asymmetric Base library and the optional Symmetric Crypto Library (SCL). If the RSA or EC
48
or Toolbox library is part of the shipment, the asymmetric Base library is automatically included.
49
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.
9
Security Target Lite
M5072
Public
The RSA library is used to provide a high-level interface to RSA (Rivest, Shamir, Adleman) cryptography
1
implemented on the hardware component Crypto2304T and includes countermeasures against SPA,
2
DPA and DFA attacks. The routines are used for the generation of RSA key pairs1
, RSA signature
3
verification, RSA signature generation and RSA modulus recalculation.The hardware Crypto2304T unit
4
provides the basic long number calculations (add, subtract, multiply, square with 1100 bit numbers) with
5
high performance. The RSA library is delivered as object code. The RSA library can perform RSA
6
operations from 512 to 4096 bits. Following the BSI2
recommendations, key lengths below 1976 bits are
7
not included in the certificate.
8
The EC library is used to provide a high-level interface to Elliptic Curve cryptography implemented on the
9
hardware component Crypto2304T and includes countermeasures against SPA, DPA and DFA attacks.
10
The routines are used for ECDSA signature generation, ECDSA signature cerification, ECDSA key
11
generation and Elliptic Curve Diffie-Hellman key agreement. The EC library is delivered as object code.
12
The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of
13
160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits, due to national AIS32 regulations by
14
the BSI. Note that there are numerous other curve types, being also secure in terms of side channel
15
attacks on this TOE, which can the user optionally add in the composition certification process.
16
The Toolbox library does not provide cryptographic support or additional security functionality as it
17
provides only the following basic long integer arithmetic and modular functions in software, supported by
18
the cryptographic coprocessor: Addition, subtraction, division, multiplication, comparison, reduction,
19
modular addition, modular subtraction, modular multiplication, modular inversion and modular
20
exponentiation. No security relevant policy, mechanism or function is supported. The toolbox library is
21
deemed for software developers as support for simplified implementation of long integer and modular
22
arithmetic operations.
23
The asymmetric Base library provides the low level interface to the asymmetric cryptographic
24
coprocessor and has no user available interface. The asymmetric Base library does not provide any
25
security functionality, implements no security mechanisms and does not contribute to a security
26
functional requirement.
27
The Symmetric Crypto library (SCL) is used to provide a high level interface to DES/3TDES and AES
28
symmetric cryptographic operations. It uses the SCP of the underlying hardware but implements also
29
countermeasures against all known weaknesses of the SCP (e.g. dummy calculations and block
30
repetitions). The symmetric crypto library consists of three C-library files Cipher.lib, AES.lib and DES.lib.
31
Those library files will not be distributed individually. Therefore we call those three library files simply the
32
Symmetric Crypto Library (SCL)
33
The cryptographic libraries RSA and EC, the Toolbox library and the SCL are delivery options. If one of
34
the libraries RSA, EC or Toolbox is delivered, the asymmetric Base library is automatically part of it. In
35
the case of deselecting one or several of these libraries the TOE does not provide the corresponding
36
functionality for additional specific security functionality Rivest-Shamir-Adleman Cryptography (RSA)
37
and/or Elliptic Curve cryptography (EC).
38
To fulfill the high security standards for smartcards today and also in the future, this TOE utilizes an
39
integral security concept comprising countermeasure mechanisms specially designed against possible
40
attack scenarios. The TOE provide a robust set of sensors for the purpose of monitoring proper chip
41
operating conditions and detecting fault attack scenarios. The sensors are complemented with digital
42
error detection mechanisms such as parities, error detection codes and instruction stream signatures.
43
Probing and forcing attacks will be counteracted by the security optimized wiring approach, implemented
44
by an Infineon-specific shielding combined with secure wiring of security critical signals, partly masking
45
of security critical signals and by encryption of all memories inside the chip (RAM, ROM, NVM). A
46
decentralized alarm propagation and system deactivation principle is implemented, further decreasing
47
1
Generation of RSA key pairs is only provided by version 2.06.003 of the library
2
Bundesamt für Sicherheit in der Informationstechnik (BSI) is the German Federal Office for Information Security
10
Security Target Lite
M5072
Public
the risk of manipulating and tampering. Additionally, an online check of the security mechanisms is
1
available by using the User Mode Security Life Control (UMSLC). Side-channel attacks (e.g. Timing
2
Attack, SPA, DPA, EMA) are typically defeated using a combination of hardware and software
3
mechanisms, for this the TOE provides several supporting features e.g. trash register writes and
4
instruction interrupt prevention. The Instruction Stream Signature Checking (ISS) is a powerful
5
countermeasure against fault attacks that try to manipulate the execution sequence of the instruction
6
stream. All executed instructions are hashed in the CPUs signature register and the hardware
7
automatically checks the fitting of the values.
8
In this security target the TOE is described and a summary specification is given. The security
9
environment of the TOE during its different phases of the lifecycle is defined. The assets are identified
10
which have to be protected through the security policy. The threats against these assets are described.
11
The security objectives and the security policy are defined, as well as the security requirements. These
12
security requirements are built up of the security functional requirements as part of the security policy
13
and the security assurance requirements. These are the steps during the evaluation and certification
14
showing that the TOE meets the targeted requirements. In addition, the functionality of the TOE
15
matching the requirements is described.
16
The assets, threats, security objectives and the security functional requirements are defined in this
17
Security Target and in [1] and are referenced here. These requirements build up a minimal standard
18
common for all Smartcards.
19
The security functions are defined here in the security target as property of this specific TOE. Here it is
20
shown how this specific TOE fulfils the requirements for the standard defined in the Protection Profile [1].
21
The user software can be implemented in various options depending on the user’s choice and described
22
in chapter 2.1.8. Thereby the user software can be implemented the NVM or coming without user
23
software. In the latter case, the user downloads his entire software on his own using the Flash Loader
24
software.
25
26
The TOE uses also Special Function Registers SFR. These SFR registers are used for general purposes
27
and chip configuration. These registers are located in the SOLID FLASH™ NVM as configuration area
28
page.
29
A shielding algorithm finishes the upper layers above security critical signals and wires, finally providing
30
the so called “security optimized wiring”.
31
The TOE with its integrated security features meets the requirements of all smart card applications such
32
as information integrity, access control, mobile telephone and identification, as well as uses in electronic
33
funds transfer and healthcare systems.
34
To sum up, the TOE is a powerful smart card IC with a large amount of memory and special peripheral
35
devices with improved performance, optimized power consumption, at minimal chip size while
36
implementing high security.
37
11
Security Target Lite
M5072
Public
2 Target of Evaluation Description
1
The TOE description helps to understand the specific security environment and the security policy. In
2
this context the assets, threats, security objectives and security functional requirements can be
3
employed. The following is a more detailed description of the TOE than in [1] as it belongs to the specific
4
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 and
12
2.1.8. The second part of this TOE includes the associated firmware and software required for operation.
13
The TOE can be delivered in various configurations, achieved by means of blocking and depending on
14
the customer order.
15
The documents as described in section 2.1.5 and listed in Table 1, are supplied as user guidance. All
16
product derivatives of this TOE, including all configuration possibilities differentiated by the GCIM data
17
and the configuration information output, are manufactured by Infineon Technologies AG. In the following
18
descriptions, the term “manufacturer” stands short for Infineon Technologies AG, the manufacturer of the
19
TOE. The Smartcard Embedded Software respectively user software is not part of the TOE. New
20
configurations can occur at any time depending on the user blocking or by different configurations
21
applied by the manufacturer. In any case the user is able to clearly identify the TOE hardware, its
22
configuration and proof the validity of the certificate independently, meaning without involving the
23
manufacturer. The various blocking options, as well as the means used for the blocking, are done during
24
the manufacturing process or at user premises. Entirely all means of blocking and the for the blocking
25
involved firmware respectively software parts, used at Infineon Technologies AG and/or the user
26
premises, are subject of the evaluation. All resulting configurations of a TOE derivative are subject of the
27
certificate. All resulting configurations are either at the predefined limits or within the predefined
28
configuration ranges.
29
One or more additional metal layer may be added on top of one of the TOE mask set. These additional
30
metal layers, it could also be more than one, just reroute the pads. Therefore, this last rerouting on top
31
does not change the function of the TOE itself and is depending on the package only, and are not
32
relevant for the security of the TOE. For these reasons, the metal layers are out the scope of the
33
certification and do not belong to the TOE. Of course, in all cases passivation and isolation coating is
34
applied on top of the last layers carrying wires.
35
The firmware used for the TOE internal testing and TOE operation, the firmware and software parts
36
exclusively used for the blocking, the parts of the firmware and software required for cryptographic
37
support are part of the TOE and therefore part of the certification. The documents as described in
38
chapter 2.1.5 are supplied as user guidance.
39
Not part of the TOE and not part of the certification are:
40
 the Smartcard Embedded Software respectively user software, and
41
 the piece of software running at user premises and collecting the BPU receipts coming from the TOE.
42
This BPU software part is the commercially deemed part of the BPU software, not running on the
43
TOE, but allowing refunding the customer, based on the collected user blocking information. The
44
receipt from each blocked TOE is collected by this software – chip by chip.
45
46
47
12
Security Target Lite
M5072
Public
2.1.1 Hardware of the TOE
1
The hardware part of the TOE (see Figure 1) as defined in [1] is comprised of:
2
Core System
3
 32-bit CPU implementation of ARM Secure Core SC300 based on ARMv7-M Instruction set
4
architecture including the Instruction Stream Signature Checking (ISS)
5
 CACHE for code and data buffering
6
 Memory Encryption/Decryption Unit (MED) and Error Detection Unit
7
 Memory Protection Unit (MPU)
8
 Nested Vectored Interrupt Controller (NVIC)
9
10
Memories
11
 Read-Only Memory (ROM, for internal firmware)
12
 Random Access Memory (RAM)
13
 SOLID FLASH™ NVM memory (NVM)
14
Note that the TOE has implemented a SOLID FLASH™ NVM memory module. Parts of this memory
15
module are configured to work as an EEPROM.
16
17
Peripherals
18
 Universal Asynchronous Receiver/Transmitter (UART)
19
 Single-Wire Protocol (SWP) with Mifare-compatible interface
20
 Inter Integrated Circuit (I2C) interface
21
 General Purpose Input Output (GPIO)
22
 Synchronous Serial Communication (SSC) which provides the
23
Serial Peripheral Interface (SPI)
24
 Universal Serial Bus (USB) interface
25
 Standard ISO Interface (PAD)
26
 True Random Number Generator (TRNG)
27
 Timers and Watchdog including a checkpoint register (T&W)
28
 System Module (SYS)
29
 Clock Unit (CLK)
30
31
Coprocessors
32
 Crypto2304T co-processor for asymmetric algorithms like RSA and EC (Crypto, optional)
33
 Symmetric Crypto co-processor for 3DES and AES Standards (SCP, optional)
34
 Checksum module (CRC)
35
36
Analog Module (ANA)
37
 Glitch Sensor
38
 Temperature Sensor
39
 Backside Light Detector
40
 User Mode Security Life Control (UMSLC)
41
13
Security Target Lite
M5072
Public
1
Buses
2
 Memory Bus
3
 Peripheral Bus
4
5
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
SWP UART
T&W
USB
6
Core Core System ROM Read Only Memory
7
NVM SOLID FLASH™ NVM RAM Random Access Memory
8
CLK Clock Unit SYS System Module
9
Crypto Crypto2304T SCP Symmetric Crypto Processor
10
CRC Cyclic Redundancy Check TRNG True Random Number Generator
11
T&W Timer and Watchdog UART UART
12
I2C Inter Integrated Circuit GPIO General Purpose IO
13
SSC Synchronous Serial Communication SWP Single Wire Protocol
14
USB Universal Serial Bus ANA Analog Units
15
ISO Standard ISO Interface
16
17
Figure 1 Block diagram of the TOE
18
19
The TOE consists of smart card ICs (Security Controllers) meeting high requirements in terms of
20
performance and security. They are manufactured by Infineon Technologies AG in a 90 nm CMOS-
21
technology (L90). This TOE is intended to be used in smart cards for particularly security-relevant
22
applications and for its previous use as developing platform for smart card operating systems according
23
to the lifecycle model from [1]
24
The term Smartcard Embedded Software is used in the following for all operating systems and
25
applications stored and executed on the TOE. The TOE is the platform for the Smartcard Embedded
26
Software. The Smartcard Embedded Software itself is not part of the TOE.
27
14
Security Target Lite
M5072
Public
The TOE consists of a core system, memories, co-processors, security peripherals, control logic and
1
peripherals. The major components of the core system are the 32-bit CPU (Central Processing Unit), the
2
MPU (Memory Protection Unit), the MED (Memory Encryption/Decryption Unit), the Nested Vectored
3
Interrupt Controller (NVIC), the Instruction Stream Signature Checking (ISS) and the Cache system. The
4
TOE contains the co-processors for RSA/EC (Crypto2304T) and DES/AES (SCP) processing, a CRC
5
module and the peripherals random number generator, four timers and two watchdog timers and several
6
external interface services. All data of the memory block is encrypted, RAM and ROM are equipped with
7
an error detection code (EDC) and the SOLID FLASH™ NVM is equipped in addition with an error
8
correction code (ECC).
9
The memories are connected to the Core with the Memory Bus and the peripherals are connected with
10
the Peripheral Bus.
11
The Analog Modules (ANA) serve for operation within the specified range and manage the alarms. A set
12
of sensors (temperature sensor, backside light detector, glitch sensor) is used to detect excessive
13
deviations from the specified operational range and serve for robustness of the TOE and the UMSLC
14
function can be used to test the alarm lines.
15
The CPU is compatible with the instruction set of the ARMv7_M architecture. Despite its compatibility the
16
CPU implementation is entirely proprietary and not standard.
17
The CPU accesses the memory via the integrated Memory Encryption and Decryption unit (MED). The
18
memory model of the TOE provides two distinct, independent levels. Additionally up to eight regions can
19
be defined with different access rights controlled by the Memory Protection Unit (MPU). Errors in RAM
20
and ROM are automatically detected (EDC, Error Detection Code), in terms of the SOLID FLASH™
21
NVM errors are detected and 1-Bit-errors are also corrected (ECC, Error Correction Code).
22
The controller of this TOE stores both code and data in a linear 4-GByte memory space, allowing direct
23
access without the need to swap memory segments in and out of memory using a memory protection
24
unit.
25
The CACHE is a high-speed memory-buffer located between the CPU and the (external) main memories
26
holding a copy of some of the memory contents to enable access, which is considerably faster than
27
retrieving the information from the main memory. In addition to its fast access speed, the CACHE also
28
consumes less power than the main memories. The CACHE is equipped with a integrity check to verify
29
the contents of the cache memories.
30
A True Random Number Generator (TRNG) specially designed for smart card applications is
31
implemented. The TRNG fulfils the requirements from the functionality class PTG.2 of the AIS31 and
32
produces genuine random numbers which then can be used internally or by the user software.
33
The implemented sleep mode logic (clock stop mode per ISO/IEC 7816-3) is used to reduce the overall
34
power consumption. The timers permits easy implementation of communication protocols such as T=1
35
and all other time-critical operations. The UART-controlled I/O interface allows the smart card controller
36
and the terminal interface to be operated independently.
37
The Clock Unit (CLKU) supplies the clocks for all components of the TOE. It generates the system clock
38
and an approximately 1MHz clock for the timers. The 1MHz clock is derived from an internal oscillator,
39
while the system clock may either be based on the internal oscillator clock (internal clock mode) or on an
40
external clock (external clock mode). Additionally a sleep mode is available. When operating in the
41
internal clock mode the system frequency can be configured by the user software combined with the
42
current limitation functionality. In the external clock mode the clock is derived from the external clock and
43
a parameter with the range of 1 to 8. The system frequency may be 1 up to 8 times the externally applied
44
frequency but is of course limited to the maximum system frequency and can be combined with the
45
current limitation function.
46
Two co-processors for cryptographic operations are implemented on the TOE. The Crypto2304T for
47
calculation of asymmetric algorithms like RSA and Elliptic Curve (EC) and the Symmetric Cryptographic
48
Processor (SCP) for dual-key or triple-key triple-DES and AES calculations. These co-processors are
49
especially designed for smart card applications with respect to the security and power consumption. The
50
15
Security Target Lite
M5072
Public
SCP module computes the complete DES algorithm within a few clock cycles and is especially designed
1
to counter attacks like DPA, EMA and DFA. The Crypto2304T module provides basic functions for the
2
implementation of RSA and EC cryptographic libraries.
3
Note that this TOE can be delivered with both crypto co-processors accessible, or with a blocked SCP or
4
with a blocked Crypto2304T, or with both crypto co-processors blocked. The blocking depends on the
5
customer demands prior to the production of the hardware. No accessibility of the deselected
6
cryptographic co-processors is without impact on any other security policy of the TOE; it is exactly
7
equivalent to the situation where the user decides just not to use the cryptographic co-processors.
8
The cyclic redundancy check (CRC) module is a 16-bit checksum generator, which shall not be used for
9
security-critical data. The TOE includes two timer modules each with two 16-bit general purpose timers.
10
The timer module can be used also as watchdog timer to monitor system operation for possible timeouts
11
and to check the correct order of operation.
12
An Interface Management module, located in the System Module (SYS), provides the TOE with the
13
possibility to maintain two or more data interfaces simultaneously. The TOE is provided with, dependent
14
on the configuration, different peripherals and interfaces as the Universal Serial Bus (USB), the SWP
15
Slave Peripheral (SWP), the Synchronous Serial Communication (SSC), which provides the serial
16
Peripheral Interface (SPI), the GPIO module (GPIO), the Inter-Integrated Cirquit Module (I2C) and the
17
Standard ISO Interface (PAD) to satisfy the different market requirements.
18
19
2.1.2 Firmware of the TOE
20
The entire firmware and software of the TOE consists of different parts:
21
The BOS (Boot Software) and the RMS (Resource Management System) compose the TOE firmware
22
stored in the ROM and the patches hereof in the SOLID FLASH™ NVM. All mandatory functions for
23
start-up and internal testing (BOS) are protected by a dedicated hardware firewall. Additionally two levels
24
are provided, the privileged level and the non-privilege level, both are protected by a hardwired Memory
25
Protection Unit (MPU) setting. For the TOE two different versions of the BOS are provided (BOS-V1 and
26
BOS-V2). The version BOS-V1 (Firmware Identifier 80001141, 80001145) executes the UMSLC test
27
during the startup phase, the version BOS-V2 (Firmware Identifier 80001144) does not execute the
28
UMSLC test during the startup phase to shorten the time duration of the startup phase. The RMS is
29
accessible in privileged level only. The FL (Flash Loader) and the Mifare-compatible software compose
30
the TOE software stored in the SOLID FLASH™ NVM. The FL allows downloading of user software to
31
the NVM during the manufacturing process and can be completely deactivated.
32
33
The Mifare-compatible software includes the Mifare-compatible Operating System and additionally the
34
optional library Management of Mifare-compatible Cards (version 01.03.0927 and 01.04.1275) and the
35
optional library Mifare-compatible Reader Mode Support (01.02.0800). The Management of Mifare-
36
compatible Cards provides an API for the management and generation of Mifare-compatible Cards (note
37
that the version 01.04.1275 provides an additionally command). The optional Mifare-compatible Reader
38
Mode support library (01.02.0800) enables an access to external Mifare-compatible cards. The Mifare
39
related libraries are not within the logical scope of the TOE, the libraries do not implement any security
40
relevant policy or function and are not within the scope of the evaluation.
41
42
2.1.3 Optional software of the TOE
43
44
The optional software part of the TOE consists of the cryptographic libraries RSA and EC, the supporting
45
Toolbox and asymmetric Base libreries, the optional SCL and the Management of Mifare-compatible
46
Cards library and the Mifare-compatible Reader Mode Support library.
47
16
Security Target Lite
M5072
Public
The Mifare-compatible software includes support for the optional Management of Mifare-compatible
1
Cards as well as support to ease the implementation of the optional Mifare-compatible Reader Mode
2
Support functionality. The Mifare related libraries are not within the logical scope of the TOE, the
3
libraries do not implement any security relevant policy or function and are not within the scope of the
4
evaluation.
5
The RSA library is used to provide a high-level interface to the RSA cryptography implemented on the
6
hardware component Crypto2304T and includes countermeasures against SPA, DPA and DFA attacks.
7
The routines are used for the generation of RSA Key Pairs1
, the RSA signature verification, the RSA
8
signature generation and the RSA modulus recalculation. The module provides the basic long number
9
calculations (add, subtract, multiply, square with 1100-bit numbers) with high performance.
10
The RSA library is delivered as object code and is integrated in this way into the user software. The RSA
11
library can perform RSA operations from 512 to 4096 bits. Depending on the customer’s choice, the TOE
12
can be delivered with the 4096 code portion or with the 2048 code portion only. The 2048 code portion is
13
included in both.
14
Part of the evaluation are the RSA straight operations with key lengths from 1024 bits to 2048 bits, and
15
the RSA CRT operations with key lengths of 1024 bits to 4096 bits. Note that key lengths below 1024
16
bits are not included in the certificate.
17
The EC library is used to provide a high level interface to Elliptic Curve cryptography and includes
18
countermeasures against SPA, DPA and DFA attacks. The routines are used for ECDSA signature
19
generation, ECDSA signature verification, ECDSA key generation and Elliptic Curve Diffie-Hellman key
20
agreement. The EC library is delivered as object code and integrated in this way into the user software.
21
The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of
22
160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits, due to national AIS32 regulations by
23
the BSI. Note that there are numerous other curve types, being also secure in terms of side channel
24
attacks on this TOE, which can the user optionally add in the composition certification process.
25
The Toolbox library provides long integer and modular arithmetic operations. It does not support any
26
security relevant policy or function.
27
The Asymmetric Base library provides the low level interface to the asymmetric cryptographic
28
coprocessor for the RSA and ECC cryptographic libraries and has no user available interface. It does not
29
support any security relevant policy or function. The Base, ECC and RSA library can optionally be
30
delivered in the following versions:
31
 The legacy version v1.03.006 for backward compatibility
32
 The recommended new version v2.06.003
33
The Symmetric Crypto library (SCL) is used to provide a high level interface to DES/3TDES and AES
34
symmetric cryptographic operations. It uses the SCP of the underlying hardware but implements also
35
countermeasures against all known weaknesses of the SCP (e.g. dummy calculations). The symmetric
36
crypto library consists of three C-library files Cipher.lib, AES.lib and DES.lib. Those library files will not
37
be distributed individually. Therefore we call those three library files simply the Symmetric Crypto Library
38
(SCL)
39
40
Table 2 Chip and optional software delivery matrix
41
Chip Waferfab Toplayer Firmware-ID RSA/ECC lib SCL
M5072 G11 TSMC WLB 80001141 (BOS-V1)
80001145 (BOS-V1)
80001144 (BOS-V2)
1.03.006
2.06.003
2.02.010
42
2.1.4 Interfaces of the TOE
43
 The physical interface of the TOE to the external environment is the entire surface of the IC.
44
 The electrical interface of the TOE to the external environment is constituted by the pads of the chip:
45
1
Generation of RSA key pairs is only provided by version 2.06.003 of the library
17
Security Target Lite
M5072
Public
− The five ISO 7816 pads consist particularly of the contacted RES, I/O, CLK lines and supply lines
1
VCC and GND. The contact based communication is according to ISO 7816/ETSI/EMV.
2
− The I2C communication can be driven via the ISO 7816 pads. In this case no other communication
3
using the ISO 7816 pads is possible.
4
− The GPIO interface consists of 4 pads which can be individually configured and combined in
5
various ways.
6
− Also the I2C and the SSC/SPI communication can be exclusively driven via the GPIO pads. In this
7
case no other communication using the GPIO pads is possible.
8
− The USB interface is build out of two dedicated pads for data communication and two pads used
9
from the ISO 7816 interface supplying power and ground.
10
− The SWP interface is build out of one pad to support the SWP slave functionality.
11
 The data-oriented I/O interface to the TOE is formed by the I/O pad.
12
 The interface to the firmware is constituted by special registers used for hardware configuration and
13
control (Special Function Registers, SFR).
14
 The interface of the TOE to the operating system is constituted on one hand by the RMS routine calls
15
and on the other by the instruction set of the TOE.
16
 The interface of the TOE to the test routines is formed by the BOS test routine call, i.e. entry to test
17
mode (OS-TM entry).
18
 The interface to the RSA calculations is defined by the RSA library (optionally).
19
 The interface to the EC calculations is defined by the EC library (optionally).
20
 The interface to the Toolbox basic arithmetic functions is defined by the Toolbox library (optionally).
21
 The interface to the symmetric crypto operations DES/3TDES/AES is defined by the SCL (optionally).
22
2.1.5 Guidance documentation
23
The guidance documentation consists
24
 SLE97 Hardware Reference Manual
25
 ARMv7-M Architecture Reference Manual, ARM Limited , ARM DDI 0403D ID021310,
26
12. February 2010
27
 SLE97 / SLC14 Family Production and Personalization User´s Manual
28
 SLE97 Programmer´s Reference Manual
29
 M5072 Security Guidelines User´s Manual
30
 M5072 Errata Sheet
31
 SLE97 Asymmetric Crypto Library for Crypto@2304T RSA/ECC/Toolbox
32
User Interface (optional)
33
 CL97 Asymmetric Crypto Library for Crypto@2304T RSA/ECC/Toolbox
34
User Interface (optional)
35
 SLx97 Symmetric Crypto Library for SCP version 3 DES/AES (optional)
36
37
Finally the certification report may contain an overview of the recommendations to the software
38
developer regarding the secure use of the TOE. These recommendations are also included in the
39
ordinary documentation.
40
2.1.6 Forms of delivery
41
The TOE can be delivered in form of bare dies, in form of plain wafers, in form of complete modules
42
(wire bond module M4.x, provided as single chip wire bond or as stacked wire bond), or in one of the
43
following an IC cases: S-MFC5.8-8-1, S-MFC5.6-6-1, S-MFC5.4-6-1 (FCOS).. The form of delivery does
44
not affect the TOE security and it can be delivered in any form, as long as the processes applied and
45
sites involved have been subject of the appropriate audit.
46
18
Security Target Lite
M5072
Public
The delivery can therefore be at the end of phase 3 or at the end of phase 4 which can also include pre-
1
personalization steps according to PP [1]. Nevertheless in both cases the TOE is finished and the
2
extended test features are removed. In this document are always both cases mentioned to avoid
3
incorrectness but from the security policy point of view the two cases are identical.
4
The delivery to the software developer (phase 2  phase 1) contains the development package and is
5
delivered in form of documentation as described above, data carriers containing the tools and emulators
6
as development and debugging tool.
7
Part of the software delivery could also be the Flash Loader program, provided by Infineon
8
Technologies, running on the TOE and receiving via the UART interface the transmitted information of
9
the user software to be loaded into the SOLID FLASH™ NVM memory. The download is only possible
10
after successful authentication. The user software can also be downloaded in an encrypted way. In
11
addition, the user can permanently block further use of the Flash Loader. Whether the Flash Loader
12
program is present or not depends on the procurement order.
13
2.1.7 Production sites
14
The silicon of the design G11 is produced at TSMC/Taiwan
15
The delivery measures are described in the ALC_DVS aspect.
16
17
Table 3 Production site in chip identification
18
Production Site Chip Identification
TSMC, Taiwan byte number 13 (Fab number): 0AH
19
20
2.1.8 TOE Configuration
21
This TOE is represented by various configurations called products, which are all derived from the equal
22
hardware design M5072. The same mask is used to produce different products of the TOE. The first
23
metal mask (called the M1 mask) contains the specific information to identify the TOE.
24
The M5072 product offers different configuration options, which a customer can choose. The mechanism
25
to choose a configuration can be done by the following methods:
26
1. by product selection or dialog-based in Tools,
27
2. via Bill-per-Use (BpU) and Flash Loader (FL),
28
29
The degree of freedom for configuring the TOE is predefined by Infineon Technologies AG. The list of
30
predefined TOE configurations is given, as an example in Table 3 and in the SLE97 Hardware
31
Reference Manual [7], section 18.
32
For details about the TOE configurations, please see [ST]
33
All these possible TOE configurations equal and/or within the specified ranges are covered by the
34
certificate.
35
36
Beside fix TOE configurations, which can be ordered as usual, this TOE implements optionally the so
37
called Bill-Per-Use (BPU) ability. This solution enables the customer to tailor the product on his own to
38
the required configuration by blocking parts of the chip on demand into the final configuration at his own
39
premises, without further delivery or involving support by Infineon Technology AG. Customers, who are
40
intended to use this feature receiving the TOE in a predefined configuration including the Flash Loader
41
software, enhanced with the BPU blocking software. The blocking information is part of a chip
42
configuration area and can be modified by customers using specific APDUs. Once a final blocking is
43
done, further modifications are disabled.
44
The BPU software part is only present on the products which have been ordered with the BPU option. In
45
all other cases this software is not present on the product.
46
19
Security Target Lite
M5072
Public
Additionally the user can choose between different firmware BOS versions and optional software
1
libraries.
2
3
The user can choose between one of the Management of Mifare-compatible Cards libraries (version
4
01.03.0927 or 01.04.1275) and the Mifare-compatible Reader Mode Support library (01.02.0800) or the
5
user can choose only one of the three libraries.
6
The user can choose1
one or a free combination out of the libraries RSA2048, RSA4096, EC and
7
Toolbox and SCL.
8
The hardware of this TOE can be delivered with the following configuration options:
9
 both crypto co-processors accessible
10
 with a blocked SCP
11
 with a blocked Crypto2304T
12
 both crypto co-processors blocked
13
In case the SCP is blocked, no AES and 3DES computation supported by hardware is possible. In the
14
case the Crypto2304T is blocked, no RSA and EC computation supported by hardware is possible. No
15
accessibility of the deselected cryptographic co-processors is without impact on any other security policy
16
of the TOE; it is exactly equivalent to the situation where the user decides just not to use the
17
cryptographic co-processors.
18
The TOE can be delivered with the following optional libraries
19
 RSA
20
 ECC
21
 Asymmetric Base library for RSA and ECC
22
 Toolbox
23
 SCL for AES/DES
24
25
The libraries of this TOE can be delivered according to the following dependencies:
26
 If one of the libraries RSA, EC or Toolbox is delivered, the asymmetric Base library is automatically
27
part of it.
28
29
In case of deselecting one or several of these libraries the TOE does not provide the respective
30
functionality.
31
32
2.1.9 TOE initialization with Customer Software
33
Beside the various TOE configurations further possibilities of how the user inputs his software on the
34
TOE are in place. This provides a maximum of flexibility and for this an overview is given in the following
35
table:
36
37
Table 4 Options to implement user software at Infineon production premises
38
1 The user or/and a subcontractor downloads
the software into the SOLID FLASH™ NVM
memory on his own. Infineon Technologies
AG has not received user software and there
are no user data in the ROM.
The Flash Loader can be activated or
reactivated by the user or subcontractor to
download his software in the SOLID
FLASH™ NVM memory.
2 The user provides software for the download
into the SOLID FLASH™ NVM memory to
Infineon Technologies AG. The software is
The Flash Loader is deactivated.
1
The user may choose either v1.03.006 or v2.06.003 of the RSA/EC/Toolbox libraries, but he may not intermix different
versions.
20
Security Target Lite
M5072
Public
downloaded to the SOLID FLASH™ NVM
memory during chip production. There are
no user data in the ROM.
3 The user provides software for the download
into the SOLID FLASH™ NVM memory to
Infineon Technologies AG. The software is
downloaded to the SOLID FLASH™ NVM
memory during chip production. There are
no user data in the ROM
The Flash Loader is blocked afterwards but
can be activated or reactivated by the user
or subcontractor to download his software in
the SOLID FLASH™ NVM memory.
Precondition is that the user has provided an
own reactivation procedure in software prior
chip production to Infineon Technologies AG.
1
The Generic Chip Identification Mode (GCIM) data of the TOE allows a unique identification of each TOE
2
and provides several detailed production information. The Chip Identification Mode data is accessible by
3
a non-ISO reset or can be read directly from the configuration area located at the NVM by the user
4
operating system. The SLE97 Hardware Reference Manual [7] gives a detailed description of the GCIM
5
data.
6
21
Security Target Lite
M5072
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 [2],
3
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 Sicherheit in
10
der Informationstechnik1
(BSI) under the reference BSI-PP-0035, Version 1.0, dated 15.06.2007.
11
The security assurance requirements of the TOE are according to the Security IC Platform Protection
12
Profile [1]. They are all drawn from Part 3 of the Common Criteria version v3.1.
13
The augmentations of the PP [1] are listed below.
14
15
Table 5 Augmentations of the assurance level of the TOE
16
Assurance
Class
Assurance
components
Description
Life-cycle
support
ALC_DVS.2 Sufficiency of security measures
Vulnerability
assessment
AVA_VAN.5 Advanced methodical vulnerability analysis
17
3.3 Package Claim
18
This Security Target does not claim conformance to a package of the PP [1].
19
The assurance level for the TOE is EAL5 augmented with the components ALC_DVS.2 and
20
AVA_VAN.5.
21
22
23
1
Bundesamt für Sicherheit in der Informationstechnik (BSI) is the German Federal Office for Information Security
22
Security Target Lite
M5072
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 the
5
security functionality
6
 the IC Dedicated Software with the parts
7
 the IC Dedicated Test Software,
8
 the IC Dedicated Support Software.
9
The TOE is designed, produced and/or generated by the TOE Manufacturer.
10
Security Problem Definition:
11
Following the PP [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 definition
14
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 the
18
usage of key-depending function, and the threat memory access violation T.Mem-Access, 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 additional
22
restrictions is given.
23
The security target fulfils the strict conformance claim of the PP [1] due to the application notes 5, 6 and
24
7 which apply here. By those notes the addition of further security functions and security services are
25
covered, even without deriving particular security functionality from a threat but from a policy.
26
Due to additional security functionality, one coming from the cryptographic libraries - O.Add-Functions,
27
and due to the memory access control - O.Mem-Access, additional security objectives have been
28
introduced. These add-ons have no impact on the conformance statements regarding CC [2] and PP [1],
29
with following rational:
30
The security target remains conformant to CC [2], claim 482 as the possibility to introduce additional
31
restrictions is given.
32
The security target fulfils the strict conformance of the PP [1] due to the application note 9 applying here.
33
This note allows the definition of high-level security goals due to further functions or services provided to
34
the Security IC Embedded Software.
35
Therefore, the security objectives of this security target are consistent with the statement of the security
36
objectives in the PP [1], as the security target claimed strict conformance to the PP [1].
37
38
All security functional requirements defined in the PP [1] are included and completely defined in this ST.
39
The security functional requirements listed in the following are all taken from Common Criteria part 2 [3]
40
and additionally included and completely defined in this ST:
41
 FDP_ACC.1 “Subset access control”
42
 FDP_ACF.1 “Security attribute based access control”
43
23
Security Target Lite
M5072
Public
 FMT_MSA.1 “Management of security attributes”
1
 FMT_MSA.3 “Static attribute initialisation”
2
 FMT_SMF.1 “Specification of Management functions”
3
 FCS_COP.1 “Cryptographic support”
4
 FCS_CKM.1 “Cryptographic key generation”
5
 FDP_SDI.1 “Stored data integrity monitoring
6
 FDP_SDI.2 “Stored data integrity monitoring and action
7
The security functional requirement
8
 FPT_TST.2 “Subset TOE security testing“(Requirement from [3])
9
 FCS_RNG.1 “Generation of Random Numbers”
10
is included and completely defined in this ST, section 6.
11
All assignments and selections of the security functional requirements are done in the PP [1] and in this
12
security target in section 7.4.
13
The Assurance Requirements of the TOE obtain the Evaluation Assurance Level 5 augmented with the
14
assurance components ALC_DVS.2 and AVA_VAN.5 for the TOE.
15
16
3.5 Application Notes
17
The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the Protection
18
Profile [1] according to “Anwendungshinweise und Interpretationen zum Schema (AIS)” [15].
19
24
Security Target Lite
M5072
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 later on
6
in the process of evaluation and certification. An overview on attacks is given in PP [1] section 3.2.
7
The threats to security are defined and described in PP [1] section 3.2.
8
9
Table 6 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
11
4.1.1 Additional Threat due to TOE specific Functionality
12
The additional functionality of introducing sophisticated privilege levels and access control allows the
13
secure separation between the operation system(s) and applications, the secure downloading of
14
applications after personalization and enables multitasking by separating memory areas and performing
15
access controls between different applications. Due to this additional functionality “area based memory
16
access control” a new threat is introduced.
17
The Smartcard Embedded Software is responsible for its User Data according to the assumption
18
“Treatment of User Data (A.Resp-Appl)”. However, the Smartcard Embedded Software may comprise
19
different parts, for instance an operating system and one or more applications. In this case, such parts
20
may accidentally or deliberately access data (including code) of other parts, which may result in a
21
security violation.
22
The TOE shall avert the threat “Memory Access Violation (T.Mem-Access)” as specified below.
23
T.Mem-Access Memory Access Violation
24
Parts of the Smartcard Embedded Software may cause security violations by accidentally or deliberately
25
accessing restricted data (which may include code) or privilege levels. Any restrictions are defined by the
26
security policy of the specific application context and must be implemented by the Smartcard Embedded
27
Software.
28
Table 7 Additional threats due to TOE specific functions and augmentations
29
T.Mem-Access Memory Access Violation
30
For details see PP [1] section 3.2.
31
25
Security Target Lite
M5072
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 processed
9
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 Embedded
11
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 numbers.
14
These random numbers are generated either by a true random number or a deterministic random
15
number generator or by both, when a true random number is used as seed for the deterministic random
16
number generator. Note that the generation of random numbers is a requirement of the PP [1].
17
To be able to protect the listed assets the TOE shall protect its security functionality as well. Therefore
18
critical information about the TOE shall be protected. Critical information includes:
19
 logical design data, physical design data, IC Dedicated Software, and configuration data
20
 Initialisation Data and Pre-personalisation Data, specific development aids, test and characterisation
21
related data, material for software development support, and reticles.
22
The information and material produced and/or processed by the TOE Manufacturer in the TOE
23
development and production environment (Phases 2 up to TOE Delivery) can be grouped as follows:
24
 logical design data,
25
 physical design data,
26
 IC Dedicated Software, Security IC Embedded Software, Initialisation Data and Pre-personalisation
27
Data,
28
 specific development aids,
29
 test and characterisation related data,
30
 material for software development support, and
31
 reticles and products in any form
32
as long as they are generated, stored, or processed by the TOE Manufacturer.
33
For details see PP [1] section 3.1.
34
4.2 Organizational Security Policies
35
The TOE has to be protected during the first phases of their lifecycle (phases 2 up to TOE delivery which
36
can be after phase 3 or phase 4). Later on each variant of the TOE has to protect itself. The
37
organizational security policy covers this aspect.
38
P.Process-TOE Protection during TOE Development and Production
39
An accurate identification must be established for the TOE. This requires that each instantiation of the
40
TOE carries this unique identification.
41
The organizational security policies are defined and described in PP [1] section 3.3. Due to the
42
augmentations of PP [1] an additional policy is introduced and described in the next chapter.
43
26
Security Target Lite
M5072
Public
1
Table 8 Organizational Security Policies according PP [1]
2
P.Process-TOE Protection during TOE Development and Production
4.2.1 Augmented Organizational Security Policy
3
Due to the augmentations of the PP [1] an additional policy is introduced.
4
The TOE provides specific security functionality, which can be used by the Smartcard Embedded
5
Software. In the following specific security functionality is listed which is not derived from threats
6
identified for the TOE’s environment because it can only be decided in the context of the smartcard
7
application, against which threats the Smartcard Embedded Software will use the specific security
8
functionality.
9
The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality
10
(P.Add-Functions)” as specified below.
11
12
P.Add-Functions Additional Specific Security Functionality
13
The TOE shall provide the following specific security functionality to the Smartcard Embedded Software:
14
 Advanced Encryption Standard (AES)
15
 Triple Data Encryption Standard (3DES)
16
 Rivest-Shamir-Adleman Cryptography (RSA)
17
 Elliptic Curve Cryptography (EC)
18
19
Note: This TOE can be delivered with the SCP accessible or blocked. The blocking depends on the
20
customer demands prior to the production of the hardware. In case the SCP is blocked, no 3DES or
21
AES computation supported by hardware is possible. The 3DES and AES functionality has then to
22
be removed from this policy.
23
Note: The TOE can also be delivered with the optional SCL. The optional SCL contains AES and
24
3DES algorithms with additional security countermeasures. The optional SCL needs an accessible
25
SCP. The 3DES and AES functionality has then to be removed from this policy.
26
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
27
the Crypto2304T is blocked, no RSA or ECC computation supported by hardware is possible. The
28
RSA and ECC functionality has then to be removed from this policy.
29
Note: The TOE can also be delivered with the optional RSA library. The optional RSA library needs
30
an accessible Crypto2304T. If the optional RSA library is not delivered then RSA functionality has
31
to be removed from this policy.
32
Note: The TOE can also be delivered with the optional ECC library. The optional ECC library needs
33
an accessible Crypto2304T. If the optional ECC library is not delivered then ECC functionality has
34
to be removed from this policy.
35
36
4.3 Assumptions
37
The TOE assumptions on the operational environment are defined and described in PP [1] section 3.4.
38
27
Security Target Lite
M5072
Public
The assumptions concern the phases where the TOE has left the chip manufacturer.
1
2
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization:
3
It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to
4
delivery to the end-consumer to maintain confidentiality and integrity of the TOE and of its manufacturing
5
and test data (to prevent any possible copy, modification, retention, theft or unauthorised use).
6
7
A.Plat-Appl Usage of Hardware Platform:
8
The Security IC Embedded Software is designed so that the requirements from the following documents
9
are met: (i) TOE guidance documents (refer to the Common Criteria assurance class AGD) such as the
10
hardware data sheet, and the hardware application notes, and (ii) findings of the TOE evaluation reports
11
relevant for the Security IC Embedded Software as documented in the certification report.
12
13
A.Resp-Appl Treatment of User Data:
14
All User Data are owned by Security IC Embedded Software. Therefore, it must be assumed that
15
security relevant User Data (especially cryptographic keys) are treated by the Security IC Embedded
16
Software as defined for its specific application context.
17
18
The support of cipher schemas needs to make an additional assumption.
19
Table 9 Assumption according PP [1]
20
A.Process-Sec-IC Protection during Packaging, Finishing and Personalization
A.Plat-Appl Usage of Hardware Platform
A.Resp-Appl Treatment of User Data
21
22
28
Security Target Lite
M5072
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 below.
3
A.Key-Function Usage of Key-dependent Functions
4
Key-dependent functions (if any) shall be implemented in the Smartcard Embedded Software in a way
5
that they are not susceptible to leakage attacks (as described under T.Leak-Inherent and
6
T.Leak-Forced).
7
Note, that here the routines which may compromise keys when being executed are part of the Smartcard
8
Embedded Software. In contrast to this, the threats T.Leak-Inherent and T.Leak-Forced address (i) the
9
cryptographic routines which are part of the TOE (For details see PP [1] section 3.4.).
10
29
Security Target Lite
M5072
Public
5 Security objectives (ASE_OBJ)
1
This section shows the subjects and objects where are relevant to the TOE.
2
A short overview is given in the following.
3
The user has the following standard high-level security goals related to the assets:
4
 SG1 maintain the integrity of User Data and of the Security IC Embedded Software
5
 SG2 maintain the confidentiality of User Data and of the Security IC Embedded Software
6
 SG3 maintain the correct operation of the security services provided by the TOE for the Security IC
7
Embedded Software
8
 SG4 provision of random numbers.
9
5.1 Security objectives for the TOE
10
The security objectives of the TOE are defined and described in PP [1] section 4.1.
11
12
Table 10 Objectives for the TOE according to PP [1]
13
O.Phys-Manipulation Protection against Physical Manipulation
O.Phys-Probing Protection against Physical Probing
O.Malfunction Protection against Malfunction
O.Leak-Inherent Protection against Inherent Information Leakage
O.Leak-Forced Protection against Forced Information Leakage
O.Abuse-Func Protection against Abuse of Functionality
O.Identification TOE Identification
O.RND Random Numbers
14
The TOE provides “Additional Specific Security Functionality (O.Add-Functions)” as specified below.
15
O.Add-Functions : Additional Specific Security Functionality
16
The TOE must optionally provide the following specific security functionality to the Smartcard Embedded
17
Software:
18
 Advanced Encryption Standard (AES)
19
 Triple Data Encryption Standard (3DES)
20
 Rivest-Shamir-Adleman (RSA)
21
 Elliptic Curve Cryptography (EC)
22
The hardware of this TOE can be delivered with the following configuration options:
23
 both crypto co-processors accessible
24
 with a blocked SCP
25
 with a blocked Crypto2304T
26
 both crypto co-processors blocked
27
In case the SCP is blocked, no AES and 3DES computations supported by hardware are possible. In the
28
case the Crypto2304T is blocked, no RSA and EC computations supported by hardware are possible.
29
The optional security relevant software part of the TOE consists of the following optional libraries:
30
 RSA Cryptographic Library
31
 EC Cryptographic Library
32
30
Security Target Lite
M5072
Public
 Symmetric Cryptographic Library (SCL)
1
2
The TOE shall provide “Area based Memory Access Control (O.Mem-Access)” as specified below.
3
O.Mem-Access: Area based Memory Access Control
4
The TOE must provide the Smartcard Embedded Software with the capability to define restricted access
5
memory areas. The TOE must then enforce the partitioning of such memory areas so that access of
6
software to memory areas and privilege levels is controlled as required, for example, in a multi-
7
application environment.
8
Table 11 Additional objectives due to TOE specific functions and augmentations
9
O.Add-Functions Additional specific security functionality
O.Mem-Access Area based Memory Access Control
5.2 Security Objectives for the development and operational
10
Environment
11
The security objectives for the security IC embedded software development environment and the
12
operational environment is defined in PP [1] section 4.2 and 4.3. The table below lists the security
13
objectives.
14
Table 12 Security objectives for the environment according to PP [1]
15
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)”
16
Regarding the cryptographic services this objective of the environment has to be clarified. The TOE
17
supports cipher schemes as additional specific security functionality. If required the Smartcard
18
Embedded Software shall use these cryptographic services of the TOE and their interface as specified.
19
When key-dependent functions implemented in the Smartcard Embedded Software are just being
20
executed, the Smartcard Embedded Software must provide protection against disclosure of confidential
21
data (User Data) stored and/or processed in the TOE by using the methods described under “Inherent
22
Information Leakage (T.Leak-Inherent)” and “Forced Information Leakage (T.Leak-Forced)“.
23
The objectives of the environment regarding the memory, software and firmware protection and the SFR
24
and peripheral-access-rights-handling have to be clarified. For the separation of different applications the
25
Smartcard Embedded Software (Operating System) may implement a memory management scheme
26
based upon security functions of the TOE.
27
5.2.2 Clarification of “Treatment of User Data (OE.Resp-Appl)”
28
Regarding the cryptographic services this objective of the environment has to be clarified. By definition
29
cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded Software shall
30
treat these data appropriately, use only proper secret keys (chosen from a large key space) as input for
31
the cryptographic function of the TOE and use keys and functions appropriately in order to ensure the
32
strength of cryptographic operation.
33
This means that keys are treated as confidential as soon as they are generated. The keys must be
34
unique with a very high probability, as well as cryptographically strong. For example, it must be ensured
35
that it is beyond practicality to derive the private key from a public key if asymmetric algorithms are used.
36
31
Security Target Lite
M5072
Public
If keys are imported into the TOE and/or derived from other keys, quality and confidentiality must be
1
maintained. This implies that appropriate key management has to be realized in the environment.
2
Regarding the memory, software and firmware protection and the SFR and peripheral access rights
3
handling these objectives of the environment has to be clarified. The treatment of User Data is also
4
required when a multi-application operating system is implemented as part of the Smartcard Embedded
5
Software on the TOE. In this case the multi-application operating system should not disclose security
6
relevant user data of one application to another application when it is processed or stored on the TOE.
7
5.2.3 Clarification of “Protection during Composite product
8
manufacturing (OE.Process-Sec-IC)”
9
The protection during packaging, finishing and personalization includes also the personalization process
10
(Flash Loader software) and the personalization data (TOE software components) during Phase 4,
11
Phase 5 and Phase 6.
12
5.3 Security Objectives Rationale
13
The security objectives rationale of the TOE are defined and described in PP [1] section 4.4. For
14
organizational security policy P.Add-Functions, OE.Plat-Appl and OE.Resp-Appl the rationale is given in
15
the following description.
16
Table 13 Security Objective Rationale
17
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
18
The justification related to the security objective “Additional Specific Security Functionality
19
(O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the
20
same specific security functionality as required by P.Add-Functions; the organizational security policy is
21
covered by the objective.
22
Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
23
Manipulation and O.Leak-Forced define how to implement the specific security functionality required by
24
P.Add-Functions. (Note that these objectives support that the specific security functionality is provided in
25
a secure way as expected from P.Add-Functions.) Especially O.Leak-Inherent and O.Leak-Forced refer
26
to the protection of confidential data (User Data or TSF data) in general. User Data are also processed
27
by the specific security functionality required by P.Add-Functions.
28
Compared to PP [1] clarification has been made for the security objective “Usage of Hardware Platform
29
(OE.Plat-Appl)”: If required the Smartcard Embedded Software shall use these cryptographic services of
30
the TOE and their interface as specified. In addition, the Smartcard Embedded Software must implement
31
functions which perform operations on keys (if any) in such a manner that they do not disclose
32
information about confidential data. The non disclosure due to leakage A.Key-Function attacks is
33
included in this objective OE.Plat-Appl. This addition ensures that the assumption A.Plat-Appl is still
34
covered by the objective OE.Plat-Appl although additional functions are being supported according to
35
O.Add-Functions.
36
Compared to the PP [1] a clarification has been made for the security objective “Treatment of User Data
37
(OE.Resp-Appl)”: By definition cipher or plain text data and cryptographic keys are User Data. So, the
38
Smartcard Embedded Software will protect such data if required and use keys and functions
39
32
Security Target Lite
M5072
Public
appropriately in order to ensure the strength of cryptographic operation. Quality and confidentiality must
1
be maintained for keys that are imported and/or derived from other keys. This implies that appropriate
2
key management has to be realized in the environment. That is expressed by the assumption A.Key—
3
Function which is covered from OE.Resp–Appl. These measures make sure that the assumption
4
A.Resp-Appl is still covered by the security objective OE.Resp-Appl although additional functions are
5
being supported according to P.Add-Functions.
6
Compared to the PP [1] an enhancement regarding memory area protection has been established. The
7
clear definition of privilege levels for operated software establishes the clear separation of different
8
restricted memory areas for running the firmware, downloading and/or running the operating system and
9
to establish a clear separation between different applications. Nevertheless, it is also possible to define a
10
shared memory section where separated applications may exchange defined data. The privilege levels
11
clearly define by using a hierarchical model the access right from one level to the other. These measures
12
ensure that the threat T.Mem-Access is clearly covered by the security objective O.Mem-Access.
13
The justification of the additional policy and the additional assumption show that they do not contradict to
14
the rationale already given in the Protection Profile for the assumptions, policy and threats defined there.
15
33
Security Target Lite
M5072
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. The
7
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 TOE
10
shall support that particular security functions or mechanisms are tested in the operational phase (Phase
11
7). The tests can be initiated by the Smartcard Embedded Software and/or by the TOE or is done
12
automatically and continuously.
13
Part 2 of the Common Criteria provides the security functional component “TSF testing (FPT_TST.1)”.
14
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 functional
16
component FPT_TST.1 does not mandate to explicitly specify the security functions being tested. In
17
addition, FPT_TST.1 requires verification of the integrity of TSF data and of the stored TSF executable
18
code which might violate the security policy. Therefore, the functional component”Subset TOE security
19
testing (FPT_TST.2)” of the family TSF self test has been newly created. This component allows that
20
particular parts of the security mechanisms and functions provided by the TOE are tested.
21
6.2 Definition of FPT_TST.2
22
The functional component “Subset TOE security testing (FPT_TST.2)” has been newly created
23
(Common Criteria Part 2 extended). This component allows that particular parts of the security
24
mechanisms and functions provided by the TOE can be tested after TOE Delivery or are tested
25
automatically and continuously during normal operation transparent for the user.
26
This security functional component is used instead of the functional component FPT_TST.1 from
27
Common Criteria Part 2. For the user it is important to know which security functions or mechanisms can
28
be tested. The functional component FPT_TST.1 does not mandate to explicitly specify the security
29
functions being tested. In addition, FPT_TST.1 requires verifying the integrity of TSF data and stored
30
TSF executable code which might violate the security policy.
31
The functional component “Subset TOE testing (FPT_TST.2)” is specified as follows (Common Criteria
32
Part 2 extended).
33
34
34
Security Target Lite
M5072
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 particular
6
security functions or mechanisms. These tests may be performed at start-up, periodically,
7
at the request of the authorized user, or when other conditions are met. It also provides
8
the ability to verify the integrity of TSF data and executable code.
9
Management: FPT_TST.2
10
The following actions could be considered for the management functions in FMT:
11
management of the conditions under which subset TSF self testing occurs, such as
12
during initial start-up, regular interval or under specified conditionsmanagement of the
13
time of the interval appropriate.
14
Audit: FPT_TST.2
15
There are no auditable events foreseen.
16
FPT_TST.2 Subset TOE testing
17
Hierarchical to: No other components.
18
Dependencies: No dependencies
19
FPT_TST.2.1 The TSF shall run a suite of self tests [selection: during initial start-up, periodically during
20
normal operation, at the request of the authorized user, and/or at the conditions
21
[assignment: conditions under which self test should occur]] to demonstrate the correct
22
operation of [assignment: functions and/or mechanisms].
23
24
6.4 Family “Generation of Random Numbers (FCS_RNG)”
25
The component “Generation of Random Numbers (FCS_RNG.1)” has to be newly created according the
26
new version of the “Anwendungshinweise und Interpretationen zum Schema (AIS)” [15]. This security
27
functional component is used instead of the functional component FCS_RNG.1 defined in the protection
28
profile [1].
29
The component “Generation of Random Numbers (FCS_RNG.1)” is specified as follows (Common
30
Criteria Part 2 extended).
31
32
6.5 Definition of FCS_RNG.1
33
This section describes the functional requirements for the generation of random numbers, which may be
34
used as secrets for cryptographic purposes or authentication. The IT security functional requirements for
35
the TOE are defined in an additional family (FCS_RNG) of the Class FCS (Cryptographic support).
36
37
35
Security Target Lite
M5072
Public
FCS_RNG Generation of random numbers
1
Family Behaviour
2
This family defines quality requirements for the generation of random numbers that are intended
3
to be used for cryptographic purposes.
4
5
Component levelling:
6
FCS_RNG: Generation of random numbers
TSF self test
1
7
8
FCS_RNG.1 Generation of random numbers, requires that the random number generator implements
9
defined security capabilities and that the random numbers meet a defined quality metric.
10
Management: FCS_RNG.1
11
There are no management activities foreseen.
12
Audit: FCS_RNG.1
13
There are no actions defined to be auditable.
14
15
FCS_RNG.1 Random number generation
16
Hierarchical to: No other components.
17
Dependencies: No dependencies.
18
FCS_RNG.1.1: The TSF shall provide a [selection: physical, non-physical true, deterministic,
19
hybrid physical, hybrid deterministic] random number generator that imple-
20
ments: [assignment: list of security capabilities].
21
FCS_RNG.1.2: The TSF shall provide random numbers that meet [assignment: a defined
22
quality metric].
23
Note: The functional requirement FCS_RNG.1 is a refinement of the FCS_RNG.1 defined in the
24
Protection Profile [1] according to “Anwendungshinweise und Interpretationen zum Schema (AIS)”
25
[15].
26
27
36
Security Target Lite
M5072
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] section
4
6.1 and in the following description.
5
The Table 14 provides an overview of the functional security requirements of the TOE, defined in the in
6
PP [1] section 6.1. In the last column it is marked if the requirement is refined. The refinements are also
7
valid for this ST.
8
Table 14 Security functional requirements defined in PP [1]
9
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
10
The Table 15 provides an overview about the augmented security functional requirements, which are
11
added additional to the TOE and defined in this ST. All requirements are taken from Common Criteria
12
Part 2 [3], with the exception of the requirement FPT_TST.2 and FCS_RNG.1, which are defined in this
13
ST completely.
14
15
Table 15 Augmented security functional requirements
16
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
17
37
Security Target Lite
M5072
Public
All assignments and selections of the security functional requirements of the TOE are done in PP [1] and
1
in the following description.
2
The above marked extended components FMT_LIM.1 and FMT_LIM.2 are introduced in PP [1] to define
3
the IT security functional requirements of the TOE as an additional family (FMT_LIM) of the Class FMT
4
(Security Management). This family describes the functional requirements for the Test Features of the
5
TOE. The new functional requirements were defined in the class FMT because this class addresses the
6
management of functions of the TSF.
7
The additional component FAU.SAS is introduced to define the security functional requirements of the
8
TOE of the Class FAU (Security Audit). This family describes the functional requirements for the storage
9
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 given
11
as the correct operation of the security functions is essential. The TOE provides mechanisms to cover
12
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 implements:
24
PTG.2.1 A: total failure test detects a total failure of entropy source
25
immediately when the RNG has started. When a total failure is detected, no
26
random numbers will be output.
27
PTG.2.2 : If a total failure of the entropy source occurs while the RNG is
28
being operated, the RNG prevents the output of any internal random number that
29
depends on some raw random numbers that have been generated after the total
30
failure of the entropy source.
31
32
PTG.2.3: The online test shall detect non-tolerable statistical defects of the
33
rawrandom number sequence (i) immediately when the RNG has started, and (ii)
34
while the RNG is being operated. The TSF must not output any random numbers
35
before the power-up online test has finished successfully or when a defect has
36
been detected.
37
PTG.2.4 :The online test procedure shall be effective to detect non-tolerable
38
weaknesses of the random numbers soon.
39
40
PTG.2.5 :The online test procedure checks the quality of the raw random num ber
41
sequence. It is triggered continuously. The online test is suitable for detecting non-
42
38
Security Target Lite
M5072
Public
tolerable statistical defects of the statistical properties of the raw random numbers
1
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 0.997.
7
Note: The functional requirement FCS_RNG.1/HW is a refinement of the FCS_RNG.1 defined in
8
chapter 6.5
9
10
11
7.1.1.2 FAU_SAS
12
To define the security functional requirements of the TOE an additional family (FAU_SAS) of the Class
13
FAU (Security Audit) is defined here. This family describes the functional requirements for the storage of
14
audit data. It has a more general approach than FAU_GEN, because it does not necessarily require the
15
data to be generated by the TOE itself and because it does not give specific details of the content of the
16
audit records.
17
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common Criteria
18
Part 2 extended).
19
20
FAU_SAS.1 Audit Storage
21
Hierarchical to: No other components
22
Dependencies: No dependencies.
23
FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery with the capability to
24
store the Initialization Data and/or Pre-personalization Data and/or supplements of
25
the Security IC Embedded Software in the not changeable configuration page area
26
and non-volatile memory.
27
7.1.2 Subset of TOE testing
28
The security is strongly dependent on the correct operation of the security functions. Therefore, the TOE
29
shall support that particular security functions or mechanisms are tested in the operational phase (Phase
30
7). The tests can be initiated by the Smartcard Embedded Software and/or by the TOE.
31
The TOE shall meet the requirement “Subset TOE testing (FPT_TST.2)” as specified below (Common
32
Criteria Part 2 extended).
33
34
FPT_TST.2 Subset TOE testing
35
Hierarchical to: No other components
36
Dependencies: No dependencies
37
FPT_TST.2.1 The TSF shall run a suite of self tests at the request of the authorized user to
38
demonstrate the correct operation of the alarm lines and/or the environmental
39
sensor mechanisms
40
39
Security Target Lite
M5072
Public
Note: For details about the sensor mechanisms, please see[ST].
1
7.2 Memory access control
2
Usage of multiple applications in one Smartcard often requires code and data separation in order to
3
prevent that one application can access code and/or data of another application. For this reason the
4
TOE provides Area based Memory Access Control. The underlying Memory Protection Unit (MPU) is
5
documented in section 4 of the [7].
6
The security service being provided is described in the Security Function Policy (SFP) Memory Access
7
Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)” requires
8
that this policy is in place and defines the scope were it applies. The security functional requirement
9
“Security attribute based access control (FDP_ACF.1)” defines security attribute usage and
10
characteristics of policies. It describes the rules for the function that implements the Security Function
11
Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or not is taken
12
based upon attributes allocated to the software. The Smartcard Embedded Software defines the
13
attributes and memory areas. The corresponding permission control information is evaluated “on-the-fly”
14
by the hardware so that access is granted/effective or denied/inoperable.
15
The security functional requirement “Static attribute initialisation (FMT_MSA.3)” ensures that the
16
default values of security attributes are appropriately either permissive or restrictive in nature. Alternative
17
values can be specified by any subject provided that the Memory Access Control Policy allows that.
18
This is described by the security functional requirement “Management of security attributes
19
(FMT_MSA.1)”. The attributes are determined during TOE manufacturing (FMT_MSA.3) or set at run-
20
time (FMT_MSA.1).
21
From TOE’s point of view the different roles in the Smartcard Embedded Software can be distinguished
22
according to the memory based access control. However the definition of the roles belongs to the user
23
software.
24
The following Security Function Policy (SFP) Memory Access Control Policy is defined for the
25
requirement “Security attribute based access control (FDP_ACF.1)”:
26
27
28
7.2.1 Memory Access Control Policy
29
The TOE shall support the standard ARMv7 Protected Memory System Architecture model.
30
The MPU provides full support for:
31
 Protection regions.
32
 Overlapping protection regions, with ascending region priority:
33
− Region 7 = highest priority.
34
− Region 0 = lowest priority.
35
 Access permissions.
36
 MPU mismatches and permission violations invoke the programmable-priority MemManage fault
37
handler.
38
The MPU can be used to:
39
 Enforce privilege rules, preventing user applications from corrupting operating system data.
40
 Separate processes, blocking the active task from accessing other tasks’ data.
41
 Enforce access rules, allowing memory regions to be defined as read-only or detecting unexpected
42
memory accesses.
43
44
40
Security Target Lite
M5072
Public
Subjects, Objects and Operations of the policy
1
 Subjects: privilege or non-privilege level of the ARM processor
2
 Objects: memory/code addresses
3
 Operations: Read a/o write a/o execute access
4
5
Attributes of the policy:
6
 MPU enable/disable bit.
7
 8 regions with the following attributes
8
− A unique priority
9
− The enable bit
10
− the start address and size
11
− an access matrix which defines if an Operation of a Subject to an Object lying in the region is
12
allowed or denied
13
 The default region with the following security attribute:
14
− A bit which defines if an Operation for the Subject (privilege level) is allowed or if no Operation is
15
allowed for any Subject.
16
17
Roles of the policy:
18
The roles correspond 1-1 to the subjects.
19
20
Properties of the policy:
21
 If an address is contained in multiple enabled regions, then the region with the highest priority defines
22
the access rights.
23
 If an address is contained in no region then the default region defines the access rights.
24
 The region defining the access rights checks in the access matrix if the Subject has access to the
25
Object with respect to the desired Operation. In case the access is denied the MPU throws an access
26
violation exception.
27
28
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below.
29
30
FDP_ACC.1 Subset access control
31
Hierarchical to: No other components.
32
Dependencies: FDP_ACF.1 Security attribute based access control
33
FDP_ACC.1.1 The TSF shall enforce the Memory Access Control Policy on all Subjects, all
34
Objects and all Operations.
35
36
37
The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as specified
38
below.
39
40
FDP_ACF.1 Security attribute based access control
41
Hierarchical to: No other components.
42
Dependencies: FDP_ACC.1 Subset access control
43
FMT_MSA.3 Static attribute initialization
44
FDP_ACF.1.1 The TSF shall enforce the Memory Access Control Policy to objects based on the
45
following:
46
As specified in the definition of the memory access control policy .
47
48
41
Security Target Lite
M5072
Public
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
1
controlled subjects and controlled objects is allowed:
2
As specified in the definition of the memory access control policy.
3
4
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the
5
following additional rules: none.
6
7
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
8
additional rules: none.
9
10
11
The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below.
12
13
FMT_MSA.3 Static attribute initialization
14
15
Hierarchical to: No other components.
16
17
Dependencies: FMT_MSA.1 Management of security attributes
18
FMT_SMR.1 security roles
19
20
FMT_MSA.3.1 The TSF shall enforce the Memory Access Control Policy to provide restrictive1
21
default values for security attributes that are used to enforce the SFP.
22
23
FMT_MSA.3.2 The TSF shall allow the privilege level to specify alternative initial values to
24
override the default values when an object or information is created.
25
26
27
The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified
28
below:
29
30
FMT_MSA.1 Management of security attributes
31
32
Hierarchical to: No other components.
33
34
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset
35
information flow control]
36
FMT_SMF.1 Specification of management functions
37
FMT_SMR.1 Security roles
38
39
FMT_MSA.1.1 The TSF shall enforce the Memory Access Control Policy to restrict the ability to
40
modify any security attributes2
to the privilege level.
41
42
The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as specified
43
below:
44
45
FMT_SMF.1 Specification of management functions
46
47
Hierarchical to: No other components
48
49
Dependencies: No dependencies
50
1
The static definition of the access rules is documented in [7]
2
editorially refined
42
Security Target Lite
M5072
Public
1
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
2
functions: The privilege level shall be able to access the configuration registers of
3
the MPU.
4
5
43
Security Target Lite
M5072
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 accordance
3
with a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and
4
cryptographic key sizes can be based on an assigned standard; dependencies are discussed in Section
5
7.5.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
12
Preface regarding Security Level related to Cryptography:
13
The strength of the cryptographic algorithms was not rated in the course of the product certification (see
14
BSIG Section 9, Para.4, Clause 2). But Cryptographic Functionalities with a security level of lower
15
than 100 bits can no longer be regarded as secure without considering the application context.
16
Therefore for these functionalities it shall be checked whether the related crypto operations are
17
appropriate for the intended system. Some further hints and guidelines can be derived from the
18
'Technische Richtlinie BSI TR-02102', www.bsi.bund.de.
19
Any Cryptographic Functionality that is marked in column 'Security Level above 100 Bits' of the following
20
table with 'no' achieves a security level of lower than 100 Bits (in general context).
21
22
Table 16 TOE cryptographic functionality
23
Purpose Cryptographic
Mechanism
Standard
of
Implemen-
tation
Key Size in Bits Security
Level above
100 Bits
Key
Agreement
ECDH [X963] Key sizes corresponding to the
used elliptic curves P-192, P-
224,K-163,K-233 [DSS] and
brainpoolP{160, 192,224}r1,
brainpoolP{160, 192,224}t1 [ECC]
No
ECDH [X963] Key sizes corresponding to the
used elliptic curves P-{256, 384,
521}, K-409, B-{283, 409} [DSS],
brainpoolP{256,320,384,512}r1,
brainpoolP{256,320,384,512}t1
[ECC]
Yes
Cryptographi
c Primitive
TDES in CBC
mode
[N867]
[N38A]
|k| = 112 No
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.
44
Security Target Lite
M5072
Public
TDES in ECB
mode
[N867]
[N38A]
|k| = 112 No
TDES in CBC
mode
[N867]
[N38A]
|k| = 168 Yes
TDES in ECB
mode
[N867]
[N38A]
|k| = 168 No
TDES in CFB
mode
[N867]
[N38A]
|k| = 112 No
TDES in CFB
mode
[N867]
[N38A]
|k| = 168 Yes
TDES in CTR
mode
[N867]
[N38A]
|k| = 112 No
TDES in CTR
mode
[N867]
[N38A]
|k| = 168 Yes
AES in CBC
mode
[N197]
[N38A]
|k| = 128, 192, 256 Yes
AES in ECB
mode
[N197]
[N38A]
|k| = 128, 192, 256 No
AES in CTR
mode
[N197]
[N38A]
|k| = 128, 192, 256 Yes
AES in CFB
mode
[N197]
[N38A]
|k| = 128, 192, 256 Yes
RSA encryption
/ decryption /
signature
generation /
verification (only
modular
exponentiation
part)
[PKCS] Modulus length =
1976 - 4096
Yes
RSA encryption
/ decryption /
signature
generation /
verification (only
modular
exponentiation
part)
[PKCS] Modulus length =
1024 - 1975
No
ECDSA
signature
generation /
verification
[X962] Key sizes corresponding to the
used elliptic curves P-192, K-163
[DSS] and brainpoolP{160,
192}r1, brainpoolP{160, 192}t1
[ECC]
No
ECDSA
signature
generation /
verification
[X962] Key sizes corresponding to the
used elliptic curves P-{224, 256,
384, 521}, K-{233, 409}, B-{233,
283, 409} [DSS],
brainpoolP{224,256,320,384,512}
r1,
brainpoolP{224,256,320,384,512}
t1 [ECC])
Yes
45
Security Target Lite
M5072
Public
Physical True
RNG PTG.2
[6] N/A N/A
1
General statements with regard to Elliptic Curves:
2
The EC library is delivered as object code and in this way integrated in the user software. The
3
certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key lengths of 160,
4
163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits, due to national AIS32 regulations by the
5
BSI. Note that there are numerous other curve types, being also secure in terms of side channel attacks
6
on this TOE, which the user can optionally add in the composition certification process.
7
8
7.3.1 Triple-DES Operation
9
The DES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as
10
specified below.
11
FCS_COP.1/DES Cryptographic operation
12
Hierarchical to: No other components.
13
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
14
FDP_ITC.2 Import of user data with security attributes, or
15
FCS_CKM.1 Cryptographic key management]
16
FCS_CKM.4 Cryptographic key destruction
17
FCS_COP.1.1/DES The TSF shall perform encryption and decryption in accordance with a specified
18
cryptographic algorithm Triple Data Encryption Standard (3DES) in Electronic
19
Codebook mode (ECB), in Cipher Block Chaining mode (CBC) and with
20
cryptographic key sizes of 2 x 56 bit or 3 x 56 bit, that meet the following
21
standards:
22
[N867], [N38A]
23
Note: This SFR refers to the direct hardware interface of the DES SCP.
24
Note: The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked,
25
no 3DES computation supported by hardware is possible and this SFR is not applicable.
26
27
FCS_COP.1/DES_SCL_v2 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 management]
34
FCS_CKM.4 Cryptographic key destruction
35
36
FCS_COP.1.1/DES_SCL_v2The TSF shall perform encryption and decryption in accordance with a
37
specified cryptographic algorithm Triple Data Encryption Standard (3DES) in
38
Electronic Codebook mode (ECB),the Cipher Block Chaining mode (CBC), Cipher
39
Feedback mode (CFB), Counter mode (CTR) mode and with cryptographic key
40
sizes of 2 x 56 bit or 3 x 56 bit, that meet the following standards:
41
[N867], [N38A]
42
43
46
Security Target Lite
M5072
Public
Note: This SFR refers to the DES interface provided by the SCL v2.02.10.
1
Note: This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked,
2
no 3DES computation supported by hardware is possible and this SFR is not applicable.
3
Note: The TOE can be delivered with the optional SCL v2.02.10. If the optional SCL v2.02.10. is
4
not available then this SFR is not applicable.
5
6
7.3.2 AES Operation
7
The AES Operation of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as
8
specified below.
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 specified
16
cryptographic algorithm Advanced Encryption Standard (AES) in Electronic
17
Codebook mode (ECB) and in the Cipher Block Chaining mode (CBC) and
18
cryptographic key sizes of 128 bit or 192 bit or 256 bit that meet the following
19
standards:
20
[N197], [N38A]
21
Note: This SFR refers to the direct hardware SCP interface of the AES.
22
Note: The TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked,
23
no AES computation supported by hardware is possible and this SFR is not applicable.
24
25
FCS_COP.1/AES_SCL_v2 Cryptographic operation
26
27
Hierarchical to: No other components.
28
29
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
30
FDP_ITC.2 Import of user data with security attributes, or
31
FCS_CKM.1 Cryptographic key generation]
32
FCS_CKM.4 Cryptographic key destruction
33
34
FCS_COP.1.1/AES_SCL_v2The TSF shall perform encryption and decryption in accordance with a
35
specified cryptographic algorithm Advanced Encryption Standard (AES) in
36
Electronic Codebook mode (ECB),the Cipher Block Chaining mode (CBC), Cipher
37
Feedback mode (CFB) , Counter (CTR) mode mode and cryptographic key sizes
38
of 128 bit or 192 bit or 256 bit that meet the following standards:
39
[N197], [N38A]
40
Note: This SFR refers to the DES interface provided by the SCL v2.02.010.
41
47
Security Target Lite
M5072
Public
Note: This TOE can be delivered with the SCP accessible or blocked. In case the SCP is blocked,
1
no AES computation supported by hardware is possible and this SFR is not applicable.
2
Note: The TOE can be delivered with the optional SCL SCL v2.02.010. If the optional SCL SCL
3
v2.02.010 is not available then this SFR is not applicable.
4
5
6
7.3.3 Rivest-Shamir-Adleman (RSA) operation
7
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation
8
(FCS_COP.1)” as specified below.
9
10
FCS_COP.1/RSA Cryptographic operation
11
12
Hierarchical to: No other components.
13
14
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
15
16
FDP_ITC.2 Import of user data with security attributes, or
17
FCS_CKM.1 Cryptographic key generation]
18
FCS_CKM.4 Cryptographic key destruction
19
20
FCS_COP.1.1/RSA The TSF shall perform encryption, decryption, signature generation and
21
verification in accordance with a specified cryptographic algorithm Rivest-Shamir-
22
Adleman (RSA) and cryptographic key sizes of 1024 - 4096 bit that meet the
23
following standards:
24
25
Encryption:
26
According to section 5.1.1 RSAEP in PKCS v2.1 RFC3447,
27
without 5.1.1.1.
28
29
Decryption (with or without CRT):
30
According to section 5.1.2 RSADP in PKCS v2.1 RFC3447
31
for u = 2, i.e., without any (r_i, d_i, t_i), i >2, therefore without 5.1.2.2.b (ii)&(v),
32
without 5.1.2.1. 5.1.2.2.a, only supported up to n < 2
2048
.
33
34
Signature Generation (with or without CRT): According to section 5.2.1 RSASP1 in
35
PKCS v2.1 RFC3447
36
for u = 2, i.e., without any (r_i, d_i, t_i), i >2,
37
therefore without 5.2.1.2.b (ii)&(v), without 5.2.1.1.
38
5.2.1.2.a, only supported up to n < 2
2048
.
39
40
Signature Verification:
41
According to section 5.2.2 RSAVP1 in PKCS v2.1 RFC3447,
42
without 5.2.2.1.
43
44
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
45
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this SFR
46
is not applicable.
47
Note: The TOE can be delivered with the optional RSA library v1.03.006 and/or v2.06.003. Either
48
optional RSA library contains the RSA algorithms stated above. Each optional RSA library needs
49
48
Security Target Lite
M5072
Public
an accessible Crypto2304T. If neither optional RSA library is available then this SFR is not
1
applicable.
2
3
4
7.3.4 Rivest-Shamir-Adleman (RSA) key generation
5
The key generation for the RSA shall meet the requirement “Cryptographic key generation
6
(FCS_CKM.1)” as specified below.
7
8
FCS_CKM.1/RSA Cryptographic key generation
9
10
Hierarchical to: No other components.
11
12
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
13
FCS_COP.1 Cryptographic operation]
14
FCS_CKM.4 Cryptographic key destruction
15
16
FCS_CKM.1.1/RSA The TSF shall generate cryptographic keys in accordance with a specified
17
cryptographic algorithm rsagen1 (PKCS v2.1 RFC3447) and specified
18
cryptographic key sizes of 1024 - 4096 bits that meet the following standard:
19
According to section 3.2(2) in PKCS v2.1 RFC3447,
20
for u=2, i.e., without any (r_i, d_i, t_i), i > 2.
21
For p x q < 22048
additionally according to section 3.2(1).
22
23
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
24
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this SFR
25
is not applicable.
26
Note: The optional RSA library v2.06.003 contains the RSA algorithms stated above. The optional
27
RSA library needs an accessible Crypto2304T. If the optional RSA library v2.06.003 is not delivered
28
then this SFR is not applicable.
29
30
7.3.5 Elliptic Curve DSA (ECDSA) operation
31
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic operation
32
(FCS_COP.1)” as specified below.
33
34
FCS_COP.1/ECDSA Cryptographic operation
35
Hierarchical to: No other components.
36
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
37
38
FDP_ITC.2 Import of user data with security attributes, or
39
FCS_CKM.1 Cryptographic key generation]
40
FCS_CKM.4 Cryptographic key destruction
41
FCS_COP.1.1/ECDSA The TSF shall perform signature generation and signature verification in
42
accordance with a specified cryptographic algorithm ECDSA and cryptographic
43
key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that
44
meet the following standard:
45
49
Security Target Lite
M5072
Public
Signature Generation:
1
1. According to section 7.3 in ANSI X9.62 – 2005
2
Not implemented is step d) and e) thereof.
3
The output of step e) has to be provided as input to our function by
4
the caller.
5
Deviation of step c) and f):
6
The jumps to step a) were substituted by a return of
7
the function with an error code, the jumps are emulated by another
8
call to our function.
9
10
2. According to sections 6.2 (6.2.2. + 6.2.3) in ISO/IEC 15946-2:2002
11
Not implemented is section 6.2.1:
12
The output of 5.4.2 has to be provided by the caller as input to the
13
function.
14
15
Signature Verification:
16
1. According to section 7.4.1 in ANSI X9.62–2005
17
Not implemented is step b) and c) thereof.
18
The output of step c) has to be provided as input to our function by
19
the caller.
20
Deviation of step d):
21
Beside noted calculation, our algorithm adds a random multiple of
22
BasepointerOrder n to the calculated values u1 and u2.
23
24
2. According to sections 6.4 (6.4.1. + 6.4.3 + 6.4.4) in ISO/IEC
25
15946-2:2002
26
Not implemented is section 6.4.2:
27
The output of 5.4.2 has to be provided by the caller as input to the
28
function.
29
30
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
31
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR
32
is not applicable.
33
Note: The TOE can be delivered with the optional ECC library v1.03.006 and/or v2.06.003. Either
34
optional ECC library contains the ECC algorithms stated above. Each optional ECC library needs
35
an accessible Crypto2304T. If neither optional ECC library is available then this SFR is not
36
applicable.
37
38
39
7.3.6 Elliptic Curve (EC) key generation
40
The key generation for the EC shall meet the requirement “Cryptographic key generation (FCS_CKM.1)”
41
FCS_CKM.1/EC Cryptographic key generation
42
43
Hierarchical to: No other components.
44
Dependencies: FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic
45
operation]
46
FCS_CKM.4 Cryptographic key destruction
47
50
Security Target Lite
M5072
Public
1
FCS_CKM.1.1/EC The TSF shall generate cryptographic keys in accordance with a specified
2
cryptographic key generation algorithm Elliptic Curve EC specified in ANSI X9.62-
3
2005 and ISO/IEC 15946-1:2002 and specified cryptographic key sizes 160, 163,
4
192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the following
5
standard:
6
7
ECDSA Key Generation:
8
1. According to the appendix A4.3 in ANSI X9.62-2005
9
the cofactor h is not supported.
10
2. According to section 6.1 (not 6.1.1) in ISO/IEC 15946-1:2002
11
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
12
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR
13
is not applicable.
14
Note: The TOE can be delivered with the optional ECC library v1.03.006 and/or v2.06.003. Either
15
optional ECC library contains the ECC algorithms stated above. Each optional ECC library needs
16
an accessible Crypto2304T. If neither optional ECC library is available then this SFR is not
17
applicable.
18
19
20
7.3.7 Elliptic Curve Diffie-Hellman (ECDH) key agreement
21
The Modular Arithmetic Operation of the TOE shall meet the requirement “Cryptographic
22
operation(FCS_COP.1)” as specified below.
23
24
FCS_COP.1/ECDH Cryptographic operation
25
26
Hierarchical to: No other components.
27
28
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
29
30
FDP_ITC.2 Import of user data with security attributes, or
31
FCS_CKM.1 Cryptographic key generation]
32
FCS_CKM.4 Cryptographic key destruction
33
34
FCS_COP.1.1/ECDH The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance
35
with a specified cryptographic algorithm ECDH and cryptographic key sizes of 160,
36
163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the
37
following standard:
38
1. According to section 5.4.1 in ANSI X9.63 – 2001: Unlike section 5.4.1.3 our,
39
implementation not only returns the x-coordinate of the shared secret, but
40
rather the x-coordinate and y-coordinate.
41
2. According to sections 8.4.2.1, 8.4.2.2, 8.4.2.3, and 8.4.2.4 in ISO/IEC 15946-
42
3:2002: The function enables the operations described in the four sections.
43
44
Note: The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with
45
key lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits. Other types of
46
elliptic curves can be added by the user during a composite certification process.
47
51
Security Target Lite
M5072
Public
Note: For easy integration of EC functions into the user’s operating system and/or application, the
1
library contains single cryptographic functions respectively primitives which are compliant to the
2
standard. The primitives are referenced above. Therefore, the library supports the user to develop
3
an application representing the standard if required.
4
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
5
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this SFR
6
is not applicable.
7
Note: The TOE can be delivered with the optional ECC library v1.03.006 and/or v2.06.003. Either
8
optional ECC library contains the ECC algorithms stated above. Each optional ECC library needs
9
an accessible Crypto2304T. If neither optional ECC library is available then this SFR is not
10
applicable.
11
12
13
7.3.8 Data Integrity
14
The TOE shall meet the requirement “Stored data integrity monitoring (FDP_SDI.1)” as specified below:
15
16
FDP_SDI.1 Stored data integrity monitoring
17
18
Hierarchical to: No other components
19
20
Dependencies: No dependencies
21
22
FDP_SDI.1.1 The TSF shall monitor user data stored in containers controlled by the TSF for
23
inconsistencies between stored data and corresponding EDC on all objects, based
24
on the following attributes: EDC value for RAM and ROM and ECC value for the
25
SOLID FLASH™ NVM and verification of stored data in the SOLID FLASH™ NVM.
26
27
The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)” as
28
specified below:
29
30
FDP_SDI.2 Stored data integrity monitoring and action
31
32
Hierarchical to: FDP_SDI.1 stored data integrity monitoring
33
34
Dependencies: No dependencies
35
36
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
37
data integrity and one- and/or more-bit-errors on all objects, based on the following
38
attributes: corresponding EDC value for RAM and ROM and error correction ECC
39
for the SOLID FLASH™ NVM.
40
41
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall correct 1 bit errors in the
42
SOLID FLASH™ NVM automatically and inform the user about more bit errors.
43
44
45
52
Security Target Lite
M5072
Public
7.4 TOE Security Assurance Requirements
1
The evaluation assurance level is EAL5 augmented with ALC_DVS.2 and AVA_VAN.5. In the following
2
table, the security assurance requirements are given. The augmentation of the assurance components
3
compared to the Protection Profile [1] is expressed with bold letters.
4
5
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
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 AVA_VAN.5 Advanced methodical vulnerability in PP [1]
53
Security Target Lite
M5072
Public
Assessment analysis
Table 17 Assurance components
1
7.4.1 Refinements
2
Some refinements are taken unchanged from the PP [1]. In some cases a clarification is necessary. In
3
Table 16 an overview is given where the refinement is done.
4
Two refinements from the PP [1] have to be discussed here in the Security Target, as the assurance
5
level is increased.
6
Life cycle support (ALC_CMS, ALC_TAT)
7
The refinement from the PP [1] can be applied even at the chosen assurance level EAL 5 augmented
8
with ALC_CMS.5 and ALC_TAT.2. The assurance package ALC_CMS.4 is extended to ALC_CMS.5
9
with aspects regarding the configuration control system for the TOE. The assurance package
10
ALC_TAT.1 is extended to ALC_TAT.2 with aspects regarding the implementation standards for the
11
TOE. The refinements are not touched.
12
Functional Specification (ADV_FSP)
13
The refinement from the PP [1] can be applied even at the chosen assurance level EAL 5 augmented
14
with ADV_FSP.5. The assurance package ADV_FSP.4 is extended to ADV_FSP.5 with aspects
15
regarding the descriptive level. The level is increased from informal to semi-formal with informal
16
description. The refinement is not touched from this measure.
17
For details of the refinement see PP [1].
18
Tests (ATE_DPT.3)
19
The refinement from the PP [1] can be applied even at the chosen assurance level EAL 5 augmented
20
with ATE_DPT.3. The assurance package ATE_DPT.2 is augmented to ATE_DPT.3 relating to the
21
requirements of the assurance level EAL 5. The refinement is not touched.
22
23
24
7.5 Security Requirements Rationale
25
7.5.1 Rationale for the Security Functional Requirements
26
The security functional requirements rationale of the TOE are defined and described in PP [1] section 6.3
27
for the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3,
28
FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1/HW and FAU_SAS.1.
29
The security functional requirements FPT_TST.2, FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3,
30
FMT_SMF.1, FCS_COP.1, FCS_CKM.1, FDP_SDI.1 and FDP_SDI.2 are defined in the following
31
description:
32
54
Security Target Lite
M5072
Public
Table 18 Rational for additional SFR in the ST
1
Objective TOE Security Functional Requirements
O.Add-Functions FCS_COP.1/DES_SCL_v2 „Cryptographic operation“
FCS_COP.1/AES_SCL_v2 „Cryptographic operation“
FCS_COP.1/RSA „Cryptographic operation“
FCS_COP.1/ECDSA „Cryptographic operation“
FCS_COP.1/ECDH „Cryptographic operation“
FCS_CKM.1/RSA „Cryptographic key generation“
FCS_CKM.1/EC „Cryptographic key generation“
O.Phys-
Manipulation
FPT_TST.2 „ Subset TOE security testing “
O.Mem-Access FDP_ACC.1 “Subset access control”
FDP_ACF.1 “Security attribute based access control”
FMT_MSA.3 “Static attribute initialisation”
FMT_MSA.1 “Management of security attributes”
FMT_SMF.1 “Specification of Management Functions”
O.Malfunction FDP_SDI.1 „Stored data integrity monitoring“
FDP_SDI.2 „Stored data integrity monitoring and action“
2
The table above gives an overview, how the security functional requirements are combined to meet the
3
security objectives. The detailed justification is given in the following:
4
The justification related to the security objective “Additional Specific Security Functionality
5
(O.Add-Functions)” is as follows:
6
The security functional requirement(s) “Cryptographic operation (FCS_COP.1)” exactly requires those
7
functions to be implemented which are demanded by O.Add-Functions. FCS_CKM.1/RSA1
supports the
8
generation of RSA keys, FCS_CKM.1/EC supports the generation of EC keys needed for this
9
cryptographic operations. Therefore, FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH,
10
FCS_CKM.1/RSA and FCS_CKM/EC are suitable to meet the security objective. The use of the
11
supporting libraries Toolbox and Base has no impact on any security functional requirement nor does its
12
use generate additional requirements.
13
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
14
functions are used as specified and that the User Data processed by these functions are protected as
15
defined for the application context. These issues are addressed by the specific security functional
16
requirements:
17
 [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
All these requirements have to be fulfilled to support OE.Resp-Appl for FCS_COP.1/DES_SCL_v2,
23
FCS_COP.1/AES_SCL_v2. For the FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH,
24
FCS_CKM.1/RSA and FCS_CKM.1/EC are optional, since they are fulfilled by the TOE or may be
25
fulfilled by the environment as the user can generate keys externally additionally.
26
1
Generation of RSA key pairs is only provided by version 2.06.003 of the library
55
Security Target Lite
M5072
Public
The security functional requirements required to meet the security objectives O.Leak-Inherent, O.Phys-
1
Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement the specific
2
security functionality. However, key-dependent functions could be implemented in the Smartcard
3
Embedded Software.
4
The usage of cryptographic algorithms requires the use of appropriate keys. Otherwise these
5
cryptographic functions do not provide security. The keys have to be unique with a very high probability,
6
and must have a certain cryptographic strength etc. In case of a key import into the TOE (which is
7
usually after TOE delivery) it has to be ensured that quality and confidentiality are maintained. Keys for
8
3DES and AES are provided by the environment, the keys for EC algorithms can be provided either by
9
the TOE or the environment. The keys for the RSA algorithms can be provided by the TOE if the
10
customer orders version 2.06.003 of the RSA library or have to be provided by the environment.
11
In this ST the objectives for the environment OE.Plat-Appl and OE.Resp-Appl have been clarified. The
12
Smartcard Embedded Software defines the use of the cryptographic functions FCS_COP.1 provided by
13
the TOE. The requirements for the environment FDP_ITC.1, FDP_ITC.2, FCS_CKM.1 and FCS_CKM.4
14
support an appropriate key management. These security requirements are suitable to meet OE.Resp-
15
Appl.
16
The justification of the security objective and the additional requirements (both for the TOE and its
17
environment) show that they do not contradict to the rationale already given in the Protection Profile for
18
the assumptions, policy and threats defined there.
19
The security functional component Subset TOE security testing (FPT_TST.2) has been newly created
20
(Common Criteria Part 2 extended). This component allows that particular parts of the security
21
mechanisms and functions provided by the TOE can be tested after TOE Delivery. This security
22
functional component is used instead of the functional component FPT_TST.1 from Common Criteria
23
Part 2. For the user it is important to know which security functions or mechanisms can be tested. The
24
functional component FPT_TST.1 does not mandate to explicitly specify the security functions being
25
tested. In addition, FPT_TST.1 requires verification of the integrity of TSF data and stored TSF
26
executable code which might violate the security policy.
27
The tested security enforcing functions are SF_DPM Device Phase Management and SF_PMA
28
Protection against modifying attacks.
29
The security functional requirement FPT_TST.2 will detect attempts to conduce a physical manipulation
30
on the monitoring functions of the TOE. The objective of FPT_TST.2 is O.Phys-Manipulation. The
31
physical manipulation will be tried to overcome security enforcing functions.
32
The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security
33
Function Policy (SFP) “Memory Access Control Policy” exactly require the implementation of an area
34
based memory access control as required by O.Mem-Access. The related TOE security functional
35
requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.3, FMT_MSA.1 and FMT_SMF.1 cover this security
36
objective. The implementation of these functional requirements is represented by the dedicated privilege
37
level concept.
38
The justification of the security objective and the additional requirements show that they do not contradict
39
to the rationale already given in the Protection Profile for the assumptions, policy and threats defined
40
there. Moreover, these additional security functional requirements cover the requirements by [3] user
41
data protection of chapter 11 which are not refined by the PP [1].
42
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
43
functions are used as specified and that the User Data processed by these functions are protected as
44
defined for the application context. The TOE only provides the tool to implement the policy defined in the
45
context of the application.
46
The justification related to the security objective “Protection against Malfunction due to Environmental
47
Stress (O.Malfunction)” is as follows:
48
56
Security Target Lite
M5072
Public
The security functional requirement “Stored data integrity monitoring (FDP_SDI.1)” requires the
1
implementation of an Error Detection (EDC) algorithm which detects integrity errors of the data stored in
2
RAM, ROM and SOLID FLASH™ NVM (in the SOLID FLASH™ NVM more bit errors are detected). By
3
this the malfunction of the TOE using corrupt data is prevented. Therefore FDP_SDI.1 is suitable to meet
4
the security objective.
5
The security functional requirement “Stored data integrity monitoring and action (FDP_SDI.2)” requires
6
the implementation of an integrity observation and correction which is implemented by the Error
7
Detection (EDC) and Error Correction (ECC) measures. The EDC is present in RAM and ROM of the
8
TOE while the ECC is realized in the SOLID FLASH™ NVM. These measures detect and inform about
9
one and more bit errors. In case of the SOLID FLASH™ NVM 1 bit errors of the data are corrected
10
automatically. By the ECC mechanisms it is prevented that the TOE uses corrupt data. Therefore
11
FDP_SDI.2 is suitable to meet the security objective.
12
The CC part 2 defines the component FIA_SOS.2, which is similar to FCS_RNG.1, as follows:
13
14
FIA_SOS.2 TSF Generation of secrets
15
Hierarchical to: No other components.
16
Dependencies: No dependencies.
17
FIA_SOS.2.1 The TSF shall provide a mechanism to generate secrets that meet
18
[assignment:a defined quality metric].
19
FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF generated secrets for
20
[assignment: list of TSF functions].
21
22
The CC part 2, annex G.3 [3], states: “This family defines requirements for mechanisms that enforce
23
defined quality metrics on provided secrets, and generate secrets to satisfy the defined metric“. Even the
24
operation in the element FIA_SOS.2.2 allows listing the TSF functions using the generated secrets.
25
Because all applications discussed in annex G.3 are related to authentication, the component
26
FIA_SOS.2 is also intended for authentication purposes while the term “secret” is not limited to
27
authentication data (cf. CC part 2, paragraphs 39-42).
28
Paragraph 685 in the CC part 2 [3] recommends use of the component FCS_CKM.1 to address random
29
number generation. However, this may hide the nature of the secrets used for key generation and does
30
not allow describing random number generation for other cryptographic methods (e.g., challenges,
31
padding), authentication (e.g., password seeds), or other purposes (e.g., blinding as a countermeasure
32
against side channel attacks).
33
The component FCS_RNG addresses general RNG, the use of which includes but is not limited to
34
cryptographic mechanisms. FCS_RNG allows to specify requirements for the generation of random
35
numbers including necessary information for the intended use. These details describe the quality of the
36
generated data where other security services rely on. Thus by using FCS_RNG a ST or PP author is
37
able to express a coherent set of SFRs that include or use the generation of random numbers as a
38
security service.
39
40
7.5.1.1 Dependencies of Security Functional Requirements
41
The dependence of security functional requirements are defined and described in PP [1] section 6.3.2 for
42
the following security functional requirements: FDP_ITT.1, FDP_IFC.1, FPT_ITT.1, FPT_PHP.3,
43
FPT_FLS.1, FRU_FLT.2, FMT_LIM.1, FMT_LIM.2, FCS_RNG.1/HW and FAU_SAS.1.
44
The dependence of security functional requirements for the security functional requirements FPT_TST.2,
45
FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FCS_COP.1, FCS_CKM.1,
46
FDP_SDI.1 and FDP_SDI.2 are defined in the following description.
47
57
Security Target Lite
M5072
Public
Table 19 Dependency for cryptographic operation requirement
1
Security Functional
Requirement
Dependencies Fulfilled by security
requirements
FCS_COP.1/DES_SC
L_v2
FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, see comment 2
FCS_CKM.4 Yes, see comment 2
FCS_COP.1/AES_SC
L_v2
FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, see comment 2
FCS_CKM.4 Yes, see comment 2
FCS_COP.1/RSA FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes, see comment 2
FCS_CKM.4 Yes, see comment 2
FCS_CKM.1/RSA1
FCS_CKM.2 or FCS_COP.1 Yes
FCS_CKM.4 Yes, see comment 2
FCS_COP.1/ECDSA FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes
FCS_CKM.4 Yes, see comment 2
FCS_CKM.1/EC FCS_CKM.2 or FCS_COP.1 Yes
FCS_CKM.4 Yes, see comment 2
FCS_COP.1/ECDH FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 Yes
FCS_CKM.4 Yes, see comment 2
FPT_TST.2 None N/A
FDP_ACC.1 FDP_ACF.1 Yes
FDP_ACF.1 FDP_ACC.1 Yes
FMT_MSA.3 Yes
FMT_MSA.3 FMT_MSA.1 Yes
FMT_SMR.1 Not required,
see comment 1
FMT_MSA.1 FDP_ACC.1 or FDP_IFC.1 Yes
FMT_SMR.1 Not required,
see comment 1
FMT_SMF.1 Yes
FMT_SMF.1 None N/A
FDP_SDI.1 None N/A
FDP_SDI.2 None N/A
2
Comment 1:
3
The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is
4
considered to be satisfied because the access control specified for the intended TOE is not role-based
5
but enforced for each subject. Therefore, there is no need to identify roles in form of a security functional
6
requirement FMT_SMR.1.
7
1
Generation of RSA key pairs is only provided by version 2.06.003 of the library
58
Security Target Lite
M5072
Public
Comment 2:
1
The security functional requirement “Cryptographic operation (FCS_COP.1)” met by the TOE, has the
2
following dependencies:
3
 [FDP_ITC.1 Import of user data without security attributes, or
4
 FDP_ITC.2 Import of user data with security attributes, or
5
 FCS_CKM.1 Cryptographic key generation] and
6
 FCS_CKM.4 Cryptographic key destruction.
7
The security functional requirement “Cryptographic key management (FCS_CKM)” met by TOE, has the
8
following dependencies:
9
 [FCS_CKM.2 Cryptographic key distribution, or
10
 FCS_COP.1 Cryptographic operation] and
11
 FCS_CKM.4 Cryptographic key destruction.
12
These requirements all address the appropriate management of cryptographic keys used by the
13
specified cryptographic function and are not part of the PP [1]. Most requirements concerning key
14
management shall be fulfilled by the environment since the Smartcard Embedded Software is designed
15
for a specific application context and uses the cryptographic functions provided by the TOE.
16
For the security functional requirement FCS_COP.1/DES_SCL_v2 and FCS_COP.1/AES_SCL_v2 the
17
respective dependencies [FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2] and FCS_CKM.4 have to be
18
fulfilled by the environment. That means that the environment shall meet the requirement FCS_CKM.1
19
as defined in [3], section 10.1 or shall meet the requirements FDP_ITC.1 or FDP_ITC.2 as defined in [3],
20
section 11.7. In addition the environment shall meet the requirement FCS_CKM.4 as defined in [3],
21
section 10.1.
22
For the security functional requirements FCS_COP.1/ECDSA, and FCS_COP.1/ECDH, the respective
23
dependencies FCS_CKM.4 has to be fulfilled by the environment. That means that the environment shall
24
meet the requirement FCS_CKM.4 as defined in [3], section 10.1. The TOE already provides the key
25
generation (FCS_CKM.1/EC), however the environment can of course implement its own key generation
26
or key importort ([FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2]).
27
For the security functional requirement FCS_COP.1/RSA the dependency [FCS_CKM.1 or FDP_ITC.1
28
or FDP_ITC.2] is already fulfilled in case library version 2.06.003 is ordered due to the implemented RSA
29
key generation (FCS_CKM.1/RSA). However if version 1.03.006 is ordered, the environment has to fulfil
30
the dependency [FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2]. This means that the environment shall
31
meet the requirement FCS_CKM.1 as defined in [3], section 10.1 or shall meet the requirements
32
FDP_ITC.1 or FDP_ITC.2 as defined in [3], section 11.7. Independent of the chosen library version, the
33
environment has to fulfil the dependency FCS_CKM.4. This means that the environment shall meet the
34
requirement FCS_CKM.4 as defined in [3], section 10.1.
35
For the security functional requirement FCS_CKM.1/RSA1
and FCS_CKM.1/EC the respective
36
dependency FCS_COP.1 is fulfilled by the TOE. The respective dependency FCS_CKM.4 has to be
37
fulfilled by the environment. That means, the environment shall meet the requirement FCS_CKM.4 as
38
defined in [3], section 10.1.
39
The cryptographic libraries RSA and EC and the Toolbox library are delivery options. If one of the
40
libraries RSA, EC or Toolbox are delivered, the asymmetric Base Lib is automatically part of it. Therefore
41
the user may choose a free combination of these libraries. In case of deselecting one or several of these
42
libraries the TOE does not provide the respective functionality Additional Specific Security Functionality
43
Rivest-Shamir-Adleman Cryptography (RSA) and/or Elliptic Curve Cryptography (EC). The Toolbox and
44
asymmetric Base Library are no cryptographic libraries and provide no additional specific security
45
functionality.
46
1
Generation of RSA key pairs is only provided by version 2.06.003 of the library
59
Security Target Lite
M5072
Public
1
7.5.2 Rationale of the Assurance Requirements
2
The chosen assurance level EAL5 and the augmentation with the requirements ALC_DVS.2 and
3
AVA_VAN.5 were chosen in order to meet the assurance expectations explained in the following
4
paragraphs. In Table 17 the different assurance levels are shown as well as the augmentations. The
5
augmentations are in compliance with the Protection Profile.
6
An assurance level EAL5 with the augmentations ALC_DVS.2 and AVA_VAN.5 are required for this type
7
of TOE since it is intended to defend against highly sophisticated attacks without protective environment.
8
This evaluation assurance package was selected to permit a developer to gain maximum assurance
9
from positive security engineering based on good commercial practices. In order to provide a meaningful
10
level of assurance that the TOE provides an adequate level of defence against such attacks, the
11
evaluators should have access to all information regarding the TOE including the TSF internals, the low
12
level design and source code including the testing of the modular design. Additionally the mandatory
13
technical document “Application of Attack Potential to Smartcards” [10] shall be taken as a basis for the
14
vulnerability analysis of the TOE.
15
16
17
ALC_DVS.2 Sufficiency of security measures
18
Development security is concerned with physical, procedural, personnel and other technical measures
19
that may be used in the development environment to protect the TOE.
20
In the particular case of a Security IC the TOE is developed and produced within a complex and
21
distributed industrial process which must especially be protected. Details about the implementation, (e.g.
22
from design, test and development tools as well as Initialization Data) may make such attacks easier.
23
Therefore, in the case of a Security IC, maintaining the confidentiality of the design is very important.
24
This assurance component is a higher hierarchical component to EAL5 (which only requires
25
ALC_DVS.1). ALC_DVS.2 has no dependencies.
26
60
Security Target Lite
M5072
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. This
2
assurance requirement is achieved by the AVA_VAN.5 component.
3
Independent vulnerability analysis is based on highly detailed technical information. The main intent of
4
the evaluator analysis is to determine that the TOE is resistant to penetration attacks performed by an
5
attacker possessing high attack potential.
6
AVA_VAN.5 has dependencies to ADV_ARC.1 “Security architecture description”, ADV_FSP.2 “Security
7
enforcing functional specification”, ADV_TDS.3 “Basic modular design”, ADV_IMP.1 “Implementation
8
representation of the TSF”, AGD_OPE.1 “Operational user guidance”, and AGD_PRE.1 “Preparative
9
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 cards
12
used for digital signature applications or payment systems. Therefore, specifically AVA_VAN.5 was
13
chosen in order to assure that even these attackers cannot successfully attack the TOE.
14
15
61
Security Target Lite
M5072
Public
8 TOE Summary Specification (ASE_TSS)
1
The product overview is given in section 2.1. In the following the Security Features are described and the
2
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, 4)
13
and final use (phase 4-7) is a rough split-up from TOE point of view. These phases are implemented in
14
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 data
16
(O.Identification) is stored in a in the not changeable configuration page area and non-volatile memory.
17
In the same area further TOE configuration data is stored. In addition, user initialization data can be
18
stored in the non-volatile memory during the production phase as well. During this first data
19
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 various operation modes is taken dependent on
22
phase 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 phase 6),
28
the TOE provides the possibility to download a user specific encryption key and user code and data into
29
the empty (erased) SOLID FLASH™ NVM memory area as specified by the associated control
30
information of the Flash Loader software. After finishing the load operation, the Flash Loader can be
31
permanently deactivated, so that no further load operation with the Flash Loader is possible. These
32
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 access
35
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 the
39
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 management in
42
dependency of the firmware or software to be executed.
43
The covered security functional requirement is FMT_SMF.1 “Specification of Management functions”.
44
62
Security Target Lite
M5072
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 authentication
3
code fails a direct security reset is performed. The covered security functional requirements is
4
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,
7
FMT_SMF.1, 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 and
11
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 timing
15
and current consumption is independent of the processed data. In the design a number of components
16
are automatically synthesized and mixed up to disguise an attacker and to make an analysis more
17
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 identified
20
and protected by special routing measures against probing. Additionally the wires are embedded into
21
shield lines and used as normal signal lines for operation of the chip to prevent successful probing. This
22
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 secure
25
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 to
27
protect them against data analysis.
28
In addition the data transferred over the memory bus to and from (bi-directional encryption) the CPU, Co-
29
processor (Crypto2304T and SCP), the special SFRs and the peripheral devices (CRC, RNG and Timer)
30
are transported encrypted with an automatically dynamic key change.
31
The encryption of the memory content is done by the MED using a proprietary cryptographic algorithm
32
and a complex key management providing protection against cryptographic analysis attacks. This means
33
that the SOLID FLASH™ NVM, RAM, ROM and the bus are encrypted with module dedicated and
34
dynamic keys. The only key remaining static over the product life cycle is the specific ROM key changing
35
from mask to mask.
36
All security relevant transfer of addresses or data via the peripheral bus is dynamically masked and thus
37
protected against readout and analysis.
38
The function Trash Register Writes can be activated by the user to hide the fact if an register has been
39
written.
40
The covered security functional requirements are FDP_IFC.1 “Subset information flow control“,
41
FPT_PHP.3 “Resistance to physical attack”, FPT_ITT.1 “Basic internal TSF data transfer protection,
42
FPT_FLS.1 “Failure with preservation of secure state” and FDP_ITT.1 “Basic internal transfer
43
protection”.
44
45
The SF_PS “Protection against Snooping” covers the security functional requirements FPT_PHP.3,
46
FDP_IFC.1, FPT_ITT.1, FPT_FLS.1 and FDP_ITT.1.
47
63
Security Target Lite
M5072
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 an
7
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 programming
12
operation or if other perturbation is applied, no data or content loss occurs and the TOE restarts power
13
on. The NVM tearing save write functionality covers FDP_SDI.1 “Stored data integrity monitoring” as the
14
new data to be programmed are checked for integrity and correct programming before the page with the
15
old data becomes valid.
16
17
The covered security functional requirement are FPT_PHP.3 “Resistance to physical attack“, since these
18
measures make it difficult to manipulate the write process of the NVM, FPT_FLS.1 “Failure with
19
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 the
21
TOE is immediately stopped and the TOE enters a secure state called security reset.
22
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure state”,
23
FPT_PHP.3 “Resistance to physical attack” and FPT_TST.2 “Subset TOE security testing“.
24
As physical effects or manipulative attacks may also address the program flow of the user software, two
25
watchdog timers each with a check point register function are implemented. This feature allows the user
26
to check the correct processing time and the integrity of the program flow of the user software.
27
The Instruction Stream Signature Checking (ISS) calculates a hash about all executed instructions and
28
automatically checks the correctness of this hash value. If the code execution follows an illegal path an
29
alarm is triggered.
30
Another measure against modifying and perturbation respectively differential fault attacks (DFA) is the
31
implementation of backward calculation in the SCP. By this induced errors are discovered.
32
The covered security functional requirements are FPT_FLS.1 “Failure with preservation of secure state”,
33
FDP_IFC.1 “Subset information flow control”, FPT_ITT.1 “Basic internal transfer protection”, FDP_ITT.1
34
“Basic internal transfer protection” and FPT_PHP.3 “Resistance to physical attack”.
35
During start up, the TOE performs various configurations and subsystem tests. After the TOE startup has
36
finished, the operating system or application can call the User Mode Security Life Control (UMSLC) test
37
provided by the Resource Management System. The UMSLC checks the alarm lines and/or the different
38
security functions and sensors for correct operation. The test can be triggered by user software during
39
normal operation. As attempts to modify the security features will be detected from the test, the covered
40
security functional requirement is FPT_TST.2 “Subset TOE security testing“.
41
The correct function of the TOE is only given in the specified range of the environmental operating
42
parameters. To prevent an attack exploiting that circumstance the TOE is equipped with a temperature
43
sensor, glitch sensor and backside light detection. The TOE falls into the defined secure state in case of
44
a specified range violation. The defined secure state causes the chip internal reset process. Note that
45
the specified range checking can only work when the TOE is running and can not prevent reverse
46
engineering.
47
The covered security functional requirements are FRU_FLT.2 “Limited fault tolerance” and FPT_FLS.1
48
“Failure with preservation of secure state“.
49
64
Security Target Lite
M5072
Public
The SF_PMA “Protection against Modifying Attacks” covers the security functional requirements
1
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
2
FPT_FLS.1.
3
4
8.4 SF_PLA: Protection against Logical Attacks
5
The memory model of the TOE provides two distinct, independent levels called the privileged and non-
6
privilege level and the possibility to define up to eight memory regions with different access rights
7
enforced by the Management Protection Unit (MPU). This gives the user software the possibility to
8
define different access rights for the regions 0 to 7 for privilege or non-privilege level. In the case of an
9
access violation the MPU will trigger a trap. The policy of setting up the MPU and specifying the memory
10
ranges for the regions (0 to 7) is defined from the user software.
11
The covered security functional requirements are FDP_ACC.1 “Subset access control”, FDP_ACF.1
12
“Security attribute based access control”, FMT_MSA.1 “Management of security attributes”, FMT_MSA.3
13
“Static attribute initialisation” and FMT_SMF.1 “Specification of Management functions”.
14
All memories present on the TOE (NVM, ROM, RAM) are encrypted using individual keys assigned by
15
complex key management. In case of security critical error a security alarm is generated and the TOE
16
ends up in a secure state.
17
The covered security functional requirements are FDP_ACF.1 “Security attribute based access control”
18
and FPT_FLS.1 “Failure with preservation of secure state”.
19
The SF_PLA “Protection against Logical Attacks” covers the security functional requirements
20
FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FPT_FLS.1 and FMT_SMF.1.
21
22
8.5 SF_CS: Cryptographic Support
23
The TOE is equipped an asymmetric and a symmetric hardware accelerators to support the standard
24
symmetric and asymmetric cryptographic operations. This security function is introduced to include the
25
cryptographic operation in the scope of the evaluation as the cryptographic function respectively
26
mathematic algorithm itself is not used from the TOE security policy. The components are a co-
27
processor supporting the DES and AES algorithms and a co-processor and software modules to support
28
RSA cryptography, RSA key generation, EC signature generation and verification, ECDH key agreement
29
and EC public key calculation and testing. Additionally the TOE is equipped with a True Random
30
Number Generator for the generation of random numbers.
31
8.5.1 3DES encryption
32
The TOE supports the encryption and decryption in accordance with the specified cryptographic
33
algorithm Triple Data Encryption Standard (3DES) in the Electronic Codebook Mode (ECB), Cipher
34
Block Chaining Mode (CBC), Cipher Feedback (CFB), Counter (CTR) Modes and with cryptographic key
35
sizes of 112 bit or 168 bit meeting the standard:
36
National Institute of Standards and Technology (NIST), Technology Administration, U.S. Department of
37
Commerce, NIST Special Publication 800-67, Recommendation for the Triple Data Encryption Algorithm
38
(TDEA) Block Cipher, Revised January 2012, Revision 1
39
and
40
NIST Special Publication 800-38A, Edition 2001
41
The covered security functional requirements are
42
1. FCS_COP.1/DES: By directly programming the hardware registers of the symmetric coprocessor.
43
2. FCS_COP.1/DES_SCL_v2: By using the interface of the optional SCL. This library contains additional
44
countermeasures.
45
65
Security Target Lite
M5072
Public
Note: This TOE can be delivered with the SCP accessible or blocked. The blocking depends on the
1
customer demands prior to the production of the hardware. In case the SCP is blocked, no DES
2
computation supported by hardware is possible and this TSF will not be provided.
3
Note: The TOE can also be delivered with the optional SCL. The optional SCL contains hardened
4
DES algorithms. The optional SCL needs an accessible SCP.
5
6
8.5.2 AES encryption
7
The TSF supports the encryption and decryption in accordance with the specified cryptographic
8
algorithm Advanced Encryption Standard (AES) ) in the Electronic Codebook Mode (ECB) , Cipher
9
Block Chaining Mode (CBC) ), Cipher Feedback (CFB), Counter (CTR) Modes and cryptographic key
10
sizes of 128 bit or 192 bit or 256 bit according to the standard:
11
U.S. Department of Commerce, National Institute of Standards and Technology, Information Technology
12
Laboratory (ITL), Advanced Encryption Standard (AES), FIPS PUB 197 and NIST Special Publication
13
800-38A, Edition 2001.
14
The covered security functional requirement are
15
1. FCS_COP.1/AES: By directly programming the hardware registers of the symmetric coprocessor.
16
2. FCS_COP.1/AES_SCL_v2: By using the interface of the optional SCL. This library contains additional
17
countermeasures.
18
Note: This TOE can be delivered with the SCP accessible or blocked. The blocking depends on the
19
customer demands prior to the production of the hardware. In case the SCP is blocked, no AES
20
computation supported by hardware is possible and this TSF will not be provided.
21
Note: The TOE can also be delivered with the optional SCL. The optional SCL contains hardened
22
AES algorithms. The optional AES library needs an accessible SCP.
23
24
8.5.3 RSA
25
8.5.3.1 Encryption, Decryption, Signature Generation and Verification
26
The TSF shall perform encryption and decryption in accordance with a specified cryptographic
27
algorithm Rivest-Shamir-Adleman (RSA) and cryptographic key sizes 1024 - 4096 bits that meet the
28
following standards:
29
Encryption:
30
According to section 5.1.1 RSAEP in PKCS v2.1 RFC3447, without 5.1.1.1.
31
Decryption (with or without CRT):
32
According to section 5.1.2 RSADP in PKCS v2.1 RFC3447
33
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.
34
5.1.2.2.a, only supported up to n < 22048
.
35
Signature Generation (with or without CRT):
36
According to section 5.2.1 RSASP1 in PKCS v2.1 RFC3447
37
for u = 2, i.e., without any (r_i, d_i, t_i), i >2,
38
therefore without 5.2.1.2.b (ii)&(v), without 5.2.1.1.
39
5.2.1.2.a, only supported up to n < 22048
.
40
66
Security Target Lite
M5072
Public
Signature Verification:
1
According to section 5.2.2 RSAVP1 in PKCS v2.1 RFC3447,
2
without 5.2.2.1.
3
The covered security functional requirement is FCS_COP.1/RSA.
4
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
5
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this SFR
6
is not applicable.
7
Note: The TOE can also be delivered with the optional RSA v1.03.006 and v2.06.003 library. Either
8
optional RSA library contains the RSA algorithms stated above. The optional RSA library needs an
9
accessible Crypto2304T. If the optional RSA library is not delivered then this TSF is not provided.
10
8.5.3.2 Asymmetric Key Generation
11
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation
12
algorithm RSA specified in PKCS#1 v2.1 and specified cryptographic key sizes of 1024 – 4096 bits that
13
meet the following standard:
14
According to section 3.2(2) in PKCS v2.1 RFC3447,
15
for u=2, i.e., without any (r_i, d_i, t_i), i > 2.
16
For p x q < 22048
additionally according to section 3.2(1).
17
The covered security functional requirement is FCS_CKM.1/RSA.
18
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
19
the Crypto2304T is blocked, no RSA computation supported by hardware is possible and this TSF
20
is not provided.
21
Note: The optional RSA v2.06.003 library contains the RSA algorithms stated above. The optional
22
RSA v2.06.003 library needs an accessible Crypto2304T. If the optional RSA v2.06.003 library is
23
not delivered then this TSF is not provided.
24
8.5.4 Elliptic Curves
25
The certification covers the standard NIST [DSS] and Brainpool [ECC] Elliptic Curves with key
26
lengths of 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 Bits, due to national AIS32
27
regulations by the BSI. Note that there are numerous other curve types, being also secure in terms
28
of side channel attacks on this TOE, which can the user optionally add in the composition
29
certification process.
30
31
8.5.4.1 Signature Generation and Verification
32
The TSF shall perform signature generation and signature verification in accordance with a specified
33
cryptographic algorithm ECDSA and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320,
34
384, 409, 512 or 521 bits that meet the following standard:
35
36
Signature Generation:
37
1. According to section 7.3 in ANSI X9.62 – 2005:
38
Not implemented is step d) and e) thereof.
39
The output of step e) has to be provided as input to our function by the caller.
40
Deviation of step c) and f):
41
The jumps to step a) were substituted by a return of the function with an error code, the jumps are
42
emulated by another call to our function.
43
67
Security Target Lite
M5072
Public
2. According to sections 6.2 (6.2.2. + 6.2.3) in ISO/IEC 15946-2:2002:
1
Not implemented is section 6.2.1:
2
The output of 5.4.2 has to be provided by the caller as input to the function.
3
4
Signature Verification:
5
1. According to section 7.4.1 in ANSI X9.62–2005:
6
Not implemented is step b) and c) thereof.
7
The output of step c) has to be provided as input to our function by the caller.
8
Deviation of step d):
9
Beside noted calculation, our algorithm adds a random multiple of the group order n to the calculated
10
values u1 and u2.
11
2. According to sections 6.4 (6.4.1. + 6.4.3 + 6.4.4) in ISO/IEC 15946-2:2002
12
Not implemented is section 6.4.2:
13
The output of 5.4.2 has to be provided by the caller as input to the function.
14
15
The covered security functional requirement is FCS_COP.1/ECDSH.
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 TSF
18
is not provided.
19
Note: The TOE can also be delivered with the optional ECC v1.03.006 and v2.06.003 library. Each
20
optional ECC library contains the ECC algorithms stated above. Either optional ECC library needs
21
an accessible Crypto2304T. If neither optional ECC library is delivered then this TSF is not
22
provided.
23
8.5.4.2 Asymmetric Key Generation
24
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation
25
algorithm Elliptic Curve EC specified in ANSI X9.62-1998 and ISO/IEC 15946-1:2002 and specified
26
cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384, 409, 512 or 521 bits that meet the
27
following standard:
28
29
ECDSA Key Generation:
30
1. According to the appendix A4.3 in ANSI X9.62-2005 the cofactor h is not supported.
31
2. According to section 6.1 (not 6.1.1) in ISO/IEC 15946-1:2002
32
33
The covered security functional requirement is FCS_CKM.1/EC.
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 TSF
36
is not provided.
37
Note: The TOE can also be delivered with the optional ECC v1.03.006 and v2.06.003 library. Each
38
optional ECC library contains the ECC algorithms stated above. Either optional ECC library needs
39
an accessible Crypto2304T. If neither optional ECC library is delivered then this TSF is not
40
provided.
41
42
68
Security Target Lite
M5072
Public
8.5.4.3 Asymmetric Key Agreement
1
The TSF shall perform elliptic curve Diffie-Hellman key agreement in accordance with a specified
2
cryptographic algorithm ECDH and cryptographic key sizes 160, 163, 192, 224, 233, 256, 283, 320, 384,
3
409, 512 or 521 bits that meet the following standard:
4
1. According to section 5.4.1 in ANSI X9.63 -2001 Unlike section 5.4.1.3 our implementation not only
5
returns the x-coordinate of the shared secret, but rather the x-coordinate and y-coordinate.
6
2. According to sections 8.4.2.1, 8.4.2.2, 8.4.2.3, and 8.4.2.4 in ISO/IEC 15946-3:2002: The function
7
enables the operations described in the four sections.
8
9
The covered security functional requirement is FCS_COP.1/ECDH.
10
Note: This TOE can be delivered with the Crypto2304T coprocessor accessible or blocked. In case
11
the Crypto2304T is blocked, no ECC computation supported by hardware is possible and this TSF
12
is not provided.
13
Note: The TOE can also be delivered with the optional ECC library. The optional ECC library
14
contains the ECC algorithms stated above. The optional ECC library needs an accessible
15
Crypto2304T. If the optional ECC library is not delivered then this TSF is not provided.
16
8.5.5 Toolbox Library
17
The toolbox provides the following basic long integer arithmetic and modular functions in software,
18
supported by the cryptographic coprocessor: Addition, subtraction, division, multiplication, comparison,
19
reduction, modular addition, modular subtraction, modular multiplication, modular inversion and modular
20
exponentiation. No security relevant policy, mechanism or function is supported. The toolbox library is
21
deemed for software developers as support for simplified implementation of long integer and modular
22
arithmetic operations.
23
The toolbox does not cover security functional requirements.
24
8.5.6 Asymmetric Base Library
25
The asymmetric Base library provides the low level interface to the asymmetric cryptographic
26
coprocessor and has no user available interface. The asymmetric Base library does not provide any
27
security functionality, implements no security mechanism, and does not provide additional specific
28
security functionality. The asymmetric Base library does not cover security functional requirements.
29
8.5.7 Symmetric Crypto Library (SCL)
30
The symmetric crypto Library provides an interface to the SCP for AES and 3DES operations. The
31
SCL contains additional software countermeasures to harden the restance against side channel and
32
fault attacks. The SCL consists of three files “AES.lib”, “DES.lib” and “cipher.lib”. Those library files
33
will only distributes together.
34
The covered security functional requirements are FCS_COP.1/DES_SCL_v2,
35
FSC_COP.1/AES_SCL_v2.
36
37
8.5.8 TRNG
38
Random data is essential for cryptography as well as for security mechanisms. The TOE is equipped
39
with a physical True Random Number Generator (TRNG, FCS_RNG.1/HW). The random data can be
40
used from the Smartcard Embedded Software and is also used from the security features of the TOE,
41
like masking. The TRNG implements also self testing features. The TRNG fulfils the requirements from
42
the functionality class PTG.2 of [6].
43
69
Security Target Lite
M5072
Public
The covered security functional requirement is FCS_RNG.1/HW “Quality metric for random numbers”,
1
FPT_PHP.3 “Resistance to physical attack”, FDP_ITT.1 “Basic internal transfer protection”, FPT_ITT.1
2
“Basic internal TSF data transfer protection, FDP_IFC.1 “Subset information flow control“, FPT_TST.2
3
“Subset TOE security testing“ and FPT_FLS.1“Failure with preservation of secure state”.
4
5
The SF_CS “Cryptographic Support” covers the security functional requirements
6
FCS_COP.1/DES_SCL_v2, FSC_COP.1/AES, FSC_COP.1/AES_SCL_v2, FCS_COP.1/RSA,
7
FCS_CKM.1/RSA, FSC_COP.1/ECDSH, FCS_COP.1/ECDH, FCS_CKM.1/EC, FPT_PHP.3,
8
FDP_ITT.1, FPT_ITT.1, FPT_FLS.1, FCS_RNG.1/HW and FDP_IFC.1.
9
10
8.6 Assignment of Security Functional Requirements to TOE’s
11
Security Functionality
12
The justification and overview of the mapping between security functional requirements (SFR) and the
13
TOE’s security functionality (SF) is given in sections the sections above. The results are shown in Table
14
20. The security functional requirements are addressed by at least one relating security feature.
15
The various functional requirements are often covered manifold. As described above the requirements
16
ensure that the TOE is checked for correct operating conditions and if a not correctable failure occurs
17
that a stored secure state is achieved, accompanied by data integrity monitoring and actions to maintain
18
the integrity although failures occurred. An overview is given in following table:
19
Table 20 Mapping of SFR and SF
20
SFR SF_DPM SF_PS SF_PMA SF_PLA SF_CS
FAU_SAS.1 X
FMT_LIM.1 X
FMT_LIM.2 X
FDP_ACC.1 X X
FDP_ACF.1 X X
FPT_PHP.3 X X X
FDP_ITT.1 X X X
FDP_SDI.1 X
FDP_SDI.2 X
FDP_IFC.1 X X X X
FMT_MSA.1 X X
FMT_MSA.3 X X
FMT_SMF.1 X X
FRU_FLT.2 X
FPT_ITT.1 X X X X
FPT_TST.2 X
FPT_FLS.1 X X X X X
FCS_RNG.1/HW X
FCS_COP.1/DES_SCL_v2 X
FCS_COP.1/AES_SCL_v2 X
FCS_COP.1/RSA X
FCS_COP.1/ ECDSA X
FCS_COP.1/ECDH X
FCS_CKM.1/RSA X
70
Security Target Lite
M5072
Public
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
In addition to the discussion in section 6.3 of PP [1] the security functional requirement FCS_COP.1 is
5
introduced. The security functional requirements required to meet the security objectives O.Leak-
6
Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the
7
cryptographic algorithms implemented according to the security functional requirement FCS_COP.1.
8
Therefore, these security functional requirements support the secure implementation and operation of
9
FCS_COP.1.
10
As disturbing, manipulating during or forcing the results of the test checking the security functions after
11
TOE delivery, this security functional requirement FPT_TST.2 has to be protected. An attacker could aim
12
to switch off or disturb certain sensors or filters and preserve the detection of his manipulation by
13
blocking the correct operation of FPT_TST.2. The security functional requirements required to meet the
14
security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-
15
Forced also protect the security functional requirement FPT_TST.2. Therefore, the related security
16
functional requirements support the secure implementation and operation of FPT_TST.2.
17
The requirement FPT_TST.2 allows testing of some security mechanisms by the Smartcard Embedded
18
Software after delivery. In addition, the TOE provides an automated continuous user transparent testing
19
of certain functions.
20
The implemented level concept represents the area based memory access protection enforced by the
21
MPU. As an attacker could attempt to manipulate the privilege level definition as defined and present in
22
the TOE, the functional requirement FDP_ACC.1 and the related other requirements have to be
23
protected themselves. The security functional requirements required to meet the security objectives
24
O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect
25
the area based memory access control function implemented according to the security functional
26
requirement described in the security functional requirement FDP_ACC.1 with reference to the Memory
27
Access Control Policy and details given in FDP_ACF.1. Therefore, those security functional
28
requirements support the secure implementation and operation of FDP_ACF.1 with its dependent
29
security functional requirements.
30
The requirement FDP_SDI.2.1 allows detection of integrity errors of data stored in memory.
31
FDP_SDI.2.2 in addition allows correction of one bit errors or taking further action. Both meet the
32
security objective O.Malfunction. The requirements FRU_FLT.2, FPT_FLS.1, and FDP_ACC.1 which
33
also meet this objective are independent from FDP_SDI.2 since they deal with the observation of the
34
correct operation of the TOE and not with the memory content directly.
35
71
Security Target Lite
M5072
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 4, September 2012, CCMB-2012-09-001
[3] Common Criteria for Information Technology Security Evaluation Part 2: Security
Functional Requirements; Version 3.1 Revision 4, September 2012, CCMB-2012-09-002
[4] Common Criteria for Information Technology Security Evaluation Part 3: Security
Assurance Requirements; Version 3.1 Revision 4, September 2012, CCMB-2012-09-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 Hardware Reference Manual, Infineon Technologies AG
[10] Joint Interpretation Library, Application of Attack Potential to Smartcards, Version 2.9, January
2013
[11] SLE97 Programmer’s Reference Manual, Infineon Technologies AG
[12] M5072 Errata Sheet, Infineon Technologies AG
[15] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS31, Version 3, 2013-05-15,
Bundesamt für Sicherheit in der Informationstechnik
[23] M5072 Security Guidelines User´s Manual
[24] SCL97 Symmetric Crypto Library for SCPv3 DES / AES
[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: 1999
[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
[PKCS] PKCS #1: RSA Cryptography Standard, v2.1, June 14, 2002, RSA Laboratories
[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
2
3
72
Security Target Lite
M5072
Public
Note that the versions of these documents will be defined at the end of the evaluation and listed in the
1
certification report.
2
3
4
73
Security Target Lite
M5072
Public
10 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
O Objective
30
OS Operating system
31
RAM Random Access Memory
32
RMS Resource Management System
33
RNG Random Number Generator
34
ROM Read Only Memory
35
RSA Rives-Shamir-Adleman Algorithm
36
SCL Symmetric Crypto Library
37
SCP Symmetric Cryptographic Processor
38
74
Security Target Lite
M5072
Public
SF Security Feature
1
SFR Special Function Register, as well as Security Functional Requirement
2
SPA Simple power analysis
3
SW Software
4
T Threat
5
TM Test Mode (BOS)
6
TOE Target of Evaluation
7
TRNG True Random Number Generator
8
TSF TOE Security Functionality
9
UART Universal Asynchronous Receiver/Transmitter
10
UM User Mode (BOS)
11
UMSLC User Mode Security Life Control
12
3DES Triple DES Encryption Standard
13
75
Security Target Lite
M5072
Public
11 Glossary
1
2
Boot System Part of the firmware with routines for controlling the operating state and
3
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 type, lot
7
number (including the production site), die position on wafer and
8
production week and data stored in the ROM containing the BOS
9
version number
10
Chip Identification Mode Operational status phase of the TOE, in which actions for identifying
11
the individual chip by transmitting the Chip Identification Mode data
12
take place
13
Controller IC with integrated memory, CPU and peripheral devices
14
Crypto2304T Cryptographic coprocessor for asymmetric cryptographic operations
15
(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 operations
19
Firmware Part of the software implemented as hardware
20
Hardware Physically present part of a functional system (item)
21
Integrated Circuit Component comprising several electronic circuits implemented in a
22
highly miniaturized device using semiconductor technology
23
Memory Encryption and Decryption
24
Method of encoding/decoding data transfer between CPU and memory
25
Memory Hardware part containing digital information (binary data)
26
Microprocessor CPU with peripherals
27
Non-privilege level Restricted (non Supervisor) mode of the CPU
28
Object Physical or non-physical part of a system which contains information
29
and is acted upon by subjects
30
Operating System Software which implements the basic TOE actions necessary for
31
operation
32
Privilege level Supervisor mode of the CPU
33
Programmable Read Only Memory
34
Non-volatile memory which can be written once and then only permits
35
read operations
36
Random Access Memory Volatile memory which permits write and read operations
37
Random Number Generator Hardware part for generating random numbers
38
Read Only Memory Non-volatile memory which permits read operations only
39
76
Security Target Lite
M5072
Public
Resource Management System Part of the firmware containing SOLID FLASH™ NVM programming
1
routines, AIS31 testbench etc.
2
Security Mechanism Logic or algorithm which implements a specific security function in
3
hardware or software
4
SCP Symmetric cryptographic coprocessor for symmetric cryptographic
5
operations (3DES, AES).
6
Security Function Part(s) of the TOE used to implement part(s) of the security objectives
7
Security Target Description of the intended state for countering threats
8
Smart Card Plastic card in credit card format with built-in chip
9
Software Information (non-physical part of the system) which is required to
10
implement functionality in conjunction with the hardware (program
11
code)
12
Subject Entity, generally in the form of a person, who performs actions
13
Target of Evaluation Product or system which is being subjected to an evaluation
14
Test Mode Operational status phase of the TOE in which actions to test the TOE
15
hardware take place
16
Threat Action or event that might prejudice security
17
User Person in contact with a TOE who makes use of its operational
18
capability
19
User Mode Operational status phase of the TOE in which actions intended for the
20
user takes place
21
WLB Wafer Level Ballgrid Array
22
WLP Wafer Level Package
23
24
25
Revision History
26
Major changes since the last revision
27
Page or Reference Description of change
2.7 2016-11-02: -827-v4 based version
2.7.1 2016-11-16: after Tüv OR v1
2.7.2 2017-01-13: after TüvIT OS v3, added ACL v2.06.003
2.7.3 2017-01-31: removed external flash and FTL
2.7.4 2017-03-15: updated security guidance
2.7.5 2017-05-09: updated according to new ACL guidances
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 2017-07-11
AppNote Number
Published by
Infineon Technologies AG
81726 Munich, Germany
© 2017 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.