Комментарии 28
Украду, пожалуй, идею брать хэш от безобидного файлика вместо ключевого файла в явном виде.
В остальном у меня другие сценарии, но на серверы давно уже передаю ключик шифрования (раньше LUKS, теперь везде переехал на ZFS) скриптом по сети. При каждой загрузке сервера дёргается скрипт, расшифровывает и подмонтирует хранилище образов дисков виртуалок и потом уже запускает оные. При необходимости вручную или по событию (например, датчику открытия корпуса...) размонтирует и ключик выгружает.
Если у меня (а) внутри моего VPN заведётся MITM, который (b) и fingerprint ssh-сервера подделает, и (c) собственно ssh-соединение расшифрует, - я... хм... изрядно изумлюсь :)
Во-первых, недостаточно. Допустим атакующий попал в VPN и каким-то образом перехватил IP сервера (тоже не вполне очевидная задача). Мой скрипт подключается к этому серверу, и без п. b ругается, что в known hosts не тот фингерпринт и ничего не передаёт.
Во-вторых, ну Вы же не думаете, что в VPN, имеющем доступ к SSH, админкам и пр., у меня толпа народа сидит, и что новые подключения к этому VPN не мониторятся и предварительно не одобряются? (На самом деле всё несколько сложнее, но упрощаю для примера).
Да нет, как раз спасибо и автору статьи, и Вам, что появился лишний повод пересмотреть свежим взглядом, как оно там устроено и какие векторы атаки насколько успешно закрывает. Вот я, например, никогда не лез в кишки ssh, чтобы понять, как этот фингерпринт генерится, наивно полагая, что уж там точно есть некая криптография, которая не позволит его продублировать просто слушая трафик. Но надо загуглить, пожалуй.
В моей картине мира риск изъятия сервера в ходе совершенно тупого маски-шоу на пару порядков более вероятен, чем риск внедрения злоумышленника во внутреннюю сеть. Но мы ж тут про паранойю, так что надо со всех сторон защититься :)
Ну можно же в https завернуть, например, с проверкой сертификатов, не?
Тогда и ключ не перехватят, и тем более свой не подсунут (а если и подсунут - что это даст кроме отказа)
неа.
TMPFS_DIR="/tmp/tmpfs_key_$USER"
...
mkdir -p "$TMPFS_DIR"
if [ $? -ne 0 ] ; then
exit 0
fiслажает на симлинке:
max@xz:~$ rm -Rf /tmp/xz*
max@xz:~$ mkdir /tmp/xz
max@xz:~$ touch /tmp/xz/123
max@xz:~$ ll /tmp/xz*
total 8
drwxrwxr-x 2 max max 4096 Mar 11 22:31 ./
drwxrwxrwt 17 root root 4096 Mar 11 22:31 ../
-rw-rw-r-- 1 max max 0 Mar 11 22:31 123
max@xz:~$ ln -s /tmp/xz /tmp/xz2
max@xz:~$ ll /tmp/ |grep xz
drwxrwxr-x 2 max max 4096 Mar 11 22:31 xz/
lrwxrwxrwx 1 max max 7 Mar 11 22:31 xz2 -> /tmp/xz/
max@xz:~$ ln -s /tmp/xz /tmp/xz2
max@xz:~$ mkdir -p /tmp/xz2
max@xz:~$ echo $?
0
max@xz:~$ ll /tmp/ |grep xz*
drwxrwxrwt 17 root root 4096 Mar 11 22:32 ./
drwxr-xr-x 23 root root 4096 Sep 14 10:56 ../
drwxrwxrwt 2 root root 4096 Feb 28 01:00 .font-unix/
drwxrwxrwt 2 root root 4096 Feb 28 01:00 .ICE-unix/
drwx------ 2 root root 4096 Mar 6 19:46 mc-root/
drwx------ 4 root root 4096 Feb 28 01:00 snap-private-tmp/
drwx------ 3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-ModemManager.service-jZBoE8/
drwx------ 3 root root 4096 Mar 4 21:09 systemd-private-4188cc9d91804f6b80f726d21c270ac4-ocserv.service-VIc0Cd/
drwx------ 3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-polkit.service-ZRHRw5/
drwx------ 3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-porcula.service-Fh0vYx/
drwx------ 3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-logind.service-fYEaRb/
drwx------ 3 root root 4096 Mar 5 21:05 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-resolved.service-uOtQ45/
drwx------ 3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-timesyncd.service-zHCHyx/
drwx------ 3 root root 4096 Mar 6 19:54 systemd-private-4188cc9d91804f6b80f726d21c270ac4-transmission-daemon.service-wVXiDO/
drwxrwxrwt 2 root root 4096 Feb 28 01:00 .X11-unix/
drwxrwxrwt 2 root root 4096 Feb 28 01:00 .XIM-unix/
drwxrwxr-x 2 max max 4096 Mar 11 22:31 xz/
lrwxrwxrwx 1 max max 7 Mar 11 22:31 xz2 -> /tmp/xz/
далее слажает вгет на уже существующем файле
wget -q -O "$IMG_FILE" "$SECRET"
if [ $? -ne 0 ] || [ ! -f "$IMG_FILE" ] ; then
вот так, например
max@xz:~$ wget -q -O /tmp/123 https://www.rbc.ru/
max@xz:~$ echo $?
0
max@xz:~$ wget -q -O /tmp/123 https://www.rbc.ru/
max@xz:~$ echo $?
0
создаем симлинк /tmp/$username, подкладываем свое и ждем пока автор выкачает ключ. кстате непонятно какой - приватный или публичный
какие проблемы: если вы тот злоумышленник, который УЖЕ сидит на машине и делает симлинки - то вам мешают просто скачать ключ только права на каталог /etc/paranoid/users.
И тогда рут мог бы сконфигурить вместо /tmp - /var/paranoid, и точно так же закрыть правами его.
для уже сидеть на машине и делать симлинки в /tmp достаточно пользователя nginx или подобного с /sbin/nologin и ровно это показывал пример - непривелигерованный пользователь
и да, спойлер - давно придумали mktemp от этих проблем, прерыват цепочку атаки прям на первом пункте, но оный не единственный для "паранойи"
Идея хорошая, но она не соответствует нескольким исходным критериям. Если вы вынуждены дать доступ (ваш пароль) к диску вашего компьютера, его можно расшифровать. Исправьте меня, если я не прав, но ключ хранится на диске... поэтому каждый, у кого есть доступ, может прочитать файл. Возможным решением является хранение папки на скрытом зашифрованном разделе.
Всё зависит от модели угроз. Например, если главная угроза - "пришли с обыском, изъяли технику, угрозой «позвонить Путину» заставили сообщить пароль", то, при условии, что вместе с техникой не забрали вас (или забрали, но дали позвонить доверенному лицу), пока техника путешествует к криминалистам, файл из интернета уже может быть и потёрт.
Другая разновидность этой схемы: расшифровка накопителя лишь при одновременном вводе правильного пароля и вставке microSD-карточки с ключевым файлом. Если успеете уничтожить карточку, пока пилят дверь, расшифровать накопитель уже будет невозможно.
Скрытый раздел может применяться, но лучше применять его как дополнение, а не возлагать всю защиту целиком на него.
В том-то и дело, ключ на диске НЕ хранится. Он где-то в другом месте, и если это место неподконтрольно тому кто вынуждает вас выдать пароль - то ключ может быть легко уничтожен третьими лицами, или автоматикой.
Проблема в том, что ключевой файл нужно как-то резервировать. Сервер в интернете это не очень надёжное место. Файл может быть банально потерян из-за сбоя (у выделенного сервера помер накопитель / в облаке произошёл сбой с потерей данных). А если есть копия, то нужно продумать оперативное уничтожение уже двух файлов.
Более того, файл диска не обязан быть именно файлом на диске - это может быть вообще подключаемая флешка
Для тех, кто захочет реализовать это в Windows: такое (ключевой файл на внешнем накопителе) умеет штатный BitLocker. Разумно дополнить эту схему и паролем (это BitLocker тоже умеет), таким образом для расшифровки нужно одновременно и знать (пароль) и иметь (флешку).
Есть такая проблема, но ее уже можно решать очень по разному. Именно поэтому ключ не должен быть похож на ключ - и резервная копия ключа может оказаться в самом неожиданном и довольно надежном месте, но об этом никто не будет знать кроме того кто создавал этот ключ - и это не обязательно пользователь под контролем.
Сама идея в том, что в отличии от традиционной схемы защиты, когда "у вас нет ключа от сейфа" - тут ключем от сейфа может быть что угодно: ключ от дверей, кофейная чашка, тапочки, кот с соседней улицы, карандаш, гвоздь-"сотка".
Получив доступ к закрытому сейфу - вы узнаете где этот ключ лежал, но вы не знаете что это такое было. Может быть он у вас в руках, но не попробовав применить - не узнаете этого.
А может быть резервной копии и нет - и этого вы тоже не узнаете.
Что-то вы не то говорите. Вот вы могли бы знать пароль, но хотите, чтобы и при вашем сотрудничестве пароль оставался неизвестным, но ведь вы будете знать где ключ и вкуда он вмонтирован, вы и расскажете...
В практическом применении имеет смысл только что-то, что имеет два ключа, и тогда, если у вас стальные яйца вы выдадите тот ключ, который уничтожит систему. Но работает это только если систему не сдублировать.
Альтернатива - получение ключа извне, и возможность третьих лиц это всё заблокировать. Но тогда вы в целом не нужны, а забирать надо этих третьих лиц...
Собственно еще много лет назад знал людей, которые работали на удаленных машинах, причем где эти машины они не знали. И доступ к ним контролировали совершенно иные люди находящиеся тоже неизвестно где и не имеющие имен. Т.е. нажав ресет на своей рабочей станции ты отключался от работы навсегда. Подключить тебя мог только некто, находящийся где-то и ты должен был ему что-то сказать, а он мог многое проверить. (Видео из офиса к нему шло к примеру итп).
Немного автоматизации добавлено в Network-Bound Disk Encryption (NBDE).
условие номер два: вы не можете рассказать пароль. Захотите — но не сможете.
условие 2 со звездочкой: иметь способ доказать любопытным злодеям что пароль вы дейcтвительно не знаете
Понравилась идея с картинкой из интернета. Только вот теперь чувствительной информацией становится уже адрес картинки. Даже если она будет своевременно заменена, будет забавно, если её какой-нибудь cdn или web archive запомнит.
В давно почившем TrueCrypt такое было, можно было любой файл в качестве ключа использовать. А для параноиков была фича с со скрытым диском - два разных ключа, зашифрованное одним лежит в начале контейнера, зашифрованное вторым в конце, и в зависимости от использованного ключа видно либо одно, либо второе. При принуждении можно отдать первый ключ, узнать по контейнеру есть ли второй нельзя. Главное, чтобы обоим фрагментам места хватило.
https://www.truecrypt71a.com/documentation/plausible-deniability/hidden-volume/
Узнать можно, по крайней мере так заявил продолжитель дела, без почин трудящийся мисье Idrassi из Франции, в форке VeraCrypt. По наводке анонимного лица. Было исправлено, что именно поменялось - не смотрел.
Эээ... простите, но что мешает требовать оба ключа :)? Если уж утилита штатно так умеет.
Да, у того кто создавал контейнер будут проблемы, если он создал один ключ. Но его проблемы совершенно никого не заботят...
Если у вас паранойя…