RSA neemt meer beveiligingsmaatregelen na SecurID-hack

Nadat hackers in maart informatie over de werking van SecurID-sleutelgenerators hebben buitgemaakt, biedt RSA bepaalde bedrijven aan om de sleutelgenerators uit voorzorg te vervangen. Tegelijk zegt RSA in de tokens te blijven geloven.

RSA biedt bepaalde bedrijven met een gecentraliseerde groep gebruikers de mogelijkheid om hun SecurID-sleutelgenerators te vervangen. Bedrijven met een grotere, gedecentraliseerde gebruikersgroep kunnen ook aanvullende bescherming krijgen, waarbij aan risicomanagement wordt gedaan. Wat deze aanvullende bescherming precies inhoudt, is onduidelijk.

Met de actie lijkt RSA toe te geven dat er problemen zijn met zijn SecurID-sleutelgenerators, al zegt het bedrijf dat zelf niet met zoveel woorden. Het zegt tegemoet te willen komen aan bedrijven die geen risico willen nemen. RSA zegt zelf nog achter SecurID te staan.

In maart werden de servers van RSA gehackt, waarbij informatie over de werking van de sleutelgenerators werd buitgemaakt. Deze buitgemaakte informatie werd volgens RSA gebruikt in een aanval op de systemen van defensiebedrijf Lockheed Martin. Het is echter nog altijd onduidelijk welke informatie over de werking van de SecurID-tokens is buitgemaakt.

De SecurID-apparatuur wordt gebruikt om elke dertig seconden een nieuwe rsa-sleutel te genereren, die door middel van een tweetraps-authenticatieproces beveiligde internetverbindingen moet opleveren. De codes kunnen ook met software worden gegenereerd. RSA Security, een dochteronderneming van EMC, heeft ten minste 40 miljoen hardwarematige en 250 miljoen softwarematige SecurID-producten in omloop.

Reacties (34)

[PPie]

Het is echter nog altijd onduidelijk welke informatie over de werking van de SecurID-tokens is buitgemaakt.

Ik zie 2 dingen die interessant en daarmee vervelend zijn:

• Bekend zijn van het algorithme, zodat met een klein aantal afgelezen/onderschepte codes de volgende berekend kan worden.
• Conversiesleutel van serienummer achterop een hardware device naar de interne seedgetallen, hiermee kan iedere softwarematige token iedere ander (hardware) token emuleren, na 1 x iemands token gezien te hebben.

Iemand nog een andere optie?

[The Van]

Niet een andere optie, maar het bekend zijn van het algoritme is eerder een voordeel - zie mijn motivatie boven.
Een wiskundige kan zwakheden in een algoritme blootleggen, voordat deze in gebruik genomen wordt. Deze dame deed dat al in 2004, bijvoorbeeld. Een link naar de statistische "botsingen" is hier

[thewiseman]

Ik heb nog een article gevonden waaruit blijkt dat alle tokens van RSA virtueel vervangen worden.


http://arstechnica.com/se...ica+-+Featured+Content%29

[Jeroen]

Als er informatie is buitgemaakt en deze succesvol in een aanval is gebruikt dan lijkt me ook wel dat je kunt stellen dat de veiligheid van het systeem op zijn minst verminderd is. Tegelijk zou ik dat ook niet groots aankondigen, want dan ontstaat overal paniek. Hopelijk komen ze er mee weg door langzaam alles te vervangen voordat er veel wordt aangevallen.

[TDeK]

Als ze een succesvolle aanval uit kunnen voeren aan de hand van de buitgemaakte informatie, dan stelt de gebruikte methode sowieso niks voor. Iedereen kan de werking van SSL, (3)DES, AES enz. inzien terwijl dat niets af doet aan de veiligheid ervan. Dat RSA nu dus toch een grote campagne op touw zet om de readers te vervangen doet mij vermoeden dat ze wellicht iets te veel op 'security through obscurity' hebben geleund.
Edit: stukje achtergrondinfo over de aanval zelf: bron.
Edit2: PPie heeft een goed punt mbt. de serienummers die onderdeel zijn van het algoritme.

[Reactie gewijzigd door TDeK op 23 juli 2024 05:46]

[Thralas]

Je vergeet hier een belangrijk aspect van Kerckhoffs' principle. Alle informatie met betrekking tot het cryptosysteem kan openbaar zijn, zonder dat hierdoor de veiligheid in het geding komt. De enige uitzondering hierop is natuurlijk de key, en in het geval van RSA is er sprake van een mogelijke compromise van de serial-to-seed mapping (bron: Wikipedia). Met andere woorden, aan de hand van het serienummer van de SecureID token zou een aanvaller (welke de eerdergenoemde mapping heeft buitgemaakt) een token kunnen emuleren. Ofwel, mogelijkerwijs is het niet security-through-obscurity wat ze de kop kost, maar 't weggeven van 'the keys to the castle'.

[Reactie gewijzigd door Thralas op 23 juli 2024 05:46]

[Verwijderd]

Dus als je de nummers op de achterkant onleesbaar maakt dan zijn ze weer veilig?
Of is dat te kort door de bocht?

[psdata]

Het nummer achter op is alleen maar een registratie nummer, hoef je niet in te geven bij verificatie.
Dit nummer is alleen maar nodig op de key server zelf, en natuurlijk voor de interne administratie, zoals uitgifte van de tokens.

[TDeK]

Ehm, ja, maar dan kun je jezelf niet meer authenticeren (wat dus het hele doel van de token is). Sommige banken gebruiken tokens van Vasco waarbij het (serie)nummer je gebruikersnaam is en de gegenereerde token het 'wachtwoord'. Dus zonder het serienummer kun je niet meer inloggen.

[Thralas]

Grote kans dat een bedrijf welke gebruik maakt van SecureID nog wel een lijst met uitgegeven tokens ergens heeft slingeren (los van de authentication server)..

[humbug]

Je haalt nu wat door elkaar. Ook AES, SSL, 3DES enz zijn onveilig zodra mensen je key weten. Hoe werken dit soort algoritmes: Je pakt de invoerwaarde en voegt daar een key aan toe. De algoritmes zijn echter herhaalbaar. Pak ik dezelfde invoerwaarde en dezelfde key krijg ik dezelfde uitkomst.

Weet ik door de hack hoe het algoritme werkt, hoe de inputwaarde wordt bepaald en wat voor key er gebruikt wordt kan ik de uitkomst zelf genereren. Ongeacht of het algoritme nu AES, 3DES, blowfish of wat anders heet.

En op dat moment zijn de tokens niet meer betrouwbaar. Dit is dus compleet onafhankelijk van het algoritme en tsja, dat kun je security through obscurity noemen. Maar dan is vrijwel elke beveiliging security through obscurity want elke beveiliging maakt gebruik van een geheime key/salt.

Waar jij op doelt zijn algoritmes die bij grondige bestudering fouten blijken te bevatten en alleen veilig zijn zolang niemand het algoritme kent. Dat hoeft hier echter niet het geval te zijn.

[Verwijderd]

RSA claimde zelf echter dat er geen keys gestolen zijn.

Nu kan je je afvragen of ze daar nu op terugkomen, óf dat ze gewoon een bug hebben opgezocht binnen het hele proces. Door nu dus generators om te ruilen geven ze dus eigenlijk toe dat er ofwel een bug in hun systeem zat (en was dat de enige? dat weet je niet), óf dat ze hebben gelogen tegen hun klanten (en wie garandeerd mij dat ze dat niet nogmaals doen).

Ze zitten dus in een lastige situatie; een beveiligingsbedrijf mag natuurlijk niet gehackt worden, maar áls er toch eens iets misgaat, dan moeten ze volledig transparant zijn. RSA is dat waarschijnlijk dus niet geweest, en dat is voor mij genoeg reden om ze te wantrouwen.

Gelukkig zijn de tokens van RSA veelal puur een extra beveiliging om brute-forcing te voorkomen, maar iedere beveiliging die omzeilt wordt is stap dichterbij voor de crackers.

@hellbringer ;
Met 'security through obscurity' wordt niet bedoeld dat je je wachtwoord geheim moet houden. Er wordt bedoeld dat mensen met kennis van je systeem iets kunnen kraken zonder verder iets te moeten weten.

Vergelijk de volgende codes van een loginsysteem maar;
<?php
if($_SERVER['HTTP_USER_AGENT'] === 'ikke heb een custom user agent') {
echo 'You got in!';
}
?>

<?php
if(hash('ripemd160', $_GET['pass']) === '12_even_afgekort_89') {
echo 'You got in!;
?>

De eerste is absurt onveilig als jij iemands site hebt bezocht, en diegene (dus) jouw user agent weet.
De tweede is redelijk veilig; zolang niet bekend is welk wachtwoord deze hash creeert kan niemand inloggen. (natuurlijk voeg je normaal een salt toe, doe je meerdere hash turns, etc.)

Dát is het verschil tussen security through obscurity, en goede security.

[hellbringer]

'security through obscurity' is de enige manier om zo'n systeem te kunnen maken.
'obscurity' heb je altijd mee te maken in beveiliging (je password moet je immers ook geheim houden)
De manier waarop deze RSA tokens deze codes genereren en/of de koppeling tussen private key en RSA token serienummer moet echter wel absoluut geheim zijn en blijven, dit is ook het enige dat je aan een RSA token zou kunnen "hacken".
Probleem is dat deze informatie onvoldoende beveiligd was; ik meende dat de aanval via de PC van een secretaresse gegaan is die toegang had tot deze SUPER geheime data en nu dus bekend is bij hackers.

RSA geeft nog steeds erg weinig informatie vrij over wat er precies aan informatie buitgemaakt is, daarom moet je eigenlijk wel uitgaan van het ergste: iedere RSA token is waardeloos geworden.
Als iemand namelijk het algoritme en de koppeling tussen serienummer & private key heeft kan deze persoon iedere RSA token spoofen.

[Nijn]

Daar heb je gelijk in. Echter, deze persoon moet ook nog weten welke token hij moet spoofen. Het onleesbaar maken van het serienummer zou in veel gevallen het probleem redelijk oplossen. (En natuurlijk een goede beveiliging rond de database waarin staat wie welke key gebruikt).

[Rob Coops]

Je moet niet vergeten dat de hardware in zo'n sleutel generator nooit heel erg krachtig kan zijn en dus de generator een relatief simpele bewerking uit moet voeren. Omdat elke generator aan een gebruiker is gekoppeld moet er dus bij elke key een grote deels vaste waarde gebruiken om de sleutel te produceren. Immers de server moet het zelfde doen om de token te kunnen controleren.

De gebruiker specifieke code is een vaste code die je simpel weg kunt uitvinden door bijvoorbeeld een keylogger etc...
En de code die iedere 30 seconde of 60 seconde (afhankelijk van de latency op de verbinding en de keuze van de security persoon die daar over beslist) een nieuwe code produceert kan dus eigenlijk niets anders doen dan een simpele hash over de huidige datum/tijd en een vaste waarde die in de key opgeslagen is. Als je eenmaal weet wat de berekening van de hash is dan is alles wat nodig is alleen maar het afluisteren van een inloggende gebruiker en je bent binnen.
Immers je weet de datum tijd variable (iedere 30 seconde een nieuwe sleutel dus maximaal 30 variaties (milliseconde zullen ze niet gebruiken te veel reken werk) en dus simpel weg

De buitgemaakte informatie bij de RSA hack is dus simpel weg de variable(n) die gevoerd worden aan de key generator in de sleutel hanger, en in ider geval de naam van het hashing algorithme dat gebruikt wordt om de hash te genereren.

Voor een hacker die de resources heeft die de mensen achter de lockhead martin hack hadden (je hacked zo'n bedrijf niet als je alleen maar even wilt rond kijken) kan het niet zo moeilijk zijn om voor een bepaalde 60 seconde (+- 30 seconde in vergelijking tot de tijs dat de user op enter drukte) honderdduizenden of zelfs miljoenen hashes te berekenen en die te vergelijken met de code die de user op zijn key vond. Heb je een match dan heb je dus ook de geheime waarde van de gebruikers sleutel hanger, en de tijd dat de key is gegenereerd. Daarna kun je dus simpel weg deze key en tijd+(n*30sec) aan het algoritme voeren en je hebt een software key generator. Omdat je al met de gebruiker mee gekeken hebt weet je ook zijn gebruikers specifieke code en dus heb je volledige toegang tot het systeem met deze gebruikers credentials.

Ik zou haast zeggen dat deze beide hacks door een zelfde groep is uitgevoerd en dat deze groep waarschijnlijk vaker met stokjes dan met mes en vork hun maaltijden nuttigt. Maar dat is heel erg moeilijk hard te maken zonder heel erg veel meer informatie van zo wel RSA als Lockhead, en zelfs dan is het nog erg lastig om te bewijzen. Ik vermoed dat bij beide inbraken meer is buitgemaakt dan de voormalig eigenaren zouden willen toegeven simpel weg omdat het nu eenmaal slecht is voor het bedrijf. Maar een organisatie die de moeite neemt RSA te hacken om er achter te komen hoe zijn sleutels werken en dan toevallig deze zelfde gegevens gebruikt om bij Lockhead Martin in te breken zal denk ik niet met legen handen naar huis gaan die komen heus wel aan hun gegevens op welke wijze dan ook.

[thewiseman]

Ze hebben hier toch wel een deukje mee opgelopen. Ze paradeerden altijd dat het zo secure was en dat het niet te brekenen viel.

De sleutel wordt gegenereerd door middel van datum tijd en een speciefiek algoritme dat samen met een persoonlijke pin de two factor authenticatie maakt.

Dit alles is erg secure.. maar toch net niet genoeg..

[The Zep Man]

Ze hebben hier toch wel een deukje mee opgelopen. Ze paradeerden altijd dat het zo secure was en dat het niet te brekenen viel.

Misschien is het wel heel veilig en is het nog niet te berekenen. De meeste 'hacks' vinden echter niet plaats op wiskundig, cryptografisch niveau. Vaak wordt iets essentieels, zoals de cryptovariabel (de sleutel) gestolen. De beveiliging kan nog zo goed ontworpen zijn: al gooi je sleutels en codes op straat, zal het niet helpen. De 'sleutel' welke in dit geval gestolen is, is de informatie die gebruikt wordt om sleutels te genereren.

De sleutel wordt gegenereerd door middel van datum tijd en een speciefiek algoritme dat samen met een persoonlijke pin de two factor authenticatie maakt.

Dit alles is erg secure.. maar toch net niet genoeg..

Dat kan heel erg veilig zijn, maar je moet het proces en het sleutelmateriaal wel goed bewaken.

Beveiliging is meer dan alleen maar het implementeren van techniek. Sterker nog: het implementeren van techniek moet gezien worden als een stuk gereedschap, niet als een oplossing. Uiteindelijk zijn het mensen zelf die bepalen of ze veilig bezig zijn of niet. Een gebruiker die single-factor authenticatie gebruikt met een goede passphrase (wat iets anders is als een wachtwoord!) is in veel gevallen veiliger bezig dan een gebruiker die bijvoorbeeld multi-factor authenticatie gebruikt in de vorm van een zwak wachtwoord en vingerafdrukherkenning.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 05:46]

[The Van]

De meeste 'hacks' vinden echter niet plaats op wiskundig, cryptografisch niveau

Nee, hacks niet, maar fouten in algoritmes juist wel. Op die manier zijn SHA-0 en zijn "veiliger" zusje, SHA-1 ook gekraakt.
MD5 is hetzelfde lot beschoren.[bron: publicatie in pdf.

Mede hierom is het belangrijk, dat juist de algoritmes publiek toegankelijk zijn - al deze codes hadden flaws in het mechanisme, waardoor het relatief simpel werd deze te misbruiken.
Ik refereer even aan de discussie hierboven over het gevaarlijk zijn van openbaarheid van algoritmes. Het mag duidelijk zijn, dat ik voorstander ben van openbaarheid! Dan was het echec met de OV kaart ook niet opgetreden (afgezien van de privacy aangelegenheden!)

[jeanj]

Veel hacks vinden ook plaats op de implementatie van het algoritme, denk aan een radom generator die niet random is etc

[ultimasnake]

Volgens mij is de sleutel voor alsnog nog steeds erg veilig en 'onbreekbaar', het probleem ligt hem dat de server van het bedrijf gehacked zijn en de werking van de sleutels (het algoritme) gestolen is. De server zelf was dus niet veilig genoeg en nu heeft de sleutel zijn waarde wat verloren maar de sleutel zelf anzich was niet de zwakke schakel

[bigbadbull]

De RSA key staat meestal nooit alleen.
Zelf moet ik ook nog username , paswoord & security code+ token ingeven
Ok de veiligheid is verminderd, maar daarom nog niet volledig weg.
Wij hebben na de aankondiging van de hack in maart dan ook verplicht ons paswoord moeten wijzigen.

[hellbringer]

Het stukje extra veiligheid wat je hiermee zou moeten hebben ben je wel kwijt, de hackers hoeven nu namelijk niet de fysieke token in handen te hebben om in te loggen onder een account.
Je hebt dus een stuk minder beveiliging; de helft van de beveiliging is namelijk weg als je een token en password gebruikt om te autoriseren.

[ToAoM]

toch moeten ze 'm een keer in handen hebben gehad, je moet namelijk nog steeds het serienummer van het token hebben... Of ze moeten een aantal gegenereerde waarden hebben onderschept om het serienummer te kunnen bepalen..

[PcDealer]

Bedrijven met een grotere, gedecentraliseerde gebruikersgroep kunnen ook aanvullende bescherming krijgen, waarbij aan risicomanagement wordt gedaan. Wat deze aanvullende bescherming precies inhoudt, is onduidelijk.

Misschien dat daar de Fraud Mitigation & Identity Assurance wordt bedoeld en Risk Account Manager Service (pdf).

[Reactie gewijzigd door PcDealer op 23 juli 2024 05:46]

[Aragnut]

"beveiligde internetverbindingen moet opleveren"

De tokens kunnen gewoon gebruikt worden voor user authentication, wat gebruikt kan worden voor VPN sessies en websites, maar ook voor system login en file transfer.

[mancide]

Keytrade bank, die deze securID-tokens gebruikt, begint met een vervanging van de bestaande securID-tokens door nieuwe...

[Verwijderd]

Gezien de resources die er blijkbaar achter zitten vraag ik me af wat voor club achter deze hack en de hele toestand bij Lockheed zit. Is daar ooit wat over naar buiten gekomen qua vermoedens en/of bewijs?

[djack]

Dit is het zoveelste bewijs dat alles te breken is ...
Veiligheid moet meer zijn dan een optelling van wat inlogs en encrypties ...
Dat vergeten veel bedrijven...
We kopen Firewall X en met RSA Token zit ik veilig... jammer maar helaas ...

[Verwijderd]

Dit is niet het breken van... Als ik een mercedes koop die niet open te breken is, maar ik verlies de sleutel en iemand neemt dan de auto mee: Dan is niet het systeem gebroken ik heb gewoon de mogelijkheid gegeven dit te omzeilen. De beveiliging van RSA tokens is niet gehacked, de manier waarop dit versleuteld wordt is bekend.