Archivo de la categoría: PKI

Expedición de certificados cualificados sin comparecencia presencial (a distancia)


El Reglamento UE 910/2014 establece en su artículo 24:

1.   Al expedir un certificado cualificado para un servicio de confianza, un prestador cualificado de servicios de confianza verificará, por los medios apropiados y de acuerdo con el Derecho nacional, la identidad y, si procede, cualquier atributo específico de la persona física o jurídica a la que se expide un certificado cualificado.

La información a que se refiere el párrafo primero será verificada por el prestador de servicios de confianza bien directamente o bien por medio de un tercero de conformidad con el Derecho nacional:

  1. en presencia de la persona física o de un representante autorizado de la persona jurídica, o
  2. a distancia, utilizando medios de identificación electrónica, para los cuales se haya garantizado la presencia de la persona física o de un representante autorizado de la persona jurídica previamente a la expedición del certificado cualificado, y que cumplan los requisitos establecidos con el artículo 8 con respecto a los niveles de seguridad «sustancial» o «alto», o
  3. por medio de un certificado de una firma electrónica cualificada o de un sello electrónico cualificado expedido de conformidad con la letra a) o b), o
  4. utilizando otros métodos de identificación reconocidos a escala nacional que aporten una seguridad equivalente en términos de fiabilidad a la presencia física. La seguridad equivalente será confirmada por un organismo de evaluación de la conformidad.

El apartado 24-1.b permite la identificación a través de una plataforma de gestión de identidad siempre que se hayan adoptado medidas de seguridad apropiadas. El Reglamento de Ejecución (UE) 2015/1502 de la Comisión de 8 de septiembre de 2015 orienta sobre los aspectos a cumplir.

Para el caso de la opción  24-1.d ya existe en España adecuada cobertura según la Ley 6/2020 (Artículo 7):

(…) 
Podrá prescindirse de la personación de la persona física que solicite un certificado cualificado si su firma en la solicitud de expedición de un certificado cualificado ha sido legitimada en presencia notarial. 
(…) 
2. Reglamentariamente, mediante Orden de la persona titular del Ministerio de Asuntos Económicos y Transformación Digital, se determinarán otras condiciones y requisitos técnicos de verificación de la identidad a distancia y, si procede, otros atributos específicos de la persona solicitante de un certificado cualificado, mediante otros métodos de identificación como videoconferencia o vídeo-identificación que aporten una seguridad equivalente en términos de fiabilidad a la presencia física según su evaluación por un organismo de evaluación de la conformidad. La determinación de dichas condiciones y requisitos técnicos se realizará a partir de los estándares que, en su caso, hayan sido determinados a nivel comunitario. 
Serán considerados métodos de identificación reconocidos a escala nacional, a los efectos de lo previsto en el presente apartado, aquellos que aporten una seguridad equivalente en términos de fiabilidad a la presencia física y cuya equivalencia en el nivel de seguridad sea certificada por un organismo de evaluación de la conformidad, de acuerdo con lo previsto en la normativa en materia de servicios electrónicos de confianza.

Este artículo da cobertura legal a la adopción de estas dos normas:

  • Orden ETD/465/2021, de 6 de mayo, por la que se regulan los métodos de identificación remota por vídeo para la expedición de certificados electrónicos cualificados. Normativa a cumplir para la identificación a distancia (videoconferencia y videoidentificación) y criterios de auditoría para permitir la evaluación de los sistemas que la implementan. Específica de España
  • ETSI TS 119 461 V1.1.1 (2021-07) – Policy and security requirements for trust service components providing identity proofing of trust service subjects. Para uso en toda la Unión Europea. Toca más casos de uso, no solo la videoidentificación remota .

Los CABs (Conformity Assessment Bodies) ya contemplan estas normas en sus auditorías.

Y es algo muy necesario como se pudo comprobar en la fase de confinamiento de la ciudadanía del primer semestre de 2020 provocado por la enfermedad COVID-19.

Firma electrónica indirecta


En ocasiones hay que realizar firmas electrónicas sobre un documento electrónico principal que lleva adjuntos otros documentos electrónicos. Y puede que sea conveniente que alguno o todos los documentos adjuntos estén firmados electrónicamente. El primer documento suele estar en formato PDF y se puede firmar con herramientas como Adobe Acrobat DC (atención, las denominaciones de la firma en Acrobat son confusas: la que hay que usar es la firma basada en certificado).

Una posible solución a la firma de múltiples documentos (en caso de que el procedimiento al que se van a incorporar los documentos lo admita) es incluir en el escrito principal un anexo de firmas indirectas que incluye la relación de documentos electrónicos adjuntos, utilizando para ellos nombres descriptivos que deberán coincidir con los de los propios documentos y, si es posible, de forma que el nombre incluya entre sus primeros caracteres las cifras que componen su número ordinal dentro de la relación de documentos según la preferencia de ordenación del firmante o de quien elabora el escrito.

Para cada fichero es conveniente indicar el tamaño y es preceptivo indicar el valor hash correspondiente al fichero.

En la sección inicial del anexo, antes de incluir la propia tabla que contiene los nombres de los ficheros y sus valores, se debe especificar el formato de hash utilizado, que normalmente será de los tipos SHA-2 o SHA-3, considerando la variante concreta. Por ejemplo «SHA-2 (variante SHA-256)». Conviene indicar la notación empleada. Por ejemplo, «El resultado del valor HASH se expresa en notación hexadecimal», o «El resultado del valor HASH se expresa en notación Base64».

También es conveniente que los valores hash se incluyan en una tipografía de las denominadas  «de espaciado fijo entre caracteres» (en inglés «monospaced») como el tipo de letra Courier que permite apreciar que todas las tiras de caracteres tienen el mismo tamaño (y detectar errores relacionados con la existencia de un número de caracteres mayor o menor del que corresponde).

Para calcular los valores HASH de los ficheros existen diversas herramientas. En sistemas Windows, una de las recomendables por su sencillez es Hashtab disponible originalmente en la web Implbits.

Tras instalar el software, se crea una opción de menú contextual en el Explorador de Windows, de modo que, si pulsamos sobre un fichero con el botón derecho del ratón y a continuación sobre la opción «Propiedades» (la opción que queda abajo del todo) se abre una ventana que contiene una pestaña para los valores hash del documento («Hash de Archivos»).

A continuación se pulsa en la pestaña de la zona superior «Hash de Archivos» y se pueden ver los valores hash del fichero por tipo de algoritmo.

Si se pulsa sobre el enlace «Parámetros» (hacia la mitad de la ventana) se pueden elegir los tipos de hash que se desea que muestre la herramienta.

Este tipo de firmas indirectas puede considerarse similar a las denominadas «separadas» o «acompañantes» («detached» en inglés) ya que los propios documentos no se modifican para incluir las firmas (como en las firmas «attached enveloped») ni se crean estructuras contenedoras de la firma y del documento (como en las firmas «attached enveloping»)

Dispositivo cualificado de protección de claves


Llevamos desde 2014, fecha de aprobación de reglamento EIDAS, llamando a las tarjetas chip, a los tokens criptográficos y a los HSM (Hardware Security Module) «Dispositivo cualificado de creación de firma» .

Si nos remontamos a la Directiva 93/1999, la denominación sería «Dispositivo seguro de creación de firma«.

Pero es un error.

Los certificados cualificados (como los demás tipos de certificado) tienen un campo denominado «Key Usage» y en ese campo se indica si el certificado se usará para «firma electrónica» (ContentCommitment) o para «autenticación» (DigitalSignature), por ejemplo, con la opción de autenticación de cliente del protocolo TLS.

Además caben otros usos e, incluso, podrían combinarse, activando estos dos, «ContentCommitment» y «DigitalSignature» simultáneamente.

Desde el punto de vista del alcance de la regulación, ni la Directiva 93/1999, ni el Reglamento 910/2014, han definido de forma expresa la posibilidad de autenticar al titular de los certificados cualificados. Pero esa posibilidad siempre ha estado ahí. Aunque solo se ha considerado la firma electrónica (y, a partir del Reglamento, el sello electrónico) los certificados que incluyen activo el bit «DigitalSignature» en el campo «Key Usage» son certificados de autenticación.

Así lo recogía la norma técnica ETSI TS 102 280 y lo recoge en la actualidad la norma técnica ETSI EN 319 412-2.

Por tanto, si concluimos que los certificados pueden ser de autenticación, y no solo de firma electrónica el hecho de que residan en el mismo dispositivo seguro de protección de claves privadas tanto para un uso como para el otro, debería determinar que el dispositivo se denominara «Dispositivo cualificado de protección de claves» y no «Dispositivo cualificado de creación de firma«

Por cierto, también creo que los bits del «Key Usage» deberían tener denominaciones distintas. Ya hubo un avance cuando quedó obsoleta la denominación «Non repudiation» en diversas normas técnicas y fue sustituida por «Content Commitment«, lo que en verdad significa «firma» porque en la firma el firmante se vincula con el contenido firmado. Pero la vieja denominación «Digital Signature» todavía persiste porque justifica técnicamente que en un protocolo de reto-respuesta, la respuesta se calcula realizando la operación criptográfica de la firma digital sobre el reto. Pero, en realidad esto es un proceso de Autenticación, y llamarlo «Digital Signature» es equívoco para expertos y legos. Los términos adecuados seguramente son «Signature» (en vez de «Content Commitment«) y «Authentication» (en vez de «DigitalSignature«), pero pueden pasar años antes de que estos términos los veamos en la normas técnicas o en la legales.

Adobe actualiza su lista de confianza y sigue incluyendo la EUTL


Adobe desempeña un papel esencial en la popularización de la firma electrónica que hay que reconocer.

Por un lado, su herramienta gratuita de visualización de archivos PDF Acrobat Reader incluye sin coste una herramienta de creación de firmas electrónicas basada en certificados (entre los que destacan los certificados cualificados tal como los define el Reglamento UE 910/2014, eIdAS ).

Por otro lado, ha apostado desde la entrada en vigor del citado reglamento por incluir en la lista de confianza de sus productos (antiguamente denominada AATL) las entidades prestadoras de servicios de confianza que figuran en la lista de confianza de la unión europea (EUTL) que se puede recorrer con detalle gracias al Visualizador de Listas,

Esta combinación es importante para impulsar el uso de la firma electrónica en una herramienta que se caracteriza por la efectividad al cumplir su misión de mostrar los documentos electrónicos de forma muy parecida a los documentos en papel y establecer una potente metáfora del uso electrónico de los documentos manteniendo muchas de las ventajas de los documentos en papel, y algunas complementarias , como las informaciones adicionales que se guardan en los metadatos.

La lista actualizada de los entidades de confianza para Adobe obtenida de la EUTL puede verse en este artículo: ¿Qué es EUTL?

Y la lista concreta de los prestadores de servicios de certificación cualificados españoles (un subconjunto de la lista anterior), es esta:

Los certificados DSC de España con los que se firman los pasaportes COVID


Algunos paises europeos han publicado la información de los certificados electrónicos ECC (y unos pocos RSA) con los que se firman los pasaportes COVID (oficialmente «Certificados Digitales COVID» y anteriormente «Certificados verdes digitales»). Estos certificados se denominan DSC (Document Signing Certificate). Ya lo mencioné en el artículo «Public Key of Spain CSCA for European digital COVID certificate«.

Uno de los países que publican la información de dichos certificados electrónicos es Suecia, que hace referencia a los certificados incluidos en la pasarela de validación de confianza de pasaportes COVID (Técnicamente «Digital Green Certificate Gateway» DGCG).

En España, todos los certificados menos uno los ha expedido EADTrust (European Agency of Digital Trust), por lo que la Sub-CA de certificados de curva elíptica P-256 para sello de órgano de EADTrust se ha convertido en la principal CSCA (Certificate Signing Certificate Authority de España. Otra singularidad del sistema adoptado en España es que los DSC emitidos por EADTrust son, además, certificados cualificados de sello de órgano según el Reglamento EIDAS.

Estos son los datos principales de certificados de CSCA y DSC de España:

Country: ES
TypeNameContactPurpose
CSCA CertificateOU=Legal Person, OID.2.5.4.97=VATES-B85626240, C=ES, O=»European Agency of Digital Trust, S.L.», CN=EADTrust ECC 256 SubCA For Qualified Certificates 2019ca@eadtrust.eu
CSCA CertificateCN=iCA Izenpe, OU=Peer, O=IZENPE S.A., C=ES
Document SignerC=ES, O=SERVICIO DE SALUD DE LAS ISLAS BALEARES, OID.2.5.4.97=VATES-Q0719003F, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0719003F, CN=IBSALUT-CVD-SELLO1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Extremeño de Salud, OID.2.5.4.97=VATES-Q0600413I, OU=SSII, OU=SELLO ELECTRONICO, SERIALNUMBER=Q0600413I, CN=Servicio Extremeño de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OID.2.5.4.97=VATES- Q4700608E, OU=GERENCIA REGIONAL DE SALUD DE CASTILLA Y LEON, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4700608E, CN=GERENCIA REGIONAL DE SALUD CASTILLA Y LEÓN (SACYL)1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=»DIRECCION GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS», OID.2.5.4.97=VATES-S2633001I, OU=»DIRECCIÓN GENERAL DE SALUD PUBLICA, CONSUMO Y CUIDADOS», OU=SELLO ELECTRONICO, SERIALNUMBER=S2633001I, CN=Gobierno de La Rioja1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Canario de la Salud, OID.2.5.4.97=VATES-Q8555011I, OU=Secretaría General del Servicio Canario de la Salud, OU=SELLO ELECTRONICO, SERIALNUMBER=Q8555011I, CN=Secretaría General del Servicio Canario de la Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTÓNOMA DE MELILLA, OID.2.5.4.97=VATES-S7900010E, OU=DIRECCIÓN GENERAL DE LA SOCIEDAD DE LA INFORMACIÓN, OU=SELLO ELECTRONICO, SERIALNUMBER=S7900010E, CN=SELLO ELECTRONICO DE LA CIUDAD AUTÓNOMA DE MELILLA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO ANDALUZ DE SALUD, OID.2.5.4.97=VATES-Q9150013B, OU=SERVICIO ANDALUZ DE SALUD, OU=SELLO ELECTRONICO, SERIALNUMBER=Q9150013B, CN=SELLO SAS PARA CERTIFICADO COVID DE LA UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerCN=DIRECCIÓN DE SALUD PÚBLICA Y ADICCIONES, OID.2.5.4.97=VATES-S4833001C, OU=SELLO ELECTRONICO, O=EUSKO JAURLARITZA – GOBIERNO VASCO, C=ES1.3.6.1.5.5.7.3.2
Document SignerC=ES, O=Servicio Cántabro de Salud, OID.2.5.4.97=VATES-Q3900738J, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3900738J, CN=Servicio Cántabro de Salud1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio de Salud de Castilla-La Mancha, OID.2.5.4.97=VATES- Q4500146H, OU=SELLO ELECTRONICO, SERIALNUMBER=Q4500146H, CN=SESCAM Certificado Digital COVID UE1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Ministerio de Defensa, OID.2.5.4.97=VATES-S2830001J, OU=Inspección General de Sanidad de la Defensa, OU=SELLO ELECTRONICO, SERIALNUMBER=S2830001J, CN=Inspección General de Sanidad de la Defensa1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Principado de Asturias, OID.2.5.4.97=VATES- S3333001J, OU=SELLO ELECTRONICO, SERIALNUMBER=S3333001J, CN=Consejería de Salud del Principado de Asturias1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Servicio Navarro de Salud-Osasunbidea, OID.2.5.4.97=VATES-Q3150004D, OU=Servicio Navarro de Salud-Osasunbidea, OU=SELLO ELECTRONICO, SERIALNUMBER=Q3150004D, CN=Sello Electrónico del Servicio Navarro de Salud-Osasunbidea1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=CIUDAD AUTONOMA DE CEUTA, OID.2.5.4.97=VATES-S6100007A, OU=CIUDAD AUTONOMA DE CEUTA, OU=SELLO ELECTRONICO, SERIALNUMBER=S6100007A, CN=CEUTA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GENERALITAT VALENCIANA, OID.2.5.4.97=VATES-S4611001A, OU=CONSELLERIA DE SANITAT UNIVERSAL I SALUT PÚBLICA, OU=SELLO ELECTRONICO, SERIALNUMBER=S4611001A, CN=GENERALITAT VALENCIANA1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Departament de Salut de la Generalitat de Catalunya, OID.2.5.4.97=VATES-S0811001G, OU=Departament de Salut, OU=SELLO ELECTRONICO, SERIALNUMBER=S0811001G, CN=CERT-GENCAT-1S-211.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=COMUNIDAD AUTONOMA DE LA REGION DE MURCIA, OID.2.5.4.97=VATES- S3011001l, OU=DIRECCION GENERAL INFORMATICA CORPORATIVA, OU=SELLO ELECTRONICO, SERIALNUMBER=S3011001l, CN=DIRECCIÓN GENERAL DE SALUD PÚBLICA Y ADICCIONES1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=MINISTERIO DE SANIDAD, OID.2.5.4.97=VATES-S2827001E, OU=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID19, OU=SELLO ELECTRONICO, SERIALNUMBER=S2827001E, CN=SELLO MINISTERIO DE SANIDAD CERTIFICACION COVID191.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=GOBIERNO DE ARAGON, OID.2.5.4.97=VATES-S5011001D, OU=DEPARTAMENTO DE SANIDAD, OU=SELLO ELECTRONICO, SERIALNUMBER=S5011001D, CN=DEPARTAMENTO DE SANIDAD DEL GOBIERNO DE ARAGON1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=SERVICIO MADRILEÑO DE SALUD, OID.2.5.4.97=VATES-Q2801221I, OU=DG SISTEMAS DE INFORMACION Y EQUIPAMIENTOS SANITARIOS, OU=SELLO ELECTRONICO, SERIALNUMBER=Q2801221I, CN=FIRMA CERTIFICADO COVID DIGITAL UE 11.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4
Document SignerC=ES, O=Consellería de Sanidad, OID.2.5.4.97=VATES-S1511001H, OU=SELLO ELECTRONICO, SERIALNUMBER=S1511001H, CN=ConselleriadeSanidade.XuntadeGalicia1.3.6.1.5.5.7.3.2, 1.3.6.1.5.5.7.3.4

Compatibilidad con EIDAS de proyectos de blockchain. Criptografía.


EADTrust está emitiendo certificados cualificados de persona física y persona física para su integración en proyectos de blockchain, lo que permitirá comprobar la viabilidad de los sistemas de identidad digital basados en carteras virtuales (User-centric Identity, denominación que sustitute a Self-sovereign Identity).

Un reto del proyecto es la selección del marco de algoritmos criptográficos que se usarán.

Aunque hay razones técnicas para adoptar el esquema de firma digital «Edwards-curve Digital Signature Algorithm (EdDSA)» (denominacion Ed25519) o la variante de «Elliptic Curve Digital Signature Algorithm (ECDSA) denominada secp256k1 y en algunos proyectos de Blockchain se ha elegido alguno de dichos algoritmos (o variantes con diferentes tamaños de clave), en las discusiones técnicas del equipo del Prestador de Servicios de Confianza indicado, finalmente se ha decidido optar por «Elliptic Curve Digital Signature Algorithm (ECDSA) en linea con las recomendaciones de la norma ETSI TS 119 312 V1.3.1. En concreto, la variante P256 (además de esta denominacion, P-256, tiene además otros nombres prime256v1 o sec256r1).

Dibujo de Carl Mehner sobre la curva P-256 usado en su blog https://www.cem.me/20170410-ecc-1.html

EADtrust ha sido la primera autoridad de certificación en emitir certificados basados en criptografía de curva elíptica y una de las pocas que lo hacen en el mundo. En el contexto de EIDAS (Reglamento UE 910/2014), emite certificados cualificados de persona física y de persona jurídica basados en el algoritmo ECDSA , con las variantes P-256 y P-384.

La compatibilidad con despliegues de infraestructura ya existentes en EIDAS es la que hace recomendable el uso de estos mismos algoritmos en proyectos con Blockchain, especialmente en las fases iniciales del proyecto en las que todavía no se han creado dependencias con decisiones de diseño para las que exista ya un histórico de bloques minados.

Electronic signatures in EU Digital COVID Certificates, based on qualified certificates issued by #EIDAS Certification Authorities


To configure DGCG (Digital Green Certificate Gateway) in Digital COVID Certificate project, participating countries provide information regarding Public Key of the certificate of CSCA (Certificate Signing Certificate Authority). Spain uses a ECC #eIDAS Sub-CA as CSCA.

CSCA, as defined in the DGC project, requires the CSCA cert to include the country field for which the CSCA is valid. However, #EIDAS certificates are intended for cross-border interoperability, so the country field in the CA cert is irrelevant to countries in which it is valid.

DGC technical documents should be changed so CSCA of one country could be serviced from a CA in other country. So #EIDAS certification authorities could provide DSC certificates to health bodies in any country. The same principle should be extended to WHO technical documents.

Extended key Usage Identifiers could be present with some information in #EIDAS certificates, so the explanation that the DSC may contain an extended key usage extension with zero or more key usage policy identifiers that constrain the types of HCERTs such DSC certificate may sign, should consider other OIDs as «not present» if the eHealth application doesn´t understand them.

If one or more of the special DGC OIDs are present, the verifiers SHALL verify the extended key usage against the stored HCERT.

In absence of any key usage extension of the special DGC OIDs (i.e. no such special DGC OIDs extensions), the related DSC certificate can be used to sign any type of HCERT.

So, in #EIDAS DSC certificates to be used to electronically sign HCERT, the following OIDs can be used in Extended Key Usage extension fields:

  • OID 1.3.6.1.4.1.1847.2021.1.1 — valid for test
  • OID 1.3.6.1.4.1.1847.2021.1.2 — valid for vaccinations
  • OID 1.3.6.1.4.1.1847.2021.1.3 — valid for recovery

This OIDs can be present if the related EU Digital COVID Certificate is restricted to one of two kind of certificates. If all 3 are included (or none of them) the related EU Digital COVID Certificate is NOT restricted and can reflect any of the three options.

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


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) .

¿Qué sucede cuando un Prestador de Servicios Electrónicos de Confianza cesa su actividad?


En la actualidad ya existen varios tipos de servicios electrónicos de confianza, no solo la emisión de certificados, pero está claro que al menos uno de los problemas a gestionar cuando se deja de ofrecer un servicio de confianza es la revocación de certificados expedidos, y la disponibilidad de esta información para los afectados (titulares de los certificados y terceros que confían en ellos).

La Ley 59/2003de 19 de diciembre, de firma electrónica ,de próxima derogación establece en su artículo 21.3 que, en caso de cese de la actividad de un prestador de servicios de certificación, éste remitirá al Organismo Supervisor (a fecha de este artículo el Ministerio de Asuntos Económicos y Transformación Digital) con carácter previo al cese definitivo de su actividad la información relativa a los certificados electrónicos cuya vigencia haya sido extinguida para que éste se haga cargo de su custodia a efectos de lo previsto en el artículo 20.1.f.

Dicho artículo 20.1.f establece que la información relativa a un certificado «reconocido» (que en la actualidad tras la publicación del Reglamento EIDAS (Reglamento (UE) Nº 910/2014 del Parlamento Europeo y del Consejo de 23 de julio de 2014 relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior y por el que se deroga la Directiva 1999/93/CE) se denomina «cualificado«) será custodiada, al menos durante 15 años contados desde el momento de su expedición, de manera que se puedan verificar las firmas realizadas con dicho certificado (serían válidas las firmas codificadas antes de su revocación).

Asimismo, el artículo 21.3 establece que el Organismo Supervisor mantendrá accesible al público un servicio de consulta específico donde figure una indicación sobre los citados certificados durante un período que se considere suficiente en función de las consultas efectuadas al mismo.

Por otro lado y en relación con la prestación de servicios cualificados de confianza, el Reglamento EIDAS obliga a los prestadores cualificados de servicios de confianza a informar al Organismo Supervisor de su intención de cesar la prestación de sus servicios (art. 24.2.a), así como a contar con un plan de cese actualizado para garantizar la continuidad del servicio (art. 24.2.i).

Además, conforme a lo indicado (art. 17.4.i) en el citado Reglamento EIDAS este Organismo Supervisor verifica la existencia y la correcta aplicación de las disposiciones relativas a los planes de cese en caso de que los prestadores de servicios de confianza cesen sus actividades.

A lo largo del tiempo, en España han ido cesando sus actividades varios Prestadores de Servicios de Confianza, que lo han comunicado al Organismo Supervisor que ha publicado la información que se transcribe a continuación:

Safe Creative S.L.

  • Nombre o Razón Social: Safe Creative S.L.
  • Nombre Comercial: Safe Creative S.L.
  • Fecha de resolución por la que se acepta la comunicación de cese: 26 de diciembre de 2019

Signen

  • Nombre o Razón Social: Signen Blockchain S.L.
  • Nombre Comercial: Signen
  • Fecha de resolución por la que se acepta la comunicación de cese: 9 de diciembre de 2019

Netfocus

  • Nombre o Razón Social: Hewlett-Packard Española Sociedad Limitada
  • Nombre Comercial: NETFOCUS
  • Fecha de resolución por la que se acepta la comunicación de cese: 03 de abril de 2009
  • El período de validez de todos los certificados electrónicos de Netfocus se encuentra expirado

Telefónica Empresas

  • Nombre o Razón Social: Telefónica Data España, S.A.U
  • Nombre Comercial: Telefónica Empresas
  • Fecha de resolución por la que se acepta la comunicación de cese: 29 de junio de 2012
  • Gestión de los certificados transferida al Prestador de Servicios de Certificación: Telefónica Soluciones de Informática y Comunicaciones de España, S.A. Sociedad Unipersonal

CertiVer

  • Nombre o Razón Social: Certificate, Verification & Revocation S.L.
  • Nombre Comercial: CertiVer
  • Fecha de resolución por la que se acepta la comunicación de cese: 07 de junio de 2012  

Banesto CA

  • Nombre o Razón Social: Banco Español de Crédito, S.A
  • Nombre Comercial: Banesto CA
  • Fecha de resolución por la que se acepta la comunicación de cese: 05 de junio de 2013
  • El período de validez de todos los certificados electrónicos de Banesto CA se encuentra expirado

Telefónica GGCC (Grandes cuentas)

  • Nombre o Razón Social:   Telefónica Soluciones de Informática y Comunicaciones de España, S.A. Sociedad Unipersonal
  • Nombre Comercial: Telefónica GGCC (Grandes cuentas)
  • Fecha de resolución por la que se acepta la comunicación de cese: 18 de marzo de 2014

Lista de certificados revocados (CRL) Telefónica

IpsCA

  • Nombre o Razón Social: IPS Certification Authority S.L.
  • Nombre Comercial: IPSCA
  • Fecha de cese: 10 de octubre de 2014

Autoridad de Sellado de Tiempo iCertia

  • Nombre o Razón Social: Evintia, S.L.
  • Nombre comercial: Autoridad de Sellado de Tiempo iCertia
  • Fecha de resolución por la que se acepta la comunicación de cese: 28 de marzo de 2015 

CICCP

  • Nombre o Razón Social: Colegio de Ingenieros de Caminos, Canales y Puertos
  • Nombre Comercial: CICCP
  • Fecha de resolución por la que se acepta la comunicación de cese: 03 de junio de 2015
  • El período de validez de todos los certificados electrónicos de CICCP se encuentra expirado

Healthsign, S.L.

  • Nombre o Razón Social: HEALTHSIGN, S.L.
  • Nombre Comercial: HEALTHSIGN, S.L.
  • Fecha de resolución por la que se acepta la comunicación de cese: 1 de diciembre de 2015

Lista de certificados revocados (CRL) CODIGI CA

Lista de certificados revocados (CRL) CODILL CA

Lista de certificados revocados (CRL) CODITA CA

Lista de certificados revocados (CRL) COMG CA

Lista de certificados revocados (CRL) COMLL CA

Lista de certificados revocados (CRL) COMT CA

STARTCOM

  • Nombre o Razón Social: STARTCOM CA SPAIN S.L.U.
  • Nombre Comercial: STARTCOM
  • Fecha de recepción del escrito de comunicación de cese: 18 de enero de 2018

Lista de certificados revocados STARTCOM CLIENT CERTIFICATES 1

Lista de certificados revocados STARTCOM CLIENT CERTIFICATES 2

Lista de certificados revocados STARTCOM CLIENT CERTIFICATES 3

Lista de certificados revocados OV

Lista de certificados revocados IV

Lista de certificados revocados EV

Lista de certificados revocados DV

Tractis

  • Nombre o Razón Social: Negonation Platform, S.L.
  • Nombre Comercial: Tractis
  • Fecha de recepción del escrito de comunicación de cese: 21 de marzo de 2018

Banco Santander

  • Nombre o Razón Social: Banco Santander, S.A.
  • Nombre Comercial: Santander
  • Fecha de resolución por la que se acepta la comunicación de cese: 17 de octubre de 2018

Lista de certificados revocados (CRL)

Servicio de Salud de Castilla-La Mancha (SESCAM)

  • Nombre o Razón Social: Servicio de Salud de Castilla-La Mancha (SESCAM)
  • Nombre Comercial: Servicio de Salud de Castilla-La Mancha (SESCAM)
  • Fecha de cese: 10 de diciembre de 2018

El Ministerio ha publicado información sobre el Procedimiento administrativo para notificar el cese de un prestador.

Habilitación para identificación remota en servicios de confianza


El Boletín Oficial del Estado del viernes 11 de septiembre de 2020 ha publicado la Resolución de 10 de septiembre de 2020, del Congreso de los Diputados, por la que se ordena la publicación del Acuerdo de derogación del Real Decreto-ley 27/2020, de 4 de agosto, de medidas financieras, de carácter extraordinario y urgente, aplicables a las entidades locales.

Al derogarlo, deja sin efecto:

  • la modificación de los arts. 44.1, 46.4, 47.d) y la disposición adicional 1 del Real Decreto-ley 25/2020, de 3 de julio (Ref. BOE-A-2020-7311).
  • la prórroga, en la forma indicada, de la aplicación del art. 9 del Real Decreto-ley 19/2020, de 26 de mayo (Ref. BOE-A-2020-5315).
  • la prórroga, de lo indicado del art. 8 hasta el 31 de octubre de 2020, y la actualización del anexo del Real Decreto-ley 15/2020, de 21 de abril (Ref. BOE-A-2020-4554).
  • la modificación del art. 20.2 del Real Decreto-ley 11/2020, de 31 de marzo (Ref. 2020/4208) (Ref. BOE-A-2020-4208).
  • la modificación del art. 5 del Real Decreto-ley 6/2020, de 10 de marzo (Ref. BOE-A-2020-3434).
  • la transposición parcial de la Directiva (UE) 2019/692, de 17 de abril (Ref. DOUE-L-2019-80763).
  • la modificación de la disposición final 7 de la Ley 39/2015, de 1 de octubre (Ref. 2015/10565) (Ref. BOE-A-2015-10565).
  • la ampliación de lo indicado del art. 10 para el año 2020, del Real Decreto 1103/2014, de 26 de diciembre (Ref. BOE-A-2014-13672).
  • la modificación de las disposiciones adicionales 2.3 y 10 de la Ley 3/2013, de 4 de junio (Ref. 2013/5940) (Ref. BOE-A-2013-5940).
  • la prórroga de la disposición adicional 6 de la Ley Orgánica 2/2012, de 27 de abril (Ref. 2012/5730) (Ref. BOE-A-2012-5730).
  • la modificación de la disposición transitoria 1 de la Ley 13/2011, de 27 de mayo (Ref. 2011/9280) (Ref. BOE-A-2011-9280).
  • la suspensión, en la forma indicada para 2020, la aplicación del art. 49.4 de la Ley reguladora de las Haciendas Locales, texto refundido aprobado por Real Decreto Legislativo 2/2004, de 5 de marzo (Ref. BOE-A-2004-4214).
  • la modificación del art. 13 de la Ley 59/2003, de 19 de diciembre (Ref. (Ref. BOE-A-2003-23399).
  • la modificación del art. 54.2 de la Ley 47/2003, de 26 de noviembre (Ref. BOE-A-2003-21614).
  • la modificación de los arts. 58, 63 quater, 71 y la adición del art. 71 bis y la disposición adicional 37 a la Ley 34/1998, de 7 de octubre (Ref. BOE-A-1998-23284).
  • la modificación del art. 45.I.B) de la Ley del Impuesto sobre Transmisiones Patrimoniales y Actos Jurídicos Documentados, texto refundido aprobado por el Real Decreto Legislativo 1/1993, de 24 de septiembre (Ref. BOE-A-1993-25359).

De los aspectos que se tratan preferentemente en este blog cabe indicar que se han cancelado los siguientes cambios:

(…)

Disposición final cuarta. Modificación de la Ley 59/2003, de 19 de diciembre, de firma electrónica.

Se añade un nuevo apartado 6 al artículo 13 de la Ley 59/2003, de 19 de diciembre, de firma electrónica, con el siguiente tenor:

«6. Por Orden de la persona titular del Ministerio de Asuntos Económicos y Transformación Digital se determinarán las condiciones y requisitos técnicos aplicables a la verificación de la identidad y, si procede, otros atributos específicos de la persona solicitante de un certificado cualificado, mediante otros métodos de identificación que aporten una seguridad equivalente en términos de fiabilidad a la presencia física.»

(…)

Disposición final sexta. Modificación de la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas.

Se modifica la disposición final séptima de la Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas, que queda redactada como sigue:

«Disposición final séptima. Entrada en vigor.

La presente Ley entrará en vigor al año de su publicación en el «Boletín Oficial del Estado».

No obstante, las previsiones relativas al registro electrónico de apoderamientos, registro electrónico, registro de empleados públicos habilitados, punto de acceso general electrónico de la Administración y archivo único electrónico producirán efectos a partir del día 2 de abril de 2021.»