Sto osservando le possibili opzioni per creare un canale sicuro tra più dispositivi embedded con funzionalità di crittografia limitate e un server HTTP (potrebbe essere una sorta di servizio Web).
1. Contesto
I dispositivi supportano solo HTTP, alcuni algoritmi a chiave simmetrica e alcune funzioni Hash tramite un framework di sviluppo sui dispositivi. Sfortunatamente SSL / TLS non è supportato e quindi non è un'opzione qui.
Al momento dell'avvio i dispositivi contattano il server HTTP per recuperare la loro configurazione specifica. Ho il controllo completo sui dispositivi prima che vengano inviati in libertà.
Alcune delle minacce identificate sono:
- Download di un file di configurazione dannoso.
- Download del file di configurazione sbagliato (da un altro dispositivo).
- Download multiplo dello stesso file di configurazione.
- Intercettazione del file di configurazione da parte di terzi non autorizzati partito.
- Accesso fraudolento al server HTTP (non necessariamente pertinente qui).
Il processo di recupero del file di configurazione dovrebbe idealmente accadere solo una volta. Una volta scaricato il file di configurazione, l'accesso al server HTTP verrà scartato per quel particolare dispositivo.
2. Proposta
Poiché posso caricare un segreto condiviso temporaneo sui dispositivi prima di lasciarli in libertà, stavo pensando di utilizzare HMAC codificato (codice di autenticazione di Hash Message) per autenticare il dispositivo senza dover inviare la chiave segreta sul filo. Qualcosa di simile alla autenticazione API AWS progetta e usa il numero seriale univoco del dispositivo come ID chiave.
Una volta autenticato, al dispositivo viene concesso l'accesso a una risorsa, in questo caso il file di configurazione. Al fine di mitigare alcune delle minacce identificate, il file di configurazione deve essere crittografato e firmato (?) Durante il trasferimento.
A questo scopo stavo pensando di utilizzare una modalità di crittografia autenticata.
Posso utilizzare solo AES256 in modalità CBC e HMAC-SHA256 . Altro algoritmo di crittografia autenticato "corretto" non è disponibile all'interno del framework.
3. Domande
Ha senso?
Per evitare di aggiungere complessità a qualcosa di abbastanza complesso è un'opzione per utilizzare il segreto condiviso precaricato come chiave per la funzione HMAC e l'hash segreto condiviso come chiave di crittografia per la crittografia AES?
Permette la mitigazione delle minacce identificate in quel particolare scenario?
Il processo può essere semplificato e mantenere le sue proprietà di sicurezza?
3. Risorse
Come scegliere una modalità di crittografia autenticata
Crittografia autenticata e come non farsi prendere a caccia di un coyote
Autenticazione delle richieste utilizzando l'API REST di AWS
Progettazione di un'API REST (Web) sicura senza OAuth
Perché non posso usare la stessa chiave per crittografia e MAC?