Атака на Internet

Медведовский Илья

1. Текст, зашифрованный на одном ключе, может быть дешифрован на другом.

2. Знание одного ключа не позволяет вычислить другой.

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

В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p

и примитивного корня степени p – 1 из 1 в поле вычетов по модулю p.

Тогда эти пользователи действуют в соответствии с нижеприведенным протоколом (рис. 7.4):

Рис. 7.4. Алгоритм открытого распределения ключей

1. A вырабатывает случайное число x, вычисляет число ax (mod p) и посылает его B.

2. B вырабатывает случайное число у, вычисляет число ay (mod p) и посылает его A.

3. Затем A и B возводят полученное число в степень со своим показателем и получают число axy (mod p).

Это число и является сеансовым ключом для одноключевого алгоритма, например DES. Для раскрытия этого ключа криптоаналитику необходимо по известным ax (mod p) и ay (mod p) найти axy (mod p), то есть x или у. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача труднорешаема, и поэтому полученный ключ может быть стойким [7].

Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений ax (mod p) и ay (mod p) не позволит атакующему получить конечный ключ шифрования axy (mod p). Далее этот ключ должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. В завершение сформулируем следующий принцип защищенного взаимодействия объектов РВС.

...

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

...

Необходимо обеспечить цифровую подпись сообщений.

...

Необходимо обеспечить возможность шифрования сообщений.

Контроль за маршрутом сообщения

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

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

Другой вариант решения – создать в заголовке пакета специальные поля, куда каждый маршрутизатор,

через который проходит пакет, заносит маршрутную информацию (например, часть своего IP-адреса). При этом первый маршрутизатор, на который поступил пакет, заносит также информацию о классе сети (A, B, C), откуда пришел пакет. Тем не менее внесение в пакет адресов всех пройденных маршрутизаторов будет неоптимальным решением, так как сложно заранее определить максимальный размер заголовка пакета, и это может серьезно увеличить размер передаваемого пакета.

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

Из всего вышесказанного следует принцип защищенного взаимодействия объектов РВС.

...

В распределенной ВС на сетевом уровне необходимо обеспечить контроль за маршрутом сообщений для аутентификации адреса отправителя.

Контроль за виртуальными соединениями

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

1. Контроль за созданием соединения.

2. Контроль за использованием соединения.

Решение второй задачи лежит на поверхности: так как сетевая операционная система не может одновременно иметь бесконечное число открытых ВК, то в случае, если ВК простаивает в течение определенного системой тайм-аута, происходит закрытие соединения. Выбор тайм-аута очистки очереди зависит от ряда параметров (подробнее об этом см. в главе 4).

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

Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и когда до него дойдет время, система выдаст ответ и отошлет его отправителю. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых, система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь, при условии, что она не заполнена (так построены сетевые ОС, поддерживающие протокол TCP/ IP), то в случае атаки это приведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов из-за того, что атакующий посылает в секунду столько запросов, сколько позволяет трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту. Следовательно, вероятность подключения легального пользователя в такой ситуации, при условии переполнения очереди, – в лучшем случае один к миллиону. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако если в РВС любой объект системы может послать запрос от имени (с адреса) другого объекта системы, то, как отмечалось ранее, решить задачу контроля за созданием соединения нельзя. Чтобы обеспечить такую возможность, вводится правило, исходя из которого, в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя, что даст возможность отсеять все пакеты с неверным адресом отправителя. Учитывая это, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.