Archivo de la categoría: Common Criteria

El «rulebook» del PID en la Cartera de Identidad Digital Europea (Cartera IDUE)

Deja un comentario

Un «rulebook» en el contexto de la EUDI Wallet (European Union Digital Identity Wallet) es un documento técnico de especificación que forma parte del «Architecture and Reference Framework» (ARF) o Arquitectura y Marco de Referencia, de la cartera de identidad digital europea. Los rulebooks definen los requisitos específicos para cada tipo de declaración de atributos o caso de uso dentro del ecosistema EUDI (regulado por eIDAS 2.0 y los Actos de Ejecución como el CIR 2024/2977 y 2024/2979).

No son documentos legales vinculantes en sí mismos (son «working documents» documentos de trabajo del eIDAS Expert Group), pero son obligatorios para lograr interoperabilidad, certificación y cumplimiento técnico entre Carteras, proveedores de PID (Person Identification Data», Datos de Identificación Personal) y Partes usuarias (Relying Parties) en toda la UE.

El PID Rulebook (o Annex 3.01 – PID Rulebook) es el específico para los Person Identification Data (PID): la declaración de atributos de identidad básica obligatoria emitida por un Estado miembro (o su PID Provider designado). Contiene requisitos adicionales a los del ARF general, que aplican a todos los casos de uso (incluyendo EAAs,(Electronic Attribute Attestation o Declaración Electrónica de Atributos, QEAAs, Qualified Electronic Attribute Attestation o Declaración Electrónica Cualificada de Atributos, etc.). Define cómo se estructura, codifica, emite y valida el PID para garantizar privacidad (selective disclosure, unlinkability), seguridad (firmas criptográficas) y portabilidad transfronteriza.

Detalles técnicos del PID Rulebook

El PID Rulebook especifica:

  • Namespaces y schema de atributos:
    • Namespace europeo principal: eu.europa.ec.eudi.pid.1 (para el tipo de documento y atributos comunes).
    • Domestic namespaces: Cada Estado miembro puede definir atributos nacionales adicionales (ej. eu.europa.ec.eudi.pid.es.1 para España). Se publican públicamente y se usan tanto en codificación ISO como SD-JWT.
    • Atributos obligatorios (M) y opcionales (O), basados en el Anexo del CIR 2024/2977 y codificados según CDDL (RFC 8610):
Atributo PID (ARF)Elementos de datos (Data Element ID)Definición / EjemploPresenciaCodificación
Current Family Namefamily_nameApellido(s) actual(es)Mtstr (UTF-8, máx. 150 chars)
Current First Namesgiven_nameNombre(s) actual(es)Mtstr
Date of Birthbirth_dateFecha completa (YYYY-MM-DD)Mfull-date (RFC 8943)
Age attestationsage_over_18, age_over_NN, age_in_years, age_birth_yearVerificaciones de edad (sin revelar fecha exacta)Obool / uint
Family/First Names at Birthfamily_name_birth / given_name_birthNombres al nacerOtstr
Place of Birthbirth_place, birth_country, etc.Lugar de nacimientoOtstr (ISO 3166)
Current Addressresident_address, resident_country, etc.Dirección actualOtstr
GendergenderISO/IEC 5218Ouint
NationalitynationalityCódigo Alpha-2 (ISO 3166-1); multi-valor en domesticOarray de tstr
  • Metadatos del PID (tratados como atributos técnicos): issuance_date (M), expiry_date (M), issuing_authority (M), document_number, issuing_country (ISO 3166-1, M), issuing_jurisdiction (ISO 3166-2, O), etc.
  • Formatos de codificación y presentación (PID_01 requiere soporte dual):
    • ISO/IEC 18013-5 (mdoc / CBOR): Para verificación offline/proximidad (tap NFC o QR). Usa CBOR (RFC 8949), MSO (Mobile Security Object) firmado por el PID Provider. Canonical CBOR obligatorio. Nacionalidad como array; portrait (foto) como JPEG puro (ISO/IEC 19794-5, sin headers).
    • SD-JWT VC (IETF RFC): Para online (OpenID4VP). JSON + selective disclosure (disclosure salts para privacidad). Soporta batch issuance y re-issuance para unlinkability.
    • Los datos deben ser válidos en el momento del validFrom del MSO o del VP Token. La firma siempre la hace el PID Provider (no el wallet). Los elementos domestic pueden firmarse opcionalmente por el wallet.
  • Trust infrastructure: PID Providers se listan en Trusted Issuer Lists (formato ETSI TS 119 612). Revocación vía status lists o embedded en el MSO/SD-JWT.
  • Otros requisitos: Soporte OpenID4VCI para emisión (incluyendo batch y re-issuance), Wallet Unit Attestation (WUA) previa, y activación del PID a LoA High (según Reglamento de Ejecución 2015/1502).

El rulebook asegura que el PID sea interoperable, minimice datos (data minimization) y cumpla privacy-by-design (zero-knowledge proofs para edad, etc.).

En el caso de España, aunque el número de DNI no forma parte de la lista de atributos obligatorios, se incluirá en todo caso, ya que es posible hacerlo en los opcionales (documet_number o personal_administrative_number) junto con otros datos correspondientes a la entidad emisora del DNI.

Reto principal para los países miembros al inicializar la cartera con el PID.

La inicialización (onboarding/provisioning) del PID es el paso crítico y más complejo. El wallet solo es plenamente operativo tras recibir un PID válido emitido por un «PID Provider» certificado del Estado miembro.

Retos técnicos y operativos:

  • Autenticación fuerte (LoA High): El usuario debe probar su identidad real frente al PID Provider (usando eID nacional, biometría, NFC, etc.). Esto requiere integración segura con fuentes auténticas nacionales.
  • Protocolos de emisión: Soporte completo de OpenID4VCI + activación del PID (verificación de que llegó al Wallet Secure Cryptographic Application – WSCA, normalmente en Secure Element del móvil o software certificado).
  • Certificación: Toda la solución (wallet + PID Provider) debe certificarse según CIR 2024/2981/CIR 2024/2982 (Common Criteria EAL4+ o equivalente). Incluye hardware/software del móvil, NFC reader mode y WSCA.
  • Privacidad y escalabilidad: Batch issuance para evitar linkability, soporte de selective disclosure, revocación eficiente y gestión de millones de usuarios sin fricción.
  • Interoperabilidad transfronteriza: El PID debe ser aceptable en toda la UE independientemente del formato (ISO o SD-JWT).
  • Infraestructura de confianza: Crear y mantener Trusted Issuer Lists, integrar con eIDAS nodes y garantizar que el wallet sea «certified EUDI Wallet Solution».
  • Experiencia de usuario vs. seguridad: Evitar fricción (muchos usuarios no tienen NFC o no quieren tapear el DNI físico) mientras se cumple el nivel High de assurance.

Muchos países usan lectura NFC del documento físico (DNIe, eID, pasaporte) como método principal de onboarding inicial, combinado con selfie + verificación biométrica y backend de autenticación.

Caso específico de España: Inicialización con NFC del móvil leyendo el DNIe

En España, el PID Provider se espera que sea la FNMT (Fábrica Nacional de Moneda y Timbre), que emitirá el PID vinculado al DNI (Documento Nacional de Identidad). La cartera nacional en desarrollo es la Cartera Digital (presentada en EUDI Wallet Launchpad 2025), que se prevé que se integrará con Cl@ve (que ya cuenta con más de 24 millones de usuarios) y aprovecha el DNIe 3.0/4.0 (con chip NFC obligatorio desde 2021).

Flujo técnico detallado de inicialización (onboarding con NFC):

  1. El usuario descarga la app oficial de la Cartera Digital IDUE e inicia la configuración (crea PIN, asocia biometría captada con el móvil, obtiene la «Wallet Unit Attestation» – WUA).
  2. Para solicitar el PID: la app activa el NFC reader mode del móvil (Android e iOS soportan lector de tarjetas ISO 14443 tipo A/B; el DNIe usa PACE/BAC para acceso seguro al chip).
  3. El usuario acerca el DNIe físico al móvil. La app lee criptográficamente:
    • Datos del chip (MRZ, foto, datos personales, certificados de autenticación).
    • Verifica la integridad y autenticidad del chip (firmas, claves de lectura protegidas).
  4. Autenticación del titular:
    • Comparación biométrica: mediante foto del usuario vs. foto conservada en el chip (usando verificación facial certificada según la norma ETSI TS 119 461).
    • Posible PIN del DNIe .
    • La app envía datos anonimizados o challenge-response al servidor de la FNMT para validación (en teoría relativa a la información del registro civil (fuente auténtica).
  5. Una vez autenticado (LoA High), el PID Provider genera el PID:
    • En ambos formatos: mdoc (ISO 18013-5/CBOR) + SD-JWT VC.
    • Incluye atributos obligatorios + opcionales nacionales (domestic namespace eu.europa.ec.eudi.pid.es.1 si aplica).
    • Firma con clave del emisor (listada en Trusted Issuer List).
    • Emite vía OpenID4VCI (posiblemente batch para privacidad futura).
  6. El wallet recibe, verifica y activa el PID (WSCA lo almacena de forma segura). El usuario puede ahora usarlo para identificación online/offline en toda la UE.

Retos específicos en España:

  • Compatibilidad NFC: El DNIe 4.0 está optimizado, pero requiere que la app gestione correctamente protocolos PACE (Password Authenticated Connection Establishment) y que el móvil tenga interfaz NFC (casi todos los actuales lo tienen). iOS restringe algo más el acceso NFC a apps de terceros, por lo que la app oficial debe estar pre-aprobada por Apple.
  • Integración con Cl@ve: La identificación y autenticación en Cl@ve con la Cartera dará lugar seguramente a un nuevo icono de autenticación en la página web de Cl@ve que posiblemente desencadene la apertura de una página con código QR que lea la Cartera y desencadene la autenticación.
  • Certificación y escalabilidad: La solución completa (app + obtención del PID) debe superar la auditoría establecida por la norma de certificación de carteras de ENISA, posiblemente mediante el esquema Lince del CCN.

El «Rulebook» del PID marca la primera implementación de una «Declaración Electrónica de Atributos» (contando con que cada tipo de «Declaración Electrónica de Aributos» tiene su propio «Rulebook»). Los «rulebooks» son las reglas de juego de tipo técnico para el PID y para las DEA e indican los tipos de datos necesarios para cada caso de uso..

En España, el uso del interfaz NFC del DNIe posiblemente sea el método más directo y seguro para la inicialización de los datos de identidad de la Cartera, con el aliciente de aprovechar la infraestructura ya existente y convirtiendo el móvil en lector de DNIe criptográficamente seguro. Esto minimizaría la fricción y maximizaría la adopción.

En todo caso, se requiere que la app esté certificada en cuanto a los requisitos de seguridad.

ENISA anticipa el borrador de la norma de evaluación de las Carteras de Identidad Digital de la UE

2 respuestas

La Agencia europea ENISA acaba de lanzar una consulta pública sobre el borrador del esquema candidato de certificación para la Cartera de Identidad Digital Europea (EUDI Wallet), tras su desarrollo por el Grupo de Trabajo Ad Hoc (Ad Hoc Working Group) auspiciado por ENISA y del que me honro en formar parte.

Tras la adopción del Reglamento que establece el Marco Europeo de Identidad Digital (EIDAS2), la Comisión Europea solicitó a ENISA que apoyara la certificación de las Carteras de Identidad Digital Europea, incluyendo el desarrollo de un esquema europeo de certificación de ciberseguridad conforme al Cybersecurity Act.

Ahora, la Agencia europea ENISA publica el borrador de la norma y lo somete a una consulta pública.

La consulta pública tiene como objetivo validar los principios y la organización general del esquema propuesto, así como recopilar comentarios sobre los elementos del borrador y sus anexos. El plazo para enviar respuestas finaliza el 30 de abril de 2026.

Próximo seminario web

ENISA organizará un webinar para presentar el borrador del esquema candidato de la EUDI Wallet y responder preguntas: el Miércoles 8 de abril, de 15:00 a 16:30 CEST.

Esquemas nacionales de certificación de la EUDI Wallet

En febrero de 2026, ENISA firmó un Acuerdo de Contribución por 1,6 millones de euros con la Comisión Europea, con una duración de dos años, para apoyar el desarrollo, despliegue e implementación de esquemas nacionales de certificación de la Cartera de Identidad Digital Europea.

Financiado por el Programa Europa Digital (DEP) 2025–2027, el acuerdo establece los siguientes ámbitos de actividad:

  • Desarrollo de esquemas nacionales de certificación por parte de los Estados miembros
  • Aumento del conocimiento, capacidades y confianza mutua entre los Estados miembros y el ecosistema de certificación
  • Incremento de la capacidad y eficacia operativa para los Estados miembros y el ecosistema
  • Inicio de la alineación y transición efectiva desde los esquemas nacionales hacia un esquema europeo de certificación de ciberseguridad

Los Estados miembros deberán proporcionar al menos una Cartera de Identidad Digital Europea certificada antes de finales de 2026.

ENISA apoyará a la Comisión Europea y a los Estados miembros en la definición de controles de ciberseguridad en el ámbito de la identificación digital, facilitando su adopción oportuna en toda la UE.

¿Qué es la EUDI Wallet?

El uso de carteras digitales (EUDI Wallet, European Union Digital Identity Wallet) es un paso clave hacia una identificación fluida y segura tanto en el mundo físico como en el digital. Garantiza la seguridad y la protección de la privacidad de los usuarios y de sus datos personales.

El esquema de certificación verificará que cada cartera cumple altos requisitos de seguridad.

Hasta 2026, las implementaciones de carteras digitales rara vez habían pasado por procesos formales de certificación. El desarrollo de esquemas de certificación responde a la necesidad de un marco coherente de ciberseguridad que facilite el cumplimiento para los fabricantes, mejore la transparencia y apoye el uso seguro de productos y servicios digitales.

Las Carteras de Identidad Digital Europea también se debatirán en la Conferencia Europea de Certificación de Ciberseguridad 2026, titulada “Construir confianza mediante la certificación: las afirmaciones de seguridad deben demostrarse, no prometerse”, el 15 de abril de 2026 en Chipre.

Esquema de Certificación propuesto (EUDIW v0.4.614) para Revisión Pública

Esta publicación es una versión preliminar del esquema candidato de certificación de EUDIW (Esquema Europeo de Certificación de Ciberseguridad para las Carteras de Identidad Digital Europeas —EUDI Wallets— y los sistemas de identidad electrónica bajo los cuales se proporcionan).

El documento es el resultado del trabajo conjunto de los expertos del Ad Hoc Working Group (creado según lo previsto en el Artículo 48.2 del Reglamento (UE) 2019/881 «Ley de Ciberseguridad») y se presenta como base para una revisión pública, cuyo objetivo es:

  • Validar los principios y la organización general del esquema propuesto.
  • Recoger comentarios y observaciones sobre los elementos del borrador y sus anexos.

El esquema aborda la certificación de la ciberseguridad de los servicios en la nube relacionados con:

  • Las Carteras de Identidad Digital Europea (EUDI Wallets).
  • Los sistemas de identidad electrónica que las sustentan.

El borrador se acompaña de una versión preliminar del documento:

  • Requisitos de Seguridad para Proveedores de Servicios Relacionados con la Cartera (Wallet-Related Service Provider Security Requirements), v0.5.614

Este documento se incluye solo como referencia y para obtener una opinión temprana sobre el enfoque seguido.

Está abierta una revisión pública mediante el siguiente formulario (EUDIW Public Review) con Fecha límite: jueves 30 de abril de 2026 (incluido)

Archivos disponibles

Referencias en inglés:

EUCC y FITCEM, sistemas de certificación de seguridad, similitudes y diferencias

Deja un comentario

EUCC y FITCEM son dos enfoques europeos para evaluar y certificar la ciberseguridad de productos TIC: EUCC es el gran “esquema europeo” basado en Common Criteria, mientras que FITCEM es una norma EN de evaluación MÁS “ligera” y de tiempo fijo que aspira a armonizar esquemas nacionales más ágiles, como LINCE, en España.

Qué es EUCC

  • EUCC es el primer esquema europeo de certificación de ciberseguridad adoptado bajo el Cybersecurity Act (Reglamento (UE) 2019/881).
  • Está pensado como esquema horizontal para productos TIC (hardware, software y componentes) reutilizable en múltiples sectores.
  • Se basa en Common Criteria y en la Common Evaluation Methodology (ISO/IEC 15408 e ISO/IEC 18045), sustituyendo paulatinamente a los esquemas nacionales CC y al acuerdo SOG-IS.
  • Aplica los niveles de garantía del Cybersecurity Act (básico, sustancial, alto), con requisitos estrictos para organismos de evaluación (CB acreditados según ISO/IEC 17065 e ITSEF según ISO/IEC 17025).
  • Es voluntario en origen, pero puede convertirse en requisito a través de NIS2 u otra normativa sectorial para determinados operadores.certification.enisa.

Ejemplo: un módulo criptográfico hardware certificado bajo Common Criteria en un esquema nacional pasará, con el periodo transitorio, a buscar el sello EUCC para tener reconocimiento uniforme en toda la UE.

Qué es FITCEM (EN 17640)

  • FITCEM es la denominación habitual de la norma europea EN 17640, que define una metodología de evaluación de ciberseguridad “fixed-time” (tiempo fijo) para productos TIC.
  • Se concibe también como marco modular, adaptable a diferentes necesidades de aseguramiento e integrable en distintos dominios y esquemas.
  • Está alineado con los niveles de aseguramiento del Cybersecurity Act (básico, sustancial y alto), aunque su foco es permitir certificaciones más ágiles que las basadas en Common Criteria.
  • Aspira a sustituir o armonizar esquemas nacionales “ligeros” como LINCE (España), BSZ (Alemania), BSPA, CSPN (Francia) u otros equivalentes, proporcionando un lenguaje común europeo para evaluaciones limitadas en tiempo y esfuerzo.
  • Puede actuar como base técnica para esquemas europeos de ciberseguridad “ligeros” orientados a productos con ciclos de vida rápidos (IoT, componentes, etc.).

Ejemplo: un dispositivo IoT de consumo que necesita una certificación rápida y económica podría evaluarse con una metodología basada en FITCEM, con un tiempo máximo predefinido de análisis y pruebas.

Similitudes clave

AspectoEUCCFITCEM (EN 17640)
Ámbito jurídicoEsquema oficial UE bajo Cybersecurity Act. certification.Norma EN apoyando esquemas y normas UE.
Tipo de esquemaEsquema horizontal de certificación CC. Marco modular de evaluación fixed‑time.
Niveles (basic/substantial/high)Aplica niveles y requisitos detallados. Metodología alineada con dichos niveles.
Sector/aplicaciónProductos TIC de alta criticidad, uso general. Productos TIC, incluido IoT y esquemas ligeros.
Rol frente a esquemas nacionalesSustituye esquemas CC y acuerdo SOG‑IS. Destinado a reemplazar/armonizar LINCE, BSZ, CSPN, etc.

Diferencias fundamentales

  • Base técnica y profundidad
    • EUCC hereda todo el rigor de Common Criteria: perfiles de protección, objetivos de seguridad, familias de requisitos, metodologías de ensayo exhaustivas, etc.certification.
    • FITCEM define una evaluación con tiempo y alcance acotado, priorizando practicidad y coste frente a exhaustividad máxima.
  • Posición en el ecosistema
    • EUCC es, en la práctica, el “pilar CC” del sistema europeo de certificación junto a otros esquemas como EUCS (cloud) o futuros esquemas 5G.itif+3
    • FITCEM actúa como estándar horizontal de referencia para esquemas “ligeros” en distintos países y sectores, facilitando convergencia y compatibilidad.
  • Casos de uso típicos
    • EUCC encaja mejor en productos con alto impacto en seguridad y ciclos de desarrollo más largos (equipamiento de red, módulos criptográficos, dispositivos industriales).
    • FITCEM se orienta a productos de rotación rápida y a necesidades de certificación ágiles, donde el mercado no soporta ni tiempo ni coste de una evaluación CC completa.

Estimación de costes

  • Para CC/EUCC de niveles medios (equivalentes a EAL2–EAL4), fuentes especializadas sitúan los costes de laboratorio típicos en un rango aproximado de 80 000–300 000 USD/EUR, pudiendo subir a 300 000–750 000 USD/EUR en EAL4 alto o productos muy complejos.
  • En FITCEM se estiman costes de laboratorio del orden de 10 000–50 000 EUR para este tipo de evaluaciones “light”, dependiendo del alcance, tipo de producto y posicionamiento del laboratorio

Los costes internos y de consultoría son del mismo orden de magnitud que los del laboratorio.

Tipos de productos certificados

EUCC puede aplicarse a cualquier producto TIC con un conjunto significativo de funciones de seguridad, pero en la práctica se concentra en familias muy concretas.

  • Circuitos integrados y tarjetas inteligentes: chips de seguridad, smart cards, tarjetas de pago, SIM/UICC, módulos seguros embebidos, etc.
  • Módulos y dispositivos criptográficos: HSM, módulos criptográficos hardware, TPM, QSCD y otros dispositivos de firma/digital ID de alta garantía.
  • Equipos de red y comunicaciones: routers, switches, firewalls, VPN gateways, puntos de acceso y otros componentes de infraestructura crítica.
  • Sistemas y plataformas especializadas: servidores seguros, appliances de seguridad, componentes de infraestructuras industriales o públicas donde se requiere alto nivel de aseguramiento.

En general, son productos B2B con alto impacto en seguridad, ciclos de vida largos y para los que un proceso de certificación de meses y costes de seis cifras puede amortizarse comercialmente.

FITCEM, como metodología de tiempo fijo, está pensada para apoyar esquemas como CSPN, LINCE, BSZ, BSPA, etc., que históricamente se han orientado a productos con necesidad de evaluación ágil.

  • Productos IoT y dispositivos conectados: sensores, actuadores, gateways IoT, cámaras IP, pequeños appliances, donde el time‑to‑market es crítico.
  • Software y appliances de seguridad de complejidad media: soluciones de red, productos de seguridad endpoint o de infraestructura donde se busca una “foto” de robustez razonable, pero sin el coste de CC/EUCC.
  • Productos TIC de fabricantes que dan sus primeros pasos en certificación: se usan esquemas tipo FITCEM como vía de entrada o como complemento a otros esquemas regulatorios.
  • Verticales específicos con esquemas acelerados: por ejemplo, infraestructuras industriales o sectoriales que adoptan metodologías fixed‑time para certificar ciertos componentes o gateways a niveles basic/substantial.

Nuevos borradores de actos de ejecución en relación con #EIDAS2 y la EUDI Wallet

1 respuesta

La implantación práctica de la Identidad Digital Europea y, en particular, de las Carteras IDUE, depende menos del texto del Reglamento (UE) 2024/1183 y mucho más del contenido de sus actos de ejecución.

​En estas semanas coinciden tres nuevos proyectos de reglamento de ejecución aún abiertos a comentarios en el portal “Have your say”, todos ellos estrechamente ligados al marco de confianza y a la interoperabilidad técnica de las carteras EUDI.

Oleadas de actos de ejecución

El primer paquete de actos de ejecución de 2024 se centró en la definición básica de la cartera, sus funcionalidades núcleo, los protocolos e interfaces y el esquema de certificación de las EUDI Wallet.

En abril y junio de 2025 la Comisión amplió el desarrollo reglamentario con nuevos actos de ejecución, orientados sobre todo a servicios de confianza (firma, sello, conservación, entrega electrónica certificada, etc.) y a la supervisión del ecosistema.

La lista completa de los 30 actos de ejecución de EIDAS2 ya publicados en el Diario Oficial la presenté hace unos días.

A pesar de ese despliegue normativo, el marco sigue siendo incompleto: es necesario ajustar referencias a normas técnicas, detallar procedimientos y cubrir ámbitos que el propio Reglamento remite expresamente a actos de ejecución adicionales (listas de estándares, métodos de verificación, actualización de requisitos para servicios de confianza, etc.). Incluso, a veces, se publican actos de ejecución para modificar otros actos de ejecución

Nuevo borrador: Modificación el Acto de Ejecución 2025/848

La Modificación de Reglamento de Ejecución 2025/848 que trata sobre el Registro de las Partes usuarias (informadas) de Carteras,

​Draft implementing regulation – Ares(2026)1286341Descarga

Annex – Ares(2026)1286341Descarga

Posibilidad de enviar comentarios hasta el 5 de marzo de 2026.

Otro nuevo borrador: Modificación de 4 actos de implementación de 2024: 2979, 2982, 2977 y 2980

Esta iniciativa modifica los Reglamentos de Ejecución (UE) de 2024: 2977, 2979, 2980 y 2982, de la Comisión, actualizando las referencias a las normas y especificaciones técnicas para garantizar que los Estados miembros puedan desarrollar y proporcionar carteras de identidad digital europeas de manera interoperable.

Son Reglamentos de Ejecución del primer lote:

Draft implementing regulation – Ares(2026)1286304Descarga

Annex – Ares(2026)1286304Descarga

Son cambios importantes que afectan a la estructura del PID de la Cartera y otros elementos.

Teniendo en cuenta la disparidad de números de identificación de los ciudadanos en Europa y el hecho de que varias especificaciones quede 2abiertas» dificultará seguramente la interoperabilidad transfronteriza.

Posibilidad de enviar comentarios hasta el 5 de marzo de 2026.​

Tercer nuevo borrador: Modificación del Acto de Ejecución 2025/1569

Esta iniciativa modifica el Reglamento de Ejecución (UE) n.º 2025/1569 de la Comisión mediante la actualización de las normas y especificaciones técnicas necesarias para emitir declaraciones electrónicas cualificadas de atributos y declaraciones electrónicas de atributos proporcionadas por un organismo del sector público responsable de una fuente auténtica o en su nombre.

Draft implementing regulation – Ares(2026)1286389Descarga

Annex – Ares(2026)1286389Descarga

Posibilidad de enviar comentarios hasta el 5 de marzo de 2026.

Son normas que llegan un poco tarde dado el estado de desarrollo de las Carteras IDUE y la presión que significa que tienen que estar disponibles en los estados miembros en las navidades del 2026, pero por otro lado, intentan resolver problemas detectados (lo que no es óbice para que puedan crear otros problemas nuevos).

A principios de diciembre de 2025 se publicó otro borrador de-acto de-ejecución relativo al registro del usuario de la Cartera IDUE

Este borrador establece una lista de estándares de referencia para el «onboarding» remoto de usuarios, enfocándose en procedimientos seguros de prueba de identidad remota (remote identity proofing), requisitos para evaluación de riesgos, recolección de evidencias, continuidad operativa, verificación de identidad y adaptaciones a normas como ETSI TS 119 461 V2.1.1, ETSI EN 319 401, entre otras. Incluye evaluaciones por laboratorios acreditados para cumplir con los niveles de aseguramiento requeridos.

Enlace directo a la iniciativa en «Have your say»: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/15572-European-Digital-Identity-Wallets-user-onboarding_en

Próximos eventos «Trust Services and eID Forum» y «CA-day» en Split, Croacia el 24 y 25 de septiembre de 2025

Deja un comentario

El 24 de septiembre de 2025, ENISA organiza el 11º Foro sobre Servicios de Confianza y Identificación Electrónica (11th Trust Services and eID Forum). El 25 de septiembre de 2025, D-TRUST, en colaboración con TÜV Nord Cert, celebrará la 17ª Jornada de CAs (17th CA-Day).

¿A quién va dirigido?

El foro, organizado en colaboración con la Comisión Europea desde 2015, se ha convertido en «la cita ineludible» para las partes interesadas del amplio ámbito del Reglamento eIDAS. Reúne a responsables políticos, prestadores de servicios de confianza, organismos de evaluación de la conformidad, supervisores, instituciones europeas y de los Estados miembros y usuarios finales interesados, ofreciendo un lugar único para los debates relacionados con las identidades digitales en Europa. Este año, el evento se traslada a Split, Croacia, y se garantiza también la retransmisión en línea para la participación virtual.

Contenido

Entre los temas que se debatirán este año, abordaremos los siguientes

  • Normalización y certificación de la Cartera de Identidad Digital Europea
  • Interacción de eIDASv2 con otra legislación (CRA, Ley de Chips de la UE, NISD2), incluidos los aspectos relacionados con la privacidad
  • Aplicación de los servicios de confianza nuevos y previamente definidos, desde el punto de vista técnico y organizativo
  • Nuevas necesidades de colaboración entre todos los servicios de confianza y las partes interesadas en la identificación electrónica
  • Estrategias para promover el mercado de la identidad digital

Como en años anteriores (desde 2018), el Trust Services and eID Forum irá seguido del CA-Day, organizado por D-Trust y TÜV Nord Cert, que tendrá lugar el 25 de septiembre en el mismo lugar.

Agenda en inglés

El borrador del programa ya está disponible. Contiene interesantes presentaciones y cautivadores debates entre expertos reconocidos en la materia. Tenga en cuenta que se seguirá actualizando en las próximas semanas. Ver la traducción más abajo

Inscripción

Ya puede reservar su plaza inscribiéndose aquí. Reserve su plaza presencial solo si está seguro de que podrá asistir al evento en persona. Tenga en cuenta que no es posible acoger presencialmente a más de 2-3 participantes de la misma organización.

Agenda en español

11th TSF – 17th CA Day – Agenda 20250804-ESDescarga

EADTrust, la entidad líder en Digital Transaction Management (DTM)

Deja un comentario

El concepto Digital Transaction Management (DTM), Gestión de Transacciones Digitales engloba un conjunto de servicios y tecnologías basados en la nube diseñados para gestionar digitalmente transacciones basadas en documentos. El objetivo principal de la Gestión de Transacciones Digitales es eliminar la fricción inherente a las transacciones que involucran personas, documentos y datos, creando procesos más rápidos, fáciles, convenientes y seguros.

Los componentes clave de un sistema DTM incluyen:

  1. Firmas electrónicas: Permiten la vinculación de documentos a sus firmantes, su autenticación segura y la atribución legalmente vinculante de documentos firmados.
  2. Gestión de documentos y transacciones: Incluye almacenamiento digital, asociado al concepto de custodia, organización y recuperación eficiente de documentos y operaciones.
  3. Automatización de flujos de trabajo: Reduciendo tareas manuales y mejorando la consistencia de los procesos.
  4. Protocolos de seguridad: Implementando el cifrado donde se precisa (teniendo en ciuenta los riesgos que anuncia la computación cuántica) y controles de acceso para proteger información sensible.
  5. Autenticación digital: Verificando la identidad de los participantes en las transacciones.
  6. Gestión de evidencias digitales para favorecer la fuerza probatoria en contextos de resolución de controversias.
  7. Gestión de entornos híbridos de documentos digitales y en papel, con gestión de la digitalización cualificada de documentos en papel con fuerza probatoria y documentos nacidos digitales que se pueden usar impresos por la posibilidad de cotejo de su CSV (Código Seguro de Verificación) en su sede electrónica de referencia.

Los servicios de EADTrust encajan perfectamente en el concepto de Digital Transaction Management, ya que ofrecen varias soluciones clave que son fundamentales para la gestión digital de transacciones:

  1. Firmas electrónicas cualificadas: EADTrust emite certificados cualificados para personas físicas y entidades legales, que permiten la creación de firmas y sellos electrónicos avanzados y cualificados. También ofrece servicios de comprobación de las firmas electrónicas que se reciben en las entidades.
  2. Sellos de tiempo cualificados: Estos sellos permiten probar el momento exacto en que ocurrió un evento digital, dejando un registro irrefutable de la fecha, hora y contenido del evento mediante criptografía. Se asocia un sello de teiempo con cada transacción.
  3. Custodia digital: EADTrust ha desarrollado una tecnología que permite a los usuarios almacenar documentos digitalmente, pudiendo probar su autenticidad a través de CSV y su inalterabilidad mediante métodos criptográficos avanzados. En línea con la normativa de eArchivos de EIDAS2
  4. Notificaciones certificadas (Noticeman): Ofreciendo una plataforma de gestión de correo electrónico y SMS certificados que permite registrar la identidad del remitente, el receptor, el contenido y el momento exacto en que se realizaron las comunicaciones.
  5. Servicios corporativos: Proporcionan testimonios de publicación de documentos a las entidades obligadas para convocatorias de juntas generales de accionistas, foros y gestión de voto electrónico, cumpliendo con la Ley de Sociedades de Capital.
  6. Custodia de claves privadas: Celebran ceremonias de creación de claves, generando pares de claves asimétricas y manteniendo la clave privada para garantizar la integridad. Estos servicios son esenciales en la gestión de firmas manuscritas capturadas en tabletas digitalizadoras

Estos servicios de EADTrust abordan aspectos críticos de DTM, como la autenticación, la seguridad, la gestión de documentos y el cumplimiento normativo. Al ofrecer estas soluciones, EADTrust contribuye significativamente a la transformación digital de las empresas, permitiéndoles gestionar sus transacciones de manera más eficiente, segura y conforme a la normativa vigente.

En relación con las Carteras IDUE ayuda a adaptarse a las entidades obligadas por mandato del Reglamento EIDAS2 en el articulo 5 septies: 

Cuando el Derecho de la Unión o nacional exija que las partes usuarias privadas que prestan servicios —con la excepción de las microempresas y pequeñas empresas según se definen en el artículo 2 del anexo de la Recomendación 2003/361/CE de la Comisión ( 5 )— utilicen una autenticación reforzada de usuario para la identificación en línea, o cuando se requiera una autenticación reforzada de usuario para la identificación en línea en virtud de una obligación contractual, en particular en los ámbitos del transporte, la energía, la banca, los servicios financieros, la seguridad social, la sanidad, el agua potable, los servicios postales, la infraestructura digital, la educación o las telecomunicaciones, dichas partes usuarias privadas también aceptarán, a más tardar treinta y seis meses a partir de la fecha de entrada en vigor de los actos de ejecución a que se refieren el artículo 5 bis, apartado 23, y el artículo 5 quater, apartado 6, y únicamente a petición voluntaria del usuario, las carteras europeas de identidad digital proporcionadas de conformidad con el presente Reglamento.

Thales anuncia la certificación EIDAS para firma remota de sus HSM

Deja un comentario

El Módulo de Seguridad de Hardware (Hardware Security Module, HSM) de Thales denominado Luna v.7.7.0 ya está certificado de acuerdo con los Criterios Comunes (Common Criteria, CC) en el nivel EAL4+ contra el Perfil de Protección (PP) EN 419 221-5 de los Servicios de Identificación, Autenticación y Confianza electrónicos (eIDAS). Además de la certificación CC, Luna HSM 7 también ha recibido la certificación eIDAS como dispositivo cualificado de creación de firmas y sellos (Qualified Signature/Seal Creation Device QSCD).

Los HSM Luna (de las generaciones 6 y 7, anteriormente englobados bajo la marca Safenet) ya habían conseguido certificaciones como QSCD independiente, o como parte de un QSCD de firma remota formado por módulos creados por entidades terceras que los incluían en su configuración. Han certificado su validez entidades de evaluación de conformidad de Austria, Italia y España, según lo previsto en el artículo 30.3.b (Procesos alternativos) del Reglamento EIDAS.

Los prestadores de servicios de confianza cualificados (Qualified Trust Service Providers, QTSP), así como las empresas públicas o privadas que emiten certificados digitales y proporcionan firmas y sellos digitales sobre servidores propios o remotos (avanzados y cualificados), sello de tiempo, entrega electrónica y servicios de autenticación de sitios web, pueden utilizar ahora los HSM Luna 7 como parte de su solución alineada con eIDAS.

Esta certificación CC EAL4+ de la familia de HSMs Luna es la quinta en cuatro generaciones de productos (Luna CA3, Luna 4, Luna 5/6 y ahora Luna 7).

Esta última versión de HSM Luna incluye funciones útiles para operaciones eIDAS de gran volumen, que requieran alto rendimiento, y funcionalidades como la autorización por clave (per-key authorization, PKA) y el almacenamiento escalable de claves (scalable key storage, SKS), funciones utilizadas por los sistemas que gestionan firmas remotas en nombre del titular del certificado.

Los Prestadores de Servicios de Confianza (Trust Service Providers – TSP) que adopten estos HSM de Thales pueden certificar sus soluciones de firma remota conPerfil de Protección Common Criteria EN 419 241-2 (perfil de protección para QSCD diseñado para la modalidad de firma electrónica en servidor), o en el caso de una certificación eIDAS existente (en base al artículo 30.3.b, procesos alternativos), ampliar su lista de certificaciones con esta nueva certificación Common Criteria.

La certificación en base al Perfil de Protección Common Criteria EN 419 221-5 “Cryptographic Modules for Trust Services” (Módulos criptográficos para servicios de confianza) puede utilizarse como certificación independiente o como base para una certificación CC de mayor alcance según el Perfil de Protección EN 419 241-2 para servicios de firma y sellado electrónico remotos. La norma EN 419 241-2 exige el empleo de un módulo criptográfico, como un HSM, destinado a ser utilizado por los TSP en apoyo de las operaciones de firma electrónica y sellado electrónico, que esté certificado conforme a la norma EN 419 221-5.

Además, los artículos 30 y 31 del reglamento eIDAS dictan que «La conformidad de los dispositivos cualificados de creación de firmas electrónicas con los requisitos [de la UE] […] será certificada por los organismos públicos o privados adecuados designados por los Estados miembros». Luna HSM 7 está publicado en la lista del artículo 31 de eIDAS, promoviendo su uso como QSCD certificado.

El uso de un equipamiento de HSM basado en la nube o en las instalaciones de la entidad que lo adopta es una forma excelente de cumplir con el eIDAS y tiene muchas ventajas, pero se exige que el HSM esté certificado como dispositivo QSCD.

En los entornos de trabajo remotos existe la necesidad de acceder a las claves de firma digital en cualquier momento y lugar. Los HSM se utilizan para gestionar y proteger las claves de firma privadas de sus titulares, sin que el firmante deba preocuparse por su custodia (como ocurre cuando se utilizan tarjetas inteligentes). Sus claves se mantienen en el perímetro del Prestador de Servicios de Confianza (protegidas por el HSM) y con sujeción a la evaluación periódica del prestador.

HSMs Luna

Además de los requisitos a los HSM impuestos por el Reglamento eIDAS mencionados anteriormente, que requieren su evaluación de conformidad, los HSM de red y de tarjeta PCIe de Luna proporcionan altos rendimientos, protección de claves de alto nivel de aseguramiento y la administración y supervisión centralizada de las operaciones de criptografía necesarias para gestionar firmas electrónicas, sellos electrónicos y otros servicios de confianza y resultan necesarios para proporcionar servicios eIDAS.

Noticia comunicada por Thales (artículo de Hermann Bauer) .

Criptografía en Mainframe IBM EC12 y firma electrónica

Deja un comentario

El nuevo mainframe de IBM zEnterprise EC12 aumenta los niveles de rendimiento y capacidad de los sistemas anteriores y da soporet a la consolidación de servidores permitiendo gran escalabilidad.

Aporta una nueva generación de hardware de seguridad para la firma digital, con soporte para criptografía de curvas elípticas y cuenta con capacidad de análisis avanzado de reconocimiento de patrones para el control inteligente de la salud del propio sistema, lo que permite predicir y evitar fallos. Ahora hay una nueva opción para instalarlo en suelo no técnico y permite configuraciones híbridas para cargas de trabajo distribuidas orientadas a AIX, Linux y Windows, demás de las tradiciones de mainframe, basadas en sistemas operativos OS/2 y zLinux.

El nuevo servidor zEC12 con el chip más rápido del mercado procesando a 5,5 GHz ofrece hasta un 25% más de rendimiento por core y un 50% más de capacidad que su predecesor.

Es el sistema con mayor seguridad y resiliencia para entornos corporativos de misión crítica: Con la criptografía de firma digital Crypto Express 4S y la certificación Common Criteria  EAL 5+

El zEC12 admite requisitos de plataforma heterogéneos con el nuevo IBM zEnterprise BladeCenter Extension (zBX) modelo 003 e IBM zEnterprise Unified Resource Manager para ampliar las capacidades de gestión a otros sistemas y cargas de trabajo que se ejecutan en servidores AIX en POWER7, Linux® en IBM System x y Microsoft® Windows® en IBM System x.

Ahora la nueva versión de zBackTrust 1.3 permite decidir sobre qué tipo de procesador y de sistema operativo se desea ejecutar la funcionalidad de firma electrónica, ya que cuenta con versiones para:

  • z/OS: java sobre  z/OS V1.12, V1.13 o superior; z/OS V1.11, V1.10 extensión de ciclo de vida
  • Linux en Systemz: java sobre RedHat Enterprise Linux (RHEL) 6y RHEL 5, SUSE Enterprise Server (SLES) 11 y SLES 10
  • Windows Server 2008 (c# y .net) (en servidores blade IBM BladeCenter HX5 instalados en ZBX Mod 003)
  • Linux en System x: java sobre Red Hat RHEL 5.5, 5.6, 5.7, 6.0, 6.1 y SUSE Linux Enterprise Server (SLES) 10 (SP4), SLES 11 SP1 (sólo de 64 bits)  (en el servidor blade IBM BladeCenter HX5 instalado en zBX Mod 003)

El modo de licenciamiento de zBackTrust permite un número ilimitado de instancias por site, y solo incrementa el coste por número de sistemas operativos soportados o por número de sites. El incremento de costes para sites de backup no activos es de solo un 10% del coste de licencia general. De este modo la escalabilidad está garantizada, sin coste adicional.

A través de CPACF (Central Processor Assist for Cryptographic Function) función que no implica coste al habilitarla en el sistema, puede gestionar los siguientes algoritmos criptográficos:

  • Algoritmos de hash (Secure hash algorithms) SHA-1, SHA-224, SHA-256, SHA-384, y SHA-512 habilitado en todos los servidores con unidades de proceso  (PUs – processor units) definidas como  CPs, IFLs, zIIPs, or zAAPs.
  • Cifrado Simétrico
    • Data Encryption Standard (DES)
    • Triple Data Encryption Standard (TDES)
    • Advanced Encryption Standard (AES) con claves de 128-bits, 192-bits, y 256-bits
  • Control de Integridad (Secure Hash Algorithms)
    • SHA-1: 160 bit
    • SHA-2: 224, 256, 384, and 512 bit
  • Control de Integridad (MAC)
    • Single-length key MAC
    • Double-length key MAC

El soporte  IBM Enterprise PKCS #11 (EP11) IBM Enterprise Public-Key Cryptography Standards (PKCS) #11 está basado en la especificatión v2.20 de PKCS #11 y se incluye enlos sistemas operativos  z/OS y z/VM medianteICSF (Integrated Cryptographic Service Facility).

El soporte criptográfico es de especial interés en banca, ya que permite, por ejemplo gestionar las funciones de seguridad de las tarjetas EMV, o cifrar la información relevante sobre tarjetas y titulares que exige el cumplimiento de la normativa PCI DSS. En entornos de banca y seguros, permite la firma de transacciones y la securización de documentos electrónicos, permitiendo la eliminación de documentos en papel.

Entre las funcionalidade de zBacktrust cabe citar:

  • Firma Electrónica de alto rendimiento.
  • Compatible con HSM IBM 4764 (Crypto Express2), IBM 4765 (Crypto Express3) y Crypto Express 4S
  • Compatible con gestión de claves y certificados X.509 a través de interfaces PCCS#12 y PKCS#11.
  • Generación de firmas XAdES (XML) y PAdES (PDF).
  • Conversión de firmas simples en completas.
  • Validación de firmas electrónicas
  • Gestión de evidencias electrónicas
  • Cumplimiento de estándares: ETSI (TS 101 903,  TS 102 778), ISO-32001, ISO 14533-2:2012 y OASIS DSS 
  • Compatiblidad con Middleware: WebSphere , Weblogic y Tomcat.
  • Accesible desde equipos con Linux, Windows, MacOS, Blackberry, Android, iOS, Windows Phone.
  • Integración con prestadores de servicios de timestamping y OCSP externos

Contactar con el +34 917160555 para obtener más información de zBacktrust

Firma electrónica con el DNI electrónico en BlackBerry

Deja un comentario

El Mobile World Congress (MWC) acaba de cerrar sus puertas, tras cuatro días en los que Barcelona se convirtió en la capital del mundo de la movilidad. Según cifras de la organización, 67.000 visitantes de 205 países visitaron el evento.

Albalia ha estado presente, anunciando su solución de firma electrónica en dispositivos BlackBerry, mediante el DNI electrónico gracias al dispositivo SCR (Smart Card Reader) de RIM.

La aplicación de firma electrónica genera firmas XAdES-XL (y otras variantes de la norma TS 101 903) y en el caso del ejemplo que se muestra en el siguiente video, permite firmas de facturas electrónicas codificadas en formato facturae.

.

.

Pido disculpas por la calidad del vídeo, ya que ha sido una grabación improvisada. Próximamente prepararemos uno mejor

El desarrollo se ha realizado con total fidelidad a los criterios definidos en los perfiles del protección  (los requisitos que especifican una solución de seguridad, en este caso de creación y verificación de firma electrónica) del DNI electrónico en el marco de la certificación Common Criteria.

El desarrollo acometido es uno más entre la serie de dispositivos para los que ha desarrollado drivers de DNIe Albalia Interactiva. De esta forma Albalia Interactiva se consolida como la entidad que ha logrado implementar drivers de DNIe y sistemas de firmas en más plataformas: Móviles con Windows CE, Kioskos de Autoservicio, Cajeros Automáticos, Set Top Boxes de TDT interactiva, Smartphones con BlackBerry OS, entornos Linux con Tomcat y Websphere, entornos .net, entornos VSTO (extensiones de Office),  entornos Mainframe (zLinux y z/OS).

Otros artículos relacionados:

Certificado Common Criteria para BlackBerry, por su OS 7.0

Deja un comentario

La última versión del OS BlackBerry, la 7.0, ha recibido la evaluación Evaluation Asurance Level 4+ del estándar internacional Common Criteria. El EAL 4+ es uno de los niveles más altos de acreditación bajo el Common Criteria Recognition Arrangement (CCRA). El EAL 4+ examina el diseño, la metodología de desarrollo de software y los mecanismos de seguridad de un producto.

“La seguridad es una de las consideraciones más importantes para los clientes de empresa y nos enorgullece saber que BlackBerry 7 OS ha conseguido esta rigurosa certificación”, afirma Scott Totzke, Senior Vice President, BlackBerry Security en RIM. “RIM es reconocido como un líder del mercado a la hora de proporcionar soluciones móviles seguras y este logro ayuda a ofrecer a nuestros clientes a nivel global la confianza continua al utilizar las soluciones BlackBerry a través de sus organizaciones”.

La certificación EAL4+ para los smartphones BlackBerry® Bold™ 9900, BlackBerry® Torch™ 9810, BlackBerry® Torch™ 9860 y BlackBerry® Curve™ 9360 basados en BlackBerry 7 OS se ha publicado en el Common Criteria Portal (http://www.commoncriteriaportal.org/products). La certificación EAL4+ para otros smartphones con BlackBerry 7 OS, entre ellos los smartphones BlackBerry Bold 9930, BlackBerry Torch 9850, BlackBerry Curve 9350, BlackBerry Curve 9370 y el Smartphone Porsche Design P’9981 de BlackBerry se espera para principios del año 2012.

Para saber más sobre las certificaciones de seguridad de BlackBerry, consulte www.blackberry.com/go/security.