Archivo de la categoría ‘Web’

La Autentificación en tiempos modernos. Certificados Digitales y Tarjetas de Acceso (Inteligentes/Criptográficas)

Nuevo capítulo de la serie, el quinto si cuento correctamente. En esta ocasión vamos a hablar de la autentificación por medio de certificados digitales, y por extensión a las tarjetas de acceso, la mayoría de ellas funcionan con certificados.

Hace ya un tiempo escribí en otra serie de artículos una publicación parecida. Los tiempos han cambiado y desde luego muchas cosas son ahora diferentes, pero realmente la mayoría de los conceptos e ideas que se daban entonces, siguen siendo igualmente válidas. El artículo original lo tenéis AQUÍ. Vamos a hablar de cuestiones muy similares, aunque vamos a orientarlo a otros usos y a otras necesidades, y vamos a extender algunas cuestiones que entonces se tocaron.

Hemos hablado ya de sistemas de autentificación como usuarios y contraseñas o sistemas biométricos. ¿Pero qué nos podría ofrecer los certificados digitales? No es algo que somos ni algo que sabemos, es algo que tenemos. Un certificado digital soluciona dos de los mayores problemas existentes: El primero, por basarse en criptografía asimétrica, no expone nunca hacia el exterior la parte sensible de estos, la clave privada, con lo que elimina en principio los riesgos de que un servidor remoto se vea comprometido y puedan robar nuestras credenciales. El segundo, puede asegurar la inequivocidad de una persona si se toman las medidas adecuadas, y la estructura PKI funciona correctamente.

Vamos por tanto a analizar un poco los certificados digitales, sin entrar en detalles como los que publiqué hace ya algún año, y más adelante la funcionalidad de las SmartCards, tarjetas de acceso, tarjetas inteligentes o como las queramos llamar.


El Maravilloso Invento de la criptografía asimétrica

Allá por los años 1970, dos criptógrafos británicos tomando unas ideas locas de unas décadas anteriores, crearon un sistema que ellos mismos denominaron como encriptado sin secretos. Hasta el momento todos los cifrados y/o sistemas de codificación requerían en última instancia de una contraseña, un objeto, un procedimiento… que tenía que ser secreto y compartido por las diferentes partes que quisiesen poder desencriptar un mensaje dado. Así que la importancia era enorme. Crearon en secreto lo que algunos años más tarde pasaría a ser una de las piedras más importantes en la seguridad moderna: El Algoritmo RSA, que lo trajeron los amigos del MIT Ron Rivest (R), Adi Shamir (S) y Leonard Adleman (A).

En realidad el algoritmo RSA es muy sencillo matemáticamente hablando. Se basa simplemente en la complejidad computacional de factorizar el producto de dos números primos muy grandes. Si cogemos dos números primos, por ejemplo el 5 y el 7 y los multiplicamos, tenemos 35. Si quisiésemos descomponer el 35 en sus factores tendríamos en principio ir dividiendo el 35 desde el 2 hasta el 34 (en realidad hasta la raíz de 35). Par el 35 es muy simple, la raiz cuadrada de 35 es más o menos 6, con lo que con 5-6 divisiones serían suficientes para encontrar que los factores son el 5 y el 7.

Parece un juego de niños… ¿pero que pasaría con un número algo más grande? Uno fácil, el 2504902397, es un número tan solo de 32bits. ¿Quien es capaz de calcular sus factores? La raiz cuadrada es de 50049 aproximadamente, significa que tendríamos que realizar en el peor de los casos algo más de 50 mil divisiones. Como es el producto de dos números primos, sabemos que no van a existir más de 2 factores. ¿Quien es ahora el guapo que lo hace a mano?

Un equipo moderno es capaz de realizar miles-millones de operaciones por segundo, sería capaz de factorizar dicho número casi al instante. Pero ese número es sólo de 32Bits. Las claves RSA privadas a día de hoy suelen ser de 1024/2048/4096 bits. ¿Cuanto es esto? Pues imaginaros un número con más de 300 cifras para claves de 1024bits. Dicho número es tan grande, que los supercomputadores tardarían cientos de años en ser capaces de factorizarlo. El problema matemático de la factorización es bien conocido, y radica en que no existe un modo eficiente de factorizar un número, haciendo que la capacidad de computación necesaria sea tan ingente que no sea viable su cálculo.

Los cifrados asimétricos radican en estas premisas, imposibilitan el poder obtener en un tiempo asumible la clave privada. Pero lo que les hace realmente interesante es que no funcionan como los cifrados normales. Aquí no existe una clave, existen realmente 2. Una, es la que denominamos clave Privada, otra la que llamamos clave pública. No es así, pero imaginemos que los factores son la clave privada, mientras que el número resultante es la clave pública. Como no hay forma humana de factorizar la clave pública, jamás se podrá obtener la clave privada a través de ella.

Tenemos dos claves, esto parece complicar el esquema normal de una simple contraseña, pero a diferencia de los sistemas simétricos, en los sistemas asimétricos las claves están asociadas de tal modo que lo que se encripta con una, se tiene que desencriptar con la otra. Si se encripta con la privada, solo la pública puede desencriptarlo, y si se encripta con la pública, solo la privada puede desencriptarlo. Y esto es maravilloso, porque de este modo la clave privada jamás es necesario enviarla o dársela a nadie!! Por el contrario, lo único que tenemos que hacer es enviarles la clave pública, que es más, no nos importa que conozca toda la población mundial, no compromete en nada nuestra seguridad. Obviamente la clave privada es aquí lo importante, y lo único que tenemos que mantener a buen recaudo, pero podemos tenerla nosotros guardada, no la tenemos que compartir.

Bien, puse este «sencillo juego de niños» es en el que se sustenta a día de hoy prácticamente toda la seguridad digital. Hoy lo aplicaremos a certificados digitales y tarjetas criptográficas, pero su uso es extremadamente extenso por las grandes ventajas que aporta, y por supuesto su seguridad. Es más, si alguien quiere ser tremendamente millonario, solo tiene que lograr un algoritmo de factorización que sea capaz de resolver la factorización de cualquier número en tiempo polinomial sin recurrir a algoritmos cuánticos. Si tal algoritmo existiese, se rompería de un día para otro toda la seguridad actual, y podría existir, no hay aun demostración ni nada que nos diga que no existe.


La Firma Digital

Aunque la firma digital pude aplicarse igualmente a criptografía simétrica y asimétrica, por regla general siempre está asociada a esta última, aun cuando se realiza con una clave simétrica, esta por regla general es «generada» «intercambiada» previamente por un sistema asimétrico.

La idea de la firma digital es muy simple, es disponer de un mecanismo por el cual ser capaces tanto de darle legitimidad como integridad (no se ha modificado el contenido) a cualquier archivo digital. Gracias a la criptografía asimétrica, esto puede asegurarse de un modo relativamente simple.

Hemos visto por encima como funciona la criptografía asimétrica. Siguiendo ese mismo esquema, lo que nos interesaría ahora no es cifrar el contenido, nos interesa que cualquiera pueda leerlo, pero que también, quien lo lea, tenga la seguridad de que ese mensaje procede de nosotros y que no ha sido alterado. Recordar que en España es posible firmar documentos legales de forma digital con la misma validez que una firma manuscrita, es importante por ello que podamos asegurar estas dos premisas.

El esquema a usar es similar, pero en vez de usar un algoritmo de cifrado se usa un algoritmo de Firma. En su versión más simple podría ser por ejemplo un Hash.

En este ejemplo, Alicia redacta un mensaje que quiere darle legitimidad e integridad para enviárselo a Bobo. Alicia aplica a su mensaje un algoritmo de Firma, por simplificar imaginemos que aplica un Hash MD5 a su mensaje. Los hash como sabemos son funciones criptográficas de un solo sentido, cuya salida tiene una longitud fija, usados extensamente para dar integridad, dado que si se modificase aunque fuese una coma de dicho hash, el hash recalculado sería totalmente diferente.

Alicia por tanto calcula un hash MD5 a su mensaje, y acto seguido usa su clave privada para cifrar dicho hash. El resultado lo adjunto a su mensaje original, y lo envía a Bob. Bob por su parte, en cuanto llega el mensaje puede leerlo sin problema, no está cifrado. Pero quiere saber quien envió realmente el mensaje. Bob extrae la firma encriptada del mensaje y usa la clave pública de Alicia que tiene para desencriptarla. El resultado es un Hash MD5. Ahora Bob solo tiene que calcular de forma local el Hash MD6 del mensaje que ha leído y compararlo con el Hash ya desencriptado que venía adjunto. Si ambos Hash coinciden, Bob puede estar seguro que dicho mensaje fue enviado efectivamente por Alicia (dado que solo la clave pública de Alicia puede desencriptar la firma), y que no ha sido modificado (dado que el Hash coincide).

Una firma no encripta el contenido, aunque en cierto modo encripta el contenido de la firma, pero no el contenido que se quiere firmar. En la realidad no se usan directamente los Hash para crear la firma, sino algoritmos de firma que por lo general hacen todo el proceso de golpe, usan algún tipo de función Hasheada en un entorno de clave asimétrica. Así tenemos por ejemplo el algoritmo DSA.

La firma será parte imprescindible en los certificados digitales, es lo que les otorga legitimidad e integridad. Sin una firma válida y confiable, un certificado digital no vale para nada.


Certificados Digitales

Ya hable mucho sobre ello, pero hagamos un rápido repaso. Un certificado digital es algo así como un documento digital con cierta estructura que contiene diferentes datos identificativos sobre aquello para lo que se ha emitido. Dependiendo de la finalidad tendrá unos datos u otros. Si por ejemplo es un certificado personal es normal que incluya información como nombre, apellidos, correo electrónico, dirección… si es un certificado de un servidor datos como empresa a la que pertenece, dirección Web… pero además de ello, todos incluyen una serie de directivas que especifican la finalidad y uso que se le va a dar, y más importante, una clave pública que tiene asociada. Esta clave pública puede venir de un cifrado RSA, pero no es el único que usamos, cada vez se ha extendido más el uso de sistemas asimétricos basados en curvas elípticas.

Todos usamos a diario de forma transparente certificados digitales. Cada página web que esté bajo HTTPS usa uno, por ejemplo. Pero esta serie de artículos están destinados a la autentificación, no al cifrado de datos en sí que es la razón de ser de HTTPS (aunque también autentifica).

Desde el punto de vista de la autentificación, también los usamos cada día muchos de nosotros. Algunos los usamos en forma de tarjetas de acceso para el trabajo, otros para realizar gestiones con la administración local o central del estado. Nuestro propio DNIe contiene 2 certificados digitales, uno de ellos expresamente para ser usado para tales fines.

Desde el punto de vista de la seguridad, es uno de los sistemas más fiables que existen para identificarnos, ya sean en forma de certificados digitales puros y duros o de alguna clase de sistema asimétrico. Si los protocolos están bien implementados y las claves privadas están a buen recaudo.

Un certificado digital identifica a una entidad/individuo/empresa por los datos identificativos que contiene, pero es gracias a la firma del emisor de dicho certificado quien le da genuinidad. Cualquiera puede crear un certificado digital con datos identificativos de cualquier cosa/persona… es más, es muy sencillo «duplicar» el certificado de quien sea para intentar suplantar su identidad. Por sí solo, un certificado sin firmar o sin una firma válida no pude aportar ninguna prueba de su legitimidad para terceras personas.

Llegados a este punto, hay que decir que no sólo existe un «modelo» o infraestructura PKI de certificados. Actualmente existen dos modelos de infraestructuras de clave pública de forma mayoritaria, y aunque ambos se basan exactamente en los mismos principios y su funcionamiento es similar, su principal diferencia radica en el sistema de «confiabilidad» que cada uno usa: Certificados X.509 y «Certificados» PGP

-Certificado X.509

Los certificados X.509 son a día de hoy los más extendidos y en los que se basa en esencia la seguridad día-a-día de Internet, todas las Webs HTTPs y otros.

Aquí la clave es la firma. Un certificado, para darle dicha legitimidad/integridad se debe de firmar. ¿Quien firma un certificado de este tipo? Normalmente el emisor de dicho certificado, aunque un certificado puede también autofirmarse.

Un certificado firmado y emitido por una entidad cual sea, tendrá validez para nosotros siempre que reconozcamos dicha entidad como genuina y confiable. La firma procederá de una autoridad de certificación (CA en inglés) que a su vez puede depender (dicho CA está a su vez firmado por otro CA) de la firma de otra CA, así hasta llega a lo que conocemos como autoridades de certificación raíces (Root CA). Los certificados CA raíces no están firmados por otro certificado superior, sino que están firmados por ellos mismos.

Este sistema dependerá por tanto de lo que consideramos entidades de certificación raíces legítimas, ya que serán en última instancia los emisores globales de los certificados legítimos, ya sea emitidos directamente por ellos, o emitidos por autoridades de certificación delegadas/creadas por ellos mismos. Si no confiamos en un CA determinado, todos los certificados que procedan de él, para nosotros, no nos aportarán seguridad, legitimidad y no nos aportarán integridad. Del mismo modo nos pasaría a nosotros si queremos disponer de un certificado digital personal, sólo si el CA que lo firma es identificado y confiable para aquel que use nuestro certificado, podrá fiarse que somos quien decimos que somos.

A lo largo de los años, este trabajo ha recaído en los navegadores Webs, en los gestores de correo electrónico en… los cuales han ido creando y manteniendo una pequeña base de datos de lo que consideran autoridades de certificación confiables. Si creen que un CA es confiable, añaden el certificado raíz de dicho CA a su software y lo marcan como legítimo, de modo que si interaccionamos con cualquier certificado emitido por dicho CA con dicho software, el software que usamos lo tomará por legítimo.

Estas compañías/empresas usan sistemas extremadamente rigurosos a la hora de mantener dichos certificados en sus software, exigiendo niveles concreto de seguridad, políticas, auditorías constantes… y por supuesto tienen la última palabra y decisión de añadir/eliminar cualquier certificado que así estimen.

Esto tiene un impacto enorme en el usuario, ya que de la noche a la mañana miles, decena de miles…. de certificados digitales pueden verse inmediatamente como no confiables si dichas compañías estiman que la autoridad implicada ya no es confiable. Por supuesto, siempre podremos forzar e instalar un CA que consideremos confiable en el software que sea, y así poder dar validez a los certificados que emita, pero será para nosotros, si dicho CA no está reconocido por desarrolladores de software conocidos, su ámbito será reducido, válido sólo para nosotros, y en todo caso para aquellos que igualmente los hayan autorizado

-Certificado PGP

Ya he hablado de PGP también hace años. PGP/OpenGPG funciona de un modo muy similar al que usan los certificados X.509. Se usan igualmente las claves públicas/privadas para cifrar o firmar contenido. Obviamente existen multitud de diferencias entre ambos sistemas, pero lo que realmente hace diferente al sistema es lo que llamamos «cadena de verdad», es decir, quien realmente dice que un certificado o una clave pública es legítima. Podemos falsificar los datos de un certificado sin problema, en los certificados X.509 son en última instancia autoridades de certificación reconocidas las que nos dicen que el certificado es legítimo.

En sistema PGP/OpenGPG llegó entre otras cosas para evitar la centralización de estas entidades, eliminar el poder que a día de hoy mantienen los CA, y devolverle dicho poder a los propios usuarios. En PGP/OpenGPG la figura de CA desaparece, y son los propios y diferentes usuarios los que van firmando las claves públicas de otros usuarios en los cuales confían, generando así una cadena de confianza, y como el sistema es «universal», dichos certificados/claves públicas se almacenan por mayor comodidad en repositorios abiertos que cualquiera puede consultar, e incluso firmar cualquier clave pública que confían.

Un ejemplo sencillo. Creo un «certificado» GPG con mis datos. Lo he creado yo, podría usar mis datos o los de cualquiera, pero escojo usar los míos. El certificado lo publico en un repositorio para que cualquiera pueda acceder a mi clave pública, y con ella desencriptar o verificar las firmas que yo mismo hago con mi clave privada. ¿Como puede un tercero tener la seguridad que dicha clave privada es realmente mía?

Una opción, sería indicándole personalmente cual es el ID de mi clave antes de que la descargue del repositorio, o directamente se la podría enviar. Esto es útil pero poco práctico en gran escala. Pongamos ahora que mi clave pública lleva años usándose por amigos, familiares, conocidos… incluso a lo mejor alguna persona más famosilla en el mundillo. Todos ellos confían en mi clave pública, así que algunos de ellos firman mi clave pública con su clave privada, y dicha firma es visible.

La diferencia es simple. Con los certificados X.509 existe una firma única que damos por buena porque reconocemos el CA que la realiza. En PGP damos por bueno el certificado porque posee diferentes firmas de diferentes personas/entidades que creen o saben seguro que el certificado es válido, personas/entidades que a su vez pueden ser conocidos o no.

OpenGPG es un sistema mucho más democrático y en principio con menos… «mano negra». Pero esa también es su debilidad, con la facilidad de crear certificados GPG, es simple inundar los repositorios públicos con certificados falsos, haciendo que al final tengamos que pasar tiempo intentando adivinar cual de ellos pude ser legítimo, lo cual no siempre es sencillo. No obstante, gracias al correo electrónico que generalmente «enlazamos» a ella, nos sirve como identificador si lo que queremos es precisamente enviar un correo electrónico a dicha persona y que vaya cifrado y/o firmado.

En entornos más privados, no obstante, tanto GPG como los certificados X.509 son igualmente seguros y confiables, puesto que presuponemos que las claves públicas/certificados que manejamos son legítimas.

Clave Privada

Hemos hablado mucho de los certificados digitales, pero aun nada de la Clave Privada. La clave privada no es un dato que se incorpore a un certificado digital, no así la clave pública. Un certificado digital realmente es para uso de un tercero, para que puedan verificar nuestra identidad y obtener nuestros datos. La clave privada de dicho certificado, por otro lado, es para uso exclusivo del propietario del certificado, será dicha clave la que nos permitirá realizar firmas o realiza autentificaciones en los protocolos destinados para dicho fin. Sin la clave privada en nuestros dispositivos de un certificado dado, dicho certificado tiene la misma validez que para el resto del mundo, que el resto de certificados instalados en nuestro equipo.

La clave privada tiene un papel aun más importante. En el caso de las autoridades de certificación de certificados X.509, es la que permitirá emitir certificados firmados y confiables (siempre que dicho CA lo sea). Si la clave privada de un CA confiable cayese en malas manos, se podría duplicar el certificado del CA, y con él emitir todos los los certificados digitales fraudulentos que quisiésemos, y estos serían aceptados por navegadores, gestores de correos… la clave privada para los CA es el secreto mejor guardado, es de vital importancia que esté a muy buen recaudo. Por lo general, los CA raíces no emiten certificados finales por muchas cuestiones de seguridad, delegan dicha capacidad a otros CA inferiores que en el peor de los casos pueden revocar sin provocar un «apocalipsis» a un nivel mucho más importante.

Para el usuario, la clave privada normalmente está protegida en el mismo equipo, pero lista para usar por el navegador o la aplicación que sea. A veces bajo contraseña, pero la mayoría de las veces su uso es automático. Si no poseemos una copia de seguridad de la clave o del archivo que contiene tanto el certificado como la clave, no habrá forma de recuperarla. Es más, cuando se obtienen certificados confiables por parte de un CA que sea mínimamente serio, las políticas de obtención obligan que la clave privada sea creada en el propio dispositivo/equipo que realiza la solicitud, de forma que esta NO SEA NUNCA TRANSFERIDA por Internet. Lo ideal es que la clave privada esté siempre a buen recaudo, y si puede no estar en el propio equipo del usuario, mejor.

Hay que entender algo muy importante. Un certificado personal que sea confiable/verificable a nivel estatal como pueda ser el DNIe o los certificados Ceres, con su clave privada, tiene la misma validez que nuestro DNI físico, nuestra firma… podemos acceder a prácticamente cualquier servicio!! no es algo que vamos a querer que otros tengan o puedan tener.


Uso de Certificados Digitales

Una vez más, vamos a enfocarlo dentro de la autentificación, no del cifrado de datos/conexiones seguras.

En el mundo digital se llevan usando desde hace tiempo como el método más seguro de identificación. Los Certificados digitales están dentro de «Algo que tenemos» pero no está libre de problemas. Por un lado requerimos una buena infraestructura PKI para asegurar que los certificados son de quienes dicen son, y por otro lado está la cuestión de que dicho certificado no sea robado o usado por otra persona que no sea su legítimo dueño. A fin de cuenta, al ser «Algo que tenemos» es susceptible a sus problemas inherentes, pero eso lo veremos algo más tarde.

Usar un certificado digital puede ser desde una tarea sumamente simple si el sistema está bien implementado, a ser una tortura. Dependiendo de la aplicación que usemos, el certificado se usará de un modo o de otro. También hay que tener en cuenta que cualquier certificado no vale para cualquier tarea, los certificados marcan estas limitaciones o concretaciones, indicando el uso para el que fue emitido. Un certificado que fue emitido sólo para firmar, no debería de permitir la identificación en servidores TLS/SSL, el sistema debería de rechazar tal certificado.

Obtención

¿Como se pude obtener uno? Un certificado para uso propio, el cual no necesitamos que tenga un reconocimiento público, podemos crearlo cuando queramos con la finalidad que sea y con las propiedades que más nos gusten. En realidad es un certificado como cualquier otro, la única diferencia es que no estará firmado por un CA que sea confiable, y por ende cuando lo usemos, o mejor dicho cuando lo use la otra parte, tendrá que tener como confiable nuestro CA que lo ha emitido.

Existe multitud de software que permite crear los certificados que queramos. Windows tiene un administrador de certificados, OpenGPG tiene herramientas que permiten administrarlos, crearlos, modificarlos, OpenSSL es la suite posiblemente más conocida al respecto… En lo personal, hace años que encontré una aplicación multiplataforma, de código abierto, muy visual, sencilla y cómoda para quien no le gustan líneas de comandos, la recomiendo: XCA

¿Y que pasa si queremos un certificado confiable? Aquí la cosa se complica. Si queremos un certificado confiable tenemos que acudir a una autoridad de certificación que lo sea, y solicitar un certificado para el uso concreto que deseemos. El ejemplo más simple es cuando necesitamos un certificado para un servidor Web para permitir conexiones Seguras. A día de hoy gracias a Let’s Encrypt la cosa se ha hecho más sencilla y económica.

Pero existen multitud de certificados que podríamos necesitar. Por ejemplo certificados para firma de código, certificados para la firma/cifrado de correos electrónicos… y peor aun, en el caso que nos atañe, certificados de identificación y firma real. Dado que no existe un censo universal (menos mal), los certificados personales identificativos suelen tener un ámbito local, entendiendo por local un pueblo, una ciudad o incluso un país. Eso no quiere decir que el CA emisor no pueda ser confiable a nivel mundial.

En España, la forma más sencilla de obtener un certificado digital personal es simplemente no hacer nada. Nuestro DNIe ya los tiene, solo requerimos un lector de tarjetas, el PIN del DNIe y que los certificados estén en vigor. No obstante, no soy muy fan del DNIe, lo han complicado tanto que su uso resulta muchas veces torpe, lento, propenso a problemas… es cierto que Windows dispone de un Minidriver ya listo para usarse, y librerías PKCS#11, pero su uso es muy limitado. Su uso se restringe tan solo a la autentificación y a la firma, y el CA emisor, AC RAIZ DNIE, dependiendo de de la Dirección General de la POlicia, no es confiable desde un punto de vista externo. Esto quiere decir que por ejemplo no podríamos usarlo para autentificar/firmar correo electrónico por ejemplo (tiene sentido, el DNIe no posee información de nuestro correo electrónico), y que además para poder usarlo incluso en nuestros propios sistemas, tendremos que tener añadidos manualmente los certificados raíces e intermedios de este.

Tenemos por suerte otra opción, en España tenemos otra entidad de certificación, que emite certificados más laxos, con la misma validez que el DNIe desde el punto de vista de nuestras instituciones (con lo que podemos usarlo como queramos en la administración), y que además dicho CA está reconocido a nivel internacional como confiable, lo que implica que vayamos a donde vayamos nuestro certificado será para todos los efectos legítimo. Lleva funcionando bastante antes de la aparición del DNIe: La FNMT, la fábrica nacional de moneda y timbre, a través de la iniciativa CERES.

Cualquiera en España puede solicitar su certificado CERES. Lo primero es realizar la solicitud del certificado, conocido como el CSR (Certificate Signing Request), desde la propia página. En dicho proceso se completará un formulario de solicitud y el navegador generará una clave privada, que de aceptarse, completará el certificado una vez la solicitud sea aceptada. A partir de aquí, si se ha realizado por el modo tradicional será necesario acudir a un punto de la administración para identificarnos y solicitar la aceptación de la petición, para volver al mismo navegador Web que generó el CSR y poder así instalar en dicho navegador el certificado. También es posible realizar la solicitud de forma íntegra sin movernos de casa con el DNIe.

Los CSR son las piedras vehiculares por las que el 99% de las veces obtenemos nuestros certificados de otras entidades. El usuario rellena los datos identificativos con los que desea que se conforme el certificado, partiendo de una plantilla que por lo general la suministra el CA. Por seguridad, el CA no generará nunca la clave privada del usuario, esa es personal e intransferible, con lo que se suele generar en el lado del propio usuario, adjuntando al CSR por ende la clave pública de este. Dicho CSR es enviado al CA, que de aceptarlo, conforma el certificado por completo y lo firma, devolviéndolo al usuario, que es de suponer ya poseerá su clave privada.

Veamos para acabar un par de ejemplos de uso: El primero, el uso de un certificado digital para firmar y/o cifrar un correo, con un certificado confiable para Google que será capaz de verificar la firma.

Gmail permite incluso desencriptar los correos cifrados si se posee una cuenta empresarial, y se tienen los certificados correctamente instalados. Los mensajes cifrados en última instancia se adjuntan como archivos p7m, la firma dentro de el propio mensaje cifrado. Por el contrario si sólo se firma, la inmensa mayoría de gestores de correos la parsearán correctamente y lo identificarán como firma. Una firma que no se ha podido verificar no significa que no sea confiable necesariamente, sino que el proveedor o servicio o equipo que la intenta verificar puede que no posea el certificado del CA emisor como confiable. Gmail por ejemplo toma por confiable solo un pequeño puñado de CA.

Si tenemos un certificado instalado y visitamos cualquier sitio que requiera identificación por certificado, obtenemos algo similar a lo mostrado. El servidor se identifica ante nosotros siempre, DGT en el ejemplo, y permite seleccionar un certificado instalado para permitir o denegar el acceso.

El certificado mostrado no está firmado por una entidad reconocible para la DGT, ni posee el formato requerido para que permitan mi acceso al sistema, con lo que lanzará un error. Que un certificado proceda además por un CA confiable a nivel mundial, no quiere decir que cualquier sistema vaya a permitir el acceso a él, aunque dicho usuario pertenezca al sistema. El sistema puede requerir que el emisor del certificado, además de confiable, pertenezca a una lista muy corta, o como he dicho que el certificado incluya datos identificativos concretos.


Tarjetas de Acceso: (Inteligentes/Criptográficas)

Sin entrar en el mundo cuántico u otros sistemas de codificación exóticos que serían dignos de la ciencia ficción, la criptografía asimétrica es la base en los tiempos modernos de la seguridad. Pero no es perfecta ni mucho menos. Sus imperfecciones no se basan tanto en sus fallos de diseño, sino en el factor humano.

En un principio dijimos que podríamos definir un sistema «totalmente» segundo cuando lográsemos sumar algo que somos, algo que tenemos y algo que sabemos. Los sistemas asimétricos como puedan ser los certificados digitales, sin duda alguna es algo que tenemos, pero encontramos problemas:

Es algo que tenemos, no tenemos capacidad de memorizar claves privadas de 256bits (para curvas elípticas) y mucho menos claves de 2048bits (para RSA). Algo que tenemos, por ende, es algo que puede ser sustraído, olvidado, almacenado en un lugar inseguro. Un cifrado asimétrico puede ser totalmente seguro, pero si nuestra clave es expuesta, nos va a valer para poco.

Existen otros peligros bien consabidos que harán que en el futuro estos sistemas dejen de ser seguros: Computación cuántica. Los ordenadores cuánticos están empezando a ser viables, aunque posiblemente aun tengan que pasar décadas para que sean una realidad cuantitativa. Pero ese día llegará, y cuando llegue, teóricamente, muchos de los problemas de computación en los que se basa el paradigma de la criptografía asimétrica, dejarán de ser seguros. Por ahora estamos seguros, pero llegará el día que la computación cuántica pueda resolverlo literalmente al instante.

No podemos hacer nada para evitar que dentro de X años el mundo cuántico deje inservible la seguridad actual, pero sí podemos tomar medidas para evitar los problemas de sustracciones, pérdidas, olvidos… de claves privadas: Tarjetas criptográficas o tokens de seguridad.

Cualquiera que mire su cartera, tendrá dentro de ella muy posiblemente varias de estas. Algunas usarán criptografía asimétrica, otras usarán criptografía simétrica. Si tiene un chip, muy posiblemente sea una tarjeta criptográfica. No existe un estándar único, el estándar rige la comunicación entre las tarjetas y los lectores externos, pero lo que hay dentro de ellas, depende únicamente del fabricante.

A pesar que son muy variadas, todas más o menos se rigen por el mismo principio: Ser una caja negra, almacenar algún secreto y realizar algunas operaciones dentro de la propia tarjeta. Tarjetas de crédito?? Usan criptografía asímetrica/simétrica. La mayoría de tarjetas de acceso? Criptografía asimétrica. No hay que confundir este tipo de tarjetas con las que podemos denominar como «tarjetas de memoria». La mayoría de tarjetas de transporte, de hoteles… (ya tengan chip o por NFC) no suelen ser tarjetas criptográficas, sino tarjetas de memorias que lo hacen es almacenar en sus celdas internas información estructurada concreta, como por ejemplo los viajes que nos quedan, la habitación asignada y el código de apertura… eso no quita que el acceso a dicha memoria esté protegido, pero no son tarjetas criptográficas.

Otra característica que por lo general todas llevan consigo es la existencia de un PIN de acceso. Ya hemos hablado de ello. Las tarjetas criptográficas nos permiten almacenar en ellas certificados u otras credenciales, y llevarlas con nosotros allá donde las necesitemos. Eso nos quita la limitación de memorizar claves privadas enormes, y que esta sea portable, pero sin un PIN estaríamos igualmente vendidos, cualquiera podría usarla sin nuestro consentimiento si se apoderase de ella. Con un PIN esto se elimina, haciendo que las tarjetas criptográficas, ellas solas, cumplan con «Algo que tenemos» y «Algo que sabemos», por ende, infinitamente más seguro que cualquier contraseña o sistema que hayamos podido ver hasta ahora.

Dado que son demasiado extensas, vamos a centrar la atención en las tarjetas criptográficas «genéricas», por ejemplo la tarjeta CERES, tarjetas OpenGPG y tarjetas PIV (Personal Identity Verification). Sí, la misma fábrica de moneda y timbre que emite certificados CERES pone a disposición de quien lo quiera tarjetas criptográficas para almacenar y proteger los certificados digitales.

Por último y no menos importante, aunque el formato habitual sigue siendo una «tarjeta», hay que entender que a día de hoy las tarjetas se han sustituido realmente por un concepto más genérico llamado «Token». Una tarjeta de acceso puede ser un token si dicho token tiene la funcionalidad de actuar como una tarjeta, aunque no tenga un chip de contactos expuesto y tenga que ser leída por NFC o por USB (por ejemplo)

Tarjeta CERES

No es la más bonita del baile, asumémoslo, y tampoco es la más versátil. Pero a su favor hay que decir que lleva con nosotros mucho tiempo, que es muy interesante ver como el Estado pone a disposición de cualquiera una tarjeta criptográfica que puede llegar a ser extremadamente útil, a un precio bastante adecuado. Los años no ha hecho que evoluciones demasiado, pero también esto tiene una cierta lógica… la tarjeta CERES en principio se diseñó para los certificados CERES. Eso no quiere decir ni mucho menos que no pueda albergar otro tipo de certificados (con su clave privada correspondiente), pero siempre y cuando no exceda las prestaciones de dicha tarjeta.

La tarjeta CERES es capaz de almacenar hasta 10 certificados, pero solo trabaja con RSA y con claves de hasta 2048bits. Esto implica que no se pueden almacenar certificados de clave elíptica o certificados RSA de 3072/4096bits. En cuanto criptografía simétrica es capaz sólo de usar 3DES, y para Hashing SHA1. Se queda fuera el uso de SHA256 y AES.

No obstante, no es una mala opción. Es barata, y la mayoría de certificados cumplen los requisitos. Espero que no pase demasiado para que lancen una revisión de sus tarjetas. En lo personal las llevo usando desde hace muchos años y no he tenido grandes problemas.

La inmensa mayoría de este tipo de tarjetas se basan en el estándar PKCS#11, protocolos y normas para gestionar este tipo de hardware, no solo tarjetas criptográficas ojo, a estas las llamamos tarjeta porque tienen dicho formato, pero podría ser un pendrive, un colgante…

PKCS11, aunque sea un estándar, dado que fabricante hace las tarjetas como quiere, es el propio fabricante que por lo general debe de suministrar bibliotecas/driver PKCS11 para el uso de sus tarjetas. Eso implica que para poder usar dichas tarjetas requeriremos el software necesario para… «gestionarlas», y es donde los módulos PKCS11 tienen su razón de ser. Cabe mencionar el gran trabajo de los chicos de OpenSC de crea un software multiplataforma para intentar dar cabida al máximo número de tokens/tarjetas posibles.

Dicho esto, el uso de las tarjetas CERES no es complicado. Se requiere por un lado la tarjeta, el certificado completo que queramos usar (con su clave privada), un lector de tarjetas y el software de CERES, ya sea en forma independiente de módulo PKCS11 o del propio software que la entidad distribuye. Se configura inicialmente con el PIN deseado, se importan los certificados y listo, preparada para funcionar. Por suerte además, desde hace ya tiempo, Windows incorpora un Minidriver CERES (y DNIe también), lo que hace que el propio sistema sea capaz sin módulo PKCS11 el acceder a la propia tarjeta.

Recordar que el certificado CERES es válido para la firma y cifrado de correo electrónico, un plus a tener en cuenta.

pkcs11-tool.exe --module fnmt-pkcs11.dll -M
Using slot 0 with a present token (0x10000)
Supported mechanisms:
  RSA-PKCS, keySize={1024,2048}, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,2048}, decrypt, sign, verify
  RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, generate_key_pair

pkcs11-tool.exe --module fnmt-pkcs11.dll -L
Available slots:
Slot 0 (0x10000): ACS CCID USB Reader 0
  token label        : TC-FNMT v2
  token manufacturer : TC-FNMT2
  token model        :
  token flags        : login required, rng, token initialized, PIN initialized
  hardware version   : 17.67
  firmware version   : 4.48
  serial num         : xxxxxxxxxx0000
  pin min/max        : 4/16

pkcs11-tool.exe --module fnmt-pkcs11.dll -O
Using slot 0 with a present token (0x10000)
Certificate Object; type = X.509 cert
  label:      MI NOMBRE - MI DNIE
  subject:    DN: C=ES/serialNumber=MIDNI, SN=APELLIDOS, GN=NOMBRE, CN=APELLIDOS NOMBRE - DNI
  ID:         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Certificate Object; type = X.509 cert
  label:      MI NOMBRE2 - MI DNIE2
  subject:    DN: C=ES/serialNumber=MIDNI2, SN=APELLIDOS2, GN=NOMBRE2, CN=APELLIDOS2 NOMBRE2 - DNI2
  ID:         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...

Prueba de Firma:

pkcs11-tool.exe --id IDClavePrivada -s -p PIN_TARJETA -m RSA-PKCS --module fnmt-pkcs11.dll --input-file prueba_firma.txt --output-file prueba_firmada.txt
Using slot 0 with a present token (0x10000)
Using signature algorithm RSA-PKCS
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Tarjeta OpenGPG

Al igual que los certificados X.509 se movieron rápido para poder se almacenados de forma segura en tarjetas criptográficas, lo mismo sucedió con los certificados PGP. Su funcionamiento y finalidad es muy similar, aunque responde a sus propios estándares. Dado que en OpenGPG es habitual almacenar/tener diferentes claves para diferentes usos, las tarjetas OpenGPG se hacen también eco de ello, almacenando en ellas mismas las Claves que creamos que son necesarias.

Lo que logramos es lo mismo, es llevar con nosotros nuestras claves en algo que tenemos y protegidas por algo que sabemos. Al igual que sucediese con las tarjetas criptográficas basadas en PKCS11, las tarjetas OpenGPG requieren de su propio software para ser usadas, aunque usa otros protocolos desarrollados por OpenGPG. A día de hoy el software OpenGPG como PKCS11 está sumamente extendido en todo tipo de aplicaciones.

De nuevo, funcionamiento similar, uso parecido. El uso depende al final de las aplicaciones que queremos usar, del modelo que queramos escoger o el que nos obliguen a tener

Al igual que las tarjetas convencionales, una tarjeta OpenGPG puede ser una tarjeta, o una minitarjeta, o estar contenida en un token de seguridad, o en un dispositivo tipo Pendrive…

gpg --card-status
Reader ...........: ACS CCID USB Reader 0
Application ID ...: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0000
Version ..........: 2.1
Manufacturer .....: N/A
Serial number ....: XXXXXXXX
Name of cardholder: Theliel
Language prefs ...: es
Sex ..............: hombre
URL of public key : hkps://pgp.rediris.es
Login data .......: Theliel
Signature PIN ....: no forzado
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 1
Signature key ....: 219A
8551 6BC9 CC2F C1BC  DDAF C3FB 5679 4699 44F1
      created ....: 2019-04-12 22:56:00
Encryption key....: E188 61CF 30EC 58D1 1833  E7F6 A979 81A8 1F48 923D
      created ....: 2019-04-12 22:39:20
Authentication key: AF46 FFDC 780B FE4A 5510  8591 49C7 3ACB 2734 2031
      created ....: 2019-04-12 22:54:37
General key info..: sub  rsa4096/C3FB5679469944F1 2019-04-12 Theliel <spam@theliel.es>
sec   rsa4096/0DF15BC22FD01DA4  creado: 2019-04-12  caduca: 2029-04-09
ssb>  rsa4096/A97981A81F48923D  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635
ssb>  rsa4096/49C73ACB27342031  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635
ssb>  rsa4096/C3FB5679469944F1  creado: 2019-04-12  caduca: 2029-04-09
                                num. tarjeta: 0006 09580635

Tarjetas PIV

Aunque es un invento americano, su uso está muy extendido. Son tarjetas/token criptográficos estructurados de modos muy concretos, usados como tarjetas de identificación personal. Desde un punto de vista funcional, se podría ver como algo similar a la tarjeta Ceres, aunque las tarjetas PIV están completamente estructuradas como digo. Estas tarjeats se consideran de alta seguridad, repito que son las usadas por el gobierno americano.

Las tarjetas PIV se dividen en diferentes slots o compartimentos, en los cuales se pueden insertar diferente tipo de información, desde certificados, claves privadas a incluso datos biométricos.

De forma genérica se usan 4 slots principales: Autentificación, Firma, Cifrado y Autentificación Directa. Cada uno de ellos almacena como es natural el certificado necesario, y por supuesto, su clave privada. En teoría la idea es que cada slot almacene un certificado específico para su función específica. Así el Slot para Autentificación debería de almacenar solo un certificado para dicho propósito, y no para firmar o para cifrar. Lo mismo sucede con los slots de firma o de cifrado. Por su parte el slot de autentificación directa es algo especial, ya que el uso de dicho certificado no requeriría la introducción de un PIN, sino que la clave privada almacenada se podría usar automáticamente. La utilidad de esta es simple… ese Slot podría contener un certificado de autentificación para puertas de acceso por medio de lectores de tarjetas, en las que solo hiciese falta introducir la tarjeta y sacarla. Si cada Slot contiene un certificado diferente con propósitos concretos, dicho certificado solo valdría para esas puertas, mientras que para seguridad avanzada se podría usar el otro.

Técnicamente, las tarjetas PIV no obligan a que el certificado almacenado en cada Slot tenga un propósito u otro. Es decir, si la tarjeta PIV es nuestra y la gestionamos nosotros, podríamos tener en el Slot de Autentificación directa un certificado de firma que no requiriese contraseña, o usar en el de firma un certificado de autentificación firma y cifrado. Serían los entornos donde se desplegase la infraestructura la que estaría preparada para leer en cada caso el certificado necesario. No pensar ahora a modo individual, pensar en un agente del gobierno. Pensar que se le otorga una tarjeta PIV que contiene 4 certificados diferenciados, y el agente los usa en las instalaciones incluso sin tener ni idea bien de como funciona la tarjeta, solo que tiene un PIN, que requiere introducirla para acceder a las instalaciones o introducirla cuando redacta un correo para que se cifre o….

Además de los 4 slots principales, las tarjetas PIV permiten almacenar datos biométricos, o incluso más de una decena slots para certificados u claves «viejos/revocados/retirados», que podrían ser necesarios para por ejemplo desencriptar o validar firmas de correos/documentos más viejos.

Todo esto hace que las tarjetas PIV puedan usarse de mil formas diferentes. Por ejemplo, con alguna modificación se podría usar como una «tarjeta CERES» en la que se podrían almacenar algo más de 20 certificados diferentes, o almacenar/usar certificados con claves más complejas si nuestra tarjeta PIV lo soporta.

De forma similar al resto de tarjetas, permiten por regla general su uso/gestión por PKCS11, aunque PIV usa en algunos procedimientos diferentes, y el fabricante de la tarjeta PIV así mismo debería de suministrar las herramientas necesarias para su correcto funcionamiento. Por supuesto, como otras tarjetas/token requiere de un PIN para la mayoría de procedimientos. Veamos mi tarjeta PIV de ejemplo leída por NFC. En mi caso no tengo actualmente ningún certificado en los slots principales, actualmente uso los slots «retirados» para uso diario. Como la infraestructura donde los uso no obliga a leerlos desde un slot concreto, los puedo usar como certificados/claves genéricas sin mayor problema.

Datos básicos:

pkcs15-tool.exe --list-info
Using reader with a card: ACS ACR122 0
PKCS#15 Card [Theliel]:
        Version        : 0
        Serial number  : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        Manufacturer ID: piv_II
        Flags          :

pkcs11-tool.exe -M
Using slot 0 with a present token (0x0)
Supported mechanisms:
  SHA-1, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,384}, hw, sign, other flags=0x1800000
  ECDH1-COFACTOR-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  ECDH1-DERIVE, keySize={256,384}, hw, derive, other flags=0x1800000
  RSA-X-509, keySize={1024,3072}, hw, decrypt, sign, verify
  RSA-PKCS, keySize={1024,3072}, hw, decrypt, sign, verify
  SHA1-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA256-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA384-RSA-PKCS, keySize={1024,3072}, sign, verify
  SHA512-RSA-PKCS, keySize={1024,3072}, sign, verify
  MD5-RSA-PKCS, keySize={1024,3072}, sign, verify
  RIPEMD160-RSA-PKCS, keySize={1024,3072}, sign, verify

En comparación con la tarjeta CERES, mi tarjeta PIV es capaz de realizar un inmenso número de operaciones adicionales, sin contar que es capaz de almacenar claves RSA de hasta 3072bits, claves elípticas de 256 y 384bits, derivaciones de claves… e incluso realizar Hash a datos de entrada:

pkcs11-tool.exe -m SHA-1 -h --input-file prueba_firma.txt
Using slot 0 with a present token (0x0)
Using digest algorithm SHA-1
¶+»úàs0¤YDd?hüçö

pkcs11-tool.exe -v -m SHA256 -h --input-file prueba_firma.txt
Using slot 0 with a present token (0x0)
Using digest algorithm SHA256
■Â¥Åä<6°»┐2yêoäSòv▄ïÄÉJ:ÔÁ║[╩

Se imprime «basura» por la codificación ASCII de la salida hexadecimal.

Podríamos realizar una lectura completa de la estructura de la tarjeta PIV también, gracias a las utilidades de OpenSC:

pkcs15-tool.exe -C -s
Using reader with a card: ACS ACR122 0
Card has 32 Data object(s).
        Path:db00          2.16.840.1.101.3.7.1.219.0  Size:   53  Card Capability Container
        Path:3000          2.16.840.1.101.3.7.2.48.0  Size:   61  Card Holder Unique Identifier
        Path:3010          2.16.840.1.101.3.7.2.48.2Data object read failed: File not found
        Path:0101          2.16.840.1.101.3.7.2.1.1Data object read failed: File not found
        Path:6010          2.16.840.1.101.3.7.2.96.16  AuthID:01   Cardholder Fingerprints
        Path:3001          2.16.840.1.101.3.7.2.48.1  AuthID:01   Printed Information
        Path:6030          2.16.840.1.101.3.7.2.96.48  AuthID:01   Cardholder Facial Image
        Path:0100          2.16.840.1.101.3.7.2.1.0Data object read failed: File not found
        Path:0102          2.16.840.1.101.3.7.2.1.2Data object read failed: File not found
        Path:0500          2.16.840.1.101.3.7.2.5.0Data object read failed: File not found
        Path:9000          2.16.840.1.101.3.7.2.144.0Data object read failed: File not found
        Path:6050          2.16.840.1.101.3.7.2.96.80  Size:   20  Discovery Object
        Path:6060          2.16.840.1.101.3.7.2.96.96  Size:   10  Key History Object
        Path:1015          2.16.840.1.101.3.7.2.16.21Data object read failed: File not found
        Path:1001          2.16.840.1.101.3.7.2.16.1  Size:  936  Retired X.509 Certificate for Key Management 1
        Path:1002          2.16.840.1.101.3.7.2.16.2  Size: 1703  Retired X.509 Certificate for Key Management 2
        Path:1003          2.16.840.1.101.3.7.2.16.3  Size: 1711  Retired X.509 Certificate for Key Management 3
        Path:1004          2.16.840.1.101.3.7.2.16.4  Size: 1914  Retired X.509 Certificate for Key Management 4
        Path:1005          2.16.840.1.101.3.7.2.16.5  Size: 1717  Retired X.509 Certificate for Key Management 5
        Path:1006          2.16.840.1.101.3.7.2.16.6Data object read failed: File not found
        Path:1007          2.16.840.1.101.3.7.2.16.7Data object read failed: File not found
        Path:1008          2.16.840.1.101.3.7.2.16.8Data object read failed: File not found
        Path:1009          2.16.840.1.101.3.7.2.16.9Data object read failed: File not found
        Path:100a          2.16.840.1.101.3.7.2.16.10Data object read failed: File not found
        Path:100b          2.16.840.1.101.3.7.2.16.11Data object read failed: File not found
        Path:100c          2.16.840.1.101.3.7.2.16.12Data object read failed: File not found
        Path:100d          2.16.840.1.101.3.7.2.16.13Data object read failed: File not found
        Path:100e          2.16.840.1.101.3.7.2.16.14Data object read failed: File not found
        Path:100f          2.16.840.1.101.3.7.2.16.15Data object read failed: File not found
        Path:1010          2.16.840.1.101.3.7.2.16.16Data object read failed: File not found
        Path:1011          2.16.840.1.101.3.7.2.16.17Data object read failed: File not found
        Path:1012          2.16.840.1.101.3.7.2.16.18Data object read failed: File not found

Conclusiones Finales

La criptografía asimétrica/simétrica y por extensión los certificados digitales, son a día de hoy posiblemente los fundamentos más sólidos a nivel práctico que disponemos para nuestra seguridad. Gracias a los principios RSA y más tarde a los algoritmos de curvas elípticas, podemos crear sistemas e infraestructuras realmente seguras.

Pero todo tiene su peligro. Recordar que un certificado digital puede poseer un valor increíblemente alto si tenemos en cuenta que, algunos de ellos, pueden usarse a todos los efectos de forma legal. Llevo años combatiendo contra gestorías, e informando a amigos/familiares/conocidos de los peligros que acarrear ceder nuestro certificado a ellos. Un gran número de personas, y cada vez más, delegan en gestorías la administración de todo sus papeleos, desde cualquier asunto fiscal (IRPF, IVA…), alquileres, facturaciones… esto me parece perfecto. El problema aparece cuando la INMENSA MAYORÍA de las gestoras solicitan al cliente que les proporcione su certificado digital personal para poder obrar en su nombre.

Esto es una barbaridad, es ilegal, es extremadamente peligroso. Ceder nuestro certificado a un tercero, además repito de ser ilegal, implica que ese tercero podría firmar cualquier documento con plena capacidad legal, podría acceder prácticamente a todos nuestros datos: Médicos, fiscales, financieros… y en la mayoría de los casos también operar sobre ellos. La excusa que las gestoras esgriman es que así el cliente no tiene que ir a las administraciones o preocuparse de presentar nada. En realidad esto no es cierto tampoco, porque la mayoría de los trámites se puede autorizar a un gestor para que nos los presenten, e irán presentados bajo SU NOMBRE y responsabilidad, aunque a nuestro nombre, y más importante, sin acceso a nuestro certificado digital.

Cada vez que explico esto a algún amigo termina con las manos en la cabeza. Sí, se ha entendido bien, cuando le damos nuestro certificado al gestor, le estamos entregando literalmente nuestra vida. El certificado digital es algo en extremo delicado que jamás se debería de ceder a nadie, podría ser cómodo en un momento dado dejarlo a un tercero, pero aun cuando dicho tercero fuese de plena y total confianza, no es algo que no haya que pensar y mucho. Y a un tercero que nos cobra por ello… en la vida.

Y la cosa puede ponerse peor… nada ni nadie nos asegura que aun cuando dicho gestor fuese honrado, su equipo fuese comprometido por una cuarta persona, ya fuese alguien de su entorno, ya fuese un hacker, ya fuese un ladrón que roba su equipo… JAMÁS, NUNCA, deis vuestro certificado a nadie, y menos a un gestor. Y quien ya haya caído en ello, es muy simple: Primero notificar al gestor que a partir de ahora todos los trámite los presentará a su nombre y en todo caso lo autorizaremos, y si tampoco es posible, presentaremos nosotros mismos los documentos. Y en segundo lugar, aunque nos asegure que ha borrado el certificado tampoco podemos creerlo, deberemos realizar una nueva solicitud, ya que al realizarla automáticamente se revocará el certificado anterior.

En otro orden de cosas, el uso de tarjetas criptográficas es igualmente recomendable para aquellos que hacen un uso habitual de sus certificados. Instalarlos en los equipos es peligroso por las razones ya expuestas. A día de hoy hay tarjetas criptográficas de todo tipo. La tarjeta CERES solo es una de muchas. Un lector de tarjetas parece algo incómodo para trabajar con los certificados, pero pensad que tenemos tarjetas/tokens que pueden conectarse por USB o por NFC incluso, la dejamos caer sobre el lector NFC, trabajamos normalmente (introducimos el PIN si se requiere) y la cogemos al acabar. Fácil, cómodo y seguro.

¿Podemos mejorar la seguridad aun más? Sí, aun podemos mejorarla algo más como veremos en capítulos siguientes. Con tarjetas/tokens criptográficos logramos usar «Algo que tenemos» y «Algo que sabemos», pero pronto podremos también usar «Algo que somos», y el uso de sistemas dobles. Al final se trata de lo mismo, poner capas que puedan ser en la medida de lo posible lo más transparente posible para el usuario, y que solucione las deficiencias de otros sistemas. El sistema perfecto no existe ni existirá, pero podemos acercarnos mucho a él.

La Autentificación en tiempos modernos. Concepto de PIN y Módulos TPM

A partir de este punto, el PIN es algo que vamos a nombrar en estos artículos de forma habitual. Así que es muy importante que se sepa que es realmente un PIN. Esto es debido a que todo el mundo cree saber que es un PIN, la inmensa mayoría lo usa a diario, ya sea para pagar con tarjetas de crédito, sacar dinero, desbloquear el teléfono o la tarjeta SIM… pero es una de esas raras paradojas en las que todo el mundo puede hablar de él y lo usa, pero raro es encontrar con alguien que realmente sepa lo que es.

Sobre lo TPM, también nos van a acompañar el resto del viaje, a veces los olvidaremos, pero estarán detrás de todo… al menos la mayoría de las veces.

En un principio iba a crear este capítulo en otra de las publicaciones, pero he pensado que era mejor dedicarle unas palabras específicamente.


El PIN

Bien… ¿que es un PIN? Si preguntamos a cualquiera, la mayoría te diría que es una contraseña, o la contraseña del móvil, o la contraseña de la tarjeta o… pero obviamente no es una contraseña, es un PIN. Otros dirán en cambio que básicamente es una contraseña «simple», numérica, de 4 dígitos. Pero realmente un PIN puede ser también una cadena con la longitud y complejidad que se quiera.

El PIN entra dentro de «Algo que sabemos», pero no es un «secreto» como una contraseña. Obviamente no queremos que nadie lo sepa, pero a diferencia que (generalmente) las contraseñas, el que alguien sepa un PIN nuestro no les da utilidad por sí solo, porque, y esta es la primera gran diferencia a una contraseña, un PIN está asociado a un dispositivo físico. Puede ser una tarjeta de crédito, un teléfono, una SIM, un módulo TPM…

Por lo geneal un PIN va a proteger el acceso a «algo que tenemos» o incluso «algo que somos«. El PIN por sí mismo no vale para nada, es necesario el dispositivo específico, con lo que alguien tendría que apoderarse de ello antes.

Otra gran ventaja de un PIN, es que al estar asociado de forma directa al dispositivo que sea, su tratamiento siempre es local. Esto es muy importante, cuando usamos un PIN, sea donde sea, no estamos transmitiéndolo hacia ningún lado, no es una contraseña que introducimos y termina en los servidores remotos. El PIN nunca abandona el dispositivo para el que fue configurado. Además, sea en una tarjeta inteligente, en un módulo TPM, en una tarjeta SIM… van a existir siempre mecanismos de protección hardware y de control de acceso, lo cual evita posibles ataques contra el mismo dispositivo. Pensemos en el caso más sencillo de una tarjeta SIM, solo basta con introducir 3 veces mal el PIN para que esta se bloquee y requiera un PUK, el cual a su vez también se puede bloquear, dejando la SIM inservible.

Otra ventaja más, la propia naturaleza del PIN y las medidas de protección que por lo general están presenten en el dispositivo, hace que pueda ser mucho más simple que una contraseña sin dejar de ser seguro. Volviendo al caso de una SIM de teléfono, un PIN de 4 números suele ser más que suficiente, si alguien quisiese acceder a nuestra SIM, aun sabiendo que es un PIN de 4 dígitos, tendría 10.000 posibilidades. Un ordenador calcularía eso al instante, el problema es que el SIM al tercer PIN que no fuese correcto bloquearía.

En los medios de Autentificación, por lo general siempre que exista un elemento hardware, del tipo que sea, suele estar presente (al menos opcionalmente) un PIN, que desbloquea por un modo u otro el acceso a un autentificador dado.

En la Biometría es algo común. Podemos configurar nuestros teléfonos para acceso por Huella dactilar o reconocimiento Facial, pero… sorpresa!! El primer acceso se hace siempre por PIN/Contraseña/Patrón. Además, e independientemente, la biometría no es una piedra filosofal, y depende como es natural de las condiciones del entorno, del elemento Hardware… así que muchas veces no es posible por la razón que sea hacer uso de los medios biométricos. siendo el uso de un PIN/Contraseña/Patrón moneda común. Imaginad que queréis desbloquear el teléfono con el dedo, y el dedo que estaba registrado sufre cualquier problema temporal/permanente que impide su uso.

En las tarjetas inteligentes, que veremos más tarde, exactamente igual. Ya sean tarjetas de crédito, el mismo DNI Electrónico, una tarjeta de acceso… el PIN es «la llave», a todos ellos. ¿Por qué es tan necesario? Porque al igual que una contraseña, entra como decía dentro del «Algo que Sabemos», es un modo simple y seguro de demostrar que un elemento hardware «Algo que tenemos» es nuestro, somos su propietario y solo responde ante nosotros. Si perdemos una tarjeta criptográfica, perdemos el valor en el peor de los casos de lo que lleve dentro, pero por lo general lo que llevase dentro está salvaguardado.


Los Modulos TPM

Con los módulos TPM (Trusted Platform Module) sucede lo mismo, cada día son más esenciales, y es importante hablar aunque sea un poco de ellos, aunque merecerían todo un artículo. Los módulos TPM son pequeños sistemas microprocesados de seguridad, que realizan un buen número de funciones, como por ejemplo (pero no exclusivamente) la generación de claves, calcular Hash, encriptar/desencriptar contenido… y todo eso a nivel hardware. Son almacenes también de seguridad de credenciales.

Si nos vamos unos años hacia atrás, el uso de los TPM era marginal, algunos equipos portátiles los traían cuando eran orientados a empresas y alguno que los quería en equipos de sobremesas. Con la necesidad de una mayor seguridad, mejores tecnologías y el aumento también de los dispositivos móviles, los módulos TPM se han extendido enormemente. Incluso la mayoría de los Móviles/Tablets actuales tienen zonas de seguridad en el SoC. QualComm lo llama TrustZone, Apple lo llama SEP. En realidad TrustZone o SEP no son realmente TPMs, pero tienen algunas de sus funciones. El problema de los módulso TPM es que no se crearon para ser tan pequeños que se pudiesen implementar en cualquier dispositivo.

Originariamente, se criticó mucho su implementación en dispositivos actuales, porque instalar en nuestros equipos algo así como una caja negra a la que no podemos acceder y que puede realizar operaciones críticas en nuestro sistema, sonaba peligroso y atentaba con nuestra privacidad. Pero realmente esa es la razón de ser de los TPM. Su utilidad e importancia radica en que el mismo puede por cuenta propia realizar un buen número de operaciones criptográficas, tiene mecanismos para identificarse de forma inequívoca, y permite «almacenar» en él información «sensible» que no pueda salir de allí, pero que el propio módulo pueda usar.

Un ejemplo muy simple de funcionamiento de un módulo TPM. Se le solicita que genere un par de claves nuevas (cifrado simétrico), y se le insta a que la parte privada no sea exportable y quede inexorablemente asociada al TPM. Además se sella en el TPM, de modo que este sólo podrá usarla cuando se desbloquee de forma externa, por ejemplo con un PIN, o un sistema biométrico, o un estado concreto del equipo… A partir de ese momento, podríamos encriptar por ejemplo un archivo o firmar cualquier cosa sin peligro de que la clave privada pudiese acabar en manos equivocadas, es más, incluso nosotros mismos perdemos control sobre ella, solo podremos desbloquear en el TPM su uso, pero quien la usará será el módulo TPM, no nuestro software. Cualquier malware que intentase recuperar la clave mirando la memoria, no vería nada, técnicamente no estaría en memoria dicha clave. El TPM se asocia además al equipo, si alguien se llevase el módulo TPM tampoco podría usarlo, podría resetearlo pero ya está.

Dado el gran expansión boom de los sistemas biométricos en estos tiempos, el uso de los módulos TPM se dispara igualmente. Encontramos 3 tipos de TPM en la actualidad: A los módulos TPM independientes los llamamos «discretos». También tenemos los TPM integrados, y por último los TPM basados en software, ya sea software puro como emuladores o simuladores, o ya sea en forma de firmware, asociado de forma íntima a un hardware.

No todos tienen las mismas funcionalidades ni son igual de seguros. Actualmente los TPM discretos son los más capaces y sobradamente los más seguros. Los fabricantes de ARM los han intentado implementar a su modo en los diferentes SoC (Android/iOS), con resultados diferentes, protegen frente a ciertos escenarios, pero fracasan en otros. Si podemos escoger, y la seguridad es lo primero, un módulo TPM discreto es lo que queremos. La imagen superior es mi placa ASUS con su módulo TPM instalado, como puede verse es un elemento hardware más del sistema, la bios UEFI lo detecta y permite su inicialización y configuración, deshabilitando a la vez el módulo PTT (TPM por Firmware) de Intel.

Hasta hace unos años lo habitual era disponer TPM en forma de TPM discretos, pero como he dicho, además de los «parecidos» que usan los dispositivos portátiles en la la actualidad en sus propios SoC, la propia Intel, desde hace ya unas cuantas generaciones de sus procesadores, los incluyen en la firmware de estos, lo llama PTT ( Platform Trust Technology). Muchos de los lectores, sin que lo sepan, tendrán un módulo TPM en sus equipos de este tipo, otra cosa es que hayan configurado la BIOS y el sistema para usarlo.

Desde el punto de vista de la Biometría, los módulos TPM juegan un interesante papel. Precisamente con sistemas biométricos deseamos aumentar la seguridad y la comodidad a la hora de autentificarnos. Por lógica, como he dicho anteriormente, un sistema biométrico requeriría muy posiblemente un PIN o cualquier otro sistema de verificación para desbloquear los datos sensibles como puedan ser los datos de nuestras huellas, los de nuestra cara… pensad, repito, en el móvil cuando tenemos habilitado el acceso por huella, podemos desbloquearlo sin más complicaciones, pero si lo apagamos y lo encendemos, ese primer inicio requiere nuestro modo de desbloqueo principal, para que el sistema pueda acceder a los datos biométricos almacenados en sí mismo. Con un módulo TPM esto puede subsanarse, porque el mismo TPM sella dichos datos sensibles, y como caja negra, ninguna información sensible sale de ella (no debería).

Esto se repite con muchos otros elementos.

Tanto Windows como Linux pueden hacer uso de los módulos TPM de múltiples maneras. En este caso, Microsoft ha estado a la cabeza desde hace años, implementando cualquier función que estime crítica en los TPM cuando se encuentran disponibles. Es más, algunas funcionalidades de Windows 10 requieren sí o también de estos módulos. AQUÍ tenemos un artículo interesante de Microsoft al respecto. Funcionalidades como el famoso BitLocker, tarjetas inteligentes virtuales, arranque seguro, registros de inicio seguro, inicio medido, Windows Hello… la lista se amplía con cada actualización de Windows 10.

De cara al usuario de a pie, es también importante, sin que él lo sepa, Windows estará gestionando ciertas funcionalidades en él, y eso implica una mayor seguridad en sus sistemas. También hace que algunas tareas puedan ser transparentes para nosotros y no requerir nuestra intervención, es decir, menos trabajo para nosotros, más comodidad. No voy a recomendar a nadie comprarse uno, pero no estaría de más echar un ojo si nuestro sistema cuenta con uno, o tenemos un procesador compatible que lo implemente por firmware y podemos habilitarlo en la BIOS

Como nota final a todo esto, decir que desde hace 2-3 años, Microsoft lista módulos TPM 2.0 como requerimiento obligatorio para Windows 10. Eso quiere decir que cualquier fabricante que de dicha fecha hasta el día de hoy que haya vendido un equipo con Windows 10, tendrá un módulo TPM 2.0, ya sea discreto o, como es lo más probable, integrado en la firmware (fTPM)


Estructura de un TPM

Me temo que en este capítulo, hasta aquí la parte sencilla de entender. Ahora viene el resto para quien quiera estrujarse el coco e intentar sacar algo más en claro. A fin de cuenta todo eso está muy bien, pero a groso modo… ¿Como funciona? Posiblemente explicarlo bien requeriría un libro entero, así que vamos a intentar hacerlo «fácil». Todo lo fácil que podamos…

Esta podría ser la estructura interna de mi módulo TPM 2.0 a groso modo:

Actualmente aun conviven el estándar antiguo 1.2 con el 2.0. Son similares, pero las mejoras que se llevaron a cabo en la especificación 2.0 permiten flexibilizar más los TPM. Lo más destacado es el aumento de algoritmos de cifrado, el uso de SHA-256, mejoras en la autentificación y la posibilidad de tener (y por ende usar) múltiples Keys raíces de almacenamiento.

El TPM<->Equipo se comunican entre sí por un Bus al que está conectado el TPM. Esta comunicación se realiza por medio de instrucciones sencillas que son enviadas al TPM, y obviamente este se puede comunicar con el exterior. No obstante hay contenido en la memoria del TPM que jamás podrá ser exportado o accedido de ninguna forma por el equipo al que está conectado, es de uso exclusivo del TPM, aunque este puede solicitar que el TPM lo use, y le devuelva el resultado de la operación criptográfica realizada. Esta comunicación puede controlarse igualmente por políticas de acceso. Pueden prohibirse ciertas instrucciones, o requerir alguna comprobación presencial del usuario delante del equipo.

El «núcleo» principal es su procesador criptográfico, capaz de realizar tareas propias. Posiblemente las más habituales sean la creación de nuevas claves y cifrar/descifrar contenido. La idea va a ser más o menos siempre la misma, el exterior le va a solicitar que realice la acción X, y aportará los datos para que el TPM realice el trabajo duro, y devuelva los datos convertidos.

La memoria del TPM podemos diferenciarla en 2-3 partes, aunque toda ella debería de ser memoria «de seguridad», en la que el hardware en cualquier caso evitaría cualquier intento de acceso no autorizado a ella. Los dTPM poseen sistemas para evitar el que físicamente puedan acceder a la información que contienen.

Por un lado posee una memoria no volátil, cuyo contenido va a persistir aunque apaguemos el dispositivo. Por lo tanto aquí se va a almacenar los datos más sensibles del TPM:

Certificado/Key de Endosamiento (EK): Cada dTPM posee en su interior un par de claves RSA (pública y privada) y un certificado que son únicas para cada dTPM y que son insertadas/añadidas cuando se fabricó (pueden cambiarse por firmware en algunos casos). Este par es único para cada TPM, es decir, cada TPM tiene una diferente. La Key Privada jamás saldrá al exterior, y tampoco se usará para cifrar o firmar contenido. No obstante sí se usará para generar otras keys, y principalmente para verificar/atestar contenido. Hasta hace muy poco, las EK eran exclusivas de los dTPM por motivos obvios, pero en los fTPM como los que produce Intel en sus procesadores, pueden reprovisionarse al inicializarse en Windows, a través de Internet de forma automática

Key raíz de Almacenamiento (SRK): A diferencia de la EK y aunque es persistente, esta no se generó cuando se fabricó, sino que es generada en el momento que se toma control sobre el TPM en la inicialización y se establece un propietario. Cuando el TPM se resetea/limpia, esta Key se borra, y se generará otra cuando se inicialice de nuevo. Esta Key (par de keys, publica y privada) es vital, pues es la Key más alta jerárquicamente hablando. Esta Key será la que cifre a su vez las diferentes Keys de Almacenamiento (Storage Keys, SK) que se generen, y estas a su vez, las SK, encriptarán las Key «Asociadas» (Binding Keys), que serán las que las aplicaciones usen en última instancia para cifrar/descifrar contenido. Cuando «ligamos» una Key al TPM, lo que hacemos es eso, cifrar en el TPM la Key con una SK, y esta SK a su vez se encuentra cifrada por la SRK

Hay que entender que los TPM tienen una memoria limitada. Lo ideal sería que un TPM pudiese almacenar y usar de forma segura cuantas Keys quisiésemos, pero esto no es viable. Una Key RSA de 2048bits son 256Bytes. Puede parecer poco, pero si incluimos tanto la parte privada como la pública (como el certificado si compete), y multiplicamos por la gran cantidad que pueden necesitarse… los TPM son pequeños, la memoria que tienen es muy reducida. Así que es mucho más práctico que incluso las SK (o algunas de ellas), asó como las Key asociadas, residan físicamente en el disco duro. Dado que están cifradas no entrañan tampoco riesgos, cuando vayan a usarse serán transferidas al TPM, el TPM las descifrará y las usará. Tampoco es posible realizar criptoanálisis a esas Keys, el TPM usará varias SK diferentes, e incluso en módulos 2.0 tendrá varias SRK

La memoria volátil se vacía cada vez que el equipo se apaga. Lo que almacena es temporal. Aquí es donde van a residir la mayoría de Keys al uso. Esta memoria se divide funcionalmente en dos partes, una porción que mantiene los PCRs, y otra que mantendrá las Keys al uso:

PCRs: Los PCRs (Platform Configuration Register) son parte esencial de los TPM. Son una serie de registros (habitualmente 24) que almacenan, por así decirlo, básicamente el estado del equipo en cada momento. Estos registros pueden leerse sin problema, sin embargo no puede inscribirse el valor que se quiera, solo puede actualizarse su valor, esto lo hace el TPM, y lo hace por medio de la concatenación del contenido actual en dicho momento de ese registro y los datos nuevos, y lo que almacena es el Hash resultante. TPM 1.2 usaba sólo Hash SHA-1, los TPM 2.0 pueden usar tanto SHA-1 como SHA-256. Mi TPM, por ejemplo, posee 24 registros que pueden ser tanto SHA-1 como SHA-256, y es importante la diferencia, porque si se cambia, cuando se consultase su valor este sería muy diferente si fuese un Hash u otro.

La función principal de los PCRs es ser usados como cadenas de verdad, para sellar Keys y para atestaciones. Todo lo veremos más tarde

-SKs; Como vimos antes, las SRK encriptan a su vez SKs que se generan que puedan utilizarse como intermediarios. Estas pueden almacenarse aquí, al igual que también las Keys enlazadas a estas de las aplicaciones. Como son Keys que en un momento dado el TPM va a usar, cuando se requieren, se pasan a la memoria.

Keys de Identificación de Atestación (AIK): El proceso de atestación se explicará más tarde, la cuestión es que el TPM tiene capacidad de atestación, de autoidentificarse como un dispositivo confiable, que la operación que se va a realizar es segura y legítima. Para ello se requiere en última instancia firmar peticiones del tipo que sea. Todas las Keys se generan en el TPM, pero el TPM en sí mismo no es una autoridad de certificación, con lo que las keys generadas por él no tienen «confiabilidad». No obstante, si lleva dentro de sí mismo la Key de Endosamiento, con su certificado en regla. La EK podría firmar los informes de atestado, pero esto no sería adecuado, podría usarse criptoanálisis, implicaría una carga de trabajo grande para el TPM y otros problemas. Así que el proceso que se realiza es por medio de las AIK, que son Keys que genera el TPM pero que se firman con la EK, luego repito se verá el proceso


Atestación

Como hemos dicho, la atestación es un proceso por el cual el TPM puede identificarse ante otros como un dispositivo confiable, que es quien dice ser. La atestación es habitual en la seguridad, impide que un tercero se haga pasar en este caso por el TPM. Esto no es una tontería.

Imaginad que se requiere una operación importante, como desencriptar un archivo confidencial, no podemos correr el riesgo de que el sistema esté infectado por algún malware y pueda interceptar información confidencial. Gracias a la atestación y a los PCR en este caso, el sistema podría saber si hay algo residente con fines maliciosos.

Gracias a la EK, podríamos decir que el TPM posee algo único e identificativo, un certificado completo que normalmente ha sido emitido por el fabricante del TPM, y por ende puede verificarse criptográficamente desde fuera que cualquier operación firmada por la EK de dicho TPM es ese TPM. La EK firma lo que sea con la clave privada, con lo que desde fuera puede verificarse la firma con la clave pública. El certificado de la EK es accesible también, y puede comprobarse que fue emitido de forma legítima por la autoridad de origen, generalmente el fabricante del TPM. Así que desde fuera se puede saber que realmente se está hablando con un TPM por ejemplo real, no un emulador o un malware que se hace pasar por TPM.

El uso no obstante de la EK no es como decíamos adecuado, así que se realiza un proceso digamos en diferido, a través de las AIK. Realmente las AIK van a desempeñar el proceso anteriormente comentado, con la única salvedad que no será la EK quien firme la atestación, sino las AIK.

Las AIKs tendrían el mismo problema, necesitan ser confiables. Por lo general el proceso a seguir es que se genera un par de claves AIK. La parte pública se firma con la EK y se envía a una entidad de certificación. Esta a su vez puede verificar la autenticidad de la clave generada comprobando la firma realizada por la EK, y crear un certificado, que firma y envía de vuelta. En ese momento el TPM tendrá un certificado completo (con clave privada guardada) firmado por un CA, y que puede verificarse por cualquiera. El resto es trivial, dicha AIK puede firmar cualquier Atestado, y la parte interesada podrá comprobar la validez y la confiabilidad verificando que la firma del certificado público de la AIK es igualmente legítimo.

Con los PCR, el TPM podría atestar un informe de estado, es decir, enviar hacia fuera el contenido de los PCR y firmarlos. El equipo a su vez podría enviar a un tercero (una aplicación por ejemplo) el informe de estado del TPM y su propio registro de eventos. La aplicación/tercero podría con el registro de eventos estipular que valor tendrían que tener los PCR para asegurar que el sistema es seguro para la labor que quiere llevar a cabo, así que no tiene más que calcular los valores de los PCRs a partir del registro enviado por el equipo, y compararlo con los valores firmados entregados por el TPM. Un malware tendría muy sencillo engañar al sistema y manipular los registros para que pareciese que todo está bien, pero el malware no puede engañar al TPM, los PCR del TPM muestran de forma real y segura el verdadero estado del equipo.

Este proceso no solo lo hacen los TPM, la atestación en general es común a muchos otros dispositivos. Cuando veamos FIDO veremos que es similar. Sea como sea lo que se quiere es algo simple, que un tercero, que una parte externa pueda saber seguro que somos quien decimos ser, en este caso un mecanismo para el TPM de poder autoidentificarse.

La atestación en los TPM hasta hace poco era sólo posible con los dTPM, dado que como hemos dicho eran los únicos que tenían un certificado de endosamiento. Eso significa que TPMs más viejos o menos capaces pueden perfectamente carecer de procedimiento de atestación, y eso impide que puedan ser válidos para algunas tareas. Con la reprovisión remota de algunos fTPM esto se soluciona, y con EK el sistema puede atestar.


Almacenamiento Seguro y Sellado

El TPM en encarga en gran medida también de encriptar contenido. Como dije la memoria es limitada, y tampoco sería bueno tener una sola Key para todo. El otro gran aliado es la Key Raíz (maestra) de almacenamiento, antes era única, un par de claves RSA, pero en los TPM 2.0 podemos encontrar varias, y con diferentes algoritmos de cifrado, pero la finalidad es la misma.

Aquí de lo que se trata es que el TPM sea quien al final encripte y desencripte el contenido que se le envíe. El contenido en sí es indiferente y no es de incunveniencia del TPM. Para hacer eso se requieren Keys criptográficas, sea cifrado simétrico o asimétrico, que en el momento de usarse, como es natural, deben de estar en la memoria del TPM. La memoria es limitada, y las Keys necesitan ser usadas cada vez que se requiera la operación a realizar. Donde se guardan entonces? En el Disco duro o almacenamiento del equipo.

La SRK nunca dejará el TPM, por así decirlo es la contraseña maestra que cifrará las Keys a su cargo. Realmente es una jerarquía:

La Key raíz de almacenamiento cifra las keys de almacenamiento que el TPM genera. Estas Keys a su vez pueden almacenarse de forma externa al TPM, están cifradas, no pueden usarse de ningún modo si no es el propio TPM quien las usa. Es decir, las SK están sujetas a la SRK, que repetimos, jamás abandonará el TPM.

¿Y para qué queremos las SK? Bueno, estas a su vez pueden cifrar cualquier Key que quiera usar una aplicación, lo que se llama Key binding, y esto es algo extremadamente importante, puesto que de este modo cualquier aplicación podría realizar operaciones de cifrado/descifrado de contenido que pudiese usar sin exponer jamás la Key. Un malware en estas circunstancias podría con suerte lograr el contenido desencriptado analizando la memoria (hay medios para impedirlo), pero la Key maestra de la aplicación para el malware no existiría, ya que es una Key enlazada al TPM.

Un ejemplo práctico. Usamos un gestor de contraseñas donde tenemos una gran base de datos con cientos de credenciales. Como es lógico la base de datos se encripta por seguridad, por ejemplo con AES y una Key maestra que solo nosotros sabemos, y que es vital. El problema es que cada vez que la tecleamos en la aplicación, la usamos para desencriptar o encriptar la base de datos, en cierto modo la exponemos al sistema, y un malware podría estar residiendo en la memoria para extraer la key maestra. Esto puedo sonar a casos aislados, pero es extremadamente habitual este tipo de ataques, y bastante sencillo extraer de la memoria este tipo de información por parte de un malware.

¿Como podemos defendernos? Pues entre otras cosas, gracias al TPM. Imaginemos que la App está preparada para este escenario, para usar el TPM. El proceso podría ser algo similar a este:

Windows Arranca y una finalizada la carga del sistema, el TPM solicita las SK cifradas que el sistema tenga en ese momento (imaginamos que solo hay una SK). Windows envía la SK cifrada, el TPM la desencripta con la SRK y la deja en el TPM para ser usada. Todo esto es transparente al usuario, y la SK desencriptada está sólo en el TPM no es accesible desde ningún otro medio.

Abrimos la aplicación por primera vez, generamos la Key maestra y la memorizamos, y le decimos a la aplicación que la «almacene», que la enlace al TPM. Nuestra Key Maestra se envía por tanto al TPM, y este la cifra con la SK que ya tiene desencriptada previamente. El TPM devuelve a Windows la Key enlazada. en ese momento está protegida por el TPM, a efectos del usuario es como si la Key estuviese almacenada de forma segura en este, en el TPM.

A partir de entonces, si queremos abrir la base de datos, la aplicación podría por ejemplo enviar al TPM la Key enlazada (cifrada) y la base de datos también cifrada. El TPM podría desencriptar la Key Enlazada, y con ella a su vez desencriptar la base de datos, que devolvería a la aplicación. Todo ello de nuevo transparente al usuario.

Por seguridad, la aplicación protegería el proceso con algún otro modo de seguridad, para evitar que cualquiera con acceso físico a nuestro equipo, al darle a abrir a la aplicación la base de datos se desencriptase de forma mágica, con lo que es igualmente habitual que este tipo de Keys enlazadas estén a su vez selladas

El sellado de Keys es otra parte importante del TPM. El enlazamiento de Keys o Key Binding es extremadamente eficaz y garantiza la seguridad de las Keys, pero no evitar que alguien pueda usarlas de forma fraudulenta. A fin de cuentas si todo es transparente, como evitar que se haga uso del TPM un malware que sea listillo.

El sellado es muy sencillo. Cuando se solicita al TPM que selle una Key, lo que se le dice es que dicha Key sólo pueda ser utilizada cuando el contenido de un PCR en concreto (o más de uno) tenga un valor en concreto, que se pasa igualmente como parámetro. Es decir, por ejemplo: «Almacena (enlaza) esta key, pero la sellas para el PCR3 con el valor de xxxxxxxx». Eso provoca que ante cualquier petición del sistema para que el TPM use dicha key, sea una aplicación legítima o un malware, el TPM no la va a liberar si en ese momento el valor del PCR3 es el que se le dijo que tenía que ser.


Políticas de Uso

Para terminar, hablemos un poco de las políticas de Uso. Cuando el TPM crea una Key, podemos configurarla para que se requiera un modo de autentificación concreto, los cuales en los módulos TPM 2.0 se hace mucho más flexible.

Hemos puesto un ejemplo de como un TPM podría proteger nuestra contraseña maestra del gestor antes citado. pero cualquiera podría pensar que un malware podría igualmente hacerse pasar por la aplicación y solicitar al TPM su desencriptado. Esto es totalmente cierto, así sin más historias sería cuanto menos peligroso, muy práctico porque el usuario no tendría que hacer nada, pero poco seguro.

El secreto aparece cuando podemos decirle al TPM que solo se pueda acceder a dicha Key con algún medio de autentificación. Ese medio podría ser algo tan básico como demostrar nuestra presencia física, un cartel que pusiese aceptar/cancelar en pantalla y tuviésemos que darle a aceptar, o como ya hemos hablado de ello, un PIN. Podríamos «asociar» a la Key un PIN concreto requerido, así que al iniciar la aplicación no tendríamos que escribir la contraseña maestra, con los peligros que entraña, sólo un PIN, que es más simple, rápido y seguro.

Otras opciones de autentificación incluirían por ejemplo el uso de HMAC, o por ejemplo los ya hablados sistemas biométricos, o una tarjeta inteligente, o la combinación de todos ellos.

Todo ello nos va a permitir que el TPM que a fin de cuentas está siempre presente en nuestro sistema, solo se use cuando realmente deseamos usarlo, y que ningún malware intenta acceder a él de forma ilegítima a nuestras Keys Enlazadas.


Apuntes Finales

Los TPM son elementos complejos. La seguridad, si realmente se requiere, es compleja entre bambalinas. Eso no quiere decir que de cara al usuario, al día a día, lo sea. Precisamente, y aunque el tocho escrito anteriormente haga imaginar otra cosa, el uso de los TPM simplifica y mucho el día a día de los usuarios. Tener un TPM implica que muchas funciones o acciones que requerirían muchos más pasos, por la seguridad que entrañan, pasan a ser transparentes para nosotros. Y sí, normalmente la forma más rápida de acceder al TPM es con un PIN

Esto, veremos en otros capítulos, va a permitir muchas veces que hagamos «magia» con nuestros equipos. 2 Ejemplos simples de como un módulo TPM hace la vida más sencilla:

1º. Bitlocker:
BitLocker es la tecnología de cifrado de Disco de Microsoft. Microsoft insta a usar módulos TPM pero puede usarse sin ellos. Cuando BitLocker trabaja con TPM todo el encriptado/desencriptado ocurre en el TPM, con lo que es más rápido. Por otro lado lo único que necesitaremos al encender el equipo será por ejemplo un PIN. Nada más. Encendemos el equipo, este nos solicita un PIN (que nos dará acceso al TPM), y el disco se desencriptará. Si no disponemos de un TPM, técnicamente se puede realizar el encriptado/desencriptado por software, pero… ¿y la Key? Pues tenemos que suministrarla nosotros. Un PIN es simple, una Key que sea segura no, como la que obviamente requiere BotLocker, así que cuando encendemos el equipo o hacemos uso de una unidad USB que tenga el archivo de la Key, o nos tiramos 2 minutos buscando donde teníamos apuntada la Key y escribiéndola.

2º. Windows Hello
Podemos configurar un sistema biométrico para desbloquear e iniciar nuestra sesión en Windows (ya hablaremos de esto largo y tendido). Sin un módulo TPM, la primera identificación en el sistema se tendría que hacer por nuestra contraseña, y a partir de ahí, desbloqueos posteriores si podrían hacerse directamente y sin más por medios biométricos. Esto es algo similar a lo que pasa en nuestro Móvil, ¿os acordáis? Cuando iniciamos el móvil, el primer acceso lo hacemos por narices siempre con PIN/Contraseña Ahora bien, si nuestro equipo dispone de un módulo TPM y por ejemplo reconocimiento facial, es suficiente con arrancar el equipo, y sin hacer absolutamente nada, Windows nos identificaría y abriría sesión, repito, sin presionar una sola tecla

Técnicamente se podría hacer lo mismo sin requerir pasos intermedios si no se usasen TPMs, pero si se usan esos pasos intermedios cuando se trabaja sin TPM es precisamente porque las Key y otros datos sensibles al no estar enlazados al TPM se tienen que proteger de otro modo, por ejemplo encriptándolos en el disco directamente.

La ventana radica en que es infinitamente más sencillo trabajar con un TPM y un PIN, o un TPM y un sistema biométrico, que con contraseñas largas, USBs que se pueden perder… y además es más seguro, pero como hemos dicho ahora hablamos de usabilidad y comodidad, no seguridad.

Prácticamente todos los capítulos siguientes van a hacer uso de un modo u otro de un TPM y del uso de PINs. De ahí a la importancia de este artículo inmenso. Del PIN no es algo que nos olvidemos porque lo requerimos de cuando en cuando, pero el TPM llega un momento que no somos conscientes que está ahí, pero os lo aseguro, nos facilita la vida sin sacrificar seguridad, es más, la aumenta, al margen de las controversias que han existido sobre su uso y lo «feo» que suena que tenemos una caja negra que no podemos controlar bien y guarda bastantes secretos.

La Autentificación en tiempos modernos. Sistemas Biométricos.

A pesar que la autentificación por usuario/contraseña sigue siendo (y posiblemente seguirá siendo durante mucho tiempo) el modo más habitual para identificarnos, los últimos años han puesto de manifiesto que estos requieren evolucionar. Quizás no eliminarlos por completo, pero al menos a combinarlos con otros. Los usuarios y contraseñas están bien, pero tienen demasiados problemas con los que lidiar, las brechas de seguridad son cada vez mayores y públicas, y vemos más despistes por parte de las grandes empresas (Recordemos de nuevo el reciente caso de Facebook).

En el mundo real no hay nada parecido que se asemeje a usuarios/contraseñas, es una invención digital por la necesidad de autentificarnos en sistemas informáticos. En el mundo real usamos otros medios. El DNI por descontado, así como nuestra firma, son nuestras principales formas de identificarnos, pero todos sabemos que cuando se requieren medidas de seguridad mejoradas, son solo una pieza más. Es entonces cuando aparecen los sistemas biométricos.

Recordemos de nuevo, un sistema para ser seguro, debe de requerir tres cosas fundamentales de nosotros: Una cosa que seamos, Una cosa que tengamos y una Cosa que sepamos.

Los sistemas biométricos nos aportan esencialmente dos características que los hacen únicos:

1º. Nos aportan la primera necesidad: Una cosa que seamos.
2º. Son extremadamente cómodos, rápidos, simples (a veces transparentes) y relativamente seguros.


Que es un sistema biométrico

La biometría versa precisamente de las diferentes técnicas, patrones, algoritmos, tecnología… que permiten de algún modo parametrizar rasgos físicos de los seres vivos de un modo único y fiable, los cuales pueden ser usados para su autentificación. Posiblemente los sistemas biómetricos más conocidos son desde los lectores de huellas dactilares, escáneres de iris/faciales… y si queremos sistemas más sofisticados que entren dentro de la ciencia ficción pero viables, la propia sangre, temperatura corporal…

En el mundo real los sistemas biométricos se han usado desde hace décadas, además de las películas de ciencia ficción. A nosotros mismos llega un momento al cumplir años que para hacernos el carnet de Identidad debemos de suministrar nuestras huellas dactilares.

La complejidad técnica, los altos costes y los requerimientos técnicos que históricamente han tenido los sistemas biométricos, han hecho que hayan sido usado solo en organizaciones concretas, o en lugares de alta seguridad.

Pero algo pasó. Como pasa en nuestra sociedad, cuando algo no interesa apenas avanza tecnológicamente, pero cuando al público general le gusta y se consume a grandes dosis, la tecnología se dispara, se necesite o no. Y agarraos, porque la biometría ha venido para quedarse, y no solo en el ámbito digital, pronto veremos tarjetas de crédito con lectores de huellas y escáneres faciales en diferentes lugares para, de forma automática, detectarnos e identificarnos.

A día de hoy, hay que decir que encontramos lectores en cualquier lado, el soporte de los sistemas operativos es tal que prácticamente el 100% de los terminales móviles que se venden a día de hoy los llevan, pero incluso en los entornos de escritorio, cada vez más y no solo en ámbito empresarial, los vemos. En este aspecto hay que alabar enormemente los esfuerzos por parte de Microsoft con Windows 10, y el increíble soporte en cuanto a seguridad se refiere: TPM, Windows Hello, Bitlocker… y muy recientemente, en la actualización que llegará en unos días/semanas, FIDO2 de forma nativa. Entraremos en algunas de esas tecnologías más adelante.

Vamos a hablar de métodos biométricos, fundamentalmente de los Lectores de Huella dactilar y de los escáner faciales/iris puesto que a día de hoy son los más predominantes. También los problemas y ventajas que entrañan, y alguna cosilla más


Lectores de Huellas Dactilares

No se puede decir que un lector de huellas dactilar sea nuevo, llevan con nosotros muchas décadas. Sin embargo, ha sido a lo largo de los últimos 6 años con los dispositivos móviles cuando la tecnología se ha implantado prácticamente en todos lados en la sociedad actual. Desde hace unos años es la moda, y lo que parecía algo tan exótico y tan singular propio más bien de las películas de James Bond, hoy en día los tenemos incluso en los terminales de gama baja.

Hay que decir que los lectores de huellas a día de hoy, distan enormemente de los lectores de hace años. Históricamente lectores de huellas han funcionado siempre como un medio óptico, literalmente un «escáner». Actualmente encontramos hasta tres tipo de lectores de huellas:

-Ópticos:
Los primeros que llegaron, y hasta hace tan solo unos pocos años los que podían encontrarse. Eran relativamente grandes, caros… Fueron también los primeros que se empezaron a montar en algunos portátiles, aunque estos usaban un sensor más pequeño por el que era necesario desplazar por encima el dedo para que realizar una lectura «completa.

El modo de funcionamiento de los lectores de huellas óptico era/es el más simple de todos. El dedo se apoyaba por lo general en un cristal que conformaba a su vez un prisma, por otro de los lados se emitía una fuente de luz para iluminar el dedo, y en el otro lado del prisma se colocaba un sensor de imagen. La luz incidía en el dedo y rebotaba hacia el sensor, y este recogía la información. Las huellas como sabemos tienen surcos y crestas (y otras anomalías), con lo que la luz incide de forma diferente en cada parte.

De todos los lectores de huellas son los menos fiables, básicamente lo que recoge el lector es algo así como una «fotografía» del dedo, fácil de suplantar, sin información de profundidad. A día de hoy es muy raro encontrarlos en el mercado, y tampoco se implantaron prácticamente en los móviles. Recientemente no obstante, se han empezado a usar en estos para poder incluirlos debajo de las pantallas

-Capacitativos:
Representan la mayoría de los lectores actuales, tanto en dispositivos móviles como en forma de pequeños (micro) dispositivos USB. La miniaturización de componentes y el desarrollo de algoritmia moderna ha permitido la creación de lectores de huellas que pueden instalarse prácticamente sin ocupar espacio, pero aplicando un concepto totalmente diferente al de los lectores ópticos. Además, a su modo, son capaces de obtener información de profundidad, y por su modo de funcionamiento son muy difíciles de engañar.

En este caso el lector en sí mismo no es más que una matriz muy grande de pequeñísimos condensadores. Estos condensadores experimentan diferenciales de carga cuando el dedo los toca, y la circuitería existente recoge con precisión estos pequeños cambios en la carga de los condensadores. No será igual aquel condensador que esté en contacto con el dedo completamente, al que está en un surco y no hay nada que lo roza, salvo el aire.

Todos estos datos se procesan, y se puede crear un «mapa» de características únicas de cada dedo. No vale una fotocopia de un dedo para engañarlo, se requeriría una superficie igualmente tridimensional con la misma morfología que el dedo de origen, lo cual si bien es cierto no es imposible, si es muy complicado

-Ultrasónicos:
La joya de la corona de los lectores actuales. Los encontramos en teléfonos de alta gama, también se venden en formato mini-usb como el de la foto. Son más seguros aun que los anteriores, más precisos y más complicados de suplantar.

en este caso, en vez de ser la luz lo que incide en la huella son ondas ultrasónicas que rebotan en la superficie del dedo, mandando de vuelta información sobre la estructura del dedo. Las ondas penetran de forma eficaz el aire que hay entre la superficie del lector y los surcos, obteniendo información mucho más exacta

No podemos saber si seguirán evolucionando, lo cierto es que hemos pasado de lectores «inseguros» voluminosos y caros, a lectores rápidos, eficaces y seguros, que podemos encontrar casi en cualquier lado a día de hoy, no solo en los dispositivos móviles.

Pero no todo es positivo. Los lectores de huellas, como veremos al final, también tienen sus propios problemas. no podremos depender de él en exclusividad, y además, tampoco podemos olvidar, que por bueno que sea el sistema, siempre cabe la posibilidad de engañarlo.


Escáner Facial/Iris

Aunque hasta hace muy los lectores de huellas dactilares no estaban en nuestro entorno,todos los conocíamos bien, en algún momento dado los habíamos tenido que usar, o al menos los habíamos visto. En cambio, los escáneres faciales o de iris aun parecen sonar a ciencia ficción.

A nadie se le escapa que en organismos de alta seguridad se han usado desde hace muchos años, sobre todo los escáneres de iris/retina. A fin de cuenta es otro distintivo único que tienen las personas, al igual que la huella dactilar, no hay dos iguales, lo que nos asegura, en teoría siempre, la inequivocidad. Pero han tenido el mismo problema, grandes, muy caros, sin estandarizar… y realmente, bastante inseguros si los comparásemos con los que tenemos a día de hoy.

Si a día de hoy hablamos de Escáner Facial, muchos posiblemente no nombrarán correctamente al que, muy posiblemente, sea responsable original de la tecnología actual en reconocimiento facial puesta a consumo. No, no fue ni Samsung con su increíble escáner de retina, ni mucho menos Apple con su llamado Face ID. Fue Microsoft, hace ya 9 años, en 2010, y el lanzamiento de Kinect. Para quien o lo recuerde, Kinect fue un accesorio que Microsoft creó para sus XBOX, para dotarlas de un dispositivo de seguimiento corporal.

Kinect fue el precursor de la tecnología que a día de hoy se usa a diario para el reconocimiento facial. De echo, Face ID de Apple es en esencia una versión en miniatura (y obviamente menos prestaciones) de Kinect, y lo mismo ocurre para otros dispositivos que implementan sistemas similares, como Xiaomi Mi8. Paralelamente existen tecnologías similares con resultados muy parecidos, más o menos sofisticados, pero funcionamiento similar, y pese a que todos digan que su sistema es el mejor, la mayoría poco tienen que envidiar al vecino.

Vamos a ver ahora algunas de estas tecnologías:

-Escáner de Retina tradicional
Sin duda alguna los primeros que aparecieron, hace ya muchos muchos años, empleado en sistemas de seguridad avanzados. Básicamente eran sistemas fotográficos del iris delas personas, en los que prácticamente se pegaba el ojo a la lente. La lente tomaba una fotografía del ojo y los algoritmos hacían el resto para la identificación de los patrones del ojo con los almacenados. No existen dos ojos iguales, pero este sistema resultó poco «fiable», sobre todo en los tiempos modernos, dada la posibilidad de engañar los escáneres con fotografías de gran resolución.

-Escáner de Retina IR
A día de hoy los escáner de retina existentes hacen uso de iluminación ocular por infrarrojos, antes de tomar la imagen del iris. Esto mejora considerablemente la seguridad y la identificación. Usando luz infrarroja se puede revelar mucho mucho mejor la textura del ojo. sin solaparse la pigmentación, y teniendo una estructura mucho más firme y clara.

Este es el tipo de Escáner que por ejemplo encontramos en los últimos terminales de Samsung. Mejoran considerablemente los anteriores, y realmente el Iris es ideal desde un punto de vista biométrico, dado que la estructura del ojo es extremadamente compleja. Pero esas ventajas, al menos a día de hoy, no logran superar las desventajas. En primer lugar, en teoría, es relativamente sencillo engañar a un escáner de retina. Por otro lado el alcance del escáner se ve muy limitado dada la necesidad de tomar una imagen clara y de alta resolución. La tecnología tiene aun mucho camino que puede recorrer, pero a día de hoy aun prevalece, desde mi opinión, la tecnología de reconocimiento facial.

-Escáner Facial tradicional
Similar al escáner de Retina tradicional. En este caso en vez de usar como imagen/patrón el iris, se usa la cara completa. Una cámara/sensor realiza una captura. A través de esa captura, una serie de algoritmos parametrizan desde la morfología de la cara, la iluminación, arrugas, defectos… incluso pueden analizar la pigmentación. Todo eso se procesa, y se compara con los patrones inicialmente almacenados. La premisa es la misma, no hay dos caras iguales

Por la mismas razones que los escáneres de retina, esta tecnología nunca ha sido demasiado segura. En entornos de Consumo, fue en este caso Google el que la puso de moda, con su «Face Unlock» para Android. Aun se usa en muchos terminales, y pese a las limitaciones que tiene la tecnología, el sistema funcionaba. El primer problema, no obstante, fue de nuevo lo fácil que resultaba burlar el sistema, y fotografías colocadas de forma inteligente era suficiente. De ahí a que Google implementase el parpadeo… Otro gran problema es la imposibilidad de usar estos escáneres sin fuentes de luzz importantes. Tecnología muy simple por requerir sólo una lente/camara, pero demasiados problemas.

-Escáner Facial IR
Usa una aproximación similar a la del escáner de retina IR. En este caso se requiere un dispositivo bastante más sofisticado, no es un solo sensor quien toma una imagen. En este caso se requiere un dispositivo similar a Kinetic, por lo general se usan 2 sensores separados, un sensor RGB y otro IR (cercano a IR). Por otro lado se requiere de emisores IR.

Estos escáneres eliminan los problemas de los escáneres Faciales tradicionales. Al usar IR, la tecnología permite ser usada en entornos de baja luminosidad, incluso en oscuridad total. También permite parametrizar mejor cualquier rasgo facial. Y por último, al estar ambos sensores separados, permiten también, en parte, hacer estereoscopia. No permite recrear una cara en 3D, pero puede aportar igualmente información de profundidad, que es usada para evitar el uso de fotografías y otros medios para burlarlos.

Son el tipo de Escáneres faciales más comunes a día de hoy, son rápidos y funcionan bastante bien. Se están empezando a sustituir por escáneres 3D, en lo personal por una cuestión de marketing, más que por seguridad.

-Escáner Facial IR-3D
Su funcionamiento es también similar al IR, y es lo que están empezando a añadir algunas empresas a sus teléfonos. Al igual que Kinetic, en esta ocasión se opta por un sistema más complejo pero igualmente efectivo. En vez de analizar la morfología y otros de una imagen 2D, aun teniendo información de profundidad, se opta por intentar reconstruir, virtualmente, una cara, y de esa reconstrucción, parametrizarla, y guardar dichos datos para la autentificación.

Esto se logra de un modo similar a los escáneres IR. En este caso hace falta también un, llamado, emisor de puntos, básicamente un emisor IR que «proyecta» sobre la cara miles de puntos, que son recogidos luego por un sensor IR, conociendo la profundidad de cada uno de esos puntos, y por ende teniendo un mapa tridimensional de la parte delantera de la cara.

Sobre el papel este tipo de escáneres debería de ser más seguro por añadir una mayor estructura a la parametrización, pero a efectos prácticos el resultado es similar a escáneres más baratos IR. Desde que apareciesen los primeros terminales móviles con ellos, ya han aparecido 2-3 generaciones diferentes de este tipo de escáneres. Si en lo que respecta a escáneres de huellas la cosa está actualmente más estable, los escáneres faciales aun están en vías de crecimiento, no apostaría por que tecnología facial va a predominar los próximos años, si escáneres 3D, IR o incluso los de iris. Todos tienen sus pros y sus contras.


Consideraciones Finales

Como veremos en el siguiente capítulo, los sistemas biométricos son una gran ayuda, pero no están exentos de problemas, y por lo general debemos de usarlos con sistemas dobles. A eso hay que sumarle que, mientras que suplantar un sistema digital como una clave privada es en la práctica inviable, suplantar o engañar a las cámaras y escáneres es más factible.

La mejor variable que mide la viabilidad de los modos biométricos es el FAR, por ser también la más peligrosa. El FAR, False Accept Rate, es un dato que proporciona el fabricante, y hace referencia a que porcentaje tiene dicho hardware de causar un falso positivo. Existen también falsos negativos, FRR, es decir, nos identifican mal y tenemos que reautentificarnos, pero esto no causa mayor problema desde un punto de vista de la seguridad, aunque cuanto mayor sea, mayor incomodidad para nosotros.

Un FAR de un 50% implicaría que cada dos intentos en la autentificacion sin que estemos registrados en el sistema, la autentificación nos concederá un acceso incorrectamente, lo cual es el peor de los casos.

Un FRR de un 50% en un sistema en el que sí estuviésemos registrado, implicaría que cada dos intentos en la autentificación el sistema no sería capaz de identificarnos en uno de ellos. Cuantas veces el lector del móvil no es capaz de reconocer la huella? Eso es un FRR alto.

Dependiendo del entorno donde nos encontremos y el grado de seguridad que se requiera, es lógico jugar con estos dos valores, requerir dispositivos y sistemas que cumplan como máximo un FAR/FRR concreto. Hay que tener en cuenta también la usabilidad, no es lo mismo un sistema que tarde en reconocernos 10 segundos que otro de 1 segundo, el de 10 segundos podría captar y analizar mucha más información, a expensas de tener que esperar 10 segundos.

Microsoft, por ejemplo, estipula que el FAR de los sistemas biométrico por huella, deberían de estar en el 0,001%-0,002% dependiendo del tipo de lector de huella, es decir, uno o dos falsos positivos entre cien mil intentos. Para el reconocimiento facial lo sitúa directamente en el 0,001%. Por otro lado, el FRR debe de ser menor al 10% (fallar menos que 1 vez de cada 10), mientras que en los sistemas faciales el FRR debería de ser menor al 5%.

Un FAR de 0,001% puede parecer algo muy bajo, pero recordemos de nuevo que estamos en la era tecnológica, y tal es así que expertos e investigadores de todo el mundo han ido sistemáticamente demostrando que es «posible» falsificar huellas dactilares y engañar a los escáneres Faciales/Retina. Aunque parezca increíble, los medios biométricos que tanto hemos visto en la ciencia ficción como los que hemos visto, son infinitamente más sencillos de vulnerar que un sistema criptográfico digital para la autentificación (veremos algunos en otros capítulos).

Hay que tener claro que eso no significa que los sistemas biométricos no sean buenos o «seguros», lo que significa que es bueno usarlos como un medio más en la cadena del Que Somos, Que tenemos, Que sabemos, no como medio único. Veremos estas cuestiones más adelante.

La Autentificación en tiempos modernos. Usuarios y Contraseñas.

Defensores y detractores. Pero sea como sea esta dupla lleva con nosotros desde hace décadas. Hace muchos años, se entendió que el mejor sistema para autentificar a una persona en el mundo digital era esta combinación. Y es lógico, un usuario y una contraseña es relativamente sencillo de recordar (cumpliendo la premisa de ser simple), era por lo general inequívoca (cumpliendo la premisa de identificar de forma fiable a quien se quiere identificar), y por último era lo suficientemente segura para ser viable, ya que no se dependía solo de un usuario, sino además una cadena que tenía que coincidir.

Estas premisas han hecho que a día de hoy sea el modo de autentificación más extendido en el mundo, digitalmente hablando. Tal es así que el que más o el que menos casi con toda posibilidad contará este tipo de autentificación por decenas.

Bien, pero antes de continuar, es necesario entender como funcionan bien estos usuarios y contraseñas, ya que también han evolucionado con los años enormemente. Puede parecer algo trivial, pero tiene bastante más… «sustancia» de la que podemos imaginar. Además, es nuestro método principal de autentificación, que menos que saber como dios manda como funciona. También veremos los diferentes problemas de seguridad que conllevan su uso.


Funcionamiento Básico de Usuarios y Contraseña

Parece un poco estúpido per sé, todos sabemos que es un usuario y una contraseña… ¿o no?. En una definición simple, un usuario es una cadena de caracteres normalmente no secreta que identifica a la persona dentro del sistema, mientras que la contraseña es, por lo general, una cadena de caracteres secreta, conocida sólo por su dueño, que está asociada de forma íntima al usuario, y que permite su verificación sencillamente por cotejamiento contra el sistema donde queremos autentificarnos.

El modo de funcionamiento de este sistema ha ido evolucionando mucho, por suerte. Pero todos se han basado en la misma premisa:

  1. El interesado crea/genera/… para el servicio indicado la tupla Usuario/Contraseña. Requiere los dos para acceder al servicio, requiere memorizarlo.
  2. El servicio almacena (por lo general en una base de datos de usuarios) dicha tupla de algún modo/formato

A partir de ahí, cuando el interesado quiere volver a ingresar en el sistema para que le autentifique, debe de proporcionar tanto el usuario y contraseña:

  1. El sistema solicita el usuario y contraseña
  2. El sistema realiza una búsqueda en su base de datos (o donde estén almacenadas las credenciales) por el usuario especificado.
  3. Si hay coincidencia, el usuario está en la base de datos, se compara la contraseña suministrada con la almacenada.
  4. Si no hay coincidencia con el usuario o la contraseña suministrada no es igual a la almacenada, se nos denegará el acceso. Si coincide, el sistema entenderá que somos quien decimos que somos y nos dará acceso.

Aunque el esquema anterior es el que se sigue usando como base, ningún sistema que podamos llamar mínimamente seguro y fiable lo aplica de forma estricta. Ver ahora los múltiples problemas que trae consigo ese esquema es fácil, pero recordemos que estamos en 2019, y que diablos.. antes éramos mucho más ingenuos y con mejor voluntad, que por desgracia la que corre en estos tiempos.

En vez de ir enumerando los diferentes posibles esquemas que pueden usarse para la autentificación Usuario/Contraseña, vamos a ver mejor los problemas que engendra, y las diferentes formas que podemos mejorar ese esquema básico para solucionar en lo posible dichos problemas:

  1. Adivinación, Imaginación
  2. Ataques de Fuerza Bruta
  3. Reusabilidad
  4. Ingeniería Social
  5. Robo/Acceso a la base de datos del Sistema
  6. Transmisión de las credenciales y Malware

Adivinación, Imaginación

Esto puede parecer gracioso y un tanto estúpido, pero funciona, ha funcionado desde el principio de los tiempos y seguirá funcionando, normalmente por desconocimiento, y sobre todo, dejadez de cada uno. Reíros, pero a lo largo de los años y simplemente por adivinación, un poco de imaginación y conocimiento, he sacado tantas contraseñas que ya ni recuerdo.

El problema es inherente a la propia contraseña. La contraseña es una cadena que se tiene que memorizar, hay quienes prefieren apuntarlas, pero entonces el problema se multiplicaría y habría que lidiar con otros factores. Dado que la contraseña la solemos memorizar, aun se cae en el error de forma casi mayoritaria de usar como contraseña aquellas cosas que nos son familiares: Números de teléfonos, DNI, fechas importantes (nacimiento, aniversarios..), nombre de mascotas, de animales que nos gustan, libros, series/películas, música…

Bien, ahora cada cual que piense en las contraseñas que tiene establecidas en sus diferentes cuentas… ¿Cuantos caen en ello? La cosa llega al absurdo de que incluso existen contraseñas «famosas» y usadas a lo largo y ancho de la tierra con una gran prominencia: «123456», «password» o «qwerty» son solo algunos ejemplos.

¿Como podemos luchar contra esto? Bueno, en cuanto al esquema básico usado, este problema de seguridad no se ve afectado por ello. Esto afecta sólo a la parte del usuario. La solución pasa por concienciar a las masas. Todos entendemos que memorizar lo que algunos llaman «contraseñas seguras» es casi imposible, pero hay más opciones. Mi opción favorita es usar de contraseña una frase corta, a la cual podemos ponerle una mayúscula/numero adicional si la queremos hacer aun más segura.

Obviamente lo ideal es usar una cadena alfanumérica de al menos 8 caracteres combinando entre números, mayúsculas, minúsculas… pero entonces estaríamos eliminando la premisa de simplicidad. Esto para mi es capital, porque si un sistema para ser seguro requiere complicarnos la existencia o tener que apuntar la contraseña en algún lado o… entonces no es adecuado. Será seguro, eso no lo dudo, pero no viable para el día a día.

Por favor, de verdad, dejar de usar contraseñas de vuestra vida.


Ataques de Fuerza Bruta

Técnicamente, los ataques de Fuerza Bruta son por lo general 100% efectivos. Cualquier contraseña por compleja que sea, en teoría, puede sacarse por fuerza bruta. La fuerza bruta es el aliado número 1 para el Hacker. «Sólo» requiere una cosa: Tiempo.

A lo largo de los años, he sacado demasiadas contraseñas simplemente adivinándolas, y cuando no ha sido posible, el siguiente vector tengo que reconocer que ha sido este. La fuerza bruta no solo se aplica a usuarios/contraseña, sino a un sin fin de metodologías.

Su funcionamiento es casi tan viejo como la historia, lo único que sucede es que nos aprovechamos de la computación para ello: Probar, Probar y Probar. Hace tiempo también escribí sobre ello AQUI

En teoría, si una contraseña no es más que una cadena de caracteres, y dado que los caracteres a usar son finitos, así como la longitud de las contraseñas, cualquier contraseña se podría averiguar sencillamente probando con todas las combinaciones posibles del espacio de caracteres usados. Algo así como la cuenta de la vieja. Puede parecer algo imposible, pero cuando tenemos equipos que pueden realizar comprobaciones a cientos de miles o millones de contraseñas por segundo, la cosa empieza a tener otro color.

Eso no significa que los ataques de fuerza bruta sean siempre viables (posibles sí, viables no). De este modo, decimos que una contraseña es segura desde este punto de vista, cuando a efectos prácticos no es viable por el tiempo estimado que se requeriría. Y este tiempo va a depender precisamente de la longitud y el espacio de caracteres usados.

El ejemplo más simple: Una contraseña de 4 caracteres sólo numéricos: 4 Caracteres, cada uno de ellos tiene 10 opciones diferentes = 10^4

Es decir, que si comprobásemos una a una 10.000 contraseñas, daríamos con la solución. Dicho de otro modo, probar desde el 0000, 0001, 0002… hasta el 9999. A mano sería complicado, pero un equipo podría probar todo ello en cuestión de segundos, o incluso fracciones de segundos si se realiza de forma local.

La defensa ante este tipo de ataques es por ende asegurarnos que cualquier posible contraseña que tengamos cumple mínimamente una longitud/complejidad suficiente para anular cualquier ataque de fuerza bruta, o incluso de diccionario, no comentados en este artículo. Se ha escrito mucho sobre el asunto y calculando que podríamos considerar realmente una contraseña segura. No hay respuesta para esto, además la tecnología sigue su progreso, y lo que antes era imposible computacionalmente o por las redes de entonces, hoy es posible, y dentro de unos años lo que hoy consideraríamos seguro, podría ser insuficiente.

¿En lo personal, que considero seguro? Bueno, podemos siempre usar una contraseña más sencilla a costa de una mayor longitud, o primera mayor complejidad sin ser necesaria una longitud alta. En el artículo que he enlazado anteriormente pongo algunos números. En este caso hablamos sobre todo de autentificaciones online, no locales, lo cual hace que el proceso de un ataque de fuerza bruta sea mucho más lento. En mi opinión:

-Sólo Numéricas: Usar al menos 11-12 cifras. Requeriría años. 10 Cifras sería posible pasarla solo en unos pocos meses, lo que quedaría dentro de lo viable.

-Solo letras minúsculas ó mayúsculas: Tenemos 26 caracteres un espacio mucho mayor que solo 10 números. En este caso a partir de 8 letras debería de ser suficientemente seguro, 7 letras caería en lo posible (en el régimen de meses)

-Mayúsculas y Minúsculas: 26+26 caracteres. A partir de 7 caracteres, 6 sería relativamente viable

-Letras y Números: 26+26+10. 6 caracteres serían suficiente en principio, por ejemplo: «Do1Re2», aunque parezca corta, un ataque online (no local), entraría en años.

Son valores muy por encima, y repito, siempre en ámbito «online». Esos valores serían muy insuficientes si se lanzasen sobre contraseñas locales. Esto es debido a que no es lo mismo depender de las estructuras de red, que depender solo del potencial de la CPU/GPU

¿Mi consejo? Soy práctico, una pequeña frase corta con sentido solo para cada uno. Si se usan espacios y sólo minúsculas tendremos un espacio de caracteres de 26+33, y una frase corta se escribe y recuerda fácil. Lo único que tendríamos que tener más cuidado sería con ataques de diccionario, pero con más de 3-4 palabras tampoco serían viable, o incluir una palabra no existente. Un ejemplo simple:

«Mi casa»

Longitud = 7, complejidad = 26+26+33. Un ataque online tardaría decenas de años, algo tan «simple» como eso. Por supuesto se podría hacer aun mejor para evitar diccionarios y otros: «Mi cas@»

Repito una vez más, hablamos de ataques online, no locales, donde estas complejidades no serían suficiente. Por su parte, y para terminar, es buena política que los propios servicios nos obliguen a crear contraseñas que cumplan un mínimo de seguridad, siendo por tanto un paso más a la hora de forzar una seguridad mayor.


Rehusabilidad

Este es otro gran problema de los usuarios y contraseñas. Todos tendemos a reusarlas, y sí, yo me incluyo. Obviamente no uso una sola contraseña para todo, pero tampoco puedo decir que uso una contraseña diferente para cada cosa, sería imposible para mi, ¿decenas de servicios con diferentes contraseñas y otro puñado diferente de usuarios? Imposible… al menos, en principio.

Nuestra memoria es limitada, y, o usamos trucos memotécnicos, o gestores de contraseñas, o repetimos antes o después. Pero… ¿por qué es tan peligroso el usar la misma contraseña en varios servicios? Porque si esa contraseña es expuesta por cualquier motivo, no solo expondremos un servicio, sino todos los que usamos con ella. Te robo la contraseña de Facebook, y es posible que logre con ello la contraseña de Instagram, el correo electrónico…

Si no podemos memorizar todo, podemos emplear diferentes técnicas:

  1. Trucos Memotécnicos: Usar una sola contraseña «fija» pero derivarla para cada servicio, o usar contraseñas diferentes también dependiendo del servicio en el que el propio servicio nos sirva de contraseña en nuestra cabeza… por ejemplo para Google = 6Letras. Tontería, sí, pero funciona.
  2. Gestores de Contraseña: En lo personal, me he rendido ante su uso. Nunca me han entusiasmado, pero es un modo «seguro» y ordenado de guardar todas nuestras credenciales. Básicamente los gestores de contraseñas mantienen una base de datos/archivo fuertemente cifrado. En conjunto con extensiones de navegadores Webs, aplicaciones móviles… nos permiten no guardar jamás una sola contraseña en ellos (recordados en el navegador por ejemplo), tener contraseñas únicas y complejas, y simplemente tener el gestor de fondo interactuando con nuestros navegadores.
  3. Usar contraseñas separadas. Para cualquier servicio que sea más crítico, usar siempre contraseñas únicas o en combinación con otros métodos que veremos más tarde, mientras que podemos tener contraseñas mucho más simples y rápidas para cosas que incluso en el peor de los casos no nos importaría mucho que nos robasen.
  4. Tener una memoria privilegiada que sea capaz de mantener contraseñas complejas para cada servicio de forma única… no es mi caso.

En cualquier caso… por favor, no uséis la misma contraseña para todo. Las últimas brechas de seguridad con cientos de millones de credenciales de seguridad lo dejan bien claro.

Algunos sistemas/servicios que queremos acceder toman medidas para evitar el rehuso. Algunas medidas es obligar el cambio de contraseña cada X días, impedir el uso de contraseñas que ya se han usado..


Ingeniería Social

Parece increíble, pero al margen de las contraseñas frágiles, este problema es el que se lleva de la mano el mayor índice de contraseñas robadas (sin incluir las brechas de seguridad, que son muy escasas pero de gran extensión)

La ingeniería social no es un harte Hacker, no hay que ser físico nuclear, ni colarse en sistemas super protegidos. Simplemente se trata de conocer a tu enemigo, ser ingenioso… y por supuesto, mentir como un bellaco de forma que parezca creíble.

Aquí tendríamos técnicas como el Spoofing o el Phising, algo que ya dediqué en su día largo y tendido. Por lo general hay dos formas habituales de pertrechar un ataque de este tipo.

El primero es induciendo o intentando que la víctima acceda a una web falsa que le solicita unas credenciales concretas, que al ponerlas lo que hará será enviárselas al atacante. El segundo, es hacerse pasar por amigo/familiar/empresa… y solicitar datos más o menos importantes que podrían llevar a dar con la contraseña, o incluso solicitar la contraseña directamente, a fin de cuenta si nos creemos que el correo es de nuestro padre/madre y que la necesita para algo, se la daremos…

Protegerse de este tipo de ataques es más sencillo, solo hay que tener cuidado. Recordar que si un sistema es fiable, ni siquiera el propio sistema debería de conocer nuestra contraseña, en todo caso resetearla por otra. Eso significa que jamás le demos nuestra contraseña a nadie, diga quien diga que sea.

Protegerse del Phising es fácil también, aunque algo más complicado para los móviles/tablets donde la URL por lo general se corta. Aquí el modo a seguir es simple… asegurarnos siempre al 1000% que la web que estamos visitando es realmente la que dice ser, desconfiar siempre de correos electrónicos digan lo que digan si nos instan a identificarnos o cambiar contraseñas o…

Más adelante detallaré el ataque más persistente que recuerdo que se está aun llevando a cabo a millones de personas, en el que se mezcla la ingeniería social, con brecha de seguridad, con reusabilidad..

Desde el punto de vista de los sistemas, lo tienen complicado protegerse de estos ataques. Una buena información a sus usuarios, uso de técnicas contra el SPAM como dmarc se hacen obligatorias.


Robo/Acceso a la base de datos del Sistema

Uno de los mayores peligros en el uso de usuarios y contraseñas, es que nuestras credenciales tienen que ser almacenadas en los servidores de los servicios/sistemas que nos tienen que identificar, como hemos dicho estos sistemas tienen que cotejar nuestros datos con los que ellos tienen. En un mundo ideal en el que fuese imposible para nadie acceder a dichas bases de datos no habría problema, pero… ¿que pasaría un hacker o un fallo de seguridad expone dicha base de datos? Pues que de un plumazo quedarían expuestas las credenciales de miles, decenas de miles o incluso decenas de millones de usuarios. Obviamente este tipo de brechas de seguridad son raras, pero suceden, y cuando suceden son millones los afectados.

Por desgracia, la única manera fiable de que esto no suceda es no usando sistemas de usuario/contraseña, más adelante, en otros capítulos de esta serie, veremos como existen sistemas de autentificación que no tienen estos problemas.

Eso no quiere decir de todos modos que no existan técnicas no sólo para evitar los accesos no autorizados en sí a la base de datos, sino para que los datos que contiene, en caso de ser robada o accedida ilegítimamente, no tenga información de extrema sensibilidad.

En nuestro esquema base, decíamos que al crear la cuenta, nuestras credenciales eran insertadas en la base de datos del servicio que fuese, y se usaría luego para compararlas cuando iniciásemos sesión. Eso implicaría almacenar la contraseña en lo que llamamos texto plano, lo cual siempre es un peligro. En un sistema que sea seguro, la contraseña jamás tendría que ser conocida ni siquiera por el proveedor del servicio, es decir, jamás se debería de almacenar en texto plano, además, no es necesario.

En criptografía, es bien conocido el término de Hash. Un Hash es un algoritmo de un solo camino que es capaz de tomar cualquier entrada y convertirla a una cadena de una longitud fija. Los Hash tienen propiedades muy interesantes. Un Hash siempre dará la misma salida para exactamente la misma entrada, pero si se modificase aunque fuese un solo bit en la entrada, el hash se modificaría por completo. Esto hace al Hash ideal para verificar la integridad de los datos por ejemplo, se calcula el hash en origen, se envían los datos y en destino se vuelve a comprobar el mismo hash, si es igual al que se calculó en origen, los datos no han sido modificados.

Otra peculiaridad de los Hash, es que al contrario que el cifrado, un Hash no es reversible, es imposible obtener la entrada a partir de la salida. Es más, dado que los hash tienen una longitud fija (dependiendo del algoritmo usado tendrá una u otra) y la entrada es totalmente arbitraria, diferentes entradas podrían en un casual producir salidas iguales. A esto se llama colisión, y de cara a la seguridad del Hash es primordial. No obstante, por lo general, usamos hash con salidas grandes. El viejo MD5 está cada vez más en deshuso, con una salida de 128bits. Actualmente los Hash más usados, por citar algunos, serían MD5 (aun), SHA-1, SHA256, HMAC…

Esta peculiaridad de los Hash, esta transformación unidireccional que pueden aplicar, se usa además para comprobar integridad, para crear derivados únicos de datos sensibles. Esto es muy útil para almacenar contraseñas sin necesidad de cifrarlas, o para anonimizar datos. Con todo ello ya podemos imaginar por tanto como va a funcionar la cosa…

En cualquier esquema que se precie, el sistema/servicio jamás almacenará la contraseña del usuario, en vez de eso almacenará por ejemplo un hash de dicha contraseña. Para el usuario que quiere acceder es indiferente, porque cuando el sistema quiera cotejar la contraseña insertada por el usuario, este la transformará con el mismo hash, y será el hash de la contraeña el que se busque correspondencia.

Ante una brecha de seguridad, tan solo se podría acceder a los hash de las contraseñas, no a las contraseñas mismas. Dado que los hash son funciones de una sola dirección, en teoría es complicado obtener las contraseñas reales. Por supuesto no es oro todo lo que reluce, y ante esto también hay ataques, generalmente con lo que se llaman tablas arcoíris, tablas precalculadas de hash de todo tipo de contraseñas. Algo así como una tabla creada por fuerza bruta que contiene la lista de millones de posibles contraseñas y su hash correspondiente. De este modo los hachers comparan los hash con el delas tablas arcoiris, y si identifican un hash en su tabla, ya sabrán la contraseña asociada.

En cualquier caso, aunque las tablas arcoiris son muy eficientes y rápidas, por lo general su efectividad es limitada, volveríamos a la necesidad de contraseñas más o menos seguras. Pero no olvidemos algo, en caso de brecha de seguridad todo ese tipo de ataques ya no serían sobre internet, serían en local, un hacker podría someter la base de datos robada a un análisis exhaustivo en su equipo o en centros de datos mucho más potentes para buscar correspondencias en tablas arcoíris y poder «revertir» muchos hash.

Debido a esto, y para luchar contra los ataques de fuerza bruta y las tablas arcoiris, hace muchos años que alguien inventó lo que hoy conocemos como «Sal» (Salt en ingles). La Sal suele ser una pequeña cadena de bytes aleatorios que se añade/intercala a la contraseña antes de realizarle el hash. Esto puede parecer un sinsentido, pero evita enormemente que cualquier ataque de fuerza bruta, de diccionario o de tabla arcoiris pueda afectar a contraseñas débiles o poco seguras. Cualquier añadido que le hagamos a la contraseña de forma automática, invalidaría cualquier intento en una tabla arcoiris o en cualquier ataque de fuerza bruta, ya que la contraseña usada sería diferente. La Sal suele ser única para cada contraseña, y se almacena en la base de datos como texto plano. Pero entonces ¿no podrían también robar la Sal, y con ello poder crear tablas arcoiris? Claro que sí, la cuestión está que precalcular las tablas arcoíris requiere una enorme cantidad de tiempo, cuantos más caracteres de entrada tengamos mucho más! eso implica que el hacker tendría que recrear las tablas arcoiris para cada usuario, no podría nunca reusarlas porque la Sal en cada uno es diferente. Precisamente las tablas arcoiris son tan útiles porque aunque se tarde años en calcular tablas maravillosas, luego puedes usarlas una y otra vez, y los resultados son casi instantáneos si el hash ya se ha computado. Pero claro, si hay Sal por medio, dichas tablas no valen para nada.

Para el usuario esto es también transparente, simplemente el sistema además de almacenar usuario y contraseña, almacenaría la Sal usada. El usuario al identificarse solo pondría su contraseña, el sistema leería la Sal de la base de datos, se la añadiría, calcularía el Hash y lo comprovaría con el almacenado.

Como última medida, se podría directamente cifrar el contenido de la base de datos, añadiría complejidad al sistema y lentitud. Además, se deberí ade usar una clave para cada entrada, si fuese una sola contraseña general para todos y fuese igualmente filtrada o averiguada, permitiría desencriptar toda la base de datos.

Nosotros, como usuarios, no podemos evitar las brechas de seguridad. Pero eso no significa que no podamos hacer nada:

  1. Cambiar las contraseña de cuando en cuando, esto impide que brechas de seguridad viejas afecten a nuestras cuentas a día de hoy.
  2. Usar contraseñas decentes, mejora la resistencia frente a posibles ataques.
  3. Fiarnos siempre de los servicios a usar, no todos usan buenas políticas, a día de hoy aun hay miles/cientos de miles de servicios que siguen almacenando las contraseñas en formato plano.
  4. Esta web nos permite de forma rápida saber si en algún momento alguna brecha de seguridad de algún servicio expuso nuestra contraseña. Puede ser vieja, puede ser actual… no significa que no estar ahí implique que estamos a salvo, pero es un buen comienzo

Para entender la importancia de las brechas de seguridad, pensemos que no hace ni 2 días (a fecha de 20 de Enero), que Facebook tuvo que reconocer que cientos de millones de contraseñas de cuentas de Facebook e Instagram se habían estado registrado/guardando en texto plano (sin hasheo, sin encriptación, nada). Aunque aseguraron que no tenían constancia que hackers pudiesen a ver accedido a ellas, si reconocen que sus empleados tuvieron accesos, y de echo se sabe que se realizaron miles de búsquedas en dicha base de datos de sus propios empleados. Dicho de otro modo si se prefiere, las contraseñas de cientos de millones de personas han estado expuesta a sabe dios quien.

La única solución efectiva ante este tipo de ataques y problemas, los veremos más adelante, como por ejemplo sistemas que no intercambian información sensible como contraseñas, o sistemas de doble autentificación.


Transmisión de Credenciales y Malware

Para acabar, y no menos importante, está el problema que conlleva el tener que usar una cadena concreta como la contraseña. Ya hemos visto el peligro que acarrea que las bases de datos externas tengan que almacenarlas, pero también es un peligro cada vez que las usamos.

Hay diferentes «lugares» o «puntos» en los que nuestras contraseñas deberían de estar protegidas. Si una contraseña es tan importante, al igual que se almacenan de forma codificada en los servidores (al menos deberían), tendríamos que tomar las medidas igualmente adecuadas para asegurarnos que llegan al destino sin que nadie pueda interceptarlas.

El primer problema aquí estaría en nuestro propio equipo, cuya responsabilidad es nuestra. Un sistema puede ser extremadamente seguro, pero si tenemos un malware que registra cada tecla que presionamos, estaremos dándole a atacantes todas las contraseñas que quieran. Los KeyLogger son demasiado habituales a día de hoy como no tenerlos en cuenta. Ante esto, lo único posible es tener buenas políticas de saneamiento de nuestros equipos, no instalar nada que sea dudoso, y ante la duda pasarlo por antivirus, mi recomendación siempre: Virustotal.

Pero ahí no se acaban los problemas, solo empiezan. Muchas webs solicitan las contraseñas en sus formularios de inicio de sesión o registro de forma directa, es decir, no las transforman antes de ser enviadas. Al igual que se puede guardar la contraseña en una base de datos de forma «codificada» con un Hash, el código de la página web del servicio en cuestión podría igualmente optar por medidas como codificar directamente a algún hash la contraseña antes de ser enviada. Esto hay muchos que no lo comparten, puesto que si alguien intercepta nuestro tráfico, aun cuando se estuviese transmitiendo un hash, podrían en principio clonar la sesión o hacer uso del mismo hash para identificarse. Es verdad que el sistema no es perfecto, pero al menos no conocerían nuestra contraseña real, ya que esta no se transferiría nunca como tal

Pero quizás la medida más importante, sea el asegurarnos que cualquier contraseña o dato sensible que pudiese transferirse a través de internet, va cifrado, al margen de que la contraseña vaya protegida o no. Y sí, hablamos obviamente de que las páginas visitas estén siempre protegidas por certificados digitales y sea posible su navegación por protocolo seguro HTTPs.

Cuando conectamos por HTTPs, todo el tráfico entre el servidor remoto y nuestro PC, es cifrado extremo a extremo, sin que nadie en medio pueda saber la transmisión de datos, sean sensibles o no. Esto cuando transmitimos datos «sensibles» es de vital importancia. Pensar que es extremadamente sencillo colocar un analizador de paquetes en una red cualquiera y realizar ataques de Man-in-the-Middle (MiTM). Peor aun, quien nos dice que la red WIFI a la que nos conectamos en el trabajo, en la universidad, en casa de vecinos/amigos… ¿es segura?

Este experimento lo he realizado varias veces. Se trata sencillamente de crear una red de «invitados» en mi Router sin ningún tipo de seguridad, para que se conecten a ella quien quiera. Luego, como el Router lo control completamente, me es muy sencillo crear un «proxy» transparente de modo que el 100% del tráfico que esa red genere me sea reenviado y poder ver así absolutamente todo lo que hacen. Bien, pues es bien simple, todo el tráfico que no vaya cifrado, aparecerá tal cual por delante de mis ojos, incluyendo contraseñas si se están transmitiendo en plano:

POST /wp-login.php HTTP/1.1
Host: miblog.com
Content-Length: 123
Cache-Control: max-age=0
Origin: http://miblog.com
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3739.1 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3
Referer: http://miblog.com/wp-login.php?loggedout=true
Accept-Encoding: gzip, deflate
Accept-Language: en,en-US;q=0.9,es;q=0.8
Cookie: viewed_cookie_policy=yes;
Connection: close
log=Admin&pwd=MyPassword&wp-submit=Acceder&redirect_to=http%3A%2F%2Fmiblog.com%2Fwp-admin%2F&testcookie=1

Cuando se transfiere la página por HTTPs, en principio todo el tráfico que podría leerse estaría cifrado. No obstante, técnicamente es posible también intentar usar ataques de inyección de certificados, pero por la propia naturaleza de estos, quien visitase dichas páginas vería avisos de seguridad.

Lo que está claro es que, al margen de que un Hacker puede buscar mil vueltas para llevar a cabo sus designios, tenemos que tener siempre un mínimo de cuidado. Y en cuanto a contraseñas se refieren, jamás, pase lo que pase, introducir una credencial o cualquier dato que pueda ser sensible en una página que no está bajo conexión segura, y con un certificado válido.

Cada vez más se usan certificados digitales en los servidores Web para proteger las transmisiones (Gracias Let’s Encrypt!!) , pero esto también propicia a que los programadores y los encargados en diseñar los sistemas presupongan que las comunicaciones siempre se harán bajo HTTPs, con lo que no toman medidas a la hora de «codificar» los datos sensibles antes de que salgan del propio navegador del usuario. En el ejemplo anterior, vemos que WordPress no codifica las contraseñas, las transmite en plano. A día de hoy posiblemente más de un 30% de las webs sean WordPress, pero el porcentaje de todas ellas que usan HTTPs es «pequeño». Eso significa un numero ingente de páginas, algunas bien conocidas, que pueden transmitir los datos al servidor de forma clara, tan clara que cualquiera podría interceptarlos.


El nuevo ataque que está causando estragos desde hace meses, y apuntes finales

Me gustaría terminar con los usuarios y contraseñas con un ataque real que se lleva realizando desde hace meses, y es extremadamente peligroso por el ingenio que hay detrás, y por desgracia el miedo y el desconocimiento del usuario.

El uso de este sistema de autentificación es obsoleto, aunque muy cómodo, hasta el punto que continuamos usándolo por defecto y de forma mayoritaria. Los problemas que tiene son muchos, y aunque hay «soluciones» parciales a parte de ellos, es algo que tenemos que tener bien presente, y a medida que sea posible, migrar nuestros sistemas tradicionales a otros mucho más seguros, que veremos en otros artículos.

Quien no esté al tanto, en los últimos meses se han ido filtrando listados de cientos de millones de credenciales, provenientes de muy variados servicios de en los que en algún momento dado alguien logró acceso a sus bases de datos. Repito, hablo de listados de cientos de millones de usuarios-contraseña, perteneciente a todo tipo de servicios, algunos más conocidos otros menos. Por supuesto, muchas de esas brechas de seguridad son viejas, cuentas de hace años muchas abandonadas u olvidadas, y contraseñas igualmente viejas. Otras mucas en cambio son recientes…

En números… tengo por ahí el último leak masivo, hablamos de TeraBytes de información, solo en listados.

Bien, eso es el precio a pagar a usar usuarios/contraseñas, y servicios mal protegidos o con políticas deficientes. A raiz de estas filtraciones masivas, muchos pensaron como sacarle rédito… muchas credenciales aun son válidas, pero hablamos de cientos de millones, como sacar partido a todo ello.

En algún momento de estos meses atrás, a saber quien fue el primero al que se le ocurrió la idea, se puso en marcha un ingenioso ataque masivo, usando como base dichas filtraciones, sin importar realmente que los datos que contenían seguían siendo válidos o no, ya que para sus intenciones esto realmente daba igual.

  1. El ataque trataba en enviar de forma masiva correos electrónicos a las cuentas de correo que venían en las filtraciones, que como ya he dicho eran de diferentes servicios, no necesariamente a servicios de correo electrónico, pero sabemos que el correo electrónico suele usarse como usuario. Con lo que el primer daño estaba hecho, miles de millones de correos electrónico expuestos, ideal también para los Spammers
  2. Para meter miedo y llamar la atención, en el asunto del mensaje se especificaba algo como: «Conozco tu contraseña: 123456», siendo 123456 la contraseña que se había filtrado junto al usuario dado que normalmente es el correo electrónico. Obviamente esa contraseña podría ser vieja, podría ser de cualquier servicio, pero sea como sea las filtraciones son reales, así que el usuario lo que ve en su correo es que alguien le ha enviado un correo y en el asunto reconoce una contraseña de él.
  3. Se redactaba un correo intimidatorio, diciendo que era un hacker, que se había apoderado de su PC e instalado software malintencionado, que lo estaba vigilando por la cámara Web, que sabía todo lo que hacía… y que como prueba de todo ello sabía su contraseña, especificada en el asunto. Hay muchas versiones, en algunas intimidan diciendo que conocen todas las webs pornográficas visitas, otras que tienen material sensible de ellos, otras que… en realidad son correos genéricos cuyo texto podría más o menor cuadrar en el 80% de la población, similar a los horóscopos, escribes algo genérico que casi todo el mundo cumplirá, y le das tintes de veracidad con la contraseña o cualquier otra cosa. Todo Mentira, obviamente, simplemente te mandan dicho correo que se filtro enalgún momento tu correo electrónico y posiblemente la contraseña de algún servicio.
  4. Por último, se insta a realizar un pago en bitcoins como extorsion para evitar que los datos comprometidos que supuestamente tienen de nosotros vean la luz.

Bien, puede parecer una tontería, pero muchos se han hecho de oro. Haciendo uso de filtraciones viejas, ingeniería social, instigar miedo, dar tintes de realidad con datos que supuestamente tienen de nosotros… cuando la triste realidad es otra, es todo mentira, no son hackers, no tiene nada, en el mejor de los casos una contraseña, que de ser cierto que la usamos en ese mismo momento en algún servicio, sería bueno cambiarla de inmediato. Os dejo la imagen de un correo de este tipo que ha estado dando guerra desde hace meses, aunque es verdad que hace ya uno o dos meses que no me llegan detalles de que se siga usando, pero si algo hemos aprendido de los ataques informáticos, es que tarde o temprano volverá:

Es hora de avanzar, no es malo seguir usando usuarios/contraseñas, pero podemos usarlos en conjunción de otros sistemas que eviten las sorpresas, o incluso sustituirlos por completo. Lo que está claro es que si queremos una autentificación fiable, segura y sin riesgo, hacerla por usuario/contraseña implica muchos riesgos.

Hay una frase que me encanta, y que usaremos por aquí en varias ocasiones, en relación a cuando un sistema podemos considerarlo seguro, cuando este esté protegido por: «Una cosa que seamos, Una cosa que tengamos y una Cosa que sepamos»

Las contraseñas, a fin de cuenta, cumplen el tercer requerimiento, es algo, en teoría, que solo nosotros deberíamos de saber.



La Autentificación en tiempos modernos. Introducción

Llevo mucho tiempo queriendo escribir sobre sistemas de doble autentificación, y específicamente sobre FIDO, y después de varios años, he creído que ya era hora. Así que aprovechando la gran demora en años, voy a aprovechar para dar un repaso del paradigma actual de la identificación.

La identificación puede parecer algo antiguo e incluso sencillo, algo que incluso nuestros abuelos y nuestros hijos/nietos bien conocen. Quizás el ejemplo más cotidiano sea nuestro DNI. ¿Y cual es la funcionalidad principal de este? Pues ni más ni menos, incluso en los tiempos que corren, la de identificarnos de forma única ante el mundo.

Internet no es tan diferente, es una entidad «virtual», pero se rige más o menos por los mismos principios. Por supuesto puede ser deseable permanecer anónimo dentro de la gran red de redes, al igual que puede ser deseable muchas veces en el mundo real querer ocultar nuestra identidad, y para nada sólo con fines delictivos. Pero al igual que pasa en el mundo real, también necesitamos muchas veces, la mayoría de ellas, que el mundo sepa quien somos, algo que nos apunte de forme inequívoca.


EL USUARIO COMO IDENTIDAD

Internet supuso un antes y un después, y con él aparecieron un sin fin de nuevos… «servicios» para las personas. Desde el correo electrónico, las nuevas formas de comunicación como IRC (que con el tiempo evolucionaría a la mensajería instantánea), foros, blogs, comercio online, redes sociales… un universo que sigue una escalada exponencial, y en el que cada vez, nosotros como individuo, tenemos más peso. Nos comunicamos por Internet, compramos por Internet, nos informamos por Internet… tal es así que incluso vamos dejando muchos servicios tradicionales, y moviéndonos rápidamente a los digitales.

Pero para que todo ello haya sido posible, ya desde los orígenes, ha sido necesario que la inmensa mayoría de servicios que usamos sean únicos para cada persona, donde podremos muchas veces mentir sobre los datos que queramos dejar, pero sean falsos o ciertos, nos identifican en sus sistemas. No hizo falta ser un genio, sólo el sentido común para entender la necesidad de diferenciar a cada persona en dichos sistemas informáticos, al igual que el DNI nos identifica y lo necesitamos en nuestro país.

Se crea así una graciosa paradoja. Cada día, hoy más que nunca, se pone de relieve la necesidad del anonimato de Internet, el Big Data (algún día hablaremos de ello) es una realidad. Aunque suene feo, estamos (algunos más que otros) totalmente «vendidos» a multinacionales, nuestras costumbres y nuestro insaciable consumo digital ha permitido que las grandes tecnológicas sepan más de nosotros que nosotros mismos!!. ¿Qué como es posible? Soy un enamorado de Google, pero eso no quita que sepa fehacientemente que tienen un «perfil» de mi persona, nutrido no solo de todos sus servicios que puede usar, sino del propio rastro/huella digital que he ido dejando en el paso de los años. Esto es mucho más siniestro si tenemos en cuenta que a día de hoy la Inteligencia Artificial puede aplicarse a esos «perfiles» para, aunque suene a ciencia ficción, saber que queremos, a donde vamos…

Pero pese a esa lucha constante por el anonimato, no deja de existir una realidad inherente también: No queremos ser anónimos. Aquí hay que explicar el sentido que vamos a darle a «anónimo». Aquí no vamos a llamar «anónimo» a un usuario que sencillamente miente con sus datos o usa pseudónimos. Yo mismo sirvo de ejemplo. Sí, escrito y se me conoce por mi pseudónimo, Theliel, y este pseudónimo me anonimiza en cierto aspecto, puede que el lector no conozca mi nombre real, o mi dirección… pero de cualquier modo identifica a mi persona con dicho nombre. De tal modo que Theliel es, entre otras cosas, el chico de Alma Oscura.

Esto es necesario. ¿Como si no podríamos usar la gran cantidad de servicios que usamos? Puede que en un momento dado nos gustase poder mandar un correo anónimo, pero si siempre fuesen anónimos, ¿como nos relacionaríamos? y si compramos algo… ¿como pagaríamos o donde recogeríamos las compras? En el mundo digital, por su misma naturaleza, es mucho más complicado demostrar que nosotros somos nosotros, y de una forma inequívoca.

Y ahí está el problema, no se trata sólo de poder identificarnos ante un sistema, sino tener garantías que dicho sistema no se va a equivocar, que nadie va a poder hacerse pasar por nosotros y suplantarnos. Y esto no es fácil, nada fácil. Tal es así que toda esta serie de artículos versan sobre ello, sobre los principales modos de hacerlo posible, cada uno con sus pros y sus contras.


LA EVOLUCIÓN EN LA AUTENTIFICACIÓN DIGITAL

Las necesidades de ayer no son las necesidades de hoy. El mundo digital sigue cambiando, y la sociedad tiene que seguir adaptándose. Cada vez tenemos «asociados» más servicios y contenido a nuestra persona, con lo que cada vez es más importante la seguridad en la red, y nuevos métodos de autentificación. El problema parece muy sencill, en principio sólo necesitaríamos un identificador único, como es nuestro número de DNI, ¿no? En principio cualquier identificador único nos serviría, como un DNI, el número de teléfono…

Y aunque parezca mentira, ellos fueron los primeros modos de identificación dentro de Internet, identificadores únicos. Es más, a día de hoy la propia Internet funciona gracias a un sistema de identificación único de páginas Web, que llamamos Direcciones IP, y que por medio del protocolo DNS mapeamos nombres únicos a direcciones concretas.

Extrapolar esto a las personas tuvo un camino muy corto. Ahora mismo nos acercamos a los 8 mil millones de personas en el mundo, os ¿imagináis un «DNI» de 20 dígitos? Complicado de recordar, de usar. Y este es el segundo gran problema con el que se topó la autentificación digital, no sólo necesitábamos que fuese única y segura, sino que fuese práctica y fácil de aplicar, y pasar minutos buscando un papel con una cadena imposible de memorizar, ir tecleándola sin error… no es viable.

Este sistema era muy mejorable. A fin de cuenta no todos las personas se conectan al mundo digital, y cuando lo hacen tampoco a los mismos servicios. Podría ser suficiente por ende identificadores mucho más pequeños, incluso inteligibles, y así aparecieron los actuales «Usuarios«, a fin de cuenta cadenas únicas que nos identifican en un servicio, que suelen ser correos electrónicos, pseudónimos… o realmente lo que queramos. Pero estamos en el mundo digital, y una cadena que puede imaginarse, copiarse, filtrar… dicta mucho de ser seguro, así que casi de forma obligatoria nos vimos obligados a usar otra cadena adicional asociada a ese ID principal, una cadena que pudiésemos mantener en secreto, sin peligro a que el usuario fuese conocido o averiguado. Y ya tenemos las «Contraseñas«

Da igual los años que hayan pasado, a día de hoy la autentificación por medio de Usuario y contraseña sigue siendo de lejos la más extensa.


Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.