Archivar por marzo, 2019

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.


La Autentificación en tiempos modernos. Índice.

Como siempre, empecé con una publicación sencilla y la cosa terminó siendo necesaria una división por partes… A medida que vaya publicando el resto de contenidos, iré actualizando los enlaces.

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.