Я собираюсь создать свой собственный центр сертификации (CA) только для внутреннего использования. Только есть проблема, заключающаяся в том, что закрытый ключ ЦС никогда не должен быть использован. Поэтому сейчас закрытый ключ зашифрован. Что еще можно сделать для повышения безопасности закрытого ключа?
Ответ 1
Я работал в компании, где безопасность ключа CA была критически важна для дальнейшего успеха бизнеса. Для этого ключ был зашифрован с помощью специального протокола, который требовал присутствия как минимум двух человек с физическими токенами, подключенными к терминалам, чтобы расшифровать его (было как минимум 5 таких токенов, любые два вместе могли работать). Терминалы были физически отделены от реальной машины с ключом CA. Интерфейс, который был у пользователей, расшифровывающих ключ, представлял собой терминал VT220, который позволял им вводить токены для расшифровки, а затем выбирать, что они хотят «подписать» ключом (никогда не давая им доступа к расшифрованному ключу). Эта система означала, что по крайней мере 4 человека должны были работать вместе, чтобы скомпрометировать ключ: два владельца токенов, парень, имеющий доступ к центру обработки данных, и еще один человек, имеющий root-доступ на сервере (поскольку расшифрованный ключ никогда не хранился на сервере, только в памяти, вы не могли просто украсть аккаунт, а люди с root-доступом к этому конкретному серверу не имели доступа по DC). Если вас интересует более подробная информация о подобной установке, есть отличный сайт, посвященный разработке и реализации компьютерной безопасности:
http://www.schneier.com/
Также есть очень хорошая книга «Прикладная криптография», которая, как мне показалось, помогла мне понять основы подобных систем и способы создания более безопасных инфраструктур:
http://www.schneier.com/book-applied.html
Ответ 2
В зависимости от того, насколько серьезно вы настроены, вам следует рассмотреть возможность использования аппаратного обеспечения FIPS 140-2 (http://en.wikipedia.org/wiki/FIPS_140#Security_levels) для хранения ключей ЦС и резервных копий этих ключей. У вас должен быть один корневой ЦС и один промежуточный ЦС, чтобы вы могли держать корневой ЦС в автономном режиме и физически защищенным. Корневой ЦС нужен только для обновления или подписания новых промежуточных ЦС, в то время как промежуточные ЦС остаются в сети для повседневной работы. Как уже отмечалось, важно обеспечить безопасную генерацию ключей и управление ими с контролем n of m.
Руководство 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, в котором указаны политики и практики, используемые для управления вашим CA. IETF предоставляет хороший шаблон: http://www.ietf.org/rfc/rfc2527.txt.
Ответ 3
Отличный вопрос и отличные ответы.
Имейте в виду, что вы на 90% опережаете большинство других людей, просто рассматривая этот вопрос, а не слепо бросаясь вперед. Учитывая это и другие ответы, я бы просто добавил: не останавливайтесь на достигнутом; следите за новостями в области безопасности и криптографии как за общими вопросами, касающимися выпуска, отзыва, взлома и т. д. сертификатов, так и за уязвимостями и проблемами конкретных продуктов, которые вы используете для генерации и управления ключами.
И последнее: физическая безопасность. Создание чего-то «защищенного от хакеров» не поможет, если я могу просто устроиться уборщиком по контракту в вашем здании и однажды положить диск с вашим корневым сертификатом в карман. Вы удивитесь, как много людей упускают этот момент.
Ответ 4
Я считаю два предыдущих ответа превосходными. Если вы решите выбрать оба варианта, а это вполне может быть уместно, я настоятельно рекомендую соблюдать осторожность при первоначальной генерации ключа, поскольку лучшее время для компрометации ключа – не в процессе использования (где можно применить множество стандартных, повторяющихся мер предосторожности), а во время генерации, которую, будучи одноразовой, гораздо легче подделать. В этом превосходном руководстве по проведению генерации ключей описаны некоторые стандартные протоколы, которые могут помочь обеспечить безопасность генерации ключей, хотя в основном они сводятся к тому, что (а) все должно быть засвидетельствовано несколькими знающими аудиторами, которые (б) делают своевременные записи всего, что делается (в) в соответствии с заранее определенным протоколом, написанным кем-то, кроме исполнителя.
Security
