Første del av sikkerhetsmekanismen publisert
Av Christian Bull, Publisert tirsdag 20. april 2010I løsningen for elektronisk stemmegivning skal du som velger kunne kontrollere at stemmen din har kommet frem uendret. Dette er viktig fordi din hjemmedatamaskin i teorien kan være infisert med programvare som endrer stemmen uten at du kan oppdage det.
Om du ikke kunne kontrollere at stemmen kom frem riktig, ville dette kunne åpne for systematisk manipulasjon av store mengder stemmer uten det kan oppdages. Det er helt uakseptabelt.
Samtidig som vi altså ønsker å kunne fortelle deg at vi har mottatt riktig stemme, så må vi sikre at myndighetene ikke på noe som helst tidspunkt får vite hva du har stemt. Det skal heller ikke være mulig for valgmedarbeidere eller andre som jobber med e-valgsystemet å manipulere eller å se stemmer.
Kort oppsummert – vi ønsker å bevise for deg som velger at vi har mottatt stemmen din, men uten at vi blir kjent med innholdet.
Førsteamanuensis ved NTNU Kristian Gjøsteen (http://www.math.ntnu.no/~kristiag/ ) har derfor i samarbeid med e-valg 2011-prosjektet og ErgoGroups underleverandør, Scytl Secure Electronic Voting, utarbeidet en kryptografisk protokoll som gjør dette mulig. Et dokument som beskriver deler av protokollen er nå publisert på vår hjemmeside, se http://bit.ly/acsDGx. Riktignok er ikke denne informasjonen enkel å forstå, men vi jobber med en enklere fremstilling.
Rent praktisk er dette løst ved at vi før valget sender ut et kodekort til velgerne – på samme måte som man i dag får et valgkort. På dette kortet står det hvilke koder vi kommer til å sende tilbake til deg avhengig av hva du har stemt. Deretter ødelegger vi denne informasjonen, slik at bare du som velger vet hva kodene betyr.
Når du da sender inn din krypterte stemme over Internett, så sørger denne protokollen for at vi kan regne oss frem til kodene på kodekortet, men ikke hva kodene betyr.
Kodene vi regner oss frem til avslører altså ingenting om hvem du har stemt på.
Koden kan vi så sende tilbake til deg på SMS, slik at du som velger kan kontrollere at stemmen kom frem riktig. Du kan stemme på nytt igjen så mange ganger du vil, og du kan avgi stemme i valglokalet som vil kansellere alle Internett-stemmer. Derfor vil ikke denne koden fungere som noen kvittering til en som vil kjøpe stemmer, eller som noe bevis overfor en som prøver å tvinge deg til å stemme noe du ikke vil.
Noen vil sikkert stille spørsmål om hvordan de kan vite at vi ikke tar vare på kodeinformasjonen på valgkortet som gjør at vi kan finne ut av hva du har stemt. Svaret på det er at vi vil etablere betryggende rutiner på dette området, som på øvrige områder i valggjennomføringen. Rutinene skal sikre kontroll med at opplysninger ikke kommer på avveie på noe stadium i prosessen, og at denne kontrollen foretas av flere personer samtidig. De som kontrollerer skal se at systemet er transparent og at det er sikkert.
Slik jeg har forstått dette leveres det en kvitteringskode som viser hvilket parti du har stemt. Om hackeren ikke endrer partiet, men i stedet legger til slengere fra andre partier vil ikke dette oppdages. I et kommunestyre med 25 representanter vil 12 slengere til et annet parti gi 13/25 av stemmen til partiet man stemte på og 12/25 av stemmen til det partiet hackeren har bestemt. Man vet ikke om det store antallet hackede maskiner er organisert eller ikke, men om det er organisert og det mulig å “kjøpe tilgang” til 5% av norges privat-PCer vil dette være en mulig måte å påvirke valget uten at det blir oppdaget.
Otto,
For enkelhets skyld pleier vi bare å snakke om parti, men det kan også gis kvitteringskode på de endringene velgeren gjør på stemmeseddelen.
For øvrig tillater bare valgloven at man har med 1/4 av kommunestyrets representanter som slengere (§7-2 (3)). I ditt eksempel med 25 representanter er det mao. ikke lov med flere enn 6 slengere.
E-valg 2011-prosjektet har lagt stor vekt på at kontrollkoder sikrer at stemmer ikke kan endres uten at dette oppdages. Selv om bare 1/4 av representantene kan være slengere er min påstand fortsatt at infiserte/kontrollerte maskiner kan påvirke valgresultatet uten at kontrollkodene bidrar til at dette oppdages.
I et kommunestyre med 25 representanter og med 10 valglister er antall mulige valglister ekstremt høyt (langt over en billiard muligheter). Det er selvfølgelig umulig å lage kvitteringskoder for alle muligheter. Hva skal da kvitteringskoden fortelle? I Oslo var det 19 lister i valget i 2007, og den åpenbare løsningen er da at kvitteringskoden kontrolleres mot en tabell med 19 par av partinavn og kontrollkoder (hva ellers). Skal man ha tilleggskoder som sier noe om slengere eller antall endringer på valglisten, og hvor komplisert blir dette? Hva da med kumuleringer? Man kan også tenke seg et organisert angrep for å kumulere inn enkeltpersoner. Her trengs bare et lavt antall infiserte maskiner for å oppnå ønsket effekt. Konklusjonen er at kontrollkoder er en for svak mekanisme og bare i moderat grad sikrer at et organisert hackerangrep vil oppdages.
Otto, det vil bli produsert kvitteringskoder for alle endringer som blir gjort på en stemmeseddel. Koden du mottar på sms kan du sammenligne med kode på valgkortet, og du har svaret på hvilken stemme som er registrert. Dette er en frivillig kontroll og det er tilstekkelig at kun en liten prosentandel av velgerne gjør dette. Vi mener at mekanismen med returkode i tilstrekkelig grad sikrer for at organisert hackerangrep vil bli oppdaget. Velgerne vil bli bedt om å varsle valgmyndighetene dersom de mottar feil returkode, og det vil bli satt i gang tiltak for å finne ut av hva som kan være årsaken til feil returkode.
Valg i ukontrollerte omgivelser er én av flere ting som taler imot internettvalg. Andre ting er etterprøving, dvs ny opptelling om noe skulle gå galt (valgfusk osv) og det faktum at dataene blir liggende i en database og kan potensielt endres av kvalifisert IT-personell.
PS: Lenka til protokollbeskrivelsen er knekt, så det er vanskelig å finne noe der. Det hadde også vært en fordel om _hele_ protokollen, ikke bare deler av den.
Sånn på tampen, http://karlsbakk.net/fun/USA/voting_machine.wmv
roy
Er det slik at kvitteringskoden kun sendes på SMS? Hvor hentes mobilnummeret fra? Er det et krav at man må ha et registrert mobilnummer på e-valg tjenesten for å kunne utføre et sikkert valg digitalt?
Hvordan er det med pålogging på e-valg, hverken “MinID” eller “eID” er nevnt på bloggen.
Linken ovenfor fungerer ikke: http://www.regjeringen.no/nb/dep/krd/kampanjer/valg/elektroniskstemmegivning/nytt-evalg/nytt-om-e-valg/2010/Analyse-av-en-protokoll-for-internettstemmegivning.html?id=594906. Kan dere oppdatere med en lenke som fungerer?
Lenken (i artikkelen) er nå fikset. En mer komplett beskrivelse kommer om kort tid.
Vi er altså opptatt av å få ut informasjon så fort som mulig, og derfor valgte vi å publisere den delen som var klar.
@Roy Sigurd Karlsbakk: Det er veldig enkelt å si “kan potensielt endres”. Det er jo ikke slik at en tilfeldig systemadministrator kan herje med stemmene som han vil bare fordi de ligger i en database. Det er langt fra trivielt å manipulere krypterte og signerte data.
Ta for eksempel en titt på denne kronikken, skrevet av uavhengige forskere ved Universitetet i Bergen: http://www.aftenposten.no/meninger/kronikker/article3482068.ece
Jeg pleier forøvrig å bruke denne i mine presentasjoner: http://www.youtube.com/watch?v=1aBaX9GPSaQ
@SondreB: Påloggingen er ikke 100% avklart, men det meste peker mot MinID. Det vil da være et krav at du har registrert mobiltelefonnummeret ditt hos MinID, og så henter vi mobiltelefonnummeret derfra. Returkoder sendes kun på SMS. Med tiden blir nok det et tema for en egen bloggpost, for det fortjener litt utdypning.
Sammen med protokollen, har dere en trusselanalyse som tar for seg hvilke trusler dere ser for dere, og hvordan dere har adressert disse? Uten at dette legges ut og er åpent, er det vanskelig å ta stilling til om løsningen er troverdig eller ikke.
Om da hackere får kjennskap til hele protokollen og de tiltakene dere har fattet, anser jeg som et av de minste sikkerhetsproblemene her – hele løsningen må tåle dagens lys for å være troverdig.
@Frode: Noe av det første vi gjorde i prosjektet var å gjennomføre en trusselanalyse, og basert på denne analysen trakk vi opp 14 sikkerhetsmål systemet må tilfredsstille. Selve analysen har vi forsåvidt aldri publisert, uten at det er noen annen grunn til det enn at den ble gjennomført lenge før vi fikk opp nettsidene våre. Nettredaktøren vår har fri i dag, men vi kan jo legge den ut rett over pinse, sammen med den fyldigere protokollbeskrivelsen.
Sikkerhetsmålene som analysen munnet ut i finner du uansett allerede nå i dokumentet “System Requirements Specification” her: http://turl.no/9ne (side 31 og utover)
Sikkerhetsmålene resulterer i sikkerhetskrav, som du finner i “SSA-U Appendix 2B Requirements Table” på samme URL.
Ergos tilbud lenger ned på samme side beskriver hvordan de foreslo å løse kravene. Det er kontraktsgrunnlaget, men det er selvsagt ikke dermed sagt at det er nøyaktig det som blir levert til akseptansetest rundt årsskiftet. Derfor har leverandøren forpliktet seg til å gjennomføre kontinuerlig trusselmodellering i systemutviklingsløpet, og dokumentere alle tiltak de gjør for å avhjelpe eventuelle identifiserte sårbarheter. Dette skal selvsagt publiseres. Det samme gjelder selvsagt tiltakene rundt driftsmiljøet, og testrapporter.
Vi tror veldig sterkt på at hele systemet, også sikkerhetstiltakene, må tåle dagens lys. Det er rett og slett en selvfølge når det kommer til valg – også e-valg.