Как не хранить ключ шифрования жесткого диска на компьютере, но при этом монтировать его при загрузке?

У Вас должна быть цель, вводят брелок для ключей. Я не уверен, необходимо ли, чтобы целевой ключ был допустим; лучше сделайте его так.

Необходимо использовать каталог конфигурации на палке. Так как этот каталог пуст, Вы импортируете ключ:

gpg --homedir /dir/on/stick --import /target/key.asc

Это должно быть сделано только однажды. Из Вашего сценария Вы делаете это:

gpg --homedir /dir/on/stick --trust-model always --recipient 0x12345678 \
  --output /path/to/encrypted_file.gpg --encrypt /source/file

Можно рассмотреть создание подписи для файла, также. Но это сделало бы операцию немного более сложной.

4
27.09.2015, 01:52
2 ответа

Самый простой способ настроить это - иметь системный раздел с открытым текстом. (на SD-карте, я полагаю) и раздел зашифрованных данных. Используйте dmcrypt для шифрования раздела данных с ключом, хранящимся в ключевом файле, загруженном с сервера.

Сначала настройте инфраструктуру сервера, затем загрузите файл ключа и создайте зашифрованный том с помощью cryptsetup luksFormat / dev / sdb1 /run/data.keyfile или добавьте ключ к существующему тому с помощью ] cryptsetup luksAddKey / dev / mapper / encrypted /run/data.keyfile. Обратите внимание, что вы можете настроить разблокировку тома с помощью парольной фразы или ключевого файла, что может быть удобно для администрирования (вы можете ввести парольную фразу, даже если сервер недоступен).

Ключевой файл не обязательно должен быть в каком-то определенном формате. Просто сгенерируйте несколько случайных байтов на сервере; 16 байт вполне достаточно (что-то большее не даст вам большей безопасности, но меньшее не даст вам большей производительности): pi.keyfile .

Обслуживать ключ по протоколу HTTPS, чтобы его не перехватили.Если у вас нет сертификата, подтвержденного центром сертификации, создайте свой собственный и добавьте его в / etc / ssl / certs или передайте его команде загрузки ( wget --ca- сертификат /etc/local/my.cert или curl --cacert /etc/local/my.cert).

Вам необходимо загрузить ключ перед активацией тома шифрования. Вы можете сделать это за один шаг с одним из

wget -nv -O - https://myserver.example.com/pi.keyfile | cryptsetup luksOpen /dev/sdb1 --key-file /dev/stdin
curl https://myserver.example.com/pi.keyfile | cryptsetup luksOpen /dev/sdb1 --key-file /dev/stdin

или вы можете загрузить ключ во временный файл, затем активировать том и, наконец (не обязательно, но может немного улучшить безопасность) удалить временный файл. Естественное место для этого временного файла находится в / run , который находится в ОЗУ и доступен для записи только root (не загружайте ключ в постоянное хранилище). Вы должны сделать файл доступным для чтения только root (вы можете установить umask 700 перед загрузкой, чтобы организовать это), хотя это имеет значение только в том случае, если вы не контролируете весь код, который запускается во время загрузки.

Если вы загружаете ключ во временный файл, вы можете поместить ключевой файл в / etc / crypttab и добавить модуль systemd для загрузки ключевого файла, который запускается перед тем, который активирует зашифрованный том (но после того, как сеть станет доступной) и еще один модуль, чтобы впоследствии удалить ключевой файл. Установка wget… | cryptsetup… в /etc/rc.local выглядит проще в настройке.

Вы, вероятно, захотите аутентифицировать клиента, когда он загружает ключ. Токен аутентификации должен храниться в открытом виде на Pi. Вы можете использовать сертификат клиента SSL:

curl --cert /etc/keyfile.cert https://myserver.example.com/pi.keyfile
wget --certificate /etc/keyfile.cert https://myserver.example.com/pi.keyfile

или пароль с базовой аутентификацией HTTP, хранящийся в / root /.netrc :

curl -n --user=pi https://myserver.example.com/pi.keyfile
wget --user=pi /etc/keyfile.cert https://myserver.example.com/pi.keyfile

Возможно, проще настроить базовую аутентификацию на стороне сервера. Используйте случайно сгенерированный пароль без специальных символов (например, ).

Обратите внимание: что бы вы ни делали, кто-то, кто украдет Pi, получит пароль и сможет загрузить ключ, если вы сначала не заблокируете его на стороне отправителя. Кроме того, тот, кто получает физический доступ к Pi, может быстро вытащить SD-карту, сделать копию и вставить ее обратно; если вы не отслеживаете ничего, кроме времени безотказной работы, это будет выглядеть как сбой питания. Нет никакого способа полностью защититься от этого. Вы можете вставить ключ в смарт-карту, что предотвратит его дублирование злоумышленником, но не от кражи смарт-карты или ее использования на месте для загрузки файла ключа.

И снова вы не можете защитить себя от кого-то с физическим доступом, который быстро загрузит файл ключа, затем украдет диск и расшифрует его на досуге. Если вы хотите защитить себя от этого, вам нужно изучить защищенное от взлома оборудование, которое находится в другом ценовом диапазоне.

8
27.01.2020, 20:49

Я решил ту же проблему, используя немного другое решение: поскольку я использовал ZoL, я предпочел использовать EcryptFS. Кроме того, поскольку я хотел, чтобы ключ был доступен, я сохранил его в зашифрованном виде ... в службе обмена файлами (например, Dropobox). Затем происходит следующее:

a) A systemd unit connects to the file exchange service, downloads the key and 
   decrypts it.
b) The dependent systemd units wait until the previous has finished and then use 
   the decrypted key to mount the file systems.
c) I have a service that monitors a box switch, so if the server box is opened I 
   receive an alert via pushbullet and the key is deleted from dropbox.

Идея состоит в том, что когда физическая целостность сервера нарушена, сервер украден и т. Д., Ключ удаляется из Dropbox, и данные становятся нечитаемыми.

0
27.01.2020, 20:49

Теги

Похожие вопросы