콘텐츠로 바로가기

Android Security & Permissions Physics

Android 보안 및 Permissions 메커니즘의 정의, 범위, 선행 지식, 학습 주제, 참고 근거를 정리한 CS&E 학습 노드입니다.

목차 보기21

1. Overview

안드로이드 보안 및 권한 역학(Android Security & Permissions Physics)은 악성 앱이 사용자의 민감한 데이터(카메라, 연락처)나 하드웨어를 장악하지 못하도록 방어하는 운영체제 차원의 샌드박스(Sandbox) 통제 물리와 암호화 공학을 다룹니다.

과거 안드로이드는 설치 시점에 모든 권한을 묻는 허술한 구조였으나, 현대 시스템은 앱이 기능을 요청하는 찰나의 순간에만(런타임) 유저에게 권한을 묻고, 언제든 박탈해버리는 극도의 제로 트러스트(Zero Trust) 구조로 진화했습니다. 학습자는 각 앱이 완전히 고립된 리눅스 사용자(UID)로 실행되는 샌드박스의 근간을 이해하고, 암호화 키스토어(Keystore)를 이용해 메모리 밖으로 키(Key)가 유출되지 않는 물리적 보안 계층을 설계합니다. 나아가 리버스 엔지니어링을 방어하는 난독화(Proguard/R8)와 외부 앱 통신의 무결성을 보장하는 컴포넌트 보안 방어막을 구축합니다.

2. Scope & Boundaries

In-Scope

  • 권한 승인 시스템: Runtime Permissions(런타임 권한), Scope Storage(범위 지정 저장소), Manifest 보안.
  • 안드로이드 샌드박스: 리눅스 UID/GID 기반 프로세스 고립, 파일 시스템 캡슐화.
  • 데이터 암호화: Android Keystore 시스템, 하드웨어 기반 암호화(TEE/SE), Biometrics(생체 인증).
  • 역공학 방어: R8/Proguard 난독화, 인증서 서명 무결성(Signature), 네트워크 보안 구성(Network Security Config).

Out-of-Scope

  • OAuth 및 일반 웹 백엔드 인증: 토큰을 발급받아 서버로 로그인하는 비즈니스 로직 ightarrow ightarrow 08-05. Identity & Security Engineering 영역으로 위임.
  • iOS Sandbox 파일 시스템: 애플의 고유 디렉토리(Documents, Caches) 구조 ightarrow ightarrow 13-01-04. App Lifecycle & Sandbox Physics 영역으로 위임.

Boundaries

  • Android Security vs General Security (10-01): 일반 보안(10-01)이 AES, RSA 등 암호학 알고리즘 자체의 수학적 난제를 다룬다면, 13-02-04는 그 암호 키를 "안드로이드 스마트폰의 하드웨어 보안 칩(Keystore) 안에 어떻게 가두어 루팅된 기기에서도 빼갈 수 없게 만들 것인가?"에 집중하는 OS 환경적 보안입니다.

3. Counterexample

  • 권한 무시 설계 (Permission Denial Fallacy): 앱 실행 시 무턱대고 카메라 권한을 요청한 뒤, 유저가 '거부(Deny)'를 누르면 크래시(Crash)를 내며 앱이 종료되는 낡은 설계. 런타임 권한 시스템에서 유저는 권한을 언제든 거부할 수 있고 심지어 앱을 쓰던 중에 세팅에서 박탈할 수도 있습니다. 코드는 항상 권한이 없음을 기본 상태(Default)로 가정하고 예외 우회(Graceful Degradation) UI를 띄워야 합니다.
  • 하드코딩 키 유출 (Hardcoded Key Fallacy): 서버와 통신하는 API Key나 암호화 패스워드를 자바/코틀린 소스코드 문자열(String)에 그대로 박아두는 치명적 무지. APK 파일은 압축 파일에 불과하여 누구나 디컴파일(Decompile)을 통해 소스코드를 1초 만에 뜯어볼 수 있습니다. 민감한 키는 R8 난독화로도 방어가 불가능하며, Keystore나 NDK(C++ 레벨)로 깊숙이 은닉해야 합니다.

4. Prerequisites

  • 운영체제 보안 모델 (Basic): 리눅스의 파일 권한(chmod)과 유저 격리(UID) 모델을 이해해야 안드로이드 샌드박스의 밑바탕을 알 수 있습니다. (03-03. OS Security)
  • 응용 암호학 기초 (Recommended): 대칭키/비대칭키의 개념을 알아야 Keystore 하드웨어의 암복호화 플로우를 이해할 수 있습니다. (10-01. Cryptography)

5. Learning Map

Sequence Core Cluster Objective & Description Evidence (BoK)
1 Sandbox & Manifest 안드로이드의 각 앱이 절대 서로의 밥그릇을 침범할 수 없도록 격리시키는 리눅스 기반 보안 감옥을 분해합니다. Primary
2 Runtime Permissions 유저가 원할 때만 카메라/마이크를 쥐어주고 언제든 빼앗아버리는 동적 권한(Zero Trust)의 방어 코드를 짭니다. Industry
3 Keystore & Crypto 스마트폰의 하드웨어 보안 칩 안에 암호키를 가두어, 해커가 폰을 훔쳐 루팅(Rooting)하더라도 키를 빼내지 못하게 물리적으로 막습니다. Primary
4 Obfuscation & Integrity 코드를 배포하기 전, 해커가 디컴파일러로 소스를 훔쳐보지 못하게 변수명과 흐름을 완전히 갈아엎는 난독화(R8)를 적용합니다. Industry

6. Learning Topics

Basic

Core Topic 01: 샌드박스와 권한(Permission) 체계 물리

  • Why to Learn: 내 앱이 악성 앱으로부터 공격받는 것을 막고, 역으로 내 앱이 유저의 데이터를 허락 없이 훔치지 못하는 통제망을 이해하기 위함입니다.
  • What to Learn: Linux UID Sandbox, Manifest Permissions, Runtime Permissions, Scoped Storage(범위 지정 저장소).
  • How to Learn: 앱 A와 앱 B가 서로 다른 UID(유저 ID)를 배정받아 OS 차원에서 파일 폴더 접근이 완벽히 차단된 감옥 구조를 확인하고, 외부 폴더(사진첩)를 열기 위해 런타임에 유저에게 다이어로그를 띄워 임시 통행증을 발급받는 흐름을 추적합니다.
  • Implement: 갤러리 앱에서 사진을 가져올 때 기기 전체 저장소 권한을 요구하는 대신, Photo PickerScoped Storage API를 이용해 딱 선택한 사진 1장만 읽어오는 최소 권한 원칙(Least Privilege) 코드 작성.

Core Topic 02: 인텐트(Intent) 보안과 Exported 제약

  • Why to Learn: 앱 내부에서만 쓰려고 만든 비밀 화면(결제 승인 창 등)을 다른 해킹 앱이 마음대로 띄워버리는 치명적 결함을 막기 위해서입니다.
  • What to Learn: android:exported, PendingIntent 취약점, Implicit Intent 가로채기 방어.
  • How to Learn: 매니페스트(Manifest) 파일에서 특정 Activity의 exported="true" 속성을 열어두었을 때, 완전히 남남인 외부 앱이 딥링크(Deeplink)를 통해 로그인 과정을 건너뛰고 결제창으로 직행해버리는 보안 뚫림(Exploit)을 시뮬레이션해 봅니다.
  • Implement: 앱 외부로 내보낼 필요가 없는 모든 브로드캐스트 리시버와 액티비티를 exported="false"로 명시하고, 외부 통신 시 서명(Signature) 레벨의 커스텀 권한을 덧씌우는 매니페스트 보안 룰 작성.

Core Topic 03: 하드웨어 암호화와 Android Keystore

  • Why to Learn: 로그인 토큰이나 비밀번호를 일반 파일 시스템(SharedPreferences)에 저장해두면 루팅된 기기에서 100% 털리기 때문입니다.
  • What to Learn: Android Keystore, TEE(Trusted Execution Environment), 암호화/복호화(AES/RSA), Biometrics(생체 인증).
  • How to Learn: 비밀번호를 암호화하기 위한 '마스터 키'를 소프트웨어(메모리)에 두는 대신, 하드웨어 칩(Keystore) 안에 가둬놓고 데이터만 칩으로 밀어넣어 암호화된 결과물만 받아오는 블랙박스 역학을 분석합니다.
  • Implement: KeyGenParameterSpec을 사용하여 안드로이드 하드웨어 Keystore 내부에 AES 키를 생성하고, 이 키를 이용해 유저의 액세스 토큰을 암호화한 뒤 샌드박스에 저장하는 강력한 암호화 모듈 구현.

Practical

Core Topic 04: 앱 무결성과 난독화(Obfuscation) 방어

  • Why to Learn: 경쟁사나 해커가 내 앱의 APK(설치 파일)를 다운받아 소스코드를 텍스트 파일처럼 뜯어보는 리버스 엔지니어링을 물리적으로 지연시키기 위함입니다.
  • What to Learn: R8/Proguard 난독화(Obfuscation) 및 축소(Shrinking), 네트워크 보안 구성(Network Security Config), SSL Pinning.
  • How to Learn: 난독화 없이 빌드한 APK를 jadx 같은 디컴파일러 도구로 열었을 때 login(username, password) 같은 코드가 적나라하게 보이는 충격을 체험하고, R8을 켠 후 코드가 a(b, c)처럼 파괴되어 해석이 불가능해지는 치환 논리를 관찰합니다.
  • Implement: 빌드 그레이들(build.gradle)에서 minifyEnabled true를 켜서 코드를 난독화하고, 해커가 중간자 공격(MITM)으로 서버 통신 패킷을 가로채지 못하도록 서버의 진짜 인증서 해시값만 허용하는 SSL Pinning 방어선 구축.

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
Sandbox 각 앱에 서로 다른 리눅스 유저 ID(UID)를 부여하여 다른 앱의 파일이나 메모리를 절대 들여다볼 수 없게 고립시킨 운영체제 보안 벽입니다. 기본 보안 격리 UID, Permission vs. Root Access 샌드박스가 앱 내부의 코드 버그까지 막아준다는 착각 Primary core
Runtime Permission 앱을 설치할 때 한 번에 묻지 않고, 유저가 마이크 버튼을 누르는 딱 그 찰나의 순간에만 권한을 묻고 즉각 회수할 수 있는 동적 방어 체계입니다. 권장 접근 제어 Manifest vs. Install-time Perm 한 번 승인받은 권한은 앱 삭제 전까지 영원하다는 오해 Industry Docs core
Android Keystore 앱의 암호화 키를 일반 메모리에 두지 않고 폰 내부의 하드웨어 보안 영역(TEE)에 가두어 해커의 유출을 물리적으로 막는 금고입니다. 실무 암호/저장 TEE, Encryption vs. SharedPreferences Keystore가 데이터를 암호화해서 저장해주는 DB라고 생각하는 오류(키만 보관함) Primary core
R8 / Proguard (난독화) 배포 전 컴파일 단계에서 클래스, 변수, 함수 이름을 a, b, c 등 무의미한 문자로 갈아엎어 디컴파일(역공학) 시 해석을 방해하는 기술입니다. 실무 소스 보호 Decompilation vs. Encryption 난독화하면 코드가 암호화되어 절대 못 뚫는 완벽한 방패라는 맹신 Industry core

8. References

Primary References

  • [CS2023: Security / OS] — 운영체제 샌드박스, 고립 환경, 메모리 보호 기법 및 암호화 모델.
  • [SWEBOK v3: Software Security] — 최소 권한 원칙(Least Privilege), 리버스 엔지니어링 방어 및 런타임 위협 모델링.

Secondary References

  • [Android Security Internals] — Zygote 프로세스 고립, UID 기반 파일 시스템 권한(Permissions) 맵핑 역학.
  • [Android Developer: Security Best Practices] — 인텐트(Intent) 인젝션 방어, HTTPS/SSL Pinning 및 네트워크 보안 구성.

Industry References

  • [OWASP Mobile Top 10] — 모바일 앱 취약점: Insecure Data Storage(하드코딩), Insecure Communication(MITM 방어 실패).
  • [Android Developer: Keystore System] — TEE(Trusted Execution Environment) 및 StrongBox 기반 하드웨어 바인딩 암호화 설계.

9. Final Checklist

Primary Checklist

  • 카메라나 위치 등 민감한 하드웨어 기능에 접근할 때 런타임 권한(Runtime Permission)을 요청하며, 거부당했을 때 앱이 크래시 나지 않고 우회 경로(Fallback)를 띄우는가?
  • 서버 로그인 토큰(JWT)이나 비밀번호를 일반 SharedPreferences에 생명문(Plain Text)으로 방치하지 않고, Android Keystore로 암호화하여 저장(EncryptedSharedPreferences)했는가?

Secondary Checklist

  • 외부 다른 앱에서 호출할 필요가 없는 내부용 액티비티(Activity)와 브로드캐스트 리시버에 android:exported="false"를 명시하여 딥링크 우회 해킹을 차단했는가?
  • 갤러리의 모든 사진이나 기기 전체 파일을 훑어보는 권한(READ_EXTERNAL_STORAGE) 대신, 딱 필요한 파일 1개만 접근하는 Photo Picker나 Scoped Storage를 도입했는가?

Industry Checklist

  • 플레이 스토어 배포 전 build.gradle에서 R8(Proguard) 옵션(minifyEnabled true)을 켜서 소스코드를 난독화하고 불필요한 디버깅 코드를 깎아냈는가?
  • 중요한 서버 API 통신 시 중간자 공격(MITM) 방어를 위해, 디폴트 HTTPS 신뢰를 넘어 특정 해시값의 서버 인증서만 통과시키는 SSL Pinning(네트워크 보안 구성)을 적용했는가?

태그

Mobile App Lifecycle & System Integration

3 / 4