AT90SC13612RCU EAL5+ Security Target Lite General Business Use

AT90SC13612RCU EAL5+ Security Target Lite General Business Use
General Business Use
AT90SC13612RCU
EAL5+
Security Target Lite
Important notice to readers…
Atmel makes no warranty for the use of its products, other than those expressly contained in the Company’s standard warranty which
is detailed in Atmel’s Terms and Conditions located on the Company’s web site. The Company assumes no responsibility for any errors
which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice,
and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property
of Atmel are granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel’s products are
not authorized for use as critical components in life support devices or systems.
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.
All products are sold subject to Atmel’s Terms & Conditions of Supply and the provisions of any agreements made between Atmel 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 Atmel’s Terms & Conditions of Supply is available on request.
© Atmel Corporation 2009
Contents
Section 1
AT90SC13612RCU Security Target Lite ..................................................... 9
1.1 Identification................................................................................................. 9
1.2 Overview ...................................................................................................... 9
1.3 Common Criteria Conformance Claim ....................................................... 12
1.4 Document Objective .................................................................................. 12
1.5 Document Structure ................................................................................... 12
1.6 Scope and Terminology............................................................................. 13
1.7 References ................................................................................................ 13
1.8 Revision History......................................................................................... 14
Section 2
Target of Evaluation Description................................................................ 15
2.1 Product Type ............................................................................................. 15
2.2 Smartcard Product Life-cycle..................................................................... 22
2.3 TOE Environment ...................................................................................... 25
2.4 TOE Logical Phases .................................................................................. 27
2.5 TOE Intended Usage ................................................................................. 27
2.6 General IT Features of the TOE ................................................................ 29
Section 3
TOE Security Environment ........................................................................ 31
3.1 Assets ........................................................................................................ 31
3.2 Assumptions .............................................................................................. 33
3.3 Threats....................................................................................................... 35
3.4 Organizational Security Policies ................................................................ 40
Section 4
Security Objectives .................................................................................... 43
4.1 Security Objectives for the TOE................................................................. 43
4.2 Security Objectives for the Environment.................................................... 49
(17 Apr 09)
TPG0186A
General Business Use
3 of 86
Security Target Lite
Section 5
TOE Security Functional Requirements .................................................... 51
5.1 TOE Functional Requirements................................................................... 51
5.2 TOE Security Assurance Requirements .................................................... 67
Section 6
TOE Summary Specification...................................................................... 69
6.1 TOE Security Functions ............................................................................. 69
6.2 TOE Assurance Measures......................................................................... 76
Section 7
PP Claims .................................................................................................. 79
7.1 PP Reference............................................................................................. 79
7.2 PP Refinements ......................................................................................... 79
7.3 PP Additions .............................................................................................. 79
4 of 86
Appendix A
Glossary..................................................................................................... 81
Appendix B
AT90SC13612RCU Life Cycle Addresses................................................. 85
General Business Use
(17 Apr 09)
TPG0186A
Figures
(17 Apr 09)
TPG0186A
Figure 2-1
AT90SC13612RCU Block Diagram .................................................................. 16
Figure 2-2
Smartcard Product Life Cycle ........................................................................... 24
Figure 3-1
Assumptions...................................................................................................... 33
Figure 3-2
Standard Threats .............................................................................................. 35
Figure 3-3
Specific Threat .................................................................................................. 35
Figure 3-4
Attack Model for the TOE.................................................................................. 36
Figure 3-5
Organizational Security Policies........................................................................ 40
Figure 4-1
Standard Security Objectives............................................................................ 44
Figure 4-2
Security Objectives Related to Specific Functionality ....................................... 44
Figure 5-1
Standard Security Functional Requirements..................................................... 51
Figure 5-2
Security Functional Requirements related to Specific Functionality ................. 52
General Business Use
5 of 86
Security Target Lite
6 of 86
General Business Use
(17 Apr 09)
TPG0186A
Tables
(17 Apr 09)
TPG0186A
Table 2-1
Classic and XP Write modes....................................................................... 18
Table 2-2
Smartcard Product Life-cycle ...................................................................... 22
Table 2-3
Phases 4 to 7 Product Users ...................................................................... 28
Table 5-1
EAL5 Package and Augmentation .............................................................. 67
Table 6-1
Relationship Between Assurance Requirements and Measures ................ 76
General Business Use
7 of 86
Security Target Lite
8 of 86
General Business Use
(17 Apr 09)
TPG0186A
Section 1
AT90SC13612RCU Security Target Lite
1.1
Identification
1
Title: AT90SC13612RCU Security Target Lite
2
Version: TPG0186A_(17 Apr 09).
3
This Security Target has been constructed with Common Criteria (CC) Version 2.3.
1.2
Overview
Protection Profile Claims
4
This Security Target (ST) is conformant to the Protection Profile BSI-PP-002-2001, with
additions taken from the Smartcard Integrated Circuit Augmentations BSI-AUG-2002:
Document
Title
Date
BSI-PP-002-2001
Smartcard IC Platform Protection Profile V1.0
July 2001
BSI-AUG-2002
Smartcard Integrated Circuit Platform Augmentations
March 2002
Project Derivation
5
(17 Apr 09)
TPG0186A
It is for a microcontroller (MCU) device with security features. The device is a member
of a family of single chip MCU devices which are intended for use within Smartcard
products. The family codename is AT90SC and the ‘parent’ device of the family, the
initial device in the family was the AT90SC19264RC part number , certified under the
French CC scheme, Ref. 2002/04.
General Business Use
9 of 86
Security Target Lite
Project Information:
Identifier
Part Number
AT90SC13612RCU
Product Identification Number
AT58U30
SN_0 = 0x32 *
Revision
C
SN_1 = 0x02 *
Atmel Toolbox Version+
00.03.10.00
0x00031000 *
00.03.13.00
0x00031300 *
+ The AT90SC13612RCU device can be delivered by Atmel with 2 different
toolbox versions.
Note
Toolbox 00.03.10.00 contains the full Atmel Toolbox, with cryptographic
functionality and AIS31 test commands.
The version 00.03.13.00 contains only the AIS31 test commands.
For purposes of this evaluation 00.03.13.00 is considered a subset of the
00.03.10.00 Atmel toolbox. Section 2 of this document gives full details of the
two toolbox versions.
Note
As detailed in [GEN_TD] [TD] the TOE is identified using the Serial Number
Registers SN_0 gives the identification of the Chip ID of the TOE, SN_1 gives
the revision identifier of the TOE.
For the Atmel toolbox the version number is outputed by the TOE when the
TBX self test function is executed [TBX_10] [TBX_13].
Assurance Level
6
10 of 86
The TOE is being evaluated against the CC Smartcard IC Platform Protection Profile
(BSI-PP-002-2001) to Evaluation Assurance Level 5 (EAL5) augmented with
AVA_VLA.4, ALC_DVS.2 and AVA_MSU.3 under the Common Criteria scheme.
General Business Use
(17 Apr 09)
TPG0186A
AT90SC13612RCU Security Target Lite
Sponsor
7
Atmel Smart Card ICs, a division of ATMEL Corporation, is the developer and the
sponsor for the AT90SC evaluations.
Atmel Corporation
3235 Orchard Parkway
San Jose
CA95131
USA
Evaluation Scheme
8
The TOE is evaluated under the French CC Scheme
DCSSI
Bureau Certification
51 boulevard de La Tour-Maubourg
75700 Paris 07 SP
FRANCE
Evaluator
9
The TOE is independently verified by the following Test facility (ITSEF), registered with
the French CC Scheme.
Serma Technologies
30 Avenue Gustave Eiffel
33608 PESSAC Cedex
France
Brief TOE Description
10
The TOE is a member of the AT90SC Enhanced Security family of products certified to
EAL5 using the Common Criteria Methodology, this family of devices is referenced as
AT90SC ASL5.
11
The devices in the AT90SC ASL5 family are based on the AVR RISC family of singlechip microcontroller devices. The AVR RISC family, with designed-in security features,
is based on the industry-standard AVR low-power HCMOS core and gives access to
the powerful instruction set of this widely used device. AT90SC ASL5 devices are
equipped with Flash, RAM, ROM and EEPROM, cryptographic coprocessors, and a
host of security features to protect device assets, making them suitable for a wide range
of smartcard applications.
(17 Apr 09)
TPG0186A
General Business Use
11 of 86
Security Target Lite
1.3
12
This Security Target is conformant to parts 2 and 3 of the Common Criteria, V2.3, as
follows:
„
Part 2 extended: the security functional requirements are based on those
identified in part 2 of the Common Criteria, the additional security functional
requirements are defined in BSI-PP-002-2001 Protection Profile.
„
Part 3 conformant: the security assurance requirements are in the form of an EAL
(assurance package) that is based upon assurance components in part 3 of the
Common Criteria (CC).The augmentations used are also taken from part 3 of the
Common Criteria.
1.4
13
Common Criteria Conformance Claim
Document Objective
The purpose of this document is to satisfy the Common Criteria (CC) requirements for
a Security Target; in particular, to specify the security requirements and functions, and
the assurance requirements and measures, in accordance with Protection Profile BSIPP-002-2001, Smartcard IC Platform Protection Profile, and including augmentations
from, Smartcard Integrated Circuit Platform Augmentations.
1.5
Document Structure
Section 1 introduces the Security Target, and includes sections on terminology,
references and main actors.
Section 2 contains the product description and describes the TOE as an aid to the
understanding of its security requirements and addresses the product type, the
intended usage and the general features of the TOE.
Section 3 describes the TOE security environment.
Section 4 describes the required security objectives.
Section 5 describes the TOE security functional requirements.
Section 6 describes the TOE security functions.
Section 7 describes the Protection Profile (PP) claims..
Appendix A provides a glossary of the terms and abbreviations.
Appendix B Lists the AT90SC13612RCU Life Cycle Addresses
12 of 86
General Business Use
(17 Apr 09)
TPG0186A
AT90SC13612RCU Security Target Lite
1.6
Scope and Terminology
14
Security objectives are defined herein with labels in the form O.xx_xx. These labels are
used elsewhere for reference. Similarly, modes, assets, subjects, threats, assumptions
and organizational security policy are defined with labels of the form M.xx_xx, D.xx_xx,
S.xx_xx, T.xx_xx, A.xx_xx, and P.xx_xx respectively.
15
Hexadecimal numbers are prefixed by 0x, e.g. 0xFF is 255 decimal. Binary numbers
are prefixed by%, e.g.%0001 1011 is decimal 27. An integer value may be expressed
as a hexadecimal, binary or decimal number, whichever form is the most convenient.
1.7
16
References
The AT90SC13612RCU Deliverables List (EDL) identifies the latest revision of the
following documents, the EDL list details all the deliverables sent as evidence as part
of the TOE evaluation.
[ESOF] AT90SC Strength of Security Functions Analysis
[DIGDES] Digital Design Specifications
[STI] Standard Test Interface
[GEN_TD] AT90SC Generic Datasheet (TPR0255)
[TD] AT90SC13612RCU Technical Data (TPR0283)
[TestROMDD] Engineering Software Detailed Description
[TestROMUG] Engineering Software User Guide
[TMRE2] Production Test Software Detailed Description
[TMR-User] Production Test Software User Guide
[PME] Package Mode Test
[TBX_10] Toolbox 3.10.x on AT90SCxxxxC Family with AdvX (TPR0259)
[TBX_13] Using Toolbox Version 00.03.13.x on AT90SCxxxx (TPR0289)
(17 Apr 09)
TPG0186A
General Business Use
13 of 86
Security Target Lite
[APP_AdvX] AdvX for AT90SC Family (TPR0116)
[APP_SCRY_10] Securing Toolbox Operations using version 00.03.10.xx on
ASL5 products (TPR0260)
[APP_SCRY_13] Securing Toolbox Operations using version 00.03.13.xx on
ASL5 products (TPR0290)
[APP_CRYPT] Efficient use of AdvX for Implementing Cryptographic
Operations (TPR0142)
[WSR] Wafer Saw Recommendations (TPG0079)
[DIGDES] AT90SC13612RCU Digital Modules Design
Within this security target the above are referred to with the use of [ ] brackets, for
example [WSR] refers to the document Wafer saw Recommendations, the ST user
should refer to the this document for further information. Some documents listed above
are only available to an ITSEF, the Composite product developer should refer to their
ITSEF for guidance on what they require.
1.8
14 of 86
Revision History
Rev
Date
Description
Originator
A
17 Apr 09
Initial release
John Boggie
General Business Use
(17 Apr 09)
TPG0186A
Section 2
Target of Evaluation Description
17
This part of the Security Target (ST) describes the Target of Evaluation (TOE) as an aid
to the understanding of its security requirements and address the product type, the
intended usage and the general features of the TOE.
2.1
Product Type
18
The TOE is the single chip microcontroller unit to be used in a smartcard product.
Specifically, the TOE is the AT90SC13612RCU device from the AT90SC family of
smartcard devices. Generally, a smartcard product may include other optional elements
(such as specific hardware components, batteries, capacitors, antennae) but these are
not in the scope of this Security Target.
19
The devices in the AT90SC family are based on ATMEL's AVR RISC family of
single-chip microcontroller devices. The AVR RISC family, with designed-in security
features, is based on the industry-standard AVR RISC low-power HCMOS core and
gives access to the powerful instruction set of this widely used device. Different
AT90SC family members offer various options. The AT90SC family of devices are
designed in accordance with the ISO standard for integrated circuit cards (ISO 7816),
where appropriate.
20
The TOE requires engineering embedded software to test the device and demonstrate
certain security characteristics during the development phase. In the end-usage phase
there will be no engineering embedded test software in the TOE. Production test
software will be downloaded into the device EEPROM and be fully erased before
devices leave the test environment. This production test software is only used in the
testing phase of the TOE life cycle and is fully erased before disabling Test Mode,
therefore this test software is outwith the scope of the evaluation. Test Mode disable is
achieved by sawing the wafer.
21
Any faulty devices returned by a customer can be put into package mode. This allows
the test engineer to access the EEPROM to analyse the failure. On entering package
(17 Apr 09)
TPG0186A
General Business Use
15 of 86
Security Target Lite
mode the EEPROM is erased clearing any customer data, Package Mode only allows
a limited set operations and inputs [PME].
Data Bus
8-bit
OTP
Access
Control
EEPROM
User Memory
PC
CRYPTO
ROM
General
Purpose
Registers
Program
Memory
X
RNG
Access
Control
Y
Z
16
8
Instruction
Register
8
CLK
GND
VCC
AdvX
CryptoCoprocessor
RAM
Data Memory
ALU
16
8
Interrupt
Unit
Instruction
Decoder
16
Secure
Control
ISO 7816
Controller
Status
Register
Control
Lines
ISO 7816
I/O Port 0
IN/OUT0
Timer 0
Timer 1
Reset
Circuit
RST
DES
CRC and
Checksum
Accelerator
Code
Signature
Module
Figure 2-1
22
AT90SC13612RCU Block Diagram
Figure 2-1 shows the block diagram of the TOE, listed below is the features of the
device.
General
„
High performance, Low power secureAVRTM Core Enhanced RISC Architecure
„
16 of 86
135 Powerful Instructions (Most executed in a Single Clock Cycle)
„
Low power Idle and Power down Modes
„
Bond Pad Locations Conforming to ISO 7816-2
„
ESD Protection to ±6000V
„
Operating Ranges: from 2.7V to 5.5V
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
Memory
„
104K bytes ROM Program Memory
„
12K bytes EEPROM, Including 128 OTP bytes and 384-byte Bit-addressable
bytes
„
1 to 128-byte Program/Erase
„
1.25ms Program, 1,25ms Erase
„
Endurance: 500,000 Write/Erase Cycles at 25oC
„
10 Years Data Retention
„
4.5K bytes RAM memory
„
32K bytes of the ROM is dedicated to Atmel’s Crypto Library [TBX]
„
Memory Protection Unit / Firewall
Peripherals
„
One I/O Port
„
One ISO 7816 Controller
„
Up to 625 kbps at 5Mhz
„
Compliant with T=0 and T=1 Protocols
„
Programmable Internal Oscillator (Up to 30Mhz for AdvX and 30Mhz for internal
CPU Clock)
„
Two 16-bit Timers
„
Random Number Generator
„
2-level Interrupt Controller
„
Hardware DES and Triple DES (DPA/DEMA Resistant)
„
Checksum Accelerator
„
Code Signature Module
„
CRC16 and 32 Engine (Compliant with ISO/IEC 3309)
„
32-bit Cryptographic Accelerator (AdvX for Public Key Operations)
„
To support SHA, RSA (Only applicable to 00.03.10.00 version of the
Toolbox)
23
The TOE widely uses ATMEL high density non volatile memories.
24
The EEPROM includes a charge pump and its oscillator, security encoding bytes
(scrambling keys, security configuration bytes), but also some chip traceability
information and a transport code.
25
The NVM can be operated in two ways Classic and XP operating mode.
26
Expert (XP) System allows the NVM to be written by page and erase block, full page or
partial page. A smart write feature is also available to avoid non-allowed actions [TD].
(17 Apr 09)
TPG0186A
General Business Use
17 of 86
Security Target Lite
27
Table Table 2-1 gives a summary of the write modes for the two operating modes.
Standard EEPROM
Bit Addressable
Write Modes Classic
Write Modes XP
Page mode with autoerase
Erase + Write
Page mode without autoerase
Write only
Byte mode with autoerase
Full page erase
Byte mode without autoerase
Partial page erase
Erase only
Block erase
Page mode with autoerase
Erase + Write
Page mode without autoerase
Write only
Byte mode with autoerase
Full page erase
Byte mode without autoerase
Partial page erase
Erase only
Block erase
Pseudo bit by page
Bit write
Pseudo bit by byte
Byte Writable OTP
Table 2-1
Note
Pseudo bit by byte
Write only
Classic and XP Write modes
XP and Classic modes deals only with writing to the NVM block, it does not
change the security of the TOE or modify the access control policy. Classic
mode is a historical feature to allow customers to port older Smartcard
Embedded Software to newer AT90SC devices (that is Smartcard Embedded
Software not compatible with the XP write features).
28
The TOE has a 32-bit Cryptographic Accelerator (AdvX) with its 32K-byte Crypto ROM
this can be loaded with either the ATMEL Toolbox library (ATMEL ROM or ATMEL
crypto ROM), or it can be loaded with the Customer Proprietary crypto library.
29
The Atmel Toolbox for the AT90SC13612RCU project is available in two versions,
00.03.10.00 and 00.03.13.00. The 00.03.10.00 is the full version of the Atmel toolbox
library.
00.03.10.00 Atmel Toolbox
30
The Atmel Toolbox [TBX] 00.03.10.00, software library allowing fast cryptographic
algorithm implementations (RSA, SHA-1, Prime Generation,...) on the AdvX. The
cryptographic library is stored in an 32K byte ROM. A crypto library [TBX] with
cryptographic primitives (such as modular exponentiation) is provided by ATMEL.
The full cryptographic functionality is only available when the TOE
includes the 00.03.10.00 version of the Atmel Toolbox.
Note
The version 00.03.13.00 version only contains the AIS31 test functions.
18 of 86
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
31
The Atmel Toolbox contains functions used to test the Random Number Generator. The
test functions contribute to the TOE Security Function SF4 RNG (section 6) and are
therefore within the scope of the evaluation. The test routine and subservices are
detailed in [APP_RNG_ENT].
32
The TOE shall also provide software cryptographic primitives to ease the customer
proprietary software implementation of these algorithms.
00.03.13.00 Atmel Toolbox
33
Toolbox 00.03.13.00, is a subset of the 00.03.10.00 Toolbox. This toolbox only contains
the test routines and subservices associated with TSF SF4 RNG.Therefore Toolbox
00.03.13.00 can be considered as simplified version of 00.03.10.00.
Customer Toolbox
34
The customer may provide a proprietary cryptographic library to be implemented
instead. If the customer wish to supply their own cryptographic library, Atmel give
guidance on how to maintain the security level of the TOE through customer guidance
notes [APP_AdvX] and [APP_CRYPT]. Therefore, part of this ROM memory can be
considered as User ROM memory
35
The TOE includes security logic comprising detectors which monitor voltage,
frequency, temperature and light exposure.
36
The TOE includes a powerful Firewall (Memory protection Unit) that protects all
memories, peripheral and IO register accesses.
37
The TOE also includes dedicated test structures, sawn at dicing, that provide
production test access, compatible with the TOE security requirements. Once test
mode has been disabled by wafer saw the only other way to access the EEPROM test
modes is to enter package mode, this is restricted mode and does not have all the
features of test mode, Package mode is within the scope of the evaluation.
38
Some configuration options can be chosen by the customer at product order.
39
The TOE is manufactured in a low voltage (1.8V +/- 0.3V) CMOS process. The device
will operate at a supply voltage of 2.7V to 5.5V, with the internal supply regulated to the
required operating voltage.
40
The smartcard embedded software delivered by the software developer for the device
comprises CPU ROM, CPU EEPROM and CPU OTP EEPROM. This smartcard
embedded software is outwith the scope of the evaluation.
TOE Interfaces
41
(17 Apr 09)
TPG0186A
The TOE interfaces consist of:
„
The physical surface of the circuit,
„
The ISO7816-3 electrical contacts (VCC, GND, CLK, RST, I/O0),
General Business Use
19 of 86
Security Target Lite
„
The software interface to the hardware component through memories and
registers,
„
The interface between the Software Toolbox (contained in ROM) and the
hardware AdvX
Customer Software Guidance Documents
42
The guidance documents applicable for the development of the smartcard embedded
software for this TOE are:
[TD] AT90SC13612RCU Technical Data (TPR0283)
[GEN_TD] AT90SC Generic Datasheet (TPR0255)
[AM_IS] AT90SC Addressing Modes and Instruction Set (1323)
[APP_SEC] Security Recommendations AT90SC ASL5 Products (TPR0267)
[APP_DES] Secure Hardware DES/TDES on the AT90SC ASL4 Products
(TPR0063) +
[APP_FWL] Using the Supervisor and User Mode in the AT90SC ASL4
Products (TPR0095) +
[APP_RNG_ENT] Generating Random Numbers with a controlled entropy on
AT90SC family (TPR0166)
[TBX_10] Using Toolbox Version 00.03.10.x (TPR0259)
[TBX_13] Using Toolbox Version 00.03.13.x on AT90SCxxxx (TPR0289)
[APP_AdvX] AdvX for AT90SC Family (TPR0116)
[APP_SCRY_10] Securing Toolbox Operations using version 00.03.10.xx on
ASL5 products (TPR0260)
[APP_SCRY_13] Securing Toolbox Operations using version 00.03.13.xx on
ASL5 products (TPR0290)
[APP_CRYPT] Efficient use of AdvX for Implementing Cryptographic
Operations (TPR0142)
[WSR] Wafer Saw Recommendations (TPG0079)
[APP_CSM] The Code Signature Module (TPR0252)
20 of 86
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
[ERR_TBX_13] Toolbox 00.03.13.xx Errata Sheet (TPR0345)
[ERR_TBX_10] Toolbox 00.03.10.xx Errata Sheet (TPR0344)
[APP_CRC] Checksum Accelerator Use on the AT90SC ASL4 Products
(TPR0065)
43
The software developer should refer to the Certification report issued by DCSSI for the
correct revisions of the documents stated above.
+
The guidance documents marked ASL4 are also applicable to the AT90SC
ASL5 family
Note
2.1.1
Scope of Evaluation Summary
Part of the TOE
„
AT90SC13612RCU Hardware device
„
Atmel Security User Guidance as detailed on page 20
„
The TOE interfaces as detailed in Section 41
„
Phases 2-3 of the Life Cycle
„
The Atmel Toolbox 00.03.10.00
„
The Atmel Toolbox 00.03.13.00 (this can be considered a subset of 00.03.10.00)
„
Atmel Toolbox Cryptographic functions (when using version 00.03.10.00 of the
Toolbox)
Outwith the TOE
(17 Apr 09)
TPG0186A
„
Software loaded during Phase 2-3, used to test the TOE
„
Customer Toolbox code
„
Phases 1 and 4-7 of the Life Cycle
General Business Use
21 of 86
Security Target Lite
2.2
44
Smartcard Product Life-cycle
The smartcard product life-cycle consists of 7 phases where the following authorities
are involved
.
Table 2-2
Smartcard Product Life-cycle
Phase 1
Smartcard software
development
The smartcard software developer is in charge of the
smartcard embedded software development and the
specification of IC pre-personalization requirements,
Phase 2
IC Development
The IC designer designs the IC, develops IC dedicated
software, provides information, software or tools to the
smartcard software developer, and receives the software
from the developer, through trusted delivery and
verification procedures. From the IC design, IC dedicated
software and smartcard embedded software, the IC
designer constructs the smartcard IC database,
necessary for the IC photomask fabrication.
Phase 3
IC manufacturing and
testing
The IC manufacturer is responsible for producing the IC
through three main steps:
„
IC manufacturing
„
IC testing
„
IC pre-personalization
Phase 4
IC packaging and
testing
The IC packaging manufacturer is responsible for the IC
packaging and testing.
Phase 5
Smartcard product
finishing process
The smartcard product manufacturer is responsible for the
smartcard product finishing process and testing.
Phase 6
Smartcard
personalization
The personalizer is responsible for the smartcard
personalization and final tests. Other application software
may be loaded onto the chip at the personalization
process.
Phase 7
Smartcard end-usage
The smartcard issuer is responsible for the smartcard
product delivery to the smartcard end-user, and the end of
life process.
Life Cycle Definition
45
22 of 86
The limits of the evaluation correspond to phases 2 and 3, including the phase 1
delivery and verification procedures and the TOE delivery to the IC packaging
manufacturer ; procedures corresponding to phases 4, 5, 6 and 7 are outside the scope
of the Security Target.
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
46
Nevertheless, in certain cases, it would be of great interest to include the phase 4 (IC
packaging and testing), within the limits of the TOE. However, for the time being, this
option remains outside the scope of this Security Target.
47
Figure 2-2 describes the Smartcard product life-cycle. Appendix B contains the
addresses of the relevant organizations.
(17 Apr 09)
TPG0186A
General Business Use
23 of 86
Security Target Lite
Phase 1
Development Phase
IC Personalization requirements
Smartcard Embedded software
Pre-personalization data
and Atmel Toolbox data, or
customer Toolbox where
applicable
Smartcard embedded software (not applicable)
IC sensitive information
software, tools (not
applicable)
Phase 2
Test Libraries, Atmel Crypto
Library
Production Phase
IC Photomask Fabrication
Product Construction
Smartcard IC Database Construction
IC Personalization requirements
IC Dedicated Software
IC Design
Design, Place & Route
Center, Atmel Scotland;
MaskPrep, Atmel France.
Maskshop, Toppan Europe
Phase 3
IC Manufacturing
IC Personalization requirements
IC Testing and Security Encoding
Wafer Fab, Atmel France.
Test Center (Memory test, Wafer
Thinning, Test, Sawing) Atmel
Scotland
Phase 4
IC Packaging
Testing (1)
Phase 5
Testing (1)
Phase 6
Personalization
Product Usage
User Phase
Smartcard Product Finishing Process
Testing (1)
Phase 7
Legend
Limits of the
development cycle
Trusted delivery and
verification procedures
Figure 2-2
24 of 86
Smartcard Product End-Usage (1)
End of Life Process
(1)
Any faulty TOEs would
be returned to the Testing
Centre and placed in
Package Mode to perform
failure analysis.
Smartcard Product Life Cycle
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
Secure Delivery Between Phases
48
These different phases may be performed at different sites; procedures on the delivery
process of the TOE shall exist and be applied for every delivery within a phase or
between phases. This includes any kind of delivery performed from phase 1 to phase
7, including:
„
Intermediate delivery of the TOE or the TOE under construction within a phase
„
Delivery of the TOE or the TOE under construction from one phase to the next
49
These procedures shall be compliant with the assumption [A.Process-Card] developed
in Section 3.2.
50
Although the return of faulty TOEs is applicable to Phases 4-7 therefore outwith the
scope of the evaluation, the fact that Package mode is controlled by hardware means
that Package mode is within the scope of the evaluation.
2.3
51
TOE Environment
Considering the TOE, three types of environments are defined:
„
Development environment corresponding to phase 2
„
Production environment corresponding to phase 3
„
User environment, from phase 4 to phase 7
2.3.1
TOE Development Environment
52
To assure security, the environment in which the development takes place is made
secure with controllable accesses having traceability. Access to the development
building is strictly monitored by a security person. Visitors must sign a log book and
record the time of arrival and time of departure to the building. All visitors are escorted
by authorized personnel at all times. All authorized personnel involved fully understand
the importance and the rigid implementation of the defined security procedures.
53
The development begins with the TOE's specification. All parties in contact with
sensitive information are required to abide by Non-Disclosure Agreements.
54
Design and development of the IC then follows. The design engineer uses appropriate
software tools with the necessary password controls to make his schematic entry/RTL
descriptions, design simulations, verifications and generation of the TOE's IC
photomask databases (design center addresses can be found in Appendix B).
Sensitive documents, databases on tapes, diskettes, and circuit layout information are
stored in appropriate locked cupboards and safes. Disposal of unwanted confidential
data is carried out by shredding (paper documents) or complete electronic erasures
(electronic documents, databases).
(17 Apr 09)
TPG0186A
General Business Use
25 of 86
Security Target Lite
55
Reticles and photomasks are generated from the verified IC database. These are
manufactured by Maskshop (see address in Appendix B), for wafer fab processing
undertaken as per (see address in Appendix B). Data is transferred from the ATMEL
design centre to the photomask manufacturer. The reticles and photomasks are then
shipped in a secure manner to the wafer fab processing facilities.
2.3.2
TOE Production Environment
56
Production starts within the Wafer Fab; here the silicon wafers undergo diffusion
processing in 25-wafer lots. Computer tracking at wafer level throughout the process is
achieved by a based batch tracking system.
57
The tracking system is an on-line manufacturing system which monitors the progress
of the wafers through the fabrication cycle. After fabrication the wafers are tested for
memory wake-up, then, sent to Test Center (see Appendix B) where they are thinned
to a pre-specified thickness and tested. The TOE is then tested to assure conformance
with the device specification. During the IC testing, security encoding is performed
where some of the EEPROM bytes are programmed with the unique traceability
information, and the customer software is loaded in the EEPROM if required.
58
The wafers are inked to separate the functional ICs from the non-functional ICs. Finally,
the wafers are thinned, sawn and then shipped to the customer.
The TOE is thinned to a thickness of 150 µm.
Note
2.3.3
TOE User Environment
59
The TOE user environment is the environment of phases 4 to 7.
60
At phases 4, 5, and 6, the TOE user environment is a controlled environment.
61
Following the sawing step, the wafers are split into individual dies. The good ICs are
assembled into modules in a module assembly plant.
62
Further testing is carried out followed by the shipment of the modules to the smartcard
product manufacturer (embedder) by means of a secure carrier.
63
Additional testing occurs followed by smartcard personalization, retesting and then
delivery to the smartcard issuer.
26 of 86
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
End-user environment (Phase 7)
64
Smartcards are used in a wide range of applications to assure authorized conditional
access. Examples of such are Pay-TV, Banking Cards, Portable communication SIM
cards, Health cards, Transportation cards.
65
Therefore, the user environment covers a wide spectrum of very different functions,
thus making it difficult to avoid or monitor any abuse of the TOE.
2.4
66
During its construction usage, the TOE may be under several life logical phases. These
phases are sorted under a logical controlled sequence. The change from one phase to
the next shall be under the TOE control.
2.5
67
68
TOE Logical Phases
TOE Intended Usage
The TOE can be incorporated in several applications such as:
„
Banking and finance market for credit/debit cards, electronic purse (stored value
cards) and electronic commerce.
„
Network based transaction processing such as mobile phones (GSM SIM cards),
pay-TV (subscriber and pay-per-view cards), communication highways (Internet
access and transaction processing).
„
Transport and ticketing market (access control cards).
„
Governmental cards (ID-cards, healthcards, driver license etc).
„
Multimedia commerce and Intellectual Property Rights protection.
During the phases 1, 2, 3, the product is being developed and produced. The
administrators are the following:
„
The smartcard embedded software developer
„
The smartcard IC designer
The Atmel toolbox [TBX] is developed during Phase 2 of the product life cycle.
„
69
(17 Apr 09)
TPG0186A
The IC manufacturer
Table 2-3 lists the users of the product during phases 4 to 7.
General Business Use
27 of 86
Security Target Lite
Table 2-3
Phase 4
Phase 5
Phase 6
Phase 7
Phases 4 to 7 Product Users
„
Packaging manufacturer (administrator)
„
Smartcard embedded software developer
„
System integrator, such as the terminal software developer
„
Smartcard product manufacturer (administrator)
„
Smartcard embedded software developer
„
System integrator, such as the terminal software developer
„
Personalizer (administrator)
„
Customers who, before manufacture, determine the MCU’s mask
options and the initial memory contents (i.e. the application
program), and who, after manufacture, incorporate the MCU into
devices. Customers are trusted and privileged users.
„
Smartcard issuer (administrator).
„
Smartcard embedded software developer.
„
System integrator, such as the terminal software developer.
„
Smartcard issuer (administrator)
„
Smartcard end-user, who use devices incorporating the MCU.
End-users are not trusted and may attempt to attack the MCU.
„
Smartcard software developer.
„
System integrator, such as the terminal software developer.
Note
70
The IC manufacturer and the smartcard product
manufacturer may also receive ICs for analysis, should
problems occur during the smartcard usage.
The MCU may be used in the following modes:
a) M.TEST_MODE: Test mode, in which the MCU runs under the control of dedicated
test software written to EEPROM via a test interface, and in conjunction with
stimulus provided by an external test system. This mode is intended to be used
solely by authorized development staff.
b) M.USER_MODE: User mode, in which the MCU runs under control of the
smartcard embedded software. It is intended that customers and end-users will
always use the MCU in user mode.
71
28 of 86
During the initial part of the manufacturing process, the MCU is set to M.TEST_MODE
mode. Authorized development staff then test the MCU. After testing, M.TEST_MODE
mode is permanently disabled by sawing, and the MCU is set to M.USER_MODE
mode.
General Business Use
(17 Apr 09)
TPG0186A
Target of Evaluation Description
72
M.PACKAGE_MODE: Package Mode is a mode similar to Test Mode for testing returns
from Phases 4-7. M.PACKAGE_MODE runs a limited subset of test commands via the
ISO pads. This mode is intended to be used solely by authorized Atmel staff. It is not
possible to change any of the security settings in M.PACKAGE_MODE.
73
If a faulty TOE is returned from the field then analysis can be done either in
M.USER_MODE, or M.PACKAGE_MODE by an authorized test engineer.
74
The only modes of operation are those stated in paragraph 70 and 72.
75
Once manufactured, the MCU operates by executing the smartcard embedded
software, which is stored in MCU ROM. The contents of the MCU ROM cannot be
modified, whereas the contents of the EEPROM can, in general, be written to or erased,
under the control of the smartcard embedded software.
76
After an MCU reset, the contents of the RAM are wiped away (except 32 bytes of
protected RAM).
77
The ISO7816 compliant I/O port can be used to pass data to or from the MCU. The
application program determines how to interpret the data.
2.6
78
(17 Apr 09)
TPG0186A
General IT Features of the TOE
The TOE IT functionalities consist of tamper resistant data storage and processing
such as:
„
Arithmetic functions (e.g. incrementing counters in electronic purses, calculating
currency conversion in electronic purses)
„
Data communication
„
Cryptographic operations (e.g. random number generation, data encryption, digital
signature verification)
General Business Use
29 of 86
Security Target Lite
30 of 86
General Business Use
(17 Apr 09)
TPG0186A
Section 3
TOE Security Environment
79
This section describes the security aspects of the environment in which the TOE is
intended to be used, and addresses the description of the assets to be protected, the
assumptions, the threats, and the organizational security policies.
80
The environment elements are derived from BSI-PP-002-2001 and adapted to the
AT90SC13612RCU TOE to cover all the phases of the TOE life cycle, and also the
delivery from one phase to another.
3.1
Assets
3.1.1
81
Assets regarding the Threats
Assets are security relevant elements of the TOE that include the Primary and
Secondary assets.
Primary Assets
„
User application data (D.xxx_DATA) of the TOE comprising the IC prepersonalization requirements, located in:
„
CPU ROM (D.CPU_ROM_DATA),
„
CPU EEPROM (D.CPU_EEPROM_DATA),
„
Crypto ROM (D.CRYPTO_ROM_DATA),
„
CPU RAM (D.CPU_RAM_DATA),
„
CRYPTO RAM (D.CRYPTO_RAM_DATA),
„
Peripherals/IO Registers (D.PERIPH_REG_DATA),
The User data can be subject to manipulation and disclosure while being stored or
processed by the TOE.
„
Smartcard embedded software (D.xxx_SOFT) located in:
„
CPU ROM (D.CPU_ROM_SOFT),
„
CPU EEPROM (D.CPU_EEPROM_SOFT),
„
Crypto ROM (D.CRYPTO_ROM_SOFT)
Smartcard Embedded software needs to be protected to prevent manipulation and
disclosure.
„
(17 Apr 09)
TPG0186A
IC dedicated software (D.xxx_DSOFT) located in:
General Business Use
31 of 86
Security Target Lite
„
„
CPU ROM (D.CPU_ROM_DSOFT),
„
CPU EEPROM (D.CPU_EEPROM_DSOFT),
„
Crypto ROM (D.CRYPTO_ROM_DSOFT)
IC dedicated support software:
„
82
Random numbers generated by the TOE (D.RNG_DATA)
Therefore, the TOE itself is an asset.
Secondary Assets
83
There are many ways to manipulate or disclose the User Data:
1. An attacker may manipulate the smartcard Embedded Software or the TOE
(Primary assets)
2. An attacker may cause malfunctions of the TOE or abuse Test Features provided
by the TOE.
Such attacks usually require design information of the TOE to be obtained. Therefore,
the design information is a secondary asset.
84
„
IC specification (D.IC_SPEC)
„
Design (D.DESIGN)
„
Development tools (D.DEV_TOOLS)
„
Technology (D.TECHNO)
„
Photomasks (D.MASK)
The above secondary assets disclose the following information to an attacker and
therefore need to be protected.
1. The circuitry of the IC (hardware including the physical memories)
2. The IC dedicated Software with the parts IC Dedicated Test software, and IC
dedicated support software
3. The TSF data
85
Assets must be protected in terms of confidentiality and integrity.
Grouping of Assets / Object Definition
86
32 of 86
These assets can be grouped to define objects that must be protected, which is useful
for the following sections of this document.
„
O1: CPU ROM: covering D.CPU_ROM_DATA, D.CPU_ROM_SOFT,
D.CPU_ROM_DSOFT,
„
O2: CPU EEPROM: covering D.CPU_E2PROM_DATA, D.CPU_E2PROM_SOFT,
D.CPU_E2PROM_DSOFT,
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Environment
„
O3: Crypto ROM: covering D.CRYPTO_ROM_DATA, D.CRYPTO_ROM_SOFT,
D.CRYPTO_ROM_DSOFT,
„
O4: CPU RAM: covering D.CPU_RAM_DATA,
„
O5: CRYPTO RAM: covering D.CRYPTO_RAM_DATA,
„
O6: Peripherals and IO Registers: covering D.PERIPH_REG_DATA,
D.RNG_DATA,
87
Illegal address is defined as unmapped regions in the memory map, as listed in [TD]
[GEN_TD].
88
Illegal opcodes are defined as unmapped CPU opcodes, as listed in [AM_IS].
3.2
Assumptions
This Security Target claims conformance to the BSI-PP-002-2001 “Smartcard IC
Platform Protection Profile”, the assumptions defined in section 3.2 of the PP are valid
for this security target and are listed below.
89
Figure 3-1
Assumptions
A.Process-Card
A.Plat-Appl
A.Resp-Appl
Scope of Protection Profile PP-BSI-002
A.Plat-Appl
Outwith the Protection Profile PP-BSI-002
Usage of Hardware Platform
The Smartcard Embedded Software shall be designed
according to the latest TOE user guidance as stated in
Section 42. The Smartcard Embedded Software designer
should also take into account the findings of the TOE
evaluation report.
Applies to Phase 1
(17 Apr 09)
TPG0186A
General Business Use
33 of 86
Security Target Lite
A.Resp-Appl
Treatment of User Data
User data is owned by the Smartcard Embedded Software.
Therefore, is assumed that security relevant User Data for
example Cryptographic keys, are treated by the Smartcard
Embedded Software according to the requirements of the
specific end application.
Applies to Phase 1
A.Process-Card
Protection during Packaging, Finishing and
Personalisation
It is assumed that security procedures are used after
delivery of the TOE by the TOE Manufacturer up to delivery
to the end-user to maintain confidentiality and integrity of the
TOE. These procedures shall prevent any possible copy,
modification, retention, theft or unauthorised use of the TOE
or the system
Applies to Phase 4-6
34 of 86
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Environment
3.3
90
Threats
This Security Target claims conformance to the BSI-PP-002-2001 “Smartcard IC
Platform Protection Profile”, the threats defined in section 3.3 of the PP are valid for this
security target and are listed below.
According to BSI-PP-002-2001, there are the following standard high-level security
concerns
91
SC1
Manipulation of User Data and of the Smartcard Embedded Software
(while being executed/processed and while being stored in the TOE’s
memories)
SC2
Disclosure of User Data and of the Smartcard Embedded Software (while
being processed and while being stored in the TOE’s memories)
SC3
Deficiency of random numbers
The security concerns 1 and 2 give rise to the following threats:
Figure 3-2
Standard Threats
T.Phys-Manipulation
T.Leak-Inherent
T.Phys-Probing
T.Leak-Forced
T.Malfunction
T.Abuse-Func
Outwith the Protection Profile
PP-BSI-002
Scope of Protection Profile PP-BSI-002
92
T.Mem_Access
The security concern 3 gives rise to the following threat:
Figure 3-3
Specific Threat
T.RND
(17 Apr 09)
TPG0186A
General Business Use
35 of 86
Security Target Lite
The TOE is exposed to different types of influences or interactions with it’s outside
world. Some of them may result from just using the TOE, others may also indicate an
attack. The different types of influences or interactions are shown in Figure 3-4.
93
Figure 3-4
Attack Model for the TOE
1
2
Energy and
Particle Exposure
(e.g. temperature)
Electrical
Stimulation
Electrical
Simulation
(glitches etc.)
9
Inspection and
Reverse-engineering
Communication
8
3
7
Electrical
Measurement
and Analysis
(Also for
unbonded pads)
4
Physical
Manipulation
Electro-magnetic
Interaction/radiation
and Analysis
Electrical
Measurement
and Analysis
6
94
36 of 86
5
An interaction with the TOE can be done through the ISO interfaces (number 7-9 in
Figure 3-4) which are realized using contacts. Influences or interactions with the TOE
also occurs through the chip surface (number 1-6 in Figure 3-4). In number 1and 6
galvanic contacts are used. In number 2 and 5 the influence (arrow directed to the chip)
does not require a contact. Number 3 and 4 refer to specific situations where the TOE
and it’s functional behaviour is not only influenced but definite changes are made by
applying mechanical, chemical and other methods (such as 1 and 2). Many attacks
require a prior inspection and some reverse-engineering (number 3).
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Environment
95
The Smartcard Embedded Software must contribute to averting the threats: At least it
must not undermine the security provided by the TOE. For details refer to the
assumptions regarding the Smartcard Embedded Software, specified in Section 3.2.
Standard Threats (referring to SC1 and SC2).
96
The TOE shall avert the threats listed below:
T.Leak-Inherent
Inherent Information Leakage
An attacker may exploit information which is leaked from the
TOE during usage of the smartcard in order to disclose
confidential data (User Data or TSF data).
No direct contact with the smartcard internal is required
here. Leakage may occur through emanations, variations in
power consumption, I/O characteristics, clock frequency, or
by changes in processing time requirements. One example
is the Differential Power Analysis (DPA). This leakage may
be interpreted as a covert channel transmission but is more
closely related to measurement of operating parameters,
which may be derived either from direct (contact)
measurements (numbers 6 and 7 Figure 3-4) or
measurement of emanations (number 5) and can be related
to the specific operation being performed.
(17 Apr 09)
TPG0186A
General Business Use
37 of 86
Security Target Lite
T.Phys-Probing
Physical Probing
An attacker may perform physical probing of the TOE in
order to:
„
Disclose User Data
„
Disclose/reconstruct the Smartcard Embedded
Software
„
Disclose other critical operational information
especially TSF data
Physical probing requires direct interaction with the
Smartcard Integrated Circuit internals (numbers 5 and 6
Figure 3-4). Techniques commonly employed in IC failure
analysis and IC reverse engineering efforts may be used.
Before hardware security mechanisms and layout
characteristics need to be identified (number 3).
Determination of software design including treatment of
User Data may also be a perquisite.
This pertains to “measurements” using galvanic contacts or
any type of charge interaction whereas manipulations are
considered under the threat “Physical Manipulation”
(T.Phys-Manipulation). The threats “inherent Information
Leakage” (T.Leak-Inherent) and “Forced Information
Leakage” (T.Leak-Forced) may use physical probing but
require complex signal processing in addition.
T.Malfunction
Malfunction due to Environmental Stress
An attacker may cause a malfunction of TSF or of the
Smartcard Embedded Software by applying environmental
stress in order to:
„
Deactivate or modify security features or functions of
the TOE
„
Deactivate or modify security functions of the
Smartcard Embedded Software
This may be achieved by operating the smartcard outside
the normal operating conditions (numbers 1, 2 and 9 Figure
3-4).
To exploit this the attacker needs information about the
functional operation.
38 of 86
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Environment
T.Phys-Manipulation
Physical Manipulation
An attacker may physically modify the smartcard in order to:
„
Modify security features or functions of the TOE
„
Modify security functions of the Smartcard Embedded
Software
„
Modify User Data
The modification may result in the deactivation of a security
function. Before that hardware security mechanisms and
layout characteristics need to be identified. Determination of
software design including treatment of User Data may also
be a pre-requisite. Changes of circuitry or data can be
permanent or temporary.
In contrast to malfunctions (refer to T.Malfunction) the
attacker requires to gather significant knowledge about the
TOE’s internal construction here (number 3 Figure 3-4).
T.Leak-Forced
Forced Information Leakage
An attacker may exploit information which is leaked from the
TOE during usage of the product in order to disclose
confidential data (User Data, TSF data) even if the
information leakage is not inherent but caused by the
attacker.
This threat pertains to attacks where methods described in
“Malfunction due to Environmental Stress” (refer to
T.Malfunction) and/or “Physical Manipulation” (refer to
T.Phys-Manipulation) are used to cause leakage from
signals (numbers 5, 6, 7 and 8 Figure 3-4) which normally
do not contain significant information about secrets.
T.Abuse-Function
Abuse of Functionality
An attacker may use functions of the TOE which may not be
used after TOE delivery in order to:
T.Mem-Access
„
Disclose or manipulate User Data
„
Manipulate (explore, bypass, deactivate or change)
security features or functions of the TOE or of the
Smartcard Embedded Software
„
Enable an attack
Memory Access Violation
Parts of the Smartcard Embedded Software may cause
security violations by accidentally or deliberately accessing
restricted data (which may include code). Any restrictions
are defined by the security policy of the specific application
context.
(17 Apr 09)
TPG0186A
General Business Use
39 of 86
Security Target Lite
Threats Related to Specific Functionality (referring to SC3)
97
The TOE shall avert the threat below
T.RND
Deficiency of Random Numbers
An attacker may predict or obtain information about random
numbers generated by the TOE for instance because of a
lack of entropy of the random numbers provided.
An attacker may gather information about the reduced
random numbers which might be a problem because they
may be used for instance to generate cryptographic keys.
Here the attacker is expected to take advantage of statistical
properties of the random numbers generated by the TOE
without specific knowledge about the TOE’s generator.
Malfunctions or premature ageing are also considered
which may assist in getting information about random
numbers.
3.4
Organizational Security Policies
98
This Security Target claims conformance to the BSI-PP-002-2001 “Smartcard IC
Platform Protection Profile”, the Security Policy defined in section 3.2 of the PP is valid
for this security target and is listed below.
99
The TOE may provide specific security functionality which can be used by the
Smartcard Embedded Software. Particular specific security functionality may not
necessarily be derived from threats identified for the TOE's environment because it can
only be decided in the context of the smartcard application, against which threats the
Smartcard Embedded Software will use the specific security functionality. Therefore,
the necessity of some specific functionality may not derived from a threat. The Security
organizational policies are shown in Figure 3-5.
Figure 3-5
Organizational Security Policies
P.Add-Functions
P.Process-TOE
Within scope of PP-BSI-0002
40 of 86
General Business Use
Outwith scope of PP-BSI-0002
(17 Apr 09)
TPG0186A
TOE Security Environment
100
The TOE developer must apply the policy “Protection during TOE Development and
Production” (P.Process-TOE) as specified below.
P.Process-TOE
Protection during TOE Development and Production
The TOE Manufacturer must ensure that the development
and production of the Smartcard Integrated Circuit (Phase 2
up to TOE Delivery, refer to Section 2.2) is secure so that no
information is unintentionally made available for the
operational phase of the TOE. For example, the
confidentiality and integrity of design information and test
data shall be guaranteed; access to samples, development
tools and other material shall be restricted to authorised
persons only; scrap will be destroyed etc. This not only
pertains to the TOE but also to all information and material
exchanged with the developer of the Smartcard Embedded
Software and therefore especially to the Smartcard
Embedded Software itself. This includes the delivery
(exchange) procedures for Phase 1 and the Phases after
TOE Delivery as far as they can be controlled by the TOE
Manufacturer.
101
The IC developer must apply the policy “Additional Specific Security Functionality”
(P.Add-Functions) as specified below.
P.Add-Functions
Additional Specific Security Functionality
The TOE must provide the following specific security
functionality to the Smartcard Embedded Software,
according to accepted international standard:
Note
(17 Apr 09)
TPG0186A
„
Triple Data Encryption Standard (TDES)
„
Secure Hash Algorithm (SHA) *
„
Rivest-Shamir-Adleman (RSA) With CRT *
„
Rivest-Shamir-Adleman (RSA) Without CRT *
* this security functionality is only available to the Smartcard Embedded
Software when the TOE includes Toolbox version 00.03.10.00. Therefore the
version of the TOE with Toolbox 00.03.13.00 has no additional cryptographic
functions, the only cryptographic function available to the user is TDES as this
is a hardware function of the TOE.
General Business Use
41 of 86
Security Target Lite
42 of 86
General Business Use
(17 Apr 09)
TPG0186A
Section 4
Security Objectives
102
The security objectives of the TOE contains the following sections:
„
Security Objectives for the TOE
„
Security Objectives for the Environment
4.1
Security Objectives for the TOE
According to this Security Target, there are the following standard high level security
goals:
SG1
Maintain the integrity of User Data and of the Smartcard Embedded
Software (when being executed/processed and when being stored in the
TOE's memories).
SG2
maintain the confidentiality of User Data and of the Smartcard Embedded
Software (when being processed and when being stored in the TOE's
memories).
103
Though the Smartcard Embedded Software stored in ROM, will in many cases not
contain secret data or algorithms, it must be protected from being disclosed, since for
instance knowledge of specific implementation details may assist an attacker. In many
cases critical User Data will be stored in the EEPROM.
104
These standard high-level security goals are refined below by defining security
objectives as required by the Common Criteria (Figure 4-1). Note that the integrity of
the TOE is a means to reach these objectives.
(17 Apr 09)
TPG0186A
General Business Use
43 of 86
Security Target Lite
Figure 4-1
Standard Security Objectives
O.Phys-Manipulation
O.Leak-Inherent
O.Phys-Probing
O.Leak-Forced
O.Mem-Access
O.Malfunction
O.Abuse-Func
O.Identification
Within scope of PP-BSI-0002
105
106
According to the security this security target there are the following high level security
goals related to specific functionality:
SG3
Provide Random Numbers.
SG4
Provide additional security functionality.
The additional high level security considerations are refined below by defining security
objectives as required by the Common Criteria.
Figure 4-2
Security Objectives Related to Specific Functionality
O.RND
O.Add-Functions
Within scope of PP-BSI-0002
44 of 86
Outwith scope of PP-BSI-0002
General Business Use
Outwith scope of PP-BSI-0002
(17 Apr 09)
TPG0186A
Security Objectives
Standard Security Objectives (referring to SG1 and SG2)
107
The TOE shall provide protection on each of the Standard Security Objectives as listed
below:
O.Leak-Inherent
Protection Against Inherent Information Leakage
The TOE must provide protection against disclosure of
confidential data (User Data or TSF data) stored and/or
processed in the smartcard IC
„
By measurement and analysis of the shape and
amplitude of signals (for example on the power, clock,
or I/O lines) and
„
By measurement and analysis of the time between
events found by measuring signals (for instance on the
power, clock, or I/O lines).
This objective pertains to measurements with subsequent
complex signal processing whereas O.Phys-Probing is
about direct measurements on elements on the chip
surface. Details correspond to an analysis of attack
scenarios which is not given here.
O.Phys-Probing
Protection against Physical Probing
The TOE must provide protection against disclosure of User
Data, against the disclosure/reconstruction of the Smartcard
Embedded Software or against the disclosure of other
critical operational information. This includes protection
against:
„
Measuring through galvanic contacts which is direct
physical probing on the chips surface except on pads
being bonded (using standard tools for measuring
voltage and current)
„
Measuring not using galvanic contacts but other types
of physical interaction between charges (using tools
used in solid-state physics research and IC failure
analysis)
with a prior
„
Reverse-engineering to understand the design and its
properties and functions
The TOE must be designed and fabricated so that it requires
a high combination of complex equipment, knowledge, skill,
and time to be able to derive detailed design information or
other information which could be used to compromise
security through such a physical attack.
(17 Apr 09)
TPG0186A
General Business Use
45 of 86
Security Target Lite
O.Malfunction
Protection against Malfunctions
The TOE must ensure its correct operation.
The TOE must prevent its operation outside the normal
operating conditions where reliability and secure operation
has not been proven or tested. This is to prevent errors. The
environmental conditions may include voltage, clock
frequency, temperature, or external energy fields.
Remark: A malfunction of the TOE may also be caused
using a direct interaction with elements on the chip surface.
This is considered as being a manipulation (refer to the
objective O.Phys-Manipulation) provided that detailed
knowledge about the TOE´s internal construction is required
and the attack is performed in a controlled manner.
O.Phys-Manipulation
Protection against Physical Manipulation
The TOE must provide protection against manipulation of
the TOE (including its software and TSF data), the
Smartcard Embedded Software and the User Data. This
includes protection against:
„
Reverse-engineering (understanding the design and its
properties and functions
„
Manipulation of the hardware and any data
„
controlled manipulation of memory contents (User
Data)
The TOE must be designed and fabricated so that it requires
a high combination of complex equipment, knowledge, skill,
and time to be able to derive detailed design information or
other information which could be used to compromise
security through such a physical attack.
O.Leak-Forced
Protection against Forced Information Leakage
The Smartcard must be protected against disclosure of
confidential data (User Data or TSF data) processed in the
Card (using methods as described under O.Leak?Inherent)
even if the information leakage is not inherent but caused by
the attacker.
„
By forcing a malfunction (refer to "Protection against
Malfunction due to Environmental Stress”
(O.Malfunction)
„
By a physical manipulation (refer to "Protection against
Physical Manipulation” (O.Phys-Manipulation)
If this is not the case, signals which normally do not contain
significant information about secrets could become an
information channel for a leakage attack.
46 of 86
General Business Use
(17 Apr 09)
TPG0186A
Security Objectives
O.Abuse-Func
Protection against Abuse of Functionality
The TOE must prevent that functions of the TOE which may
not be used after TOE Delivery can be abused in order:
„
To disclose critical User Data
„
To manipulate critical User Data of the Smartcard
Embedded Software
„
To manipulate Soft-coded Smartcard Embedded
Software
„
To bypass, deactivate, change or explore security
features or functions of the TOE
Details depend, for instance, on the capabilities of the Test
Features provided by the IC Dedicated Test Software which
are not specified here.
O.Identification
TOE Identification
The TOE must provide means to store Initialisation Data and
Pre-personalisation Data in its non-volatile memory. The
Initialisation Data (or parts of them) are used for TOE
identification.
O.Mem-Access
Area based Memory Access Control
The TOE must provide the Smartcard Embedded Software
with the capability to define restricted access memory
areas. The TOE must then enforce the partitioning of such
memory areas so that access of software to memory areas
is controlled as required, for example, in a multi-application
environment.
(17 Apr 09)
TPG0186A
General Business Use
47 of 86
Security Target Lite
Security Objectives Relating to Specific Functionality (referring to SG3 and SG4)
108
The TOE shall provide protection on each of the Specific Functionality Security
Objectives as listed below:
Random Numbers
O.RND
The TOE will ensure the cryptographic quality of random
number generation. For instance random numbers shall not
be predictable and shall have a sufficient entropy.
The TOE will ensure that no information about the produced
random numbers is available to an attacker since they might
be used for instance to generate cryptographic keys.
O.Add-Function
Additional Specific Security Functionality
The TOE must provide the following specific security
functionality to the Smartcard Embedded Software:
Note
48 of 86
„
Triple Data Encryption Standard (TDES)
„
Secure Hash Algorithm (SHA) *
„
Rivest-Shamir-Adleman (RSA) With CRT *
„
Rivest-Shamir-Adleman (RSA) Without CRT *
* this security functionality is only available to the Smartcard Embedded
Software when the TOE includes Toolbox version 00.03.10.00. Therefore the
version of the TOE with Toolbox 00.03.13.00 has no additional cryptographic
functions, the only cryptographic function available to the user is TDES as this
is a hardware function of the TOE.
General Business Use
(17 Apr 09)
TPG0186A
Security Objectives
4.2
Security Objectives for the Environment
Phase 1
109
The Smartcard Embedded Software shall provide for each of the Security Objectives
for the Environment as stated below.
OE.Plat-Appl
Usage of Hardware Platform
To ensure that the TOE is used in a secure manner the
Smartcard Embedded Software shall be designed so that
the requirements from the following documents are met:
OE.Resp-Appl
„
Hardware data sheet for the TOE
„
TOE application notes
„
Findings of the TOE evaluation reports relevant for the
Smartcard Embedded Software
Treatment of User Data
Security relevant User Data (especially cryptographic keys)
are treated by the Smartcard Embedded Software as
required by the security needs of the specific application
context.
For example the Smartcard Embedded Software will not
disclose security relevant user data to unauthorised users or
processes when communicating with a terminal.
(17 Apr 09)
TPG0186A
General Business Use
49 of 86
Security Target Lite
Phase 2 up to TOE Delivery
110
The TOE manufacturer shall ensure that the Security Objective for the Environment is
complied with as stated below.
OE.Process-TOE
Protection during TOE Development and Production
The TOE Manufacturer must ensure that the development
and production of the Smartcard Integrated Circuit (Phases
2 and 3 up to TOE Delivery, Figure 2-2) is secure so that no
information is unintentionally made available for the
operational phase of the TOE. For example, the
confidentiality and integrity of design information and test
data must be guaranteed, access to samples, development
tools and other material must be restricted to authorised
persons only, scrap must be destroyed. This not only
pertains to the TOE but also to all information and material
exchanged with the developer of the Smartcard Embedded
Software and therefore especially to the Smartcard
Embedded Software itself. This includes the delivery
(exchange) procedures for Phase 1 and the Phases after
TOE Delivery as far as they can be controlled by the TOE
Manufacturer.
An accurate identification must be established for the TOE.
This requires that each instantiation of the TOE carries this
unique identification. In order to make this practical,
electronic identification shall be possible.
For a list of assets refer to Section 3.1.
TOE Delivery up to the end of Phase 6
111
Appropriate protection during packaging finishing and personalisation must be ensured
after TOE Delivery up to the end of Phase 6, as well as during delivery to Phase 7 as
specified below.
OE.Process-Card
Protection during Packaging, Finishing and
Personalisation
Security procedures shall be used after TOE Delivery up to
delivery to the end user to maintain confidentiality and
integrity of the TOE and of its manufacturing and test data
(to prevent any possible copy, modification, retention, theft
or unauthorised use).
This means that Phases after TOE Delivery up to the end of
Phase 6, Figure 2-2, must be protected appropriately. For a
list of assets to be protected refer to Section 3.1.
50 of 86
General Business Use
(17 Apr 09)
TPG0186A
Section 5
TOE Security Functional Requirements
112
The TOE security functional requirements define the functional requirements for the
TOE using functional requirements components drawn from the Common Criteria part
2, and extended functional requirements defined in BSI-PP-002-2001.
113
The minimum strength of function level for the TOE security requirements is SOF-high.
5.1
TOE Functional Requirements
Standard Security Functional Requirements
The Standard TOE Security Functional Requirements as listed within the BSI-PP-0022001 are shown in Figure 5-1
114
Figure 5-1
Standard Security Functional Requirements
Standard SFRs which
- Protect User Data
- Support the Other SFRs
Malfunctions
Limited Fault
Tolerance
(FRU_FLT.2)
Failure with
Preservation of
Secure State
(FPT_FLS.1)
Domain
Separation
(FPT_SEP.1)
Physical Manipulation
and Probing
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)
Standard SFRs which
- Support the TOE’s Life Cycle
- Prevent Abuse of Functions
Abuse of Functionality
Limited
Capabilities
(FMT_LIM.1)
(17 Apr 09)
TPG0186A
Identification
Limited
Availability
(FMT_LIM.2)
General Business Use
Audit Storage
(FAU_SAS.1)
51 of 86
Security Target Lite
The Security Functional Requirements related to specific Functionality are shown in
Figure 5-2. The Security Functional Requirements are split into three:
115
„
the SFRs as stated within the BSI-PP-002-2001 the SFRs as stated within this
Security Target and taken from BSI-AUG-2002
„
the SFR as stated within this Security Target and taken from the CC
Figure 5-2
Security Functional Requirements related to Specific Functionality
SFRs related to Specific Functionality
- Cryptography
Random Numbers
Cryptography
Quality Metric for
Random Numbers
(FCS_RND.1)
Cryptograhic
Operations
(FCS_COP.1)
Within scope of BSI-PP-002-2001
From BSI-AUG-2002
SFRs related to Specific Functionality
- Configuration of Security System
Security Roles
(FMT_SMR.1)
Management of
Security Function
Behaviour
(FMT_MOF.1)
Management of
Security Attributes
(FMT_MSA.1)
Static Attribute
Initialisation
(FMT_MSA.3)
Taken from CC
SFRs related to Specific Functionality
- Memory Access
Complete Access
Control
(FDP_ACC.2)
Security Attribute
Based Access
Control
(FDP_ACF.1)
From BSI-AUG-2002
From BSI-AUG-2002
52 of 86
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
5.1.1
Functional Requirements Relating to Physical Malfunction
Limited Fault Tolerance (FRU_FLT.2)
116
The TOE shall meet the requirement “Limited Fault Tolerance” as specified below:
FRU_FLT.2
Limited fault tolerance
Hierarchical to
FRU_FLT.1
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s
capabilities when the following failure occur: exposure to
operating conditions which are not detected according to
the requirement “Failure with preservation of secure
state” (FPT_FLS.1).
Dependencies
FPT_FLS.1 Failure with preservation of secure state
Refinement
The term “failure” above means “circumstances”. The TOE
prevents failures for “Circumstances” defined above.
Failure with Preservation of Secure State (FPT_FLS.1)
117
The TOE shall meet the requirement “Failure with Preservation of Secure State” as
specified below:
FPT_FLS.1
Failure with preservation of secure state
Hierarchical to
No other components
FPT_FLS.1.1
The TSF shall preserve a secure state when the following
types of failure occur: exposure to operating conditions
which may not be tolerated according to the requirement
“Limited fault tolerance” (FRU_FLT.2) and where
therefore a malfunction could occur.
Dependencies
ADV_SPM.1 Informal TOE security policy model
Refinement
The term “failure” above means “circumstances”. The TOE
prevents failures for “Circumstances” defined above.
TSF Domain Separation (FPT_SEP.1)
118
(17 Apr 09)
TPG0186A
The TOE shall meet the requirement “TSF domain separation” as specified below:
FPT_SEP.1
TSF domain separation
Hierarchical to
No other components
FPT_SEP.1.1
The TSF shall maintain a security domain for its own
execution that protects it from interference and tampering by
untrusted subjects.
General Business Use
53 of 86
Security Target Lite
FPT_SEP.1.2
the TSF shall enforce separation between the security
domains of subjects in the TSC.
Dependencies
No dependencies
Refinement
Those parts of the TOE which support the security functional
requirements "Limited fault tolerance (FRU_FLT.2)" and
"Failure with preservation of secure state (FPT_FLS.1)" shall
be protected from interference of the Smartcard Embedded
Software.
5.1.2
Functional Requirements Relating to Leakage
Basic Internal Transfer Protection (FDP_ITT.1)
119
The TOE shall meet the requirement “Basic internal transfer protection” as specified
below:
FDP_ITT.1
Basic internal transfer protection
Hierarchical to
No other components
FDP_ITT.1.1
The TSF shall enforce the Data Processing Policy to
prevent the disclosure of user data when it is transmitted
between physically-separated parts of the TOE.
Dependencies
FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset
information flow control
Refinement
The different memories, the CPU and other functional units of
the TOE (e.g. a cryptographic co-processor) are seen as
physically-separated parts of the TOE.
Basic Internal TSF data transfer protection (FPT_ITT.1)
120
54 of 86
The TOE shall meet the requirement “Basic internal TSF data transfer protection” as
specified below:
FPT_ITT.1
Basic internal TSF data transfer protection
Hierarchical to
No other components
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
FPT_ITT.1.1
The TSF shall protect TSF data from disclosure when it is
transmitted between separate parts of the TOE.
Dependencies
No dependencies
Refinement
The different memories, the CPU and other functional units of
the TOE (e.g. a cryptographic co-processor) are seen as
separated parts of the TOE.
This requirement is equivalent to FDP_ITT.1 above but refers
to TSF data instead of User Data. Therefore, it should be
understood as to refer to the same Data Processing Policy
defined under FDP_IFC.1.
Subset Information Flow Control (FDP_IFC.1)
121
122
The TOE shall meet the requirement “Subset information flow control” as specified
below:
FDP_IFC.1
Subset information flow control
Hierarchical to
No other components
FDP_IFC.1.1
The TSF shall enforce the Data Processing Policy on all
confidential data when they are processed or transferred
by the TOE or by the Smartcard Embedded Software.
Dependencies
FDP_IFF.1 Simple security attributes
The following Security Functional Policy (SFP) Data Processing Policy is defined for the
requirement “Subset information flow control”:
„
(17 Apr 09)
TPG0186A
User Data and TSF data shall not be accessible from the TOE except when the
Smartcard Embedded Software decides to communicate the User Data via an
external interface. The protection shall be applied to confidential data only but
without the distinction of attributes controlled by the Smartcard Embedded
Software.
General Business Use
55 of 86
Security Target Lite
5.1.3
Functional Requirements Relating to Physical Manipulation and Probing
Resistance to Physical Attack (FPT_PHP.3)
123
The TOE shall meet the requirement “Resistance to physical attack” as specified
below:
FPT_PHP.3
Resistance to physical attack
Hierarchical to
No other components
FPT_PHP.3.1
The TSF shall resist physical manipulation and physical
probing to the TSF by responding automatically such that the
TSP is not violated.
Dependencies
No dependencies
Refinement
The TOE will implement appropriate measures to
continuously counter physical manipulation and physical
probing. Due to the nature of these attacks (especially
manipulation) the TOE can by no means detect attacks on all
of its elements. Therefore, permanent protection against
these attacks is required ensuring that the TSP could not be
violated at any time. Hence, "automatic response" means
here:
5.1.4
„
assuming that there might be an attack at any time
„
and countermeasures are provided at any time.
Functional Requirements Relating to Abuse of Functionality
Limited Capabilities (FMT_LIM.1)
124
56 of 86
The TOE shall meet the requirement “Limited capabilities” as specified below:
FMT_LIM.1
Limited capabilities
Hierarchical to
No other components
FMT_LIM.1.1
The TSF shall be designed in a manner that limits their
capabilities so that in conjunction with "Limited availability
(FMT_LIM.2)" the following policy is enforced: Deploying
Test Features after TOE Delivery does not allow User
Data to be disclosed or manipulated, TSF data to be
disclosed or manipulated, software to be reconstructed
and no substantial information about construction of TSF
to be gathered which may enable other attacks.
Dependencies
FMT_LIM.2 Limited availability
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
Limited Availability (FMT_LIM.2)
125
The TOE shall meet the requirement “Limited availability” as specified below:
FMT_LIM.2
Limited availability
Hierarchical to
No other components
FMT_LIM.2.1
The TSF shall be designed in a manner that limits their
availability so that in conjunction with "Limited capabilities" the
following policy is enforced: Deploying Test Features after
TOE Delivery does not allow User Data to be disclosed or
manipulated, TSF data to be disclosed or manipulated,
software to be reconstructed and no substantial
information about construction of TSF to be gathered
which may enable other attacks.
Dependencies
FMT_LIM.1 Limited capabilities
5.1.5
Functional Requirements Relating to Identification
Audit Storage (FAU_SAS.1)
126
The TOE shall meet the requirement “Audit storage” as specified below:
FAU_SAS.1
Audit storage
Hierarchical to
No other components
FAU_SAS.1.1
The TSF shall provide test personnel before TOE Delivery
with the capability to store the Initialisation Data and/or Prepersonalisation Data and/or supplements of the
Smartcard Embedded Software in the audit records.
Dependencies
No dependencies
5.1.6
Functional Requirements Relating to Cryptography
Quality Metric for Random Numbers (FCS_RND.1)
127
The TOE shall meet the requirement “Quality metric for random numbers” as specified
below:
FCS_RND.1
(17 Apr 09)
TPG0186A
Quality metric for random numbers
General Business Use
57 of 86
Security Target Lite
Hierarchical to
No other components
FCS_RND.1.1
The TSF shall provide a mechanism to generate random
numbers that meet AIS31 class P2 quality metric.
Dependencies
No dependencies
Cryptographic operation (FCS_COP.1) for Toolbox 00.03.10.00 and 00.03.13.00
128
The TOE shall meet the requirement “Cryptographic operation” on cryptographic
operations as specified below:
FCS_COP.1
Cryptographic operation
Hierarchical to
No other components
FCS_COP.1.1
The TSF shall perform hardware TDES encryption and
decryption in accordance with a specified cryptographic
algorithm: triple Data Encryption Standard (TDES) and
cryptographic key sizes: 112-bit cryptographic key sizes
that meet the following E-D-E two-key triple-encryption
implementation of the Data Encryption Standard, FIPS
PUB 46-3, 25th October, 1999.
Dependencies
(FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation)
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
Note
E-D-E =The simplest variant of TDES operates as follows:
DES(k3;DES(k2;DES(k1;M))), where M is the message block to be encrypted
and k1, k2, and k3 are DES keys. This variant is commonly known as EEE
because all three DES operations are encryptions. In order to simplify
interoperability between DES and TDES the middle step is usually replaced
with decryption (EDE mode): DES(k3;DES - 1(k2;DES(k1;M))) and so a
single DES encryption with key k can be represented as TDES-EDE with k1
= k2 = k3 = k. The choice of decryption for the middle step does not affect the
security of the algorithm.
Cryptographic operation (FCS_COP.1) Toolbox 00.03.10.00 only
129
58 of 86
The TOE shall meet the requirement “Cryptographic operation” on cryptographic
operations as specified below:
FCS_COP.1
Cryptographic operation
Hierarchical to
No other components
FCS_COP.1.1
The TSF shall perform software:
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
Dependencies
„
data Hash in accordance with a specified cryptographic
algorithm: SHA-1, and cryptographic key size:with no
cryptographic key size that meet the following Secure
Hash Standard, Federal Information Processing
Standards Publication 180-2, 2002 August 1
„
data Hash in accordance with a specified cryptographic
algorithm: SHA-224, and cryptographic key size:with no
cryptographic key size that meet the following Secure
Hash Standard, Federal Information Processing
Standards Publication 180-2, 2002 August 1
„
data Hash in accordance with a specified cryptographic
algorithm: SHA-256, and cryptographic key size:with no
cryptographic key size that meet the following Secure
Hash Standard, Federal Information Processing
Standards Publication 180-2, 2002 August 1
„
data encryption and decryption in accordance with a
specified cryptographic algorithm: RSA without CRT
data, and cryptographic key size:between 96 bits and
2624 bits that meet the following, PKCS#1 V2.0, 1st
October, 1998.
„
data encryption and decryption in accordance with a
specified cryptographic algorithm: RSA with CRT data,
and cryptographic key size:between 192 bits and 3520
bits that meet the following PKCS#1 V2.0, 1st October,
1998.
(FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation)
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
(17 Apr 09)
TPG0186A
General Business Use
59 of 86
Security Target Lite
5.1.7
Functional Requirements Relating to Configuration of Security System
Security Roles (FMT_SMR.1)
130
The TOE shall meet the requirement “Security roles” as specified below:
FMT_SMR.1
Security roles
Hierarchical to
No other components
FMT_SMR.1.1
The TSF shall maintain the roles:
„
S.TME_ADMIN: Test mode entry (TME) administrator
„
S.P0_SUPER: P0-supervisor
„
S.P1_SUPER: P1-Supervisor
„
S.NON_SUPER: Non-supervisor
„
S.P5_SUPER: P5-supervisor
„
S.P6_SUPER: P6-supervisor
„
S.PME_ADMIN: Package mode entry (PME)
administrator
FMT_SMR.1.2
The TSF shall be able to associate users with roles
Dependencies
FIA_UID.1 Timing of Identification
Management of Security Function Behaviour (FMT_MOF.1)
131
The TOE shall meet the requirement “Management of security function behaviour” as
specified below:
FMT_MOF.1
60 of 86
Management of security function behaviour
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
Hierarchical to
No other components
FMT_MOF.1.1
The TSF shall:
Dependencies
„
restrict the ability to F1 (modify the behaviour of the
function SF1 (Not disclosed in ST-Lite).
„
restrict the ability to F2 (enable the function SF7 (Event
Audit)) (Not disclosed in ST-Lite).
„
restrict the ability to F3 (disable the function SF7 (Event
Audit)) (Not disclosed in ST-Lite).
„
restrict the ability to F4 (modify the behaviour of the
function SF8 (Event Action)) (Not disclosed in STLite).
„
restrict the ability to F5 (modify the behaviour of the
function SF9 (Unobeservability)) (Not disclosed in STLite).
FMT_SMR.1 Security Roles
FMT_SMF.1 Specification of Management Functions
Labels Fx and Ax are tags to aid identification within the rationale.
Note
Management of Security Attributes (FMT_MSA.1)
132
The TOE shall meet the requirement “Management of security attributes” as specified
below:
FMT_MSA.1
Management of security attributes
Hierarchical to
No other components
FMT_MSA.1.1
The TOE security functions shall enforce the ACSF_Policy
(Access Control Security Functions Policy) to restrict the
ability to modify the security attributes A1-A30 to
S.TME_ADMIN, S.P0_SUPER, S.P1_SUPER,
S.P5_SUPER, S.P6_SUPER
Dependencies
FDP_ACC.1 Subset access control or FDP_IFC.1 subset
information flow control
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
(17 Apr 09)
TPG0186A
General Business Use
61 of 86
Security Target Lite
Static Attribute Initialisation (FMT_MSA.3)
133
The TOE shall meet the requirement “Static attribute initialisation” as specified below:
FMT_MSA.3
Static attribute initialisation
Hierarchical to
No other components
FMT_MSA.3.1
The TOE security functions shall enforce the ACSF_Policy to
provide restrictive default values for security attributes that
are used to enforce the security functions policy.
FMT_MSA.3.2
The TSF shall allow the S.TME_ADMIN to specify alternate
initial values to override the default values when an object or
information is created.
Dependencies
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
5.1.8
Functional Requirements Relating to Memory Access
Complete Access Control (FDP_ACC.2)
134
The TOE shall meet the requirement “Complete access control” as specified below:
FDP_ACC.2
Complete access control
Hierarchical to
FDP_ACC.1 Subset access control
FDP_ACC.2.1
The TOE security functions shall enforce the Access Control
SFP on:
„
Subjects: S.TME_ADMIN, S.P0_SUPER,
S.P1_SUPER, S.P5_SUPER, S.P6_SUPER,
S.PME_ADMIN, S.NON_SUPER
„
Objects: (O1) CPU ROM, (O2) EEPROM, (O3) Crypto
ROM, (O4) CPU RAM, (O5) Crypto RAM, (O6)
peripheral and IO registers
and all operations among subjects and objects covered by the
SFP
62 of 86
FDP_ACC.2.2
The TOE security function shall ensure that all operations
between any subject in the TOE scope of control and any
object within the TOE scope of control are covered by an
access control SFP.
Dependencies
FDP_AFC.1 Security attribute based access control
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
Security attribute based access control (FDP_ACF.1)
135
The TOE shall meet the requirement “Security attribute based access control” as
specified below:
FDP_ACF.1
Security attribute based access control
Hierarchical to
No other components
FDP_ACF.1.1
The TOE security functions shall enforce the ACSF_Policy to
objects based on the following:
„
Subjects: S.TME_ADMIN,S.P0_SUPER, S.P1_SUPER,
S.P5_SUPER, S.P6_SUPER, S.PME_ADMIN,
S.NON_SUPER
„
Objects: (O1) CPU ROM, (O2) EEPROM, (O3) Crypto
ROM, (O4) CPU RAM, (O5) Crypto RAM, (O6)
peripheral and IO registers
„
Operations: Read, Write, Execute
„
Conditions: the Firewall configuration
For full list see note
FDP_ACF.1.2
The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed see (Not disclosed in ST-Lite)
FDP_ACF.1.3
The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: None
FDP_ACF.1.4
The TSF shall explicitly deny access of subjects to objects
based on the following additional rules see (Not disclosed
in ST-Lite)
Dependencies
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
(17 Apr 09)
TPG0186A
General Business Use
63 of 86
Security Target Lite
Note
64 of 86
„
A1: Read P0 CPU ROM (O1) access right
„
A2: Write P0 CPU ROM (O1) access right
„
A3: Execute P0 CPU ROM (O1) access right
„
A4: Read P1 EEPROM (O2) access right
„
A5: Write P1 EEPROM (O2) access right
„
A6: Execute P1 EEPROM (O2) access right
„
A7: Read P2 EEPROM (O2) access right
„
A8: Write P2 EEPROM (O2) access right
„
A9: Execute P2 EEPROM (O2) access right
„
A10: Read P3 EEPROM (O2) access right
„
A11: Write P3 EEPROM (O2) access right
„
A12: Execute P3 EEPROM (O2) access right
„
A13: Read P5 Crypto ROM (O3) access right
„
A14: Write P5 Crypto ROM (O3) access right
„
A15: Execute P5 Crypto ROM (O3) access right
„
A16: Read P6 Crypto ROM (O3) access right
„
A17: Write P6 Crypto ROM (O3) access right
„
A18: Execute P6 Crypto ROM (O3) access right
„
A19: Read CPU EEPROM (O2) access right
„
A20: Write CPU EEPROM (O2) access right
„
A21: Execute CPU EEPROM (O2) access right
„
A22: Read CPU RAM (O4) access right
„
A23: Write CPU RAM (O4) access right
„
A24: Execute CPU RAM (O4) access right
„
A25: Read Crypto RAM (O5) access right
„
A26: Write Crypto RAM (O5) access right
„
A27: Execute Crypto RAM (O5) access right
„
A28: Read peripheral and IO registers (O6) access right
„
A29: Write peripheral and IO registers (O6) access right
„
A30: Execute peripheral and IO registers (O6) access right
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
5.1.9
136
Security Requirements for the IT-Environment
The security functional requirement ”Cryptographic operation (FCS_COP.1)” met by
the TOE has the following dependencies:
„
[FDP_ITC.1 import of user data without security attributes or FCS_CKM.1
Cryptographic key generation]
„
FCS_CKM.4 Cryptographic key destruction
„
FMT_MSA.2 Secure security attributes
137
These requirement address the appropriate management of cryptographic keys used
by the specified cryptographic function. All requirements concerning key management
shall be fulfilled by the environment since the Smartcard Embedded Software is
designed for a specific application context and uses the cryptographic functions
provided by the TOE.
138
The environment shall meet the requirements:
„
FDP_ITC.1 or FCS_CKM.1
„
FCS_CKM.4
„
FMT_MSA.2
5.1.10
139
Security Requirements for the NON-IT-Environment
In the following, security requirements for the Non-IT-Environment are defined. For the
development of the Smartcard Embedded Software (in Phase 1) the requirement
“Design and implementation of the Smartcard Embedded Software (RE.Phase-1)” is
valid.
RE.Phase-1
Design and Implementation of the Smartcard Embedded Software
The developers shall design and implement the Smartcard Embedded
Software in such a way that it meets the requirements from the
following documents (i) hardware data sheet for the TOE, (ii) TOE
application notes, and (iii) findings of the TOE evaluation reports
relevant for the Smartcard Embedded Software.
The developers shall implement the Smartcard Embedded Software in
a way that it protects security relevant User Data (especially
cryptographic keys) as required by the security needs of the specific
application context.
(17 Apr 09)
TPG0186A
General Business Use
65 of 86
Security Target Lite
140
The Smartcard Embedded Software shall meet the requirement “Cipher Schemas
(RE.Cipher)” as specified below.
RE.Cipher
Cipher Schemas
The developers of Smartcard Embedded Software must not
implement routines in a way which may compromise keys when the
routines are executed as part of the Smartcard Embedded Software.
Performing functions which access cryptographic keys could allow an
attacker to misuse these functions to gather information about the key
which is used in the computation of the function.
Keys must be kept confidential as soon as they are generated. The
keys must be unique with a very high probability, as well as
cryptographically strong. For example, it must be ensured that it is not
possible to derive the private key from a public key if asymmetric
algorithms are used. This implies that an appropriate key management
has to be realized in the environment.
141
The responsible parties for Phases 4-6 are required to support the security of the TOE
by appropriate measures.
RE.Process
-Card
Protection during Packaging, Finishing and Personalisation
The card manufacturer (after TOE delivery up to the end of Phase 6)
shall use adequate security measures to maintain confidentiality and
integrity of the TOE and of its manufacturing and test data (to prevent
any possible copy, modification, retention, theft or unauthorised use.)
66 of 86
General Business Use
(17 Apr 09)
TPG0186A
TOE Security Functional Requirements
5.2
TOE Security Assurance Requirements
142
The assurance requirement is EAL5 augmented of additional assurance components
listed in Table 5-1.
143
Some of the augmentation components are hierarchical ones to the components
specified in EAL5.
144
All the components are drawn from Common Criteria Part 3.
Table 5-1
(17 Apr 09)
TPG0186A
EAL5 Package and Augmentation
Assurance Class
EAL5 Package
AT90SC13612RCU
EAL5+ Package
Augmented From
EAL5
ACM_AUT
1
1
No
ACM_CAP
4
4
No
ACM_SCP
3
3
No
ADO_DEL
2
2
No
ADO_IGS
1
1
No
ADV_FSP
3
3
No
ADV_HLD
3
3
No
ADV_IMP
2
2
No
ADV_INT
1
1
No
ADV_LLD
1
1
No
ADV_RCR
2
2
No
ADV_SPM
3
3
No
AGD_ADM
1
1
No
AGD_USR
1
1
No
ALC_DVS
1
2
Yes
ALC_FLR
N/A
N/A
No
ALC_LCD
2
2
No
ALC_TAT
2
2
No
ATE_COV
2
2
No
ATE_DPT
2
2
No
ATE_FUN
1
1
No
ATE_IND
2
2
No
AVA_CCA
1
1
No
AVA_MSU
2
3
Yes
AVA_SOF
1
1
No
AVA_VLA
3
4
Yes
General Business Use
67 of 86
Security Target Lite
145
68 of 86
The refinements to the assurance requirements as stated within the Protection Profile
BSI-PP002-2001 have been taken into account.
General Business Use
(17 Apr 09)
TPG0186A
Section 6
TOE Summary Specification
146
This section defines the TOE security functions that implement the security functional
requirements defined in Section 5.1, and the TOE assurance measures that implement
the security assurance requirements defined in Section 5.2.
6.1
6.1.1
TOE Security Functions
Test Mode Entry (SF1)
147
SF1 shall ensure that only authorized users will be permitted to enter Test Mode. This
is provided by M1.1 Test Mode Entry conditions that are required to enable the TOE to
enter Test Mode.
148
All test entry requirements occur while the TOE is held in reset and failure in any one
will prevent Test Mode Entry. It is required that the TOE satisfies the test entry
conditions during any internal reset condition.
149
It is not possible to move from User Mode to Test Mode. Any attempt to do this, for
example, by forcing internal nodes will be detected and the security functions will
disable the ability to enter Test Mode.
150
The Strength of Function claimed for the Test Mode Entry security function is high.
(17 Apr 09)
TPG0186A
General Business Use
69 of 86
Security Target Lite
6.1.2
Protected Test Memory Access (SF2)
151
SF2 shall ensure that, although authenticated users can have access to memories
using commands in test mode, they cannot access directly their contents.
152
Authorized Test Mode users also have access to other address regions which are not
accessible in user mode.
153
The Strength of Function claimed for the Protected Test Memory Access security
function is high.
6.1.3
154
Test Mode Disable (SF3)
SF3 shall make provision for:
„
M3.1 Wafer sawing which, once done, shall ensure that none of the test features
are available, not even to authenticated users in test mode. Although Package
Mode Entry (PME) is available.
6.1.4
RNG (SF4)
155
M4.1 the TSF shall provide a hardware Random Number Generator (RNG) to support
security operations performed by cryptographic applications. This RNG noise source
shall not be predictable, have sufficient entropy, and not leaking information related to
the value of the generated random numbers as this leakage could be used to retrieve
cryptographic keys for instance. The RNG noise source as a sufficient entropy to
comply with the AIS31 standard. The RNG has a Digitized Analogue Source (DAS) bit
that enables the smartcard embedded software to check that the RNG noise source
maintains a sufficient entropy throughout the life of the TOE, this confirms to the AIS31
class P2 standard.
156
The Atmel Toolbox allows the testing of the hardware RNG, to allow the testing the
Atmel Toolbox provides a routine and several subservices.
„
Main Toolbox test routine
„
Test a buffer against total failure of the hardware RNG
„
Perform a test of above buffer
157
Subservice total failure can be considered as a TOT-test. Test of buffer can be
considered as a Online-test. Full details of how to use the functions listed to provide
AIS31 complaint random data is given in guidance document [APP_RNG_ENT].
158
The Strength of Function claimed for the RNG security function is high.
6.1.5
159
70 of 86
Data Error Detection (SF5)
SF5 shall provide means for performing data error detection.
General Business Use
(17 Apr 09)
TPG0186A
TOE Summary Specification
160
Means of performing checksum error detection and parity error detection is provided
the following mechanisms:
„
M5.1 16/32-bit Checksum Accelerator
„
M5.2 CRC-16/32 hardware peripheral
„
M5.3 Cstack Checker.
„
M5.4 parity checking CPU core registers
„
M5.5 parity checking CPU RAM
„
M5.6 parity checking Crypto RAM
„
M5.8 parity checking ROM
„
M5.9 Enhanced Protection Object (EPO)
6.1.6
161
FireWall (SF6)
SF6 shall enforce access control based on the FireWall rules as defined in the
ACSF_Policy (Not disclosed in ST-Lite).
M6.1 Memory protection
162
The FireWall defines user modes to execute embedded software, if an illegal area is
accessed by the user mode a security interrupt is invoked.
M6.2 Illegal address
163
If an illegal address is accessed, a security interrupt is invoked.
M6.3 Illegal opcode
164
If an attempt is made to execute any opcode that is not implemented in the instruction
set, a security non maskable interrupt is invoked.
6.1.7
Event Audit (SF7)
165
The TOE shall provide an Event Audit security function (SF7) to enforce the following
rules for monitoring audited events.
166
Accumulation or combination of the following auditable events would indicate a
potential security violation.
(17 Apr 09)
TPG0186A
„
M7.1 The external voltage supply goes outside acceptable bounds
„
M7.2 The external clock signal goes outside acceptable bounds
„
M7.3 The ambient temperature goes outside acceptable bounds
„
M7.4 Application program abnormal runaway
„
M7.5 Attempts to physically probe the device
„
M7.6 Attempts to gain illegal access to reserved RAM memory locations
General Business Use
71 of 86
Security Target Lite
167
„
M7.7 Attempts to gain illegal access to reserved EEPROM (O2) memory
locations: audited by SVR0.EEVI (IO register bit).
„
M7.8 Attempts to gain illegal access to reserved peripheral, IO and AdvX register
locations
„
M7.9 Attempts to execute illegal instruction “LPM” to read the program memory
from the S.NON_SUPER program location
„
M7.10 Attempts to move the RAM stack to an illegal RAM memory location
defined by SPHLC and SPLLC registers
„
M7.11 Attempts to move the RAM Cstack to an illegal RAM memory location
defined by CSTACKH CSTACKL
„
M7.12 Attempts to execute an CPU opcode that is not implemented
„
M7.13 Attempts to illegally write access the device’s EEPROM (O2)
„
M7.14 Attempts to gain illegal access to supervisor modes
„
M7.15 Exposure to UV light goes outside acceptable bounds
„
M7.16 Attempts to scan the TOE with a focused light beam
„
M7.17 Attempts to modify the AVRcore register file
„
M7.18 Attempts to modify the CPU RAM contents
„
M7.19 Attempts to modify the Crypto RAM contents
„
M7.21 Attempts to modify the ROM memories
„
M7.22 Attempts to modify the NVM memories
„
M7.24 A violation encountered by the Code Signature Module
„
M7.25 A register mirroring violation
The Strength of Function claimed for the Event audit security function is high.
6.1.8
Event Action (SF8)
168
SF8 shall provide an Event Action security function to register occurrences of audited
events and take appropriate action. Detection of such occurrences will cause an
information flag to be set, and may cause one of the following to occur if warranted by
the violation: (Not disclosed in ST-Lite)
169
Event Action depends on the type of Event (see [TD] for more information).
6.1.9
170
72 of 86
Unobservability (SF9)
SF9 shall ensure that users/third parties will have difficulty observing the following
operations on the TOE by the described means.
„
Monitoring power consumption
„
Carrying out timing analysis on cryptographic functions
„
Using optical, mechanical or electrical means
General Business Use
(17 Apr 09)
TPG0186A
TOE Summary Specification
171
The Strength of Function claimed for the Unobservability security function is high.
6.1.10
172
Cryptography (SF10)
The TSF shall provide a cryptographic algorithm to be able to transmit and receive
objects in a manner protected from data retrieval or modification.
Note
The software mechanisms M10.2, M10.3, M10.4, M10.5 are only available
when using Toolbox version 00.03.10.00. Therefore the version of the TOE
with Toolbox 00.03.13.00 has no additional cryptographic functions, the only
cryptographic function available to the user is TDES as this is a hardware
function.
173
M10.1 the TSF shall provide hardware TDES data encryption/decryption capability.
174
M10.2 the TSF shall provide software secure Hash, SHA-1, 224, 256, data signing
capability
175
M10.3 the TSF shall provide software RSA without CRT (i.e. modular exponentation)
data encryption decryption function.
176
177
178
„
Secure encryption
„
Fast encryption (see note*)
M10.4 the TSF shall provide software RSA with CRTdata encryption decryption
function.
„
Secure encryption
„
Fast encryption (see note*)
M10.5 the TSF shall provide software RSA cryptographic key generation capability
using Miller Rabin algorithm with confidence criteria (t parameter) between 0 and 255
„
Secure generation
„
Fast generation (see note*)
These may be used by the smartcard embedded software to support data encryption
and decryption for maintaining data integrity, and protect against sensitive data
unauthorized disclosure.
* The Fast functions of M10.3, M10.4, M10.5 do not offer any DPA/SPA
protection and must not be used for secure data.
Note
179
(17 Apr 09)
TPG0186A
The Strength of Function claimed for the cryptography security function is high.
General Business Use
73 of 86
Security Target Lite
180
181
An assessment of the strength of the following algorithms does not form part of the
evaluation:
„
TDES algorithm
„
RSA without CRT algorithm
„
RSA with CRT algorithm
The following functions use probabilistic or permutational effects and have a strength
of function claim of high.
„
SHA algorithm
„
Miller Rabin algorithm
6.1.11
Package Mode Entry (SF11)
182
SF11 shall ensure only authorized users will be permitted to enter Package Mode. This
is provided by the M1.1 Test Mode Entry conditions, and also the M11.1 Package Mode
Entry conditions. Both M1.1 and M11.1 conditions must be met to enter Package Mode.
183
To enter Package mode the conditions must be met in SF1 (M1.1) first, then whilst the
TOE is still held in reset the PME conditions (M11.1) must be met. Failure to meet these
conditions will prevent entry into Package Mode.
184
The Strength of Function for the Package Mode Entry function is high.
6.1.12
Test Memory Access in Package Mode (SF12)
185
SF12 shall ensure that, although authenticated users can have access to memories
using commands in package mode, they cannot access directly their contents.
186
When package mode is entered a full EEPROM (O2) erase is performed. Access to the
device memories are limited by test algorithms.
187
74 of 86
„
M12.1 the EEPROM (O2) tests are read/write functions controlled via a test
interface.
„
M12.2 CPU ROM (O1) data no access.
„
M12.3 Crypto ROM (O3) data no access.
„
M12.4 CPU RAM no write access.
„
M12.5 Crypto RAM no write access
The Strength of Function claimed for the Protected Test Memory Access in Package
Mode is high.
General Business Use
(17 Apr 09)
TPG0186A
TOE Summary Specification
6.1.13
Security Functions Based on Permutations/combinations
188
Security function SF1 and SF11 are based on mechanisms using permutation and/or
combination properties.
189
Therefore, the resistance of SF1 and SF11 should be evaluated against attacks using
brute force techniques.
190
Parts of SF10 use problematic or permutational effects and is included in the Strength
of function analysis [ESOF].
191
Further details on these mechanisms and on the Strength of Function Analysis
performed by ATMEL can be found in [ESOF].
(17 Apr 09)
TPG0186A
General Business Use
75 of 86
Security Target Lite
6.2
Table 6-1 specifies how they satisfy the TOE security assurance requirements.
Sub-contractor Site
SA13
Smartcard Devices
SA9
Manufacturing Site
Vulnerability assessment
SA8
SA12
Test Activity
SA7
Test Site
Life Cycle Support
SA6
SA11
Guidance
SA5
Development Site
Development Activity
SA4
ACM_AUT.1
x
x
x
x
x
ACM_CAP.4
x
x
x
x
x
ACM_SCP.3
x
x
x
x
x
ASE_xxx
SA1
SA10
Delivery and Operation
SA3
Assurance
Requirement
Configuration Management
Relationship Between Assurance Requirements and Measures
Security Target
Table 6-1
SA2
192
TOE Assurance Measures
x
ADO_DEL.2
x
x
x
x
x
ADO_IGS.1
x
x
x
x
x
ADV_FSP.3
x
ADV_HLD.3
x
ADV_IMP.2
ADV_INT.1
x
x
ADV_LLD.1
x
ADV_RCR.2
x
ADV_SPM.3
x
AGD_ADM.1
x
AGD_USR.1
x
ALC_DVS.2
x
x
x
x
x
ALC_LCD.2
x
x
x
x
x
ALC_TAT.2
x
x
x
x
x
ATE_COV.2
x
x
x
ATE_DPT.2
x
x
x
ATE_FUN.1
x
x
x
ATE_IND.2
x
x
x
AVA_CCA.1
x
x
AVA_MSU.3
x
x
AVA_SOF.1
x
x
AVA_VLA.4
x
x
Security Target (SA1)
193
76 of 86
SA1 shall provide the “TOE Security Target” document plus its references.
General Business Use
(17 Apr 09)
TPG0186A
TOE Summary Specification
Configuration Management (SA2)
194
SA2 shall provide the “CC Configuration Management (ACM)” interface document plus
its references.
Delivery and Operation (SA3)
195
SA3 shall provide the “CC Delivery and Operation (ADO)” interface document plus its
references.
Development Activity (SA4)
196
SA4 shall provide the “CC Development Activity (ADV)” interface document plus its
references.
Guidance (SA5)
197
SA5 shall provide the “CC Guidance (AGD)” interface document plus its references.
Life Cycle Support (SA6)
198
SA6 shall provide the “CC Life Cycle Support (ALC)” interface document plus its
references.
Test Activity (SA7)
199
SA7 shall provide the “CC Test Activity (ATE)” interface document plus its references,
and undertaking of testing described therein.
Vulnerability Assessment (SA8)
200
SA8 shall provide the “CC Vulnerability Assessment (AVA)” interface document plus its
references, and undertaking of vulnerability assessment described therein.
Smart Card Devices (SA9)
201
SA9 shall provide functional AT90SC13612RCU smart card devices.
Development Site (SA10)
202
SA10 shall provide access to the development site.
Test Site (SA11)
203
SA11 shall provide access to the test site.
Manufacturing Site (SA12)
204
(17 Apr 09)
TPG0186A
SA12 shall provide access to the manufacturing site.
General Business Use
77 of 86
Security Target Lite
Sub-contractor Sites (SA13)
205
78 of 86
SA13 shall provide access to the sub-contractor sites.
General Business Use
(17 Apr 09)
TPG0186A
Section 7
PP Claims
7.1
206
PP Reference
This Security Target is conformant to the Protection Profile “Smartcard IC Platform
Protection Profile” V1.0 July 2001,and has been registered under the German
Certification Scheme (BSI) under the reference BSI-PP-002-2001.
7.2
207
PP Refinements
For clarification of this Security Target, modes, assets, subjects, threats, assumptions
and organizational security policy are defined with labels of the form M.xx_xx, D.xx_xx,
S.xx_xx, T.xx_xx, A.xx_xx, and P.xx_xx respectively.
7.3
208
PP Additions
The PP additions fall into the following categories, the additions:
„
from the “Smartcard Integrated Circuit Augmentations” registered under the
German Certification Scheme (BSI) under the reference BSI-AUG-2002
„
taken directly from Common Criteria V2.3
„
assumption and security objective for environment, defined in Section 3.2 of this
Security Target
7.3.1
209
Additions include Assumptions, Threats, Organisational security Policies, Security
Objectives and Security Functional Requirements.
7.3.1.1
210
(17 Apr 09)
TPG0186A
Additions from BSI-AUG-2002
Assumptions
None
General Business Use
79 of 86
Security Target Lite
7.3.1.2
211
This security target specifies the additional threat, T.Mem-Access this relates to the
threat that the Smartcard Embedded Software may cause security violations by
accessing restricted data.
7.3.1.3
212
Threats
Organizational Security Policies
This security target specifies the additional organizational security policies, P.AddFunctions this policy relates to the cryptographic functions provided by the TOE.
7.3.1.4
Security Objectives
213
This security target specifies the additional security objective, O.Add-Functions this
objective relates to the cryptographic functions provided by the TOE.
214
This security target specifies the additional security objective, O.Mem-Access this
objective relates to area based memory access control provided by the TOE.
7.3.1.5
215
This security target specifies the additional security functional requirements:
„
FCS_COP.1 relating to the cryptographic functions provided by the TOE
„
FMT_MSA.1 relating to the configuration of security functions
„
FMT_MSA.3 relating to the configuration of security functions
„
FDP_ACC.2 relating to the memory access controls provided by the TOE
„
FDP_ACF.1 relating to the memory access controls provided by the TOE
7.3.2
7.3.2.1
216
80 of 86
Security Functional Requirements
Additions from the Common Criteria
Security Functional Requirements
This security target specifies the additional security functional requirements:
„
FMT_SMR.1 relating to the configuration of security functions
„
FMT_MOF.1 relating to the configuration of security functions
General Business Use
(17 Apr 09)
TPG0186A
Appendix A
Glossary
A.1
Terms
BIST
Built In Self Test. Hardware implementation of an
algorithm which tests for stuck at, transition, coupling
and address faults in a memory
Control Bytes
Reserved bytes of EEPROM which can be
programmed with traceability information.
CRC-32
Algorithm used to compute powerful checksum on
memory blocks
HASH
Transformation of a string of characters into a usually
shorter fixed length value or key that represents the
original string.
IC Dedicated Software
IC Proprietary software which is required for testing
purposes and to implement special functions. For
AT90SC13612RCU this includes the embedded test
software and additional test programmes which are
run from outside of the IC.
The Crypto libraries also form part of the IC dedicated
software.
(17 Apr 09)
TPG0186A
IC Designer
Institution (or its agent) responsible for the IC
Development. Atmel is the institution in respect of the
TOE.
IC Manufacturer
Institution (or its agent) responsible for the IC
manufacturing, testing and pre-personalization. Atmel
is the institution in respect of the TOE.
IC Packaging
Manufacturer
Institution (or its agent) responsible for the IC
packaging and testing.
IC Pre-personalization
Data
Required information to enable the smartcard IC to be
configured by means of ROM options and to enable
programming of the EEPROM with customer specified
data.
General Business Use
81 of 86
Security Target Lite
82 of 86
Integrated Circuit (IC)
Electronic component(s) designed to perform
processing and/or memory functions.
MARCH C
Algorithm which tests for stuck at, transition, coupling
and address faults in a memory.
MARCH LR
Algorithm which tests for stuck at, transition, coupling
and address faults in a memory.
MARCH Y
Algorithm which tests for stuck at, transition, coupling
and address faults in a memory.
Personalizer
Institution (or its agent) responsible for the smartcard
personalization and final testing.
Smartcard
A credit sized plastic card which has a non volatile
memory and a processing unit embedded within it.
Smartcard Embedded
Software
Software embedded in the smartcard application
(smartcard application software). This software is
provided by smartcard embedded software developer
(customer). Embedded software may be in any part of
User ROM or EEPROM.
Smartcard Embedded
Software Developer
Institution (or its agent) responsible for the smartcard
embedded software development and the
specification of pre-personalization requirements.
Smartcard Issuer
Institution (or its agent) responsible for the smartcard
product delivery to the smartcard end-user.
Smartcard Product
Manufacturer
Institution (or its agent) responsible for the smartcard
product finishing process and testing.
UNIX
Interactive Time Sharing Operating System.
Workstream
Manufacturing Unix based batch Tracking System.
General Business Use
(17 Apr 09)
TPG0186A
Glossary
A.2
(17 Apr 09)
TPG0186A
Abbreviations
ACSF
Access Control Security Functions
AdvX
32-bit Crypto Accelerator developed and produced by Atmel
AVR
8-bit RISC processor developed and produced by Atmel
BIST
Built-in Self Test
CC
Common Criteria
CPU
Central Processing Unit
CRC
Cyclic Redundancy Check
DES
Data Encryption Standard
DPA
Differential Power Analysis
EEPROM
Electrically Erasable Programmable ROM
EKB
East Kilbride
FIB
Focussed Ion Beam
HCMOS
High Speed Complementary Metal Oxide Semiconductor
I/O
Input/Output
IC
Integrated Circuit
IFCSF
Information Flow Control Security Functions
ISO
International Standards Organization
LFSR
Linear Feedback Shift Register
MAC
Master Authentication Key
MCU
Microcontroller
MPU
Memory Protection Unit (Firewall)
NVM
Non Volatile Memory
OTP
One Time Programmable
P0
ROM Program Supervisor
P1
EEPROM Program Supervisor
P5
Crypto ROM Program Supervisor
P6
Crypto ROM Program Supervisor
PME
Package Mode Entry
PMT
Package Mode Test
PP
Protection Profile
RAM
Random-Access Memory
General Business Use
83 of 86
Security Target Lite
84 of 86
RFO
Rousset France Operations
RISC
Reduced Instruction Set Core
RNG
Random Number Generator
ROM
Read-Only Memory
SPA
Simple Power Analysis
TD
Technical Data
TME
Test Mode Entry
TMR
Test Mode Run
TOE
Target of Evaluation
USB
Universal Serial Bus
VFO
Variable Frequency Oscillator
General Business Use
(17 Apr 09)
TPG0186A
Appendix B
AT90SC13612RCU Life Cycle Addresses
217
The table below details the relevant addresses for the AT90SC13612RCU Project
Centre
Address
Design Centre
Atmel Secure Products Division
Scottish Technology Park
East Kilbride
Scotland
United Kingdom
G75 0QR
Maskshop
Toppan Photomasks Europe
13106 Rousset Cedex,France
22529 Hamburg, Germany
01109 Dresden, Germany
91105 Corbeil Essonnes Cedex,
France
Wafer Fab
Atmel Rousset
Zone Industrielle
13106 Rousset Cedex
France
Test Centre
Atmel Secure Products Division
Scottish Technology Park
East Kilbride
Scotland
United Kingdom
G75 0QR
(17 Apr 09)
TPG0186A
General Business Use
85 of 86
Security Target Lite
86 of 86
General Business Use
(17 Apr 09)
TPG0186A
General Business Use
Atmel Corporation
2325 Orchard Parkway
San Jose, CA 95131, USA
Tel: 1(408) 441-0311
Fax: 1(408) 487-2600
Regional Headquarters
Europe
Atmel Sarl
Route des Arsenaux 41
Case Postale 80
CH-1705 Fribourg
Switzerland
Tel: (41) 26-426-5555
Fax: (41) 26-426-5500
Asia
Room 1219
Chinachem Golden Plaza
77 Mody Road Tsimshatsui
East Kowloon
Hong Kong
Tel: (852) 2721-9778
Fax: (852) 2722-1369
Japan
9F, Tonetsu Shinkawa Bldg.
1-24-8 Shinkawa
Chuo-ku, Tokyo 104-0033
Japan
Tel: (81) 3-3523-3551
Fax: (81) 3-3523-7581
Atmel Operations
Memory
2325 Orchard Parkway
San Jose, CA 95131, USA
Tel: 1(408) 441-0311
Fax: 1(408) 436-4314
RF/Automotive
Theresienstrasse 2
Postfach 3535
74025 Heilbronn, Germany
Tel: (49) 71-31-67-0
Fax: (49) 71-31-67-2340
Microcontrollers
2325 Orchard Parkway
San Jose, CA 95131, USA
Tel: 1(408) 441-0311
Fax: 1(408) 436-4314
La Chantrerie
BP 70602
44306 Nantes Cedex 3, France
Tel: (33) 2-40-18-18-18
Fax: (33) 2-40-18-19-60
ASIC/ASSP/Smart Cards
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906, USA
Tel: 1(719) 576-3300
Fax: 1(719) 540-1759
Biometrics/Imaging/Hi-Rel MPU/
High Speed Converters/RF Datacom
Avenue de Rochepleine
BP 123
38521 Saint-Egreve Cedex, France
Tel: (33) 4-76-58-30-00
Fax: (33) 4-76-58-34-80
Zone Industrielle
13106 Rousset Cedex, France
Tel: (33) 4-42-53-60-00
Fax: (33) 4-42-53-60-01
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906, USA
Tel: 1(719) 576-3300
Fax: 1(719) 540-1759
Scottish Enterprise Technology Park
Maxwell Building
East Kilbride G75 0QR, Scotland
Tel: (44) 1355-803-000
Fax: (44) 1355-242-743
Literature Requests
www.atmel.com/literature
Disclaimer: The information in this document is provided in connection with Atmel 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 Atmel products. EXCEPT AS SET FORTH IN ATMEL’S TERMS AND CONDITIONS OF SALE LOCATED ON ATMEL’S WEB SITE, ATMEL ASSUMES 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, FITNESS FOR A PARTICULAR
PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT
OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ATMEL HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel 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. Atmel does not make any commitment to update the information contained herein. Unless specifically provided
otherwise, Atmel products are not suitable for, and shall not be used in, automotive applications. Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life.
© Atmel Corporation 2009. All rights reserved. Atmel ®, logo and combinations thereof, Everywhere You Are ® and others, are registered trademarks or trademarks of Atmel Corporation or its subsidiaries. Other terms and product names may be trademarks of others.
Printed on recycled paper.
TPG0186A–SMS–17Apr09
Was this manual useful for you? yes no
Thank you for your participation!

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

Download PDF

advertisement