Qual è l'implicazione energetica della crittografia del traffico del mio sensore?

Considerando un tipo tipico di applicazione, un sensore alimentato a batteria che rileva letture (valore a 32 bit) ogni 10 minuti, qual è il probabile impatto sulla durata della batteria se scelgo un semplice protocollo on-air non crittografato, rispetto a una trasmissione crittografata?

Supponiamo che i miei dati non siano particolarmente segreti, ma secondo questa domanda probabilmente dovrei prendere in considerazione la crittografia, a condizione che non ci sia un costo di progettazione significativo.

Per semplicità, supponiamo che io stia usando un SoC nRF51822 che supporta uno stack BLE e anche un protocollo 2.4 GHz più semplice.

Dal momento che sto pensando a un'applicazione di prodotto commerciale piuttosto che a un'installazione una tantum, la crittografia deve essere intensiva per il calcolo per essere interrotta (diciamo almeno $ 500 del 2016 cloud computing), piuttosto che una semplice offuscamento. Qualcosa che rimane sicuro anche con l'accesso al firmware del dispositivo.

La maggior parte della tua energia sarà probabilmente spesa per la trasmissione RF, non per i cicli della CPU spesi nelle routine di crittografia. Ogni bit aggiuntivo trasmesso ti costerà più potenza della crittografia che stai proponendo. Ciò significa che se si adotta un approccio ingenuo, come l'utilizzo di AES in modalità CBC, si rischia di aumentare la dimensione del messaggio per trasportare i bit extra in ciascun blocco.

Se ritieni che la tua azienda abbia bisogno che i dati vengano crittografati, considera l'utilizzo di AES in modalità CTR per generare bit di cifratura del flusso. La modalità contatore è pratica per gestire i casi in cui la ricezione può essere inaffidabile e i pacchetti potrebbero andare persi. Dovrai mantenere sincronizzati i contatori, quindi tieni presente che la trasmissione periodica del valore del contatore aggiungerà al sovraccarico. E dovrai riservare alcuni byte di stato per contenere il contatore, perché il riutilizzo di un flusso di bit crittografato può portare direttamente al recupero dei dati.

Esistono una varietà di metodi di crittografia che è possibile utilizzare per proteggere il traffico e ognuno ha un consumo di energia leggermente diverso, quindi sceglierò un paio di scelte popolari. La metodologia che utilizzo per valutare ciascun metodo dovrebbe essere applicabile a qualsiasi altro codice che trovi e desideri confrontare.

AES

AES è uno dei più popolari algoritmi di crittografia a chiave simmetrica (il che significa che si utilizza la stessa chiave per crittografare e decrittografare). In termini di sicurezza, AES è una scommessa sicura:

La migliore crittoanalisi pubblica

Sono stati pubblicati attacchi che sono computazionalmente più veloci di un attacco di forza bruta completa, anche se nessuno dal 2013 è fattibile dal punto di vista computazionale.

- Wikipedia

Il documento Bicypt Cryptanalysis of the Full AES descrive che AES-128 richiede 2 ^126,1 operazioni, AES-192 richiede 2 ^189,7 operazioni e AES-256 richiede 2 ^254,4 operazioni da interrompere. Su un processore da 2,9 GHz, supponendo che ogni 'operazione' sia 1 ciclo della CPU (probabilmente non vero), la rottura di AES-128 richiederebbe molto tempo . Con 10.000 di loro in esecuzione, ci vorrà ancora quasi per sempre . Quindi, la sicurezza non è un problema qui; consideriamo l'aspetto del potere.

Questo documento mostra (a pagina 15) che la crittografia di un blocco con AES ha utilizzato 351 pJ. Lo confronterò un po 'più tardi dopo aver parlato di alcuni altri algoritmi comuni.

SIMON

Ho fatto una domanda su SIMON e SPECK in precedenza, che vale la pena leggere. Dove SIMON eccelle è nelle situazioni in cui è necessario crittografare un po 'di dati, frequentemente . Il documento che ho collegato in precedenza afferma che SIMON 64/96 utilizza 213 pJ per 64 bit, il che è pratico quando è necessario inviare solo 32 bit di payload.

SIMON 64/96 è significativamente più facile da interrompere rispetto ad AES; il documento che ho collegato suggerisce 2 ^63,9 operazioni, quindi la nostra configurazione di 10.000 CPU potrebbe decifrare la crittografia in pochi anni , a differenza di milioni di millenni.

Importa davvero?

Alla velocità che prevedi di trasmettere, la risposta è quasi certamente no ; l'utilizzo di energia dalla crittografia sarà del tutto trascurabile. Per AES, utilizzeresti 50 544 pJ al giorno , quindi una batteria AA al carbonio-zinco economica con 2340 J di energia durerebbe ben oltre la durata del dispositivo . Se rivaluti i calcoli con SIMON, scopri che ha anche una durata molto lunga

In breve, a meno che non si stia trasmettendo molto frequentemente, la radio è molto più preoccupante per il potere . Wikipedia cita il consumo di energia tra 0,01 e 0,5 W. Se trasmetti per 1 secondo a 0,01 W , hai già usato più potenza di AES durante l'intera giornata .

Per BLE, però, probabilmente stai bene affidandoti alla sicurezza predefinita; BLE utilizza AES-CCM per impostazione predefinita per la sicurezza a livello di collegamento :

La crittografia in Bluetooth a bassa energia utilizza la crittografia AES-CCM. Come BR / EDR, il controller LE eseguirà la funzione di crittografia. Questa funzione genera dati crittografati a 128 bit da una chiave a 128 bit e dati in testo normale a 128 bit utilizzando il cifrario a blocchi AES-128 bit come definito in FIPS-1971.

Tuttavia, vi sono alcune preoccupazioni in merito alla presenza di difetti di sicurezza nell'implementazione di BLE della sicurezza a livello di collegamento; questo non è un difetto in AES; piuttosto Bluetooth SIG ha deciso di implementare il proprio meccanismo di scambio di chiavi in ​​4.0 e 4.1 . Il problema è ora risolto in 4.2 poiché la curva ellittica Hellman-Diffie è ora supportata.

A meno che non si stia eseguendo una crittografia con accelerazione hardware, è probabile che il costo dell'energia sia elevato quando si arriva a un processore che è essenzialmente sopraffatto per le esigenze di base (non crittografiche). Tuttavia, nella maggior parte dei casi è comunque l'uso della radio a consumare più energia.

Dal momento che stai specificamente guardando un SOC bluetooth, considera il BGM-111 , che ha crittografia con accelerazione hardware sul chip. Ho giocato con questo chip e sembra buono, anche se non ho esaminato le funzioni crittografiche in modo specifico.

Un altro percorso, e forse il percorso "migliore" se si desidera assicurarsi che nessuno possa ottenere le chiavi anche se smontano il dispositivo. Comprende un chip TPM, come OPTIGA TPM , che ha chip TPM I2C e SPI supportati dai kernel Linux.

In breve, brucerai le batterie senza crittografia hardware specifica. Costruisci una scheda con un chip TPM o scegli un SoC più moderno con crittografia hardware già integrata.