Bruksområder for PKI: HTTPS, S/MIME og kodesignering

Public Key Infrastructure (PKI) er den usynlige ryggraden i sikker digital kommunikasjon. Sertifikatene og CA-ene De har studert, brukes daglig i dusinvis av virkelige scenarier. Security+-eksamen tester evnen Deres til å gjenkjenne bruksområder for PKI, forstå hvilken sertifikattype som passer i hvert tilfelle, og identifisere hvilken beskyttelse PKI gir i hver sammenheng. De tre viktigste bruksområdene på eksamen er HTTPS/TLS (nettsikkerhet), S/MIME (e-postsikkerhet) og kodesignering (programvareintegritet).

HTTPS (HTTP over TLS) er det mest synlige bruksområdet for PKI. Når De kobler til https://bank.com, gjør nettleseren følgende: (1) mottar TLS-sertifikatet til serveren, (2) bekrefter at sertifikatkjeden fører til en klarert rot-CA, (3) kontrollerer vertsnavnet mot SAN-feltene, (4) bekrefter at sertifikatet ikke er tilbakekalt, og (5) bruker den offentlige nøkkelen i en Diffie-Hellman-nøkkelutveksling for å opprette en kryptert økt. Hengelåsikonet i nettleseren viser at alle disse kontrollene er bestått. Et manglende eller ugyldig sertifikat utløser en nettleseradvarsel som hindrer de fleste brukere i å fortsette.

S/MIME (Secure/Multipurpose Internet Mail Extensions) bruker PKI-sertifikater til å tilby to sikkerhetstjenester for e-post. Kryptering: Avsenderen krypterer e-postinnholdet med mottakerens offentlige nøkkel, slik at bare mottakeren kan dekryptere det – og beskytter konfidensialiteten selv om e-posten blir fanget opp under overføring eller lagret på en kompromittert server. Digitale signaturer: Avsenderen signerer med sin private nøkkel, noe som beviser overfor mottakeren at e-posten faktisk kommer fra avsenderen og ikke er endret – og beskytter integriteten samt gir ikke-benektelse. S/MIME krever at hver bruker har sitt eget sertifikat utstedt av en CA.

Kodesignering bruker PKI til å signere programvare digitalt – kjørbare filer, skript, drivere og installasjonsprogrammer – slik at brukere kan bekrefte at programvaren kommer fra en klarert utgiver og ikke er manipulert. Programvareleverandøren signerer koden med en privat nøkkel fra et kodesigneringssertifikat som er utstedt av en klarert CA. Når en bruker kjører programvaren, bekrefter operativsystemet signaturen ved hjelp av leverandørens offentlige nøkkel fra sertifikatkjeden. Windows SmartScreen, macOS Gatekeeper og appbutikkene for iOS/Android er alle avhengige av kodesignering for å etablere programvarens opphav. Usignert programvare kan bli blokkert eller utløse sikkerhetsadvarsler.

Autentisering med klientsertifikat (også kalt gjensidig TLS eller mTLS) utvider den vanlige TLS-modellen ved å kreve at klienten også presenterer et sertifikat. I standard TLS blir bare serveren autentisert med sertifikat; i mTLS blir begge parter gjensidig autentisert. Dette brukes til: VPN-autentisering (smartkort eller klientsertifikater i stedet for passord), API-autentisering (maskin-til-maskin-autentisering der klienten er en tjeneste, ikke en person) og privilegert administratortilgang (der administratorer må bruke maskinvarebrikker med innebygde sertifikater).

SSH bruker kryptografi med offentlige nøkler til to formål: serverautentisering og klientautentisering. Serverautentisering: Når De kobler til en SSH-server for første gang, presenterer den vertsnøkkelen sin (offentlige nøkkel). SSH-klienten lagrer denne i ~/.ssh/known_hosts. Ved senere tilkoblinger varsler SSH Dem hvis vertsnøkkelen er endret, noe som kan indikere et MITM-angrep eller at serveren er bygget på nytt. Klientautentisering: I stedet for passord bruker administratorer nøkkelpar – den offentlige nøkkelen legges til i serverens authorized_keys, og den private nøkkelen (som aldri sendes) beviser identiteten. SSH-vertsnøkler er separate fra PKI-sertifikater, men har samme tillitsfunksjon.

PKI muliggjør juridisk bindende digital dokumentsignering i mange jurisdiksjoner. Adobe PDF-signaturer, DocuSign og offentlige systemer for elektroniske signaturer bruker alle PKI-sertifikater til å signere dokumenter. Et viktig supplement til dokumentsignering er tidsstempling: En Trusted Timestamp Authority (TSA) medsignerer dokumentets hash med et betrodd tidspunkt og beviser dermed at dokumentet eksisterte på et bestemt tidspunkt. Tidsstempling er også avgjørende for kodesignering – uten et tidsstempel blir kodesignaturer ugyldige når signeringssertifikatet utløper, selv for programvare som ble distribuert før utløpsdatoen.

Etter hvert som IoT-enheter blir stadig mer utbredt, tilbyr PKI en mekanisme for å autentisere enheter i stor skala. Hver enhet utstyres med et unikt sertifikat under produksjonen (en prosess kalt klargjøring av enhetsidentitet), slik at servere kan autentisere enkeltstående enheter ved hjelp av sertifikatene deres. Dette muliggjør scenarier som at en smartmåler beviser identiteten sin overfor energiselskapets server, at en medisinsk enhet autentiserer seg mot et sykehusnettverk, eller at en kjøretøyflåte autentiserer seg mot produsentens backend. IoT-PKI må håndtere millioner av enheter med begrensede ressurser, noe som driver bruken av ECC-sertifikater på grunn av den lille størrelsen og raske verifiseringen.

Sertifikatbasert VPN-autentisering er betydelig sikrere enn passordbasert VPN-autentisering. Hver VPN-bruker eller -enhet får utstedt et klientsertifikat av organisasjonens interne CA. Ved tilkobling bekrefter VPN-gatewayen klientsertifikatet (og kontrollerer at det er utstedt av den klarerte interne CA-en, er innenfor gyldighetsperioden og ikke er tilbakekalt via CRL/OCSP). Når en ansatt slutter, hindrer tilbakekalling av sertifikatet umiddelbart VPN-tilgang – noe som er mer pålitelig enn å håpe at vedkommende ikke har delt passordet sitt med andre.

Sikkerhetseksperter må kunne diagnostisere vanlige sertifikatfeil. Sertifikatet er utløpt: Datoen notAfter er passert – forny sertifikatet. Vertsnavnet samsvarer ikke: SAN-en i sertifikatet samsvarer ikke med det forespurte vertsnavnet – kontroller CN-er og SAN-er; det kan være nødvendig med et jokertegnsertifikat eller et sertifikat med flere SAN-er. Selvsignert sertifikat: Ingen CA har gått god for sertifikatet – legg det til i det lokale tillitslageret eller erstatt det med et CA-signert sertifikat. Ufullstendig kjede: Det mellomliggende CA-sertifikatet leveres ikke av serveren – konfigurer serveren til å sende hele kjeden. Sertifikatet er tilbakekalt: CRL eller OCSP viser tilbakekalling – umiddelbar håndtering av kompromittert nøkkel er nødvendig.

To sertifikattyper håndterer flere vertsnavn. Et jokertegnsertifikat dekker alle underdomener på første nivå i et domene: *.example.com dekker www.example.com, mail.example.com og api.example.com, men IKKE sub.api.example.com (to nivåer). Ett sertifikat og én privat nøkkel for alle tjenester er praktisk, men risikabelt hvis nøkkelen kompromitteres (alle tjenester rammes). Et sertifikat med flere SAN-er viser uttrykkelig flere bestemte domener i SAN-utvidelsen (for eksempel example.com, www.example.com og api.example.com). Dette gir mer detaljert kontroll, men krever at sertifikatet oppdateres når nye domener legges til.

I denne leksjonen har De lært at HTTPS/TLS bruker serversertifikater til å kryptere nettrafikk og autentisere servere; S/MIME-sertifikater muliggjør signering og kryptering av e-post; kodesigneringssertifikater beviser programvareintegritet og utgiverens identitet; og klientsertifikater muliggjør gjensidig autentisering for VPN-er og API-er. Neste tema er passordregler og flerfaktorautentisering.