[ 논문 스터디 ] 안드로이드 애플리케이션의 본인인증 키 관리 안정성 연구

해당 논문은 민간 인증 서비스 중 하나인 카카오 지갑 서비스의 인증 과정 및 키 관리 방법에 대해 분석한 논문임

링크 : https://www-dbpia-co-kr.libproxy.swu.ac.kr/pdf/pdfView.do?nodeId=NODE11224563 

안드로이드 애플리케이션의 본인인증 키 관리 안정성 연구.pdf

0.43MB

---

애플리케이션 본인인증 서비스 : 애플리케이션에서 인터넷 뱅킹, 백신 예약 등을 위해 본인을 인증하는 서비스

현재의 인증 서비스는 공공기관이 지원하는 공동인증서 / 민간 기업들에서 지원하는 민간 본인인증으로 분류됨.

(홈택스 등의 민감한 요청에서는 공공 인증서만을 지원했으나 전자서명법 개정안 시행 이후 민간 본인인증도 활용함)

---

분석 환경 구성

인증 과정 분석 : 카카오톡 v9.7.2

모바일 기기 : AOSP 커널 탑재한 Google Pixel 4를 루팅

애플리케이션 디컴파일 & 역공학 : Frida v15.1.17

인증 사례 : 카카오 간편 인증을 통한 홈택스 로그인

 

인증 과정에서의 동적 분석 및 패킷 감청을 위해서는 애플리케이션에서 기능하는 각종 보안 기법에 대한 우회가 필요

카카오 지갑 서비스에는 Rooting 탐지, SSL Pinning의 보안 기법이 적용되어 있음

---

Rooting

위키피디아

모바일 기기에서 구동되는 안드로이드 운영 체제 상에서 최상위 권한(루트 권한)을 얻음으로
해당 기기의 생산자 또는 판매자 측에서 걸어 놓은 제약을 해제하는 행위를 가리키는 말

 

해당 기기의 사용자들은 판매자 측에서 공식 제공하는 버전보다 더 높은 버전의 안드로이드나
사용자들이 임의로 개조한 안드로이드를 설치 및 구동할 수 있다.

 

루팅 검사 시 Open되는 파일 - 루팅 탐지 과정에서 libc의 open 함수가 실행되는 파일들.

카카오톡은 루팅된 장비에서도 동작하나 카카오 지갑과 같은 민감한 서비스에서는 루팅 탐지를 통해 사용자를 보호한다

따라서 인증 과정을 진행하기 위해서는 루팅 우회가 필요(루팅에 사용되는 파일 여부를 확인해서 수정한다)

 

위의 사진을 확인해 보면 su, magisk등의 루팅 바이너리 및 default.prop과 같은 기기 설정 정보를 읽음을 확인 가능

이 경우, 함수 호출 스택의 상단에서 검사 함수를 찾은 후 해당 함수를 코드 주입 프레임워크인 Frida를 통해 변조하여 우회 가능

---

SSL Pinning

통신 주체 간 암호화 채널을 구축할 때, 클라이언트 측에서 고정된 서버 인증서만 사용하도록 제한하는 것을 말한다.

- TLS 프로토콜을 통해 암호화 채널을 구축하기 전에 개입하는 중간자 공격에 대해 안전

- 인증 과정의 패킷 감청을 위해서는 신뢰할 수 있는 저장소를 무시하고 고정된 인증서만을 사용하는 SSL Pinning에 대한 우회 필요

 

카카오톡 인증서 검사 프로세스

카카오톡의 경우, 인증서 유효성 검사 후 고정된 인증서인지 검사하는 2단계 검사로 구현했음이 확인됨

유효성 검사의 경우 Java Security의 SSL Context 생성자를 변조하여 고정된 인증서 검사의 경우

Certificate Pinner 객체의 check 함수를 변조해서 각각 우회할 수 있었음

---

인증 과정 및 키 관리

인증 기관으로부터 요청받은 서버는 Task를 생성하여 클라이언트에게 전달

Task를 수신한 클라이언트는 FIDO 인증 후 자신의 개인키를 이용하여 서명 -> 서버에 전송

서버는 수신받은 서명된 Task를 클라이언트의 공개키를 통해 확인함

서버는 확인한 결과를 인증 기관에 전송하여 인증을 완료

 

따라서 클라이언트의 비밀키 접근은 Task에 서명할 때 이루어짐

카카오톡은 애플리케이션의 XML 파일 중 하나에 서명용 비밀키와 초기화 벡터를 암호화하여 보관하며,

비밀키의 복호화 과정은 서명 함수의 호출부터 동적 분석을 통해 확인할 수 있었다.

 

데이터 서명 과정

서버로부터 수신한 password와 송신했던 pin, 구해진 *salt를 이용하여 키를 생성

구해진 1차 복호화 된 비밀키 PK를 해당 키로 하여 2차 복호화를 수행 = 최종 키 PKF

구해진 PKF와 서버로부터 받은 초기화 벡터 iv는 데이터 서명에 사용됨

(PK, salt는 임시로 생성되는 1차 복호화된 임시 바이트의 배열)

 

*salt : 양념처럼 원문에 가미하여 암호문을 다른 값으로 만드는 것

PK(Private Key), salt 생성 과정

XML 파일에 저장된 PK', salt'는 PK, salt가 암호화 된 값들이다.

암호화는 1회 복호화된 SK(대칭키), IV(초기화 벡터)를 통해 복호화된다.

SK, IV는 각각 저장된 값 SK', IV'로 부터 복호화되며, 복호화에 쓰이는 키는 생성 시

Android KeyPairGenerator에 고정된 값을 받아 생성, 후에 Android KeyStore에 저장되어 사용된다.

 

---

결론

인증에 사용되는 키들은 모두 암호화되어 애플리케이션 내부저장소의 XML 파일에 저장되고,

해당 암호화 및 복호화 키는 Android KeyStore에 저장된 키로부터 시작된다는 것이 확인됨.

 

Android KeyStore는 각종 보안 조치로써 키의 추출을 차단하기 위해,
신뢰할 수 있는 실행 환경(TEE)이나 하드웨어 보안 모듈을 적용하고 있다.

 

but 공격자가 장비 잠금 PIN의 탈취 등 특정 상황에서 비밀키의 추출이 가능함이 확인되었다.
또한 분석 환경 구성 과정에서 SSL Pinning이나 Rooting과 같은 보안 기법들이
코드 주입을 통한 프로그램 변조를 통해 우회됨이 확인되었다.

 

따라서, Android KeyStore의 취약점을 이용하는 실제 본인인증 키 추출 및 공격 시나리오 구현,
코드 주입 방지 기법 및 코드 난독화 적용을 통한 안정성 강화 등이 향후 연구될 과제일 것.