Come assicurarsi che una nuova chiave si sia propagata

Suppongo che tu stia utilizzando HMAC o la crittografia autenticata in modo che i messaggi siano immuni alle modifiche e quindi puoi rilevare in modo pulito una decrittografia non riuscita.

1. L'hub ha un elenco di dispositivi collegati e, per ciascun dispositivo connesso, la chiave attiva da utilizzare nei messaggi e un elenco di chiavi aggiuntive da provare a utilizzare per decrittografare i messaggi.
2. L'hub decide una nuova chiave e, per ciascun dispositivo connesso, la aggiunge alla fine dell'elenco di chiavi aggiuntive. (Semplice miglioramento apportando una piccola modifica qui: potresti invece creare una nuova chiave separata per ogni dispositivo. Non è necessario condividere chiavi tra dispositivi.)
3. Ogni volta che esiste una quantità diversa di chiavi aggiuntive per un dispositivo, l'hub invia periodicamente un messaggio (crittografato con la chiave attiva del dispositivo) contenente una richiesta per passare a una nuova chiave (l'ultima chiave nell'elenco delle chiavi aggiuntive).
4. Ogni volta che l'hub riceve un messaggio da un dispositivo connesso, proverà a decrittografarlo con la chiave attiva e quindi ciascuna delle chiavi aggiuntive fino a quando la decrittografia avrà esito positivo. Se la decrittografia ha esito positivo con una delle chiavi aggiuntive, sostituisci la chiave attiva con quella chiave, quindi rimuovi quella chiave e tutte le chiavi prima dall'elenco delle chiavi aggiuntive.

Ogni dispositivo deve ricordare solo un singolo tasto attivo alla volta.

Questo dovrebbe significare che le cose continuano a funzionare anche nello scenario in cui l'hub cicla tra i tasti A- > B- > C, e un dispositivo non conferma il passaggio al tasto B fino a quando l'hub non ha annunciato la chiave C .

Gli utenti del mondo reale delle chiavi crittografiche probabilmente ti daranno il seguente consiglio:

• Per ogni copia di una chiave emessa, l'esito positivo (intatto) la ricezione di tale chiave deve essere riconosciuta all'emittente.
• L'adozione di una chiave per l'utilizzo può essere consentita solo quando tutti i destinatari hanno confermato la ricezione.

Oltre a fornire i bit che compongono la chiave (128 bit, 256 bit o qualsiasi cosa sia), è utile fornire metadati che identificano la chiave in un modo che è unico per ogni chiave all'interno del sistema, e preferibilmente compresa la data prevista di adozione. Questi metadati dovrebbero essere associati ai bit della chiave, in modo che non vengano separati, ad esempio fanno parte dello stesso blocco di dati, con i metadati come una parte di "intestazione".

I dati crittografati devono essere formattati per identificare la chiave utilizzata per crittografarla. Quindi ciascun nodo remoto può rilevare quando la chiave del futuro è stata adottata per l'utilizzo (ad esempio, ora è la chiave attiva). La chiave precedentemente attiva può quindi essere programmata per la cancellazione sicura dalla memoria locale su quel nodo.

Ciò implica che ogni nodo deve tenere traccia della chiave attualmente adottata (attiva) e della chiave successiva che è stata emessa con (Futuro). Alla data / ora di adozione pianificata, il nodo centrale responsabile della distribuzione può decidere di adottare la chiave Future se ogni nodo che lo richiede ha confermato il suo ricevimento (ad esempio citando i metadati in un messaggio di riconoscimento). Ciò richiede che il nodo centrale traccia, per ogni chiave, su quali nodi ha inviato una copia e su quali nodi hanno confermato la ricezione.

Questo è davvero il modello più semplice. Se i tuoi nodi sono più affidabili, tu può emettere una pipeline di più di una chiave Future, con date di adozione successive e successive fornite nei metadati.