Jag har använt RSA SecureID ® -tangenter under ganska lång tid nu (kanske tio år), för saker som säkert mitt hembankkonto online eller tillgång till min företagets nätverk av datorer hemifrån. Dessa nycklar genererar en 6-siffrig numerisk symbol som är inställd på att upphöra. Jag har alltid undrat hur dessa fungerar.
På höger sida finns en punkt (visas inte på bilden) som blinkar en gång per sekund och till vänster finns en stapel med sex vertikalt staplade horisontella staplar, som var och en försvinner var tionde sekund. Varje gång sextio sekunder har gått återställs token själv och den föregående token blir ogiltig.
AFAIK använder dessa enheter inte nätverket och numren de genererar måste kontrolleras av servern servern är en bank eller ett företags server). Därför måste inuti denna enhet lagras en algoritm som genererar slumptal med en mekanism som inkluderar en mycket exakt timer som drivs av ett litet batteri. Timern måste vara mycket exakt, eftersom servern måste kontrollera giltigheten för de genererade siffrorna inom samma tidsintervall. För varje användare / anställd måste servern, så vitt jag förstår, lagra samma slumptalsgenererande algoritm med en sådan algoritm per kund / anställd. Självklart måste chipet konstrueras på ett sådant sätt att om det blir stulet så kan angriparen inte komma åt den slumpmässiga genereringsalgoritmen som finns lagrad där, även om enheten är trasig.
Är det så här? / p>
Tack!
Kommentarer
- Samma sätt TOTP fungerar, förutom det senare behöver du inte ’ inte köpa en för dyr lösning och kan använda vanliga telefoner eller vilken enhet som helst som kan basera beräkningen, även en smartwatch .
- Programvarudefinierad OTP är extremt dålig eftersom du inte får manipuleringsmotståndet, vilket krävs för att få motstånd mot kloning av utsäde. Alla som har en Micro-USB-kabel och rätt verktyg kan klona din telefon på < 5 minuter. Om det är lösenordsskyddat kan den krypterade klonen lagras tills koden kan erhållas genom skadlig programvara eller surfning på axeln. Vissa telefoner erbjuder idag en manipulationsresistent hårdvarunyckellager, då är det en bra idé att använda det eller en säkerhetssmart-MicroSD. Det förhindrar att fröet extraheras, endast ” använde ”. Men TOTP-tokens som inte är RSA-hårdvara är riktigt billiga.
- Relaterat: Hur RSA-tokens fungerar
- @sebastiannielsen att litar fortfarande på social ingenering eller på användare som inte tittar ordentligt på sina saker. Om jag kan ansluta användarens ’ -telefon till en dator utan att han märker det, kan jag lika gärna stjäla hans RSA-token och sätta en annan på sin plats (och han vann ’ t märker tills nästa gång han försöker använda det som skulle vara för sent).
- Värt att länka: Kan siffror på RSA SecurID-tokens förutses?
Svar
Ja det fungerar som du säger . Chipet är ”manipuleringsbeständigt” och raderar ”fröet” (hemlig nyckel) om något försök görs för att attackera det. Detta åstadkoms ofta genom att ha ett batteri som inte kan bytas ut av användaren och en ”fälla” som bryter strömmen till enheten när enheten öppnas eller chipets yta tas bort. Nyckeln lagras sedan i en SRAM, vilket kräver ström för att behålla nyckeln.
Nyckeln är en frö som kombineras med den aktuella tiden i 60 sekunders steg (effektivt den nuvarande UNIX-tidsstämpeln / 60), uppdaterar koden.
Nej, enheten behöver INTE vara exakt. Istället lagrar servern tiden för den senast accepterade koden. Då accepterar servern en kod en minut tidigare, en minut framåt och vid den aktuella tiden, så om den aktuella tiden på servern är 23:20, kommer den att acceptera en kod från 23:19, 23:20 och 23: 21.
Därefter lagras tidpunkten för den senast accepterade koden, t.ex. om en 23:21-kod accepterades, kommer den att lagras 23:21 i en databas och vägrar att acceptera någon kod som genererades kl 23:21 eller tidigare.
Nu till den intressanta delen: För att förhindra att en exakt token desynkroniseras från servern lagras servern i sin databas om den krävde att acceptera en 23: 19-kod eller en 23:21-kod vid 23:20-tiden. Detta kommer att säkerställa att servern vid nästa inloggning korrigerar koden med antalet steg.
Låt oss säga att du klockan 23:20 loggar in med en 23:19-kod. Server lagrar ”-1” i sin databas (och om det skulle vara en 23:21-kod, skulle den lagra ”+1” i databasen). Nästa gång du loggar in är klockan 23:40. Då accepterar servern en kod 23:38, 23:39 eller 23:40.Om en 23:38-kod accepteras kommer den att lagra ”-2” i databasen, vid 23:39 kommer den att behålla ”-1” i databasen och vid 23:40 kommer den att lagra ”0” i databasen.
Detta ser till att servern synkroniseras till din token. Utöver detta tillåter systemet omkronisering om en token ”sprang för långt bort” från servern (på grund av att den inte använts under lång tid). Detta åstadkommes antingen av en systemadministratör eller så presenteras en självsynkroniseringstjänst där tokenanvändaren ombeds att tillhandahålla två efterföljande koder från token, som 23:20 och 23:21, eller 19:10 och 19:11. Observera att servern ALDRIG accepterar en token-kod som genererades vid eller före den tidpunkt då ”senast använda token-kod” var (eftersom detta skulle möjliggöra återanvändning av OTP-koder). När en resynkronisering är klar kommer token att lagra skillnaden från de angivna 2 tokenkoderna och den aktuella servertiden och i en resynkronisering kan sökfönstret vara som plus / minus 50 steg (vilket tillåter cirka 0,75 timmar av desync i båda riktningarna).
Servern kan upptäcka en desynkroniserad token genom att generera 50 tidigare koder och 50 framtida koder, och om den angivna koden matchar det kommer den att starta om-synkroniseringsprocessen automatiskt. Många gånger, för att förhindra att en angripare använder resync-processen för att hitta giltiga koder, när ett konto är i resync-läge accepteras inte inloggning utan att synkronisera igen, vilket skulle kräva att angriparen hittar den exakta koden efter eller före koden bara hittades.
Kommentarer
- Coola saker, visste ’ inte om detta.
Svar
SecurID-token har ett ”seed” -värde och är programmerat med en specifik algoritm som genererar siffror baserat på utsäde och dess systemklocka. Utsädesvärdet lagras också i en fil som levereras med token. Efter mottagningen av token importerar systemadministratörer seed-filen till autentiseringsservern. Eftersom SecurID-tokenheten och servern båda har såvärdet, och båda använder algoritmen, kan servern bestämma vilken rätt tokenkod som ska vara vid varje given tidpunkt.
Ibland kan token ”s klockan kan komma ur synkronisering med autentiseringsservern. Om detta händer kan systemadministratörer eller annan auktoriserad supportpersonal hjälpa användaren genom att utföra en omsynkroniseringsprocess på servern. Detta kommer att konfigurera servern för att känna igen tidsförskjutningen för den token så att framtida autentiseringsförsök ska hanteras exakt.
Obs: Eftersom dessa siffror måste vara förutsägbara av servern, baserat på endast de data som är lagrade i seed-filen, aktuell tid och en standardalgoritm, de kan också förutsägas av en angripare med specialverktyg och åtkomst till token. (Eller värre, åtkomst till själva seedfilerna – som misstänks ha hänt 2011 .) Med tanke på tillräckligt många token-koder är det till ol som kan bestämma utsädesvärdet och sedan skapa framtida koder på egen hand.
Svar
Sebastian-svaret var fantastiskt. Jag kommer att återge det i lekmanns termer. SecureID-token är helt enkelt en klocka med ett frövärde i. I stället för att visa tid visar det ett nummer. Punkten i det vi kan se på bilden är sekunder (tror jag), fältet är när numret kommer att ändras så att du kan tid det. Om det når botten är det på väg att ändras och om du skriver det vill du vänta.
” seed ”finns också på servern som verifierar enheten. När säkerhets killar installerar RSA-servern måste de ladda samma frön i servern som kommer att få din pinkod.
Så … I grund och botten är det är ett kryptoklocka. Precis som de gamla LCD-klockorna som mina barn har med dora eller prinsessor på sig. Skillnaden är fröet som ger matematiken för numret.