사전 암호화 지우기, 왜?


25

Kali 드라이브에 암호화하고 설치 하기 전에 왜 그런지 알고 싶었습니다 .

  1. 전체 드라이브를 닦아
  2. 드라이브를 0으로 채웠다
  3. 드라이브를 1로 채웠다
  4. 임의의 데이터로 드라이브를 채웠다
  5. 드라이브를 다시 닦아

칼리가 설치되어 있지는 않지만 여기서 중요한 것은 아닙니다.

그렇다면 새로운 HDD에 설치하기 전에 이것이 어떻게 유용합니까? 나는 HDD 제거시 설치가 아니라는 것을 알았습니다.


1 ~ 3 단계 badblocks는 불량 섹터를 확인하고 0과 1, 01, 10을 쓰고 확인 하는 것과 비슷합니다 . 전체 디스크 암호화의 경우 frostschultz의 답변 (+1)으로 인해 암호화 된 제로 채우기 (모든 곳에서 암호화 된 데이터를 작성)를 권장하는 것이 일반적이지만 , 암호화 후 실행 또는 mkfs 가 달성 한 후 암호화 하기 전에이 모든 작업을 수행하는 것은 이례적인 일 입니다 마찬가지로 불량 블록을 식별합니다. 어쩌면 칼리의 누군가가 플래시 메모리 (USB, SSD)가 같은 장소에서 항상 같은 섹터를 쓰지 않고 백업과 섹터를 바꾸는 것이 아니라는 점에 대해 약간의 편집증이있을 수 있습니다.badblocks-cc
Xen2050

답변:


36

여러 패스를 수행 할 필요가 없습니다. 한 번이면 충분합니다.

무작위 데이터로 암호화 할 드라이브를 채우는 데는 주로 두 가지 용도가 있습니다.

  • 오래된 암호화되지 않은 데이터 제거
  • 암호화 된 데이터로 여유 공간을 확보 할 수 있습니다

일반적으로 암호화하면 다른 사람이 내 데이터를 보지 못하게합니다. 따라서이 드라이브에 암호화되지 않은 오래된 데이터가있는 경우이 드라이브도 제거 할 수 있습니다. SSD를 사용하면 더 쉽고 빠르게 처리 할 수 ​​있습니다 blkdiscard. 실제로 Linux mkfs는 확인 요청없이 모든 데이터를 트리밍하므로 모든 종류의 데이터 복구가 불가능합니다. Linux에 TRIM이 너무 많습니다.

여유 공간은 약간 회색 영역입니다. 새로운 HDD에서 임의의 데이터를 미리 채우지 않으면 쓰여지지 않은 섹터는 0이됩니다. SSD에서 폐기 / TRIM을 허용하면 여유 공간도 0이됩니다.

이는 데이터에 영향을주지 않지만 (여전히 암호화되어 있음) 보유한 여유 공간 / 실제 데이터의 양과이 여유 공간 / 데이터의 위치를 ​​나타냅니다. 예를 들어, hexdump -C암호화 된 트림 된 SSD의 모양은 다음과 같습니다.

# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0  dc c9 c7 89 16 ca d3 4f  a3 27 d6 df a0 10 c3 4f  |.......O.'.....O|
b3eac000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f70000  5a 99 44 b5 9c 6b 1e 9c  81 cf 9a 43 b6 23 e9 0f  |Z.D..k.....C.#..|
b3f70010  2c e6 9a 5d 59 9b 46 5f  21 3f 4d 5f 44 5b 0a 6b  |,..]Y.F_!?M_D[.k|
--
b3f70ff0  5f 63 8d e8 c4 10 fd b1  a6 17 b5 7d 4a 57 09 68  |_c.........}JW.h|
b3f71000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f72000  5d 1c 09 dd c9 6b 57 18  db 67 e1 35 81 57 45 8e  |]....kW..g.5.WE.|
b3f72010  0f a8 be 39 ae e5 5f cf  cf e3 8b a7 c1 25 1a a3  |...9.._......%..|
--
...

이것에서 당신은 내가 주소에 여유 공간이 세그먼트를 말할 수있다 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000... 그리고 그 역 같은 코스 데이터 세그먼트입니다 0xb3f70000 .. b3f71000.

그것으로 무엇을 할 수 있습니까? 음, 아무것도 없습니다 (*).

(*)는 내가 말하고 싶은 것입니다. 그러나 사람들은 창의적 입니다. 여유 공간 패턴을 사용하여 사용하는 파일 시스템 유형을 파생시킬 수 있습니다 (메타 데이터를 저장하는 방법 / 위치로 인해 ext4메타 데이터 백업 중 하나를 저장할 여유 공간이있는 경우에는 그렇지 않을 가능성 ext4등). 때로는 배포판을 보여 주기도합니다 (Linux 설치 프로그램이 파일 시스템을 결정적으로 채우면 파일은 항상 동일한 물리적 주소로 끝날 수 있음). 이 시점에서 누군가 특정 시스템 파일의 위치를 ​​알고 어떤 식 으로든 수정 / 손상 할 수 있습니다. (설치자는 파일 시스템을 채우는 방식을 무작위로 지정하여이를 방지해야합니다.)

그러나 이러한 고려 사항은 다른 이유로 인해 대부분의 암호화 된 설치가 얼마나 취약한 지에 비해 이론적으로 매우 위험합니다. 기본적으로 설치되는 대부분의 경우, 암호화 된 데이터에 대한 원시 액세스 및 분석을 통해 이러한 방식으로 모든 것을 달성하기를 기대하는 것보다 initramfs를 무단 변경하거나 키로거를 설치하거나 실행중인 시스템을 이용하는 것이 더 쉽고 간단합니다.

여유 공간을 공개하기 전에 먼저 걱정해야합니다.

SSD의 경우 TRIM을 활성화하는 것이 일반적으로 정상이므로 여유 공간이 항상 공개됩니다. 이는 블록 레이어가 아닌 파일 레이어에서 작동하는 암호화 솔루션의 경우에도 해당됩니다.

HDD를 사용하면 새 디스크에서도 무작위로 데이터를 지우는 것이 가능하기 때문에 비용이 들지 않으며 (처음 설정을 제외하고) 단점이 없기 때문에 그럴 이유가 없습니다.


1
트림 된 일부 낸드 플래시가 트림되지 않은 섹터와 같은 지우기 블록에있을 수 있기 때문에 트림은 실제로 트림 된 모든 NAND 플래시를 실제로 지울 필요는 없습니다. (삭제 블록은 쓰기 블록보다 큽니다). 새 메타 데이터를 쓰기 전에 mkfs가 전체 파티션을 트리밍하더라도 다른 파티션 (EFI 시스템 파티션 등)의 데이터는 여전히 활성 상태이며 SSD 펌웨어는 파티션에 대해 알지 못합니다.
Peter Cordes

답변에 en.wikipedia.org/wiki/Trim_(computing)에 대한 링크 가 유용 할 수 있습니다!
Gaurav
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.