2015-05-15
2172
В этом разделе описаны технологии, которые используются для поддержки целостности и конфиденциальности данных. Протоколами безопасности на транспортном уровне являются SSL и Secure Shell Protocol (SSH), которые обеспечивают безопасную передачу данных между клиентом и сервером. Оба протокола разработаны рабочей группой IETF по безопасности транспортного уровня (Transport Layer Security — TLS). Безопасный протокол передачи гипертекста (S-HTTP) предоставляет надежный механизм web-транзакций, однако в настоящее время наиболее популярным средством является SSL. Средство SOCKS является рамочной структурой, позволяющей приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами сетевого межсетевого экрана. Протокол безопасности IP (IPSec) представляет собой набор стандартов поддержки целостности и конфиденциальности данных на сетевом уровне (в сетях IP). X.509 — это стандарт безопасности и аутентификации, который поддерживает структуры безопасности электронного информационного транспорта. Он определяет структуру данных цифрового сертификата и решает вопросы обращения общих ключей. X.509 является важнейшим компонентом инфраструктуры общих ключей (PKI).
SSL
SSL — это открытый протокол, разработанный компанией Netscape. SSL определяет механизм поддержки безопасности данных на уровне между протоколами приложений (такими как Hypertext Transfer Protocol [HTTP], Telnet, Network News Transfer Protocol [NNTP] или File Transfer Protocol [FTP]) и протоколом TCP/IP. Он поддерживает шифрование данных, аутентификацию серверов, целостность сообщений и (в качестве опции) аутентификацию клиентов в канале TCP/IP. SSL был представлен рабочей группе по безопасности консорциума W3 (W3C) для утверждения в качестве стандартного средства безопасности Web-браузеров и серверов в сети Интернет.
Основная цель протокола SSL состоит в том, чтобы обеспечить защищенность и надежность связи между двумя подключенными друг к другу приложениями. Этот протокол состоит из двух уровней. Нижний уровень, который располагается поверх надежного транспортного протокола (например, TCP), называется SSL Record Protocol. SSL Record Protocol используется для встраивания различных протоколов высокого уровня. Один из таких встроенных протоколов, SSL Handshake Protocol, позволяет серверу и клиенту аутентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, прежде чем протокол приложения произведет обмен первыми битами данных. Одно из преимуществ SSL состоит в том, что он независим от протоколов приложений. Протокол высокого уровня может совершенно прозрачно располагаться поверх протокола SSL.
Протокол SSL поддерживает безопасность связи, придавая ей следующие свойства:
· Защищенность связи. После первоначального квитирования связи применяются средства шифрования и определяется секретный ключ. Для шифрования данных используются средства симметричной криптографии (например, DES, RC4 и т. д.).
· Участник сеанса связи может быть аутентифицирован и с помощью общих ключей, то есть средствами асимметричной криптографии (например, RSA, DSS и т.д.).
· Надежность связи. Транспортные средства проводят проверку целостности сообщений с помощью зашифрованного кода целостности (MAC). Для вычисления кодов МАС используются безопасные хэш-функции (например, безопасный хэш-алгоритм [SHA], MD5 и т. д.).
Протокол SSL состоит из нескольких уровней.
На каждом уровне сообщения имеют ряд полей для указания длины, описания и содержания. SSL воспринимает данные, предназначенные для передачи, делит их на управляемые блоки, проводит компрессию данных (если это необходимо), использует код MAC, производит шифрование и передает результат.
Принятые данные расшифровываются, проверяются, декомпрессируются и реассемблируются, а затем передаются клиентам более высокого уровня.
Протокол SSL принят только в рамках HTTP.
Другие протоколы доказали свою способность работать с SSL, но используют ее не часто.
SSH
Протокол Secure Shell (SSH) предназначен для защиты удаленного доступа и других сетевых услуг в незащищенной сети. Он поддерживает безопасный удаленный вход в сеть, безопасную передачу файлов и безопасную эстафетную передачу сообщений по протоколам TCP/IP и X11. SSH может автоматически шифровать, аутентифицировать и сжимать передаваемые данные. В настоящее время SSH достаточно хорошо защищен от криптоанализа и протокольных атак. Он довольно хорошо работает при отсутствии глобальной системы управления ключами и инфраструктуры сертификатов и при необходимости может поддерживать инфраструктуры сертификатов, которые существуют в настоящий момент (например, DNSSEC, простую инфраструктуру общих ключей [SPKI], X.509).
Протокол SSH состоит из трех основных компонентов:
· Протокол транспортного уровня. Обеспечивает аутентификацию сервера, конфиденциальность и целостность данных с отличной защищенностью эстафетной передачи. В качестве опции может поддерживаться компрессия данных.
· Протокол аутентификации пользователя позволяет серверу аутентифицировать клиента.
· Протокол соединения мультиплексирует зашифрованный туннель, создавая в нем несколько логических каналов.
Все сообщения шифруются с помощью IDEA или одного из нескольких других шифровальных средств (тройного DES с тремя ключами, DES, RC4-128, Blowfish). Обмен ключами шифрования происходит с помощью RSA, а данные, использованные при этом обмене, уничтожаются каждый час (ключи нигде не сохраняются).
Каждый центральный компьютер имеет ключ RSA, который используется для аутентификации центрального компьютера при использовании специальной технологии аутентификации RSA. Для защиты от подслушивания (спуфинга) сети IP используется шифрование; для защиты от DNS и спуфинга маршрутизации используется аутентификация с помощью общих ключей. Кроме того, ключи RSA используются для аутентификации центральных компьютеров.
Недостатком протоколов безопасности, действующих на уровне сессий, является их зависимость от инструкций протокола транспортного уровня. В случае SSL это означает, что атака на TCP может быстро прервать сессию SSL и потребовать формирования новой сессии, в то время как TCP будет считать, что все идет нормально.
Преимущества средств безопасности транспортного уровня (например, SSL или SSH) включают:
· возможность действий на сквозной основе (end-to-end) с существующими стеками TCP/IP, существующими интерфейсами прикладного программирования (API) (WinSock, Berkeley Standard Distribution [BSD] и т. д.);
· повышенная эффективность по сравнению с медленными каналами, поддержка технологии Van Jacobson для компрессии заголовков, поддержка различных средств контроля за переполнением сети, просматривающих заголовки TCP/IP;
· отсутствие каких-либо проблем с фрагментацией, определением максимального объема блоков, передаваемых по данному маршруту (MTU) и т. д.;
· сочетание компрессии с шифрованием. На этом уровне такое сочетание оказывается гораздо более эффективным, чем на уровне пакетов.
S-HTTP
S-HTTP представляет собой безопасный протокол связи, ориентированный на сообщения и разработанный для использования в сочетании с HTTP. Он предназначен для совместной работы с моделью сообщений HTTP и легкой интеграции с приложениями HTTP. Этот протокол предоставляет клиенту и серверу одинаковые возможности (он одинаково относится к их запросам и ответам, а также к предпочтениям обеих сторон). При этом сохраняется модель транзакций и эксплуатационные характеристики HTTP.
Клиенты и серверы S-HTTP допускают использование нескольких стандартных форматов криптографических сообщений. Клиенты, поддерживающие S-HTTP, могут устанавливать связь с серверами S-HTTP и наоборот, эти серверы могут связываться с клиентами S-HTTP, хотя в процессе подобных транзакций функции безопасности S-HTTP использоваться скорее всего не будут. S-HTTP не требует от клиента сертификатов общих ключей (или самих общих ключей), потому что этот протокол поддерживает только операции с симметричными шифровальными ключами. Хотя S-HTTP может пользоваться преимуществами глобальных сертификационных инфраструктур, для его работы такие структуры не обязательны.
Протокол S-HTTP поддерживает безопасные сквозные (end-to-end) транзакции, что выгодно отличает его от базовых механизмов аутентификации HTTP, которые требуют, чтобы клиент попытался получить доступ и получил отказ, и лишь затем включают механизм безопасности. Клиенты могут быть настроены таким образом, чтобы любая их транзакция автоматически защищалась (обычно с помощью специальной метки в заголовке сообщения). Такая настройка, к примеру, часто используется для передачи заполненных бланков. Если вы используете протокол S-HTTP, вам никогда не придется отправлять важные данные по сети в незащищенном виде.
S-HTTP поддерживает высокий уровень гибкости криптографических алгоритмов, режимов и параметров.
Для того, чтобы клиенты и серверы смогли выбрать единый режим транзакции (так, например, им нужно решить, будет ли запрос только шифроваться или только подписываться или и шифроваться, и подписываться одновременно; такое же решение нужно принять и для ответов), используется механизм согласования опций, криптографических алгоритмов (RSA или Digital Signature Standard [DSA] для подписи, DES или RC2 для шифрования и т. д.), и выбора сертификатов (например: «Подписывайтесь своим сертификатом Verisign»). S-HTTP поддерживает криптографию общих ключей и функцию цифровой подписи и обеспечивает конфиденциальность данных.
SOCKS
SOCKS разработан для того, чтобы дать возможность приложениям клиент/сервер в доменах TCP и UDP удобно и безопасно пользоваться услугами межсетевого экрана. Он дает пользователям возможность преодолевать межсетевой экран организации и получать доступ к ресурсам, расположенным в сети Интернет.
SOCKS является «посредником уровня приложений»: он взаимодействует с общими сетевыми средствами (например, Telnet и браузер Netscape) и с помощью центрального сервера (прокси-сервера) от имени вашего компьютера устанавливает связь с другими центральными компьютерами.
SOCKS был разработан много лет назад Дейвом Кобласом (Dave Koblas) из компании SGI, и сегодня этот код можно бесплатно получить через Интернет. С момента первого выпуска этот код пережил несколько крупных модификаций, но каждая из них распространялась совершенно бесплатно. SOCKS версия 4 решает вопрос незащищенного пересечения межсетевых экранов приложениями клиент/сервер, основанными на протоколе TCP, включая Telnet, FTP и популярные информационные протоколы, такие как HTTP, Wide Area Information Server (WAIS) и GOPHER. SOCKS версия 5, RFC 1928, является дальнейшим расширением четвертой версии SOCKS. Он включает в себя UDP, расширяет общую рамочную структуру, придавая ей возможность использования мощных обобщенных схем аутентификации, и расширяет систему адресации, включая в нее имя домена и адреса IP v6.
В настоящее время предлагается создать механизм управления входящими и исходящими многоадресными сообщениями IP, которые проходят через межсетевой экран. Это достигается определением расширений для существующего протокола SOCKS V.5, что создает основу для аутентифицированного перехода межсетевого экрана одноадресным пользовательским трафиком TCP и UDP. Однако ввиду того, что поддержка UDP в текущей версии SOCKS V.5 имеет проблемы с масштабируемостью и другие недостатки (и их обязательно нужно разрешить, прежде чем переходить к многоадресной передаче), расширения определяются двояко: как базовые расширения UDP и как многоадресные расширения UDP.
Функционирование SOCKS заключается в замене стандартных сетевых системных вызовов в приложении их специальными версиями. Эти новые системные вызовы устанавливают связь с прокси-сервером SOCKS (который конфигурируется самим пользователем в приложении или системным файлом конфигурации), подключаясь к хорошо известному порту (обычно это порт 1080/TCP). После установления связи с сервером SOCKS приложение отправляет серверу имя машины и номер порта, к которому хочет подключиться пользователь. Сервер SOCKS реально устанавливает связь с удаленным центральным компьютером, а затем прозрачно передает данные между приложением и удаленной машиной. При этом пользователь даже не подозревает, что в канале связи присутствует сервер SOCKS.
Трудность с использованием SOCKS состоит в том, что кто-то должен проводить работу по замене сетевых системных вызовов версиями SOCKS (этот процесс обычно называется «SOCKS-ификацией» приложения).
К счастью, большинство обычных сетевых приложений (Telnet, FTP, finger, whois) уже SOCKSифицированы, и многие производители включают поддержку SOCKS в свои коммерческие приложения.
Кроме того, SOCKS V.5 включает эти процедуры в свою общую библиотеку: на некоторых системах (например, на машинах Solaris) можно автоматически SOCKS-ифицировать приложение, поставив общую библиотеку SOCKS перед «shared libc» в вашей строке поиска библиотек (переменная среды LD_LIBRARY_PATH в системах Solaris).
IPSec
Безопасный протокол IP (IPSec) представляет собой набор стандартов, используемых для защиты данных и для аутентификации на уровне IP. Текущие стандарты IPSec включают независимые от алгоритмов базовые спецификации, которые являются стандартными RFC.
Эти RFC, перечисленные ниже, сейчас пересматриваются с целью разрешения различных проблем безопасности, которые имеются в текущих спецификациях.
· RFC 2401 (Security Architecture for the Internet Protocol) – Архитектура защиты для протокола IP.
· RFC 2402 (IP Authentication header) – Аутентификационный заголовок IP.
· RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) – Использование алгоритма хэширования MD-5 для создания аутентификационного заголовка.
· RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) – Использование алгоритма хэширования SHA-1 для создания аутентификационного заголовка.
· RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) – Использование алгоритма шифрования DES.
· RFC 2406 (IP Encapsulating Security Payload (ESP)) – Шифрование данных.
· RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) – Область применения протокола управления ключами.
· RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) – Управление ключами и аутентификаторами защищенных соединений.
· RFC 2409 (The Internet Key Exchange (IKE)) – Обмен ключами.
· RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) – Нулевой алгоритм шифрования и его использование.
· RFC 2411 (IP Security Document Roadmap) – Дальнейшее развитие стандарта.
· RFC 2412 (The OAKLEY Key Determination Protocol) – Проверка аутентичности ключа.
Заметим, что со временем будут разработаны новые алгоритмы аутентификации и шифрования. Работа над ними не прекращается, и в результате мы будем иметь смесь из этих алгоритмов, одни из которых будут сильнее, а другие слабее.
Протокол IPSec также включает криптографические методы, удовлетворяющие потребности управления ключами на сетевом уровне безопасности. Протокол управления ключами Ассоциации безопасности Интернет (Internet Security Association Key Management Protocol — ISAKMP) создает рамочную структуру для управления ключами в сети Интернет и предоставляет конкретную протокольную поддержку для согласования атрибутов безопасности. Само по себе это не создает ключей сессии, однако эта процедура может использоваться с разными протоколами, создающими такие ключи (например, с Oakley), и в результате мы получаем полное решение для управления ключами в Интернет.
Стандарт IPSec позволит поддержать на уровне IP потоки безопасных и аутентичных данных между взаимодействующими устройствами, включая центральные компьютеры, межсетевые экраны (сетевые фильтры) различных типов и маршрутизаторы. Ниже приводится пример использования IPSec для обеспечения обмена аутентифицированными конфиденциальными данными между удаленным маршрутизатором и межсетевым экраном (см. рисунок 22).
Прежде чем пройти через межсетевой экран предприятия, весь трафик, идущий от удаленного маршрутизатора, должен быть аутентифицирован. Маршрутизатор и межсетевой экран должны согласовать «ассоциацию безопасности» (SA), то есть прийти к согласию относительно политики в области безопасности.
SA включает:
· алгоритм шифрования;
· алгоритм аутентификации;
· общий ключ сессии;
· срок действия ключа.
Ассоциация SA является однонаправленной, поэтому для двусторонней связи нужно устанавливать две SA, по одной для каждого направления. Как правило, в обоих случаях политика остается той же самой, но существует возможность и для асимметричной политики в разных направлениях. Согласование SA проводится через ISAKMP. Кроме того, SA могут определяться вручную. На рисунке 23 показан процесс согласования через ISAKMP, который происходит, когда на маршрутизатор поступает пакет, предназначенный для межсетевого экрана предприятия.
После согласования SA принимается решение о том, следует ли использовать средства аутентификации, конфиденциальности и целостности данных или ограничиться только аутентификацией. Если использоваться будут только средства аутентификации, текущий стандарт предполагает применение хэш-функции, а точнее алгоритма не ниже MD5 с 128-разрядными ключами. Заголовок пакета и данные пропускаются через хэш-функцию, и результаты этого вычисления вводятся в специальное поле заголовка AH, как показано на рисунке 24.
Новый пакет с аутентификационным заголовком, расположенным между заголовком IP и данными, отправляется через маршрутизатор в пункт назначения. Когда этот пакет попадает на межсетевой экран, который проверяет его аутентичность, вычисляя хэш с помощью хэш-функции, указанной в SA, обе стороны должны использовать одни и те же хэш-функции. Как показано на рисунке 25, межсетевой экран сравнивает вычисленный им хэш с параметрами, указанными в соответствующем поле AH.
Если эти величины совпадают, аутентичность и целостность данных считается доказанной (если пакет передан из удаленной точки и при передаче не был искажен ни один бит). Заметим, что вставка заголовка АН расширяет пакет, и поэтому для данного пакета может потребоваться фрагментация. Фрагментация производится после заголовка AH для исходящих пакетов и перед ним для входящих пакетов. Если, помимо всего вышесказанного, стороны пожелают использовать средства поддержки конфиденциальности, SA указывает, что весь трафик, поступающий из удаленного маршрутизатора на межсетевой экран предприятия, должен аутентифицироваться и шифроваться. В противном случае межсетевой экран его не пропустит. ESP поддерживает аутентификацию, целостность и конфиденциальность данных и работает в двух режимах: туннельном и транспортном, как показано на рисунках 26 и 27.
В туннельном режиме вся датаграмма IP, заголовок IP и данные встраиваются в заголовок ESP. В транспортном режиме шифруются только данные, а заголовок IP передается в незашифрованном виде.
Современные стандарты требуют использования DES в режиме цепочки зашифрованных блоков (CBC). Заметим, что вставка заголовка АН расширяет пакет, и поэтому для данного пакета может потребоваться фрагментация. Фрагментация производится после ESP для исходящих пакетов и перед ESP для входящих пакетов.
Преимущества поддержки безопасности на сетевом уровне с помощью IPSec включают:
· поддержку совершенно немодифицированных конечных систем, хотя в этом случае шифрование нельзя назвать в полном смысле слова сквозным (end-to-end);
· частичную поддержку виртуальных частных сетей (VPN) в незащищенных сетях;
· поддержку транспортных протоколов, иных, чем TCP (например, UDP);
· защиту заголовков транспортного уровня от перехвата и, следовательно, более надежную защиту от анализа трафика;
· при использовании AH и средств обнаружения повторяющихся операций обеспечивается защита от атак типа «отказ от обслуживания», основанных на «затоплении» систем ненужной информацией (например, от атак TCP SYN).
X.509
Многие протоколы и приложения, которые пользуются услугами Интернет, применяют в целях безопасности технологию общих ключей. Для безопасного управления общими ключами в среде широкораспределенных пользователей или систем им необходим PKI. Стандарт X.509 представляет собой весьма популярную основу для подобной инфраструктуры. Он определяет форматы данных и процедуры распределения общих ключей с помощью сертификатов с цифровыми подписями, которые проставляются сертификационными органами (CA). RFC 1422 создает основу для PKI на базе X.509, что позволяет удовлетворить потребности электронной почты с повышенным уровнем защищенности, передаваемой через Интернет (PEM). С момента появления RFC 1422 требования приложений к PKI для сети Интернет резко выросли. Столь же резко возросли и возможности X.509. Предстоит большая работа по поддержке цифровых сертификатов в web-приложениях, а также в приложениях электронной почты и приложениях IPSec. В действующих стандартах определен сертификат X.509 версия 3 и список отзыва сертификатов (CRL) версия 2. Для технологии общих ключей необходимо, чтобы пользователь общего ключа был уверен, что этот ключ принадлежит именно тому удаленному субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты общих ключей, то есть структуры данных, которые связывают величины общих ключей с субъектами.
Эта связь достигается цифровой подписью доверенного CA под каждым сертификатом. Сертификат имеет ограниченный срок действия, указанный в его подписанном содержании. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищенные каналы связи и серверные системы, а также храниться в кэш-памяти незащищенных пользовательских систем. Содержание сертификата должно быть одинаковым в пределах всего PKI. В настоящее время в этой области предлагается общий стандарт для Интернет с использованием формата X.509 v3 (см. рисунок 28).
Каждый сертификат состоит из трех основных полей: текста сертификата, алгоритма подписи и самой подписи. В тексте сертификата указывается номер версии, серийный номер, имена эмитента и субъекта, общий ключ для субъекта, срок действия (дата и время начала и окончания действия сертификата). Иногда в этом тексте содержится дополнительная опционная информация, которую помещают в уникальные поля, связывающие пользователей или общие ключи с дополнительными атрибутами.
Алгоритм подписи – это алгоритм, который использует CA для подписи сертификата. Подпись создается пропусканием текста сертификата через одностороннюю хэш-функцию. Величина, получаемая на выходе хэш-функции, зашифровывается частным ключом CA. Результат этого шифрования и является цифровой подписью (см. рисунок 29).
При выдаче сертификата подразумевается, что он будет действовать в течение всего указанного срока. Однако могут возникнуть обстоятельства, требующие досрочного прекращения действия сертификата. Эти обстоятельства могут быть связаны с изменением имени, изменением ассоциации между субъектом и CA (если, например, сотрудник уходит из организации), а также с раскрытием или угрозой раскрытия соответствующего частного ключа. В этих случаях CA должен отозвать сертификат. CRL представляет собой список отозванных сертификатов с указанием времени. Он подписывается CA и свободно распространяется через общедоступный репозиторий. В списке CRL каждый отозванный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и срок его действия, но и просматривает последний из доступных списков CRL, проверяя, не отозван ли этот сертификат. Значение термина «последний из доступных» зависит от местной политики в области безопасности, но обычно здесь имеется в виду самый последний список CRL. CA составляет новые списки CRL на регулярной основе с определенной периодичностью (например, каждый час, каждый день или каждую неделю). Отозванные сертификаты немедленно вносятся в список CRL. Записи об отозванных сертификатах удаляются из списка в момент истечения официального срока действия сертификатов.
На рисунке 30 показан пример связи между системами и единым CA при помощи цифровых сертификатов.
Оба маршрутизатора и CA имеют свои пары общих/частных ключей. Вначале CA должен передать обоим маршрутизаторам по защищенным каналам сертификат X.509 v3. Кроме того, оба маршрутизатора должны получить по защищенным каналам копию общего ключа CA. После этого, если маршрутизатор в Нью-Йорке имеет трафик для отправки парижскому маршрутизатору и хочет передать этот трафик аутентичным и конфиденциальным способом, он должен предпринять следующие шаги:
1. Маршрутизатор в Нью-Йорке направляет запрос в CA для получения общего ключа парижского маршрутизатора.
2. CA отправляет ему сертификат парижского маршрутизатора, подписанный своим частным ключом.
3. Маршрутизатор в Нью-Йорке проверяет подпись общим ключом CA и убеждается в аутентичности общего ключа парижского маршрутизатора.
4. Парижский маршрутизатор направляет запрос в CA для получения общего ключа нью-йоркского маршрутизатора.
5. CA отправляет ему сертификат нью-йоркского маршрутизатора, подписанный своим частным ключом.
6. Парижский маршрутизатор проверяет подпись общим ключом CA и убеждается в аутентичности общего ключа нью-йоркского маршрутизатора.
Теперь, когда оба маршрутизатора обменялись своими общими ключами, они могут пользоваться средствами шифрования и с помощью общих ключей отправлять друг другу аутентичные конфиденциальные данные. Для получения общего секретного ключа обычно используется метод Диффи-Хеллмана, поскольку общий секретный ключ, как правило, применяется для шифрования больших объемов данных.
Предстоит большая работа по созданию эффективной инфраструктуры обращения общих ключей в среде Интернет и в корпоративной среде. Еще не решены вопросы ввода в действие новых сертификатов (как регистрировать новый сертификат в CA?), распределения сертификатов через какую-то службу директорий (рассматривается возможность использования для этой цели FTP или Lightweight Directory Access Protocol [LDAP]) и перекрестной сертификации сертификатов (управления иерархией сертификатов).
