Nieuws
image

Onderzoeker: geen backdoor in Windowsversie TrueCrypt

vrijdag 25 oktober 2013, 10:21 door Redactie, 16 reacties
Laatst bijgewerkt: 25-10-2013, 13:03

De meest recente Windowsversie van de populaire encryptiesoftware TrueCrypt bevat op het eerste gezicht geen backdoor. Dat zegt de informaticastudent Xavier de Carné de Carnavalet van het Concordia Institute for Information Systems Engineering. Hij besloot de broncode van TrueCrypt zelf te compileren naar een Windowsversie.

Onlangs werd er een crowdfunding-initiatief gestart om de broncode van TrueCrypt te laten auditen. Hoewel het om opensourcesoftware gaat, blijkt dat nog nooit iemand de broncode heeft geaudit. Daarnaast is het nog altijd onbekend wie de auteur van het encryptieprogramma is. Uit eerder uitgevoerd onderzoek zou verder blijken dat het niet valt uit te sluiten dat de Windows-installatie aan de hand van een andere broncode is gecompileerd.

Visual Studio

De Carné de Carnavalet besloot daarop de broncode van TrueCrypt 7.1a zelf te compileren. Als eerste gebruikte hij voor het compileren Visual Studio 2010 met Service Pack 1, waardoor hij een versie kreeg die afweek van het origineel. Ontevreden met het resultaat gebruikte de student vervolgens Visual Studio 2008 met SP1, maar kreeg wederom een afwijkende versie, hoewel minder dan bij Visual Studio 2010 SP1 het geval was.

Het doel was om dezelfde productieomgeving te reproduceren die door de originele ontwikkelaar of ontwikkelaars was gebruikt. Uiteindelijk bleek de gouden combinatie Visual Studio 2008 met Service Pack 1 te zijn, inclusief alle updates voordat TrueCrypt 7.1a uitkwam.

De versie die De Carné de Carnavalet met deze opstelling compileerde kwam overeen met het origineel. "Alleen toen kon ik een identieke build maken en voor mezelf bewijzen dat TrueCrypt niet door de ontwikkelaars van een backdoor is voorzien op een manier die aan de hand van de bronnen is te herleiden." De informaticastudent benadrukt dat zijn resultaten zorgen over de betrouwbaarheid van TrueCrypt in het algemeen kunnen wegnemen, maar dat een audit van de broncode echt zekerheid geeft.

Reacties (16)
25-10-2013, 10:36 door Anoniem
De kop klop niet. De conclusie van de onderzoeker is dat een eventuele backdoor in de source (of compiler) moet zitten.

Het citaat is (nadruk toegevoegd):

"Only then, I could achieve an identical build and prove to myself that TrueCrypt is not backdoored by the developers **in a way that is not visible from the sources**"
25-10-2013, 11:14 door fransdb
De conclusie dat er geen backdoor inzit is iets te vroeg, wie zegt dat die al niet in de standaard software zit. Bv, het aanbieden van een specifieke code of sequence van codes/handelingen kan het ook al open zetten.

Goede source code auditing is het enige wat antwoord kan geven.
25-10-2013, 11:17 door Anoniem
Door fransdb: De conclusie dat er geen backdoor inzit is iets te vroeg, wie zegt dat die al niet in de standaard software zit. Bv, het aanbieden van een specifieke code of sequence van codes/handelingen kan het ook al open zetten.

Goede source code auditing is het enige wat antwoord kan geven.

eens. nog steeds lijkt de broncode niet gecontroleerd te zijn.
25-10-2013, 11:27 door schele
Lijkt me ook wat voorbarig inderdaad. De backdoor is niet toegevoegd dat klopt, maar zolang de makers onbekend zijn en de source code nooit is doorgelicht bewijst het helemaal niks rond betrouwbaarheid: die backdoor kan net zo goed van begin af aan zijn ingebouwd.
25-10-2013, 11:47 door Anoniem
Door fransdb: De conclusie dat er geen backdoor inzit is iets te vroeg, wie zegt dat die al niet in de standaard software zit.
Jup, zoiets dacht ik ook. Dat met begrijpend lezen is nog wel eens een probleem hier en daar. Want het origineel zegt iets compleet anders:

We show in this article how to reproduce a deterministic compilation process specific to TrueCrypt 7.1a for Windows that matches the official binaries, and relieve the world from at least some concerns.

Met andere woorden, met de vrijgegeven broncode is het programma verschilvrij te herproduceren.

Goede source code auditing is het enige wat antwoord kan geven.

Dat niet helemaal, maar dit recept vergemakkelijkt de zaak wel: Zolang je de compiler kan vertrouwen niet stieken allerlei code toe te voegen*, kun je ervanuitgaan dat het deze broncode is waar de binaries mee gebouwd zijn. En dat versimpelt het doen van een code audit.

Al met al positief nieuws maar Redactie loopt hier gewoon veel te hard van stapel door te stellen dat alle er dus geen achterdeurtjes in zouden zitten. Het staat niet in het origineel en je mag het er ook indirect niet uit opmaken.

Laat ik er wat redelijk bekende voorbeelden bijhalen: Naast de "obfuscated C contest"**, wat voorbeelden geeft van code die niet te lezen is maar wel werkt, is er "underhanded C contest"***, waar het de kunst is zo gewoon mogelijk uitziende code te produceren die stiekem iets heel anders doet dan je zou denken, maar waar je normaliter gewoon overheen leest en behalve als geactiveerd ook niet te merken is aan het uiteindelijke programma. Dat eerste hoort goed op te vallen bij een code audit, en dan kan je er wat aan doen. Dat tweede valt niet op, dat is nou net het punt.

* Wat niet ondenkbaar is: http://cm.bell-labs.com/who/ken/trust.html****
** http://www.ioccc.org/
*** http://underhanded.xcott.com/
**** Daar zijn dan weer mitigatiestrategien voor, dat dan weer wel.
25-10-2013, 11:52 door [Account Verwijderd] - Bijgewerkt: 25-10-2013, 11:59
[Verwijderd]
25-10-2013, 12:30 door Anoniem
Door schele: Lijkt me ook wat voorbarig inderdaad. De backdoor is niet toegevoegd dat klopt, maar zolang de makers onbekend zijn en de source code nooit is doorgelicht bewijst het helemaal niks rond betrouwbaarheid: die backdoor kan net zo goed van begin af aan zijn ingebouwd.

Ehhrrrr. Hij heeft de source code doorgelicht. Daar gaat dit artikel over.
25-10-2013, 12:36 door N4ppy
Door pe0mot: Nu nog een tweede partij die zijn conclusies bevestigd, en iemand die de sources audit. Oef! Wie heeft er tijd over?

Vraag is meer wie kan het? Je moet dan iemand hebben die en code kent en de benodigde kennis van encrypty/entropie/etc etc
25-10-2013, 12:42 door Anoniem
Gebruikt truecrypt geen windows api's ?
25-10-2013, 13:02 door Anoniem
Dus die nsa.dll uit windows/system32 kan gewoon weg? :P
25-10-2013, 13:07 door Anoniem
Door N4ppy: Vraag is meer wie kan het? Je moet dan iemand hebben die en code kent en de benodigde kennis van encrypty/entropie/etc etc
Duik in de materie. Je begint met een cursus invoering programmeren (als je dat niet al kan) en een cursus invoering crypto, en je blijft je inlezen. Ondertussen ga je de source lezen en uittekenen wat het allemaal doet. Wellicht aan het einde nog een keertje vanaf het begin af aan, want je hebt ondertussen bijgeleerd. Alles wat je niet snapt, uitzoeken. Navragen. Met anderen bediscussieren. Kost veel tijd, maar is ook heel leerzaam. Zie het als een hobby en je komt een heel eind.

Bij dit soort dingen is het belangrijker dat veel mensen er naar kijken (waaronder hopelijk ook een paar goed scherpe) dan dat je het maar aan de experts overlaat--door veel te kijken word je vanzelf expert... in het kijken.

Schrijven is een stapje hogerop, en cryptoalgorithmes ontwerpen weer een paar stapjes moeilijker. Voordat je daar aan begint moet je toch eerst een paar keer je tanden in al bestaande algorithmes gezet hebben. Maar kijken en alles wat je niet helemaal zeker weet uitpluizen is een prima begin.

Merk op dat je nog steeds geen garanties hebt nadat je het ding helemaal uitgeplozen hebt. Niets vinden is geen garantie dat er niets te vinden is. Maar de kans dat er nog onopgemerkte dingen in zitten gaat wel omlaag (hoeveel? goede vraag), en het is dus beter wel te kijken dan om niet te kijken.
25-10-2013, 13:56 door Prx
Door Anoniem:
Door schele: Lijkt me ook wat voorbarig inderdaad. De backdoor is niet toegevoegd dat klopt, maar zolang de makers onbekend zijn en de source code nooit is doorgelicht bewijst het helemaal niks rond betrouwbaarheid: die backdoor kan net zo goed van begin af aan zijn ingebouwd.

Ehhrrrr. Hij heeft de source code doorgelicht. Daar gaat dit artikel over.

Nee, dat is niet wat er staat. Deze student heeft de gepubliceerde (openbare) broncode genomen van TrueCrypt en deze compileerd op Windows. Het resultaat van deze actie is dus de gecompileerde versie, die overeen kwam met de versie zoals deze zelf door TrueCrypt wordt gedistribueerd voor het Windows platform. Dat geeft niet aan of de broncode wel of niet voorzien is van een backdoor, alleen dat build niet is aangepast met extra code, anders dan de reeds gepubliceerde broncode.
25-10-2013, 14:34 door fvandillen
Door Prx_:
Door Anoniem:
Door schele: Lijkt me ook wat voorbarig inderdaad. De backdoor is niet toegevoegd dat klopt, maar zolang de makers onbekend zijn en de source code nooit is doorgelicht bewijst het helemaal niks rond betrouwbaarheid: die backdoor kan net zo goed van begin af aan zijn ingebouwd.

Ehhrrrr. Hij heeft de source code doorgelicht. Daar gaat dit artikel over.

Nee, dat is niet wat er staat. Deze student heeft de gepubliceerde (openbare) broncode genomen van TrueCrypt en deze compileerd op Windows. Het resultaat van deze actie is dus de gecompileerde versie, die overeen kwam met de versie zoals deze zelf door TrueCrypt wordt gedistribueerd voor het Windows platform. Dat geeft niet aan of de broncode wel of niet voorzien is van een backdoor, alleen dat build niet is aangepast met extra code, anders dan de reeds gepubliceerde broncode.

Precies, uitstekend verwoord overigens :)
25-10-2013, 15:46 door Anoniem
Als leek begrijp ik dat ook gedurende het omzetten van de tekst (broncode) door de het compileer programmahet uiteindelijke encryptie programma kan worden uitgebreid met een achterdeur, die dus een masterkey toevoegt.
Er moet dus voor de zuiverheid van het programma ook een nieuw compileer programma worden ontwikkelt.
25-10-2013, 17:34 door [Account Verwijderd]
[Verwijderd]
25-10-2013, 20:11 door Anoniem
Door Anoniem: Als leek begrijp ik dat ook gedurende het omzetten van de tekst (broncode) door de het compileer programmahet uiteindelijke encryptie programma kan worden uitgebreid met een achterdeur, die dus een masterkey toevoegt.
Dat is theoretisch mogelijk. We kennen er een (1) historisch voorbeeld van (zie linkje boven). Uitleggen waarom precies voert te ver, maar gezien de complexiteit (en het verschil in context!) niet heel practisch dat via deze route een achterdeur is toegevoegd aan dit programma en daarom niet heel waarschijnlijk, ik zou zeggen behoorlijk onwaarschijnlijk.

Maar niet geheel voor dat hele kleine beetje overgebleven kans uit te sluiten. Desondanks is het een stuk waarschijnlijker dat als ongenode gasten toegang gaan blijken te hebben dat via een andere route zal blijken te zijn geweest.

Er moet dus voor de zuiverheid van het programma ook een nieuw compileer programma worden ontwikkelt.
Dat doe je niet "even". Reken op honderden tot duizenden manjaren werk.

Proberen dezelfde code met een andere (bestaande, van een andere fabrikant) compiler te bouwen is simpeler en practischer. Daarmee krijg je niet bit-voor-bit dezelfde binary terug, maar wellicht wel een fuctionerend programma.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search