пользователи могли его прочитать (для этого необходимо иметь копию
соответствующих отрытых ключей).
Pgp –esимя_файла получатель/получатели Зашифровать файл и поставить цифровую подпись.
Pgp –sимя_файла Поставить цифровую подпись.
(Создается двоичный файл, который не так просто переслать по почте;
получателям необходимо воспользоваться PGP).
Pgp –sa имя_файла Поставить цифровую подпись и сохранить
результат как ASCII-текст. (Просто пересылается по сети, но также требует PGP для прочтения).
Pgpзашифрованный_файл Проверить подпись на зашифрованном файле.
Pgp зашифрованный_файл расшифрованный_файл Расшифровать присланный файл.
3.5. Blowfish.
Blowfish 97 использует ряд схем систем защиты в два этапа. Первичный механизм шифрования базируется на Blowfish, которую разработал в 1993 году Bruce Schneier. Blowfish – это симметричный шифр, который использует ключи сменной длины – от 32 бит до 448 бит. Система защиты Blowfish не запатентована, и, следовательно, разрешена для использования в любом продукте, в который входит. Существуют четыре разных варианта Blowfish, вы часто можете встретиться с ней среди опций многих программ защиты.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
Blowfish -блочный шифр с ключом переменной длины. Это подходит для приложений, где ключ изменяется не часто, подобных линии связи или автоматическому шифрователю файла. Он значительно быстрее, чем DES при выполнении на 32-битных процессорах с большим КЭШем данных, таких как Pentium и PowerPC.
ОПИСАНИЕ АЛГОРИТМА
Blowfish - 64-битный блочный шифр с ключом переменной длины. Алгоритм включает в себя 2 части: часть расширения ключей и часть шифрования данных. Расширение ключа преобразует ключ, в большинстве 448-битный, в несколько суммированных массивов подключей в 4168 байт.
Шифрование данных происходит через 16-итерационную сеть Feistel. Каждая итерация состоит из ключе-зависимой перестановки, и зависящей от ключа и данных замены. Все операции - XOR и сложение на 32-битных словах. Единственные дополнительные операции - 4 поиска в индексированных массивах на итерацию.
Подключи: Blowfish использует большое количество подключей. Эти ключи должны быть предварительно вычислены перед любым шифрованием данных или расшифровкой.
1. P-массив включает 18 32-битных подключей:
P1, P2,..., P18.
2.Имеются четыре 32-битных S-блока с 256 входами каждый:
S1,0, S1,1,..., S1,255;
S2,0, S2,1,..,, S2,255;
S3,0, S3,1,..., S3,255;
S4,0, S4,1,..,, S4,255.
Шифрование: Blowfish - сеть Feistel, которая включает 16 итераций.
Реализации Blowfish, которые требуют наибольших скоростей, не должны организовываться в цикле, что гарантирует присутствие всех подключей в КЭШе.
Всего, 521 итерация требуются, для генерации всех требуемых подключей. Прикладные программы могут сохранить подключи, чтобы сократить время.
MINI-BLOWFISH
Следующие малые версии Blowfish определены исключительно для криптоанализа. Они не предлагаются для реализации. Blowfish-32 имеет размер блока в 32 бита, и массивы подключей с 16 битными входами (каждый S-блок имеет 16 входов). Blowfish-16 имеет размер блока в 16-бит, и массивы подключей с 8-битными входами (каждый S-блок имеет 4 входа).
РЕАЛИЗАЦИЯ ПРОЕКТА
Вероятность ошибок в реализации алгоритма мала, т.к. сами S блоки и P-блок очень просты. 64-битный блок в действительности разбивается на 32-битные слова, что совместимо с существующими алгоритмами. В Blowfish можно легко повышать размер блока до 128-бит, и понижать размер блока. Криптоанализ вариантов мини-Blowfish может быть значительно проще, чем криптоанализ полной версии.
Сеть Feistel, составляющая тело Blowfish, разработана так, чтобы при наибольшей простоте она сохраняла свои криптографические свойства.
В проекте алгоритма существует два способа гарантировать, что ключ является достаточно длинным, чтобы достичь нужного уровня защиты. Первый в том, чтобы тщательно разработать алгоритм так, чтобы энтропия случайно введенного ключа сохранялась, так как тогда не существует другого метода криптоанализа, кроме атаки в "лоб". Другой способ - в увеличении длины ключа настолько, что уменьшение эффективности ключа на несколько битов не дает больших преимуществ. Так как Blowfish разработан для больших процессоров с большим размером памяти я выбрал последний способ.
Отнимающий много времени процесс порождения подключей добавляет сложность для нападения "в лоб". Всего 522 итераций алгоритма шифрования требуется, чтобы проверить один ключ, что добавляет 29 шагов при любом нападение в лоб.
ВОЗМОЖНЫЕ УПРОЩЕНИЯ
Меньшее количество итераций. Вероятно, возможно уменьшение количества итераций с 16 до 8 без сильного ослабления защиты. Число итераций требуемых для защиты может зависеть от длины ключа. Обратите внимание, что с имеющейся процедурой порождения подключа, алгоритм с 8 итерациями не может обрабатывать ключ длиной больше 192 бит.
Непрерывное вычисление подключа. Текущий метод вычисления подключей требует, чтобы все подключи вычислялись перед любым шифрованием. Фактически невозможно вычислить последний подключ последнего S-блока без вычисления перед этим предыдущего ключа. Был бы предпочтительней альтернативный метод вычисления подключа: когда каждый подключ может быть вычислен независимо от другого подключа. Высококачественные реализации могли бы предварительно вычислять подключи для более высокой скорости, но реализации с низкими требованиями могут вычислять подключи, когда это необходимо.
Наиболее эффективный способ взломать Blowfish - через полный перебор ключей Исходный текст на Си и тестовые векторы может получить любой, желающий реализовать алгоритм, в соответствие с законами США об экспорте.
Blowfish незапатентован, и будет таким оставаться во всех странах. Алгоритм тем самым помещен в общую область и может быть использован любым.
Blowfish - это простая и легкая в понимании программа. Панель инструментов содержит только картинки и ни одного слова. Четкая система подсказок. Выбрав файл, и нажав на изображение «замка», вы получите сообщение, что сейчас возможно использование шифрования только с ключом из пяти позиций, но после регистрации доступными будут и 32000-символьные ключи шифрования. После введения ключа процесс шифрования длится несколько секунд. Файл получает новое расширение (.BFA), которое служит командой для операционной системы при встрече с ним запустить в действие Blowfish Advanced.
В сети существует также защитная программа под Windows 95/NT, которая использует механизм Blowfish. EncLib 5/5 Использует для шифрования варианты Blowfish CDC и ECB.
3.6.KERBEROS.
Развитие криптологии с открытым ключом позволило криптологическим системам довольно быстро найти широкое коммерческое применение. Но интенсивное использование криптографии не обходится без “накладок”. Время от времени появляется информация о неприятностях в той или иной системе защиты. Последним нашумевшим в мире происшествием стал взлом системы Kerberos. Система эта, разработанная в середине 80-х годов, довольно популярна в мире, и ее взлом вызвал немалое беспокойство пользователей.
Проблема защиты компьютерных сетей от несанкционированного доступа приобрела особую остроту. Развитие коммуникационных технологий позволяет строить сети распределенной архитектуры, объединяющие большое количество сегментов, расположенных на значительном удалении друг от друга. Все это вызывает увеличение числа узлов сетей, разбросанных по всему миру, и количества различных линий связи между ними, что, в свою очередь, повышает риск несанкционированного подключения к сети для доступа к важной информации. Особенно неприятной такая перспектива может оказаться для банковских или государственных структур, обладающих секретной информацией коммерческого или любого другого характера. В этом случае необходимы специальные средства идентификации пользователей в сети, обеспечивающие доступ к информации лишь в случае полной уверенности в наличии у пользователя прав доступа к ней. Существует ряд разработок, позволяющих с высокой степенью надежности идентифицировать пользователя при входе в систему. Среди них, например, есть технологии, идентифицирующие пользователя по сетчатке глаза или отпечаткам пальцев. Кроме того, ряд систем использует технологии, основанные на применении специального идентификационного кода, постоянно передаваемого по сети. Так, при использовании устройства (фирмы Security Dinamics) обеспечивается дополнительная информация о пользователе в виде шестизначного кода. В данном случае работа в сети невозможна без наличия специальной карты SecureID (похожей на кредитную), которая обеспечивает синхронизацию изменяющегося кода пользователя с хранящимися на UNIX-хосте. При этом доступ в сеть и работа в ней может осуществляться лишь при знании текущего значения кода, который отображается на дисплее устройства SecureID. Однако основным недостатком этой и ей подобных систем является необходимость в специальном оборудовании, что вызывает неудобства в работе и дополнительные затраты. Система Kerberos (по-русски – Цербер), разработанная участниками проекта Athena, обеспечивает защиту сети от несанкционированного доступа, базируясь исключительно на программных решениях, и предполагает многократное шифрование передаваемой по сети управляющей информации. Kerberos обеспечивает идентификацию пользователей сети и серверов, не основываясь на сетевых адресах и особенностях операционных систем рабочих станций пользователей, не требуя физической защиты информации на всех машинах сети и исходя из предположения, что пакеты в сети могут быть легко прочитаны и при желании изменены.
Клиент/Kerberos/Сервер.
Kerberos имеет структуру типа клиент/сервер и состоит из клиентских частей, установленных на все машины сети (рабочие станции пользователей и серверы), и Kerberos-сервера (или серверов), располагающегося на каком-либо (не обязательно выделенном) компьютере.Kerberos-сервер, в свою очередь, делится на две равноправные части: сервер идентификации (authentication server) и сервер выдачи разрешений (ticket granting server). Следует отметить, что существует и третий сервер Kerberos, который, однако, не участвует в идентификации пользователей, а предназначен для административных целей. Область действия Kerberos (realm) распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в базе Kerberos-сервера и где все серверы обладают общим кодовым ключом с идентификационной частью Kerberos. Эта область не обязательно должна быть участком локальной сети, поскольку Kerberos не накладывает ограничения на тип используемых коммуникаций. Упрощенно модель работы Kerberos можно описать следующим образом. Пользователь (Kerberos-клиент), желая получить доступ к ресурсу сети, направляет запрос идентификационному серверу Kerberos. Последний идентифицирует пользователя с помощью его имени и пароля и выдает разрешение на доступ к серверу выдачи разрешений, который, в свою очередь, дает “добро” на использование необходимых ресурсов сети. Однако данная модель не отвечает на вопрос о надежности защиты информации, поскольку, с одной стороны, пользователь не может посылать идентификационному серверу свой пароль по сети, а с другой – разрешение на доступ к обслуживанию в сети не может быть послано пользователю в виде обычного сообщения. В обоих случаях информация может быть перехвачена и использована для несанкционированного доступа в сеть. Для того, чтобы избежать подобных неприятностей Kerberos применяет сложную систему многократного шифрования при передаче любой управляющей информации в сети. Доступ пользователей к сетевым серверам, файлам, приложениям, принтерам и т.д. осуществляется по следующей схеме. Клиент (под которым в дальнейшем будет пониматься клиентская часть Kerberos, установленная на рабочей станции пользователя) направляет запрос идентификационному серверу на выдачу “разрешения на получение разрешения” (ticket-granting ticket), которое даст возможность обратиться к серверу выдачи разрешений. Идентификационный сервер адресуется к базе данных, хранящей информацию о всех пользователях, и на основании содержащегося в запросе имени пользователя определяет его пароль. Затем клиенту отсылается “разрешение на получение разрешения” и специальный код сеанса (session key), которые шифруются с помощью пароля пользователя как ключа. При получении этой информации пользователь на его рабочей станции должен ввести свой пароль, и если он совпадает с хранящимися в базе Kerberos-сервера, “разрешение на получение разрешения” и код сеанса будут успешно расшифрованы. Таким образом решается проблема с защитой пароля – в данном случае он не передается по сети. После того как клиент зарегистрировался с помощью идентификационного сервера Kerberos, он отправляет запрос серверу выдачи разрешений на получение доступа к требуемым ресурсам сети. Этот запрос (или “разрешение на получение разрешения”) содержит имя пользователя, его сетевой адрес, отметку времени, срок жизни этого разрешения и код сеанса.“Разрешение на получение разрешения” зашифровывается два раза: сначала с помощью специального кода, который известен только идентификационному серверу и серверу выдачи разрешений, а затем, как уже было сказано, с помощью пароля пользователя. Это предотвращает не только возможность использования этого разрешения при его перехвате, но и делает его недоступным самому пользователю. Для того чтобы сервер выдачи разрешений дал клиенту доступ к требуемым ресурсам, недостаточно только “разрешения на получение разрешения”. Вместе с ним клиент посылает так называемый аутентикатор (authenticator), зашифровываемый с помощью кода сеанса и содержащий имя пользователя, его сетевой адрес и еще одну отметку времени. Сервер выдачи разрешений расшифровывает полученное от клиента “разрешение на получение разрешения”, проверяет, не истек ли срок его “годности”, а затем сравнивает имя пользователя и его сетевой адрес, находящиеся в разрешении, с данными, которые указаны в заголовке пакета пришедшего сообщения. Однако на этом проверки не заканчиваются. Сервер выдачи разрешений расшифровывает аутентикатор с помощью кода сеанса и еще раз сравнивает имя пользователя и его сетевой адрес с предыдущими двумя значениями, и только в случае положительного результата может быть уверен наконец, что клиент именно тот, за кого себя выдает. Поскольку аутентикатор используется для идентификации клиента всего один раз и только в течение определенного периода времени, становится практически невозможным одновременный перехват “разрешения на получение разрешения” и аутентикатора для последующих попыток несанкционированного доступа к ресурсам сети. Каждый раз, при необходимости доступа к серверу сети, клиент посылает “разрешение на получение разрешения” многоразового использования и новый аутентикатор. После успешной идентификации клиента в качестве источника запроса сервер выдачи разрешений отсылает пользователю разрешение на доступ к ресурсам сети (которое может использоваться многократно в течение некоторого периода времени) и новый код сеанса. Это разрешение зашифровано с помощью кода, известного только серверу выдачи разрешений и серверу, к которому требует доступа клиент, и содержит внутри себя копию нового кода сеанса. Все сообщение (разрешение и новый код сеанса) зашифровано с помощью старого кода сеанса, поэтому расшифровать его может только клиент. После расшифровки клиент посылает целевому серверу, ресурсы которого нужны пользователю, разрешение на доступ и аутентикатор, зашифрованные с помощью нового кода сеанса. Для обеспечения еще более высокого уровня защиты, клиент, в свою очередь, может потребовать идентификации целевого сервера, чтобы обезопаситься от возможного перехвата информации, дающей право на доступ к ресурсам сети. В этом случае он требует от сервера высылки значения отметки времени, увеличенного на единицу и зашифрованного с помощью кода сеанса. Сервер извлекает копию кода сеанса, хранящуюся внутри разрешения на доступ к серверу, использует его для расшифровки аутентикатора, прибавляет к отметке времени единицу, зашифровывает полученную информацию с помощью кода сеанса и отсылает ее клиенту. Расшифровка этого сообщения позволяет клиенту идентифицировать сервер. Использование в качестве кода отметки времени обеспечивает уверенность в том, что пришедший клиенту ответ от сервера не является повтором ответа на какой-либо предыдущий запрос. Теперь клиент и сервер готовы к передаче необходимой информации с должной степенью защиты. Клиент обращается с запросами к целевому серверу, используя полученное разрешение. Последующие сообщения зашифровываются с помощью кода сеанса. Более сложной является ситуация, когда клиенту необходимо дать серверу право пользоваться какими-либо ресурсами от его имени. В качестве примера можно привести ситуацию, когда клиент посылает запрос серверу печати, которому затем необходимо получить доступ к файлам пользователя, расположенным на файл-сервере. Кроме того, при входе в удаленную систему пользователю необходимо, чтобы все идентификационные процедуры выполнялись так же, как и с локальной машины. Эта проблема решается установкой специальных флагов в “разрешении на получение разрешения” (дающих одноразовое разрешение на доступ к серверу от имени клиента для первого примера и обеспечивающих постоянную работу в этом режиме для второго). Поскольку, как было сказано выше, разрешения строго привязаны к сетевому адресу обладающей ими станции, то при наличии подобных флагов сервер выдачи разрешений должен указать в разрешении сетевой адрес того сервера, которому передаются полномочия на действия от имени клиента. Следует отметить также, что для всех описанных выше процедур идентификации необходимо обеспечить доступ к базе данных Kerberos только для чтения. Но иногда требуется изменять базу, например, в случае изменения ключей или добавления новых пользователей. Тогда используется третий сервер Kerberos – административный (Kerberos Administration Server). Не вдаваясь в подробности его работы, следует отметить, что его реализации могут сильно отличаться (так, возможно ведение нескольких копий базы одновременно).