Qual é a implicação de poder da criptografia do tráfego do meu sensor?

Considerando um tipo típico de aplicação, um sensor alimentado por bateria faz leituras (valor de 32 bits) a cada 10 minutos, qual é o provável impacto na vida útil da bateria se eu escolher um protocolo no ar não criptografado simples, em comparação com uma transmissão criptografada?

Suponha que meus dados não sejam particularmente secretos, mas, de acordo com essa pergunta, eu provavelmente preciso criptografá-los, desde que não haja um custo de design significativo.

Para simplificar, vamos assumir que estou usando um SoC nRF51822 que suporta uma pilha BLE e também um protocolo mais simples de 2,4 GHz.

Como estou pensando em um aplicativo comercial de produto em vez de em uma instalação única, a criptografia precisa ser intensiva em computação (digamos, pelo menos, US $ 500 em computação em nuvem em 2016), em vez de uma simples ofuscação. Algo que permanece seguro, mesmo com o acesso ao firmware do dispositivo.

Provavelmente, a maior parte de sua energia será gasta na transmissão de RF, não nos ciclos de CPU gastos nas rotinas de criptografia. Cada bit adicional transmitido lhe custará mais energia do que a criptografia que você está propondo. Isso significa que, se você adotar uma abordagem ingênua, como usar o AES no modo CBC, corre o risco de aumentar o tamanho da mensagem para transportar os bits extras em cada bloco.

Se você determinar que sua empresa precisa que os dados sejam criptografados, considere usar o AES no modo CTR para gerar bits de criptografia de fluxo. O modo contador é prático para lidar com casos em que a recepção pode não ser confiável e pacotes podem ser perdidos. Você precisará manter os contadores sincronizados. Lembre-se de que a transmissão periódica do valor do contador aumentará a sobrecarga. E você terá que reservar alguns bytes de estado para conter o contador, porque a reutilização de um fluxo de bits criptografado pode levar diretamente à recuperação dos dados.

Há uma variedade de métodos de criptografia que você pode usar para proteger seu tráfego, e cada um tem um uso de energia um pouco diferente, então vou escolher algumas opções populares. A metodologia usada para avaliar cada método deve ser aplicável a quaisquer outras cifras que você encontrar e desejar comparar.

AES

O AES é um dos algoritmos de criptografia de chave simétrica mais populares (o que significa que você usa a mesma chave para criptografar e descriptografar). Em termos de segurança, o AES é uma aposta segura:

Melhor criptoanálise pública

Foram publicados ataques computacionalmente mais rápidos do que um ataque de força bruta total, embora nenhum a partir de 2013 seja computacionalmente viável.

- Wikipedia

O artigo Biclique Cryptanalysis do AES Completo descreve que o AES-128 requer 2 ^126,1 operações, o AES-192 exige 2 ^189,7 operações e o AES-256 requer 2 ^254,4 operações para quebrar. Em um processador de 2,9 GHz, assumindo que cada 'operação' é de 1 ciclo da CPU (provavelmente não é verdade), a quebra do AES-128 levaria muito tempo . Com 10.000 deles em execução, ainda levará quase uma eternidade . Portanto, segurança não é uma preocupação aqui; vamos considerar o aspecto do poder.

Este artigo mostra (na página 15) que criptografar um bloco com o AES usou 351 pJ. Compararei isso um pouco mais tarde, depois de falar sobre outros algoritmos comuns.

SIMON

Fiz uma pergunta sobre SIMON e SPECK anteriormente, que vale a pena ler. Onde o SIMON se destaca é em situações em que você precisa criptografar um pouco de dados com frequência . O artigo que eu relacionei anteriormente afirma que o SIMON 64/96 usa 213 pJ para 64 bits, o que é prático quando você precisa enviar apenas 32 bits de carga útil.

O SIMON 64/96 é significativamente mais fácil de quebrar do que o AES; o artigo que vinculei sugere 2 ^63,9 operações; portanto, nossa configuração de 10.000 CPU pode quebrar a criptografia em apenas alguns anos , em oposição a milhões de milênios.

Isso realmente importa?

Na taxa que você planeja transmitir, a resposta é quase certamente não ; o uso de energia da criptografia será totalmente desprezível. Para o AES, você usaria 50 544 pJ por dia , portanto, uma bateria AA de carbono-zinco barata com 2340 J de energia duraria muito além da vida útil do dispositivo . Se você reavaliar os cálculos com o SIMON, descobre que ele também tem uma vida útil muito longa

Em resumo, a menos que você esteja transmitindo com muita frequência, o rádio é muito mais uma preocupação com energia . A Wikipedia cita o uso de energia entre 0,01 e 0,5 W. Se você transmitir por 1 segundo a 0,01 W , você já usou mais energia do que a AES durante todo o dia .

No entanto, para o BLE, você provavelmente está bem apenas confiando na segurança padrão; O BLE usa o AES-CCM por padrão para segurança da camada de link :

A criptografia no Bluetooth com baixa energia usa a criptografia AES-CCM. Como BR / EDR, o LE Controller executará a função de criptografia. Essa função gera dados criptografados de 128 bits a partir de uma chave de 128 bits e dados simples de texto de 128 bits usando o código de bloco AES de 128 bits, conforme definido em FIPS-1971.

Existe alguma preocupação de que haja falhas de segurança com a implementação do BLE da segurança da camada de link; isso não é uma falha no AES; Em vez disso, o Bluetooth SIG decidiu lançar seu próprio mecanismo de troca de chaves nas versões 4.0 e 4.1 . Agora, o problema foi resolvido no 4.2, pois a curva elíptica Hellman-Diffie agora é suportada.

A menos que você esteja usando criptografia acelerada por hardware, o custo de energia provavelmente será alto, pois você terá um processador que é essencialmente sobrecarregado para as necessidades básicas (não criptográficas). No entanto, na maioria dos casos, é o uso do rádio que consome mais energia de qualquer maneira.

Como você está olhando especificamente para um SOC bluetooth, considere o BGM-111 , que possui criptografia acelerada por hardware no chip. Joguei com esse chip e parece bom, embora não tenha examinado especificamente as funções de criptografia.

Outra rota e, possivelmente, a melhor rota, se você quiser garantir que ninguém possa obter suas chaves, mesmo que desmonte o dispositivo. Isso inclui um chip TPM, como o OPTIGA TPM , que possui chips I2C e SPI TPM compatíveis com os kernels do Linux.

Em resumo, você queimará baterias sem criptografia de hardware específica. Crie uma placa com um chip TPM ou escolha um SoC mais moderno que possua criptografia de hardware já incorporada.