Linux는 자체 암호화 디스크 API를 지원합니까?

에서 이 기사 BIOS ATA는 열쇠 글을 우회하는 것이 얼마나 쉬운 표시되며, 이는 OS 내에서 디스크 자체 암호화 디스크 (SED) API를 사용하여 성능 저하를 제공하지 않을 것이라고으로 끝납니다. Windows에서는이 API를 Microsoft eDrive라고합니다. 여기 와 여기를 참조 하십시오 .

리눅스가 SED 레이어와 직접 통신 할 수 있는지 아는 사람이 있습니까?

"SED 계층"에서 SED를 관리 할 수있는 GPL sedutil 을 찾았습니다 .

msed-자체 암호화 드라이브 관리

이 프로그램과 함께 제공되는 Pre-Boot Authorization 이미지를 사용하면 BIOS 시스템의 TCG OPAL 2.00 표준을 준수하는 SED의 잠금을 활성화 할 수 있습니다.

msed 의 저자는 Drive Trust Alliance와 협력 하여 GPL의 엔터프라이즈 솔루션을 만들었습니다.

저는 최고의 오픈 소스 SED 도구를 커뮤니티에 제공하기 위해 Drive Trust Alliance (GitHub의 Drive-Trust-Alliance)와 협력하고 있습니다.

이것이 정말로 당신이 원하는 질문에 대답하는지 모르겠습니다. 그러나 나는이 페이지의 정보를 사용했다 : https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

자체 암호화 SSD가 있습니다. hdparm 명령을 사용하여 사용자 비밀번호, 마스터 비밀번호를 설정하고 마스터 비밀번호 기능을 "최대"로 설정하여 마스터 비밀번호를 잠금 해제 또는 비활성화 할 수 없도록 설정했습니다. (BIOS에서 마스터 암호 또는 마스터 모드를 설정할 수 없었습니다. 제조업 (Dell)에 마스터 암호가 있고 아마도 모든 서비스 담당자가 암호를 얻을 수 있기 때문에 이것은 안전하지 않습니다.)

올바른 BIOS / UEFI는 드라이버가 잠금을 해제하고 정지시켜 OS가 암호를 비활성화 할 수 없도록해야합니다. 펌웨어가 드라이브를 고정 해제 상태로두면 암호를 비활성화하는 방법을 알 수 있습니다.

그러나이 모든 것들은 드라이브 펌웨어가 백도어 나 보안 허점을 갖지 않는다고 신뢰한다고 가정합니다. 인용 한 기사는 이것이 일반적임을 암시하는 것 같습니다. 기사에 따르면 드라이브가 이미 잠금 해제되어 있어야하므로 BIOS 레벨이 얼마나 "쉽게"이기는지 의문이 듭니다. 이 기사에서는 드라이브 보안이 동결되었는지 여부를 밝히지 않았습니다.

드라이브 펌웨어를 신뢰할 수없는 경우 ATA 암호 기능이 어떻게 도움이되는지 모르겠습니다. 드라이브 HW를 계속 활용하려면 AES 엔진 자체에 액세스하고 AES 키를 직접 프로그래밍 할 수 있어야합니다.

{나는 그런 HW 레벨 API를 모른다. 누군가 참조가 있으면 관심이 있습니다.}

대답하기 전에 모든 참고 문헌을 읽어 보시기 바랍니다. 해당 표준은 TCG Opal 2.0 및 IEEE-1667입니다. 1667은 ATA의 일반 텍스트 암호 교환을 통해 챌린지 응답 프로토콜로 이동 한 것으로 보입니다. 그러나 암호는 여전히 드라이브에 저장되어 있으며 드라이브 펌웨어를 신뢰해야합니다.