디스크 암호화를 사용한 사전 부팅 인증은 기술적으로 어떻게 작동합니까?

디스크 암호화를 사용한 사전 부팅 인증은 기술적으로 어떻게 작동합니까?

저는 듀얼 부팅 SSD 드라이브를 완전히 암호화할 수 있는 솔루션을 찾고 있습니다(아직 새 제품이고 비어 있어서 드라이브에 아무것도 넣기 전에 암호화를 설정하고 싶습니다).

해당 질문에 관해 웹상에는 많은 혼란이 있지만, 추가 부팅 디스크에 부트 로더가 필요할 수도 있지만 TrueCrypt가 이 작업을 수행할 수 있는 것으로 보입니다. 내가 읽은 바에 따르면 일부 Linux 도구(일부 수정된 GRUB2 포함)도 이를 수행할 수 있습니다.

그러나 나는 의심이 들며, 내가 읽은 기사 중 기본적인 질문에 답할 만큼 깊이 있는 기사는 없었습니다. 전체 디스크가 암호화되어 있고 일부 사전 부팅 도구가 사용자에게 이를 해독할 키를 요청하는 경우, 그렇지 않습니까? 이 도구가 부팅할 OS 아래에서 실행되어야 한다는 뜻인가요? 즉, OS가 보는 디스크가 실제로 암호화되어 있다는 사실을 인식하지 못하게 하는 도구가 있습니까?

그러한 도구가 없다면, 이는 암호 해독 도구가 부팅 시 암호 해독 정보를 OS에 전달해야 한다는 의미가 아닙니까? 크로스 플랫폼에서는 이것이 어려울 것이라고 상상할 수 있습니다.

답변1

전체 디스크가 암호화되어 있고 일부 사전 부팅 도구가 사용자에게 이를 해독하기 위한 키를 요청하는 경우 이는 이 도구가 부팅할 OS 아래에서 실행되어야 한다는 의미가 아닙니까?

네, 꽤 그렇습니다.하드웨어 기반 전체 디스크 암호화암호화는 장치(하드 디스크/플래시)에 의해 완전히 처리되거나 물리적 장치로 연결되는 체인을 따라 컨트롤러에서 처리되며 OS에는 "표시"되지 않습니다.
이를 통해 OS는 암호화되지 않은 일반 장치를 처리하는 것과 똑같이 I/O를 수행합니다. 마법 같은 일은 하드웨어(및/또는 펌웨어 - 어떤 경우든 OS "아래")에서 발생합니다.

그러한 도구가 없다면, 이는 암호 해독 도구가 부팅 시 암호 해독 정보를 OS에 전달해야 한다는 의미가 아닙니까?

OS "아래에서" 암호화를 수행할 수 없는 경우(위와 같이 또는 가상화 기술을 사용하여) 실제로 어떤 형태의 정보 전송이 필요하지만 두 개(또는 그 이상의) OS가 실행되고 있는 경우가 있습니다. 그리고 그렇습니다. 이는 크로스 OS가 어렵다는 것을 의미합니다.
또한 하드웨어/펌웨어 지원이 없는 경우 암호화를 해제하려면 부스트랩 코드(최소한 부트로더)가 필요합니다.

위키피디아디스크 암호화기사에 이에 대한 자세한 내용이 있습니다.

답변2

암호화된 드라이브에 대한 하드웨어(더 정확하게는 펌웨어, 즉 BIOS) 지원이 있는 경우 펌웨어로 전체 디스크를 암호화할 수 있습니다. 그렇게 하는 데는 단점이 있습니다. 주변에 디스크 암호화를 지원하는 컴퓨터가 많지 않고 이로 인해 특정 펌웨어에 연결됩니다. 더 나쁜 것은 컴퓨터에 TPM이 있고 암호화 키가 TPM에 있는 경우 스토리지 암호화 키를 백업하지 않은 경우 이 특정 마더보드에 적용됩니다.

운영 체제가 암호화를 수행하는 경우 운영 체제의 초기 부분이 저장되는 암호화되지 않은 작은 공간이 디스크에 있어야 합니다. Linux의 일반적인 구성은 별도의 일반 텍스트 파티션을 갖고 /boot다른 모든 파티션을 암호화하는 것입니다. "전체 디스크 암호화"는 약간 잘못된 이름입니다. 일반적으로 볼륨이 디스크가 아닌 파티션인 "전체 볼륨 암호화"를 의미하는 데 사용됩니다. 전체 디스크 암호화는 모든 파일(또는 최소한 디렉터리 트리)을 별도로 암호화하지 않는 경우입니다.

Linux에서 전체 디스크 암호화를 위한 표준 도구는 다음과 같습니다.디엠크립트. 모든 주요 배포판에서 사용할 수 있으며 많은 설치 프로그램에 통합되어 있습니다.

답변3

예, Grub2를 사용하면 /bootLUK로 파티션을 암호화할 수 있습니다.

  • /boot/LUK 암호화 파티션의 폴더로
  • /boot파티션에서 암호화된 LUK에 대해
  • 그리고 Linux에서는 정렬되지 않은 차단 목록을 장치로 사용할 수 있으므로 루트가 될 수 있습니다(initramfs는 정렬되지 않은 차단 목록에 대해 구성하기가 매우 복잡하지만 수행할 수 있습니다. 이는 편집증적인 방식입니다)

나는 또한 둘 이상의 레이어로 암호화하는 편집증적인 방법 /boot(파티션인 경우)을 테스트했습니다.

  1. /dev/sda5디스크의 유일한 논리 파티션(2개의 확장 파티션만 있는 MBR /boot/)
  2. 위에 /dev/sda5LUK를 레벨 1로 설정하고 다음과 같이 매핑했습니다./dev/mapper/level_0001
  3. 나는 LUK 레벨 2를 다음과 같이 /dev/mapper/level_0001매핑했습니다./dev/mapper/level_0002
  4. /dev/mapper/level_0002나는 LUK 레벨 3을 다음과 같이 매핑했습니다 ./dev/mapper/level_0003
  5. 그리고 그 위에 /dev/mapper/level_####LUK 레벨을 넣어서 ####+1매핑했습니다./dev/mapper/level_####+1
  6. 위에 /dev/mapper/level_3436LUK 레벨 3437을 매핑했습니다./dev/mapper/level_3436
  7. 위에는 /dev/mapper/level_3437Ext4를 놓고 다음과 같이 마운트했습니다./boot
  8. /boot실행 후 Grub2를 설치합니다 .echo GRUB_CRYPTODISK_ENABLE=y >> /etc/default/grub
  9. 나는 한 레벨의 LUK만 /dev/sda6사용했습니다 ./

부팅할 때 3437개의 서로 다른 비밀번호를 묻는데, 각각에 32자 이상의 문자를 사용합니다.

단지 개념 증명일 뿐이며 부팅 시간이 끔찍합니다.

하지만 동일한 작업을 수행하면 /모든 시스템 읽기/쓰기 속도도 끔찍하지만 적어도 Linux는 작동합니다. 나는 또한 만 개가 넘는 레벨을 테스트했습니다. 부분적으로 작동하고, 내 CPU에서 읽기/쓰기 속도가 10KiB/s(예, 정말 끔찍합니다)로 떨어지고, 부팅하는 데 하루가 걸리고, 온라인 액세스(서핑 등)를 수행할 때 디스크 시간 초과로 인해 응용 프로그램이 많이 충돌하는 경향이 있습니다. .

따라서 3개 또는 4개 레벨의 LUK를 배치하는 것이 허용되며 10개도 허용됩니다. 이는 CPU와 CPU 대 DISK, 3D 렌더 대 거대한 데이터 스크램블 등을 사용하는 대상에 따라 크게 달라집니다.

PD: LUK의 각 수준에서 서로 다른 해시 함수와 알고리즘을 사용할 수도 있고 --iter-time=#마운트 시간을 더 크게 만드는 데 사용할 수도 있습니다(경고: Grub2 사전 부팅에서는 약 1만 원인 값을 사용하면 마운트 시간이 3~4배 더 길어집니다). 부팅 전 거의 30초).

관련 정보