Xóa tiền mã hóa, tại sao?


25

Tôi muốn biết tại sao, trước khi mã hóa và cài đặt chính nó vào ổ đĩa, Kali:

  1. xóa sạch toàn bộ ổ đĩa
  2. lấp đầy ổ đĩa bằng 0s
  3. lấp đầy ổ đĩa với 1s
  4. điền vào ổ đĩa với dữ liệu ngẫu nhiên
  5. lại lau ổ đĩa

Tôi biết rằng Kali không có nghĩa là sẽ được cài đặt, nhưng đó không phải là vấn đề ở đây.

Vì vậy, làm thế nào là hữu ích trước khi cài đặt, nói trên một ổ cứng hoàn toàn mới? Tôi đã từng thấy rằng trên ổ cứng, không phải cài đặt.


Các bước 1-3 nghe có vẻ giống với những gì badblockscần kiểm tra các thành phần xấu, viết và kiểm tra 0, 1, 01, 10. Đối với mã hóa toàn bộ đĩa, người ta thường khuyên dùng zero-fill được mã hóa (để ghi dữ liệu được mã hóa ở mọi nơi) vì lý do trong câu trả lời của frostschultz (+1), nhưng thực hiện tất cả điều này trước khi mã hóa là bất thường, sau khi mã hóa thì chạy badblockshoặc mkfs -ccsẽ hoàn thành giống nhau, cộng với xác định khối xấu. Có lẽ ai đó ở Kali hơi hoang tưởng về bộ nhớ flash (USB, SSD) không phải lúc nào cũng viết cùng một khu vực ở cùng một nơi và hoán đổi các lĩnh vực thành / từ các bản sao lưu
Xen2050

Câu trả lời:


36

Không có điểm nào trong việc thực hiện nhiều đường chuyền. Một lần là đủ.

Việc lấp đầy một ổ đĩa được mã hóa với dữ liệu ngẫu nhiên chủ yếu có hai cách sử dụng:

  • thoát khỏi dữ liệu cũ, không được mã hóa
  • làm cho không gian trống không bị phân biệt từ dữ liệu được mã hóa

Thông thường nếu bạn mã hóa, bạn không muốn ai nhìn thấy dữ liệu của mình. Vì vậy, rất có thể, nếu bạn có dữ liệu cũ, không được mã hóa trên ổ đĩa này, bạn cũng muốn thoát khỏi nó. Một ổ SSD có thể chăm sóc nó dễ dàng hơn và nhanh hơn với blkdiscard. Trong thực tế, Linux mkfsTRIMs tất cả dữ liệu mà không yêu cầu bạn xác nhận, điều này làm cho bất kỳ loại phục hồi dữ liệu nào là không thể. Có quá nhiều TRIM trong Linux.

Không gian trống là một chút của một khu vực màu xám. Nếu bạn không điền trước dữ liệu ngẫu nhiên, trên một ổ cứng hoàn toàn mới, các lĩnh vực không bao giờ được ghi vào sẽ là số không. Trên ổ SSD, nếu bạn cho phép loại bỏ / TRIM, dung lượng trống cũng sẽ bằng không.

Mặc dù điều này không ảnh hưởng đến dữ liệu của bạn theo bất kỳ cách nào (nó vẫn được mã hóa), nhưng nó cho thấy bạn có bao nhiêu dung lượng trống / dữ liệu thực tế và vị trí của không gian / dữ liệu miễn phí này. Ví dụ: một hexdump -Cổ SSD được mã hóa, cắt xén sẽ trông giống như thế này:

# 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.._......%..|
--
...

Từ đây bạn có thể nói tôi có phân đoạn không gian miễn phí tại địa chỉ 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000... và nghịch đảo của đó là các phân đoạn dữ liệu trình như 0xb3f70000 .. b3f71000.

bạn có thể làm gì với nó? Cũng không có gì(*).

(*) là những gì tôi muốn nói. Nhưng mọi người có được sáng tạo . Các mẫu không gian trống có thể được sử dụng để lấy loại hệ thống tệp bạn sử dụng (do cách thức / nơi họ lưu trữ siêu dữ liệu - nếu có không gian trống nơi ext4lưu trữ một trong các bản sao lưu siêu dữ liệu của nó, thì rất có thể là không ext4, v.v.). Đôi khi, nó thậm chí còn tiết lộ phân phối nào bạn sử dụng (nếu trình cài đặt Linux của bạn điền vào hệ thống tệp một cách xác định, các tệp có thể luôn luôn ở cùng một địa chỉ vật lý). Tại thời điểm đó, ai đó có thể biết vị trí của một tệp hệ thống cụ thể và có thể sửa đổi / làm hỏng nó theo một cách nào đó. (Trình cài đặt nên chọn ngẫu nhiên cách chúng điền vào các hệ thống tệp để ngăn chặn điều này.)

Tuy nhiên, những cân nhắc như vậy là rất lý thuyết và rủi ro rất thấp so với mức độ dễ bị cài đặt mã hóa nhất là do các lý do khác. Trong hầu hết các cài đặt ngoài hộp, sẽ dễ dàng hơn / đơn giản hơn là chỉ can thiệp vào initramfs hoặc cài đặt keylogger hoặc khai thác hệ thống đang chạy, bằng cách nào đó có được quyền truy cập thô và phân tích dữ liệu được mã hóa và hy vọng đạt được mọi thứ theo cách này.

Bạn nên lo lắng về những điều này trước khi lo lắng về việc tiết lộ không gian trống.

Với SSD, việc bật TRIM là hoàn toàn bình thường và do đó luôn có không gian trống được tiết lộ. Đây cũng là trường hợp cho các giải pháp mã hóa hoạt động trên một lớp tệp chứ không phải lớp khối.

Với ổ cứng, bạn chủ yếu thực hiện xóa ngẫu nhiên ngay cả trên một đĩa mới bởi vì bạn có thể, và không có lý do gì để không phải trả phí (ngoài thiết lập lần đầu) và không có nhược điểm.


1
Trim không nhất thiết thực sự xóa tất cả đèn flash NAND được cắt xén, bởi vì một số trong số đó có thể nằm trong cùng khối xóa như một số khu vực không được cắt xén. (khối xóa lớn hơn khối ghi). Ngay cả khi mkfs cắt toàn bộ phân vùng trước khi viết siêu dữ liệu mới, dữ liệu từ các phân vùng khác (như phân vùng hệ thống EFI) vẫn hoạt động và phần sụn SSD không biết về phân vùng.
Peter Cordes

Liên kết đến en.wikipedia.org/wiki/Trim_(computing) có thể hữu ích trong câu trả lời của bạn!
Gaurav
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.