функция

В январе 1977 году правительство Соединенных Штатов приняло продукцион­ный шифр, разработанный фирмой IBM, в качестве официального стандарта для несекретных сведений. Этот шифр, получивший название DES (Data Encryption Standard — стандарт шифрования данных), получил широкое распространение в промышленности для защиты информации. В своем исходном виде он уже боль­ше не является надежным, но в модифицированном виде все еще полезен. Сейчас мы объясним принципы его работы.

Схема DES-шифра показана на рис. 8.6, а. Открытый текст шифруется блоками по 64 бита, в результате чего на выходе получаются 64-битные блоки зашифро­ванного текста. Алгоритм, использующий 56-разрядный ключ, состоит из 19 от­дельных этапов. На первом этапе выполняется независимая перестановка 64 раз­рядов открытого текста. Последний представляет собой обратную перестановку. Предпоследний этап меняет местами левые и правые 32 разряда. Остальные 16 эта­пов функционально идентичны, но управляются разными функциями входного ключа. Алгоритм был разработан так, чтобы дешифрация выполнялась тем же ключом, что и шифрование. Это обеспечивает соответствие алгоритма принципу симметричных ключей. Этапы при расшифровке просто выполняются в обрат­ном порядке.

Операция, выполняемая на одном из промежуточных этапов, показана на рис. 8.6, 6. На каждом этапе из двух порций по 32 разряда на входе формируются две порции по 32 разряда на выходе. Правая половина входа просто копируется в левые разряды выхода. Правые 32 выходных разряда представляют собой сум­му по модулю 2 левой части входа и функции правой части входа и ключа данно­го этапа Kv Вся сложность шифра заключается в этой функции.

Функция состоит из четырех последовательно выполняемых шагов. Сначала из 32 разрядов правой части Rhl с помощью фиксированной перестановки и дуб­лирования формируется 48-разрядное число Е. На втором шаге число Е и ключ Kt складываются по модулю 2. Затем выход разделяется на восемь групп по шесть разрядов, каждая из которых преобразуется независимым S-блоком в 4-раз­рядные группы. Наконец, эти 8 • 4 разряда пропускаются через Р-блок.

На каждом из 16 этапов используются различные функции исходного ключа. Перед началом работы алгоритма к ключу применяется 56-разрядная переста­новка. Перед каждым этапом ключ разделяется на две группы по 28 разрядов, каж­
дая из которых вращается влево на число разрядов, зависящее от номера этапа. Ключ К{ получается из результата этой операции при помощи еще одной пере­становки 56 разрядов. На каждом этапе из 56 разрядов ключа выбираются 48 раз­рядов, которые также переставляются местами.

 

L,-

64-разрядный открытый текст j j | У Ц У У

1-1

illlllll UUUU

Стандарт шифрования данных DES" title="Стандарт шифрования данных DES" border=0 width=194 height=197 src="http://s55.radikal.ru/i147/1007/25/e1da771fc25d.png">

ы *

Начальная перестановка

У V У У У У У

Итерация 1

У У У У У У У У

Итерация 2

Итерация 16

У У У X У У

Перестановка 32 битов

у у у у у у уу

Инверсная перестановка

 

ttfттттУ

32 бита L,

32 бита Я/

64-разрядный зашифрованный текст а

 

Рис. 8.6. Стандарт шифрования данных DES: общий вид (а); детализация одного из этапов (б)

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

Стандарт шифрования данных DES был полон противоречий с самого мо­мента его создания. Он основывался на шифре Люцифер (Lucifer), разработан­ном и запатентованном корпорацией IBM, с той разницей, что IBM использова­ла 128-разрядный, а не 56-разрядный ключ. Когда федеральное правительство

Соединенных Штатов пожелало стандартизировать какой-то шифр для несек­ретного применения, оно «пригласило» IBM на «обсуждение» этого вопроса с Агентством национальной безопасности, NSA (National Security Agency), являю­щимся самым крупным в мире работодателем в области математики и крипто­анализа. Агентство национальной безопасности США настолько секретно, что существует даже такая популярная шутка:

Вопрос: Что означает аббревиатура NSA?

Ответ: No Such Agency — такого агентства нет.

После этих обсуждений корпорация IBM уменьшила длину ключа со 128 до 56 бит и решила держать в секрете процедуру разработки стандарта DES. Мно­гие полагали, что длина ключа была уменьшена, чтобы гарантировать, что NSA сможет взломать DES, но организациям с более низким финансированием это будет не по силам. Вероятно, цель засекречивания проекта состояла в сокрытии потайного хода, позволяющего Агентству национальной безопасности еще легче взламывать шифр DES. Когда сотрудник этого управления предложил Институ­ту инженеров по электротехнике и электронике (IEEE) отменить планирую­щуюся конференцию по криптографии, ощущения комфорта это не прибавило. Агентство национальной безопасности всегда препятствовало всему.

В 1977 году ученые Стэнфордского университета, занимающиеся исследова­ниями в области криптографии, Диффи (Diffie) и Хеллман (Hellman), разрабо­тали машину для взлома кода DES и оценили стоимость ее создания в 20 млн долларов. По небольшому участку открытого текста и соответствующего ему за­шифрованному тексту эта машина путем полного перебора 256 вариантов за один день могла найти 56-разрядный ключ. На сегодняшний день такая машина могла бы стоить около 1 млн долларов.

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

Далее, какая организация будет заведовать Управлением? Довольно трудно представить себе какую-либо законную структуру с большим кредитом доверия мирового масштаба. В некоторых странах предпочтительно, чтобы это было ка- кое-нибудь правительственное учреждение, а где-то — наоборот, чтобы это было чем угодно, но не правительством.

По этим причинам был разработан альтернативный способ сертификации открытых ключей. Он известен под общим названием PKI (Public Key Infra­structure — инфраструктура систем с открытыми ключами). В этом разделе мы
рассмотрим только общие принципы действия PKI, поскольку было внесено мно­жество предложений по ее модификации и некоторые детали могут со временем измениться.

ЦУ

РО 2

УС принято. Открытый ключ: 6384AF863B... Подпись РО 2

а                                                                                                            б Рис. 8.22. Иерархия PKI (а); цепочка сертификатов (б) Итак, наш PKI работает следующим образом. Допустим, Алисе нужен откры­тый ключ Боба, чтобы она могла с ним пообщаться. Она ищет и находит содер­жащий его сертификат, подписанный УС 5. Однако Алиса никогда ничего не слышала про УС 5. Этим «Управлением» может оказаться, на самом деле, деся­тилетняя дочка Боба. Алиса может отправиться в УС 5 и попросить подтвердить легитимность. Управление в ответ может показать сертификат, полученный от

PKI состоит из множества компонентов, среди которых Управления сертифи­кации, сами сертификаты, а также каталоги. Инфраструктура систем с открытыми ключами предоставляет возможность структурной организации этих компонен­тов и определяет стандарты, касающиеся различных документов и протоколов. Одним из простейших видов PKI является иерархия Управлений, представлен­ная на рис. 8.22. На рисунке представлены три уровня, однако реально их может быть как больше, так и меньше. Управление сертификации верхнего уровня (root) мы будем называть Центральным управлением (ЦУ). Центральное управление сертифицирует управления второго уровня — назовем их Региональными отде­лами (РО), — так как они могут обслуживать некоторый географический регион, например, страну или континент. Этот термин не стандартизован. Названия для уровней иерархии вообще не оговариваются стандартом. Региональные отделы, в свою очередь, занимаются легализацией реальных Управлений сертификации (УС), эмитирующих сертификаты стандарта Х.509 для физических и юриди­ческих лиц. При легализации Центральным управлением нового Регионального отдела последнему выдается сертификат, подтверждающий его признание. Он содержит открытый ключ нового РО и подпись ЦУ. Аналогичным образом РО взаимодействуют с Управлениями сертификации: выдают и подписывают серти­фикаты, содержащие открытые ключи УС и признающие легальность деятель­ности.

РО 2 принят. Открытый ключ: 47383АЕ349...

Подпись ЦУ

РО 2 и содержащий открытый ключ УС 5. Теперь, вооружившись открытым ключом УС 5, Алиса может удостовериться в том, что сертификат Боба действи­тельно подписан УС 5, а значит, является легальным.

Если только РО 2 не является двенадцатилетним сыном Боба. Если Алисе вдруг придет в голову такая мысль, она может запросить подтверждение леги­тимности РО 2. Ответом будет служить сертификат, подписанный Центральным управлением и содержащий открытый ключ РО 2. Вот теперь Алиса может не сомневаться, что она получила открытый ключ Боба, а не кого-то другого.

А если Алиса хочет узнать открытый ключ ЦУ? Как это сделать? Загадка. Предполагается, что открытый ключ ЦУ знают все. Например, он может быть «зашит» внутрь ее браузера.

Но наш Боб — добряк, он не хочет доставлять Алисе лишние хлопоты. Он по­нимает, что она захочет проверить легитимность УС 5 и РО 2, поэтому он сам собирает соответствующие сертификаты и отправляет их ей вместе со своим. Те­перь, зная открытый ключ ЦУ, Алиса может проверить по цепочке все интере­сующие ее организации. Ей не придется никого беспокоить для подтверждения. Поскольку все сертификаты подписаны, она может запросто уличить любые по­пытки подлога. Цепочка сертификатов, восходящая к ЦУ, иногда называется до­верительной цепочкой или путем сертификата. Описанный метод широко при­меняется на практике.

Конечно, остается проблема определения владельца ЦУ. Следует иметь не од­но Центральное управление, а несколько, причем связать с каждым из них свою иерархию региональных отделов и управлений сертификации. На самом деле, в современные браузеры действительно «зашиваются» открытые ключи более 100 центральных управлений, иногда называемые доверительными якорями. Как видите, можно избежать проблемы одного всемирного учреждения, занимающе­гося сертификацией.

Однако встает вопрос, какие доверительные якоря производители браузеров могут считать надежными, а какие — нет. Все, на самом деле, сводится к тому, насколько конечный пользователь доверяет разработчику браузера, насколько он уверен в том, что решения генерируются грамотно и доверительные якоря не принимаются от всех желающих за умеренную плату. Большинство браузеров обеспечивают возможность проверки ключей ЦУ (обычно это делается с помо­щью сертификатов, подписанных им) и удаления подозрительных ключей.

Каталоги

Инфраструктура систем с открытыми ключами должна решать еще один вопрос. Он касается места хранения сертификатов (и цепочек, ведущих к какому-нибудь доверительному якорю). Можно заставить всех пользователей хранить свои сер­тификаты у себя. Это безопасно (так как невозможно подделать подписанные сертификаты незаметно), но не слишком удобно. В качестве каталога для серти­фикатов было предложено использовать DNS. Прежде чем соединиться с Бобом, Алисе, видимо, все равно придется узнать с помощью службы имен доменов (DNS) его IP-адрес. Так почему бы не заставить DNS возвращать вместе с 1Р-ад- ресом всю цепочку сертификатов?

Кому-то это кажется выходом из положения, однако некоторые считают, что лучше иметь специализированные серверы с каталогами для хранения серти­фикатов Х.509. Такие каталоги могли бы с помощью имен Х.500 обеспечивать возможность поиска. Например, теоретически можно представить себе услугу сер­вера каталогов, позволяющую получать ответы на запросы типа «Дайте мне пол­ный список всех людей по имени Алиса, работающих в отделе продаж в любом месте США или Канады». Хранить такую информацию можно, например, при помощи LDAP.

Аннулирование

Реальный мир полон разного рода сертификатов, среди которых, например, пас­порта, водительские удостоверения. Иногда эти сертификаты необходимо анну­лировать (например, водительское удостоверение надо аннулировать за езду в нетрезвом состоянии). Та же проблема возникает и в мире цифровых технологий: лицо, предоставившее сертификат, может отозвать его за нарушение противопо­ложной стороной каких-либо условий. Это необходимо делать и тогда, когда за­крытый ключ, в сущности, перестал быть защищенным или, что еще хуже, ключ УС потерял кредит доверия. Таким образом, инфраструктура систем с открыты­ми ключами должна как-то обеспечивать процедуру аннулирования.

Первым шагом в этом направлении является принуждение всех УС к перио­дическому выпуску списка аннулированных сертификатов (CRL — Certificate Revocation List). В нем перечисляются порядковые номера всех аннулированных сертификатов. Поскольку в сертификатах содержится дата окончания срока год­ности, в CRL следует включать номера только тех из них, срок годности которых еще не истек. По истечении срока годности сертификаты перестают быть дейст­вительными автоматически, поэтому нужно различать случаи аннулирования «по старости» и по другим причинам. В любом случае их использование необхо­димо запрещать.

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

Еще больше усложняет ситуацию то, что аннулированный сертификат иногда требуется восстанавливать. Например, если причиной отзыва была неуплата ка­ких-нибудь взносов, после внесения необходимой суммы не остается никаких причин, которые не позволяли бы восстановить сертификат. Обработка ситуа­ций аннулирования и восстановления сводят на нет такое ценное свойство сер­тификатов, как возможность их использования без помощи УС.

Где хранить списки аннулированных сертификатов? Было бы здорово хра­нить их там же, где и сами сертификаты. Одна из стратегий подразумевает, что

УС периодически выпускает «черные» списки и заставляет вносить обновления в каталоги (удаляя отозванные сертификаты). Если для хранения сертификатов каталоги не используются, можно кэшировать их в разных удобных местах в се­ти. Поскольку «черный» список сам по себе является подписанным документом, любые попытки подлога тотчас будут замечены.

Если сертификаты имеют большие сроки годности, списки аннулированных сертификатов также будут довольно длинными. Например, количество отозван­ных кредитных карточек со сроком годности 5 лет будет гораздо больше списка отозванных трехмесячных карточек. Стандартным способом борьбы с длинными списками является довольно редкий выпуск самих списков и частый — обновле­ний к ним. Кроме всего прочего, это помогает снизить необходимую для распро­странения списков пропускную способность.

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

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

Хосты могут уменьшать трафик, изменяя свои стратегические параметры, на­пример размер окна. Обычно первый сдерживающий пакет уменьшает скорость передачи данных в два раза, следующий — в четыре и т. д. Увеличения скорости производятся меньшими приращениями, чтобы избежать слишком быстрого по­вторения перегрузки.

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

В качестве варианта может измеряться длина очереди или объем свободной памяти маршрутизатора. При этом можно использовать ту же экспоненциаль­ную весовую функцию, что и для и.