Welche Auswirkungen hat die Verschlüsselung meines Sensordatenverkehrs auf die Leistung?

Unter Berücksichtigung eines typischen Anwendungstyps, eines batteriebetriebenen Sensors, der alle 10 Minuten Messwerte (32-Bit-Wert) erfasst. Was ist die wahrscheinliche Auswirkung auf die Batterielebensdauer, wenn ich mich für ein einfaches unverschlüsseltes On-Air-Protokoll im Vergleich zu einer verschlüsselten Übertragung entscheide?

Angenommen, meine Daten sind nicht besonders geheim, aber gemäß dieser Frage muss ich wahrscheinlich überlegen, sie zu verschlüsseln, solange es keine nennenswerten Designkosten gibt.

Nehmen wir zur Vereinfachung an, ich verwende einen nRF51822- SoC, der einen BLE-Stack und ein einfacheres 2,4-GHz-Protokoll unterstützt.

Da ich eher an eine kommerzielle Produktanwendung als an eine einmalige Installation denke, muss die Verschlüsselung rechenintensiv sein (sagen wir mindestens 500 US-Dollar für 2016 Cloud-Computing), statt an eine einfache Verschleierung. Etwas, das auch bei Zugriff auf die Gerätefirmware sicher bleibt.

Der Großteil Ihrer Energie wird wahrscheinlich für die HF-Übertragung aufgewendet, nicht für CPU-Zyklen, die für Verschlüsselungsroutinen aufgewendet werden. Jedes zusätzliche übertragene Bit kostet mehr Strom als die von Ihnen vorgeschlagene Verschlüsselung. Wenn Sie also einen naiven Ansatz wählen, wie z. B. AES im CBC-Modus, riskieren Sie, die Nachrichtengröße zu erhöhen, um die zusätzlichen Bits in jedem Block zu übertragen.

Wenn Sie feststellen, dass in Ihrem Unternehmen die Daten verschlüsselt werden müssen, sollten Sie AES im CTR- Modus verwenden, um Stream- Verschlüsselungsbits zu generieren. Der Zählermodus ist praktisch, wenn der Empfang unzuverlässig sein und Pakete verloren gehen können. Sie müssen die Zähler synchron halten. Beachten Sie daher, dass die regelmäßige Übertragung des Zählerwerts den Overhead erhöht. Außerdem müssen Sie einige Statusbytes reservieren, um den Zähler zu speichern, da die Wiederverwendung eines verschlüsselten Bitstroms direkt zur Datenwiederherstellung führen kann.

Es gibt eine Vielzahl von Verschlüsselungsmethoden, mit denen Sie Ihren Datenverkehr schützen können, und jede hat einen leicht unterschiedlichen Stromverbrauch. Ich werde daher einige beliebte Methoden auswählen. Die Methode, die ich zur Bewertung der einzelnen Methoden verwende, sollte auf alle anderen Chiffren anwendbar sein, die Sie finden und vergleichen möchten.

AES

AES ist einer der beliebtesten Verschlüsselungsalgorithmen für symmetrische Schlüssel (dh Sie verwenden denselben Schlüssel zum Ver- und Entschlüsseln). In Bezug auf die Sicherheit ist AES eine sichere Sache:

Beste öffentliche Kryptoanalyse

Es wurden Angriffe veröffentlicht, die rechnerisch schneller sind als ein voller Brute-Force-Angriff, obwohl ab 2013 keine rechnerisch durchführbar sind.

- Wikipedia

In der Veröffentlichung Biclique Cryptanalysis of the Full AES wird beschrieben, dass AES-128 2 ^126,1 Operationen erfordert , AES-192 2 ^189,7 Operationen erfordert und AES-256 2 ^254,4 Operationen erfordert , um zu brechen. Bei einem 2,9-GHz-Prozessor würde das Unterbrechen von AES-128 eine sehr lange Zeit in Anspruch nehmen, vorausgesetzt, jeder "Vorgang" ist ein CPU-Zyklus (wahrscheinlich nicht wahr) . Mit 10 000 davon wird es immer noch fast ewig dauern . Sicherheit ist hier also kein Problem. Betrachten wir den Leistungsaspekt.

Dieses Dokument zeigt (auf Seite 15), dass für die Verschlüsselung eines Blocks mit AES 351 pJ verwendet wurden. Ich werde dies etwas später vergleichen, nachdem ich über einige andere gängige Algorithmen gesprochen habe.

SIMON

Ich habe vorher eine Frage zu SIMON und SPECK gestellt , die es wert ist, gelesen zu werden. SIMON zeichnet sich durch Situationen aus, in denen Sie häufig ein wenig Daten verschlüsseln müssen . Das zuvor verlinkte Papier besagt, dass SIMON 64/96 213 pJ für 64 Bit verwendet, was praktisch ist, wenn Sie nur 32 Bit Nutzlast senden müssen.

SIMON 64/96 ist jedoch wesentlich leichter zu brechen als AES; Das von mir verlinkte Papier schlägt 2 ^63,9 Operationen vor, sodass unser 10 000 CPU-Setup die Verschlüsselung in nur wenigen Jahren knacken könnte , im Gegensatz zu Millionen von Jahrtausenden.

Ist es wirklich wichtig?

Bei der geplanten Übertragungsrate lautet die Antwort mit ziemlicher Sicherheit Nein . Der Energieverbrauch aus der Kryptographie wird völlig vernachlässigbar sein. Für AES würden Sie 50 544 pJ pro Tag verbrauchen , sodass eine billige Kohlenstoff-Zink-AA-Batterie mit 2340 J Energie weit über die Lebensdauer des Geräts hinaus reicht . Wenn Sie die Berechnungen mit SIMON neu auswerten, stellen Sie fest, dass es auch eine sehr lange Lebensdauer hat

Kurz gesagt, wenn Sie nicht sehr häufig senden , ist das Radio weitaus wichtiger für die Stromversorgung . Wikipedia gibt einen Stromverbrauch zwischen 0,01 und 0,5 W an. Wenn Sie eine Sekunde lang mit 0,01 W senden , haben Sie den ganzen Tag über bereits mehr Strom verbraucht als AES .

Für BLE ist es wahrscheinlich in Ordnung, sich nur auf die Standardsicherheit zu verlassen. BLE verwendet standardmäßig AES-CCM für die Sicherheit der Verbindungsschicht :

Bei der Bluetooth-Verschlüsselung mit geringem Energieverbrauch wird AES-CCM-Kryptografie verwendet. Wie BR / EDR führt der LE-Controller die Verschlüsselungsfunktion aus. Diese Funktion generiert verschlüsselte 128-Bit-Daten aus einem 128-Bit-Schlüssel und 128-Bit-Nur-Text-Daten unter Verwendung des AES-128-Bit-Block-Chiffrierers, wie in FIPS-1971 definiert.

Es gibt jedoch Bedenken, dass es Sicherheitslücken bei der Implementierung der Link-Layer-Sicherheit durch BLE gibt. Dies ist kein Fehler in AES; Stattdessen entschied sich Bluetooth SIG, einen eigenen Schlüsselaustauschmechanismus in 4.0 und 4.1 zu implementieren . Das Problem wurde in 4.2 behoben, da jetzt die elliptische Kurve Hellman-Diffie unterstützt wird.

Wenn Sie keine hardwarebeschleunigte Kryptografie durchführen, sind die Stromkosten wahrscheinlich hoch, da Sie einen Prozessor haben, der im Wesentlichen für die Grundanforderungen (nicht für Kryptografie) überlastet ist. In den meisten Fällen ist es jedoch die Verwendung des Radios, die ohnehin die meiste Energie verbraucht.

Da Sie sich speziell mit einem Bluetooth-SOC befassen, sollten Sie das BGM-111 in Betracht ziehen , das eine hardwarebeschleunigte Krypto auf dem Chip aufweist. Ich habe mit diesem Chip gespielt und es scheint gut zu sein, obwohl ich mich nicht speziell mit den Kryptofunktionen befasst habe.

Eine andere Route und möglicherweise die 'beste' Route, wenn Sie sicherstellen möchten, dass niemand Ihre Schlüssel erhalten kann, auch wenn er das Gerät zerlegt. Dazu gehört ein TPM-Chip wie der OPTIGA TPM , der I2C- und SPI-TPM-Chips enthält, die von Linux-Kerneln unterstützt werden.

Kurz gesagt, Sie werden Batterien ohne spezielle Hardware-Krypto durchbrennen. Bauen Sie entweder ein Board mit einem TPM-Chip oder wählen Sie einen moderneren SoC mit bereits integrierter Hardware-Krypto.