Quelle est la puissance impliquée du chiffrement du trafic de mes capteurs?

Compte tenu d'un type d'application typique, un capteur alimenté par batterie prenant des mesures (valeur 32 bits) toutes les 10 minutes, quel est l'impact probable sur la durée de vie de la batterie si je choisis un simple protocole en direct non crypté, par rapport à une transmission cryptée?

Supposons que mes données ne soient pas particulièrement secrètes, mais selon cette question, je dois probablement envisager de les chiffrer, tant qu'il n'y a pas réellement de coût de conception important.

Par souci de simplicité, supposons que j'utilise un SoC nRF51822 qui prend également en charge une pile BLE et un protocole 2,4 GHz plus simple.

Étant donné que je pense à une application commerciale plutôt qu'à une installation unique, le chiffrement doit être intensif en calcul pour se casser (disons au moins 500 $ de calcul en nuage de 2016), plutôt que d'un simple brouillage. Quelque chose qui reste sécurisé même avec l'accès au firmware de l'appareil.

La majeure partie de votre énergie sera probablement dépensée pour la transmission RF, et non pour les cycles CPU dépensés dans les routines de chiffrement. Chaque bit supplémentaire transmis vous coûtera plus d'énergie que le cryptage que vous proposez. Cela signifie que si vous adoptez une approche naïve, comme l'utilisation d'AES en mode CBC, vous risquez d'augmenter la taille du message pour transporter les bits supplémentaires dans chaque bloc.

Si vous déterminez que votre entreprise a besoin que les données soient chiffrées, envisagez d'utiliser AES en mode CTR pour générer des bits de chiffrement de flux. Le mode compteur est pratique pour traiter les cas où la réception peut ne pas être fiable et les paquets peuvent être perdus. Vous devrez garder les compteurs synchronisés, alors sachez que la transmission périodique de la valeur du compteur augmentera les frais généraux. Et vous devrez réserver quelques octets d'état pour contenir le compteur, car la réutilisation d'un flux binaire chiffré peut conduire directement à la récupération de données.

Il existe une variété de méthodes de cryptage que vous pouvez utiliser pour sécuriser votre trafic, et chacune a une consommation d'énergie légèrement différente, donc je vais choisir quelques choix populaires. La méthodologie que j'utilise pour évaluer chaque méthode devrait être applicable à tout autre chiffre que vous trouverez et souhaitez comparer.

AES

AES est l'un des algorithmes de chiffrement à clé symétrique les plus populaires (ce qui signifie que vous utilisez la même clé pour chiffrer et déchiffrer). En termes de sécurité, AES est une valeur sûre:

Meilleure cryptanalyse publique

Des attaques ont été publiées qui sont plus rapides sur le plan informatique qu'une attaque par force brute complète, bien qu'aucune en 2013 ne soit réalisable sur le plan informatique.

- Wikipédia

Le document Biclique Cryptanalysis of the Full AES décrit que AES-128 nécessite 2 ^126,1 opérations, AES-192 nécessite 2 ^189,7 opérations et AES-256 nécessite 2 ^254,4 opérations pour se casser. Sur un processeur à 2,9 GHz, en supposant que chaque «opération» représente 1 cycle CPU (probablement faux), la rupture de l'AES-128 prendrait très longtemps . Avec 10 000 d'entre eux en marche, cela prendra encore presque toujours . Donc, la sécurité n'est pas une préoccupation ici; considérons l'aspect puissance.

Ce document montre (à la page 15) que le chiffrement d'un bloc avec AES a utilisé 351 pJ. Je comparerai cela un peu plus tard après avoir parlé d'autres algorithmes courants.

SIMON

J'ai déjà posé une question sur SIMON et SPECK , qui vaut la peine d'être lue. SIMON excelle dans les situations où vous devez crypter un peu de données, fréquemment . L'article que j'ai lié plus tôt indique que SIMON 64/96 utilise 213 pJ pour 64 bits, ce qui est pratique lorsque vous n'avez besoin d'envoyer que 32 bits de charge utile.

SIMON 64/96 est cependant beaucoup plus facile à casser que AES; l'article que j'ai lié suggère une opération de 2 ^63,9 , de sorte que notre configuration de 10 000 CPU pourrait casser le cryptage en seulement quelques années , par opposition à des millions de millénaires.

Est-ce que c'est vraiment important?

Au rythme que vous prévoyez de transmettre, la réponse est presque certainement non ; la consommation d'énergie de la cryptographie sera entièrement négligeable. Pour AES, vous utiliseriez 50 544 pJ par jour , donc une batterie AA carbone-zinc bon marché avec 2340 J d'énergie durerait bien au-delà de la durée de vie de l'appareil . Si vous réévaluez les calculs avec SIMON, vous constatez qu'il a également une très longue durée de vie

Bref, à moins que vous n'émettiez très fréquemment, la radio est bien plus un souci de puissance . Wikipedia cite la consommation d'énergie entre 0,01 et 0,5 W. Si vous transmettez pendant 1 seconde à 0,01 W , vous avez déjà utilisé plus de puissance que AES pendant toute la journée .

Pour BLE, cependant, vous êtes probablement bien en vous basant uniquement sur la sécurité par défaut; BLE utilise AES-CCM par défaut pour la sécurité de la couche liaison :

Le cryptage Bluetooth à faible énergie utilise la cryptographie AES-CCM. Comme BR / EDR, le contrôleur LE effectuera la fonction de cryptage. Cette fonction génère des données chiffrées de 128 bits à partir d'une clé de 128 bits et de données en clair de 128 bits à l'aide du chiffrement de bloc AES-128 bits tel que défini dans FIPS-1971.

Il y a cependant une certaine inquiétude quant à la mise en œuvre de la sécurité de la couche liaison par BLE; ce n'est pas une faille dans AES; Bluetooth SIG a plutôt décidé de déployer son propre mécanisme d'échange de clés en 4.0 et 4.1 . Le problème est désormais résolu en 4.2 car la courbe elliptique Hellman-Diffie est désormais prise en charge.

À moins que vous ne fassiez de la cryptographie accélérée par matériel, le coût de l'énergie sera probablement élevé à mesure que vous obtiendrez un processeur qui est essentiellement surpuissant pour les besoins de base (pas de crypto). Cependant, dans la plupart des cas, c'est l'utilisation de la radio qui consomme le plus d'énergie de toute façon.

Étant donné que vous regardez spécifiquement un SOC Bluetooth, pensez au BGM-111 , qui a une crypto-accélération matérielle sur la puce. J'ai joué avec cette puce et cela semble bon, même si je n'ai pas examiné spécifiquement les fonctions de cryptographie.

Un autre itinéraire, et peut-être le «meilleur» itinéraire si vous voulez vous assurer que personne ne peut récupérer vos clés même s'il démonte l'appareil. Il doit inclure une puce TPM, comme l' OPTIGA TPM , qui a des puces I2C et SPI TPM qui sont prises en charge par les noyaux Linux.

En bref, vous brûlerez des batteries sans crypto matériel spécifique. Soit vous construisez une carte avec une puce TPM, soit vous choisissez un SoC plus moderne avec une cryptographie matérielle déjà intégrée.