Certificate Pinning: 개념, 인증서 바인딩 방법 및 구현 방법

Certificate Pinning의 장단점

Certificate Pinning은 모바일 애플리케이션 보안을 크게 향상시키지만 개발 팀에 운영 부담을 줍니다. 잘못된 구현으로 인한 연결 차단 위험과 보안 이점을 저울질하는 것이 중요합니다.

주요 장점은 CA 손상 사례를 포함한 Man-in-the-Middle 공격으로부터의 보호입니다. Pinning은 공격자가 발행한 가짜 인증서를 무용지물로 만듭니다: CA가 위조 서명을 한 경우에도 애플리케이션이 이를 거부합니다. 추가 이점은 트래픽 검사를 위해 인증서를 교체하는 기업용 프록시 서버로부터의 보호입니다. Google Security Blog(2023)에 따르면, pinning을 사용하는 애플리케이션은 표준 TLS 검증만 사용하는 애플리케이션에 비해 트래픽 가로채기를 통해 손상될 확률이 86% 낮습니다.

Pinning의 주요 단점은 자체 차단 위험입니다: 애플리케이션 업데이트가 출시되기 전에 서버 인증서가 변경(갱신, 제공자 변경, 키 순환)되면 사용자가 서버에 액세스할 수 없게 됩니다. 추가 단점: 디버깅 복잡성(구성 변경 시마다 핀 업데이트 필요), TrustKit 사용 시 APK 크기 5–15 KB 증가, 새 릴리스 없이 변경 사항을 신속하게 롤백할 수 없음. 위험을 최소화하기 위해 백업 핀, 2–3개월마다 자동 순환, 애플리케이션이 이전 및 새 인증서를 모두 수용하는 유예 기간이 사용됩니다. 또한 pinning을 활성화한 개발 중에는 프록시 도구(Burp Suite, Charles)를 사용하여 네트워크 요청을 디버깅할 수 없다는 점도 고려해야 합니다 — 개발 빌드의 경우 BuildConfig.DEBUG 플래그를 통해 pinning을 비활성화해야 하며, QA 테스트는 보호 기능이 활성화된 릴리스 서명으로 수행해야 합니다. 일부 팀은 개발 중에도 보호를 유지하기 위해 개발 환경용 별도 pinning 인증서가 있는 스테이징 도메인을 사용합니다.

Android에서 Certificate Pinning 구현

OkHttp — 네트워크 요청의 표준 라이브러리 — 를 사용하여 Android에서 Certificate Pinning을 구현하는 예를 살펴보겠습니다. OkHttp는 공개키의 SHA-256 해시를 수락하는 내장 CertificatePinner를 제공합니다.

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

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

위 코드에서는 도메인 api.example.com에 대해 두 개의 핀을 추가합니다: 기본 핀(현재 인증서)과 백업 핀(순환용)입니다. OkHttp는 서버의 인증서가 지정된 SHA-256 지문 중 하나와 일치하는지 자동으로 확인합니다. 인증서의 SHA-256 지문을 얻으려면 다음 명령을 사용합니다: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. 지문을 코드에 일반 텍스트로 저장하지 않고 암호화 또는 난독화하여 저장하는 것이 중요합니다: MobSF 정적 분석은 DEX 파일에서 원시 SHA-256 문자열을 쉽게 찾습니다. 핀은 AES를 통해 암호화된 res/raw 리소스에 저장하고 네이티브 코드(NDK/JNI)를 통해 애플리케이션 시작 시 복호화하는 것이 좋습니다.

TrustKit을 통한 iOS 구현

iOS에서 Certificate Pinning의 주요 도구는 오픈 소스 TrustKit 라이브러리입니다. OkHttp와 달리 TrustKit은 Info.plist를 통해 선언적으로 구성되므로 애플리케이션을 다시 컴파일하지 않고도 핀을 변경할 수 있습니다. 구성에는 도메인이 있는 딕셔너리와 SHA-256 공개키 지문 배열이 포함됩니다. TrustKit은 NSURLSession 요청을 자동으로 가로채고 데이터 전송이 시작되기 전에 인증서를 확인합니다. TrustKit의 중요한 기능은 핀 검증 보고서 지원입니다: 라이브러리는 핀 불일치 시 지정된 엔드포인트에 보고서를 보내 인증서 이상에 신속하게 대응할 수 있습니다. Apple은 iOS 14부터 Info.plist에서 네이티브 NSPinnedDomains 메커니즘도 제공하지만, TrustKit은 더 유연한 구성, 보고서 지원 및 OS 업데이트 없이 핀을 핫스왑할 수 있는 기능으로 인해 선호되는 선택입니다. TrustKit은 didReceiveChallenge 델리게이트를 통해 URLSession과 통합되며, 핀 검증 성공 시 .performDefaultHandling을, 불일치 시 .cancelAuthenticationChallenge를 반환합니다. 핀 검증 보고서 모니터링을 위해 오류 빈도를 분석하는 별도의 엔드포인트를 설정하는 것이 좋습니다: 보고서 수가 급격히 증가하면 — 이는 MitM 공격 또는 즉각적인 핀 업데이트가 필요한 임박한 인증서 만료를 나타낼 수 있습니다.