General Business Use
AT90SC9608RC_ST_Lite_V1.0 (31 Jul 03)
AT90SC9608RC Security Target Lite
Matthieu Robert (0335164)
Important notice to readers…
Atmel makes no warranty for the use of its products, other than those expressly contained in the Company’s standard warranty which
is detailed in Atmel’s Terms and Conditions located on the Company’s web site. The Company assumes no responsibility for any errors
which may appear in this document, reserves the right to change devices or specifications detailed herein at any time without notice,
and does not make any commitment to update the information contained herein. No licenses to patents or other intellectual property
of Atmel are granted by the Company in connection with the sale of Atmel products, expressly or by implication. Atmel’s products are
not authorized for use as critical components in life support devices or systems.
The security of any system in which the product is used will depend on the system’s security as a whole. Where security or
cryptography features are mentioned in this document this refers to features which are intended to increase the security of the product
under normal use and in normal circumstances.
All products are sold subject to Atmel’s Terms & Conditions of Supply and the provisions of any agreements made between Atmel and
the Customer. In ordering a product covered by this document the Customer agrees to be bound by those Terms & Conditions and
agreements and nothing contained in this document constitutes or forms part of a contract (with the exception of the contents of this
Notice). A copy of Atmel’s Terms & Conditions of Supply is available on request.
 Atmel Corporation 2003
(31 Jul 03) General Business Use 3 of 64
AT90SC9608RC_ST_Lite_V1.0
Contents
Section 1 AT90SC9608RC 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..................................................................... 15
2.3 TOE Environment ...................................................................................... 17
2.4 TOE Logical Phases .................................................................................. 18
2.5 TOE Intended Usage ................................................................................. 19
2.6 General IT Features of the TOE ................................................................ 21
Section 3 TOE Security Environment ........................................................................ 23
3.1 Assets ........................................................................................................ 23
3.2 Assumptions .............................................................................................. 23
3.3 Threats....................................................................................................... 25
3.4 Organizational Security Policies ................................................................ 29
Section 4 Security Objectives.................................................................................... 31
4.1 Security Objectives for the TOE................................................................. 31
4.2 Security Objectives for the Environment.................................................... 34
Matthieu Robert (0335164)
4 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Section 5 TOE Security Functional Requirements .................................................... 39
5.1 Functional Requirements Applicable to Phase 3 Only
(Testing Phase) .........................................................................................39
5.2 Functional Requirements Applicable to Phases 3 to 7 ..............................41
5.3 TOE Security Assurance Requirements ....................................................46
Section 6 TOE Summary Specification...................................................................... 49
6.1 TOE Security Functions.............................................................................49
6.2 TOE Assurance Measures.........................................................................55
Section 7 Protection Profile Claims ........................................................................... 59
7.1 Protection Profile Reference......................................................................59
7.2 Protection Profile Refinements ..................................................................59
7.3 Protection Profile Additions........................................................................59
Appendix A Glossary..................................................................................................... 61
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 5 of 98
AT90SC9608RC_ST_Lite_V1.0
Figures
Figure 2-1 AT90SC9608RC Block Diagram.......................................................................14
Figure 2-2 Smartcard Product Life Cycle ...........................................................................16
Matthieu Robert (0335164)
Ariel Security Target Lite
6 of 98 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 7 of 64
AT90SC9608RC_ST_Lite_V1.0
Tables
Table 2-1 Smartcard Product Life-cycle...................................................................... 15
Table 2-2 Phases 4 to 7 Product Users ...................................................................... 20
Table 3-1 Threats and Phases.................................................................................... 28
Table 5-1 IFCSF-Policy............................................................................................... 44
Table 6-1 Relationship Between Security Requirements and Security Functions ...... 54
Table 6-2 Relationship Between Assurance Requirements and Measures ................ 57
Matthieu Robert (0335164)
Ariel Security Target Lite
8 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 9 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 1
AT90SC9608RC Security Target Lite
1.1 Identification
1 Title: AT90SC9608RC Security Target Lite [ST_Lite]
2 This Security Target Lite has been constructed with Common Criteria (CC) Version 2.1.
1.2 Overview
3 This Security Target Lite [ST_Lite] 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 AVR ASL4 and the
‘parent’ device of the family, from which other family members will be derived, is the
AT90SC19264RC.
4 The AT90SC9608RC MCU device (AT578A7 Rev D) is being evaluated against the CC
Smartcard Integrated Circuit Protection Profile PP/9806 to Evaluation Assurance Level
4 (EAL4) augmented of AVA_VLA.4 under the Common Criteria maintenance scheme.
Atmel Smart Card ICs, a division of ATMEL Corporation, is the developer and the
sponsor for the AVR ASL4 evaluations.
5 The devices in the AVR 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. AVR ASL4 devices are equipped
with Flash, RAM, ROM and EEPROM, cryptographic coprocessors, and a host of
security features to protect device assets, making them suitable for a wide range of
smartcard applications.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
10 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
1.3 Common Criteria Conformance Claim
6 This Security Target Lite is conformant to parts 2 and 3 of the Common Criteria, V2.1,
as follows:
n Part 2 conformant: the security functional requirements are based on those
identified in part 2 of the Common Criteria.
n Part 3 augmented conformant: the security assurance requirements, including
those used in the augmentation, are based on those in part 3 of the Common
Criteria.
1.4 Document Objective
7 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, against which the AVR ASL4 devices will
be evaluated.
1.5 Document Structure
8 Section 1 introduces the Security Target Lite and includes sections on terminology and
references.
9 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.
10 Section 3 describes the TOE security environment.
11 Section 4 describes the required security objectives.
12 Section 5 describes the TOE security functional requirements and the security
assurance requirements.
13 Section 6 describes the TOE security functions.
14 Section 7 describes the Protection Profile (PP) claims
15 Appendix A provides a glossary of terms and abbreviations.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
(31 Jul 03) General Business Use 11 of 64
AT90SC9608RC_ST_Lite_V1.0
1.6 Scope and Terminology
16 This document is based on the AT90SC9608RC Technical Data Sheet [TD].
17 The term Target of Evaluation (TOE) is standard CC terminology and refers to the
product being evaluated, the AT90SC9608RC AT90SC9608RC 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].
18 Security objectives are defined herein with labels in the form O.xx_xx. These labels are
used elsewhere for reference. Similarly, threats, assumptions and organizational
security policy are defined with labels of the form T.xx_xx, A.xx_xx, and P.xx_xx
respectively.
19 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
20 The following list refers to the latest revision of the documents. Contact your local Atmel
Sales office for further information.
[SOF] AT90SC9608RC Strength of Security Functions Analysis
[STI] Standard Test Interface
[TD] AT90SC9608RC Technical Data (1581)
[TestROMDD] AT90SC9608RC Engineering Evaluation Test Software
Detailed Description
[TestROMUG] AT90SC9608RC Engineering ROM - User Guide
[TMRE2] AT90SC9608RC Test Software Specification - Test Description
[TMR-USER] Test Software Specification - User Guide
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
12 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
1.8 Revision History
Rev Date Description Originator
1.0 31 Jul 03 Initial release. Based on
AT90SC19264RC_ST_Lite_V1.0
Atmel, EKB
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 13 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 2
Target of Evaluation Description
21 This part of the Security Target Lite [ST_Lite] 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
22 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 AT90SC9608RC device (AT578A7 Rev D) from the AVR 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 Lite.
23 The devices in the AVR 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 AVR
ASL4 family members offer various options. The AVR ASL4 family of devices are
designed in accordance with the ISO standard for integrated circuit cards (ISO 7816),
where appropriate.
24 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.
25 The EEPROM contains both Atmel and customer specific data.
26 The TOE includes security logic comprising detectors which monitor voltage, frequency
and temperature.
27 The TOE is equipped with logic peripherals including 2 timers, 2 serial ports, an
ISO7816 interface and an ISO7816 controller.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
14 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Figure 2-1 AT90SC9608RC Block Diagram
28 The embedded software for the AT90SC9608RC device comprises AVR ROM and
EEPROM data, and SC16 crypto ROM data.
AVR CPU
SC16 Crypto CPU
Memories and Peripherals FireWall
User EEPROM
(incl. OTP)
User ROM
Crypto ROM
Library
User RAM
CLK
Interrupt
Controller
ISO Port 1 I/O 1
I/O 0
RSTN
GND
VDD
Random Number
Generator
Test Structures
ISO Port 0
ISO7816
Controller
Checksum
Accelerator
DES/TDES
Controller
CRC-16 Controller
Watchdog
Timers
Security and
Control Logic
Power
Management
SPA/DPA
Repression
VFO
Clock Generator
% 2/3/4/8
Reset Controller
Voltage
Regulator
Crypto RAM
Scrambling
Key Fuses
Charge Pump
Charge Pump
Oscillator
GF(2
<
n)
Matthieu Robert (0335164)
Target of Evaluation Description
(31 Jul 03) General Business Use 15 of 64
AT90SC9608RC_ST_Lite_V1.0
2.2 Smartcard Product Life-cycle
29 The smartcard product life-cycle consists of 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 this document.
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 document.
Table 2-1 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:
n IC manufacturing
n IC testing
n 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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
16 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
32 Figure 2-2 describes the Smartcard product life-cycle.
Figure 2-2 Smartcard Product Life Cycle
Legend
Limits of the
development cycle
Trusted delivery and
verification procedures
Embedded software
Pre-personalization data
(not applicable hardware only)
IC sensitive information
software, tools (not
applicable hardware only)
Test Libraries
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
Personalization
Testing
Smartcard Product End-Usage
End of Life Process
IC Design IC Dedicated Software
IC Personalization requirements Smartcard embedded software (not applicable) hardware only
IC Personalization requirements
Testing
Phase 7
Phase 6
Phase 5
Phase 3
Phase 2
Phase 1
Phase 4
IC Personalization requirements
Product
Construction
Product
Usage
Matthieu Robert (0335164)
Target of Evaluation Description
(31 Jul 03) General Business Use 17 of 64
AT90SC9608RC_ST_Lite_V1.0
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:
n Intermediate delivery of the TOE or the TOE under construction within a phase
n 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.
2.3 TOE Environment
35 Considering the TOE, three types of environments are defined:
n Development environment corresponding to phase 2
n Production environment corresponding to phase 3
n 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 security staff. 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 securely to the wafer fab processing facilities.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
18 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
2.3.2 TOE Production Environment
40 Production starts within the ATMEL NTS Wafer Fab (England, UK); here the silicon
wafers undergo diffusion processing in 25-wafer lots. Computer tracking at wafer level
throughout the process is achieved by the FACTORYworks based batch tracking
system.
41 The FACTORYworks system is an on-line manufacturing tracking system which
monitors the progress of the wafers through the fabrication cycle. After fabrication the
wafers are sent to ATMEL EKB (Scotland, UK) where they are thinned to a
pre-specified thickness and tested. ATMEL EKB test the TOE 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.
42 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.
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 the sawing step, the wafers are split into individual dies. 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.
Matthieu Robert (0335164)
Target of Evaluation Description
(31 Jul 03) General Business Use 19 of 64
AT90SC9608RC_ST_Lite_V1.0
2.5 TOE Intended Usage
51 The TOE can be incorporated in several applications such as:
n Banking and finance market for credit/debit cards, electronic purse (stored value
cards) and electronic commerce.
n 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).
n Transport and ticketing market (access control cards).
n Governmental cards (ID-cards, healthcards, driver license etc).
n 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:
n The IC designer:
Authorized staff who work for the developer, and who design the MCU (such
development staff are trusted and privileged users).
n 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).
n 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).
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
20 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
53 Table 2-2 lists the users of the product during phases 4 to 7.
Table 2-2 Phases 4 to 7 Product Users
54 The MCU may be used in the following modes:
a) 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) 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.
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.
Phase 4 n Packaging manufacturer (administrator)
n Smartcard embedded software developer
n System integrator, such as the terminal software developer
Phase 5 n Smartcard product manufacturer (administrator)
n Smartcard embedded software developer
n System integrator, such as the terminal software developer
Phase 6 n Personalizer (administrator)
n 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.
n Smartcard issuer (administrator).
n Smartcard embedded software developer.
n System integrator, such as the terminal software developer.
Phase 7 n Smartcard issuer (administrator)
n Smartcard end-user, who use devices incorporating the MCU.
End-users are not trusted and may attempt to attack the MCU.
n Smartcard software developer.
n 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
Matthieu Robert (0335164)
Target of Evaluation Description
(31 Jul 03) General Business Use 21 of 64
AT90SC9608RC_ST_Lite_V1.0
56 If a faulty MCU is returned from the field then analysis can only be done in User mode
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, which is stored in AVR ROM. The contents of the AVR 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 OTP bytes, which can be used to store security-related
information such as cryptographic keys. The OTP bytes cannot be erased in User
mode.
60 The FireWall (Memories and Peripherals Protection Unit) allows the smartcard
embedded software to prevent read/write/execute access to (parts of) AVR ROM,
EEPROM, RAM, Crypto ROM and peripherals from EEPROM.
61 The ISO7816 compliant I/O ports can be 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 functionalities consist of data storage and processing such as:
n Arithmetic functions (e.g. incrementing counters in electronic purses, calculating
currency conversion in electronic purses)
n Data communication
n Cryptographic operations (e.g. data encryption, digital signature verification)
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
22 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 23 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 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:
n Application data of the TOE comprising the IC pre-personalization requirements,
such as the AVR ROM, EEPROM, the Crypto ROM and OTP contents.
n Smartcard embedded software
n 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:
n Due to the definition of the TOE limits, any assumption for the smartcard software
development (phase 1 is outside the scope of the TOE)
n 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:
n Assumptions on phase 1
n Assumptions on the TOE delivery process (phases 4 to 7)
n Assumptions on phases 4-5-6
n Assumptions on phase 7
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
24 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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.
3.2.3 Assumptions on Phases 4 to 6
3.2.4 Assumptions on Phase 7
A.SOFT_ARCHI The smartcard embedded software 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 (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.
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.
Matthieu Robert (0335164)
TOE Security Environment
(31 Jul 03) General Business Use 25 of 64
AT90SC9608RC_ST_Lite_V1.0
3.3 Threats
70 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.
71 Threats have to be split in:
n Threats against which specific protection within the TOE is required (class I),
n 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:
n Unauthorized disclosure
n Modification or theft of the smartcard embedded software and any additional
data at phase 1.
73 Considering the limits of the TOE, these previous threats are outside the scope of this
document.
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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
26 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
74 The previous types b and c threats are described hereafter.
3.3.3 Threats on Phases 2 to 7
75 During these phases, the assumed threats could be described in three types:
n Unauthorized disclosure of assets
n Theft or unauthorized use of assets
n Unauthorized modification of assets
Unauthorized disclosure of assets
76 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, 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.
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.
Matthieu Robert (0335164)
TOE Security Environment
(31 Jul 03) General Business Use 27 of 64
AT90SC9608RC_ST_Lite_V1.0
Theft or unauthorized use of assets
77 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
78 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.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.
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.
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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
28 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
79 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
Matthieu Robert (0335164)
TOE Security Environment
(31 Jul 03) General Business Use 29 of 64
AT90SC9608RC_ST_Lite_V1.0
3.4 Organizational Security Policies
80 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.
81 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 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, AES, RSA, MACs, and Digital Signatures, 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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
30 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 31 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 4
Security Objectives
82 The security objectives of the TOE cover principally the following aspects:
n Integrity and confidentiality of assets
n Protection of the TOE and associated documentation during development and
production phases
4.1 Security Objectives for the TOE
83 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)
on the device external interfaces (for example clock, supply,
I/O lines) that could be used to disclose confidential data, as
well as forced information leakage caused by induced
malfunction or physical manipulation
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
32 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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.
Matthieu Robert (0335164)
Security Objectives
(31 Jul 03) General Business Use 33 of 64
AT90SC9608RC_ST_Lite_V1.0
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 Cryptographic capability shall be available for users to
maintain integrity and confidentiality of sensitive data.
The TOE must provide hardware implementation of some
cryptographic algorithms that can be used by the embedded
software in conjunction with appropriate counter-measure to
achieve cryptographic operations (for instance encryption,
decryption, integrity checking, signature, key generation, for
algorithms such as DES, TDES, RSA, SHA-1, DSA, Elliptic
Curves, ...).
These cryptographic operations are used for instance to
support establishment and control of a trusted channel
between the TOE and the outside environment, or protect
confidential data stored in the TOE memories.
The TOE must also provide random number generation and
ensure the cryptographic quality of random number
generation. For example, random numbers shall not be
predictable and shall have a sufficient entropy.
The TOE must 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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
34 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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:
n Tools are only delivered to the parties authorized
personnel.
n 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 Lite, 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.
Matthieu Robert (0335164)
Security Objectives
(31 Jul 03) General Business Use 35 of 64
AT90SC9608RC_ST_Lite_V1.0
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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
36 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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:
n TOE manufacturing data (to prevent any possible copy,
modification, retention, theft or unauthorized use).
n 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:
n Packaging and storage.
n Traceability.
n Storage and protection of manufacturing process
specific assets (such as manufacturing process
documentation, further data, or samples)
n Access control and audit to tests, analysis tools,
laboratories, and databases.
n 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.
Matthieu Robert (0335164)
Security Objectives
(31 Jul 03) General Business Use 37 of 64
AT90SC9608RC_ST_Lite_V1.0
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:
n Non-disclosure of any security relevant information.
n Identification of the elements under delivery.
n Meet confidentiality rules (confidentiality level,
transmittal form, reception acknowledgement).
n Physical protection to prevent external damage.
n Secure storage and handling procedures are
applicable for all TOEs (including rejected TOEs).
n Traceability of TOE during delivery including the
following parameters:
n Origin and shipment details
n Reception, reception acknowledgement
n 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.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
38 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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.
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 39 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 5
TOE Security Functional Requirements
84 The TOE security functional requirements define the functional requirements for the
TOE using only functional requirements components drawn from the Common Criteria
part 2.
85 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)
86 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)
87 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)
88 The TOE security functions shall maintain the following list of security attributes
belonging to individual users:
n Test mode access right
n Read, write fuses access rights
n Read AVR ROM access right
n Write AVR ROM access right
n Execute AVR ROM access right
n Read EEPROM access right
n Write EEPROM access right
n Execute EEPROM access right
n Read Crypto ROM access right
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
40 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
n Write Crypto ROM access right
n Execute Crypto ROM access right
n Read RAM access right
n Write RAM access right
n Execute RAM access right
n Read access right to peripherals and IO registers
n Write access right to peripherals and IO registers
n Execute access right to peripherals and IO registers
5.1.4 TOE Security Functions Testing (FPT_TST.1)
89 The TOE security functions shall:
n Run a suite of self tests at the request of the authorized user to demonstrate the
correct operation of the TOE security functions
n Provide authorized users with the capability to verify the integrity of TOE security
functions data
n 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)
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:
n Test signatures from AVR ROM
n Test signatures and hardware test of RAM
n Test signatures from Crypto ROM
n Test signatures of EEPROM
Matthieu Robert (0335164)
TOE Security Functional Requirements
(31 Jul 03) General Business Use 41 of 64
AT90SC9608RC_ST_Lite_V1.0
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:
n Enable the functions available in Test mode to the Test Mode Entry (TME)
administrator
n Restrict the ability to disable the functions available in Test mode to the TME
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 the security attributes to TME administrator and
Firewall supervisor/non-supervisor modes.
5.2.3 Security Roles (FMT_SMR.1)
93 The TOE security functions shall:
n Maintain the role of TME administrator
n Maintain the role of Firewall supervisor/non-supervisor modes
n Be able to associate users with roles
5.2.4 Static Attribute Initialization (FMT_MSA.3)
94 The TOE security functions shall:
n Enforce the ACSF_Policy and IFCSF_Policy to provide restrictive default values
for security attributes that are used to enforce the security functions policy
n Allow the TME administrator to specify alternate initial values to override the
default values when an object or information is created
Note
The ACSF_Policy is not described in this document. See Table 5-1 for further
information on the IFCSF_Policy.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
42 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
5.2.5 Complete Access Control (FDP_ACC.2)
95 The TOE security functions shall enforce the ACSF_Policy on:
n TME administrator, Firewall supervisor/non-supervisor modes.
n AVR ROM, EEPROM, RAM, Crypto ROM, peripheral and IO registers.
n And all operations among subjects and objects covered by the security functions
policy.
96 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)
97 The TOE security functions shall enforce the ACSF_Policy to objects based on:
n Read AVR ROM access right
n Write AVR ROM access right
n Execute AVR ROM access right
n Read EEPROM access right
n Write EEPROM access right
n Execute EEPROM access right
n Read Crypto ROM access right
n Write Crypto ROM access right
n Execute Crypto ROM access right
n Read RAM access right
n Write RAM access right
n Execute RAM access right
n Read peripheral and IO registers access right
n Write peripheral and IO registers access right
n Execute peripheral and IO registers access right
98 The TOE security functions shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed.
Firewall rules, that are not disclosed in this ST-Lite document.
The TOE security functions shall explicitly authorize access of subjects to objects
based on the following additional rules: no additional rules.
Matthieu Robert (0335164)
TOE Security Functional Requirements
(31 Jul 03) General Business Use 43 of 64
AT90SC9608RC_ST_Lite_V1.0
5.2.7 Subset Information Flow Control (FDP_IFC.1)
99 The TOE security functions shall enforce the IFCSF_Policy on TME administrator, test
commands and test operations that cause controlled information to flow between the:
n AVR ROM and the TME administrator
n EEPROM and the TME administrator
n Crypto ROM and the TME administrator
n RAM and the TME administrator
n Peripheral and IO registers and the TME administrator
5.2.8 Simple Security Attributes (FDP_IFF.1)
100 The TOE security functions shall enforce the IFCSF_Policy based on the following
types of subject and information security attributes: test command syntax.
101 The TOE security functions shall:
n Permit an information flow between a controlled subject and controlled information
via a controlled operation if the following rules hold: test command syntax rules.
n Provide no additional information flow control security functions policy rules.
n Enforce no additional security functions policy capabilities.
102 The TOE security functions shall explicitly authorize an information flow based on the
following rules:
103 Test command syntax rules, based on test command syntax, that explicitly authorize
information flows between TME administrator and:
n AVR ROM
n EEPROM
n Crypto ROM
n RAM
n Peripheral and IO registers
104 The TOE security functions shall explicitly deny an information flow based on the
following rules:
105 Test command syntax rules, based on test command syntax, that explicitly deny
information flows between TME administrator and:
n AVR ROM
n EEPROM
n Crypto ROM
n RAM
n Peripheral and IO registers
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
44 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
IFCSF-Policy
5.2.9 Potential Violation Analysis (FAU_SAA.1)
106 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.
107 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.
5.2.10 Unobservability (FPR_UNO.1)
108 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.
Table 5-1 IFCSF-Policy
Rules Test command syntax rules
Attribute Test command syntax
TME Administrator Data flow (1)
(1) All information about possible data flow and Test command
syntax can be found in [STI], [TMR-USER], [TestROMUG],
[TestROMDD] and [TMRE2].
Matthieu Robert (0335164)
TOE Security Functional Requirements
(31 Jul 03) General Business Use 45 of 64
AT90SC9608RC_ST_Lite_V1.0
5.2.11 Notification of Physical Attack (FPT_PHP.2)
109 The TOE security functions shall provide:
n Unambiguous detection of physical tampering that might compromise the TOE
security functions.
n The capability to determine whether physical tampering with the TOE security
functions’s devices or TOE security functions’s elements has occurred.
110 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 Firewall-supervisor
when physical tampering with the TOE security functions’ devices or TOE security
functions’ elements has occurred.
5.2.12 Resistance to Physical Attack (FPT_PHP.3)
111 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.13 Cryptographic Operation (FCS_COP.1)
112 The TSF shall perform hardware data encryption and decryption in accordance with
the:
n DES cryptographic algorithm using 56-bit cryptographic key sizes that meets the
Data Encryption Standard (DES), FIPS PUB 46-3, 25th October, 1999.
n 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.
n Hardware data hash and signature in accordance with the SHA-1 cryptographic
algorithm using no cryptographic key that meets the Secure Hash Standard, FIPS
PUB 180-1, 17th April, 1995.
113 The TSF shall perform hardware data encryption and decryption in accordance with
the:
n RSA without CRT cryptographic algorithm using 512-bit, 1024-bit, 2048-bit
cryptographic key sizes that meets no standard.
n RSA with CRT cryptographic algorithm using 512-bit, 1024-bit, 2048-bit
cryptographic key sizes that meets no standard
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
46 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
5.2.14 Cryptographic Key Generation (FCS_CKM.1)
114 The TSF shall generate cryptographic keys in accordance with cryptographic key
generation algorithm Miller-Rabin algorithm with confidence criteria (t) between 0 and
255 and specified cryptographic key sizes 512-bit, 1024-bit, 2048-bit (respectively 2
primes of 256 bits, 512 bits and 1024 bits) that meet the NIST special publication 800-2,
April 1991.
5.3 TOE Security Assurance Requirements
115 The assurance requirement is EAL4 augmented of additional assurance components
listed in the following sections.
116 Some of these components are hierarchical ones to the components specified in EAL4.
117 All the components are drawn from Common Criteria Part 3, V2.1.
5.3.1 ADV_IMP.2 Implementation of the TSF
Developer actions elements
118 The developer shall provide the implementation representation for the entire TOE
security functions.
Content and presentation of evidence elements
119 The implementation representation shall:
n Unambiguously define the TOE security functions to a level of detail such that the
TOE security functions can be generated without further design decisions
n Be internally consistent
n Describe the relationships between all portions of the implementation
Evaluator actions elements
120 The evaluator shall:
n Confirm that the information provided meets all requirements for content and
presentation of evidence.
n Determine that the implementation representation is an accurate and complete
instantiation of the TOE security functional requirements.
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 47 of 64
AT90SC9608RC_ST_Lite_V1.0
5.3.2 ALC_DVS.2 Sufficiency of Security Measures
Developer actions elements
121 The developer shall produce development security documentation.
Content and presentation of evidence elements
122 The development security documentation shall:
n 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.
n Provide evidence that these security measures are followed during the
development and maintenance of the TOE.
123 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
124 The evaluator shall confirm that the:
n Information provided meets all requirements for content and presentation of
evidence
n Security measures are being applied
5.3.3 AVA_VLA.4 Highly Resistant
Developer actions elements
125 The developer shall:
n Perform and document an analysis of the TOE deliverables searching for ways in
which a user can violate the TOE security policy
n Document the disposition of identified vulnerabilities
Content and presentation of evidence elements
126 The documentation shall:
n Show, for all identified vulnerabilities, that the vulnerability cannot be exploited in
the intended environment for the TOE.
n Justify that the TOE, with the identified vulnerabilities, is resistant to obvious
penetration attacks.
127 The evidence shall show that the search for vulnerabilities is systematic.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
48 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
128 The analysis documentation shall provide a justification that the analysis completely
addresses the TOE deliverables.
Evaluator actions elements
129 The evaluator shall:
n Confirm that the information provided meets all requirements for content and
presentation of evidence
n Conduct penetration testing, building on the developer vulnerability analysis, to
ensure the identified vulnerabilities have been addressed.
n Perform independent vulnerability analysis
n Perform independent penetration testing, based on the independent vulnerability
analysis, to determine the exploitability of additional identified vulnerabilities in the
intended environment.
n Determine that the TOE is resistant to penetration attacks performed by an
attacker possessing a high attack potential.
130
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 49 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 6
TOE Summary Specification
131 This section defines the TOE security functions, and Figure 6-1 on page 54 specifies
how they satisfy the TOE security functional requirements.
6.1 TOE Security Functions
6.1.1 Test Mode Entry (SF1)
132 SF1 shall ensure that only authorized users shall be permitted to enter Test mode. This
is provided by Test Mode Entry conditions that are required to enable the TOE to enter
Test mode.
133 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.
134 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.
135 The Strength of Function claimed for the Test Mode Entry security function is high.
6.1.2 Protected Test Memory Access (SF2)
136 SF2 shall ensure that, although authenticated users can have access to memories
using commands in Test mode, they cannot access directly their contents.
137 Only authorized design and production engineers running test on the TOE will have
access to the TME conditions.
138 The Strength of Function claimed for the Protected Test Memory Access security
function is high.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
50 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
6.1.3 Test Mode Disable (SF3)
139 SF3 shall make provision for Test Mode Disable master fuses which, once blown, shall
ensure that none of the test features are available, not even to authenticated users in
Test mode.
6.1.4 TOE Testing (SF4)
140 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.
141 Testing of Security Functions is dependent on a fault free and fully functional TOE. The
RAM, ROM and standard cell logic (including the MCU) is tested by functional tests
under the control of the test interface circuit. EEPROM is tested through the test
interface circuit by external stimulus. CPU to EEPROM data flow will also be tested by
functional tests, run from the EEPROM, using test software loaded under the control of
the test interface circuit.
142 To conform with ISO 7816 standards the TOE embedded software will always return an
Anwer-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)
143 SF5 shall provide means for performing data error detection.
144 Means of performing checksum error detection and parity error detection is provided.
The 32-bit Checksum Accelerator or the CRC-16 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.
Matthieu Robert (0335164)
TOE Summary Specification
(31 Jul 03) General Business Use 51 of 64
AT90SC9608RC_ST_Lite_V1.0
6.1.6 FireWall (SF6)
145 SF6 shall enforce access control based on the FireWall rules as defined in the
ACSF_Policy:
Memory protection
n The FireWall defines different modes to execute embedded software (supervisor /
non-supervisor).
n The different modes provide restricted access privilege to the memories, and to
the MCU peripheral registers. In case of illegal accesses performed by the
embedded software, a security action is invoked.
Illegal Address
n If an illegal address is accessed, then a security action is invoked.
Illegal Opcode
n If an attempt is made to execute any opcode that is not implemented in the
instruction set, a security action is invoked.
6.1.7 Event Audit (SF7)
146 The TOE shall provide an Event Audit security function (SF7) to enforce the following
rules for monitoring audited events:
Accumulation or combination of the following auditable events would indicate a
potential security violation:
1. The external voltage supply goes outside acceptable bounds.
2. The external clock signal goes outside acceptable bounds.
3. The ambient temperature goes outside acceptable bounds.
4. Application program abnormal runaway.
5. Attempts to physically probe the device.
6. Attempts to gain illegal access to reserved RAM memory locations.
7. Attempts to gain illegal access to reserved EEPROM memory locations.
8. Attempts to gain illegal access to reserved peripheral or IO register locations.
9. Attempts to execute instruction to read the program memory from the
non-supervisor program location,
10. Attempts to move the RAM stack to an illegal RAM memory location.
11. Attempts to execute an AVR opcode that is not implemented.
12. Attempts to illegally write access the device’s EEPROM.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
52 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
13. Attempts to gain illegal access to supervisor modes.
14. The exposition to UV light goes outside acceptable bounds.
147 These events are audited by IO register bits or other hardware mechanisms accessible
to the embedded software.
The Strength of Function claimed for the Event audit security function is high.
6.1.8 Event Action (SF8)
148 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 the violation
warrants such action:
n Memory wiping actions
n Different levels of immediate resets
n Different levels of security interrupts
149 Event Action depends on the type of Event (see [TD] for more information).
6.1.9 Unobservability (SF9)
150 SF9 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,
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.
151 The Strength of Function claimed for the Unobservability security function is high.
Matthieu Robert (0335164)
TOE Summary Specification
(31 Jul 03) General Business Use 53 of 64
AT90SC9608RC_ST_Lite_V1.0
6.1.10 Cryptography (SF10)
152 The TSF shall provide a cryptographic algorithm to be able to transmit and receive
objects in a manner protected from data retrieval or modification.
153 The TSF shall provide hardware DES, TDES data encryption/decryption capability, and
SHA-1 data signing capability. The TSF shall also provide hardware RSA without CRT
(i.e. modular exponentiation) data encryption/decryption capability, as well as RSA with
CRT data encryption/decryption capability.
154 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.
155 The TSF shall provide a 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.
156 The TSF shall provide RSA cryptographic key generation capability using Miller Rabin
algorithm with confidence criteria (t parameter) between 0 and 255.
157 An assessment of the strength of the:
n DES algorithm does not form part of the evaluation
n TDES algorithm does not form part of the evaluation
n SHA-1 algorithm does not form part of the evaluation
n RSA without CRT algorithm does not form part of the evaluation
n RSA with CRT algorithm does not form part of the evaluation
n Miller Rabin algorithm does not form part of the evaluation
158 The TSF shall also provide cryptographic primitives to ease the customer proprietary
software implementation of these algorithms (multiply, square, ...) as well as DSA and
EC-DSA data signature in the AVR embedded software. As the TOE does not include
any embedded software, these cryptographic primitives are out of its scope.
6.1.11 Security Functions Based on Permutations/Combinations
159 The description of the security functions using permutations and/or combination
properties is not disclosed in this document.
160 Further details on these mechanisms and on the Strength of Function Analysis
performed by ATMEL can be found in [SOF].
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
54 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Table 6-1 Relationship Between Security Requirements and Security Functions
Security Functions
Test
Mode
Entry
Protected
Test
Memory
Access
Test
Mode
Disable
TOE
Testing
Data
Error
Detection
FireWall
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 x
FPT_TST.1 O4 x x x x x
FDP_SDI.1 O5 x x
FMT_MOF.1 O6 x x
FMT_MSA.1 O7 x x x
FMT_SMR.1 O8 x x x
FMT_MSA.3 O9 x x x x
FDP_ACC.2 O10 x x
FDP_ACF.1 O11 x x
FDP_IFC.1 O12 x x
FDP_IFF.1 O13 x x
FAU_SAA.1 O14 x
FPR_UNO.1 O15 x
FPT_PHP.2 O16 x x
FPT_PHP.3 O17 x x
FCS_COP.1 O18 x
FCS_CKM.1 O19 x
Matthieu Robert (0335164)
TOE Summary Specification
(31 Jul 03) General Business Use 55 of 64
AT90SC9608RC_ST_Lite_V1.0
6.2 TOE Assurance Measures
161 This section defines the TOE assurance measures and Table 6-2 specifies how they
satisfy the TOE security assurance requirements.
6.2.1 Security Target (SA1)
162 SA1 shall provide the “AT90SC9608RC Security Target” document plus its references.
6.2.2 Configuration Management (SA2)
163 SA2 shall provide the “AT90SC9608RC CC Configuration Management (ACM)”
interface document plus its references.
6.2.3 Delivery and Operation (SA3)
164 SA3 shall provide the “AT90SC9608RC CC Delivery and Operation (ADO)” interface
document plus its references.
6.2.4 Development Activity (SA4)
165 SA4 shall provide the “AT90SC9608RC CC Development Activity (ADV)” interface
document plus its references.
6.2.5 Guidance (SA5)
166 SA5 shall provide the “AT90SC9608RC CC Guidance (AGD)” interface document plus
its references.
6.2.6 Life Cycle Support (SA6)
167 SA6 shall provide the “AT90SC9608RC CC Life Cycle Support (ALC)” interface
document plus its references.
6.2.7 Test Activity (SA7)
168 SA7 shall provide the “AT90SC9608RC CC Test Activity (ATE)” interface document
plus its references, and undertaking of testing described therein.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
56 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
6.2.8 Vulnerability Assessment (SA8)
169 SA8 shall provide the “AT90SC9608RC CC Vulnerability Assessment (AVA)” interface
document plus its references, and undertaking of vulnerability assessment described
therein.
6.2.9 Smartcard Devices (SA9)
170 SA9 shall provide functional AT90SC9608RC smartcard devices.
6.2.10 Development Site (SA10)
171 SA10 shall provide access to development site.
6.2.11 Test Site (SA11)
172 SA11 shall provide access to test site.
6.2.12 Manufacturing Site (SA12)
173 SA12 shall provide access to manufacturing site.
6.2.13 Sub-contractor Sites (SA13)
174 SA13 shall provide access to sub-contractor sites.
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 57 of 64
AT90SC9608RC_ST_Lite_V1.0
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.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_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
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
58 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 59 of 64
AT90SC9608RC_ST_Lite_V1.0
Section 7
Protection Profile Claims
7.1 Protection Profile Reference
175 This Security Target Lite 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 Protection Profile Refinements
176 None.
7.3 Protection Profile Additions
7.3.1 Cryptographic Capability
177 In addition to conforming to PP/9806, this Security Target Lite specifies an additional
Organizational Security Policy P.CRYPTO in Section 3.4, and an additional Security
Objective for the TOE O. CRYPTO in Section 4.1.
178 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.
179 The security function to satisfy the FCS_COP.1 and FCS_CKM.1 requirements is SF10
and is specified in Section 6.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
60 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
(31 Jul 03) General Business Use 61 of 64
AT90SC9608RC_ST_Lite_V1.0
Appendix A
Glossary
A.1 Terms
CRC-16 Algorithm used to compute powerful checksum on
memory blocks
FACTORYworks Manufacturing Unix based batch Tracking System.
HASH Transformation of a string of characters into a usually
shorter fixed length value or key that represents the
original string.
IC Dedicated Software IC Proprietary software which is required for testing
purposes and to implement special functions. For
AT90SC9608RC 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.
Integrated Circuit (IC) Electronic component(s) designed to perform
processing and/or memory functions.
MARCH Y Algorithm which tests for stuck at, transition, coupling
and address faults in a memory.
Personalizer Institution (or its agent) responsible for the smartcard
personalization and final testing.
Smartcard A credit sized plastic card which has a non volatile
memory and a processing unit embedded within it.
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
62 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
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.
Matthieu Robert (0335164)
Glossary
(31 Jul 03) General Business Use 63 of 64
AT90SC9608RC_ST_Lite_V1.0
A.2 Abbreviations
ACSF Access Control Security Functions
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
EKB East Kilbride
HCMOS High Speed Complementary Metal Oxide Semiconductor
I/O Input/Output
IC Integrated Circuit
IFCSF Information Flow Control Security Functions
ISO International Standards Organization
MCU Microcontroller
NTS North Tyneside
OTP One Time Programmable
PP Protection Profile
RAM Random-Access Memory
RISC Reduced Instruction Set Core
RNG Random Number Generator
ROM Read-Only Memory
SPA Simple Power Analysis
TD Technical Data
TME Test Mode Entry
TOE Target of Evaluation
VFO Variable Frequency Oscillator
Matthieu Robert (0335164)
AT90SC9608RC Security Target Lite
64 of 64 General Business Use (31 Jul 03)
AT90SC9608RC_ST_Lite_V1.0
Matthieu Robert (0335164)
Matthieu Robert (0335164)
Printed on recycled paper.
© Atmel Corporation 2003.
Atmel Corporation 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.
Atmel Headquarters Atmel Operations
Corporate Headquarters
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 441-0311
FAX 1(408) 487-2600
Europe
Atmel Sarl
Route des Arsenaux 41
Casa Postale 80
CH-1705 Fribourg
Switzerland
TEL (41) 26-426-5555
FAX (41) 26-426-5500
Asia
Atmel Asia, Ltd.
Room 1219
Chinachem Golden Plaza
77 Mody Road Tsimhatsui
East Kowloon
Hong Kong
TEL (852) 2721-9778
FAX (852) 2722-1369
Japan
Atmel Japan K.K.
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
Atmel Corporate
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 436-4270
FAX 1(408) 436-4314
Microcontrollers
Atmel Corporate
2325 Orchard Parkway
San Jose, CA 95131
TEL 1(408) 436-4270
FAX 1(408) 436-4314
Atmel Nantes
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
Atmel Rousset
Zone Industrielle
13106 Rousset Cedex, France
TEL (33) 4-42-53-60-00
FAX (33) 4-42-53-60-01
Atmel Colorado Springs
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906
TEL 1(719) 576-3300
FAX 1(719) 540-1759
Atmel Smart Card ICs
Scottish Enterprise Technology Park
Maxwell Building
East Kilbride G75 0QR, Scotland
TEL (44) 1355-803-000
FAX (44) 1355-242-743
RF/Automotive
Atmel Heilbronn
Theresienstrasse 2
Postfach 3535
74025 Heilbronn, Germany
TEL (49) 71-31-67-0
FAX (49) 71-31-67-2340
Atmel Colorado Springs
1150 East Cheyenne Mtn. Blvd.
Colorado Springs, CO 80906
TEL 1(719) 576-3300
FAX 1(719) 540-1759
Biometrics/Imaging/Hi-Rel MPU/
High Speed Converters/RF Datacom
Atmel Grenoble
Avenue de Rochepleine
BP 123
38521 Saint-Egreve Cedex, France
TEL (33) 4-76-58-30-00
FAX (33) 4-76-58-34-80
e-mail
literature@atmel.com
Web Site
http://www.atmel.com
ATMEL®
is the registered trademark of Atmel.
FACTORYworks®
is the registered trademark of Brooks Automation Inc. Other terms and product names
may be the trademarks of others.
Ariel_ST_Lite–(31 Jul 03)
Matthieu Robert (0335164)