Fuente: disk91.com
“El ataque habitual contra la red Sigfox está relacionado con la “seguridad”. Detrás de este gran concepto, de verdad, el único punto está relacionado con el uso de un payload en el aire. Como consecuencia, algunos están extendiendo esto a la posible repetición después de 2048 cuadros con lo que el uso estándar de Sigfox será aproximadamente 6 meses más tarde …
Dicho esto, de verdad, todo esto es simplemente la ignorancia de estos expertos en pseudo “seguridad” y la pereza del desarrollador. No se molesten conmigo por decirlo, formo parte de esos “desarrolladores perezosos”: la única diferencia es que no me estoy quejando y soy consciente de que la solución está en mis propias manos.
Y es que es verdad: el encriptado el payload existe tal como se documentó en la publicación de mayo de 2017 y como detallé en el documento de seguridad técnica de febrero de 2017 publicado por Sigfox en este documento.
Por lo tanto, decir que Sigfox no está proponiendo
el encriptado del payload es incorrecto. Y esta opción también corrige los 6 meses posteriores a la reproducción del mensaje. ¡Es como decir que WiFi no es seguro porque puedes crear una red abierta!
Así que ahora, veamos por qué el encriptado no es la opción predeterminada, por qué un encriptado estándar de red no es la mejor opción y luego ver cómo dejar de ser un desarrollador perezoso y hacer que el encriptado funcione.
°°°
¿Por qué no se ha elegido el encriptado predeterminado?
El encriptado para el IoT no es realmente un encriptado para navegar en la web. Me refiero a que la información personal transferida a través del protocolo IoT no es exactamente la misma que en Internet cuando estamos considerando LPWA.
Estas son las razones:
° La identificación del dispositivo es un tipo de número aleatorio y no se puede usar para encontrar su identidad personal como una dirección IP. Básicamente, si no lo publicas, no hay razón para identificarte.
°Incluso Sigfox puede ubicar un dispositivo solo con una precisión de 1 km. Esto hace una gran posibilidad antes de encontrarte.
° Debido a que la mayoría de los datos que transmite a través de Sigfox no son confidenciales … como la temperatura de mi oficina no es realmente un tema sensible …
Al considerar los dispositivos personales conectados a través de BLE, honestamente tendría un discurso totalmente diferente.
Dicho esto, significa que hay una gran área donde los datos pueden considerarse confidenciales y por eso el encriptado del payload es una característica necesaria: nunca lo diré de manera diferente. “Necesitar” simplemente no significa “debe tener”.
Por lo tanto, suponiendo que la mayoría de los dispositivos no sean sensibles, con respecto al objetivo objetivo de ahorrar energía, utilizar un MCU de bajo costo para obtener lo mejor de la tecnología LPWA, la configuración predeterminada se ha decidido como transporte de payload clara. Entonces usted decide encriptar o no por su cuenta.
¿Por qué el cifrado estándar no es el mejor enfoque?
Además de lo que hemos visto anteriormente, agregaría los siguientes elementos a tener en cuenta: consideremos que los objetos estarán en los campos durante 5 a 10 años. En los campos, estos objetos no tienen posibilidad de actualizarse con un nuevo firmware. ¿Qué pasará cuando se rompa el encriptado seleccionado para todos? Esto se convertirá en otro historial de WiFi WEP … algo que se rompió hace 10 años y aún está en producción en muchas áreas. Así que mi sensación es: “nunca confíe en el encriptado estándar / global para la seguridad a largo plazo”.
No digo que la solución de Sigfox no esté asegurada o que no se use, digo que si no quiere ser parte de una posible brecha de seguridad global en el futuro, es mejor pensar en implementar su propio encriptado. ¿Por qué no múltiples? Empleando múltiples podrías cambiarlo de forma remota. No hay pues límite en el desarrollo de la seguridad. La seguridad, la protección de datos es un compromiso que usted decide con respecto a la sensibilidad de los datos, el tiempo que tiene y la energía que tiene y la cual tiene interés en su contra.
Básicamente, esto es algo que puede leer en el foro de LoRaWan: si el encriptado es el valor predeterminado para las comunicaciones, los expertos recomiendan implementar su propio método de encriptado subyacente.
Ventaja del encriptado: potencialmente pueden ser acumulativas.
Algunos desafíos del encriptado del payload
En la red IoT, usar el encriptado con el intercambio de claves basado en la clave pública / privada no es algo que pueda imaginar. La potencia de cálculo que tiene en MCU es realmente ligera y las comunicaciones bidireccionales de la red son un problema real debido al ciclo de trabajo y a la confiabilidad de la comunicación, especialmente en el enlace descendente (cualquiera que sea la tecnología). Como consecuencia, por lo general, el dispositivo y el lado del servidor comparten una clave secreta. Esta clave se utiliza para encriptar los mensajes.
Para proteger su comunicación, debe asegurarse de que un mismo mensaje no se encriptará de la misma manera en todas las comunicaciones; de lo contrario, el descifrado será sencillo, ya que la determinación de la clave será mucho más simple.
Por otro lado, ya que puede perder muchos mensajes, necesita tener un mecanismo de sincronización para administrarlo. Este mecanismo de sincronización comienza a ser complejo si no puede determinar si el marco recibido y descifrado es válido o no. ¡La sincronización se puede perder y puede tener problemas! Esto se puede gestionar con algunos bits adicionales que puede o no puede tener.
También puede usar la misma clave en todas las transmisiones (por lo que el mismo payload transparente proporcionará el mismo payload encriptado) o realizar una acción similar con un elemento cambiante como la identificación de secuencia. Este enfoque está resolviendo el punto de desincronización visto anteriormente, pero reducirá los aspectos de seguridad y permitirá la reproducción posterior. Por lo tanto, esto debe implementarse con un procedimiento de cambio clave que ejecute de manera regular. Aquí está la complejidad de gestionar, ya que garantizar que una comunicación se haya enviado y recibido en ambos lados es muy complejo. (Puede ver mi publicación del Sigfox downlink aquí).
Como ejemplo, LoRaWan está implementando un intercambio de claves durante la fase de conexión para las comunicaciones posteriores. Para mantenerlo seguro, esta clave debe renovarse con desconexiones / reconexiones regulares, con el riesgo de no poder volver a conectarse en una situación en la que pudo alcanzar la red (enlace ascendente) pero no recibir comunicaciones de ella (enlace descendente). Esto se debe a que en LPWAn, el área de envío es mayor que el área de recepción.
Además de estas consideraciones, también debe comprender que el encriptado está mezclando los bits, por lo que, dependiendo del protocolo seleccionado, necesita un tamaño de payload específico para aplicar el algoritmo. Sigfox es un protocolo de tamaño de trama de 1 bit a 96 bits. La forma en que el algoritmo sea encriptado debe ser compatible, de lo contrario no funcionará: como mover bits fuera del tamaño del marco.
¿Cómo funciona el servicio de encriptación sigfox?
Entonces, ya que ahora entendemos el desafío del encriptado, consideremos lo que Sigfox propone como un protocolo estándar.
En primer lugar, el encritpado se realiza desde el dispositivo a la red kernel de Sigfox. Es decir: al nivel de radio. El payload se descifra antes de almacenarse en el backend. Así que este encriptado es transparente para su aplicación (lo que no importa). Esto es bueno para la protección de la radio pero deja sus datos visibles desde el backend y su aplicación.
Si no desea que Sigfox vea sus datos, necesita implementar su propia solución de encriptación o usar la estándar con una clave que Sigfox no sabrá, por lo que aplicará el descifrado en el lado del servidor. Dicho esto, también deberá implementar el mecanismo de sincronización como se explicó anteriormente.
Para encriptar las comunicaciones, el dispositivo utilizará una clave previamente compartida. Este puede derivarse simplemente de la clave privada que cualquier dispositivo Sigfox utiliza para HMAC (la clave NAK) o una personalizada almacenada en la memoria del dispositivo o almacenada en un elemento seguro. Depende del tipo de ataques físicos contra los que quiera protegerse. Una vez que esta clave compartida exista y se conozca por ambos lados, esta clave se utilizará con un valor de “contador” específico. El valor del “contador” se cifrará con el estándar AES128 gracias a la clave compartida. Esto generará un nuevo valor de 128b que no puede predecir hasta que conozca la clave compartida y el valor de “contador”. El valor del “contador” contiene diferentes valores estáticos y específicos del dispositivo y un contador secuencial.
El valor dado se usará como una máscara para una función XOR simple para mezclar el payload. Este XOR cambiará algunos de los bits de carga útil. Este enfoque permite mezclar la carga útil independientemente de su tamaño. De esta manera, incluso con 128b AES puede proceder a 96 bits (o menos) del marco. Este enfoque no mezcla / gira los bits en el marco.
Esto se describe en las documentaciones con el siguiente esquema:
Como puede ver, necesitamos dos datos para compartir: la clave (Ke) y el CTR (anteriormente identificado como “contador”). CTR se modifica en cada fotograma. En caso de pérdida de trama, el receptor puede volver a sincronizar fácilmente el CTR con el número de secuencia, pero el número de secuencia y el CTR pueden ser diferentes y tener un módulo diferente para evitar cualquier repetición de trama en cualquier momento. Para esto, Sigfox usa el ID de secuencia de 12 bits y agrega bits adicionales. Nombraré estos 8 bits adicionales como CycleID. El CycleID puede incrementar cada vez que la ID de secuencia se desborda. El siguiente procedimiento se utiliza para crear el CTR de Sigfox:
1 – Consideremos V1 y V2 (16 bytes cada uno) hechos al obtener el ID de dispositivo y desplazarlo 1 bit a la derecha. Agregue un bit 1 (para V1) y un bit 0 (para V2) por adelantado. La representación de la ID del dispositivo es LittleEndian (00112233) producirá 1 | 33 22 11 00…
2 – Transforme V1 y V2 en W y Ke gracias a la transformación AES128-ECB utilizando la KEY interna del dispositivo (NAK). Ke será la clave utilizada para cifrar el CTR con AES.
3 – Cree el vector CTR con los siguientes elementos: tome los primeros bytes de W y agregue para el último cuarteto 5 el ID de ciclo y la ID de secuencia.
4 – Luego, el vector CTR se encripta con AES-ECB usando la tecla Ke.
5 – Este resultado se utiliza para mezclar la carga útil con la función XOR. El resultado previamente calculado: Carga cifrada = PlainTextPayload XORD AES (CTR, Ke)
5 – Calcula el HMAC del marco con el siguiente vector
El tamaño del vector varía dependiendo del tamaño del payload. Puede tener 16 o 32 bytes de largo. La diferencia con un marco no encriptado es el uso del byte CycleID en la secuencia. Un marco no encriptado no tendrá este byte presente. Como consecuencia, en el caso de la desincronización de CycleID entre el dispositivo y el backend de Sigfox, el HMAC no será válido y el marco será rechazado. El marco enviado no encriptado también será rechazado. No hay riesgo de tener un descifrado inválido.
En la biblioteca de Sigfox, el valor de CycleID se vuelve a sincronizar gracias a un mensaje OOB enviado regularmente.
Esta implementación de Sigfox es similar al protocolo de cifrado LoRaWAN. La principal diferencia es que LoRaWan está negociando un nuevo Ke durante la fase de conexión. Sigfox está utilizando una clave derivada de la clave interna utilizada para la autenticación HMAC. En LoRaWan, el CTR se crea a partir de algunos elementos estáticos, el ID del dispositivo y el equivalente del ID de secuencia (sin módulo)
¿Cómo empezar a usar el encriptado sigfox?
Entonces, básicamente, el problema del encriptado de la comunicación en Sigfox no se debe a la red o al protocolo. Es debido a las implementaciones. Dicho esto, la verdad es que si desea implementar el encriptado, tendrá que administrarlo por su cuenta. En realidad, ninguno de los módems Sigfox que utilizo habitualmente está implementando o documentando cómo usar el modo encriptado. Telecom Design TD120X, Wisol Sfm10, ATA8520 (Mkrfox1200), ninguno de ellos propone una forma de activar el payload encriptado.
Así que tenemos que ir a un nivel bajo para implementarlo: usar directamente la biblioteca de Sigfox. Esto se puede hacer con el kit de desarrollo STM32 + S2LP. La siguiente imagen muestra la arquitectura:
Puede ver en esta imagen la integración del encriptado de seguridad entre la biblioteca de Sigfox y la solución general. La biblioteca requiere una implementación de AES y posiblemente utilice un elemento seguro para almacenar las claves secretas.
Para utilizar el encriptado, debe tener un dispositivo con una certificación de encriptado de payload. Honestamente, no entiendo por qué la mayoría del módem no implementa el encriptado, al menos como una opción … como consecuencia, si desea utilizar el encriptado, es un poco complicado encontrar una plataforma que lo soporte. Básicamente, cualquier plataforma en la que se ejemplifique directamente la biblioteca de Sigfox como STM2 / S2LP o Murata STM32 / Semtech funcionará perfectamente. Luego, debe solicitar al soporte de Sigfox el cifrado activado en el dispositivo. Esto es posible si el CRA (Certificado de dispositivo) se valida para el cifrado; STM32 / S2LP puede ser pronto.
Una vez hecho esto puedes transmitir la carga útil encriptada. Para hacerlo más sencillo, puede acceder al código fuente de mi ejemplo de demostración en GitHub. Se basa en el Disk91 IoT SDK, básicamente solo necesita modificar el archivo configSigfox.h para agregar el indicador __SIGFOX_ENCRYPT_SIGFOX en la configuración ITSDK_SIGFOX_ENCRYPTION y los marcos enviados se cifrarán.
¡No hay más que hacer! Así que es fácil, ¿no es así?
La ventaja del encriptado Sigfox es tener una solución perfecta. La sincronización se gestiona por sí sola y, en caso de desincronización, la trama se elimina y no tendrá riesgo de recibir un payload no válido. La desventaja es la falta de implementación en el módem habitual. Por este motivo, es posible que desee implementar su propia solución de encriptado.
¿Cómo puedo hacer mi propia solución de cifrado?
Existen diferentes formas de cifrar su payload, la que se vio anteriormente, utilizada por Sigfox y LoRaWan, son las más fáciles de usar: funciona con cualquier tamaño de payload. El encriptado final es solo un cambio de bit “impredecible” sin codificación de bits. No es un encriptado AES sino un encriptado CTR que utiliza AES128 para generar el encriptado de encriptado de bloque.
La ventaja: 2 cuadros idénticos enviados consecutivamente tendrán 2 cuadros diferentes.
Puede implementarlo fácilmente por sí mismo: genera el elemento Ke como un secreto compartido entre su dispositivo y el servidor. Asegúrese de tener uno específico por dispositivo y de mantenerlo en secreto. Cree su CTR basado en el Id. De secuencia + lo que desee estático o derivado del id del dispositivo. No hay nada complejo aquí, todo es estático, solo necesita tener una ID de secuencia sin módulo.
También puede mirar un encriptado que permita codificar bits en un bloque de datos (como AES). En este caso, debe tener una solución de encriptado que administre el tamaño de bloque compatible con los datos que desea intercambiar. Como ejemplo, AES128 trabaja con bloques de 128 bits. El tamaño máximo del payload para el payload de Sigfox es de 96 bits. Así que esto no está funcionando. Como el tamaño del marco para Sigfox es 4bytes, 8bytes, 12bytes, necesita usar el algoritmo de encriptado que trabaje en bloques de 32bits (4bytes).
Un algoritmo como Speck se puede usar en diferentes tamaños de palabra de 32b a 128b. Es un posible buen candidato para un encriptado de payload Sigfox. Una implementación se puede encontrar en este repositorio de Github. El tamaño de la clave para los bloques de 32b es 64b, el tamaño de un enlace descendente de Sigfox. Los otros parámetros importantes a tener en cuenta son el tamaño del código, la RAM necesaria y el Tiempo de encriptado (correspondiente a un consumo de energía asociado). Como ejemplo para Speck, se puede encontrar cierta información en Internet. El tamaño del código es de aproximadamente 0.5KB, la RAM necesaria es de unos 60B. El tiempo de procesamiento es 3s en un AVR según alguna publicación. Puede ver que el encriptado no es realmente una cuestión de costo de software, sino que puede ser una cuestión de costo de energía, principalmente cuando tiene una MCU de baja velocidad. La elección de Speck es controvertida porque esta solución vino de la NSA. Desde mi punto de vista, si no quiere protegerse contra el gobierno de los Estados Unidos, tiene muchas ventajas.
Con este enfoque dos cuadros idénticos darán un resultado idéntico. Por eso se recomienda cambiar la clave regularmente. Como ya se explicó la principal complejidad llega a ese punto. Pero todavía es algo factible con un poco de trabajo.
El uso de SPECK32 + AES128-CTR también es posible, como puede ver en el ejemplo de ejecución completo accesible en mi repositorio de demostración de encriptación de Sigfox en GitHub.
Ir más lejos
El método de encriptado AES-ECB (CTR) está haciendo un buen trabajo, pero desde mi punto de vista, tan pronto como se conoce una parte del texto sin formato, suena a riesgo. Cuando creas un protocolo de comunicación, normalmente tienes un encabezado para un marco común y estos encabezados son valores estáticos que sabes. Esto está reduciendo, cuadro tras cuadro los posibles candidatos clave. En realidad, no sé cuál es el riesgo relacionado, pero debe ser considerado. Esto es válido para todos los métodos basados en AES vistos anteriormente, como para Sigfox y LoRaWan.
Mirar el enfoque de AES-OFB como Pascal L. (gracias, Pascal) me propuso podría ser una mejora compatible con el contexto de IoT / LPWAn. En este enfoque se añade un vector IV. Este IV se calcula a partir del AES anterior (Ke, CTR). Como es independiente de los datos transmitidos anteriormente, se puede calcular en la red del kernel (o en el backend) incluso si se pierden algunos marcos durante la comunicación. Más adelante intentaré una implementación 😉 ”
