CC-T6NC9-ST-ENG-002
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
T6NC9 Integrated Circuit
with Crypto Library v1.1
Security Target
2 Apri 2009
Version 2.10
TOSHIBA CORPORATION
Communication and Multimedia System LSI Group 4
Wireless and Multimedia System LSI Department
System LSI DivisionⅠ
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Change History
No Version Date Chapter Content Name
1 0.1 31/03/2006 New
2
0.2 10/07/2006 SF description refined
LFSR is added to SFR and SF.
3
0.3 21/07/2006 §2 refined
Memory access control was deleted.
4 0.4 31/08/2006 T6NC9 (TOE ID)
5 0.5 01/04/2007 Update for version 3.1 CC
6 0.6 04/04/2007 Update by TOSHIBA
7
0.7
14/05/2007
After meeting Toshiba and Brightsight
§2.1 added attack potential doc.
§5.2.1 Update of SFRs
§5.4.2 Update of dependencies table
and some small changes
8
0.8
07/12/2007
Processing evaluator comments after
first evaluation cycle:
- removed inconsistencies
- Include HW config in TOE scope
- Define operational mode of the TOE
- Update TSS
9
0.9
11/12/2007
Processing evaluator comments.
- SFR definitions
- RNG adjustments
10 0.91 17/03/2008 - TOE version revised
11 0.92 18/03/2008 -
12 0.93 31/03/2008 Dependencies, PP reference
13
0.94
23/04/2008
Clarification physical RNG
14 1.00 18/Aug/2008 §6.2 countermeasure against SPA/DPA
15 2.00 13/Jan/2009 Added diced wafer delivery format
16 2.10 2/April/2009 TOE table fixed.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Table of contents
1. ST Introduction ................................................... 1
1.1. ST identifiers ................................................... 1
1.2. TOE overview ..................................................... 1
1.3. TOE description .................................................. 3
1.3.1. Physical scope ........................................................... 3
1.3.2. Logical scope ............................................................ 5
2. Conformance claim ................................................. 7
2.1. CC Conformance ................................................... 7
2.2. PP Claim ......................................................... 7
2.3. Package claim .................................................... 7
2.4. Conformance claim rationale ...................................... 7
3. Security problem definition ....................................... 8
3.1. Description of Assets ............................................ 8
3.2. Threats .......................................................... 8
3.3. Organisational security policies ................................. 8
3.4. Assumptions ..................................................... 10
4. Security objectives .............................................. 11
4.1. Security objectives for the TOE ................................. 11
4.2. Security objectives for the security IC embedded software development
environment ........................................................... 12
4.3. Security objectives for the operational environment ............. 13
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
4.4. Security objectives rationale ................................... 13
5. Security requirements ............................................ 15
5.1. Definitions ..................................................... 15
5.2. Security Functional Requirements (SFR) .......................... 15
5.2.1. SFRs derived from the Security IC Platform Protection Profile ........... 15
5.2.2. SFRs regarding cryptographic functionality .............................. 17
5.3. Security Assurance Requirements (SAR) ........................... 18
5.4. Security requirements rationale ................................. 19
5.4.1. Security Functional Requirements (SFR) .................................. 19
5.4.2. Dependencies of the SFRs ................................................ 20
5.4.3. Security Assurance Requirements (SAR) ................................... 21
6. TOE summary specification ........................................ 22
6.1. Malfunction ..................................................... 22
6.2. Leakage ......................................................... 23
6.3. Physical manipulation and probing ............................... 24
6.4. Abuse of functionality and Identification ....................... 25
6.5. Random numbers .................................................. 25
6.6. Cryptographic operations ........................................ 25
6.6.1. DES ..................................................................... 25
6.6.2. RSA ..................................................................... 26
7. Reference ........................................................ 27
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
1. ST Introduction
This Security Target (ST) is built upon the Security IC Platform Protection Profile [5]. Registered
and Certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference
BSI-PP-0035.
This chapter presents the ST reference and for the Target Of Evaluation (TOE) the reference, an
overview and a description.
1.1. ST identifiers
ST reference: T6NC9 Integrated Circuit with Crypto Library v1.1 Security Target, version 2.1,
2 April 2009
ST Status: Final Version.
TOE reference: T6NC9 Integrated Circuit with Crypto Library v1.1
1.2. TOE overview
The T6NC9 Integrated Circuit with Crypto Library v1.1 (Target of Evaluation – TOE_ is an
Integrated Circuit (diced wafer) with a DES and RSA crypto library. The TOE that is described in
this ST is a single chip microcontroller (hardware, security IC dedicated software and security IC
dedicated test software) that is used in smartcards. While a smartcard may utilise the contact type
or contact less type communication methods, this TOE utilises only the contact type communication
method. Any other security IC embedded software is not part of the TOE.
The TOE stated in this ST is a highly functional and security single chip microcontroller with a
contact type communication interface. The objective of the TOE is to protect the IT security of the
smartcard usage that are intended to be used for banking, finance or electronic commerce, etc. The
intended usage of the operational TOE is by consumers (end-user). The TOE is delivered to a
composite product manufacturer to load security IC embedded software in the ROM. The TOE does
not allow access to security IC dedicated test software when the TOE is delivered to the composite
product manufacturer or used by the end-user.
Protected information is in general secret data as Personal Identification Numbers,
Balance Value (Stored Value Cards), and Personal Data Files. Other protected information is the
data representing the access rights; these include any cryptographic algorithms and keys needed
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
for accessing and using the services provided by the system through use of the smartcard.
The IC that is used in a smartcard consists of the central processing unit (CPU), memory element
(ROM, RAM, NV memory.), and circuit for contact external interface that have been integrated with
consideration given to tamper resistance. The security IC dedicated software that is incorporated in
the memory element is capable of providing security functions for the various security IC embedded
software.
The increase in the number and complexity of applications in the smartcard market is reflected in
the increase of the level of data security required. The security needs for a smartcard can be
summarised as being able to counter those who want to defraud, gain unauthorised access to data
and control a system using a smartcard. Therefore it is mandatory to:
• maintain the integrity and the confidentiality of the content of the smartcard memory as
required by the security IC embedded software the smartcard is built for and
• maintain the correct execution of the security IC embedded software residing on the card.
This requires that the smartcard integrated circuit especially maintains the integrity and the
confidentiality of its security enforcing and security relevant architectural components.
The TOE consists also of security IC dedicated software: a DES library and a RSA library.
The DES library provides functions to perform primitive operations such as Triple DES ECB and
CBC using the hardware. Secondly this library adds defensive mechanisms to help protect the TOE
against fault injection attacks as well as attacks aimed at circumventing critical steps in the
cryptographic processing.
The RSA provides functions to perform primitive operations such as CRT and non CRT RSA
calculations using the hardware coprocessor. Secondly this library adds defensive mechanisms to
help protect the TOE against fault injection attacks as well as attacks aimed at circumventing
critical steps in the cryptographic processing.
Other security features of the TOE are:
• Bus and memory encryption
• Clock filter
• Detection Warm/Cold reset, Power supply voltage, Temperature, Input clock frequency, Power
supply glitch, Metal cover removal, Light.
• Duplicated signals
• EEPROM error correction
• Memory firewall
• Metal cover
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
• Random number generator
• Random wait insertion circuit
• Undefined instruction monitoring
• Vacant address access guard
The intended environment is very large; and generally once issued the smartcard can be stored and
used anywhere in the world, at any time, and no control can be applied to the smartcard and the
card operational environment.
1.3. TOE description
In this chapter, for the sake of providing deeper understanding of the security requirements and
intended use of the TOE, overall information regarding the TOE will be provided.
1.3.1. Physical scope
The Target of Evaluation (TOE) is intended to be used in a smartcard product, independent of the
physical interface and the way it is packaged. Generally, a smartcard product may include other
optional elements (such as specific hardware components, batteries, capacitors, antennae,...) but
these are not in the scope of this Security Target. In Table 1-1 the physical scope the TOE is
presented.
Table 1-1, Physical scope of the TOE.
DELIVERY
ITEM TYPE
IDENTIFIER VERSION MEDIUM ADDITIONAL INFORMATION
Hardware T6NC9 #4.0 Chip Delivery formats: packaged die or diced
wafer
Software Hardware configuration
(CODE)
1.02 Electrical data HWCONFIG.REL ‘s
HASH VALUE (SHA-256) =
0563a5685308a6b706176268704215f8
f62b96e83e037a819f3c9aa3851bef8d
Hardware configuration
(Data)
1.0 EEPROM in delivered
T6NC9 hardware
Co-Processor control library 1.0.1 Electrical data
DES control library 1.0.1 Electrical data
CRYPTO.REL(Co-Processor control
Library and DES control library)’s
HASH VALUE (SHA-256) =
2b87c7391f45ba5c61276463b28ba586
4cdb0aaa1a663a2921678f72a53cdd2e
TEST ROM software 1.2 ROM of hardware
(test area)
Manuals User guidance overview 1.00 Electronic document
T6NC9 User Specification 0.92 Electronic document
T6NC9 Software Security
Guidance
1.03 Electronic document
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
The software (i.e. Hardware configuration, Co-Processor control library and DES control library,
TEST ROM software) is part of the TOE, because it exists on the Smartcard after TOE Delivery to a
composite product manufacturer1. The software is usable after TOE Delivery. This comprises
cryptographic library and hardware configuration software. Exception is the “IC dedicated test
software (TEST ROM software)” that is not usable after TOE Delivery to a composite product
manufacturer and is only used to support production of the TOE.
The configuration of the T6NC9 is defined by the hardware configuration settings. For secure
operation the security IC embedded software must use the mandated settings. These settings are
defined in the T6NC9 User Specification.
The manuals are delivered to the composite product manufacturer. The end user does not receive
the manuals. The delivery to the end user contains the operational TOE consisting of the IC
Hardware and IC embedded software together with security IC embedded software in the ROM
from the composite product manufacturer.
The components of the TOE are depicted in Figure2-1 as block diagram. The basic configuration
elements of the TOE are the CPU, the CPU peripheral circuits (MFW, MEMC, UART, Control
Logic), the various memory elements (EEP, ROM, RAM), security function circuit (CRC, RNG, DES,
RSA), various types of detection circuits (SECURITY DETECTORS), and others (TEST CIRCUIT,
etc.).
1 In terms of the protection profile the TOE is delivered at the end of Phase 3 IC Manufacturing.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Figure 2-1 Basic Configuration Elements of the Hardware
The following components are used.
- CPU Z80TM CPU
- MFW Memory Fire Wall
- MEMC Memory Cipher Circuit
- RAM, ROM,EEP 1.5KB RAM, 48KB USER ROM, 8KB EEPROM
- Control Logic
- DES
- RSA
- CRC ISO 3309 (16 bit CRC)
- RNG Random number generator
- VOLTAGE REGURATOR
- SECURITY DETECTOR
- TEST CIRCUIT
- UART
1.3.2. Logical scope
The logical security features offered by the TOE are the following:
1. Triple-DES:
a. ECB mode, Triple DES 2KEY,Encryption/Decryption
b. ECB mode, Triple DES 3KEY,Encryption/Decryption
c. CBC mode, initial value: 0,Triple DES 2KEY,Encryption/Decryption
d. CBC mode, initial value: 0,Triple DES 3KEY,Encryption/Decryption
Control Logic
CPU
UART
MFW
&
MEMC
ROM
(48KB)
RAM
(1.5KB)
EEP
(8KB)
CRC
RNG
DES & RSA
VDD
GND
PCLK
PIO
PRST
TEST CIRCUIT SECURITY DETECTORS
VOLTAGE
REGURATOR
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
e. CBC mode, initial value: arbitrary, Triple DES 2KEY,Encryption/Decryption
f. CBC mode, initial value: arbitrary, Triple DES 3KEY,Encryption/Decryption
2. RSA:
pRSA_CRT. Exponential reminder calculations by CRT are performed to the input data with the
secret key. Key length is up to 1408 bit. Anti-tamper measures are implemented because the
secret key is used for these calculations. Calculation result is same bit length as key(N) length.
The size of key e is less than 10 bytes and the errors occurs more than 10 bytes.
3. Physically seeded random number generator:
A physical noise source provides seeding for a deterministic random number generator built
from recursive calls to Triple DES, conformant to AIS20 Class K3. The seeding must be
performed before use (i.e. at least after each power on, more often if desired). The quality of the
noise source is monitored during this seeding process for total failure of the noise source. The
whole construction (physical noise source, total failure tests, Triple DES in recursive mode) is
completely implemented in hardware, and the actual entropy is provided by physical random
processes.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
2. Conformance claim
This chapter presents conformance claim and the conformance claim rationale.
2.1. CC Conformance
This Security Target claims to be conformant to the Common Criteria “version 3.1 revision 1” d.d.
September 2006.
• The conformance of the ST to CC Part 2 is CC Part 2 extended
• The conformance of the ST to CC Part 3 is CC Part 3 conformant
The extended Security Functional Requirements are defined in chapter 5.
This TOE claims to be conformant to the Common Criteria “version 3.1 revision 1” d.d. September
2006.
The attack potential quotation as part of the vulnerability analysis shall use the Mandatory
Technical Document “Application of Attack Potential to Smartcards”, which current version is [7].
2.2. PP Claim
The ST and the TOE claim conformance to the following Protection Profile (PP):
• Security IC Platform Protection Profile. Registered and Certified by Bundesamt für Sicherheit
in der Informationstechnik (BSI) under the reference BSI-PP-0035. [5]
2.3. Package claim
The assurance level for this Security Target is EAL4 augmented with AVA_VAN.5 and ALC_DVS.2.
This assurance level is in line with the Security IC Platform Protection Profile.
2.4. Conformance claim rationale
This TOE is equivalent to the conformance claim stated in a Security IC Platform Protection Profile.
The crypto libraries are considered as security IC dedicated software as defined in this Protection
Profile.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
3. Security problem definition
This chapter presents the threats, organisational security policies and assumptions for the TOE.
The Assets, Assumptions, Threats and Organisational Security Policies are completely taken from
the Security IC Platform Protection Profile [5].
3.1. Description of Assets
Since this Security Target claims conformance to the Security IC Platform Protection Profile [5], the
assets defined in section 3.1 of the Protection Profile are applied.
3.2. Threats
Since this Security Target claims conformance to the Security IC Platform Protection Profile [5], the
threats defined in section 3.3 of the Protection Profile are valid for this Security Target. The
following table lists the threats of the Protection Profile.
Table 3-1, Threats defined in the Security IC Platform Protection Profile.
Threats Titles
T.Phys-Manipulation Physical Manipulation
T.Phys-Probing Physical Probing
T.Malfunction Malfunction due to Environmental Stress
T.Leak-Inherent Inherent Information Leakage
T.Leak-Forced Forced Information Leakage
T.Abuse-Func Abuse of Functionality
T.RNG Deficiency of Random Numbers
3.3. Organisational security policies
Since this Security Target claims conformance to the Security IC Platform Protection Profile [5], the
Organisational Security Policies defined in section 3.3 of the Protection Profile are valid for this
Security Target. The following table lists the Organisational Security Policies of the Protection
Profile.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Table 3-2, Organisational Security Policies defined in the Security IC Platform Protection Profile.
Organisational Security Policies Titles
P.Process-TOE Protection during TOE Development and Production
The following the Organisational Security Policy considers the Application Note 12 of the Security
IC Platform Protection Profile [5] related to the specialised functions of the TOE.
The TOE provides specific security functionality, which can be used by the security IC embedded
software. In the following specific security functionality is listed which is not derived from threats
identified for the TOE’s environment because it can only be decided in the context of the smartcard
application, against which threats the security IC embedded software will use the specific security
functionality.
The IC Developer / Manufacturer must apply the policy “Additional Specific Security Functionality
(P.Add-Functions)” as specified below.
P.Add-Functions Additional Specific Security Functionality
The TOE shall provide the following specific security functionality to the
security IC embedded software:
· Data Encryption Standard (DES),
· Rivest-Shamir-Adleman (RSA),
The following Organisational Security Policy considers the Application Note 8 of the Security IC
Platform Protection Profile [5] related to the specialised encryption hardware of the TOE. The
developer of the security IC embedded software must ensure the appropriate “Usage of Key
dependent Functions (P.Key-Function)” while developing this software in Phase 1 IC embedded
software developer (see Security IC Platform Protection Profile [5]) as specified below.
P.Key-Function Usage of Key-dependent Functions
Key-dependent functions (if any) shall be implemented in the security IC
embedded software in a way that they are not susceptible to leakage
attacks (as described under T.Leak-Inherent and T.Leak-Forced).
Note that here the routines which may compromise keys when being
executed are part of the security IC 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
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
of User Data including cryptographic keys.
3.4. Assumptions
Since this Security Target claims conformance to the Security IC Platform Protection Profile [5], the
assumptions defined in section 3.2 of the Protection Profile are valid for this Security Target. No
additional assumptions are added. The following table lists the assumptions of the Protection
Profile.
Table 3-3, Assumptions defined in the Security IC Platform Protection Profile.
Assumptions Titles
A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation
A.Plat-Appl Usage of Hardware Platform
A.Resp-Appl Treatment of User Data
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
4. Security objectives
This chapter provides the statement of security objectives and the security objective rationale. For
this chapter the Security IC Platform Protection Profile [5] can be applied completely. Only a short
overview is given in the following.
4.1. Security objectives for the TOE
The TOE shall provide the following security objectives, taken from the Security IC Platform
Protection Profile [5]. The following table lists the security objectives for the TOE of the Protection
Profile.
Table 4-1, Security objectives for the TOE defined in the Security IC Platform Protection Profile.
Security objectives for the TOE Titles
O.Leak-Inherent Protection against Inherent Information Leakage
O.Phys-Probing Protection against Physical Probing
O.Malfunction Protection against Malfunctions
O.Phys-Manipulation Protection against Physical Manipulation
O.Leak-Forced Protection against Forced Information Leakage
O.Abuse-Func Protection against Abuse of Functionality
O.Identification TOE Identification
O.RNG Random Numbers
Regarding Application Notes 13 and 14 of the Security IC Platform Protection Profile [5] the
following additional security objectives are defined based on additional functionality provided by
the TOE as specified below.
O.HW_DES DES Functionality
The TOE shall provide the cryptographic functionality to calculate a DES
encryption and decryption to the security IC embedded software. The
TOE supports directly the calculation of Triple-DES.
O.HW_RSA RSA Functionality
The TOE shall provide the cryptographic functionality to calculate a RSA
encryption and decryption to the security IC embedded software. The
TOE supports the calculation of RSA.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
4.2. Security objectives for the security IC embedded software
development environment
According to the Security IC Platform Protection Profile [5], the following security objectives for the
environment are specified:
Table 4-2, Security objectives for the security IC embedded software development environment defined
in the Security IC Platform Protection Profile.
Security objectives for the
Environment
Titles
OE.Plat-Appl Usage of Hardware Platform
OE.Resp-Appl Treatment of User Data
Clarification of “Usage of Hardware Platform (OE.Plat-Appl)”
The TOE supports cipher schemes as additional specific security functionality. If required the
security IC embedded software shall use these cryptographic services of the TOE and their interface
as specified. When key-dependent functions implemented in the security IC embedded software are
just being executed, the security IC embedded software must provide protection against disclosure
of confidential data (User Data) stored and/or processed in the TOE by using the methods described
under “Inherent Information Leakage (T.Leak-Inherent)” and “Forced Information Leakage
(T.Leak-Forced)“.
Clarification of “Treatment of User Data (OE.Resp-Appl)”
By definition cipher or plain text data and cryptographic keys are User Data. The security IC
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.
This means that keys are treated as confidential as soon as they are generated. The keys must be
unique with a very high probability, as well as cryptographically strong.
For example, it must be ensured that it is beyond practicality to derive the private key from a public
key. If 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.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
4.3. Security objectives for the operational environment
According to the Security IC Platform Protection Profile [5], the following security objectives for the
environment are specified.
Table 4-3, Security objectives for the Environment defined in the Security IC Platform Protection Profile.
Security objectives for the
Environment
Titles
OE.Process-Sec-IC Protection during composite product manufacturing
4.4. Security objectives rationale
In Table 4-4 each security objective for the TOE is traced back to threats countered by that security
objective and OSPs enforced by that security objective.
Table 4-4, Tracing between objectives and Threat, Organisational Security Policy or Assumption.
Threat, Organisational Security
Policy or Assumption
Security Objective Sufficiency of
countering
T.Phys-Manipulation O.Phys-Manipulation See PP
T.Phys-Probing O.Phys-Probing See PP
T.Malfunction O.Malfunction See PP
T.Leak-Inherent O.Leak-Inherent See PP
T.Leak-Forced O.Leak-Forced See PP
T.Abuse-Func O.Abuse-Func See PP
T.RNG O.RNG See PP
P.Process-TOE O.Identification See PP
P.Add-Functions O.HW_DES See below
P.Add-Functions O.HW_RSA See below
P.Key-Functions OE.Plat-Appl See PP
A.Process-Sec-IC OE.Process-Sec-IC See PP
A.Plat-Appl OE.Plat-Appl See PP
A.Resp-Appl OE.Resp-Appl See PP
The justification related to the organisational security policy “Protection during TOE
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Development and Production (P.Add-Functions) is as follows:
Since these objectives require the TOE to implement exactly the same specific security functionality
as required by P.Add-Functions, the organisational security policy is covered by the objectives.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
5. Security requirements
This chapter presents the statement of security requirements for the TOE and the security
requirements rationale. This chapter applies the Security IC Platform Protection Profile [5].
5.1. Definitions
In the next sections the following the notation used
· Whenever iteration is denoted, the component has an additional identification [XXX].
· When the refinement, selection or assignment operation is used these cases are indicated by
italic text and explained in footnotes.
5.2. Security Functional Requirements (SFR)
To support a better understanding of the combination Security IC Platform Protection Profile vs.
Security Target, the TOE Security Functional Requirements are presented in the following several
different sections.
5.2.1. SFRs derived from the Security IC Platform Protection Profile
Table 5-1, Security Functional Requirements taken from the Security IC Platform Protection Profile.
Security functional requirements Titles
FRU_FLT.2 “Limited fault tolerance“
FPT_FLS.1 “Failure with preservation of secure state”
FMT_LIM.1 “Limited capabilities”
FMT_LIM.2 “Limited availability”
FAU_SAS.1 “Audit storage”
FPT_PHP.3 “Resistance to physical attack”
FDP_ITT.1 “Basic internal transfer protection”
FDP_IFC.1 “Subset information flow control”
FPT_ITT.1 “Basic internal TSF data transfer protection”
FCS_RNG.1 “Quality metric for random numbers”
Table 5-1 lists the Security Functional Requirements that are directly taken from the Security IC
Platform Protection Profile. With two exceptions, all assignment and selection operations are
performed on these SFRs. The fist exception is the left open assignment of type of persistent
memory by FAU_SAS.1. The second exception is the left open definition of a quality metric for the
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
random numbers required by FCS_RNG.1. The following statements define these SFRs. The SFRs
FMT_LIM, FAU_SAS and FCS_RNG are extended security requirements, completely defined in the
PP.
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
FAU_SAS.1.1 The TSF shall provide the test process before TOE Delivery 2 with the capability
to store the Initialisation Data and/or Pre-personalisation Data and/or supplements of the security
IC embedded software 3 in the EEPROM and/or ROM 4.
Dependencies: No dependencies.
FCS_RNG.1 Random number generation
Hierarchical to: No other components.
FCS_RNG.1.1 The TSF shall provide a physical random number generator that implements total
failure test of the random source5.
FCS_RNG.1.2 The TSF shall provide random numbers that meet Class K3 of [6]6.
Dependencies: No dependencies.
2 [assignment: list of subjects]
3 [assignment: list of audit information]
4 [assignment: type of persistent memory]
5 [assignment: list of security capabilities] refined with “none” in accordance with application note 20 of
[5]. The results of the total failure test are provided to the Security IC Embedded Software by a seeding
error warning.
6 [assignment: a defined quality metric] – refined in the PP as [selection: independent bits with Shannon
entropy of 7.976 bits per octet, Min-entropy of 7.95 bit per octet, [assignment: other comparable quality
metric]]. The TOE uses the physical random processes for its entropy and post-processes this with a
Triple DES deterministic random number generator for additional security. AIS20 describes this
construction exactly, therefore AIS20 is chosen as quality metric and evaluation methodology.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
5.2.2. SFRs regarding cryptographic functionality
For the security IC embedded software the following cryptographic functionality is defined related
to DES and RSA operations.
5.2.2.1. DES Operation
The DES Operation of the TOE shall meet the requirement “Cryptographic operation
(FCS_COP.1)”.
FCS_COP.1 [DES] Cryptographic operation
Hierarchical to: No other components.
FCS_COP.1.1 [DES] The TSF shall perform encryption and decryption7 in accordance with a
specified cryptographic algorithm Triple Data Encryption Standard (3DES – ECB and CBC mode)8
and cryptographic key sizes of 112 bit and 168 bit keys9 that meet the following standards10:
U.S. Department of Commerce / National Bureau of Standards, Data Encryption Standard (DES),
FIPS PUB 46-3, 1999, October 25, keying option 1 and 2.
Dependencies: [FDP_ITC.1 Import of user data without security attributes,
or FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
5.2.2.2. RSA Operation
The RSA Operation of the TOE shall meet the requirement “Cryptographic operation
(FCS_COP.1)”.
FCS_COP.1 [RSA] Cryptographic operation
Hierarchical to: No other components.
7 [assignment: list of crypto-graphic operations]
8 [assignment: cryptographic algorithm], change due to different standard
9 [assignment: cryptographic key sizes], change due to different part of standard
10 [assignment: list of standards], change of referred standard
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
FCS_COP.1.1 [RSA] The TSF shall perform encryption and decryption11 in accordance with a
specified cryptographic algorithm Rivest-Shamir-Adleman (RSA)12 and cryptographic key sizes of
1408 bit or less13 that meet the following standards14:
PKCS#1: RSA Encryption Standard, version 2.1, RSA Laboratories.
Dependencies: [FDP_ITC.1 Import of user data without security attributes
or, FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
5.3. Security Assurance Requirements (SAR)
The Security Target will be evaluated according to
Security Target evaluation (Class ASE)
The Security Assurance Requirements for the TOE for the evaluation of the TOE are those taken
from the Evaluation Assurance Level 4 (EAL4) and augmented by taking the following components:
ALC_DVS.2, and AVA_VAN.5.
The assurance requirements are:
· Class ADV: Development
Architectural design (ADV_ARC.1)
Functional specification (ADV_FSP.4)
Implementation representation (ADV_IMP.1)
TOE design (ADV_TDS.3)
· Class AGD: Guidance documents
Operational user guidance (AGD_OPE.1)
Preparative user guidance (AGD_PRE.1)
· Class ALC: Life-cycle support
CM capabilities (ALC_CMC.4)
CM scope (ALC_CMS.4)
Delivery (ALC_DEL.1)
11 [assignment: list of crypto-graphic operations]
12 [assignment: cryptographic algorithm]
13 [assignment: cryptographic key sizes], change due to different standard
14 [assignment: list of standards], change of referred standard
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Development security (ALC_DVS.2)
Life-cycle definition (ALC_LCD.1)
Tools and techniques (ALC_TAT.1)
· Class ATE: Tests
Coverage (ATE_COV.2)
Depth (ATE_DPT.2)
Functional tests (ATE_FUN.1)
Independent testing (ATE_IND.2)
· Class AVA: Vulnerability assessment
Vulnerability analysis (AVA_VAN.5)
5.4. Security requirements rationale
5.4.1. Security Functional Requirements (SFR)
Table 5-2, Tracing between SFRs and objectives for the TOE.
Security Objectives
for the TOE
Dependencies Fulfillment of dependencies
O.Leak-Inherent FDP_ITT.1
FDP_IFC.1
FDP_ITT.1
See PP
O.Phys-Probing FPT_PHP.3 See PP
O.Malfunction FRU_FLT.2
FPT_FLS.1
See PP
O.Phys-Manipulation FPT_PHP.3 See PP
O.Leak-Forced FDP_ITT.1
FDP_IFC.1
FDP_ITT.1
FRU_FLT.2
FPT_FLS.1
FPT_PHP.3
See PP
O.Abuse-Func FMT_LIM.1
FMT_LIM.2
FDP_ITT.1
FDP_IFC.1
FDP_ITT.1
See PP
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
FRU_FLT.2
FPT_FLS.1
FPT_PHP.3
O.Identification FAU_SAS.1 See PP
O.RNG FCS_RNG.1
FDP_ITT.1,
FPT_ITT.1,
FDP_IFC.1,
FPT_PHP.3,
FRU_FLT.2,
FPT_FLS.1
See PP
O.HW_DES FCS_COP.1 [DES] See below.
O.HW_RSA FCS_COP.1 [RSA] See below
OE.Process-Sec-IC
OE.Plat-Appl
OE.Resp-Appl
The justification related to the security objective “DES Functionality (O.HW_DES)” is as follows:
The SFR define the DES standard implemented with its specific characteristics regarding bit size.
The justification related to the security objective “RSA Functionality (O.HW_RSA)” is as follows:
The SFR define the RSA standard implemented with its specific characteristics regarding bit size.
5.4.2. Dependencies of the SFRs
In the following table the satisfaction of the dependencies is indicated.
Table 5-3, Dependencies of SFRs.
SFR Dependencies Fulfillment of dependencies
FRU_FLT.2 FPT_FLS.1 Covered by PP
FPT_FLS.1 none -
FMT_LIM.1 FMT_LIM.2 Covered by PP
FMT_LIM.2 FMT_LIM.1 Covered by PP
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
FAU_SAS.1 none -
FPT_PHP.3 none -
FDP_ITT.1 FDP_ACC.1 or
FDP_IFC.1
FDP_IFC.1 covered by PP
FDP_IFC.1 FDP_IFF.1 The PP states in the Data Processing Policy (referred to in
FDP_IFC.1) that there are no attributes necessary and therefore
this dependency is met.
FPT_ITT.1 none -
FCS_RNG.1 none -
FCS_COP.1
[DES]
FDP_ITC.1 or
FCS_CKM.1
The security IC embedded software using this TOE is
responsible to cover this. This is arranged by OE.Plat-Appl and
OE.Resp-Appl.
FCS_CKM.4 The security IC embedded software using this TOE is
responsible to cover this. This is arranged by OE.Plat-Appl and
OE.Resp-Appl.
FMT_MSA.2 The PP states in the Data Processing Policy (referred to in
FDP_IFC.1) that there are no attributes necessary and therefore
this dependency is met.
FCS_COP.1
[RSA]
FDP_ITC.1 or
FCS_CKM.1
The security IC embedded software using this TOE is
responsible to cover this. This is arranged by OE.Plat-Appl and
OE.Resp-Appl.
FCS_CKM.4 The security IC embedded software using this TOE is
responsible to cover this. This is arranged by OE.Plat-Appl and
OE.Resp-Appl.
FMT_MSA.2 The PP states in the Data Processing Policy (referred to in
FDP_IFC.1) that there are no attributes necessary and therefore
this dependency is met.
5.4.3. Security Assurance Requirements (SAR)
The SARs as defined in section 5.3 are in line with the SARs in the Security IC Platform Protection
Profile. The context of this ST is equivalent to the context described in the Protection Profile and
therefore these SARs are also applicable for this ST.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
6. TOE summary specification
This chapter presents the TOE summary specification to gain a general understanding of how the
TOE is implemented. The TOE summary specification describes how the TOE meets each SFR.
The TOE is implemented by a series of security functions. All these security functions are active
during the delivery from Phase 3 to 4 as defined in Security IC Platform Protection Profile [5]. In
the table for each SFR is indicated which security functions are supportive in meeting the SFR.
Table 6-1, Tracing between TOE summary specification and SFRs.
SFR Security Functionality
F.Corr-Operation F.Phys-Protection F.Logical-Protection F.Prev-Abuse F.RNG F.DES F.RSA
FRU_FLT.2 X
FPT_FLS.1 X
FMT_LIM.1 X
FMT_LIM.2 X
FAU_SAS.1 X
FPT_PHP.3 X
FDP_ITT.1 X
FDP_IFC.1 X
FPT_ITT.1 X
FCS_RNG.1 X
FCS_COP.1 [DES] X
FCS_COP.1 [RSA] X
In the next paragraphs the grouping of the security requirements of the Security IC Platform
Protection Profile is used.
6.1. Malfunction
Malfunctioning relates to the security requirements FRU_FLT.2 and FPT_FLS.1. The TOE meets
these SFRs by F.Corr-Operation that guarantees correct operation of the TOE.
The TOE ensures its correct operation and prevents any malfunction while the security IC
embedded software is executed and utilises standard functions offered by the micro-controller
(standard CPU instruction set including usage of standard peripherals such as memories, registers,
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
I/O interfaces, timers etc.) and of all other Specific Security Functionality.
This is achieved through an appropriate design of the TOE and the implementation of filters,
sensors/detectors and integrity monitoring components. The filter eliminates high-frequency pulse
(more than 45MHz) in order to ensure the correct operation of the TOE. The sensors/detectors
measure the applied voltage, frequency, temperature, electro magnetic radiation, and glitch signals
in applied voltage. In addition, the target address range, the accessible segments of each memory
and the operation of CPU are monitored. In case that any malfunction occurred or may likely occur,
operation is stopped. The integrity monitoring components involves Error Correct Circuit (ECC) for
ensuring EEPROM data integrity, dual line signal and parity check for data transfer.
“stopped”
If one of the monitored parameters is out of the specified range, operation is stopped. ”stopped”
means that reset signal is impressed to CPU, halt instruction is executed and I/O disabled. If
Operation is “stopped”, all components of the TOE are initialised with their reset values.
“ECC”
If 2 bit or more bit errors of ECC for EEPROM are occurred, an exception is raised which interrupts
the program flow and allows a reaction of the security IC embedded software. In the case of an
exception raised, the security IC embedded software can select one of several operations). In case of
1 bit errors the memory content is automatically corrected by the ECC.
“accessible segments of each memory”
This security mechanism restricts the ability of security IC embedded software to access segmented
memory areas. The decision whether the access operation is granted or denied is based upon the
address. The ability to define the access rights and memory segmentation is permitted to user by
setting data on specific registers.
6.2. Leakage
Leakages relates to the security requirements FDP_ITT.1, FDP_IFC.1 and FPT_ITT.1. The TOE
meets these SFRs by F.Logical-Protection that provides logical protection against leakage.
The TOE implements measures to limit or eliminate the information that might be contained in the
shape and amplitude of signals or in the time between events found by measuring such signals.
This comprises the power consumption and signals on the other pads that are not intended by the
terminal or the security IC embedded software.
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Thereby this security function prevents the disclosure of User Data or TSF data stored and/or
processed in the smartcard IC through the measurement of the power consumption and subsequent
complex signal processing. The protection of the TOE comprises different features within the design
that support the other security functions.
The DES circuit and DES Crypto Library include special features to prevent timing attacks,
SPA/DPA analysis and fault attacks. The special features and sequences are included to provide
limitations of the capability for the analysis of shape and amplitude of the power consumption, and
fault insertions on calculations.
The RSA co-processor and RSA Crypto Library provide measures to prevent timing attacks,
SPA/DPA analysis and fault attacks. The special features and sequences are included to provide
limitations of the capability for the analysis of shape and amplitude of the power consumption, and
fault insertions on calculations.
An additional features that can be configured by the security IC embedded software comprise is to
add dummy consumptions and dummy clock cycle.
Refer to [8] about SPA/DPA by the software developers.
6.3. Physical manipulation and probing
Physical manipulation and probing relates to the security requirement FPT_PHP.3. The TOE meets
this SFR by F.Phys-Protection that provides physical protection against physical probing and
manipulation.
The function F. Phys-Protection protects the TOE against manipulation of
(i) the hardware,
(ii) the security IC embedded software in the ROM and the EEPROM,
(iii) the application data in the EEPROM and RAM including the configuration data.
It also protects User Data or TSF data against disclosure by physical probing when stored or while
being processed by the TOE. The protection of the TOE comprises different features within the
design and construction, which make reverse-engineering and tamper attacks more difficult. These
features comprise dedicated shielding techniques for different components and specific encryption
features for the memory blocks.
The protection of the TOE comprises different features of the construction, which makes a tamper
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
attack more difficult. By this the security function F.Phys-Protection comprises protection of other
security functions.
6.4. Abuse of functionality and Identification
Abuse of functionality and Identification relates to the security requirements FMT_LIM.1,
FMT_LIM.2 and FAU_SAS.1. The TOE meets these SFRs by F.Prev-Abuse that prevents abuse of
test functionality delivered as part of the TOE.
The test functionality is not available to the user after Phase 3 IC Manufacturing as defined in
Security IC Platform Protection Profile [5]. The TOE has an access control mechanisms in place to
prevent using this functionality.
6.5. Random numbers
Random numbers relate to the security requirement FCS_RNG.1. The TOE meets this SFR by
F.RNG that provides a random number generator.
The random number generator contains a physical noise source, total failure tests on this noise
source and a Triple-DES deterministic random number generator post-processing construction
seeded by the physical noise source output. Thus the random number generator produces the
random number by a noise source based on physical random processes. Seeding must be performed
after each power-on at a minimum. The total failure tests are automatically performed on the
seeding data. The whole construction is implemented entirely in the hardware component and
operates within the limits guaranteed by F.Corr-Operation (operational conditions).
The random number generator fulfils the requirements of functionality class K3 of [6].
6.6. Cryptographic operations
Cryptographic operations relate to the security requirements FCS_COP.1 [DES] and FCS_COP.1
[RSA] The TOE meet these SFRs by respectively F.DES and F.RSA that provides
DES-Encryption/Decryption and RSA-Encryption/Decryption.
6.6.1. DES
The TOE provides the Triple Data Encryption Standard (Triple-DES) algorithm according to the
Data Encryption Standard. F.DES is a modular basic cryptographic function, which provides the
Triple-DES algorithm as defined by FIPS PUB 46-3 by means of a hardware co-processor and a
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
crypto library. T.DES supports the Triple-DES algorithm with three 56bit keys (168 bit) for the
3-key Triple DES algorithm(TBD). The keys for the Triple-DES algorithm shall be provided by the
security IC embedded software.
FIPS PUB 46-3
FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION
DATA ENCRYPTION STANDARD (DES)
Reaffirmed 1999 October 25
6.6.2. RSA
The TOE provides RSA algorithm according to :
PKCS#1: RSA Encryption Standard, version 2.1, RSA Laboratories.
The security IC embedded software selects and combines the appropriate functions of the TOE (i.e.
co-processor and Crypto Library) and provides an interface for RSA-Encryption/Decryption, which
can be used by the security IC embedded software.
This security function implements the following standard asymmetric key cryptography algorithms:
ƒ RSA decryption (verification),
ƒ RSA encryption (signature) with the Chinese Remainder Theorem (CRT),
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
7. Reference
No Title Date Version publisher Document number
[1]
Common Criteria for
Information Technology
Security Evaluation, Part
1: Introduction and
General Model
September
2006
3.1
Revision
1
[2]
Common Criteria for
Information Technology
Security Evaluation, Part
2: Security Functional
Requirements
September
2006
3.1
Revision
1
[3]
Common Criteria for
Information Technology
Security Evaluation, Part
3: Security Assurance
Requirements
September
2006
3.1
Revision
1
[4] Common Methodology for
Information Technology
Security Evaluation
(CEM), Part 2: Evaluation
Methodology
September
2006
3.1
Revision
1
[5] Security IC Platform
Protection Profile
15.06.2007 1.0
Bundesamt für
Sicherheit in der
Informationstechnik
(BSI)
BSI-PP-0035
[6] Application Notes and
Interpretation of the
Scheme (AIS), AIS 20:
Functionality classes and
evaluation methodology
for deterministic random
number generators
2
December
1999
1
[7] Supporting Document,
Mandatory Technical
Document: Application of
April 2006
2.1
Revision
1
CCDB-2006-04-002
©TOSHIBA CORPORATION 2007. ALL RIGHTS RESERVED. CC-T6NC9-ST-ENG-002
CC-T6NC9-ST-ENG-002
Attack Potential to
Smartcards
[8] T6NC9 software
security guidance
18 Aug
2008
1.03 Toshiba
※ End of Document※※