Maintenance ST: 0624_ma2b_pdf
PUBLIC
Common Criteria
Information Technology
Security Evaluation
Security Target Lite of
Samsung S3CC9L5
16-bit Secure RISC Microcontroller
for Smart Card with
optional Secure RSA and ECC Library
including specific IC Dedicated Software
Version 1.5
31th May 2010
S3CC9L5
SECURITY TARGET
PUBLIC
REVISION HISTORY
UPDATES:
Version
Date
Modification
1.0
3rd June 2008
Creation
1.1
9th December 2008
Revision 5 update
1.2
14th January 2009
Revision 8 update
1.3
26th May 2009
Revision 9 update
1.4
15th December 2009
Added ECC Lib
1.5
31th May 2010
Update for S3CC9L5
WRITERS:
Written by
Title
Joongchul Yoon
Principal Engineer
Version 1.5
Page 2
S3CC9L5
SECURITY TARGET
PUBLIC
CONTENTS
1
INTRODUCTION ................................................................................................................................................. 4
1.1
1.2
1.3
2
TOE DESCRIPTION ............................................................................................................................................. 7
2.1
2.2
2.3
2.4
2.5
3
PP REFERENCE ................................................................................................................................................ 52
PP TAILORING ................................................................................................................................................. 52
PP ADDITIONS ................................................................................................................................................. 52
RATIONALE......................................................................................................................................................... 53
8.1
8.2
8.3
9
LIST OF SECURITY FUNCTIONS ....................................................................................................................... 45
RELATIONSHIP BETWEEN SECURITY FUNCTIONS AND FUNCTIONAL REQUIREMENTS ................................... 50
ASSURANCE MEASURES.................................................................................................................................. 51
PP CLAIMS ........................................................................................................................................................... 52
7.1
7.2
7.3
8
TOE SECURITY REQUIREMENTS ...................................................................................................................... 25
SECURITY REQUIREMENTS FOR THE ENVIRONMENT ..................................................................................... 37
TOE SUMMARY SPECIFICATION................................................................................................................. 45
6.1
6.2
6.3
7
SECURITY OBJECTIVES FOR THE TOE .............................................................................................................. 19
SECURITY OBJECTIVES FOR THE ENVIRONMENT ............................................................................................. 22
IT SECURITY REQUIREMENTS ..................................................................................................................... 25
5.1
5.2
6
DEFINITION OF ASSETS ................................................................................................................................... 14
ASSUMPTIONS ................................................................................................................................................. 14
THREATS ......................................................................................................................................................... 15
ORGANIZATIONAL SECURITY POLICIES ......................................................................................................... 17
SECURITY OBJECTIVES................................................................................................................................... 19
4.1
4.2
5
PRODUCT DESCRIPTION ................................................................................................................................... 7
TOE DEFINITION .............................................................................................................................................. 8
TOE FEATURES ............................................................................................................................................... 11
INTERFACES OF THE TOE ............................................................................................................................... 13
TOE INTENDED USAGE .................................................................................................................................. 13
TOE SECURITY ENVIRONMENT .................................................................................................................. 14
3.1
3.2
3.3
3.4
4
SECURITY TARGET IDENTIFICATION ................................................................................................................. 4
SECURITY TARGET OVERVIEW .......................................................................................................................... 4
CC CONFORMANCE & EVALUATION ASSURANCE LEVEL .............................................................................. 6
SECURITY OBJECTIVES RATIONALE ................................................................................................................ 53
SECURITY REQUIREMENTS RATIONALE.......................................................................................................... 55
SECURITY REQUIREMENTS ARE MUTUALLY SUPPORTIVE AND INTERNALLY CONSISTENT .......................... 64
ANNEX .................................................................................................................................................................. 67
Version 1.5
Page 3
S3CC9L5
SECURITY TARGET
PUBLIC
1 INTRODUCTION
2
This introductory chapter contains the following sections:
1.1 Security Target Identification
1.2 Security Target Overview
1.3 Common Criteria conformance & Evaluation Assurance Level
1.1
Security Target Identification
3
The Security Target version is 1.5 and dated 31th May 2010
4
The Security Target is based on the Smartcard IC Platform Protection Profile BSI-PP-0002 version 1.0,
July 2001.
5
The Protection Profile and the Security Target are built on Common Criteria version 2.3.
1.2
z
Title: Security Target of Samsung S3CC9L5 16-bit Secure RISC Microcontroller for Smart Card
with optional Secure RSA and ECC Library including specific IC Dedicated Software
z
Target of Evaluation: S3CC9L5 revision 2
z
Provided by: Samsung Electronics Co., Ltd.
z
Common Criteria version : ISO/IEC 15408-2005(E) (CC V2.3) part 1 to 3
Security Target Overview
6
The Target of Evaluation (TOE), the S3CC9L5 microcontroller featuring the TORNADO™
cryptographic coprocessor, is a smartcard integrated circuit which is composed of a processing unit,
security components, contactless and contact based I/O ports, hardware circuit for testing purpose
during the manufacturing process and volatile and non-volatile memories (hardware). The TOE also
includes any IC Designer/Manufacturer proprietary IC Dedicated Software as long as it physically
exists in the smartcard integrated circuit after being delivered by the IC Manufacturer. Such software
(also known as IC firmware) is used for testing purpose during the manufacturing process but also
provides additional services to facilitate the usage of the hardware and/or to provide additional
services, including optional RSA and/or ECC asymmetric cryptography library and an AIS20
compliant random number generation library. The ECC library further includes the functionality of
hash computation. The ECC library further includes the functionality of hash computation using
SHA1, SHA224 and SHA256 algorithm. The use of these functionalities for keyed hash operations like
HMAC or similar security critical operations involving keys and other secrets, is not subject of this
TOE and requires specific security improvements and DPA analysis including the operating system,
which is not part of this TOE. However, the functionalities of SHA224 and SHA256 computation are
intended to be used for signature generation and verification.
7
Regarding the RSA and ECC library the user has the possibility to tailor this IC Dedicated Software
part of the TOE during the manufacturing process by deselecting the RSA and ECC library. Hence
the TOE can be delivered with or without the functionality of the RSA and ECC library what’s
resulting in four TOE configurations (without RSA and ECC library, with RSA and ECC library, with
ECC library only, with RSA library only). This is considered in this Security Target and a
corresponding note (indicated by “optional”) is added where required. In case the TOE is delivered
including the RSA and ECC library, these optional marked parts have to be considered, otherwise
these parts can be neglected. If the user decides not to use the RSA and ECC library are not delivered
to the user and the accompanying “Additional Specific Security Functionality (O.Add-Functions)”
Rivest-Shamir-Adleman (RSA) and/or Elliptic Curve Cryptography (ECC) is/are not provided by the
TOE. Deselecting the RSA and ECC library means excluding the code implementing functionality,
Version 1.5
Page 4
S3CC9L5
SECURITY TARGET
PUBLIC
which the user decided not to use. Excluding the code of the deselected functionality has no impact on
any other security policy of the TOE, it is exactly equivalent to the situation where the user decides
just not to use the functionality.
Version 1.5
Page 5
S3CC9L5
1.3
8
SECURITY TARGET
PUBLIC
CC Conformance & Evaluation Assurance Level
This security target conforms to Common Criteria version 2.3 (ISO15408) part 2 extended, part 3
conformant and conforms to the Smartcard IC Platform Protection Profile BSI-PP-0002 version 1.0, July
2001. The assurance level is EAL5 augmented with components ALC_DVS.2, AVA_MSU.3 and
AVA_VLA.4. The minimum strength of the TOE security functions is Strength of Functions High
(“SOF high”).
Version 1.5
Page 6
S3CC9L5
SECURITY TARGET
PUBLIC
2 TOE DESCRIPTION
9
This chapter 2 contains the following sections:
2.1 Product Description
2.2 TOE Definition
2.3 TOE Features
2.4 Interface of the TOE
2.5 TOE intended usage
2.1
Product Description
10
The Target of Evaluation (TOE), the S3CC9L5 microcontroller featuring the TORNADO™
cryptographic coprocessor, is a smartcard integrated circuit which is composed of a processing unit,
security components, contactless and contact based I/O ports, hardware circuit for testing purpose
during the manufacturing process and volatile and non-volatile memories (hardware). The TOE also
includes any IC Designer/Manufacturer proprietary IC Dedicated Software as long as it physically
exists in the smartcard integrated circuit after being delivered by the IC Manufacturer. Such software
(also known as IC firmware) is used for testing purpose during the manufacturing process but also
provides additional services to facilitate the usage of the hardware and/or to provide additional
services, including optional RSA and/or ECC asymmetric cryptography library and an AIS20
compliant random number generation library. The ECC library further includes the functionality of
hash computation using SHA1, SHA224 and SHA256 algorithm. The use of these functionalities for
keyed hash operations like HMAC or similar security critical operations involving keys and other
secrets, is not subject of this TOE and requires specific security improvements and DPA analysis
including the operating system, which is not part of this TOE. However, the functionalities of SHA224
and SHA256 computation are intended to be used for signature generation and verification.
11
Regarding the RSA and ECC library the user has the possibility to tailor this IC Dedicated Software
part of the TOE during the manufacturing process by deselecting the RSA and ECC library. Hence
the TOE can be delivered with or without the functionality of the RSA and ECC library what’s
resulting in four TOE configurations (without RSA and ECC library, with RSA and ECC library, with
ECC library only, with RSA library only). This is considered in this Security Target and corresponding
notes (indicated by “optional”) are added where required. If the user decides not to use the RSA and
ECC library the library is not delivered to the user and the accompanying “Additional Specific
Security Functionality (O.Add-Functions)” Rivest-Shamir-Adleman (RSA) and/or Elliptic Curve
Cryptography (ECC) is/are not provided by the TOE. Deselecting the RSA and ECC library means
excluding the code implementing functionality, which the user decided not to use. Excluding the code
of the deselected functionality has no impact on any other security policy of the TOE, it is exactly
equivalent to the situation where the user decides just not to use the functionality.
12
The S3CC9L5 single-chip CMOS micro-controller is designed and packaged specifically for "Smart
Card" applications.
13
The CalmRISC16 CPU architecture of the S3CC9L5 microcontroller follows the Harvard style, that is,
it has separate program memory and data memory. Both instruction and data can be fetched
simultaneously without causing a stall, using separate paths for memory access.
14
The main security features of the S3CC9L5 integrated circuit are:
15
Security sensors or detectors including High and Low Temperature detectors, High and Low
Frequency detectors, High and Low Supply Voltage detectors, Supply Voltage Glitch detectors, Light
detector and the Passivation Removing Detector
16
A Active Shield against physical intrusive attacks
Version 1.5
Page 7
S3CC9L5
SECURITY TARGET
PUBLIC
17
Dedicated tamper-resistant design based on synthesizable glue logic and secure topology
18
Dedicated hardware mechanisms against side-channel attacks such as Internal Variable Clock,
Random Waits Generator, Random Current Generator, RAM and EEPROM Encryption.
19
Secure DES coprocessors for Symmetric Cryptography support
20
Secure Tornado™ coprocessor for RSA and ECC Asymmetric Cryptographic Support
21
A non-deterministic Random Number Generator
22
The IC Dedicated Software includes:
23
A modular arithmetic library v3.7s for RSA Asymmetric Cryptography support (optional)
24
A modular arithmetic library v2.1s for ECC and SHA support (optional)
25
A Deterministic Random Number Generator (DRNG) for AIS20-compliant Random Number
Generation
26
The main hardware blocks of the S3CC9L5 Integrated Circuit are described in Figure 1 below:
I/O L1 L2
Test ROM
8K-byte
CPU
(CalmRISC16)
ROM
256K-byte
EEPROM
18K-byte
Contact &
Contactless
I/O
RNG
MPU
Power-on
Reset
T-DES
Address and Data Bus
RAM
4K-byte
CryptoRAM
2K-byte
Timers
(16-bit Timer/
20-bit W DT)
Clock
IVR
(Internal
Voltage
Regulator)
TORNADO
Crypto
co-processor
27
Detectors &
Security
Control
Vcc
RST
CLK
GND
Figure1. S3CC9L5 Block Diagram
28
29
2.2
30
2.2.1
Note also that only the Triple DES algorithm belongs to the TOE, not the Single DES.
TOE Definition
The TOE consists of the following Hardware and Software:
TOE Hardware
•
18 bytes EEPROM/4K bytes RAM/2K bytes Crypto. RAM/256K User ROM/8K Test ROM
•
16-bit Central Processing Unit (CPU)
•
Internal Voltage Regulator (IVR)
•
Detectors & Security Logic
Version 1.5
Page 8
S3CC9L5
2.2.2
31
SECURITY TARGET
•
A non-deterministic random number generator (RNG)
•
Memory Protection Unit (MPU)
•
Triple DES cryptographic coprocessor with 112 or 168 bits key size
•
TORNADO™ supporting up to 2048-bit RSA and 512-bit ECC key size
•
Hardware UART for contact and contactless I/O modes
•
Address & data buses
•
Internal Clock
•
Timers
PUBLIC
TOE Software
The TOE software comprises the following components:
•
Test ROM code that is used for testing the chip during production
•
The TORNADO RSA secure cryptographic library v3.7s (optional)
TORNADO is Hardware coprocessor for high speed modular multiplications.
The TORNADO RSA Library v3.7s is a software library built on the TORNADO coprocessor that
provides high level interface for RSA cryptographic algorithms.
The functions of the library included in the TOE are:
z
TND_RSA_SigSTD_Secure (RSA signature generation with straighforward
method)
z
TND_RSA_SigCRT_Secure (RSA signature generation with CRT method)
z
TND_RSA_SigCRT_Secure3 (RSA signature generation with CRT method)
z
TND_RSA_Verify (RSA signature verification)
The library supports key sizes from 32 bits to 2048 bit by step of 2 bits. However, only key sizes
from 1280 bits up to 2048 bits are within the scope of this evaluation.
The functions TND_RSA_SigSTD_Secure, TND_RSA_SigCRT_Secure and
TND_RSA_SigCRT_Secure3 features some countermeasures against classical dedicated attacks
such as SPA, DPA, high-order DPA and fault attacks.
•
The TORNADO ECC library provides a set of functions to implement elliptic curve
cryptography algorithms. In particular it provides some function to implement ECDSA signature
and ECDH key exchange protocols. The library implements ECC for prime field and general
curve for bit size from 192 bits to 512 bits and the only certain curves are in the scope of this
evaluation. The functions of the library included in the TOE are:
z
ECDSA_keygen (Generate ephemeral or static key pairs for ECDSA signature
generation or ECDH key agreement)
z
ECDSA_sign_digest (ECDSA signature generation of a digest message byte
string)
z
ECDSA_verify_digest (ECDSA signature verification of a digest message byte
string)
z
ECDH_generate (ECDH key agreement)
The functions ECDSA_keygen and ECDSA_sign_digest have some countermeasure against SPA,
DPA and DFA attacks. The function ECDSA_verify_digest has some countermeasure against
DFA attack. The function ECDH_generate can be used with ephemeral or static private keys. It
has some countermeasure against SPA, DPA and DFA attacks implemented to protect the
private key. The base point is assumed to be public.
Version 1.5
Page 9
S3CC9L5
SECURITY TARGET
PUBLIC
Note1) The ECC library support any valid curve of prime field of size 192 bit to 512 bits. However
standard curves listed below and whose security has been proven are in the scope of this
evaluation.
1) [NIST curves] : Curves P-192, P-224, P-256, P-384
2)[Brainpool curves]:brainpoolP192r1, brainpoolP224r1, brainpoolP256r1, brainpoolP320r1,
brainpoolP384r1, brainpoolP512r1.
The TORNADO ECC library provides the functions for calculating hash (digest) values using
the SHA1, SHA224 and SHA256 algorithm as specified in [FIPS PUB 180-3]:
z
SHA1_init, SHA1_update, SHA1_final,
z
SEC_SHA224_init, SEC_SHA224_update, SEC_SHA224_final,
z
SEC_SHA256_init, SEC_SHA256_update, SEC_SHA256_final.
These functions are not security relevant functions, i.e. they must not be used to hash security va
lues like keys etc. There are no countermeasures against side channel attacks implemented. The
TOE provides the functionality of hash computation if and only if the optional TORNADO ECC
library is delivered.”
•
32
A Deterministic Random Number Generator (DRNG) that fulfills the requirements of AIS 20,
Class K3, Strength of Function High.
The TOE configuration is summarized in table 1 below:
Item Type
Item
Version
S3CC9L5 16-Bit RISC
Microcontroller for Smart
Card
2
Software
Test ROM Code
1.0
Included in S3CC9L5 Test ROM
Software
(optional)
RSA Crypto. Library
3.7s
Software Library
Software
(optional)
ECC Library
2.4s
Software Library
Software
DRNG
2.0
Software Library
Document
Hardware User’s manual
5.0
Softcopy
Document
Security Application Note
1.7
Softcopy
Document
RSA Application Note
1.16
Softcopy
Document
ECC Application Note
2.9
Softcopy
Document
DRNG Application Note
2.0
Softcopy
Document
Delivery Specification
2.4
Softcopy
Hardware
Form of delivery
Wafer or Module
Table1. TOE Configuration
Version 1.5
Page 10
S3CC9L5
33
2.3
SECURITY TARGET
PUBLIC
Note:
The TOE can be delivered without the RSA crypto library and/or ECC library. In this case
the TOE does not provide the Additional Specific Security Functionality Rivest-Shamir-Adleman
Cryptography and/or Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA).
TOE Features
CPU
• 16-bit CalmRISC16 core
Memory
• 256K-byte Program Memory (ROM)
•
8K- byte Test ROM
•
18K-byte Data/Program Memory (EEPROM)
•
4K-byte Data Memory (RAM)
•
2K-byte Crypto Memory (Crypto RAM)
EEPROM Write Operations
• 1 to 128-byte erase/write operation
•
1.5msec erase/write time for each operation
•
Min. 500,000 write/erase cycles
•
Data retention for min. 10 years
•
128-bytes Read-only Area
•
128-bytes non erasable EEPROM (OTP)
Triple DES
• Built-in hardware Triple DES accelerator
•
Circuit for resistance against SPA and DPA attacks
Abnormal Condition Detectors
• Abnormal Voltage/Frequency/Light/Temperature detectors
•
Power glitch detector
•
Inner insulation removal detector
•
Active shield removal detector
Interrupts
• Two interrupt sources and vectors (FIQ,IRQ)
•
Source for FIQ: Invalid memory access
•
Sources for IRQ:
•
SIO Falling edge
•
16-bit Timer
•
Watchdog Timer
•
Contact UART Tx/Rx
•
Contactless Type A Tx
•
Contactless Type A Rx
Version 1.5
Page 11
S3CC9L5
SECURITY TARGET
•
Contactless Type B Tx
•
Contactless Type B Rx
•
Software Interrupts
PUBLIC
Serial I/O Interface
• UART for handling serial I/O interface in accordance with the ISO 7816 communication
protocols
•
Type A and Type B contactless interfaces compliant with the ISO 14443 standard
Reset and Power Down Mode
• Power-on reset and external reset
•
Stop mode
16-Bit Random Number Generator
• One 16-bit RNG with non-deterministic internal oscillator
•
Start/Stop control
Memory Protection Unit
• Read/write access configurable.
•
8 Base/Limit region registers
•
Configurable memory range: 4M bytes areas with 128-byte resolution.
Memory Encryption
• Automatic RAM encryption
•
EEPROM encryption with User-defined value
Timers
• 16-Bit Timer with 8 Bit prescaler
•
20-bit Watchdog Timer
Clock Sources
• External clock: 1 MHz–5 MHz
•
Internal clock: 2MHz–18MHz (non-divided)
Operating Voltage Range
• 1.62 V - 5.5 V
Operating Temperature
• - 25°C to 85°C
Package
• Wafer
•
8-pin COB (compliant with ISO 7816)
Version 1.5
Page 12
S3CC9L5
2.4
2.5
34
SECURITY TARGET
PUBLIC
Interfaces of the TOE
•
The physical interface of the TOE with the external environment is the entire surface of the IC
•
The electrical interface of the TOE with the external environment is made of the chip’s pads
including the Vdd, RESETB, XCLK, GND, IO1, IO2, FUSE, L1 and L2 pads as well as the
contactless radio-frequency interface.
•
The data interface of the TOE is made of the Contact I/O pads and Contactless I/O pads.
•
The software interface of the TOE with the hardware consists of Special Function Registers (SFR)
and CPU instructions.
•
The DRNG interface of the TOE is defined by the DRNG library interface.
•
The RSA interface of the TOE is defined by the RSA library interface (optional).
•
The interface to the ECC and SHA calculations is defined from the ECC library interface
(optional).
TOE Intended Usage
The TOE is dedicated to applications such as:
z
Banking and finance applications for credit or debit cards, electronic purse (stored value cards)
and electronic commerce.
z
Network based transaction processing such a mobile phones (GSM SIM cards), pay TV
(subscriber and pay-per-view cards), communication highways (Internet access and transaction
processing).
z
Transport and ticketing applications (access control cards).
z
Governmental cards (ID cards, health cards, driving licenses).
z
Multimedia applications and Digital Right Management protection.
Version 1.5
Page 13
S3CC9L5
SECURITY TARGET
PUBLIC
3 TOE SECURITY ENVIRONMENT
35
This chapter 3 contains the following sections:
3.1 Definition of Assets
3.2 Assumptions
3.3 Threats
3.4 Organizational Security Policies
3.1
36
37
Definition of Assets
The primary assets to be protected are
•
User’s Data stored in the TOE memories (confidentiality and integrity)
•
Smartcard Embedded Software for (confidentiality and integrity)
•
Correct operation of the TOE (integrity)
Other primary assets are
•
38
3.2
39
Random numbers generated by the TOE (confidentiality and integrity)
Other secondary assets are
•
logical design data,
•
physical design data,
•
IC Dedicated Software, Initialization Data, Pre-personalization Data, TSF data
•
specific development aids,
•
test and characterization related data,
•
material for software development support, and
•
photomasks and products in any form
Assumptions
The following assumptions apply in this Security Target.
A.Process-Card
Protection during Packaging, Finishing and Personalisation
It is assumed that security procedures are used after delivery of the TOE by
the TOE Manufacturer up to delivery to the end-user to maintain
confidentiality and integrity of the TOE and of its manufacturing and test
data (to prevent any possible copy, modification, retention, theft or
unauthorised use).
A.Plat-Appl
Usage of Hardware Platform
The Smartcard Embedded Software is designed so that the requirements
from the following documents are met:
(i)
S3CC9L5 User’s manual
Version 1.5
Page 14
S3CC9L5
SECURITY TARGET
A.Resp-Appl
PUBLIC
(ii)
S3CC9L5 Security application Note
(iii)
TOE application notes, and
(iv)
Results from TOE evaluation reports relevant for the Smartcard
Embedded Software.
Treatment of User Data
All User Data are owned by Smartcard Embedded Software. Therefore, it
must be assumed that security relevant User Data (especially cryptographic
keys) are treated by the Smartcard Embedded Software as defined for the
specific application context.
40
The developer of the Smartcard Embedded Software must ensure the appropriate “Usage of Keydependent Functions (A.Key-Function)” while developing this software in Phase 1 as specified below.
A.Key-Function
Usage of Key-dependent Functions
Key-dependent functions (if any) shall be implemented in the Smartcard
Embedded Software in a way that they are not susceptible to leakage attacks
(as described under T.Leak-Inherent and T.Leak-Forced).
Note that here the routines which may compromise keys when being e
xecuted are part of the Smartcard Embedded Software. In contrast to this the
threats T.Leak-Inherent and T.Leak-Forced address (i) the cryptographic
routines which are part of the TOE and (ii) the processing of User Data
including cryptographic keys.
3.3
41
3.3.1
42
Threats
According to the Protection Profile BSI-PP-0002, section 3.3 there are the following high-level security
concerns:
SC1
Manipulation of User Data and of the Smartcard Embedded Software (while being
executed/processed and while being stored in the TOE’s memories)
SC2
Disclosure of User Data and of the Smartcard Embedded Software (while being processed
and while being stored in the TOE’s memories).
SC3
Deficiency of random numbers.
Standard Threats (referring to SC1 and SC2)
The TOE shall avert the threat “Inherent Information Leakage (T.Leak-Inherent)” as specified below.
T.Leak-Inherent
Inherent Information Leakage
An attacker may exploit information which is leaked from the TOE during
usage of the Smartcard in order to disclose confidential data (User Data or
TSF data).
No direct contact with the Smartcard internals is required here. Leakage
may occur through emanations, variations in power consumption, I/O
characteristics, clock frequency, or by changes in processing time
requirements. One example is the Differential Power Analysis (DPA).
43
The TOE shall avert the threat “Physical Probing (T.Phys-Probing)” as specified below.
Version 1.5
Page 15
S3CC9L5
T.Phys-Probing
SECURITY TARGET
PUBLIC
Physical Probing
An attacker may perform physical probing of the TOE in order (i) to disclose
User Data, (ii) to disclose/reconstruct the Smartcard Embedded Software or
(iii) to disclose other critical operational information especially TSF data.
Physical probing requires direct interaction with the Smartcard Integrated
Circuit internals. Techniques commonly employed in IC failure analysis and
IC reverse engineering efforts may be used. Before that hardware security
mechanisms and layout characteristics need to be identified. Determination
of software design including treatment of User Data may also be a prerequisite.
44
The TOE shall avert the threat “Malfunction due to Environmental Stress (T.Malfunction)” as
specified below.
T.Malfunction
Malfunction due to Environmental Stress
An attacker may cause a malfunction of TSF or of the Smartcard Embedded
Software by applying environmental stress in order to (i) deactivate or
modify security features or functions of the TOE or (ii) deactivate or modify
security functions of the Smartcard Embedded Software. This may be
achieved by operating the Smartcard outside the normal operating
conditions. To exploit this an attacker needs information about the
functional operation.
45
The TOE shall avert the threat “Physical Manipulation (T.Phys-Manipulation)” as specified below.
T.Phys-Manipulation
Physical Manipulation
An attacker may physically modify the Smartcard in order to (i) modify
security features or functions of the TOE, (ii) modify security functions of
the Smartcard Embedded Software or (iii) to modify User Data.
The modification may be achieved through techniques com-monly
employed in IC failure analysis and IC reverse engineering efforts. The
modification may result in the deactivation of a security function. Before
that hardware security mechanisms and layout characteristics need to be
identified. Determination of software design including treatment of User
Data may also be a pre-requisite. Changes of circuitry or data can be
permanent or temporary.
In contrast to malfunctions (refer to T.Malfunction) the attacker requires to
gather significant knowledge about the TOE’s internal construction.
46
The TOE shall avert the threat “Forced Information Leakage (T.Leak-Forced)“ as specified below:
T.Leak-Forced
Forced Information Leakage
An attacker may exploit information which is leaked from the TOE during
usage of the Smartcard in order to disclose confidential data (User Data or
TSF data) even if the information leakage is not inherent but caused by the
attacker.
This threat pertains to attacks where methods described in “Malfunction
due to Environmental Stress” (refer to T.Malfunction) and/or “Physical
Manipulation” (refer to T.Phys-Manipulation) are used to cause leakage
Version 1.5
Page 16
S3CC9L5
SECURITY TARGET
PUBLIC
from signals which normally do not contain significant information about
secrets.
47
The TOE shall avert the threat “Abuse of Functionality (T.Abuse-Func)” as specified below.
T.Abuse-Func
Abuse of Functionality
An attacker may use functions of the TOE which may not used after TOE
Delivery in order to (i) disclose or manipulate User Data, (ii) to manipulate
(explore, bypass, deactivate change) security features or functions of the
TOE or of Smartcard Embedded Software or (iii) to enable an attack.
3.3.2
48
Threats related to Specific Functionality (referring to SC3)
The TOE shall avert the threat “Deficiency of Random Numbers (T.RND)” as specified below.
T.RND
Deficiency of Random Numbers
An attacker may predict or obtain information about random numbers
generated by the TOE for instance because of a lack of entropy of the
random numbers provided.
An attacker may gather information about the produced random numbers
which might be a problem because they may be used for instance to
generate cryptographic keys.
Here the attacker is expected to take advantage of statistical properties of the
random numbers generated by the TOE without specific knowledge about
the TOE’s generator. Malfunctions or premature ageing are also considered
which may assist in getting information about random numbers.
3.3.3
49
Threats related to additional TOE Specific Functionality
The TOE shall avert the additional threat “Memory Access Violation (T.Mem-Access)” as specified
below.
T.Mem-Access
Memory Access Violation
Parts of the Smartcard Embedded Software may cause security violations by
accidentally or deliberately accessing restricted data (which may include
code). Any restrictions are defined by the security policy of the specific
application context and must be implemented by the Smartcard Embedded
Software.
3.4
50
Organizational Security Policies
The IC Developer / Manufacturer must apply the policy “Protection during TOE Development and
Production (P.Process-TOE)” as specified below.
P.Process-TOE
Protection during TOE Development and Production
The TOE Manufacturer must ensure that the development and production
of the Smartcard Integrated Circuit (Phase 2 up to TOE Delivery, refer to
Section 2.1) is secure so that no information is unintentionally made
Version 1.5
Page 17
S3CC9L5
SECURITY TARGET
PUBLIC
available for the operational phase of the TOE. For example, the
confidentiality and integrity of design information and test data shall be
guaranteed; access to samples, development tools and other material shall
be restricted to authorized persons only; scrap will be destroyed etc. This
not only pertains to the TOE but also to all information and material
exchanged with the developer of the Smartcard Embedded Software and
therefore especially to the Smartcard Embedded Software itself. This
includes the delivery (exchange) procedures for Phase 1 and the Phases after
TOE Delivery as far as they can be controlled by the TOE Manufacturer.
An accurate identification must be established for the TOE. This requires
that each instantiation of the TOE carries this unique identification.
51
The TOE provides specific security functionality which can be used by the Smartcard Embedded
Software. In the following specific security functionality is listed which is not derived from threats
identified for the TOE’s environment because it can only be decided in the context of the smartcard
application, against which threats the Smartcard Embedded Software will use the specific security
functionality.
52
The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality
(P.Add-Functions)” as specified below.
P.Add-Functions
Additional Specific Security Functionality
The TOE shall provide the following specific security functionality to the
Smartcard Embedded Software:
53
z
Triple Data Encryption Standard (3DES)
z
Rivest-Shamir-Adleman (RSA) public key asymmetric cryptography
(optional)
z
Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA)
(optional)
Note: The TOE can be delivered without the RSA crypto library and/or
ECC library. In this case the TOE does not provide the Additional Specific Security Functionality
Rivest-Shamir-Adleman Cryptography and/or Elliptic Curve Cryptography (ECC) and Secure Hash
Algorithm (SHA).
Version 1.5
Page 18
S3CC9L5
SECURITY TARGET
PUBLIC
4 SECURITY OBJECTIVES
54
This chapter Security Objectives contains the following sections:
4.1 Security Objectives for the TOE
4.2 Security Objectives for Environment
4.1
55
56
4.1.1
57
Security objectives for the TOE
According to the Protection Profile[BSI-PP-0002] there are the following standard high-level security
goals:
SG1
maintain the integrity of User Data and of the Smartcard Embedded
Software (when being executed/processed and when being stored in the
TOE’s memories)
SG2
maintain the confidentiality of User Data and of the Smartcard Embedded
Software (when being processed and when being stored in the TOE’s
memories).
SG3
provide random numbers.
These standard high-level security goals are refined below by defining security objectives as required
by the Common Criteria. Note that the integrity of the TOE is a mean to reach these objectives.
Standard Security Objectives (referring to SG1 and SG2)
The TOE shall provide “Protection against Inherent Information Leakage (O.Leak-Inherent)” as
specified below.
O.Leak-Inherent
Protection against Inherent Information Leakage
The TOE must provide protection against disclosure of confidential data
(User Data or TSF data) stored and/or processed in the Smartcard IC
z
by measurement and analysis of the shape and amplitude of signals (for
example on the power, clock, or I/O lines) and
z
by measurement and analysis of the time between events found by
measuring signals (for instance on the power, clock, or I/O lines).
This objective pertains to measurements with subsequent complex signal
processing whereas O.Phys-Probing is about direct measurements on
elements on the chip surface. Details correspond to an analysis of attack
scenarios which is not given here.
58
The TOE shall provide “Protection against Physical Probing (O.Phys-Probing)” as specified below.
O.Phys-Probing
Protection against Physical Probing
The TOE must provide protection against disclosure of User Data, against
the disclosure/reconstruction of the Smartcard Embedded Software or
against the disclosure of other critical operational information. This includes
protection against
Version 1.5
Page 19
S3CC9L5
SECURITY TARGET
PUBLIC
z
measuring through galvanic contacts which is direct physical probing
on the chips surface except on pads being bonded (using standard tools
for measuring voltage and current) or
z
measuring not using galvanic contacts but other types of physical
interaction between charges (using tools used in solid-state physics
research and IC failure analysis)
with a prior
z
reverse-engineering to understand the design and its properties and
functions.
The TOE must be designed and fabricated so that it requires a high
combination of complex equipment, knowledge, skill, and time to be able to
derive detailed design information or other information which could be
used to compromise security through such a physical attack.
59
The TOE shall provide “Protection against Malfunctions (O.Malfunction)” as specified below.
O.Malfunction
Protection against Malfunctions
The TOE must ensure its correct operation.
The TOE must prevent its operation outside the normal operating conditions
where reliability and secure operation has not been proven or tested. This is
to prevent errors. The environmental conditions may include voltage, clock
frequency, temperature, or external energy fields.
Remark: A malfunction of the TOE may also be caused using a direct
interaction with elements on the chip surface. This is considered as being a
manipulation (refer to the objective O.Phys-Manipulation) provided that
detailed knowledge about the TOE´s internal construction is required and
the attack is performed in a controlled manner.
60
The TOE shall provide “Protection against Physical Manipulation (O.Phys-Manipulation)” as
specified below.
O.Phys-Manipulation
Protection against Physical Manipulation
The TOE must provide protection against manipulation of the TOE
(including its software and TSF data), the Smartcard Embedded Software
and the User Data. This includes protection against
z
reverse-engineering (understanding the design and its properties and
functions),
z
manipulation of the hardware and any data, as well as
z
controlled manipulation of memory contents (User Data).
The TOE must be designed and fabricated so that it requires a high
combination of complex equipment, knowledge, skill, and time to be able to
derive detailed design information or other information which could be
used to compromise security through such a physical attack.
61
The TOE shall provide “Protection against Forced Information Leakage (O.Leak-Forced)“ as specified
below:
Version 1.5
Page 20
S3CC9L5
O.Leak-Forced
SECURITY TARGET
PUBLIC
Protection against Forced Information Leakage
The Smartcard must be protected against disclosure of confidential data
(User Data or TSF data) processed in the Card (using methods as described
under O.Leak-Inherent) even if the information leakage is not inherent but
caused by the attacker
z
by forcing a malfunction (refer to “Protection against Malfunction due
to Environmental Stress (O.Malfunction)” and/or\
z
by a physical manipulation (refer to “Protection against
Physical Manipulation (O.Phys-Manipulation)”. If this is not the case,
signals which normally do not contain significant information about secrets
could become an information channel for a leakage attack.
62
The TOE shall provide “Protection against Abuse of Functionality (O.Abuse-Func)” as specified below.
O.Abuse-Func
Protection against Abuse of Functionality
The TOE must prevent that functions of the TOE which may not be used
after TOE Delivery can be abused in order (i) to disclose critical User Data,
(ii) to manipulate critical User Data of the Smartcard Embedded Software,
(iii) to manipulate Soft-coded Smartcard Embedded Software or (iv) bypass,
deactivate, change or explore security features or functions of the TOE.
Details depend, for instance, on the capabilities of the Test Features
provided by the IC Dedicated Test Software which are not specified here.
63
The TOE shall provide “TOE Identification (O.Identification)“ as specified below:
O.Identification
TOE Identification
The TOE must provide means to store Initialisation Data and Prepersonalisation Data in its non-volatile memory. The Initialisation Data (or
parts of them) are used for TOE identification.
4.1.2
64
Security Objectives related to Specific Functionality (referring to SG3)
The TOE shall provide “Random Numbers (O.RND)” as specified below.
O.RND
Random Numbers
The TOE will ensure the cryptographic quality of random number
generation. For instance random numbers shall not be predictable and shall
have sufficient entropy.
The TOE will ensure that no information about the produced random
numbers is available to an attacker since they might be used for instance to
generate cryptographic keys.
4.1.3
65
Security Objectives for Added Function
The TOE shall provide “Additional Specific Security Functionality (O.Add-Functions)” as specified
below.
Version 1.5
Page 21
S3CC9L5
O.Add-Functions
SECURITY TARGET
PUBLIC
Additional Specific Security Functionality
The TOE must provide the following specific security functionality to the
Smartcard Embedded Software:
z
Triple Data Encryption Standard (3DES)
z
Rivest-Shamir-Adleman (RSA) public key asymmetric cryptography
(optional)
z
Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA
(optional)
66
Note:
The TOE can be delivered without the RSA crypto library and/or ECC library. In this case
the TOE does not provide the Additional Specific Security Functionality Rivest-Shamir-Adleman
Cryptography and/or Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA).
67
The TOE shall provide “Area based Memory Access Control (O.Mem-Access)” as specified below.
O.Mem-Access
Area based Memory Access Control
The TOE must provide the Smartcard Embedded Software with the
capability to define restricted access memory areas. The TOE must then
enforce the partitioning of such memory areas so that access of software to
memory areas is controlled as required, for example, in a multi-application
environment.
4.2
Security objectives for the Environment
4.2.1
Phase 1
68
The Smartcard Embedded Software shall provide “Usage of Hardware Platform (OE.Plat-Appl)” as
specified below.
OE.Plat-Appl
Usage of Hardware Platform
To ensure that the TOE is used in a secure manner the Smartcard Embedded
Software shall be designed so that the requirements from the following
documents are met:
69
(i)
S3CC9L5 User’s manual
(ii)
S3CC9L5 Security Application Note
(iii)
TOE application notes, and
(iv)
Results from the TOE evaluation reports relevant for the Smartcard
Embedded Software.
The Smartcard Embedded Software shall provide “Treatment of User Data (OE.Resp-Appl)” as
specified below.
OE.Resp-Appl
Treatment of User Data
Version 1.5
Page 22
S3CC9L5
SECURITY TARGET
PUBLIC
Security relevant User Data (especially cryptographic keys) are treated by
the Smartcard Embedded Software as required by the security needs of the
specific application context.
For example the Smartcard Embedded Software will not disclose security
relevant user data to unauthorised users or processes when communicating
with a terminal.
4.2.2
70
Phase 2 up to TOE Delivery
The TOE Manufacturer shall ensure the “Protection during TOE Development and Production
(OE.Process-TOE)” as specified below.
OE.Process-TOE
Protection during TOE Development and Production
The TOE Manufacturer must ensure that the development and production
of the Smartcard Integrated Circuit (Phases 2 and 3 up to TOE Delivery,
refer to Section 2.1) is secure so that no information is unintentionally made
available for the operational phase of the TOE. For example, the
confidentiality and integrity of design information and test data must be
guaranteed, access to samples, development tools and other material must
be restricted to authorised persons only, scrap must be destroyed. This not
only pertains to the TOE but also to all information and material exchanged
with the developer of the Smartcard Embedded Software and therefore
especially to the Smartcard Embedded Software itself. This includes the
delivery (exchange) procedures for Phase 1 and the Phases after TOE
Delivery as far as they can be controlled by the TOE Manufacturer.
An accurate identification must be established for the TOE. This requires
that each instantiation of the TOE carries this unique identification. In order
to make this practical, electronic identification shall be possible.
4.2.3
71
TOE Delivery up to the end of Phase 6
Appropriate “Protection during Packaging, Finishing and Personalisation (OE.Process-Card)” must
be ensured after TOE Delivery up to the end of Phases 6, as well as during the delivery to Phase 7 as
specified below.
OE.Process-Card
Protection during Packaging, Finishing and Personalisation
Security procedures shall be used after TOE Delivery up to delivery to the
end-user to maintain confidentiality and integrity of the TOE and of its
manufacturing and test data (to prevent any possible copy, modification,
retention, theft or unauthoriseduse).
This means that Phases after TOE Delivery up to the end of Phase 6 (refer to
Section 2.1) must be protected appropriately.
4.2.4
72
Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”
Regarding the cryptographic services this objective of the environment has to be clarified. The TOE
supports cipher schemes as additional specific security functionality. If required the Smartcard
Embedded Software shall use these cryptographic services of the TOE and their interface as specified.
When key-dependent functions implemented in the Smartcard Embedded Software are just being
executed, the Smartcard Embedded Software must provide protection against disclosure of
confidential data (User Data) stored and/or processed in the TOE by using the methods described
under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information Leakage (T.LeakForced)“.
Version 1.5
Page 23
S3CC9L5
SECURITY TARGET
PUBLIC
73
Regarding the area based access control this objective of the environment has to be clarified. For the
separation of different applications the Smartcard Embedded Software (Operating System) may
implement a memory management scheme based upon security mechanisms of the TOE.
74
For the separation of different applications the Smartcard Embedded Software may implement a
memory management scheme based upon security mechanisms of the TOE as required by the security
policy defined for the specific application context.
4.2.5
Clarification of “Treatment of User Data (OE.Resp-Appl)”
75
Regarding the cryptographic services this objective of the environment has to be clarified. By
definition cipher or plain text data and cryptographic keys are User Data. The Smartcard Embedded
Software shall treat these data appropriately, use only proper secret keys (chosen from a large key
space) as input for the cryptographic function of the TOE and use keys and functions appropriately in
order to ensure the strength of cryptographic operation.
76
This means that keys are treated as confidential as soon as they are generated. The keys must be
unique with a very high probability, as well as cryptographically strong. For example, it must be
ensured that it is beyond practicality to derive the private key from a public key if asymmetric
algorithms are used. If keys are imported into the TOE and/or derived from other keys, quality and
confidentiality must be maintained. This implies that appropriate key management has to be realised
in the environment.
77
Regarding the area based access control this objective of the environment has to be clarified. The
treatment of User Data is also required when a multi-application operating system is implemented as
part of the Smartcard Embedded Software on the TOE. In this case the multi-application operating
system should not disclose security relevant user data of one application to another application when
it is processed or stored on the TOE.
78
The treatment of User Data is still required when a multi-application operating system is
implemented as part of the Smartcard Embedded Software on the TOE. In this case the multiapplication operating system should not disclose security relevant user data of one application to
another application when it is processed or stored on the TOE.
Version 1.5
Page 24
S3CC9L5
SECURITY TARGET
PUBLIC
5 IT SECURITY REQUIREMENTS
79
This chapter 5 IT Security Requirements contains the following sections:
5.1 TOE Security Requirements
5.2 Security Requirements for the Environment
5.1
TOE security requirements
5.1.1
TOE security functional requirements
80
In order to define the Security Functional Requirements the Part 2 of the Common Criteria was used.
However, some Security Functional Requirements have been newly created and are not taken from
Part 2 of the Common Criteria. Therefore, this Security Target is characterized by “Part 2 extended”.
5.1.1.1 Malfunctions
81
82
The TOE shall meet the requirement “Limited fault tolerance (FRU_FLT.2)” as specified below.
FRU_FLT.2
Limited fault tolerance
Hierarchical to:
FRU_FLT.1
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s capabilities when the
following failures occur: exposure to operating conditions which are not detected
according to the requirement Failure with preservation of secure state (FPT_FLS.1) .
Dependencies:
FPT_FLS.1 Failure with preservation of secure state
Refinement:
The term “failure” above means “circumstances”. The TOE prevents failures
for the “circumstances” defined above.
The TOE shall meet the requirement “Failure with preservation of secure state (FPT_FLS.1)” as
specified below.
FPT_FLS.1
Failure with preservation of secure state
Hierarchical to:
No other components.
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures
occur: exposure to operating conditions which may not be tolerated according to
the requirement Limited fault tolerance (FRU_FLT.2) and where therefore a
malfunction could occur.
Dependencies:
ADV_SPM.1 informal TOE security policy model
Refinement:
The term “failure” above also covers “circumstances”. The TOE prevents
failures for the “circumstances” defined above.
Version 1.5
Page 25
S3CC9L5
83
SECURITY TARGET
PUBLIC
The TOE shall meet the requirement “TSF domain separation” state (FPT_SEP.1)” as specified below.
FPT_SEP.1
TSF domain separation
Hierarchical to:
No other components.
FPT_SEP.1.1
The TSF shall maintain a security domain for its own execution that protects
it from interference and tampering by untrusted subjects.
FPT_SEP.1.2
The TSF shall enforce separation between the security domains of subjects in
the TSC.
Dependencies:
No dependencies.
Refinement:
Those parts of the TOE, which support the security functional requirements
“Limited fault tolerance (FRU_FLT.2)” and “Failure with preservation of
secure state (FPT_FLS.1)” shall be protected from interference of the
Smartcard Embedded Software.
5.1.1.2 Abuse of Functionality
84
85
The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as specified below
(Common Criteria Part 2 extended).
FMT_LIM.1
Limited capabilities
Hierarchical to:
No other components.
FMT_LIM.1.1
The TSF shall be designed in a manner that limits their capabilities so that in
conjunction with “Limited availability (FMT_LIM.2)” the following policy is
enforced: Deploying Test Features after TOE Delivery does not allow User Data to
be disclosed or manipulated, TSF data to be disclosed or manipulated, software to be
reconstructed and no substantial information about construction of TSF to be
gathered which may enable other attacks.
Dependencies:
FMT_LIM.2 Limited availability.
The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified below (Common
Criteria Part 2 extended).
FMT_LIM.2
Limited availability
Hierarchical to:
No other components.
FMT_LIM.2.1
The TSF shall be designed in a manner that limits their availability so that in
conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is
enforced: Deploying Test Features after TOE Delivery does not allow User Data to
be disclosed or manipulated, TSF data to be disclosed or manipulated, software to be
reconstructed and no substantial information about construction of TSF to be
gathered which may enable other attacks.
Dependencies:
FMT_LIM.1 Limited capabilities.
Version 1.5
Page 26
S3CC9L5
86
SECURITY TARGET
PUBLIC
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common
Criteria Part 2 extended).
FAU_SAS.1
Audit storage
Hierarchical to:
No other components.
FAU_SAS.1.1
The TSF shall provide test personnel before TOE Delivery with the
capability to store the Initialisation Data and/or Prepersonalisation Data
and/or supplements of the Smartcard Embedded Software 8 in the audit records.
Dependencies:
No dependencies.
5.1.1.3 Physical Manipulation and Probing
87
The TOE shall meet the requirement “Resistance to physical attack (FPT_PHP.3)” as specified below.
FPT_PHP.3
Resistance to physical attack
Hierarchical to:
No other components.
FPT_PHP.3.1
The TSF shall resist physical manipulation and physical probing 10 to the TSF
by responding automatically such that the TSP is not violated.
Dependencies:
No dependencies.
Refinement:
The TOE will implement appropriate measures to continuously counter
physical manipulation and physical probing. Due to the nature of these
attacks (especially manipulation) the TOE can by no means detect attacks on
all of its elements. Therefore, permanent protection against these attacks is
required ensuring that the TSP could not be violated at any time. Hence,
“automatic response” means here (i) assuming that there might be an attack
at any time and (ii) countermeasures are provided at any time.
11
5.1.1.4 Leakage
88
The TOE shall meet the requirement “Basic internal transfer protection (FDP_ITT.1)” as specified
below.
FDP_ITT.1
Basic internal transfer protection
Hierarchical to:
No other components.
FDP_ITT.1.1
The TSF shall enforce the Data Processing Policy to prevent the disclosure of
user data when it is transmitted between physically-separated parts of the
TOE.
Dependencies:
[FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow
control]
Refinement:
The different memories, the CPU and other functional units of the TOE (e.g.
a cryptographic co-processor) are seen as physically-separated parts of the
TOE.
Version 1.5
Page 27
S3CC9L5
89
SECURITY TARGET
PUBLIC
The TOE shall meet the requirement “Basic internal TSF data transfer protection (FPT_ITT.1)” as
specified below.
FPT_ITT.1
Basic internal TSF data transfer protection
Hierarchical to:
No other components.
FPT_ITT.1.1
The TSF shall protect TSF data from disclosure when it is transmitted
between separate parts of the TOE.
Dependencies:
No dependencies.
Refinement:
The different memories, the CPU and other functional units of the TOE (e.g.
a cryptographic co-processor) are seen as separated parts of the TOE.
This requirement is equivalent to FDP_ITT.1 above but refers to TSF data
instead of User Data. Therefore, it should be understood as to refer to the
same Data Processing Policy defined under FDP_IFC.1 below.
90
The TOE shall meet the requirement “ Subset information flow control (FDP_IFC.1)”as specified
below:
FDP_IFC.1
Subset information flow control
Hierarchical to:
No other components.
FDP_IFC.1.1
The TSF shall enforce the Data Processing Policy on all confidential data when
they are processed or transferred by the TOE or by the Smartcard Embedded
Software.
Dependencies:
FDP_IFF.1 Simple security attributes
Data Processing Policy User Data and TSF data shall not be accessible from the TOE except when
the Smartcard Embedded Software decides to communicate the User Data
via an external interface. The protection shall be applied to confidential data
only but without the distinction of attributes controlled by the Smartcard
Embedded Software.
5.1.1.5 Random Numbers
91
The TOE shall meet the requirement “Quality metric for random numbers (FCS_RND.1)” as specified
below (Common Criteria Part 2 extended).
FCS_RND.1
Quality metric for random numbers
FCS_RND.1.1
The TSF shall provide a mechanism to generate random numbers that meet
the AIS20 version 1, Functional Classes and Evaluation Methodology for
Deterministic Random Number Generators, 2 December 1999, Class K3 Strength
of Function High requirements.
Dependencies:
No dependencies.
Version 1.5
Page 28
S3CC9L5
SECURITY TARGET
PUBLIC
5.1.1.6 Memory access control
92
Usage of multiple applications in one Smartcard often requires separating code and data in order to
prevent that one application can access code and/or data of another application. To support this the
TOE provides Area based Memory Access Control.
93
The security service being provided is described in the Security Function Policy (SFP) Memory Access
Control Policy. The security functional requirement “Subset access control (FDP_ACC.1)” requires
that this policy is in place and defines the scope were it applies. The security functional requirement
“Security attribute based access control (FDP_ACF.1)” defines addresses security attribute usage
and characteristics of policies. It describes the rules for the function that implements the Security
Function Policy (SFP) as identified in FDP_ACC.1. The decision whether an access is permitted or not
is taken based upon attributes allocated to the software. The user software defines the attributes and
memory areas. The corresponding permission control information is evaluated “on-the-fly” by the
hardware so that access is granted/effective or denied/inoperable.
94
The security functional requirement “Static attribute initialization (FMT_MSA.3)” ensures that the
default values of security attributes are appropriately either permissive or restrictive in nature.
Alternative values can be specified by any subject provided that the Memory Access Control Policy
allows that. This is described by the security functional requirement “Management of security
attributes (FMT_MSA.1)”. The attributes are determined during TOE manufacturing (FMT_MSA.3)
or set at run-time (FMT_MSA.1).
95
From TOE´s point of view the different roles in the user software can be distinguished according to
the memory based access control. However the definition of the roles belongs to the user software.
96
The following Security Function Policy (SFP) Memory Access Control Policy is defined for the
requirement “Security attribute based access control (FDP_ACF.1)”:
Memory Access Control Policy
The TOE shall control read, write, delete, execute accesses of software running at
between two different modes (privilege and user mode) on data including code
stored in memory areas.
The TOE shall restrict the ability to define, to change or at least to finally
accept the applied rules (as mentioned in FDP_ACF.1) to software with
privilege mode).
97
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified below.
FDP_ACC.1
Subset access control
Hierarchical to:
No other components.
FDP_ACC.1.1
The TSF shall enforce the Memory Access Control Policy on all subjects (software
with privilege mode and user mode), all objects (data including code stored in
memories) and all the operations defined in the Memory Access Control Policy.
Subjects are software codes in Privilege and User mode.
Object are data stored in ROM, RAM and EEPROM memories.
Dependencies:
98
FDP_ACF.1 Security attribute based access control
The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1)” as
specified below.
FDP_ACF.1
Security attribute based access control
Version 1.5
Page 29
S3CC9L5
SECURITY TARGET
PUBLIC
The attributes are all the operations related to the data stored in memories,
which are the read, write, delete and execute operations.
99
100
101
Hierarchical to:
No other components.
FDP_ACF.1.1
The TSF shall enforce the Memory Access Control Policy to objects based on
the memory area where the software is executed from and/or the memory area where
the access is performed to and/or the operation to be performed.
FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: evaluate the
corresponding permission control information before the access so that accesses to be
denied can not be utilised by the subject attempting to perform the operation.
FDP_ACF.1.3
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none.
Dependencies:
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified below.
FMT_MSA.3
Static attribute initialisation
Hierarchical to:
No other components.
FMT_MSA.3.1
The TSF shall enforce the Memory Access Control Policy to provide well defined
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2
The TSF shall allow any subject (provided that the Memory Access Control Policy
is enforced and the necessary access is therefore allowed) to specify alternative
initial values to override the default values when an object or information is
created.
Dependencies:
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1)” as specified
below:
FMT_MSA.1
Management of security attributes
Hierarchical to:
No other components.
FMT_MSA.1.1
The TSF shall enforce the Memory Access Control Policy to restrict the ability
to change default, modify or delete the security attributes permission control
information to running at privilege mode.
Dependencies:
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
The TOE shall meet the requirement “Specification of management functions (FMT_SMF.1)” as
specified below:
Version 1.5
Page 30
S3CC9L5
SECURITY TARGET
PUBLIC
FMT_SMF.1
Specification of management functions
Hierarchical to:
No other components
FMT_SMF.1.1
The TSF shall be capable of performing the following security management
functions: access the control registers of the MPU.
Dependencies:
No dependencies
5.1.1.7 Cryptographic Support
102
FCS_COP.1n Cryptographic operation requires, a cryptographic operation to be performed in
accordance with a specified algorithm and with a cryptographic key of specified sizes. The specified
algorithm and cryptographic key sizes can be based on an assigned standard.
103
The following additional specific security functionality is implemented in the TOE:
104
Triple Data Encryption Standard (3DES) with 112bit or 168bit key size,
z
Rivest-Shamir-Adleman (RSA) public key asymmetric cryptography, with key size from
1280bit up to 2048bit with a granularity of 2 bits (optional)
z
Elliptic Curve Cryptography (ECC) (optional)
Note:
The TOE can be delivered without the RSA crypto library and/or ECC library. In this case
the TOE does not provide the Additional Specific Security Functionality Rivest-Shamir-Adleman
Cryptography and/or Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm (SHA).
5.1.1.7.1
105
z
Triple-DES Operation
The Triple DES (3DES) operation of the TOE shall meet the requirement “Cryptographic operation
(FCS_COP.1)” as specified below.
FCS_COP.1/3DES
Cryptographic operation
Hierarchical to:
No other components.
FCS_COP.1.1/3DES
The TSF shall perform encryption and decryption in accordance with a
specified cryptographic algorithm Triple Data Encryption Standard (3DES) ECB mode and cryptographic key sizes 112 bit or 168 bit key size that meet the
following standards: [FIPS SP800-67], chapter 2 and 3. TOE implements 3DES
with key option 1 and 2 with ECB mode.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
5.1.1.7.2
106
Rivest-Shamir-Adleman (RSA) operation (optional)
The RSA cryptographic library v3.7s of the TOE shall meet the requirement “Cryptographic operation
(FCS_COP.1)” as specified below.
FCS_COP.1/RSA
Cryptographic operation
Hierarchical to:
No other components
Version 1.5
Page 31
S3CC9L5
FCS_COP.1.1/RSA
SECURITY TARGET
PUBLIC
The TSF shall perform the modular exponentiation part of RSA signature
generation and verification in accordance with a specified cryptographic
algorithm Rivest-Shamir-Adleman (RSA) and cryptographic key sizes from
1280bit up to 2048bit with 2-bit granularity that meet the following standard:
[ISO14888-2:2008] section 6.2 and 6.3.
Note 1) In context of signature generation only the modular exponentiation,
i.e. only Step 2 of [ISO14888-2:2008], section 6.2 are implemented.
Furthermore,
the
functions
TND_RSA_SigSTD_Secure
and
TND_RSA_SigCRT_Secure3 check the length of the message to be
signed. Especially the proper use of a format mechanism
(including the related hash algorithm) is in the responsibility of
the embedded software developer.
Note 2) In context of signature verification only the modular
exponentiation, i.e. only the part asking to compute G* = S^v mod n
in Step 1 of [ISO14888-2:2008], section 6.3 is implemented.
Especially the proper check of a signatures format (including the
related hash algorithm) is in the responsibility of the embedded
software developer.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
107
Version 1.5
Page 32
S3CC9L5
5.1.1.7.3
108
SECURITY TARGET
PUBLIC
Elliptic Curve DSA operation (optional)
The ECC library of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as
specified below.
FCS_COP.1/ECDSA
Cryptographic operation
Hierarchical to:
No other components
FCS_COP.1.1/ECDSA The TSF shall perform signature generation and signature verification in
accordance with a specified cryptographic algorithm ECDSA and
cryptographic key sizes from 192bit up to 512bit that meet the following
standard: [ANS X9.62] , section 7.3 Signing Process and section 7.4 Verifying
Process.
Note1) The ECC library support any valid curve of prime field of size 192
bit to 512 bits. However standard curves listed below and whose
security has been proven are in the scope of this evaluation.
1) [NIST curves]: Curves P-192, P-224, P-256, P-384
2)[Brainpool
curves]:
brainpoolP192r1,
brainpoolP224r1,
brainpoolP256r1,brainpoolP320r1,
brainpoolP384r1,brainpoolP512r1
Note2) The TOE can be delivered without the ECC library. In this case the
TOE does not provide the Additional Specific Security Functionality
Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm
(SHA) realised with the security functional requirements
FCS_COP.1 / ECDSA, FCS_COP.1 / ECDH, FCS_COP.1 / SHA and
FCS_CKM.1 / ECDSA.
Note3) The TOE offers the functionality of hash value computation using
SHA-1, SHA-224 and SHA-256. However, only SHA-224 and SHA256 are intended to be used for signature generation and
verification. Note that neither of the functions must be used to hash
secret values. In addition, the user is responsible for the truncation
or padding of the hash value as required by step e), section 7.3 and
step c), section 7.4.1 of above cited standard.
Note4) According to the above cited standard a ECDSA signature consists
of a pair of numbers, both different from zero. In case that one or
both of these numbers are computed to be zero during the signature
generation process the TOE will return an error. In this case the user
needs to generate a new ephemeral key pair and repeat the
signature generation.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
5.1.1.7.4
109
Elliptic Curve DSA Key generation (optional)
The key generation for the ECC library shall meet the requirement “Cryptographic key generation
(FCS_CKM.1)” as specified below.
Version 1.5
Page 33
S3CC9L5
SECURITY TARGET
FCS_CKM.1/ECDSA
Cryptographic key generation
Hierarchical to:
No other components
PUBLIC
FCS_CKM.1.1/ECDSA The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm specified in [ANS X9.62] and
specified cryptographic key sizes from 192bit up to 512bit that meet the
following standard: [ANS X9.62] , section A.4.3 Elliptic Curve Key Generation.
Note1) The ECC library support any valid curve of prime field of size 192
bit to 512 bits. However standard curves listed below and whose
security has been proven are in the scope of this evaluation.
1) [NIST curves] : Curves P-192, P-224, P-256, P-384
2)[Brainpool
curves]:
brainpoolP192r1,
brainpoolP224r1,
brainpoolP256r1,brainpoolP320r1,
brainpoolP384r1,brainpoolP512r1
Note2) For the generation of the ephemeral key pair the standard requires
the random number generator to be capable of performing a self
check on demand. The implementation of such a self test is in the
responsibility of the user.
Dependencies:
5.1.1.7.5
110
[FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
Elliptic Curve Diffie-Hellman (ECDH) key agreement (optional)
The ECC library of the TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as
specified below.
FCS_COP.1/ECDH
Cryptographic operation
Hierarchical to:
No other components
FCS_COP.1.1/ECDH
The TSF shall perform key exchange in accordance with a specified
cryptographic algorithm ECDH and cryptographic key sizes from 192bit up to
512bit that meet the following standard: [ANS X9.63], section 5.4.1 Standard
Diffie-Hellman primitive.
Note1) The ECC library support any valid curve of prime field of size 192
bit to 512 bits. However standard curves listed below and whose
security has been proven are in the scope of this evaluation.
1) [NIST curves] : Curves P-192, P-224, P-256, P-384
2)[Brainpool
curves]:
brainpoolP192r1,
brainpoolP224r1,
brainpoolP256r1,brainpoolP320r1,
brainpoolP384r1,brainpoolP512r1
Note2) The TOE can be delivered without the ECC library. In this case the
TOE does not provide the Additional Specific Security Functionality
Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm
(SHA) realised with the security functional requirements
FCS_COP.1 / ECDSA, FCS_COP.1 / ECDH, FCS_COP.1 / SHA and
FCS_CKM.1 / ECDSA.
Version 1.5
Page 34
S3CC9L5
SECURITY TARGET
PUBLIC
Note3) The implemented routine can be used with ephemeral or static
private keys. The base point is assumed to be public.
Note4) For full compatibility the user is responsible to perform step 2 of
[ANS X9.63], section 5.2.2.1 prior to using the ECDH_generate
function.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
5.1.1.7.6
111
Secure Hash Algorithm (SHA) (optional)
The Secure Hash Algorithm (SHA) of the TOE shall meet the requirement “Cryptographic operation
(FCS_COP.1)” as specified below.
FCS_COP.1/SHA
Cryptographic operation
Hierarchical to:
No other components
FCS_COP.1.1/SHA
The TSF shall perform secure hash computation in accordance with a specified
cryptographic algorithm SHA1, SHA224 and SHA256 and cryptographic key
sizes none that meet the following standard: [FIPS PUB 180-3].
Note1) The TORNADO ECC library provides the functionalities for
computation of hash values. The use of these functionalities for
keyed hash operations like HMAC or similar, is not subject of this
TOE and requires specific security improvements and DPA analysis
by the operating system which is not part of the TOE. The SHA224
and SHA256 functionalities are intended to be used for signature
generation and verification.
Note2) The TOE can be delivered without the ECC library. In this case the
TOE does not provide the Additional Specific Security Functionality
Elliptic Curve Cryptography (ECC) and Secure Hash Algorithm
(SHA) realised with the security functional requirements
FCS_COP.1 / ECDSA, FCS_COP.1 / ECDH, FCS_COP.1 / SHA and
FCS_CKM.1 / ECDSA.
Dependencies:
5.1.1.7.7
No dependencies
Summary of Security Functional Requirements
Security Functional Requirements
Limited fault tolerance (FRU_FLT.2)
Failure with preservation of secure state (FPT_FLS.1)
TSF Domain Separation (FPT_SEP.1)
Audit storage (FAU_SAS.11)
Version 1.5
Page 35
S3CC9L5
SECURITY TARGET
PUBLIC
Limited capabilities(FMT_LIM.11)
Limited availability (FMT_LIM.21)
Resistance to physical attack (FPT_PHP.3)
Basic internal transfer protection (FDP_ITT.1)
Basic internal TSF data transfer protection (FPT_ITT.1)
Subset information flow control (FDP_IFC.1)
Quality metric for random numbers (FCS_RND.11)
Table2. Security Functional Requirements defined in Smart Card IC Protection Profile
Note 1: Security Functional Requirement coming from Protection Profile BSI-PP-0002 version 1.0, not from
Common Criteria version 2.3 Part 2
Security Functional Requirements
Subset access control (FDP_ACC.1)
Security attribute based access control (FDP_ACF.1)
Static attribute initialization (FMT_MSA.3 )
Management of security attributes (FMT_MSA.1)
Specification of management functions (FMT_SMF.1)
Cryptographic operation (FCS_COP.1/3DES)
Cryptographic operation (FCS_COP.1/RSA) (optional)
Cryptographic operation (FCS_COP.1/ECDSA) (optional)
Cryptographic operation (FCS_COP.1/ECDH) (optional)
Cryptographic key generation (FCS_CKM.1/ ECDSA) (optional)
Cryptographic key generation (FCS_CKM.1/ SHA) (optional)
Table3. Augmented Security Functional Requirements
5.1.2
112
TOE Assurance Requirements
The Security Target to be developed based upon this Protection Profile will be evaluated according to
Security Target evaluation (Class ASE)
113
The TOE Assurance Requirements for the evaluation of the TOE and its development and operating
environment are those taken from the
Evaluation Assurance Level 5 (EAL5)
and augmented by the following components
ALC_DVS.2, AVA_MSU.3 and AVA_VLA.4.
114
corresponding to level “EAL5+”.
115
All refinements from Protection Profile BSI-PP-0002 version 1.0 for the assurance requirements
(ACM_CAP.4, ADO_DEL.2, ADO_IGS.1, AGD_ADM.1, AGD_USR.1, and ATE_COV.2) have to be
taken into consideration.
Version 1.5
Page 36
S3CC9L5
SECURITY TARGET
PUBLIC
Development activities (Class ADV)
Functional Specification (Component ADV_FSP.3)
Security Policy Modelling (Component ADV_SPM.3)
High-Level Design (Component ADV_HLD.3)
Low-Level Design (Component ADV_LLD.1)
Implementation Representation (Component ADV_IMP.2)
TSF internals (Component ADV_INT.1)
Representation Correspondence (Component ADV_RCR.2)
Tests activities (Class ATE)
Coverage (Component ATE_COV.2)
Depth (Component ATE_DPT.2)
Functional Tests (Component ATE_FUN.1)
Independent Testing (Component ATE_IND.2)
Delivery and operation activities (Class ADO)
Delivery (Component ADO_DEL.2)
Installation, generation, and start-up (Component ADO_IGS.1)
Guidance documents activities (Class AGD)
Administrator Guidance (Component AGD_ADM.1)
User guidance (Component AGD_USR.1)
Configuration management activities (Class ACM)
CM automation (Component ACM_AUT.1)
CM Capabilities (Component ACM_CAP.4)
CM Scope (Component ACM_SCP.3)
Life cycle support activities (Class ALC)
Development Security (Component ALC_DVS.2)
Life Cycle Definition (Component ALC_LCD.2)
Tools and Techniques (Component ALC_TAT.2)
Vulnerability assessment activities (Class AVA)
Covert Channel Analysis (Component AVA_CCA.1)
Misuse (Component AVA_MSU.3)
Strength of TOE Security Functions (Component AVA_SOF.1)
Vulnerability Analysis (Component AVA_VLA.4)
5.2
Security Requirements for the Environment
5.2.1
Security Requirements for the IT-Environment
116
The security functional requirement “Cryptographic operation (FCS_COP.1)” met by TOE has the
following dependencies:
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction,
FMT_MSA.2 Secure security attributes.
117
These requirements all address the appropriate management of cryptographic keys used by the
specified cryptographic function. All requirements concerning key management shall be fulfilled by
the environment since the Smartcard Embedded Software is designed for a specific application
context and uses the cryptographic functions provided by the TOE.
Version 1.5
Page 37
S3CC9L5
SECURITY TARGET
PUBLIC
5.2.1.1 Triple DES
118
The environment shall meet the requirement “Import of user data without security attributes
(FDP_ITC.1)” or “Import of user data with security attributes (FDP_ITC.2)” or “Cryptographic key
generation (FCS_CKM.1)” as specified below.
FDP_ITC.1
Import of user data without security attributes
Hierarchical to:
No other components.
FDP_ITC.1.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
FDP_ITC.1.2
The TSF shall ignore any security attributes associated with the user data
when imported from outside the TSC.
FDP_ITC.1.3
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy.
Dependencies:
[FDP_ITC.2 Import of user data with security attributes, or
FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.2
Import of user data with security attributes
Hierarchical to:
No other components.
FDP_ITC.2.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with the imported user
data.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the
imported user data is as intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy.
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FCS_CKM.1
Cryptographic keys generation
Hierarchical to: No other components.
Version 1.5
Page 38
S3CC9L5
119
120
SECURITY TARGET
PUBLIC
FCS_CKM.1.1
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm Triple DES (3DES) and specified
cryptographic key sizes 112 bit or 168 bit that meet the following: [FIPS
SP800-67] Recommendation for the Triple Data Encryption Algorithm (TDEA)
Block Cipher, version 1.1.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
The environment shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as
specified below.
FCS_CKM.4
Cryptographic key destruction
Hierarchical to:
No other components.
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method change key and change key with
certificate verification that meets the following: ISO/IEC 7816.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2
Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FMT_MSA.2 Secure security attributes
The environment shall meet the requirement “Secure security attributes (FMT_MSA.2)” as specified
below.
FMT_MSA.2
Secure security attributes
Hierarchical to:
No other components.
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for security
attributes.
Dependencies:
ADV_SPM.1 Informal TOE security policy model
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
5.2.1.2 RSA (optional)
121
The environment shall meet the requirement “Import of user data without security attributes
(FDP_ITC.1)” or “Import of user data with security attributes (FDP_ITC.2)” or “Cryptographic key
generation (FCS_CKM.1)” as specified below.
FDP_ITC.1
Import of user data without security attributes
Hierarchical to:
No other components.
FDP_ITC.1.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
Version 1.5
Page 39
S3CC9L5
SECURITY TARGET
PUBLIC
FDP_ITC.1.2
The TSF shall ignore any security attributes associated with the user data
when imported from outside the TSC.
FDP_ITC.1.3
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy.
Dependencies:
[FDP_ITC.2 Import of user data with security attributes, or
FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.2
Import of user data with security attributes
Hierarchical to:
No other components.
FDP_ITC.2.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with the imported user
data.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the
imported user data is as intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FCS_CKM.1
Cryptographic keys generation
Hierarchical to:
No other components.
FCS_CKM.1.1
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm rsagen1 and specified cryptographic
key sizes form 1280 up to 2048 bit with 2-bit granularity that meet the
following standards: [ETSI TS 102 176-1], section 6.2.2.1 Key and parameter
generation algorithm rsagen1.
Note 1) the RSA cryptographic key generation of the TOE generate two
primes p and q with equal bit length, where the standard
recommand to generate two primes p and q such that 0.1 <
|log_2(p)-log_2(q)| < 30.
Note 2) The standard specify that the private exponent d shoul be larger
than the square root of the RSA modulus, i.e. d > sqrt(N), this
Version 1.5
Page 40
S3CC9L5
SECURITY TARGET
verification is not performed by the
generation of the TOE.
PUBLIC
RSA cryptographic key
Note 3) RSA cryptographic key generation of the TOE perform a number of
Miller-Rabin test that ensure a probability below 2^-80 for the
prime number generation.
Dependencies:
122
123
[FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
The environment shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as
specified below.
FCS_CKM.4
Cryptographic key destruction
Hierarchical to:
No other components.
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method change key and change key with
certificate verification that meets the following: ISO/IEC 7816.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2
Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FMT_MSA.2 Secure security attributes
The environment shall meet the requirement “Secure security attributes (FMT_MSA.2)” as specified
below.
FMT_MSA.2
Secure security attributes
Hierarchical to:
No other components.
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for security
attributes.
Dependencies:
ADV_SPM.1 Informal TOE security policy model
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
The security functional requirement “Cryptographic key generation (FCS_CKM.1)” met by the TOE
has the following dependencies:
[FDP_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation],
FCS_CKM.4 Cryptographic key destruction,
FMT_MSA.2 Secure security attributes.
FCS_COP.1 is fulfilled by the TOE. FCS_CKM.4 and FMT_MSA.2 has to be fulfilled by the
environment as described above for the RSA algorithm.
Version 1.5
Page 41
S3CC9L5
SECURITY TARGET
PUBLIC
5.2.1.3 ECC (optional)
124
The environment shall meet the requirement “Import of user data without security attributes
(FDP_ITC.1)” or “Import of user data with security attributes (FDP_ITC.2)” or “Cryptographic key
generation (FCS_CKM.1)” as specified below.
FDP_ITC.1
Import of user data without security attributes
Hierarchical to:
No other components.
FDP_ITC.1.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
FDP_ITC.1.2
The TSF shall ignore any security attributes associated with the user data
when imported from outside the TSC.
FDP_ITC.1.3
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy.
Dependencies:
[FDP_ITC.2 Import of user data with security attributes, or
FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.2
Import of user data with security attributes
Hierarchical to:
No other components.
FDP_ITC.2.1
The TSF shall enforce the Access Control Policy or Information Flow Control
Policy when importing user data, controlled under the SFP, from outside of
the TSC.
FDP_ITC.2.2
The TSF shall use the security attributes associated with the imported user
data.
FDP_ITC.2.3
The TSF shall ensure that the protocol used provides for the unambiguous
association between the security attributes and the user data received.
FDP_ITC.2.4
The TSF shall ensure that interpretation of the security attributes of the
imported user data is as intended by the source of the user data.
FDP_ITC.2.5
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: Access Control Policy or
Information Flow Control Policy
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FCS_CKM.1
Cryptographic keys generation (ECDSA)
Hierarchical to: No other components.
Version 1.5
Page 42
S3CC9L5
FCS_CKM.1.1
SECURITY TARGET
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm specified in [ANS X9.62] and
specified cryptographic key sizes from 192bit up to 512bit that meet the
following standard: [ANS X9.62] , section A.4.3 Elliptic Curve Key Generation.
Note)
Dependencies:
PUBLIC
The ECC library support any valid curve of prime field of size 192
bit to 512 bits. However standard curves listed below and whose
security has been proven are in the scope of this evaluation.
1) [NIST curves] : Curves P-192, P-224, P-256, P-384
2)[Brainpool
curves]:
brainpoolP192r1,
brainpoolP224r1,
brainpoolP256r1,brainpoolP320r1,
brainpoolP384r1,brainpoolP512r1
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
125
126
The environment shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as
specified below.
FCS_CKM.4
Cryptographic key destruction
Hierarchical to:
No other components.
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method change key and change key with
certificate verification that meets the following: ISO/IEC 7816.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2
Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FMT_MSA.2 Secure security attributes
The environment shall meet the requirement “Secure security attributes (FMT_MSA.2)” as specified
below.
FMT_MSA.2
Secure security attributes
Hierarchical to:
No other components.
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for security
attributes.
Dependencies:
ADV_SPM.1 Informal TOE security policy model
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
The security functional requirement “Cryptographic key generation (FCS_CKM.1)” met by the TOE
has the following dependencies:
[FDP_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation],
FCS_CKM.4 Cryptographic key destruction,
FMT_MSA.2 Secure security attributes.
Version 1.5
Page 43
S3CC9L5
SECURITY TARGET
PUBLIC
FCS_COP.1 is fulfilled by the TOE. FCS_CKM.4 and FMT_MSA.2 has to be fulfilled by the
environment as described above for the RSA and ECC algorithm.
Note: The TOE can be delivered without the ECC library. In this case the TOE does not provide the
Additional Specific Security Functionality Elliptic Curve Cryptography (ECC) and Secure Hash
Algorithm (SHA) and IT environment has not to be fulfilled the requirement of this chapter.
5.2.2
127
Security Requirements for the Non-IT-Environment
In the following security requirements for the Non-IT-Environment are defined. For the development
of the Smartcard Embedded Software (in Phase 1) the requirement RE.Phase-1 is valid.
RE.Phase-1
Design and Implementation of the Smartcard Embedded Software
The developers shall design and implement the Smartcard Embedded
Software in such way that it meets the requirements from the following
documents:
(i) S3CC9L5 user’s manual,
(ii) Security application note,
(iii) TOE-application notes and
(iv) findings of the TOE evaluation reports relevant for the Smartcard
Embedded Software.
The developers shall implement the Smartcard Embedded Software in a
way that it protects security relevant User Data (especially cryptographic
keys) as required by the security needs of the specific application context.
128
The responsible parties for the Phases 4-6 are required to support the security of the TOE by
appropriate measures:
RE.Process-Card
Protection during Packaging, Finishing and Personalisation
The Card Manufacturer (after TOE Delivery up to the end of Phase 6) shall
use adequate security measures to maintain confidentiality and integrity of
the TOE and of its manufacturing and test data (to prevent any possible
copy, modification, retention, theft or unauthorised use).
129
The Smartcard Embedded Software shall meet the requirements “Cipher Schemas (RE.Cipher)” as
specified below.
RE.Cipher
Cipher Schemas
The developers of Smartcard Embedded Software must not implement
routines in a way, which may compromise keys when the routines are
executed as part of the Smartcard Embedded Software. Performing
functions, which access cryptographic keys could allow an attacker to
misuse these functions to gather information about the key, which is used in
the computation of the function.
Keys must be kept confidential as soon as they are generated. The keys must
be unique with a very high probability, as well as cryptographically strong.
For example, it must be ensured that it is not possible to derive the private
key from a public key if asymmetric algorithms are used. If keys are
imported into the TOE and/or derived from other keys, quality and
confidentiality must be maintained. This implies that an appropriate key
management has to be realised in the environment.
Version 1.5
Page 44
S3CC9L5
SECURITY TARGET
PUBLIC
6 TOE SUMMARY SPECIFICATION
130
This chapter 6 TOE Summary Specification contains the following sections:
6.1 List of Security Functions
6.2 Relationship between security functions and functional requirements
6.3 Assurances Measures
6.1
List of Security Functions
SF1:
Environmental Security violation recording and reaction
1) Detectors
131
These functions records in register the events notified by the detectors (refer to list below). The
software configures the reaction in case of detection:
z
The TOE is immediately reset when an event is detected.
z
Or, a special function register bit is set.
List of detectors:
z
Abnormal frequency Detector
z
Abnormal voltage Detector
z
Abnormal temperature Detector
z
Light Detector
z
Inner insulation removal Detector
z
Active shield removal Detector
z
Power Glitch Detector
2) Filters
132
These filters are used for preventing noise, glitches and extremely high frequency in the external reset
or clock pad from causing undefined or unpredictable behavior of the chip.
z
High Frequency Filter.
z
Reset Noise Filter:
Version 1.5
Page 45
S3CC9L5
SECURITY TARGET
PUBLIC
Specification (typical)
Detectors & Filters
Low
High
Voltage
1.62V and below
5.5V and Above
Frequency
1Mhz and below
5Mhz and Above
Temperature
-25°C and below
+85°C and Above
Power Glitch
Rising & falling time of Power is lower than 400ns
High Frequency Filter
13Mhz and above
Reset Noise Filter
Reset width 1000ns and below
Table4. Detectors & Filters Specification
133
Security Function 1 covers the following Security Functional Requirements:
134
FPT_FLS.1: Failure with preservation of secure state. The detection thresholds of SF1 detectors are
inside the operating range of the TOE. Therefore abnormal events/failures are detected before the
secure state is compromised. This allows to take User’s defined appropriate actions by software or to
immediately RESET the TOE.
135
FRU_FLT.2: Limited fault tolerance. All operating signals (Clock, RESET and supply voltage) are
filtered/regulated in order to prevent malfunction.
136
FPT_SEP.1: TSF domain separation. SF1 filters and detectors are implemented by the hardware. The
filtering and detection cannot be affected or bypassed by Smartcard Embedded Software. The reaction
to the detection can be configured by the software. The influence on security and the way how to
configure it is described in details in the S3CC9L5 User’s Manual. Therefore, FPT_SEP.1 is
implemented by SF1.
137
FPT_PHP.3: Resistance to physical attacks. This requirement is achieved by security feature as the
Active shield must be removed and bypassed in order to perform physical intrusive attacks
138
SF2:
Access Control
1) Security registers access control
139
This security function manages access to the security control registers through access control security
attributes.
140
The USER mode has another function, which is write-enable bit for security related registers. If user
does not enable this bit in 128cycles after the reset, user cannot write security control registers any
more.
2) Invalid address access
141
This function detects invalid address access occurrence. In case of an invalid address access is
detected, an FIQ is evoked. The memory access rights are defined and configured trough the control
register MASCON and the Memory Protection Unit (MPU).
142
The MPU provide the Embedded Software the ability to define different access rights for different
data and program memory areas. In case of an illegal memory access, a non-maskable interrupt (FIQ)
is generated, allowing to take dedicated and appropriate actions.
143
3) Access rights for the code executed in EEPROM
144
This security function manages the code execution in EEPROM, through access control security
attributes. If an invalid access is detected, then a FIQ occurs.
145
Security Function 2 covers the following Security Functional Requirements:
Version 1.5
Page 46
S3CC9L5
SECURITY TARGET
PUBLIC
146
FDP_ACC.1: Subset access control. The MPU allows defining different memory areas with different
access rights.
147
FDP_ACF.1: Security attributes based access control. This is covered by the Privilege and User modes
of the TOE.
148
FMT_MSA.3: Static attribute initialization. All Special Function Registers have DEFAULT values after
Power on Reset.
149
FMT_MSA.1: Management of security attributes. This is achieved with the MPU feature.
150
FMT_SMF.1: Specification of management functions. This is achieved via access to Special Function
Registers.
151
FPT_SEP.1: TSF domain separation. Security domains are maintained since accesses to the accessprohibited area are trapped by this access control function. Therefore, FPT_SEP.1 is implemented by
this SF.
SF3:
Non-reversibility of TEST and NORMAL modes
The NORMAL mode of the TOE consists of PRIVILEGE mode and USER mode (cf. chapter 2.3 of
this document).
1) Non-reversibility of TEST mode and NORMAL mode
152
This function disables the TEST mode and enables the NORMAL mode of the TOE. This function
ensures the non-reversibility of the NORMAL mode. This function is used once during the
manufacturing process.
2) TEST mode communication protocol and data commands
153
This function is the proprietary protocol used to operate the chip in TEST mode. This function
enforces the identification and authentication of the TEST administrator during the test phase of the
manufacturing process. The Strength of this function (SOF) is: High
3) Functional Tests
154
During the manufacturing process, the operation of the TOE and the embedded software checksum
are verified. This security function ensures the correct operation of the TOE security functions and the
integrity of the embedded software.
4) Identification
155
During the TEST mode of manufacturing process, traceability data are written in the non-volatile
memory of the TOE. Once the TOE is switched from TEST to NORMAL mode, those traceability data
are READ ONLY and cannot be modified anymore. This enables to identify and track the TOE during
the rest of its life.
156
Security Function 3 covers the following Security Functional Requirements:
157
FAU_SAS.1: Audit Storage. This is fulfilled by the traceability/identification data written once and for
all during the TEST mode of the manufacturing process.
158
FMT_LIM.1: Limited capabilities. TEST mode can be accessed only by the TEST administrator by
supplying an authentication password through a proprietary protocol.
159
FMT_LIM.2: Limited availability. TEST mode can be accessed only by the TEST administrator by
supplying an authentication password through a proprietary protocol.
160
161
SF4:
Hardware countermeasures for unobservability
This Security Function is ensured by the combination of the following security features.
Version 1.5
Page 47
S3CC9L5
SECURITY TARGET
PUBLIC
1) Static Address/Data scrambling for bus and memory
162
This function protects memory and address/data bus from probing attacks.
2) Memory encryption
163
This security function protects the memory contents of the TOE from data analysis on the stored data
as well as on internally transmitted data. The algorithms used for encryption are proprietary. The
ROM encryption is static key while the RAM and the EEPROM encryption is dynamic key. RAM
encryption is performed automatically while EEPROM encryption is defined and managed by the
embedded software.
3) Synthesizable processor core
164
The Central Processing Unit (CPU) of the TOE is synthesizable with glue logic, which makes reverse
engineering and signal identification more difficult. Most sensitive hardware components such as
buses are also hidden and implemented in deepest layers.
4) De-synchronization and signal-to-noise ratio reduction mechanisms
165
The TOE operations can be made asynchronous by using the Internal Variable Clock and the Random
Wait Generator security features. They make a full range of intrusive (e.g. probing attacks) and non
intrusive attacks (e.g. side-channel attacks) more complex and difficult.
166
Security Function 4 covers the following Security Functional Requirements:
167
FPT_PHP.3: Resistance to physical attacks. This requirement is achieved by bypassed in order to
perform physical intrusive attacks and by security features 1) and 3) that makes the reverseengineering of the TOE layout unpractical.
168
FDP_IFC.1: Subset information flow control. This requirement is covered by security feature 2).
169
FDP_ITT.1: Basic internal transfer protection. This requirement is achieved by the combination of the
TOE security features 1) to 4) as it is unpractical to get access to internal signals and interpret them.
170
FPT_ITT.1: Basic internal TSF data transfer protection. This requirement is achieved by the
combination of the TOE features 1) to 4) as it is unpractical to get access to internal signals and
interpret them.
SF5:
Cryptography
1) Triple Data Encryption Standard Engine
171
This function is used for encrypting and decrypting data using the Triple DES symmetric algorithm
with 112bit or 168bit key size.
2) Random Number Generator
172
This function is used for generating random numbers for security process in smart card applications
and provides a mechanism to generate random numbers. It includes two functions:
z
z
A random SEED Generation algorithm that generates a truly random number
A Digital Random Number Generator (DRNG) algorithm compliant with AIS 20 class K3
SOF High requirements.
3) TORNADO™ RSA Cryptographic Library (optional)
173
This function assists in the acceleration of modulo exponentiations required in the RSA
encryption/decryption algorithm.
174
TORNADO is a high speed modular multiplication coprocessor for RSA public key asymmetric
cryptographic support.
The TORNADO RSA Library is the software built on the TORNADO coprocessor that provides high
level interface for RSA based algorithms.
The functions of the library included in the evaluation are:
z
TND_RSA_SigSTD_Secure (RSA signature generation)
Version 1.5
Page 48
S3CC9L5
SECURITY TARGET
PUBLIC
This function perform RSA signature with standard method (i.e. without CRT). It has several
countermeasure implemented against power analysis attacks, including message blinding and
exponent masking with random data. In addition some redundancy is added when reading the
exponent in order to prevent fault attack.
z
TND_RSA_SigCRT_Secure (RSA signature generation with CRT method)
This function perform RSA signature with CRT. It has several countermeasures implemented
against power analysis attacks based on message blinding and exponent masking with random
data. After computing the signature, verification is done on the result based on the public
exponent that ensures that no fault occurred during computation (prevent fault attacks).This
function uses two pre-computed values based on knowledge of the public exponent. These
values can be calculated with the function TND_RSA_PrecomR.
z
TND_RSA_SigCRT_Secure3 (RSA signature generation with CRT method)
This function perform RSA signature with CRT. It has several countermeasures implemented
against power analysis attacks based on message blinding and exponent masking with random
data. The CRT calculation is performed twice and the result is compared in order to ensure that
no fault occurred during computation (prevent fault attacks). This function does not require the
knowledge of the public exponent.
z
TND_RSA_Verify (RSA signature verification)
The functions TND_RSA_SigSTD_Secure, TND_RSA_SigCRT_Secure and
TND_RSA_SigCRT_Secure3 have some countermeasure against SPA, DPA and DFA attacks.
4) TORNADO™ ECC Cryptographic Library (optional)
175
This function assists in the ECC signature generation, ECC signature verification and in performing a
Diffie-Hellman-Key-Exchange
176
TORNADO is a high speed modular multiplication coprocessor for ECC support.
The TORNADO ECC Library is the software built on the TORNADO coprocessor that provides high
level interface for ECC based algorithms.
The functions of the library included in the evaluation are:
z
ECDSA_keygen (Generate an ephemeral or static key pairs for ECDSA signature)
This function generates an ephemeral public / private key pair for ECDSA signature. It has
countermeasure implemented against power analysis attacks, in particular it uses the fast
Montgomery power ladder algorithm in order to prevent SPA attack
z
ECDSA_sign_digest (ECDSA signature generation of a digest message byte string)
This function calculates the ECDSA signature of a digest message string. It takes as input the
ECDSA key, the ephemeral key, the digest message string as input and return the
corresponding signature.
z
ECDSA_verify_digest (ECDSA signature verification of a digest message byte string)
This function calculates the ECDSA verification of a digest message string. It takes as input the
ECDSA public key, a digest message string and its signature and verify that the signature of the
message is correct.
z
ECDH_generate (ECDH key generation)
This function generates a ephemeral key for ECDH key agreement protocol. It take as input the
ECC group parameter, the user1 ECC secret key, the user2 public key and output the common
shared secret.
The TORNADO ECC library provides the functions for calculating hash (digest) values using the SHA1,
SHA224 and SHA256 algorithm as specified in [FIPS PUB 180-3]:
z
SEC_SHA1_init, SHA1_update, SHA1_final,
Version 1.5
Page 49
S3CC9L5
SECURITY TARGET
PUBLIC
z
SEC_SHA224_init, SEC_SHA224_update, SEC_SHA224_final,
z
SEC_SHA256_init, SEC_SHA256_update, SEC_SHA256_final.
These functions are not security relevant functions, i.e. they must not be used to hash security values
like keys etc. There are no countermeasures against side channel attacks implemented. The TOE
provides the functionality of hash computation if and only if the optional TORNADO ECC library is
delivered.”
177
6.2
178
Relationship between security functions and functional requirements
The following table shows that the set of Security Functions covers all Functional Requirements:
FCS_
SR
FAU_ FDP_ FDP_ FMT_ FMT_ FPT_ FPT_P FPT_ FPT_ FRU_ FDP_ FDP_ FMT_ FMT_ FMT_ FCS_ FCS_ CKM.1
SF
SAS.1 IFC.1 ITT.1 LIM.1 LIM.2 FLS.1 HP.3 ITT.1 SEP.1 FLT.2 ACC.1 ACF.1 MSA.3 MSA.1 SMF.1 RND.1 COP.1 (option
al)
SF1
D D
SF2
SF3
SF4
D D
D
D
D D D D D
D D
D D
D D
D D D
SF5
Table5. Relationship between security function and functional requirement
Version 1.5
Page 50
S3CC9L5
6.3
SECURITY TARGET
PUBLIC
Assurance Measures
Assurance
Class
Assurance
Family
Security
Target
ASE
ACM:
ACM_AUT
1
Configuration
Management
ACM_CAP
4
ACM_SCP
3
ADO:
ADO_DEL
2
Delivery Procedures Documentation (Class ADO)
Delivery and
Operation
ADO_IGS
1
Installation, generation and start-up Procedures
(Class ADO)
ADV_FSP
3
Functional Specification (Class ADV)
ADV_HLD
3
High Level Design (Class ADV)
ADV_INT
1
Modularity (Class ADV)
ADV:
ADV_LLD
1
Low Level Design (Class ADV)
Development
ADV_IMP
2
Implementation (Class ADV)
ADV_RCR
2
All representation correspondence analyses are
included in the relevant TOE representation
documentation (FSP, HLD, LLD, IMP)
ADV_SPM
3
Security Policy Model (Class ADV)
AGD:
AGD_ADM
1
Guidance
Documents
AGD_USR
1
ALC:
ALC_DVS
2
Development Security Procedures (Class ALC)
Life Cycle
Support
ALC_LCD
2
Life Cycle Definition Documentation (Class ALC)
ALC_TAT
2
Development Tool Documentation (Class ALC)
ATE_COV
2
Test Coverage Analysis (Class ATE)
ATE_DPT
2
Test Depth Analysis (Class ATE) is described in Test
Documentation (Class ATE)
ATE_FUN
1
Test Documentation (Class ATE),
AVA_CCA
1
Covert Channel Analysis (Class AVA)
AVA_MSU
3
Analysis of the Guidance Documentation (Class
AVA)
AVA_SOF
1
Strength of TOE SF Analysis (Class AVA)
AVA_VLA
4
Vulnerability Analysis (Class AVA)
ATE:
Tests
AVA:
Vulnerability
Assessment
Assurance
Component
Assurance measure (document reference)
Security Target
Configuration Management Documentation (Class
ACM)
Guidance Documentation (Class AGD)
Table6. Assurance measures table
Version 1.5
Page 51
S3CC9L5
SECURITY TARGET
PUBLIC
7 PP CLAIMS
179
This chapter 7 PP Claims contains the following sections:
7.1 PP Reference
7.2 PP Tailoring
7.3 PP Auditions
7.1
180
7.2
181
7.3
PP reference
This security target conforms to the Smartcard IC Platform Protection Profile [BSI-PP-0002].
PP tailoring
The only tailoring made to the Smartcard IC Platform Protection Profile [BSI-PP-0002] is FCS_RND as
described in section 5.1.1.5.
PP additions
182
Additional objectives and security functional requirements are explicitly mentioned in this Security
Target:
183
One additional assumption A.Key-Function as described in section 3.2
184
One additional threat T.Mem-Access as described in section 3.3.3
185
One additional security policy P.Add-Functions as described in section ST, 3.4.1,
186
Two additional security objectives O.Add-Functions and O.Mem-Access as described in section 4.1.3,
187
Additional functional requirements FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMF.1,
FCS_COP.1, and FCS_CKM.1 (optional) as described in section 5.1.1
188
Additional functional requirements for the environment FDP_ITC.1, FDP_ITC.2, FCS_CKM.1, and
FCS_CKM.4 as described in section 5.1.1.7.5.
189
One additional requirement for the non-IT environment RE.Cipher as described in section 5.2.2.
Version 1.5
Page 52
S3CC9L5
SECURITY TARGET
PUBLIC
8 RATIONALE
190
This chapter 8 Rational contains the following sections:
8.1 Security Objectives Rationale
8.2 Security Requirements Rationale
8.3 Security Requirements are Mutually Supportive and Internally Consistent
8.1
Security Objectives Rationale
Assumption, Threat or
Organisational Security Policy
Security Objective
Note
A.Plat-Appl
OE.Plat-Appl
(Phase 1)
A.Resp-Appl
OE.Resp-Appl
(Phase 1)
P.Process-TOE
OE.Process-TOE
O.Identification
(Phase 2 – 3)
A.Process
OE.Process-Card
Card (Phase 4 – 6)
T.Leak-Inherent
O.Leak- Inherent
T.Phys_Probing
O.Phys-Probing
T.Malfunction
O.Malfunction
T.Phys-Manipulation
O.Phys-Manipulation
T.Leak-Forced
O.Leak-Forced
T.Abuse-Func
O.Abuse-Func
T.RND
O.RND
T.Mem-Access
O.Mem-Access
P.Add-Functions
O.Add-Functions
A.Key-Function
OE.Plat-Appl
OE.Resp-Appl
Table7. Security Objectives versus Assumptions, Threats or Policies
191
The justification related to the assumption “Usage of Hardware Platform (A.Plat-Appl)” is as follows:
192
Since OE.Plat-Appl requires the Smartcard Embedded Software developer to implement those
measures assumed in A.Plat-Appl, the assumption is covered by the objective.
193
The justification related to the assumption “Treatment of User Data (A.Resp-Appl)” is as follows:
194
Since OE.Resp-Appl requires the developer of the Smartcard Embedded Software to implement
measures as assumed in A.Resp-Appl, the assumption is covered by the objective.
195
The justification related to the organisational security policy “Protection during TOE Development
and Production (P.Process-TOE)” is as follows:
196
OE.Process-TOE requires the TOE Manufacturer to implement those measures assumed in P.ProcessTOE. Therefore, the organisational security policy is covered by this objective, as far as organisational
measures are concerned. The only issue not completely covered by these measures is the fact that the
TOE has to support the possibility of unique identification. This is the content of
Version 1.5
Page 53
S3CC9L5
SECURITY TARGET
PUBLIC
O.Identification. Therefore, the organisational security policy is covered by OE.Process-Card and
O.Identification.
197
The justification related to the assumption “Protection during Packaging, Finishing and
Personalisation (A.Process-Card)” is as follows:
198
Since OE.Process-Card requires the Card Manufacturer to implement those measures assumed in
A.Process-Card, the assumption is covered by this objective.
199
The justification related to the threats “Inherent Information Leakage (T.Leak-Inherent)”, “Physical
Probing (T.Phys-Probing)”, “Malfunction due to Environmental Stress (T.Malfunction)”, “Physical
Manipulation (T.Phys-Manipulation)”, “Forced Information Leakage (T.Leak-Forced)“, “Abuse of
Functionality (T.Abuse-Func)” and “Deficiency of Random Numbers (T.RND)” is as follows:
200
For all threats the corresponding objectives are stated in a way, which directly corresponds to the
description of the threat. It is clear from the description of each objective , that the corresponding
threat is removed if the objective is valid. More specifically, in every case the ability to use the attack
method successfully is countered, if the objective holds. The justification related to the threat
“Memory Access Violation (T.Mem-Access)” is as follows:
201
According to O.Mem-Access the TOE must enforce the partitioning of memory areas so that access of
software to memory areas is controlled. Any restrictions are to be defined by the Smartcard
Embedded Software. Thereby security violations caused by accidental or deliberate access to
restricted data (which may include code) can be prevented (refer to T.Mem-Access). The threat
T.Mem-Access is therefore removed if the objective is met.
202
The clarification of “Usage of Hardware Platform (OE.Plat-Appl)” makes clear that it is up to the
Smartcard Embedded Software to implement the memory management scheme by appropriately
administrating the TSF. This is also expressed both in T.Mem-Access and O.Mem-Access. The TOE
shall provide access control functions as a means to be used by the Smartcard Embedded Software.
This is further emphasised by the clarification of “Treatment of User Data (OE.Resp-Appl)” which
reminds that the Smartcard Embedded Software must not undermine the restrictions it defines.
Therefore, the clarifications contribute to the coverage of the threat T.Mem-Access.
203
The justification related to the security objective “Additional Specific Security Functionality
(O.Add-Functions)” is as follows: Since O.Add-Functions requires the TOE to implement exactly the
same specific security functionality as required by P.Add-Functions, the organisational security policy
is covered by the objective.
204
Nevertheless the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.PhysManipulation and O.Leak-Forced define how to implement the specific security functionality required
by P.Add-Functions. (Note that these objectives support that the specific security functionality is
provided in a secure way as expected from P.Add-Functions.) Especially O.Leak-Inherent and
O.Leak-Forced refer to the protection of confidential data (User Data or TSF data) in general. User
Data are also processed by the specific security functionality required by P.Add-Functions.
205
Compared to Smartcard IC Platform Protection Profilea clarification has been made for the security
objective “Usage of Hardware Platform (OE.Plat-Appl)”: If required the Smartcard Embedded
Software shall use these cryptographic services of the TOE and their interface as specified. In addition,
the Smartcard Embedded Software must implement functions which perform operations on keys (if
any) in such a manner that they do not disclose information about confidential data. The non
disclosure due to leakage A.Key-Function attacks is included in this objective OE.Plat-Appl. This
addition ensures that the assumption A.Plat-Appl is still covered by the objective OE.Plat-Appl
although additional functions are being supported according to O.Add-Functions.
206
Compared to Smartcard IC Platform Protection Profilea clarification has been made for the security
objective “Treatment of User Data (OE.Resp-Appl)”: By definition cipher or plain text data and
cryptographic keys are User Data. So, the Smartcard Embedded Software will protect such data if
required and use keys and functions appropriately in order to ensure the strength of cryptographic
operation. Quality and confidentiality must be maintained for keys that are imported and/or derived
from other keys. This implies that appropriate key management has to be realised in the environment.
Version 1.5
Page 54
S3CC9L5
SECURITY TARGET
PUBLIC
That is expressed by the assumption A.Key—Function which is covered from OE.Resp–Appl. These
measures make sure that the assumption A.Resp-Appl is still covered by the security objective
OE.Resp-Appl although additional functions are being supported according to P.Add-Functions.
207
The justification of the additional policy and the additional assumption show that they do not
contradict to the rationale already given in the Protection Profile for the assumptions, policy and
threats defined there.
8.2
Security Requirements Rationale
8.2.1
Rationale for the security functional requirements
Objective
TOE Security Functional Requirements
z
O.Leak-Inherent
O.Phys-Probing
z
FDP_ITT.1 “Basic internal transfer
protection”
FPT_ITT.1 “Basic internal TSF data
transfer protection”
z
FDP_IFC.1“Subset information flow
control”
z
FPT_PHP.3 “Resistance
physical attack”
Security Requirements for the
environment
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software”
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded Software”
z
O.Malfunction
z
z
z
O.PhysManipulation
O.Leak-Forced
FRU_FLT.2 “Limited fault tolerance
FPT_FLS.1 “Failure with
preservation of secure state”
FPT_SEP.1 “TSF domain separation”
FPT_PHP.3 “Resistance to physical
attack”
All requirements listed for O.LeakInherent
z
FDP_ITT.1, FPT_ITT.1, FDP_IFC.1
plus those listed for O.Malfunction and
O.Phys-Manipulation
z
RE.Phase-1 “Design and
Implementation of the Smartcard
Embedded Software” (e. g. by
implementing FDP_SDI.1 Stored
data integrity monitoring)
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software”
FRU_FLT.2, FPT_FLS.1,
FPT_SEP.1,FPT_PHP.3
Version 1.5
Page 55
S3CC9L5
SECURITY TARGET
Objective
TOE Security Functional Requirements
PUBLIC
Security Requirements for the
environment
FMT_LIM.1 “Limited capabilities”
FMT_LIM.2 “Limited availability”
plus those for O.Leak-Inherent,
O.Phys-Probing, O.Malfunction,
z
z
O.Abuse-Func
O.Phys-Manipulation, O.Leak-Forced
z
O.Identification
FDP_ITT.1, FPT_ITT.1, FDP_IFC.1,
FPT_PHP.3, FRU_FLT.2, FPT_FLS.1,
FPT_SEP.1
- FAU_SAS.1 “Audit storage”
z
FCS_RND.1 “Quality metric for
random numbers” plus those for
O.Leak-Inherent, O.Phys-Probing,
O.Malfunction, O.Physmanipulation, O.Leak-Forced
z
FDP_ITT.1, FPT_ITT.1, FDP_IFC.1,
FPT_PHP.3, FRU_FLT.2,
FPT_FLS.1,FPT_SEP.1
z
FAU_SAS.1 “Audit storage”
O.RND
OE.Process-TOE
OE.Process-Card
Version 1.5
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software” (e. g. by
implementing FPT_AMT.1
“Abstract machine testing”)
Assurance Components: Delivery
(ADO_DEL); Installation,
generation, and startup
(ADO_IGS) (using Administrator
Guidance (AGD_ADM), User
guidance
(AGD_USR)); CM automation
(ACM_AUT); CM Capabilities
(ACM_CAP); CM Scope
(ACM_SCP); Development Security
(ALC_DVS); Life Cycle Definition
(ALC_LCD);
Tools and Techniques (ALC_TAT)
RE.Process-Card possibly
supported by RE.Phase-1
Page 56
S3CC9L5
SECURITY TARGET
Objective
PUBLIC
Security Requirements for the
environment
TOE Security Functional Requirements
O.Add-Functions
z
FCS_COP.1 „Cryptographic
operation“
z
FCS_COP.1/SHA (optional)
z
FCS_CKM.1/ECDSA (optional)
z
RE.Phase-1 “Design and
Implementation of the
Smartcard Embedded
Software” with RE.Cipher
RE.Phase-1 “Design and
Implementation of the Smartcard
Embedded Software”
RE.Cipher
OE.Plat-Appl
RE.Phase-1 “Design and
Implementation of the Smartcard
Embedded Software”
RE.Cipher
[FDP_ITC.1 or FDP_ITC.2] (for
3DES and RSA and/or
ECDSA/ECDH (optional))
FCS_CKM.1 (for 3DES and
optionally for RSA and/or ECDSA
(optional))
FCS_CKM.4 (for 3DES and RSA
and/or ECDSA (optional))
OE.Resp-Appl
FMT_MSA.2 (for 3DES and RSA
and/or ECDSA/ECDH (optional))
O.Mem-Access
RE.Phase-1 “Design and
Implementation of the Smartcard
z FDP_ACF.1 “Security attribute based
Embedded Software”
access control”
z
FDP_ACC.1 “Subset access control”
z FMT_MSA.3 “Static attribute
initialisation”
z FMT_MSA.1 “Management of
security attributes”
z FMT_SMF.1 “Specification of
Management Functions”
Table8. Security Objectives versus Assumptions, Threats or Policies
208
The justification related to the security objective “Protection against Inherent Information Leakage
(O.Leak-Inherent)” is as follows:
209
The refinements of the security functional requirements FPT_ITT.1 and FDP_ITT.1 together with the
policy statement in FDP_IFC.1 explicitly require the prevention of disclosure of secret data (TSF data
as well as User Data) when transmitted betweenseparate parts of the TOE or while being processed.
This includes that attackers cannot reveal such data by measurements of emanations, power
consumption or other behaviour of the TOE while data are transmitted between or processed by TOE
parts.
210
Of course this has also to be supported by the Smartcard Embedded Software. For example timing
attacks were possible if the processing time of algorithms implemented in the software would depend
on the content of secret variables. The requirement RE.Phase-1 makes sure that this is avoided.
211
The justification related to the security objective “Protection against Physical Probing (O.PhysProbing)” is as follows:
Version 1.5
Page 57
S3CC9L5
SECURITY TARGET
PUBLIC
212
The scenario of physical probing as described for this objective is explicitly included in the assignment
chosen for the physical tampering scenarios in FPT_PHP.3. Therefore, it is clear that this security
functional requirement supports the objective.
213
It is possible that the TOE needs additional support by the Smartcard Embedded Software (e. g. to
send data over certain buses only with appropriate precautions). If necessary this support is provided
according to RE.Phase-1. Together with this FPT_PHP.3 is suitable to meet the objective.
214
The justification related to the security objective “Protection against Malfunctions (O.Malfunction)” is
as follows:
215
The definition of this objective shows that it covers a situation, where malfunction of the TOE might
be caused by the operating conditions of the TOE (while direct manipulation of the TOE is covered
O.Phys-Manipulation). There are two possibilities in this situation: Either the operating conditions are
inside of the tolerated range or at least one of them is outside of this range. The second case is covered
by FPT_FLS.1, because it states that a secure state is preserved in this case. The first case is covered by
FRU_FLT.2 because it states that the TOE operates correctly under normal (tolerated) conditions. To
support this, FPT_SEP.1 the functions implementing FRU_FLT.2 and FPT_FLS.1 must work
independently so that their operation can not affected by the Smartcard Embedded Software (refer to
the refinement). Therefore, there is no possible instance of conditions under O.Malfunction, which is
not covered.
216
The justification related to the security objective “Protection against Physical Manipulation (O.PhysManipulation)” is as follows:
217
The scenario of physical manipulation as described for this objective is explicitly included in the
assignment chosen for the physical tampering scenarios in FPT_PHP.3. Therefore, it is clear that this
security functional requirement supports the objective.
218
It is possible that the TOE needs additional support by the Embedded Software (for instance by
implementing FDP_SDI.1 to check data integrity with the help of appropriate checksums, refer to
Section 8.2.2). This support is provided according to RE.Phase-1. Together with this FPT_PHP.3 is
suitable to meet the objective.
219
The justification related to the security objective “Protection against Forced Information Leakage
(O.Leak-Forced)“ is as follows:
220
This objective is directed against attacks, where an attacker wants to force an information leakage,
which would not occur under normal conditions. In order to achieve this the attacker has to combine a
first attack step, which modifies the behaviour of the TOE (either by exposing it to extreme operating
conditions or by directly manipulating it) with a second attack step measuring and analysing some
output produced by the TOE. The first step is prevented by the same measures which support
O.Malfunction and O.Phys-Manipulation, respectively. The requirements covering O.Leak-Inherent
also support O.Leak-Forced because they prevent the attacker from being successful if he tries the
second step directly.
221
The justification related to the security objective “Protection against Abuse of Functionality (O.AbuseFunc)” is as follows:
222
This objective states that abuse of functions (especially provided by the IC Dedicated Test Software,
for instance in order to read secret data) must not be possible in Phase 7 of the life-cycle. There are
two possibilities to achieve this: (i) They cannot be used by an attacker (i. e. its availability is limited)
or (ii) using them would not be of relevant use for an attacker (i. e. its capabilities are limited) since
the functions are designed in a specific way. The first possibility is specified by FMT_LIM.2 and the
second one by FMT_LIM.1. Since these requirements are combined to support the policy, which is
suitable to fulfil O.Abuse-Func, both security functional requirements together are suitable to meet
the objective.
223
Other security functional requirements which prevent attackers from circumventing the functions
implementing these two security functional requirements (for instance by manipulating the
hardware) also support the objective.
Version 1.5
Page 58
S3CC9L5
SECURITY TARGET
PUBLIC
224
It was chosen to define FMT_LIM.1 and FMT_LIM.2 explicitly (not using Part 2 of the Common
Criteria) for the following reason: Though taking components from the Common Criteria catalogue
makes it easier to recognise functions, any selection from Part 2 of the Common Criteria would have
made it harder for the reader to understand the special situation meant here. As a consequence, the
statement of explicit security functional requirements was chosen to provide more clarity.
225
The justification related to the security objective “TOE Identification (O.Identification)“ is as follows:
226
Obviously the operations for FAU_SAS.1 are chosen in a way that they require the TOE to provide the
functionality needed for O.Identification. The Initialisation Data (or parts of them) are used for TOE
identification.
227
It was chosen to define FAU_SAS.1 explicitly (not using a given security functional requirement from
Part 2 of the Common Criteria) for the following reason: The security functional requirement
FAU_GEN.1 in Part 2 of the CC requires the TOE to generate the audit data and gives details on the
content of the audit records (for instance data and time). The possibility to use the functions in order
to store securityrelevant data which are generated outside of the TOE, is not covered by the family
FAU_GEN or by other families in Part 2. Moreover, the TOE cannot add time information to the
records, because it has no real time clock. Therefore, the new family FAU_SAS was defined for this
situation.
228
The justification related to the security objective “Random Numbers (O.RND)” is as follows:
229
FCS_RND.1 requires the TOE to provide random numbers of good quality.
230
Other security functional requirements, which prevent physical manipulation and malfunction of the
TOE (see the corresponding objectives listed in the table) support this objective because they prevent
attackers from manipulating or otherwise affecting the random number generator.
231
Random numbers are often used by the Smartcard Embedded Software to generate cryptographic
keys for internal use. Therefore, the TOE must prevent the unauthorised disclosure of random
numbers. Other security functional requirements which prevent inherent leakage attacks, probing and
forced leakage attacks ensure the confidentiality of the random numbers provided by the TOE.
232
Depending on the functionality of specific TOEs the Smartcard Embedded Software will have to
support the objective by providing runtime-tests of the random number generator .Together, these
requirements allow the TOE to provide cryptographically good random numbers and to ensure that
no information about the produced random numbers is available to an attacker.
233
It was chosen to define FCS_RND.1 explicitly, because Part 2 of the Common Criteria does not contain
generic security functional requirements for Random Number generation. (Note that there are
security functional requirements in Part 2 of the Common Criteria, which refer to random numbers.
However, they define requirements only for the authentication context, which is only one of the
possible applications of random numbers.)
234
The justification related to the security objective “Usage of Hardware Platform (OE.Plat-Appl)” is as
follows:
235
RE.Phase-1 requires the Smartcard Embedded Software developer to design and implement the
software in a way, which is suitable to meet OE.Plat-Appl.
236
The justification related to the security objective “Treatment of User Data (OE.Resp-Appl)” is as
follows:
237
RE.Phase-1 requires the developer of the Smartcard Embedded Software to design and implement the
software in a way, which is suitable to meet OE.Resp-Appl.
238
The justification related to the security objective “Protection during TOE Development and
Production (OE.Process-TOE)” is as follows:
239
The objective OE.Process-TOE has mainly to be fulfilled by organisational and other measures, which
the TOE Manufacturer has to implement. These measures are a subset of those measures, which are
examined during the evaluation of the assurance requirements of the classes ACM, AGD, ALC and
ADO. The technical capability of the TOE to store Initialisation Data and/or Pre-personalisation Data
Version 1.5
Page 59
S3CC9L5
SECURITY TARGET
PUBLIC
is provided according to FAU_SAS.1. Together these security requirements are suitable to meet the
objective.
240
The justification related to the security objective “Protection during Packaging, Finishing and
Personalisation (OE.Process-Card)” is as follows:
241
RE.Process-Card requires the Card Manufacturer to use adequate measures to fulfil OE.Process-Card.
Depending on the security needs of the application, the Smartcard Embedded Software may have to
support this for instance by using appropriate authentication mechanisms for personalisation
functions. Therefore, RE.Phase-1 may support RE.Process-Card in fulfilling the objective in addition.
242
The justification related to the security objective “Area based Memory Access Control (O.MemAccess)” is as follows:
243
The security functional requirement “Subset access control (FDP_ACC.1)” with the related Security
Function Policy (SFP) “Memory Access Control Policy” exactly require the implementation of an area
based memory access control, which is a requirement from O.Mem-Access. Therefore, FDP_ACC.1
with its SFP is suitable to meet the security objective.
244
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
functions are used as specified and that the User Data processed by these functions are protected as
defined for the application context. These issues are addressed by the requirement RE.Phase-1. The
TOE only provides the tool to implement the policy defined in the context of the application.
245
The justification related to the security objective “Additional Specific Security Functionality
(O.Add-Functions)” is as follows:
246
The security functional requirement(s) “Cryptographic operation (FCS_COP.1) and FCS_COP.1/
SHA(optional)” exactly require those functions to be implemented which are demanded by
O.Add-Functions. FCS_CKM.1 supports the generation of ECC keys needed for this cryptographic
operations (optional). Therefore, FCS_COP.1 and FCS_CKM.1 are suitable to meet the security
objective.
247
Nevertheless, the developer of the Smartcard Embedded Software must ensure that the additional
functions are used as specified and that the User Data processed by these functions are protected as
defined for the application context. These issues are addressed by the requirement RE.Phase-1 and
more specific by the security functional requirements
248
[FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction,
FMT_MSA.2 Secure security attributes.
249
to be met by the environment.
250
All these requirements have to be fulfilled to support OE.Resp-Appl for the 3DES algorithms and RSA
algorithms. For ECC FCS_CKM.1 is optional, since it is fulfilled by the TOE. Nevertheless the user can
generate keys externally additionally.
251
The security functional requirements required to meet the security objectives O.Leak-Inherent,
O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced define how to implement
the specific security functionality. However, key-dependent functions could be implemented in the
Smartcard Embedded Software. In this case RE.Cipher requires that these functions ensure that
confidential data (User Data) can not be disclosed while they are just being processed by the
Smartcard Embedded Software. Therefore, with respect to the Smartcard Embedded Software the
issues addressed by the objectives just mentioned are addressed by the requirement RE.Cipher.
252
The usage of cryptographic algorithms requires using appropriate keys. Otherwise they do not
provide security. The requirement RE.Cipher addresses these specific issues since cryptographic keys
and other data are provided by the Smartcard Embedded Software. RE.Cipher requires that keys must
be kept confidential. They must be unique with a very high probability, cryptographically strong etc.
If keys are imported into the TOE (usually after TOE Delivery), it must be ensured that quality and
Version 1.5
Page 60
S3CC9L5
SECURITY TARGET
PUBLIC
confidentiality is maintained. Therefore, with respect to the environment the issues addressed (i) by
the objectives just mentioned and (ii) implicitly by O.Add-Functions are addressed by the
requirement RE.Cipher.
253
All these requirements have to be fulfilled to support OE.Resp-Appl for the 3DES and RSA algorithms.
For the ECC algorithm FCS_CKM.1 is optional, since it is fulfilled by the TOE. Nevertheless the user
can generate keys externally additionally.
254
In this ST the objectives for the environment OE.Plat-Appl and OE.Resp-Appl have been clarified. The
requirement for the environment Re.Cipher has been introduced to cover the objectives OE.Plat-Appl
and OE.Resp-Appl (in addition to O.Add-Functions). The Smartcard Embedded Software defines the
use of the cryptographic functions FCS_COP.1 provided by the TOE. RE.Phase-1, which is assigned to
OE. Resp-Appl in the Smartcard IC Platform Protection Profile, requires the Smartcard Embedded
Software Developer to design and implement the software that it protects security relevant User Data
(especially cryptographic keys). The requirements for the environment FDP_ITC.1, FDP_ITC.2,
FCS_CKM.1, FCS_CKM.4, and FMT_MSA.2 support an appropriate key management. These security
requirements are suitable to meet OE.Resp-Appl.
255
The justification of the security objective and the additional requirements (both for the TOE and its
environment) show that they do not contradict to the rationale already given in the Protection Profile
for the assumptions, policy and threats defined there.
8.2.2
Dependencies of security functional requirements
Security Functional
Requirement
Fulfilled by security
requirements
Dependencies
FRU_FLT.2
FPT_FLS.1
Yes
FPT_FLS.1
ADV_SPM.1
Yes (Part of EAL4)
FPT_SEP.1
None
No dependency
FMT_LIM.1
FMT_LIM.2
Yes
FMT_LIM.2
FMT_LIM.1
Yes
FAU_SAS.1
None
No dependency
FPT_PHP.3
None
No dependency
FDP_ITT.1
FDP_ACC.1 or FDP_IFC.1
Yes
FDP_IFC.1
FDP_IFF.1
See discussion below
FPT_ITT.1
None
No dependency
FCS_RND.1
None
No dependency
Version 1.5
Page 61
S3CC9L5
SECURITY TARGET
Security Functional
Requirement
Fulfilled by security
requirements
Dependencies
FCS_CKM.1
FCS_COP.1/3DES
PUBLIC
Yes (by the environment)
FDP_ITC.1 or FDP_ITC.2 (if not Yes (by the environment)
FCS_CKM.1)
FCS_CKM.4
FMT_MSA.2
FCS_CKM.1
FCS_COP.1/RSA
(optional)
Yes (by the environment)
FDP_ITC.1 or FDP_ITC.2 (if not Yes (by the environment)
FCS_CKM.1)
FCS_CKM.4
FMT_MSA.2
FCS_CKM.1
FCS_COP.1/ECDSA
(optional)
Yes
(additionally it can be fulfilled
by the environment)
FDP_ITC.1 or FDP_ITC.2 (if not Yes (by the environment)
FCS_CKM.1)
FCS_CKM.4
FMT_MSA.2
FCS_CKM.1
FCS_COP.1/ECDH
(optional)
Yes
(additionally it can be fulfilled
by the environment)
FDP_ITC.1 or FDP_ITC.2 (if not Yes (by the environment)
FCS_CKM.1)
FCS_CKM.4
FMT_MSA.2
None
No dependency
FDP_ACC.1
FDP_ACF.1
Yes
FDP_ACF.1
FDP_ACC.1
FMT_MSA.3
Yes
Yes
FMT_MSA.3
FMT_MSA.1
FMT_SMR.1
Yes
See discussion below
FMT_MSA.1
FDP_ACC.1 or FDP_IFC.1
FMT_SMR.1
FMT_SMF.1
Yes
See discussion below
Yes
FMT_SMF.1
None
No dependency
FCS_COP.1/SHA
(optional)
FCS_CKM.1/ECDSA
(optional)
FCS_COP.1
FCS_CKM.4
FMT_MSA.2
or
FCS_CKM.2 Yes
See discussion below
See discussion below
Table9. Dependencies of the Security Functional Requirements
The dependencies FCS_CKM.1, FCS_CKM.4 and FMT_MSA.2 are not required for the SHA algorithm,
because the SHA algorithm is a keyless operation. So the environment is not obligated to meet certain
requirements for key management.
Version 1.5
Page 62
S3CC9L5
SECURITY TARGET
PUBLIC
256
Part 2 of the Common Criteria defines the dependency of FDP_IFC.1 (information flow control policy
statement) on FDP_IFF.1 (Simple security attributes). The specification of FDP_IFF.1 would not
capture the nature of the security functional requirement nor add any detail. As stated in the Data
Processing Policy referred to in FDP_IFC.1 there are no attributes necessary. The security functional
requirement for the TOE is sufficiently described using FDP_ITT.1 and its Data Processing Policy
(FDP_IFC.1). Therefore the dependency is considered satisfied.
257
As Table 9 shows, all other dependencies are fulfilled by security requirements defined in this
Protection Profile. The dependencies FCS_CKM.1, FCS_CKM.4 (optional) and FMT_MSA.2 (optional)
must be covered from the environment (the smartcard embedded software).
258
Concerning the requirement FPT_FLS.1 (Failure with preservation of secure state) the TSF shall
preserve a secure state when the following types of failures occur: exposure to operating conditions
which may not be tolerated according to the requirement FRU_FLT.2 (Limited fault tolerance) and
where therefore a malfunction could occur. Here the term “failure” above also covers “circumstances”.
The TOE prevents failures for the “circumstances” defined above. In this context the detection
thresholds of detectors are inside the operating range of the TOE. Therefore abnormal events/failures
are detected before the secure state is compromised. This allows to take user defined appropriate
actions by software or to immediately RESET the TOE (also cf. FPT_FLS.1 related information in the
TSP model).
259
The dependency FMT_SMR.1 introduced by the two components FMT_MSA.1 and FMT_MSA.3 is
considered to be satisfied because the access control specified for the intended TOE is not role-based
but enforced for each subject. Therefore, there is no need to identify roles in form of a security
functional requirement FMT_SMR.1.
8.2.3
Rationale for the Assurance Requirements and the Strength of Function Level
260
The assurance level EAL5 and the augmentation with the requirements ALC_DVS.2, AVA_MSU.3,
and AVA_VLA.4 were chosen in order to meet assurance expectations explained in the following
paragraphs.
261
An assurance level of EAL5 is required for this type of TOE since it is intended to defend against
highly sophisticated attacks without a protected environment. This evaluation assurance level was
selected since it provides even formal evidence on the conducted vulnerability assessment. In order to
provide a meaningful level of assurance that the TOE provides an adequate level of defense against
such attacks, the evaluators have access to all information regarding the TOE including the low level
design and source code.
262
The rationale for the strength of function level from the Smartcard IC Platform Protection Profile is
used as the level is not changed.
ALC_DVS.2 Sufficiency of security measures
263
Development security is concerned with physical, procedural, personnel and other technical measures
that may be used in the development environment to protect the TOE.
264
In the particular case of a Smartcard Integrated Circuit the TOE is developed and produced within a
complex and distributed industrial process which must especially be protected. Details about the
implementation, (e.g. from design, test and development tools as well as Initialization Data) may
make such attacks easier. Therefore, in the case of a Smartcard Integrated Circuit, maintaining the
confidentiality of the design is very important.
265
This assurance component is a higher hierarchical component to EAL5 (which only requires
ALC_DVS.1). ALC_DVS.2 has no dependencies.
AVA_MSU.3 Analysis and testing for insecure states
266
The user guidance must be correct and sufficient to ensure that the TOE can be used in a secure way
and that vulnerabilities are not introduced.
267
This component is included to ensure that misleading, unreasonable and conflicting guidance is
absent from the guidance documentation, and that secure procedures for all modes of operation have
Version 1.5
Page 63
S3CC9L5
SECURITY TARGET
PUBLIC
been addressed. Insecure states should be easy to detect. In this component, an analysis of the
guidance documentation provided by the developer is validated and confirmed through testing by
the evaluator to provide additional assurance.
268
This assurance component is a higher hierarchical component to EAL5 (which only requires
AVA_MSU.2).
269
AVA_MSU.3 has dependencies with ADO_IGS.1 “Installation, generation, and start-up procedures“,
ADV_FSP.1 “Informal functional specification”, AGD_ADM.1 “Administrator guidance” and
AGD_USR.1 “User guidance”. The dependencies are satisfied in EAL5.
AVA_VLA.4 Highly resistant
270
Due to the intended use of the TOE, it must be shown to be highly resistant to penetration attacks.
This assurance requirement is achieved by the AVA_VLA.4 component.
271 Independent vulnerability analysis is based on highly detailed technical information and goes beyond
the vulnerabilities identified by the developer. The main intent of the evaluator analysis is to
determine that the TOE is resistant to penetration attacks performed by an attacker possessing a high
attack potential.
272
AVA_VLA.4 has dependencies with ADV_FSP.1 “Informal functional specification”, ADV_HLD.2
“Security enforcing high-level design”, ADV_LLD.1 “Descriptive low-level design”, ADV_IMP.1
“Subset of the implementation of the TSF”, AGD_ADM.1 “Administrator Guidance”, AGD_USR.1
“User Guidance”.
273
All these dependencies are satisfied by EAL5.
8.3
Security Requirements are Mutually Supportive and Internally Consistent
274
The discussion of security functional requirements and assurance components in the preceding
sections has shown that mutual support and consistency are given for both groups of requirements.
The arguments given for the fact that the assurance components are adequate for the functionality of
the TOE also shows that the security functional requirements and assurance requirements support
each other and that there are no inconsistencies between these groups.
275
The security functional requirement FPT_PHP.3 makes it harder to manipulate User Data and TSF
Data. This protects the primary assets identified in Section 3.1 and other security features or functions
which use these data.
276
Though a manipulation of the TOE (refer to FPT_PHP.3) is not of great value for an attacker in itself, it
can be an important step in order to threaten the primary assets identified in Section 3.1. Therefore,
the security functional requirement FPT_PHP.3 is not only required to meet the security objective
O.Phys-Manipulation. Instead it protects other security features or functions of both the TOE and the
Smartcard Embedded Software from being bypassed, deactivated or changed. In particular this may
pertain to the security features or functions being specified using FDP_ITT.1, FPT_ITT.1, FPT_FLS.1,
FMT_LIM.2, FCS_RND.1, and those implemented in the Smartcard Embedded Software.
277
A malfunction of TSF (refer to FRU_FLT.2 and FPT_FLS.1) can be an important step in order to
threaten the primary assets identified in Section 3.1. Therefore, the security functional requirements
FRU_FLT.2 and FPT_FLS.1 are not only required to meet the security objective O.Malfunction. Instead
they protect other security features or functions of both the TOE and the Smartcard Embedded
Software from being bypassed, deactivated or changed. In particular this pertains to the security
features or functions being specified using FDP_ITT.1, FPT_ITT.1, FMT_LIM.1, FMT_LIM.2,
FCS_RND.1, and those implemented in the Smartcard Embedded Software.
278
In a forced leakage attack the methods described in “Malfunction due to Environmental Stress” (refer
to T.Malfunction) and/or “Physical Manipulation” (refer to T.Phys-Manipulation) are used to cause
leakage from signals which normally do not contain significant information about secrets. Therefore,
in order to avert the disclosure of primary assets identified in Section 3.1 it is important that the
security functional requirements averting leakage (FDP_ITT.1, FPT_ITT.1) and those against
malfunction (FRU_FLT.2 and FPT_FLS.1) and physical manipulation (FPT_PHP.3) are effective and
Version 1.5
Page 64
S3CC9L5
SECURITY TARGET
PUBLIC
bind well. The security features and functions against malfunction ensure correct operation of other
security functions (refer to above) and help to avert forced leakage themselves in other attack
scenarios. The security features and functions against physical manipulation make it harder to
manipulate the other security functions (refer to above).
279
Physical probing (refer to FPT_PHP.3) shall directly avert the disclosure of primary assets identified
in Section 3.1. In addition, physical probing can be an important step in other attack scenarios if the
corresponding security features or functions use secret data. For instance the security functional
requirement FMT_LIM.2 may use passwords. Therefore, the security functional requirement
FPT_PHP.3 (against probing) help to protect other security features or functions including those being
implemented in the Smartcard Embedded Software. Details depend on the implementation.
280
Leakage (refer to FDP_ITT.1, FPT_ITT.1) shall directly avert the disclosure of primary assets identified
in Section 3.1. In addition, inherent leakage and forced leakage (refer to above) can be an important
step in other attack scenarios if the corresponding security features or functions use secret data. For
instance the security functional requirement FMT_LIM.2 may use passwords. Therefore, the security
functional requirements FDP_ITT.1 and FPT_ITT.1 help to protect other security features or functions
implemented in the Smartcard Embedded Software (FDP_ITT.1) or provided by the TOE (FPT_ITT.1).
Details depend on the implementation.
281
According to the assumption Usage of Hardware Platform (A.Plat-Appl) the Smartcard Embedded
Software will correctly use the functions provided by the TOE. Hereby the User Data are treated as
required to meet the requirements defined for the specific application context (refer to Treatment of
User Data (A.Resp-Appl)). However, the TOE may implement additional functions. This can be a risk
if their interface can not completely be controlled by the Smartcard Embedded Software. Therefore,
the security functional requirements FMT_LIM.1 and FMT_LIM.2 are very important. They ensure
that appropriate control is applied to the interface of these functions (limited availability) and that
these functions, if being usable, provide limited capabilities only.
282
The combination of the security functional requirements FMT_LIM.1 and FMT_LIM.2 ensures that
(especially after TOE Delivery) these additional functions can not be abused by an attacker to (i)
disclose or manipulate User Data, (ii) to manipulate (explore, bypass, deactivate or change) security
features or functions of the TOE or of the Smartcard Embedded Software or (iii) to enable an attack.
Hereby the binding between these two security functional requirements is very important:
283
The security functional requirement Limited Capabilities (FMT_LIM.1) must close gaps which could
be left by the control being applied to the function’s interface (Limited Availability (FMT_LIM.2)).
Note that the security feature or function which limits the availability can be bypassed, deactivated or
changed by physical manipulation or a malfunction caused by an attacker. Therefore, if Limited
Availability (FMT_LIM.2) is vulnerable, it is important to limit the capabilities of the functions in
order to limit the possible benefit for an attacker.
284
The security functional requirement Limited Availability (FMT_LIM.2) must close gaps which could
result from the fact that the function’s kernel in principle would allow to perform attacks. The TOE
must limit the availability of functions which potentially provide the capability to disclose or
manipulate User Data, to manipulate security features or functions of the TOE or of the Smartcard
Embedded Software or to enable an attack. Therefore, if an attacker could benefit from using such
functions,it is important to limit their availability so that an attacker is not able to use them.
285
No perfect solution to limit the capabilities (FMT_LIM.1) is required if the limited availability
(FMT_LIM.2) alone can prevent the abuse of functions. No perfect solution to limit the availability
(FMT_LIM.2) is required if the limited capabilities (FMT_LIM.1) alone can prevent the abuse of
functions. Therefore, it is correct that both requirements are defined in a way that they together
provide sufficient security.
286
It is important to avert malfunctions of TSF and of security functions implemented in the Smartcard
Embedded Software (refer to above). There are two security functional requirements which ensure
that malfunctions can not be caused by exposing the TOE to environmental stress. First it must be
ensured that the TOE operates correctly within some limits (Limited fault tolerance (FRU_FLT.2)).
Second the TOE must prevent its operation outside these limits (Failure with preservation of secure
Version 1.5
Page 65
S3CC9L5
SECURITY TARGET
PUBLIC
state (FPT_FLS.1)). Both security functional requirements together prevent malfunctions. The two
functional requirements must define the “limits”. Otherwise there could be some range of operating
conditions which is not covered so that malfunctions may occur. Consequently, the security functional
requirements Limited fault tolerance (FRU_FLT.2) and Failure with preservation of secure state
(FPT_FLS.1) are defined in a way that they together provide sufficient security.
287
The security functional requirements required to meet the security objectives O.Leak-Inherent,
O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the
cryptographic algorithms implemented according to the security functional requirement FCS_COP.1.
Therefore, these security functional requirements support the secure implementation and operation of
FCS_COP.1.
288
The security functional requirements required to meet the security objectives O.Leak-Inherent,
O.Phys-Probing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced also protect the area based
memory access control function implemented according to the security functional requirement
described in the security functional requirement FDP_ACC.1 with reference to the Memory Access
Control Policy and details given in FDP_ACF.1. Therefore, those security functional requirements
support the secure implementation and operation of FDP_ACF.1 with its dependent security
functional requirements.
Version 1.5
Page 66
S3CC9L5
SECURITY TARGET
PUBLIC
9 ANNEX
Glossary
Application Software (AS)
Is the part of ES in charge of the Application of the Smart Card IC.
Basic Software (BS)
Is the part of ES in charge of the generic functions of the Smart Card IC such as Operating System, general
routines and Interpreters.
DAC
Discretionary Access Control
Dedicated Software (DS)
Is defined as the part of ES provided to test the component and/or to manage specific functions of the
component.
Embedded Software (ES)
Is defined as the software embedded in the Smart Card Integrated Circuit. The ES may be in any part of the
non-volatile memories of the Smart Card IC.
Embedded software developer
Institution (or its agent) responsible for the Smart Card embedded software development and the
specification of pre-personalization requirements.
Initialization
Is the process to write specific information in the NVM during IC manufacturing and testing (phase 3) as
well as to execute security protection procedures by the IC manufacturer. The information could contain
protection codes or cryptographic keys.
Initialization Data
Specific information written during manufacturing or testing of the TOE
Integrated Circuit (IC)
Electronic component(s) designed to perform processing and/or memory functions.
IC designer
Institution (or its agent) responsible for the IC development.
Version 1.5
Page 67
S3CC9L5
SECURITY TARGET
PUBLIC
IC manufacturer
Institution (or its agent) responsible for the IC manufacturing, testing, and pre-personalization.
IC packaging manufacturer
Institution (or its agent) responsible for the IC packaging and testing.
Personaliser
Institution (or its agent) responsible for the Smart Card personalization and final testing.
Personalization data
Specific information in the NVM during personalization phase
RBAC
Role-Based Access Control
Security Information
Secret data, initialization data or control parameters for protection system)
Smart Card
A credit sized plastic card, which has a non-volatile memory and a processing unit embedded within it.
Smart Card Issuer
Institution (or its agent) responsible for the Smart Card product delivery to the Smart Card end-user.
Smart Card product manufacturer
Institution (or its agent) responsible for the Smart Card product finishing process and testing.
Smart Card Application Software (AS)
is the part of ES dedicated to the applications
Abbreviations
CC
Common Criteria
EAL
Evaluation Assurance Level
Version 1.5
Page 68
S3CC9L5
SECURITY TARGET
PUBLIC
ECC
Elliptic Curve Cryptography
IT
Information Technology
PP
Protection Profile
SF
Security Function
SHA
Secure Hash Algorithm
SOF
Strength of Function
ST
Security Target
TOE
Target of Evaluation
TSC
TSF Scope of Control
TSF
TOE Security Functions
TSFI
TSF Interface
TSP
TOE Security Policy
Version 1.5
Page 69
S3CC9L5
SECURITY TARGET
PUBLIC
Literature
[ALGO]
Federal Gazette No 19, Notification in accordance with the Electronic Signatures Act and the Electronic
Signatures Ordinance (overview of suitable algorithms), Federal Network Agency for Electricity, Gas,
Telecommunications, Post and Railway, 2008-11-17
[ETSI TS 102 176-1] Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure
Electronic Signatures; Part 1: Hash functions and asymmetric algorithms, 2007-11, version
2.0.0
[FIPS SP800-67] Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, version 1.1
[FIPS PUB 180-3] U.S. Department of Commerce / National Bureau of Standards, Secure Hash Algorithm, FIPS PUB
180-3, 2008-October
[ANS X9.62] American National Standard X9.62-2005, Public Key Cryptography for the Financial Services Industry,
The Elliptic Curve Digital Signature Algorithm (ECDSA), November 16, 2005.
[ANS X9.63] American National Standard X9.63-2001, Public Key Cryptography for the Financial Services Industry:
Key Agreement and Key Transport Using Elliptic Curve Cryptography, November 20, 2001
[ISO14888-2:2008] - Information technology -- Security techniques-- Digital signatures with appendix -- Part 2:
Integer factorization based mechanisms, 2008-04-01
[Brainpool curves]
ECC Brainpool Standard Curves and Curve generation, M. Lochter, v1.0, www.eccbrainpool.org
[NIST curves] Federal Information Processing Standards Publication FIPS PUB 180-3, Digital Signature Standard;
U.S. department of Commerce / National Institute of Standards and Technology (NIST),
June 2009
[BSI-PP-0002] Smartcard IC Platform Protection Profile BSI-PP-0002 version 1.0, July 2001
Version 1.5
Page 70
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement