Dagens tekst er hentet fra kapittel 15 i Cryptography and Network Security, og handler om autentisering av brukere som ikke nødvendigvis befinner seg på samme sted som systemet de ønsker å bruke.

Autentisering er prosessen som består i å verifisere en identitet som en aktør i et system påstår å ha. Autentiseringsprosessen består av to steg: Identifiseringssteget, å presentere en identifikator til sikkerhetssystemet; og verifikasjonssteget, å presentere eller generere autentiseringsinformasjon som underbygger bindingen mellom aktøren og identifikatoren.

Autentiseringsmåter

Det finnes fire generelle måter å autentisere en brukers identitet; disse kan brukes enten alene eller i kombinasjon:

• Noe du vet: Eksempler omfatter et passord, en kode (PIN), eller svar til et sett av forhåndsavtalte spørsmål
• Noe du har: Eksempler omfatter elektroniske nøkkelkort, smartkort og fysiske nøkler; dette kalles ofte et “token”.
• Noe du er (statisk biometri): Eksempler omfatter fingeravtrykk, netthinnemønster, og ansiktsform.
• Noe du gjør (dynamisk biometri): Eksempler omfatter stemmemønster, håndskriftkarakteristikk, tastatur-rytme og ganglag.

For nettverksbasert brukerautentisering involverer de viktigste metodene kryptografiske nøkler og noe brukeren vet, slik som et passord.

Gjensidig autentisering

Protokoller som gjør kommuniserende parter i stand til å gjensidig versifisere hverandres identitet (og ofte utveksle sesjonsnøkler) kalles gjensidig autentisering. Det er to ting som er sentrale ved problemet autentisert nøkkelutveksling:

• Konfidensialitet: Essensiell identifikasjons- og sesjonsnøkkel-informasjon må kommuniseres i kryptert form. Dette forutsetter at det allerede finnes hemmelige eller offentlige nøkler som kan brukes til dette formålet.
• Tidsriktighet: Viktig pga. faren for meldingsavspilling (replay). En slik avspilling kan gjøre det mulig for en angriper å kompromittere en sesjonsnøkkel, gi seg ut fra å være noen andre, forkludre operasjoner ved å presentere meldinger som framstår som ekte, men som ikke er det.

Avspillingsangrep

Det enkleste avspillingsangrepet er at en angriper helt enkelt avlytter og kopierer en melding fra nettverket, og deretter spiller den tilbake senere. Dersom meldingen har et tidsstempel, kan angriperen fortsatt spille den av innenfor det gitte gyldige tidsvinduet. Hvis motstanderen samtidig som hun avlytter den gyldige meldingen forhindrer den fra å nå mottakeren, kan hun avspille den senere innenfor det gyldige tidsvinduet, og det vil ikke være mulig å detektere at avspillingen som det. Et siste angrep involverer en speiling av en melding uten modifisering, noe som er mulig hvis symmetrisk kryptering er brukt, og det ikke er enkelt for senderen å se forskjellen på meldinger sendt og meldinger mottatt basert på innhold.

Tilnærminger til håndtering av avspilling

Der er flere ting man kan gjøre for å motvirke avspilling. Man kan legge til et sekvensnummer til hver melding som brukes i en autentiseringsutveksling; en ny melding aksepteres bare dersom sekvensnummeret er i rett rekkefølge. Et problem med denne metoden er at det krever at hver part holder rede på siste sekvensnummeret for hver aktør den har vært i kontakt med, og den brukes generelt sett ikke for autentisering og nøkkelutveksling pga. overhead. Man kan legge til et tidsstempel i hver melding, men det krever at aktørene har synkronisert klokker. Alice vil kun akseptere en melding fra Bob dersom meldingen har et tidsstempel som Alice vurderer til å være nært nok Alices opplevelse av gjeldende tid. Man kan også bruke såkalt utfordring/svar, hvor Alice først sender et tilfeldig tall, eller en nonce (utfordringen) til Bob, og forventer at svaret fra Bob inneholder samme nonce på en eller annen måte (vanligvis vil svaret også involvere prosessering av nonce på noe vis).

Enveisautentisering

Det blir stadig mer populært å sende kryptert epost. Hodet til eposten (header) må være i klartekst, slik at meldingen kan håndteres av den aktuelle lagre-og-videresend epostprotokollen (SMTP eller X.400). Epostmeldingen bør krypteres slik at epos-systemet ikke har tilgang på dekrypteringsnøkkelen. Et annet krav er autentisering; mottakeren ønsker en form for bekreftelse på at meldingen er fra den påståtte avsenderen.

Autentisering av fjerne brukere ved symmetrisk kryptering

Et tonivå hierarki av symmetrisk nøkler kan brukes for å oppnå konfidensialitet for kommunikasjon i et distribuert miljø. Denne strategien involvere bruk av et tiltrodd nøkkeldistribusjonssenter (KDC). Hver aktør deler en hemmelig master-nøkkel med KDC, som på sin side er ansvarlig for å generere sesjonsnøkler som skal brukes for kortere tidsrom mellom to parter, og bruker master-nøklene til å beskytte distribusjonen av sesjonsnøklene.

Needham-Schroeder-protokollen

Dette er den opprinnelige protokollen for distribusjon av nøkler via en tredjepart. Alice og Bob ønsker å kommunisere sikkert ved hjelp av KDC:

1. A->KDC: ID_A || ID_B || N₁
2. 2. KDC -> A: E(K_a, [K_s||ID_B||N₁ || E(K_b,[K_s||ID_A])] )
3. A -> B: E(K_b, [K_s||ID_A])
4. B -> A: E(K_s, [N₂])
5. A -> B: E(K_s, [f(N₂)])

Denne protokollen kan brukes til å distribuere en ny sesjonsnøkkel som Alice og Bob kan bruke til å kommunisere sikkert, men den er sårbar for et avspillingsangrep dersom Charlie er i stand til å knekke en gammel sesjonsnøkkel, og sender den korresponderende melding 3 (som Charlie har spart på i lang tid). Bob vil være overbevist om at han kommuniserer med Alice, mens det i virkeligheten er Charlie. Modifikasjoner for å adressere dette krever enten tidsstempler i steg 2 & 3 (Denning,81) eller å bruke en ekstra nonce (Neuman,93).

Denning-protokollen

I 1981 modifiserte Denning Needham-Schroeder-protokollen ved å legge inn et tidsstempel i steg 2 & 3:

1. A→KDC: ID_A || ID_B
2. 2. KDC→A: E_Ka[Ks || ID_B || T || E_Kb[Ks||ID_A ||T ] ]
3. A→B: E_Kb[Ks||ID_A ||T]
4. B→A: E_Ks[N₁]
5. A→B: E_Ks[f(N₁)]

Alice og Bob verifiserer tidsriktighet ved å sjekke at forskjellen mellom tidsstempelet T og deres klokke er mindre enn forventet avvik til KDC klokke pluss forventet nettverksforsinkelse. Problemet er at denne protokollen er avhengig av synkroniserte klokker, og er sårbar for angrep som holder tilbake meldinger og senere spiller dem av (suppress-replay).

Suppress-Replay angrep

De distribuerte klokkene kan bli usynkroniserte, enten som følge av sabotasje eller pga. en feil i synkroniseringsmekanismen. Problemet oppstår når en avsenders klokke ligger foran den tiltenkte mottakeren. Angriperen kan snappe opp meldingen fra avsenderen, og spille den av senere når tidsstempelet i meldingen stemmer med klokken til mottakeren.

Neuman-protokollen

I 1993 foreslo Neuman følgende forbedring av Needham/Schroeder-protokollen som beskytter mot suppress-replay angrep:

1. A→B: ID_A || N_a
2. B→KDC: ID_B || N_b || E_Kb[ ID_A || N_a ||T_b ]
3. KDC→A:
   E_Ka[ID_B|| N_a|| Ks|| T_b] || E_Kb[ID_A|| Ks|| T_b] || N_b
4. A→B: E_Kb[ID_A|| Ks|| T_b] || E_Ks[N_b]

Så lenge man er innenfor tidsbegrensningene, kan Alice kontakte Bob som:

1. A→B: E_Kb[ID_A|| Ks|| T_b], N’_a
2. B→A: N’_b, E_Ks[N’_a]
3. A→B: E_Ks[N’_b]

Tidsstempelet T_b er relativt til Bobs klokke, så det er ikke behov for synkroniserte klokker.

One-Way Authentication

Vi kan bruke en variant av KDC for å sikre epost – ettersom Bob ikke er online dropper vi stegene 4 & 5:

1. A->KDC: ID_A || ID_B || N₁
2. 2. KDC -> A: E(K_a, [K_s||ID_B||N₁ || E(K_b,[K_s||ID_A])])
3. A -> B: E(K_b, [K_s||ID_A]) || E(K_s, M)

Dette sørger for kryptering og noe autentisering, men de beskytter ikke mot avspillingsangrep.

Kerberos

Hva er en billett?

En vanlig billett er et bevis for noe – f.eks. at du har betalt for å få lov til å reise en tur med bussen. En vanlig billett blir samlet inn/stemplet/ ødelagt slik at den ikke kan brukes flere ganger, og en vanlig billett er vanskelig å kopiere.

Leidebrev

Et leidebrev var i en konvolutt lukket med kongens segl, og brevet kan ikke åpnes uten å ødelegge seglet. Hvis brevet inneholder kontroll-informasjon, kan mottaker verifisere at bæreren ikke har stjålet brevet.

En ticket er en slags elektronisk billett, men elektroniske data er lette å kopiere – også for ”observatører”. En Kerberos ticket baserer seg derfor mer på ”leidebrevprinsippet”. I stedet for et segl, ”låses” innholdet inn  med kryptering, og ”kontrollspørsmålet” er en sesjons-nøkkel som ligger lagret inne i ticket’en.

Bakgrunn

Kerberos er en autentiseringstjeneste utviklet av Project Athena ved MIT. En arbeidsstasjon kan ikke stoles på for å identifisere dens brukere på en korrekt måte ovenfor nettverkstjenester; en bruker kan få urettmessig tilgang til en arbeidsstasjon og lates som om hun er en annen bruker som opererer fra den arbeidsstasjonen. Alternativt kan en bruker endre nettverksadressen til en arbeidsstasjon slik at anmodninger fra den endrede arbeidsstasjonen fremstår som om de kommer fra den påståtte arbeidsstasjonen. En bruker kan avlytte utvekslinger og bruke avspillingsangrep for å få tilgang til en tjener eller forstyrre operasjoner.

Kerberos har en sentralisert autentiseringstjener hvis rolle er å autentisere brukere til tjenere og tjener til brukere. Kerberos er basert på symmetrisk kryptering, med ingen bruk av offentlig-nøkkel-kryptering. Den opprinnelige Kerberosrapporten anga følgende krav:

• Sikker: En avlytter på nettverket skal ikke være i stand til å få tak i informasjonen som er nødvendig for å si seg ut for en annen bruker
• Pålitelig: Skal bruke en distribuert tjenerarkitektur hvor et system skal være i stand til å steppe inn for et annet
• Transparent: Brukeren skal ideelt sett ikke være klar over at autentisering finner sted, utover kravet å taste inn et passord.
• Skalerbart: Systemet skal være i stand til å håndtere et stort antall klienter og tjenere.

Kerberos v4

Kerberos versjon 4 bruker DES for å tilby autentiseringstjenesten.

Aktører i Kerberos-protokollen

Authentication server (AS) har tilgang på alle passord, og deler en unik nøkkel med alle TGS. Ticket-granting server (TGS) utsteder tickets til autentiserte brukere; AS og TGS kalles KDC som en fellesbetegnelse. Klienten refereres til som C, mens tjenerenen kalles V (serVer).

En spesiell ticket kalt TicketGrantingTicket (TGT) opprettes når AS aksepterer brukeren som autentisk; den inneholder brukerens ID og nettverksadresse, og tjenerens ID (dvs. TGS). Ticketen er kryptert med den hemmelige nøkkelen delt mellom AS og tjeneren. Hver gang brukeren ber om tilgang til en ny tjeneste vil klienten henvende seg til TGS med TGT som autentisering. TGS vil så utstede en ticket for den aktuelle tjenesten. Klienten vil spare på hver tjeneste-ticket (så lenge den er gyldig) og bruke den for å autentisere seg hver gang den aktuelle tjenesten skal brukes.

Levetiden på TGT kan være et problem: Hvis levetiden er veldig kort (f.eks. minutter), vil brukeren stadig vekk bli bedt om å taste inn passordete. Hvis levetiden er veldig lang (timer) vil en angriper ha større muligheter for avspilling.

En nettverkstjeneste (TGS eller en applikasjonstjeneste) må være i stand til å bevise at personen som bruker en ticket er samme person som ticketen opprinnelig var utstedt til, og tjenere må kunne autentisere seg ovenfor brukere.

Nøkler i Kerberos

Langtidsnøkkel (Long-term key), basert på hash av brukerens passord (brukes bare ved pålogging). Sesjonsnøkkel (Session key), utstedes av KDC, hver ticket inneholder en (unik) sesjonsnøkkel som serveren bruker til å dekryptere informasjon fra klienter med. Det vil totalt mange forskjellige sesjonsnøkler!

Kerberos steg for steg

I det følgende beskriver vi hvordan gangen i en Kerberos versjon 5 er.

• Klient C kontakter først autentiserings-server AS for å få TGT
• Kontakter deretter TGS for å få ticket for gitt tjeneste (eller server, V)
• Kontakter til slutt V for å få tjenestesesjon

Hver gang bruker logger på

(1) Fra C til AS:
PA || Options || ID_C || Realm_C || ID_TGS || Times || Nonce₁

(2) Fra AS til C:
Realm_C || ID_C || Ticket_TGS|| E_Kc[K_C,TGS || Times || Nonce₁ || Realm_TGS || ID_TGS]

Ticket_TGS= E_KTGS[Flags || K_C,TGS || Realm_C || ID_C || AD_C || Times]

Feltet “Times” består av:

• from : ønsket start-tid
• till : ønsket utløpstid
• rtime : ønsket tidsfrist for fornyelse

PA: Pre-Authentication data (optional)

Bruker aksesserer ny tjeneste

(3) Fra C til TGS:
Options || ID_C || Times || Nonce₂ || Ticket_TGS || Authenticator1_C

(4) Fra TGS til C:
Realm_C || ID_C || Ticket_V ||
E_KC,TGS[K_C,V || Times || Nonce₂ || Realm_V || ID_V]

Ticket_V = E_KV[ Flags || K_C,V || Realm_C || ID_C || AD_C || Times ]

Authenticator1_C = E_KC,TGS[ID_C || Realm_C || TS₁]

For hver ny tjenestesesjon

(5) Fra C til V:
Options || Ticket_V || Authenticator2_C

(6) Fra V til C:
 E_KC,V[TS₂ || Subkey_V || Seq#]

(for gjensidig autentisering)

Authenticator2_C = E_KC,V[ID_C || Realm_C || TS₂ || Subkey_C || Seq#]

Subkey_V kan utelates, men hvis den finnes, tar den presedens over Subkey_C

Kerberos Realms og flere Kerberi

Et komplett Kerberos-miljø som består av en Kerberos server, et antall klienter, og et antall applikasjonstjenere krever at Kerberos serveren må ha bruker ID og hashede passord til alle de medvirkende brukerne i sin database; alle brukere må være registrert hos Kerberos serveren. Kerberos serveren må dele en hemmelig nøkkel med hver tjener; alle tjenere må være registrert hos Kerberos serveren. Kerberos serveren i hvert interoperable realm deler en hemmelig nøkkel med serveren i det andre realmet; de to Kerberos serverne må være registrert hos hverandre.

Kerberos Realm

Et Kerberos realm et en samling administrerte noder som deler samme Kerberos database. Databasen befinner seg på Kerberos master datamaskinsystemet, som skal befinnes seg på et fysisk sikret rom. Det kan også finnes kopier med kun lesetilgang på andre Kerberos systemer, men alle endringene i databasen må skje på master-systemet. Endring av eller tilgang til innholdet i en  Kerberos database krever Kerberos master-passordet.

Kerberos principal

En Kerberos principal er en tjeneste eller bruker som er kjent for Kerberos systemet. Den er idfentifisert ved sitt principal navn, som består av et tjeneste- eller brukernavn, et instansnavn, og et realm navn.

Version 5

Kerberos versjon 5 ble introdusert for å adressere begrensninger i versjon 4 på to områder:

• Miljømessige begrensninger
  • Avhengighet av krypteringssystem
  • Avhengighet av Internettprotokoll
  • Rekekfølge på meldingsbyter
  • Ticket levetid
  • Videresending av autentisering
  • Interrealm autentisering
• Tekniske svakheter
  • Doblel kryptering
  • PCBC kryptering -> standard CBC
  • Sessionsnøkler
  • Passordangrep

Fjernautentisering med offentlige nøkler

Gjensidig autentisering

Hvis vi skal bruke offentlig-nøkkel- kryptering for å distribuere sesjonsnøkler, må vi gå ut fra at begge partene har den oppdaterte offentlige nøkkelen til den andre parten i sin besittelse, men det er ikke alltid praktisk å kreve denne antagelsen.

Denning lanserte en protokol med tidsstempling som bruker en autentisering server (AS) for å tilby offentli-nøkkel-sertifikater; denne forutsetter synkroniserte klokker. Woo og Lam lanseerte et alternativ med bruk av noncer, her må man trå varsomt for å forsikre seg om at protokollen ikke inneholder feil.

Denning AS Protocol

• Denning (1981) presenterte følgende:

1. A -> AS: ID_A || ID_B
2. AS -> A: E_PRas[ID_A||PU_a||T] || E_PRas[ID_B||PU_b||T]
3. A -> B: E_PRas[ID_A||PU_a||T] || E_PRas[ID_B||PU_b||T] || E_PUb[E_PRa[K_s||T]]

Bemerk at sesjonsnøkkelen er valgt av A, så AS trenger ikke være tiltrodd til å beskytte den. Tidsstempler forhindrer avspilling, men forutsetter synkroniserte klokker.

Woo & Lam KDC Protocol

Woo & Lam presenterte følgende:

1. A→KDC: ID_A || ID_B
2. KDC→A: E_KRauth[ID_B || KU_b]
3. A→B: E_KUb[N_a || ID_A]
4. B→KDC: ID_B || ID_A || E_KUauth [N_a]
5. KDC→B: E_KRauth[ID_A ||KU_a] || E_KUb[E_KRauth [N_a ||K_s ||ID_B]]
6. B→A: E_KUa[E_KRauth [N_a || K_s || ID_B] ||N_b]
7. A→B: E_Ks[N_b]

Denne later til å motvirke forskjellige angrep, men det er fortsatt en svakhet her.

Woo & Lam lanserte så følgende forbedrede versjon:

1. A→KDC: ID_A || ID_B
2. KDC→A: E_KRauth[ID_B || KU_b]
3. A→B: E_KUb[N_a || ID_A]
4. B→KDC: ID_B || ID_A || E_KUauth [N_a]
5. KDC→B:
   E_KRauth[ID_A || KU_a] || E_KUb[E_KRauth [N_a || K_s || ID_A || ID_B]]
6. B→A: E_KUa[E_KRauth [N_a || K_s || ID_A || ID_B] ||N_b]
7. A→B: E_Ks[N_b]

Den forbedrede varianten tar med identiteten til A (ID_A) i den signerte listen av elementer som sendes i steg 5 og 6.

Enveisautentisering

Hvis man skal bruke offentlige nøkler for epost, enten det er for konfidensialitet, autentisering eller begge, er det ikke særlig gunstig å bruke offentlig-nøkkel-kryptering på hele meldingen. For konfidensialitet vil man kryptere meldingen med en tilfeldig symmetrisk sesjonsnøkkel som så krypteres med den offentlige nøkkelen til mottakeren. Hvis det er autentisering man er ute etter, kan det være tilsrtekkelig med en digital signatur.

Federated Identity Management

FIM er et relativt nytt konsept som dreier seg om bruk av et felles identitethåndteringssystem på tvers av organisasjoner, flere applikasjoner, med støtte for mange brukere. Tilbudte tjenester omfatter: kontaktpunkt, enkelt-påloggings-tjenester (SSO), tillitstjenester, nøkkeltjenester,  identitetstjenester, autorisering, tilrettelegging og administrasjon.

Nøkkelstandarder

FIM baserer seg på et utvalg sentrale standarder:

• Extensible Markup Language (XML) – Et markeringsspråk som bruker innebygde merkelapper for å karakterisere tekstelementer innen et dokument for å indikere utseende, funksjon, betydning eller kontekst.
• Simple Object Access Protocol (SOAP) – Gjør applikasjoner i stand til å be om tjenester fra hverandre med XML-baserte anmodninger, og motta svar som data formattert med XML.
• WS-Security – En samling SOAP-utvidelser for å implementere meldingsintegritet og konfidensialtitet i Web services
• Security Assertion Markup Language (SAML) – Et XML-basert språk for å utveksle sikkerhetsinformasjon mellom forretningsforbindelser over nettet.

Personal Identity Verification

Brukerautentisering basert på at man er i besittelse av et smartkort er i ferd med å bli vanlig. Et smartkort ser som kjent ut som et kredittkort med et elektronisk grensesnitt (de karakteristiske metallkontaktene oppe til venstre – men nå blir stadig flere trådløse), og kan bruke et utvalg forskjellige autentiseringsprotokoller.

Et smartkort har innebygget en hel liten datamaskin, med prosessor, minne og I/O porter. Smartkortet har tre typer minne: Read-only memory (ROM) som lagrer data som ikke endrer seg i løpet av kortets levetid, elektronisk slettbar programmerbar ROM (EEPROM) som lagrer applikasjonsdata og programmer (også data som kan variere over tid), og Random access memory (RAM) som lagrer midlertidige data som genereres nå applikasjoner kjører.

Det finnes en rekke standarder som definerer forskjellige aspekter av PIV og hvordan det brukes.

PIV akkreditiver og nøkler

• Personal Identification Number (PIN) – nødvendig for å aktivere kortet for privilegert operasjon.
• Cardholder Unique Identifier (CHUID) – inkluderer Federal Agency Smart Credential Number (FASC-N) og Global Unique Identification Number (GUID), som identifiserer kort og korteier på en unik måte.
• PIV Authentication Key – asymmetrisk nøkkelpar og korresponderende sertifikat for autentisering.
• To fingeravtrykk-sjablonger (templates) – for biometrisk autentisering
• Electronisk ansiktsbilde – for biometrisk autentisering.
• Asymmetrisk kort-autentiseringsnøkkel – asymmetrisk nøkkelpar og korresponderende certifikat for autentisering av kortet.

Valgfrie elementer omfatter følgende:

• Digital Signaturnøkkel – asymmetrisk nøkkelpar og korresponderende sertifikat som understøtter signering av dokumenter og signering av dataelementer som
• Nøkkeladministrasjonsnøkkel– asymmetrisk nøkkelpar og korresponderende sertifikat som understøtter etablering og overføring av sesjonsnøkler.
• Symmetrisk kortautentiseringsnøkkel – for å understøtte fysiske tilgangsapplikasjoner.
• PIV kort-applikasjon administrasjonsnøkkel – symmetrisk nøkkel assosiert med kortadministrasjonssystemet.
• Ett eller to iris-bilder – for biometrisk autentisering.

Ved å bruke de elektroniske akkreditivene som lligger på et PIV-kort understøtter kortet følgende autentiseringsmekanismer:

• CHUID: Korteieren autentiseres det signerte CHUID data elementet på kortet. PIN er ikke påkrevd. Denne mekanismen er nyttig i miljøer hvor et lavt tiltronivå er akseptabelt, og rask kontaktøs autentisering er påkrevd.
• Kortautentiseringsnøkkel: PIV-kortet autentiseres vha. kortautentiseringsnøkkelen i en utfordring-svar-protokoll. PIN er ikke påkrevd. Denne mekanismen tillater kontakt-basert (via kortleser) eller kontaktløs (via radiobølger) autentisering av PIV-kortet uten aktiv deltakelse av kortholderen, og gir et lavt nivå av tiltro.
• BIO: Kortholderen er autentisert ved å sammenligne hennes fingeravtrykk med de signerte biometriske dataene som er lagret på kortet, uten at det overvåkes av en menneskelig observatør. PIN kreves for å aktivere kortet. Mekanismen oppnår et høyt tiltronivå, og krever kortholderens aktive deltakelse ved tasting av PIN og presentering av biometrisk prøve (fingeravtrykk).
• BIO-A: Kortholderen er autentisert ved å sammenligne hennes fingeravtrykk med de signerte biometriske dataene som er lagret på kortet, samtidig som at det overvåkes av en menneskelig observatør. PIN kreves for å aktivere kortet. Mekanismen oppnår et svært høyt tiltronivå når den kobles til en full tillitsvalidering av den biometriske sjablongen som hentes fra kortet, og krever kortholderens aktive deltakelse ved tasting av PIN og presentering av biometrisk prøve (fingeravtrykk).
• PKI: Kortholderen autentiseres ved å demonstrere kontroll over den private PIV-autentiseringsnøkkelen i en utfordring-svar-protokoll som kan valideres av PIV-autentiseringssertifikatet. PIN kreves for å aktivere kortet. Mekanismen oppnår et svært høyt tiltronivå, og krever at kortholderen kjenner til PIN.

Illustrasjon ved Timm Suess, CC BY-SA 2.0