Ik heb je verhaal een paar keer gelezen - maar is dat niet altijd zo.

Je staat op punt A (fysiek) en je wil verbinding met punt B.
Je maakt contact via een device op punt A met een device op punt B

1. Je meldt je aan met Username/Password (iets dat je weet)
Je bent dus nu op de Server bij B maar om verder te kunnen heb je dus optie 2 ook nodig !!
2. Vervolgens bevestig je met een biometrisch kenmerk of een token (code uit een apparaatje of een tancode, chipkaart o.i.d.)
(iets dat je hebt)

Als 1. gecomprimeerd is moet je altijd 2. nog hebben om verder te kunnen komen.
Als je 2 ook kwijt bent (in geval van token) ja dan heb je pech.

Jouw UITSLUITEND valt of staat dus bij hoe jij me je spullen omgaat.

Als ik jou mijn PinPas meegeef om te pinnen omdat ik in het ziekenhuis lig en ik geef je mijn Code dan kun jij voor mij pinnen. Dan ben ik dus NIET de enige die kan pinnen.

In geval van biometrische beveiliging heb je wat meer zekerheid echter ik kan me een aflevering van Mythbusters (Discovery) herinneren waarin ze een vingerafdruk met succes hebben gekopieerd en ge(mis)bruikt.

Het is in ieder geval en stuk beter dan one -factor-authenticatie

secureId is een time based token systeem. dus..

2-factor authenticatie is niet waterdicht, het is alleen een extra beveiligingslaag. Er zijn helaas een aantal verschillende technische uitwerkingen van 2-factor authenticatie die qua veiligheid erg van elkaar verschillen. Wat je hier beschrijft is een software-token op een "open" device. Hierdoor is het inderdaad een stuk makkelijker om de seed (private key) te achterhalen en te dupliceren. Als je dan ook nog het bijbehoren wachtwoord (pin) weet af te vangen dan ben je inderdaad relatief eenvoudig door de beveiliging heen (Niet zo eenvoudig als met 1-factor authenticatie, maar toch). Hardware tokens zijn per definitie veiliger omdat het veel moeilijker is de secret key daar uit te halen en te dupliceren. Zolang je echter het bijbehorende wachtwoord op een "open" systeem invult blijf je kwetsbaar voor het afluisteren daarvan en hoeft men alleen nog je token te stelen om toegang te krijgen. Een stapje verder gaan de challenge response hardware tokens zoals banken in nederland die gebruiken. Hier bestaat je token uit de pasreader in combinatie met je pinpas. Doordat je je pincode hier niet op een "open" systeem (PC) invoert maar op het token zelf is het risico dat dit wordt afgevangen nihil. Op het "open" systeem worden dan alleen one-time-passwords gebruikt. Als je dit systeem wilt kraken kan dat alleen in realtime terwijl jij zelf bezig bent met authenticeren. Hiervoor moet je "open" systeem bijna geheel onder controle van de aanvaller staan zonder dat je dit doorhebt.
Een software token is dus niet per definitie slecht maar wel minder veilig als een hardware token. Het is aan RSA om dit duidelijk te maken aan hun klanten. (mijn ervaring is dat ze dat ook doen). Uiteindelijk maakt de klant een afweging tussen veiligheid, kosten en gebruiksgemak. (een autofabrikant verkoopt ook modellen in verschillende veiligheidsklassen)

Het probleem van de huidige pinpas is dat, terwijl jij deze in je bezit hebt en je niet bewust bent van malversaties, iemand ergens, met een identieke kopie van jouw pas, geld van jouw rekening kan halen. De oorzaak daarvan is dat de gegevens op de (nog steeds gebruikte) magneetstrip eenvoudig gekopieerd kunnen worden, zonder dat je je daarvan bewust bent (skimmen). Om dat kopieeren te voorkomen (in elk geval bemoeilijken) gaan we over naar passen met een chip erin.

De kracht van de losse (fysieke) SecurID pincode generatoren is dat men daarop geen software naar keuze kan installeren, er geen sprake is van (netwerk-) connectiviteit met wat voor andere devices dan ook en er geen enkele reden zou moeten bestaan om zo'n ding uit te lenen (in veel gevallen zal de gebruiker daarvoor moeten tekenen).

De stap die RSA maakt door SecurID als software applicatie op Android uit te brengen kun je m.i. vergelijken met het vervangen van passen met chip door passen met magneetstrip.

Het verschil tussen zo'n hardware token en een software-oplossing is dat de "seed", d.w.z. de unieke code die de gebruiker (feitelijk het device) identificeert, in het geval van zo'n hardware token verankerd is in die hardware, terwijl je deze bij software oplossing zelf op je smartphone moet invoeren.

Bij het genereren van een token zal die seed ongetwijfeld met een timestamp gehashed worden (om replay attacks te voorkomen), maar die functionaliteit is hetzelfde in beide oplossingen.

Het gaat mij erom dat een aanvaller, die jouw seed kan kopiëren, op elke Android smartphone de functionaliteit van jouw token kan klonen.

Dat spat er, in elk geval in de aankondiging, nog niet vanaf. Ik ben benieuwd...

RSA heeft al tijden software based tokens voor o.a. windows en blackberry maar ook symbian OSX en Iphone.
Het is dus niet iets nieuws maar (zoals ik al aangaf in mijn post van 10:18 op 15-12) inderdaad wel iets minder veilig dan een hardware token om de reden die Bitwiper aangeeft.

Voor de berekening van een RSA secureID tokencode wordt zowel het serienummer (ook software tokens hebben een serienummer) als de seed (private key) als de tijd gebruikt. Je hebt echter wel de mogelijkheid om "device binding" te gebruiken zodat een seedfile gekoppeld wordt aan een specifiek device. (bij windows bv de SID)
Hierdoor wordt het veel moeilijker iets met een gekopieerde seed te doen omdat je ook de unieke op door het softwaretoken gegenereerde en op de hardware gebaseerde devicecode moet weten te faken op een ander device.
De aanvaller hierdoor geen gebruik meer maken van alleen de standaard RSA software voor het genereren van de tokencode op een ander device. Die software zal de seedfile namelijk niet accepteren omdat het deviceid niet overeenkomt.

Verder kan er een wachtwoord worden gezet op de seedfile zodat je ook dit wachtwoord moet hebben om de seedfile te kunnen importeren.

Als laatste kun je gebruik maken van dynamic seed provisioning waarbij een geëncrypte seedfile naar je device wordt gestuurd en je via een side channel een eenmalig geldige activatiecode krijgt.
De geëncrypte seedfile kan dan worden geïmporteerd in het softwaretoken waarna de key via een device fingerprint aan het device gekoppeld wordt en geëncrypt. De seedfile zelf kan daarna niet meer worden gebruikt.

Zoals je ziet zijn er allerlei ingebouwde methoden die je kunt gebruiken om de beveiliging van software tokens toch erg dicht in de buurt van hardware tokens te krijgen.

Groet,
Een security officer bij een RSA SecureID gebruikende overheidsorganisatie.

Dank voor jouw reactie! Dat al die devices werden ondersteund wist ik niet toen ik de Android app aankondiging las. Ik heb erover geschreven omdat ik het een slecht plan vind en er zo snel nergens kritische geluiden over kon vinden (zojuist vond ik die wel, onderaan http://en.wikipedia.org/wiki/SecurID vond ik een link naar http://securology.blogspot.com/2007/11/soft-tokens-arent-tokens-at-all.html).

Ik hou het op aanzienlijk minder veilig, en m.i. hooguit geschikt voor toepassingen waarbij net ietsje meer veiligheid gevraagd wordt dan uitsluitend een wachtwoord.

De methodes die je aangeeft waren vele jaren geleden al gangbaar bij kopieerbeveiligingen en werden toen en masse gekraakt. Dat gebeurde meestal door de betreffende software te reverse-engineeren en bijv. de routine, die alleen "true" teruggeeft als de actuele hardware-karakteristieken overeenkomen met een eerder daarvan gemaakte hash, zo aan te passen dat deze altijd true teruggeeft. Natuurlijk kun je dat weer bemoeilijken door digitale handtekeningen onder apps te checken, maar mensen plegen smartphones te jail-breaken en bovendien blijken beveiligingen in de praktijk niet waterdicht (zie bijv. http://blogs.rsa.com/curry/disruptor-user-driven-it-mobile-rises-up/ van, notabene, RSA zelf).

Verder noem je het versleutelen van gegevens: tenzij de gebruiker elke keer een wachtwoord moet invoeren om een seed o.i.d. vrij te geven, zal de decryptiesleutel ergens bereikbaar voor de applicatie moeten zijn opgeslagen. Natuurlijk kun je het terugvinden van zo'n sleutel flink lastig maken middels obfuscatie, maar ook hier zal een vastberaden aanvaller, gebruik makend disassemblers en debuggers, zijn weg wel weten te vinden.

Ter vergelijking: voor NT4 (en later voor W2k, XP en W2k3) heeft Microsoft de SysKey utility gemaakt waarmee de "SAM" password database wordt versleuteld (zie http://support.microsoft.com/kb/310105/). De sleutel daarvoor kun je naar keuze:
1) tijdens het opstarten van het systeem intikken;
2) of tijdens het opstarten van het systeem vanaf een floppy laten inlezen;
3) of middels een "complex obfuscation algorithm" (aldus http://support.microsoft.com/kb/143475/) op je harde schijf zetten.
Dat de sleutel-onder-de-deurmat methode 3) vanzelfsprekend gekraakt kan worden kun je o.a. hier lezen: http://s-t-d.org/mirrors/syskey/syskey.txt.

Om de SecurID-in-software technologie betrouwbaarder te kunnen laten werken, zouden smartphones van een chip moeten zijn voorzien waar je, write-only, een unieke code in wegschrijft. Tevens moet die chip zelf van buiten komende informatie (zoals een timestamp), samen met de unieke code, secure kunnen hashen, zodat die unieke code de chip nooit hoeft te verlaten.

Helemaal safe is het dan nog steeds niet, want het is denkbaar dat een trojan op je smartphone op afstand wordt bestuurd en jouw smartphone vraagt zo'n one-time-password te genereren, om deze vervolgens naar de aanvaller terug te sturen. Die hoeft dan alleen nog maar jouw wachtwoord te kennen, wat natuurlijk niet zo moeilijk is als je dat eerder invoerde op diezelfde gecompromitteerde smartphone...

Als je een los token hebt (zo'n fob) is het inloggen misschien wel veiliger, maar als je PC van een trojan is voorzien (die kans is volgens mij nog steeds een stuk groter dan bij een mobieltje/smartphone) kan de hackert ook meekijken met wat je doet e.d. Volgens mij is dat makkelijker dan het stelen/hijacken van je seed op je mobiel.

Je hebt gelijk dat de eerste aandacht naar de gebruikte PC moet gaan, maar tokens worden normaal gesproken niet uitgedeeld aan mensen die onveilige PC's gebruiken om zich aan te melden.

Feitelijk kun je stellen dat een token geen extra zekerheid biedt als de PC die men gebruikt om aan te melden gecompromitteerd is; een veilige PC is dus gewoon een voorwaarde. Als daaraan is voldaan (bijv. doordat vanaf de PC of laptop geen directe internet-toegang mogelijk is, maar uitsluitend een VPN naar de zaak), dan spelen mijn bovenstaande argumenten wel een rol, en dat zijn ook de scenario's waar je m.i. niet op een software token zou moeten vertrouwen.

Daarnaast ben ik het met RSA eens (zie http://blogs.rsa.com/curry/disruptor-user-driven-it-mobile-rises-up/) dat het niet de vraag is of smartphones serieuze targets voor malwaremakers zullen worden, maar wanneer. Smartphones zijn nauwelijks geschikt om serieuze beveiligingssoftware te draaien (die trouwens niet werkt tegen targeted attacks), dus bijna niemand doet dat, en gebruikers lijken eerder dan met hun PC/laptop openbare WiFi (en bluetooth) netwerken te vertrouwen.

Ten slotte is bijv. het patchbeleid voor Windows Mobile non-existent (zie http://www.security.nl/artikel/34699/1/WinMobile_update_werkt_niet%3F.html) terwijl SecurID software ook voor dat platform beschikbaar is (zie http://www.rsa.com/node.aspx?id=2571); ik ben benieuwd of de bugs die Coverity in Android vond en naar verluidt in januari zal publiceren (zie http://www.eweekeurope.co.uk/news/serious-security-bugs-found-in-android-kernel-11040), voor die tijd gepatched zullen zijn.

@Bitwiper, Goede inhoudelijke discussie hier!
Als het software token op de juiste manier wordt gedistribueerd (bv met dynamic seed provisioning) en gebruikt (inderdaad door het decrypten van de seed met een wachtwoord te beveiligen) kunnen de kwetsbaarheden die jij schetst slechts worden uitgebuit door eerst het tokenpassword (pin) te stelen via bijv malware op het device en daarna het device zelf te stelen. Zolang de seedfile zelf niet op het device achterblijft na het importeren in het software token zal namelijk eerst de encryptie van de seed gekraakt moeten worden voordat de seed kan worden gekopieerd.

Dat tokens slechts worden uitgedeeld aan mensen die veilige PC's gebruiken lijkt me een heel gevaarlijke veronderstelling. Vanwege het eenmalig karakter van de wachtwoorden zijn tokens (OTP's) juist bij uitstek geschikt voor gebruik op onvertrouwde PC's (dat geldt echter niet voor software tokens). Bij software tokens is het dus zaak je device veilig te houden door bijv geen app installaties toe te staan en alle verbindingen via een bedrijfsproxy met malware scanning te laten lopen.

Dat gebruikers een manier kunnen vinden om daar omheen te komen door te rooten/jailbreaken etc. is in mijn optiek een ander risico dat op andere wijze (bewustwording / sancties) aangepakt moet worden. Software tokens verstrek je dus alleen aan vertrouwde medewerkers voor gebruik op vertrouwde devices. Als je medewerkers op de hoogte zijn van de regels m.b.t. het gebruik van de tokens en je kunt ze daarin niet in enige mate vertrouwen kun je ze beter ontslaan en anderen aannemen :-)

De conclusie is volgens mij dus dat de mate van veiligheid van software tokens afhangt van de implementatie en het gebruik. Tot slot een kleine illustratie van hoe je een hardware token onveilig maakt :-) http://cyberiapc.com/forums/index.php?showtopic=8772