Security Target: ANSSI_cible2015_60en

Public
Common Criteria
Information Technology
Security Evaluation
S3FT9MF/S3FT9MT/S3FT9MS 16-bit RISC
Microcontroller for Smart Card with optional
Secure RSA and ECC Library including
specific IC Dedicated Software
Class: ASE
Version 7.2
25th August 2015
ST(Security Target)Lite
 2013
Samsung Electronics Co., Ltd. All rights reserved.
Important Notice
Samsung Electronics Co. Ltd. (―Samsung‖) reserves the right
to make changes to the information in this publication at any
time without prior notice. All information provided is for
reference purpose only. Samsung assumes no responsibility
for possible errors or omissions, or for any consequences
resulting from the use of the information contained herein.
This publication on its own does not convey any license,
either express or implied, relating to any Samsung and/or
third-party products, under the intellectual property rights
of Samsung and/or any third parties.
Samsung makes no warranty, representation, or guarantee
regarding the suitability of its products for any particular
purpose, nor does Samsung assume any liability arising out
of the application or use of any product or circuit and
specifically disclaims any and all liability, including without
limitation any consequential or incidental damages.
Customers are responsible for their own products and
applications. "Typical" parameters can and do vary in
different applications. All operating parameters, including
"Typicals" must be validated for each customer application
by the customer's technical experts.
Samsung products are not designed, intended, or authorized
for use in applications intended to support or sustain life, or
for any other application in which the failure of the
Samsung product could reasonably be expected to create a
situation where personal injury or death may occur.
Customers acknowledge and agree that they are solely
responsible to meet all other legal and regulatory
requirements regarding their applications using Samsung
products notwithstanding any information provided in this
Copyright  2013 Samsung Electronics Co., Ltd.
Samsung Electronics Co., Ltd.
San #24 Nongseo-Dong, Giheung-Gu
Yongin-City, Gyeonggi-Do, Korea 446-711
Contact Us: junghyun.kim@samsung.com
Home Page: http://www.samsungsemi.com
publication. Customer shall indemnify and hold Samsung
and its officers, employees, subsidiaries, affiliates, and
distributors harmless against all claims, costs, damages,
expenses, and reasonable attorney fees arising out of, either
directly or indirectly, any claim (including but not limited to
personal injury or death) that may be associated with such
unintended, unauthorized and/or illegal use.
WARNING
No part of this publication may be
reproduced, stored in a retrieval system, or transmitted in
any form or by any means, electric or mechanical, by
photocopying, recording, or otherwise, without the prior
written consent of Samsung. This publication is intended for
use by designated recipients only. This publication contains
confidential information (including trade secrets) of
Samsung protected by Competition Law, Trade Secrets
Protection Act and other related laws, and therefore may not
be, in part or in whole, directly or indirectly publicized,
distributed, photocopied or used (including in a posting on
the Internet where unspecified access is possible) by any
unauthorized third party. Samsung reserves its right to take
any and all measures both in equity and law available to it
and claim full damages against any party that
misappropriates
Samsung’s
trade
secrets
and/or
confidential information.
警 告 本文件仅向经韩国三星电子株式会社授权的人员提供,
其内容含有商业秘密保护相关法规规定并受其保护的三星电
子株式会社商业秘密,任何直接或间接非法向第三人披露、
传播、复制或允许第三人使用该文件全部或部分内容的行为
(包括在互联网等公开媒介刊登该商业秘密而可能导致不特
定第三人获取相关信息的行为)皆为法律严格禁止。此等违
法行为一经发现,三星电子株式会社有权根据相关法规对其
采取法律措施,包括但不限于提出损害赔偿请求。
Chip Handling Guide
Precaution against Electrostatic Discharge
When using semiconductor devices, ensure that the environment is protected against static electricity:
1. Wear antistatic clothes and use earth band.
2. All objects that are in direct contact with devices must be made up of materials that do not produce static
electricity.
3. Ensure that the equipment and work table are earthed.
4. Use ionizer to remove electron charge.
Contamination
Do not use semiconductor products in an environment exposed to dust or dirt adhesion.
Temperature/Humidity
Semiconductor devices are sensitive to:

Environment

Temperature

Humidity
High temperature or humidity deteriorates the characteristics of semiconductor devices. Therefore, do not store or
use semiconductor devices in such conditions.
Mechanical Shock
Do not to apply excessive mechanical shock or force on semiconductor devices.
Chemical
Do not expose semiconductor devices to chemicals because exposure to chemicals leads to reactions that
deteriorate the characteristics of the devices.
Light Protection
In non- Epoxy Molding Compound (EMC) package, do not expose semiconductor IC to bright light. Exposure to
bright light causes malfunctioning of the devices. However, a few special products that utilize light or with
security functions are exempted from this guide.
Radioactive, Cosmic and X-ray
Radioactive substances, cosmic ray, or X-ray may influence semiconductor devices. These substances or rays may
cause a soft error during a device operation. Therefore, ensure to shield the semiconductor devices under
environment that may be exposed to radioactive substances, cosmic ray, or X-ray.
EMS (Electromagnetic Susceptibility)
Strong electromagnetic wave or magnetic field may affect the characteristic of semiconductor devices during the
operation under insufficient PCB circuit design for Electromagnetic Susceptibility (EMS).
Revision History
Version
Date
Modification
1.0
14th December 2013
1.1
02th April 2014
Update the section 1.1 and table 1
3.0
12th June 2014
Update the section 1.1 and table 1
5.0
8th October 2014
7.0
8th July 2015
Update the section 1.2.4 and table 1.
7.1
24th July 2015
Miscellaneous update to conform with PP0084
7.1
24th July 2015
Miscellaneous update to conform with PP0084
7.2
25th August 2015
-
Creation
Update the section 1.1 , table 1 and section6.2 for EAL6+
Added the section 7.2 for EAL6+
Update the chapter 1.2.2, 6.1 and 7.1 for RNG
-
Table of Contents
1 ST INTRODUCTION .................................................................................... 13
1.1 Security Target and TOE Reference ...........................................................................................................14
1.2 TOE Overview and TOE Description ........................................................................................................15
1.2.1 Introduction ........................................................................................................................................15
1.2.2 TOE Definition....................................................................................................................................15
1.2.3 TOE Features ......................................................................................................................................20
1.2.4 TOE Life cycle .....................................................................................................................................21
1.3 Interfaces of the TOE ..................................................................................................................................23
1.4 TOE Intended Usage ..................................................................................................................................23
2 CONFORMANCE CLAIMS........................................................................... 24
2.1 CC Conformance Claim .............................................................................................................................25
2.2 Package Claim ............................................................................................................................................25
2.3 Conformance Claim Rationale ...................................................................................................................25
3 SECURITY PROBLEM DEFINITION ........................................................... 27
3.1 Description of Assets .................................................................................................................................27
3.2 Threats .......................................................................................................................................................29
3.2.1 Standard Threats ................................................................................................................................31
3.2.2 Threats related to security services .....................................................................................................33
3.2.3 Threats related to additional TOE Specific Functionality ...................................................................34
3.2.4 Threats related to Authentication of the Security IC ..........................................................................34
3.3 Organizational Security Policies ................................................................................................................35
3.4 Assumptions ..............................................................................................................................................37
4 SECURITY OBJECTIVES .............................................................................. 39
4.1 Security Objectives for the TOE .................................................................................................................40
4.1.1 Standard Security Objectives ..............................................................................................................41
4.1.2 Security Objectives related to Specific Functionality (referring to SG4) .............................................43
4.1.3 Security Objectives for Added Function .............................................................................................44
4.2 Security Objectives for the Security IC Embedded Software .....................................................................46
4.2.1 Clarification of ―Treatment of User Data (OE.Resp-Appl)‖ ...............................................................46
4.3 Security Objectives for the Operational Environment ...............................................................................46
4.3.1 Clarification of ―Protection during Composite Product Manufacturing (OE.Process-Sec-IC)‖ .........47
4.4 Security Objectives Rationale .....................................................................................................................47
5 EXTENDED COMPONENTS DEFINITION ................................................. 51
5.1 Definition of the Family FCS_RNG ............................................................................................................52
5.2 Definition of the Family FMT_LIM ............................................................................................................53
5.3 Definition of the Family FAU_SAS ............................................................................................................55
5.4 Definition of the Family FDP_SDC ............................................................................................................56
5.5 Definition of the Family FIA_API ..............................................................................................................57
6 IT SECURITY REQUIREMENTS .................................................................. 59
6.1 Security Functional Requirements for the TOE .........................................................................................60
6.1.1 Malfunctions .......................................................................................................................................60
6.1.2 Abuse of Functionality .......................................................................................................................60
6.1.3 Physical Manipulation and Probing ...................................................................................................61
6.1.4 Leakage ...............................................................................................................................................62
6.1.5 Random Numbers (DTRNG FRO) ......................................................................................................63
6.1.6 Memory Access Control .....................................................................................................................64
6.1.7 Cryptographic Support.......................................................................................................................66
6.1.8 Triple-DES Operation .........................................................................................................................66
6.1.9 AES Operation ....................................................................................................................................67
6.1.10 Rivest-Shamir-Adleman (RSA) Operation (optional) .......................................................................67
6.1.11 Rivest-Shamir-Adleman (RSA) Key Generation (optional) ..............................................................67
6.1.12 Elliptic Curve DSA Operation (optional) .........................................................................................68
6.1.13 Elliptic Curve DSA Key Generation (optional).................................................................................68
6.1.14 Elliptic Curve Diffie-Hellman (ECDH) Key Agreement (optional) ..................................................68
6.1.15 Secure Hash Algorithm (SHA) (optional) .........................................................................................69
6.1.16 Bootloader ........................................................................................................................................69
6.1.17 Authentication Proof of Identity.......................................................................................................72
6.1.18 Summary of Security Functional Requirements ...............................................................................72
6.2 TOE Assurance Requirements ...................................................................................................................74
6.3 Security Requirements Rationale ...............................................................................................................76
6.3.1 Rationale for the Security Functional Requirements ..........................................................................76
6.3.2 Dependencies of Security Functional Requirements ..........................................................................81
6.3.3 Rationale for the Assurance Requirements ........................................................................................84
6.3.4 Security Requirements are Internally Consistent ...............................................................................84
7 TOE SUMMARY SPECIFICATION .............................................................. 87
7.1 List of Security Functional Requirements ..................................................................................................88
7.2 Architectural Design Summary .................................................................................................................91
8 ANNEX ........................................................................................................... 92
8.1 Glossary .....................................................................................................................................................92
8.2 Abbreviations .............................................................................................................................................94
8.3 References ..................................................................................................................................................95
List of Figures
Figure
Number
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Title
Page
Number
S3FT9MF/S3FT9MT/S3FT9MS Block Diagram ......................................................................................16
Definition of ―TOE Delivery‖ and responsible Parties ............................................................................22
Standard Threats ......................................................................................................................................30
Threats related to security service ...........................................................................................................30
Interactions between the TOE and its outer world ..................................................................................31
Policies .....................................................................................................................................................35
Assumptions ............................................................................................................................................37
Standard Security Objectives ...................................................................................................................40
Security Objectives related to Specific Functionality ...............................................................................41
List of Tables
Table
Number
Table 1.
Table 4
Table 5
Table 6
Table 7:
Table 8
Title
Page
Number
TOE Configuration ...................................................................................................................................20
Security Objectives versus Assumptions, Threats or Policies ..................................................................48
Security Functional Requirements defined in Smart Card IC Protection Profile ....................................72
Augmented Security Functional Requirements .......................................................................................73
Security Requirements versus Security Objectives .................................................................................77
Dependencies of the Security Functional Requirements .........................................................................82
List of Conventions
Register RW Access Type Conventions
Type
Definition
Description
R
Read Only
The application has permission to read the Register field. Writes to read-only fields
have no effect.
W
Write Only
The application has permission to write in the Register field.
RW
Read & Write
The application has permission to read and writes in the Register field. The
application sets this field by writing 1’b1 and clears it by writing 1’b0.
Register Value Conventions
Expression
Description
x
Undefined bit
X
Undefined multiple bits
?
Undefined, but depends on the device or pin status
Device dependent
Pin value
The value depends on the device
The value depends on the pin status
Reset Value Conventions
Expression
Warning:
Description
0
Clears the register field
1
Sets the register field
x
Don't care condition
Some bits of control registers are driven by hardware or write operation only. As a result the
indicated reset value and the read value after reset might be different.
List of Terms
Terms
Descriptions
Application Data
All data managed by the Security IC Embedded Software in the application context.
Application data comprise all data in the final Security IC.
Composite Product
Integrator
Role installing or finalising the IC Embedded Software and the applications on
platform transforming the TOE into the unpersonalised Composite Product after TOE
delivery. The TOE Manufacturer may implement IC Embedded Software delivered by
the Security IC Embedded Software Developer before TOE delivery (e.g. if the IC
Embedded Software is implemented in ROM or is stored in the non-volatile memory as
service provided by the IC Manufacturer or IC Packaging Manufacturer)
Composite Product
Manufacturer
The Composite Product Manufacturer has the following roles (i) the Security IC
Embedded Software Developer (Phase 1), (ii) the Composite Product Integrator (Phase
5) and (iii) the Personaliser (Phase 6). If the TOE is delivered after Phase 3 in form of
wafers or sawn wafers (dice) he has the role of the IC Packaging Manufacturer (Phase
4) in addition.
End-consumer
User of the Composite Product in Phase 7.
IC Dedicated
Software
IC proprietary software embedded in a Security IC (also known as IC firmware) and
developed by the IC Developer. Such software is required for testing purpose (IC
Dedicated Test Software) but may provide additional services to facilitate usage of the
hardware and/or to provide additional services (IC Dedicated Support Software).
IC Dedicated Test
Software
That part of the IC Dedicated Software (refer to above) which is used to test the TOE
before TOE Delivery but which does not provide any functionality thereafter.
IC Dedicated
Support Software
That part of the IC Dedicated Software (refer to above) which provides functions after
TOE Delivery. The usage of parts of the IC Dedicated Software might be restricted to
certain phases.
Initialisation Data
Initialisation Data defined by the TOE Manufacturer to identify the TOE and to keep
track of the Security IC’s production and further life-cycle phases are considered as
belonging to the TSF data. These data are for instance used for traceability and for TOE
identification (identification data).
Integrated Circuit
(IC)
Electronic component(s) designed to perform processing and/or memory functions.
Pre-personalisation
Data
Any data supplied by the Card Manufacturer that is injected into the non-volatile
memory by the Integrated Circuits manufacturer (Phase 3). These data are for instance
used for traceability and/or to secure shipment between phases.
Security IC
Composition of the TOE, the Security IC Embedded Software, User Data and the
package (the Security IC carrier).
Security IC
Embedded Software
Software embedded in a Security IC and normally not being developed by the IC
Designer. The Security IC Embedded Software is designed in Phase 1 and embedded
into the Security IC in Phase 3 or in later phases of the Security IC product life-cycle.
Some part of that software may actually implement a Security IC application others
may provide standard services. Nevertheless, this distinction doesn’t matter here so
that the Security IC Embedded Software can be considered as being application
dependent whereas the IC Dedicated Software is definitely not.
Security IC Product
Composite product which includes the Security Integrated Circuit (i.e. the TOE) and
the Embedded Software and is evaluated as composite target of evaluation in the sense
of the Supporting Document
TOE Delivery
The period when the TOE is delivered which is either (i) after Phase 3 (or before Phase
4) if the TOE is delivered in form of wafers or sawn wafers (dice) or (ii) after Phase 4 (or
before Phase 5) if the TOE is delivered in form of packaged products.
TOE Manufacturer
The TOE Manufacturer must ensure that all requirements for the TOE and its
development and production environment are fulfilled. The TOE Manufacturer has the
following roles: (i) IC Developer (Phase 2) and (ii) IC Manufacturer (Phase 3). If the
TOE is delivered after Phase 4 in form of packaged products, he has the role of the (iii)
IC Packaging Manufacturer (Phase 4) in addition.
TSF data
Data created by and for the TOE, that might affect the operation of the TOE. This
includes information about the TOE’s configuration, if any is coded in non-volatile nonprogrammable memories (ROM), in specific circuitry, in non-volatile programmable
memories (for instance E2PROM) or a combination thereof.
User data
All data managed by the Smartcard Embedded Software in the application context.
User data comprise all data in the final Smartcard IC except the TSF data.
List of Acronyms
Acronyms
Descriptions
CC
Common Criteria
EAL
Evaluation Assurance Level
IT
Information Technology
PP
Protection Profile
ST
Security Target
TOE
Target of Evaluation
TSC
TSF Scope of Control
TSF
TOE Security Feature
TSFI
TSF Interface
TSP
TOE Security Policy
Samsung Confidential
ST Lite Ver7.2
1
1
1 ST INTRODUCTION
ST INTRODUCTION
This introductory chapter contains the following sections:
1.1 Security Target and TOE Reference
1.2 TOE Overview and TOE Description
1.3 Interfaces of the TOE
1.4 TOE Intended Usage
13/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
1.1 Security Target and TOE Reference
2
The Security Target Lite version is 7.2 and dated 25th August 2015
The Security Target is strictly compliant to
3
[5] Eurosmart Security IC Platform Protection Profile with Augmentation Packages, Version 1.0, BSI-CCPP-0084-2014.
4
The Protection Profile and the Security Target are built on Common Criteria version 3.1.

Title: Security Target Lite of S3FT9MF/S3FT9MT/S3FT9MS 16-Bit RISC Microcontroller for Smart
Cards

Target of Evaluation: S3FT9MF/S3FT9MT/S3FT9MS

TOE reference: S3FT9MF/S3FT9MT/S3FT9MS_rev1_SW10-50-60-24_GU111-12-19-225-15-19-14-20-05

Provided by: Samsung Electronics Co., Ltd.

Common Criteria version :
5
[1] Common Criteria, Part 1: Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model, Version 3.1, Revision 4, September 2012, CCMB-2012-09-001
6
[2] Common Criteria, Part 2: Common Criteria for Information Technology Security Evaluation,Part2:
Security Functional Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-002
7
[3] Common Criteria, Part 3: Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003
8
[4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology,
Version 3.1, Revision 4, September 2012, CCMB-2012-09-004
14/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
1.2 TOE Overview and TOE Description
1.2.1 Introduction
9
The Target of Evaluation (TOE), the S3FT9MF/S3FT9MT/S3FT9MS microcontroller featuring the
TORNADO2MX2 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/ECC public key cryptographic library, an [6]AIS31 compliant random number generation
library and an [6]AIS31 compliant random number generator. The RSA/ECC library further includes the
functionality of hash computation. The use 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,
this functionality is intended to be used for signature generation and verification only. All other software is
called Smartcard Embedded Software and is not part of the TOE.
10
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 two TOE
configurations. 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/ECC cryptographic library, the library is
not delivered to the user and the accompanying ―Additional Specific Security Functionality‖ RivestShamir-Adleman (O.RSA) and Elliptic Curve Cryptography (O.ECC) is not provided by the TOE.
Deselecting 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.
11
The only difference between S3FT9MF, S3FT9MT and S3FT9MS is at the FLASH memory size in a logical
meaning, say, S3FT9MF(264KB), S3FT9MT(232KB) and S3FT9MS(212KB), which means that all 3
microcontrollers have the same layout.
1.2.2 TOE Definition
12
The S3FT9MF/S3FT9MT/S3FT9MS single-chip CMOS micro-controller is designed and packaged
specifically for "Smart Card" applications.
13
The CalmRISC16 CPU architecture of the S3FT9MF/S3FT9MT/S3FT9MS 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 S3FT9MF/S3FT9MT/S3FT9MS integrated circuit are:
15
Security sensors , detectors or filters
16
Shields
15/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
17
Dedicated tamper-resistant design based on synthesizable glue logic and secure topology
18
Dedicated hardware mechanisms against side-channel attacks
19
Secure DES and AES Symmetric Cryptography support
20
Secure TORNADO™2MX2 coprocessor for the support of RSA and ECC cryptographic operations
21
One Hardware Digital True Random Number Generator (DTRNG FRO) that meet P2 class of BSI-AIS31
(German Metric).
22
The IC Dedicated Software includes:
23
- A modular arithmetic library for the support of RSA and ECC (with SHA) cryptographic operations
(optional)
24
- A DTRNG FRO library built around Hardware DTRNG FRO together with a DTRNG FRO application
note that meets some of ANSSI requirements as well as P2 class of BSI-AIS31 (German Metric).
25
The main hardware blocks of the S3FT9MF/S3FT9MT/S3FT9MS Integrated Circuit are described in Figure
1 below:
ROM
32KB
SecuCalm
CPU
DMA RAM
Contactless
Interface
Peripherals
monitor
FLASH
L1
L2
DTRNG
RNG
MPU
AES
Address and Data Bus
RAM
CryptoRAM
2.5KB
Clock
TORNADO
Timers
(16-bit Timer /
20-bit WDT)
Detectors &
Security
Control
IVR (Internal
Voltage
Regulator)
Power on
reset
Contact
Interface
DES
Vcc
RST
CLK
SIO
GND
Figure 1
S3FT9MF/S3FT9MT/S3FT9MS Block Diagram
*Note that only the Triple DES algorithm belongs to the TOE, not the Single DES.
26
The TOE consists of the following Hardware and Software:
TOE Hardware

264Kbytes(S3FT9MF), 232Kbytes(S3FT9MT), 212Kbytes(S3FT9MS) FLASH / 6K bytes RAM / 2.5K
16/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
bytes Crypto. RAM / 32Kbytes ROM / 768 Bytes Flash special area

16-bit Central Processing Unit (CPU)

Internal Voltage Regulator (IVR)

Detectors & Security Logic

Filters

Digital True random number generator (DTRNG FRO)

Bilateral Pseudo Random Number Generator (BPRNG)

Memory Protection Unit (MPU)

Triple DES cryptographic coprocessor

AES cryptographic coprocessor

TORNADO2MX2 supporting modular multiplications

Hardware UART for contact and contactless I/O modes

Address & data buses

Internal Clock

Timers

Power on Reset

Error Correcting Code (ECC)
17/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
TOE Software
27
The TOE software comprises the following components:

Test ROM code that is used for testing the chip during production.

The TORNADO2MX2 Secure RSA/ECC library (optional)
TORNADO2MX2 is a hardware coprocessor for high speed modular multiplications, modular
additions and modular subtractions.
The TORNADO2MX2 Secure RSA/ECC library is a software library built on the TORNADO2MX2
coprocessor that provides high level interface for RSA and ECC cryptographic algorithms.
The RSA functions of the library included in the TOE are:

RSA_KeyGen_Secure (RSA public/private key pair generation)

TND_RSA_SigSTD_Secure (RSA signature generation with the standard method)

TND_RSA_SigCRT_Secure (RSA signature generation with the CRT method)

TND_RSA_Verify (RSA signature verification)

RSA_R2modM_precompute_sec (RSA R^2 value precomputation for the standard
method)

RSA_R2modPandQ_precompute_sec (RSA R^2 value precomputation for the CRT
method)

The TORNADO2MX2 Secure RSA/ECC library provides a set of functions to implement ECC
cryptographic algorithms. In particular, it provides some functions to implement the ECDSA
signing/verifying and the ECDH key exchange protocol. The library implements ECC for general
curves over prime fields of size from 192-bit to 512-bit and the only certain curves are in the scope of
this evaluation. The ECC functions of the library included in the TOE are:

ECDSA_keygen (Ephemeral or static key pair generation for ECDSA
signing/verifying)

ECDSA_sign_digest (ECDSA signature generation for a message digest)

ECDSA_verify_digest (ECDSA signature verification for a message digest)

ECDH_generate (ECDH secret key derivation)

The TORNADO2MX2 Secure RSA/ECC library provides the functions for calculating hash
(digest) values using the SHA1, SHA224, SHA256, SHA384 and SHA512 algorithms as specified in
[FIPS PUB 180-3], but only those related to SHA224, SHA256, SHA384 and SHA512 listed below are
within the scope of this evaluation:


SHA224_init, SHA224_update, SHA224_final

SHA256_init, SHA256_update, SHA256_final

SHA384_init, SHA384_update, SHA384_final

SHA512_init, SHA512_update, SHA512_final
A Digital True Random Number Generator (DTRNG FRO) library.
18/96
Samsung Confidential
ST Lite Ver7.2

28
1 ST INTRODUCTION
Secure Boot Loader can download the encrypted user code with AES
The TOE configuration is summarized in table 1 below:
Item
Type
Item
Versio
n
Hardware
S3FT9MF/S3FT9MT/S3FT9
MS 16-Bit RISC
Microcontroller for Smart
Card
1
Software
Test ROM Code
1.0
Software
Secure Boot loader code
5.0
Date
Wafer or Module
2013.05.27
2013.11.14
Software
DTRNG FRO library
6.0
2013.03.07
Software
(optional)
Secure RSA/ ECC Library
Document
DTRNG FRO Application
Note
Hardware User’s manual
Document
Security Application Note
Document
Document
Document
Document
Document
Tornado-2Mx2 RSA/ECC
Library API Manual
Chip Delivery Specification
Boot Loader Specification
Architecture Reference:
SecuCalm CPU Core
2.4
1.11
2015.06.10
1.2
2014.09.23
1.9
2015.06.09
2.25
2014.10.04
1.5
2014.06
1.9
2015.06.09
14
Form of delivery
2011.03.03
- Included in
S3FT9MF/MT/MS Test
ROM
- Test ROM code is not part
of the TOE.
Included in
S3FT9MF/MT/MS in ROM
Software Library. This
library is delivered as object
file and is optionally
integrated into user NVM
code.
Software Library. This
library is delivered as object
file and is optionally
integrated into user NVM
code.
Softcopy
Softcopy
Softcopy
Softcopy
Softcopy
Softcopy
Softcopy
Document
Boot Loader Appendix
2.0
2015.06.09
Optional Softcopy
Document
Errata for UMv1.2
0.5
2015.07
Softcopy
Address
Refer to the chapter 7
Items
Device type
The value
S3FT9MF: 160F
19/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
in Delivery specification
S3FT9MT: 161D
S3FT9MS: 161C
01
IC Version
Test ROM Code Version
10
Boot loader code version
50
Crypto. Library Version
2.4
DTRNG FRO Library Version
6.0
Table 1.
TOE Configuration
1.2.3 TOE Features
CPU
 16-bit SecuCalm core
Memory
 32K-byte Program Memory (ROM)

8K-byte Test ROM

264Kbytes(S3FT9MF), 232Kbytes(S3FT9MT), 212Kbytes(S3FT9MS) Data/Program Memory (FLASH)

768 bytes Data Memory(FLASH)

6K-byte Data Memory (RAM)

2.5K-byte Crypto Memory (Crypto RAM)

512bytes DMA RAM
FLASH Write Operations
 Minimum 500,000 write/erase cycles

Data retention for minimum 25 years at 25°C
Triple DES
 Built-in hardware Triple DES accelerator
AES
 Built-in hardware AES accelerator
TORNADO-2Mx2
 Built-in hardware accelerator for big number calculation
Abnormal Condition Detectors and Filters
20/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
Interrupts
 Two interrupt sources and vectors (FIQ,IRQ)
Serial I/O Interface
 T=0 and 1 (ISO 7816-3)

Type A and Type B contactless interfaces compliant with the ISO 14443 standard
Reset and Power Down Mode
 Stop mode
Random Number Generator
Memory Protection Unit
 The MPU allow the CPU to access memories through channels. Each channel can allow the access to a
contiguous range of address.
Memory Encryption and Bus Scrambling
Timers
ECC
Clock Sources
 External clock: 1 MHz–10 MHz
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)
1.2.4 TOE Life cycle
29
The complex development and manufacturing processes of a Composite Product can be separated into
seven distinct phases. The phases 2 and 3 of the Composite Product life cycle cover the IC development and
production:

IC Development (Phase 2):
–
– IC design,
IC Dedicated Software development, the IC Manufacturing (Phase 3):
21/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
– integration and photomask fabrication,
– IC production,
– IC testing,
– preparation and
30
– Pre-personalisation if necessary
The Composite Product life cycle phase 4 can be included in the evaluation of the IC as an option:

the IC Packaging (Phase 4):
– Security IC packaging (and testing),
31
– Pre-personalisation if necessary.
In addition, three important stages have to be considered in the Composite Product life cycle:

Security IC Embedded Software Development (Phase 1),

the Composite Product finishing process, preparation and shipping to the personalisation line for the
Composite Product (Composite Product Integration Phase 5),
Package in Phase 5
Package 1
Package 2
Description
Loader dedicated for usage in Secured Environment only
Loader dedicated for usage by authorized users only

the Composite Product personalisation and testing stage where the User Data is loaded into the
Security IC's memory (Personalisation Phase 6),

the Composite Product usage by its issuers and consumers (Operational Usage Phase 7) which may
include loading and other management of applications in the field.
Device is in Test
mode
Device is in Normal
mode
Figure 2
32
Definition of “TOE Delivery” and responsible Parties
The Security IC Embedded Software is developed outside the TOE development in Phase 1. The TOE is
developed in Phase 2 and produced in Phase 3. Then the TOE is delivered in form of wafers. The TOE can
22/96
Samsung Confidential
ST Lite Ver7.2
1 ST INTRODUCTION
also be delivered in form of packaged products. In this case, the development and production of the TOE
not only pertain to Phase 2 and 3 but to Phase 4 in addition.
1.3 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, L1 and L2 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 TRNG interface of the TOE is defined by the DTRNG FRO libraries interface.

The RSA interface of the TOE is defined by the RSA/ECC library interface (optional).

The interface to the ECC and SHA calculations is defined from the RSA/ECC library interface
(optional)
1.4 TOE Intended Usage
33
The TOE is dedicated to applications such as:

Banking and finance applications for credit or debit cards, electronic purse (stored value cards) and
electronic commerce.

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).

Transport and ticketing applications (access control cards).

Governmental cards (ID cards, health cards, driving licenses).

Multimedia applications and Digital Right Management protection.
23/96
Samsung Confidential
ST Lite Ver7.2
2
34
2 CONFORMANCE CLAIMS
CONFORMANCE CLAIMS
This chapter 2 contains the following sections:
2.1 CC Conformance Claim
2.2 PP Claim
2.3 Package Claim
2.4 Conformance Claim Rationale
24/96
Samsung Confidential
ST Lite Ver7.2
2 CONFORMANCE CLAIMS
2.1 CC Conformance Claim
35
This Security target claims to be conformant to the Common Criteria version 3.1 R4.
36
Furthermore it claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security
Functional Requirements are defined in chapter 5.
37
This Security Target has been built with the Common Criteria for Information Technology Security
Evaluation; Version 3.1 which comprises
[1] Common Criteria, Part 1: Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model, Version 3.1, Revision 4, Sept. 2012, CCMB-2012-09-001
[2] Common Criteria, Part 2: Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components, Version 3.1, Revision 4, Sept. 2012, CCMB-2012-09-002
[3] Common Criteria, Part 3: Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components, Version 3.1, Revision 4, Sept. 2012, CCMB-2012-09-003
[4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology,
Version 3.1, Revision 4, Sept. 2012, CCMB-2012-09-004
has been taken into account.
2.2 PP Claim
This Security Target is strictly compliant to the Security IC Platform Protection Profile [5] with additional
packages:
 Package ―Authentication of the Security IC‖
 Package 1: Loader dedicated for usage in secured environment only
 Package 2: Loader dedicated for usage by authorized users only
The Security IC Platform Protection Profile is registered and certified by the Bundesamt fü r Sicherheit in der
Informationstechnik (BSI) under the reference BSI-CC-PP-0084, Version 1.0, dated 01.2014.
This ST does not claim conformance to any other PP.
2.2 Package Claim
38
The assurance level for this Security Target is EAL6 augmented with ASE_TSS.2.
2.3 Conformance Claim Rationale
39
This security target claims strict conformance only to one PP, the Security IC Platform Protection Profile [5].
40
The Evaluation Assurance Level (EAL) of the PP [5] is EAL 4 augmented with the assurance components
ALC_DVS.2 and AVA_VAN.5. The Assurance Requirements of the TOE obtain the Evaluation Assurance
Level 6 augmented with the assurance component ASE_TSS.2 for the TOE.
41
The Target of Evaluation (TOE) is a complete solution implementing a security integrated circuit (security
IC) as defined in the PP [5] section 1.3.1, so the TOE is consistent with the TOE type in the PP [5].
25/96
Samsung Confidential
ST Lite Ver7.2
2 CONFORMANCE CLAIMS
42
The security problem definition of this security target is consistent with the statement of the security
problem definition in the PP [5], as the security target claimed strict conformance to the PP [5]. Additional
threats, organisational security policies and assumptions are introduced in chapter 3 of this ST, a rationale
is given in chapter 4.4.
43
The security objectives of this security target are consistent with the statement of the security objectives in
the PP [5], as the security target claimed strict conformance to the PP [5]. Additional security objectives are
added in chapter 4.1 of this ST, a rationale is given in chapter 4.4.
44
The security requirements of this security target are consistent with the statement of the security
requirements in the PP [5], as the security target claimed strict conformance to the PP [5]. Additional
security requirements are added in chapter 6.1 of this ST, a rationale is given in chapter 6.3. All assignments
and selections of the security functional requirements are done in the PP [5] and in this security target
section 6.1.
26/96
Samsung Confidential
ST Lite Ver7.2
3
45
3 SECURITY PROBLEM DEFINITION
SECURITY PROBLEM DEFINITION
This chapter 3 contains the following sections:
3.1 Description of Assets
3.2 Threats
3.3 Organizational Security Policies
3.4 Assumptions
3.1 Description of Assets
Assets regarding the Threats
46
47
The assets (related to standard functionality) to be protected are

the User Data of the Composite TOE,

the Security IC Embedded Software stored and in operation,,

the security services provided by the TOE for the Security IC Embedded Software.
The user (consumer) of the TOE places value upon the assets related to high-level security concerns:
SC1
integrity of User Data of the Composite TOE,
SC2
confidentiality of User Data and of the Composite TOE being stored in the TOE’s protected
memory areas,
SC3
correct operation of the security services provided by the TOE for the Security IC Embedded
Software.
Note the Security IC Embedded Software is user data and shall be protected while being
executed/processed and while being stored in the TOE’s protected memories
48
The Security IC may not distinguish between user data which is public knowledge or kept confidential.
Therefore the security IC shall protect the user data of the Composite TOE in integrity and in
confidentiality if stored in protected memory areas, unless the Security IC Embedded Software chooses to
disclose or modify it.
49
In particular integrity of the Security IC Embedded Software means that it is correctly being executed
which includes the correct operation of the TOE’s functionality. Parts of the Security IC Embedded
Software which do not contain secret data or security critical source code, may not require protection from
being disclosed. Other parts of the Security IC Embedded Software may need to be kept confidential since
specific implementation details may assist an attacker.
27/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
50
This Protection Profile requires the TOE to provide at least one security service: the generation of random
numbers by means of a physical Random Number Generator. The annex 7 provides packages for typical
additional security services. The Security Target may require additional security services as described in
these packages or define TOE specific security services. It is essential that the TOE ensures the correct
operation of all security services provided by the TOE for the Security IC Embedded Software.
51
According to the Protection Profile there is the following high-level security concern related to security
service:
SC4
52
deficiency of random numbers.
To be able to protect these assets (SC1 to SC4) the TOE shall self-protect its TSF. Critical information about
the TSF shall be protected by the development environment and the operational environment. Critical
information may include:

logical design data, physical design data, IC Dedicated Software, and configuration data,

Initialisation Data and Pre-personalisation Data, specific development aids, test and characterisation
related data, material for software development support, and photomasks.
53
Such information and the ability to perform manipulations assist in threatening the above assets.
54
Note that there are many ways to manipulate or disclose the user data of the Composite TOE: (i) An
attacker may manipulate the Security IC Embedded Software or the TOE. (ii) An attacker may cause
malfunctions of the TOE or abuse Test Features provided by the TOE. Such attacks usually require design
information of the TOE to be obtained. They pertain to all information about (i) the circuitry of the IC
(hardware including the physical memories), (ii) the IC Dedicated Software with the parts IC Dedicated
Test Software (if any) and IC Dedicated Support Software (if any), and (iii) the configuration data for the
TSF. The knowledge of this information may enable or support attacks on the assets. Therefore the TOE
Manufacturer must ensure that the development and production of the TOE (refer to Section 1.2.3) is secure
so that no restricted, sensitive, critical or very critical information is unintentionally made available for
attacks in the operational phase of the TOE (cf. [8] for details on assessment of knowledge of the TOE in the
vulnerability analysis).
55
The TOE Manufacturer must apply protection to support the security of the TOE. This not only pertains to
the TOE but also to all information and material exchanged with the developer of the Security IC
Embedded Software. This covers the Security IC Embedded Software itself if provided by the developer of
the Security IC Embedded Software or any authentication data required to enable the download of
software. 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. These aspects enforce the usage of the supporting
documents and the refinements of SAR defined in the protection profile.
56
The information and material produced and/or processed by the TOE Manufacturer in the TOE
development and production environment (Phases 2 up to TOE Delivery) can be grouped as follows:
●
●
●
●
●
●
logical design data,
physical design data,
IC Dedicated Software, Initialisation Data and Pre-personalisation Data,
Security IC Embedded Software, provided by the Security IC Embedded Software developer
and implemented by the IC manufacturer,
specific development aids,
test and characterisation related data,
28/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
●
material for software development support, and
●
photomasks and products in any form
as long as they are generated, stored, or processed by the TOE Manufacturer.
3.2 Threats
57
The following explanations help to understand the focus of the threats and objectives defined below. For
example, certain attacks are only one step towards a disclosure of assets, others may directly lead to a
compromise of the application security.

Manipulation of user data (which includes user data and code of the Composite TOE, stored in or
processed by the Security IC) means that an attacker is able to alter a meaningful block of data. This
should be considered for the threats T.Malfunction, T.Phys-Manipulation and T.Abuse-Func

Disclosure of user data (which may include user data and code of the Composite TOE, stored in
protected memory areas or processed by the Security IC) or TSF data means that an attacker is
realistically3F2 able to determine a meaningful block of data. This should be considered for the threats
T.Leak-Inherent, T.Phys-Probing, T.Leak-Forced and T.Abuse-Func.

Manipulation of the TSF or TSF data means that an attacker is able to deliberately deactivate or
otherwise change the behaviour of a specific security functionality in a manner which enables
exploitation. This should be considered for the threat T.Malfunction, T.Phys-Manipulation and
T.Abuse-Func.
58
The cloning of the functional behaviour of the Security IC on its physical and command interface is the
highest level security concern in the application context.
59
The cloning of that functional behaviour requires to (i) develop a functional equivalent of the Security IC
Embedded Software, (ii) disclose, interpret and employ the user data of the Composite TOE stored in the
TOE, and (iii) develop and build a functional equivalent of the Security IC using the input from the
previous steps.
60
The Security IC is a platform for the Security IC Embedded Software which ensures that especially the
critical user data of the Composite TOE are stored and processed in a secure way (refer to below). The
Security IC Embedded Software must also ensure that critical user data of the Composite TOE are treated as
required in the application context. In addition, the personalisation process supported by the Security IC
Embedded Software (and perhaps by the Security IC in addition) must be secure. This last step is beyond
the scope of the Protection Profile. As a result the threat ―cloning of the functional behaviour of the Security
IC on its physical and command interface‖ is averted by the combination of mechanisms which split into
those being evaluated according to this Protection Profile (Security IC) and those being subject to the
evaluation of the Security IC Embedded Software or Security IC and the corresponding personalisation
process. Therefore, functional cloning is indirectly covered by the security concerns and threats described
below.
61
The high-level security concerns are refined below by defining threats as required by the Common Criteria
(refer to Figure 3). Note that manipulation of the TOE is only a means to threaten user data and is not a
success for the attacker in itself.
29/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
T.Phys-Manipulation
T.Leak-Inherent
T.Phys-Probing
T.Leak-Forced
T.Malfunction
T.Abuse-Func
Figure 3
62
Standard Threats
The high-level security concern related to security service is refined below by defining threats as required
by the Common Criteria (refer to Figure 4).
T.MemAccess
T.RND
Figure 4
T.Masquerade_TOE
Threats related to security service
63
The Security IC Embedded Software must contribute to averting the threats: At least it must not undermine
the security provided by the TOE.
64
The above security concerns are derived from considering the end-usage phase (Phase 7) since

Phase 1 and the Phases from TOE Delivery up to the end of Phase 6 are covered by assumptions and

the development and production environment starting with Phase 2 up to TOE Delivery are covered
by an organisational security policy.
65
The TOE’s countermeasures are designed to avert the threats described below. Nevertheless, they may be
effective in earlier phases (Phases 4 to 6).
66
The TOE is exposed to different types of influences or interactions with its outer world. Some of them may
result from using the TOE only but others may also indicate an attack. The different types of influences or
interactions are visualised in Figure 5. Due to the intended usage of the TOE all interactions are considered
as possible.
30/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
Figure 5
67
Interactions between the TOE and its outer world
An interaction with the TOE can be done through the physical interfaces (Number 7 – 9 in Figure 5) which
are realised using contacts and/or a contactless interface. Influences or interactions with the TOE also occur
through the chip surface (Number 1 – 6 in Figure 5). In Number 1 and 6 galvanic contacts are used. In
Number 2 and 5 the influence (arrow directed to the chip) or the measurement (arrow starts from the chip)
does not require a contact. Number 3 and 4 refer to specific situations where the TOE and its functional
behaviour is not only influenced but definite changes are made by applying mechanical, chemical and other
methods (such as 1, 2). Many attacks require a prior inspection and some reverse-engineering (Number 3).
This demonstrates the basic building blocks of attacks. A practical attack will use a combination of these
elements.
3.2.1 Standard Threats
68
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 Security IC in order to disclose confidential user data as part of the assets.
69
No direct contact with the Security IC 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). This leakage may be interpreted as a
covert channel transmission but is more closely related to measurement of operating parameters, which
may be derived either from direct (contact) measurements (Numbers 6 and 7 in Figure 5) or measurement
of emanations (Number 5 in Figure 5) and can then be related to the specific operation being performed.
70
The TOE shall avert the threat ―Physical Probing (T.Phys-Probing)‖ as specified below.
31/96
Samsung Confidential
ST Lite Ver7.2
T.Phys-Probing
3 SECURITY PROBLEM DEFINITION
Physical Probing
An attacker may perform physical probing of the TOE in order (i) to disclose user
data while stored in protected memory areas, (ii) to disclose/reconstruct the user
data while processed or (iii) to disclose other critical information about the
operation of the TOE to enable attacks disclosing or manipulating the user data
of the Composite TOE or the Security IC Embedded Software.
71
Physical probing requires direct interaction with the Security IC internals (Numbers 5 and 6 in Figure 5).
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 (Number 3 in
Figure 5). Determination of software design including treatment of user data of the Composite TOE
may also be a pre-requisite.
72
This pertains to ―measurements‖ using galvanic contacts or any type of charge interaction whereas
manipulations are considered under the threat ―Physical Manipulation (T.Phys-Manipulation)‖. The threats
―Inherent Information Leakage (T.Leak-Inherent)‖ and ―Forced Information Leakage (T.Leak-Forced)― may
use physical probing but require complex signal processing in addition.
73
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 Security IC Embedded
Software by applying environmental stress in order to (i) modify security services
of the TOE or (ii) modify functions of the Security IC Embedded Software (iii)
deactivate or affect security mechanisms of the TOE to enable attacks disclosing
or manipulating the user data of the Composite TOE or the Security IC
Embedded Software. This may be achieved by operating the Security IC
outside the normal operating conditions (Numbers 1, 2 and 9 in Figure 5).
74
The modification of security services of the TOE may e.g. affect the quality of random numbers provided by
the random number generator up to undetected deactivation when the random number generator does not
produce random numbers and the Security IC Embedded Software gets constant values. In another case
errors are introduced in executing the Security IC Embedded Software. To exploit this an attacker needs
information about the functional operation, e.g. to introduce a temporary failure within a register used by
the Security IC Embedded Software with light or a power glitch.
75
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 Security IC in order to (i) modify user
data of the Composite TOE, (ii) modify the Security IC Embedded Software, (iii)
modify or deactivate security services of the TOE, or (iv) modify security
mechanisms of the TOE to enable attacks disclosing or manipulating the user
data of the Composite TOE or the Security IC Embedded Software.
76
The modification may be achieved through techniques commonly employed in IC failure analysis
(Numbers 1, 2 and 4 in Figure 5) and IC reverse engineering efforts (Number 3 in Figure 5). The
modification may result in the deactivation of a security feature. Before that hardware security mechanisms
and layout characteristics need to be identified. Determination of software design including treatment of
32/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
user data of the Composite TOE may also be a pre-requisite. Changes of circuitry or data can be permanent
or temporary.
77
In contrast to malfunctions (refer to T.Malfunction) the attacker requires gathering significant knowledge
about the TOE’s internal construction here (Number 3 in Figure 5).
78
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 Security IC in order to disclose confidential user data of the Composite
TOE as part of the assets even if the information leakage is not inherent but
caused by the attacker.
79
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 from signals (Numbers 5, 6, 7 and 8 in Figure 5) which normally do not contain significant
information about secrets.
80
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 be used after TOE
Delivery in order to (i) disclose or manipulate user data of the Composite TOE, (ii)
manipulate (explore, bypass, deactivate or change) security services of the TOE
or (iii) manipulate (explore, bypass, deactivate or change) functions of the
Security IC Embedded Software or (iv) enable an attack disclosing or
manipulating the the user data of the Composite TOE or the Security IC
Embedded Software.
3.2.2 Threats related to security services
81
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 security service for instance because of a lack of entropy of the
random numbers provided.
An attacker may gather information about the random numbers produced by the TOE security service.
Because unpredictability is the main property of random numbers this may be a problem in case they are
used to generate cryptographic keys. The entropy provided by the random numbers must be appropriate
for the strength of the cryptographic algorithm, the key or the cryptographic variable is used for. Here the
attacker is expected to take advantage of statistical properties of the random numbers generated by the
TOE. Malfunctions or premature ageing are also considered which may assist in getting information about
random numbers.
33/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
3.2.3 Threats related to additional TOE Specific Functionality
82
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 IC 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 IC Embedded Software.
Clarification: This threat does not address the proper definition and management
of the security rules implemented by the Security IC Embedded Software, this
being software design and correctness issue.This threat addresses the reliability
of the abstract machine targeted by the software implementation. To avert the
threat, the set of access rules provided by this TOE should be undefeated if
operated according to the provided guidance. The threat is not realized if the
Security IC Embedded Software is designed or implemented to grant access to
restricted information. It is realized if an implemented access denial is granted
under unexpected conditions or if the execution machinery does not effectively
control a controlled access.
Here the attacker is expected to (i) take advantage of flaws in the design and/or
the implementation of the TOE memory access rules (refer to T.Abuse-Func but
for functions available after TOE delivery), (ii) introduce flaws by forcing
operational conditions (refer to T.Malfunction) and/or by physical manipulation
(refer to T.Phys-Manipulation). This attacker is expected to have a high level
potential of attack.
3.2.4 Threats related to Authentication of the Security IC
The TOE shall avert the threat ―Masquerade the TOE (T. Masquerade_TOE)‖ as specified below.
T.Masquerade_TOE
Masquerade the TOE
An attacker may threaten the property being a genuine TOE by producing a chip
which is not a genuine TOE but wrongly identifying itself as genuine TOE sample.
The threat T.Masquerade_TOE may threaten the unique identity of the TOE as described in the P.ProcessTOE or the property as being a genuine TOE without unique identity. Mitigation of masquerade requires
tightening up the identification by authentication.
34/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
3.3 Organizational Security Policies
83
The following Figure 6 shows the policies applied in this Security Target.
P.CryptoService
P.ProcessTOE
P.Lim_Block_Lo
ader
Figure 6
84
P.Ctlr_Loader
Policies
The IC Developer / Manufacturer must apply the policy ―Identification during TOE Development and
Production (P.Process-TOE)‖ as specified below.
P.Process-TOE Identification during TOE Development and Production
An accurate identification must be established for the TOE. This requires that
each instantiation of the TOE carries this unique identification.
85
The accurate identification is introduced at the end of the production test in phase 3. Therefore the
production environment must support this unique identification.
86
The information and material produced and/or processed by the TOE Manufacturer in the TOE
development and production environment (Phases 2 up to TOE Delivery) can be grouped as follows:

logical design data,

physical design data,

IC Dedicated Software, Security IC Embedded Software, Initialisation Data and Pre-personalisation
Data,

specific development aids,

test and characterisation related data,

material for software development support, and

photomasks and products in any form
as long as they are generated, stored, or processed by the TOE Manufacturer.
87
The TOE provides specific cryptographic services which can be used by the Smartcard Embedded Software.
In the following specific cryptographic services are 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 applications, against
which threats the Smartcard Embedded Software will use the specific cryptographic service.
The IC Developer / Manufacturer must apply the policy ―Cryptographic Service (P.Crypto-Service)‖ as
specified below.
P.Crypto-Service
Cryptographic Services provided by the TOE
The TOE shall provide the following cryptographic services to the IC Embedded
Software:

Triple Data Encryption Standard (TDES)
35/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION

Advanced Encryption Standard (AES)

Rivest-Shamir-Adleman
(optional)

Elliptic Curve Cryptography (ECC) (optional)

Secure Hash Algorithm (SHA) (optional)
(RSA)
public
key
asymmetric
cryptography
Note: The TOE can be delivered without the RSA/ECC crypto library. In this
case the TOE does not provide the Additional Specific Security Functionality
Rivest-Shamir-Adleman Cryptography and Elliptic Curve Cryptography (ECC)
and Secure Hash Algorithm (SHA).
The IC Developer / Manufacturer must apply the organisational security policy ―Limiting and Blocking
the Loader Functionality (P.Lim_Block_Loader)‖ applies to Loader dedicated for usage in secured
environment specified below.
P.Lim_Block_Loader
Limiting and Blocking the Loader Functionality
The composite manufacturer uses the Loader for loading of Security IC
Embedded Software, user data of the Composite Product or IC Dedicated
Support Software in charge of the IC Manufacturer. He limits the capability and
blocks the availability of the Loader in order to protect stored data from
disclosure and manipulation.
The organizational security policy ―Controlled usage to Loader Functionality (P.Ctlr_Loader)‖ applies to
Loader dedicated for usage by authorized users only.
P.Ctlr_Loader
Controlled usage to Loader Functionality
Authorized user controls the usage of the Loader functionality in order to protect stored and loaded user
data from disclosure and manipulation.
36/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
3.4 Assumptions
88
The following Figure 7 shows the assumptions applied in this Security Target.
A.Process-Sec-IC
A.Resp-Appl
Figure 7
A.Key-Function
Assumptions
89
The intended usage of the TOE is twofold, depending on the Life Cycle Phase: (i) The Security IC
Embedded Software developer use it as a platform for the Security IC software being developed. The
Composite Product Manufacturer (and the consumer) uses it as a part of the Security IC. The Composite
Product is used in a terminal which supplies the Security IC (with power and clock) and (at least) mediates
the communication with the Security IC Embedded Software.
90
Before being delivered to the consumer the TOE is packaged. Many attacks require the TOE to be removed
from the carrier. Though this extra step adds difficulties for the attacker no specific assumptions are made
here regarding the package.
91
Appropriate ―Protection during Packaging, Finishing and Personalisation (A.Process-Sec-IC)‖ must be
ensured after TOE Delivery up to the end of Phase 6, as well as during the delivery to Phase 7 as specified
below.
A.Process-Sec-IC
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-consumer 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).
This means that the Phases after TOE Delivery are assumed to be protected
appropriately.
92
The information and material produced and/or processed by the Security IC Embedded Software
Developer in Phase 1 and by the Composite Product Manufacturer can be grouped as follows:

the Security IC Embedded Software including specifications, implementation and related
documentation,

Pre-personalisation Data and Personalisation Data including specifications of formats and memory
areas, test related data,

the user data of the Composite TOE and related documentation, and

material for software development support
93
as long as they are not under the control of the TOE Manufacturer. Details must be defined in the
Protection Profile or Security Target for the evaluation of the Security IC Embedded Software and/or
Security IC.
94
The developer of the Security IC Embedded Software must ensure the appropriate usage of Security IC
while developing this software in Phase 1 as described in the (i) TOE guidance documents (refer to the
37/96
Samsung Confidential
ST Lite Ver7.2
3 SECURITY PROBLEM DEFINITION
Common Criteria assurance class AGD) such as the hardware data sheet, and the hardware application
notes, and (ii) findings of the TOE evaluation reports relevant for the Security IC Embedded Software as
documented in the certification report.
95
The Security IC Embedded Software must ensure the appropriate ―Treatment of user data of the Composite
TOE (A.Resp-Appl)‖ as specified below.
A.Resp-Appl
Treatment of user data the Composite TOE
All user data of the Composite TOE are owned by Security IC Embedded
Software. Therefore, it must be assumed that security relevant user data of the
Composite TOE (especially cryptographic keys) are treated by the Security IC
Embedded Software as defined for its specific application context.
96
The application context specifies how the the user data of the Composite TOE shall be handled and
protected. The evaluation of the Security IC according to this Security Target is conducted on generalized
application context. The concrete requirements for the Security IC Embedded Software shall be defined in
the Protection Profile respective Security Target for the Security IC Embedded Software. The Security IC
cannot prevent any compromise or modification of user data of the Composite TOE by malicious Security
IC Embedded Software.
97
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).
98
Note that here the routines which may compromise keys when being executed 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.
38/96
Samsung Confidential
ST Lite Ver7.2
4
99
4 SECURITY OBJECTIVES
SECURITY OBJECTIVES
This chapter Security Objectives contains the following sections:
4.1 Security Objectives for the TOE
4.2 Security Objectives for the Security IC Embedded Software
4.3 Security Objectives for the operational Environment
4.4 Security Objectives Rationale
39/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
4.1 Security Objectives for the TOE
100
The user have the following standard high-level security goals related to the assets:
SG1
maintain the integrity user data (when being executed/processed and when being stored
in the TOE’s memories) as well as
SG2
maintain the confidentiality of user data (when being processed and when being stored in
the TOE’s protected memories).
SG3
maintain the correct operation of the security services provided by the TOE for the
Security IC Embedded Software.
101
Note, the Security IC may not distinguish between user data which are public known or kept confidential.
Therefore the security IC shall protect the user data in integrity and in confidentiality if stored in protected
memory areas, unless the Security IC Embedded Software chooses to disclose or modify it. Parts of the
Security IC Embedded Software which do not contain secret data or security critical source code, may not
require protection from being disclosed. Other parts of the Security IC Embedded Software may need kept
confidential since specific implementation details may assist an attacker.
102
These standard high-level security goals in the context of the security problem definition build the starting
point for the definition of security objectives as required by the Common Criteria (refer to Figure 8). Note
that the integrity of the TOE is a means to reach these objectives.
O.Phys-Manipulation
O.Leak-Inherent
O.Phys-Probing
O.Leak-Forced
O.Malfunction
O.Abuse_Func
O.Identification
Figure 8
Standard Security Objectives
103
According to this Protection Profile there is the following high-level security goal related to specific
functionality:
104
SG4
105
The additional high-level security considerations are refined below by defining security objectives as
provide random numbers.
40/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
required by the Common Criteria (refer to Figure 9).
O.RND
O.Cap_Avail_Loader
O.Mem-Access
O.Authentication
O.TDES
O.AES
O.SHA
O.RSA
O.ECDSA
O.ECDH
Figure 9
O.Ctrl_Auth_Loader
Security Objectives related to Specific Functionality
4.1.1 Standard Security Objectives
106
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
●
by measurement and analysis of the shape and amplitude of signals (for
example on the power, clock, or I/O lines) and
●
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.
107
The TOE shall provide ―Protection against Physical Probing (O.Phys-Probing)‖ as specified below.
O.Phys-Probing
Protection against Physical Probing
41/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
The TOE must provide protection against disclosure/reconstruction of user data
while stored in protected memory areas and processed or against the disclosure
of other critical information about the operation of the TOE.
This includes protection against
●
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
●
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 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.
108
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 indicate or prevent its operation outside the normal operating
conditions where reliability and secure operation has not been proven or tested.
This is to prevent malfunctions. Examples of 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.
109
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 of
the Composite TOE. This includes protection against
●
reverse-engineering (understanding the design and its properties and
functions),
●
manipulation of the hardware and any data, as well as
●
undetected manipulation of memory contents.
42/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
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.
110
The TOE shall provide ―Protection against Forced Information Leakage (O.Leak-Forced)― as specified
below:
O.Leak-Forced
Protection against Forced Information Leakage
The Security IC must be protected against disclosure of confidential data
processed in the Security IC (using methods as described under O.Leak-Inherent)
even if the information leakage is not inherent but caused by the attacker
●
by forcing a malfunction (refer to ―Protection against Malfunction due to
Environmental Stress (O.Malfunction)‖ and/or
●
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.
111
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 to (i) disclose critical user data of the
Composite TOE, (ii) manipulate critical user data of the Composite TOE, (iii)
manipulate Security IC Embedded Software or (iv) bypass, deactivate, change or
explore security features or security services 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.
112
The TOE shall provide
O.Identification
―TOE Identification (O.Identification)― as specified below:
TOE Identification
The TOE must provide means to store Initialisation Data and Pre-personalisation
Data in its non-volatile memory. The Initialisation Data (or parts of them) are
used for TOE identification.
4.1.2 Security Objectives related to Specific Functionality (referring to SG4)
113
The TOE shall provide
O.RND
―Random Numbers (O.RND)‖ as specified below.
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.
43/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
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 Security Objectives for Added Function
114
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.
115
The TOE shall provide ―Capability and availability of the Loader (O.Cap_Avail_Loader)‖ as specified
below.
O.Cap_Avail_Loader
Capability and availability of the Loader
The TSF provides limited capability of the Loader functionality and
irreversible termination of the Loader in order to protect stored user
data from disclosure and manipulation.
116
The TOE shall provide ―Access control and authenticity for the Loader (O.Ctrl_Auth_Loader)‖ as specified
below.
O.Ctrl_Auth_Loader
Access control and authenticity for the Loader
The TSF provides trusted communication channel with authorized user,
supports confidentiality protection and authentication of the user data
to be loaded and access control
117
for usage of the Loader functionality.
The TOE shall provide ―Cryptographic service Triple-DES (O.TDES)‖ as specified below.
O.TDES
Cryptographic service Triple-DES
The TOE provides secure hardware based cryptographic services implementing
the Triple-DES for encryption and decryption.
118
The TOE shall provide ―Cryptographic service AES (O.AES)‖ as specified below.
O.AES
Cryptographic service AES
The TOE provides secure hardware based cryptographic services for the AES
44/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
for encryption and decryption.
119
The TOE shall provide ―Cryptographic service Hash function (O.SHA)‖ as specified below.
O.SHA
Cryptographic service Hash function
The TOE provides secure software based cryptographic services for secure
hash calculation.
120
The TOE shall provide ―Cryptographic service Rivest-Shamir-Adleman (O.RSA)‖ as specified below.
O.RSA
Cryptographic service Rivest-Shamir-Adleman
The TOE provides secure software based cryptographic services for
Cryptographic operation and Cryptographic key generation.
121
The TOE shall provide ―Cryptographic service Elliptic Curve DSA (O.ECDSA)‖ as specified below.
O.ECDSA
Cryptographic service Elliptic Curve DSA
The TOE provides secure software based cryptographic services for
Cryptographic operation and Cryptographic key generation.
122
The TOE shall provide ―Cryptographic service Elliptic Curve Diffie-Hellman (O.ECDH)‖ as specified
below.
O.ECDH
Cryptographic service Elliptic Curve Diffie-Hellman
The TOE provides secure software based cryptographic services for
Cryptographic operation.
123
The Security IC Embedded Software shall provide ―Authentication to external entities (O.Authentication)‖
as specified below.
O. Authentication
Authentication to external entities
The TOE shall be able to authenticate itself to external entities. The Initialisation
Data (or parts of them) are used for TOE authentication verification data.
45/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
4.2 Security Objectives for the Security IC Embedded Software
124
125
The development of the Security IC Embedded Software is outside the development and manufacturing of
the TOE. The Security IC Embedded Software defines the operational use of the TOE. This section describes
the security objective for the Security IC Embedded Software.
Note, in order to ensure that the TOE is used in a secure manner the Security IC Embedded Software shall
be designed so that the requirements from the following documents are met: (i) hardware data sheet for the
TOE, (ii) data sheet of the IC Dedicated Software of the TOE, (iii) TOE application notes, other guidance
documents, and (iv) findings of the TOE evaluation reports relevant for the Security IC Embedded Software
as referenced in the certification report.
The Security IC Embedded Software shall provide ―Treatment of user data of the Composite TOE
(OE.Resp-Appl)‖ as specified below.
OE.Resp-Appl
Treatment of user data of the Composite TOE
Security relevant user data of the Composite TOE (especially cryptographic keys)
are treated by the Security IC Embedded Software as required by the security
needs of the specific application context.
For example the Security IC Embedded Software will not disclose security relevant user data of the
Composite TOE to unauthorised users or processes when communicating with a terminal.
4.2.1 Clarification of “Treatment of User Data (OE.Resp-Appl)”
126
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.
127
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. 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.
128
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.
4.3 Security Objectives for the Operational Environment
TOE Delivery up to the End of Phase 6
129
Appropriate ―Protection during Packaging, Finishing and Personalisation (OE.Process-Sec-IC)‖ 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-Sec-IC
Protection during composite product manufacturing
46/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
Security procedures shall be used after TOE Delivery up to delivery to the
"consumer" 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).
This means that Phases after TOE Delivery up to the end of Phase 6 must be
protected appropriately.
The operational environment of the TOE shall provide ―Limitation of capability and blocking the Loader
(OE.Lim_Block_Loader)‖ as specified below.
OE.Lim_Block_Loader
Limitation of capability and blocking the Loader
The Composite Product Manufacturer will protect the Loader functionality
against misuse, limit the capability of the Loader and terminate irreversibly the
Loader after intended usage of the Loader and terminate irreversibly the Loader
after intended usage of the Loader and before the end of phase 5.
Note: To maintain the confidentiality of the data of the composite TOE, the
intended usage of the Loader is limited to the phase 5 of the life cycle.
The operational environment of the TOE shall provide ―Secure communication and usage of the Loader
(OE.Loader_Usage)‖ as specified below.
OE.Loader_Usage
Secure communication and usage of the Loader
The authorized user must support the trusted communication channel with the
TOE by confidentiality protection and authenticity proof of the data to be loaded
and fulfilling the access conditions required by the Loader
The operational environment shall provide ―External entities authenticating of the TOE (OE.TOE_Auth)‖.
OE.TOE_Auth
External entities authenticating of the TOE
The operational environment shall support the authentication verification
mechanism and know authentication reference data of the TOE.
4.3.1 Clarification of “Protection during Composite Product Manufacturing (OE.Process-Sec-IC)”
130
The protection during packaging, finishing and personalization includes also the personalization process
and the personalization data during Phase 4, Phase 5 and Phase 6.
131
Since OE.Process-Sec-IC requires the Composite Product Manufacturer to implement those measures
assumed in A.Process-Sec-IC, the assumption is covered by this objective.
4.4 Security Objectives Rationale
132
Table 4 below gives an overview, how the assumptions, threats, and organisational security policies are
addressed by the objectives. The text following after the table justifies this in detail.
47/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
Assumption, Threat or
Organisational Security
Policy
Security Objective
Notes
A.Resp-Appl
OE.Resp-Appl
Phase 1
P.Process-TOE
O.Identification
Phase 2 – 3
optional
Phase 4
A.Process-Sec-IC
OE.Process-Sec-IC
Phase 5 – 6
optional
Phase 4
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.Crypto-Service
O.TDES
O.AES
O.RSA
O.ECDSA
O.ECDH
O.SHA
A.Key-Function
OE.Resp-Appl
P.Lim_Block_Loader
O.Cap_Avail_Loader
Phase 5
OE.Lim_Block_Loader
P.Ctlr_Loader
O.Ctrl_Auth_Loader
Phase 5
OE.Loader_Usage
T.Masquerade_TOE
O.Authentication
OE.TOE_Auth
Table 4
Security Objectives versus Assumptions, Threats or Policies
133
The justification related to the assumption ―Treatment of user data of the Composite TOE (A.Resp-Appl)‖ is
as follows:
134
Since OE.Resp-Appl requires the Security IC Embedded Software to implement measures as assumed in
A.Resp-Appl, the assumption is covered by the objective.
135
The justification related to the organisational security policy ―Protection during TOE Development and
Production (P.Process-TOE)‖ is as follows:
48/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
136
O.Identification requires that the TOE has to support the possibility of a unique identification. The unique
identification can be stored on the TOE. Since the unique identification is generated by the production
environment the production environment must support the integrity of the generated unique identification.
The technical and organisational security measures that ensure the security of the development
environment and production environment are evaluated based on the assurance measures that are part of
the evaluation. For a list of material produced and processed by the TOE Manufacturer refer to paragraph
44. All listed items and the associated development and production environments are subject of the
evaluation. Therefore, the organisational security policy P.Process-TOE is covered by this objective, as far as
organisational measures are concerned.
137
The justification related to the assumption ―Protection during Packaging, Finishing and Personalisation
(A.Process-Sec-IC)‖ is as follows:
138
Since OE.Process-Sec-IC requires the Composite Product Manufacturer to implement those measures
assumed in A.Process-Sec-IC, the assumption is covered by this objective.
139
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.AbuseFunc)‖ and ―Deficiency of Random Numbers (T.RND)‖ is as follows:
140
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.
141
The justification related to the threat ―Memory Access Violation (T.Mem-Access)‖ is as follows:
142
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.
143
The clarification of O.Mem-Access makes clear that it is up to the Smartcard Embedded Software to
implement the memory management scheme by appropriately administrating the TSF. 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. .
144
Compared to Smartcard IC Platform Protection Profile a 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. 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.
145
The organisational security policy Limitation of capability and blocking the Loader (P.Lim_Block_Loader)
is directly implemented by the security objective for the TOE ―Capability and availability of the Loader
(O.Cap_Avail_Loader)‖ and the security objective for the TOE environment ―Limitation of capability and
49/96
Samsung Confidential
ST Lite Ver7.2
4 SECURITY OBJECTIVES
blocking the Loader (OE.Lim_Block_Loader)‖. The TOE security objective ―Capability and availability of
the Loader‖ (O.Cap_Avail_Loader)‖ mitigates also the threat ―Abuse of Functionality ― (T.Abuse-Func) if
attacker tries to misuse the Loader functionality in order to manipulate security services of the TOE
provided or depending on IC Dedicated Support Software or user data of the TOE as IC Embedded
Software, TSF data or user data of the smartcard product.
146
The organisational security policy ―Controlled usage to Loader Functionality (P.Ctlr_Loader) is directly
implemented by the security objective for the TOE ―Access control and authenticity for the Loader
(O.Ctrl_Auth_Loader)‖ and the security objective for the TOE environment ―Secure communication and
usage of the Loader (OE.Loader_Usage)‖.
147
The threat ―Masquerade the TOE (T.Masquerade_TOE)‖ is directly covered by the TOE security objective
―Authentication to external entities (O.Authentication)‖ describing the proving part of the authentication
and the security objective for the operational environment of the TOE ―External entities authenticating of
the TOE (OE.TOE_Auth)‖ the verifying part of the authentication.
148
The justification related to the security objectives O.TDES, O.AES, O.RSA, O.ECDSA, O.ECDH and O.SHA
is followings: Since these objectives require the TOE to implement the same specific security functionality
as required by P.Crypto-Service, the organization security policy is covered by the objective.
50/96
Samsung Confidential
ST Lite Ver7.2
5
149
5 EXTENDED COMPONENTS DEFINITION
EXTENDED COMPONENTS DEFINITION
This chapter 5 Extended Components Definition contains the following sections:
5.1 Definition of the family FCS_RNG
5.2 Definition of the Family FMT_LIM
5.3 Definition of the Family FAU_SAS
5.4 Definition of the Family FDP_SDC
5.5 Definition of the Family FIA_API
51/96
Samsung Confidential
ST Lite Ver7.2
5 EXTENDED COMPONENTS DEFINITION
5.1 Definition of the Family FCS_RNG
150
To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the Class
FCS (cryptographic support) is defined here. This family describes the functional requirements for random
number generation used for cryptographic purposes.
FCS_RNG Generation of Random Numbers
151
Family behaviour
152
This family defines quality requirements for the generation of random numbers which are intended to be
used for cryptographic purposes.
153
Component levelling:
FCS_RNG.1
Generation of random numbers requires that random numbers meet a defined
quality metric.
Management:
FCS_RNG.1
There are no management activities foreseen.
Audit:
FCS_RNG.1
There are no actions defined to be auditable.
FCS_RNG.1
Random number generation
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FCS_RNG.1.1
The TSF shall provide a [selection: physical, non-physical true, deterministic,
hybrid physical, hybrid deterministic] random number generator that
implements: [assignment: list of security capabilities].
FCS_RNG.1.2
The TSF shall provide [selection: bits, octets of bits, numbers [assignment: format of
the numbers]] that meet [assignment: a defined quality metric].
52/96
Samsung Confidential
ST Lite Ver7.2
5 EXTENDED COMPONENTS DEFINITION
5.2 Definition of the Family FMT_LIM
154
To define the IT security functional requirements of the TOE an additional family (FMT_LIM) of the Class
FMT (Security Management) is defined here. This family describes the functional requirements for the Test
Features of the TOE. The new functional requirements were defined in the class FMT because this class
addresses the management of functions of the TSF. The examples of the technical mechanism used in the
TOE appropriate to address the specific issues of preventing the abuse of functions by limiting the
capabilities of the functions and by limiting their availability.
155
The family ―Limited capabilities and availability (FMT_LIM)‖ is specified as follows.
FMT_LIM Limited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of functions in a combined
manner. Note that FDP_ACF restricts the access to functions whereas the component Limited Capability
of this family requires the functions themselves to be designed in a specific manner.
Component levelling:
FMT_LIM.1
Limited capabilities requires that the TSF is built to provide only the capabilities
(perform action, gather information) necessary for its genuine purpose.
FMT_LIM.2
Limited availability requires that the TSF restrict the use of functions (refer to
Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by
removing or by disabling functions in a specific phase of the TOE’s life-cycle.
Management:
FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
Audit:
FMT_LIM.1, FMT_LIM.2
There are no actions defined to be auditable.
156
The TOE Functional Requirement ―Limited capabilities (FMT_LIM.1)‖ is specified as follows.
FMT_LIM.1
Limited capabilities
Hierarchical to:
No other components.
FMT_LIM.1.1
The TSF shall be designed and implemented in a manner that limits their
53/96
Samsung Confidential
ST Lite Ver7.2
5 EXTENDED COMPONENTS DEFINITION
capabilities so that in conjunction with ―Limited availability (FMT_LIM.2)‖ the
following policy is enforced [assignment: Limited capability policy].
Dependencies:
157
158
FMT_LIM.2 Limited availability.
The TOE Functional Requirement ―Limited availability (FMT_LIM.2)‖ is specified as follows.
FMT_LIM.2
Limited availability
Hierarchical to:
No other components.
FMT_LIM.2.1
The TSF shall be designed in a manner that limits its availability so that in
conjunction with ―Limited capabilities (FMT_LIM.1)‖ the following policy is
enforced [assignment: Limited availability policy].
Dependencies:
FMT_LIM.1 Limited capabilities.
Application note: The functional requirements FMT_LIM.1 and FMT_LIM.2 assume that there are two
types of mechanisms (limitation of capabilities and limitation of availability) which together shall provide
protection in order to enforce the same policy or two mutual supportive policies related to the same
functionality. This allows e.g. that
(i)
the TSF is provided without restrictions in the product in its user environment but its capabilities are
so
limited that the policy is enforced
or conversely
(ii)
the TSF is designed with high functionality but is removed or disabled in the product in its user
environment.
The combination of both requirements shall enforce the policy.
54/96
Samsung Confidential
ST Lite Ver7.2
5 EXTENDED COMPONENTS DEFINITION
5.3 Definition of the Family FAU_SAS
159
To define the security functional requirements of the TOE an additional family (FAU_SAS) of the Class
FAU (Security Audit) is defined here. This family describes the functional requirements for the storage of
audit data. It has a more general approach than FAU_GEN, because it does not necessarily require the data
to be generated by the TOE itself and because it does not give specific details of the content of the audit
records.
160
The family ―Audit data storage (FAU_SAS)‖ is specified as follows.
FAU_SAS Audit data storage
Family behaviour
This family defines functional requirements for the storage of audit data.
Component levelling
FAU_SAS.1
Requires the TOE to provide the possibility to store audit data.
Management:
FAU_SAS.1
There are no management activities foreseen.
Audit:
FAU_SAS.1
There are no actions defined to be auditable.
FAU_SAS.1
Hierarchical to:
FAU_SAS.1.1
Dependencies:
Audit storage
No other components.
The TSF shall provide [assignment: list of subjects] with the capability to store
[assignment: list of audit information] in the [assignment: type of persistent
memory].
No dependencies.
55/96
Samsung Confidential
ST Lite Ver7.2
5 EXTENDED COMPONENTS DEFINITION
5.4 Definition of the Family FDP_SDC
2
To define the security functional requirements of the TOE an additional family (FDP_SDC.1) of the Class
FDP (User data protection) is defined here.
The family ―Stored data confidentiality (FDP_SDC)‖ is specified as follows.
FDP_SDC.1 Stored data confidentiality
Family behavior
This family provides requirements that address protection of user data confidentiality while these data are
stored within memory areas protected by the TSF. The TSF provides access to the data in the memory
through the specified interfaces only and prevents compromise of their information bypassing these
interfaces. It complements the family ―Stored data integrity (FDP_SDI)‖ which protects the user data from
integrity errors while being stored in the memory.
Component leveling
3
FDP_SDC.1
Requires the TOE to protect the confidentiality of information of the user data in specified
memory areas.
Management:
FDP_SDC.1.
There are no management activities foreseen.
Audit:
There
FDP_SDC.1
are no actions defined to be auditable.
FDP_SDC.1
Stored data confidentiality
Hierarchical to:
No other components.
56/96
Samsung Confidential
ST Lite Ver7.2
Dependencies:
FDP.SDC.1.1
5 EXTENDED COMPONENTS DEFINITION
No dependencies.
The TSF shall ensure the confidentiality of the information of the user data while it
is stored in the [assignment: memory area]
5.5 Definition of the Family FIA_API
4
To describe the IT security functional requirements of the TOE a functional family FIA_API
(Authentication Proof of Identity) of the Class FIA (Identification and authentication) is defined here. This
family describes the functional requirements for the proof of the claimed identity by the TOE and enables
the authentication verification by an external entity. The other families of the class FIA address the
verification of the identity of an external entity by the TOE.
5
The other families of the Class FIA describe only the authentication verification of users’ identity
performed by the TOE and do not describe the functionality of the user to prove their identity. The
following paragraph defines the family FIA_API in the style of the Common Criteria part 2 (cf. [3],
chapter ―Extended components definition (APE_ECD)‖) from a TOE point of view.
6
The family ―Authentication Proof of Identity (FIA_API)‖ is specified as follows.
FIA_API.1
Authentication Proof of Identity
Family behaviour
7
This family defines functions provided by the TOE to prove its identity and to be verified by an external
entity in the TOE IT environment.
Component levelling
FIA_API.1
Authentication Proof of Identity, provides proof of the identity of the TOE, an object or
an authorized user or role to an external entity.
Management:
FIA_API.1
The following actions could be considered for the management functions in FMT: Management of
authentication information used to prove the claimed identity.
Audit:
FIA_API.1
There
are no actions defined to be auditable.
FIA_API.1
Authentication Proof of Identity
Hierarchical to:
No other components.
Dependencies:
No dependencies.
57/96
Samsung Confidential
ST Lite Ver7.2
FIA_API.1.1
5 EXTENDED COMPONENTS DEFINITION
The TSF shall provide a [assignment: authentication mechanism] to prove the
identity of the [selection: TOE, [assignment: object, authorized user or role]] to an
external entity.
58/96
Samsung Confidential
ST Lite Ver7.2
6
161
6 IT security requirements
IT security requirements
This chapter 6 IT Security Requirements contains the following sections:
6.1 Security Functional Requirements for the TOE
6.2 Security Assurance Requirements for the TOE
6.3 Security Requirements Rationale
59/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.1 Security Functional Requirements for the TOE
162
In order to define the Security Functional Requirements the Part 2 of the Common Criteria was used.
However, some Security Functional Requirements have been refined. The refinements are described below
the associated SFR. The operations completed in the ST are marked in italic font.
6.1.1 Malfunctions
163
164
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 Degraded fault tolerance
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s capabilities when the
following failures occur:.
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:.
Dependencies:
No dependencies
Refinement:
The term ―failure‖ above also covers ―circumstances‖. The TOE prevents failures
for the ―circumstances‖ defined above.
Application note:
The secure state is maintained by TOE’s detectors.
6.1.2 Abuse of Functionality
165
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 and implemented in a manner that limits their
capabilities so that in conjunction with ―Limited availability (FMT_LIM.2)‖ the
following policy is enforced:
Dependencies:
FMT_LIM.2 Limited availability.
60/96
Samsung Confidential
ST Lite Ver7.2
166
167
6 IT security requirements
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:
Dependencies:
FMT_LIM.1 Limited capabilities.
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 the test process before TOE Delivery with the capability to
store.
Dependencies:
No dependencies.
6.1.3 Physical Manipulation and Probing
168
The TOE shall meet the requirement ―Stored data confidentiality (FDP_SDC.1)‖ as specified below.
FDP_SDC.1
Stored data confidentiality
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FDP.SDC.1.1
169
The TSF shall ensure the confidentiality of the information of the user data while it
is stored
The TOE shall meet the requirement ―Stored data integrity monitoring and action (FDP_SDI.2)‖ as specified
below.
FDP_SDI.2
Stored data integrity monitoring and action
Hierarchical to:
FDP_SDI.1 Stored data integrity monitoring
Dependencies:
No dependencies.
FDP.SDI.2.1
The TSF shall monitor user data stored in containers
61/96
Samsung Confidential
ST Lite Ver7.2
FDP.SDI.2.2
170
6 IT security requirements
Upon detection of a data integrity error, the TSF shall enforce adevice.
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 by responding automatically such that the SFRs are always
enforced.
Dependencies:
No dependencies.
Refinement:
The TSF will implement appropriate mechanisms to continuously counter
physical manipulation and physical probing. Due to the nature of these attacks
(especially manipulation) the TSF can by no means detect attacks on all of its
elements. Therefore, permanent protection against these attacks is required
ensuring that security functional requirements are enforced. Hence, ―automatic
response‖ means here (i) assuming that there might be an attack at any time and
(ii) countermeasures are provided at any time.
6.1.4 Leakage
171
172
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.
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
62/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
user data. Therefore, it should be understood as to refer to the same Data
Processing Policy defined under FDP_IFC.1 below.
173
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.
Dependencies:
174
FDP_IFF.1 Simple security attributes
The following Security Function Policy (SFP) Data Processing Policy is defined for the requirement ― Subset
information flow control (FDP_IFC.1)‖:
User data of the Composite TOE and TSF data shall not be accessible from the TOE except when the Security IC
Embedded Software decides to communicate the User data of the Composite TOE via an external interface. The
protection shall be applied to confidential data only but without the distinction of attributes controlled by the
Security IC Embedded Software.
6.1.5 Random Numbers (DTRNG FRO)
175
The TOE shall meet the requirement “Quality metric for random numbers (FCS_RNG.1)” as specified below
(Common Criteria Part 2 extended).
FCS_RNG.1/P2High
Random number generation – AIS31 P2-High
Hierarchical to:
No other components.
FCS_RNG.1.1/P2High
The TSF shall provide a physical random number generator that implements
total-failure and online tests of the random source.
FCS_RNG.1.2/P2High
The TSF shall provide 16-bit random numbers generated by a physical random
number generator (referred to as DTRNG FRO) coupled with Von-Neumann postprocessing mechanism that meets AIS31 version 3.1 Functional Classes and
Evaluation Methodology for Physical Random Number Generators, 25 September 2001,
Class P2-High (German metric).
Dependencies:
No dependencies.
FCS_RNG.1/RGS_B1
Random number generation – RGS_B1
Hierarchical to:
No other components.
FCS_RNG.1.1/RGS_B1
The TSF shall provide a physical random number generator that implements
- the rules RègleArchiGVA-1 and the recommendation RecomArchiGVA-1 of
[21] ;
- total failure tests and online tests.
63/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
FCS_RNG.1.2/RGS_B1
The TSF shall provide random numbers that meet the rule RègleArchiGVA-2 of
[21].
Dependencies:
No dependencies.
Warning:
The TSF fulfils some but not all the necessary rules to comply with [21]
regardingrandom numbers generators (RNG). The composite product's RNG will
comply with [21] only when all the rules of §2.4 "Génération d'aléa
cryptographique" of [21] are addressed. In particular, a cryptographic postprocessing must be implemented by the composite developer.
6.1.6 Memory Access Control
176
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 the TOE provides Area
based Memory Access Control.
177
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.
178
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).
179
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.
180
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 access.
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).
181
The TOE shall meet the requirement ―Subset access control (FDP_ACC.1)‖ as specified below.
FDP_ACC.1
Hierarchical to:
Subset access control
No other components.
64/96
Samsung Confidential
ST Lite Ver7.2
FDP_ACC.1.1
Dependencies:
6 IT security requirements
The TSF shall enforce the Memory Access Control Policy
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
The attributes are all the operations related to the data stored in memories.
Hierarchical to:
No other components.
FDP_ACF.1.1
The TSF shall enforce to objects based on the memory area.
FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:.
FDP_ACF.1.3
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules:.
FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects based on the following
additional rules:.
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.
182
FMT_MSA.3
Static attribute initialisation
Hierarchical to:
No other components.
FMT_MSA.3.1
The TSF shall enforce to provide default values for security attributes that are
used to enforce the SFP.
FMT_MSA.3.2
The TSF shall allow 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 to restrict the ability to the security attributes.
65/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
Dependencies:
183
[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:
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:.
Dependencies:
No dependencies
6.1.7 Cryptographic Support
184
FCS_COP.1 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.
185
The following additional specific security functionality is implemented in the TOE:

Triple Data Encryption Standard (TDES)

Advanced Encryption Standard (AES)

Rivest-Shamir-Adleman (RSA) public key asymmetric cryptography, with key size 1280-bit
2048-bit with a granularity of 2 bits (optional)

Elliptic Curve Cryptography (ECC) (optional)
up to
6.1.8 Triple-DES Operation
186
The Triple DES (TDES) operation of the TOE shall meet the requirement ―Cryptographic operation
(FCS_COP.1)‖ as specified below.
FCS_COP.1/TDES
Cryptographic operation – TDES
Hierarchical to:
No other components.
FCS_COP.1.1/TDES
The TSF shall perform encryption and decryption in accordance with a specified
cryptographic algorithm Triple Data Encryption Standard (TDES) and cryptographic
key sizes that meet the following standards:.
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
66/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.1.9 AES Operation
187
The AES operation of the TOE shall meet the requirement ―Cryptographic operation (FCS_COP.1)‖ as
specified below.
FCS_COP.1/AES
Cryptographic operation – AES
Hierarchical to:
No other components.
FCS_COP.1.1/AES
The TSF shall perform in accordance with a specified cryptographic algorithm
Advanced Encryption Standard (AES) and cryptographic key sizes that meet the
following standard:
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
6.1.10 Rivest-Shamir-Adleman (RSA) Operation (optional)
188
The RSA/ECC cryptographic library 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
FCS_COP.1.1/RSA
The TSF shall perform the modular exponentiation part of RSA signature generation and
verification in accordance with a specified cryptographic algorithm Rivest-ShamirAdleman (RSA:standard RSA and RSA-CRT) and cryptographic key sizes that meet
the following standard:
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
6.1.11 Rivest-Shamir-Adleman (RSA) Key Generation (optional)
189
The RSA key generation for the RSA/ECC library shall meet the requirement ―Cryptographic key
generation (FCS_CKM.1)‖ as specified below.
FCS_CKM.1/RSA
Cryptographic key generation
Hierarchical to:
No other components
67/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
FCS_CKM.1.1/RSA
The TSF shall generate the RSA public/private key pair in accordance with the
specified cryptographic key generation algorithm and with the specified
cryptographic key size that meet the following standards:.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
6.1.12 Elliptic Curve DSA Operation (optional)
190
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 the signature generation/verification in accordance with the
specified cryptographic algorithm ECDSA and cryptographic key sizes that meet
the following standard:.
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
6.1.13 Elliptic Curve DSA Key Generation (optional)
191
The key generation for the ECC library shall meet the requirement ―Cryptographic key generation
(FCS_CKM.1)‖ as specified below.
FCS_CKM.1/ECDSA
Cryptographic key generation
Hierarchical to:
No other components
FCS_CKM.1.1/ECDSA The TSF shall generate ECC cryptographic keys in accordance with the
cryptographic key generation algorithm specified in [ANS X9.62] and with the
cryptographic key sizes that meet the following standard:.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
6.1.14 Elliptic Curve Diffie-Hellman (ECDH) Key Agreement (optional)
192
The ECC library of the TOE shall meet the requirement ―Cryptographic operation (FCS_COP.1)‖ as
specified below.
68/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
FCS_COP.1/ECDH
Cryptographic operation
Hierarchical to:
No other components
FCS_COP.1.1/ECDH
The TSF shall perform the key exchange in accordance with the specified
cryptographic algorithm ECDH and cryptographic key sizes that meet the
following standard:.
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
6.1.15 Secure Hash Algorithm (SHA) (optional)
193
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, SHA256, SHA384 and SHA512 and
cryptographic key sizes none that meet the following standard:
Dependencies:
No dependencies
6.1.16 Bootloader
194
The TOE Functional Requirement ―Limited capabilities – Loader(FMT_LIM.1/Loader)‖ is specified as
follows.
FMT_LIM.1/Loader
Limited capabilities
Hierarchical to:
No other components.
FMT_LIM.1.1/Loader
The TSF shall be designed and implemented in a manner that limits its
capabilities so that in conjunction with ―Limited availability (FMT_LIM.2)‖ the
following policy is enforced:.
Dependencies:
FMT_LIM.2 Limited availability.
The TOE Functional Requirement ―Limited availability – Loader (FMT_LIM.2/Loader)‖ is specified as
follows.
69/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
FMT_LIM.2/Loader
Limited availability - Loader
Hierarchical to:
No other components.
FMT_LIM.2.1/Loader
The TSF shall be designed in a manner that limits its availability so that in
conjunction with ―Limited capabilities (FMT_LIM.1)‖ the following policy is
enforced:.
Dependencies:
FMT_LIM.1 Limited capabilities.
The TOE Functional Requirement ―Inter-TSF trusted channel (FTP_ITC.1)‖ is specified as follows.
FTP_ITC.1
Inter-TSF trusted channel
Hierarchical to:
No other components.
FTP_ITC.1.1
The TSF shall provide a communication channel between itself and user that is
logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from
modification or disclosure.
FTP_ITC.1.2
The TSF shall permit another trusted IT product to initiate communication via the
trusted channel.
FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for deploying
Loader.
Dependencies:
No dependencies.
The TOE Functional Requirement ―Basic data exchange confidentiality (FDP_UCT.1)‖ is specified as
follows.
FDP_UCT.1
Basic data exchange confidentiality
Hierarchical to:
No other components.
FDP_UCT.1.1
The TSF shall enforce the Loader SFP to receive user data in a manner protected
from unauthorised disclosure.
Dependencies:
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1
Subset access control, or FDP_IFC.1 Subset information flow control]
The TOE Functional Requirement ―Data exchange integrity (FDP_UIT.1)‖ is specified as follows.
FDP_UIT.1
Data exchange integrity
70/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
Hierarchical to:
No other components.
FDP_UIT.1.1
The TSF shall enforce the Loader SFP to receive user data in a manner protected.
FDP_UIT.1.2
The TSF shall be able to determine on receipt of user data.
Dependencies:
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1
Subset access control, or FDP_IFC.1 Subset information flow control]
The TOE Functional Requirement ―Subset access control - Loader (FDP_ACC.1/Loader)‖ is specified as
follows.
FDP_ACC.1/ Loader
Subset access control - Loader
Hierarchical to:
No other components.
Dependencies:
FDP_ACC.1.1/ Loader The TSF shall enforce the Loader SFP on
Dependencies:
FDP_ACF.1 Security attribute based access control.
Application Note 38: The TOE enforces the Loader SFP by FTP_ITC.1, FDP_UCT.1 and FDP_UIT.1 and
FDP_ACF.1 to describe additional access control rules.
The TOE Functional Requirement ―Security attribute based access control - Loader (FDP_ACF.1/Loader)‖
is specified as follows.
FDP_ACF.1/ Loader
Security attribute based access control - Loader
Hierarchical to:
No other components.
FDP_ACF.1.1/
FDP_ACF.1.1 The TSF shall enforce the Loader SFP to objects based on the
following:
FDP_ACF.1.2/ Loader FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
FDP_ACF.1.3/ Loader FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based
on the following additional rules:
FDP_ACF.1.4/ Loader The TSF shall explicitly deny access of subjects to objects based on the following
additional rules:
Dependencies:
FMT_MSA.3 Static attribute initialization.
71/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.1.17 Authentication Proof of Identity
195
The TOE shall meet the requirement ―Authentication Proof of Identity (FIA_API.1)‖ as specified below.
FIA_API.1
Authentication Proof of Identity
Hierarchical to:
No other components
Dependencies:
No dependencies.
FIA_API.1.1
The TSF must provide to prove the identity of the TOE to an external entity
6.1.18 Summary of Security Functional Requirements
Security Functional Requirements
Limited fault tolerance (FRU_FLT.2)
Failure with preservation of secure state (FPT_FLS.1)
Audit storage (FAU_SAS.1)
Stored data confidentiality (FDP_SDC.1)
Stored data integrity monitoring and action (FDP_SDI.2)
Limited capabilities(FMT_LIM.1)
Limited availability (FMT_LIM.2)
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)
Authentication Proof of Identity (FIA_API.1)
Quality metric for random numbers (FCS_RNG.1)
Table 5 Security Functional Requirements defined in Smart Card IC Protection Profile
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/TDES)
Cryptographic operation (FCS_COP.1/AES)
Cryptographic operation (FCS_COP.1/RSA) (optional)
Cryptographic key generation (FCS_CKM.1/ RSA) (optional)
72/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
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_COP.1/SHA) (optional)
Limited capabilities(FMT_LIM.1/Loader)
Limited availability - Loader(FMT_LIM.2/Loader)
Inter-TSF trusted channel (FTP_ITC.1)
Basic data exchange confidentiality (FDP_UCT.1)
Data exchange integrity (FDP_UIT.1)
Subset access control - Loader (FDP_ACC.1/ Loader)
Security attribute based access control - Loader (FDP_ACF.1/Loader)
Random number generation – P2 High(FCS_RNG.1)
Table 6 Augmented Security Functional Requirements
73/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.2 TOE Assurance Requirements
196
The Security Target will be evaluated according to
Security Target evaluation (Class ASE)
197
The TOE Assurance Requirements for the evaluation of the TOE and its development and operating
environment are those taken from the
Evaluation Assurance Level 6 (EAL6)
198
and augmented by the following component
ASE_TSS.2
199
corresponding to level ―EAL6+‖.
200
All refinements from Protection Profile BSI-PP-0084 version 1.0 for the assurance requirements (ALC_DEL,
ALC_DVS, ALC_CMS, ALC_CMC, ADV_ARC, ADV_FSP, ADV_IMP, ATE_COV, AGD_OPE, AGD_PRE
and AVA_VAN) have to be taken into consideration. In particular the document [12] is used in the context
of vulnerability analysis.
Class ADV: Development
Architectural design
Security Policy Model
Functional Specification
Implementation Representation
TSF Internals
TOE Design
Class AGD: Guidance documents activities
Operational User Guidance
Preparative procedures
(ADV_ARC.1)
(ADV_SPM.1)
(ADV_FSP.5)
(ADV_IMP.2)
(ADV_INT.3)
(ADV_TDS.5)
(AGD_OPE.1)
(AGD_PRE.1)
Class ALC: Life-cycle support
CM Capabilities
(ALC_CMC.5)
CM Scope
(ALC_CMS.5)
Delivery
(ALC_DEL.1)
Development Security
(AULCU_DVS.2)
Life Cycle Definition
(ALC_LCD.1)
Tools and Techniques
(ALC_TAT.3)
Class ASE: Security Target evaluation
Conformance claims
(ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction
(ASE_INT.1)
Security objectives
(ASE_OBJ.2)
Derived security requirements (ASE_REQ.2)
Security problem definition
(ASE_SPD.1)
TOE summary specification
(ASE_TSS.2)
Class ATE: Tests
Coverage
(ATE_COV.3)
Depth
(ATE_DPT.3)
74/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
Functional Tests
Independent Testing
(ATE_FUN.2)
(ATE_IND.2)
Class AVA: Vulnerability assessment
Vulnerability Analysis
75/96
(AVA_VAN.5)
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.3 Security Requirements Rationale
6.3.1 Rationale for the Security Functional Requirements
201
Table 7 below gives an overview, how the security functional requirements are combined to meet the
security objectives. The detailed justification follows after the table.
Objective
O.Leak-Inherent
TOE Security Functional and Assurance Requirements
- FDP_ITT.1 ―Basic internal transfer protection‖
- FPT_ITT.1 ―Basic internal TSF data transfer protection‖
- FDP_IFC.1
―Subset information flow control‖
- AVA_VAN.5 ―Advanced methodical vulnerability analysis‖
O.Phys-Probing
- FDP_SDC.1 ―Stored data confidentiality‖
- FPT_PHP.3 ―Resistance to physical attack‖
O.Malfunction
- FRU_FLT.2 ―Limited fault tolerance
- FPT_FLS.1 ―Failure with preservation of secure state‖
- ADV_ARC.1 ―Architectural Design with domain separation and
non-bypassability‖
O.Phys-Manipulation
- FDP_SDI.2 ―Stored data integrity monitoring and action‖
- FPT_PHP.3 ―Resistance to physical attack‖
O.Leak-Forced
All requirements listed for O.Leak-Inherent
- FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, AVA_VAN.5
plus those listed for O.Malfunction and
O.Phys-Manipulation
- FRU_FLT.2, FPT_FLS.1, FPT_PHP.3, ADV_ARC.1
O.Abuse-Func
- FMT_LIM.1 ―Limited capabilities‖
- FMT_LIM.2 ―Limited availability‖
plus those for O.Leak-Inherent, O.Phys-Probing, O.Malfunction,
O.Phys-Manipulation, O.Leak-Forced
- FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, FPT_PHP.3, FRU_FLT.2,
FPT_FLS.1, ADV_ARC.1
O.Identification
- FAU_SAS.1
―Audit storage‖
O.RND
- FCS_RNG.1 ―Quality metric for random numbers‖ plus those
for O.Leak-Inherent, O.Phys-Probing, O.Malfunction,
O.Phys-Manipulation, O.Leak-Forced
- FDP_ITT.1, FPT_ITT.1, FDP_IFC.1, FPT_PHP.3, FRU_FLT.2,
FPT_FLS.1, AVA_VAN.5, ADV_ARC.1
OE.Resp-Appl
not applicable
76/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
Objective
TOE Security Functional and Assurance Requirements
OE.Process-Sec-IC
not applicable
O.Mem-Access
- FDP_ACC.1 ―Subset access control‖
- FDP_ACF.1 ―Security attribute based access control‖
- FMT_MSA.3 ―Static attribute initialisation‖
- FMT_MSA.1 ―Management of security attributes‖
- FMT_SMF.1 ―Specification of Management Functions‖
O.TDES
- FCS_COP.1/TDES
O.AES
- FCS_COP.1/ AES
O.RSA
- FCS_COP.1/RSA
- FCS_CKM.1/RSA
O.ECDSA
- FCS_COP.1/ ECDSA
- FCS_CKM.1/ ECDSA
O.ECDH
- FCS_COP.1/ ECDH
O.SHA
- FCS_COP.1/SHA
O.Authentication
- FIA_API.1 ‖ Authentication Proof of Identity‖
OE.TOE_Auth
not applicable
O.Cap_Avail_Loader
- FMT_LIM.1/Loader ―Limited capabilities‖
- FMT_LIM.2/Loader ―Limited availability – Loader‖
OE.Lim_Block_Loader
not applicable
O.Ctrl_Auth_Loader
- FTP_ITC.1 "Inter-TSF trusted channel"
- FDP_UCT.1 "Basic data exchange confidentiality"
- FDP_UIT.1 "Data exchange integrity"
- FDP_ACC.1/Loader "Subset access control - Loader"
- FDP_ACF.1/Loader "Security attribute based access control Loader"
OE.Loader_Usage
not applicable
Table 7: Security Requirements versus Security Objectives
202
The justification related to the security objective ―Protection against Inherent Information Leakage
(O.Leak-Inherent)‖ is as follows:
203
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 between separate parts of the TOE or while being processed. This includes that
attackers cannot reveal such data by measurements of emanations, power consumption or other behavior of
the TOE while data are transmitted between or processed by TOE parts.
204
It is possible that the TOE needs additional support by the Security IC Embedded Software (e.g. timing
attacks are possible if the processing time of algorithms implemented in the software depends on the
content of secret). This support must be addressed in the Guidance Documentation. Together with this
77/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
FPT_ITT.1, FDP_ITT.1 and FDP_IFC.1 are suitable to meet the objective.
205
The justification related to the security objective ―Protection against Physical Probing (O.Phys-Probing)‖ is
as follows:
206
The SFR FDP_SDC.1 requires the TSF to protect the confidentiality of the information of the user data
stored in specified memory areas and prevent its compromise by physical attacks bypassing the specified
interfaces for memory access. 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.
207
It is possible that the TOE needs additional support by the Security IC Embedded Software (e. g. to send
data over certain buses only with appropriate precautions). This support must be addressed in the
Guidance Documentation. Together with this FPT_PHP.3 is suitable to meet the objective.
208
The justification related to the security objective ―Protection against Malfunctions (O.Malfunction)‖ is as
follows:
209
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.PhysManipulation). There are two possibilities in this situation: Either the operating conditions are inside 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. The functions implementing
FRU_FLT.2 and FPT_FLS.1 must work independently so that their operation cannot affected by the Security
IC Embedded Software (refer to the refinement). Therefore, there is no possible instance of conditions
under O.Malfunction, which is not covered.
210
The justification related to the security objective ―Protection against Physical Manipulation
(O.Phys-Manipulation)‖ is as follows:
211
The SFR FDP_SDI.2 requires the TSF to detect the integrity errors of the stored user data and react in case of
detected errors. 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.
212
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
6.1). This support must be addressed in the Guidance Documentation. Together with this FPT_PHP.3 is
suitable to meet the objective.
213
The justification related to the security objective ―Protection against Forced Information Leakage
(O.Leak-Forced)― is as follows:
214
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.
215
The justification related to the security objective ―Protection against Abuse of Functionality
78/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
(O.Abuse-Func)‖ is as follows:
216
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.
217
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. The relevant objectives are also listed in Table 7.
218
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.
219
The justification related to the security objective ―TOE Identification (O.Identification)― is as follows:
220
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. The technical capability of the TOE to store Initialisation Data and/or Pre-personalisation
Data is provided according to FAU_SAS.1.
221
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 security relevant 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.
222
The objective must be supported 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 AGD and ALC.
223
The justification related to the security objective ―Random Numbers (O.RND)‖ is as follows:
224
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.
225
Random numbers are often used by the Security IC 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.
226
Depending on the functionality of specific TOEs the Security IC 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
79/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
about the produced random numbers is available to an attacker.
227
It was chosen to define FCS_RNG.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.)
228
The security objective ―Capability and availability of the Loader (O.Cap_Avail_Loader) is directly covered
by the SFR FMT_LIM.1/Loader and FMT_LIM.2/Loader.
229
The security objective Access control and authenticity for the Loader (O.Ctrl_Auth_Loader) is covered by
the SFR as follows:
230
The SFR FDP_ACC.1/Loader defines the subjects, objects and operations of the Loader SFP enforced by the
SFR FTP_ITC.1, FDP_UCT.1, FDP_UIT.1 and FDP_ACF.1/Loader.
231
The SFR FTP_ITC.1 requires the TSF to establish a trusted channel with assured identification of its end
points and protection of the channel data from modification or disclosure.
232
The SFR FDP_UCT.1 requires the TSF to receive data protected from unauthorised disclosure.
233
The SFR FDP_UIT.1 requires the TSF to verify the integrity of the received user data.
234
The SFR FDP_ACF.1/Loader requires the TSF to implement access control for the Loader functionality.
235
The FCS_COP.1/TDES meets the security objective ―Cryptographic service Triple-DES (O.TDES)‖.
236
The FCS_COP.1/AES meets the security objective ―Cryptographic service AES (O.AES)‖.
237
The security functional requirement(s) ―Cryptographic operation
(FCS_COP.1/RSA,FCS_COP.1/ECDSA,ECDH)‖ exactly requires those functions to be implemented which
are demanded by O.RSA or O.ECC. FCS_CKM.1 supports the generation of keys needed for this
cryptographic operations(optional). Therefore, FCS_COP.1/RSA, FCS_COP.1/ECDSA, FCS_COP.1/ECDH,
FCS_CKM.1/RSA and FCS_CKM.1/ ECDSA are suitable to meet the security objective.
238
The FCS_COP.1/SHA meet the security objective ―Cryptographic service SHA (O.SHA)‖.
239
The security objective ―Authentication to external entities (O.Authentication) is directly covered by the SFR
FIA_API.1..
240
The justification related to the security objective ―Area based Memory Access Control (O.Mem-Access)‖ is
as follows:
241
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.
242
The security functional requirement ―Static attribute initialisation (FMT_MSA.3)‖ requires that the TOE
provides default values for the security attributes. Since the TOE is a hardware platform these default
values are generated by the reset procedure. Therefore FMT_MSA.3 is suitable to meet the security
80/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
objective O.Mem-Access.
243
The security functional requirement ―Management of security attributes (FMT_MSA.1)‖ requires that the
ability to change the security attributes is restricted to privileged subject(s). It ensures that the access control
required by O.Mem-Access can be realised using the functions provided by the TOE. Therefore
FMT_MSA.1 is suitable to meet the security objective O.Mem_Access.
244
Finally, the security functional requirement ―Specification of Management Functions (FMT_SMF.1)‖ is used
for the specification of the management functions to be provided by the TOE as required by
O.MEM_ACCESS. Therefore, FMT_SMF.1 is suitable to meet the security objective O.Mem_Access.
245
The justification related to the security objective ―Protection during Packaging, Finishing and
Personalisation (OE.Process-Sec-IC)‖ is as follows:
246
The Composite Product Manufacturer has to use adequate measures to fulfil OE.Process-Sec-IC. Depending
on the security needs of the application, the Security IC Embedded Software may have to support this for
instance by using appropriate authentication mechanisms for personalisation functions.
6.3.2 Dependencies of Security Functional Requirements
247
Table 8 below lists the security functional requirements defined in this Protection Profile, their
dependencies and whether they are satisfied by other security requirements defined in this Protection
Profile. The text following the table discusses the remaining cases.
Security Functional Requirement
Dependencies
Fulfilled by security requirements
FRU_FLT.2
FPT_FLS.1
Yes
FPT_FLS.1
None
No dependency
FMT_LIM.1
FMT_LIM.2
Yes
FMT_LIM.2
FMT_LIM.1
Yes
FAU_SAS.1
None
No dependency
FDP_SDC.1
None
No dependency
FDP_SDI.2
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_RNG.1
None
No dependency
FCS_CKM.4
Yes (by environment, see discussion
below)
FDP_ITC.1 or FDP_ITC.2 (if
not FCS_CKM.1) or
FCS_CKM.1
Yes (by environment, see discussion
below)
FCS_CKM.4
Yes (by environment, see discussion
below)
FDP_ITC.1 or FDP_ITC.2 (if
Yes (by environment, see discussion
FCS_COP.1 /TDES
FCS_COP.1 /AES
81/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
Security Functional Requirement
Fulfilled by security requirements
not FCS_CKM.1) or
FCS_CKM.1
below)
FCS_CKM.1 /RSA
(optional)
FCS_COP.1 or FCS_CKM.2
FCS_CKM.4
Yes
FCS_COP.1/RSA
(optional)
FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
Yes
FCS_COP.1/ECDSA
(optional)
FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.4
Yes
FCS_COP.1/ECDH
(optional)
FDP_ITC.1 or FDP_ITC.2, or
FCS_CKM.1
FCS_CKM.4
Yes
FCS_CKM.1 /ECDSA (optional)
FCS_COP.1 or FCS_CKM.2
FCS_CKM.4
Yes
FDP_ITC.1 or FDP_ITC.2
Yes
See discussion below
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
FMT_LIM.1/Loader
FMT_LIM.2
Yes
FMT_LIM.2/Loader
FMT_LIM.1
Yes
FTP_ITC.1
None
No dependency
FDP_UCT.1
FTP_ITC.1 or FTP_TRP.1,
FDP_ACC.1 or FDP_IFC.1
Yes
FDP_UIT.1
FTP_ITC.1 or FTP_TRP.1,
FDP_ACC.1 or FDP_IFC.1
Yes
FDP_ACC.1/ Loader
FDP_ACF.1
Yes
FDP_ACF.1/ Loader
FMT_MSA.3
Yes
FIA_API.1
None
FCS_COP.1/SHA (optional)
Table 8
248
Dependencies
No dependency
Dependencies of the Security Functional Requirements
Part 2 of the Common Criteria defines the dependency of FDP_IFC.1 (information flow control policy
82/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
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.
249
In particular the security functional requirements providing resistance of the hardware against
manipulations (e. g. FPT_PHP.3) support all other more specific security functional requirements (e. g.
FCS_RNG.1) because they prevent an attacker from disabling or circumventing the latter. Together with the
discussion of the dependencies above this shows that the security functional requirements build a mutually
supportive whole.
250
The functional requirements FCS_CKM.1 and FCS_CKM.4 which are dependent to FCS_COP.1/DES and
FCS_COP.1/AES are not included in this Security Target since the TOE only provides an engine for
encryption and decryption. But the Security IC Embedded Software may fulfill these requirements related
to the needs of the implemented application. The dependent requirements of FCS_COP.1/DES and
FCS_COP.1/AES concerning these functions shall be fulfilled by the environment (Security IC Embedded
Software).
251
The TOE provides the cryptographic key generation for RSA and ECDSA by the TOE (FCS_CKM.1/RSA,
FCS_CKM.1/ECDSA), but it is up to the Smart Card Embedded Software’s security policy to adopt the
cryptographic key generation by the TOE or use the cryptographic key generation by the Smart Card
Embedded Software. The dependent requirements of FCS_COP.1/RSA and FCS_COP.1/ECDSA shall be
fulfilled by the environment (Security IC Embedded Software).
252
The functional requirement FCS_CKM.1 which is dependent to FCS_COP.1/ECDH is not included in this
Security Target. But the Security IC Embedded Software may fulfill this requirement related to the needs of
the implemented application. The dependent requirements of FCS_COP.1/ECDH concerning this function
shall be fulfilled by the environment (Security IC Embedded Software).
253
The functional requirement FCS_CKM.4 which is dependent to FCS_COP.1/RSA, FCS_COP.1/ECDH and
FCS_COP.1/ECDSA are not included in this Security Target. But the Security IC Embedded Software may
fulfill this requirement related to the needs of the implemented application. The dependent requirements of
FCS_COP.1/RSA, FCS_COP.1/ECDH and FCS_COP.1/ECDSA concerning this function shall be fulfilled
by the environment (Security IC Embedded Software).
254
Since FCS_COP.1/SHA is a keyless algorithm, the dependencies FCS_CKM.1 and FCS_CKM.4 are not
required.
255
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.
83/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
6.3.3 Rationale for the Assurance Requirements
256
The assurance level EAL6 and the augmentation with the requirement ASE_TSS.2 were chosen to
demonstrate that the TOE fulfills the high-level Common Criteria requirements.
6.3.3.1 ADV_SPM.1 Formal TOE Security Policy Model
257
The formally modeled security policy consists of the complete TSF access control.
6.3.3.2 ASE_TSS.2 TOE Summary specification with architectural design summary
258
The augmentation ASE_TSS.2 is required in order to provide the potential users (e.g. the embedded
software developers) with a succinct but comprehensive explanation on the TOE security functions that
protect it against interference, logical tampering and bypass. This description is also necessary to establish
the component ASE_TSS.2 for any composed TOE.
259
This assurance component is a higher hierarchical component to EAL6. ASE_TSS.2 has two dependencies
(ASE_INT.1 and ASE_REQ.1) that both are satisfied by this TOE.
6.3.4 Security Requirements are Internally Consistent
260
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.
261
The security functional requirements FDP_SDC.1 and FDP_SDI.2 address the protection of user data in the
specified memory areas against compromise and manipulation. The security functional requirement
FPT_PHP.3 makes it harder to manipulate data. This protects the primary assets identified in Section 3.1
and other security features or functionality which use these data.
262
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. 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 Security IC 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_RNG.1, and those implemented in the
Security IC Embedded Software.
263
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. 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 Security IC 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_RNG.1, and those implemented in the Security IC Embedded
Software.
84/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
264
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 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 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).
265
Physical probing (refer to FPT_PHP.3) shall directly avert the disclosure of primary assets. 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 Security IC Embedded Software. Details
depend on the implementation.
266
Leakage (refer to FDP_ITT.1, FPT_ITT.1) shall directly avert the disclosure of primary assets. 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 Security IC
Embedded Software (FDP_ITT.1) or provided by the TOE (FPT_ITT.1). Details depend on the
implementation.
267
The user data of the Composite TOE are treated as required to meet the requirements defined for the
specific application context (refer to Treatment of user data of the Composite TOE (A.Resp-Appl)).
However, the TOE may implement additional functions. This can be a risk if their interface cannot
completely be controlled by the Security IC 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.
268
The combination of the security functional requirements FMT_LIM.1 and FMT_LIM.2 ensures that
(especially after TOE Delivery) these additional functions cannot be abused by an attacker to (i) disclose or
manipulate user data of the Composite TOE, (ii) to manipulate (explore, bypass, deactivate or change)
security features or services of the TOE or of the Security IC Embedded Software or (iii) to enable other
attacks on the assets. Hereby the binding between these two security functional requirements is very
important:
269
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 vulnerable1, it is important to limit the capabilities of the functions in order to limit the
possible benefit for an attacker.
270
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 of the
Composite TOE, to manipulate security features or functions of the TOE or of the Security IC Embedded
Software or to enable an attack. Therefore, if an attacker could benefit from using such functions1F, it is
85/96
Samsung Confidential
ST Lite Ver7.2
6 IT security requirements
important to limit their availability so that an attacker is not able to use them.
271
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.
272
It is important to avert malfunctions of TSF and of security functions implemented in the Security IC
Embedded Software (refer to above). There are two security functional requirements which ensure that
malfunctions cannot 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 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.
273
The security functional requirements required to meet the security objectives O.Leak-Inherent, O.PhysProbing, O.Malfunction, O.Phys-Manipulation and O.Leak-Forced protect the cryptographic algorithms
(FCS_COP.1) and the cryptographic key generations (FCS_CKM.1). Therefore these security functional
requirements support the secure implementation and operation of FCS_COP.1 and FCS_CKM.1.
274
Parts of the Smartcard IC Embedded Software may cause security violations by accidentally or deliberately
accessing restricted data (which may include code). In order to avert the memory access violation it is
important to the security functional requirement defining the scope where the Memory Access Policy is
applied (FDP_ACC.1) and the security functional requirement defining the Memory Access
Policy(FDP_ACF.1), and the security functional requirement ensuring the default value of security
attribute(FMT_MSA.3) and the security functional requirement managing security attribute ( FMT_MSA.1)
and the security functional requirement performing security management function(FMT_SMF.1) are
effective and bind well.
275
Two refinements from the PP [5] have to be discussed here in the ST as the assurance level is increased. The
refinement for ALC_CMS from the PP [5] can even be applied at the assurance level EAL 5 augmented with
ALC_CMS.5. The assurance component ALC_CMS.4 is augmented to ALC_CMS.5 with aspects regarding
the configuration control system for the TOE. The refinement is not touched. The refinement for ADV_FSP
from the PP [5] can even be applied at the assurance level EAL 5 augmented with ADV_FSP.5. The
assurance component ADV_FSP.4 is extended to ADV_FSP.5 with aspects regarding the description level.
The level is increased from informal to semi-formal with informal description. The refinement is not
touched by this measure.
86/96
Samsung Confidential
ST Lite Ver7.2
7
276
7 TOE SUMMARY SPECIFICATION
TOE SUMMARY SPECIFICATION
This chapter 7 TOE Summary Specification contains the following sections:
7.1 List of Security Functional Requirements
87/96
Samsung Confidential
ST Lite Ver7.2
7 TOE SUMMARY SPECIFICATION
7.1 List of Security Functional Requirements
SFR1: FPT_FLS.1: Failure with preservation of secure state
277 The detection thresholds of TOE’s detectors are inside the operating range of the TOE.
SFR2: FRU_FLT.2: Limited fault tolerance
278 All operating signals are filtered/regulated in order to prevent malfunction.
SFR3: FPT_PHP.3: Resistance to physical attacks
279 This requirement is achieved by security feature as the shield must be removed and bypassed in order to
perform physical intrusive attacks.
SFR4: FDP_ACC.1: Subset access control
280 This requirement is achieved by security register access control.
SFR5: FDP_ACF.1: Security attributes based access control.
281 This is covered by the Privilege and User modes of the TOE.
SFR6: FMT_MSA.3: Static attribute initialization.
282 All Special Function Registers have DEFAULT values.
SFR7: FMT_MSA.1: Management of security attributes.
283 This is achieved with the MPU, OPRMON and CPAMON feature.
SFR8: FMT_SMF.1: Specification of management functions.
284 This is achieved via access.
SFR9: FAU_SAS.1: Audit Storage
285 This is fulfilled by the traceability/identification data written once.
SFR10: FMT_LIM.1: Limited capabilities
286 TEST mode can be accessed.
88/96
Samsung Confidential
ST Lite Ver7.2
7 TOE SUMMARY SPECIFICATION
SFR11: FMT_LIM.2: Limited availabilities
287 TEST mode can be accessed only by the administrator.
SFR12: FDP_IFC.1: Subset information flow control
288 Memory Encryption: This is achieved by the function protects the memory contents of the TOE.
SFR13: FDP_ITT.1: Basic internal transfer protection
289 This requirement is achieved by the combination of the TOE security features TOE features as it is
unpractical to get access to internal signals and interpret them.
SFR14: FPT_ITT.1: Basic internal TSF data transfer protection
290 This requirement is achieved by the combination of the TOE security features TOE features as it is
unpractical to get access to internal signals and interpret them.
SFR15: FCS_RNG.1: Random number generation
291 This requirement is ensured by the design of the random number generation algorithm.
SFR17: FCS_COP.1: Cryptographic operation
292 This requirement is covered by the TOE.
293
Triple Data Encryption Standard Engine
This function is used for encrypting and decrypting data using the Triple DES symmetric algorithm.
294
AES (Advanced Encryption Standard)
This function supports the AES operation.
TORNADO2MX2 RSA Cryptographic Library as part of Secure RSA/ECC library (optional)
295
This function assists in the acceleration of modulo exponentiations required in the RSA
encryption/decryption algorithm. (FCS_COP.1/RSA)
TORNADO2MX2 ECC Cryptographic Library as part of Secure RSA/ECC library (optional)
296
This function assists in the acceleration of required for the ECC cryptographic operations including the
ECDSA signature generation/verification and the ECDH secret key derivation. (FCS_COP.1/ECDSA and
FCS_COP.1/ECDH)
297
TORNADO2MX2 RSA/ECC library provides a set of functions to implement elliptic curve cryptographic
algorithms. In particular, it provides some functions to implement the ECDSA signature
generation/verification and the ECDH secret key derivation.
298
The TORNADO2MX2 Secure RSA/ECC library provides the functions to calculate hash (digest) values
using the SHA1, SHA224, SHA256, SHA384 and SHA 512 algorithm as specified in [FIPS PUB 180-3], but
only the functions related to SHA224, SHA256, SHA384 and SHA512 listed below are in the scope of this
evaluation:
89/96
Samsung Confidential
ST Lite Ver7.2
7 TOE SUMMARY SPECIFICATION
SFR17: FCS_CKM.1: Cryptographic key generation
299
This requirement is covered by the TOE for the RSA/ECC key generation. (optional)
SFR18: Limited capabilities - Loader(FMT_LIM.1/Loader)
300
This requirement is achieved by the changing.
SFR19: Limited availability – Loader (FMT_LIM.2/Loader)
301
This requirement is achieved by the changing.
SFR20: Inter-TSF trusted channel (FTP_ITC.1)
302
This requirement is achieved by processing.
SFR21: Basic data exchange confidentiality (FDP_UCT.1)
303
This requirement is achieved by function.
SFR22: Data exchange integrity (FDP_UIT.1)
304
This requirement is achieved by function.
SFR23: Subset access control - Loader (FDP_ACC.1/ Loader)
305
This requirement is achieved by functions.
SFR24: Security attribute based access control - Loader (FDP_ACF.1/Loader)
306
This is covered by function.
SFR25: Stored data confidentiality (FDP_SDC.1)
307
This requirement is achieved by the combination of the TOE security features TOE features 1) to 4) as it is
unpractical to get access to internal signals and interpret them.
SFR26: Stored data integrity monitoring and action (FDP_SDI.2)
308
This requirement is achieved by functions.
SFR27: Authentication Proof of Identity (FIA_API.1)
309
This requirement is achieved by function.
90/96
Samsung Confidential
ST Lite Ver7.2
7 TOE SUMMARY SPECIFICATION
7.2 Architectural Design Summary
310
The TOE claims the assurance requirement ASE_TSS.2, the security architectural information on a very high
level is included in the TSS to inform the embedded software developers on how the TOE protects itself
against interference, logical tampering and bypass.
311
Interference
312
Interference consists in interfering in the TSF in order to get access to assets.
313
Logical tampering
314
Logical tampering consists in get access to the assets by a logical means (in contrast with physical
tampering). For this TOE, logical tampering may be used on
315
316

the access control

the information flow control
The access control is enforced by the following security functions: ―Security registers access control‖,
―Invalid address access‖, ―Access rights for the code executed in FLASH‖, ―Access control for Operating
state‖, ―Flash protection about Write operation‖.
The information flow control is enforced by the following security function ―Memory Encryption‖.
317
Bypass
318
Non-bypassability is a property that the security functionality of the TSF is always invoked. For this TOE,
bypassing a security function may be caused by
319
A physical perturbation on the IC: protection against this bypass if ensured by the security functions
―Static Address/Data scrambling for bus and memory‖, ―Synthesizable processor core‖, ―Detectors‖,
―Filters‖
320
Switching back from Normal mode to Test mode in order to get more privilege: protection against this
bypass if ensured by the security functions ―Non-reversibility of TEST mode and NORMAL mode‖
321
Masking the security errors: protection against this bypass if ensured by the security function ―Security
registers access control‖
91/96
Samsung Confidential
ST Lite Ver7.2
8
8 Annex
Annex
8.1 Glossary
Application Data
All data managed by the Security IC Embedded Software in the application context. Application data comprise all
data in the final Security IC.
Composite Product Integrator
Role installing or finalising the IC Embedded Software and the applications on platform transforming the TOE
into the unpersonalised Composite Product after TOE delivery. The TOE Manufacturer may implement IC
Embedded Software delivered by the Security IC Embedded Software Developer before TOE delivery (e.g. if the
IC Embedded Software is implemented in ROM or is stored in the non-volatile memory as service provided by
the IC Manufacturer or IC Packaging Manufacturer)
Composite Product Manufacturer
The Composite Product Manufacturer has the following roles (i) the Security IC Embedded Software Developer
(Phase 1), (ii) the Composite Product Integrator (Phase 5) and (iii) the Personaliser (Phase 6). If the TOE is
delivered after Phase 3 in form of wafers or sawn wafers (dice) he has the role of the IC Packaging Manufacturer
(Phase 4) in addition.
End-consumer
User of the Composite Product in Phase 7.
IC Dedicated Software
IC proprietary software embedded in a Security IC (also known as IC firmware) and developed by the IC
Developer. Such software is required for testing purpose (IC Dedicated Test Software) but may provide additional
services to facilitate usage of the hardware and/or to provide additional services (IC Dedicated Support Software).
IC Dedicated Test Software
That part of the IC Dedicated Software (refer to above) which is used to test the TOE before TOE Delivery but
which does not provide any functionality thereafter.
IC Dedicated Support Software
That part of the IC Dedicated Software (refer to above) which provides functions after TOE Delivery. The usage of
parts of the IC Dedicated Software might be restricted to certain phases.
Initialisation Data
Initialisation Data defined by the TOE Manufacturer to identify the TOE and to keep track of the Security IC’s
production and further life-cycle phases are considered as belonging to the TSF data. These data are for instance
92/96
Samsung Confidential
ST Lite Ver7.2
8 Annex
used for traceability and for TOE identification (identification data).
Integrated Circuit (IC)
Electronic component(s) designed to perform processing and/or memory functions.
Pre-personalisation Data
Any data supplied by the Card Manufacturer that is injected into the non-volatile memory by the Integrated
Circuits manufacturer (Phase 3). These data are for instance used for traceability and/or to secure shipment
between phases.
Security IC
Composition of the TOE, the Security IC Embedded Software, User Data and the package (the Security IC carrier).
Security IC Embedded Software
Software embedded in a Security IC and normally not being developed by the IC Designer. The Security IC
Embedded Software is designed in Phase 1 and embedded into the Security IC in Phase 3 or in later phases of the
Security IC product life-cycle. Some part of that software may actually implement a Security IC application others
may provide standard services. Nevertheless, this distinction doesn’t matter here so that the Security IC
Embedded Software can be considered as being application dependent whereas the IC Dedicated Software is
definitely not.
Security IC Product
Composite product which includes the Security Integrated Circuit (i.e. the TOE) and the Embedded Software and
is evaluated as composite target of evaluation in the sense of the Supporting Document
TOE Delivery
The period when the TOE is delivered which is either (i) after Phase 3 (or before Phase 4) if the TOE is delivered in
form of wafers or sawn wafers (dice) or (ii) after Phase 4 (or before Phase 5) if the TOE is delivered in form of
packaged products.
TOE Manufacturer
The TOE Manufacturer must ensure that all requirements for the TOE and its development and production
environment are fulfilled. The TOE Manufacturer has the following roles: (i) IC Developer (Phase 2) and (ii) IC
Manufacturer (Phase 3). If the TOE is delivered after Phase 4 in form of packaged products, he has the role of the
(iii) IC Packaging Manufacturer (Phase 4) in addition.
TSF data
Data created by and for the TOE, that might affect the operation of the TOE. This includes information about the
TOE’s configuration, if any is coded in non-volatile non-programmable memories (ROM), in specific circuitry, in
non-volatile programmable memories (for instance E2PROM) or a combination thereof.
User data
93/96
Samsung Confidential
ST Lite Ver7.2
8 Annex
All data managed by the Smartcard Embedded Software in the application context. User data comprise all data in
the final Smartcard IC except the TSF data.
8.2 Abbreviations
CC
Common Criteria
EAL
Evaluation Assurance Level
IT
Information Technology
PP
Protection Profile
ST
Security Target
TOE
Target of Evaluation
TSC
TSF Scope of Control
TSF
TOE Security Functionality
TSFI
TSF Interface
TSP
TOE Security Policy
94/96
Samsung Confidential
ST Lite Ver7.2
8 Annex
8.3 References
[1] Common Criteria, Part 1: Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model, Version 3.1, Revision 4, September 2012, CCMB-2012-09-001
[2] Common Criteria, Part 2: Common Criteria for Information Technology Security Evaluation, Part 2: Security
Functional Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-002
[3] Common Criteria, Part 3: Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Components, Version 3.1, Revision 4, September 2012, CCMB-2012-09-003
[4] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1,
Revision 4, September 2012, CCMB-2012-09-004
[5] Eurosmart Security IC Platform Protection Profile with Augmentation Packages, Version 1.0, BSI-CC-PP-00842014.
[6] AIS31: Functionality classes and evaluation methodology for true (physical) random number generators,
Version 1, 25.09.2001, Bundesamt fü r Sicherheit in der Informationstechnik
[7] A proposal for: Functionality classes for random number generators, Version 2.0, 18.09.2011, Bundesamt fü r
Sicherheit in der Informationstechnik
[8] 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
[9] [FIPS SP800-67] Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, version 1.1
[10] [FIPS 197] Advanced Encryption Standard (AES), 2001-11-26
[11] [ISO/IEC 14888-2:2008] - Information technology -- Security techniques-- Digital signatures with appendix -Part 2: Integer factorization based mechanisms.
[12] CC Supporting Document, Mandatory Technical Document, "Application of Attack Potential to Smartcards":
version 2.9 (January 2013) as recommended by SOG-IS.
[13] [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.
[14] [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
[15] [FIPS PUB 180-3] U.S. Department of Commerce / National Bureau of Standards, Secure Hash Algorithm,
FIPS PUB 180-3, 2008-October
[16] [Brainpool curves] ECC Brainpool Standard Curves and Curve generation, M. Lochter, v1.0, www.eccbrainpool.org
[17] [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
[18] [SEC-recommended curves] SEC2: Recommended Elliptic Curve Domain Parameters, Certicom Research,
v1.0, September 20, 2000.
[19] [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
[20] [SCA on Prime Gen] T. Finke, M. Gebhardt and W. Schindler, A New Side-Channel Attack on RSA Prime
Generation, CHES 2009, LNCS 5747, pp. 141-155, 2009.
[17] [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
[18] [SEC-recommended curves] SEC2: Recommended Elliptic Curve Domain Parameters, Certicom Research,
v1.0, September 20, 2000.
95/96
Samsung Confidential
ST Lite Ver7.2
8 Annex
[19] [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
[20] [SCA on Prime Gen] T. Finke, M. Gebhardt and W. Schindler, A New Side-Channel Attack on RSA Prime
Generation, CHES 2009, LNCS 5747, pp. 141-155, 2009.
[21] Les règles et recommandations concernant le choix et le dimensionnement de mécanismes cryptographiques.
Annexe B1 du RGS 2.0. Version 2.03, 21/02/2014, ANSSI. http://www.ssi.gouv.fr/uploads/2015/01/RGS_v-20_B1.pdf
96/96