Понятие информационной системы

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

Эти два правила комбинируются в следующее требование защиты. Если личность пользователя подтверждена и пользователь локально известен в данном домене, то в этом домене он может считаться прошедшим аутентификацию. То есть Globus полагает, что при получении доступа к ресурсам удаленного домена общесистемным средствам аутентификации достаточно установить тот факт, что пользователь уже аутентифицирован в этом удаленном домене (если он там известен). Дополнительная аутентификация в этом удаленном домене уже не нужна.

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

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

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

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

Для этой цели вводятся два типа представителей. Заместитель пользователя (user proxy) представляет собой процесс, которому дано право действовать от лица пользователя в течение ограниченного времени. Ресурсы представляются в виде заместителей ресурсов. Заместитель ресурса (resource proxy) -- это процесс, работающий в определенном домене и используемый для трансляции глобальных операций с ресурсами в локальные операции, удовлетворяющие требованиям локальных правил защиты. Так, например, заместитель пользователя обычно применяется для связи с заместителем ресурса в процессе доступа к необходимым ресурсам.

Архитектура защиты системы Globus в основном состоит из различных сущностей, таких как пользователи, заместители пользователей, заместители ресурсов и процессы общего назначения. Эти сущности размещены в доменах и взаимодействуют друг с другом. В частности, архитектура защиты определяет четыре различных протокола взаимодействия, показанных на рис. 8.1.

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

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

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

Четвертый и последний протокол в архитектуре защиты Globus -- это способ, посредством которого пользователь может объявить о себе в удаленном домене. Если считать, что пользователь имеет учетную запись в конкретном домене, нам необходимо, чтобы системный набор прав, представленный заместителем пользователя, автоматически конвертировался в права для этого домена. Протокол предписывает, как зарегистрировать отображение глобальных прав пользователя в локальные права в локальной таблице отображений домена.

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

Вопросы разработки

В распределенную систему, да впрочем, и в любую компьютерную систему, должны быть встроены механизмы защиты, при помощи которых можно будет реализовать различные правила защиты. При реализации служб защиты общего назначения следует учитывать несколько моментов. Ниже мы рассмотрим три таких важных момента: фокус управления, многоуровневую организацию механизмов защиты и простоту.

Фокус управления

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

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

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

Многоуровневая организация механизмов защиты

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

В сущности, на рисунке службы общего назначения отделены от коммуникационных служб. Это разделение очень важно для понимания распределения по уровням механизмов защиты распределенных систем и, в частности, для представления о доверии. Разница между доверием и защитой очень важна. Система может быть или не быть защищенной, особенно принимая во внимание различные случайности, но мнение клиента о том, что система защищена -- это вопрос доверия. Уровень, на котором размещается механизм защиты, зависит от доверия клиента к защите служб этого уровня.

В качестве примера рассмотрим организацию, расположенную в нескольких географически удаленных друг от друга местах, которые соединены коммуникационной службой, такой как коммутируемая мультимегабитная служба данных (Switched Multi-megabit Data Service, SMDS). Сеть SMDS можно рассматривать как базовую сеть канального уровня, соединяющую локальные сети, в том числе и разнесенные в пространстве, как это показано на рис. 8.4.

Защиту можно обеспечить путем установки шифрующего устройства на каждом маршрутизаторе SMDS, как показано на рисунке. Эти устройства автоматически зашифровывают и расшифровывают пересылаемые пакеты, но не предоставляют никаких средств для организации безопасной связи в пределах одной локальной сети. Если Алиса из сети А посылает сообщение Бобу в сеть Б и беспокоится о том, что это письмо кто-нибудь перехватит, она должна быть уверена по крайней мере в том, что шифрование трафика с удаленными сетями работает успешно. Это означает, например, что она должна доверять системным администраторам обеих локальных сетей и полагать, что они принимают меры против вмешательства в работу шифрующих устройств.

Допустим теперь, что Алиса не доверяет защите трафика с удаленными сетями. Она может предпринять собственные меры, например, использовать службу защиты транспортного уровня, такую как служба SSL (Secure Socket Layer -- уровень защищенных сокетов), которая служит, в частности, для защищенной пересылки почты по соединениям TCP. Важно отметить, что SSL позволит Алисе установить защищенное соединение с Бобом. Все сообщения транспортного уровня будут зашифрованы -- и на уровне SMSD тоже, но Алисе это не важно. В данном случае Алиса доверяет своей службе SSL. Другими словами, она верит, что SSL ее защитит.

В распределенных системах механизмы защиты часто размещаются на промежуточном уровне. Если Алиса не доверяет SSL, она может пожелать использовать локальную службу защиты RPC. И опять-таки она должна доверять этой службе, полагая, что та работает корректно, а в данном случае не допускает утечек информации и верно идентифицирует клиенты и серверы.

Службам защиты, размещаемым на промежуточном уровне распределенных систем, можно доверять только в том случае, если те службы, на которые они полагаются, также защищены. Так, например, если служба защиты RPC реализована частично на основе SSL, доверие к службе RPC зависит от того, насколько вы доверяете SSL. Если вы не доверяете защите SSL, то не можете доверять и уровню защиты, предоставляемому службой RPC.

Распределение механизмов защиты

Зависимости между службами, требующими доверия, приводят к понятию доверенной вычислительной базы (Trusted Computing Base, TSB). TSB -- это набор всех механизмов защиты (распределенной) компьютерной системы, необходимых для осуществления правил защиты. Чем меньше TSB, тем лучше. Если распределенная система построена на базе промежуточного уровня (надстройки над существующей сетевой операционной системой), ее защита может зависеть от защиты базовых локальных операционных систем. Другими словами, TSB в распределенной системе может включать в себя локальные операционные системы различных хостов.

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

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

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

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

Подобное разделение эффективно уменьшает размер ТСВ до относительно небольшого числа аппаратных и программных компонентов. В ходе последующей защиты этих машин от внешних атак общее доверие к защите распределенной системы может быть еще увеличено. Предотвращение прямого доступа клиентов и их приложений к критически важным службам производится путем предоставления ограниченного интерфейса к защищенным системным компонентам (Reduced Interfaces for Secure System Components, RISSC). Согласно этому подходу, любой критичный к уровню защиты сервер помещается на отдельную машину, изолированную от систем конечных пользователей, и использует низкоуровневые защищенные сетевые интерфейсы, как показано на рис. 8.5. Клиенты и их приложения работают на различных машинах и могут взаимодействовать с защищенным сервером только через эти сетевые интерфейсы.

Простота

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

К сожалению, простых механизмов для реализации правил защиты часто недостаточно. Рассмотрим снова эпизод, когда Алиса посылает письмо Бобу. Мы обсуждали его чуть раньше. Шифрование на канальном уровне -- это простой и легко понятный механизм защиты от перехвата глобального трафика. Однако если Алиса хочет, чтобы ее письма мог получить только Боб, ей необходимо кое-что еще. Она нуждается в службах аутентификации пользовательского уровня, кроме того, чтобы доверять им, Алисе может потребоваться знать о том, как они работают. Поэтому аутентификация пользовательского уровня может потребовать как минимум представления о криптографических ключах и знания определенных механизмов, таких как сертификация, даже несмотря на то, что многие службы защиты полностью автоматизированы и прозрачны для пользователя.

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

Криптография

В защите распределенных систем очень важную роль играют приемы криптографии. Основная идея этих приемов проста. Рассмотрим отправителя S, который хочет переслать сообщение т получателю R. Чтобы обезопасить сообщение от угроз защите, отправитель сначала шифрует его, превращая в непонятное сообщение т', после чего посылает это т' получателю R. R, в свою очередь, должен расшифровать полученное сообщение и получить оригинал, то есть сообщение т.

Шифрование и расшифровка осуществляются путем применения криптографических методов с использованием ключей, как показано на рис. 8.6. Исходная форма посылаемого сообщения, называемая простым текстом (plaintext), обозначена на рисунке как Р, его зашифрованный вариант, известный как шифрованный текст (ciphertext), обозначен как С.

Чтобы описать различные протоколы, используемые для построения служб защиты распределенных систем, полезно будет ввести обозначения для обычного текста, шифрованного текста и ключей. В соответствии с общими соглашениями мы будем использовать выражение С = ЕK(Р) для описания того факта, что шифрованный текст С был получен путем шифрования простого текста Р с использованием ключа K, Точно так же Р = DK(C) обозначает операцию расшифровки шифрованного текста С с использованием ключа K, приводящую к получению простого текста Р.

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

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

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

Третий тип атак -- добавление злоумышленником шифрованного сообщения в систему коммуникации с попыткой заставить R поверить, что это сообщение пришло от S. И снова, как мы увидим далее в этой главе, шифрование может помочь нам защититься от подобных атак. Отметим, что если злоумышленник в состоянии изменить сообщения, он может и добавлять в систему собственные сообщения.

Существует фундаментальное разделение криптографических систем на системы с одинаковыми и различными ключами шифрования и дешифровки. В случае симметричной криптосистемы (symmetric cryptosystem) для шифрования и расшифровки сообщения используется один и тот же ключ. Иными словами:

P = DK(EK(P)).

Симметричные криптосистемы также именуются системами с секретным, или общим, ключом, поскольку отправитель и получатель должны совместно использовать один и тот же ключ, и, чтобы гарантировать защиту, этот общий ключ должен быть секретным. Никто другой этот ключ видеть не должен. Мы будем использовать для такого ключа, разделяемого A и В, обозначение KА,В.

В асимметричной криптосистеме (asymmetric cryptosystem) ключи шифрования и расшифровки различны, но вместе образуют уникальную пару. Другими словами, существует отдельный ключ шифрования KЕ. И отдельный ключ расшифровки, KD, так что:

.

Один из ключей асимметричной криптосистемы является закрытым, другой -- открытым. По этой причине асимметричные криптосистемы также называют системами с открытым ключом (public-key systems). Поэтому мы будем использовать обозначение для обозначения открытого ключа, принадлежащего A, а -- для соответствующего ему закрытого ключа.

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

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

Еще одно применение криптографии в распределенных системах -- это хэш-функции (hash functions). Хэш-функция H принимает на входе сообщение т произвольной длины и создает строку битов h фиксированной длины:

h = Н(т).

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

Хэш-функции, используемые в криптографических системах, имеют определенные свойства. Во-первых, это односторонние функции (one-way functions). То есть вычисление входного сообщения т по известному результату их работы h невозможно. С другой стороны, вычислить h по т достаточно несложно. Во-вторых, они обладают свойством слабой устойчивости к коллизиям (weak collision resistance), означающим, что если заданы исходное сообщение т и соответствующий ему результат h = Н(т), невозможно вычислить другое сообщение т', такое, что Н(т) = Н(т'). И наконец, криптографическая хэш-функция также обладает свойством сильной устойчивости к коллизиям (strong collision resistance). Это значит, что если дана только хэш-функция Н, невозможно вычислить любые два различных входных значения т и т' такие что Н(т) = Н(т').

Подобные свойства приложимы к любой функции шифрования Е и используемым ключам. Кроме того, для любой функции шифрования Е не должно быть возможности вычислить используемый ключ K, имея простой текст Р и соответствующий ему шифрованный текст С = EK(Р). Также аналогично устойчивости к коллизиям, при наличии простого текста Р и ключа K невозможно вычислить другой подходящий ключ K' такой, что .

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

Перед тем как мы погрузимся в детали различных протоколов, обобщим используемую нотацию и аббревиатуры (табл. 8.1).

Нашим первым примером криптографического алгоритма будет стандарт шифрования данных (Data Encryption Standard, DES), который используется в симметричных криптосистемах. Алгоритм DES создавался для работы с 64-битовыми блоками данных. Блок преобразуется в зашифрованный (64-битный) блок за 16 шагов, на каждом из которых используется собственный 48-битный ключ шифрования. Каждый из этих 16 ключей порождается из 56-битного главного ключа, как показано на рис. 8.7, а. Перед тем как над исходным блоком начнут выполняться его 16 циклов шифрования, проводится его первичное преобразование, а после шифрования производится преобразование, обратное первичному. Результатом является зашифрованный блок.

Каждый цикл шифрования i берет в качестве исходных данных 64-битный блок с предыдущего цикла шифрования i - 1, как показано на рис. 8.7, б. 64 бита разбиваются на левую часть Li-1 и правую часть Ri-1 по 32 бита каждая. Правая часть в следующем цикле используется в качестве левой, и наоборот.

Главная работа выполняется в искажающей функции f. Эта функция принимает в качестве исходных данных 32-битный блок Ri-1 и 48-битный ключ Ki, а затем генерирует 32-битный блок, который подвергается операции «исключающее ИЛИ» (XOR) с блоком Li-1, порождая Ri. Искажающая функция сначала расширяет Ri-1 до 48 бит, а затем проводит над ним операцию «исключающее ИЛИ» с ключом Ki, Результат делится на восемь частей по шесть бит. Каждая часть протягивается затем через различные S-боксы (S-boxes), которые представляют собой операции замены каждой из возможных 64 6-битных комбинаций на одну из 16 возможных 4-битных комбинаций. Восемь получившихся кусков по 4 бита объединяются в одно 32-битовое значение и преобразуются далее.

48-битный ключ Ki порождается из 56-битного главного ключа следующим образом. Сначала главный ключ преобразуется и делится на две 28-битных половины. На каждом цикле первая половина сдвигается на один или два бита влево, после чего из нее выделяются 24 бита. Вместе с 24 битами из второй сдвинутой половины они образуют 48-битный ключ. Детально один цикл шифрования иллюстрирует рис. 8.8.

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

Аналитические атаки на DES сильно усложняет тот факт, что структура этого алгоритма никогда не была полностью описана в открытой документации. Так, например, можно показать, что применение нестандартных S-боксов значительно упрощает взлом алгоритма. Рекомендации по структуре и использованию S-боксов были опубликованы только после новых «моделей» атак, разработанных в девяностых годах. Алгоритм DES доказал свою устойчивость к этим атакам, и его разработчики открыли, что они знали об этих «новых» моделях еще в 1974 году, когда разрабатывали DES.

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

Криптосистемы с открытым ключом -- RSA

В качестве второго примера криптографического алгоритма рассмотрим широко используемую систему с открытым ключом -- RSA, названную в честь ее изобретателей -- Ривеста (Rivest), Шамира (Shamir) и Альдемана (Aldeman). Защита RSA вытекает из того факта, что в настоящее время не существует эффективного метода нахождения простых множителей больших чисел. Можно показать, что любое целое число можно записать в виде произведения простых чисел. Так, например, 2100 может быть записано как:

2100 = 2 Ч 2 Ч 3 Ч 5 Ч 5 Ч 7.

Таким образом, 2, 3, 5 и 7 являются простыми множителями числа 2100. В RSA открытый и закрытый ключи создаются из очень больших простых чисел (содержащих сотни десятичных цифр). Взлом RSA эквивалентен обнаружению этих чисел. В настоящее время подобная задача неразрешима, несмотря на то, что математики работают над ней уже несколько столетий.

Создание открытых и закрытых ключей происходит в четыре этапа.

1. Выбираются два больших простых числа, р и q.

2. Вычисляется их произведение n = pЧq и z = (p - 1)Ч(q - 1).

3. Выбирается число d, взаимно простое с z.

4. Вычисляется число е, такое, что eЧd = 1 mod z.

Одно из чисел, например d, может впоследствии использоваться для расшифровки, а е -- для шифрования. Только одно из этих двух чисел будет открытым, какое именно -- зависит от используемого алгоритма.

Рассмотрим вариант, когда Алиса хочет, чтобы сообщение, которое она посылает Бобу, было конфиденциально. Другими словами, она хочет быть уверена в том, что никто кроме Боба не сможет перехватить и прочитать ее сообщение. RSA рассматривает любое сообщение т как строку битов. Каждое сообщение сначала разбивается на блоки фиксированной длины, и каждый очередной блок mi представляется в виде числа в двоичном виде, лежащего в интервале 0 ? mi < п.

Для шифрования сообщения т отправитель вычисляет для каждого блока mi значение ci = mei(mod п), которое и отправляется получателю. Расшифровка на стороне получателя производится путем вычисления mi = cdi(mod п). Отметим, что для шифрования необходимы e и n, в то время как для расшифровки -- d и n.

Сравним RSA с симметричными криптосистемами, такими как DES. Для RSA характерен недостаток -- сложность вычислений, которая приводит к тому, что расшифровка сообщений, зашифрованных по алгоритму RSA, занимает в 100-1000 раз больше времени, чем расшифровка сообщений, зашифрованных по алгоритму DES. Точный показатель зависит от реализации. В результате многие криптографические системы используют RSA только для безопасного обмена общими секретными ключами, избегая применять этот способ для шифрования «обычных» данных. Хэш-функции -- MD5

В качестве последнего примера широко используемого криптографического алгоритма мы рассмотрим MD5. MD5 -- это хэш-функция для вычисления 128-битных дайджестов сообщений (message digests) фиксированной длины из двоичных исходных строк произвольной длины. Сначала исходная строка дополняется до общей длины в 448 бит (по модулю 512), после чего к ней добавляется длина исходной строки в виде 64-битового целого числа. В результате исходные данные преобразуются в набор 512-битных блоков.

Структура алгоритма приведена на рис. 8.9. Начиная с определенного постоянного 128-битового значения, алгоритм включает в себя k фаз, где k -- число 512-битных блоков, получившихся из дополненного согласно алгоритму сообщения. В ходе каждой из фаз из 512-битного блока данных и 128-битного дайджеста, вычисленного на предыдущей фазе, вычисляется новый 128-битный дайджест. Фаза алгоритма MD5 состоит из четырех циклов вычислений, на каждом из которых используется одна из следующих четырех функций:

F(x, y, z) = (х AND у) OR ((NOT х) AND z),

G(x, y, z) = (х AND z) OR (у AND (NOT z)),

H(x, y, z) = x XOR у XOR z,

I(x, y, z) = y XOR (x OR (NOT z)).

Каждая из этих функций работает с 32-битными переменными x, y и z. Чтобы проиллюстрировать, как используются эти функции, рассмотрим 512-битный блок b дополненного сообщения на фазе k. Блок b разделяется на 16 32-битных подблоков b0, b1, …, b15. Как показано на рис. 8.10, в ходе первого цикла для изменения четырех переменных (назовем их p, q, r и s соответственно) в ходе 16 итераций используется функция F. Эти переменные переносятся на очередной цикл, а после окончания этой фазы передаются на следующую. Всего существует 64 заранее определенных констант Ci. Для указания циклического сдвига влево используется запись х <<< п: биты в х сдвигаются на п позиций, причем биты, ушедшие за левую границу числа, добавляются справа.

Во втором цикле подобным же образом используется функция G, а H и I -- соответственно в третьем и четвертом циклах. Каждый шаг, таким образом, включает в себя 64 итерации, и в очередной фазе используются вычисленные на предыдущей фазе значения р, q, r и s.

Размещено на Allbest.ru