Вопрос по memory, key, aes, cryptography – Криптография: лучшие практики для ключей в памяти?

10

Предыстория: я получил некоторые данные, зашифрованные с помощью AES (то есть симметричного шифрования) в базе данных. Приложение на стороне сервера, работающее на (предполагаемом) защищенном и изолированном Linux-боксе, использует эти данные. Он считывает зашифрованные данные из БД и записывает зашифрованные данные, имея дело только с незашифрованными данными в памяти. Таким образом, чтобы сделать это, приложение должно хранить ключ в памяти.

Вопрос в том, есть ли хорошие передовые методы для этого? Закрепление ключа в памяти.

Несколько идей:

Хранение его в неподключаемой памяти (для linux: настройкаSHM_LOCK сshmctl(2) ?)Разделение ключа по нескольким ячейкам памяти.Шифрование ключа. С чем и как сохранить ... ключ ключ ... в безопасности?Загрузка ключа из файла каждый раз, когда он необходим (медленный, и если злоумышленник может прочитать нашу память, он, вероятно, может прочитать и наши файлы)

Некоторые сценарии того, почему ключ может утечь: evildoer завладевает дампом памяти / дампом ядра; проверка плохих границ в коде, приводящая к утечке информации;

Первый кажется хорошим и довольно простым делом, но как насчет остальных? Другие идеи? Какие-либо стандартные спецификации / лучшие практики?

Спасибо за любой вклад!

Ваш Ответ

6   ответов
4

Если вы серьезно относитесь к безопасности, вы можете рассмотреть возможность использования отдельной криптографической подсистемы. Предпочтительно тот, которыйFIPS 140-2 / 3 сертифицированный (список сертифицированных модулей).

Затем ключ хранится в защищенной от несанкционированного доступа памяти и все криптографические операции выполняются внутри криптографической границы.

Дорого, но для некоторых приложений необходимо.

+1, очень хороший момент. Мне как-то удалось забыть о выделенной криптографии :-) Andrew Y
Я считаю, что МозиллаБиблиотека NSS сделает это, и это бесплатно Adam Batkin
1

Также не надоне забывайте об угрозе дампов ядра и обменивайте память!

В системах POSIX (например, Linux) и Windows существуют методы, предотвращающие это, если выРабота с языком C - см. этот раздел в CERT Secure Coding Standards:

MEM06-С. Убедитесь, что конфиденциальные данные не записываются на диск

1

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

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

Итак, вы предполагаете, что серверОС безопасна. Но давайСкажем, кто-то может прийти и украсть жесткий диск, чтобы запуск сервера дал им ключ. Затем пусть сервер запрашивает у половины сервера половину ключа, удаленный сервер проверяет запрос (используя пары ip, private / public key) и предоставляет половину ключа. Тогда ваш сервер имеет полный ключ, а удаленный сервер никогда не имеет больше половины. Это мне кажется улучшенным уровнем защиты.

1

буду смотреть на что

OpenSSH,OpenSSL,GnuPG (см. Связанные подпроекты с помощью раскрывающегося списка проектов), а такжеGnuTLS

делать при обработке ключей. Oни'достаточно параноидален в отношении таких вопросов безопасности ...

0

Использование "супер супер пользователь " аппаратная память идеальна. Все Intel Mac имеют эту область памяти SecureEnclave, и она также включает аппаратное дешифрование AES, так что приложение и операционная система никогда не имеют доступа к необработанному секретному ключу. Когда машина загружается, вводится пароль (необязательно), и SecureEnclave дешифрует свою зашифрованную версию ключа, хранящегося в холодной флэш-памяти, в свою область ОЗУ, которая недоступна для основной операционной системы.

Приятным побочным эффектом является аппаратное ускорение шифрования: я проверил 600 МБ / сек записи в свое хранилище PCIe на только что отформатированном зашифрованном диске.

В облаке Amazon имеет эту управляемую службу AWS Key Management Service (KMS), которая упрощает создание и управление ключами шифрования, используемыми для шифрования ваших данных, и использует проверенные аппаратные модули безопасности FIPS 140-2 для защиты безопасности твои ключи:https://aws.amazon.com/kms/

7

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

С шляпой из фольги, хотя - (1), (2), (3) кажутся разумными. (4) выигралне делайте это точно по той причине, которую вы упомянули. (Мало того, что это медленно, но при условии, что вы читаете в стек, при разной глубине стека ключ может становиться видимым более одного раза).

Предполагая, что дешифрованные данные того стоят, и они будут в подменной памяти, вам определенно следует также зашифровать сам подкачку. Корневой раздел / tmp также должен быть зашифрован. Это довольно стандартная настройка, которая легко доступна в большинстве руководств по ОС.

И тогда, конечно, вы хотите обеспечить высокий уровень физической безопасности для самой машиныа также свести к минимуму выполняемые им функции - чем меньше кода выполняется, тем меньше подверженность. Возможно, вам также захочется узнать, как вы можете полностью минимизировать возможности удаленного доступа к этой машине - то есть использовать ssh на основе RSA-ключей, который будет заблокирован другим ACL, управляемым с другого хоста.portknocking может использоваться как один из дополнительных векторов аутентификации перед тем, как войти в систему на этом втором хосте. Чтобы убедиться, что если хозяинявляется Скомпрометировано, труднее получить данные, убедитесь, что этот хост не имеет прямого маршрутизируемого соединения с Интернетом. В целом, чем более болезненно вы получаете доступ к конфиденциальным данным, тем меньше вероятность того, что кто-то туда попадет, однако там это также сделает жизнь постоянных пользователей болезненной - поэтому необходимо остаток средств.

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

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

Устройства Firewire также могут использоваться для чтения ключей из памяти. Они могут напрямую обращаться к памяти, а специально созданный может сделать полную копию памяти для последующего анализа. Увидетьmmadan.wordpress.com/2008/03/14/physical-hack-via-firewire-port Eric J.

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