Certificate Pinning: ano ito, mekanismo at mga paraan ng pag-pin

Ano ang Certificate Pinning?

Certificate Pinning — ay isang teknik sa seguridad kung saan iniimbak ng app ang fingerprint ng isang pinagkakatiwalaang sertipiko at ginagamit ito bilang tanging pamantayan para magtatag ng HTTPS na koneksyon. Sa karaniwang modelo ng TLS, sinusuri ng kliyente kung ang sertipiko ng server ay nilagdaan ng isang pinagkakatiwalaang root CA — alinman sa daan-daang pre-install na awtoridad sa system. Pinapalitan ng Certificate Pinning ang chain na ito ng direktang pagsusuri: ang sertipiko ay dapat tumugma sa naka-imbak na sample o naglalaman ng inaasahang pampublikong susi.

Ang problema ng karaniwang modelo ay naging halata pagkatapos ng mga insidente ng kompromiso ng CA — DigiNotar (2011), Comodo (2011), TrustCor (2022). Kung ang CA ay nag-isyu ng pekeng sertipiko para sa iyong domain, tatanggapin ito ng browser o app bilang wasto. Certificate Pinning ay pumipigil sa pag-atake na ito: kahit isang perpektong nilagdaang pekeng sertipiko ay tatanggihan, dahil ang fingerprint nito ay hindi tumutugma sa naka-pin sa app.

Ang terminong pinning ay nagmula sa pin — “aspili” o “panali”: inaayos ng developer ang pinagkakatiwalaang sertipiko, at anumang paglihis dito ay humaharang sa koneksyon. Ayon sa pananaliksik ng Mitre CWE-295, ang hindi tamang pag-validate ng sertipiko ay nananatiling isa sa top-10 pinakadelikadong pagkakamali sa seguridad sa mobile apps, at ang Certificate Pinning ay direktang paraan upang maiwasan ito.

Kasaysayan at ebolusyon ng Certificate Pinning

Sa simula, ginamit ang Certificate Pinning sa mga browser sa pamamagitan ng mekanismong HPKP (HTTP Public Key Pinning), na na-standardize sa RFC 7469. Nagpadala ang developer ng HTTP header na Public-Key-Pins na may mga hash ng inaasahang susi, at naaalala sila ng browser para sa isang tinukoy na panahon. Gayunpaman, napatunayang mapanganib ang HPKP: isang pagkakamali sa configuration ay maaaring humarang sa site nang ilang buwan. Noong 2018, itinigil ng Chrome ang suporta para sa HPKP, at ngayon ang pamantayan ay software implementasyon sa panig ng kliyente — sa loob ng mobile app o browser extension.

Paano gumagana ang Certificate Pinning?

Ang proseso ng Certificate Pinning ay may kasamang tatlong pangunahing yugto: pagkalkula ng fingerprint, pag-verify sa koneksyon, at paghawak ng error. Sa yugto ng paghahanda, nakukuha ng developer ang SHA-256 hash ng sertipiko o pampublikong susi ng production server. Para sa mga app na sumusunod sa GDPR at PCI DSS, kinakailangan din na i-pin ang mga fingerprint ng mga intermediate na CA sa chain.

Sa bawat HTTPS na kahilingan, naharang ng app ang TLS authentication callback, kinukuha ang sertipiko ng server, at kinakalkula ang SHA-256 hash nito. Ang hash na ito ay inihambing sa naka-imbak na listahan ng mga pinagkakatiwalaang fingerprint. Kung may natagpuang tugma — magpapatuloy ang koneksyon. Kung wala — dapat putulin ng app ang koneksyon at iulat ang error, nang hindi isinasapubliko ang mga detalye ng implementasyon sa umaatake.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

Tumatanggap ang function ng X509Certificate object mula sa server at inaasahang hash. Una, kinukuha ang pampublikong susi ng sertipiko, kinakalkula ang SHA-256 hash at naka-encode sa Base64. Ang resulta ay inihambing sa inaasahang fingerprint. Sa produksyon, makabubuting magdagdag ng pagsusuri sa isang array ng 2–3 fingerprint para suportahan ang rotasyon.

Certificate Pinning vs Public Key Pinning

Sa pagpapatupad ng pinning, kailangang pumili kung aling cryptographic object ang i-pin. Ang Certificate Pinning ay kumakapit sa X.509 certificate mismo — ang serial number nito, panahon ng bisa, at buong chain. Ang Public Key Pinning ay nagpi-pin lamang ng pampublikong susi sa loob ng sertipiko, hindi pinapansin ang iba pang field. Ang pagpili ay malaki ang epekto sa mga gastos sa operasyon.

Public Key Pinning — ang mas gustong pagpili para sa karamihan ng mga proyekto. Ang mga pampublikong susi ng server ay karaniwang nananatiling hindi nagbabago kapag muling inisyu ang sertipiko — nilalagdaan lang ng kumpanya ang lumang susi ng bagong sertipiko. Ibig sabihin nito na ang app ay hindi nangangailangan ng update pagkatapos ng pagbabago ng sertipiko, kung ang key pair ay hindi nagbago. Ang Certificate Pinning ay inirerekomenda para sa mga senaryo kung saan ganap na kinokontrol ng developer ang parehong server at client code, halimbawa, sa corporate apps na may mahigpit na cycle ng update.

Trust On First Use (TOFU)

TOFU — isang estratehiya kung saan ang Certificate Pinning ay hindi na-configure nang maaga, ngunit naaalala ang sertipiko sa unang koneksyon sa server. Ang approach na ito ay maginhawa para sa mga app na hindi alam nang maaga kung aling server ang kokonektahan. Ang disadvantage — kahinaan sa unang pag-atake: kung ang unang koneksyon ay naharang, ang pekeng sertipiko ay tatanggapin bilang pinagkakatiwalaan. Ang TOFU ay ginagamit sa SSH connections at ilang P2P protocol.

Implementasyon sa iOS at Android

Sa parehong platform, ang Certificate Pinning ay ipinapatupad sa pamamagitan ng pagharang ng TLS connection sa antas ng network stack. Sa iOS, ginagamit ang URLSession delegate o Alamofire ServerTrustManager. Sa Android, ang mas gustong paraan ay OkHttp CertificatePinner, na naka-embed sa mga sikat na HTTP client at sumusuporta sa configuration ng maraming fingerprint para sa bawat domain.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

Sa Swift function, mula sa serverTrust ay kinukuha ang chain ng mga sertipiko, para sa bawat isa ay kinakalkula ang SHA-256 hash, at ang resulta ay inihambing sa inaasahan. Ang pagdaan sa lahat ng sertipiko sa chain ay nagbibigay-daan sa pagpapatupad ng pinning sa antas ng intermediate na CA — kung ang intermediate na sertipiko ay tugma, ang koneksyon ay tinatanggap. Ito ay nagbibigay ng flexibility sa rotasyon ng mga leaf certificate.

TrustManager para sa Android (custom)

Kung ang app ay hindi gumagamit ng OkHttp, ang Certificate Pinning ay maaaring ipatupad sa pamamagitan ng custom na X509TrustManager. Ang pamamaraang ito ay nangangailangan ng mas maraming code, ngunit nagbibigay ng ganap na kontrol sa proseso ng pag-verify. Ang TrustManager ay nag-o-override sa checkServerTrusted method, kung saan manu-manong sinusuri ng developer ang mga sertipiko ng server at gumagawa ng desisyon tungkol sa pagtitiwala. Inirerekomenda lamang para sa mga tiyak na senaryo kung saan ang OkHttp library ay hindi available.

Mga pagkakamali sa implementasyon ng Certificate Pinning

Ang pinakakaraniwang pagkakamali — kawalan ng backup pins. Ang developer ay naglalagay ng isang fingerprint ng sertipiko, at sa pag-expire nito, ang mga user ay nawawalan ng koneksyon nang maramihan. Ang minimum na katanggap-tanggap na configuration — dalawang fingerprint: kasalukuyang sertipiko at backup. Optimal — tatlo: kasalukuyan, backup, at fingerprint ng root CA bilang fallback.

Pangalawang pagkakamali — pag-iimbak ng mga pin sa bukas na anyo sa code. Ang isang umaatake na may access sa APK o IPA ay madaling kumuha at magpalit ng mga fingerprint. Inirerekomenda ang obfuscation ng mga hash: hatiin ang string sa mga bahagi, iimbak sa naka-encrypt na resources, o kalkulahin sa pamamagitan ng runtime. Para sa Android, epektibo ang ProGuard na may obfuscation ng string constants.

Pangatlong pagkakamali — pinning sa antas ng development certificate. Ang development at production certificate ay karaniwang magkaiba, ngunit madalas nakakalimutan ng mga developer na palitan ang mga pin kapag nagbu-build ng release. Resulta — ang production app ay hindi makakonekta sa server. Solusyon — hiwalay na configuration ng pin para sa debug at release sa pamamagitan ng BuildConfig o flavour-specific resources.

• Ignoring certificate chain — pagsusuri lamang ng leaf certificate nang hindi isinasaalang-alang ang mga intermediate na CA, na pumuputol ng koneksyon sa rotasyon
• Hardcoded dates — hardcoded na petsa ng pag-expire ng sertipiko na hindi nagbabago pagkatapos ng update
• No monitoring — kawalan ng mga alerto para sa Certificate Pinning errors, dahil dito ang mga problema ay natutuklasan lamang mula sa mga user
• TOFU nang walang validation — paggamit ng Trust On First Use nang walang karagdagang pagsusuri, na nagpapahintulot sa unang MITM attack na mag-pin ng pekeng sertipiko