¿Cuál es la implicación energética de cifrar el tráfico de mi sensor?

Teniendo en cuenta un tipo típico de aplicación, un sensor alimentado por batería que toma lecturas (valor de 32 bits) cada 10 minutos, ¿cuál es el impacto probable en la vida de la batería si elijo un protocolo en el aire simple no encriptado, en comparación con una transmisión encriptada?

Suponga que mis datos no son particularmente secretos, pero de acuerdo con esta pregunta , probablemente deba considerar encriptarlos, siempre que no haya realmente un costo de diseño significativo.

Para simplificar, supongamos que estoy usando un SoC nRF51822 que admite una pila BLE y un protocolo más simple de 2.4 GHz también.

Como estoy pensando en una aplicación de producto comercial en lugar de una instalación única, el cifrado debe ser intensivo en cómputo para interrumpir (digamos al menos $ 500 de cómputo en la nube de 2016), en lugar de una simple ofuscación. Algo que permanece seguro incluso con acceso al firmware del dispositivo.

La mayor parte de su potencia probablemente se gastará en la transmisión de RF, no en los ciclos de CPU dedicados a las rutinas de cifrado. Cada bit adicional transmitido le costará más potencia que el cifrado que está proponiendo. Eso significa que si adopta un enfoque ingenuo, como usar AES en modo CBC, corre el riesgo de aumentar el tamaño del mensaje para transportar los bits adicionales en cada bloque.

Si determina que su empresa necesita que los datos se cifren, considere usar AES en modo CTR para generar bits de cifrado de flujo. El modo de contador es práctico para tratar casos en los que la recepción puede ser poco confiable y los paquetes pueden perderse. Tendrá que mantener los contadores sincronizados, así que tenga en cuenta que la transmisión periódica del valor del contador aumentará la sobrecarga. Y tendrá que reservar unos pocos bytes de estado para mantener el contador, porque la reutilización de una secuencia de bits cifrada puede conducir directamente a la recuperación de datos.

Hay una variedad de métodos de encriptación que podría usar para proteger su tráfico, y cada uno tiene un uso de energía ligeramente diferente, por lo que voy a elegir un par de opciones populares. La metodología que uso para evaluar cada método debe ser aplicable a cualquier otro cifrado que encuentre y desee comparar.

AES

AES es uno de los algoritmos de cifrado de clave simétrica más populares (lo que significa que usa la misma clave para cifrar y descifrar). En términos de seguridad, AES es una apuesta segura:

El mejor criptoanálisis público

Se han publicado ataques que son computacionalmente más rápidos que un ataque de fuerza bruta completa, aunque ninguno a partir de 2013 es computacionalmente factible.

- Wikipedia

El criptoanálisis Biclique en papel del AES completo describe que AES-128 requiere 2 ^126.1 operaciones, AES-192 requiere 2 ^189.7 operaciones y AES-256 requiere 2 ^254.4 operaciones para romper. En un procesador de 2.9 GHz, suponiendo que cada 'operación' sea 1 ciclo de CPU (probablemente no sea cierto), romper el AES-128 llevaría mucho tiempo . Con 10 000 de ellos funcionando, todavía tomará casi una eternidad . Entonces, la seguridad no es una preocupación aquí; Consideremos el aspecto del poder.

Este documento muestra (en la página 15) que encriptar un bloque con AES utilizó 351 pJ. Compararé esto un poco más tarde después de hablar sobre algunos otros algoritmos comunes.

SIMÓN

Hice una pregunta sobre SIMON y SPECK anteriormente, que vale la pena leer. Donde SIMON sobresale es en situaciones en las que necesita cifrar un poco de datos, con frecuencia . El documento que vinculé anteriormente afirma que SIMON 64/96 usa 213 pJ para 64 bits, lo cual es práctico cuando solo necesita enviar 32 bits de carga útil.

Sin embargo, SIMON 64/96 es significativamente más fácil de romper que AES; el documento que vinculé sugiere una operación de 2 ^63.9 , por lo que nuestra configuración de 10 000 CPU podría descifrar el cifrado en solo unos pocos años , a diferencia de millones de milenios.

¿Realmente importa?

Al ritmo que planea transmitir, la respuesta es casi seguro que no ; El uso de energía de la criptografía será completamente insignificante. Para AES, usaría 50 544 pJ por día , por lo que una batería AA barata de carbono-zinc con 2340 J de energía duraría mucho más que la vida útil del dispositivo . Si reevalúa los cálculos con SIMON, encontrará que también tiene una vida útil muy larga.

En resumen, a menos que esté transmitiendo con mucha frecuencia, la radio es mucho más preocupante por el poder . Wikipedia cita el uso de energía entre 0.01 y 0.5 W. Si transmite durante 1 segundo a 0.01 W , ya ha usado más energía que AES durante todo el día .

Sin embargo, para BLE, probablemente estés bien solo confiando en la seguridad predeterminada; BLE usa AES-CCM de forma predeterminada para la seguridad de la capa de enlace :

El cifrado en Bluetooth con baja energía utiliza la criptografía AES-CCM. Al igual que BR / EDR, el controlador LE realizará la función de cifrado. Esta función genera datos cifrados de 128 bits a partir de una clave de 128 bits y datos de texto sin formato de 128 bits utilizando el cifrado de bloque AES-128 bits como se define en FIPS-1971.

Sin embargo, existe cierta preocupación de que haya fallas de seguridad con la implementación de BLE de la seguridad de la capa de enlace; esto no es un defecto en AES; más bien Bluetooth SIG decidió implementar su propio mecanismo de intercambio de claves en 4.0 y 4.1 . El problema ahora se resuelve en 4.2 ya que ahora se admite la curva elíptica Hellman-Diffie.

A menos que esté haciendo una criptografía acelerada por hardware, es probable que el costo de energía sea alto a medida que obtiene un procesador que está esencialmente dominado para las necesidades básicas (no criptográficas). Sin embargo, en la mayoría de los casos, el uso de la radio es el que consume más energía de todos modos.

Dado que está buscando específicamente un SOC bluetooth, considere el BGM-111 , que tiene un cifrado acelerado por hardware en el chip. He jugado con este chip y parece bueno, aunque no he mirado específicamente las funciones de cifrado.

Otra ruta, y posiblemente la 'mejor' ruta si desea asegurarse de que nadie pueda obtener sus llaves, incluso si desmontan el dispositivo. Para incluir un chip TPM, como el OPTIGA TPM , que tiene chips I2C y SPI TPM que son compatibles con los núcleos de Linux.

En resumen, quemará las baterías sin un cifrado de hardware específico. Construya una placa con un chip TPM o elija un SoC más moderno que ya tenga un hardware de cifrado incorporado.