EncFS
| 개발자 | 발리앙 고흐 |
|---|---|
| 최종 버전 | 1.9.5
/ 2018년 4월 27일[1] |
| 저장소 | |
| 운영 체제 | 리눅스, FreeBSD, macOS,[2] Windows ("encfs4win" port)[3] (또한 Safe, macOS, Windows의 대안 포트) 및 안드로이드 앱 |
| 대체된 소프트웨어 | gocryptfs [4] |
| 종류 | 파일 시스템, 암호화 |
| 라이선스 | LGPL |
| 웹사이트 | EncFS 홈 |
EncFS는 자유 (LGPL) FUSE 기반의 암호화 파일 시스템이다. 임의의 디렉터리를 암호화된 파일을 위한 저장 공간으로 사용하여 파일을 투명하게 암호화한다.[5][6]
EncFS 파일 시스템을 마운트하는 데 두 개의 디렉터리가 관여한다: 원본 디렉터리와 마운트 지점. 마운트 지점의 각 파일은 원본 디렉터리에 해당하는 특정 파일을 갖는다. 마운트 지점의 파일은 원본 디렉터리에 있는 파일의 암호화되지 않은 보기를 제공한다. 파일 이름은 원본 디렉터리에서 암호화된다.
파일은 볼륨 키를 사용하여 암호화되며, 이 키는 암호화된 원본 디렉터리 내부에 또는 외부에 저장된다.[7] 이 키를 해독하는 데 비밀번호가 사용된다.
EncFS는 개발자인 발리앙 고흐가 2024년 5월 GitHub 페이지에서 더 이상 업데이트 없이 휴면 상태라고 선언했다. 그는 대신 gocryptfs를 사용하는 것을 권장한다.[4]
일반적인 용도
[편집]- 리눅스에서 eCryptfs의 대안으로 홈 폴더 암호화를 허용한다.
- 클라우드 스토리지 (Dropbox, 구글 드라이브, 원드라이브 등)에 저장된 파일 및 폴더의 암호화를 허용한다.
- 이동식 디스크에 있는 파일 폴더의 휴대용 암호화를 허용한다.
- 교차 플랫폼 폴더 암호화 메커니즘으로 사용 가능하다.
- 2단계 인증 (2FA)을 추가하여 저장 보안을 강화한다. EncFS 볼륨 키가 암호화된 원본 디렉터리 외부에, 실제 암호화된 데이터와 물리적으로 분리된 위치에 저장될 경우, 2단계 인증 (2FA)을 추가하여 보안이 크게 향상된다. 예를 들어, EncFS는 각 고유 볼륨 키를 실제 암호화된 데이터가 아닌 USB 플래시 드라이브, 네트워크 마운트, 광 디스크 또는 클라우드와 같은 다른 어떤 곳에도 저장할 수 있다.[7] 이 외에도 이 볼륨 키를 해독하는 데 비밀번호가 필요할 수 있다.
장점
[편집]EncFS는 각 파일이 호스트의 디렉터리 트리의 다른 곳에 암호화된 파일로 개별적으로 저장된다는 이유만으로 다른 디스크 암호화 소프트웨어에 비해 몇 가지 장점을 제공한다.
교차 플랫폼
[편집]EncFS는 여러 플랫폼에서 사용할 수 있는 반면, eCryptfs는 리눅스 커널에 종속된다.
비트 부패 감지
[편집]EncFS는 기본 파일 시스템 위에 비트 부패 감지 기능을 구현한다.
확장 가능한 저장 공간
[편집]EncFS는 고정된 크기를 차지하는 "볼륨"이 없으며, 마운트 지점에 파일이 추가되거나 제거됨에 따라 암호화된 디렉터리가 늘어나고 줄어든다.
일반 파일 서버
[편집]EncFS의 암호화된 디렉터리는 일반 파일 서버(NFS, SSHFS 등)에 위치할 수 있으며, Rsync와 같은 일반 파일 시스템 도구를 사용하여 효율적으로 미러링 및 백업할 수 있다.
다른 물리적 장치
[편집]원본 디렉터리의 하위 디렉터리 중 하나에 파일 시스템이 마운트된 경우, 마운트 지점의 일부 디렉터리가 다른 물리적 장치에 존재할 수 있다.
더 빠른 백업
[편집]백업 유틸리티는 원본 디렉터리에서 변경된 파일만 백업할 수 있다(파일 동기화, 클라우드 스토리지).
손상 감소
[편집]데이터 손상이 더욱 격리된다. 파일 데이터 손상은 단일 파일에 국한되며, 파일 시스템의 데이터 손상은 fsck와 같은 신뢰할 수 있는 파일 시스템 복구 유틸리티로 수정할 수 있다. 일부 전체 디스크 암호화 시스템은 이러한 속성 중 하나 또는 둘 다를 가지고 있지 않다.
최적화
[편집]파일 수정 사항이 기본 파일 시스템에 반영되므로, 전체 디스크 암호화와 달리 운영 체제의 다양한 최적화가 여전히 가능하다. 예를 들어, 해제된 공간에 대한 정보(TRIM)를 전달하면 SSD 드라이브의 성능을 향상시킬 수 있다. 하지만 이는 dm-crypt에서도 지원된다.
임의 파일 접근
[편집]파일에 임의로 접근할 수 있다. 예를 들어, 매우 큰 암호화된 비디오 파일 전체를 해독하지 않고도 중간으로 건너뛸 수 있다.
단점
[편집]EncFS를 사용하는 데에는 몇 가지 단점이 있다.
호환성
[편집]마운트된 EncFS 디렉터리는 원본 디렉터리를 포함하는 파일 시스템과 동일한 기능 및 제한 사항을 공유한다.
매우 긴 파일 이름에 대한 지원 없음
[편집]암호화 때문에 EncFS가 생성하는 암호화된 파일의 파일 이름은 원래 파일 이름보다 길다. 따라서 파일 시스템이 지원하는 최대 길이에 가까운 파일 이름은 암호화 후 길이 제한을 초과하므로 EncFS에 저장할 수 없다. 대부분의 파일 시스템은 파일 이름을 255바이트로 제한한다. 이 경우 EncFS는 최대 190바이트의 파일 이름만 지원한다.[8][9]
일반적인 보안 문제
[편집]원본 디렉터리에 접근할 수 있는 사람은 누구든지 암호화된 파일 시스템에 파일이 몇 개 있는지, 파일 권한, 대략적인 크기, 마지막 접근 또는 수정 시간을 볼 수 있지만, 파일 이름과 파일 데이터는 암호화되어 있다.[10]
EncFS 1.7 보안 문제
[편집]2014년 2월에 유료 보안 감사가 수행되었으며, 몇 가지 잠재적 취약점이 발견되었다. 결론은 다음과 같다.[11]
EncFS는 공격자가 암호문 사본 하나만 얻고 그 이상은 얻지 못하는 한 아마 안전할 것이다. EncFS는 공격자가 서로 다른 시간에 암호문의 두 개 이상의 스냅샷을 볼 기회가 있다면 안전하지 않다. EncFS는 악의적인 수정으로부터 파일을 보호하려고 하지만, 이 기능에 심각한 문제가 있다.
EncFS 1.8 보안 문제
[편집]EncFS 1.8 발표에는 이전 감사에서 제기된 보안 문제를 인정한 몇 가지 근본적인 설계 변경 사항이 포함되었다. 그러나 이러한 취약점에 대한 특정 우려 사항은 여전히 남아 있다.[12]
파일 시스템 옵션
[편집]새 EncFS 볼륨을 생성할 때, 다양한 요구에 맞게 파일 시스템을 사용자 정의할 수 있는 여러 옵션이 제공된다.
암호화 알고리즘
[편집]EncFS는 시스템의 다양한 암호화 라이브러리에서 찾을 수 있는 모든 암호를 사용한다. 블로피시와 AES가 일반적으로 사용 가능하다.
가변 키 길이를 지원하는 암호에 대해 암호화 키 길이(keySize)를 선택할 수 있다.
블록 크기
[편집]각 파일은 블록 단위로 암호화되며, 이 옵션은 블록의 크기를 제어한다. 단일 바이트가 읽힐 때마다 해당 블록 전체가 해독되어야 한다. 마찬가지로, 각 쓰기 작업에 대해 블록은 해독되고, 변경되고, 다시 암호화되어야 한다.
대부분의 목적에는 기본 블록 크기인 1024가 충분하다.
파일 이름 인코딩
[편집]원본 디렉터리의 파일 이름은 일반 또는 블록 또는 스트림 모드로 암호화될 수 있다. 블록 모드는 파일 이름 길이를 다소 가리지만, 스트림 모드는 가능한 한 짧게 유지하므로 파일 시스템이 디렉터리 트리를 관리하는 방식에 따라 원본 디렉터리의 파일 시스템에서 공간을 절약할 수 있다.
파일 이름 IV 체이닝
[편집]활성화되면 파일 이름 암호화를 위한 초기화 벡터가 파일의 상위 디렉터리에서 파생되어, 같은 이름을 가진 두 파일(다른 디렉터리에 있지만)이 다른 암호화된 파일 이름을 갖게 된다.
디렉터리 이름이 변경되면 그 안에 포함된 모든 파일과 디렉터리의 암호화된 파일 이름을 다시 암호화해야 하며, 이는 비용이 많이 드는 작업이 될 수 있다. 이 옵션은 매우 많은 파일이 있는 디렉터리가 자주 이름이 변경될 경우 비활성화해야 한다.
파일당 IV 초기화 벡터
[편집]활성화되면 각 파일은 무작위 8바이트 초기화 벡터로 암호화되며, 이는 원본 디렉터리의 암호화된 파일 내부에 저장된다. 이 옵션이 비활성화되면 각 파일은 동일한 초기화 벡터로 암호화되어 볼륨 키를 해독하기 더 쉽게 만들 수 있다.
이 옵션을 활성화하면 파일당 추가 8바이트의 비용으로 파일 시스템이 더 안전해진다.
외부 IV 체이닝
[편집]파일 데이터 초기화 벡터가 파일 이름의 초기화 벡터 체인에서 파생되도록 한다. 동일한 데이터는 다른 파일 이름이나 디렉터리가 주어지면 다르게 암호화된다.
결과적으로, 이 모드가 활성화된 상태에서 파일 이름을 변경하려면 파일의 무작위 초기화 벡터가 파일 이름 초기화 벡터 체인의 변경 사항에 따라 오프셋되거나 데이터가 다시 인코딩되어야 한다. EncFS 개발자들은 후자가 특히 큰 파일의 경우 훨씬 빠르기 때문에 전자를 선택했다.
파일 이름에서 IV 헤더 체이닝
[편집]인코딩이 전체 경로 이름에 의존하도록 한다. 따라서 이름 변경이나 이동은 다시 인코딩을 의미한다. 하드 링크는 지원되지 않는다.
블록 MAC 헤더
[편집]각 암호화된 블록과 함께 체크섬을 저장하여 암호화된 파일의 손상 또는 수정을 EncFS가 감지하도록 한다. 체크섬(blockMACBytes)은 8바이트이며, 선택적으로 최대 8바이트의 추가 임의 데이터(blockMACRandBytes)를 각 블록에 추가하여 동일한 암호화되지 않은 데이터를 가진 두 블록이 동일한 체크섬을 갖는 것을 방지할 수 있다. 이 옵션은 CPU 오버헤드가 많이 발생하는데, 데이터가 읽히거나(무결성 확인) 쓰일 때마다(체크섬 업데이트) 각 블록의 체크섬을 계산해야 하기 때문이다.
같이 보기
[편집]각주
[편집]- ↑ “Releases - vgough/encfs”. 2018년 6월 11일에 확인함 – GitHub 경유.
- ↑ “Valient Gough”. 《Valient Gough》. 2018년 4월 23일에 확인함.
- ↑ “encfs4win - an experimental project of porting encfs to the Windows world”. 2011년 7월 4일에 원본 문서에서 보존된 문서. 2013년 11월 29일에 확인함.
- ↑ 가 나 “README.md - vgough/encfs” (영어). 《GitHub》. 2025년 4월 13일에 확인함.
- ↑ Falko, Timme (2017년 1월 14일). “How to Encrypt your Data with EncFS on Debian 8 (Jessie)”. 《The Linux Foundation》. 2017년 4월 13일에 확인함.
- ↑ Falko, Timme (2016년 5월 6일). “Encrypt your Data with EncFS on Ubuntu 16.04”. 《The Linux Foundation》. 2017년 4월 13일에 확인함.
- ↑ 가 나 Gough, Valient (2016년 12월 26일). “ENVIRONMENT VARIABLES” (영어). 《GitHub》. 2017년 5월 7일에 확인함.
- ↑ “Issue #7 - alternative filename storage for very long filenames”. 《github.com》. 2014년 8월 22일. 2016년 1월 27일에 확인함.
Long filenames can exceed the filesystem limits after encryption & encoding.
- ↑ “Manpage for enfs.1”. 《manpages.ubuntu.com》. Ubuntu. 2016년 2월 3일에 원본 문서에서 보존된 문서. 2016년 1월 27일에 확인함.
If your underlying filesystem limits you to N characters in a filename, then EncFS will limit you to approximately 3*(N-2)/4. For example if the host filesystem limits to 256 characters, then EncFS will be limited to 190 character filenames. This is because encrypted filenames are always longer than plaintext filenames.
- ↑ “EncFS Directory Encryption Notes”. 2016년 10월 3일에 원본 문서에서 보존된 문서. 2015년 6월 8일에 확인함.
- ↑ “EncFS Security Audit”.
- ↑ “EncFS 1.8 Announcement”.