Archivo de la categoría: Firma Electrónica

Amadeus cytric Travel & Expense – Digitalización Certificada


cytric_LogoAmadeus cytric Travel & Expense es una plataforma global para gestión de viajes y gastos orientado a dar servicio a grandes empresas que facilita a los empleados de estas entidades, que viajan por necesidades de negocio, la gestión de forma rápida y sencilla de sus gastos de viaje.

La plataforma permite la reserva online flexible para vuelos, trenes, habitaciones de hotel, alquiler de coches, taxis y traslados, incluida una gama completa de familias de tarifas aéreas y servicios complementarios.

Integra las transacciones realizadas con tarjeta de crédito en el proceso de capturar y revisar los tickets, facturas simplificadas y facturas completas, con una experiencia de usuario sencilla y rápida, que permite presentar hojas de gastos sin demora y agilizar su cobro teniendo en cuenta los recibos y las dietas, según el marco fiscal aplicable al viajero, así como las reglas de negocio propias de su empresa.

Con la aplicación de móvil de cytric, los empleados de una empresa que tienen que viajar, pueden buscar y reservar viajes y alojamientos, revisar sus itinerarios, presentar sus gastos online, acceder a contactos y servicios locales, obtener recibos de gastos, y aprobar o rechazar solicitudes de viajes y de reembolso de gastos.

Optimiza el flujo de trabajo de la agencia de viajes de negocios seleccionada con reglas de validación, registros de auditoría, notificaciones, recordatorios e hilos de discusión automatizados que ayudan a todos los roles involucrados en el proceso de viaje, incluidos viajeros, autorizadores, auditores y contables.

Amadeus ha confiado en EADTrust para realizar la auditoría de Digitalización Certificada de su solución cytric Travel & Expense – Certified Digitization Engine y la ha presentado a la Agencia Tributaria que resolverá sobre la concesión de la Homologación a la plataforma. Un equipo multidisciplinar coordinado con profesionales situados en varios países ha dado forma a un motor de digitalización integrado en la plataforma que permite cumplir con todos los requisitos de la Norma EHA/962/2007 de 10 de abril y la Resolución de 24 de octubre de 2007 de la Agencia Estatal de Administración Tributaria española.

 

Certificados de prueba #eIdAS para #PSD2


Hace ya algún tiempo traté sobre los certificados que se podrían usar en el contexto de PSD2, en el artículo “Directiva PSD2 y certificados #eIdAS de Proveedores de Servicios de Pago

Todavía antes (en 2017) traté temas técnicos (algunos controvertidos) de PSD2 en el artículo “Segunda directiva de servicios de pago (PSD2) y Regulatory Technical Standards

PSD2-PI-AI-Card

Ahora ya hay más información y sabemos como se codificarán las Autoridades Nacionales Competentes en los certificados de los prestadores delos diferentes servicios definidos en PSD2:

i) Servicios de cuenta (PSP_AS) que proporcionan las entidades financieras actuales;
ii) Servicios de iniciación de pagos (PSP_PI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y ordenando transferencias en su nombre;
iii) Servicios de información de cuentas (PSP_AI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y recogiendo las transacciones de varias entidades para presentarlas al cliente de formas más interesantes o útiles;
iv) Servicios de expedición de instrumentos de pago basados en tarjetas (PSP_IC), para emisión de servicios equivalentes a tarjetas virtuales o adquirencia de transacciones de pago de tarjetas.

La lista de entidades es

Code Country Authority Title
AT-FMA Austria Austria Financial Market Authority
BE-NBB Belgium National Bank of Belgium
BG-BNB Bulgaria Bulgarian National Bank
HR-CNB Croatia Croatian National Bank
CY-CBC Cyprus Central Bank of Cyprus
CZ-CNB Czech Czech National Bank
DK-DFSA Denmark Danish Financial Supervisory Authority
EE-FI Estonia Estonia Financial Supervisory Authority
FI-FINFSA Finland Finnish Financial Supervisory Authority
FR-ACPR France Prudential Supervisory and Resolution Authority
DE-BAFIN Germany Federal Financial Supervisory Authority
GR-BOG Greece Bank of Greece
HU-CBH Hungary Central Bank of Hungary
IS-FME Iceland Financial Supervisory Authority
IE-CBI Ireland Central Bank of Ireland
IT-BI Italy Bank of Italy
LI-FMA Liechtenstein Financial Market Authority Liechtenstein
LV-FCMC Latvia Financial and Capital Markets Commission
LT-BL Lithuania Bank of Lithuania
LU-CSSF Luxembourg Commission for the Supervision of Financial Sector
NO-FSA Norway The Financial Supervisory Authority of Norway
MT-MFSA Malta Malta Financial Services Authority
NL-DNB Netherlands The Netherlands Bank
PL-PFSA Poland Polish Financial Supervision Authority
PT-BP Portugal Bank of Portugal
RO-NBR Romania National Bank of Romania
SK-NBS Slovakia National Bank of Slovakia
SI-BS Slovenia Bank of Slovenia
ES-BE Spain Bank of Spain
SE-FINA Sweden Swedish Financial Supervision Authority
GB-FCA United Kingdom Financial Conduct Authority

Las URLS de las NCA (National Competent Authorities) Autoridades Naciones Competentes se ven en la siguiente lista:

Country Competent authority
Austria Financial Market Authority
Belgium National Bank of Belgium
Bulgaria Bulgarian National Bank
Croatia Croatian National Bank for credit institutions and Croatian Financial Services Supervisory Agency for investment firms
Cyprus Central Bank of Cyprus
Czech Republic Czech National Bank
Denmark Finanstilsynet
ECB (SSM) European Central Bank (SSM)
Estonia Financial Supervision Authority
Finland Finanssivalvonta (Fin-FSA)
France Autorité de contrôle prudentiel et de Resolution
Germany BaFin and Bundesbank
Greece Bank of Greece
Hungary Central Bank of Hungary
Iceland Financial Supervisory Authority
Ireland Central Bank of Ireland
Italy Banca d’Italia
Latvia Financial and Capital Market Commission
Liechtenstein Financial Services Authority
Lithuania Bank of Lithuania
Luxembourg Commission de Surveillance du Secteur Financier
Malta Malta Financial Services Authority
Netherlands De Nederlandsche Bank
Poland Polish Financial Supervision Authority
Portugal Banco de Portugal
Romania National Bank of Romania
Slovakia National Bank of Slovakia
Slovenia Bank of Slovenia
Spain Banco de España
Sweden Finansinspektionen
UK Prudential Regulation Authority and Financial Conduct Authority

Con la novedad de que ya se pueden introducir guiones en el campo organizationIdentifier que mencioné en el artículo “Resuelto uno de los frenos a los certificados cualificados de PSD2” ya se pueden emitir certificados cualificados extended validation para las diferentes entidades que operan en el despliegue de PSD2.

Algunos Prestadores de Servicios de Certificación ya se están preparando para emitirlos (inicialmente, certificados de prueba) y en TCAB ya estamos listos para auditarlos. Llámenos al  91 388 0789

Resuelto uno de los frenos a los certificados cualificados de PSD2


EIDAS-CAB-forumEl CAB Forum ha aprobado una modificación del documento “Extended Validation Guidelines” para permitir incluir guiones en el campo rganizationIdentifier (OID 2.5.4.97) de los certificados EV, con lo que los certificados expedidos en el contexto de la norma ETSI TS 119 495 ya no serán incompatibles con las comprobaciones que realizan los navegadores. De esta forma se podrán expedir certificados QWAC para entidades financieras y otras entidades que operan en aplicación de la Directiva (UE) 2015/2366 llamada Segunda Directiva de Pagos (PSD2).

La propuesta SC17 se ha aprobado con 23 votos favorables de entidades emisoras de certificados y 6 de las entidades desarrolladoras de navegadores (comprobadores de certificados).

Votos a favor:

  • Emisores:  Actalis, Buypass, Camerfirma, Certigna (DHIMYOTIS), Certum (Asseco), Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, DigiCert, eMudhra, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy,  SHECA, SSC, SecureTrust (anteriormente Trustwave), TurkTrust.
  • Comprobadores: Apple, Cisco, Google, Microsoft, Mozilla, 360

1 Abstención (Emisores): TrustCor

Con este resultado, se permite la inclusión de información adicional en los certificados EV para cumplir con ciertas regulaciones de la Unión Europea.

La motivación argumentada que dio lugar a la solicitud que se ha votado fue:

  • El Reglamento de la Unión Europea Nº 910/2014 (eIDAS)  define ciertos requisitos reglamentarios para los certificados con un nivel de calidad acordado denominado “Cualificado”. Este reglamento especifica en el Anexo IV los requisitos específicos para “Certificados cualificados para la autenticación de sitios web”, incluida la declaración de que el certificado contendrá: “para personas jurídicas: al menos el nombre de la persona jurídica a la que se expida el certificado y, cuando proceda, el número de registro, tal como se recojan en los registros oficiales;
  • Se entiende que este requisito se relaciona con los atributos validados para la identificación del sujeto del certificado y, por lo tanto, se ajusta mejor al nombre distinguido del sujeto (subject’s distinguished name).
  • En línea con el marco regulatorio, ETSI ha definido una estructura general para llevar “números de registro” en la norma TS 119 412-1 (en la actualidad EN 319 412-1). Ver cláusula 5.1. 4. En ella se utiliza el identificador de organización (organizationIdentifier) de la norma  X.520 dentro del nombre distinguido del  sujeto el propósito de servir como “identificación de una organización diferente del nombre de la organización”. Esto se utiliza para los requisitos de ETSI para llevar los números de registro para certificados, cualificados o de otro tipo.
  • Se considera que este uso de organizationIdentifier es compatible con el propósito principal de los certificados de EV como se indica en la sección 2.1.1 de las Directrices de EV como “otra información desambiguadora”.
  • Un reciente Reglamento delegado de la UE 2018/389 sobre comunicaciones seguras para servicios de pago establece en el artículo 34.2 que para los Certificados de sitio web cualificados (QWAC), el número de registro requerido en eIDAS “será el número de autorización del proveedor de servicios de pago (…) o equivalente [referencia hecha a regulaciones anteriores relacionadas con entidades financieras]”.
  • ETSI ha especificado los requisitos de la norma TS 119 495 para incluir los números de registro relacionados con PSD2 en la estructura general para los números de registro definidos en la citada norma TS 119 412-1 en su cláusula 5.1 .4
  • ETSI se ha esforzado por garantizar y siempre ha intentado que los requisitos relacionados con los certificados de sitios web en el nivel Calificado estén en línea con las pautas de Extended Validation de CA / B Forum.
  • Esta propuesta solo incluye algunos de los Esquemas de registro utilizados en la norma ETSI TS 119 412-1, que tienen reglas de validación claras (NTR, IVA, PSD) que brindan una seguridad razonable de acuerdo con las “EV Guidelines”. Se propone que los IPR (intellectual property rights) para la semántica de este esquema se cedan al CA / B Forum, lo que le permitirá extender aún más el uso del Identificador de la organización (organizationIdentifier) para incluir otros Esquemas de registro (por ejemplo, LEI, Legal Entity Identifier) y las reglas de validación correspondientes, a discreción del CA / B Forum.  Además, cualquier cambio futuro realizado por ETSI a la norma ETSI TS 119 412-1 ya no tendrá impacto adicional en CA / B Forum.
  • Al tomar conciencia de que la interpretación del CA / B Forum de los “Requisitos de EV” en la sección 9.2.8 “Otros Atributos” no estaba en línea con la forma de entenderlos por los expertos de ETSI, este organismo desearía armonizar su interpretación con la de CA / B Forum para reflejar en los certificados diferentes formas de establecer números de registro para PSD2 y otros esquemas de identificación alfanumérica de entidades.

Por otro lado, las preocupaciones específicas del CA / B Forum eran:

  • Los requisitos con respecto a los atributos que se han de incluir en el DN (Distinguished Name) del sujeto deben recogerse de forma explícita en el apartado 9.2.
  • Las organizaciones pueden desear identificar las unidades organizativas dentro de su organización. No está claro si esto está permitido actualmente en las Directrices de EV (ambigüedad similar a la de la sección 9.2.8).
  • Se han argumentado objeciones al uso específico de ETSI del campo Distinguished Name.
  • Los procedimientos para la validación del atributo deben estar claramente establecidos.
  • Puede haber otros usos del campo OrganizationIdentifier  en varias PKI, sin embargo, no se considera un problema. dado que la semántica única que se está especificando para cada identificador, las aplicaciones deben ser capaces de comprender los diferentes usos del campo organizationIdentifier  por diferentes emisores y usuarios. Hay muchas “PKI” diferentes que pueden usar todos los atributos de X.500 de manera diferente y con una validación diferente o sin ninguna validación. Según parece, el WebPKI no ha usado anteriormente este atributo de subjectDN antes para los Certificados de confianza pública (Publicly-Trusted Certificates). Por lo tanto, no hay “conflicto” al usar este atributo en las Directrices EV para Certificados SSL / TLS, y tal vez más adelante para Certificados de Firma de Código EV.
  • Este uso de OrganisationIdentifier debe ser extensible para permitir el uso de otros números de registro asignados por diferentes esquemas de registro. Algunos miembros de CAB Forum han expresado interés en incluir números de registro que no sean para identificar el tipo de sociedad dentro de Certificados EV. Esto está previsto en la propuesta actual.
  • Algunos miembros del CA / B Forum tienen interés en llevar incluir las identificaciones LEI dentro de los certificados del CA / B Forum, pero hasta ahora el esquema de registro LEI no se considera lo suficientemente extendido como para ser reconocido como un esquema de numeración de registro para ser aceptado por el CA / B Forum. Por lo tanto, esta propuesta solo introduce un conjunto limitado de esquemas de registro (a saber, NTR, IVA, PSD) que tienen reglas de validación razonablemente sólidas.
  • Algunos miembros del CA / B Forum han indicado la posible necesidad de múltiples identificadores en el campo “nombre del sujeto”. Sin embargo, esto no se puede lograr utilizando el campo definido en la norma X.520 organizationIdentifier que definió este atributo como “SINGLE VALUE”.

Los cambios aprobados, que se reflejarán el documento “EV Guidelines” son:

  • Agregar a la sección 4 las siguientes definiciones:
    Entidad legal: una organización privada, entidad gubernamental, entidad comercial o entidad no comercial.
    Referencia de registro: un identificador único asignado a una entidad legal (persona jurídica).
    Esquema de registro: un esquema para asignar una referencia de registro que cumple con los requisitos identificados en el Apéndice H. “
  • Cambiar el título de la Sección 9.2 para indicar”Campos de Nombre Distinguido del Sujeto” (Subject Distinguished Name Fields).
  • Eliminar la Sección 9.2.2 y renumerar las secciones 9.2.3 a 9.2.8 como 9.2.2 a 9.2.7.
  • Insertar una nueva sección 9.2.8:
    “9.2.8. Campo identificador de organización del sujeto
    ** Campo de certificado **: organizationIdentifier (OID: 2.5.4.97)
    ** Requerido / Opcional **: Opcional
    ** Contenido **: Si está presente, este campo DEBE contener una referencia de registro para una entidad legal asignada de acuerdo con el Esquema de registro identificado.
    El organizationIdentifier DEBE estar codificado como PrintableString o UTF8String (ver RFC 5280).
    El Esquema de Registro DEBE identificarse utilizando la siguiente estructura en el orden presentado:
    * Identificador de esquema de registro de 3 caracteres;
    * Se utilizará el código de país ISO 3166 de 2 caracteres para la nación en la que opera el Esquema de Registro, o si el esquema se opera globalmente, se utilizará el código ISO 3166 “XG”
    * Para el identificador del Esquema de Registro NTR, si es requerido bajo la Sección 9.2.4, un identificador ISO 3166-2 de dos caracteres para la subdivisión (estado o provincia) de la nación en la que opera el Esquema de Registro, precedido por el signo más “+” ( 0x2B (ASCII), U + 002B (UTF-8));
    * un guión (signo menos) “-” (0x2D (ASCII), U + 002D (UTF-8));
    * Referencia de registro asignada de acuerdo con el Esquema de Registro identificado.Nota: las Referencias de Registro PUEDEN contener guiones, pero los Esquemas de Registro, los códigos de país ISO 3166 y los identificadores ISO 3166-2 no PUEDEN contenerlos. Por lo tanto, si aparece más de un guión en la estructura, el guión más a la izquierda es un separador, y los guiones restantes forman parte de la Referencia de Registro.Como en la sección 9.2.4, la información de ubicación especificada DEBE coincidir con el alcance del registro al que se hace referencia.Ejemplos:
    * NTRGB-12345678 (esquema NTR, Gran Bretaña, cuyo identificador único a nivel de país es 12345678)
    * NTRUS + CA-12345678 (Esquema NTR, Estados Unidos – California, cuyo identificador único a nivel estatal es 12345678)
    * VATDE-123456789 (Esquema de IVA o CIF, Alemania, cuyo Identificador único a nivel de país es 12345678)
    * PSDBE-NBB-1234.567.890 (Esquema de PSD2, Bélgica, con identificador de la NCA (National Competent Authority) por sus siglas NBB, y con identificador único del sujeto asignado por la NCA formado por la secuencia 1234.567.890)

    Los esquemas de registro enumerados en el Apéndice H se reconocen actualmente como válidos bajo estas pautas (“Guidelines”).

    La CA DEBE:
    1. confirmar que la organización representada por la Referencia de Registro es la misma que la organización nombrada en el campo de organización como se especifica en la Sección 9.2.1 dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4;
    2. Verificar además que la Referencia de registro coincida con otra información verificada de acuerdo con la sección 11;
    3. Tomar las medidas adecuadas para desambiguar entre diferentes organizaciones como se describe en el Apéndice H para cada Esquema de Registro;
    4. Aplicar las reglas de validación relevantes al Esquema de Registro como se especifica en el Apéndice H. “

  • Insertar nueva sección 9.8 (renumerar las siguientes secciones según sea necesario):
    9.8. Extensiones de Certificado
    Las extensiones enumeradas en la Sección 9.8 se recomiendan para la máxima interoperabilidad entre los certificados y los navegadores / aplicaciones, pero no son obligatorias en las CA, excepto cuando se indica como “Requerido”. Las CA pueden usar otras extensiones que no están enumeradas en esta Sección 9.8, pero se les recomienda que propongan su inclusión en esta sección de vez en cuando para ayudar a aumentar la estandarización de la extensión en toda la industria.Si una CA incluye una extensión en un certificado que tiene un campo de Certificado que se menciona en esta Sección 9.8, la CA debe seguir el formato especificado en esa subsección. Sin embargo, ninguna extensión o formato de extensión será obligatorio en una CA a menos que se indique específicamente como “Requerido” en la subsección que describe la extensión.9.8.1. Extensión del nombre alternativo del sujeto (Subject Alternative Name Extension)
    ** Campo del certificado: ** _subjectAltName: dNSName_
    ** Requerido / Opcional: ** Requerido
    ** Contenido: ** Esta extensión DEBE contener uno o más nombres de dominio de host que sean propiedad o estén controlados por el sujeto y que estén asociados con el servidor del sujeto. Dicho servidor PUEDE ser propiedad y operado por el Sujeto u otra entidad (por ejemplo, un servicio de alojamiento). Los certificados comodín no están permitidos para los certificados EV.9.8.2. Campo de identificador de organización del foro de CA / navegador
    ** Nombre de la extensión **: _cabfOrganizationIdentifier_ (OID: 2.23.140.3.1)
    ** OID detallado **: {joint-iso-itu-t (2) international-Organizations (23) ca-browser-forum (140) extensiones de certificado (3) cabf-organization-identifier (1)}
    ** Requerido / Opcional **: Opcional (pero ver más abajo)
    ** Contenido **: Si el asunto: organizationIdentifier está presente, este campo DEBE estar presente.

    A partir del 31 de enero de 2020, si está presente el campo sujeto: organizaciónIdentificador, este campo DEBE estar presente.
    Si está presente, este campo DEBE contener una Referencia de Registro para una entidad legal asignada de acuerdo con el esquema de registro identificado.

    El esquema de registro DEBE estar codificado como se describe en la siguiente gramática ASN.1:

    id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= 
    { joint-iso-itu-t(2) international-organizations(23) 
    ca-browser-forum(140) certificate-extensions(3) 
    cabf-organization-identifier(1) }
    
    ext-CABFOrganizationIdentifier EXTENSION ::= 
    { SYNTAX CABFOrganizationIdentifier IDENTIFIED BY 
    id-CABFOrganizationIdentifier }
    
    CABFOrganizationIdentifier ::= SEQUENCE {
    
    registrationSchemeIdentifier   PrintableString (SIZE(3)),
    
    registrationCountry            PrintableString (SIZE(2)),
    
    registrationStateOrProvince    [0] IMPLICIT PrintableString OPTIONAL (SIZE(0..128)),
    
    registrationReference          UTF8String
    
    }
    

    donde están los subcampos y tienen los mismos significados y restricciones descritos en la Sección 9.2.8. La CA DEBE validar el contenido utilizando los requisitos de la Sección 9.2.8 “.

  • Añadir nuevo Apéndice H – Esquemas de registro
    “Los siguientes esquemas de registro se reconocen actualmente como válidos según estas pautas:** NTR **: La información incluida en este campo será la misma que se guardó en el campo Número de registro del sujeto como se especifica en 9.2.5 y el código de país utilizado en el identificador del esquema de registro coincidirá con el de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.
    Cuando la Jurisdicción de constitución de la entidad o el Campo de Registro en 9.2.4 incluya más que el código del país, la información de localidad adicional se incluirá como se especifica en las secciones 9.2.8 y / o 9.8.1.** IVA **: Referencia asignada por las autoridades fiscales nacionales a una entidad jurídica. Esta información se validará utilizando la información provista por la autoridad fiscal nacional contra la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el campo del número de registro del sujeto (ver 9.2.5) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.

    ** PSD **: Número de autorización especificado en ETSI TS 119 495, cláusula 4.4, asignado a un proveedor de servicios de pago y que contiene la información especificada en ETSI TS 119 495 cláusula 5.2.1. Esta información SE DEBE obtener directamente del registro de la autoridad nacional competente para servicios de pago o de una fuente de información aprobada por una agencia gubernamental, organismo regulador o legislación para este propósito. Esta información DEBE validarse comparándola directa o indirectamente (por ejemplo, haciendo coincidir un número de registro único global) con la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el Campo del número de registro del sujeto (ver 9.2.5). ) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4. La dirección indicada de la organización combinada con el nombre de la organización NO SERÁ la única información utilizada para desambiguar la organización “.

Norma del CCN para firma en la nube


CCN-CertificacionLos dispositivos cualificados de creación de firma son necesarios para producir firmas electrónicas y sellos electrónicos cualificados en el contexto del Reglamento 910/2014 (EIDAS).

Dada la lentitud del proceso de publicación en el seno del CEN (Comité Europeo de Normalización) de las normas de evaluación de conformidad de dispositivos cualificados de creación de firma que promovía el Reglamento EIDAS, en su artículo 30, en 2016 el Centro Criptológico Nacional (CCN) impulsó la publicación de una norma propia a lo que le autorizaba el propio artículo 30 en su apartado 3-b.

En efecto, el artículo 30 en su apartado 1 indica:

La conformidad de los dispositivos cualificados de creación de firmas electrónicas con los requisitos que figuran en el anexo II será certificada por los organismos públicos o privados adecuados designados por los Estados miembros.

Y en su apartado 3

La certificación contemplada en el apartado 1 se basará en los elementos siguientes:

a) un proceso de evaluación de la seguridad llevado a cabo de conformidad con las normas para la evaluación de la seguridad de los productos de tecnología de la información incluidos en la lista que se establecerá de conformidad con el párrafo segundo

(…)

La Comisión establecerá, por medio de actos de ejecución, la lista de las normas para la evaluación de la seguridad de los productos de tecnología de la información a que se refiere la letra a). Dichos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.

En abril de 2016 se publicó la DECISIÓN DE EJECUCIÓN (UE) 2016/650 DE LA COMISIÓN de 25 de abril de 2016 por la que se fijan las normas para la evaluación de la seguridad de los dispositivos cualificados de creación de firmas y sellos con arreglo al artículo 30, apartado 3, y al artículo 39, apartado 2, del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo, relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior.

Sin embargo, esta norma solo hacía mención al marco de evaluación Common Criteria (ISO/IEC 15408 — Information technology — Security techniques — Evaluation criteria for IT security (Tecnología de la información — Técnicas de seguridad — Criterios de evaluación para la seguridad de la TI), Partes 1 a 3 y a la norma de perfiles de protección de dispositivos seguros de creación de firma EN 419 211 — Protection profiles for secure signature creation device (Perfiles de protección para los dispositivos seguros de creación de firma, Partes 1 a 6), que pasaba de puntillas sobre los requisitos de firma en la nube (limitado a la parte  EN 419 211-5).

En base a la Directiva 1999/93/CE se había publicado en julio del año 2003 la Decisión 2003/511/CE:de la Comisión, de 14 de julio de 2003, relativa a la publicación de los números de referencia de las normas que gozan de reconocimiento general para productos de firma electrónica, de conformidad con lo dispuesto en la Directiva 1999/93/CE del Parlamento Europeo y del Consejo que permitía contar con dispositivos seguros de creación de firma mientras evolucionaba el marco de normas técnicas de evaluacón de conformidad.

Dado el interés de algunas entidades españolas en certificar dispositivos cualificados de creación de firma (necesarios, por ejemplo, para finalizar el proyecto de DNI en la nube) el Centro Criptológico Nacional publicó en enero de 2017 la norma IT-009 -Remote Qualified Electronic Signature Creation Device Evaluation Methodology.

Esta norma se publicó al amparo del apartado 3-b del artículo 30 de EIDAS:

3.   La certificación contemplada en el apartado 1 se basará en los elementos siguientes:

(…)

b) un proceso distinto del proceso contemplado en la letra a), con tal de que ese proceso haga uso de niveles de seguridad equivalentes y que los organismos públicos o privados a los que se refiere el apartado 1 notifiquen ese proceso a la Comisión. Podrá recurrirse a ese proceso únicamente a falta de las normas a que se refiere la letra a) o cuando esté en curso el proceso de evaluación de la seguridad a que se refiere la letra a).

El documento recoge lo esencial de las normas técnicas en estado borrador en ese momento y posicionó a España en la punta de lanza de la evaluación de conformidad. Debe agradecerse al CCN esta labor proactiva que redunda en la competitividad de las empresas españolas del sector de la seguridad.

Por parte de TCAB (Trust Conformity Assessment Body) fué un privilegio el que pudiéramos colaborar en los trabajos preparatorios previos a la publicación de la norma.

Nuevas normas de ETSI para firmas digitales en la nube


El comité técnico de ETSI sobre Infraestructura de firma electrónica (TC ESI, technical committee on Electronic Signature Infrastructure) acaba de publicar un conjunto de tres Especificaciones técnicas para firmas digitales basadas en la nube que admiten dispositivos móviles: ETSI TS 119 431-1, ETSI TS 119 431-2 y ETSI TS 119 432.

Este nuevo conjunto de estándares promueve la creación de firmas digitales en la nube, lo que facilita la adopción de las tecnologías de firma electrónica al evitar la necesidad de software especializado por parte de los usuarios y la de contar con dispositivos seguros de creación de firma, tales como lectores de tarjeta chip.

El acrónimo TW4S (Trustworthy System Supporting Server Signing) se usa con frecuencia para identificar los entornos de firma electrónica en la nube.

El firmante confía en un servicio de confianza ofrecido por terceros especialistas para administrar su clave secreta de firma electrónica y para firmar digitalmente bajo su control aquellos documentos electrónicos que considere.

Para garantizar que es confiable el entorno de creación de firmas basado en la nube y que la clave privada de firma se usa bajo el control del firmante, el prestador del servicio de firma digital remota debe aplicar procedimientos seguros de gestión y utilizar sistemas y productos confiables, incluyendo canales seguros de comunicación electrónica.

Según Nick Pope, Vicepresidente del comité ESI de ETSI, “este es un gran paso en la seguridad de los despliegues de firmas digitales que tiene en cuenta la tendencia de adopción de servicios basados ​​en la nube y la generalización de los dispositivos móviles. Estas normas permiten una nueva forma de implementar los Servicios de confianza que simplifica enormemente su uso y proporciona un conjunto de herramientas importante para contrarrestar el creciente fraude de Internet dirigido a empresas y organismos”.

Las normas ETSI TS 119 431 partes 1 y 2 definen requisitos de política y seguridad que los organismos de evaluación de la conformidad (Conformity Assessment Bodies) pueden utilizar para certificar que un prestador de servicios de confianza sigue las mejores prácticas para la operación de dichos servicios de creación de firmas basados ​​en la nube, en particular en el contexto del Reglamento eIDAS (UE) 910/2014. Este trabajo de ETSI complementa las publicaciones del Comité Europeo de Normalización, CEN EN 419241-1: 2018 (requisitos generales para sistemas confiables que dan soporte a la firma electrónica en servidor) y EN 419241-2: 2019 (perfil de protección para dispositivos cualificados de creación de firma electrónica (QSCD) para la firma en servidor), que proporcionan los requisitos básicos de la firma electrónica en la nube.

Cloud-signature

La norma ETSI TS 119 432 especifica el protocolo que permite a una aplicación cliente solicitar la creación de una firma digital a un servidor. Esta especificación establece un protocolo para la comunicación segura entre los diferentes componentes necesarios para crear una firma digital segura en la nube, en consonancia con los estándares de seguridad establecidos en el Reglamento eIDAS. Se especifican dos tipos de conexión para implementar este protocolo: XML, que se basa en la especificación OASIS DSS-v2.0, y JSON, que se basa en la especificación del Cloud Signature Consortium (CSC). ETSI colaboró ​​con ambs organismos de normalización, OASIS y CSC para elaborar estas especificaciones de protocolo.

TCAB, Trust Conformity Assessment Body ya está considerando esta nuevas normas para las evaluaciones de conformidad de firma en la nube de sus clientes. Estas normas no están contempladas todavía por ENAC para su uso en la evaluación de servicios cualificados. Para más información, llame a 91 388 0789 

Digital por diseño


Va llegando el momento de abandonar el término “transformación digital” que transmite la idea de que hay que cambiar los procesos de las organizaciones, conforme avanza la digitalización de la sociedad y la adopción masiva de las tecnologías de la información.

Con el estado actual de la tecnología y de la legislación, no tiene sentido diseñar procesos de información, contratación o mero trámite que no estén diseñados desde el principio pensando en el valor probatorio de los registros digitales administrados con ayuda de la criptografía.

En todo caso, cualquier concesión a procedimientos o actuaciones arcaicos debe ser en atención a la experiencia de usuario.

Uno de los aspectos claves del nuevo paradigma es la gestión de la identidad digital de las personas con las que se relacionan las entidades que debería tener en cuenta la posibilidad de acceso de personas de diversa procedencia y medios de identificación.

Las “piezas de lego” que facilitan la gestión digital por diseño de los procedimientos preservando la seguridad jurídica son componentes como las firmas electrónicas de persona, los sellos electrónicos de empresa, los sistemas de conservación digital de documentos electrónicos (incluso con códigos seguros de verificación) y evidencias electrónicas, los sellos de tiempo electrónicos, los sistemas de gestión de información de representación (de otras personas o de empresas) los sistemas que permiten comprobar la validez de las firmas y de los sellos, los que permiten gestionar mecanismos de identificación y de firmas y sellos “en la nube”, los que permiten realizar la digitalización certificada de documentos, los que permiten la identificación remota co y los que permiten acreditar las notificaciones electrónicas.

En la actualidad. el Reglamento (UE) Nº 910/2014, de 23 de julio, relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior (eIDAS), ofrece una buena base para construir sistemas digitales con valor legal admisibles en todos los países miembros, sea cual sea el país de origen, de entre los europeos.

Un aspecto clave en la digitalización por diseño es que la experiencia de usuario debe ser una de las principales prioridades en el diseño de los procesos, para evitar repetir errores de usabilidad  que en el pasado no contribuyeron a poner en valor tecnologías como el DNI electrónico, que se expide desde 2006.

El despliegue de sistemas digitales de gestión debería preservar principios esenciales como el “soporte duradero” o la “simetría probatoria” (igualdad de armas) para que los usuarios de las plataformas cuenten con la misma posición respecto a la prueba digital que los promotores de las plataformas.

El conocimiento técnico y legal de estos principios de despliegue digital ayudará a las entidades a diseñar sistemas digitales eficientes, sencillos y con valor probatorio por lo que es útil contar con especialistas a los que consultar.

Los sistemas de gestión de identidad disponibles ya contemplan la interoperabilidad entre países con “nodos eIDAS” como el español que se instancia a través del sistema “Cl@ve“.

 

Lightweight Online Certificate Status Protocol (OCSP) en entornos de alto volumen de certificados


OCSPEl Protocolo de consulta en linea del estado de certificados (Online Certificate Status Protocol – OCSP) permite determinar el estado de vigencia o revocación de los certificados digitales sobre los que se consulta, como mecanismo alternativo al uso de listas de revocación de certificados (Certificate Revocation List – CRL).

Desde su definición en 1999, se ha desplegado en múltiples entornos y ha demostrado su utilidad hasta el punto de que se ha convertido en el mecanismo preferido de verificación de vigencia de certificados establecido en el Reglamento EIDAS.

En efecto, el  Art 24 indica:

(…)

3.   Cuando los prestadores cualificados de servicios de confianza que expidan certificados cualificados decidan revocar un certificado, registrarán su revocación en su base de datos de certificados y publicarán el estado de revocación del certificado oportunamente y, en todo caso, en un plazo de 24 horas después de la recepción de la solicitud. La revocación será efectiva inmediatamente después de su publicación.

4. Con respecto a lo dispuesto en el apartado 3, los prestadores cualificados de servicios de confianza que expidan certificados cualificados proporcionarán a cualquier parte usuaria información sobre el estado de validez o revocación de los certificados cualificados expedidos por ellos. Esta información deberá estar disponible al menos por cada certificado en cualquier momento y con posterioridad al período de validez del certificado en una forma automatizada que sea fiable, gratuita y eficiente.

Un servidor OCSP debe responder en “tiempo real”, generando una respuesta de información de vigencia por cada consulta relativa a un certificado.

A medida que el uso de tecnologías PKI continúa creciendo y cubre nuevos requerimientos, la necesidad de comprobar la vigencia de los certificados debe adaptarse a nuevos escenarios.

Al pensar en despliegues de dispositivos ubicuos en contextos de IoT (Internet de las cosas) con menores capacidades de proceso y quizá menor ancho de banda  se requiere un uso cuidadoso de OCSP para minimizar el uso de ancho de banda y la complejidad de procesamiento del lado del cliente. Si a eso se añade que pueden existir millones o cientos de millones de certificados expedidos para otros tantos dispositivos, el potencial consumo de ancho de banda destinado a OCSP cuando las entidades que confían en los certificados consultan su validez hacer recomendable contar con mecanismos optimizados. De ahí la conveniencia de contar con una versión ligera de OCSP que con el tiempo pueda ser adoptada por los diferentes intervinientes en estos contextos de despliegues masivos de certificados.

Estas consideraciones han dado lugar a la publicación del estándar RFC 5019, que simplifica el protocolo OCSP manteniendo la compatibilidad con versiones anteriores.