Google brengt tests uit om cryptokwetsbaarheden op te sporen

Google heeft een project in het leven geroepen onder de naam 'Wycheproof'. Dat bestaat uit een aantal tests waarmee ontwikkelaars kwetsbaarheden in cryptografische bibliotheken kunnen opsporen. Er zijn bijvoorbeeld tests voor rsa- en aes-encryptie.

Beveiligingsmedewerkers van Google schrijven in hun aankondiging dat bij het toepassen van encryptie kleine fouten vaak grote gevolgen kunnen hebben. Google maakt net als andere ontwikkelaars gebruik van cryptografische bibliotheken van derden, waarvoor vaak geen implementatierichtlijnen te vinden zijn. Daarom hebben zij het project in het leven geroepen, wat in feite bestaat uit een verzameling van ongeveer tachtig unittests. Aan de hand van deze tests kunnen ontwikkelaars bekende kwetsbaarheden opsporen in crypto-implementaties.

Door de tests zelf uit te voeren, was het beveiligingsteam van Google in staat om veertig bugs op te sporen. Deze zijn nog niet allemaal openbaar gemaakt, omdat sommige ervan nog door de respectievelijke ontwikkelaars opgelost moeten worden. Een voorbeeld van een gevonden bug is dat de privésleutel achterhaald kon worden bij veelgebruikte implementaties van dsa en ecdhc. De Google-medewerkers waarschuwen dat het slagen voor de tests niet betekent dat een implementatie veilig is. De tests moeten ontwikkelaars die niet veel van cryptografie weten helpen om bekende aanvallen af te weren.

De eerste tests van het Google-team zijn geschreven in Java, omdat de taal beschikt over een gezamenlijke cryptografische interface. Het team werkt eraan het porten van de tests naar andere talen te vergemakkelijken. Er zijn inmiddels tests voor aanbieders binnen het JCA-framework, zoals Bouncy Castle, en de standaardmogelijkheden in OpenJDK.

Het project is vernoemd naar de kleinste berg ter wereld, Wycheproof, die 43 meter hoog is. De reden daarachter is dat het project een haalbaar doel moet hebben, 'net als het beklimmen van een kleine berg'.

Reacties (6)

[totaalgeenhard]

Wel vreemd dat iemand daar nu pas mee komt.

In keten afhankelijkheid is implementatie van encryptie uiteraard zeer belangrijk.

Maar als dat zelfstandig al niet op implementatie (en andere fouten) is getest, vertrouwen we kennelijk blind op.

De partijen die er wel baat bij hebben (criminelen en inlichtingendiensten) zullen het niet openbaren.

[TheGhostInc]

Maar als dat zelfstandig al niet op implementatie (en andere fouten) is getest, vertrouwen we kennelijk blind op.

Je moet altijd (gedeeltelijk) vertrouwen op de implementatie, je kunt namelijk niet alles testen. Als je een applicatie gaat bouwen en je wilt op een gegeven moment een extra thread gebruiken, dan ga je niet eerst maanden testen of de implementatie van die threads wel goed is gedaan.
Je bent (voornamelijk) verantwoordelijk voor de code die je zelf schrijft, het lastige is ook nog dat encryptie vaak 'verstopt' zit aan het begin of einde. En als het goed is ook nog eens 'transparant' is voor je code.
In Java bijvoorbeeld is het niet meer dan een paar annotaties links en rechts en je encryptie staat aan of uit. Of die encryptie dan volledig goed geïmplementeerd is, is voor de gemiddelde programmeur amper meer uit te zoeken. Als ik 'garbage' over de lijn zie komen weet ik dat er 'iets' gebeurd.

De eerste tests van het Google-team zijn geschreven in Java, omdat de taal beschikt over een gezamenlijke cryptografische interface.

Dit geeft trouwens aan wat de kracht van Java is. Veel Interfaces hebben meerdere implementaties, dan kun je wel specifieke varianten hebben (sneller of geoptimaliseerd voor een toepassing), maar hoef je maar 1 testsuite te hebben.

[3raser]

Zijn deze test alleen bedoeld om kwetsbaarheden in bestaande bibliotheken te vinden? Dan is het toch een kwestie van alle bibliotheken een keer testen en klaar?

Het zou goed zijn als Google dan ook een lijstje zou bijhouden met de best geteste bibliotheken zodat meer mensen weten welke zij (redelijk) veilig toe kunnen passen.

[Maurits van Baerle]

Als ik het goed begrijp gaat het niet om bibliotheken maar specifieke implementaties met die bibliotheken. Je kunt als developer gebruik maken van een bibliotheek die goed in elkaar zit en toch fouten maken met de implementatie van die bibliotheek en grote gaten achter laten. Volgens mij is deze tool er voor om dat soort problemen te vinden.

[RangedNeedles]

Want? Ik zie er niet bepaald een probleem mee..
Waarschijnlijk vergis je je nog steeds met de Java-applets die je in de browser kan kon draaien. Die kenden inderdaad wel wat veiligheidsissues. Maar een taal an sich is zo veilig (of onveilig) dan wat je er zelf mee programmeert.