Hardware authentication tokens

Hardware authentication tokens
Door: Gerben Aalvanger
1.Inleiding
Hardware authentication is begonnen met een opmars. Nadat Google in 2011 als een
van de eerste internetservices de two-step verificatie beschikbaar heeft gesteld, zijn
verschillende grote internetbedrijven (Facebook, Twitter, Dropbox) gevolgd.
Met het gebruik van hardware authentication tokens gaat versleuteling weer terug
naar waar het ooit begonnen is, met fysieke beveiliging van objecten. De sleutel van
vroeger is nu een een stukje hardware. Tegelijk met de terugkeer van het object als
vereiste voor authenticatie blijft in de veelgebruikte two-step verificatie ook de kennis
van een wachtwoord vereist.
In dit paper wordt ingegaan op verschillende vormen van hardware-authenticatie en
de technische aspecten hiervan. Zowel authenticatie met als zonder kennis van een
wachtwoord wordt besproken.
2. Authenticatievormen
Om hardware authenticatie goed te definieeren moet eerst duidelijk geschetst worden
in welke vormen authenticatie voorkomt en op welke van deze vormen
hardwareauthenticatie betrekking heeft.
Authenticatie bestaat uit drie factoren, die op zichzelf of in combinatie gebruikt
kunnen worden als een authenticatiemiddel. De drie factoren zijn allen al bekend sinds
de oudheid, maar worden in dit digitale tijdperk op een heel ander niveau gebruikt.
De eerste authenticatiefactor is kennis, in de oudheid bestond het concept
wachtwoord al. Een Romeinse soldaat komt het legerkamp niet binnen als hij het
geheime wachtwoord niet weet. Tegenwoordig zien wij deze vorm van authenticatie
terug in het invoeren van een wachtwoord voor bijvoorbeeld de mail.
De tweede authenticatiefactor is gebaseerd op persoonlijke eigenschappen. De
Romeinse soldaat uit het voorbeeld zal ook binnen gelaten worden als zijn beste maat
op wacht staat. Hier is namelijk sprake van authenticatie door wie iemand is, in plaats
van wat iemand weet. Deze vorm van authenticatie is erg sterk: een wachtwoord kan
afgeluistert worden, maar in iemands huid kruipen is nog niet zo eenvoudig. Deze
vorm van authenticatie is nu terug te zien in iris-scans of vingerafdrukscans. Op deze
vorm van authenticatie wordt in het vervolg van dit verslag niet verder op ingegaan.
De laatste authenticatiefactor is gebaseerd op bezit. Deze factor is te vergelijken met
de bekende sleutel voor het slot op je voordeur of op je fiets. Hardware authentication
tokens maken altijd gebruik van deze vorm van authenticatie. Two-step verificatie (of:
two-factor authentication) maakt gebruik van de factoren Kennis en Bezit.
3. Werking van hardwareauthenticatie
Hardware authentication tokens kunnen gebruikt worden voor de authenticatie of
identificatie van de gebruiker. Hardware authenticatie maakt altijd gebruik van een
One Time Password (OTP). Het stukje hardware dat voor authenticatie zorgt, maakt
gebruik van een algoritme dat bij elke nieuwe authenticatiepoging een ander
wachtwoord gebruikt.
Dit is belangrijk, omdat een wachtwoord dat altijd gelijk is, eenvoudig nagebootst kan
worden door hackers. Voor het gebruik van een OTP zijn er drie manieren om te
werken met een One Time Password:
1. Mathematisch algoritmisch op vorig wachtwoord
Deze vorm van het genereren van een wachtwoord is als volgt. Het authentication
token heeft een initieele seed, die we s noemen. Na elke keer dat het wachtwoord
wordt gevraagt, wordt over het laatst gebruikte wachtwoord een One-Way functie f
gedaan, die het nieuwe wachtwoord oplevert.
De eerste keer dat het wachtwoord gevraagd wordt, wordt f(s) weergeven, de tweede
keer f(f(s)) enz.
Deze vorm van OTP gebruik wordt in Linux ondersteunt via het S/KEY OTP systeem.
In hardwareauthenticatie komt deze vorm terug bij authenticatiesystemen met RFIDtags
2. Tijdsynchronisatie-mechanisch algoritme
Deze vorm van het genereren van een wachtwoord maakt gebruik van de tijd.
Afhankelijk van het moment in de tijd genereerd dit algoritme een ander wachtwoord.
Deze vorm van OTP authenticatie wordt het meest gebruikt bij hardware
authenticatie.
Een veelgebruikt algoritme hiervoor is TOTP (Time-based One-Time-Password)
algoritme. Dit algoritme is een standaard. TOTP wordt in verschillende 2-factor
authenticatiesystemen gebruikt.
TOTP is afgeleid van HOTP, maar verschilt slechts hierin dat TOTP in plaats van een
counter gebruik maakt van een tijdswaarde.
De tijdswaarde TC is gedefinieerd als (unixtime(now) – unixtime(T0))/TS, Hierbij
wordt gebruik gemaakt van een stapgrootte TS, zodat er een tijdsmarge is waarin het
password geldig is.
Zowel server als client kent een secret key K. Als de Client zich wil identificeren bij de
server, berekend hij de HMAC(K, TC), waarna deze gereduceerd wordt tot 4 bytes.
Van deze vier bytes wordt de eerste bit om praktische redenen altijd op 0 gezet.
De server ontvangt de TOTP-waarde van de client en vergelijkt deze met de TOTP van
zijn TC, ± 1. Dit voorkomt dat een verhoging van de TC tussen verzenden en
ontvangen leidt tot een foutieve login. Bovendien kan het zijn dat de klokken van
server en client niet exact gelijk zijn, dit is nu geen probleem.
Bekende organisaties als Google en Microsoft maken gebruik van TOTP.
KADER: Hoe en waarom werkt HMAC?
In HOTP/TOTP wordt gebruik gemaakt van de HMAC: Hash-based Message
Authentication code. HMAC is een methode om een hash te genereren die zowel
dataintegriteit als authenticatie van een bericht regelt. Voor een webshop die wil
controleren dat de juiste gebruiker de juiste items besteld kan zo'n controlehash
toegevoerd worden, door HMAC(Key, items) te berekenen.
HMAC kan gebruikt worden in combinatie met elke willekeurige hashfunctie, vandaar
dat ook gesproken wordt van specifiek HMAC-MD5 of HMAC-SHA1.
De HMAC-functie is als volgt gedefinieerd:
HMAC (K,m) = H((K XOR opad) | H((K XOR ipad) | m))
Deze functie lijkt overbodig onhandig, omdat een functie
HMAC(K,m) = H(K | m) voldoende lijkt.
Soortgelijke functies blijken echter gevoelig voor length-extention attacks, of ze
hebben andere onveilige plekken. De binnenste hash zorgt voor een maskering van
het tussenresultaat. De opad en ipad zijn constanten, die zorgen voor een verschil
tussen de inner en outer key. Opad en ipad zijn gekozen zodat zij een grote
onderlinge hamming-distance hebben en de keys dus minder op elkaar lijken. De
veiligheid van het algoritme is ook gegarandeerd zonder de opad en ipad.
3. Challenge type OTP
Deze vorm van OTP-generatie is net als de eerste vorm een mathematisch algoritme.
Het wachtwoord dat gegenereerd wordt in challenge-OTP is gebaseerd op een
identiteitsvraag van de server en een tegenvraag van de client.
De server en de client kiezen beide een willekeurig getal sc en cc en kennen beide een
key K. De server stuurt zijn getal naar de client, die antwoord met het sturen van cc
en hash(cc + sc + K). De server kan nu bevestigen dat k juist is, omdat hij cc en sc
weet. De servers stuurt naar de client hash(sc + cc + K), en de client kan bevestigen
dat de server inderdaad kennis heeft van K. Beide systemen weten nu dat ze
communiceren met een geauthenticeerd station.
4. Gebruik van Hardware Authenticatie
Google authenticator, RSA SecurID en de Random Reader van Rabobank maken
gebruik van een vorm van hardware authenticatie. Al deze authenticatiemethoden zijn
verschillend. Om een goed beeld te krijgen van hardware authenticatie worden een
XTAL authenticatievormen hieronder besproken.
Google Authenticator
Met Google Authenticator is behalve een wachtwoord en inlognaam ook het bezit van
een specifieke smartphone nodig. Google Authenticator vraagt eerst om de
logingegevens, daarna stuurt hij een 6-cijferige code, die ingevoerd kan worden op de
site. De 6-cijferige code wordt gegenereerd met behulp van het ingevoerde
wachtwoord en het tijdstip/een teller. Met behulp van HMAC-SHA1 wordt een lange
hash gemaakt, die teruggebracht wordt tot 6 cijfers.
Als het mobiele device gehackt is, zijn man-in-the-middle aanvallen mogelijk op het
systeem van Google Authenticator.
RSA SecurID
RSA SecurID is de marktleider op het gebied van hardware authenticatie. Ongeveer
70% van de hardware authenticatiedevices komt bij RSA SecurID vandaan. RSA
SecurID levert een token, die elke 60 seconden een nieuwe token genereerd,
gebaseerd op tijd en een seed van 64/128 bits.
Deze seed is bekend bij RSA SecurId. Als een gebruiker wil inloggen, voert hij zijn
unieke ID en wachtwoord in en de code die op zijn scherm staat. Via de algemene
database van RSA kan gekeken worden of op dit tijdstip met die seed de juiste code
gegeven is.
In tegenstelling tot Google Authenticator kan een RSA SecurID device niet zomaar
voorzien worden van een trojan, die de code verklapt, daarom is RSA SecurID veiliger
dan Google Authenticator.
De RSA SecureID is in opspraak gekomen, toen de database gehackt is. Een groot
aantal seeds en het algoritme zijn toen buitgemaakt. Hier ligt een groot gevaar van de
hardware authenticatietokens. Als de seeds bekend zijn, is het hele gedeelte van de
hardware niet meer nodig. Nu is enkel het wachtwoord nog geheim. RSA SecureID
maakt gebruik van het principe 'security door obscurity', in plaats van Kerkhoffs'
'veiligheid in de key alleen'. Nu één hacker het algoritme kent, kan hij lekken hierin
zoeken, maar het publiek kan deze niet zoeken om ze te fixen.
Op RSA SecurID is ook verschillende malen kritiek geweest, zo zouden de tokencodes
niet geheel random gegenereerd worden en zouden er teveel collisions zijn.
Random Reader van Rabobank
De Rabobank gebruikt voor internetbankieren ook een hardware authenticatie token.
De random reader van VASCO. In tegenstelling tot de vorige besproken authenticators
heeft deze reader geen unieke seed. De unieke informatie bevind zich allemaal in de
pinpas van de persoon die wil internetbankieren. De pinpas bevat de pincode,
pasnummer en rekeningnummer. Als een transactie plaatsvind, genereert de
transactieserver een willekeurig getal van 8 cijfers. Na invoer van de pincode in de
reader, voert de gebruiker ook deze 8 cijfers en het transactiebedrag in. De reader
genereert nu met behulp van deze informatie en met de huidige tijd een nieuw
nummer, dat ingevoerd moet worden bij de transactie.
Behalve transacties kan ook ingelogd worden bij internetbankieren. Hiervoor hoeft de
gebruiker geen bedrag op te geven, maar wel een gegenereerde code van 8 cijfers op
basis van een random getal en informatie van de kaart. Ook moet dan de pincode
gegeven worden.
Transacties zijn extra beveiligd, omdat de gebruiker niet via een phishingsite meer
geld kan overmaken dan hij denkt te doen. Als een hacker het bedrag wil verhogen,
dan zal dit bedrag ook ingevoerd moeten worden in de random reader. Het exacte
algoritme is niet bekend bij het publiek, ook hier wordt gebruik gemaakt van 'security
door obscurity'.
RFID authenticatie
In tegenstelling tot de andere genoemde authenticatiemiddelen maakt RFID (Radio
Frequency Authentication) geen gebruik van de gebruiker die een numerieke code
moet overbrengen. De RFID-tag zelf zorgt voor de communicatie tussen zichzelf en
het authenticatieplatform. Er wordt onderscheid gemaakt tusssen twee soorten RFIDchips: read-only of read/write. Voor beide vormen van RFID-chips wordt hieronder
een protocol beschreven die de authenticatie afhandeld met behulp van symmetrische
encryptie.
RFID authenticatie is een erg lastig probleem, omdat de draadloze communicatie
afgeluisterd kan worden. Het eerst beschreven protocol zal theoretisch kwetsbaar zijn
in de privacy en in security, het tweede protocol heeft hier praktisch geen last van.
Protocol 1:
Het eerste protocol voor RFID authenticatie maakt gebruik van het in hoofdstuk 3
genoemde mathematische-chaining principe. Het protocol is in 2003 door Ohkubo,
Suzuki en Kinoshita gepubliceerd. Voor het gemak noemen we dit protocol in het
vervolg het OSK-protocol.
Het OSK-protocol kent een station (S) en een tag (T). In de tag is een code si
opgeslagen. Op het moment dat de tag een bericht van een station ontvangt,
antwoord de tag met het opsturen van zijn M = g(si).
De server gaat nu op zijn beurt de hele tabel van mogelijke tags met hun chains af,
om te berekenen welke tag gereageerd kan hebben met dit antwoord. In het geval dat
enkel de eindpunten van de chains opgeslagen zijn, kost dit dus O(mn) tijd, waarbij m
de lengte van de chain is en n het aantal chains.
Een mogelijke oplossing voor deze O(mn) complexiteit is het introduceren van
tussenpunten: als precomputatie berekent een station alle m*n elementen en slaat
van elke chain een aantal tussenpunten op. Met het gebruik van deze lookup table kan
een complexiteit van O(n) bereikt worden ten koste van opslaggeheugen in het
station. (Avoine and Oechslin)
Het OSK-protocol heeft nog enkele tekortkomingen: een tag kan afgeluisterd worden
en vervolgens kan de reactie van de tag geimiteerd worden en op deze manier kan
authenticatie verkregen worden. Dit probleem wordt opgelost door een aanpassing
aan te brengen in het protocol, hierbij wordt een random challenge toegevoegd,
waarbij nu M = g(si XOR r) geld. Nu kan de tag enkel geimiteerd worden met een
gelijke challenge.
Het grote voordeel van dit OSK-protocol is het feit dat een bezitter van een RFID-tag
niet getraced kan worden doordat hij voortdurend antwoord met zijn
identificatienummer. In plaats hiervan antwoord hij telkens met een nieuwe waarde uit
zijn hashchain. Deze waarde kan niet zonder bijkomende kennis tot een specifieke
RFID-tag teruggebracht worden.
Protocol 2
Het tweede protocol is een stuk geavanceerde dan het eerst beschreven protocol. In
dit protocol heeft de tag slechts één waarde opgeslagen, van tag i is dit ti.
Doordat ti wisselt per geslaagde check-in poging, is de privacy gewaarborgd.
Daarnaast geldt dat de authenticatie van zowel server als clientside gedaan wordt. Dit
gebeurt doordat challenges over en weer gestuurt worden, die de ander dient te
beantwoorden. Berichten kunnen geblokkeerd worden door een DoS aanval, maar
omdat de server ook de oude waarden van si en ti onthoud, zal dit geen probleem zijn.
In tegenstelling tot de eerder besproken hardware authenticatiemethoden wordt RFID
authenticatie niet gebruikt met 2-factor authenticatie. Hierin vervangt de RFID dus
helemaal de authenticatie, in plaats dat het een extra laag authenticatie levert. In het
volgende hoofdstuk zal een apart gedeelte komen met gevaren voor RFID
authenticatie, omdat hierin veel valkuilen zitten.
5. Gevaren in Hardware Authenticatie
Hardwareauthenticatie heeft verschillende gevaren in zich. Omdat
hardwareauthenticatie in veel gevallen samen gaat met het bekende passwordauthenticatiesysteem, zijn verschillende gevaren van hardwareauthenticatie
voorkomen. Te denken valt aan het stelen van het hardwaredevice. De toegang is op
dat moment nog volledig toegesloten voor de dief. Voor RFID-tags geld dit echter niet,
daarom zal in dit hoofdstuk apart ingegaan worden op 2-factor authenticatiegevaren
en RFID-authenticatiegevaren. In dit laatste deel zal ook rekening gehouden worden
met het versturen van data over een onderschepbaar medium en met het simuleren
van het zijn van een geldig serverstation. Allereerst zal de veiligheid van een stuk
hardware zelf onder de loep genomen worden: kan hardware nagebootst worden of
uitgelezen worden?
Aanvallen op de hardware
Voor een smartcard zoals deze gebruikt word voor je pinpas en je simkaart is een
stevige beveiliging nodig om indringers buiten te houden. Een smartcard bevat
geheugen cpu en contactpunten. Een indringer heeft er belang bij om te weten hoe
een smartcard exact in elkaar zit. Helaas voor de eenvoudige indringer: een smartcard
is 'tamper resistant', resistent tegen 'tampering', indringers. Een 'tamper resistant'
smartcard valt echter niet te bestempelen als 100% veilig. Er bestaan technieken om
met behlp van zuren en andere chemische stoffen toegang te krijgen tot het CPU.
Daarnaast zou met differential power analysis gemeten kunnen worden wat de private
key van de versleuteling is. Zulke zware aanvallen zijn echter niet heel realistisch.
Ook RSA SecurID claimt dat zijn tokens tamper resistant zijn. Ook RFID Tags kunnen
tamper resistant zijn. Door tamper resistance kan een eenvoudige aanval op de
hardware afgeslagen worden. Een onderdel van tamper resistance is vaak het selfdestruction: als een poging gedaan wordt om iets uit te lezen, vernietig je de kaart
zelf ook.
2-factor authenticatiegevaren
Het meest voor de hand liggende gevaar van de 2-factor authenticatie is het
kwijtraken van je hardware token. Dit heeft niet automatisch een ongeoorloofde
authenticatie van de vinder van het token tot gevolg. Op dat moment houd de
password protected tweede laag van authenticatie de inbreker tegen. Een reeël gevaar
van de 2-factor authenticatie zijn de phishingsites. Een gebruiker die niet goed oplet
en raobank.nl ipv rabobank.nl intoetst in zijn browser kan zomaar op een phishingsite
terecht komen. Als de gebruiker een transactie denkt te doen bij de rabobank, kan
deze transactie in werkelijkheid door de phisher gecontroleerd worden. De aanvallen
die dit ook kunnen zijn 'man-in-the-middle', 'man-in-the-browser' en keyloggers.
Ondanks deze aanvallen is 2-factor authentication niet nutteloos, verschillende
aanvallen kunnen worden afgeslagen door middel van 2-factor authentication. Te
beginnen bij het simpele wachtwoord aflezen. Daarnaast moeten de genoemde
aanvallen geavanceerder zijn dan wanneer er geen gebruik gemaakt wordt van 2factor authentication.
RFID-authenticatiegevaren
RFID authenticatie heeft verschillende gevaren, deze zitten in de privacy en in de
security.
Wat betreft privacy is het van belang dat er geen informatie van de gebruiker uit de
tag lekt en dat de tag niet achtervolgt kan worden. Het is niet de bedoeling dat
iemand weet dat jij met je RFID-tag elke dag om 12 uur incheckt.
Wat betreft de security zijn er een zes verschillende gevaren. Dit zijn:
– Iemand kan zich voordoen alsof hij jou tag is, zonder dat hij je communicatie
ziet
– Iemand kan aan de hand van eerdere authenticaties een succesvolle
authenticatie doen
– Iemand kan berichten vervormen
– Iemand kan met een DoS berichten blokkeren
– Iemand kan voorspellen/achterhalen wat er gebeurt (is) met jouw tag na het
zien van één of meerdere communicaties
– Iemand kan zich voordoen als een server/station
Deze zes gevaren worden allen opgevangen door het tweede beschreven RFIDprotocol. Het eerste protocol kan met zijn aanpassing redelijk goed overweg met deze
zaken, maar de laatste twee gevaren kunnen niet voorkomen worden met dit eerste
protocol. Het protocol is dan ook ontwikkeld voor de privacy en is minder gericht op
veiligheid.
Daarnaast is het gevaarlijk dat een RFID-token gestolen kan worden, op dat moment
moet in de server aangegeven kunnen worden dat een token niet meer voldoet, deze
moet eenvoudig gewist kunnen worden uit de database. Dit is echter geen groot
probleem, de tijd tussen verdwijnen van de tag en het wissen van de token is echter
wel een probleem.
6. Samenvatting
Hardware authentication tokens werken niet op een heel eenvoudige manier en veel
bedrijven die authenticatie tokens leveren, vertellen hun algoritme niet uit
veiligheidsoverwegingen. Met behulp van one time passwords geeft een hardware
authentication token een hogere veiligheid dan een gewoon
wachtwoord/gebruikersnaam combinatie. Met behulp van het TOTP van Google
Authenticator kan veilig ingelogd worden, mits de app veilig is op de smartphone van
de gebruiker. RFID authenticatie bevat naast authenticatiegevaren ook gevaren in de
privacy, hiervan hebben we een protocol beschreven. Smardcards zijn tamperresistant gemaakt, om het uitlezen van de hardware onmogelijk te maken.
7. Bronnen:
[1] OWASP: testing multiple factor authentication
[2] Gildas Avoine and Philippe Oechslin, A Scalable and Provably Secure Hash-Based RFID
Protocol
[3] Boyeon Song, RFID Authentication Protocols using Symmetric Cryptography
[4] Mudge and Kingpin, Initial Cryptanalysis of the RSA SecurID Algorithm
[5] Smart Card Alliance, Strong Authentication Using Smart Card Technology for Logical Access
[6] Google, Google Authenticator, Google.code
[7] Wikipedia, One Time Password
[8] IETF, TOTP: Time-Based One-time Password Algorithm
[9] IETF, HOTP: Keyed-Hashing for Message Authentication

Download Report