Jeg har brukt RSA SecureID ® -taster i ganske lang tid nå (kanskje 10 år), for ting som å sikre min hjemmebankonto online eller få tilgang til selskapets nettverk av datamaskiner hjemmefra. Disse tastene genererer et 6-sifret numerisk token som er satt til å utløpe. Jeg har alltid lurt på hvordan disse fungerer.
På høyre side er det en prikk (ikke vist på bildet) som blinker en gang i sekundet, og til venstre er det en stabel med seks loddrett stablet horisontale barer, som hver forsvinner en gang hvert tiende sekund. Hver gang seksti sekunder har gått, nullstiller tokenet seg selv, og det forrige token blir ugyldig.
AFAIK disse enhetene bruker ikke nettverket, og tallene de genererer må kontrolleres av serveren (enten serveren er en bank eller en bedrifts server). Derfor må det i denne enheten være lagret en algoritme som genererer tilfeldige tall med en mekanisme som inkluderer en veldig presis tidtaker drevet av et lite batteri. Timeren må være veldig presis, siden serveren må sjekke gyldigheten til de genererte sifrene i det samme tidsintervallet. For hver bruker / ansatt må serveren, så vidt jeg forstår, lagre den samme tilfeldige tallgenererende algoritmen, med en slik algoritme per kunde / ansatt. Brikken må selvfølgelig konstrueres på en slik måte at hvis den blir stjålet, kan angriperen ikke få tilgang til den tilfeldige tallgenererende algoritmen som er lagret der, selv om enheten er ødelagt.
Er dette hvordan dette fungerer?
Takk!
Kommentarer
- På samme måte TOTP fungerer, bortsett fra sistnevnte, trenger du ikke ‘ å kjøpe en for dyr løsning og kan bruke vanlige telefoner eller en hvilken som helst enhet som er i stand til grunnleggende beregning, til og med et smartklokke .
- Programvaredefinert OTP er ekstremt dårlig siden du ikke får manipulasjonsmotstand, som er nødvendig for å få motstand mot kloning av frøet. Alle med en Micro-USB-kabel og de riktige verktøyene kan klone telefonen din på < 5 minutter. Hvis det er passordbeskyttet, kan den krypterte klonen lagres til koden kan oppnås ved skadelig programvare eller surfing på skulderen. Noen telefoner gir i dag en manipuleringsbestandig maskinvarenøkkelbutikk, så det er en god ide å bruke det, eller en Security Smart-MicroSD. Som forhindrer at frøet blir ekstrahert, brukte bare » «. Men TOTP-tokens som ikke er RSA-maskinvare er veldig billige.
- Relatert: Hvordan RSA-tokens fungerer
- @sebastiannielsen at er fortsatt avhengig av sosial ingenering eller av brukere som ikke passer på tingene sine ordentlig. Hvis jeg kan koble brukerens ‘ -telefon til en datamaskin uten at han legger merke til det, kan jeg like godt stjele hans RSA-token og sette en annen på plass (og han vant ‘ ikke legg merke til neste gang han prøver å bruke det som ville være for sent).
- Verdt å koble til: Kan tall på RSA SecurID-tokens blir forutsagt?
Svar
Ja, det fungerer som du sier . Brikken er «tåleresistent» og vil slette «frøet» (hemmelig nøkkel) hvis det blir gjort noe forsøk på å angripe den. Dette oppnås ofte ved å ha et ikke-utskiftbart batteri og en «felle» som bryter strøm til enheten når enheten er åpnet, eller chip-overflaten er fjernet. Nøkkelen blir deretter lagret i en SRAM, og krever strøm for å beholde nøkkelen.
Nøkkelen er et frø som kombineres med gjeldende tid i 60 sekunders trinn (effektivt den nåværende UNIX-tidsstemplet / 60), oppdaterer koden.
Nei, enheten trenger IKKE å være presis. I stedet lagrer serveren tiden for den sist aksepterte koden. Deretter vil serveren akseptere en kode ett minutt tidligere, ett minutt foran og på det nåværende tidspunktet, så hvis den nåværende tiden på serveren er 23:20, vil den akseptere en kode fra 23:19, 23:20 og 23: 21.
Etter dette vil den lagre tiden for den siste aksepterte koden, f.eks. Hvis en 23:21-kode ble akseptert, vil den lagre 23:21 i en database, og nekte å akseptere en kode som ble generert kl. 23:21 eller tidligere.
Nå til den interessante delen: For å forhindre at et upresist token desynkroniseres fra serveren, vil serveren lagre i sin database hvis det var nødvendig å godta en 23: 19-kode eller en 23:21-kode 23:20 tid. Dette vil sikre at serveren vil korrigere koden med antall trinn ved neste pålogging.
La oss si deg klokke 23:20 pålogging med en 23:19-kode. Server lagrer «-1» i databasen sin (og hvis det ville være en 23:21-kode, vil den lagre «+1» i databasen). Neste gang du logger inn, er klokken 23:40. Da vil serveren godta en kode 23:38, 23:39 eller 23:40.Hvis en 23:38-kode aksepteres, vil den lagre «-2» i databasen, kl. 23:39 vil den beholde «-1» i databasen, og klokka 23:40 vil den lagre «0» i databasen.
Dette sørger effektivt for å holde serveren synkronisert med tokenet ditt. På toppen av dette tillater systemet resynkronisering, hvis et token «løp for langt bort» fra serveren (på grunn av at det var ubrukt i lang tid). Dette oppnås enten av en systemadministrator, eller det presenteres en selvbetjening-resynkroniseringstjeneste der tokenbrukeren blir bedt om å gi 2 påfølgende koder fra tokenet, som 23:20 og 23:21, eller 19:10 og 19:11. Merk at serveren ALDRI vil godta en token-kode generert på eller før tidspunktet som «sist brukte token-kode» var (da dette ville tillate gjenbruk av OTP-koder). Når en resynkronisering er ferdig, vil token lagre forskjellen fra de angitte to tokenkodene, og den aktuelle servertiden og i en resynkronisering, søkevinduet kan være som pluss / minus 50 trinn (som vil tillate omtrent 0,75 timer med desync i begge retninger).
Serveren kan oppdage et desynkronisert token ved å generere 50 tidligere koder og 50 fremtidige koder, og hvis den spesifiserte koden samsvarer med det, vil den starte resynkroniseringsprosessen automatisk. Mange ganger, for å forhindre at en angriper bruker resynkroniseringsprosessen for å finne gyldige koder, vil ikke innlogging aksepteres uten resynkronisering når en konto er i resynkroniseringsmodus, noe som krever at angriperen finner den nøyaktige koden etter eller før koden bare funnet.
Kommentarer
- Kule ting, visste ikke ‘ om dette.
Svar
SecurID-tokenet har en «seed» -verdi, og er programmert med en spesifikk algoritme som genererer tall basert på frøet og dets systemklokke. Frøverdien lagres også i en fil som sendes med tokenet. Ved mottak av token importerer systemadministratorer seed-filen til godkjenningsserveren. Siden SecurID-token-enheten og serveren begge har såverdien, og begge bruker algoritmen, kan serveren bestemme hva den riktige token-koden skal være til enhver tid.
Noen ganger kan tokenet s klokken kan komme ut av synkronisering med autentiseringsserveren. Hvis dette skjer, kan systemadministratorer eller annet autorisert supportpersonell hjelpe brukeren ved å utføre en resynkroniseringsprosess på serveren. Dette vil konfigurere serveren til å gjenkjenne tidsforskyvningen for det tokenet slik at fremtidige godkjenningsforsøk skal håndteres nøyaktig.
Merk: Fordi disse tallene må være forutsigbare av serveren, bare basert på dataene som er lagret i seed-filen, gjeldende tid og en standardalgoritme, kan også forutsies av en angriper med spesialverktøy og tilgang til tokenet. (Eller verre, tilgang til frøfilene selv – som mistenkes å ha skjedd i 2011 .) Gitt nok påfølgende token-koder, det er det ol som kan bestemme frøverdien og deretter generere fremtidige koder på egenhånd.
Svar
Sebastian-svaret var kjempefint. Jeg vil gjenta det i lekmannens termer. SecureID-token er ganske enkelt en klokke med en kjerneverdi i. I stedet for å vise tid viser det et tall. Punktet i det vi kan se på bildet er sekunder (tror jeg), linjen er når nummeret skal endres slik at du kan sette det på tid. Hvis det når bunnen, er det i ferd med å endre seg, og hvis du skriver det inn, vil du vente.
» seed «er også på serveren som autentiserer enheten. Når sikkerhetsgutta installerer RSA-serveren, må de laste de samme frøene inn i serveren som mottar PIN-koden din.
Så … I utgangspunktet er en kryptoklokke. Akkurat som de gamle LCD-klokkene som barna mine har med dora, eller prinsesser på. Forskjellen er frøet som gir matematikken for tallet.