Seguridad criptográfica en IoT (V)

lunes, 6 de junio de 2016

La proliferación de dispositivos y plataformas de servicios IoT está siendo mucho más rápida que la adopción de medidas de seguridad en su ámbito. Ante la apremiante necesidad de mecanismos que garanticen la autenticación, integridad y confidencialidad, tanto de las comunicaciones como de los propios dispositivos, se tiende a trasladar las soluciones criptográficas contrastadas en la IT tradicional, como son los certificados digitales de clave pública sobre protocolos SSL/TLS. Seguimos avanzando en el estado del arte de las soluciones criptográficas para IoT.

Cálculo de HMAC

La ejecución del comando HMAC, al igual que ocurre con otros comandos del ATSHA204A, debe ir precedida de la ejecución del comando Nonce.

El objetivo del comando Nonce es poblar el registro interno de 32 bytes llamado TempKey, generando o cargando un desafío (challenge), que será utilizado en posteriores comandos.

El comando Nonce tiene tres modos de operación. Los modos 0x00 y 0x01 son los más comunes. En estos modos se invoca el comando Nonce proporcionándole un número de 20 bytes como entrada, al cual responderá devolviendo un número aleatorio de 32 bytes internamente generado a modo de desafío (challenge).

A este número aleatorio de 32 bytes se le concatenan los 20 bytes recibidos, junto a tres bytes más: 0x16, el modo y 0x00. Y sobre el conjunto de 55 bytes se calcula el resumen SHA-256 que es almacenado en la TempKey.

Adicionalmente se modifican dos registros binarios:
  • TempKey.SourceFlag a valor 0, significado origen aleatorio.
  • TempKey.Valid, a valor 1, significando que la TempKey es utilizable.
La diferencia entre el modo 0x00 y 0x01, es que el segundo caso no se actualiza la semilla del generador de números aleatorios, algo que Atmel no recomienda.

En modo 0x03 es utilizado para poblar la TempKey directamente, sin la generación del número aleatorio, ni calculo del SHA-256, a modo de bypass.



Si el comando Nonce ha finalizado de forma satisfactoria, estableciéndose el bit TempKey.Valid a valor 1, es posible a continuación invocar el comando HMAC.

La llamada al comando HMAC se realiza proporcionado únicamente como parámetros de entrada su modo de operación, y el número del slot que contiene la clave a utilizar en el cálculo HMAC. La respuesta a este comando será el número de 32 bytes resultante del computo HMAC-256 sobre un total de 88 bytes formados por:
  • Conjunto de 32 bytes de valor 0x00.
  • Contenido de 32 bytes de la TempKey.
  • Base de 24 bytes determinada por el modo de operación.

El comando HMAC presenta múltiples modos de operación, los cuales determinaran que contenido de la zona OPT y del número de serie (SN) del dispositivo se incorporaran a la base. Puede no incorporarse ninguno de estos elementos, estableciéndose los últimos 20 bytes de la base a 0x00.

La base del cálculo HMAC comenzará siempre por el byte 0x11, seguido del byte de modo, y dos bytes más que indican el slot que ocupa la clave con la que se realizará el computo HMAC-SHA-256.


El tercer bit menos significativo del byte de modo, debe coincidir con el valor del TempKey.SourceFlag establecido anteriormente por el comando Nonce.




En todas las comunicaciones con el dispositivo ATSHA204A, tanto entrantes como salientes, se agregan dos bytes de control de redundancia cíclica CRC para garantizar la integridad, tanto de la invocación del comando como de su respuesta.

En la próxima entrega, a modo de simple prueba de concepto (PoC) implementaremos el caso de uso práctico de un dispositivo IoT que debe autenticarse ante un servicio web de forma robusta, utilizando hardware criptográfico.

Seguridad criptográfica en IoT (I)
Seguridad criptográfica en IoT (II)
Seguridad criptográfica en IoT (III)
Seguridad criptográfica en IoT (IV)
Seguridad criptográfica en IoT (V)
* Seguridad criptográfica en IoT (VI)


Jorge Rivera
jorge.rivera@11paths.com

No hay comentarios:

Publicar un comentario en la entrada