В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 19. PKI: красивая мечта опасность всей системы. Вне всяких сомнений, еще есть люди, которые до сих пор пользуются неисправленной версией библиотеки. 19.3.2 Срок действия Ни один криптографический ключ не должен жить вечно; он всегда рис- кует оказаться взломанным. Регулярное изменение ключа позволяет пусть медленно, но все же восстановить систему после взлома. Аналогичным свой- ством должны обладать и сертификаты, так как и ключ самого центра сер- тификации, и открытый ключ, заверенный сертификатом, имеют ограничен- ный срок действия. Вдобавок ко всему ограничение срока действия помога- ет поддерживать информацию в актуальном состоянии. По окончании сро- ка действия сертификата ЦС должен выдать новый сертификат, а заодно и обновить содержащиеся в нем данные. Обычно срок действия сертификата составляет от нескольких месяцев до нескольких лет. Практически все сертификаты содержат дату и время окончания срока действия. По истечении этого времени сертификат приниматься не должен. Вот для чего участникам инфраструктуры открытого ключа нужны часы. Довольно часто в сертификат включаются и другие данные. Многие сер- тификаты содержат не только дату окончания срока действия, но и дату его начала. В число других дополнительных данных могут входить классы сертификатов, серийные номера сертификатов, время и дата выдачи и т.п. Некоторые из этих данных действительно полезны, а некоторые — нет. Самым распространенным форматом сертификатов является X.509 v3, который содержит просто немыслимое количество всякого мусора. Если вы не боитесь сойти с ума, почитайте справочник Питера Гутманна (Peter Gutt- mann) [39]. Если ваша система не должна обладать возможностью взаимо- действия с другими системами, забудьте об X.509 v3 раз и навсегда. Если же вам все-таки придется использовать X.509 v3 — примите наши искренние соболезнования. 19.3.3 Отдельный центр регистрации Некоторые системы вдобавок к центру сертификации содержат еще и от- дельный центр регистрации. Данная проблема относится к разряду политиче- ских. Как известно, решение о принятии на работу того или иного сотрудника осуществляет отдел кадров. Но работой центра сертификации руководит IT- департамент; он ни за что не разрешит заниматься этим отделу кадров. Существует два неплохих способа решения данной проблемы. Первый — использовать многоуровневую структуру сертификации и разрешить отделу кадров самому стать подчиненным ЦС. Это автоматически обеспечит гиб- 19.4. Заключение 343 кость, необходимую для поддержки нескольких регионов. Второе решение во многом напоминает первое, за исключением того, что пользователь обращает- ся к главному ЦС и обменивает полученный им двухуровневый сертификат на одноуровневый. Это избавит нас от необходимости проверять двухуров- невый сертификат каждый раз, когда он используется, а дополнительные расходы составят лишь стоимость добавления к системе простого протокола, состоящего из двух сообщений. Одно из наиболее неудачных решений — добавить к криптографическому протоколу третьего участника. В этом случае в спецификациях проекта бу- дет фигурировать центр сертификации и еще один участник, который может называться, скажем, центром регистрации или ЦР (Registration Authority — RA) . ЦС и ЦР будут рассматриваться как две совершенно отдельные сущно- сти, в результате чего к системе добавится еще по крайней мере 100 страниц документации. Это плохо уже само по себе. Кроме того, нам понадобится описать взаимодействие между ЦР и ЦС. Мы даже встречали протоколы с тремя участниками, в которых ЦР авторизует ЦС, чтобы последний мог выдать сертификат. Это не просто безумие, но и хороший пример того, как требования пользователей могут навязать неудобоваримое техническое ре- шение. Требования пользователей задают только внешнее поведение систе- мы. Компании нужно обладать отдельными наборами функций для отдела кадров и IT-департамента, но это не значит, что программное обеспечение должно содержать для них отдельный код. Во многих ситуациях, в том чис- ле и в данной, оба отдела могут с успехом использовать б´ольшую часть одной и той же функциональности, а следовательно, б´ольшую часть одного и то- го же кода. Использование одного и того же набора функций сертификации упрощает структуру системы, делает ее менее дорогостоящей, а также более мощной и гибкой, чем структура, основанная непосредственно на требова- ниях пользователей, которые включают в себя и ЦС и ЦР. Двухуровневая схема сертификации позволяет отделу кадров и IT-департаменту совмест- но использовать б´ольшую часть кода и протоколов. Разница будет касаться в основном пользовательского интерфейса, что совсем несложно реализовать. Применение подобной схемы, может, и приведет к появлению нескольких со- тен дополнительных строк кода, но никак не нескольких сотен дополнитель- ных страниц спецификации, для описания которых программе потребуются десятки тысяч строк кода. 19.4 Заключение То, что описано в этой главе, — всего лишь мечта, но мечта очень важная. Инфраструктура открытого ключа — это первое и последнее слово в управ- |