Los TPM son la raíz de toda la seguridad. Sin TPM = Sin seguridad

 

Introducción

Todo el mundo está de acuerdo en que los ATM deben estar asegurados en la mayor medida posible sin restar importancia a su facilidad de uso. Sin embargo, parece no haber un consenso sobre cómo lograrlo. Parte de esa confusión surge debido a la competencia entre proveedores, con diferentes productos de seguridad que compiten por la atención del cliente. Pero también hay una buena cantidad de información errónea que confunde a los clientes y, en última instancia, conduce a implementaciones deficientes que son vulnerables a los ataques.

Este documento técnico reunirá fundamentos importantes de la seguridad del sistema, empezando por la línea de base de cómo deben protegerse los sistemas informáticos individuales y luego abordando el caso de uso único de las redes de ATMs que, por supuesto, requieren el más alto nivel de protección. Las redes de ATMs no solo contienen bastante dinero en efectivo, sino también son un potencial punto de entrada a los sistemas informáticos de los bancos, lo que te daría acceso a muchas cuentas y a poder realizar, por ejemplo, transferencias.

Primero, veamos algunos conceptos erróneos que son comunes sobre la seguridad en nuestra industria. Tal vez el mayor error en la seguridad del sistema es un mal entendimiento del concepto de seguridad en capas. Es cierto que no existe una solución mágica cuando se protege un sistema tan complejo. Para esto se necesitan múltiples bloqueos coordinados. Sin embargo, a menudo se malinterpreta ese concepto en el sentido de que cuanto más compleja sea la seguridad, más seguro será el sistema.  Esto simplemente no es el caso. Existen técnicas criptográficas fundamentales que pueden ser simples, discutidas abiertamente y bien entendidas, éstas deben conformar el núcleo de cualquier arquitectura de seguridad. Estas técnicas no solo ofrecen seguridad cuantificable, sino que también son fáciles de usar y no dependen de los usuarios para que funcionen.

Vamos a ilustrar esto con un ejemplo rápido. Todos estamos acostumbrados a sistemas de PC que requieren un nombre de usuario y contraseña para iniciar sesión. A medida que el sistema de seguridad basado en contraseñas fue atacado por hackers, las organizaciones crearon reglas de contraseñas cada vez más complicadas que son muy poco amigables para los usuarios, algunas como: cambios regulares de contraseñas, no poder usar las últimas “x” contraseñas, creación de contraseñas complicadas y difíciles de recordar, etc. Microsoft cortó todo eso con «Windows Hello».

“Windows Hello” combina el reconocimiento de dispositivos de hardware seguro con cifrado TPM y el reconocimiento facial biométrico. Esto es, de hecho, muy similar a un concepto de seguridad que la industria de los ATM entiende bien: chip y pin. Con Windows Hello, el chip es el TPM, que es un procesador criptográfico similar al chip en una tarjeta de pago, y la información biométrica ocupa el lugar del pin. Este sistema no solo es más seguro que cualquier sistema de nombre de usuario más contraseña, sino que también es fabulosamente fácil de usar. No solo puedo iniciar sesión en mi tablet con solo mirarla, tenemos que alejarnos de la idea de que no hay ganancia sin dolor: la seguridad real no requiere una tortura para el usuario.

Habrá notado que introdujimos el concepto de TPM en el párrafo anterior. Este documento se basa en los TPM como la «raíz base de la confianza» en la informática. El TPM es un chip semiconductor seguro que consta de una arquitectura de seguridad diseñada por el Trusted Computing Group (TCG) constituido por más de 100 empresas, incluidas empresas importantes como Intel, Microsoft, HP e IBM. Su trabajo comenzó en 1999 con el objetivo de crear un núcleo seguro para dispositivos informáticos donde toda la seguridad informática pudiera construirse a partir de ese núcleo seguro. La buena noticia es que los TPM son completamente estándar en todos los nuevos dispositivos de PC y lo han sido durante muchos años. La mala es que muchas organizaciones ni siquiera saben que tienen esta joya de seguridad dentro de sus dispositivos informáticos y no se aprovechan de ella. Este documento es un intento de cambiar esa situación, especialmente para nuestra industria de los ATMs. Después de todo, necesitamos una informática más segura que la mayoría de las industrias.

TPM — la «raíz base de la confianza»

¿Qué significa «raíz base de confianza» y por qué el TPM es fundamental para la seguridad informática? Para entenderlo, es importante apreciar que toda la seguridad informática se basa en el uso inteligente del cifrado. El cifrado es un método informático que convierte los datos de una forma “clara” a una forma aparentemente aleatoria y viceversa.

Cuando los datos o la información están en la forma clara, pueden utilizarse para un propósito previsto. Cuando los datos se cifran, no se pueden utilizar hasta que se descifran. Lo crucial que hay que apreciar sobre el cifrado y el descifrado es que se necesita una «clave» segura para cifrar o descifrar datos. Sin la clave, los datos cifrados son inútiles. De hecho, la palabra «clave o llave» en este sentido no es diferente de una clave para una caja fuerte. Si se pierde la llave de una caja fuerte, no se puede acceder al oro dentro de esa caja fuerte. En informática, el oro son los datos que están protegidos por el proceso de cifrado.

Ahora, lo importante a entender es que la clave en sí debe estar en forma clara para poder utilizarse y descifrar un mensaje. Esto significa que necesita tener una forma de almacenar la clave de manera segura. Sí, puede cifrar esa clave con otra clave, eso haría que la clave original fuera segura, pero luego tiene un problema sobre dónde almacenar la segunda clave. De hecho, puede tener una cadena de claves (y muy a menudo hay una cadena de este tipo). Pero la clave inicial debe almacenarse en algún lugar seguro en forma clara. ¿Dónde se puede almacenar una clave maestra “clara” dentro de una computadora? La respuesta es NO en el disco duro (o SSD). Es imposible almacenar una clave clara en el disco de forma segura, un hacker que puede obtener acceso físico a la unidad siempre puede encontrar la clave clara. El software por sí solo no puede protegerlo si un atacante tiene acceso físico.

Ingrese al TPM. El TCG diseñó el TPM como una bóveda de hardware para los secretos, está integrado dentro de la placa madre y en algunos diseños el TPM puede estar embebido dentro del propio chip de la CPU. Está diseñado para el propósito exacto de guardar las claves de forma segura. También es mucho más que un simple almacén de claves, y llegaremos a eso en la siguiente sección. Por el momento, considere que un sistema informático puede tener una cadena de claves, pero que la clave al inicio de esa cadena debe estar clara y debe almacenarse de forma muy segura para que solo pueda utilizarse con fines confiables. El TPM es ese almacén de claves.

Raíz base de la medición de confianza (CRTM, por sus siglas en inglés)

Les aseguré que el TPM no es solo un glorioso almacén de claves. Piense en el primer problema que tiene un almacén de claves seguro, en su primer día de trabajo. Si alguien le dice al TPM: «¿Puedo tener esa clave clara?» ¿Cómo sabe quién está pidiendo la clave? Está muy bien almacenar una clave de forma segura, pero ¿a quién le va a dar esa clave? ¿Es una pieza legítima de código que pide usar la clave o es algún malware? Tiene un hacker modificado el software en la PC con un malware, y luego dice siempre cortésmente: «TPM, ¿puedo usar la clave?» Ese es el problema: no es suficiente con ser un almacén de claves súper seguro. Debe autenticar el software que solicita usar esas claves. Presentamos ahora el truco de segunda parte del TPM: la raíz base de la medición de confianza (CRTM).

CRTM trabaja con una cadena de confianza que comienza en el encendido. El hardware y el TPM trabajan de la mano para «medir» la secuencia de arranque del PC desde el arranque inicial, luego al BIOS/UEFI, y hasta el inicio del sistema operativo. «Mide» si alguno de los programas informáticos del PC ha sido modificado o alterado durante el proceso de puesta en marcha. Este proceso es más conocido como arranque seguro, que hoy es una característica estándar de los nuevos núcleos de PC que utilizan el firmware UEFI para iniciar el PC.

Para ayudar con el arranque seguro, el diseño de TPM introdujo un concepto llamado PCR (registros de configuración de plataforma). Los valores de PCR son calculados por el TPM en un proceso llamado «extender la PCR» de una manera algo similar a la creación de una cadena de bloques, lo que resulta en que los PCR tienen una huella digital única (es decir, un conjunto de hashes) de la secuencia de inicio de la PC. Si los PCR no se modifican desde el pasado, el software de arranque en el PC no se modifica, y eso está garantizado criptográficamente. Es imposible que el malware haya modificado ni siquiera un solo byte, del software de arranque medido, sin afectar los valores de PCR.

Este es un concepto muy importante en la criptografía. Lo que se conoce como la función hash segura es una función de cifrado que convierte un bloque de datos en una cadena de caracteres de longitud fija que actúa como una huella digital de los datos originales. Si los datos cambian, la huella digital cambia. Por lo tanto, esta es una forma segura de detectar incluso la modificación más ligera de un gran cuerpo de software. El TPM utiliza una variante de hash llamada HMAC. Un HMAC tiene un «hash con clave», lo que significa que solo alguien que tenga la clave segura correcta puede generar o verificar el hash HMAC. Es una especie de «hash cifrado».

Hay una razón por la que llegamos a esta parte en detalle. Esta es la forma en que la tecnología TPM garantiza que el software principal del ATM sea 100 % seguro. No hay forma de modificar ni siquiera un solo bit de software en la secuencia de arranque de un ATM protegido por un TPM sin romper la criptografía moderna. También es el concepto que luego extendemos en este documento para asegurar el resto del ATM.

Ahora tenemos un núcleo de software seguro: ¿qué pasa con el software de la aplicación?

En un ATM de Windows 10, hay dos tecnologías importantes de Microsoft que toman el control en este punto. Bitlocker y Device Guard (ahora conocido como Control de aplicaciones de Windows Defender ‒ WDAC). Bitlocker es la tecnología de cifrado de unidades de Microsoft, es capaz de cifrar todo el disco duro o SSD, y lo que es más importante, guarda su clave de cifrado de unidad «en el TPM». En realidad, es un poco más complicado que simplemente guardar la clave en el TPM. Arrojaremos un poco de luz.

Tenga en cuenta que no es suficiente simplemente almacenar claves de forma segura, es esencial averiguar «quién» está pidiendo la clave antes de entregarla. El TPM tiene otro nuevo truco llamado «sellado» de la clave. Cuando la unidad o disco duro de un ATM se cifra por primera vez en un entorno seguro y Windows genera una nueva clave, esa clave se cifra utilizando una «clave de cifrado» separada llamada KEK. La propia KEK se vuelve a encriptar en un proceso llamado «sellado» utilizando los valores de PCR y una clave privada del TPM. Cuando se inicia el ATM, la clave KEK solo estará disponible si se han validado todas las huellas digitales del software principal medidas por los PCR, lo que significa que el BIOS y el código de Windows no han sido manipulados, como se explicó anteriormente. Al usar la KEK, Windows descifra su clave de cifrado del disco y la usa para descifrar toda la unidad. Una vez recuperada la KEK, Windows cierra la “puerta KEK” detrás de él. Lo hace al «extender» la PCR 11, lo que significa que la PCR 11 se modifica después de quitar el sello de la KEK, de modo que nadie más pueda recuperarla posteriormente. La KEK se mantiene a salvo por el TPM hasta la siguiente secuencia de arranque y solo se pone a disposición de nuevo si los PCR confirman que ningún software principal ha sido manipulado y, a continuación, cierra la puerta de nuevo tan pronto como la KEK haya sido puesta a disposición de Bitlocker para descifrar la unidad.

Como puede ver, hemos construido el software principal paso a paso, comprobando cada uno con los PCRs para asegurarnos de que no haya habido manipulación, hasta que completemos el proceso de arranque y carguemos Windows. Ahora tenemos que iniciar el software de la aplicación del ATM y verificar que todos los ejecutables requeridos no hayan sido manipulados antes de usarlos. En otras palabras, ampliamos aún más los mismos conceptos de comprobación de la huella digital criptográfica de cada componente de software antes de usarla. Windows WDAC (o software de terceros con funcionalidad similar) es el encargado de ejecutar esta parte final de la cadena de inicio. Esto a menudo se denomina la lista blanca, y da como resultado el hash (es decir, la huella digital calculada) de cada ejecutable el cual se comprueba antes de que se le permita ejecutar.

Lista blanca del ATM

La mejor manera de incluir software del ATM en la lista blanca usando WDAC de Windows (u otro software de lista blanca) es usar lo que se conoce como una «regla de certificado». Esto requiere que el software que se implementa en el ATM haya sido firmado previamente por el desarrollador de ese software. Por ejemplo, los ejecutables de Windows 10 están firmados por Microsoft con su clave privada, esto significa que cualquiera haciendo uso de la clave pública puede verificar que los ejecutables de Windows no hayan sido modificados ni manipulados en tránsito y que están en el mismo estado en el que estaban en el momento en que fueron firmados por Microsoft. Para que WDAC confirme eso, todo lo que se necesita es crear una «regla de certificado» que diga que los ejecutables firmados por Microsoft son seguros de usar.

Del mismo modo, el software de KAL siempre está firmado por la clave privada de firma de código de KAL. Nuestros clientes pueden verificar que el software de KAL no ha sido manipulado instalando el certificado de firma de código de KAL en cada ATM.

Pero ¿Qué pasa con otro software que puede no estar firmado previamente de esa manera? Allí, hay tres opciones abiertas al banco:

• Hacer que el proveedor firme su código.
• Despedir al vendedor. (¿Hay realmente proveedores de ATM que no firmen su código en el año 2020? Aparentemente, sí).
• Una Utilización de una «regla hash».

Regla hash es una regla que se agrega a la directiva de lista blanca para WDAC, mediante la cual el banco calcula un hash para cada uno de los archivos que proceden de un proveedor que no ha firmado sus ejecutables. En otras palabras, usted hace su firma de código para ellos. Obviamente, esto no es tan bueno como el código que se firma en el origen, ya que no se puede detectar cualquier manipulación que se produzca en el tránsito entre el vendedor y el banco (aunque podría haber otros mecanismos para garantizar una transmisión segura).

Un segundo inconveniente con implementarlo de esta manera es que el banco necesita crear una «regla hash» para cada archivo ejecutable. Esto es mucho menos elegante que simplemente instalar el certificado público del proveedor en el ATM que luego cubre todos los ejecutables de ese proveedor, incluidas todas las actualizaciones futuras.

¿Ya llegamos?

Una vez que llegamos a este punto y el ATM está en funcionamiento, todo el software ha sido verificado criptográficamente. Ningún ejecutable que haya sido manipulado o modificado de alguna manera está permitido ejecutarse. Ni siquiera un solo bit de los gigabytes de ejecutables de software en un ATM moderno puede ser hackeado sin ser detectado y bloqueado.

Sin embargo, aún no llegamos al punto. Un ATM protegido de esta manera es a prueba de balas en lo que respecta a la modificación no autorizada de su pila de software. Pero ese no es el final de la historia. Inyectar malware en el ATM no es el único método para atacar un ATM. Ahora veremos cómo el TPM puede ayudar ante otros tipos de ataques.

Comprender lo que pueden hacer los TPM

El TPM no se trata solo de asegurar el proceso de inicio de un ATM. Es la raíz base de la confianza que permite que todo lo demás esté asegurado, también. Pasemos a un fabuloso libro escrito por los miembros de Trusted Computing Group, Will Arthur, David Challener y Kenneth Goldman. El libro, «Una guía práctica de TPM 2.0», es excepcional y un tesoro de ideas que me inspiraron a escribir este documento técnico. El libro se puede descargar gratis aquí.

La mejor manera de resumir este libro rápidamente en este documento es centrarse en los 53 casos de uso enumerados en el libro. Con el permiso de los autores, reproduzco sus casos de uso a continuación:

Revise los casos de uso anteriores. Lo primero que hay que apreciar es que los TPM no se limitan a asegurar el proceso de arranque. Como dijimos anteriormente, el TPM es la raíz base de la confianza que permite asegurar cada paso de lo que debemos hacer con los ATMs, un paso a la vez. Por supuesto, cada caso de uso anterior puede no aplicarse necesariamente a nuestra industria. Y recuerde que estos casos de uso se relacionan con la protección de ese elemento de una manera criptográficamente segura.

Entonces, tomemos un ejemplo ‒ Caso #40 «Claves de VPN». En uso normal, una VPN se configuraría entre un ATM y un servidor mediante la instalación de certificados digitales (es decir, claves públicas firmadas) en los dos sistemas. Pero ¿qué pasa si alguien hackea los certificados? Es cierto que los certificados almacenados en un entorno Windows protegido por TPM con el bloqueo descrito en este documento hasta ahora no serían modificables. Sin embargo, podemos ir un paso más allá. Las claves de VPN se pueden sellar contra PCR mediante el TPM. Esto significa que en el momento en que la VPN está a punto de configurarse, las claves necesarias para configurar la VPN solo pueden estar disponibles si los PCR están en el estado correcto. Cualquier diferencia rechazará la conexión de la VPN. Ahora considere que este concepto puede aplicarse a ambos lados del túnel VPN. No solo los PCR deben estar en el estado correcto en el lado del ATM, sino que también pueden requerirse que estén en estado correcto en el servidor del ATM en el centro de datos. Si esto se hace, habríamos confirmado criptográficamente que tanto el ATM como el servidor del ATM están en un estado seguro antes de conectarse. Sabríamos que todos los ejecutables que se han ejecutado en ambos lados del túnel VPN hasta ese momento son prístinos y no están manipulados, y permitiríamos que los dos se conecten, si y solo si, ese escenario lo cumplen ambos sistemas.

Este documento técnico no es el lugar en el que propongo discutir todas las ideas del libro electrónico. De hecho, hay casos de uso adicionales que se aplican específicamente a los ATM que deben discutirse, diseñarse e implementarse. Espero que la industria de los ATM lo haga a través de uno o más de sus comités. Ahondaremos más sobre eso después.

Protección de conexiones de red

La sección anterior se refería a la seguridad de la red. Ahora lo exploraremos en profundidad, ya que este es un caso de uso que tiene especial importancia para los ATM. Está claro que no solo queremos que los ATM sean seguros individualmente, sino que también requerimos que cualquier sistema de “servidor backend” que toquemos sea seguro y no esté comprometido.  Observe el siguiente diagrama:

 

 

El diagrama muestra el escenario de conexión en un banco típico grande con servicios sofisticados en los ATMs. Los ATMs se conectan a un controlador terminal que orquesta los servicios de varios servidores backend. Un HSM (módulo de seguridad de hardware) proporciona servicios criptográficos y ayuda con la zonificación de pines. Una vez que una transacción ha sido puesta en escena y requiere ser autorizada, se envía al sistema bancario principal si es una transacción «On Us», o a los esquemas de tarjetas si es una transacción «Off Us».

Ahora considere una utopía de seguridad donde cada ATM y cada servidor tiene un TPM (que es el caso de todo el hardware reciente), todos los sistemas se han verificado desde el arranque con mediciones PCR, y todas las conexiones TLS y VPN se han configurado utilizando certificados manejados por el TPM y por lo tanto son criptográficamente garantizados que no han sido manipulados. Una utopía de hecho. La triste situación en agosto de 2020 es que muy pocos bancos han alcanzado este nivel de seguridad.

Un posible desafío de implementación aquí es la escalabilidad y la agrupación en clústeres. ¿Cómo se crea un clúster de servidores si las conexiones están vinculadas a TPM individuales? Vea el caso de uso #47 arriba «Un conjunto de servidores actúa como uno». El TCG ya pensó en eso.

Protección de las conexiones del dispositivo de hardware del ATM

Este documento se ha centrado hasta ahora en el núcleo de PC del ATM y en cómo garantizar que el software esté libre de malware después de la puesta en marcha y durante su funcionamiento. Ahora pasemos a los dispositivos de hardware individuales dentro del ATM como el lector de tarjetas, el Pinpad y, por supuesto, el dispensador de efectivo. ¿Cuál es la situación de seguridad con las conexiones entre el PC-core y los dispositivos individuales? En la mayoría de los ATM, estas conexiones son conexiones USB que pueden ser manipuladas físicamente. Si estas conexiones tienen datos claros, el ATM es vulnerable a ataques, incluso si está libre de malware. Vamos a analizar esto de nuevo con un diagrama: 

 

 

Como puede ver, he dibujado las conexiones USB como una nube para indicar el riesgo de ataque. El TPM asegura el núcleo del PC, pero los cables USB corren el riesgo de ser atacados si no están protegidos. Puede decirse que es responsabilidad del proveedor proteger estas conexiones de hardware del ATM. Sin embargo, la situación no es tan simple, ya que también depende de los requisitos de interoperabilidad entre los dispositivos de hardware y el resto del sistema. Por ejemplo, si los mensajes al CDM (Cash Dispensing Module) están cifrados de extremo a extremo, ¿dónde debería estar ese «otro extremo»? Si el otro extremo termina en el controlador de terminales, por ejemplo, hay que discutir y acordar muchos requisitos de interoperabilidad.

También está claro que incluso el dispensador de efectivo aún no está bien asegurado en muchos ATMs. Tenga en cuenta los diversos «ataques de blackbox» en los informes de los medios. Un ataque de blackbox al ATM ocurre cuando los piratas informáticos interceptan la conexión al CDM y dispensan efectivo usando su propio núcleo de PC. La mayoría de los ATM modernos tienen una conexión cifrada desde el núcleo de PC al CDM, pero KAL sospecha que el diseño de seguridad deja mucho que desear, ya que algunos de estos ATM no cuentan con TPM. Seamos muy claros: Sin TPM = Sin seguridad. Las formas oscuras de cifrar la conexión usando claves protegidas por magia no son seguridad. Es oscuridad y esperanza. Si el proveedor de hardware no puede publicar información sobre cómo se protegen las claves de cifrado, tenga muy claro que esto se debe a que las claves no están protegidas correctamente.

Protección de dispositivos de hardware y XFS4IoT

La buena noticia es que el comité XFS de la industria ATM está analizando cómo debe protegerse la próxima generación de dispositivos ATM. Algunos de ustedes pueden haber oído hablar de la próxima versión de XFS 4.0 que se ha llamado XFS4IoT. La parte de IoT (Internet of Things) demuestra la intención de la especificación de estar lista para el mundo moderno de IoT. Hay varios objetivos principales para XFS4IoT:

1. La especificación es independiente del sistema operativo. Esto significa que los ATM pueden tener Windows, así como Linux o cualquier otro sistema operativo, dentro del ATM.
2. Es amigable con la nube. Los dispositivos ATM pueden exponer los servicios directamente a la nube. Los cerebros de los ATM pueden estar en la nube y no solo dentro del ATM como lo es hoy. Por ejemplo, el lector de tarjetas podría exponer los servicios de lector de tarjetas a la nube. El dispensador de efectivo podría exponer los servicios de dispensación de efectivo a la nube.
3. Los servicios web expuestos de esa manera deben ser seguros. El XFS4IoT tendrá seguridad integrada para garantizar la seguridad de extremo a extremo para los dispositivos. El protocolo de transporte se ha seleccionado como Web Sockets protegidos por TLS con certificados en ambos lados. Además, cada dispositivo de XFS4IoT puede tener un elemento seguro de hardware (HSE, por sus siglas en inglés) para permitir la seguridad de extremo a extremo en la conexión. Esa conexión puede terminar dentro del propio ATM (como es común hoy en día) o puede terminar en un servidor en la nube.

El siguiente diagrama muestra el concepto:

Los ATM con XFS4 se pueden diseñar como el ATM convencional en el lado izquierdo del diagrama donde los dispositivos se conectan a una aplicación de software en el PC-core, o pueden exponer un servicio seguro a la nube como en el lado derecho. En el segundo caso, puede que no haya un PC-core en absoluto dentro del ATM y cada dispositivo puede ser completamente independiente del otro, pero deben estar físicamente cerca y trabajar en conjunto, orquestado por la aplicación en la nube.

Lo más importante a tener en cuenta son las cajas verdes etiquetadas como «HSE». HSE significa «elemento seguro de hardware» y la especificación XFS, por supuesto, las deja abiertas para que los proveedores de hardware determinen la mejor manera de implementarlas. Es obvio que el HSE debe ser un TPM o contener un subconjunto de características de TPM. Como mínimo, el HSE debe ser capaz de:

• Almacenar claves privadas de forma segura.
• Implementar una «raíz base de la medición de confianza» (CRTM) básica para garantizar que solo el firmware seguro puede utilizar el HSE.
• Implementar servicios de cifrado y firma.

KAL ha analizado esto con el comité de TCG y ellos indican que estarían encantados de ayudar a la industria de los ATM a intercambiar ideas sobre las opciones. De hecho, el TCG ya ha hecho algunos progresos con los conceptos de «mini TPM». Uno es el diseño DICE de TCG y el otro es el diseño MARS de TCG. ¿Están DICE y MARS listos para su uso en la industria de los ATM? Tenemos que averiguarlo.

Una idea interesante aquí es si los TPM estándar podrían usarse como el HSE dentro de cada dispositivo. Desde el punto de vista del costo, la respuesta puede ser sí, los TPM cuestan menos de $1 USD en volumen OEM. DICE podría costar aún menos. Para nuestra industria que protege millones de dólares de fondos de consumo, es poco probable que el costo de un TPM u otro tipo de HSE sea un impedimento.

Los ATM tienen una segunda raíz de confianza: el EPP

Hemos analizado la protección de dispositivos en la sección anterior, pero hay un dispositivo único que debemos destacar en el contexto de la seguridad, y es el EPP (pin pad de cifrado). El EPP es, de hecho, una raíz independiente de confianza dentro del ATM. Es altamente seguro, está regulado a través de los requisitos de PCI PED, y la industria administra individualmente cada EPP y lo rastrea a nivel mundial. Tiene su propia medición CRTM de su propio firmware y se autodestruye si se detecta manipulación. De hecho, es muy seguro.

Sin embargo, el EPP ha tenido puntos a favor y en contra en la industria. Dado que el EPP proporciona un cierto nivel de seguridad para los ATM (evaluaremos sus limitaciones en un momento), los bancos han confiado en él para asegurar las transacciones de los ATM. El EPP almacena la clave maestra del banco de forma segura, y el uso de una cadena de claves asegura que el bloque de pines es seguro y los mensajes de comunicación entre el ATM y el host están cifrados y cuentan con MAC. Esto es una buena seguridad. Sin embargo, no es suficiente seguridad.

El EPP no está disponible cuando se inicia el ATM y permanece no disponible hasta que haya arrancado Windows y se hayan iniciado los SPs XFS (los controladores de hardware del ATM). Esto significa que el EPP no tiene nada que decir sobre la validez del software dentro del ATM. Si una aplicación del ATM infectada por malware desea aceptar un pin o autenticar un mensaje (MAC) para el host del ATM, el EPP cumplirá sus órdenes. El perímetro de protección del EPP es demasiado pequeño para ayudar a asegurar la totalidad del ATM. Es una joya de seguridad en una gran cantidad de software potencialmente desprotegido donde no hay TPM.

¿Cómo se actualiza el software cuando está protegido por un TPM?

Tal vez el lector piensa en este punto que, si es imposible cambiar cualquier software dentro de un ATM protegido por un TPM, será difícil realizar actualizaciones de software válidas. Recuerde que el software de la aplicación está protegido mediante una regla de certificado. Está firmado por el desarrollador de la aplicación (que podría ser el propio banco o el proveedor de confianza del banco). Todo lo que se necesita es que el software actualizado se firme con la clave privada segura de la organización de desarrollo de software, y el ATM aceptará el cambio. Es así de sencillo.

Los cambios en el software central medidos por los PCR necesitan un paso adicional. El software principal se puede actualizar completamente de forma remota sin la visita de un técnico, pero requiere que se cree una clave temporal durante el proceso de instalación que esté sellada contra los PCR sin cambios. Una vez completada la instalación, las nuevas claves se sellan contra el conjunto completo de PCR. Fácil.

Recuerde nuestro ejemplo anterior sobre “Windows Hello”, una buena seguridad no necesita ser difícil de usar. De hecho, la seguridad de clase mundial, que es lo que la protección TPM proporciona a los bancos, es más fácil de usar, además de ser criptográficamente segura en comparación con los métodos tradicionales.

Defensa contra los ataques físicos

Aunque no lo hemos dicho específicamente antes, gran parte de la discusión anterior se refiere a proteger el ATM de ataques físicos y de software. Un método de ataque común en los ATMs es quitar la unidad de disco duro, modificar el software y restaurar los cambios en ese ATM, así como en otros ATMs. Ese método de ataque no es posible si la unidad está cifrada y la cadena de arranque está protegida por el TPM.

Otro tipo de ataque es intentar «forzar brutalmente» el TPM y probar varias claves en rápida sucesión. El TPM tiene una protección incorporada contra ataques de repetición anti-hammering que lo bloquea en ese caso.

Por último, hay otros tipos de ataques extremos que podrían implicar interferencias directas con la electrónica de la placa base. Tales ataques serían costosos de llevar a cabo, ya que requiere equipo especializado y no han ocurrido hasta ahora, no que nosotros sepamos. Sin embargo, existen formas de protección de bajo costo contra tales ataques, como el uso de resina para proteger las conexiones electrónicas expuestas en la placa base.

Cuidado con las soluciones mágicas

Asegurar ATMs y PCs con TPM como raíz de confianza es la única forma conocida y publicada de proteger completamente los sistemas informáticos. Nuestra industria debería preguntarse por qué la seguridad basada en TPM no es más común en las redes ATM. Por supuesto, diferentes empresas querrán competir en el mercado y querrán posicionar sus productos de seguridad. Eso es de esperar. Pero es muy importante que los bancos no caigan en soluciones ilusorias. Aquí hay una lista de cosas para tener en cuenta:

Mito: «No se necesita un elemento seguro de hardware»

Sea muy claro que es imposible almacenar claves privadas en el disco/SSD de un ATM de forma segura. La razón es que por más larga que sea la cadena de claves, tiene que haber una clave clara inicial. Si esa clave está «oculta» en la unidad, siempre se puede recuperar. Algunas soluciones afirman generar la clave en la puesta en marcha. Pero recuerde que se necesita un código claro para generar esa clave. Tiene que estar claro, ya que aún no hemos descifrado la unidad. Si está claro, puede ser muy simple revertir el diseño desde el código ejecutable, que estará en claro antes de descifrar la unidad.

Piense en esto de otra manera. Si fuera posible mantener las claves de forma segura en un ATM utilizando técnicas de software solamente, nuestra industria no se habría tomado la molestia de construir los EPPs…

Mito: «No se requiere ningún elemento seguro de hardware, ya que las claves se almacenan en la red»

Si el ATM no es lo suficientemente seguro como para mantener las claves de forma segura porque no hay TPM, no es posible resolver ese problema moviendo las claves a una ubicación de red. He aquí el motivo: cuando el ATM se inicia, necesita acceder a la red para obtener la clave segura. Entonces no tiene una forma criptográficamente segura de autenticarse en la red porque no tiene almacén de claves. Eso significa que el servidor de red no sabe «quién está pidiendo la clave». Por ejemplo, cuando Bitlocker almacena claves en la red, necesita un TPM para autenticarse en la red. Sin TPM = Sin seguridad.

Mito: «No hay necesidad de claves de cifrado»

El proveedor afirma que el almacenamiento de claves es innecesario porque tienen una tecnología mágica que permite que el cifrado ocurra sin claves. Bueno, eso sería demasiado bueno para ser verdad. ¿Por qué el mundo ha luchado siempre con las técnicas de administración de claves cuando no necesita claves? Todas las técnicas de cifrado conocidas como 3DES, AES y RSA requieren claves privadas. Las claves privadas se llaman así, ya que deben almacenarse de forma segura. Lo que hace que un sistema de encriptación sea seguro es que las claves se eligen entre un gran número de posibilidades. Por ejemplo, 3DES tiene al menos 2¹¹² claves. Tomaría 30 años probar todas las claves si se intentaran a un ritmo de 5000 millones por segundo. Con AES tardaría 10²² años al mismo ritmo.

Mito: «Nuestro algoritmo es confidencial»

La seguridad real se basa en estándares y algoritmos abiertos junto con claves confidenciales. El único aspecto de un sistema de seguridad que debe ser confidencial son las claves. Si las claves se ven comprometidas, las cambias y el sistema estará seguro de nuevo.

Mito: «Las listas de control de acceso (ACL) nos mantienen seguros»

Las listas de control de acceso se pueden burlar fácilmente cuando no hay bloqueos de TPM. Hay otras desventajas de las ACL que no discutiremos aquí, pero lo que es seguro es que las ACL no son protección suficiente para los ATMs.

Conclusiones

Espero que el lector haya llegado a una apreciación de por qué el TPM es fundamental para la seguridad informática y, por lo tanto, fundamental para la seguridad de los ATMs. Espero que también haya quedado claro que la mayoría de los bancos todavía tienen un largo camino por recorrer para asegurar su red de una manera criptográficamente garantizada. También es importante señalar que cualquier sistema de seguridad de este tipo debe diseñarse teniendo en cuenta la interoperabilidad. Dado que varios proveedores y múltiples soluciones de productos son una parte estándar del panorama moderno de la tecnología del ATM, no sería posible que cada proveedor implementara bloqueos de forma independiente. Eso crearía un ATM que es inutilizable.

Espero que este documento sea el comienzo de un proceso que permita desarrollar especificaciones de seguridad interoperables utilizando las bases criptográficas que tenemos disponibles desde los TPM. Trusted Computing Group nos ha ofrecido su ayuda. Ahora depende de los diversos comités de nuestra industria (XFS4IoT, ATMIA y EAST), junto con bancos y proveedores, diseñar el camino a seguir.

Mis agradecimientos

• Michael Moltke (NCC Group Dinamarca)
• Kit Patterson (KAL)
• Will Arthur, David Challener y Kenneth Goldman por escribir el libro electrónico sobre TPM, y David Challener por organizar el apoyo del TCG

Póngase en contacto con KAL hoy mediante Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.