하드웨어 보안은 정상적으로 작동하고 있습니다. 그게 문제는 아닙니다.

우리는 이와 비슷한 반론을 자주 듣습니다. "저희는 이미 Android StrongBox를 사용하고 있습니다. ECDH 키 교환 방식도 사용하고 있고요. 키는 하드웨어 밖으로 나가지 않습니다. 왜 그 위에 화이트박스 암호화가 필요한 거죠?" 

타당한 질문입니다. StrongBox, TEE가 지원하는 Keystore, 그리고 ECDH는 확실히 강력한 기술입니다. 이러한 기술들을 무시하는 것은 지적으로 정직하지 못한 처사이며, 도움이 되지도 않습니다. 따라서 이러한 기술들을 무시하기보다는, 실제로 무엇을 보호하는지, 그리고 어떤 허점이 있는지 살펴보겠습니다.

금고 비유와 그것이 불완전한 이유 

하드웨어 보안은 한 가지 면에서 탁월합니다. 바로 키를 안전하게 보관하는 것입니다. safe 금고 안에 보관합니다. StrongBox는 키를 생성하고 저장하며 암호화 작업을 수행하지만, 원시 키 자료는 절대 노출하지 않습니다. 이것이 진정한 보호이며 매우 중요합니다. 

하지만 대부분의 보안 설계자들이 묻지 않는 질문이 있습니다. 가장 중요한 작전을 수행하는 경로에 금고가 있습니까? 

HttpsURLConnection, OkHttp 또는 이와 유사한 OS 관리 API를 사용하여 표준 서버 연결을 수행하는 Android 앱의 경우, 답은 대체로 '아니오'입니다. Android의 TLS 스택은 BoringSSL과 Conscrypt라는 두 가지 소프트웨어 라이브러리를 통해 실행되며, StrongBox나 TEE Keystore를 거치지 않고 ECDH 키 교환을 소프트웨어 자체에서 처리합니다. TLS 세션 키는 기기의 하드웨어 사양과 관계없이 메모리에 원시 바이트 형태로 존재합니다. 

이것은 안드로이드 설계의 결함이 아니라, 대부분의 앱 보안 논의에서 간과되는 아키텍처적 현실입니다. 여러분의 데이터 저장소는 훌륭합니다. 하지만 TLS의 경우, 그 저장소가 건물 안에 있지 않습니다. 

바이너리 데이터가 공격 표면일 때 

TLS는 잠시 접어두고, 하드웨어 기반 키를 사용하여 자체 암호화 작업을 수행하는 앱을 생각해 보세요. 이러한 키는 적절하게 프로비저닝되고, ECDH 방식으로 생성되어, StrongBox에 안전하게 저장됩니다. 이는 매우 강력한 설정입니다. 

이제 공격자가 실제로 여러분의 앱으로 무엇을 하는지 생각해 보세요. 공격자는 StrongBox에서 보안 키를 추출하려고 시도하지 않습니다. 그건 어렵거든요. 공격자는 앱을 다운로드하고, 역어셈블러를 실행해서 코드를 읽습니다. 

그들이 찾아내는 것은 핸드셰이크 로직입니다. 즉, 앱이 서버와 통신하는 데 사용하는 프로토콜, 인증 흐름, API 구조입니다. 이러한 이해를 바탕으로 그들은 사용자의 키가 필요하지 않습니다. 그들은 처음부터 합법적인 것처럼 보이는 핸드셰이크를 완료하는 수정된 앱을 구축합니다. StrongBox는 이러한 방식으로 작동합니다. 그들의 이제 해당 장치는 서버가 신뢰하는 키를 보유하게 됩니다. 

더 큰 피해를 줄 수 있는 공격은 단순히 한 사용자의 복호화된 데이터를 읽는 것이 아닙니다. 프로토콜을 충분히 이해하여 인증된 API 요청을 위조하는 것, 그것도 대규모로, 임의의 사용자로 가장하여 요청하는 것입니다. 이러한 공격은 하드웨어 자체에는 영향을 미치지 않기 때문에 하드웨어 보안으로는 대응할 수 없습니다. 

이것이 바로 화이트박스 암호화와 애플리케이션 강화의 핵심 과제입니다. 단순히 키만 보호하는 것이 아니라 프로토콜 로직 자체를 보호하는 것이죠. 

분열 문제 (지속되는 동안) 

BoringSSL의 현실은 차치하더라도, 안드로이드에서 하드웨어 보안은 적용 범위에 문제가 있습니다. 안드로이드 기기 보안에 대한 동료 평가를 거친 DroidCCT 연구에 따르면, StrongBox는 프리미엄급 기기의 8.7%, 중급급 기기의 7.2%, 저가형 기기의 0.2%에서만 사용 가능합니다. 즉, 대부분의 사용자는 StrongBox를 사용할 수 없는 상황입니다. 

iOS는 상황이 다릅니다. Secure Enclave는 현재 모든 iOS 기기에 탑재되어 강력한 하드웨어 기반 보안을 제공합니다. 파편화 문제는 주로 안드로이드에 해당됩니다. 

이러한 주장이 유효기간이 있다는 점을 인지해야 합니다. 하드웨어 가용성은 시간이 지남에 따라 개선될 것이며, 일부 보안 가이드라인에서는 하드웨어 도입이 따라잡을 때까지 TEE를 보완하는 임시 방편으로 화이트박스 암호화를 이미 권장하고 있습니다. 바이너리 역공학, 인증, 그리고 벤더 독립성은 지속적인 영향력을 발휘할 것이지만, 현재로서는 파편화가 중요한 논거입니다. 특히 규제나 공급망 제약이 있는 조직의 경우, 특정 하드웨어 벤더의 보안 구현에 대한 의존도를 줄이는 것 자체가 설계 목표가 될 수 있습니다. 

"앱 레이어 인증"이란 실제로 무엇을 의미하는가? 

한 가지 더 언급할 만한 문제점이 있습니다. 서버는 핸드셰이크를 완료했지만, 누구와 통신하고 있는지 알지 못합니다. 

이 시스템은 실제 기기에서 실행되는 정식 앱, 루팅된 기기에서 실행되는 재패키징된 앱, 그리고 프로토콜을 역분석하여 핸드셰이크를 모방한 완전히 합성된 클라이언트를 구분할 수 없습니다. 

Google Play 무결성 API가 도움이 됩니다. 적절한 nonce와 requestHash 바인딩을 사용하면 MEETS_STRONG_INTEGRITY 등급을 달성하여 우회 가능성을 크게 줄일 수 있습니다. 하지만 무결성 등급과 관계없이 프록시 장치를 이용한 재실행은 여전히 ​​위험 요소로 남아 있습니다. 

화이트박스 암호화는 애플리케이션 계층 인증을 제공합니다. 즉, 운영 체제나 하드웨어 신뢰 신호와는 별개로, 요청이 보호된 프로토콜 로직을 실행하는 수정되지 않은 애플리케이션에서 발생했음을 암호화 방식으로 증명하는 것입니다. 이는 Play Integrity를 ​​대체하는 것이 아니라, Play Integrity가 해결할 수 없는 부분을 보완하는 두 번째 독립적인 신호입니다. 

이보다 더 정교한 버전이자 업계가 나아갈 방향은 지속적인 행동 검증입니다. 즉, 이 클라이언트가 마지막 요청 이후 변조 감지를 발생시켰는지 여부를 확인하는 것입니다. 클라이언트의 런타임 보안 상태에 따라 응답을 조절할 수 있는 서버는 세션 설정 시 신뢰/비신뢰 여부를 이분법적으로 판단하는 서버보다 훨씬 더 강력한 복원력을 갖습니다. 

전체 그림 

하드웨어 보안은 금고와 같습니다. 화이트박스 암호화와 애플리케이션 강화는 금고를 떠나 현실 세계에 나가야 하는 모든 것을 보호하는 장갑 운송 수단입니다. 

대부분의 안드로이드 TLS 작업에서 볼트는 경로에 포함되지 않습니다. 경로에 포함되는 경우에도 프로토콜, 바이너리 또는 인증 계층을 보호하지는 않습니다. 이는 하드웨어 보안을 포기해야 할 이유가 아니라, 하드웨어 보안을 완전한 방어 체계의 한 계층으로 간주해야 한다는 것을 의미합니다. 

다음은 저희 엔지니어링, 보안 및 고객 성공 팀과 함께 내부적으로 스트레스 테스트를 거친 네 가지 논점입니다. 이 외에도 특정 플랫폼, 규정 준수 프레임워크 등에 어떻게 적용되는지 등 더 자세한 내용이 있습니다.Digital.ai 키 및 데이터 보호는 FIPS 140-3 인증서(#4910)를 보유하고 있으며, 업계에서 요구하는 규제 사항을 준수합니다. 

앱 보호 방안을 평가 중이시고, 귀사 환경에 적용되는 전체적인 그림을 살펴보고 싶으시다면 언제든지 문의해 주세요. 지금 데모를 요청하세요