STMicroelectronics
ST23YS64C
Security Target -
Public Version
Common Criteria for IT security
evaluation
SMD_ST23YS64_ST_11_002 Rev 01.00
September 2011
BLANK
September 2011 SMD_ST23YS64_ST_11_002 Rev 01.00 1/45
ST23YS64C
Security Target - Public Version
Common Criteria for IT security evaluation
1 Introduction
1.1 Security Target reference
1 Document identification: ST23YS64C SECURITY TARGET - PUBLIC VERSION.
2 Version number: V01.00, issued September 2011.
3 Registration: registered at ST Microelectronics under number
SMD_ST23YS64_ST_11_002_V01.00.
1.2 Purpose
4 This document presents the ST23YS64C Security Target - Public version (ST) of Security
Integrated Circuits (ICs), with its Dedicated Software (DSW), designed on the ST23
platform of STMicroelectronics.
5 This document is a sanitized version of the Security Target used for the evaluation. It is
classified as public information.
6 The precise reference of the Target of Evaluation (TOE) and the security IC features are
given in Section 3: ST23YS64C TOE description.
7 A glossary of terms and abbreviations used in this document is given in Appendix A:
Glossary
www.st.com
Contents ST23YS64C Security Target - Public Version
2/45 SMD_ST23YS64_ST_11_002
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Security Target reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 ST23YS64C TOE description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 TOE overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 TOE life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 TOE environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 TOE development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 TOE production environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 TOE operational environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Conformance claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Common Criteria conformance claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 PP Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 PP Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 PP Refinements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3 PP Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4 PP Claims rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Security problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 Description of assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Organisational security policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 Security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Security objectives for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Security objectives for the environment . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3 Security objectives rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1 TOE threat "Memory Access Violation" . . . . . . . . . . . . . . . . . . . . . . . . . 20
ST23YS64C Security Target - Public Version Contents
SMD_ST23YS64_ST_11_002 3/45
6.3.2 Organisational security policy "Additional Specific Security Functionality"
20
7 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1 Security functional requirements for the TOE . . . . . . . . . . . . . . . . . . . . . . 22
7.1.1 Limited fault tolerance (FRU_FLT.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1.2 Failure with preservation of secure state (FPT_FLS.1) . . . . . . . . . . . . . 23
7.1.3 Limited capabilities (FMT_LIM.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1.4 Limited availability (FMT_LIM.2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.5 Audit storage (FAU_SAS.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1.6 Resistance to physical attack (FPT_PHP.3) . . . . . . . . . . . . . . . . . . . . . . 24
7.1.7 Basic internal transfer protection (FDP_ITT.1) . . . . . . . . . . . . . . . . . . . . 24
7.1.8 Basic internal TSF data transfer protection (FPT_ITT.1) . . . . . . . . . . . . 24
7.1.9 Subset information flow control (FDP_IFC.1) . . . . . . . . . . . . . . . . . . . . 24
7.1.10 Random number generation (FCS_RNG.1) . . . . . . . . . . . . . . . . . . . . . . 25
7.1.11 Cryptographic operation (FCS_COP.1) . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1.12 Static attribute initialisation (FMT_MSA.3) . . . . . . . . . . . . . . . . . . . . . . . 25
7.1.13 Management of security attributes (FMT_MSA.1) . . . . . . . . . . . . . . . . . 25
7.1.14 Complete access control (FDP_ACC.2) . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1.15 Security attribute based access control (FDP_ACF.1) . . . . . . . . . . . . . . 26
7.2 TOE security assurance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3 Refinement of the security assurance requirements . . . . . . . . . . . . . . . . 27
7.3.1 Refinement regarding functional specification (ADV_FSP) . . . . . . . . . . 28
7.3.2 Refinement regarding test coverage (ATE_COV) . . . . . . . . . . . . . . . . . 29
7.4 Security Requirements rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.4.1 Rationale for the Security Functional Requirements . . . . . . . . . . . . . . . 29
7.4.2 Additional security objectives are suitably addressed . . . . . . . . . . . . . . 30
7.4.3 Additional security requirements are consistent . . . . . . . . . . . . . . . . . . 30
7.4.4 Dependencies of Security Functional Requirements . . . . . . . . . . . . . . . 31
7.4.5 Rationale for the Assurance Requirements . . . . . . . . . . . . . . . . . . . . . . 32
8 TOE summary specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1 Statement of TOE security functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.1 TSF_INIT_A: Hardware initialisation & TOE attribute initialisation . . . . 33
8.1.2 TSF_CONFIG_A: TOE configuration switching and control . . . . . . . . . 33
8.1.3 TSF_INT_A: TOE logical integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.4 TSF_TEST_A: Test of the TOE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Contents ST23YS64C Security Target - Public Version
4/45 SMD_ST23YS64_ST_11_002
8.1.5 TSF_FWL_A: Memory Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1.6 TSF_PHT_A: Physical tampering protection . . . . . . . . . . . . . . . . . . . . . 34
8.1.7 TSF_ADMINIS_A: Security violation administrator . . . . . . . . . . . . . . . . 34
8.1.8 TSF_OBS_A: Unobservability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1.9 TSF_SKCS_A: Symmetric Key Cryptography Support . . . . . . . . . . . . . 35
8.1.10 TSF_ALEAS_A: Unpredictable Number Generation Support . . . . . . . . 35
8.2 TOE summary specification rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2.1 TSF rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix A Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.1 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ST23YS64C Security Target - Public Version List of tables
SMD_ST23YS64_ST_11_002 5/45
List of tables
Table 1. TOE product identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 2. Composite product life cycle phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 3. Summary of security environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 4. Summary of security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 5. Security Objectives versus Assumptions, Threats or Policies . . . . . . . . . . . . . . . . . . . . . . 20
Table 6. Summary of functional security requirements for the TOE . . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 7. FCS_COP.1 iterations (cryptographic operations) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Table 8. TOE security assurance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 9. Impact of EAL5 selection on BSI-PP-0035 refinements . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 10. Dependencies of security functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 11. Mapping of TSF services and SFRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 12. List of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 13. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
List of figures ST23YS64C Security Target - Public Version
6/45 SMD_ST23YS64_ST_11_002
List of figures
Figure 1. ST23YS64C block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
ST23YS64C Security Target - Public Version Context
SMD_ST23YS64_ST_11_002 7/45
2 Context
8 The Target of Evaluation (TOE) referred in Section 3: ST23YS64C TOE description, is
evaluated under the French IT Security Evaluation and Certification Scheme and is
developed by the Secure Microcontrollers Division of STMicroelectronics (ST).
9 The assurance level of the performed Common Criteria (CC) IT Security Evaluation is EAL 5
augmented.
10 The intent of this Security Target is to specify the Security Functional Requirements (SFRs)
and Security Assurance Requirements (SARs) applicable to the ST23YS64C security IC,
and to summarise its chosen TSF services and assurance measures.
11 This ST claims to be an instantiation of the "Security IC Platform Protection Profile" (PP)
registered and certified under the reference BSI-PP-0035 in the German IT Security
Evaluation and Certification Scheme, with the following augmentations:
● Addition #1: “Support of Cipher Schemes” from AUG
● Addition #4: "Area based Memory Access Control" from AUG
The original text of this PP is typeset as indicated here, its augmentations from AUG as
indicated here, when they are reproduced in this document.
12 Extensions introduced in this ST to the SFRs of the Protection Profile (PP) are exclusively
drawn from the Common Criteria part 2 standard SFRs.
13 This ST makes various refinements to the above mentioned PP and AUG. They are all
properly identified in the text typeset as indicated here. The original text of the PP is
repeated as scarcely as possible in this document for reading convenience. All PP identifiers
have been however prefixed by their respective origin label: BSI for BSI-PP-0035, AUG1 for
Addition #1 of AUG and AUG4 for Addition #4 of AUG.
ST23YS64C TOE description ST23YS64C Security Target - Public Version
8/45 SMD_ST23YS64_ST_11_002
3 ST23YS64C TOE description
3.1 TOE overview
14 The Target of Evaluation (TOE) is the ST23YS64C, a Smartcard IC with enhanced security,
and 64 Kbytes EEPROM.
15 The ST23YS64C is a commercial derivative of the already certified ST23YL80C.
Table 1. TOE product identification
16 The TOE is a serial access IC based on the enhanced 8/16-bit ST23 CPU core. Operations
are synchronized with an internally generated clock issued by the Clock Generator module.
The internal speed of the device is fully software programmable. High performance can be
reached by using high speed internal clock frequency (up to 29 MHz). The CPU interfaces
with the on-chip RAM, ROM and EEPROM memories via an internal bus offering 16MBytes
of linear addressing space, protected by the memory protection unit (MPU) without
performance loss.
17 The CPU includes the Arithmetic Logic Unit (ALU) and the control logic.
This device includes a flexible memory protection unit (MPU), which enables a fully dynamic
memory segmentation and protection without downgrading the CPU performance. The MPU
enables the software to control the addressable space and registers available to any given
program, thanks to a flexible and software-friendly interface. As a result, the MPU allows the
software developers to enforce a wide range of memory protection policies.
The Enhanced DES accelerator (EDES) enables Cipher Block Chaining (CBC), fast DES
and triple DES computation. This module provides a protection against side channel
attacks.
This device also includes a True Random Number Generator (TRNG) compliant with P2
class of AIS-31 standard.
18 In a few words, the ST23YS64C offers a unique combination of high performances and very
powerful features for high level security:
● Die integrity,
● Monitoring of environmental parameters,
● Protection mechanisms against faults,
● Hardware Security Enhanced DES accelerator,
● AIS-31 class P2 compliant True Random Number Generator,
● ISO 3309 CRC calculation block,
● Memory Protection Unit,
● EDES accelerator.
19 The TOE includes in the ST protected ROM a Dedicated Software which provides full test
capabilities (operating system for test, called "OST"), not accessible by the Security IC
Embedded SoftWare (SICESW), after delivery.
Commercial
name
Maskset
Product
version
OST name OST version
ST23YS64 K2K0 C AIC 34h
ST23YS64C Security Target - Public Version ST23YS64C TOE description
SMD_ST23YS64_ST_11_002 9/45
20 In addition, the ROM of the tested samples contains an operating system called "Card
Manager" that allows the evaluators to use a set of commands with the I/O, and to load in
EEPROM (or in RAM) test software.
21 Figure 1 provides a overview of the ST23YS64C.
Figure 1. ST23YS64C block diagram
3.2 TOE life cycle
22 This Security Target is fully conform to the claimed PP. In the following, just a summary and
some useful explanations are given. For complete details on the TOE life cycle, please refer
to the Security IC Platform Protection Profile (BSI-PP-0035), section 1.2.3.
23 The composite product life cycle is decomposed into 7 phases. Each of these phases has
the very same boundaries as those defined in the claimed protection profile.
24 The life cycle phases are summarized in Table 2.
25 The limit of the evaluation corresponds to phases 2, 3, including the delivery and verification
procedures of phase 1, and the TOE delivery to the IC packaging manufacturer ;
procedures corresponding to phases 1, 4, 5, 6 and 7 are outside the scope of this
evaluation.
ST23YS64C TOE description ST23YS64C Security Target - Public Version
10/45 SMD_ST23YS64_ST_11_002
26 In the following, the term "TOE delivery" is uniquely used to indicate after phase 3 (or before
phase 4). The TOE is delivered after phase 3, in USER configuration.
3.3 TOE environment
27 Considering the TOE, three types of environments are defined:
● Development environment corresponding to phase 2,
● Production environment corresponding to phase 3,
● Operational environment, including phase 1 and from phase 4 to phase 7.
3.3.1 TOE development environment
28 To ensure security, the environment in which the development takes place is secured with
controllable accesses having traceability. Furthermore, all authorised personnel involved
fully understand the importance and the strict implementation of defined security
procedures.
29 The development begins with the TOE's specification. All parties in contact with sensitive
information are required to abide by Non-Disclosure Agreements.
30 Design and development of the IC then follows, together with the dedicated and engineering
software and tools development. The engineers use secure computer systems (preventing
unauthorised access) to make their developments, simulations, verifications and generation
of the TOE's databases. Sensitive documents, files and tools, databases on tapes, and
printed circuit layout information are stored in appropriate locked cupboards/safe. Of
Table 2. Composite product life cycle phases
Phase Name Description Responsible party
1
IC embedded software
development
Security IC embedded software
development
IC embedded software
developer
2 IC development
IC design
IC dedicated software development
IC developer: ST
3 IC manufacturing
integration and photomask fabrication
IC production
IC testing
preparation
pre-personalisation
IC manufacturer: ST or
GLOBAL FOUNDRIES
4 IC packaging
security IC packaging (and testing)
pre-personalisation if necessary
IC packaging
manufacturer
5
Composite product
integration
composite product finishing process
composite product preparation
composite product shipping
Composite product
integrator
6 Personalisation
composite product personalisation
composite product testing
Personaliser
7 Operational usage
composite product usage by its
issuers and consumers
End-consumer
ST23YS64C Security Target - Public Version ST23YS64C TOE description
SMD_ST23YS64_ST_11_002 11/45
paramount importance also is the disposal of unwanted data (complete electronic erasures)
and documents (e.g. shredding).
31 The development centres involved in the development of the TOE are the following: ST
ROUSSET (FRANCE) and ST ANG MO KIO (SINGAPORE), for the design activities, ST ROUSSET
(FRANCE), for the engineering activities, ST ROUSSET (FRANCE) for the software development
activities.
32 Reticules and photomasks are generated from the verified IC databases; the former are
used in the silicon Wafer-fab processing. As reticules and photomasks are generated off-
site, they are transported and worked on in a secure environment with accountability and
traceability of all (good and bad) products. During the transfer of sensitive data
electronically, procedures are established to ensure that the data arrive only at the
destination and are not accessible at intermediate stages (e.g. stored on a buffer server
where system administrators make backup copies).
33 The authorized sub-contractors involved in the TOE mask manufacturing can be DNP
(JAPAN) and DPE (ITALY).
3.3.2 TOE production environment
34 As high volumes of product commonly go through such environments, adequate control
procedures are necessary to account for all product at all stages of production.
35 Production starts within the Wafer-fab; here the silicon wafers undergo the diffusion
processing. Computer tracking at wafer level throughout the process is commonplace. The
wafers are then taken into the test area. Testing of each TOE occurs to assure conformance
with the device specification. The wafers are then delivered for assembly onto the composite
products.
36 The authorized front-end plant involved in the manufacturing of the TOE can be ST ROUSSET
(FRANCE) or GLOBAL FOUNDRIES FAB 2 & 6 (SINGAPORE).
37 The authorized EWS plant involved in the testing of the TOE can be ST ROUSSET (FRANCE)
or ST TOA PAYOH (SINGAPORE).
38 Wafers are then scribed and broken such as to separate the functional from the non-
functional ICs. The latter is discarded in a controlled accountable manner. The good ICs are
then packaged in phase 4. When testing, programming or deliveries are done offsite, ICs
are transported and worked on in a secure environment with accountability and traceability
of all (good and bad) products.
39 The other sites that can be involved during the production of the TOE are ST LOYANG
(SINGAPORE) for the logistics, and ST SHENZEN (CHINA) for the wafers backlap.
3.3.3 TOE operational environment
40 A TOE operational environment is the environment of phases 1, then 4 to 7.
41 At phases 1, 4, 5 and 6, the TOE operational environment is a controlled environment.
42 End-user environments (phase 7): composite products are used in a wide range of
applications to assure authorised conditional access. Examples of such are pay-TV, banking
cards, portable communication SIM cards, health cards, transportation cards, identity and
passport cards. The end-user environment therefore covers a wide range of very different
functions, thus making it difficult to avoid and monitor any abuse of the TOE.
Conformance claims ST23YS64C Security Target - Public Version
12/45 SMD_ST23YS64_ST_11_002
4 Conformance claims
4.1 Common Criteria conformance claims
43 The ST23YS64C Security Target claims to be conformant to the Common Criteria version
3.1.
44 Furthermore it claims to be CC Part2 (CCMB-2009-07-002) extended and CC Part 3
(CCMB-2009-07-003) conformant. The extended Security Functional Requirements are
those defined in the Security IC Platform Protection Profile (BSI-PP-0035).
45 The assurance level for the ST23YS64C Security Target is EAL 5 augmented by
ALC_DVS.2 and AVA_VAN.5.
4.2 PP Claims
4.2.1 PP Reference
46 The ST23YS64C Security Target claims strict conformance to the Security IC Platform
Protection Profile (BSI-PP-0035), as required by this Protection Profile.
4.2.2 PP Refinements
47 The main refinements operated on the BSI-PP-0035 are:
● Addition #1:“Support of Cipher Schemes”from AUG,
● Addition #4:"Area based Memory Access Control"from AUG,
● Refinement of assurance requirements.
48 All refinements are indicated with type setting text as indicated here, original text from the
BSI-PP-0035 being typeset as indicated here. Text originating in AUG is typeset as indicated
here.
4.2.3 PP Additions
49 The security environment additions relative to the PP are summarized in Table 3.
50 The additional security objectives relative to the PP are summarized in Table 4.
51 A simplified presentation of the TOE Security Policy (TSP) is added.
52 The additional SFRs for the TOE relative to the PP are summarized in Table 6.
53 The additional SARs relative to the PP are summarized in Table 8.
4.2.4 PP Claims rationale
54 The differences between this Security Target security objectives and requirements and
those of BSI-PP-0035, to which conformance is claimed, have been identified and justified
in Section 6 and in Section 7. They have been recalled in the previous section.
55 In the following, the statements of the security problem definition, the security objectives,
and the security requirements are consistent with those of the BSI-PP-0035.
ST23YS64C Security Target - Public Version Conformance claims
SMD_ST23YS64_ST_11_002 13/45
56 The security problem definition presented in Section 5, clearly shows the additions to the
security problem statement of the PP.
57 The security objectives rationale presented in Section 6.3 clearly identifies modifications
and additions made to the rationale presented in the BSI-PP-0035.
58 Similarly, the security requirements rationale presented in Section 7.4 has been updated
with respect to the protection profile.
59 All PP requirements have been shown to be satisfied in the extended set of requirements
whose completeness, consistency and soundness has been argued in the rationale sections
of the present document.
Security problem definition ST23YS64C Security Target - Public Version
14/45 SMD_ST23YS64_ST_11_002
5 Security problem definition
60 This section describes the security aspects of the environment in which the TOE is intended
to be used and addresses the description of the assets to be protected, the threats, the
organisational security policies and the assumptions.
61 This Security Target being fully conform to the claimed PP, in the following, just a summary
and some useful explanations are given. For complete details on the security problem
definition please refer to the Security IC Platform Protection Profile (BSI-PP-0035), section
3.
62 A summary of all these security aspects and their respective conditions is provided in
Table 3.
5.1 Description of assets
63 The assets (related to standard functionality) to be protected are
● the User Data,
● the Security IC Embedded Software, stored and in operation
● the security services provided by the TOE for the Security IC Embedded Software.
64 The user (consumer) of the TOE places value upon the assets related to high-level security
concerns:
SC1 integrity of User Data and of the Security IC Embedded Software (while being
executed/processed and while being stored in the TOE's memories),
SC2 confidentiality of User Data and of the Security IC Embedded Software (while being
processed and while being stored in the TOE's memories)
SC3 correct operation of the security services provided by the TOE for the Security IC
Embedded Software.
65 According to the Protection Profile there is the following high-level security concern related to
security service:
SC4 deficiency of random numbers.
66 To be able to protect these assets the TOE shall protect its security functionality. Therefore
critical information about the TOE shall be protected. Critical information includes:
● logical design data, physical design data, IC Dedicated Software, and configuration
data,
● Initialisation Data and Pre-personalisation Data, specific development aids, test and
characterisation related data, material for software development support, and
photomasks.
Such information and the ability to perform manipulations assist in threatening the above
assets.
ST23YS64C Security Target - Public Version Security problem definition
SMD_ST23YS64_ST_11_002 15/45
67 The information and material produced and/or processed by ST in the TOE development
and production environment (Phases 2 up to TOE delivery) can be grouped as follows:
● logical design data,
● physical design data,
● IC Dedicated Software, Security IC Embedded Software, Initialisation Data and pre-
personalisation Data,
● specific development aids,
● test and characterisation related data,
● material for software development support, and
● photomasks and products in any form
as long as they are generated, stored, or processed by ST.
5.2 Threats
68 The threats are described in the BSI-PP-0035, section 3.2. Only those originating in AUG
are detailed in the following section.
Table 3. Summary of security environment
Label Title
TOE
threats
BSI.T.Leak-Inherent Inherent Information Leakage
BSI.T.Phys-Probing Physical Probing
BSI.T.Malfunction Malfunction due to Environmental Stress
BSI.T.Phys-Manipulation Physical Manipulation
BSI.T.Leak-Forced Forced Information Leakage
BSI.T.Abuse-Func Abuse of Functionality
BSI.T.RND Deficiency of Random Numbers
AUG4.T.Mem-Access Memory Access Violation
OSPs
BSI.P.Process-TOE Protection during TOE Development and Production
AUG1.P.Add Functions Additional Specific Security Functionality (Cipher Scheme
Support)
Assumptions
BSI.A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation
BSI.A.Plat-Appl Usage of Hardware Platform
BSI.A.Resp-Appl Treatment of User Data
BSI.T.Leak-Inherent Inherent Information Leakage
BSI.T.Phys-Probing Physical Probing
BSI.T.Malfunction Malfunction due to Environmental Stress
BSI.T.Phys-Manipulation Physical Manipulation
BSI.T.Leak-Forced Forced Information Leakage
BSI.T.Abuse-Func Abuse of Functionality
Security problem definition ST23YS64C Security Target - Public Version
16/45 SMD_ST23YS64_ST_11_002
5.3 Organisational security policies
69 The TOE provides specific security functionality that can be used by the Security IC
Embedded Software. In the following specific security functionality is listed which is not
derived from threats identified for the TOE’s environment because it can only be decided in
the context of the Security IC application, against which threats the Security IC Embedded
Software will use the specific security functionality.
70 ST applies the policy Protection during TOE Development and Production (BSI.P.Process-
TOE) as specified below.
71 ST applies the policy Additional Specific Security Functionality (AUG1.P.Add Functions) as
specified below.
72 No other Organisational Security Policy (OSP) has been defined in this ST since their
specifications depend heavily on the applications in which the TOE will be integrated. The
Security Targets for the applications embedded in this TOE should further define them.
BSI.T.RND Deficiency of Random Numbers
AUG4.T.Mem-Access Memory Access Violation:
Parts of the Security IC Embedded Software may cause security violations
by accidentally or deliberately accessing restricted data (which may include
code). Any restrictions are defined by the security policy of the specific
application context and must be implemented by the Security IC
Embedded Software.
Clarification: This threat does not address the proper definition and
management of the security rules implemented by the Security IC
Embedded Software, this being a software design and correctness issue.
This threat addresses the reliability of the abstract machine targeted by the
software implementation. To avert the threat, the set of access rules
provided by this TOE should be undefeated if operated according to the
provided guidance. The threat is not realized if the Security IC Embedded
Software is designed or implemented to grant access to restricted
information. It is realized if an implemented access denial is granted under
unexpected conditions or if the execution machinery does not effectively
control a controlled access.
Here the attacker is expected to (i) take advantage of flaws in the design
and/or the implementation of the TOE memory access rules (refer to
BSI.T.Abuse-Func but for functions available after TOE delivery), (ii)
introduce flaws by forcing operational conditions (refer to
BSI.T.Malfunction) and/or by physical manipulation (refer to BSI.T.Phys-
Manipulation). This attacker is expected to have a high level potential of
attack.
BSI.P.Process-TOE Protection during TOE Development and Production:
An accurate identification is established for the TOE. This requires that
each instantiation of the TOE carries this unique identification.
ST23YS64C Security Target - Public Version Security problem definition
SMD_ST23YS64_ST_11_002 17/45
5.4 Assumptions
73 The assumptions are described in the BSI-PP-0035, section 3.4. Only those originating in
AUG are detailed in this document.
AUG1.P.Add Functions Additional Specific Security Functionality:
The TOE shall provide the following specific security functionality to the
Security IC Embedded Software:
– Data Encryption Standard (DES),
– Triple Data Encryption Standard (3DES).
Note that DES is no longer recommended as an encryption function in the
context of smart card applications. Hence, Security IC Embedded Software
may need to use triple DES to achieve a suitable strength.
BSI.A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation
BSI.A.Plat-Appl Usage of Hardware Platform
BSI.A.Resp-Appl Treatment of User Data
Security objectives ST23YS64C Security Target - Public Version
18/45 SMD_ST23YS64_ST_11_002
6 Security objectives
74 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,
● provide random numbers,
● provide cryptographic support and access control functionality.
75 A summary of all security objectives is provided in Table 4. Note that the origin of each
objective is clearly identified in the prefix of its label.
76 Most of these security aspects can therefore be easily found in the protection profile. Only
those originating in AUG are detailed in the following sections.
6.1 Security objectives for the TOE
Table 4. Summary of security objectives
Label Title
TOE
BSI.O.Leak-Inherent Protection against Inherent Information Leakage
BSI.O.Phys-Probing Protection against Physical Probing
BSI.O.Malfunction Protection against Malfunctions
BSI.O.Phys-Manipulation Protection against Physical Manipulation
BSI.O.Leak-Forced Protection against Forced Information Leakage
BSI.O.Abuse-Func Protection against Abuse of Functionality
BSI.O.Identification TOE Identification
BSI.O.RND Random Numbers
AUG1.O.Add-Functions Additional Specific Security Functionality
AUG4.O.Mem Access Dynamic Area based Memory Access Control
Environments
BSI.OE.Plat-Appl Usage of Hardware Platform
BSI.OE.Resp-Appl Treatment of User Data
BSI.OE.Process-Sec-IC Protection during composite product manufacturing
BSI.O.Leak-Inherent Protection against Inherent Information Leakage
BSI.O.Phys-Probing Protection against Physical Probing
BSI.O.Malfunction Protection against Malfunctions
BSI.O.Phys-Manipulation Protection against Physical Manipulation
BSI.O.Leak-Forced Protection against Forced Information Leakage
BSI.O.Abuse-Func Protection against Abuse of Functionality
ST23YS64C Security Target - Public Version Security objectives
SMD_ST23YS64_ST_11_002 19/45
6.2 Security objectives for the environment
77 Security Objectives for the Security IC Embedded Software development Environment
(phase 1):
78 Security Objectives for the operational Environment (TOE delivery up to end of phase 6):
6.3 Security objectives rationale
79 The main line of this rationale is that the inclusion of all the security objectives of the BSI-
PP-0035 protection profile, together with those in AUG, guarantees that all the security
environment aspects identified in Section 5 are addressed by the security objectives stated
in this chapter.
80 Thus, it is necessary to show that:
● security environment aspects from AUG are addressed by security objectives stated in
this chapter,
● security objectives from AUG are suitable (i.e. they address security environment
aspects),
● security objectives from AUG are consistent with the other security objectives stated in
this chapter (i.e. no contradictions).
81 The selected augmentations from AUG introduce the following security environment
aspects:
● TOE threat "Memory Access Violation, (AUG4.T.Mem-Access)",
● organisational security policy "Additional Specific Security Functionality, (AUG1.P.Add
Functions)".
BSI.O.Identification TOE Identification
BSI.O.RND Random Numbers
AUG1.O.Add-Functions Additional Specific Security Functionality:
The TOE must provide the following specific security functionality to
the Security IC Embedded Software:
– Data Encryption Standard (DES),
– Triple Data Encryption Standard (3DES).
AUG4.O.Mem Access Dynamic Area based Memory Access Control:
The TOE must provide the Security IC Embedded Software with the
capability to define dynamic memory segmentation and
protection. The TOE must then enforce the defined access rules
so that access of software to memory areas is controlled as required,
for example, in a multi-application environment.
BSI.OE.Plat-Appl Usage of Hardware Platform
BSI.OE.Resp-Appl Treatment of User Data
BSI.OE.Process-Sec-IC Protection during composite product manufacturing
Security objectives ST23YS64C Security Target - Public Version
20/45 SMD_ST23YS64_ST_11_002
82 The justification of the additional policy, additional threat and the additional assumption
provided in the next subsections shows that they do not contradict to the rationale already
given in the protection profile BSI-PP-0035 for the assumptions, policy and threats defined
there.
6.3.1 TOE threat "Memory Access Violation"
83 The justification related to the threat “Memory Access Violation, (AUG4.T.Mem-Access)” is
as follows:
84 According to AUG4.O.Mem Access the TOE must enforce the dynamic memory
segmentation and protection so that access of software to memory areas is controlled.
Any restrictions are to be defined by the Security IC Embedded Software. Thereby security
violations caused by accidental or deliberate access to restricted data (which may include
code) can be prevented (refer to AUG4.T.Mem-Access). The threat AUG4.T.Mem-Access is
therefore removed if the objective is met.
85 The added objective for the TOE AUG4.O.Mem Access does not introduce any contradiction
in the security objectives for the TOE.
6.3.2 Organisational security policy "Additional Specific Security
Functionality"
86 The justification related to the organisational security policy "Additional Specific Security
Functionality, (AUG1.P.Add Functions)” is as follows:
Table 5. Security Objectives versus Assumptions, Threats or Policies
Assumption, Threat or Organisational
Security Policy
Security Objective Notes
BSI.A.Plat-Appl BSI.OE.Plat-Appl Phase 1
BSI.A.Resp-Appl BSI.OE.Resp-Appl Phase 1
BSI.P.Process-TOE BSI.O.Identification
Phase 2-3
optional
Phase 4
BSI.A.Process-Sec-IC BSI.OE.Process-Sec-IC
Phase 5-6
optional
Phase 4
BSI.T.Leak-Inherent BSI.O.Leak-Inherent
BSI.T.Phys-Probing BSI.O.Phys-Probing
BSI.T.Malfunction BSI.O.Malfunction
BSI.T.Phys-Manipulation BSI.O.Phys-Manipulation
BSI.T.Leak-Forced BSI.O.Leak-Forced
BSI.T.Abuse-Func BSI.O.Abuse-Func
BSI.T.RND BSI.O.RND
AUG1.P.Add Functions AUG1.O.Add-Functions
AUG4.T.Mem-Access AUG4.O.Mem Access
ST23YS64C Security Target - Public Version Security objectives
SMD_ST23YS64_ST_11_002 21/45
87 Since AUG1.O.Add-Functions requires the TOE to implement exactly the same specific
security functionality as required by AUG1.P.Add Functions, and in the very same
conditions, the organisational security policy is covered by the objective.
88 Nevertheless the security objectives BSI.O.Leak-Inherent, BSI.O.Phys-Probing, ,
BSI.O.Malfunction, BSI.O.Phys-Manipulation and BSI.O.Leak-Forced define how to
implement the specific security functionality required by AUG1.P.Add Functions. (Note that
these objectives support that the specific security functionality is provided in a secure way
as expected from AUG1.P.Add Functions.) Especially BSI.O.Leak-Inherent and BSI.O.Leak-
Forced refer to the protection of confidential data (User Data or TSF data) in general. User
Data are also processed by the specific security functionality required by AUG1.P.Add
Functions.
89 The added objective for the TOE AUG1.O.Add-Functions does not introduce any
contradiction in the security objectives. It merely extends the scope of the objectives
identified above so that they cover the added functionality.
Security requirements ST23YS64C Security Target - Public Version
22/45 SMD_ST23YS64_ST_11_002
7 Security requirements
90 This chapter on security requirements contains a section on security functional
requirements (SFRs) for the TOE (Section 7.1), a section on security assurance
requirements (SARs) for the TOE (Section 7.2), a section on the refinements of these SARs
(Section 7.3) as required by the "BSI-PP-0035" Protection Profile. This chapter includes a
section with the security requirements rationale (Section 7.4).
7.1 Security functional requirements for the TOE
91 Security Functional Requirements (SFRs) from the "BSI-PP-0035" Protection Profile (PP)
are drawn from CCMB-2009-07-002, except the following SFRs, that are extensions to
CCMB-2009-07-002:
● FCS_RNG Generation of random numbers,
● FMT_LIM Limited capabilities and availability,
● FAU_SAS Audit data storage.
The reader can find their certified definitions in the text of the "BSI-PP-0035" Protection
Profile.
92 All extensions to the SFRs of the "BSI-PP-0035" Protection Profiles (PPs) are exclusively
drawn from CCMB-2009-07-002.
93 All iterations, assignments, selections, or refinements on SFRs have been performed
according to section C.4 of CCMB-2009-07-001. They are easily identified in the following
text as they appear as indicated here. Note that in order to improve readability, iterations
are sometimes expressed within tables.
94 In order to ease the definition and the understanding of these security functional
requirements, a simplified presentation of the TOE Security Policy (TSP) is given in the
following section.
95 The selected security functional requirements for the TOEs, their respective origin and type
are summarized in Table 6.
Table 6. Summary of functional security requirements for the TOE
Label Title Addressing Origin Type
FRU_FLT.2 Limited fault tolerance
Malfunction BSI-PP-0035
CCMB-2009-07-002
FPT_FLS.1
Failure with preservation
of secure state
FMT_LIM.1 Limited capabilities
Abuse of functionality BSI-PP-0035
Extended
FMT_LIM.2 Limited availability
FAU_SAS.1 Audit storage Lack of TOE identification
BSI-PP-0035
Operated
ST23YS64C Security Target - Public Version Security requirements
SMD_ST23YS64_ST_11_002 23/45
7.1.1 Limited fault tolerance (FRU_FLT.2)
96 The TSF shall ensure the operation of all the TOE’s capabilities when the following failures
occur: exposure to operating conditions which are not detected according to the
requirement Failure with preservation of secure state (FPT_FLS.1).
7.1.2 Failure with preservation of secure state (FPT_FLS.1)
97 The TSF shall preserve a secure state when the following types of failures occur: exposure
to operating conditions which may not be tolerated according to the requirement
Limited fault tolerance (FRU_FLT.2) and where therefore a malfunction could occur.
98 Refinement:
The term “failure” above also covers “circumstances”. The TOE prevents failures for the
“circumstances” defined above.
Regarding application note 15 of BSI-PP-0035, the TOE provides information on the
operating conditions monitored during Security IC Embedded Software execution and after
a warm reset. No audit requirement is however selected in this Security Target.
7.1.3 Limited capabilities (FMT_LIM.1)
99 The TSF shall be designed and implemented in a manner that limits their capabilities so that
in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced:
Limited capability and availability Policy.
FPT_PHP.3
Resistance to physical
attack
Physical manipulation &
probing
BSI-PP-0035
CCMB-2009-07-002
FDP_ITT.1
Basic internal transfer
protection
Leakage
FPT_ITT.1
Basic internal TSF data
transfer protection
FDP_IFC.1
Subset information flow
control
FCS_RNG.1
Random number
generation
Weak cryptographic
quality of random
numbers
BSI-PP-0035
Operated
Extended
FCS_COP.1 Cryptographic operation Cipher scheme support
AUG #1
Operated
CCMB-2009-07-002
FDP_ACC.2 Complete access control
Memory access violation
Security Target
Operated
FDP_ACF.1
Security attribute based
access control
AUG #4
Operated
FMT_MSA.3
Static attribute
initialisation
Correct operation
FMT_MSA.1
Management of security
attribute
Table 6. Summary of functional security requirements for the TOE (continued)
Label Title Addressing Origin Type
Security requirements ST23YS64C Security Target - Public Version
24/45 SMD_ST23YS64_ST_11_002
7.1.4 Limited availability (FMT_LIM.2)
100 The TSF shall be designed and implemented in a manner that limits their availability so that
in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced:
Limited capability and availability Policy.
101 SFP_1: Limited capability and availability Policy
Deploying Test Features after TOE Delivery does not allow User Data to be disclosed or
manipulated, TSF data to be disclosed or manipulated, software to be reconstructed and no
substantial information about construction of TSF to be gathered which may enable other
attacks.
7.1.5 Audit storage (FAU_SAS.1)
102 The TSF shall provide the test process before TOE Delivery with the capability to store
the Initialisation Data and/or Pre-personalisation Data and/or supplements of the
Security IC Embedded Software in the NVM.
7.1.6 Resistance to physical attack (FPT_PHP.3)
103 The TSF shall resist physical manipulation and physical probing, to the TSF by
responding automatically such that the SFRs are always enforced.
104 Refinement:
The TSF will implement appropriate mechanisms to continuously counter physical
manipulation and physical probing. Due to the nature of these attacks (especially
manipulation) the TSF can by no means detect attacks on all of its elements. Therefore,
permanent protection against these attacks is required ensuring that security functional
requirements are enforced. Hence, “automatic response” means here (i)assuming that there
might be an attack at any time and (ii)countermeasures are provided at any time.
7.1.7 Basic internal transfer protection (FDP_ITT.1)
105 The TSF shall enforce the Data Processing Policy to prevent the disclosure of user data
when it is transmitted between physically-separated parts of the TOE.
7.1.8 Basic internal TSF data transfer protection (FPT_ITT.1)
106 The TSF shall protect TSF data from disclosure when it is transmitted between separate
parts of the TOE.
107 Refinement:
The different memories, the CPU and other functional units of the TOE (e.g. a cryptographic
co-processor) are seen as separated parts of the TOE.
This requirement is equivalent to FDP_ITT.1 above but refers to TSF data instead of User
Data. Therefore, it should be understood as to refer to the same Data Processing Policy
defined under FDP_IFC.1 below.
7.1.9 Subset information flow control (FDP_IFC.1)
108 The TSF shall enforce the Data Processing Policy on all confidential data when they are
processed or transferred by the TSF or by the Security IC Embedded Software.
109 SFP_2: Data Processing Policy
ST23YS64C Security Target - Public Version Security requirements
SMD_ST23YS64_ST_11_002 25/45
User Data and TSF data shall not be accessible from the TOE except when the Security IC
Embedded Software decides to communicate the User Data via an external interface. The
protection shall be applied to confidential data only but without the distinction of attributes
controlled by the Security IC Embedded Software.
7.1.10 Random number generation (FCS_RNG.1)
110 The TSF shall provide a physical random number generator that implements total failure
test of the random source.
111 The TSF shall provide random numbers that meet P2 class of BSI-AIS31.
7.1.11 Cryptographic operation (FCS_COP.1)
112 The TSF shall perform the operations in Table 7 in accordance with a specified
cryptographic algorithm in Table 7 and cryptographic key sizes of Table 7 that meet the
standards in Table 7.
7.1.12 Static attribute initialisation (FMT_MSA.3)
113 The TSF shall enforce the Dynamic Memory Access Control Policy to provide minimally
protective(a)
default values for security attributes that are used to enforce the SFP.
114 The TSF shall allow none to specify alternative initial values to override the default values
when an object or information is created.
Application note:
The security attributes are the set of access rights currently defined. They are dynamically
attached to the subjects and objects locations, i.e. each logical address.
7.1.13 Management of security attributes (FMT_MSA.1)
115 The TSF shall enforce the Dynamic Memory Access Control Policy to restrict the ability
to modify the current set of access rights security attributes to software running in
supervisor level.
Table 7. FCS_COP.1 iterations (cryptographic operations)
[assignment: list of
cryptographic
operations]
[assignment:
cryptographic
algorithm]
[assignment:
cryptographic key
sizes]
[assignment: list of
standards]
encryption
decryption
in Cipher Block Chaining
(CBC) mode
Data Encryption
Standard (DES)
56 effective bits ISO 8372:1987
ISO 8731-1:1987
ISO/IEC 9797:1994
ISO/IEC 10116:1997
Triple Data
Encryption
Standard (3DES)
112 effective bits
a. See the Data Sheet referenced in Section 9 for actual values
Security requirements ST23YS64C Security Target - Public Version
26/45 SMD_ST23YS64_ST_11_002
7.1.14 Complete access control (FDP_ACC.2)
116 The TSF shall enforce the Dynamic Memory Access Control Policy on all subjects
(software), all objects (data including code stored in memories) and all operations
among subjects and objects covered by the SFP.
117 The TSF shall ensure that all operations between any subject controlled by the TSF and any
object controlled by the TSF are covered by an access control SFP.
7.1.15 Security attribute based access control (FDP_ACF.1)
118 The TSF shall enforce the Dynamic Memory Access Control Policy to objects based on
the software clearance level, the object location, the operation to be performed, and
the current set of access rights.
119 The TSF shall enforce the following rules to determine if an operation among controlled
subjects and controlled objects is allowed: the operation is allowed if and only if the
software clearance level, the object location and the operation matches an entry in
the current set of access rights.
120 The TSF shall explicitly authorise access of subjects to objects based on the following
additional rules: none.
121 The TSF shall explicitly deny access of subjects to objects based on the following additional
rules: none.
Note: It should be noted that this level of policy detail is not needed at the application level. The
composite Security Target writer should describe the SICESW access control and
information flow control policies instead. Within the SICESW High Level Design description,
the chosen setting of IC security attributes would be shown to implement the described
policies relying on the IC SFP presented here.
122 The following SFP Dynamic Memory Access Control Policy is defined for the requirement
"Security attribute based access control (FDP_ACF.1)":
123 SFP_3: Dynamic Memory Access Control Policy
124 The TSF must control read, write, execute accesses of software to data (including code
stored in memory areas), based on their respective clearance levels and on the current set
of access rights.
7.2 TOE security assurance requirements
125 Security Assurance Requirements for the TOE for the evaluation of the TOE are those taken
from the Evaluation Assurance Level 5 (EAL5) and augmented by taking the following
components:
● ALC_DVS.2, and AVA_VAN.5.
126 Regarding application note 21 of BSI-PP-0035, the continuously increasing maturity level of
evaluations of Security ICs justifies the selection of a higher-level assurance package.
127 The set of security assurance requirements (SARs) is presented in Table 8, indicating the
origin of the requirement.
ST23YS64C Security Target - Public Version Security requirements
SMD_ST23YS64_ST_11_002 27/45
7.3 Refinement of the security assurance requirements
128 As BSI-PP-0035 defines refinement for selected SARs, these refinements are also claimed
in this Security Target.
129 The main customizing is that the IC Dedicated Software is an operational part of the TOE
after delivery, although it is not available to the user.
130 Regarding application note 22 of BSI-PP-0035, the refinements for all the assurance
families have been reviewed for the hierarchically higher-level assurance components
selected in this Security Target.
131 The text of the impacted refinements of BSI-PP-0035 is reproduced in the next sections.
132 For reader’s ease, an impact summary is provided in Table 9.
Table 8. TOE security assurance requirements
Label Title Origin
ADV_ARC.1 Security architecture description EAL5/BSI-PP-0035
ADV_FSP.5
Complete semi-formal functional specification with
additional error information
EAL5
ADV_IMP.1 Implementation representation of the TSF EAL5/BSI-PP-0035
ADV_INT.2 Well-stuctured internals EAL5
ADV_TDS.4 Semiformal modular design EAL5
AGD_OPE.1 Operational user guidance EAL5/BSI-PP-0035
AGD_PRE.1 Preparative procedures EAL5/BSI-PP-0035
ALC_CMC.4
Production support, acceptance procedures and
automation
EAL5/BSI-PP-0035
ALC_CMS.5 Development tools CM coverage EAL5
ALC_DEL.1 Delivery procedures EAL5/BSI-PP-0035
ALC_DVS.2 Sufficiency of security measures BSI-PP-0035
ALC_LCD.1 Developer defined life-cycle model EAL5/BSI-PP-0035
ALC_TAT.2 Compliance with implementation standards EAL5
ATE_COV.2 Analysis of coverage EAL5/BSI-PP-0035
ATE_DPT.3 Testing: modular design EAL5
ATE_FUN.1 Functional testing EAL5/BSI-PP-0035
ATE_IND.2 Independent testing - sample EAL5/BSI-PP-0035
AVA_VAN.5 Advanced methodical vulnerability analysis BSI-PP-0035
Security requirements ST23YS64C Security Target - Public Version
28/45 SMD_ST23YS64_ST_11_002
7.3.1 Refinement regarding functional specification (ADV_FSP)
133 Although the IC Dedicated Test Software is a part of the TOE, the test functions of the IC
Dedicated Test Software are not described in the Functional Specification because the IC
Dedicated Test Software is considered as a test tool delivered with the TOE but not
providing security functions for the operational phase of the TOE. The IC Dedicated
Software provides security functionalities as soon as the TOE becomes operational
(boot software). These are properly identified in the delivered documentation.
134 The Functional Specification refers to data sheet to trace security features that do not
provide any external interface but that contribute to fulfil the SFRs e.g. like physical
protection. Thereby they are part of the complete instantiation of the SFRs.
135 The Functional Specification refers to design specifications to detail the mechanisms
against physical attacks described in a more general way only, but detailed enough to be
able to support Test Coverage Analysis also for those mechanisms where inspection of the
layout is of relevance or tests beside the TSFI may be needed.
136 The Functional Specification refers to data sheet to specify operating conditions of the
TOE. These conditions include but are not limited to the frequency of the clock, the power
supply, and the temperature.
137 All functions and mechanisms which control access to the functions provided by the IC
Dedicated Test Software (refer to the security functional requirement (FMT_LIM.2)) are part
of the Functional Specification. Details will be given in the document for ADV_ARC, refer to
Section 6.2.1.5. In addition, all these functions and mechanisms are subsequently be
refined according to all relevant requirements of the Common Criteria assurance class ADV
because these functions and mechanisms are active after TOE Delivery and need to be part
of the assurance aspects Tests (class ATE) and Vulnerability Assessment (class AVA).
Therefore, all necessary information is provided to allow tests and vulnerability assessment.
138 Since the selected higher-level assurance component requires a security functional
specification presented in a “semi-formal style" (ADV_FSP.5.2C) the changes affect the style
Table 9. Impact of EAL5 selection on BSI-PP-0035 refinements
Assurance
Family
BSI-PP-0035
Level
ST
Level
Impact on refinement
ADO_DEL 1 1 None
ALC_DVS 2 2 None
ALC_CMS 4 5 None, refinement is still valid
ALC_CMC 4 4 None
ADV_ARC 1 1 None
ADV_FSP 4 5
Presentation style changes, IC Dedicated Software is
included
ADV_IMP 1 1 None
ATE_COV 2 2 IC Dedicated Software is included
AGD_OPE 1 1 None
AGD_PRE 1 1 None
AVA_VAN 5 5 None
ST23YS64C Security Target - Public Version Security requirements
SMD_ST23YS64_ST_11_002 29/45
of description, the BSI-PP-0035 refinements can be applied with changes covering the IC
Dedicated Test Software and are valid for ADV_FSP.5.
7.3.2 Refinement regarding test coverage (ATE_COV)
139 The TOE is tested under different operating conditions within the specified ranges. These
conditions include but are not limited to the frequency of the clock, the power supply, and the
temperature. This means that “Fault tolerance (FRU_FLT.2)” is proven for the complete TSF.
The tests must also cover functions which may be affected by “ageing” (such as EEPROM
writing).
140 The existence and effectiveness of measures against physical attacks (as specified by the
functional requirement FPT_PHP.3) cannot be tested in a straightforward way. Instead
STMicroelectronics provides evidence that the TOE actually has the particular physical
characteristics (especially layout design principles). This is done by checking the layout
(implementation or actual) in an appropriate way. The required evidence pertains to the
existence of mechanisms against physical attacks (unless being obvious).
141 The IC Dedicated Test Software is seen as a “test tool” being delivered as part of the TOE.
However, the Test Features do not provide security functionality. Therefore, Test Features
need not to be covered by the Test Coverage Analysis but all functions and mechanisms
which limit the capability of the functions (cf. FMT_LIM.1) and control access to the
functions (cf. FMT_LIM.2) provided by the IC Dedicated Test Software must be part of the
Test Coverage Analysis. The IC Dedicated Software provides security functionalities as
soon as the TOE becomes operational (boot software). These are part of the Test
Coverage Analysis.
7.4 Security Requirements rationale
7.4.1 Rationale for the Security Functional Requirements
142 Just as for the security objectives rationale of Section 6.3, the main line of this rationale is
that the inclusion of all the security requirements of the BSI-PP-0035 protection profile,
together with those in AUG, guarantees that all the security objectives identified in Section 6
are suitably addressed by the security requirements stated in this chapter, and that the latter
together form an internally consistent whole.
143 As origins of security objectives have been carefully kept in their labelling and origins of
security requirements have been carefully identified in Table 6 and Table 8, it can be verified
that the justifications provided by the BSI-PP-0035 protection profile and AUG can just be
carried forward to the unions.
144 From Table 4, it is straightforward to identify two additional security objectives for the TOE
(AUG1.O.Add-Functions and AUG4.O.Mem Access), and two clarifications on two security
objectives for the environment (BSI.OE.Plat-Appl and BSI.OE.Resp-Appl), all tracing back to
AUG. This rationale must show that security requirements suitably address these too.
145 Furthermore, a more careful observation of the requirements listed in Table 6 and Table 8
shows that:
● there are additional security requirements introduced by this Security Target
(FDP_ACC.2 and various assurance requirements of EAL5),
● there are security requirements introduced from AUG (FCS_COP.1, FDP_ACF.1,
FMT_MSA.3 and FMT_MSA.1).
Security requirements ST23YS64C Security Target - Public Version
30/45 SMD_ST23YS64_ST_11_002
146 Though it remains to show that:
● security objectives from AUG are addressed by security requirements stated in this
chapter,
● additional security requirements from this Security Target and from AUG are mutually
supportive to the security requirements from the BSI-PP-0035 protection profile, and
they do not introduce internal contradictions,
● all dependencies are still satisfied.
147 The justification that the additional security objectives are suitably addressed, that the
additional security requirements are mutually supportive and that, together with those
already in BSI-PP-0035, they form an internally consistent whole, is provided in the next
subsections.
7.4.2 Additional security objectives are suitably addressed
Security objective “Dynamic Area based Memory Access Control
(AUG4.O.Mem Access)”
148 The justification related to the security objective “Dynamic Area based Memory Access
Control (AUG4.O.Mem Access)” is as follows:
149 The security functional requirements "Complete access control (FDP_ACC.2)" and
"Security attribute based access control (FDP_ACF.1)", with the related Security Function
Policy (SFP) “Dynamic Memory Access Control Policy” exactly require to implement an
Dynamic area based memory access control as demanded by AUG4.O.Mem Access.
Therefore, FDP_ACC.2 and FDP_ACF.1 with their SFP are suitable to meet the security
objective.
150 The security functional requirement "Static attribute initialisation (FMT_MSA.3)" requires
that the TOE provides default values for security attributes. These default values can be
overwritten by any subject (software) provided that the necessary access is allowed what is
further detailed in the security functional requirement "Management of security attributes
(FMT_MSA.1)". The ability to update the security attributes is restricted to privileged
subject(s) as further detailed in the security functional requirement "Management of
security attributes (FMT_MSA.1)". These management functions ensure that the required
access control can be realised using the functions provided by the TOE.
Security objective “Additional Specific Security Functionality (AUG1.O.Add-
Functions)”
151 The justification related to the security objective “Additional Specific Security Functionality
(AUG1.O.Add-Functions)” is as follows:
152 The security functional requirements “Cryptographic operation (FCS_COP.1)” exactly
requires those functions to be implemented that are demanded by AUG1.O.Add-Functions.
Therefore, FCS_COP.1 is suitable to meet the security objective.
7.4.3 Additional security requirements are consistent
"Cryptographic operation (FCS_COP.1)"
153 This security requirement has already been argued in Section : Security objective
“Additional Specific Security Functionality (AUG1.O.Add-Functions)” above.
ST23YS64C Security Target - Public Version Security requirements
SMD_ST23YS64_ST_11_002 31/45
"Static attribute initialisation (FMT_MSA.3),
Management of security attributes (FMT_MSA.1),
Complete access control (FDP_ACC.2),
Security attribute based access control (FDP_ACF.1)"
154 These security requirements have already been argued in Section : Security objective
“Dynamic Area based Memory Access Control (AUG4.O.Mem Access)” above.
7.4.4 Dependencies of Security Functional Requirements
155 All dependencies of Security Functional Requirements have been fulfilled in this Security
Target except :
● those justified in the BSI-PP-0035 protection profile security requirements rationale,
● those justifed in AUG security requirements rationale (except on FMT_MSA.2, see
discussion below),
● the dependency of FMT_MSA.1 on FMT_SMF.1 (see discussion below).
156 Details are provided in Table 10 below.
Table 10. Dependencies of security functional requirements
Label Dependencies
Fulfilled by security
requirements in this
Security Target
Dependency already
in BSI-PP-0035 or
in AUG
FRU_FLT.2 FPT_FLS.1 Yes Yes, BSI-PP-0035
FPT_FLS.1 None No dependency Yes, BSI-PP-0035
FMT_LIM.1 FMT_LIM.2 Yes Yes, BSI-PP-0035
FMT_LIM.2 FMT_LIM.1 Yes Yes, BSI-PP-0035
FAU_SAS.1 None No dependency Yes, BSI-PP-0035
FPT_PHP.3 None No dependency Yes, BSI-PP-0035
FDP_ITT.1
FDP_ACC.1 or
FDP_IFC.1
Yes Yes, BSI-PP-0035
FPT_ITT.1 None No dependency Yes, BSI-PP-0035
FDP_IFC.1 FDP_IFF.1 No, see BSI-PP-0035 Yes, BSI-PP-0035
FCS_RNG.1 None No dependency Yes, BSI-PP-0035
FCS_COP.1
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
Yes (by the environment)
Yes, AUG #1 (adapted to
CC V3.1 R2, see
discussion below)
FDP_ACC.2 FDP_ACF.1 Yes No, CCMB-2009-07-002
FDP_ACF.1
FDP_ACC.1 Yes
Yes, AUG #4
FMT_MSA.3 Yes
FMT_MSA.3
FMT_MSA.1 Yes
Yes, AUG #4
FMT_SMR.1 No, see AUG #4
Security requirements ST23YS64C Security Target - Public Version
32/45 SMD_ST23YS64_ST_11_002
157 Part 2 of the Common Criteria defines the dependency of "Management of security
attributes (FMT_MSA.1)" on "Specification of management functions (FMT_SMF.1)". In this
particular ST, the specification of FMT_SMF.1 is useless. As stated in the Dynamic
Memory Access Control Policy and in FMT_MSA.1, there is no specific function for the
management of the memory access rights, it is just part of the Management of the security
attributes.
158 AUG #1 defines the dependency of “Cryptographic operation (FCS_COP.1)" on "Secure
security attributes (FMT_MSA.2)". This dependency is not anymore defined in the Part 2 of
the Common Criteria V3.1 Revision 2. Thus, it has not been retained in this Security Target.
7.4.5 Rationale for the Assurance Requirements
Security assurance requirements added to reach EAL5 (Table 8)
159 Regarding application note 21 of BSI-PP-0035, this Security Target chooses EAL5 because
developers and users require a high level of independently assured security in a planned
development and require a rigorous development approach without incurring unreasonable
costs attributable to specialist security engineering techniques.
160 EAL5 represents a meaningful increase in assurance from EAL4 by requiring semiformal
design descriptions, a more structured (and hence analyzable) architecture, and improved
mechanisms and/or procedures that provide confidence that the TOE will not be tampered
during development.
161 The assurance components in an evaluation assurance level (EAL) are chosen in a way that
they build a mutually supportive and complete set of components. The requirements chosen
for augmentation do not add any dependencies, which are not already fulfilled for the
corresponding requirements contained in EAL5. Therefore, these components add
additional assurance to EAL5, but the mutual support of the requirements and the internal
consistency is still guaranteed.
162 Note that detailed and updated refinements for assurance requirements are given in
Section 7.3.
Dependencies of assurance requirements
163 Dependencies of security assurance requirements are fulfilled by the EAL5 package
selection.
164 Augmentation to this package are identified in paragraph 125 and do not introduce
dependencies not already satisfied by the EAL5 package.
FMT_MSA.1
[FDP_ACC.1 or
FDP_IFC.1]
Yes Yes, AUG #4
FMT_SMF.1 No, see discussion below No, CCMB-2009-07-002
FMT_SMR.1 No, see AUG #4 Yes, AUG #4
Table 10. Dependencies of security functional requirements (continued)
Label Dependencies
Fulfilled by security
requirements in this
Security Target
Dependency already
in BSI-PP-0035 or
in AUG
ST23YS64C Security Target - Public Version TOE summary specification
SMD_ST23YS64_ST_11_002 33/45
8 TOE summary specification
165 This section demonstrates how the TOE meets each Security Functional Requirement.
166 The following TSS relies on the refinement of the TSF security elements, as detailed in the
TOE Functional Specification referenced in the ST23YL Documentation Report
(see Section 9, paragraph 203).
8.1 Statement of TOE security functionality
167 The following TSF services are an abstraction of the TOE Functional Specification.
8.1.1 TSF_INIT_A: Hardware initialisation & TOE attribute initialisation
168 In TEST and USER configurations, this functionality ensures the following:
● the TOE starts running in a secure state,
● the TOE is securely initialised,
● the reset operation is correctly managed.
8.1.2 TSF_CONFIG_A: TOE configuration switching and control
169 In TEST and USER configurations, this functionality ensures the switching and the control of
TOE configuration.
170 This functionality ensures that the TOE is either in TEST or USER configuration.
171 The only authorised TOE configuration modifications are:
● TEST to USER configuration by TEST administrator.
172 This functionality is responsible for the TOE configuration detection and notification to the
other resources of the TOE.
8.1.3 TSF_INT_A: TOE logical integrity
173 In TEST and USER configurations, this functionality is responsible for:
● correcting single bit fails upon a read operation on each NVM byte,
● verifying valid CPU usage,
● checking integrity loss when accessing NVM, ROM or RAM,
● providing a sign engine to check code and/or data integrity loss,
● monitoring various manifestations of fault injection attempts,
● providing a security timeout feature (watchdog timer),
● providing the SICESW with the traceability information of the TOE.
174 This functionality is responsible for reporting to TSF_ADMINIS_A all detected errors
resulting from the above operations.
8.1.4 TSF_TEST_A: Test of the TOE
175 This functionality is responsible for restricting access of the TOE TEST functionality to the
TEST process in TEST configuration.
TOE summary specification ST23YS64C Security Target - Public Version
34/45 SMD_ST23YS64_ST_11_002
176 In TEST configuration, this functionality ensures that the only allowed TOE user is an
authorized TEST process.
177 In TEST configuration, this functionality ensures the test of TOE functionality with respect to
the IC specification, including the TSF. This functionality is therefore responsible of the
hardware functional integrity (CPU, RAM, ROM, NVM, Bus...).
178 In TEST configuration, this functionality provides commands to store data and/or pre-
personalisation data and/or supplements of the Security IC Embedded Software
(personalisation).
179 In USER configuration, this functionality ensures that the critical TOE TEST functionality is
disabled.
8.1.5 TSF_FWL_A: Memory Firewall
180 In TEST and USER configurations, this security functionality monitors:
● access from memory locations to other locations for ROM, RAM and NVM,
● register access.
181 The TOE memories segmentation and protection can be dynamically defined, by the TOE
user, thanks to the Memory Protection Unit (MPU), in order to implement various access
control policies.
182 A default-TOE memories segmentation and protection is initially defined by ST.
183 In TEST and USER configurations, this security functionality relies on the MPU to ensure
that only the Supervisor programs can change the TOE memories segmentation and
protection in ROM, RAM and NVM.
184 This security functionality is responsible for the notification of violation attempts to
TSF_ADMINIS_A.
8.1.6 TSF_PHT_A: Physical tampering protection
185 In TEST and USER configurations, this functionality ensures the following:
● the TOE detects clock and voltage supply operating changes by the environment,
● the TOE detects attempts to violate its physical integrity, and glitch attacks,
● the TOE is always clocked with shape and timing within specified operating conditions.
186 This functionality is responsible for the notification of physical tampering attempts and clock
and voltage supply operating changes by the environment to TSF_ADMINIS_A.
8.1.7 TSF_ADMINIS_A: Security violation administrator
187 In TEST and USER configurations, this functionality ensures the management of security
violations attempts.
ST23YS64C Security Target - Public Version TOE summary specification
SMD_ST23YS64_ST_11_002 35/45
188 The main security violations attempts which are managed are:
● bad CPU usage,
● integrity loss in NVM, ROM or RAM,
● code signature alarm,
● fault injection attempt,
● watchdog timeout.
● access attempt to unavailable or reserved memory areas,
● MPU errors,
● clock and voltage supply operating changes by the environment,
● TOE physical integrity abuse.
8.1.8 TSF_OBS_A: Unobservability
189 In USER configuration, this functionality addresses the Basic internal transfer protection
(FDP_ITT.1), the Basic internal TSF data transfer protection (FPT_ITT.1) and the Subset
information flow control (FDP_IFC.1) security functional requirements expressed in this
document.
190 This functionality provides additional support mechanisms to the SICESW developer
contributing to avoid information leakage.
8.1.9 TSF_SKCS_A: Symmetric Key Cryptography Support
191 In USER configuration, this functionality implements the following standard symmetric key
cryptography algorithms:
● Data Encryption Standard (DES) with 64 bits long keys (56 effective bits).
This functionality supports the following standard modes of operation, both for encryption
and for decryption:
● DES by itself (fast DES),
● Triple DES, chaining two DES encryption and one DES decryption.
Each of these modes of operation can be chained in the standard Cipher Block Chaining
mode (CBC).
8.1.10 TSF_ALEAS_A: Unpredictable Number Generation Support
192 In all configurations, this functionality provides 8-bit true random numbers.
193 In USER configuration, this functionality supports the mitigation of information leakage.
194 This functionality can be qualified with the test metrics required by the BSI-AIS31 standard
for a P2 class device.
8.2 TOE summary specification rationale
195 This section shows that the TSF and assurance measures are suitable to meet the TOE
security requirements.
TOE summary specification ST23YS64C Security Target - Public Version
36/45 SMD_ST23YS64_ST_11_002
8.2.1 TSF rationale
196 This section demonstrates that the combination of the specified TSF work together so as to
satisfy the TOE security functional requirements.
197 Each of the security functional requirements is addressed by at least one or a combination
of TSF services.
198 The complete rationale has been presented and evaluated in the ST23YS64 Security
Target.
199 For confidentiality reasons, this rationale is not fully reproduced here.
200 Table 11 below summarises which TOE security functional requirements (SFRs) are
addressed by each TSF service (TSF_).
Table 11. Mapping of TSF services and SFRs
T SFs
SFRs
TSF_INIT_A
(8.1.1)
TSF_CONFIG_A
(8.1.2)
TSF_INT_A
(8.1.3)
TSF_TEST_A
(8.1.4)
TSF_FWL_A
(8.1.5)
TSF_PHT_A
(8.1.6)
TSF_ADMINIS_A
(8.1.7)
TSF_OBS_A
(8.1.8)
TSF_ALEAS_A
(8.1.10)
TSF_SKCS_A
(8.1.9)
FAU_SAS.1 (7.1.5) X X
FRU_FLT.2 (7.1.1) X X
FPT_FLS.1 (7.1.2) X X X X X
FMT_LIM.1 (7.1.3) X X
FMT_LIM.2 (7.1.4) X X
FPT_PHP.3 (7.1.6) X X X
FDP_ITT.1 (7.1.7) X X X X
FPT_ITT.1 (7.1.8) X X X X
FDP_IFC.1 (7.1.9) X X X X
FCS_RNG.1 (7.1.10) X
FDP_ACC.2 (7.1.14) X
FDP_ACF.1 (7.1.15) X
FMT_MSA.3 (7.1.12) X
FMT_MSA.1 (7.1.13) X
FCS_COP.1 (7.1.11) X
ST23YS64C Security Target - Public Version References
SMD_ST23YS64_ST_11_002 37/45
9 References
201 Protection Profile references
202 ST23YS64C Security Target reference
203 Target of Evaluation referenced documents
204 For security reasons, all these documents are classified and their applicable revisions are
referenced in the ST23YL Documentation Report.
205 Standards references
Component description Reference Revision
Security IC Platform Protection Profile BSI-PP-0035 1.0
Component description Reference
ST23YS64 Security Target SMD_ST23YS64_ST_11_001
Component description Reference
ST23YL Documentation Report SMD_ST23YL_DR_08_001
Identifier Description
BSI-AIS31
A proposal for Functionality classes and evaluation methodology for
true (physical) random number generators,
W. Killmann & W. Schindler
BSI, Version 3.1, 25-09-2001
NIST FIPS PUB-140-2:1999 Security Requirements for Cryptographic Modules
NIST FIPS PUB 180-2:2002 Secure Hash Standard
NIST FIPS PUB 186 Recommended simplified Rabin-Miller primality tests for DSS
ISO 8372:1987
Information processing - Modes of operation for a 64-bit block cipher
algorithm
ISO 8731-1:1987
Banking - Approved algorithms for message authentication -Part 1:
DEA
ISO/IEC 9796-2:1997
Information technology - Security techniques - Digital signature
scheme giving message recovery - Part 2: Mechanism using a hash
function
ISO/IEC 9797:1994
Information technology - Security techniques - Data integrity
mechanism using a cryptographic check function employing a block
cipher algorithm
ISO/IEC 10116:1997
Information technology - Modes of operation of an n-bit block cipher
algorithm
ISO/IEC 10118-3:1998
Information technology - Security techniques - Hash functions - Part
3: Dedicated hash functions
References ST23YS64C Security Target - Public Version
38/45 SMD_ST23YS64_ST_11_002
CCMB-2009-07-001
Common Criteria for Information Technology Security Evaluation -
Part 1: Introduction and general model, July 2009, version 3.1
Revision 3
CCMB-2009-07-002
Common Criteria for Information Technology Security Evaluation -
Part 2: Security functional components, July 2009, version 3.1
Revision 3
CCMB-2009-07-003
Common Criteria for Information Technology Security Evaluation -
Part 3: Security assurance components, July 2009, version 3.1
Revision 3
AUG
Smartcard Integrated Circuit Platform Augmentations,
Atmel, Hitachi Europe, Infineon Technologies, Philips
Semiconductors,
Version 1.0, March 2002.
MIT/LCS/TR-212
On digital signatures and public key cryptosystems,
Rivest, Shamir & Adleman
Technical report MIT/LCS/TR-212, MIT Laboratory for computer
sciences, January 1979
JoCSS
Riemann's hypothesis and tests for primality, Miller
Journal of computer and system sciences, vol 13 n°3 p300-317
JoNT
Probabilistic algorithm for testing primality, Miller
Journal of number theory, vol 12 n°1 p 128-138
Identifier Description
ST23YS64C Security Target - Public Version Glossary
SMD_ST23YS64_ST_11_002 39/45
Appendix A Glossary
A.1 Terms
Authorised user
A user who may, in accordance with the TSP, perform an operation.
Composite product
Security IC product which includes the Security Integrated Circuit (i.e. the TOE) and the
Embedded Software and is evaluated as composite target of evaluation.
Differential Power Analysis (DPA)
An analysis in variations of the electrical power consumption of a device, using
advanced statistical methods and/or error correction techniques, for the purpose of
extracting information correlated to secrets processed in the device. When several
consumption traces are recombined during analysis to remove counter-measures
adding random, the analysis is known as Higher Order DPA (HODPA).
End-consumer
User of the Composite Product in Phase 7.
Integrated Circuit (IC)
Electronic component(s) designed to perform processing and/or memory functions.
IC Dedicated Software
IC proprietary software embedded in a Security IC (also known as IC firmware) and
developed by ST. Such software is required for testing purpose (IC Dedicated Test
Software) but may provide additional services to facilitate usage of the hardware and/or
to provide additional services (IC Dedicated Support Software).
IC Dedicated Test Software
That part of the IC Dedicated Software which is used to test the TOE before TOE
Delivery but which does not provide any functionality thereafter.
IC developer
Institution (or its agent) responsible for the IC development.
IC manufacturer
Institution (or its agent) responsible for the IC manufacturing, testing, and pre-
personalization.
IC packaging manufacturer
Institution (or its agent) responsible for the IC packaging and testing.
Initialisation data
Initialisation Data defined by the TOE Manufacturer to identify the TOE and to keep
track of the Security IC’s production and further life-cycle phases are considered as
belonging to the TSF data. These data are for instance used for traceability and for
TOE identification (identification data)
Object
An entity within the TSC that contains or receives information and upon which subjects
perform operations.
Packaged IC
Security IC embedded in a physical package such as micromodules, DIPs, SOICs or
TQFPs.
Glossary ST23YS64C Security Target - Public Version
40/45 SMD_ST23YS64_ST_11_002
Pre-personalization data
Any data supplied by the Card Manufacturer that is injected into the non-volatile
memory by the Integrated Circuits manufacturer (Phase 3). These data are for instance
used for traceability and/or to secure shipment between phases.
Secret
Information that must be known only to authorised users and/or the TSF in order to
enforce a specific SFP.
Security IC
Composition of the TOE, the Security IC Embedded Software, User Data, and the
package.
Security IC Embedded SoftWare (SICESW)
Software embedded in the Security IC and not developed by the IC designer. The
Security IC Embedded Software is designed in Phase 1 and embedded into the
Security IC in Phase 3.
Security IC embedded software (SICESW) developer
Institution (or its agent) responsible for the security IC embedded software
development and the specification of IC pre-personalization requirements, if any.
Security attribute
Information associated with subjects, users and/or objects that is used for the
enforcement of the TSP.
Sensitive information
Any information identified as a security relevant element of the TOE such as:
– the application data of the TOE (such as IC pre-personalization requirements, IC
and system specific data),
– the security IC embedded software,
– the IC dedicated software,
– the IC specification, design, development tools and technology.
Simple Power Analysis (SPA)
A direct analysis, primarily visual, of patterns of instruction execution (or execution of
individual instructions), obtained through monitoring the variations in electrical power
consumption of a device, for the purpose of revealing the features and implementations
of (cryptographic) algorithms and subsequently the values of the secrets they process
in the device.
Smartcard
A card according to ISO 7816 requirements which has a non volatile memory and a
processing unit embedded within it.
Subject
An entity within the TSC that causes operations to be performed.
Test features
All features and functions (implemented by the IC Dedicated Software and/or
hardware) which are designed to be used before TOE Delivery only and delivered as
part of the TOE.
TOE Delivery
ST23YS64C Security Target - Public Version Glossary
SMD_ST23YS64_ST_11_002 41/45
The period when the TOE is delivered which is either (i) after Phase 3 (or before Phase
4) if the TOE is delivered in form of wafers or sawn wafers (dice) or (ii) after Phase 4 (or
before Phase 5) if the TOE is delivered in form of packaged products.
TSF data
Data created by and for the TOE, that might affect the operation of the TOE.
User
Any entity (human user or external IT entity) outside the TOE that interacts with the
TOE.
User data
All data managed by the Smartcard Embedded Software in the application context.
User data comprise all data in the final Smartcard IC except the TSF data.
Warm reset
Reset operation on the TOE without lowering power under the Power on Reset (POR)
level.
A.2 Abbreviations
Table 12. List of abbreviations
Term Meaning
AIS Application notes and Interpretation of the Scheme (BSI)
ALU Arithmetical and Logical Unit.
API Application Programming Interface.
BSI Bundesamt für Sicherheit in der Informationstechnik.
CBC Cipher Block Chaining.
CC Common Criteria Version 3.1.
CPU Central Processing Unit.
CRC Cyclic Redundancy Checkj.
DCSSI Direction Centrale de la Sécurité des Systèmes d’Information
DEMA Differential Electromagnetic Analysis.
DES Data Encryption Standard.
DIP Dual-In-Line Package.
DPA Differential Power Analysis.
DSW IC Proprietary Dedicated Software.
EAL Evaluation Assurance Level.
ECC Error Correcting Code.
EDES Enhanced DES.
EEPROM Electrically Erasable Programmable Read Only Memory.
EMA Electromagnetic Analysis.
FIPS Federal Information Processing Standard.
Glossary ST23YS64C Security Target - Public Version
42/45 SMD_ST23YS64_ST_11_002
HODPA Higher Order Differential Power Analysis.
I/O Input / Output.
IART ISO-7816 Asynchronous Receiver Transmitter.
IC Integrated Circuit.
ISO International Standards Organisation.
IT Information Technology.
MPU Memory Protection Unit.
NIST National Institute of Standards and Technology.
NVM Non Volatile Memory.
OSP Organisational Security Policy.
OST Operating System for Test.
OTP One Time Programmable.
POR Power on Reset.
PP Protection Profile.
PUB Publication Series.
RAM Random Access Memory.
ROM Read Only Memory.
RSA Rivest, Shamir & Adleman.
SAR Security Assurance Requirement.
SFP Security Function Policy.
SFR Security Functional Requirement.
SICESW Security IC Embedded SoftWare.
SOIC Small Outline IC.
SPA Simple Power Analysis.
ST Context dependent : STMicroelectronics or Security Target.
ST_ROM ST reserved ROM.
TOE Target of Evaluation.
TQFP Thin Quad Flat Package.
TRNG True Random Number Generator.
TSC TSF Scope of Control.
TSF TOE Security Functionality.
TSFI TSF Interface.
TST The logical phase TEST configuration.
TSP TOE Security Policy.
Table 12. List of abbreviations (continued)
Term Meaning
ST23YS64C Security Target - Public Version Glossary
SMD_ST23YS64_ST_11_002 43/45
TSS TOE Summary Specification.
USR_ROM User reserved ROM.
Table 12. List of abbreviations (continued)
Term Meaning
Revision history ST23YS64C Security Target - Public Version
44/45 SMD_ST23YS64_ST_11_002
10 Revision history
Table 13. Document revision history
Date Revision Changes
09-Sep-2011 01.00 Initial release.
ST23YS64C Security Target - Public Version
SMD_ST23YS64_ST_11_002 45/45
Please Read Carefully:
Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries (“ST”) reserve the
right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any
time, without notice.
All ST products are sold pursuant to ST’s terms and conditions of sale.
Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no
liability whatsoever relating to the choice, selection or use of the ST products and services described herein.
No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this
document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products
or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such
third party products or services or any intellectual property contained therein.
UNLESS OTHERWISE SET FORTH IN ST’S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED
WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS
OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.
UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZED ST REPRESENTATIVE, ST PRODUCTS ARE NOT
RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING
APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY,
DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE
GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER’S OWN RISK.
Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void
any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any
liability of ST.
ST and the ST logo are trademarks or registered trademarks of ST in various countries.
Information in this document supersedes and replaces all information previously supplied.
The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners.
© 2011 STMicroelectronics - All rights reserved
STMicroelectronics group of companies
Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan -
Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America
www.st.com