Một cách tiếp cận khác cho vấn đề cụ thể này là sử dụng TPM để lưu trữ khóa mã hóa, nhưng việc phòng thủ không phụ thuộc vào người dùng để làm cho nó hiệu quả. Một giải pháp thô sơ, dựa trên RHEL7 là tpm-luks ( https://github.com/GeisingerBTI/tpm-luks ).
Cách thức hoạt động của nó là khi khởi động, mỗi bước của quy trình khởi động sẽ đo bước tiếp theo và lưu trữ phép đo này vào các PCR trên TPM. Khi quá trình khởi động hoàn tất, tpm-luks sẽ kiểm tra trạng thái của các PCR dựa trên cấu hình "đã biết". Nếu trong cấu hình "đã biết", TPM sẽ bỏ khóa khóa LUKS và tpm-luks sẽ truyền dữ liệu này để mở khóa phân vùng LUKS gốc.
Bởi vì mọi thứ quan trọng đều được đo bằng hàm băm của crpytographic, về cơ bản không có cách nào để một cô hầu gái độc ác thay thế GRUB / kernel / ramdisk của bạn để thu thập mật khẩu FDE của bạn một cách chính xác. Là một phần thưởng bổ sung, bạn hoàn toàn không cần cụm mật khẩu FDE! Về lý thuyết, bạn có thể loại bỏ hoàn toàn cụm mật khẩu có thể đọc được của con người và hoàn toàn dựa vào tpm-luks, nhưng nếu bạn đi theo con đường đó, có lẽ nên lưu trữ tiêu đề LUKS của bạn và giữ nó làm bản sao lưu.
Như tôi đã đề cập, điều này đòi hỏi một số sự siêng năng đối với người dùng. Nếu bạn để máy tính không giám sát và bạn được hiển thị một dấu nhắc mật khẩu, có lẽ đó là một ý tưởng tồi để nhập nó cho đến khi bạn thực hiện một số điều tra. Tại thời điểm đó, bạn nên khởi động vào môi trường CD trực tiếp và xem thử xem có lỗi trong tpm-luks hay không, nếu /boot
phân vùng thực sự bị thay đổi. Bạn vẫn đang để /boot
phân vùng không được mã hóa, nhưng nếu bất cứ điều gì quan trọng bị thay đổi, đĩa chính sẽ không bao giờ được giải mã.