들어가며
안녕하세요. Auth & Account Dev 팀의 김은찬, 김종민, 권기범, 정의엽, 허원영입니다. Auth & Account Dev 팀은 LY Corporation 그룹 서비스의 계정 및 인증과 관련된 백엔드 개발을 담당하고 있습니다.
이번 포스팅에서는 앞서 Security R&D 팀에서 소개한 기기와 앱의 무결성 보장부터 서비스 요청 보호까지: LINE의 기기 증명 서비스 - 1편에 이어 기기 증명(device attestation)을 저희 회사의 서비스에 적용한 경험과 앞으로의 개발 방 향을 소개하고자 합니다.
기기 증명 서비스 개발 과정
Auth & Account Dev 팀과 Security R&D 팀은 사용자가 더 안전하게 저희 회사의 서비스를 이용할 수 있도록 지속해서 협업해 왔습니다. 그 결과 LINE 앱에 패스워드 없이 LINE 앱에 로그인할 수 있는 기능이 도입됐으며(참고: FIDO at LINE: 패스워드 없는 세상으로의 첫 발걸음), 이번 글에서 소개할 기기 증명 서비스 역시 Security R&D 팀과의 긴밀한 협업을 통해 도입됐습니다.
기기 증명 서비스는 저희 회사의 서비스를 계정 탈취나 스패밍(spamming), 피싱(phishing), 사기 등을 목적으로 악용하는 사례가 증가하면서 이러한 서비스 남용을 방지할 수 있는 수단을 마련하고자 개발됐습니다. Security R&D 팀에서 기기 증명의 설계를 진행해 PoC(proof of concept) 구현을 완료했고, Auth & Account Dev 팀에서 그 PoC 구현체를 공유 받아 실제 서비스에 적용하기 위한 백엔드를 구현했는데요. 패스워드 없는 인증의 표준인 FIDO2 WebAuthn 객체를 사용하도록 설계된 덕분에 원활하게 구현을 완료할 수 있었습니다.
기기 증명 기능은 2023년 12월부터 LINE Android와 iOS 앱에 적용되기 시작했습니다. 안정적으로 기능을 적용하기 위해 국가별로 점진적으로 배포해서 2024년 5월에 LINE 앱을 서비스하고 있는 모든 국가를 대상으로 배포 완료했으며, 그 결과 Android와 iOS, 두 플랫폼의 차이에 따른 기기 증명 결과를 관찰할 수 있었습니다. 그 관찰 결과를 공유하겠습니다.
기기 증명 적용 - LINE Android 앱
Android 플랫폼에서 기기 증명 기능을 원활히 구현하기 위해서는 신뢰 실행 환경(trusted execution environment)과 특정 버전 이상의 Android 운영 체제가 필수인데요. Samsung, Xiaomi, vivo, OPPO 등 다양한 제조사에서 출시한 기기들은 모델별로 탑재된 하드웨어 구성 요소와 지원하는 Android 버전이 상이합니다. 이 때문에 동일 제조사 내에서도 기기 증명 기능을 지원하는 모델과 그렇지 않은 모델이 공존합니다.
기기 증명 기능 배포 후 LINE Android 앱에서 크게 다섯 가지의 실패 원인을 확인할 수 있었으며, 이를 발생 빈도순으로 나열하면 다음과 같습니다.
- 인증서 체인 검증에 실패한 경우: 증명 객체(attestation object) 내의 x.509 인증서 체인의 검증이 실패한 경우
attestationSecurityLevel값이Software로 설정된 경우: 보안 수준이 낮은 기기(하드웨어 기반의 키 저장소 제공되지 않음) 또는 에뮬레이터에서 실행되고 있는 경우- LINE 앱이 변조된 경우: LINE 앱이 변조돼 패키지 이름과 서명이 공식 LINE 앱과 다른 경우
- 기기가 루팅된 경우: 기기를 루팅해 x.509 인증서 확장의 신뢰 루트(root of trust)가 정상이 아닌 경우
- 취소된 인증서가 사용된 경우: 인증서 체인에 포함된 인증서를 개인 키 유출 등의 이유로 Google이 취소한 경우(참고: 인증서 취소 상태 목록)
각 경우를 하나씩 자세히 살펴보겠습니다.
인증서 체인 검증에 실패한 경우
증명 객체 내의 x.509 인증서 체인을 검증할 때에는 각 인증서의 서명뿐 아니라 인증서 확장에 기록된 여러 정보도 함께 확인합니다. 따라서 인증서 서명이 올바르다고 하더라도 일부 정보가 잘못돼 있다면 검증에 실패합니다.
인증서 체인 검증에 실패하는 경우는 어뷰징으로 추정되는 경우와 정상 사용자로 추정되는 경우로 나눌 수 있으며, 각 경우에서 체인 검증에 실패하는 사례는 다음과 같습니다.
- 어뷰징으로 추정되는 경우
- 인증서 서명 검증에 실패하는 경우: 인증서 체인에 포함된 인증서들의 서명이 올바르지 않은 경우
- 루트 인증서를 신뢰할 수 없는 경우: 루트 인증서가 Google이 발행하지 않은 인증서인 경우
- 정상 사용자로 추정되는 경우
- keyCertSign 비트 혹은 CA 비트가 1로 설정되지 않은 경우(참고: RFC 5280 - Basic Constraints)
- 인증서 유효 기간이 과거로 설정된 경우
- RFC 5280에 따르면 두 자리 숫자 'YY'로 표현된 연도가 50보다 크거나 같을 경우 19YY로 해석되기 때문에 인증서 발급자가 2069년을 의도해서 '69'를 입력했다고 하더라도 1969년으로 해석돼 인증서 검증에 실패
- 인증서 유효기간이 단순히 '0'으로 설정된 경우 1970년 1월 1일로 해석돼 인증서 검증에 실패
- 인증서의
Issuer가 잘못된 경우- 인증서의
Issuer값은 자신을 서명한 상위 인증서의Subject값과 일치해야 하는데 일부 인증서에서는Issuer값이 상위 인증서Subject값의 일부만 포함하고 있는 것으로 확인
- 인증서의
별도 검증 기준의 필요성
저희 팀과 Security R&D 팀에서 인증서 체인 검증에 실패하는 데이터를 검토한 결과 인증서 서명 검증 실패와 루트 인증서를 신뢰할 수 없는 경우를 제외하고는 대부분 정상 사용자로 추정됐습니다. 기기 증명의 거짓 음성을 줄이기 위해서는 정상적인 기기를 사용하는데도 증명에 실패하는 경우를 줄이는 것이 중요하므로, 정상 사용자로 추정되는 경우에는 별도 기준을 적용하기로 결정했습니다.
새로운 검증 기준을 적용하기 위해 Security R&D 팀에서는 Java의 CertPathValidator를 기반으로 별도 구현체를 만들었으며, 저희 팀에서는 정상 사용자로 추정되는데 기기 검증에 실패하는 모델들을 수집해 별도 기준을 적용해도 괜찮을지 검토했습니다. 확인된 기기 모델에는 별도 기준을, 그 외 기기 모델에는 기존 기준을 적용해 인증서 체인을 검증했고, 이를 통해 인증서 체인 검증에 실패하는 Android 기기 수를 10분의 1로 줄일 수 있었습니다.
AttestationSecurityLevel 값이 Software로 설정된 경우
이 경우와 관련해서는 1편의 잠재적으로 신뢰할 수 없는 실행 환경 탐지에 자세히 설명돼 있으니 이쪽을 참고해 주시기 바랍니다.
LINE 앱이 변조된 경우
Android의 경우 APK 파일을 디컴파일해 앱의 기능을 변경한 후 다시 컴파일할 수 있습니다. 이와 같은 방법으로 LINE 앱이 변조된 경우 AttestationApplicationId를 검증해 앱의 위변조 유무를 확인할 수 있습니다. 기기 증명을 통해 실제 서비스에서 확인한 LINE 앱 변조 케이스는 크게 두 가지였습니다.
듀얼 앱을 이용해 한 기기에 같은 앱을 여러 개 설치
Google Play에서 'Dual 앱'으로 검색하면 한 기기에 같은 앱을 여러 개 설치할 수 있게 해주는 기능의 앱들이 많이 나타납니다. 이런 앱들이 사용하는 방법 중 하나가 APK 파일의 패키지 이름을 변경해 다시 컴파일하는 것입니다. 실제로 LINE 앱의 기기 증명 기능을 통해 들어오는 데이터를 분석한 결과 10개 이상의 듀얼 앱들이 시중에서 사용되고 있는 것을 확인할 수 있었습니다.
LINE 앱을 변조해 악의적으로 이용
듀얼 앱을 통해 단순히 LINE 앱을 여러 개 설치하는 것을 넘어 LINE 앱의 작동 자체를 변경하려는 시도가 여기에 해당합니다. 악의적인 목적을 가진 사용자가 본인이 수정한 LINE 앱을 범죄 행위에 사용할 수 있기 때문에 가장 주의해야 할 유형이라고 볼 수 있는데요. 변조된 앱은 다음과 같은 위험을 초래할 수 있습니다.
- 개인 정보 유출
- 변조된 앱은 사용자의 민감한 개인 정보를 무단으로 수집하고 전송할 수 있으며, 이렇게 수집된 개인 정보는 또 다른 범죄에 이용될 수 있습니다.
- 서비스 방해
- 변조된 앱은 LINE 앱 서비스의 정상적인 작동을 방해할 수 있으며, 이는 서버 과부하나 서비스 품질 저하 등의 문제를 일으킬 수 있습니다. 이는 다른 사용자에게 불편을 초래하며, LINE 앱 서비스의 신뢰를 훼손할 수 있습니다.
변조된 앱을 사용하는 것은 LINE 앱의 서비스 약관을 위반하는 행위로 서비스 이용이 제한될 수 있으며, 특히 변조된 앱을 사용해 금융 사기, 신원 도용, 데이터 유출 등의 범죄 행위를 저지르는 경우 무거운 형사 처분을 받을 수 있습니다. 변조된 앱 사용을 방지하기 위해 꼭 Google Play나 Apple App Store와 같은 공식 경로를 통해서 LINE 앱을 설치하시기 바랍니다.
기기가 루팅된 경우
Android에서는 여러 루팅 프레임워크를 사용해 루트 권한을 획득할 수 있습니다. 루트 권한을 이용하면 앱들의 특정 메서드 호출을 가로챈 후 원하는 코드를 실행해 앱을 변조하지 않고도 원하는 작동을 실행할 수 있는데요. 1편의 잠재적으로 신뢰할 수 없는 실행 환경 탐지에서 설명한 아래 항목에 해당합니다.
deviceLocked값이False로 설정된 경우verifiedBootState값이Verified로 설정되지 않은 경우
취소된 인증서가 사용된 경우
인증서의 개인 키가 유출되는 등의 이유로 Google에서 취소한 인증서가 증명 객체의 인증서 체인에 사용된 경우입니다. 이 경우는 공격자가 유출된 인증서 개인 키를 가지고 인증서 체인을 만들었을 수 있기 때문에 해당 인증서 체인의 내용을 신뢰할 수 없습니다. 자세한 내용은 1편의 증명 키 유출 대책 부분을 참고하시기 바랍니다.
기기 증명 적용 - LINE iOS 앱
Apple은 iOS와 iPhone을 개발할 때 일관된 방향을 유지해 대부분의 기능이 모든 iPhone 모델에서 호환되도록 설계하며, 정기적으로 iOS를 업데이트해 대부분의 iPhone 모델에서 최신 iOS 버전이 작동하도록 지원합니다. 그 덕분에 LINE iOS 앱 사용자들은 100%에 가까운 비율로 기기 증명에 성공하고 있습니다.
LINE 앱이 변조된 경우
iOS에서는 기기 증명 성공률이 100%에 가깝긴 하지만, 그럼에도 LINE 앱 변조 때문에 일부 실패하는 사례를 확인할 수 있었습니다. iOS는 앱을 변조하려면 기기의 루트 권한을 얻는 탈옥(jailbreaking)이 필요한데요. 최근에 출시된 iPhone에서 가능한 탈옥 방법은 아직 공개된 것이 없으므로 일반 사용자가 LINE iOS 앱을 변조해 사용했을 가능성은 매우 낮습니다. 또한 iOS에서 루트 권한을 획득해 LINE iOS 앱을 변조할 수 있게 되었다고 하더라도 1편의 증명 객체에서 소개된 rpIdHash값이 변경되기 때문에 이를 통해 앱이 변조됐다는 것을 확인할 수 있습니다.
기기 증명 적용 결과
앞서 소개한 내용을 종합해 보면, Android에서는 여러 기기 증명 유형을 관찰할 수 있을 것이라고 예상하기는 했지만 실제로 파악된 기기 증명 실패 유형은 생각보다 더 많았으며, 반대로 iOS는 예상보다 더 유형이 단일화돼 있었습니다.
저희는 이번 기기 증명 서비스 적용을 통해 현실 세계의 다양한 기기 증명 유형을 확인할 수 있었고, 각 유형의 규모를 정량적으로 파악할 수 있었습니다.
앞으로의 방향
이제 서비스에 적용된 기기 증명을 앞으로 어떤 방식으로 활용할지 소개하겠습니다.
잠재적 위험이 될 수 있는 유형 추적 및 관찰
저희는 기기 증명 실패 유형을 분석하며 잠재적 위험이 될 수 있는 다음 경우와 관련해 사용 패턴을 관찰한 후 안티 어뷰징에 활용할 예정입니다.
- 앱을 사용하지 않고 직접 API를 호출해 LINE 앱을 모방하는 경우
- 루팅 등을 통해 앱을 변조한 경우
Apple의 Risk Metric 필드 활용
Apple의 receipt 필드에는 App ID, Attested Public Key, Client Hash, Token, Receipt Type, Creation Time, Risk Metric, Not Before, Expiration Time 등의 필드가 포함되며, 그 중 Risk Metric 필드를 이용해 해당 기기의 비정상 가능성을 간접적으로 판단할 수 있습니다.
Risk Metric 필드
가능성은 적지만 애플리케이션 및 커널 취약점을 통해 기기의 운영 체제를 직접 수정하지 않고도 루트 권한을 얻으면 기기 증명을 우회할 수 있습니다(참고: 1편의 기기 증명 우회 방지 대책). 이 경우 부트 레벨의 무결성이 손상되지 않으므로 공격자는 증명과 어설션 과정을 우회하거나 조작할 수 있습니다. 이런 상황에 활용할 수 있는 것이 바로 Risk Metric 필드입니다.
Apple에서 제공하는 관련 문서에 따르면 Risk Metric 필드값은 해당 기기에서 발생한 최근 한 달간의 증명 횟수입니다. 만약 획득한 루트 권한을 통해 LINE 앱이 여러 개 실행되거나 여러 번 재설치된 경우 증명이 많이 실행되면서 Risk Metric값이 올라갑니다. 따라서 Risk Metric 필드값이 특정 기준보다 높으면 해당 사용자 혹은 기기는 정상적인 사용자나 사용 사례가 아닐 확률이 높습니다.
저희는 iOS 사용자들의 Risk Metric 필드값을 수집해 안티 어뷰징 시스템에서 탐지된 비정상 사용자들과의 연관성을 조사했습니다. 그 결과 특정 기준을 넘는 Risk Metric 필드값을 가진 사용자는 비정상 사용일 확률이 유의미하게 높은 것을 파악할 수 있었으며, 기존의 안티 어뷰징 시스템에서 바로 탐지할 수 없던 비정상 사용자들을 이를 통해 빠르게 탐지할 수 있다는 것을 확인했습니다. 이와 같이 활용 가능성을 통계적으로 확인했기에 기존의 안티 어뷰징 시스템에 Risk Metric 필드값을 새로운 지표로 활용할 예정입니다.
높은 보안 수준이 필요한 서비스에 적용
저희는 메시징 서비스뿐 아니라 다른 패밀리 서비스에서도 기기 증명 기능을 손쉽게 통합할 수 있도록 다양한 수단을 제공하고 있습니다. 이를 이용하면 금융이나 헬스케어와 같이 프라이버시 보호가 매우 중요해 높은 보안 수준이 요구되는 서비스에서 기기 증명 기능을 쉽고 빠르게 도입해 앱 혹은 OS의 위 변조 여부를 검사할 수 있습니다.
현재 이미 저희 회사의 은행 및 결제 서비스에 기기 증명을 적용하기 위한 작업이 진행되고 있습니다. 단순히 증명 성공 여부를 확인하는 것에 그치지 않고 결제 및 송금과 같은 중요한 기능에서 API의 파라미터 값들을 어설션에 바인딩해(참고: 1편의 API를 어설션에 바인딩) 해당 정보가 중간 프락시 서버나 기타 외부 요인 때문에 변조되지 않았다는 것을 검증할 예정입니다. 이를 통해 민감한 금융 거래를 보호하고 서비스의 무결성을 유지할 수 있으며, 사용자에게 더욱 신뢰할 수 있는 금융 환경을 제공할 수 있습니다.
마치며
두 편에 걸쳐 기기 증명의 기술적 원리와 기기 증명 기능이 LINE 앱 서비스에 적용된 과정 및 앞으로의 계획을 소개해 드렸습니다. 기기 증명은 점진적으로 저희 회사의 다른 서비스들로 확장해 나갈 예정이며, 이를 통해 서비스의 신뢰 수준을 더 높일 수 있을 것이라고 예상합니다.
이 자리를 빌려 기기 증명을 적용하는 과정에서 큰 도움을 주신 Security R&D 팀, Account Product App Dev 1 팀, Platform Product Management 팀, Developer Platform Dev 팀, LINE BK 팀에게 진심으로 감사의 말씀을 전하며 글을 마치겠습니다. 긴 글 읽어주셔서 감사합니다.