LUKS 암호화 볼륨만 포함된 디스크가 있습니다. 이는 cryptsetup v.1.6.1을 사용하여 파티션 테이블이 없는 베어 드라이브에 생성되었습니다. 잠금이 해제되면 복호화된 볼륨의 크기를 확인하고 전체 디스크와 비교해 보면 그 차이가 정확히 2MB인 것을 확인할 수 있습니다. 반면에 헤더를 백업할 때는 다음을 사용합니다.
cryptsetup luksHeaderBackup /dev/sda --header-backup-file <filename>
2MB보다 30kB 작은 파일을 얻었습니다. dd를 사용하여 디스크의 처음 2MB를 덤프하고 이를 백업된 헤더와 비교하면 30KB가 끝에서 누락되고 모두 0이 포함되어 있음을 알 수 있습니다. 이상하게도 cryptsetup 1.4.1 및 1.4.3을 사용하여 다양한 (다른) LUKS 헤더의 백업이 있는데 모두 정확히 2MB입니다. 이는 다음과 일치합니다.cryptsetup FAQ의 섹션 6.2, 헤더 크기가 2MB여야 함을 나타냅니다.
누군가 이 30KB가 무엇인지 이해하도록 도와줄 수 있습니까? (헤더를 별도의 장치에 넣었기 때문에 임의의 데이터로 헤더를 덮어쓰고, 내가 무엇을 하고 있는지 확인하고 싶습니다.)
또한 보다 일반적인 문제로서 luksDump의 출력을 사용하여 디스크에서 헤더의 위치를 정확하게 알려주는 더 쉽고/자동화된 방법이 있습니까? (오프셋과 크기 모두.) cryptsetup FAQ를 읽었지만 결과는 확실히 사라지지 않습니다.
그리고 dd를 사용하는 것보다 헤더를 덮어쓰는 더 좋은 방법이 있습니까?
cryptsetup luksHeaderRestore <file_with_random_data>
cryptsetup은 이미 존재하는 헤더가 마스터 키 크기 및 오프셋과 일치하는지 확인하기 위해 몇 가지 바보 검사를 수행하기 때문에 작동하지 않습니다.
답변1
30k는 사용되지 않은 공간이지만 헤더 데이터는 1MB로 정렬되었습니다. 이전 버전의 cryptsetup으로 백업할 때 전체 2MB가 포함되었지만 이후 버전에서는 이를 생략합니다.
(512B 섹터 수) 의 payloadOffset 출력을 사용하면 cryptsetup luksDump
암호화된 볼륨이 시작되는 오프셋을 볼 수 있습니다. 거기까지 수동으로 닦을 수 있습니다. 또는 cryptsetup 1.6.4부터 cryptsetup luksErase
모든 활성 키 슬롯을 덮어쓰는 데 사용할 수 있습니다 . 메타데이터가 포함된 나머지 표시 헤더는 디스크의 처음 4KB이므로 수동으로 지워야 합니다.
[cryptlab의 cryptsetup 개발자 중 한 명인 Milan에게 감사드립니다!]