☰

설치 시 LUKS 파티션에 비밀번호가 필요하지 않은 이유는 무엇입니까?

tag-icon • tag-icon raspbian luks cryptsetup
설치 시 LUKS 파티션에 비밀번호가 필요하지 않은 이유는 무엇입니까?

내 시스템에는 두 개의 암호화된 디스크가 있습니다.

  1. raspbianstretch 루트 파티션에 대한 암호화가 포함되어 있습니다.
  2. usb-crypt는 외부 USB 디스크입니다. 이 디스크에는 LVM이 사용됩니다.

두 디스크는 모두 동일한 비밀번호로 보호되지만 "cryptsetup luksDump"에 따르면 마스터 키가 다릅니다. 두 디스크 모두 키 파일로 구성되지 않습니다(LUKS 컨테이너당 하나의 키 슬롯만 사용됨).

시스템이 시작되면 "crypt" 비밀번호를 입력하라는 메시지가 표시되지만 usb-crypt는 비밀번호를 입력하지 않고도 자동으로 마운트됩니다. 참고: 암호화되지 않은 루트 파티션으로 시작했는데 이 설정을 사용하면 부팅 중에 usb-crypt에 대한 비밀번호를 묻는 메시지가 표시되었습니다.

자세한 설정은 다음과 같습니다.

$ sudo dmsetup ls --target crypt
crypt   (254, 0)
usb-crypt       (254, 1)

$ sudo cat /etc/fstab
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mapper/crypt  /            ext4    defaults,noatime  0       1
# ...
UUID=b9fb061f-0877-4d2c-bd3c-9c155b8f88a5       /mountpoint       ext4            rw,auto                 0       0

$ sudo cat /etc/crypttab 
# <target name> <source device>         <key file>      <options>
crypt   /dev/mmcblk0p2  none    luks
usb-crypt       UUID=31fb8df7-6148-4408-90a2-93b8ec752fa0       none    luks

비밀번호를 한 번만 입력하면 편리하지만 이런 동작을 보고 놀랐습니다. 나는 두 가지 비밀번호를 모두 물어볼 것으로 예상했습니다.

두 디스크 모두에서 동일한 비밀번호를 사용하는 것과 관련이 있을 수 있습니까? 아니면 USB 플래시 드라이브의 마스터 키가 "crypt" 암호화된 루트 파티션 어딘가에 자동으로 저장됩니까? 누군가 여기서 무슨 일이 일어나고 있는지 설명하고 관련 로그 파일 등에 대한 힌트를 제공할 수 있다면 매우 감사하겠습니다.

미리 감사드립니다!

답변1

비밀번호를 묻는 초기화 스크립트가 수행하는 작업에 따라 다릅니다.

그렇다면 systemd그것은 단지 기능일 수도 있습니다. systemd-ask-password책임을 질 수 있는 캐싱 기능이 함께 제공됩니다.

https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html

--accept-cached

    If passed, accept cached passwords, i.e. passwords previously entered.

--multiple

    When used in conjunction with --accept-cached accept multiple passwords.
    This will output one password per line.

이런 방식으로 먼저 이미 입력한 비밀번호를 시도하고, 그래도 작동하지 않는 경우에만 다른 비밀번호를 요청합니다.

이 아이디어의 단점은 LUKS로 비밀번호를 확인하는 데 CPU 시간이 1초 걸리므로 LUKS 컨테이너가 많으면 이러한 시도로 인해 속도가 느려질 수 있다는 것입니다. 그러나 대부분의 사람들은 하나 또는 두 개의 비밀번호만 가지고 있으며 실제로 동일한 비밀번호를 사용하는 경우가 많습니다.

실제로 이 문제를 담당하는 소스 코드를 찾을 수 없으므로 위의 내용은 단지 추측일 뿐이며 이 기능을 비활성화할 수 있는 옵션이 있는지는 알 수 없습니다.

책임이 있는 것으로 보이는 코드를 찾았고,Github에서 확인해보세요.

tries = 01로 시작 하고 반복할 때마다 1씩 증가하는 for 루프가 있습니다 .tries

루프는 if를 호출 get_password()하고 bool accept_cached이를 true로 설정합니다 tries == 0 && !arg_verify. 따라서 루프의 첫 번째 반복에서 이미 캐시된 경우에만 캐시된 비밀번호를 반환합니다. 이것이 작동하지 않으면 다음 반복은 false로 tries == 1설정되고 accept_cached그 후에만 시도할 다른 비밀번호를 묻는 메시지가 표시됩니다.

비밀번호 목록이 로 전달됩니다 attach_luks_or_plain(). 이는 첫 번째 반복에서 이전에 캐시된 비밀번호가 되고 모든 후속 반복에서는 단일 새 비밀번호가 되므로 이전에 시도한 비밀번호를 다시 시도하지 않습니다(동일한 비밀번호를 계속 입력하지 않는 한).

비밀번호 일반 텍스트를 메모리에 유지하는 경우 비밀번호 목록이 로 선언되므로 _cleanup_strv_free_erase_ char **passwords = NULL;적어도 정리와 같은 소리는 어느 시점에서 제대로 처리됩니다.

키는 항상 메모리 어딘가에 있으며, 그 주위에는 방법이 없습니다. crypt를 사용하려면 마스터키가 필요하며 컨테이너가 열려 있는 한 항상 키를 볼 수 있습니다 dmsetup table --showkeys.

일반적으로 arg_tries = 3유효한 비밀번호를 입력하기 위해 세 번 시도하지만, 컨테이너가 여러 개 있고 캐시된 비밀번호가 작동하지 않는 경우 캐시된 비밀번호 시도가 이미 첫 번째 시도로 계산되므로 비밀번호 입력을 두 번만 시도하게 됩니다. . 이것이 사실인지 테스트할 암호화된 시스템 시스템이 없거나 어딘가에서 코드를 잘못 읽었을 뿐입니다.

관련 정보