Posts Tagged 'encryptie'

Dag 2 Keynote

12 januari 2010

Dank aan allen die uit kwam om de encryptie / DLP top. Hier zijn de slides van mijn keynote op dag 2.

encryptie-dlp-keynote

Het gaat allemaal over sleutelbeheer

07 januari 2010

Ik heb geschreven in het verleden over hoe als encryptie faalt, sleutelbeheer is meestal de schuld van. Je hebt misschien gezien het nieuws dat SySS heeft bedacht hoe om tegelijkertijd te openen kraken FIPS 140-2 level 2 USB-drives uit Kinston, SanDisk en Verbatim. Als u nog niet gehoord dit nog, lees dan verder. De scheur zou komisch als het niet zo eng gemakkelijk.

Alle USB drives in kwestie gebruikt 256 bit AES om de partitie te beveiligen. Ze gebruiken ook hardware om de encryptie proces uit te voeren. De fout is in de front-end software die de authenticatie uitvoert. SySS ontdekt dat wanneer een succesvolle wachtwoord is ingevoerd, een numerieke string is verzonden naar het station te coderen / decoderen van de gegevens. Tot zover gaat alles goed. De fout is dat het exact dezelfde numerieke string wordt gebruikt door alle schijven, ongeacht van het wachtwoord. Met andere woorden, het lijkt erop dat het altijd dezelfde toets wordt gebruikt om elke aandrijving te beschermen. Maak een kleine software-magie om die string te sturen naar een van de hierboven genoemde stations, en je zal toegang tot de gegevens krijgen. Geen kennis van het wachtwoord vereist is, noch is brute forcing. Stuur gewoon de magie string en 'poef!' Het station open is.
Dit doet me denken aan de hack een Europese groep gevonden met een militaire graad USB schijf een paar jaar terug. Wat ze erachter is dat een succesvol wachtwoord een specifieke pin combinatie geactiveerd. Trigger de pin met een batterij en heeft u toegang tot het station.
Natuurlijk is dit creëert grote problemen voor de eindgebruiker gemeenschap. De marketing materiaal op de stations ziet er goed uit. Ze gebruiken de juiste algoritme, dat voldoet aan de juiste spec NIST, en toch de schijven zijn net niet nutteloos. Hoe weet je dat eigenlijk drives veilig zijn? Voor mij gaat het terug om een ​​reactie een oude mentor ooit maakte tegen mij: "bloeden rand en cryptografie gaan niet samen '. Denk dat de enige manier om zeker te weten is voor anderen dierenarts het voor een paar jaar laten we eerst.

AES wordt nu wel heel dicht bij de gebroken

30 juli 2009

In eerdere berichten heb ik overlegd wat er mis is met WPA en waarom is het altijd een slecht idee om een standaard rond basis een enkele methode van encryptie, zelfs AES . Bruce Schneier geplaatst op zijn blog vandaag over een nieuwe aanval op AES . Kortom, de krant waar hij naar refereert wordt aangegeven hoe om drastisch verminderen van het aantal raden nodig is om een ​​sleutel te halen. Terwijl zijn niet praktisch vandaag voor een kelder hack om de aanval, zijn nog steeds vervelende dingen uit te voeren.

De aanval in kwestie is wat wordt aangeduid als een verwante sleutel aanval . Dit vereist de aanvaller te hebben een zekere mate van kennis van de platte tekst beveiligd door meerdere gerelateerde sleutels. Met andere woorden, moeten we weten al een beetje van wat er wordt beschermd en waar te zoeken.

Dit is een ernstig probleem als je het over VPN's of draadloos, omdat we gebruiken om IP-verkeer te beveiligen. IP maakt gebruik van een aantal mooie consistente waarden:

  • Byte 0 bevat de IP-versie (meestal 4) en de grootte van de IP-header (meestal 20 bytes)
  • Byte 1 bevat het type service veld (meestal niet gebruikt, zodat ingesteld op 0)
  • Bytes 2 en 3 bevatten de totale lengte veld (een consistente waarde voor het verkeer, zoals ARP-pakketten als je weet dat het besturingssysteem)
  • Byte 8 bevat de TTL (een consistente waarde op een per besturingssysteem basis)
  • 12-15 bytes bevatten het bron-IP-adres (een consistente waarde voor elk specifiek systeem)

En dat is nog maar de IP-header ...

Dus als we het verkeer te beschermen op de draad, kan gerelateerd sleutel aanvallen worden vooral kwaad omdat er veel repeterende waarden om mee te werken.

Dus wat moet je doen? Ik zal terug te vallen op hetzelfde advies dat ik gaf in die vroegere berichten ik hierboven vermelde. Zorg ervoor dat je meer opties dan alleen maar een enkele encryptie-algoritme, voor het geval dat dingen een stuk erger.