파일 시스템 암호화

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 검색

파일 시스템 암호화 (EFS: Encrypting File System)는 마이크로소프트 윈도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
Mixed (AES, SHA, and 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 (1 May 2008). 2011년 8월 24일에 확인.
  5. Cryptographic Filesystems, Part One: Design and Implementation. Security Focus. 2010년 1월 11일에 확인.
  6. Encrypting File System.
  7. Chris Corio (2006 May). First Look: New Security Features in Windows Vista. 《TechNet Magazine》. Microsoft. 2006년 11월 6일에 확인.
  8. ntpasswd, available since 1997
  9. 역자 주: 공격당하기 이전 파일이라고 해서 안전한 것도 아니다. 강제로 파일의 복호화 정보영역을 갱신시켜 버리면 되기 때문이다.
  10. Microsoft website.
  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일). 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일). 2007년 11월 6일에 확인.
  14. Scott Field (2006 June). 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 May). How IT Works: Encrypting File System. 《TechNet Magazine》. Microsoft. 2009년 5월 22일에 확인.

외부링크[편집]