Как обезопасить беспроводные технологии
Антон Мальцев
Любые новые технологии — «палка о двух концах», иными словами, любая новая технология приносит ее обладателю проблемы, число которых пропорционально дивидендам, полученным с помощью использования этой новой технологии. В любом случае стоит задуматься о рисках, которые таят в себе так полюбившиеся многим беспроводные технологии, и о том, как их минимизировать.
В одном из номеров журнала «Кейс», издаваемого компанией «КОРУС Консалтинг», упоминалось об использовании беспроводной связи в крупном гипермаркете, где была внедрена ERP-система Axapta Retail. Использование карманных персональных компьютеров (КПК), оснащенных возможностью беспроводной связи, позволило расширить функциональные возможности этой системы. У работников магазина значительно сократились затраты времени на стандартные процедуры — приемку товара, инвентаризацию и многое другое. Большинство данных, например для бухгалтерии, они могут передавать прямо с собственного рабочего места. С учетом площади гипермаркета – около 10 000 кв. м – это сэкономило им массу времени.
Теперь смоделируем ситуацию: нарушителю удается продублировать ПО с настройками КПК, входящего в систему гипермаркета, на своем КПК. Нарушитель авторизуется в системе под идентификатором КПК-оригинала. После этого он может выполнять все те же действия, что и продавец. Степень ущерба для компании может стать огромной.
Чтобы избежать такой ситуации, нужно правильно оценивать риски, которые таят в себе методы аутентификации пользователей в беспроводных системах. Как и в обычных сетях, в Wi-Fi используется защита на уровне IP, для чего предназначен безопасный протокол передачи данных IPSEC. Это основа безопасности беспроводных сетей и «подводная часть айсберга», однако не стоит забывать про его верхнюю часть – аутентификацию сервера и клиента на более высоком уровне. В последнее время широко используется и протокол аутентификации на базе открытых ключей – EAP-TLS (а также его модификация при туннелировании – EAP-TTLS), он-то и служит защитой клиента и сервера от нарушителя. Этот протокол надежно защищает передаваемые данные, однако и в нем можно разглядеть недостатки: например, отсутствует возможность делегирования прав доступа от одного клиента другому.
Для чего протоколу такая «гибкость»?
Возьмем для примера проект сети крупных гипермаркетов. Допустим, КПК с соответствующим ПО есть у каждого сотрудника компании: от менеджера до продавца. Каждый работник выполняет свои функции, соответственно, менеджер назначает права (функции) своей команде работников. Для этого необходимо построить схему делегирования прав, которую можно совместить с безопасным протоколом EAP-TLS.
На мой взгляд, сегодня выбрать способ авторизации, устраивающий владельца беспроводной сети, позволяет набор протоколов стандарта 802.х и, в частности, протокол EAP-TLS, построенный на базе доверенных сертификатов (CA). В общих чертах, эта схема работает так: клиент отправляет серверу доступа случайное число с. Затем сервер доступа отправляет собственный сертификат cert(AS) и другое случайное значение s. В случае, если серверу доступа необходимо аутентифицировать клиента, он отправляет сообщение с запросом, уведомляя клиента, что ему требуется отправить свой сертификат и цифровую подпись в ответе. Получив сертификат от AS, клиент проверяет его достоверность с помощью открытого ключа СА. Если он действующий, клиент выбирает другое случайное значение p, зашифровывает его с помощью открытого ключа сервера и отправляет его обратно. Это значение необходимо для создания сессионных ключей. Если в сети выполняется обоюдная аутентификация, клиент отправляет сертификат cert(клиент) вместе с сообщением доверенного сертификата. Отправитель содержит открытый ключ клиента и аутентифицирует клиента, определяя, известен ли ему секретный ключ, который соотносится с открытым ключом в сертификате. По завершении handshake сервер отправляет сообщение TLS-finished. Клиент аутентифицирует сервер, проверяя, совпадает ли отправленное сервером сообщение с вычисленным клиентом.
Главное достоинство EAS-TLS — поддержка взаимной аутентификации и устойчивость ко многим типам атак. К недостаткам я бы отнес невозможность делегирования прав доступа к сети другим пользователям. И, что немаловажно, данный протокол не поддерживает аутентификацию клиентов, которые не имеют сертификата, подписанного CA и доверенного серверу доступа.
Наиболее гибким я бы назвал сочетание протокола EAP-TLS и функции делегирования прав Greenpass. Предположим, в схеме будут участвовать два субъекта – гость и делегатор (субъект, передающий права). Поскольку протокол EAP-LTS построен на базе открытых ключей, гостю сперва необходимо будет передать открытый ключ делегатору, тот же в ответ отправляет цепочку сертификатов (после того, как подпишет их). Процесс делегирования происходит следующим образом:
Гость предоставляет значение открытого ключа, обернутое в сертификат Х.509, модулю аутентификации, который в дальнейшем хранит их в Кэше.
Приложение со стороны Гостя генерирует оригинальное изображение, построенное на базе фракталов из открытого ключа Гостя, и отправляет их обратно на приложение Гостя, где они отображаются на экране.
Делегатор открывает своё веб-приложение и получает открытый ключ Гостя из Кэша. веб-приложение подсоединяется к Апплету делегирования в веб-браузере делегатора и отправляет ему открытый ключ гостя.
Апплет делегирования отображает оригинальное изображение Гостя, делегатору необходимо сравнить его с тем, которое отображалось на стороне Гостя.
Если сравниваемые изображения совпадают, то Апплет делегирования создаст и подпишет SPKI сертификат, который несет в себе привилегии доступа в локальную сеть через Wi-Fi. Затем он отправит этот сертификат обратно веб-приложению делегатора, а затем направит его в Кэш.
Когда Гость обновит веб-страницу по делегированию прав Greenpass, приложение опознает в нем ожидающего авторизации на удостоверение личности, извлечет цепочку сертификатов из Кэша авторизации и отправит ее в хранилище сертификатов.
Прямая передача ключей или сертификатов по сети или выделенному каналу имеет много преимуществ. В качестве альтернативного варианта обмен информацией может происходить посредством инфракрасного порта, однако данное решение требует установки дополнительного ПО. Для передачи ключей и сертификатов лучше выбрать веб-сервер, который будет являться связующим звеном между гостем и делегатором. Такое решение имеет многочисленные преимущества:
Веб-сервер может опознать открытый ключ гостя с помощью аутентификации SSL. SSL либо TLS позволяют серверу получить открытый ключ клиента и проверить его согласно закрытому ключу, даже если доверительные отношения с создателем клиентского сертификата Х.509 отсутствуют.
В большинстве случаев пользователю не требуется экспортировать сертификат EAP-TLS в файл. Для SSL-аутентификации большинство клиентов ОС (Windows, FreeBsd), наряду со стандартными веб-браузерами (Internet Explorer, Opera), использует стандартные хранилища ключей, которые доступны EAP-TLS и другим клиентам.
Веб-браузеры, поддерживающие SSL-аутентификацию клиента, обычно позволяют генерировать и регистрировать сертификаты, которые, в свою очередь, обеспечивают подходящий способ получения этих материалов для Гостя.
Вкратце, протокол аутентификации EAP-TLS – это именно тот путь, который обеспечивает надежность беспроводных клиента и сервера с сохранением гибкости делегирования прав. Поэтому, какую бы роль ни играли беспроводные технологии в вашем бизнесе, у вас всегда есть возможность избежать неприятных подводных камней, связанных с новыми рисками.
|
