건강 관리 스타트업이 월간 이상의 시간을 보낼 수 있는 보안 모바일 워크플로우를 설계하고, 감옥화된 테스터의 전화로 환자 기록이 스크린샷과 로컬 캐시를 통해 노출된 것을 발견할 수 있습니다. 동시에 팀의 Electron 관리 패널의 디버그 빌드는 API 키가 패키지에 포함된 채로 배포될 수 있습니다. 두 가지 사례 모두 암호화와 관련이 있지만, 단순히 암호화 라이브러리를 추가하는 것으로 해결되지 않습니다.
앱 암호화는 시스템의 결정입니다. 팀은 데이터가 저장되는 동안 보호되는지, 시스템 간에 데이터가 이동하는지, 키가 어디에 존재하는지, 애플리케이션 패키지에서 공격자가 무엇을 학습할 수 있는지, 런타임이 조작에 어떻게 반응하는지, signed 업데이트가 보장된 약속을 유지하는지에 대한 결정이 필요합니다. 유용한 시작점은 sensitive 데이터, 신뢰 경계, 클라이언트 기능, 그리고 유력한 악용 경로를 매핑하는 앱 위험 평가 로 구성됩니다.
모바일 및 크로스 플랫폼 애플리케이션은 특히 취약한 환경에 있습니다. 장치들은 사무실을 떠나고, 빌드는 복사되거나 사이드 로드될 수 있으며, 로컬 파일은 검사될 수 있고, 역 엔지니어링 도구는 널리 사용되고 있습니다. 아래의 섹션은 저장, 전송, 플랫폼 키 보호, 클라이언트 측 비밀성, 규정 준수, 및 릴리스 작업을 차례대로 설명합니다.
목차
- 앱 암호화는 지금보다 더 중요합니다
- 앱 암호화가 지금보다 더 중요합니다.
- 앱 Code, 데이터 및 비밀을 보호하는 방법
- iOS, Android, Capacitor, 및 Electron을 위한 플랫폼 고려 사항
- 키 관리 및 클라이언트 측 비밀의 한계
- 규제 및 준수 요구 사항
- 일반적인 실수와 강화된 최선의 관행
- 앱 암호화 계획에 모든 것을 통합하는 방법
앱 암호화가 지금보다 더 중요해진 이유
웹 애플리케이션은 일반적으로 조직이 관리하는 인프라에서敏感한 논리와 비밀 자료를 많이 보관합니다. 모바일 애플리케이션은 code, 자산, 구성, 데이터 처리 논리를 장치에 속한 다른 사람에게 보냅니다. Electron 애플리케이션은 유사한 문제를 가지고 있습니다. 왜냐하면 JavaScript, 리소스 및 패키지 파일은 사용자가 애플리케이션을 실행할 수 있는 사용자가 검사할 수 있습니다.
그것은 보안 경계를 변경합니다. 클라이언트는 유용하지만 보관소가 아닙니다. 정보를 비공식적으로 검사하고 훔친 파일을 덜 유용하게 보호할 수 있지만 앱은 여전히 평문에 접근해야 하는 경우가 있습니다. 공격자가 장치를 제어하는 경우 입력을 관찰할 수 있으며 메모리를 검사하고 API를 도구화하거나 실행을 수정할 수 있습니다.
건강 관리 예를 들어보겠습니다. 데이터베이스를 암호화하면 디스크에서 복사된 기록을 보호할 수 있지만 실행 중인 런타임이 악성 프로세스에게 암호화된 기록을 표시하는 것을 막을 수는 없습니다. 클리닉의 요청을 백엔드로 전송하는 동안 네트워크 트래픽을 암호화하면 보호할 수 있지만 앱이 보호되지 않은 캐시에 저장한 후 지역 내보내기 보호를 제공하지 않습니다. 미니파이드 자바스크립트에 숨겨진 키는 여전히 회복 가능합니다.
실용적인 규칙: 모든 클라이언트 측 보호를 노출을 줄이는 층으로 다루세요. 장치가 신뢰할 수 있다고 가정하지 마세요.
완전한 디자인은 일반적으로 combination합니다.
- 휴면 보호데이터베이스, 파일, 캐시, 선호도 및 다운로드 문서와 같은 데이터를 보호합니다.
- 수송 보호요청, 동기화, 업데이트 전달 및 서비스 간 통신과 같은 데이터를 보호합니다.
- 플랫폼 키 저장소암호화 키가 일반적인 애플리케이션 파일에 남지 않도록 합니다.
- Code 및 런타임 보호및 가려움, 무결성 검사, 디버깅 방지 조치 및 적절한 인증서 검증.
- A 제어된 업데이트 채널이유는 서명된 릴리스가 이전 버전에 빌드된 보안 가정들을 보존해야 하기 때문이다.
- 문서화된 준수 제어소유권, 증거, 모니터링 및 대응 절차를 포함하여.
규제 의무는 압력을 가하지만, 엔지니어링의 규율을 향상시킨다. GDPR, HIPAA, PCI DSS 및 SOC 2는 암호화를 일반적인 체크박스로 만드는 것이 아니다. 암호화를 보호하는 데 무엇을 보호해야 하는지, 키가 어떻게 관리되는지, 보안 장치가 작동하는지 증명할 수 있는지 이해해야 한다.
전송 중 암호화 versus 저장 중 암호화
신분증명된 우편으로 보내는 비밀 문서를 생각해 보세요. 봉투가 보호하는 메시지는 사람들 사이를 이동하는 동안 보호됩니다. 받는 사람이 열어 버리면 문서는 여전히 잠금이 걸린 서류함이 필요합니다. 전송 중 암호화는 이동을 보호하고, 저장 중 암호화는 저장을 보호합니다. 봉투와 서류함은 서로 다른 문제를 해결합니다.
저장 중 암호화
저장 중 암호화는 데이터가 장치, 서버 디스크, 백업, 데이터베이스 또는 이동식 볼륨에 저장되는 경우에 적용됩니다. 모바일 플랫폼에서 운영 체제 보호가 자동으로 장치의 일부를 암호화하는 경우에도, 애플리케이션은 여전히 안전한 저장 위치, 접근 제어 및 키 사용을 선택해야 합니다. sensitive 애플리케이션 파일은 플랫폼 지원 암호화 및 키를 보호된 저장소에 보관하는 것이 좋습니다. 암호화된 데이터 옆에 작성된 키보다는.
인증된 암호화가 여기서 중요합니다. OWASP는 플랫폼 암호화 API, 하드웨어 백업 키 저장소가 있는 경우, 인증 모드인 AES-GCM 또는 AES-CCM과 같은 것을 권장합니다. AES-GCM 또는 AES-CCM이것들은 도난이나 변조를 감지하고 콘텐츠를 숨기는데 도움이 됩니다. OWASP는 또한 민감한 데이터를 저장하고 전송하는 동안 보호하는 것이 중요하다고 권장합니다. 또한 내부 저장소에 개인 데이터를 저장하고, 플랫폼 구현 대신 사유 암호화 알고리즘을 사용하는 것을 피하는 것이 좋습니다.OWASP 모바일 애플리케이션 보안 가이드).
실제 구현 세부 사항은 플랫폼에 따라 다릅니다. iOS는 Data Protection과 Keychain 서비스를 제공합니다. Android는 Keystore 백업 옵션과 라이브러리를 제공하여 암호화된 파일을 관리하는 데 도움이 됩니다. 데스크톱 애플리케이션은 운영 체제 자격 증명과 로컬 접근 제어에 더 많이 의존합니다. Chromium Embedded Framework 환경에서 파일을 처리하는 팀은 또한 CEF 문서 저장에 대한最佳 관행을 검토하여 시프터 자체를 넘어 저장 경계를 조사할 수 있습니다. 전송 중 암호화
best practices for CEF document storage
네트워크를 통해 요청과 응답을 보호하는 인-트랜잭션 암호화(In-transit encryption)가 있습니다. 올바르게 구성된 TLS 연결은 중간 매체가 애플리케이션 트래픽을 읽거나 수정하는 것을 방지하지만, 클라이언트가 서버를 올바르게 인증하고 백엔드가 신뢰할 수 있는 인증서를 제공할 때만 작동합니다. 인증서 확인이 비활성화된 경우, 안전하지 않은 fallback, 또는 의도치 않은 클리어텍스트 엔드포인트가 의도된 보호를 무력화할 수 있습니다.
인증서 핑핑은 선택된 모바일 시나리오에서 인증서 연산을 제어하는 팀이 회복 계획을 갖고 인증서 회전을 위한 계획을 갖고 있을 때 추가적인 검증 layer를 제공할 수 있습니다. 그러나 올바른 TLS 대신에 인증서 핑핑은 올바른 TLS를 대체하지 않으며 잘못된 핑핑은 합법적인 사용자를 차단할 수 있습니다. Capgo를 사용하는 팀은 Capacitor를 검토할 수 있습니다. SSL 핫링킹을 위한 Capacitor 앱 애플리케이션의 요구 사항에 맞는지 여부를 결정하기 전에 운영상의 트레이드 오프가 적합한지 여부를 결정합니다.
데이터베이스는 잃어버린 장치에서 복사된 경우 전송 보안이 보호하지 못합니다. 저장 장치 암호화는 위조된 연결을 통해 제출된 암호가 보호되지 않습니다. 양쪽 경로를 설계한 다음 평문이 나타나는 지점을 테스트하세요. 이에는 로그, 스크린샷, 임시 파일, 충돌 보고서, 클립보드 콘텐츠 및 동기화 큐가 포함됩니다.
앱 내 Code 보호, 데이터, 및 비밀을 보호하십시오.
팀들은 종종 "암호화," "가리기," 및 "강화"라는 단어를 같은 제어를 설명하는 것으로 사용한다. 그러나 그들은 아니다. 각 단어는 다른 공격자 동작을 다루고, 그들을 혼동하는 것은 잘못된 자신감을 부여한다.
암호화 및 압축 code를 더 읽기 어려운 것으로 만들 수 있습니다. 그들은 애플리케이션 또는 비즈니스 로직을 이해하는 데 필요한 비용을 높일 수 있지만, API 키가 자바스크립트 번들을 통해, 서명 인증서가 아카이브에, 또는 예측 가능한 함수에 의해 재구성된 값은 여전히 추출될 수 있습니다. Hermes 바이트코드 및 Electron 아카이브는 소스 파일보다 더 편리하게 검사할 수 있지만, 패키징은 비밀을 보호하는 것과 다릅니다. asar 소스 파일보다 아카이브가 더 편리하게 검사할 수 있지만, 패키징은 비밀을 보호하는 것과 다릅니다.
데이터 암호화 사용자 콘텐츠 및 로컬 인증서를 저장한 동안 보호합니다. 플랫폼 암호화 API 및 Keychain, Keystore, Secure Enclave, StrongBox, 또는 운영 체제에서 제공하는 등価시스템에서 키를 보유해야 합니다. OWASP의 암호화 테스트 지침은 소스 code에 패스워드나 키를 넣지 말라고 경고하고, 클라이언트에 남아 있는 비밀을 추출할 수 있음을 강조합니다.OWASP MASTG 암호화 테스트).
런타임 보호 탐파밍 또는 자동화된 악용의 가능성을 높이는 조건을 찾습니다. Jailbreak 및 root 신호, 디버거 감지, 애플리케이션 무결성 검사, attestation, 및 인증서 검증은 공격을 더 어려운 것으로 만들거나 응답 신호를 제공할 수 있습니다. 그러나 신뢰할 수 있는 장치를 만들지는 않습니다. 결정된 공격자는 검사를 수정할 수 있고, 합법적인 사용자는 가정 규칙을 트리거할 수 있습니다.
| 보호 층 | 보호하는 것 | 보호하지 않는 것 |
|---|---|---|
| Code 암호화 | 애플리케이션 로직의 읽기 및 비공식적인 복제 | 애플리케이션이 접근할 수 있는 비밀의 추출 |
| 데이터 암호화 | 선택한 저장된 데이터의 비밀성과 무결성 | 유효한 해독 후 평문 노출 |
| 런타임 보호 | 일부 조작, 디버깅 및 자동 악용 | 런타임을 제어하는 숙련된 공격자 |
안전한 설계는 서버에 고가치 비밀을 유지하고 클라이언트에 좁은 범위의 자격 증명만 제공하며 offline 접근이 필요한 데이터만 암호화합니다. 토큰 저장은 만료, 취소, 갱신 동작 및 플랫폼 결합에 대한 검토가 필요합니다. 모바일 개발자에게 유용한 보안 토큰 저장 지침 이 지침은 개발자가 결정한 요구 사항으로 구현을 변환하는 데 도움이 됩니다.
간단한 접근법은 비밀의 생애주기보다는 비밀의 외모를 보호하기 때문에 실패합니다. code의 값을 XOR하는 것, 키를 여러 파일에 분산하는 것, 또는 JavaScript 미니파이징에 의존하는 것은 애플리케이션이 값의 재구성과 사용을 위해 다시 생성해야 한다는 사실을 변경하지 않습니다.
iOS, Android, Capacitor, 및 Electron 플랫폼에 대한 고려사항
다양한 런타임에서 암호화 설계는 서로 다른 키 저장소, API, 격리 경계, 복구 메커니즘을 노출하기 때문에 다르게 동작합니다. 다중 플랫폼 추상화는 애플리케이션 code를 단순화할 수 있지만, 그 차이를 지우지는 못합니다.
자연스러운 모바일 플랫폼
iOS에서 Keychain은 보호된 자격 증명 저장소를 제공합니다. Secure Enclave 주 애플리케이션 프로세서에서 분리된 키 연산을 제공할 수 있습니다. 애플리케이션은 사용자 경험 요구 사항에 맞는 접근 제어를 선택해야 하며, 데이터가 장치 인증 후에만 사용되거나 사용자가 인증한 후에만 사용되도록 해야 합니다.
Android Keystore는 지원되는 장치에서 하드웨어 백업 경로를 제공하고, StrongBox 강화된 격리 환경을 제공할 수 있습니다. Android 팀은 장치 기능, 백업 동작, 인증 요구 사항, 진술 신호를 고려해야 합니다. 하드웨어 지원은 균일하지 않기 때문에, 애플리케이션은 동일한 보호를 제공하는 장치가 항상 존재한다고 가정하지 말고, 대체 정책을 정의해야 합니다.
다중 플랫폼 셸
Capacitor 애플리케이션은 웹 code와 네이티브 플랫폼 기능을 연결합니다. 이 연결은 보안 경계이며, 단순한 편의层만은 아닙니다. localStorage, IndexedDB, 일반 웹 설정이 암호화된 비밀 저장소로 간주되지 않습니다. 팀은 네이티브 스토리지 플러그인 또는 플랫폼의 보호된 키 시설을 사용하는 네이티브 모듈을 구현해야 합니다.
Electron은 다른 위협 모델을 가지고 있습니다. 렌더러는 웹 콘텐츠를 처리하며 메인 프로세스는 더 광범위한 권한을 가지고 있으므로 sensitive한 작업은 노출된 렌더러에서 유지해야합니다. Electron의 safeStorage can 운영 체제 자격 증명 보호를 사용할 수 있지만 결과적인 보안은 호스트 운영 체제, 사용자 계정, 데스크톱 구성 및 프로세스 격리에 달려 있습니다. 키는 자동으로 하드웨어 격리되지 않습니다. 모바일 플랫폼이 보호된 키를 격리하는 것과 같은 방식으로.
| Platform | Key Storage | 암호화 API | 기본 위협 모델 |
|---|---|---|---|
| iOS | Keychain 및, 지원되는 경우 Secure Enclave | Apple 플랫폼 암호화 및 Data Protection | 장치와 앱은 분리되지만 compromized된 장치 또는 런타임이 사용을 관찰할 수 있습니다 |
| Android | Keystore 및, 지원되는 경우 StrongBox | 안드로이드 플랫폼 암호화 및 Jetpack 보안 구성 요소 | 장치에 따라 하드웨어 및 소프트웨어 기능이 다릅니다 |
| Capacitor | Native storage selected through plugins or custom bridge code | 웹 API와 네이티브 플랫폼 API | 웹 자산은 네이티브 셸 내에서 실행되며 보안 스토리지 자동으로 상속되지 않습니다 |
| Electron | OS 자격 증명 시설을 통해 API safeStorage |
Node 및 Chromium 호환 애플리케이션 API | 렌더러 노출 및 호스트 레벨 접근이 주요 관심사입니다 |
팀은 대상에 따라 행동을 문서화해야 하며 제품을 "모든 플랫폼에서 암호화"라고 설명하지 않아야 합니다. 플랫폼 차이점에 대한 Capgo의 접근 방식 Capacitor 플랫폼 차이점에 대한 접근법 platform-specific한 결정은 bridge에서 보이도록 해야합니다.
Key Management and the Limits of Client-Side Secrecy
암호화는 키 관리가 키를 보호할 때만 데이터를 보호합니다. 유용한 라이프 사이클에는 5 단계가 있습니다. 생성, 배포, 저장, 회전, 취소. 각 단계는 다른 실패 모드를 생성합니다.
trusted 플랫폼 또는 서버 암호화 API를 사용하여 키를 생성하고, 인증된 프로토콜을 통해 배포하고, 보호된 플랫폼 시설에서 저장하고, 정책, 위험, 암호화 요구 사항에 따라 회전하고, 서버가 제어하는 인증을 통해 취소합니다.
이러한 작업에서 클라이언트는 인프라보다 약합니다. 사용자가 장치를 제어하고 애플리케이션 상태를 잠재적으로 검사할 수 있기 때문입니다. 클라이언트가 보유한 키는 오프라인 데이터를 보호하는 사용자로 부터 암호화된 패스프레이즈를 사용하는 경우에만 의미가 있습니다. 제품이 회복 및 사용성의 결과를 수용한다면. 그러나 API 토큰이 광범위한 백엔드 접근 권한을 부여하는 경우에는 그다지 의미가 없습니다. 공격자가 토큰을 추출하면, 로컬 데이터베이스에 대한 암호화가 토큰이 원격으로 할 수 있는 것을 제한하지 않습니다.
데이터 암호화 키와 마스터 키를 분리하는velope 암호화는 데이터 암호화 키를 사용하여 지역 객체를 암호화하고, 서버 측 키 관리 서비스 또는 HSM 백업 시스템이 wrapping 키를 보호할 수 있습니다.远程 키 릴리스 디자인은 인증된 장치, 사용자, 정책 결정 또는 attestation 신호가 필요하기 전에 암호화에 필요한 자료를 릴리스할 수 있습니다.이 패턴은 손상된 클라이언트를 안전하게 만들지 않지만 장치에 영구적으로 존재하는 권한의 양을 줄입니다.
OWASP는 개인 식별 정보, 암호화 자료, 비밀, API 키를 포함한 지역敏감적 데이터를 식별합니다. 또한 암호화와 생명 주기 제어를 연결합니다. 암호화된 자료를 안전하게 저장하고, 키를 회전하고, 사용 후 0화하는 등.
높은 가치의 비밀을 팀이 관리하는 시스템에서 유지하고 클라이언트에게 현재 작업을 위해 필요한 최소한의 권한만 부여합니다.
릴리스 시스템에 대한 키 관리는 업데이트에 대한 서명과 배포에도 적용됩니다. 팀은谁가 버ंडल을 서명할 수 있는지, 서명 자격 증명이 어디에 있는지, 접근이 감사되는지, 손상된 서명 자격 증명이 대체되는지 정의해야합니다. 업데이트를 위한 OTA 보안을 위한 키 관리에 대한 지침 업데이트 생명 주기와 애플리케이션 암호화를 연결하는 데 도움이 될 수 있습니다.
규제 및 준수 요구 사항
법적 팀은 일반적으로 '앱이 암호화를 사용한다'는 statement만으로 충분한 증거로 받아들이지 않는다. 그들은 어떤 데이터가 보호되는지, 활성화된 알고리즘 및 프로토콜, 키를 관리하는 사람, 접근을 제한하는 방법, 조직이 구성 변경 감지를 어떻게 감지하는지에 대한 정보를 요청한다.
GDPR 32조는 암호화를 위험을 줄이는 적절한 기술적 조치로 취급하며, 유럽 연합의 GDPR 텍스트에 반영되어 있다. 의무는 위험에 기반을 두고 있으므로 조직은 여전히 개인 데이터와 처리 환경의 성질에 따라 안전장치를 연결해야 한다. 의료 정보, 신분 데이터 또는 금융 기록을 처리하는 모바일 앱은 지역 저장, 전송, 접근 및 사고 대응에 대한 설명이 필요하다.
HIPAA의 보안 규칙은 전자 보호 건강 정보에 대한 암호화를 주소할 수 있는 보안 대안으로 대신 취급한다. 따라서 보호된 엔티티 또는 비즈니스 협력자는 암호화를 합리적이고 적절한지 여부를 평가하고, 결정서를 작성하고, 암호화를 구현하지 않는 경우 대안적 조치를 적용해야 한다. HHS 보안 규칙 지침은 통치적인 맥락을 제공한다.
PCI DSS는 저장된 카드 홀더 데이터를 오픈 네트워크를 통해 전송하는 것을 분리한다. 팀은 암호화 결정이 적용되는 요구 사항에 매핑하고, 결제 데이터를 필요 이상으로 저장하지 않도록 해야 한다. PCI 보안 표준 council 도서관은 현재의 문구와 범위 확인을 위한 적절한 장소이다.
SOC 2 검증자는 제어가 작동하는 증거에 초점을 맞추고 있습니다. 그 증거는 키 관리 정책, TLS 구성, 암호화 목록, 접근 로그, 변경 승인, 사건 기록, 테스트 결과 및 서명된 릴리스가 의도한 프로세스를 따르는 증거가 포함될 수 있습니다. 문서화된 제어가 모니터링되지 않으면 효과적인 작동을 보여주지 못할 수 있습니다.
공통된 주제는 증명 가능성입니다. 앱 암호화를 구현하는 동안 증거 경로를 만들지 마십시오. 감사 시 주말에만 하십시오.
일반적인 실수와 강화된 최선의 방법
대부분의 암호화 실패는 평범한 엔지니어링 결정으로 시작됩니다. 개발자는 시작 시 토큰이 필요합니다. 팀은 오프라인 검색이 빠르게 느껴지도록 하려는 것입니다. 또는 릴리스 프로세스에 빠른 방법으로 핫픽스를 배포하는 것이 필요합니다. 위험이 발생할 때는 단축된 방법이 신뢰 모델의 영구적인 부분이 됩니다.
최근 모바일 위험 연구에서 60% 이상의 평가된 앱이 sensitive 데이터에 대한 보안이 취약하거나 업데이트되지 않은 암호화를 사용했다고 보고되었습니다.그리고 약 1/3은 초기화 벡터를 재사용했습니다. 그리고 20% 사용하는 고정된 정적 값그것은 발견이 질문을 “앱이 암호화하는가?”에서 “실제 사용하도록 implementation이 비밀성과 무결성을 보장할 수 있는가?”로 바꾸었다.SC World 모바일 앱 위험에 대한 보고서)
| 일반적인 실수 | 강화된 실천 |
|---|---|
| API 키 또는 암호화 키를 소스, 바이트코드 또는 패키지에 고정하는 것 | 고가치 인증서를 서버 측에서 유지하고 장치 범위에 대한 물리적 저장소에서 보호된 플랫폼 저장소를 사용하여 |
| SQLite 데이터베이스를 암호화하는 동안 평문 캐시, 내보내기, 로그 또는 백업을 남겨두는 것 | Sensitive 데이터의 모든 복사본을 목록하고 임시 항목에 동일한 저장 정책을 적용하는 것 |
| 일반적인 웹 저장소에 리프레시 토큰을 저장하는 것 | 플랫폼 백업된 인증서 저장소, 토큰 범위 좁히고 서버 측에서 취소하는 것 |
| 사용자 정의 암호화 또는 키 오버클로킹을 작성하는 것 | 인증된 플랫폼 API 및 인증된 암호화 모드를 사용하십시오. |
| 인증서 검증을 비활성화하여 연결성 문제를 해결하십시오. | TLS를 올바르게 구성한 후 테스트된 복구 프로세스를 통해 핌닝을 평가하십시오. |
| 민식화를 비밀보호로 간주하십시오. | 클라이언트 code에서 비밀을 제거하고 역공학 비용을 높이기 위해 오버스케이프만 사용하십시오. |
| 앱完整성 검사 및 신뢰 신호를 생략하십시오. | 적절한 경우 릴리스 식별성을 검증하고 신호를 통해 접근을 조정하거나 검토를 트리거하십시오. |
| unsigned 또는 약한 제어된 업데이트를 허용하십시오. | 릴리스 아티팩트에 서명하고 서명 인증서를 보호하고 업데이트 결과를 모니터링하십시오. |
스파이웨어 크루가 시그널 및 왓츠앱 계정에 대한 위장 애플리케이션을 사용하여 전화 아래에 있는 것을 악용하는 것으로 위협 보고서가 설명했습니다. 동일한 보고서에서 모바일 위협 평가를 인용했습니다. 2025년 1분기 동안 2024년 1분기와 비교하여 안드로이드 스마트폰 공격이 29% 증가했습니다. (Register의 CISA와 관련된 보도. 암호화가 실패한 것이 아니다. 공격자가 선택하는 장치, 계정, 세션, 또는 업데이트 경로가 암호화된 ciphertext를 우회할 수 있는 layer를 bypass하기 때문이다.
CI에서 알려진 비밀 패턴을 거부하고, 사용자 지정 암호화 code를 플래그로 표시하고, 서명 단계를 검증하고, 패키지 내용을 검사하고, 저장 또는 전송 설정이 변경될 때 보안 검토를 요구하여 자동화된 릴리스 규칙으로 각 강화된 관행을 변환하라.
모든 암호화 계획을 통합하는 방법
암호화 계획은 엔지니어링 계약처럼 읽혀야 한다. 앱이 보호하는 것을 설명하고, 키가 어디에 있는지, 평문이 어떤 구성 요소에 보일 수 있는지, 팀이 각 릴리스 후에 제어가 활성화되는지 증명하는 것을 설명해야 한다.
시작하라 데이터 분류.敏감도와 보존 필요에 따라 레코드, 토큰, 문서, 로그, 캐시, 백업, 및 분석 필드를 표시하라. 장치에 도달하지 않는 데이터는 장치 저장소 설계가 필요하지 않다.
그 다음 저장 및 전송 결정을 문서화하라:
- 휴면 상태: 인증된 암호화, 플랫폼 관리 키 저장소, 보호된 파일 위치, 백업 동작, 삭제 또는 zeroization 처리를 선택하라.
- 수송 중: TLS 구성, 인증서 검증, 엔드포인트 정책, 및 위협 모델에 따라 pinning이 적절한지 정의하라.
- 키 보관: 기록 생성, 접근, 배포, 회전, 취소, 복구 및緊急 대체 절차.
- Code 및 런타임 제어: 어떤 암호화, 무결성 검사, 진술, 디버거 감지 및 sensitive-screen 보호가 기여하는지 결정하십시오.
- 감사 증거: 구성 요소 목록, 접근 로그, 릴리스 승인, 테스트 결과, 사고 기록 및 예외를 캡처하십시오.
순서는 중요합니다. 데이터 분류는 보호해야 하는 항목을 결정합니다. 이 결정은 저장소 및 키 보관을 형성합니다. 신뢰할 수 있는 서비스와 클라이언트 사이의 경로를 보존하기 위해 수송 및 업데이트 제어를 사용합니다. Capacitor 및 Electron 팀은 각 목표에 대해 이 검토를 반복해야 합니다. native iOS 키 저장소, Android 하드웨어 백업 옵션, 브라우저 저장소 API, 데스크톱 자격 증명 시설은 동일한 보장을 제공하지 않습니다.
업데이트 채널은 이 계획 내에 있어야 하며, 이 후에 있어서는 안 됩니다. 서명된 릴리스는 code 무결성을 보존할 수 있으며, 제어된 대상 지정, 롤백 보호 및 릴리스 관찰성은 팀이 취약한 빌드 또는 구성이 사용자에게 도달했을 때 응답할 수 있도록 도와줍니다. 앱이 오프라인 데이터를 추가하거나 저장소 플러그인을 변경하거나 새로운 백엔드 권한을 도입하거나 업데이트가 서명되고 전달되는 방법을 변경할 때마다 이 계획을 검토하십시오.
Capgo는 CapacitorJS 및 Electron 애플리케이션에 대해 서명된 라이브 업데이트를 제공하고 자바스크립트 code 및 자산에 대한 암호화된 번들 지원, 제어된 릴리스 채널, 롤백 보호 및 장치별 업데이트 관찰성을 제공합니다. 방문하여 Capgo 업데이트 경로를 통해 앱 암호화 및 릴리스 관리 계획을 지원하는지 평가하세요.
