Файл: Безопасность электронных платежей в сети Интернет. Протокол защиты электронных платежей ssl(tls).pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 17.10.2024
Просмотров: 12
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
7 сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием, для того чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требуемую для того чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (premastersecret), каждый раз, когда они устанавливают соединение. Для того чтобы предотвратить остановку секрета
(premastersecret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (mastersecret) настолько быстро, на сколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Структура сообщения
Формат заголовка записей SSL
Все данные в SSL пересылаются в виде записей или рекордов - объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит 2 или 3 байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель, и полная длина заголовка равна 3 байтам. В случае длинного (3 байта) заголовка второй по старшинству бит первого байта имеет специальное значение. Если он равен 0 - рекорд является информационным, если он равен 1 - рекорд является security escape. Код длины рекорда не включает в себя число байт заголовка. Для 2-байтового заголовка его длина вычисляется так:
RECORD-LENGTH = ((byte[0] & 0x7F) << 8) | byte[1];
Здесь byte[0] - первый полученный байт, а byte[1] - второй полученный байт.
Для 3-байтового заголовка длина рекорда вычисляется следующим образом:
RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = byte[2];
Значение PADDING специфицирует число байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра. Отправитель добавляет PADDING после имеющихся данных, а затем шифрует все это, т. к. длина этого массива кратна размеру
8 блока используемого шифра. Поскольку известен объем передаваемых данных, заголовок сообщения может быть сформирован с учетом объема PADDING.
Получатель сообщения дешифрует все поле данных и получает исходную информацию, затем вычисляет истинное значение RECORD-LENGTH, при этом
PADDING из поля “данные” удаляется.
Формат информационных записей SSL
Часть данных рекорда SSL состоит из 3х компонентов:
MAC-DATA[MAC-SIZE]
ACTUAL-DATA[N]
PADDING-DATA[PADDING]
MAC-DATA - код аутентификации сообщения
MAC-SIZE - функция используемого алгоритма вычисления хеш-суммы
ACTUAL-DATA - реально переданные данные или поле данных сообщения
PADDING-DATA - данные PADDING (при блочном шифровании)
MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-
NUMBER ]
Здесь SECRET передается хеш-функции первым, затем следует ACTUAL-DATA и
PADDING-DATA, за которыми передается SEQUENCE-NUMBER - порядковый номер.
Значение SECRET зависит от того, кто именно посылает сообщение. Если это делает клиент, то SECRET равен CLIENT-WRITE-KEY. Если же клиент получает сообщение, SECRET равен CLIENT-READ-KEY.
Порядковый номер представляет собой 32-битовый код, который передается хеш- функции в виде 4 байт, используя сетевой порядок передачи “от старшего к младшему”. Порядковый номер - счетчик для сервера или клиента. Для каждого направления передачи используется пара счетчиков - для отправителя и для получателя; каждый раз, когда отправляется сообщение, счетчик увеличивает свое значение на 1.
Получатель сообщения использует ожидаемое значение порядкового номера для передачи MAC (тип хеш-функции определяется параметром CIPHER-CHOICE).
Вычисленное значение MAC-DATA должно совпадать с переданным значением. Если сравнение не прошло, сообщение считается поврежденным, что приводит к возникновению ошибки, которая вызывает закрытие соединения.
9
Окончательная проверка соответствия выполняется, когда используется блочный шифр. Объем данных в сообщении (RECORD-LENGTH) должен быть кратен размеру блока шифра. Если данное условие не выполнено, сообщение считается поврежденным, что приводит к разрыву соединения.
Для 2х-байтового заголовка максимальная длина сообщения равно 32767 байтов, для 3х-байтового 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL, а сообщения прикладного протокола могут занимать несколько рекордов SSL.
Протокол диалога SSL
Протокол диалога SSL содержит 2 основные фазы:
Фаза 1.
Первая фаза используется для установления конфиденциального канала коммуникаций.
Эта фаза инициализирует соединение, когда оба партнера обмениваются сообщениями “hello”. Клиент посылает сообщение CLIENT-HELLO. Сервер получает это сообщение, обрабатывает его и посылает в ответ сообщение SERVER-HELLO.
В этот момент и сервер и клиент имеют достаточно информации, чтобы знать, нужен ли новый master key. Если ключ не нужен, сервер и клиент переходят в фазу 2.
Когда возникает необходимость создания нового master key, сообщение сервера
SERVER-HELLO уже содержит достаточно данных для того, чтобы клиент мог сгенерировать master key. В эти данные входят подписанный сертификат сервера, список базовых шифров и идентификатор соединения (случайное число, сгенерированное сервером, которое используется на протяжении всей сессии). После генерации клиентом master key он посылает серверу сообщение CLIENT-MASTER-
KEY или же сообщение об ошибке, когда клиент и сервер не могут согласовать базовый шифр.
После определения master key сервер посылает клиенту сообщение SERVER-
VERIFY, что аутентифицирует сервер.
Фаза 2.
Фаза 2 называется фазой аутентификации. Т. к. сервер уже аутентифицирован на первой фазе, то на второй фазе осуществляется аутентификация клиента. Сервер отправляет запрос клиенту и, если у клиента есть необходимая информация, он присылает позитивный отклик, если же нет, то сообщение об ошибке. Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер.
Если верификация была неудачной, сервер посылает сообщение ERROR.
10
Когда один из партнеров послал сообщение finished он должен принимать сообщения до тех пор, пока не получит сообщение finished от другого партнера, и только когда оба партнера послали и получили сообщения finished протокол диалога
SSL закончит свою работу. С этого момента начинает работу прикладной протокол.
Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент
(С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что
“нечто” зашифровано с помощью ключа "key".
Таблица 1. При отсутствии идентификатора сессии.
Таблица 2. Идентификатор сессии найден клиентом и сервером.
11
Таблица 3. Использован идентификатор сессии и аутентификация клиента.
Криптостойкость протокола SSL
SSL 2.0
Существует ряд атак, которые могут быть предприняты против протокола SSL.
Однако SSL устойчив к этим атакам при условии, что пользователь использует только доверенные сервера для обработки информации. SSL 2.0 уязвима в некоторых ситуациях:
Идентичные криптографические ключи используются для аутентификации и шифрования сообщений;
SSL 2.0 имеет слабую MAC конструкцию, которая использует MD5 хэш- функцию с секретом префикса, что делает его уязвимым для атак;
SSL 2.0 не имеет никакой защиты для протокола рукопожатия, то есть атаки типа злоумышленник посередине (man-in-the-middle) могут остаться незамеченными;
SSL 2.0 использует TCP закрытое соединенние, чтобы указать конец данных.
Это означает, что возможна следующая атака: злоумышленник просто подделывает TCP FIN, оставив получателя без сообщения о конце передачи данных (в SSL 3.0 эту ошибку исправили);
SSL 2.0 предполагает наличие единой службы поддержки и фиксированного домена, что идет вразрез со стандартной функцией виртуального хостинга на веб-серверах.
SSL 3.0
14 октября 2014 года была выявлена уязвимость CVE-2014-3566, названная
POODLE (Padding Oracle On Downgraded Legacy Encryption). Данная уязвимость позволяет злоумышленнику осуществить атаку Man-in-the-Middle на соединение, зашифрованное с помощью SSL 3.0. Уязвимость POODLE -- это уязвимость протокола, а не какой-либо его реализации, соответственно, ей подвержены все соединения, зашифрованные SSL v3.
В SSL 3.0 есть и иные слабые моменты. К примеру, половина мастер-ключа
(master key), которая устанавливается, полностью зависит от хэш-функции MD5, которая не является устойчивой к коллизиям и, следовательно, не считается безопасной.
12
Примеры возможных атак
Атака по словарю
Такой тип атак производится, когда атакующий имеет представление о том, какого типа сообщения посылаются.
Крипто аналитик может сформировать базу данных, где ключами являются зашифрованные строки открытого текста. По созданной базе данных можно определить ключ сессии, соответствующий определенному блоку данных.
Вообще для SSL такие атаки возможны. Но SSL пытается противостоять этим атакам, используя большие ключи сессии - клиент генерирует ключ, который длиннее, чем допускается экспортными ограничениями, часть которого посылается серверу открытым текстом, а остальная часть объединяется с секретной частью, чтобы получить достаточно длинный ключ (например, 128 бит, как этого требует RC4).
Способ блокирования атак открытого текста заключается в том, чтобы сделать объем необходимого текста неприемлемо большим. Каждый бит, добавляемый к длине ключа сессии, увеличивает размер словаря в 2 раза. Использование ключа сессии длиной 128 бит делает размер словаря далеко за пределами современных технических возможностей (решение потребует такого количества атомов, которого нет во всей вселенной). Другой способ, с помощью которого SSL может противостоять данной атаке, заключается в использовании максимально возможных длин ключей (в случае не экспортного варианта). Следствием этого является то, что самым простым и дешевым способом атаки становится лобовая атака ключа, но для 128-битного ключа стоимость его раскрытия можно считать бесконечной.
Атака отражением
Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий.
Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать 264 кодов nonce, чтобы получить вероятность угадывания 50 %. Но 264 достаточно большое число, что делает эти атаки бессмысленными.
13
Взлом SSL-соединений внутри ЦОД
Наиболее известный инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore иNarusInsight, что привело к судебному процессу от лица правозащитной организации
Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации.
Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и
NarusInsight были установлены в самом ЦОД, где находились сервера, ведущие SSL- соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, принявшим их от внешних пользователей.
Тем не менее, указанный инцидент показал, что SSL не может являться надёжным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2, в ЦОД.
Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев
ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом.
THC-SSL-DOS
24 октября 2011 года организация The Hacker's Choice (THC) выпустила утилиту
THC-SSL-DOS, которую можно использовать для проведения DoS-атак на SSL серверы. Данная утилита использует уязвимость в функции повторного подтверждения SSL - SSL Renegotiation, которая изначально была предназначена для обеспечения большей безопасности SSL. Повторное подтверждение позволяет серверу создавать новый секретный ключ поверх уже имеющегося SSL-соединения. Эта функция по умолчанию включена в большинство серверов. Установка безопасного соединения, а также выполнение повторного подтверждения SSL, требуют в несколько раз больше ресурсов на стороне сервера, чем на стороне клиента, т. е. если клиент отправляет множество запросов на повторное подтверждение SSL, это истощает системные ресурсы сервера.
14
Согласно одному из участников THC, для успешного проведения атаки нужен ноутбук с установленной утилитой и доступ в интернет. Программа была опубликована в свободном доступе, потому что ее аналог появился в сети уже несколько месяцев тому назад. Также, по утверждениям разработчиков, атака может быть произведена даже в том случае, если сервер не поддерживает функцию повторного подтверждения, хотя для этого придется модифицировать метод атаки. В этом случае устанавливается множество TCP-соединений для нового рукопожатия
SSL, но для эффективной атаки необходимо больше ботов.
В качестве защиты некоторые разработчики ПО рекомендуют устанавливать особые правила для разрыва соединения с клиентом, который выполняет операцию повторного подтверждения больше установленного количества раз в секунду.
Дополнительный вопрос
Модель шифрования/дешифрования дискретных сообщений (математическое описание, требования).
Математической моделью системы шифрования/дешифрования дискретных сообщений называется - пара функций которые преобразуют сообщение в криптограмму при помощи ключа шифрования и, наоборот, криптограмму в сообщение при помощи ключа дешифрования. Обе функции, задающие криптосистему, должны удовлетворять следующим требованиям:
Функции и при известных аргументах вычисляются сравнительно просто.
Функция g при неизвестном ключе дешифрования вычисляется достаточно сложно.
Голландский криптограф А. Керкхофс (1835 - 1903) предположил, что секретность шифров должна основываться только на секретности ключа, а не на секретности алгоритма шифрования, который, в конце концов, может оказаться известным противнику.
Если ключ шифрования равен ключу дешифрования, т.е. - система называется симметричной (одноключевой). Для ее работы в пункты шифрования и дешифрования должны быть секретным образом доставлены одинаковые ключи.
Если, т.е. ключ шифрования не равен ключу дешифрования, то система шифрования называется несимметричной (двухключевой). В этом случае ключ доставляется в пункт шифрования, а ключ - в пункт дешифрования. Оба ключа очевидно должны быть связаны функциональной зависимостью, но такой, что по известному ключу шифрования нельзя было бы восстановить ключ дешифрования.
Это означает, что для несимметричной системы шифрования функция должна быть трудно вычисляемой.
15
Существуют два основных класса стойкости криптосистем:
Идеально (безусловно) стойкие или совершенные криптосистемы, для которых стойкость к криптоанализу (дешифрованию) без знания ключа не зависит от вычислительной мощности оппонента. Их называют теоретически не дешифруемыми (ТНДШ) системами.
Вычислительно стойкие криптосистемы, у которых стойкость к криптоанализу зависит от мощности вычислительной системы оппонента.