ASEPCOS-TS/CNS STMicroelectronics
Public Security Target
ASEPCOS-TS/CNS STM with Digital Signature Application
on ST23YR48/80 with NesLib v3.0
Version 1.1
August 30, 2010
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 2 of 38
Contents
1. ST INTRODUCTION................................................................................................................................4
1.1. ST IDENTIFICATION...............................................................................................................................4
1.2. COMPOSITE TOE ..................................................................................................................................5
1.3. ST OVERVIEW .......................................................................................................................................6
1.4. CC CONFORMANCE...............................................................................................................................7
2. TOE DESCRIPTION.................................................................................................................................8
2.1. GENERAL..............................................................................................................................................8
2.2. SECURE SIGNATURE CREATION DEVICES..............................................................................................9
2.3. LIMITS OF THE TOE............................................................................................................................10
2.4. TOE LIFE CYCLE.................................................................................................................................12
2.5. FEATURES OF THE TOE – INFORMATIONAL.........................................................................................14
3. CONFORMANCE CLAIMS ..................................................................................................................16
3.1. CC CONFORMANCE CLAIM.................................................................................................................16
3.2. PP CLAIM ...........................................................................................................................................16
4. TOE SECURITY ENVIRONMENT ......................................................................................................17
4.1. ASSETS ...............................................................................................................................................17
4.2. SUBJECTS............................................................................................................................................17
4.3. THREATS.............................................................................................................................................18
4.4. ORGANISATIONAL SECURITY POLICIES ...............................................................................................19
4.5. ASSUMPTIONS.....................................................................................................................................19
5. SECURITY OBJECTIVES.....................................................................................................................20
5.1. SECURITY OBJECTIVES FOR THE TOE.................................................................................................20
5.2. SECURITY OBJECTIVES FOR THE ENVIRONMENT.................................................................................21
6. EXTENDED COMPONENTS DEFINITION.......................................................................................23
6.1. TOE EMANATION (FPT_EMSEC.1) ...................................................................................................23
7. SECURITY REQUIREMENTS .............................................................................................................24
7.1. TOE SECURITY FUNCTIONAL REQUIREMENTS....................................................................................24
7.2. TOE SECURITY ASSURANCE REQUIREMENTS.....................................................................................33
8. TOE SUMMARY SPECIFICATION .....................................................................................................34
8.1. TOE SECURITY FUNCTIONS................................................................................................................34
9. RATIONALE............................................................................................................................................35
9.1. DEPENDENCIES RATIONALE................................................................................................................35
9.2. SECURITY REQUIREMENTS GROUNDING IN OBJECTIVES.....................................................................35
9.3. TOE SUMMARY SPECIFICATIONS RATIONALE.....................................................................................35
9.4. RATIONALE FOR EXTENSIONS .............................................................................................................35
9.5. PP CLAIM RATIONALE ........................................................................................................................35
10. TERMINOLOGY ................................................................................................................................36
11. REFERENCES.....................................................................................................................................38
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 3 of 38
List of Tables
TABLE 2 – ASSURANCE REQUIREMENTS: EAL4 AUGMENTED WITH AVA_VAN.5 ...............................................33
List of Figures
FIGURE 1 - TOE DESCRIPTION...............................................................................................................................8
FIGURE 2 - SSCD TYPES AND MODES OF OPERATION .............................................................................................9
FIGURE 3 - SCOPE OF THE SSCD, STRUCTURAL VIEW..........................................................................................11
FIGURE 4 - SSCD LIFE CYCLE..............................................................................................................................12
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 4 of 38
1. ST introduction
1.1. ST identification
ST title ASEPCOS-TS/CNS STM with Digital Signature Application
on ST23YR48/80 with NesLib v3.0
Authors Athena Smartcard Solutions
General Status Public
ST Version Number 1.1
Date of production August 30, 2010
TOE ASEPCOS TS/CNS Athena Smartcard
Version 1.82
Build 001
Corrective Patch Athena Smartcard
Build 003
ST23YR48/80 STMicroelectronics
Revision G
Configuration SB
Maskset K2M0A
Certificate ANSSI-CC-2010/02 [10]
NesLib ST Microelectronics
Version 3.0
Certificate ANSSI-CC-2010/02 [10]
Common Criteria CC version 3.1
Part 1: CCMB 2009-07-001 revision 3
Part 2: CCMB 2009-07-002 revision 3
Part 3: CCMB 2009-07-003 revision 3
PP Claim Protection Profile — Secure Signature-Creation Device Type 2
Version: 1.04, EAL 4+
Wednesday, 25 July 2001
Prepared By: ESIGN Workshop - Expert Group F
Identification PP0005b
Protection Profile — Secure Signature-Creation Device Type 3
Version: 1.05, EAL 4+
Wednesday, 25 July 2001
Prepared By: ESIGN Workshop - Expert Group F
Identification PP0006b
ANSSI-CC-2010/02 ―Microcontrôleurs sécurisés SA23YR48/80B et SB23YR48/80B, incluant la
bibliothèque cryptographique NesLib v2.0 ou v3.0 en configuration SA ou SB”
CC v3 .1
EAL 6+ (ALC_FLR.1)
Compliant to BSI-PP-0035-2007 version 1.0
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 5 of 38
1.2. Composite TOE
ASEPCOS TS/CNS with associated patch(s) is embedded on STMicroelectronics ST23YR48/80 IC.
The composition analysis conducted in this section will use the words:
- Platform to designate the STMicroelectronics ST23YR48/80 IC [15,8] with its cryptographic
library NesLib [14],
- Application to designate the Athena software components of ASEPCOS TS/CNS, and
- Composite Product to designate the TOE.
According to the Composite product documentation [16], the different roles considered in the
composition activities are associated as follows:
Platform Developer STMicroelectronics
Platform Evaluator Serma Technologies
Platform Certification Body ANSSI
Application Developer Athena
Composite Product Integrator STMicroelectronics
Composite Product Evaluator Thales
Composite Product Certification Body ANSSI
Composite Product evaluation Sponsor Athena
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 6 of 38
1.3. ST overview
This ST describes the security functions of the ASEPCOS with EU compliant Digital Signature
Application ‗TS/CNS‘ (Hereinafter referred to as the TOE). This configuration of ASEPCOS enforces
the security functions required for digital signature and supports usage only through secure trusted
communication channels. The TOE implements a Secure Signature Creation Device (SSCD) in
accordance with the European Directive 1999/93/EC [1] as a smart card which allows the generation
and importation of signature creation data (SCD) and the creation of qualified electronic signatures.
The TOE protects the SCD and ensures that only an authorized Signatory can use it.
ASEPCOS is a multi-application ISO7816 compatible smart card OS which supports RSA
cryptography of up to 2048 RSA.
The TOE meets all the following requirements as defined in the European Directive (article 2.2):
(a) it is uniquely linked to the signatory
(b) it is capable of identifying the signatory
(c) it is created using means that the signatory can maintain under his sole control
(d) it is linked to the data to which it relates in such a manner that any subsequent change of
the data is detectable
The underlying hardware platform on which the ASEPCOS software is implemented is the
STMicroelectronics ST23YR48/80 IC [15, 8] supporting contact and contactless interfaces. This IC is
certified according to CC EAL 6+ [10] and its Security Target is compliant with BSI-PP-0035-2007 [9].
The TOE consists of the software and hardware parts available in a variety of form factors:
1. Dual interface cards and modules 2. Contact only cards and modules
(antenna embedded
in plastic)
(contactless interface
absent or disabled)
3. SOIC8 package 4. QFN44 package 5. Chip on Board (PCB)
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 7 of 38
1.4. CC conformance
The ST is conformant to CC Version 3.1 Part 2 [3] (with extension made in SSCD PP [7]) and CC
Version 3.1 Part 3 [4].
The ST claims conformance to SSCD Type 2 Protection Profile [6] and SSCD Type 3 Protection
Profile [7]. These protections profiles are compliant to CC v2.3 and an analysis of conformity with CC
version 3.1 was conducted as part of this evaluation. See section 9.5 for more details.
The assurance level for this ST is EAL4+, augmented with AVA_VAN.5. The claimed PPs are
compliant with CC v2.3 and EAL4 augmented by AVA_MSU.3 and AVA_VLA.4, which translates in
CC v3.1 by an augmentation to AVA_VAN.5. See section 9.5 for more details.
The minimum strength level for the TOE security functions is ‗SOF High‘ (Strength of Functions
High).
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 8 of 38
2. TOE Description
2.1. General
The TOE is a module where digital application software is masked in ROM.
The TOE is linked to a card reader/writer via its HW and physical interfaces.
 The contact type interface of the TOE smartcard is ISO/IEC 7816 compliant.
 The contactless type interface of the TOE smartcard is ISO/IEC 14443 compliant.
 The interfaces of the TOE SOIC-8 are ISO 9141 compliant.
 The interfaces of the TOE QNF-44 are JEDEC compliant.
The TOE smartcard may be applied to a contact type card reader/writer or to a contactless card
reader/writer when the contactless interface of the smartcard is available. The card reader/writer is
connected to a computer such as a personal computer and allows application programs (APs) to use
the TOE.
Figure 2-1 shows the boundaries of the TOE within the module.
Figure 1 - TOE Description
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 9 of 38
2.2. Secure Signature Creation Devices
The following is an introduction to SSCD based on the SSCD Protection Profile [7] and [6].
The PP documents assume a well defined process signature-creation to take place. The present
chapter defines three possible SSCD implementations, referred to as ‗SSCD types‘, as illustrated in
Figure 2.
If the SSCD holds the SVD and exports the SVD to a CGA for certification, a trusted channel is to be
provided. The CGA initiates SCD/SVD generation (―Init.‖) and the SSCD exports the SVD for
generation of the corresponding certificate (―SVD into cert.‖).
The signatory must be authenticated to create signatures that he sends his authentication data (e.g.,
a PIN) to the SSCD Type 2 or Type 3 (e.g., a smart card). If the Human Interface (HI) for such
signatory authentication is not provided by the SSCD, and thus a trusted path (e.g., a encrypted
channel) between the SSCD and the SCA implementing to HI is to be provided. The data to be
signed (DTBS) representation (i.e., the DTBS itself, a hash value of the DTBS, or a pre-hashed
value of the DTBS) shall be transferred by the SCA to the SSCD only over a trusted channel. The
same shall apply to the signed data object (SDO) returned from a SSCD to the SCA.
SSCD Type 2 and 3 components are personalized components: they can be used for signature
creation by one specific user – the signatory - only.
* The trusted path for user authentication will be required if the HI is not provided by the TOE itself
(e. g., it is provided by a SCA outside the SSCD)
** The trusted channel between the SSCD Type 2 and the CGA is required for cases where the SSCD type 2 holds the SVD
and export of the SVD to the CGA for certification is provided
Figure 2 - SSCD types and modes of operation
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 10 of 38
2.3. Limits of the TOE
The TOE is a secure signature-creation device (combination of SSCD type 2 and type 3) according
to Directive 1999/93/ec of the European parliament and of the council of 13 December 1999 on a
Community framework for electronic signatures [1].The destruction of the SCD is mandatory before
the TOE generate a new pair SCD/SVD or loads a new pair SCD/SVD.
A SSCD is configured software or hardware used to implement the signature-creation data (SCD).
The smart card HW and Software in which the SSCD application is installed can contain additional
functions and files which are not related to the digital signature application and do not influence it or
interact with it in any way and are regarded as data structures. Such applications and files are
beyond the scope of this TOE.
The TOE described in this ST is a smart card operating system implemented on a smart card IC
which is certified CC EAL 6+. The TOE includes embeddable software in the NVM of the IC and a
file system including the digital signature application stored in EEPROM. Parts of the operating
systems may be stored in EEPROM. NVM (Non Volatile Memory) corresponds to ROM memory for
the STMicroelectronics ST23YR48/80 IC [15, 8].
The TOE provides the following functions necessary for devices involved in creating qualified
electronic signatures:
(1) to generate the SCD and the correspondent signature-verification data (SVD)
(2) to create qualified Electronic Signatures
(a) after allowing for the Data To Be Signed (DTBS) to be displayed correctly by the
appropriate environment
(b) using appropriate hash functions that are, according to [5], agreed as suitable for
qualified electronic signatures
(c) after appropriate authentication of the signatory by the TOE
(d) using appropriate cryptographic signature function that employ appropriate
cryptographic parameters agreed as suitable according to [5]
The generation of the SCD/SVD key pair by means of a SSCD type 1 requires the export of the SCD
into the TOE (Type 2). Vice versa, signature generation by means of the TOE (Type 2) requires that
the SCD/SVD has been generated by and imported from an SSCD Type 1, or has been generated
by the TOE itself. Consequently, there is interdependence where an SSCD Type 1 constitutes the
environment of the TOE.
The TOE implements all IT security functionality which are necessary to ensure the secrecy of the
SCD. To prevent the unauthorised usage of the SCD the TOE provides user authentication and
access control. The TOE may provide an interface for user authentication by its own or implements
IT measures to support a trusted path to a trusted human interface device.
This TOE does not implement, in addition to the functions of the SSCD, the signature-creation
application (SCA). The SCA presents the data to be signed (DTBS) to the signatory and prepares
the DTBS-representation the signatory wishes to sign for performing the cryptographic function of
the signature. The SCA is considered as part of the environment of the TOE.
The SSCD protects the SCD during the whole life cycle as to be solely used in the signature creation
process by the legitimate signatory. The TOE will be initialised for the signatory's use by
(1) importation of the SCD or generation of SCD/SVD pair
(2) personalization for the signatory by means of the signatory‘s verification authentication data
(VAD)
The SVD corresponding to the signatory's SCD will be included in the certificate of the signatory by
the certificate-service-provider (CSP). The TOE will destroy the SCD if the SCD is no longer used for
signature generation.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 11 of 38
The TOE allows to implement a Human Interface (HI) for user authentication:
(i) by the TOE itself or
(ii) by a trusted human interface device connected via a trusted channel with the TOE.
The human interface device is used for the input of VAD for authentication by knowledge or for the
generation of VAD for authentication by biometric characteristics. The TOE holds RAD to check the
provided VAD. The human interface implies appropriate hardware. The second approach allows to
reduce the TOE hardware to a minimum e. g. a smart card.
Figure 3 - Scope of the SSCD, structural view
Figure 3 shows the PP scope from the structural perspective. The SSCD, i.e. the TOE, comprises
the underlying hardware, the operating system (OS), the SCD/SVD generation, SCD storage and
use, and signature-creation functionality. The SCA and the CGA (and possibly other applications)
are part of the immediate environment of the TOE. They shall communicate with the TOE over a
trusted channel, a trusted path for the human interface provided by the SCA, respectively.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 12 of 38
2.4. TOE life cycle
The TOE life cycle is shown in Figure 4. Basically, it consists of a development phase and the
operational phase.
HW Design OS Design
Application
Design
HW Fabrication
OS and Application Implementation
Loading of General Application Data
Loading of Personal data
SCD/SVD import or generation
Signature-creation
Optional SCD/SVD generation
SSCD Destruction
Design
Fabrication
Initialisation
Personalisation
Usage
Development
Phase
Operational
Phase
IC Manufacturing
IC Packaging
Card Manufacturing
Integration
Figure 4 - SSCD life cycle
The integration phase is added to the PP generic lifecycle as this particular TOE requires that cards
production phase is refined.
2.4.1. Development Phase
HW Design – STMicroelectronics
OS Design – Athena Development department – Edinburgh, Scotland
Application Design – Athena Development department – Edinburgh, Scotland
2.4.2. Fabrication phase
HW Fabrication and OS & Application implementation – STMicroelectronics
The operating system part of the TOE which is developed by Athena is sent in a secure way to
STMicroelectronics for masking in NVM (both ROM and EEPROM). In addition to the TOE, the mask
contains confidential data, knowledge of which is required in order to initialize and personalize the
chip.
2.4.3. Integration phase
IC Manufacturing – STMicroelectronics
IC Packaging – STMicroelectronics or specialized companies such as NedCard
Card Manufacturing – STMicroelectronics or specialized companies such as Polygrafico, Cardag
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 13 of 38
This phase corresponds to the integration of the hardware and firmware components into the final
product body. In the case of this TOE it will be a smart card, but it could also be a USB token.
The TOE is protected during transfer between various parties.
IC Packaging and Card Manufacturing are not part of the scope of this TOE.
2.4.4. Operational Phase
The chip may be sent by STMicroelectronics to Athena or to a 3rd party initialization centre/card
manufacturer and Athena sends to itself or the 3rd party initialization centre the confidential
information required in order to proceed with initialization. Initialization may be done in parts at
various facilities (for example, start at Athena and continue in a 3rd Party or start at 3rd Party and
transfer to another 3rd Party) and personalization can be done by Athena, 3rd Party initialization
facility or Card Issuer/Customer. The TOE is protected during transfer between various parties by
the confidential information which resides in the card during mask production.
This ST addresses the functions used in the operational phases but developed during development
phase.
Initialization – Athena or 3rd Party initialization facility/Card Manufacturer which includes loading of
the General Application Data
Personalization – Athena or 3rd Party Personalization facility which includes the loading of Personal
Application Data and optional generation of the SCD/SVD pair if loading does not include importing
an SCD/SVD pair
Usage – Where upon the card is delivered from the Customer (the Card Issuer) to the End User and
the End User may use it for signature-creation including all supporting functionality (e.g., SCD
storage and SCD use) but only following a correct verification of the initial PIN-Activate PIN which
allows the End User to make sure that he is the first user to ever use this SCA for digital signature.
2.4.5. Application note: Scope of SSCD PP application
This ST refers to qualified certificates as electronic attestation of the SVD corresponding to the
signatory's SCD that is implemented by the TOE.
While the main application scenario of a SSCD will assume a qualified certificate to be used in
combination with a SSCD, there still is a large benefit in the security when such SSCD is applied in
other areas and such application is encouraged. The SSCD may as well be applied to environments
where the certificates expressed as 'qualified certificates' in the SSCD do not fulfil the requirements
laid down in Annex I and Annex II of the Directive [1].
When an instance of a SSCD is used with a qualified certificate, such use is from the technical point
of view eligible for an electronic signature as referred to in Directive [1], article 5, paragraph 1. This
Directive does not prevent TOE itself from being regarded as a SSCD, even when used together
with a non-qualified certificate.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 14 of 38
2.5. Features of the TOE – Informational
This section is information and intended to provide general details about the ASEPCOS-TS/CNS
STM OS which implements the TOE. Information in this section does not extend the TOE description
or claims of this ST.
ASEPCOS-TS/CNS STM is a general purpose multi-application cryptographic smart card operating
system supporting CNS, NetLink, Transport/ePurse applications and ICAO LDS. It complies with ISO
7816 and ISO14443.
ASEPCOS-TS/CNS STM is designed to comply with the Italian CNS specification, Netlink HPC/PDC
specifications, the Italian Digital Signature law and the European Electronic Signature Directive.
The API exposed by ASEPCOS allows for fast development of cryptographic supported applications
for National ID, ePassport, Enterprise ID, Healthcare, Transportation, and payment applications.
2.5.1. File System
Directory structure depth up to 8 levels
Maximum number of active authentication keys – 256
DF can have DF Name and/or DF-ID
Record files can have Binary or TLV records
Records can be accessed using current record pointer and tag value, in addition to record number
2.5.2. Features
ASEPCOS-TS/CNS STM is designed for the STMicroelectronics ST23 family of smart card
microprocessors and specifically the STMicroelectronics ST23YR48/80 IC [15, 8] certified according
to the CC EAL 6+ [10]. ASEPCOS is protected against state of the art attacks.
The OS:
 supports ISO 14443-4 Type B, ISO 7816-4, 8 and 9 standards
 supports PC/SC applications
 provides fast cryptography
 enforces smart memory management
 provides strong security and data integrity mechanisms
 has been designed with PKI in mind
 supports patching
Note that the corrective patch that is included in the TOE (EEPROM mask) disables the Patch
Loading Mechanism in addition to performing software corrections.
2.5.3. Secure Messaging
All commands can be secured
ASEPCOS-TS/CNS STM supports both CNS and ICAO Secure Messaging schemes (static keys
and session keys)
The OS supports extended length APDUs with data file length up to 64K bytes (ICAO mode).
2.5.4. Keys and security
ASEPCOS-TS/CNS STM provides up to 256 authentication keys (or PINS) under secure conditions.
Private RSA keys that are generated from internal random source are tagged. Application can
differentiate between keys that have never left the card and keys that were imported from outside.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 15 of 38
All keys have attributes that can help detect and prevent unauthorized usage and change of keys.
Authentication keys may have the AutoClear attribute. After such a key is used, the corresponding
bit in the security status is automatically cleared.
Security Status protects application‘s data from being accessed by other applications.
All DES keys are checked against ―weak key‖ values.
ECC keys are between 160 bits and 512 bits long.
2.5.5. Memory Management
All internal file system structures in non-volatile memory are updated using ―atomic operations‖. This
provides safe operations even when power is interrupted.
Key data integrity is verified using CRC16 each time before a key is used.
Deleted files are erased and returned to the ―free memory pool‖ for reuse.
DF can optionally have a ―size quota‖ (pre-allocated fixed memory area). Otherwise, a DF can
expand dynamically to the full memory capacity of the card.
2.5.6. Cryptography
Counter measures against state of the art attacks such as SPA/DPA/HO-DPA and Faults.
FIPS compatible Random Number Generator algorithm.
RSA signature calculation and verification according to PKCS#1 standard [12] and [13] (1024 to
2048 bits).
SHA1, SHA 256, and RIPEMD160 hash algorithms (ISO 7816-8 compatible).
3DES encryption and decryption (16 or 24 bytes, ECB and CBC modes).
3DES Message Authentication Code (16 or 24 bytes, MAC).
Key Pair generation (RSA).
AIS31 True RNG.
ECC 160 to 512 bits for Sign and Verify.
2.5.7. Performance
ASEPCOS-TS/CNS STM supports T=1 protocol, with speeds of up to 115200 baud/s, and T=CL,
with speeds up to 424000 baud/s.
Fast RSA Key Generation.
Fast implementation of Rabin-Miller prime-number test algorithm. The number of iterations is by
default according to the size of the key as per ANSSI recommendation, or can be set manually.
Fast RSA Signature Calculation.
All RSA private key operations (Signature Calculation, Internal Authentication, Decrypt) use the
Chinese Remainder Theorem, resulting in faster operations (this includes RSA private keys that are
imported as <d, n>).
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 16 of 38
3. Conformance Claims
3.1. CC Conformance Claim
The ST claims compliance with the following references:
- CC Version 3.1 Part 2 [1] extended
- CC Version 3.1 Part 3 [2]
Extensions are based on the Protection Profiles (PP [6] and PP [7]) presented in section 6:
- FPT_EMSEC.1 ‗TOE emanation‘
The assurance level for this ST is EAL 4 augmented with: AVA_VAN.5.
The minimum strength level for the TOE security functions is ‗SOF High‘ (Strength of Functions
High).
3.2. PP Claim
This ST claims compliance with:
[6] Protection Profile — Secure Signature-Creation Device Type 2
Version 1.04
Date Wednesday, 25 July 2001
Prepared by ESIGN Workshop - Expert Group F
Identification PP0005b
Approved by WS/E-SIGN on the 30 November 2001
Registration BSI-PP-0005-2002
[7] Protection Profile — Secure Signature-Creation Device Type 3
Version 1.05
Date Wednesday, 25 July 2001
Prepared by ESIGN Workshop - Expert Group F
Identification PP0006b
Approved by WS/E-SIGN on the 30 November 2001
Registration BSI-PP-0006-2002
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 17 of 38
4. TOE security environment
4.1. Assets
1. SCD: private key used to perform an electronic signature operation (confidentiality of the
SCD must be maintained).
2. SVD: public key linked to the SCD and used to perform an electronic signature verification
(integrity of the SVD when it is exported must be maintained).
3. DTBS and DTBS-representation: set of data, or its representation which is intended to be
signed (Their integrity must be maintained).
4. VAD: PIN, PUK, Activate-PIN code or biometrics data entered by the End User to perform a
signature operation, changing and unblocking (confidentiality and authenticity of the VAD as
needed by the authentication method employed)
5. RAD: Reference PIN, PUK, Activate-PIN code or biometrics authentication reference used to
identify and authenticate the End User (integrity and confidentiality of RAD must be
maintained)
6. Signature-creation function: Code of the SSCD dedicated to the generation of digital
signature of DTBS using the SCD (The quality of the function must be maintained so that it
can participate to the legal validity of electronic signatures)
7. Electronic signature: output of the Signature-creation function (Unforgeability of electronic
signatures must be assured).
Note: Biometrics is no supported by the TOE and thus Biometric Data and Authentication
Reference assets, as presented in the SSCD type 3 PP, are not included.
4.2. Subjects
Subjects Definition
S.User
End user of the TOE which can be identified as S.Admin or
S.Signatory
S.Admin
User who is in charge to perform the TOE initialization, TOE
personalization or other TOE administrative functions.
S.Signatory
User who holds the TOE and uses it on his own behalf or on behalf
of the natural or legal person or entity he represents.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 18 of 38
4.3. Threats
4.3.1. Threat agents
S.OFFCARD
Attacker. A human or process acting on his behalf being located outside
the TOE. The main goal of the S.OFFCARD attacker is to access
Application sensitive information. The attacker has a high level potential
attack and knows no secret.
4.3.2. Threats to Security
T.Hack_Phys Physical attacks through the TOE interfaces
An attacker interacts with the TOE interfaces to exploit vulnerabilities, resulting in arbitrary security
compromises. This threat addresses all the assets.
T.SCD_Divulg Storing, copying, and releasing of the signature-creation data
An attacker can store, copy, the SCD outside the TOE. An attacker can release the SCD during
generation, storage and use for signature-creation in the TOE.
T.SCD_Derive Derive the signature-creation data
An attacker derives the SCD from public known data, such as SVD corresponding to the SCD or
signatures created by means of the SCD or any other data communicated outside the TOE, which is
a threat against the secrecy of the SCD.
T.SVD_Forgery Forgery of the signature-verification data
An attacker forges the SVD presented by the TOE to the CGA. This results in loss of SVD integrity in
the certificate of the signatory.
T.DTBS_Forgery Forgery of the DTBS-representation
An attacker modifies the DTBS-representation sent by the SCA. Thus the DTBS-representation used
by the TOE for signing does not match the DTBS the signatory intended to sign.
T.SigF_Misuse Misuse of the signature-creation function of the TOE
An attacker misuses the signature-creation function of the TOE to create SDO for data the signatory
has not decided to sign. The TOE is subject to deliberate attacks by experts possessing a high
attack potential with advanced knowledge of security principles and concepts employed by the TOE.
T.Sig_Forgery Forgery of the electronic signature
An attacker forges the signed data object maybe together with its electronic signature created by the
TOE and the violation of the integrity of the signed data object is not detectable by the signatory or
by third parties. The signature generated by the TOE is subject to deliberate attacks by experts
possessing a high attack potential with advanced knowledge of security principles and concepts
employed by the TOE.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 19 of 38
T.Sig_Repud Repudiation of signatures
If an attacker can successfully threaten any of the assets, then the non repudiation of the electronic
signature is compromised. This results in the signatory being able to deny having signed data using
the SCD in the TOE under his control even if the signature is successfully verified with the SVD
contained in his un-revoked certificate.
T.SOFT_MOD Unauthorized Software Modification
Unauthorized modification of the Smart Card Embedded Software using the patch mechanism.
4.4. Organisational Security Policies
P.CSP_QCert Qualified certificate
The CSP uses a trustworthy CGA to generate the qualified certificate for the SVD generated by the
SSCD. The qualified certificates contains at least the elements defined in Annex I of the Directive,
i.e., inter alias the name of the signatory and the SVD matching the SCD implemented in the TOE
under sole control of the signatory. The CSP ensures that the use of the TOE is evident with
signatures through the certificate or other publicly available information.
P.QSign Qualified electronic signatures
The signatory uses a signature-creation system to sign data with qualified electronic signatures. The
DTBS are presented to the signatory by the SCA. The qualified electronic signature is based on a
qualified certificate (according to directive Annex 1) and is created by a SSCD.
P.Sigy_SSCD TOE as secure signature-creation device
The TOE implements the SCD used for signature creation under sole control of the signatory. The
SCD used for signature generation can practically occur only once.
4.5. Assumptions
A.CGA Trustworthy certification-generation application
The CGA protects the authenticity of the signatory‘s name and the SVD in the qualified certificate by
an advanced signature of the CSP.
A.SCA Trustworthy signature-creation application
The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS-representation
of data the signatory wishes to sign in a form appropriate for signing by the TOE.
A.SCD_Generate Trustworthy SCD/SVD generation
If a party other than the signatory generates the SCD/SVD-pair of a signatory, then
(a) this party will use a SSCD for SCD/SVD-generation,
(b) confidentiality of the SCD will be guaranteed until the SCD is under the sole control
of the signatory and
(c) the SCD will not be used for signature-creation until the SCD is under the sole
control of the signatory.
(d) The generation of the SCD/SVD is invoked by authorised users only
(e) The SSCD Type1 ensures the authenticity of the SVD it has created an exported
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 20 of 38
5. Security Objectives
This section identifies and defines the security objectives for the TOE and its environment. Security
objectives reflect the stated intent and counter the identified threats, as well as comply with the
identified organizational security policies and assumptions.
5.1. Security Objectives for the TOE
OT.EMSEC_Design Provide physical emanations security
Design and build the TOE in such a way as to control the production of intelligible emanations
within specified limits.
OT.Lifecycle_Security Lifecycle security
The TOE shall detect flaws during the initialization, personalization and operational usage. The
TOE shall provide safe destruction techniques for the SCD in case of re-import or re-generation.
OT.Init SCD/SVD generation
The TOE provides security features to ensure that the generation of the SCD and the SVD is
invoked by authorized users only
OT.SCD_Secrecy Secrecy of the signature-creation data
The secrecy of the SCD (used for signature generation) is reasonably assured against attacks
with a high attack potential.
OT.SCD_SVD_Corresp Correspondence between SVD and SCD
The TOE shall ensure the correspondence between the SVD and the SCD. The TOE shall verify
the correspondence between the SCD and the SVD when they are generated by the TOE on
demand. The TOE shall verify on demand the correspondence between the SCD stored in the
TOE and the SVD if it has been sent to the TOE.
OT.SVD_Auth_TOE TOE ensures authenticity of the SVD
The TOE provides means to enable the CGA to verify the authenticity SVD that has been
exported by that TOE.
OT.Tamper_ID Tamper detection
The TOE provides system features that detect physical tampering of a system component, and
use those features to limit security breaches.
OT.Tamper_Resistance Tamper resistance
The TOE prevents or resists physical tampering with specified system devices and components.
OT.SCD_Unique Uniqueness of the signature-creation data
The TOE shall ensure the cryptographic quality of the SCD/SVD pair for the qualified electronic
signature. The SCD used for signature generation can practically occur only once and cannot be
reconstructed from the SVD. In that context ‗practically occur once‘ means that the probability of
equal SCDs is negligible low.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 21 of 38
OT.DTBS_Integrity_TOE Verification of the DTBS-representation integrity
The TOE shall verify that the DTBS-representation received from the SCA has not been altered
in transit between the SCA and the TOE. The TOE itself shall ensure that the DTBS-
representation is not altered by the TOE as well. Note, that this does not conflict with the
signature-creation process where the DTBS itself could be hashed by the TOE.
OT.Sigy_SigF Signature generation function for the legitimate signatory only
The TOE provides the signature generation function for the legitimate signatory only and
protects the SCD against the use of others. The TOE shall resist attacks with high attack
potential.
OT.Sig_Secure Cryptographic security of the electronic signature
The TOE generates electronic signatures that cannot be forged without knowledge of the SCD
through robust encryption techniques. The SCD cannot be reconstructed using the electronic
signatures. The electronic signatures shall be resistant against these attacks, even when
executed with a high attack potential.
OT.SCD_Transfer Secure transfer of SCD between SSCD
The TOE shall ensure the confidentiality of the SCD transferred between SSCDs.
OT.Patch_End Secure Patch Termination
The TOE shall ensure that a mechanism to close the TOE patching mechanism is available to
the Administrator. Terminating patching feature implies that it is not possible for an attacker to
load any patch in the card.
OT.Patch_Integrity Patch code and data integrity
The TOE shall ensure that the integrity of code and data loaded in a corrective patch cannot be
altered and then used. The patched code (i.e. original code) could not be recovered and the
patched data could not be changed.
5.2. Security Objectives for the Environment
Because ASEPCOS-TS/CNS STM is both SSCD type 2 and SSCD type3 means that the TOE
environment consists of a CGA, an SCA, an SSCD type 1 and a specific development environment.
OE.CGA_QCert Generation of qualified certificates
The CGA generates qualified certificates which include inter alia
(f) the name of the signatory controlling the TOE,
(g)the SVD matching the SCD implemented in the TOE under sole control of the signatory,
(h)the advanced signature of the CSP
OE.SVD_Auth_CGA CGA verifies the authenticity of the SVD
The CGA verifies that the SSCD is the sender of the received SVD and the integrity of the
received SVD. The CGA verifies the correspondence between the SCD in the SSCD of the
signatory and the SVD in the qualified certificate.
OE.HI_VAD Protection of the VAD
If an external device provides the human interface for user authentication, this device will ensure
confidentiality and integrity of the VAD as needed by the authentication method employed.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 22 of 38
OE.SCA_Data_Intend Data intended to be signed
The SCA
(a)generates the DTBS-representation of the data that has been presented as DTBS and
which the signatory intends to sign in a form which is appropriate for signing by the TOE,
(b)sends the DTBS-representation to the TOE and enables verification of the integrity of the
DTBS-representation by the TOE
(c) attaches the signature produced by the TOE to the data or provides it separately
OE.SCD_SVD_Corresp Correspondence between SVD and SCD
The SSCD Type1 shall ensure the correspondence between the SVD and the SCD. The SSVD
Type1 shall verify the correspondence between the SCD sent to the TOE and the SVD sent to
the CGA or TOE.
OE.SCD_Transfer Secure transfer of SCD between SSCD
The SSCD Type1 shall ensure the confidentiality of the SCD transferred to the TOE. The SSCD
Type1 shall prevent the export of a SCD that already has been used for signature generation by
the SSCD Type2. The SCD shall be deleted from the SSCD Type1 whenever it is exported into
the TOE.
OE.SCD_Unique Uniqueness of the signature-creation data
The SSCD Type1 shall ensure the cryptographic quality of the SCD/SVD pair for the qualified
electronic signature. The SCD used for signature generation can practically occur only once and
cannot be reconstructed from the SVD. In that context ‗practically occur once‘ means that the
probability of equal SCDs is negligible low.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 23 of 38
6. Extended Components Definition
This ST contains the following extended component:
- SFR FPT_EMSEC.1 ‗TOE emanation‘
6.1. TOE emanation (FPT_EMSEC.1)
Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component levelling:
FPT_EMSEC.1 TOE Emanation has two constituents:
- FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible
emissions enabling access to TSF data or user data.
- FPT_EMSEC.1.2 Interface Emanation requires not to emit interface emanation
enabling access to TSF data or user data.
Management: FPT_EMSEC.1
There are no management activities foreseen.
Audit: FPT_EMSEC.1
There are no actions identified that should be auditable if FAU_GEN Security audit data
generation is included in the PP/ST.
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No other components.
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to [assignment: list of types
of TSF data] and [assignment: list of types of user data].
FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use the
following interface [assignment: type of connection] to gain access to
[assignment: list of types of TSF data] and [assignment: list of types of
user data].
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 24 of 38
7. Security Requirements
This chapter gives the security functional requirements and the security assurance requirements for
the TOE and the environment.
Security functional requirements components given in section 7.1, except FPT_EMSEC.1 which is
explicitly stated, are drawn from Common Criteria part 2 v2.3: they are extracted from the claimed
PPs which have been certified before CC v3.0 was issued. The content of the SFRs present in this
ST have not been impacted by the CC v3.1: FDP_ITC.1 and FDP_SDI.1 have only been rephrased.
Some security functional requirements represent extensions to [3]. Operations for assignment,
selection and refinement have been made and are designated by an underline, in addition, where
operations that were uncompleted in the PP [7] are also identified by italic underlined type.
The TOE security assurance requirements statement given in section 7.2 is drawn from the security
assurance components from Common Criteria part 3 [4].
Section Error! Reference source not found. identifies the IT security requirements that are to be
met by the TOE IT environment.
The non-IT environment is described in section Error! Reference source not found..
7.1. TOE Security Functional Requirements
7.1.1. Cryptographic support (FCS)
7.1.1.1. Cryptographic key generation (FCS_CKM.1)
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm RSA and specified cryptographic
key sizes between 1024 bit and 2048 bit that meet the following:
Algorithms and parameters for algorithms [5].
7.1.1.2. Cryptographic key destruction (FCS_CKM.4)
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in case of re-importation and
regeneration of a new SCD in accordance with a specified cryptographic
key destruction method overwriting old key with new key that meets the
following: none.
Application notes:
The cryptographic key SCD will be destroyed on demand of the Signatory or Administrator. The
destruction of the SCD is mandatory before the SCD/SVD pair is re-generated by the TOE.
Re-importation is not supported by the TOE.
7.1.1.3. Cryptographic operation (FCS_COP.1)
FCS_COP.1.1/
CORRESP
The TSF shall perform SCD / SVD correspondence verification in
accordance with a specified cryptographic algorithm RSA and
cryptographic key sizes between 1024 bit and 2048 bit that meet the
following: Algorithms and parameters for algorithms [5].
FCS_COP.1.1/
SIGNING
The TSF shall perform digital signature-generation in accordance with a
specified cryptographic algorithm RSA and cryptographic key sizes
between 1024 bit and 2048 bit that meet the following: Algorithms and
parameters for algorithms [5].
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 25 of 38
7.1.2. User data protection (FDP)
7.1.2.1. Subset access control (FDP_ACC.1)
FDP_ACC.1.1/
SVD Transfer SFP
The TSF shall enforce the SVD Transfer SFP on import and on export of
SVD by User.
Application note:
FDP_ACC.1/SVD Transfer SFP is only required to protect the exportation of the SVD as the SVD is
never imported from an SSCD type 1 into the TOE. Actually, this TOE only provides SCD/SVD
import with a fixed SVD that is known by the TOE: only SCD is transferred during an SCD/SVD
import.
FDP_ACC.1.1/
SCD Import SFP
The TSF shall enforce the SCD Import SFP on Import of SCD by User.
FDP_ACC.1.1/
Initialisation SFP
The TSF shall enforce the Initialisation SFP on generation of
SCD/SVD pair by User.
FDP_ACC.1.1/
Personalisation SFP
The TSF shall enforce the Personalisation SFP on creation of RAD by
Administrator.
FDP_ACC.1.1/
Signature Creation SFP
The TSF shall enforce the Signature-creation SFP on
1. sending of DTBS-representation by SCA,
2. signing of DTBS-representation by Signatory.
7.1.2.2. Security attribute based access control (FDP_ACF.1)
The security attributes for the user, TOE components and related status are:
User, subject or object the
attribute is associated with
Attribute Status
General attribute
User Role Administrator, Signatory
Initialization attribute
User SCD / SVD management authorized, not authorized
SCD Secure SCD import allowed No, yes
Signature-creation attribute group
SCD SCD operational no, yes
DTBS sent by an authorized SCA no, yes
Initialisation SFP
FDP_ACF.1.1/
Initialisation SFP
The TSF shall enforce the Initialisation SFP to objects based on the
following: General attribute and Initialisation attribute.
FDP_ACF.1.2/
Initialisation SFP
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
The user with the security attribute ―role‖ set to ―Administrator‖ or set to
―Signatory‖ and with the security attribute ―SCD / SVD management‖ set to
―authorised‖ is allowed to generate SCD/SVD pair.
FDP_ACF.1.3/
Initialisation SFP
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 26 of 38
FDP_ACF.1.4/
Initialisation SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
The user with the security attribute ―role‖ set to ―Administrator‖ or set to
―Signatory‖ and with the security attribute ―SCD / SVD management‖ set to
―not authorised‖ is not allowed to generate SCD/SVD pair.
SVD Transfer SFP
FDP_ACF.1.1/
SVD Transfer SFP
The TSF shall enforce the SVD Transfer SFP to objects based on the
following: General attribute.
FDP_ACF.1.2/
SVD Transfer SFP
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
The user with the security attribute ―role‖ set to ―Administrator‖ or to
―Signatory‖ is allowed to export SVD.
FDP_ACF.1.3/
SVD Transfer SFP
The TSF shall explicitly authorise access of subjects to objects based
On the following additional rules: none.
FDP_ACF.1.4/
SVD Transfer SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
none.
SCD Import SFP
FDP_ACF.1.1/
SCD Import SFP
The TSF shall enforce the SCD Import SFP to objects based on the
following: General attribute and Initialisation attribute group.
FDP_ACF.1.2/
SCD Import SFP
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
The user with the security attribute ―role‖ set to ―Administrator‖ or to
―Signatory‖ and with the security attribute ―SCD / SVD management‖ set to
―authorised‖ is allowed to import SCD if the security attribute ―secure SCD
import allowed‖ is set to ―yes‖.
FDP_ACF.1.3/
SCD Import SFP
The TSF shall explicitly authorise access of subjects to objects based
On the following additional rules: none.
FDP_ACF.1.4/
SCD Import SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) The user with the security attribute ―role‖ set to ―Administrator‖ or to
―Signatory‖ and with the security attribute ―SCD / SVD management‖ set
to ―not authorised‖ is not allowed to import SCD if the security attribute
―secure SCD import allowed‖ is set to ―yes‖.
(b) The user with the security attribute ―role‖ set to ―Administrator‖ or to
―Signatory‖ and with the security attribute ―SCD / SVD management‖ set
to ―authorised‖ is not allowed to import SCD if the security attribute
―secure SCD import allowed‖ is set to ―no‖.
Personalisation SFP
FDP_ACF.1.1/
Personalisation SFP
The TSF shall enforce the Personalisation SFP to objects based on the
following: General attribute.
FDP_ACF.1.2/
Personalisation SFP
The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed:
User with the security attribute ―role‖ set to ―Administrator‖ is allowed to
create the RAD.
FDP_ACF.1.3/
Personalisation SFP
The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: none.
FDP_ACF.1.4/
Personalisation SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
none
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 27 of 38
Signature-creation SFP
FDP_ACF.1.1/
Signature Creation SFP
The TSF shall enforce the Signature-creation SFP to objects based on
the following: General attribute and Signature-creation attribute group.
FDP_ACF.1.2/
Signature Creation SFP
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
User with the security attribute ―role‖ set to ―Signatory‖ is allowed to
create electronic signatures for DTBS sent by an authorised SCA with
SCD by the Signatory which security attribute ―SCD operational‖ is set to
―yes‖.
FDP_ACF.1.3/
Signature Creation SFP
The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: none.
FDP_ACF.1.4/
Signature Creation SFP
The TSF shall explicitly deny access of subjects to objects based on the
rules:
(a) User with the security attribute ―role‖ set to ―Signatory‖ is not
allowed to create electronic signatures for DTBS which is not sent by an
authorised SCA with SCD by the Signatory which security attribute ―SCD
operational‖ is set to ―yes‖.
(b) User with the security attribute ―role‖ set to ―Signatory‖ is not
allowed to create electronic signatures for DTBS sent by an authorised
SCA with SCD by the Signatory which security attribute ―SCD
operational‖ is set to ―no‖.
7.1.2.3. Export of user data without security attributes (FDP_ETC.1)
FDP_ETC.1.1/
SVD Transfer
The TSF shall enforce the SVD Transfer SFP when exporting user data,
controlled under the SFP(s), outside of the TOE.
FDP_ETC.1.2/
SVD Transfer
The TSF shall export the user data without the user data's associated security
attributes.
7.1.2.4. Import of user data without security attributes (FDP_ITC.1)
FDP_ITC.1.1/
SCD
The TSF shall enforce the SCD Import SFP when importing user data,
controlled under the SFP, from outside of the TOE.
FDP_ITC.1.2/
SCD
The TSF shall ignore any security attributes associated with the user data
when imported from outside the TOE.
FDP_ITC.1.3/
SCD
The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: SCD shall be sent by an authorised
SSCD.
Application note:
An SSCD of Type 1 is authorised to send SCD to an SSCD of Type 2, if it is designated to generate
the SCD for this SSCD of Type 2 and to export the SCD for import into this SSCD of Type 2.
Authorised SSCD of Type 1 is able to establish a trusted channel to the SSCD of Type 2 for SCD
transfer as required by FTP_ITC.1.3/SCD export.
FDP_ITC.1.1/
DTBS
The TSF shall enforce the Signature-creation SFP when importing user data,
controlled under the SFP, from outside of the TOE.
FDP_ITC.1.2/
DTBS
The TSF shall ignore any security attributes associated with the user data
when imported from outside the TOE.
FDP_ITC.1.3/
DTBS
The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TOE: DTBS-representation shall be sent by an
authorised SCA.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 28 of 38
Application note:
An SCA is authorised to send the DTBS-representation if it is actually used by the Signatory to
create an electronic signature and able to establish a trusted channel to the SSCD as required by
FTP_ITC.1.3/SCA DTBS.
7.1.2.5. Subset residual information protection (FDP_RIP.1)
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is
made unavailable upon the de-allocation of the resource from the following
objects: SCD, VAD, RAD.
7.1.2.6. Stored data integrity monitoring and action (FDP_SDI.2)
The following data persistently stored by TOE have the user data attribute "integrity checked
persistent stored data" (integrity redundancy code):
1. SCD
2. RAD
3. SVD (if persistent stored by TOE)
4. Corrective patch code and data
FDP_SDI.2.1/
Persistent
The TSF shall monitor user data stored in containers controlled by the TSF for
integrity error on all objects, based on the following attributes: integrity
checked persistent data.
FDP_SDI.2.2/
Persistent
Upon detection of a data integrity error, the TSF shall
1. prohibit the use of the altered data
2. inform the Signatory about integrity error.
The DTBS-representation temporarily stored by TOE has the user data attribute "integrity checked
stored data":
FDP_SDI.2.1/
DTBS
The TSF shall monitor user data stored in containers controlled by the TSF for
integrity error on all objects, based on the following attributes: integrity
checked stored data.
FDP_SDI.2.2/
DTBS
Upon detection of a data integrity error, the TSF shall
1. prohibit the use of the altered data
2. inform the Signatory about integrity error.
7.1.2.7. Basic data exchange confidentiality (FDP_UCT.1)
FDP_UCT.1.1/
Receiver
The TSF shall enforce the SCD Import SFP to be able to receive user data in
a manner protected from unauthorised disclosure.
7.1.2.8. Data exchange integrity (FDP_UIT.1)
FDP_UIT.1.1/
SVD Transfer
The TSF shall enforce the SVD Transfer SFP to be able to transmit user data
in a manner protected from modification and insertion errors.
FDP_UIT.1.2/
SVD Transfer
The TSF shall be able to determine on receipt of user data, whether
modification and insertion has occurred.
FDP_UIT.1.1/
TOE DTBS
The TSF shall enforce the Signature-creation SFP to be able to receive the
DTBS-representation in a manner protected from modification, deletion and
insertion errors.
FDP_UIT.1.2/
TOE DTBS
The TSF shall be able to determine on receipt of user data, whether
modification, deletion and insertion has occurred.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 29 of 38
7.1.3. Identification and authentication (FIA)
7.1.3.1. Authentication failure handling (FIA_AFL.1)
FIA_AFL.1.1 The TSF shall detect when a certain number of unsuccessful authentication
attempts occur related to: RAD authentication (3 attempts are allowed) and
PUK authentication (10 attempts are allowed).
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
met or surpassed, the TSF shall block RAD.
7.1.3.2. User attribute definition (FIA_ATD.1)
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: RAD.
7.1.3.3. Timing of authentication (FIA_UAU.1)
FIA_UAU.1.1 The TSF shall allow
1. Identification of the user by means of TSF required by FIA_UID.1.
2. Establishing a trusted path between the TOE and a SSCD of Type 1 by
means of TSF required by FTP_ITC.1/SCD Import
3. Establishing a trusted path between local user and the TOE by means
of TSF required by FTP_TRP.1/TOE
4. Establishing a trusted channel between the SCA and the TOE by
means of TSF required by FTP_ITC.1/DTBS import.
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
Application note:
―Local user‖ mentioned in component FIA_UAU.1.1 is the user using the trusted path provided
between the SGA in the TOE environment and the TOE as indicated by FTP_TRP.1/SCA and
FTP_TRP.1/TOE.
7.1.3.4. Timing of identification (FIA_UID.1)
FIA_UID.1.1 The TSF shall allow
1. Establishing a trusted channel between the TOE and a SSCD of Type
1 by means of TSF required by FTP_ITC.1/SCD import.
2. Establishing a trusted path between local user and the TOE by means
of TSF required by FTP_TRP.1/TOE.
3. Establishing a trusted channel between the SCA and the TOE by
means of TSF required by FTP_ITC.1/DTBS import.
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
7.1.4. Security management (FMT)
7.1.4.1. Management of security functions behaviour (FMT_MOF.1)
FMT_MOF.1/
Sign
The TSF shall restrict the ability to enable the functions signature-creation
function to Signatory.
FMT_MOF.1/
Patch
The TSF shall restrict the ability to disable the functions Patching to
Administrator.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 30 of 38
7.1.4.2. Management of security attributes (FMT_MSA.1)
FMT_MSA.1.1/
Administrator
The TSF shall enforce the SCD Import SFP and Initialisation SFP to restrict
the ability to modify the security attributes SCD/SVD management and Secure
SCD import allowed to Administrator.
FMT_MSA.1.1/
Signatory
The TSF shall enforce the Signature-creation SFP to restrict the ability to
modify the security attributes SCD operational to Signatory.
7.1.4.3. Secure security attributes (FMT_MSA.2)
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for security
attributes.
7.1.4.4. Static attribute initialisation (FMT_MSA.3)
FMT_MSA.3.1 The TSF shall enforce the SCD Import SFP, Initialisation SFP and Signature-
creation SFP to provide restrictive default values for security attributes that
are used to enforce the SFP.
Refinement: The security attribute of the SCD ―SCD operational‖ is set to ―No‖ after generation or
Importation of the SCD. Also, the security Attribute of the SCD ―Secure SCD import allowed‖ is set to
―No‖ after creation of the SCD by the Administrator.
FMT_MSA.3.2 The TSF shall allow the Administrator to specify alternative initial values to
override the default values when an object or information is created.
7.1.4.5. Management of TSF data (FMT_MTD.1)
FMT_MTD.1.1 The TSF shall restrict the ability to modify or unblock the RAD to Signatory.
7.1.4.6. Specifications of Management Functions (FMT_SMF.1)
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
functions: RAD creation, RAD Modification, Access Condition Management,
Patching termination.
7.1.4.7. Security roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the roles Administrator and Signatory.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
7.1.5. Protection of the TSF (FPT)
7.1.5.1. TOE Emanation (FPT_EMSEC.1)
FPT_EMSEC.1.1 The TOE shall not emit information of IC Power consumption in excess of
State of the Art values enabling access to RAD and SCD.
FPT_EMSEC.1.2 The TSF shall ensure S.OFFCARD is unable to use the following interface
physical chip contacts and contactless I/O to gain access to RAD and SCD.
Application note:
The TOE shall prevent attacks against the SCD and other secret data where the attack is based on
external observable physical phenomena of the TOE. Such attacks may be observable at the
interfaces of the TOE or may origin from internal operation of the TOE or may origin by an attacker
that varies the physical environment under which the TOE operates. The set of measurable physical
phenomena is influenced by the technology employed to implement the TOE. Examples of
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 31 of 38
measurable phenomena are variations in the power consumption, the timing of transitions of internal
states, electromagnetic radiation due to internal operation, radio emission.
Due to the heterogeneous nature of the technologies that may cause such emanations, evaluation
against state-of-the-art attacks applicable to the technologies employed by the TOE is assumed.
Examples of such attacks are, but are not limited to, evaluation of TOE‘s electromagnetic radiation,
simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc.
7.1.5.2. Failure with preservation of secure state (FPT_FLS.1)
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur: Random Number Generation failure, EEPROM failure, out of range
temperature, clock and voltage of chip.
7.1.5.3. Passive detection of physical attack (FPT_PHP.1)
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that
might compromise the TSF.
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical tampering
with the TSF's devices or TSF's elements has occurred.
7.1.5.4. Resistance to physical attack (FPT_PHP.3)
FPT_PHP.3.1 The TSF shall resist Physical Intrusions to the IC Hardware by responding
automatically such that the SFRs are always enforced.
7.1.5.5. Testing of external entities (FPT_TEE.1)
FPT_TEE.1.1 The TSF shall run a suite of tests during initial start-up to check the fulfilment
of the correct operation of the underlying cryptography and RNG, memory
initialization, and the integrity of TOE sensitive properties.
FPT_TEE.1.2 If the test fails, the TSF shall enter a mute state and possibly get
TERMINATED.
7.1.5.6. TSF testing (FPT_TST.1)
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up or before running a
secure operation to demonstrate the correct operation of the TSF.
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity
of TSF data.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity
of stored TSF executable code.
7.1.6. Trusted path/channels (FTP)
7.1.6.1. Inter-TSF trusted channel (FTP_ITC.1)
FTP_ITC.1.1/
SCD Import
The TSF shall provide a communication channel between itself and a remote
trusted IT product that is logically distinct from other communication channels
and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
FTP_ITC.1.2/
SCD Import
The TSF shall permit the remote trusted IT product to initiate communication
via the trusted channel.
FTP_ITC.1.3/
SCD Import
The TSF or the trusted IT shall initiate communication via the trusted channel
for SCD Import.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 32 of 38
FTP_ITC.1.1/
SVD Transfer
The TSF shall provide a communication channel between itself and a remote
trusted IT product that is logically distinct from other communication channels
and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
FTP_ITC.1.2/
SVD Transfer
The TSF shall permit the remote trusted IT product to initiate communication
via the trusted channel.
FTP_ITC.1.3/
SVD Transfer
The TSF or the trusted IT shall initiate communication via the trusted channel
for transfer of SVD.
FTP_ITC.1.1/
DTBS Import
The TSF shall provide a communication channel between itself and a remote
trusted IT product that is logically distinct from other communication channels
and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
FTP_ITC.1.2/
DTBS Import
The TSF shall permit the remote trusted IT product to initiate communication
via the trusted channel.
FTP_ITC.1.3/
DTBS Import
The TSF or the trusted IT shall initiate communication via the trusted channel
for signing DTBS-representation.
Refinement
The mentioned remote trusted IT products are: an SSCD type 1 for SVD import, the CGA for the
SVD export, and the SCA for DTBS Import.
7.1.6.2. Trusted path (FTP_TRP.1)
The trusted path between the TOE and the SCA will be required only if the human interface for user
authentication is not provided by the TOE itself but by the SCA.
FTP_TRP.1.1/
TOE
The TSF shall provide a communication path between itself and local users
that is logically distinct from other communication paths and provides assured
identification of its end points and protection of the communicated data from
modification or disclosure.
FTP_TRP.1.2/
TOE
The TSF shall permit local users to initiate communication via the trusted path.
FTP_TRP.1.3/
TOE
The TSF shall require the use of the trusted path for initial user authentication.
Refinement:
The local and initial user who can communicate and authenticate with the TOE via a trusted path is
the Signatory only.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 33 of 38
7.2. TOE Security Assurance Requirements
TOE Security Assurance Requirements as stated in section 5.2 of SSCD PPs [7] and [6].
AVA_VAN is augmented from 3 to 5 compared to the CC V3.1 package for EAL4.
This augmentation in CC v3.1 complies with the augmentation required by the claimed Protection
Profiles [7] and [6].
7.2.1. SARs Measures
The assurance measures that satisfy the TOE security assurance requirements are the following:
Table 1 – Assurance Requirements: EAL4 augmented with AVA_VAN.5
Assurance Class Component Description
ADV:
Development
ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3 Basic modular design
AGD:
Guidance documents
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC:
Life cycle support
ALC_CMC.4
Production support, acceptance procedures and
automation
ALC_CMS.4 Problem of Tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.1 Identification of security measures
ALC_LCD.1 Developer defined life cycle model
ALC_TAT.1 Well defined development tools
ASE:
Security Target evaluation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
ATE:
Test
ATE_COV.2 Analysis of coverage
ATE_DPT.2 Testing: security enforcing modules
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
AVA:
Vulnerability assessment
AVA_VAN.5 Advanced methodical vulnerability analysis
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 34 of 38
8. TOE summary specification
8.1. TOE Security Functions
Description of TOE Security Functions:
- SF.Access Control
- SF.Identification and Authentication
- SF.Signature Creation
- SF.Secure Messaging
- SF.Crypto
- SF.Protection
Details of the TSFs is not provided in the Public version of the Security Target.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 35 of 38
9. Rationale
9.1. Dependencies Rationale
Not provided in the Public version of the Security Target.
9.2. Security Requirements Grounding in Objectives
Not provided in the Public version of the Security Target.
9.3. TOE Summary Specifications Rationale
Not provided in the Public version of the Security Target.
9.4. Rationale for Extensions
Not provided in the Public version of the Security Target.
9.5. PP Claim Rationale
This ST includes all the security objectives and requirements claimed by PP [7], PP [6], and, all of
the operations applied to the SFRs are in accordance with the requirements of these PPs.
9.5.1. PP compliancy
The TOE type is compliant with the claimed PPs: the TOE is a Secure Signature-Creation Device
representing the SCD storage, SCD/SVD generation, and signature-creation component.
The TOE is compliant with the representation provided in both PPS:
- SSCD of Type 1 represents the SCD/SVD generation component,
- SSCD of Type 2 represents the SCD storage and signature-creation component.
- SCD generated on an SSCD Type 1 shall be exported to an SSCD Type 2 over a trusted
channel.
- SSCD Type 3 is analogous to a combination of Type 1 and Type 2, but no transfer of the
SCD between two devices is provided.
- SSCD Type 2 and Type 3 are personalized components; it means that they can be used for
signature creation by one specific user – the signatory - only.
Actually, Type 2 and Type 3 are not necessarily to be considered mutually exclusive, as both PPs
state.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 36 of 38
10. Terminology
Term Definition
CC Common Criteria
CGA
Certification generation application (CGA) means a collection of application
elements which requests the SVD from the SSCD for generation of the
qualified certificate. The CGA stipulates the generation of a correspondent
SCD / SVD pair by the SSCD, if the requested SVD has not been generated
by the SSCD yet. The CGA verifies the authenticity of the SVD by means of
the SSCD proof of correspondence between SCD and SVD and checking the
sender and integrity of the received SVD.
CSP
Certification-service-provider (CSP) means an entity or a legal or natural
person who issues certificates or provides other services related to electronic
signatures (defined in the Directive, article 2.11).
DI Dual Interface
Directive
The Directive; DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT
AND OF THE COUNCIL of 13 December 1999 on a Community framework
for electronic signatures
DTBS
Data to be signed (DTBS) means the complete electronic data to be signed
(including both user message and signature attributes)
DTBS Representation
Data to be signed representation (DTBS-representation) means the
representation data sent by the SCA to the TOE for signing and is
- a hash-value of the DTBS or
- an intermediate hash-value of a first part of the DTBS and a
remaining part of the DTBS or
- the DTBS
The SCA indicates to the TOE the case of DTBS-representation, unless
implicitly indicated. The hash-value in case (a) or the intermediate hash-value
in case (b) is calculated by the SCA. The final hash-value in case (b) or the
hash-value in case (c) is calculated by the TOE.
OS Operating System
Qualified Certificate
Means a certificate which meets the requirements laid down in Annex I of the
Directive and is provided by a CSP who fulfils the requirements laid down in
Annex II of the Directive. (defined in the Directive, article 2.10)
RAD
Reference authentication data (RAD) means data persistently stored by the
TOE for verification of the authentication attempt as authorised user.
SCA
Signature-creation application (SCA) means the application used to create an
electronic signature, excluding the SSCD. I.e., the SCA is a collection of
application elements.
- to perform the presentation of the DTBS to the signatory prior to the
signature process according to the signatory's decision,
- to send a DTBS-representation to the TOE, if the signatory indicates by
specific non misinterpretable input or action the intend to sign,
- to attach the qualified electronic signature generated by the TOE to the
data or provides the qualified electronic signature as separate data.
SCD
Signature-creation data (SCD) means unique data, such as codes or private
cryptographic keys, which are used by the signatory to create an electronic
signature. (defined in the Directive, article 2.4)
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 37 of 38
Term Definition
SDO
Signed data object (SDO) means the electronic data to which the electronic
signature has been attached to or logically associated with as a method of
authentication.
Signatory
Signatory means a person who holds a SSCD and acts either on his own
behalf or on behalf of the natural or legal person or entity he represents.
(defined in the Directive, article 2.3)
SSCD
Secure signature-creation device (SSCD) means configured software or
hardware which is used to implement the SCD and which meets the
requirements laid down in Annex III of the Directive. (SSCD is defined in the
Directive, article 2.5 and 2.6)
SVD
Signature-verification data (SVD) means data, such as codes or public
cryptographic keys, which are used for the purpose of verifying an electronic
signature. (defined in the Directive, article 2.7)
TS Tessera Sanitaria
VAD
Verification authentication data (VAD) means authentication data provided as
input by knowledge or authentication data derived from user‘s biometric
characteristics.
ASEPCOS-TS/CNS STMicroelectronics Security Target REF: ST-SSCD_STM-01
V1.1 Copyright Athena Smartcard Inc. – 2010 Page 38 of 38
11. References
[1] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13
December 1999 on a Community framework for electronic signatures
[2] Common Criteria for Information Technology Security Evaluation — CCMB-2009-07-001 —
Part 1: Introduction and general model, July 2009.
[3] Common Criteria for Information Technology Security Evaluation — CCMB-2009-07-002 —
Part 2: Security functional requirements, July 2009.
[4] Common Criteria for Information Technology Security Evaluation — CCMB-2009-07-003 —
Part 3: Security assurance requirements, July 2009.
[5] Algorithms and parameters for algorithms, list of algorithms and parameters eligible for
electronic signatures, procedures as defined in the directive 1999/93/EC, article 9 on the
‗Electronic Signature Committee‘ in the Directive.
[6] PP0005b – Protection Profile — Secure Signature-Creation Device Type 2 – EAL 4+ –
Version: 1.04, 25 July 2001
[7] PP0006b – Protection Profile — Secure Signature-Creation Device Type 3 – EAL 4+ –
Version: 1.05, 25 July 2001
[8] STMicroelectronics 23YR80 Technical Datasheet – Revision 2
[9] Protection Profile PP9806 Smartcard – Integrated Circuit, version: 2.0 EAL4+
[10] Certification Report ANSSI-2010/02 – STMicroelectronics – Feb 10, 2010
[11] Sx23YRxxB Security Target - Public Version – Ref: SMD_Sx23YRxx_ST_09_002 –
STMicroelectronics – version 02.01
[12] PKCS#1: RSA Cryptography Standard, Version 1.5
[13] PKCS#1: RSA Cryptography Standard, Version 2.1
[14] ST23 NesLib 3.0 cryptographic library user manual – STMicroelectronics – Version 2
[15] STMicroelectronics 23YR48 Technical Datasheet – Revision 1