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.