Implantación de @firma y TL Manager

Laura Cabezas

•Parte I. Suite @firma•Parte II. TL Manager

2

Indice

• Identificación/autenticación: Acreditar la identidad de la persona.• Datos de identidad :¿Qué información? NUMERO DE IDENTIFICACION (DNI,

CEDULA…) + Nombre y Apellidos

• Univoco. • Unos datos siempre corresponden a una sola persona

• Una persona solo tiene un conjunto de datos que la identifican. (no puede aparecer duplicada en los registros, mediante aportación de distintos datos)

• Firma: Acreditar la voluntad de la persona.

USO DE LA SUITE @FIRMA

•@firma- VA para la identificación y Autenticación de ciudadanos con certificados electrónicos.

•Otros elementos de la Suite @firma

•@firma- VA para la validación de la firma realizada por el ciudadano y verificación de esa firma.

•@firma- VA para el Upgrade de firma

•Otros

4

USO DE LA SUITE @FIRMA

I*Net

Consulta

CRL/OCSP3

Prerrequisitos de las aplicaciones de AE:

- Haberse previamente configurado en @firma.

- Disponer de herramientas para recoger la firma del ciudadano (ej Autofirma)

1- El ciudadano se conecta a una página web de la Administración, donde usa su certificado (para autenticarse o firmar).

2- La aplicación envía esa firma a @firma, para que verifique

3 y 4- @firma se conecta con el PSV para recuperar las evidencias de validación

5- @firma responde a la aplicación de AE: OK o firma invalida.

6- La aplicación de AE continua el trámite

PSCPSC

PSCPSC

PSCPSC

...

OCSP

HTTPS

LDAP

Organismospúblicos

Ciudadanosy Empresas

Acceso a

servicios1

Solicitud

validación2

Verif. Firma/

Autenticación6

I*Net

intranet

Funcionamiento de la Suite

PSCs

Respuesta5

CRL /OCSP4

• Busca el certificado en la Política de Certificados, en base a un discriminador (normalmente el OID del certificado, pero se puede establecer otro).

• Si lo encuentra, le aplica la configuración (mapeos de los campos del certificado; CRL indicada, en caso de que haya una, en el orden especificado, o si no lo busca en el DP o AIA…)

• Si no lo encuentra, lo busca en la TSL, acorde a un mapeo estándar.

6

Funcionamiento @firma-VA

El certificado esta en la Política?

Aplica mapeos, CRL/OCSP, tipo de certificado…

Busca en los campos estándar

El certificado esta en la

TSL? Rechaza el certificado

SI

SI

NO

NO

Dos modos de funcionamiento

1. Funcionamiento por Políticas de confianza. • Una o varias

• Discriminador

• Mapeos de los campos de los certificados. Libertad en cuanto a estructura de los certificados.

• CRL/OSCP no identificadas en los certificados.

• Clasificación de los certificados, ad hoc. EJ: Certificado de representante de persona jurídica, certificado de empleado público, certificado de sello automatizado, etc.

- Se asocian a aplicaciones- Se exportan

1- Por políticas de certificados

8

Administración. Políticas de Certificación.

• Exportación /Importación de Política de Certificación.

@firma Central

@firma Federado

2- Funcionamiento por TSL en @firma-VA. • ETSI TS 119 612 V2.1.1• Necesario configurar las URL de las TSL a

buscar (@firma las busca periódicamente y avisa de que se han actualizado)

• Para obtener información de la revocación y verificar el certificado, es necesario que los certificados tengan informado en Distribution Point (DP) o Autority Information Access (AIA).

• Se busca la información de identidad y los puntos de verificación de la revocación en base a unos patrones estándar, no configurables por PSC.

• Es necesario que los campos de identidad (nombre, apellidos, número de identificación personal) estén homogéneos en todos los certificados de esa TSL.

9

2- Por TSL

10

Administración. Gestión de TSLs.

•Menu ‘Gestión de TSLs.’ • Hay que dar previamente el certificado de confianza de las TSL para que la plataforma confíe en el.• Gestión de almacenes de

confianza

• Gestión de campos lógicos estándar. Se define un Certificado Patrón por TSL.

• Comparador de la TSL con las políticas de certificación

• PSC.• Métodos de validación.

• Si el PSC requiere autenticación para acceder a sus métodos de validación.

• Método de validación web service (@firma federadas)

• Orden de consulta de los métodos de validación

• Timeout.

• Verificación de la firma de la CRL/OCSP del PSC.• Certificados de firma de respuestas

• Caducidad y revocación de los certificados de firma de respuestas

• Cache de CRL – cache de nivel 2 (optativo)

Otras funcionalidades de @firma solo si NO se usa TSL

3- Configuración de @firma- por políticas

12

Administración. Gestión de PSCs.

• Gestión de Prestadores de Servicio de Certificación (PSC).

Gestión del Árbol de Prestadores de

Servicios de Certificación (PSC).

Gestión de los distintos tipos de

certificados por cada PSC

13

Administración. Métodos de Validación.

• Gestión de Métodos de Validación.

• HTTP/S, LDAP, FTP.

• Delta CRL

CRLs / ARLs

• HTTP/S

• Firma de peticiones

• Compatible con OCSP @firma

OCSP

• Delegación en otra plataforma federada

WS

Optimización de la verificación•Cache de nivel 1.• Configurable por administración.

• Breve.

•Cache de nivel 2.• Almacenamiento mas largo.

14

Cache

15

Administración. Políticas de Certificación.

• Gestión de Políticas de Certificación.

Tipo de Certificado

Método de Validación

Certificado Patrón

Configuración Mapeo

16

4- Configurar organismos y aplicaciones usuarias • Permite agrupar las aplicaciones por unidades organizativas en estructura Jerárquica.

Ministerio 1

Secretaria de Estado 1.1

Aplicación 1.1.1

Aplicación 1.1.2

Aplicación 1.1.3

Secretaria de Estado 1.2

Aplicación 1.2.1

Organismos dependiente 1.3

Aplicación 1.3.1

Ministerio 2

Aplicación 2.1 Aplicación 2.2

Aplicación 3

• Cada aplicación tiene asociado:• un ID de aplicación.• Responsables (datos de contacto)• Método de autenticación…Password/certificado.• Si se firma o no la respuesta de @firma.• Política de certificación• Política de validación de firma• Política de custodia (Si se custodia o no la

respuesta)• Habilitar o deshabilitar servicios de la plataforma.

• Si esta habilitado Firma en Servidor – que certificado se usa

• Si se usa upgrade – que TSA se usa (si es distinto de la configuración general de TSA)

• Deshabilitar TSL.

Configuración de aplicaciones

17

Administración. Gestión de Aplicaciones.

• Gestión de Aplicaciones y Unidades Organizativas.

• Estructura Jerárquica

• Configuración a nivel de aplicación:• Métodos de Autorización.

• Servicios disponibles.

• Política de Certificación.

• Política de Custodia, etc.

18

Nodos de Administración / Nodos de Servicio

@firma – Servicio

@firma – Servicio

@firma – AdministraciónUsuarios Administradores

AP

LICA

CIO

NES

Usuarios Servicios

Autofirma

Integr@

Responsables TSL

TSL

TSLs

PSCs

Time Stamping

19

Administración. Gestión de Usuarios.

• Gestión de los usuarios administradores de la plataforma

• Contraseñas seguras

• Bloqueo de usuarios tras varios intentos fallidos

• Acceso a la Administración:• Con certificado• Con usuario /contraseña

• BBDD de Emergencia

• Parámetros Generales• Gestión de Alarmas: resúmenes, correos…

• Configuraciones estables…

• Gestión de almacenes de confianza (de todos los certificados de autenticación: respuestas PSC, identificación de aplicaciones, etc)

• Proxi

• Gestión de tareas.

• Modulo de auditoria. Ver las trazas del sistema

• Estadísticas (modulo Pentaho)• opcional

Otras configuraciones @firma

•@firma- VA para la identificación y Autenticación de ciudadanos con certificados electrónicos.

•Otros elementos de la Suite @firma

•@firma- VA para la validación de la firma realizada por el ciudadano y verificación de esa firma.

•@firma- VA para el Upgrade de firma

•Otros

21

USO DE LA SUITE @FIRMA

• Integrar firma con certificados en pag. Web, mediante JavaScript.• Es una aplicación de escritorio (Autofirma), invocable mediante JavaScript.

• Compatibilidad con :

• Sistemas Operativos de escritorio: Windows, Linux y Mac.• Navegadores: Firefox, Internet Explorer, Chrome y Safari.

• S.O. móviles: Android e IOS• javascrip + firm@movil

• JRE: Versiones hasta Java 9.

• Almacenes:

• Repositorio de Windows/Internet Explorer,

• Repositorio de Mozilla/Firefox,

• PKCS#12, Certificados en disco,

• Tarjetas inteligentes, Tokens USB

Software libre• https://github.com/ctt-gob-es/clienteafirma

• Firmar el ejecutable con un certificado de firma de software del país.

• Otros enlaces a Github relacionado con Autofirma:• https://github.com/ctt-gob-es/clienteafirma• https://github.com/ctt-gob-es/clienteafirma-docs• https://github.com/ctt-gob-es/jmulticard• https://github.com/ctt-gob-es/clienteafirma-external

• Enlaces a Github relacionado con FIRe:• https://github.com/ctt-gob-es/fire• https://github.com/ctt-gob-es/fire-doc

23

Ciudadanosy Empresas

internet

OrganismosPúblicos

• Debe estar instalada previamente.• Conviene una página que haga de centro de descargas de Autofirma, con la

última versión disponible.

• Integración en cada una de las aplicaciones.• Otra opción: FIRe, que facilita la integración con las aplicaciones.

23

Aplicación JavaScript enNavegador Web Móvil oNavegador

Aplicaciónde Firma

1

Servidor web

FIRe• Para los integradores:

• Integrar la firma en las aplicaciones de forma transparente.

• Mantenimiento de versiones de forma sencilla.

• Facilitar el despliegue de las soluciones de firma

Para el ciudadano:UsabilidadExperiencia de uso homogénea independiente del dispositivo

Firma en PC/móvil (ej Autofirma), requiere: - Integrar el javascript en la aplicación.- Controlar la necesidad de descargar Autofirma- Instalar el servidor intermedio/servidor trifásico. - Actualizar muchos elementos con cada nueva versión del software

@firma

Organismo 1

Aplicación 1

Aplicación 2

Aplicación 3

Organismo 2

Aplicación 1API Firma

Aplicación 2

Aplicación 3

API Firma

API Firma

API Firma

API Firma

API Firma

ComponenteCentral Fire

ComponenteCentral

Organismo 1

Aplicación 1

Aplicación 2

Aplicación 3

API Firma

API Firma

API Firma

ComponenteCentral Fire

@firma

• Funciones:

• La aplicación solicita realizar firma (o firma de lotes) en FIRe a través del API.

• Utilizarse los certificados locales. (Ampliable a certificados en la nube)

• Delega todas las funciones de

firma en el servidor FIRe:

• selección de certificados

• Acciones de firma

Solicitud de Firma

ORGANISMO PÚBLICO

Datos a firmar FIRe Servidor

Componente de Firma

Miniapplet + Autofirma

DOCUMENTO

Id

Librerías PHP, JAVA, .NET

Servicio JAVA

3

1

4

5 Selección del certificado

Páginas Web FIRe

6

Firmar

8

Hash

9

Hash “firmado”

Prefirmar

7

Postfirmar

10

FIRe. API

Aplicación WEB

2 11 Firma electrónica

• Librería de clases java, configuración y plantillas xml.

• Facilitan integración con @Firma

• Validación de certificados y firmas

• Upgrade a formatos longevos.

• Firma automatizada en servidor:

• CAdES, XAdES, PAdES.

• Múltiples firmantes

• SW libre EUPL.• https://github.com/ctt-gob-es/integra

INTERNET

INTRANET

•@firma- VA para la identificación y Autenticación de ciudadanos con certificados electrónicos.

•Otros elementos de la Suite @firma

•@firma- VA para la validación de la firma realizada por el ciudadano y verificación de esa firma.

•@firma- VA para el Upgrade de firma

•Otros

29

USO DE LA SUITE @FIRMA

Firma y verificación

• Elementos implicados: Igual que el caso anterior: (Autofirma +) @firma (+ integr@)

• Configuraciones adicionales:• (Opcional) Se pueden establecer políticas de firma, asociadas a

contextos funcionales (ej: Firma de facturas electrónicas). OJO. Complicado de gestionar. Para empezar, se recomienda no usar políticas de firma.• Se pueden establecer:

• formatos admitidos,

• certificados admitidos (solo de persona física, o solo jurídica, etc),

• periodos de guarda...

30

Configuraciones @firma

FAMILIA ASN.1- formatos binarios– PKCS#7, CMS: Cryptographic Message Syntax

• Recomendación del IETF, RFC 2630, 3852.

– CAdES: CMS Advanced Electronic Signatures• Normalizado por ETSI TS 101 733 y actualizaciones.• Permite incorporar: time-stamps, certificados de atributos, indicaciones de responsabilidades asumidas al

firmar, etc). Asegura la longevidad de las firmas.• Múltiples versiones. CAdES 1.6.3, 1.7.3, 1.7.4, 1.8.1, 1.8.3, 2.1, y Baseline Profiles

FAMILIA XML- formatos xml– XMLdsig: XML Signature

• W3C y RFC 3275

– XAdES: XML Advanced Electronic Signatures• Estandarizado por ETSI TS 101 903 y actualizaciones• Permite incorporar: time-stamps, certificados de atributos, indicaciones de responsabilidades asumidas al

firmar, etc). Asegura la longevidad de las firmas• Múltiples versiones. XAdES 1.2.2, 1.3.2, 1.4.1, 1.4.2, Baseline Profiles…

FAMILIA PDF– Firma PAdES: PDF Advanced Electronic Signatures

• Estandarizado por ETSI TS 102 778 y actualizaciones• Permite incorporar información a la firma básica PDF: time-stamps, etc. Asegura la longevidad de las firmas• Múltiples versiones.

Para información detallada: ‘@Firma-EstandaresSoportados.pdf’

Formatos de firmas soportados:

• EPES: Incorporación de política de firma electrónica a las firmas básicas

• BES: Firma con formato básico, incluyendo los atributos necesarios para la firma-e

• T (timestamp): añade sello de tiempo

• C (completo): añade referencias a datos de verificación (certificados y listas de revocación) a los documentos firmados para permitir la verificación fuera de línea y la verificación longeva

• X (extendido): añade sellos de tiempo en las referencias introducidas por el formato -C para proteger contra el posible compromiso de validez en el futuro

• XL (extendido longevo): añade certificados y listas de revocación al documento firmado para permitir la verificación en el futuro, incluso si su fuente original no estuviera disponible

• A (archivo): añade la posibilidad de re-sellado de tiempo periódico del documento archivado para prevenir el compromiso causado por la debilidad de los algoritmos de firma con el tiempo.

Formatos de firmas longevos:

• Múltiples formas de conformar la firma de documentos.

• Recrean las situaciones de firma que se dan con la firma manuscrita.

• Relación entre las firmas y documentos:a. Independientes o cofirma/firma paralelo

• Se firma un documento por varios firmantesb. Cascada o contrafirma

• Se firma la firma anterior (refrendo)

Multifirmas:

Procedimiento de verificación:

El c

erti

fica

do

est

a re

con

oci

do

en

el

paí

s

Val

idez

(n

o r

evo

caci

ón

) d

el

cert

ific

ado

Ob

tien

e lo

s d

ato

s d

e id

enti

dad

d

el f

irm

ante

.

Val

idez

cri

pto

gráf

ica

de

la f

irm

a

Val

idez

aco

rde

a la

Po

lític

a d

e fi

rma

La c

orr

ecci

ón

de

la e

stru

ctu

ra d

e la

fir

ma

aco

rde

a lo

s es

tán

dar

es.

Niv

el d

e la

fir

ma

(lo

nge

vid

ad)

al

men

os

el in

dic

ado

Procedimiento de verificación:

• Si el certificado esta en una política de certificados o en la TSL

Verifica que el certificado esta

reconocido en el país

• contra la CRL/OCSP.

Verifica la validez del certificado • que se extraen del

certificado, en base a las políticas de certificados (mapeos).

Obtiene los datos de identidad del

firmante.

• Validez criptográfica, acorde a los datos incluidos en la firma.

Verifica la validez de la firma electrónica,

• se verifica que la firma cumple las restricciones de la política de firma (por ejemplo en cuanto a formatos admitidos: XADES; PADES…

Si la firma está asociada a una política de firma,

• Para los formatos de firma aceptados.

La corrección de la estructura de la firma

acorde a los estándares. • los PSC de los certificados de firma y de Sello de tiempo deben estar configurados en @firma (en la política de certificados), o en las TSL

En las firmas longevas, que incluyen información

de validación,

• Política de validación de firma:• Result mayor + result minor.• Necesario. Se puede definir solo una• Se configura en un fichero de properties

Configuraciones necesarias @firma

Firma y verificación

•@firma- VA para la identificación y Autenticación de ciudadanos con certificados electrónicos.

•Otros elementos de la Suite @firma

•@firma- VA para la validación de la firma realizada por el ciudadano y verificación de esa firma.

•@firma- VA para el Upgrade de firma

•Otros

37

USO DE LA SUITE @FIRMA

• DSSAfirmaverify también permite upgrade de firma.

• No requiere configuración adicional.

Extensión de la longevidad una firma.

38

Se verifica la firma

Error

Es posible el upgrade

Upgrade

Incorrecta

SI

Correcta

NO

39

Administración. Gestión de TS@.

• Gestión de Plataformas de Sellado de Tiempo.

• Configurar TSA• Necesario para las

firmas longevas

• Multi-TS@• Orden• timeouts

• Integración• RFC 3161• XML Timestamping

Profile

Documento nº: @Firma-Global-Firma-MAN

•@firma- VA para la identificación y Autenticación de ciudadanos con certificados electrónicos.

•Otros elementos de la Suite @firma

•@firma- VA para la validación de la firma realizada por el ciudadano y verificación de esa firma.

•@firma- VA para el Upgrade de firma

•Otros

41

USO DE LA SUITE @FIRMA

- Firma con sello de órgano – Integr@

- Firma de empleado público – Port@firmas

Integración con @Firma -llamadas a

los WS @firma.

Firma, cofirma y contrafirma con varios formatos.

• Securizar peticiones y validar las respuestas firmadas.

• Parseo de las respuestas de los WS.

• Firma de sistemas automatizados.

• Sello electrónico.

Firmas de sistemas automatizados.

2 funciones:

Funcionalidad de firma en servidor

• Permite incorporar las firmas electrónicas a los flujos de trabajo

• Dos formas de uso;• Manual – como un correo electrónico• Automático- con WS que reciben peticiones de firma de los procesos

administrativos

Firmas por empleados públicos.

Peti

cio

nes

de

firm

a

Ver

ific

acio

n

firma

firma

• Incluye Autofirm@, para la firma en escritorio

• Incluye una APP para la firma en dispositivos Móviles Android e iOS.

• SW libre:• https://administracionelectronica.gob.es/ctt/portafirmas/descargas

• https://github.com/ctt-gob-es/portafirmas-proxy

• https://github.com/ctt-gob-es/portafirmas-android

• https://github.com/ctt-gob-es/portafirmas-ipad

• https://github.com/ctt-gob-es/portafirmas-ios

Firmas por empleados públicos.

•Resumen Suite

45

Parte I. USO DE LA SUITE @FIRMA

Suite @firma

Creación

En cliente: javascript +

En escritorio: autoFirm@

En movil: Firm@Movil

En servidor -> Integr@

Validación

@firma (+Integr@)

• TL Manager

47

Parte I. USO DE LA SUITE @FIRMA

• TL Manager.• El Organismo Supervisor (o la entidad certificadora raíz), usa el TL Manager

para crear la lista de CA roots y subCAs que están aprobadas en el país.• El resultado es un fichero XML (la TSL), que se publica en web.• El Supervisor se encarga de actualizarlo cuando se producen cambios en las

CAs cualificadas

• La TSL (fichero XML) :• Está firmado por el organismo supervisor• Tiene fecha de caducidad. El organismos supervisor debe publicar otro antes

de su caducidad.• Debe porder consultarse por los interesados.• @firma lo consulta periódicamente, y se descarga la TSL actualziada cada vez

que hay una

TL Manager

INTERNET

Organismo supervisor

TSL 1

TSL 1

Publica

TSL 1

TSL 2

TSL 3

Almacena las TSL de todos los países

TL Manager

50

TL Manager. Descripción

• Herramienta para la edición de TSL acordes al estándar ETSI TS 119 612 V2.1.1.

51

TL Manager. Distribuciones

• TL Manager-noEU (v.5.0) https://ec.europa.eu/cefdigital/wiki/display/TLSO/Trusted+List+Manager+non-EU

• TL Manager EU (v.5.6).

https://ec.europa.eu/cefdigital/wiki/display/TLSO/Trusted+List+Manager

52

TL Manager No-EU. Requisitos Tecnológicos

NexU – 1.22

53

TL Manager No-EU. Repositorio de TSL

• Navegación de la TSL.

• Validación sintáctica.

• Exportación/Importación.

• Firma.

• Comparación entre versiones

54

TL Manager No-EU. Otras Capacidades

• El sistema ofrece las siguientes capacidades adicionales:• Gestión de Usuarios.• Gestión de Certificados.

• Reglas de Validación.• Gestión de los valores definidos para los elementos de las TSLs.• Gestión de Tareas.

• Auditoría• Gestión de Logs

Muchas gracias