(Domain Name System, система доменных имен). Существуют органы, обладающие властью назначать имя в системе DNS, но ни один из сертифицирующих органов SSL, представленных в списках, которые можно видеть в популярных браузерах, таковым не является. Это означает, что имя DNS в сертификате не является авторитетно установленным. Есть органы, назначающие корпоративные имена. Такое имя должно регистрироваться, когда некто хочет получить лицензию на какой-либо бизнес. Однако ни один из СА SSL, опубликованных в популярных браузерах, не обладает полномочиями делать это. В добавление ко всему, если сервер получает сертификат SSL-сервера, он имеет разрешение работать по протоколу SSL. Кто дал полномочия сертификационному органу SSL контролировать подобные разрешения? И является ли контроль за этими разрешениями необходимым? Какой вред будет причинен, если несертифицированный сервер будет использовать кодирование? Никакого.

Некоторые центры сертификации, учитывая тот факт, что они не властны Над содержимым сертификата, выделили структуру, называемую бюро регистрации (Registration Authority, RA), которая должна отвечать за содержание. Идея состоит в том, что RA ответственен за проверку информации, находящейся в сертификатах, а СА отвечает за их выдачу.

Модель RA+CA, безусловно, менее безопасна, чем система, при которой СА находится в составе полномочного органа (то есть RA). Модель RA+CA позволяет некоторому объекту (СА), который не является полномочным относительно содержания, подделать сертификат с соответствующим содержанием. Конечно, сертифицирующий орган подписывает контракт, в котором обещает так не делать, но это не исключает подобную возможность. Между тем, поскольку безопасность всей модели зависит от безопасности обеих ее частей и взаимодействия между ними (они должны каким-либо способом взаимодействовать), RA+CA менее безопасна, чем каждая из частей, безотносительно того, насколько силен СА и насколько хорош контракт, который с ним подписан. Конечно, модель, в которой СА находится в составе органа- распорядителя (не со стороны продавца), препятствует некоторым способам ведения бизнеса продавцами в инфраструктуре PKI.

Другую проблему представляет защита закрытого ключа. Вспомним: чтобы вся система цифровых подписей работала, вы должны быть уверены, что ваш закрытый ключ известен только вам. Отлично, но как защитить его? Можно быть почти уверенным, что у вас нет безопасной вычислительной системы, с контролем физического доступа, экранированием TEMPEST, «пространством» сетевой безопасности и другими средствами защиты; вы храните свой закрытый ключ на обычном компьютере. Таким образом, он является объектом для вирусов и иных разрушительных программ. Даже если ваш закрытый ключ в безопасности на вашем компьютере, находится ли этот компьютер в закрытой комнате, снабженной системой видеонаблюдения, уверены ли вы, что никто, кроме вас, никогда не воспользуется им? Если он защищен паролем, то насколько трудно «вычислить» этот пароль? Если ваш ключ хранится на смарт-карте, насколько она устойчива к атакам? Если он содержится на действительно устойчивом к атакам устройстве, то не может ли инфицированный компьютер найти способ «убедить» это заслуживающее доверия устройство подписать то, что вы не хотели бы подписывать?

Здесь дело преимущественно касается термина безотказность (nonrepudation). Подобно «доверенному» объекту, этот термин взят из академической литературы по криптографии. Здесь он используется в специфическом значении, описывая алгоритм создания цифровой подписи, который невозможно разрушить, так что никто не может подделать вашу подпись. Продавцы PKI замыкаются на этом термине и используют его в юридическом смысле, лоббируя законы, согласно которым, если кто-то использует свой закрытый ключ, то он в любом случае не может отказаться от своей подписи. Другими словами, в соответствии с некоторыми законами об использовании цифровой подписи (например, законами штатов Юта и Вашингтон), если ключ вашей подписи сертифицирован правомочным СА, вы отвечаете за все, что с помощью этого ключа делается. Им нет дела до того, кто сидел за клавиатурой компьютера или какой вирус создал эту подпись: вы ответственны по закону.

Считается, что работает следующий механизм: если вы подозреваете, что ваш ключ ненадежен, вы «отправляете» его в CRL. Все, что подписано этим ключом в дальнейшем, автоматически считается недействительным. Это кажется невероятным, но такая система изначально порочна. Боб хочет знать, что ключ Алисы вне подозрений, прежде чем примет ее подпись. Злоумышленник не собирается объявлять о том, что он взломал Алисин ключ. Таким образом, Алиса может понять, что ее ключ взломан, только когда она получит от Боба сообщение, демонстрирующее доказательства подделки ее подписи. В большинстве случаев это может произойти, только если Боб примет ее подпись.

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

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

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

И наконец, как бюро сертификации идентифицируют владельца сертификата? Будет ли сертификат использоваться только как идентификатор или для другой специфической авторизации, но СА должен идентифицировать претендента перед вручением ему сертификата.

Некоторые кредитные организации подумывают о том, чтобы заняться сертификационным бизнесом. Помимо всего прочего они имеют обширную базу, содержащую данные о множестве людей, так что логично предположить, что они способны с легкостью установить подлинность личности. Если они хотят подтверждать подлинность по сети, они в состоянии сделать это, обеспечив совместный с субъектом доступ к секретной информации и безопасный канал, по которому конфиденциальную информацию можно передавать. SSL обеспечивает безопасный канал.

Помешать подобным кредитным организациям выполнить свою роль может то, что у них не получится сделать совместный доступ секретным. Другими словами, не существует безопасного идентификатора, который мог бы использоваться для запуска всего процесса, потому что такие организации участвуют в продаже имеющейся у них информации другим людям. Хуже того, поскольку кредитные бюро делают такое «доброе» дело, как сбор и продажа информации о людях, другие, кто предположительно имеет информацию о субъекте, возможно, подвергаются сильному давлению, чтобы они помогли найти те секретные данные о субъекте, которые еще не известны этому кредитному бюро.

Между тем, каким-либо образом идентифицировав претендента, как СА проверит, что претендент действительно контролировал закрытый ключ, соответствующий открытому ключу, подтвержденному сертификатом? Некоторые сертифицирующие органы даже не рассматривают эту часть процесса. Другие могут требовать, чтобы претендент подписал некоторый документ тут же на месте, в присутствии СА.

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

Как вычисляется время жизни ключа? Почему продавцы используют один год – потому, что это общепринято? Ключ имеет криптографическое время жизни. Он также имеет время жизни до воровства, являющееся функцией от уязвимости подсистемы, в которой он хранится, состояния ее физического и сетевого окружения, привлекательности ключа для взломщика и т. д. Исходя из этого можно вычислить

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату