Certificate pinning i mobil- og desktopapplikationer

Standard-TLS stoler på ethvert certifikat, der er signeret af en af de cirka 150 rod-CA'er, som er forudinstalleret i operativsystemet. Hvis en rod-CA kompromitteres eller tvinges til det, kan en angriber få et certifikat til ethvert domæne og opsnappe TLS-trafik. Certifikatbinding begrænser tilliden til et bestemt certifikat eller en bestemt offentlig nøgle, uanset hvilken CA der har signeret det. En applikation med certifikatbinding afviser forbindelser til sine servere, medmindre serveren præsenterer præcis det forventede certifikat eller den forventede nøgle. Denne beskyttelse er især værdifuld for mobilapps, hvor brugerne ikke kan inspicere netværkstrafik, og hvor virksomheders MDM-løsninger måske installerer rod-CA'er fra virksomheden.

Der findes tre detaljeringsniveauer for certifikatbinding: (1) Fuld certifikatbinding — det præcise DER-kodede certifikat skal matche. Dette er den mest skrøbelige metode: den går i stykker ved enhver fornyelse af certifikatet. (2) Binding af offentlig nøgle — kun SubjectPublicKeyInfo- (SPKI-)byte sammenlignes. Den overlever fornyelse af certifikatet, hvis det samme nøglepar bevares. (3) Hash af SPKI — gem SHA-256(SPKI) i stedet for den rå nøgle. Dette er tilgangen i HTTP Public Key Pinning (HPKP) og Android Network Security Config. Binding af offentlig nøgle eller SPKI foretrækkes: den overlever rotation af CA og fornyelse af certifikater, samtidig med at MITM-angreb med et andet nøglepar stadig opdages.

Android (API 24+) tilbyder en deklarativ mekanisme til certifikatbinding via XML-konfigurationen Network Security Config. Filen res/xml/network_security_config.xml angiver bindinger pr. domæne: pin-set med digest="SHA-256" og den base64-kodede SPKI-hash. Appen refererer til denne fil i AndroidManifest.xml via android:networkSecurityConfig. Android håndhæver bindingerne for alle HTTP-forbindelser, der oprettes gennem standard-HttpsURLConnection og OkHttp, når platformens tillidsstyring bruges. Pin-settet kræver mindst én reservebinding (en anden nøgle eller CA-binding) for at forhindre udelukkelse, hvis den primære nøgle kompromitteres. Udløb af bindingen (attributten expiration) tvinger apps til at opdatere, før bindingerne bliver forældede.

iOS-apps implementerer certifikatbinding i NSURLSession-delegerede objekter. Delegeringsmetoden URLSession(_:didReceive:completionHandler:) modtager serverens tillidsobjekt. Appen kalder SecTrustEvaluateWithError for at validere kæden, udtrækker derefter bladcertifikatet med SecTrustGetCertificateAtIndex(trust, 0), eksporterer dets SPKI-byte, beregner deres SHA-256-hash og sammenligner den med den gemte binding. TrustKit (et open source-bibliotek) omslutter dette mønster med konfigurationsbaseret certifikatbinding og understøtter flere bindinger, matchning af underdomæner og tilstanden kun rapportering. Apples App Transport Security (ATS) er separat fra certifikatbinding — ATS håndhæver minimumsversioner for TLS, men binder ikke nøgler.

HTTP Public Key Pinning (HPKP, RFC 7469) forsøgte at tilføje certifikatbinding for webbrowsere via HTTP-svarheadere: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Browseren ville huske bindingen i den angivne max-age-periode og afvise forbindelser til nøgler, der ikke matchede. HPKP blev forældet i Chrome i 2017 og fjernet i 2019 på grund af katastrofale fejl: en enkelt forkert konfiguration eller mistet nøgle kunne permanent udelukke brugere fra et websted uden mulighed for genoprettelse. HPKP er nu reelt dødt i webbrowsere; certifikatbinding på applikationsniveau i mobilapps er stadig anvendelig, fordi appopdateringer kan indeholde nye bindinger.

OkHttp (udbredt på Android) understøtter certifikatbinding via CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Den anden binding er reservebindingen. OkHttp verificerer, at mindst én binding matcher et certifikat i serverens kæde — bladcertifikatet, et mellemliggende certifikat eller rodcertifikatet. Det gør det muligt at binde til en mellemliggende CA, som overlever rotation af bladcertifikatet, eller til rod-CA'en, som overlever rotation af det mellemliggende certifikat. OkHttp udløser en SSLPeerUnverifiedException med en nyttig meddelelse, der viser serverens faktiske SPKI-hashværdier, så det er enkelt at udlede bindinger under udviklingen.

Certifikatbinding gør det sværere at opsnappe trafik, men den er ikke umulig at bryde. Almindelige metoder til omgåelse på mobilenheder er: (1) Frida-hooks — injicer JavaScript i applikationsprocessen for at hægte sig på metoden, der verificerer bindingen, og ubetinget returnere true. (2) SSLUnpinning-værktøjer — automatiserede Frida-/Objection-scripts, der målrettes almindelige biblioteker til certifikatbinding (TrustKit, OkHttp, native SecTrust). (3) Tilpasset ROM — få root-adgang til enheden, og ændr TLS-stakken. (4) Ompakning — dekompiler APK'en, ændr konfigurationen for certifikatbinding, og pak den igen med et nyt certifikat. (5) Patching af hukommelsen — patch den bytekode, der udfører verificeringen, under kørsel. Modforanstaltninger: detektering af root/jailbreak, kodeobfuskering og integritetskontroller (SafetyNet/App Attest).

Den største driftsmæssige risiko ved certifikatbinding er at låse sig selv ude: Hvis produktionsnøglen går tabt, eller certifikatet udløber, og reservebindingen ikke er tilgængelig, er brugerne udelukket, indtil en appopdatering udgives (dage til uger). God praksis er: (1) Bind altid mindst to nøgler — den aktuelle nøgle og en forudgenereret reservenøgle, der opbevares offline (i en HSM eller et luftgab). (2) Angiv en udløbsdato for bindingen, og udgiv appopdateringer før udløbet. (3) Overvåg fejl i bindingen via tilstanden kun rapportering, før bindingen håndhæves. (4) Oprethold et nødopdateringsforløb for appen (fremskyndet godkendelse) til hændelser med rotation af bindinger. (5) Bind på niveauet for den mellemliggende CA, ikke bladcertifikatet, så bladcertifikater kan roteres uden appopdateringer.

Desktopapplikationer skrevet i Electron, Qt eller platformens eget sprog kan implementere certifikatbinding ved hjælp af API'er i deres TLS-stak. Electron-apps bruger hændelsen app.on("certificate-error") og session.setCertificateVerifyProc() til at implementere brugerdefineret verificering. Qt-netværkskode bruger QSslSocket med et brugerdefineret verificerings-callback. .NET-applikationer bruger ServicePointManager.ServerCertificateValidationCallback. Native Windows-apps bruger WinHTTP med manuel inspektion af certifikater. Desktopapplikationer står over for yderligere udfordringer: TLS-inspektion på operativsystemniveau via virksomhedsproxyer er almindelig, og brugerne forventer måske, at proxyfunktionalitet virker — hvilket kræver en beslutning om, hvorvidt certifikatbinding kun skal gælde for bestemte endpoints.

Certifikatbinding komplicerer automatiserede test og CI/CD-forløb. Integrationstest, der foretager ægte HTTPS-kald til præproduktionsservere, skal bruge testcertifikater, hvis SPKI-hashværdier er angivet i en testkonfiguration. Muligheder: (1) Byggevarianter — fejlfindings-/præproduktionsbygningen indeholder bindinger til præproduktionsserveren; udgivelsesbygningen indeholder produktionsbindinger. (2) Tilsidesættelser af Network Security Config — Android tillader konfiguration af bindinger, der kun gælder ved fejlfinding. (3) Simuleringsserver — aflyt ved HTTP-klientlaget før TLS, så certifikatbinding helt omgås. (4) Selvsigneret CA til CI — udsted testcertifikater fra en CI-CA, hvis rod kun er tillid til i testbygninger. Udgiv aldrig en bygning med deaktiveret certifikatbinding i produktion.

Certifikatbindinger er typisk hashværdier af offentlige RSA- eller EC-nøgler. Når postkvante-migreringen begynder, skifter servere til ML-DSA (CRYSTALS-Dilithium) eller hybridnøgler. Bundne SPKI-hashværdier ændres, fordi nøgletypen og kodningen ændres. Apps, der binder bladcertifikater eller offentlige nøgler, får brug for koordinerede opdateringer: (1) Udgiv en ny appversion med den postkvante SPKI-hash som reservebinding, før servermigreringen. (2) Gennemfør servermigreringen. (3) Udgiv en opdatering, der fjerner den gamle klassiske binding. Overgangsperioden kræver omhyggelig koordinering. Apps, der binder mellemliggende CA'er eller rod-CA'er, påvirkes mindre — kun CA'ens nøgle ændres, og ikke nødvendigvis samtidig med bladcertifikaterne.

Certifikat-pinning begrænser TLS-tillid til et bestemt certifikat eller en bestemt offentlig nøgle og beskytter mod kompromittering af en CA og MITM-angreb. SPKI-hash-pinning (SHA-256 af SubjectPublicKeyInfo) foretrækkes frem for pinning af hele certifikatet, fordi det er mere robust over for fornyelser. Android bruger Network Security Config-XML, iOS bruger URLSession-delegering med SecTrust-API'er, og OkHttp understøtter CertificatePinner. Medtag altid en reserve-pin for at undgå at låse dig selv ude. HPKP (HTTP-headeren til browsere) er udfaset. Pinning kan omgås ved hjælp af Frida-hooks og ROM-ændringer. Overgangen til postkvantekryptering kræver koordinerede appopdateringer for at opdatere SPKI-hashes.