Digipost - del 2

Digipost - del 2

Nylig har digipost annonsert at de skal tilby ende-til-ende-kryptering. I forrige bloggpost analyserte vår konsulent Rolf Rander Næss hva som menes med ende-til-ende og hvorfor det er viktig. Her analyseres hvordan digipost har valgt å løse dette og hva det betyr for brukeren.

Hva er digipost?

Man trenger ikke en veldig grundig analyse for å konkludere med at korrespondanse fra offentlige etater til borgere både kan og bør gjøres digitalt. Politikerne besluttet i 2012 at denne tjenesten skal leveres av private på oppdrag fra difi. Hva denne tjenesten skal være er definert i en kravspesifikasjon.

Hvorfor ikke epost?

Hvis man leser kravene til "sikker digital postkasse" ser man at dette ligner veldig på hva man kjenner som epost: det skal være mulig å sende meldinger til en eller mange mottakere, meldinger skal kunne ha vedlegg, mottaker skal kunne lese, lagre, arkivere, sortere og slette meldinger. Her er det altså mange aktører inne i bildet for å definere og implementere en løsning som er til forveksling lik det mange har brukt i årevis allerede. Hvorfor ikke bruke vanlig epost?

Det er flere krav man ønsker å stille til løsningen som formidler meldinger fra myndigheter til publikum, som vanlig internett-epost (SMTP, IMAP og POP) ikke løser:

  • Konfidensialitet: hvordan hindre at uvedkommende kan lese meldingen? Gitt noen forutsetninger og antagelser er det mulig å sikre konfidensialitet med SMTP, IMAP og POP, men det er valgfritt i disse protokollene, og det er veldig vanskelig å garantere konfidensialitet.
  • Integritet: hvordan kan man være sikker på at meldingen ikke er endret fra avsender til mottaker? Tilsvarende som for konfidensialitet: vi kan få til noe, men ikke alt, og med varierende grad av tillit. Også relevant for integritet og konfidensialitet er følgende to punkter:
       1. Autentisering av avsender: hvordan kan du være helt sikker på at meldingen du har fått som tilsynelatende er fra "skatteetaten", faktisk er fra skatteetaten?
       2. Autentisering av mottaker: hvordan kan skatteetaten være sikker på at de har rett adresse til deg, og at det faktisk er bare du (eller de du bemyndiger) som disponerer denne adressen?
  • Tilgjengelighet: tradisjonell epost er ganske pålitelig i våre dager, men om man ønsker en viss garanti for at meldinger kommer frem er man avhengig av å bruke en sentralisert tjeneste som kan ta ansvar for hele kjeden fra avsender til mottaker.
  • Kvittering på mottak ("rekommandert post"): hvordan kan mottaker vite om du har mottatt og sett meldingen?

Hvordan er sikkerheten ivaretatt?

Digipost inneholder mange sikkerhetsmekanismer, både på teknisk og organisatorisk nivå. Men de viktigste for å oppfylle kravene over er:

  • Konfidensialitet: kryptering av kommunikasjon gjennom https (tls), hindrer at uvedkommende kan avlytte trafikk til og fra digipost.
  • Autentisering av private brukere: førstegangs pålogging må gjøres med BankID/BuyPass, slik at digipost har en sikker autentisering av brukeren med kobling til fødselsnummmer i det brukeren opprettes
  • Autentisering av virksomheter: for at en virksomhet skal kunne sende brev med digipost må den først være registrert og bruke en privat nøkkel for å signere alle tjenestekall. Tilhørende sertifikat må være registrert hos digipost.
  • Kvittering på mottak håndteres ved at meldingen må leses gjennom digipost sitt brukergrensesnitt, og digipost vet dermed når brukeren har lest den.

I tillegg tilbyr digipost at avsender krypterer meldingen med en nøkkel som er unik for mottakeren. Dermen får man ende-til-ende konfidensialitet fra avsender til disk hos digipost. Meldingen blir først dekryptert når mottakeren åpner den.

Hvorfor er ikke dette nok?

Om avsender krypterer med mottakerens offentlige nøkkel er det fortsatt digipost som forvalter den tilhørende private nøkkelen, og en angriper med tilgang til digipost sine systemer vil teoretisk kunne hente ut både privat nøkkel og den krypterte meldingen og så dekryptere selv.

Hva er løsningen?

For en virkelig ende-til-ende-løsning, hvor det er umulig for både noen som angriper digipost, og digipost selv, å få tak i innholdet i meldinger som sendes, må meldingen krypteres med den offentlige delen av et nøkkelpar hvor det er mottaker og kun mottaker som kontrollerer den private nøkkelen.

Hvordan løser digipost dette?

Som nevnt er det flere utfordringer med å implementere ende-til-ende-sikkerhet:

  • Forvaltning av private nøkler
  • Definisjon av "identitet"
  • Kobling av offentlige nøkler til den definerte identiteten

Identitet og offentlige nøkler

Det at digipost allerede har autentisert avsender og mottaker på en sikker måte løser to av problemene vi pekte på i forrige bloggpost, nemlig definisjon av identitet og hvordan vite at den offentlige nøkkelen faktisk tilhører den man tror den tilhører.

Identitet i digipost er knyttet til folkeregisteret: man må ha et fødselsnummer og være identifisert med BankId/BuyPass for å være bruker av digipost, digipost vet dermed hvem du er.

Tilknytning mellom offentlig nøkkel og identitet er håndtert ved at begge deler ligger i digipost sin brukerkatalog, hvis du stoler på digipost betyr det at du også kan stole på at når digipost gir deg "Rolf" sin nøkkel kan du være sikker på at den faktisk tilhører "Rolf", men det er fortsatt forutsatt at du stoler på at ingen har lagt inn feil nøkkel i digipost sin katalog. 

Private nøkler

Til slutt er vi ved den private nøkkelen.

  1. Den må genereres og oppbevares på en måte som hindrer (altså gjør det tilstrekkelig vanskelig for) uvedkommende å få tak i den
  2. Men den må være tilgjengelig for programmet som skal dekryptere meldinger og vise dem til brukeren

Funksjonen knyttet til dekryptering av meldinger er den mest sårbare delen av hele infrastrukturen. Den må være implementert på en slik måte at brukeren ikke er i tvil om hva som skjer, og kvalitetssikret slik at alle parter kan være sikker på at den ikke lekker informasjon.

Digipost sin løsning er en plugin til chrome som håndterer punkt 2. Denne er publisert på github. Pkt 1 må brukeren ta ansvar for selv.

For å implementere selve kryptofunksjonaliteten bruker de Forge fra DigitalBazaar som egentlig er et TLS-bibliotek implementert i javascript. NSM har uttalt at kryptokode bør være FIPS-140-sertifisert. Rapporter om OpenSSL tyder på at FIPS-140 ikke nødvendigvis sier så mye om kodekvalitet, men uavhengig av dette er det flere grunner til å være skeptisk til digipost sin løsning:

  • Det er vanskelig å vite noe som helst om kvaliteten på et tredjeparts javascript-bibliotek for TLS. Å håndtere TLS i javascript er ikke noe veldig mange kan tenkes å ha bruk for, så det er ikke sikkert det er så mange som bruker denne koden.
  • Videre brukes her et veldig lite subsett av denne koden for å implementere noe annet enn TLS, noe den opprinnelig ikke var designet for.
  • Brukeren må kopiere (via utklippstavlen) sin private nøkkel over til chrome, til noe som utgir seg for å være en utvidelse laget av digipost, men i hvilken grad er sluttbruker i stand til å avgjøre hvor utvidelsen kommer fra og om den er sikker?
  • Alle andre programmer som kjører på brukerens maskin vil også ha tilgang til den private nøkkelen fra utklippstavlen.
  • Nøkkelen er lagret i chrome til brukeren selv fjerner den eller til chrome avsluttes. Hvor sikker kan du være på at ikke andre deler av chrome eller andre plugins får tak i den?

Dessuten:

  • Som nevnt over: man må stole på digipost sin katalog. Det betyr at dersom digipost, noen som angriper digipost eller noen som kan påvirke digipost ønsker å lese posten din vil de kunne legge inn en falsk nøkkel i katalogen og bryte ende-til-ende-krypteringen uten at du som sluttbruker har mulighet til å oppdage dette.
  • Digipost kan se hvem du kommuniserer med, når og hvor mye. At kommunikasjonen er konfidensiell (ved hjelp av kryptering) betyr ikke at den er anonym.
  • Hvorfor trenger dette å være en plugin? Kunne ikke javascript-biblioteket som dekrypterer meldinger bli lastet ned i det brukeren logger på?

Hva de kunne ha gjort

Flere har foreslått at digipost kan integreres med gpg/pgp, ved at digipost signerer brukerens gpg-nøkkel eller at digipost videresender meldinger med vanlig epost, kryptert med gpg.

Om digipost signerer brukerens nøkler innebærer det at avsender og mottaker kan verifisere hverandres offentlige nøkler gjennom flere kanaler, som betyr at digipost tilbyr ekstra verifikasjon og sikkerhet utover hva brukeren/nøkkelen har fra før.

Og ved å videresende meldinger som vanlig epost, kryptert med gpg, kan en bruker som allerede har et fungerende oppsett for håndtering av kryptert epost få også meldinger som sendes via digipost inn i sin vanlige postboks. Da hadde også all håndtering av den private nøkkelen skjedd inne i gpg, som er en utbredt, godt testet og velkjent løsning.

Ulempen med disse løsningene, som er grunnen til at digipost sannsynligvis ikke kommer til å tilby dette, er at:

  • Det er ikke mulig å implementere "kvittering på mottak"
  • Brukeren er ikke nødt til å logge på digipost, slik at de mister den direkte kontakten med brukeren
  • Digipost bidrar med ekstra verdi til en ekstern infrastruktur (gpg) i stedet for å få brukeren inn i sin egen infrastruktur, og i ytterste konsekvens vil avanserte brukere bruke digipost kun som ekstra sikkerhet i nøkkelutvekslingen, mens den faktiske utvekslingen av krypterte meldinger skjer over andre kanaler. Dermed er mye av verdien for digipost (kontroll av folks korrespondanse) borte.
  • Gpg krever mye av brukeren og det vil være veldig få brukere som er i stand til å utnytte en slik løsning.

For å finne andre alternativer må vi se grundig på de avveiingene og kompromissene som må gjøres:

  1. For å få tilgjengelighet må tjenesten kunne nås fra nesten hvor som helst, uavhengig av klientens hw eller operativsystem, i praksis betyr dette at den må være tilgjengelig via web. For å gjøre brukerterskelen lav er det en forutsetning at det kun brukes programvare som brukeren allerede kan forventes å ha tilgjengelig (altså en nettleser, ikke noe nedlasting og installasjon av spesialprogramvare)
  2. For sikker håndtering av data etter at de er dekryptert må programvaren som gjør dette være minst mulig, enkel og oversiktlig, og brukes av mange slik at det er stor sannsynlighet for at feil oppdages tidlig.
  3. For å få til sikker håndtering av private nøkler må disse ligge i HW, altså et smartkort eller tilsvarende. Dette gir utfordringer med drivere og kompatibilitet, samt stabilitet og tilgjengelighet. (HW går i stykker, man kan pr definisjon ikke ta backup av en slik nøkkel, hvis smartkortet ligger hjemme får du ikke tilgang til kryptert informasjon)

I avveiingen mellom disse tre har digipost valgt å prioritere pkt 1: tilgjengelighet. Prioritering av pkt 2 kan bety bruk av gpg, mens pkt 3 vil innebære en nasjonal infrastruktur (PKI) for hw-nøkler knyttet opp til identitet. Det er sannsynligvis mulig å få til pkt 3 kombinert med gpg eller andre løsninger i mindre skala, men det vil gå på bekostning av pkt 1.

comments powered by Disqus