Я собираюсь внедрить свой собственный центр сертификации (ЦС) только для внутреннего использования.
Теперь существует проблема, что частный CA никогда не должен использоваться. Итак, сейчас закрытый ключ зашифрован.
Что еще можно сделать для повышения безопасности закрытого ключа?
Я работал в компании, где безопасность ключа CA имела решающее значение для непрерывного успеха бизнеса. С этой целью ключ был зашифрован с использованием специального протокола, который требовал присутствия не менее 2 человек с физическими токенами, подключенными к терминалам для его расшифровки (таких токенов было не менее 5, любые 2 вместе взятые). Терминалы были физически отделены от реальной машины с помощью ключа CA. Интерфейс, которым пользовались расшифровавшие его пользователи, представлял собой терминал VT220, который позволял им вводить токены расшифровки, а затем выбирать то, что они хотели «подписать» с помощью ключа (никогда не давая им доступа к расшифрованному ключу). Эта система означала, что по крайней мере 4 человека должны будут работать вместе, чтобы взломать ключ, два держателя токенов, парень, который имел доступ к центру обработки данных, и еще один человек, у которого был root-доступ на сервере (потому что расшифрованный ключ никогда не хранился на сервер только в памяти, вы не могли просто украсть ящик, и люди с root на этом конкретном сервере не имели доступа к DC).
Если вас интересует более подробная информация о подобной установке, у Брюса Шнайера есть отличный сайт, посвященный разработке и внедрению компьютерной безопасности:
Он также опубликовал действительно хорошую книгу «Прикладная криптография», которая, как я нашел, помогла мне понять основы подобных систем и то, как создавать более безопасные инфраструктуры (читаемые людьми, которые не носят карманные протекторы):
Одним из больших преимуществ является полностью отключенный от сети закрытый ключ CA на выделенном компьютере. Затем вы подписываете и, возможно, также генерируете новые сертификаты на этом компьютере, а затем используете физический носитель для передачи новых сертификатов с машины CA.
Такая установка, конечно, также должна включать соображения относительно физической доступности машины, а также ограничения на разрешенные носители. Хорошо проходимый USB-накопитель, вероятно, не лучший выбор ...
(Это, кстати, очень наглядный пример компромисса между безопасностью и удобством.)
Я поддержал два других ответа и прокомментировал их, потому что считаю, что оба они превосходны. Если вы решили выбрать их обоих, и это вполне может быть подходящим, я сильно советуют проявлять осторожность при первоначальной генерации ключа, так как лучшее время для компрометации ключа - это не использование (где могут применяться многие стандартные повторяемые меры предосторожности), а время генерации, которое намного легче подорвать.
Это отличное руководство по проведению церемонии генерации ключей. описывает некоторые из стандартных протоколов, которые могут помочь в обеспечении безопасности генерации ключей, хотя в основном они сводятся к (а) тому, что все должно быть засвидетельствовано несколькими компетентными аудиторами, которые (б) делают одновременные записи обо всем, что делается (в) в соответствии с заранее определенный протокол, написанный кем-то, кроме исполнителя.
В зависимости от того, насколько вы серьезны, вам следует рассмотреть возможность использования FIPS 140-2 (http://en.wikipedia.org/wiki/FIPS_140#Security_levels) оборудование для хранения ключей CA и резервных копий этих ключей. У вас должен быть один корневой ЦС и один промежуточный ЦС, чтобы корневой ЦС оставался автономным и физически защищенным. Корень необходим только для обновления или подписания новых промежуточных центров сертификации, тогда как промежуточные центры сертификации остаются в сети для повседневных операций. Как предлагали другие, безопасное создание ключей и управление ключами с п из м контроль важен.
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% опережаете большинство других людей, просто рассматривая этот вопрос, а не слепо забегая вперед.
Помня об этом и воспользовавшись другим советом, я бы просто добавил: не останавливайтесь на достигнутом; следите за новостями в области безопасности и криптографии как по общим вопросам, связанным с выдачей, отзывом, взломом сертификатов и т. д., так и, в первую очередь, по уязвимостям и проблемам с конкретными продуктами, которые вы используете для создания ключей и управления ими.
Наконец: физическая безопасность. Создание чего-то «хакерского» не поможет, если я смогу просто устроиться на работу уборщиком по контракту в вашем здании, а затем однажды положить диск, содержащий ваш корневой сертификат, в свой карман. Вы будете удивлены, сколько людей упускают это из виду.