Jeg har brugt RSA SecureID ® nøgler i nogen tid nu (måske 10 år) til ting som sikkert min hjemmebankekonto online eller få adgang til min firmaets netværk af computere hjemmefra. Disse nøgler genererer et 6-cifret numerisk token, som er indstillet til at udløbe. Jeg har altid spekuleret på, hvordan disse fungerer.
På højre side er der en prik (ikke vist på billedet), der blinker en gang i sekundet, og til venstre er der en stak på seks lodret stablet vandret søjler, som hver forsvinder en gang hvert tiende sekund. Hver gang der er gået tres sekunder, nulstilles tokenet, og det forrige token bliver ugyldigt.
AFAIK bruger disse enheder ikke netværket, og de numre, de genererer, skal kontrolleres af serveren (uanset om serveren er en bank eller en virksomheds server). Derfor skal der inde i denne enhed opbevares en algoritme, der genererer tilfældige tal med en mekanisme, der inkluderer en meget præcis timer, der drives af et lille batteri. Timeren skal være meget præcis, da serveren skal kontrollere gyldigheden af de genererede cifre i det samme tidsinterval. For hver bruger / medarbejder skal serveren, så vidt jeg forstår, gemme den samme algoritme, der genererer tilfældigt antal, med en sådan algoritme pr. Kunde / medarbejder. Chippen skal naturligvis være konstrueret på en sådan måde, at hvis den bliver stjålet, kan angriberen ikke få adgang til den tilfældige talgenererende algoritme, der er gemt deri, selvom enheden er brudt.
Er det sådan, dette fungerer?
Tak!
Kommentarer
- Samme måde TOTP fungerer, bortset fra sidstnævnte behøver du ikke ‘ at købe en overpris løsning og kan bruge almindelige telefoner eller en hvilken som helst enhed, der er i stand til grundlæggende beregning, endda et smartwatch .
- Softwaredefineret OTP er ekstremt dårlig, da du ikke får manipulationsmodstand, der kræves for at få modstand mod kloning af frøet. Alle med et Micro-USB-kabel og de rigtige værktøjer kan klone din telefon inden for < 5 minutter. Hvis dens adgangskode er beskyttet, kan den krypterede klon gemmes, indtil koden kan opnås ved ondsindet software eller skulder-surfing. Nogle telefoner leverer i dag en manipulationsresistent hardware-nøglelager, så det er en god ide at bruge det eller en Security Smart-MicroSD. Det forhindrer frø i at blive ekstraheret, kun ” brugte “. Men ikke-RSA-hardware TOTP-tokens er virkelig billige.
- Relateret: Sådan fungerer RSA-tokens
- @sebastiannielsen at er stadig afhængig af social ingenering eller af brugere, der ikke følger deres ting ordentligt. Hvis jeg kan forbinde brugerens ‘ -telefon til en computer uden at han bemærker det, kan jeg lige så godt stjæle hans RSA-token og sætte en anden på sin plads (og han vandt ‘ t bemærker indtil næste gang han prøver at bruge det, som ville være for sent).
- Værd at linke: Kan numre på RSA SecurID-tokens forudsiges?
Svar
Ja det fungerer som du siger . Chippen er “manipulationsresistent” og sletter “frøet” (hemmelig nøgle), hvis der gøres et forsøg på at angribe det. Dette opnås ofte ved at have et ikke-udskifteligt batteri og en “fælde”, der bryder strøm til enheden, når enheden åbnes, eller chipoverfladen fjernes. Nøglen gemmes derefter i en SRAM, hvilket kræver strøm for at beholde nøglen.
Nøglen er et frø, der kombineres med den aktuelle tid i 60 sekunders trin (effektivt det nuværende UNIX-tidsstempel / 60), opdaterer koden.
Nej, enheden behøver IKKE at være præcis. I stedet gemmer serveren tidspunktet for den sidst accepterede kode. Derefter accepterer serveren en kode et minut tidligere, et minut foran og på det aktuelle tidspunkt, så hvis det aktuelle tidspunkt på serveren er 23:20, accepterer den en kode fra 23:19, 23:20 og 23: 21.
Herefter gemmer det tidspunktet for den sidst accepterede kode, f.eks. Hvis en 23:21-kode blev accepteret, gemmer den 23:21 i en database og nægter at acceptere enhver kode, der blev genereret kl. 23:21 eller tidligere.
Nu til den interessante del: For at forhindre, at et upræcist token desynkroniseres fra serveren, gemmer serveren i sin database, hvis det var nødvendigt at acceptere en 23: 19-kode eller en 23:21-kode kl. 23:20. Dette vil sikre, at serveren ved næste logon korrigerer koden med antallet af trin.
Lad os sige, at du ved ur 23:20 logger ind med en 23:19-kode. Server gemmer “-1” i sin database (og hvis det ville være en 23:21-kode, ville den gemme “+1” i databasen). Næste gang du logger ind, er uret 23:40. Derefter accepterer serveren en 23:38, 23:39 eller 23:40 kode.Hvis en 23:38-kode accepteres, gemmer den “-2” i databasen, 23:39 gemmer den “-1” i databasen, og kl. 23:40 gemmer den “0” i databasen.
Dette sørger effektivt for at holde serveren synkroniseret med dit token. Oven på dette tillader systemet resynkronisering, hvis et token “løb for langt væk” fra serveren (på grund af at det ikke var brugt i lang tid). Dette opnås enten af en systemadministrator, eller der præsenteres en selvservice-resynkroniseringstjeneste, hvor tokenbrugeren bliver bedt om at give 2 efterfølgende koder fra tokenet, som 23:20 og 23:21 eller 19:10 og 19:11. Bemærk, at serveren ALDRIG accepterer en token-kode, der er genereret på eller før det tidspunkt, hvor “sidst anvendte token-kode” var (da dette ville muliggøre genbrug af OTP-koder). Når en resynkronisering er udført, gemmer token forskellen fra de angivne 2 token-koder, og den aktuelle servertid og i en resync, søgevinduet kan være som plus / minus 50 trin (hvilket vil give ca. 0,75 timers desync i begge retninger).
Serveren kan registrere et desynkroniseret token ved at generere de 50 tidligere koder og 50 fremtidige koder, og hvis den angivne kode svarer til det, vil den starte resync-processen automatisk. Mange gange for at forhindre en hacker i at bruge resync-processen til at finde gyldige koder, når en konto er i resync-tilstand, accepteres login ikke uden resynkronisering, hvilket kræver, at angriberen finder den nøjagtige kode efter eller før koden bare fundet.
Kommentarer
- Seje ting, vidste ‘ ikke om dette.
Svar
SecurID-token har en “seed” -værdi tildelt og er programmeret med en bestemt algoritme, der genererer tal baseret på frøet og dets systemur. Frøværdien gemmes også i en fil, der sendes med tokenet. Efter modtagelse af token importerer systemadministratorer seed-filen til godkendelsesserveren. Da SecurID token-enheden og serveren begge har såværdien, og begge bruger algoritmen, kan serveren bestemme, hvad den korrekte tokenkode skal være til enhver tid.
Lejlighedsvis er tokenet “s uret kan komme ud af synkronisering med godkendelsesserveren. Hvis dette sker, kan systemadministratorer eller andet autoriseret supportpersonale hjælpe brugeren ved at udføre en re-synkroniseringsproces på serveren. Dette konfigurerer serveren til at genkende tidsforskydningen for det token så fremtidige godkendelsesforsøg skal håndteres nøjagtigt.
Bemærk: Da disse tal skal kunne forudsiges af serveren, baseret på kun de data, der er gemt i frøfilen, det aktuelle tidspunkt og en standardalgoritme, de kan også forudsiges af en angriber med specielle værktøjer og adgang til tokenet (eller værre, adgang til frøfilerne selv – som mistænkes for at være sket i 2011 .) Givet tilstrækkelige token-koder i træk, er der til ol, der kan bestemme frøværdien og derefter selv generere fremtidige koder.
Svar
Sebastian-svaret var fantastisk. Jeg vil gentage det med lægmand. SecureID-tokenet er simpelthen et ur med en frøværdi i. I stedet for at vise tid viser det et tal. Prikken i det vi kan se på billedet er sekunder (tror jeg), bjælken er, når nummeret skal ændre sig, så du kan få tiden til det. Hvis det når bunden, er det ved at ændre sig, og hvis du skriver det, vil du vente.
” seed “er også på den server, der godkender enheden. Når sikkerhedsgutter installerer RSA-serveren, skal de indlæse de samme frø på den server, der modtager din pinkode.
Så … Dybest set er det er en kryptoklok. Ligesom de gamle LCD-ure, som mine børn har med dora, eller prinsesser på. Forskellen er frøet, der giver matematikken til nummeret.