En la Parte 3 del Documento 9303 de la OACI se recogen los detalles técnicos, que hemos reproducido anteriormente. La Parte 9 del Documento 9303 se refiere a la identificación biométrica:
3. IDENTIFICACIÓN BIOMÉTRICA
“Identificación biométrica” es un término genérico utilizado para describir medios automáticos de reconocer una persona viviente mediante la medición de rasgos fisiológicos o de comportamiento distintos.
Una “plantilla biométrica” es una representación codificada a máquina del rasgo en cuestión creada por un algoritmo de soporte lógico de computadora y que permite realizar comparaciones (cotejos) para medir el grado de confianza de que rasgos registrados por separado identifican (o no identifican) a la misma persona. Normalmente, una plantilla biométrica tiene un volumen de datos relativamente pequeño; no obstante, cada fabricante de sistemas biométricos emplea un formato de plantilla propio y las plantillas no son intercambiables entre sistemas. Para permitir que un Estado u organización seleccione el sistema biométrico que se adapte a sus necesidades, los datos deben almacenarse en una forma de la cual su sistema pueda obtener una plantilla. Esto exige que los datos biométricos se almacenen en forma de una o más imágenes.
(Una “plantilla biométrica” es una imagen codificada a máquina del rasgo interesado creada por un algoritmo de soporte lógico de computadora y que posibilita realizar comparaciones (cotejos) para medir el grado de confianza de que rasgos registrados por separado identifican (o no identifican) a la misma persona. Normalmente, una plantilla biométrica tiene una cantidad de datos relativamente pequeña; pese a ello, cada fabricante de sistemas biométricos utiliza un modelo de plantilla propio y las plantillas no son intercambiables entre sistemas. Para posibilitar que un Estado u organización seleccione el sistema biométrico que se adecúe a sus necesidades, los datos deben almacenarse en una forma de la cual su sistema pueda obtener una plantilla. Esto exige que los datos biométricos se almacenen en forma de una o más imágenes.)
3.1 Visión de la OACI respecto de la biometría
La visión de la OACI para la aplicación de la tecnología biométrica comprende:
(La visión de la OACI para la aplicación de la tecnología biométrica incluye:)
• la especificación de una forma principal interfuncional de la tecnología biométrica para utilizar en el control fronterizo (verificación, listas de vigilancia), así como por los transportistas y expedidores de documentos y la especificación de tecnologías biométricas complementarias convenidas;
(la determinación de una forma principal interfuncional de la tecnología biométrica para utilizar en el control fronterizo (comprobación, listas de vigilancia), así como por los transportistas y emisores de documentos y la determinación de tecnologías biométricas complementarias establecidas;)
• la especificación de las tecnologías biométricas que han de utilizar los expedidores de documentos (identificación, verificación y listas de vigilancia);
(la determinación de las tecnologías biométricas que han de utilizar los emisores de documentos (identificación, comprobación y listas de vigilancia);
• la capacidad de recuperación de datos por un período de 10 años, máxima validez recomendada para un documento de viaje;
• la ausencia de elementos patentados para asegurar que los Estados u organizaciones que invierten en la tecnología biométrica están protegidos contra cambios en la infraestructura o en los proveedores de la misma.
En el Doc 9303 se consideran solamente tres tipos de sistemas de identificación biométrica. Con respecto al almacenamiento de estos tres elementos biométricos en el CI sin contacto de un eMRTD, el Estado expedidor u organización expedidora se AJUSTARÁ a la norma internacional pertinente.
(En el Doc 9303 se tienen en cuenta solamente tres tipos de sistemas de identificación biométrica. Con respecto al almacenamiento de estos tres elementos biométricos en el CI (circuito integrado) sin contacto de un eMRTD, el Estado emisor u organización emisora se AJUSTARÁ a la norma internacional correspondiente.)
Los tipos de elementos biométricos son:
• reconocimiento del rostro – REQUERIDO
• reconocimiento de huella digital – OPCIONAL;
• reconocimiento del iris – OPCIONAL
La ISO/IEC 39794 sucedió a la ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Se ha definido el siguiente calendario de transición:
(La ISO/IEC 39794 sustituyó a la ISO/IEC 19794:2005 como norma internacional para la codificación biométrica. Se ha elaborado el siguiente calendario de transición:)
• los sistemas de inspección DEBEN poder manejar datos conforme a la ISO/IEC 39794 para el 1/1/2026, después de un período de preparación de seis años a partir del 1/1/2020;
(los sistemas de inspección DEBEN poder manejar datos de acuerdo con la ISO/IEC 39794 para el 1/1/2026, después de un período de preparación de seis años desde el 1/1/2020;)
• entre 2026 y 2030, los Estados expedidores u organizaciones expedidoras pueden emplear los formatos de datos especificados en ISO/IEC 19794-X:2005 o en ISO/IEC 39794-X durante un período de transición de cuatro años. Durante ese período de transición, serán esenciales las pruebas de interoperabilidad y conformidad;
(entre 2026 y 2030, los Estados emisores u organizaciones emisoras pueden utilizar los modelos de datos descritos en ISO/IEC 19794-X:2005 o en ISO/IEC 39794-X durante un período de transición de cuatro años. Durante ese período de transición, serán esenciales las pruebas de interfuncionamiento y adecuación;)
• del 1/1/2030 en adelante, los Estados expedidores u organizaciones expedidoras DEBERÁN emplear la ISO/IEC 39794-X para la codificación de datos biométricos.
(del 1/1/2030 en adelante, los Estados emisores u organizaciones emisoras DEBERÁN utilizar la ISO/IEC 39794-X para la codificación de datos biométricos.)
El Doc 9303, Parte 10, Enmienda 1, proporciona orientación acerca de la transición de la ISO/IEC 19794:2005 a la ISO/IEC 39794.
(El Doc 9303, Parte 10, Enmienda 1, suministra orientación sobre la transición de la ISO/IEC 19794:2005 a la ISO/IEC 39794.)
La Parte 10 del Documento 9303 recoge en su apartado 4 lo siguiente:
4. APLICACIÓN DE LA LDS1 PARA EL eMRTD (OBLIGATORIA)
La estructura LDS1 para el eMRTD proporciona espacio para almacenar y firmar en forma digital los elementos de datos obligatorios y opcionales que pueden usarse para vincular la persona titular al documento. La información almacenada en la LDS1 del eMRTD se vuelve estática en el momento de expedición y no puede modificarse de ninguna manera. Esta característica es necesaria para proteger la información personal y para que pueda detectarse más fácilmente la manipulación de documentos. Si bien la versión LDS1 del eMRTD incluye campos de datos opcionales que podrían usarse para ampliar el uso del eMRTD (i. e. datos biométricos adicionales, trámites fronterizos automatizados, etc.), el requisito de proteger la aplicación de la LDS1 presente en la microplaqueta del eMRTD contra la escritura en el momento de expedición es OBLIGATORIO.
(La estructura LDS1 (LDS = Logical Data Structure, estructura lógica de datos) para el eMRTD (documento de viaje de lectura mecánica electrónico) facilita espacio para almacenar y firmar en forma digital los componentes de datos obligatorios y opcionales que pueden usarse para relacionar la persona titular al documento. La información almacenada en la LDS1 del eMRTD se vuelve estática en el momento de puesta en circulación y no puede modificarse de ninguna manera. Esta característica es necesaria para proteger la información personal y para que pueda detectarse más fácilmente la manipulación de documentos. Si bien la versión LDS1 del eMRTD incluye campos de datos opcionales que podrían usarse para ampliar el uso del eMRTD (es decir, datos biométricos adicionales, trámites fronterizos mecánicos, etc.), el requisito de proteger la aplicación de la LDS1 presente en la microplaqueta del eMRTD contra la escritura en el momento de puesta en circulación es OBLIGATORIO.)
4.1 Selección de aplicación — DF
La aplicación de la LDS1 para el eMRTD SE SELECCIONARÁ utilizando la identificación de aplicación (AID) como nombre de DF reservado. La AID CONSISTIRÁ en el identificador de aplicación registrado asignado por la ISO con arreglo a [ISO/IEC 7816-5] y una extensión de identificador de aplicación de propiedad (PIX) especificada en este documento:
(La aplicación de la LDS1 para el eMRTD SE SELECCIONARÁ utilizando la identificación de aplicación (AID) como nombre de DF reservado. La AID CONSISTIRÁ en el identificador de aplicación registrado asignado por la ISO de acuerdo con [ISO/IEC 7816-5] y una extensión de identificador de aplicación de propiedad (PIX) descrita en este documento:)
• el identificador de aplicación registrado es ‘A000000247’;
• la aplicación de datos almacenados por el expedidor UTILIZARÁ PIX = ‘1001’;
(la aplicación de datos almacenados por el emisor UTILIZARÁ PIX = ‘1001’;)
• la AID completa de la aplicación de la LDS1 para el eMRTD es ‘A0 00 00 02 47 10 01’.
El CI DEBE rechazar la selección de una aplicación si la extensión de esa aplicación está ausente.
(El CI (circuito integrado) DEBE rechazar la selección de una aplicación si la extensión de esa aplicación está ausente.)
4.2 Plan de ordenamiento aleatorio
El plan de ordenamiento aleatorio permite registrar los grupos de datos y los elementos de datos siguiendo un orden aleatorio compatible con la posibilidad de la tecnología de ampliación de capacidad opcional, que permite la recuperación directa de elementos de datos específicos, incluso si se han registrado fuera de orden. Los elementos de datos de longitud variable se codifican como objetos de datos TLV especificados en ASN.1.
(El plan de ordenamiento imprevisible admite registrar los grupos de datos y los elementos de datos siguiendo un orden imprevisible que sea compatible con la posibilidad de la tecnología de ampliación de capacidad opcional, que posibilita la recuperación directa de elementos de datos concretos, incluso si se han registrado sin ordenar. Los elementos de datos de longitud cambiable se codifican como objetos de datos TLV especificados en ASN.1.)
4.3 Representación del fichero de acceso aleatorio
La representación del fichero de acceso aleatorio se ha definido sobre la base de las siguientes consideraciones e hipótesis
(La representación del fichero de acceso aleatorio se ha definido sobre la base de las siguientes valoraciones e hipótesis)
Para apoyar una amplia gama de implementaciones, la LDS comprende una gran variedad de elementos de datos opcionales. Estos elementos de datos se incluyen para facilitar la autenticación de la LDS1 del eMRTD y de la persona titular legítima y para acelerar el procesamiento en los distintos puntos de control de los documentos y personas.
(Para apoyar una amplia gama de implementaciones, la LDS incluye una gran variedad de elementos de datos opcionales. Estos elementos de datos se incluyen para facilitar la autenticación de la LDS1 del eMRTD y de la persona titular legítima y para acelerar el procesamiento en los distintos puntos de control de los documentos y personas.)
La estructura de datos debe admitir:
• un conjunto limitado o amplio de elementos de datos;
• ocurrencias múltiples de elementos de datos específicos;
• la evolución continua de las implementaciones específicas.
Figura 3. Resumen de la estructura de fichero de la LDS1 del eMRTD
• el apoyo como mínimo a un conjunto de datos de aplicación;
(la compatibilidad como mínimo a un conjunto de datos de aplicación;)
• la posibilidad de otras aplicaciones específicas nacionales;
(la posibilidad de otras aplicaciones concretas nacionales;)
• el apoyo a la autenticación activa opcional del documento por medio de un par de claves asimétricas almacenadas;
(la compatibilidad con la autenticación activa opcional del documento por medio de un par de claves asimétricas almacenadas;)
• el apoyo al acceso rápido a elementos de datos seleccionados para facilitar el rápido procesamiento del documento;
(la compatibilidad con el acceso rápido a elementos de datos seleccionados para facilitar el rápido procesamiento del documento;)
• el acceso inmediato a los elementos de datos necesarios; y
• el acceso directo a las plantillas de datos y a los datos biométricos.
4.4 Agrupamiento de los elementos de datos
En una LDS pueden estar presentes o no agrupamientos de elementos de datos añadidos por los Estados expedidores u organizaciones receptoras aprobadas. En la LDS puede estar presente más de un registro de elementos de datos agrupados añadidos por los Estados receptores u organizaciones receptoras aprobadas.
(En una LDS pueden estar presentes o no agrupamientos de elementos de datos añadidos por los Estados emisores u organizaciones receptoras aprobadas. En la LDS puede estar presente más de un registro de elementos de datos agrupados añadidos por los Estados receptores u organizaciones receptoras aprobadas.)
La capacidad de un Estado receptor u organización receptora aprobada para añadir datos a la LDS no se considera en esta edición del Doc 9303.
(La capacidad de un Estado receptor u organización receptora aprobada para añadir datos a la LDS no se analiza en esta edición del Doc 9303.)
La LDS se considera una entidad cohesiva única que contiene el número de agrupamientos de elementos de datos registrados en la tecnología de ampliación de capacidad opcional en el momento de efectuarse la lectura mecánica.
(La LDS se considera una entidad aglutinante única que incluye el número de agrupamientos de elementos de datos registrados en la tecnología de ampliación de capacidad opcional en el momento de efectuarse la lectura mecánica.)
La LDS se ha diseñado con la flexibilidad suficiente para que pueda aplicarse a todos los tipos de eMRTD. En las figuras y tablas que siguen, algunos elementos de datos solo se aplican a los visados de lectura mecánica y a los pasaportes de lectura mecánica, o exigen una presentación diferente para dichos documentos.
Dentro de la LDS se han establecido agrupamientos lógicos de elementos de datos conexos. Estos agrupamientos lógicos se conocen como grupos de datos.
4.5 Requisitos de la estructura lógica de datos
La tecnología de ampliación de capacidad del CI sin contacto contenida en la LDS1 de un eMRTD seleccionada por un Estado expedidor u organización expedidora debe permitir que los Estados receptores tengan acceso a los datos correspondientes.
(La tecnología de ampliación de capacidad del CI sin contacto incluida en la LDS1 de un eMRTD seleccionada por un Estado emisor u organización emisora debe posibilitar que los Estados receptores tengan acceso a los datos correspondientes.)
La OACI ha determinado que la estructura lógica de datos (LDS) predefinida y normalizada DEBE satisfacer varios requisitos obligatorios:
(La OACI ha determinado que la estructura lógica de datos (LDS) predefinida y normalizada DEBE cumplir varios requisitos obligatorios:)
• asegurar la facilitación eficiente y óptima de la persona titular legítima;
• asegurar la protección de los detalles registrados en la tecnología de ampliación de la capacidad opcional;
• permitir la interoperabilidad mundial de los datos de capacidad ampliada basándose en el uso de una LDS única común a todos los eMRTDs;
(permitir el interfuncionamiento mundial de los datos de capacidad ampliada basándose en el uso de una LDS única común a todos los eMRTDs;)
• responder a las diversas necesidades de ampliación de capacidad opcional de los Estados expedidores y las organizaciones expedidoras;
(responder a las diversas necesidades de ampliación de capacidad opcional de los Estados emisores y las organizaciones emisoras;)
• proporcionar ampliación de capacidad a medida que evolucionan las necesidades de las personas usuarias y la tecnología disponible
(suministrar ampliación de capacidad a medida que evolucionan las necesidades de las personas usuarias y la tecnología disponible)
• permitir una variedad de opciones de protección de datos;
(posibilitar una variedad de opciones de protección de datos;)
• utilizar las especificaciones internacionales existentes en la mayor medida posible, en particular las especificaciones internacionales emergentes para una biometría interoperable a escala mundial.
(utilizar las determinaciones internacionales existentes en la mayor medida posible, en especial las determinaciones internacionales que aparezcan para una biometría interfuncionable a escala mundial.)
4.5.1 Seguridad
Solo el Estado expedidor u organización expedidora TENDRÁ acceso de escritura a estos grupos de datos. Por consiguiente, no hay requisitos de intercambio y los métodos para lograr la protección contra la escritura no forman parte de esta especificación. Una vez bloqueada la microplaqueta (después de la personalización y antes de la expedición) no pueden escribirse, modificarse ni suprimirse datos de la aplicación de la LDS1 en/de la microplaqueta. Después de la expedición, las microplaquetas bloqueadas no pueden desbloquearse.
(Solo el Estado emisor u organización emisora TENDRÁ acceso de escritura a grupos de datos. Por consiguiente, no hay requisitos de intercambio y los métodos para lograr la protección contra la escritura no forman parte de esta determinación. Una vez bloqueada la microplaqueta (después de la personalización y antes de la puesta en circulación) no pueden escribirse, modificarse ni eliminarse datos de la aplicación de la LDS1 en/de la microplaqueta. Después de la puesta en circulación, las microplaquetas bloqueadas no pueden desbloquearse.)
4.5.2 Autenticidad e integridad de los datos
Para permitir la confirmación de la autenticidad e integridad de los detalles registrados, se incluye un objeto de autenticidad/integridad. Cada grupo de datos DEBE estar representado en este objeto de autenticidad/integridad, que se registra en un fichero elemental EF separado (EF.SOD). Empleando la estructura de marco común de formatos de intercambio biométrico (CBEFF) utilizada para los grupos de datos 2-4 de las características de identificación codificadas y las características opcionales de “seguridad biométrica adicional” definidas en el Doc 9303-12, también PUEDEN protegerse individualmente los elementos de confirmación de la identidad (p. ej., las plantillas biométricas) a discreción del Estado expedidor o de la organización expedidora.
(Para admitir la confirmación de la autenticidad e invariabilidad de los detalles registrados, se incluye un objeto de autenticidad/invariabilidad. Cada grupo de datos DEBE estar representado en este objeto de autenticidad/invariabilidad, que se registra en un fichero elemental EF separado (EF.SOD) (Elementary File. Security Object Document = Archivo elemental. Documento objeto de seguridad). Utilizando la estructura de marco común de modelos de intercambio biométrico (CBEFF = Common Biometric Exchange Formats Framework) utilizada para los grupos de datos 2-4 de las características de identificación codificadas y las características opcionales de “seguridad biométrica adicional” definidas en el Doc 9303-12, también PUEDEN protegerse individualmente los elementos de confirmación de la identidad (p. ej., las plantillas biométricas) a elección del Estado emisor o de la organización emisora.)
La Parte 12 del Documento 9303 de la OACI se refiere a la reseña de la infraestructura de clave pública:
2. RESEÑA DE LA INFRAESTRUCTURA DE CLAVE PÚBLICA
La infraestructura de clave pública (PKI) del eMRTD permite la creación y subsiguiente verificación de firmas digitales en objetos eMRTD, incluyendo el objeto de seguridad de documento (SOD) para asegurar que los datos firmados son auténticos y no han sido modificados. La revocación de un certificado, la falla del procedimiento de validación de la ruta de certificación o la falla de la verificación de la firma digital, por sí solos, no hacen que el eMRTD se considere inválido. Dicha falla significa que la verificación electrónica de la integridad y autenticidad de los datos LDS ha fallado y que entonces podrían utilizarse otros mecanismos no electrónicos para efectuar esa determinación como parte de la inspección general del eMRTD.
(La infraestructura de clave pública (PKI = Public Key Infrastructure) del eMRTD posibilita la creación y subsiguiente comprobación de firmas digitales en objetos eMRTD, incluyendo el objeto de seguridad de documento (SOD = Document Security Object) para asegurar que los datos firmados son auténticos y no han sido modificados. La revocación de un certificado, el fallo del procedimiento de comprobación de la ruta de certificación o el fallo en la comprobación de la firma digital, por sí solos, no hacen que el eMRTD se considere inválido. Dicho fallo significa que la comprobación electrónica de la invariabilidad y autenticidad de los datos LDS ha fallado y que entonces podrían utilizarse otros mecanismos no electrónicos para efectuar esa determinación como parte de la inspección general del eMRTD.)
La PKI del eMRTD es mucho más sencilla que las PKI más genéricas con muchas aplicaciones como la PKI de Internet definida en [RFC 5280]. En la PKI del eMRTD cada Estado expedidor o autoridad expedidora establece una única autoridad de certificación (CA) que expide todos los certificados directamente a entidades finales, incluyendo firmantes del documento. Estas CA se conocen como autoridades de certificación de firma de país (CSCA). No hay otras CA en la infraestructura. Los Estados receptores establecen la confianza directamente en las claves o certificados CSCA de cada Estado expedidor u organización expedidora.
(La PKI del eMRTD es mucho más sencilla que las PKI más genéricas con muchas aplicaciones como la PKI de Internet definida en [RFC 5280]. En la PKI del eMRTD cada Estado emisor o autoridad emisora establece una única autoridad de certificación (CA = Certification Authority) que emite todos los certificados directamente a entidades finales, incluyendo firmantes del documento. Estas CA se conocen como autoridades de certificación de firma de país (CSCA = Country Signing Certification Authority). No hay otras CA en la infraestructura. Los Estados receptores establecen la confianza directamente en las claves o certificados CSCA de cada Estado emisor u organización emisora.)
La PKI del eMRTD se basa en normas PKI genéricas, incluyendo las [X.509] y [RFC 5280]. Estas normas básicas de PKI definen un gran conjunto de características opcionales y complejas relaciones de confianza entre las CA que no son pertinentes a la aplicación del eMRTD. En esta parte del Doc 9303 se especifica un perfil de dichas normas, adaptadas a la aplicación del eMRTD. Algunos de los aspectos singulares de la aplicación del eMRTD son los siguientes:
(La PKI del eMRTD se basa en normas PKI generales, incluyendo las [X.509] y [RFC 5280]. Estas normas básicas de PKI definen un gran conjunto de características opcionales y complejas relaciones de confianza entre las CA que no son adecuadas para la aplicación del eMRTD. En esta parte del Doc 9303 se describe un perfil de dichas normas, adecuadas a la aplicación del eMRTD. Algunos de los aspectos singulares de la aplicación del eMRTD son los siguientes:)
• hay exactamente una CSCA por Estado expedidor;
(hay exactamente una CSCA por Estado emisor;)
• las rutas de certificación comprenden exactamente un certificado (p. ej., firmante del documento);
(las rutas de certificación incluyen únicamente un certificado (p. ej., firmante del documento);
• la verificación de la firma debe ser posible de 5 a 10 años después de la creación;
(la comprobación de la firma debe ser posible de 5 a 10 años después de la creación;)
• se admite el cambio de nombre de la CSCA; y
• los certificados de enlace CSCA no se procesan como certificados intermedios en una ruta de certificación.
En su mayor parte, la infraestructura PKI del eMRTD cumple con [RFC 5280]. No obstante, el hecho de que las CSCA puedan experimentar un cambio de nombre impone requisitos singulares sobre la PKI del eMRTD que son incompatibles con algunos de los procedimientos de validación CRL definidos en [RFC 5280]. Estas diferencias se han mantenido en un mínimo y se identifican claramente.
(En su mayor parte, la infraestructura PKI del eMRTD cumple con [RFC 5280]. Pese a ello, el hecho de que las CSCA puedan efectuar un cambio de nombre establece requisitos singulares sobre la PKI del eMRTD que son incompatibles con algunos de los procedimientos de comprobación CRL (Certificate Revocation List = Lista de Revocación de Certificados) definidos en [RFC 5280]. Estas diferencias se han mantenido en un mínimo y se identifican claramente.)
En el caso del VDS y la LDS2, la PKI de la firma digital, que proporciona la autenticidad e integridad de los objetos de datos, es una extensión de la PKI de la LDS1. Los firmantes del VDS y la LDS2 son expedidos por la misma CSCA que expide los firmantes de la LDS1. Los cambios en los perfiles de certificado de estas nuevas aplicaciones se especifican en el presente documento. Esta infraestructura se conoce, en su conjunto, como la PKI del eMRTD.
(En el caso del VDS (Visible Digital Seal = Sello digital visible) y la LDS2 (LDS = Logical Data Structure = Estructura lógica de datos), la PKI de la firma digital, que suministra la autenticidad e invariabilidad de los objetos de datos, es una extensión de la PKI de la LDS1. Los firmantes del VDS y la LDS2 son emitidos por la misma CSCA que emite los firmantes de la LDS1. Los cambios en los perfiles de certificado de estas nuevas aplicaciones se concreta en este documento. Esta infraestructura se conoce, en su conjunto, como la PKI del eMRTD.)
La PKI de la firma digital comprende las entidades siguientes:
• CA de firma de país (CSCA);
• certificados de firmante del documento (CDS) que se utilizan para validar los objetos de seguridad de documento (SOD);
(certificados de firmante del documento (DSC = Document Signer Certificate) que se utilizan para aprobar los objetos de seguridad de documento (SOD);
• certificados de firmante LDS2, que abarca los elementos siguientes:
– firmante LDS2-TS – firma los sellos de viaje LDS2;
– firmante LDS2-V – firma los visados electrónicos LDS2; y
– firmante LDS2-B – firma los datos biométricos adicionales LDS2;
• certificados de firmante del código de barras (BSC), para los que, en el presente documento, se definen los dos tipos específicos siguientes:
(certificados de firmante del código de barras (BSC = Bar Code Signer Certificate), para los que, en este documento, se definen los dos tipos concretos siguientes:)
– certificados de firmante del visado (VSC); y
(certificados de firmante del visado (VSC = Visa Signer Certificates); y)
– certificados de firmante del documento de viaje de emergencia (ESC);
(certificados de firmante del documento de viaje de emergencia (ESC = Emergency Travel Document Signer Certificates);)
• certificados de firmante de la lista maestra (MSC) utilizados para firmar listas maestras;
(certificados de firmante de la lista maestra (MSC = Master List Signer Certificates) utilizados para firmar listas maestras;)
• certificados de firmante de la lista de desviaciones (DLSC) utilizados para firmar listas de desviaciones;
(certificados de firmante de la lista de desviaciones (DLSC = Deviation List Signer Certificates) utilizados para firmar listas de desviaciones;)
• lista de revocación de certificados (CRL).
Los distintos tipos de certificados están firmados por la misma CSCA. La CSCA también firma la CRL, que contiene cualquier certificado revocado, independientemente del tipo de certificado. Todos los certificados expedidos por la CSCA se conocen en su conjunto como certificados de firmante.
(Los distintos tipos de certificados están firmados por la misma CSCA. La CSCA también firma la CRL (Certificate Revocation List), que incluye cualquier certificado revocado, independientemente del tipo de certificado. Todos los certificados emitidos por la CSCA se conocen en su conjunto como certificados de firmante.)
En el caso de las aplicaciones LDS2, se define una PKI de autorización separada. La PKI de autorización permite que el Estado expedidor o la organización expedidora del eMRTD controle y gestione los Estados extranjeros a los que se concede autorización para escribir objetos de datos LDS2 en sus eMRTD y leer dichos objetos de datos. Un Estado extranjero que prevea leer o escribir datos LDS2 debe obtener un certificado de autorización directamente del Estado expedidor u organización expedidora del eMRTD.
(En el caso de las aplicaciones LDS2, se define una PKI de autorización separada. La PKI de autorización admite que el Estado emisor o la organización emisora del eMRTD controle y gestione los Estados extranjeros a los que se atribuye autorización para escribir objetos de datos LDS2 en sus eMRTD y leer dichos objetos de datos. Un Estado extranjero que prevea leer o escribir datos LDS2 debe obtener un certificado de autorización directamente del Estado emisor u organización emisora del eMRTD.)
La PKI de autorización utiliza una estructura de certificado diferente (certificado verificable mediante tarjeta ISO 7816) y, por lo tanto, requiere componentes de infraestructura adicionales.
(La PKI de autorización utiliza una estructura de certificado diferente (certificado comprobable mediante tarjeta ISO 7816) y, por lo tanto, necesita componentes de infraestructura adicionales.)
La LDS2 requiere que el terminal demuestre al CI sin contacto del eMRTD que tiene derecho a escribir objetos de datos LDS2 en el CI sin contacto o que tiene derecho a leer objetos de datos LDS2. Dicho terminal está equipado con al menos una clave privada y el correspondiente certificado de terminal, que codifica la clave pública del terminal y los derechos de acceso. Después de que el terminal haya demostrado conocer esta clave privada, el chip del MRTD concede al terminal el acceso para leer/escribir datos LDS2, según lo indicado en el certificado del terminal.
(La LDS2 necesita que el terminal demuestre al CI sin contacto del eMRTD que tiene derecho a escribir objetos de datos LDS2 en el CI sin contacto o que tiene derecho a leer objetos de datos LDS2. Dicho terminal está equipado con al menos una clave privada y el correspondiente certificado de terminal, que codifica la clave pública del terminal y los derechos de acceso. Después de que el terminal haya demostrado conocer esta clave privada, el chip del MRTD admite al terminal el acceso para leer/escribir datos LDS2, según lo indicado en el certificado del terminal.)
La PKI de autorización LDS2 comprende las entidades siguientes:
(La PKI de autorización LDS2 incluye las entidades siguientes:)
• autoridades de certificación de verificación de país (CVCA);
(autoridades de certificación de verificación de país (CVCA = Country Verifying Certification Authority);)
• verificadores del documento (DV);
(•verificadores del documento (DV = Document Verifier);)
• terminales; y
• punto de contacto único (SPOC).
(punto de contacto único (SPOC = Single Point Of Contact).
La distribución y gestión de los certificados de autorización entre las CVCA de un Estado y las DV de otros Estados se realiza a través de un punto de contacto único (SPOC) en cada Estado.
En esta Parte 12 del Doc 9303 se especifica el perfil de la PKI del eMRTD, el perfil de la PKI de autorización y los objetos correspondientes, entre los cuales:
(En esta Parte 12 del Doc 9303 se detalla el perfil de la PKI del eMRTD, el perfil de la PKI de autorización y los objetos correspondientes, entre los cuales:)
• funciones y responsabilidades de las entidades en la infraestructura;
• algoritmos criptográficos y gestión de claves;
• contenido de certificados y CRL;
• mecanismos de distribución de certificados y CRL; y
• validación de la ruta de certificación.
(aprobación de la ruta de certificación.)
3. FUNCIONES Y RESPONSABILIDADES
En esta sección se describen las entidades, las funciones y las responsabilidades relativas a la PKI del eMRTD y la PKI de autorización.
3.1 La PKI del eMRTD
La autenticidad e integridad de los datos almacenados en los eMRTD está protegida por autenticación pasiva. Este mecanismo de seguridad se basa en firmas digitales y consiste en las siguientes entidades PKI para las PKI de eMRTD:
• CA de firma de país (CSCA): Cada Estado expedidor o autoridad expedidora establece una única CSCA con su punto de confianza nacional en el contexto de los eMRTD. La CSCA expide certificados de clave pública para uno o más firmantes del documento (nacionales) y, con carácter opcional, para otras entidades finales como los firmantes de la lista maestra y firmantes de la lista de desviaciones. La CSCA también expide listas de revocación de certificado (CRL) periódicas indicando si alguno de los certificados expedidos ha sido revocado.
(CA de firma de país (CSCA): Cada Estado emisor o autoridad emisora establece una única CSCA (Autoridad de Certificación de Firma de País) con su punto de confianza nacional en el contexto de los eMRTD. La CSCA emite certificados de clave pública para uno o más firmantes del documento (nacionales) y, con carácter opcional, para otras entidades finales como los firmantes de la lista maestra y firmantes de la lista de desviaciones. La CSCA también emite listas de revocación de certificado (CRL) periódicas indicando si alguno de los certificados emitidos ha sido revocado.)
• Firmante del documento (DS): El firmante del documento firma digitalmente los datos que han de almacenarse en el eMRTD; esta firma se almacena en el eMRTD, en un objeto de seguridad de documento.
(Firmante del documento (DS = Document Signer): El firmante del documento firma digitalmente los datos que han de almacenarse en el eMRTD; esta firma se almacena en el eMRTD, en un objeto de seguridad de documento.)
• Firmantes LDS2: Un firmante LDS2 firma digitalmente objetos de datos LDS2 de uno o más tipos.
• Firmante del código de barras (BCS): Un firmante del código de barras firma digitalmente los datos (encabezado y mensaje) codificados en el código de barras. La firma también se almacena en el código de barras. En este documento se detallan dos ejemplos para el uso del firmante del código de barras: visados y documentos de viaje de emergencia.
• Sistema de inspección (IS): El sistema de inspección verifica la firma digital, incluyendo la validación de la ruta de certificación para verificar la autenticidad e integridad de los datos electrónicos almacenados en el eMRTD como parte de la autenticación pasiva.
(Sistema de inspección (IS): El sistema de inspección comprueba la firma digital, incluyendo la aprobación de la ruta de certificación para comprobar la autenticidad e invariabilidad de los datos electrónicos almacenados en el eMRTD como parte de la autenticación pasiva.)
• Firmante de la lista maestra: El firmante de la lista maestra es una entidad opcional que firma digitalmente una lista de certificados CSCA (nacionales y extranjeros) en apoyo del mecanismo bilateral de distribución para certificados CSCA.
• Firmantes de la lista de desviaciones: Los firmantes de la lista de desviaciones se utilizan para firmar las listas de desviaciones. Las listas de desviaciones se definen en el Doc 9303-3.
La Parte 3 del Documento 9303 de la OACI dispone en su apartado 7 lo siguiente:
7. DESVIACIONES
A medida que los Estados en todo el mundo continúan adoptando MRTD, la creciente complejidad y el aumento del número de desviaciones han conducido a la necesidad de notificar las desviaciones con respecto a las normas o a la práctica normal del Estado mediante un mecanismo normalizado. Se definen como desviaciones los MRTD que contienen elementos que no se ajustan precisamente a las especificaciones de la OACI o a las normas rectoras de la ISO y la RFC. Las desviaciones se observan normalmente dentro de las autoridades de certificación de firma de país (CSCA) o certificado de firmante de documentos (DSC). No obstante, los Estados también han indicado problemas con respecto a la LDS y a las casillas de la ZLM en sus MRTD. La finalidad de esta sección es presentar en detalle el mecanismo por el cual los Estados expedidores pueden publicar sus desviaciones.
(A medida que los Estados en todo el mundo continúan incorporando MRTD, la creciente complejidad y el aumento del número de desviaciones han llevado a la necesidad de notificar las desviaciones con respecto a las normas o a la práctica normal del Estado mediante un mecanismo normalizado. Se definen como desviaciones los MRTD que incluyen elementos que no se ajustan precisamente a las determinaciones de la OACI o a las normas rectoras de la ISO y la RFC. Las desviaciones se observan normalmente dentro de las autoridades de certificación de firma de país (CSCA) o certificado de firmante de documentos (DSC). Aun así, los Estados también han indicado problemas con respecto a la LDS y a las casillas de la ZLM en sus MRTD. La finalidad de esta sección es presentar en detalle el mecanismo por el cual los Estados emisores pueden publicar sus desviaciones.)
Si bien los documentos de viaje pueden contener desviaciones, todavía pueden utilizarse en los sistemas de gestión de fronteras. Los documentos que son válidos en los demás aspectos pueden continuar utilizándose por varios años. En consecuencia, las partes interesadas deberían identificar sus propios procesos para el tratamiento de cualesquiera desviaciones publicadas.
(Si bien los documentos de viaje pueden incluir desviaciones, todavía pueden utilizarse en los sistemas de gestión de fronteras. Los documentos que son válidos en los demás aspectos pueden continuar utilizándose durante varios años. En consecuencia, las partes interesadas deberían identificar sus propios procesos para el tratamiento de cualesquiera desviaciones publicadas.)
7.1 Experiencias operacionales
Durante un largo tiempo el único método para gestionar las desviaciones se basaba en la comunicación general de los Estados expedidores por medios diplomáticos. La presente sección comprende desviaciones que afectan grandes cantidades de MRTD y que podían notificarse de modo de ayudar a los controles fronterizos en determinar si los documentos de viaje son válidos, están alterados o sustituidos. Algunos ejemplos de errores operacionales comprenden desviaciones en la ZLM, LDS e PKI.
(Durante un largo tiempo el único método para gestionar las desviaciones se basaba en la comunicación general de los Estados emisores por medios diplomáticos. Esta sección incluye desviaciones que afectan a grandes cantidades de MRTD y que podían notificarse para ayudar a los controles fronterizos a determinar si los documentos de viaje son válidos, están alterados o han sido sustituidos. Algunos ejemplos de errores operacionales incluyen desviaciones en la ZLM, LDS y PKI.)
Cuando la ZLM se ha estado utilizando durante muchos años algunos ejemplos recientes de errores conocidos en dicha zona son:
• la fecha de nacimiento en la ZLM no corresponde a la fecha de nacimiento en la página de la ZIV.
• la nacionalidad en la ZLM se indica incorrectamente como país de nacimiento en vez de país de nacionalidad.
En la mayoría de los casos los documentos de viaje con una ZLM que no es conforme a las normas serán retirados por el Estado expedidor, pero como transcurre un cierto tiempo entre la expedición y la nueva expedición subsiguiente, los viajeros pueden verse obligados a utilizar sus MRTD con desviaciones. Durante este tiempo, la publicación de la desviación puede mitigar posibles problemas para los viajeros.4
(En la mayoría de los casos los documentos de viaje con una ZLM que no es adecuada a las normas serán retirados por el Estado emisor, pero como transcurre un cierto tiempo entre la emisión y la nueva emisión posterior, los viajeros pueden verse obligados a utilizar sus MRTD con desviaciones. Durante este tiempo, la publicación de la desviación puede reducir posibles problemas para los viajeros4.)
*La nota 4 a pie de página dice:
«Los casos de no conformidad que afectan documentos únicos o pequeñas cantidades de eMRTD no se tratarán en esta sección, correspondiendo al Estado expedidor la retirada y nueva expedición de cada documento.»
(Los casos de no adecuación que afectan a documentos individuales o pequeñas cantidades de eMRTD no se tratarán en esta sección, correspondiendo al Estado emisor la retirada y nueva emisión de cada documento.)
Algunas desviaciones de LDS e PKI pueden pasar desapercibidas durante extensos períodos de tiempo, dado que muchos Estados todavía no ejecutan la autenticación pasiva y según se especifica en el Doc 9303. No obstante, se exhorta firmemente a los Estados expedidores a que publiquen las desviaciones para asistir a la comunidad mundial en la adopción técnica de los MRTD5.
(Algunas desviaciones de LDS y PKI pueden pasar desapercibidas durante extensos períodos de tiempo, dado que muchos Estados todavía no ejecutan la autenticación pasiva y según se concreta en el Doc 9303. Pese a ello, se pide firmemente a los Estados emisores que publiquen las desviaciones para ayudar a la comunidad mundial en la incorporación técnica de los MRTD5.)
*La nota 5 a pie de página dice:
«Por cada caso en que haya habido un problema de seguridad relativo a un certificado PKI, la respuesta adecuada es la revocación según se describe en el Doc 9303-12. Una mayor orientación no corresponde al alcance de esta sección.»
7.2 Enfoque de lista de desviaciones
El enfoque se describe en esta sección tiene por objeto proporcionar un medio normalizado para que los Estados expedidores publiquen y distribuyan una lista de desviaciones de documentos de viaje. Dicha lista se basa en principios establecidos durante la elaboración de la lista maestra CSCA (véase el Doc 9303-12), en el sentido de que una lista de desviaciones firmada para los casos de no conformidad de cada Estado se proporcionará a través del PKD de la OACI o de la autoridad expedidora por un sitio web o un servidor LDAP. El PKD se utiliza para apoyar la difusión de la información pertinente a la gestión de desviaciones.
(El enfoque que se describe en esta sección tiene por objeto facilitar un medio normalizado para que los Estados emisores publiquen y distribuyan una lista de desviaciones de documentos de viaje. Dicha lista se basa en principios establecidos durante la elaboración de la lista maestra CSCA (véase el Doc 9303-12), en el sentido de que una lista de desviaciones firmada para los casos de no adecuación de cada Estado se facilitará a través del PKD (Directorio de claves públicas) de la OACI o de la autoridad emisora por un sitio web o un servidor LDAP. El PKD se utiliza para ayudar a la difusión de la información correspondiente para la gestión de las desviaciones.)
(sigue la Parte 3 del Documento 9303 de la OACI)
Las desviaciones se dividen en cuatro áreas específicas:
(Las desviaciones se dividen en cuatro áreas concretas:)
• claves y certificados;
• estructura lógica de datos (LDS);
• zona de lectura mecánica (ZLM);
• microplaqueta.
Para cada una de estas categorías se describirán las desviaciones en un nivel solamente, por ejemplo:
Categoría: LDS
Error DG2
Se brindará mayor información a través de un parámetro operacional proporcionado por cada Estado o una casilla de texto libre en el marco de notificación que permita al Estado informante añadir cualquier texto descriptivo que se requiera. El Estado informante puede incluir en la casilla de texto libre enlaces hacia lugares de información adicional. Para los errores de certificación, el expedidor tendrá la opción de expedir un nuevo certificado, pero esto no será obligatorio.
(Se ofrecerá mayor información a través de un parámetro operacional facilitado por cada Estado o una casilla de texto libre dentro de la notificación que posibilite al Estado informante añadir cualquier texto descriptivo que se necesite. El Estado informante puede incluir en la casilla de texto libre enlaces hacia lugares de información adicional. Para los errores de certificación, el emisor tendrá la opción de emitir un nuevo certificado, pero esto no será obligatorio.)
La decisión de comunicar un caso de no conformidad a las partes interesadas corresponde únicamente al Estado expedidor. Al decidir si conviene crear una lista de desviación, los Estados deberían tener en cuenta que a medidas que el autoprocesamiento de los viajeros en las fronteras se hace más común, el no comunicar la información pertinente a los documentos de viaje no conformes puede provocar demoras e inconvenientes para los viajeros, lo que dará una mala impresión tanto del Estado expedidor como del proceso de control fronterizo en su totalidad.
(La decisión de comunicar un caso de no adecuación a las partes interesadas corresponde únicamente al Estado emisor. Al decidir si conviene crear una lista de desviación, los Estados deberían tener en cuenta que a medida que el autoprocesamiento de los viajeros en las fronteras se hace más común, el no comunicar la información correspondiente a los documentos de viaje no adecuados puede provocar esperas e inconvenientes para los viajeros, lo que dará una mala impresión tanto del Estado emisor como del proceso de control fronterizo en su totalidad.)
Las listas de desviación brindan un medio de notificar desviaciones que afectan a miles de documentos de viaje, más que a unos pocos o a unos cientos. Es conveniente que los Estados gestionen directamente pequeños números de documentos de viaje no conformes.
(Las listas de desviación ofrecen un medio de notificar desviaciones que perjudican a miles de documentos de viaje, más que a unos pocos o a unos cientos. Es conveniente que los Estados gestionen directamente pequeños números de documentos de viaje no adecuados.)
7.3 Método
7.3.1 Elementos de la desviación
Los elementos que constituyen un MRTD abarcan desde el papel a las microplaquetas RFID, estando cada elemento protegido de algún modo por elementos de seguridad que puedan definirse y ensayarse por sistemas de inspección durante la vida del documento de viaje. Los elementos de seguridad empleados en el documento de viaje físico son o bien manifiestos o bien ocultos. En esta sección se consideran solamente los elementos de desviación dentro de la ZLM, la LDS y la PKI.
(Los elementos que forman un MRTD abarcan desde el papel a las microplaquetas RFID (Radio Frequency Identification = Identificación por radiofrecuencia), estando cada elemento protegido de algún modo por elementos de seguridad que puedan definirse y ensayarse por sistemas de inspección durante la vida del documento de viaje. Los elementos de seguridad utilizados en el documento de viaje físico son o bien manifiestos o bien ocultos. En esta sección se examinan solamente los elementos de desviación dentro de la ZLM (Zona de Lectura Mecánica), la LDS (Estructura lógica de datos) y la PKI (Infraestructura de clave pública).)
La ZLM es un área de dimensiones fijas emplazada en la página de datos del MRTD, que contiene datos obligatorios y opcionales formateados para lectura mecánica empleando métodos OCR. En el Doc 9303 se proporcionan las especificaciones para la ZLM, incluyendo:
(La ZLM es un área de dimensiones fijas situada en la página de datos del MRTD, que incluye datos obligatorios y opcionales formateados para lectura mecánica utilizando métodos OCR. En el Doc 9303 se suministran las determinaciones para la ZLM, incluyendo:)
• finalidad;
• limitaciones;
• transliteración; y
• estructura de datos en las líneas de la ZLM.
La conformidad de la ZLM se comprueba normalmente mediante sistemas de inspección por comparación de datos con la página de datos correspondiente en la ZIV y el nuevo cálculo de los dígitos de verificación de la ZLM.
(La adecuación de la ZLM se comprueba normalmente mediante sistemas de inspección por comparación de datos con la página de datos correspondiente en la ZIV (Zona de Inspección Visual) y el nuevo cálculo de los dígitos de comprobación de la ZLM.)
La autenticidad y la integridad de los datos almacenados en la microplaqueta RFID del MRTD están protegidas por la autenticación pasiva. Este es un mecanismo de seguridad basado en las firmas digitales y en la infraestructura de clave pública (PKI).
(La autenticidad y la invariabilidad de los datos almacenados en la microplaqueta RFID del MRTD están protegidas por la autenticación pasiva. Este es un mecanismo de seguridad basado en las firmas digitales y en la infraestructura de clave pública (PKI).)
La estructura de la LDS del MRTD se define en el Doc 9303-10. Si bien no existen ensayos específicos para establecer la conformidad, los datos almacenados en la LDS son parcialmente un subconjunto de datos disponibles de la ZLM o de la página ZIV del MRTD. En consecuencia, los mismos ensayos aplicados a los datos digitales de la ZLM y la ZIV se aplicarían a la ZLM y a la página ZIV. La autenticidad de la LDS se proporciona mediante la correcta aplicación de la autenticación pasiva por los sistemas de inspección, mientras que la autenticación activa es ejecutada por la microplaqueta. A continuación se presenta una breve descripción al respecto:
(La estructura de la LDS (Estructura lógica de datos) del MRTD (Documento de viaje de lectura mecánica) se define en el Doc 9303-10. Si bien no existen ensayos concretos para establecer la adecuación, los datos almacenados en la LDS son parcialmente un subconjunto de datos disponibles de la ZLM o de la página ZIV (Zona de Inspección Visual) del MRTD. En consecuencia, los mismos ensayos aplicados a los datos digitales de la ZLM y la ZIV se aplicarían a la ZLM y a la página ZIV. La autenticidad de la LDS se suministra mediante la correcta aplicación de la autenticación pasiva por los sistemas de inspección, mientras que la autenticación activa es ejecutada por la microplaqueta. A continuación se presenta una breve descripción al respecto:)
La autenticación pasiva (PA) se basa en firmas digitales y contiene los componentes de PKI siguientes:
(La autenticación pasiva (PA) se basa en firmas digitales e incluye los componentes de PKI siguientes:)
1. CA de firma de país (CSCA): cada Estado establece una CSCA como su punto de confianza nacional en el contexto de los eMRTD. La CSCA expide certificados de clave pública para uno o más firmantes de documento (nacionales). Además, cada CSCA expide listas de revocación de certificados (CRL) de todos los certificados revocados6.
(CA de firma de país (CSCA): cada Estado establece una CSCA como su punto de confianza nacional en el contexto de los eMRTD. La CSCA emite certificados de clave pública para uno o más firmantes de documento (nacionales). Además, cada CSCA emite listas de revocación de certificados (CRL = Certificate Revocation List) de todos los certificados revocados6.)
*La nota 6 a pie de página dice:
«Dado que las CRL constituyen un mecanismo de notificación de seguridad y se vuelven a expedir constantemente, no es necesario notificar defectos en ellas y, por consiguiente, quedan fuera del alcance de esta Parte.»
(Dado que las CRL son un mecanismo de notificación de seguridad y se vuelven a emitir constantemente, no es necesario notificar defectos en ellas y, por consiguiente, quedan fuera del alcance de esta Parte.)
2. Firmante del documento (DS): un firmante de documento firma en forma digital los datos que han de almacenarse en los MRTD; esta firma se almacena en el objeto de seguridad de documento para cada documento.
(Firmante del documento (DS = Document Signer): un firmante de documento firma en forma digital los datos que han de almacenarse en los MRTD; esta firma se almacena en el objeto de seguridad de documento para cada documento.)
Autenticación activa (AA): cuando se implanta la AA, cada microplaqueta contiene su propio par de claves AA. La clave privada se almacena en la memoria protegida de la microplaqueta y la clave pública se almacena en el grupo de datos 15 de la LDS.
(Autenticación activa (AA = Active Authentication): cuando se instala la AA, cada microplaqueta incluye su propio par de claves AA. La clave privada se almacena en la memoria protegida de la microplaqueta y la clave pública se almacena en el grupo de datos 15 de la LDS.)
7.3.2 Publicación de listas de desviación
Las listas de desviación NO DEBEN ser publicadas directamente por una CSCA; en vez de ello, la CSCA AUTORIZARÁ a un firmante de lista de desviación (véase el Doc 9303-12) a que recopile, firme y publique listas de desviación. Las especificaciones para la lista de desviaciones figuran en el Doc 9303-12.
El apartado 10 de la Parte 12 del documento 9303 de la OACI recoge:
10. ESTRUCTURA DE LA LISTA DE DESVIACIONES
La lista de desviaciones se implementa como un tipo SignedData, según se especifica en [RFC 3852]. Todas las listas de desviaciones DEBEN producirse en formato DER para conservar en ellas la integridad de las firmas.
(La lista de desviaciones se instala como un tipo SignedData (Datos Firmados), según se detalla en [RFC 3852]. Todas las listas de desviaciones DEBEN producirse en formato DER (Regla de codificación distinguida) para conservar en ellas la invariabilidad de las firmas.)
El intervalo de desviaciones estará delimitado por:
• intervalo de fechas (incluyendo la fecha de expedición y la de caducidad);
(intervalo de fechas (incluyendo la fecha de emisión y la de caducidad);)
• nombre del expedidor y número de serie;
(nombre del emisor y número de serie;)
• el identificador subjectKeyIdentifier del DSC;
(el identificador subjectKeyIdentifier del DSC (Document Signer Certificate = Certificado de Firmante de Documento);
• lista de números de eMRTD.
Se utilizarán combinaciones apropiadas de estos valores para vincular con precisión el intervalo de MRTD afectados.
(Se utilizarán combinaciones adecuadas de estos valores para coordinar con precisión el intervalo de MRTD perjudicados.)
Cuando se combinen los valores, estos deben procesarse unidos por “AND” (Y). No puede optarse por procesar valores unidos utilizando “OR” (O).
10.1 Tipo SignedData (datos firmados)
Se aplican las reglas de procesamiento de [RFC 3852].
m obligatorio — el campo DEBE estar presente;
r recomendado — el campo DEBERÍA estar presente;
x no utilizar — el campo NO DEBE estar presente;
o opcional — el campo PUEDE estar presente.
Tabla 19. Lista de desviaciones
| Valor | Comentarios | |
| SignedData | ||
| version | m | Valor = v3 |
| digestAlgorithms | m | |
| encapContentInfo | m | |
| eContentType | m | id-icao-DeviationList |
| eContent | m | La DeviationList del contenido codificado. |
| certificates | m | Los estados DEBEN incluir el certificado de firmante de la lista de desviaciones y DEBERÍAN incluir el certificado CSCA, que puede utilizarse para verificar la firma en el campo signerInfos. |
| crls | x | |
| signerInfos | m | SE RECOMIENDA que los Estados solo proporcionen 1 signerinfo dentro de este campo. |
| SignerInfo | m | |
| version | m | El valor de este campo está dictado por el campo sid. Véanse las reglas relativas a este campo en [RFC 3852] sección 5.3. |
| sid | m | |
| subjectKeyIdentifier | r | SE RECOMIENDA que los Estados admitan este campo más que issuerandSerialNumber. |
| digestAlgorithm | m | Identificador de algoritmo del algoritmo utilizado para producir el valor condensado sobre encapsulatedContent y SignedAttrs. |
| signedAttrs | m | Es posible que los Estados productores deseen disponer de atributos adicionales para su inclusión en la firma, pero estos no tienen que ser procesados por los Estados receptores, salvo para verificar el valor de la firma. signedAttrs DEBE incluir la hora de la firma (véase [PKCS #9]). |
| signatureAlgorithm | m | Identificador de algoritmo del algoritmo utilizado para producir el valor de firma y cualquier parámetro conexo. |
| signature | m | El resultado del proceso de generación de firma. |
| unsignedAttrs | x |
10.2 Especificación ASN.1
DeviationList
{ joint-iso-itu-t (2) international-organization(23) icao(136) mrtd(1) security(1)
deviationlist(7)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
— Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
— Imports from RFC 3852
SubjectKeyIdentifier, Digest, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
cms-2004(24) };
DeviationListVersion ::= INTEGER {v0(0)}
DeviationList ::= SEQUENCE {
version DeviationListVersion,
digestAlgorithm AlgorithmIdentifier OPTIONAL,
deviations SET OF Deviation
}
Deviation ::= SEQUENCE{
documents DeviationDocuments,
descriptions SET OF DeviationDescription
}
DeviationDescription ::= SEQUENCE{
description PrintableString OPTIONAL,
deviationType OBJECT IDENTIFIER,
parameters [0] ANY DEFINED BY deviationType OPTIONAL,
nationalUse [1] ANY OPTIONAL
— The nationalUse field is for internal State use, and is not governed
— by an ICAO specification.
}
DeviationDocuments ::= SEQUENCE {
documentType [0] PrintableString (SIZE(2)) OPTIONAL,
— per MRZ, e.g. ‘P’
dscIdentifier DocumentSignerIdentifier OPTIONAL,
issuingDate [4] IssuancePeriod OPTIONAL,
documentNumbers [5] SET OF PrintableString OPTIONAL
}
DocumentSignerIdentifier ::= CHOICE{
issuerAndSerialNumber [1] IssuerAndSerialNumber,
subjectKeyIdentifier [2] SubjectKeyIdentifier,
certificateDigest [3] Digest — if used, digestAlgorithm must be present in
DeviationList
}
IssuancePeriod ::= SEQUENCE {
firstIssued GeneralizedTime,
lastIssued GeneralizedTime
}
— CertField is used to define which part of a certificate is
affected by a coding error. Parts of the Body are identified by
the corresponding value of CertificateBodyField, extensions
by the corresponding OID identifying the extension.
CertField ::= CHOICE {
body CertificateBodyField,
extension OBJECT IDENTIFIER
}
CertificateBodyField ::= INTEGER {
generic(0), version(1), serialNumber(2), signature(3), issuer(4),
validity(5), subject(6), subjectPublicKeyInfo(7),
issuerUniqueID(8), subjectUniqueID(9)
}
Datagroup ::= INTEGER
{dg1(1), dg2(2), dg3(3), dg4(4), dg5(5), dg6(6),
dg7(7), dg8(8), dg9(9), dg10(10), dg11(11),
dg12(12), dg13(13), dg14(14), dg15(15), dg16(16),
sod(20), com(21)}
MRZField ::= INTEGER
{generic(0), documentCode(1), issuingState(2), personName(3),
documentNumber(4), nationality(5), dateOfBirth(6),
sex(7), dateOfExpiry(8), optionalData(9)}
— Base Object Identifiers
id-icao OBJECT IDENTIFIER ::= {2 23 136 }
id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}
id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}
id-icao-DeviationList OBJECT IDENTIFIER ::= {id-icao-mrtd-security 7}
id-icao-DeviationListSigningKey OBJECT IDENTIFIER ::= {id-icao-mrtd-security 8}
— Deviation Object Identifiers and Parameter Definitions
id-Deviation-CertOrKey OBJECT IDENTIFIER ::= {id-icao-DeviationList 1}
id-Deviation-CertOrKey-DSSignature OBJECT IDENTIFIER ::= {id-Deviation-CertOrKey 1}
id-Deviation-CertOrKey-DSEncoding OBJECT IDENTIFIER ::= {id-Deviation-CertOrKey 2}
id-Deviation-CertOrKey-CSCAEncoding OBJECT IDENTIFIER ::= {id-Deviation-CertOrKey 3}
id-Deviation-CertOrKey-AAKeyCompromised OBJECT IDENTIFIER ::= {id-Deviation-CertOrKey 4}
id-Deviation-LDS OBJECT IDENTIFIER ::= {id-icao-DeviationList 2}
id-Deviation-LDS-DGMalformed OBJECT IDENTIFIER ::= {id-Deviation-LDS 1}
id-Deviation-LDS-DGHashWrong OBJECT IDENTIFIER ::= {id-Deviation-LDS 2}
id-Deviation-LDS-SODSignatureWrong OBJECT IDENTIFIER ::= {id-Deviation-LDS 3}
id-Deviation-LDS-COMInconsistent OBJECT IDENTIFIER ::= {id-Deviation-LDS 4}
id-Deviation-MRZ OBJECT IDENTIFIER ::= {id-icao-DeviationList 3}
id-Deviation-MRZ-WrongData OBJECT IDENTIFIER ::= {id-Deviation-MRZ 1}
id-Deviation-MRZ-WrongCheckDigit OBJECT IDENTIFIER ::= {id-Deviation-MRZ 2}
id-Deviation-Chip OBJECT IDENTIFIER ::= {id-icao-DeviationList 4}
id-Deviation-NationalUse OBJECT IDENTIFIER ::= {id-icao-DeviationList 5}
END
(sigue la Parte 3 del Documento 9303 de la OACI)
Los procedimientos que han de ejecutarse para expedir una lista de desviación DEBERÍAN reflejarse en las políticas de certificación publicadas de la CSCA expedidora.
(Los procedimientos que han de ejecutarse para emitir una lista de desviación DEBERÍAN reflejarse en las políticas de certificación publicadas por la CSCA emisora.)
7.3.3 Recepción de listas de desviaciones
Cada Estado receptor define sus propias políticas en el marco de las cuales acepta una lista de desviación, así como la forma en que se tramitan dichas desviaciones durante la inspección de documentos. En general, estas políticas constituyen información privada.
(Cada Estado receptor establece sus propias políticas dentro de las cuales acepta una lista de desviación, así como la forma en que se tramitan dichas desviaciones durante la inspección de documentos. En general, estas políticas constituyen información privada.)
El Estado receptor, a su sola discreción, optará por permitir el uso de MRTD con una desviación.
(El Estado receptor, a su sola elección, optará por admitir el uso de MRTD con una desviación.)
7.3.4 Categorías de desviaciones
7.3.4.1 Claves y certificados
Las desviaciones de certificados y claves se limitan a las siguientes:
| Asunto | Observación |
| Certificado | Descrita para la casilla o extensión |
| Claves | Descrita para la casilla o extensión |
| AA | Descrita para el error o problema solamente |
Nota.— Cuando un Estado notificador decide expedir un nuevo certificado, dicho certificado NO DEBE incluirse en la lista de desviaciones, pero podría hacerse referencia al mismo en la casilla de texto libre.
(Nota.— Cuando un Estado notificador decide emitir un nuevo certificado, dicho certificado NO DEBE incluirse en la lista de desviaciones, pero podría hacerse referencia al mismo en la casilla de texto libre.)
7.3.4.2 Estructura lógica de datos (LDS)
Las desviaciones de LDS se limitan a las siguientes:
| Asunto | Observación |
| EF. Com | Descrita para el error de codificación |
| DG | Descrita para el grupo de datos |
| EF.sod | Descrita para el asunto (p. ej., DSC) |
7.3.4.3 Zona de lectura mecánica (ZLM)
Las desviaciones de ZLM se limitan a las siguientes:
| Asunto | Observación |
| Correspondencia con ZIV | Descrita para la casilla |
| Dígitos de verificación | Descrita para el dígito de verificación responsable |
| Información errónea codificada | Descrita para la casilla ZLM |
| (Asunto | Observación |
| Correspondencia con ZIV | Descrita para la casilla |
| Dígitos de comprobación | Descrita para el dígito de comprobación responsable |
| Información errónea codificada | Descrita para la casilla ZLM) |
7.3.5 Definiciones de tipo de desviación
Las categorías de desviaciones y parámetros correspondientes pueden ampliarse con el tiempo y se actualizarán en el Doc 9303.
Cada desviación se describe mediante un elemento de descripción de desviación (deviationDescription). La desviación se identifica mediante un tipo de desviación de identificador de objeto y puede detallarse más mediante parámetros. La descripción de la casilla PUEDE contener más información, acerca de cómo el carácter de la desviación no puede describirse adecuadamente mediante el tipo de desviación aplicable.
(Cada desviación se describe mediante un elemento de descripción de desviación (deviationDescription). La desviación se identifica mediante un tipo de desviación de identificador de objeto y puede detallarse más mediante criterios. La descripción de la casilla PUEDE incluir más información, acerca de cómo el tipo de la desviación no puede describirse adecuadamente mediante el tipo de desviación aplicable.)
| Tipo de desviación | Parámetro | Descripción |
| Desviación de certificado/clave | ||
| id-Deviation-CertOrKey | Ninguno | Desviación relacionada con certificado o clave genéricos no abarcada por las desviaciones más detalladas que siguen. |
| id-Deviation-CertOrKey- DSSignature | Ninguno | La firma del certificado de firmante del documento está equivocada. |
| id-Deviation-CertOrKey- DSEncoding CertField | CertField | El certificado de firmante del documento contiene un error de codificación. |
| id-Deviation-CertOrKey- CSCAEncoding | CertField | El certificado de CA de firma de país contiene un error de codificación. |
| id-Deviation-CertOrKey- AAKeyCompromised | Ninguno | La clave para autenticación activa puede ser vulnerable y no se debería confiar en la misma. |
| Desviación de LDS | ||
| id-Deviation-LDS | Ninguno | Desviación relacionada con LDS genérica no abarcada por las desviaciones más detalladas que siguen. |
| id-Deviation-LDS- DGMalformed | Datagroup | La codificación TLV del grupo de datos determinado está alterada. |
| id-Deviation-LDS- DGHashWrong | Datagroup | El valor de condensación del grupo de datos determinado en la EF.SOD está equivocado. |
| id-Deviation-LDS- SODSignatureWrong | Ninguno | La firma que figura en EF.SOD está equivocada. |
| id-Deviation-LDS- COMinconsistent | Ninguno | EF.COM y EF.SOD son contradictorias. |
(Desviación de LSD = Desviación de la Estructura lógica de datos)
(TLV = Tag Length Value = Valor de longitud de rótulo)
| Tipo de desviación | Parámetro | Descripción |
| Desviación de ZLM | ||
| id-Deviation-MRZ | Ninguno | Desviación relacionada con ZLM genérica no abarcada por la desviación más detallada que sigue. |
| id-Deviation-MRZ- WrongData | MRZField | La casilla de la ZLM dada contiene datos equivocados (p. ej., contradicción con la ZIV), pero la clave BAC obtenida puede usarse para abrir la microplaqueta. Si la clave BAC obtenida no puede usarse, SE INCLUIRÁ el añadido de id-Deviation-Chip en la lista de desviación |
| id-Deviation-MRZ- WrongCheckDigit | MRZField | El dígito de verificación de la casilla dada de la ZLM está mal calculado. |
| Desviación de la microplaqueta | ||
| id-Deviation-Chip | Ninguno | La microplaqueta no es utilizable, p. ej., clave BAC equivocada, antena dañada u otro defecto físico. |
(BAC = Basic Access Control = Control de acceso básico)
Los identificadores de objetos de la OACI se especifican en 9303-10, 9303-11 y 9303-12. A continuación figura una lista de los identificadores de objetos de desviación:
— Deviation List Base Object identifiers
id-icao-mrtd-security-DeviationList OBJECT IDENTIFIER ::= {id-icao-mrtd-security 7}
id-icao-mrtd-security-DeviationListSigningKey OBJECT IDENTIFIER ::= {id-icao-mrtd-security 8}
— Deviation Object Identifiers and Parameter Definitions
id-Deviation-CertOrKey OBJECT IDENTIFIER ::= {id-icao-DeviationList 1}
id-Deviation-CertOrKey-DSSignature OBJECT IDENTIFIER ::= {id-Deviation-
CertOrKey 1}
id-Deviation-CertOrKey-DSEncoding OBJECT IDENTIFIER ::= {id-Deviation-
CertOrKey 2}
id-Deviation-CertOrKey-CSCAEncoding OBJECT IDENTIFIER ::= {id-Deviation-
CertOrKey 3}
id-Deviation-CertOrKey-AAKeyCompromised OBJECT IDENTIFIER ::= {id-
Deviation-CertOrKey 4}
id-Deviation-LDS OBJECT IDENTIFIER ::= {id-icao-DeviationList 2}
id-Deviation-LDS-DGMalformed OBJECT IDENTIFIER ::= {id-Deviation-LDS 1}
id-Deviation-LDS-SODSignatureWrong OBJECT IDENTIFIER ::= {id-Deviation-LDS
3}
id-Deviation-LDS-COMInconsistent OBJECT IDENTIFIER ::= {id-Deviation-LDS 4}
id-Deviation-MRZ OBJECT IDENTIFIER ::= {id-icao-DeviationList 3}
id-Deviation-MRZ-WrongData OBJECT IDENTIFIER ::= {id-Deviation-MRZ 1}
id-Deviation-MRZ-WrongCheckDigit OBJECT IDENTIFIER ::= {id-Deviation-MRZ 2}
id-Deviation-Chip OBJECT IDENTIFIER ::= {id-icao-DeviationList 4}
id-Deviation-NationalUse OBJECT IDENTIFIER ::= {id-icao-DeviationList 5}.
En la parte 10 del documento 9303 de la OACI encontramos los siguientes identificadores de objetos:
– En el apartado 3.11.4 se recoge lo siguiente:
El archivo CardSecurity SE IMPLEMENTARÁ como SignedData con arreglo al [RFC 3369] con el tipo de contenido id-SecurityObject dentro del campo encapContentInfo. El firmante de documentos FIRMARÁ los objetos de seguridad. El certificado de firmante del documento DEBE incluirse en SignedData. El siguiente identificador de objetos SE UTILIZARÁ para identificar el tipo de contenido:
(El archivo CardSecurity (seguridad de la tarjeta) SE INSTALARÁ como SignedData (datos firmados) de acuerdo con el [RFC 3369] con el tipo de contenido id-SecurityObject (identificador del objeto de seguridad) dentro del campo encapContentInfo. El firmante de documentos FIRMARÁ los objetos de seguridad. El certificado de firmante del documento DEBE incluirse en SignedData. El siguiente identificador de objetos SE UTILIZARÁ para identificar el tipo de contenido:)
bsi-de OBJECT IDENTIFIER ::= {
itu-t(0) identified-organization(4) etsi(0)
reserved(127) etsi-identified-organization(0) 7
}
id-SecurityObject OBJECT IDENTIFIER ::= {
bsi-de applications(3) eID(2) 1
}
– En el apartado 4.6.2.3, titulado «ASN.1 Profile LDS Document Security Object for SOD V1″ (Perfil ASN.1 del Objeto de Seguridad del Documento LDS para SOD (objeto de seguridad de documento) V1)aparecen los siguientes identificadores de objeto:
id-icao OBJECT IDENTIFIER::={joint-iso-itu-t(2) international(23) icao(136) }
id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}
id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}
id-icao-mrtd-security-ldsSecurityObject OBJECT IDENTIFIER ::= {id-icao- mrtd-security 1}
– En el apartado 5.4.1, titulado «Funciones y niveles de autorización por defecto (OBLIGATORIO)» se recoge:
Cada certificado CV contiene una plantilla de autorización de la persona titular del certificado (CHAT) que identifica la función del titular del certificado (IS, DV, CVCA) y contiene derechos de acceso a DG3/DG4 de la aplicación de la LDS2 del eMRTD EXIGIDA (debido a usos heredados u otros usos nacionales).
(Cada certificado CV incluye una plantilla de autorización de la persona titular del certificado (CHAT = Certificate Holder Authorization Template) que identifica la función del titular del certificado (IS = Inspección Systema (Sistema de Inspección), DV = Document Verifier (Verificador del Documento), CVCA = Country Verifying Certification Authority (Autoridad de certificación de verificación de país) e incluye derechos de acceso a DG3/DG4 de la aplicación de la LDS2 del eMRTD EXIGIDA (debido a usos heredados u otros usos nacionales).)
CHAT comprende una secuencia de dos objetos
(CHAT incluye una secuencia de dos objetos)
a) Un identificador de objetos que especifique el tipo de terminal y el formato de la plantilla [TR- 03110]:
(Un identificador de objetos que concrete el tipo de terminal y el tipo de la plantilla [TR- 03110]:)
id-roles OBJECT IDENTIFIER ::= {bsi-de applications(3) mrtd(1) 2}
id-IS OBJECT IDENTIFIER ::= {id-roles 1}
b) Un objeto de datos discrecional (rótulo ‘53’) que contenga la función codificada en bits y derechos de acceso de solo lectura de la persona titular del certificado con arreglo a la siguiente tabla:
(Un objeto de datos opcional (rótulo ‘53’) que incluya la función codificada en bits y derechos de acceso de solo lectura de la persona titular del certificado de acuerdo con la siguiente tabla:)
Tabla 95. Autorización CHAT por defecto
Descripción | Byte 1 | ||||||||
| b8 b7 b6 b5 b4 b3 b2 b1 | |||||||||
| Función | CVCA | 1 | 1 | ||||||
| DV (nacional) | 1 | 0 | |||||||
| DV (extranjero) | 0 | 1 | |||||||
| IS | 0 | 0 | |||||||
| Acceso de lectura | RFU | ||||||||
| RFU | |||||||||
| RFU | |||||||||
| RFU | |||||||||
| DG4 (iris) | 1 | ||||||||
| DG3 (dedo) | 1 | ||||||||
Nota.— La LDS2 para el eMRTD NO DEBE tener en cuenta el valor de los bits RFU de la autorización de la persona titular del certificado.
– En el apartado 5.4.2, titulado «Niveles de autorización de la aplicación (OBLIGATORIO)» se recoge:
Las autorizaciones de personas titulares de certificados para cada aplicación de la LDS2 se codifican con extensiones de certificado CV (una extensión por aplicación). La extensión de certificado es una plantilla discrecional (rótulo ‘73’) que comprende dos objetos de datos: un identificador de objeto de autorización (rótulo ‘06’) para una aplicación específica y un objeto de datos discrecional (rótulo ‘53’) que contenga derechos de acceso codificados en bits de la persona titular del certificado a una aplicación especificada.
(Las autorizaciones de personas titulares de certificados para cada aplicación de la LDS2 se codifican con extensiones de certificado CV (una extensión por aplicación). La extensión de certificado es una plantilla opcional (rótulo ‘73’) que incluye dos objetos de datos: un identificador de objeto de autorización (rótulo ‘06’) para una aplicación concreta y un objeto de datos opcional (rótulo ‘53’) que tenga derechos de acceso codificados en bits de la persona titular del certificado a una aplicación especificada.)
Para determinar la autorización efectiva de una persona titular de un certificado, la LDS2 para la microplaqueta del eMRTD calcula un operador booleano “Y” a nivel de bit de los derechos de acceso contenidos en las extensiones del certificado IS y los certificados DV y CVCA de referencia.
(Para determinar la autorización efectiva de una persona titular de un certificado, la LDS2 para la microplaqueta del eMRTD calcula un operador booleano “Y” a nivel de bit de los derechos de acceso incluidos en las extensiones del certificado IS y los certificados DV y CVCA de referencia.)
Para la aplicación de los registros de viaje, los identificadores de objeto de autorización y las codificaciones de derechos de acceso son las siguientes:
id-icao-lds2-travelRecords OBJECT IDENTIFIER ::= {id-icao-lds2 1}
id-icao-lds2-travelRecords-access OBJECT IDENTIFIER ::= {id-icao-lds2-
travelRecords 3}
Tabla 96. Autorizaciones para la aplicación de los registros de viaje
Descripción | Byte 1 | ||||||||
| b8 b7 b6 b5 b4 b3 b2 b1 | |||||||||
| Derechos de acceso | RFU | ||||||||
| RFU | |||||||||
| RFU | |||||||||
| RFU | |||||||||
| Añadir EF. Certificates | 1 | ||||||||
| Leer/Buscar/Seleccionar/EF. Certificates FMM | 1 | ||||||||
| Añadir EF. EntryRecords/ExistRecords | 1 | ||||||||
| Leer/Buscar/Seleccionar/EF.EntryRecords/ExitRecords FMM | 1 | ||||||||
Para la aplicación de los registros de visado, los identificadores de objeto de autorización y las codificaciones de derechos de acceso son los siguientes:
id-icao-lds2-visaRecords OBJECT IDENTIFIER ::= {id-icao-lds2 2}
id-icao-lds2-visaRecords-access OBJECT IDENTIFIER ::= {id-icao-lds2-visaRecords 3}
Tabla 97. Autorizaciones para la aplicación de los registros de visado
Descripción | Byte 1 | ||||||||
| b8 b7 b6 b5 b4 b3 b2 b1 | |||||||||
| Derechos de acceso | RFU | ||||||||
| RFU | |||||||||
| RFU | |||||||||
| RFU | |||||||||
| Añadir EF. Certificates | 1 | ||||||||
| Leer/Buscar/Seleccionar/EF. Certificates FMM | 1 | ||||||||
| Añadir EF. EntryRecords/ExistRecords | 1 | ||||||||
| Leer/Buscar/Seleccionar/EF.EntryRecords/ExitRecords FMM | 1 | ||||||||
Para la aplicación de datos biométricos adicionales, los identificadores de objeto de autorización y las codificaciones de derechos de acceso son las siguientes:
id-icao-lds2-additionalBiometrics OBJECT IDENTIFIER ::= {id-icao-lds2 3}
id-icao-lds2-additionalBiometrics-access OBJECT IDENTIFIER::= {id-icao-lds2-additionalBiometrics 3}
Tabla 98. Autorizaciones para la aplicación de datos biométricos adicionales
Descripción | Iden-tificador EF | Autorizaciones | ||||||||
| b8 b7 b6 b5 b4 b3 b2 b1 | ||||||||||
| Byte 1 | RFU | |||||||||
| RFU | ||||||||||
| RFU | ||||||||||
| RFU | ||||||||||
| RFU | ||||||||||
| RFU | ||||||||||
| Añadir EF. Certificates | ‘011A’ | 1 | ||||||||
| Seleccionar/FMM/Leer/Buscar EF.Certificates | ‘011A’ | 1 | ||||||||
| Byte 2 | Seleccionar/FMM/Escribir/Activar/Leer EF.Biometrics1 en estado desactivado | ‘0201’ | 1 | |||||||
| Seleccionar/FMM/Leer EF.Biometrics1 en estado activado | ‘0201’ | 1 | ||||||||
| Seleccionar/FMM/Escribir/Activate/Read EF.Biometrics2 en estado desactivado | ‘0202’ | 1 | ||||||||
| Seleccionar/FMM/Read EF.Biometrics2 en estado activado | ‘0202’ | 1 | ||||||||
| Seleccionar/FMM/ Escribir/Activate/Read EF.Biometrics3 en estado desactivado | ‘0203’ | 1 | ||||||||
| Seleccionar/FMM/Read EF.Biometrics3 en estado activado | ‘0203’ | 1 | ||||||||
| Seleccionar/FMM/ Escribir/Activate/Read EF.Biometrics4 en estado desactivado | ‘0204’ | 1 | ||||||||
| Seleccionar/FMM/Read EF.Biometrics4 en estado activado | ‘0204’ | 1 | ||||||||
…
| Byte 17 | Seleccionar/FMM/Escribir/Activate/Leer EF.Biometrics61 en estado desactivado | ‘023D’ | 1 | |||||||
| Seleccionar/FMM/Leer EF.Biometrics61 en estado activado | ‘023D’ | 1 | ||||||||
| Seleccionar/FMM/Write/Activate/Leer EF.Biometrics62 en estado desactivado | ‘023E’ | 1 | ||||||||
| Seleccionar/FMM/Leer EF.Biometrics62 en estado activado | ‘023E’ | 1 | ||||||||
| Seleccionar/FMM/Escribir/Activate/Read EF.Biometrics63 en estado desactivado | ‘023F’ | 1 | ||||||||
| Seleccionar/FMM/Leer EF.Biometrics63 en estado activado | ‘023F’ | 1 | ||||||||
| Seleccionar/FMM/Escribir/Activate/Leer EF.Biometrics64 en estado desactivado | ‘0240’ | 1 | ||||||||
| Seleccionar/FMM/Leer EF.Biometrics64 en estado activado | ‘0240’ | 1 |
Nota 1.— La LDS2 para el eMRTD NO DEBE tener en cuenta el valor de los bits RFU en la autorización de la persona titular del certificado.
Nota 2.— Los Estados expedidores u organizaciones expedidoras NO DEBEN expedir certificados de terminal con autorizaciones para escribir/activar el IS si solo tienen autorizaciones de lectura para las datos biométricos adicionales.
(Los Estados emisores u organizaciones emisoras NO DEBEN emitir certificados de terminal con autorizaciones para escribir/activar el IS si solo tienen autorizaciones de lectura para las datos biométricos adicionales.)
El apartado 6 de la Parte 10 del documento 9303 de la OACI recoge:
6. IDENTIFICADORES DE OBJETO
6.1 Resumen de los identificadores de objeto de las aplicaciones de la LDS1 y LDS2
Tabla 99. OID de LDS1.7, LDS1.8 y LDS2
| Identificador de objeto | Valor | Comentario |
| id-icao | joint-iso-itu-t(2) international- organizations(23) icao(136) | OID de la OACI |
| id-icao-mrtd | id-icao 1 | OID del eMRTD |
| id-icao-mrtd-security | id-icao-mrtd 1 | |
| id-icao-ldsSecurityObject | id-icao-mrtd-security 1 | Objeto de seguridad de LDS |
| id-icao-mrtd-security-cscaMasterList | id-icao-mrtd-security 2 | Lista maestra de CSCA |
| id-icao-mrtd-security-cscaMasterListSigningKey i | id-icao-mrtd-security 3 | |
| id-icao-mrtd-security-documentTypeList | id-icao-mrtd-security 4 | Lista de tipos de documento |
| id-icao-mrtd-security-aaProtocolObject | id-icao-mrtd-security 5 | Protocolo de autenticación activa |
| id-icao-mrtd-security-extensions | id-icao-mrtd-security 6 | Cambio de nombre de la CSCA |
| id-icao-mrtd-security-extensions-nameChange | id-icao-mrtd-security-extensions 1 | |
| id-icao-mrtd-security-extensions- documentTypeList | id-icao-mrtd-security-extensions 2 | Tipo de documento DS |
| id-icao-mrtd-security-DeviationList | id-icao-mrtd-security 7 | OID de base de la lista de defectos |
| id-icao-mrtd-security-DeviationListSigningKey | id-icao-mrtd-security 8 | |
| id-icao-lds2 | id-icao-mrtd-security 9 | Identificadores de objetos LDS2 |
| id-icao-lds2-travelRecords | id-icao-lds2 1 | OID de la base de aplicación de los registros de viaje |
| id-icao-lds2-travelRecords-application | id-icao-lds2-travelRecords 1 | AID de la aplicación de los registros de viaje |
| id-icao-lds2-travelRecords-access | id-icao-lds2-travelRecords 3 | Extensión de certificado de autorización |
| id-icao-lds2-visaRecords | id-icao-lds2 2 | OID de la base de aplicación de los registros de visado |
| id-icao-lds2-visaRecords-application | id-icao-lds2-visaRecords 1 | AID de los registros de visado |
| id-icao-lds2-visaRecords-access | id-icao-lds2-visaRecords 3 | Extensión del certificado de autorización |
| id-icao-lds2-additionalBiometrics | id-icao-lds2 3 | OID de la base de los datos biométricos adicionales |
| id-icao-lds2-additionalBiometrics-application | id-icao-lds2-additionalBiometrics 1 | AID de los datos biométricos adicionales |
| Identificador de objeto | Valor | Comentario |
| id-icao-lds2-additionalBiometrics-access | id-icao-lds2-additionalBiometrics 3 | Extensión del certificado de autorización |
| id-icao-lds2Signer | id-icao-lds2 8 | Identificadores de objetos de firmante LDS2 |
| id-icao-tsSigner | id-icao-lds2Signer 1 | Certificado de firmante del sello de viaje LDS2 |
| id-icao-vSigner | id-icao-lds2Signer 2 | Certificado de firmante del visado LDS2 |
| id-icao-bSigner | id-icao-lds2Signer 3 | Certificado de firmante de los datos biométricos adicionales LDS2 |
| id-icao-spoc | id-icao-mrtd-security 10 | Identificadores de objeto de SPOC |
| id-icao-spocClient | id-icao-spoc 1 | Cliente |
| id-icao-spocServer | id-icao-spoc 2 | Servidor |
Asimismo, en el apartado 7 de la Parte 10 del documento 9303 encontramos:
7. ESPECIFICACIONES ASN.1
id-icao OBJECT IDENTIFIER ::= {joint-iso-itu-t(2) international-organizations(23)
icao(136) }
id-icao-mrtd OBJECT IDENTIFIER ::= {id-icao 1}
id-icao-mrtd-security OBJECT IDENTIFIER ::= {id-icao-mrtd 1}
id-icao-ldsSecurityObject OBJECT IDENTIFIER ::= {id-icao-mrtd-security 1}
id-icao-mrtd-security-cscaMasterList OBJECT IDENTIFIER ::= {id-icao-mrtd-security 2}
id-icao-mrtd-security-cscaMasterListSigningKey OBJECT IDENTIFIER ::= {id-icao-mrtd-security 3}
id-icao-mrtd-security-documentTypeList OBJECT IDENTIFIER ::= {id-icao-mrtd-security 4}
id-icao-mrtd-security-aaProtocolObject OBJECT IDENTIFIER ::= {id-icao-mrtd-security 5}
id-icao-mrtd-security-extensions OBJECT IDENTIFIER ::= {id-icao-mrtd-security 6}
id-icao-mrtd-security-extensions-nameChange OBJECT IDENTIFIER ::= {id-icao-mrtd-security-extensions 1}
id-icao-mrtd-security-extensions-documentTypeList OBJECT IDENTIFIER ::= {id-icao-mrtd-security-extensions 2}
id-icao-mrtd-security-DeviationList OBJECT IDENTIFIER ::= {id-icao-mrtd-security 7}
id-icao-mrtd-security-DeviationListSigningKey OBJECT IDENTIFIER ::= {id-icao-mrtd-security 8}
id-icao-lds2 OBJECT IDENTIFIER ::= {id-icao-mrtd-security 9}
Identificadores de objeto de las aplicaciones de los registros de viaje LDS2
id-icao-lds2-travelRecords OBJECT IDENTIFIER ::= {id-icao-lds2 1}
id-icao-lds2-travelRecords-application OBJECT IDENTIFIER ::= {id-icao-lds2-travelRecords 1}
id-icao-lds2-travelRecords-access OBJECT IDENTIFIER ::= {id-icao-lds2-travelRecords 3}
Identificadores de objeto de las aplicaciones de los registros de visado LDS2
id-icao-lds2-visaRecords OBJECT IDENTIFIER ::= {id-icao-lds2 2}
id-icao-lds2-visaRecords-application OBJECT IDENTIFIER ::= {id-icao-lds2-visaRecords 1}
id-icao-lds2-visaRecords-access OBJECT IDENTIFIER ::= {id-icao-lds2-visaRecords 3}
Identificadores de objeto de las aplicaciones de datos biométricos adicionales LDS2
id-icao-lds2-additionalBiometrics OBJECT IDENTIFIER ::= {id-icao-lds2 3}
id-icao-lds2-additionalBiometrics-application OBJECT IDENTIFIER ::= {id-icao-lds2-additionalBiometrics 1}
id-icao-lds2-additionalBiometrics-access OBJECT IDENTIFIER ::= {id-icao-lds2-additionalBiometrics 3}
id-icao-lds2Signer OBJECT IDENTIFIER ::= {id-icao-lds2 8}
id-icao-tsSigner OBJECT IDENTIFIER ::= {id-icao-lds2Signer 1}
id-icao-vSigner OBJECT IDENTIFIER ::= {id-icao-lds2Signer 2}
id-icao-bSigner OBJECT IDENTIFIER ::= {id-icao-lds2Signer 3)
id-icao-spoc OBJECT IDENTIFIER ::= {id-icao-mrtd-security 10}
id-icao-spocClient OBJECT IDENTIFIER ::= {id-icao-spoc 1}
id-icao-spocServer OBJECT IDENTIFIER ::= {id-icao-spoc 2}
Por su parte, en la parte 11 del documento 9303 de la OACI se encuentran los siguientes identificadores de objetos no reproducidos anteriormente:
– En el apartado 9.2.3, titulado «Identificador de objeto PACE», que recoge:
Los identificadores de objeto utilizados para PACE figuran en el subárbol de bsi-de:
bsi-de OBJECT IDENTIFIER ::= {
itu-t(0) identified-organization(4) etsi(0)
reserved(127) etsi-identified-organization(0) 7
}
Se UTILIZARÁ el siguiente identificador de objeto:
id-PACE OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 4
}
id-PACE-DH-GM OBJECT IDENTIFIER ::= {id-PACE 1}
id-PACE-DH-GM-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-PACE-DH-GM 1}
id-PACE-DH-GM-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-PACE-DH-GM 2}
id-PACE-DH-GM-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-PACE-DH-GM 3}
id-PACE-DH-GM-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-PACE-DH-GM 4}
id-PACE-ECDH-GM OBJECT IDENTIFIER ::= {id-PACE 2}
id-PACE-ECDH-GM-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-PACE-ECDH-GM 1}
id-PACE-ECDH-GM-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-PACE-ECDH-GM 2}
id-PACE-ECDH-GM-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-PACE-ECDH-GM 3}
id-PACE-ECDH-GM-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-PACE-ECDH-GM 4}
id-PACE-DH-IM OBJECT IDENTIFIER ::= {id-PACE 3}
id-PACE-DH-IM-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-PACE-DH-IM 1}
id-PACE-DH-IM-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-PACE-DH-IM 2}
id-PACE-DH-IM-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-PACE-DH-IM 3}
id-PACE-DH-IM-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-PACE-DH-IM 4}
id-PACE-ECDH-IM OBJECT IDENTIFIER ::= {id-PACE 4}
id-PACE-ECDH-IM-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-PACE-ECDH-IM 1}
id-PACE-ECDH-IM-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-PACE-ECDH-IM 2}
id-PACE-ECDH-IM-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-PACE-ECDH-IM 3}
id-PACE-ECDH-IM-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-PACE-ECDH-IM 4}
id-PACE-ECDH-CAM OBJECT IDENTIFIER ::= {id-PACE 6}
id-PACE-ECDH-CAM-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-PACE-ECDH-CAM 2}
id-PACE-ECDH-CAM-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-PACE-ECDH-CAM 3}
id-PACE-ECDH-CAM-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-PACE-ECDH-CAM 4}
– En el apartado 9.2.7 titulado «Identificador de objeto de autenticación de microplaqueta»:
Se UTIIZARÁ el siguiente identificador de objeto:
id-PK OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 1
}
id-PK-DH OBJECT IDENTIFIER ::= {id-PK 1}
id-PK-ECDH OBJECT IDENTIFIER ::= {id-PK 2}
id-CA OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 3
}
id-CA-DH OBJECT IDENTIFIER ::= {id-CA 1}
id-CA-DH-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-CA-DH 1}
id-CA-DH-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-CA-DH 2}
id-CA-DH-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-CA-DH 3}
id-CA-DH-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-CA-DH 4}
id-CA-ECDH OBJECT IDENTIFIER ::= {id-CA 2}
id-CA-ECDH-3DES-CBC-CBC OBJECT IDENTIFIER ::= {id-CA-ECDH 1}
id-CA-ECDH-AES-CBC-CMAC-128 OBJECT IDENTIFIER ::= {id-CA-ECDH 2}
id-CA-ECDH-AES-CBC-CMAC-192 OBJECT IDENTIFIER ::= {id-CA-ECDH 3}
id-CA-ECDH-AES-CBC-CMAC-256 OBJECT IDENTIFIER ::= {id-CA-ECDH 4}
– En el apartado 9.2.9, denominado «Identificadores de objeto de autenticación del terminal», que recoge:
SE UTILIZARÁ el siguiente identificador de objeto:
id-TA OBJECT IDENTIFIER ::= {
bsi-de protocols(2) smartcard(2) 2
}
id-TA-RSA OBJECT IDENTIFIER ::= {id-TA 1}
id-TA-RSA-PSS-SHA-256 OBJECT IDENTIFIER ::= {id-TA-RSA 4}
id-TA-RSA-PSS-SHA-512 OBJECT IDENTIFIER ::= {id-TA-RSA 6}
id-TA-ECDSA OBJECT IDENTIFIER ::= {id-TA 2}
id-TA-ECDSA-SHA-224 OBJECT IDENTIFIER ::= {id-TA-ECDSA 2}
id-TA-ECDSA-SHA-256 OBJECT IDENTIFIER ::= {id-TA-ECDSA 3}
id-TA-ECDSA-SHA-384 OBJECT IDENTIFIER ::= {id-TA-ECDSA 4}
id-TA-ECDSA-SHA-512 OBJECT IDENTIFIER ::= {id-TA-ECDSA 5}
– En el apartado 9.2.10, denominado «EFDIRInfo», que recoge:
Esta estructura de datos encierra una copia completa del contenido del fichero elemental transparente EF.DIR contenido en el fichero maestro.
EFDIRInfo ::= SEQUENCE {
protocol OBJECT IDENTIFIER(id-EFDIR),
eFDIR OCTET STRING
}
id-EFDIR OBJECT IDENTIFIER ::={
id-icao-mrtd-security 13
}
(sigue la Parte 3 del documento 9303 de la OACI)
7.3.6 Identificación de documentos con desviaciones
Los documentos afectados por una desviación PUEDEN identificarse por varios medios diferentes:
(Los documentos perjudicados por una desviación PUEDEN identificarse por varios medios diferentes:)
• por el certificado de firmante de documentos empleados para firmar dichos documentos; el firmante de documento puede ser identificado por:
(por el certificado de firmante de documentos utilizados para firmar dichos documentos; el firmante de documento puede ser identificado por:)
◦ el nombre distinguido del expedidor combinado con el número de serie del certificado (issuerAndSerialNumber),
(el nombre distinguido del emisor unido al número de serie del certificado (issuerAndSerialNumber = emisorYNúmeroDeSerie ),)
◦ el subjectKeyIdentifier que identifica unívocamente al firmante del documento, o
(◦ el subjectKeyIdentifier (sujetoClaveIdentificador) que identifica inequívocamente al firmante del documento, o)
◦ la condensación (hash) del certificado de firmante del documento (certificateHash); la función de condensación que ha de utilizarse es la misma que la empleada en la firma de la lista de desviación.
(◦ la condensación (hash) del certificado de firmante del documento (certificateHash); la función de condensación que ha de utilizarse es la misma que la utilizada en la firma de la lista de desviación.)
*NOTA: Condensación (Hash): Fórmula matemática que convierte un mensaje de cualquier longitud en una cadena de dígitos única de longitud fija conocida como “compendio de mensajes” que representa el mensaje original. La función hash es unidireccional, es decir, que es imposible invertir el proceso para determinar el mensaje original. Además, esta función no producirá el mismo compendio de mensaje a partir de dos entradas diferentes.
• por una gama de fechas de expedición (startIssuingDate, endIssuingDate)
(por una variedad de fechas de emisión (startIssuingDate, endIssuingDate) (fecha de inicio de emisión, fecha de fin de emisión))
• por una lista de números de documentos (listOfDocNumbers).
Cada método presenta ventajas y desventajas para el expedidor de una lista de desviación así como para receptor de dicha lista, a saber:
(Cada método presenta ventajas y desventajas para el emisor de una lista de desviación así como para el receptor de dicha lista, a saber:)
• La identificación por el firmante del documento permite que los sistemas de inspección reconozcan una desviación solamente después de realizarse la autenticación pasiva. Además, la identificación por el firmante de documentos puede ser demasiado vasta como para identificar con precisión solamente los documentos defectuosos, es decir, la desviación afecta solamente a parte de los documentos firmados por un firmante de documento determinado.
(La identificación por el firmante del documento posibilita que los sistemas de inspección reconozcan una desviación solamente después de realizarse la autenticación pasiva. Además, la identificación por el firmante de documentos puede ser demasiado imprecisa como para identificar con precisión solamente los documentos defectuosos, es decir, la desviación afecta solamente a parte de los documentos firmados por un firmante de documento determinado.)
• La fecha de expedición no es parte de la zona de lectura mecánica, y en general no está disponible en la LDS electrónica. Por consiguiente, no resulta adecuada al tratamiento automático. Además, dependiendo del Estado de expedición, la fecha de expedición puede no ser la fecha real de personalización del pasaporte, sino la fecha de solicitud y, por consiguiente, no es suficientemente precisa para identificar solo los documentos afectados.
(La fecha de emisión no es parte de la zona de lectura mecánica, y en general no está disponible en la LDS electrónica. Por consiguiente, no resulta adecuada al tratamiento mecanizado. Además, dependiendo del Estado de emisión, la fecha de emisión puede no ser la fecha real de personalización del pasaporte, sino la fecha de solicitud y, por consiguiente, no es suficientemente concreta para identificar solo los documentos perjudicados.)
• Una lista de números de documentos es difícil de compilar si los números de documentos no son expedidos en forma secuencial. Una lista de números de documentos crece en forma relativamente rápida hasta un tamaño inmanejable si muchos documentos están afectados por un defecto.
(Una lista de números de documentos es difícil de recopilar si los números de documentos no son emitidos en forma secuencial. Una lista de números de documentos crece en forma relativamente rápida hasta un tamaño inmanejable si muchos documentos están perjudicados por un defecto.)
Se RECOMIENDA brindar tanta información de identificación sobre documentos afectados como sea posible. Si se dan varios métodos para la identificación, las condiciones DEBEN satisfacerse simultáneamente para identificar un documento. Queda a discreción del Estado interesado decidir cuáles eran los medios de identificación indicados en una anotación de lista de desviaciones que se utilizarán para identificar los documentos afectados.
(Se RECOMIENDA ofrecer tanta información de identificación sobre documentos dañados como sea posible. Si se dan varios métodos para la identificación, los requisitos DEBEN satisfacerse simultáneamente para identificar un documento. Queda a elección del Estado interesado decidir cuáles serán los medios de identificación indicados en una anotación de lista de desviaciones que se utilizarán para identificar los documentos dañados.)
7.4 Publicación
Las listas de desviación pueden publicarse a través de la PKD de la OACI o la autoridad expedidora en un sitio web o servidor LDAP. El punto de distribución principal para las listas de desviaciones es el PKD.
(Las listas de desviación pueden publicarse a través de la PKD (Public Key Directory = Directorio de Claves Públicas) de la OACI o la autoridad emisora en un sitio web o servidor LDAP. El punto de distribución principal para las listas de desviaciones es el PKD.)
| Listas de desviación |
| Distribución principal PKD |
| Distribución Sitioweb/LDAP secundaria |
7.4.1 Publicación por el Estado expedidor
Las listas de desviación pueden publicarse en un sitio web o por un servidor LDAP de la autoridad expedidora.
(Las listas de desviación pueden publicarse en un sitio web o por un servidor LDAP de la autoridad emisora.)
7.4.2 Publicación en el PKD
El PKD funciona como depósito central para listas de desviaciones.
El procedimiento para publicar una lista de desviaciones es el siguiente:
1. Las listas de desviaciones se envían a la parte escritura del PKD, como parte del proceso normal de carga de certificados, según se define en la especificación para interfaz PKD y manual de procedimientos PKD.
La carga de los certificados en el Directorio de Clave Pública (PKD) de la OACI se regula en el Reglamento del Directorio de Claves Públicas de la OACI (ICAO PKD Regulations), que está redactado en inglés y con relación a la carga de certificados recoge:
SECTION 10 – PKD UPLOAD PROCEDURES
10.1 The Service Operator provides Participants with a secure privileged access for PKD upload on request. Participants shall neither share their access credentials with non-Participants nor with any other Participants.
10.2 New Document Signer Certificates (DSC), Master Lists, Deviation Lists and Certificate Revocation Lists (CRL) issued by an authorized EMA of the Participant will be forwarded by the CIL electronically to the ICAO PKD in a manner specified in the ICAO PKD Interface Specification.
a. Each DSC should be forwarded preferably 30 days in advance of actual use by the Participant (i.e. signing eMRTD data), except in the case of unusual or urgent situations.
b. Each Master List should be forwarded to the ICAO PKD whenever the Participant deems necessary.
c. Each Deviation List should be forwarded to the ICAO PKD whenever the Participant deems necessary.
d. Ordinary CRLs should be forwarded to the ICAO PKD at least every 90 days. Exceptional CRLs representing real and serious key compromises and consequential revocation of that key by the Participant should be forwarded to the ICAO PKD on an urgent basis whenever such compromises occur. The ICAO PKD is the primary CRL distribution point for Participants.
10.3 New CSCA certificates and CSCA Link Certificates issued by an authorized EMA of the Participant will be provided electronically to the ICAO PKD Office along with its electronic fingerprint for registration and conformance check. The import to the ICAO PKD system is done in a manner specified in the PKD Key Ceremony Procedures.
10.4 Each new CSCA certificate should be announced 90 days in advance but forwarded not less than 30 days in advance of actual use by the Participant (i.e. signing eMRTD data), except in the case of unusual or urgent situations.
10.5 Prior to uploading newly issued Master Lists, Deviation Lists, DSC and CRL or importing new CSCA certificates, participants may check the conformity to ICAO Doc 9303 and related international standards by uploading to the ICAO PKD Conformance Website. This website performs automated checks and provides the results through the website. Such uploads and conformance check requests are protected by secure communications.
10.6 Upon receipt of the uploaded DSCs, Master Lists, Deviation Lists and CRLs in the PKD Upload Directory, a system-level acknowledgement will be automatically sent to the Participant’s CIL e-mail address.
10.7 An automated engine will carry out appropriate DSC, Master List, Deviation List and CRL verification and will upon successful verification transfer it to the PKD Download Directory. The transfer will be postponed by a configurable wait period (cool-down period) that gives the Participant the possibility to terminate the upload. Should this occur ICAO will carry out termination.
10.8 Independent from authentication of new PKD contents the conformity to ICAO Doc 9303 and related international standards is scrutinized (cf. PKD Upload Contents Checks). Non-conformant new PKD contents is tagged. For all non-conformant PKD contents error codes are assigned to elaborate the deviations in greater detail. The process of DSC, Master Lists, Deviation Lists and CRL upload to the PKD Download Directory will be accompanied by automated notifications via e-mail to the Participant’ s CIL and EMA.
10.9 The new DSCs, Master Lists, Deviation Lists and CRL shall be available for public download after the next version update of the PKD Download Directory, not to be later than 6 hours after the wait period ended.
10.10 Upon receipt of the e-mail acknowledgement of successful upload to the PKD Download Directory the CIL shall verify the accuracy of the new DSC, Master Lists, Deviation Lists and CRL and immediately notify ICAO in the event of any discrepancies. If the CIL fails to receive any receipt notification within 2 hours of DSC, Master Lists, Deviation Lists and CRL upload to the PKD Upload Directory, or an approval e-mail notification within 4 business days after the wait period ended, the CIL should follow-up with ICAO immediately.
10.11 As the EMA is notified by the ICAO PKD System of all successfully completed PKD Upload activities of a CIL, it can provide a second level of checks on the accuracy of the contents uploaded to the PKD. In addition, the EMA has the responsibility to ensure that all actions carried out by a CIL are authorized, and that there are no unusual activities.
The details how to access to PKD Production environment for PKD Upload can be found in the document “PKD Procedures for Participants” provided by ICAO upon successful registration.
Por su parte, la especificación para interfaz PKD sólo está disponible para los Estados asociados, si bien, se puede encontrar información sobre este proceso en el «ICAO PKD White Paper for Participants» (Libro Blanco del PKD de la OACI para Participantes), que también está redactado en inglés y con relación a la carga de certificados recoge:
3 LDAP structure
This chapter describes the handling of the LDAP structure within the provided ICAO PKD service. This includes the description of the LDAP structure.
3.1 LDAP structure
The ICAO PKD service provides a LDAP structure with clearly defined attribute type definitions, object class definitions and an unique directory root “dc=pkd,dc=icao,dc=int”. The attribute types and object classes of the LDAP structure are described in the separate document “ICAO PKD Interface Specification for Participants”.
Within the provided ICAO PKD service there are three different repositories, providing different sub-trees of the unique ICAO PKD directory root – the upload repository providing the writable upload sub-tree structure for the participants, the download repository providing the read-only download sub-tree structure for the participants and the intermediate repository providing the working sub-tree for the ICAO PKD Operators and ICAO PKD Officers. Each repository contains separate access user accounts.
3.1.1 Upload Repository
The upload repository in the “dc=upload,dc=pkd,dc=icao,dc=int” subtree contains during the upload step the data uploaded by the participating states, which is their PKD data in the “dc=data” subtree and their CSCA registry information in the “dc=registry” subtree. Each participating state gets its own writable subtree.
The certificate-based upload user accounts are located in the “dc=meta” subtree.
Figure 2: Directory Information Tree – Upload Repository
3.1.2 Intermediate Repository
The intermediate repository in the “dc=intermediate,dc=pkd,dc=icao,dc=int” subtree contains all data that have been processed by the upload prepare process, but have not been processed for download or alternatively rejected. Processed PKD data are stored in the “dc=ul-data” subtree, while processed CSCA registry information are stored in the “dc=ul-registry”subtree. This repository also holds data that have been accepted and that have not already been published to the download repository (i.e. data are held during the implemented cool down period). The intermediate repository is also used to create new upload user accounts and download user accounts.
3.1.3 Download Repository
The non-writable download repository in the “dc=download,dc=pkd,dc=icao,dc=int” subtree contains all PKD data and CSCA registry information that have been accepted, that have passed their cool-down period and that have been processed by the download prepare process. Processed PKD data are stored in the “dc=data” or in the “dc=nc-data” subtree, depending on their conformance check results and depending on the decision made by the ICAO. Processed CSCA registry information are stored in the “dc=registry” subtree.
The certificate-based download user accounts and the password-based download user accounts are located in the “dc=meta” subtree.
Figure 3: Directory Information Tree – Download Repository
(sigue la Parte 3 del documento 9303 de la OACI)
2. La oficina PKD de la OACI convalida las firmas de las listas de desviación cargadas, según se especifica en el manual de procedimientos PKD.
(La oficina PKD de la OACI valida las firmas de las listas de desviación cargadas, según se describe en el manual de procedimientos PKD.)
3. Las listas de desviaciones válidas se trasladan a la parte lectura del PKD.
4. El Estado distribuidor determinará si su lista de desviaciones estará disponible públicamente, o si se limitará a los Estados miembros del PKD.
7.4.3 Partes confiantes
Para poder verificar una lista de desviaciones, una parte confidente necesita haber recibido el certificado CSCA correspondiente del Estado emisor mediante comunicaciones fuera de banda. Corresponde a la parte confidente decidir la forma de tramitar los MRTD que tienen una anotación correspondiente en la lista de desviaciones del Estado expedido.»
(Para poder comprobar una lista de desviaciones, una parte que confía necesita haber recibido el certificado CSCA correspondiente del Estado emisor mediante comunicaciones fuera de banda. Corresponde a la parte que confía decidir la forma de gestionar los MRTD que tienen una anotación correspondiente en la lista de desviaciones del Estado emisor.)
(sigue la Parte 12 del documento 9303 de la OACI)
Los medios protegidos de generación de pares de claves ESTARÁN bajo el control del Estado expedidor u organización expedidora. Cada par de claves incluye una clave “privada” y una clave “pública”. Las claves privadas y sistemas o medios conexos ESTARÁN bien protegidos con respecto a cualquier acceso del exterior o no autorizado mediante un diseño inherente y medios de seguridad del soporte físico.
(Los medios protegidos de creación de pares de claves ESTARÁN bajo el control del Estado emisor u organización emisora. Cada par de claves incluye una clave “privada” y una clave “pública”. Las claves privadas y sistemas o medios relacionados ESTARÁN bien protegidos con respecto a cualquier acceso del exterior o no autorizado mediante un diseño interno y medios de seguridad del soporte físico.)
Si bien el certificado CSCA permanece relativamente estático, con el tiempo se creará un gran número de certificados de firmante del documento.
(Si bien el certificado CSCA se mantiene relativamente estable, con el tiempo se creará un gran número de certificados de firmante del documento.)
La CSCA de cada Estado expedidor u organización expedidora actúa como punto de confianza para el Estado receptor. El Estado expedidor u organización expedidora distribuye su propia clave pública CSCA a los Estados receptores en forma de certificado. El Estado receptor establece que este certificado (y claves certificadas) son “de confianza” a través de medios fuera de banda y almacena un “punto de confianza” para dicha clave o certificado de confianza. Estos certificados CSCA SERÁN certificados autofirmados expedidos directamente por la CSCA. Los certificados CSCA NO DEBEN ser certificados subordinados o cruzados en una infraestructura PKI de mayores dimensiones. Los certificados de enlace CSCA autoexpedidos también pueden expedirse para ayudar al Estado receptor a establecer confianza en una nueva clave/certificado CSCA después de una renovación de claves.
(La CSCA de cada Estado emisor u organización emisora actúa como punto de confianza para el Estado receptor. El Estado emisor u organización emisora distribuye su propia clave pública CSCA a los Estados receptores en forma de certificado. El Estado receptor establece que este certificado (y claves certificadas) son “de confianza” a través de medios fuera de banda y almacena un “punto de confianza” para dicha clave o certificado de confianza. Estos certificados CSCA SERÁN certificados autofirmados emitidos directamente por la CSCA. Los certificados CSCA NO DEBEN ser certificados subordinados o cruzados en una infraestructura PKI de mayores dimensiones. Los certificados de enlace CSCA autoemitidos también pueden emitirse para ayudar al Estado receptor a establecer confianza en una nueva clave/certificado CSCA después de una renovación de claves.)
Nota.— En algunos Estados se exige que un controlador de autoridad de certificación (CCA) centralizado sea la autoridad suprema para publicar certificados autofirmados para todas las aplicaciones. En estos casos, una posible solución es que la CSCA cree un certificado autofirmado (que satisfaga los requisitos del Doc 9303 de la OACI) y que dicho certificado sea refrendado por la CCA (satisfaciendo los propios requisitos CCA del Estado). No obstante, estos certificados refrendados no son parte de la PKI del eMRTD y no se distribuyen a los Estados receptores.
(Nota.— En algunos Estados se exige que un controlador de autoridad de certificación (CCA) centralizado sea la autoridad suprema para publicar certificados autofirmados para todas las aplicaciones. En estos casos, una posible solución es que la CSCA cree un certificado autofirmado (que cumpla los requisitos del Doc 9303 de la OACI) y que dicho certificado sea aprobado por la CCA (cumpliendo los propios requisitos CCA del Estado). Aun así, estos certificados aprobados no son parte de la PKI del eMRTD y no se distribuyen a los Estados receptores.)
3.1.1 Autoridad de certificación de firma de país
SE RECOMIENDA que los pares de claves CSCA (KPuCSCA, KPrCSCA) se generen y almacenen en una infraestructura de CA fuera de línea y altamente protegida.
(SE RECOMIENDA que los pares de claves CSCA (Country Signing Certification Authority = Autoridad de certificación de firma de país) (KPuCSCA, KPrCSCA) se creen y almacenen en una infraestructura de CA fuera de línea y altamente protegida.)
La clave privada CSCA (KPrCSCA) se utiliza para firmar certificados de firmante del documento (CDS), otros certificados y CRL.
Los certificados de autoridad de certificación de firma de país (CCSCA) se utilizan para validar los certificados de firmante del documento, certificados de firmante de la lista maestra, certificados de firmante de la lista de desviaciones, CRL y otros certificados expedidos por la CSCA.
(Los certificados de autoridad de certificación de firma de país (CCSCA) se utilizan para validar los certificados de firmante del documento, certificados de firmante de la lista maestra, certificados de firmante de la lista de desviaciones, CRL y otros certificados emitidos por la CSCA.)
Todos los certificados y las CRL DEBEN cumplir con los perfiles especificados en la sección 7 y DEBEN distribuirse utilizando los mecanismos de distribución especificados en la sección 5.
(Todos los certificados y las CRL DEBEN cumplir con los perfiles descritos en la sección 7 y DEBEN distribuirse utilizando los mecanismos de distribución detallados en la sección 5.)
La Sección 5 de la Parte 12 del Documento 9303 recoge:
5. MECANISMOS DE DISTRIBUCIÓN
En el caso de la PKI del eMRTD, los objetos PKI deben distribuirse a los Estados receptores. Se utilizan varios mecanismos de distribución diferentes dependiendo del tipo de objeto y los requisitos operacionales. Es importante destacar que la distribución de estos objetos NO establece confianza en ellos ni en las claves privadas o públicas relacionados con ellos. Los mecanismos para establecer confianza se especifican en la sección 6.1.
La Sección 6 de la Parte 12 del Documento 9303 recoge:
6. CONFIANZA Y VALIDACIÓN DE LA PKI
La confianza y validación de la PKI es distinta para la PKI del eMRTD y la PKI de autorización.
6.1 La PKI del eMRTD
En el entorno de la PKI del eMRTD, los sistemas de inspección en los Estados receptores desempeñan la función de partes que confían en la PKI. La verificación satisfactoria de la firma digital en el objeto de seguridad de documento de un eMRTD asegura la autenticidad e integridad de los datos almacenados en el CI sin contacto de dicho eMRTD. Este proceso de verificación de firma requiere que la parte que confía establezca que la clave pública de firmante del documento utilizada para verificar la firma es en sí “de confianza”.
(En el entorno de la PKI del eMRTD, los sistemas de inspección en los Estados receptores realizan la función de partes que confían en la PKI. La comprobación satisfactoria de la firma digital en el objeto de seguridad de documento de un eMRTD asegura la autenticidad e invariabilidad de los datos almacenados en el CI sin contacto de dicho eMRTD. Este proceso de comprobación de firma exige que la parte que confía establezca que la clave pública de firmante del documento utilizada para comprobar la firma es en sí “de confianza”.)
Los diversos mecanismos de distribución definidos en la sección 5 permiten que los Estados receptores tengan acceso a los certificados y CRL que necesitan para verificar las firmas digitales en cuestión. No obstante, estos planes de distribución no establecen confianza en los certificados, CRL o en las claves públicas que se utilizarán para verificar las firmas en esos certificados y CRL.
(Los diversos mecanismos de distribución definidos en la sección 5 posibilitan que los Estados receptores tengan acceso a los certificados y CRL que necesitan para comprobar las firmas digitales respectivas. Aun así, estos planes de distribución no establecen confianza en los certificados, CRL o en las claves públicas que se utilizarán para comprobar las firmas en esos certificados y CRL.)
Las claves públicas contenidas en los certificados CSCA (CCSCA) se utilizan para verificar la firma digital en los certificados y las CRL. Por consiguiente, para aceptar un eMRTD de otro Estado expedidor, el Estado receptor DEBE haber colocado ya en alguna forma de depósito de confianza, accesible por su sistema de control fronterizo, una copia “de confianza” del certificado CSCA (CCSCA) del Estado expedidor u organización expedidora, u otra forma de información sobre el punto de confianza para la clave pública CSCA obtenida del certificado.
(Las claves públicas incluidas en los certificados CSCA (CCSCA) se utilizan para comprobar la firma digital en los certificados y las CRL. Por consiguiente, para aceptar un eMRTD de otro Estado emisor, el Estado receptor DEBE haber colocado ya en alguna forma de depósito de confianza, accesible por su sistema de control fronterizo, una copia “de confianza” del certificado CSCA (CCSCA) del Estado emisor u organización emisora, u otra forma de información sobre el punto de confianza para la clave pública CSCA obtenida del certificado.)
Es responsabilidad del Estado receptor establecer confianza en los certificados CSCA (CCSCA) y almacenar dichos certificados (o información obtenida en los mismos) como puntos de confianza en forma segura para que los utilicen sus sistemas de inspección fronterizos.
6.1.1 Gestión del punto de confianza
Como se especifica en [RFC 5280], debe establecerse un punto de confianza que pueda utilizarse para fundamentar el procedimiento de validación de un firmante del documento, firmante de la lista maestra, firmante de la lista de desviaciones u otro tipo de certificado.
(Como se describe en [RFC 5280], debe establecerse un punto de confianza que pueda utilizarse para fundamentar el procedimiento de aprobación de un firmante del documento, firmante de la lista maestra, firmante de la lista de desviaciones u otro tipo de certificado.)
Cada punto de confianza comprende una clave pública “de confianza” y sus metadatos conexos. Los puntos de confianza DEBEN incluir, como mínimo:
(Cada punto de confianza incluye una clave pública “de confianza” y sus metadatos relacionados. Los puntos de confianza DEBEN incluir, como mínimo:)
• la clave pública de confianza y cualesquiera parámetros de clave conexos;
(la clave pública de confianza y cualesquiera criterios de clave relacionados;)
• el algoritmo de clave pública;
• el nombre del propietario de la clave; y
• el valor de la extensión SubjectAltName del certificado CSCA que contiene el código de tres letras asignado por la OACI de la autoridad u organización expedidora. Aunque no se utilice en la ruta de certificación o procedimientos de validación de CRL, se utiliza en la autenticación pasiva definida en el Doc 9303-11.
(• el valor de la extensión SubjectAltName del certificado CSCA que incluye el código de tres letras asignado por la OACI de la autoridad u organización emisora. Aunque no se utilice en la ruta de certificación o procedimientos de aprobación de CRL, se utiliza en la autenticación pasiva definida en el Doc 9303-11.)
La sección 5 de la Parte 11 del documento 9303 de la OACI recoge:
5. AUTENTICACIÓN DE LOS DATOS
Además de los grupos de datos de LDS, el CI sin contacto también contiene un objeto de seguridad de documento (SOD). Este objeto se firma en forma digital por el Estado expedidor u organización expedidora y contiene representaciones condensadas del contenido de la LDS (véase el Doc 9303-10).
(Además de los grupos de datos de LDS, el CI (Circuito Integrado) sin contacto también incluye un objeto de seguridad de documento (SOD). Este objeto se firma en forma digital por el Estado emisor u organización emisora e incluye representaciones condensadas del contenido de la LDS (véase el Doc 9303-10).)
Un sistema de inspección, que contenga la clave pública del firmante de documentos de cada Estado, o que haya leído el certificado del firmante de documentos (CDS) en el eMRTD, podrá verificar el objeto de seguridad de documento (SOD). De esta manera, mediante el contenido del objeto de seguridad de documento (SOD), se autentica el contenido de la LDS.
(Un sistema de inspección, que tenga la clave pública del firmante de documentos de cada Estado, o que haya leído el certificado del firmante de documentos (CDS = Document Signer Certificate) en el eMRTD, podrá comprobar el objeto de seguridad de documento (SOD = Document Security Object). De esta manera, mediante el contenido del objeto de seguridad de documento (SOD), se autentica el contenido de la LDS =Logical Data Structure.)
Este mecanismo de verificación no exige capacidades de procesamiento en el CI sin contacto del eMRTD. Por consiguiente, se denomina “autenticación pasiva” del contenido del CI.
(Este mecanismo de comprobación no exige capacidades de procesamiento en el CI sin contacto del eMRTD (Electronic Machine Readable Travel Document = Documento de viaje de lectura mecánica electrónico). Por consiguiente, se denomina “autenticación pasiva” del contenido del CI.)
La autenticación pasiva prueba que el contenido del objeto de seguridad de documento (SOD) y la LDS es auténtico y no se ha modificado. No impide la copia exacta del contenido del CI sin contacto o la sustitución de la microplaqueta.
(La autenticación pasiva prueba que el contenido del objeto de seguridad de documento (SOD) y la LDS es auténtico y no se ha modificado. No evita la copia exacta del contenido del CI sin contacto o la sustitución de la microplaqueta.)
Por consiguiente, un sistema de autenticación pasiva DEBERÍA estar apoyado por una inspección física adicional del eMRTD.
5.1 Autenticación pasiva
5.1.1 Proceso de inspección
El sistema de inspección ejecuta las etapas siguientes:
- El sistema de inspección LEERÁ del CI sin contacto el objeto de seguridad de documento (SOD) [que DEBE contener el certificado del firmante del documento (CDS), véase también el Doc 9303-10].
El Apéndice B de la Parte 10 del documento 9303 de la OACI recoge:
Apéndice B de la Parte 10
CI SIN CONTACTO DE UN eMRP (INFORMATIVO)
B.1 TAMAÑO Y CLASE DE LA ANTENA DE UN eMRTD
El Estado expedidor establece el tamaño de antena según su propio criterio. A excepción del tamaño de la antena, tanto la LDS1 como la LDS2 del eMRTD superarán satisfactoriamente todos los ensayos especificados en [ISO/IEC 18745-2] aplicando las especificaciones de clase 1.
(El Estado emisor establece el tamaño de antena según su propio criterio. A excepción del tamaño de la antena, tanto la LDS1 como la LDS2 del eMRTD superarán satisfactoriamente todos los ensayos descritos en [ISO/IEC 18745-2] aplicando las determinaciones de clase 1.)
Se RECOMIENDA que los eMRTD sean también conformes con las especificaciones de la Clase 1.
(Se RECOMIENDA que los eMRTD sean también compatibles con las determinaciones de la Clase 1.)
No se establece una posición obligatoria para el CI, que PUEDE ubicarse en cualquier posición. La situación de la antena sin contacto es discrecional del Estado expedidor, pero siempre en una de las posiciones siguientes:
(No se establece una posición obligatoria para el CI, que PUEDE situarse en cualquier posición. La situación de la antena sin contacto es opcional del Estado emisor, pero siempre en una de las posiciones siguientes:)
Página de datos — el CI y la antena se incluyen en la estructura de una página de datos que es página interna,
Central en el cuadernillo — el CI y la antena se colocan entre las páginas centrales del cuadernillo,
Tapa — se sitúa en la estructura o diseño constructivo de la tapa,
Página separada cosida — el CI y su antena se incluyen en una página separada que PUEDE tener la forma de una tarjeta de plástico de tamaño ID-3 cosida al cuadernillo durante el proceso de fabricación, o
Contratapa — se sitúa en la estructura o diseño constructivo de la tapa trasera del cuadernillo.
B.2 ARRANQUE E INTERROGACIÓN
Un eMRTD expuesto a un campo magnético alterno de 1,5 A/m medido con arreglo a [ISO/IEC 18745-2] responderá a cualquier REQ/WUP que sea adecuada a su tipo tras una exposición a un campo magnético alterno no modulado de 10 m. Se RECOMIENDA que pueda responder a cualquier REQ/WUP adecuada a su tipo tras una exposición al campo magnético alterno no modulado de 5 ms.
(Un eMRTD expuesto a un campo magnético periódico de 1,5 Amperios/milisegundo medido de acuerdo con [ISO/IEC 18745-2] responderá a cualquier REQ/WUP (request / wake up = interrogación / arranque)* que sea adecuada a su tipo tras una exposición a un campo magnético periódico no modulado de 10 milisegundos. Se RECOMIENDA que pueda responder a cualquier REQ/WUP adecuada a su tipo tras una exposición al campo magnético periódico no modulado de 5 milisegundos.)
*NOTA de la redactora: El lector del sistema de inspección pregunta al eMRTD (request) y lo despierta (wake up) para realizar la comunicación sin contacto.
B.3 ANTICOLISIÓN Y TIPO
El eMRTD PUEDE ser conforme con el Tipo A o el Tipo B definidos en [ISO/IEC 14443-2]. Ello no modificará su tipo salvo que sea reinicializado por el sistema de inspección asociado al eMRTD.
(El eMRTD PUEDE ser compatible con el Tipo A o el Tipo B definidos en [ISO/IEC 14443-2]. Ello no modificará su tipo salvo que sea reinicializado por el sistema de inspección enlazado al eMRTD.)
B.4 VELOCIDADES BINARIAS OBLIGATORIAS
El eMRTD proporcionará obligatoriamente, al menos, las velocidades binarias siguientes definidas en [ISO/IEC 14443-2]: 106 kbit/s y 424 kbit/s en ambos sentidos entre el eMRTD y el sistema de inspección asociado al eMRTD.
(El eMRTD admitirá obligatoriamente, al menos, las velocidades binarias siguientes definidas en [ISO/IEC 14443-2]: 106 kilobits por segundo y 424 kilobits por segundo en ambos sentidos entre el eMRTD y el sistema de inspección enlazado al eMRTD.)
La velocidad binaria de 212 kbit/s, y todas las velocidades binarias desde 848 kbit/s hasta 6,78 Mbit/s en ambos sentidos, y de 10,17 Mbit/s a 27.12 Mbit/s desde el sistema de inspección del eMRTD al eMRTD, tal como se define en [ISO/IEC 14443-2], son opcionales.
B.5 PERTURBACIÓN ELECTROMAGNÉTICA (EMD)
No es obligatorio admitir la EMD.
(No es obligatorio admitir la EMD (Electromagnetic Disturbance = Perturbación electromagnética).)
Nota.— La característica EMD mejora la robustez de la comunicación sin contacto entre el eMRTD y el sistema de inspección asociado al eMRTD contra la perturbación electromagnética generada por el propio eMRTD. El consumo de corriente dinámica del eMRTD durante la ejecución de una instrucción puede tener un efecto aleatorio de modulación de la carga (que puede no ser puramente resistiva) sobre el campo magnético. En algunos casos, el sistema de inspección asociado al eMRTD puede interpretar erróneamente la EMD como datos enviados por el eMRTD, lo que puede afectar negativamente a la recepción adecuada de la respuesta del eMRTD.
( Nota.— La característica EMD mejora la robustez de la comunicación sin contacto entre el eMRTD y el sistema de inspección enlazado al eMRTD contra la perturbación electromagnética creada por el propio eMRTD. El consumo de corriente dinámica del eMRTD durante la ejecución de una orden puede tener un efecto imprevisible de modulación de la carga (que puede no ser puramente resistiva) sobre el campo magnético. En algunos casos, el sistema de inspección enlazado al eMRTD puede interpretar erróneamente la EMD como datos enviados por el eMRTD, lo que puede influir negativamente en la recepción adecuada de la respuesta del eMRTD.)
B.6 ADMISIÓN DEL INTERCAMBIO DE PARÁMETROS ADICIONALES (OPCIONAL)
El eMRTD PUEDE admitir el intercambio de parámetros adicionales definidos en [ISO/IEC 14443-4] al objeto de negociar velocidades binarias superiores a 106 kbit/s. También PUEDE utilizar los mismos parámetros adicionales para negociar tramas con corrección de errores, tal como se especifica en [ISO/IEC 14443-4].
(El eMRTD PUEDE admitir el intercambio de criterios adicionales definidos en [ISO/IEC 14443-4] con el fin de negociar velocidades binarias superiores a 106 kilobits por segundo. También PUEDE utilizar los mismos datos adicionales para negociar grupos de datos con corrección de errores, tal como se describe en [ISO/IEC 14443-4].)
B.7 APANTALLAMIENTO
Se RECOMIENDA no apantallar ninguna página del eMRTD.
B.8 IDENTIFICADOR ÚNICO (UID) E IDENTIFICADOR PICC PSEUDOÚNICO (PUPI) (RECOMENDADO)
El eMRTD PUEDE ofrecer un UID/PUPI aleatorio o fijo, tal como se define en [ISO/IEC 14443-3].
(El eMRTD PUEDE ofrecer un UID (UID = Unique Identifier = Identificador Único)/PUPI (PUPI = Pseudo-Unique PICC (PICC = Proximity Integrated Circuit Card = Tarjeta con circuito integrado de proximidad) Identifier = Identificador PICC Pseudoúnico)imprevisible o fijo, tal como se define en [ISO/IEC 14443-3].)
Se RECOMIENDA utilizar un UID/PUPI aleatorio para mejorar la privacidad del titular del eMRTD y reducir la posibilidad de seguimiento.
(Se RECOMIENDA utilizar un UID/PUPI imprevisible para mejorar la privacidad del titular del eMRTD y reducir la posibilidad de seguimiento.)
B.9 GAMA DE FRECUENCIAS DE RESONANCIA (RECOMENDADO)
No existen requisitos sobre la frecuencia de resonancia. Quienes soliciten un eMRTD PUEDEN limitar la frecuencia de resonancia por defecto a una gama de valores dada a fin de aumentar la interoperabilidad.
(No existen requisitos sobre la frecuencia de resonancia. Quienes soliciten un eMRTD PUEDEN limitar la frecuencia de resonancia automáticamente a una gama de valores dada a fin de aumentar el interfuncionamiento.)
B.10 TAMAÑOS DE TRAMA (RECOMENDADO)
El eMRTD PUEDE admitir tamaños de trama de hasta 4 kbyte con arreglo a [ISO/IEC 14443]. No obstante, se RECOMIENDA admitir tamaños de trama de al menos 1 kbyte. Si se admiten tamaños de trama superiores a 1 kbyte, se RECOMIENDA utilizar tramas con la corrección de errores definida en [ISO/IEC 14443-4].
(El eMRTD PUEDE admitir tamaños de grupos de datos de hasta 4 kilobyte de acuerdo con [ISO/IEC 14443]. Aun así, se RECOMIENDA admitir tamaños de grupos de datos de al menos 1 kilobyte. Si se admiten tamaños de grupos de datos superiores a 1 kilobyte, se RECOMIENDA utilizar grupos de datos con la corrección de errores definida en [ISO/IEC 14443-4].)
Nota.— Un tamaño de trama superior reduce sustancialmente el tiempo total de procesamiento de una aplicación del eMRTD.
(Nota.— Un tamaño de grupo de datos superior reduce sustancialmente el tiempo total de procesamiento de una aplicación del eMRTD.)
B.11 ENTERO CORRESPONDIENTE AL TIEMPO DE ESPERA DE TRAMA (FWI) Y PETICIÓN DE PRÓRROGA DEL TIEMPO DE ESPERA DEL BLOQUE-S [S(WTX)] (RECOMENDADO)
(B.11 ENTERO CORRESPONDIENTE AL TIEMPO DE ESPERA DE TRAMA (FWI = Frame Waiting Time Integer) Y PETICIÓN DE PRÓRROGA DEL TIEMPO DE ESPERA DEL BLOQUE-S [S(WTX) = S-Block Request For Waiting Time Extension] (RECOMENDADO))
Se RECOMIENDA que se fije un valor de FWI para el eMRTD menor o igual a 11 para mejorar la calidad de funcionamiento. Se RECOMIENDA utilizar instrucciones S(WTX) para ampliar el tiempo de espera de trama para cada instrucción que requiera tiempo adicional mediante el uso de instrucciones S(WTX) con un WTXM no superior a 10.
(Se RECOMIENDA que se fije un valor de FWI (Frame Waiting Time Integer) para el eMRTD menor o igual a 11 para mejorar la calidad de funcionamiento. Se RECOMIENDA utilizar instrucciones S(WTX) (S-Block Request For Waiting Time Extension) para ampliar el tiempo de espera de grupo de datos para cada orden que necesite tiempo adicional mediante el uso de instrucciones S(WTX) con un WTXM no superior a 10.)
Si se envían varias solicitudes S(WTX) al eMRTD, se RECOMIENDA que el tiempo de procesado total para el bloque I-Block no supere los 5 s.
(Si se envían varias solicitudes S(WTX) al eMRTD, se RECOMIENDA que el tiempo de procesado total para el bloque I-Block (I-Bloque) no supere los 5 segundos.)
Nota.— Valores inferiores de FWI tal como se RECOMIENDA aquí disminuyen sustancialmente la pérdida de tiempo debida a errores de transmisión, mientras que las S(WTX) son el medio ideal para proporcionar más tiempo cuando sea necesario.
(Nota.— Valores inferiores de FWI tal como se RECOMIENDA aquí disminuyen sustancialmente la pérdida de tiempo debida a errores de transmisión, mientras que las S(WTX) son el medio ideal para suministrar más tiempo cuando sea necesario.)
(sigue la sección 5 de la Parte 11 del documento 9303)
- El sistema de inspección CONSTRUIRÁ y VALIDARÁ un trayecto de certificación desde un punto de confianza al certificado del firmante del documento utilizado para firmar el objeto de seguridad de documento (SOD) con arreglo al Doc 9303-12.
- El sistema de inspección UTILIZARÁ la clave pública del firmante del documento verificada para revisar la firma del objeto de seguridad de documento (SOD).
- El sistema de inspección PUEDE leer del CI sin contacto los grupos de datos pertinentes.
- El sistema de inspección GARANTIZARÁ que el contenido del grupo de datos es auténtico y no se ha modificado mediante condensación de dicho contenido y comparación del resultado con el valor de condensación correspondiente en el objeto de seguridad de documento (SOD). (El sistema de inspección GARANTIZARÁ que el contenido del grupo de datos es auténtico y no se ha modificado mediante condensación* de dicho contenido y comparación del resultado con el valor de condensación correspondiente en el objeto de seguridad de documento (SOD).)
*NOTA de la redactora: El Documento nº 9303 describe la condensación (Hash) de la siguiente manera: Fórmula matemática que convierte un mensaje de cualquier longitud en una cadena de dígitos única de longitud fija conocida como “compendio de mensajes” que representa el mensaje original. La función hash es unidireccional, es decir, que es imposible invertir el proceso para determinar el mensaje original. Además, esta función no producirá el mismo compendio de mensaje a partir de dos entradas diferentes.
Las siguientes verificaciones adicionales se consideran mejores prácticas:
(Las siguientes comprobaciones adicionales se interpretan como las mejores prácticas:)
- El sistema de inspección o el funcionario inspector DEBERÍA verificar la presencia de una DocumentTypeExtension en el certificado del firmante del documento.
• En caso afirmativo, el sistema de inspección DEBERÍA verificar la coherencia del DocumentTypeExtension, el tipo de documento del Grupo de datos 1 y el tipo de documento de la ZLM (véanse los Docs 9303-12, 9303-10 y 9303-3, respectivamente).
(En caso afirmativo, el sistema de inspección DEBERÍA comprobar la coherencia del DocumentTypeExtension, el tipo de documento del Grupo de datos 1 y el tipo de documento de la ZLM (véanse los Docs 9303-12, 9303-10 y 9303-3, respectivamente).)
En la sección 3 de la Parte 10 del documento 9303 se recoge:
3. ESPECIFICACIONES COMUNES A LDS1 Y LDS2
3.1 Requisitos mínimos de interoperabilidad
Los siguientes SERÁN los requisitos mínimos de interoperabilidad de los pasaportes electrónicos de proximidad de CI sin contacto:
(Los siguientes SERÁN los requisitos mínimos de interfuncionamiento de los pasaportes electrónicos de proximidad de CI sin contacto:)
• ajustarse a [ISO/IEC 14443-1], [ISO/IEC 14443-2], [ISO/IEC 14443-3], [ISO/IEC 14443-4] incluyendo todas las enmiendas y corrigendas conexas;
(• ajustarse a [ISO/IEC 14443-1], [ISO/IEC 14443-2], [ISO/IEC 14443-3], [ISO/IEC 14443-4] incluyendo todas las correcciones y corrigendas relacionadas;)
• ajustarse a la especificación de ensayos de [ISO/IEC 10373-6] incluyendo todas las enmiendas y corrigendas conexas;
(• ajustarse a la determinación de ensayos de [ISO/IEC 10373-6] incluyendo todas las correccioines y corrigendas relacionadas;)
• interfaz de señales Tipo A o Tipo B;
• apoyo para estructura de fichero definida en [ISO/IEC 7816-4] para ficheros transparentes de longitud variable;
(apoyo para estructura de fichero definida en [ISO/IEC 7816-4] para ficheros transparentes de longitud cambiable;)
• apoyo para una o más aplicaciones y órdenes apropiadas definidas en [ISO/IEC 7816-4], según se especifica en el Doc 9303;
(apoyo para una o más aplicaciones y órdenes adecuadas definidas en [ISO/IEC 7816-4], según se describe en el Doc 9303;)
3.2 Características eléctricas
La potencia de radiofrecuencia y la interfaz de señal SERÁN las definidas en [ISO/IEC14443-2]. Se aconseja un mínimo de velocidad de transmisión de 424 kilobits por segundo. El uso de los elementos EMD especificados en [ISO/IEC 14443-2] es OPCIONAL.
3.3 Características físicas
Se recomienda que el tamaño del área de antena de acoplamiento se ajuste a la [ISO/IEC 14443-1] Clase 1 (tamaño de antena ID-1) solamente.
3.4 Protocolo de transmisión
El eMRTD APOYARÁ un protocolo de transmisión en semidúplex definido en [ISO/IEC14443-4]. El eMRTD ADMITIRÁ los protocolos de transmisión de Tipo A o B y la inicialización y protocolos de anticolisión y transmisión con arreglo a ISO/IEC 14443.
(El eMRTD ADMITIRÁ un protocolo de transmisión en semidúplex definido en [ISO/IEC14443-4]. El eMRTD ADMITIRÁ los protocolos de transmisión de Tipo A o B y la inicialización y protocolos de anticolisión y transmisión de acuerdo con ISO/IEC 14443.)
3.4.1 Petición de orden y respuesta a petición
El CI sin contacto RESPONDERÁ a una petición de orden de Tipo A (REQA) o petición de orden de Tipo B (REQB) con respuesta a petición de Tipo A (ATQA) o respuesta a petición de Tipo B (ATQB), según corresponda.
3.4.2 Identificador aleatorio e identificador fijo para el CI sin contacto
El eMRTD puede servir como “radiofaro” en el cual el CI sin contacto emite un identificador único (UID) para el Tipo A, y un PUPI para el Tipo B cuando se le activa inicialmente. Esto puede permitir la identificación de la autoridad emisora. La [ISO/IEC 14443] permite elegir la opción de si el eMRTD presenta un identificador fijo, asignado unívocamente para solo eMRTD, o un número aleatorio, que es diferente en cada comienzo del diálogo de comunicación. Algunos Estados expedidores prefieren implantar un número único por razones de seguridad o cualquier otro motivo. Otros expedidores dan mayor preferencia a preocupaciones sobre el carácter privado de los datos y la posibilidad de rastrear personas debido al uso de identificadores CI fijos.
(El eMRTD puede valer como “radiofaro” en el cual el CI sin contacto emite un identificador único (UID) para el Tipo A, y un PUPI para el Tipo B cuando se le activa inicialmente. Esto puede posibilitar la identificación de la autoridad emisora. La [ISO/IEC 14443] admite elegir la opción de si el eMRTD lleva un identificador fijo, asignado inequívocamente para solo eMRTD, o un número imprevisible, que es diferente en cada comienzo del diálogo de comunicación. Algunos Estados emisores prefieren insertar un número único por razones de seguridad o cualquier otro motivo. Otros emisores dan mayor preferencia a preocupaciones sobre el carácter privado de los datos y la posibilidad de rastrear personas debido al uso de identificadores CI fijos.)
La elección de una u otra opción no disminuye el interfuncionamiento dado que un terminal lector que cumpla con ISO/IEC 14443 entenderá ambos métodos. SE RECOMIENDA el uso de identificadores de CI aleatorios pero los Estados PUEDEN optar por aplicar UID únicos para el Tipo A o PUPI únicos para el Tipo B.
3.5 Conjunto de comandos
Todos los comandos, formatos y sus bytes de estado se definen en [ISO/IEC 7816-4] y en [ISO/IEC 7816-8] con la excepción del comando FILE AND MEMORY MANAGEMENT. El conjunto de comandos mínimo que ha de ser admitido por la LDS1 del eMRTD DEBE ser el siguiente:
(Todas las órdenes, tipos y sus bytes de estado se definen en [ISO/IEC 7816-4] y en [ISO/IEC 7816-8] con la excepción de la orden FILE AND MEMORY MANAGEMENT (GESTIÓN DE FICHEROS Y MEMORIA). El conjunto de órdenes mínimo que ha de ser admitido por la LDS1 del eMRTD DEBE ser el siguiente:)
SELECT (SELECCIONAR);
READ BINARY (LEER BINARIO).
Se reconoce que será necesario contar con órdenes adicionales para establacer el entorno de seguridad correcto y aplicar las disposiciones de seguridad opcionales que se identifican en el Doc 9303-11. La implantación de los mecanismos especificados en el Doc 9303-11 requiere el apoyo de las siguientes órdenes adicionales:
(Se reconoce que será necesario contar con órdenes adicionales para establacer el entorno de seguridad correcto y aplicar las disposiciones de seguridad opcionales que se identifican en el Doc 9303-11. La instalación de los mecanismos especificados en el Doc 9303-11 necesita el apoyo de las siguientes órdenes adicionales:
GET CHALLENGE (OBTENER PUESTA A PRUEBA);
EXTERNAL AUTHENTICATE/ MUTUAL AUTHENTICATE (AUTENTICACIÓN EXTERNA/
AUTENTICACIÓN MUTUA);
INTERNAL AUTHENTICATE (AUTENTICACIÓN INTERNA);
MANAGE SECURITY ENVIRONMENT (GESTIONAR ENTORNO DE SEGURIDAD);
GENERAL AUTHENTICATE (AUTENTICACIÓN GENERAL).
En la sección 3 de la Parte 11 del documento 9303 se recoge:
3. SEGURIDAD DE LOS DATOS ELECTRÓNICOS
Además de la autenticación pasiva mediante firmas digitales y el control de acceso a la microplaqueta, los Estados expedidores o las organizaciones expedidoras PUEDEN optar por una seguridad adicional, utilizando formas más complejas de proteger el CI sin contacto y sus datos.
(Además de la autenticación pasiva mediante firmas digitales y el control de acceso a la microplaqueta, los Estados emisores o las organizaciones emisoras PUEDEN optar por una seguridad adicional, utilizando formas más complejas de proteger el CI sin contacto y sus datos.)
El acceso a un eMRTD comprende las etapas siguientes:
(El acceso a un eMRTD incluye las etapas siguientes:)
- Obtención de acceso al CI sin contacto del eMRTD (sección 4)
La sección 4 de la Parte 11 del documento 9303 recoge:
4. ACCESO AL CI SIN CONTACTO
La adición de un CI sin contacto y sin control de acceso a un eMRTD introduce dos nuevas posibilidades de ataque:
(La unión de un CI sin contacto y sin control de acceso a un eMRTD introduce dos nuevas posibilidades de ataque:)
• los datos almacenados en el CI sin contacto pueden leerse electrónicamente sin que se haya autorizado esta lectura del documento (despumado); y
• la comunicación no cifrada entre un CI sin contacto y un lector puede escucharse furtivamente a una distancia de varios metros.
Aunque hay medidas físicas posibles para impedir el despumado (p. ej., blindaje utilizando una malla metálica en la cubierta de una libreta pasaporte), estas no se aplican a la escucha furtiva. Por consiguiente, se entiende que los Estados expedidores u organizaciones expedidoras DEBERÁN optar por implantar un mecanismo de control de acceso a la microplaqueta, es decir un mecanismo de control de acceso que en efecto requiera el conocimiento del titular del eMRTD de que los datos almacenados en el CI sin contacto son leídos en forma segura. Este mecanismo de control de acceso a la microplaqueta impide el despumado así como la escucha furtiva.
(Aunque hay medidas físicas posibles para impedir el despumado (p. ej., blindaje utilizando una malla metálica en la cubierta de una libreta pasaporte), estas no se aplican a la escucha furtiva. Por consiguiente, se entiende que los Estados emisores u organizaciones emisoras DEBERÁN optar por instalar un mecanismo de control de acceso a la microplaqueta, es decir un mecanismo de control de acceso que en efecto requiera el conocimiento del titular del eMRTD de que los datos almacenados en el CI sin contacto son leídos en forma segura. Este mecanismo de control de acceso a la microplaqueta impide el despumado así como la escucha furtiva.)
Un CI sin contacto protegido por un mecanismo de control de acceso a la microplaqueta impide el acceso a su contenido a menos que el sistema de inspección pueda probar que está autorizado para acceder al CI sin contacto. Esta prueba se obtiene en un protocolo criptográfico, en el que el sistema de inspección demuestra conocer la información obtenida del documento físico.
(Un CI sin contacto protegido por un mecanismo de control de acceso a la microplaqueta impide el acceso a su contenido salvo que el sistema de inspección pueda probar que está autorizado para acceder al CI sin contacto. Esta prueba se obtiene en un protocolo criptográfico, en el que el sistema de inspección demuestra conocer la información obtenida del documento físico.)
DEBE proporcionarse esta información al sistema de inspección antes de que pueda leer el CI sin contacto. La información debe obtenerse en forma óptica/visual del eMRTD (p. ej., de la ZLM). También DEBE ser posible para un inspector ingresar esta información manualmente en el sistema de inspección en caso de no poderse leer mecánicamente la información.
(DEBE facilitarse esta información al sistema de inspección antes de que pueda leer el CI sin contacto. La información debe obtenerse en forma óptica/visual del eMRTD (p. ej., de la ZLM). También DEBE ser posible para un inspector introducir esta información manualmente en el sistema de inspección en caso de no poderse leer mecánicamente la información.)
Suponiendo que en la información del documento físico no pueda obtenerse de un documento cerrado (p. ej., dado que la información se obtiene de la ZLM de lectura óptica), se acepta que el eMRTD fue entregado a inspección con pleno conocimiento. Debido al cifrado del canal, la escucha furtiva de la comunicación exigiría un esfuerzo considerable.
(Suponiendo que la información del documento físico no pueda obtenerse de un documento cerrado (p. ej., dado que la información se obtiene de la ZLM de lectura óptica), se acepta que el eMRTD fue entregado a inspección con pleno conocimiento. Debido al cifrado del canal, la escucha clandestina de la comunicación exigiría un esfuerzo considerable.)
En esta sección se definen dos mecanismos para el control de acceso a la microplaqueta:
• Control de acceso de base (BAC, sección 4.3), basado exclusivamente en criptografía simétrica; y
(Control de acceso de base (BAC = Basic Access Control, sección 4.3), basado exclusivamente en criptografía simétrica; y)
• Establecimiento de conexión autenticada por contraseña (PACE, sección 4.4), que emplea criptografía asimétrica para proporcionar claves de sesión de entropía mayor.
(Establecimiento de conexión autenticada por contraseña (PACE = Password Authenticated Connection Establishment, sección 4.4), que utiliza criptografía asimétrica para facilitar claves de sesión de entropía mayor.)
En el Apéndice A figura información adicional sobre la fuerza de las claves de sesión:
El Apéndice A de la Parte 11 del documento 9303 recoge:
Apéndice A de la Parte 11
ENTROPÍA DE LAS CLAVES DE ACCESO OBTENIDAS
DE LA ZLM (INFORMATIVO)
(ENTROPÍA (MEDIDA DEL DESORDEN DE UN SISTEMA) DE LAS CLAVES DE ACCESO OBTENIDAS DE LA ZLM (ZONA DE LECTURA MECÁNICA) (INFORMATIVO))
Debido a su sencillez, el control de acceso de base resultó ser un protocolo muy exitoso y se ha implantado en casi todos los eMRP.
(Debido a su sencillez, el control de acceso de base resultó ser un protocolo muy exitoso y se ha instalado en casi todos los eMRP.)
La seguridad proporcionada por el control de acceso de base está limitada por el diseño de protocolo. Las claves de acceso de base al documento (KEnc y KMAC) se generan a partir de datos impresos con carácter aleatorio muy limitado. Los datos que se utilizan para la generación de las claves son el número de documento, fecha de nacimiento y fecha de caducidad. Como consecuencia, las claves resultantes tienen una entropía relativamente baja y son débiles desde el punto de vista criptográfico. La entropía real depende del tipo del número de documento. Para un documento de viaje válido por 10 años la fuerza máxima de las claves es de aproximadamente:
(La seguridad suministrada por el control de acceso de base está limitada por el diseño de protocolo. Las claves de acceso de base al documento (KEnc y KMAC) se crean partiendo de datos impresos con carácter imprevisible muy limitado. Los datos que se utilizan para la creación de las claves son el número de documento, fecha de nacimiento y fecha de caducidad. Como consecuencia, las claves resultantes tienen una entropía relativamente baja y son débiles desde el punto de vista criptográfico. La entropía real depende del tipo del número de documento. Para un documento de viaje válido durante 10 años la fuerza máxima de las claves es de aproximadamente:)
• 56 bits para un número de documento numérico (3652 * 1012 posibilidades)
• 73 bits para un número de documento alfanumérico (3652 * 369 * 103 posibilidades).
Especialmente en el segundo caso, esta estimación requiere que el número de documento se elija en forma aleatoria y uniforme, lo que por lo general no sucede. Dependiendo del conocimiento del atacante, la entropía real de la clave de acceso de base al documento puede ser inferior, p. ej., si el atacante conoce todos los números de documento en uso o es capaz de correlacionar números de documento con fechas de caducidad.
(Especialmente en el segundo caso, esta estimación exige que el número de documento se elija en forma imprevisible y unificada, lo que por lo general no sucede. Dependiendo del conocimiento del atacante, la entropía real de la clave de acceso de base al documento puede ser inferior, p. ej., si el atacante conoce todos los números de documento en uso o es capaz de relacionar números de documento con fechas de caducidad.)
No existe una forma directa de fortalecer el control de acceso de base dado que sus limitaciones son inherentes al diseño del protocolo basado en criptografía simétrica (“clave secreta”). Un mecanismo de control de acceso criptográficamente fuerte debe (además) utilizar criptografía asimétrica (“clave pública”).
(No existe una forma directa de fortalecer el control de acceso de base dado que sus limitaciones son propias del diseño del protocolo basado en criptografía simétrica (“clave secreta”). Un mecanismo de control de acceso criptográficamente fuerte debe (además) utilizar criptografía asimétrica (“clave pública”).)
El establecimiento de conexión autenticada por contraseña (PACE) se diseñó para solucionar este problema. Emplea criptografía asimétrica para establecer claves de sesión, cuya fuerza es independiente de la entropía de la contraseña utilizada. Si PACE se implanta con criptografía de curva elíptica con curvas de 256 bits y AES-128 (una elección común), las claves de sesión tendrán entropía de 128 bits.
(El establecimiento de conexión autenticada por contraseña (PACE) se diseñó para solucionar este problema. Utiliza criptografía asimétrica para establecer claves de sesión, cuya fuerza es independiente de la entropía de la contraseña utilizada. Si PACE se instala con criptografía de curva elíptica con curvas de 256 bits y AES-128 (una elección común), las claves de sesión tendrán entropía de 128 bits.)
Deben distinguirse dos tipos de ataque:
• Despumado: es un ataque en línea, es decir, el atacante trata de acceder al CI sin contacto en tiempo real, p. ej., adivinando la contraseña. Si el protocolo utilizado para proteger el CI sin contacto no tiene debilidad criptográfica, la probabilidad de éxito del atacante está dada por el tiempo en que el atacante tiene acceso al CI, la duración de un único intento para adivinar la contraseña y la entropía de pasaporte.
(Despumado: es un ataque en línea, es decir, el atacante trata de acceder al CI sin contacto en tiempo real, p. ej., adivinando la contraseña. Si el protocolo utilizado para proteger el CI sin contacto no tiene debilidad criptográfica, la probabilidad de éxito del atacante depende del tiempo en que el atacante tiene acceso al CI, la duración de un único intento para adivinar la contraseña y la entropía de pasaporte.)
• Escucha furtiva: es un ataque fuera de línea, es decir, el atacante trata de descifrar la comunicación interceptada sin acceder al CI sin contacto. Si el protocolo utilizado para establecer las claves de sesión no tiene debilidad criptográfica, la probabilidad de éxito está dada por la fuerza de las claves de sesión y la potencia de cálculo de que dispone el atacante.
(•Escucha clandestina: es un ataque fuera de línea, es decir, el atacante trata de descifrar la comunicación interceptada sin acceder al CI sin contacto. Si el protocolo utilizado para establecer las claves de sesión no tiene debilidad criptográfica, la probabilidad de éxito depende de la fuerza de las claves de sesión y la potencia de cálculo de que dispone el atacante.)
Para más información, véase [Keesing2009] donde figura un análisis general sobre la entropía de las claves de sesión y una comparación de BAC y PACE, y [BFK2009] que contiene un análisis criptográfico de PACE.
(Para más información, véase [Keesing2009] donde figura un análisis general sobre la entropía de las claves de sesión y una comparación de BAC y PACE, y [BFK2009] que incluye un análisis criptográfico de PACE.)
(sigue la sección 4 de la Parte 11 del documento 9303)
4.1 Configuraciones conformes
(Configuraciones adecuadas)
Las siguientes configuraciones cumplen esta especificación:
• microplaquetas de eMRTD con BAC solamente;
• microplaquetas de eMRTD con PACE y BAC;
• microplaquetas de eMRTD con PACE solamente.
La seguridad proporcionada por el control de acceso de base (BAC) está limitada por el diseño de protocolo, como se explica en el apéndice A. Se prevé que el aumento de la potencia informática a lo largo de los años permitirá realizar ataques contra el BAC con medios financieros moderados y en un plazo de tiempo razonable. Por lo tanto, se acuerda un cambio gradual del BAC al PACE.
(La seguridad suministrada por el control de acceso de base (BAC) está limitada por el diseño de protocolo, como se explica en el apéndice A. Se prevé que el aumento de la potencia informática a lo largo de los años posibilitará realizar ataques contra el BAC con medios financieros moderados y en un plazo de tiempo razonable. Por lo tanto, se acuerda un cambio progresivo del BAC al PACE.)
Se ha definido el siguiente periodo de transición:
(Se ha establecido el siguiente periodo de transición:)
• A partir del 1 de enero de 2027, las microplaquetas de eMRTD DEBERÁN implantar microplaquetas PACE y eMTRD. Implantar únicamente el BAC queda obsoleto. Todos los eMRTD con BAC únicamente, que hayan sido expedidos antes del 1 de enero de 2027 seguirán siendo conformes durante todo su período de validez.
(Desde el 1 de enero de 2027, las microplaquetas de eMRTD DEBERÁN instalar microplaquetas PACE y eMTRD. Instalar únicamente el BAC queda anticuado. Todos los eMRTD con BAC únicamente, que hayan sido emitidos antes del 1 de enero de 2027 seguirán siendo adecuados durante todo su período de validez.)
• A partir del 1 de enero de 2028, el BAC quedará obsoleto y las microplaquetas de eMRTD DEBERÁN implantar el PACE únicamente. Todos los eMRTD con PACE y BAC expedidos antes del 1 de enero de 2028 seguirán siendo conformes durante todo su período de validez.
(Desde el 1 de enero de 2028, el BAC quedará anticuado y las microplaquetas de eMRTD DEBERÁN instalar el PACE únicamente. Todos los eMRTD con PACE y BAC emitidos antes del 1 de enero de 2028 seguirán siendo adecuados durante todo su período de validez.)
Los sistemas de inspección conformes DEBEN apoyar todas las configuraciones del eMRTD conformes. Si un eMRTD apoya PACE y BAC, el sistema de inspección UTILIZARÁ el BAC o el PACE pero no ambos en la misma sesión.
(Los sistemas de inspección adecuados DEBEN apoyar todas las configuraciones del eMRTD que sean adecuadas. Si un eMRTD admite PACE y BAC, el sistema de inspección UTILIZARÁ el BAC o el PACE pero no ambos en la misma sesión.)
Nota 1.— Versiones anteriores del Doc 9303 aceptaban las microplaquetas de eMRTD sin control de acceso a la microplaqueta (“eMRTD simples”). Esto se considera obsoleto en la octava edición. No obstante, los sistemas de inspección conformes DEBEN apoyar eMRTD sin control de acceso a la microplaqueta.
(Nota 1.— Versiones anteriores del Doc 9303 aceptaban las microplaquetas de eMRTD sin control de acceso a la microplaqueta (“eMRTD simples”). Esto se considera anticuado en la octava edición. Pese a ello, los sistemas de inspección adecuados DEBEN apoyar eMRTD sin control de acceso a la microplaqueta.)
Nota 2.— Para el acceso a las aplicaciones LDS2, el IC DEBE requerir también la ejecución del PACE.
(Nota 2.— Para el acceso a las aplicaciones LDS2, el IC DEBE necesitar también la ejecución del PACE.)
4.2 Procedimiento de acceso a la microplaqueta
El procedimiento de acceso a la microplaqueta para autenticar el sistema de inspección consiste en las etapas siguientes.
1. Lectura de EF.CardAccess . (EXIGIDO)
Si el PACE es apoyado por el eMRTD, la microplaqueta de éste DEBE proporcionar los parámetros que han de utilizarse para el PACE en el fichero EF.CardAccess.
(Si el PACE es admitido por el eMRTD, la microplaqueta de éste DEBE suministrar los criterios que han de utilizarse para el PACE en el fichero EF.CardAccess (EF = Elementary File = Fichero elemental; CardAccess = Acceso a la tarjeta.)
Si se dispone de EF.CardAccess, el sistema de inspección LEERÁ el fichero EF.CardAccess (véase la sección 9.2.11) para determinar los parámetros (es decir, cifrado simétrico, algoritmos de acuerdo de clave, parámetros de dominio y correspondencias) apoyados por la microplaqueta eMRTD. El sistema de inspección puede seleccionar cualquiera de estos parámetros.
(Si se dispone de EF.CardAccess, el sistema de inspección LEERÁ el fichero EF.CardAccess (véase la sección 9.2.11) para determinar los criterios (es decir, cifrado simétrico, algoritmos de acuerdo de clave, criterios de dominio y coincidencias) admitidos por la microplaqueta eMRTD. El sistema de inspección puede seleccionar cualquiera de estos criterios.)
Si no se dispone del fichero EF.CardAccess o éste no contiene parámetros para PACE, el sistema de inspección DEBERÍA tratar de leer el eMRTD con control de acceso de base (omitir las etapas hasta la 4).
(Si no se dispone del fichero EF.CardAccess o éste no incluye criterios para PACE, el sistema de inspección DEBERÍA tratar de leer el eMRTD con control de acceso de base (omitir las etapas hasta la 4).)
La sección 9.2.11 de la Parte 11 del documento 9303 recoge:
9.2.11 Almacenamiento en la microplaqueta
Para indicar el apoyo a los protocolos y parámetros apoyados, la microplaqueta del eMRTD PROPORCIONARÁ SecurityInfos en ficheros elementales transparentes (la estructura genérica de estos ficheros figura en el Doc 9303-10):
(Para indicar el apoyo a los protocolos y criterios admitidos, la microplaqueta del eMRTD SUMINISTRARÁ SecurityInfos en ficheros elementales transparentes (la estructura genérica de estos ficheros figura en el Doc 9303-10):)
• El fichero EF.CardAccess contenido en el fichero maestro se EXIGE si la microplaqueta del eMRTD apoya PACE y CONTENDRÁ las SecurityInfos pertinentes que se requieren para PACE:
(El fichero EF.CardAccess incluido en el fichero maestro se EXIGE si la microplaqueta del eMRTD admite PACE e INCLUIRÁ las SecurityInfos correspondientes que se necesitan para PACE:)
– PACEInfo
– PACEDomainParameterInfo
• El fichero EF.CardSecurity contenido en el fichero maestro se EXIGE si
(• El fichero EF.CardSecurity incluido en el fichero maestro se EXIGE si)
– la microplaqueta del eMRTD admite PACE con correspondencia de autenticación de microplaqueta, o
(la microplaqueta del eMRTD admite PACE con coincidencia de autenticación de microplaqueta, o)
– la microplaqueta del eMRTD admite la autenticación del terminal en el fichero maestro, o
– el eMRTD admite la autenticación de la microplaqueta en el fichero maestro
y CONTENDRÁ las siguientes SecurityInfos:
(e INCLUIRÁ las siguientes SecurityInfos:)
– ChipAuthenticationInfo según requiere la autenticación de microplaqueta
(ChipAuthenticationInfo según necesita la autenticación de microplaqueta=
– ChipAuthenticationPublicKeyInfo según se requiere para PACE-CAM/autenticación de microplaqueta
(ChipAuthenticationPublicKeyInfo según se necesite para PACE-CAM/autenticación de microplaqueta)
– TerminalAuthenticationInfo según requiere la autenticación del terminal
(TerminalAuthenticationInfo según necesita la autenticación del terminal)
– EFDIRInfo si hay más aplicaciones, además del eMRTD, presentes en la microplaqueta
– Las SecurityInfos contenidas en EF.CardAccess.
(Las SecurityInfos incluidas en EF.CardAccess.)
• El fichero EF.DG14 contenido en la aplicación del eMRTD SE EXIGE si
(El fichero EF.DG14 incluido en la aplicación del eMRTD SE EXIGE si)
• La microplaqueta del eMRTD admite PACE con correspondencia genérica/integrada
(La microplaqueta del eMRTD admite PACE con coincidencia genérica/integrada)
• La microplaqueta del eMRTD admite la autenticación del terminal en la aplicación eMRTD, o
• La microplaqueta del eMRTD admite la autenticación de la microplaqueta en la aplicación eMRTD
y CONTENDRÁ las siguientes SecurityInfos:
(e INCLUIRÁ las siguientes SecurityInfos:)
– ChipAuthenticationInfo según requiere la autenticación de microplaqueta
– ChipAuthenticationPublicKeyInfo según requiere la autenticación de microplaqueta
– TermninalAuthenticationInfo según requiere la autenticación del terminal
– Las SecurityInfos contenidas en EF.CardAccess.
(- Las SecurityInfos incluidas en EF.CardAccess.)
• El conjunto completo de SecurityInfos (incluyendo las SecurityInfos contenidas en EF.CardAccess no especificadas en el Doc 9303) se ALMACENARÁ adicionalmente en EF.DG14 de la aplicación eMRTD (véase el Doc 9303-10).
(El conjunto completo de SecurityInfos (incluyendo las SecurityInfos incluidas en EF.CardAccess no descritas en el Doc 9303) se ALMACENARÁ adicionalmente en EF.DG14 de la aplicación eMRTD (véase el Doc 9303-10).)
El Apéndice E de la Parte 10 del documento recoge:
Apéndice E de la Parte 10
RESUMEN DE LA ESTRUCTURA DE FICHERO (INFORMATIVO)
Figura E-1. Resumen de las estructuras de fichero
(sigue la sección 9.2.11 de la Parte 11 del documento 9303)
Los ficheros PUEDEN contener SecurityInfos adicionales que caen fuera del alcance de esta especificación.
(Los ficheros PUEDEN incluir SecurityInfos adicionales que están fuera del alcance de esta determinación.)
Nota.— Si bien la autenticidad de las SecurityInfos almacenadas en EF.DG14 y EF.CardSecurity está protegida por la autenticación pasiva, el fichero EF.CardAccess no está protegido.
(sigue la sección 4 de la Parte 11 del documento 9303)
2. Lectura de EF.DIR (OPCIONAL)
El sistema de inspección PUEDE leer el EF.DIR (si está presente) para recuperar una lista de aplicaciones presentes en la microplaqueta del eMRTD.
3. PACE (CONDICIONAL)
(3. PACE (CONDICIONAL = El uso de un artículo depende del uso de otros artículos. Por consiguiente, se especifica bajo qué condiciones el artículo se EXIGE o se RECOMIENDA.))
Esta etapa se RECOMIENDA si la microplaqueta del eMRTD apoya PACE. Este paso se EXIGE si se pretende acceder a las aplicaciones LDS2.
(Esta etapa se RECOMIENDA si la microplaqueta del eMRTD admite PACE. Este paso se EXIGE si se pretende acceder a las aplicaciones LDS2.)
• El sistema de inspección DEBERÍA obtener la clave Kπ de la ZLM. En vez de la ZLM PUEDE usar el número de acceso a la tarjeta (CAN) si éste es conocido por el sistema de inspección.
(El sistema de inspección DEBERÍA obtener la clave Kπ de la ZLM. En vez de la ZLM PUEDE usar el número de acceso a la tarjeta (CAN = Card Access Number) si éste es conocido por el sistema de inspección.)
• La microplaqueta del eMRTD ACEPTARÁ la ZLM como contraseñas para PACE. También PUEDE aceptar el CAN en lugar de la ZLM.
(La microplaqueta del eMRTD (Documento de viaje de lectura mecánica electrónico) ACEPTARÁ la ZLM (Zona de Lectura Mecánica) como contraseñas para PACE (Establecimiento de conexión autenticada por contraseña). También PUEDE aceptar el CAN en lugar de la ZLM.)
• El sistema de inspección y la microplaqueta del eMRTD autentican mutuamente el uso de Kπ y obtienen las claves de sesión KSEnc y KSMAC. Se UTILIZARÁ el protocolo PACE según se describe en la sección 4.4.
(El sistema de inspección y la microplaqueta del eMRTD se autentican mutuamente utilizando Kπ y obtienen las claves de sesión KSEnc y KSMAC. Se UTILIZARÁ el protocolo PACE según se describe en la sección 4.4.)
Si tiene éxito, la microplaqueta del eMRTD ejecuta lo siguiente:
• INICIARÁ la construcción segura de mensajes.
(NICIARÁ la construcción segura de mensajes (protegidos contra alteración o creación ilegal)).
• DARÁ acceso a datos menos sensibles (p. ej., EF.DG1, EF.DG2, EF.DG14, EF.DG15, etc. de la aplicación eMRTD, y al objeto de seguridad de documento. Para la definición de “datos sensibles”, véase el Doc 9303-1).
*NOTA 1: La parte 1 del documento 9303 define los «datos sensibles» de la siguiente manera:
Estos datos se consideran como más sensibles con respecto a la privacidad que los datos no sensibles. El acceso a los datos sensibles DEBERÍA ser más restringido. En el Doc 9303-11 se especifica la autenticación del terminal como un mecanismo interoperable para acceder a datos sensibles. Si no se necesita la interoperabilidad, pueden emplearse otros mecanismos.
(Estos datos se califican como más sensibles con respecto a la privacidad que los datos no sensibles. El acceso a los datos sensibles DEBERÍA ser más limitado. En el Doc 9303-11 se describe la autenticación del terminal como un mecanismo interfuncionable para acceder a datos sensibles. Si no se necesita la interfuncionalidad, pueden utilizarse otros mecanismos)
*NOTA 2: Asimismo, se define en la parte 1 la interoperabilidad o interfuncionamiento como la capacidad de varios sistemas independientes o componentes de subsistemas para trabajar juntos.
(sigue la sección 4 de la Parte 11 del documento 9303)
• RESTRINGIRÁ los derechos de acceso para exigir protección segura de mensajes.
(LIMITARÁ los derechos de acceso para exigir protección segura de mensajes.)
El sistema de inspección DEBE verificar la autenticidad del contenido del fichero EF.CardAccess utilizando el EF.DG14 o el EF.CardSecurity, y del EF.DIR (si está presente y se ha leído) utilizando el EF.CardSecurity.
(El sistema de inspección DEBE comprobar la autenticidad del contenido del fichero EF.CardAccess utilizando el EF.DG14 o el EF.CardSecurity, y del EF.DIR (si está presente y se ha leído) utilizando el EF.CardSecurity.)
Nota.— Si en la microplaqueta del eMRTD no está presente ninguna aplicación LDS2, puede que el EF.CardSecurity no contenga una copia segura del EF.DIR.
(Nota.— Si en la microplaqueta del eMRTD no está presente ninguna aplicación LDS2, puede que el EF.CardSecurity no incluya una copia segura del EF.DIR.)
4. Control de acceso de base (CONDICIONAL)
Esta etapa es EXIGIDA si la microplaqueta del eMRTD impone el control de acceso a la microplaqueta y no se ha utilizado PACE. Si PACE se ejecutó satisfactoriamente o si el eMRTD no impone el control de acceso a la microplaqueta, puede omitirse esta etapa.
(Esta etapa es EXIGIDA si la microplaqueta del eMRTD establece el control de acceso a la microplaqueta y no se ha utilizado PACE. Si PACE se ejecutó satisfactoriamente o si el eMRTD no establece el control de acceso a la microplaqueta, puede saltarse esta etapa.)
La aplicación eMRTD DEBE seleccionarse antes de que se lleve a cabo el control de acceso de base.
• El sistema de inspección DEBERÍA obtener las claves de acceso de base al documento (KEnc y KMAC) de la ZLM.
• El sistema de inspección y la microplaqueta del eMRTD autentican mutuamente el uso de las claves de acceso de base al documento y obtienen las claves de sesión KSEnc y KSMAC.
(• El sistema de inspección y la microplaqueta del eMRTD se autentican mutuamente utilizando las claves de acceso de base al documento y obtienen las claves de sesión KSEnc y KSMAC.)
Si tiene éxito, la microplaqueta del eMRTD ejecuta lo siguiente:
• INICIARÁ la construcción segura de mensajes.
• OTORGARÁ acceso a datos menos sensibles (p. ej., EF.DG1, EF.DG2, EF.DG14, EF.DG15, etc. de la aplicación eMRTD, y al objeto de seguridad de documento).
(ADMITIRÁ el acceso a datos menos sensibles (p. ej., EF.DG1, EF.DG2, EF.DG14, EF.DG15, etc. de la aplicación eMRTD, y al objeto de seguridad de documento).)
• RESTRINGIRÁ los derechos de acceso para exigir construcción segura de mensajes.
(LIMITARÁ los derechos de acceso para exigir construcción segura de mensajes.)
Nota.— Como resultado del procedimiento de acceso a la microplaqueta, el actual DF puede ser o bien el fichero maestro (si se usa el PACE) o la aplicación eMRTD (si se usa el BAC).
(Nota.— Como resultado del procedimiento de acceso a la microplaqueta, el actual DF (Dedicated File = Fichero especializado) puede ser o bien el fichero maestro (si se usa el PACE) o la aplicación eMRTD (si se usa el BAC).)
4.3 Control de acceso de base
4.3.1 Especificación del protocolo
La autenticación y el establecimiento de claves se proporcionan mediante un protocolo de puesta a prueba-respuesta de tres pasadas con arreglo a [ISO/IEC 11770-2] mecanismo de establecimiento de claves 6 utilizando 3DES [FIPS 46-3] como cifra en bloque. Una suma de control criptográfica con arreglo a [ISO/IEC 9797-1] El algoritmo MAC 3 se calcula y se añade a los textos cifrados. DEBEN utilizarse los modos de operación descritos en la sección 4.3.3. Los números aleatorios utilizados solo una vez (nonces) intercambiados DEBEN ser de 8 bytes, el material de cifrado intercambiado DEBE ser de 16 bytes. El IFD (i.e., el sistema de inspección) y el CI sin contacto NO DEBEN utilizar identificadores distintivos como nonces.
(La autenticación y el establecimiento de claves se facilitan mediante un protocolo de puesta a prueba-respuesta de tres pasadas de acuerdo con [ISO/IEC 11770-2] mecanismo de establecimiento de claves 6 utilizando 3DES [FIPS 46-3] como cifra en bloque. Una suma de control criptográfica de acuerdo con [ISO/IEC 9797-1] El algoritmo MAC 3 se calcula y se añade a los textos cifrados. DEBEN utilizarse los modos de operación descritos en la sección 4.3.3. Los números imprevisibles utilizados solo una vez (nonces) intercambiados DEBEN ser de 8 bytes, el material de cifrado intercambiado DEBE ser de 16 bytes. El IFD (InterFace Device = Dispositivo de interfaz) (es decir, el sistema de inspección) y el CI sin contacto NO DEBEN utilizar identificadores distintivos como nonces.)
Con más detalle, el IFD y el CI EJECUTARÁN las etapas siguientes
1) El IFD pide una puesta a prueba en el RND.IC enviando el comando GET CHALLENGE. El CI genera y responde con un nonce RND.IC.
(1) El IFD pide una puesta a prueba en el RND.IC enviando la orden GET CHALLENGE. El CI crea y responde con un nonce (número aleatorio utilizado solo una vez) RND.IC.)
2) El IFD ejecuta las operaciones siguientes:
a) genera un nonce RND.IFD y material de cifrado K.IFD.
(crea un nonce RND.IFD y material de cifrado K.IFD.)
b) genera la concatenación S = RND.IFD || RND.IC || K.IFD.
(crea la concatenación S = RND.IFD || RND.IC || K.IFD.)
c) calcula el criptograma EIFD = E(KEnc, S).
(c) calcula el criptograma* EIFD = E(KEnc, S).)
(*NOTA: En la Parte 1 del documento 9303 se define la criptografía como la «ciencia de transformar información en una forma cifrada e ininteligible por medio de un algoritmo y una clave»)
d) calcula la suma de control MIFD = MAC(KMAC, EIFD).
(calcula la suma de control MIFD = MAC (Message Authentication Code = Código de autenticación de mensajes) (KMAC, EIFD).)
e) envía el comando EXTERNAL AUTHENTICATE con función de autenticación mutua utilizando los datos EIFD || MIFD.
(envía la orden EXTERNAL AUTHENTICATE con función de autenticación mutua utilizando los datos EIFD || MIFD.)
3) El CI ejecuta las operaciones siguientes:
a) verifica la suma de control MIFD del criptograma EIFD.
(comprueba la suma de control MIFD del criptograma EIFD.)
b) descifra el criptograma EIFD.
c) extrae el RND.IC de S y verifica si IFD devolvió el valor correcto.
(extrae el RND.IC de S y comprueba si IFD devolvió el valor correcto.)
d) genera material de cifrado K.IC.
(crea material de cifrado K.IC.)
e) genera la concatenación R = RND.IC || RND.IFD || K.IC.
(crea la concatenación R = RND.IC || RND.IFD || K.IC.)
f) calcula el criptograma EIC = E(KEnc, R).
g) calcula la suma de control MIC = MAC(KMAC, EIC).
h) envía la respuesta utilizando los datos EIC || MIC.
4) El IFD ejecuta las operaciones siguientes:
a) verifica la suma de control MIC del criptograma EIC.
(comprueba la suma de control MIC del criptograma EIC.)
b) descifra el criptograma EIC.
c) extrae RND.IFD de R y verifica si el CI devolvió el valor correcto.
(extrae RND.IFD de R y comprueba si el CI devolvió el valor correcto.)
5) El IFD y el CI obtienen las claves de sesión KSEnc y KSMAC utilizando el mecanismo de obtenció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.
El apartado 9.7 de la Parte 11 del documento 9303 recoge:
9.7 Mecanismo de obtención de clave
9.7.1 Función de obtención de claves
La función de obtención de claves KDF(K,c), se define como sigue:
Entrada: Se requieren las entradas siguientes:
(Entrada: Se necesitan las entradas siguientes:)
• El valor de secreto compartido K (EXIGIDO)
• Un contador c de enteros big-endian de 32-bits (EXIGIDO)
Salida : Cadena de octetos keydata.
Acciones : Se ejecutan las acciones siguientes:
• keydata = H(K || c)
• Salida de cadena de octetos keydata
La función de obtención de claves que el KDF(K,c) requiere una función de condensación adecuada indicada por H (), es decir, la longitud de bits de la función de condensación SERÁ mayor o igual que la longitud de bits de la clave obtenida. El valor de condensación se INTERPRETARÁ como salida de bytes big-endian.
(La función de obtención de claves KDF (Key Derivation Function = Función de obtención de claves)(K,c) necesita una función de condensación adecuada indicada por H(), es decir, la longitud de bits de la función de condensación SERÁ mayor o igual que la longitud de bits de la clave obtenida. El valor de condensación se INTERPRETARÁ como salida de bytes big-endian.)
Nota.— El secreto compartido K se define como cadena de octetos. Si el secreto compartido se genera con ECKA [TR-03111], se UTILIZARÁ la coordenada x del punto generado.
(Nota.— El secreto compartido K se define como cadena de octetos. Si el secreto compartido se crea con ECKA (Elliptic Curve Key Agreement = Acuerdo de clave de curva elíptica) [TR-03111], se UTILIZARÁ la coordenada x del punto creado.)
9.7.1.1 3DES
Para obtener claves 3DES [FIPS 46-3] de 128-bits (112-bits excluyendo bits de paridad) se EMPLEARÁ la función de condensación SHA-1 [FIPS 180-4] y DEBEN ejecutarse las siguientes etapas adicionales:
(Para obtener claves 3DES (DES = Data Encryption Standard = Norma de cifrado de datos; 3DES = Triple DES) [FIPS 46-3] (FIPS = Federal Information Processing Standard = Norma federal de procesamiento de la información) de 128-bits (112-bits excluyendo bits de paridad) se UTILIZARÁ la función de condensación SHA-1 (SHA = Secure Hash Algorithm = Algoritmo de condensación (hash) seguro) [FIPS 180-4] y DEBEN ejecutarse las siguientes etapas adicionales:)
• Utilización de octetos 1 a 8 de keydata para formar keydataA y octetos 9 a 16 de keydata para formar keydataB; no se utilizan octetos adicionales.
• Ajustar los bits de paridad de keydataA y keydataB para formar claves DES correctas (OPCIONAL).
9.7.1.2 AES
9.7.1.2 AES (AES = Advanced Encryption Standard = Norma criptográfica avanzada)
Para obtener claves AES [FIPS 197] de 128-bits se UTILIZARÁ la función de condensación SHA-1 [FIPS 180-4] y se DEBE ejecutar la siguiente etapa adicional:
• Utilización de octetos 1 a 16 de keydata; no se utilizan octetos adicionales.
Para obtener claves AES [FIPS 197] de 192-bits y 256-bits se UTILIZARÁ la función SHA-256 [FIPS 180-4]. Para las claves AES de 192-bits DEBE ejecutarse la siguiente etapa adicional:
• Utilización de octetos 1 a 24 de keydata; no se utilizan octetos adicionales.
9.7.2 Claves de acceso de base al documento
El cálculo de dos claves 3DES a partir de una semilla de claves (K) se utiliza para establecer las claves de acceso de base al documento KEnc = KDF (K,1) y KMAC = KDF (K,2).
(El cálculo de dos claves 3DES partiendo de una semilla de claves (K) se utiliza para establecer las claves de acceso de base al documento KEnc = KDF (K,1) y KMAC = KDF (K,2).)
9.7.3 PACE
Sea KDFπ(π) = KDF(f(π),3) una función de obtención de claves para obtener claves de cifrado de una contraseña π. La codificación de las contraseñas, es decir, K= f(π) se especifica en la tabla 14:
Tabla 14. Codificación de contraseñas
Nota.— El número del documento que ha de utilizarse como entrada siempre es el número completo del documento. En el caso de los documentos TD1 cuyo número de documento consta de más de nueve caracteres, el número del documento tiene que concatenarse a partir del campo del número del documento y el campo de datos opcionales de la ZLM, excluido el carácter de relleno. Véase también la nota j) en la sección 4.2.2 del Doc 9303-5.