#CyberCamp17

Asegurando los API con Criptografía RSA: Más allá del SSL

Tomás García-Merás

Sobre el ponente

Tomás García-Merás Más de diez años trabajando en Administración Electrónica,

principalmente en proyectos de seguridad y firma electrónica. Líder e impulsor de numerosos proyectos de firma electrónica y

criptografía:□ Cl@ve Firma (firma en la nube), AutoFirma (firma local), JMultiCard

(controlador DNIe desarrollado en INTECO/INCIBE), etc.

Impulsor del Software Libre, tanto de su uso como de la generación de software con licencias abiertas.

Actualmente Gerente de Sector Público en atSistemas:□ https://www.atsistemas.com/es

2

Introducción a la criptografía RSA

Todo se basa en dos conceptos simples: El par de claves y las huellas digitales El par de claves: Lo que se cifra con una, solo puede ser

descifrado con la otra (y viceversa).□ La clave privada solo es accesible por el propietario, mientras que la pública

es de libre acceso para todos.□ Si alguien cifra algo con mi clave pública, este contenido solo puede

descifrarse con la privada, que como solo la tengo yo, solo yo puedo descifrar el mensaje: Cifrado de datos

□ Si yo cifro algo con mi clave privada, todo el mundo puede descifrarlo con la pública, lo que es de facto una forma de comprobar que solo yo he podido hacerlo, ya que solo yo tengo esa clave: Firma electrónica.

La huella digital: Un dígito que corresponde unívocamente a un activo digital.

□ Un dígito (hexadecimal) de pequeña longitud (entre 256 y 512 bits típicamente) que identifica a un único binario, que no se puede reproducir a partir de este.

3

Introducción a la criptografía RSA

Par de claves más huellas digitales: Firma Si cifro con mi clave privada la huella digital de un documento…

□ Es una acción que solo yo he podido hacer (solo yo tengo mi clave privada).– NO REPUDIO.

□ Se puede ligar unívocamente a un documento, ya que la huella corresponde a un único documento.

– Adicionalmente, no es posible crear, a partir del valor de una huella digital, un documento coincidente.

□ Además, si el documento se modifica después del cálculo de la huella esta ya no coincidirá.

– INTEGRIDAD DEL DOCUMENTO.

4

Introducción a la criptografía RSA

Un paso adicional: Los certificados electrónicos Estos certificados, emitidos por Prestadores

de Servicios de Certificación (PSC) certificados, asocian una clave pública (y por extensión, una privada) a una identidad concreta.

1. El usuario genera su par de claves (custodiando en secreto la privada).

2. Acude a una Autoridad de Registro (RA), donde demuestra su identidad y la asocia a una clave pública (jamás debe mostrar la clave privada).

3. La RA transmite esta asociación a la Autoridad de Certificación (CA), que le emite un certificado firmado donde se liga la identidad del tenedor de las claves con la propia clave pública.

4. Cualquiera puede comprobar la validez de un certificado preguntándoselo a la Autoridad de Validación (VA) del PSC.

5

Introducción a la criptografía RSA

Por último: Los sobres digitales La criptografía simétrica (una única clave para cifrar y descifrar)

es mucho más rápida que la asimétrica, pero el tener una única clave presenta problemas en su distribución.

La criptografía asimétrica es muy lenta, pero la separación de claves en públicas y privadas facilita los despliegues.

Combinando ambas cosas: Los sobres digitales.1. Genero una clave simétrica aleatoria de un solo uso.2. Cifro los datos con esta clave.3. Cifro esta clave con la clave pública del destinatario (puede repetirse este

proceso tantas veces como destinatarios haya).4. Firmo el contenido.

Sobres digitales:□ Combina eficazmente criptografía simétrica y asimétrica.□ Se identifica el remitente (opcional), asociado a uno o varios destinatarios.

6

Introducción a la criptografía RSA

Unas cuantas siglas y datos de utilidad: Algoritmos de cifrado asimétrico (con par de claves):

□ DSA (en desuso), RSA, ECDSA (curva elíptica, más seguro).

Algoritmos de huella digital:□ Obsoletos: MD2, MD5, SHA-1…□ Actuales: Familia SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512).□ Futuros: SHA-3.

PSC certificados: https://sedeaplicaciones2.minetur.gob.es/prestadores/

Algoritmos de cifrado simétrico (con clave única):□ DES (obsoleto), 3DES (en uso en banca), AES (muy seguro en 256 bits)…

Formatos de firma electrónica:□ Obsoletos (pero son la base de los actuales): CMS, PKCS#7, XMLDSig.□ Actuales: XAdES (XML), CAdES (binario), PAdES (PDF).

7

SSL: Criptografía RSA en la Web

SSL es la aplicación más común de la criptografía RSA en la web: Permite identificar al servidor mediante su certificado. Opcionalmente, el servidor puede identificar al usuario igualmente

mediante su certificado. Las huellas digitales garantizan la integridad de los datos. La combinación de criptografía simétrica y asimétrica (de forma

parecida a los sobres digitales) proporcionan confidencialidad en las comunicaciones.

SSL se presenta a nivel de transporte HTTPS (y otros protocolos, como FTPS) se apoya sobre los

sockets seguros, siendo la infraestructura TCP/IP y HTTP la encargada de todo (mostrar y pedir certificados, cifrar, calcular huellas, etc.).

8

Seguridad en los API

Si SSL lo hace todo de forma automática ¿Por qué hacerlo manualmente? Independencia de la capa de transporte.

□ Puedo separar el tratamiento de los mensajes firmados de su transporte.– Elimino ligaduras con el servidor Web (que es el encargado de gestionar el SSL).– Habilito nuevas formas de provisión de los servicios (no necesariamente por

TCP/IP. Podría usar, por ejemplo, un intercambio de ficheros en carpetas compartidas).

Respaldo legal.□ El uso de firmas electrónicas es equivalente a la firma convencional (Ley

59/2003). Puedo hacer que cada transacción en mi API tenga las ventajas de la firma:

– No repudio: Los usuarios no pueden negar que hicieron la transacción.» Responsabilidades, acuerdos de nivel de servicio, auditoría, evidencias…

Identidad: Gestión fuerte de la identidad□ Aunque esto ya nos lo ofrece SSL, el independizarnos de él permite una

gestión personalizada (confianza, validación, certificados, etc.).

9

Seguridad en los API

Ejemplos de implementación con software libre: Proyecto “Cliente @firma” en GitHub

(GPLv2 + EUPLv1.1): □ https://github.com/ctt-gob-es/clienteafirma□ https://github.com/ctt-gob-es/clienteafirma-

external□ https://github.com/ctt-gob-es/clienteafirma-docs

Más de lo que parece: Bibliotecas Java perfectamente probadas para la generación y validación de firmas electrónicas.

– En cualquier formato.– Acorde a la normativa y legislación española y europea.– Bien documentado (JavaDoc y ejemplos). Con mantenimiento regular.– Para Java 7 y superiores (probado en Java 9).– Compatible con Windows, macOS, Linux, Solaris y (parcialmente) con Android

10

Seguridad en los API: Ejemplos

Generando un XML firmado:1. Cargamos las claves de firma

2. Firmamos

final KeyStore ks = KeyStore.getInstance("PKCS12"); //$NON-NLS-1$ks.load(ClassLoader.getSystemResourceAsStream(CERT_PATH), CERT_PASS.toCharArray());final PrivateKeyEntry pke = (PrivateKeyEntry) ks.getEntry(

CERT_ALIAS, new KeyStore.PasswordProtection(CERT_PASS.toCharArray())

);

final AOSigner signer = new AOXAdESSigner();final byte[] result = signer.sign(

"<data>Hola Mundo!</data>".getBytes(), //$NON-NLS-1$AOSignConstants.SIGN_ALGORITHM_SHA512WITHRSA,pke.getPrivateKey(),pke.getCertificateChain(),null // Opciones por defecto

);

11

Seguridad en los API: Ejemplos

12

Seguridad en los API: Ejemplos

Cifrado RSA

Datos Firmados

Fecha de firma

Emisor Certificado

13

Seguridad en los API: Ejemplos

Validando una firma:1. Valida la firma en sí (clave publica descifra bien el RSA, todas

las huellas digitales coinciden, se sigue el formato, etc.).2. Valida el certificado usado en la firma (está bien firmado por el

PSC, no está revocado, etc.).final SignValider validator = new ValidateXMLSignature();final SignValidity validity = validator.validate(result);if (SIGN_DETAIL_TYPE.OK.equals(validity.getValidity())) {

System.out.println("Firma correcta"); //$NON-NLS-1$}

// Extraemos el primer certificado de la primera firmafinal AOTreeModel tree = new AOXAdESSigner().getSignersStructure(result, true);final AOTreeNode node = (AOTreeNode) AOTreeModel.getChild(tree.getRoot(),0);final AOSimpleSignInfo ssi = (AOSimpleSignInfo) node.getUserObject();final X509Certificate signingCert = ssi.getCerts()[0];

// Lo validamosfinal ValidationResult vr = CertificateVerifierFactory.getCertificateVerifier(

signingCert).validateCertificate();vr.check();

14

Seguridad en los API

Unas cuantas notas sobre el ejemplo La validación del certificado solo nos dice eso, si es válido o no.

Debemos implementar nosotros los mecanismos para:□ Decidir que emisores (PSC) aceptamos o no.□ Obtener la identidad del certificado.

– Guardando su clave pública como un dato del usuario, extrayendo su correo o su número de DNI del certificado, etc.

La fecha de firma se obtiene del equipo del firmante.□ Esto puede ser una limitación, especialmente cuando el momento de la

transacción sea relevante en cuanto a su validez (validez jurídica o validez en cuanto al negocio).

□ ¡Pero hay formas de solventarlo! Podemos solicitar a una Autoridad de Sellado de Tiempo (TSA) que nos certifique que un activo existe en un momento determinado de tiempo.

– ¡Veamos un ejemplo!

15

Seguridad en los API: Ejemplos

Generando un XML firmado con sello de tiempo:

// Opciones de Sello de Tiempofinal Properties extraParams = new Properties();extraParams.put("tsaURL", TSA_TSP); //$NON-NLS-1$extraParams.put("tsaPolicy", TSA_POLICY); //$NON-NLS-1$extraParams.put("tsaRequireCert", TSA_REQUIRECERT); //$NON-NLS-1$extraParams.put("tsaHashAlgorithm", "SHA-512"); //$NON-NLS-1$ //$NON-NLS-2$

// Firmamosfinal AOSigner signer = new AOXAdESSigner();final byte[] result = signer.sign(

"<data>Hola Mundo!</data>".getBytes(), //$NON-NLS-1$AOSignConstants.SIGN_ALGORITHM_SHA512WITHRSA,pke.getPrivateKey(),pke.getCertificateChain(),extraParams // Opciones con sello de tiempo

);

16

Seguridad en los API: Ejemplos

17

Seguridad en los API: Ejemplos

18

Seguridad en los API: Ejemplos

19

Seguridad en los API

¿Qué hemos logrado con este ejemplo? Asegurar la identidad del remitente del mensaje, imposibilitando

el repudio. Firmar, con validez legal, el propio mensaje. Asegurar criptográficamente la integridad del mensaje. Asegurar, con validez legal, el momento (fecha y hora) de la

transacción.

¿Qué nos falta? La confidencialidad del mensaje.

□ La confidencialidad del mensaje es algo que podemos relegar sin problemas a la capa de transporte (con SSL, por ejemplo, usando servicios Web REST sobre HTTPS).

□ Podemos implementarla manualmente mediante sobres digitales.

20

Seguridad en los API: Ejemplos

Generando un sobre digital:

final byte[] content ="Hola mundo".getBytes(); //$NON-NLS-1$

// Destinatario del sobrefinal X509Certificate recipientCert = (X509Certificate) CertificateFactory.getInstance("X.509").generateCertificate( //$NON-NLS-1$

TestEnvelopes.class.getResourceAsStream("/ANFCERT.cer" // <- DESTINATARIO EN DIRECTORIO DE RECURSOS DE PRUEBA //$NON-NLS-1$

));

final byte[] envelope = new AOCMSEnveloper().createCMSEnvelopedData(content,null, // Referencia a la clave privada del remitente, cuando se quiera firmarnew AOCipherConfig(

AOCipherAlgorithm.AES,AOCipherBlockMode.ECB,AOCipherPadding.PKCS5PADDING

),new X509Certificate[] { recipientCert },Integer.valueOf(128) // <- CAMBIAR A 256 SI SE TIENE DESACTIVADA LA RESTRICCION EN EL JRE

);

21

Seguridad en los API: Ejemplos

Abriendo un sobre digital:// Almacen donde tengo mi clave privadafinal KeyStore ksOpen = KeyStore.getInstance("PKCS12"); //$NON-NLS-1$ksOpen.load(ClassLoader.getSystemResourceAsStream(CERT_PATH), CERT_PASS.toCharArray());final PrivateKeyEntry pkeOpen = (PrivateKeyEntry) ksOpen.getEntry(

CERT_ALIAS,new KeyStore.PasswordProtection(CERT_PASS.toCharArray())

);

// Abrimos el sobrefinal byte[] recoveredData = new AOCMSEnveloper().recoverData(envelope, pkeOpen);

System.out.println(new String(recoveredData));

22

Seguridad en los API

Una consideración adicional: XML vs. JSON El XML es especialmente apropiado para la criptografía por la

existencia del llamado “XML en forma canónica” (https://en.wikipedia.org/wiki/Canonical_XML).

Dado que la más mínima modificación de un mensaje modifica su huella digital (y por lo tanto invalida la firma), es necesario el contenido no informativo del mensaje.

□ En un XML, por ejemplo, serían los espacios, retornos de carro, tabuladores, etc.

□ Un XML sin contenido no significativo es un XML en forma canónica, y hay normativas de cómo hacerlo: https://www.w3.org/TR/xml-c14n/

JSON no tiene una normativa que establezca su “forma canónica”, por lo que no es posible establecer una “validación universal”.

□ Puedo crearme mis métodos de “canonizar”, pero validadores de firmas y firmantes deben conocerlos y aplicarlos.

23

Ejemplo real de uso

Un caso de negocio real: FNMT-RCM FNMT-RCM asegura sus API contra ciertos

registros oficiales aplicando firmas electrónicas en los XML transmitidos desde API REST.

FNMT comprueba los datos de un sujeto consultándolo mediante el API provisto por el registro.

□ Esa información viene firmada y con sello de tiempo. Así, la FNMT puede dar por ciertos esos datos en ese momento, con plena seguridad jurídica.

Si hay cambios en los datos registrales, el registro avisa a FNMT usando igualmente un mensaje firmado y un API de FNMT.

Cada transacción tiene un coste y una responsabilidad asociada.□ Hay plena seguridad de la autenticidad e integridad de los mensajes.□ Se garantiza el no repudio, tanto para costes como para posibles

responsabilidades.

24

Seguridad en los API

Datos de interés Presentación disponible en SlideShare. Muchos más ejemplos y documentación en GitHub:

□ https://github.com/ctt-gob-es/clienteafirma□ https://github.com/ctt-gob-es/clienteafirma-docs□ https://github.com/ctt-gob-es/clienteafirma-external

¿Quieres implementarlo en tu organismo o empresa?□ tgarciameras@atsistemas.com□ +34 619980058□ https://www.linkedin.com/in/tomas-gmeras/

¿Colaboraciones en proyectos de Software Libre?□ clawgrip@hotmail.com

25

Gracias por su atención