지침

LUKS를 사용한 그럴듯한 거부성. 전체 디스크 암호화를 지원하는 Linux 부트 로더? 리눅스 암호화

08.09.2023

디스크(TrueCrypt와 유사). GRUB2에 암호화 지원을 추가하는 작업이 있었던 것으로 알고 있지만 아직 준비되지 않았습니다. 다른 옵션이 있나요?

(실제로 여기서는 /boot를 포함한 전체 디스크 암호화를 의미합니다.)

대부분의 답변은 /boot가 암호화되지 않은 설정을 설명하고 일부 답변은 암호화되지 않은 /boot가 괜찮은 이유를 설명하려고 합니다.

실제로 /boot를 암호화해야 하는 이유에 대한 논쟁을 시작하지 않고 GRUB2의 수정된 버전을 기반으로 필요한 것을 정확하게 설명하는 기사는 다음과 같습니다.

http://xercestech.com/full-system-encryption-for-linux.geek

문제는 이러한 수정 사항이 현재 GRUB2 코드 베이스에서 지원되지 않는 것 같다는 것입니다(또는 뭔가 빠졌을 수도 있습니다).

8 솔루션은 "전체 디스크 암호화를 지원하는 Linux 부트로더?"에 대한 양식을 웹에서 수집합니다.

현재 버전의 GRUB2는 자체적으로 LUKS 파티션 로드 및 암호 해독을 지원하지 않는 것 같습니다(일부 암호가 포함되어 있지만 암호 지원에만 사용되는 것 같습니다). 실험적인 개발 브랜치를 확인할 수는 없지만 GRUB 페이지에는 원하는 작업을 구현하기 위해 일부 작업이 계획되어 있다는 힌트가 있습니다.

업데이트(2015): 최신 버전의 GRUB2(2.00)에는 암호화된 LUKS 및 GELI 파티션에 액세스하기 위한 코드가 이미 포함되어 있습니다. (OP가 제공한 xercestch.com 링크에는 이에 대한 첫 번째 수정 사항이 언급되어 있지만 이제 최신 버전에 포함되어 있습니다.)

그러나 보안상의 이유로 전체 드라이브를 암호화하려는 경우 암호화되지 않은 부트로더(예: TrueCrypt, BitLocker 또는 수정된 GRUB)는 암호화되지 않은 /boot 파티션(SP에서 지적한 대로)보다 더 많은 보호 기능을 제공하지 않는다는 점에 유의하세요. 위 댓글에서). 컴퓨터에 물리적으로 접근할 수 있는 사람이라면 누구나 쉽게 사용자 정의 버전으로 교체할 수 있습니다. 귀하가 링크한 xercestech.com 기사에서도 언급되었습니다.

분명히 말하면, 이것이 시스템을 오프라인 공격에 덜 취약하게 만드는 것은 아닙니다. 공격자가 부트로더를 자신의 부트로더로 교체하거나 부트 프로세스를 리디렉션하여 자체 코드를 로드하는 경우 시스템이 여전히 손상될 수 있습니다.

암호화되지 않은 부트로더 또는 암호화되지 않은 부팅/사전 부팅 파티션을 사용하는지 여부에 관계없이 모든 전체 디스크 암호화 소프트웨어 제품에는 이러한 약점이 있습니다. BitLocker와 같이 TPM(Trusted Platform Module) 칩을 지원하는 제품도 하드웨어 변경 없이 구현할 수 있습니다.

더 나은 접근 방식은 다음과 같습니다.

BIOS 수준에서 암호 해독(TPM 칩 유무에 관계없이 마더보드, 디스크 어댑터 또는 외부 하드웨어[스마트 카드]에서) 또는
이동식 장치(예: 스마트 카드 또는 USB 드라이브)에 PBA(부팅 전 인증) 인증 코드(이 경우 /boot 파티션)를 휴대하세요.

두 번째 방법으로 이 작업을 수행하려면 http://lfde.org/에서 Linux 전체 디스크 암호화(LFDE) 프로젝트를 확인하세요. 이 프로젝트는 /boot 파티션을 외부 USB 드라이브로 이동하는 설치 후 스크립트를 제공합니다. GPG로 키를 암호화하고 USB에도 저장합니다. 이렇게 하면 부팅 경로의 취약한 부분(암호화되지 않은 /boot 파티션)이 항상 사용자와 함께 있게 됩니다(해독 코드와 키에 물리적으로 접근할 수 있는 유일한 사람은 사용자가 됩니다). ( 메모: 이 사이트는 사라졌고 작성자의 블로그도 사라졌습니다. 하지만 https://github.com/mv-code/lfde에서 이전 파일을 찾을 수 있습니다. 마지막 개발이 6년 전에 완료되었다는 점만 참고하세요. 더 쉬운 대안으로, OS를 설치할 때 USB 드라이브에 암호화되지 않은 부팅 파티션을 설치할 수 있습니다.

감사합니다, M.V.

첫 번째 RAMdisk 및 /boot 폴더를 암호화되지 않은 상태로 만드세요.

이로 인해 드라이버 및 지원이 포함된 "최소" 커널이 암호화된 "실제" 루트 파일 시스템으로 전환됩니다.

"해킹이다"라고 선언하기 전에 기억하세요. 현재 대부분의 Linux 배포판은 기본적으로 부팅됩니다. 이를 통해 시스템이 파일 시스템에서 로드해야 하는 모듈을 사용하여 루트 FS를 부팅하고 로드할 수 있습니다. (일종의 닭고기와 달걀 문제). 예를 들어 루트 파일 시스템이 하드웨어 RAID 볼륨에 있고 루트 FS를 마운트하기 전에 드라이버를 로드해야 하는 경우입니다.

귀하가 게시한 링크를 살펴보았습니다. 부팅 파티션은 없지만 하드 드라이브에는 여전히 악의적인 공격에 액세스하여 손상될 수 있는 암호화되지 않은 부트로더가 있습니다. 저는 하드 드라이브에 암호화되지 않은 데이터가 없는 유사한 설정을 찾고 있었지만 지금까지는 이동식 드라이브에서 부트로더를 실행하는 방법만 생각해 냈습니다.

나는 그들 중 대부분에게 필요한 것은 먼저 암호화된 HD로 OS를 설치하는 방법에 대한 지침이라고 생각합니다.

Ubuntu에는 배포 버전에 따라 암호화된 파티션, LMVP, 폴더 등을 생성하는 방법에 대한 지침이 포함된 좋은 페이지가 있습니다.

아니, 내 생각에는 그렇지 않다.

정말로 암호화/다운로드해야 합니까? 나는 그렇지 않다고 생각한다. 파일 시스템의 나머지 부분은 /boot의 initramfs에 상주하고 이에 따라 사용자에게 메시지를 표시하는 일반 Linux 소프트웨어로 암호화할 수 있습니다.

불가능한 일을 요구하고 이를 Windows 솔루션과 비교하는 것 같습니다. 구현을 숨깁니다.그러나 실제로는 Linux가 수행하는 것과 동일한 작업을 수행합니다.

제가 생각하는 가장 가까운 해결책은 보안 비밀번호와 암호화를 구현하는 하드 드라이브를 사용하는 것입니다. 일부 Thinkpad 노트북은 이러한 하드웨어 솔루션을 사용합니다.

답변은 기사에 요약되어 있습니다. "이제 지원을 위해 패치가 적용된 차세대 GRUB2 부트로더에 대한 확장을 통해 가능합니다.", "나중에 luks grub2 지원이 포함된 새 이미지를 설치하고 싶습니다.", "이제 LUKS 지원으로 GRUB2 소스를 컴파일하겠습니다. . "GRUB2 또는 분기된 GRUB2 소스를 사용하여 얻고 활성화해야 하는 수정 사항이나 확장이 있는 것 같습니다.

Grub2 버전 2.02~beta3은 Grub2 버전 2.02~beta2가 할 수 없는 많은 일을 할 수 있습니다. 제가 테스트한 내용은 다음과 같습니다.

Super Grub 2 디스크를 사용하여 부팅
명령줄로 이동하려면 "c"를 입력하세요.
원하는 암호화된 파티션을 마운트하는 명령을 입력하세요.
- 인스모드 럭스
- cryptomount(hd0, #) // 여기서 #은 암호화된 파티션을 나타냅니다.
암호를 입력하고 일부 명령을 입력하세요
- 멀티부팅(crypto0) /grub/i386-pc/core.img
- 신병

이렇게 하면 암호화된 파티션 내부에 있는 또 다른 Grub2가 로드됩니다. 여기에는 사악하고 미친 공격이 있을 수 없습니다... CD(읽기 전용)에서 부팅한 다음 암호화된 파티션(암호 문구가 아닌 모든 것!)을 마운트한 다음 내부에서 부팅합니다. 암호화된 파티션 및 자체 메뉴 등으로 Grub2 부팅

경고: Grub2 버전 2.02~beta2에는 cryptomount 명령과 관련된 일부 버그(Grub2 버전 2.02~beta3에서 수정된 것으로 보임)가 있기 때문에 동일한 작업을 수행할 수 없습니다...

내가 말하는 beta2 오류는 다음과 같습니다.

실제로 암호화된 파티션을 마운트하지 않으므로 (crypto0)/*에 대한 액세스를 허용하지 않습니다.
암호화된 파티션이 두 개 이상인 경우 cryptomount -a를 사용하려면 하나의 암호만 필요합니다.
cryptomount를 다시 실행한 후 아무 작업도 수행하지 않습니다.

베타 3:

암호화된 파티션을 마운트하고 동시에 둘 이상이 마운트된 경우 (crypto0)/* 또는 (crypto1)/* 등을 통해 파일에 액세스할 수 있습니다.
각 암호 문구를 묻습니다(암호화된 섹션당 하나씩).
이를 통해 필요한 만큼 여러 번 실행할 수 있으며, 하나를 설치한 다음 다른 것을 설치할 수도 있습니다.

참고 사항: 다른 부트 로더 또는 동일한 grub2/기타 부트 로더를 재부팅하거나 부팅하는 것 외에는 마운트 해제하는 방법을 찾지 못했습니다.

이것이 문제를 해결하는 데 도움이 되기를 바라며 Grub2 2.02~beta3 버전이 LiveCD에 통합되어 직접 컴파일하지 않고도 설치할 수 있기를 바랍니다.

PD: Super Grub 2 디스크를 사용하면 MBR/부팅 파티션 등에 Grub2 버전 2.02~beta3을 설치하는 방법이 없습니다.

저자: 니티시 티와리
발행일: 2015년 2월 4일
번역: N. Romodanov
번역일: 2015년 3월

TrueCrypt는 더 이상 지원되지 않지만 dm-crypt 및 LUKS는 암호화된 데이터를 암호화하고 사용하기 위한 훌륭한 오픈 소스 옵션입니다.

데이터 보안은 인터넷 사용자들 사이에서 가장 큰 관심사 중 하나가 되었습니다. 웹사이트로부터의 데이터 도난 소식은 매우 흔해졌습니다. 그러나 귀하의 데이터를 보호하는 것은 웹사이트만의 책임이 아니며, 최종 사용자로서 우리 자신의 보안을 위해 할 수 있는 일이 많이 있습니다. 예를 들어, 강력한 비밀번호 사용, 컴퓨터에 있는 하드 드라이브 암호화, 보안 연결 사용 등이 그 예입니다. 특히, 하드 드라이브를 암호화하는 것은 보안을 보장하는 좋은 방법입니다. 이는 네트워크를 통해 데이터를 훔치려는 트로이 목마로부터 보호할 뿐만 아니라 물리적 공격으로부터도 보호합니다.

올해 5월, 오픈소스 디스크 암호화 도구로 잘 알려진 트루크립트(TrueCrypt) 개발이 중단됐다. 많은 분들이 아시다시피 이는 디스크 암호화를 위해 설계된 매우 안정적인 도구 중 하나였습니다. 이 정도 수준의 도구가 사라지는 것은 슬픈 일이지만, 많은 구성 옵션이 있는 디스크 암호화로 보안을 달성하는 데 도움이 될 수 있는 다른 오픈 소스 도구도 있다는 점은 오픈 소스 세계의 위대함입니다. Linux 플랫폼용 TrueCrypt의 대안으로 그 중 두 가지(dm-crypt 및 LUKS)를 살펴보겠습니다. dm-crypt와 LUKS를 간단히 살펴보겠습니다.

이는 LUKS를 사용하는 장치에 대한 기본 정보로, 사용되는 암호화, 암호화 모드, 해싱 알고리즘 및 기타 암호화 데이터를 나타냅니다.

자원

01단계: Dm-crypt 고려

앱 이름 dm-crypt는 device mapper-crypt의 약어입니다. 이름에서 알 수 있듯이 블록 장치를 더 높은 수준의 가상 블록 장치에 매핑하도록 설계된 Linux 커널 프레임워크인 장치 매핑을 기반으로 합니다. 장치를 매핑할 때 dm-cache(하이브리드 볼륨 생성), dm-verity(Chrome OS의 일부인 블록 무결성을 확인하도록 설계됨) 및 매우 인기 있는 Docker와 같은 여러 커널 기능을 사용할 수 있습니다. 암호화 목적으로 dm-crypt는 Linux 커널 Crypto API 프레임워크를 사용합니다.

요약하면 dm-crypt 애플리케이션은 투명한 디스크 암호화를 제공하는 커널 수준 암호화 하위 시스템입니다. 즉, 디스크가 마운트된 후 즉시 파일에 액세스할 수 있으며 최종 사용자에게 눈에 띄는 지연이 없습니다. dm-crypt를 사용하여 암호화하려면 대칭 암호 중 하나, 암호화 모드, 키(유효한 크기), IV 생성 모드를 지정한 다음 /dev에 새 블록 장치를 생성하면 됩니다. 이제 이 장치에 쓰는 모든 내용은 암호화되며 읽는 내용은 모두 해독됩니다. 평소대로 이 장치에 파일 시스템을 마운트하거나 dm-crypt 장치를 사용하여 RAID 또는 LVM 볼륨과 같은 다른 디자인을 생성할 수 있습니다. dm-crypt 조회 테이블은 다음과 같이 정의됩니다.

여기서 start-sector는 일반적으로 0이고, size는 섹터 단위의 장치 크기이며, target name은 암호화된 장치에 부여하려는 이름입니다. 대상 매핑 테이블은 다음 섹션으로 구성됩니다.

[<#opt_params> ]

02단계: LUKS를 고려하면

이전 단계에서 이미 본 것처럼 dm-crypt 애플리케이션은 자체적으로 데이터를 암호화/해독할 수 있습니다. 그러나 여기에는 몇 가지 단점이 있습니다. dm-crypt를 직접 사용하면 디스크에 메타데이터가 생성되지 않으며, 이는 서로 다른 Linux 배포판 간의 호환성을 보장하려는 경우 심각한 문제가 될 수 있습니다. 또한 dm-crypt 애플리케이션은 다중 키 사용을 지원하지 않지만 실제 상황에서는 다중 키를 사용하는 것이 매우 중요합니다.

이러한 이유로 LUKS(Linux Unified Key Setup) 기술이 탄생했습니다. LUKS는 Linux 하드 드라이브 암호화 표준이며 표준화를 통해 다양한 배포판 간의 호환성이 가능합니다. 여러 키와 암호 문구의 사용도 지원됩니다. 이 표준화의 일환으로 LUKS 헤더가 암호화된 데이터에 추가되며 이 헤더에는 구성에 필요한 모든 정보가 포함됩니다. 데이터가 포함된 헤더가 있으면 사용자는 다른 배포로 쉽게 전환할 수 있습니다. dm-crypt 프로젝트는 현재 디스크 암호화를 구성하는 기본 방법으로 LUKS를 사용할 것을 권장합니다. cryptsetup 유틸리티를 설치하는 방법과 이를 사용하여 LUKS 기반 볼륨을 생성하는 방법을 살펴보겠습니다.

03단계:설치

dm-crypt에 사용되는 커널 수준 기능은 이미 모든 Linux 배포판에 있습니다. 우리는 그들에 대한 인터페이스만 필요합니다. 우리는 LUKS 표준인 dm-crypt와 오래된 TrueCrypt 애플리케이션을 사용하여 볼륨을 생성할 수 있는 cryptsetup 유틸리티를 사용할 것입니다. Debian/Ubuntu 배포판에 cryptsetup을 설치하려면 다음 명령을 사용할 수 있습니다.

$ sudo apt-get 업데이트 $ sudo apt-get 설치 cryptsetup

첫 번째 명령은 로켓 인덱스 파일을 해당 저장소의 내용과 동기화합니다. 사용 가능한 모든 패키지의 최신 버전에 대한 정보를 얻습니다. 두 번째 명령은 컴퓨터에 cryptsetup 패키지를 다운로드하고 설치합니다. RHEL/Fedora/CentOS 배포판을 사용하는 경우 yum 명령을 사용하여 cryptsetup 유틸리티를 설치할 수 있습니다.

$ 냠 설치 cryptsetup-luks

04단계:대상 파일 만들기

이제 cryptsetup 유틸리티가 성공적으로 설치되었으므로 LUKS 컨테이너를 저장할 대상 파일을 생성해야 합니다. 이러한 파일을 만드는 방법에는 여러 가지가 있지만 파일을 만들 때 충족해야 하는 여러 조건이 있습니다.

파일은 디스크의 여러 위치에 있는 여러 부분으로 구성되어서는 안 됩니다. 즉, 파일을 생성할 때 즉시 충분한 양의 메모리를 할당해야 합니다.
전체 파일은 암호화에 사용되는 데이터가 어디에 있는지 누구도 알 수 없도록 임의의 데이터로 채워야 합니다.

dd 명령은 상대적으로 느리기는 하지만 위의 조건을 만족하는 파일을 생성하는 데 도움이 될 수 있습니다. 입력으로 지정된 특수 장치 파일 /dev/random과 출력으로 지정된 대상 파일과 함께 사용하면 됩니다. 예제 명령은 다음과 같습니다.

$ dd if=/dev/random of=/home/nitish/basefile bs=1M count=128

결과적으로 /home/nitish 디렉터리에 128MB 크기의 basefile이라는 파일이 생성됩니다. 그러나 이 명령을 완료하는 데 시간이 꽤 오래 걸릴 수 있습니다. 우리 전문가가 사용한 시스템에서는 이 작업에 한 시간이 걸렸습니다.

05단계: dm-crypt LUKS 생성

대상 파일을 생성한 후에는 해당 파일에 LUKS 파티션을 생성해야 합니다. 이 섹션은 모든 데이터 암호화가 구축되는 기본 계층 역할을 합니다. 또한 이 섹션의 헤더(LUKS 헤더)에는 다른 장치와의 호환성에 필요한 모든 정보가 포함되어 있습니다. LUKS 파티션을 생성하려면 cryptsetup 명령을 사용하십시오.

$ cryptsetup -y luksFormat /home/nitish/basefile

기본 파일 내부의 데이터가 영구 삭제된다는 점에 동의하신 후, 암호를 입력하고 확인하시면 LUKS 파티션이 생성됩니다. 다음 파일 명령을 사용하여 이를 확인할 수 있습니다.

$filebase파일

여기에 입력하는 문구는 데이터를 해독하는 데 사용됩니다. 이를 기억하고 안전한 곳에 보관하는 것이 매우 중요합니다. 왜냐하면 잊어버리면 암호화된 파티션의 모든 데이터가 거의 손실될 것이기 때문입니다.

6단계:파일 시스템 생성 및 마운트

이전 단계에서 생성한 LUKS 컨테이너를 이제 파일로 사용할 수 있습니다. 이 예에서는 /home/nitish/basefile입니다. cryptsetup 유틸리티를 사용하면 LUKS 컨테이너를 독립 장치로 열 수 있습니다. 이렇게 하려면 먼저 컨테이너 파일을 장치 이름에 매핑한 다음 장치를 탑재합니다. 표시 명령은 다음과 같습니다.

이전 단계에서 생성한 암호를 성공적으로 입력하면 LUKS 컨테이너가 볼륨 1에 매핑됩니다. 실제로 일어나는 일은 파일이 로컬 루프백 장치로 열리므로 이제 시스템의 나머지 부분이 파일을 실제 장치인 것처럼 처리할 수 있다는 것입니다.

7단계:파일 시스템 - 계속

이제 LUKS 컨테이너 파일을 시스템에서 일반 장치로 사용할 수 있습니다. 정상적인 작업에 사용하려면 먼저 포맷하고 파일 시스템을 만들어야 합니다. 시스템에서 지원되는 모든 파일 시스템을 사용할 수 있습니다. 내 예에서는 Linux 시스템의 최신 파일 시스템인 ext4를 사용했습니다.

$ mkfs.ext4 -j /dev/mapper/volume1

장치가 성공적으로 포맷되면 다음 단계는 장치를 마운트하는 것입니다. 먼저 (상식적으로) /mnt에 마운트 지점을 생성해야 합니다.

$mkdir/mnt/파일

이제 마운트하자:

교차 확인하려면 df –h 명령을 사용하십시오. 마운트된 장치 목록 끝에 "/dev/mapper/volume1" 장치가 표시됩니다. LUKS 헤더가 이미 장치의 일부 공간을 차지하고 있음을 알 수 있습니다.

이 단계 덕분에 이제 ext4 파일 시스템에서 LUKS 장치를 사용할 수 있습니다. 이 장치를 사용하여 파일을 저장하세요. 이 장치에 쓰는 모든 내용은 암호화되며, 여기서 읽는 모든 내용은 해독되어 사용자에게 표시됩니다.

08단계:암호화된 드라이브 사용

우리는 이 결과를 얻기 위해 여러 단계를 따랐으며, 모든 것이 어떻게 작동하는지 명확하지 않은 경우 한 번만 수행하면 되는 작업(설치에 필요함)과 설치 시 정기적으로 수행해야 하는 작업에 대해 혼란스러울 가능성이 높습니다. 암호화를 사용합니다. 다음 시나리오를 고려해 보겠습니다. 위의 모든 단계를 성공적으로 완료한 다음 컴퓨터를 종료했습니다. 다음날 컴퓨터를 시작하면 마운트된 장치를 찾을 수 없습니다. 어디로 갔습니까? 이 모든 것을 파악하려면 시스템이 시작된 후 LUKS 컨테이너를 마운트해야 하고 컴퓨터를 중지하기 전에 마운트를 해제해야 한다는 점을 명심해야 합니다.

LUKS 파일에 액세스하려면 컴퓨터를 켤 때마다 다음을 수행한 다음 컴퓨터를 끄기 전에 파일을 안전하게 닫으십시오.

LUKS 파일(예: /home/nitish/basefile)을 열고 비밀번호를 입력하세요. 명령은 다음과 같습니다.

$ cryptsetup luksOpen /home/nitish/basefile 볼륨1

파일이 열리면 파일을 마운트합니다(자동으로 마운트되지 않는 경우).

$ 마운트 /dev/mapper/volume1 /mnt/files

이제 마운트된 장치를 일반 디스크로 사용하고 데이터를 읽거나 쓸 수 있습니다.

완료되면 다음과 같이 장치를 마운트 해제합니다.

$ umount /mnt/파일

성공적으로 마운트 해제한 후 LUKS 파일을 닫습니다.

$cryptsetup luksClose 볼륨1

9단계:지원

LUKS 컨테이너에 저장된 데이터 손실의 대부분은 LUKS 헤더 또는 키 슬롯의 손상으로 인해 발생합니다. 헤더를 메모리에 실수로 다시 쓰는 경우에도 LUKS 헤더가 손상될 수 있다는 사실 외에도 실제 상황에서는 하드 드라이브가 완전히 고장날 수도 있습니다. 이러한 문제로부터 자신을 보호하는 가장 좋은 방법은 백업을 하는 것입니다. 어떤 백업 옵션을 사용할 수 있는지 살펴보겠습니다.

LUKS 헤더 파일의 백업을 생성하려면 명령에 luksHeaderBackup 매개변수를 지정합니다.

$ sudo cryptsetup luksHeaderBackup /home/nitish/basefile --header-backup-file /home/nitish/backupfile

또는 백업에서 파일을 복원하려면 명령에 luksHeaderRestore 매개변수를 지정합니다.

$ sudo cryptsetup luksHeaderRestore /home/nitish/basefile --header-backup-file /home/nitish/backupfile

LUKS 헤더 파일을 확인하고 처리 중인 파일이 실제 LUKS 장치에 해당하는지 확인하려면 isLuks 매개변수를 사용할 수 있습니다.

$ sudo cryptsetup -v isLuks /home/nitish/basefile

LUKS 헤더 파일을 백업하는 방법을 이미 살펴보았지만 LUKS 헤더 백업은 실제로 전체 디스크 오류로부터 보호하지 못하므로 다음 cat 명령을 사용하여 전체 파티션을 백업해야 합니다.

$ 고양이 /home/nitish/basefile > basefile.img

10단계:다양한 설정

dm-crypt LUKS 암호화를 사용할 때 유용할 수 있는 몇 가지 다른 설정이 있습니다. 그들을 살펴보자.

LUKS 헤더를 덤프하기 위해 cryptsetup 명령에는 luksDump 옵션이 있습니다. 이를 통해 사용 중인 장치의 LUKS 헤더 파일의 스냅샷을 찍을 수 있습니다. 예제 명령은 다음과 같습니다.

$ cryptsetup luksDump /home/nitish/basefile

이 기사의 시작 부분에서 LUKS가 여러 키를 지원한다고 언급했습니다. 이제 새 키 슬롯( 번역자 주: 키 슬롯 - 키 공간):

$ cryptsetup luksAddKey --키 슬롯 1 /home/nitish/basefile

이 명령은 키 슬롯 번호 1에 키를 추가하지만 현재 비밀번호(키 슬롯 0에 있는 키)를 입력한 후에만 가능합니다. 총 8개의 키 슬롯이 있으며, 어떤 키를 사용해도 데이터를 해독할 수 있습니다. 두 번째 키를 추가한 후 헤더를 덤프하면 두 번째 키 슬롯이 채워져 있는 것을 볼 수 있습니다.

다음과 같이 키 슬롯을 제거할 수 있습니다.

$ cryptsetup luksRemoveKey /home/nitish/basefile

이렇게 하면 슬롯 번호가 가장 높은 키 슬롯이 제거됩니다. 모든 슬롯을 삭제하지 않도록 주의하십시오. 그렇지 않으면 데이터가 영원히 손실됩니다.

이 작품의 저자는 자신이 사용하는 디스크 파티션을 암호화하는 방법에 대해 .

리눅스

이 매뉴얼에서는 리눅스 dm-암호화 (장치 매퍼) 핵심에 2.6 . 섹션을 암호화하겠습니다. /dev/sdc1, 이는 임의의 파티션, 디스크, USB 또는 생성된 파일일 수 있습니다. 패배. 여기서 우리는 사용할 것입니다 /dev/loop0, 바라보다 . 장치 매퍼이 예에서는 레이블을 사용하여 파티션을 식별합니다. sdc1이지만 다른 문자열일 수도 있습니다.

LUKS를 사용하여 디스크 파티션 암호화

루크스와 함께 DM-암호화디스크 파티션을 암호화하는 데 매우 편리합니다. 하나의 파티션에 대해 여러 개의 비밀번호를 가질 수 있고 쉽게 변경할 수도 있습니다. 사용이 가능한지 확인하려면 루크스, 다이얼: cryptsetup --help, 만약에 루크스아무것도 나타나지 않았습니다. 아래를 읽어보세요." LUKS 없는 dm-crypt". 먼저 필요한 경우 파티션을 만듭니다. fdisk /dev/sdc.

암호화된 파티션을 만드는 방법

# dd if=/dev/urandom of=/dev/sdc1 # 선택사항. 편집증 환자에게만 해당# cryptsetup -y luksFormat /dev/sdc1 # 이렇게 하면 다음의 모든 데이터가 삭제됩니다. sdc1 # cryptsetup luksOpen /dev/sdc1 sdc1 # mkfs.ext3 /dev/mapper/sdc1 # 파일 시스템이 생성됩니다 ext3 # mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt # cryptsetup luksClose sdc1

산

# cryptsetup luksOpen /dev/sdc1 sdc1 # mount -t ext3 /dev/mapper/sdc1 /mnt

마운트 해제

# umount /mnt # cryptsetup luksClose sdc1

LUKS가 없는 dm-crypt

# cryptsetup -y sdc1 /dev/sdc1 생성 # 또는 다음과 같은 다른 섹션 /dev/loop0 # dmsetup ls # 확인하면 다음과 같이 표시됩니다. sdc1 (254, 0) # mkfs.ext3 /dev/mapper/sdc1 # 처음 했을 경우에만!# mount -t ext3 /dev/mapper/sdc1 /mnt # umount /mnt/ # cryptsetup sdc1 제거 # 암호화된 파티션 분리파티션을 다시 연결하려면 fs를 생성하지 않고 동일한 작업을 수행합니다. 잘못된 비밀번호를 입력하면 마운트 명령이 실행되지 않습니다. 이 경우 디스플레이를 제거하면 됩니다. sdc1 (cryptsetup은 sdc1을 제거합니다) 새 항목을 만듭니다.

FreeBSD

의 디스크 암호화에 널리 사용되는 몇 가지 모듈은 다음과 같습니다. GBDE그리고 겔리. 겔리하드웨어 가속을 사용하기 때문에 더 빠릅니다. 더 자세한 설명은 FreeBSD 핸드북 18.6장을 참조하세요. 작업, 겔리커널 모듈로 로드되거나 컴파일 타임에 내장되어야 합니다. 옵션 GEOM_ELI 장치 암호화 # 아니면 커널 모듈로 로드합니다:# echo "geom_eli_load="YES"" >> /boot/loader.conf # 또는 kldload geom_eli

비밀번호와 키 사용

작성자는 일반적인 파티션 암호화에 이러한 설정을 사용하며 비밀번호와 암호화 키를 사용합니다. 마스터 키- 기본 키." 암호화된 파티션을 마운트하려면 비밀번호와 키가 모두 필요합니다. /root/ad1.key. "마스터 키"는 파티션 내부에 저장되며 보이지 않습니다. 다음 예는 USB 또는 파일 이미지의 일반적인 예입니다.

암호화된 파티션 생성

# dd if=/dev/random of=/root/ad1.key bs=64 count=1 # 이 키는 마스터 키를 암호화합니다# geli init -s 4096 -K /root/ad1.key /dev/ad1 # -s 8192 및 디스크의 경우 OK# geli 연결 -k /root/ad1.key /dev/ad1 # DO는 /root/ad1.key를 백업합니다.# dd if=/dev/random of=/dev/ad1.eli bs=1m # 선택 사항이며 시간이 많이 소요됨 # newfs /dev/ad1.eli # 파일 시스템 생성# 마운트 /dev/ad1.eli /mnt # 암호화된 파티션을 마운트합니다

붙이다

# geli 연결 -k /root/ad1.key /dev/ad1 # fsck -ny -t ffs /dev/ad1.eli # 의심스러운 경우 파일 시스템을 확인하십시오.# 마운트 /dev/ad1.eli /mnt

분리하다

마운트 해제 절차는 종료 시 자동으로 수행됩니다. # umount /mnt # geli 분리 /dev/ad1.eli

/etc/fstab

암호화된 파티션 마운트는 다음을 통해 구성할 수 있습니다. /etc/fstab. 다운로드 시 비밀번호를 요청하게 됩니다. # grep geli /etc/rc.conf geli_devices="ad1" geli_ad1_flags="-k /root/ad1.key" # grep geli /etc/fstab /dev/ad1.eli /home/private ufs rw 0 0

비밀번호로만

이는 플래시 드라이브나 이미지의 파일 기반 암호화에 더 적합한 방법으로, 비밀번호만 요구합니다. 이 경우 키 파일에 대해 걱정할 필요가 없습니다. 키 파일 생성을 제외하면 절차는 위에서 설명한 절차와 유사합니다. 파일에서 생성된 1GB 이미지를 암호화해 보겠습니다. /암호화된 파일. # dd if=/dev/zero of=/cryptedfile bs=1M count=1000 # 1GB 파일을 생성합니다# mdconfig -at vnode -f /cryptedfile # geli init /dev/md0 # 비밀번호로만 암호화# geli attachment /dev/md0 # newfs -U -m 0 /dev/md0.eli # mount /dev/md0.eli /mnt # umount /dev/md0.eli # geli detach md0.eli 이제 이 이미지를 마운트할 수 있습니다. 다른 컴퓨터에서는 비밀번호만 입력하면 됩니다. # mdconfig -at vnode -f /cryptedfile # geli 연결 /dev/md0 # 마운트 /dev/md0.eli /mnt

오늘날 중요한 데이터를 일반 텍스트로 저장하는 것은 그 어느 때보다 위험해졌습니다. 그리고 정부 감시 때문이 아니라(원하는 경우 불평할 내용을 찾을 수 있음 등) 이 데이터를 훔치려는 사람들 때문입니다. 정보를 보호하는 방법은 원칙적으로 여러 가지가 있지만, 이 글에서는 암호화 수단에 대해 설명하겠습니다.

다른 운영 체제와 달리 Linux에는 이메일 통신 암호화부터 파일 및 블록 장치 암호화에 이르기까지 암호화 정보 보호를 위한 다양한 도구가 있습니다. 우리는 파일 시스템, 파일 및 블록 장치 수준의 암호화에 관심이 있습니다. 첫째, 차이점이 무엇인지 이해하는 것이 좋습니다. 파일 시스템 수준의 암호화에는 기본 파일 시스템(물론 파일 시스템 자체가 암호화를 지원하지 않는 경우 제외)과 사용자 사이에 계층이 있어야 합니다.

이러한 유형의 암호화의 장점은 키가 모든 사용자에게 다르다는 것입니다. 단점은 파일 이름 암호화를 활성화하면 유효한 이름의 길이가 줄어들고 사용자가 파일을 디스크의 다른 위치에 저장할 수 있어 자동으로 이점이 무효화된다는 것입니다. 그리고 한 가지 더 - 이름 암호화가 활성화되어 있어도 타임스탬프는 동일하게 유지됩니다. 블록 장치 암호화는 파일 시스템 아래의 낮은 수준에서 발생합니다. 이 경우 파일 시스템 자체는 물론 암호화된 볼륨에 위치한다는 사실을 알지 못합니다.

이 방법의 장점은 이전 방법의 단점과 정반대입니다. 단점은 다운로드/마운트할 때마다 비밀번호를 입력해야 한다는 것입니다. 두 번째 단점은 런타임 중에 공격자가 암호화폐에 있는 파일에 액세스할 수 있다는 것입니다.
teiner, 그게 다예요. 잃어버렸어요. 이것이 바로 오프라인 공격으로부터의 보호입니다. 또한 암호화폐 컨테이너를 클라우드에 저장하는 대부분의 경우 전체를 다시 업로드해야 합니다.

이 문서에서는 다음과 같은 암호화 보호 방법을 설정하는 방법을 설명합니다.
dm-crypt/LUKS- 장치 매퍼 및 CryptoAPI 커널을 사용하여 암호화 컨테이너 생성
eCryptfs- 파일 시스템 수준의 암호화
EncFS- 위에서 설명한 것과 유사하지만 커널 모듈을 로드할 필요가 없습니다.

DM-CRYPT/LUKS
dm-crypt 구성에는 일반 및 LUKS의 두 가지 유형이 있습니다. 차이점은 LUKS를 사용할 때 메타데이터가 암호문 시작 부분에 존재하므로 여러 키를 사용하고 변경할 수 있다는 것입니다. 동시에, 어떤 경우에는 그러한 헤더의 존재 자체가 손상될 수 있습니다. 그러나 대부분의 경우 엔트로피 수준이 높은 영역도 손상될 것입니다. 키 파일 및 암호 문구를 사용하여 일반 dm-crypt 설정 키 파일로 암호화되고 LUKS 컨테이너에 포함된 일반 dm-crypt 볼륨의 조합을 설정하는 방법을 살펴보겠습니다. 먼저 섹션을 배치할 방법을 정확히 결정해야 합니다. 세 가지 주요 옵션이 있습니다:
단지 암호화폐 볼륨일 뿐입니다.
먼저 암호화폐 볼륨을 만들고 그 위에 LVM을 추가합니다.
첫 번째 암호화 볼륨, RAID, LVM 순입니다.

그리고 모든 종류의 조합. 두 번째 옵션을 시도해 보겠습니다. 첫 번째 단계는 키 문구와 함께 이 파일을 사용할 수 있도록 키 파일을 저장할 LUKS 컨테이너를 만드는 것입니다. 이 경우 일반 dm-crypt를 사용하여 암호화된 볼륨의 암호화 분석 가능성이 줄어듭니다.

# dd if=/dev/zero of=/root/key.luks bs=512 count=2057

# cryptsetup --align-payload=1 luksFormat /root/key.luks

# cryptsetup luksOpen /root/key.luks 암호화키

# dd if=/dev/urandom of=/dev/mapper/cryptokey

첫 번째 명령은 컨테이너 파일을 준비하고, 두 번째 명령은 이 컨테이너를 생성하고, 세 번째 명령은 이를 연결하고, 네 번째 명령은 키 정보를 생성합니다. LUKS 메타데이터의 크기가 4096 512바이트 블록이 아닌 2056바이트인지 확인하려면 –align-payload=1 옵션이 필요하다는 점에 주목할 필요가 있습니다. 따라서 실제 키 정보에는 512바이트가 남습니다.
그런 다음 암호문 생성으로 넘어갑니다. 이 시점에서 선택적으로 의사 난수 데이터로 디스크를 채워 암호 분석을 어렵게 만들 수도 있습니다. 그런 다음 암호화폐를 만들 수 있습니다. 이에 대한 명령은 다음과 같습니다(물론 다른 경우에는 식별자가 다를 수 있으므로 주의해야 합니다).

# cryptsetup --cipher=serpent-xts-plain64 --offset=0--key-file=/dev/mapper/cryptokey --key-size=512 open --type=plain/dev/disk/by-id/ ata-VBOX_HARDDISK_VB05eadebe-f25e8d59 암호화0

필요한 경우 암호화가 필요한 다른 장치에서 유사한 명령을 반복해야 합니다. 그런 다음 암호화 볼륨에 LVM 및 FS를 생성합니다.

대략 다음 내용으로 /etc/initramfs-tools/hooks/cryptokeys 파일을 생성해 보겠습니다(스크립트의 서비스 부분은 생략됨).

그리고 파일 /etc/initramfs-tools/scripts/local-top/cryptokeys(서비스 부분 다시
생략):

# <...>

modprobe -b dm_crypt

하는 동안! (/sbin/cryptsetup luksOpen /etc/crypto/key.luks cryptokey

/dev/disk/by - ID /ata - VBOX_HARDDISK_VB05eadebe - f25e8d59 crypto0

&& /sbin/cryptsetup plainOpen -- 키 - 파일 = /dev/mapper/cryptokey

/dev/disk/by - ID /ata - VBOX_HARDDISK_VBc2414841 - cfeccde5 crypto1

&& /sbin/cryptsetup luks암호화 키 닫기

) ; 하다

에코 “다시 시도해보세요. . . ”

완료

이 두 파일은 실행 가능해야 합니다. 그런 다음 initrd를 만듭니다.

# 업데이트-initramfs -u -k 모든 -v

다음에 재부팅할 때 LUKS 컨테이너의 비밀번호를 묻는 메시지가 표시됩니다. 일반 dm-crypt를 사용하는 경우 숨겨진 TrueCrypt 볼륨과 같은 작업을 수행할 수 있는 공통 하단 레이어라는 또 다른 옵션이 있습니다. 예를 들면 다음과 같습니다.

# cryptsetup --cipher=serpent-xts-plain64 --offset=0--size=2097152 --shared open --type=plain/dev/disk/by-id/ata-VBOX_HARDDISK_VBcda8398f-f1f1deec crypto

# cryptsetup --cipher=serpent-xts-plain64 --offset=2097152--size=2097152 --shared open --type=plain/dev/disk/by-id/ata-VBOX_HARDDISK_VBcda8398f-f1f1deec crypto_shared

크기와 오프셋은 512바이트 블록으로 지정됩니다.

LUKS의 고급 기능
LUKS 컨테이너의 고급 용도도 살펴보겠습니다. 여기에는 키 변경이 포함됩니다. 이는 키 순환 정책을 손상시키거나 생성할 때 필요합니다. 이를 수행하는 첫 번째 단계는 컨테이너 헤더의 백업을 생성하는 것입니다. 만약 모두
좋습니다. 키를 변경한 후에는 파기될 수 있습니다. 물론 암호화되지 않은 파티션에서 수행합니다.

마지막으로 시스템에 새 키를 추가합니다.

LUKS 볼륨을 복원하는 절차도 고려해 보겠습니다. 물론 가장 쉬운 방법은 헤더 사본이 있는 경우입니다. 이 경우 복원에는 하나의 명령만 필요합니다.

가장 긴 연속 라인이 마스터 키가 됩니다. 암호화되지 않은 볼륨의 파일에 복사한 다음 바이너리 형식으로 변환해야 합니다.
줄 끝 문자):

ENCFS
로그인 시 자동으로 마운트되도록 EncFS를 구성하는 방법을 살펴보겠습니다. 먼저 필요한 패키지를 설치해 보겠습니다.

전문가 모드에서 설정할 때 다음과 같은 여러 가지 질문을 받게 됩니다: 암호 유형(AES 및 Blowfish만 사용 가능), 키 크기, 블록 크기, 파일 이름 암호화 방법 - 블록 암호화(다음을 포함하여 파일 이름을 완전히 숨김) 길이), 스트림 암호화(가능한 가장 가까운 길이로 암호화합니다. 이는 이름이 너무 길고 블록 암호를 사용할 때 최대 허용 길이를 초과할 가능성이 상당히 높은 경우 때때로 편리함) 또는 전혀 없습니다. .. 마지막에 비밀번호를 묻는 메시지가 표시됩니다. 비밀번호는 로그인에 사용된 비밀번호와 일치해야 합니다. 그렇지 않으면 자동 마운트가 작동하지 않습니다.

다음으로 /etc/security/pam_encfs.conf 파일을 편집해야 합니다:

그리고 /etc/fuse.conf 파일:

그리고 퓨즈 그룹에 사용자를 추가합니다.

$ sudo usermod - a - G 퓨즈 $ 사용자

로그아웃하고 로그인한 후 개인 디렉터리를 개인 데이터 저장소로 사용할 수 있습니다. 그러나 감사 결과 일부 (매우 심각한) 보안 문제가 드러났다는 점은 주목할 가치가 있습니다. 이것이 바로 이 시스템이 정말 중요한 데이터를 저장하는 데 권장되지 않는 이유입니다.

암호화폐
eCryptFS는 Ubuntu에서 홈 디렉터리를 보호하기 위한 기본 도구로 사용되는 것으로 알려져 있습니다. 어떻게 작동하는지 살펴보겠습니다. 암호화된 디렉터리를 수동으로 생성해 보겠습니다. 패키지를 설치해 보겠습니다.

eCryptFS 생성

그리고 파일 시스템을 마운트합니다(첫 번째 마운트 중에 필요한 모든 메타데이터가 생성됩니다).

$ sudo 마운트 -t ecryptfs /home/rom/. 비밀/집/ROM/비밀

암호 문구(한 번만, 재입력이 구현되지 않았으므로 길이가 길어야 한다는 점을 고려하면 좋은 솔루션인 것 같지 않음)를 요청한 다음 암호 유형(AES, Blowfish, 3DES, Twofish, CAST6 및 CAST5), 크기 키, 암호화된 파일이 있는 디렉터리에서 암호화되지 않은 파일을 허용할지 거부할지, 파일 이름을 암호화할지 여부에 대한 질문이 표시되고 결국에는 실제로 마운트하고 저장할 것인지 묻는 메시지가 표시됩니다. 특정 파일에 서명합니다. 질문은 처음에 보이는 것처럼 어리석지 않습니다. 이 소프트웨어에서는 서명이 없으면 올바른 비밀번호와 잘못된 비밀번호를 구별할 방법이 없습니다.

사용자의 홈 디렉터리 암호화

처음 실행하는 동안 여러 프로세스를 종료해야 할 수도 있습니다. 암호화 후에는 즉시 사용자로 로그인해야 하며, 암호화를 위해 생성된 암호를 적거나 인쇄하라는 메시지가 표시되고 차례로 사용자 암호로 보호됩니다. 이는 긴급 상황 발생 시 복구를 위해 필요합니다.

암호를 기억하라는 경고

복원하는 방법을 살펴보겠습니다. 암호가 기록되지 않고 Live CD에서 복구한다고 가정해 보겠습니다. 파일 시스템이 마운트된 것으로 가정합니다. home/.ecryptfs/rom/.ecryptfs 디렉터리로 이동하여 다음 명령을 입력합니다.

DM 확인
dm-verify 모듈은 블록 장치의 무결성을 확인하도록 설계되었습니다. 검증은 해시 트리를 사용하여 수행됩니다. 여기서 "잎"은 블록의 해시 합계이고 "분기"는 "잎" 집합의 해시 합계입니다. 따라서 블록 장치(파티션이든 디스크이든)를 확인하려면 체크섬 하나만 확인하면 충분합니다.
이 메커니즘(디지털 서명과 함께)은 Google Chromium OS뿐만 아니라 시스템 파티션 수정을 방지하기 위해 일부 Android 장치에서 사용됩니다.

결론
Linux에는 실제로 암호화 정보 보호를 위한 많은 도구가 포함되어 있습니다. 설명된 세 가지 도구 중 적어도 하나는 모든 최신 Linux 배포판에 존재합니다. 하지만 무엇을 선택해야 할까요?
dm-crypt/LUKS암호화된 볼륨을 신속하게 비활성화할 수 있는 경우와 백업 복사본이 필요하지 않거나 달리 분류된 경우에 사용해야 합니다. 이 경우 이 솔루션은 특히 임의 중첩 및 유형(예: AES-Twofish-AES)의 계단식으로 암호화가 수행될 수 있다는 점을 고려하면 매우 효과적입니다.
편집증 환자를 위해.
eCryptFS예를 들어 클라우드와 같은 어딘가에 암호화된 데이터를 저장해야 하는 경우에 적합합니다. 이는 상당히 강력한 암호화를 제공하며(기본 128비트 옵션에는 암호화 강도를 2비트 줄이는 옵션이 있지만) 최종 사용자에게 투명합니다.
EncFS하지만 훨씬 더 오래된 작품을 바탕으로 한 약 10년 전의 노인입니다. 잠재적인 보안 허점으로 인해 현재 사용이 권장되지 않지만 클라우드에서 민감하지 않은 데이터를 보호하기 위한 크로스 플랫폼 도구로 사용할 수 있습니다.

그러한 수단을 사용해야 한다면 보호가 포괄적이어야 한다는 점을 항상 기억해야 합니다.