모바일 보안에 대한 신뢰 재고: 화이트 박스 암호화가 중요한 이유

미션 크리티컬 모바일 애플리케이션을 배포하는 모든 조직에게 가장 중요한 과제는 통제할 수 없는 환경에서 암호화 키와 민감한 데이터를 보호하는 것입니다. 일반적인 접근 방식은 Android Keystore 및 iOS Secure Enclave와 같은 플랫폼 고유의 보안 기능에 의존하는 것입니다. 하지만 이것만으로 항상 충분할까요?

플랫폼 기반 보안에 내장된 가정을 검토하고 소프트웨어 기반 보호의 추가 계층과 같은 위협 모델을 살펴보겠습니다. 화이트박스 암호화, 필수적이 됩니다.

이러한 차이점을 이해하는 것은 보안 태세를 실제 위험에 맞게 조정하는 정보에 입각한 결정을 내리는 데 중요합니다.

플랫폼 보안의 역할

Android Keystore 및 iOS Secure Enclave와 같은 플랫폼 보안 기능은 모바일 보안의 기반이 됩니다. 이러한 기능은 제대로 구현되고 사용 가능할 경우 암호화 키에 대한 강력하고 하드웨어 가속 보안을 제공합니다. 하지만 플랫폼 보안에만 의존하려면 애플리케이션이 작동하는 환경에 대해 몇 가지 중요한 가정을 해야 합니다. 이러한 가정을 살펴보겠습니다.

가정 1: 플랫폼 보안은 항상 사용 가능하고 일관적입니다.

현실: 모바일 생태계는 파편화되어 있습니다. 수백만 대의 구형 또는 저가형 기기에는 최신 하드웨어 기반 보안이 미흡합니다. 더욱이, Android Keystore와 같은 기능의 구현 방식은 제조업체마다 크게 달라 보안 보장의 일관성이 떨어질 수 있습니다. 플래그십 Google Pixel에서 효과적인 보안 전략이 저가형 기기나 수정된 ​​OEM 버전의 Android에서는 효과적이지 않을 수 있습니다.

가정 2: 장치는 항상 신뢰할 수 있습니다.

현실: 루팅이나 탈옥을 통해 기기가 침해되면 전체 플랫폼의 신뢰 모델이 붕괴됩니다. 이러한 기기에서는 Frida나 Xposed와 같은 일반적인 도구를 사용하는 공격자가 보안 API를 조작하여 해킹할 수 있습니다. 플랫폼 자체가 침해되면 모든 보안을 플랫폼 API에 위임하는 것은 구조적으로 큰 부담이 됩니다.

가정 3: 위협 모델은 API 경계에서 끝납니다.

현실: 정교한 공격자는 아키텍처 다이어그램을 무시합니다. 하드웨어 보안에 대한 역방향 프록시 공격을 생각해 보세요.

• 공격자는 장치를 루팅하고 애플리케이션이 Secure Enclave에 대해 수행하는 API 호출을 가로챕니다.
• 앱이 합법적인 암호화 작업(예: 거래 서명)을 요청하면 해당 요청이 가로채집니다.
• 공격자의 맬웨어는 요청을 실제 Secure Enclave로 전달하고, Secure Enclave는 유효한 서명을 반환합니다.
• 공격자는 이제 원격으로 남용할 수 있는 서명 오라클을 보유하게 되었는데, 키가 기술적으로 보안 하드웨어를 벗어나지 않았더라도 마찬가지입니다.

플랫폼 보안만으로는 이를 방어할 수 없습니다. 수신한 요청이 합법적인지 확인할 수 없기 때문입니다.

심층 방어: 플랫폼 가정이 실패할 때

고위험 애플리케이션의 경우 "플랫폼을 신뢰하라"는 접근 방식은 충분하지 않습니다. 바로 이 부분에서 소프트웨어 기반 보호 기능을 통합한 심층 방어 전략이 중요해집니다.

화이트박스 암호화는 이러한 "제로 트러스트" 시나리오를 위해 설계되었습니다. 키를 한 곳(하드웨어 기반일지라도)에 저장하는 대신, 키를 암호화 구현 코드 자체에 수학적으로 연결합니다. 공격자가 장치를 완전히 제어하고 애플리케이션 바이너리를 분석할 수 있더라도, 키를 추출하는 데 따르는 계산상의 어려움에서 보안이 확보됩니다. 이는 "모호함을 통한 보안"이 아닙니다. 비밀이 발견되면 모호함은 무력화됩니다. 적절하게 강화된 화이트박스 구현은 공격자가 바이너리, 실행 추적, 메모리 덤프 등 모든 것을 가지고 있다는 가정 하에 설계되었습니다. 화이트박스 구현의 보안은 모든 현대 암호화의 근간이 되는 원리인 계산상의 견고함에 기반합니다.

실제 애플리케이션

모바일 뱅킹 애플리케이션은 루팅된 기기가 흔하고 하드웨어 기반 키스토어 구현이 일관되지 않거나 전혀 없는 신흥 시장에서 운영됩니다.

은행의 위협 모델에는 다음이 포함됩니다.

• Frida를 통해 연결할 수 있는 Keystore API가 있는 루팅된 기기
• 하드웨어 보안 기능이 부족한 저가형 기기
• API 호출을 가로챌 수 있는 정교한 맬웨어

이러한 분산된 환경에서 거래 서명 키를 보호하기 위해 은행은 계층형 방어를 구현했습니다.

• 기준: 사용 가능하고 신뢰할 수 있는 기기의 Android 키스토어
• 심층 방어: Digital.ai 중요 서명 작업을 위한 화이트박스 암호화

이를 통해 기기 보안 기능에 관계없이 일관된 키 보호가 보장됩니다. 플랫폼 보안을 우회할 수 있는 손상된 기기의 경우, 화이트박스 구현은 키 추출에 필요한 시간과 전문 지식을 크게 증가시키는 컴퓨팅 강화 기능을 제공합니다. 이를 통해 3시간짜리 공격이 맞춤형 분석이 필요한 4개월의 작업으로 전환됩니다.

모바일 보안 솔루션 평가를 위한 프레임워크

보안 아키텍처를 선택할 때 중요한 것은 어떤 기술이 "더 나은지"가 아니라, 특정 위협 모델에 어떤 기술이 적합한지입니다. 정보에 기반한 결정을 내리려면 보안 공급업체에 다음 질문을 고려해 보세요.

• 위협 모델: OS를 신뢰할 수 없는 손상된(루팅/탈옥) 장치에서 암호화 키와 작업을 보호하기 위한 솔루션 전략은 무엇입니까?
• 일관성 : 데스크톱, iOS, Android 제조업체 및 OS 버전의 분산된 환경에서 균일한 보안 속성과 동작을 보장하려면 어떻게 해야 합니까?
• 확인: 솔루션의 암호화 모듈은 알려진 공격에 대한 정확성과 견고성을 검증하기 위해 독립적인 제3자 검증 및 인증을 거쳤습니까? 솔루션에 기밀 유지 협약(NDA)에 따라 제공되는 평판 있는 제3자 기관의 침투 테스트 보고서가 포함되어 있습니까?
• 규정 준수 실적: 귀사는 보안 관련 표준을 준수하기 위해 어떤 실적을 보이고 있나요?
• 다각화: "BREAK ONSE, RUN ARE Everywhere"(BORE) 공격을 방지하기 위해 어떤 조치가 마련되어 있습니까? 솔루션은 인스턴스별 다각화를 지원하여 대규모 공격을 경제적으로 불가능하게 만듭니까?
• 장단점: 해당 솔루션의 성능과 코드 크기에 미치는 영향은 무엇이며, 어떤 사용 사례에서 그러한 균형이 정당화됩니까?

보안 태세상 기기의 신뢰성을 전제로 한다면, 플랫폼 기반 기능을 활용하는 것이 효율적이고 강력한 선택입니다. 그러나 위협 모델에 정교한 공격자와 침해된 기기가 포함되어 있다면, 독립적으로 검증된 소프트웨어 기반 암호화를 포함하는 심층 방어 전략은 허황된 것이 아니라 현실 세계를 위한 엔지니어링입니다.

화이트박스 암호화에 대한 일반적인 비판에 대한 대처

보안 기술을 평가할 때는 연구용 프로토타입과 실제 운영에 적용된 솔루션을 구분하는 것이 중요합니다. Appdome의 최근 블로그 게시물경쟁 모바일 보안 업체인 는 화이트박스 암호화를 "가짜"라고 일축합니다. 그들의 비판은 학술 연구 구현과 실제 운영 환경에서 강화된 솔루션을 혼동하는 것입니다.

그들의 핵심 요점을 직접 살펴보겠습니다.

비판: "학계의 많은 화이트박스 계획이 무너졌습니다."

맞습니다. 모든 암호학의 학문적 과정은 체계를 공개하고 다른 연구자들이 이를 해독하도록 하는 과정을 포함합니다. 이러한 공개적인 검토가 AES와 TLS와 같은 기술을 강력하게 만드는 것입니다. 학문적 화이트박스 구현은 종종 이론적 속성을 탐구하기 위해 단순화됩니다.

그러나 생산에 강화된 상용 솔루션은 학문적 개념 증명에서 설계상 생략된 여러 계층의 방어 기능을 통합합니다.

• 차등 계산 분석(DCA) 및 차등 오류 분석(DFA) 대책
• 런타임 무결성 검사 및 오류 감지 및/또는 자체 복구
• "한 번 깨면 어디든 실행"(BORE) 공격을 방지하기 위한 인스턴스별 다각화
• 난독화 및 런타임 애플리케이션 자체 보호(RASP)와의 통합

학계가 해킹당했기 때문에 모든 화이트박스 암호화가 무용지물이라고 주장하는 것은 마치 영화에서 감옥 탈출이 가능하다는 것을 보여주었기 때문에 감옥이 쓸모없다고 주장하는 것과 같습니다. 이는 연구 개념과 실전에서 검증된 다층적 방어 체계의 차이를 왜곡하는 것입니다.

비판: "화이트박스 암호화는 모호함을 통한 보안일 뿐입니다."

이는 기술의 작동 방식을 근본적으로 잘못 표현하고 있습니다. "은폐를 통한 보안"의 원칙은 시스템이 safe 내부 작동 방식이 비밀로 유지되는 한 말이죠.

화이트박스 암호는 정반대 원리, 즉 계산적 난해성(computational hardness)을 기반으로 작동합니다. 화이트박스 암호의 보안 모델은 공격자가 바이너리에 대한 완전한 접근 권한을 가지고 있으며 알고리즘을 알고 있다고 가정합니다. 이 보안은 인코딩되고 변환된 구현에서 키 자료를 추출하는 데 필요한 수학적 어려움에 의존합니다. 이는 현대 공개 키 암호의 근간이 되는 원리와 동일합니다. 핵심은 암호 방식을 숨기는 것이 아니라, 공격자가 실질적인 시간 내에 해독하기 어려운 수학적 원리를 구현하는 것입니다.

독립적 검증의 문제

Appdome은 자체 솔루션의 효과에 대한 증거를 제시하지 않고 상업용 화이트박스 암호화 구현을 일축합니다.

Digital.ai Key & Data Protection의 화이트박스 암호화 솔루션 FIPS 140-3이 검증되었나요? (인증서 번호 #4910; 2024년 FIPS140-2 표준 만료 전 인증 - 인증 번호 #2840)은 NIST 공인 암호화 시험소 두 곳에서 독립적으로 검증되었습니다. 이 검증을 통해 암호화 알고리즘의 올바른 구현, 안전한 키 관리 및 연방 보안 표준 준수가 확인되었습니다.

Appdome 웹사이트에 FIPS140에 대한 자세한 설명이 있는 페이지가 있음에도 불구하고, 저는 검증 인증서가 존재하는지 독립적으로 확인할 수 없었습니다.

금융 서비스, 의료, 정부 등 규제 대상 산업에 종사하는 조직의 경우, 독립적인 검증은 선택 사항이 아닙니다. 보안 관리에 대한 실사를 입증하는 필수 요건입니다.

공격자가 기기를 완전히 제어할 수 있고, API를 연결하여 실행을 모니터링할 수 있고, 플랫폼 보안이 이용 불가능하거나 손상된 경우에도 당사의 구현은 암호화 키를 계속 보호합니다.

플랫폼 보안이 실패할 때

화이트박스 암호화를 부정하는 비평가들은 손상된 기기에 대한 대안적인 접근 방식을 거의 설명하지 않습니다. Appdome은 주로 플랫폼 보안 기능, 즉 루팅된 기기에서 후킹 및 프록시가 가능한 API에 의존하는 것으로 보입니다. 플랫폼이 손상되면 플랫폼 API를 래핑하는 것만으로는 추가적인 보안 효과를 얻을 수 없습니다. 바로 이 부분을 소프트웨어 기반 암호화 강화가 해결합니다.

중요한 애플리케이션에 대한 보안 결정을 내리는 조직의 경우, 독립적인 검증이 마케팅 주장보다 더 효과적이라고 믿습니다.

맺음말

화이트박스 암호화는 만병통치약이 아닙니다. 이는 플랫폼 보안 기능(사용 가능하고 적절한 경우), 코드 난독화, 런타임 애플리케이션 자가 보호, 보안 통신, 그리고 보안 개발 관행을 포함하는 포괄적인 심층 방어 전략의 한 단계일 뿐입니다.

회사 소개 Digital.ai 키 및 데이터 보호: 당사의 화이트박스 암호화 솔루션은 FIPS140-3 인증을 받았으며, 전 세계 금융 서비스, 보험, 의료, 정부 및 게임 애플리케이션에 구축되어 있습니다. 장치 침해, 플랫폼 단편화, 정교한 공격 등의 위협 모델을 가진 조직을 위해 당사는 독립적으로 검증된 심층 방어 보안을 제공합니다.