Costruisci un canale sicuro senza SSL / TLS

8

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?

    
posta Moustache 18.06.2013 - 12:11
fonte

1 risposta

6

Sia il server che il client sanno qualcosa di segreto, quindi possono fidarsi del fatto che la comunicazione non viene alterata nel percorso. Effettivamente, usare una connessione tramite la chiave condivisa tra di loro è come usare SSL senza il movimento della mano. Normalmente SSL usa la crittografia asimmetrica per a) convalida una o più parti nella comunicazione eb) stabilisce una chiave condivisa per la comunicazione.

Tuttavia, sei in grado di stabilire la fiducia in una parte prima di rilasciare il dispositivo poiché entrambi sono in tuo possesso. A condizione che la chiave sul dispositivo non sia compromessa (che è il punto debole principale a seconda dell'utilizzo), allora se un dispositivo è in grado di comunicare in un modo che decrittografa, correttamente, il messaggio è originato dal dispositivo. Pertanto, è sufficiente preoccuparsi degli attacchi di riproduzione, ma qualsiasi meccanismo semplice potrebbe bloccarlo (ad esempio un contatore o un timestamp per evitare il riutilizzo o l'uso di un messaggio precedente rispetto a quello corrente.)

    
risposta data 18.06.2013 - 15:07
fonte

Leggi altre domande sui tag