암호화 파일 시스템

암호화 파일 시스템(Encrypting File System, EFS)은 마이크로소프트 윈도우NTFS 버전 3.0에서 추가된 파일 시스템 단계 암호화를 하는 기능이다. [1] 이 기술로 직접 컴퓨터에 접근하는 공격자로부터 간단하게 기밀 파일을 암호화해 보호할 수 있다.

EFS는 윈도우 2000부터 현재까지 사업용으로 개발된 모든 버전의 윈도우에서 사용할 수 있다. [2] 기본적으로 모든 파일이 암호화되어있지 않지만, 사용자에 의해 파일, 폴더, 드라이브단위로 암호화될 수 있다. [3] 일부 EFS 설정은 윈도우 서버 도메인환경의 그룹 정책으로 관리할 수 있다. [4]

다른 운영 체제의 파일 암호화 시스템 구현은 가능하지만, 마이크로소프트 암호화 파일 시스템은 다른 것들과 호환되진 않는다. [5] 파일 암호화 시스템 목록을 참고하라.

기본 개념 편집

파일 암호화 없이 운영 체제가 구동 중이면, 파일을 열 때 운영 체제가 사용자 인증접근 제어 목록확인을 한다. 하지만 공격자가 직접 컴퓨터를 조작할 수 있다면 이런 보호는 쉽게 피할 수 있다. 예를 들어 디스크를 빼서 그 파일 시스템을 볼 수 있는 운영 체제를 설치한 다른 컴퓨터에 끼우거나, 그 파일 시스템을 읽을 수 있는 운영 체제를 포함한 CD로 부팅하여 손쉽게 파일 시스템에 접근할 수 있다.

이 경우 가장 타당하다고 인정받는 대책은 암호화된 저장장치(하드 디스크, USB메모리, 테이프, CD 등)에 파일을 보관하는 것이다.

마이크로소프트 윈도우 제품군에서는 이 대책으로 EFS를 쓸 수 있다. NTFS 드라이브만 지원하는 게 흠이지만 공개 키 암호 방식대칭 키 암호 방식을 조합해 쓰면 알맞은 키 없이 파일을 복호화하기 매우 어려워진다.

하지만 사실상 사용자 계정 비밀번호가 EFS 암호화 키를 보호하기 때문에 대부분의 비밀번호 공격에 취약하다. 다시 말해 EFS 암호화는 사용자 계정 비밀번호만큼만 강력하다.

동작 편집

 
암호화 파일 시스템 동작 원리

EFS는 파일을 파일 암호화 키(FEK: File Encryption Key) 라고 부르는 임의의 대칭 키로 암호화한다. 파일을 암호화 하는데 대칭 키 암호 방식을 사용하는 이유는 비대칭 암호 방식보다 암호화·복호화가 빠르기 때문이다. 대칭 키 암호화 알고리즘은 운영 체제의 버전과 설정에 따라 바뀔 수 있다. 아래에 있는 #윈도우 버전에 따라 쓰이는 암호화 알고리즘을 참고하라.

파일 암호화 과정

파일을 파일 암호화 키(FEK: 파일을 암호화 할 때 쓰는 대칭 키)로 암호화한다. 이 FEK를 파일을 암호화한 사용자가 가진 공개 키로 암호화해 암호화된 파일의 $EFS 대체 데이터 스트림(ADS: Alternate Data Stream)에 저장한다. [6]

파일 복호화 과정

EFS 컴포넌트 드라이버가 (파일 암호화에 쓴) EFS 인증서에 맞는 개인 키로 $EFS 스트림에 저장된 암호화된 FEK를 복호화한다. 그 다음 암호화가 풀린 FEK 대칭 키로 파일을 복호화한다.

암호화와 복호화가 NTFS 단계 아래에서 이루어지기 때문에 사용자와 프로그램은 암호화된 파일을 일반 파일처럼 쓸 수 있다.

파일 시스템에서 폴더에 암호화 속성을 걸 수 있다. EFS 컴포넌트 드라이버는 이 암호화 속성을 NTFS의 권한 상속처럼 다룬다. 예를 들어 암호화 속성이 걸린 폴더가 있고 그 안에 새로운 파일이나 폴더를 만들면 기본적으로 모두 암호화가 걸린다. 암호화된 파일을 NTFS 볼륨 안에서 옮겨도 암호화 속성은 유지된다. 하지만 사용자가 윈도우에게 암호화를 풀라고 하지 않았는데도 암호화가 풀리는 일이 종종 있다.

EFS로 암호화된 파일이나 폴더를 FAT32같이 다른 파일 시스템으로 포맷된 볼륨으로 옮기는 경우 암호화가 풀리고, 암호화된 파일을 SMB/CIFS를 통해 파일을 복사할 때도 암호화가 풀린다. 즉 네트워크로 전송하는 파일은 전부 전송하기 전에 암호화가 풀린다.

"Raw"로 시작하는 API를 쓰면 복사할 때 암호화가 풀리는 걸 막을 수 있다. Raw API를 도입한 백업 프로그램은 암호화된 데이터와 $EFS ADS를 하나의 파일로 손쉽게 복사한다. 다시 말해 복호화 되지 않고 암호화된 상태 그대로 백업된다.

윈도우 비스타부터 사용자의 개인 키를 스마트 카드에 보관할 수 있다. 데이터 복구 에이전트(DRA: Data Recovery Agent)키도 스마트 카드에 보관할 수 있다. [7]

보안 편집

취약점 편집

윈도우 2000 EFS에 지금까지 다양하게 공격당한 2가지 취약점이 있다.

관리자 계정을 이용한 파일 복호화 편집

윈도우 2000에서, Administrator계정이 기본 데이터 복구 에이전트였다. 때문에 이 어드민 계정을 이용하면 모든 로컬 사용자가 암호화한 파일을 전부 복호화할 수 있었다. 윈도우 2000에선 EFS가 데이터 복구 에이전트 없이 동작할 수 없었고, 그래서 암호화된 파일엔 암호화를 풀 수 있는 사용자가 항상 있었다. 도메인에 가입하지 않은 윈도우 2000 컴퓨터는 Administrator계정을 이용한 허가받지 않은 EFS 복호화에 취약해졌다. 인터넷에 무수히 돌아다니는 툴들을 생각하면 사소한 문제이다. [8]

윈도우 XP이후로, 기본 데이터 복구 에이전트는 사라졌고 요구하지도 않게 되었다. 시스키(SYSKEY)를 2 또는 3 모드로 설정하면 (부팅 중에 눌리거나 플로피에 저장된 시스키) 관리자 계정을 통한 허가받지 않은 복호화 위험을 줄일 수 있다. 보안 계정 관리자에 저장되는 사용자의 비밀번호 해시가 시스키로 암호화되고, 그 시스키 값은 오프라인 공격자조차도 시스키 암호나 플로피가 없으면 알 수 없기 때문이다.

패스워드 초기화를 통한 개인 키 획득 편집

윈도우 2000에선, 사용자의 RSA 개인 키를 정말로 암호화해 저장했지만, 그 개인키의 백업을 허술하게 보관하고 있다. 만약 공격자가 윈도우 2000 컴퓨터에 물리적으로 접근해서 사용자 계정의 비밀번호를 초기화시켜 버리면[8] 공격자는 그 계정으로 (혹은 데이터 복구 에이전트 계정으로) 로그인해서 개인 키를 획득해 모든 파일들을 복호화할 수 있다. 이건 사용자들의 RSA 개인 키 백업이 LSA 인증으로 암호화되기 때문에 LocalSystem계정으로 로그인할 수 있는 공격자가 접근할 수 있었기 때문이다 (다시 말하지만, 인터넷의 수많은 툴들에 비하면 사소하다).

윈도우 XP이후로 사용자의 RSA 개인 키는 짝이 되는 공개 키로 암호화해 암호 재설정 디스크(윈도우 XP가 도메인 멤버가 아닌 경우)나 액티브 디렉터리(윈도우 XP가 도메인 구성원인 경우)에 백업된다. 이로 인해 윈도우 XP에 LocalSystem계정으로 인증할 수 있더라도 컴퓨터 하드 드라이브에 있는 복호화 키를 얻을 수 없다.

윈도우 2000이후로 사용자의 RSA 개인 키는 사용자의 NTLM 비밀번호 해시와 사용자 이름이 합치진 값의 해시로 암호화한다. 이런 설트기법을 사용한 해시는 사용자의 비밀번호를 알지 못하는 이상 역과정을 통해 개인 키를 알아내기 무척 어렵게 만들었다. 또 다시 말하지만, 시스키를 2 또는 3 모드로 설정(부팅 중에 눌리거나 플로피에 저장된 시스키)하는 것은 사용자의 비밀번호 해시가 암호화된 보안 계정 관리자 파일에 저장되게 해서 이 공격을 다소 방어할 수 있다.

기타 사항 편집

사용자가 한번 로그인하면, 그 사용자는 자신의 EFS 암호화된 파일에 추가적인 인증없이 그냥 파일을 읽을 수 있다. 즉, 계정 비밀번호만 알려주면 암호화된 파일도 읽을 수 있게 된다. 기본적으로 동작하지는 않지만 윈도우는 사용자 계정 비밀번호를 해독 가능한 암호화로 저장할 수 있다. 사용자 계정 비밀번호의 랜 관리자 해시를 그런 방식으로 저장할 수도 있고(초기버전의 윈도우 XP 이하 버전에서는 기본 동작이었다) 이것은 쉽게 뚫릴 수 있었다. 이 랜 관리자 해시처럼 계정 비밀번호를 저장할 수 있고, 비밀번호가 약하면 레인보우 테이블을 이용한 공격으로 쉽게 뚫릴 수 있다(윈도우 비스타 이후로는 기본적으로 약한 비밀번호를 허용하지 않는다). 구버전의 윈도우에서 EFS를 제대로 활용하기 위해서는 무차별 대입 공격을 막기 위해 랜 관리자 해시를 저장하지 않도록 해야 한다(그룹 정책의 보안 설정에서 설정할 수 있다). 물론 자동 로그인을 해제하는 것은 기본이다(이건 레지스트리에 계정 비밀번호를 평문으로 저장하게 만든다). 더 나아가면, 14글자를 초과한 사용자 계정 비밀번호를 사용하면 윈도우가 랜 관리자 해시를 보안 계정 관리자에 저장하는 것을 막을 수 있고 무차별 대입 공격을 막는데도 도움이 된다.

EFS를 사용해서 파일을 변환할 때(원본파일을 EFS암호화 파일로 변환하는 경우) 원본파일이 지워지지 않고 디스크에 남아있을 수 있다. 파일을 덮어쓰는 게 아니라 새로 암호화한 파일을 만들고 원본 파일을 삭제하기 때문에 발생하는 문제인데, 이 때문에 TRIM 기능을 지원하는 SSD가 아닌 한 지워진 파일을 복구하면 원본파일을 복구할 수 있다. 이걸 활용하는 공격방법을 방지하기 위해 EFS를 폴더단위로 적용하는 게 좋다(워드프로세서를 사용할 때 생기는 임시파일들까지 암호화되게 한다거나). 정 하나의 파일만 암호화하고 싶으면 파일을 암호화한 후 cipher 프로그램의 /w 옵션을 이용해서 빈 공간을 밀어버릴 수도 있다. 비슷한 서드 파티 프로그램들을 써도 좋다.

관리자계정을 가진 누구나 데이터 복구 에이전트 설정을 덮어쓰거나, 무시하거나 바꿀 수 있다. 이건 매우 심각한 문제인데, (서드 파티 도구를 사용해) 관리자 계정을 획득한 공격자가 데이터 복구 에이전트 인증서를 설정해놓고 기다리는 수가 있다. 두 단계의 공격이라고 언급되기도 하는데, PC가 도난당한 경우와는 다른 점이 내부의 악의적인 사용자가 몰래 데이터를 꺼내갈 수 있다는 것을 말해주기 때문이다.

사용자가 첫 번째 공격(인증서 삽입)을 당한 후에 파일을 암호화하면 [9] 파일 암호화키가 삽입된 데이터 복구 에이전트 공개 키로도 암호화되어 저장된다. 나중에 사용자가 비밀번호를 바꾸더라도 공격자가 디스크 파일에 직접 접근만 할 수 있으면 가지고 있는 데이터 복구 에이전트 개인 키로 얼마든지 파일을 열어볼 수 있다. 때문에 시스키 모드 2나 3도 이건 어쩔 수 없다. 물론 그런 공격자가 내부에 있다면 모든 보안 고려가 의미없긴 하다. 이런 공격방법보다 루트킷이나 하드웨어 키로거를 심으면 더 편리하고 효과적이기 때문이다.

복구 편집

EFS로 암호화된 파일은 파일을 암호화한 공개 키에 맞는 개인 키가 있어야만 복호화할 수 있다. 그리고 사용자의 개인 키는 계정 비밀번호로 보호되고 있다. 다른 운영 체제(리눅스라든가)에서 암호화된 파일에 접근하는 건 불가능하다. 적어도 서드 파티 EFS 드라이버가 없어서라는 이유가 있다.

사용자의 비밀번호를 초기화시키는 툴을 쓰면 사용자의 개인 키를 해독할 수 없게 돼서 파일에 접근할 수 있는 권한을 얻더라도 파일이 무용지물이 된다. 이런 특징은 "잠재적인 휴지통"이란 말을 만들었는데, 단적인 예로 미숙한 사용자가 비밀번호를 잊어버려서 비밀번호 초기화 툴을 검색해서 사용하곤 암호화한 모든 파일을 영영 복구할 수 없는 것을 알게되는 경우가 있기 때문이다. 이런 경우는 개인 키를 따로 백업해두지 않은 이상 복구할 방법이 없다.

만약 EFS가 공개 키 기반 구조에서 발급받은 키를 사용하고 있고 거기서 키 보관 및 복구를 지원하면 개인 키를 복구해서 암호화된 파일을 복구할 수 있다.

키 종류 편집

  • 사용자 비밀번호 (혹은 스마트 카드 개인 키): 사용자의 DPAPI 마스터 키를 복호화할 키를 만드는 데 쓴다
  • DPAPI 마스터 키: 사용자의 RSA 개인키를 복호화하는 데 쓴다
  • RSA 개인 키: 암호화된 각각의 파일 암호화 키를 복호화하는 데 쓴다
  • 파일 암호화 키(FEK): 파일의 데이터를 암호화/복호화하는 데 쓴다 (NTFS 스트림 맨 앞에 있다)
  • 시스키(SYSKEY): 캐싱된 도메인 확인자와 보안 계정 관리자에 저장된 비밀번호 해시를 암호화하는 데 쓴다

지원되는 운영 체제 편집

윈도우 편집

다른 운영 체제 (리눅스 등) 편집

EFS파일을 iSCSI를 통해 다른 디스크 형식을 쓰는 (리눅스같은) 다른 운영 체제에 저장하는 것이 가능하다. EFS를 제어하고 구현하는 API가 윈도우에 맞춰져있는 반면에 (또한 EFS 자체도 NTFS에 종속되어있다) iSCSI를 쓰면 가상 NTFS 볼륨을 네트워크 드라이브로 쓸 수 있다 (리눅스에서는 ext3으로 쓸 수 있을 것이다). 윈도우에서 iSCSI 클라이언트(내장되어있다)를 쓰고 iSCSI를 지원하는 리눅스가 있다면, 원격 네트워크 장치에서 호스팅하는 iSCSI 가상 드라이브를 만들고 NTFS로 포맷한 다음 EFS 암호화된 폴더나 파일을 저장할 수 있다. 윈도우가 iSCSI 가상 드라이브를 로컬 디스크로 간주하기 때문에 (이전에 말한) Raw API를 쓰는 백업 프로그램을 쓸 때처럼 모든 데이터가 복호화되지 않고 그대로 네트워크로 전송되어 리눅스에 암호화된 채로 저장된다. iSCSI를 쓰면 EFS암호화한 파일들이 온전히 리눅스 기반 장치에 보관될 수 있다.

윈도우 버전마다 추가된 기능들 편집

윈도우 XP
  • 클라이언트측 캐시의 암호화 (오프라인 파일 데이터베이스)
  • 도메인 범위 공개 키를 사용한 데이터 보호 API 마스터 키 백업 보호
  • 사용자 인증서 자동등록 (EFS 인증서 포함)
  • 암호화된 파일마다 다중 사용자 접근기능(즉, 사용자까리 공유가능), 공유할 때 사용하는 인증서가 무효한지 확인하는 기능
  • 암호화된 파일을 다른 색으로 표시 됨(기본적으로 초록색)
  • 복구 에이전트를 꼭 만들지 않아도 됨
  • 지원하지 않는 파일시스템으로 파일을 옮겨 은연중에 복호화될 때 경고하는 기능
  • 비밀번호 초기화 디스크
  • WebDAV를 통한 EFS와 액티브 디렉터리를 쓰는 서버를 위한 원격 암호화
윈도우 XP SP1
윈도우 XP SP2 + KB 912761
  • 자체 서명 인증서의 등록 방지
윈도우 서버 2003
  • Digital Identity 관리 서비스
  • 자체 서명 인증서를 등록할 때 RSA 최소 키 길이를 강제하는 설정
윈도우 비스타[11]와 윈도우 서버 2008

[12][13]

  • 유저마다 클라이언트 측 캐시 암호화 (오프라인 파일)
  • RSA개인 키를 PC/SC 스마트 카드에 저장 지원
  • EFS 재설정 마법사
  • EFS 키 백업 프롬프트
  • PC/SC 스마트 카드로부터 데이터 보호 API 마스터 키 얻어오기 지원
  • pagefile.sys의 암호화 지원
  • EFS와 관련된 정보들을 비트락커로 보호 (윈도우 비스타 엔터프라이즈, 얼티밋 에디션)[14][15]
  • 그룹 정책 적용이 가능한 항목:
    • 내 문서 폴더 암호화
    • 오프라인 파일 암호화
    • 암호화된 파일 색인
    • EFS에 스마트카드 요구
    • 스마트 카드로 캐싱이 가능한 사용자 키를 생성하기
    • 사용자 키를 만들거나 바꿨을 때 키를 백업해야 한다고 알려주기
    • 자동으로 EFS 인증서를 등록하는데 쓰는 틀을 지정
윈도우 서버 2008
[13]
  • 윈도우 서버 2008에 자체 서명된 인증서를 등록하면 기본적으로 RSA키 길이를 2048비트로 한다
  • 모든 EFS 틀은 (사용자와 데이터 복구 에이전트) 기본적으로 RSA키 길이를 2048비트로 한다
윈도우 7과 윈도우 서버 2008 R2[16]
  • 타원곡선 암호(ECC). 윈도우 7은 ECC알고리즘을 지원하고 호환성을 위해 RSA알고리즘도 지원한다.
  • 자체 서명된 인증서에서 타원곡선 암호를 쓸 때 기본적으로 256비트 키를 쓴다.
  • 자체 서명된 인증서를 쓸 땐 1024/2048/4096/8192/16384비트 키를 쓸 수 있고, ECC 인증서를 쓰면 256/384/521비트 키를 쓴다

윈도우 버전에 따라 쓰이는 암호화 알고리즘 편집

윈도우 EFS는 윈도우 버전에 따라 파일 암호화에 쓰는 다양한 대칭 암호화 알고리즘을 지원한다

운영 체제 기본 알고리즘 다른 알고리즘
윈도우 2000 DESX (없음)
윈도우 XP RTM DESX Triple DES
윈도우 XP 서비스 팩 1 AES Triple DES, DESX
윈도우 서버 2003 AES Triple DES, DESX[17]
윈도우 비스타 AES Triple DES, DESX
윈도우 서버 2008 AES Triple DES, DESX (?)
윈도우 7
윈도우 서버 2008 R2
혼합 (AES, SHA, ECC) Triple DES, DESX

같이 보기 편집

참고 문헌 편집

  1. “File Encryption (Windows)”. Microsoft. 2010년 1월 11일에 확인함. 
  2. EFS는 윈도우 2000 서버와 워크스테이션, 윈도우 XP 프로페셔널, 윈도우 서버 2003과 2008, 윈도우 비스타, 윈도우 7 비즈니스, 엔터프라이즈, 얼티밋에디션에서 사용할 수 있다. 윈도우 XP 홈 에디션이나, 윈도우 비스타윈도우 7의 스타터, 베이직, 홈 프리미엄 에디션에서는 EFS를 쓸 수 없거나 기능이 제한된다. 윈도우 9x계열의 운영 체제는 EFS의 기반인 NTFS를 지원하지 않기 때문에 구현조차 할 수 없다.
  3. 역자 주: 드라이브단위로 암호화된다는 건 좀 애매하다. 데이터 드라이브는 모든 폴더에 암호화를 걸면 그만이지만 운영 체제가 설치된 파티션의 경우 시스템 파일 암호화가 불가능하기 때문이다. 드라이브 단위의 암호화를 지원하는 건 비트락커같은 디스크 암호화다. “BitLocker 드라이브 암호화와 암호화 파일 시스템의 차이점”. Microsoft. 2013년 8월 27일에 확인함. 
  4. “Encrypting File System”. Microsoft. 2008년 5월 1일. 2011년 8월 24일에 확인함. 
  5. “Cryptographic Filesystems, Part One: Design and Implementation”. Security Focus. 2010년 1월 11일에 확인함. 
  6. “Encrypting File System”. 
  7. Chris Corio (2006년 5월). “First Look: New Security Features in Windows Vista”. 《TechNet Magazine》. Microsoft. 2006년 11월 10일에 원본 문서에서 보존된 문서. 2006년 11월 6일에 확인함. 
  8. “ntpasswd, available since 1997”. 2016년 2월 12일에 원본 문서에서 보존된 문서. 2016년 2월 12일에 확인함. 
  9. 역자 주: 공격당하기 이전 파일이라고 해서 안전한 것도 아니다. 강제로 파일의 복호화 정보영역을 갱신시켜 버리면 되기 때문이다.
  10. “Microsoft website.”. 2007년 2월 3일에 원본 문서에서 보존된 문서. 2013년 8월 29일에 확인함. 
  11. Kim Mikkelsen (2006년 9월 5일). “Windows Vista Session 31: Rights Management Services and Encrypting File System” (PDF). 《presentation》. Microsoft. 2007년 10월 2일에 확인함. [깨진 링크(과거 내용 찾기)] [깨진 링크]
  12. “Encrypting File System”. 《documentation》. Microsoft. 2007년 4월 30일. 2014년 1월 20일에 원본 문서에서 보존된 문서. 2007년 11월 6일에 확인함. {{
  13. “Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008: Encrypting File System”. 《documentation》. Microsoft. 2007년 9월 1일. 2008년 3월 25일에 원본 문서에서 보존된 문서. 2007년 11월 6일에 확인함. 
  14. Scott Field (2006년 6월). “Microsoft Windows Vista Security Enhancements” (DOC). 《whitepaper》. Microsoft. 2007년 6월 14일에 확인함. 
  15. Microsoft Corporation (2006년 11월 30일). “Data Communication Protocol”. 《patent》. Microsoft. 2007년 6월 14일에 확인함. 
  16. “Changes in EFS”. Microsoft TechNet. 2009년 5월 2일에 확인함. 
  17. Muller, Randy (2006년 5월). “How IT Works: Encrypting File System”. 《TechNet Magazine》. Microsoft. 2009년 5월 22일에 확인함. 

외부 링크 편집