많은 사람들이 실제로 알지도 못하고 신경도 쓰지 않고 "Linux를 실행"합니다. 많은 가정용 라우터, 탐색 보조 장치, 웹캠 및 기타 IoT 장치가 Linux를 기반으로 합니다. 전 세계 휴대전화의 대부분은 Android라는 Linux 파생 변종을 실행합니다. 그리고 대부분은 아니지만 대부분의 즉시 사용 가능한 클라우드 서비스가 Linux에 의존하여 콘텐츠를 호스팅합니다.
그러나 많은 사용자와 시스템 관리자는 단순히 "Linux를 사용"하는 것이 아니라 Linux가 실행되는 수백, 수천, 심지어 수백만의 다른 사람들의 데스크탑, 랩톱 및 서버를 책임지고 있습니다.
이러한 시스템 관리자는 일반적으로 자신의 관할 하에 있는 시스템이 안정적으로 실행되고 있는지 확인하는 것뿐만 아니라 시스템을 가능한 한 안전하게 유지할 책임이 있습니다.
오늘날의 세계에서 그것은 거의 확실히 일종의 지식, 이해, 배포 및 관리를 의미합니다. 전체 디스크 암호화 시스템, 그리고 Linux에서는 아마도 LUKS(Linux 통합 키 설정) 및 라는 프로그램 cryptsetup 그것을 돌보기 위해.
승리를 위한 FDE
전체 디스크 암호화, 일반적으로 간단히 FDE, 간단하지만 효과적인 아이디어입니다. 모든 섹터가 속한 소프트웨어, 사용자, 파일 또는 디렉토리에 관계없이 디스크에 쓰기 직전에 모든 섹터를 암호화합니다. 다시 읽은 직후 모든 섹터를 해독하십시오.
FDE는 기본적으로 모든 것에 대해 하나의 암호가 있기 때문에 자체적으로 충분하지 않으므로 일반적으로 그 위에 파일별, 앱별 또는 사용자별 암호 보호 수준을 추가로 계층화하게 됩니다.
그러나 FDE는 요즈음, 특히 랩톱의 경우 정확히 같은 이유로 필수로 간주될 수 있습니다. 모든 것에 대해 최소한 하나의 암호가 있으므로 암호화되지 않은 것이 남아 있지 않습니다.
FDE를 사용하면 암호화하는 것을 잊어버린 파일에 대해 걱정할 필요가 없습니다. 또는 핸드오버를 준비하는 동안 암호화된 폴더에서 암호화되지 않은 폴더로 만든 임시 사본 또는 다음과 같은 메뉴 옵션을 사용할 때 즐겨 찾는 앱에서 불가피하게 생성되는 짜증나게 많은 중간 파일 Export, Compile or Print.
FDE를 사용하면 디스크의 사용되지 않은 부분, 삭제된 섹터, 파일 이름, 스왑 파일 데이터, 사용 중인 앱, 설치한 운영 체제 파일, 의도적으로 XNUMX으로 만든 디스크 공간을 포함하여 모든 것이 암호화됩니다. 이전에 있던 것을 강제로 덮어씁니다.
결국, 암호화되지 않은 상태로 남겨두고 랩톱을 도난당하는 경우 디스크의 데이터는 도둑이나 이를 판매하는 사이버 범죄자에게 별로 쓸모가 없습니다.
이제 없어진 랩톱에 실제로 FDE를 설치했음을 보여줄 수 있다면, 마음에 손을 대고 감사관, 규제 기관, 고객, 심지어 호기심 많은 언론인에게 맹세할 수 있습니다! – 도난당한 노트북이 다크 웹에 표시되는 경우 두려워할 것이 거의 또는 전혀 없습니다.
FDE는 녹색으로 간주됨
더 좋은 것은 오래된 장비를 폐기하려는 경우(특히 안정적으로 작동하지 않는 경우) 일반적으로 FDE는 일반적인 재사용 또는 재활용을 위해 오래된 장비를 보내는 것을 훨씬 덜 논란으로 만듭니다.
FDE는 숨은 의도가 있는 누군가가 재활용 회사에서 노후된 키트를 구입하고 오래된 디스크 드라이브를 추출하여 어떻게든 다시 되살리는 경우 재미와 이익을 위해 이전 데이터를 쉽게 버릴 수 없다는 것을 의미합니다.
FDE가 없으면 오래된 저장 장치는 약간 핵폐기물과 같아집니다. "용도 변경"을 위해 감히 신뢰할 수 있는 사람이 거의 없기 때문에 일반적으로 "아직 이것을 어떻게 해야 할지 잘 모르겠습니다. ” 디스크 드라이브를 사용하거나 환경 친화적이지 않은 힘든 장치 폐기 프로토콜을 사용합니다.
(늙어가는 재료 용광로에 들어가는 것은 빠르고 효과적입니다. 법 집행 팀이 이것을 하고, TV로 생중계하고, 풍토병을 줄이기 위한 무기 사면을 한 후 - 그러나 맹목적으로 컴퓨터 키트와 그 많은 에스테릭 금속과 폴리머를 증발시키는 것은 더 이상 용납될 수 없는 얼굴입니다. "보안 삭제".)
하지만 버그가 있다면?
FDE의 문제점 - 그리고 그 못지 않게 중요한 것은 FDE를 안정적으로 관리하는 데 도움이 되는 소프트웨어 도구가 잘못하기 쉽다는 것입니다.
올바른 암호화 알고리즘을 사용했습니까? 암호화 키를 안정적으로 생성했습니까? 데이터 무결성 문제를 올바르게 처리했습니까? 비밀번호를 안전하고 빠르게 변경할 수 있습니까? 실수로 자신을 잠그는 것이 얼마나 쉬운가요? 기업 정책이 발전함에 따라 암호화 매개변수를 조정하려면 어떻게 합니까?
불행히도 cryptsetup 위의 질문을 해결하는 방식으로 Linux FDE를 관리하는 데 널리 사용되는 프로그램에는 CVE-2021-4122, 라는 유용한 기능에서 재암호화.
잘 설계된 FDE 솔루션은 다음과 같은 몇 가지 합당한 이유로 귀하의 비밀번호를 낮은 수준의 원시 암호화 키로 직접 사용하지 않습니다.
- 저수준 키를 변경한다는 것은 전체 디스크를 복호화하고 재암호화하는 것을 의미합니다. 몇 시간이 걸릴 수 있습니다.
- 여러 사용자가 단일 키를 공유해야 합니다. 따라서 동시에 다른 모든 사용자를 잠그지 않고는 한 사용자의 액세스 권한을 취소할 수 없습니다.
- 사용자는 종종 약한 암호를 선택하거나 암호 위반을 겪습니다. 방금 이런 일이 발생했다는 것을 알게 되면 비밀번호를 더 빨리 변경할 수 있을수록 좋습니다.
따라서 대부분의 FDE 시스템은 장치에 대한 마스터 암호를 선택합니다. LUKS의 경우 일반적으로 512비트 길이이며 커널의 고품질 랜덤 생성기에서 가져옵니다.
기본적으로 최대 8개까지의 암호 보유자는 LUKS가 호출하는 마스터 키의 개인 스크램블 버전을 생성하는 데 사용되는 개인 암호를 선택합니다. 키슬롯, 따라서 마스터 키 자체는 실제로 장치가 사용되는 동안 메모리를 제외하고는 어디에도 저장될 필요가 없습니다.
간단히 말해서, 유효한 사용자 키를 제공할 때까지 장치의 마스터 키를 파생시킬 수 없습니다. 사용자 키는 장치의 어디에도 저장되지 않습니다. 사용자 키와 마스터 키는 기본적으로 일반 텍스트 형식으로 표시되거나 저장되지 않습니다.
LUKS 장치에 대한 마스터 키를 덤프할 수 있지만 실수로 하기 어렵고 마스터 키 데이터를 생성하려면 유효한 사용자 키를 입력해야 합니다.
# cryptsetup luksDump /dev/sdb --dump-master-key 경고! ======== 볼륨 키가 있는 헤더 덤프는 암호 없이 암호화된 파티션에 액세스할 수 있는 민감한 정보입니다. 이 덤프는 안전한 장소에 암호화되어 저장되어야 합니다. 확실합니까? (대문자로 'yes' 입력): 예 /dev/sdb에 대한 암호를 입력하십시오. **************** /dev/sdb에 대한 LUKS 헤더 정보 암호 이름: aes 암호 모드: xts-plain64 페이로드 오프셋: 32768 UUID: 72f6e201-cbdc-496b-98bd-707ece662c9a MK 비트: 512 <-- MK는 "마스터 키" MK 덤프의 약자입니다. MK 덤프: 7a 31 be05 e3 ba f68 6 b5 ea 6 6b 16 fe ce ae ec a92 ec 44 db ea c35 0e 66 9d 22 f9 d9 b15 cb b4 60f ab f8 0f d9 e5 c1 4f 8 3 9 1d 1 05 37 73d 7 64 8 e38b be #
재암호화 옵션
위에서 언급한 것처럼 기기의 마스터 암호화 설정을 변경해야 하는 경우가 있습니다. 특히 더 큰 키 크기로 전환하는 것과 같이 암호화 권장 사항 변경을 따라가기 위해 사용한 매개변수 중 일부를 조정해야 하는 경우에 특히 그렇습니다.
이 목적을 위해, cryptsetup 편리하지만 구현하기 복잡한 옵션을 제공합니다. reencrypt, 실제로 세 가지 다른 프로세스를 처리합니다. 해독, encrypting및 재암호화 장치를 사용하는 동안에도 데이터.
물론 재암호화는 다음과 같은 옵션만으로 구현할 수 있습니다. --decrypt 과 --encrypt그러나 사용 중인 장치를 다시 암호화하려면 먼저 전체 암호를 해독한 다음 나중에 순수한 일반 텍스트에서 다시 암호화해야 합니다.
그렇게 하면 꼭 필요한 것보다 훨씬 더 오랜 시간 동안 위험에 노출될 수 있습니다. 장치가 암호를 해독하는 데 12시간이 걸리고 처음부터 다시 암호화하는 데 12시간이 더 걸린다면 디스크의 데이터 중 적어도 일부는 전체 기간 동안 일반 텍스트 형식이 됩니다. 데이터의 50% 이상이 최소 12시간 동안 일반 텍스트 형식입니다.
재암호화 간소화
그래서, cryptsetup 일부 디스크는 이전 키로 암호화된 상태로 유지하고 나머지 디스크는 새 키로 암호화하여 재암호화 프로세스를 간소화하는 동시에 프로세스가 중간에 중단될 경우를 대비하여 얼마나 남았는지 주의 깊게 추적할 수 있습니다. 또는 프로세스가 완료되기 전에 컴퓨터를 종료해야 합니다.
다시 시작하고 정식으로 인증된 사용자가 장치를 마운트하기 위해 암호를 입력하면(사용자의 암호는 이전 마스터 키와 새 마스터 키를 모두 일시적으로 암호 해독하므로 이중 배럴 암호 해독 프로세스를 계속할 수 있음), 암호화 프로세스는 중단된 곳에서 계속됩니다…
… 그리고 마지막에 이전 마스터 키는 지워지고 새 마스터 키는 기본 데이터에 대한 유일한 암호화 키로 커밋됩니다.
불행히도 재암호화를 처리하도록 신중하게 설계된 코드는 덜 유용하지만 때때로 필요한 옵션을 구현하는 데 재사용되었습니다. "일반 텍스트로 완전히 해독" (암호화 단계에서 널 암호로 재암호화하는 것과 동일), "일반 텍스트에서 완전히 암호화" (기본적으로 암호 해독 부분에서 null 암호를 사용하여 재암호화).
그리고 이러한 방식으로 용도를 변경할 때 사용되는 세심한 검사 reencrypt 프로세스가 얼마나 진행되었는지 추적하는 데 사용된 임시 데이터를 아무도 변경하지 않았는지 확인하고 디스크에 대한 루트 액세스 권한은 있지만 암호를 모르는 사람이 재암호화 절차를 남용하는 것을 방지하는 모드 …
… 적용되지 않았습니다.
보안 영향 평가
에 대한 설명으로 관련 버그 수정 그것을 박았 :
문제는 새로운 암호화 및 암호 해독 작업에 대한 보안 영향을 재평가하지 않고 실제 재암호화 작업을 위해 설계된 메커니즘을 재사용했기 때문에 발생했습니다. 재암호화에는 두 키 다이제스트를 모두 계산하고 확인해야 하지만 대상이 일반 텍스트(암호화 키 없음)인 경우 암호 해독 복구를 시작하는 데 다이제스트가 필요하지 않습니다.
간단히 말해서: 디스크에 물리적으로 접근할 수 있지만 스스로 암호를 해독할 암호가 없는 사람은 재암호화 도구를 속여 암호 해독 전용 절차를 부분적으로 수행한 것으로 생각하고 FDE를 속일 수 있습니다. 소프트웨어를 디스크의 일부를 해독하고 암호화되지 않은 상태로 둡니다.
버그 수정에서 설명하는 것처럼 LUKS 시스템 자체는 "[디스크에 대한 물리적 액세스 권한이 있는 누군가가 LUKS 코드를 통하지 않고 디스크에 쓸 수 있기 때문에] 의도적인 수정으로부터 보호하지만 그러한 수정이 데이터 기밀성을 위반하지 않아야 합니다."
그리고 이것이 여기에서 위험합니다. 암호화된 것처럼 보이는 디스크로 끝날 수 있습니다. 마운트하려면 여전히 유효한 비밀번호가 필요합니다. 암호화된 것처럼 작동합니다. 암호화되어 감사자를 만족시킬 수 있습니다…
...하지만 그럼에도 불구하고 일반 텍스트로 저장될 뿐만 아니라 나중에 다시 암호화되지 않는 (아마도 크고 많은) 청크를 포함합니다.
더 나쁜 것은 아마도 다음과 같은 관찰일 것입니다.
공개된 일반 텍스트를 수정할 수 있어 공격을 나중에 되돌릴 수도 있습니다(일반 텍스트에서 손상된 암호화 시뮬레이션).
이것이 의미하는 바는 악의적인 사용자가 암호 없이 디스크의 일부를 조용히 해독할 수 있다는 것입니다. 그런 다음 나중에 매끄럽고 은밀하게 데이터를 재암호화하고 "재통합"합니다.
느슨하게 말해서, 그들은 최소한 이론상으로는 가짜 "증거"와 그 다음에 비밀번호로 재암호화, 비록 그들이 실제로 귀하의 비밀번호를 알지 못하더라도.
무엇을해야 하는가?
- 업그레이드
cryptsetup 2.4.3이상. 정기적인 업데이트를 제공하는 Linux 배포판을 실행하는 경우 이미 이 버전이 있을 수 있습니다. (사용cryptsetup --version알아보기 위해.) - 재암호화 옵션이 사용 중일 때 감지하는 방법을 알아보세요. 당신은을 사용할 수 있습니다
luksDump부분 복호화/암호화가 진행 중인지 확인하는 기능입니다. (아래 참조.) - 가능한 한 신중하게 물리적 접근을 제한하십시오. 예를 들어 클라우드 서비스나 같은 위치에 있는 서버를 사용하는 경우 누가 무엇을 얻을 수 있는지에 대해 완전히 제어할 수 없는 경우가 있습니다. 그러나 신뢰할 수 있는 컴퓨팅 모듈과 변조 방지 암호화 칩이 있는 세상에서도 피할 수만 있다면 모든 사람에게 액세스 권한을 부여할 필요는 없습니다.
재암호화를 추적하기 위한 CRYPTSETUP 명령
--> 첫 번째 명령은 마스터 키 길이를 512비트로 늘리도록 cryptsetup에 지시합니다. # cryptsetup reencrypt /dev/sdb --key-size 512 키 슬롯 1에 대한 암호를 입력하십시오: [. . .] --> 재암호화하는 동안 사용 중인 두 개의 추가 키가 표시됩니다. 하나는 액세스 --> 새 마스터 키(여기서는 슬롯 0)이고 다른 하나는 얼마나 멀리 --> 해독하고 -recrypt 프로세스에 (여기서는 슬롯 2) # cryptsetup luksDump /dev/sdb [. . .] 키슬롯: 0: luks2(언바운드) 키: 512비트 [. . .] 소금: f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 [. . .] 1: luks2 키: 256비트 [. . .] 소금: 75 33 81 96 ba f3 ec 8a dc ef 28 dc 68 a9 a7 44 [. . .] 2: 재암호화(언바운드) 키: 8비트 우선순위: 무시 모드: 재암호화 방향: 앞으로 [. . .] --> 재암호화가 완료된 후 키슬롯 1(-> 이전 마스터 키에 대한 액세스용)이 제거되고 키슬롯 2(-> 절차의 진행률을 나타냄)가 제거되고 키슬롯 0이 장치에 대한 액세스를 위해 # cryptsetup luksDump /dev/sdb [. . .] 키 슬롯: 0: luks2 키: 512비트 [. . .] 소금: f4 be b9 3f 15 bc 8f 97 43 2c f8 1f 31 e3 60 d1 [. . .]
