4.2.3 Truncamiento del nombre en la ZLM

Las reglas básicas para escribir el nombre de la persona titular en la ZIV y la ZLM figuran en el Doc 9303-3. Cuando el nombre contenga más caracteres de los disponibles en la casilla de nombre de la ZLM del DV2, es necesario truncar el nombre. Los métodos siguientes brindan varias opciones disponibles para utilizar a discreción del Estado expedidor u organización expedidora.

(Las reglas básicas para escribir el nombre de la persona titular en la ZIV y la ZLM figuran en el Doc 9303-3. Cuando el nombre incluya más caracteres de los disponibles en la casilla de nombre de la ZLM del DV2, es necesario abreviar el nombre. Los métodos siguientes ofrecen varias opciones disponibles para utilizar a elección del Estado emisor u organización emisora.)

4.2.3.1 Nombres truncados — Identificador secundario truncado

a) Uno o más nombres reducidos a iniciales:

Nombre: Nilavadhanananda Chayapa Dejthamrong Krasuang

ZIV: NILAVADHANANANDA, CHAYAPA DEJTHAMRONG KRASUANG

ZLM (línea superior): I<UTONILAVADHANANANDA<<CHAYAPA<DEJ<K

b) Uno o más nombres truncados:

Nombre: Nilavadhanananda Arnpol Petch Charonguang

ZIV: NILAVADHANANANDA, ARNPOL PETCH CHARONGUANG

ZLM (línea superior): I<UTONILAVADHANANANDA<<ARN<PET<CHARO

4.2.3.2 Nombres truncados — Identificador primario truncado

a) Uno o más nombres reducidos a iniciales:

Nombre: Dingo Potoroo Bennelong Wooloomooloo Warrandyte Warnambool

ZIV: BENNELONG WOOLOOMOOLOO WARRANDYTE WARNAMBOOL, DINGO POTOROO

ZLM (línea superior): I<UTOBENNELONG<WOOLOOMOOLOO<W<W<<D<P

b) Uno o más nombres truncados:

Nombre: Dingo Potoroo Bennelong Wooloomooloo Warrandyte Warnambool

ZIV: BENNELONG WOOLOOMOOLOO WARRANDYTE WARNAMBOOL, DINGO POTOROO

ZLM (línea superior): I<UTOBENNELONG<WOOLOOM<WAR<WARN<<D<P

c) Uno o más nombres reducidos a un número fijo de caracteres:

Nombre: Dingo Potoroo Bennelong Wooloomooloo Warrandyte Warnambool

ZIV: BENNELONG WOOLOOMOOLOO WARRANDYTE WARNAMBOOL, DINGO POTOROO

ZLM (línea superior): I<UTOBENNEL<WOOLO<WARRA<WARNA<<DIN<P

4.2.3.3 Nombres que ocupan el número máximo de espacios disponibles en el mismo campo y que, por terminar con una letra en el último espacio de ese campo podrían parecer truncados, aunque no lo hayan sido.

Nombre: Jonathoon Alec Papandropoulous

ZIV: PAPANDROPOULOUS, JONATHOON ALEC

ZLM (línea superior r): I<UTOPAPANDROPOULOUS<<JONATHOON<ALEC

Nota.— Aunque en el espacio 36 de la línea inferior de lectura mecánica de este DV2 aparece un carácter alfabético, el nombre no ha sido truncado, pero debe suponerse que lo ha sido.

(Nota.— Aunque en el espacio 36 de la línea inferior de lectura mecánica de este DV2 aparece un carácter alfabético, el nombre no ha sido abreviado, pero debe entenderse que lo ha sido.)

4.2.3.4 Nombres que contienen varios componentes

Nombre: Martin Van Der Muellen

ZIV: VAN DER MUELLEN, MARTIN

ZLM (línea superior): VAN<DER<MUELLEN<<MARTIN<<<<<<<

Nombre: Huda Muhammad Jawad Al-Basri

ZIV: AL-BASRI, HUDA MUHAMMAD JAWAD

ZLM (línea superior): I<UTOAL<BASRI<<HUDA<MUHAMMAD<JAWAD<<

Nombre: Jose Ramon Vilarchao Fernandez

ZIV: VILARCHAO FERNANDEZ, JOSE RAMON

ZLM (línea superior): I<UTOVILARCHAO<FERNANDEZ<<JOSE<RAMON

4.2.3.5 Sin identificador secundario

Nombre: Arkfreith

ZIV: ARKFREITH

ZLM (línea superior): I<UTOARKFREITH<<<<<<<<<<<<<<<<<<<<<<

Nombre: Satriya Sudarpa

ZIV: SATRIYA SUDARPA

ZLM (línea superior): I<UTOSATRIYA<SUDARPA<<<<<<<<<<<<<<<<

4.2.4 Dígitos de verificación en la ZLM

El método para calcular los dígitos de verificación figura en el Doc 9303-3. Para el DV2 la disposición de los datos de las líneas de lectura mecánica en el párrafo 4.2.2 tiene en cuenta la inclusión de cuatro dígitos de verificación como sigue:

(El método para calcular los dígitos de comprobación figura en el Doc 9303-3. Para el DV2 la colocación de los datos de las líneas de lectura mecánica en el párrafo 4.2.2 tiene en cuenta la inclusión de cuatro dígitos de comprobación como sigue:)

4.3 Representación del Estado expedidor u organización expedidora

y de la nacionalidad del titular en la ZLM y la ZIV

El uso de los códigos de tres letras indicados en el Doc 9303-3 es obligatorio en la ZLM. En la ZIV, el nombre del Estado expedidor u organización expedidora aparecerá en su totalidad; la nacionalidad de la persona titular en la ZIV puede aparecer en su totalidad o en forma de código de tres letras. Los lugares específicos se definen en la tabla siguiente:

(El uso de los códigos de tres letras indicados en el Doc 9303-3 es obligatorio en la ZLM. En la ZIV, el nombre del Estado emisor u organización emisora aparecerá en su totalidad; la nacionalidad de la persona titular en la ZIV puede aparecer en su totalidad o en forma de código de tres letras. Los lugares concretos se definen en la tabla siguiente:)

(sigue la sección 4 de la Parte 11 del documento 9303)

2) El sistema de inspección y el CI sin contacto del eMRTD autentican y obtienen mutuamente claves de sesión. DEBE utilizarse el protocolo de autenticación y establecimiento de claves descrito anteriormente.

3) Después de una autenticación exitosa del protocolo de autenticación tanto el IFD como el CI calculan las claves de sesión KSEnc y KSMAC utilizando un mecanismo de extensión de claves que se describe en las secciones 9.7.1 y 9.7.4 con (K.IC xor K.IFD) como secreto compartido. Todas las comunicaciones subsiguientes DEBEN estar protegidas por la construcción segura de mensajes según se describe en la sección 9.8.

4.3.3 Especificaciones criptográficas

4.3.3.1 Cifrado de puesta a prueba y respuesta

Para el cálculo de EIFD y EIC se utilizarán 3DES de dos claves en modo CBC con IV cero (es decir, 0x00 00 00 00 00 00 00 00) con arreglo a [ISO/IEC 11568-2]. NO DEBE utilizarse relleno para los datos de entrada al ejecutar el comando EXTERNAL AUTHENTICATE.

(Para el cálculo de EIFD y EIC se utilizarán 3DES (Triple DES = Data Encryption Standard = Norma de cifrado de datos) de dos claves en modo CBC (Cypher Block Chaining = Cadena de bloques cifrados) con IV (Initial Vector = Vector inicial) cero (es decir, 0x00 00 00 00 00 00 00 00) de acuerdo con [ISO/IEC 11568-2]. NO DEBE utilizarse relleno para los datos de entrada al ejecutar el comando EXTERNAL AUTHENTICATE.)

4.3.3.2 Autenticación de puesta a prueba y respuesta

Las sumas de control criptográficas MIFD y MIC se CALCULARÁN utilizando el algoritmo 3 MAC de [ISO/IEC 9797-1] con cifra en bloque DES, IV cero (8 bytes) y el método de relleno 2 de [ISO/IEC 9797-1]. La longitud MAC DEBE ser de 8 bytes.

(Las sumas de control criptográficas MIFD y MIC se CALCULARÁN utilizando el algoritmo 3 MAC (Message Authentication Code = Código de autenticación de mensajes) de [ISO/IEC 9797-1] con cifra en bloque DES, IV cero (8 bytes) y el método de relleno 2 de [ISO/IEC 9797-1]. La longitud MAC DEBE ser de 8 bytes.)

4.3.4 Unidades de datos del protocolo de aplicación

El control de acceso de base se ejecuta utilizando los comandos GET CHALLENGE y EXTERNAL AUTHENTICATE con función de autenticación mutua. Los comandos se CODIFICARÁN según se especifica en [ISO/IEC 7816-4].

4.3.4.1 OBTENER PUESTA A PRUEBA (GET CHALLENGE)

4.3.4.2 AUTENTICACIÓN EXTERNA (EXTERNAL AUTHENTICATE)

4.4 Establecimiento de conexión autenticada por contraseña

PACE es un protocolo de acuerdo de claves Diffie-Hellman autenticado por contraseña que proporciona comunicación segura y autenticación basada en contraseña de la microplaqueta del eMRTD y del sistema de inspección (es decir, que

la microplaqueta del eMRTD y el sistema de inspección comparten la misma contraseña π).

(PACE (Password Authenticated Connection Establishment = Establecimiento de conexión autenticada por contraseña) es un protocolo de acuerdo de claves Diffie-Hellman autenticado por contraseña que facilita comunicación segura y autenticación basada en contraseña de la microplaqueta del eMRTD y del sistema de inspección (es decir, que la microplaqueta del eMRTD y el sistema de inspección comparten la misma contraseña π).)

PACE establece una construcción segura de mensajes entre una microplaqueta de eMRTD y un sistema de inspección basada en contraseñas débiles (breves). El contexto de seguridad se establece en el fichero maestro. El protocolo permite que la microplaqueta del eMRTD verifique que el sistema de inspección está autorizado para acceder a los datos almacenados y tiene las características siguientes:

(PACE establece una construcción segura de mensajes entre una microplaqueta de eMRTD y un sistema de inspección basada en contraseñas débiles (breves). El contexto de seguridad se establece en el fichero maestro. El protocolo posibilita que la microplaqueta del eMRTD compruebe que el sistema de inspección está autorizado para acceder a los datos almacenados y tiene las características siguientes:)

• Se proporcionan claves de sesión fuertes independientemente de la fuerza de la contraseña.

(Se suministran claves de sesión fuertes independientemente de la fuerza de la contraseña.)

• La entropía de las contraseñas utilizadas para autenticar el sistema de inspección puede ser muy baja (p. ej., en general alcanza con 6 dígitos).

PACE utiliza claves Kπ obtenidas de contraseñas mediante una función de obtención de claves KDFπ (véase la sección 9.7.3). Para los documentos de viaje de lectura mecánica de interfuncionamiento mundial se dispone de las siguientes dos contraseñas y sus claves correspondientes:

• ZLM: la clave Kπ definida por Kπ = KDFπ(ZLM) es EXIGIDA. Se obtienen de la zona de lectura mecánica (ZLM) en forma similar al control de acceso de base, es decir, la clave se obtiene del número de documento, la fecha de nacimiento y la fecha de caducidad.

• CAN: la clave Kπ definida por Kπ = KDFπ(CAN) es OPCIONAL. Se obtiene del número de acceso de la tarjeta (CAN). El CAN es un número impreso en el documento y DEBE escogerse en forma aleatoria o pseudoaleatoria (p. ej., utilizando una función pseudoaleatoria criptográficamente fuerte). Las Partes 4, 5 y 6 del Doc 9303 especifican el campo CAN.

(CAN: la clave Kπ definida por Kπ = KDFπ(CAN) es OPCIONAL. Se obtiene del número de acceso de la tarjeta (CAN). El CAN es un número impreso en el documento y DEBE escogerse en forma impredecible o pseudoimpredecible (p. ej., utilizando una función pseudoimpredecible criptográficamente fuerte). Las Partes 4, 5 y 6 del Doc 9303 describen el campo CAN.)

Nota.— En contraste con la ZLM (número de documento, fecha de nacimiento, fecha de caducidad) el CAN tiene la ventaja de que puede escribirse manualmente con facilidad.

PACE apoya dos correspondencias diferentes como parte de la ejecución del protocolo:

(PACE admite dos correspondencias diferentes como parte de la ejecución del protocolo:)

• correspondencia genérica basada en el acuerdo de claves Diffie-Hellman;

• correspondencia integrada basada en la correspondencia directa de un elemento del campo con el grupo criptográfico;

• correspondencia de autenticación de microplaqueta amplía la correspondencia genérica e integra la autenticación de microplaqueta en el protocolo PACE.

(correspondencia de autenticación de microplaqueta amplía la correspondencia genérica e incluye la autenticación de microplaqueta en el protocolo PACE.)

Si la microplaqueta apoya la correspondencia de autenticación de microplaqueta, por lo menos una correspondencia genérica o correspondencia integrada y autenticación de microplaqueta DEBE también ser apoyada por la microplaqueta. Esto entraña que, para los sistemas de inspección que apoyan PACE, solo se EXIGE apoyo para correspondencia genérica y correspondencia integrada. El apoyo para la correspondencia de autenticación de microplaqueta es OPCIONAL.

(Si la microplaqueta admite la correspondencia de autenticación de microplaqueta, por lo menos una correspondencia genérica o correspondencia incluida y autenticación de microplaqueta DEBE también ser admitida por la microplaqueta. Esto significa que, para los sistemas de inspección que admiten PACE, solo se EXIGE apoyo para correspondencia genérica y correspondencia incluida. El apoyo para la correspondencia de autenticación de microplaqueta es OPCIONAL.)

4.4.1 Especificación de protocolo

El sistema de inspección lee los parámetros para PACE apoyados por la microplaqueta del eMRTD del fichero EF.CardAccess (véase la sección 9.2.11) y seleccione los parámetros que han de utilizarse, seguido de la ejecución del protocolo.

(El sistema de inspección lee los parámetros para PACE admitidos por la microplaqueta del eMRTD del fichero EF.CardAccess (véase la sección 9.2.11) y selecciona los parámetros que han de utilizarse, seguido de la ejecución del protocolo.)

Se UTILIZARÁN los comandos siguientes:

• READ BINARY según se especifica en el Doc 9303-10;

• MSE:Set AT (comando MANAGE SECURITY ENVIRONMENT con función de plantilla de autenticación Set) según se especifica en la sección 4.4.4.1;

• Los pasos siguientes se EJECUTARÁN por el sistema de inspección y la microplaqueta del eMRTD utilizando una cadena de comandos GENERAL AUTHENTICATE según se especifica en la sección 4.4.4.2:

1) La microplaqueta del eMRTD elige en forma aleatoria y uniforme un nonce s, cifra el nonce a z = E(Kπ,s), donde Kπ = KDFπ (π) se obtiene de la contraseña compartida π, y envía el texto cifrado z al sistema de inspección.

(La microplaqueta del eMRTD elige en forma impredecible y única un nonce s, cifra el nonce a z = E(Kπ,s), donde Kπ = KDFπ (π) se obtiene de la contraseña compartida π, y envía el texto cifrado z al sistema de inspección.)

2) Sistema de inspección recupera el texto simple s = D(Kπ,z) con ayuda de la contraseña compartida π.

3) Tanto la microplaqueta del eMRTD como el sistema de inspección ejecutan los pasos siguientes:

a) Intercambio en datos adicionales requeridos para la correspondencia del nonce:

(Intercambio en datos adicionales exigidos para la correspondencia del nonce:)

i) para la correspondencia genérica, la microplaqueta del eMRTD y el sistema de inspección intercambian claves públicas efímeras.

(para la correspondencia genérica, la microplaqueta del eMRTD y el sistema de inspección intercambian claves públicas breves.)

ii) para la correspondencia integrada, el sistema de inspección envía un nonce adicional a la microplaqueta del eMRTD.

b) Calculan los parámetros de dominio efímero D = Map(DIC,s,…) según se describe en la sección 4.4.3.3.

c) Ejecutan un acuerdo de clave Diffie-Hellman anónimo (véase la sección 9.6) basado en los parámetros de dominio efímero y generan el secreto compartido K = KA(SKDH,IC, PKDH,IFD,D) = KA(SKDH,IFD, PKDH,IC,D).

(Ejecutan un acuerdo de clave Diffie-Hellman anónimo (véase la sección 9.6) basado en los parámetros de dominio breve y crean el secreto compartido K = KA(SKDH,IC, PKDH,IFD,D) = KA(SKDH,IFD, PKDH,IC,D).)

d) Durante el acuerdo de clave Diffie-Hellman, el CI y el sistema de inspección DEBERÍAN verificar que las dos claves públicas PKDH,IC y PKDH,IFD son diferentes.

(Durante el acuerdo de clave Diffie-Hellman, el CI y el sistema de inspección DEBERÍAN comprobar que las dos claves públicas PKDH,IC y PKDH,IFD son diferentes.)

e) Obtienen claves de sesión KSMAC = KDFMAC(K) y KSEnc = KDFEnc(K) según se describe en la sección 9.7.1.

f) Intercambian y verifican el testigo (token) de autenticación TIFD = MAC(KSMAC,PKDH,IC) y TIC = MAC(KSMAC,PKDH,IFD) según se describe en la sección 4.4.3.4.

(Intercambian y comprueban el testigo (token) de autenticación TIFD = MAC(KSMAC,PKDH,IC) y TIC = MAC(KSMAC,PKDH,IFD) como se describe en la sección 4.4.3.4.)

4) Condicionalmente, la microplaqueta eMRTD calcula los datos de autenticación de microplaqueta CAIC, los cifra y AIC = E(KSEnc, CAIC) y los envía al terminal (véase la sección 4.4.3.5.1). El terminal descifra AIC y verifica la autenticidad de la microplaqueta utilizando los datos de autenticación de microplaqueta recuperado CAIC (véase la sección 4.4.3.5.2).

(Condicionalmente, la microplaqueta eMRTD calcula los datos de autenticación de microplaqueta CAIC, los cifra y AIC = E(KSEnc, CAIC) y los envía al terminal (véase la sección 4.4.3.5.1). El terminal descifra AIC y comprueba la autenticidad de la microplaqueta utilizando los datos de autenticación de microplaqueta recuperado CAIC (véase la sección 4.4.3.5.2).)

En la figura 1 también se muestra una versión simplificada del protocolo.

Figura 1. Establecimiento de conexión autenticada por contraseña

4.4.2 Condición de seguridad

Un eMRTD que apoye PACE RESPONDERÁ a los intentos de lectura no autenticados [incluyendo la selección de ficheros (protegidos) en la LDS] con el mensaje “condición de seguridad no satisfecha” (0x6982).

(Un eMRTD que admita PACE RESPONDERÁ a los intentos de lectura no autenticados [incluyendo la selección de ficheros (protegidos) en la LDS (Logical Data Structure = Estructura lógica de datos )] con el mensaje “requisito de seguridad no satisfecho” (0x6982).)

Nota.— Esta especificación es más restrictiva que la especificación correspondiente para eMRTD con BAC solamente.

(Nota.— Esta determinación es más limitativa que la determinación correspondiente para eMRTD con BAC solamente.)

Si PACE fue ejecutado con éxito, la microplaqueta eMRTD ha verificado la contraseña utilizada. La construcción segura de mensajes se inicia utilizando las claves de sesión obtenidas KSMAC y KSEnc.

(Si PACE fue ejecutado con éxito, la microplaqueta eMRTD ha comprobado la contraseña utilizada. La construcción segura de mensajes se inicia utilizando las claves de sesión obtenidas KSMAC y KSEnc.)

4.4.3 Especificaciones criptográficas

En esta sección figuran los detalles criptográficos de la especificación.

(En esta sección figuran los detalles criptográficos de la determinación.)

Los algoritmos particulares son seleccionados por el Estado expedidor u organización expedidora. El sistema de inspección DEBE apoyar todas las combinaciones que se describen en las subsecciones siguientes, con la excepción de la correspondencia de autenticación de microplaqueta, que es OPCIONAL. La microplaqueta del eMRTD PUEDE admitir más de una combinación de algoritmos.

(Los algoritmos especiales son seleccionados por el Estado emisor u organización emisora. El sistema de inspección DEBE aceptar todas las combinaciones que se describen en las subsecciones siguientes, salvo la correspondencia de autenticación de microplaqueta, que es OPCIONAL. La microplaqueta del eMRTD PUEDE admitir más de una combinación de algoritmos.)

Nota.— Algunos algoritmos no están disponibles para la correspondencia de autenticación de microplaqueta: por razones de seguridad, ya no se recomienda el uso de 3DES. No se dispone de variantes de DH para reducir el número de variantes que han de implantar los terminales.

(Nota.— Algunos algoritmos no están disponibles para la correspondencia de autenticación de microplaqueta: por razones de seguridad, ya no se recomienda el uso de 3DES (Triple DES = Data Encryption Standard = Norma de cifrado de datos). No se dispone de modificaciones de DH (Diffie Hellmann) para reducir el número de variantes que han de instalar los terminales.)

4.4.3.1 DH

Para PACE con DH DEBEN utilizarse los respectivos algoritmos y formatos de la sección 9.6 y de la tabla 2.

(Para PACE con DH DEBEN utilizarse los respectivos algoritmos y modelos de la sección 9.6 y de la tabla 2.)

Tabla 2. Algoritmos y formatos para DH

4.4.3.2 ECDH

Para PACE con ECDH DEBEN utilizarse los respectivos algoritmos y formatos de la sección 9.6 y de la tabla 3.

Sólo se UTILIZARÁN curvas de números primos. DEBERÍAN utilizarse los parámetros de dominio normalizados que se describen en la sección 9.5.1.

(Sólo se UTILIZARÁN curvas de números primos. DEBERÍAN utilizarse los criterios de dominio unificados que se describen en la sección 9.5.1.)

La sección 9.5 de la Parte 11 del documento 9303 recoge:

9.5 Parámetros de dominio

Con la excepción de los parámetros de dominio contenidos en PACEInfo, todos los parámetros de dominio se PROPORCIONARÁN como AlgorithmIdentifier (véase la sección 9.1).

(Con la excepción de los criterios de dominio incluidos en PACEInfo, todos los criterios de dominio se SUMINISTRARÁN como AlgorithmIdentifier (véase la sección 9.1).)

Dentro del PACEInfo, se HARÁ referencia directamente a los ID de parámetros de dominio normalizados que se describen en la tabla 12. Los parámetros de dominio explícitos proporcionados por PACEDomainParameterInfo NO DEBEN utilizar estos ID reservados para los parámetros de dominio normalizados.

(Dentro del PACEInfo, se HARÁ referencia directamente a los ID de criterios de dominio unificados que se describen en la tabla 12. Los criterios de dominio expresos suministrados por PACEDomainParameterInfo NO DEBEN utilizar estos ID reservados para los criterios de dominio unificados.)

9.5.1 Parámetros de dominio normalizados

DEBERÍAN utilizarse los ID de parámetros de dominio normalizados descritos en la tabla siguiente. Los parámetros de dominio explícitos NO DEBEN utilizar dichos ID reservados para parámetros de dominio normalizados.

(DEBERÍAN utilizarse los ID de criterios de dominio unificados descritos en la tabla siguiente. Los parámetros de dominio expresos NO DEBEN utilizar dichos ID reservados para criterios de dominio unificados.)

El siguiente identificador de objeto DEBERÍA utilizarse para hacer referencia a los parámetros de dominio normalizados en un AlgorithmIdentifier (véase la sección 9.1):

(El siguiente identificador de objeto DEBERÍA utilizarse para hacer referencia a los criterios de dominio unificados en un AlgorithmIdentifier (véase la sección 9.1):)

standardizedDomainParameters OBJECT IDENTIFIER ::= {

bsi-de algorithms(1) 2

}

La sección 9.1 de la Parte 11 del documento 9303 recoge:

9.1 Estructuras ASN.1

Las estructuras de datos SubjectPublicKeyInfo y AlgorithmIdentifier se definen como sigue:

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING

}

AlgorithmIdentifier ::= SEQUENCE {

algorithm OBJECT IDENTIFIER,

parameters ANY DEFINED BY algorithm OPTIONAL

}

En [X9.42] y [TR-03111] figuran detalles sobre los parameters.

(sigue la sección 9.5 de la Parte 11 del documento 9303)

Dentro de un AlgorithmIdentifier, este identificador de objeto HARÁ referencia al ID del parámetro de dominio normalizado según figura en la Tabla 12 como INTEGER, contenido como parameters en el AlgorithmIdentifier.

(Dentro de un AlgorithmIdentifier, este identificador de objeto HARÁ referencia al ID del criterio de dominio unificado según figura en la Tabla 12 como INTEGER, incluido como parameters en el AlgorithmIdentifier.)

Tabla 12. Parámetros de dominio normalizados

* Esta curva no puede utilizarse con la correspondencia integrada.

9.5.2 Parámetros de dominio explícitos

El Identificador de objeto dhpublicnumber o ecPublicKey para DH o ECDH, respectivamente, SE UTILIZARÁ para hacer referencia a los parámetros de dominio explícito en un AlgorithmIdentifier (véase la sección 9.1):

(El Identificador de objeto dhpublicnumber o ecPublicKey para DH o ECDH, respectivamente, SE UTILIZARÁ para hacer referencia a los criterios de dominio expreso en un AlgorithmIdentifier (véase la sección 9.1):)

dhpublicnumber OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1

}

ecPublicKey OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) ansi-x962(10045) keyType(2) 1

}

En el caso de curvas elípticas, los parámetros de dominio DEBEN describirse explícitamente en la estructura ECParameters, contenida como parameters en el AlgorithmIdentifier, es decir, NO DEBEN utilizarse curvas nombradas y parámetros de dominio implícitos.

(En el caso de curvas elípticas, los criterios de dominio DEBEN describirse expresamente en la estructura ECParameters, incluida como parameters en el AlgorithmIdentifier, es decir, NO DEBEN utilizarse curvas nombradas y criterios de dominio tácitos.)

(sigue la sección 4 de la Parte 11 del documento 9303)

Tabla 3. Algoritmos y formatos para ECDH

4.4.3.3 Nonces de cifrado y correspondencia

La microplaqueta eMRTD SELECCIONARÁ en forma aleatoria y uniforme el nonce s como cadena de bits binarios de longitud l, donde l es múltiplo del tamaño de bloque en bits del cifrado de bloque E() respectivo elegido por la microplaqueta del eMRTD.

(La microplaqueta eMRTD SELECCIONARÁ en forma impredecible y única el nonce s como cadena de bits binarios de longitud l, donde l es múltiplo del tamaño de bloque en bits del cifrado de bloque E() respectivo elegido por la microplaqueta del eMRTD.)

• El nonce s se CIFRARÁ en modo CBC con arreglo a [ISO/IEC 10116] utilizando la clave Kπ = KDFπ(π) obtenida de la contraseña π y IV puesto a la cadena de todos 0.

(El nonce s se CIFRARÁ en modo CBC (Cypher Block Chaining = Cadena de bloques cifrados) de acuerdo con [ISO/IEC 10116] utilizando la clave Kπ = KDFπ(π) obtenida de la contraseña π y IV (Initial Vector = Vector inicial) puesto a la cadena de todos 0.)

• El nonce s se CONVERTIRÁ en generador aleatorio utilizando una función de correspondencia Map específica del algoritmo.

(El nonce s se CONVERTIRÁ en creador impredecible utilizando una función de correspondencia Map concreta del algoritmo.)

• Para la correspondencia integrada se seleccionará un nonce t adicional en forma aleatoria y uniforme como cadena de bits binarios de longitud k y se enviará en claro. En este caso k es el tamaño de clave en bits del respectivo cifrado en bloque E() y l SERÁ el menor múltiplo del tamaño de bloque de E() de modo que l ≥ k.

(Para la correspondencia incluida se seleccionará un nonce t adicional en forma impredecible y única como cadena de bits binarios de longitud k y se enviará en claro. En este caso k es el tamaño de clave en bits del respectivo cifrado en bloque E() y l SERÁ el menor múltiplo del tamaño de bloque de E() de modo que l ≥ k.)

Para ejecutar la correspondencia del nonce s o los nonces s, t en el grupo criptográfico se UTILIZARÁ uno de los siguientes modos de correspondencia:

• Correspondencia genérica (sección 4.4.3.3.1);

• Correspondencia integrada (sección 4.4.3.3.2);

• Correspondencia de autenticación de mensaje (sección 4.4.3.3.3).

4.4.3.3.1 Correspondencia genérica

ECDH

(ECDH = Elliptic Curve Diffie Hellmann = Curva elíptica Diffie Hellmann)

La función Map:G → Ĝ se define como Ĝ = s×G+H, donde H en <G> se elige de modo que se desconoce el logGH. El punto H se CALCULARÁ mediante un acuerdo de clave Diffie-Hellman anónimo [TR-03111] como H = KA(SKMap,IC, PKMap, IFD, DIC) = KA(SKMap,IFD, PKMap, IC, DIC).

Nota.— El algoritmo de acuerdo de clave ECKA impide pequeños ataques de subgrupo utilizando multiplicación de cofactores compatibles.

DH

(DH = Diffie Hellmann)

La función Map:g → ĝ se define como ĝ =gs×h, donde h en <g> se elige de modo que se desconoce el loggh. El elemento h del grupo se CALCULARÁ mediante un acuerdo de clave Diffie-Hellman anónimo como h = KA(SKMap,IC, PKMap,IFD, DIC) =

KA(SKMap,IFD, PKMap,IC, DIC).

Nota.— El método de validación de clave pública que se describe en [RFC 2631] DEBE utilizarse para impedir ataques de subgrupos pequeños.

(Nota.— El método de comprobación de clave pública que se describe en [RFC 2631] DEBE utilizarse para impedir ataques de subgrupos pequeños.)

4.4.3.3.2 Correspondencia integrada

ECDH

La función Map:G → Ĝ se define como Ĝ = fG(Rp(s,t)), donde Rp() es una función pseudoaleatoria que transforma cadenas de octetos en elementos de GF(p) y fG() es una función que transforma elementos de GF(p) a <G>. El nonce t aleatorio se ELEGIRÁ en forma aleatoria por el sistema de inspección y se enviará a la microplaqueta eMRTD. La función pseudoaleatoria Rp() se describe a continuación. La función fG() se define en [BCIMRT2010]. En el Apéndice B figura una descripción informativa al respecto.

(La función Map:G → Ĝ se define como Ĝ = fG(Rp(s,t)), donde Rp() es una función pseudoimpredecible que transforma cadenas de octetos en elementos de GF(p) y fG() es una función que transforma elementos de GF(p) a <G>. El nonce t impredecible se ELEGIRÁ en forma impredecible por el sistema de inspección y se enviará a la microplaqueta eMRTD. La función pseudoimpredecible Rp() se describe a continuación. La función fG() se define en [BCIMRT2010]. En el Apéndice B figura una descripción informativa al respecto.)

El Apéndice B de la Parte 11 del documento 9303 recoge:

Apéndice B de la Parte 11

CODIFICACIÓN DE PUNTOS PARA CORRESPONDENCIA

INTEGRADA DE ECDH (INFORMATIVO)

B.1 DESCRIPCIÓN DE ALTO NIVEL DEL MÉTODO DE CODIFICACIÓN DE PUNTOS

El algoritmo toma como entradas los parámetros de curva (a, b, p, f ) donde (a, b) son los coeficientes de la curva y p es la característica del campo primo sobre el cual está definida la curva.

(El algoritmo utiliza como entradas los criterios de curva (a, b, p, f ) donde (a, b) son los coeficientes de la curva y p es la característica del campo primo sobre el cual está definida la curva.)

E : y² ≡ x³ + ax + b (mod p)

El orden de E es siempre de la forma f q para algún primo q y f se denomina cofactor. PACE v2 exige la generación de un punto que pertenece al subgrupo q de E que indicamos con E[q]. La codificación de puntos también toma como entrada un número t tal que:

(El orden de E es siempre de la forma f q para algún primo q y f se denomina cofactor. PACE (Password Authenticated Connection Establishment = Establecimiento de conexión autenticada por contraseña) v2 exige la creación de un punto que pertenezca al subgrupo q de E que indicamos con E[q]. La codificación de puntos también utiliza como entrada un número t tal que:)

0 < t < p

y devuelve, en tiempo constante, un punto que pertenece a E[q]. Según se describe en [BCIMRT2010], la codificación de puntos se presenta en dos tipos, dependiendo del sistema de coordenadas preferido por la implantación:

y devuelve, en tiempo constante, un punto que pertenece a E[q]. Según se describe en [BCIMRT2010], la codificación de puntos se presenta en dos tipos, dependiendo del sistema de coordenadas preferido por la instalación:

• Una primera implantación, que se describe en la sección B.2, tiene como salida el punto de curva elíptico en coordenadas afines (x, y);

(Una primera instalación, que se describe en la sección B.2, tiene como salida el punto de curva elíptico en coordenadas afines (x, y);)

• Otra implantación, que se presenta en la sección B.3, tiene como salida el mismo punto en coordenadas Jacobianas (X, Y, Z).

(Otra instalación, que se presenta en la sección B.3, tiene como salida el mismo punto en coordenadas Jacobianas (X, Y, Z).)

Cualquiera sea la opción adoptada, el punto generado es idéntico en el sentido de que

(Cualquiera sea la opción tomada, el punto creado es idéntico en el sentido de que)

x = XZ^{– 2} mod p y y= YZ^-3 mod p

y la implantación de la fase subsiguiente de PACE v2 (la fase de intercambio de claves Diffie-Hellman de curva elíptica) puede por lo tanto aprovechar el uso de la opción que mejor corresponda a la interfaz de la API criptográfica que realiza las operaciones de curva elíptica.

(y la instalación de la fase subsiguiente de PACE v2 (la fase de intercambio de claves Diffie-Hellman de curva elíptica) puede por lo tanto aprovechar el uso de la opción que mejor corresponda a la interfaz de la API criptográfica que realiza las operaciones de curva elíptica.)

Como se observa a continuación, la codificación de puntos para coordenadas afines requiere aproximadamente dos exponenciaciones modulares en módulo p mientras que la codificación de puntos para coordenadas Jacobianas requiere solamente una.

(Como se observa a continuación, la codificación de puntos para coordenadas afines exige aproximadamente dos exponenciaciones modulares en módulo p mientras que la codificación de puntos para coordenadas Jacobianas exige solamente una.)

Obsérvese que para las dos implantaciones disponibles, la codificación de puntos requiere explícitamente que p ≡ 3 mod 4.

(Obsérvese que para las dos instalaciones disponibles, la codificación de puntos exige expresamente que p ≡ 3 mod 4.)

B.2 IMPLANTACIÓN PARA COORDENADAS AFINES

El algoritmo se implanta como sigue:

(El algoritmo se instala como sigue:)

Entradas : parámetros de curva (a, b, p, f ) y t tal que 0 < t < p

Salida : un punto (x, y) en el subgrupo de orden primo E[q] de E

1. Calcular α = -t² mod p

2. Calcular X₂ = -ba^-1(1+(α+α²) ^-1) mod p

3. Calcular X₃ = α X₂ mod p

4. Calcular h₂ = (X₂)³+ a X₂ + b mod p

5. Calcular h₃ = (X₃)³+ a X₃ + b mod p

6. Calcular U = t³ h₂ mod p

7. Calcular A = (h₂) ^p-1-(p+1)/4 mod p

8. Si A² h₂=1 mod p defínase (x, y) = (X₂, A h₂ mod p)

9. En caso contrario defínase (x, y) = (X₃, A U mod p)

10. Salida (x, y) = [f ] (x, y).

Notas sobre la implantación

Sin contar las multiplicaciones y adiciones modulares, el tiempo de ejecución de la implantación anterior está dominado por dos exponenciaciones modulares:

(Sin contar las multiplicaciones y adiciones modulares, el tiempo de ejecución de la istalación anterior está dominado por dos exponenciaciones modulares:)

• la Etapa 2 puede escribirse

X₂ = -ba^-1(1+(α+α²) ^-1) = -b(1+α+α²) (a(α+α²)) ^p-2 mod p

que esencialmente significa una exponenciación modular con exponente p-2;

• la Etapa 7 es una exponenciación modular con exponente p-1-(p+1)/4

Nota.— La Etapa 10 requiere una multiplicación escalar por el cofactor f. Para muchas curvas, el cofactor es igual a 1 de modo que esta multiplicación escalar puede evitarse.

(Nota.— La Etapa 10 necesita una multiplicación escalar por el cofactor f. Para muchas curvas, el cofactor es igual a 1 de modo que esta multiplicación escalar puede evitarse.)

B.3 IMPLANTACIÓN PARA COORDENADAS JACOBIANAS

El algoritmo se implanta como sigue:

(El algoritmo se instala como sigue:)

Entradas : parámetros de curva (a, b, p, f) y t tal que 0 < t < p

(Entradas : criterios de curva (a, b, p, f) y t tal que 0 < t < p)

Salida : un punto (X, Y, Z) en el subgrupo E de orden primo E[q] de E

1. Calcular α = -t² mod p

2. Calcular Ζ = a(α+α²) mod p

3. Calcular X₂ = -bΖ (1+α+α²) mod p

4. Calcular X₃ = α X₂ mod p

5. Calcular h₂ = (X₂)³+ a X₂ Z⁴+ b Z⁶ mod p

6. Calcular h₃ = (X₃)³+ a X₃ Z⁴ + b Z⁶ mod p

7. Calcular U = -α t h₂ mod p

8. Calcular A = (h₂) ^p-1-(p+1)/4 mod p

9. Si A² h₂=1 mod p defínase (X, Y, Z) = (X₂, A h₂ mod p, Z)

10. En caso contrario defínase (X, Y, Z) = (X₃, A U mod p, Z)

11 Salida (X, Y, Z) = [f ]( X, Y, Z ).

Notas sobre la implantación

Sin contar las multiplicaciones y adiciones modulares, el tiempo de ejecución de la implantación anterior está dominado por la única exponenciación modular de la Etapa 7. Por consiguiente, se prevé que sea aproximadamente el doble de rápido que la implantación para coordenadas afines.

(Sin contar las multiplicaciones y adiciones modulares, el tiempo de ejecución de la instalación anterior está dominado por la única exponenciación modular de la Etapa 7. Por consiguiente, se prevé que sea aproximadamente el doble de rápido que la instalación para coordenadas afines.)

Nota.— La multiplicación escalar de la Etapa 10 puede evitarse completamente cuando el cofactor f es igual a 1.

(sigue la sección 4 de la Parte 11 del documento 9303)

DH

La función Map:g → ĝ se define como ĝ = f_g(R_p(s,t)), donde Rp() es una función pseudoaleatoria que transforma cadenas de octetos en elementos de GF(p) y fg() es la función que transforma elementos de GF(p) en <g>. El nonce t aleatorio se ELEGIRÁ en forma aleatoria por el sistema de inspección y se enviará a la microplaqueta eMRTD. La función pseudoaleatoria Rp() se describe a continuación. La función fg() se define como fg(x)=x^a mod p, y a = (p-1)/q es el cofactor. Las implantaciones DEBEN verificar ĝ ≠ 1.

(La función Map:g → ĝ se define como ĝ = f_g(R_p(s,t)), donde Rp() es una función pseudoimpredecible que transforma cadenas de octetos en elementos de GF(p) y fg() es la función que transforma elementos de GF(p) en <g>. El nonce t impredecible se ELEGIRÁ en forma impredecible por el sistema de inspección y se enviará a la microplaqueta eMRTD. La función pseudoimpredecible Rp() se describe a continuación. La función fg() se define como fg(x)=x^a mod p, y a = (p-1)/q es el cofactor. Las instalaciones DEBEN comprobar ĝ ≠ 1.)

Correspondencia de números pseudoaleatorios

La función Rp(s,t) es una función que transforma cadenas de octetos s (de longitud de bits l) y t (de longitud de bits k) en un elemento int(x₁||x₂||…||x_n) mod p of GF(p). La función Rp(s,t) se especifica a continuación en la figura 2.

La construcción se basa en el respectivo cifrado de bloques E() en modo CBC con arreglo a [ISO/IEC 10116] con IV=0, donde k_i es el tamaño de clave (en bits) de E(). Cuando se requiera, el resultado ki DEBE truncarse para llevarlo a un tamaño de clave k. El valor n se SELECCIONARÁ como número más pequeño, de modo que n*l ≥ log2 p + 64.

(La construcción se basa en el respectivo cifrado de bloques E() en modo CBC (Cadena de bloques cifrados) de acuerdo con [ISO/IEC 10116] con IV=0 (IV = Initial Vector = Vector inicial), donde k es el tamaño de clave (en bits) de E(). Cuando se necesite, el resultado k_i DEBE abreviarse para llevarlo a un tamaño de clave k. El valor n se SELECCIONARÁ como número más pequeño, de modo que n*l ≥ log2 p + 64.)

Nota.— El truncamiento solo es necesario para AES-192: Se emplean octetos de 1 a 24 de k_i ; no se utilizan octetos adicionales. En caso de DES, k se considera igual a 128 bits, y el resultado de R(s,t) será de 128 bits.

(Nota.— La abreviación solo es necesaria para AES-192 (AES= Advanced Encryption Standard = Norma criptográfica avanzada). Se utilizan octetos de 1 a 24 de k_i ; no se utilizan octetos adicionales. En caso de DES (Data Encryption Standard = Norma de cifrado de datos) k se entiende igual a 128 bits, y el resultado de R(s,t) será de 128 bits.)

Figura 2. Correspondencia de números pseudoaleatorios

Las constantes c₀ y c₁ se definen como sigue:

• Para 3DES y AES-128 (l=128):

– c0=0xa668892a7c41e3ca739f40b057d85904

– c1=0xa4e136ac725f738b01c1f60217c188ad

• Para AES-192 y AES-256 (l=256):

– c0=

0xd463d65234124ef7897054986dca0a174e28df758cbaa03f240616414d5a1676

– c1=

0x54bd7255f0aaf831bec3423fcf39d69b6cbf066677d0faae5aadd99df8e53517

4.4.3.3.3 Correspondencia de autenticación de microplaqueta

La fase de correspondencia del PACE-CAM es idéntica a la fase de correspondencia de PACE-GM (véase la sección 4.4.3.3.1).

4.4.3.4 Testigo de autenticación

El testigo de autenticación se CALCULARÁ sobre un objeto de datos de clave pública (véase la sección 9.4) que contiene el identificador de objeto según se indica en MSE:Set AT (véase la sección 4.4.4.1) y la clave pública efímera recibida (es decir, excluyendo los parámetros de dominio, véase la sección 9.4.5) utilizando un código de autenticación y la clave KSMAC obtenida del acuerdo de claves.

(El testigo de autenticación se CALCULARÁ sobre un objeto de datos de clave pública (véase la sección 9.4) que incluye el identificador de objeto como se indica en MSE:Set AT (véase la sección 4.4.4.1) y la clave pública breve recibida (es decir, excluyendo los criterios de dominio, véase la sección 9.4.5) utilizando un código de autenticación y la clave KSMAC obtenida del acuerdo de claves.)

La sección 9.4 de la Parte 11 del documento 9303 recoge:

9.4 Objetos de datos de clave pública

Un objeto de datos de clave pública es una estructura BER TLV construida que contiene un identificador de objeto y varios objetos de datos específicos del contexto anidados dentro de la plantilla de clave pública del titular de la tarjeta 0x7F49.

(Un objeto de datos de clave pública es una estructura BER (Basic Encoding Rules = Reglas de codificación básicas) TLV (Tag Length Value = Valor de longitud de rótulo) construida que incluye un identificador de objeto y varios objetos de datos específicos del contexto alojados dentro de la plantilla de clave pública del titular de la tarjeta 0x7F49.)

• El identificador de objeto es específico de cada aplicación y se refiere no solamente al formato de clave pública (es decir, los objetos de datos específicos de contexto) sino también a su uso.

(El identificador de objeto es específico de cada aplicación y se refiere no solamente al modelo de clave pública (es decir, los objetos de datos específicos de contexto) sino también a su uso.)

• Los objetos de datos específicos del contexto son definidos por el identificador de objeto y contienen el valor de clave pública y los parámetros de dominio.

(Los objetos de datos específicos del contexto son definidos por el identificador de objeto e incluyen el valor de clave pública y los criterios de dominio.)

El formato de los objetos de datos de clave pública utilizados en esta especificación se describe a continuación.

(El modelo de los objetos de datos de clave pública utilizados en esta determinación se describe a continuación.)

9.4.1 Codificación del objeto de datos

Un entero sin signo se CONVERTIRÁ en una cadena de octetos utilizando la representación binaria del entero en un formato big-endian. Se UTILIZARÁ el número mínimo de octetos, es decir, NO DEBEN utilizarse los octetos iniciales de valor 0x00.

Para codificar puntos de curva elíptica, se UTILIZARÁ la codificación no comprimida con arreglo a [TR-03111].

(Para codificar puntos de curva elíptica, se UTILIZARÁ la codificación no comprimida de acuerdo con [TR-03111].)

9.4.2 Claves públicas RSA

En la tabla 9 se muestran los objetos de datos contenidos en una clave pública RSA. El orden de los objetos de datos es fijo.

(En la tabla 9 se muestran los objetos de datos incluidos en una clave pública RSA. El orden de los objetos de datos es fijo.)

Tabla 9. Clave pública RSA

9.4.3 Claves públicas Diffie Hellman

Los objetos de datos contenidos en una clave pública DH se muestran en la tabla 10. El orden de los objetos de datos es fijo.

(Los objetos de datos incluidos en una clave pública DH se muestran en la tabla 10. El orden de los objetos de datos es fijo.)

Tabla 10. Objetos de datos para claves públicas DH

Nota.— La codificación de los componentes de la clave como enteros no firmados implica que cada uno de ellos se codifica sobre el menor número de bytes posible, es decir, sin los bytes precedentes puestos a 0x00. En particular, la clave pública DH puede codificarse sobre un número de bytes menor que el número de bytes del primo.

(Nota.— La codificación de los componentes de la clave como enteros no firmados conlleva que cada uno de ellos se codifica sobre el menor número de bytes posible, es decir, sin los bytes precedentes puestos a 0x00. En concreto, la clave pública DH puede codificarse sobre un número de bytes menor que el número de bytes del primo.)

9.4.4 Claves públicas de curva elíptica

Los objetos de datos contenidos en una clave pública EC se muestran en la tabla 11. El orden de los objetos de datos es fijo, los parámetros de dominio CONDICIONALES DEBEN estar todos presentes, excepto el cofactor, o todos ausentes como sigue:

(Los objetos de datos incluidos en una clave pública EC se muestran en la tabla 11. El orden de los objetos de datos es fijo, los criterios de dominio CONDICIONALES DEBEN estar todos presentes, excepto el cofactor, o todos ausentes como sigue:)

Tabla 11. Objetos de datos para claves públicas ECDH

9.4.5 Claves públicas efímeras

Esta subsección se ha reproducido anteriormente.

(sigue la sección 4 de la Parte 11 del documento 9303)

Nota.— El código de autenticación de mensajes ejecuta internamente el relleno, es decir, no se ejecuta relleno específico de la aplicación.

(Nota.— El código de autenticación de mensajes ejecuta internamente el relleno, es decir, no se ejecuta relleno propio de la aplicación.)

3DES

Se UTILIZARÁ 3DES [FIPS 46-3] en modo minorista con arreglo a [ISO/IEC 9797-1] MAC algoritmo 3 / relleno método 2 con cifrado de bloque DES y IV=0.

AES

La AES [FIPS 197] se UTILIZARÁ en modo CMAC [SP 800-38B] con una longitud MAC de 8 bytes.

4.4.3.5 Datos de autenticación de microplaqueta cifrados

La microplaqueta eMRTD DEBE proporcionar pares de claves estáticas SKIC, PKIC según se describe en la sección 6.2. Los datos de autenticación de claves cifrados se EXIGEN para PACE con correspondencia de autenticación de microplaqueta.

(La microplaqueta eMRTD DEBE suministrar pares de claves estáticas SKIC, PKIC como se describe en la sección 6.2. Los datos de autenticación de claves cifrados se EXIGEN para PACE con correspondencia de autenticación de microplaqueta.)

4.4.3.5.1 Generación por la microplaqueta eMRTD

Los datos de autenticación de microplaqueta se CALCULARÁN como CAIC = (SKIC)^-1 * SKMap,IC mod p, donde SKIC es laclave privada estática de la microplaqueta, SKMap, IC es la clave privada efímera utilizada por la microplaqueta para calcular H en la etapa de correspondencia de PACE (véase la sección 4.4.3.3.1) y p es el orden del grupo criptográfico utilizado. Los datos de autenticación de microplaqueta se CIFRARÁN utilizando la clave KSEnc obtenida del acuerdo de clave como AIC = E(KSEnc, CAIC) para producir los datos de autenticación de microplaqueta cifrado.

(Los datos de autenticación de microplaqueta se CALCULARÁN como CAIC = (SKIC)^-1 * SKMap,IC mod p, donde SKIC es laclave privada estática de la microplaqueta, SKMap, IC es la clave privada breve utilizada por la microplaqueta para calcular H en la etapa de correspondencia de PACE (véase la sección 4.4.3.3.1) y p es el orden del grupo criptográfico utilizado. Los datos de autenticación de microplaqueta se CIFRARÁN utilizando la clave KSEnc obtenida del acuerdo de clave como AIC = E(KSEnc, CAIC) para producir los datos de autenticación de microplaqueta cifrado.)

Nota.— (SKIC)^-1 puede calcularse previamente durante la personalización de la microplaqueta eMRTD y almacenarse en forma segura en la microplaqueta, evitando la inversión modular durante el tiempo de ejecución.

4.4.3.5.2 Verificación por el terminal

El terminal DESCIFRARÁ AIC para recuperar CAIC y verificar PKMap,IC = KA(CAIC, PKIC, DIC), donde PKIC es la clave pública estática de la microplaqueta eMRTD.

(El terminal DESCIFRARÁ AIC para recuperar CAIC y comprobar PKMap,IC = KA(CAIC, PKIC, DIC), donde PKIC es la clave pública estática de la microplaqueta eMRTD.)

Nota.— La autenticación pasiva DEBE realizarse en combinación con la correspondencia de autenticación de microplaqueta. Solo después de una validación exitosa del objeto de seguridad respectivo puede considerarse que la microplaqueta eMRTD es genuina.

(Nota.— La autenticación pasiva DEBE realizarse conjuntamente con la correspondencia de autenticación de microplaqueta. Solo después de una aprobación exitosa del objeto de seguridad respectivo puede concluirse que la microplaqueta eMRTD es auténtica.)

4.4.3.5.3 Relleno

Los datos que han de cifrarse se RELLENARÁN con arreglo a [ISO/IEC 9797-1] “Método de relleno 2”.

4.4.3.5.4 AES

La AES [19] se UTILIZARÁ en modo CBC con arreglo a [ISO/IEC 10116] con IV=E(KSEnc,^-1), donde -1 es la cadena de bits de longitud 128 con todos los bits puestos a 1.

4.4.4 Unidades de datos de protocolo de aplicación

Se UTILIZARÁ la siguiente secuencia de comandos para implantar PACE:

(Se UTILIZARÁ la siguiente secuencia de comandos para instalar PACE:)

1. MSE:Set AT

2. GENERAL AUTHENTICATE

4.4.4.1 MSE:Set AT

El comando MSE:Set AT se utiliza para seleccionar e inicializar el protocolo PACE. El uso de MSE:Set AT para el PACE se indica mediante un identificador de objeto PACE (véanse las secciones 4.4.3 y 9.2.3) que figura como referencia de mecanismo criptográfico con el rótulo 0x80, como se muestra en la siguiente tabla.

Nota 1.— Algunos sistemas de operación aceptan la selección de una clave no disponible y devuelven un error sólo cuando la clave se utiliza para el fin seleccionado.

Nota 2.— Para el comando MSE:Set, el IC DEBERÍA hacer caso omiso de los objetos de datos con rótulos no especificados para este comando. La terminal NO DEBERÍA incluir objetos de datos con rótulos desconocidos para que los entienda el IC.

(Nota 2.— Para el comando MSE:Set, el IC DEBERÍA hacer caso omiso de los objetos de datos con rótulos no determinados para este comando. La terminal NO DEBERÍA incluir objetos de datos con rótulos desconocidos para que los entienda el IC.)

4.4.4.2 GENERAL AUTHENTICATE

Se utiliza una cadena de comandos GENERAL AUTHENTICATE para ejecutar el protocolo PACE.

4.4.4.3 Encadenamiento de órdenes

El encadenamiento de comandos DEBE utilizarse para que el comando GENERAL AUTHENTICATE enlace la secuencia de comandos con la ejecución del protocolo. El encadenamiento de órdenes NO DEBE utilizarse para otros fines a menos que se indique claramente en la microplaqueta. En la [ISO/IEC 7816-4] figuran detalles sobre el encadenamiento de comandos.

4.4.5 Datos intercambiados

Los objetos de datos específicos del protocolo se INTERCAMBIARÁN en una cadena de comandos GENERAL AUTHENTICATE, con los datos de comando y respuesta específicos del protocolo encapsulado en un objeto de datos de autenticación dinámica (véase la sección 4.4.4.2) con rótulos específicos de contexto según se indica en la tabla 4.

(Los objetos de datos concretos del protocolo se INTERCAMBIARÁN en una cadena de comandos GENERAL AUTHENTICATE, con los datos de comando y respuesta concretos del protocolo encapsulado en un objeto de datos de autenticación dinámica (véase la sección 4.4.4.2) con rótulos concretos de contexto según se indica en la tabla 4.)

Tabla 4. Datos intercambiados para PACE

La(s) referencia(s) de la autoridad de certificación DEBE(N) estar presente(s) si se transmitió un objeto de datos 0x7F4C al IC durante el establecimiento del PACE (cf. sección 4.4.4.1) y la autenticación del terminal es admitida por el IC. En este caso, el objeto de datos 0x87 CONTENDRÁ la referencia de la autoridad de certificación más reciente. El objeto de datos 0x88 PUEDE contener la referencia de la autoridad de certificación previa.

(La(s) referencia(s) de la autoridad de certificación DEBE(N) estar presente(s) si se transmitió un objeto de datos 0x7F4C al IC durante el establecimiento del PACE (cf. sección 4.4.4.1) y la autenticación del terminal es admitida por el IC. En este caso, el objeto de datos 0x87 INCLUIRÁ la referencia de la autoridad de certificación más reciente. El objeto de datos 0x88 PUEDE incluir la referencia de la autoridad de certificación anterior.)

Los datos de autenticación de microplaqueta cifrados (véase la sección 4.4.3.5) DEBEN estar presentes si se utiliza correspondencia de autenticación de microplaqueta y NO DEBEN estar presentes en otros casos.

4.4.5.1 Nonce cifrado

El nonce cifrado (véase la sección 4.4.3.3) se CODIFICARÁ como cadena de octeto.

4.4.5.2 Datos de correspondencia

Los datos intercambiados son específicos de la correspondencia utilizada:

(Los datos intercambiados son propios de la correspondencia utilizada:)

4.4.5.2.1 Correspondencia genérica

Las claves públicas efímeras (véanse la sección 4.4.3.3 y la sección 9.4.5 se CODIFICARÁN como punto de curva elíptica (ECDH) o entero sin signo (DH).

(Las claves públicas breves (véanse la sección 4.4.3.3 y la sección 9.4.5 se CODIFICARÁN como punto de curva elíptica (ECDH) o entero sin signo (DH).)

4.4.5.2.2 Correspondencia integrada

El nonce t se CODIFICARÁ como cadena de octetos.

Nota.— El objeto de datos específico del contexto 0x82 ESTARÁ vacío para la correspondencia integrada.

(Nota.— El objeto de datos propio del contexto 0x82 ESTARÁ vacío para la correspondencia incluida.)

4.4.5.2.3 Correspondencia de autenticación de microplaqueta

La codificación de los datos de correspondencia es idéntica a la correspondencia genérica (véase la sección 4.4.5.2.1).

4.4.5.3 Claves públicas

Las claves públicas se CODIFICARÁN según se describe en la sección 9.4.5

4.4.5.4 Testigo de autenticación

El testigo de autenticación (véase la sección 4.4.3.4) se CODIFICARÁ como cadena de octetos.

4.4.5.5 Referencia de la autoridad de certificación

Los objetos de datos de la referencia de la autoridad de certificación (CAR) SE CODIFICARÁN según se especifica en el Doc 9303-12.

(Los objetos de datos de la referencia de la autoridad de certificación (CAR) SE CODIFICARÁN según se concreta en el Doc 9303-12.)

4.4.5.6 Datos de autenticación de microplaqueta

Los datos de autenticación de microplaqueta se CODIFICARÁN como cadena de octetos utilizando la función FE2OS() especificado en [TR-03111] antes del cifrado. Obsérvese que FE2OS() exige que la codificación tenga el mismo número de octetos que el orden primo del grupo, es decir, posiblemente incluyendo 0x00 iniciales. Los datos de autenticación de microplaqueta cifrados se CODIFICARÁN como cadena de octetos.

(Los datos de autenticación de microplaqueta se CODIFICARÁN como cadena de octetos utilizando la función FE2OS() detallado en [TR-03111] antes del cifrado. Obsérvese que FE2OS() exige que la codificación tenga el mismo número de octetos que el orden primo del grupo, es decir, posiblemente incluyendo 0x00 iniciales. Los datos de autenticación de microplaqueta cifrados se CODIFICARÁN como cadena de octetos.)

(sigue la sección 3 de la Parte 11 del documento 9303)

2. Autenticación de los datos (sección 5)
3. Autenticación de la microplaqueta (sección 6)
4. Mecanismos de control de acceso adicionales (sección 7)
5. Lectura de los datos (véase el Doc 9303-10).

Se dispone de diferentes protocolos para las diferentes etapas. La configuración exacta del eMRTD es determinada por el Estado expedidor u organización expedidora. Las opciones presentadas en la tabla 1 pueden combinarse adecuadamente para lograr una seguridad adicional con arreglo a las necesidades de los expedidores.

(Se dispone de diferentes protocolos para las diferentes etapas. La configuración exacta del eMRTD es determinada por el Estado emisor u organización emisora. Las opciones presentadas en la tabla 1 pueden combinarse adecuadamente para lograr una seguridad adicional en función de las necesidades de los emisores.)

En el apéndice J se describen los procedimientos de inspección para diferentes configuraciones de los eMRTD.

Tabla 1. Seguridad de los datos electrónicos (Resumen)

Nota.— En la sección 4 figuran detalles sobre configuraciones normalizadas de CI sin contacto con respecto a la implantación del control de acceso de base y al establecimiento de conexión autenticada por contraseña.

(Nota.— En la sección 4 figuran detalles sobre configuraciones normalizadas de CI sin contacto con respecto a la instalación del control de acceso de base y al establecimiento de conexión autenticada por contraseña.)

La implantación de los métodos de seguridad avanzados que figuran en la Tabla 1 no afecta el cumplimiento de las normas de la OACI.

(La instalación de los métodos de seguridad avanzados que figuran en la Tabla 1 no afecta el cumplimiento de las normas de la OACI.)

(sigue la sección 3 de la Parte 10 del Documento 9303)

Si están presentes aplicaciones de la LDS2 opcionales, el eMRTD ADMITIRÁ adicionalmente las siguientes órdenes:

Para la aplicación de los registros de viaje:

READ RECORD (LEER REGISTRO);

APPEND RECORD (ADJUNTAR REGISTRO);

SEARCH RECORD (BUSCAR EN REGISTRO);

FILE AND MEMORY MANAGEMENT (GESTIÓN DE FICHEROS Y MEMORIA);

PERFORM SECURITY OPERATION (PSO) (REALIZAR OPERACIONES DE SEGURIDAD).

Para la aplicación de los registros de visados:

READ RECORD (LEER REGISTRO);

APPEND RECORD (AÑADIR REGISTRO);

SEARCH RECORD (BUSCAR EN REGISTRO);

FILE AND MEMORY MANAGEMENT (GESTIÓN DE FICHEROS Y MEMORIA);

PERFORM SECURITY OPERATION (PSO) (REALIZAR OPERACIONES DE SEGURIDAD).

Para la aplicación de los datos biométricos adicionales:

UPDATE BINARY (ACTUALIZAR BINARIO);

READ RECORD (LEER REGISTRO);

APPEND RECORD (ADJUNTAR REGISTRO);

SEARCH RECORD (BUSCAR EN REGISTRO);

ACTIVATE (ACTIVAR);

FILE AND MEMORY MANAGEMENT (GESTIÓN DE FICHEROS Y MEMORIA);

PERFORM SECURITY OPERATION (PSO) (REALIZAR OPERACIONES DE SEGURIDAD).

En el Doc 9303-11 figuran más detalles sobre los protocolos de comandos.

3.5.1 SELECT

La LDS1 del eMRTD admite dos métodos de selección de estructura, concretamente el identificador de fichero y el identificador EF breve. Los lectores admiten por lo menos uno de ambos métodos. El identificador de fichero y el identificador EF breve son OBLIGATORIOS para el sistema operacional del CI sin contacto, pero son opcionales para el lector.

3.5.2 READ BINARY

El apoyo al comando READ BINARY con un byte INS impar por un eMRTD es CONDICIONAL. El eMRTD APOYARÁ esta variedad de comando si apoya los grupos de datos con 32 768 bytes o más.

3.6 Formatos de comandos y opciones de parámetros (LDS1 y LDS2)

3.6.1 Selección del DF de la aplicación por medio del comando SELECT

Las aplicaciones tienen que seleccionarse por su nombre DF que indica el identificador de la aplicación (AID). Después de la selección de una aplicación puede accederse al fichero que está dentro de dicha aplicación.

(Las aplicaciones tienen que seleccionarse por su nombre DF (Dedicated File = Fichero especializado) que indica el identificador de la aplicación (AID = Application Identifier = Identificador de aplicación). Después de la selección de una aplicación puede accederse al fichero que está dentro de dicha aplicación.)

Nota.— Los nombres DF tienen que ser únicos. Por consiguiente, la selección de una aplicación utilizando el nombre del DF puede efectuarse desde donde se requiera.

(Nota.— Los nombres DF tienen que ser únicos. Por consiguiente, la selección de una aplicación utilizando el nombre del DF puede efectuarse desde donde se necesite.)

3.6.1.1 Selección de fichero maestro

Tabla 1. Comando SELECT para la selección del MF

Respuesta para el comando SELECT

Nota.— Se RECOMIENDA no utilizar el comando SELECT MF.

3.6.1.2 Selección del DF de la aplicación

Se seleccionará un DF de la aplicación utilizando el comando SELECT con el nombre DF que indica el identificador de la aplicación (AID). A continuación se muestran los parámetros para el comando de la unidad de datos de protocolo de aplicación (APDU):

Tabla 2. Comando SELECT con AID para la selección del DF de la aplicación

Respuesta para el comando SELECT

3.6.2 Selección del EF mediante el comando SELECT

El EF se selecciona por medio del comando SELECT con identificador EF. Cuando se selecciona el EF, es preciso asegurarse de que se ha seleccionado previamente el DF de la aplicación que almacena el EF.

(El EF (Elementary File = Fichero elemental) se selecciona por medio del comando SELECT con identificador EF. Cuando se selecciona el EF, es preciso asegurarse de que se ha seleccionado previamente el DF de la aplicación que almacena el EF.)

Tabla 3. Comando SELECT con identificador de fichero para la selección de EF

Respuesta para el comando SELECT

El eMRTD APOYARÁ el comando SELECT con el identificador de fichero según se especifica en la Tabla 3. El sistema de inspección APOYARÁ por lo menos uno de los métodos siguientes:

(El eMRTD APOYARÁ el comando SELECT con el identificador de fichero según se detalla en la Tabla 3. El sistema de inspección APOYARÁ por lo menos uno de los métodos siguientes:)

• el comando SELECT con identificador de fichero según se especifica en la Tabla 3;

• el comando READ BINARY con código INS par y un identificador EF breve según se especifica en la tabla 5.

3.6.3 Lectura de datos del EF (READ BINARY)

Existen dos métodos principales para leer los datos del eMRTD: seleccionar el EF y luego leer los datos del EF seleccionado o leer los datos directamente utilizando el identificador EF breve (SFI). Para el eMRTD es OBLIGATORIO admitir el identificador EF breve; por ello, se RECOMIENDA que el sistema de inspección utilice el identificador EF breve.

3.6.3.1 Lectura de datos de un EF seleccionado (fichero transparente)

Tabla 4. Comando READ BINARY para un EF seleccionado

Respuesta para el comando READ BINARY

3.6.3.2 Lectura de datos mediante el identificador EF (fichero transparente)

Tabla 5. Comando READ BINARY con identificador EF breve

Respuesta para el comando READ BINARY

3.6.4 Apoyo Lc/Le ampliado

Dependiendo del tamaño de los objetos criptográficos (p. ej., claves públicas, firmas), las APDU con campos de longitud ampliada DEBEN utilizarse para enviar estos datos a la microplaqueta del eMRTD. Los detalles sobre los campos de longitud ampliada figuran en la [ISO/IEC 7816-4].

3.6.4.1 Longitud ampliada y microplaquetas de eMRTD

Para las microplaquetas de eMRTD, el apoyo del campo de longitud ampliada es CONDICIONAL. Si los algoritmos criptográficos y los tamaños de claves seleccionados por el Estado expedidor exigen el uso del campo de longitud ampliada, las microplaquetas del eMRTD ADMITIRÁN el campo de longitud ampliada. Si la microplaqueta del eMRTD admite el campo de longitud ampliada, DEBE indicarse en ATS o en EF.ATR/INFO, según se especifica en [ISO/IEC 7816-4].

(Para las microplaquetas de eMRTD, el apoyo del campo de longitud ampliada es CONDICIONAL. Si los algoritmos criptográficos y los tamaños de claves seleccionados por el Estado emisor exigen el uso del campo de longitud ampliada, las microplaquetas del eMRTD ADMITIRÁN el campo de longitud ampliada. Si la microplaqueta del eMRTD admite el campo de longitud ampliada, DEBE indicarse en ATS o en EF.ATR/INFO, según se describe en [ISO/IEC 7816-4].)

3.6.4.2 Terminales

Para los terminales la admisión del campo de longitud ampliada es OBLIGATORIA. Un terminal DEBERÍA examinar si la admisión del campo de longitud ampliada se indica en el ATR/ATS de la microplaqueta del eMRTD o en EF.ATR/INFO antes de utilizar esta opción. El terminal NO DEBE utilizar el campo de longitud ampliada para las APDU con comandos distintos de los siguientes a menos que el tamaño exacto de la memoria intermedia de entrada y de salida de la microplaqueta del eMRTD esté explícitamente declarado en ATS o en EF.ATR/INFO.

(Para los terminales la admisión del campo de longitud ampliada es OBLIGATORIA. Un terminal DEBERÍA examinar si la admisión del campo de longitud ampliada se indica en el ATR/ATS de la microplaqueta del eMRTD o en EF.ATR/INFO antes de utilizar esta opción. El terminal NO DEBE utilizar el campo de longitud ampliada para las APDU con comandos distintos de los siguientes salvo que el tamaño exacto de la memoria intermedia de entrada y de salida de la microplaqueta del eMRTD esté expresamente declarado en ATS o en EF.ATR/INFO.)

• MSE: Set KAT;

• GENERAL AUTHENTICATE

3.6.5 Encadenamiento de comandos

El encadenamiento de comandos DEBE utilizarse para que el comando GENERAL AUTHENTICATE enlace la secuencia de comandos con la ejecución del protocolo. El encadenamiento de comandos NO DEBE utilizarse para otros fines a menos que se indique claramente en la microplaqueta. En la [ISO/IEC 7816-4] figuran detalles sobre encadenamiento de comandos.

3.6.6 EF mayor de 32 767 bytes

El tamaño máximo de un EF es normalmente 32 767 bytes, pero algunos CI apoyan ficheros mayores. Se requiere un formato de comando y una opción de parámetro READ BINARY diferentes para tener acceso a la suma de datos cuando el desplazamiento es mayor de 32 767. Este formato de comando DEBERÍA utilizarse después de haberse determinado la longitud de la plantilla y la necesidad de acceder a los datos en la zona de datos ampliada. Por ejemplo, si la zona de datos contiene objetos de datos biométricos múltiples, puede no ser necesario leer toda la zona de datos. Una vez que el desplazamiento de la zona de datos sea mayor que 32 767, SE EMPLEARÁ este formato de comando. El desplazamiento se coloca en el campo de comandos en vez de en los parámetros P1 y P2.

(El tamaño máximo de un EF es normalmente 32 767 bytes, pero algunos CI admiten ficheros mayores. Se necesita un modelo de comando y una opción de criterio READ BINARY diferentes para tener acceso a la suma de datos cuando el desplazamiento es mayor de 32 767. Este modelo de comando DEBERÍA utilizarse después de haberse determinado la longitud de la plantilla y la necesidad de acceder a los datos en la zona de datos ampliada. Por ejemplo, si la zona de datos incluye objetos de datos biométricos múltiples, puede no ser necesario leer toda la zona de datos. Una vez que el desplazamiento de la zona de datos sea mayor que 32 767, SE UTILIZARÁ este modelo de comando. El desplazamiento se coloca en el campo de comandos en vez de en los parámetros P1 y P2.)

Tabla 6. Formato de comando READ BINARY cuando el desplazamiento para EFes superior a 32 767 bytes

Respuesta para el comando READ BINARY

Tabla 7. Codificación en P1-P2 del comando READ BINARY con INS = B1

Este campo de longitud y el campo de valor en el objeto de datos BER-TLV son de longitud variable y pueden codificarse de diferentes maneras (véase [ISO/IEC 7816-4]: “campos de longitud BER-TLV”).

Por razones de actuación, la comunicación entre el eMRTD y el terminal DEBERÍA mantenerse lo más breve posible. Por consiguiente, los campos de longitud y de valor en el objeto de datos BER-TLV DEBERÍAN ser lo más breves posibles. Esto se aplica no solamente a los objetos de datos desplazados en las órdenes READ BINARY de INS impar sino también a todos los otros objetos de datos BER-TLV intercambiados entre el eMRTD y el terminal.

Ejemplos de desplazamiento codificado de campo de datos:

• Desplazamiento: ‘0001’ se codifica como rótulo = ‘54’ Longitud = ‘01’ valor = ‘01’;

• Desplazamiento: ‘FFFF’ se codifica como rótulo= ‘54’ Longitud = ‘02’ valor = ‘FFFF’.

Los siguientes comandos READ BINARY ESPECIFICARÁN el desplazamiento en el campo de datos. El comando READ BINARY final DEBERÍA pedir la zona de datos restante.

Con respecto a [ISO/IEC 7816-4], en el valor de desplazamiento no se especifican limitaciones cuando el bit 1 de INS se pone a 1 para permitir un uso más amplio.

(Con respecto a [ISO/IEC 7816-4], en el valor de desplazamiento no se describen limitaciones cuando el bit 1 de INS se pone a 1 para posibilitar un uso más amplio.)

Nota 1.— En algunos casos, hay eMRTD en los que los comandos B1 y el tradicional B0 READ Binary no podrían superponerse. En otras palabras, el B0 solo debería utilizarse para leer los primeros 32 767 bytes y el B1 los bytes de 32 K en adelante. Para otros fines podría haber una pequeña superposición de 256 bytes alrededor del umbral 32 767 para permitir una transición más fluida entre B0 y B1. Para este último grupo, B1 podría utilizarse a partir del mismo comienzo del fichero, es decir, con un desplazamiento a partir de 0 para permitir el uso de la misma orden a efectos de leer todo el contenido.

(Nota 1.— En algunos casos, hay eMRTD en los que los comandos B1 y el tradicional B0 READ Binary no podrían superponerse. En otras palabras, el B0 solo debería utilizarse para leer los primeros 32 767 bytes y el B1 los bytes de 32 K en adelante. Para otros fines podría haber una pequeña superposición de 256 bytes alrededor del límite 32 767 para posibilitar una transición más fluida entre B0 y B1. Para este último grupo, B1 podría utilizarse desde el mismo comienzo del fichero, es decir, con un desplazamiento desde de 0 para posibilitarr el uso de la misma orden a fin de leer todo el contenido.)

Nota 2.— El sistema de inspección no ha de utilizar el byte INS impar si el tamaño de una EF es de 32 767 bytes o menos.