Valgdirektoratet lovet full åpenhet etter 2017-valget, men så langt kan kommunikasjonsstrategien deres best beskrives som radiostillhet, mener Torgeir Waterhouse i IKT-Norge.
I oppkjøringen til stortingsvalget 2017 oppsto det en debatt om sikkerheten i Norges valgsystemer.
Patricia Aas, en programvareutvikler med interesse for IT-sikkerhet, startet å stille spørsmål på Twitter og i en kronikk i VG.
Den «letteste» måten å manipulere et valg er å gå etter datamaskinene, programvaren og utviklerne som lager dem.
Patricia Aas i VG, 29. juni 2017
Hun mente at Valgdirektoratet (som ble etablert i 2016) ikke viste nok åpenhet i hvordan valget ble gjennomført. Spesielt reagerte hun på at noen stemmer kun ville bli talt av maskiner, som i verste fall kunne utnyttes av ondsinnede aktører til å vippe valget.
Frem mot valgdagen ble ulike potensielle sårbarheter omtalt av NRK og andre medier. Til slutt bestemte Kommunal- og moderniseringsdepartementet at alle stemmer skulle telles av et menneske i hvert fall én gang.
NRKbeta har på forespørsel fått tall fra Valgdirektoratet som viser at:
- Omtrent 950 000 stemmer i kommunevalget 2015 ble kun talt av maskiner. Dette er 40% av stemmene ved valget.
- Omtrent én million stemmer i stortingsvalget 2017 kunne kun blitt talt av maskiner, noe som tilsvarer hver tredje stemme.
Direktør for direktoratet, Bjørn Berg, sier til NRKbeta at de har «ingen indikasjon eller grunnlag for å si at det har vært forsøk på eller vellykkede angrep» i 2017-valget eller tidligere.
Kritisk til kun maskintelling
Ved gjennomføring av valg regnes det som god praksis å håndtere stemmer på papir og å gjøre kontrolltellinger mot fysiske stemmesedler sjekket av mennesker minst én gang.
I Norge har man regler for å telle stemmer i to omganger for å sikre at alle stemmer telles korrekt.
Torgeir Waterhouse i IKT-Norge forklarer problemet med å telle to ganger med maskiner slik:
– Det fine med en datamaskin er at om den først gjør en feil, gjør den gjerne samme feil på nytt.
Slik kan en feil, tilfeldig eller ikke, i verste fall føre til en systematisk skjevhet i enkeltpersoners eller partiers favør.
Ifølge Waterhouse er «ikke problemet at man bruker en maskin, men hvilke kontrollmekanismer man har», og før stortingsvalget i 2017 var han bekymret for at de ikke var gode nok.
– Utilsiktet praksis
Kommunal- og moderniseringsdepartementet har nå ute på høring en endring av valgforskriften. Der foreslår departementet at det i fremtidige valg skal kreves at alle stemmer skal telles av et menneske minst én gang.
– Det er en vurdering fra oss og departementet at det er en utilsiktet praksis som vi ønsker å korrigere gjennom en forskriftsendring, sier Berg.
Er du overrasket over at det var et så høyt tall som kun skulle telles maskinelt, siden du beskriver det som en utilsiktet praksis?
– Altså, forskriften har ikke tatt høyde for det. Det har ikke blitt fokusert på som en potensiell risiko. Vi fjerner nå en sårbarhet som vi anser det er lite sannsynlig at man skal bli utsatt for, men det er likevel viktig å korrigere den for å opprettholde tillit.
Valgdirektoratet oppgir at de ikke var kjent med at et betydelig andel stemmer kun ble talt av maskiner før forberedelsesfasen til valget i 2017.
- Maskinell stemmetelling går ut på at stemmesedlene scannes og at stemmetallet føres opp i et digitalt register.
- Ved stortingsvalget i 2017 omtalte VG og NRK enkelte sikkerhetsutfordringer. Det førte til at det ble påbudt å manuelt telle stemmer kort tid før valget.
- Kommunal- og moderniseringsdepartementet har nå et forslag ute på høring hvor hver stemme må telles at et menneske minst en gang.
- Elektronisk valgadministrasjonssystem (EVA) er det sentrale IT-systemet som brukes av kommuner og fylkeskommuner i forberedelse og gjennomføring av valg.
- EVA består av tre moduler. Kildekoden og systemdokumentasjon til disse skal publiseres løpende i 2019 – EVA Admin (januar 2019), EVA Skanning (april 2019), EVA Resultat (juni 2019).
«Radiostillhet» fra Valgdirektoratet
Torgeir Waterhouse beskriver Valgdirektoratets kommunikasjon i etterkant av 2017-valget med ordet «radiostillhet».
– Jeg hadde forventet mer åpenhet fra dem. Gitt det som skjedde i 2017 og det som ble sagt om åpenhet, er det bemerkelsesverdig.
Patricia Aas sier i dag at:
– Det går ikke an å få dem i prat om de ikke står på TV.
Hun sikter til en debatt hun hadde med Bjørn Berg 28. august. Der sier Berg blant annet:
– Du kan gjerne komme og se kildekoden på hele denne softwaren. Den er fullt åpen og tilgjengelig. Ved tidligere valg er kildekoden på disse systemene offentlig tilgjengeliggjort.
Kildekode er reglene en datamaskin jobber etter, og noe senere følger han opp:
– Dette er ikke noe hemmelighold rundt denne koden. Det er full åpenhet rundt det. Alle kan få det.
Valgdirektoratet har så langt ikke publisert den omtalte kildekoden, noe de har fått kritikk for av uavhengige valgobservatører.
Organisasjonen for sikkerhet og samarbeid i Europa (OSSE) påpeker i sin rapport om det norske valget at:
«Motstridende med internasjonale standarder og god praksis, var kildekoder ikke tilgjengelig for offentlig granskning før dette valget.»
Hva er deres kommentar til valgobservatør-rapporten der det påpekes at dere bryter med anbefalinger fra FN og Europarådet?
– Norge har helt siden 2009 invitert OSSE til å sende observatører til Norge. Rapportene blir behandlet grundig og ved flere anledninger har regelverket blitt endret som en del av dette. Anbefalingen om kildekoden følges opp nå, sier Berg.
Automatisert nyhetsbrev fra NRKbeta
Få et ping i postkassa hver gang vi publiserer noe interessant om teknologi eller medier!
Valgdirektoratet opplyser at systemet skal publiseres i tre faser, den første allerede i januar. I andre kvartal 2019 skal valgsystemet i sin helhet testes av uavhengige eksperter, og ifølge Berg skal det offentliggjøres en rapport fra testen.
I kjølvannet av valget har direktoratet også fått et eksternt selskap til å gjennomføre en full revisjon av kildekoden i valgsystemet. Berg ønsker på nåværende tidspunkt å ikke gå i detalj om funnene for å unngå å skape «unødvendig usikkerhet»:
– Hovedkonklusjonen er at vi har veldig sikre og gode systemer. Så er det avdekket enkelte områder hvor vi har et forbedringspotensial som vi nå ivaretar gjennom ulike tiltak. Det er ingen kritiske eller alvorlige forhold som vi mener kan ha påvirket resultatet i tidligere valg.
Berg sier også at de vil vurdere å publisere kildekoden fra 2017-valget samtidig med tilhørende kode for 2019-valget.
«– Det fine med en datamaskin er at om den først gjør en feil, gjør den gjerne samme feil på nytt.»
Artig formulert – selv om det altfor ofte er feil. En programutvikler / testers mareritt er når feilen bare oppstår en gang iblant: Søker du etter feilen er den borte! (Faghumor: «Heisenbugs». Eller «POM errors» – Phase-Of-Moon dependent errors – de som bare kan sees tirsdager og fredager.)
Men dette gjelder bare når du kjører programmet på samme maskin – her med «maskin» i utvidet tolking: Et program er en maskin.
NASA overvåker svært nøye alt som skjer ved oppskyting av en rakett. For noen år siden ble en oppskyting avbrutt: Fire separate, identiske maskiner avleste sensorer etc, gjorde sine beregninger etc. Alt dette ble også gjor av en femte maskin som var totalt uavhengig av de fire andre; det eneste de hadde felles var kravspesifikasjonen. Maskinen var designet og bygget av et helt uavhengig team (dette er ikke hyllevare PCer!), programvaren var utviklet helt fra grunnen av av et uavhengig team, testene var laget av et annet team.
Resultatene de fem maskinene kom til ble fortløpende jamnført av en (fysisk) femvegs komparator. Hvis ikke signalene fra alle fem var 100% identiske, ville oppskytingen bli stoppet. Den femte, uavhengig utviklede, var uenig. Oppskytingen ble stoppet.
Det er måten å gjøre det på: Gjør samme opptellingen med to ulike programpakker, utviklet helt uavhengig av hverandre. For telling av stemmesedler er det unødvendig å gå så langt som til å bygge to ulike maskiner. Men feil kan forårsakes av f.eks. biblioteker og kompilatorer, så de to implementasjonene bør heller ikke bruke samme verktøy. En måte å redusere risikoen for det er å bygge alternativene på hver sin plattform, f.eks. Linux og Windows, og ikke tillate at f.eks. gcc brukes på begge plattformer – det bør brukes ulike programmeringsspråk. Om det er mulig bør avlesing av stemmesedlene gjøres to ganger, med bruk av ulikt utstyr.
DA ville sikkerheten for at samme feil ble gjort to ganger være betydelig redusert.
I dagens politiske virkelighet der «skattebetalernes penger» er hellig og minimalisering av statens utgifter (aka reduserte skatter) er Det Aller Viktigste i valgkampene, er sjansene et godt stykke under null for at staten skal finansiere to ulike implementasjoner av et opptellingssystem. Da får vi heller leve med at samme feil gjøres to ganger. Og at vi utsetter de demokratiske mekanismene for en viss risiko.
Epilog:
De som kjenner historien om NASA-oppskytingen vet at de fem maskinene egentlig var enige, men den femte maskinen leverte sitt resultat til komparatoren én klokkesyklus tidligere (eller senere, det er uvesentlig) enn de fire andre. Ingen ble kritisert for den «unødvendige» utsetting av oppskytingen: En utsettelse er enormt mye billigere enn en mislykket oppskyting. Det er alltid best å være på den sikre siden – det var nettopp derfor det var laget et slikt dobbeltsjekk-system.
Kommentaren din er strålende. Kjekt å lese. Lærererik og «to the point».
Fortsett med slike bidrag. Takk!
Dersom eg hadde litt ressursar til rådigheit for å fuske med valprogramma i Norge, ville eg t.d. ha forsøkt å infisere kompilatoren på maskinene som skulle laga om kjeldekoden til lågnivåspråk.
Kanskje det er gjort allerede 🙂
Prinsippet er beskrevet i en av dataverdenens mest berømte foredrag, «Reflections on trusting trust» (Ken Thomsons «Turing Award Lecture», 1984). Ytterst få 34 år gamle data-foredrag er stadig aktuelle – dette er en av dem. Det finnes på nettet et stort antall videre diskusjoner og utbroderinger av prinsippene, f.eks. hvordan en trojaner kan migrere på binærnivå inn i en kompilator for et helt annet språk.
Det er hard realitet at det kan finnes trojanere i ethvert program som genererer binærkode (mest åpenbart: en kompilator), som det er tilnærmet fullstendig umulig å oppdage. Den opprinnelige kildekoden til trojaneren behøver ikke ha vært i nærheten av kompilatoren som har den i seg, den kan ha ligget på lur og hoppet på binærnivå fra kompilator til kompilator helt fra før «Reflections» ble først presentert.
Det er vel tilfeldig at det skjedde akkurat i året 1984.
«For telling av stemmesedler er det unødvendig å gå så langt som til å bygge to ulike maskiner.»
Jo, det er nødvendig. Demokratiet vårt og tilliten til valgprosessen er langt viktigere enn en rakettoppskytning.
Greit nok, som symbolhandling.
Min kommetar var ment som en datafaglig vurdering. «Faglig sett» har det ingen verdi å bygge to maskiner i et slikt tilfelle.
Så kommer spørsmålet om vi skal «styrke tilliten til demokratiet og valgprosessen» gjennom tiltak som reelt, saklig/faglig sett, ikke har noen som helst verdi.
For meg, som fagmann på det datatekniske, føles dette som en reinspikka bløff. Å kreve to uavhengig utviklede fysiske maskiner for å telle opp stemmer er på nivå med å si at notatene tellerne gjør må gjøres på papir fra ulike papirfabrikker. Hvis vi kan fortelle publikum: Se, SÅ langt går vi for å sikre uavhengighet! og publikum dermed får større tillit til demokratiet, er det likevel en bløff: Ulike papirprodusenter for notatføringen under opptellingen betyr null og niks for demokratiet.
Joda, vi kunne konstruere opp hypotetiske scenarioer der den ene papirprodusenten leverte så urent papir at en «0» senere ble lest som en «8» på grunn av en urenhet i papiret. Alle vet at noe slikt aldri ville skje med noen papirkvalitet brukt de siste femti år.
På samme måte vet alle at ingen datamaskin som får beskjed om å telle opp med 1 den verdien som angir stemmer til X-partiet vil finne på å telle opp med 7 eller 9. Hvis det skjedde, ville hele maskinen være på vei ned for telling med gigantfart – den ville krasje umiddlebart. Ingen maskin som har problemer med å øke en teller vil fungere.
Du kan vise til I/O-utstyr – som jeg allerede har gjort. Der kan det skje feil i lesing av sedlene. Fortsatt oppnår du ganske mye øket sikkerhet ved å velge to ulike alternativer. Du behøver ikke bygge dem!
Joda, feil som bare oppstår en gang i blant, kan virkelig være et mareritt. Er det det, så har man som oftest en svært dårlig teststrategi, eller enda oftere mangel på sådan. Da har man også typisk en forfeilet arkitektur pga mangel på testing. Jeg har noen ganger vært nødt til å løse slike situasjoner ved å skrive om koden for store deler av systemet slik at den blir ordentlig testbar. Ulempen er at en slik omskriving kan ta tid, og bli kostbar der og da. Dette er straffen for ikke å følge anerkjente metoder for utvikling, der automatisk testing inngår. En løsning på problemet innebærer normalt endring av arkitekturen slik at den feilende koden får et veldefinert I/O, og kan behandles som en black box der man står fritt til å påtrykke all input, og avlese all output. Det hyppigst forekommende problemet jeg pleier rette da, er feilaktig å lese maskinens klokke direkte fra koden, i stedet for som korrekt er å la tidspunktet komme inn som del av kodens grensesnitt. I disse spesielle tilfellene der feil forekommer når Mars og Jupiter står på linje, og ulven uler under månen, så kan man etter en slik korrigering simulere enorme mengder kjøretid – kanskje flere år – i virtuell tid, og dermed fange opp disse sjeldne tilfellene i løpet av få minutter. Man kan kjøre simulering mange ganger med forskjellige input, og dermed undersøke et stort antall langvarige scenarier på rekordtid. Da skal det mye til for at man ikke finner årsaken til problemene.
«Det førte til at det ble påbudt å manuelt telle stemmer kort tid før valget.»
… det kan vel ha medført visse kronologisk-praktiske vanseligheter, vil jeg tro 🙂
(Men vi skal kanskje ikke føre den diskusjonen videre: NRKbeta-redaktøren synes å være av den oppfatningen at hvis du bryr deg om bruken av norsk språk er, sitat: «muligens NRKbeta feil sted for deg ;)».
Hei! Er ganske tett i pappen på denne tiden av døgnet. Hva har jeg skrevet feil?
Ikke direkte «feil». Vi snakker bare om dårlige formuleringer som kan leses feil.
«Det førte til at det kort tid før valget ble påbudt å manuelt telle stemmer» er entydig. Slik det står kan det leses som at det ble påbudt å telle stemmene kort tid før valget, hvilket er vanskelig å gjøre.
Dette er bare en «mulig» måte å lese det på. Med rimelig semantisk tolking forstår «alle» at en annen tolking er riktig: At vedtaket ble gjort kort tid før valget. I og med at tellingen nødvendigvis må skje etter valget, er det ikke en logisk forsvarlig tolking at tellingen skal skje før valget, derfor kan det ikke være det som menes.
Så lenge vi kan være garantert at samtlige lesere skjønner at én tolkingen er ulogisk, derfor må en annen være den riktige, da er det «på sett og vis» greit. Helt til du kommer bort i tilfeller som den klassiske «heng ham ikke vent til jeg kommer» – der, i en gitt kontekst, to ulike tolkinger begge kan forsvares.
Yrkesskibenter bør unngå slike fallgruver, selv der de kan forvente at de fleste lesere utelukker den «feilaktige» tolkingen ut fra en semantisk og kontekstuell analyse.
… Lesere med begrep om hva «semantisk og kontekstuell analyse» er, tolker trolig teksten slik den var ment. For de som sier «Hæ???» kan situasjonen være litt annerledes 🙂
Skal se på det i morgen!
Det heter «vanskeligheter», ikke «vanseligheter».
Smilefjes finnes ikke i det norske språk. Ei heller semikolon som øyeblink. Dessuten heter det «… den oppfatning», ikke «oppfatningen», i settingen du har brukt uttrykket.
Siden rusk er så betyelig.
Linken til Nvidia prosjektet er ødelagt og leder bare til «<a href=", med resten av linken strødd litt rundt i elementet