56
Page 1 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
EUROPA AT05SC1604R
Security Target - Lite
Revision 1.2
22 Feb 02
Page 2 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Contents
1. ST Introduction...............................................................................................3
2. TOE Description.............................................................................................7
3. TOE Security Environment ..........................................................................17
4. Security Objectives.......................................................................................25
5. TOE Security Functional Requirements.......................................................31
6. TOE Security Assurance Requirements .......................................................37
7. TOE Security Functions................................................................................45
8. TOE Security Assurance Measures ..............................................................49
9. PP Claims......................................................................................................53
Annex A: Glossary..............................................................................................54
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 3 of 56
Chapter 1
ST Introduction
1.1 ST identification
1 Title: EUROPA AT05SC1604R Security Target (ST-Lite)
2 A glossary of terms used is given in Annex A.
3 This Security Target has been constructed with Common Criteria (CC) Version 2.1.
1.2 ST overview
4 This Security Target 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 EUROPA and the
‘parent’ device of the family, from which other family members will be derived, is
the AT05SC3208R.
5 The EUROPA AT05SC1604R MCU device is being evaluated against the CC
Smartcard Integrated Circuit Protection Profile PP/9806 to Evaluation Assurance
Level 4 (EAL4). The other EUROPA family members will be evaluated in the
future under the Common Criteria maintenance scheme. Atmel Smart Card ICs is
the developer and the sponsor for the EUROPA evaluations.
6 The devices in the EUROPA family are centred around Motorola's M68HC05SC
family of single-chip microcontroller devices. The M68HC05SC family, with
designed-in security features, is based on the industry-standard M68HC05 low-
power HCMOS core and gives access to the powerful instruction set of this widely
used device. EUROPA devices are equipped with ROM, RAM and EEPROM, and
a host of security features to protect device assets, making them suitable for a wide
range of smartcard applications. Some EUROPA devices are also equipped with a
cryptographic coprocessor dedicated to performing the complex mathematical
functions involved in data encryption and authentication applications.
Page 4 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
1.3 CC conformance claim
7 This Security Target is conformant to parts 2 and 3 of the Common Criteria, v2.1,
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) i.e. 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 CC requirements for a Security
Target; in particular, to specify the security requirements and functions, and the
assurance requirements and measures, in accordance with Protection Profile
PP/9806, Smartcard Integrated Circuit v2.0, against which the EUROPA devices
will be evaluated.
1.5 Document Structure
9 Chapter 1 introduces the Security Target, and includes sections on terminology and
references.
10 Chapter 2 provides a description of 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 Chapter 3 describes the TOE security environment.
12 Chapter 4 describes the required security objectives.
13 Chapter 5 describes the TOE security functional requirements.
14 Chapter 6 describes the TOE security assurance requirements.
15 Chapter 7 describes the TOE security functions.
16 Chapter 8 describes the TOE assurance measures.
17 Chapter 9 describes the PP claims.
1.6 Scope and Terminology
18 This document is based on the AT05SC1604R Document [TD].
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 5 of 56
19 The term Target of Evaluation (TOE) is standard CC terminology and refers to the
product being evaluated, the EUROPA AT05SC1604R MCU device in this case.
The TOE is subject to hardware evaluation only. 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].
20 Security objectives are defined herein with labels in the form O.xx_xx. These labels
are used elsewhere for reference. Similarly, threats and assumptions are defined
with labels of the form T.xx_xx and A.xx_xx respectively.
21 Hexadecimal numbers are prefixed by $; for example, $FF is decimal 255. Binary
numbers are prefixed by ‘%’; for example, %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
[TD] AT05SC1604R Technical Data
[THW] EUROPA Test Specification
1.8 Revision History
Rev Date Description
1.0 16 Apr 2001 First release based on first release AT05SC1604R_ST
Rev.1.0.
1.1 01 Feb 2002 Revised to maintain consistency with AT05SC1604R_ST
Rev.1.1.
1.2 22 Feb 2002 Corrected cross-reference in paragraph 34, page 10.
Page 6 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 7 of 56
Chapter 2
TOE Description
22 This part of the ST 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.
2.1 Product type
23 The Target of Evaluation (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 AT05SC1604R device from the EUROPA
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 EUROPA family are centred around Motorola’s M68HC05SC
family of single-chip microcontroller devices. The M68HC05SC family, with
designed-in security features, is based on the industry-standard M68HC05 low-
power HCMOS core and gives access to the powerful instruction set of this widely
used device. Different EUROPA family members offer various options. The
EUROPA family of devices is designed in accordance with the ISO standard for
integrated circuit cards (ISO 7816), where appropriate.
25 Although the TOE evaluation is hardware only, 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.
26 The EEPROM contains both Atmel and customer specific data.
27 The TOE includes security logic comprising detectors which monitor voltage,
frequency and temperature.
28 The TOE is manufactured in a low voltage (3.3V +/- 0.3V) CMOS process. The
device will operate at a supply voltage of 3.0V +/- 10% or 5.0V +/- 10%, with the
internal supply regulated to the required operating voltage.
Page 8 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Figure 2.1 AT05SC1604R Block Diagram
PA0
PORT
A
Interrupt
M68HC05 CPU
÷4, 2 or 1
RESET
CLK
VDD
VSS
DDRA
control
Charge pump
Control logic
RAM
EEPROM oscillator
PLL PA0
Random Number
Generator (RNG)
Security logic
Voltage
Regulator
Test Software
bytes
DPA
Repression
CRC
Time base and Watchdog
User ROM
(including vectors)
User EEPROM
(including control bytes)
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 9 of 56
2.2 Smartcard Product Life-cycle
29 The smartcard product life-cycle comprises 7 phases where the following
authorities are involved:
30 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.
31 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.1 The 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, and 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.
Page 10 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
32 Figure 2.2 describes the Smartcard product life-cycle.
33 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.
34 These procedures shall be compliant with the assumptions [A_DLV] developed in
Section 3.2.2.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 11 of 56
Figure 2.2 Smartcard Product Life Cycle
Smartcard product
Finishing process
Phase 2
IC Design
Development
phase
Phase 1
Production
phase
Smartcard IC
database construction
Pre-personalization data
Embedded software
Phase 3
Phase 4
User
phase
PRODUCT
CONSTRUCTION
IC sensitive information
software, tools (not
IC Dedicated software
IC Photomask
Fabrication
IC Manufacturing
IC Packaging
Testing
Testing
Personalization
Testing
Phase 5
Phase 6
Phase 7
PRODUCT
USAGE
Smartcard product
End-Usage
End of life process
Limits of the ST
Legend:
Trusted delivery and
verification procedures
IC Pre-personalization
requirements
Smartcard embedded software
IC Pre-personalization
requirements (not applicable) hardware only
(not applicable hardware
only)
applicable hardware
only)
Test Libraries
IC Testing and Security
Encoding
Page 12 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
2.3 TOE environment
35 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
36 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.
37 The development begins with the TOE’s specification. All parties in contact with
sensitive information are required to abide by Non-Disclosure Agreements.
38 Design and development of the IC then follows. The design engineer uses
appropriate software tools running on a UNIX operating system with the necessary
password controls to make his schematic entry/RTL descriptions, design
simulations, verifications and generation of the TOE’s IC photomask databases.
Many of the major components of the TOE were designed in East Kilbride,
Scotland. Other components were obtained from Atmel in Rousset, France and
Colorado, USA, and were tailored in East Kilbride to suit the requirements of the
TOE. Sensitive documents, databases on tapes, diskettes, and circuit layout
information are stored in appropriate locked cupboards and safes. Disposal of
unwanted confidential data is carried out by shredding (paper documents) or
complete electronic erasures (electronic documents, databases).
39 Reticles and photomasks are generated from the verified IC database. The reticles
and photomasks are then shipped to the wafer fab processing facilities by means of
a secure carrier.
2.3.2 TOE Production Environment
40 Production starts within the Wafer Fab; here the silicon wafers undergo diffusion
processing in 24-wafer lots. Computer tracking at wafer level throughout the
process is achieved by the WORKSTREAM batch tracking system.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 13 of 56
41 The WORKSTREAM system is an on-line manufacturing tracking system that
monitors the progress of the wafers through the fabrication cycle. After fabrication
the wafers are thinned to a pre-specified thickness, and the TOE is tested to assure
conformance with the device specification. During the IC testing, security encoding
is performed where the control bytes of the EEPROM are programmed with unique
traceability information and customer specified data.
42 The wafers are inked to separate the functional ICs from the non-functional ICs.
2.3.3 TOE User Environment
43 The TOE user environment is the environment of phases 4 to 7.
44 At phases 4, 5, and 6, the TOE user environment is a controlled environment.
45 Following testing and security encoding in phase 3, the wafers are sawn into
individual dies. After the wafers are sawn, the good ICs are assembled into modules
in a module assembly plant.
46 Further testing is carried out followed by the shipment of the modules to the
smartcard product manufacturer (embedder) by means of a secure carrier.
47 Additional testing occurs followed by smartcard personalization, retesting and then
delivery to the smartcard issuer.
End-user environment (phase 7)
48 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.
49 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
50 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.
Page 14 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
2.5 TOE Intended usage
51 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.
52 During the phases 1, 2, 3, the product is being developed and produced. The
administrators are the following:
- the IC designer,
authorized staff who work for the developer, and who design the MCU
(such development staff are trusted and privileged users),
- the IC manufacturer,
authorized staff who work for the developer and who manufacture and test
the MCU (such manufacturing staff are trusted and priviliged users),
- the smartcard dedicated software developer.
authorized staff who work for the developer and who develop the dedicated
test software and crypto libraries (such development staff are trusted and
priviliged users).
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 15 of 56
53 The users of the product during phases 4 to 7 are shown in Table 2.2.
54 The MCU may be used in the following modes:
a) Test mode, in which the MCU runs under the control of 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) 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.
Table 2.2 Users of the Product during Phases 4 to 7
Phase 4 - the packaging manufacturer (administrator),
- the smartcard embedded software developer,
- the system integrator, such as the terminal software developer.
Phase 5 - the smartcard product manufacturer (administrator),
- the smartcard embedded software developer,
- the system integrator, such as the terminal software developer.
Phase 6 - the 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.
- the smartcard issuer (administrator),
- the smartcard embedded software developer,
- the system integrator, such as the terminal software developer.
Phase 7 - the smartcard issuer (administrator),
- the smartcard end-user, who uses devices incorporating the
MCU. End-users are not trusted and may attempt to attack the
MCU.
- the smartcard software developer,
- the 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.
Page 16 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
55 During the initial part of the manufacturing process, the MCU is set to test mode.
Authorized development staff then test the MCU. After testing, test mode is
permanently disabled and the MCU is set to user mode.
56 If a faulty MCU is returned from the field, analysis can be done in user mode only,
because test mode is inhibited prior to devices going to the field.
57 There is no intermediate mode for fault analysis. The only modes of operation are
those stated in paragraph 54.
58 Once manufactured, the MCU operates by executing the smartcard embedded
software stored in ROM. The contents of the 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.
59 The EEPROM includes control bytes, which can be used to store security-related
information such as cryptographic keys. The control bytes cannot be erased in user
mode.
60 One control byte can be programmed in order to prevent read/write/execute access
to (parts of) ROM, RAM and/or EEPROM from EEPROM or RAM.
61 The I/O port is used to pass data to or from the MCU. The application program
determines how to interpret the data.
2.6 General IT features of the TOE
62 The TOE IT (Information Technology) functionalities consist of data storage and
processing such as:
- arithmetical functions (e.g. incrementing counters in electronic purses,
calculating currency conversion in electronic purses...),
- data communication,
- cryptographic operations (e.g. data encryption, digital signature
verification).
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 17 of 56
Chapter 3
TOE Security Environment
63 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
64 Assets are security relevant elements of the TOE that include:
- the application data of the TOE comprising the IC pre-personalization
requirements, such as the ROM options and the control byte data.
- the smartcard embedded software.
- the IC specification, design, development tools and technology.
65 Therefore, the TOE itself is an asset.
66 Assets must be protected in terms of confidentiality, integrity and availability.
3.2 Assumptions
67 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.
68 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.
Page 18 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
3.2.1 Assumptions on phase 1
3.2.2 Assumptions on the TOE delivery process (phases 4 to 7)
69 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 shall be designed in a
secure manner, i.e. 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 (e.g.
source code and any associated documents) and IC
designer proprietary information (tools, software,
documentation.) 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.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.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 19 of 56
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).
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.
Page 20 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
3.3 Threats
70 The TOE as defined in Chapter 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...
71 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)
72 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 and any additional 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 and any additional application
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.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 21 of 56
73 The previous types b and c threats are described hereafter:
3.3.3 Threats on phases 2 to 7
74 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.
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, design and technology,
software and tools if applicable;
T.DIS_DEL Unauthorized disclosure of the smartcard embedded software
and any additional application 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 and any additional application data (such as IC pre-
personalization requirements) during the delivery process to
the IC designer;
T.T_DEL Theft of the smartcard embedded software and any additional
application data (such as IC pre-personalization requirements)
during the delivery process to the IC designer;
Page 22 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Unauthorized disclosure of assets
75 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_DESIGN Unauthorized disclosure of IC design.
This threat covers the unauthorized disclosure of
proprietary elements such as IC specification, IC
design, IC technology detailed information, IC
hardware security mechanisms specifications.
T.DIS_SOFT Unauthorized disclosure of smartcard embedded
software and data such as access control,
authentication system, data protection system,
memory partitioning, cryptographic programs.
T.DIS_DSOFT Unauthorized disclosure of IC dedicated software.
This threat covers the unauthorized disclosure of IC
dedicated software including security mechanisms
specifications and implementation.
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.
This threat covers potential disclosure of IC
development tools and testing tools (analysis tools,
microprobing tools).
T.DIS_PHOTOMASK Unauthorized disclosure of photomask information,
used for photoengraving during the silicon fabrication
process.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 23 of 56
Theft or unauthorized use of assets
76 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
77 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 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.T_SAMPLE Theft or unauthorized use of TOE silicon samples
(e.g. bond out chips...).
T.T_PHOTOMASK Theft or unauthorized use of TOE photomasks.
T.T_PRODUCT Theft or unauthorized use of smartcard products.
T.MOD_DESIGN Unauthorized modification of IC design.
This threat covers the unauthorized modification
of IC specification, IC design including IC
hardware security mechanisms specifications and
realization.
T.MOD_PHOTOMASK Unauthorized modification of TOE photomasks.
T.MOD_DSOFT Unauthorized modification of IC dedicated
software including modification of security
mechanisms.
T.MOD_SOFT Unauthorized modification of smartcard
embedded software and data.
Page 24 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
78 Table 3.1 indicates the relationships between the smartcard phases and the threats.
3.4 Organizational Security Policies
79 An organizational security policy is mandatory for the smartcard product usage.
Nevertheless, no organizational security policy has been defined in the scope of this
ST since their specifications depend essentially on the applications in which the
TOE is incorporated.
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
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 25 of 56
Chapter 4
Security Objectives
80 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
81 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.
O.CLON The TOE functionality needs to be protected from
cloning.
O.OPERATE The TOE must ensure the continued correct
operation of its security functions.
O.FLAW The TOE must not contain flaws in design,
implementation or operation.
O.DIS_MECHANISM The TOE shall ensure that the hardware security
mechanisms are protected against unauthorized
disclosure.
O.DIS_MEMORY The TOE shall ensure that sensitive information
stored in memories is protected against unauthorized
access.
O.MOD_MEMORY The TOE shall ensure that sensitive information
stored in memories is protected against any
corruption or unauthorized modification.
Page 26 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
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 documentations, 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.
It must be ensured that 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 as specified in the smartcard IC
documentation (e.g. sensors,...) [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.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 27 of 56
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 and any other 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 other 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 to 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.
Page 28 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
4.2.3 Objectives on Phase 3 (Manufacturing Phase)
O.TOE_PRT The manufacturing process shall ensure 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
copying, 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.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 29 of 56
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 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 of 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.
Page 30 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
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 confidentiality of sensitive data stored or
handled by the system (terminals, communications....) shall
be maintained.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 31 of 56
Chapter 5
TOE security functional requirements
82 The TOE security functional requirements define the functional requirements for
the TOE using only functional requirements components drawn from the Common
Criteria part 2.
83 The minimum strength of function level for the TOE security requirements is SOF-
high.
5.1 Functional requirements applicable to phase 3 only
(testing phase)
5.1.1 User authentication before any action (FIA_UAU.2)
84 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)
85 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)
86 The TOE security functions shall maintain the following list of security attributes
belonging to individual users: read, write and execute access privileges to ROM,
RAM, EEPROM, and Test Mode Functions in test mode.
5.1.4 TOE Security Functions Testing (FPT_TST.1)
87 The TOE security functions shall run a suite of self tests at the request of the
authorized user, at the conditions in a controlled environment (probe area) to
demonstrate the correct operation of the TOE security functions.
88 The TOE security functions shall provide authorized users with the capability to
verify the integrity of TOE security functions data.
89 The TOE security functions shall provide authorized users with the capability to
verify the integrity of stored TOE security functions executable code.
Page 32 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
5.1.5 Stored Data Integrity Monitoring (FDP_SDI.1)
90 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: pass/fail
signatures from ROM and RAM, and write/read checks of EEPROM in test mode
to verify the integrity of the device memories.
5.2 Functional requirements applicable to phases 3 to 7
5.2.1 Management of Security functions behaviour (FMT_MOF.1)
91 The TOE security functions shall restrict the ability to enable the functions
available in Test Mode to the Test Mode Entry Administrator.
5.2.2 Management of security attributes (FMT_MSA.1)
92 The TOE security functions shall enforce the ACSF_Policy (Access Control
Security Functions Policy) and IFCSF_Policy (Information Flow Control Security
Functions Policy) to restrict the ability to access Test Mode to the Test Mode
Entry Administrator, and restrict the ability to access locked out memory
regions, illegal address regions and illegal opcodes to authorized users.
93 ACFS-Policy
Table 5.1 TEST Mode
Administrator User
ROM Read (Signature) No Access
RAM Read/Write No Access
EEPROM Read/Write* No Access
Test Mode Functions Read/Write No Access
*If Write access to the EEPROM is required, the administrator would need to
execute an appropriate routine in RAM.
Table 5.2 User Mode
Administrator User
ROM No Access Read*
RAM No Access Read/Write*
EEPROM No Access Read/Write*
Test Mode Functions No Access No Access
*Access permitted only if authorized by lock-out
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 33 of 56
94 IFCSF_Policy
5.2.3 Security roles (FMT_SMR.1)
95 The TOE security functions shall maintain the role of Test Mode Entry
Administrator.
96 The TOE security functions shall be able to associate users with roles.
5.2.4 Static Attribute Initialization (FMT_MSA.3)
97 The TOE security functions shall enforce the ACSF_Policy and IFCSF_Policy to
provide restrictive default values for security attributes that are used to enforce the
security functions policy.
98 The TOE security functions shall allow the Test Mode Entry Administrator to
specify alternate initial values to override the default values when an object or
information is created.
5.2.5 Complete Access Control (FDP_ACC.2)
99 The TOE security functions shall enforce the ACSF_Policy (as described in tables
above) on Administrator, User, ROM, RAM, EEPROM, Test Mode Functions, and
all operations among subjects and objects covered by the security functions policy.
Table 5.3 Test Mode
Administrator User
ROM Signature No Data Flow
RAM Read/Write No Data Flow
EEPROM Read/Write* No Data Flow
*If Write information flow to the EEPROM is required, the administrator would
need to execute an appropriate routine in RAM.
Table 5.4 User Mode
Administrator User
ROM No Data Flow Read*
RAM No Data Flow Read/Write*
EEPROM No Data Flow Read/Write*
*Information flow permitted only if authorized by lock-out
Page 34 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
100 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.6 Security Attribute Based Access Control (FDP_ACF.1)
101 The TOE security functions shall enforce the ACSF_Policy to objects based on
Read, Write security attributes.
102 The TOE security functions shall enforce the ACSF_Policy on Administrator, User,
ROM, RAM, EEPROM, Test Mode Functions, and all operations among subjects
and objects covered by the security functions policy.
103 The TOE security functions shall explicitly authorize access of subjects to objects
based on the following additional rules: no additional rules.
104 The TOE security functions shall explicitly deny access of subjects to objects based
on the lockout, illegal address and illegal opcode rules, based on security
attributes, that explicitly deny access of subjects to objects.
5.2.7 Subset Information Flow Control (FDP_IFC.1)
105 The TOE security functions shall enforce the IFCSF_Policy on Administrator,
User and Read, Write and Execute operations that cause controlled
information on flow to and from controlled objects covered by the security
functions policy.
5.2.8 Simple Security Attributes (FDP_IFF.1)
106 The TOE security functions shall enforce the IFCSF_Policy based on the following
types of subject and information security attributes: Signature, Read, Write.
107 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: lockout, illegal address and illegal opcode rules based on security
attributes that explicitly deny information flows.
108 The TOE security functions shall provide no additional information flow control
security functions policy rules.
109 The TOE security functions shall enforce no additional security functions policy
capabilities.
110 The TOE security functions shall explicitly authorize an information flow based on
the following rules: lockout, illegal address and illegal opcode rules based on
security attributes that explicitly authorize information flows.
111 The TOE security functions shall explicitly deny an information flow based on the
following rules: lockout, illegal address and illegal opcode rules based on
security attributes that explicitly deny information flows.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 35 of 56
5.2.9 Potential Violation Analysis (FAU_SAA.1)
112 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.
113 The TOE security functions shall enforce the following rules for monitoring audited
events:
a) Accumulation or combination of abnormal environmental conditions,
access control activity or physical tampering would indicate a potential
security violation.
5.2.10 Unobservability (FPR_UNO.1)
114 The TOE security functions shall ensure that any users are unable to observe the
operation of TOE internal activity on TOE objects by authorized users or subjects.
5.2.11 Notification of Physical Attack (FPT_PHP.2)
115 The TOE shall provide unambiguous detection of physical tampering that might
compromize the TOE security functions.
116 The TOE security functions shall provide the capability to determine whether
physical tampering with the TOE security functions’s devices and elements has
occurred.
117 For values of voltage, clock input frequency and temperature which go outside
acceptable bounds, and for probing, the TOE security functions shall monitor the
devices and elements and notify the authorized user when physical tampering with
the TOE security functions’ devices and elements has occurred.
5.2.12 Resistance to Physical Attack (FPT_PHP.3)
118 The TOE security functions shall resist tampering of voltage, clock input
frequency and temperature to the TOE and its security functions by responding
automatically such that the TOE security policy is not violated.
5.2.13 Cryptographic operation (FCS_COP.1)
119 The TSF shall provide a Random Number Generator to support security operations
performed by cryptographic applications.
Page 36 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 37 of 56
Chapter 6
TOE security assurance requirements
120 The assurance requirement is EAL4 augmented of additional assurance components
listed in the following sections.
121 Some of these components are hierarchical ones to the components specified in
EAL4. The others are required for the maintenance process required for the
EUROPA family.
6.1 ADV_IMP.2 Implementation of the TSF
6.1.1 Developer actions elements
122 The developer shall provide the implementation representation for the entire TSF.
123 Content and presentation of evidence elements:
124 The implementation representation shall unambiguously define the TSF to a level
of detail such that the TSF can be generated without further design decisions.
125 The implementation representation shall describe the relationships between all
portions of the implementation.
126 The implementation representation shall be internally consistent.
6.1.2 Evaluator actions elements
127 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
128 The evaluator shall determine that the implementation representation is an accurate
and complete instantiation of the TOE security functional requirements.
6.2 ALC_DVS.2 Sufficiency of security measures
6.2.1 Developer actions elements
129 The developer shall produce development security documentation.
130 Content and presentation of evidence elements:
Page 38 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
131 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.
132 The development security documentation shall provide evidence that these security
measures are followed during the development and maintenance of the TOE.
133 The evidence shall justify that the security measures provide the necessary level of
protection to maintain the confidentiality and integrity of the TOE.
6.2.2 Evaluator actions elements
134 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
135 The evaluator shall confirm that the security measures are being applied.
6.3 AVA_VLA.4 Highly resistant
6.3.1 Developer actions elements
136 The developer shall perform and document an analysis of the TOE deliverables
searching for ways in which a user can violate the TSP.
137 The developer shall document the disposition of identified vulnerabilities.
138 Content and presentation of evidence elements:
139 The evidence shall show, for all identified vulnerabilities, that the vulnerability
cannot be exploited in the intended environment for the TOE.
140 The documentation shall justify that the TOE, with the identified vulnerabilities, is
resistant to obvious penetration attacks.
141 The evidence shall show that the search for vulnerabilities is systematic.
142 The analysis documentation shall provide a justification that the analysis
completely addresses the TOE deliverables.
6.3.2 Evaluator actions elements
143 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
144 The evaluator shall conduct penetration testing, building on the developer
vulnerability analysis, to ensure the identified vulnerabilities have been addressed.
145 The evaluator shall perform independent vulnerability analysis.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 39 of 56
146 The evaluator shall conduct independent penetration testing, based on the
independent vulnerability analysis, to determine the exploitability of additional
identified vulnerabilities in the intended environment.
147 The evaluator shall determine that the TOE is resistant to penetration attacks
performed by an attacker possessing a high attack potential.
6.4 AMA_AMP.1 Assurance maintenance plan
6.4.1 Developer action elements
148 The developer shall provide an AM Plan.
149 Content and presentation of evidence elements:
150 The AM Plan shall contain or reference a brief description of the TOE, including
the security functionality it provides.
151 The AM Plan shall identify the certified version of the TOE, and shall reference the
evaluation results.
152 The AM Plan shall reference the TOE component categorization report for the
certified version of the TOE.
153 The AM Plan shall define the scope of changes to the TOE that are covered by the
plan.
154 The AM Plan shall describe the TOE life-cycle, and shall identify the current plans
for any new releases of the TOE, together with a brief description of any planned
changes that are likely to have a significant security impact.
155 The AM Plan shall describe the assurance maintenance cycle, stating and justifying
the planned schedule of AM audits and the target date of the next re-evaluation of
the TOE.
156 The AM Plan shall identify the individual(s) who will assume the role of developer
security analyst for the TOE.
157 The AM Plan shall describe how the developer security analyst role will ensure that
the procedures documented or referenced in the AM Plan are followed.
158 The AM Plan shall describe how the developer security analyst role will ensure that
all developer actions involved in the analysis of the security impact of changes
affecting the TOE are performed correctly.
159 The AM Plan shall justify why the identified developer security analyst(s) have
sufficient familiarity with the security target, functional specification and (where
appropriate) high-level design of the TOE, and with the evaluation results and all
applicable assurance requirements for the certified version of the TOE.
Page 40 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
160 The AM Plan shall describe or reference the procedures to be applied to maintain
the assurance in the TOE, which as a minimum shall include the procedures for
configuration management, maintenance of assurance evidence, performance of the
analysis of the security impact of changes affecting the TOE, and flaw remediation.
6.4.2 Evaluator action elements
161 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
162 The evaluator shall confirm that the proposed schedules for AM audits and re-
evaluation of the TOE are acceptable and consistent with the proposed changes to
the TOE.
6.5 AMA_CAT.1 TOE component categorization report
6.5.1 Developer action elements:
163 The developer shall provide a TOE component categorization report for the
certified version of the TOE.
164 Content and presentation of evidence elements:
165 The TOE component categorization report shall categorize each component of the
TOE, identifiable in each TSF representation from the most abstract to the least
abstract, according to its relevance to security; as a minimum, TOE components
must be categorized as one of TSP-enforcing or non-TSP-enforcing.
166 The TOE component categorization report shall describe the categorization scheme
used, so that it can be determined how to categorize new components introduced
into the TOE, and also when to re-categorize existing TOE components following
changes to the TOE or its security target.
167 The TOE component categorization report shall identify any tools used in the
development environment that, if modified, will have an impact on the assurance
that the TOE satisfies its security target.
6.5.2 Evaluator action elements
168 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
169 The evaluator shall confirm that the categorization of TOE components and tools,
and the categorization scheme used, are appropriate and consistent with the
evaluation results for the certified version.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 41 of 56
6.6 AMA_EVD.1 Evidence of assurance maintenance
6.6.1 Developer action elements
170 The developer security analyst shall provide AM documentation for the current
version of the TOE.
171 Content and presentation of evidence elements:
172 The AM documentation shall include a configuration list and a list of identified
vulnerabilities in the TOE.
173 The configuration list shall describe the configuration items that comprise the
current version of the TOE.
174 The AM documentation shall provide evidence that the procedures documented or
referenced in the AM Plan are being followed.
175 The list of identified vulnerabilities in the current version of the TOE shall show,
for each vulnerability, that the vulnerability cannot be exploited in the intended
environment for the TOE.
6.6.2 Evaluator action elements
176 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
177 The evaluator shall confirm that the procedures documented or referenced in the
AM Plan are being followed.
178 The evaluator shall confirm that the security impact analysis for the current version
of the TOE is consistent with the configuration list.
179 The evaluator shall confirm that all changes documented in the security impact
analysis for the current version of the TOE are within the scope of changes covered
by the AM Plan.
180 The evaluator shall confirm that functional testing has been performed on the
current version of the TOE, to a degree commensurate with the level of assurance
being maintained.
6.7 AMA_SIA.2 Security impact analysis
6.7.1 Developer action elements
181 The developer security analyst shall, for the current version of the TOE, provide a
security impact analysis that covers all changes affecting the TOE as compared with
the certified version.
Page 42 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
182 Content and presentation of evidence elements:
183 The security impact analysis shall identify the certified TOE from which the current
version of the TOE was derived.
184 The security impact analysis shall identify all new and modified TOE components
that are categorized as TSP-enforcing.
185 The security impact analysis shall, for each change affecting the security target or
TSF representations, briefly describe the change and any effects it has on lower
representation levels.
186 The security impact analysis shall, for each change affecting the security target or
TSF representations, identify all IT security functions and all TOE components
categorized as TSP-enforcing that are affected by the change.
187 The security impact analysis shall, for each change which results in a modification
of the implementation representation of the TSF or the IT environment, identify the
test evidence that shows, to the required level of assurance, that the TSF continues
to be correctly implemented following the change.
188 The security impact analysis shall, for each applicable assurance requirement in the
configuration management (ACM), life cycle support (ALC), delivery and
operation (ADO) and guidance documents (AGD) assurance classes, identify any
evaluation deliverables that have changed, and provide a brief description of each
change and its impact on assurance.
189 The security impact analysis shall, for each applicable assurance requirement in the
vulnerability assessment (AVA) assurance class, identify which evaluation
deliverables have changed and which have not, and give reasons for the decision
taken as to whether or not to update the deliverable.
6.7.2 Evaluator action elements
190 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
191 The evaluator shall check that the security impact analysis documents all changes
to an appropriate level of detail, together with appropriate justifications that
assurance has been maintained in the current version of the TOE.
6.8 ALC_FLR.1 Flaw remediation
6.8.1 Developer action elements
192 The developer shall document the flaw remediation procedures.
193 Content and presentation of evidence elements:
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 43 of 56
194 The flaw remediation procedures documentation shall describe the procedures used
to track all reported security flaws in each release of the TOE.
195 The flaw remediation procedures shall require that a description of the nature and
effect of each security flaw be provided, as well as the status of finding a correction
to that flaw.
196 The flaw remediation procedures shall require that corrective actions be identified
for each of the security flaws.
197 The flaw remediation procedures documentation shall describe the methods used to
provide flaw information, corrections and guidance on corrective actions to TOE
users.
6.8.2 Evaluator action elements
198 The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
Page 44 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 45 of 56
Chapter 7
TOE security functions
199 This chapter defines the TOE security functions, and Table 7.1 specifies how they
satisfy the TOE security functional requirements.
7.1 Test Mode Entry (SF1)
200 SF1 shall ensure that only authorized users will be permitted to enter Test Mode.
This is provided by multi-level test mode entry conditions that are required to
enable the TOE to enter test mode.
201 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.
202 The Strength of Function claimed for the Test Mode Entry security function is high.
7.2 Access privileges (Read/Write/Execute) (SF2)
203 SF2 shall ensure that only authenticated users can have access
(Read/Write/Execute) privileges to commands in test mode.
204 Only authorized design and production engineers running tests on the TOE will
have access to the TME Code.
7.3 Test mode disable (SF3)
205 SF3 shall make provision for Test Mode Disable which, once activated, shall ensure
that none of the test features are available, not even to authenticated users in test
mode.
7.4 TOE Testing (SF4)
206 Testing of Security Functions is dependent on a fault free and fully functional TOE.
The RAM, ROM, and standard cell logic (including the MCU) are tested by
functional tests under the control of the test interface circuit. The EEPROM is tested
through the test interface circuit by external stimulus. CPU to EEPROM data flow
will also be tested using this method.
Page 46 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
207 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 and logic).
7.5 Data error detection (SF5)
208 SF5 shall provide means for performing data error detection. Means of performing
CRC error detection and parity error detection shall be provided.
7.6 Illegal access and lockout (SF6)
209 SF6 shall enforce access and information flow rights based on the lockout, illegal
address and illegal opcode rules:
210 Lockout
- If a locked out address is accessed, then a chip reset is invoked.
211 Illegal Address
- If an illegal address is accessed, then a chip reset is invoked.
212 Illegal Opcode
- If an attempt is made to execute any opcode that is not implemented in the
instruction set, a chip reset is invoked.
7.7 Event audit (SF7)
213 The TOE shall provide an Event Audit security function (SF7) to enforce the
following rules for monitoring audited events:
a) Accumulation or combination of the following auditable events would
indicate a potential security violation:
1) The external voltage supply or clock signal goes outside acceptable
bounds (SM.VOLT, SM.FREQ).
2) The ambient temperature goes outside acceptable bounds
(SM.TEMP).
3) Application program runaway occurs (SM.WDOG).
4) Attempts to gain illegal access to reserved memory locations
(SM.ILLADD).
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 47 of 56
5) Attempts to probe the device (SM.TAMPER)
6) Attempts to gain illegal access to locked out areas of memory
(SM.LOCKOUT).
7) Attempts to execute an opcode that is not implemented
(SM.OPCODE)
8) Attempts are made to illegally enter device stop mode (SM.STOP)
9) Attempts to illegally access the device EEPROM (SM.EER)
10) Attempts to gain access to Test Mode (SM.TMODE).
7.8 Event action (SF8)
214 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 an immediate reset or a
suspended reset to occur if the violation warrants such action.
7.9 Unobservability (SF9)
215 SF8 shall ensure that users/third parties will have difficulty observing the following
operations on the TOE by the described means.
1) Extracting information, relating to any specific resource or service being
used, by monitoring power consumption
2) Extracting information, relating to any specific resource or service being
used, by carrying out timing analyses on cryptographic functions.
3) Extracting information, relating to any specific resource or service being
used, by using mechanical, electrical or optical means, in order to examine the
topology of the TOE, including address and data buses and regular structures.
7.10 Cryptography (SF10)
216 A Random Number Generator shall be provided to support security operations
performed by cryptographic applications.
Page 48 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Table 7.1 Relationship Between Security Requirements and Security Functions
Security Functions
Test
Mode
Entry
Access
Privileges
Test
Mode
Disable
TOE
Testing
Data
Error
Detection
Illegal
access
and
lockout
Event
Audit
Event
Action
Unobservability
Cryptography
Security
Requirement
SF1
SF2
SF3
SF4
SF5
SF6
SF7
SF8
SF9
SF10
FIA_UAU.2 O1 x
FIA_UID.2 O2 x
FIA_ATD.1 O3 x x x
FPT_TST.1 O4 x x
FDP_SDI.1 O5 x x
FMT_MOF.1 O6 x
FMT_MSA.1 O7 x
FMT_SMR.1 O8 x x x x
FMT_MSA.3 O9 x x x x
FDP_ACC.2 10 x x x x
FDP_ACF.1 11 x x x x
FDP_IFC.1 12 x x x x
FDP_IFF.1 13 x x x x
FAU_SAA.1 14 x
FPR_UNO.1 15 x
FPT_PHP.2 16 x x
FPT_PHP.3 17 x x
FCS_COP.1 18 x
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 49 of 56
Chapter 8
TOE Security Assurance Measures
217 This chapter defines the TOE assurance measures and Table 8.1 specifies how they
satisfy the TOE security assurance requirements.
8.1 Security target (SA1)
218 SA1 shall provide the “EUROPA Security Target” document plus its references.
8.2 Configuration management (SA2)
219 SA2 shall provide the “EUROPA CC Configuration Management (ACM)”
document plus its references.
8.3 Delivery and operation (SA3)
220 SA3 shall provide the “EUROPA CC Delivery and Operation (ADO)” document
plus its references.
8.4 Development Activity (SA4)
221 SA4 shall provide the “EUROPA CC Development Activity (ADV)” document
plus its references.
8.5 Guidance (SA5)
222 SA5 shall provide the “EUROPA CC Guidance (AGD)” document plus its
references.
8.6 Life cycle support (SA6)
223 SA6 shall provide the “EUROPA CC Life Cycle Support (ALC)” document plus its
references.
8.7 Test Activity (SA7)
224 SA7 shall provide the “EUROPA CC Test Activity (ATE)” document plus its
references, and undertaking of testing described therein.
Page 50 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
8.8 Vulnerability Assessment (SA8)
225 SA8 shall provide the “EUROPA CC Vulnerability Assessment (AVA)” document
plus its references, and undertaking of vulnerability assessment described therein.
8.9 Smartcard devices (SA9)
226 SA9 shall provide functional EUROPA smartcard devices.
8.10 Development site (SA10)
227 SA10 shall provide access to development site.
8.11 Test site (SA11)
228 SA11 shall provide access to test site.
8.12 Manufacturing site (SA12)
229 SA12 shall provide access to manufacturing site.
8.13 Sub-contractor sites (SA13)
230 SA13 shall provide access to sub-contractor sites.
8.14 Maintenance process (SA14)
231 SA14 shall provide the “EUROPA CC Maintenance Process (AMA)” document
plus its references.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 51 of 56
Table 8.1 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
Maintenance
Process
Assurance
Requirement
SA1
SA2
SA3
SA4
SA5
SA6
SA7
SA8
SA9
SA10
SA11
SA12
SA13
SA14
ASE_xxx x
ACM_AUT.1 x x x x x
ACM_CAP.4 x x x x x
ACM_SCP.2 x x x x x
ADO_DEL.2 x x x x x
ADO_IGS.1 x x x x x
ADV_FSP.2 x
ADV_HLD.2 x
ADV_IMP.2 x
ADV_LLD.1 x
ADV_RCR.1 x
ADV_SPM.1 x
AGD_ADM.1 x
AGD_USR.1 x
ALC_DVS.2 x x x x x
ALC_FLR.1 x x
ALC_LCD.1 x x x x x
ALC_TAT.1 x x x x x
ATE_COV.2 x x x
ATE_DPT.1 x x x
ATE_FUN.1 x x x
ATE_IND.2 x x x
AVA_MSU.2 x x
AVA_SOF.1 x x
AVA_VLA.4 x x
AMA_AMP.1 x
AMA_CAT.1 x
AMA_EVD.1 x
AMA_SIA.2 x
Page 52 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 53 of 56
Chapter 9
PP claims
9.1 PP reference
232 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.
9.2 PP refinements
233 None.
9.3 PP additions
9.3.1 Cryptographic capability
234 The security function to satisfy the FCS_COP.1 requirement is SF10 and is
specified in Chapter 7 of this Security Target.
9.3.2 Maintenance process
235 In addition to conforming to PP/9806, this Security Target specifies additional
security assurance requirements to cover a maintenance process. This maintenance
process is necessary because family derivatives of the EUROPA AT05SC1604R
TOE will be evaluated under the Common Criteria maintenance scheme.
236 The additional security assurance requirements are specified in Chapter 6 of this
Security Target and consist of AMA_AMP.1, AMA_CAT.1, AMA_EVD.1,
AMA_SIA.2, and ALC_FLR.1.
237 The assurance measure to satisfy these requirements is SA14 and is specified in
Chapter 8 of this Security Target.
Page 54 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Annex A
Glossary
Control Bytes
Reserved bytes of EEPROM that can be programmed with traceability information.
IC Dedicated Software
IC Proprietary software which is required for testing purposes and to implement
special functions. This includes embedded test software and additional test
programmes which are run from outside of the IC.
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.
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
Page 55 of 56
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 is not applicable in the case of the TOE since it is a
hardware evaluation only.
Smartcard Embedded Software Developer
Institution (or its agent) responsible for the smartcard embedded software
development and the specification of pre-personalization requirements.
Smartcard Issuer
Institution (or its agent) responsible for the smartcard product delivery to the
smartcard end-user.
Smartcard Product Manufacturer
Institution (or its agent) responsible for the smartcard product finishing process and
testing.
UNIX
Interactive Time Sharing Operating System.
WORKSTREAM
Manufacturing VAX based Batch Tracking System.
Page 56 of 56
AT05SC1604R_ST-Lite Rev. 1.2 (22 Feb 02)
56
Abbreviations
CPU Central Processor Unit
EEPROM Electrically Erasable Programmable ROM
HCMOS High Speed Complementary Metal Oxide Semiconductor
IC Integrated Circuit
I/O Input/Output
IT Information Technology
ITSEC Information Technology Security Evaluation Criteria
MCU Microcontroller Unit
PLL Phase Locked Loop
RAM Random Access Memory
RNG Random Number Generator
ROM Read Only Memory
TME Test Mode Entry
TOE Target of Evaluation
TSF TOE Security Function(s)
TSP TOE Security Policy