AD RMS를 이용한 파일 보안/암호화3

마지막으로,

AD RMS를 이용한 파일 보안/암호화에 사용되는 암호화 알고리즘 및 그 진행 흐름에 대해 살펴본다.

먼저,

AD RMS의 암호화/복호화 흐름에 따라 파일명 및 파일 내용 등에 두루 사용되는 약어들부터 정리해본다.

- CERT: machine CERTificate, 장치 인증서. AD RMS 서버가 클라이언트 컴퓨터에 발급해주는 인증서 체인.

- CLC: Client Licensor Certificate, 클라이언트 사용 허가자 인증서. 파일 보호의 주체가 자신을 증명하는 용도로 사용하는 인증서 체인.

- SLC: Server Licensor Certificate, 서버 사용 허가자 인증서. AD RMS 서버에 발급된 인증서 체인.

- GIC: Group Identify Credential, 보호된 파일을 사용하는 사용자(그룹) 계정.

- RAC: Rights Account Certificate, 권한 계정 인증서. GIC에 대해 발급되는 인증서 체인. 개인키 keyfile3.drm과 함께 쌍으로 생성된다.

- EUL: End User License, 보호된 파일에 대한 허가 내용 및 암호화된 콘텐츠 키가 포함된 인증서 체인.

좀 어렵고 복잡한 개념인 관계로,

쉽게 이해할 수 있게 하기 위해 구체적인 예를 들어 살펴보기로 하겠다.

상황: A 사용자가 abc.txt 파일을 AD RMS 서버를 통해 암호화하여 B 사용자에게 abc.ptxt 파일로 전달해준다. 물론 읽기 권한을 부여한 정책 권한 템플릿을 이용해 파일을 암호화했으므로 B 사용자는 abc.ptxt 파일을 읽을 수만 있다. B 사용자는 abc.ptxt 파일을 받아 더블클릭해서 (IPViewer-Open) 열어볼 수 있는 권한이 있다.

1. A 사용자가 RMS 서버에 연결되어 DRM 서비스를 할 준비가 되어 있다면 A 사용자의 컴퓨터에는 다음의 DRM 캐시 파일들이 생성되어 있다.

CERT-Machine.drm

CERT-Machine-2048.drm (옵션)

CLC-{...}.drm

GIC-{...}.drm

keyfile3.drm

(폴더 위치: %LOCALAPPDATA%\Microsoft\MSIPC)

이상의 파일 다섯 개가 기본셋이다.

각 파일들에 대한 상세한 설명은 아래 URL을 참조하도록 하고...

>> 참조: http://technet.microsoft.com/en-us/library/cc747725(v=ws.10).aspx

여기서는 간략한 설명만 조금 덧붙여보자면,

실제 사용자에게 발급된 인증서는 "GIC-"로 시작하는 파일과 "CLC-"로 시작하는 파일이고,

keyfile3.drm 파일은 "GIC-" 파일과 한 쌍이 되는 개인키 파일이다.

"CERT-"로 시작하는 파일들은 컴퓨터 장치 인증서.

마지막 keyfile3.drm 파일을 제외하고 위 캐시 폴더에 있는 나머지 모든 파일들은 XrML 문서다. XrML 문서는 x.509v3 인증서 체인이 포함하고 있지 않은 배포, 권한 관리의 내용까지 포함하고 있는 XML 형태의 문서로, 일종의 인증서 체인 파일이라 생각하면 되겠다.

XrML 파일(유니코드)의 구조를 간략히 표시해보면 아래와 같다.

<XrML> 목적 인증서 </XrML>

( <XrML> 목적 인증서 발급자 인증서 </XrML> )

<XrML> 목적 인증서 발급 서버(AD RMS) 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] 발급 서비스 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] 발급 CA 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] CA 인증서 </XrML>

즉, 여러 개의 XrML 구성 섹션으로 나눠진 인증서 체인 파일이라 할 수 있다. (재밌는 것은, 이 인증서 체인에 포함되어 있지 않은 최상위 인증서, 즉 "Microsoft DRM [ISV 또는 Production] Root" 인증서는 이 인증서를 확인하는 서버인 AD RMS 서버에 의해 내부적으로 신뢰할 수 있는 루트 인증기관으로 설정되어 있을 것으로 짐작된다. PC에 기본 설치되어 있는 루트 인증기관 중에는 없으므로.)

실제 목적에 해당하는 내용은 첫 번째 XrML 구성 섹션에 다 들어있다. 두 번째 이하의 XrML 내용들은 첫 번째 인증서를 인증/신뢰할 수 있도록 해주기 위한 인증서 체인의 역할일뿐이다.

그런데, "CERT-"로 시작하는 파일은 인증서 체인의 내용이 다른 파일들과 조금 다르다. 해당 파일은 장치 인증서로, 아래와 같은 별도의 인증서 체인을 가지고 있다.

<XrML> 장치 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] 서버 사용 허가자 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] 장치 활성화 데스크톱 보안 프로세서 CA 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] 장치 활성화 서버 CA 인증서 </XrML>

<XrML> Microsoft DRM [ISV 또는 Production] CA 인증서 </XrML>

인증서 체인의 마지막 "Microsoft DRM ISV(또는 Production) CA 인증서"는 같은데, 중간에 들어있는 CA들이 차이가 있다.

...

인증서 체인에 대해서는 이 정도만 살펴보기로 하고 실제 파일 보호(암호화)를 하는 경우에 대해 살펴본다.

2. A가 RMS를 이용해서 abc.txt 파일을 읽기 전용 정책으로 보호(암호화)하여 abc.ptxt 파일을 생성했다.

이렇게 하면 A의 컴퓨터에 있는 DRM 캐시 폴더에 다음과 같은 새 파일이 하나 생성된다.

EUC-{...}-GIC-{...}-{...}.drm

위 파일을 열어서 살펴보면 CLC 인증서 주체(A 사용자)가 GIC 인증서 주체(A 사용자)에게 사용 허가한 내용이 들어있다. 즉, 본인이 스스로에게 사용 허가한 라이선스가 발급된 것이다. 그런데 그 아래 인증서 체인을 보면 AD RMS 서버가 해당 라이선스 인증을 인증해주었음을 의미하는 인증서 체인이 있고 GIC 인증서 주체(A 사용자)가 사용할 수 있는 암호화된 콘텐츠 키도 함께 저장되어 있음을 알 수 있다. 즉, 이 EUC 파일은 로컬에서 그냥 생성한 것이 아니고 AD RMS 서버를 통해 정보를 받아서 기록한 것이다.

그 과정을 조금 상세히 구분해서 살펴보면,

파일을 보호(암호화)할 때 파일 본문은 AES 대칭키 알고리즘으로 암호화하게 되는데,

일단 AES 대칭키 알고리즘의 콘텐츠 키를 생성하여 파일을 암호화하고,

해당 콘텐츠 키는 RMS 서버의 공개키로 암호화한 뒤

암호화된 파일과 암호화된 콘텐츠 키 둘 다 파일에 기록하여 파일을 생성한다.(해당 정보들은 abc.ptxt 파일 내에 XrML 형태로 저장된다.)

1. AES 콘텐츠 키 생성

2. abc.txt ----> AES 암호화 (with 콘텐츠 키) ----> abc.txt에 기록(덮어쓰기)

3. 콘텐츠 키 ----> AD RMS 서버 공개키로 암호화 ----> 암호화 된 콘텐츠 키 ----> abc.txt에 기록(업데이트)

4. abc.txt ----> abc.ptxt 확장자 변경

그런 다음 AD RMS 서버로 파일 게시를 요청하면서

해당 암호화된 콘텐츠 키를 전송하는 것으로 CLC 인증서 주체로서의 역할은 끝난다.

(물론 이때 콘텐츠 키뿐만 아니라 해당 콘텐츠의 GUID, 파일 보호 주체(CLC) 등 여러 가지 다른 정보들도 함께 전송될 것이다.)

이 때, AD RMS 서버는 전달받은 정보들을 내부 데이터베이스에 저장해둔다.

5. 암호화 된 콘텐츠 키 전송 ----> AD RMS 서버 ----> DB 저장

3. 숨은 과정: abc.txt 파일을 암호화한 A 사용자 본인도 AD RMS로부터 EUL을 발급받아야 암호화된 abc.ptxt 파일을 보거나 제어할 수 있으므로 파일 보호 요청 후 즉시 아래의 4번 과정이 수행되어 EUL 파일이 생성된다.

4. B 사용자가 메일이나 기타 경로로 전달받은 abc.ptxt 파일을 더블클릭하여 IPViewer로 연다.

(이 단계 전에 B 사용자 역시 AD RMS 서버와 즉시 통신할 수 있는 준비가 되어 있어야 한다. 즉, B 사용자도 로컬 컴퓨터에 DRM 캐시 파일 기본셋 5개를 가지고 있는 상태여야 한다. 그렇지 않은 경우 정상적으로 파일이 열리지 않고 오류가 발생한다.)

그러면 B 사용자의 컴퓨터(AD RMS Client)는 abc.ptxt 파일에 대한 EUL(최종 사용자 라이선스)를 AD RMS 서버로 요청한다. (아마도 abc.ptxt 파일에 있는 GUID 정보 같은 것으로 요청할 듯)

6. abc.ptxt EUL 확인 ----> 없으면 AD RMS 서버로 요청

그러면 AD RMS 서버는 abc.ptxt 파일의 콘텐츠 키를 데이터베이스에서 찾아 꺼내어 서버 자신의 개인키로 복호화한 뒤 해당 요청 GIC 인증서 주체(B 사용자)의 공개키로 암호화한 뒤 전달해 주어 해당 암호화된 콘텐츠 키가 기록된 EUC 파일을 생성한다.

7. DB에서 콘텐츠 키 조회 ----> 서버 개인키로 암호화 된 콘텐츠 키 복호화

8. B 사용자의 GIC 공개키로 콘텐츠 키 암호화 ---> B 사용자에게 전달 --> EUC 파일 생성

B 사용자에게 abc.ptxt 파일을 열 수 있는 권한이 있으면 EUC 파일에서 암호화된 콘텐츠 키를 GIC 인증서 주체(B 사용자 본인)의 개인키인 keyfile3.drm을 이용하여 복호화하여 평문 콘텐츠 키를 얻고 이를 이용하여 abc.ptxt 파일을 복호화하여 B 사용자가 원래 문서인 abc.txt 파일의 내용을 볼 수 있다.

9. GIC 개인키로 콘텐츠 키 복호화 ----> AES 복호화 (with 콘텐츠 키) ----> abc.txt 원문

끝.

부가 지식.

여기서 좀 재미있는 것은, 예를 들어 .xml 파일을 암호화하여 전달한 뒤 받은 .xml.pfile을 열어서 보면 원본 .xml 파일이 웹 브라우저로 열리는데, 이때 경로가 %LOCALAPPDATA%IPViewerTempFile\{랜덤폴더}\{원본파일}.xml 이 된다는 것을 알 수 있다. 해당 경로로 가서 생성되어 있는 파일을 복사하면 원래 권한이 읽기 전용이든 뭐였든 간에 원본 파일을 얻을 수 있게 되는 것이므로 권한 제어가 별 의미가 없어진다는 점? 이건 좀 보안상 문제가 있을 듯... 그래서 오피스나 PDF 문서처럼 자체 프로그램 내에서 암호화된 파일을 처리할 수 있어야 제대로 된 의미에서의 권한 제어가 될 것 같다는 생각.

위에 나열한 DRM 암/복호화 진행 흐름은, 실제 파일을 암/복호화해보면서 "대충" 분석해본 것이기 때문에 실제와 다를 수 있음.

절대로 위에서 말한 대로 100% 된다는 것을 보장할 수는 없으니 "참고"만 하시기 바람.