Archivo de la categoría: QWAC

Robustez de las claves asimétricas recomendadas por el CCN


Recientemente, el Organismo Supervisor de Prestadores Cualificados de Confianza eIDAS en España ha comunicado a los prestadores de servicios de confianza la recomendación de abandonar el uso de claves RSA de hasta 2048 bits, indicando que la fuente de la recomendación es el CCN (Centro Criptógico Nacional) a través del documento CCN-STIC 221 – Guía de Mecanismos Criptográficos autorizados por el CCN.

Sin embargo, ese documento no entra en detalles de tamaños de clave recomendados aunque indica en su página 104

Los resultados del ataque ROCA obligó a varios gobiernos europeos a revocar todos
los certificados digitales de millones de tarjetas de identificación de sus ciudadanos,
ya que tenían claves de 1024 bits y se podía suplantar la identidad de sus ciudadanos. En España se optó por la misma medida de prevención, aunque los DNIe españoles no corrían el mismo peligro que los documentos de identidad utilizados en otros países, ya que el DNIe español utiliza claves de 2048 bits.

dando a entender que un tamaño de 2048 bits en RSA es apropiado.

En realidad, las claves de los dispositivos cualificados de casi todos los países (no solo España) eran en aquel momento de 2048 bits, pero la vulnerabilidad ROCA afectaba al algoritmo de generación de claves adoptado por Infineon (que lo limitó al uso de la variante «Fast Prime») con lo que hubiera sido sencillo sustituir las claves generadas por aquellos chips con generadores externos al propio chip.

En muchos lugares (incluida España) se optó por generar claves RSA de 1952-bits en el propio chip. A tal efecto se modificó el software de los «cajeros automáticos del DNI» para actualizar los certificados (y su clave privada asociada) cuando acudieran los ciudadanos a la renovación de certificados. Para siguientes emisiones de DNIe se usaron dispositivos diferentes.

El documento del CCN que entra en más detalles sobre la criptografía es el CCN-STIC 807 – Criptología de empleo en el Esquema Nacional de Seguridad, y la versión más reciente es de mayo de 2022.

En su apartado 3 se indica:

Los mecanismos criptográficos autorizados indicados en los siguientes apartados se han clasificado en dos (2) categorías (CAT) de acuerdo con su fortaleza estimada a corto y largo plazo:

a) Recomendados (R): mecanismos que ofrecen un nivel adecuado de seguridad a largo plazo. Se considera que representan el estado del arte actual en seguridad criptográfica y que, a día de hoy, no presentan ningún riesgo de seguridad significativo. Se pueden utilizar de forma segura a largo plazo, incluso teniendo en cuenta el aumento en potencia de computación esperado en un futuro próximo. Cualquier riesgo residual, solo podrá proceder del desarrollo de ataques muy innovadores.

b) Heredado o Legacy (L): mecanismos con una implementación muy extendida a día de hoy, pero que ofrecen un nivel de seguridad aceptable solo a corto plazo. Únicamente deben utilizarse en escenarios en los que la amenaza sea baja/media y el nivel de seguridad requerido por el sistema bajo/medio (como veremos en el apartado 5) y deben ser reemplazados tan pronto como sea posible, ya que se consideran obsoletos respecto al estado del arte actual en seguridad criptográfica, y su garantía de seguridad es limitada respecto a la que ofrecen los mecanismos recomendados. Como consecuencia de ello, para estos mecanismos se define el periodo de validez hasta 2025 (31 de diciembre), salvo indicación expresa de otro periodo.

En la Tabla 3-2. Tamaño de las primitivas RSA acordadas se considera (L)egacy la criptografía RSA de hasta 2024 bits.

En la Tabla 3-4. Curvas elípticas acordadas se consideran (R)ecomendada la criptografía ECC de todos los tamaños habituales entre los que se encuentran NIST P-256 o secp256r11 y NIST P-384 o secp384r1

En la Tabla 3-8. Esquemas de Firma electrónica autorizados se consideran L los tamaños de clave RSA hasta 2024 y R los tamaños de clave RSA de más de 3072 bits. Y en las variantes ECC las de tamaños a partir de 256 bits.

En la página 50 se entra en detalle sobre la firma electrónica [MP.INFO.3] tal como se encuentra definida en el Reglamento eIDAS y según la forma en la que se debe aplicar en las Administraciones Públicas en el contexto del Esquema Nacional de Seguridad.

Para los niveles bajo y medio del ENS se admiten claves RSA (del firmante) de, al menos, 2048 bits, claves de 224-255 bits si se emplean curvas elípticas y Funciones hash SHA-256 o superior.

Sin embargo, tal como se ha visto esa posibilidad entra en la consideración de «Legacy» y se tiene que dejar de usar desde el 1 de enero de 2026.

Para el nivel alto del ENS se requiere una fortaleza mínima de 128 bits, que, según se ve en las tablas indicadas anteriormente debe ser en RSA de al menos, 3072 bits, y de más de 256 bits si se emplean curvas elípticas . Se entra en detalle en la Tabla 3-8.

En cuanto a los Sellos de Tiempo [MP.INFO.4] se consideran los requisitos para el ENS alto:

  • Se utilizarán productos certificados conforme a lo establecido en el ENS ([op.pl.5] Componentes Certificados).
  • Se emplearán «sellos cualificados de tiempo electrónicos» atendiendo a lo establecido en el Reglamento eIDAS.
  • Se utilizarán mecanismos de firma electrónica recomendados y fortaleza mínima 128 bits, es decir:
     # RSA de, al menos, 3072 bits (aunque se recomienda el uso de 4096 bits).
     # Curvas elípticas con claves de, al menos, 256 bits.
     # Funciones resumen de las incluidas en la serie SHA-2 o SHA-3 con una seguridad mayor o igual que SHA-256. – Para los esquemas enlazados, la seguridad recae en la función resumen empleada, por tanto, se empleará cualquiera de las funciones de la serie SHA-2 o SHA-3 con una seguridad mayor o igual que SHA-256.

Todos estos requisitos son muy difíciles de afrontar si se empiezan a considerar en el año 2025, pero EADTrust ya los tuvo en cuenta en la definición de sus jerarquías de certificación desde su creación.

Jerarquias de certificación de EADTrust.

Las jerarquías de certificación de EADTrust ya cumplen los requisitos establecidos por el CCN desde que se diseñaron y se llevó a cabo la ceremonia de generación de claves de CA en 2019, sin esperar a la fecha límite de diciembre de 2025. Se estructuran en tres niveles (Root CA, Sub-CA e Issuing CA) y combinan tecnologías RSA y ECC, posicionando a EADTrust como pionera en Europa por su uso dual. Esta estructura soporta la emisión de certificados cualificados para firma electrónica, sellos electrónicos y autenticación de sitios web, cumpliendo con los estándares de ETSI y CEN para eIDAS y garantizando alta seguridad y confianza en transacciones electrónicas. La adopción de ECC refuerza su preparación para desafíos criptográficos futuros y ha sido clave para su designación como la entidad emisora de los certificados utilizados por los organismos sanitarios españoles para emitir el pasaporte COVID-19 durante la pandemia.

Las variantes de certificados ofrecidos por EADTrust son las siguientes:

  • Autenticación y firma electrónica de personas físicas,
  • Autenticación y firma electrónica de personas físicas, con indicación de entidad en la que trabajan,
  • Autenticación y firma electrónica de representantes legales de personas jurídicas,
  • Autenticación y firma electrónica de empleados públicos,
  • Autenticación y firma electrónica de empleados públicos, en el contexto de la Administración de Justicia
  • Autenticación y sello electrónico de personas jurídicas,
  • Autenticación y sello electrónico de órganos de la administración pública,
  • Autenticación y sello electrónico de personas jurídicas sujetas a la normativa PSD2,
  • La creación de sellos de tiempo electrónicos cualificados,
  • La comprobación y validación de firmas electrónicas, sellos electrónicos, y de sellos de tiempo electrónicos,
  • La conservación de firmas electrónicas, sellos o certificados para estos servicios

Se contemplan algoritmos criptográficos de tipo RSA con tamaños de clave de 2048 bits, 4196 bits y 8192 bits y algoritmos criptográficos de tipo ECC (Criptografía de Curva Elíptica) con tamaños de clave de 256 bits y 384 bits.

Los diferentes niveles de robustez de criptografía permiten el cumplimiento de los niveles medios y altos del ENS (Esquema Nacional de Seguridad) de España, tal como se describen en el documento “Guía de Seguridad de las TIC – CCN-STIC 807 – Criptología de empleo en el Esquema Nacional de Seguridad” citado, según las necesidades de las Administraciones Públicas.

Los tamaños de clave para los certificados cualificados (a partir de los certificados de Autoridad de Certificación raíz) son:

  • RSA Root CA 2048-bit key size with SHA256 digest algorithm para certificados cualificados.
  • RSA Root CA 4096-bit key size with SHA256 digest algorithm para certificados cualificados.
  • RSA Root CA 8192-bit key size with SHA512 digest algorithm para certificados cualificados.
  • ECC Root CA P-256 with SHA256 digest algorithm para certificados cualificados.
  • ECC Root CA P-384 with SHA384 digest algorithm para certificados cualificados.
    Para certificados no cualificados
  • RSA Root CA 2048-bit key size with SHA256 digest algorithm para certificados no cualificados.

En la siguiente figura se muestra la jerarquía RSA de 4096 bits que es similar a la de 8192 bits.

En la siguiente figura se muestra la jerarquía ECC de 384 bits que es similar a la de 256 bits.

Desde principios de 2023 EADTrust ha difundido además los nuevos certificados para la provisión de servicios de sello de tiempo cualificado diferenciados por usar diferentes algoritmos criptográficos, tamaño de clave y uso o no de Dispositivo Cualificado de Creación de Sello o de Firma (DCCF, DCCS o QSCD) Algunos están especialmente diseñados para cumplir requisitos establecidos en el Esquema nacional de Seguridad (ENS) para el Nivel de Seguridad Alto.

Los campos “CommonName” de los nuevos certificados son:

CertificadoCriptografíaTamaño ClaveQCSDENS
EADT QTSU 2023 RSA 2048RSA2048NONO
EADT QTSU 2023 ENS alto RSA 3072RSA3072NOSI
EADT QTSU QSCD 2023 ENS alto RSA 4096RSA4096SISI
EADT QTSU 2023 ENS alto ECC 256ECC256NOSI
EADT QTSU QSCD 2023 ENS alto ECC 384ECC384SISI

Por compatibilidad se mantienen los sellos de tiempo basados en criptografía RSA de 2048 bits, destinados a entidades no sujetas al cumplimiento del la normativa ENS del Esquema nacional de Seguridad.

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


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

Tercer lote de actos de ejecución relativos a los servicios electrónicos de confianza y a la Cartera de Identidad Digital Europea


La Unión Europea publicó el 15 de abril de 2025 los borradores de doce nuevos actos de ejecución centrados en los servicios electrónicos de confianza y la cartera de identidad digital europea, en lo que será el tercer bloque de actos de ejecución tras los dos anteriores, cumpliendo lo previsto en el Reglamento (UE) 1183/2024.

La publicación de estos borradores abre también la posibilidad de enviar comentarios hasta el 13 de mayo de 2025 a través de la plataforma  «Have your say» .

El conjunto de actos de ejecución configura el Marco Europeo de Identidad Digital y forma parte del juego de requisitos y especificaciones que determinan la evolución del documento de ARF («Architecture and Reference Framework», Arquitectura y Marco de Referencia) de la Cartera de Identidad DIgital. Recientemente publiqué la traducción al español del documento ARF versión 1.8.

Logo EUDI Wallet

¿Cuáles son los nuevos actos de ejecución?

El lote anterior se publicó el viernes 29 de noviembre de 2024 con posibilidad de enviar comentarios en el portal ‘Have your say’ (Díganos lo que piensa), hasta el 27 de diciembre.

Los actos de ejecución se adoptaron el 9 de abril de 2025, per todavía no están publicados en el Diario Oficial.

El primer lote de 5 actos de ejecución se publicó el 4 de diciembre de 2024, en el Diario Oficial de la Unión Europea, entrando en vigor a los 20 días, el 24 de diciembre. Desde esa fecha se calculan los 2 años para que los estados pongan a disposición de los ciudadanos la Cartera de Identidad Digital correspondiente a cada estado y el plazo de 3 años para que las entidades privadas obligadas a la aceptación de la identidad basada en una Cartera Digital deban empezar a hacerlo.

«Verificación del Beneficiario» o «Verification of Payee»


La «Verificación del Beneficiario» (o Verification of Payee en inglés) es un servicio o proceso utilizado principalmente en el sector bancario y financiero para confirmar la identidad del destinatario de un pago antes de que se realice la transacción. Este mecanismo busca reducir el riesgo de fraude, errores en los pagos o transferencias a cuentas incorrectas.

En términos prácticos, cuando alguien inicia un pago (por ejemplo, a través de una transferencia bancaria), el sistema de Verificación del Beneficiario comprueba que los datos proporcionados (como el nombre del beneficiario y el número de cuenta) coincidan con los registros del banco receptor. Si hay una discrepancia, se puede alertar al usuario para que revise la información antes de ejecutar la transferencia.

Este servicio es especialmente común en países como el Reino Unido, donde se implementó como parte del esquema Confirmation of Payee bajo las regulaciones de la Autoridad de Conducta Financiera (FCA) para combatir el fraude de pagos autorizados (Authorised Push Payment fraud). Por ejemplo, al introducir los detalles de una transferencia, el banco podría devolver un mensaje como «Nombre coincide», «Nombre no coincide» o «Nombre similar» (Match, No Match o Close Match), ayudando al ordenante a tomar una decisión informada.

Contexto en España

En España existe un equivalente al concepto de «Verification of Payee» (Verificación del Beneficiario), aunque no se denomina exactamente así de manera oficial en la normativa española.

En España, la verificación de la identidad del beneficiario en transferencias bancarias no era un servicio obligatorio con un nombre específico como el «Confirmation of Payee» o «Verification of Payee», pero los bancos y entidades financieras han adoptado medidas similares para cumplir con las normativas de prevención de fraude y blanqueo de capitales. Estas medidas suelen incluir la validación de los datos del beneficiario (como el IBAN y el nombre) antes de procesar una transferencia, especialmente en el marco de las transferencias SEPA (Zona Única de Pagos en Euros). En la actualidad les aplica el Reglamento (UE) 2024/886.

La base legal y regulatoria para este tipo de procedimientos proviene principalmente de la legislación europea, que ha sido traspuesta al ordenamiento jurídico español. Los marcos principales son:

  1. Directiva (UE) 2015/2366 – PSD2 (Segunda Directiva de Servicios de Pago):
    • Entró en vigor en la UE en 2016 y fue traspuesta en España mediante el Real Decreto-ley 19/2018, de 23 de noviembre, sobre servicios de pago y otras medidas urgentes en materia financiera.
    • Esta directiva busca mejorar la seguridad de los pagos electrónicos y proteger a los consumidores. Aunque no menciona explícitamente la «Verificación del Beneficiario» como un servicio obligatorio, exige a las entidades financieras implementar medidas de autenticación reforzada (Strong Customer Authentication, SCA) y garantizar la seguridad en las transacciones, lo que incluye verificar la identidad de las partes involucradas en un pago.
    • En la práctica, algunos bancos españoles han integrado sistemas que cotejan el IBAN con el nombre del beneficiario para evitar errores o fraudes, aunque esto depende de las políticas internas de cada entidad.
  2. Reglamento SEPA (Reglamento (UE) No 260/2012):
    • Establece los requisitos técnicos y comerciales para las transferencias y adeudos domiciliados en euros en la zona SEPA, que incluye España.
    • Aunque el foco está en la estandarización de los pagos, las entidades pueden implementar controles adicionales, como la verificación del beneficiario, para cumplir con las expectativas de seguridad.
  3. Ley 10/2010, de 28 de abril, de prevención del blanqueo de capitales y de la financiación del terrorismo:
    • Esta ley, modificada posteriormente para adaptarse a directivas europeas (como la 4ª y 5ª Directivas AML), obliga a las entidades financieras a identificar y verificar la identidad de los clientes y beneficiarios en las operaciones financieras. Esto incluye medidas para evitar que los fondos se transfieran a cuentas fraudulentas o no deseadas, lo que indirectamente fomenta la verificación de los datos del beneficiario.
  4. Reglamento de Transferencias inmediatas (Reglamento (UE) 2024/886)
    • Modifica varios reglamentos y directivas existentes relacionados con las transferencias inmediatas en euros. Este reglamento tiene como objetivo promover el uso generalizado de transferencias instantáneas en la Unión Europea, mejorando la eficiencia, la digitalización y la innovación en los pagos.

Bancos españoles

En la actualidad los bancos españoles ya cuentan con servicios equivalentes:

  • Algunos bancos, como Santander, BBVA o CaixaBank, han desarrollado sistemas internos que alertan al usuario si el nombre del beneficiario no coincide con el IBAN proporcionado, aunque esto no es un estándar obligatorio en todo el sector.
  • La adopción de estas medidas depende de la entidad y suele estar motivada por la necesidad de cumplir con las expectativas de seguridad de los clientes y reducir el riesgo de fraude, como el fraude de suplantación (Authorised Push Payment Fraud).

European Payments Council

El 19 de marzo de 2024 se publicó el Reglamento (UE) 2024/886 del Parlamento Europeo y del Consejo de 13 de marzo de 2024 por el que se modifican los Reglamentos (UE) n.o 260/2012 y (UE) 2021/1230 y las Directivas 98/26/CE y (UE) 2015/2366 en lo que respecta a las transferencias inmediatas en euros,

Establece que el servicio VoP «Verification of Payee», lo deben ofrecer los proveedores de servicios de pago sin cargo adicional.

La comprobación debe realizarse antes de que el ordenante autorice la transferencia. En caso de «nombre similar» (close match) el ordenante deberá ser informado del nombre asociado al IBAN proporcionado.

Los PSP deberán informar a los ordenantes sobre las implicaciones de la responsabilidad del PSP y de los derechos de reembolso del ordenante sobre la opción del PSP de ignorar la notificación proporcionada. En la medida de lo posible, el servicio que garantice la verificación deberá llevarse a cabo de conformidad con un conjunto de reglas y normas para toda la Unión (por ejemplo el «rulebook» del EPC – European Payments Council).

Los ordenantes que no sean consumidores y que envíen varias órdenes de pago en forma de paquete deben poder optar por no recibir los avisos de VoP en su relación contractual con el PSP. El Servicio VoP se debe ofrecer 18 meses después de la entrada en vigor de la regulación,es decir, el 9 de octubre de 2025.

El reglamento indica que los Estados miembros adoptarán, publicarán y aplicarán, a más tardar el 9 de abril de 2025, las disposiciones legales, reglamentarias y administrativas necesarias para dar cumplimiento a lo establecido en los artículos 3 y 4. Comunicarán inmediatamente el texto de dichas disposiciones a la Comisión.

El Banco Central Europeo ha publicado un resumen del proceso del implantación del Servicio VoP.

Y el European Payment Council ha publicado en octubre de 2024 el «Verification of Payee Scheme Rulebook» y un video explicativo sobre VoP.

Como ayuda EADtrust

EADTrust proporciona certificados QWAC y QSEALC con el perfil PSD2 que se necesitan en las conexiones entre bancos y entidades de pagos. Se tienen en cuenta diferentes roles:

  1. PISP Payment Initiation Service Provider (Proveedor de Servicios de Iniciación de Pagos)
    • Estas entidades permiten a los usuarios iniciar pagos directamente desde sus cuentas bancarias a través de un tercero, sin necesidad de usar una tarjeta de crédito o débito. Actúan como intermediarios entre el pagador y el banco, facilitando transacciones seguras mediante APIs abiertas.
  2. AISP Account Information Service Provider (Proveedor de Servicios de Información de Cuentas)
    • Estas entidades recopilan y consolidan información de las cuentas bancarias del usuario (con su consentimiento), ofreciendo una visión unificada de sus finanzas. Por ejemplo, pueden mostrar saldos o historiales de transacciones de diferentes bancos en una sola plataforma.

Y están, claro, las entidades que gestionan las cuentas, que tienen su denominación propia del contexto normativo de PSD2:

  1. ASPSP Account Servicing Payment Service Provider (Proveedor de Servicios de Pago que Gestiona Cuentas)
    • Son los bancos o instituciones financieras tradicionales que mantienen las cuentas de los clientes y deben proporcionar acceso a PISP y AISP a través de interfaces seguras (como APIs) bajo el consentimiento del usuario.
  2. TPP Third Party Providers (Terceros Proveedores)
    • Es un término general que engloba a PISP y AISP, refiriéndose a cualquier entidad autorizada por PSD2 para ofrecer servicios de pago o información, distinta de los bancos tradicionales.

Contacte con EADTrust en +34 91716 0555 si necesita certificados cualificados para PSD2

Qualified Certificates for PSD2 (Second Payment Services Directive)


EADTrust offers several services related to the issuance of PSD2 qualified certificates, including the issuance of test certificates.

But, what Are PSD2 Certificates?

PSD2 certificates are specialized digital certificates mandated under the European Union’s Revised Payment Services Directive (PSD2, EU Directive 2015/2366), designed to enhance the security, transparency, and interoperability of electronic payment systems across the EU. Introduced to foster open banking, PSD2 requires financial institutions, such as banks, and third-party providers (TPPs) to allow secure access to customer account data and payment services, provided customer consent is given. To facilitate this securely, PSD2 mandates the use of qualified electronic certificates compliant with the eIDAS Regulation (EU No 910/2014), which ensures trust and authenticity in electronic transactions.

These certificates serve as a digital “company ID” for payment service providers (PSPs), identifying them and their roles within the payment ecosystem while securing communications between parties, such as banks (Account Servicing Payment Service Providers, or ASPSPs) and TPPs. The certificates are critical for meeting the Regulatory Technical Standards (RTS) outlined in EU 2018/389, particularly Article 34, which specifies requirements for strong customer authentication (SCA) and secure communication channels. Issued by Qualified Trust Service Providers (QTSPs) listed in the EU Trusted List, PSD2 certificates ensure that only authorized entities can access sensitive financial data or initiate payments, thereby reducing fraud and enhancing consumer protection.

Types of PSD2 Certificates

There are two primary types of PSD2 certificates, each serving distinct purposes within the PSD2 framework:

  1. Qualified Website Authentication Certificate (QWAC):
    • Purpose: QWACs are used to establish a secure, encrypted Transport Layer Security (TLS) connection between parties, such as a TPP and a bank’s API. They authenticate the identity of the PSP or TPP and secure the communication channel, ensuring data confidentiality and integrity during transmission.
    • Use Case: QWACs are mandatory for identifying PSPs when they access a bank’s dedicated interface (API) or fallback mechanism (emergency interface). They are akin to Extended Validation (EV) TLS/SSL certificates but include additional PSD2-specific fields.
    • Technical Details: QWACs rely on a minimum key length of 2048 bits and are generated using a Certificate Signing Request (CSR) that includes the public key and specific attributes (e.g., Organization, Country).
  2. Qualified Certificate for Electronic Seal (QSealC or QSEAL):
    • Purpose: QSealCs provide a digital signature or “seal” on data or messages exchanged between parties, ensuring the data’s origin and integrity. They prevent tampering and offer non-repudiation, meaning the sender cannot deny having sent the message.
    • Use Case: QSealCs are used to sign requests or transactions (e.g., payment initiation or account information retrieval), providing evidence of the request’s authenticity. While not always mandatory, some banks or standards (e.g., Berlin Group’s NextGenPSD2) may require their use alongside QWACs.
    • Technical Details: QSealCs require a minimum key length of 3072 bits for higher security. They can be implemented as “soft seals” (stored digitally without hardware) or with hardware security modules (HSMs) or smart cards, depending on the provider.

Both certificate types are defined under the ETSI TS 119 495 standard, which outlines their technical specifications and ensures interoperability across the EU.

Information Contained in PSD2 Certificates

PSD2 certificates include standard fields found in digital certificates, as well as additional PSD2-specific information to meet regulatory requirements. The key details are:

  • Standard Certificate Fields:
    • Organization (O): The legal name of the PSP or entity.
    • Organizational Unit (OU): Optional, specifying a department or division (if applicable).
    • Common Name (CN): Typically the domain or identifier of the entity.
    • Country Code (C): The two-letter code of the entity’s home country (e.g., “DE” for Germany).
    • State or Province (S): The entity’s state or region (optional).
    • City (L): The entity’s city of operation.
  • PSD2-Specific Fields (in the Qualified Certificate Statement, QC Statement):
    • Authorization Number: A unique identifier issued by the National Competent Authority (NCA) upon registration or licensing of the PSP. This links the certificate to the official public register.
    • PSD2 Roles: The specific roles or entitlements of the PSP, indicating the services they are authorized to provide (detailed below).
    • Name of the National Competent Authority (NCA): The regulatory body overseeing the PSP (e.g., BaFin in Germany, Bank of Spain in Spain).

These fields ensure that the certificate unambiguously identifies the PSP, its authorized activities, and the supervising authority, enabling banks and other parties to verify legitimacy during transactions.

Requirements for Issuance of PSD2 Certificates

The issuance of PSD2 certificates involves strict requirements to ensure security and compliance with EU regulations. These include:

  1. Authorization by a National Competent Authority (NCA):
    • Before applying for a certificate, a PSP must obtain a license or registration from its NCA (e.g., the Financial Conduct Authority in the UK, KNF in Poland). This process confirms the entity’s eligibility to operate as a PSP under PSD2.
    • CRR credit institutions (banks with a full banking license) do not require additional authorization and can directly apply for certificates covering all roles.
  2. Application to a Qualified Trust Service Provider (QTSP):
    • Certificates must be issued by a QTSP accredited under eIDAS and listed in the EU Trusted List. Examples include DigiCert, GlobalSign, and Buypass.
    • The PSP submits a Certificate Signing Request (CSR) containing the public key and required attributes, generated with specified key lengths (2048 bits for QWACs, 3072 bits for QSealCs).
  3. Identity Verification:
    • A natural person (e.g., an authorized signatory) must be identified to represent the PSP. This can be:
      • The signatory themselves for a Qualified Seal Card PSD2.
      • A delegated representative (subscriber’s representative) for QWACs or QSealCs, authorized via a signed request form.
    • Identification methods vary by country:
      • In Germany, PostIdent is standard.
      • Elsewhere, it may involve embassies, consulates, or notaries listed in the European Directory of Notaries.
  4. Validation Against Public Registers:
    • The QTSP verifies the PSP’s authorization number and roles against the NCA’s public register or the European Banking Authority (EBA) register to ensure accuracy and legitimacy.
  5. Technical Requirements:
    • The PSP generates and manages its own private keys, ensuring they remain secure (e.g., using an HSM for QSealCs).
    • Test certificates, which do not require an NCA license, are available for pre-authorization testing but follow the same technical standards.
  6. Certificate Validity and Renewal:
    • QWACs are typically valid for one year, while QSealCs may vary depending on the QTSP. Changes (e.g., PSP name or roles) require revocation of the old certificate and issuance of a new one, as fields cannot be edited.

Roles Encoded in PSD2 Certificates

PSD2 recognizes four distinct roles for PSPs, which define their authorized activities within the payment ecosystem. These roles are encoded in the certificates and align with the ETSI TS 119 495 standard abbreviations:

  1. Account Information Service Provider (AISP, PSP_AI):
    • Description: AISPs aggregate and provide consolidated views of a customer’s payment accounts (e.g., from multiple banks). They help with budgeting, expense tracking, and financial planning.
    • Function: Read-only access to account data, with customer consent.
  2. Payment Initiation Service Provider (PISP, PSP_PI):
    • Description: PISPs initiate payments on behalf of customers directly from their bank accounts, acting as intermediaries between merchants and banks.
    • Function: Facilitates online credit transfers or direct debits, bypassing traditional card payments.
  3. Account Servicing Payment Service Provider (ASPSP, PSP_AS):
    • Description: Typically traditional banks or institutions that maintain payment accounts for customers.
    • Function: Provides account management services and must open APIs for TPPs to access customer data or initiate payments.
  4. Payment Service Provider Issuing Card-Based Payment Instruments (PSP_IC):
    • Description: Entities authorized to issue card-based payment instruments (e.g., debit or credit cards).
    • Function: Enables card payments as part of the payment ecosystem.

A single PSP can hold multiple roles (e.g., both AISP and PISP), and these are all encoded in the certificate’s QC Statement. Banks with a full CRR license can apply for all roles without additional authorization, while TPPs must specify their roles during NCA registration.


Conclusion

PSD2 certificates (QWACs and QSealCs) are vital tools for ensuring secure, authenticated, and interoperable electronic payments under the PSD2 framework. They identify PSPs, secure communications, and protect data integrity, relying on strict issuance processes overseen by QTSPs and NCAs. Containing detailed organizational and regulatory information, they encode one or more of the four PSP roles (AISP, PISP, ASPSP, PSP_IC), reflecting the diverse functions within the open banking landscape. This robust system supports PSD2’s goals of enhancing security, promoting competition, and protecting consumers across the EU.

Certificados cualificados para PSD2 (Segunda Directiva de Servicios de Pago)


EADTrust expide Certificados Cualificados PSD2 para entidades financieras y otros roles definidos en la Directiva PSD2: TPP, AISP, PISP, ASPSP. CISP

Los certificados PSD2 son certificados digitales cualificados diseñados para cumplir con la Directiva de Servicios de Pago (PSD2) de la Unión Europea. Estos certificados aseguran las transacciones financieras y la comunicación entre los proveedores de servicios de pago y las instituciones financieras.

Tipos de certificados PSD2

Existen dos tipos principales de certificados PSD2:

  1. QWAC (Qualified Website Authentication Certificate):
    • Autentifica el sitio web del proveedor de servicios de pago.
    • Cifra las comunicaciones entre el banco y el proveedor mediante conexión TLS.
    • Garantiza la comunicación segura en la transmisión de datos.
  2. QSealC (Qualified eSeal Certificate):
    • Securiza los datos a nivel de aplicación.
    • Identifica de forma unívoca quién ha accedido a la API.
    • Protege los datos firmados contra modificaciones, asegurando su integridad.

Información contenida

Los certificados PSD2 incluyen:

  • Identidad del proveedor de servicios de pago.
  • Roles del proveedor (pueden ser uno o varios: AISP, PISP,…).
  • Número de autorización asignado por la Autoridad Nacional Competente.
  • Nombre del dominio/dominios autenticados

Requisitos para su expedición

Para obtener un certificado PSD2, se requiere:

  1. Ser un proveedor de servicios de pago autorizado con un número de autorización asignado por la Autoridad Nacional Competente (en España, el Banco de España).
  2. Presentar documentación:
    • Documento de identificación (DNI, NIE) del representante legal.
    • Poder que acredite la representación vigente.
    • Identificación de la categoría de la entidad (organización privada, entidad gubernamental, comercial o no comercial)
  3. Pasar por un proceso de validación, similar al requerido para TLS de validación extendida (EV), que puede incluir:
    • Verificación cara a cara de los documentos oficiales del titular del certificado.
    • Confirmación de la licencia y roles del proveedor de servicios de pago por parte de la autoridad certificadora
  4. En algunos casos, se puede requerir la intervención de un notario público para facilitar el proceso de validación

Los certificados PSD2 son cruciales para garantizar la seguridad y la confianza en las transacciones financieras digitales en el marco de la normativa europea, proporcionando autenticación, integridad y confidencialidad en las comunicaciones entre proveedores de servicios de pago, bancos y clientes.

Puede contactar con EADTrust llamando al 91 7160555 o 902 365 612.