eID og brukerautentisering

1. Brukerautentsering i e-forvaltning

Myndigheter i alle land går i økende grad over til e-forvaltning (e-Governance), som betyr online tilgang til offentlige tjenester. God autentisering er viktig når innbyggere må logge seg inn for å få tilgang til offentlige tjenester. En ordning for brukerautentisering i e-forvaltning kalles eID. Det er naturlig at eID-ordninger harmoniseres mellom alle offentlige tjenester, både nasjonalt innen hvert land og regionalt som i EU. Norge og mange andre land har derfor publisert veiledere for autentisering til bruk i offentlig sektor. Veileder for identifikasjon og sporbarhet i elektronisk kommunikasjon med og i offentlig sektor, publisert av DigDir i 2022, følger eIDAS-forordningen fra EU implementert som lov om elektroniske tillitstjenester, som trådte i kraft i 2018, og som ble oppdatert til eIDAS-2 i 2024. Begrepet «tillitstjeneste» er EU-sjargong for PKI-baserte sertifiserings- og autentiseringstjenester. Det europeiske eIDAS definerer tre autentiseringsnivåer (eng. LoA: Levels of Assurance), også kalt sikkerhetsnivåer for autentisering. Den norske veilederen følger eIDAS og definerer autentiseringsnivåene HØYT, BETYDELIG, og LAVT. Et nivå for autentisering skal reflektere grad av visshet om korrekt identitet for en autentisert bruker, der ulike autentiseringsordninger støtter ulike autentiseringsnivåer. Merk at det i Norge noen ganger fremdeles refereres til det gamle norske autentiseringsrammeverket fra 2008 som definerer fire nivåer, der nivå 2, 3, og 4 tilsvarer dagens tre nivåer. Det viste seg at nivå 1, med betydningen «liten eller ingen garanti for korrekt identitet», ikke hadde noen praktisk anvendelse i e-forvaltning. Moderne veiledere og standarder for autentisering definerer derfor bare tre nivåer for brukerautentisering. I 2024 publiserte NIST veilederen SP 800-63-4 Digital Identity Guidelines, som også definerer tre nivåer for autentisering. Tabellen nedenfor viser noen relevante veiledere og standarder for e-autentisering og hvordan de definerer autentiseringsnivåer.

Veiledere og standarder for e-autentisering.

Slike veiledere/standarder definerer kategorier med krav for brukerautentisering. For at en ordning skal oppnå et spesifikt autentisering, må kravene for det nivået i alle kategorier oppfylles. Figuren nedenfor viser tre kategorier av krav til autentisering, med eksempler fra hver kategori. Kjettinglenken viser metaforisk at autentiseringen ikke kan være sterkere enn det svakeste ledd, det vil si at ordningens helhetlige autentiseringsnivå ikke kan være høyere enn det svakeste sett med oppfylte krav i hver kategori. Enkelt forklart betyr det at korrekt autentisering typisk er avhengig av tre komponenter (kategorier) som er:
a) korrekt registrering av brukere samt forsvarlig klargjøring og håndtering av autentikatorene,
b) tilstrekkelig robust autentiseringsmetode,
c) sikkerhet i ID-føderering.

Kategorier av krav til ordninger for eID.

Nedenfor er en forenklet beskrivelse av krav for hvert garantinivå for autentisering i den norske veilederen for identifikasjon og sporbarhet, som tilsvarer den europeiske eIDAS-forordingen, og som er omtrent lik den amerikanske veilederen SP 800-63-3.

• LAVT: 1-faktorautentisering, f.eks. statisk passord mottatt personlig eller via post til brukerens offisielle postadresse.
• BETYDELIG: 2-faktorautentisering (2FA), f.eks. statisk passord og i tillegg engangskoder mottatt via post til brukerens offisielle postadresse, alternativt via SMS (norsk ordning: MinID).
• HØYT: 2-faktorautentisering (2FA), f.eks. statisk passord, og i tillegg fysisk brikke mottatt ved personlig oppmøte, eller autentiserings-app på mobil (norske ordninger: Commfides, Buypass, BankID-brikke, BankID-app).

Det er verdt å nevne at kun det amerikanske SP 800-63-4 beskriver kategori (c) med krav til fødereringssikkerhet. Den norske veilederen inkluderer ikke kategori (c) med fødereringssikkerhet fordi veilederen bygger på eIDAS-forordningen der fødereringssikkerhet ikke nevnes. Imidlertid bør krav til fødereringssikkerhet absolutt inkluderes ettersom ID-føderering brukes i alle moderne eID-ordninger. Forhåpentlig vil krav til ID-føderering tas med i forskrifter relatert til EUs eIDAS forordning.

Tilbydere av offentlige digitale tjenester kan benytte slike standarder og veiledere for autentisering som grunnlag for å velge garantinivå og metoder for autentisering. Når en tjeneste er vurdert til å ha lav, betydelig eller høy sensitivitet, setter veilederne tilsvarende krav til hva som kreves av en passende ordning for brukerautentisering. Tilbydere av offentlige digitale tjenester kan være fristet til å alltid velge en autentiseringsordning med høyeste garantinivå, men de må også huske at høyere garantinivå gir større kompleksitet og kostnader ved utrulling og forvaltning. Derfor er det viktig at autentiseringsnivået er tilpasset sensitivitetsnivået for tjenesten. Vurdering av en tjenestes sensitivitet og valg av passende autentiseringsnivå er en viktig del av risikostyring for tjenesten.

Phishingangrep er en trussel som eksisterende autentiseringsmetoder i liten grad gir beskyttelse mot. Et mellommannsangrep med phishing betyr for eksempel at brukeren blir lurt til å sende autentikatorer til et falskt nettsted, som videresender autentikatorene til den genuine tjenestetilbyderen/autentiseringstjeneren for å spoofe brukeren. For å stoppe slike angrep forskes det på å utvikle phishingresistent autentisering. Det kan for eksempel gjøres ved at autentikatorer blir en dynamisk funksjon av identiteten og/eller IP-adressen til tjenestetilbyder / autentiseringstjener, slik at autentikatorer ikke kan videresendes fra det falske nettstedet til den ekte tjenestetilbyderen / autentiseringstjeneren. I den amerikanske NIST SP 800-63-4 Digital Identity Guidelines nevnes det at phishingresistente autentiseringsmetoder er et krav for det høyeste autentiseringsnivået (nivå 3). Phishingresistente ordninger er typisk implementert med passnøkler. Samtidig er det et krav for det høyeste autentiseringsnivået at en passnøkkel ikke skal synkroniseres mellom ulike enheter eller til lagring i skyen, dvs. at en passnøkkel kun skal lagres lokalt i en autentiseringsbrikke.

2. Passordløs phishingresistent brukerautentisering

Brukerautentisering med passnøkler betyr at hver passnøkkel som er lagret på en klientplattform – eller på en enhet koblet til klienten – har et attributt som entydig knytter nøkkelen til domenenavnet til en bestemt tjenesteleverandør («relying party»). Under autentiseringen verifiserer klienten at domenenavnet til tjenesteleverandøren stemmer overens med domenenavnet som er knyttet til passnøkkelen. Selve passnøkkelen er en lang kryptografisk nøkkel som brukeren verken kan huske eller taste inn; det er derfor klientplattformen som utfører autentiseringen overfor tjenesteleverandøren på brukerens vegne. Autentiseringsmetoden med passnøkler bygger på en «utfordring-respons»-protokoll (challenge-response) som benytter offentlige og private nøkler – et konsept som først ble foreslått i den banebrytende artikkelen New Directions in Cryptography av Whitfield Diffie og Martin Hellman i 1976. Merk at challenge-response i seg selv ikke skaper ikke phishingresistens. Man oppnår kun phishingresistens når klienten verifiserer at tjenerens domenenavn stemmer overens med passnøkkelens domeneattributt. På samme måte kunne man oppnå phishingresistens med vanlige passord ved at passordbanken lagrer et domeneattributt sammen med hvert passord, og sjekker tjenerens domenenavn ved hver autentisering. Begrepene FIDO og WebAuthn er andre navn for den samme typen autentisering med passnøkler.

2.1. Brukerautentisering med passnøkler

Figuren nedenfor illustrerer prinsippet for autentisering med passnøkler.

Brukerautentisering med passnøkler.

Trinnene i figuren er forklart nedenfor:

1. Under innlogging sender tjeneren en utfordring i form av et tilfeldig tall til klienten. For at brukeren skal bli autentisert og logget inn, forventer tjeneren en respons i form av en korrekt digital signatur på denne utfordringen.
2. Klienten slår opp den lagrede passnøkkelen som samsvarer med domenenavnet til tjeneren. Hvis ingen tilhørende passnøkkel finnes, avbrytes autentiseringen. Hvis en tilhørende passnøkkel finnes, blir brukeren bedt om å autentisere seg lokalt.
3. Brukeren autentiserer seg lokalt overfor klienten. Avhengig av kravene til autentiseringsnivå, kan ulike former for lokal brukerautentisering benyttes.
4. Etter at klienten har autentisert brukeren lokalt, genereres en digital signatur som sendes som respons tilbake til tjeneren.
5. Brukeren blir autentisert når den digitale signaturen i responsen er korrekt verifisert av tjeneren.

• I ordninger med passnøkler er det altså brukerens klientplattform som autentiserer seg på brukerens vegne til autentiseringstjeneren.
• På klienten kan funksjonen for autentisering med passnøkler være implementert i:
  • en brikke (USB-brikke eller smartkort) som er koblet til klientplattformen eller som kommuniserer med klienten via NFC eller blåtann,
  • en app innebygd i en klientplattformen som f.eks. i en smarttelefon eller en laptop-computer, støttet av tiltrodd maskinvare som f.eks. TPM (Trusted Platform Module),
  • operativsystemet på en klientplattform (f.eks. en mobiltelefon/laptopp) eller en nettleser på slike plattformer, støttet av tiltrodd maskinvare som f.eks. TPM (Trusted Platform Module).
• Brukerens klientplattform/app/brikke krever å autentisere brukeren lokalt med biometri eller PIN før den i sin tur foretar online-autentisering mot autentiseringstjeneren, slik at autentiseringen foregår i to etapper.
• Når biometri inngår i lokal autentisering på klienten kalles slike ordninger for autentisering med biometri, som kan være misvisende fordi det feilaktig gir inntrykk av at biometriske prøver sendes online til autentiseringstjeneren.
• Hver private nøkkel er en «passkey», derav navnet «Passkeys».
• En passnøkkel (passkey) er på mange måter som et passord.
• Brukerplattform/nettleser lagrer separate passnøkler for ulike autentiseringstjenere.
• En mobiltelefon som støtter passnøkler kan støtte brukerautentisering via en vilkårlig terminal/nettleser ved at mobiltelefonen og terminalen kommuniserer med blåtann-tilkobling.

2.2. Fordeler og ulemper med passnøkler

• Fordeler:
  • Private nøkler lagret i plattform/enhet er spesifikke for autentiseringstjenerens URL, som betyr at plattformen/enheten ikke vil signere en utfordring fra en falsk nettside pga. feil URL. Det betyr at Passnøkler/FIDO/WebAuthn gir phishingresistent autentisering.
  • Brukeren slipper å håndtere passord.
• Utfordringer:
  • Det fins ingen god løsning for migrering av passnøkler (private nøkler) til ny plattform/enhet ved utskifting eller tap av plattform/enhet.
  • Foreløpige migreringsløsninger for passnøkler er basert på lagring av iskyen, f.eks:
    • egen passordbank
    • passnøkkelbank kontrollert av produsenten for platform/enhet
  • Tilgang til passnøkler i skyen krever til syvende og sist tradisjonell autentisering med passord eller andre autentikatorer.
  • Brukere er skeptiske, fordi passnøkler kan være vanskelig å forstå, og fordi mange brukere feiaktig tror at biometriske prøver blir sendt online til autentiseringstjeneren.
  • Biometri kan forfalskes eller tvinges, noe som kan utsette brukere for fysisk fare. Trusselaktører kan stjele brukerenheter og autentisere med forfalsket biometri, eller kan tvinge biometriske prøver fra brukere f.eks. ved å dope dem ned. For å ivareta brukernes trygghet bør lokal brukerautentisering på klienten ikke baseres på biometri alene, men bør inkludere en memorert PIN eller mønsterkode fordi det er vanskeligere å stjele eller tvinge.