Технологии аутентификации. Технологии аутентификации Сертификат использованный при аутентификации

В том случае, когда пользователи имеют сертификаты открытых ключей , необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК , если УЦ недоступен, аутентификация по-прежнему может быть выполнена.

Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) >, Internet Key Exchange (IKE) >, S/MIME >, PGP и Open PGP >. Каждый из них немного по-своему использует сертификаты , но основные принципы - одни и те же.

Рис. 2.5. Взаимная аутентификация на базе сертификатов

Иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов , использующий цифровые подписи >. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами >. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.

Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А , то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация , а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B , это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B . Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.

Пользователь А подписывает последовательность из трех элементов: свой запрос ran A , запрос сервера ran B и имя сервера name B . Ran A - это запрос А к серверу В , гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В . Получив ответ Token АВ от пользователя А , сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1 , а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В . Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию .

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A , ran B и name A , где ran A - запрос, сгенерированный А , ran B - исходный запрос сервера В , а name A - имя пользователя А . Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ , а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А ). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В , и взаимная аутентификация выполнена.

Аутентификация с применением цифровых сертификатов является альтекрнативой применения паролей и представляется естественным решением в условия, когда число пользователей сети (пусть и потенциальных) измеряется миллионами. В таких обстоятельствах процедура предварительной регистрации пользователей, связанная с назначением их паролей, становится крайне обременительной, опасной, а иногда и просто нереализуемой, При наличии сертификатов сеть, которая дает пользователю доступ к своим ресурсам, не хранит никакой информации о своих пользователях – они ее предоставляют сами в своих запросах в виде сертификатов, удостоверяющих личность пользователей. Сертификаты выдаются специальными уполномоченными организациями – центрами сертификации (Certificate Authority, CA). Поэтому задача хранения секретной информации (закрытых ключей) возлагается на самих пользователей, что делает это решение гораздо более масштабируемым, чем вариант с централизованной базой паролей.

Сертификат представляет собой электронную форму, в которой содержится следующая информация:

1. Открытый ключ владельца данного сертификата;

2. Сведения о владельце сертификата, такие, например, как имя, адрес электронной почты, наименовании организации, в которой он работает, и так далее;

3. Наименование сертифицирующей организации, выдавшей данный сертификат:

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

Принцип работы алгоритма аутентификации на основе сертификатов приведена на рисунке 2.3.1 [Олифер и олифер]:

Рисунок 2.3.1 – Аутентификация на основе сертификатов.

Шифрование.

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

Шифрование может быть симметричным (например алгоритм DES) и асимметричным (например алгоритм RSA). Симметричное шифрование использует один и тот же секретный ключ для шифровки и дешифровки. Основным недостатком симметричного шифрования является то, что секретный ключ должен быть известен и отправителю, и получателю. С одной стороны, это ставит новую проблему рассылки ключей. С другой стороны, получатель, имеющий шифрованное и расшифрованное сообщение, не может доказать, что он получил его от конкретного отправителя, поскольку такое же сообщение он мог сгенерировать и сам.

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

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

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

При использовании асимметричных методов необходимо иметь гарантию подлинности пары (имя, открытый ключ) адресата. Для решения этой задачи вводится понятие сертификационного центра, который заверяет справочник имен/ключей своей подписью.

Услуги, характерные для асимметричного шифрования, можно реализовать и с помощью симметричных методов, если имеется надежная третья сторона, знающая секретные ключи своих клиентов. Эта идея положена, например, в основу сервера аутентификации Kerberos.

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

Шифрование программ гарантирует невозможность внесения в них изменений. Криптографическая защита данных осуществляется и при хранении данных и при передаче их по сети. В настоящее время возможна как программная, так и аппаратная реализация средств криптографии.

В настоящее время существует большое количество алгоритмов шифрования, алгоритмы DES и RSA подробно рассмотрены в , алгоритм Диффи-Хелмана в .

Разграничение прав доступа.

Разграничение прав доступа пользователей к ресурсам сети. Этот метод основан на использовании наборов таблиц, которые определяют права пользователей. Они построены по правилам «разрешено все, кроме» или «разрешено только». Таблицы по паролю или идентификатору пользователя определяют его права доступа к дискам, файлам, операциям чтения, записи, копирования, удаления и другим сетевым ресурсам. Такое разграничение доступа определяется, как правило, возможностями используемой ОС.

Межсетевые экраны.

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

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

Угрозы несанкционированного доступа из внутренней сети во внешнюю сеть являются актуальными в случае ограничения разрешенного доступа во внешнюю сеть правилами, установленными в организации.

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

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

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

Межсетевые экраны обеспечивают несколько типов защиты:

· блокирование нежелательного трафика;

· перенаправление входного трафика только к надежным внутренним системам;

· сокрытие уязвимых систем, которые нельзя обезопасить от атак из глобальной сети другим способом;

· протоколирование трафика в и из внутренней сети;

· сокрытие информации (имен систем, топологии сети, типов сетевых устройств и внутренних идентификаторов пользователей, от внешней сети;

· обеспечение более надежной аутентификации, чем та, которую представляют стандартные приложения.

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

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

Технология VPN на основе шифрования – совокупность защищенных каналов, созданных предприятием в открытой публичной сети для объединения своих филиалов [Олифер и Олифер]. Вышеупомянутая технология обладает рядом существенных достоинств при организации защищенного соединения, а именно:

1. Шифрование гарантирует конфиденциальность корпоративных данных при передаче их через открытую сеть;

2. Аутентификация отвечает за то, чтобы взаимодействующие системы (пользователи) были уверены в идентичности друг друга;

3. Туннелирование предоставляет возможность передавать зашифрованные пакеты через открытую сеть.

Сейчас наиболее широко применяются сети VPN на основе протоколов IPsec и SSL.

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

В таких сетях клиент самостоятельно создает туннели IPsec через IP-сеть поставщика услуг (сети типа CPVPN). Причем от поставщика требуется только предоставление стандартного сервиса по объединению сетей, следовательно предприятию доступны услуги сети поставщика и сети Интернет. Однако, конфигурирование данных сетей является сложной задачей, так как туннели IPsec двухточечные, то есть при полносвязной топологии их количество N(N-1), где N – число соединений. Необходимо еще учитывать непростую задачу поддержания инфраструктуры ключей. Протокол IPsec может применятся так же для создания виртуальных частных сетей, поддерживаемых провайдером (PPVPN) - туннели в них так же строятся на базе устройств клиента, но эти устройства удаленно конфигурируются и администрируются поставщиком услуг.

В последнее время возросла популярность VPN на основе протокола SSL. Этот протокол работает на уровне представления, непосредственно под уровнем приложений, так что приложения должны его вызвать, чтобы создать защищенный канал для своего трафика. Наиболее популярным приложением, использующим данный протокол, является веб-браузер. В этом случае защищенные каналы SSL задействуют протокол HTTP, в данном режиме работы его называют HTTPS. Браузер прибегает к данному режиму во всех случаях, когда необходимо обеспечить конфиденциальность передаваемой информации: при покупках в интернет-магазинах, при интернет-банкинге. Данный вид реализации существенно облегчает задачу конфигурирования и администрирования VPN сети.

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

Рисунок 2.3.2 – Обобщенная схема защищенного канала связи между двумя удаленными пользователями

Защищенный канал передачи данных можно построить при помощи системных средств, реализованных на разных уровнях модели OSI. Иерархия технологий защищенного канала представлена на рисунке 1.3:

Рисунок 2.3.3 – Иерархия технологий защищенного канала

Защищенный канал, реализованный на самом высоком (прикладном) уровне, защищает только вполне определенную сетевую службу, например файловую, гипертекстовую или почтовую. Так, протокол S/MIME предназначен для обеспечения криптографической безопасности электронной почты. Использование данного протокола обеспечивает аутентификация, целостность сообщения и гарантия сохранения авторства, безопасность данных (посредством шифрования). При таком подходе для каждой службы необходимо разрабатывать собственную защищенную версию протокола, что является существенным недостатком.

PPTP позволяет компьютеру устанавливать защищённое соединение с сервером за счёт создания специального туннеля в стандартной, незащищённой сети. PPTP помещает (инкапсулирует) кадры PPP в IP-пакеты для передачи по глобальной IP-сети, например Интернет. Данный протокол может также использоваться для организации туннеля между двумя локальными сетями - использует дополнительное TCP-соединение для обслуживания туннеля.

Однако описываемый протокол был объектом множества анализов безопасности, в нём были обнаружены различные серьёзные уязвимости. Известные относятся к используемым протоколам аутентификации PPP, устройству протокола MPPE, и интеграции между аутентификациями MPPE и PPP для установки сессионного ключа.

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

Взлом сессии IPSec вполне вероятен, если не используется заголовок аутентификации AH. При таком типе атаки данные злоумышленника могут быть вставлены в полезную передающуюся информацию, например, в случае Unix-систем достаточно вставить в поток команду rm -R, чтобы получатель в итоге недосчитался многих, а то и всех файлов на жестком диске.

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

В настоящее время IPSec - это часть IPv6, но не IPv4. Хотя, конечно же, имеются и реализации IPSec для протокола IP четвертой версии. В реализации для IPv6 некоторые слабые места IPSec, которые все же присутствуют в версии для IPv4, устранены. Так, например, поля фрагментации в заголовке пакета IPv4 потенциально могут быть изменены, поэтому при функционировании IPSec в транспортном режиме злоумышленник может перехватить пакет и изменить поле фрагментации, а затем вставить необходимые данные в передаваемый поток. В IPv6 же промежуточные маршрутизаторы не допускают изменения полей фрагментации.

Многие продукты, которые могут использовать IPSec, взаимодействуют с альтернативной технологией шифрования, именуемой "Уровень защищенных сокетов" (Secure Sockets Layer, SSL). Основное различие между IPSec и SSL в том, что IPSec работает на уровне сети, обеспечивая зашиту сетевого соединения от начала и до конца. SSL же действует на уровне приложений, обеспечивая защиту лишь выбранному приложению, например веб-браузеру или программе для работы с электронной почтой. Хотя как IPSec, так и SSL призваны обеспечить конфиденциальность обмена информацией, что достигается совершенно различными способами. SSL был разработан компанией Netscape для защиты трафика HTTP, проходящего через программу-браузер. SSL - протокол уровня отдельной сессии, и в этом отношении он, несомненно, проигрывает IPSec, который позволяет построить постоянный туннель, не зависящий от проходящего сквозь него сетевого трафика.

Протокол SSL основан на клиент-серверной модели и обычно используется для защиты на отрезке "хост-хост". В связи с тем, что IPSec взаимодействует на сетевом уровне, возможны такие варианты, как "подсеть-подсеть", "сеть-сеть" или "сеть-хост". Это наводит на мысль, что IPSec допускает маршрутизацию, а SSL - нет.

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

С учетом вышеизложенного при организации защищенного соединения между двумя удаленными пользователями напрашивается обоснованное решение об использовании технологии организации защищенного соединения на основе протокола SSL. Забегая вперед, следует отметить, что в процессе решения задачи по организации защищенного соединения между двумя удаленными пользователями была использована программа OpenVPN, так как она бесплатна и находится в свободном доступе (не требует покупки дополнительно сетевого оборудования, в отличие от использования стека протоколов IPsec, которое подразумевает наличие сетевого оборудования компании Cisco), к тому же используется в операционных системах Solaris, OpenBSD, FreeBSD, NetBSD, GNU/Linux, Apple Mac OS X, QNX, Microsoft Windows, Android.

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

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

Инфраструктура, используемая для поддержки сертификатов в организации, на­зывается инфраструктурой открытого ключа (Public Key Infrastructure, PKI).

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

Важно, что в отличие от алгоритмов с симметричным ключом, где для расшифро­вания и шифрования используется один и тот же ключ, в алгоритмах с открытым/ секретным ключом используются два ключа: один для шифрования, а другой - для расшифровки. Если шифрование осуществляется с использованием открытого клю­ча, то расшифровать зашифрованный текст можно только с помощью соответствую­щего секретного ключа. Если шифрование осуществляется на секретном ключе, то расшифровать текст можно только с помощью соответствующего открытого ключа.

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

1. Клиент подает запрос аутентификации.

2. Сервер создаст вопрос.

3. Рабочая станция использует свой секретный ключ для шифрования вопроса.

4. Ответ возвращается серверу.

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

6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.

Рис. 4.2. Аутентификация с использованием открытого и секретного ключей

Здесь полезно понять, что исходный набор ключей генерируется клиентом и в центр сертификации передается только открытый ключ. СА генерирует сертифи­кат и подписывает его с помощью секретного ключа, после чего возвращает копию сертификата пользователю и его базе данных.

SSL (англ. Secure Sockets Layer - уровень защищённых сокетов) - криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Дан­ная система может использоваться в электронной коммерции или в любой другой сфере, где требуется машинная аутентификация или необходимы безопасные со­единения. Transport Layer Security (TLS) - это версия SSL, стандартизированная для использования в Интернете (RFC 2246). Несмотря на то, что TLS и SSL выпол­няют одну и ту же функцию, они не являются совместимыми: сервер, использую­щий SSL, не может установить защищенный сеанс с клиентом, который использу­ет только TLS. Необходимо обеспечить совместимость приложений с SSL или TLS, прежде чем использовать одну из этих двух систем.

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

В наиболее распространенном варианте использования SSL организация полу­чает SSL-сертификат сервера из открытого центра сертификации, такого как VeriSign, и устанавливает его на свой Веб-сервер.

Процесс аутентификации состоит из следующих этапов.

1. Пользователь вводит URL сервера в браузере.

3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.

4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертифи­ката от центра сертификации, выпустившего сертификат сервера.

5. Если обнаруживается сертификат СА, браузер подтверждает сертификат посред­ством проверки подписи на сертификате сервера с использованием открытого ключа, имеющегося в сертификате СА.

6. Если проверка завершается успешно, браузер принимает сертификат сервера и считает его действительным.

7. Генерируется симметричный ключ шифрования, происходит его шифрование клиентом с использованием открытого ключа сервера.

8. Зашифрованный ключ возвращается серверу.

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

Существует множество потенциальных проблем, связанных с данной системой.

· Если веб-сервер не настроен соответствующим образом на требование исполь­зования SSL, сервер не аутентифицируется относительно клиента, и может быть установлено обычное незащищенное соединение. Безопасность зависит от того, укажет ли пользователь в строке URL браузера протокол https:/ вместо http:/.

· Если у клиента нет копии сертификата СА, она будет предложена ему сервером. Несмотря на то, что это обеспечивает наличие шифруемого соединения между клиентом и сервером, данный подход не обеспечивает аутентификацию серве­ра. Безопасность соединения здесь зависит от пользователя, который, в лучшем случае, откажется от соединения с сервером, который не идентифицирован третьей стороной.

· Процесс получения сертификата СА в хранилище браузера не является четко контролируемым. В прошлом данное обстоятельство могло потребовать уплаты денежных средств или зависело от ваших связей. Теперь же Microsoft требует, чтобы сертификаты, устанавливаемые все браузеры, были выпущены центрами сертификации, прошедшими соответствующий аудит.

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

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

Стойкость шифра SSL-сеанса прямо пропорциональна числу разрядов в ключе сеанса. Иначе говоря, считается, что ключи с большим числом разрядов безопаснее - их труднее взломать.

Для SSL-сеансов обычно применяются 40- и 128-разрядный уровни шифрования. Первый вариант подходит для большинства ситуаций, включая электронную коммерцию, а второй - обеспечивает дополнительную защиту важных личных и финансовых сведений клиента. В версиях Microsoft Windows для США реализовано 128-, а в экспортных версиях - 40-разрядное шифрование. Чтобы обновить сервер для 128-разрядного шифрования, необходимо установить специальный пакет обновления, распространяемый Microsoft.

Необходимо различать уровень шифрования SSL-сеансов (стойкость ключа сеанса, выраженная в разрядах) и уровень шифрования SSL-сертификатов (стойкость открытого и закрытого ключей сертификата, выраженная в разрядах). Обычно длина ключа шифрования, открытого или закрытого, составляет 512 или 1024 разряда. Внутренние американские и экспортные версии большинства приложений и ОС поддерживают ключи шифрования длиной 512 разрядов. Ключи длиной 1 024 и более разрядов во многих случаях не поддерживаются.

Когда пользователь пытается установить SSL-соединение с Web-сервером, клиентский браузер и сервер на основе своих ключей шифрования определяют максимально возможный уровень шифрования. Если длина ключей шифрования 512 разрядов, используется 40-разрядное, если 1 024 - 128-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.

Похожая информация.

Знаете ли Вы, в чем ложность понятия "физический вакуум"?

Физический вакуум - понятие релятивистской квантовой физики, под ним там понимают низшее (основное) энергетическое состояние квантованного поля, обладающее нулевыми импульсом, моментом импульса и другими квантовыми числами. Физическим вакуумом релятивистские теоретики называют полностью лишённое вещества пространство, заполненное неизмеряемым, а значит, лишь воображаемым полем. Такое состояние по мнению релятивистов не является абсолютной пустотой, но пространством, заполненным некими фантомными (виртуальными) частицами. Релятивистская квантовая теория поля утверждает, что, в согласии с принципом неопределённости Гейзенберга, в физическом вакууме постоянно рождаются и исчезают виртуальные, то есть кажущиеся (кому кажущиеся?), частицы: происходят так называемые нулевые колебания полей. Виртуальные частицы физического вакуума, а следовательно, он сам, по определению не имеют системы отсчета, так как в противном случае нарушался бы принцип относительности Эйнштейна, на котором основывается теория относительности (то есть стала бы возможной абсолютная система измерения с отсчетом от частиц физического вакуума, что в свою очередь однозначно опровергло бы принцип относительности, на котором постороена СТО). Таким образом, физический вакуум и его частицы не есть элементы физического мира, но лишь элементы теории относительности, которые существуют не в реальном мире, но лишь в релятивистских формулах, нарушая при этом принцип причинности (возникают и исчезают беспричинно), принцип объективности (виртуальные частицы можно считать в зависимсоти от желания теоретика либо существующими, либо не существующими), принцип фактической измеримости (не наблюдаемы, не имеют своей ИСО).

Когда тот или иной физик использует понятие "физический вакуум", он либо не понимает абсурдности этого термина, либо лукавит, являясь скрытым или явным приверженцем релятивистской идеологии.

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

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

Когда число пользователей в сети измеряется миллионами, процедура предварительной регистрации пользователей, связанная с назначением и хранением паролей пользователей, становится крайне громоздкой и практически плохо реализуемой. В таких условиях аутентификация на основе цифровых сертификатов служит рациональной альтернативой применению паролей.

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

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

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

Сертификат представляет собой электронную форму, в которой содержится следующая информация:

· открытый ключ владельца данного сертификата;

· сведения о владельце сертификата, например имя, электронный адрес, наименование организации, в которой работает данный сотрудник и т.п.;

· наименование сертифицирующей организации, выдавшей этот сертификат;

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

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

Сертификаты можно использовать не только для аутентификации, но и для предоставления определенных прав доступа. Для этого в сертификат вводятся дополнительные поля, в которых указывается принадлежность его владельца к той или иной категории пользователей.

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

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

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

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

Альтернативное решение проблемы выполнения функций сертифицирующей организации – привлечение на коммерческой основе независимых центров по выдаче сертификатов. Такие услуги предлагает, в частности, сертифицирующий центр компании Verisign. Ее сертификаты удовлетворяют требованиям международного стандарта Х.509 и используются в ряде продуктов защиты данных, например в протоколе защищенного канала SSL.