PKI-anvendelser: HTTPS, S/MIME og code signing

Public Key Infrastructure (PKI) er den usynlige grundstruktur for sikker digital kommunikation. De certifikater og CA'er, du har studeret, anvendes dagligt i snesevis af virkelige scenarier. Security+-eksamen tester din evne til at genkende PKI-anvendelsestilfælde, forstå hvilken certifikattype der passer til hvert tilfælde, og identificere hvilken beskyttelse PKI giver i den enkelte sammenhæng. De tre vigtigste anvendelsestilfælde på eksamen er HTTPS/TLS (websikkerhed), S/MIME (e-mailsikkerhed) og kodesignering (softwareintegritet).

HTTPS (HTTP over TLS) er det mest synlige PKI-anvendelsestilfælde. Når du opretter forbindelse til https://bank.com, gør din browser følgende: (1) modtager serverens TLS-certifikat, (2) kontrollerer, at certifikatkæden fører til en betroet rod-CA, (3) kontrollerer værtsnavnet mod SAN-felterne, (4) kontrollerer, at certifikatet ikke er tilbagekaldt, og (5) bruger den offentlige nøgle til en Diffie-Hellman-nøgleudveksling for at etablere en krypteret session. Hængelåsikonet i browseren betyder, at alle disse kontroller er bestået. Et manglende eller ugyldigt certifikat medfører en browseradvarsel, som får de fleste brugere til at stoppe.

S/MIME (Secure/Multipurpose Internet Mail Extensions) bruger PKI-certifikater til at levere to sikkerhedstjenester til e-mail. Kryptering: Afsenderen krypterer e-mailens indhold med modtagerens offentlige nøgle, så kun modtageren kan dekryptere det — det beskytter fortroligheden, selv hvis e-mailen opsnappes under transport eller gemmes på en kompromitteret server. Digitale signaturer: Afsenderen signerer med sin private nøgle, hvilket beviser over for modtageren, at e-mailen faktisk kommer fra afsenderen og ikke er blevet ændret — det beskytter integriteten og sikrer uafviselighed. S/MIME kræver, at hver bruger har sit eget certifikat udstedt af en CA.

Kodesignering bruger PKI til at signere software digitalt — eksekverbare filer, scripts, drivere og installationsprogrammer — så brugerne kan kontrollere, at softwaren kommer fra en betroet udgiver og ikke er blevet manipuleret. Softwareleverandøren signerer sin kode med en privat nøgle fra et kodesigneringscertifikat, der er udstedt af en betroet CA. Når en bruger kører softwaren, kontrollerer operativsystemet signaturen ved hjælp af leverandørens offentlige nøgle fra certifikatkæden. Windows SmartScreen, macOS Gatekeeper og appbutikkerne til iOS og Android er alle afhængige af kodesignering for at fastslå softwarens oprindelse. Usigneret software kan blive blokeret eller udløse sikkerhedsadvarsler.

Godkendelse med klientcertifikat (også kaldet gensidig TLS eller mTLS) udvider den almindelige TLS-model ved også at kræve, at klienten fremlægger et certifikat. I standard-TLS godkendes kun serveren med et certifikat; i mTLS godkendes begge parter gensidigt. Det bruges til: VPN-godkendelse (smartkort eller klientcertifikater i stedet for adgangskoder), API-godkendelse (maskine-til-maskine-godkendelse, hvor klienten er en tjeneste og ikke et menneske) og privilegeret administratoradgang (hvor administratorer skal bruge hardwaretokens med indlejrede certifikater).

SSH bruger kryptografi med offentlige nøgler til to formål: servergodkendelse og klientgodkendelse. Servergodkendelse: Når du opretter forbindelse til en SSH-server for første gang, præsenterer den sin værtsnøgle (offentlige nøgle). Din SSH-klient gemmer den i ~/.ssh/known_hosts. Ved efterfølgende forbindelser advarer SSH dig, hvis værtsnøglen er ændret, hvilket kan være tegn på et MITM-angreb eller en genopbygning af serveren. Klientgodkendelse: I stedet for adgangskoder bruger administratorer nøglepar — den offentlige nøgle føjes til serverens authorized_keys, og den private nøgle (som aldrig sendes) beviser identiteten. SSH-værtsnøgler er adskilt fra PKI-certifikater, men har samme tillidsfunktion.

PKI muliggør juridisk bindende digital dokumentsignering i mange jurisdiktioner. Adobe PDF-signaturer, DocuSign og offentlige systemer til elektroniske signaturer bruger alle PKI-certifikater til at signere dokumenter. Et vigtigt supplement til dokumentsignering er tidsstempling: En Trusted Timestamp Authority (TSA) medsignerer dokumentets hash med et betroet tidspunkt og beviser dermed, at dokumentet eksisterede på et bestemt tidspunkt. Tidsstempling er også afgørende for kodesignering — uden et tidsstempel bliver kodesignaturer ugyldige, når signeringscertifikatet udløber, selv for software, der blev distribueret før udløbet.

Efterhånden som IoT-enheder bliver mere udbredte, giver PKI en mekanisme til at godkende enheder i stor skala. Hver enhed forsynes med et unikt certifikat under fremstillingen (en proces kaldet klargøring af enhedsidentitet), så servere kan godkende individuelle enheder ud fra deres certifikater. Det muliggør scenarier som: en intelligent elmåler, der beviser sin identitet over for forsyningsselskabets server, en medicinsk enhed, der godkendes på et hospitalsnetværk, eller en flåde af køretøjer, der godkendes over for producentens backend. IoT-PKI skal håndtere millioner af enheder med begrænsede ressourcer, hvilket fremmer brugen af ECC-certifikater på grund af deres lille størrelse og hurtige kontrol.

Certifikatbaseret VPN-godkendelse er betydeligt mere sikker end VPN-godkendelse baseret på adgangskoder. Hver VPN-bruger eller -enhed får udstedt et klientcertifikat af organisationens interne CA. Ved oprettelse af forbindelse kontrollerer VPN-gatewayen klientcertifikatet (og sikrer, at det er udstedt af den betroede interne CA, er inden for sin gyldighedsperiode og ikke er blevet tilbagekaldt via CRL/OCSP). Når en medarbejder fratræder, forhindrer tilbagekaldelse af vedkommendes certifikat straks VPN-adgang — det er mere pålideligt end at håbe på, at medarbejderen ikke har delt sin adgangskode med andre.

Sikkerhedsprofessionelle skal kunne diagnosticere almindelige certifikatfejl. Certifikatet er udløbet: Datoen notAfter er overskredet — forny certifikatet. Uoverensstemmelse mellem værtsnavne: Certifikatets SAN matcher ikke det ønskede værtsnavn — kontrollér CN'er og SAN'er; der kan være behov for et wildcard- eller multi-SAN-certifikat. Selvsigneret certifikat: Ingen CA har godkendt dette certifikat — føj det til det lokale tillidslager, eller erstat det med et CA-signeret certifikat. Ufuldstændig kæde: Det mellemliggende CA-certifikat leveres ikke af serveren — konfigurer serveren til at sende hele kæden. Certifikatet er tilbagekaldt: CRL eller OCSP viser tilbagekaldelse — øjeblikkelig reaktion på kompromittering af nøglen er nødvendig.

To certifikattyper håndterer flere værtsnavne. Et wildcard-certifikat dækker alle underdomæner på første niveau af et domæne: *.example.com dækker www.example.com, mail.example.com og api.example.com, men IKKE sub.api.example.com (to niveauer). Ét certifikat og én privat nøgle til alle tjenester — praktisk, men risikabelt, hvis nøglen kompromitteres (alle tjenester påvirkes). Et multi-SAN-certifikat angiver udtrykkeligt flere bestemte domæner i SAN-udvidelsen (for eksempel example.com, www.example.com og api.example.com). Det giver større detaljeringsgrad, men kræver, at certifikatet opdateres, når der tilføjes nye domæner.

I denne lektion har du lært, at HTTPS/TLS bruger servercertifikater til at kryptere webtrafik og godkende servere; S/MIME-certifikater muliggør signering og kryptering af e-mail; kodesigneringscertifikater beviser softwarens integritet og udgiverens identitet; og klientcertifikater muliggør gensidig godkendelse til VPN'er og API'er. Næste emne er adgangskodepolitikker og multifaktorgodkendelse.