File System - NTFS (4)

이번 글에서는 이전 글에서 알아 봤던 MFT 엔트리 표준 속성을 제외한 나머지 다른 개념의 속성들을 알아 볼 것이다.

다른 속성들을 알아보기 전에 참고로 알아두어야 할 것이다. 바로 기준 MFT 엔트리와 비기준 MFT 엔트리 라는 개념이다.

기준 MFT 엔트리란, MFT 엔트리에는 속성이 65536개가 올 수 있는데 이 모든 속성의 헤더를 저장하려면 하나 이상의 MFT 엔트리가 필요하게 된다.

이런 경우 추가적인 MFT 엔트리가 필요한데 추가적으로 MFT 엔트리가 파일이나 디렉토리에 할당 될 시 기존에 할당되어 있던 MFT 엔트리가 기준 MFT 엔트리가 된다.

자연스레 원본 MFT 엔트리가 아닌 추가적으로 할당 된 MFT 엔트리가 비기준 MFT 엔트리가 되는 것을 짐작 했을 것이다.

기준 MFT 엔트리에는 하나의 $ATTRIBUTE_LIST 속성이 있고, 해당 속성은 파일의 속성과 MFT 주소가 있는 목록을 포함한다.

* 참고 : 비기준 MFT 엔트리는 $FILE_NAME 과 $STANDARD_INFORMATION 속성이 없다.

이제 간단히 개념을 알았으니 다른 속성들을 하나씩 살펴보자.

[스파스 속성]
스파스 속성은 FAT 파일시스템 글에서도 다룬 적이 있다. 간단히 말하면 압축 기능 중 하나인데, 파일에 0으로 채워진 클러스터를 제외하고 디스크에 기록하는 기능이다. NTFS에서도 이 기능을 속성으로 지원하는데 NTFS에서는 $DATA 속성 값을 이 속성으로 정의하여 하나의 파일을 압축한다. 하지만 FAT 파일시스템과는 조금 다르게 제외된 0으로 채워진 클러스터를 위해 runlist에 0으로 채워진 클러스터에 대한 run 을 하나 생성한다.
기본적으로 run 은 시작 클러스터 위치와 크기를 포함하지만, 0으로 채워진 클러스터를 위해 생성된 run은 데이터로 크기만 가질 뿐 시작 위치는 포함하지 않는다. 또, 0으로 채워진 클러스터를 위한 run이라는 것을 표시하기 위한 플래그 값도 포함한다. 이러한 run은 sparse run 이라고 부른다.
아래는 run과 sparse run을 보기 쉽게 그림으로 표현 한 것이다.

 [그림 1 - Sparse run]

 * 참고 : RunList는 스파스 속성 클러스터의 RunList 이다. 

 

[속성의 압축]
NTFS에서 속성을 압축하는 알고리즘은 아직 공개되지 않았다. 하지만 이 부분에서는 그나마 정확하게 알려진 정보를 설명하려고 한다. NTFS에서 지원하는 속성 압축은 파일시스템 수준의 압축으로 $DATA 속성이 비거주 속성 일 때만 압축 할 수 있다. 위에서 설명한 스파스 속성도 속성 압축을 위한 기능 중 하나이다. 속성이 압축 되었는지 판단하는 것은 속성 헤더이며, $STANDARD_INFORMATION, $FILE_NAME 속성의 플래그는 해당 파일이 압축된 속성을 포함하였는지 판단하도록 정보를 제공한다. 
속성 내용이 압축되기 전에 속성 내용은 압축 유닛이라는 같은 크기의 단위로 나뉘게 된다.

 * 참고 : 압축 유닛의 크기는 속성 헤더에서 결정한다.

압축 유닛이 생성 될 때 발생 할 수 있는 경우가 3가지 정도 있는데 이는 아래와 같다. 

 - Spase run이 압축 유닛 크기로 만들어지는 경우, 모든 클러스터는 0을 포함하게 되고 디스크 공간에 할당되지 않는다.
 - 압축 될 때 압축 결과는 저장을 위한 같은 수의 클러스터가 필요한데, 이 경우 압축 유닛은 압축 되지 않고 하나의 run이 원본 데이터로 만들어진다.
 - 압축 될 때 압축 결과는 적은 양의 클러스터를 사용한다. 이 경우 압축 결과를 디스크에 run으로 압축하고 저장하는데, sparse run은 전체 run 길이와 압축 유닛에 클러스터 수를 같도록 하기 위해 압축된 run 뒤에 위치하게 된다.  

[속성의 암호화]
NTFS는 속성을 압축하는 기능뿐만 아니라 암호화 하는 기능도 있다. OS별로 보았을 때 윈도우를 제외한 OS는 여러가지의 속성을 암호화 할 수 있고 윈도우는 $DATA의 속성만을 암호화 한다.
암호화 시 속성 헤더를 제외하고 속성 내용만 암호화가 된다. $LOGGED_UTILITY_STREAM 속성이 암호화된 파일을 복호화하기 위해서 사용하는 복호화 키를 포함한다.
NTFS에서는 암호화 알고리즘으로 3DES 알고리즘을 사용한다. 간단히 말해 3DES 알고리즘은 대칭 알고리즘으로 DES를 연속으로 3번 적용한 알고리즘이라고 생각하면 된다.
복호화 할 때 사용되는 난수 키는 암호화된 각 MFT 엔트리를 위해 생성되며, NTFS 에서는 FEK(File Encryption Key)로 불린다. 만약 MFT 엔트리에 여러개의 $DATA가 있다면, 그것들은 모두 같은 FEK로 암호화 되는 것을 뜻한다.
FEK는 $LOGGED_UTILITY_STREAM 속성에 암호화 된 상태로 저장이 되는데, 해당 속성은 DDF(Data Decryption Fields)와 DRF(Data Recovery Fields)의 목록을 포함한다. DDF는 해당 파일에 접근하려는 모든 사용자를 위해 생성되는 것이며, 포함하는 데이터로는 사용자 SID, 암호화 정보, 사용자의 공개 키로 암호화 된 FEK를 포함한다.  
DRF는 데이터 복구를 위해 생성 되는 것이며, 데이터 복구 공개 키로 암호화 된 FEK를 포함한다.
아래는 암호화 과정을 보기 쉽게 그림으로 표현 한 것이다.

 [그림 2 - 암호화 과정]

암호화가 되었다면 해당 내용을 사용자에게 보여주기 위해서는 복호화가 이루어져야 한다.
복호화 과정은 암호화 된 FEK가 포함되어 있는 $LOGGED_UTILITY_STREAM을 참조하고, 참조하여 얻은 FEK를 사용자 공개 키로 복호화 하여, 복호화 된 FEK를 $DATA 속성 내용 복호화하는 것이다.

 * 참고 : 사용자 공개 키는 레지스트리 저장되며, 해당 키는 로그인 패스워드를 키로 하는 대칭 알고리즘으로 암호화 되어 있다.

아래는 복호화 과정을 그림으로 표현 한 것이다.

[그림 3 - 복호화 과정]

대부분의 보안 도구들이 이러한 암호화를 풀기 위하여 무작위 대입 공격등을 시도하는 기능들이 들어있다.
하지만 성공률은 시간에 따라 달라 오래 걸릴 수도 있고 짧게 걸릴 수도 있어 무조건적인 신뢰는 하지 않는 것이 좋다.
일부 디렉토리들과 파일들이 암호화 되어 있다면 암호화 되지 않은 파일 내용의 복사본이 어느 비 할당 어딘가에 존재 할 수도 있다. NTFS 설계상의 취약점이다.
위 문제로 인해 평문 파일 내용이 저장된 EFS0.TMP 임시파일이란 것이 생성되고, 이 파일은 MFT 엔트리가 재 할당 되지 않았다면 충분히 복구가 가능하다.
또 Swap 공간이나 페이지 파일 또한 암호화 되지 않은 평문 내용의 복사본을 포함하기도 한다.
하지만 이럴 수고를 할 필요 없이 관리자나 도메인 컨트롤러, 해당 사용자 계정을 알고 있다면 바로 접근하고자 하는 암호화 파일에 접근하여 내용을 확인 할 수 있다.