Multiapp ID CIE/CNS Security Target UPDATES

Multiapp ID CIE/CNS Security Target UPDATES
SECURITY TARGET
TOE CIE/CNS
Multiapp ID CIE/CNS
Security Target
UPDATES
Date
April 7,2011
ST
Author
Christine Crippa-Martinez
Modification
Creation from evaluated ST (V1.8)
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 1 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
CONTENT
1 ST INTRODUCTION ................................................................................................................................................. 5 1.1 ST REFERENCE........................................................................................................................................................ 5 1.2 TOE REFERENCE .................................................................................................................................................... 5 1.3 TOE OVERVIEW ...................................................................................................................................................... 6 1.3.1 TOE type ........................................................................................................................................................ 7 1.3.2 TOE boundaries ............................................................................................................................................. 7 1.3.3 TOE configurations ....................................................................................................................................... 8 1.4 REFERENCES, GLOSSARY AND ABBREVIATIONS ..................................................................................................... 9 1.4.1 External references ........................................................................................................................................ 9 1.4.2 Glossary ....................................................................................................................................................... 10 1.4.3 Abbreviations ............................................................................................................................................... 11 2 TOE DESCRIPTION ................................................................................................................................................ 13 2.1 CIE/CNS APPLET DESCRIPTION............................................................................................................................ 13 2.2 TOE LIFE-CYCLE .................................................................................................................................................. 14 2.2.1 TOE Phases ................................................................................................................................................. 16 2.2.1.1 2.2.1.2 2.2.2 2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.3 2.4 3 THE ACTORS AND ROLES ....................................................................................................................................... 19 TOE INTENDED USAGE ......................................................................................................................................... 20 CC CONFORMANCE CLAIM .................................................................................................................................... 22 PP CLAIM, PACKAGE CLAIM.................................................................................................................................. 22 CONFORMANCE RATIONALE ................................................................................................................................. 22 PP REFERENCE ...................................................................................................................................................... 22 PP REFINEMENTS .................................................................................................................................................. 22 PP ADDITIONS ....................................................................................................................................................... 26 ASSURANCE REQUIREMENTS ADDITIONAL TO THE PP ........................................................................................... 26 DIGITAL SIGNATURE ASSETS ................................................................................................................................ 27 DIGITAL SIGNATURE SUBJECTS ............................................................................................................................. 27 DIGITAL SIGNATURE THREATS.............................................................................................................................. 27 DIGITAL SIGNATURE ASSUMPTIONS ...................................................................................................................... 28 ORGANIZATIONAL SECURITY POLICIES ................................................................................................................. 29 SECURITY OBJECTIVES ...................................................................................................................................... 30 5.1 5.2 6 Development phase .................................................................................................................................................... 17 Production environment............................................................................................................................................. 18 Personalization environment...................................................................................................................................... 19 User environment....................................................................................................................................................... 19 TOE SECURITY ENVIRONMENT ....................................................................................................................... 27 4.1 4.2 4.3 4.4 4.5 5 TOE Environment ........................................................................................................................................ 17 CONFORMANCE CLAIMS .................................................................................................................................... 22 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 TOE Actors & roles ................................................................................................................................................... 16 Smart Card product life cycle .................................................................................................................................... 16 SECURITY OBJECTIVES FOR THE TOE ................................................................................................................... 30 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ............................................................................. 31 SECURITY REQUIREMENTS ............................................................................................................................... 32 6.1 TOE SECURITY FUNCTIONAL REQUIREMENTS ....................................................................................................... 32 6.1.1 Security functional requirements list ........................................................................................................... 32 Cryptographic support .............................................................................................................................................................. 33 6.1.2 6.1.2.1 6.1.2.2 ST
FCS – Cryptographic support ..................................................................................................................... 34 FCS_CKM cryptographic key management .............................................................................................................. 34 FCS_COP Cryptographic operation .......................................................................................................................... 34 Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 2 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
6.1.3 FDP: User data protection .......................................................................................................................... 35 6.1.4 FIA: Identification and authentication ........................................................................................................ 40 6.1.5 FMT: Security management......................................................................................................................... 42 6.1.6 FPT: Protection of the TSF ......................................................................................................................... 43 6.1.7 FTP: Trusted Path / Channel....................................................................................................................... 45 6.1.3.1 6.1.3.2 6.1.3.3 6.1.3.4 6.1.3.5 6.1.3.6 6.1.3.7 6.1.3.8 6.1.4.1 6.1.4.2 6.1.4.3 6.1.4.4 6.1.5.1 6.1.5.2 6.1.5.3 6.1.5.4 6.1.5.5 6.1.6.1 6.1.6.2 6.1.6.3 6.1.6.4 6.1.6.5 6.1.7.1 6.1.7.2 FDP_ACC Access Control policy ............................................................................................................................. 35 FDP_ACF access control function............................................................................................................................. 35 FDP_ETC :Export to outside TSF control ................................................................................................................. 38 FDP_ITC Import From outside TSF control .............................................................................................................. 38 FDP_RIP Residual information protection ................................................................................................................ 39 FDP_SDI Stored data integrity .................................................................................................................................. 39 FDP_UCT Inter-TSF user data confidentiality transfer protection ............................................................................ 40 FDP_UIT Inter-TSF user data integrity transfer protection ...................................................................................... 40 FIA_AFL Authentication failure ............................................................................................................................... 40 FIA_ATD User attribute definition ........................................................................................................................... 41 FIA_UAU User authentication .................................................................................................................................. 41 FIA_UID User Identification .................................................................................................................................... 41 FMT_MOF Management of functions in TSF ........................................................................................................... 42 FMT_MSA Management of security attributes ......................................................................................................... 42 FMT_MTD Management of TSF data ....................................................................................................................... 43 FMT_SMF Specification of Management Functions................................................................................................. 43 FMT_SMR Security management roles .................................................................................................................... 43 FPT_AMT Underlying Abstract machine test ........................................................................................................... 43 FPT_EMSEC TOE Emanation .................................................................................................................................. 44 FPT_FLS Failure secure ............................................................................................................................................ 44 FPT_PHP TSF physical Protection ............................................................................................................................ 44 FPT_TST TSF self test .............................................................................................................................................. 45 FTP_ITC Inter-TSF trusted channel .......................................................................................................................... 45 FTP_TRP Trusted path .............................................................................................................................................. 46 6.2 SECURITY ASSURANCE REQUIREMENTS ................................................................................................................ 47 6.2.1 TOE security assurance requirements list ................................................................................................... 47 6.3 SECURITY REQUIREMENTS FOR THE IT ENVIRONMENT......................................................................................... 48 6.3.1 Signature key generation (SSCD Type1) ..................................................................................................... 48 6.3.1.1 6.3.1.2 6.3.1.3 6.3.1.4 6.3.1.5 6.3.1.6 6.3.2 Certification Generation application (CGA) ............................................................................................... 49 6.3.3 Signature creation application (SCA).......................................................................................................... 50 6.3.2.1 6.3.2.2 6.3.2.3 6.3.2.4 6.3.3.1 6.3.3.2 6.3.3.3 6.3.3.4 6.4 7 FCS_CKM.1: Cryptographic key generation............................................................................................................. 48 FCS_CKM.4: Cryptographic key destruction ............................................................................................................ 48 FCS_COP.1: Cryptographic operation ...................................................................................................................... 48 FDP_ACC.1: Subset access control ........................................................................................................................... 49 FDP_UCT.1: Basic data exchange confidentiality .................................................................................................... 49 FTP_ITC.1: Inter-TSF trusted channel ..................................................................................................................... 49 FCS_CKM.2 .............................................................................................................................................................. 49 FCS_CKM.3 .............................................................................................................................................................. 49 FDP_UIT.1 ................................................................................................................................................................ 49 FTP_ITC.1 ................................................................................................................................................................. 50 FCS_COP.1 ............................................................................................................................................................... 50 FDP_UIT.1 ................................................................................................................................................................ 50 FTP_ITC.1 ................................................................................................................................................................. 50 FTP_TRP.1 ................................................................................................................................................................ 50 SECURITY REQUIREMENTS FOR THE NON-IT ENVIRONMENT ................................................................................ 51 TOE SUMMARY SPECIFICATION ...................................................................................................................... 52 7.1 7.2 7.3 7.4 7.5 ST
SF_SIG_AUTHENTICATION: AUTHENTICATION MANAGEMENT ..................................................................... 52 SF_SIG_CRYPTO: CRYPTOGRAPHY MANAGEMENT ........................................................................................... 52 SF_SIG_INTEGRITY: INTEGRITY MONITORING ................................................................................................. 53 SF_SIG_MANAGEMENT: MANAGEMENT OF OPERATIONS AND ACCESS CONTROL .......................................... 53 SF_SIG_SECURE_MESSAGING ...................................................................................................................... 53 Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 3 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FIGURES
Figure 1 - Multiapp ID CIE/CNS Card....................................................................................................................................................... 8 Figure 2 - Type 2 and Type 3 SSCD operations ....................................................................................................................................... 14 Figure 3 – Product Life Cycle .................................................................................................................................................................. 15 Figure 4 - TOE Usage .............................................................................................................................................................................. 21 TABLES
Table 1. TOE component ........................................................................................................................................................................... 5 Table 2. Product component ...................................................................................................................................................................... 7 Table 3 – Smart Card Product Life Cycle ................................................................................................................................................ 17 Table 4. PP functional requirements that have been refined ................................................................................................................... 23 Table 5. IAS Classic security functional requirements list ...................................................................................................................... 33 Table 6 . TOE security assurance requirements list................................................................................................................................. 48 Table 7. TOE Security functions List ....................................................................................................................................................... 52 ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 4 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
1 ST INTRODUCTION
1.1
ST REFERENCE
ST Title:
CIE/CNS - Security Target
ST Reference:
D1077254
Origin:
GEMALTO
ITSEF
Serma
Certification scheme:
French (ANSSI)
This ST has been built with:
Common Criteria for Information Technology Security Evaluation Version 2.3 which comprises [CCPART1],
[CCPART2], and [CCPART3]
Table 1 gives an overview of the components of the TOE.
Component
Version number
Supplier
Hardmask in ROM
1.0 (MSA081)
Gemalto
Softmask in EEPROM
V05
Gemalto
Micro-controller S3CC91C
0
Samsung
AIS20-certified Deterministic Random
Number Generator (DRNG)
2.0
Samsung
TORNADO RSA library
3.5S
Samsung
Table 1. TOE component
1.2
TOE REFERENCE
TOE Title:
CIE/CNS
Product name:
Multiapp ID CIE/CNS
Commercial name:
Multiapp ID CIE/CNS
Product reference:
T1003893
The main objectives of this ST are:
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 5 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
1.3
•
To introduce TOE and the application (TOE overview),
•
To define the scope of the TOE and its security features (TOE description),
•
To describe the security environment of the TOE, including the assets to be protected and the
threats to be countered by the TOE and its environment during the product development,
production and usage (TOE security environment),
•
To describe the security objectives of the TOE and its environment supporting in terms of
integrity and confidentiality of application data and programs and of protection of the TOE
(Security objectives),
•
To specify the security requirements which include the TOE security functional requirements,
the TOE assurance requirements (Security objectives) and TOE security functions (TOE
summary specification).
TOE OVERVIEW
The Target of Evaluation (TOE) is the CIE/CNS application and the functionalities/services provided by the
Multiapp software to the CIE/CNS application with the Samsung device S3CC91C identified in the BSI
certificate BSI-DSZ-CC-0451-2007 (Reassessment 29/01/2010)
Multiapp implements [JC2.2.1] and [GP2.1.1], and CIE/CNS and ROMed application defined in Table 2.
All application codes are masked in ROM.
The product provides an electronic signature services:
•
Signature creation
•
Signature verification
•
Key importation
•
Key generation (on board)
The Gemalto CIE/CNS application is compliant with E-sign specifications (PK and SK authentication).
It covers the identity, digital signature and data storage services. The Digital signature key size is 1024 bits or
1536 bits.
The Target Of Evaluation defined in this Security Target is the Secure Signature Creation Device (SSCD)
functionalities provided by the CIE/CNS application, supported by the Java Card platform. The other
applications are not in the TOE Scope of Control and therefore not part of the evaluation.
The TOE is a Secure Signature Creation Device (SSCD) that provides both SCD/SVD generation and
Signature creation as described in the Protection Profile [PP SSCD2] and Protection Profile [PP SSCD3].
TOE Components
Version
Constructor
Micro Controller
S3CC91C rev 0
SAMSUNG
Embedded software (platform)
Multiapp version 1.1
GEMALTO
Digital signature application (Applet)
CIE/CNS version 1.0
GEMALTO
Other non TOE Components
Version
Constructor
Instanciable ROMed applet
MPCOS v 3.8
Gemalto
OATH v2.10
Gemalto
PayPass MCHIP Select v2.7
Gemalto
Biomatch J API v3.0.1 &,
Precise Biometrics
Cryptomanager v2.0,
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 6 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Not instanciable ROMed applets
(entry point deactivated)
IAS classic version 3.0,
GEMALTO
eID2048 V2.10,
GEMALTO
Almerys,
GEMALTO
VSDC v2.7.1
GEMALTO
Dual PSE
GEMALTO
Table 2. Product component
1.3.1 TOE type
The product is a smartcard including a plastic card and a module performing the interface between reader and
the embedded chip. Other smart card product elements (such as holograms, security printing…) are outside
the scope of this Security Target. The Target of Evaluation (TOE) is the Smart Card Integrated Circuit with
Embedded Software in operation and in accordance to its functional specifications.
1.3.2 TOE boundaries
The TOE is composed of the IC, the software platform and a digital signature application:
•
•
•
S3CC91C IC including its crypto libraries, which has been certified separately according to [IC-ST]
claiming [PP/BSI-0002]
Multiapp platform (see detail in [ST_ADRIATIC_PLTF])
CIE/CNS application
The TSFs are composed of:
1. The digital-signature related functions of the CIE/CNS application: Signatory Authentication, Signature
Creation, SCD/SVD Generation, SCD Import & storage, SVD Export, RAD Import & storage.
2. Part of Multiapp platform that installs and supports the CIE/CNS application.
3. The S3CC91C IC including its crypto libraries to supports the Multiapp platform.
Figure 1 represents the product. The TOE is bordered with bold and un-continuous line. The architecture of
Multiapp inside the TOE is presented in [ST_ADRIATIC_PLTF].
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 7 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Dual PSE
VSDC
Pay Pass
Almerys
PIV
eID2048 2.1
CryptoManager
OATH
Biomatch J API
MPCOS v3.8
CIE/CNS
IAS Classic
Multiapp
Javacard platform JC 2.2.1 GP 2.1.1
Integrated circuit S3CC91C + Crypto libraries
Figure 1 - Multiapp ID CIE/CNS Card
Beside the TOE, the product also contains the following Java Card applications:
•
Applets ROMed:
•
IAS classic provides the digital signature services (but is not included in the TOE).
•
MPCOS v3.8 provides secure data storage and e-purse services.
•
OATH provides One-Time-Password (OTP) authentication service following the OATH
standard.
•
Biomatch C API & Cryptomanager provide the biometric Match-On-Card service (by Precise
Biometrics).
•
EID2048 provides public-key based cryptographic services and file management.
•
PIV provides secure data storage and key management services.
•
Almersys provides secure data storage and file management services dedicated to a French
mutual group.
•
Pay Pass MCHIP Select, VSDC, Dual PSE provide the EMV payment service.
1.3.3 TOE configurations
The TOE defined in this Security Target is the electronic signature functionalities provided by the CIE
application, and supported by the MultiApp platform. The other applications are not in the TOE scope and
therefore not part of the evaluation. The final product can be configured as described in table 2.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 8 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
1.4
REFERENCES, GLOSSARY AND ABBREVIATIONS
1.4.1 External references
Reference
Title - Reference
[CCPART1]
Common Criteria for Information Technology Security
Evaluation Part 1: Introduction and general model CCIMB-2005-08-001, version 2.3,
August 2005 (conform to ISO 15408).
[CCPART2]
Common Criteria for Information Technology Security
Evaluation Part 2: Security Functional Requirements CCIMB-2005-08-002, version 2.3,
August 2005 (conform to ISO 15408).
[CCPART3]
Common Criteria for Information Technology security
Evaluation Part 3: Security Assurance Requirements CCIMB-2005-08-003, version 2.3,
August 2005 (conform to ISO 5408).
Common Methodology for Information Technology Security
[CEM]
Evaluation CCIMB-2005-08-004, version 2.3, August 2005.
[PP SSCD1]
Protection Profile Creation Device Type 1 Version 1.05
BSI-PP-0004-2002T- 03-04-2002
[PP SSCD2]
Protection Profile Creation Device Type 2 Version 1.04
BSI-PP-0005-2002T-03-04-2002
[PP SSCD3]
Protection Profile Creation Device Type 3 Version 1.05
BSI-PP-0006-2002T-03-04-2002
[PP/BSI-0002]
Smartcard IC Platform Protection Profile - BSI-PP-0002; Version 1.0, July 2001
[DIRECTIVE]
DIRECTIVE 1999/93/EC of the European Parliament and of the Council of 13 December
1999 on a Community Framework for electronic signatures”
DIRECTIVE 1999/93/EC
[E-Sign 1]
Application Interface for Smart Cards used as Secure Signature Creation Device
CEN/ISSS WS/E-Sign Draft CWA Group K part 1 – Basic requirements. Version 1
Release 9 (17th September 2003)
[E-Sign 2]
Application Interface for Smart Cards used as Secure Signature Creation Device
CEN/ISSS WS/E-Sign Draft CWA Group K part 2 – Additional services. Version 0
Release:19 (12th December 2003)
[IC-ST]
Security Target of S3CC91C (Samsung) 16-bit RISC Microcontroller for Smart Cards.
Version 1.0, August 2007.
[CC-COMP]
Composite product evaluation for Smart Card and similar devices – ISCI-WG1
[JC2.2.1]
Java Card 2.2.1 Virtual Machine - 2.2.1 - Oct 2003
[JCRE221]
Java CardTM Runtime Environment Specification version 2.2.1, Sun Microsystems, Inc,
2003.
[JCAPI221]
Java CardTM APIs specification version 2.2.1, Sun Microsystems, Inc, June 23, 2003.
[GP2.1.1]
Global Platform - Card specification v2.1.1 - 2.1.1 - March 2003
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 9 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
1.4.2 Glossary
CEN workshop agreement (CWA) is a consensus-based specification, drawn up in an open workshop
environment of the European Committee for Standardization (CEN). This Protection Profile (PP) represents
Annex A to the CWA that has been developed by the European Electronic Signature Standardization Initiative
(EESSI) CEN/ISSS electronic signature (E-SIGN) workshop, Area F on secure signature-creation devices
(SSCD).
Certificate means an electronic attestation which links the SVD to a person and confirms the identity of that
person. (defined in the Directive [1], article 2.9)
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
(a)
the SSCD proof of correspondence between SCD and SVD and
(b)
checking the sender and integrity of the received SVD.
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 [1], article 2.11)
Data to be signed (DTBS) means the complete electronic data to be signed (including both user message and
signature attributes).
Data to be signed representation (DTBS-representation) means the 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.
Qualified certificate means a certificate which meets the requirements laid down in Annex I of the Directive [1]
and is provided by a CSP who fulfils the requirements laid down in Annex II of the Directive [1]. (defined in the
Directive [1], article 2.10)
Qualified electronic signature means an advanced signature which is based on a qualified certificate and which
is created by a SSCD according to the Directive [1], article 5, and paragraph 1.
Reference authentication data (RAD) means data persistently stored by the TOE for verification of the
authentication attempt as authorized user.
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 [1]. (SSCD is defined in the
Directive [1], article 2.5 and 2.6).
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 [1], article 2.3)
Signature attributes means additional information that is signed together with the user message.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 10 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
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
1. to perform the presentation of the DTBS to the signatory prior to the signature process according to
the signatory's decision,
2. to send a DTBS-representation to the TOE, if the signatory indicates by specific nonmisinterpretable input or action the intend to sign,
3. to attach the qualified electronic signature generated by the TOE to the data or provides the qualified
electronic signature as separate data.
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 [1], article 2.4)
Signature-creation system (SCS) means the overall system that creates an electronic signature. The signaturecreation system consists of the SCA and the SSCD.
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 [1], article 2.7)
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.
Sub-Referential. Consistent set of software components (Example: test scripts, specification documents,). A
Sub-referential belongs to a Referential.
SSCD provision service means a service that prepares and provides a SSCD to subscribers.
Tip Revision. The latest revision of a line of development (the trunk or a branch)
User means any entity (human user or external IT entity) outside the TOE that interacts with the TOE.
Verification authentication data (VAD) means authentication data provided as input by knowledge or
authentication data derived from user’s biometric characteristics.
1.4.3 Abbreviations
Abreviations
AVA
Vulnerability Assessment
CC
Common Criteria
CSP
certificate-service-provider
DTBS
Data To Be Signed
IC
Integrated Circuit
OS
Operating System
RAD
Reference Authentication Data
SAR
Security Assurance Requirements
SCD
Signature Creation Data
SF
Security Function
SFR
Security functional requirements
SSCD
Secure Signature Creation Device
ST
Security Target
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 11 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
SVD
Signature Verification Data
TOE
Target Of Evaluation
TSF
TOE Security Functionality
VAD
Verification Authentication Data
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 12 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
2 TOE DESCRIPTION
The description of the Multiapp platform is described in [ST_ADRIATIC_PLTF].
2.1
CIE/CNS APPLET DESCRIPTION
CIE/CNS is a Java Card application that provides a Digital Signature Creation Device [SSCD] as defined in
the DIRECTIVE 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a
Community Framework for electronic signatures.
Three Protection Profiles have been defined:
•
•
•
The SSCD PP Type 1, which is a SCD/SVD generation component without signature creation and
verification. The SCD generated on a SSCD Type 1 shall be exported to a SSCD Type 2 over a trusted
channel [PP SSCD1].
The SSCD PP for a TOE Type 2, which is a Signature creation and verification component [PP SSCD2].
This device imports the SCD from a SSCD Type 1
The SSCD PP for a TOE Type 3, which is combination of the TOE Type 1 and Type 2 – i.e. Generation
and Signature creation/verification component [PP SSCD3].
Terminology
In this document the terminology of [PP SSCD2] and [PP SSCD3] is used.
The SSCD Application uses public key encryption. The Signature Creation Data (SCD) is the private key and
the Signature Verification Data (SVD) is the public key.
The Signatory's Reference Authentication Data (RAD) is the PIN stored in the card and the Signatory's
Verification Authentication Data (VAD) is the PIN provided by the user.
SSCD Application provides the following functions necessary for devices involved in digital electronic
signatures:
1. Generate the (SCD) and the correspondent (SVD), or Load the SCD,
2. Create qualified electronic signatures:
(a) After allowing for the Data To Be Signed (DTBS) to be displayed correctly by an appropriate
environment,
(b) Using appropriate hash functions agreed according to [CWA-ALGO] suitable for qualified electronic
signatures,
(c) After appropriate authentication of the signatory by the TOE itself,
(d) Using appropriate cryptographic signature function that employs appropriate cryptographic
parameters agreed according to [CWA-ALGO].
The TOE implements all IT security functionalities, which are necessary to ensure the secrecy of the SCD. To
prevent the unauthorized usage of the SSCD the TOE provides user authentication and access control. The
TOE implements IT measures to support a trusted path to a trusted human interface device. Therefore, the
TOE holds Signatory's Reference Authentication Data (RAD) that is used to verify the verification data
provided by the user as Signatory's Verification Authentication Data (VAD).
The TOE is initialized by importing an SCD or by generating a pair of SCD and SVD. The SCD is protected so
as to be solely used in the signature-creation process by the legitimate signatory during the validity of this
SCD/SVD pair.
The TOE stores the SCD and may export the SVD. The SVD corresponding to the signatory’s SCD will be
included in the certificate of the signatory by the certificate-service-provider (CSP).
When in usage phase, the TOE allows the creation of a new SCD/SVD pair. The previous SCD shall be
destroyed before the creation of the new SCD/SVD pair.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 13 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
The signatory uses a signature-creation system to create electronic signatures. The signature-creation device
consists of the TOE.
The SCA presents the DTBS to the signatory and prepares the DTBS-representation that the signatory wishes
to sign for performing the cryptographic function of the signature.
The TOE returns the digital electronic signature.
The TOE implements the SSCD of type 2 and type 3, and all functions concerning the SSCD to create
electronic signatures in a secure way.
The Figure below shows the type 3 and type 2 TOE operations as defined in [PP SSCD2] & [PP SSCD3].
.
SSCD Type 2 & 3
Personalization
SCA
DTBS representation
SDO
Trusted
channel
Other SSCD Type 1
Trusted
Channel
Trusted
Path
HI
Authentication data
User
Authentication
Signature Creation
SCD Import
SVD Export
CGA
Init/SVD into
certificate
Trusted
Channel
SCD/SVD Generation
Figure 2 - Type 2 and Type 3 SSCD operations
2.2
TOE LIFE-CYCLE
The product life cycle is described in Figure 3 – Product Life Cycle. Some remarks are added to explain this
figure regarding Table 3 – Smart Card Product Life Cycle.
•
The TOE is the product at the end of the phase 5 “Smart card product finishing process”.
•
Platform design and application design correspond to the phase 1 “Smart card software
development”.
Hardware design corresponds to the phase 2 “IC development”.
Hardware fabrication corresponds to the phase 3” IC manufacturing and testing”
IC packaging and testing corresponds to the phase 4.
Application installation is done in the phase 5.
Loading of softmask is done in the phase 5.
Loading of application data, SCD/SVD import (type 2), and SVD export (for certificate) are done
in the phase 6 “Smart card personalization”.
SCD/SVD generation (type 3) and signature creation correspond to the phase 7“Smart card endusage”.
SSCD destruction corresponds to the end of the phase 7.
•
•
•
•
•
•
•
•
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 14 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Phase 1
TOE Dev. Phase
Dev. Environment
Platform
design
Phase 2
Application
design
Softmask design
HW fabrication,
HW design
HW dedicated software
Phase 3
Prod. Environment
IC manufacturing
and testing
Phase 4
IC packaging and testing
Module assembling & packaging
Phase 5
Perso. Env
User. Env
TOE Oper. Phase
Phase 6
Phase 7
Smart cards pre-personalization
Softmask
loading
TOE delivery
Smart card personalization
SCD/SVD import
SVD export
SCD/SVD generation
Product end-usage
Signature Creation
SSCD destruction
Figure 3 – Product Life Cycle
The global security requirements of the TOE mandate to consider, during the development phase, the threats
to security occurring in the other phases. Therefore, this ST addresses the functions used in the phases 6 and
7 but developed during the phases 1 to 5. The limits of the evaluation process correspond to phases 1 to 5
including the TOE under development delivery from the party responsible of each phase to the parties
responsible of the following phases.
These different phases may be performed at different sites. This implies that procedures on the delivery
process of the TOE must exist and be applied for every delivery within a phase or between phases. This
includes any kind of delivery performed from phase 1 to 5 to subsequent phases, including:
• Intermediate delivery of the TOE or the TOE under construction within a phase,
• Delivery of the TOE or the TOE under construction from one phase to the next.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 15 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
These procedures must be compliant with the security assurance requirements developed in TOE “Security
Assurance Requirements” section 6.2. Table 3 gives a description of the product life cycle and explains where
the authorities are involved.
2.2.1 TOE Phases
2.2.1.1 TOE Actors & roles
For the digital signature application, two roles have been identified, the Administrator and the Signatory.
1. The Administrator acts during the personalization phase (phase 6). He creates the Signatory’s PIN and
optionally imports the first SCD into the TOE.
The Signatory that owns the TOE is the End-User in the usage phase (phase 7). He can sign, destroy the
SCD and generate a new SCD/SVD pair.
At the first usage of the TOE, the Signatory must change his PIN code before he is allowed to sign.
A new PIN is also required each time a new SCD/SVD pair is generated.
2.2.1.2 Smart Card product life cycle
The Smart card product life cycle, as defined in [PP/BSI-0002], is split up into 7 phases where the following
authorities are involved:
Phase 1 Smart card software
development
The smart card embedded software developer is in
charge of the smart card embedded software
development and the specification of IC prepersonalization requirements.
Phase 2 IC Development
The IC designer designs the integrated circuit,
develops IC firmware if applicable, provides
information, software or tools to the smart card software
developer, and receives the software from the
developer, through trusted delivery and verification
procedures. From the IC design, IC firmware and
smart card embedded software, he constructs the smart
card IC database, necessary for the IC photo mask
fabrication.
Phase 3 IC manufacturing and
testing
The IC manufacturer is responsible for producing the
IC through three main steps: IC manufacturing, testing,
and IC pre-personalization.
Phase 4 IC packaging and
testing
The IC packaging manufacturer is responsible for the
IC packaging and testing.
Phase 5 Smart card product
finishing process
The smart card product manufacturer is responsible
for the smart card product finishing process and testing,
and the smart card pre-personalization1
Phase 6 Smart card
personalization
The Personalizer is responsible for the smart card Administrator
personalization and final tests.2 3
1
In maintenance case, pre-issuance applet loading in EEPROM is done by commands “install for Install” and
“load”
2
In maintenance case, if not done in phase 5, pre-issuance applet loading in EEPROM is done by commands
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 16 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Phase 7 Smart card end-usage The smart card issuer is responsible for the smart Signatory
card product delivery to the smart card end-user, and
Administrator
for the end of life process.
Table 3 – Smart Card Product Life Cycle
2.2.2 TOE Environment
The TOE environment is defined as follow:
•
For TOE development phase:
o Development environment corresponding to the software developer environment (phase1),
and the hardware fabrication environment (phase 2);
o Production environment corresponding to the generation of the masked Integration Circuit
(phase 3), the manufacturing of the card (phase 4), the initialization of the JavaCard (phase 5)
and the installation of the applet (phase 5), the test operations, and initialization of the
JavaCard.
•
For TOE operational phase
o Personalization environment corresponding to personalization and testing the loading of
TOE application data and the import of the SCD (phase 6), during which the card generates
the signatures on behalf of the end user.
o User environment corresponding to card usage (phase 7). End of life environment, during
which the TOE is made inapt for the signature creation (end of the phase 7).
Phase 1
Software development
CIE/CNS, softmask)
(Multiapp,
Pre-personalization design
Phase 2
IC design
Gemalto Meudon
& Gemalto la Ciotat
Samsung Giheung
Hardware fabrication
Phase 3
IC manufacturing & testing
Phase 4
IC packaging & testing
Phase 5
Samsung Giheung
Module assembling
Gemalto
Module packaging
Gemalto
Pre-personalization
Gemalto
2.2.2.1 Development phase
2.2.2.1.1 Software development ((Phase 1)
This environment is limited to GEMALTO Meudon & La ciotat site.
install for “Install” and “load”
3
In maintenance case, applet install could be done by Gemalto or by Card issuer by command “Install for
Install”
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 17 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
In order to ensure security, the environment in which the development takes place must be made secure with
access control tracing entries. Furthermore, it is important that all authorized personnel feels involved and fully
understands the importance and the rigid implementation of the defined security procedures.
The development begins with the TOE specification. All parties in contact with sensitive information are
required to abide by Non-disclosure Agreement.
Design and development of the ES then follows. The engineers use a secure computer system (preventing
unauthorized access) to make the conception, design, implementation and test performances.
To ensure security, access to development tools and products elements (PC, emulator, card reader,
documentation, source code, etc…) is protected. The protection is based on measures for prevention and
detection of unauthorized access. Two levels of protection are applied:
• Access control to GEMALTO Meudon officz, GEMALTO la ciotat office and sensitive areas.
• Access to development data through the use of a secure computer system to design, implement and test
software.
Storage of sensitive documents, databases on tapes, diskettes, and printed circuit layout information are in
appropriately locked cupboards/safe. Of paramount importance also is the disposal of unwanted data
(complete electronic erasures) and documents (e.g. shredding).
Testing, programming and deliveries of the TOE then take place. When these are done offsite, they must be
transported and worked on in a secure environment with accountability and traceability of all (good and bad)
products.
During the electronic transfer of sensitive data, procedures must be established to ensure that the data arrive,
only at the destination and is not accessible at intermediate stages (e.g. stored on a buffer server where
system administrators make backup copies). It must also be ensured that transfer is done without modification
or alteration.
2.2.2.1.2 Hardware fabrication (Phase 2)
This environment is limited to Samsung sites.
The IC development environment is described in [IC_ST]. A transport key protects the IC delivery from
Samsung to Gemalto. We are only interested below in the software aspect of the TOE.
2.2.2.2 Production environment
2.2.2.2.1 IC manufacturing (Phases 3)
This environment is limited to Samsung sites.
The IC manufacturing environment is described in [IC ST].
2.2.2.2.2 IC Packaging (phase 4)
This environment is limited to GEMALTO site, for module assembling, and for module packaging (embedding).
Access to IC packaging and testing is physically protected. The protection is based on measures for
prevention and detection of unauthorized access.
During fabrication, phases 3, and 4, all the persons involved in storage and transportation operations should
fully understand the importance of the defined security procedures.
Moreover, the environment in which these operations take place must be secured.
2.2.2.2.3 Pre-personalization: Card Initialization and applet installation (phase 5)
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 18 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
This environment is limited to GEMALTO site. If the pre-personalization is done on module main site is
assembling site used.
Initialization requires a secure environment, which guarantees the integrity and confidentiality of operations.
Access to production is physically protected. The protection is based on measures for prevention and
detection of unauthorized access.
During smart card pre-personalization the application data structure is created. At the end of this phase, the
ROMed applets entry points are deactivated except CIE/CNS application.
2.2.2.3 Personalization environment
This environment can be GEMALTO site.
Access to personalization site is physically protected. The protection is based on measures for prevention and
detection of unauthorized access.
Additional data may be loaded and the SCD may be imported. Then the TOE is issued to the Card Holder
(Signatory).
2.2.2.4 User environment
At the end of phase 6, the Card Issuer delivers the Smart Card to the Card Holder.
Once delivered to the Card Holder (phase 7), the TOE can generate the SCD/SVD key pair. The TOE then
exports the public part of the key to the Certification Authority for certification.
The TOE is owned by the Card Holder who cannot impose strict security rules. It is the responsibility of the
TOE and of the signature protocols to ensure that the signature security requirements are met.
The signatory will generate the SCD/SVD keys pair.
The signatory will export the public key (SVD)
The signatory will have to present his PIN (VAD) before being allowed to create signature.
The end of life environment is corresponding to the physical destruction of the card.
2.3
THE ACTORS AND ROLES
The actors can be divided in:
Developers
The IC designer and Dedicated Software (DS) developer designs the chip and its DS. For this TOE, it is
SAMSUNG.
The Embedded Software developer designs the OS according to IC/DS specifications, the CIE/CNS
application and the softmask if necessary. For this TOE, it is GEMALTO.
Manufacturers
The IC manufacturer -or founder- designs the photomask, manufactures the IC with its DS and hardmask from
the Product Developer. For this TOE, the founder is SAMSUNG.
The IC die bonding manufacturer is responsible for the die bonding the ICs provided by the founder. For this
TOE, the IC die bonding manufacturer is GEMALTO.
The Smart Card product manufacturer (or Card manufacturer) is responsible to obtain a pre-personalized card
from a packaged IC. In the phase 5, the card manufacturer is also responsible for loading additional code
belonging to the Developer and Manufacturer of the Card (the softmask) if necessary. For this TOE, the Smart
Card product manufacturer is GEMALTO.
Personalizer
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 19 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
The Smart Card Personalizer personalizes the card by loading the cardholder data as well as cryptographic
keys and PINs. The Personalizer may also load card issuer applets during this phase. For this TOE, the
personalizer may be GEMALTO or the Card Issuer.
At the end of this phase, no more applets may be loaded on the card (post-issuance is not allowed). The card
is issued in OP_SECURED state.
Card Issuer, Administrator
The Card Issuer -short named “issuer”- is a National Administration (or Identity Cards Authority). It issues
cards to the citizens who are the “Card holders”. The Card Issuer has also the role of Administrator.
Therefore, the Card Issuer is responsible for selecting and managing the personalization, for managing
applets (load, install and delete), for creating the Signatory’s PIN, for optionally importing the first SCD into the
TOE, as well as for distribution and invalidation of the card.
End-user, Signatory
The Signatory is the End-user in the usage phase (phase 7) and owns the TOE. The card is personalized with
his or her identification and secrets. The Signatory can sign, destroy the SCD and generate a new SCD/SVD
pair.
The roles (administration and usage) are defined in the following tables.
Phase
Administrator
Environment
6 and 7
Card Issuer
Personalization and Usage Environment
Phase
User
Environment
7
Signatory
Usage Environment
During the delivery between phases the responsibility is transferred from the current phase administrator to
the next phase administrator.
2.4
TOE INTENDED USAGE
SCD import:
1. The SCA authenticates itself to the TOE.
2. The signatory authenticates to the TOE (see above).
3. The signatory requests the import of SCD from a SSCD Type 1 device.
4. The SCD is imported to the TOE.
5. The CGA generates the certificate for the corresponding SVD and sends it ot the TOE.
SCD/SVD Key generation in the final usage phase,
1. The SCA authenticates itself to the TOE.
2. The signatory enters his PIN code.
3. The signatory requests the generation of a SCD / SVD key pair
4. The SCD / SVD are generated in the TOE.
5. The SVD is sent to the CGA.
6. The CGA generates the certificate and sends it to the TOE.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 20 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Signature Creation in the final usage phase,
1. The SCA authenticates itself to the TOE.
2. The signatory enters his PIN code.
3. The signatory sends the DTBS to the TOE.
4. The TOE computes the Signature.
5. The TOE sends the Signature to the SCA.
Connected
Device
Certification
Authority
(CA)
Human
Interface
Smart Card
Authentication Data
Signatory
Authentication
DTBS / Signature
Signature - Creation
SCD Import
Certification
Generation
Application
(CGA)
Signature
Creation
Application
(SCA)
SVD / Certificate
SVD / Certificate
SCD / SVD
Generation
Figure 4 - TOE Usage
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 21 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
3 CONFORMANCE CLAIMS
3.1
CC CONFORMANCE CLAIM
This Security Target is built with CC V2.3
This ST is conformant with [CCPART2] extended.
This ST is conformant with [CCPART3] augmented.
The TOE includes an Integrated Circuit certified with CC V2.3 EAL4+ ADV_IMP.2, ALC_DVS.2, AVA_MSU.3,
AVA_VLA.4.This IC has its own ST [IC-ST]. The assets, threats, objectives, SFR and security functions
specific to the IC are describe in [IC-ST].and are not repeatable in the current ST.
It is a composite evaluation.
3.2
PP CLAIM, PACKAGE CLAIM
This ST is compliant to [PP SSCD2] and [PP SSCD3].
The [IC-ST] refines the assets, threats, objectives and SFR of [PP/BSI-0002].
This TOE is CC v2.3 EAL4 augmented (+) with:
• ADV_IMP.2: Complete mapping of the implementation representation of the TSF,
• ALC_DVS.2: Sufficiency of security measures.
• AVA_MSU.3:Analysis and testing for insecure states
• AVA_VLA.4: Highly resistant
The strength level for the TOE security functional requirements is “SOF high” (Strength Of Functions high).
3.3
CONFORMANCE RATIONALE
This Security Target is built with CC V2.3 as referenced in External references.
This ST is conformant with [CCPART2] extended due to additional components as stated in Protection Profile
[PP SSCD2], [PP SSCD3] and [PP/BSI-0002].
This ST is conformant with [CCPART3] augmented due to augmentation given in [PP SSCD2], [PP SSCD3]
and [PP/BSI-0002].
The [IC-ST] refines the assets, threats, objectives and SFR of [PP/BSI-0002] see BSI certificate and
certification report.
The current ST refines the assets, threats, objectives and SFR of [PP SSCD2], [PP SSCD3] and [BSI PP].
3.4
PP REFERENCE
The PP [PP SSCD2], [PP SSCD3] and [PP/BSI-0002] are claimed.
3.5
PP REFINEMENTS
Refinements of [PP/BSI-0002] are described in [IC-ST] and are not repeated here.
The table below shows the functional requirements refined in PP and in ST.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 22 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Functional
requirement
Refined in
Refined in
Refined in
[PP SSCD2]
[PP SSCD3]
ST
_
X
FCS_CKM.1
FCS_CKM.4
_
_
X
FCS_COP.1
X
X
X
FDP_ACC.1
X
X
(X)
FDP_ACF.1
X
X
X
FDP_ETC.1
X
X
(X)
FDP_ITC.1
X
X
(X)
FDP_RIP.1
X
X
(X)
FDP_SDI.2
X
X
(X)
FDP_UCT.1
X
FDP_UIT.1
X
X
(X)
FIA_AFL.1
X
X
X
FIA_ATD.1
X
X
(X)
FIA_UAU.1
X
X
X
FIA_UID.1
X
X
X
FMT_MOF.1
X
X
(X)
FMT_MSA.1
X
X
(X)
FMT_MSA.2
NA
NA
NA
FMT_MSA.3
X
X
(X)
FMT_MTD.1
X
X
(X)
(X)
FMT_SMF.1
X
FMT_SMR.1
X
X
(X)
FPT_AMT.1
_
_
X
FPT_EMSEC.1
_
_
X
FPT_FLS.1
_
_
X
FPT_PHP.1
NA
NA
NA
FPT_PHP.3
_
_
X
FPT_TST.1
_
_
X
FTP_ITC.1
X
X
(X)
FTP_TRP.1
X
X
X
Table 4. PP functional requirements that have been refined
The functional requirements are both refined in the claimed PP and in this ST. This section demonstrates the
compatibility of the refinements done in both documents.
-: No refinement
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 23 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
(X): no additional refinement has been made in the ST.
X: Refinement
NA: the functional requirement requires no refinement.
FCS_CKM.1: Cryptographic key generation
This functional requirement has been refined from [PP SSCD3] with a specific list of approved
algorithms that gives the cryptographic key generation algorithms and key sizes used by the TOE.
FCS_CKM.4: Cryptographic key destruction
This functional requirement is refined from [PP SSCD2] and [PP SSCD3] with a description of the key
destruction method used that follows [no specific standard].
FCS_COP.1: Cryptographic operation
This functional requirement partially refined in [PP SSCD2] and [PP SSCD3] has been completed in the
ST with a specific list of cryptographic algorithms and key sizes that are used by the TOE. Furthermore,
two iterations have been added, one for Hashing and one for the MAC computation.
FDP_ACC.1: Subset access control
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FDP_ACF.1: Security based access control functions
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3]. Additional refinement is
done in the ST.
FDP_ETC.1: Export of user data without security attributes
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FDP_ITC.1: Import of user data without security attributes
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FDP_RIP.1: Subset residual information protection
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FDP_SDI.2: Stored data integrity monitoring and action
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FDP_UCT.1 Basic data exchange confidentiality
This functional requirement is already refined in [PP SSCD2] and no other refinement has been added
in the ST.
FDP_UIT.1: Data exchange integrity
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FIA_AFL.1: Basic authentication failure handling
This functional requirement is partially refined in [PP SSCD2] and [PP SSCD3]. In the ST the number of
authentication failures has been refined.
FIA_ATD.1: User attribute definition
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 24 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FIA_UAU.1: Timing of authentication
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3]. Additional refinement is
done in the ST.
FIA_UID.1: Timing of identification
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3]. Additional refinement is
done in the ST.
FMT_MOF.1: Management of security functions behavior
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FMT_MSA.1: Management of security attributes
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FMT_MSA.2: Secure security attributes
There is no refinement required for this security requirement.
FMT_MSA.3: Static attributes initialization
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FMT_MTD.1: Management of TSF data
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FMT_SMF.1: Specification of Management
This functional requirement is added to [PP SSCD2] and [PP SSCD3] in order to fulfill dependencies of
CC.
FMT_SMR.1: Security roles
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FPT_AMT.1: Abstract machine testing
This functional requirement is not refined in [PP SSCD2] and [PP SSCD3] and is entirely refined in the
ST.
FPT_EMSEC.1: TOE emanation
This functional requirement, extended from CC is not refined in [PP SSCD2] and [PP SSCD3]. It is
entirely refined in the ST.
FPT_FLS.1: Failure with preservation of secure state
This functional requirement is not refined in [PP SSCD2] and [PP SSCD3] and is entirely refined in the
ST.
FPT_PHP.1: Passive detection of physical attacks
There is no refinement required for this security requirement.
FPT_PHP.3: Resistance to physical attack
This functional requirement is not refined in [PP SSCD2] and [PP SSCD3] and is entirely refined in the
ST.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 25 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FPT_TST.1: Testing
This functional requirement is not refined in [PP SSCD2] and [PP SSCD3] and is entirely refined in the
ST.
FTP_ITC.1: Inter-TSF trusted channel
This functional requirement is already refined in [PP SSCD2] and [PP SSCD3] and no other refinement
has been added in the ST.
FTP_TRP.1: Trusted path
This functional requirement is partly refined in [PP SSCD2] and [PP SSCD3]. Additional refinement is
done in the ST.
3.6
PP ADDITIONS
The table below shows the functional requirements refined in PP and in ST.
Addition in ST
3.7
Assets
-
Threats
-
Assumptions
X
Organizational Security Policies
X
Security objectives for the TOE
-
Security objectives for the operational environment
X
Security functional requirements
X
security assurance requirements
-
Security Requirements for the IT Environment
-
ASSURANCE REQUIREMENTS ADDITIONAL TO THE PP
There is no assurance requirement, which is not in [PP SSCD2], [PP SSCD3] or [PP/BSI-0002].
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 26 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
4 TOE SECURITY ENVIRONMENT
This section describes the security aspects of the TOE environment and addresses the description of the
assets to be protected, the threats, the organizational security policies and the assumptions.
4.1
DIGITAL SIGNATURE ASSETS
The assets of the TOE are those defined in [PP SSCD2], [PP SSCD3] and [PP/BSI-0002].
This Security Target deals with the assets of [PP SSCD2] and [PP SSCD3]. The assets of [PP/BSI-0002] are
studied in [IC-ST]. ]. The assets of the platform are defined in [ST_ PLTF_ADRIATIC].
D.SCD
SCD: private key used to perform an electronic signature operation
(confidentiality of the SCD must be maintained).
D.SVD
SVD: public key linked to the SCD and used to perform electronic signature
verification (integrity of the SVD when it is exported must be maintained).
D.DTBS
DTBS and DTBS-representation: set of data or its representation which is
intended to be signed (their integrity must be maintained)
D.VAD
VAD: PIN code data entered by the End User to perform a signature operation
(confidentiality and authenticity of the VAD as needed by the authentication
method employed)
D.RAD
RAD: Reference PIN code authentication reference used to identify and
authenticate the End User (Integrity and confidentiality of RAD must be
maintained)
D.SSCD
Signature-creation function of the SSCD using the SCD: (The quality of the
function must be maintained so that it can participate to the legal validity of
electronic signatures)
Electronic signature: (enforceability of electronic signatures must be assured).
D.SIG
4.2
DIGITAL SIGNATURE SUBJECTS
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.
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
DIGITAL SIGNATURE THREATS
T.Hack_Phys
ST
Physical attacks through the TOE interfaces.
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 27 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
An attacker S.OFFCARD interacts with the TOE interfaces to exploit
vulnerabilities to gain fraudulent access to the Assets.
Storing, copying, and releasing of signature-creation D.SCD.
T.SCD_Divulg
An attacker S.OFFCARD can store, copy the SCDD.SCD outside the TOE.
An attacker S.OFFCARD can release the SCD D.SCD during generation,
storage and use for signature-creation in the TOE.
Derive the signature-creation data D.SCD.
T.SCD_Derive
An attacker S.OFFCARD derives the SCD D.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.
Forgery of electronic signature D.SIG.
T.Sig_Forgery
An attacker S.OFFCARD 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.
Repudiation of signatures D.SIG.
T.Sig_Repud
If an attacker S.OFFCARD can successfully threaten any of the assets, then
the non repudiation of the electronic signature is compromised.
The signatory is 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.
Forgery of the signature- verification data D.SVD.
T.SVD_Forgery
An attacker S.OFFCARD forges the SVD D.SVD presented by the TOE. This
result in loss of SVD integrity in the certificate of the signatory.
Forgery of the DTBS-representation D.DTBS.
T.DTBS_Forgery
An attacker S.OFFCARD modifies the DTBS-representation D.DTBS. sent by
the SCA. Thus the DTBS-representation used by the TOE for signing does not
match the DTBS the signatory intends to sign.
Misuse of the Signature-Creation function of the TOE
T.SigF_Misuse
4.4
An attacker S.OFFCARD 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.
DIGITAL SIGNATURE ASSUMPTIONS
This section defines assumptions related to the Digital Signature application as stated in PP SSCD and as
stated in [PP/BSI-0002] for composite evaluation.
Trustworthy certification-generation application
A.CGA
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 28 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
The CGA protects the authenticity of the signatory’s name and the SVD in
the qualified certificate by an advanced signature of the CSP.
Trustworthy signature-creation application
A.SCA
A.SCD_Generate (type2)
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.
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
and exported.
Secure Key Management
The IT Environment SCA and CGA shall protect the confidentiality of the
keys used for the secure communications with the TOE.
These are assumptions additional to [PP SSCD2] and [PP SSCD3].
A.Key_Mngt (additional
assumption)
4.5
ORGANIZATIONAL SECURITY POLICIES
This section defines OSPs related to the Digital Signature application as stated in PP SSCD3.
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 [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.CSP_Qcert
Qualified electronic signatures.
The signatory uses a signature-creation system to sign data with qualified
electronic signatures.
P.Qsign
The DTBS are presented to the signatory by the SCA. The qualified
electronic signature is based on a qualified certificate and is created by a
SSCD.
TOE as secure signature-creation device.
The TOE stores the SCD used for signature creation under sole control of
the signatory. The SCD used for signature generation can practically occur
only once.
P.Sigy_SSCD
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 29 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
P.IC_Usage
OSP)
(additional
P.IC_Protection
OSP)
(additional All employees follows the security requirements for the materials and
documentations given by the IC manufacturer .
The Smartcard Embedded Software developers follow the IC guidance
documents given by the IC manufacturer.
5 SECURITY OBJECTIVES
The security objectives in this Security Target are those named and described in [PP SSCD2] and [PP
SSCD3].
They cover the following aspects:
- The security objectives for the TOE,
- The security objectives for the environment.
The security objectives stated in [PP/BSI-0002] can be found in [IC ST].
5.1
SECURITY OBJECTIVES FOR THE TOE
Provide physical emanations security
OT.EMSEC_Design
Design and build the TOE in such a way as to control the production of
intelligible emanations within specified limits.
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-generation or re-import.
OT.Lifecycle_Security
Secrecy of the signature-creation data.
OT.SCD_Secrecy
The secrecy of the SCD (used for signature generation) is reasonably
assured against attacks with a high attack potential.
Correspondence between SVD and SCD.
The TOE shall ensure the correspondence between the SVD and the
SCD. 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.SCD_SVD_Corresp
TOE ensures authenticity of SVD.
OT.SVD_Auth_TOE
The TOE provides means to enable the CGA to verify the authenticity
SVD that has been exported by that TOE.
Tamper detection.
OT.Tamper_ID
The TOE shall provide system features that detect physical tampering of
a system component, and use those features to limit security breaches.
Tamper resistance.
OT.Tamper_Resistance
The TOE shall prevent or resist physical tampering with specified system
devices and components.
OT.Init (type 3)
Secure SCD SVD generation.
The TOE provides security features to ensure that the generation of the
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 30 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
SCD and the SVD is invoked by authorized users only.
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.
OT.SCD_Unique (type 3)
Secure transfer of SCD between SSCD.
OT.SCD_Transfer (Type 2)
The TOE shall ensure the confidentiality of the SCD transferred between
SSCDs.
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.DTBS_Integrity_TOE
Signature generation function for the legitimate signatory only.
The TOE provides the signature generation function for the legitimate
signatory only and protects SCD against the use of others. The TOE shall
resist attacks with high attack potential.
OT.Sigy_SigF
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.Sig_Secure
5.2
SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT
This section describes the security objectives for the environment.
The IT environment of the TOE is composed of the Certification Generation Application (CGA) and the
Signature Creation Application (SCA).
Security Objectives
Description
OE.SCD_SVD_Corresp
(type 2)
Correspondence between SVD and SCD
The SSCD Type1 shall ensure the correspondence between the SVD and the
SCD. The SSVD Type1 shall prove the correspondence between the SCD
sent to the TOE and the SVD sent to the CGA or TOE.
OE.SCD_Transfer (type 2) 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 Type1. The SCD shall be
deleted from the SSCD Type1 whenever it is exported into the TOE.
OE.SCD_Unique (type 2)
ST
Uniqueness of the signature-creation data
The SSCD Type1 shall ensure the cryptographic quality of the SCD/SVD pair
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 31 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
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.
Generation of qualified certificates
OE.CGA_Qcert
The CGA generates qualified certificates which include inter alias
the name of the signatory controlling the TOE,
the SVD matching the SCD implemented in the TOE under sole control of the
signatory,
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.
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 DTBS-representation by the TOE,
(c) attaches the signature produced by the TOE to the data or provides it
separately .
Secure management of the keys
The IT Environment SCA and CGA protect the confidentiality of the keys used
for the secure communications with the TOE.
OE.Key_Mngt
OE.IC_Usage_and_Prote
ction
The user guidance of the hardware (data-sheet…) are followed by the
software developer. Gemalto people shall follow Security measures to ensure
the confidentiality and the Integrity of the IC (material & documentations) after
delivery by the IC manufacturer.
6 SECURITY REQUIREMENTS
6.1
TOE SECURITY FUNCTIONAL REQUIREMENTS
This chapter defines the security functional requirements for the TOE using functional requirements
components as specified in [PP SSCD2] and [PP SSCD3].
[IC ST] deals with the security functional requirements of [PP/BSI-0002].
The security functions requirements provided by the platform are described in [ST_PLTF_ADRIATIC].
6.1.1 Security functional requirements list
Identification
ST
DESCRIPTION
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 32 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Cryptographic support
FCS
FCS_CKM.1 Cryptographic key generation
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FDP
User data protection
FDP_ACC.1 Subset Access control
FDP_ACF.1 Security attributes based access control
FDP_ETC.1 Export of user data without security attributes
FDP_ITC.1 Import of User Data without security attributes
FDP_RIP.1 Subset residual information protection
FDP_SDI.2 Stored data integrity monitoring and action
FDP_UCT.1 Basic data exchange confidentiality
FDP_UIT.1 Basic data exchange integrity
FIA
Identification and Authentication
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_UAU.1 Timing of authentication
FIA_UID.1 Timing of identification
FMT
Security management
FMT_MOF.1 Management of security function behavior
FMT_MSA.1 Management of security attributes
FMT_MSA.2 Secure security attributes
FMT_MSA.3 Static attribute initialization
FMT_MTD.1 Management of TSF data
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FPT
Protection of the TOE Security function
FPT_AMT.1 Abstract machine testing
FPT_EMSEC.1 TOE Emanation
FPT_FLS.1 Failure with preservation of secure state
FPT_PHP.1 Passive detection of physical attack
FPT_PHP.3 Resistance to physical attack
FPT_TST.1 TSF testing
FTP
Trusted path/Channel
FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1 TOE Trusted path
Table 5. IAS Classic security functional requirements list
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 33 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
6.1.2 FCS – Cryptographic support
6.1.2.1 FCS_CKM cryptographic key management
FCS_CKM.1 Cryptographic key generation
FCS_CKM.1/SCD
FCS_CKM.1/SCD
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [RSA key generation] and specified
cryptographic key sizes [1024 bits or 1536 bits] that meet the following: [no
standard].
Application note: Type 3 only.
Remark: Link with Initialization SFP.
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4/SCD
FCS_CKM.4.1/SCD
The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [Delete BSO command used] that meets the
following: [no standard].
Application note (refined):
The cryptographic key SCD will be destroyed on demand of the Signatory.
The destruction of the SCD is mandatory before the SCD/SVD pair is re-imported into the TOE.(Type 2)
The destruction of the SCD is mandatory before the SCD/SVD pair is re-generated by the TOE.(Type 3)
Remark: Link with SCD destruction SFP.
6.1.2.2 FCS_COP Cryptographic operation
FCS_COP.1 Cryptographic operation
FCS_COP.1/CORRESP
FCS_COP.1.1/
CORRESP
The TSF shall perform [SCD / SVD correspondence proof] in accordance with a
specified cryptographic algorithm [RSA key generation] and cryptographic key
sizes [1024 bits or 1536 bits] that meet the following: [no standard].
Application note:
When the key pair is generated on card, the key generation process ensures that the public key corresponds
to the private key.( Link with Initialization SFR)
When the SCD is input in the card, the card does not manage the SVD. The SVD or the corresponding
certificate can be input in a standard file for future use by the application. But the card does not even know the
content of the file. (Link with SVD transfer SFP)
FCS_COP.1/SIGNING
FCS_COP.1.1/
ST
The TSF shall perform [Digital signature-generation] in accordance with a
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 34 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
specified cryptographic algorithm [RSA_SHA_PKCS#1] and cryptographic key
sizes [1024 bits or 1536 bits] that meet the following: [RSA PKCS #1].
SIGNING
Remark : Link with Signature creation SFP
6.1.3 FDP: User data protection
6.1.3.1 FDP_ACC Access Control policy
FDP_ACC.1 Subset access control
FDP_ACC.1/Initialization SFP
FDP_ACC.1.1/
Initialization SFP
The TSF shall enforce the [Initialization SFP] on [Generation of SCD/SVD
pair by User].
Application note: Type 3 only.
FDP_ACC.1/SVD Transfer SFP
FDP_ACC.1.1/
Transfer SFP
SVD The TSF shall enforce the [SVD Transfer SFP] on [export of SVD by User].
Application note:
When SCD is imported into the TOE, FDP_ACC.1/SVD Transfer SFP will be required only, if the TOE is to
import the SVD from a SSCD Type1 so it will be exported to the CGA for certification. This is not the case in
this TOE. (Type 2)
When SCD is generated in the TOE, FDP_ACC.1/SVD Transfer SFP will be required to export the SVD to the
CGA for certification. (Type 3).
FDP_ACC.1/SCD Import SFP
FDP_ACC.1.1/
Import SFP
SCD The TSF shall enforce the [SCD Import SFP] on [Import of SCD by User].
Application note: Type 2 only.
FDP_ACC.1/Personalization SFP
FDP_ACC.1.1/
Personalization SFP
The TSF shall enforce the [Personalization SFP] on [Creation of RAD by
Administrator].
FDP_ACC.1/Signature-creation SFP
FDP_ACC.1.1/ Signature- The TSF shall enforce the [Signature-creation SFP] on [Sending of DTBScreation SFP
representation by SCA] and [Signing of DTBS-representation by
Signatory].
6.1.3.2 FDP_ACF access control function
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 35 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FDP_ACF.1 Security attributes based access control
The security attributes for the subjects, TOE components and related status are:
ATTRIBUTES STATUS
ATTRIBUTES
Groups of security attributes
[USER, SUBJECT OR OBJECT THE
ATTRIBUTE IS ASSOCIATED WITH]
GENERAL ATTRIBUTE GROUP
[User]
ROLE
INITIALIZATION ATTRIBUTE GROUP
[USER]
SCD/SVD MANAGEMENT
ADMINISTRATOR, SIGNATORY
[SCD]
SECURE SCD IMPORT ALLOWED
SIGNATURE-CREATION ATTRIBUTE GROUP
[SCD ]
SCD OPERATIONAL
[DTBS]
SENT BY AN AUTHORIZED SCA
AUTHORIZED
AUTHORIZED
NO/YES
/
NOT
NO/YES
NO/YES
Refinement:
The rules for specific functions that implement access control SFP defined in FDP_ACC.1 are the following:
FDP_ACF.1/Initialization SFP
FDP_ACF.1.1/
Initialization SFP
FDP_ACF.1.2/
Initialization SFP
The TSF shall enforce the [Initialization SFP] to objects based on [General
attribute group] and [Initialization attribute group].
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
“authorized” is allowed to generate SCD/SVD pair.
FDP_ACF.1.3/
Initialization SFP
FDP_ACF.1.4/
Initialization SFP
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: [none]
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
authorized” is not allowed to generate SCD/SVD pair.
Application note: Type 3 only.
FDP_ACF.1/SVD Transfer SFP
FDP_ACF.1.1/
SVD Transfer SFP
FDP_ACF.1.2/
SVD Transfer SFP
FDP_ACF.1.3/
SVD Transfer SFP
FDP_ACF.1.4/
ST
The TSF shall enforce the [SVD Transfer SFP] to objects based on [General
attribute group]
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.
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules [none].
The TSF shall explicitly deny access of subjects to objects based on the rule:
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 36 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
[none].
SVD Transfer SFP
Application note:
FDP_ACF.1/SVD Transfer SFP will be required only, if the TOE holds the SVD and the SVD is exported to the
CGA for certification.
FDP_ACF.1/SCD Import SFP
FDP_ACF.1.1/
Import SFP
FDP_ACF.1.2/
SCD Import SFP
FDP_ACF.1.3/
Import SFP
FDP_ACF.1.4/
Import SFP
SCD The TSF shall enforce the [SCD Import SFP] to objects based on [General
attribute group] and [Initialization attribute group].
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 “authorized” is
allowed to import SCD if the security attribute “secure SCD import allowed” is
set to “yes”.
SCD The TSF shall explicitly Authorize access of subjects to objects based on the
following additional rules [none].
SCD 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 to “Signatory”
and with the security attribute “SCD / SVD management” set to “not authorized”
is not allowed to import SCD if the security attribute “secure SCD import
allowed” is set to “yes”.
The user with the security attribute “role” set to “Administrator” or to “Signatory”
and with the security attribute “SCD / SVD management” set to “authorized” is
not allowed to import SCD if the security attribute “secure SCD import allowed”
is set to “no”.
Application note: Type 2 only.
FDP_ACF.1/Personalization SFP
FDP_ACF.1.1/
Personalization SFP
FDP_ACF.1.2/
Personalization SFP
FDP_ACF.1.3/
Personalization SFP
FDP_ACF.1.4/
Personalization SFP
The TSF shall enforce the [Personalization SFP] to objects based on
[General attribute group]
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.
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules [none].
The TSF shall explicitly deny access of subjects to objects based on the rule:
[none].
FDP_ACF.1/Signature Creation SFP
FDP_ACF.1.1/
Signature-creation SFP
FDP_ACF.1.2/
Signature-creation SFP
ST
The TSF shall enforce the [Signature-creation SFP] to objects based on
[General attribute group] and [Signature-creation attribute group].
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 authorized SCA with SCD by the
Signatory which security attribute “SCD operational” is set to “yes”.
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 37 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FDP_ACF.1.3/
Signature-creation SFP
FDP_ACF.1.4/
Signature-creation SFP
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: [none].
The TSF shall explicitly deny access of subjects to objects based on the rule:
User with the security attribute “role” set to “Signatory” is not allowed to create
electronic signatures for DTBS which is not sent by an authorized SCA with
SCD by the Signatory which security attribute “SCD operational” is set to “yes”.
User with the security attribute “role” set to “Signatory” is not allowed to create
electronic signatures for DTBS sent by an authorized SCA with SCD by the
Signatory which security attribute “SCD operational” is set to “no”.
6.1.3.3 FDP_ETC :Export to outside TSF control
FDP_ETC.1: Export of user data without security attributes
FDP_ETC.1/ SVD Transfer
FDP_ETC.1.1/
Transfer
FDP_ETC.1.2/
Transfer
SVD The TSF shall enforce the [SVD Transfer SFP] when exporting user data,
controlled under the SFP(s), outside of the TSC.
SVD The TSF shall export the user data without the user data’s associated security
attributes.
Application note:
FDP_ETC.1/SVD Transfer SFP will be required only, if the TOE holds the SVD and the SVD is exported to the
CGA for certification.
6.1.3.4 FDP_ITC Import From outside TSF control
FDP_ITC.1: Import of user data without security attributes
FDP_ITC.1/SCD
FDP_ITC.1.1/SCD
FDP_ITC.1.2/SCD
FDP_ITC.1.3/SCD
The TSF shall enforce the [SCD Import SFP] when importing user data, controlled
under the SFP, from outside of the TSC.
The TSF shall ignore any security attributes associated with the user data when
imported from outside the TSC.
The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TSC: [SCD shall be sent by an Authorized
SSCD].
Application note:
A SSCD of Type 1 is authorised to send SCD to a 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
are able to establish a trusted channel to the SSCD of Type 2 for SCD transfer as required by
FTP_ITC.1.3/SCD export.
Type 2 only.
Remark: Link with trusted channel SFP.
FDP_ITC.1/DTBS
FDP_ITC.1.1/DTBS
ST
The TSF shall enforce the [Signature-creation SFP] when importing user data,
controlled under the SFP, from outside of the TSC.
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 38 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FDP_ITC.1.2/DTBS
FDP_ITC.1.3/DTBS
The TSF shall ignore any security attributes associated with the user data when
imported from outside the TSC.
The TSF shall enforce the following rules when importing user data controlled
under the SFP from outside the TSC: [DTBS-representation shall be sent by an
Authorized SCA].
Application note:
A 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.
Remark: Link with trusted channel and authenticate SFP.
6.1.3.5 FDP_RIP Residual information protection
FDP_RIP.1: Subset residual information protection
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, and RAD].
FDP_RIP.1.1
Remark: Link with SCD destruction SFP.
6.1.3.6 FDP_SDI Stored data integrity
FDP_SDI.2 Stored data integrity monitoring and action
FDP_SDI.2/Persistent
The following data persistently stored by TOE have the user data attribute “integrity checked persistent stored
data”
1. SCD
2. RAD
3. SVD (if persistently stored by TOE)
FDP_SDI.2.1/
Persistent
The TSF shall monitor user data stored within the TSC for [integrity error] on
all objects, based on the following attributes: [integrity checked persistent
stored data].
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.]
FDP_SDI.2.2/
Persistent
FDP_SDI.2/DTBS
The DTBS representation temporarily stored by TOE has the user data attribute “integrity checked stored
data”
FDP_SDI.2.1/DTBS
FDP_SDI.2.2/DTBS
ST
The TSF shall monitor user data stored within the TSC for [integrity error] on
all objects, based on the following attributes: [integrity checked stored data].
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.]
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 39 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Application note:
DTBS is input into the TOE by the Signing command. It is not stored in the card between two commands.
6.1.3.7 FDP_UCT Inter-TSF user data confidentiality transfer protection
FDP_UCT.1 Basic data exchange confidentiality
FDP_UCT.1/Receiver
FDP_UCT.1.1/Receiver
The TSF shall enforce the [SCD Import SFP, Personalization SFP and
Change RAD SFP] to be able to [receive] objects in a manner protected from
unauthorized disclosure.
Application note: Type 2 only.
6.1.3.8 FDP_UIT Inter-TSF user data integrity transfer protection
FDP_UIT.1: Data exchange integrity
FDP_UIT.1/SVD Transfer
FDP_UIT.1.1/
Transfer
FDP_UIT.1.2/
Transfer
SVD The TSF shall enforce the [SVD Transfer SFP] to be able to [transmit] user
data in a manner protected from [modification and insertion] errors.
SVD The TSF shall be able to determine on receipt of user data, whether
[modification and insertion] has occurred.
FDP_UIT.1/TOE DTBS
FDP_UIT.1.1/TOE DTBS
FDP_UIT.1.2/TOE DTBS
The TSF shall enforce the [Signature-creation SFP] to be able to [receive]
user data in a manner protected from [modification, deletion and insertion]
errors.
The TSF shall be able to determine on receipt of user data, whether
[modification, deletion and insertion] has occurred.
Refinement: The mentioned user data is the DTBS-representation.
6.1.4 FIA: Identification and authentication
6.1.4.1 FIA_AFL Authentication failure
FIA_AFL.1 Authentication failure handling
FIA_AFL.1.1
FIA_AFL.1.2
The TSF shall detect when [3] unsuccessful authentication attempts occur related to
[consecutive failed authentication attempts].
When the defined number of unsuccessful authentication attempts has been met or
surpassed, the TSF shall [block RAD]
Refinement:
When the RAD is blocked, any attempt of authentication fails.
Remark: Link with Authenticate SFP.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 40 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
6.1.4.2 FIA_ATD User attribute definition
FIA_ATD.1User attributes definition
FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belonging to individual users
[RAD]
Remark: Link with personalization SFP and Change RAD SFP.
6.1.4.3 FIA_UAU User authentication
FIA_UAU.1 Timing of authentication
The TSF shall allow
1 [Identification of the user by means of TSF required by FIA_UID.1]
2 [Establishing a trusted channel 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.
The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
FIA_UAU.1.1
FIA_UAU.1.2
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.
Note: The TSF shall allow no Signature generation related action to be performed before user is
authenticated. That means that other actions, not specifically related to the Signature creation, may be
performed before user is authenticated.
Dependencies: FIA_UID.1 Timing of identification.
6.1.4.4 FIA_UID User Identification
FIA_UID.1Timing of identification
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.
The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
FIA_UID.1.1
FIA_UID.1.2
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 41 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
Note: The TSF shall allow no Signature generation related action to be performed before user is identified.
That means that other actions, not specifically related to the Signature creation, may be performed before user
is identified.
6.1.5 FMT: Security management
6.1.5.1 FMT_MOF Management of functions in TSF
FMT_MOF.1 Management of security functions behavior
FMT_MOF.1.1
The TSF shall restrict the ability to [enable] the [signature-creation function]
to [Signatory].
6.1.5.2 FMT_MSA Management of security attributes
FMT_MSA.1 Management of security attributes
FMT_MSA.1/Administrator
FMT_MSA.1.1/
Administrator
The TSF shall enforce the [Initialization SFP] and [SCD Import SFP] to restrict
the ability to [modify] the security attributes [SCD / SVD management and
secure SCD import allowed] to [Administrator].
Application note:
The SCD Import SFP enforcing comes from Type 2.
The Initialisation SFP enforcing comes from Type 3.
FMT_MSA.1/Signatory
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].
FMT_MSA.2 Secure security attributes
The TSF shall ensure that only secure values are accepted for security
attributes.
FMT_MSA.2.1
FMT_MSA.3 Static attribute initialization
FMT_MSA.3/Type 2
FMT_MSA.3.1/Type 2
The TSF shall enforce the [SCD Import 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 import of the SCD.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 42 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FMT_MSA.3.2/Type 2
The TSF shall allow the [Administrator] to specify alternative initial values to
override the default values when an object or information is created.
FMT_MSA.3/Type 3
FMT_MSA.3.1/Type 3
The TSF shall enforce the [Initialization 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 of the SCD.
FMT_MSA.3.2/Type 3
The TSF shall allow the [Administrator] to specify alternative initial values to
override the default values when an object or information is created.
6.1.5.3 FMT_MTD Management of TSF data
FMT_MTD.1 Management of TSF data
FMT_MTD.1.1
The TSF shall restrict the ability to [modify] the [RAD] to [Signatory].
Note: RAD being the PIN code, RAD and VAD are the same data.
Remark: Link with Change RAD SFP.
6.1.5.4 FMT_SMF Specification of Management Functions
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1
The TSF shall be capable of performing the following functions [Identification and
authentication management].
Additional SFR
6.1.5.5 FMT_SMR Security management roles
FMT_SMR.1 Security roles
FMT_SMR.1.1
FMT_SMR.1.2
The TSF shall maintain the roles [Administrator] and [Signatory].
The TSF shall be able to associate users with roles.
6.1.6 FPT: Protection of the TSF
6.1.6.1 FPT_AMT Underlying Abstract machine test
FPT_AMT.1 Underlying Abstract machine test
FPT_AMT.1.1
ST
The TSF shall run a suite of tests [during initial start-up] to demonstrate the correct
operation of the security assumptions provided by the abstract machine that underlies the
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 43 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
TSF.
Refinement:
In this document, the underlying abstract machine test is the IC and its library.
Remark: Link with Protection SFP.
6.1.6.2 FPT_EMSEC TOE Emanation
FPT_EMSEC.1.1 TOE Emanation
FPT_EMSEC.1.1
The TOE shall not emit [Side channel current] in excess of [State of the art
limits] enabling access to [RAD and SCD].
Notes:
This SFR is an extension to [CCPART 2].
State of the art limits are the limits currently expected for IC meeting EAL4+ level of security.
FPT_EMSEC.1.2
The TSF shall ensure [all users] are unable to use the following interface
[external contacts] emanations to gain access to [RAD and SCD].
Notes:
This SFR is an extension to [CCPART 2].
State of the art limits are the limits currently expected for IC meeting EAL4+ level of security.
Remark: Link with Protection SFP.
6.1.6.3 FPT_FLS Failure secure
FPT_FLS.1 Failure with preservation of secure state
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur:
power shortage, over and under voltage, over and under clock frequency, over
and under temperature, integrity problems, unexpected abortion of the execution
of the TSF due to external events.].
Remark: Link with Protection SFP.
6.1.6.4 FPT_PHP TSF physical Protection
FPT_PHP.1 Passive detection of physical attack
FPT_PHP.1.1
FPT_PHP.1.2
ST
The TSF shall provide unambiguous detection of physical tampering that might
compromise the TSF.
The TSF shall provide the capability to determine whether physical tampering with the
TSF's devices or TSF's elements has occurred.
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 44 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
FPT_PHP.3 Resistance to physical attack
FPT_PHP.3.1
The TSF shall resist [voltage, clock frequency and temperature out of bounds as
well as penetration attacks] to the [integrated circuit] by responding automatically
such that the TSP is not violated
Remark: Link with Protection SFP.
6.1.6.5 FPT_TST TSF self test
FPT_TST.1 TSF testing
FPT_TST.1.1
The TSF shall run a suite of self-tests [during initial start-up] to demonstrate the
correct operation of the TSF.
The TSF shall provide authorized users with the capability to verify the integrity of TSF
data.
The TSF shall provide authorized users with the capability to verify the integrity of
stored TSF executable code.
FPT_TST.1.2
FPT_TST.1.3
Remark: Link with Protection SFP.
6.1.7 FTP: Trusted Path / Channel
6.1.7.1 FTP_ITC Inter-TSF trusted channel
FTP_ITC.1 Inter-TSF trusted Channel
FTP_ITC.1/SCD import
FTP_ITC.1.1/SCD import
FTP_ITC.1.2/SCD import
FTP_ITC.1.3/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.
The TSF shall permit [the remote trusted IT product] to initiate
communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [SCD import]
Refinement: The mentioned remote trusted IT product is a SSCD of type 1.
Application note:
The SCD Import must be protected in Integrity. This protection must be ensured by crypto mechanisms in the
TOE. No “Trusted Environment” can ensure this integrity.
Type 2 only.
Remark: Link with SCD import SFP.
FTP_ITC.1/SVD Transfer
FTP_ITC.1.1/SVD
Transfer
ST
The TSF shall provide a communication channel between itself and a remote
trusted IT product that is logically distinct from other communication channels
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 45 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
and provides assured identification of its end points and protection of the
channel data from modification or disclosure.
The TSF shall permit [the remote trusted IT product] to initiate
communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [SVD
Transfer]
FTP_ITC.1.2/SVD
Transfer
FTP_ITC.1.3/SVD
Transfer
Refinement: The mentioned remote trusted IT product is a CGA or the SCA application that will transmit the
SVD to the CGA.
Application note:
The SVD Transfer must be protected in Integrity. This protection can be ensured by crypto mechanisms in the
TOE. It can also be ensured by a “Trusted Environment”. At personalization time, the Issuer will be able to
assess if the usage environment will be a “Trusted Environment”.
Remark: Link with SVD transfer SFP.
FTP_ITC.1/ DTBS import
FTP_ITC.1.1/DTBS import
FTP_ITC.1.2/DTBS import
FTP_ITC.1.3/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.
The TSF shall permit [the remote trusted IT product] to initiate
communication via the trusted channel.
The TSF shall initiate communication via the trusted channel for [signing
DTBS-representation]
Refinement: The mentioned remote trusted IT product is a SCA.
Application note:
The DTBS Import must be protected in Integrity. This protection can be ensured by crypto mechanisms in the
TOE. It can also be ensured by a “Trusted Environment”. At personalization time, the Issuer will be able to
assess if the usage environment will be a “Trusted Environment”.
Remark: Link with Signature creation SFP.
6.1.7.2 FTP_TRP Trusted path
FTP_TRP.1 Trusted path
FTP_TRP.1.1
FTP_TRP.1.2
FTP_TRP.1.3
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.
The TSF shall permit [local users] to initiate communication via the trusted path.
The TSF shall require the use of the trusted path for [initial user authentication][no
other service].
Application note:
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 46 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
The RAD/VAD Import must be protected in Integrity and confidentiality. This protection can be ensured by
crypto mechanisms in the TOE. It can also be ensured by a “Trusted Environment”. At personalization time,
the Issuer will be able to assess if the usage environment will be a “Trusted Environment”.
6.2
SECURITY ASSURANCE REQUIREMENTS
The TOE security assurance requirements define the assurance requirements for the TOE using only
assurance components drawn from [CCPART3].
The assurance level is EAL4 augmented on:
• ADV_IMP.2 (Complete mapping of the implementation representation of the TSF)
• ALC_DVS.2 ( Sufficiency of security measures)
• AVA_MSU.3 (Misuse - Analysis and testing for insecure states)
• And AVA_VLA.4 (Vulnerability Analysis - Highly resistant).
6.2.1 TOE security assurance requirements list
All requirements below are those from [PP SSCD3].
Identification
DESCRIPTION
ACM
Configuration management
ACM_AUT.1 Partial CM automation
ACM_CAP.4 Generation support and acceptance procedures
ACM_SCP.2 Problem tracking CM coverage
ADO
Delivery and Operation
ADO_DEL.2 Detection of modification
ADO_IGS.1 Installation, generation and start-up procedures
ADV
Development
ADV_FSP.2 Fully defined external interfaces
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.2 Implementation of the TSF
ADV_LLD.1 Descriptive low-level design
ADV_RCR.1 Informal correspondence demonstration
ADV_SPM.1 Informal TOE security policy model
AGD
Guidance documents
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ALC
Life cycle support
ALC_DVS.2 Sufficiency of security measures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ATE
Tests
ATE_COV.2 Analysis of coverage
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 47 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
ATE_DPT.1 Testing: high –level design
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing – sample
AVA
Vulnerability assessment
AVA_MSU.3 Analysis and testing for insecure states
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.4 Highly resistant
Table 6 . TOE security assurance requirements list
6.3
SECURITY REQUIREMENTS FOR THE IT ENVIRONMENT
This section describes the IT security requirements that are to be met by the IT environment of the TOE. The
IT environment of the TOE is composed of the Certification Generation Application (CGA) and the Signature
Creation Application (SCA).
These requirements are as stated in [PP SSCD2] & [PP SSCD3].
6.3.1
Signature key generation (SSCD Type1)
6.3.1.1 FCS_CKM.1: Cryptographic key generation
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm [RSA key generation] and specified cryptographic key sizes
[1024 bits or 1536 bits] that meet the following: none (generation of random numbers
and Miller- Rabin primality testing).
FCS_CKM.1.1
6.3.1.2 FCS_CKM.4: Cryptographic key destruction
FCS_CKM.4.1/
Type1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method [physical irreversible destruction of the stored key value]
that meets the following: [no standard].
Application notes:
The cryptographic key SCD will be destroyed automatically after export.
6.3.1.3 FCS_COP.1: Cryptographic operation
FCS_COP.1.1/C The TSF shall perform SCD / SVD correspondence verification in accordance with a
ORRESP
specified cryptographic algorithm [RSA key generation] and cryptographic key sizes
[1024 bits or 1536 bits] that meet the following: [no standard].
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 48 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
6.3.1.4 FDP_ACC.1: Subset access control
The TSF shall enforce the SCD Export SFP on export of SCD by Administrator.
FDP_ACC.1.1/
SCD Export SFP
6.3.1.5 FDP_UCT.1: Basic data exchange confidentiality
The TSF shall enforce the SCD Export SFP to be able to transmit objects in a manner
protected from unauthorised disclosure.
FDP_UCT.1.1/
Sender
6.3.1.6 FTP_ITC.1: Inter-TSF trusted channel
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.
The TSF shall permit [the remote trusted IT product] to initiate communication via the
trusted channel.
FTP_ITC.1.1/
SCD Export
FTP_ITC.1.2/
SCD Export
FTP_ITC.1.3/
SCD Export
The TSF or the SSCD Type2 shall initiate communication via the trusted channel for SCD
export.
Refinement: The mentioned remote trusted IT product is a SSCD Type2
Application note:
If the TOE exports the SVD to a SSCD Type2 and the SSCD Type 2 holds the SVD then the trusted channel
between the TOE and the SSCD type 2 will be required.
6.3.2 Certification Generation application (CGA)
6.3.2.1 FCS_CKM.2
The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method [qualified
certificate] that meets the following [TDES 112 bits or DiffieHellman 1024]
FCS_CKM.2.1 / CGA
6.3.2.2 FCS_CKM.3
The TSF shall perform [import the SVD] in accordance with a
specified cryptographic key access method [import through a
secure channel that meets the following: [no standard]
FCS_CKM.3.1 /CGA
6.3.2.3 FDP_UIT.1
The TSF shall enforce the SVD Import SFP to be able to receive
user data in a manner protected from modification and insertion
errors.
FDP_UIT.1.1 / SVD Import
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 49 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
The TSF shall be able to determine on receipt of user data, whether
modification and insertion has occurred.
FDP_UIT.1.2 / SVD Import
6.3.2.4 FTP_ITC.1
FTP_ITC.1.1 / SVD 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 / SVD Import
The TSF shall permit [the TSF] to initiate communication via the
trusted channel.
FTP_ITC.1.3 / SVD Import
The TSF or the remote trusted IT product shall
communication via the trusted channel for[ import SVD]
initiate
6.3.3 Signature creation application (SCA)
6.3.3.1 FCS_COP.1
FCS_COP.1.1 /
The TSF shall perform [hashing the DTBS] in accordance with a
specified cryptographic algorithm [SHA-1 or SHA-256] and
cryptographic key sizes [none] that meet the following: [FIPS
180-2], hash length = 160 or 256 bits].
SCA Hash
6.3.3.2 FDP_UIT.1
The TSF shall enforce the Signature-creation SFP to be able to
transmit user data in a manner protected from modification, deletion,
and insertion errors.
FDP_UIT.1.1 /
SCA DTBS
FDP_UIT.1.2 /
The TSF shall be able to determine on receipt of user data, whether
modification, deletion, and insertion has occurred.
SCA DTBS
6.3.3.3 FTP_ITC.1
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.1 /
SCA DTBS
FTP_ITC.1.2 /
The TSF shall permit the TSF to initiate communication via the
trusted channel.
SCA DTBS
FTP_ITC.1.3 /
The TSF or the remote trusted IT product shall initiate
communication via the trusted channel for [signing DTBSrepresentation by means of the SSCD]
SCA DTBS
6.3.3.4 FTP_TRP.1
FTP_TRP.1.1 /
ST
The TSF shall provide a communication path between itself and
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 50 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
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.
SCA
FTP_TRP.1.2 /
The TSF shall permit the TSF to initiate communication via the
trusted path.
SCA
FTP_TRP.1.3 /
The TSF shall require the use of the trusted path for initial user
authentication.
SCA
6.4
SECURITY REQUIREMENTS FOR THE NON-IT ENVIRONMENT
R.Administrator_Guide
Application of Administrator Guidance
The implementation of the requirements of the Directive, ANNEX II “Requirements for certification-serviceproviders issuing qualified certificates”, literal (e), stipulates employees of the CSP or other relevant entities to
follow the administrator guidance provided for the TOE. Appropriate supervision of the CSP or other relevant
entities shall ensure the ongoing compliance.
R.Sigy_Guide
Application of User Guidance
The SCP implementation of the requirements of the Directive, ANNEX II “Requirements for certificationservice-providers issuing qualified certificates”, literal (k), stipulates the signatory to follow the user guidance
provided for the TOE.
R.Sigy_Name
Signatory’s name in the Qualified Certificate
The CSP shall verify the identity of the person to which a qualified certificate is issued according to the
Directive [1], ANNEX II “Requirements for certification-service-providers issuing qualified certificates”,
literal (d). The CSP shall verify that this person holds the SSCD which implements the SCD corresponding to
the SVD to be included in the qualified certificate.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 51 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
7 TOE SUMMARY SPECIFICATION
The security functions provided by the IC are described in [IC ST]. The security functions provided by the
platform are described in [ST_PLTF_ADRIATIC].
This section presents the security functions provided by the CIE/CNS applet.
Identification
Name
SF_SIG_AUTHENTICATION
Authentication management
SF_SIG_CRYPTO
Cryptography management
SF_SIG_INTEGRITY
Integrity monitoring
SF_SIG_MANAGEMENT
Management of operations & access control
SF_SIG_SECURE_MESSAGING
Secure messaging management
Table 7. TOE Security functions List
7.1
SF_SIG_AUTHENTICATION: AUTHENTICATION MANAGEMENT
This security function manages the authentication mechanisms such as:
• Authentication operations by PIN verification (for role management)
• Authentication by external authentication (with symmetric and asymmetric schemes).
This security function:
•
Manages authentication failure: when the pre-defined number (3) of unsuccessful authentication
attempts has been met or surpassed, the TSF shall block D.RAD. (Pre-defined number put at
personalization phase)
•
Manage the asset D.RAD.
•
Handles the authentications during the personalization and application phases.
This SF allows the following operations to be performed before the user is authenticated:
•
Identification of the user
•
Establishing a trusted path between local user and the TOE
•
Establishing a trusted channel between the SCA and the TOE for D.DTBS import
•
Establishing a trusted channel between the TOE and the SSCD Type 1 for D.SCD import
7.2
SF_SIG_CRYPTO: CRYPTOGRAPHY MANAGEMENT
This function manages residual information protection (related to SCD, VAD and RAD) and ONLY the
cryptographic operations of the electronic signature application (cryptographic operations not related to the
electronic signature are not involved on this SF.):
•
Key generation and correspondence verification (for RSA keypairs)
•
Key destruction
•
Perform cryptographic operations
This function is supported by platform security function SF_CARD_CRYPTO that provides cryptographic
algorithms TDES, RSA and RNG and ensures that D.SCD information is made unavailable after key
destruction.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 52 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
7.3
SF_SIG_INTEGRITY: INTEGRITY MONITORING
This SF monitors the integrity of sensitive user data and the integrity of the DTBS. The integrity of persistently
stored data such as D.SCD, D.RAD and D.SVD is monitored using the platform security function
SF_CARD_INTEGRITY.
In case of integrity error this SF will
•
Prohibit the use of the altered data, and
•
Inform the S.Signatory about integrity error.
This SF also monitors the integrity of the access conditions of created data objects.
7.4
SF_SIG_MANAGEMENT: MANAGEMENT OF OPERATIONS AND ACCESS CONTROL
This SF provides application operation management and access control.
Operation management
This SF manages the electronic signature application during its initialization and operation. This SF manages
the security environment of the application and:
•
Maintains the roles S.Signatory, S.Admin.
•
Controls if the authentication required for a specific operation has been performed with success.
•
Manages restriction to security function access and to security attribute modification.
•
Ensures that only secure values are accepted for security attributes.
This SF restricts the ability to perform the function Signature-creation SFP to S.Signatory. This SF ensures
that only S.Admin is authorized to
• Modify Initialization SFP and Signature-creation SFP attributes
• Specify alternative default values
This SF ensures that only S.Signatory is authorized to modify D.RAD (Change RAD SFP)
Access control
This SF provides the electronic signature application with access control and ensures that the following
operations are executed by authorized roles:
•
Export of D.SVD by S.User (SVD transfer SFP)
•
Import of D.SCD by S.User(SCD Import SFP)
•
Generation of D.SCD/D.SVD pair by S.User
•
Creation of D.RAD by S.Admin (Personalization SFP)
•
Signing of D.DTBS-representation by S.Signatory (Signature-creation SFP)
This SF provides access control to data objects.
This SF enforces the security policy on the import and the export of user data on:
•
SVD Transfer SFP: D.SVD shall be sent to an authenticated CGA.
•
Signature-creation SFP: D.DTBS shall be sent by an authenticated SCA.
7.5
SF_SIG_SECURE_MESSAGING
This SF ensures the integrity and the confidentiality of exchanged user data.
This SF ensures that the TSF is able to
• Receive D.SCD with protection from unauthorized disclosure.
• Transmit D.SVD with protection from modification and insertion errors.
• Receive D.DTBS with protection from modification, deletion and insertion errors.
• Determine on received user data whether modification, deletion or insertion has occurred.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 53 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
SECURITY TARGET
TOE CIE/CNS
This SF manages four modes of secure channel during the personalization phase and usage phase
•
No secure messaging
•
Integrity mode
•
Confidentiality mode
•
Integrity and confidentiality mode
Platform secure channel (SF_CARD_SECURE_MESSAGING) is used only at pre-personalization phase.
Specific and proprietary CIE secure channel is used at usage phase with support of SF_CARD_CRYPTO
security function.
ST
Applicable on: January 2008
⌧ Gemalto Public
Gemalto Private
Gemalto Restricted
Page : 54 / 54
Gemalto Confidential <code>
No disclosure to a third party without prior written consent of Gemalto
Gemalto Secret .
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement