Certificate Pinning: vad är det, metoder för certifikatbindning och hur implementerar man

Fördelar och nackdelar med Certificate Pinning

Certificate Pinning ökar säkerheten för mobilappen avsevärt, men lägger en operativ börda på utvecklingsteamet. Det är viktigt att väga fördelarna med skydd mot risken för anslutningsblockering vid felaktig implementering.

Den största fördelen — skydd mot Man-in-the-Middle-attacker, inklusive fall av CA-kompromettering. Pinning gör falska certifikat utfärdade av angriparen värdelösa: även om CA har signerat en förfalskning kommer appen att avvisa den. En extra fördel — skydd mot företagsproxyservrar som byter ut certifikat för trafikinspektion. Enligt Google Security Blog (2023) har appar med pinning 86% mindre chans att bli hackade genom trafikavlyssning jämfört med appar som endast använder standard TLS-verifiering.

Den största nackdelen med pinning — risken för självblockering: om serverns certifikat ändras (förlängning, byte av leverantör, nyckelrotation) innan appuppdateringen släpps förlorar användarna åtkomst till servern. Ytterligare nackdelar: svårighet med felsökning (vid varje ändring av inställningar måste pins uppdateras), ökning av APK-storleken med 5–15 KB vid användning av TrustKit och omöjlighet att snabbt återställa ändringar utan ny version. För att minimera risker används reservpins, automatisk rotation varannan till var tredje månad och en grace-period där appen accepterar både gamla och nya certifikat. Man måste också beakta att med aktiverad pinning under utveckling kan man inte använda proxyverktyg (Burp Suite, Charles) för felsökning av nätverksförfrågningar — för utvecklingsbyggen bör pinning inaktiveras via flaggan BuildConfig.DEBUG, och QA-testning bör utföras på releasesignaturen med aktiverat skydd. Vissa team använder en staging-domän med separat pinning-certifikat för utvecklingsmiljön för att behålla skyddet även i utvecklingsfasen.

Implementera Certificate Pinning i Android

Låt oss titta på ett exempel på hur man implementerar Certificate Pinning på Android med OkHttp — standardbiblioteket för nätverksförfrågningar. OkHttp tillhandahåller en inbyggd CertificatePinner som accepterar SHA-256-hashar av offentliga nycklar.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

I koden ovan lägger vi till två pins för domänen api.example.com: primär (aktuellt certifikat) och reserv (för rotation). OkHttp kontrollerar automatiskt om serverns certifikat matchar någon av de angivna SHA-256-fingeravtrycken. För att få SHA-256-fingeravtrycket av certifikatet används kommandot: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Det är viktigt att lagra fingeravtrycken inte i öppen form i koden utan krypterade eller förskingrade: statisk analys MobSF hittar lätt nakna SHA-256-strängar i DEX-filer. Det rekommenderas att lagra pins i res/raw-resurser, krypterade via AES, och dekryptera dem vid appstart via inbyggd kod (NDK/JNI).

Implementering på iOS via TrustKit

På iOS är huvudverktyget för Certificate Pinning det öppna källkodsbiblioteket TrustKit. Till skillnad från OkHttp konfigureras TrustKit deklarativt via Info.plist, vilket gör det möjligt att ändra pins utan att omkompilera appen. Konfigurationen innehåller en ordbok med domäner och en array av SHA-256-fingeravtryck av offentliga nycklar. TrustKit fångar automatiskt upp NSURLSession-förfrågningar och kontrollerar certifikat innan dataöverföringen börjar. En nyckelfunktion hos TrustKit — stöd för pin-valideringsrapporter: biblioteket kan skicka rapporter till en angiven slutpunkt vid pin-avvikelse, vilket möjliggör snabb reaktion på certifikatanomalier. Apple tillhandahåller också den inbyggda mekanismen NSPinnedDomains i Info.plist från och med iOS 14, men TrustKit förblir det föredragna valet tack vare mer flexibel konfiguration, rapportstöd och möjlighet till het utbyte av pins utan systemuppdatering. TrustKit integreras med URLSession via delegaten didReceiveChallenge och returnerar .performDefaultHandling vid lyckad pin-verifiering och .cancelAuthenticationChallenge vid avvikelse. För övervakning av pin-valideringsrapporter rekommenderas att konfigurera en separat slutpunkt som analyserar frekvensen av fel: om antalet rapporter plötsligt ökar — kan detta indikera en MitM-attack eller förestående certifikatutgång som kräver omedelbar pin-uppdatering.