Het is 2018. We leven in de toekomst. We kunnen een pizza bestellen, kijken hoe het wordt gemaakt en zien hoe het bij ons thuis wordt afgeleverd. Dus waarom kunnen we niet online stemmen?

Laten we beginnen met wat achtergrondinformatie over wat programmeertalen zijn en waarom we ze nodig hebben. Binnenkort zul je zien waarom je nooit online zou willen stemmen (en waarom je nooit een computer bij je in de buurt wilt wanneer je stemt).

U weet waarschijnlijk dat computers op binair, 1'en en 0'en werken. En schrijven in binair schrift is moeilijk - zo moeilijk zelfs, dat eigenlijk niemand het wil doen. Zelfs als je erin slaagt om het te doen, is wat je produceert gewoon een heleboel getallen, en het zal heel moeilijk zijn voor iedereen - inclusief jij over een paar weken, als je eenmaal vergeet wat je hebt geschreven - om erachter te komen wat je code is eigenlijk wel.

Dus in plaats daarvan hebben wij computerwetenschappers 'machinetalen' uitgevonden. Dit zijn abstracties die binaire code veranderen in iets dat op zijn minst een beetje dichter bij de talen ligt die mensen spreken. Ze zijn nog steeds eenvoudig, maar ze zijn een stap in de goede richting. Machinetalen zijn gebaseerd op - en gekoppeld aan - de hardware van de machine waarvoor ze zijn ontworpen. Dus hoewel je niet iets eenvoudigs kunt zeggen als "10 en 20 bij elkaar optellen en dat resultaat op het scherm afdrukken," kun je zeggen "plaats de waarde 10 in register één, plaats de waarde 20 in register twee, voer beide registers in voeg een toe en plaats de uitvoer in register drie en druk de inhoud van register drie af op het scherm. ' .

Er zijn hier duidelijke nadelen: je moet bekend zijn met de hardware van je computer om in een machinetaal te schrijven, en de architectuur van elke computer is iets anders. Bovendien moet u elke stap van het proces expliciet specificeren. Dat is lastig. Maar het voordeel is dat wanneer je onderweg naar een programma kijkt dat in machinetaal is geschreven, wat er gebeurt veel duidelijker is - vooral in vergelijking met een eindeloze stroom van nullen en enen in binair getal.

Wat u ook schrijft, u vertrouwt erop dat de compiler nauwkeurig wat u heeft geschreven, omzet in binaire code. Als ik met je resultaten wilde rotzooien, hoef ik alleen maar met je compiler te rotzooien.

De volgende stap is om de hardware te abstraheren, zodat u niet echt de locatie hoeft te weten van dingen als 'adders' en 'registers'. Als u een slim genoeg compiler bouwt, kunt u machine-onafhankelijke programmeertalen ontwerpen, met meer abstracte instructies die gemakkelijk zaken als "voeg 10 en 20 bij elkaar te voegen, en druk dat resultaat af op het scherm". U zou dan op de compiler vertrouwen om dat in machinetaal en vervolgens in binair te vertalen.

Hoewel al deze programmeertalen verschillende benaderingen hanteren om dit probleem op te lossen, hebben ze hetzelfde doel: computercode gemakkelijker leesbaar maken voor mensen, waardoor het gemakkelijker te begrijpen en te onderhouden is. Met programmeertalen van vandaag is afdrukken van het resultaat van 10 + 20 net zo eenvoudig als het schrijven van dit:

print 10 + 20

Heb je de reden ontdekt dat je geen enkele computer kunt vertrouwen?

Ik geef je een hint: het is er in de compiler.

Wat u ook schrijft, u vertrouwt erop dat de compiler nauwkeurig wat u heeft geschreven, omzet in binaire code. Als ik met je resultaten wilde rotzooien, hoef ik alleen maar met je compiler te rotzooien.

Als ik bijvoorbeeld de opdracht "afdrukken" veranderde, zodat deze altijd 1 toevoegt aan de cijfers die u hebt opgegeven, wordt uw programma niet correct uitgevoerd, ook al hebt u het correct geprogrammeerd. U zult de glitch nooit vinden door alleen naar uw broncode te kijken, want dat is niet waar de glitch is. Het is verborgen in de compiler.

Dat voorbeeld is eenvoudig en je zou het vrij snel detecteren omdat je programma duidelijk kapot zou zijn. Maar wat als ik iets subtielers zou doen? Wat als ik in plaats van te rotzooien met het commando "print", de compiler veranderde zodat telkens wanneer code met wachtwoorden werd gedetecteerd, het ook zo werd gebruikt dat het wachtwoord "ryaniscool" ook werkte?

Het is niet het einde van de wereld als iemand hackt en ziet dat mijn pizza wordt bezorgd. Niemand geeft genoeg om het te proberen te breken. Maar stemmen is niet een van die gevallen.

Als ik dat deed, zou ik een "achterdeur" hebben in elk computerprogramma dat je met mijn compiler bouwt. Met andere woorden, je kunt je voordeur op slot doen, maar dat doet er niet toe, want ik heb een geheime deur achterin waar niemand iets van weet. Wat je ook schrijft, hoe veilig je wachtwoordcode ook is, mijn wachtwoord van "ryaniscool" werkt ook - en je weet het niet eens.

Dit is duidelijk een probleem. En je zou kunnen denken: “Maar compilers zijn computerprogramma's zoals alle andere. Ik zou de broncode van mijn compiler kunnen bekijken om te controleren of er geen schadelijke code is. Het enige dat ik hoef te doen, is het gedeelte vinden dat spreekt over het toevoegen van ‘ryaniscool’ als wachtwoord, het verwijderen en het komt goed. Rechtsaf?"

En dat zou je kunnen. Behalve, zoals je zei, zijn compilers computerprogramma's zoals alle andere. En dat betekent dat ze zelf zijn samengesteld.

Dit is alles wat ik zou moeten doen om dat te benutten:

Stap 1

Zoals eerder, zou ik code schrijven die "ryaniscool" als een geldig wachtwoord toevoegt aan alles wat hij compileert en dit in de compiler plaatsen. Op dit moment voeg ik een achterdeur toe aan alles wat de compiler compileert, maar ik word betrapt als iemand naar de bron van mijn compiler kijkt. Dus ga ik verder met stap 2.

Stap 2

Ik schrijf code voor de compiler die detecteert wanneer hij zichzelf compileert, en wanneer dat gebeurt, voegt hij de code voor stap 1 toe aan de compiler. Nu, wanneer ik de compiler compileer, maakt hij een nieuwe versie van zichzelf die compilerinstructies toevoegt voor het invoegen van het "ryaniscool" -wachtwoord wanneer de compiler opnieuw wordt opgebouwd. En om mijn tracks te dekken, hoef ik alleen maar de kwaadaardige instructies uit de compilerbron te verwijderen en ik ben klaar.

Wanneer de compiler opnieuw wordt opgebouwd, bouwt deze zichzelf zodanig dat deze instructies bevat om mijn achterdeur toe te voegen. Wanneer die compiler iets anders bouwt, volgt deze instructies en bouwt mijn achterdeur meteen in. En er is geen enkele regel schadelijke code meer in elke broncode die het onthult.

De enige manier om deze bug te detecteren, is om zelf de binaire code te doorlopen - een taak die moeilijk begint en letterlijk onmogelijk wordt naarmate programma's complexer worden. Het complete werk van William Shakespeare komt uit op minder dan 6 megabytes. Alleen al de Firefox-browser vereist 200 megabytes om het te installeren, en dat is slechts één programma op uw computer. Er is geen mens in leven die alle 200 megabytes van die code heeft gelezen. Het is zelfs niet geschreven in een taal die is ontworpen voor mensen om te lezen.

Waarom gebruiken we deze nachtmerriemachines?

Niets hiervan is nieuw. In 1984 presenteerde Ken Thompson - de man die Unix ontwierp en implementeerde, de voorloper van de besturingssystemen waarop de meeste computers en telefoons draaien - een paper genaamd "Reflections on Trusting Trust" en kwam tot deze conclusie:

De moraal is duidelijk. Je kunt de code die je niet helemaal zelf hebt gemaakt niet vertrouwen ... Geen enkele hoeveelheid verificatie op bronniveau of controle zal je beschermen tegen het gebruik van niet-vertrouwde code.

Met "volledig zelf maken" bedoelt Ken niet alleen een programma dat u hebt geschreven, maar een programma waarvoor u de hele stapel hebt geschreven: alles tot aan de compiler. Zeer weinig mensen hebben de tijd, vaardigheden en geld om een ​​computer vanaf het begin te bouwen, inclusief alle software erop. Dit lijkt een kogel in het hoofd voor het vertrouwen van computers met alles.

En toch vertrouwen we op computers met allerlei dingen. Dus wat geeft? Waarom gebruiken we deze nachtmerriemachines?

Nou, ten eerste zijn computers echt leuk en handig. En ze zijn op veel manieren praktisch. Bovendien kan een compiler-hack in de praktijk lastig zijn: je hebt tijd en motivatie nodig om op iemand te richten. De waarheid is dat er in veel gevallen geen absoluut vertrouwen in je computer nodig is: het is tenslotte niet het einde van de wereld als iemand hackt en ziet dat mijn pizza wordt bezorgd. Niemand geeft genoeg om het te proberen te breken.

Maar stemmen is niet een van die gevallen.

De enige veilige manier om met een computer te stemmen is er een waarin een papieren stembriefje in het zicht van de kiezer wordt afgedrukt, goedgekeurd en vervolgens opgeslagen in een stembus.

Stemmen is een geval waarbij de uitkomst van een hack enorme gevolgen kan hebben. Stemmen is ook relatief eenvoudig te richten (je weet wanneer en waar het gaat gebeuren), en er is een zeer sterke motivatie om de uitkomst te veranderen. Zo gemakkelijk als ik dat "ryaniscool" -wachtwoord kon toevoegen, kon ik het "toevoegen" -commando wijzigen zodat het, wanneer het stemmen optelde, wat extra toevoegden voor de partij van mijn keuze.

Hoeveel moet ik toevoegen? Eerlijk gezegd is het helemaal aan mij. Vandaar deze conclusie: online stemmen zal nooit veilig zijn. Computerstemmen zal nooit veilig zijn.

De enige veilige manier om met een computer te stemmen is er een waarin een papieren stembriefje in het zicht van de kiezer wordt afgedrukt, goedgekeurd en vervolgens opgeslagen in een stembus. Op die manier, als iemand denkt dat de computersystemen zijn aangetast - als er überhaupt een reden is om te vermoeden dat iemand de stemmen onjuist heeft toegevoegd - dan is er een papieren spoor. Met andere woorden, de computer die de stemmen optelt, is een gemak, meer niet. De echte stem, de echte macht, ligt nog steeds in de papieren stemming.

Zonder dat papieren spoor vertrouw je de computer.

En niemand moet ooit een computer vertrouwen.

UPDATES:

Er zijn een aantal terugkerende thema's in de discussie rond dit essay geweest, dus ik dacht dat ik ze hier in Q + A-formaat zou opnemen! Het bovenstaande essay is niet gewijzigd, maar ik dacht dat het onderstaande nuttig zou kunnen zijn als je wat meer over dit onderwerp wilt lezen!

Vraag: Wat bedoel je met computerstemmen?

A: Ik heb het over een systeem waarin u uitsluitend op een computer stemt: er wordt geen papieren spoor gegenereerd. In dit geval is de computer de autoriteit op wat u hebt gestemd: er is geen andere bron die u kunt controleren.

Een ethische en veiligere manier om computers te gebruiken bij het stemmen is om ze niet als autoriteit, maar als een gemak te gebruiken. Als u op een papieren stemming stemt en een computer scant dat om een ​​resultaat op te tellen, kunt u zich veiliger voelen, want als er iets misgaat, is er nog steeds een fysiek papieren spoor. Als u op een computer stemt, maar vervolgens een papieren stembriefje wordt afgedrukt, waarvan u moet bevestigen dat deze juist is voordat uw stem wordt geregistreerd, dan kunt u zich ook veiliger voelen, omdat in beide situaties de computer een gemak is. Het is wanneer de computer een autoriteit wordt die de problemen doet rijzen.

Vraag: Kan dit niet worden opgelost door elke persoon die stemt op een geheime code, of een soort sleutel, of misschien kunnen we hun ogen of vingerafdrukken biometrisch scannen of zo? Of wat als we ergens op internet een back-up van de stemmen zouden maken?

A: Nee. Codes en sleutels kunnen worden onderschept of gedupliceerd, en elke biometrische scanner zou een computer zijn, kwetsbaar voor exact dezelfde problemen die hier worden besproken. En elk netwerksysteem - waarbij de computer het deelt stemt om ergens anders een back-up van te maken - hangt er weer van af dat niet wordt geknoeid. Sorry.

Vraag: Oké, maar misschien kunnen we onze programma's testen en kijken of onze gecompileerde code anders werkt dan we verwachten?

A: Dit werkt om een ​​aantal redenen niet. Natuurlijk, in mijn "verander de waarde van wat 10 + 20 optelt", zou dat gemakkelijk te testen zijn en eventuele wijzigingen opvangen. Maar zelfs als u dacht om dat in de eerste plaats te testen - en waarom zou u? - dat lost het probleem nog steeds niet op. Mijn kwaadaardige code kan detecteren wanneer het wordt getest en niets slechts doen, alleen actief worden wanneer je niet kijkt.

Klinkt als scifi, toch?

Nou, het is al gebeurd: in het Volkswagen-emissieschandaal van 2015 hebben de boordcomputers van de auto gedetecteerd wanneer hun emissies werden getest en uitgevoerd in een milieuvriendelijke modus met laag vermogen, en schakelden over naar een vervuilende modus met hoog vermogen toen de test voorbij was . De computers detecteerden wanneer ze werden getest, reageerden op hun beste gedrag en stopten toen de test voorbij was. Dit schandaal kostte Volkswagen 18,32 miljard dollar om op te lossen, exclusief de boete van 2,8 miljard dollar die ze betaalden.

De enige reden waarom Volkswagen dit in de eerste plaats zou doen, is omdat het voor hen winstgevend zou zijn en ze dachten dat ze niet zouden worden gepakt. Dezelfde prikkels zijn van toepassing op een verkiezing.

Vraag: Als ik gedwongen ben om op een computer te stemmen, betekent dat dan dat ik niet moet stemmen?

A: Nee, je moet toch absoluut stemmen. Het doel van bemoeienis met een verkiezing is om u te ontnemen. Als je niet stemt, ontneem je jezelf al met 100% efficiëntie. Ga stemmen en doe daarna wat u moet doen om ervoor te zorgen dat u nooit meer met computerstemmen hoeft te werken.

Vraag: Betekent dit dat we computers voor niets moeten vertrouwen?

A: In absolute zin: ja. Je moet niet 100% vertrouwen hebben in een computersysteem. Maar dat is duidelijk niet praktisch, en in de meeste gevallen hoeft u niet 100% vertrouwen in een computer te hebben. Een van de weinige gevallen waarin u zou stemmen is. De volgende vraag gaat hier dieper op in.

Vraag: Kom op. We doen online bankieren, miljarden dollars worden dagelijks digitaal verplaatst en u schreef dit zelfs op een computer. Je bent toch wel alarmistisch en / of hypocriet?

A: Dit is waar het idee van absoluut vertrouwen opkomt. Ik vertrouw computers niet absoluut, maar ik bank online. Maar dat komt omdat, als er iets misgaat, de bank het achteraf kan repareren. U gebruikt een creditcard, wetende dat er een kans bestaat dat uw informatie kan worden gestolen - maar als dat gebeurt, hebt u er vertrouwen in dat de creditcardmaatschappij deze zal repareren. En dat zullen ze ook doen - omdat de winst die ze met u maken wanneer u hun kaart elke dag gebruikt, de kosten voor het dekken van fraude en kapotte software goedmaakt.

Maar er is geen manier om een ​​gebroken verkiezing achteraf te corrigeren.

Het is allemaal een kwestie van compromissen: dit online publiceren was handig en ik deed het wetende dat mijn woorden konden worden gewijzigd. Er is een risico dat ze zouden kunnen zijn - maar uiteindelijk is het niet het einde van de wereld. Lage inzet en de voordelen opwegen tegen de nadelen. Evenzo doe ik online bankieren - omdat het ook handig is en ik een compromis wil sluiten omdat ik weet dat hoewel er een kans is dat mijn gegevens en / of geld kunnen worden gestolen, ik er relatief zeker van ben dat de bank het zal dekken. En ja, ik gebruik computers om vrienden $ 10 te sturen om ze terug te betalen voor het avondeten, maar ik doe het omdat de inzet zo laag is. Het is maar $ 10.

De inzet is niet laag als het gaat om stemmen.

En een kiesstelsel - een democratie - is niet iets waar je compromissen over wilt sluiten.

Vraag: Hoe zit het met blockchain? Je had blockchain moeten noemen. Dat is een nieuwe technologie die in 1984 niet bestond en die dit probleem zeker zou kunnen oplossen.

A: Nee, nee, nee. Sorry. Ik wou dat het ook werkte.

Vraag: Je weet niet waar je het over hebt en wie heeft je tot autoriteit gemaakt? Waarom zou ik je vertrouwen?

A: Zoals ik in het essay zeg, dit zijn niet mijn briljante originele ideeën. Ik herformuleer in feite wat Ken Thompson in 1984 in zijn artikel Reflections on Trusting Trust beweerde. Ken's argument is eigenlijk sterker: zijn voorbeeld is het inlogprogramma, waarvan een analoog op zowat elke computer wordt gebruikt. Ik heb het alleen over stemmen. Ken's paper staat al meer dan 30 jaar als een baanbrekend artikel in de informatica, maar het is niet bekend buiten de kringen van de informatica. Daarom wilde ik dit essay schrijven.

(Overigens is er een manier om de problemen te corrigeren die Ken aan de orde heeft gesteld en die ik heb geparafraseerd: je zou je code twee keer kunnen compileren, een keer met een nieuwe compiler en een keer met een bekende compiler. Als je de twee uitgangen vergelijkt en zij zijn de hetzelfde, je weet dat je compiler goed is. Dit roept natuurlijk de vraag op waar je die bekende-goede compiler vandaan kunt halen - hier is een proefschrift over dat onderwerp).

Vraag: Oké, zeker dat dit behoorlijk stoer is, maar dit is allemaal hypothetisch. We gebruiken computers om kernreactoren aan te sturen, om hardop te huilen. Als dingen niet veilig waren, zouden we het weten.

A: Een aanval die erg lijkt op degene die hier wordt besproken - waarin het bewijs van de aanval verborgen was - werd slechts een paar jaar geleden in het echt gedaan, met de Stuxnut-worm in 2010. En die viel aan - u raadt het al - nucleaire centrifuges .

Deze aanvallen gebeuren al. Whoops.

Vraag: Computerstemmen kan slecht zijn, maar papieren stembiljetten kunnen ook worden gewijzigd, weet u. Ze zijn ook niet perfect.

A: Absoluut. Maar papieren stembiljetten hebben een paar grote voordelen: hun nadelen worden goed begrepen (niemand schrijft grote essays over waarom je papier niet te vertrouwen is), en hun kwetsbaarheden zijn beperkt tot fysieke toegang.

Als ik wil knoeien met een papieren stembusverkiezing, moet ik stembiljetten stelen, of stembiljetten wijzigen, of stembiljetten - hoe dan ook, ik heb fysieke toegang tot die stembus nodig. En dat beperkt de hoeveelheid schade die een slechte acteur kan veroorzaken. Een verveelde tiener die de helft van de wereld weg is, kan geen papieren stemronde uit zijn kelder halen. Hetzelfde kan niet gezegd worden voor computerstemmen.

En bovendien is er een simpel feit: programmeurs zijn niet perfect. Zelfs als de aanval in dit essay niet wordt gebruikt, betekent dit niet dat uw computerstemsysteem veilig is. Heck, Google - waarvan ik denk dat we het er allemaal over eens kunnen zijn dat we heel slimme mensen inhuren - hebben een premiesysteem waarin ze je contant geld betalen als je hen helpt bij het vinden van bugs in hun eigen software, omdat ze niet kunnen garanderen dat ze niet hebben gemaakt fouten.

Software programmeren is moeilijk. Computers zijn hard. Zelfs een briljante, goedbedoelde softwareontwikkelaar kan een enkele fout maken die een hele softwarestapel opent voor inbraak. De Heartbleed-bug werd in 2011 per ongeluk geïntroduceerd - in open source software die in theorie iedereen op de planeet had kunnen bekijken, onderzoeken en detecteren - maar het werd pas in 2014 gevonden, waarbij 17% van de servers op internet waren nu kwetsbaar.

Dat gebeurde per ongeluk. Stel je voor wat iemand kan doen als ze het proberen.

Kijk, ik weet dat het zonde is om te horen dat computerstemmen slecht is. Het is een hele klus om buiten in de rij te staan, wanneer het zo eenvoudig is om je voor te stellen dat je tijdens je lunchpauze gewoon op een app op je telefoon stemt. Maar belangrijker dan een verkiezing die handig is, is dat deze nauwkeurig is, en hoewel computerstemmen zeker handig zou zijn, hoop ik dat ik u ervan heb overtuigd dat u niet moet vertrouwen dat deze nauwkeurig is.

Vraag: Is er een relevante xkcd?

A: Er is altijd een relevante xkcd.