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

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

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

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

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

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

http://www.schneier.com/

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

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

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

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

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

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

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

В зависимости от того, насколько вы серьезны, вам следует подумать об использовании оборудования 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

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

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

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

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