Взрывной рост популярности сети Internet и связанных с ней коммерческих проектов послужил толчком для развития нового поколения технологий защиты информации в TCP/IP-сетях. Причем, если вплоть до начала 90-х основной задачей технологий защиты в Internet было сохранение ресурсов преимущественно от хакерских атак, то сегодня актуальной становится задача защиты коммерческой информации. Качественно это должна быть совершенно другая защита. Учитывая важность информации, атакующая сторона может позволить себе большие финансовые затраты на взлом защиты, и, следовательно, существенно более высокий уровень приемов - наблюдение трафика, перехват информации, ее криптоанализ, а также разного рода имитоатаки, диверсии и мошенничество.
Проблема защиты информации в Internet
Наивные способы защиты, такие как запрос пароля с последующей его передачей в открытом виде по коммуникационному каналу и простые списки доступа (access list) на серверах и маршрутизаторах, становятся уже сегодня малоэффективными. Что же может быть противопоставлено квалифицированной и технически вооруженной атакующей стороне? Только полноценная, криптографически обеспеченная система защиты.
На рынке достаточно много предложений средств защиты Internet, однако по ряду параметров ни одно из них не может быть признано адекватным задачам защиты информации именно для Сети. Например, достаточно криптостойкой и замечательной по своей идее формирования "паутины доверия" является распространенная система PGP (Pritty good privacy). Однако, поскольку PGP обеспечивает шифрование файлов, она применима только там, где можно обойтись файловым обменом. Защитить, например, приложения on-line при помощи PGP затруднительно. Кроме того, уровень иерархии управления защиты PGP слишком высок: эту систему можно отнести к прикладному или представительскому уровням модели OSI. Стыковка защиты PGP с другими прикладными системами потребует также определенных усилий, если, конечно, вообще окажется осуществимой.
Альтернативу таким "высокоуровневым" системам защиты среди традиционных решений составляют устройства защиты канального и физического уровня - скремблеры и канальные шифраторы. Они "невидимы" с прикладного уровня и, в этом смысле, совместимы со всеми приложениями. Однако такие системы имеют ограниченную совместимость с различным каналообразующим оборудованием и физическими средами передачи данных. Это, как правило, не сетевые устройства, способные распознавать топологию сети и обеспечить связь из конца в конец через многие промежуточные узлы, а "двухточечные" системы, работающие на концах защищаемой линии и, поэтому, вносящие значительную аппаратную избыточность. И, конечно же, на таких устройствах невозможно построить систему защиты в рамках такой сети, как Internet, уже хотя бы потому, что невозможно обеспечить их повсеместное распространение (высокая цена) и всеобщую аппаратную совместимость.
Одной из технологий, предлагающей необходимые для применения в масштабах Internet универсальность и общность, является спецификация SKIP (Simple Key management or Internet Protocol - Простой протокол управления криптоключами в интерсети), существующая на сегодняшний день в виде проекта стандарта Internet (draft RFC, Request For Comments). Эта спецификация была разработана компанией Sun в 1994 году и предложена в качестве стандарта Internet.
Протокол SKIP
Почему же SKIP представляется решением, адекватным задачам защиты информации в масштабах такой сети, как Internet?
Прежде всего потому, что SKIP совместим с IP. Это достигается тем, что заголовок SKIP-пакета является стандартным IP-заголовком, и поэтому защищенный при помощи протокола SKIP пакет будет распространяться и маршрутизоваться стандартными устройствами любой TCP/IP-сети. Отсюда вытекает и аппаратная независимость SKIP. Протокол SKIP имплементируется в IP-стек выше аппаратно-зависимой его части и работает на тех же каналах, на которых работает IP.
Принадлежность SKIP к IP-стеку обеспечивает универсальность и прозрачность этого протокола для приложений: SKIP шифрует IP-пакеты, ничего не зная о приложениях, пользователях или процессах, их формирующих; он обрабатывает весь трафик, не накладывая никаких ограничений на вышележащее программное обеспечение. В свою очередь, приложения никак не "чувствуют" SKIP. SKIP сеансонезависим: для организации защищенного взаимодействия между парой абонентов не требуется никакого дополнительного информационного обмена и передачи по каналам связи какой-либо открытой информации.
В основе SKIP лежит криптография открытых ключей Диффи-Хеллмана [1]. Следует сказать, что пока в рамках такой сети, как Internet, этой криптографической системе нет альтернативы. Дело в том, что эта система предоставляет возможность каждому участнику защищенного взаимодействия обеспечить полную конфиденциальность информации за счет неразглашения собственного секретного ключа и в то же время позволяет взаимодействовать с любым, даже незнакомым партнером путем безопасного обмена с ним открытым ключом. Все другие решения требуют конфиденциального обмена секретным ключом между каждой парой взаимодействующих партнеров. Очевидно, что такой обмен представляет собой трудоемкую и дорогостоящую организационно-техническую задачу. Может быть, это и окажется возможным для частной, относительно малонаселенной сети, но нет никаких шансов на внедрение такой технологии в большой сети.
Наконец, еще одной чертой SKIP является его независимость от системы шифрования. Пользователь может конфигурационно выбирать любой из предлагаемых поставщиком криптоалгоритмов или использовать свой алгоритм шифрования; могут использоваться различные по своей криптостойкости алгоритмы шифрования.
Технические детали спецификации SKIP
Техническая реализация протокола SKIP достаточно подробно рассмотрена в [2,3], а в данной статье попытаемся кратко описать принцип действия и структуры данных последней версии протокола.
Используемая в SKIP система открытых ключей Диффи-Хеллмана представляет собой криптографическую систему с асимметричными ключами, в которой используются различные ключи для шифрования и дешифрования. Каждый узел сети снабжается секретным и открытым ключами. Открытые ключи могут свободно распространяться среди пользователей, заинтересованных в организации защищенного обмена информацией. Узел i, адресующий свой трафик к узлу j, на основе логики открытых ключей вычисляет разделяемый секрет Kij. Однако этот, требующий высокой степени защиты, разделяемый секрет не используется прямо для шифрования данных.
Для шифрования конкретного пакета или их небольшой группы узел i вырабатывает специальный пакетный (сеансовый) ключ Kp, шифрует при помощи этого ключа данные, укладывает их в блок данных SKIP-пакета. Далее, собственно пакетный ключ Kp шифруется на основе другого ключа, вырабатываемого из разделяемого секрета Kij и тоже записывается в пакет. Пакет снабжается SKIP-заголовком, по синтаксису совпадающим с заголовком IP-пакета и отправляется в сеть. Поскольку SKIP-заголовок совпадает с заголовком IP-пакета, все промежуточное оборудование сети стандартным образом маршрутизирует этот пакет до его доставки узлу-получателю j.
Узел j, получив пакет и вычислив разделяемый секрет Kij, дешифрует ключ Kp и, с его помощью, дешифрует весь пакет. Инкапсуляция в SKIP (туннелирование) обеспечивает шифрование (путем инкапсуляции пакетов, подлежащих защите, в SKIP-пакеты) и аутентификацию (достоверную идентификацию источника) информации. Режимы инкапсуляции и шифрования могут применяться как совместно, так и раздельно. Структура пакета, получающегося в результате такой инкапсуляции, приведена ниже:
IP | SKIP | AH | ESP | Inner protocol
IP - заголовок протокола
IP SKIP - заголовок протокола SKIP
AH - аутентификационный заголовок
ESP - заголовок, включающий данные об инкапсулированном протоколе
Inner protocol - пакет инкапсулируемого протокола
Если применяется только режим аутентификации или инкапсуляции, то заголовки AH и ESP, ответственные за аутентификацию и инкапсуляцию могут изыматься из пакета.
Эволюция спецификации SKIP
Текущая версия эскизных материалов IETF по стандарту SKIP от 21 декабря 1995 года [4] имеет ряд отличий от первой версии, опубликованной 15 мая 1994 года. В результате деятельности рабочей группы IETF появился целый набор проектов стандартов, превращающих SKIP из отдельного протокола в действительно работающее средство поддержки шифрования и аутентификации данных в IP-сетях. Кроме этого, произошли некоторые изменения в самом протоколе SKIP. Рассмотрим наиболее существенные из них.
В первой версии SKIP для повышения криптостойкости разделяемого секрета - вычисляемого парного ключа - предлагалась следующая логика. При шифровании данных каждого пакета или их группы вырабатывался случайный пакетный или сеансовый ключ, Kp. Далее, уже непосредственно ключ Kp шифровался при помощи вычисляемого парного ключа - долговременного разделяемого секрета Kij. Такое решение обеспечивало два преимущества:
- в случае компрометации пакетного ключа риску подвергается только относительно малая часть трафика, зашифрованная при помощи этого ключа;
- обеспечивалась дополнительная защита разделяемого секрета, поскольку он использовался для шифрования относительно малой части передаваемого трафика и накопить статистику, необходимую для проведения криптоатаки на этот ключ представлялось затруднительным.
В последующих реализациях спецификации SKIP были приняты дополнительные меры для защиты разделяемого секрета. Повышение криптостойкости протокола при атаках на пакетный ключ Kp достигнуто за счет включения в заголовок пакета нового параметра (n), который используется для вычисления ключа (Kijn), применяемого при шифровании сеансового ключа. Основная идея заключается в том, что для получения ключа Kp используется не сам разделяемый секрет Kij, а результат применения хэш-функции к выражению, составленному из разделяемого ключа Kij и параметра n. При этом n никогда не уменьшается, а только увеличивается. Правила для работы с n отнесены на усмотрение разработчика, однако для обеспечения совместимости версий предлагается считать, что n - это время в часах, отсчитанное от 00 час. 00 мин. 01.01.95.
Проблема синхронизации часов на защищаемых системах решается достаточно просто - если параметр n отличается более, чем на 1, что составляет разбежку по времени свыше одного часа, то пакет выбрасывается, поскольку потенциально может быть инструментом для выполнения имитоатаки с повторной передачей (replay attack). Далее, пожалуй, наиболее существенной из эволюций спецификации SKIP является приведение протокола SKIP к единообразному виду с точки зрения архитектуры протоколов семейства IP. Это выразилось, в первую очередь, в некотором упорядочении инкапсуляции протоколов, выполненной в соответствии со стандартом RFC 1827.
В заголовке SKIP-пакета появилось поле NEXT HEADER, которое указывает протокол, содержащийся внутри данного SKIP-пакета. Таким образом достигается привычная картина последовательной инкапсуляции пакетов один в другой.
Аналогично привычной цепочке Ethernet packet -> IP packet -> TCP packet при работе по протоколу SKIP мы получаем IP packet -> SKIP packet -> ESP packet -> TCP packet. Еще один результат появления в заголовке информации о следующем протоколе заключается в том, что теперь протокол SKIP отвечает только за передачу сеансового ключа и номера алгоритма для использования внутри инкапсулируемого протокола ESP. В качестве протокола ESP может применяться любой протокол. SKIP не накладывает никаких ограничений на конкретную реализацию ESP.
Дополнительные спецификации
Как уже отмечалось, в рабочей группе IETF по безопасности находятся на рассмотрении еще несколько рабочих материалов, связанных с протоколом SKIP. Проект протокола SKIP базируется на открытых ключах, поэтому естественна озабоченность разработчиков проблемой подтверждения авторства открытого ключа. В качестве одного из возможных решений предлагается использовать процедуру, описанную в рекомендации X.509. Специальный документ выпущен авторами протокола SKIP для описания особенностей применимости рекомендации X.509 для целей SKIP [7]. Однако кроме рекомендации X.509 рассматриваются и другие возможные представления сертификатов [5].
Другой интересный проект протокола, разрабатываемый совместно с основной спецификацией SKIP, - это процедура обмена информацией о поддерживаемых алгоритмах шифрования для данного узла [6]. Важность стандартизации этой процедуры обусловлена потенциальной возможностью работы двух узлов на различных алгоритмах - невозможностью понимать друг друга в стандартном режиме. Предлагаемый протокол базируется на расширении известного протокола ICMP (Internet Control Message Protocol, RFC 792). При использовании этого протокола для защиты от приема неавторизованной информации обязательным требованием является наличие авторизации в SKIP-пакете, в котором передается ICMP-пакет. В случае несовпадения подписи и содержимого данный пакет отбраковывается.
Опуская ряд идейно более мелких коррекций спецификации, следует отметить проработку в новой спецификации вопросов совместимости SKIP со следующей версией протокола IP v6.
Эволюции линии продуктов SKIP
Хотя SKIP пока не является стандартом Internet, с этим протоколом, на правах открытого индустриального стандарта, начали работать, по меньшей мере, три организации: компания Sun, Swiss Federal Institute of Technology и АО ЭЛВИС+. Уже в июле 1995 года на сессии IETF этими организациями были представлены реализации протоколов и проверена их совместимость. Тогда эти программы были еще далеки от состояния, которое можно было бы охарактеризовать как "программный продукт". На сегодняшний день картина изменилась, и мы имеем масштабируемый ряд продуктов защиты информации на основе спецификации SKIP. В разработке этого ряда приняли участие, по существу, все три из упомянутых организаций - каждая в соответствии со своей специализацией и внутренней спецификой.
Компания Sun Microsystems использовала SKIP как базовое средство защиты трафика в устройстве SunScreen [2,3], получившее признание как продукт 1996 года по категории firewall в журнале LAN Magazine. SunScreen анонсирован в мае 1995 года и с тех пор находится в эксплуатации, правда, только на территории США. Практически начиная с самого анонса продукта SunScreen подпадал под федеральные экспортные ограничения США для продуктов защиты информации. Постепенно эти ограничения удалось преодолеть, сначала путем получения ограниченной экспортной лицензии для финансовых организаций, затем последовало объявление о пересмотре цен на продукт и снятии экспортных ограничений на SunScreen SPF 100 G. Кроме устройства SunScreen Sun предлагает программную реализацию SKIP для ОС Solaris.
В Швейцарии выпущена public domain версия протокола SKIP. Разработка продуктных предложений, видимо, вследствие некоммерческой ориентации Swiss Federal Institute of Technology, не анонсировалась.
Компания ЭЛВИС+, ориентируясь на специфику российского рынка, пошла по пути разработки недорогих программных реализаций SKIP для распространенных платформ UNIX и Windows. Помимо деления на платформы эта компания предлагает версии продукта с различной функциональностью: от простой программы для защиты трафика оконечного устройства, работающего с одним выделенным сервером, до полнофункционального продукта защиты станции в корпоративной сети, который обеспечивает учет топологии сети и индивидуальную настройку дисциплины взаимодействия с различными ее узлами. Кроме того, было разработано и предлагается сегодня в виде готового продукта устройство для коллективной защиты локальных сетей SKIPbridge. Это - аппаратно-программный комплекс на основе станции SPARCserver 5, который устанавливается на интерфейсе LAN/WAN и обеспечивает решение двух задач: SKIP-защиту входящего и исходящего трафика и реализацию заданной политики безопасности на интерфейсе LAN/WAN путем расширенной пакетной фильтрации. На текущий момент все продукты компаний ЭЛВИС+ и Sun Microsystems прошли тестирование на совместимость, и можно говорить о едином, широко масштабируемом по функциональности и стоимости, ряде продуктов.
Проблемы внедрения технологии SKIP
Проблемы внедрения технологии SKIP не исчерпываются разработкой программных продуктов, просто реализующих спецификацию этого протокола. Вообразите себе, что вы приобрели некоторый продукт защиты информации, например программную реализацию SKIP. Сразу же становится ясно, что для работы этого явно недостаточно - вам нужно обмениваться информацией с партнерами. Вы не можете начать работать с ними, даже если у них имеется такое же средство защиты - нужно получить открытые ключи. Это можно сделать любым удобным способом, например получить их в открытом виде по сети, но, как уже упоминалось, нужно обеспечить имитостойкость этих открытых ключей - снабдить их электронной подписью некоторой заслуживающей доверия стороны. Найти такого, заслуживающего доверия посредника и организовать его деятельность - задача достаточно сложная, и ее решение может сильно различаться для открытой сети типа Internet и для корпоративной сети.
Проблема сертификационного центра в Internet. Трудность построения сертификационного центра в Internet определяется следующими факторами:
1) неясно, кому в Internet сможет доверять массовый пользователь;
2) если такая доверительная сторона найдена, то нужно решить проблему доступа к ее ресурсам: поток запросов сертификатов открытых ключей к этому источнику может быть столь интенсивен, что невозможно будет найти достаточные для его работы канальные и вычислительные ресурсы.
Предпосылкой для решения проблемы поиска стороны, заслуживающей доверия, является принципиальная возможность генерации секретного ключа самим пользователем и представления для сертификации только открытого ключа. В этом случае конфиденциальность информации пользователя обеспечивается тем, что он никому не сообщает свой секретный ключ, и все сводится к чисто техническим трудностям, связанным с процессом передачи открытого ключа на сертификацию и с распространением сертификатов открытых ключей.
Для решения второй - ресурсной - задачи предложено решение, в котором администрация, ведающая распределением сертификатов открытых ключей, будет иметь распределенную иерархическую древовидную архитектуру, подобную структуре службы DNS (Domain Name System - системе именования доменов), работающей в Internet. Следует, однако, сказать, что полномасштабное внедрение такого решения можно ожидать не ранее, чем SKIP будет утвержден в качестве стандарта. Тем не менее Sun Microsystems уже сейчас предлагает службу распределения сертификатов открытых ключей для покупателей SKIP-продуктов. При этом, однако, еще не создана сложная распределенная структура для поддержки сертификатов. Генерацией секретных ключей для своих пользователей занимается пока также компания Sun.
Проблема сертификационного центра корпоративной сети. В корпоративной сети проблема, с одной стороны, выглядит проще: любая корпоративная сеть в тысячи раз менее "населена", чем Internet, поэтому служба распределения сертификатов будет значительно менее ресурсоемкой и может иметь простую структуру, основанную, в простейшем случае, на одном сервере - лучше, конечно, обеспечить резервирование и распределить эту функцию между несколькими серверами. Кроме того, в корпоративной сети легче найти сторону, заслуживающую доверия, например администрацию безопасности этой сети. С другой стороны, защита информации в корпоративной сети, как правило, должна осуществляться с учетом ряда дополнительных требований и ограничений, вытекающих из регламента безопасности предприятия-владельца сети. Прежде всего, это требования по дисциплине работы с криптоключами, требования по оперативности замены скомпрометированных ключей и административные ограничения типа разрешений и запретов на взаимодействия отдельных пользователей и подразделений.
Ориентируясь на запросы корпоративных заказчиков, компания ЭЛВИС+ произвела разработку ряда полуфабрикатов и дополнительных, не представленных в спецификации SKIP, технических средств. На состоянии "полуфабрикат" для ряда продуктов, предназначенных для службы распределения ключей, приходится остановиться, поскольку невозможно подготовить единое решение, в равной степени удовлетворительное для всех организаций. Что касается технических новаций, то к ним относится административное конфигурирование локальных SKIP-программ, устанавливающее условия взаимодействия одних хостов с другими.
Станет ли SKIP стандартом Internet?
Этот вопрос не представляется не праздным. С одной стороны, SKIP - уникальная технология, выглядящая вполне адекватной задачам защиты трафика в сети любого масштаба, в том числе и Internet. До последнего времени решения, обладающего общностью и мощностью SKIP, просто не существовало. Это вселяет надежду на то, что может стать SKIP стандартом для решения задач информационной безопасности сетей. С другой стороны, задача выработки такого стандарта представляется настолько многоплановой и технически сложной, что прогнозировать срок завершения работы над этим стандартом сейчас не невозможно. Что, впрочем, не мешает пользоваться существующей открытой индустриальной спецификацией SKIP.
Информация о SKIP:Web-сервер Internet Commerce Group - подразделения Sun Microsystems, занимающегося разработкой спецификации SKIP и SKIP-продуктов http://www.incog.com, http://skip.incog.com WWW-сервер АО ЭЛВИС+ http://www.elvis.ru FTP-сервер Swiss Federal Institute of Technology ftp://www.tik.ee.ethz.ch/pub/packages/skip WWW-сервер Internet Security Group IETF http://www.ietf.cnri.reston.va.us |
Литература
[1]. W.Diffie, M.E.Hellmann, "New Directions in Cryptography", IEEE Transactions on Information Theory, v.IT-22, n.6, Nov 1976, pp.644- 654.
[2]. Вопилов А.В., Галицкий А.В., Рябко С.Д., Защита информации в Internet - Банковские технологии, N7, 1995, стр. 37-42.
[3]. Вопилов А.В., Галицкий А.В., Рябко С.Д., Безопасность в Internet: проблема решена? - Сети, N7, 1995, стр. 118-123.
[4]. Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management For Internet Protocols (SKIP)"
[5]. Aziz, A., Markson, T., Prafullchandra, H., "Certificate Discovery Protocol", (I-D draft-ietf-ipsec-cdp-00.txt), Work in Progress.
[6]. Aziz, A., Markson, T., Prafullchandra, H., "SKIP Algorithm Discovery Protocol", (I-D draft-ietf-ipsec-skip-adp-00.txt), Work in Progress.
[7]. Aziz, A., Markson, T., Prafullchandra, H., "X.509 Encoding of Diffie- Hellman Public Value", (I-D draft-ietf-ipsec-skip-x509-00.txt), Work in Progress.
