Как защитить закрытый ключ вашего CA?

24

Я собираюсь внедрить свой собственный центр сертификации (ЦС) только для внутреннего пользования.

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

Что еще можно сделать для повышения безопасности закрытого ключа?

JMW
источник
Можем ли мы получить ОС, на которой работает веб-сервер? Вы, вероятно, могли бы установить права доступа к файлу, чтобы он не мог быть прочитан никем, кроме приложения и суперпользователя.
Рилиндо
мы бежим RHEL
JMW

Ответы:

25

Я работал в компании, где безопасность ключа CA имела решающее значение для дальнейшего успеха бизнеса. С этой целью ключ был зашифрован с использованием специального протокола, который требовал присутствия как минимум 2 человек с физическими токенами, подключенными к терминалам для его расшифровки (было как минимум 5 из этих токенов, любые 2 вместе работали). Терминалы были физически отделены от реальной машины ключом CA. Интерфейс, который использовали пользователи, расшифровавшие его, был терминалом VT220, который позволял им вводить токены расшифровки и затем выбирать то, что они хотели «подписать» ключом (никогда не давая им доступ к расшифрованному ключу). Эта система означала, что как минимум 4 человека должны были бы работать вместе, чтобы скомпрометировать ключ, двух держателей токенов, парня, который имел доступ к центру обработки данных

Если вас интересуют более подробные сведения об этом типе настройки, у Брюса Шнайера есть отличный сайт, посвященный разработке и реализации компьютерной безопасности:

http://www.schneier.com/

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

http://www.schneier.com/book-applied.html

многочлен
источник
2
И операция с двумя ключами (или любое n из m, m> = n, n> 1) - еще одна превосходная мера предосторожности - но за мои деньги, сначала воздушный зазор, и добавьте уточнения, например, в эту секунду, в зависимости от вашей степени паранойи (т.е. стоимость отказа).
MadHatter поддерживает Монику
1
Почему человек с правами root не может записать содержимое памяти в файл, пока два авторизованных человека выполняют свою работу? Это означает, что парень с root может получить ключ только с дополнительными ресурсами, необходимыми для получения дампа памяти с машины.
Слартибартфаст
Проверенный контроль физического доступа так же важен для такого рода безопасности, как проверенный контроль логического доступа. Операция подписи не должен требовать привилегий на коробке (что контроль обрабатываемое требованием любого-п-с-м), поэтому владелец корневой пароль не должен быть там вообще когда обмен подписями ключей происходит. (S) он будет необходим для обслуживания системы, но они должны выполняться в соответствии с точным заранее написанным сценарием кем-то, кроме автора сценария, и проверяться в режиме реального времени хорошо осведомленным третьим лицом.
MadHatter поддерживает Монику
16

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

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

(Это, кстати, очень четкий пример компромисса между безопасностью и удобством.)

andol
источник
Airgap - отличная мера предосторожности, и опасность съемных носителей можно уменьшить, установив флажок для подписи, чтобы ничего не запускать автоматически, разрешать двоичные файлы SUID или каким-либо другим образом доверять исполняемым файлам на таких носителях.
MadHatter поддерживает Монику
Это может быть дополнительно оптимизировано с помощью смарт-карты для генерации, хранения и использования ключа. Представьте себе смарт-карту как отдельную машину, которая имеет некоторую защиту от взлома (по сути, чип скорее сломается, чем откажется от ключа, что трудно сделать в более сложной системе), и имеет интерфейс, достаточно простой, чтобы стек протоколов мог быть правильно проверен.
Саймон Рихтер
Я второе предложение смарт-карты, но там есть риск. Когда ключ может находиться только в одном месте, только один аппаратный элемент должен потерпеть неудачу, чтобы сделать ключ недоступным. Я думаю, что одна или несколько смарт-карт могут составить важную часть в практике безопасного создания ключей и хранения.
Слартибартфаст
По поводу вопроса автозапуска. В случае файлового менеджера с графическим интерфейсом также может быть целесообразным явно указать, что он не пытается делать какие-либо умные предварительные просмотры / миниатюры перечисленных файлов. Хотя сама по себе она не представляет опасности, она может быть вектором атаки на существующие уязвимости.
Andol
Если безопасность действительно важна, я бы пошел с кучей CD-R с однократной записью.
Ли Райан
15

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

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

MadHatter поддерживает Монику
источник
Yepp, хорошая точка зрения по поводу начального ключа gen.
Andol
7

В зависимости от того, насколько вы серьезны, вам следует подумать об использовании оборудования FIPS 140-2 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) для хранения ключей CA и их резервных копий. У вас должен быть один корневой ЦС и один промежуточный ЦС, чтобы вы могли держать корневой ЦС в автономном и физически защищенном состоянии. Корень необходим только для продления или подписания новых промежуточных ЦС, тогда как промежуточные ЦС остаются включенными для повседневных операций. Как и предполагали другие, важна безопасная генерация ключей и управление ключами с помощью n of m control.

VeriSign (теперь Symantec) CPS - хороший пример того, как коммерческий ЦС генерирует и защищает свои ключи. Посмотрите на главы 5 и 6, а именно: http://www.verisign.com/repository/cps/ . (Я работал в VeriSign в течение нескольких лет)

Кроме того, в NIST есть несколько хороших публикаций по управлению ключами ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf ) и генерации, и ваша компания также должна иметь CPS в которой указаны политики и практики, которые вы используете для управления вашим ЦС. IETF предоставляет хороший шаблон: http://www.ietf.org/rfc/rfc2527.txt

грушевый сидр
источник
1

Отличный вопрос и несколько отличных ответов тоже.

Имейте в виду, что вы на 90% опережаете большинство других людей, просто рассматривая эту проблему, а не вслепую.

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

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

Роб Моир
источник
Рад слышать это @jmw - как я уже сказал, вы уже опережаете 90% или, может быть, даже 99% большинства людей, и, похоже, у вас все в руках. Вы были бы шокированы количеством людей, которые тратят недели и тонны денег, глядя на программную сторону вещей, не делая ничего для физической защиты данных.
Роб Мойр
Спасибо, вы абсолютно правы: информирование о новых рисках обязательно для каждого администратора. :-) о физической безопасности: центр обработки данных, в котором находятся наши серверы, обладает высокой физической безопасностью. таким образом, настроены пароли bios && grub. раздел, в котором хранится содержимое CA, также зашифрован. кроме того, сам ключ CA зашифрован. И в случае физической кражи nagios будет вызывать оповещения «отключение сервера». Я больше обеспокоен "нефизическими" подвигами. :-)
JMW