여러 하드 드라이브를 잠금 해제하는 LUKS에 대해 한 번 물었습니다.Linux: LUKS 및 여러 하드 드라이브.
이제 관련 파티션을 자동으로 잠금 해제하는 데 사용되는 키 파일을 안전하게 저장하는 방법을 알고 싶습니다.
내 계획은 (가능하다면):
비밀번호가 필요한 LUKS를 사용하여 소형 USB 드라이브 암호화
부팅 시 첫 번째 드라이브로 비밀번호를 사용하여 잠금 해제
예를 들어 /test와 같은 특정 마운트 지점에 마운트합니다(이것이 가능합니까?)
이제 키 파일을 안전하게 읽을 수 있습니다: /test/keyfile
비밀번호를 묻지 않고 키 파일을 사용하여 다른 드라이브의 잠금을 해제하세요.
Luks는 보안 수준을 보장하기 위해 다른 드라이브의 잠금이 해제되는 즉시 USB 드라이브를 닫습니다.
평소와 같이 /, /usr, /var 및 기타 마운트 지점을 자동으로 마운트합니다.
괜찮나요? 기본적으로 저는 LUKS 키 파일을 비밀번호로 암호화된 LUKS USB 드라이브에 저장합니다. 이 드라이브는 비밀번호가 한 번만 필요하고 다른 모든 드라이브는 추가 조치 없이 잠금 해제될 수 있습니다. USB 드라이브를 먼저 잠금 해제한 다음 마운트한 다음 다른 드라이브에서 키 파일에 액세스를 시도하는 방법이 있는지 잘 모르겠습니다. 또한 자동화 측면에서 다른 드라이브를 마운트하기 전에 /etc/fstab 및 /etc/crypttab에 액세스할 수 있어야 한다고 생각하지만, 전체 / 파일 시스템이 LUKS 암호화된 경우에는 불가능합니다.
가능하지 않는 한LUKS 작동 방식에 대한 완전한 수동 구성:
Luks는 /dev/sdc1 usb_keyfile을 엽니다.
mount /dev/mapper/usb_keyfile /keyfile (이것이 가능합니까?)
LuksOpen --keyfile /keyfile/key /dev/sda1 disk1
LuksOpen --keyfile /keyfile/key /dev/sdb1 disk2
Luks는 /dev/sdc1을 닫습니다.
기본적으로 필요한 모듈이 로드되자마자 쉘 스크립트를 실행하고 자동 LUKS 비밀번호 프롬프트를 비활성화하는 기능입니다.
그 외 세부 사항
- 사용된 배포판: Gentoo GNU/Linux(amd64) 또는 Debian GNU/Linux(amd64). 이 프로세스를 여러 설치에 적용하고 싶기 때문입니다.
답변1
당신의 방법은 좋아 보입니다. 그러나 일부 의견은 다음과 같습니다.
rootfs를 암호화하려면 initrd를 사용해야 합니다(암호화된 파티션을 처리하기 위한 최소한의 암호화되지 않은 시스템 보유).
USB 장치가 제거 가능한 경우 변조 방지를 강화하기 위해 initrd와 커널을 모두 USB에 저장할 수 있습니다(USB가 승인되지 않은 손에 들어가지 않는다는 것을 보장한다는 가정 하에). 이는 대개 rootfs를 암호화하는 이유입니다. 커널과 initrd가 모두 이동식 미디어에 있으면 미디어를 간단히 제거하여 누구도 실행 중인 시스템에서 커널(또는 initrd)을 변경하지 못하도록 할 수 있습니다.
서버 내부에 설치하려는 경우 이는 확실히 옵션이 아니지만 다시 한 번 질문은 하드 드라이브 중 하나에 작은 파티션을 사용하는 대신 이러한 장치를 갖는 것이 합당한지 여부입니다. 예를 들어, 시스템의 모든 드라이브가 RAID에 있는 경우 rootfs를 USB에도 넣을 수 있습니다. 그런데 내부적으로 연결된 USB 플래시 장치에 대한 흥미로운 대안은 어댑터를 통해 ATA 인터페이스에 연결된 CompactFlash 카드입니다.
일부 배포판은 암호화된 루트에 대해 기성 솔루션을 제공하고 일부는 그렇지 않습니다. 그러나 대부분은 "실제" 루트를 마운트하기 전에 initrd 스크립트에 몇 줄의 코드를 입력하는 문제입니다(예를 들어 매뉴얼 페이지 참조).
pivot_root
일반적으로 섹션 2(syscall) 및 8(프로시저에 익숙하지 않은 경우 보조)에 있습니다.USB 드라이브가 손상될 경우를 대비해 백업 키와 비밀번호를 기억해 두세요. LUKS는 헤더 손상과 관련하여 다소 일방적인 접근 방식을 취합니다. 헤더의 단일 섹터(보다 정확하게는 키웨이)가 죽으면 이를 마운트할 수 없습니다. 이는 장치 자체에서 수행되는 블록 재할당으로 인해 헤더 삭제가 효과적으로 방해되지 않도록 하기 위한 것입니다(플래시 기반 장치가 흔히 수행하는 방식). 키는 전체 키 슬롯에 분산되며 모든 데이터를 재구성해야 합니다. - 아니요 중복성. 바라보다클레멘스 프루어스 홈페이지좀 더 깊이 있는 토론을 해보세요.
즉, 아마도 USB의 간단한 암호화 장치로 충분할 것입니다(참고 자료
PLAIN MODE
섹션 참조man cryptsetup
). 또는 암호화된 파일 등을 사용하세요openssl enc
. 암호화된 파티션 자체의 경우에도 전자가 실제로 옵션일 수 있습니다.