Система Debian с зашифрованными данными, которые могут быть дешифрованы только от удаленного сервера

Я думаю, есть вещи, которые вы просто не можете предотвратить.

На вашем месте я использовал 2 раздела на флешке клиента. Первый использовался для загрузки, и для загрузки в минимальной программе на Си. Эта минимальная программа на Си связалась с сервером и получила ключ для декодирования второго раздела. Весь этот запуск из initrd.

После успешного декодирования второй, настоящий раздел системы уже был пригоден для использования.

Самое важное - это удалить все из ядра, а также из пользовательского программного обеспечения, которое может быть использовано против вашей безопасности.

(p.s. с похожей, но ориентированной на безопасность точки зрения, вы можете спросить и на security.stackexchange.com)

Вы получите более точные ответы, если скажете , что именно вы хотите сделать, вместо , как вы хотите это сделать - другими словами: Положите шоколад покрытый бананом и отойти от европейских валютных систем .

TL; Резюме DR

Q: Это будет работать?
A: Может.
Q: Есть ли в этом смысл?
A: Боюсь, только при очень определенных предположениях.

Обеспечить безопасность очень сложно - вы можете спросить у Security SE общий подход.

Длинная версия

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

Однако ключевой проблемой здесь является доверие. Насколько я понимаю, вы хотите сохранить конфиденциальные данные (как зашифрованные E, так и временно открытый текст P) на клиенте и ключ K на сервере. Чтобы расшифровать E в P, в какой-то момент у вас будут K и E на одной машине - и именно в этот момент он развалится: сервер недостаточно доверяет клиенту, поэтому он запускается какие-то проверки - как можно гарантировать, что результаты проверки не будут подделаны? Если вас так беспокоит то, что кто-то подключает клавиатуру к клиентскому устройству, разве вас не беспокоит, что JTAG захватывает его и смотрит, что там происходит? Что, если кто-то скопирует клиента, проанализирует его, а затем заменит его / ее собственной системой при подделке результатов теста?

Вторая (более важная с моей точки зрения) проблема: что вы собираетесь делать с незашифрованными данными? данные и почему нельзя это сделать на "сервере"? Ключевым моментом здесь является: если вы недостаточно доверяете серверу, чтобы временно удерживать данные в своей оперативной памяти (здесь речь идет о клиенте, запрашивающем расшифровку с сервера), почему вы так доверяете ему, что вы постоянно храните там ключ к зашифрованным данным? Если вы не доверяете ему настолько, чтобы помещать открытый текст в свою оперативную память, разумно ли загружать ключевые данные в ту же самую память и отправлять их по сетевому интерфейсу?

Что если вы решите, что хотите работать с данными? в, скажем, редакторе по ssh-каналу? Откуда вы знаете, что кто-то не будет отслеживать данные ssh-соединения, которые обязательно будут содержать открытый текст?

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

1. аутентифицирует обе стороны, затем

2. разрешает клиенту запрашивать ключ дешифрования у сервера

3. разрешает серверу предоставить ключ дешифрования клиенту

4. запрещает любое команды, испускаемые на одной стороне канала, запускаются непосредственно на другой - т.е. никаких вещей вроде:

    user @ server $ ssh client -c "decrypt -k key  plaintext"
    

   Почему?

   Как правило, вы не хотите позволять кому-либо выполнять произвольные команды удаленно. Вам будет гораздо лучше, если настроить специальный двоичный файл, который позволит удаленному пользователю выбрать одну из предопределенных команд (немного похоже на ограниченную оболочку, только более ограниченную). Если ваши токены доступа будут скомпрометированы, злоумышленник сможет выполнить только несколько действий. Хотя в вашем случае это может означать кражу данных, в конце концов, это помешает ему превратить систему в троянского коня. Например, sshd (по крайней мере, из пакета OpenSSH) работает точно так же на этапе аутентификации: слушающий демон создает дочерний элемент, который немедленно отбрасывает все привилегии (чтение «root») и обрабатывает аутентификацию как непривилегированную. процесс, который запрашивает привилегированные действия от своего родителя через очень ограниченный API. Таким образом, любой ввод, который вы ему передаете, приведет либо к небольшому прогрессу аутентификации, либо к сбою непривилегированного приложения, что исключит возможность использования удаленного корневого эксплойта.

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