Come funzionano le chiavi RSA SecurID ®?

Sì, funziona come dici tu. Il chip è "antimanomissione" e cancellerà il "seme" (chiave segreta) se si tenta di attaccarlo. Ciò viene spesso ottenuto con una batteria non sostituibile dall'utente e una "trappola" che interrompe l'alimentazione al dispositivo una volta che il dispositivo è stato aperto o la superficie del chip è stata rimossa. La chiave viene quindi memorizzata in una SRAM, che richiede l'alimentazione per mantenere la chiave.

La chiave è un seme, che combinato con il tempo corrente in 60 secondi (in pratica, il timestamp UNIX corrente / 60), aggiorna il codice.

No, il dispositivo NON deve essere preciso. Invece, il server memorizzerà l'ora dell'ultimo codice accettato. Quindi il server accetterà un codice un minuto prima, un minuto in anticipo e al momento attuale, quindi se l'ora corrente sul server è 23:20, accetterà un codice dalle 23:19 alle 23:20 e 23: 21.

Dopo questo, memorizzerà l'ora dell'ultimo codice accettato, ad esempio se è stato accettato un codice 23:21, esso memorizzerà 23:21 in un database e si rifiuterà di accettare qualsiasi codice generato alle 23:21 o prima.

Ora per la parte interessante: per evitare che un token impreciso si desincronizzi dal server, il server lo memorizzerà nel suo database, se è stato richiesto di accettare un codice 23:19 o un codice 23:21 alle 23:20. . Ciò garantirà che all'accesso successivo, il server correggerà il codice con il numero di passaggi.

Ti dico di accedere a Clock 23:20 con un codice 23:19. Il server memorizza "-1" nel suo database (e se fosse un codice 23:21, memorizzerebbe "+1" nel database). La prossima volta che accedi, l'orologio è alle 23:40. Quindi il server accetterà un codice 23:38, 23:39 o 23:40. Se viene accettato un codice 23:38, esso memorizzerà "-2" nel database, alle 23:39 manterrà "-1" nel database, e alle 23:40 memorizzerà "0" nel database.

Questo assicura in modo efficace di mantenere il server sincronizzato con il token. Oltre a ciò, il sistema, se un token "è andato troppo lontano" dal server (a causa del suo inutilizzo per un lungo periodo), consente la risincronizzazione. Ciò viene eseguito da un amministratore di sistema o viene presentato un servizio di risincronizzazione self-service in cui all'utente token viene richiesto di fornire 2 codici successivi dal token, come 23:20 e 23:21, o 19:10 e 19:11. Si noti che il server NON accetterà MAI un codice token generato o precedente al tempo in cui "l'ultimo codice token utilizzato" era (poiché ciò consentirebbe il riutilizzo dei codici OTP). Quando viene eseguita una risincronizzazione, il token memorizzerà la differenza tra i 2 codici token forniti e l'ora corrente del server e in una risincronizzazione, la finestra di ricerca potrebbe essere come più / meno 50 passi (che consentirebbe circa 0,75 ore di desincronizzazione in entrambe le direzioni).

Il server può rilevare un token non sincronizzato generando i 50 codici precedenti e 50 codici futuri e, se il codice specificato corrisponde, avvierà automaticamente il processo di risincronizzazione. Molte volte, per impedire a un utente malintenzionato di utilizzare il processo di risincronizzazione per trovare codici validi, una volta che un account è in modalità di risincronizzazione, l'accesso non sarà accettato senza resyncing, il che richiederebbe all'utente malintenzionato di trovare il codice esatto successivo o precedente al codice trovato.

Il token SecurID ha un valore "seme" ad esso assegnato ed è programmato con un algoritmo specifico che genera numeri basati sul seme e il suo orologio di sistema. Il valore di inizializzazione viene inoltre memorizzato in un file che viene fornito con il token. Dopo aver ricevuto il token, gli amministratori di sistema importano il file seme sul server di autenticazione. Poiché il dispositivo token SecurID e il server hanno entrambi il valore di inizializzazione e entrambi utilizzano l'algoritmo, il server può determinare quale dovrebbe essere il codice token corretto in qualsiasi momento.

Occasionalmente, l'orologio del token potrebbe non essere sincronizzato con il server di autenticazione. In tal caso, gli amministratori di sistema o altro personale di supporto autorizzato possono assistere l'utente eseguendo un processo di risincronizzazione sul server. Questo configurerà il server per riconoscere l'offset temporale per quel token in modo che i tentativi di autenticazione futuri debbano essere gestiti in modo accurato.

Nota: poiché questi numeri devono essere prevedibili dal server, sulla base solo dei dati memorizzati nel file seme, l'ora corrente e un algoritmo standard, possono anche essere previsti da un utente malintenzionato con strumenti speciali e accesso al gettone. (O peggio, l'accesso ai file seme stessi - come è sospettato di essere successo nel 2011 .) Dato abbastanza consecutivi codici token, ci sono strumenti in grado di determinare il valore iniziale e quindi generare autonomamente codici futuri.

La risposta di Sebastian è stata fantastica. Lo rifarò in parole povere. Il token SecureID è semplicemente un orologio con un valore di inizializzazione. Invece di visualizzare il tempo visualizza un numero. Il punto in cui possiamo vedere nella foto è secondi (penso), la barra è quando il numero cambierà in modo da poter cronometrare. Se sta toccando il fondo, sta per cambiare e se stai digitando, vorresti aspettare.

Il "seme" è anche sul server che sta autenticando il dispositivo. Quando i membri della sicurezza installano il server RSA, devono caricare gli stessi semi nel server che riceverà il codice PIN.

Quindi ... Fondamentalmente è un criptoclock. Proprio come i vecchi orologi LCD che i miei bambini hanno con Dora, o principesse su di loro. La differenza è il seme che fornisce la matematica per il numero.