Declaración de Seguridad
reducida de la
TARJETA TC-FNMT 5.6
29 de junio de 2023
Versión 2.1 Revisión 0
Versión 2.1.0 Página 2 de 158
NOMBRE FECHA
Elaborado por: Área de Desarrollo – Documentos de Identificación / Tarjetas 29/06/2023
Revisado por:
Aprobado por:
HISTÓRICO DEL DOCUMENTO
Versión Revisión Fecha Descripción Autor
2.1 0 29/06/2023 Versión reducida FNMT-RCM
Documento clasificado como: Público
Destinatarios: Departamento de Documentos de Identificación/Tarjetas de la FNMT-RCM, Applus
Laboratories, Centro Criptológico Nacional
Introducción
Versión 2.1.0 Página 3 de 158
Indice
1. Introducción .......................................................................................................................... 7
1.1. Identificación..................................................................................................................... 7
1.1.1. Identificación de la declaración de seguridad............................................................... 7
1.1.2. Identificación del objeto a evaluar (TOE)...................................................................... 7
1.2. Resumen............................................................................................................................ 8
1.2.1. Non-TOE Hardware/Software/Firmware ...................................................................... 8
1.3. Descripción del TOE........................................................................................................... 8
1.4. Ciclo de vida .................................................................................................................... 11
2. Declaraciones de conformidad ........................................................................................... 13
2.1. Declaración de conformidad respecto a los Criterios Comunes ..................................... 13
2.2. Declaración de conformidad respecto a otros PP........................................................... 13
2.3. Conformidad con eIDAS .................................................................................................. 14
2.4. Justificación de conformidad .......................................................................................... 14
3. Compatibilidad entre funcionalidades del TOE................................................................... 15
4. Security problem definition ................................................................................................ 16
4.1. Introduction .................................................................................................................... 16
4.1.1. Assets .......................................................................................................................... 16
4.1.1.1. Primary assets ......................................................................................................... 16
4.1.1.2. Secondary assets..................................................................................................... 16
4.1.1.2.1. Secondary assets from [MR.ED-ON-PP] .................................................................. 16
4.1.2. Subjects ....................................................................................................................... 17
4.1.2.1.1. Subject from [MR.ED-ON-PP].................................................................................. 20
4.2. Threats............................................................................................................................. 20
4.2.1. Threats from [MR.ED-PP]............................................................................................ 20
4.2.2. Threats from [MR.ED-ON-PP]...................................................................................... 20
4.2.3. Threats from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and [SSCDPP6] ............... 21
4.3. Organizational Security Policies ...................................................................................... 23
4.3.1. OSPs from [MR.ED-PP] ................................................................................................ 23
4.3.2. OSPs from [MR.ED-ON-PP].......................................................................................... 23
4.3.3. OSPs from [EAC2PP].................................................................................................... 24
4.3.4. OSPs from [PACEPP].................................................................................................... 24
Introducción
Versión 2.1.0 Página 4 de 158
4.3.5. OSPs from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and [SSCDPP6] ................... 26
4.4. Assumptions.................................................................................................................... 27
4.4.1. Assumptions from [PACEPP] ....................................................................................... 27
4.4.2. Assumptions from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and [SSCDPP6]....... 28
5. Security Objectives.............................................................................................................. 28
5.1. Security Objectives for the TOE ...................................................................................... 28
5.1.1. Security Objectives for the TOE from [MR.ED-PP]...................................................... 28
5.1.2. Security Objectives for the TOE from [MR.ED-ON-PP]................................................ 29
5.1.3. Security Objectives for the TOE from [PACEPP].......................................................... 30
5.1.4. Security objectives for the TOE from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6].................................................................................................................................... 32
5.2. Security Objectives for the Operational Environment.................................................... 34
5.2.1. Security objectives from [MR.ED-PP].......................................................................... 34
5.2.2. Security objectives from [MR.ED-ON-PP].................................................................... 35
5.2.3. Security Objectives from [EAC2PP] ............................................................................. 36
5.2.4. Security Objectives from [PACEPP] ............................................................................. 37
5.2.5. Security Objectives from [SSCDPP], [SCCDPP3], [SSCDPP4], [SSCDPP5] Y [SSCDPP6] 39
5.3. Security Objective Rationale ........................................................................................... 42
6. Extended Components Definition....................................................................................... 46
6.1. Extended Components Definition from claimed PPs...................................................... 46
6.2. Propiterary Extended Components Definition................................................................ 47
7. Security Requirements........................................................................................................ 52
7.1. Security Functional Requirements .................................................................................. 55
7.1.1. Class FCS...................................................................................................................... 55
7.1.1.1. SFRs for [MR.ED-ON-PP].......................................................................................... 55
7.1.1.2. SFRs for [EAC2PP].................................................................................................... 61
7.1.1.3. SFRs for [SSCDPP].................................................................................................... 67
7.1.1.4. SFRs for [SSCDPP] and [SSCDPP3] ........................................................................... 68
7.1.1.5. Class FCS for PRO secure channel ........................................................................... 71
7.1.2. Class FIA....................................................................................................................... 73
7.1.2.1. SFRs for [MR.ED-ON-PP].......................................................................................... 73
7.1.2.2. SFRs for [EAC2PP].................................................................................................... 75
7.1.2.3. SFRs concerning eSign-applications [SSCDPP], [SSCDPP3], [SSCDPP4] and
[SSCDPP6] 84
Introducción
Versión 2.1.0 Página 5 de 158
7.1.3. Class FDP ..................................................................................................................... 86
7.1.3.1. SFRs for [MR.ED-PP]................................................................................................ 86
7.1.3.2. SFRs for [MR.ED-ON-PP].......................................................................................... 89
7.1.3.3. SFRs for [EAC2PP].................................................................................................... 95
7.1.3.4. SFRs for [SSCDPP], [SSCDPP3] and [SSCDPP6]......................................................... 97
7.1.3.5. SFRs for [SSCDPP3]................................................................................................ 104
7.1.3.6. SFRs for [SSCDPP4]................................................................................................ 106
7.1.3.7. SFRs for [SSCDPP5] and [SSCDPP6] ....................................................................... 107
7.1.4. Class FTP.................................................................................................................... 108
7.1.4.1. SFRs for [MR.ED-ON-PP]........................................................................................ 108
7.1.4.2. SFRs for [EAC2PP].................................................................................................. 108
7.1.4.3. SFRs for [SSCDPP3]................................................................................................ 110
7.1.4.4. SFRs for [SSCDPP4]................................................................................................ 111
7.1.4.5. SFRs for [SSCDPP5] and [SSCDPP6] ....................................................................... 112
7.1.5. Class FAU................................................................................................................... 113
7.1.5.1. SFRs for [MR.ED-ON-PP]........................................................................................ 113
7.1.5.2. SFRs for [EAC2PP].................................................................................................. 114
7.1.6. Class FMT................................................................................................................... 115
7.1.6.1. SFRs for [MR.ED-PP].............................................................................................. 115
7.1.6.2. SFRs for [MR.ED-ON-PP]........................................................................................ 117
7.1.6.3. SFRs for [EAC2PP].................................................................................................. 119
7.1.6.4. SFRs for [SSCDPP] and [SSCDPP3] ......................................................................... 129
7.1.7. Class FPT.................................................................................................................... 135
7.1.7.1. SFRs for [MR.ED-ON-PP]........................................................................................ 135
7.1.7.2. SFRs for [EAC2PP].................................................................................................. 137
7.1.7.3. SFRs for [SSCDPP].................................................................................................. 138
7.2. Security Assurance Requirements for the TOE ............................................................. 140
7.3. Security Requirements Rationale.................................................................................. 142
7.3.1. Security Functional Requirements Rationale............................................................ 142
7.3.2. Rationale for SFR’s Dependencies............................................................................. 145
7.3.3. Security Assurance Requirements Rationale ............................................................ 146
7.3.4. Security Requirements – Internal Consistency ......................................................... 147
8. Resumen de las características funcionales del producto ................................................ 148
Introducción
Versión 2.1.0 Página 6 de 158
9. Acrónimos ......................................................................................................................... 152
10. Bibliografía .................................................................................................................... 154
11. Índice de tablas ............................................................................................................. 158
Introducción
Versión 2.1.0 Página 7 de 158
1. Introducción
1.1. Identificación
1.1.1. Identificación de la declaración de seguridad
Título: Declaración de Seguridad de la tarjeta TC-FNMT 5.6
Nombre del fichero: Declaración de Seguridad TC-FNMT
Versión: 2.1.
Revisión: 0.
Autor: FNMT - Departamento de Documentos de Identificación – Tarjetas
Fecha: 29 de junio de 2023
1.1.2. Identificación del objeto a evaluar (TOE)
TOE: TC-FNMT
Versión: 5.6
Compuesto de:
IC plataforma subyacente
Sistema Operativo: DNIe
Opciones:
 TCFNMT 05.70 A01 H 00B8
 TCFNMT 05.70 B01 H 00B8
 TCFNMT 05.70 C01 H 00B8
 TCFNMT 05.70 D01 H 00B8
 TCFNMT 05.70 E01 H 00B8
 TCFNMT 05.70 F01 H 00B8
Resumen
Versión 2.1.0 Página 8 de 158
1.2. Resumen
Esta declaración de seguridad establece las bases para la evaluación Common Criteria [CC] de la
tarjeta criptográfica de la Fábrica Nacional de Moneda y Timbre – Real Casa de la Moneda “TC-
FNMT” en su versión y opciones identificadas anteriormente.
The TOE type addressed by the current security target is a smartcard programmed according to
[TR03110-2]. The programmed smartcard is called an electronic document as a whole. Here, an
application is a collection of elementary files and their access conditions. We mainly distinguish
between SCD, SVD, DTBS and DTBS/R.
In addition to the above user data, there are also data required for TOE security functionality
(TSF). Such data is needed to execute the access control protocols, to verify integrity and
authenticity of user data, or to generate cryptographic signatures.
The TOE contains the following applications and protocols:
 Electronic Document configuration: user data contained in [TR03110-2]-conformant eSign
application. SCD, SVD, DTBS and DTBS/R used by eSign application are protected by
PACE/EAC2.
De aquí en adelante, al TOE se le denominará indistintamente “TC-FNMT”, “TCFNMT”, “tarjeta
TC-FNMT”, “electronic document” o simplemente “tarjeta”; a “SCD”, “SVD”, “DTBS” y “DTBS/R”
se le denominará indistintamente “user data”; y a “Company” se le denominará indistinamente
“organization”.
1.2.1. Non-TOE Hardware/Software/Firmware
No existe un hardware, software o firmware específico requerido por el TOE para llevar a cabo
las características de seguridad que declara. El TOE se define compuesto por el chip y el sistema
operativo del TOE. En cualquier caso, se debe tener en cuenta que el soporte plástico que
contiene el chip así como la antena son necesarios para representar un documento completo,
aunque estas partes no son imprescindibles para llevar a cabo las operaciones seguras del TOE.
1.3. Descripción del TOE
Como se ha indicado en el apartado “Identificación del objeto a evaluar (TOE)”, el TOE está
compuesto por un controlador de seguridad (chip) y un sistema operativo (DNIe, versión 5.70).
También se incluyen los manuales que contienen los procedimientos de operación e instalación:
Documento Referencia
Guía preparativa – Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023. [GP]
Guía operativa para usuario final – Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023. [GOU]
Guía operativa para administrador. Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023. [GOA]
Descripción del TOE
Versión 2.1.0 Página 9 de 158
Guías operativas – TC-FNMT 5.6. v2.0 r3. 27/02/2023. [GO]
Anexo I Ejemplo – Guía Operativa para usuario final v2.0 r3. 27/02/2023. [AGO]
Especificación funcional. Manual de comandos. TC-FNMT 5.6. v2.0 r4.
27/02/2023.
[CMD]
Scripts de expedición:
 TCFNMT_5_70_Expedicion_eSign_Sin_Claves_No_Bio_v01.esc (Para la
opción de TOE sin biometría).
 TCFNMT_5_70_Expedicion_eSign_Sin_Claves_BIOMETRIA_v01.esc (Para
la opción de TOE con biometría: sea Sagem o Siemens).
 TCFNMT_5_70_Expedicion_CerrarTCFNMT_v01.esc
 PACE_192.esc
 PRO_RSA.esc
-
El TOE se entrega encartado en una tarjeta física con el diseño gráfico y medidas de seguridad
al cliente por parte de la FNMT-RCM. Las tarjetas se agrupan y se almacenan en su embalaje
correspondiente (típicamente contenedores o cajas de cartón) y se empaquetan agrupados por
lotes que se entregan físicamente al cliente en las instalaciones de la FNMT-RCM o del cliente.
De forma adicional se entregan por correo los documentos y scripts de la tabla anterior cifrados
y en formato pdf, para su validación conforme a las especificaciones y requisitos del producto.
El cliente recibe por parte de la FNMT-RCM el TOE en Fase de Expedición. El cliente puede ser
cualquier entidad (incluyendo la misma FNMT-RCM).
En caso de que el TOE sea aquirido por parte del usuario final (i.e ciudadano) a través de la tienda
online de la FNMT-RCM. La entrega del TOE se realizará internamente entre el taller y el
departamento encargado de la expedición del TOE dentro de la FNMT-RCM. El proceso de
entrega entre el departamento encargado de la expedición y el usuario final queda fuera del
alcance de esta evaluación.
El conjunto de todos ellos conforma un TOE con las funciones de seguridad que a lo largo de
este apartado se detallan.
Los elementos controlador de seguridad y librería criptográfica, ya han sido evaluados y
certificados por su fabricante. Los resultados de estas certificaciones se emplean para realizar la
evaluación compuesta del TOE, conforme a los requisitos del documento [ASE_COMP].
The TOE contains the following applications and protocols:
 Electronic Document configuration: user data contained in [TR03110-2]-conformant eSign
application. User data of eSign applications are protected by PACE/EAC2.
The purpose and usage of the above mentioned application is as follows:
Descripción del TOE
Versión 2.1.0 Página 10 de 158
 An eSign application, as defined in [TR03110-2], is intended to generate qualified electronic
signatures. The main specific property distinguishing qualified electronic signatures from
other, i.e. advanced electronic signatures, is that they are based on qualified certificates
and created by secure signature creation devices (SSCD). For the eSign application, the
electronic document holder can control access to the digital signature functionality by
consciously presenting his electronic document to an EAC2 terminal and inputting his secret
PIN for this application.
This application contains its own set of user data, composed according to its requirements.
Application note 1: While it is technically possible to grant access to the electronic signature
functionality by inputting only the CAN (see [TR03110-2]), this technical option is not allowed by
the security policy defined for the eSign application. This is due to the fact that solely the
signatory – which is here the electronic document holder – shall be able to generate an
electronic signature on his own behalf.
Application note 2: The cryptographic algorithms used by the TOE are defined outside the TOE
in the Public Key Infrastructure. The security parameters of these algorithms must be selected
by the electronic document issuer according to the Organizational Security Policies. The TOE
supports the standardized domain parameters mentioned in [RFC5639] (key length 256, 384 and
512 bit), and the following NIST curves (P-256, P-384 and P-521). PACE and hence the General
Inspection Procedure require the use of AES-192. This depends on the Initialization of the TOE.
Operational use of the TOE is explicitly in the focus of current ST. Nevertheless, some TOE
functionality might not be directly accessible to the end-user during operational use. Some
single properties of the manufacturing and the card issuing life cycle phases that are significant
for the security of the TOE in its operational phase are also considered by the current ST.
Conformance with this ST requires that all life cycle phases are considered to the extent that is
required by the assurance package chosen here for the TOE.
The following TOE security features are the most significant for its operational use. The TOE
ensures that
 only authenticated terminals can get access to the user data stored on the TOE and use
security functionality of the electronic document according to the access rights of the
terminal,
 the electronic document holder can control access by consciously presenting his
electronic document and/or by entering his secret PIN,
 authenticity and integrity of user data can be verified,
 confidentiality of user data in the communication channel between the TOE and the
connected terminal is provided,
 inconspicuous tracing of the electronic document is averted,
 its security functionality and the data stored inside are self-protected, and
 digital signatures can be created.
Ciclo de vida
Versión 2.1.0 Página 11 de 158
The TOE also provides the following functions:
 to generate signature creation data (SCD) and the correspondent signature-verification
data (SVD),
 to export the SVD for certification,
 to import signature creation data (SCD) and, optionally, the correspondent signature
verification data (SVD),
 to, optionally, receive and store certificate info,
 to switch the TOE from a non-operational state to an operational state, and
 if in an operational state, to create digital signatures for data with the following steps:
o select an SCD if multiple are present in the SSCD,
o authenticate the signatory and determine its intent to sign,
o receive data to be signed or a unique representation thereof (DTBS/R),
o apply an appropriate cryptographic signature creation function using the
selected SCD to the DTBS/R.
1.4. Ciclo de vida
The TOE life cycle is described in terms of the above mentioned four life cycle phases. Akin to
[ICPP], the TOE life-cycle is additionally subdivided into seven steps.
Phase 1: Development
Step 1
The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC
dedicated software and the guidance documentation associated with these TOE components.
Step 2
The software developer uses the guidance documentation for the integrated circuit and the
guidance documentation for relevant parts of the IC dedicated software, and develops the IC
embedded software (operating system), the electronic document application(s) and the
guidance documentation associated with these TOE components.
The manufacturing documentation of the IC including the IC dedicated software and the
embedded software in the non-volatile non-programmable memories is securely delivered to
the IC manufacturer. The IC embedded software in the non-volatile programmable memories,
the application(s), and the guidance documentation is securely delivered to the electronic
document manufacturer.
Phase 2: Manufacturing
Step 3
Ciclo de vida
Versión 2.1.0 Página 12 de 158
In a first step, the TOE integrated circuit is produced. The circuit contains the electronic
document's chip dedicated software, and the parts of the electronic document's chip embedded
software in the non-volatile non-programmable memory (ROM). The IC manufacturer writes IC
identification data onto the chip in order to track and control the IC as dedicated electronic
document material during IC manufacturing, and during delivery to the electronic document
manufacturer. The IC is securely delivered from the IC manufacturer to the electronic document
manufacturer. If necessary, the IC manufacturer adds parts of the IC embedded software in the
non-volatile programmable memory, e. g. EEPROM.
Step 4 (optional)
If the electronic document manufacturer delivers a packaged component, the IC is combined
with hardware for the contact based or contactless interface.
Step 5
The electronic document manufacturer
1. if necessary, adds the IC embedded software, or parts of it in the non-volatile
programmable memories, e. g. EEPROM or FLASH,
2. creates the application(s), and
3. equips the electronic document's chip with pre-personalization data.
Creation of the application(s) implies the creation of the master file (MF), dedicated files (DFs),
and elementary files (EFs) according to [ISO7816-4]. How this process is handled internally
depends on the IC and IC embedded software.
The pre-personalized electronic document together with the IC identifier is securely delivered
from the electronic document manufacturer to the personalization agent. The electronic
document manufacturer also provides the relevant parts of the guidance documentation to the
personalization agent.
Phase 3: Personalization of the Electronic Document
Step 6
The personalization of the electronic document includes
1. the survey of the electronic document holder’s biographical data (optional),
2. the enrollment of the electronic document holder's biometric reference data, such as a
digitized portrait or other biometric reference data (optional),
3. printing the visual readable data onto the physical part of the electronic document
(optional), and
4. configuration of the TSF, if necessary.
Configuration of the TSF is performed by the personalization agent and includes, but is not
limited to, the creation of the digitized version of the textual, printed data, the digitized version
of e.g. a portrait, or a cryptographic signature of a cryptographic hash of the data that are stored
Declaraciones de conformidad
Versión 2.1.0 Página 13 de 158
on the chip. The personalized electronic document, if required together with appropriate
guidance for TOE use, is handed over to the electronic document holder for operational use.
Application note 3: TSF data are data for the operation of the TOE upon which the enforcement
of the SFRs relies CC Part 1 [CC]. Here TSF data include, but are not limited to, the personalization
agent's authentication key(s).
Phase 4: Operational Use
Step 7
The chip of the TOE is used by the electronic document and terminals that verify the chip's data
during the phase operational use. The user data can be read and modified according to the
security policy of the issuer.
The TOE additionally has the ability to update its TOE software during the life-cycle phase
operational use by a secure update mechanism. The updated TOE software is out of scope of
this ST as it will be a different version of the TOE.
Phase 5: End of life
Step 8
The TOE reaches its end of life and it is no longer valid.
2. Declaraciones de conformidad
2.1. Declaración de conformidad respecto a los Criterios Comunes
Esta declaración de seguridad declara conformidad con la norma [CC]:
• Common Criteria for Information Technology Security Evaluation Part 1:
Introduction and general model, Version 3.1, Revision 5, April 2017.
• Common Criteria for Information Technology Security Evaluation Part 2: Security
functional components, Version 3.1, Revision 5, April 2017. Se declara conformidad
extendida con esta parte.
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; Version 3.1, Revision 5, April 2017. Se declara
conformidad con esta parte.
2.2. Declaración de conformidad respecto a otros PP
Esta declaración de seguridad declara conformidad estricta con los siguientes perfiles de
protección [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] y [SSCDPP6]:
Conformidad con eIDAS
Versión 2.1.0 Página 14 de 158
• Protection Profiles for Secure Signature Creation Device – Part 2: Device with key
generation, prEN 14169-2:2012 ver. 2.0.1, 2012-01, BSI-CC-PP-0059-2009-MA-01,
[SSCDPP].
• Protection Profiles for Secure Signature Creation Device – Part 3: Device with key
import, prEN 14169-3:2012 ver. 1.0.2, 2012-07-24, BSI-CC-PP-0075, [SSCDPP3].
• Protection profiles for secure signature creation device — Part 4: Extension for
device with key generation and trusted channel to certificate generation
application. Version: 1.0.1. 2013-11-27, BSI-CC-PP-0071. [SSCDPP4].
• Protection profiles for secure signature creation device — Part 5: Extension for
device with key generation and trusted communication with signature creation
application. Version: 1.0.1. 2012-11-14, BSI-CC-PP-0072. [SSCDPP5].
• Protection profiles for secure signature creation device — Part 6: Extension for
device with key import and trusted communication with signature creation
application. Version: 1.0.4. 2013-04-03, BSI-CC-PP-0076. [SSCDPP6].
En resumen, esta declaración de seguridad cumple estrictamente el paquete de garantía EAL4
aumentado con los componentes ALC_DVS.2, ATE_DPT.2 y AVA_VAN.5 definidos en:
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; Version 3.1, Revision 5, April 2017.
2.3. Conformidad con eIDAS
Además del cumplimiento de los requisitos en la funcionalidad de firma electrónica, la TC-FNMT
v5.6 también cumple con los requisitos del Reglamento (UE) nº 910/2014 (eIDAS) en materia de
identificación electrónica, requisitos derivados de la Decisión de Ejecución (UE) 2016/650 de la
Comisión de 25 de abril de 2016 por la que se fijan las normas para la evaluación de los
dispositivos cualificados de creación de firmas y sellos con arreglo al artículo 30, apartado 3, y al
artículo 39, apartado 2 del Reglamento eIDAS.
2.4. Justificación de conformidad
El TOE presentado en esta declaración de seguridad se ajusta al tipo de objeto definido en
[SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] y [SSCDPP6], definido como documento electrónico
que contiene la aplicación de firma electrónica.
Se deduce del análisis del contenido y de la presentación de las evidencias, que se satisfacen los
requisitos del nivel de evaluación exigido, esto es, EAL4+ aumentado con ALC_DVS.2, ATE_DPT.2
y AVA_VAN.5.
La definición del problema de seguridad, los objetivos y requisitos de seguridad son consistentes
con los presentados en los perfiles de protección [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] y
[SSCDPP6], cumpliendo la conformidad estricta.
Compatibilidad entre funcionalidades
del TOE
Versión 2.1.0 Página 15 de 158
3. Compatibilidad entre funcionalidades del TOE
Con objeto de asegurar la compatibilidad de las diferentes funcionalidades presentes en el TOE
se ha tenido en cuenta el enfoque realizado por el perfil de protección:
• Common Criteria Protection Profile — Machine-Readable Electronic Documents
based on BSI TR-03110 for Official Use [MR.ED-PP], BSI-CC-PP-0087-V2-MA-01,
Version 2.0.3, July 18th, 2016.
Sin embargo, esta declaración de seguridad no declara formalmente conformidad con dicho
perfil de protección puesto que el TOE no implementa los protocolos de identificación
restringida (Restricted Identification), firma pseudónima (Pseudonymous Signature) y
autenticación de chip versión 3 (Chip Authentication 3) de la especificación técnica TR-03110
[TR03110-2].
Además, en lo referente a los mecanismos de protección, esta declaración de seguridad sigue
las recomendaciones descritas en el perfil de protección:
• Common Criteria Protection Profile — Electronic document implementing Extended
Access Control Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP), BSI-CC-PP-0086.
Version 1.01, May 20th, 2015. [EAC2PP].
Puesto que el último perfil de protección [EAC2PP] declaran a su vez conformidad estricta
con el perfil de protección [PACEPP], esta declaración de seguridad también sigue las
recomendaciones de forma implícita con dicho perfil de protección:
• Common Criteria Protection Profile — Machine Readable Travel Document using
Standard Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011-MA-01. Version
1.01, 22th July 2014. [PACEPP].
Sin embargo, esta declaración de seguridad no declara formalmente conformidad con dichos
perfiles de protección puesto que el TOE no implementa la apliación ePassport definida en
[PACEPP].
Del mismo modo, en lo referente al mecanismo de actualización del TOE, esta declaración de
seguridad sigue las recomendaciones descritas en el perfil de protección modular:
• Common Criteria Protection Profile - Configuration Machine Readable Electronic
Documents - Optionales Nachladen (Optional Post-Emission Updates) [MR.ED-ON-
PP], BSI-CC-PP-0090-2016, Version 0.9.2, August 18th, 2016.
No obstante, tampoco se declara formalmente conformidad con dicho perfil de protección
modular al estar definido éste sobre la base del perfil de protección [MR.ED-PP].
Security problem definition
Versión 2.1.0 Página 16 de 158
4. Security problem definition
4.1. Introduction
4.1.1. Assets
4.1.1.1. Primary assets
As long as they are in the scope of the TOE, the primary assets to be protected by the TOE are
listed below. For a definition of terms used, but not defined here, see the Glossary.
SCD
Private key used to perform an electronic signature operation. The confidentiality, integrity and
signatory’s sole control over the user of the SCD must be maintained.
This asset is included from [SSCDPP]
SVD
Public key linked to the SCD ans used to perform electronic signature verification. The integrity
of the SVD when it is exported must be maintained.
This asset is included from [SSCDPP]
DTBS
DTBS and DTBS/R: set of data, or its representation, which the signatory intends to sign. Their
integrity and unforgeability of the link to the signatory provided by the electronic signature must
be maintained.
This asset is included from [SSCDPP]
4.1.1.2. Secondary assets
In order to achieve a sufficient protection of the primary assets listed above, the following
secondary assets also have to be protected by the TOE.
4.1.1.2.1. Secondary assets from [MR.ED-ON-PP]
Secret Cryptographic Update Keys
All cryptographic key material related to the update mechanism; i.e. cryptographic material that
is used to establish a secure communication channel with the update terminal, to authenticate
an update terminal, to decrypt and verify the authenticity of an update package, and for other
update-related cryptographic operations. Note that this term deliberately includes public (in the
Subjects
Versión 2.1.0 Página 17 de 158
cryptographic sense) signing keys installed on the TOE for verifying the authenticity of update
packages, as well as ephemeral keys.
Meta-Data
Data that contains information about the update, e.g. version information, checksums,
information w.r.t. applicability to specific product versions and platforms, etc.
Update Data
Unencrypted data that is used to update the TOE software.
Note that we use the term update data to denote the unencrypted data. Encrypted update data,
appended with optional additional unencrypted meta-data (i.e. version number, TOE product
identifier), and signed, is called an update package.
Update Log Data
Log records that store information about previously applied updates and failed update attempts.
Update Package
Encrypted update data, appended with optional unencrypted meta-data, and signed.
Update Package Verification Status
Security attribute indicating whether the supplied update was successfully verified (and where
hence its authenticity and integrity can be assumed) or not, and whether an attempt to verify
was made or not. Allowed values are NOT VERIFIED, SUCCESSFULLY VERIFIED and VERIFICATION
FAILED.
Version Information
Version information that uniquely identify the version of the TOE software currently installed on
the TOE.
4.1.2. Subjects
This security target considers the following external entities and subjects:
Attacker
A threat agent (a person or a process acting on his behalf) trying to undermine the security policy
defined by the current ST, especially to change properties of the assets that have to be
maintained. The attacker is assumed to possess at most high attack potential. Note that the
attacker might capture any subject role recognized by the TOE.
Company Signing Certification Authority (CSCA)
Subjects
Versión 2.1.0 Página 18 de 158
An organization enforcing the policy of the electronic document issuer, i. e. confirming
correctness of user and TSF data that are stored within the electronic document. The CSCA
represents the organization specific root of the public key infrastructure (PKI) for the electronic
document, and creates Document Signer Certificates within this PKI.
Company Verifying Certification Authority (CVCA)
The Company Verifying Certification Authority (CVCA) enforces the privacy policy of the issuing
organization, i. e. enforcing protection of TSF data that are stored in the electronic document.
The CVCA represents the organization specific root of the PKI of EAC2 terminals and creates
Document Verifier Certificates within this PKI. Updates of the public key of the CVCA are
distributed as CVCA Link-Certificates.
Document Signer (DS)
An organization enforcing the policy of the CSCA. A DS signs the Document Security Object that
is stored on the electronic document for Passive Authentication. A Document Signer is
authorized by the organization CSCA that issues Document Signer Certificate. Note that this role
is usually delegated to a Personalization Agent.
Document Verifier (DV)
An organization issuing terminal certificates as a Certificate Authority, authorized by the
corresponding CVCA to issue certificates for EAC2 terminals, see [TR03110-3].
Electronic Document Holder
A person the electronic document issuer has personalized the electronic document for.
Personalization here refers to associating a person uniquely with a specific electronic electronic
document. This subject includes “Signatory” as defined [SSCDPP].
Electronic Document Presenter
A person presenting the electronic document to a terminal and claiming the identity of the
electronic document holder. Note that an electronic document presenter can also be an
attacker. Moreover, this subject includes “user” as defined in [SSCDPP].
Manufacturer
Generic term comprising both the IC manufacturer that produces the integrated circuit, and the
electronic document manufacturer that creates the electronic document and attaches the IC to
it. The manufacturer is the default user of the TOE during the manufacturing life cycle phase.
When referring to the role manufacturer, the TOE itself does not distinguish between the IC
manufacturer and the electronic document manufacturer.
PACE Terminal
Subjects
Versión 2.1.0 Página 19 de 158
A technical system verifying correspondence between the password stored in the electronic
document and the related value presented to the terminal by the electronic document
presenter. A PACE terminal implements the terminal part of the PACE protocol and
authenticates itself to the electronic document using a shared password (CAN). A PACE terminal
is not allowed reading EAC2 restricted access condition data.
Personalization Agent
An organization acting on behalf of the electronic document issuer that personalizes the
electronic document for the electronic document holder. Personalization includes some or all of
the following activities: (i) establishing the identity of the electronic document holder for the
biographic data in the electronic document, (ii) enrolling the biometric reference data of the
electronic document holder, (iii) writing a subset of these data on the physical electronic
document (optical personalization) and storing them within the electronic document's chip
(electronic personalization), (iv) writing document meta data (i. e. document type, issuing
organization, expiry date, etc.) (v) writing the initial TSF data, and (vi) signing the Document
Security Object, and the elementary files EF.CardSecurity and the EF.ChipSecurity (if applicable
[ICAO9303], [TR03110-3]) in the role DS. Note that the role personalization agent may be
distributed among several institutions according to the operational policy of the electronic
document issuer. This subject includes “Administrator” as defined in [SSCDPP].
EAC2 Terminal
A terminal that has successfully passed the Terminal Authentication protocol (TA) version 2 is
an EAC2 terminal. It is authorized by the electronic document issuer through the Document
Verifier of the receiving branch (by issuing terminal certificates) to access a subset or all of the
data stored on the electronic document.
Terminal
A terminal is any technical system communicating with the TOE through the contactless or
contact-based interface. The role terminal is the default role for any terminal being recognized
by the TOE as neither being authenticated as a PACE terminal nor an EAC2 terminal.
Users
This ST considers the following users and subjects acting for users:
 User: End user of the TOE that can be indentified as administrator or signatory. The
subject S.User may act as S.Admin in the role of R.Admin or as S.Sigy in the role of
R.Sigy.
 Administrator: User who is in charge to perform the TOE initialization, TOE
personalization or other TOE administrative functions. The subject S.Admin is acting
in the role R.Admin for this user after successful authentication as administrator.
 Signatory: User who hold the TOE and uses it on his own behalf or on behalf of the
natural or legal person or entity he represent. The subject S.Sigy is acting in the role
R.Sigy for this user after successful authentication as signatory.
Subject from [MR.ED-ON-PP]
Versión 2.1.0 Página 20 de 158
4.1.2.1.1. Subject from [MR.ED-ON-PP]
Update Terminal
A terminal to read out version information and update log data of the TOE software, and to
install updates of the TOE software. Prior executing these functions, the update terminal must
authenticate itself towards the TOE.
4.2. Threats
This section describes the threats to be averted by the TOE independently or in collaboration
with its IT environment. These threats result from the assets protected by the TOE and the
method of the TOE's use in the operational environment.
4.2.1. Threats from [MR.ED-PP]
This section includes the following threats from [MR.ED-PP].
 T.InconsistentSec Inconsistency of security measures
Adverse action: An attacker gains read or write access to SCD and/or SVD
without being allowed to, due to an ambiguous/unintended
configuration of the TOE's internal access conditions of user or
TSF data. This may lead to a forged electronic document or
misuse of SCD and/or SVD.
Threat agent: having high attack potential, being in possession of one or more
legitimate electronic documents.
Asset: SCD and SVD.
 T.Interfere Interference of security protocols
Adverse action: An attacker uses an unintended interference of implemented
security protocols to gain access to SCD and/or SVD.
Threat agent: having high attack potential, being in possession of one or more
legitimate electronic documents.
Asset: SCD and SVD
4.2.2. Threats from [MR.ED-ON-PP]
 T.FaTSF Faulty TSF
Adverse action: An attacker gains read or write access to SCD, SVD or TSF data,
or manipulates or mitigates the TSF, for example due to:
Threats from [SSCDPP], [SSCDPP3],
[SSCDPP4], [SSCDPP5] and
[SSCDPP6]
Versión 2.1.0 Página 21 de 158
 software issues that were not detected, not exploitable, or
deemed unable to being exploitable at the time of
certification, but due to unforeseen advances in technology
became a security risk during operational use of the TOE, or
 cryptographic mechanisms that were deemed secure at the
time of certification, but due to unforeseen advances in the
field of cryptography became a security risk during
operational use of the TOE.
Threat agent: having high attack potential, being in possession of one or more
legitimate electronic documents
Asset: all data stored on the TOE (esp. the integrity, authenticity and –
if applicable – secrecy of the data)
 T.UaU Unauthorized Update
Adverse action: An attacker gains read or write access to SCD, SVD or TSF data,
or manipulates or mitigates the TSF by misuse of the update
functionality. This threat contains two main aspects:
 the unauthorized installation, which may lead to the use of
untimely, outdated or revoked updates.
 the installation of updates that are not authorized and
authentic.
Threat agent: having high attack potential, being in possession of one or more
legitimate electronic documents
Asset: all data stored on the TOE (esp. the integrity, authenticity and –
if applicable – secrecy of the data).
4.2.3. Threats from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5]
and [SSCDPP6]
Threat agents:
1. Attacker: Human or process acting on their behalf located outside the TOE. The main goal
of the attacker is to access the SCD or to falsify the electronic signature. The attacker has
got a high attack potential and knows no secret.
The current section also includes all threats of [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6].
Threats from [SSCDPP], [SSCDPP3],
[SSCDPP4], [SSCDPP5] and
[SSCDPP6]
Versión 2.1.0 Página 22 de 158
 T.DTBS_Forgery Forgery of the DTBS/R
An attacker modifies the DTBS/R sent by the SCA. Thus the
DTBS/R used by the TOE for signing does not match the DTBS
the signatory intended to sign.
 T.Hack_Phys Physical attacks through the TOE interfaces
An attacker interacts physically with the TOE to exploit
vulnerabilities, resulting in arbitrary security compromises. This
threat is directed against SCD, SVD and DTBS.
 T.SCD_Derive Derive the signature-creation data
An attacker derives the SCD from publicly known data, such as
SVD corresponding to the SCD or signatures created by means
of the SCD or any other data exported outside the TOE, which is
a threat against the secrecy of the SCD.
 T.SCD_Divulg Storing, copying, and releasing of the signature-creation data
An attacker stores or copies the SCD outside the TOE. An
attacker can obtain the SCD during generation, storage and use
for signature-creation in the TOE.
 T.Sig_Forgery Forgery of the digital signature
An attacker forges a signed data object, maybe using an
electronic signature which has been 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
created 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.
 T.SigF_Misuse Misuse of the signature-creation function of the TOE
An attacker misuses the signature-creation function of the TOE
to create a digital signature for data the signatory has not
decided to sign. The TOE is subject to deliberate attacks by
experts possessing a high attack potential with advanced
knowledge of security principles and concepts employed by the
TOE.
 T.SVD_Forgery Forgery of the signature-verification data
An attacker forges the SVD presented by the CSP to the CGA.
This results in loss of SVD integrity in the
certificate of the signatory.
Organizational Security Policies
Versión 2.1.0 Página 23 de 158
4.3. Organizational Security Policies
The TOE shall comply with the following Organizational Security Policies (OSP) as security rules,
procedures, practices, or guidelines imposed by an organization upon its operations (see CC part
1, sec. 3.2).
4.3.1. OSPs from [MR.ED-PP]
The next OSP addresses the need of a policy for the document manufacturer. It is formulated
akin to [ICPP].
 P.Lim_Block_Loader
The composite manufacturer uses the Loader for loading of Security IC Embedded
Software, data of the Composite Product or IC Dedicated Support Software in charge of
the IC Manufacturer. She limits the capability and blocks the availability of the Loader1
in order to protect stored data from disclosure and manipulation.
4.3.2. OSPs from [MR.ED-ON-PP]
This section includes the following OSPs from [MR.ED-ON-PP].
 P.Code_Confidentiality
Update code packages that are created by the TOE software developer or document
manufacturer are kept confidential, are encrypted after development at the site of the
electronic document manufacturer, and are delivered to the TOE in encrypted form.
 P.Secure_Environment
Update terminals are placed in a secure environment that prevents unauthorized
physical access, and are operated by authorized staff only. Authorized staff oversees the
complete update procedure.
 P.Eligible_Terminals_Only
Update terminals (i.e. terminals with appropriate certificates that are able to install
updates) are handed only to those entities where P.Secure_Environment is enforced. In
case of a security incident, these update terminals are functionally disabled (through
organizational and/or cryptographic means by e.g. withdrawing certificates).
1
Note that blocking the Loader is not required, as only authorized users can use the Loader as stated in
BSI.P.Ctrl-Loader.
OSPs from [EAC2PP]
Versión 2.1.0 Página 24 de 158
4.3.3. OSPs from [EAC2PP]
This section is inspired on OSPs from [EAC2PP].
 P.EAC2_Terminal Abilities of Terminals executing EAC Version 2
Terminals that intent to be EAC2 terminals must implement the
respective terminal part of the protocols required to execute
EAC version 2 according to [TR03110-2], and store (static keys)
or generate (temporary keys and nonces) the corresponding
credentials.
 P.Terminal_PKI PKI for Terminal Authentication
The electronic document issuer shall establish a public key
infrastructure for the card verifiable certificates used for
Terminal Authentication. For this aim, the electronic document
issuer shall run a Company Verifying Certification Authority. The
instances of the PKI shall fulfill the requirements and rules of the
corresponding certificate policy. The electronic document issuer
shall make the CVCA certificate available to the personalization
agent or the manufacturer.
4.3.4. OSPs from [PACEPP]
This section is inspired on OSPs from [PACEPP], since [EAC2PP] claims [PACEPP].
 P.Card_PKI PKI for Passive Authentication (issuing branch)
Application note 4: The description below states the responsibilities of involved parties and
represents the logical, but not the physical structure of the PKI. Physical distribution ways
shall be implemented by the involved parties in such a way that all certificates belonging to
the PKI are securely distributed / made available to their final destination, e.g. by using
directory services.
1) The electronic document Issuer shall establish a public key
infrastructure for the passive authentication, i.e. for digital
signature creation and verification for the electronic document.
For this aim, he runs a Company Signing Certification Authority
(CSCA). The electronic document Issuer shall publish the CSCA
Certificate (CCSCA).
2) The CSCA shall securely generate, store and use the CSCA key
pair. The CSCA shall keep the CSCA Private Key secret and issue
a self-signed CSCA Certificate (CCSCA) having to be made
available to the electronic document Issuer by strictly secure
means, see [ICAO9303], 5.5.1. The CSCA shall create the
Document Signer Certificates for the Document Signer Public
OSPs from [PACEPP]
Versión 2.1.0 Página 25 de 158
Keys (CDS) and make them available to the electronic document
Issuer, see [ICAO9303], 5.5.1.
3) A Document Signer shall (i) generate the Document Signer Key
Pair, (ii) hand over the Document Signer Public Key to the CSCA
for certification, (iii) keep the Document Signer Private Key
secret and (iv) securely use the Document Signer Private Key for
signing the target elementary file data of electronic document.
 P.Manufact Manufacturing of the electronic document’s chip
The Initialization Data are written by the IC Manufacturer to
identify the IC uniquely. The electronic document Manufacturer
writes the Pre-personalisation Data which contains at least the
Personalisation Agent Key.
 P.Pre-Operational Pre-operational handling of the electronic document
1) The electronic document Issuer uses only such TOE’s
technical components (IC) which enable traceability of the
electronic document in their manufacturing and issuing life
cycle phases, i.e. before they are in the operational phase,
cf. sec. 1.4.
2) If the electronic document Issuer authorises a
Personalisation Agent to personalise the electronic
document for electronic documents holders, the electronic
document Issuer has to ensure that the Personalisation
Agent acts in accordance with the electronic document
Issuer’s policy.
 P.Terminal Abilities and trustworthiness of terminals
The terminal with PACE shall operate as follows:
1) They shall implement the terminal parts of the PACE
protocol [ICAO9303], of the Passive Authentication
[ICAO9303] and use them in this order2
. The PACE terminal
shall use randomly and (almost) uniformly selected nonces,
if required by the protocols (for generating ephemeral keys
for Diffie-Hellmann).
2) The related terminals need not to use any own credentials.
3) They shall also store the Company Signing Public Key and
the Document Signer Public Key (in form of CCSCA and CDS)
in order to enable and to perform Passive Authentication
(determination of the authenticity of elementary file data
stored in the electronic document).
2
This order is commensurate with [ICAO9303].
OSPs from [SSCDPP], [SSCDPP3],
[SSCDPP4], [SSCDPP5] and
[SSCDPP6]
Versión 2.1.0 Página 26 de 158
4) The related terminals and their environment shall ensure
confidentiality and integrity of respective data handled by
them (e.g. confidentiality of PACE passwords, integrity of
PKI certificates, etc.), where it is necessary for a secure
operation of the TOE according to the current ST.
 P.Trustworthy_PKI Trustworthiness of PKI
The CSCA shall ensure that it issues its certificates exclusively to
the rightful organisations (DS) and DSs shall ensure that they
sign exclusively correct elementary file data to be stored on the
electronic document.
4.3.5. OSPs from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6]
The current section also includes all OSPs of [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6].
 P.CSP_QCert Qualified certificate
The CSP uses a trustworthy CGA to generate a qualified
certificate or non-qualified certificate (The Directive[DIR]3
: 2:9,
Annex I of [DIR]) for the SVD generated by the SSCD. The
certificates contain at least 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
as SSCD is evident with signatures through the certificate or
other publicly available information.
 P.QSign Qualified electronic signatures
The signatory uses a signature-creation system to sign data with
an advanced electronic signature (The Directive[DIR]: 1, 2),
which is a qualified electronic signature if it is based on a valid
qualified certificate (Annex I of [DIR])4
. The DTBS are presented
to the signatory and sent by the SCA as DTBS/R to the SSCD. The
SSCD creates the digital signature created with a SCD
implemented in the SSCD that the signatory maintain under his
sole control and is linked to the DTBS/R in such a manner that
any subsequent change of the data is detectable.
3
Se mantienen las referencias a [DIR] por respetar los perfiles de protección originales [SSCDPP],
[SSCDPP3], [SSCDPP4], [SSCDPP5] y [SSCDPP6], pero estas referencias se deben entender realizadas a
[eIDAS] toda vez que en el Anexo de la [DE] se referencian los mismos perfiles de protección [SSCDPP],
[SSCDPP3], [SSCDPP4], [SSCDPP5] y [SSCDPP6] para la evaluación de la seguridad de los dispositivos
cualificados de creación de firmas según se indica en los informes de mantenimiento [MR2], [MR3], [MR4],
[MR5] y [MR6].
4
It is a non-qualified advanced electronic signature if it is based on a non-qualified certificate for the SVD.
Assumptions
Versión 2.1.0 Página 27 de 158
 P.Sig_Non-Repud Non-repudiation of signatures
The life cycle of the SSCD, the SCD and the SVD shall be
implemented in a way that the signatory is not able to deny
having signed data if the signature is successfully verified with
the SVD contained in his un-revoked certificate.
 P.Sigy_SSCD TOE as secure signature-creation device
The TOE meets the requirements for an SSCD laid down in Annex
III of [DIR]. This implies the SCD is used for digital signature
creation under sole control of the signatory and the SCD can
practically occur only once.
4.4. Assumptions
The assumptions describe the security aspects of the environment in which the TOE will be
used or is intended to be used. This section includes the assumptions from the claimed
protection profiles as listed below and defines no further assumptions.
4.4.1. Assumptions from [PACEPP]
This section is inspired on assumptions from [PACEPP], since [EAC2PP] claims [PACEPP].
 A.Passive_Auth PKI for Passive Authentication
The issuing and receiving Organisations establish a public key
infrastructure for passive authentication i.e. digital signature
creation and verification for the logical electronic document.
The issuing Organisation runs a Certification Authority (CA)
which securely generates, stores and uses the Company Signing
CA Key pair. The CA keeps the Company Signing CA Private Key
secret. The Document Signer (i) generates the Document Signer
Key Pair, (ii) hands over the Document Signer Public Key to the
CA for certification, (iii) keeps the Document Signer Private Key
secret and (iv) uses securely the Document Signer Private Key
for signing the Chip Authentication Public Key signature of the
electronic document. The CA creates the Document Signer
Certificates for the Document Signer Public Keys that are
distributed to the receiving Organisations. It is assumed that the
Personalisation Agent ensures that the EF-011D (Card Sec.)
contains the hash values of genuine Chip Authentication Public
Key.
Assumptions from [SSCDPP],
[SSCDPP3], [SSCDPP4], [SSCDPP5]
and [SSCDPP6]
Versión 2.1.0 Página 28 de 158
4.4.2. Assumptions from [SSCDPP], [SSCDPP3], [SSCDPP4],
[SSCDPP5] and [SSCDPP6]
The current section includes all assumptions of [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6].
 A.CGA Trustworthy certification-generation application
The CGA protects the authenticity of the signatory’s name or
pseudonym and the SVD in the (qualified) certificate by an advanced
electronic signature of the CSP.
 A.SCA Trustworthy signature-creation application
The signatory uses only a trustworthy SCA. The SCA generates and sends
the DTBS/R of the data the signatory wishes to sign in a form appropriate
for signing by the TOE.
 A.CSP Secure SCD/SVD management by CSP
The CSP uses only a trustworthy SCD/SVD generation device and ensures
that this device can be used by authorised user only. The CSP ensures
that the SCD generated practically occurs only once, that generated SCD
and SVD actually correspond to each other and that SCD cannot be
derived from the SVD. The CSP ensures the confidentiality of the SCD
during generation and export to the TOE, does not use the SCD for
creation of any signature and irreversibly deletes the SCD in the
operational environment after export to the TOE.
5. Security Objectives
This chapter describes the security objectives for the TOE and for the TOE environment. The
security objectives for the TOE environment are separated into security objectives for the
development, and production environment and security objectives for the operational
environment.
5.1. Security Objectives for the TOE
5.1.1. Security Objectives for the TOE from [MR.ED-PP]
This section describes the security objectives for the TOE, addressing the aspects of identified
threats to be countered by the TOE, and organizational security policies to be met by the TOE.
 OT.Non_Interfere No interference of Access Control Mechanisms
The various implemented access control mechanisms must be
consistent. Their implementation must not allow to circumvent
an access control mechanism by exploiting an unintended
Security Objectives for the TOE from
[MR.ED-ON-PP]
Versión 2.1.0 Página 29 de 158
implementational interference of one access control
mechanism with another one.
A loader is a part of the chip operating system that allows to load data, i.e. the file-system/applet
containing SCD, SVD, TSF data etc. into the Flash or EEPROM memory after delivery of the
smartcard to the document manufacturer.
The following objective for the TOE addresses limiting the availability of the loader, and is
formulated akin to [ICPP].
 OT.Cap_Avail_Loader Capability and availability of the Loader
The TSF provides limited capability of the Loader
functionality of the TOE embedded software and
irreversible termination of the Loader in order to
protect SCD and SVD from disclosure and manipulation.
5.1.2. Security Objectives for the TOE from [MR.ED-ON-PP]
This section includes the following additional security objectives for the TOE from [MR.ED-ON-
PP].
 OT.Update_Mechanism TOE Update Mechanism
The TSF provides a mechanism to install code-signed
updates of the TOE software by authorized staff during
operational use.
 OT.Enc_Sign_Update Encrypted-then-signed Update Packages
The TOE only installs update packages that are
encrypted, integrity-protected and signed by the
authority in charge of delivering and installing updates.
 OT.Update_Terminal_Auth Updates only by authenticated Update Terminals
The TOE allows only authenticated update terminals to
upload an update package to the TOE and to initiate the
update procedure. The TOE uses a dedicated
cryptographic method described in [GOA] to
authenticate an update terminal.
 OT.Attack_Detection Detection of Attacks on the TOE using the Update
Mechanism
The TOE has logging capabilities that track installed
updates and failed update attempts. It also limits the
Security Objectives for the TOE from
[PACEPP]
Versión 2.1.0 Página 30 de 158
amount of faulty (signature verification or decryption
fails) update attempts. It allows dedicated terminals to
read out the update logs.
 OT.Key_Secrecy Key Secrecy of Cryptographic Update Keys
The TOE keeps the cryptographic update keys secret,
and is designed such that emissions from the TOE do not
allow to read out or gain full or partial information
about the keys.
5.1.3. Security Objectives for the TOE from [PACEPP]
As we are referencing to [EAC2PP] and it claims [PACEPP]. Therefore the following security
objectives are inspired on security objectives from [PACEPP] as well. We list them only once
here.
 OT.AC_Pers Access Control for Personalisation of logical MRTD
The TOE must ensure that the logical electronic
document elementary file data and the TSF data can be
written by authorized Personalisation Agents only. The
electronic document elementary file data and the TSF
data may be written only during and cannot be changed
after personalisation of the document.
Application note 5: The OT.AC_Pers implies that the data of the LDS files written during
personalisation for electronic document holder can not be changed using write access
after personalisation.
 OT.Data_Authenticity Authenticity of Data
The TOE must ensure authenticity of the SVD and the
TSF-data stored on it by enabling verification of their
authenticity at the terminal-side. The TOE must ensure
authenticity of the SVD and the TSF-data during their
exchange between the TOE and the terminal connected
after the PACE Authentication. It shall happen by
enabling such a verification at the terminal-side (at
receiving by the terminal) and by an active verification
by the TOE itself (at receiving by the TOE)5
.
Application note 6: OT.Data_Authenticity shall be extended to all kinds of PACE
terminals and EAC2 terminals.
5
secure messaging after the PACE authentication, see also [ICAO9303]
Security Objectives for the TOE from
[PACEPP]
Versión 2.1.0 Página 31 de 158
 OT.Data_Confidentiality Confidentiality of Data
The TOE must ensure confidentiality of the SCD and the
TSF-data by granting read access only to the PACE
authenticated terminal connected.The TOE must ensure
confidentiality of the TSF-data during their exchange
between the TOE and the terminal connected (and
represented by PACE authenticated terminals) after the
PACE Authentication.
Application note 7: OT.Data_Confidentiality shall be extended to all kinds of PACE
terminals and EAC2 terminals.
 OT.Data_Integrity Integrity of Data
The TOE must ensure integrity of the SCD, SVD and the
TSF-data stored on it by protecting these data against
unauthorised modification (physical manipulation and
unauthorised modifying). The TOE must ensure integrity
of the SVD and the TSF-data during their exchange
between the TOE and the terminal connected after the
PACE Authentication.
Application note 8: OT.Data_Integrity is extended here to all kinds of PACE terminals and
EAC2 terminals. Justification: Obviously, data integrity must be ensured w.r.t. all
possible terminal types.
 OT.Identification Identification of the TOE
The TOE must provide means to store Initialisation6
and
Pre-Personalisation Data in its non-volatile memory.
The Initialisation Data must provide a unique
identification of the IC during the manufacturing and
the card issuing life cycle phases of the electronic
document. The storage of the Pre-Personalisation data
includes writing of the Personalisation Agent Key(s).
Note that careful analysis reveals that OT.AC_Pers, OT.Data_Authenticity,
OT.Data_Confidentiality, OT.Data_Integrity, and OT.Identification are actually fully or partly
covered by security objectives included from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5] and
[SSCDPP6].
6
amongst other, IC Identification data
Security objectives for the TOE from
[SSCDPP], [SSCDPP3], [SSCDPP4],
[SSCDPP5] and [SSCDPP6]
Versión 2.1.0 Página 32 de 158
5.1.4. Security objectives for the TOE from [SSCDPP], [SSCDPP3],
[SSCDPP4], [SSCDPP5] and [SSCDPP6]
The current section includes all security objectives for the TOE of [SSCDPP], [SSCDPP3],
[SSCDPP4], [SSCDPP5] and [SSCDPP6].
 OT.DTBS_Integrity_TOE DTBS/R integrity inside the TOE
The TOE must not alter the DTBS/R. As by definition of
the DTBS/R this may consist of the DTBS themselves,
this objective does not conflict with a signature creation
process where the TOE hashes the provided DTBS (in
part or entirely) for signature creation..
 OT.EMSEC_Design Provide physical-emanation security
Design and build the TOE in such a way as to control the
production of intelligible emanations within specified
limits.
 OT.Lifecycle_Security Lifecycle security
The TOE shall detect flaws during the initialisation,
personalisation and operational usage. The TOE shall
provide functionality to securely destroy the SCD on
demand of the signatory.
Application note 9: The TOE may contain more than one set of SCD. There is no need to
destroy the SCD in case of repeated SCD generation. The signatory shall be able to
destroy the SCD stored in the SSCD e.g. after the (qualified) certificate for the
corresponding SVD has been expired.
 OT.SCD_Secrecy Secrecy of the signature-creation data
The secrecy of an SCD (used for signature creation) shall
be reasonably assured against attacks with a high attack
potential.
Application note 10: The TOE shall keep the confidentiality of the SCD at all times in
particular during SCD/SVD generation, SCD signing operation, storage and by
destruction.
 OT.SCD_SVD_Corresp Correspondence between SVD and SCD
The TOE shall ensure the correspondence between the
SVD and the SCD generated by the TOE. This includes
unambiguous reference of a created SVD/SCD pair for
export of the SVD and in creating a digital signature
creation with the SCD.
Security objectives for the TOE from
[SSCDPP], [SSCDPP3], [SSCDPP4],
[SSCDPP5] and [SSCDPP6]
Versión 2.1.0 Página 33 de 158
 OT.SCD_Unique Uniqueness of the signature-creation data
The TOE shall ensure the cryptographic quality of an
SCD/SVD pair it creates as suitable for the advanced or
qualified electronic signature. The SCD used for
signature creation 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.
 OT.SCD/SVD_Auth_Gen SCD/SVD authorized generation
The TOE provides security features to ensure that
authorised users only invoke the generation of the SCD
and the SVD.
 OT.Sig_Secure Cryptographic security of the electronic signature
The TOE shall create digital signatures that cannot be
forged without knowledge of the SCD through robust
encryption techniques. The SCD shall not be
reconstructable using the digital signatures or any other
data exportable from the TOE. The digital signatures
shall be resistant against these attacks, even when
executed with a high attack potential.
 OT.Sigy_SigF Signature creation function for the legitimate
signatory only
The TOE provides the digital signature creation function
for the legitimate signatory only and protects the SCD
against the use of others to create a digital signature.
The TOE shall resist attacks with high attack potential.
 OT.Tamper_ID Tamper detection
The TOE shall provide system features that detect
physical tampering of its components, and uses those
features to limit security breaches.
 OT.Tamper_Resistance Tamper resistance
The TOE prevents or resists physical tampering with
specified system devices and components.
 OT.TOE_TC_VAD_Imp Trusted channel of TOE for VAD import
The TOE shall provide a trusted channel for the
protection of the confidentiality and integrity of the
Security Objectives for the Operational
Environment
Versión 2.1.0 Página 34 de 158
VAD received from the HID as needed by the
authentication method employed.
Application note 11: This security objective for the TOE is partly covering OE.HID_VAD
from [SSCDPP]. While OE.HID_VAD in [SSCDPP] requires only the operational
environment to protect VAD, [SSCDPP5] requires the HID and the TOE to implement a
trusted channel for the protection of the VAD: the HID exports the VAD and establishes
one end of the trusted channel according to OE.HID_TC_VAD_Exp, the TOE imports VAD
at the other end of the trusted channel according to OT.TOE_TC_VAD_Imp. Therefore
[SSCDPP5] re-assigns partly the VAD protection from the operational environment as
described by OE.HID_VAD to the TOE as described by OT.TOE_TC_VAD_Imp and leaves
only the necessary functionality by the HID.
 OT.TOE_TC_DTBS_Imp Trusted channel of TOE for DTBS import
The TOE shall provide a trusted channel to the SCA to
detect alteration of the DTBS/R received from the SCA.
The TOE must not generate electronic signatures with
the SCD for altered DTBS.
 OT.TOE_SSCD_Auth Authentication proof as SSCD
The TOE shall hold unique identity and authentication
data as SSCD and provide security mechanisms to
identify and to authenticate itself as SSCD.
 OT.TOE_TC_SVD_Exp TOE trusted channel for SVD export
The TOE shall provide a trusted channel to the CGA to
protect the integrity of the SVD exported to the CGA.
The TOE shall enable the CGA to detect alteration of the
SVD exported by the TOE.
 OT.SCD_Auth_Imp Authorized SCD import
The TOE shall provide security features to ensure that
authorised users only may invoke the import of the SCD.
5.2. Security Objectives for the Operational Environment
5.2.1. Security objectives from [MR.ED-PP]
The following objective on the environment is defined akin to the objective from [ICPP].
 OE.Lim_Block_Loader Limitation of capability and blocking the Loader
Security objectives from [MR.ED-ON-
PP]
Versión 2.1.0 Página 35 de 158
The manufacturer will protect the Loader functionality
against misuse, limit the capability of the Loader and
terminate irreversibly7
the Loader after intended usage
of the Loader.
Justification: This security objective directly addresses the threat T.Non_Interfere. This threat
concerns the potential interference of different access control mechanisms, which could occur
as a result of combining different applications on a smartcard. Such combination does not occur
in one of the claimed PPs. Hence, this security objective for the environment does
- neither mitigate a threat of one of the claimed PPs that was addressed by security
objectives of that PP,
- nor does it fulfill any organizational security policy of one of the claimed PPs that was
meant to be addressed by security objectives of the TOE of that PP.
5.2.2. Security objectives from [MR.ED-ON-PP]
 OE.Code_Confidentiality
The operational environment must ensure that the TOE
software developer or document manufacturer keeps
update code packages confidential, encrypts them after
development at the site of the
developer/manufacturer, and delivers them to the TOE
in encrypted form.
 OE.Secure_Environment
The operational environment must ensure that update
terminals are placed in a secure environment that
prevents unauthorized physical access, and are
operated by authorized staff only. The operational
environment must also ensure through e.g.
organizational policies and procedures, that authorized
staff oversees the complete update procedure.
 OE.Eligible_Terminals_Only
The operational environment must also ensure by e.g.
organizational procedures, supported by cryptographic
means, that only those entities that have policies in
place that guarantee OE.Secure_Environment, are
supplied with update terminals. Moreover the
7
Note that blocking the Loader is not required, as only authorized users can use the Loader as stated in
BSI.P.Ctrl-Loader.
Security Objectives from [EAC2PP]
Versión 2.1.0 Página 36 de 158
operational environment guarantees that update
terminals can be functionally deactivated if these
policies are no longer in place or not enforced at the
entities. This can be implemented for example by the
issuance of certificates for update terminals together
with a public key infrastructure.
Justification: Each of these security objectives on the environment directly addresses
one of the organizational security policies P.Code_Confidentiality,
P.Secure_Environment, and P.Eligible_Terminals_Only. Hence, these security objectives
for the environment do
 neither mitigate a threat of the [MR.ED-PP] that was addressed by security objectives of
the [MR.ED-PP],
 nor do they fulfill any organizational security policy of the [MR.ED-PP] that was meant
to be addressed by security objectives of the TOE of the [MR.ED-PP].
Note in particular that OE.Eligible_Terminals_Only requires a general issuance and
revocation mechanism for update terminals and leaves the specific implementation
open, whereas OE.Terminal_Authentication of the [MR.ED-PP] specifically addresses
certificates for EAC2 terminals.
5.2.3. Security Objectives from [EAC2PP]
This section is inspired in the security objectives for the Operational Environment from the
[EAC2PP].
 OE.Chip_Auth_Key Key Pair needed for Chip Authentication
The electronic document issuer has to ensure that the
electronic document’s chip authentication key pair is
generated securely, that the private keys of this key pair
is stored correctly in the electronic document's chip,
and that the corresponding public keys are distributed
to the EAC2 terminals that are used according to
[TR03110-2] to check the authenticity of the electronic
document's chip.
 OE.Terminal_Authentication Key pairs needed for Terminal Authentication
The electronic document issuer shall establish a public
key infrastructure for the card verifiable certificates
used for Terminal Authentication. For this aim, the
electronic document issuer shall run a Company
Verifying Certification Authority. The instances of the
Security Objectives from [PACEPP]
Versión 2.1.0 Página 37 de 158
PKI shall fulfill the requirements and rules of the
corresponding certificate policy. The electronic
document issuer shall make the CVCA certificate
available to the personalization agent or the
manufacturer.
5.2.4. Security Objectives from [PACEPP]
As we are referencing to [EAC2PP] and it claims [PACEPP]. Therefore the following security
objectives for the operational environment are inspired on security objectives from [PACEPP] as
well.
Electronic document Issuer and CSCA: electronic’s document PKI (issuing) branch
The electronic document Issuer and the related CSCA will implement the following security
objectives for the TOE environment (see also the Application note 15 above):
 OE.Passive_Auth_Sign Authentication of electronic document by Signature
The electronic document Issuer has to establish the
necessary public key infrastructure as follows: the CSCA
acting on behalf and according to the policy of the
electronic document Issuer must (i) generate a
cryptographically secure CSCA Key Pair, (ii) ensure the
secrecy of the CSCA Private Key and sign Document
Signer Certificates in a secure operational environment,
and (iii) publish the Certificate of the CSCA Public Key
(CCSCA). Hereby authenticity and integrity of these
certificates are being maintained. A Document Signer
acting in accordance with the CSCA policy must (i)
generate a cryptographically secure Document Signing
Key Pair, (ii) ensure the secrecy of the Document Signer
Private Key, (iii) hand over the Document Signer Public
Key to the CSCA for certification, (iv) sign Chip
Authentication Public Key of genuine electronic
document in a secure operational environment only.
The Personalisation Agent has to ensure that the Chip
Authentication Public Key signature contains only the
hash values of genuine key. The CSCA must issue its
certificates exclusively to the rightful organisations (DS)
and DSs must sign exclusively correct Chip
Authentication Public Key signatures to be stored on the
electronic document.
 OE.Personalisation Personalisation of electronic document
Security Objectives from [PACEPP]
Versión 2.1.0 Página 38 de 158
The electronic document Issuer must ensure that the
Personalisation Agents acting on his behalf (i) may
establish the correct identity of the electronic
document holder and create the biographical data for
the electronic document, (ii) may enrol the biometric
reference data of the electronic document holder, (iii)
may write a subset of these data on the physical card
(optical personalisation) and store them in the
electronic document (electronic personalisation) for the
electronic document holder, (iv) write the initial TSF
data.
Terminal operator: Terminal’s receiving branch
 OE.Terminal Terminal operating
The terminal operators must operate their terminals as follows:
1) The related terminals implement the terminal parts of the
PACE protocol [ICAO9303], of the Passive Authentication
[ICAO9303] (by verification of the signature of the Chip
Authenticate public key) and use them in this order8
. The
PACE terminal uses randomly and (almost) uniformly
selected nonces, if required by the protocols (for generating
ephemeral keys for Diffie-Hellmann).
2) The related terminals need not to use any own credentials.
3) The related terminals securely store the Company Signing
Public Key and the Document Signer Public Key (in form of
CCSCA and CDS) in order to enable and to perform Passive
Authentication of the electronic document (determination
of the authenticity of Chip Authenticate public key).
4) The related terminals and their environment must ensure
confidentiality and integrity of respective data handled by
them (e.g. confidentiality of the PACE passwords, integrity
of PKI certificates, etc.), where it is necessary for a secure
operation of the TOE according to the current ST.
Application note 12: Opposite to OE.Terminal from this ST, a terminal supporting EAC2
according to [TR03110-2] needs to store its own credentials for Extended Access Control.
8
This order is commensurate with [ICAO9303].
Security Objectives from [SSCDPP],
[SCCDPP3], [SSCDPP4], [SSCDPP5]
Y [SSCDPP6]
Versión 2.1.0 Página 39 de 158
5.2.5. Security Objectives from [SSCDPP], [SCCDPP3], [SSCDPP4],
[SSCDPP5] Y [SSCDPP6]
This section includes all security objectives for the TOE of [SSCDPP], [SSCDPP3], [SSCDPP4],
[SSCDPP5] y [SSCDPP6].
 OE.CGA_QCert Generation of qualified certificates
The CGA shall generate a qualified certificate that
includes (amongst others)
- the name of the signatory controlling the TOE,
- the SVD matching the SCD stored in the TOE and
being under sole control of the signatory,
- the advanced signature of the CSP.
The CGA shall confirm with the generated qualified
certificate that the SCD corresponding to the SVD is
stored in a SSCD.
 OE.DTBS_Intend SCA sends data intended to be signed
The Signatory uses trustworthy SCA that
- generates the DTBS/R 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,
- sends the DTBS/R to the TOE and enables
verification of the integrity of the DTBS/R by the
TOE,
- attaches the signature produced by the TOE to
the data or provides it separately.
- Application note 13: The SCA should be able to
support advanced electronic signatures.
Currently, there exist three formats defined by
ETSI recognized as meeting the requirements
needed by advanced electronic signatures:
CAdES, XAdES and PAdES. These three formats
mandate to include the hash of the signer's
public key certificate in the data to be signed. In
order to support for the mobility of the signer, it
is recommended to store the certificate info on
the SSCD for use by SCA and identification of the
corresponding SCD if more than one SCD is
stored on the SSCD.
-
Security Objectives from [SSCDPP],
[SCCDPP3], [SSCDPP4], [SSCDPP5]
Y [SSCDPP6]
Versión 2.1.0 Página 40 de 158
 OE.SCA_TC_DTBS_Exp9
Trusted channel of SCA for DTBS export.
The SCA provides a trusted channel to the TOE for the
protection of the integrity of the DTBS to ensure that the
DTBS/R cannot be altered undetected in transit
between the SCA and the TOE.
 OE.HID_TC_VAD_Exp10
Trusted channel of HID for VAD export.
The HID provides the human interface for user
authentication. The HID will ensure confidentiality and
integrity of the VAD as needed by the authentication
method employed including export to the TOE by means
of a trusted channel.
 OE.Signatory Security obligation of the Signatory
The signatory shall check that the SCD stored in the
SSCD received from SSCD-provisioning service is in non-
operational state. The signatory shall keep their VAD
confidential.
 OE.SVD_Auth Authenticity of the SVD
The operational environment shall ensure the integrity
of the SVD sent to the CGA of the CSP. The CGA verifies
the correspondence between the SCD in the SSCD of the
signatory and the SVD in the qualified certificate.
 OE.Dev_Prov_Service Authentic SSCD provided by SSCD Provisioning Service
The SSCD Provisioning Service handles authentic devices
that implement the TOE, prepares the TOE for proof as
SSCD to external entities, personalises the TOE for the
legitimate user as signatory, links the identity of the TOE
as SSCD with the identity of the legitimate user, and
delivers the TOE to the signatory.
Note: This objective replaces OE.SSCD_Prov_Service from the [SSCDPP], which is
possible as it does not imply any additional requirements for the operational
environment when compared to OE.SSCD_Prov_Service (OE.Dev_Prov_Service is a
subset of OE.SSCD_Prov_Service).
 OE.CGA_SSCD_Auth Pre-initialisation of the TOE for SSCD authentication
9
Dado que el TOE incluye la funcionalidad del canal seguro, este OE es el resultado de adaptar el
OE.DTBS_Protect de [SSCDPP] tal y como se indica en [SSCDPP5].
10
Dado que el TOE incluye la funcionalidad del canal seguro, este OE es el resultado de adaptar el
OE.HI_VAD de [SSCDPP] tal y como se indica en [SSCDPP5].
Security Objectives from [SSCDPP],
[SCCDPP3], [SSCDPP4], [SSCDPP5]
Y [SSCDPP6]
Versión 2.1.0 Página 41 de 158
The CSP shall check by means of the CGA whether the
device presented for application of a (qualified)
certificate holds unique identification as SSCD,
successfully proved this identity as SSCD to the CGA, and
whether this identity is linked to the legitimate holder
of the device as applicant for the certificate.
 OE.CGA_TC_SVD_Imp CGA trusted channel for SVD import
The CGA shall detect alteration of the SVD imported
from the TOE with the claimed identity of the SSCD.
The developer prepares the TOE by pre-initialisation for the delivery to the customer (i.e.
the SSCD provisioning service) in the development phase not addressed by a security
objective for the operational environment. The SSCD Provisioning Service performs
initialisation and personalisation as TOE for the legitimate user (i.e. the Device holder). If
the TOE is delivered to the Device holder with SCD the TOE is a SSCD. This situation is
addressed by OE.SSCD_Prov_Service except the additional initialisation of the TOE for
proof as SSCD and trusted channel to the CGA. If the TOE is delivered to the Device holder
without a SCD the TOE will be a SSCD only after generation of the first SCD/SVD pair.
Because this SCD/SVD pair generation is performed by the signatory in the operational
use stage the TOE provides additional security functionality addressed by
OT.TOE_SSCD_Auth and OT.TOE_TC_SVD_Exp. But this security functionality must be
initialised by the SSCD Provisioning Service as described in OE.Dev_Prov_Service.
Therefore this ST substitutes OE.SSCD_Prov_Service by OE.Dev_Prov_Service allowing
generation of the first SCD/SVD pair after delivery of the TOE to the Device holder and
requiring initialisation of security functionality of the TOE. Nevertheless the additional
security functionality must be used by the operational environment as described in
OE.CGA_SSCD_Auth and OE.CGA_TC_SVD_Imp. This approach does not weaken the
security objectives of and requirements to the TOE but enforce more security
functionality of the TOE for additional method of use. Therefore it does not conflict with
the CC conformance claim to the [SSCDPP2].
 OE.SCD/SVD_Auth_Gen Authorized SCD/SVD generation
The CSP shall provide security features to ensure that
authorised users only may invoke the generation of the
SCD and the SVD.
 OE.SCD_Secrecy SCD Secrecy
The CSP shall protect the confidentiality of the SCD
during generation and export to the TOE. The CSP shall
not use the SCD for creation of any signature and shall
Security Objective Rationale
Versión 2.1.0 Página 42 de 158
irreversibly delete the SCD in the operational
environment after export to the TOE.
 OE.SCD_Unique Uniqueness of the signature creation data
The CSP shall ensure the cryptographic quality of the
SCD/SVD pair, which is generated in the environment,
for the qualified or advanced electronic signature. The
SCD used for signature creation shall practically occur
only once, i.e. the probability of equal SCDs shall be
negligible, and the SCD shall not be reconstructable
from the SVD.
 OE.SCD_SVD_Corresp Correspondence between SVD and SCD
The CSP shall ensure the correspondence between the
SVD and the SCD generated by the CSP. This includes the
correspondence between the SVD send to the CGA and
the SCD exported to the TOE of the signatory identified
in the SVD certificate.
5.3. Security Objective Rationale
Tabla 1 provides an overview of the security objectives' coverage. According to CC part 1 [CC],
the tracing between security objectives and the security problem definition must ensure that 1)
each security objective traces to at least one threat, OSP and assumption, 2) each threat, OSP
and assumption has at least one security objective tracing to it, and 3) the tracing is correct (i.e.
the main point being that security objectives for the TOE do not trace back to assumptions).
This is illustrated in the following way:
1) can be inferred for security objectives from claimed PPs by looking up the security
objective rationale of the claimed PPs and for newly introduced security objectives (i.e.
OE.Lim_Block_Loader and OT.Cap_Avail_Loader) by checking the columns of Tabla 1,
2) can be inferred for threats, OSPs and assumptions from the claimed PPs by looking up
the security objective rationale of the claimed PPs and for newly introduced threats,
OSPs and assumptions by checking the rows of Tabla 1, and
3) simply by checking the columns of Tabla 1 and the security objective rationales from the
claimed PPs.
Security Objective Rationale
Versión 2.1.0 Página 43 de 158
Tabla 1.- Security Objective Rationale
The threat T.InconsistentSec addresses attacks on the confidentiality and the integrity of user
data stored on the TOE, facilitated by the data not being protected as intended.
OT.AC_Pers define the restriction on writing or modifying data;
OT.Data_Authenticity, OT.Data_Confidentiality and OT.Data_Integrity require the security of
stored user data as well as user data transferred between the TOE and a terminal to be secure
w.r.t. authenticity, integrity and confidentiality.
OT.Non_Interfere requires the TOE's access control mechanisms to be implemented
consistently and their implementations not to allow to circumvent an access control mechanism
by exploiting an unintended implementational interference of one access control mechanism
with another one.
OT.Cap_Avail_Loader requires the TOE to provide limited capability of the loader functionality
and irreversible termination of the loader in order to protect stored user data.
OE.Lim_Block_Loader requires the manufacturer to protect the loader functionality against
misuse, limit the capability of the loader, and terminate irreversibly the loader after intended
usage of the loader.
The combination of these security objectives cover the threat posed by T.InconsistentSec.
Security Objective Rationale
Versión 2.1.0 Página 44 de 158
The threat T.Interfere addresses the attack on SCD and SVD by exploiting the unintended
interference of security protocols. This is directly countered by OT.Non_Interfere, requiring the
TOE's access control mechanisms to be implemented consistently, and their implementations to
not allow to circumvent an access control mechanism by exploiting an unintended
implementational interference of one access control mechanism with another one.
The threat T.FaTSF addresses attacks on the TOE and TSF by an attacker exploiting flaws of the
TOE software implementation that manifest themselves after the TOE enters the phase
operational usage. This threat is countered by the TOE offering a secure update mechanism; in
particular:
- The security objective OT.Update_Mechanism counters this threat by ensuring that the
TOE has the ability to update the TOE software in a secure manner.
- The security objective OT.Attack_Detection ensures that the TOE is able to detect
multiple failed update attempts and can take action upon that detection.
- The security objective OT.Key_Secrecy makes sure that the required cryptographic key
material for the update mechanism cannot be accessed or reconstructed by a malicious
attacker.
The threat T.UaU addresses attacks on the TOE and TSF by an attacker installing unauthorized
and potential harmful updates:
- The security objective OT.Enc_Sign_Update ensures that only signed and encrypted
updates are installed by the TOE, and that during the transmission to the TOE, a protocol
based on encrypt-then-MAC is used.
- The security objective OT.Update_Terminal_Auth ensures that only authenticated
update terminals are able to update version information, upload update packages on
the TOE, and initiate the update procedure.
The OSP P.EAC2_Terminal addresses the requirement for EAC2 terminals to implement the
terminal parts of the protocols needed to executed EAC2 according to its specification in
[TR03110-2], and to store (static keys) or generate (temporary keys and nonces) the needed
related credentials. This is enforced by OE.Chip_Auth_Key which requires Chip Authentication
keys to be correctly generated and stored, by OE.Terminal_Authentication for the PKI needed
for Terminal Authentication, and by OE.Terminal which covers the PACE protocol and the Passive
Authentication protocol.
The OSP P.Terminal_PKI is enforced by establishing the receiving PKI branch as aimed by the
objective OE.Terminal_Authentication.
The OSP P.Card_PKI is enforced by establishing the issuing PKI branch as aimed by the objectives
OE.Passive_Auth_Sign.
The OSP P.Manufact “Manufacturing of the electornic document’s chip” requires a unique
identification of the IC by means of the Initialization Data and the writing of the Pre-
personalisation Data as being fulfilled by OT.Identification.
Security Objective Rationale
Versión 2.1.0 Página 45 de 158
The OSP P.Pre-Operational is enforced by the following security objectives: OT.Identification is
affine to the OSP’s property ‘traceability before the operational phase’; OT.AC_Pers and
OE.Personalisation together enforce the OSP’s property ‘authorisation of Personalisation
Agents’.
The OSP P.Terminal is obviously enforced by the objective OE.Terminal, whereby the one-to-
one mapping between the related properties is applicable.
The OSP P.Trustworthy_PKI is enforced by OE.Passive_Auth_Sign (for CSCA, issuing PKI branch).
The OSP P.Lim_Block_Loader addresses limiting the capability and blocking the availability of
the Loader in order to protect stored data from disclosure and manipulation. This is addressed
by OT.Cap_Avail_Loader, which requires the TOE to provide a limited capability of the loader
functionality and irreversible termination of the loader in order to protect stored SCD and SVD;
by OT.Non_Interfere, which requires the TOE's access control mechanisms to be implemented
consistently and their implementations not to allow to circumvent an access control mechanism
by exploiting an unintended implementational interference of one access control mechanism
with another one; and by OE.Lim_Block_Loader, which requires the manufacturer to protect the
Loader functionality against misuse, limit the capability of the Loader and terminate irreversibly
the Loader after intended usage of the Loader.
The organizational security policies P.Code_Confidentiality, P.Secure_Environment, and
P.Eligible_Terminals_Only, address the confidentiality of the code, the way the update
procedure must be carried out, and precise control over which terminals are allowed to carry
out the update procedure. Each of these policies are enforced through security objectives for
the environment of the TOE, namely OE.Code_Confidentiality, OE.Secure_Environment, and
OE.Eligible_Terminals_Only.
The Assumption A.Passive_Auth “PKI for Passive Authentication” is directly addressed by
OE.Passive_Auth_Sign requiring the electronic document issuer to establish a PKI for Passive
Authentication, generating Document Signing private keys only for rightful organisations and
requiring the Document Signer to sign exclusively correct Chip Authenticate public key to be
stored on electronic document.
Extended Components Definition
Versión 2.1.0 Página 46 de 158
6. Extended Components Definition
This section includes all extended components.
6.1. Extended Components Definition from claimed PPs
This section includes all extended components from the claimed PPs.
- FPT_EMS.1 from the family FPT_EMS from [SSCDPP], [SSCDPP3], [SSCDPP4], [SSCDPP5]
y [SSCDPP6]
The family FPT_EMS (TOE Emanation) of the class FPT (Protection of the TSF) is defined
here to describe the IT security functional requirements of the TOE. The TOE shall
prevent attacks against secret data stored in and used by the TOE where the attack is
based on external observable physical phenomena of the TOE. Examples of such attacks
are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA),
differential power analysis (DPA), timing attacks, etc. This family describes the functional
requirements for the limitation of intelligible emanations being not directly addressed
by any other component of CC part 2 [CC].
The family ‘TOE Emanation (FPT_EMS)’ is specified as follows:
FPT_EMS TOE emanation
Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component levelling:
FPT_EMS.1 TOE emanation has two constituents:
FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling
access to TSF data or user data.
FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation enabling
access to TSF data or user data.
Management: FPT_EMS.1
There are no management activities foreseen.
Audit: FPT_EMS.1
There are no actions defined to be auditable.
FPT_EMS.1 TOE Emanation
FPT_EMS TOE emanation
numbePT_EMS TOE Emanation
1
Propiterary Extended Components
Definition
Versión 2.1.0 Página 47 de 158
Hierarchical to: No other components
Dependencies: No dependencies
FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to [assignment: list of
types of TSF data] and [assignment: list of types of user data].
FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use the
following interface [assignment: type of connection] to gain access to
[assignment: list of types of TSF data] and [assignment: list of types of
user data].
6.2. Propiterary Extended Components Definition
This section include all proprietary extended components from non claimed PPs.
- FAU_SAS.1 from the family FAU_SAS
To describe the security functional requirements of the TOE, the family FAU_SAS of the
class FAU (Security audit) is defined here. This family describes the functional
requirements for the storage of audit data. It has a more general approach than
FAU_GEN, because it does not necessarily require the data to be generated by the TOE
itself and because it does not give specific details of the content of the audit records.
The family ‘Audit data storage (FAU_SAS)’ is specified as follows:
FAU_SAS Audit data storage
Family behaviour
This family defines functional requirements for the storage of audit data.
Component levelling
FAU_SAS.1 Requires the TOE to provide the possibility to store audit data.
Management: FAU_SAS.1
There are no management activities foreseen.
Audit: FAU_SAS.1
There are no actions defined to be auditable.
FAU_SAS Audit data storage
PT_EMS TOE Emanation
1
Propiterary Extended Components
Definition
Versión 2.1.0 Página 48 de 158
FAU_SAS.1 Audit storage
Hierarchical to: No other components
Dependencies: No dependencies
FAU_SAS.1.1 The TSF shall provide [assignment: authorised users] with the
capability to store [assignment: list of audit information] in the
audit records.
- FCS_RND.1 from the family FCS_RND
To describe the IT security functional requirements of the TOE, the family FCS_RND of
the class FCS (Cryptographic support) is defined here. This family describes the
functional requirements for random number generation used for cryptographic
purposes. The component FCS_RND.1 is not limited to generation of cryptographic keys
unlike the component FCS_CKM.1. The similar component FIA_SOS.2 is intended for
non-cryptographic use.
The family ‘Generation of random numbers (FCS_RND)’ is specified as follows:
FCS_RND Generation of random numbers
Family behaviour
This family defines quality requirements for the generation of random numbers
intended to be used for cryptographic purposes.
Component levelling:
FCS_RND.1 Generation of random numbers requires that random numbers
meet a defined quality metric.
Management: FCS_RND.1
There are no management activities foreseen.
Audit: FCS_RND.1
There are no actions defined to be auditable.
FCS_RND.1 Quality metric for random numbers
Hierarchical to: No other components
FCS_RND Generation of random
numbers PT_EMS TOE Emanation
1
Propiterary Extended Components
Definition
Versión 2.1.0 Página 49 de 158
Dependencies: No dependencies
FCS_RND.1.1 The TSF shall provide a mechanism to generate random
numbers that meet [assignment: a defined quality metric].
- FMT_LIM.1 and FMT_LIM.2 from the family FMT_LIM
The family FMT_LIM describes the functional requirements for the test features of the
TOE. The new functional requirements were defined in the class FMT because this class
addresses the management of functions of the TSF. The examples of the technical
mechanism used in the TOE show that no other class is appropriate to address the
specific issues of preventing abuse of functions by limiting the capabilities of the
functions and by limiting their availability.
The family ‘Limited capabilities and availability (FMT_LIM)’ is specified as follows:
FMT_LIM Limited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of
functions in a combined manner. Note, that FDP_ACF restricts access to
functions whereas the Limited capability of this family requires the functions
themselves to be designed in a specific manner.
Component levelling:
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only
the capabilities (perform action, gather information) necessary
for its genuine purpose.
FMT_LIM.2 Limited availability requires that the TSF restrict the use of
functions (refer to Limited capabilities (FMT_LIM.1)). This can be
achieved, for instance, by removing or by disabling functions in
a specific phase of the TOE’s life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
Audit: FMT_LIM.1, FMT_LIM.2
There are no actions defined to be auditable.
FMT_LIM Limited capabilities and availability
numbers PT_EMS TOE Emanation
1
2
Propiterary Extended Components
Definition
Versión 2.1.0 Página 50 de 158
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components
Dependencies: FMT_LIM.2 Limited availability
FMT_LIM.1.1 The TSF shall be designed in a manner that limits their
capabilities so that in conjunction with ‘Limited availability
(FMT_LIM.2)’ the following policy is enforced [assignment:
Limited capability and availability policy].
FMT_LIM.2 Limited availability
Hierarchical to: No other components
Dependencies: FMT_LIM.1 Limited capabilities
FMT_LIM.2.1 The TSF shall be designed in a manner that limits their
availability so that in conjunction with ‘Limited capabilities
(FMT_LIM.1)’ the following policy is enforced [assignment:
Limited capability and availability policy].
Application note 14: The functional requirements FMT_LIM.1 and FMT_LIM.2 assume
existence of two types of mechanisms (limited capabilities and limited availability) which
together shall provide protection in order to enforce the related policy. This also allows
that
i. the TSF is provided without restrictions in the product in its user environment,
but its capabilities are so limited that the policy is enforced
or conversely
ii. (ii)the TSF is designed with high functionality, but is removed or disabled in the
product in its user environment.
The combination of both the requirements shall enforce the related policy.
- FIA_API.1 from the family FIA_API
To describe the IT security functional requirements of the TOE, the family FIA_API of the
class FIA (Identification and authentication) is defined here. This family describes the
functional requirements for proof of the claimed identity for the authentication
Propiterary Extended Components
Definition
Versión 2.1.0 Página 51 de 158
verification by an external entity, where the other families of the class FIA address the
verification of the identity of an external entity.
Application note 15: Other families of the class FIA describe only the authentication
verification of the user’s identity performed by the TOE and do not describe the
functionality of the TOE to prove its own identity. The following paragraph defines the
family FIA_API in the style of Common Criteria part 2 (cf. CC part 3 [CC], chapter
‘Extended components definition (APE_ECD)’) from a TOE point of view.
FIA_API Authentication Proof of Identity
Family behaviour
This family defines functions provided by the TOE to prove its identity and to be
verified by an external entity in the TOE IT environment.
Component levelling:
FIA_API.1 Authentication Proof of Identity.
Management FIA_API.1
The following actions could be considered for the management
functions in FMT: Management of authentication information used
to prove the claimed identity.
Audit: FIA_API.1
There are no actions defined to be auditable.
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components
Dependencies: No dependencies
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to
prove the identity of the [assignment: authorised user or role, or of the
TOE itself].
FIA_API Authentication Proof of Identity
PT_EMS TOE Emanation
1
Security Requirements
Versión 2.1.0 Página 52 de 158
7. Security Requirements
This part defines detailed security requirements that shall be satisfied by the TOE. The statement
of TOE security requirements shall define the functional and assurance security requirements
that the TOE must satisfy in order to meet the security objectives for the TOE.
Common Criteria allows several operations to be performed on security requirements on the
component level: refinement, selection, assignment and iteration, cf. sec. 8.1 of CC part 1 [CC].
Each of these operations is used in this ST.
The refinement operation is used to add detail to a requirement, and thus further restricts a
requirement. Refinements of security requirements made by the PP author are denoted in such
a way that added words are in bold text and removed are crossed out. Refinements made by
the ST author appear italicized, bold and underlined and crossed out if text is removed.
The selection operation is used to select one or more options provided by the CC in stating a
requirement. Selections having been made by the PP author are denoted as underlined text.
Selections made by the ST author appear italicized and underlined.
The assignment operation is used to assign a specific value to an unspecified parameter, such
as the length of a password. Assignments having been made by the PP author are denoted by
showing as underlined text. Assignments made by the ST author appear italicized and
underlined.
The iteration operation is used when a component is repeated with varying operations. Iteration
is denoted by showing a slash “/”, and the iteration indicator after the component identifier. For
the sake of better readability, the iteration operation may also be applied to a non-repeated
single component in order to indicate that such component belongs to a certain functional
cluster. In such a case, the iteration operation is applied to only one single component.
In order to distinguish between SFRs defined here and SFRs that are taken over from PPs to
which this ST claims strict conformance, the latter are iterated resp. renamed in the following
way:
/SSCDPP or /XXX_SSCDPP for [SSCDPP],
/SSCDPP3 or /XXX_SSCDPP3 for [SSCDPP3],
/SSCDPP4 or /XXX_SSCDPP4 for [SSCDPP4],
/SSCDPP5 or /XXX_SSCDPP5 for [SSCDPP5]
and /SSCDPP6 or /XXX_SSCDPP6 for [SSCDPP6].
The definition of the subjects “Manufacturer”, “Personalisation Agent”, “Extended Inspection
System”, “ Company Verifying Certification Authority”, “Document Verifier” and “Terminal”
used in the following chapter is given in section 3.1. Note, that all these subjects are acting for
Security Requirements
Versión 2.1.0 Página 53 de 158
homonymous external entities. All used objects are defined either in section 7 or in the following
table. The operations “write”, “modify”, “read” and “disable read access” are used in accordance
with the general linguistic usage. The operations “store”, “create”, “transmit”, “receive”,
“establish communication channel”, “authenticate” and “re-authenticate” are originally taken
from [CC]. The operation “load” is synonymous to “import” used in [CC].
Definition of security attributes:
security attribute values meaning
terminal authentication
status
none (any Terminal) default role (i.e. without
authorisation after start-up)
CVCA roles defined in the certificate used
for authentication; Terminal is
authenticated as Company Verifying
Certification Authority after
successful CA and TA; equivalent to
CVCA from [TR03110-3] but
restricting to only companies and
organizations.
DV (domestic) roles defined in the certificate used
for authentication (cf. [TR03110]);
Terminal is authenticated as
domestic Document Verifier after
successful CA and TA
DV (foreign) roles defined in the certificate used
for authentication (cf. [TR03110]);
Terminal is authenticated as foreign
Document Verifier after successful
CA and TA
IS roles defined in the certificate used
for authentication (cf. [TR03110]);
Terminal is authenticated as
Extended Inspection System after
successful CA and TA
Terminal Authorization none
EF-0021 (Fingerprint) Read access to EF-0021
Tabla 2.- Definition of security attributes.
The following table provides an overview of the keys and certificates used.
Name Data
TOE intrinsic secret
cryptographic keys
Permanently or temporarily stored secret cryptographic
material used by the TOE in order to enforce its security
functionality.
Company Verifying
Certification Authority Private
Key (SKCVCA)
The Company Verifying Certification Authority (CVCA) holds a
private key (SKCVCA) used for signing the Document Verifier
Certificates.
Company Verifying
Certification Authority
The TOE stores the Company Verifying Certification Authority
Public Key (PKCVCA) as part of the TSF data to verify the
Security Requirements
Versión 2.1.0 Página 54 de 158
Public Key (PKCVCA) Document Verifier Certificates. The PKCVCA has the security
attribute Current Date as the most recent valid effective date
of the Company Verifying Certification Authority Certificate or
of a domestic Document Verifier Certificate.
Company Verifying
Certification Authority
Certificate (CCVCA)
The Company Verifying Certification Authority Certificate may
be a self-signed certificate or a link certificate (cf. equivalent
to CVCA from [TR03110-3] but restricting to companies and
organizations). It contains (i) the Company Verifying
Certification Authority Public Key (PKCVCA) as authentication
reference data, (ii) the coded access control rights of the
Company Verifying Certification Authority, (iii) the Certificate
Effective Date and the Certificate Expiration Date as security
attributes.
Document Verifier Certificate
(CDV)
The Document Verifier Certificate CDV is issued by the
Company Verifying Certification Authority. It contains (i) the
Document Verifier Public Key (PKDV) as authentication
reference data (ii) identification as domestic or foreign
Document Verifier, the coded access control rights of the
Document Verifier, the Certificate Effective Date and the
Certificate Expiration Date as security attributes.
Inspection System Certificate
(CIS)
The Inspection System Certificate (CIS) is issued by the
Document Verifier. It contains (i) as authentication reference
data the Inspection System Public Key (PKIS), (ii) the coded
access control rights of the Extended Inspection System, the
Certificate Effective Date and the Certificate Expiration Date as
security attributes.
Chip Authentication Public
Key Pair
The Chip Authentication Public Key Pair (SKICC, PKICC) are used
for Key Agreement Protocol: Diffie-Hellman (DH) according to
RFC 2631 or Elliptic Curve Diffie-Hellman according to ISO
11770-3 [ISO11770].
Chip Authentication Public
Key (PKICC)
The Chip Authentication Public Key (PKICC) is stored in the
EF.CardSecurity (cf. [TR03110]).
Chip Authentication Private
Key (SKICC)
The Chip Authentication Private Key (SKICC) is used by the TOE
to authenticate itself as authentic electronic document chip. It
is part of the TSF data.
Company Signing Certification
Authority Key Pair
Company Signing Certification Authority of the issuing
Organisation signs the Document Signer Public Key Certificate
with the Company Signing Certification Authority Private Key
and the signature will be verified by receiving terminal with
the Company Signing Certification Authority Public Key.
Document Signer Key Pairs Document Signer of the issuing Organisation signs the Chip
Authentication Public Key of the electronic document with the
Document Signer Private Key and the signature will be verified
by the terminal with the Document Signer Public Key.
Chip Authentication Session
Keys
Secure messaging encryption key and MAC computation key
agreed between the TOE and an Inspection System in result of
the Chip Authentication Protocol Version 2.
PACE Session Keys Secure messaging encryption key and MAC computation key
agreed between the TOE and a terminal in result of PACE.
Security Functional Requirements
Versión 2.1.0 Página 55 de 158
PACE authentication
ephemeral key pair
The ephemeral PACE Authentication Key Pair is used for Key
Agreement Protocol: Diffie-Hellman (DH) according to RFC
2631 or Elliptic Curve Diffie-Hellman according to ISO 11770-3
[ISO11770].
Tabla 3.- Keys and certificates.
Application note 16: The Company Verifying Certification Authority identifies a Document
Verifier as “domestic” in the Document Verifier Certificate if it belongs to the same
Organization as the Company Verifying Certification Authority. The Company Verifying
Certification Authority identifies a Document Verifier as “foreign” in the Document Verifier
Certificate if it does not belong to the same Organization as the Company Verifying
Certification Authority. From electronic document’s point of view the domestic Document
Verifier belongs to the issuing Organisation.
7.1. Security Functional Requirements
The statements of security requirements must be internally consistent. As several different PPs
with similar SFRs are claimed, great care must be taken to ensure that these several iterated
SFRs do not lead to inconsistency.
7.1.1. Class FCS
7.1.1.1. SFRs for [MR.ED-ON-PP]
FCS_COP.1/UPD_ITC Cryptographic Operation – Inter Trusted Channel
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/UPD_ITC
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 56 de 158
FCS_COP.1.1/UPD_ITC The TSF shall perform secure messaging – encryption and
decryption11
in accordance with a specified cryptographic
algorithm AES in CBC mode12
and cryptographic key sizes 192
bits13
that meet the following: [EN419212-3]14
.
FCS_CKM.1/UPD_ITC Cryptographic Key Generation
Hierarchical to:
No other components.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/UPD_ITC
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
FCS_CKM.1.1/UPD_ITC The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm Section 3.8.3
of [EN419212-3]15
and specified cryptographic key sizes 192
bits16
that meet the following: [EN419212-3]17
.
FCS_COP.1/UPD_DEC Cryptographic Operation – Decryption of Update Packages
Hierarchical to:
No other components.
Dependencies:
11
[assignment: list of cryptographic operations]
12
[assignment: cryptographic algorithm]
13
[assignment: cryptographic key sizes]
14
[assignment: list of standards]
15
[assignment: cryptographic key generation algorithm]
16
[assignment: cryptographic key sizes]
17
[assignment: list of standards]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 57 de 158
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/UPD_DEC
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
FCS_COP.1.1/UPD_DEC The TSF shall perform decryption of update packages18
in
accordance with a specified cryptographic algorithm AES19
and
cryptographic key sizes 128 bits20
that meet the following:
none21
.
FCS_CKM.1/UPD_DEC Cryptographic Key Generation
Hierarchical to:
No other components.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/UPD_DEC
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
FCS_CKM.1.1/UPD_DEC The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm AES22
and
18
[assignment: list of cryptographic operations]
19
[assignment: cryptographic algorithm]
20
[assignment: cryptographic key sizes]
21
[assignment: list of standards]
22
[assignment: cryptographic key generation algorithm]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 58 de 158
specified cryptographic key sizes 128 bits23
that meet the
following: none24
.
FCS_COP.1/UPD_SIG Cryptographic Operation – Signature Verification of Update
Packages
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
not fulfilled but justified: The TOE uses security attributes (keys) that have been defined
during the personalization and are fixed over the whole life time of the TOE. No import
or generation of these security attributes is necessary here.
FCS_CKM.4 Cryptographic key destruction
not fulfilled but justified: The TOE uses security attributes (keys) that have been defined
during the personalization and are fixed over the whole life time of the TOE. Key
destruction implies not being able to verify digital signatures from then on, and hence,
is not applicable here.
FCS_COP.1.1/UPD_SIG The TSF shall perform digital signature verification25
in
accordance with a specified cryptographic algorithm RSA or
ECDSA26
and cryptographic key sizes 3072 – 3840 bits (for RSA)
or 256 bits, 384 bits, 512 bits and 521 bits (for ECDSA)27
that
meet the following: [PKCS#1] v2.1 RFC 3447 or The Elliptic Curve
Digital Signature Algorithm (ECDSA) American National
Standards Institute, ANSI, 200528
.
23
[assignment: cryptographic key sizes]
24
[assignment: list of standards]
25
[assignment: list of cryptographic operations]
26
[assignment: cryptographic algorithm]
27
[assignment: cryptographic key sizes]
28
[assignment: list of standards]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 59 de 158
FCS_COP.1/UPD_INT Cryptographic Operation – Integrity Verification of Update
Package
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/UPD_INT
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
FCS_COP.1.1/UPD_INT The TSF shall perform integrity verification of update packages29
in accordance with a specified cryptographic algorithm CMAC30
and cryptographic key sizes 128 bits31
that meet the following:
NIST. Recommendation for Block Cipher Modes of Operation:
The CMAC Mode for Authentication, Special Publication 800-
38B, 200532
.
Application note 17: Integrity verification of packages is intended to be used for a hash function
(keyed or unkeyed) with which the TOE checks the integrity of received update packages prior
to decryption.
FCS_CKM.1/UPD_INT Cryptographic Key Generation
Hierarchical to:
No other components.
29
[assignment: list of cryptographic operations]
30
[assignment: cryptographic algorithm]
31
[assignment: cryptographic key sizes]
32
[assignment: list of standards]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 60 de 158
Dependencies:
[FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/UPD_INT
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/UPD
FCS_CKM.1.1/UPD_INT The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm AES33
and
specified cryptographic key sizes 128 bits34
that meet the
following: none35
.
Application note 18: This SFR is intended for the key generation in case a keyed hash function is
used for FCS_COP.1/UPD_INT. In case of unkeyed hash function is used, the integrity is solely
implied by digital signature verification. Hence in this case, 'none' is assigned.
FCS_CKM.4/UPD_OS Cryptographic Key Destruction – Operating System
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]:
fulfilled by FCS_CKM.1/UPD_DEC and FCS_CKM.1/UPD_ITC
FCS_CKM.4.1/UPD_OS The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method zeroes writing in the zone
33
[assignment: cryptographic key generation algorithm]
34
[assignment: cryptographic key sizes]
35
[assignment: list of standards]
SFRs for [EAC2PP]
Versión 2.1.0 Página 61 de 158
memory in where (AES) session key is stored36
that meets the following:
none37
.
FCS_CKM.4/UPD Cryptographic Key Destruction
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]:
fulfilled by FCS_CKM.1/UPD_INT
FCS_CKM.4.1/UPD The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method Loader mechanism destruction
method38
that meets the following: none39
.
7.1.1.2. SFRs for [EAC2PP]
FCS_CKM.1/DH_PACE Cryptographic Key Generation – Diffie-Hellman for
PACE and CA2 Session Keys
Hierarchical to:
No other components
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]
not fulfilled, but justified:
A Diffie-Hellman key agreement is used in order to have no key distribution, therefore
FCS_CKM.2 makes no sense in this case.
FCS_CKM.4 Cryptographic key destruction
36
[assignment: cryptographic key destruction method]
37
[assignment: list of standards]
38
[assignment: cryptographic key destruction method]
39
[assignment: list of standards]
SFRs for [EAC2PP]
Versión 2.1.0 Página 62 de 158
fulfilled by FCS_CKM.4/EAC2
FCS_CKM.1.1/DH_PACE
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm ECDH compliant to [TR03111]40
and specified cryptographic
key sizes 256 bits, 384 bits, 512 bits and 521 bits41
that meet the following: [TR03110-2]
using brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1 curves defined in
[RFC5639] and NIST P-256, NIST P-384 and NIST P-521 curves defined in [NIST SP 800-
186]42
.
Application note 19: National cryptographic requirements may further restrict available choices
in the selection of the above SFR.
Application note 20: Diffie-Hellman key generation is considered for PACE and Chip
Authentication 2 (cf. FIA_API.1/CA), here FCS_CKM.1/DH_PACE applies for CA2 as well.
FCS_COP.1/SHA Cryptographic operation – Hash for key derivation
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data
with security attributes, or FCS_CKM.1 Cryptographic key generation]
not fulfilled, but justified:
A hash function does not use any cryptographic key; hence, neither a respective key import
nor key generation can be expected here.
FCS_CKM.4 Cryptographic key destruction
not fulfilled, but justified:
A hash function does not use any cryptographic key; hence, a respective key destruction
cannot be expected here.
FCS_COP.1.1/SHA
40
[assignment: cryptographic key generation algorithm]
41
[assignment: cryptographic key sizes]
42
[assignment: list of standards]
SFRs for [EAC2PP]
Versión 2.1.0 Página 63 de 158
The TSF shall perform hashing43
in accordance with a specified cryptographic algorithm SHA-
25644
and cryptographic key sizes none45
that meet the following: [SHS]46
.
Application note 21: For compressing (hashing) an ephemeral public key for DH (TA2 and CA2),
the hash function SHA-1 shall be used ([TR03110-3]). The TOE shall implement as hash functions
either SHA-1 or SHA-224 or SHA-256 for Terminal Authentication 2, cf. [TR03110-3].
Within the normative Appendix of [TR03110-3] ‘Key Derivation Function’, it is stated that the
hash function SHA-1 shall be used for deriving 128-bit AES keys, whereas SHA-256 shall be used
for deriving 192-bit and 256-bit AES keys.
FCS_COP.1/SIG_VER Cryptographic operation – Signature verification
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user
data with security attributes, or FCS_CKM.1 Cryptographic key generation]
not fulfilled, but justified:
The root key PKCVCA (initialization data) used for verifying the DV Certificate is stored in
the TOE during its personalization in the card issuing life cycle phase47
. Since importing
the respective certificates (Terminal Certificate, DV Certificate) does not require any
special security measures except those required by the current SFR (cf.
FMT_MTD.3/EAC2 below), the current ST does not contain any dedicated requirement
like FDP_ITC.2 for the import function.
FCS_CKM.4 Cryptographic key destruction
not fulfilled, but justified:
Cryptographic keys used for the purpose of the current SFR (PKPCD, PKDV, PKCVCA) are
public keys; they do not represent any secret, and hence need not to be destroyed.
FCS_COP.1.1/SIG_VER
43
[assignment: list of cryptographic operations]
44
[assignment: cryptographic algorithm]
45
[assignment: cryptographic key sizes]
46
[assignment: list of standards]
47
as already mentioned, operational use of the TOE is explicitly in focus of the current ST.
SFRs for [EAC2PP]
Versión 2.1.0 Página 64 de 158
The TSF shall perform digital signature verification48
in accordance with a specified
cryptographic algorithm ECDSA49
and cryptographic key sizes 256 bits, 384 bits, 512 bits
and 521 bits50
that meet the following: The Elliptic Curve Digital Signature Algorithm
(ECDSA) American National Standards Institute, ANSI, 2005.51
Application note 22: This SFR is concerned with Terminal Authentication 2, cf. [TR03110-2].
FCS_COP.1/PACE_ENC Cryptographic operation – Encryption /
Decryption AES
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data
with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/DH_PACE
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/EAC2
FCS_COP.1.1/PACE_ENC
The TSF shall perform secure messaging – encryption
and decryption52
in accordance with a specified
cryptographic algorithm AES in CBC mode53
and
cryptographic key sizes 192 bits54
that meet the
following: [TR03110-3].55
Application note 23: This SFR requires the TOE to implement the cryptographic primitive AES for
secure messaging with encryption of transmitted data. The related session keys are agreed
between the TOE and the terminal as part of either the PACE protocol (PACE-KEnc) or Chip
Authentication 2 (CA-KEnc) according to FCS_CKM.1/DH_PACE. Note that in accordance with
48
[assignment: list of cryptographic operations]
49
[assignment: cryptographic algorithm]
50
[assignment: cryptographic key sizes]
51
[assignment: list of standards]
52
[assignment: list of cryptographic operations]
53
[selection: cryptographic algorithm]
54
[selection: 128, 192, 256 bit ]
55
[assignment: list of standards]
SFRs for [EAC2PP]
Versión 2.1.0 Página 65 de 158
[TR03110-3], 3DES could be used in CBC mode for secure messaging. Due to the fact that 3DES
is not recommended any more (cf. [TR03116-2]), 3DES in any mode is no longer applicable here.
FCS_COP.1/PACE_MAC Cryptographic operation – CMAC
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user
data with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/DH_PACE
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/EAC2
FCS_COP.1.1/PACE_MAC
The TSF shall perform secure messaging – message authentication code56
in accordance
with a specified cryptographic algorithm CMAC57
and cryptographic key sizes 192 bits58
that meet the following: [TR03110-3]59
.
FCS_CKM.4/EAC2 Cryptographic key destruction – Session keys
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user
data with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/DH_PACE
56
[assignment: list of cryptographic operations]
57
[selection: cryptographic algorithm]
58
[selection: 112,128, 192, 256 bit]
59
[assignment: list of standards]
SFRs for [EAC2PP]
Versión 2.1.0 Página 66 de 158
FCS_CKM.4.1/EAC2 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method zeroes writing
in the zone memory in where (AES) session key is stored60
that
meets the following: none61
.
Application note 24: The TOE shall destroy the PACE session keys after detection of an error in
a received command by verification of the MAC. The TOE shall clear the memory area of any
session keys before starting the communication with the terminal in a new after-reset-session
as required by FDP_RIP.1/EAC2.
The Application Note above concerning this component requires the destruction of PACE session
keys after detection of an error in a received command by verification of the MAC. While the
definition of FCS_CKM.4/EAC2 remains unaltered, here this component also requires the
destruction of sessions keys after a successful run of Chip Authentication 2. The TOE shall
destroy the CA2 session keys after detection of an error in a received command by verification
of the MAC. The TOE shall clear the memory area of any session keys before starting the
communication with the terminal in a new after-reset-session as required by FDP_RIP.1/EAC2.
FCS_RND.1/EAC2 Quality metric for random numbers
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FCS_RND.1.1/EAC2 The TSF shall provide a mechanism to generate random
numbers that meet NIST Special Publication 800-90A62
.
Application note 25: This SFR requires the TOE to generate random numbers (random nonce)
used for the authentication protocol (PACE) as required by FIA_UAU.4/PACE.
The Application Note above concerning this component requires the TOE to generate random
numbers (random nonces) for PACE. While the definition of FCS_RND.1/EAC2 remains
unaltered, here this component requires the TOE to generate random numbers (random nonce)
for all authentication protocols (i.e. PACE, CA2), as required by FIA_UAU.4/PACE_EAC2.
60
[assignment: cryptographic key destruction method]
61
[assignment: list of standards]
62
[assignment: a defined quality metric]
SFRs for [SSCDPP]
Versión 2.1.0 Página 67 de 158
7.1.1.3. SFRs for [SSCDPP]
The following SFRs are imported due to claiming [SSCDPP]. They only concern the cryptographic
support for an eSign application.
FCS_CKM.1/RSA_SSCDPP Cryptographic key generation - RSA
Hierarchical to:
No other components.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/RSA_SSCDPP
FCS_CKM.4 Cryptographic key destruction fulfilled by FCS_CKM.4/RSA_SSCDPP
FCS_CKM.1.1/RSA_SSCDPP The TSF shall generate an SCD/SVD pair in accordance with a
specified cryptographic key generation algorithm RSA63
and
specified cryptographic key sizes 3072 – 3840 bits64
that meet
the following: [FIPS 186-4] and [FIPS 140-2].65
FCS_CKM.1/EC_SSCDPP Cryptographic key generation - EC
Hierarchical to:
No other components.
Dependencies:
[FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation]
fulfilled by FCS_COP.1/EC_SSCDPP
FCS_CKM.4 Cryptographic key destruction fulfilled by FCS_CKM.4/EC_SSCDPP
FCS_CKM.1.1/EC_SSCDPP The TSF shall generate an SCD/SVD pair in accordance with a
specified cryptographic key generation algorithm Appendix
A.4.3 in [ANSI X9.62] and section 6.1 in [ISO15946-1]66
and
63
[assignment: cryptographic key generation algorithm]
64
[assignment: cryptographic key sizes]
65
[assignment: list of standards]
66
[assignment: cryptographic key generation algorithm]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 68 de 158
specified cryptographic key sizes 256 bits, 384 bits, 512 bits and
521 bits67
that meet the following: [ANSI X9.62]68
.
7.1.1.4. SFRs for [SSCDPP] and [SSCDPP3]
The following SFRs are imported due to claiming [SSCDPP] and [SSCDPP3]. They only concern
the cryptographic support for an eSign application.
FCS_CKM.4/RSA_SSCDPP Cryptographic key destruction - RSA
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] fulfilled by FCS_CKM.1/RSA_SSCDPP
FCS_CKM.4.1/RSA_SSCDPP The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method zeroes writing
in the zone memory in where SCD/SVD is stored69
that meets the
following: none70
.
FCS_CKM.4/EC_SSCDPP Cryptographic key destruction - EC
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
67
[assignment: cryptographic key sizes]
68
[assignment: list of standards]
69
[assignment: cryptographic key destruction method]
70
[assignment: list of standards]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 69 de 158
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] fulfilled by FCS_CKM.1/EC_SSCDPP
FCS_CKM.4.1/EC_SSCDPP The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method zeroes writing
in the zone memory in where SCD/SVD is stored71
that meets the
following: none72
.
FCS_COP.1/RSA_SSCDPP Cryptographic operation - RSA
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] fulfilled by FCS_CKM.1/RSA_SSCDPP
FCS_CKM.4 Cryptographic key destruction fulfilled by FCS_CKM.4/RSA_SSCDPP
FCS_COP.1.1/RSA_SSCDPP The TSF shall perform digital signature creation73
in accordance
with a specified cryptographic algorithm RSA74
and
cryptographic key size 3072 – 3840 bits75
that meet the
following: [PKCS#1] v2.1 RFC 344776
.
FCS_COP.1/SHA_SSCDPP Cryptographic operation - SHA
Hierarchical to:
No other components.
71
[assignment: cryptographic key destruction method]
72
[assignment: list of standards]
73
[assignment: list of cryptographic operations]
74
[assignment: cryptographic algorithm]
75
[assignment: cryptographic key sizes]
76
[assignment: list of standards]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 70 de 158
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]: not fulfilled but justified
FCS_CKM.4 Cryptographic key destruction: not fulfilled but justified
A hash function does not use any cryptographic key; hence, neither a respective key
import nor key generation can be expected here.
A hash function does not use any cryptographic key; hence, a respective key destruction
cannot be expected here.
FCS_COP.1.1/SHA_SSCDPP The TSF shall perform digital signature creation hash-value
calculation of user chosen data77
in accordance with a specified
cryptographic algorithm SHA-25678
and cryptographic key sizes
of none79
that meet the following: Federal Information
Processing Standards (FIPS) Publication 180-4 [SHS]80
.
FCS_COP.1/EC_SSCDPP Cryptographic key operation - EC
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] fulfilled by FCS_CKM.1/EC_SSCDPP
FCS_CKM.4 Cryptographic key destruction fulfilled by FCS_CKM.4/EC_SSCDPP
77
[assignment: list of cryptographic operations]
78
[assignment: cryptographic algorithm]
79
[assignment: cryptographic key sizes]
80
[assignment: list of standards]
Class FCS for PRO secure channel
Versión 2.1.0 Página 71 de 158
FCS_COP.1.1/EC_SSCDPP81
The TSF shall perform digital signature creation82
in accordance
with a specified cryptographic algorithm Appendix A.4.3 in [ANSI
X9.62] and section 6.1 in [ISO15946-1]83
and cryptographic key
sizes 256 bits, 384 bits, 512 bits and 521 bits84
that meet the
following: [ANSI X9.62] using brainpoolP256r1, brainpoolP384r1
and brainpoolP512r1 curves defined in [RFC5639] and NIST P-
256, NIST P-384 and NIST P-521 curves defined in [NIST SP 800-
186]85
.
7.1.1.5. Class FCS for PRO secure channel
FCS_CKM.1/AES_PRO Cryptographic key generation – AES session keys for PRO
secure channel
Hierarchical to:
No other components
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation]
not fulfilled, but justified:
A Diffie-Hellman key agreement is used in order to have no key distribution, therefore
FCS_CKM.2 makes no sense in this case.
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/AES_PRO
FCS_CKM.1.1/AES_PRO
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm AES86
and specified cryptographic key sizes 192 bits87
that
meet the following: based on ECDH protocol compliant to [EN419212-3]88
using
brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1 curves defined in [RFC5639]
and NIST P-256, NIST P-384 and NIST P-521 curves defined in [NIST SP 800-186].
81
on Weierstrass curves
82
[assignment: list of cryptographic operations]
83
[assignment: cryptographic algorithm]
84
[assignment: cryptographic key sizes]
85
[assignment: list of standards]
86
[assignment: cryptographic key generation algorithm]
87
[assignment: cryptographic key sizes]
88
[assignment: list of standards]
Class FCS for PRO secure channel
Versión 2.1.0 Página 72 de 158
FCS_CKM.4/AES_PRO Cryptographic key destruction - AES
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] fulfilled by FCS_CKM.1/AES_PRO
FCS_CKM.4.1/AES_PRO The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method zeroes writing
in the zone memory in where (AES) session key is stored89
that
meets the following: none90
.
FCS_COP.1/AES_PRO Cryptographic operation - AES
Hierarchical to:
No other components.
Dependencies:
[FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data
with security attributes, or FCS_CKM.1 Cryptographic key generation]
fulfilled by FCS_CKM.1/AES_PRO
FCS_CKM.4 Cryptographic key destruction
fulfilled by FCS_CKM.4/AES_PRO
FCS_COP.1.1/AES_PRO
89
[assignment: cryptographic key destruction method]
90
[assignment: list of standards]
Class FIA
Versión 2.1.0 Página 73 de 158
The TSF shall perform secure messaging – encryption and decryption91
in accordance
with a specified cryptographic algorithm AES in CBC mode92
and cryptographic key sizes
192 bits93
that meet the following: [EN419212-3]94
.
Note that this SFR requires the TOE to implement the cryptographic primitive AES for secure
messaging with encryption of transmitted data. The related session keys are agreed between
the TOE and the terminal as part of an elliptic curve Diffie-Hellman key agreement according to
FCS_CKM.1/AES_PRO, using brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1 curves
defined in [RFC5639] and NIST P-256, NIST P-384 and NIST P-521 curves defined in [NIST SP 800-
186].
7.1.2. Class FIA
Tabla 4 provides an overview of the authentication and identification mechanisms used.
Name SFR for the TOE
Authentication mechanisms related
to applications with user data
FIA_AFL.1/Suspend_PIN
FIA_AFL.1/Block_PIN
FIA_API.1/CA
FIA_UID.1/PACE
FIA_UID.1/EAC2_Terminal
FIA_UAU.1/PACE
FIA_UAU.1/EAC2_Terminal
FIA_UAU.4/PACE
FIA_UAU.5/PACE
FIA_UAU.6/CA
FIA_UAU.6/PACE
Authetication mechanisms for
updating the TOE
FIA_AFL.1/UPD
FIA_UAU.1/UPD
FIA_UID.1/UPD
Access mechanisms for an eSign
application
FIA_UID.1/SSCDPP
FIA_API.1.1/SSCDPP4
FIA_AFL.1/SSCDPP
FIA_AFL.1/BIO_SSCDPP
Tabla 4.- Overview of authentication SFRs
7.1.2.1. SFRs for [MR.ED-ON-PP]
FIA_AFL.1/UPD Update Package Verification Failure Handling
91
[assignment: list of cryptographic operations]
92
[selection: cryptographic algorithm]
93
[selection: 128, 192, 256 bit ]
94
[assignment: list of standards]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 74 de 158
Hierarchical to:
No other components.
Dependencies:
FIA_UAU.1 Timing of authentication:
fulfilled by FIA_UAU.1/UPD
FIA_AFL.1.1/UPD The TSF shall detect when 395
unsuccessful authentication
update attempts occur related to the digital signature
verification96
.
FIA_AFL.1.2/UPD When the defined number of unsuccessful authentication
update attempts has been met97
, the TSF shall block the update
mechanism98
.
Application note 26: The above SFR is slightly refined here by replacing 'authentication' with
'update'. Also the second assignment is made more precise. An update attempt includes
authentication of the update terminal to the TOE. But when a properly authenticated terminal
sends an update package that is not authentic or whose integrity cannot be validated, this is still
a failed update attempt, and the TOE must handle it according to the above SFR. Hence this
refinement is stricter than the original SFR definition.
FIA_UID.1/UPD Timing of Identification
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UID.1.1/UPD The TSF shall allow
1) to establish a communication channel,
95
[assignment: positive integer number]
96
[assignment: list of authentication events of the update procedure]
97
[selection: met, surpassed]
98
[assignment: list of actions]
SFRs for [EAC2PP]
Versión 2.1.0 Página 75 de 158
2) to authenticate an update terminal by a successful
establishment of a secure channel according to [EN419212-
3]99
on behalf of the user to be performed before the user is
identified.
FIA_UID.1.2/UPD The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
FIA_UAU.1/UPD Timing of Authentication
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of Identification
fulfilled by FIA_UID.1/UPD
FIA_UAU.1.1/UPD The TSF shall allow
1) to establish a communication channel,
2) to authenticate an update terminal by a successful
establishment of a secure channel according to [EN419212-
3]100
3) to authenticate an update terminal by a successful
establishment of a secure channel with the loader101
on behalf of the user to be performed before the user is
authenticated.
FIA_UAU.1.2/UPD The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of
that user.
7.1.2.2. SFRs for [EAC2PP]
99
[assignment: cryptographic method]
100
[assignment: cryptographic method]
101
[assignment: list of TSF-mediated actions]
SFRs for [EAC2PP]
Versión 2.1.0 Página 76 de 158
FIA_AFL.1/Suspend_PIN Authentication failure handling – Suspending PIN
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
fulfilled by FIA_UAU.1/PACE
FIA_AFL.1.1/Suspend_PIN The TSF shall detect when 2102
unsuccessful
authentication attempts occur related to consecutive
failed authentication attempts using the PIN as the
shared password for PACE103
.
FIA_AFL.1.2/Suspend_PIN When the defined number of unsuccessful
authentication attempts has been met104
, the TSF shall
suspend the reference value of the PIN according to
[TR03110-2]105
.
Application note 27: The assigned integer number for unsuccessful authentication attempts with
any PACE password could be different to the integer for the case when using a PIN, since it just
adds a requirement specific to the case where the PIN is the shared password
FIA_AFL.1/Block_PIN Authentication failure handling – Blocking PIN
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication:
fulfilled by FIA_UAU.1/PACE
FIA_AFL.1.1/Block_PIN The TSF shall detect when 3106
unsuccessful
authentication attempts occur related to consecutive
102
[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
103
[assignment: list of authentication events]
104
[selection: met , surpassed]
105
[assignment: list of actions]
106
[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
SFRs for [EAC2PP]
Versión 2.1.0 Página 77 de 158
failed authentication attempts using the suspended PIN
as the shared password for PACE107
.
FIA_AFL.1.2/Block_PIN When the defined number of unsuccessful
authentication attempts has been met108
, the TSF shall
block the reference value of PIN according to [TR03110-
2]109
.
FIA_API.1/CA Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1/CA The TSF shall provide the protocol Chip Authentication 2
according to [TR03110-2]110
, to prove the identity of the
TOE111
.
FIA_UID.1/PACE Timing of identification
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UID.1.1/PACE The TSF shall allow
1. to establish a communication channel,
2. carrying out the PACE protocol according to
[TR03110-2]
107
[assignment: list of authentication events]
108
[selection: met , surpassed]
109
[assignment: list of actions]
110
[assignment: authentication mechanism]
111
[assignment: authorised user or role, or of the TOE itself ]
SFRs for [EAC2PP]
Versión 2.1.0 Página 78 de 158
3. to read the Initialization Data if it is not disabled by
TSF according to FMT_MTD.1/INI_DIS112
on behalf of the user to be performed before the user is
identified.
FIA_UID.1.2/PACE The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated
actions on behalf of that user.
Application note 28: The user identified after a successful run of PACE is a PACE terminal. In case
the PIN or PUK were used for PACE, the user identified is the electronic document holder using
a PACE terminal. Note that the CAN does not effectively represent a secret, but is restricted-
revealable; i.e. in case the CAN is used for PACE, it is either the electronic document holder itself,
an authorized person other than the electronic document holder, or a device.
FIA_UID.1/EAC2_Terminal Timing of identification
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UID.1.1/EAC2_Terminal The TSF shall allow
1. to establish a communication channel,
2. carrying out the PACE protocol according to
[TR03110-2] ,
3. to read the Initialization Data if it is not
disabled by TSF according to
FMT_MTD.1/INI_DIS
4. carrying out the Terminal Authentication
protocol 2 according to [TR03110-2]113
on behalf of the user to be performed before
the user is identified.
112
[assignment: list of TSF-mediated actions]
113
[assignment: list of TSF-mediated actions]
SFRs for [EAC2PP]
Versión 2.1.0 Página 79 de 158
FIA_UID.1.2/EAC2_Terminal The TSF shall require each user to be
successfully identified before allowing any other
TSF-mediated actions on behalf of that user.
Application note 29: The user identified after a successfully performed TA2 is an EAC2 terminal.
The types of EAC2 terminals are application dependent;
Application note 30: In the life cycle phase manufacturing, the manufacturer is the only user role
known to the TOE. The manufacturer writes the initialization data and/or pre-personalization
data in the audit records of the IC.
Note that a personalization agent acts on behalf of the electronic document issuer under his and
the CSCA's and DS's policies. Hence, they define authentication procedures for personalization
agents. The TOE supports these authentication procedures. These procedures are subject to
evaluation within the assurance components ALC_DEL.1 and AGD_PRE.1. The TOE assumes the
user role personalization agent, if a terminal proves the respective Terminal Authorization level
(e. g. a privileged terminal, cf. [TR03110-2]).
FIA_UAU.1/PACE Timing of authentication
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification
fulfilled by FIA_UID.1/PACE
FIA_UAU.1.1/PACE The TSF shall allow
1. to establish a communication channel,
2. carrying out the PACE protocol according to
[TR03110-2]
3. to read the Initialization Data if it is not disabled by
TSF according to FMT_MTD.1/INI_DIS114
on behalf of the user to be performed before the user is
authenticated.
114
[assignment: list of TSF-mediated actions]
SFRs for [EAC2PP]
Versión 2.1.0 Página 80 de 158
FIA_UAU.1.2/PACE The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated
actions on behalf of that user.
Application note 31: If PACE has been successfully performed, secure messaging is started using
the derived session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE. Application note 30 also
applies here.
FIA_UAU.1/EAC2_Terminal Timing of authentication
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification fulfilled by FIA_UID.1/EAC2_Terminal
FIA_UAU.1.1/EAC2_Terminal The TSF shall allow
1. to establish a communication channel,
2. carrying out the PACE protocol according to
[TR03110-2] ,
3. to read the Initialization Data if it is not
disabled by TSF according to
FMT_MTD.1/INI_DIS
4. carrying out the Terminal Authentication 2
protocol according to [TR03110-2]115
on behalf of the user to be performed before
the user is authenticated.
FIA_UAU.1.2/EAC2_Terminal The TSF shall require each user to be
successfully authenticated before allowing any
other TSF-mediated actions on behalf of that
user.
Application note 32: The user authenticated after a successful run of TA2 is an EAC2 terminal.
The authenticated terminal will immediately perform Chip Authentication 2 as required by
115
[assignment: list of TSF mediated actions]
SFRs for [EAC2PP]
Versión 2.1.0 Página 81 de 158
FIA_API.1/CA using, amongst other, Comp(ephem-PKPCD-TA) from the accomplished TA2. Note
that Passive Authentication using PKICC signature is considered to be part of CA2.
FIA_UAU.4/PACE Single-use authentication of the Terminals by the TOE
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data
related to
1. PACE protocol according to [TR03110-2],
2. Authentication Mechanism based on AES116
3. Terminal Authentication 2 protocol according to
[TR03110-2]117
Application note 33: For PACE, the TOE randomly selects an almost uniformly distributed nonce
of 128 bit length. The current ST supports a key derivation function based on AES; see [TR03110-
2]. For TA2, the TOE randomly selects a nonce rPICC of 64 bit length, see [TR03110-2].
FIA_UAU.5/PACE Multiple authentication mechanisms
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UAU.5.1/PACE The TSF shall provide
1. PACE protocol according to [TR03110-2],
2. Passive Authentication according to [ICAO9303]
3. Secure messaging according to [TR03110-3]
116
[selection: AES or other approved algorithms]
117
[assignment: identified authentication mechanism(s)]
SFRs for [EAC2PP]
Versión 2.1.0 Página 82 de 158
4. Symmetric Authentication Mechanism based on
AES118
5. Terminal Authentication 2 protocol according to
[TR03110-2],
6. Chip Authentication 2 according to [TR03110-2]119
to support user authentication.
FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity
according to the following rules:
1. Having successfully run the PACE protocol the TOE
accepts only received commands with correct
message authentication codes sent by secure
messaging with the key agreed with the terminal by
the PACE protocol.
2. The TOE accepts the authentication attempt as
personalization agent by the Authentication
Mechanism with Personalization Agent Key(s)120
3. The TOE accepts the authentication attempt by
means of the Terminal Authentication 2 protocol,
only if (i) the terminal presents its static public key
PKPCD and the key is successfully verifiable up to the
CVCA and (ii) the terminal uses the PICC identifier
IDPICC = Comp(ephem-PKPICC-PACE) calculated during,
and the secure messaging established by the,
current PACE authentication.
4. Having successfully run Chip Authentication 2, the
TOE accepts only received commands with correct
message authentication codes sent by secure
messaging with the key agreed with the terminal by
Chip Authentication 2121
FIA_UAU.6/CA Re-authenticating of Terminal by the TOE
Hierarchical to:
No other components.
Dependencies:
118
[selection: AES or other approved algorithms]
119
Passive Authentication using PKICC signature is considered to be part of CA2
120
[selection: the Authentication Mechanism with Personalization Agent Key(s)]
121
[assignment: rules describing how the multiple authentication mechanisms provide authentication]
SFRs for [EAC2PP]
Versión 2.1.0 Página 83 de 158
No dependencies.
FIA_UAU.6.1/CA The TSF shall re-authenticate the user under the
conditions each command sent to the TOE after a
successful run of Chip Authentication 2 shall be verified
as being sent by the EAC2 terminal122
.
FIA_UAU.6/PACE Re-authenticating of Terminal by the TOE
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FIA_UAU.6.1/PACE The TSF shall re-authenticate the user under the
conditions each command sent to the TOE after
successful run of the PACE protocol shall be verified as
being sent by the PACE terminal.123
Application note 34: The PACE protocol specified in [ICAO9303] starts secure messaging used
for all commands exchanged after successful PACE authentication. The TOE checks each
command by secure messaging in encrypt-then-authenticate mode based on CMAC or Retail-
MAC, whether it was sent by the successfully authenticated terminal (see
FCS_COP.1/PACE_MAC for further details). The TOE does not execute any command with
incorrect message authentication code. Therefore, the TOE re-authenticates the terminal
connected, if a secure messaging error occurred, and accepts only those commands received
from the initially authenticated terminal.
122
[assignment: list of conditions under which re-authentication is required]
123
[assignment: list of conditions under which re-authentication is required]
SFRs concerning eSign-applications
[SSCDPP], [SSCDPP3], [SSCDPP4]
and [SSCDPP6]
Versión 2.1.0 Página 84 de 158
7.1.2.3. SFRs concerning eSign-applications [SSCDPP], [SSCDPP3],
[SSCDPP4] and [SSCDPP6]
The following SFRs are imported due to claiming [SSCDPP], [SSCDPP3], [SSCDPP4] and
[SSCDPP6]. They concern access mechanisms for an eSign application.
FIA_UID.1/SSCDPP Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1/SSCDPP The TSF shall allow
(1) Self-test according to FPT_TST.1/SSCDPP,
(2) To establish a trusted channel between the user and the TOE
and to establish a trusted channel between the SCA and the TOE
(3) To establish a trusted channel between the CSP and the TOE
by means of TSF required by FTP_ITC.1/SCD_SSCDPP3,124
on behalf of the user to be performed before the user is
identified.
FIA_UID.1.2/SSCDPP The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
FIA_AFL.1/SSCDPP Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
fulfilled by FIA_UAU.1/SSCDPP
124
[assignment: list of additional TSF-mediated actions]
SFRs concerning eSign-applications
[SSCDPP], [SSCDPP3], [SSCDPP4]
and [SSCDPP6]
Versión 2.1.0 Página 85 de 158
FIA_AFL.1.1/SSCDPP The TSF shall detect when 3125
unsuccessful authentication
attempts occur related to consecutive failed authentication
attempts.126
FIA_AFL.1.2/SSCDPP When the defined number of unsuccessful authentication
attempts has been met127
, the TSF shall block RAD128
.
FIA_AFL.1/BIO_SSCDPP Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
fulfilled by FIA_UAU.1/SSCDPP
FIA_AFL.1.1/BIO_SSCDPP The TSF shall detect when 24129
unsuccessful authentication
attempts occur related to consecutive failed authentication
attempts130
.
FIA_AFL.1.2/BIO_SSCDPP When the defined number of unsuccessful authentication
attempts has been met131
, the TSF shall block RAD132
.
FIA_API.1/SSCDPP4 Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1/SSCDPP4 The TSF shall provide an administrator secure channel133
to
prove the identity of the SSCD134
.
125
[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
126
[assignment: list of authentication events]
127
[selection: met ,surpassed]
128
[assignment: list of actions]
129
[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
130
[assignment: list of authentication events]
131
[selection: met ,surpassed]
132
[assignment: list of actions]
133
[assignment: authentication mechanism]
134
[assignment: authorized user or rule]
Class FDP
Versión 2.1.0 Página 86 de 158
The next claimed SFR is refined from [SSCDPP], [SSCDPP3], [SSCDPP4] and [SSCDPP5] by
additional assignments. Note that this does not violate strict conformance to [SSCDPP].
FIA_UAU.1/SSCDPP Timing of authentication
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/SSCDPP
FIA_UAU.1.1/SSCDPP
The TSF shall allow
1. self test according to FPT_TST.1/SSCDPP,
2. identification of the user by means of TSF required by FIA_UID.1/SSCDPP,
3. establishing a trusted channel between CGA and the TOE by means of TSF required
by FTP_ITC.1/SVD_SSCDPP4 and FTP_ITC.1/CA respectively,
4. establishing a trusted channel between HID and the TOE by means of TSF required
by FTP_ITC.1/VAD_SSCDPP5 and FTP_ITC.1/CA respectively135
.
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2/SSCDPP
The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
7.1.3. Class FDP
7.1.3.1. SFRs for [MR.ED-PP]
Multiple iterations of FDP_ACF.1 exist from imported PPs to define the access control SFPs for
(common) user data, and EAC2-protected user data.
Concerning FDP_ACF.1/TRM here and the several iterations FDP_ACF.1 from [SSCDPP], we
remark that FDP_ACF.1/TRM also concerns data and objects for signature generation. Note
however, that FDP_ACF.1/TRM requires that prior to granting access to the signature
135
[assignment: list of additional TSF-mediated actions]
SFRs for [MR.ED-PP]
Versión 2.1.0 Página 87 de 158
application, in which the access controls defined in [SSCDPP] apply, an EAC2 terminal and the
electronic document holder need to be authenticated. Hence, no inconsistency exist.
FDP_ACF.1/TRM Security attribute based access control – Terminal Access
Hierarchical to:
No other components.
Dependencies:
FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/TRM
FMT_MSA.3 Static attribute initialization
not fulfilled, but justified:
The access control TSF according to FDP_ACF.1/TRM uses security attributes having
been defined during the personalization and fixed over the whole life time of the TOE.
No management of these security attributes (i.e. SFR FMT_MSA.1/Admin_SSCDPP,
FMT_MSA.1/Signatory_SSCDPP and FMT_MSA.3/SSCDPP) is necessary here.
FDP_ACF.1.1/TRM The TSF shall enforce the Access Control SFP136
to objects based on the
following:
1) Subjects:
a) Terminal,
b) PACE terminal ,
c) EAC2 terminal, authentication terminal, signature
terminal137
;
2) Objects:
a) all user data stored in the TOE.
b) all TOE intrinsic secret (cryptographic) data
3) Security attributes:
a) Terminal Authorization Level (access rights)
136
[assignment: access control SFP]
137
[assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-
relevant security attributes, or name groups of SFP-relevant security attributes]
SFRs for [MR.ED-PP]
Versión 2.1.0 Página 88 de 158
b) Authentication status of the electronic document holder as
a signatory (as an eSign application is included)138 139
.
FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
A PACE terminal is allowed to read data objects from FDP_ACF.1/TRM
after successful PACE authentication according to [TR03110-2] and/or
[ICAO9303], as required by FIA_UAU.1/PACE.140
FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on
the following additional rules: none.141
FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the
following additional rules:
1. Any terminal not being a PACE terminal or an EAC2 terminal is not
allowed to read, to write, to modify, or to use any user data stored
on the electronic document.142
2. Terminals not using secure messaging are not allowed to read, write,
modify, or use any data stored on the electronic document.
3. No subject is allowed to read ‘Communication Establishment
Authorization Data’ stored on the electronic document
4. No subject is allowed to write or modify ‘secret electronic document
holder authentication data’ stored on the electronic document,
except for PACE terminals or EAC2 terminals executing PIN
management based on the following rules:
Change PIN, Resume PIN, Resume PUK, Unblock PIN, Activate PIN,
Deactivate PIN.
5. No subject is allowed to read, write, modify, or use Chip
Authentication key(s) stored on the electronic document.
6. Reading, modifying, writing, or using EAC2 protected data that are
protected only by EAC2, is allowed only to EAC2 terminals using the
following mechanism:
138
[assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-
relevant security attributes, or name groups of SFP-relevant security attributes]
139
[assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-
relevant security attributes, or name groups of SFP-relevant security attributes] (all bullets in
FDP_ACF.1.1/TRM w.r.t. CC part 2 [CC])
140
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
141
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
142
note that authentication of an EAC2 terminal to a TOE in certified mode implies a prior run of PACE.
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 89 de 158
The TOE applies the EAC2 protocol (cf. FIA_UAU.5) to determine
access rights of the terminal according to [TR03110-2]. To determine
the effective authorization of a terminal, the chip must calculate a
bitwise Boolean ’and’ of the relative authorization contained in the
CHAT of the Terminal Certificate, the referenced DV Certificate, and
the referenced CVCA Certificate, and additionally the confined
authorization sent as part of PACE. Based on that effective
authorization and the terminal type drawn from the CHAT of the
Terminal Certificate, the TOE shall grant the right to read, modify or
write EAC2 protected data, or perform operations using these EAC2
protected data.
7. No subject is allowed to read, write, modify or use the data objects
2b) of FDP_ACF.1.1/TRM.
8. Nobody is allowed to read the private signature key(s).143
7.1.3.2. SFRs for [MR.ED-ON-PP]
FDP_ACC.1/UPD Subset Access Control – Terminal Access
Hierarchical to:
No other components.
Dependencies:
FDP_ACF.1 Security attribute based access control:
fulfilled by FDP_ACF.1/UPD
FDP_ACC.1.1/UPD The TSF shall enforce the Update Access Control SFP144
on
1) Subjects:
a) terminal,
b) update terminal.
2) Objects:
a) version information identifying the TOE software
b) update package
c) update log information
3) Operations:
143
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
144
[assignment: access control SFP]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 90 de 158
a) reading out version information,
b) reading out log data,
c) uploading an update package on the TOE, or
d) initiating an update procedure
and none145
.
FDP_ACF.1/UPD Security Attribute based Access Control – Terminal Access
Hierarchical to:
No other components.
Dependencies:
FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/UPD
FMT_MSA.3 Static attribute initialization
not fulfilled, but justified:
The access control TSF according to FDP_ACF.1/UPD uses security attributes that have
been defined during personalization, and that are fixed over the whole life time of the
TOE. No management of these security attributes (i.e. SFR FMT_MSA.1/Admin_SSCDPP,
FMT_MSA.1/Signatory_SSCDPP and FMT_MSA.3/SSCDPP) is necessary here.
FDP_ACF.1.1/UPD The TSF shall enforce the Update Access Control SFP146
to objects
based on the following:
1) Subjects:
a) terminal,
b) update terminal
2) Objects:
a) version information identifying the TOE software
b) update package
c) update log information
3) Security attributes:
a) access rights
145
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
146
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 91 de 158
4) none147
.
FDP_ACF.1.2/UPD The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed:
The authentication level of a terminal must be determined by a
successful establishment of a secure channel according to
[EN419212-3]148
as required by FIA_UAU.1/UPD. Depending on
the authentication level, an authenticated update terminal is
allowed to initiate the update procedure.
The precise definition of access rights and how the
authentication level is calculated from an authenticated
terminal is defined in [GOA].
Once the terminal is authenticated to initiate the update
procedure, it must establish a secure channel using the session
keys from FCS_CKM.1.1/UPD_INT and FCS_CKM.1.1/UPD_DEC
to be authenticated to the loader as required by
FIA_UAU.1/UPD; then, the terminal can start to upload each
update package ensuring its integrity and confidentiality.149
FDP_ACF.1.3/UPD The TSF shall explicitly authorize access of subjects to objects
based on the following additional rules: none.150
FDP_ACF.1.4/UPD The TSF shall explicitly deny access of subjects to objects based
on the following additional rules: none.151
FDP_IFC.1/UPD Subset information flow control
Hierarchical to:
147
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
148
[assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]
149
[assignment: list of technical specifications of cryptographic procedures ]
150
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
151
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 92 de 158
No other components.
Dependencies:
FDP_IFF.1 Simple security attributes,
fulfilled by FDP_IFF.1/UPD
FDP_IFC.1.1/UPD The TSF shall enforce the Update Flow Control SFP152
on the
following:
1) Subjects:
a) terminal,
b) update terminal.
2) information:
a) update package
b) update data
c) c)meta-data, such as version information
3) operations:
a) performing an update153
.
FDP_IFF.1/UPD Simple Security Attributes
Hierarchical to:
No other components.
Dependencies:
FDP_IFC.1 Subset information flow control:
fulfilled by FDP_IFC.1/UPD
FMT_MSA.3 Static attribute initialization:
not fulfilled, but justified:
The update control TSF according to FDP_IFF.1/UPD uses security attributes that have
been defined during personalization, and that are fixed over the whole life time of the
TOE. No management of these security attributes (i.e. SFR FMT_MSA.1/Admin_SSCD y
FMT_MSA.1/Signatory_SSCDPP and FMT_MSA.3/SSCDPP) is necessary here.
152
[assignment: information flow control SFP]
153
[assignment: list of subjects, information, and operations that cause controlled information to flow to
and from controlled subjects covered by the SFP]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 93 de 158
FDP_IFF.1.1/UPD The TSF shall enforce the Update Control SFP154
based on the
following types of subject and information security attributes:
1) Subjects:
a) terminal,
b) update terminal.
2) information:
a) update package
b) update data
c) meta-data, such as version information
3) security attributes:
a) update package verification status with the values:
NOT VERIFIED (default status), SUCCESSFULLY
VERIFIED, and VERIFICATION FAILED155
.
FDP_IFF.1.2/UPD The TSF shall permit an information flow between a controlled
subject and controlled information via a controlled operation if
the following rules hold:
1. The terminal has established a secure channel with the TOE.
2. The TOE shall only accept update packages sent via a secure
channel established with an authenticated update
terminal156
.
FDP_IFF.1.3/UPD The TSF shall enforce the following rules in their specific order:
1) The authenticity (using the digital signature, cf.
FCS_COP.1/UPD_SIG) of the first step of the updating
process is verified by the OS. If the authenticity is not
validated, abort with VERIFICATION FAILED. If the OS
identifier is not verified as correct according to [none] the
security attribute is set to VERIFICATION FAILED.
2) Once the OS has verified the authenticity correctly, the
update package process starts using the loader mechanism.
The integrity (using the keyed or unkeyed hash function cf.
FCS_COP.1/UPD_INT) update package is verified. If the
integrity is not validated, abort with VERIFICATION FAILED,
and erase all data transferred so far, cf. FDP_RIP.1/UPD.
154
[assignment: information flow control SFP]
155
[assignment: list of subjects and information controlled under the indicated SFP, and for each, the
security attributes]
156
[assignment: for each operation, the security attribute-based relationship that must hold between
subject and information security attributes]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 94 de 158
3) The update package is only decrypted, cf.
FCS_COP.1/UPD_DEC, if the integrity has been verified in
rule 2. If the decryption fails, abort with VERIFICATION
FAILED, and erase all data transferred so far, cf.
FDP_RIP.1/UPD.
4) For each update package, steps 2 and 3 will be repeated.
If all conditions are verified, the verification status is set to
SUCCESSFULLY VERIFIED. Otherwise abort with VERIFICATION
FAILED, and erase all data transferred so far, cf. FDP_RIP.1/UPD.
Only if the verification status is SUCCESSFULLY VERIFIED, the TOE
shall install the update data157
.
FDP_IFF.1.4/UPD The TSF shall explicitly authorize an information flow based on
the following rules: none158
.
FDP_IFF.1.5/UPD The TSF shall explicitly deny an information flow based on the
following rules: none159
.
FDP_RIP.1/UPD Subset Residual Information Protection
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FDP_RIP.1.1/UPD The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the
resource from160
the following objects:
1) session keys (immediately after closing related
communication session),
2) all ephemeral keys related to the update mechanism.
157
[assignment: additional information flow control SFP rules]
158
[assignment: rules, based on security attributes, that explicitly authorize information flows]
159
[assignment: rules, based on security attributes, that explicitly deny information flows]
160
[selection: allocation of the resource to, deallocation of the resource from]
SFRs for [EAC2PP]
Versión 2.1.0 Página 95 de 158
3) Update package, decrypted update data and meta-data
uploaded to the TOE or generated during the update
procedure
4) none161
.
Application note 35: The functional family FDP_RIP possesses such a general character, so that
it is applicable not only to user data (as assumed by the class FDP), but also to TSF-data; in this
respect it is similar to the functional family FPT_EMS. Applied to cryptographic keys,
FDP_RIP.1/UPD requires a certain quality metric (‘any previous information content of a
resource is made unavailable’) for key destruction in addition to FCS_CKM.4 that merely requires
a fact of key destruction according to a method/standard. The update procedure is defined in
[GOA].
7.1.3.3. SFRs for [EAC2PP]
The following SFRs concern access control mechanisms related to user data.
FDP_ACC.1/TRM Subset access control – Terminal Access
Hierarchical to:
No other components.
Dependencies:
FDP_ACF.1 Security attribute based access control:
fulfilled by FDP_ACF.1/TRM
FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP162
on terminals
gaining access to the User Data and data stored in EF-011D
(Card Sec.) of the electronic document.163
and none.164
FDP_RIP.1/EAC2 Subset residual information protection
Hierarchical to:
No other components.
161
[assignment: list of objects]
162
[assignment: access control SFP]
163
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
164
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
SFRs for [EAC2PP]
Versión 2.1.0 Página 96 de 158
Dependencies:
No dependencies.
FDP_RIP.1.1/EAC2 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the
resource from165
the following objects:
1. Session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc)
(immediately after closing related communication session),
2. the ephemeral private key ephem - SKPICC- PACE (by having
generated a DH shared secret K),
3. secret electronic document holder authentication data, e.g.
PIN and/or PUK (when their temporarily stored values are
not used any more)166
Application note 36: The functional family FDP_RIP possesses such a general character, that it is
applicable not only to user data (as assumed by the class FDP), but also to TSF-Data; in this
respect it is similar to the functional family FPT_EMS. Applied to cryptographic keys,
FDP_RIP.1/EAC2 requires a certain quality metric (any previous information content of a
resource is made unavailable) for key destruction.
FDP_UCT.1/TRM Basic data exchange confidentiality – MRTD
Hierarchical to:
No other components.
Dependencies:
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
fulfilled by FTP_ITC.1/PACE
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/TRM
165
[selection: allocation of the resource to, deallocation of the resource from]
166
[assignment: list of objects]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 97 de 158
FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP167
to be able to
transmit and receive168
user data in a manner protected from
unauthorised disclosure.
FDP_UIT.1/TRM Data exchange integrity
Hierarchical to:
No other components.
Dependencies:
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
fulfilled by FTP_ITC.1/PACE
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/TRM
FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP169
to be able to
transmit and receive170
user data in a manner protected from
modification, deletion, insertion and replay171
errors.
FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion and replay172
has
occurred.
7.1.3.4. SFRs for [SSCDPP], [SSCDPP3] and [SSCDPP6]
The following SFRs are imported due to claiming [SSCDPP], [SSCDPP3] and [SSCDPP6]. They
concern access control mechanisms of an eSign application.
167
[assignment: access control SFP(s) and/or information flow control SFP(s)]
168
[selection: transmit, receive]
169
[assignment: access control SFP(s) and/or information flow control SFP(s)]
170
[selection: transmit, receive]
171
[selection: modification, deletion, insertion, replay]
172
[selection: modification, deletion, insertion, replay]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 98 de 158
The security attributes and related status for the subjects and objects are:
Subject or object the
security attribute is
associated with
Security attribute type
Value of the security
attribute
S.User Role
R.Admin,
R.Sigy
S.User SCD/SVD Management
authorised,
not authorised
SCD SCD Operational
no,
yes
SCD SCD identifier arbitrary value
SVD (This ST does not define
security attributes for SVD)
(This ST does not
define security
attributes for SVD)
FDP_ACC.1/SCD/SVD_Generation_SSCDPP Subset access control
Hierarchical to:
No other components.
Dependencies:
FDP_ACF.1 Security attribute based access control
fulfilled by FDP_ACF.1/SCD/SVD_Generation_SSCDPP
FDP_ACC.1.1/SCD/SVD_Generation_SSCDPP The TSF shall enforce the SCD/SVD Generation
SFP173
on
(1) subjects: S.User,
(2) objects: SCD, SVD,
(3) operations: generation of SCD/SVD pair174
.
173
[assignment: access control SFP]
174
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 99 de 158
FDP_ACF.1/SCD/SVD_Generation_SSCDPP Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCDPP
FMT_MSA.3 Static attribute initialization
fulfilled by FMT_MSA.3/SSCDPP
FDP_ACF.1.1/SCD/SVD_Generation_SSCDPP The TSF shall enforce the SCD/SVD Generation
SFP175
to objects based on the following: the
user S.User is associated with the security
attribute “SCD/SVD Management“176
.
FDP_ACF.1.2/SCD/SVD_Generation_SSCDPP The TSF shall enforce the following rules to
determine if an operation among controlled
subjects and controlled objects is allowed:
S.User with the security attribute “SCD/SVD
Management” set to “authorised” is allowed to
generate SCD/SVD pair177
.
FDP_ACF.1.3/SCD/SVD_Generation_SSCDPP The TSF shall explicitly authorise access of
subjects to objects based on the following
additional rules: none178
.
FDP_ACF.1.4/SCD/SVD_Generation_SSCDPP The TSF shall explicitly deny access of subjects
to objects based on the following additional
rules: S.User with the security attribute
“SCD/SVD management” set to “not
authorised” is not allowed to generate SCD/SVD
pair179
.
FDP_ACC.1/SVD_Transfer_SSCDPP Subset access control
175
[assignment: access control SFP]
176
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
177
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
178
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
179
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 100 de 158
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
fulfilled by FDP_ACF.1/SVD_Transfer_SSCDPP
FDP_ACC.1.1/SVD_Transfer_SSCDPP The TSF shall enforce the SVD Transfer SFP180
on
(1) subjects: S.User,
(2) objects: SVD
(3) operations: export.181
Application note 37: SVD export operation is allowed only for SVD generated by the TOE.
FDP_ACF.1/SVD_Transfer_SSCDPP Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/SVD_Transfer_SSCDPP
FMT_MSA.3 Static attribute initialisation
fulfilled by FMT_MSA.3/SSCDPP
FDP_ACF.1.1/SVD_Transfer_SSCDPP The TSF shall enforce the SVD Transfer SFP182
to
objects based on the following:
(1) the S.User is associated with the security
attribute Role,
(2) the SVD.183
FDP_ACF.1.2/SVD_Transfer_SSCDPP The TSF shall enforce the following rules to
determine if an operation among controlled
180
[assignment: access control SFP]
181
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
182
[assignment: access control SFP]
183
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 101 de 158
subjects and controlled objects is allowed:
R.Admin and R.Sigy is allowed to export SVD.184
FDP_ACF.1.3/SVD_Transfer_SSCDPP The TSF shall explicitly authorise access of
subjects to objects based on the following
additional rules: none185
.
FDP_ACF.1.4/SVD_Transfer_SSCDPP The TSF shall explicitly deny access of subjects
to objects based on the following additional
rules: none186
.
Application note 38: SVD export operation is allowed only for SVD generated by the TOE.
FDP_ACC.1/Signature_Creation_SSCDPP Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
fulfilled by FDP_ACF.1/Signature_Creation_SSCDPP
FDP_ACC.1.1/Signature_Creation_SSCDPP The TSF shall enforce the Signature Creation
SFP187
on
(1) subjects: S.User,
(2) objects: DTBS/R, SCD,
(3) operations: signature creation188
.
FDP_ACF.1/Signature_Creation_SSCDPP Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/Signature_Creation_SSCDPP
184
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]]
185
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
186
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
187
[assignment: access control SFP]
188
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 102 de 158
FMT_MSA.3 Static attribute initialisation
fulfilled by FMT_MSA.3/SSCDPP
FDP_ACF.1.1/Signature_Creation_SSCDPP The TSF shall enforce the Signature Creation
SFP189
to objects based on the following:
(1) the user S.User is associated with the
security attribute “Role” and
(2) the SCD with the security attribute “SCD
Operational”190
.
FDP_ACF.1.2/Signature_Creation_SSCDPP The TSF shall enforce the following rules to
determine if an operation among
controlled subjects and controlled objects is
allowed:
R.Sigy is allowed to create electronic signatures
for DTBS/R with SCD which security attribute
“SCD operational” is set to “yes”191
.
FDP_ACF.1.3/Signature_Creation_SSCDPP The TSF shall explicitly authorise access of
subjects to objects based on the following
additional rules: none192
.
FDP_ACF.1.4/Signature_Creation_SSCDPP The TSF shall explicitly deny access of subjects
to objects based on the following additional
rules:
S.User is not allowed to create electronic
signatures for DTBS/R with SCD which security
attribute “SCD operational” is set to “no”193
.
FDP_RIP.1/SSCDPP Subset residual information protection
Hierarchical to: No other components.
189
[assignment: access control SFP]
190
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
191
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
192
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
193
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
SFRs for [SSCDPP], [SSCDPP3] and
[SSCDPP6]
Versión 2.1.0 Página 103 de 158
Dependencies: No dependencies.
FDP_RIP.1.1/SSCDPP The TSF shall ensure that any previous information content of a
resource is made unavailable upon the de-allocation of the
resource from194
the following objects: SCD195
.
The following data persistently stored by the TOE shall have the user data attribute "integrity
checked persistent stored data":
1. SCD
2. SVD (if persistently stored by the TOE).
The DTBS/R temporarily stored by the TOE has the user data attribute "integrity checked stored
data".
FDP_SDI.2/Persistent_SSCDPP Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring.
Dependencies: No dependencies.
FDP_SDI.2.1/Persistent_SSCDPP The TSF shall monitor user data stored in containers
controlled by the TSF for integrity error196
on all objects,
based on the following attributes: integrity checked
stored data197
.
FDP_SDI.2.2/Persistent_SSCDPP Upon detection of a data integrity error, the TSF shall
(1) prohibit the use of the altered data
(2) inform the S.Sigy about integrity error198
.
FDP_SDI.2/DTBS_SSCDPP Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring.
Dependencies: No dependencies.
FDP_SDI.2.1/DTBS_SSCDPP The TSF shall monitor user data stored in containers
controlled by the TSF for integrity error199
on all objects,
194
[selection: allocation of the resource to, deallocation of the resource from]
195
[assignment: list of objects]
196
[assignment: integrity errors]
197
[assignment: user data attributes]
198
[assignment: action to be taken]
199
[assignment: integrity errors]
SFRs for [SSCDPP3]
Versión 2.1.0 Página 104 de 158
based on the following attributes: integrity checked
stored DTBS200
.
FDP_SDI.2.2/DTBS_SSCDPP Upon detection of a data integrity error, the TSF shall (1)
prohibit the use of the altered data
(2) inform the S.Sigy about integrity error201
.
7.1.3.5. SFRs for [SSCDPP3]
FDP_ACC.1/SCD_Import_SSCDPP3 Subset access control
Hierarchical to:
No other components.
Dependencies:
FDP_ACF.1 Security attribute based access control
fulfilled by FDP_ACF.1/SCD_Import_SSCDPP3
FDP_ACC.1.1/SCD_Import_SSCDPP3 The TSF shall enforce the SCD Import SFP202
on
(1) subjects: S.User,
(2) objects: SCD,
(3) operations: import of SCD203
.
FDP_ACF.1/SCD_Import_SSCDPP3 Security attribute based access control
Hierarchical to:
No other components.
Dependencies:
FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/SCD_Import_SSCDPP3
FMT_MSA.3 Static attribute initialization
200
[assignment: user data attributes]
201
[assignment: action to be taken]
202
[assignment: access control SFP]
203
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
SFRs for [SSCDPP3]
Versión 2.1.0 Página 105 de 158
fulfilled by FMT_MSA.3/SSCDPP
FDP_ACF.1.1/SCD_Import_SSCDPP3 The TSF shall enforce the SCD Import SFP204
to objects
based on the following: the S.User is associated with the
security attribute “SCD/SVD Management”205
.
FDP_ACF.1.2/SCD_Import_SSCDPP3 The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled
objects is allowed: S.User with the security attribute
“SCD/SVD Management” set to “authorised” is allowed
to import SCD206
.
FDP_ACF.1.3/SCD_Import_SSCDPP3 The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: none207
.
FDP_ACF.1.4/SCD_Import_SSCDPP3 The TSF shall explicitly deny access of subjects to objects
based on the following additional rules: S.User with the
security attribute “SCD/SVD management” set to “not
authorised” is not allowed to import SCD208
.
FDP_ITC.1/SCD_SSCDPP3 Import of user data without security attributes
Hierarchical to:
No other components.
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/SCD_Import_SSCDPP3
FMT_MSA.3 Static attribute initialization
fulfilled by FMT_MSA.3/SSCDPP
204
[assignment: access control SFP]
205
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
206
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
207
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
208
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
SFRs for [SSCDPP4]
Versión 2.1.0 Página 106 de 158
FDP_ITC.1.1/SCD_SSCDPP3 The TSF shall enforce the SCD Import SFP209
when importing user
data, controlled under the SFP, from outside of the TOE.
FDP_ITC.1.2/SCD_SSCDPP3 The TSF shall ignore any security attributes associated with the
user data SCD when imported from outside the TOE.
FDP_ITC.1.3/SCD_SSCDPP3 The TSF shall enforce the following rules when importing user
data controlled under the SFP from outside the TOE: the SCD
shall be sent by an authorized trusted IT environment210
.
FDP_UCT.1/SCD_SSCDPP3 Basic data exchange confidentiality
Hierarchical to:
No other components.
Dependencies:
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
fulfilled by FTP_ITC.1/SCD_SSCDPP3
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/SCD_Import_SSCDPP3
FDP_UCT.1.1/SCD_SSCDPP3 The TSF shall enforce the SCD Import SFP211
to receive212
user
data SCD in a manner protected from unauthorised disclosure.
Application note 39: The component FDP_UCT.1/SCD_SSCDPP3 requires the TSF to ensure the
confidentiality of the SCD during import. The refinement substituting “user data” by “SCD”
highlights that confidentiality of other imported user data like DTBS is not required.
7.1.3.6. SFRs for [SSCDPP4]
209
[assignment: access control SFP(s) and/or information flow control SFP(s)]
210
[assignment: additional importation control rules]
211
[assignment: access control SFP(s) and/or information flow control SFP(s)]
212
[selection: transmit, receive]
SFRs for [SSCDPP5] and [SSCDPP6]
Versión 2.1.0 Página 107 de 158
FDP_DAU.2/SVD_SSCDPP4 Data Authentication with Identity of Guarantor
Hierarchical to: FDP_DAU.1 Basic Data Authentication
Dependencies: FIA_UID.1 Timing of identification
fulfilled by FIA_UID.1/SSCDPP
FDP_DAU.2.1/SVD _SSCDPP4 The TSF shall provide a capability to generate evidence
that can be used as a guarantee of the validity of SVD213
.
FDP_DAU.2.2/SVD_SSCDPP4 The TSF shall provide CGA214
with the ability to verify
evidence of the validity of the indicated information and
the identity of the user that generated the evidence.
7.1.3.7. SFRs for [SSCDPP5] and [SSCDPP6]
FDP_UIT.1/DTBS_SSCDPP5 Data exchange integrity
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control,
or FDP_IFC.1 Subset information flow control.
fulfilled by FDP_ACC.1/Signature_Creation_SSCDPP
FTP_ITC.1 Inter-TSF trusted channel
or FTP_TRP.1 Trusted path.
fulfilled by FTP_ITC.1/DTBS_SSCDPP5
FDP_UIT.1.1/DTBS_SSCDPP5 The TSF shall enforce the Signature Creation SFP215
to
receive216
user data in a manner protected from
modification and insertion217
errors.
FDP_UIT.1.2/DTBS_SSCDPP5 The TSF shall be able to determine on receipt of user
data, whether modification and insertion218
has
occurred.
213
[assignment: list of objects or information types]
214
[assignment: list of subjects]
215
[assignment: access control SFP(s) and/or information flow control SFP(s)]
216
[selection: transmit, receive]
217
[selection: modification, deletion, insertion, replay]
218
[selection: modification, deletion, insertion, replay]
Class FTP
Versión 2.1.0 Página 108 de 158
7.1.4. Class FTP
7.1.4.1. SFRs for [MR.ED-ON-PP]
FTP_ITC.1/UPD Inter-TSF trusted Channel
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FTP_ITC.1.1/UPD The TSF shall provide a communication channel between itself
and another trusted IT product an update terminal219
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/UPD The TSF shall permit an update terminal220
to initiate
communication via the trusted channel.
FTP_ITC.1.3/UPD The TSF shall initiate enforce communication via the trusted
channel for any data exchange between the TOE and the update
terminal.221
7.1.4.2. SFRs for [EAC2PP]
FTP_ITC.1/PACE Inter-TSF trusted channel after PACE
Hierarchical to:
219
[selection: the TSF, another trusted IT product]
220
[selection: the TSF, another trusted IT product]
221
[assignment: list of functions for which a trusted channel is required]
SFRs for [EAC2PP]
Versión 2.1.0 Página 109 de 158
No other components.
Dependencies:
No dependencies.
FTP_ITC.1.1/PACE The TSF shall provide a communication channel between itself
and another trusted IT product a PACE terminal 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 trusted
channel shall be established by performing the PACE protocol
according to [TR03110-2].
FTP_ITC.1.2/PACE The TSF shall permit a PACE terminal222
to initiate
communication via the trusted channel.
FTP_ITC.1.3/PACE The TSF shall initiate enforce communication via the trusted
channel for any data exchange between the TOE and a PACE
terminal after PACE.223
Application note 40: The above definition refines FTP_ITC.1 from [CC]. The definitions there are
unclear as to what the “other trusted IT product” actually is. Since we distinguish here between
trusted channels that are established once after PACE, and then then (re)established after CA2,
the above refinement is necessary for clarification.
FTP_ITC.1/CA2 Inter-TSF trusted channel after CA2
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FTP_ITC.1.1/CA2 The TSF shall provide a communication channel between itself
and another trusted IT product an EAC2 terminal 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 trusted
channel shall be established by performing the CA2 protocol
according to [TR03110-2].
222
[selection: the TSF, another trusted IT product]
223
[assignment: list of functions for which a trusted channel is required]
SFRs for [SSCDPP3]
Versión 2.1.0 Página 110 de 158
FTP_ITC.1.2/CA2 The TSF shall permit another trusted IT product an EAC2
terminal224
to initiate communication via the trusted channel.
FTP_ITC.1.3/CA2 The TSF shall initiate enforce communication via the trusted
channel for any data exchange between the TOE and an EAC2
terminal after Chip Authentication 2.225
Application note 41: The trusted channel is established after successful performing the PACE
protocol (FIA_UAU.1/PACE), the TA2 protocol (FIA_UAU.1/EAC2_Terminal) and the CA2
protocol (FIA_API.1/CA). If Chip Authentication 2 was successfully performed, secure messaging
is immediately restarted using the derived session keys (CA-KMAC, CA-KEnc)226
. This secure
messaging enforces the required properties of operational trusted channel; the cryptographic
primitives being used for the secure messaging are as required by FCS_COP.1/PACE_ENC and
FCS_COP.1/PACE_MAC.
7.1.4.3. SFRs for [SSCDPP3]
The following SFRs is imported due to claiming [SSCDPP3].
FTP_ITC.1/SCD_SSCDPP3 Inter-TSF trusted channel
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FTP_ITC.1.1/SCD_SSCDPP3 The TSF shall provide a communication channel between itself
and another trusted IT product that is logically distinct from
other communication channels and provides assured
identification of its end points and protection of the channel
data from modification or disclosure.
FTP_ITC.1.2/SCD_SSCDPP3 The TSF shall permit another trusted IT product227
to initiate
communication via the trusted channel.
FTP_ITC.1.3/SCD_SSCDPP3 The TSF shall initiate communication via the trusted channel for:
224
[selection: the TSF, another trusted IT product]
225
[assignment: list of functions for which a trusted channel is required]
226
otherwise secure messaging is continued using the established PACE session keys, cf. FTP_ITC.1/PACE
227
[selection: the TSF, another trusted IT product]
SFRs for [SSCDPP4]
Versión 2.1.0 Página 111 de 158
(1) Data exchange integrity according to
FDP_UCT.1/SCD_SSCDPP3,
(2) none228
.
Application note 42: The component FPT_ITC.1 requires the TSF to support a trusted channel
established to another trusted IT product generating the SCD/SVD pair for import the SCD as
described by FDP_UCT.1/SCD_SSCDPP3. The ST writer shall perform the missing operations in
the element FTP_ITC.1.3/SCD_SSCDPP3. If the TSF does not enforce the use of trusted channel
for other functions the operation in the element FTP_ITC.1.3/SCD_SSCDPP3 is “none”.
7.1.4.4. SFRs for [SSCDPP4]
The following SFRs is imported due to claiming [SSCDPP4].
FTP_ITC.1/SVD_SSCDPP4 Inter-TSF trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/SVD_SSCDPP4 The TSF shall provide a communication channel between itself
and another trusted IT product CGA 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_SSCDPP4 The TSF shall permit another trusted IT product229
to initiate
communication via the trusted channel.
FTP_ITC.1.3/SVD_SSCDPP4 The TSF or the CGA shall initiate communication via the trusted
channel for
1) data Authentication with Identity of Guarantor according to
FIA_API.1/SSCDPP4 and FDP_DAU.2/SVD_SSCDPP4,
2) signature verification and VAD verification230
.
Application note 43: The component FPT_ITC.1/SVD_SSCDPP4 requires the TSF to enforce a
trusted channel established by the CGA to export the SVD to the CGA. The ST has performed the
missing operations in the element FTP_ITC.1.3/SVD_SSCDPP4.
Application note 44: If the ST writer requires the TSF to support (not to enforce) a trusted
channel established by the CGA to export the SVD to the CGA than he or she shall use the
228
[assignment: list of functions for which a trusted channel is required]
229
[selection: the TSF, another trusted IT product ]
230
[assignment: list of functions for which a trusted channel is required]
SFRs for [SSCDPP5] and [SSCDPP6]
Versión 2.1.0 Página 112 de 158
[SSCDPP] and include a similar component FPT_ITC.1/SVD_SSCDPP4 with assignment “none” in
the element FPT_ITC.1.3/SVD_SSCDPP4.
7.1.4.5. SFRs for [SSCDPP5] and [SSCDPP6]
The following SFRs are imported due to claiming [SSCDPP5] and [SSCDPP6].
FTP_ITC.1/VAD_SSCDPP5 Inter-TSF trusted channel – TC Human Interface Device
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/VAD_SSCDPP5 The TSF shall provide a communication channel between itself
and another trusted IT product HID 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/VAD_SSCDPP5 The TSF shall permit the remote trusted IT product231
to initiate
communication via the trusted channel.
FTP_ITC.1.3/VAD_SSCDPP5 The TSF or the HID shall initiate communication via the trusted
channel for
(1) User authentication according to FIA_UAU.1/SSCDPP,
(2) signature verification and SVD export232
.
Application note 45: The component FTP_ITC.1/VAD_SSCDPP5 requires the TSF to support a
trusted channel established by the HID to send the VAD. The ST writer has performed the missing
operations in the element FTP_ITC.1.3/VAD_SSCDPP5. Note the VAD needs protection
depending on the authentication methods employed: VAD for authentication by knowledge
needs protection in confidentiality; VAD for biometric authentication may need protection in
integrity only.
FTP_ITC.1/DTBS_SSCDPP5 Inter-TSF trusted channel – Signature creation Application
Hierarchical to: No other components.
Dependencies: No dependencies.
231
[selection: the TSF, another trusted IT product ]
232
[assignment: list of functions for which a trusted channel is required]
Class FAU
Versión 2.1.0 Página 113 de 158
FTP_ITC.1.1/DTBS_SSCDPP5 The TSF shall provide a communication channel between itself
and another trusted IT product SCA that is logically distinct from
other communication channels and provides assured
identification of its end points and protection of the channel
data from modification or disclosure.
FTP_ITC.1.2/DTBS_SSCDPP5 The TSF shall permit the remote trusted IT product233
to initiate
communication via the trusted channel.
FTP_ITC.1.3/DTBS_SSCDPP5 The TSF or the SCA shall initiate communication via the trusted
channel for
(1) signature creation
(2) signature verification and SVD export234
.
Application note 46: The component FTP_ITC.1/DTBS_SSCDPP5 requires the TSF to support a
trusted channel established by the SCA to send the DTBS. The ST writer has performed the
missing operations in the element FTP_ITC.1.3/DTBS_SSCDPP5.
7.1.5. Class FAU
7.1.5.1. SFRs for [MR.ED-ON-PP]
FAU_SAS.1/UPD Audit Storage of Update History
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FAU_SAS.1.1/UPD The TSF shall provide the TOE update functionality235
with the
capability to store update log information and version history,
namely the following data objects: OS version coded on the ATR,
233
[selection: the TSF, another trusted IT product ]
234
[assignment: list of functions for which a trusted channel is required]
235
[assignment: authorized users]
SFRs for [EAC2PP]
Versión 2.1.0 Página 114 de 158
hash of the OS loaded retrieved on the Get Chip Info APDU236
in
the audit records.
Justification: According to [CC], a PP author is allowed to refine an SFR to apply to some, but not
all subjects. The refinement of this SFR is such an exception, since the TOE update functionality
is technically not an authorized user. Hence, the refinement is justified.
Note FAU_SAS.1 from [MR.ED-PP] applies as well. The SFR here is a new iteration refining the
definition of [CC] and is only concerned with the TOE update functionality.
7.1.5.2. SFRs for [EAC2PP]
FAU_SAS.1/EAC2 Audit storage
Hierarchical to:
No other components
Dependencies:
No dependencies
FAU_SAS.1.1/EAC2 The TSF shall provide the Manufacturer237
with the capability to
store the Initialization and Pre-personalization Data238
in the
audit records.
Application note 47: The Manufacturer role is the default user identity assumed by the TOE in
the life cycle phase ‘manufacturing’. The IC manufacturer and the electronic document
manufacturer in the Manufacturer role write the Initialization and/or Pre-personalization Data
as TSF-data into the TOE. The audit records are usually write-only-once data of the electronic
document (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also
be such audit records which cannot be read out, but directly used by the TOE.
236
[assignment: list of audit information]
237
[assignment: authorised users]
238
[assignment: list of audit information]
Class FMT
Versión 2.1.0 Página 115 de 158
7.1.6. Class FMT
7.1.6.1. SFRs for [MR.ED-PP]
FMT_SMR.1 Security roles
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/PACE, FIA_UID.1/EAC2_Terminal, see also the Application Note
below.
FMT_SMR.1.1 The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Company Verifying Certification Authority,
4. Document Verifier,
5. Terminal,
6. PACE terminal,
7. EAC2 terminal, if the eSign application is active,
8. Electronic document holder.239
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
The following SFRs concern loading applications onto the IC during manufacturing and relate
directly to OT.Cap_Avail_Loader.
FMT_LIM.1/Loader Limited Capabilities
Hierarchical to:
No other components
Dependencies:
239
[assignment: the authorized identified roles]
SFRs for [MR.ED-PP]
Versión 2.1.0 Página 116 de 158
FMT_LIM.2/Loader Limited availability
fulfilled by FMT_LIM.2/Loader
FMT_LIM.1.1/Loader
The TSF shall be designed and implemented in a manner that limits their capabilities so
that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is
enforced: Deploying Loader functionality after delivery240
does not allow stored user
data to be disclosed or manipulated by unauthorized users.241
Application note 48: FMT_LIM.1/Loader supplements FMT_LIM.2/Loader allowing for non-
overlapping loading of user data and protecting the TSF against misuses of the Loader for attacks
against the TSF. The TOE Loader may allow for correction of already loaded user data before the
assigned action e.g. before blocking the TOE Loader for TOE Delivery to the end-customer or any
intermediate step on the life cycle of the Security IC or the smartcard.
FMT_LIM.2/Loader Limited Availability
Hierarchical to:
No other components
Dependencies:
FMT_LIM.1/Loader Limited capabilities
fulfilled by FMT_LIM.1/Loader
FMT_LIM.2.1/Loader
The TSF shall be designed and implemented in a manner that limits their availability so
that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is
enforced: The TSF prevents deploying the Loader functionality after blocking of the
loader.242
Application note 49: The Loader functionality relies on a secure boot loading procedure in a
secure environment before TOE delivery to the assigned user and preventing to deploy the
Loader of the Security IC after an assigned action, e.g. after blocking the Loader for TOE delivery
to the end-user.
240
[assignment: action]
241
[assignment: Limited capability and availability policy]
242
[assignment: Limited capability and availability policy]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 117 de 158
7.1.6.2. SFRs for [MR.ED-ON-PP]
FMT_SMF.1/UPD Specification of Management Functions including Updates
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FMT_SMF.1.1/UPD The TSF shall be capable of performing the following
management functions:
1) Updating the TOE software with the mechanism specified in
[GOA]243 244
.
FMT_MTD.1/UPD_SK_PICC Management of TSF Data – Secret Update Keys
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions:
fulfilled by FMT_SMF.1/UPD
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/UPD
FMT_MTD.1.1/UPD_SK_PICC The TSF shall restrict the ability to create, load245
the session
update keys246
to the update key installation agent247
.
243
[assignment: list of technical specification(s) defining an update mechanism]
244
[assignment: list of management functions to be provided by the TSF]
245
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
246
[assignment: list of TSF data]
247
[assignment: the authorized identified roles]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 118 de 158
FMT_MTD.1/UPD_KEY_READ Management of TSF data – Secret Update Keys
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/UPD
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/UPD
FMT_MTD.1.1/UPD_KEY_READ The TSF shall restrict the ability to read248
the
1) Update keys249
2) Any data involved in the updating.250
to none251
.
FMT_SMR.1/UPD Security roles
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/UPD
FMT_SMR.1.1/UPD The TSF shall maintain the roles
1) terminal,
2) update terminal
3) update key installation agent
248
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
249
[assignment: list of or reference specifying the Secret Cryptographic Update Keys required for the
update procedure]
250
[assignment: list of TSF data]
251
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 119 de 158
4) Administrator252
FMT_SMR.1.2/UPD The TSF shall be able to associate users with roles.
7.1.6.3. SFRs for [EAC2PP]
FMT_MTD.1/CVCA_INI Management of TSF data – Initialization of CVCA
Certificate and Current Date
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions:
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles:
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/CVCA_INI The TSF shall restrict the ability to write253
the
1. initial CVCA Public Key,
2. meta-data of the initial CVCA Certificate as required
in [TR03110-2], resp. [TR03110-3],
3. initial Current Date254
to the manufacturer255
.
Application note 50: The initial CVCA Public Key may be written by the manufacturer in the
manufacturing phase or by the personalization agent in the issuing phase (cf. [TR03110-2]). The
initial CVCA Public Keys and their updates later on are used to verify the CVCA Link-Certificates.
252
[assignment: the authorized identified roles]
253
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
254
[assignment: list of TSF data]
255
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 120 de 158
FMT_MTD.1/CVCA_UPD Management of TSF data – Company Verifying
Certification Authority
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/CVCA_UPD The TSF shall restrict the ability to update256
the
1. CVCA Public Key (PKCVCA),
2. meta-data of the CVCA Certificate as required by
[TR03110-2] , resp. [TR03110-3]257
to the Company Verifying Certification Authority.258
Application note 51: The CVCA updates its asymmetric key pair and distributes the public key
and related meta-data by means of CVCA Link-Certificates. The TOE updates its internal trust-
point, if a valid CVCA Link-Certificate (cf. FMT_MTD.3/EAC2) is provided by the terminal (cf.
[TR03110-3]).
FMT_SMF.1/EAC2 Specification of Management Functions
Hierarchical to:
No other components.
Dependencies:
No dependencies.
256
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
257
[assignment: list of TSF data]
258
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 121 de 158
FMT_SMF.1.1/EAC2 The TSF shall be capable of performing the following
management functions:
1. Initialization,
2. Pre-Personalization,
3. Personalization,
4. Configuration,
5. Resume and unblock the PIN (if any),
6. Activate and deactivate the PIN (if any)259
.
Application note 52: The capability of PIN management gives additional security to the TOE.
FMT_SMR.1/PACE Security roles
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/PACE, FIA_UID.1/EAC2_Terminal, see also the Application Note
below
FMT_SMR.1.1/PACE The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Company Verifying Certification Authority,
4. Document Verifier,
5. Terminal,
6. PACE terminal,
7. EAC2 terminal, if theeSign application is active,
8. Electronic document holder.260
FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles.
Application Note 53: The role terminal is the default role for any terminal being recognized by
the TOE as neither PACE terminal nor EAC2 terminal. The roles CVCA, DV, and EAC2 terminal are
recognized by analyzing the current Terminal Certificate, cf. [TR03110-2],
(FIA_UAU.1/EAC2_Terminal). Specific types of EAC2 terminals are identified analogously. The
259
[assignment: list of management functions to be provided by the TSF]
260
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 122 de 158
TOE recognizes the electronic document holder by using a PACE terminal together with inputs
PIN or PUK (FIA_UAU.1/PACE).
FMT_MTD.1/DATE Management of TSF data – Current date
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE_EAC2
FMT_MTD.1.1/DATE The TSF shall restrict the ability to modify261
the current
date262
to
1. CVCA,
2. Document Verifier
3. EAC2 terminal (Inspection system, authentication
terminal, signature terminal) possessing an
Accurate Terminal Certificate according to
[TR03110-3]263
.
Application note 54: The authorized roles are identified in their certificates (cf. [TR03110-2]) and
are authorized by validating the certificate chain up to the CVCA (cf. FMT_MTD.3). The
authorized role of a terminal is part of the Certificate Holder Authorization in the card verifiable
certificate that is provided by the terminal within Terminal Authentication 2 (cf. [TR03110-3]).
FMT_MTD.1/PA Management of TSF data – Personalization Agent
Hierarchical to:
No other components.
Dependencies:
261
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
262
[assignment: list of TSF data]
263
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 123 de 158
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/PA The TSF shall restrict the ability to write264
the card/chip
security object(s) (SOC) and the Chip Authenticate public
key signature (EF-011D)265
to the Personalization
Agent266
.
Application note 55: Note that the card/chip security objects are mentioned here as well. These
contain information, such as algorithm identifiers, only necessary for EAC2.
FMT_MTD.1/SK_PICC Management of TSF data – Chip Authentication and
Restricted Identification Private Key(s)
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions:
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE_EAC2
FMT_MTD.1.1/SK_PICC The TSF shall restrict the ability to create, load267
the
Chip Authentication private key(s) (SKPICC) to the
Personalization Agent268
.
264
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
265
[assignment: list of TSF data]
266
[assignment: the authorized identified roles]
267
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
268
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 124 de 158
Application note 56: The component FMT_MTD.1/SK_PICC is refined by (i) selecting other
operations and (ii) defining a selection for the operations ‘create’ and ‘load’. The verb ‘load’
means here that the Chip Authentication private key(s) are securely generated outside the TOE
and written into the TOE memory. The verb ‘create’ means here that the Chip Authentication
private key(s) are generated by the TOE itself.
FMT_MTD.1/KEY_READ Management of TSF data – Private Key Read
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read269
the
1. PACE passwords,
2. Personalization Agent Keys,
3. the Chip Authentication private key(s) (SKPICC)270
to none271
.
FMT_MTD.1/Initialize_PIN Management of TSF data – Initialize PIN
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
269
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
270
[assignment: list of TSF data]
271
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 125 de 158
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/Initialize_PIN The TSF shall restrict the ability to write272
the
initial PIN and PUK273
to the personalization
agent274
.
FMT_MTD.1/Change_PIN Management of TSF data – Changing PIN
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/Change_PIN The TSF shall restrict the ability to change275
the
blocked PIN276
to the authorised identified roles
that match the list of PIN changing rules
conformant to [TR03110-2]]277
FMT_MTD.1/Resume_PIN Management of TSF data – Resuming PIN
Hierarchical to:
No other components.
Dependencies:
272
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
273
[assignment: list of TSF data]
274
[assignment: the authorized identified roles]
275
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
276
[assignment: list of TSF data]
277
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 126 de 158
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE_EAC2
FMT_MTD.1.1/Resume_PIN The TSF shall restrict the ability to resume278
the
suspended PIN279
to the electronic document
holder280
.
Application note 57: Resuming is a two-step procedure, subsequently using PACE with the CAN
and PACE with the PIN. It must be implemented according to [TR03110-2], and is relevant for
the status as required by FIA_AFL.1/Suspend_PIN. The electronic document holder is
authenticated as required by FIA_UAU.1/PACE using the PIN as the shared password.
FMT_MTD.1/Unblock_PIN Management of TSF data – Unblocking PIN
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE_EAC2
FMT_MTD.1.1/Unblock_PIN The TSF shall restrict the ability to unblock281
the
blocked PIN282
to
278
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
279
[assignment: list of TSF data]
280
[assignment: the authorized identified roles]
281
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
282
[assignment: list of TSF data]
SFRs for [EAC2PP]
Versión 2.1.0 Página 127 de 158
1. the electronic document holder (using the
PUK for unblocking),
2. an EAC2 terminal of a type that has the
terminal authorization level for PIN
management.283
Application note 58: The unblocking procedure must be implemented according to [TR03110-
2], and is relevant for the status as required by FIA_AFL.1/Block_PIN. It can be triggered by either
(i) the electronic document holder being authenticated as required by FIA_UAU.1/PACE using
the PUK as the shared password or (ii) an EAC2 terminal (FIA_UAU.1/EAC2_Terminal) that
proved a terminal authorization level being sufficient for PIN management (FDP_ACF.1/TRM).
FMT_MTD.1/Activate_PIN Management of TSF data –
Activating/Deactivating PIN
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/Activate_PIN The TSF shall restrict the ability to activate and
deactivate284
the PIN285
to an EAC2 terminal of a
type that has the terminal authorization level for
PIN management286
.
Application note 59: The activation/deactivation procedures must be implemented according to
[TR03110-2]. They can be triggered by an EAC2 terminal (FIA_UAU.1/EAC2_Terminal) that
proved a terminal authorization level sufficient for PIN management (FDP_ACF.1/TRM).
283
[assignment: the authorized identified roles]
284
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
285
[assignment: list of TSF data]
286
[assignment: the authorized identified roles]
SFRs for [EAC2PP]
Versión 2.1.0 Página 128 de 158
FMT_MTD.3/EAC2 Secure TSF data
Hierarchical to:
No other components.
Dependencies:
FMT_MTD.1 Management of TSF data
fulfilled by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and FMT_MTD.1/DATE
FMT_MTD.3.1/EAC2 The TSF shall ensure that only secure values of the certificate
chain are accepted for TSF data of the Terminal Authentication
protocol 2 and the Access Control SFP287
.
To determine if the certificate chain is valid, the TOE shall
proceed the certificate validation according to [TR03110-3].
Application note 60: Terminal Authentication is used as required by (i)
FIA_UAU.1/EAC2_Terminal and FIA_UAU.5/PACE. The terminal authorization level derived from
the CVCA Certificate, the DV Certificate and the Terminal Certificate is used as TSF-data for the
access control required by FDP_ACF.1/TRM.
FMT_MTD.1/INI_ENA Management of TSF data – Writing Initialisation and
Pre-personalisation Data
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions:
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles:
fulfilled by FMT_SMR.1/PACE_EAC2
287
[assignment: list of TSF data]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 129 de 158
FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write288
the
Initialisation Data and Pre-personalisation Data289
to
the Manufacturer.290
FMT_MTD.1/INI_DIS Management of TSF data – Reading and Using
Initialisation and Pre-personalisation Data
Hierarchical to:
No other components.
Dependencies:
FMT_SMF.1 Specification of management functions:
fulfilled by FMT_SMF.1/EAC2
FMT_SMR.1 Security roles:
fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to read out291
the
Initialisation Data and the Pre-personalisation Data292
to the Personalisation Agent.293
7.1.6.4. SFRs for [SSCDPP] and [SSCDPP3]
The following SFRs are imported due to claiming [SSCDPP] and [SSCDPP3]. They mostly concern
the security management of an eSign application.
FMT_SMR.1/SSCDPP Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
288
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
289
[assignment: list of TSF data]
290
[assignment: the authorised identified roles]
291
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
292
[assignment: list of TSF data]
293
[assignment: the authorised identified roles]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 130 de 158
fulfilled by FIA_UID.1/SSCDPP
FMT_SMR.1.1/SSCDPP The TSF shall maintain the roles R.Admin and R.Sigy294
.
FMT_SMR.1.2/SSCDPP The TSF shall be able to associate users with roles.
FMT_SMF.1/SSCDPP Security management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1/SSCDPP The TSF shall be capable of performing the following
management functions:
1. Creation and modification of RAD,
2. Enabling the signature creation function,
3. Modification of the security attribute SCD/SVD management,
SCD operational,
4. Change the default value of the security attribute SCD
Identifier,
5. none295
.
FMT_MOF.1/SSCDPP Management of security functions behaviour
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_SMF.1 Specification of Management Functions.
fulfilled by FMT_SMF.1/SSCDPP
FMT_MOF.1.1/SSCDPP The TSF shall restrict the ability to enable296
the functions
signature creation function297
to R.Sigy298
.
FMT_MSA.1/Admin_SSCDPP Management of security attributes
294
[assignment: the authorised identified roles]
295
[assignment: list of other security management functions to be provided by the TSF]
296
[selection: determine the behaviour of, disable, enable, modify the behaviour of]
297
[assignment: list of functions]
298
[assignment: the authorised identified roles]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 131 de 158
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCDPP
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_SMF.1 Specification of Management Functions
fulfilled by FMT_SMF.1/SSCDPP
FMT_MSA.1.1/Admin_SSCDPP The TSF shall enforce the SCD/SVD Generation SFP and
SCD Import SFP299
to restrict the ability to modify300
the
security attributes SCD/SVD management301
to
R.Admin302
.
FMT_MSA.1/Signatory_SSCDPP Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/Signature_Creation_SSCDPP
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_SMF.1 Specification of Management Functions
fulfilled by FMT_SMF.1/SSCDPP
299
[assignment: access control SFP(s), information flow control SFP(s)]
300
[selection: change_default, query, modify, delete, [assignment:other operations] ]
301
[assignment: list of security attributes]
302
[assignment: the authorised identified roles]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 132 de 158
FMT_MSA.1.1/Signatory_SSCDPP The TSF shall enforce the Signature Creation SFP303
to
restrict the ability to modify304
the security attributes
SCD operational305
to R.Sigy306
.
FMT_MSA.2/SSCDPP Secure security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCDPP
and FDP_ACC.1/Signature_Creation_SSCDPP
FMT_MSA.1 Management of security attributes
fulfilled by FMT_MSA.1/Admin_SSCDPP and
FMT_MSA.1/Signatory_SSCDPP
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_MSA.2.1/SSCDPP The TSF shall ensure that only secure values are
accepted for SCD/SVD Management and SCD
operational307
.
FMT_MSA.3/SSCDPP Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
fulfilled by FMT_MSA.1/Admin_SSCDPP and
FMT_MSA.1/Signatory_SSCDPP
FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
303
[assignment: access control SFP(s), information flow control SFP(s)]
304
[selection: change_default, query, modify, delete, [assignment: other operations]]
305
[assignment: list of security attributes]
306
[assignment: the authorised identified roles]
307
[selection: list of security attributes]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 133 de 158
FMT_MSA.3.1/SSCDPP The TSF shall enforce the SCD/SVD Generation SFP, SVD Transfer
SFP, SCD Import SFP and Signature Creation SFP308
to provide
restrictive309
default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2/SSCDPP The TSF shall allow the R.Admin310
to specify alternative initial
values to override the default values when an object or
information is created.
FMT_MSA.4/SSCDPP Security attribute value inheritance
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCDPP and
FDP_ACC.1/Signature_Creation_SSCDPP
FMT_MSA.4.1/SSCDPP The TSF shall use the following rules to set the value of security
attributes:
(1) If S.Admin successfully generates an SCD/SVD pair without
S.Sigy being authenticated the security attribute “SCD
operational of the SCD” shall be set to “no” as a single operation.
(2) If S.Sigy successfully generates an SCD/SVD pair the security
attribute “SCD operational of the SCD” shall be set to “yes” as a
single operation311
.
(3) If S.Admin imports SCD while S.Sigy is not currently
authenticated, the security attribute “SCD operational” of the
SCD shall be set to “no” after import of the SCD as a single
operation.
(4) If S.Admin imports SCD while S.Sigy is currently
authenticated, the security attribute “SCD operational” of the
308
[assignment: access control SFP, information flow control SFP]
309
[selection, choose one of: restrictive, permissive, [assignment: other property] ]
310
[assignment: the authorised identified roles]
311
[assignment: rules for setting the values of security attributes]
SFRs for [SSCDPP] and [SSCDPP3]
Versión 2.1.0 Página 134 de 158
SCD shall be set to “yes” after import of the SCD as a single
operation.312
FMT_MTD.1/Admin_SSCDPP Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_SMF.1 Specification of Management Functions
fulfilled by FMT_SMF.1/SSCDPP
FMT_MTD.1.1/Admin_SSCDPP The TSF shall restrict the ability to create313
the RAD314
to R.Admin315
.
FMT_MTD.1/Signatory_SSCDPP Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
fulfilled by FMT_SMR.1/SSCDPP
FMT_SMF.1 Specification of Management Functions
fulfilled by FMT_SMF.1/SSCDPP
FMT_MTD.1.1/Signatory_SSCDPP The TSF shall restrict the ability to modify and unblock316
the RAD317
to R.Sigy318
.
312
[assignment: rules for setting the values of security attributes]
313
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
314
[assignment: list of TSF data]
315
[assignment: the authorised identified roles]
316
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
317
[assignment: list of TSF data]
318
[assignment: the authorised identified roles]
Class FPT
Versión 2.1.0 Página 135 de 158
7.1.7. Class FPT
7.1.7.1. SFRs for [MR.ED-ON-PP]
FPT_EMS.1/UPD TOE Emanation
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FPT_EMS.1.1/UPD The TOE shall not emit electromagnetic and current emissions319
in excess of intelligible threshold320
enabling access to the
update keys321
and any user data322
.
FPT_EMS.1.2/UPD The TSF shall ensure any users323
are unable to use the following
interface electronic document ’s contactless/contact-based
interface and circuit contacts324
to gain access to the update keys
325
and any user data326
.
Application note 61: The TOE shall prevent attacks against the listed secret data where the attack
is based on external observable physical phenomena of the TOE. Such attacks may be observable
at the interfaces of the TOE, originate from internal operation of the TOE, or be caused by an
attacker that varies the physical environment under which the TOE operates. The set of
measurable physical phenomena is influenced by the technology employed to implement the
smart card. Examples of measurable phenomena include, but are not limited to variations in
power consumption, timing of signals, and electromagnetic radiation due to internal operations
or data transmissions.
319
[assignment: types of emissions]
320
[assignment: specified limits]
321
[assignment: list of types of TSF data]
322
[assignment: list of types of user data]
323
[assignment: type of users]
324
[assignment: type of connection]
325
[assignment: list of types of TSF data]
326
[assignment: list of types of user data]
SFRs for [MR.ED-ON-PP]
Versión 2.1.0 Página 136 de 158
Note that while the security functionality described in FPT_EMS.1/UPD should be taken into
account during development of the TOE, associated tests must be carried out as part of the
evaluation, and not/not only during product development.
FPT_FLS.1/UPD Failure with Preservation of Secure State (Failed Update)
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FPT_FLS.1.1/UPD The TSF shall preserve a secure state when the following types
of failures occur:
1) Failure during a transmission of the update package data file
2) Failure detected by TSF according to FPT_TST.1/UPD
3) Failure detected after a failed update327
4) Wrong digital signature328
.
Application note 62: The secure state after a failed update should be achieved by reverting to
the previous TOE software version. Nevertheless this capability will have limits, since the
atomicity of the software update mechanism can technically only be achieved up to a certain
extent.
FPT_TST.1/UPD TSF Testing (after Installation of an Update)
Hierarchical to:
No other components.
Dependencies:
No dependencies.
327
[assignment: list of types of failures in the TSF]
328
[assignment: list of types of failures in the TSF]
SFRs for [EAC2PP]
Versión 2.1.0 Página 137 de 158
FPT_TST.1.1/UPD The TSF shall run a suite of self tests during initial start-up329
to
demonstrate the correct operation of the TSF330
.
FPT_TST.1.2/UPD The TSF shall provide authorized users with the capability to
verify the integrity of the TSF data331
.
FPT_TST.1.3/UPD The TSF shall provide authorized users with the capability to
verify the integrity of stored TSF executable code332
.
7.1.7.2. SFRs for [EAC2PP]
The following security functional requirements address the protection against forced illicit
information leakage, including physical manipulation.
FPT_PHP.3/EAC2 Resistance to physical attack
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FPT_PHP.3.1/EAC2 The TSF shall resist physical manipulation and physical
probing333
to the TSF334
by responding automatically such that
the SFRs are always enforced.
Application note 63: The TOE will implement appropriate measures to continuously counter
physical manipulation and physical probing. Due to the nature of these attacks (especially
manipulation) the TOE can by no means detect attacks on all of its elements. Therefore,
permanent protection against these attacks is required ensuring that the TSP could not be
violated at any time. Hence, ‘automatic response’ means here (i) assuming that there might be
an attack at any time and (ii) countermeasures are provided at any time.
329
[selection: during initial start-up, periodically during normal operation, at the request of the authorised
user, at the conditions[assignment: conditions under which self test should occur]]
330
[selection: [assignment: parts of TSF], the TSF]
331
[selection: [assignment: parts of TSF data], TSF data]
332
[selection: [assignment: parts of TSF], TSF]
333
[assignment: physical tampering scenarios]
334
[assignment: list of TSF devices/elements]
SFRs for [SSCDPP]
Versión 2.1.0 Página 138 de 158
7.1.7.3. SFRs for [SSCDPP]
The following SFRs are imported due to claiming [SSCDPP]. They mostly concern the protection
of security functionality related to eSign application.
FPT_EMS.1/SSCDPP TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1/SSCDPP The TOE shall not emit electromagnetic and current emissions335
in excess of useless information336
enabling access to RAD337
and
SCD338
.
FPT_EMS.1.2/SSCDPP The TSF shall ensure attackers339
are unable to use the following
interface the contactless interface and circuit contacts340
to gain
access to RAD341
and SCD342
.
Application note 64: The TOE shall prevent attacks against the SCD and other secret data where
the attack is based on external observable physical phenomena of the TOE. Such attacks may be
observable at the interfaces of the TOE or may origin from internal operation of the TOE or may
origin by an attacker that varies the physical environment under which the TOE operates. The
set of measurable physical phenomena is influenced by the technology employed to implement
the TOE. Examples of measurable phenomena are variations in the power consumption, the
timing of transitions of internal states, electromagnetic radiation due to internal operation,
radio emission.
Due to the heterogeneous nature of the technologies that may cause such emanations,
evaluation against state-of-the-art attacks applicable to the technologies employed by the TOE
is assumed. Examples of such attacks are, but are not limited to, evaluation of TOE’s
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing
attacks, etc.
FPT_FLS.1/SSCDPP Failure with preservation of secure state
335
[assignment: types of emissions]
336
[assignment: specified limits]
337
[assignment: list of types of TSF data]
338
[assignment: list of additional types of user data]
339
[assignment: type of users]
340
[assignment: type of connection]
341
[assignment: list of types of (further) TSF data]
342
[assignment: list of types of user data]
SFRs for [SSCDPP]
Versión 2.1.0 Página 139 de 158
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1/SSCDPP The TSF shall preserve a secure state when the following types
of failures occur:
(1) self-test according to FPT_TST.1/SSCDPP fails,
(2) any communication protocol attack or sensor detection of
not detected parameters343
.
Application note 65: The ST writer has performed the missing assignment in the element
FPT_FLS.1.1/SSCDPP. The assignment (1) addresses failures detected by a failed self-test and
requiring appropriate action to prevent security violation. When the TOE is in a secure state the
TSF shall not perform any cryptographic operations and all data output interfaces shall be
inhibited by the TSF.
FPT_PHP.1/SSCDPP Passive detection of physical attack
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PHP.1.1/SSCDPP The TSF shall provide unambiguous detection of physical
tampering that might compromise the TSF.
FPT_PHP.1.2/SSCDPP The TSF shall provide the capability to determine whether
physical tampering with the TSF’s devices or TSF’s elements has
occurred.
FPT_PHP.3/SSCDPP Resistance to physical attack
(subsumed by FPT_PHP.3/EAC2)
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PHP.3.1/SSCDPP The TSF shall resist physical manipulation and physical
probing344
to the TSF345
by responding automatically such that
the SFRs are always enforced.
343
[assignment: list of types of failures in the TSF]
344
[assignment: physical tampering scenarios]
345
[assignment: list of TSF devices/elements]
Security Assurance Requirements for
the TOE
Versión 2.1.0 Página 140 de 158
Application note 66: The TOE will implement appropriate measures to continuously counter
physical tampering which may compromise the SCD. The “automatic response” in the element
FPT_PHP.3.1/SSCDPP means (i) assuming that there might be an attack at any time and (ii)
countermeasures are provided at any time. Due to the nature of these attacks the TOE can by
no means detect attacks on all of its elements (e.g. the TOE is destroyed). But physical tampering
must not reveal information of the SCD. E.g. the TOE may be physically tampered in power-off
state of the TOE (e.g. a smart card), which does not allow TSF for overwriting the SCD but leads
to physical destruction of the memory and all information therein about the SCD. In case of
physical tampering the TFS may not provide the intended functions for SCD/SVD pair generation
or signature creation but ensures the confidentiality of the SCD by blocking these functions. The
SFR FPT_PHP.1/SSCDPP requires the TSF to react on physical tampering in a way that the
signatory is able to determine whether the TOE was physical tampered or not. E.g. the TSF may
provide an appropriate message during start-up or the guidance documentation may describe a
failure of TOE start-up as indication of physical tampering.
FPT_TST.1/SSCDPP TSF testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1/SSCDPP The TSF shall run a suite of self tests during initial start-up before
any use of TSF data346
to demonstrate the correct operation of
the TSF347
.
FPT_TST.1.2/SSCDPP The TSF shall provide authorised users with the capability to
verify the integrity of TSF data348
.
FPT_TST.1.3/SSCDPP The TSF shall provide authorised users with the capability to
verify the integrity of TSF349
.
7.2. Security Assurance Requirements for the TOE
The assurance requirements for the evaluation of the TOE, its development and operating
environment are to choose as the predefined assurance package EAL4 augmented by the
following components:
- ALC_DVS.2 (Sufficiency of security measures),
- ATE_DPT.2 (Testing: security enforcing modules) and
- AVA_VAN.5 (Advanced methodical vulnerability analysis).
346
[selection: during initial start-up, periodically during normal operation, at the request of the authorised
user, at the conditions [assignment: conditions under which self-test should occur]]
347
[selection: [assignment: parts of TSF], the TSF]
348
[selection: [assignment: parts of TSF data], TSF data]
349
[selection: [assignment: parts of TSF], TSF]
Security Assurance Requirements for
the TOE
Versión 2.1.0 Página 141 de 158
Los requisitos de garantía de seguridad se justifican mediante la presentación a la evaluación de
los distintos documentos que acreditan el cumplimiento de los correspondientes requisitos.
Componente Documentos
ADV_ARC.1 Security architecture
description
Descripción de la arquitectura de seguridad
ADV_FSP.4 Complete functional
specification
Especificación funcional - Manual de comandos
ADV_IMP.1 Implementation
representation of the TSF
Código fuente y mapas de ficheros
ADV_TDS.3 Basic modular design Diseño
AGD_OPE.1 Operational user guidance Guía operativa para administrador y para usuario
final
AGD_PRE.1 Preparative procedures Guía preparativa
ALC_CMC.4 Production support,
acceptance procedures and
automation
Plan de gestión de la configuración
ALC_CMS.4 Problem tracking CM
coverage
Listado de configuración
ALC_DEL.1 Delivery procedures Procedimientos de entrega
ALC_DVS.2 Sufficiency of security
measures
Medidas de seguridad para de desarrollo
ALC_LCD.1 Developer defined life-cycle
model
Ciclo de vida de la tarjeta
ALC_TAT.1 Well-defined development
tools
Herramientas y técnicas para el desarrollo del
Sistema Operativo
ASE_CCL.1 Conformance claims
Declaración de seguridad
ASE_ECD.1 Extended components
definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security
requirements
Security Requirements Rationale
Versión 2.1.0 Página 142 de 158
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
ATE_COV.2 Analysis of coverage Análisis de la cobertura de las pruebas para la
especificación funcional
ATE_DPT.2 Testing: security enforcing
modules
Definición de las pruebas de los subsistemas
ATE_FUN.1 Functional testing Plan de pruebas
ATE_IND.2 Independent testing –
sample
Documentación de pruebas
AVA_VAN.5 Advanced methodical
vulnerability analysis
Documentación de análisis de vulnerabilidades
Tabla 5.- Documentación y requisitos de garantía de seguridad.
7.3. Security Requirements Rationale
7.3.1. Security Functional Requirements Rationale
The following table provides an overview for the coverage of the security functional
requirements, and also gives evidence for sufficiency and necessity of the chosen SFRs.
Security Functional Requirements
Rationale
Versión 2.1.0 Página 143 de 158
Security Functional Requirements
Rationale
Versión 2.1.0 Página 144 de 158
Rationale for SFR’s Dependencies
Versión 2.1.0 Página 145 de 158
Tabla 6.- Coverage of Security Objectives for the TOE by SFRs
The dependency analysis for the security functional requirements given in the corresponding
Tables of the Protection Profiles and the following rationale shows that the mutual support and
internal consistency between all defined.
To achieve the security objectives of the TOE, the security functional requirements defined and
not referenced in any PP must be suitable.A detailed justification for this suitability is given
below.
The administrator channel implemented by FCS_COP.1/AES_PRO is also used for SCD import and
SVD export, thus contributing to OT.SCD_Secrecy and OT.TOE_TC_SVD_Exp. As prerequisite to
generate the channel the TOE uses key generation FCS_CKM.1/AES_PRO. FCS_CKM.4/AES_PRO
is used to destroy the keys.
7.3.2. Rationale for SFR’s Dependencies
The dependency analysis for the security functional requirements shows that the basis for
mutual support and internal consistency between all defined functional requirements is
satisfied. All dependencies between the chosen functional components are analyzed, and non-
dissolved dependencies are appropriately explained.
Security Assurance Requirements
Rationale
Versión 2.1.0 Página 146 de 158
The dependency analysis has directly been made within the description of each SFR in Section
6.1 above. All dependencies being expected by CC part 2 [CC] and by extended components
definition in Chapter 5 are either fulfilled, or their non-fulfillment is justified.
7.3.3. Security Assurance Requirements Rationale
The current assurance package was chosen based on the predefined assurance package EAL4.
This package permits a developer to gain maximum assurance from positive security engineering
based on good commercial development practices which, though rigorous, do not require
substantial specialist knowledge, skills, and other resources. EAL4 is the highest level, at which
it is likely to retrofit to an existing product line in an economically feasible way. EAL4 is applicable
in those circumstances where developers or users require a moderate to high level of
independently assured security in conventional commodity TOEs and are prepared to incur
additional security specific engineering costs.
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
electronic document’s development and manufacturing, especially for the secure handling of
sensitive material.
The selection of the component ATE_DPT.2 provides a higher assurance than the predefined
EAL4 package due to requiring the functional testing of SFR-enforcing modules.
The selection of the component AVA_VAN.5 provides a higher assurance than the predefined
EAL4 package, namely requiring a vulnerability analysis to assess the resistance to penetration
attacks performed by an attacker possessing a high attack potential. This decision represents a
part of the conscious security policy for the electronic document required by the electronic
document issuer and reflected by the current ST.
The set of assurance requirements being part of EAL4 fulfills all dependencies a priori. The
augmentation of EAL4 chosen comprises the following assurance components: ALC_DVS.2,
ATE_DPT.2 and AVA_VAN.5. For these additional assurance component, all dependencies are
met or exceeded in the EAL4 assurance package. Below we list only those assurance
requirements that are additional to EAL4.
ALC_DVS.2
Dependencies:
None
ATE_DPT.2
Dependencies:
ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
fulfilled by ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
Security Requirements – Internal
Consistency
Versión 2.1.0 Página 147 de 158
AVA_VAN.5
Dependencies:
ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1
fulfilled by ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1,
ATE_DPT.2
7.3.4. Security Requirements – Internal Consistency
The following part of the security requirements rationale shows that the set of security
requirements for the TOE consisting of the security functional requirements (SFRs) and the
security assurance requirements (SARs) are internally consistent. The analysis of the TOE´s
security requirements with regard to their mutual support and internal consistency
demonstrates:
The dependency analysis in Section 6.3.2 for the security functional requirements shows that
the basis for internal consistency between all defined functional requirements is satisfied. All
dependencies between the chosen functional components are analyzed and non-satisfied
dependencies are appropriately justified.
All subjects and objects addressed by more than one SFR are also treated in a consistent way:
the SFRs impacting them do not require any contradictory property or behavior of these ‘shared’
items.
The assurance package EAL4 is a predefined set of internally consistent assurance requirements.
The dependency analysis for the sensitive assurance components in Section 6.3.3 shows that the
assurance requirements are internally consistent as all (additional) dependencies are satisfied
and no inconsistency appears.
Inconsistency between functional and assurance requirements can only arise due to functional-
assurance dependencies not being met. As shown in Section 6.3.2 and Section 6.3.3, the chosen
assurance components are adequate for the functionality of the TOE. Hence, there are no
inconsistencies between the goals of these two groups of security requirements.
Resumen de las características
funcionales del producto
Versión 2.1.0 Página 148 de 158
8. Resumen de las características funcionales del producto
El TOE provee las siguientes capacidades relacionadas con la aplicación de firma electrónica:
1. Establecimiento del canal seguro (con o sin contactos)
Para el establecimiento del canal seguro, en primer lugar, se realiza un intercambio de las claves
públicas de la tarjeta y el terminal mediante certificados que serán verificados por ambas partes.
A continuación se realiza un protocolo de autenticación mutua, con intercambio de semillas para
la derivación de una semilla común que dé lugar a las claves de sesión de cifrado y autenticado.
Una vez concluido el protocolo para el establecimiento de la semilla común todos los mensajes
deben transmitirse securizados.
Si se rompe el canal seguro establecido debido a que se haya recibido un comando APDU que
no respete el formato de mensaje securizado o a que la información de autenticación o MAC sea
errónea, el canal queda deshabilitado y el estado de seguridad de la tarjeta es reseteado (se
borran las claves de sesión y los secretos presentados quedan invalidados).
El canal seguro se puede establecer empleando tanto el interfaz con contactos como el sin
contactos.
Este procedimiento permite que cada una de las partes (tarjeta y aplicación externa) confíe en
la otra, mediante la presentación mutua de certificados, y su verificación. En el proceso, también
se incluye el intercambio seguro de unas claves de sesión, que deberán ser utilizadas para
securizar (encriptar) todos los mensajes intercambiados posteriormente.
 Autenticación con intercambio de claves
Este procedimiento corresponde con el apartado 3.9 del documento [EN419212-3], en
el que se utilizan claves RSA de 3072 a 3840 bits, y SHA-256 en la validación de
certificados y en los comandos de autenticación.
 Autenticación de dispositivo con protección de privacidad
Este procedimiento corresponde con el apartado 3.6 del documento [EN419212-3], en
el que se utilizan claves EC de 256 a 521 bits, y SHA-256 en la validación de certificados
y en los comandos de autenticación.
 Protocolo EAC
Este procedimiento corresponde con el apartado 3.7 del documento [EN419212-3] y con
las especificaciones [TR03110-2], en el que se utilizan claves EC de 256 a 521 bits, y SHA-
256 en la validación de certificados y en los comandos de autenticación.
Resumen de las características
funcionales del producto
Versión 2.1.0 Página 149 de 158
La aplicación eSign soporta EAC2, es decir, Chip Authentication versión 2 y Terminal
Authentication versión 2.
 Protocolo PACE
Es un protocolo Diffie-Hellman key agreement que se basa en una contraseña (CAN, PIN
o PUK) definido en [TR03110-2]. Se debe establecer antes de cualquier otro canal para
acceder a las aplicaciones del TOE. También es utilizado como canal seguro en la
verificación del PIN en la aplicación eSign.
El TOE soporta la versión 2 de PACE según [TR03110-1], con el algoritmo ECDH AES 192
con curvas de 256 bits, 384 bits, 512 bits y 521 bits.
Esta alternativa se basa en la capacidad de la tarjeta para verificar certificados firmados por una
autoridad certificadora raíz, posiblemente a través de autoridades certificadoras intermedias, y
en la comprobación mediante protocolos de desafío-respuesta de que la otra parte dispone de
la clave privada asociada al certificado.
Cuando se completa con éxito el establecimiento de un canal seguro, se adquiere un nuevo
estado de seguridad en el diálogo con la tarjeta, que en función del certificado utilizado por el
terminal, podrá ser:
 Canal Seguro Administrativo. Corresponde a la condición de acceso “PRO”, y por lo
tanto se podrá acceder a los recursos que requieran esta condición. Solamente se
puede establecer con los canales Autenticación con intercambio de claves o
Autenticación de dispositivo con protección de privacidad definidos en [EN419212-
3].
 Canal Seguro de Usuario. Se corresponde con el canal EAC2 definido en [TR03110-
2].
 Canal Seguro de PIN. Se emplea para la presentación de los códigos CHV. Necesario
como paso previo a la realización de la operación de firma. Se corresponde con el
canal PACE definido en [TR03110-2].
2. Securización de mensajes
El TOE puede, previo establecimiento de un canal seguro, securizar los mensajes transmitidos.
Para el establecimiento es necesaria la autenticación previa del terminal y la tarjeta, mediante
el uso de certificados electrónicos.
Cuando el canal está establecido, los mensajes intercambiados entre la tarjeta y terminal se
cifran y autentican, de tal forma que se asegura una comunicación una-a-uno entre los dos
puntos originarios de canal. El canal seguro puede ser requerido por la aplicación o puede ser
una restricción de acceso impuesta a algún recurso de la tarjeta.
3. Identificación y Autenticación
Resumen de las características
funcionales del producto
Versión 2.1.0 Página 150 de 158
El TOE dispone de distintos métodos de autenticación, mediante los que una entidad externa
demuestra su identidad, o el conocimiento de algún dato secreto almacenado en la tarjeta.
La correcta realización de cada uno de estos métodos, permite obtener unas condiciones de
seguridad, que podrán ser requeridas para el acceso a los distintos recursos de la tarjeta.
 Autenticación de usuario mediante PIN
La tarjeta soporta verificación de usuario (CHV- Card Holder verification) para el acceso
a determinados ficheros. La verificación es realizada, a través del canal seguro de PIN,
comprobando el código facilitado por la entidad externa a través del comando diseñado
para tal fin. El dato es comparado con la información de referencia almacenada en el
fichero CHV. El código CHV (PIN) es una secuencia de 12-16 bytes.
Cada código CHV tiene su propio contador de intentos. Tras una presentación válida de
PIN, el contador de reintentos correspondiente es automáticamente puesto a su valor
inicial (3 intentos). El contador de intentos es decrementado cada vez que se realiza una
presentación errónea, pudiendo llegar a bloquearlo si el contador llega a cero. Es posible
desbloquear un código CHV tras una correcta presentación del código de desbloqueo.
La operación de desbloqueo se realiza con la presentación de la clave PUK o con
biometría más “clave APP”.
 Desbloqueo de PIN (Opción 1: Biometría)
La tarjeta TC-FNMT tiene soporte para biometría con algoritmo “Match on Card”, es
decir, la verificación de los datos biométricos frente a los datos de referencia se realiza
dentro de la propia tarjeta. Por tanto, se mantienen los datos sensibles de biometría
siempre internos a la tarjeta, y su utilización está controlada mediante control de
acceso. Esta característica de “Match on Card” confiere una importante diferencia
frente a algoritmos “Match off Card”, donde la tarjeta sólo es utilizada como soporte de
los datos para la verificación externa.
 Desbloqueo de PIN (Opción 2: PUK)
El desbloqueo del PIN con PUK se realiza a través del canal seguro de usuario,
comprobando el código facilitado por la entidad externa a través del comando diseñado
para tal fin. El dato es comparado con la información de referencia almacenada en el
fichero CHV. El código CHV (PUK) es una secuencia de 16 bytes.
El código PUK tiene su propio contador de intentos. Tras una presentación válida de PUK,
el contador de reintentos del PIN es automáticamente puesto a su valor inicial (3
intentos). El contador de intentos del PUK es decrementado cada vez que se realiza una
presentación errónea, pudiendo llegar a bloquearlo si el contador llega a cero. No es
posible desbloquear un código PUK.
4. Opciones del TOE – Biometría y actualización de S.O.
Resumen de las características
funcionales del producto
Versión 2.1.0 Página 151 de 158
 Biometría
El TOE dispone de un método de autenticación basado en la identificación biométrica
“Match On Card”. Este mecanismo es suministrado por dos proveedores diferentes con
objeto de reducir la dependencia tecnológica de cada uno de ellos. Ambos proveedores
ofrecen prestaciones equivalentes tanto en rendimiento como en las diferentes tasas
de comparación biométrica. Se procura que la mitad de los TOE cuenten con la biometría
de un proveedor y la otra mitad de los TOE con la biometría del otro con objeto de tener
un reparto equilibrado.
Si este mecanismo se encuentra activo, en dicha opción del TOE aplicarían los SFR
relacionados con esta funcionalidad. Concretamente: FIA_AFL.1/BIO_SSCDPP.
Si el mecanismo no se encuentra activo, a dicha opción del Toe no le aplicarían los SFRs
mencionados anteriormente.
 Actualización de Sistema Operativo
El TOE cuenta con un mecanismo que permite la actualización del sistema operativo en
el caso de que se considere necesario. Si este mecanismo se encuentra activo, en dicha
opción del TOE aplicarían los SFR relacionados con esta funcionalidad. Concretamente:
FCS_COP.1.1/UPD_ITC, FCS_CKM.1.1/UPD_ITC, FCS_COP.1.1/UPD_DEC,
FCS_CKM.1.1/UPD_DEC, FCS_COP.1.1/UPD_SIG, FCS_COP.1.1/UPD_INT,
FCS_CKM.1.1/UPD_INT, FCS_CKM.4.1/UPD, FCS_CKM.4.1/UPD_OS, FIA_AFL.1.1/UPD,
FIA_AFL.1.2/UPD, FIA_UID.1.1/UPD, FIA_UID.1.2/UPD, FIA_UAU.1.1/UPD,
FIA_UAU.1.2/UPD, FDP_ACC.1.1/UPD, FDP_ACF.1.1/UPD, FDP_ACF.1.2/UPD,
FDP_ACF.1.3/UPD, FDP_ACF.1.4/UPD, FDP_IFC.1.1/UPD, FDP_IFF.1.1/UPD,
FDP_IFF.1.2/UPD, FDP_IFF.1.3/UPD, FDP_IFF.1.4/UPD, FDP_IFF.1.5/UPD,
FDP_RIP.1.1/UPD, FTP_ITC.1.1/UPD, FTP_ITC.1.2/UPD, FTP_ITC.1.3/UPD,
FAU_SAS.1.1/UPD, FMT_SMF.1.1/UPD, FMT_MTD.1.1/UPD_SK_PICC,
FMT_MTD.1.1/UPD_KEY_READ, FMT_SMR.1.1/UPD, FMT_SMR.1.2/UPD,
FPT_EMS.1.1/UPD, FPT_EMS.1.2/UPD, FPT_FLS.1.1/UPD, FPT_TST.1.1/UPD,
FPT_TST.1.2/UPD, FPT_TST.1.3/UPD, FMT_LIM.1.1/Loader y FMT_LIM.2.1/Loader.
Si el mecanismo no se encuentra activo, a dicha opción del TOE no le aplicarían los SFRs
mencionados anteriormente.
Acrónimos
Versión 2.1.0 Página 152 de 158
9. Acrónimos
ALC Clase Life-Cycle Support
APDU Application Protocol Data Unit, Unidad de Datos del Protocolo de Aplicación
ATR Answer To Reset, Respuesta al Reset
BAC Basic Access Control
CA Autoridad de Certificación
CA Chip Authentication
CAN Card Access Number
CC Common Criteria
CCSCA CSCA Certificate
CGA Certificate-generation application, Aplicación de Generación de Certificados
CHAT Certificate Holder Authorization Template
CPU Central Processing Unit, Unidad Central de Proceso
CRT Chinese Remainder Theorem, Teorema del Residuo Chino
CSCA Company Signing Certification Authority
CSP Certification Service Provider, Proveedor de Servicios de Certificación
CVCA Company Verifying Certification Authority
DEMA Differential Electromagnetic Analysis
DES Data Encryption Standard
DPA Differential Power Analysis
DTBS Data to be signed, Datos a ser firmados
DTBS/R
Data to be signed or its unique representation, Representación unívoca de los datos a ser
firmados
EAC Extended Access Control
EAL Evaluation Assurance Level, Nivel de garantía de evaluación
ECC Elliptic curve cryptography, Criptografía de curvas elípticas
EEPROM Electrically Erasable Programable Read Only Memory, Memoria ROM programable
eléctricamente
FDP User Data Protection, Protección de datos de usuario
FIPS Federal Information Processing Standard
GND Ground, Tierra
HI Human Interface, Interfaz humana
Acrónimos
Versión 2.1.0 Página 153 de 158
IC Integrated Circuit, Circuito Integrado
ICAO International Civil Aviation Organization
IO Input/Output, Entrada/Salida
ISO International Organization for Standardization
LDS Logical Data Structure
MSE Manage Security Environment
OS Operating system, Sistema Operativo
OSP Organizational security policy
PACE Password Authenticated Connection Establishment
PKCS Public Key Cryptography Standards, Normas de Criptografía de Clave Pública
PIN Personal Identification Number, Número de Identificación Personal
PP Protection Profile, Perfil de Protección
PUK PIN Unblocking Key, Clave de Desbloqueo del PIN
RAD Reference authentication data, Datos de referencia de autenticidad
RAM Random Access Memory, Memoria de acceso aleatorio
ROM Read Only Memory, Memoria de solo lectura
RSA Rivest, Shamir & Adleman
SAC Supplemental Access Control
SCA Signature Creation Application, Aplicación de creación de firma
SCD Signature Creation Data, Datos de creación de firma
SDO Signed Data Object, Objeto de datos firmado
SFP Security Function Policy, Política de función de seguridad
SFR Security Functional Requirement, Requisito funcional de seguridad
SHA Secure Hashing Algorithm
SPA Simple Power Analysis
ST Security Target, Declaración de Conformidad
SVD Signature Verification Data, Datos de verificación de firma
TA Terminal Authentication
TOE Target of Evaluation, Objeto a evaluar
TSF TOE Security Functionality, Funciones de seguridad del TOE
TSFI TSF Interface, Interfaz de las funciones de seguridad del TOE
VAD Verification Authentication Data, Datos de verificación de identidad
VCC Supply Voltage, Tensión de Alimentación
Bibliografía
Versión 2.1.0 Página 154 de 158
10. Bibliografía
[AGO] Anexo I Ejemplo – Guía Operativa para usuario final v2.0 r3. 27/02/2023.
[AIS31] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS31, Version
2.0, 2011-09-18, Bundesamt für Sicherheit in der Informationstechnik.
[AES] Federal Information Processing Standards Publication 197 Advanced Encryption
Standard. U.S. Department of Commerce/National Institute of Standards and
Technology, 2001 November 26.
[ANSI X9.62] Public Key Cryptography for the Financial Services Industry, The Elliptic Curve
Digital Signature Algorithm (ECDSA). American National Standards Institute,
ANSI, 2005.
[ANSI X9.63] Public Key Cryptography for the Financial Services Industry - Key Agreement and
Key Transport Using Elliptic Curve Cryptography. American National Standards
Institute, ANSI, 2001.
[ASE_COMP] Composite product evaluation for smart card and similar devices, v1.5.1, May.
2018.
[CC] Common Criteria for Information Technology Security Evaluation. April 2017.
Version 3.1. Revision 5.
[CMD] Especificación funcional. Manual de comandos. TC-FNMT 5.6. v2.0 r4.
27/02/2023.
[eIDAS] Reglamento (UE) Nº 910/2014 del Parlamento Europeo y del Consejo de 23 de
julio de 2014 relativo a la identificación electrónica y los servicios de confianza
para las transacciones electrónicas en el mercado interior y por la que se deroga
la Directiva 1999/93/CE.
[EN419212-3] EN 419212-3. Interfaz de aplicación para tarjetas inteligentes utilizadas como
dispositivos seguros de creación de firma. Parte 3: Protocolos de autentificación
de dispositivos. Noviembre 2017.
[DIR] Directiva 1999/93/CE del Parlamento Europeo y del Consejo de 13 de diciembre
de 1999 por la que se establece un marco comunitario para la firma electrónica.
[DE] Decisión de ejecución (UE) 2016/650 de la Comisión de 25 de abril de 2016 por
la que se fijan las normas para la evaluación de la seguridad de los dispositivos
cualificados de creación de firmas y sellos con arreglo al artículo 30, apartado 3,
y al artículo 39, apartado 2, del Reglamento (UE) n.o 910/2014 del Parlamento
Europeo y del Consejo, relativo a la identificación electrónica y los servicios de
confianza para las transacciones electrónicas en el mercado interior.
Bibliografía
Versión 2.1.0 Página 155 de 158
[EAC2PP] Common Criteria Protection Profile — Electronic document implementing
Extended Access Control Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP),
BSI-CC-PP-0086. Version 1.01, May 20th, 2015.
[FIPS 140-2] Security Requirements for Cryptographic Modules, National Institute of
Standards and Technology (NIST), up to change notice December 3, 2002.
[FIPS 186-4] Digital Signature Standard (DSS) July 2013.
[GO] Guías operativas – TC-FNMT 5.6. v2.0 r3. 27/02/2023.
[GOA] Guía operativa para administrador – Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023.
[GOU] Guía Operativa para usuario final – Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023.
[GP] Guía preparativa – Tarjeta TC-FNMT 5.6. v2.0 r3. 27/02/2023.
[ICAO9303] International Civil Aviation Organization, ICAO Doc 9303, Machine Readable
Travel Documents – Machine Readable Passports, Version Seventh Edition,
2015.
[ICPP] Inside Secure, Infineon Technologies AG, NXP Semiconductors Germany GmbH,
STMicroelectronics: Common Criteria Protection Profile - Security IC Platform
Protection Profile with Augmentation Packages, BSI-CC-PP-0084-2014, v1.0. 13
January 2014.
[ISO7816-2] ISO/IEC 7816 Identification cards -- Integrated circuit cards -- Part 2: Cards with
contacts -- Dimensions and location of the contacts. 2007.
[ISO7816-4] Identification cards -- Integrated circuit cards -- Part 4: Organization, security
and commands for interchange. 2005.
[ISO11770-3] ISO/IEC 11770-3 Information technology -- Security techniques -- Key
management – Part 3: Mechanisms using asymmetric techniques
[ISO15946-1] ISO/IEC 15946-1 Information technology -- Security techniques -- Cryptographic
techniques based on elliptic curves -- Part 1: General. 2002.
[MR2] Assurance Continuity Maintenance Report. BSI-CC-PP-0059-2009-MA-02.
30/06/2016.
[MR3] Assurance Continuity Maintenance Report. BSI-CC-PP-0075-2012-MA-01.
30/06/2016.
[MR4] Assurance Continuity Maintenance Report. BSI-CC-PP-0071-2012-MA-01.
30/06/2016.
Bibliografía
Versión 2.1.0 Página 156 de 158
[MR5] Assurance Continuity Maintenance Report. BSI-CC-PP-0072-2012-MA-01.
30/06/2016.
[MR6] Assurance Continuity Maintenance Report. BSI-CC-PP-0076-2013-MA-01.
30/06/2016.
[MR.ED-PP] Common Criteria Protection Profile — Machine-Readable Electronic Documents
based on BSI TR-03110 for Official Use, BSI-CC-PP-0087-V2-MA-01, Version
2.0.3, July 18th, 2016.
[MR.ED-ON-PP]Common Criteria Protection Profile - Configuration Machine Readable Electronic
Documents - Optionales Nachladen (Optional Post-Emission Updates), BSI-CC-
PP-0090-2016, Version 0.9.2, August 18th, 2016.
[NIST SP 800-186] Recommendations for Discrete Logarithm_Based Cryptography: Elliptic Curve
Domain Parameters.
[NIST SP 800-90A] NIST Special Publication 800-90A Revision 1, Recommendation for
Random Number Generation Using Deterministic Random Bits Generators, June
2015.
[PACEPP] Common Criteria Protection Profile — Machine Readable Travel Document
using Standard Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011-MA-
01. Version 1.01, 22th July 2014.
[PKCS#1] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1.
[RFC5639] M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard
Curves and Curve Generation, RFC 5639, IETF, 2010-03.
[SSCDPP] Protection profiles for secure signature creation device — Part 2: Device with
key generation. Version: 2.0.1. January 2012.
[SSCDPP3] Protection Profiles for Secure Signature Creation Device – Part 3: Device with
key import, prEN 14169-3:2012 ver. 1.0.2, 2012-07-24.
[SSCDPP4] Protection profiles for secure signature creation device — Part 4: Extension for
device with key generation and trusted channel to certificate generation
application. Version: 1.0.1. November 2013.
[SSCDPP5] Protection profiles for secure signature creation device — Part 5: Extension for
device with key generation and trusted communication with signature creation
application. Version: 1.0.1. November 2012.
Bibliografía
Versión 2.1.0 Página 157 de 158
[SSCDPP6] Protection profiles for secure signature creation device — Part 6: Extension for
device with key import and trusted communication with signature creation
application. Version: 1.0.4. April 2013.
[SHS] Federal Information Processing Standards Publication 180-4 Secure Hash
Standard, U.S. Department of Commerce/National Institute of Standards and
Technology, March 2012.
[TR03110] Technical Guideline TR-03110. Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token – Parts 1, 2 and 3. See more
details below.
[TR03110-1] Technical Guideline TR-03110. Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token – Part 1 – eMRTDs with
BAC/PACEv2 and EACv1. Version 2.20. 26. February 2015
[TR03110-2] Technical Guideline TR-03110. Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token – Part 2: Protocols for electronic
IDentification, Authentication and trust Services (eIDAS). Version 2.21. 21.
December 2016.
[TR03110-3] Technical Guideline TR-03110. Advanced Security Mechanisms for Machine
Readable Travel Documents and eIDAS Token – Part 3: Common Specifications.
Version 2.21. 21. December 2016.
[TR03111] BSI: TR 03111: Elliptic Curve Cryptography, Version 2.0, 28. June 2012.
[TR03116-2] BSI: TR 03116-2: Kryptographische Vorgaben für Projekte der Bundesregierung
Teil 2 – Hoheitliche Ausweisdokumente, 2. February 2015
Índice de tablas
Versión 2.1.0 Página 158 de 158
11. Índice de tablas
Tabla 1.- Security Objective Rationale........................................................................................ 43
Tabla 2.- Definition of security attributes................................................................................... 53
Tabla 3.- Keys and certificates. ................................................................................................... 55
Tabla 4.- Overview of authentication SFRs................................................................................. 73
Tabla 5.- Documentación y requisitos de garantía de seguridad. ............................................ 142
Tabla 6.- Coverage of Security Objectives for the TOE by SFRs................................................ 145