General Business Use
EAL5+
Security Target Lite
AT90SC12872RCFT / AT90SC12836RCFT
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.
Export of this Product outside of the EU may require an Export Licence.
 Atmel Corporation 2008
(19 Feb 08) General Business Use 3 of 72
TPG0129D
Contents
Section 1 AT90SC12872RCFT / AT90SC12836RCFT Security Target Lite ............... 9
1.1 Identification................................................................................................. 9
1.2 Overview...................................................................................................... 9
1.3 Common Criteria Conformance Claim....................................................... 10
1.4 Document Objective .................................................................................. 10
1.5 Document Structure................................................................................... 10
1.6 Scope and Terminology............................................................................. 11
1.7 References ................................................................................................ 11
1.8 Revision History......................................................................................... 12
Section 2 Target of Evaluation Description................................................................ 13
2.1 Product Type ............................................................................................. 13
2.2 Smartcard Product Life-cycle..................................................................... 17
2.3 TOE Environment ...................................................................................... 19
2.4 TOE Logical Phases .................................................................................. 20
2.5 TOE Intended Usage ................................................................................. 21
2.6 General IT Features of the TOE ................................................................ 23
Section 3 TOE Security Environment ........................................................................ 25
3.1 Assets ........................................................................................................ 25
3.2 Assumptions .............................................................................................. 26
3.3 Threats....................................................................................................... 29
3.4 Organizational Security Policies ................................................................ 34
Section 4 Security Objectives.................................................................................... 35
4.1 Security Objectives for the TOE................................................................. 35
4.2 Security Objectives for the Environment.................................................... 38
Security Target Lite
4 of 72 General Business Use (19 Feb 08)
TPG0129D
Section 5 TOE Security Functional Requirements .................................................... 43
5.1 Functional Requirements Applicable to Phase 3 Only
(Testing Phase) .........................................................................................43
5.2 Functional Requirements Applicable to Phases 3 to 7 ..............................46
5.3 Functional Requirements Applicable to PMT in Phase 4 to 7 Only ...........53
5.4 TOE Security Assurance Requirements ....................................................54
Section 6 TOE Summary Specification...................................................................... 57
6.1 TOE Security Functions.............................................................................57
6.2 TOE Assurance Measures.........................................................................64
Section 7 PP Claims.................................................................................................. 67
7.1 PP Reference.............................................................................................67
7.2 PP Refinements.........................................................................................67
7.3 PP Additions ..............................................................................................67
Appendix A Glossary..................................................................................................... 69
(19 Feb 08) General Business Use 5 of 72
TPG0129D
Figures
Figure 2-1 Smartcard Product Life Cycle ...........................................................................18
Security Target Lite
6 of 72 General Business Use (19 Feb 08)
TPG0129D
(19 Feb 08) General Business Use 7 of 72
TPG0129D
Tables
Table 2-1 Classic and XP Write modes....................................................................... 14
Table 2-2 Smartcard Product Life-cycle...................................................................... 17
Table 2-3 Phases 4 to 7 Product Users ...................................................................... 22
Table 3-1 Threats and Phases.................................................................................... 33
Table 5-1 IFCSF_Policy .............................................................................................. 50
Table 6-1 Relationship Between Security Requirements and Security Functions ...... 63
Table 6-2 Relationship Between Assurance Requirements and Measures ................ 66
Security Target Lite
8 of 72 General Business Use (19 Feb 08)
TPG0129D
(19 Feb 08) General Business Use 9 of 72
TPG0129D
Section 1
AT90SC12872RCFT / AT90SC12836RCFT Security Target Lite
1.1 Identification
1 Title: AT90SC12872RCFT / AT90SC12836RCFT Security Target Lite: TPG0129D_(19
Feb 08)
2 This Security Target Lite has been constructed with Common Criteria (CC) Version 2.3.
1.2 Overview
3 This Security Target (ST) is conformant to the Protection Profile PP/9806, 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 ASL4 and the ‘parent’ device of the family, from which
other family members will be derived, is the AT90SC19264RC.
4 The AT90SC12872RCFT / AT90SC12836RCFT+
MCU device:
5 is being evaluated against the CC Smartcard Integrated Circuit Protection Profile
PP/9806 to Evaluation Assurance Level 5 (EAL5) augmented with AVA_VLA.4,
ALC_DVS.2 and AVA_MSU.3 under the Common Criteria scheme. Atmel Smart Card
ICs, a division of ATMEL Corporation, is the developer and the sponsor for the AT90SC
ASL4 evaluations.
6 The devices in the AT90SC ASL4 family are based on the AVR RISC family of single-
chip 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 ASL4 devices are
Product Identification Number AT58803
Revision (s)* M
Atmel Toolbox Version 00.03.01.07
Note
+
The TOE is offered to customers under two part numbers
AT90SC12872RCFT and AT90SC12836RCFT, there is no difference in
either hardware or software between the 2 part numbers.
Security Target Lite
10 of 72 General Business Use (19 Feb 08)
TPG0129D
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.
1.3 Common Criteria Conformance Claim
7 This Security Target is conformant to parts 2 and 3 of the Common Criteria, V2.3, as
follows:
! Part 2 conformant: the security functional requirements are based on those
identified in part 2 of the Common Criteria.
! 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.
1.4 Document Objective
8 The purpose of this document is to satisfy the Common Criteria (CC) requirements for
a Security Target lite; in particular, to specify the security requirements and functions,
and the assurance requirements and measures, in accordance with Protection Profile
PP/9806, Smartcard Integrated Circuit V2.0.
1.5 Document Structure
9 Section 1 introduces the Security Target, and includes sections on terminology and
references.
10 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.
11 Section 3 describes the TOE security environment.
12 Section 4 describes the required security objectives.
13 Section 5 describes the TOE security functional requirements and the security
assurance requirements.
14 Section 6 describes the TOE security functions.
15 Section 7 describes the Protection Profile (PP) claims.
16 Appendix A provides a glossary of the terms and abbreviations.
AT90SC12872RCFT / AT90SC12836RCFT Security Target Lite
(19 Feb 08) General Business Use 11 of 72
TPG0129D
1.6 Scope and Terminology
17 This document is based on the AT90SC12872RCFT Technical Data Sheet [TD].
18 The term Target of Evaluation (TOE) is standard CC terminology and refers to the
product being evaluated, the AT90SC12872RCFT / AT90SC12836RCFT MCU device
in this case.The stated toolbox commands are also part of the evaluation. Downloaded
test software will be used for evaluation purposes but is outside the scope of the TOE.
Description of how to use the security features can be found in [TD].
19 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.
20 Hexadecimal numbers are prefixed by $, e.g. $FF 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 References
21 The following relates to the latest revision of the document.
[ESOF] AT90SC Strength of Security Functions Analysis
[STI] Standard Test Interface
[TD] AT90SC12872RCFT Technical Data (TPR0097)
[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] Toolbox 3.x on AT90SCxxxxC Family with AdvX (TPR0133)
Security Target Lite
12 of 72 General Business Use (19 Feb 08)
TPG0129D
1.8 Revision History
[APP_AdvX] AdvX for AT90SC Family (TPR0116)
[APP_CRYPT] Efficient use of AdvX for Implementing Cryptographic
Operations (TPR0142)
[WSR] Wafer Saw Recommendations (TPG0079)
[PLC] Common Criteria PLC
Rev Date Description Originator
A 03 Aug 06 Initial Release John Boggie
B 09 Aug 06 Fixed errors in Section 5.1.3, 6.1.8 and
Appendix
John Boggie
C 09 Jan 07 Added AT90SC12836RCFT to scope of
evaluation, updated Rev to I and J added
explanation.
John Boggie
D 19 Feb 08 Updated Rev to M and added new TBX
00.03.01.07
John Boggie
(19 Feb 08) General Business Use 13 of 72
TPG0129D
Section 2
Target of Evaluation Description
22 This part of the Security Target Lite (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
23 The TOE is the single chip microcontroller unit to be used in a smartcard product,
independent of the physical interface and the way it is packaged. Specifically, the TOE
is the AT90SC12872RCFT/AT90SC12836RCFT device from the AT90SC ASL4 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.
24 The devices in the AT90SC ASL4 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 ASL4 family members offer various options. The AT90SC ASL4 family of
devices are designed in accordance with the ISO standard for integrated circuit cards
(ISO 7816), where appropriate.
25 The TOE is availabe to customers under 2 part numbers AT90SC12872RCFT and
AT90SC12836RCFT. Both the AT90SC12836RCT and AT90SC12872RCFT are no
different from each other, i.e. they are both the same in both Hardware configuration
and associated Atmel Toolbox (software configuration). The stating of 2 different part
numbers is for marketing purposes only.
26 The TOE requires embedded software to test the device and demonstrate certain
security characteristics during the development phase. In the end-usage phase there
will be no embedded test software in the TOE. Test software will be downloaded into
the device EEPROM and be fully erased before devices leave the test environment.
This test software is only used in the testing phase of the TOE life cycle and is fully
erased before disabling Test Mode, therefore this software is outwith the scope of the
evaluation. Test Mode disable is achieved by sawing the wafer.
27 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
mode the EEPROM is erased clearing any customer data, Package Mode only allows
a limited set operations and inputs [PME]. Package mode can only be entered on sawn
wafers.
Security Target Lite
14 of 72 General Business Use (19 Feb 08)
TPG0129D
28 The TOE widely uses ATMEL high density non volatile memories: it features 128K
bytes of CPU ROM program memory, 72K bytes of EEPROM program/data memory,
5K bytes of static RAM memory, and 32K bytes dedicated to Atmel’s Crypto Library
[TBX].
29 The EEPROM includes 128 bytes of One Time Programmable (OTP) memory and a
384-byte of bit-addressable area.
30 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.
31 The NVM can be operated in two ways Classic and XP operating mode. Classic System
this is embedded in most AT90SC products. It features byte and page writing modes
and uses BHS, IDLE or Polling modes [TD].
32 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].
33 Table Table 2-1 gives a summary of the write modes for the two operating modes.
Table 2-1 Classic and XP Write modes
34 The TOE also includes a 32bit Checksum Accelerator, a CRC-16/32 peripheral, a
Random Number Generator, a fast hardware DES/3DES peripheral, and a 32bit crypto
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. The Atmel Toolbox [TBX] 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
Write Modes Classic Write Modes XP
Standard EEPROM
Page mode with autoerase
Page mode without autoerase
Byte mode with autoerase
Byte mode without autoerase
Erase only
Erase + Write
Write only
Full page erase
Partial page erase
Block erase
Bit Addressable
Page mode with autoerase
Page mode without autoerase
Byte mode with autoerase
Byte mode without autoerase
Erase only
Pseudo bit by page
Pseudo bit by byte
Erase + Write
Write only
Full page erase
Partial page erase
Block erase
Bit write
Byte Writable OTP Pseudo bit by byte Write only
Target of Evaluation Description
(19 Feb 08) General Business Use 15 of 72
TPG0129D
crypto library [TBX] with cryptographic primitives (such as modular exponentiation) is
provided by ATMEL, but the customer can 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]. Within the scope of the
TOE is the full Atmel Toolbox as detailed in [TBX].
35 The TOE includes security logic comprising detectors which monitor voltage, frequency
and temperature.
36 The TOE is equipped with logic peripherals including 2 timers, 2 serial port for use in
contact mode, 2 RF pins for use in contactless mode, an ISO7816 interface and an
ISO7816 controller.
37 The TOE can be operated in contactless mode. RF contactless interface (CIC) with full
support for ISO/IEC 14443 type A and B protocol.
38 Depending on the end application of the TOE some customers require the antenna
inductance to be modified. The end usage and antenna are outwith the scope of the
evaluation, but to enable the modification of the antenna inductance the TOE tuning
capacitance must be modified. The modification to the tuning capacitance is achieved
by changing a metal mask layer. The change of a metal mask using Atmel’s
configuration management process causes a new revision of the TOE to be produced,
therefore it is possible to have several revisions of the TOE certified at the same time.
39 The TOE includes a powerful Firewall that protects all memories, peripheral and IO
register accesses. This Firewall defines the user modes (supervisor mode S.SUPER
and User S.NON-SUPER) and many different address spaces [TD].
40 The TOE interfaces consist of:
! The physical surface of the circuit,
! The ISO7816-3 electrical contacts (VCC, GND, CLK, RSTN, I/O0, I/O1),
! The ISO14443 RF contacts (RF1, RF2)
! The software interface to the hardware component through memories and
registers,
! No other software interface (as there is no IC dedicated software in the TOE).
Note
Please note that within the scope of the evaluation is the TOE hardware with
and without the Atmel Toolbox software. If the smartcard embedded software
developer wishes to create their own cryptographic toolbox they must follow
the guidance notes [APP_AdvX] and [APP_CRYPT] to ensure that the
security requirements are maintained.
Security Target Lite
16 of 72 General Business Use (19 Feb 08)
TPG0129D
41 The guidance documents applicable for the development of the smartcard embedded
software for this TOE are:
42 These guidance documents are constantly updated as the state-of-the-art of attacks
evolves. Software developer should always refer to the latest version of these
documents.
[TD] AT90SC12872RCFT Technical Data (TPR0097)
[AM_IS] AT90SC Addressing Modes and Instruction Set (1323)
[APP_SEC] Security Recommendations AT90SC ASL4 Products (TPR0066)
[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] Generating Unpredictable Random Numbers on the AT90SC
Family Devices (1573)
[APP_RNG_ENT] Generating Random Numbers with a controlled entropy on
AT90SC family (TPR0166)
[TBX] Toolbox 3.x on AT90SCxxxxC Family with AdvX (TPR0133)
[APP_AdvX] AdvX for AT90SC Family (TPR0116)
[APP_CRYPT] Efficient use of AdvX for Implementing Cryptographic
Operations (TPR0142)
Target of Evaluation Description
(19 Feb 08) General Business Use 17 of 72
TPG0129D
2.2 Smartcard Product Life-cycle
43 The smartcard product life-cycle consists of 7 phases where the following authorities
are involved.
44 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.
45 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.
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.
Security Target Lite
18 of 72 General Business Use (19 Feb 08)
TPG0129D
46 Figure 2-1 describes the Smartcard product life-cycle. [PLC] contains the addresses of
the relevant organizations.
Figure 2-1 Smartcard Product Life Cycle
Legend
Limits of the
development cycle
Trusted delivery and
verification procedures
Embedded software
Pre-personalization data
and Atmel Toolbox data
IC sensitive information
software, tools (not
applicable)
Test Libraries, Atmel Crypto
Library
Design, Place & Route
Maskprep Center
Maskshop
Wafer Fab
Test Center (Memory test,
Wafer Thinning, Test, Sawing)
Production
Phase
User
Phase
Development
Phase
Smartcard IC Database Construction
IC Photomask Fabrication
IC Testing and Security Encoding
IC Manufacturing
IC Packaging
Smartcard Product Finishing Process
Testing (1)
Personalization
Testing (1)
Smartcard Product End-Usage (1)
End of Life Process
IC Design IC Dedicated Software
IC Personalization requirements Smartcard embedded software (not applicable)
IC Personalization requirements
Testing (1)
Phase 7
Phase 6
Phase 5
Phase 3
Phase 2
Phase 1
Phase 4
IC Personalization requirements
Customer Toolbox if applicable
Product
Construction
Product
Usage
(1) Any faulty TOEs would
be returned to the Testing
Centre and placed in
Package Mode to perform
failure analysis.
Target of Evaluation Description
(19 Feb 08) General Business Use 19 of 72
TPG0129D
47 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
48 These procedures shall be compliant with the assumptions [A_DLV] developed in
Section 3.2.2.
49 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 TOE Environment
50 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
51 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.
52 The development begins with the TOE's specification. All parties in contact with
sensitive information are required to abide by Non-Disclosure Agreements.
53 Reticles and photomasks are generated from the verified IC database. These are
manufactured by Maskshop (see address in [PLC]), for wafer fab processing
undertaken as per [PLC]. The reticles and photomasks are then shipped in a secure
manner to the wafer fab processing facilities.
2.3.2 TOE Production Environment
54 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 batch tracking system.
Security Target Lite
20 of 72 General Business Use (19 Feb 08)
TPG0129D
55 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 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.
56 The wafers are inked to separate the functional ICs from the non-functional ICs. Finally,
the wafers are sawn and then shipped to the customer. Unsawn wafers may be shipped
to the customer if requested.
2.3.3 TOE User Environment
57 The TOE user environment is the environment of phases 4 to 7.
58 At phases 4, 5, and 6, the TOE user environment is a controlled environment.
59 Following the sawing step, the wafers are split into individual dies. The good ICs are
assembled into modules in a module assembly plant.
60 Further testing is carried out followed by the shipment of the modules to the smartcard
product manufacturer (embedder) by means of a secure carrier.
61 Additional testing occurs followed by smartcard personalization, retesting and then
delivery to the smartcard issuer.
End-user environment (Phase 7)
62 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.
63 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 TOE Logical Phases
64 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.
Target of Evaluation Description
(19 Feb 08) General Business Use 21 of 72
TPG0129D
2.5 TOE Intended Usage
65 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.
66 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.
! The IC manufacturer
Security Target Lite
22 of 72 General Business Use (19 Feb 08)
TPG0129D
67 Table 2-3 lists the users of the product during phases 4 to 7.
Table 2-3 Phases 4 to 7 Product Users
68 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.
69 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
Phase 4 ! Packaging manufacturer (administrator)
! Smartcard embedded software developer
! System integrator, such as the terminal software developer
Phase 5 ! Smartcard product manufacturer (administrator)
! Smartcard embedded software developer
! System integrator, such as the terminal software developer
Phase 6 ! 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.
Phase 7 ! 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.
The IC manufacturer and the smartcard product
manufacturer may also receive ICs for analysis, should
problems occur during the smartcard usage.
Note
Target of Evaluation Description
(19 Feb 08) General Business Use 23 of 72
TPG0129D
mode is permanently disabled by sawing off the critical wires, and the MCU is set to
M.USER_MODE mode.
70 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 a
test interface, and in conjunction with stimulus provided by an external test system. This
mode is intended to be used solely by authorized staff.
71 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.
72 The only modes of operation are those stated in paragraph 68 and 70.
73 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.
74 The EEPROM includes One Time Programmable (OTP) bytes, which can be used by
the embedded software to store security-related information such as cryptographic
keys or life state software flags. Customer embedded software is outwith the scope of
the evaluation.
75 The FireWall (Memories and Peripherals Protection Unit) allows the smartcard
embedded software to prevent read/write/execute access to (parts of) CPU ROM,
EEPROM, RAM, Crypto ROM and peripherals from EEPROM.
76 The ISO7816 compliant I/O ports can be used to pass data to or from the MCU in
contact mode. The application program determines how to interpret the data.
77 The ISO14443 complaint RF pads can be used to pass data to or from the MCU in
contactless mode. The application program determines haw to interpret the data.
2.6 General IT Features of the TOE
78 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)
Security Target Lite
24 of 72 General Business Use (19 Feb 08)
TPG0129D
(19 Feb 08) General Business Use 25 of 72
TPG0129D
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 assumptions, the assets to
be protected, the threats, and the organizational security policies.
3.1 Assets
80 Assets are security relevant elements of the TOE that include the:
! Application data (D.xxx_DATA) of the TOE comprising the IC pre-personalization
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),
! 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)
! IC dedicated software (D.xxx_DSOFT) located in:
! CPU ROM (D.CPU_ROM_DSOFT),
! CPU EEPROM (D.CPU_EEPROM_DSOFT),
! Crypto ROM (D.CRYPTO_ROM_DSOFT)
! IC specification (D.IC_SPEC), design (D.DESIGN), development tools
(D.DEV_TOOLS) and technology (D.TECHNO).
81 Therefore, the TOE itself is an asset.
82 Assets must be protected in terms of confidentiality and integrity.
83 These assets can be grouped to define objects that must be protected, which is useful
for the following sections of this document.
Security Target Lite
26 of 72 General Business Use (19 Feb 08)
TPG0129D
! 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,
! O3 : Crypto ROM: covering D.CRYPTO_ROM_DATA, D.CRYPTO_ROM_SOFT,
D.CRYPTO_ROM_DSOFT,
! O4: CPU RAM : covering D.CPU_ROM_DATA,
! O5: CRYPTO RAM : covering D.CRYPTO_ROM_DATA,
! O6 : Peripherals and IO Registers : covering D.PERIPH_REG_DATA,
! O7 : Illegal address : unmapped memory space areas,
! O8 : Illegal opcode : unmapped CPU opcode.
84 Illegal address is defined as unmapped regions in the memory map, as listed in [TD].
85 Illegal opcodes are defined as unmapped CPU opcodes, as listed in [AMIS].
3.2 Assumptions
86 It is assumed that this section concerns the following items:
! Due to the definition of the TOE limits, any assumption for the smartcard software
development (phase 1 is outside the scope of the TOE)
! Any assumption from phases 4 to 7 for the secure usage of the TOE, including the
TOE trusted delivery procedures
87 Security is always dependent on the whole system: the weakest element of the chain
determines the total system security. Assumptions described hereafter must be
considered for a secure system using smartcard products:
! Assumptions on phase 1
! Assumptions on the TOE delivery process (phases 4 to 7)
! Assumptions on phases 4-5-6
! Assumptions on phase 7
(19 Feb 08) General Business Use 27 of 72
TPG0129D
3.2.1 Assumptions on Phase 1
3.2.2 Assumptions on the TOE Delivery Process (Phases 4 to 7)
88 Procedures shall guarantee the control of the TOE delivery and storage process and
conformance to its objectives as described in the following assumptions.
A.SOFT_ARCHI The smartcard embedded software and data (D.SOFT_xxx
and D.xxx_DATA) shall be designed in a secure manner,
that is focusing on integrity of program and data.
A.DEV_ORG Procedures dealing with physical, personnel,
organizational, technical measures for the confidentiality
and integrity of smartcard embedded software and data
(e.g. source code and any associated documents related to
D.xxx_SOFT and D.xxx_DATA) and IC designer proprietary
information (tools D.DEV_TOOLS, software D.xxx_DSOFT,
documentation D.IC_SPEC, D.DESIGN, D.TECHNO) shall
exist and be applied in software development.
A.DLV_PROTECT Procedures shall ensure protection of TOE material and
information under delivery and storage. A procedure shall
ensure protection of the TOE for unsawn wafer delivery.
A.DLV_AUDIT Procedures shall ensure that corrective actions are taken in
case of improper operation in the delivery process and
storage.
A.DLV_RESP Procedures shall ensure that people dealing with the
procedure for delivery have got the required skill.
Security Target Lite
28 of 72 General Business Use (19 Feb 08)
TPG0129D
3.2.3 Assumptions on Phases 4 to 6
3.2.4 Assumptions on Phase 7
A.USE_TEST It is assumed that appropriate functionality testing of the IC
is used in phases 4, 5 and 6.
A.USE_PROD It is assumed that security procedures are used during all
manufacturing and test operations through phases 4, 5, 6 to
maintain confidentiality and integrity of the TOE and of its
manufacturing and test data (to prevent any possible copy,
modification, retention, theft or unauthorized use). In the
case where unsawn wafers are delivered, appropriate
guidance on sawing will be known and used by the
customer.
A.USE_DIAG It is assumed that secure communication protocols and
procedures are used between smartcard and terminal.
A.USE_SYS It is assumed that the integrity and confidentiality of
sensitive data stored/handled by the system (terminals,
communications...) is maintained.
TOE Security Environment
(19 Feb 08) General Business Use 29 of 72
TPG0129D
3.3 Threats
89 The TOE as defined in Section 2 is required to counter the threats described hereafter;
a threat agent wishes to abuse the assets either by functional attacks, environmental
manipulations, specific hardware manipulations or by any other types of attacks.
90 Threats have to be split in:
! Threats against which specific protection within the TOE is required (class I),
! Threats against which specific protection within the environment is required (class
II).
3.3.1 Unauthorized Full or Partial Cloning of the TOE
3.3.2 Threats on Phase 1 (Delivery and Verification Procedures)
91 During phase 1, three types of threats have to be considered:
a) Threats on the smartcard’s embedded software and its environment of
development, such as:
! Unauthorized disclosure
! Modification or theft of the smartcard embedded software D.xxx_SOFT and
any additional data D.xxx_DATA at phase 1.
Considering the limits of the TOE, these previous threats are outside the scope of this
security target.
b) Threats on the assets transmitted from the IC designer to the smartcard software
developer during the smartcard development.
c) Threats on the smartcard embedded software D.xxx_SOFT and any additional
application data D.xxx_DATA transmitted during the delivery process from the
smartcard embedded software developer to the IC designer.
T.CLON Functional cloning of the TOE (full or partial) appears to be
relevant to any phases of the TOE life-cycle, from phase 1
to phase 7.
Generally, this threat is derived from specific threats
combining unauthorized disclosure, modification or theft of
assets at different phases.
Security Target Lite
30 of 72 General Business Use (19 Feb 08)
TPG0129D
92 The previous types b and c threats are described hereafter.
3.3.3 Threats on Phases 2 to 7
93 During these phases, the assumed threats could be described in three types:
! Unauthorized disclosure of assets
! Theft or unauthorized use of assets
! Unauthorized modification of assets
Unauthorized disclosure of assets
94 This type of threats covers unauthorized disclosure of assets by attackers who may
possess a wide range of technical skills, resources and motivation. Such attackers may
also have technical awareness of the product.
T.DIS_INFO Unauthorized disclosure of the assets delivered by the IC
designer to the smartcard software developer such as
sensitive information on IC specification D.IC_SPEC,
design D_DESIGN and technology D.TECHNO, software
and tools D.DEV_TOOLS if applicable.
T.DIS_DEL Unauthorized disclosure of the smartcard embedded
software D.xxx_SOFT and any additional application data
D.xxx_DATA (such as IC pre-personalization requirements)
during the delivery process to the IC designer.
T.MOD_DEL Unauthorized modification of the smartcard embedded
software D.xxx_SOFT and any additional application data
D.xxx_DATA (such as IC pre-personalization requirements)
during the delivery process to the IC designer.
T.T_DEL Theft of the smartcard embedded software D.xxx_SOFT
and any additional application data D.xxx_DATA (such as
IC pre-personalization requirements) during the delivery
process to the IC designer.
T.DIS_DESIGN Unauthorized disclosure of IC design D.DESIGN.
This threat covers the unauthorized disclosure of proprietary
elements such as IC technology detailed information
D.TECHNO, IC specification, IC design, IC hardware
security mechanisms specifications D.DESIGN and
D.IC_SPEC.
T.DIS_SOFT Unauthorized disclosure of smartcard embedded software
D.xxx_SOFT and data D.xxx_DATA such as access control,
authentication system, data protection system, memory
partitioning, cryptographic programs.
TOE Security Environment
(19 Feb 08) General Business Use 31 of 72
TPG0129D
Theft or unauthorized use of assets
95 Potential attackers may gain access to the TOE and perform operations for which they
are not authorized. For example, such attackers may personalize the product in an
unauthorized manner, or try to gain fraudulous access to the smartcard system.
Unauthorized modification of assets
96 The TOE may be subjected to different types of logical or physical attacks which may
compromise security. Due to the intended usage of the TOE (the TOE environment may
be hostile), the TOE security parts may be bypassed or compromised reducing the
T.DIS_DSOFT Unauthorized disclosure of IC dedicated software
D.xxx_DSOFT.
This threat covers the unauthorized disclosure of IC
dedicated software D.xxx_DSOFT including security
mechanisms specifications D.IC_SPEC and
implementation D.DESIGN.
T.DIS_TEST Unauthorized disclosure of test information such as full
results of IC testing including interpretations.
T.DIS_TOOLS Unauthorized disclosure of development tools
D.DEV_TOOLS.
This threat covers potential disclosure of IC development
tools and testing tools (analysis tools, microprobing tools).
T.DIS_PHOTOMASK Unauthorized disclosure of photomask information
D.CPU_ROM_DATA, D.CPU_ROM_SOFT,
D.CPU_ROM_DSOFT, D.CRYPTO_ROM_DATA,
D.CRYPTO_ROM_SOFT, D.CRYPTO_ROM_DSOFT,
D.DESIGN, used for photoengraving during the silicon
fabrication process.
T.T_SAMPLE Theft or unauthorized use of TOE silicon samples, for
example, bond out chips.
T.T_PHOTOMASK Theft or unauthorized use of TOE photomasks,
D.CPU_ROM_DATA, D.CPU_ROM_SOFT,
D.CPU_ROM_DSOFT, D.CRYPTO_ROM_DATA,
D.CRYPTO_ROM_SOFT, D.CRYPTO_ROM_DSOFT,
D.DESIGN.
T.T_PRODUCT Theft or unauthorized use of smartcard products.
Security Target Lite
32 of 72 General Business Use (19 Feb 08)
TPG0129D
integrity of the TOE security mechanisms and disabling their ability to manage the TOE
security. This type of threat includes the implementation of malicious trojan horses.
T.MOD_DESIGN Unauthorized modification of IC design D.DESIGN.
This threat covers the unauthorized modification of IC
specification D.IC_SPEC, IC design including IC hardware
security mechanisms specifications and realization
D.DESIGN.
T.MOD_PHOTOMASK Unauthorized modification of TOE photomasks,
D.CPU_ROM_DATA, D.CPU_ROM_SOFT,
D.CPU_ROM_DSOFT, D.CRYPTO_ROM_DATA,
D.CRYPTO_ROM_SOFT, D.CRYPTO_ROM_DSOFT,
D.DESIGN.
T.MOD_DSOFT Unauthorized modification of IC dedicated software
D.xxx_DSOFT including modification of security
mechanisms.
T.MOD_SOFT Unauthorized modification of smartcard embedded
software D.xxx_SOFT and data D.xxx_DATA.
TOE Security Environment
(19 Feb 08) General Business Use 33 of 72
TPG0129D
97 Table 3-1 indicates the relationships between the smartcard phases and the threats.
Table 3-1 Threats and Phases
Threats Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Phase 7
Functional cloning
T.CLON Class II Class II Class I/II Class I Class I Class I Class I
Unauthorized disclosure of assets
T.DIS_INFO Class II
T.DIS_DEL Class II
T.DIS_SOFT Class II Class I/II Class I Class I Class I Class I
T.DIS_DSOFT Class II Class I/II Class I Class I Class I Class I
T.DIS_DESIGN Class II Class I/II Class I Class I Class I Class I
T.DIS_TOOLS Class II Class II
T.DIS_PHOTOMASK Class II Class II
T.DIS_TEST Class I/II Class I Class I Class I
Theft or unauthorized use of assets
T.T_DEL Class II
T.T_SAMPLE Class II Class I/II Class I Class I
T.T_PHOTOMASK Class II Class II
T.T_PRODUCT Class I/II Class I Class I Class I Class I
Unauthorized modification threats
T.MOD_DEL Class II
T.MOD_SOFT Class II Class I/II Class I Class I Class I Class I
T.MOD_DSOFT Class II Class I/II Class I Class I Class I Class I
T.MOD_DESIGN Class II Class I/II Class I Class I Class I Class I
T.MOD_PHOTOMASK Class II Class II
Security Target Lite
34 of 72 General Business Use (19 Feb 08)
TPG0129D
3.4 Organizational Security Policies
98 An organizational security policy is mandatory for the smartcard product usage. The
specifications of organizational security policies essentially depend on the applications
in which the TOE is incorporated.
99 However, it was found relevant to address the following organizational security policy
with the TOE because most of the actual Smart Card secure applications make use of
cryptographic standards.
P.CRYPTO The TOE must provide cryptographic entities, data
authentication, and approval functions must be in
accordance with ISO, associated industry, or
organizational standards or requirements.
Various cryptographic algorithms and mechanisms, such as
triple DES, RSA, SHA, ECC, and Prime Generation, are
accepted international standards. These, or others in
accordance with industry or organizational standards of
similar maturity and definition, should be used for all
cryptographic operations in the TOE.
These cryptographic operations are used for instance to
support establishment and control of a trusted channel
between the TOE and the outside environment.
To support these cryptographic functions, the TOE should
supply Random Number Generation (RNG) with sufficient
unpredictability and entropy. The TOE shall 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.
(19 Feb 08) General Business Use 35 of 72
TPG0129D
Section 4
Security Objectives
100 The security objectives of the TOE cover principally the following aspects:
! Integrity and confidentiality of assets
! Protection of the TOE and associated documentation during development and
production phases
4.1 Security Objectives for the TOE
101 The TOE shall use state of art technology to achieve the following IT security objectives:
O.TAMPER The TOE must prevent physical tampering with its
security critical parts.
The TOE must provide protection against disclosure of User
data, against disclosure/reconstruction of the Smartcard
Embedded Software or against disclosure of other critical
operational information.
This includes protection against direct micro-probing of
signals not connected to bonding pads, but also other
contact or contactless probing techniques such as laser
probing or electromagnetic sensing. Most of these
techniques require a prior reverse engineering of parts of
the device to understand its architecture and its security
functions.
This also includes protection against inherent information
leakage (for example shape of signals, power consumption,
electromagnetic emissions) on the device external
interfaces (for example clock, supply, I/O lines, and chip
physical surfaces) that could be used to disclose
confidential data, as well as forced information leakage
caused by induced malfunction or physical manipulation
Security Target Lite
36 of 72 General Business Use (19 Feb 08)
TPG0129D
O.CLON The TOE functionality needs to be protected from
cloning.
The TOE must include means to prevent an attacker from
reproducing the smartcard functionality. Most of these
techniques require a prior reverse engineering of parts of
the device to understand its architecture and its security
functions.
O.OPERATE The TOE must ensure the continued correct operation
of its security functions.
The TOE must include protection against the use of stolen
silicon samples or products that would ease an attacker
gaining fraudulous access to the smartcard system.
The TOE must also provide mechanisms to avoid the
unauthorized modification of the security functions or
software and data, by using the device test commands for
instance, or by using uncontrolled/unauthentified software
access to memories.
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
O.FLAW The TOE must not contain flaws in design,
implementation or operation.
The TOE design must include protection against
modification of its security mechanisms (for example
detectors or memory protections) that would lead to bypass
or reduce their integrity, and therefore open security holes
that could be used to access embedded software and data.
The TOE design must also provide protection against
modification of its embedded software that would lead to
bypass or reduce the integrity of some software controlled
security mechanisms (for example memory areas
definition), and therefore open security holes that could be
used to access embedded software and data.
O.DIS_MECHANISM The TOE shall ensure that the hardware security
mechanisms are protected against unauthorized
disclosure.
The TOE must be designed and fabricated so that it requires
a high combination of complex equipment, knowledge, skill
and time to derive detailed designed information or other
information which could be used to compromise security
through physical attacks.
Security Objectives
(19 Feb 08) General Business Use 37 of 72
TPG0129D
O.DIS_MEMORY The TOE shall ensure that sensitive information stored
in memories is protected against unauthorized access.
The TOE must provide protection against unauthorized
access to embedded software and data stored in memories,
either using test commands, or by some embedded
software (for instance a non-supervisor user application)
that would try to dump the memories protected by the
Firewall programmation (for instance the supervisor
program and/or data), or even by some physical attacks.
O.MOD_MEMORY The TOE shall ensure that sensitive information stored
in memories is protected against any corruption or
unauthorized modification.
The TOE must provide protection against unauthorized
access to embedded software and data stored in memories,
either using test commands, or by some embedded
software (for instance a non-supervisor user application)
that would try to modify the memories protected by the
Firewall programmation (for instance the supervisor
program and/or data), or even by some physical attacks.
O.CRYPTO The TOE shall provide cryptographic entities, data
authentication, and approval functions in accordance
with ISO, associated industry, or organizational
standards or requirements.
The TOE must provide cryptographic algorithms and
mechanisms, such as triple DES, RSA, SHA, ECC, and
Prime Generation, that are accepted international
standards. These, in accordance with industry
organizational standards, must be used for all cryptographic
operations in the TOE.
These cryptographic operations are used for instance to
support establishment and control of a trusted channel
between the TOE and the outside environment.
To support these cryptographic functions, the TOE shall
supply Random Number Generation (RNG) with sufficient
unpredictability and entropy. The TOE shall 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.
Security Target Lite
38 of 72 General Business Use (19 Feb 08)
TPG0129D
4.2 Security Objectives for the Environment
4.2.1 Objectives on Phase 1
O.DEV_DIS The smartcard IC designer must have procedures to control
the sales, distribution, storage and usage of the software and
hardware development tools and classified documents,
suitable to maintain the integrity and the confidentiality of the
assets of the TOE.
It must be ensured that:
! Tools are only delivered to the parties authorized
personnel.
! Confidential information such as data sheets and
general information on defined assets are only delivered
to the parties authorized personnel on the basis of
need-to-know.
O.SOFT_DLV The smartcard embedded software must be delivered from
the smartcard embedded software developer (Phase 1) to
the IC designer through a trusted delivery and verification
procedure that shall be able to maintain the integrity of the
software and its confidentiality, if applicable.
O.SOFT_MECH To achieve the level of security required by this security
target, the smartcard embedded software shall use IC
security features and security mechanisms (for example,
sensors) as specified in the smartcard IC documentation
[TD].
O.DEV_TOOLS The smartcard embedded software shall be designed in a
secure manner, by using exclusively software development
tools (compilers, assemblers, linkers, simulators etc.) and
software-hardware integration testing tools (emulators) that
will grant the integrity of program and data.
Security Objectives
(19 Feb 08) General Business Use 39 of 72
TPG0129D
4.2.2 Objectives on Phase 2 (Development Phase)
O.SOFT_ACS Embedded software shall be accessible only by authorized
personnel within the IC designer on the basis of
need-to-know.
O.DESIGN_ACS IC specifications, detailed design, IC databases,
schematics/layout or any further design information shall be
accessible only by authorized personnel within the IC
designer on the basis of need-to-know (physical, personnel,
organizational, technical procedures).
O.DSOFT_ACS Any IC dedicated software specification, detailed design,
source code or any further information shall be accessible
only by authorized personnel within the IC designer on the
basis of need-to-know.
O.MASK_FAB Physical, personnel, organizational, technical procedures
during photomask fabrication (including deliveries between
photomasks manufacturer and IC manufacturer) shall
ensure the integrity and confidentiality of the TOE.
O.MECH_ACS Details of hardware security mechanisms shall be
accessible only by authorized personnel within the IC
designer on the basis of need-to-know.
O.TI_ACS Security relevant technology information shall be accessible
only by authorized personnel within the IC designer on the
basis of need-to-know.
Security Target Lite
40 of 72 General Business Use (19 Feb 08)
TPG0129D
4.2.3 Objectives on Phase 3 (Manufacturing Phase)
O.TOE_PRT The manufacturing process shall ensure that protection of
the TOE from any kind of unauthorized use such as
tampering or theft.
During the IC manufacturing and test operations, security
procedures shall ensure the confidentiality and integrity of:
! TOE manufacturing data (to prevent any possible copy,
modification, retention, theft or unauthorized use).
! TOE security relevant test programs, test data,
databases and specific analysis methods and tools.
These procedures shall define a security system applicable
during the manufacturing and test operations to maintain
confidentiality and integrity of the TOE by control of:
! Packaging and storage.
! Traceability.
! Storage and protection of manufacturing process
specific assets (such as manufacturing process
documentation, further data, or samples)
! Access control and audit to tests, analysis tools,
laboratories, and databases.
! Change/modification in the manufacturing equipment,
management of rejects.
O.IC_DLV The delivery procedures from the IC manufacturer shall
maintain the integrity and confidentiality of the TOE and its
assets.
Security Objectives
(19 Feb 08) General Business Use 41 of 72
TPG0129D
4.2.4 Objectives on the TOE Delivery Process (Phases 4 to 7)
4.2.5 Objectives on Phase 4 to 6
O.DLV_PROTECT Procedures shall ensure protection of TOE material
(including sawn and unsawn wafers) and information under
delivery, including the following objectives:
! Non-disclosure of any security relevant information.
! Identification of the elements under delivery.
! Meet confidentiality rules (confidentiality level,
transmittal form, reception acknowledgement).
! Physical protection to prevent external damage.
! Secure storage and handling procedures are
applicable for all TOEs (including rejected TOEs).
! Traceability of TOE during delivery including the
following parameters:
! Origin and shipment details.
! Reception, reception acknowledgement.
! Location material and information.
O.DLV_AUDIT Procedures shall ensure that corrective actions are taken in
the event of improper operation in the delivery process
(including, if applicable any non-conformance to the
confidentiality convention) and highlight all non
conformance to this process.
O.DLV_RESP Procedures shall ensure that people (shipping department,
carrier, reception department) dealing with the procedure for
delivery get the required skill, training and knowledge to
meet the procedure requirements, and to act in full
accordance with the above expectations.
O.TEST_OPERATE Appropriate functionality testing of the IC shall be used in
phases 4 to 6.
During all manufacturing and test operations, security
procedures shall be used through phases 4, 5, 6, to maintain
confidentiality and integrity of the TOE and of its
manufacturing and test data. This applies to both sawn and
unsawn wafers.
Security Target Lite
42 of 72 General Business Use (19 Feb 08)
TPG0129D
4.2.6 Objectives on Phase 7
O.USE_DIAG Secure communication protocols and procedures shall be
used between smartcard and terminal.
O.USE_SYS The integrity and the confidentiality of sensitive data stored
or handled by the system (terminals, communications....)
shall be maintained.
(19 Feb 08) General Business Use 43 of 72
TPG0129D
Section 5
TOE Security Functional Requirements
102 The TOE security functional requirements define the functional requirements for the
TOE using only functional requirements components drawn from the Common Criteria
part 2.
103 The minimum strength of function level for the TOE security requirements is SOF-high.
104
5.1 Functional Requirements Applicable to Phase 3 Only
(Testing Phase)
5.1.1 User Authentication Before any Action (FIA_UAU.2)
105 The TOE security functions shall require each user to be successfully authenticated
before allowing any other TOE security functions-mediated actions on behalf of that
user.
5.1.2 User Identification Before any Action (FIA_UID.2)
106 The TOE security functions shall require each user to identify itself before allowing any
other TOE security functions mediated actions on behalf of that user.
5.1.3 User Attribute Definition (FIA_ATD.1)
107 The TOE security functions shall maintain the following list of security attributes
belonging to individual users:
Note
Some functional requirements refer to objects, subjects, attributes and
management functions. To formalize this:
! Objects are defined in section 3.1 based on defined assets.
! Subjects are the security roles defined in section 5.2.1.
! Attributes are defined in section 5.1.3.
! Management functions are defined in section 5.2.2.
Security Target Lite
44 of 72 General Business Use (19 Feb 08)
TPG0129D
! A1 : Read CPU ROM (O1) access right
! A2 : Write CPU ROM (O1) access right
! A3 : Execute CPU ROM (O1) access right
! A4 : Read EEPROM (O2) access right
! A5 : Write EEPROM (O2) access right
! A6 : Execute EEPROM (O2) access right
! A13 : Read Crypto ROM (O3) access right
! A14 : Write Crypto ROM (O3) access right
! A15 : Execute Crypto ROM (O3) access right
! A19 : Read CPU EEPROM (O2) access right
! A20 : Write DCPU 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 Peripherals and IO Registers (O6) access right
! A29 : Write Peripherals and IO Registers (O6) access right
! A30 : Execute Peripherals and IO Registers (O6) access right
! A31 : Read Illegal Address (O7) access right
! A32 : Write Illegal Address (O7) access right
! A33 : Execute Illegal Address (O7) access right
! A34 : Execute Illegal Opcode (O8) access right
! A100 : Test signatures of CPU ROM (O1)
! A101 : Test signatures of CPU RAM (O3)
! A102 : Encrypted contents of CPU EEPROM (O2)
! A103 : Checksum32/CRC16 signature result
! A104: Test signatures of Crypto ROM (O7)
! A200 : Test command syntax
5.1.4 TOE Security Functions Testing (FPT_TST.1)
108 The TOE security functions shall:
! Run a suite of self tests at the request of the authorized user to demonstrate the
correct operation of the TOE security functions.
TOE Security Functional Requirements
(19 Feb 08) General Business Use 45 of 72
TPG0129D
! Provide authorized users with the capability to verify the integrity of TOE security
functions data.
! Provide authorized users with the capability to verify the integrity of stored TOE
security functions executable code.
5.1.5 Stored Data Integrity Monitoring (FDP_SDI.1)
109 The TOE security functions shall monitor user data stored within the TOE scope of
control for integrity errors on all objects, based on the following attributes:
! A100 : Test signatures of CPU ROM (O1)
! A101 : Test signatures of CPU RAM (O4)
! A102 : Encrypted contents of CPU EEPROM (O2)
! A103 :Checksum32/CRC16 signature result
! A104: Test signatures of Crypto ROM (O3)
Security Target Lite
46 of 72 General Business Use (19 Feb 08)
TPG0129D
5.2 Functional Requirements Applicable to Phases 3 to 7
5.2.1 Management of Security Functions Behaviour (FMT_MOF.1)
110 The TOE security functions shall restrict the ability to F2 (Not disclosed in ST-Lite)
111 The TOE security functions shall restrict the ability to F3 (Not disclosed in ST-Lite).
112 The TOE security functions shall restrict the ability to F4 (Not disclosed in ST-Lite)
113 The TOE security functions shall restrict the ability to F5 (Not disclosed in ST-Lite)
5.2.2 Management of Security Attributes (FMT_MSA.1)
114 The TOE security functions shall enforce the ACSF_Policy (Not disclosed in ST-Lite)
and IFCSF_Policy (Information Flow Control Security Functions Policy) to restrict the
ability to access the following security attributes to S.TME_ADMIN, S.PME_ADMIN,
S.SUPER, S.NON_SUPER
5.2.3 Security Roles (FMT_SMR.1)
115 The TOE security functions shall maintain the role of:
! S.TME_ADMIN: Test Mode Entry (TME) administrator
! S.SUPER: supervisor
! S.NON_SUPER: Non-supervisor
! S.PME_ADMIN: PME administrator
116 The TOE security functions shall be able to associate users with roles.
5.2.4 Specification of Management Functions (FMT_SMF.1)
117 The TOE security functions shall provide the following security management functions
of security functions:
! F1 : Modify the behaviour of the function SF1 (Test Mode Entry).
! F2 : Enable the function (Not disclosed in ST-Lite)
! F3 : Disable the function (Not disclosed in ST-Lite)
! F4 : Modify the behaviour of the function (Not disclosed in ST-Lite)
! F5 : Modify the behaviour of the function (Not disclosed in ST-Lite)
TOE Security Functional Requirements
(19 Feb 08) General Business Use 47 of 72
TPG0129D
5.2.5 Static Attribute Initialization (FMT_MSA.3)
118 The TOE security functions shall:
! Enforce the ACSF_Policy (Not disclosed in ST-Lite) and IFCSF_Policy to
provide restrictive default values for security attributes that are used to enforce the
security functions policy
! Allow the S.TME_ADMIN to specify alternate initial values to override the default
values when an object or information is created
5.2.6 Complete Access Control (FDP_ACC.2)
119 The TOE security functions shall enforce the ACSF_Policy (Not disclosed in ST-Lite)
on:
! S.TME_ADMIN, S.SUPER, S.PME_ADMIN, S.NON_SUPER.
! (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 security functions
policy.
120 The TOE security functions 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 security functions policy.
5.2.7 Security Attribute Based Access Control (FDP_ACF.1)
121 The TOE security functions shall enforce the ACSF_Policy to objects based on:
! A1: Read CPU ROM (O1) access right
! A2: Write CPU ROM (O1) access right
! A3: Execute CPU ROM (O1) access right
! A4: Read EEPROM (O2) access right
! A5: Write EEPROM (O2) access right
! A6: Execute EEPROM (O2) access right
! A13: Read Crypto ROM (O3) access right
! A14: Write Crypto ROM (O3) access right
! A15: Execute 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
Security Target Lite
48 of 72 General Business Use (19 Feb 08)
TPG0129D
! 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
122 The TOE security functions shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed.
123 Firewall rules, that are Not disclosed in ST-Lite.
5.2.8 Subset Information Flow Control (FDP_IFC.1)
124 The TOE security functions shall enforce the IFCSF_Policy on S.TME_ADMIN and
S.PME_ADMIN, test commands and test operations that cause controlled information
to flow between the:
! CPU ROM (O1) and the Test Mode Entry administrator
! EEPROM (O2) and the Test Mode Entry administrator
! EEPROM (O2) and the Package Mode Entry administrator
! Crypto ROM (O3) and the Test Mode Entry administrator
! CPU RAM (O4) and the Test Mode Entry administrator
! Crypto RAM (O5) and the Test Mode Entry administrator
! Peripheral and IO registers (O6) and the Test Mode administrator
5.2.9 Simple Security Attributes (FDP_IFF.1)
125 The TOE security functions shall enforce the IFCSF_Policy based on the following
types of subject and information security attributes: test command syntax.
126 The TOE security functions shall:
! Permit an information flow between a controlled subject and controlled information
via a controlled operation if the following rules hold: test command syntax rules.
! Enforce no additional information flow control security functions policy rules.
! Provide no additional security functions policy capabilities.
127 The TOE security functions shall explicitly authorize an information flow based on the
following rules:
128 Test command syntax rules, based on test command syntax, that explicitly authorize
information flows between S.TME_ADMIN and:
TOE Security Functional Requirements
(19 Feb 08) General Business Use 49 of 72
TPG0129D
! CPU ROM (O1)
! EEPROM (O2)
! Crypto ROM (O3)
! CPU RAM (O4)
! Crypto RAM (O5)
! Peripheral and IO registers (O6)
129 Test command syntax rules, based on test command syntax, that explicitly authorize
information flows between S.PME_ADMIN and:
! EEPROM (O2)
130 The TOE security functions shall explicitly deny an information flow based on the
following rules:
131 Test command syntax rules, based on test command syntax, that explicitly deny
information flows between S.TME_ADMIN and:
! CPU ROM (O1)
! EEPROM (O2)
! Crypto ROM (O3)
! CPU RAM (O4)
! Crypto RAM (O5)
! Peripheral and IO registers (O6)
132 Test command syntax rules, based on test command syntax, that explicitly deny
information flows between S.PME_ADMIN and:
! CPU ROM (O1)
! EEPROM (O2)
! Crypto ROM (O3)
! CPU RAM (O4)
Note
All information about possible data flow and Test command syntax can be found in
[STI], [TMR-USER], [TestROMUG], [TestROMDD] and [TMRE2]
Note
All information about possible data flow and Test command syntax can be found in
[STI], [PME]
Note
All information about possible data flow and Test command syntax can be found in
[STI], [TMR-USER], [TestROMUG], [TestROMDD] and [TMRE2]
Security Target Lite
50 of 72 General Business Use (19 Feb 08)
TPG0129D
! Crypto RAM (O5)
! Peripheral and IO registers (O6)
IFCSF_Policy
5.2.10 Potential Violation Analysis (FAU_SAA.1)
133 The TOE Security Functions shall be able to apply a set of rules in monitoring the
audited events and based upon these rules indicate a potential violation of the TOE
Security Policy.
134 The TOE security functions shall enforce the following rules for monitoring audited
events:
a) Accumulation or combination of abnormal environmental conditions (Supply
voltage, clock input frequency, temperature, UV light) known to indicate a potential
security violation.
b) Accumulation or combination of physical tampering (Micro-probing, critical FIB
modification) known to indicate a potential security violation.
c) Accumulation or combination of Firewall violations (user trying to illegally access
controlled memories or objects, user trying to execute illegal opcodes) known to
indicate a potential security violation.
d) Accumulation of watchdog violations known to indicate a potential security
violation.
e) No other rules.
Note
All information about possible data flow and Test command syntax can be
found in [STI], [PME]
Table 5-1 IFCSF_Policy
Rules Test command syntax rules
Attribute A200: Test command syntax
S.TME_ADMIN Data flow (1)
S.PME_ADMIN Data flow (2)
(1) All information about possible data flow and Test command
syntax can be found in [STI], [TMR-USER], [TestROMUG],
[TestROMDD] and [TMRE2].
(2)
All information about possible data flow and Test command
syntax can be found in [STI], [PME].
TOE Security Functional Requirements
(19 Feb 08) General Business Use 51 of 72
TPG0129D
5.2.11 Unobservability (FPR_UNO.1)
135 The TOE security functions shall ensure that any users are unable to observe the
operations that are critical (i.e. cryptographic, read, write and erase), on assets
protected in terms of confidentiality by authorized users or subjects.
5.2.12 Notification of Physical Attack (FPT_PHP.2)
136 The TOE security functions shall:
! Provide unambiguous detection of physical tampering that might compromise the
TOE security functions.
! Provide the capability to determine whether physical tampering with the TOE
security functions’s devices or TOE security functions’s elements has occurred.
137 For values of voltage, clock input frequency, temperature and UV light which go outside
acceptable bounds, for micro-probing and critical FIB modification, for Firewall rules
violations (including illegal opcodes), and for watchdog violations, the TOE security
functions shall monitor the devices and elements and notify the S.SUPER when
physical tampering with the TOE security functions’ devices or TOE security functions’
elements has occurred.
5.2.13 Resistance to Physical Attack (FPT_PHP.3)
138 The TOE security functions shall resist tampering of voltage, clock input frequency,
temperature, UV light, micro-probing, critical FIB modification, Firewall rules violations
(including illegal opcodes), and watchdog violations to the TOE and its security
functions by responding automatically such that the TOE security policy is not violated.
5.2.14 Cryptographic Operation (FCS_COP.1)
139 The TSF shall perform hardware cryptographic checksum generation for integrity and
verification of checksum.
140 The TSF shall perform hardware data encryption and decryption in accordance with
the:
! DES cryptographic algorithm using 56-bit cryptographic key sizes that meets the
Data Encryption Standard (DES), FIPS PUB 46-3, 25th October, 1999.
! Triple Data Encryption Standard (TDES) cryptographic algorithm using 112-bit
cryptographic key sizes that meets the E-D-E two-key triple-encryption
implementation of the Data Encryption Standard, FIPS PUB 46-3, 25th October,
1999.
141 The TSF shall perform software:
Security Target Lite
52 of 72 General Business Use (19 Feb 08)
TPG0129D
! 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, FIPS PUB 180-1, 17th April 1995
! 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.
! digital signature in accordance with a specified cryptographic algorithm: EC-
DSA, and cryptographic key size:between 192 and 521 bits that meet the
following, FIPS 186-2, 27th January, 2007 for Digital Signatures.
! key agreement in accordance with a specified cryptographic algorithm: ECDH,
and cryptographic key size:between 192 and 521 bits key size that meet the
following ISO 15946-3:2002 for ECDH standard.
5.2.15 Cryptographic Key Generation (FCS_CKM.1)
142 The TSF shall generate cryptographic keys in accordance with cryptographic key
generation Miller-Rabin algorithm with confidence criteria (t) between 0 and 255, also
specified cryptographic key sizes between 192-bits and 4480-bits (respectively 2
primes of size between 96 bits and 2240 bits) specified by the NIST special publication
800-2, April 1991.
TOE Security Functional Requirements
(19 Feb 08) General Business Use 53 of 72
TPG0129D
5.3 Functional Requirements Applicable to PMT in Phase 4 to 7
Only
5.3.1 User Authentication Before any Action (FIA_UAU.2)
143 The TOE security functions shall require each user to be successfully authenticated
before allowing any other TOE security functions-mediated actions on behalf of that
user.
5.3.2 User Identification Before any Action (FIA_UID.2)
144 The TOE security functions shall require each user to identify itself before allowing any
other TOE security functions mediated actions on behalf of that user.
5.3.3 User Attribute Definition (FIA_ATD.1)
145 The TOE security functions shall maintain the following list of security attributes
belonging to PMT users:
! Package mode access right
! Limited write EEPROM (O2) access right (The S.PME_ADMIN only has access to
the physical value of the EEPROM (O2) contents not its logical contents (that is
the data read/written by the S.PME_ADMIN are encrypted data only), only a
limited set of values may be written to the EEPROM (O2) [PME])
! Limited read EEPROM (O2) access right (The S.PME_ADMIN only has access to
the physical value of the EEPROM (O2) contents not its logical contents (that is
the data read/written by the S.PME_ADMIN are encrypted data only))
! EEPROM (O2) internal signal access (charge pump and margin)
! ISO clock access right
! Clock selection right
146 The write to EEPROM (O2) access is limited to the following:
! Full erase and program
! Chip erase and program
! Page mode write*
147 The read from EEPROM (O2) access is limited to the following
! Page mode read
Note
For page mode writes, the data to write is restricted to the following fixed
values: (Not disclosed in ST-Lite)
Security Target Lite
54 of 72 General Business Use (19 Feb 08)
TPG0129D
5.4 TOE Security Assurance Requirements
148 The assurance requirement is EAL5 augmented of additional assurance components
listed in the following sections.
149 Some of these components are hierarchical ones to the components specified in EAL5.
150 All the components are drawn from Common Criteria Part 3, V2.3.
5.4.1 ALC_DVS.2 Sufficiency of Security Measures
Developer actions elements
151 The developer shall produce development security documentation.
Content and presentation of evidence elements
152 The development security documentation shall:
! Describe all the physical, procedural, personnel, and other security measures that
are necessary to protect the confidentiality and integrity of the TOE design and
implementation in its development environment.
! Provide evidence that these security measures are followed during the
development and maintenance of the TOE.
153 The evidence shall justify that the security measures provide the necessary level of
protection to maintain the confidentiality and integrity of the TOE.
Evaluator actions elements
154 The evaluator shall confirm that the:
! Information provided meets all requirements for content and presentation of
evidence
! Security measures are being applied
5.4.2 AVA_VLA.4 Highly Resistant
Developer actions elements
155 The developer shall:
! Perform a vulnerability analysis.
! Provide vulnerability analysis documentation.
TOE Security Functional Requirements
(19 Feb 08) General Business Use 55 of 72
TPG0129D
Content and presentation of evidence elements
156 The documentation shall:
! Describe the analysis of the TOE deliverables performed to search for ways in
which a user can violate the TSP.
! Describe the disposition of identified vulnerabilities.
! Show, for all identified vulnerabilities, that the vulnerability cannot be exploited in
the intended environment for the TOE.
! Justify that the TOE, with the identified vulnerabilities, is resistant to obvious
penetration attacks.
! Show that the search for vulnerabilities is systematic.
! Provide a justification that the analysis completely addresses the TOE
deliverables.
Evaluator actions elements
157 The evaluator shall:
! Confirm that the information provided meets all requirements for content and
presentation of evidence
! Conduct penetration testing, building on the developer vulnerability analysis, to
ensure the identified vulnerabilities have been addressed.
! Perform independent vulnerability analysis
! Perform independent penetration testing, based on the independent vulnerability
analysis, to determine the exploitability of additional identified vulnerabilities in the
intended environment.
! Determine that the TOE is resistant to penetration attacks performed by an
attacker possessing a high attack potential.
5.4.3 AVA_MSU.3 Analysis and Testing for Insecure States
Developer action elements
! Shall provide guidance documents
! Document an analysis of the guidance documentation.
Content and presentation of evidence elements
! Guidance documents shall identify all/possible modes of operation of the TOE
(including operation failure or operational error), their consequences and
implications for maintaining secure operation.
! Guidance documentation shall be complete, clear, consistent and reasonable.
! Guidance documentation shall list all assumptions about the intended
environment.
Security Target Lite
56 of 72 General Business Use (19 Feb 08)
TPG0129D
! Guidance documentation shall list all requirements for external security measures
(including external procedural, physical and personnel controls)
! The analysis documentation shall demonstrate documentation is complete.
Evaluator action elements
! Shall confirm that the information provided meets all requirements for content and
presentation of evidence
! Shall repeat all configuration and installation procedures, and other procedures
selectively, to confirm that the TOE can be configured and used securely using
only the supplied guidance documentation.
! Shall determine that the use of the guidance documentation allows all insecure
states to be detected.
! Shall confirm that the analysis documentation shows that guidance is provided for
secure operation in all modes of operation of the TOE.
! Shall perform independent testing to determine that an administrator or user, with
an understanding of the guidance documentation, would reasonably be able to
determine if the TOE is configured and operating in a manner that is insecure.
TOE Summary Specification
(19 Feb 08) General Business Use 57 of 72
TPG0129D
Section 6
TOE Summary Specification
158 This section defines the TOE security functions, and Figure 6-1 on page 63 specifies
how they satisfy the TOE security functional requirements.
6.1 TOE Security Functions
6.1.1 Test Mode Entry (SF1)
159 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.
160 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.
161 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.
162 The Strength of Function claimed for the Test Mode Entry security function is high.
Security Target Lite
58 of 72 General Business Use (19 Feb 08)
TPG0129D
6.1.2 Protected Test Memory Access (SF2)
163 SF2 shall ensure that, although authenticated users can have access to memories
using commands in test mode, they cannot access directly their contents.
164 Authorized Test Mode users also have access to other address regions which are not
accessible in user mode.
165 The Strength of Function claimed for the Protected Test Memory Access security
function is high.
6.1.3 Test Mode Disable (SF3)
166 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 now available.
6.1.4 TOE Testing (SF4)
167 SF4 shall provide embedded hardware test circuitry with high fault coverage to prevent
faulty devices being released in the field. Devices with manufacturing problems (short
circuits, open nets,...) could lead to a poor level of security by disabling some security
functions.
168 To conform with ISO 7816 standards the TOE embedded software will always return an
Answer-To-Reset command via the serial I/O port. This contains messages with
information on the integrity and identification of the device. An ATR also verifies
significant portions of device hardware (CPU, ROM, EEPROM and logic).
6.1.5 Data Error Detection (SF5)
169 SF5 shall provide means for performing data error detection.
170 Means of performing checksum error detection and parity error detection is provided.
The M5.1 16/32-bit Checksum Accelerator or the M5.2 CRC-16/32 hardware peripheral
can be used by the embedded software to compute fast data error detection on the
program and/or data memories before starting any operation.
TOE Summary Specification
(19 Feb 08) General Business Use 59 of 72
TPG0129D
6.1.6 FireWall (SF6)
171 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
172 The FireWall defines five user modes to execute embedded software:
! S.SUPER
! S.NON_SUPER mode (also named user mode).
173 The embedded software is split into two segments: a supervisor Operating System, and
a S.NON_SUPER application. The supervisor segment defines by software the limits
of the S.NON_SUPER segment.
174 If a protected address is accessed by the S.NON_SUPER software, a security interrupt
is invoked.
M6.2 Illegal address
175 If an illegal address is accessed, a security interrupt is invoked.
M6.3 Illegal opcode
176 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)
177 The TOE shall provide an Event Audit security function (SF7) to enforce the following
rules for monitoring audited events.
178 Accumulation or combination of the following auditable events would indicate a
potential security violation.
! 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
! M7.7 Attempts to gain illegal access to reserved EEPROM (O2) memory locations
! 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
Security Target Lite
60 of 72 General Business Use (19 Feb 08)
TPG0129D
! M7.10 Attempts to move the RAM stack to an illegal RAM memory location
! M7.11 Attempts to execute an CPU opcode that is not implemented
! M7.12 Attempts to illegally write access the device’s EEPROM (O2
! M7.13 Attempts to gain illegal access to S.SUPER mode
! M7.14 Exposure to UV light goes outside acceptable bounds
179 The Strength of Function claimed for the Event audit security function is high.
6.1.8 Event Action (SF8)
180 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:
! Memory Wiping Actions
! Different levels of immediate reset
! Different levels of security interrupts
181 Event Action depends on the type of Event (see [TD] for more information).
6.1.9 Unobservability (SF9)
182 SF9 shall ensure that users/third parties will have difficulty observing the following
operations on the TOE by the described means.
! Extracting information relating to any specific resource or service which is being
used by:
! Monitoring power consumption
! Carrying out timing analysis on cryptographic functions
! Using mechanical, electrical or optical means
183 The Strength of Function claimed for the Unobservability security function is high.
6.1.10 Cryptography (SF10)
184 The TSF shall provide a cryptographic algorithm to be able to transmit and receive
objects in a manner protected from data retrieval or modification.
185 M10.1 the TSF shall provide hardware DES, TDES data encryption/decryption
capability.
186 The TSF shall provide software
! M10.2 SHA-1
TOE Summary Specification
(19 Feb 08) General Business Use 61 of 72
TPG0129D
! M10.3 RSA without CRT (i.e. modular exponentiation)
! M10.4 RSA with CRT
187 Those 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.
188 M10.5 the TSF shall provide a hardware Random Number Generator (RNG) to support
security operations performed by cryptographic applications. This RNG 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 complies to the FIPS 140-2 quality metric.
189 M10.6 the TSF shall provide software RSA prime generation capability using Miller
Rabin algorithm with confidence criteria (t parameter) between 0 and 255 (function
vTBX3_Process (PrimeGen and Tbx3Param) of the Toolbox), this function can be used
to generate cryptographic keys.
190 M10.7 the TSF shall provide software sign and verify signatures with ECC, conforming
to EC-DSA standard
191 M10.8 the TSF shall provide software point multiplication on an elliptical curve,
conforming to EC-DSA standard
192 M10.9 the TSF shall provide software point addition on an elliptical curve, conforming
to EC-DSA standard
193 M10.10 the TSF shall provide software point doubling on an elliptical curve, conforming
to EC-DSA standard
194 M10.11 the TSF shall provide software ECDH cryptographic capability using Elliptic
Curve point operations (point addition, point doubling and point multiply)
195 M10.12 the TSF shall provide a software function that performs a selftest operation of
the TOE, at the end of the selftest function the TOE will output a Version number.
196 The Strength of Function claimed for the cryptography security function is high.
197 An assessment of the strength of the following algorithms does not form part of the
evaluation:
! DES algorithm
! TDES algorithm
! SHA-1 algorithm
Note
The Atmel Toolbox must be considered as a whole
Security Target Lite
62 of 72 General Business Use (19 Feb 08)
TPG0129D
! RSA without CRT algorithm
! RSA with CRT algorithm
! Miller Rabin algorithm
! EC-DSA
! ECDH.
6.1.11 Package Mode Entry (SF11)
198 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.
199 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.
200 It is not possible to enter Test Mode on a sawn wafer, only Package Mode can be
entered. So this function is protected by Test Mode Entry and Package Mode Entry.
201 The Strength of Function for the Package Mode Entry function is high.
6.1.12 Test Memory Access in Package Mode (SF12)
202 SF12 shall ensure that, although authenticated users can have access to memories
using commands in package mode, they cannot access directly their contents.
203 When package mode is entered a full EEPROM (O2) erase is performed. Access to the
device memories are limited by test algorithms.
! M12.1 the EEPROM (O2) tests are read/write functions controlled via a test
interface circuit but do not allow the user data to be read since they are in an
encrypted form.
! M12.2 CPU ROM (O1) data no access.
! M12.3 Crypto ROM (O3) data no access.
! M12.4 CPU RAM (O4) no access.
! M12.5 Crypto RAM (O5) no access
204 The Strength of Function claimed for the Protected Test Memory Access in Package
Mode is high.
Note
Please note that within the scope of the evaluation is the TOE hardware with
and without the Atmel Toolbox software. If the smartcard embedded software
developer wishes to create their own cryptographic toolbox they must follow
the guidance notes [APP_AdvX] and [APP_CRYPT] to ensure that the
security requirements are maintained.
TOE Summary Specification
(19 Feb 08) General Business Use 63 of 72
TPG0129D
6.1.13 Security Functions Based on Permutations/combinations
205 (Not disclosed in ST-Lite).
Table 6-1 Relationship Between Security Requirements and Security Functions
Security Functions
Test
Mode
Entry
Protected
Test
Memory
Access
Test
Mode
Disable
RNG
Data
Error
Detection
FireWall
Event
Audit
Event
Action
Unobservability
Cryptography
Package
Mode
Entry
Test
Memory
Access
in
Package
Mode
Security
Requirement
SF1
SF2
SF3
SF4
SF5
SF6
SF7
SF8
SF9
SF10
SF11
SF12
FIA_UAU.2 O1 x x
FIA_UID.2 O2 x x
FIA_ATD.1 O3 x x x x x x x x
FPT_TST.1 O4 x x x x x
FDP_SDI.1 O5 x x x
FMT_MOF.1 O6 x
FMT_MSA.1 O7
x x x x x x
FMT_SMR.1 O8 x x x x
FMT_SMF.1 O9 x x x
FMT_MSA.3 10
x x x
FDP_ACC.2 O11 x x x
FDP_ACF.1 O12 x x x
FDP_IFC.1 O13 x x x
FDP_IFF.1 O14 x x x
FAU_SAA.1 O15 x
FPR_UNO.1 O16 x
FPT_PHP.2 O17 x x
FPT_PHP.3 O18 x x
Security Target Lite
64 of 72 General Business Use (19 Feb 08)
TPG0129D
6.2 TOE Assurance Measures
206 This section defines the TOE assurance measures and Figure 6-2 on page 66 specifies
how they satisfy the TOE security assurance requirements.
6.2.1 Security Target (SA1)
207 SA1 shall provide the “AT90SC12872RCFT / AT90SC12836RCFT Security Target”
document plus its references.
6.2.2 Configuration Management (SA2)
208 SA2 shall provide the “CC Configuration Management (ACM)” interface document plus
its references.
6.2.3 Delivery and Operation (SA3)
209 SA3 shall provide the “CC Delivery and Operation (ADO)” interface document plus its
references.
6.2.4 Development Activity (SA4)
210 SA4 shall provide the “CC Development Activity (ADV)” interface document plus its
references.
6.2.5 Guidance (SA5)
211 SA5 shall provide the “CC Guidance (AGD)” interface document plus its references.
6.2.6 Life Cycle Support (SA6)
212 SA6 shall provide the “CC Life Cycle Support (ALC)” interface document plus its
references.
FCS_COP.1 O19 x
FCS_CKM.1 O20 x
Table 6-1 Relationship Between Security Requirements and Security Functions (Continued)
TOE Summary Specification
(19 Feb 08) General Business Use 65 of 72
TPG0129D
6.2.7 Test Activity (SA7)
213 SA7 shall provide the “CC Test Activity (ATE)” interface document plus its references,
and undertaking of testing described therein.
6.2.8 Vulnerability Assessment (SA8)
214 SA8 shall provide the “CC Vulnerability Assessment (AVA)” interface document plus its
references, and undertaking of vulnerability assessment described therein.
6.2.9 Smart Card Devices (SA9)
215 SA9 shall provide functional AT90SC12872RCFT / AT90SC12836RCFT smart card
devices.
6.2.10 Development Site (SA10)
216 SA10 shall provide access to the development site.
6.2.11 Test Site (SA11)
217 SA11 shall provide access to the test site.
6.2.12 Manufacturing Site (SA12)
218 SA12 shall provide access to the manufacturing site.
6.2.13 Sub-contractor Sites (SA13)
219 SA13 shall provide access to the sub-contractor sites.
Security Target Lite
66 of 72 General Business Use (19 Feb 08)
TPG0129D
Table 6-2 Relationship Between Assurance Requirements and Measures
Security
Target
Configuration
Management
Delivery
and
Operation
Development
Activity
Guidance
Life
Cycle
Support
Test
Activity
Vulnerability
assessment
Smartcard
Devices
Development
Site
Test
Site
Manufacturing
Site
Sub-contractor
Site
Assurance
Requirement
SA1
SA2
SA3
SA4
SA5
SA6
SA7
SA8
SA9
SA10
SA11
SA12
SA13
ASE_xxx x
ACM_AUT.1 x x x x x
ACM_CAP.4 x x x x x
ACM_SCP.3 x x x x 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 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
(19 Feb 08) General Business Use 67 of 72
TPG0129D
Section 7
PP Claims
7.1 PP Reference
220 This Security Target is compliant with CC Smartcard Integrated Circuit Protection
Profile PP/9806, Version 2.0, Issue September 1998, and has been registered at the
French Certification Body.
7.2 PP Refinements
221 Refinements to assumptions A.DLV_PROTECT, A.USE_PROD and objectives
O.DLV_PROTECT, O.TEST_OPERATE relate to unsawn wafers and corresponding
procedures and guidance.
222 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 PP Additions
7.3.1 Cryptographic Capability
223 In addition to conforming to PP/9806, this Security Target specifies an additional
Organizational Security Policy P.CRYPTO in Section 3.4. and an additional objective
O.CRYPTO in Section 4.1.
224 The CC security functional requirements to meet this Organizational Security Policy are
Cryptographic Operation (FCS_COP.1), and Cryptographic key generation
(FCS_CKM.1), which are specified in Section 5.
225 The security function to satisfy the FCS_COP.1, and FCS_CKM.1, requirements is
SF10 and is specified in Section 6.
7.3.2 Specification of Management Functions
226 This is an addition to the Security Management Class (FMT)
Security Target Lite
68 of 72 General Business Use (19 Feb 08)
TPG0129D
227 The security functions that satisfy the FMT_SMF.1 requirement are SF3, SF6 and
SF11. These security functions are described in Section 6.
7.3.3 Analysis and Testing for Insecure States
228 This is an addition to the Assurance Vulnerability class (AVA)
229 The assurance measures that satisfy the AVA_MSU.3 requirement are SA8 and SA9.
These assurance measures are described in Section 6.
7.3.4 Additions to Life Cycle
230 Due to the addition of Package Mode the following functional requirements are now
applicable to not only Phase 3, but also Phases 4-7.
! FIA_UAU.2 - User authentication before any action
! FIA_UID.2 - User Identification before any action
! FIA_ATD.1 - User attribute definition
231 This is due to the control of entry into Package Mode, and also the control of what
authenticated Package Mode user have access to.
232 The security functions that satisfy the FIA_UAU.2 requirements are SF1 and SF11. The
security functions are described in Section 6.
233 The security functions that satisfy the FIA_UID.2 requirements are SF1 and SF11. The
security functions are described in Section 6.
234 The security functions that satisfy the FIA_ATD.1 requirement are SF1, SF2, SF3, SF4,
SF5, SF6, SF11, and SF12. These security functions are described in Section 6.
Glossary
(19 Feb 08) General Business Use 69 of 72
TPG0129D
Appendix A
Glossary
A.1 Terms
Control Bytes Reserved bytes of EEPROM which can be
programmed with traceability information.
CRC-32 Algorithm used to compute powerful checksum on
memory blocks
IC Dedicated Software IC Proprietary software which is required for testing
purposes and to implement special functions. For
AT90SC12872RCFT / AT90SC12836RCFT 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.
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.
Integrated Circuit (IC) Electronic component(s) designed to perform
processing and/or memory functions.
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.
Security Target Lite
70 of 72 General Business Use (19 Feb 08)
TPG0129D
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.
Glossary
(19 Feb 08) General Business Use 71 of 72
TPG0129D
A.2 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
CC Common Criteria
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DES Data Encryption Standard
DPA Differential Power Analysis
EEPROM Electrically Erasable Programmable ROM
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
NVM Non Volatile Memory
OTP One Time Programmable
PME Package Mode Entry
PMT Package Mode Test
PP Protection Profile
RAM Random-Access Memory
RF Radio Frequency
RISC Reduced Instruction Set Core
RNG Random Number Generator
ROM Read-Only Memory
SPA Simple Power Analysis
TD Technical Data
Security Target Lite
72 of 72 General Business Use (19 Feb 08)
TPG0129D
TME Test Mode Entry
TOE Target of Evaluation
VFO Variable Frequency Oscillator
General Business Use
TPG0129D––19 Feb 08
© Atmel Corporation 2008. 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.
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 CONDI-
TIONS 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 INCIDEN-
TAL 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 Atmel Operations
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
Memory
2325 Orchard Parkway
San Jose, CA 95131, USA
Tel: 1(408) 441-0311
Fax: 1(408) 436-4314
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
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
RF/Automotive
Theresienstrasse 2
Postfach 3535
74025 Heilbronn, Germany
Tel: (49) 71-31-67-0
Fax: (49) 71-31-67-2340
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
Literature Requests
www.atmel.com/literature