Papers we love: Reflections on trusting trust: kun je je hard-, en software nog wel vertrouwen?

Om na de vakantie weer rustig op gang te komen is er deze week korte paper aan de beurt die je waarschijnlijk aan het denken zal zetten. De paper heet Reflections on trusting trust, komt uit 1984 en is geschreven door Ken Thompson. Het oorspronkelijke idee is zelfs iets ouder, maar bij het ontvangen van de Turing Award heeft hij het als speech aan het grote publiek  voorgelegd.

De compositie van de speech is briljant. Er is eerst een standaard dankwoord, daarna een hommage aan zijn meest belangrijke partner en vervolgens volgt er een triplet met de daadwerkelijke inhoud. Hierdoor wordt de echte impact van het stuk aan het eind van het drie-paginas tellende stuk in een keer duidelijk, waarna hij afsluit met een maatschappelijke noot.

In de eerste akte vertelt Ken hoe hij zich vroeger op school soms bezig hield met het schrijven van quines. Dit zijn programma’s die, wanneer ze worden uitgevoerd, de broncode van zichzelf reproduceren. Dit is best tricky, waardoor het algauw een competetief iets werd. Hoe korter deze programma’s waren hoe beter ze werden beoordeeld. Hij geeft een demo die niet extreem kort, maar wel correct is en twee belangrijke eigenschappen heeft. Het programma kan (eenvoudig) worden gegenereerd door een ander programma en hij kan een arbitraire payload bevatten die ook wordt meegenomen bij reproductie.

De tweede akte begint met een stukje uitleg over hoe de taal C met strings omspringt en dat de compiler voor C zelf ook in C is geschreven. Vervolgens beschrijft hij op een conceptuele manier hoe een language feature kan worden toegevoegd aan de taal. Om dit te kunnen gebruiken wordt de ‘oude’ C compiler gebruikt om de ‘nieuwe’ te maken, waarna deze wordt geïnstalleerd op het systeem. Vanaf dit moment is de language feature bruikbaar voor een ieder ander.

In de laatste akte laat hij, weer op een conceptuele manier, zien dat je de C compiler aan kunt passen om code anders te compileren dan eigenlijk zou moeten. Door bijvoorbeeld te matchen op code die wordt gebruikt om wachtwoorden te verifiëren op het moment dat een gebruiker inlogd kun je dus effectief een compile-time backdoor injecteren in een ander programma. Er is echter wel een nadeel: deze code zal snel opvallen zodra er een code review wordt uitgevoerd.

Bij het slot komen deze stappen samen: breng de backdoor-aanpassingen aan in de compiler broncode, distribueer deze compiler als een binary en haal de zelf-reproducerende backdoors weer uit je compiler broncode. Doordat er in de bron geen referenties meer te vinden zijn naar de backdoor, maar deze zichzelf wel reproduceert bij het compileren van nieuwe software heb je een systeem gecompromitteerd zonder dat je hier achter kunt komen. Linkers, debuggers en zelfs op microcode niveau zou op een identieke manier backdoors kunnen worden geintroduceerd.

De vraag is nu: wat kan je nog vertrouwen? Zelfs bij complete toegang tot de broncode en het zelf kunnen compileren van alle binaries ben je niet 100% zeker dat je veilig bent. Thompson sluit zijn speech met het aankaarten van een op dat moment maatschappelijk probleem. Nu heb ik zelf hier mijn ideeën over, maar in ieder geval is de situatie veranderd ten opzichte van hoe hij in de paper beschreven staat. Een tweede punt van reflectie, aangewakkerd door de titel, is naar mijn mening wel nog steeds compleet genegeerd.

De centrale vraag is: wie kun je vertrouwen? En hoeveel zekerheid heb je nodig? Als je dit op je werk betrekt, is dit dan een probleem bij de typische Sogyo opdracht? Of misschien bij enkele high-profile klanten? Misschien pas als er doden kunnen vallen? Gaat het dan over zaken als medische apparatuur (waar ook veel fout kan gaan…) of wordt het pas relevant bij de aansturing van militaire systemen waar bijvoorbeeld kernraketten onder vallen?

Dit is ook breder te trekken. Ons vertrouwen in compilers die juiste code produceren is groot en tampering zullen veel van ons als far-fetched beschouwen, maar dichter bij de dagelijkse realiteit zijn soortgelijke chain of trust problemen te herkennen. Welke root certificaten vertrouwen we allemaal om te bepalen of de S in https echt secure is? Vertrouwen we alle 349 root SSL certificaten die standaard met Windows worden meegeleverd? Zoals je ziet zijn dit veel vragen met vergaande implicaties waar vermoedelijk weinig over wordt nagedacht.

Nu wil Ik niet zeggen dat dit allemaal een probleem is, maar het is goed je bewust te zijn van de implicaties van vertrouwen op een computer en de bijbehorende systemen. We doen dit, impliciet of expliciet, namelijk al duizenden keren per dag, met honderden dienstverleners en tientallen apparaten. Met elkaar is dit de basis van onze samenleving. En hier kunnen we de code niet eens van zien..


Over deze papers we love: binnen Sogyo hebben we de traditie dat we maandelijks een nieuwsbrief rondsturen. De nieuwsbrief gaat veel over interne feitjes, echter sinds februari 2015 verzorgd Kevin van der Vlist het topic: papers we love. Hij deelt met ons papers die interessant zijn om te lezen en ons kunnen inspireren. De topic is uitgegroeid tot een mooie verzameling die we ook graag hier willen delen.