FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC) que recibe su nombre por "El señor de los Anillos"

No hace mucho os hablaba de HQC "Hamming Quasi-Cyclic" el segundo KEM (Key-Encapsulation Mechanism) elegido por el NIST para completar al primero que se anuncio y que fue bautizado como  Module-Latice-Based KEM, o MLB-KEM o ML-KEM. Estos dos primeros KEM han sido elegidos como parte de la estandarización de los algoritmos de Criptografía Post-Cuántica (PQC: Post-Quantum Cryptography). 

Figura 1: FrodoKEM: Un Key-Encapsulation Mechanism Quantum-Safe (PQC)

que recibe su nombre por "El señor de los anillos"

Sin embargo, hubo otros que se quedaron en el camino, y que con la aceleración de los últimos anuncios de Google Willow Quantum Chip, Microsoft Majorana-1 y Amazon Ocelot Quantum Chip,  merece la pena conocerlos porque alguno se está convirtiendo en estándar ISO. Uno de ellos es FrodoKEM, en el que han colaborado el mundo de la universidad, investigadores de Google y de Microsoft, que incluso tienes publicado en su GitHub para que lo puedas probar.

Figura 2: FrodoKEM en GitHub

Si queréis conocer más información de  Module-Latice-Based KEM, o MLB-KEM o ML-KEM, la podéis encontrar en la publicación completa del standard de ML-KEM la tenéis documentada en el siguiente paper del NIST, y yo escribí un artículo de HQC "Hamming Quasi-Cyclic", que también podéis leer.

Figura 3: Module-Lattice-Based Key-Encapsulation Mechanism Standard

Estos dos algoritmos se basan en una estructura de anillo algebraica central para esos algoritmos, y la apuesta de Frodo "es librarse del anillo". Sí, has entendido correctamente, este algoritmo recibe su nombre en homenaje al mítico personaje "Frodo" de "El señor de los anillos", que si no te has leído el libro, estás tardando ya - yo le dediqué un verano y lo disfruté como un "enano".

Figura 4: El Hobbit y El Señor de los anillos.

Tu lectura de este verano, sí o sí.

En este caso, FrodoKEM utiliza, para la generación de las claves de cifrado PQC (Post-Quantum Cryptography) que se usarán en una solución PKI se basan en la dificultad de resolver el problema de Learning With Errors. En este caso, el problema radica en dada una matriz A cuadrada de n x n generada uniformemente aleatoria, y dos matrices lineales siendo una muestra s de la clave, pero teniendo además la matriz e "errores", se realiza el cálculo de A x s + e y se obtiene una matriz b.

Figura 5: Explicación del problema de Learning With Errors

Para un atacante la dificultad del algoritmo es resolver la inversa, es decir, dado A y el resultado b, encontrar s, que sería la derivada sampleada de la clave, que no sería fácil de resolver para un algoritmo cuántico por la explosión de probabilidades en los que se ha podido inyectar el error, lo que le obliga a descubrir la matriz de errores, además de la clave. Como se puede ver en la imagen siguiente, la clave pública está compuesta de sA y b, por lo que se hace complejo resolver el problema.

Figura 6: Funcionamiento de FrodoKEM

Esta es la base fundamental de FrodoKEM, que como bien explican en la web de "FrodoKEM" y en el artículo "FrodoKEM: A conservative quantum-safe cryptographic algorithm" fue descartado del proceso de estandarización de NIST en la Ronda 3, pero va a ser estandarizado por la ISO/IEC 18033-2 para que sea un estándar que pueda ser utilizado por cualquiera que lo desee en la industria. 

Figura 7: Estandarización ISO de FrodoKEM

El problema que tiene FrodoKEM, como bien explican, es que evitar las posibles vulnerabilidades criptográficas que puede tener en el futuro el "anillo algebraico" en el que se centran ML-KEM y HQC-KEM es un coste en tamaño y en ciclos de computación.

Figura 8: Comparativa de ML-KEN y FrodoKEM

en tamaño y ciclos de computo hecha por el NIST.

Por supuesto, si te interesa el mundo de la criptografía, y no estás al día, te recomiendo que te pongas las pilas con el libro de  Cifrado de las comunicaciones digitales: de la cifra clásica a RSA 2ª Edición de 0xWord que te va a aclarar muchos de los conceptos que que son importantes en los algoritmos PQC (Post Quantum Cryptography).

Figura 9: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Así que, si no tenías lectura para estos días, ya sabes qué te puedes comenzar a leer, que esto es fundamental para entender el mundo de la seguridad informática en cualquiera de las áreas profesionales en la que te quieras especializar.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)

Como hemos visto en la parte anterior de este artículo, ya habíamos solucionado los problemas de usabilidad e interconexión entre los diferentes ecosistemas de usuarios, para que todos ellos pudieran enviar y recibir correos utilizando todo tipo de clientes de escritorio, web, móviles, etcétera a usuarios que se encontraran en cualquier otro destino. Se había conseguido una infraestructura global e interconectada, algo que desde luego no han fomentado las redes sociales en versiones posteriores y de lo que hablaremos un poco más adelante.

Figura 4: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)a

Con la construcción de esta infraestructura global interoperable y compatible para la comunicación, aparecieron los primeros problemas de seguridad, que tenían que ver más con las comunicaciones sobre Internet, un medio que se definió de forma insegura sin un modelo de amenazas claro desde el principio, lo que nos llevó a aplicar las primeras soluciones de cifrado y firma digital para garantizar la integridad y confiabilidad de la información que sobre el e-mail se envía.

Para el cifrado y la firma digital de los correos electrónicos aplicamos túneles SSL a los protocolos de red, y para el cifrado y la firma digital de los mensajes se puede utilizar a día de hoy S/MIME (certificados digitales para e-mail) o PGP (Pretty Good Privacy), que permiten firmar y cifrar extremo a extremo - sin contar con que los servidores de correo electrónico aplican una capa de seguridad o no -. Los clientes de correo electrónico, por su parte, avisan a los usuarios del nivel de cifrado y privacidad utilizado en cada uno de los mensajes. Pero no es suficiente ni mucho menos para todas las amenazas que fueron apareciendo.

Más soluciones de seguridad para saber de dónde viene un correo:
Reverse MX Lookup, SPF, SenderID, DKIM & DMARC

Con el escenario de envío masivo de mensajes no solicitados a direcciones de correo electrónico comenzamos a poner un montón de soluciones para ir tapando la sangría de problemas que supone para una persona y una organización – no olvidemos que el 90% de los APTs de seguridad han provenido por un correo electrónico en un ataque de spear phihing enviado a una persona de la empresa - que su buzón de correo electrónico esté abierto y disponible para cualquiera que conozca la dirección.

En esta primera remesa de soluciones vamos a intentar centrarnos en el problema de la suplantación del remitente o e-mail Spoofing, que da lugar a los ataques de Phishing y Spear Phishing. Por supuesto, la firma digital S/MIME y PGP son lo ideal, pero como hemos dicho repetidas veces, no es muy popular en el mundo global.

Reverse MX Lookup

Para evitar que suplantaran las direcciones de correo electrónico de nuestra organización, es decir, que nadie pudiera enviar mensajes de correo en nuestro nombre como se hace en los ataques de phishing, comenzamos a indicar cuáles eran los servidores de correo electrónico que pueden enviar mensajes con un remitente de nuestro dominio. La primera solución fue sencilla, pero inútil. Como al principio el servidor de correo entrante - donde están los buzones y se implementan POP3 - era el mismo que por el que salían los correos electrónicos - donde se implementa SMTP - algunos servidores de correo comenzaron a aplicar el filtro de Reverse MX Lookup.

Para saber dónde está el servidor de correo entrante de una organización, en el servidor DNS de esa organización se crea un registro especial llamado MX (Mail eXchanger) que apunta a la dirección IP o hostname del servicio que recibe el correo electrónico de ese dominio. Lo que hacían algunos servicios de correo electrónico entrante es rechazar cualquier correo electrónico que viniera de @otrodominio.com si el servidor que entregaba ese mensaje no tenía la dirección que tenía alguno de los registros MX del dominio otrodominio.com.

Como os podéis imaginar, cuando los servidores de correo saliente se separaron físicamente de los servidores de correo electrónico entrante, este filtro dejó de ser útil, ya que nunca coincidían las direcciones IP de los servidores que entregaban los mensajes con los registros MX. Por eso, hubo que crear otro registro. El registro SPF, donde se da la lista de cuáles son los servidores autorizados desde nuestra organización para entregar correos electrónicos que tengan como remitente uno de nuestros usuarios.

SPF (Sender Policy Framerwork)

Creando los famosos registros SPF (Sender Policy Framework) - también conocido como SPFv1 - se identifican los servidores de correo saliente que usa esa organización y qué debería hacer el servidor de correo entrante de un tercero si recibe un mensaje de este dominio que no viene de esos servidores identificados en SPF. A priori, suena como una medida útil, pero tiene muchos "peros" a la hora de su implementación y uso.

Figura 5: Registro SPF de Gmail.com.

Por desgracia, como las empresas tienen cedidos "alias" de correo de sus dominios a campañas de de marketing que se envían desde servidores externos a la organización o que no son controlados por ellos, la política de seguridad suele ser “Softfail” que se identifica con un "~". Para que os hagáis una idea, cuando usamos SPF lo que hacemos es irnos al DNS de nuestra empresa y decir algo como:

"Estos son los servidores que pueden enviar correo de @miempresa.com o @mibanco.com. Si te llega un correo de alguien que dice que es de @mibanco.com debes aplicar esta política."

La política más férrea debería ser “Hardfail” (-), o lo que es lo mismo, “tíralo y no lo entregues al destinatario, que es falso”, pero por desgracia sucede lo que he comentado antes, y las políticas son “Softfail” o lo que es lo mismo:

 “Míralo bien y ponlo un poco en alerta, pero no estoy seguro de que no sea mío”.

La cosa se complica a la hora de detectar si un registro realmente viene de una organización o no, yo que hay muchas variantes. Muchas personas tienen delegada la gestión de su buzón de correos a terceros, por lo que hay casuísticas en las que una persona manda un mensaje en nombre de otra.

SenderID o SPFv2 (antes conocido como CallerID)

Así, en un e-mail tenemos los campos from, pero también sender y también resent-from y resent-sender. y es ahí donde apareció el estándar SenderID, empujado por Microsoft, y conocido como SPFv2. Su idea es garantizar que el remitente de un correo viene realmente de la organización que tiene el servidor de correo electrónico que lo entrega.

Así que, determinar si un correo electrónico viene o no de una organización realmente es complejo. SenderID intentó centrarse en identificar esa casuística del emisor, pero no consiguió ser un estándar de facto, y su aplicación fue residual en el mundo de Internet, así que encontrar registros SPFv2 con políticas Hardfail fue como localizar un unicornio o un mirlo blanco.

De hecho, al final, se utilizan otras cabeceras como Return-Path y X-Return-Path (las cabeceras X- no son parte del estándar oficial y son introducidas por servidores de correo electrónico para dejar información extra que consideran útil hasta que son estandarizadas... o no.)

DKIM (Domain Keys Identified Mail)

Intentar determinar que un mensaje no es legítimo cuando la situación es tan completo hizo que SPF no fuera el único estándar que salió para evitar la suplantación de los remitentes en los mensajes de correo. Y así nació DKIM, con una aproximación distinta, tratando de decir algo como:

"No sé si este correo electrónico que viene de un servidor que no conozco y un resent-from o resent-sender extraño es un correo electrónico legítimo de esta organización o no, pero este otro que viene firmado por uno de mis servidores de correo saliente sí que es mío y puedes estar más que seguro de que su contenido es legítimo."

Como veis, la idea de DKIM (Domain Key Indentified Mail) es que cada correo electrónico que ha salido de un servidor autorizado de la organización, va firmado por una clave privada que tiene configurado el servidor de correo saliente y cuyo par de clave pública está accesible para todo el mundo en el servidor DNS de la organización y se puede consultar.

Figura 6: Clave DKIM usada por un servidor de yahoo.com

Es decir, recibo un correo de paco@yahoo.com y en el texto del mensaje aparece una cabecera DKIM con un HASH, que se supone que ha generado el servidor de correo saliente de Yahoo.com que ha entregado el correo. Así que se mira qué servidor ha entregado el correo, nos vamos al servidor DNS de Yahoo.com, pedimos la clave pública DKIM de ese servidor y comprobamos que el hash que nos han entregado es correcto.

Figura 7: Correo de Ebay firmado correctamente por DKIM

Como veis, la aproximación es diferente, mientras que con Reverse MX Lookup, SPF o SenderID se trata de eliminar lo que no venga entregado desde el dominio correcto, con DKIM se trata de indicar que, si el correo ha llegado desde la IP correcta, el usuario lo sepa con un icono especial, tal y como podéis ver en esta captura con correos de Ebay tiempo atrás. Pero como la mayoría no lo usa, pues otro intento fallido para diferenciar los correos legítimos de los no legítimos.

Como veis, el uso de Reverse MX Lookup, SPF, SenderID y DKIM hace que haya mucha información en el cuerpo de un mensaje para analizar un correo electrónico. Esta información no es concluyente ninguna por sí misma, ya que los casos son muchísimos, y es lo que hizo que los clientes de correo electrónico no se atrevieran a marcar definitivamente un mensaje como malo o como bueno.

El Proyecto "Apolo"

Para poder dar más información al usuario, nosotros creamos en Informática 64, un plugin para el navegador que se leía el cuerpo de los mensajes en el cliente web de Gmail y Hotmail, buscaba la información SPF, DKIM, SenderID, las direcciones IP en los registros MX y hacía las comprobaciones desde el propio navegador, y luego mostraba información de ayuda al usuario sobre los mensajes de correo electrónico que estaban en su bandeja de entrada. Fue un proyecto de investigación más que una verdadera herramienta, pero lo llamamos el Proyecto Apolo.

Figura 8: Información del proyecto Apolo

Si el registro SPF era correcto en el mensaje, mostramos un icono verde. Si no cumple DKIM, ni Sender ID, ni SPF, ni MX Reverse Lookup, lo poníamos en alerta roja. Una prueba para dar más información a los usuarios avanzados.

DMARC (Domain-based, Message Authentication, Reporting & Conformance)

Al final, lo que nosotros hicimos en el Proyecto Apolo tenía todo el sentido. Había que hacer algo que mezclara todo, y así, tiempo después, nació DMARC. El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 9: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -, para lo que vamos a necesitar alguna tecnología extra.

PCL (Phishing Confidence Level)

Al final, ni con DMARC se garantiza que un mensaje no sea malicioso. Existen casos concretos en los que es posible pasar DMARC o no hay información suficiente para tomar una decisión firme. En algunos mensajes habrá información de Return-Path o X-Return-Path útil. En otros habrá información de direcciones IP que podremos consultar en bases de datos de salud que nos dirán si son de hosters que nunca hacen ataques o de otros con "mala reputación". Además, si miramos el cuerpo del mensaje podremos ver si tienen textos utilizados normalmente en ataques de phishing o no, etcétera.

Figura 10: Configuración de umbrales PCL en Microsoft Outlook

Es decir, que si independientemente de los estándares que intentan garantizar que un mensaje viene o no viene de un determinado dominio, podemos aplicar técnicas avanzada de Machine Learning a los mensajes que utilicen toda la información en el mensaje disposnible, y todo el conocimiento histórico que tengamos de nuestro correo electrónico para generar un índice, que llamamos PCL (Phishing Confidence Level) y que generar mi servidor de correo para clasificar el mensaje en función del número que salga.

Así, creamos unos umbrales para decidir qué mensajes entran en la carpeta de entrada, cuáles entran en ella pero con funcionalidad limitada - carga de imágenes, alertas mostradas y deshabilitación de funciones -, cuáles van a la carpeta de Spam y cuáles no se entregan al buzón.

Es un trabajo avanzado e ímprobo, y muchas veces tiene errores, pero es la solución que aglutina todos los intentos anteriores existentes para sacar el máximo de la información disponible. Además, para poder tener la información actualizada y el PCL vaya ajustándose, es necesario contar con la colaboración de los usuarios, que deberán ir reportando aquellos mensajes sospechosos. Pero esto es solo para los ataques de Phishing.

Y aún así no son suficientes y se intentan cosas nuevas.

Aún nos queda el SPAM por donde vienen la mayoría de los problemas de malware, robo de tiempo de las personas para convertir el e-mail en improductivo y molesto para las personas. Y mucho peor, los problemas de identidad asociados a las direcciones de correo electrónico, así que nos queda mucho por hablar todavía de la muerte y resurrección del e-mail.

Como os podéis imaginar, a pesar de todas estas tecnologías, el correo electrónico sigue siendo un caos. Al final un mensaje puede entrar en el buzón de entrada de un destinatario o no dependiendo de la configuración de estas tecnologías en su servidor de correo, lo que permite que un mensaje de Spam o un Phishing puedan entrar o no dependiendo de la configuración que tengas.

Nos quedan muchas cosas, y lo iremos viendo en las partes siguientes de este artículo. Espero que estéis disfrutando la lectura tanto como yo la escritura.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************

SealSign BioSignature: Firma manuscrita biométrica en iPad Pro #Apple #iPad #Biometría

Hace ya dos años que presentamos en ElevenPaths la llegada de SealSign BioSignature, un sistema que permite reconocer la biometría de la firma manuscrita en un dispositivo móvil o tablet para poder firmar documentos o autenticar usuarios por medio de sistemas que evntien los ataques "Ruber Hose". Desde entonces el trabajo ha sido largo con esta tecnología y hemos ido realizando proyectos y avances en la misma, como os hemos ido contando.

Figura 1: SealSign BioSignature: Firma manuscrita biométrica en iPad Pro

Para poneros un poco en situación, la idea es tan sencilla como que una persona firme en dispositivo móvil o tablet, y por medio de los algoritmos SealSign BioSignature sea capaz de, en primer lugar, capturar de la firma todos los detalles y minucias del grafo dibujado, la velocidad y la presión en los ejes X e Y para obtener la huella biométrica de esa firma.


Figura 2: Firma manuscrita biométrica en entornos de movilidad
Con esta solución en entornos de movilidad se pueden crear soluciones de todo tipo, incluso en entornos de aplicaciones web corporativas como este ejemplo en el que yo utilizaba una tableta digitalizadora a través de una página web.

Figura 3: Demo de SealSign en una tablet y página web

Esto permite que, cuando se ha hecho la firma en frente de una persona autorizada para el control, se pueda garantizar que se obtenido de la persona correcta y con todo lujo de datos para que un perito calígrafo pudiera verificarla en un proceso de impugnación. En el siguiente vídeo puedes ver el ejemplo con una app en una tablet Samsung con Android.

Figura 4: Demo de verificación de firmas en tablet Android

Un ejemplo de este sistema es la aplicación de falsificadores que enseñamos en el Mobile World Congress de 2015, donde el rey Felipe VI tenía que intentar falsificar una firma del entonces presidente de Telefónica, César Alierta. Aquí tenéis la demo.

Figura 5: Prueba del Rey Felipe VI a SealSign BioSignature

Como caso de uso de SealSign BioSignature en el que el máximo interés es recoger una firma en un documento para garantizar que la persona que ha firmado el documento es consciente de ello, hay que citar el sistema de consentimiento informado que se usa en los hospitales, como se explica en el siguiente vídeo.

Figura 6: Uso de SealSign BioSignature en recogida de Consentimientos Informados

En este modo de funcionamiento SealSign BioSignature está implantado en hospitales y se usa para que cuando el doctor debe informar al paciente del tratamiento al que va a ser sometido pueda recoger el factultativo la firma de los pacientes de forma segura. De esto dimos una sesión en las ElevenPaths Talks explicando el proceso detallado.

Figura 7: Firma digital en el ámbito sanitario

En segundo lugar, con esa firma caligráfica se puede llegar a saber si una nueva firma es o no es perteneciente a la misma persona, lo que lo convierte en un poderoso sistema de autenticación basada en biometría de hábitos tan usados hoy en día, como podría ser la forma en cómo se pulsan las teclas, cómo coges el terminal móvil o cómo mueves el dedo a lo largo de una tablet. 

Figura 8: Autenticación con firma para acceder a los caramelos

Uniendo el sistema de firma manuscrita biométrica al de firma con certificados digitales, el resultado es un sistemas de firma robusto y usable que permite autorizar el uso del certificado digital mediante la autenticación de por la biometría de la firma manuscrita.

Figura 9: Firma digital manuscrita + certificado digital

Esta solución que aúna la biometría de la firma digital manuscrita más el uso de firma digital con certificados digitales ya está implantado con SealSign en la Administración Pública de España, y de eso ya os hablamos en el último Security Day 2016 en el que Joseba García Celada, responsable de este proyecto, explicaba su funcionamiento y cómo se está usando.

Figura 10: Firma digital en la Administración Pública de España con SealSign

Además, usando este sistema en un tablet, permite la firma masiva de documentos utilizando este sistema robusto doble de firma de documentos usando un certificado digital autorizado por la firma manuscrita.

Figura 11: Firma digital masiva de documentos con SealSign BioSignature

Ahora, tras reunirnos con la unidad de empresas para Apple en España, decidimos dar un paso más y firmar un acuerdo de comercialización conjunto para vender terminales iPad Pro como plataforma de firma digital de documentos utilizando SealSign BioSignature, y desde ya está disponible para aquellos que quieran tenerlo.

Figura 12: SealSign BioSignature en Apple iPad Pro

Al final, SealSign BioSignature permite usar tabletas digitalizadoras como se ve en el vídeo de la Figura 2, tablets Android o iPad Pro, lo que amplía el ecosistema de dispositivos, pero lo más importante de SealSign es que es también una plataforma con un "Engine" para la firma digital centralizada usando certificados digitales o firma manuscrita y con el añadido de tener un sistema de almacenamiento longevo de documentos, lo que permite adaptarla a cualquier proceso.


Figura 13: Arquitectura y Administración de la plataforma SealSign BioSignature
Si quieres conocer más sobre cómo integrar esta plataforma en tus sistemas de negocio o conocer más de SealSign, puedes ponerte en contacto con nosotros o ver los recursos disponibles. Recuerda que la puedes integrar incluso con una máquina de caramelos.

- Comunidad de SealSign en ElevenPaths
- Cómo integrar SealSign Engine en aplicaciones .NET
- Cómo integrar SealSign BioSignature en aplicaciones .NET
- Cómo integrar SealSign Engine en aplicaciones Java y Web
- Cómo integrar SealSign BioSignature en aplicaciones Java y Web
- Cómo integrar SealSign bioSignature en el mundo IoT

Saludos Malignos!

Security Day 2016_: Security Evolution [Madrid]

Un año más repetimos nuestro calendario en Eleven Paths y antes de irnos de KickOff y hacer la parada veraniega, hacemos un catch-up públicamente con todo lo que hemos avanzado en este periodo de tiempo en la parte tecnológica. Esta será la tercera edición del Security Day, y lo hacemos para enseñaros demostraciones de nuestras tecnologías, junto con proyectos que hemos implantado usando los productos, y alguna novedad que esperamos que os guste.

Figura 1: Security Day 2016_ - Security Evolution

En la agenda vamos a hablar de Virtual Patching y cómo utilizar Faast con sistemas WAF para el parcheo en caliente de vulnerabilidades. Vamos a hablar de cómo hemos desplegado servicios de firma digital con certificados digitales habilitados con firma digital manuscrita y protegidos con Latch. Vamos a hablar de como hemos utilizado SandaS GRC y Vamps en el control de sistemas industriales y SCADA.

También vamos a hablar de novedades con MetaShield Protector para Exchange Server y MetaShield para Office 365. Vamos hablar de nuevas alianzas estratégicas que hemos firmado con Fortinet o las integraciones que hemos hecho con CheckPoint y Kaspersky. Y vamos a hablar de las implementaciones con Sinfonier y Latch que se han hecho en los concursos.... y alguna sorpresa más. Esta es la agenda que tenemos preparada.

Figura 2: Agenda del evento

El evento es para clientes y profesionales y tendrá lugar en Madrid, el día 26 de Mayo, en el auditorio Rafael del Pino sito en la calle Rafael Calvo 39A. Será únicamente por la mañana y habrá un café y un cóctel al terminar.

Figura 3: Ubicación del evento

Para asistir hay que registrarse previamente y se confirmará las plazas a los asistentes por correo electrónico ya que hay un aforo limitado y debemos respetarlo, así que si quieres asistir, regístrate cuanto antes e intentaremos reservarte tu sitio.

Saludos Malignos!

Eleven Paths Talks: Una serie de webcasts tecnológicos

Una de las acciones que hemos comenzado a realizar en Eleven Paths ha sido la planificación de un calendario de seminarios online sobre seguridad informática y tecnología a la que hemos llamado Eleven Paths Talks. Son impartidas vía online y de forma gratuita para que pueda apuntarse cualquier persona a la que le interese la temática. Cada una de estas charlas está impartida por un compañero de Eleven Paths y los asistentes pueden interactuar y participar con preguntas.

Figura 1: Eleven Paths Talks. Una serie de webcasts tecnológicos

Ya se han impartido algunas sesiones, que han quedado grabadas, así que las voy a recopilar en este artículo para que las tengáis a mano y podáis verlas si así lo deseáis. Además, como veréis, tenemos un calendario abierto con las nuevas sesiones que puedes consultar en la web: Eleven Paths Talks.

Figura 2: Eleven Paths Talks 1 - Firma biométrica en entornos sanitarios

Figura 3: Eleven Paths Talks 2 - Equipo de respuesta ante incidentes

Figura 4: Eleven Paths Talks 3 - Conociendo la seguridad en sistemas industriales

Figura 5: Eleven Paths Talks 4 - Metodologías de Testing de Aplicaciones


Figura 6: Eleven Paths Talks 5 - Latch en el mundo IoT


Figura 7: Eleven Paths Talks 6 - Gestión de la seguridad


Figura 8: Eleven Paths Talks 7 - Big Data & InfoSec [Portugués] 

Figura 9: Eleven Paths Talks 8 - Big Data & InfoSec [Español]


Figura 10: Eleven Paths Talks 9 - Defensa en Profundidad 

Figura 11: Eleven Paths Talks 10 - The ISF Standard of Good Practices for Information Security [ENG]


Figura 12: Eleven Paths Talks 11 - Deep Web


Figura 13: Eleven Paths Talks 12 - Técnicas OSINT


Figura 14: Eleven Paths Talks 13 - SealSign en IoT


Figura 15: Eleven Paths Talks 14 - ¿Desaparecerán las contraseñas?
  Figura 16: Eleven Paths Talks 15 - WordPress in Paranoid Mode

Figura 17: Eleven Paths Talks 16 - Análisis de Riesgos

En el calendario detallado puedes ver las próximas charlas. Como podéis ver, hay sesiones dedicadas a Latch e IoT en la que Jorge Rivera contará como hacer esos proyectos en los que mezcla el mundo físico y la seguridad digital, sesiones en inglés impartida por nuestro CSA en Alemania Sebastian Piecha, charlas en portugués que serán dadas por nuestro CSA en Brasil Leandro Bennaton, o en Español, como las que impartirán nuestro último fichaje como CSA en Chile, Gabriel Bergel. De momento están planificadas hasta Junio.

Saludos Malignos!

Estrategia de Identidad en Telefónica y más sobre Latch: (AuthaaS) Authentication & Authorization as a Service

Durante el último Security Innovation Day 2015 tuvimos una sesión de presentación sobre toda la estrategia de soluciones de identidad que estamos impulsando desde Telefónica, haciendo uso de las tecnologías que estamos creando en Eleven Paths. Los que pudisteis venir a las sesiones visteis que en directo mezclábamos todas nuestras soluciones de diversas maneras y en diversas situaciones. Desde autenticar de forma robusta con Mobile Connect o SmartID - para usar smartcards, biometría, NFC, DNIe o RFID, autorizar vía Latch, Mobile Connect con Biometría o tokens OTPs vía SMS para los terminales pre-smartphone, e incluso identificar en el sistema de recuperación de contraseñas a los usuarios vía SealSign (como sistema de autenticación anti Rubber Hose).

Figura 1: Estrategia de identidad en Telefónica y más sobre Latch

Todos ellos funcionando según la estrategia de identidad que una compañía quiera realizar, ya que al final, los productos son nuestros y los podemos adaptar a cada situación. Durante la presentación, lo recogíamos todo en esa diapositiva que habíamos extraído del informe que Gartner ha hecho sobre nuestra propuesta de Authentication & Authorization as a Service.

Figura 2: Estrategia de identidad de Telefónica con tecnologías de Eleven Paths

El informe que ha hecho el equipo de Gartner se ha basado en el trabajo de varios meses analizando nuestra propuesta, y ha quedado plasmado en el siguiente documento que he subido a mi canal SlideShare:

Figura 3: New Paradigms of Digital Identity: Authentication & Authorization as a Service (AuthaaS)

Para conseguir dar esa flexibilidad, tenemos un roadmap muy extenso que va haciendo que día a día, versión a versión, todos ellos tengan nuevas características que permitan hacer más y más cosas. En el caso de Mobile Connect, ya sabéis que lo hemos puesto en producción en España, Argentina, México y Perú, y que en breve estará disponible para integrar en cualquier sitio que quieras. 

Figura 4: Un ejemplo de autenticación con Mobile Connect en una web

En el caso de Latch hemos seguido ampliando el número de sitios donde está integrado - ya hay más de 7.000 aplicaciones integradas con Latch - y hemos continuado metiendo características. Algunas de usabilidad e información para el usuario, como las características de Silenciar y de Log & Stats que os contaba hace poco, y otras vía API, como personalizar los mensajes OTP o permitir crear operaciones de forma dinámica. Esta última opción es la que utilizó Ben Metzel CTO de Vaultive para controlar dinámicamente los dispositivos que podrían acceder al correo electrónico de Office 365 descifrado, tal y como mostró en su demostración en el evento.

Figura 5: Ben Metzel, CTO de Vaultive, controlando el acceso al correo de
Office 365 descifrado por dispositivos desde Latch

Desde el punto de vista más puro de usabilidad, también lanzamos Latch para Apple Watch, que ya puedes descargar y probar, además de una serie de características que están escondidas para los menos curiosos, y que os paso a contar por aquí. Estas características las teníamos en el roadmap desde hace tiempo, pero las vamos metiendo según la cola de prioridad que tienen, y las que hemos sacado son las siguientes que puedes utilizar arrastrando el Latch hacia la derecha.

Figura 6: Acceso a opciones de cada Latch

En la imagen veis unos textos que he añadido yo para hacer más fácil la comprensión, pero luego no van a estar en la app. Son bastante sencillos de entender, ya que son las opciones de Renombrar, Agrupar, Silenciar y acceso a Log & Stats. Esta última, la gestión de Log & Stats, ya la explique en detalle en un artículo, así que me voy a centrar hoy en las otras.

Renombrar y Silenciar

Estas dos opciones son muy sencillas. La primera de ellas es tan fácil que consiste en cambiarle el nombre al pestillo. Esto es útil sobre todo si hay varios Latches protegiendo varias identidades en el mismo sitio. De esta forma se puede poner un nombre que ayude a diferenciarlos. De momento no hemos permitido cambiar el icono del Latch, pero todo se andará.

Figura 7: Cuadro para renombrar un Latch

La segunda opción, la de silenciar, hará que no lleguen alertas para esa identidad. Esto puede ser útil en muchos entornos en los que hay demasiadas comprobaciones, pero puede dejar al usuario sin enterarse de lo que está pasando. Para ello, cuando se activa aparece el icono avisando de esto en el Latch principal.

Figura 8: Un Latch con las alertas silenciadas

Decidimos meter esta opción solo cuando teníamos terminada la parte de logs & stats, ya que a pesar de que no que lleguen las alertas en tiempo real, el usuario podrá revisar siempre todo lo que ha pasado con su identidad.

Mover a una Carpeta

En muchos wallets de Latch el número de identidades empieza a crecer lo suficiente como para que sea útil agruparlos. Hemos decidido meterlos ahora que ya hemos sobrepasado la barrera de los 320.000 usuarios, y su funcionamiento es sencillo. Desde la opción de Mover se pone un nombre de una carpeta la primera vez que se crea y a partir de ese momento aparece una carpeta en la lista de Latches.

Figura 9: Cuadro para mover un Latch a un nuevo Grupo

Es muy similar su funcionamiento a las carpetas de iOS u otros sistemas operativos móviles. Si en algún momento se quiere sacar de la carpeta a una identidad, se vuelve a seleccionar la misma opción y se deselecciona el grupo. Por último, para borrar el grupo, se hace exactamente igual que antes, arrastrando hacia la derecha y con la opción X de borrar. 

Figura 10: Grupo Tienda con Latches dentro

Hemos metido la opción de renombrar el grupo o carpeta de Latches, pero no hemos permitido aún poner iconos personalizados, que tal vez lo hagamos en la siguiente versión.

Figura 11: Izquierda opción de cambiar un Latch de Grupo. Derecha borrar un Grupo.

Como veis, poco a poco intentamos ir metiendo aquellas ideas que se nos ocurren y que nos dais, así que cualquier feedback o necesidad que vayáis teniendo será bien recibida. Recordad que ahora tenemos abierto el Latch Plugin Contest 2015 - puedes debatir sobre él en nuestra comunidad - y que puedes ganar por tus implementaciones de Latch hasta 5.000 $ en BitCoins, así que "Put your code where your mouth is".

Saludos Malignos!

Aplicaciones .NET con campos ViewState sin firmar o cifrar

Las aplicaciones web escritas en ASP.NET utilizan desde su concepción hace ya muchos años un campo oculto llamado ViewState que controla el flujo de datos y estados de la aplicación en todo momento. Este campo se utiliza para garantizar la privacidad y la integridad de la información en cada uno de los intercambios de información que se producen entre el servidor web y el cliente web. Es decir, para garantizar que la información no ha sido manipulada y que además se ha transferido de forma correcta en todos sus campos.

Figura 1: Aplicaciones ASP.NET con campos ViewState sin firmar o cifrar

Para poder conseguir estos objetivos con garantías, ViewState debe ir firmado y cifrado, pero esto no siempre es así, sobre todo en aplicaciones más antiguas que puedan estar aún en los servidores de muchas organizaciones.

Firmado de ViewState

Desde ASP.NET v.1.0 los campos ViewState van firmados por con un código MAC (Machine Authentication Check), que no es más que un CheckSum de toda la información que se encuentra almacenada dentro de ViewState. La idea es tan sencilla como que una vez que se decide qué se tiene que transferir, se hace una codificación en BASE64, se hace el CheckSUM de la misma y se calcula el valor MAC.

Figura 2: Flujo de utilización de ViewState

De esta forma, cuando se carga la página que se debe renderizar o cuando se envía de vuelta al servidor se puede comprobar si esta ha sido modificada verificándola con el valor de ViewState. Si no coincide, el servidor dará un error de aplicación.

Figura 3: Error .NET de fallo de validación de MAC en el campo ViewState

Esto está configurado a TRUE por defecto en la propiedad EnableViewStateMac desde la versión ASP.NET 1.0, por lo que es raro encontrar aplicaciones que no manejen el campo ViewState firmado, pero si esto sucediera entonces las funciones de integridad de la web aportadas por ASP.NET no serían robustas. 

Cifrado de ViewState

En cuanto al cifrado del campo ViewState no se activó por defecto hasta la versión ASP.NET 2.0. donde para configurar que se cifre el contenido almacenado - y no vaya solo codificado en BASE64 y con un código MAC - hay que configurar los valores decryptionKey y decrypt de las propiedades de MachineKey, tal y como se explica en este artículo de la MSDN. 

Figura 4: Generación de claves de MachineKey

La claves para algunas versiones de ASP.NET, como se puede ver en la imagen superior, se pueden crear y renovar desde el servidor IIS 7, tal y como se explica en este blog de MSDN.

Decodificar campos ViewState sin cifrar

No es demasiado común encontrar aplicaciones ASP.NET que tengan el campo ViewState sin cifrar, pero aún así, en nuestro sistema de Pentesting Persistente Faast, uno de los plugins que se centra en la seguridad y vulnerabilidades de este tipo de tecnologías, sí que lo revisa. En el siguiente ejemplo se puede ver una web localizada en producción con el campo ViewState sin cifrar.

Figura 5: Detección de aplicación ASP.NET con ViewState sin cifrar

Cuando el campo está sin cifrar, lo único que sucede es que se pueden acceder a todos los datos en tránsito, y entre ellos pueden ir las cookies de sesión que se estén intercambiando, o cualquier otra información sensible de la web.

Figura 6: El campo ViewState localizado sin cifrar en un decodificador

El código para decodificar un campo ViewState sin cifrar es conocido - tenéis uno disponible en esta pregunta de StackOverflow -, y es fácil localizar decodificadores online que te muestran todo el contenido dentro del mismo, tal y como se puede ver en la imagen siguiente.

Figura 7: Contenido decodificado de un ViewState sin cifrar

La firma y el cifrado de ViewState ayudan a hacer mucho más robustas las aplicaciones ASP.NET y a protegerlas frente a ataques avanzados, por lo que es una recomendación de seguridad básica en estos entornos. Además, los campos ViewState ayudan también a gestionar la seguridad frente a ataques CSRF, pero eso exige otras configuraciones de las que ya os contaré en otro artículo.

Saludos Malignos!

Integrar biometría de firma manuscrita en aplicaciones

Una de las tecnologías que tenemos en Eleven Paths es SealSign, una plataforma de firma digital de documentos que permite, entre otras muchas cosas, firmar un documento manualmente y recoger la biometría tu firma manuscrita en entornos de movilidad. Es decir, como ya hicimos en el pasado Mobile World Congress, se puede reconocer a una persona o a otra por medio de la firma manuscrita que realiza en un dispositivo móvil, como un tablet, para saber si es él o no el que ha firmado el documento. 

Figura 1: Integrar biometría de firma manuscrita en aplicaciones Web, Java y .NET

Lo bueno de la tecnología SealSign es que se puede integrar en muchas aplicaciones, y es por ello que cualquier desarrollador de aplicaciones que quiera integrar esa tecnología en sus procesos puede hacerlo. En el siguiente vídeo yo os mostraba cómo se puede integrar en aplicaciones web.

Figura 2: Ejemplo de aplicación web con reconocimiento de firma manuscrita

Pero no solo eso, también está pensado para aplicaciones móviles. El siguiente vídeo es de una herramienta de Vodafone, llamada VodaGest, donde se puede ver la integración de la firma manuscrita biométrica en un entorno 100% de movilidad para la firma de contratos. Este es un buen ejemplo para entender la flexibilidad que ofrecen tecnologías com SealSign para la mejora de los procesos.

Figura 3: Vodagest 3.0 integra biometría de firma manuscrita en entornos de movilidad

Para que nuestros partners puedan integrar SealSign BioSignature en sus plataformas y sistemas informáticos, los ingenieros de Eleven Paths han dado varias formaciones por Internet, y de ellas hemos sacado estos 5 vídeos que podéis ver para entender cómo funciona la plataforma, y cómo se pueden integrar en aplicaciones Web, Java y .NET.

Figura 4: Arquitectura y Consola de Administración de SealSign 

Figura 5: Integración de aplicaciones Java y Web con SealSign Engine 

Figura 6: Integración de aplicaciones Java y Web con SealSign BioSignature 

Figura 7: Integración de aplicaciones .NET con SealSign Engine 

Figura 8: Integración de aplicaciones .NET con SealSign BioSignature

La plataforma SealSign ofrece las mismas posibilidades para la firma digital con la biometría de tu huella dactilar, para la firma de documentos con certificados digitales, para hacerlo usando smartcards, DNIe o el nuevo DNIe 3.0.

Figura 9: Componentes de la arquitectura de SealSign

Además, permite centralizar la plataforma de firma digital, gestionar el archivo longevo de documentos y gestionar de forma segura los certificados de todos los empleados de una empresa en un Central Key Control. Si deseas integrar estas tecnologías en cualquier sistema informático que tú tengas, no dudes en ponerte en contacto con nosotros que te ayudaremos en todo lo que necesites.

Saludos Mallignos!