Deskundigen vinden geen aanwijzingen voor backdoor in TrueCrypt

In de eerste fase van de security-audit van opensource-encryptiesoftware TrueCrypt zijn geen aanwijzingen van backdoors gevonden, wel is er een aantal kleine bugs opgespoord en is de kwaliteit van de code volgens deskundigen onvoldoende.

De onderzoekers van iSEC onderwierpen de Truecrypt-bootloader en de Windows-kerneldriver aan een grondige analyse en hebben hun bevindingen gepubliceerd, meldt Ars Technica. Er werden in totaal elf kleine kwetsbaarheden gevonden in de code, deze zouden volgens de onderzoekers echter niet bewust zijn aangebracht.

De code zelf zou volgens de onderzoekers echter kwalitatief niet voldoende zijn. Er zouden veel te weinig comments in de code aanwezig zijn en er wordt veelvuldig gebruikgemaakt van verouderde of onveilige functies. De documentatie van de software zou daarentegen wel op orde zijn.

Beveiligingsbedrijf iSEC voerde de audit uit in opdracht van het Open Crypto Audit Project. Dit project werd in oktober vorig jaar opgestart om geld in te zamelen voor de bekostiging van een securityaudit en een cryptoanalyse van TrueCrypt. Sinds de start is er al tachtigduizend dollar, omgerekend ongeveer 58.000 euro, opgehaald om TrueCrypt te laten analyseren.

Na de vele onthullingen over de praktijken van de NSA vreesden sommige mensen dat de spionagedienst ook met TrueCrypt gerommeld zou hebben. Matthew Green, als hoogleraar cryptografie verbonden aan het Johns Hopkins Information Security Institute en betrokken bij het Open Crypto Audit Project, is daarom tevreden met de resultaten. Hij zegt vooral blij te zijn dat er geen kritieke beveiligingsproblemen zijn gevonden.

Reacties (60)

[strompf]

Hier is het rapport: https://opencryptoaudit.org/reports/

Erg leuk om zo in detail code + evaluatie te zien

[TunderNerd]

Ik programmeer al een aantal jaar C, maar ik heb me toch verbaast over de stiekeme risico's van bepaalde constructies. Een must read voor alle C programmeurs!

[SED]

Inderdaad, ook opvallend dat twee serieuze reviewers er 11 problemen uithalen die de open source Truecrypt community over het hoofd had gezien. Er is te veel vertrouwen in open source sec. Zonder zorgvuldige regelmatige review is het een schijnveiligheid!

[psyBSD]

Je hebt gelijk, open-source is niet impliciet secure.

Maar er is geen alternatief. Closed-Source security is practisch een contradictio in terminis. Alle gerespecteerde security-specialisten zijn het over 1 ding eens. Waar open-source risico's met zich meebrengt is het de enige manier waarop je betrouwbare security-producten kunt ontwikkelen.

Er moet regelmatig ge-audit worden. Dit wordt continue gedaan, uit deze audit is een mooi rapportje gekomen met een 11 tal bevindingen. Van vorm-fouten tot code die iets anders zou kunnen doen dan oorspronkelijk voorzien is. Dit zijn echter geen vulnerabilities waar een CVE-score aan toegekend wordt, en zijn dan ook beperkt in hun impact.

Ik ben opzich tevreden over de uitkomst. Er is goed te zien dat de ontwikkelaars ook mensen zijn, er zijn zaken die door onoplettendheid erdoor glippen maar dat gebeurt iedereen.

[Parody]

Dan ga je uit van twee aannames:

• Het gespecialiseerde bedrijf doet z'n werk naar behoren
• Gesloten code is beter beveiligd Open Source code

Beide zijn wat twijfelachtig. En waarom zou je Open Source code niet laten beveiligen door een gespecialiseerd bedrijf? Win-win situatie, want het resultaat daarvan kan weer door een onafhankelijke derde gereviewed worden.

[Soultaker]

Een soortgelijk onderzoek is vorig jaar ook al eens gedaan: https://madiba.encs.conco...ecrypt-binaries-analysis/

Toen werd vooral gecheckt of de officiële binaries wel overeenkomen met de gepubliceerde broncode. (Als je een backdoor introduceert is het handig om die wel in de binary te stoppen, maar niet in de broncode, zodat het lijkt alsof er niets aan de hand is.)

Natuurlijk wel goed om het experiment periodiek te herhalen, maar op zich denk ik niet dat het heel waarschijnlijk is dat er opeens een backdoor wordt geïntroduceerd in de software die publiek beschikbaar is. Het lijkt me waarschijnlijker dat geheime diensten specifieke personen targetten, zodat hun werk onopgemerkt blijft.

[Reactie gewijzigd door Soultaker op 7 augustus 2024 17:42]

[Parody]

Dat laatste is onzin. Je gaat er vanuit dat er zoiets bestaat als oneindige rekenkracht als je maar genoeg betaalt. Alles valt of staat met een goed algoritme i.c.m. een fatsoenlijke sleutel. Brute-force helpt niet als je miljoenen jaren bezig bent, en niet alle algoritmen bevatten per definitie een backdoor. Het is waarschijnlijker dat echt goed versleutelde informatie door social engineering, chantage of martelen gedecrypt wordt, omdat de sleutel op die manier vrij komt.

[roboreaper]

De code zelf zou volgens de onderzoekers echter kwalitatief niet voldoende zijn. Er zouden veel te weinig comments in de code aanwezig zijn en er wordt veelvuldig gebruikgemaakt van verouderde of onveilige functies. De documentatie van de software zou daarentegen wel op orde zijn.

ik snap dat verouderde of onveilige funties slecht is, maar hoezo is veel te weinig comments in de code slecht.

ja code moet leesbaar zijn en anders goed begrepen kunnen worden met documentatie ( wat wel in orde is, blijkbaar) of commentaar. Maar het lijkt me niet echt handig om alle functies helemaal vol te zaaien met comments.

zo lees ik het teminste

[Gropah]

Het hangt er erg van af. Als er goed geprogrammeerd wordt met veel functie's (met descriptive names) etc dan is de code al goed te volgen zonder te veel commentaar. Echter als er in C(++) geschreven wordt dan hebben veel mensen de neiging om veel operatie's bij elkaar te zetten, waardoor het (voor mij in ieder geval) een stuk minder leesbaar is.

[graverobber2]

Dan is het gewoon slecht geschreven code (als in: onleesbare code)

[jozuf]

Ik vind het enigsinds vreemd om te zeggen dat de documentatie in orde is maar te weinig comments. In mijn ogen is commenting van code onderdeel van documentatie.
Ik ben het er mee eens dat commenten om het commenten niet nodig is. Ook moet je enkel comments schrijven voor zaken die niet geheel duidelijk zijn en niet elke if uit gaan lopen leggen ofzo.

Daarnaast vind ik commenting op functie/class niveau wel fijn aangezien de code completers dit dan mooi laten zien in je IDE.

[Gropah]

Persoonlijk ben ik het niet met je eens. Comments zijn voor maintainability (wat doe je met dit stuk code en waarom). terwijl documentatie gaat over waarom je een bepaalde structuur/framework/etc aan houd. Dit zijn totaal verschillende niveaus van abstractie en dus vind ik het wel andere dingen

[Brahiewahiewa]

D'r is een optimum aan comments in code. Geen comments is niet goed; te veel comments is niet goed. Volgens de onderzoekers ligt het aantal comments in de code van trueCrypt onder het optimum

[phyraxian]

De stel regel is ruwweg dat alles wat public beschikbaar is, moet van commentaar worden voorzien.
Dit omdat deze delen van de code aangesproken kunnen worden door derden zonder een volledig begrip van de werking van het systeem.

[_Pussycat_]

hoezo is veel te weinig comments in de code slecht.

Te weinig is per definitie slecht. Weinig kan wel nog OK zijn. Vol zaaien hoeft ook niet (er zijn mensen die "i++;" commenteren met "//increase value of i by one"), maar schijnbaar was het wel erg weinig en ja, dat kan het moelijk maken dingen te begrijpen.

[mashell]

maar hoezo is veel te weinig comments in de code slecht.

Het is open source, dat door veel mensen wordt gelezen en onderhouden wordt. Nou, in theorie, in de praktijk is dat natuurlijk maar een handjevol mensen. Maar als je wilt dat de theorie de praktijk wordt, dan zul je rijkelijk moeten commenten zodat andere het kunnen begrijpen, je zult dus je bedoelingen moeten vastleggen in commentaren.

[Gropah]

Het gebruik van onveilige en/of oude functie's is wel een kritiek beveiligingsprobleem... Dit is (voor zover ik weet) de oorzaak van heartbleed bug waar iedereen het de laatste tijd over heeft.

[Whatts]

De oorzaak van Heartbleed was 1 developer (Robin Seggelmann) die vergeten was 1 value op lengte te checken (ik dacht in 2010 maar ik vind het niet zo direct terug). Dit was in code specifiek geschreven voor Open SSL en dus geen hergebruik van oude code of functies.

Edit:
http://it.slashdot.org/st...ssl-was-an-honest-mistake

"The change was logged on New Year's Eve 2011. 'I was working on improving OpenSSL and submitted numerous bug fixes and added new features,' Seggelmann told the Sydney Morning Herald. 'In one of the new features, unfortunately, I missed validating a variable containing a length.' His work was reviewed, but the reviewer also missed the error, and it was included in the released version of OpenSSL."

[Reactie gewijzigd door Whatts op 7 augustus 2024 17:42]

[Gropah]

Ik dacht dat er gebruik gemaakt werd van malloc, waar er bij in ieder geval C++ (waar deze lib volgens mij in geschreven is (?)) heb je betere manieren om geheugen te alloceren. Maar ik kan er ook totaal naast zitten.

[anboni]

Je zit er inderdaad behoorlijk naast. Ze gebruiken juist eigen memory management functies. Als ze malloc hadden gebruikt, was de impact van deze bug (die verder totaal ongerelateerd is aan malloc) vermoedelijk kleiner geweest omdat malloc in recente implementaties vaak geheugenblokken wist voordat ze worden vrijgegeven.

[Sh4wn]

Nee, OpenSSL gebruikt een zelfgeschreven geheugenallocator omdat die op bepaalde platformen sneller is. Deze allocator heeft heel veel beveiligingsopties niet die wel in de recente standaard malloc functies zitten.

De oorzaak is overigens een vergeten check op de lengte, maar de impact wordt vergroot doordat deze geheugenallocator zoveel mogelijk ook geheugenadressen hergebruikt.

[Reactie gewijzigd door Sh4wn op 7 augustus 2024 17:42]

[Mathieu_Hinder]

Voor zover ik weet is malloc gebruikt in C, en wordt er in C++ gebruik gemaakt van new en niet van malloc/free.

[Kirth]

OpenSSL is in C geschreven.

[jaapzb]

De oorzaak van de heartbleed bug was toch gewoon dat de lengte van een bepaalde variabele niet werd gecheckt? Dat heeft in mijn optiek verder niet heel veel te maken met verouderde of onveilige functies. Ligt er wel aan hoe "functies" gedefinieerd is.

[witchdoc]

Die heartbleed bug heeft niks met verouderde/onveilige functies te maken.
Uiteraard is het wel een erg kritische bug in de heartbeat functie maar dus niet door ouderdom of 'perse' onveilige functies. Enkel de bug maakt het onveilig.

[Bitage]

Als een project al een tijd loopt kom je bijna niet om oude legacy code heen. Ben het met je eens dat het beter is als al die code wordt hernieuwd, maar je zal in ieder al langer lopend project verouderde stukken tegenkomen, dit is echter niet noodzakelijkerwijs een "kritiek beveiligingsprobleem". De Heartbleed bug was gewoon een zware blunder, je pointer incrementen met user input zonder iets te checken is gewoon dom.

[Verwijderd]

Niet alleen meldt Ars Technica het, maar Truecrypt heeft via Indiegogo een update gegeven (met verwijzing naar de bevindingen) aan iedereen die heeft bijgedragen.

[madmaxnl]

"Hij zegt vooral blij te zijn dat er geen kritieke beveiligingsproblemen zijn gevonden."

Hiermee geeft die dus effectief aan dat ze liever geen beveiligingsproblemen vinden terwijl dit nu juist wel hun werk was. Dit zegt wellicht iets over de kwaliteit van hun werk. Hoe lager de kwaliteit van hun werk hoe "beter" het resultaat, ergo: "Matthew Green is daarom tevreden met de resultaten. Hij zegt vooral blij te zijn dat er geen kritieke beveiligingsproblemen zijn gevonden."

Als ze niks vinden kun je twee stellingen doen, er viel niks te vinden of ze hebben niet goed genoeg gezocht. Er is dus nog altijd net zoveel zekerheid als dat er eerst was.

[Reactie gewijzigd door madmaxnl op 7 augustus 2024 17:42]

[mashell]

Hiermee geeft die dus effectief aan dat ze liever geen beveiligingsproblemen vinden terwijl dit nu juist wel hun opdracht/werk was

Natuurlijk niet. Hij geeft daarmee aan dat niet is gebleken dat mensen jarenlang op software hebben vertrouwd die onveilig was en dat is natuurlijk de grote angst die hij had.
En tja, kwaliteit. Ik heb geen idee hoe goed de review was, maar dat er een externe review was is al beter dan wat veel andere open source projecten halen. We zouden dit soort projecten eigenlijk ook moeten doen met de hele Linux kernel en de subsystemen.

[Xthemes.us]

Ben ik het niet mee eens, nu is het onderzocht door mensen die er niet alleen kaas van hebben gegeten maar ook nog eens specifiek naar veiligheidsproblemen hebben gezocht. Als er dan niks gevonden is zou ik zeg dat er met meer zekerheid gezegd kan worden dat het in ieder geval niet zo lek als een mandje is.

Hiermee geeft die dus effectief aan dat ze liever geen beveiligingsproblemen vinden terwijl dit nu juist wel hun opdracht/werk was.

Ze hebben mensen betaald om er naar te laten kijken of alles wel in orde is, als je voor een medische checkup naar de dokter gaat en die verklaard je gezond zeg jij dan ook met minder zekerheid dat je gezond bent?

[indigo79]

Of vind je het dan ook raar dat jijzelf of de dokter blij zijn om vast te stellen dat je in orde bent (omdat het de dokter z'n taak is te kijken wat je mankeert)?

[Stijn]

Matthew Green deed de audit niet, lees ik in het artikel, hij maakt deel uit van de organisatie die opdracht gaf voor de audit. Als je je project laat controleren hoop je natuurlijk dat de kwaliteit ervan hoog blijkt te zien, dat lijkt me een heel natuurlijke reactie.

Als ze niks vinden betekent dat inderdaad dat ze óf niet goed genoeg hebben gezocht óf dat er gewoon niks te vinden viel. Maar die laatste optie is wel waarschijnlijker dan de eerste, als je aanneemt dat iSEC zijn werk goed doet. Nou ken ik iSEC niet, maar ik wil wel aannemen dat de opdrachtgevers een kwalitatief goede auditor hebben uitgezocht voor dit werk. Dan is er dus wél meer zekerheid dan er eerst was.

[Dragonheart-03]

' die zo maar even een truecrypt volume met 1 van de vele backdoortrukks decrypt' .

Jij stelt dus dat die backdoor er wel is. Misschien even voordoen hoe je dat dan precies doet.

Lukt het niet ? Misschien dan een paar nachten wakker blijven en goed blijven zoeken naar iets wat er misschien ook wel niet is.

Zo zijn er zat kinderen die voor de schoorsteen zitten te wachten op sinterklaas die dan toch niet door de schoorsteen komt.

[mrlammers]

wel zijn er een aantal kleine bugs opgespoord en zou de kwaliteit van de code volgens deskundigen onvoldoende zijn.

..de kwaliteit van de ongecompileerde code? Comments? Alsof dat zo boeiend is. Je hebt er veel meer aan als de documentatie op orde is.
En misschien moeten we kwaliteit eerst even goed definieren. Want kwaliteit heeft nogal te maken met de persoon/partij die de eisen stelt. Wat 'goed' is voor de een, kan onvoldoende zijn voor de ander...

[MrMonkE]

Als je een codereview of een audit moet doen op code is het wel handig als er bijstaat wat die code moet doen. Dan kun je beter evalueren of de code voldoet en doet wat hij moet doen.
Als je niet weet wat de code moet doen kun je er ook nooit een review van doen.

[mrlammers]

Ik snap de zin en de onzin van comments, maar wat verwacht je in dit geval te vinden?

// Here is the part of code written for the NSA.
// It allows the agency to rape everything that we believe is sacred.
// Magic. Do not touch.
Dat ga je heus niet vinden, hoor.

Ik zie dan liever dit:
// drukn. fix later.

[electricretard]

Nou ben ik geen voltijd programmeur maar er wordt eerst gezegd dat er te weinig code commentaar is, maar dat de code wel voldoende gedocumenteerd is.

Kan me voorstellen dat wanneer er een uitgebreide documentatie over de code bestaat dat een paar code comments dan ook niet meer nodig zijn.

[M-Opensource]

"Beveiligingsbedrijf iSEC voerde de audit uit in opdracht van het Open Crypto Audit Project."

[djpdjpnl]

Wat Frustus Maximus bedoelt, en dat begrijp ik heel goed; heeft de NSA niet juist ook een back geld naar iSEC gestuurd om een foute audit te doen? Dat kun je niet controleren.

[mashell]

Tja, als we zo gaan doen. Betaald de NSA jou niet om hier paranoia comments te posten zodat tweakers de indruk krijgen dat de NSA veel machtiger is dan ze in werkelijkheid is?

[djpdjpnl]

Ook dat weet je nooit zeker. Ik bedoel maar, je weet nooit wie wat waarom doet. Je zult nooit 100% de waarheid weten. Of de audit de moeite waard is is dus de vraag.

[Verwijderd]

Conclusie: waarom nog audits doen als je toch niet weet dat het bedrijf in kwestie integer is?

[Verwijderd]

Juist, alles lekker zelf doen. Daar schieten we wat mee op. Niemand meer vertrouwen. Zo gaan we een mooie toekomst tegemoet

[djpdjpnl]

Dus je moet maar vertrouwen hebben in iets waar niet van vast staat dat het te vertrouwen is? Gewoon omdat dat een betere toekomst zou brengen? Ik denk dat het juist een slechtere toekomst wordt dan. Het is niet alsof deze diensten ineens gaan stoppen.

[Verwijderd]

Ik ben blij dat je mijn post begrijpt. Ga niet eens de moeite doen om het uit te leggen.

[mphilipp]

Nee, twee audits laten doen door volstrekt random gekozen bedrijven. Maar ook dan kan er tussendoor gefraudeerd worden.

Wat maken we ons voor illusies? De NSA is een onderdeel van de regering. Een regering die zich bemoeid heeft met verkiezingen (en ze beïnvloed, met succes), infiltranten president van een land kunnen maken (Manuel Norriega), illegaal oorlog kunnen voeren, de hele wereld in de maling nemen, eigen geld/paspoorten/what have you kunnen drukken...need I say more? Ja, die kunnen alles doen.

Ben ik paranoïa? Nee, ik maak me er niet zo druk (meer) om. En op zich vertrouw ik die audit wel, maar garanties heb je absoluut niet. Onmogelijk. Ze zijn inderdaad heel erg machtig, als ze dat willen. Vraag is of ze ook dit willen kunnen beheersen. Ik denk dat ze dat zouden willen, maar niet al die moeite willen doen omdat het op enig moment spaak kan lopen. Zodra iets tè ingewikkeld wordt, is de kans op falen groter. Als het simpel kan, neem dan maar aan dat het gebeurt, dan ben je van de onzekerheid af
Ik heb al genoeg vuile streken van de VS gezien om nog enige reserve te hebben. Wie denkt dat het meevalt, check 'The untold history of the US' van Oliver Stone maar. Da's geen conspiracy geleuter, maar feiten.

[Dragonheart-03]

Met conspiracy denken kom je er ook niet.

[SED]

twijfel jij nog aan de mogelijkheden van de NSA dan?

[Dragonheart-03]

De NSA heeft zat veel mogelijkheden. Maar Snowden het zwijgen opleggen lukt niet. De 'macht' is dus toch erg relatief.

Maar problematisch aan een heleboel comments is dat er ook teveel macht aan de NSA wordt toegedicht.

In Conspiracy land worden er ook wel een aantal issue's bedacht die complete fantasie zijn.

[SED]

Klopt, maar akelig genoeg blijkt de realiteit zelfs verder te gaan dan conspiracy thinkers ons lieten weten. Als je kijkt naa rhet overzicht van NSA activiteiten dan staan daar zaken die niemand voor mogelijk gehouden had.
Onderschatten van de NSA lijkt me erg gevaarlijk. Overschatten van hun mogelijkheden blijkt nauwelijks mogelijk.

[Dragonheart-03]

En dit is dus wat ik net bedoel. : Onderschatten van de NSA lijkt me erg gevaarlijk. Overschatten van hun mogelijkheden blijkt nauwelijks mogelijk.

Dat houdt nl. geen steek.

Er zijn al jaren mensen die vraagtekens zetten bij bepaalde technieken en of middelen zonder door te slaan in conspiracy denken.

Het probleem is dat men het niet juist kan inschatten wat nu wel of niet gebeurt en wat wel of niet met een goede reden gebeurt.

Ook de burger zal zich beklagen bij de politicus cq de overheidsdienst als er niet is ingegrepen.

Het is in principe nooit goed - of de burger klaagt over het feit dat er niet of onvoldoende is ingegrepen (voorkomen dat er een risico op onveiligheid ontstaat) of men klaagt over het feit dat de inbreuk te groot is. Dit is een dilemma waar men soms in doorslaat zowel bij de burger als bij de overheidsambtenaar die het op dat moment bedenkt.

[SED]

Misschien een goed idee voor je omdeze ( inmiddels alweer deels achterhaalde en dus incomplete) lijst eens door te kijken.
Je bent duidelijk niet volledig geinformeerd.

http://www.peaceactionwi....snowdens-nsa-revelations/

[Dragonheart-03]

Alles wat je op internet doet KAN gelogd worden. De vraag is ALS je alles logt, kun je het dan ook efficient gebruiken.

Er is een verschil over 'verontwaardiging over inbreuken waarvan men dacht dat deze niet gebeurden' en er is 'het toekennen van een almacht' aan de NSA.

Dat het een gebeurt, impliceert niet per definitie dat de NSA ook alles kan. Bijv. terreuraanslagen voorkomen. Het is dat onderscheid dat er vaak niet wordt gemaakt en zeer relevant is in casu.

[SED]

Niemand (zeker ik niet) kent een almacht toe. Naïviteit over hun mogelijkheden is wat misplaatst als je ziet welke zaken er nu uitlekken. Dat is nog maar een deel van wat ze doen/deden.
Er is de NSA zelfs veel aan gelegen dit soort geluiden te laten horen: "het valt allemaal wel mee en de aandacht gaat vanzelf over".
Maar het staat je vrij ze te onderschatten.