Протокол записи (SSL RP).
Спецификация SSL предполагает использование для защиты трафика блочных шифров в режиме сцепления блоков (cipher block chaining - СВС). Пусть Р = Рр..., Р, - открытый текст с длиной каждого блока Л, равной длине блока открытого текста алгоритма блочного шифрования, используемого протоколом. С0 = /V- век-тор инициализации, sk - секретный ключ шифра. Блоки шифртек- ста вычисляются в этом режиме следующим образом:
CI -ESK(P. ©Cw)І -1,/. Последовательность блоков С0,...,С, и является шифртекстом, хотя передавать С0 нет необходимости, так как получатель уже знает его или закон его получения - эта величина не является секретной. Для расшифрования текста получатель
вычисляет Pi = (С-)©Сы,і = 1,1. Обычной практикой является выбор нового, случайного значения вектора инициализации С0 для
каждого открытого текста. Однако для работы шифра в режиме сце-пления блоков не имеет значения, как эта величина выбирается. В протоколе SSL, например, установлено, что вектор инициализации для каждого нового открытого текста берется равным последнему блоку шифртекста, полученному при шифровании предыдущего со-общения. Этот способ называют цепочкой векторов инициализации. Самое первое значение вектора инициализации выбирается по псев-дослучайному алгоритму.
Необходимо иметь в виду, что на такой протокол при опреде-ленных условиях возможно осуществление атаки по выбранным от-крытым текстам.
В научной литературе описаны примеры таких атак. Предположим, что противник желает проверить свое предпо-ложение о том, что определенный блок открытого текста принимает некоторое фиксированное значение, а именно противник, наблю-дающий шифртекст С0,...,Су, хочет определить, равен ли блок от-крытого текста Pj величине Р* При этом противник знает вектор инициализации, который будет использован при шифровании сле-дующего сообщения: он равен последнему блоку шифртекста теку-щего сообщения С/. Посмотрим, что будет, если противник вынудитотправителя сообщения зашифровать сообщение Р\ первый блок /
которого Рх равен Cj_x © С, © Р *. Первый блок шифртекста будет вычислен отправителем следующим образом:
с/ = Ей (/>' ®С,)=Esk (сн © q ® Р *®с,)=еа (Р*есн).
Однако мы также знаем, что Ci = Esk © См). А это означает, /
что С, = CJ тогда и только тогда, когда Р.-Р *. Таким путем про-тивник может проверить свою догадку относительно того, что блок открытого текста Pj принимает значение Р*. В частности, если про-тивник знает, что Pj - одна из двух возможных величин, то против-ник сможет определить истинное значение этого блока открытого текста всего за одну попытку. Если же блок может принимать одно из N возможных значений, противник сможет узнать его значение в среднем за N/2 попытки.
Такая атака показывает, что протокол SSL не в полной мере удовлетворяет принятому в криптографии определению безопасности схем шифрования и, например, в случае, если открытым текстом является короткий пароль, противник может раскрыть его полно-стью, осуществляя словарную атаку (т. е. перебирая наиболее веро-ятные значения этого пароля). Рассмотрим условия, при которых такая атака на пароль или PIN-код становится возможной. Во-первых, злоумышленник должен знать номер j блока открытого текста, со-держащего интересующую его информацию. Для этого достаточно, например, знать формат сообщений протокола HTTPS. Во-вторых, противник должен знать блок шифртекста С,_і - его он получает из открытого канала связи.
В-третьих, противник должен знать значение вектора инициализации для следующего сообщения: он получает его из наблюдения предыдущего сеанса связи. Наконец, нужно иметь возможность подставить выбранный открытый текст в первый блок следующего передаваемого отправителем сообщения. Это, пожалуй, самое трудновыполнимое для противника условие. Однако и это условие осуществимо, если противник сумеет убедить пользова-теля установить дополнительный компонент веб-браузера, реали-зующий такую программную закладку. При выполнении всех пере-численных условий такая атака становится вполне реальной. Из на-учной литературы известны и другие, более «тонкие» примеры атак на стандартные режимы работы блочных шифров, которые стано-вятся возможными не в силу неправильной или неудачной конст-рукции самих режимов шифрования, а именно в силу технических особенностей их реализации.Подводя итог рассмотрению самых употребительных способов реализации защищенных каналов передачи информации, можно сделать следующие выводы. Каждому из рассмотренных методов (IPSec и SSL) присущи свои достоинства и недостатки. Отметим сначала достоинства каждого метода. Так, основными преимуществами решений, основанных на архитектуре IPSec, можно считать следующие:
• Архитектура IPSec обеспечивает дополнительный уровень защиты, если требуется, чтобы на клиентской машине не только функционировала ПП, например, для соединения с виртуальной частной сетью, но и чтобы эта машина была должным образом сконфигурирована. Это создает дополнительные преграды для злоумышленника, который пытается осуществить несанкциони-рованный доступ к сети.
Архитектура IPSec относится к сетевому уровню коммуникаци-онной модели OSI, инкапсулируя обычные IP-пакеты. Поскольку при этом образуется туннельное соединение, любая ПП (веб- приложение, электронная почта, FTP-сервис, протокол telnet, го-лосовой протокол VoIP и др.) может использовать его без огра-ничений. Это может быть большим преимуществом для сред со множеством ПП, но может стать недостатком в том случае, если удаленный клиент будет скомпрометирован.
Архитектура IPSec хорошо подходит для реализации защищенной сети, состоящей из отдельных, географически распределенных узлов, поскольку они могут быть реализованы в любых сетевых устройствах без модификации клиентских ОС или при-кладного ПО.
На базе архитектуры IPSec могут создаваться виртуальные част-ные сети, которые поддерживают любые ПП, ориентированные на архитектуру TCP/IP, поскольку сами IP-пакеты при этом не подвергаются внешним изменениям.
Вместе с этим нельзя не отметить следующие несомненные пре-имущества решений, основанных на спецификации SSL:
SSL - это общепринятая, повсеместно реализуемая спецификация, и большинство веб-браузеров уже имеют встроенную реа-лизацию SSL, т.
е. почти каждый компьютер, имеющий выход в Интернет, имеет готовЫЙ «клиентскЫЙ компонент», реали-зующий этот метод.SSL допускает более точный контроль доступа к ресурсам системы. Во-первых, он реализует туннели для каждой отдельно взятой ПП, а не для всей корпоративной локальной сети. Таким образом, пользователи SSL-соединений могут иметь доступ только к тем ПП, к которым им был разрешен доступ, а не ко всей сети. Во-вторых, в этом случае гораздо легче присваивать различным пользователям различные права доступа и осуществлять более тонкий контроль над каждой попыткой доступа. SSL удобна для «разовых» соединений с пользователями, работаю- щими с ресурсами системы не систематически, а от случая к случаю.
SSL функционирует прозрачно через все прокси-серверы и мар-шрутизаторы, выполняющие трансляцию сетевых адресов, и ис-пользует TCP-порты, которые обычно остаются открытыми для межсетевых экранов.
В то же время каждому из двух подходов свойственны и опреде-ленные недостатки. Так, для архитектуры IPSec можно отметить следующие слабости:
Большинство решений на базе архитектуры IPSec требуют про-граммных и аппаратных компонентов сторонних производителей. Для доступа к протоколам на каждой вычислительной системе необходимо иметь инсталлированное ПО, реализующее не-обходимые для этого функции. Покупка большого числа лицензий на такие программные продукты, их техническая под-держка и конфигурирование связаны с немалыми дополнительными расходами.
Продукты и сервисы на базе архитектуры IPSec не всегда предос-тавляют простые решения для сложных конфигураций удаленного доступа, включающего трансляцию сетевых адресов, расстановку и конфигурирование множества межсетевых экранов.
Недостаток стандартов и отсутствие соглашений между фирмами-поставщиками решений на базе IPSec может вызвать пробле-мы при интеграции продуктов и изделий различных производи-телей.
Среди недостатков спецификации SSL и основанных на ней ре-шений выделим такие:
Спецификация SSL может использоваться для организации вирту-альных частных сетей.
Однако виртуальные частные сети на базе SSL реально создаются сейчас лишь для веб-приложений. Вполне возможна защита и других прикладных программ таким же способом, но это вносит дополнительные сложности в уже готовые про-граммно-аппаратные решения. Прямой доступ только к веб- приложениям, поддерживающим SSL, означает, что пользователи такой виртуальной сети не будут иметь прямого доступа к сетевым ресурсам (принтеры, средства сетевого хранения данных), не будут
способны использовать эту сеть для групповой работы с файлами, для резервного копирования данных.
Протоколы SSL привносят довольно большие дополнительные вычислительные расходы как для клиентских вычислительных средств, так и для системных устройств сети; например, они мо-гут требовать выполнения нескольких протоколов рукопожатия в течение одного сеанса.
Спецификация SSL не подходит для организации виртуальной сети между оконечными точками соединений пользователей. Чтобы SSL-пакеты могли проходить через IP-сеть, на межсете-вых экранах должен быть открыт порт для протокола HTTPS.
Вывод о целесообразности использования того или иного метода в каждом конкретном случае можно сделать только с учетом всех обстоятельств и условий, существующих в той или иной информа-ционной системе. Сейчас же можно дать лишь одну, самую общую рекомендацию: по-видимому, решения, основанные на архитектуре IPSec, целесообразно применять для горизонтальных задач элек-тронной коммерции, в то время как решения на базе протокола SSL и ему подобных более подходят для вертикальных задач.