I. 서론
지적 재산의 가치가 상승함에 따라 기업 내 데이터 보호의 중요성이 증가하고 있다. 가장 일차원적인 보호 방법은 데이터를 암호화하는 것으로, 데이터의 기밀성은 보장되지만, 그 자체만으로는 조직 내 고도화된 접근 권한 관리를 제공할 수 없다. 조직 내 데이터는 지정된 사용자에 의해서만 접근이 가능하도록 제한되어야 한다. 각 사용자의 데이터 접근에 대해서도 일괄적인 권한이 아닌, 읽기, 편집 등 권한을 세분화하여 최소한의 권한만 부여할 수 있어야 한다. 이러한 목적을 실현하기 위해 ERM(Enterprise Rights Management)의 개념이 등장하였다.
ERM을 통해 데이터를 안전하게 관리하려는 수요가 증가하여 Microsoft는 RMS(Rights Management Services)[1]를 설계 및 도입하였다. RMS는 Microsoft O365(Office 365)[2] 외에도 SharePoint[3] 등의 다양한 Microsoft 서비스와 원활하게 통합된다. 이러한 통합을 기반으로, 많은 기업들이 데이터 보호를 위해 RMS를 사용하며, RMS는 현재 ERM 시장을 선도하고 있다[4].
RMS는 Microsoft Office 등의 다양한 문서를 보호하는 기능을 제공한다. 문서 작성자는 RMS를 통해 특정 사용자나 그룹에 세부 권한을 부여하여 데이터 보호를 강화한다. 문서를 공유받은 사용자는 자신에게 부여된 권한 내에서 문서를 이용한다.
사용자가 자신의 기기에서 RMS로 보호된 문서를 생성하거나 열람할 때, 데이터 보호 및 해제를 위한 정보들이 기기에 저장된다. 이러한 RMS 기반 정보가 유출되는 경우, 권한이 없는 사용자도 기밀 데이터에 접근할 수 있으므로, RMS 기반 정보는 기기내에서 유효한 사용자만 접근할 수 있도록 보호되어야 한다. 기기에 대한 외부의 물리적 접근이 있더라도, RMS 기반 정보가 유출되지 않도록 보장되어야 한다.
본 논문은 기기 내 데이터 보호 관점에서 RMS의 보안을 검토한 연구이다. RMS로 보호된 문서가 생성 및 열람되는 전 과정을 확인하고, 그 과정에서 사용되는 RMS 기반 정보를 식별한다. 사용자 기기내에서 해당 정보가 보호되는 체계를 분석하고, Windows RMS 환경에서의 한계점을 도출한다. 이러한 취약성에 기반하여 잠겨 있는 사용자 기기로부터 RMS 기반 정보를 추출하고, RMS 문서 보호를 우회할 수 있는 두 가지 공격을 제시한다. 서로 다른 9가지 Windows RMS 운용 환경(Windows 버전, 로그인 수단 등)에서 공격을 검증한다. 최종 7개 유형(1개는 조건부)에서 성공적으로 데이터가 유출되며, 특정 환경에서만 가능한 공격이 아니라 보편적인 공격임을 보여준다.
본 논문의 구조는 다음과 같이 구성된다. 2절에서는 기존에 알려진 RMS 동작 전반에관한 프로토콜을 배경으로 설명한다. 3절은 연구 동기로, 사용자기기 관점에서 안전성 점검이 필요한 이유와 그 타당성에 대해 논의한다. 4절에서는 기기 내 RMS 데이터 보호 방식에 대해 분석한 내용을 서술한다. 5절에서는 본 논문에서 가정하는 공격자모델을 정의하고, 4절의 분석 내용을 바탕으로 문서의 보호를 무력화할 수 있는 두 가지 공격과 그 파급력을 강조한다. 6절에서는 Windows RMS 운용 환경에서 해당 공격을 수행한 결과를 보여주며, 기기 내 RMS 데이터 보호의 취약성을 강조한다. 7절에서는 관련 연구를 다루고, 8절에서는 가능한 해결 방안과 연구의 한계점을 논의하며 논문을 마무리한다.
II. RMS의 구조
특정 사용자에게 문서에 대한 접근을 허용하고, 읽기, 편집 등 세부 권한을 사용자별로부여하기 위해 RMS가 사용된다. 본 절에서는 작성자가 RMS로 보호된 문서를 생성하고 열람자가 공유받은 문서를 여는 일련의 과정을 통해 RMS 구조 전반을 설명한다. 작성자는 문서를 RMS로 보호하여 열람자에게 공유한다. 열람자는 보호된 문서에 대한 접근 권한이 부여된 사용자를 지칭하며, 주어진 권한 내에서 문서 사용이 가능하다. 보호된 문서에 대한 열람자의 접근은 중앙 서버에 의해 통제된다. 이를 위해 서버는 작성자와 열람자에 대한 인증과 키 분배를 진행한다.
2.1 작성된 문서의 보호
RMS는 문서를 암호화하고, 지정된 열람자에게 문서 암호화에 사용된 키를 분배하여문서를 보호한다. Fig. 1.은 RMS로 보호된 문서의 구조이며, 암호화된 문서(Fig. 1.-①)와 메타데이터로 구성된다. 작성된 문서는 무작위로 생성된 문서 암호화 키로 암호화된다. 작성자는 문서 암호화 키를 열람자에게 공유하기 위해 메타데이터를 생성한다. 메타데이터는 접근 제어 목록(Fig. 1.-②)과 문서 암호화 키(Fig. 1.-③)로 구성된다. 접근 제어 목록은 문서 암호화 키에 접근이 가능한 열람자와 열람자의 세부 권한을 포함한다. 접근 제어 목록은 위변조 방지를 위해 문서 암호화 키로 보호된다. 문서 암호화 키는 서버를 통해서만 열람자에게 분배될 수 있도록 서버의 공개 키로 암호화된다. 작성자는 열람자에게 암호화된 문서와 메타데이터를 함께 배포한다.
Fig. 1. Structure of an RMS-protected document
RMS로 보호된 문서는 패스워드로 보호된 문서와 차이가 있다. RMS로 보호된 문서는 무작위로 생성되는 문서 암호화 키로 암호화된다. 열람자는 서버를 통해서만 문서 암호화 키를 발급받을 수 있어 접근 제어가 가능하다. 반면, 패스워드로 보호된 문서는 작성자가 지정한 패스워드로부터 도출된 키를 사용하여 문서가 암호화된다. 열람자는 작성자 외에도 패스워드를 아는 누구에게서나 패스워드를 공유받을 수 있다. 패스워드 공유를 통제할 방법이 없으므로 접근 제어가 불가능하다.
2.2 보호된 문서의 열람
Fig. 2.는 열람자가 보호된 문서를 열람하기까지 일련의 과정을 나타낸다. 열람자는 서버로부터 인증을 받고, 문서 암호화 키를 요청할 수 있는 권한이 있음을 확인받는다(Fig. 2.-①). 허가된 열람자는 문서의 메타데이터를 서버로 보내 문서 암호화 키를 요청한다(Fig. 2.-②). 서버는 개인 키로 문서 암호화 키를 복호화하고, 문서 암호화 키로 접근 제어 목록을 복호화한다. 접근 제어 목록을 통해 열람자의 권한을 확인한 후(Fig. 2.-③), 서버는 암호화 키를 열람자에게 발급한다(Fig. 2.-④). 열람자는 획득한 키를 이용하여 문서를 복호화한다(Fig. 2.-⑤). 문서를 다시 열람할 때의 사용성을 높이기 위해문서 암호화 키가 디스크에 저장된다. 복호화된 문서는 Word와 같은 문서 편집 프로그램을 통해 열람이 가능하며, 해당 프로그램은 열람자의 권한을 확인하여 일부 기능을 비활성화한다.
Fig. 2. Protocol for accessing an RMS-protected document
III. 연구의 동기
RMS의 보안성 점검에 관한 연구는 이전부터 진행되어왔다. 기존 연구들[5, 6, 7, 8]은보호된 문서에 대해 일정 권한을 보유한 공격자를 가정해 왔으며, 권한이 전혀 없는 공격자에 대한 보안성 점검은 이루어지지 않았다.
RMS 기반 정보는 RMS 문서 보호 및 해제 과정에서 사용되는 정보를 지칭하며, 문서 암호화 키가 그 예이다. RMS가 동작하면서 해당 정보가 서버와 열람자의 기기에 저장된다. 열람자의 기기는 사용자의 로그온 상태에 따라 활성화된 기기와 비활성화된 기기로 분류된다. 활성화된 기기는 화면 잠금이 해제된 기기를 지칭하며, 비활성화된 기기는 화면이 잠겨 있거나 시스템이 종료된 기기를 의미한다.
서버와 활성화된 기기에서 일부 권한을 가진 공격자가 RMS 문서 보호를 해제하는 연구는 이미 존재한다. 서버에서의 연구[5, 6]는 관리자 수준의 권한을 가진 공격자를 가정하고, 서버와 활성화된 사용자 기기로부터 RMS 기반 정보인 문서 암호화 키를 추출한다. 활성화된 기기에서의 연구[7, 8]는 문서에 대한 일부 권한을 가진 열람자가 문서암호화 키를 획득하여 문서에 대한 세부 권한을 상승시키는 것을 목표로 한다.
권한이 없는 공격자가 비활성화된 열람자의 기기를 유용하여 RMS 기반 정보에 접근하는 문제는 아직 논의된 바가 없다. 열람자가 보호된 문서를 열기 위해 서버로부터 인증을 받으면, 열람자의 기기는 열람자의 권한을 위임받은 상태가 된다. 이러한 위임상태는 기기가 종료되어 비활성화된 상태에서도 유지된다. 따라서, 기기가 잠긴 상태로 분실되거나 탈취되어 공격자의 접근이 가능한 상황에서도, 보호된 문서와 위임된 권한이 허가되지 않은 공격자로부터 악용되지 못하도록 보장되어야 한다. 이는 잠긴 기기 내 RMS 기반 정보가 외부의 물리적 공격자에 대해 저항성을 가져야 함을 의미한다. 사용자에 대한 별도의 배경지식 없이 비활성화된 기기만을 획득한 공격자 모델은 여러 포렌식 연구들[9, 10, 11, 12]에 의해 그 중요성과 현실성이 증명되었다. RMS의 본질이 권한이 없는 사용자로부터 데이터를 보호하는 것인 만큼, 비활성화된 기기에서의 점검이 필요하다.
본 논문은 이러한 필요성을 바탕으로, 기존 연구에서 다루지 않았던 비활성화된 열람자 기기와 권한이 없는 공격자를 대상으로 연구를 진행하였다. Microsoft가 RMS 프로토콜과 Windows 운영체제를 모두 개발하였으므로, Windows에서의 RMS 구현이 기준 구현으로 간주된다. 이에 따라, 본 연구는 Windows RMS 환경을 대상으로 수행되었다.
IV. RMS의 데이터 보호 체계 분석
본 절에서는 기기 내에서 보호되어야 하는 RMS 기반 정보를 식별하고, 이를 보호하는 일련의 과정에 대해 분석한다. 분석 내용을 바탕으로 RMS 기반 정보의 보호 체계를 재구성하여 공격에 취약한 부분과 그 요인을 분석하여 지적한다.
4.1 핵심 RMS 기반 정보와 보호의 필요성
Fig. 3.은 2절의 문서 열람 과정을 상세하게 묘사한 그림이다. 해당 그림은 본 연구에서 식별한 열람자의 기기에서 보호되어야 할 두 가지 핵심 RMS 기반 정보인 토큰과 문서 암호화 키를 보여준다.
Fig. 3. In-depth process for accessing an RMS-protected document
4.1.1 첫 번째 핵심 정보: 토큰
2절에서 설명한 바와 같이 열람자는 서버와의 인증을 거친 후, 토큰을 발급받는다(Fig. 3.-①~②). 토큰은 발급일로부터 약 15일간 유효하며, 유효 기간이 만료되면 열람자의 재로그인을 필요로 한다. 열람자의 편의성을 떨어뜨리지 않기 위해 토큰은 주기적으로 갱신된다. 열람자는 이전에 발급받은 토큰을 만료 전에 서버로 전달하고, 유효 기간이 갱신된 새 토큰을 서버로부터 발급받는다.
유효한 토큰이 공격자에게 노출되면, 공격자는 토큰을 활용해 열람자에게 접근 권한이 부여된 조직 내 모든 문서의 문서 암호화 키를 요청할 수 있다. 이는 현재 기기에 존재하는 문서뿐만 아니라 미래에 습득 가능한 문서의 암호화 키도 요청할 수 있음을 의미한다. 더 나아가, 공격자는 사용자 편의를 위해 제공되는 토큰 갱신 기능을 악용하여토큰의 유효성을 지속시키는 것이 가능하다. 토큰 탈취가 무기한으로 연장되는 효과를 가지며, 공격자는 문서 암호화 키를 지속적으로 획득하게 된다. 토큰은 문서 암호화 키 획득을 위한 시작점이 되므로, 열람자의 기기에서 보호되어야 하는 첫 번째 대상으로 식별하였다.
4.1.2 두 번째 핵심 정보: 문서 암호화 키
열람자는 보호된 문서의 메타데이터와 토큰을 이용하여 문서 암호화 키를 획득하고(Fig. 3.-③~④) 문서를 복호화한다(Fig. 3.-⑤). 문서 암호화 키는 문서 재열람 시 사용자 편의성을 위해 기기 내에 저장된다. 문서 암호화 키는 암호학적 키로서 그 유효기간이 존재하지 않으므로, 공격자가 문서 암호화 키를 획득한 시점과 무관하게 RMS로 보호된 문서를 복호화할 수 있다. 문서 암호화 키는 문서 보호의 해제와 가장 직접적으로 관련된 RMS 기반 정보이므로, 문서 암호화 키를 열람자의 기기에서 보호되어야 하는 두 번째 대상으로 식별하였다.
4.2 RMS 기반 정보의 보호 체계
4.1절에서 식별한 핵심 RMS 기반 정보가 사용자 기기 내에서 보호되는 과정을 분석하였다. 그 과정에서 데이터 보호 기법이 적절히 적용되어 있는지 확인하였다.
4.2.1 Windows 데이터 보호 기법
Windows는 민감한 데이터를 안전하게 보호하기 위한 DPAPI(Data Protection Application Programming Interface)[13]를 제공한다. DPAPI는 복잡한 암·복호화와 그 과정에서 사용되는 값의 관리를 추상화하는 역할을 한다. 일반적으로 DPAPI는 소프트웨어 기반의 보호를 제공하며, 사용자의 비밀 값에서 파생되는 DPAPI 키를 통해 데이터를 암호화한다. 데이터 보호 강화를 위해 추가적인 보안 계층을 도입함에 따라, DPAPI는 하드웨어 기반의 보호와 결합되어 사용되기도 한다.
하드웨어 기반의 보호는 데이터를 물리적으로 격리된 상태로 보호하여, 물리적 접근을 통해 데이터가 유출되는 것을 방지한다. TPM(Trusted Platform Module)[14]과 같은 장치를 통해 격리된 환경에서 암호화 연산을 수행하고, 데이터를 저장한다. Windows는 TPM과 긴밀하게 상호작용하여 BitLocker[15], Secure Boot[16]와 같은 보안 기능을 지원한다. 하드웨어 기반의 보호를 적용하면 사용자 편의성을 제공하면서 데이터 보호의 안전성을 높일 수 있다.
Windows 운영체제가 설치된 기기에 등록되는 계정은 개인용과 조직용으로 구분되며, DPAPI의 동작 방식은 계정 유형에 따라 달라진다. 개인용 계정의 경우, DPAPI 키 도출에 사용되는 데이터가 모두 디스크에 저장된다. 조직용 계정은 TPM의 활성화 여부에 따라 데이터의 저장 위치가 결정되며, TPM 내에 저장되거나 디스크에 저장된다. TPM이 사용되지 않는 경우에 한하여, 기기에 대한 물리적인 접근을 통해 DPAPI 키를 복구하고, 보호된 데이터를 복호화하는 연구가 존재한다[17, 18, 21, 24].
4.2.2 RMS 기반 정보의 보호 기법
토큰과 문서 암호화 키는 각각 독립적으로 보호되지만, 유사한 키 계층 구조를 통해 보호되는 것을 확인하였다. 이에 따라, 두 RMS 기반 정보의 데이터 보호 기법을 통합하여 설명한다. Fig. 4.는 열람자 기기 내에서 핵심 RMS 기반 정보가 세 단계로 보호되는 과정을 나타낸다. 각 RMS 기반 정보는 데이터 암호화 키(data encryption key)에 의해일차적으로 암호화되어 저장된다. 데이터 암호화 키는 키 암호화 키(key encryption key)를 통해 보호되어 저장된다. 마지막으로 키 암호화 키는 Windows의 DPAPI에 의해 보호되어 저장된다. 모든 단계에서 보호된 데이터는 디스크에 저장되며, 각 단계의 보호 과정에서 하드웨어 기반의 보호를 포함한 다른 보안 기법은 적용되지 않는다. 결과적으로 RMS 기반 정보는 계층적 암호화 구조에 따라 연쇄적으로 보호되며, 최종 보안 강도는 DPAPI에만 의존한다.
Fig. 4. Protection mechanism for RMS credentials
4.3 RMS 기반 정보의 보호 체계에 관한 문제점
4.2절에서 설명한 바와 같이 RMS 기반 정보는 보호 기법의 다원화 없이 DPAPI에만 의존하는 구조이다. DPAPI에 취약점이 존재하여 DPAPI 키가 노출되면 연쇄적인 복호화를 통해 RMS 기반 정보도 노출된다. 소프트웨어 기반의 DPAPI는 과거 연구[17, 18]에 의해 그 취약성이 공개된 바가 있다. 하드웨어 기반의 보호와 결합되지 않은DPAPI가 사용되는 한, 각 키 계층이 별도의 보안 강도를 제공하지 못하여 토큰과 문서 암호화 키가 유출될 위협이 존재한다.
V. 문서 보호를 우회하는 공격
본 절에서는 공격 모델을 정의하고, 핵심 RMS 기반 정보로부터 문서 보호를 우회하는 두 가지 공격을 제시한다. RMS의 데이터 보호 기법에 대한 분석 내용을 바탕으로, 피해자의 기기에서 보호된 문서와 RMS 기반 정보를 추출하여 획득한 문서의 보호를 우회하는 방법을 단계별로 설명한다.
5.1 공격 모델
5.1.1 피해자
피해자의 기기는 비활성화된 열람자의 기기로, RMS로 보호된 문서가 저장되어 있다. 피해자는 해당 기기에서 보호된 문서를 최소 한 번 이상 열람하였으며, 이 과정에서 서버와의 인증을 완료하였다. 서버가 발급한 RMS 기반 정보는 모두 기기에 저장되어 있으며, 별도로 삭제되지 않았다. 피해자 기기에는 Windows 운영체제가 설치되어 있으며, BitLocker 디스크 암호화 기능이 비활성화된 상태를 가정한다. BitLocker는 Windows Pro, Enterprise, Education에만 지원되는 기능이며[15], Bitlocker가 자동으로 활성화되는 조건이 엄격하다[19]. Microsoft도 이를 인지하고, 공개 예정인 Windows 11 24H2 버전에서 해당 기준을 완화하려는 움직임을 보이고 있다[19].
피해자 기기에서의 TPM 존재 유무는 Windows 버전에 따라 결정된다. Windows 10에서는 TPM이 선택적으로 적용되며, Windows 11에서는 기본적으로 요구된다. 이에 따라 Windows 10이 설치된 경우에는 TPM 활성화 여부가 모두 가능하지만, Windows 11이 설치된 경우에는 반드시 TPM이 탑재된 것으로 한다.
5.1.2 공격자
공격자는 피해자의 디스크에 저장된 데이터를 외부에서 물리적으로 접근하여 추출할 수 있다. 보호된 문서의 획득은 피해자 기기로부터 이루어진다. 단, 공격자는 피해자의 기기와 계정에 대한 로그인 정보는 보유하고 있지 않다.
공격자는 피해자의 디스크에서 보호된 문서를 획득하고, 열람하는 것을 목표로 한다. 공격자가 보호된 문서의 열람을 시도하면, 권한 부재로 인해 접근이 차단된다. 이를 우회하여 보호된 문서를 열람하기 위해 공격자는 문서 암호화 키를 획득하고자 한다.
5.2 공격 1: 토큰을 이용하여 문서 보호를 우회
토큰을 이용하여 문서 보호를 우회하는 공격은 피해자 기기 내 보호된 문서를 모두 열람할 수 있게 한다. 공격자는 토큰을 이용해 서버로부터 문서 암호화 키를 발급받아 문서를 복호화하고자 한다. 데이터 보호 기법을 우회하여 기기 내 저장된 토큰을 획득하고, 이를 통해 문서 보호를 우회하는 공격 방법을 설명한다.
5.2.1 문서 보호를 우회하는 과정
공격은 다섯 단계로 이루어진다. 1) 데이터 식별, 2) 데이터 추출, 3) 토큰 보호 해제, 4) 서버로의 데이터 요청, 5) 문서 보호 해제 순서이다. 1) 토큰 보호를 위해 사용된 모든 데이터를 식별한다. 토큰과 토큰을 보호하는 데이터 암호화 키, 키 암호화 키는 모두 암호화되어 저장되어 있으며, 키 암호화 키는 DPAPI로 보호된다. 2) 각 키와 DPAPI 키 도출에 사용되는 데이터를 추출하여 공격자 기기에 이식한다. 3) 4.2.2절에서 설명한 RMS 기반 정보의 보호 과정을 역으로 수행하여 토큰을 복호화한다. 추출한 데이터에서 가장 먼저 DPAPI 키를 도출하고, 이로부터 키 암호화 키와 데이터 암호화 키를 차례로 복호화하여 토큰을 획득한다. DPAPI 키 도출은 기존 연구 내용[17, 18, 21]을 바탕으로 진행한다. 4) 공격자는 열람을 원하는 문서의 메타데이터와 토큰을 함께 서버로 보내 문서 암호화 키를 요청한다. 5) 서버는 토큰과 메타데이터를 검증한 후, 문서암호화 키를 발급한다. 문서 암호화 키는 평문으로 전달되며, 공격자는 이를 이용하여 문서를 복호화한다.
5.2.2 공격의 파급 효과
피해자에게 권한이 없는 문서를 제외하고, 기기에 저장된 모든 문서가 공격자에 의해열람이 가능하다. 토큰을 통해 문서 암호화 키를 서버로부터 받아오기 때문에, 문서 암호화 키가 디스크에 남아있지 않아도 문서 복호화가 가능하다. 문서 암호화 키를 이용해 원본 문서가 복호화되므로 공격자는 읽기, 수정을 포함한 모든 작업이 가능하다. 4.1.1절에서 설명한 토큰 갱신 과정을 통해 토큰의 유효성을 지속적으로 유지시키면, 기기 접근 시점 이후에 획득하는 문서들도 계속해서 복호화할 수 있다.
5.3 공격 2: 저장된 문서 암호화 키를 이용하여 문서 보호를 우회
기기에 저장된 문서 암호화 키를 이용하여 문서 보호를 우회하는 공격은 토큰이 만료되어 서버로부터 문서 암호화 키를 발급받을 수 없는 경우에도 유효하다. 공격자는 기기로부터 저장된 문서 암호화 키를 추출하여 문서를 복호화할 수 있다. 본 절에서는 저장된 문서 암호화 키에 대한 데이터 보호 기법을 우회하고, 문서의 보호를 우회하는 공격을 설명한다.
5.3.1 문서 보호를 우회하는 과정
공격은 네 단계로 이루어진다. 1) 데이터 식별, 2) 데이터 추출, 3) 문서 암호화 키 보호 해제, 4) 문서 보호 해제 순서이다. 3)까지의 과정은 공격 1과 유사하나 목표로 하는 RMS 기반 정보가 기기 내 저장된 문서 암호화 키이다. 1) ~ 3)까지의 과정을 통해 문서 암호화 키에 대한 보호를 해제한다. 4) 획득한 문서 암호화 키를 사용하여 문서를 복호화한다. 공격 1과의 차이점은 문서 암호화 키의 획득 방식에 있다. 공격 1은 서버에 토큰을 보내 문서 암호화 키를 요청하는 반면, 해당 공격은 기기에 이미 저장된 문서 암호화 키를 사용한다.
5.3.2 공격의 파급 효과
토큰이 만료되어 서버로부터 문서 암호화 키를 획득할 수 없더라도 공격자는 기기 내에 저장된 일부 문서를 복호화할 수 있다. 열람자가 한 번이라도 열람하여 문서 암호화 키가 기기에 저장된 문서는 모두 공격자에 의해 복호화될 수 있다. 토큰을 이용한 공격에서와 같이, 문서 암호화 키를 이용해 원본 문서를 복호화하므로 공격자는 읽기, 수정을 포함한 모든 작업이 가능한 상태가 된다.
VI. 실험
본 절에서는 공격 검증을 위해 구성한 실험 환경과 각 환경에서의 실험 결과에 대해 서술한다. Table 1.은 5절에서 제시한 두 가지 RMS 보호 우회 공격을 다양한 Windows RMS 환경에서 실험한 결과이다.
Table 1. Assessment results of our two proposed attacks across 9 different Windows RMS environments. The evaluation focuses on whether attackers can exfiltrate the document encryption key from a locked device. If the key can be extracted, the device is deemed vulnerable. When the key can only be obtained under specific conditions related to the device’s configuration, the vulnerability is categorized as limited.
PA:Personal Microsoft Account OA:Organizational Account *: With hardware protection ●:Vulnerable ◐:Limited vulnerability ○:Not vulnerable
6.1 실험 환경
Microsoft 365 Business Premium[20] 구독을 이용하여 조직 내 RMS를 구성하였다. 피해자는 조직에 등록된 유효한 사용자이다. 해당 구독을 통해 조직용 RMS 서버를 구축하지 않고 Microsoft에서 운영하는 RMS 서비스를 사용하였다.
피해자의 기기는 Windows 10 또는 Windows 11이 설치된 가상 머신으로 구축하였다. 운영체제 설치 과정은 기본 설정으로 진행하였다. Windows 운영체제를 사용하기 위해서는 기기에 사용자 계정을 등록해야 하며, 사용자 계정은 개인용 계정과 조직용 계정으로 나뉜다. 개인용 계정은 사용자가 기기에 대해 암호를 설정하고 로그인하는방식과 Microsoft 계정으로 로그인하는 방식으로 구분된다. 조직용 계정은 조직의 도메인에 등록된 계정을 사용하여 인증하는 방식이다. 사용자 계정의 종류별로Windows에서 지원하는 보호 기법이 상이하여 모든 종류의 사용자 계정에 대해 실험을 진행하였다. Microsoft 계정과 조직용 계정을 기기에 등록하는 경우, 기본적으로 PIN 추가가 요구된다. 일반적으로 PIN은 숫자로만 조합되지만, 사용자의 인위적인 설정에 의해 문자나 기호가 포함된다. 실험에서는 두 가지 경우를 모두 고려하여 PIN을 설정하였다. 사용자가 PIN을 등록한 이후에는 지문을 포함한 다양한 로그인 옵션을 추가할 수 있다. 본 논문에서는 기본 설정인 PIN에 대해서만 실험을 진행하였다.
5.1.1절에서 서술한 바와 같이, Windows 10에서는 TPM 활성화 여부를 모두 다루었으며, Windows 11에서는 TPM이 활성화된 환경에서만 실험하였다.
구성된 Windows 환경에 2046 버전(빌드 16.0.17726.20078)의 Office 365를 설치하였으며, Office 프로그램은 조직 도메인에 등록된 조직용 계정을 이용하여 로그인하였다. 기기의 사용자 계정과 Office에 로그인하는 계정은 별개로, RMS는 Office에 로그인한 사용자 정보로 작동한다.
최종적으로 두 가지 Windows 버전, 세 가지 사용자 계정, TPM 유무를 조합하여 Windows 운영체제상의 9가지 RMS 운용 환경을 대상으로 실험을 진행하였다.
6.2 공격 1의 결과
토큰을 이용한 문서 보호 우회 공격을 앞서 설명한 RMS 운용 환경에서 실험하였다. 실험의 결과를 개인용 계정과 조직용 계정으로 나누어 설명한다.
6.2.1 개인용 계정
개인용 계정을 사용하는 피해자 기기를 대상으로 공격 1을 수행한 결과를 설명한다. 토큰의 키 암호화 키는 소프트웨어 기반의 DPAPI로만 보호된다. 개인용 계정의 기기에서는 DPAPI 키가 잠겨 있는 기기로부터 추출이 되며[17, 18], 이를 통해 키 암호화 키가 연쇄적으로 복호화된다.
키 암호화 키가 노출이 된 상황에서 토큰의 보호는 데이터 암호화 키에 의존한다. 데이터 암호화 키는 키 암호화 키로만 보호되며, TPM 기반의 보호가 적용되어 있지 않다. 키 암호화키를 사용하여 데이터 암호화 키와 토큰을 연쇄적으로 복호화하였으며, 토큰에 적용된 보호 기법을 성공적으로 우회하였다.
획득한 토큰과 문서의 메타데이터를 함께 서버로 보내고, 서버로부터 문서 암호화 키를 획득하였다. 문서 암호화 키로 문서를 복호화하였으며, 문서에 대한 보호까지 성공적으로 우회하였다. TPM이 활성화 된 기기에서도 토큰의 보호 과정에서 TPM을 사용하지 않아 데이터 유출에 취약한 결과를 보였다.
6.2.2 조직용 계정
조직용 계정이 등록된 피해자 기기를 대상으로 공격 1을 시도한 결과를 설명한다. 조직용 계정의 기기에서는 TPM 사용 유무에 따라 공격 가능 여부에 차이가 존재하였다.
TPM을 사용하지 않는 기기. TPM이 없는 조직용 계정의 기기에서는 토큰의 키 암호화 키가 소프트웨어 기반 DPAPI로만 보호가 가능하다. 피해자가 열 자리 미만의 숫자로 구성된 PIN을 사용하는 경우, 공격자는 PIN에 대한 무차별 대입 공격을 통해 DPAPI 키를 알아낼 수 있다[21]. PIN은 네자리부터 최대 20자리까지 가능하지만, 대부분 열자리 이내의 PIN이 사용되는 것으로 알려져 있다[22]. PIN 무차별 대입 공격을 시도했을 때, 열 자리 이내의 PIN은 현실적인 시간 내에 탐색이 가능하다[23]. PIN이 식별되는 때에만, DPAPI 키 도출이 가능하다. 한편, 문자, 숫자, 특수 문자가 모두 조합되어 암호와 비슷한 형태의 PIN이 사용되는 경우, 무차별 대입 공격을 통해 DPAPI 키를 도출해 내기 어렵다. 해당 계정의 기기에서는 PIN 설정에 따라 DPAPI 키 도출 가능 여부가 결정되었으며, 이에 따라 키 암호화 키의 노출 여부가 결정되었다.
키 암호화 키가 노출될 경우, 토큰의 보호는 데이터 암호화 키에 의존한다. 데이터 암호화 키는 키 암호화 키로만 보호되며, 하드웨어 기반으로 보호되지 않는다. 키 암호화 키를 획득하고, 데이터 암호화 키와 토큰을 차례로 복호화하여 토큰의 보호를 성공적으로 우회하였다. 이후, 추출한 토큰과 문서의 메타데이터를 서버로 보내 문서 암호화 키를 획득하였다. 해당 키로 문서를 복호화하였으며, 문서의 보호를 성공적으로 우회하였다.
TPM을 사용하는 기기. TPM을 사용하는 조직용 계정의 기기에서는 토큰의 키 암호화 키가 하드웨어 보호와 결합된 DPAPI로 보호된다. 현재까지 알려진 바에 따르면, 하드웨어 보호를 사용하는 DPAPI 키 획득은 어렵다. TPM을 사용하는 조직용 계정의 기기에서는 DPAPI 키가 노출되지 않아 최종적으로 토큰 추출에 실패하였으며, 공격자가 문서의 보호를 우회하는 것이 불가능하였다.
6.3 공격 2의 결과
기기에 저장된 문서 암호화 키를 이용하여 문서의 보호를 우회하는 공격을 9가지 RMS 운용 환경에서 실험하였다. 공격의 성공 여부와 그 원인이 토큰을 이용한 공격과 유사하다.
6.3.1 개인용 계정
기기에 저장된 문서 암호화 키를 보호하는 키 암호화 키는 공격 1에서와 동일하게 소프트웨어 기반의 DPAPI로만 보호된다. 개인용 계정의 기기에서는 DPAPI 키가 노출되어 사용자 기기에 저장된 문서 암호화 키의 획득이 가능하였다. 추출한 키로 문서를 복호화하였으며, 문서 보호까지 성공적으로 우회하였다. 공격 1에서와 동일하게 TPM이 활성화된 기기에서도 문서 암호화 키가 하드웨어 기반의 보호를 받지 않아 데이터 유출에 취약한 결과를 보였다.
6.3.2 조직용 계정
TPM을 사용하지 않는 기기. TPM이 없는 조직용 계정의 기기에서는 키 암호화 키가 소프트웨어 기반의 DPAPI로만 보호가 가능하다. 해당 실험 환경에서도 PIN 탐색 성공 여부에 따라 조건부로 DPAPI 키를 추출할 수 있었으며, 이를 통해 연쇄적으로 문서 암호화 키를 획득하였다. 기기의 PIN 설정에 따라 제한적으로 문서 보호를 우회하였다.
TPM을 사용하는 기기. TPM을 사용하는 조직용 계정의 기기에서는 키 암호화 키가 하드웨어 보호가 적용된 DPAPI로 보호된다. TPM을 사용하는 조직용 계정의 기기에서는 문서 복호화 키를 획득할 수 없었으며, 공격자가 문서의 보호를 우회하는 것이 불가능하였다.
VII. 관련 연구
7.1 RMS 분석 및 안전성 점검 연구
사용자의 기기 및 서버로부터 문서 암호화 키를 획득하기 위해 다양한 관점에서 RMS가 분석되었다. Schrittwieser 등[5]은 Microsoft RMS와 또 다른 ERM 솔루션인 Adobe LiveCycle에 대한 포렌식 연구를 진행하였다. 연구의 목표는 사용자의 기기와 서버에 저장된 문서 암호화 키를 획득하는 것이었다. 잠금이 해제된 기기와 서버에 관리자 권한으로 접근할 수 있는 분석관을 가정하여 연구가 진행되었다. 해당 분석관은 본 연구의 공격자 모델에 비해 월등히 많은 권한을 요하므로, 잠겨 있는 기기와 권한이 없는 공격자 모델에는 적용하기 어렵다.
Grothe 등[7]은 RMS의 문서 보호 과정을 분석하여 보호된 문서에 대한 권한 상승 공격을 제시하였다. 공격자는 조직 내 사용자로 문서에 대한 일부 권한을 부여받은 상태를 가정하였다. 공격자의 목표는 문서에 대한 모든 권한을 획득하고, 해당 문서를 은밀히 위변조하는 것이었다. 해당 연구 또한 잠금이 해제된 기기에서 진행되었으며, 공격자가 직접 RMS 관련 함수를 호출하여 RMS 문서 보호를 해제하였다. 이러한 접근 방식은 본 연구의 기기 탈취 시나리오에는 적용되지 않는다.
Grothe 등[8]은 앞선 연구를 확장하여 RMS에서의 문서 암호화 키 보호 체계를 분석하였다. 해당 연구는 토큰에 대해 다루지 않았으며, RMS가 업데이트됨에 따라 RMS의 데이터 보호 체계가 변화하여 현재 RMS에는 적용하기 어렵다.
Grothe 등[6]은 종단간 암호화와 RMS를 적용하여 데이터를 이중으로 보호하는 Tesorit RMS에 대한 보안 점검 연구를 진행하였다. 해당 연구는 서버 내 관리자가 공격자인 상황에서 종단간 암호화를 우회하여 중간자 공격을 수행하는 방법을 제안하였다. 이 논문은 다른 서비스에 RMS를 접목할 때 고려해야 할 보안 위협에 대한 통찰을 제공한다.
7.2 Windows DPAPI 분석 및 안전성 점검 연구
Windows에 저장되는 민감 데이터는 DPAPI로 보호되며, RMS에서도 데이터 보호를 위해 DPAPI가 사용된다. 데이터 보호를 우회하기 위해 공격자 관점에서의 연구가 여러 차례 진행되었다[13, 17, 18, 21, 24]. 소프트웨어 기반으로만 동작하는 DPAPI는 보호 과정에 사용된 키가 노출될 수 있음이 밝혀졌다[17, 18]. DPAPI 보호 해제는 기존 연구들을 참고하여 진행하였으며, 본 연구에서는 별도의 DPAPI 분석을 진행하지 않았다.
개인용 계정의 DPAPI 키 노출에 관한 취약점은 Windows 10 이후 탑재된 TBAL(Trusted Boot Auto Logon) 기능[18]에 의해 발생한다. TBAL은 시스템 업데이트 후 사용자 로그인 비밀번호 입력을 기다리지 않고 사용자 세션을 복원하며, 이 과정에서 세션을 복호화하기 위한 키 도출 값이 디스크에 저장된다. 해당 기능이 Windows 데이터 보호의 백도어로 사용될 수 있음을 지적하는 연구들[17, 18]이 공개되었다. 시스템 종료 후 디스크에 저장된 값을 통해 개인용 계정의 기기에서 DPAPI 보호를 해제할 수 있는 키가 도출될 수 있음을 보여주었다.
Jullian 등[21]은 조직용 계정을 기반으로 동작하는 인증 시스템인 Windows Hello for Business[25]를 분석하였다. PIN이 등록된 조직용 계정의 기기에서 DPAPI 키가 노출될 가능성을 보여주었으며, PIN 무차별 대입 공격이 성공하는 경우에만 DPAPI 키가 노출되었다. PIN이 숫자와 문자가 혼합되어 복잡할 경우 무차별 대입 공격의 난이도가 증가하였다.
Burzstein 등[13]은 DPAPI의 동작 과정을 분석하고, 공격자 관점에서 이를 우회 및 악용하는 방법을 제안하였다. 기기 사용자가 이전에 사용했던 모든 비밀번호를 복구하는 방법과 비활성화된 기기에서 DPAPI로 보호된 데이터를 복호화하는 라이브러리[24]를 공개하였다.
VIII. 논의
본 절에서는 RMS 기반 정보 노출에 의한 문서 보호 우회 공격의 해결 방안에 관하여 논의한다. 연구의 한계점에 대해 다루고, 향후 연구 방향을 제시한다.
8.1 해결 방안
RMS 기반 정보를 안전하게 보호하기 위한 두 가지 방안을 제시한다.
8.1.1 DPAPI의 보안 강화
현재 데이터 보호 체계에서 기반이 되는 DPAPI의 보안을 강화할 것을 제안한다. 하드웨어와 결합된 DPAPI를 통해 실현할 수 있으며, 이는 TPM이 활성화된 조직용 계정의 기기에서 검증된 바가 있다.
개인용 계정이 등록된 기기의 경우, TPM 활성화 유무에 관계없이 소프트웨어 기반의DPAPI만 사용이 된다. 하드웨어 기반의 보호를 받을 수 있음에도 이를 활용하지 않아 데이터가 유출된다. TPM이 지원되는 기기에서는 하드웨어 기반의 DPAPI를 사용하여 데이터를 보호해야 한다.
8.1.2 보호 기법의 다원화
RMS 기반 정보의 보호 체계에서 보안 기법을 다원화할 것을 제안한다. 해당 정보를 보호하기 위한 키 중 하나를 택하여 하드웨어 기반으로 저장한다. 여기서 하드웨어 기반의 저장은 키를 TPM 내에 저장하거나, TPM만 접근 가능한 값으로 키를 암호화하여 시스템 내에 저장하는 것을 의미한다. DPAPI 키가 노출되어도, 하드웨어로 보호된키를 기점으로 복호화가 중단되어 데이터가 안전하게 보호된다.
하드웨어 기반의 보호를 제공할 수 없는 환경에서는 데이터를 보호하는 값이 노출되지 않도록 하는 것이 중요하다. 보호된 데이터에 대한 접근 시마다 사용자의 비밀 값을 요구하고, 해당 비밀값에서 도출된 키로 데이터를 보호할 것을 제안한다.
8.2 연구의 한계점 및 향후 과제
분석한 RMS의 데이터 보호 기법은 Windows 기기를 대상으로 제한된다. 각 운영체제에서 RMS의 데이터 보호 기법을 분석하고 비교하는 연구는 추후 연구 과제로 제안한다.
본 연구는 Office 애플리케이션에 적용된 RMS를 대상으로 분석을 진행하였다. Microsoft에서 배포한 RMS 관련 SDK(Software Development Kit)[26]을 사용하는 타사 프로그램도 유사한 방식으로 데이터를 보호할 가능성이 존재한다. 본 연구를 확장하여 RMS가 적용된 타 프로그램의 데이터 보호 기법에 대한 분석을 시도해볼 수 있다.
문서 보호를 우회하는 공격에서 TPM에 저장되는 데이터는 추출이 불가하다. 비활성화된 기기에서 피해자의 인증 정보 없이 TPM으로부터 데이터를 획득하는 것은 난제이다. 하드웨어 보안을 우회하여 데이터를 추출하는 것은 향후 연구 과제로 제안한다.
보편성이 높은 Windows RMS 환경을 대상으로 공격을 검증하기 위해 Windows 운영체제의 기본 설정 환경에서 실험을 진행하였다. 운영체제 설치시, 개인용 Microsoft 계정과 조직용 계정 모두 PIN을 기본 로그인 수단으로 사용한다. Windows 운영체제는 PIN 외에도 지문 인식 등 다양한 로그인 옵션을 제공하지만, 이는 사용자가 별도로 설정해야 한다. 본 연구에서는 기본 로그인 옵션인 PIN이 등록된 기기에 대해서만 실험을 진행하였다. 향후 연구에서는 실험 대상 기기의 인증 수단을 다양화하여 공격을 검증해 볼 수 있다.
IX. 결론
조직 내 데이터를 보호하고 권한을 관리하기 위해 RMS가 사용된다. 사용자가 RMS를 사용하면 데이터 보호와 관련된 정보가 기기 내에 저장된다. 해당 정보가 유출되면, 권한이 없는 사용자가 보호된 데이터에 접근할 수 있다. 기기가 탈취된 상황에서도 해당 정보는 기기 내에서 안전하게 보호되어야 한다.
본 논문에서는 기기 내 데이터 보호 관점에서 RMS의 보안을 점검하였다. RMS를 통해 문서를 보호 및 열람하는 전체 과정을 분석하고, 그 과정에서 권한 관리의 핵심이 되는 RMS 기반 정보를 식별하였다. 잠긴 기기 내에서 RMS 기반 정보가 적용받는 보호 체계를 상세히 분석하였으며, 그 과정에서 일부 정보가 취약하게 보호됨을 확인하였다.
이를 바탕으로 RMS 기반 정보를 잠긴 사용자 기기로부터 추출하고, RMS 보호를 무력화시키는 두 가지 공격을 제시하였다. 공격의 보편성을 입증하기 위해 9가지 서로 다른 Windows RMS 운용 환경에서 공격을 시도하였다. 실험 결과, 최종 7개 유형(1개는 조건부)에서 기기의 물리적 접근에 의한 데이터 유출에 취약하였다. 해결을 위해 RMS 데이터 보호 과정에 추가적인 하드웨어 보안 계층을 추가할 것을 제안하였다.
부록
토큰과 문서 암호화 키 보호 과정에서 사용되는 데이터가 암호화되어 저장된 위치를설명한다. 해당 경로는 Word 애플리케이션 사용을 기준으로 작성된 것이다.
토큰을 보호하기 위해 사용된 데이터 암호화 키, 키 암호화 키와 토큰은 모두 암호화되어 하나의 파일에 저장된다. 파일의 위치는 %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\LocalState\{User Identifier}\c_mi1cmdi10dtsodg6l5e346dh 이다.
Table 2.는 문서 암호화 키의 보호 과정에서 사용되는 키가 암호화되어 저장된 위치를나타낸다. 키 암호화 키가 저장된 파일은 조직용 계정의 이메일 주소를 통해 식별할 수 있다.
Table 2. Storage of data within the protection mechanism for a document encryption key
References
- Microsoft, "MS-RMPR: Rights Management Services (RMS): Client-to-Server Protocol," https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rmpr/d8ed4b1e-e605-4668-b173-6312cba6977e, Aug. 2023.
- Microsoft, "The Microsoft 365 App (formerly Office)," https://www.office.com/?omkt=en-U, Jul. 2024.
- Microsoft, "What is SharePoint?," https://support.microsoft.com/en-us/office/what-is-sharepoint-97b915e6-651b-43b2-827d-fb25777f446f, Jul. 2024.
- Mordor Intelligence, "Digital Rights Management Market Size & Share," https://www.mordorintelligence.com/industry-reports/digital-rights-management-drm-market, Jul. 2024.
- S. Schrittwieser, P. Kieseberg, and E. Weippl, "Digital forensics for enterprise rights management systems," Proceedings of the 14th International Conference on Information Integration and Web-based Applications & Services, pp. 111-120, Dec. 2012.
- M. Grothe, C. Mainka, P. Rosler, J. Jupke, J. Kaiser, and J. Schwenk, "Your Cloud in My Company: Modern Rights Management Services Revisited," Proceedings of 2016 11th International Conference on Availability, Reliability and Security. pp. 217-222, Aug. 2016.
- M. Grothe, C. Mainka, P. Rosler, and J. Schwenk, "How to Break Microsoft Rights Management Services," Proceedings of 10th USENIX Workshop on Offensive Technologies, pp. 1-14, Aug. 2016.
- M. Grothe, "Security implications through legacy software systems," Ph.D. Thesis, Ruhr-Universitat Bochum, Sep. 2020.
- D. Sladovic, D. Topolcic, and D. Delija, "Overview of Mac system security and its impact on digital forensics process," Proceedings of the202043rd International Convention on Information, Communication and Electronic Technology, pp. 1236-1241, Sep. 2020.
- A. Fukami, R. Stoykova, and Z. Geradts, "A new model for forensic data extraction from encrypted mobile devices," Forensic Science International: Digital Investigation, vol. 38, pp. 1-10, May. 2021.
- P. Teufl, T. Zefferer, C. Stromberger, and C. Hechenblaikner, "iOS encryption systems: Deploying iOS devices in security-critical environments," Proceedings of the 2013International Conference on Security and Cryptography, pp. 1-13, Jul. 2013
- A. Belenko, "Overcoming iOS data protection to re-enable iPhone forensics," Black Hat USA, Aug. 2011.
- E. Burzstein and J. M. Picod, "Recovering Windows Secrets and EFS Certificates Offline," Proceedings of 4th USENIX Workshop on Offensive Technologies, pp. 1-9, Aug. 2010.
- Microsoft, "Trusted Platform Module Technology Overview," https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-overview, Jul. 2024.
- Microsoft, "BitLocker overview," https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/, Jul. 2024.
- Microsoft, "Secure Boot," https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot, Jul. 2024.
- Vztekoverflow, "TBAL: DPAPI Backdoor for local users," https://vztekoverflow.com/2018/07/31/tbal-dpapi-backdoor/, Dec. 2023.
- Passcape, "DPAPI security flaw," https://www.passcape.com/index.php?section=blog&cmd=details&id=38, Dec. 2023.
- Microsoft, "BitLocker drive encryption in Windows 11 for OEMs," https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker, Jul. 2024.
- Microsoft, "Microsoft 365 Business Premium," https://www.microsoft.com/enus/microsoft-365/business/microsoft-365-business-premium?activetab=pivot:overviewtab, Jul. 2024.
- Synscktiv, "WHFB and Entra ID : Say Hello to your new cache flow," https://www.synacktiv.com/publications/whfb-and-entra-id-say-hello-to-your-new-cache-flow, Jun. 2024.
- DataGenetics, "PIN analysis," http://www.datagenetics.com/blog/september32012/, Jun. 2024.
- E. Kim and H. Choi, "Security Analysis and Bypass User Authentication Bound to Device of Windows Hello in the Wild," Security and Communication Networks, vol. 2021, no. 1, pp. 1-13, Jul. 2021.
- GitHub, "DPAPIck," https://github.com/jordanbtucker/dpapick, Dec. 2023.
- Microsoft, "Windows Hello for Business," https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/, Jul. 2024.
- Microsoft, "Microsoft Information Protection (MIP) SDK setup and configuration," https://learn.microsoft.com/enus/information-protection/develop/setup-configure-mip, Jul. 2024.