Perché non potremmo passare da AES a qualcosa di asimmetrico? Quindi una chiave privata non ha bisogno di essere condivisa con il cliente; piuttosto basta condividere una chiave pubblica con loro.
Il concetto
Immagino tu intenda un cryptosystem ibrido , poiché la crittografia di tutto con algoritmi asimmetrici sarebbe lenta per dispositivi embedded come ( economico) router. TLS (usato in HTTPS) usa la stessa cosa: la chiave pubblica viene inviata al browser, la usano per scambiare una chiave segreta (generata casualmente per ogni connessione), e da lì utilizzare AES o ChaCha20 per scambiare dati (crittografati usando il casuale chiave).
Nelle reti WPA2-PSK, è possibile decodificare il traffico da tutti i client se si conosce la chiave pre-condivisa (PSK) e si è riusciti a catturare l'handshake che si è verificato all'inizio di una connessione. Perché non utilizziamo la crittografia asimmetrica, che consente solo al destinatario di decifrare il nostro messaggio? Funzionerebbe così:
Non è possibile configurare un AP senza conoscere il PSK, poiché non sarebbero mai in grado di decodificare la chiave casuale.
Il problema: verifica della chiave pubblica
C'è un problema qui: come sai di aver ricevuto la chiave pubblica corretta al momento della connessione? Chiunque potrebbe inviarti una chiave pubblica, anche un aggressore, e il tuo cliente potrebbe crittografare la chiave casuale con la chiave pubblica dell'attaccante. L'attaccante può decrittografare il tuo traffico e inoltrarlo all'AP, quindi non hai idea di essere intercettato.
Perché un sistema CA non può essere utilizzato
In HTTPS, questo è risolto dal sistema CA, dove ci sono terze parti fidate che possono firmare la tua chiave pubblica. Chiunque si connetta al sito Web verificherà che sia firmato da una terza parte fidata. Funziona perché una CA può facilmente verificare se qualcuno possiede un dominio: "firmerò il tuo certificato solo per example.com , se inserisci il codice 1ZTHrM5OM14fe2ce in example.com/verification ". Questo non è possibile per una rete WiFi poiché richiede la vicinanza fisica e non esiste il concetto di avere un nome di dominio univoco.
Controllo dell'impronta digitale
SSH risolve questo mostrando l'impronta digitale al client, qualcosa sulla falsariga di " 192.168.1.1 ha l'impronta digitale SHA256:1OBS2zY... , vuoi continuare?" Se continui, memorizzerà l'impronta digitale (FP) e l'indirizzo IP o il dominio a cui ti stavi connettendo, quindi può solo verificare che non sia cambiato dall'ultima volta.
Questo è anche possibile con WiFi (dopo il primo utilizzo, FP sarà memorizzato con l'SSID). Il problema è che il FP completo deve essere comunicato al client e l'utente deve controllare ogni byte. Vedi i tuoi nonni che controllano attentamente se Wa3rQOGlqo corrisponde al FP pubblicato dal proprietario della rete? Se si controllano solo pochi byte all'inizio e / o alla fine, è banale generare una chiave pubblica la cui FP corrisponde all'inizio e / o alla fine. Rende inoltre più difficile la sostituzione del punto di accesso, poiché è necessario trasferire la chiave privata (o riconfigurare ciascun dispositivo connesso per fidarsi del nuovo FP).
Qual è il punto di questo nuovo?
Ma perché preoccuparsi? L'AP ha già dimostrato di conoscere il PSK. Perché vogliamo avere una verifica aggiuntiva?
Bene, l'intero punto di utilizzo della crittografia asimmetrica piuttosto che della crypto simmetrica impedisce ai client di leggere il traffico reciproco. Chiunque abbia conoscenza di PSK può configurare un AP falso e intercettare il traffico. Pertanto è necessario utilizzare uno schema che verifica che sia stata utilizzata la chiave pubblica corretta.
Conclusione
Perché non esiste un modo semplice per farlo, presumo. Ma non conosco nessuna letteratura in cui questo sia stato discusso e respinto. O qualsiasi standard proposto che non ha mai avuto un uso diffuso.
Potrebbe sicuramente essere fatto come descritto sopra se le persone sono disposte a verificare le impronte digitali, ma potrebbe essere più semplice connettersi a una VPN se si desidera proteggere il proprio traffico.
AES è molto veloce, anche nel software non è male, ma con l'accelerazione hardware è abbastanza facile stare al passo con elevate velocità di trasmissione dati senza impazzire enormi blocchi di accelerazione hardware.
Puoi cercare benchmark di velocità per varie operazioni di crittografia - noterai quasi sempre RSA / ECC in tempo utile per eseguire una singola operazione di decrittografia o un singolo scambio di chiavi.
Per darti un po 'di confusione, possiamo guardare i core dell'hardware IP dallo stesso fornitore e dall'uso di velocità / risorse. Userò IPcores.com perché hanno entrambi i tipi di core, è solo una società casuale che ho usato come esempio. Nell'hardware userò il loro "numero di porte" pubblicato per darti un po 'di scala - più porte significano più hardware necessario nel chip = più costoso.
Per Un core ECC da IPCores.com si tratta di circa 10.000 porte. Per Un core AES da IPCores.com si tratta di porte da 3K.
Il core AES pubblicizza 0,8 bit / ora, quindi ad esempio eseguendolo a 100 MHz si otterrebbe un throughput di 80 Mb / s (10 MByte / sec). Potresti facilmente andare più veloce di così o eseguire un core più grande (ma processa più contemporaneamente) per ottenere quasi ogni bit rate di cui hai bisogno, dato che quel core da 3000 gate è l'opzione più lenta.
Il core ECC non pubblica un bit rate - ma dice circa 5000 punti muls / secondo (il core non è un'implementazione ECC completa, quindi ci sono altre cose necessarie). Ma dovrebbe darti la sensazione che questo non sia nemmeno lontanamente vicino alle prestazioni richieste per eseguire la decrittazione dei dati effettiva con la massima velocità di trasmissione dati necessaria.
L'altro problema associato al compromesso in termini di dimensioni / velocità è che un core più grande che gira più velocemente sarà un vero e proprio power hog, quindi avrai anche problemi con il consumo di energia della batteria.
Ma penso che se inizi a fare alcuni esperimenti con velocità asimmetriche della crittografia, ti aiuterà a capire perché non utilizziamo la crittografia asimmetrica ovunque, e solo per scambiare alcune informazioni critiche prima di passare a una cifratura simmetrica.
Poiché i dispositivi wireless hanno una quantità minore di RAM e spazio di archiviazione, sarebbe difficile eseguire le operazioni di gestione delle chiavi necessarie per un algoritmo di crittografia asimmetrica.