[안드로이드 리버싱] 안드로이드 시스템 이해 :: 보안 모델, 서명, 키스토어, apk

 

안드로이드 보안 모델과, 개발자 서명, .apk 파일 등 어떤 보안적인 요소가 적용되고 있고,

실제 배포까지 어떤 일이 발생하는지 살펴보겠습니다.

 

---

안드로이드 보안 모델

안드로이드는 기본적인 리눅스 커널 + 스마트폰에 맞는 보안 기능 구성합니다.

그 중에서 짚고 넘어가야 할 사항들을 간단히 살펴보고 넘어가겠습니다.

• UID: 앱 설치 시 고유한 UID 를 자동으로 할당해주는데, 이는 앱을 보호해주는 샌드박스 역할을 한다.
• Permission: 앱에 필요한 권한을 앱에서 요청해야 한다. (ex. 카메라, 전화 등) 이는 AndroidManifest.xml 에 작성해두고 필요할 때 권한을 요청하면 된다.
• TrustZone: 주요한 정보를 분리된 공간에 저장해두는 것. 즉, 디바이스 공간을 물리적 / 논리적 영역으로 분리하여 중요한 내용이 바로 노출되지 않도록 한다. 이렇게 보호되는 영역을 TEE (Trusted Execution Environment) 라고 한다.
• 개발자 서명: 출시, 즉 release 에는 반드시 개발자 서명이 필요하다. (단, debug 모드에서는 서명이 필요하지 않다)
• 암호학적 해시 트리를 이용하여 디바이스의 무결성을 검증한다. 암호학적 해시를 사용한다는 것은, 원본이 수정되었는지 확인하려는 것이고 이를 통해 무결성을 검증할 수 있다.
• SELinux: 강제 접근 제어를 포함한 접근 제어 보안 정책을 지원하는 리눅스 커널 보안 모듈로, 안드로이드 5.0 부터 완전히 적용되고 있다. (접근 제어 DAC, MAC, RBAC 중 MAC 에 해당) 강제 접근 제어는 "관리자"에 의해 정의된 권한까지만 사용 가능하게 한다는 것이다.

 

 

안드로이드 앱 빌드 프로세스

Android 빌드 시스템은 , 

• 앱 리소스 및 소스 코드를 컴파일
• 테스트
• 서명
• 배포할 수 있는 Android Application Package (APK) 또는 Android App Bundle (AAB) 로 패키징

 

을 합니다.

 

Android Studio 는 Gradle 을 사용하여 빌드 프로세스를 자동화하고 관리합니다.

Gradle 에서 작성한 내용은 Android Studio 와 독립적으로 작동하여 Android Studio 가 설치되지 않았어도 빌드가 가능합니다.

 

따라서 빌드 프로세스는 다음과 같이 프로젝트를 APK 나 AAB 로 변환하는 과정으로 볼 수 있습니다.

 

https://developer.android.com/studio/build

 

위 사진은 일반적인 Android 앱 빌드 프로세스를 보여줍니다.

• 1) Compiler 는 소스 코드를 DEX (Dalvik Executable) 로 변환하고, 다른 모든 것도 컴파일된 리소스로 변환한다. DEX 파일에는 Android 기기에서 실행되는 바이트 코드가 포함된다. (Dalvik 에 대한 정보는 이전 포스팅)
• 2) 출시를 위해 빌드를 준비하는 개발자는 출시 버전의 키스토어를 준비합니다.
• 3) Packager 는 DEX 파일 + 컴파일된 리소스를 결합하여 APK 또는 AAB (선택) 를 만든다.
• 4) Packager 가 키스토어를 사용해 3) 에서 만든 APK 나 AAB 에 서명한다. (출시하려면 꼭 해야함)
• 5) 최종 APK 를 생성하기 전에, Packager 는 앱을 최적화하기 위해 zipalign 도구를 사용한다.

 

이렇게 생성한 APK 파일은 바로 스마트폰에 설치할 수 있고, 출시할 수 있습니다.

(물론 배포는 정당한 앱스토어에서!)

 

 

앱 서명

앱에 서명하는 것을 통해 이 앱을 변경한 사용자를 알고, 정당한 사용자인지 확인할 수 있습니다.

즉, 제3자가 앱을 변형시키고 다시 스토어에 업로드시키는 것은 불가능하게 하려는 것인 동시에 앱에 대한 책임을 (부정 방지) 두는 것으로 이해하면 될 것입니다.

 

Google 에서는 Play 앱 서명으로 앱의 서명 키를 관리하고 보호하며, 배포할 APK 에 서명하는 데에 사용합니다.

Play 앱 서명은 2021년 8월 이전에는 선택사항이었으나, 이제는 Google Play 스토어에 업로드하려면 필수사항입니다.

Play 앱 서명은 서명 키와 업로드 키의 2가지 키를 사용합니다.

• 서명 키: 사용자의 신원 확인, 배포를 위해 APK 에 서명하는 데에 사용
• 업로드 키: 개발자가 보관하다가 앱을 Google Play 스토어에 업로드하기 위해 서명할 때 사용
  단, 새로운 업로드 키를 생성하지 않으면 앱 서명 키를 업로드 키로 사용하게 됩니다.

 

https://developer.android.com/studio/publish/app-signing

 

여기서 별도의 업로드 키를 사용하면 사건 발생 시 업로드 키 재설정을 요청할 수 있습니다.

(주의: 2021년 8월 이전에 생성한 앱 중 Play 앱 서명을 선택하지 않은 경우 앱 서명 키를 분실하면 앱을 업데이트할 수 없습니다.)

또한, 앱 서명 키와 업로드 키는 반드시 기밀로 유지하되, 각 키를 사용하여 생성한 인증서는 공유할 수 있습니다.

Play 앱 서명을 구성한 후 앱을 출시하면 Google Play에서 앱의 서명 키를 생성(기존 키를 업로드한 경우 제외)하고 관리합니다.

 

이런 키스토어를 생성하는 것은 Android Studio 에서 간단히 할 수 있습니다.

키스토어를 만들 때 필요한 것은 저장 위치, 비밀번호, 유효기간 등이 있습니다.

 

 

키스토어 구조

Android Keystore 시스템은 Android 4.0 에서 도입된 KeyChain API (https://developer.android.com/reference/android/security/KeyChain) 에서 사용됩니다. 즉, KeyChain 으로 X.509 (인증서 표준) 인증서 chain 인증을 진행하는 것으로, 루트 인증서의 유효성을 판단합니다.

키스토어는 암호화 키를 컨테이너에 저장하여 키를 추출하기 어렵게 만들면서 키를 암호화에 사용할 수 있습니다.

 

또한, 다음의 특징이 있습니다.

• 앱 프로세스가 손상된 경우 공격자가 앱 키를 사용할 수 있지만 Android 기기 외부에서 사용하기 위해 키 자료를 추출할 수는 없다.
• 키 자료를 Android 기기의 보안 하드웨어(TEE(신뢰할 수 있는 실행 환경), SE(보안 요소) 등)에 바인딩할 수 있다. 키에 이 기능을 사용하도록 설정하면 키 자료가 보안 하드웨어 외부에 노출되지 않는다. 즉, apk 에 키스토어를 두지 않아서 apk 가 노출되어도 공격자가 키를 추출할 수 없다.
• 시스템은 StrongBox Keymaster (Android 9 이상에서, 하드웨어 보안 모듈에 상주하는 Keymaster HAL 구현) 에 저장된 키를 검사할 때 TEE(신뢰할 수 있는 실행 환경) 를 사용하여 키의 무결성을 입증합니다.

 

KeyStore는 KeyPairGenerator 및 KeyGenerator 와 동일한 키 유형을 지원합니다.

• KeyGenerator 지원 알고리즘: AES, HmacSHA1, HmacSHA224, HmacSHA256, HmacSHA384, HmacSHA1
  (https://developer.android.com/training/articles/keystore?hl=ko#SupportedKeyGenerators)
• KeyPairGenerator 지원 알고리즘: EC, RSA
  (https://developer.android.com/training/articles/keystore?hl=ko#SupportedKeyPairGenerators)

 

공개키, 대칭키 암호 알고리즘을 모두 지원하는 것을 확인할 수 있습니다.

 

이런 키스토어는 그 보안성으로 인해 서명 키 뿐만 아니라, 다른 민감한 정보들을 저장하는 데에 이용하기도 합니다.

 

 

.apk 파일이란?

안드로이드 앱은 기본적으로 .apk 라는 확장자를 가지지만, 사실은 zip 형식으로 압축된 파일입니다.

소스 파일 (.class) 을 Dalvik 이 인식할 수 있도록 dex 파일로 변환 후 Packager 가 생성하는 파일로, 인증을 위한 서명도 포함되어 있습니다. 이를 스마트폰에서 실행시키면 실질적인 실행 파일인 dex 파일이 Dalvik VM 에서 작동하게 됩니다.

dex 파일의 구조는 https://source.android.com/devices/tech/dalvik/dex-format.html 에서 확인할 수 있습니다.

 

apk 내부 구조는 apk 의 압축을 풀면 확인할 수 있는데, 다음과 같이 이루어져 있습니다.

• META-INF: 서명과 관련된 정보
• lib: 라이브러리 파일 (.so)
• res: 앱 실행에 필요한 resource. 보통 아이콘 같은 파일이 포함되어 있다. (컴파일 X)
• assets: 앱 실행에 필요한 자원. res 보다 용량이 큰 동영상 같은 파일을 저장한다. (컴파일 O)
• AndroidManifest.xml: 앱의 정보를 저장하는 파일. 패키지명, 버전, 권한 정보 등이 포함되어 있다. 단, 디컴파일 없이 보면은 .xml 파일은 바이너리로 되어있어서 내용을 알아보기 힘들다.
• classes.dex: .class 파일을 bytecode 로 변환시킨 .dex 소스 파일
• resources.arsc: 리로스의 배열이라는 뜻으로, res 의 정보가 기록되어 있다.

 

https://programist.tistory.com/entry/안드로이드-앱-apk-Android-Package의-구조-분석

 

이런 구조는 직접 apk 파일을 뜯어보며 살펴보면 좋을 것이고, 이후 실제로 해보도록 하겠습니다.