Truecrypt-ontwikkelaars overwegen EU-klacht tegen Microsoft

De ontwikkelaars van de opensource-versleutelingssoftware Truecrypt overwegen een aanklacht tegen Microsoft bij de Europese Commissie in te dienen als deze de api voor de slaapstand van Windows niet openbaar maakt.

De Truecrypt-ontwikkelaars willen toegang tot de slaapstand-api van Windows om hun encryptiesoftware veiliger te kunnen maken. Als Microsoft geen gehoor aan de oproep geeft, volgt mogelijk een klacht bij de Europese Commissie, bericht Heise Online. Sinds versie 5.1 ondersteunt Truecrypt de Windows-slaapstand in combinatie met het versleutelen van systeempartities.

Een Russische beveiligingsdeskundige claimt echter dat de encryptiesleutel in de slaapstandmodus onversleuteld op de harde schijf wordt opgeslagen. Hackers kunnen deze sleutel uitlezen, waarna de partitie benaderd kan worden. De hack is te voorkomen door enkele Windows-bestanden aan te passen, maar een systeemupdate van Microsoft voor Windows kan die workaround teniet doen, dus hebben de ontwikkelaars de hulp van Microsoft nodig. Hoewel de beschrijving van de hack wat fouten bevatte, heeft Truecrypt de authenticiteit ervan toegegeven, al zeggen de ontwikkelaars dat de kwetsbaarheid zich alleen voordoet met een raid-systeem op basis van Intels Matrix Storage-technologie.

Reacties (48)

[Rembert]

Kan iemand me uitleggen hoe die onversleutelde encryptiesleutel dan in op de harddisk terecht komen? Want dat zou betekenen dat die data tevoren ook ergens in het geheugen staat - die zou je immers ook uit kunnen lezen (hoe protected is het geheugen?): hybernation betekent stomweg een memorydump - zou je die dump met andere software maken, dan heb je ook die key in handen.

al zeggen de ontwikkelaars dat de kwetsbaarheid zich alleen voordoet met een raid-systeem op basis van Intels Matrix Storage-technologie.

De speeltuin is vast nog kleiner hoor: het betreft met name Windows 2000 systemen.

[Kaasje123]

Tuurlijk staat die sleutel ook in het geheugen op het moment dat je hem gebruikt anders kan je niks decrypten. En als je niks unmount aan versleutelde paritties/file containers voordat de computer in hibernation gaat ja dan krijg je dit soort tafarelen. Unmount je eerst de encrypted dingen dan heb je er geen last van.

[b0On]

Ze eisen wel van Microsoft dat ze deze code vrijgeven maar ze geven geen argumenten waarom het dat wel zou MOETEN. Ik denk dat Microsoft helemaal niets vrijgeeft!

[simplicidad]

Ze eisen geen code, ze eisen toegang tot een ongedocumenteerde API die er klaarblijkelijk is.

Wat dacht je van de reden dat concurrenten bepaalde features niet kunnen integreren en Microsoft wel omdat die laatste over api calls kan beschikken zodat ze zo hun eigen producten een concurrentieel voordeel kunnen bieden. Klinkt dat bekend ?

[Reactie gewijzigd door simplicidad op 29 juli 2024 22:32]

[miw]

Het probleem bij het vrijgeven van dergelijke API's is dat na publicatie de API ondersteund moet worden in toekomstige versies van een OS. Dat geeft een behoorlijke hoeveelheid werk omdat deze nieuwe interface nu ook onderhouden moet worden. Er zijn dus goede redenen om deze API niet vrij te geven. Het is natuurlijk ook mogelijk om een ongedocumenteerde functie uit het OS te gebruiken. Het achterhalen van deze slaapstand API is minder werk dan een stapel juristen de API op te laten vragen via de EU.

[Blokker_1999]

Daar ga ik niet mee akkoord.

Een API bestaat omdat MS deze zelf ook gebruikt en andere MS Software kan dus ook deze APIs aanspreken. Daarnaast is er geen enkele verplichting van MS om een API te blijven ondersteunen in nieuwe versies van het OS.

[Atmosphere]

Nou het is wel degelijk zo dat MS iets vrij kan wijzigen aan een API en dat deze zeker niet vast staan. Echter MS heeft een aantal API's vrijgegeven waarvan je mag uitgaan dat ze nog wel even ondersteund zullen worden.

Het hele doel van een API is namelijk er een zo goed als mogelijk onafhankelijke laag wordt gemaakt. Op deze manier kan 1 applicaties tegen een heel arsenaal aan diverse type en merken hardware spreken.

Dat MS de API niet vijgegeven heeft kan zijn omdat ze speciale functies e.d. hebben geintegreerd in deze API welke veiligheidsgevoelig zijn of misschien gevolgen kunnen hebben voor systeem stabiliteit. Misschien gebruiken ze een gelicenseerde techniek waar zij zelf geen rechten hebben om daar documentatie van vrij te geven.

MS heeft gewoon een goede reden om het niet aan de 'grote' klok te hangen, en misschien wel omdat inderdaad de volledige systeemstand wordt weggeschreven (zoals wij verlangen) met encryptiesleutels en alles. Als ontwikkelaar van encryptiesoftware is dit handig om te weten zodat je hier misschien een aktie op kan ondernemen.

Een exploit hiervan zou overigens wel inhouden dat de machine uitgeschakeld moet worden, de schijf fysiek verwijderen en mounten om zo de dump-file te kunnen bekijken.

[dusti]

Een exploit hiervan zou overigens wel inhouden dat de machine uitgeschakeld moet worden, de schijf fysiek verwijderen en mounten om zo de dump-file te kunnen bekijken.

hmmz, zelfs nog niet.
-> live linux cd booten en dan maar de dump file analyseren...
en als je erover nadenkt zullen er nog wel mogelijkheden zijn.

[elmuerte]

Een API ondersteunen? Daar heb ik nog nooit van gehoord.
En het is geen nieuwe API die geproduceerd moet worden, het is een bestaande API waarvan MS de documentatie niet vrijgeeft.

[Devil_Inside]

Geen argumenten?

Het feit dat de door hun ontwikkelde encryptiesleutel onbeveiligd word opgeslagen wanneer de computer in slaapstand gaat, en het voor hackers kinderspel is om deze te verkrijgen en zo de hele beveiliging makkelijk te omzeilen is geen goed argument voor jou? En ze willen geen toegang tot de code, maar toegang tot een API, dat is wat anders dan de daadwerkelijke code.

Om nou inderdaad onmiddelijk beginnen te dreigen is in mijn ogen niet nodig, er kan eerst ook gewoon rustig met Microsoft gepraat worden om samen tot een oplossing te komen. Maar waarschijnlijk denken ze dat dit te lang zal duren, en door te dreigen met een klacht hopen ze waarschijnlijk dat Microsoft ook een beetje vaart hierachter zet.

[]Byte[]

Misschien moet je de tekst dan nog eens lezen en misschien dat je het dan wel ziet...

Maar wat ik mij nu zo bedenk... Hoe zit dat met andere encryptie-software als bijv. SafeGuard?!?
Hebben die daar dan ook last van?

[BlackOwl]

Ja
nieuws: Dram lekt encryptiesleutels harde schijf

[Kaasje123]

Dat gaat over iets heel anders dat heeft niks met de slaapstand te maken. Het artikel waar jij naar linkt gaat het erom dat de gegevens via koeling nog enkele seconden in het geheugen blijven hangen ook na uitzetten van de pc zodat de encryptie sleutel daaruit gelezen kan worden.

[WinL]

Losstaand van deze discussie is het wel merkwaardig dat Microsoft alle functies van Windows moet vrijgeven. Let wel, ik schrijf 'functies'. Een API is een interface van een systeem, in dit geval Windows. Niet alle in C/C++ geschreven functies maken deel uit van een API. Het zou namelijk van de zotten zijn als Microsoft juist wel al die functies moet vrijgeven.
De vraag is dus wat wel en wat niet tot de API behoort. In principe bepaalt Microsoft dat. Alhoewel zij zich wel zelf in de vingers snijden als ze bepaalde functies zoals CloseHandle(...) niet vrijgeven.
Verder, iedere keer wordt op tweakers.net gevraagd waarom Microsoft dit moet vrijgegeven. Iedere keer antwoorden weer andere mensen van tweakers.net dat het komt omdat Microsoft een monopoliepositie geeft. Dus, concluderende hieruit hoeft een klein bedrijf zich niet aan de regels te houden en een wat groter bedrijf wel? Vreemd.... Hoezo een vrijemarkteconomie?
Als laatste is het ook nog zo dat de functies waarover het hier gaat, tot de kern van het OS behoren, waar cliëntapplicaties in feite niets van hoeven te merken. Wellicht dat Microsoft er ook niet van bewust was dat derden functionaliteit hiervan direct willen aanroepen.

Overigens houd ik geen pleidooi voor Microsoft, wel wil ik laten zien dat er met twee maten gemeten wordt. Wordt betreft de reactie van Microsoft over dit onderwerp weet ik niet veel, daarom dat ik dat ook laat voor wat het is.

[RedLizard]

Dus, concluderende hieruit hoeft een klein bedrijf zich niet aan de regels te houden en een wat groter bedrijf wel? Vreemd.... Hoezo een vrijemarkteconomie?

Nee, voor een klein bedrijf gelden andere regels als voor een groot bedrijf. Hoge bomen vangen veel wind, en als je 90% van de markt wil bedienen zul je ook verregaande verantwoordelijkheden moeten accepteren.

Als laatste is het ook nog zo dat de functies waarover het hier gaat, tot de kern van het OS behoren, waar cliëntapplicaties in feite niets van hoeven te merken. Wellicht dat Microsoft er ook niet van bewust was dat derden functionaliteit hiervan direct willen aanroepen.

Behalve dat Microsoft's eigen cryptografiesoftware - een directe concurrent van Truecrypt - wel gebruik kan maken van deze functies. Microsoft gebruikt dus zijn gewicht in de OS-markt om een voordeel te verkrijgen in de cryptografiemarkt, en dat is misbruik van een monopoliepositie.

[roy-t]

Volgens mij hebben ze niet echt netjes in klacht ingedient, in de nieuweste changelog (van vandaag op t.net) staat dit

Remark: As Microsoft does not provide any API for handling hibernation, all non-Microsoft developers of disk encryption software are forced to modify undocumented components of Windows in order to allow users to encrypt hibernation files. Therefore, no disk encryption software (except for Microsoft's BitLocker) can guarantee that hibernation files will always be encrypted. At anytime, Microsoft can arbitrarily modify components of Windows (using the Auto Update feature of Windows) that are not publicly documented or accessible via a public API. Any such change, or the use of an untypical or custom storage device driver, may cause any non-Microsoft disk encryption software to fail to encrypt the hibernation file. We plan to file a complaint with Microsoft (and if rejected, with the European Commission) about this issue, also due to the fact that Microsoft's disk encryption software, BitLocker, is not disadvantaged by this.

IK neem aan dat MS toch echt wel meer tijd dan een week (veel ouder kan de changelog niet zijn) nodig heeft om de claim te verrifieren en uberhaupt alle no-name opensource zeurders te filteren van terechte claims.

Het kan natuurlijk best zijn dat MS niet mee wil werken (gebeurt wel vaker voor goede en soms hele slechte redenen) maar ik vindt dat je ze op een minst toch wel een maand de tijd moet geven en niet meteen gaan zeuren!

[SunnieNL]

Volgens die quote kan het al gebeuren door gebruik van een untypical of custom storage device driver.. wanneer is iets een custom device driver??
Volgens mij is elke device driver gemaakt door een leverancier custom voor het product dat wordt ondersteund. De basis device drivers die MS standaard meelevert gebruikt toch hopelijk niemand als de fabrikant al een driver heeft gemaakt??


Daarnaast is nog helemaal niet bewezen dat BitLocker van deze niet gedocumenteerde API gebruik maakt en het probleem zelf ook niet kent? Wie zegt dat die API het probleem oplost als je niet weet wat die API precies doet?

[Reactie gewijzigd door SunnieNL op 29 juli 2024 22:32]

[joho]

Het lijkt me niet echt zinvol om een encryptie applicatie te bouwen op een gesloten systeem als Windows. Je hebt geen inzicht in de werking, kan eventuele achterdeuren niet zien, en geen aanpassingen maken om jouw applicatie naadloos te integreren.

[SirBlade]

Meteen beginnen met dreigementen is echt de juiste manier als je iemands hulp nodig hebt. Hebben ze al een onderbouwd verzoek bij MS ingedient om die informatie te krijgen?

[Dutch_Razor]

Ehm, waarom denk je dat er zoveel kritiek is op Microsoft en API's? Dr zijn genoeg bedrijven die gesmeekt hebben om toegang tot de API's maar MS weigert steevast, soms geven ze dan een heel klein beetje vrij.

[Verwijderd]

Daarintegen lees ik nooit eens dat MS betaalde licentie's eventueel weigerd en dat is ook het hele proleem wat ik heb tegen bedrijven die "eisen", er word nooit gesproken over "geboden".

En dat lees ik ook nooit terug in het hele EU verhaal, kan het mis hebben. MS kan alleen maar winnen lijkt mij als ze bepaalde api's in licentie geven en voorkomen daarmee dat hun hele code op straat komt te liggen want hoe meer er vrij komt hoe gevaarlijker het weer word voor misbruikers. En ze mogen er toch voor betaald worden

[Verwijderd]

Er is wel een verschil tussen een API documenteren en je code op straat leggen.

Als je een API bouwt, dan doe je dat om te zorgen dat andere software met het stuk software waar je die API in bouwt kan communiceren. Als je dan vervolgens niet vertelt hoe je daarmee moet communiceren, valt het hele nut voor iedereen (behalve jij zelf) weg.

Mooi voorbeeld is de API van Java: hier is de werking van alle klassen netjes beschreven en kan iedereen ermee werken, hoewel bijna niemand weet hoe doe klassen dan precies geprogrammerd zijn.

[Cameleon73]

... hoewel bijna niemand weet hoe doe klassen dan precies geprogrammerd zijn.

Oh, jawel hoor. Zodra je de Java SDK installeeert, heb je gelijk alle sources te pakken. Kijk maar 'ns naar een src.zip in je SDK installatie map.

[Verwijderd]

Maar dat is geen onderdeel van de API die staat namelijk geheel online.

[Sv3n]

API != code

Een API beschrijft alleen maar welke functies er zijn en wat ze doen:

The software that provides the functionality described by an API is said to be an implementation of the API. The API itself is abstract, in that it specifies an interface and the behavior of the identifiers specified in that interface; it does not specify how the behavior may be implemented.

Wat men dus wil is dat Microsoft die beschrijvingen vrij geeft zodat andere ontwikkelaars op de juiste manier gebruik kunnen maken van functionaliteit die Windows biedt.

Daarnaast Linux is toch ook niet onveilig omdat de code openbaar is ? Dat het gevaarlijk is, is dus onzin.

[Emielio]

Jij maakt zeker een grapje, dit soort dingen worden vaak eerst met tig verzoeken opgevraagt, maar hier geven ze bij ms gewoon geen gehoor aan. Kijk een gemiddelde opensource mailinglist er maar eens op na, bedrijven geven nooit info vrij om het een en ander compatible te maken.

[Webdoc]

Is dat de nieuwe hit... dreigen met een EU actie naar Microsoft als je iets van ze wil?

[R-O-Y]

Er staat niet of ze wel of niet met MS overlegd hebben. Dus er stomweg vanuit gaan dat ze dat niet gedaan hebben is ook niet goed. Het lijkt mij dat je pas naar de EU gaat als het echt niet meer werkt. Gelijk gaan dreigen schiet niemand wat mee op.

[daft_dutch]

"Als Microsoft geen gehoor aan de oproep geeft...."

[simplicidad]

Als Microsoft , zoals het hoort , al hun api's voldoende begint te documenteren dan zouden er weinig redenen zijn om te dreigen met een EU actie.

[Verwijderd]

En waarom zou Microsoft alle APIs beschikbaar moeten maken?

[Verwijderd]

Omdat MS een dominante (lees: monopolie) positie inneemt op de markt voor besturingssystemen.

Door het niet documenteren maken ze andere softwaremakers het onmogelijk hun software op een goede wijze te laten integreren met Windows. MS weet dit ook want ze komen heel vaak met een eigen programma die dan vaak ook nog heerlijk geïntegreerd wordt toegevoegd via een MS update...

[smokalot]

Omdat MS niet alleen een OS maakt, maar ook veel applicaties, en het is oneerlijk als MS wel gebruik kan maken van die APIs, en concurrerende software niet.

[Countess]

omdat de EU ze dat heeft opgedragen, om te voldoen aan de anti-monopoly wetgeving.

[? ?]

Omdat de wet dat hier zegt

[bbob]

omdat in dit geval truecript aansprakelijk kan zijn als blijkt dat de hack echt is. De veiligheid van hun product staat hiermee op het spel en het is niets meer dan logisch dat microsoft openheid geeft om het probleem op te lossen.

[apokalypse]

Ik dacht altijd dat het handiger is om het eerst aardig te vragen ipv meteen te dreigen.

OffT: mooi programma, dat TrueCrypt

[bush]

Niet alle API's moeten public zijn, sommige zijn private en zo hoort het ook.
Hoe meer API's public zijn hoe meer software er afhankelijk van wordt wat er op z'n beurt voor al zorgen dat je deze API's niet meer kan wijzigen (backwards compatible)

[Kaasje123]

Dat is dan toch de verantwoordelijkheid van de makers om hun software te voorzien van een update? Je kan Microsoft niet altijd de schuld geven van het feit dat ze hun eigen software van een update voorzien.

[elmuerte]

Regel 1 van een interface: eenmaal gepubliceerd (intern of extern, maakt niet uit) veranderd het nooit meer. Als je iets wilt verandered doe je dat door een nieuw element toe toevoegen, de oude interface blijft bestaan.

[Het.Draakje]

Sinds wanneer kunnen functie-calls niet obsolete meer worden ?
Of zelfs discontinued ?

Het feit dat het in een API staat, maakt de functie nog niet 'eeuwig' geldig.

[elmuerte]

In het geval van deprecation (wat je doet als een oude interface vervangen word door een nieuwe) zullen de oude interfaces een redirect krijgen naar de nieuwe interface. Het is dan niks anders dan een wrapper.

Voorbeeld interface:
@Deprecated
FileHandle open(String filename);

FileHandle openEx(String filename, FileMode mode);

Implementatie van open(String):
FileHandle open(String filename)
{
return openEx(filename, FM_ReadWrite & FM_Exclusive & FM_Binary);
}

Als de oude specificatie niet duidelijk genoeg was om de implementeren in de nieuwe specificatie gebruik je de meest descrutieve manier. (die de meeste rechten nodig heeft, en het snelst niet geldig is).

De feature set van een API zal zelden kleiner worden. Alleen in het geval van het opsplitsen van een API zal deze kleiner worden, maar je krijgt dan meerdere APIs.

Pas in een volgende generatie zou je kunnen overwegen om deprecated elementen te verwijderen. (gen1 -> gen2 -> ... -> genN)
dus: active -> (deprecated)+ -> removed
maar nooit: active -> removed

[Reactie gewijzigd door elmuerte op 29 juli 2024 22:32]

[Het.Draakje]

quote: active -> (deprecated)+ -> removed

Dus zoals ik zei : (of het nu in twee, drie of zes versie's gebeurd) een API-call is niet eeuwig.

Dus dit kan nooit de reden zijn om een API niet te publiceren.

[Verwijderd]

Ik snap echt niet waar dit nu weer over gaat. Ik kan nergens iets vinden van een eis dat MS alle api's moet documenteren en moet vrijgeven.

De eis was specifiek gericht op documentatie die gaat over communicatieprotocollen voor Windows Server-software.

[blouweKip]

Het gaat erom dat truecrypt dezelfde mogelijkheden wil als het concurrerende product dat microsoft aanbied, je eigen product bevoordelen door api's te onthouden aan developers is stout, en dus mag t niet.