%EC%9D%98%20%EC%95%85%EC%9D%98%EC%A0%81%EC%9D%B8%20%EC%88%98%EC%A0%95%EC%9D%84%20%EC%96%B4%EB%96%BB%EA%B2%8C%20%EC%A4%91%EC%A7%80%ED%95%A9%EB%8B%88%EA%B9%8C%3F.png)
이것은 ecryptfs 개발자가 ecryptfs와 dm-crypt의 차이점을 설명하는 페이지입니다.https://stackoverflow.com/questions/18230784/what-is-difference-between-linux-kernel-subsystem-dm-crypt-and-ecryptfs/18234635#18234635. 그러나 이로 인해 ecryptfs가 /home파티션만 암호화하는 경우 악의적인 해커가 파티션을 수정하여 암호화 비밀번호를 스니핑하거나 프로그램 등을 수정하는 등의 작업을 /막는다 는 질문이 생겼습니다 ./boot
간단히 말해서, 권한이 없는 사람이 내 컴퓨터의 데이터를 읽을 수 없을 뿐만 아니라 내가 모르는 사이에 내 컴퓨터의 어떤 것도 수정되지 않는다는 것을 어떻게 확신할 수 있습니까?
또한 프로세서가 부팅 코드를 이해하려면 어느 시점에서 부팅 코드를 암호화 해제해야 하므로 이것이 끝나는 곳은 어디입니까? (일종의 하드웨어 암호 해독을 사용하지 않는 한) 하지만 정의에 따르면 암호화되지 않은 모든 항목을 수정할 수 있습니까?
(부담으로, 부팅 코드의 암호화되지 않은 부분의 해시를 암호화된 부분에 유지하고 암호 해독 시 미리 계산된 해시를 암호화되지 않은 부분의 해시와 비교하여 부팅 시퀀스의 무결성을 결정하는 방법을 볼 수 있습니다. 그러나 이는 암호화되지 않은 영역이 있는 문제를 해결하지 못하며, 나중에 무언가 수정되었는지 알 수 있는 방법일 뿐입니다.
답변1
짧은 대답은 "매우 적다"는 것입니다. 해커가 /boot를 수정하는 것을 막는 것은 실제로는 시간, 감지되지 않은 물리적 액세스 및 키 로거를 사용하여 initrd를 다시 컴파일하는 기능뿐입니다.
물리적 시스템에 액세스할 수 있는 경우 악의적인 해커가 ecryptfs 기반 / 또는 /boot를 수정하는 것을 막을 수 있는 방법은 없습니다. 하지만 나중에 살펴보겠습니다. 이것이 의미하는 바는 아닙니다.
"/"는 LUKS와 같은 전체 디스크 암호화를 사용하여 보호할 수 있습니다(그러나 제가 아는 한 파일별 암호화는 아닙니다). 시스템이 처음에 /boot에서 부팅되므로 initrd는 /를 마운트하기 전에 볼륨 잠금을 해제하는 데 필요한 암호를 요청할 수 있습니다.
나는 귀하가 전체 디스크 암호화의 능력을 과대평가하고 있다고 생각합니다. 노트북 도난이나 개인 정보가 포함된 하드 드라이브를 RMA하려는 경우와 같은 비지속적 위협으로부터 사람들을 보호하도록 설계되었다는 점을 알려드립니다. 두 경우 모두 데이터가 더 이상 사용되지 않지만 알 수 없는 제3자가 해당 데이터에 액세스하는 것을 막고 싶고, 매우 자주 문서의 파일 기반 암호화가 적절합니다. 시스템의 암호화되지 않은 복사본이 있는지 누가 신경쓰나요? 바이너리 - 어쨌든 오픈 소스입니다.
로컬 액세스 권한이 없는 사람으로부터 시스템을 보호할 수 없으므로 이에 대한 해결책은 물리적 액세스를 방지하는 것입니다. 모든 시스템 파일을 체크섬하고 오프라인 백업과 비교하여 사용자 모르게 수정되지 않도록 할 수 있습니다. 이는 수정되지 않은 체크섬 프로그램을 실행하고 있는지 확인해야 하기 때문에 완벽하지는 않습니다. 충돌 해시를 다시 만드는 것이 사실상 불가능해집니다. [ 파일 시스템을 분리하고 그 중 일부를 읽기 전용으로 만든 다음 각 읽기 전용 파티션에 대해 단일 해시를 유지하면 이를 단순화할 수 있습니다.] 하지만 이 모든 과정은 번거롭습니다.
전체 디스크 암호화 "/"를 사용하는 경우 일반적으로 업그레이드 등을 제외하고는 컴퓨터를 "루트"로 사용하지 않습니다.