General Business Use
Security Target Lite
MS6001 Security Target-Lite
TPR0234B
2/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
TABLE OF CONTENTS
1 INTRODUCTION...................................................................................................4
1.1 Security Target Reference.................................................................................4
1.2 Purpose.............................................................................................................4
1.3 Reference list ....................................................................................................4
1.4 TOE Overview...................................................................................................5
1.4.1 TOE Reference.................................................................................................5
1.4.2 TOE Definition ..................................................................................................6
1.4.2.1 TOE Overview .....................................................................................6
1.4.2.2 Security IC Embedded Software Developer Guidance Documents ......8
1.4.2.3 TOE Life Cycle Addresses.................................................................10
1.4.2.4 TOE Description ................................................................................11
1.4.2.5 Cryptographic Toolbox Software........................................................14
1.5 TOE Life Cycle ................................................................................................16
1.5.1 Overview of the Composite Product Life Cycle ...............................................16
1.5.2 Phases 2 and 3 of the TOE Life Cycle ............................................................18
1.5.2.1 Phase 2 IC Development ...................................................................18
1.5.2.2 Phase 3 IC Manufacturing..................................................................18
1.5.3 Phase 3 of the TOE Life Cycle........................................................................19
1.5.3.1 Security IC Embedded Software Loading...........................................19
1.5.4 State of the TOE between sites ......................................................................20
1.5.5 Modes of Operation and Life Cycle Phases ....................................................20
1.5.6 Composite Product Manufacturer Phases of the Life Cycle ............................20
2 CONFORMANCE CLAIMS ...................................................................................22
2.1 CC Conformance Claim...................................................................................22
2.2 Package Claim ................................................................................................22
2.3 PP Claim .........................................................................................................22
2.4 PP Refinements ..............................................................................................22
2.5 PP Additions....................................................................................................22
2.6 PP Claims Rationale .......................................................................................23
3 SECURITY PROBLEM DEFINITION .......................................................................24
3.1 Description of Assets.......................................................................................24
3.2 Threats ............................................................................................................25
3.3 Organisational Security Policies ......................................................................26
3.4 Assumptions....................................................................................................27
4 SECURITY OBJECTIVES.....................................................................................29
4.1 Security Objectives for the TOE ......................................................................29
4.2 Security Objectives for the Security IC Embedded Software development
Environment (not part of TOE) ..............................................................................31
4.3 Security Objectives for the operational Environment.......................................32
4.4 Security Objectives Rationale..........................................................................33
3/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
5 EXTENDED COMPONENTS DEFINITION................................................................35
6 IT SECURITY REQUIREMENTS............................................................................36
6.1 Security Functional Requirements for the TOE ...............................................37
6.2 Security Assurance Requirements for the TOE...............................................49
6.2.1 Refinements of the TOE Assurance Requirements.........................................50
6.3 Security Requirements Rationale ....................................................................51
6.3.1 Rationale for the security functional requirements...........................................51
6.3.2 Dependencies of security functional requirements..........................................52
7 TOE SUMMARY SPECIFICATION ........................................................................53
7.1 Description of TSF Features of the TOE .........................................................54
7.1.1 TSF_TEST Test Interface...............................................................................54
7.1.1.1 SFR to TSF Test Interface .................................................................54
7.1.2 TSF_ENV_PROTECT Environmental Protection ............................................55
7.1.2.1 SFR to TSF_ENV_PROTECT............................................................56
7.1.3 TSF_LEAK_PROTECT Leakage Protection ...................................................56
7.1.3.1 SFR to TSF_LEAK_PROTECT..........................................................57
7.1.4 TSF_DATA_PROTECT Data Protection .........................................................58
7.1.4.1 SFR to TSF_DATA_PROTECT..........................................................59
7.1.5 TSF_AUDIT_ACTION Event Audit and Action ................................................60
7.1.5.1 SFR to TSF_AUDIT_ACTION............................................................60
7.1.6 TSF_RNG Random Number Generator ..........................................................60
7.1.6.1 SFR to TSF_RNG..............................................................................61
7.1.7 TSF_CRYPTO_HW Hardware Cryptography..................................................62
7.1.7.1 SFR to TSF_CRYPTO_HW ...............................................................62
7.1.8 TSF_CRYPTO_SW Toolbox Cryptography.....................................................63
7.1.8.1 SFR to TSF_CRYPTO_SW ...............................................................63
7.1.9 TSF_AUTHENTICATION................................................................................64
7.1.9.1 SFR to TSF_AUTHENTICATION.......................................................64
7.2 Rationale for TSF ............................................................................................65
7.2.1 Summary of TSF to SFR.................................................................................65
7.2.2 Rationale for the TSF Features of the TOE.....................................................66
7.2.3 Note on ADV_ARC.1 ......................................................................................67
8 ANNEX ............................................................................................................68
8.1 Glossary ..........................................................................................................68
8.2 Literature .........................................................................................................70
8.3 List of Abbreviations ........................................................................................71
4/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1 INTRODUCTION
1.1 Security Target Reference
Title: MS6001 Security Target
Version number: B
Sponsor: INSIDE SECURE
Evaluation Scheme: France (ANSSI)
Evaluator: LETI
Version Date Changes Author
A 24 Feb 16 First Release Graeme Calder
B 25 Feb 16 Update post review Gareme Calder
1.2 Purpose
This document defines the Security Target of the MS6001 project, and is provided to satisfy the
Assurance Class ASE Security Target Evaluation as defined in Part 3 [3] of the Common Criteria
version 3.1, Revision 4.
1.3 Reference list
[TDS] MS6001 Semi-Formal TOE Design MS6001_TDS
[FSP] MS6001 Semi-Formal Functional Specification MS6001_FSP
[DESSPEC] MS6001 Design Specifications MS6001_DESSPEC
[ARC] MS6001 Security Architecture Description MS6001_ARC
[COF] Customer Option Form COF
Note: For the correct version of the above documents, the user of this document should refer to the TOE
Deliverables list (EDL).
5/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4 TOE Overview
1.4.1 TOE Reference
The Target of Evaluation is a Secure Microcontroller with Cryptographic Software library and Wear
Levelling library. The TOE is identified as shown below:
Identifier (FAU_SAS.1 where applicable)
Part Number MS6001 PID = 0x44 [TD]
Product Identification Number 90T02
Hardware Revision E SNB1 = 0x04[TD]
Applicable Inside Toolbox(s) 06.04.01.02 0x06040102 a
Applicable Inside Wear
Levelling
06.02.02.01 0x06020201 b
The TOE is a Secure Microcontroller (Security IC) that may be used in a variety of security
applications, including, Banking, Identification, Pay TV and embedded systems.
The increase in the number and complexity of applications in the market of a Secure Microcontroller
is reflected in the increase of the level of data security required. The security needs for the TOE can
be summarized as being able to counter those who want to defraud, gain unauthorized access to
data and control a system utilizing the TOE. Therefore it is mandatory to:
• maintain the integrity of the content of the TOE memories and the confidentiality of the
content of protected memory areas as required by the end application(s)
• maintain the correct execution of the software residing on the TOE
The TOE implements security features to protect the confidentiality of data in the protected memory
areas and may protect data in other memory areas even if not required by SFR, e.g.in ROM. The
TOE also maintains the integrity of its TSF and TSF data and their confidentiality when required.
Protected information is in general secret or integrity sensitive data such as Personal Identification
Numbers, Balance Value (Stored Value Cards), and Personal Data Files. Other protected information
data representing the access rights; these include any cryptographic algorithms and keys needed for
accessing and using the services provided by the system through use of the TOE.
The TOE can be used in a smartcard application, a USB token or other devices. The intended
environment is very large; and generally once issued the TOE may be stored and used anywhere,
generally there is no control applied to the TOE and its operational environment.
a
The toolbox identification is output by the TOE when the self-test function of the toolbox is called
b
The Wear Levelling identification is output by the TOE when the ROM function initialisation is called.
6/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4.2 TOE Definition
1.4.2.1 TOE Overview
General Features
 ARM®
SecureCore®
SC300™ 32-bit RISC core featuring:
o Harvard architecture
o Thumb2®
High-code-density instruction set
o 3-stage pipeline architecture
o 8-bit, 16-bit, 32-bit data types
o Nested Vector Interrupt Controller
o Memory Protection Unit
 Very low power consumption, GSM and ETSI compliant
 Programmable Internal Clock Up to 50 MHz
 Bond Pad Locations Conforming to ISO 7816-2
 ESD Protection to ± 4kV (HBM)
 Operating Ranges: from 1.62V to 5.5V
 Compliant with EMV 4.3 Specifications and CQM
 Compliant with GSM, 3GPP and EMV 2000 Specifications
 Available in Wafers, Modules, and Industry-standard Packages
Memory
 64KB ROM Program Memory
– INSIDE SECURE’s crypto library
– Wear Levelling Mechanism
 1MB of Flash memory featuring:
– 2KB of OTP
– Sector granularity of 2KB and page granularity of 128 or 256 bytes
– Sector erase time: 2 to 7ms depending on cell endurance
– Word write time: 70µs
– Raw Endurance: 100,000 Write/Erase Cycles
– Endurance up to: 1,000,000 Write/Erase Cycles using Built-in optimised
programming algorithm and depending on use
– 10 Years Data Retention at 25o
C
 20KB of RAM + 4KB of shared RAM between Ad-X3 and CPU
Peripherals
 ISO 7816 Controller
– Up to 625 kbps at 5 MHz
– Compliant with T = 0 and T = 1 Protocols
 SWP, Single Wire Protocol controller for communications with NFC chip
7/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
 Two I/O, multiplexed with other interfaces
 Three GPIOs, shared with SPI
 High-speed SPI interface up to 20Mbits/s
 I2C interface up to 1Mbits/s
 Two Timers
– One 32-bit timer that can be clocked by ISO clock
– One 16-bit timer with watchdog capability
 SysTick 24-bit Timer part of the SC300
 Random Number Generator (RNG), compliant AIS31 PTG.2
 2-level Interrupt Controller
 Hardware Simple DES and Triple DES 2 keys and 3 keys, DPA/DEMA Resistant
 Hardware AES (128, 192, 256 bits key system)
 CRC 16 and CRC 32 Engine (Compliant with ISO/IEC 3309)
 32-Bit Cryptographic Accelerator (Ad-X3 for Asymmetric Cryptographic Operations)
 High performance Hardware Java Card Accelerator
Security
 Dedicated Hardware for Protection Against SPA/DPA/SEMA/DEMA Attacks
 Advanced Protection Against Physical Attack, Including Active Shield, EPO,
CStack Checker, Slope Detector, and Parity Error Detector.
 Environmental Protection Systems
– Voltage Monitor
– Frequency Monitor
– Temperature Monitor
– Light Protection
– Glitch Detector
 Secure Memory Management/Access Protection (Privileged / Unprivileged)
 Memory Protection Unit (part of the SC300)
 Bus Polarity, Uniform Data Dependency Timing, Uniform Branch Timing, Trash
Register Write, Clock Gating Randomisation, Secure Bridge and CPU Lockup
Protection
Software
 Crypto Software Toolbox
– AIS31 Online Test, RSA, RSA with CRT, PrimeGen (Miller Rabin), Lucas Test,
ECC Multiply over GF(P), ECC Multiply over GF(2n), ECDSA generation and
verification over GF(2n), ECDSA generation and verification over GF(P), Self-
Test
 Wear Levelling
8/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4.2.2 Security IC Embedded Software Developer Guidance Documents
REF Title Inside
Identifier
Version Note
[TD_GEN] MS6xxx Technical Datasheet TPR0702 C Hardware Datasheet details
the FSP
[TD] MS6001 Technical Datasheet TPR0705 D Hardware Datasheet details
the FSP
[APP_SEC] Security Recommendations for 90nm
Products
TPR0706 B General Security
recommendations for the TOE
[APP_DES] Secure Hardware DES/TDES for 90nm
products
TPR0707 C Hardware TDES
recommendations
[APP_AES] Secure Hardware AES for 90nm
products
TPR0708 B Hardware AES
recommendations
[APP_AD-
X3]
Ad-X3 Datasheet TPR0701 B Ad-X3 Hardware Datasheet
[APP_RNG] Generating Random numbers to known
standards for 90nm products
TPR0709 C Details how to write an AIS31
driver using the hardware and
the AIS31 test routines from
the Inside toolbox
[APP_TBX] Toolbox 06.04.01.02 TPR0711 G Toolbox 06.04.01.02
Datasheet details the FSP for
the Toolbox functions
[APP_TBX_
ERR]
Tbx 06.04.01.xx Erratasheet TPR0727 A Tbx 06.04.01.xx erratasheet
[APP_TBX_
SEC]
Secure use of 06.04.01.02 TPR0712 E Toolbox 06.04.01.02 family
Security recommendations
[APP_WEA
R]
Wear Levelling library and low level
Flash drivers
TPR0710 A Wear Levelling user guide
[APP_CRYP
T]
Efficient use of AD-X3 TPR0726 C Ad-X3 User Guide
[APP_SEC_
ACC]
MS6xxx Secure Acceptance Guidance TPR0754 A Secure Acceptance of MS6xxx
products
[APP_SC30
0]
SC300 Guide DDI 0447A 0447A A SC300 Guide [ARM
Datasheet]
[ACT] SmartACT User’s Manual TPR0134 E Security IC developer Code
entry user manual
9/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
[COF] Customer Option Form MS600X_C
OF_V1.0-
25_RV.pdf
1.0 Customer Option Form
10/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4.2.3 TOE Life Cycle Addresses
Function Company Location Phase
 IC Design
 Dataprep
 Cryptographic Support
Software Development
Inside Secure
(MEY)
Inside Secure
Arteparc Bachasson, Bat A
Rue de la carriere de Bachasson, CS70025
13590 MEYREUIL - FRANCE
2
 IC Design Inside Secure
(EKB)
Inside Secure
Vault-IC Division
Torus Building, Rankine Avenue,
Scottish Enterprise Technology Park
East Kilbride - SCOTLAND
2
 IC Design Inside Secure
(Nice)
Inside Secure
Space Antipolis 9
2323 chemin St-Bernard
06225 Vallauris Cedex
2
 Wafer Manufacturing
and Mask Site
TSMC No. 8, Li-Hsin Rd. VI, Hsinchu Science Park,
Hsinchu, Taiwan 300-78, R. O. C.
3
 Masks Manufacturing
Site
TCE 1127-3 Hopin Road
Padeh City
Taoyuan
Taiwan 30080
3
 Test Centre ASE Advanced Semiconductor Engineering
26 Chin 3rd Rd
Nantze Export Processing Zone
Kaohsiung
Taiwan
3
 Warehouse Hong Kong Hub FedEx Hong Kong RDC
9/F, Phase One, Modern Terminals
Warehouse Building
11/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4.2.4 TOE Description
Figure 1 gives an overview of the MS6001 device.
Figure 1 - Block Diagram of the MS6001 TOE
The Target of Evaluation (TOE) is a Secure Microcontroller (Security IC) composed of a processing
unit, security components, I/O port, ROM, FLASH, and RAM memories.
12/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
The TOE will contain software elements during its life cycle. This software falls into 2 distinct
categories:
• IC Dedicated Software comprising
o IC Dedicated Test Software
o IC Dedicated Support Software (Cryptographic Support Software / Wear Levelling)
• Security IC Embedded Software (Composite Product)
IC Dedicated Software:
 IC Dedicated Test Software
Test Software includes the test programs that are produced as evidence to support the ATE class
for the evaluation of the TOE. INSIDE Engineering Code is provided to facilitate testing of the device;
this Engineering Code is applicable to Phases 2 and 3 of the TOE life Cycle. To further aid testing of
the TOE, additional test programs may be loaded into the FLASH. In addition to the Test Software,
the TOE also includes dedicated hardware to perform testing. To allow the ITSEF to perform testing
of the TOE, the TOE is delivered with an INSIDE Engineering Code and some simple test routines
stored in the FLASH. It must be noted that this Engineering Code and associated Test Software
is not part of the TOE. The entry and abuse of test modes (hardware) must be verified after TOE
Delivery: this is evaluated according to the Common Criteria assurance family AVA_VAN. Refer to
TOE Summary Specification for further information.
 IC Dedicated Support Software
Cryptographic Support Software (Toolbox): The TOE where applicable also consists of a
Cryptographic Toolbox provided by INSIDE. This Toolbox is stored in ROM and is embedded on the
TOE. The user of this document should refer to the TOE Summary specification of this document for
the full details. The INSIDE Toolbox is considered part of the TOE.
Wear Levelling Library: The TOE where applicable also consists of a Wear Levelling library
provided by INSIDE. This Library is stored in ROM and is embedded on the TOE. The user of this
document should refer to the TOE Summary specification of this document for the full details. The
INSIDE Wear Levelling Library is considered part of the TOE.
Security IC Embedded Software:
The final version of the MS6001 device also includes embedded software; this final version of the
product is referred to as a Composite Product. The Security IC Embedded Software will be stored
in FLASH memory. All data managed by the Security IC Embedded Software is called User Data. In
addition, Pre-personalisation Data [PP] belongs to the User Data.
The Composite Product comprises
• the TOE
• the Security IC Embedded Software comprising
o Security IC Embedded Software (stored in FLASH)
o User Data (especially personalisation data and other data generated and used by
the Security IC Embedded Software)
The Security IC Embedded Software and the User Data are developed separately to the hardware
TOE by the Inside Customers. The Security IC Embedded Software is not part of the TOE.
Note: even though the Security IC Embedded Software is not part of the TOE, the documentation
delivered as evidence for the AGD Class (Guidance Documentation) aid the developer to ensure
the correct operation of the device and more importantly the security functionality of the device.
Therefore, the Guidance Documentation is considered part of the TOE.
Therefore, the TOE comprises:
13/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
• the circuitry of the IC (hardware including the physical memories)
• initialisation data related to the IC Dedicated Software and the behaviour of the security
functionality a
• the associated guidance documentation
• Cryptographic and Wear Levelling Support Software
The TOE is designed and generated by the TOE manufacturer.
The TOE is intended to be used for a Secure Microcontroller product (Security IC), independent of
the physical interface and the way it is packaged. Generally, a Security IC 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.
Note that the Security IC is usually packaged. However, the way it is packaged is not specified here.
a
This may also be coded in specific circuitry of the IC; for a definition refer to the Glossary.
14/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.4.2.5 Cryptographic Toolbox Software
The TOE contains the 06.04.01.02 Inside Toolbox which contains the following algorithms and
functions:
Algorithm Function
AIS31 Online Test vTbx4CsAis31
Selftest vTbx4CsSelfTest
RSA vTbx4CsExpModSecure
vTbx4CsExpModFast
RSA with CRT vTbx4CsCRTSecure
vTbx4CsCRTFast
Prime Gen (Miller Rabin) vTbx4CsPrimeGenSecure
vTbx4CsPrimeGenFast
FIPS PrimeGen (Miller Rabin) vTbx4CsPrimeGenFipsSecure
vTbx4CsPrimeGenFipsFast
vTbx4CsLucas
ECDSA over Zp vTbx4CsGFpEcDsaGenerateSecure
vTbx4CsGFpEcDsaGenerateFast
vTbx4CsGFpEcDsaVerify
EC-DH over Zp vTbx4CsGFpEccAddSecure
vTbx4CsGFpEccDblSecure
vTbx4CsGFpEccMulSecure
vTbx4CsGFpEccAddFast
vTbx4CsGFpEccDblFast
vTbx4CsGFpEccMulFast
vTbx4CsGFpEcRandomiseCoordinate
vTbx4CsGFpEccConvAffineToProjective
vTbx4CsGFpEccConvProjectiveToAffine
vTbx4CsGFpEccPointIsValid
ECDSA over GF(2n) vTbx4CsGF2nEcDsaGenerateSecure
vTbx4CsGF2nEcDsaGenerateFast
vTbx4CsGF2nEcDsaVerify
EC-DH over GF(2n) vTbx4CsGF2nEccAddSecure
vTbx4CsGF2nEccDblSecure
vTbx4CsGF2nEccMulSecure
vTbx4CsGF2nEccAddFast
vTbx4CsGF2nEccDblFast
vTbx4CsGF2nEccMulFast
vTbx4CsGF2nEcRandomiseCoordinate
15/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
vTbx4CsGF2nEccConvAffineToProjective
vTbx4CsGF2nEccConvProjectiveToAffine
vTbx4CsGF2nEccPointIsValid
vTbx4CsClear
vTbx4CsComp
vTbx4CsDiv
vTbx4CsFill
vTbx4CsFmult
vTbx4CsGCD
vTbx4CsModularSetup
vTbx4CsRedMod
vTbx4CsSmult
vTbx4CsSquare
vTbx4CsSecwap
Toolbox 06.04.01.02 contains the full set of cryptographic functions however the SHA functions are
out of the scope of the TOE. The functions highlighted in red and Italics are not part of the TSF.
16/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.5 TOE Life Cycle
This Security Target is fully conformant to the claimed PP, section 2.3, the full details of the Security IC
life cycle is shown in the PP. This Security Target gives a short summary of the information given in the
PP. Information is also given within this Security Target to expand on the applicable phases of the life
cycle of the TOE.
1.5.1 Overview of the Composite Product Life Cycle
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 TOE
(IC) development and production:
• The IC Development (Phase 2):
o IC design
o IC Dedicated Software development
• The IC Manufacturing (Phase 3):
o integration and photomask fabrication
o IC production
o IC testing
o Preparation
o Pre-personalisation if necessary
In addition, five important stages have to be considered in the Composite Product life cycle:
• Security IC Embedded Software Development (Phase 1) (not part of the TOE)
• the IC Packaging (Phase 4)
• the Composite Product finishing process, preparation and shipping to the personalisation
line for the Composite Product (Composite Product Integration Phase 5) a
• 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
a
It should be noted that as the TOE contains FLASH memory Phase 1 Security IC Embedded Software Development can also
take place in Phase 5 that is prior to personalisation and finishing. In theory loading of the FLASH embedded software could
take place later in the life cycle that is it could be loaded once shipped to the end user. This is not part of the life cycle.
17/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Figure 2 - Definition of “TOE Delivery” and responsible Parties
The Security IC Embedded Software is developed outside the TOE development between Phase 1
and 5 (as the TOE contains FLASH memory). The TOE is developed in Phase 2 and produced in
Phase 3. Then the TOE can be delivered in the form of wafers or sawn wafers (dice).
In the following the term “TOE Delivery” (refer to Figure 2) is uniquely used to indicate:
• the TOE is delivered after Phase 3 in the form of wafers or sawn wafers (dice)
• the Security Target uniquely uses the term “TOE Manufacturer” (refer to Figure 2) which
includes the following roles:
o the IC Developer (Phase 2) and the IC Manufacturer (Phase 3)
Hence, the “TOE Manufacturer” comprises all roles beginning with Phase 2 and before “TOE
Delivery”. Starting with “TOE Delivery”, another party takes over the control of the TOE.
The Security Target uniquely uses the term “Composite Product Manufacturer” which includes all
roles (outside TOE development and manufacturing) except the End-consumer as user of the
Composite Product (refer to Figure 2) which are the following:
• Security IC Embedded Software development (Phase 1)
• the IC Packaging Manufacturer (Phase 4) if the TOE is delivered after Phase 3 in the form
of wafers or sawn wafers (dice)
• the Composite Product Manufacturer (Phase 5) and the Personaliser (Phase 6).
Phase 1:
IC Embedded
Software Development
Phase 2:
IC Development
Phase 3:
IC Manufacturing
Phase 4:
IC Packaging
Phase 5:
Composite Product
Integration
Phase 6:
Personalisation
Phase 7:
Operational Usage
TOE Delivery
TOE
Manufacturer
Composite
Product
Manufacturer
IC Embedded
Software Developer
IC Developer
IC Manufacturer
Personaliser
Composite Product Issuer
Composite Product
Integrator
Consumer of Composite
Product (End-Consumer)
Delivery of
Composite
Product
IC Packaging Manufacturer
18/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.5.2 Phases 2 and 3 of the TOE Life Cycle
1.5.2.1 Phase 2 IC Development
The development of the TOE is applicable to phase 2 of the life cycle and can be split into two
sections:
• IC design
• Support Software Development (Cryptographic Toolbox and Wear Levelling Library)
IC design: IC design takes place across two locations, the Inside Design Centre in East Kilbride
Scotland (EKB), and the design centre in Meyreuil France (MEY). The main project design team is
located in MEY but some modules or libraries may originate in other Inside Secure design locations.
Support Software Development: The development takes place within the Inside Design Centre.
To ensure security of the design centre, IC design takes place within a secure environment; access
is controlled with full traceability. A dedicated security person is on site at all times. The IC and
Toolbox development is achieved using appropriate development tools running on a secure network.
All access to tools and data are controlled using appropriate restrictions and passwords. The full
details are shown within the evidence provided for the ALC class. On completion of the design
database, the data is transferred from Design to Dataprep to allow for generation of the Photo masks
used to manufacture the TOE.
1.5.2.2 Phase 3 IC Manufacturing
The IC manufacturing falls into three sections
• Dataprep and Mask Shop
• Wafer Fab
• Testing
Dataprep and Mask Shop: The design database is delivered from the design centre to the Dataprep
team within Inside Secure. This delivery and acceptance process and associated outputs are
delivered as part of the evidence provided for the ALC class. The Photo masks used to manufacture
the TOE are created by the Mask Shop. Data is transferred from Inside Secure to the Mask Shop by
secure FTP. Once created the Photo masks are transferred to the Wafer Fab by a secure approved
carrier. This transfer includes tamper evidence and full traceability.
Wafer Fab: The TOE is manufactured within the Wafer Fabrication facility. The fabrication process
occurs within the secure facility, as with the protection mechanisms in place in Phase 2 access to
the fabrication facility is restricted. The batches are controlled using a tracking database to ensure
that there is traceability of wafers at all times (including rejected wafers/dies). On completion of the
fabrication process, the wafers are transferred to the test facility for test and pre-personalisation.
Transfer is by a secure carrier, includes tamper evidence, and has full traceability.
Testing: This stage of the process includes production testing (refer to ATE evidence), pre-
personalisation, configuration of the security functionality and optionally, wafer thinning and saw. The
test facility has a controlled environment, access is restricted with full traceability, and dedicated
security personnel are on site at all times.
19/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.5.3 Phase 3 of the TOE Life Cycle
1.5.3.1 Security IC Embedded Software Loading
The TOE is a FLASH product and the Security IC Embedded Software is loaded during Phase 3 of
the TOE life cycle under control of the TOE Manufacturer. This loading takes place in a secure
environment as detailed in section 1.4.2.3. To be more precise software loading takes place within
either the Test Centre or the Inside Secure development (design) centre. The controls listed in
section 1.5.2 are also applicable to the Software loading operation.
The loading of software is only performed by the TOE manufacturer via the hardware loader. The
hardware loader is part of the Test Mode and is therefore only accessable to Inside Secure
authenticated engineers. The hardware loader is disabled as soon as the device is configured in
User Mode. Access to the hardware loader is not provided to the Composite Product manufacturer.
20/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
1.5.4 State of the TOE between sites
The following table (figure 3) details the state and protection applicable to the TOE between sites as
detailed in the Life Cycle flow.
Function Wafer
Wafer
Manufacturing
Test Mode -
Protected1,
Unconfigured, No
Loader Present
Test Centre Test Mode -
Protected1,
Configured
Transport Code2
Delivery Phase 3
Assembly
Manufacturing
Delivery
Warehouse User Mode,
Configured,
Transport Code2
Customer
1
Protected by Authentication Process
2
Protected by Transport Code
Figure 3 - Definition of “TOE Delivery” and responsible Parties
1.5.5 Modes of Operation and Life Cycle Phases
The TOE has two distinct modes of operation:
Test Mode This mode is designed to allow authenticated test engineers
access to Test features of the TOE. This mode of operation is
applicable to the full life cycle of the TOE, however this is only
applicable to the TOE Manufacturer via the authentication
mechanism available to authenticated engineers.
User Mode This is the Mode of operation that the end Security IC (composite
product) is intended to be used in. This mode of operation is
dependent on the ROM and NVM code loaded. This mode of
operation is available throughout the life cycle of the TOE.
1.5.6 Composite Product Manufacturer Phases of the Life Cycle
Although the pertinent phases of the Life Cycle associated with the TOE and this Security Target are
Phases 2 and 3, it should be noted that parts of the TOE and this Security Target relate to Phase 1
of the TOE life Cycle. The user of this document should note the following:
• Development Samples
• Guidance Documents
• Code Entry (Security IC Embedded Software Delivery)
Development Samples: To aid with the development of the Security IC Embedded Software,
development samples (with JTAG debug interface) can be delivered by Inside. The development
samples are treated with the same level of protection by Inside as the final IC and are managed
through the already approved controlled sample process.
Guidance Documents: To ensure that the end Composite Product is fully protected and that the
SFR enforcing mechanisms cannot be tampered with or bypassed, user guidance is delivered in
Phase 1 to the Security IC Embedded Software Developer. Delivery procedures are in place to
21/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
ensure the confidentiality of the sensitive information contained in this documentation set, including
secure courier delivery with traceability is followed. Also all parties are covered with NDA before any
information is delivered (this also is applicable to Tools and Emulator).
Code Entry: Guidance documents and a delivery tool (SmartACT) are delivered to the Security IC
Embedded Software Developer. The guidance document [ACT] describes how to use the SmartACT
tool and how to securely transmit the final code to Inside for embedding on the final device. As part
of the code delivery a Customer Option Form [COF] is also delivered to the Code entry team in Inside
Secure, this gives details of the options that the customer may choose for the MS6001 device.
Guidance Documents and Code Entry documents are also delivered as evidence for the AGD class,
to allow the ITSEF to use these as part of the search for vulnerabilities during the Vulnerability
Assessment part of the evaluation.
22/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
2 CONFORMANCE CLAIMS
This chapter contains details the conformance claims for the TOE.
2.1 CC Conformance Claim
This Security Target claims to be conformant to the Common Criteria Version 3.1, Revision 4,
September 2012.
Furthermore, it claims to be CC Part 2 extended and CC Part 3 conformant. The extended Security
Functional Requirements are defined in the Protection Profile.
2.2 Package Claim
The TOE is evaluated to EAL5 level augmented with AVA_VAN.5 and ALC_DVS.2.
2.3 PP Claim
This Security Target is strictly conformant to the Protection Profile BSI-CC-PP-0084-2014 “Security
IC Platform Protection Profile with Augmentation Packages”. The following augmentation packages
from PP have been included.
• Package 1: Loader dedicated for usage in secured environment only.
o P.Lim_Block_Loader
o O.Cap_Avail_Loader
o OE.Lim_Block_Loader
o FMT_LIM.1/Loader
o FMT_LIM.2/Loader
• Package for Masquerade “Authentication of the Security IC”
o T.Masquerade_TOE
o FIA_API.1
o O.Authentication
o OE.TOE_Auth
2.4 PP Refinements
Refinements are made to the PP within this security target relating to the Cryptographic Operations.
Refinements are made to the following Security objectives for the environment:
• OE.Resp-Appl
• OE.Lim_Block_Loader
2.5 PP Additions
The following organisational security policies, security objectives, and security functional
requirements have been added.
• P.Add-Functions
• A.Key-Function
• O.Add-Functions
• FCS_COP.1
23/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
2.6 PP Claims Rationale
The differences between this Security Target and the BSI-CC-PP-0084-2014 that is the addition of:
• Organisational Security Policy
• Assumptions
• Security Objectives for the TOE
• Security Functional Requirements for the TOE
Do not affect the conformance claim of this Security Target. The Rationale for these additions is
given in section 6 and section 7 of this ST.
For each addition, the appropriate section clearly shows the addition, that is, section 3, Section 4
and section 6.
Although the PP recommends an EAL4 certification level with augmentations, the TOE claims an
EAL5 plus certification level. This ST maintains the conformance to BSI-CC-PP-0084-2014, the
rationale for this is given in sections 6.2.1 and 6.3.3.
All the Protection Profile requirements have been shown to be satisfied within this Security Target.
24/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
3 SECURITY PROBLEM DEFINITION
This chapter describes the security aspects of the environment in which the TOE is intended to be used.
As this security target is conformant to BSI-CC-PP-0084-2014, this section contains only the relevant
details and a summary where applicable. For complete details, refer to the Protection Profile.
3.1 Description of Assets
Assets regarding the Threats
The assets (related to standard functionality) to be protected are
• the User Data
• 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 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
According to this Protection Profile there is the following high-level security concern related to
security service:
SC4 deficiency of random numbers.
To be able to protect these assets (SC1 to SC4) the TOE shall self-protect its TSF. Therefore, 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 photo masks
Such information and the ability to perform manipulations assist in threatening the above assets.
25/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
3.2 Threats
The threats are listed in BSI-CC-PP-0084-2014, only a summary is provided in this Security target.
The standard threats to the TOE are shown in Figure 4.
Figure 4 - Standard Threats
The threats relating to specific security services are shown in Figure 5.
Figure 5 - Threats related to security service
The Security IC Embedded Software may be required to contribute to preventing the threats. At least
it must not undermine the security provided by the TOE. For detail refer to the assumptions regarding
the Security IC Embedded Software specified in Section 3.4
The above security concerns are derived from considering the operational usage by the end-
consumer (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.
T.Malfunction
T.Phys-Probing T.Leak-Forced
T.Abuse-Func
T.Phys-Manipulation T.Leak-Inherent
From BSI-CC-PP-0084-2014
From BSI-CC-PP-0084-2014
T.RND
T.Masquerade_TOE
26/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
3.3 Organisational Security Policies
The following Figure 6 shows the policies applied in this Security Target. The IC Developer /
Manufacturer must apply the policy “Protection during TOE Development and Production (P.Process-
TOE)” as specified below.
Figure 6 - Policies
P.Process-TOE Protection 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.
The accurate identification is introduced at the end of the production test in phase 3. Therefore, the
production environment must support this unique identification.
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:
• RSA without CRT b*
• RSA with CRT b *
• PrimeGen (Miller Rabin algorithm) b *
• Lucas Test b *
• ECDSA over Zp b *
• EC-DH over Zp b *
• ECDSA over GF(2n) b *
• EC-DH over GF(2n) b *
The organisational security policy “limiting and blocking the loader functionality
(P.Lim_Block_Loader)” applies to Loader dedicated for usage in secured environment. The
Production Test Environment must apply this security policy.
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
P.Process-TOE
From BSI-CC-PP-0084-2014
P.Add-Functions
P.Lim_Block_Loader
From AUG
27/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
availability of the Loader in order to protect stored data from
disclosure and manipulation.
3.4 Assumptions
Full details of the assumptions are listed in BSI-CC-PP-0084-2014, only a summary is provided in
this Security Target. Full details are given for the additional assumption taken from [AUG].
Figure 7 shows the assumptions applied in this Security Target.
Figure 7 - Assumptions
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 (refer to Section 1.5)
are assumed to be protected appropriately. For a list of assets to be
protected, see below.
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 and personalisation data including specifications of formats and
memory areas, test related data
• the User Data and related documentation
• material for software development support
The developer of the Security IC Embedded Software must ensure the appropriate “Treatment of
User Data of the Composite TOE (A.Resp-Appl)” while developing this software in Phase 1 as
specified below.
A.Resp-Appl Treatment of User Data of the Composite TOE
All User Data of the Composite TOE are owned by the Security IC
Embedded Software. Therefore, it must be assumed that security
relevant User Data of the Composite TOE (especially cryptographic
From BSI-CC-PP-0084-2014
A.Key-Function
From [AUG]
A.Process-Sec-IC A.Resp-Appl
28/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
keys) are treated by the Security IC Embedded Software as defined
for its specific application context.
The developer of the Security IC Embedded Software must ensure the appropriate “Usage of key-
dependent 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
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 of User Data including cryptographic
keys.
29/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
4 SECURITY OBJECTIVES
The full details of the Security Objectives are listed in BSI-CC-PP-0084-2014, only a summary is
provided in this Security target.
4.1 Security Objectives for the TOE
The user has the following standard high-level security goals related to the assets:
SG1 maintain the integrity of 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.
The Security IC may not distinguish between User Data which is publicly known or requires being
confidential. Therefore, the Security IC shall protect the confidentiality and integrity of the User Data
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.
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.
Figure 8 - Standard Security Objectives
O.Malfunction
O.Phys-Probing O.Leak-Forced
O.Abuse-Func
O.Phys-Manipulation O.Leak-Inherent
O.Identification
From BSI-CC-PP-0084-2014
30/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
According to this Security Target there is the following high-level security goal related to specific
functionality:
SG4 provide true random numbers.
The additional high-level security considerations are refined below by defining security objectives as
required by the Common Criteria (refer to Figure 9).
Figure 9 - Security Objectives related to Specific Functionality
Security Objectives related to Specific Functionality (referring to SG4).
The TOE shall provide “Additional Specific Security Functionality (O.Add-Functions)” [AUG] as
specified below.
O.Add-Functions Additional Specific Security Functionality
The TOE shall provide the following specific security functionality
to the Security IC Embedded Software:
• TDES
• AES
As per [AUG]
• RSA without CRT
• RSA with CRT
• ECDSA over Zp
• EC-DH over Zp
• ECDSA over GF(2n)
• EC-DH over GF(2n)
As per Inside Secure
• PrimeGen (Miller Rabin algorithm)
• Lucas Test
The TOE 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.
O.RND
From BSI-CC-PP-0084-2014
From [AUG]/[PP]
O.Add-Functions
O.Cap_Avail_Loader
O.Authentication
31/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
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.
4.2 Security Objectives for the Security IC Embedded Software
development Environment (not part of TOE)
The development of the Security IC Embedded Software is outside the development and
manufacturing of the TOE (cf. section 1.5). The Security IC Embedded Software defines the
operational use of the TOE. This section describes the security objective for the Security IC
Embedded Software.
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.
By definition, cipher or plain text data and cryptographic keys are User Data. The Security IC
Embedded Software shall treat this 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 the 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 not practical to derive the private key from a public key if asymmetric algorithms are
used. If keys are imported into the TOE and/or derived from other keys, quality and confidentiality
must be maintained. This implies that appropriate key management has to be realised in the
environment [AUG].
32/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
4.3 Security Objectives for the operational Environment
TOE Delivery up to the end of Phase 6
Appropriate “Protection during Packaging, Finishing and Personalisation (OE.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.
OE.Process-Sec-IC Protection during composite product manufacturing
Security procedures shall be used after TOE Delivery 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 Phases after TOE Delivery up to the end of
Phase 6 (refer to Section 1.5) must be protected appropriately.
For a preliminary list of assets to be protected, refer to (Section
3.4, A.Process-Sec-IC).
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.
Phase 3
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.
33/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
4.4 Security Objectives Rationale
Table 1 below shows how the assumptions, threats, and organisational security policies are
addressed by the objectives. The text following the table justifies this in detail.
Assumption, Threat or Organisational Security
Policy
Security Objective Notes
A.Resp-Appl OE.Resp-Appl Phase 1
A.Key-Function 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
O.Cap_Avail_Loader
T.RND O.RND
P.Add-Functions O.Add-Functions
P.Lim_Block_Loader O.Cap_Avail_Loader
OE.Lim_Block_Loader
T.Masquerade_TOE O.Authentication_TOE
OE.TOE_Auth
Table 1 - Security Objectives versus Assumptions, Threats or Policies
The justification related to the assumption “Usage of Key-dependent Functions (A.Key-Function)” is
as follows:
Since OE.Resp-Appl requires the Security IC Embedded Software developer to implement those
measures assumed in A.Key-Function, the assumption is covered by the objective.
The justification related to the assumption “Treatment of user data of the Composite TOE (A.Resp-
Appl)” is as follows:
Since OE.Resp-Appl requires the developer of the Security IC Embedded Software to implement
measures as assumed in A.Resp-Appl, the assumption is covered by the objective.
The justification related to the organisational security policy “Protection during TOE Development
and Production (P.Process TOE)” is as follows:
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 section 3.1. 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.
34/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
The justification related to the assumption “Protection during Packaging, Finishing and
Personalisation (A.Process-Sec-IC)” is as follows:
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.
The justification related to the threats “Inherent Information Leakage (T.Leak Inherent)”, “Physical
Probing (T.Phys Probing)”, “Malfunction due to Environmental Stress (T.Malfunction)”, “Physical
Manipulation (T.Phys Manipulation)”, “Forced Information Leakage (T.Leak Forced)“, “Abuse of
Functionality (T.Abuse Func)” and “Deficiency of Random Numbers (T.RND)” is as follows:
For all threats, the corresponding objectives (refer to Table 1) are stated in a way that directly
corresponds to the description of the threat (refer to Section 3.2). It is clear from the description of
each objective (refer to Section 4.1), that the corresponding threat is removed if the objective is valid.
More specifically, in every case the ability to use the attack method successfully is countered, if the
objective holds.
The justification related to the security objective “Additional Specific Security Functionality (O.Add-
Functions)” is as follows:
Since O.Add-Functions requires the TOE to implement exactly the same specific security
functionality as required by P.Add-Functions, the organizational security policy is covered by the
objective.
Nevertheless, the security objectives O.Leak-Inherent, O.Phys-Probing, O.Malfunction, O.Phys-
Manipulation and O.Leak-Forced define how to implement the specific security functionality required
by P.Add-Functions (Note that these objectives support that the specific security functionality is
provided in a secure way as expected from P.Add-Functions). Especially O.Leak-Inherent and
O.Leak-Forced refer to the protection of confidential data (User Data or TSF Data (section 7.1) in
general. User Data are also processed by the specific security functionality required by P.Add-
Functions.
The following text gives details of the clarification added to OE.Resp-Appl. By definition cipher or
plain text data and cryptographic keys, are defined as User Data. Therefore, the Security IC
Embedded Software will protect such data if required and use keys and functions appropriately in
order to ensure the strength of cryptographic operation. Strength 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. These measures make sure that the
assumption A.Resp-Appl is still covered by the security objective OE.Resp-Appl although additional
functions are being supported according to P.Add-Functions.
The justification related to the organisational security policy “Limitation of capability and blocking of
the Loader (P.Lim_Block_Loader) is as follows:
The organisational security policy “Limitiation of capability and blocking of 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 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.
The justification of the additional policies (P.Add-Functions), (A.Key-Function) and (O.Add-
Functions) do not contradict the rationale already given in the Protection Profile for assumptions,
policy and threats defined in the PP and within this Security Target.
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.
35/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
5 EXTENDED COMPONENTS DEFINITION
The extended components:
• FCS_RNG.1
• FMT_LIM.1
• FMT_LIM.2
• FAU_SAS.1
• FDP_SDC.1
• FIA_API.1
The above are defined within the Protection Profile [PP] that this Security Target is strictly conformant
to.
36/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
6 IT SECURITY REQUIREMENTS
The standard Security Requirements are shown in Figure 10. These security components are listed and
explained below.
Figure 10 - Standard Security Requirements
Standard security requirements which
 protect user data and
 also support the other SFRs
Malfunction
From BSI-CC-PP-0084-2014
Limited Fault
Tolerance
(FRU_FLT.2)
Failure with
Preservation of
State
(FPT_FLS.1)
Leakage
Basic Internal
Transfer
Protection
(FDP_ITT.1)
Basic Internal
TSF Data
Transfer
Protection
(FPT_ITT.1)
Subset
Information
Flow Control
(FDP_IFC.1)
Resistance to
Physical Attack
(FPT_PHP.3)
Physical Manipulation and Probing
Limited
Capabilities
(FMT_LIM.1)
Limited
Availability
(FMT_LIM.2)
Standard SFR which
 Support the TOE life cycle
 And prevent abuse of functions
Abuse of Functionality
Audit Storage
(FAU_SAS.1)
Identification
Stored data
integrity
monitoring and
action
(FDP_SDI.2)
Stored data
confidentiality
(FDP_SDC.1)
37/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
The Security Functional Requirements related to Specific Functionality are shown in Figure 11. These
security functional components are listed and explained below.
Figure 11 - Security Functional Requirements related to Specific Functionality
6.1 Security Functional Requirements for the TOE
In order to define the Security Functional Requirements Part 2 of the Common Criteria was used.
However, some Security Functional Requirements have been refined (please refer to the Protection
Profile [PP]).
Malfunctions
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
Dependencies: FPT_FLS.1 Failure with preservation of secure state.
FRU_FLT.2.1 The TSF shall ensure the operation of all the TOE’s capabilities when
the following failures occur: exposure to operating conditions which
Random
Number
Generation
(FCS_RNG.1)
From BSI-CC-PP-0084-2014
Standard SFR related to Specific Functionality
Cryptographic
Operation
(FCS_COP.1)
Random Numbers Cryptography
Limited
Capabilities
(FMT_LIM.1/L
oader)
Limited
Availability
(FMT_LIM.2/L
oader)
Abuse of Functionality Loader
Authentication
Proof of Identity
FIA_API.1)
Authentication
38/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
are not detected according to the requirement Failure with
preservation of secure state (FPT_FLS.1) a
.
Refinement: The term “failure” above also covers “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.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: exposure to operating conditions which may not be
tolerated according to the requirement Limited fault tolerance
(FRU_FLT.2) and where therefore a malfunction could occur b
.
Refinement: The term “failure” above also covers “circumstances”. The TOE
prevents failures for the “circumstances” defined above.
Refinement Note Environmental conditions include but are not limited to power
supply, clock, and other external signals (e.g. reset signal)
necessary for the TOE operation.
Abuse of Functionality
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.
Dependencies: FMT_LIM.2 Limited availability.
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: Deploying Test
Features after TOE Delivery does not allow user data of the
Composite TOE to be disclosed or manipulated, TSF data to be
disclosed or manipulated, software to be reconstructed and no
substantial information about construction of TSF to be gathered
which may enable other attacksc
.
a The TOE operates in a stable way within this operating window, this is verified during the development and manufacturing phase
of the life cycle. This is verified by the ITSEF during the ATE Assurance Class analysis.
b
TSF_ENV_PROTECT details the operating conditions that are not tolerated by the TOE (namely Voltage and temperature out
of bounds, and internal frequency following below a defined level). The TOE takes action through TSF_AUDIT_ACTION to
ensure the TOE fails in a secure state.
c
TSF_TEST details the Limited capability and availability policy.
39/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
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.
Dependencies: FMT_LIM.1 Limited capabilities.
FMT_LIM.2.1 The TSF shall be designed and implemented in a manner that limits
their availability so that in conjunction with “Limited capabilities
(FMT_LIM.1)” the following policy is enforced: Deploying Test
Features after TOE Delivery does not allow user dataof the
Composite TOE to be disclosed or manipulated, TSF data to be
disclosed or manipulated, software to be reconstructed and no
substantial information about construction of TSF to be gathered
which may enable other attacksa
.
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.
Dependencies: No dependencies.
FAU_SAS.1.1 The TSF shall provide the test process before TOE Deliveryb
with
the capability to store the Initialisation Data and/or Pre-
personalisation Data and/or supplements of the Security IC
Embedded Softwarec
in the Non-Volatile Memory.
Physical Manipulation and Probing
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 The TSF shall ensure the confidentiality of the information of the user
data while it is stored in the ROM, RAM and Flash.
The TOE shall meet the requirement “Stored Data Integrity monitoring and action (FDP_SDI.1)” as
specified below.
a
TSF_TEST details the Limited capability and availability policy.
b
The code entry process allows the Security IC Embedded Software developer to deliver pre-personalisation data, details are
given in the SmartACT manual [ACT]. Some configuration of the TOE is allowed using the [COF].
c
The Security IC Embedded Software Developer may deliver data during the code entry process [ACT].
40/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
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 controlled by the
TSF for integrity errors on all objects, based on the following
attributes: ROM, RAM and Flash content.
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall automatically
invoke a violation.
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.
Dependencies: No dependencies.
FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing a
to the TSFb
by responding automatically such that the SFRs are always
enforced.
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.
Note: The TOE provides the ability to perform an automatic response when a violation is detected.
To allow the Security IC Embedded Software developer to choose an appropriate response the TOE
allows some configuration of this response mechanism (refer to TSF_AUDIT_ACTION). Further
details of the automatic response mechanisms can be found in [GEN_TD] (section 10.1.3 Violation
reactions).
Leakage
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.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information
flow control]
a
Direct Probing, manipulation by operating the TOE, out with the specified operating conditions [TD].
b
The TSF are detailed in TOE Summary Specification Section.
41/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
FDP_ITT.1.1 The TSF shall enforce the Data Processing Policy a
to prevent the
disclosure or modification of user data when it is transmitted between
physically separated parts of the TOE.
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.
Dependencies: No dependencies.
FPT_ITT.1.1 The TSF shall protect TSF data from disclosure or modification when
it is transmitted between separate parts of the TOE.
Refinement: The different memories, the CPU and other functional units of the
TOE (e.g. a cryptographic co-processor) are seen as separated
parts of the TOE.
This requirement is equivalent to FDP_ITT.1 above but refers to TSF data instead of User Data.
Therefore, it should be understood as to refer to the same Data Processing Policy defined under
FDP_IFC.1 below.
a
The user of this document should refer to TSF_LEAK_PROTECT for the SFP: Data Processing Policy
42/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
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.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1 The TSF shall enforce the Data Processing Policya
on all
confidential data when they are processed or transferred by the
TOE or by the Security IC Embedded Software b
.
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.
Random Numbers
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 Random number generation – AIS31 PTG.2
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1/PTG.2 The TSF shall provide a physical random number generator that
implements:
(PTG.2.1) A total failure test detects a total failure of entropy source
immediately when the RNG has started. When a total failure is
detected, no random numbers will be output.
(PTG.2.2) If a total failure of the entropy source occurs while the RNG is
being operated, the RNG prevents the output of any internal
random number that depends on some raw random numbers that
have been generated after the total failure of the entropy source.
(PTG.2.3) The online test shall detect non-tolerable statistical defects of the
raw random number sequence (i) immediately when the RNG has
started, and (ii) while the RNG is being operated. The TSF must
not output any random numbers before the power-up online test
has finished successfully or when a defect has been detected.
(PTG.2.4) The online test procedure shall be effective to detect non-tolerable
weaknesses of the random numbers soon.
a
The user of this document should refer to TSF_LEAK_PROTECT for the SFP: Data Processing Policy
b
The sensitive information that must be protected includes information when transferred from one memory location to another
by the user or Security IC Embedded Software or being operated on by the hardware processors. This information must be
protected as it would allow an attacker to gain knowledge of the functions of the TOE TSF, or gain access to cryptographic key
information.
43/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
(PTG.2.5) The online test procedure checks the quality of the raw random
number sequence. It is triggered continuously. The online test is
suitable for detecting non-tolerable statistical defects of the
statistical properties of the raw random numbers within an
acceptable period of time.
FCS_RNG.1.2/PTG.2 The TSF shall provide a physical random number generator that meet:
(PTG.2.6) Test procedure A does not distinguish the internal random
numbers from output sequences of an ideal RNG.
(PTG.2.7) The average Shannon entropy per internal random bit exceeds
0.997.
Notes on RNG Definition of the Security Functional Requirement FCS_RNG.1 has
been taken from [BSI-CC-PP-0084-2014] and is further refined
according to [Functionality classes for random number generators,
Version 2.0, 18. September 2011].
The average Shannon entropy 0.997 per internal random bit compares
to 7.984 per octet.
The RNG is evaluated against AIS31 without post-processing so the
internal random number defined is the RNGDAS output.
44/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Cryptography
The TOE shall meet the requirement “Cryptographic Operation – TDES (FCS_COP.1/TDES)” as
specified below.
FCS_COP.1/TDES Cryptographic operation – TDES
Hierarchical to: No other components.
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
FCS_COP.1.1/TDES The TSF shall perform hardware TDES encryption and decryption in
accordance with a specified cryptographic algorithm: Triple Data
Encryption Standard (TDES) with cryptographic key sizes: 112-bit
and 168-bit that meet the following NIST SP 800-67 [8], NIST SP 800-
38A [9]
Note on TDES TDES Cryptographic operation based on a hardware
dedicated part of the TOE and is applicable to all versions of
the TOE. This is not based on the PP-0084.
FCS_COP.1/AES Cryptographic operation – AES
Hierarchical to: No other components.
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
FCS_COP.1.1/AES The TSF shall perform hardware AES encryption and decryption in
accordance with a specified cryptographic algorithm: Advanced
Encryption Standard (AES) with cryptographic key sizes: 128-bit,
192-bit and 256-bit that meet the following: FIPS 197 November 26,
2001 [7], NIST SP 800-38A [9].
Note on AES AES Cryptographic operation based on a hardware dedicated
part of the TOE and is applicable to all versions of the TOE.
This is not based on the PP-0084.
FCS_COP.1/RSA Cryptographic operation – RSA without CRT
without CRT
Hierarchical to: No other components.
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
45/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
FCS_COP.1.1 The TSF shall perform data encryption and decryption in accordance
with a specified cryptographic algorithm: RSA without CRT and
cryptographic key sizes: between 96 bits and 5120 bits that meet the
following: PKCS#1 V2.2, 27th
October, 2012 [12].
FCS_COP.1/RSA Cryptographic operation – RSA with CRT
with CRT
Hierarchical to: No other components.
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
FCS_COP.1.1 The TSF shall perform data encryption and decryption in accordance
with a specified cryptographic algorithm: RSA with CRT data and
cryptographic key sizes: between 192 bits and 5120 bits that meet the
following: PKCS#1 V2.2, 27th
October, 2012 [12].
FCS_COP.1/ECDSA Cryptographic operation – ECDSA over Zp
over Zp Hierarchical to: No other components.
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
FCS_COP.1.1 The TSF shall perform signature generation and verification in
accordance with a specified cryptographic algorithm: EC-DSA over Zp
and cryptographic key sizes: between 192 bits and 521 bits that meet
the following: FIPS 186-4 [11].
FCS_COP.1/Prime Cryptographic operation – Prime Generation
Generation Hierarchical to: No other components.
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
46/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Cryptographic key generation] FCS_CKM.4 Cryptographic key
destruction
FCS_COP.1.1 The TSF shall perform Miller-Rabin Prime Generation in accordance
with a specified cryptographic algorithm: PrimeGen and cryptographic
key sizes: between 96 bits and 5120 bits that meet the following: FIPS
186-4 [11].
FCS_COP.1/Lucas Cryptographic operation – Lucas Test
Test Hierarchical to: No other components.
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
FCS_COP.1.1 The TSF shall perform Lucas Test in accordance with a specified
cryptographic algorithm: Lucas Test and cryptographic key sizes:
between 96 bits and 5120 bits that meet the following: FIPS 186-4
[11].
FCS_COP.1/EC-DH Cryptographic operation – EC-DH over Zp
over Zp
Hierarchical to: No other components.
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
FCS_COP.1.1 The TSF shall perform signature generation and verification in
accordance with a specified cryptographic algorithm: EC-DH over Zp
and cryptographic key sizes: between 192 bits and 521 bits that meet
the following: ISO/IEC 11770-3:2008.
FCS_COP.1/ECDSA Cryptographic operation – ECDSA over GF(2n)
over GF(2n)
Hierarchical to: No other components.
47/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
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
FCS_COP.1.1 The TSF shall perform signature generation and verification in
accordance with a specified cryptographic algorithm: ECDSA over
GF(2n) and cryptographic key sizes: between 163 bits and 571 bits
that meet the following: FIPS 186-4 [11].
FCS_COP.1/EC-DH Cryptographic operation – EC-DH over GF(2n)
over GF(2n)
Hierarchical to: No other components.
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
FCS_COP.1.1 The TSF shall perform signature generation and verification in
accordance with a specified cryptographic algorithm: EC-DH over
GF(2n) and cryptographic key sizes: between 163 bits and 571 bits
that meet the following: ISO/IEC 11770-3:2008.
Abuse of Functionality Loader
The TOE shall meet the requirement “Limited capabilities – Loader (FMT_LIM.1/Loader)” is specified
below:
FMT_LIM.1/Loader Limited capabilities – Loader
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability – Loader.
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: Deploying Loader
functionality is only available to the TOE Manufacturer.
The TOE shall meet the requirement “Limited availability – Loader (FMT_LIM.2/Loader)” as specified
below:
48/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
FMT_LIM.2/Loader Limited availability – Loader
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities – Loader.
FMT_LIM.2.1/LoaderThe 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: The TSF
prevents deploying the Loader functionality out with the TOE Manufacturer.
Authentication Proof of Identity
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 an accurate and mandatory guidance
which appropriately describes how to implement security
embedded software in such a way to prove the identity of the TOE
to an external entity.
49/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
6.2 Security Assurance Requirements for the TOE
This Security Target is evaluated according to Security Target evaluation (Class ASE)
The “Security Assurance Requirements for the TOE”, for the evaluation of the MS6001 TOE are
those taken from the Evaluation Assurance Level 5 (EAL5) and augmented by taking the following
components:
ALC_DVS.2 and AVA_VAN.5
The assurance requirements are (augmentation from EAL5+ highlighted)
Class ADV: Development
Architectural design (ADV_ARC.1)
Functional specification (ADV_FSP.5)
Implementation representation (ADV_IMP.1)
Well-structured internals (ADV_INT.2)
TOE design (ADV_TDS.4)
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.5)
Delivery (ALC_DEL.1)
Development security (ALC_DVS.2)
Life-cycle definition (ALC_LCD.1)
Tools and techniques (ALC_TAT.2)
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.1)
Class ATE: Tests
Coverage (ATE_COV.2)
Depth (ATE_DPT.3)
Functional tests (ATE_FUN.1)
Independent testing (ATE_IND.2)
Class AVA: Vulnerability assessment
Vulnerability analysis (AVA_VAN.5)
50/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
6.2.1 Refinements of the TOE Assurance Requirements
The Protection Profile BSI-CC-PP-0084-2014 defines refinements to the Security Assurance
requirements defined in CC V3.1 Part 3. The TOE is assessed to EAL5 Level with additional
augmentations which are taken into account in this analysis.
The [PP] allows the TOE to be evaluated above the EAL4+ requirements given in the [PP], therefore
the fact that this Security Target is assessed to EAL5 level, it still maintains the conformance claim
to [PP]. The refinements stated in [PP] remain consistent with the EAL5 package claims of this
Security Target.
The full details of the Assurance Requirement refinements are listed in BSI-CC-PP-0084-2014.
51/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
6.3 Security Requirements Rationale
6.3.1 Rationale for the security functional requirements
Table 2 below gives an overview of how the security functional requirements are combined to meet
the security objectives. The detailed justification follows the table.
Objective TOE Security Functional and Assurance Requirements
O.Leak-Inherent FDP_ITT.1 “Basic internal transfer protection”
FPT_ITT.1 “Basic internal TSF data transfer protection”
FDP_IFC.1 “Subset information flow control”
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”
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
plus those listed for O.Malfunction and
O.Phys-Manipulation
FRU_FLT.2, FPT_FLS.1, FPT_PHP.3
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
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
O.Add-Functions FCS_COP.1 “Cryptographic Operation”
O.Cap_Avail_Loader FMT_LIM.1 “Limited capabilities – Loader”
FMT_LIM.2 “Limited availability – Loader”
OE.Resp-Appl not applicable
OE.Process-Sec-IC not applicable
OE.Lim_Block_Loader not applicable
O.Authentication FIA_API.1
OE.TOE_Auth not applicable
Table 2 - Security Requirements versus Security Objectives
It should be noted by the user of this Security Target Lite that the justification related to the security
objective “Random Numbers (O.RND)” contains the following note:
Depending on the functionality of the TOE 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 about the produced random numbers is available to an attacker.
It should be noted by the user of this Security Target Lite that the justification related to the security
objective “Additional Specific Security Functionality” (O.Add-Functions)” contains the follwoing note:
Depending on the functionality of the end composite device, the Security IC Embedded Software will
have to support the objective by using the additional functions as specified by the [CC]. The user
data processed by the functions relating to FCS_COP.1 is protected as defined for the end
application. The Embedded Software will have to support the objective O.Add-Functions by
implementing the security functional requirements below:
52/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
o [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]
o FCS_CKM.4 Cryptographic key destruction
6.3.2 Dependencies of security functional requirements
Table 3 below lists the security functional requirements defined in this Security Target, their
dependencies and whether they are satisfied by other security requirements defined in this Security
Target.
Security Functional
Requirement
Dependencies Fulfilled by security requirements in
this ST
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
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
FDP_SDC.1 None No dependency
FDP_SDI.2 None No dependency
FCS_RNG.1 None No dependency
FCS_COP.1 (FDP_ITC.1 or FDP_ITC.2 or
FCS_CKM.1)
FCS_CKM.4
See discussion below
FIA_API.1 None No dependency
Table 3 - Dependencies of the Security Functional Requirements
53/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7 TOE SUMMARY SPECIFICATION
This section demonstrates how the TOE matches the Security Functional requirements as detailed in
section 6.1 (Security functional Requirements).
It gives a description of the TSF elements of the TOE to allow an understanding of how the security of
the TOE matches the SFR of section 6.1, and also how they TOE protects itself against tampering,
interfering and bypass of the TSF Features of the TOE.
54/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1 Description of TSF Features of the TOE
7.1.1 TSF_TEST Test Interface
• Test Mode (TME)
• Serial Number Registers Write
The TOE has an engineering test mode (TME). The hardware loader is part of the Test Mode
functionality and is therefore only available when Test Mode is applied.
Test Mode Entry: TME is protected by a test mode entry condition and is only accessible to
authenticated test engineers. This mechanism is strong enough to protect the test functionality of the
TOE.
Serial Number Register Write: In Test Mode it is possible to store pre-personalisation data. The
serial number information is also written at this time.
SFP: Limited capability
and availability Policy
The TOE Test features are only available to authenticated
Inside engineers with the knowledge of the Test Mode Entry
sequence.
7.1.1.1 SFR to TSF Test Interface
Identification
Abuse of Function
FMT_LIM.1
Limited
Capabilities
FMT_LIM.2
Limited
Availability
FAU_SAS.1
Audit Storage
TSF_TEST
Test Interface
Abuse of Functionality
Loader
FMT_LIM.1
/Loader Limited
Capabilities
FMT_LIM.2/Load
er Limited
Availability
55/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.2 TSF_ENV_PROTECT Environmental Protection
• Hardware Protection (Active Shield)
• Voltage Monitor
• Frequency Monitor
• Temperature Monitor
• Light Scan Detector
• Memory Encryption (Scramblers)
• Bus Encryption (Protection)a
• Structure and Layoutb
Hardware Protection: The TOE has an active shield that covers the top of the chip, this provides
tamper evidence protection.
Voltage Monitor: The VCC and GND lines to the TOE are monitored to protect the TOE from the
supply going out of bounds.
Frequency Monitor: The internal frequency is monitored to protect the internal clock falling below a
defined level.
Temperature Monitor: The operating temperature of the TOE is monitored to prevent the TOE from
being operated out-with the correct operating conditions.
Light Scan Detector: The TOE provides a Light scan Detector (LSD) to protect against laser (or
focused light) scanning of the TOE.
Memory encryption: The memories and register file are encrypted.
Bus Encryption: Layout structures are implemented to make internal bus probing difficult. The TOE
contains no visible bus structures.
Structure and Layout: This provides complexity to any attack that involves identifying specific
areas of the TOE.
a
The security mechanism Bus Encryption utilises the layout process of the design, this mechanism is not included in the TOE
testing, FSP, and TDS description, if the evaluator requires further information or confirmation of this mechanism, they can be
shown the methods used during the project site visit. This mechanism has no TSFI.
b
The security mechanism Structure and Layout utilises the TOE design technology, and the layout process of the design, this
mechanism is not included in the TOE testing, FSP, and TDS description, if the evaluator requires further information or
confirmation of this mechanism, they can be shown the methods used during the project site visit. This mechanism has no
TSFI.
56/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.2.1 SFR to TSF_ENV_PROTECT
7.1.3 TSF_LEAK_PROTECT Leakage Protection
• Internal Clock (VFO)
• VFO Jitter
• Dummy Interrupt
• Random Branch Insertion
• Frequency Divider
• CRC Power Scrambling
• Dummy Flash write
• Bus Polarity
• Uniform Data Dependency Timing
• Uniform Branch Timing
• Trash Register Write
• Clock Gating Randomisation
Internal Clock: The TOE provides an internal Variable Frequency Oscillator (VFO).
VFO Jitter: The VFO frequency offers variances of the frequency through time (Jitter) to help against
side channel leakage analysis.
Dummy Interrupt: The TOE can trigger Dummy Interrupts.
Random Branch Insertion: The TOE can insert a branch-to-self instruction at a random interval.
Frequency Divider: The VFO clock can be varied by dividing the clock; this can also be set up by
the IC embedded software to perform this subdivision on the fly.
CRC Power Scrambling: CRC Power scrambling introduces a random component into the power
signature of the chip.
Malfunction
Physical Manipulation
and Probing
FPT_PHP.3
Resistance to
Physical Attacks
FPT_FLS.1
Failure with
preservation of
secure state
Tolerance
TSF_ENV_PROTECT
Environmental
Protection
FDP_SDC.1
Stored data
confidentiality
FPT_SDI.2 Stored
data integrity
monitoring and
action
57/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Dummy Flash write: This allows the Security IC embedded Software to cause a dummy write of the
Flash.
Bus Polarity: When enabled, can mask to power signature of the bus.
Uniform Data Dependency Timing: Ensures that arithmetic operations take a fixed/repeatable
number of cycles.
Uniform Branch Timing: is used to ensure that branch timing is the same for all branch paths.
Trash Register Write: when enabled it allows selected operations that normally end without writing
to write the current value to a trash register. Therefore the power signature associated with whether
or not a register write does or does not occur is masked.
Clock Gating Randomisation: This feature causes the hardware to modify in a random way the
power signature of the core.
SFP: Data Processing
Policy
When processing or moving information within the TOE, the
TOE should not leak any specific information that would
allow an attacker to gain sufficient knowledge to gain
access to secret information stored within the TOE
memories.
7.1.3.1 SFR to TSF_LEAK_PROTECT
Leakage
FDP_ITT.1 Basic
Internal Transfer
Protection
FPT_ITT.1 Basic
Internal TSF Data
Transfer
Protection
TSF_LEAK_PROTECT
Leakage Protection
FDP_IFC.1 Subset
Information Flow
Control
58/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.4 TSF_DATA_PROTECT Data Protection
• Memory Access Protection
• CRC Accelerator
• Parity Checker
• Mirroring
• Enhanced Protection Object (EPO)
• Program stack Checker
• Glitch Detectors
• Secure Bridge
• Memory Protection Unit
• CPU Lockup Protection
• Flash Lock
• Filters on Power Supply
Secure Memory Management: The TOE provides a Memory Protection Unit.
CRC Accelerator: The TOE provides a Cyclic Redundancy Check (CRC32 or CRC16).
Parity Checker: The TOE features parity checking on the ROM, Registers and RAM. If a fault is
injected by modifying a data bit the parity check will be able to detect it and generate a violation.
Mirroring: Some of the internal security registers have been duplicated/ mirrored. A violation is
triggered if the register and its mirror differ.
Enhanced Protection Object: The NVM read is protected against attempted perturbations.
Program Stack Checker: The SC300 core provides the IC Embedded Software a Program Stack
Checker.
Secure Bridge: When enabled, any byte/halfword access will generate error response, and any
fetch access will also generate an error response.
Glitch Detectors: The Glitch Detectors can detect a glitch on the Vcc signal. This protects against
attempted perturbations.
Memory Protection Unit: Is a component for memory protection, supports regions and sub-regions,
overlapping protection regions, access permissions, possibility to define memory access
characteristics.
CPU Lockup Protection: The CPU is able to detect some incoherent code, identified as lockup
state.
Flash Lock: Allows a part of the flash to be locked from any write or erase.
Filters on Power Supply: The filters on the power supply protect and provide robustness against
glitches.
59/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.4.1 SFR to TSF_DATA_PROTECT
Physical Manipulation
and Probing
TSF_DATA_PROTECT
DATA Protection
FPT_PHP.3
Resistance to
Physical Attacks
FDP_SDC.1
Stored data
confidentiality
FPT_SDI.2 Stored
data integrity
monitoring and
action
Malfunction
FRU_FLT.2
Limited fault
tolerance
60/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.5 TSF_AUDIT_ACTION Event Audit and Action
• Reset System
• Security Registers
Reset System: The TOE allows the Security IC Embedded Software to select the response the TOE
makes to a security violation. Several reactions are possible depending upon how the TOE is
configured by the Security IC Embedded Software.
Security registers: The TOE includes several registers to report failures (violations) detected by the
security mechanisms of the TOE.
7.1.5.1 SFR to TSF_AUDIT_ACTION
7.1.6 TSF_RNG Random Number Generator
• True RNG
• Random Generator Enable Bit
• RNGLFSR Post-Processing
• Random Number Total Failure Bit
• RNG Digitized Analog Source Register – RNGDAS
• Random Word Data Register - RDWDR
True RNG: The TOE has an analogue noise source that can be used to provide random numbers
when required by the Security IC Embedded Software.
Random generator Enable Bit: This bit must be set to (re)start the random sequence.
Random Number Total Failure Bit: The TOE sets a flag if the analogue noise source fails. The
Security IC Embedded Software can monitor this security flag and the software can then take
appropriate action.
RNGDAS: The Analogue Noise Source is sampled to create a digitized analogue source that is
accessible to the Security IC Embedded Software through the RNGDAS register.
Malfunction
TSF_AUDIT_ACTION
Event Audit and Action
FPT_FLS.1
Failure with
Preservation of
Secure State
Physical Manipulation
and Probing
FDP_SDI.2 Stored
data integrity
monitoring action
61/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
RDWDR: The digital analogue source from RNGDAS can be post processed. The result of the post-
processed data is accessible to the Security IC Embedded Software through the RDWDR register
7.1.6.1 SFR to TSF_RNG
Leakage
Random Numbers
FCS_RNG.1
Random Number
Generation
TSF_RNG Random
Number Generator
FDP_ITT.1 Basic
Internal Transfer
Protection
FPT_ITT.1 Basic
Internal TSF Data
Transfer
Protection
FDP_IFC.1 Subset
Information Flow
Control
62/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.7 TSF_CRYPTO_HW Hardware Cryptography
• Hardware Triple DES
• Hardware AES
Hardware Triple DES: The TOE provides a hardware DES / TDES engine that enables fast
cryptographic computations.
Hardware AES: The TOE provides a hardware AES engine which enables fast cryptographic
computations.
7.1.7.1 SFR to TSF_CRYPTO_HW
Cryptography
FCS_COP.1
Cryptographic
Operations
TSF_CRYPTO_HW
Hardware Cryptography
63/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.8 TSF_CRYPTO_SW Toolbox Cryptography
• AIS31 Online Test
• RSA
• RSA with CRT
• PrimeGen (Miller Rabin)
• Lucas Test
• ECC Multiply over GF(P)
• ECC Multiply over GF(2n)
• ECDSA generation and verification over GF(2n)
• ECDSA generation and verification over GF(P)
• Self-Test
Self-Test: The TOE can perform a test of the crypto toolbox at the request of the Security IC
Embedded Software
AIS31 Online Test: The TOE provides the ability to run online tests of the random numbers provided
to the RNGDAS register. The test performed is a χ2 (chi squared) test to check the randomness of
the data.
RSA without CRT: The TOE provides RSA without CRT (Modular Exponentiation), data encryption
and decryption functions.
RSA with CRT: The TOE provides RSA with CRT, data encryption and decryption functions.
PrimeGen: The TOE provides RSA cryptographic key generation capability using Miller Rabin
algorithm with confidence criteria (t parameter) between 0 and 255.
Lucas Test: The TOE provides a Lucas Test for Primality
ECC Multiply over GF(P): The TOE provides a Multiplication on an Elliptical Curve
ECC Multiply over GF(2n): The TOE provides a Multiplication on an Elliptical Curve
ECDSA over GF(P): The TOE provides ECDSA over GF(P) cryptographic signature and verification
ECDSA over GF(2n): The TOE provides ECDSA over GF(2n) cryptographic signature and
verification
7.1.8.1 SFR to TSF_CRYPTO_SW
Cryptography
FCS_COP.1
Cryptographic
Operations
TSF_CRYPTO_SW
Software Cryptography
Random Numbers
FCS_RNG.1
Random Number
Generation
64/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.1.9 TSF_AUTHENTICATION
• TSF_CRYPTO_SW Toolbox Cryptography
• TSF_CRYPTO_HW Hardware Cryptography
Authentication: The authentication of the TOE requires that the composite product manufacturer
should select a function from the above security mechanisms in the IC embedded software in order
to prove the identification of the TOE.
7.1.9.1 SFR to TSF_AUTHENTICATION
Authentication Proof
of Identity
FIA_API.1
Authentication
Proof of Identity
TSF_AUTHENTICATION
TOE Authentication
65/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.2 Rationale for TSF
This section demonstrates how the TSF contribute and work together to fulfil the SFR defined in section
6.
7.2.1 Summary of TSF to SFR
Table 4 gives an overview of the TSF that contribute to the SFRs.
Security Functional Requirements
Malfunctions
Leakage
Physical
Manipulation
and
Probing
Abuse
of
Functionality
Identification
Random
Number
Generation
Cryptography
18
Abuse
Of
Functionality
Loader
Proof
of
Identity
FRU_FLT.2
FPT_FLS.1
FDP_ITT.1
FPT_ITT.1
FDP_IFC.1
FPT_PHP.3
FDP_SDC.13
FDP_SDI.2
FMT_LIM.1
FMT_LIM.2
FAU_SAS.1
FCS_RNG.1
FCS_COP.1
FMT_LIM.1
FMT_LIM.2
FIA_API.1
TSF
Features
TSF_TEST X X X X X
TSF_ENV_PROTECT X X X X
TSF_LEAK_PROTECT X X X
TSF_DATA_PROTECT X X X X
TSF_AUDIT_ACTION X X
TSF_RNG X X X X
TSF_CRYPTO_HW X
TSF_CRYPTO_SW X X
TSF_AUTHENTICATION X
Table 4 - Dependencies of the TOE Security Features
18
Refer to Table 6 which gives Cryptographic Functions Overview
66/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.2.2 Rationale for the TSF Features of the TOE
The justification for the SFR relating to Cryptography FCS_COP.1 is as follows:
The SFR “FCS_COP.1/TDES and FCS_COP.1/AES Cryptographic Operation” relates to
TSF_CRYPTO_HW and TSF_CRYPTO_SW. The SFR requires cryptographic operations to be
performed with certain key lengths and to a specific standard. To understand how the mechanisms of the
TSF features contribute to this, a map is shown in Table 5.
FCS_COP.1
requirement TSF Feature Mechanism
/TDES TSF_CRYPTO_HW Triple DES
/AES TSF_CRYPTO_HW AES
/RSA without CRT TSF_CRYPTO_SW
RSA Without CRT
PrimeGen
/RSA with CRT TSF_CRYPTO_SW
RSA with CRT
PrimeGen
/ECDSA over Zp TSF_CRYPTO_SW ECDSA over Zp
/EC-DH over Zp TSF_CRYPTO_SW EC-DH over Zp
/ECDSA over GF(2n) TSF_CRYPTO_SW ECDSA over GF(2n)
/EC-DH over GF(2n) TSF_CRYPTO_SW EC-DH over GF(2n)
/Lucas Test TSF_CRYPTO_SW Lucas Test
N/A
(support for FCS_RNG.1) TSF_CRYPTO_SW AIS31 Online test
Table 5 - Cryptographic Functions Overview
67/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
7.2.3 Note on ADV_ARC.1
The Assurance component ADV_ARC.1 states that the TOE should be self-protected against any
tampering or bypassing of the TSF of the TOE.
The TSF Features TSF_ENV_PROTECT, TSF_AUDIT_ACTION and TSF_DATA_PROTECT contain
mechanisms that fully protected the TOE against any external tamper or bypass.
The Security Mechanisms applicable to this protection are:
• Hardware Protection (Active Shield)
• Voltage Monitor
• Frequency Monitor
• Temperature Monitor
• Glitch Detectors
• Memory Encryption
• Reset System
68/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
8 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 un-
personalised 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 the form of wafers
or sawn wafers (dice,) he has the role of the IC Packaging
Manufacturer (Phase 4) in addition.
End-consumer The customer of the TOE Manufacturer who receives the TOE
during TOE Delivery. The Composite Product Manufacturer
includes the Security IC Embedded Software developer and all roles
after TOE Delivery up to Phase 6. 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.
69/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Pre-personalisation Data Any data supplied by the Card Manufacturer that is programmed
into the non-volatile memory by the Integrated Circuits manufacturer
(Phase 3). This data is for example used for traceability and/or to
secure shipment between phases.
Security IC (as used in this Protection Profile) Composition of the TOE, the
Security IC Embedded Software, User Data and the package (the
Security IC carrier).
Security IC Embedded Software The 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
Test Features All features and functions (implemented by the IC Dedicated Test
Software and/or hardware) which are designed to be used before
TOE Delivery only and delivered as part of the TOE.
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 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.
70/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
8.2 Literature
[1]
Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model;
Version 3.1, Revision 4, September 2012
[2]
Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements;
Version 3.1, Revision 4, September 2012
[3]
Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements;
Version 3.1, Revision 4, September 2012
[4]
Common Methodology for Information Technology Security Evaluation (CEM), Part 2: Evaluation
Methodology; Version 3.1, Revision 4, September 2012
[5]
Supporting Document, Mandatory Technical Document: Application of Attack Potential to Smartcards, March
2009, Version 2.7
[6]
Supporting Document: Composite product evaluation for Smart Cards and similar devices, CCDB-2007-09-
001, Sept. 2007
[7]
Federal Information Processing Standards Publication 197, ADVANCED ENCRYPTION STANDARD (AES),
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, November 26, 2001
[8]
NIST SP 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, revised
January 2012, National Institute of Standards and Technology
[9]
IST SP 800-38A Recommendation for Block Cipher Modes of Operation, 2001, with Addendum
Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode,
October 2010
[10]
Federal Information Processing Standards Publication 180-4 SECURE HASH STANDARD U.S.
DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, 2011 February, 11
[11]
Federal Information Processing Standards Publication 186-4 Digital Signature Standard (DSS).
DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, 2013 July.
[12]
RSL Laboratories, RSA Cryptography Standard, PKCS#1 v2.2, October 27, 2012
[13]
Information technology – Security techniques – Key management – Part 3: Mechanisms using asymmetric
techniques, ISO/IEC 11770-3:2008
[PP]
Security IC Platform Protection Profile with Augmentation Packages, BSI-CC-PP-0084-2014, V1.0
[AIS31]
AIS31: Functionality classes for random number generators, Version 2.0, 18. September 2011
[AUG]
Smartcard Integrated Circuit Augmentations Version 1.0, March 2002, registered under the German
Certification Scheme BSI-AUG-2002
71/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
8.3 List of Abbreviations
CC Common Criteria.
EAL Evaluation Assurance Level.
IC Integrated circuit.
IT Information Technology.
PP Protection Profile.
ST Security Target.
TOE Target of Evaluation.
TSC TSF Scope of Control.
TSF TOE Security Functionality.
72/72 General Business Use
25 February 2016 MS6001 Security Target-Lite
TPG0234B-25Feb16
Headquarters Product Contact
INSIDE Secure
Arteparc Bachasson,
Bat A
Rue de la carrier de
Bachasson
CS70025
13590 Meyreuil
France
Tel: +33 (0)4-42-39-63-00
Fax: +33 (0)4-42-39-63-19
Web Site
www.insidesecure.com
Technical Support
@insidefr.com
Sales Contact
sales_web@insidefr.com
Disclaimer: All products are sold subject to Inside Secure Terms & Conditions of Sale and the provisions of any agreements made between Inside
Secure and the Customer. In ordering a product covered by this document the Customer agrees to be bound by those Terms & Conditions and
agreements and nothing contained in this document constitutes or forms part of a contract (with the exception of the contents of this Notice). A copy of
Inside Secure's Terms & Conditions of Sale is available on request. Export of any Inside Secure product outside of the EU may require an export
Licence.
The information in this document is provided in connection with Inside Secure products. No license, express or implied, by estoppel or otherwise, to any
intellectual property right is granted by this document or in connection with the sale of Inside Secure products. EXCEPT AS SET FORTH IN INSIDE
SECURE'S TERMS AND CONDITIONS OF SALE, INSIDE SECURE OR ITS SUPPLIERS OR LICENSORS ASSUME NO LIABILITY WHATSOEVER
AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTY OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-
INFRINGEMENT. IN NO EVENT SHALL INSIDE SECURE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, EXEMPLARY,
SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, LOSS OF REVENUE, BUSINESS
INTERRUPTION, LOSS OF GOODWILL, OR LOSS OF INFORMATION OR DATA) NOTWITHSTANDING THE THEORY OF LIABILITY UNDER
WHICH SAID DAMAGES ARE SOUGHT, INCLUDING BUT NOT LIMITED TO CONTRACT, TORT (INCLUDING NEGLIGENCE), PRODUCTS
LIABILITY, STRICT LIABILITY, STATUTORY LIABILITY OR OTHERWISE, EVEN IF INSIDE SECURE HAS BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGES. Inside Secure makes no representations or warranties with respect to the accuracy or completeness of the contents of this
document and reserves the right to make changes to specifications and product descriptions at any time without notice. Inside Secure does not make
any commitment to update the information contained herein. Inside Secure advises its customers to obtain the latest version of device data sheets to
verify, before placing orders, that the information being relied upon by the customer is current. Inside Secure products are not intended, authorized, or
warranted for use as critical components in life support devices, systems or applications, unless a specific written agreement pertaining to such intended
use is executed between the manufacturer and Inside Secure. Life support devices, systems or applications are devices, systems or applications that
(a) are intended for surgical implant to the body or (b) support or sustain life, and which defect or failure to perform can be reasonably expected to result
in an injury to the user. A critical component is any component of a life support device, system or application which failure to perform can be reasonably
expected to cause the failure of the life support device, system or application, or to affect its safety or effectiveness.
The security of any system in which the product is used will depend on the system's security as a whole. Where security or cryptography features are
mentioned in this document this refers to features which are intended to increase the security of the product under normal use and in normal circumstances.
© Inside Secure 2013. All Rights Reserved. Inside Secure ®, Inside Secure logo and combinations thereof, and others are registered trademarks or
tradenames of Inside Secure or its subsidiaries. Other terms and product names may be trademarks of others.
The products identified and/or described herein may be protected by one or more of the patents and/or patent applications listed in related datasheets,
such document being available on request under specific conditions. Additional patents or patent applications may also apply depending on geographic
regions.