Криптография - статьи

О современной криптографии

В. М. Сидельников, д. ф.-м. н., профессор, академик Академии криптографии РФ,

зав. лабораторией МГУ по математическим проблемам криптографии

Опубликовано на сайте

Криптография (cryptography) -- наука о способах преобразования (шифрования) информации с целью защиты ее от незаконного или нежелательного использования. Одним из видов такого преобразования является шифрование информации, которое призвано обеспечивать практическую невозможность ее прочтения или изменения незаконными пользователями. Кроме того, шифрование должно также обеспечивать возможность легкого получения исходной информации из зашифрованной легитимными пользователями, которым доступен ключ алгоритма расшифрования. Следует сказать, что в последние годы круг задач криптографии существенно расширился. Некоторые из новых направлений будут рассмотрены ниже.
Обычно предполагается, что зашифрованная информация передается по общедоступному каналу связи так, что все пользователи (законные и незаконные) имеют к ней свободный доступ.
В прикладной криптографии слова "практическая невозможность вскрытия (взламывания) шифра" означают, что незаконный пользователь будет вынужден привлекать для проведения необходимого объема вычислений или других работ по вскрытию шифра неприемлемые для него ресурсы (оборудование, время, пространство, энергию, деньги и т.п.). Обсуждение проблем соотношения цены информации и приемлемости затрат для ее получения выходит за пределы данной статьи.
В математической или теоретической криптографии стремятся показать, что задача взламывания шифра является задачей со строго доказуемыми свойствами, в частности, ее решение имеет определенную "сложность" в рамках той или иной математической модели, например, в рамках теоретико-информационного или теоретико-сложностного подхода.
Мы далее рассматриваем только математические преобразования информации, представленной в дискретном виде, т. е. в виде последовательности w элементов конечного алфавита A.
Известны два вида шифрования -- традиционное (оно же симметрическое) и "открытое шифрование" (асимметрическое). При традиционном шифровании законный пользователь X с помощью некоторого конечного автомата AK

(шифратора) преобразует последовательность

w=(w1,...wn), называемую открытой информацией, в шифрованную информацию . Шифратор AK (ключа), известного пользователю X. Законные пользователи, которым предназначена информации w, осуществляют расшифрование информации также с помощью некоторого конечного автомата, зависящего от параметра K`, связанного с K. Обычно K`=K. В рассматриваемом случае каждый законный пользователь изначально обладает как преобразованием , так и преобразованием

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

В традиционном варианте шифрования законные пользователи X

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

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

Второй вид шифрования (возникший в 70-х годах XX столетия), для которого нет необходимости в дополнительном секретном канале распределения ключей, носит название "открытого шифрования". При открытом шифровании каждый абонент X сети связи строит (или доверяет кому-либо построить) "одностороннюю" функцию , которая, так же как и в первом случае, определяется некоторым секретным параметром K, известным только абоненту X. Функция строится таким образом, чтобы ее значения

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


при известном секретном параметре K также вычислялась достаточно "просто", т. е. абонент X

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

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

Абонент Y, желающий передать открытую информацию w

абоненту X, вычисляет шифрованную информацию

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

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

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

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


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

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

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

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

в тех или иных условиях. Обычно усилия направляются на вычисление ключа K. Вместе с тем в некоторых случаях можно определить w без определения ключа (бесключевое чтение). Далее под взламыванием будем понимать только задачу определения ключа.

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


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

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

Традиционные шифраторы обычно делятся на блочные и поточные. Поточный шифратор представляет собой автономный автомат, который вырабатывает псевдослучайную последовательность

обычно двоичную. В качестве шифрованной информации выступает последовательность ,

. Обычно в качестве функции наложения используется функция сложения в каком либо конечном поле или кольце, в частности, в двоичном случае , т. е.

. В последнем случае обратное преобразование (дешифрование) осуществляется точно так же:

, что позволяет на обоих концах канала связи иметь шифраторы с одинаковыми ключами.

Блочный шифратор представляет собой автомат, входами и выходами которого являются последовательности w и длины n. Входная последовательность разбивается на блоки длины n и каждый блок шифруется независимо один от другого на одном ключе K. Блочный шифратор реализует перестановку элементов пространства An, где A -- используемый алфавит. Самым известными блочными шифраторами являются американский шифратор DES (data encryption standard) и отечественный стандарт ГОСТ 28147-89 , у которых длина блока n

равна 64 и 256 соответственно. Имеются и другие типы шифраторов, существенно отличные от рассмотренных.

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


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

Ввиду того, что задача определения ключа может быть представлена как задача решения некоторой системы нелинейных уравнений в конечном поле, для криптографии представляют значительный интерес методы решения систем того или иного вида и оценки их сложности. С примерами криптографических исследований можно познакомиться по многочисленным работам, связанным с изучением свойств преобразования DES, которые опубликованы в последние 20 лет в Procedings of Crypto, Procedings of Eurocrypt, Journal of Cryptology.

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

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

За последние годы получил значительное развитие раздел теоретической криптографии, занимающийся изучением вопросов существования тех или иных криптографических объектов с доказуемыми (при некоторых дополнительных предположениях) оценками стойкости. В круг интересов этого раздела криптографии входят вопросы построения и обоснования свойств таких криптографических понятий как "односторонняя функция", псевдослучайный генератор, криптографический протокол (cryptographic protocol), в частности, протокол доказательства с нулевым разглашением (zero-knowledge proof protocol) и т. п. Эти понятия изучаются с точки зрения абстрактных позиций сложности вычислений.


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

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

Пусть необходимо передать элемент из конечного множества A. В качестве часто выступает значение хэш-функции. Будем предполагать, что на обоих концах канала связи имеется секретный элемент b (ключ) из множества B. Пусть функция инъективна при каждом фиксированном y и обладает тем свойством, что для каждых и c множество решений уравнения

имеет достаточно много элементов.

В рассматриваемой системе имитозащиты по общедоступному каналу связи вместо элемента из A передается элемент

. Законный пользователь знает ключ b, поэтому он, получив элемент c, решает уравнение и определяет элемент .

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

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


вида , где Fq -- конечное поле с q

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

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

Наиболее известной на настоящий момент, используемой на практике и достаточно стойкой (2001 г.) является система RSA (сокращение от фамилий авторов - Rivest, Shamir, Adleman). В этой системе законный пользователь X для построения однонаправленной функции F=FX выбирает число n=nX, являющееся произведением двух достаточно больших простых чисел p и q, и целое число z=zX такое, что

, где (r,m) -- наибольший общий делитель чисел r и m, -- функция Эйлера (количество натуральных чисел, не превосходящих n и взаимно простых с n, или порядок мультипликативной группы вычетов по modn взаимно простых с n). Открытая информация, представленная целым числом w, , шифруется с помощью общеизвестной функции

, действующей на . Числа n="nX" и zX всех абонентов сети засекреченной связи обычно помещают в общедоступный справочник. Таким образом, любой абонент может послать секретное сообщение абоненту X.

Секретная информация (ключ) законного пользователя X

состоит из чисел p и q, на которые разлагается число n. Знание p и q позволяет вычислить значение функции Эйлера , а затем с помощью алгоритма Евклида -- число z`, для которого . Очевидно, обратное преобразование имеет вид


и может быть реализовано абонентом X достаточно быстро - за операций даже без использования "быстрых" алгоритмов умножения целых чисел.

Так как незаконный пользователь не знает разложения n, то простейший для него способ вычисления функции, обратной к F, состоит в разложении n на множители с последующим вычислением . В общем случае сложность решения задачи разложения является достаточно большой. В течение нескольких последних десятилетий математиками было найдены несколько нетривиальных алгоритмов разложения целых чисел на множители. В частности, удалось разложить 155-разрядное девятое число Ферма на три простых множителя. Множители имеют примерно одинаковое число разрядов. Считается, что система RSA имеет достаточную стойкость, если n имеет более 512 двоичных разрядов.

Теория кодирования доставляет много примеров стойких систем открытого шифрования. Пусть -- линейный код над с параметрами (n,k,b), который имеет простое декодирование, и M -- его порождающая -матрица. Пусть H -- невырожденная -матрица и -- перестановочная -матрица.

Открытой информацией является k-мерный вектор

, шифрованной -- n-мерный вектор

(функция ), где -- случайный вектор веса

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

Получив , абонент X вычисляет следующие элементы:

, декодирует , т. е. представляет его в виде ,

, , где

, и, наконец, с помощью последнего соотношения находит w.

Проделать последнюю цепочку вычислений злоумышленнику трудно из-за того, что он не знает . Поэтому ему трудно декодировать код с порождающей матрицей M`, который для него является кодом "общего положения". Известно, что сложность N декодирования таких кодов имеет вид , т. е. при относительно небольших k и n-k является неприемлемо большой.

Если в качестве взять код Боуза -- Чоудхури -- Хоквингема или код Рида -- Маллера, то при подходящем k и n мы получим стойкую систему открытого шифрования. Если же в качестве взять код Рида -- Соломона, то получим слабую систему. Кодовые системы имеют алгоритм зашифрования информации существенно более быстрый, чем системы RSA.

Другими идейно близкими к открытому шифрованию являются методы построения "открытого ключа" (public key), т. е. методы создания общего ключа двух абонентов или большего числа абонентов, недоступного для внешнего наблюдателя, с помощью обмена между ними информацией по общедоступному каналу связи. После создания ключа пользователи могут использовать его, например, как ключ для традиционного симметричного шифрования.

Для примера рассмотрим один популярный метод построения открытого ключа в сети абонентов Xj, , предложенный Диффи и Хеллманом. Пусть -- конечное поле с достаточно большим числом элементов q и -- первообразный элемент мультипликативной группы G этого поля. Каждый из абонентов Xj и Xi один независимо от другого выбирают по секретному числу xj,xi, ,

поля, например, помещают их в общедоступный справочник. Для образования секретной связи между Xj и Xi первый абонент вычисляет элемент , а второй -- . Таким образом, у каждого из абонентов образуется один и тот же элемент поля , который и является "открытым ключом".

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

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

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

Необходимо отметить, что сложность логарифмирования определяется не только числом разрядов, требуемых для записи q -- числа элементов поля, но и некоторыми нетривиальными его теоретико-числовыми свойствами. В частности, для полей характеристики 2 и для полей, у которых в разложении q-1

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

На основе идей "открытого шифрования" в криптографии появились методы преобразования информации, открывающие новые возможности для ее использования в деловом мире. К таким методам следует отнести алгоритмы по созданию цифровой подписи, системы идентификации, пароли, системы распределения ключей и многие другие (см., например, и статьи в Proceding of Crypto, Proceding of Eurocrypt, Journal of Cryptolodgy и др.).

Цифровая подпись сообщения w

пользователя X образуется с помощью отображения , которое характеризуются следующими свойствами:

при известном w элемент g может быть относительно просто вычислен X, но не может быть вычислен злоумышленником без привлечения очень значительных и потому недоступных ему вычислительных ресурсов (подпись не может быть подделана),

существует простой алгоритм проверки соответствия

(от подписи не может отказаться абонент X).

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

В качестве примера иного способа построения функции

, который нашел достаточно широкое практическое применение, рассмотрим цифровую подпись Эль Гамаля. Используем обозначения, введенные при описании примера построения открытого ключа. Поле считаем простым, т. е. p -- простое число.

Пользователь X вырабатывает секретное число x, и помещает его в общедоступный справочник. Цифровой подписью сообщения w, . Секретное число r

пользователь X выбирает случайно из интервала (1,p-1). Число m определяется числами r и w с помощью соотношения .

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

>

Дополнительная информация

1.	Разработка CSP для Windows
2.	Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms
3.	Много интересной информации об архитектуре CSP можно найти тут

Функции конвертирования ключей

Архитектура круговорота открытых ключей для "нестандартных" алгоритмов в Windows представлена на .
Функция A_ConvertPublicKeyInfo - на входе принимает ключ в формате ASN.1 DER и должна преобразовать его в формат, который "понимает" функция CSP CPImportKey
Функция A_EncodePublicKeyInfoAndParameters на входе принимает ключ в том формате,

в котором ключ экспортирует CPExportKey. На выходе A_EncodePublicKeyInfoAndParameters должна сформировать ASN.1 DER структуру с ключом - ту же самую, которая в случае импорта передается в A_ConvertPublicKeyInfo - на вход. Надеюсь, вы не запутались во всех этих входах и выходах.
Вот сигнатуры и краткие описания параметров этих функций:
BOOL WINAPI A_ConvertPublicKeyInfo( DWORD dwCertEncodingType, // IN - VOID *EncodedKeyInfo, // IN - буфер с ключом - указатель // на структуру CERT_PUBLIC_KEY_INFO
DWORD dwAlg, // IN - AlgId ключа
DWORD dwFlags, // IN - обычно 0
BYTE **ppStructInfo, // OUT - двойной указатель на структуру // в заголовке структуры идет сначала PUBLICKEYSTRUC, затем DSSPUBKEY, // а затем сам ключ с параметрами DWORD *StructLen // OUT - длина структуры
);
BOOL WINAPI A_EncodePublicKeyAndParameters( DWORD dwCertEncodingType, // IN
LPCSTR lpszStructType, // IN - OID алгоритма
const void* pvStructInfo, // IN - такая же структура как // на выходе ConvertPublicKeyInfo
DWORD nStructLen, // IN - длина входной структуры
DWORD dwFlags, // IN - обычно 0
DWORD Unk, // ? - неизвестно
BYTE **pbPubKey, // OUT - открытый ключ в ASN.1 DER
DWORD* pcPubKeyLen, // OUT - длина открытого ключа BYTE **pbParams, // OUT - параметры открытого ключа
DWORD* pcParamsLen // OUT - длина параметров
);
Форматы ключей зависят от криптопровайдера и используемых алгоритмов.

Функция I_CryptGetDefaultCryptProvider из crypt32.dll

По непонятной для меня причине Windows часто не пытается искать нужный криптопровайдер по идентификатору алгоритма, с которым требуется работать. В таких случаях она просто вызывает недокументированную функцию I_CryptGetDefaultCryptProvider, и если тот провайдер, который вернула эта функция, не умеет работать с данным алгоритмом, то процесс завершается с ошибкой. Так происходит, например, при разборе в Internet Explorer PKCS#7 ответа в сценарии с запросом сертификата на тестовом УЦ.
HCRYPTPROV WINAPI I_CryptGetDefaultCryptProv(ALG_ID algid);
Необходимо заменить эту функцию таким образом, чтобы при нулевом параметре algid на входе она возвращала наш провайдер, который уже в отличие от штатного провайдера легко справится с "нестандартными алгоритмами".
Обсуждение способов замены функций в системной dll выходит далеко за рамки данной статьи. Могу лишь, как один из способов решения, предложить библиотеку Microsoft Detours.

Интеграция провайдера в Windows

Помимо наличия библиотеки самого провайдера, дополнительно требуется:

зарегистрировать провайдер и криптоалгоритмы в системе, прописав определенные параметры в реестре;

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

заменить функцию I_CryptGetDefaultCryptProvider в библиотеке crypt32.dll

Только после выполнения этих действий провайдер нормально интегрируется в систему и вы сможете, например, генерировать сертификаты при помощи вашего провайдера на основе стандартного компонента ОС Windows Server - Сertification services или на тестовом УЦ КриптоПро.
Корректно будет отображаться статус проверки подписи у сертификатов, подписанных вашим "нестандартным" алгоритмом и т.п.
Далее подробно рассмотрим каждый из упомянутых выше шагов, предполагая при этом, что библиотека с Вашим CSP уже имеется и корректно работают все функции провайдера.

Привязка закрытого ключа к сертификату

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

Контекст сертификата - это набор дополнительных атрибутов сертификата, которые находятся не в теле сертификата, а хранятся отдельно от него. Одним из таких атрибутов и является ссылка на закрытый ключ, которая состоит из имени провайдера и имени ключевого контейнера.
Пример кода для привязки закрытого ключа к сертификату:
PCCERT_CONTEXT pCert; CRYPT_KEY_PROV_INFO prov_info; … prov_info.cProvParam = 0; prov_info.rgProvParam = 0; prov_info.dwFlags = 0; prov_info.dwKeySpec = AT_SIGNATURE; prov_info.dwProvType = 0; prov_info.pwszContainerName = L"key-kont-name"; prov_info.pwszProvName = L"A-CSP";
CertSetCertificateContextProperty( pCert, CERT_KEY_PROV_INFO_PROP_ID, 0, &prov_info );
Успехов в разработке криптопровайдера!

Регистрация криптопровайдера и алгоритмов в системе

Когда у вас уже есть готовая библиотека с реализацией функций CSP, необходимо зарегистрировать ее в системе, для того чтобы новый криптопровайдер стал доступен различным приложениям.
Процесс регистрации самого CSP подробно описан в MDSN, и повторять эту информацию здесь смысла нет. Все это подробно описано в []. Также здесь мы не будем останавливаться на проблеме подписи нового CSP в Microsoft и путях ее обхода. Эта проблема уже многократно обсуждалась на различных форумах, например смотрите []. Гораздо интереснее рассмотреть регистрацию криптографических алгоритмов. Каждый алгоритм имеет свой уникальный ASN.1 идентификатор Оbject Identifier - OID. Например, алгоритм подписи ГОСТ-34.10-2001 имеет такой OID (представленный в виде строки) - "1.2.643.2.2.3". Идентификатор каждого поддерживаемого вашим CSP алгоритма следует занести в реестр. Помимо OID у каждого криптоалгоритма в Windows существует еще идентификатор в виде четырехбайтового числа - AlgID, по которому алгоритмы идентифицируются в провайдере. Этот идентификатор заносится в CSP и его можно узнать, перечислив алгоритмы посредством вызова CPGetProvParam. В КриптоПро, например, для алгоритма хеширования ГОСТ-34.11-94 AlgID используется значение 0x801e.
Пусть нам необходимо зарегистрировать алгоритм подписи ГОСТ-34.10-2001. Тогда в реестре необходимо прописать следующие идентификаторы:

"1.2.643.2.2. 9!1" - Хэш ГОСТ-34.11-94

"1.2.643.2.2.19!3" - Ключ подписи ГОСТ-34.10-2001

"1.2.643.2.2.3!4" - Подпись ГОСТ-34.10-2001 - Алгоритм Хэша + Алгоритм Ключа

Далее приведен пример кода регистрации OID алгоритма ГОСТ-34.11-94 // Регистрация GOST-3411-94 HASH OID //
CRYPT_OID_INFO oidInfo; int rc = 0;
memset(&oidInfo, 0, sizeof(CRYPT_OID_INFO)); oidInfo.cbSize = sizeof(CRYPT_OID_INFO);
oidInfo.pszOID="1.2.643.2.2.9"; oidInfo.pwszName= L"GOST-3411-94 HASH"; oidInfo.dwGroupId = CRYPT_HASH_ALG_OID_GROUP_ID; oidInfo.Algid = 0x801e; oidInfo.ExtraInfo.cbData=0; oidInfo.ExtraInfo.pbData=0;

rc = CryptRegisterOIDInfo( &oidInfo, 0 ); if(rc) printf("\nHash algorithm registered"); else printf("\nError registering hash algorithm");

Аналогично регистрируются и остальные алгоритмы. Подробную информацию о структуре CRYPT_OID_INFO можно найти в MSDN.

Для того, чтобы провайдер вызывался для проверки сертификата, подписанного нашим "нестандартным" алгоритмом, необходимо еще одно дополнительное действие.

Дело в том, что Windows определяет, какой провайдер использовать для проверки по полю ExtraInfo (см. ссылку в предыдущем абзаце для описания этого поля) в ключе реестра, соответствующем алгоритму подписи - такой ключ мы создаем, вызывая функцию CryptRegisterOIDInfo. Поэтому надо указать системе наш провайдер в качестве провайдера по умолчанию для типа, который занесен в ExtraInfo алгоритма подписи.

Следующий код устанавливает провайдер по умолчанию для определенного типа.

#define YOUR_PROV_NAME "MY_PROV"

#define YOUR_PROV_TYPE 75

rc = CryptSetProvider( YOUR_PROV_NAME, YOUR_PROV_TYPE );

Сценарии применения нашего CSP

Рассмотрим здесь два сценария применения CSP.
Первый сценарий - проверка подписи сертификата. Для проверки подписи система загружает открытый ключ из сертификата, которым подписан проверяемый. Затем по OID алгоритма подписи проверяемого сертификата, так как описано в предыдущем разделе статьи, определяется требуемый провайдер. Чтобы проверить подпись, нужно импортировать открытый ключ в CSP и можно было бы подумать, что Windows сразу вызывает функцию нашего провайдера CPImportKey. Но не тут-то было!
Второй сценарий - генерация ключевой пары и отправка запроса на сертификат на Удостоверяющий Центр. Windows загружает наш CSP, генерирует ключевую пару и экспортирует к себе наверх открытый ключ, вызывая функцию CPExportKey. Все хорошо. Вроде бы надо взять и поместить полученный буфер с ключом в PKCS#10 запрос, который затем будет отправлен на УЦ. И тут все опять не совсем так.
Оказывается, существуют промежуточные функции для экспорта/импорта открытых ключей, и без их реализации ничего хорошего с нашим CSP, в упомянутых выше двух сценариях, не получится. Беда еще и в том, что функции эти недокументированные и найти информацию по ним крайне сложно. Их описанию посвящен следующий раздел.

Криптография - статьи

Криптография - статьи

Александр Лозовюк

Для обеспечения конфиденциальности информации, передаваемой через интернет, используется шифрование и цифровые подписи. Рассмотрим одну из бесплатных утилит для поддержки этих функций на вашем компьютере.
Программа является продуктом сообщества OpenSource, распространяется под лицензией General Public License (GPL) и получить ее можно как в бинарном виде для любой платформы, так и в виде исходных текстов. Пакет изначально присутсвует в любом дистрибутиве Linux и используется во многих приложениях.
Основные функции GnuPG таковы:

шифрование текста и файлов (используется несколько алгоритмов);

подписывание документов электронной цифровой подписью и проверка чужих подписей;

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

Конечно, используются только открытые и свободные системы шифрования, например, алгоритм IDEA не поддерживается ввиду того, что срок действия патента на него еще не истек (он действителен до 2007 года, но реализации алгоритма доступны уже сейчас, например: ftp://ftp.gnupg.dk/pub/contrib-dk/.
Следует отметить, что GnuPG исключительно консольная утилита и работает только с командной строки. Конечно, уже есть несколько графических оболочек для упрощения работы и доступно множество компонент для разных языков и сред программирования, но об этом мы расскажем в следующих статьях. GnuPG разработана для обеспечения совместимости с пакетом PGP - в большей части все сказанное о GnuPG, включая алгоритмы, команды и форматы файлов, можно применить и к пакету PGP.
В GnuPG используются разные криптографические алгоритмы: симметричные шифры, шифрование с открытым ключом и смешанные алгоритмы. Длина ключа в 1024 или 2048 бит достаточна для того, что бы вы могли спокойно доверить шифрованию свои секретные данные.
Основной особенностью является система ключей. В GnuPG вы создаете себе несколько ключей, причем каждый служит для отдельного действия (и использует разные алгоритмы). Один из ключей, создаваемые первым, является главным ключом, остальные подчиненными, подключами. Например, главный ключ используется только для подписи самых важных документов, имеет длину 1024 бит, алгоритм DSA, срок действия ключа не ограничен. Для шифрования документов вы создаете еще один или несколько подключей (например, для деловой и личной переписки), которые могут использоваться только для шифрования (алгоритмы ElGamal или RSA). Для этих ключей можно назначить срок использования, например, год или два.
Для первичного ключа можно (и надо) сгенерировать отзывающий сертификат (revokation certificate), который поможет уведомить ваших респондентов о том, что ваш ключ утерян или раскрыт и не может больше применятся, он с этого момента считается отозванным. В дальнейшем с помощью отозванного ключа можно проверять вашу подпись, но нельзя использовать для подписывания новых документов.
Описанная иерархия ключей изображена на рис.


К этой схеме надо дать пояснение. Изначально, при генерации набора ключей, создается пара из двух ключей: главного (алгоритм DSA, 1024 бит) который используется для подписи, и подключа для шифрования документа (ElGamal). Для ключей ElGamal длина может быть до 4096 бит, для остальных – по умолчанию 1024, а максимум 2048 бит.
Теперь давайте приступим к практической работе с GnuPG. Для запуска достаточно перейти в каталог и вызвать программу gpg. Краткий список наиболее важных команд будет дан ниже (как уже говорилось, GnuPG консольная утилита, поэтому все операции выполняются посредством команд из командной строки), сейчас мы воспользуемся командой для генерации нового ключа - --gen-key.

Сперва надо выбрать типы ключей (DSA или RSA), потом задать их длину и срок действия. Если выбирается генерация ключа с установками по умолчанию, то главный ключ DSA будет иметь длину 1024 бит, а для подчиненного ключа ElGamal длину можно выбрать произвольно. Далее в диалоговом режиме укажите свое имя и адрес email, а также пароль для защиты вашего закрытого ключа. В результате в списке ключей (программа ведет свою собственную базу ключей, куда заносятся открытые ключи ваших респондентов) появится новый ключ. GnuPG также поддерживает связь с открытыми серверами, на которых размещаются базы данных открытых ключей, ваш ключ можно туда экспортировать командой --send-keys.
В некоторых случаях вам может потребоваться ваш ключ (открытый или закрытый) в виде переносимого файла (его можно записать на носитель, к примеру USB flash-drive). GnuPG позволяет экспортировать ваши ключи или всю базу ключей в виде одного файла, в бинарном или текстовом виде (команда --export).
И так, вернемся назад к возможностям программы. Для работы с документами доступны несколько команд:

подписать документ;

зашифровать документ;

подписать и зашифровать документ;

Причем, выходной файл можно получить как в исходном виде, так и в чистом текстовом виде (ASCI) вне зависимости от природы исходного файла. К примеру, имеете файл с программой, он двоичный, шифруете и подписываете его, на выходе получаете текстовый файл. После расшифровки, естественно, файл восстанавливается. Это может пригодиться для сохранения зашифрованных файлов в таблицах СУБД.
Для примера приведем содержания зашифрованного и подписанного файла, а справа – в документ внедрена только цифровая подпись, сам текст документа открыт – такая подпись называется прозрачной – clearsign.
Кроме прозрачной подписи, GnuPG может создавать еще и отделённые подписи командой --detach-sign. Такая подпись сохраняется в отдельном файле с расширением *.asc и должна распространятся вместе с подписываемым документом. При проверке такой подписи необходимо указать полный путь к файлу подписи. При этом сам документ может быть как зашифрованным, так и полностью открытым.
Тут следует остановиться на методе шифрования файлов. Для этого GnuPG (и PGP) использует не чистый алгоритм с открытым ключом, а смешанный – для документа формируется уникальный сеансовый ключ, который шифруется шифром с открытым ключом, текст документа шифруется симметричным шифром на основе сеансового ключа. Получатель с помощью своего секретного ключа расшифровывает сначала сеансовый ключ, а потом с его помощью сам документ. Такая схема работает быстрее, чем шифрование с открытым ключом, а по надежности (криптостойкости) равна надежности самого слабого из алгоритмов. Конечно, теоретически, это позволяет упростить задачу дешифровки – вместо взлома системы шифрования с открытым ключом надо взломать только симметричный шифр, то есть подобрать сеансовый ключ. Но такой метод даст возможность расшифровать только одно сообщение, ведь для каждого документа сеансовый ключ генерируется отдельно. Для симметрического шифрования по умолчанию применяется алгоритм CAST5.
Кратко опишем основные команды GnuPG, которые могут понадобиться для повседневной работы. Весь список команд есть в справке и доступен при помощи команды gpg --help:

--gen-key – создание новой пары ключей. Команда –edit-key позволяет в последствии изменить параметры ключа.

--sign – создает подпись для указанных файлов, используя ключ (если не введен его идентификатор, использует ключ по-умолчанию). --detach-sign создаст подпись в отдельном файле, иначе создается совмещенная подпись.

--encrypt – указывает на то, что данные надо зашифровать. Если применяется совместно с –-sign то данные одновременно подписываются.

--symmetric – можно применять когда просто надо зашифровать файл (используется симметричный алгоритм, но можно выбрать алгоритм командой --cipher-algo).

--decrypt – расшифровывает указанные файлы и сохраняет результат в файл (если указан) или выводит в консоль. Если файлы содержат подпись, она также проверяется.

--verify – проверяет подписи для указанных файлов, не выводя содержимого файла.

--list-keys – выводит список всех открытых ключей. Команда --list-secret-keys показывает ваши секретные ключи.

--delete-key – удаляет открытый ключ из списка. --delete-secret-key удаляет секретный ключ (например, он скомпрометирован или окончился срок действия)

--export (--import) – экспорт/импорт ваших ключей, например, для резервирования или переноса на другой компьютер. По умолчанию ключи в бинарном виде, для получения их в ASCI-виде укажите параметр –armor.

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

Математика криптологии

В. Масол, д.ф-м.н,
Классическая криптология состоит из двух частей: криптографии - науки о засекречивании информации, и криптоанализа - науки о проникновении в засекреченные материалы. Если необходимость первой (криптографии) никогда не вызывала сомнений, то относительно второй составляющей время от времени возникали диспуты об этичности целей науки криптоанализа. Однако конкретные исторические события поставили точку в этих диспутах. Напомним об одном из них.
– Джентельмены не читают чужих писем,- заявил госсекретарь США Стимсон в 1929 г., узнав о том, что “черный кабинет” госдепартамента США занимался раскрытием шифрованных дипломатических телеграмм многих стран. Он немедленно упразднил упомянутый кабинет. Однако, являясь в 1940 г. военным министром, Стимсон заметно смягчился и простил раскрытие японских шифров (подробнее об этом и других исторических фактах см. В работе [1]).
Период до 1949 г. называют эпохой донаучной криптологии, поскольку достижения тех времен основаны в большей мере на интуиции и “вере”, не подкрепленных доказательствами. Последние впервые появились в публикации 1949 г. К. Шеннона [2]. Он доказал в ней, в частности, невозможность раскрытия случайного шифра Г. Вернама, введенного в работе [3], без знания секретного ключа.
В свою очередь, идеология криптографии с открытыми (несекретными) ключами впервые была изложена в 1976 г. У. Диффи и М. Хеллманом в работе [4]. В ней авторы показали, что секретная связь возможна без передачи секретного ключа между отправителем и получателем.
Благодаря ставшими уже классическими статьям [2 и 4], криптология состоялась как математическая наука.
К. Шеннон выделил в своей работе два общих принципа, используемых в практических шифрах: рассеивание и перемешивание. Достижение рассеивания и перемешивания осуществляется посредством реализации перестановок символов открытого текста, а также подстановок, заменяющих символы открытого текста на другие символы, из того же алфавита. Конкретный вид как перестановок, так и подстановок определяют секретные ключи. Один из примеров криптоалгоритма, разработанного в соответствии с указанными принципами К.Шеннона, является стандарт шифрования данных (DES), принятый в США в июле 1977 г. в качестве Федерального стандарта. В этом стандарте открытый текст Х, криптограмма Y и ключ Z -- двоичные последовательности длиной М = 64, N = 64 и K = 56 соответственно. Так как M = N, то DES является подстановкой в алфавите, содержащем 264 символов. Полное описание криптоалгоритма DES можно найти практически в любом учебнике по криптографии (например [5]), опубликованном после 1977 г.
С момента принятия Федерального стандарта DES и по сей день, он остается в центре внимания криптоаналитиков. Используемые при этом математические методы частично изложены в упоминавшейся ранее книге [5]. К ним А. Конхайм (автор книги [5]) относит методы теории вероятностей и математической статистики, линейной алгебры, теории групп и теории сложности. Более десяти лет стандарт DES оправдывал надежды его защитников. По состоянию на январь 1988 г. наиболее быстрый из известных вариантов криптоанализа этого стандарта предполагал выполнение 2K-1 процедур шифрования, т. е. практически предполагалось осуществление перебора всех вариантов. Первые сообщения о том, что теоретически возможно вскрыть стандарт DES за число операций, меньшее, чем 2K-1, появились в 1990 г., а соответствующие публикации в 1993 г. Так в работе [6] показано, что методом разностного криптоанализа перебор вариантов можно снизить до 247. Данный подход, как выяснилось со временем, был известен разработчикам стандарта DES. Однако противодействия этому методу, заложенные ими в криптосистему DES, при некоторых обстоятельствах, указанных авторами работы [6], удается обойти. Линейный криптографический анализ, предложенный в работе [7], основан на вероятностной оценке числа линейных соотношений между открытым текстом, шифртекстом и битами ключа, которые содержат информацию о ключе. Для успешной атаки на стандарт DES метод линейного криптоанализа требует 243 зашифрованных текстов (см. [7]).
Теоретические работы [6 и 7] послужили толчком к совершенствованию известных и созданию новых криптографических схем. Этот период в развитии криптографии нашел свое отображение в монографии [8], перевод которой на русский язык в настоящее время готовится в Издательском доме “Вильямс” (). В частности, в этой работе помещено детальное описание криптоалгоритма RC5, являющегося, по мнению специалистов, весьма удачным и таким, который после незначительных модификаций мог бы сменить стандарт DES.
Современные криптографические схемы являются более стойкими к разностному и линейному криптоанализу, чем стандарт DES. Однако физическая реализация многих существующих криптоалгоритмов (как с секретными, так и с открытыми ключами) оказалась уязвимой к атакам, предложенным в работе [9]. Эти атаки основаны на использовании специально подобранных шифртекстов с последующим замером времени расшифрования и потребленной при этом мощности. Оказывается, что мощность, идущая на зашифрование и расшифрование, зависит от проводимых операций и обрабатываемых данных.
В связи со сказанным более острым становится вопрос о том, что понимать под надежностью криптографического алгоритма. От чего в точности он защищает? Ответ на поставленный вопрос ищется, в частности, в рамках различных математических теорий. Принимая во внимание тот факт, что в большинстве случаев криптосистемы являются булевыми функциями, т. е. функциями, отображающими наборы из n битов в наборы из m битов, создатели указанных систем стремятся к тому, чтобы эти функции имели равномерно распределенный выход и тем самым “уничтожали” статистические закономерности открытого текста, обеспечивая, таким образом, криптосистеме надежность в теоретико-информационном смысле. В свою очередь, стандарт DES и возможные его приемники, к которым специалисты относят криптоалгоритмы RC6 (незначительная модификация упоминавшегося ранее RC5), MARS, Twofish, Serpent и Rijndael, считаются надежными в вычислительном смысле.
Различные толкования понятия надежности можно объяснить, обратившись к правилу для криптографов, сформулированному еще в XIX веке Керкхоффом (Kerckhoffs) в его книге “La Cryptographic militare”: криптоаналитику противника известен весь механизм шифрования, кроме значения секретного ключа. Для криптографа, придерживающегося этого правила, понятие надежности алгоритма становится, таким образом, динамически изменяющимся, зависящим от криптоаналитических возможностей противника в различные моменты времени.
Формирование понятия надежности, изобретение линейного криптоанализа в ответ на принятие стандарта DES -- все это может служить примерами проявления взаимосвязи двух составных частей криптологии. В свою очередь криптография с открытым ключом послужила толчком к раскрытию многих криптосистем. Чтобы объяснить это явление, обратимся снова к работе К. Шеннона [2]. В ней автор рекомендует конструировать такие шифры, чтобы раскрытие любого из них было эквивалентно решению задачи, о которой известно, что для ее решения требуется большой объем работы. Эта рекомендация помогла авторам работы [4] предложить криптографию, не использующую передачи секретного ключа. Их метод построен на применении односторонней функции и односторонней функции с потайным ходом. Определения и примеры этих функций, а также собственно алгоритм шифрования можно найти практически в каждом учебнике по криптографии, вышедшем после 1977 г., в частности [5, 8, 10, 11 и др. ]. Доказательство стойкости криптосистемы с открытым ключом могло бы состоять в обосновании того факта, что любой алгоритм раскрытия этой системы требует неприемлемо большого объема вычислений. Ни одна из систем с открытым ключом не удовлетворяет этому критерию стойкости. Хотя существуют такие криптосистемы, в отношении которых доказано, что их стойкость эквивалентна сложности решения задачи разложения целого числа n на простые множители. По мнению многих специалистов, указанная задача является крайне сложной для больших значений числа n. Вполне естественно, что поиски труднорешаемых математических задач могут привести к доказательству того, что задача, считавшаяся трудной и на этом основании использовавшаяся в криптоалгоритме, в действительности не является таковой и, следовательно, криптосистема, построенная на ней, вполне раскрываемая.
Ранее мы коснулись содержания учебников по криптографии, опубликованных после 1977 г. Для читателя, заинтересовавшегося данной тематикой, добавим к сказанному, что как учебники, так и справочные пособия по криптографии последних лет содержат, как правило, сведения о классическом шифровании с секретными ключами, о шифровании с открытыми ключами и о применениях криптографии. Различие между монографиями обусловлено различными научно-педагогическими интересами их авторов. Так, в работе [5] значительное место уделено математическим методам криптоанализа, в [11] - криптографии с открытыми ключами, в [8] - применениям криптографии (в частности, к безопасному общению в сети интернет), в [12] - программной реализации на языке Java алгоритмов криптографии с открытыми ключами и иллюстрациям их применения в задачах аутентификации информации, цифровой подписи и т. д.
Математические методы криптологии, их программно-алгоритмическая реализация и сферы приложений, освещенные в перечисленной учебно-справочной литературе, сохранят, по-видимому, свою актуальность в ближайшие десятилетия. Безусловно, она пополнится в случае смены криптоалгоритма DES описанием нового Федерального стандарта, расширенной подачей разностного и линейного криптографического анализа, исследованиями нелинейных булевых функций, наметившимися в работе [13].

Основы работы с OpenSSL

Автор: Vsevolod A. Stakhov/CEBKA
E-mail: VStakhov tehnopark org
Сайт:
OpenSSL — это система защиты и сертификации данных, название SSL переводится, как система безопасных сокетов (secure socket layer). OpenSSL используется практически всеми сетевыми серверами для защиты передаваемой информацией. Существует программное API SSL (SSLEAY), позволяющее создавать безопасные сокеты с шифрацией передаваемых данных в собственных разработках. Но в данной статье я бы хотел рассказать о самой системе OpenSSL, вызываемой через командную строку.
Т.к. OpenSSL поддерживает очень много различных стандартов сертификации, шифрования, хеширования, то использование данной команды достаточно сложно. Внутри OpenSSL существуют отдельные компоненты, отвечающие за то или иное действие, для получения списка доступных компонентов можно вызвать openssl с параметрами list-standart-commands. Можно также получить список доступных алгоритмов хеширования (list-message-digest-commands) и алгоритмов шифрования (list-cipher-commands).
OpenSSL может использоваться во множестве случаев и умеет выполнять следующие задачи:

Создавать и управлять ключами RSA и DSA — команды rsa, dsa, dsaparam.

Создавать сертификаты формата x509, запросы на сертификацию, восстановление — команды x509, req, verify, ca, crl, pks12, pks7.

Зашифровывать данные с помощью симметрического или асимметрического шифрования — команды enc, rsautl.

Высчитывать хеши различных типов — команда dgst.

Работа с S/MIME — команда s/mime.

Проверка работы серверов и клиентов ssl — команды s_client, s_server.

Cуществует также несколько вспомогательных утилит ssl:
— openssl speed [список_алгоритмов_хеширования_или шифрования]:
тестирование скорости различных алгоритмов, если запускать без параметров, то тестируются все алгоритмы; алгоритмы внутри списка разделяются пробелом, например: openssl speed md5 rsa idea blowfish des 3des sha1. В конце работы выводится общая скорость работы различных алгоритмов (в 1000-х байт в секунду), для обработки различной длины блоков. Вот результат работы тестов скорости на моем домашнем компьютере (Celeron 366), на других машинах значения будут другими:
Проверка алгоритмов асимметрического шифрования:
— openssl rand [-out file] [-rand file] num:
генерация num рандомных байт, можно использовать для проверки рандомизационной последовательности rand:
# openssl rand -rand .rnd 5
Wеб~
#

— openssl ciphers [-ssl2] [-ssl3] [-tls1] NAME: вывод доступных алгоритмов для обеспечения уровня безопасности NAME, где NAME — это символическое название группы алгоритмов. Обычно используются значения:

LOW — алгоритмы низкого уровня безопасности (<128 бит);

MEDIUM — алгоритмы среднего уровня стойкости (128 бит);

HIGH — алгоритмы высокой стойкости (>128 бит);

ALL — все алгоритмы;

NULL — алгоритмы без шифрования.

Обычно в настоящее время используются алгоритмы групп MEDIUM и HIGH, которые еще долго не смогут быть взломаны прямым перебором. Можно также вывести список алгоритмов из нескольких групп, разделив их «:» (например, MEDIUM:HIGH).

Теперь я бы хотел рассказать об основных утилитах openssl. Для начала о методах генерации ключей, затем о командах шифрования, и, наконец, о сертификатах, s/mime. Итак, пару слов о генерации ключей. Для создания rsa-ключей используется команда genrsa: openssl genrsa [-out file] [-des | -des3 | -idea] [-rand file] [bits]

Команда genrsa создает секретный ключ длиной bits в формате PEM, шифрует его одним из алгоритмов: des (56 бит), des3 (3-й des 168 бит) или idea (128 бит). При выборе алгоритма шифрования будет запрошен пароль для шифрации создаваемого секретного ключа (если алгоритм не указан, то секретный ключ не шифруется, чего делать ни в коем случае нельзя для личных ключей, т.к. некоторые серверы требуют отсутствие шифрации для сектетного ключа сервера). Опция -out говорит программе, что вывод нужно осуществлять не в stdout, а в файл file (опция -out присутствует во множестве других компонентов openssl и используется аналогичным образом для указания выходного файла). Опция -rand указывает на файл[ы] (разделенные «:»), из которых будут считываться данные для установки seed (зерна) генератора случайных чисел. В качестве таких файлов сразу же приходит на ум использовать что-то вроде /dev/random или /dev/urandom, но у меня с этим возникли проблемы: все вешалось наглухо, поэтому я рекомендую в этом случае использовать какие-нибудь сложно угадываемые файлы, вроде /var/log/messages или /boot/vmlinuz, думаю, что угадать содержимое этих файлов не намного проще, чем содержимое /dev/random, но работает этот фокус в любом *nix (опция -rand также присутствует во всех компонентах генерации и управления ключами и сертификатами). Использовать /dev/random и /dev/urandom, конечно, можно, но я для этого скопировал из /dev/random 32768 байт в файл .rnd таким образом: dd if=/dev/[u]random of=.rnd count=64


Кроме этого, можно указывать в качестве -rand-файла EGD-сокет, который обеспечивает генерацию определенного количества случайных байт, EGD доступен на узле http://www.lothar.com/tech/crypto/. Установка генератора случайных чисел производится на основании хеша -rand файла, поэтому можно указывать файлы различной длины, т.к. хеш все равно имеет фиксированное число бит. Пример генерации 4096 битового секретного ключа RSA: # openssl genrsa -out /etc/openssl/key.pem -des3
-rand /var/log/messages 4096 Generating RSA private key .....++*...++++++++* Enter PEM passphrase: Verify PEM passphrase:

После этого секретный ключ зашифровывается и записывается в файл (в текстовом виде). В начале ключа указывается алгоритм шифрования. Для создания публичного ключа rsa на основе секретного используется команда openssl rsa. Даная команда имеет следующий формат:

openssl rsa -in filename [-out file] [-des | -des3 |-idea] [-check] [-pubout]

Утилита openssl rsa способна изменять пароль и алгоритм шифрования секретного ключа, будучи вызвана с параметром -in и -out. Если применить параметр -pubout, то в указанный файл -out будет записан публичный ключ, вычисленный на основе -in секретного. Например, создание публичного ключа на основании секретного: openssl rsa -in /etc/openssl/key.pem
-out /etc/openssl/pubkey.pem -pubout

Изменение пароля и алгоритма шифрования секретного ключа с des3 на idea: openssl rsa -in /etc/openssl/key.pem -out /etc/openssl/key1.pem -idea

Для создания ключей DSA используется утилита openssl gendsa, аналогичная genrsa, но есть два отличия: во-первых, для ключей DSA нельзя прямо указывать длину в битах и, во-вторых, ключи DSA могут генерироваться согласно некоторым параметрам, записанным в файл paramfile утилитой openssl dsaparam. dsaparam имеет следующий формат:

openssl dsaparam [-rand file{s}] [-C] [-genkey] [-out file] numbits

где numbits — длина желаемого ключа, -С заставляет dsaparam вывести на stdout код на СИ для программной генерации DSA на основе необходимых параметров, а опция -genkey говорит, что в выходной файл, наряду с параметрами, дополнительно записывается созданный секретный ключ DSA, но нельзя его сразу же зашифровать, поэтому удобнее воспользоваться утилитой openssl gendsa, которая имеет схожий синтаксис с командой genrsa, но вместо числа бит указывается файл параметров, созданный dsaparam:

# openssl gendsa -out /etc/openssl/dsakey.pem -rand /boot/vmlinuz -idea paramfile


Enter PEM passphrase:

Verify PEM passphrase:

Для управления ключами dsa используется программа openssl dsa, которая абсолютно аналогична (в параметрах) утилите openssl rsa. Поэтому я просто приведу пример генерации публичного ключа DSA: # openssl dsa -in /etc/openssl/dsakey.pem
-out /etc/openssl/pubdsakey.pem -pubout

Теперь настало время рассказать о компонентах openssl, выполняющих шифрование и хеширование данных. Для выполнения симметрического шифрования используется утилита openssl enc -cipher или ее сокращенная запись openssl cipher, где cipher — это одно из символических имен симметрических шифров. Наиболее популярными являются следующие: base-64 (преобразование в текстовый вид), bf (blowfish — 128 бит), des (56 бит), des3 (168 бит), rc4 (128 бит), rc5 (128 бит), rc2 и idea (128 бит). Для указания входного и выходного файлов используется опции -in и -out соответственно. Пароль для шифрования вводится с клавиатуры (можно указать в командной строке параметром -k, но это очень плохо по соображениям безопасности, т.к. большинство шеллов умеют сохранять историю командной строки, IMHO намного лучше ввести пароль непосредственно перед шифрованием, хотя эта опция полезна для скриптов, так что забывать о ней нельзя :). Учтите, что пароль не спрашивается при обработке файла base64, т.к. шифрования не происходит. Для расшифровки зашифрованных данных примените openssl cipher с опцией -d (алгоритм шифрования и дешифрования должен совпадать!), а для одновременной обработки данных base64 можно воспользоваться опцией -a. Шифрование по умолчанию происходит с подмешиванием, т.е. для выбора алгоритма подмешивания используется случайная соль (salt), в этом случае, если вы шифруете один и тот же файл в разное время одним и тем же алгоритмом и паролем, то результаты скорее всего будут разными (это затрудняет атаку по словарю). Также по умолчанию используется cbc-режим алгоритмов, когда ключ меняется в течение всего сеанса работы согласно передаваемым данным, этот прием очень сильно затрудняет брутфорс, т.к. атакующему сложно поймать нужный момент времени. Приведу несколько примеров:

* зашифруем файл, используя алгоритм des3
# openssl des3 -in file -out file.des3
* расшифруем полученный файл
# openssl des3 -d -in file.des3 -out file
* зашифруем файл, используя алгоритм blowfish(bf), и


* закодируем base64
# openssl bf -a -in file -out file.bf64
* теперь расшифруем его и обработаем сразу же base64
# openssl bf -a -d -in file.bf64 -out file

Для вычисления хешей ( их еще называют отпечатками или контрольными суммами) используется команда openssl dgst -hashalg или краткая форма openssl hashalg (первая команда может также выполнять манипуляции с ЭЦП, но об этом далее). Обычное использование данной команды таково:

openssl hashalg [-c] file[s]

Вычисляется хеш-сообщения фиксированной длины в виде одной строки или, если указана опция -c, строки, разделенной на пары HEX-чисел двоеточием. Из алгоритмов хеширования могут применяться следующие: md2 (128 бит), md4(128 бит), md5 (128 бит), mdc2 (128 бит), sha (160 бит), sha1 (160 бит), ripemd160 (160 бит). Опять же приведу пару примеров:

* вычислим md5-хеш файла:
# openssl md5 -c file
MD5(file)= 81:fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94
* а теперь SHA1-хеш этого же файла:
# openssl sha1 file
SHA1(file)= 13f2b3abd8a7add2f3025d89593a0327a8eb83af

Как я уже говорил, утилита openssl dgst может использоваться для подписывания сообщения секретным ключом и проверки ЭЦП публичным ключом. Для этого используется следующий синтаксис:

openssl dgst -sign private_key -out signature -hashalg file[s]

Подписывание file с помощью секретного ключа "private_key", используя алгоритм хеширования "hasalg" (обычно применяются sha1 или md5). openssl dgst -signature signature -verify public_key file[s]

Проверка подписи в "file", используя публичный ключ "public_key" и ЭЦП "signature". Данная программа выводит «Verification OK» при правильной подписи или «Verification Failure» в любом другом случае. Учтите, что ЭЦП в таком случае хранится отдельно от файла, который ею подписан (причем в каком-то кривом формате).

Для шифрации и дешифрации RSA алгоритмом используется программа rsautl. Данная утилита имеет также возможность подписывать и проверять подпись сообщений (однако работать все равно приходится с хешем сообщения, т.к. подписывать можно только небольшой объем данных, по этой причине лучше применять openssl dgst). Для шифрации/дешифрации используется следующий синтаксис:

openssl rsautl -in file -out file.cr -keyin pubkey.pem -pubin -encrypt


(Шифрация "file" с использованием публичного ключа "pubkey.pem")

openssl rsautl -in file.cr -out file -keyin secretkey.pem -decrypt

(Дешифрация "file.cr" с использованием секретного ключа "secretkey.pem")

Теперь настало время рассказать об одном из главных применений openssl — управление сертификатами. Openssl имеет возможность генерировать сертификаты, управлять ЭЦП и шифрацией с помощью сертификатов. Однако применение утилит управления сертификатами — достаточно сложная задача. Поэтому для начала я дам общие представления о сертификатах. Сертификат содержит публичный ключ, подписанный одним из корневых доверенных центров сертификации (или комплементарным секретным ключом), данные об организации, выдавшей сертификат и в некоторых случаях зашифрованный секретный ключ, а также отпечаток (хеш) публичного ключа. Сертификаты имеют время действия, по окончанию которого они автоматически считаются недействительными, иерархия сертификатов обычно строится на основании сети доверия (бывают довольно длинные цепочки сертификатов, ведущие к доверенному ключу из root CA). Таким образом, сертификат — это полный комплекс системы асимметрического шифрования, предоставляющий гораздо больше возможностей, чем сами по себе ключи (а также являющийся более защищенной системой). Основным привлекательным моментом сертификата является возможность записи в него информации об организации, этот ключ выдавшей. Таким образом явно напрашивается применение собственной системы сертификации в данной организации. Можно, например, выдавать сотрудникам их персональные сертификаты, подписанные сертификатом организации (его можно сгенерировать самому или получить от сторонней компании). Причем эти сертификаты впоследствии можно использовать для удостоверения личности сотрудника, например, при почтовой переписке или аутентификации на http-сервере (apache+ssl). Единственное условие, которое должно выполняться, — это наличие на машине клиента сертификата организации в списке корневых доверенных ключей. Общее содержание сертификатов определено стандартом x509, в то время как форматы записей сертификатов могут внести некоторую путаницу. Openssl по умолчанию использует формат PKCS#10, Microsoft использует по умолчанию формат PKCS#12 (в руководстве по openssl этот формат охарактеризован, как один большой баг :), формат PKCS#7 используется для запросов на сертификацию к CA (центр сертификации) и не может содержать секретного ключа, также для этой цели может использоваться DER-закодированный сертификат (DER-кодирование подобно кодированию base64, но имеет специальное назначение для использования в криптографических системах) также без секретного ключа. Учтите, что при использовании DER-формата убираются маркеры начала и конца сертификата, а его содержимое кодируется base64, поэтому в файле DER можно хранить только один сертификат, с другой стороны DER сертификаты поддерживаются M$ (стандартное расширение .cer), поэтому иногда бывает нужно преобразовать сертификаты из одного формата в другой (я здесь имею ввиду PEM или DER): PEM-->DER openssl x509 -inform PEM -in cert.pem
-outform DER -out cert.cer DER-->PEM openssl x509 -inform DER -in cert.cer
-outform PEM -out cert.pem


Таким же образом можно конвертировать и ключи асимметрического шифрования (используя утилиты rsa или dsa).

Думаю, что не сильно запутал вас всеми этими стандартами. Если объяснять на пальцах, то все выглядит следующим образом: клиент создает сертификат и отправляет свой публичный сертификат (PKCS#7) в центр сертификации. В центре сертификации обрабатывается запрос клиента (запрос на сертификацию), и сертификат клиента подписывается секретным ключом центра сертификации. Клиент, имея публичный ключ центра сертификации, проверяет подлинность подписи и может далее использовать свой сертификат. Для организации можно предложить следующее решение: на сервере создается сертификат организации; генерируется запрос на сертификацию и отправляется к некоему доверенному центру сертификации (который будет известен всем клиентам и персоналу данной организации); получается сертификат организации, который можно использовать при создании сертификатов клиентов. Последние создаются так: клиент посылает запрос на выдачу сертификата; сервер создает сертификат клиента и подписывает его сертификатом организации; клиент получает сертификат клиента и сертификат организации; после проверки достоверности ключа организации (предполагается, что клиент доверяет CA, которым был подписан сертификат организации) проверяется достоверность сертификата клиента. После такой операции клиент будет точно уверен, что получил сертификат от данной организации, и может его использовать для работы с ней. По такой схеме построены все центры выдачи сертификатов(правда зачастую сертификат организации бывает подписан самим собой, что требует от клиента добавить сертификат организации к доверенным, а в первой схеме сертификат организации принадлежит к группе промежуточных центров сертификации, и этот случай предпочтительнее с точки зрения безопасности и удобства клиента, но требует больше работы от администратора). Да, хорошенькое объяснение на пальцах! Но что тут поделать: сертификаты — это довольно запутанная вещь. Сейчас я объясню, как создавать сертификаты с помощью openssl, и приведу пример только что описанного безобразия…

Для создания сертификата используется инструмент openssl req. Он имеет довольно много параметров, поэтому, чтобы не парить мозги, я просто приведу пару примеров его использования. Для начала требуется конфигурационный файл, который имеет следующий формат(все строки, начинающиеся с # — это мои комментарии, в конечном файле их может и не быть):

[ req ]
# Секция основных опций
default_bits = 2048
# Число бит
default_keyfile = keyfile.pem
# Имя ключа, используемого для сертификата
distinguished_name = req_distinguished_name
# DN организации, выдавшей сертификат
prompt = no
# Брать параметры из конфига неинтерактивный режим
[ req_distinguished_name ]
# DN организации
CN=RU
# Страна
ST=Ivanovskaya
# Область
L=Gadukino
# Город
O=Krutie parni
# Название организации
OU=Sysopka
# Название отделения
CN=Your personal certificate
# Имя для сертификата (персоны, получающей сертификат)
emailAddress=certificate@gaduk.ru
# Мыло организации


Если не указывать prompt no, то значения для параметров будут считаны в интерактивном режиме (то бишь с клавиатуры), а значения параметров будут являться подсказками при вводе данных. При интерактивном режиме можно указывать значения по умолчанию, а также минимальное и максимальное значения для параметров (для строковых параметров устанавливается ограничение на длину). В таком случае общий формат параметра таков:

имя = подсказка
имя_default = значение_по_умолчанию
имя_max = максимум
имя_min = минимум

Пример интерактивного файла конфигурации:

[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name

[ req_distinguished_name ]

countryName = Country Name (2 letter code)

countryName_default = RU

countryName_min = 2

countryName_max = 2

localityName = Locality Name (eg, city)

organizationName = Organization Name(eg, org)

organizationalUnitName = Organizational Unit Name (eg, section)

commonName = Common Name (eg, YOUR name)

commonName_max = 64

emailAddress = Email Address

emailAddress_max = 40

Спешу обрадовать некоторых ленивых товарищей: если вы намереваетесь создавать просто сертификат сервера (например, для LDAP-сервера), то указывать конфиг необязательно, будет использоваться конфиг по умолчанию /usr/lib/ssl/openssl.cnf, который содержит все необходимое. Ну а теперь традиционно приведу примеры использования openssl req(я не собираюсь подробно описывать данную команду, т.к. думаю, что для большинства случаев хватит примеров, а для особых случаев можно почитать man req).

openssl req -new -newkey rsa:2048 -keyout rsa_key.pem -config cfg -out certreq.pem

Создание запроса на сертификацию (-new) на основе создаваемого секретного ключа rsa (-newkey rsa:2048), который записывается в файл -keyout(и шифруется тройным DES). Запрос на сертификацию создается на основе конфигурационного файла — config. openssl req -x509 -new -key private_key.pem -config cfg -out selfcert.pem -days 365

Создание (-new) self-signed сертификата (-x509) для использования в качестве сертификата сервера или сертификата CA. Сертификат создается с использованием секретного ключа -key и конфигурационного файла -config. Создаваемый сертификат будет действителен в течение 365 дней (-days), опция -days не применима к запросам на сертификацию.

Для управления сертификатами x509 используется утилита openssl x509. С ее помощью можно подписать сертификат или запрос на сертификацию сертификатом CA. Также можно просмотреть содержимое сертификата в читаемой форме (DN, публичный ключ, время действия, отпечаток и.т.д.). Приведу примеры вышеописанных действий:

openssl x509 -in cert.pem -noout -text


Просмотреть информацию о сертификате в «нормальной» форме. Вот что примерно будет выведено, также можно использовать дополнительные опции: -fingerprint (необходимо сочетать с одной из опций -sha1, -md5 или -mdc2), -modulus (вывод публичного ключа), -serial, -subject, -issuer (организация, выдавшая сертификат), -email, -startdate, -enddate:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=RU, ST=region, L=city, O=organization, OU=Sysopka,CN=CEBKA/Email=CEBKA@smtp.ru
Validity
Not Before: Nov 9 08:51:03 2002 GMT
Not After : Nov 9 08:51:03 2003 GMT
Subject: C=RU, ST=region, L=city, O=organization, OU=Sysopka,CN=CEBKA/Email=CEBKA@smtp.ru
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c6:6b:3b:8e:f8:33:05:a0:dc:e1:38:8f:6a:68:
42:1c:21:33:aa:90:b6:8c:93:14:11:9b:69:94:8a:
3a:0e:42:29:b0:45:14:1b:f0:37:2c:f3:05:db:13:
06:a9:cd:eb:99:31:51:25:86:c8:69:e0:5e:8d:28:
04:8d:1f:08:37:d7:72:39:fe:05:57:61:68:95:bf:
5c:ae:13:f2:05:a1:29:c3:bf:3b:32:ca:1a:ff:22:
53:f9:32:92:78:fe:44:c3:e1:ca:42:5c:5f:d1:49:
da:1c:9f:34:06:04:ee:46:74:8d:11:68:ef:37:e2:
74:1e:d9:46:04:b8:7e:d5:c5
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
3b:42:85:45:08:95:f3:f1:fc:8a:23:88:58:0e:be:e5:9b:56:
1e:c1:ff:39:28:4f:84:19:f8:3e:38:ef:98:34:d6:ee:e0:0a:
de:36:3a:5c:15:88:d7:2a:a4:0a:d5:dc:3e:b2:72:4c:82:57:
b8:fe:52:f6:e2:06:01:38:eb:00:0b:f2:a9:87:be:65:83:19:
13:50:ae:6c:f2:0a:07:14:e6:8c:60:cd:c5:a3:d1:e1:ea:da:
24:c2:6a:06:d5:dc:1c:71:c9:64:fa:9e:c9:ca:97:e2:06:84:
de:4c:69:b8:9a:af:66:14:8d:46:9a:00:53:13:c9:ab:10:b8:
09:c2

openssl x509 -req -in clientreq.pem -extfile /usr/lib/ssl/openssl.cnf \ -extensions /usr/lib/ssl/openssl.cnf -CA CAcert.pem
-CAkey serverkey.pem \ -CAcreateserial -out clientcert.pem

Подписать запрос на сертификацию (-req) файла -in, используя доверенный CA сертификат -CA и его секретный ключ -CAkey. В конечный сертификат клиента (-out), записываются дополнительные параметры сертификата 3-й версии из файла /usr/lib/ssl/openssl.cnf (конфигурационный файл по умолчанию). Но об этом я расскажу после на конкретном примере. Такое поведение x509 позволяет организовать свой центр сертификации, подписывающий запросы клиентов на сертификацию. openssl x509 -in CAcert.pem -addtrust sslclient -alias "myorganization CA" \ -out CAtrust.pem


Преобразование сертификата -in в доверенный сертификат для использования в SSL-клиентах (sslserver — использование в качестве сертификата сервера, emailProtection — использование в качестве сертификата S/MIME).

Я еще раз хотел бы вернуться к проблеме построения CA. Для использования внутри организации можно использовать self-signed сертификат, но для использования CA вне организации приходится использовать сертификаты, выданные или подписанные сторонней организацией. Во втором случае возникает проблема выбора такой сторонней организации (она легко разрешается для дочерних компаний), которая требует юридического анализа (в разных странах существуют свои законы криптографии и поэтому дать какой-либо конкретный совет я не могу). Если вам довелось работать в российской правительственной компании, то считайте, что вам не повезло — использовать openssl для работы с правительственными организациями нельзя. Наши уважаемые гос. деятели добавили геморроя админам, разрешив использовать только алгоритмы ГОСТ (симметрические, асимметрические, хеширования — меня просто выворачивает от самого этого слова ГОСТ ;), поэтому использовать вам придется только специальные программы, реализующие эти алгоритмы. Я же приведу здесь пример построение собственного CA с self-signed сертификатом:

1) Генерируем секретный ключ:

openssl genrsa -out CAkey.pem -rand randfile -des3 4096

2) Создаем self-signed сертификат:

openssl req -new -x509 -key CAkey.pem -out CAcert.pem -days 365 -config cfg

Содержимое конфигурационного файла зависит от организации, можно даже воспользоваться утилитой /usr/lib/ssl/misc/CA.pl -newcert, которая создаст ключ и сертификат в одном файле в интерактивном режиме (хотя мне этот вариант не очень понравился, лучше один раз написать нормальный конфиг) — о дополнительных требованиях к конфигурации CA сертификата см. ниже.

3) Приведу пример скрипта, генерирующего клиентские сертификаты:

#!/bin/bash

dd if=/dev/random of=/tmp/.rnd count=64

RAND="/var/log/messages:/boot/vmlinuz:/tmp/.rnd"


REQ="openssl req"

X509="openssl x509"

RSA="openssl rsa"

GENRSA="openssl genrsa"

O="company"

C="RU"

ST="region"

L="city"

PURPOSES="digitalSignature, keyEncipherment"

CERTTYPE="client, email, objsign"

CA="/etc/openssl/CAcert.pem"

CAkey="/etc/openssl/CAkey.pem"

OUTDIR="/etc/openssl/clientcert/"

CN="client"
BITS=2048
DAYS=365

# Создаем секретный ключ во временной папке БЕЗ шифрования

TMP="/tmp/ssl-$$"
mkdir $TMP

if [ ! -d $OUTDIR ];then
mkdir $OUTDIR
fi


pushd $TMP > /dev/null
$GENRSA -rand $RAND -out tmp.key $BITS

# Создаем конфиг для клиента

cat > cfg <

[ req ]
default_bits = $BITS
distinguished_name = req_DN
extensions = v3_req
[ req_DN ]
countryName = "1. Country Name (2 letter code)"
countryName_default = "$C"
countryName_min = 2
countryName_max = 2
stateOrProvinceName = "2. State or Province Name (full name) "
stateOrProvinceName_default = "$ST"
localityName = "3. Locality Name (eg, city) "
localityName_default = "$L"
0.organizationName = "4. Organization Name (eg, company) "
0.organizationName_default = "$O"
organizationalUnitName = "5. Organizational Unit Name (eg, section) "
organizationalUnitName_default = "$OU"
commonName = "6. Common Name (eg, CA name) "
commonName_max = 64
commonName_default = "$CN"
emailAddress = "7. Email Address (eg, name@FQDN)"
emailAddress_max = 40
emailAddress_default = ""
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = $PURPOSES
nsCertType = $CERTTYPE
EOT
# Создаем запрос на сертификацию
$REQ -new -key tmp.key -config cfg -rand $RAND -out $CN.pem

# Этот файл лучше удалить побыстрее: мало ли чего...
rm -fr /tmp/.rnd

if [ $? -ne 0 ]; then
echo "Failed to make a certificate due to error: $?"
popd > /dev/null
rm -fr $TMP
exit $?
fi
# Подписываем сертификат сертификатом сервера

$X509 -req -in $CN.pem -CA $CA -CAkey $CAkey -CAsetserial \
-extensions -config cfg -days $DAYS -out $OUTDIR$CN.pem

chmod 0400 $OUTDIR$CN.pem
chown root:root $OUTDIR$CN.pem
# Шифруем секретный ключ
$RSA -in tmp.key -des3 -out $OUTDIR$CN-key.pem

chmod 0400 $OUTDIR$CN-key.pem
chown root:root $OUTDIR$CN-key.pem
# Выполняем заключительные действия
popd > /dev/null

rm -fr $TMP

echo -e "Generation complete, go to $OUTDIR and give to client $CN his certificate and \
\n private key (for windows users you should use openssl pkcs12 utility)"


Дополнительные свойства, описанные в скрипте (v3_req), означают, что клиент может использовать сертификат для подписывания и шифрации, но его сертификат не является CA сертификатом. Для CA-сертификата значение basicConstraits должно быть равно CA:TRUE (об этом забывать нельзя!). Поле nsCertType определяет дополнительные назначения данного ключа (для использования в качестве клиента, подписывания, использования в почтовых сообщениях). Для CA-сертификатов обычно применяют следующие значения nsCertType: sslCA, emailCA. Для ssl-ключей серверов (например, Apache) используется значение nsCertType = server. Полученный таким образом сертификат клиента будет содержать информацию о поставщике сертификата (то есть о вашем сертификате организации). Клиенту необходимо будет передать его сертификат, его секретный ключ (зашифрованный!) и ваш сертификат организации. Для клиентов Micro$oft необходимо еще и перевести сертификаты в формат PKCS#12. Для этого воспользуемся командой openssl pkcs12: openssl pkcs12 -export -in client.pem
-inkey client-key.pem -out client.p12 \ -name "Client certificate from our organization"

Для обратного преобразования используется синтаксис:

openssl pkcs12 -in client.p12 -out client.pem

В выходной файл записываются сертификат клиента, ca сертификат, секретный ключ клиента (его можно зашифровать опцией -des3, -idea и.т.д.). Такое поведение позволяет использовать для вывода только формат pem (маркеры здесь обязательны!). Для экспорта сертификата организации можно воспользоваться командой pkcs12 (конечно же, без параметра inkey ;), можно также обработать сертификат организации base64 и сохранить в файле .cer (openssl x509 -in CA.pem -outform DER -out CA.cer).

В openssl существует компонент управления s/mime-сообщениями, называющийся openssl smime. Данная утилита позволяет зашифровывать, расшифровывать, управлять ЭЦП и MIME-заголовками писем. Приведу опять же несколько примеров ее использования:

openssl smime -sign -in mail.txt -text -from CEBKA@smtp.ru -to \


user@mail.ru -subject "Signed message" -signer mycert.pem -inkey \
private_key.pem | sendmail user@mail.ru

Подписывает сообщение -in (в текстовом виде) и подписывает (-sign) его с помощью сертификата (-signer) и секретного ключа (-inkey). Вывод идет непосредственно к sendmail, для этого определены MIME-заголовки from, to и subject.

openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt

Проверяет подпись в файле -in, записывает сообщение в файл -out, а полученный сертификат — в файл -signer (для проверки s/mime-сообщения не требуется ничего, кроме него самого, т.к. ЭЦП s/mime содержит публичный ключ!). openssl smime -encrypt -in mail.txt -from CEBKA@smtp.ru
-to user@mail.ru \ -subject "Encrypted message" -des3 user.pem | sendmail \ user@mail.ru

Шифрация файла -in с помощью сертификата получателя "user.pem", используя алгоритм "des3". Вывод программы посылается непосредственно в sendmail. openssl smime -decrypt -in mail.msg -recip mycert.pem -inkey private_key.pem \ -out mail.txt

Расшифровка файла -in с помощью секретного ключа -inkey и сертификата -recip (ваш собственный сертификат).

Есть альтернатива не указывать smime-заголовки from, to и subject. Можно просто указать необходимый файл -out и добавить заголовки с помощью программы sendmail вручную. Кроме этого, есть еще одна деталь использования smime: некоторые почтовые клиенты используют в качестве подписи вложение в формате PKCS#7 (чаще всего закодированное base64). В таком случае необходимо применять smime следующим образом: openssl smime -verify -inform [PEM | DER]
-in signature.pem[der] -content \ mail.txt

PEM используется для стандартного формата PKCS#7, а DER заставляет произвести дополнительную обработку base64. Учтите, что в данном случае файл -in представляет собой только подпись (аттачмент), а -content — непосредственно текст письма. Можно также заставить smime подписывать сообщения подобным образом, если указать опцию -pk7out (PEM формат). Для преобразования PKCS#7 структуры из формата PEM в формат DER можно воспользоваться утилитой openssl base64 (обратное преобразование достигается за счет использования опции -d).

Итак, думаю, что для большинства операций с использованием SSL этого будет достаточно.

Доступ через сеть

Обе технологии рассчитаны на работу в незащищенных сетях, работающих по протоколу IP. Однако различие в возможностях этой работы очень существенны. Благодаря наличию системы сертификатов PKI может реализовать взаимодействие в сетях по протоколам HTTPS и (в том числе к почтовому серверу Microsoft Exchange Server, веб-сервисам на базе MicrosoftIIS), в то время как область применения PGP - это фактически только электронная почта.

Программы шифрования данных особенно полезны именно при работе в незащищенных сетях. Даже в случае использования незащищенного HTTP с помощью программ шифрования можно организовать обмен зашифрованными документами через онлайновые хранилища данных. Пользователь может зашифровать документы любым доступным встроенным криптопровайдером, поместить зашифрованный файл в хранилище и дать ссылку на скачивание своему корреспонденту. В системе PGP в этом варианте обмена не возникает вообще никаких проблем, в системе PKI необходимо, чтобы пользователи пользовались одинаковыми криптопровайдерами. Для официального документооборота необходимо в этом случае еще и использование сертифицированных российских СКЗИ. Ведущими средствами криптографической защиты информации на российском рынке программных средств сегодня являются от компании "Крипто-Про", - "Сигнал-КОМ", - "МО ПНИЭИ".

PKI или PGP?

,
Обеспечение безопасного обмена информацией в современных электронных системах реализуется разными способами. Наиболее широкое распространение получили системы на основе открытых ключей: PGP и PKI. Подтверждение личности или сообщения - основное предназначение описываемых систем - реализуется с помощью связки цифровых кодов (или сертификатов): ЭЦП, открытого и закрытого ключей. Это общее для обеих систем. Главной особенностью , в отличие от , является наличие компонентов, известных как и . Благодаря им возможно подтверждение подлинности личности сторонними уполномоченными организациями.
Наличие ЦС и ЦР обусловило то, что в системе PKI доминирующим направлением подтверждения подлинности является вертикальная (иерархическая) составляющая, когда сертификат подтверждается кем-то, имеющим более высокий статус. В системе PGP основной является горизонтальная составляющая или, другими словами, схема "прямого доверия". Хотя и в той, и в другой системе возможно как вертикальное, так и горизонтальное подтверждение подлинности. Образно можно представить, что в PKI доверие распространяется в виде дерева, а в PGP - в виде сети.

Различия в стандартах

В основу PGP положен стандарт , который содержит:

сведения о владельце сертификата;

открытый ключ владельца сертификата;

ЭЦП владельца сертификата;

период действия сертификата;

предпочтительный алгоритм шифрования.

В основу PKI положен стандарт Х.509, который содержит:

открытый ключ владельца сертификата;

серийный номер сертификата;

уникальное имя владельца;

период действия сертификата;

уникальное имя издателя;

ЭЦП издателя и идентификатор алгоритма подписи.

Несмотря на наличие множества версий формата Х.509, существует ряд фундаментальных различий между форматами сертификатов Х.509 и PGP:

сертификат PGP создается только лично (самоподписанный сертификат), сертификат Х.509 может получаться от центра сертификации, а также быть самоподписанным;

сертификат Х.509 содержит только одно имя владельца сертификата;

сертификат Х.509 содержит только одну ЭЦП, подтверждающую подлинность сертификата.

Так что же лучше?

PGP и PKI - это две похожие, но все же разные системы. Первая предназначена для неструктурированного (или слабо структурированного) защищенного обмена данными. Даже применение программ, созданных для крупных корпоративных клиентов, не делает систему в целом стройной и понятной. PKI обеспечивает обмен зашифрованными данными как на локальном, так и на межсетевом уровне с достаточной степенью защищенности и достоверности. В настоящее время технология PGP развивается в сторону совместимости с PKI. Однако действующий опыт показывает, что на рынке отдается большее предпочтение технологии PKI.
При этом необходимо помнить, что приобретение одних только программ шифрования на основе стандарта Х.509 не создает в полной мере саму инфраструктуру PKI. Необходимо использовать сертифицированные для РФ криптопровайдеры, а также обеспечить взаимодействие с официальными российскими ЦС.
Ссылки по теме:

document.write('');

Новости мира IT:

02.08 -

02.08 -

02.08 -

02.08 -

02.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

31.07 -

31.07 -

31.07 -

31.07 -

31.07 -

Архив новостей
Последние комментарии:
(66)

2 Август, 17:53
(19)

2 Август, 17:51
(34)

2 Август, 15:40
(42)

2 Август, 15:35
(1)

2 Август, 14:54
(3)

2 Август, 14:34
(3)

2 Август, 14:15
(2)

2 Август, 13:34
(7)

2 Август, 13:04
(3)

2 Август, 12:28

BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!
Loading
google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг

Software Engineering

Программирование

СУБД

Безопасность

Internet

Сети

Операционные системы

Hardware

<

VPN

Для организации частных виртуальных сетей обе технологии PGP и PKI подходят в одинаковой степени, так как основное отличие таких сетей от открытых - использование специального протокола IPSec. Однако и здесь надо учитывать преимущественные возможности PKI в плане использования сертификатов, выданных внешними ЦС.

Who is who?

Все версии программы PGP (даже корпоративные, способные обслуживать от 25 до 50000 пользователей) не рассчитаны на получение сертификатов от сторонних ЦС. Просто потому, что этого не допускает используемый ими протокол OpenPGP. Это не плохо и не хорошо. Дело в том, что система PGP изначально создавалась под потребности в основном частных пользователей и предназначена в основном для работы с электронной почтой. Имея дело с PGP-сертификатом, каждый пользователь может выступать в качестве заверителя содержащихся в нем сведений (за исключением случаев, когда эта возможность намеренно ограничена политикой безопасности). В последующем PGP стали приспосабливать под потребности защиты электронного документооборота. Все бы хорошо, но возникает проблема доверия сторонним корреспондентам. Что толку от заверений сертификата пользователя, который прислал вам письмо, если вы не знакомы и не доверяете никому из подписавших полученный вами сертификат?

Система PGP вполне может выступить удачным решением для внутрикорпоративных целей, когда заверителем сертификата является уполномоченное администрацией компании лицо. Но, отправляя документы во внешний мир, вы должны подтверждать свою личность отправителя. Аналогично и в случае с получением корреспонденции: вы должны быть уверены в том, что сообщение отправлено именно тем, кто назвался отправителем. Для юридически правильного документооборота в этом случае необходимо заверение подлинности сертификата сторонней уполномоченной организацией. Такую возможность может предоставить только протокол Х.509, на основе которого и построена PKI.
Но проблема аутентификации не сводится только к определению авторства послания. С помощью PKI можно организовать систему доступа к данным, например с помощью ключей, размещенных на внешних носителях (). Правда, надо учесть, что не все стандартные криптопровайдеры операционной системы Windows поддерживают размещение ключей на внешних носителях.

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

Задачи, решаемые PGP и PKI

Обе эти технологии используются для следующих целей:

обеспечение механизма строгой аутентификации;

организация защищенного обмена электронной почтой;

организация виртуальных частных сетей (VPN) для защищенных соединений удаленных пользователей и филиальных сетей организации;

организация защищенных порталов (доступ через Интернет), систем разграничения доступа к сайтам, порталам и приложениям.

Рассмотрим работу систем PGP и PKI.

Защита файлов и документов

Задача криптографической защиты электронных почтовых сообщений, файлов и документов сводится к шифрованию данных. И PGP, и российские программные продукты, реализующие логику PKI, позволяют шифровать информацию. Для частной переписки этих мер безопасности может быть вполне достаточно, но для работы государственных и коммерческих организаций этих возможностей недостаточно. Прежде всего потому, что PGP не работает с российскими стандартами, а значит, не отвечает ни необходимому уровню безопасности, ни существующим . Работу с сертифицированными криптографическими алгоритмами поддерживают такие отечественные программы, как (компания "Информзащита"), (компания Digt), (ООО "Газинформсервис"), и ("Сигнал-КОМ").

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

Алгоритм декодирования ресурсов из PWL-файла с правильным паролем

После нахождения правильного пароля прогоняем функцию XorT с индексами не 1...33, а 33...63. Таким образом мы декодируем 15 адресов блоков с ресурсами. Должны получиться значения типа 0x292, 0x294 и т.д. Как мы помним, адрес 1-го блока всегда равен 0x290. Таким образом, у нас будет массив Res[17] типа WORD, в первое значение - 0x290, далее 15 декодированных адресов, а последний WORD - это размер файла (в примере выше это будет значение 0x2DC).

Далее следует цикл на 16 (проверка блоков с ресурсами), в начале его вычисляем разницу между соседними адресами N - если разница между ними равна 2, то переход на следующий адрес.

Если N > 2, то данный i-й блок содержит ресурсы.

Формируем новый массив X (размером 64 байта) следующим образом:

0xFFFFFFFF (DWORD)

Логин в верхнем регистре

0x0 (1 байт)

CryptoSeed[i] (DWORD) - это значение берем из массива по адресу 0x20C, причем i - это номер блока ресурсов.

0x80 (1 байт)

0x0 (по адрес 0x37 включительно)

По адресу 0x38 записываем (0x48 + (длина логина << 3)) (DWORD)

0x0 (до конца массива)

Выполняем MD5 (массив X), получаем массив Cnt (16 байт), т.е. производим свертку логина с нужным CryptoSeed.

Формируем массив Z (размером 64 байта) следующим образом:

Пароль

0x0 (1 байт)

Cnt (16 байт)

0x80 (1 байт)

0x0 (по адрес 0x37 включительно)

По адресу 0x38 записываем (0x88 + (длина пароля << 3)) (DWORD)

0x0 (до конца массива)

Выполняем MD5 (массив Z), получаем массив Key (16 байт), т.е. производим свертку пароля.

Выполняем RC4, используя в качестве ключа Key.

И теперь полученным массивом M начинаем декодировать весь блок с ресурсами длиной N процедурой, аналогичной XorT. Причем начинаем использовать массив M также с 1-го значения (не с нулевого(!)) до 255, если ресурс больше 255 символов, то i "переваливает" байтовую границу и уже массив M начинает использоваться с нуля, а не с единицы.

Посмотрим на приведенном выше примере структуру первого из наших декодированных ресурсов:
0290: .. .. .. .. .. .. 1A 00 0A 00 08 00 01 03 43 52 |..............CR


02A0: 49 53 54 49 41 4E 5C 44 68 65 6C 6C 67 61 74 65 |ISTIAN\Dhellgate

Ее формат такой:

? длина ресурса (WORD), в нашем примере - 26(0x1A) байт.

? длина логина (WORD), в нашем примере - 10 символов.

? длина пароля (WORD), в нашем примере - 8 символов.

? BYTE, назначение которого пока точно не известно.

? тип хранимого ресурса (BYTE):

1 = NT Domain

2 = NT Server

3 = Shared

4 = MAPI

6 = Dial-Up

18 = NetWare

19 = WWW

Далее располагаются логин, а после него - пароль.

В нашем примере - тип ресурса "Shared", логин "CRISTIAN\D", пароль "hellgate".
(Примечание: для Shared-ресурсов запись CRISTIAN\D будет означать следующее: CRISTIAN - имя компьютера, а D - ресурс, предоставленный для общего пользования.)

Далее анализируем текущий блок с ресурсами, пока не перевалили за N, "поглядывая" в таблицу по адресу 0x109, т.к. в PWL-файлах между блоками ресурсов очень часто бывает "мусор" (неисповедимы пути Microsoft), а в этой таблице будет точное указание - в каком блоке сколько ресурсов.

Формат PWL-файлов Windows'OSR2/98/ME

Информация о формате PWL-файлов компанией Microsoft нигде и никогда не документировалась, и, хотя в Интернете можно найти много различных документов по форматам PWL-ок, вся эта информация взята из практического использования этих файлов и в основном написана авторами программ, аналогичных PWLInside.
Подробно рассмотрим в качестве примера следующий PWL-файл:
0000: E3 82 85 96 03 00 00 00 02 00 01 00 00 00 00 00

0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0100: 00 00 00 00 00 00 00 00 00 0D 03 FF FF FF FF FF

0110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0150: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF


01E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0200: FF FF FF FF FF FF FF FF 52 02 00 00 00 00 00 00

0210: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00

0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0240: 01 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00

0250: 00 00 88 51 47 58 2C 74 13 7C 6F D7 9E 9D 58 59

0260: 0B 3A A5 22 85 22 94 80 58 F9 61 00 B6 51 72 28

0270: D5 D7 3A 58 23 03 DD BC A7 4B E7 E2 71 65 66 CE

0280: 3F 58 FC 59 76 02 F0 12 8E 5F 79 94 39 E0 36 29

0290: 13 B9 8E 3B A1 F3 74 D4 78 38 01 E0 B5 FE DE A3

02A0: 80 CC 4E B7 67 1D 7C 36 7B C5 AA 76 4C D0 8E EE

02B0: 28 78 8A BB 7A 5A 81 2C AB 29 79 97 33 89 60 79

02C0: F7 6C 1C 72 1B 33 0A 09 F2 7E E4 3A A6 BE F4 C6

02D0: AE 06 DE 31 67 BB EA 7B D5 CA AE 01

Теперь внимательно посмотрим, из каких полей состоит файл:

Сразу оговорю следующие ограничения PWL-файлов: в файле может находится максимум 16 блоков ресурсов. Максимальное количество ресурсов в файле - 255. Это ограничения самой Windows. В каждом блоке может располагаться любое количество ресурсов, но их суммарное количество не может быть больше 255. И еще одно ограничение PWL-файла - то, что он не может быть больше 64кБ.

Итак, первое, что мы видим - это сигнатура (т.е. первые 4 байта файла), которая равна 0x968582E3, сразу же замечу, что у PWL-файлов от Windows'3.11/95 сигнатура другая - 0x4E464DB0.

По смещению 0x4 следует DWORD с неизвестным содержимым.

По смещению 0x8 следует WORD. Он определяет общее кол-во ресурсов в файле. В нашем примере - 2 ресурса.

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

Начиная с адреса 0x109 до адреса 0x208 находится другая таблица (тоже размером 255 байт), в которой хранится такая информация: любой байт из этой таблицы равный i (кроме 0xFF) означает, что i-й блок содержит ресурсы. Количество одинаковых байт равных i в данной таблице отражает количество ресурсов в i-м блоке. В нашем примере - 1-й байт в таблице показывает, что у нас имеются ресурсы в 13-м (0x0D) блоке, а 2-й байт в таблице показывает, что у нас имеются ресурсы в 3-м блоке ресурсов.

По адресу 0x208 находится DWORD (у нас он равен 0x00000252), который определяет смещение CryptoSign. Кстати, я в этом поле других значений не видел ни в одной PWL-ке!

С адреса 0x20C по 0x24C располагается массив CryptoSeed[16], он необходим для декодирования всех 16 блоков ресурсов.

По адресу 0x24C располагается CheckSeed (DWORD), с которого и начинается декодирование PWL-файла.

Далее идут два нулевых байта. Какую они несут функцию - неизвестно.

По адресу 0x252 располагается массив CryptoSign (16 байт).

По адресу 0x262 располагается массив CheckSign (16 байт) - этот массив вместе с CryptoSign является "контрольным значением" для определения правильности пароля. Их применение рассмотрим ниже.

По адресу 0x272 располагается массив из 15 WORD'ов - это адреса 15 блоков ресурсов, начиная со второго. Адрес же первого ресурса всегда один и тот же и составляет 0x290. Эти адреса уже являются зашифрованными. Посмотрим, что это будут за байты после декодирования правильным паролем:

0270: .. .. 92 02 94 02 96 02 B2 02 B4 02 B6 02 B8 02

0280: BA 02 BC 02 BE 02 C0 02 C2 02 C4 02 D8 02 DA 02

Как мы видим - действительно там находятся адреса! Эти адреса никогда не могут быть одинаковымии получается, что если блок ресурсов пустой, то он все равно занимает 2 байта - это мы видим на начальных адресах: 0x292, 0x294 - эти значения ссылаются на "мусор", ресурсы же в этом файле находятся по адресам 0x296 ... 0x2B2 и 0x2C4 ... 0x2D8 - это видно по тому, что разница между этими соседними адресами больше двух байт и т.к. мы уже отмечали, у нас 3-й и 13-й блок имеют ресурсы (см. пункт 6).

А с адреса 0x290 начинаются непосредственно ресурсы. Эти данные также зашифрованы. После дешифрования мы увидим, что с адресов 0x296 и 0x2C4 действительно есть что-то, похожее на ресурсы :)

0290: 4C 9C 50 94 C9 82 1A 00 0A 00 08 00 01 03 43 52 |L.P...........CR

02A0: 49 53 54 49 41 4E 5C 44 68 65 6C 6C 67 61 74 65 |ISTIAN\Dhellgate

02B0: E3 A8 CF DD 80 8A 8D 9A 1B 97 6B B9 BD F0 AE 9A |....?.....k.....

02C0: 5C D4 20 88 12 00 05 00 05 00 00 04 4D 41 50 49 |\. .........MAPI

02D0: 00 4D 41 50 49 00 28 F3 1D B2 90 80 |.MAPI.(....?

Как правильно декодировать ресурсы и их формат будет рассмотрен ниже.

это не что иное, как

MD5 - это не что иное, как операция свертки 64 байт в 16.

Посмотрим как эта функция описана в официальном документе - RFC1321 с небольшими упрощениями и нашими комментариями:

...

#define S11 7

#define S12 12

#define S13 17

#define S14 22

#define S21 5

#define S22 9

#define S23 14

#define S24 20

#define S31 4

#define S32 11

#define S33 16

#define S34 23

#define S41 6

#define S42 10

#define S43 15

#define S44 21

/* F, G, H and I are basic MD5 functions */

/* Основные макросы преобразования */

#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))

#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))

#define H(x, y, z) ((x) ^ (y) ^ (z))

#define I(x, y, z) ((y) ^ ((x) | (~z)))

/* ROTATE_LEFT rotates x left n bits */

/* Этот макрос - это всего лишь элементарная команда циклического сдвига ROL на Асме! Оригинальный вариант ротации на С работает быстрее на процессорах с архитектурой RISC. Для x86 процессоров лучше использовать команду ROL */

#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n))))

/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4. Rotation is separate from addition to prevent recomputation */

/* Основные макросы трансформации значений a, b, c и d */

#define FF(a, b, c, d, x, s, ac) { \

(a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define GG(a, b, c, d, x, s, ac) { \

(a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define HH(a, b, c, d, x, s, ac) { \

(a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define II(a, b, c, d, x, s, ac) { \

(a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

/* MD5 basic transformation. Transforms state based on block */

/* Непосредственно сам алгоритм MD5 */

static void MD5Transform (state, block)

{

UINT4 a,b,c,d,state[4], x[16];

a = state[0] = 0x67452301;


b = state[1] = 0xefcdab89;

c = state[2] = 0x98badcfe;

d = state[3] = 0x10325476;

/* Round 1 */

FF (a, b, c, d, x[ 0], S11, 0xd76aa478); /* 1 */

FF (d, a, b, c, x[ 1], S12, 0xe8c7b756); /* 2 */

FF (c, d, a, b, x[ 2], S13, 0x242070db); /* 3 */

FF (b, c, d, a, x[ 3], S14, 0xc1bdceee); /* 4 */

FF (a, b, c, d, x[ 4], S11, 0xf57c0faf); /* 5 */

FF (d, a, b, c, x[ 5], S12, 0x4787c62a); /* 6 */

FF (c, d, a, b, x[ 6], S13, 0xa8304613); /* 7 */

FF (b, c, d, a, x[ 7], S14, 0xfd469501); /* 8 */

FF (a, b, c, d, x[ 8], S11, 0x698098d8); /* 9 */

FF (d, a, b, c, x[ 9], S12, 0x8b44f7af); /* 10 */

FF (c, d, a, b, x[10], S13, 0xffff5bb1); /* 11 */

FF (b, c, d, a, x[11], S14, 0x895cd7be); /* 12 */

FF (a, b, c, d, x[12], S11, 0x6b901122); /* 13 */

FF (d, a, b, c, x[13], S12, 0xfd987193); /* 14 */

FF (c, d, a, b, x[14], S13, 0xa679438e); /* 15 */

FF (b, c, d, a, x[15], S14, 0x49b40821); /* 16 */

/* Round 2 */

GG (a, b, c, d, x[ 1], S21, 0xf61e2562); /* 17 */

GG (d, a, b, c, x[ 6], S22, 0xc040b340); /* 18 */

GG (c, d, a, b, x[11], S23, 0x265e5a51); /* 19 */

GG (b, c, d, a, x[ 0], S24, 0xe9b6c7aa); /* 20 */

GG (a, b, c, d, x[ 5], S21, 0xd62f105d); /* 21 */

GG (d, a, b, c, x[10], S22, 0x2441453); /* 22 */

GG (c, d, a, b, x[15], S23, 0xd8a1e681); /* 23 */

GG (b, c, d, a, x[ 4], S24, 0xe7d3fbc8); /* 24 */

GG (a, b, c, d, x[ 9], S21, 0x21e1cde6); /* 25 */

GG (d, a, b, c, x[14], S22, 0xc33707d6); /* 26 */

GG (c, d, a, b, x[ 3], S23, 0xf4d50d87); /* 27 */

GG (b, c, d, a, x[ 8], S24, 0x455a14ed); /* 28 */

GG (a, b, c, d, x[13], S21, 0xa9e3e905); /* 29 */

GG (d, a, b, c, x[ 2], S22, 0xfcefa3f8); /* 30 */

GG (c, d, a, b, x[ 7], S23, 0x676f02d9); /* 31 */

GG (b, c, d, a, x[12], S24, 0x8d2a4c8a); /* 32 */

/* Round 3 */

HH (a, b, c, d, x[ 5], S31, 0xfffa3942); /* 33 */

HH (d, a, b, c, x[ 8], S32, 0x8771f681); /* 34 */

HH (c, d, a, b, x[11], S33, 0x6d9d6122); /* 35 */

HH (b, c, d, a, x[14], S34, 0xfde5380c); /* 36 */

HH (a, b, c, d, x[ 1], S31, 0xa4beea44); /* 37 */


HH (d, a, b, c, x[ 4], S32, 0x4bdecfa9); /* 38 */

HH (c, d, a, b, x[ 7], S33, 0xf6bb4b60); /* 39 */

HH (b, c, d, a, x[10], S34, 0xbebfbc70); /* 40 */

HH (a, b, c, d, x[13], S31, 0x289b7ec6); /* 41 */

HH (d, a, b, c, x[ 0], S32, 0xeaa127fa); /* 42 */

HH (c, d, a, b, x[ 3], S33, 0xd4ef3085); /* 43 */

HH (b, c, d, a, x[ 6], S34, 0x4881d05); /* 44 */

HH (a, b, c, d, x[ 9], S31, 0xd9d4d039); /* 45 */

HH (d, a, b, c, x[12], S32, 0xe6db99e5); /* 46 */

HH (c, d, a, b, x[15], S33, 0x1fa27cf8); /* 47 */

HH (b, c, d, a, x[ 2], S34, 0xc4ac5665); /* 48 */

/* Round 4 */

II (a, b, c, d, x[ 0], S41, 0xf4292244); /* 49 */

II (d, a, b, c, x[ 7], S42, 0x432aff97); /* 50 */

II (c, d, a, b, x[14], S43, 0xab9423a7); /* 51 */

II (b, c, d, a, x[ 5], S44, 0xfc93a039); /* 52 */

II (a, b, c, d, x[12], S41, 0x655b59c3); /* 53 */

II (d, a, b, c, x[ 3], S42, 0x8f0ccc92); /* 54 */

II (c, d, a, b, x[10], S43, 0xffeff47d); /* 55 */

II (b, c, d, a, x[ 1], S44, 0x85845dd1); /* 56 */

II (a, b, c, d, x[ 8], S41, 0x6fa87e4f); /* 57 */

II (d, a, b, c, x[15], S42, 0xfe2ce6e0); /* 58 */

II (c, d, a, b, x[ 6], S43, 0xa3014314); /* 59 */

II (b, c, d, a, x[13], S44, 0x4e0811a1); /* 60 */

II (a, b, c, d, x[ 4], S41, 0xf7537e82); /* 61 */

II (d, a, b, c, x[11], S42, 0xbd3af235); /* 62 */

II (c, d, a, b, x[ 2], S43, 0x2ad7d2bb); /* 63 */

II (b, c, d, a, x[ 9], S44, 0xeb86d391); /* 64 */

state[0] += a;

state[1] += b;

state[2] += c;

state[3] += d;

}

В итоге получаем из входного массива x (16 DWORD'ов) массив state (всего 4 DWORD'a).

Описание алгоритмов, используемых для шифрования PWL-файлов

Ниже подробно опишем те алгоритмы, которые используются при шифровании данных в PWL-файлах. Т.к. подробные описания RC4 и MD5 можно найти в различных источниках, то я опишу их поверхностно, т.к. предполагаю, что читатель либо знает принципы работы этих алгоритмов, либо сам сможет найти в Интернете подробные их описания, хотя бы в тех же RFC.

Оптимизация алгоритмов восстановления паролей

Вот и начинается самое интересное. ;)

Посмотрим, что же мы можем сделать для повышения быстродействия вышеприведенных алгоритмов.

RC4 (1-я часть)

1. Сразу же бросается в глаза инициализация массива значениями от 0 до 255, которое происходит при каждом новом значении ключа (т.е. фактически при каждом новом пароле). Как же можно сделать ее более эффективной?
Выход есть - инициализировать массив не побайтно (256 команд), а, например, используя 32-битные регистры процессора, по 4 байта за 64 команды - и действительно, выигрыш по времени будет в 4 раза (конечно же, если массив M выровнен минимум по границе DWORD'a). А есть ли еще более "широкие" регистры, чтобы за одну команду "махом" записывать бОльшее кол-во байт? Регистры FPU отпадают, т.к. операции с ними выполняются очень долго, остаются, конечно же, MMX-регистры:
.DATA

qwInit DQ 0706050403020100h

qwAdd DQ 0808080808080808h

...

.CODE

mov edi,offset M+128

movq mm0,qword ptr [qwInit]

movq mm1,qword ptr [qwAdd]

movq [qword ptr edi-128],mm0

paddb mm0,mm1

movq [qword ptr edi-120],mm0

paddb mm0,mm1

movq [qword ptr edi-112],mm0

...

paddb mm0,mm1

movq [qword ptr edi+112],mm0

paddb mm0,mm1

movq [qword ptr edi+120],mm0
Чтобы не писать 31 одинаковый фрагмент кода, гораздо проще использовать зарезервированный макрос Ассемблера IRP, тогда последние строки кода можно заменить на следующую конструкцию:
IRP i,<-15,-14, ... ,14,15>

paddb mm0,mm1

movq [qword ptr edi+(i*8)],mm0

ENDM
Итого получаем - на инициализацию массива из 256 байт затрачиваем 66 команд процессора, которые выполняются за ~35-40 тактов, т.к. команды PADDB и MOVQ выполняются синхронно.

Нетрудно догадаться, ЧТО наворотил бы на месте этого цикла любой компилятор С, если этот код писать не на Асме. ;)
У читателя, наверное, возник вопрос - почему мы инициализируем EDI не на начало массива M, а на его середину?

Просто дело в том, что при таком варианте программы дополнительное смещение к EDI будет приводить к увеличению длины команды MOVQ всего на один байт (знаковый диапазон -128...+127) и команда получает длину в 4 байта. А если, к примеру, прибавить к EDI +256, то смещение будет расширено до DWORD'a и длина команды увеличится до 7 байт. Использование же более коротких команд является предпочтительным, т.к. идет более "плотное" заполнение буфера предвыборки команд и более оптимальное их декодирование процессорами.
И еще - вдумчивый читатель скажет, что есть ведь еще более "широкие" XMM-регистры - те, которые используются в наборах команд SSE (которые, кстати, поддерживают и Athlon'ы) и SSE2 от Intel. Используя их, можно оперировать с памятью блоками по 16 байт за такт!
Действительно, это так. В PWLInside не была включена поддержка SSE только по причине недостаточного распространения таких процессоров в то время, когда создавалась программа. Вполне возможно, что в следующей версии программы поддержка SSE будет присутствовать.

RC4 (2-я часть)

Теперь рассмотрим "перетасовку" байт в массиве M, используя входной ключ.

Здесь получается такая картина - на обработку одного байта массива M необходимо минимум 7 команд, покажем это на примере одной итерации:
xor eax,eax ;в AL будем хранить индекс A

mov ebp,offset Key

mov edi,offset M

...

add al,byte ptr[ebp+i] ;A += Key[i % 16]

mov dl,byte ptr [edi+i] ;Считываем M[i]

add al,dl ;A += M[i]

movzx esi,al

mov bl,byte ptr [edi+esi] ;Считываем M[A]

mov byte ptr [edi+esi],dl

mov byte ptr [edi+i],bl

...

Причем такая конструкция имеет ряд особенностей:

Использование команды MOVZX ESI,AL устраняет следующий конфликт на процессорах Intel: обращение к 32-битному регистру сразу после модификации его младшей (16- или 8-битной) части. В этом случае ко времени выполнения команды добавляется несколько тактов штрафа. Кстати, на процессорах от AMD таких штрафов нет. :)

Конфликты по чтению/записи в одну кэш-линейку процессора.

Известно, что при обращении к ячейке памяти процессор считывает из памяти (или кэша 2-го уровня) не одну эту ячейку, а целую строку (например, 32 байта), которую и размещает в кэше 1-го уровня. При этом ВСЯ эта строка помечается как доступная либо только для чтения, либо для записи. Поэтому, если прочитать байт по адресу X, а потом записать байт по адресу (X + 1), то несмотря на то, что байт по адресу (X + 1) уже в кэше(!), процессор после выполнения первой команды должен сначала "освободить" всю строку, а лишь потом снова ее загрузить, но уже для записи в нее, что, естественно, приводит к штрафам. Но, т.к. алгоритм формирует равномерное распределение байт, то такие конфликты возникают нечасто.

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

В итоге такая конструкция выполняется в среднем за 5 тактов, т.к. все эти команды простые и на процессорах P-II/III от Intel могут декодироваться всеми 3-мя декодерами. Таким образом, декодирование может происходить по 3 команды за такт, что частично компенсирует вышеописанные штрафы.

Краткое описание: на входе имеем

Краткое описание: на входе имеем ключ размером 16 байт, на выходе получаем массив из 256 байт, в котором равномерно и псевдослучайно распределены байты от 0 до 255, причем их распределение зависит от входного ключа:

byte t; //Временная ячейка

byte A = 0; //Здесь будем получать новый псевдослучайный индекс

byte M[256]; //Наш формируемый массив

byte Key[16]; //Исходный ключ, с помощью него будем формировать массив M

for (int i = 0; i < 256; i++)

M[i] = i; //Последовательно заполняем массив значениями от 0 до 255

for (int i = 0; i < 256; i++)

{

A += (M[i] + Key[i % 16]); //Вычисляем новый индекс для обмена байтами

t = M[i];

M[i] = M[A]; //Меняем местами i-й байт и байт по вычисленному индексу A

M[A] = t;

}

Далее по этому алгоритму байтами из массива M с помощью завершающей процедуры RC4 с применением операции XOR расшифровываются любые необходимые данные.

Стандартный алгоритм восстановления паролей к PWL-файлам

Считываем из исходного PWL-файла по смещению 0x24C - CheckSeed (DWORD).

-//- по смещению 0x252 - CryptoSign (16 байт).

-//- по смещению 0x262 - CheckSign (16 байт).

Формируем массив X (размером 64 байта) следующим образом:

0xFFFFFFFF (DWORD)

Логин в верхнем регистре

0x0 (1 байт)

CheckSeed (DWORD)

0x80 (1 байт)

0x0 (по адрес 0x37 включительно)

По адресу 0x38 записываем (0x48 + (длина логина << 3)) (DWORD)

0x0 (до конца массива)

Выполняем MD5 (массив X), получаем массив Cnt (16 байт), т.е. производим свертку логина.

Формируем массив Y (размером 64 байта) следующим образом:

Логин в верхнем регистре

0x0 (0x11 байт)

0x80 (1 байт)

0x0 (по адрес 0x37 включительно)

По адресу 0x38 записываем (0x88 + (длина логина << 3)) (DWORD)

0x0 (до конца массива)

Формируем массив Z (размером 64 байта) следующим образом:

Пароль

0x0 (1 байт)

Cnt (16 байт)

0x80 (1 байт)

0x0 (по адрес 0x37 включительно)

По адресу 0x38 записываем (0x88 + (длина пароля << 3)) (DWORD)

0x0 (до конца массива)

Выполняем MD5 (массив Z), получаем массив Key (16 байт), т.е. производим свертку пароля.

Выполняем RC4, используя в качестве ключа Key.

Копируем во временный буфер Temp (32 байта):

CryptoSign (16 байт)

CheckSign (16 байт)

Выполняем процедуру XorT (массив M, массив Temp), получаем модифицированный массив Temp.

Копируем первые 16 байт из массива Temp в буфер Y с адреса (длина логина + 1)

Выполняем MD5 (массив Y), получаем массив TempKey (16 байт).

Сравниваем 16 байт массива TempKey и вторые 16 байт из массива Temp и если они не равны, то инкремент пароля и возврат на пункт 7, иначе - пароль верный!

Внимание! А на "десерт" - самое вкусненькое ;) - то, что позволило в свое время программе PWLInside существенно увеличить скорость перебора и по этому параметру здорово "оторваться" от своих конкурентов.
Оказывается, для быстрой оценки - тот пароль или нет, можно пункты 10...14 не выполнять, а значит и не вызывать второй раз MD5, который (как уже было сказано) выполняется около 300 тактов, что дает прирост скорости еще на 20-25%!
Дело вот в чем.
Если внимательно присмотреться к процедуре декодирования ресурсов, то мы увидим, что с помощью массива M после пункта 9 стандартного алгоритма при проходе с правильным паролем мы декодируем:

начальный буфер Temp - это не что иное, как 32 байта исходного PWL-файла с адреса 0x252,

смещения (адреса) блоков ресурсов с адреса 0x272,

и, наконец, сами ресурсы.

Поэтому можно не выполнять операции над CryptoSign и CheckSign (для проверки правильности пароля), а просто проверить после XOR'a адрес первого блока ресурсов, который находится по адресу 0x272.
Если он лежит в диапазоне 0x292...(длина PWL-файла), то есть вероятность, что этот пароль верный! Для окончательной же проверки правильности пароля нужно выполнить пункты 10...14, т.к. только в этом случае (когда совпадут все 16 байт массива Temp), можно быть уверенным, что это именно верный пароль.
И, соответственно, наоборот - если предварительная проверка показала, что адрес первого блока ресурсов декодировался неверно, то пароль однозначно неверный и можно смело идти на перебор следующего. :)
Практика показала, что процент "ложных" попаданий, т.е. когда после XOR'а первого адреса получили смещение, похожее на правду, крайне низок, и временем выполнения повторных полных "перепроверок" можно пренебречь.
Поэтому код предварительной оценки пароля в упрощенном виде будет выглядеть так:
...

//Массив M перерабатывается с помощью RC4

...

byte t; //Временная ячейка

byte A = 0; //Здесь будем получать новый псевдослучайный индекс


WORD Offset = (WORD *)&lpFile[0x272]; //Зашифров. адрес 1-го блока ресурсов

WORD Len = XXX; //Длина исходного PWL-файла

//

for (int i = 1; i < 35; i++)

{

A += M[i]; // Вычисляем новый индекс для обмена байтами

t = M[i];

M[i] = M[A]; //Меняем местами i-й байт и байт по вычисленному индексу A

M[A] = t;

//

t = M[i] + M[A]; //Вычисляем еще один индекс

if (i == 33)

((byte *)&Offset)[0] ^= M[t]; //Декодируем 1-й байт адреса

if (i == 34)

((byte *)&Offset)[1] ^= M[t]; //Декодируем 2-й байт адреса

}

//

if ((Offset > 0x291) && (Offset < Len))

{

//Есть вероятность, что пароль верный,

//делаем полную перепроверку по пунктам 10...14

}

else

{

//Однозначно пароль неверный, переходим на новый пароль

}

Как видим, переработка массива M все равно остается, но(!) - первые 32 итерации мы НИЧЕГО не XOR'им, а декодируем ТОЛЬКО на 33 и 34 итерациях адрес блока ресурсов.

Таким образом, зачем нам делать пункты 10...14 и проверять 16 байт, когда можно выполнить "упрощенный" вариант процедуры XorT и проверить всего 2 байта! ;)

При всем моем уважении к Microsoft, однако, это еще одна их "дыра" в реализации качественных методов хранения паролей пользователей!

Итак, что мы получили в среднем:

~40 тактов на инициализацию массива M.

~300 тактов на первый проход MD5.

~1000 тактов на проход RC4.

~150 тактов на все остальное (формирование массива Z, инкремент пароля, "упрощенная" функция XorT, проверки и пр.)

В итоге мы получаем суммарное время обработки одного пароля около 1500 тактов

на всех типах процессоров, что приведены в начале статьи, кроме процессора Pentium 4. :(

Дело в том, что микроархитектура P4 по сравнению с P-II/III была существенно переработана - увеличено время выполнения команды (до 20 стадий), изменились размеры строк кэша данных и кода и еще ряд "усовершенствований", поэтому этот код (в особенности, реализация алгоритма RC4) для P4 не является оптимальным и в следующей версии PWLInside будет модифицирован. При этом на процессорах AMD, даже последних, таких проблем не возникает - на Athlon'e XP 1700+ (1466МГц) с ядром ThoroughBred программа исправно выдает около миллиона паролей в секунду. Вот так AMD делает аналоги процессоров Intel в чем-то лучше, чем сама Intel. :)

Восстановление паролей к PWL-файлам

Автор: (c), 2003

WWW: www.InsidePro.com

Версия документа: 1.0

PWL-файлы ( или так называемые парольные кэши Windows) - это файлы с именами пользователей компьютера и с расширениями *.PWL (к примеру, Master.PWL, Sales.PWL и пр.), которые находятся в директории Windows.
Это файлы, в которых хранятся различные аккаунты (т.е. сочетание логин/пароль) данного пользователя, т.е. пароли ко всем ресурсам, при первом подключении к которым в окне ввода пароля был включен флажок "Запомнить пароль". Таким образом, в нем хранятся пароли к "расшаренным" ресурсам сети, пароли на подключение к NetWare/NT-серверам, пароли на Dial-Up-соединения и пр.
Функция запоминания паролей в Windows реализована давно и была введена с "благой" целью - облегчение работы пользователей. И действительно - зачем вводить каждый раз при подключении к провайдеру пароль "q6Rf8UI24dq" :) , когда можно один раз ввести его с бумажки, а потом забыть про этот пароль вообще. Таким образом, Windows собирает все пароли пользователя, шифрует их с помощью логина (имени пользователя) и текущего пароля пользователя (т.е. того пароля, который вводится при загрузке Windows) и хранит в этом PWL-файле.
Естественно, все эти данные зашифрованы определенными алгоритмами, и для их дешифрования необходимо знать пароль пользователя - а это фактически пароль на вход в Windows. А так как людям свойственно забывать свои пароли, то подбор пароля, во-первых, позволяет его "вспомнить", а во-вторых, позволяет просмотреть список аккаунтов этого пользователя, которые Windows сохраняет в этом PWL-файле, например, там может быть и забытый пароль на подключение к провайдеру. ;)
В данной статье будут описаны те методы оптимизации при подборе паролей к PWL-файлам, которые были использованы при создании программы PWLInside и которые позволили занять программе лидирующее место по скорости работы среди аналогичных программ.
И сразу оговорюсь, что речь пойдет только о PWL-файлах операционных систем Windows'OSR2/98/ME, т.к. в PWL-файлах ОС Windows'3.11/95 методы шифрования гораздо проще и подбор пароля любой сложности - дело одного часа работы любой программы по восстановлению к ним паролей, в том числе и PWLInside.
Вся информация в тексте о времени выполнения фрагментов кода в тактах дана для следующих типов процессоров:

Intel Pentium MMX/II/III и все Celeron'ы из этих семейств.

AMD K6-II/III, все Duron'ы и Athlon'ы.

Такая информация дается как усредненное время выполнения на всех этих типах процессоров.
Примеры кода, приведенные ниже, даны в синтаксисе Microsoft Visual С++ v6.0 и MASM v7.0.

к концу наше описание. Надеюсь,

Вот и подошло к концу наше описание. Надеюсь, теперь по работе с PWL-файлами от Windows'OSR2/98/ME ни у кого не осталось "темных пятен". Видно, что данные алгоритмы можно было бы прооптимизировать еще больше с применением команд современных процессоров, но - операционные системы этих поколений уже уходят "в прошлое" - процент этих ОС и так уже невысокий, со временем снижается все больше и больше, и восстановление паролей к PWL-файлам уже не столь актуально, как несколько лет назад.
Хотя, возможно, стоит еще поработать в этой области. ;)
Сейчас основной процент ОС семейства Windows - это Windows'2000, Windows'XP, а теперь уже и Windows'2003. Так как у всех этих систем ядро другое (на базе NT), то и методы хранения, шифрования, а также восстановления ;) паролей пользователей тоже другие.
В них информация о паролях пользователей хранится в SAM-файлах, которые представляют собой ветку "HKEY_LOCAL_MACHINE\SAM" реестра Windows, и пароли зашифрованы другими алгоритмами, нежели в PWL-файлах.
Но(!) - несмотря на все попытки Microsoft создать максимально надежный механизм авторизации, все их методы почему-то имеют явные огрехи - это наглядно демонстрируют как методики, описанные выше, так и методы хранения и шифрования паролей в SAM-файлах.
В операционных системах Windows'NT, начиная с 6-го сервис-пака, Windows'2000, Windows'XP (а по всей видимости и в Windows'2003) применяется дополнительное шифрование хешэй пользователей (которые и так получены путем шифрования паролей определенными алгоритмами) с использованием утилиты Syskey.
Данный механизм успешно просуществовал несколько лет. Его многократно пытались взломать, но все попытки были безуспешны, пока этой проблемой не заинтересовались мы с Ocean'ом. ;)
И механизм был "взломан"! Это наглядно демонстрирует программа SAMInside.
Но про SAM-файлы и методы восстановления к ним паролей расскажу как-нибудь в другой раз. :)
Особую благодарность выражаю 'у, т.к. только наша с ним совместная деятельность в этой области привела к появлению на свет таких программ как PWLInside, SAMInside
и ряда других.
Удачи всем!

Здесь будем получать новый псевдослучайный

Эта часть RC4 (не описанная выше), которая декодирует необходимые данные с помощью массива M:

...

//Массив M перерабатывается с помощью RC4

...

byte t; //Временная ячейка

byte A = 0; // Здесь будем получать новый псевдослучайный индекс

for (byte i = 1; i < 33; i++)

{

A += M[i]; //Вычисляем новый индекс для обмена байтами

t = M[i];

M[i] = M[A]; //Меняем местами i-й байт и байт по вычисленному индексу A

M[A] = t;

//

t = M[i] + M[A]; //Вычисляем еще один индекс

Data[i - 1] ^= M[t]; //Декодируем 32 байта массива Data

}

Квантовая криптография, почти реальность

07.08.2003

Один из самых авторитетных технологических журналов, MIT Enterprise Technology Review в феврале опубликовал список десяти наиболее быстро развивающихся технологий, способных изменить мир. Квантовая криптография — одна из них.
Одни футурологи считают, что наступивший век станет веком оптики, другие говорят о господстве квантовой физики. Квантовая криптография лежит на перекрестке этих дисциплин. Не исключено, что именно квантовая криптография может стать первым практическим результатом технологий XXI века.
В большинстве своем все статьи про квантовую криптографию начинаются со сравнения этой схемы с двумя классическими и хорошо известными схемами — с симметричным и асимметричным распределением ключей. Затем следует представление физических принципов квантовой криптографии. Парадоксально, но несмотря на всю серьезность предмета основные идеи, лежащие в основе квантовой криптографии, настолько просты, что популярное введение было напечатано в журнале для школьников [1]. Существует более продвинутое популярное введение [2], а также огромное количество статей, где излагаются физические принципы и история вопроса.
В надежде на то, что физики не читают «Открытые системы», ограничимся сообщением, что в основе квантовой криптографии лежит телепортация фотонов, в процессе которой фотон пересылается от передатчика приемнику. При этом обнаруживается замечательная для криптографии особенность данного способа передачи, которая заключается в том, что «подслушивание» теоретически невозможно. В основе этого утверждения лежит принцип неопределенности Гейзенберга, который постулирует, что любое поползновение внедриться в канал передачи — т.е. произвести измерение в квантовой системе — неизбежно приведет к ее нарушению и будет зафиксировано принимающей стороной. В результате образуется абсолютно защищенный канал, но у этого канала есть один теоретически непреодолимый недостаток: он не в состоянии обеспечить высокую пропускную способность, а поэтому может быть использован только для обмена ключами. Это ограничение являлось настолько значительным, что об использовании квантовой криптографии до сих пор говорили только в будущем времени. Однако ситуация стремительно меняется.

Фотография Женевского озера, сделанная со спутника

Для распространения квантовой криптографии есть не только теоретические предпосылки, но и вполне реальная практическая потребность. Защищенность передачи данных зависит от возможности сохранить ключ в секрете от противника. Если говорить о синхронной схеме, то ее уязвимость в существенной мере зависит, например, от успешности деятельности разведки. Яркий пример тому — использование криптомашины Enigma немецкими военными во время Второй мировой войны. Как только английские спецслужбы добывали ключи, то, какой бы ухищренной ни была схема шифрования, она раскрывалась в считанные дни и при том весьма незамысловатыми по сегодняшним меркам средствами. Сохранность криптосистемы с публичными ключами, являющейся основой передачи данных в Internet, возможна только до тех пор, пока нет достаточной вычислительной мощности для ее раскрытия. Безопасность схемы, предложенной RSA, гарантируется факторизацией больших целых чисел. В предвидении неизбежного конца этой схемы информационному обществу требуется альтернативное решение. Пока ничего иного помимо квантовой криптографии не предложено. Ведущий специалист RSA Laboratories Бурт Калиски сказал по этому поводу: «Квантовое распределение ключей является основным сдвигом парадигмы в развитии криптографии. Способность обнаруживать прослушивание линии связи с абсолютной уверенностью в обнаружении вызывает восхищение. Сочетание квантовой и классической криптографии способно обеспечить реальную защищенность коммуникаций» [3]. Подобное признание дорогого стоит.

Квантовая криптография еще не вышла на уровень практического использования, но приблизилась к нему. В мире существует несколько организаций, где ведутся активные исследования в области квантовой криптографии. Среди них IBM, GAP-Optique, Mitsubishi, Toshiba, Национальная лаборатория в Лос-Аламосе, Калифорнийский технологический институт (Caltech), а также молодая компания MagiQ и холдинг QinetiQ, поддерживаемый британским министерством обороны. Диапазон участников — от крупнейших мировых вендоров до небольших начинающих компаний — свидетельствует о начальном периоде в формировании рыночного сегмента, когда в нем на равных могут участвовать и те, и другие.


В IBM продолжаются фундаментальные исследования в области квантовых вычислений [6], начатые группой во главе с Чарльзом Беннеттом, который в 1984 году вместе с Жилем Броссардом предложил простую схему защищенного квантового распределения ключей. Схема получила известность под названием «протокол BB84». О практических достижениях IBM в квантовой криптографии в последние годы известно немногое; эти работы ведутся без излишней рекламы.

Особое место занимает созданная на основе Женевского университета компания GAP (Group of Applied Phisics) Optique. Компания с европейскими академическими корнями сохраняет традиции научных публикаций; для тех, кто серьезно заинтересуется квантовой криптографией, несомненно, будут интересны две статьи авторов из GAP [4, 5]. О том, что квантовая криптография выходит из лабораторного состояния можно судить хотя бы потому, что в 2003 году о ней пишет и бизнес-пресса (в частности, New York Times), и популярные издания (в том числе, National Geographic). Под руководством Николаса Гисина GAP-Optique совмещает теоретические исследования с практической деятельностью. Компании впервые удалось передать ключ на расстояние 67 километров из Женевы в Лозанну, воспользовавшись почти промышленным образцом аппаратуры [7].

Этот рекорд был побит компанией Mitsubishi Electric, которой удалось передать квантовый ключ на расстояние 87 километров; скорости еще очень невелики, всего 7,2 бит в секунду.

Исследования в области квантовой криптографии ведутся и в европейском исследовательском центре Toshiba Research Europe, расположенном в Кембридже. Отчасти они спонсируются английским правительством; в них участвуют сотрудники Кембриджского университета и Империал-колледжа в Лондоне. Сейчас им удается передавать фотоны на расстояние до 100 километров; есть надежда, что через три года будут выпущены коммерческие продукты.

Компания MagiQ Technologies была основана в 1999 году на средства пула крупных финансовых институтов. Помимо собственных сотрудников с ней сотрудничают научные работники из целого ряда университетов США, Канады, Великобритании и Германии. До последнего времени вела скрытное существование и заявила о себе после того, как сочла себя готовой к объявлению готовящегося коммерческого продукта, но и после него ясного представления о нем пока нет. В качестве кодового имени для средства для распределения ключей (quantum key distribution, QKD) избрано имя племени индейцев навахо. Известно, что во время Второй мировой войны язык навахо использовался для передачи особо секретных сообщений: лиц, знавших его за пределами Соединенных Штатов попросту не было. Navajo способен в реальном времени генерировать и распространять ключи средствами квантовых технологий, он должен обеспечивать защиту от внутренних и внешних злоумышленников. По сообщениям, Navajo находится в состоянии бета-тестирования и станет коммерчески доступным в конце года. Вице-президентом MagiQ является Алексей Трифонов, наш соотечественник, защитивший докторскую диссертацию Санкт-Петербургском университете в 2000 году.


QinetiQ — своего рода исследовательская корпорация, поддерживаемая министерством обороны Великобритании. Она появилась на свет в результате деления британского агентства DERA (Defence Evaluation and Research Agency) в 2001 году, вобрав в себя все неядерные оборонные исследования. В силу этой специфики в QinetiQ не особенно расположены делиться своими достижениями.

Литература

А. Корольков, Квантовая криптография, или как свет формирует ключи шифрования. Компьютер в школе, № 7, 1999.

В. Красавин, Квантовая криптография, www.submarine.ru.

MagiQ Technologies offers different kind of Grid Security. Grid Today, vol. 1, no. 23, November 2002.

I. Marcikic, H. de Riedmatten, W. Tittel, H. Zbinden, N. Gisin, Long-distance teleportation of qubits at telecommunication wavelengths. http://www.gap-optique.unige.ch/I&Hnature.pdf

Nicolas Gisin, Gregoire Ribordy, Wolfgang Tittel, Hugo Zbinden, Quantum cryptography. http://www.gap-optique.unige.ch/Publications/Pdf/QC.pdf

Brad Huntting, David Mertz, Introduction to Quantum Computing. A guide to solving intractable problems simply. http://www-106.ibm.com/developerworks/linux/library/l-quant.html

D Stucki, N Gisin, O Guinnard, G Ribordy, H Zbinden, Quantum key distribution over 67 km with a plug&play system. http://www.gapoptic.unige.ch/Publications/Pdf/njp-2002.pdf

Квантовая телепортация

Слово телепортация пришло из фантастических романов. Их авторы предполагали создание некоей машины, которая могла бы переносить тело и душу человека на расстояние с сохранением или разрушением оригинала, в зависимости от их желаний.
В 1993 группа под руководством Чарльза Бенетта, работавшая в IBM и состоявшая из шести специалистов из разных стран, подтвердила возможность телепортации, но только при условии разрушения оригинала. До этого телепортация считалась теоретически невозможной из-за известного принципа неопределенности, являющегося одним из постулатов квантовой механики. Согласно нему, чем точнее мы сканируем или измеряем объект, тем больше мы его разрушаем. В процессе измерения возникает такой момент, когда они еще не закончены, но объект настолько разрушен, что уже не представляется возможным создать его точную реплику. Рассуждения коллектива Бенетта основывались на эффекте Эйнштейна-Подольского-Розена. Ученые обнаружили, что, если сканировать часть информации с предполагаемого для телепортации объекта, то оставшуюся не сканированную часть можно предать получателю, основываюсь на этом эффекте. В таком случае на приемной стороне можно воссоздать объект полностью.

Экспериментальная реализация

Не так давно метод квантового распространения ключа воспринимался как научная фантастика. Но в 1989 г. в Уотсоновском исследовательском центре IBM Чарльзом Беннетом, Джилом Брасардом и их студентами была построена первая система, реализующая протокол ВВ84. Она позволяла «Алисе» и «Бобу» обмениваться секретным ключом со скоростью 10 бит/с на расстоянии 30 см. Это был небольшой шаг для Алисы и Боба, но большой шаг в развитии квантовой криптографии!
Позже эту идею реализовала Национальная лаборатория в Лос-Аламосе в эксперименте по распространению ключа в оптоволоконном кабеле на расстояние 48 км. В качестве среды передачи сигнала использовался и открытый воздух, расстояние передачи, в котором составляло около 1 км. Разработан план эксперимента по передаче квантового сигнала на спутник. Если этот эксперимент увенчается успехом, можно надеяться, что технология вскоре станет широко доступной.
В квантово-криптографических исследованиях прогресс идет быстрыми темпами. В ближайшем будущем квантово-криптографические методы защиты информации будут использоваться сверхсекретных военных и коммерческих приложениях, которые... Однако «честность, стоявшая за моим писательским креслом, останавливает разбежавшуюся руку: «Товарищ, здесь ты начинаешь врать, остановись поживем, увидим. Поставь точку» (А.Н. Толстой, «Ибикус, или Похождения Невзорова»).

Сведения об авторах:
Виноградова Лилия Степановна, ассистент Украинского государственного химико-технологического университета
Виноградов Константин Георгиевич, ст. преподаватель
document.write('');

Новости мира IT:

02.08 -

02.08 -

02.08 -

02.08 -

02.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

31.07 -

31.07 -

31.07 -

31.07 -

31.07 -

Архив новостей
Последние комментарии:
(66)

2 Август, 17:53
(19)

2 Август, 17:51
(34)

2 Август, 15:40
(42)

2 Август, 15:35
(1)

2 Август, 14:54
(3)

2 Август, 14:34
(3)

2 Август, 14:15

Квантовое распространение ключа

Состояние квантового объекта (то есть, грубо говоря, объекта очень малой массы и размеров, например, электрона или фотона) может быть определено измерением. Однако сразу после выполнения этого измерения квантовый объект неизбежно переходит в другое состояние, причем предсказать это состояние невозможно. Следовательно, если в качестве носителей информации использовать квантовые частицы, то попытка перехватить сообщение приведет к изменению состояния частиц, что позволит обнаружить нарушение секретности передачи. Кроме того, невозможно получить полную информацию о квантовом объекте, и следовательно, невозможно его скопировать. Эти свойства квантовых объектов делают их «неуловимыми».
Идея использовать квантовые объекты для защиты информации от подделки и несанкционированного доступа впервые была высказана Стефаном Вейснером (Stephen Weisner) в 1970 г. Спустя 10 лет Беннет и Брассард, которые были знакомы с работой Вейснера, предложили использовать квантовые объекты для передачи секретного ключа. В 1984 г. они опубликовали статью, в которой описывался протокол квантового распространения ключа ВВ84.
Носителями информации в протоколе ВВ84 являются фотоны, поляризованные под углами 0, 45, 90, 135 градусов. В соответствии с законами квантовой физики, с помощью измерения можно различить лишь два ортогональных состояния: если известно, что фотон поляризован либо вертикально, либо горизонтально, то путем измерения, можно установить — как именно; то же самое можно утверждать относительно поляризации под углами 45 и 135 градусв. Однако с достоверностью отличить вертикально поляризованный фотон от фотона, поляризованного под углом 45?, невозможно.
Эти особенности поведения квантовых объектов легли в основу протокола квантового распространения ключа. Чтобы обменяться ключом, Алиса и Боб предпринимают следующие действия:
Алиса посылает Бобу фотон в одном из поляризованных состояний (0, 45, 90, 135 градусов) и записывает угол поляризации. Отсчет углов ведется от направления "вертикально вверх" по часовой стрелке. В реальных же системах перед процессом передачи ключа оборудование специально юстируется для обеспечения одинакового режима отсчета на приемнике и передатчике (причем эту юстировку приходится проводить периодически в процессе передачи), а "пространственное расположение" начала отсчета угла -- несущественно.
Боб располагает двумя анализаторами: один распознает вертикально-горизонтальную поляризацию, другой — диагональную. Для каждого фотона Боб случайно выбирает один из анализаторов и записывает тип анализатора и результат измерений.
По общедоступному каналу связи Боб сообщает Алисе, какие анализаторы использовались, но не сообщает, какие результаты были получены.
Алиса по общедоступному каналу связи сообщает Бобу, какие анализаторы он выбрал правильно. Те фотоны, для которых Боб неверно выбрал анализатор, отбрасываются.
Протокол для обмена ключом может выглядеть, как показано на рис. 1.

Значения разрядов ключа получаются следующим

Последовательность фотонов Алисы	|	/	/	—	\	|	|	—	—
Последовательность анализаторов Боба

+ x + + x x x + x Результаты измерений Боба 0 0 1 1 1 0 1 1 0 Анализаторы выбраны верно + + + + + Ключ 0 0 1 1 1 Рис. 1. Принцип действия протокола ВВ84.

Условные обозначения:

Поляризация фотонов: | - вертикальная, — - горизонтальная, / - под угром 45, \ - под углом 135.

Анализаторы: + - прямоугольный, х - диагональный

Значения разрядов ключа получаются следующим образом: в случае вертикально-горизонтальной ("прямоугольной") поляризации вертикально-поляризованный фотон означает 0, горизонтально-поляризованный — 1; в случае диагональной поляризации фотон, поляризованный под углом 45 градусов -- 0, 135 градусов -- 1.

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

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

Чтобы было легче разобраться, проследим результаты во всех ячейках на рисунке:

1-й столбец — Алиса послала вертикально-поляризованный фотон, Боб выбрал "прямоугольный" анализатор и, следовательно, смог получить правильный результат — 0. Этот результат вошел в ключ.

2-й столбец — Алиса посылает фотон, поляризованный под углом 45 градусов, Боб выбирает диагональный анализатор и может получить верный результат — 0. Этот результат также входит в ключ.

3-й столбец — Алиса вновь посылает фотон, поляризованный под углом 45 градусов, но Боб выбирает неверный, прямоугольный анализатор, поэтому с равной вероятностью может получить как 0, так и 1. В случае, показанном на рисунке, его результат равен 1. После сверки анализаторов этот результат будет отброшен и в ключ не войдет.

4-й столбец — Алиса посылает горизонтально-поляризованный фотон, Боб выбирает верный анализатор и получает результат 1, который войдет в ключ.

5-й столбец — Алиса посылает фотон, поляризованный под углом 135 градусов, Боб выбирает правильный, диагональный анализатор и получает результат 1, который войдет в ключ.

6-й и 7-й столбцы — Алиса дважды подряд (это случайно!) посылает вертикально-поляризованный фотон, но Боб оба раза (это тоже случайно) выбирает неверный, диагональный анализатор, в результате чего результаты его измерений — случайны, что и представлено на рисунке: в 6-м столбце Боб получил 0, а в 7-м — 1. Оба эти результата при формировании ключа будут отброшены из-за того, что был выбран неверный анализатор.

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

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

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

Если Алиса и Боб не собираются использовать полученный ими ключ сразу, то перед ними возникает новая проблема, — как сохранить ключ в секрете? В 1991 г. Артур Экерт (Artur Ekert) предложил протокол, позволяющий решить обе эти проблемы — распространения и хранения ключа. Протокол Экерта основан на эффекте сцепления квантовых частиц. Сцепленные частицы ведут себя необычном образом: если произвести измерение одной из них, то другая (на каком бы расстоянии она ни находилась) обязательно «перейдет» в состояние, противоположное состоянию первой частицы. Парадокс заключается в том, что информация о состоянии частицы передается со скоростью, превышающей скорость света. Тем не менее, это явление демонстрируется физиками экспериментально и может быть использовано для шифрования информации.

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

Введение в криптографию

Криптография — это искусство скрытия информации в последовательности битов от любого несанкционированного доступа. Для достижения этой цели используют шифрование: сообщение с помощью некоторого алгоритма комбинируется с дополнительной секретной информацией (ключом), в результате чего получается криптограмма. Долгое время способы разработки алгоритмов шифрования определялись исключительно хитростью и изобретательностью их авторов. И лишь в ХХ веке этой областью заинтересовались математики, а впоследствии — и физики.
Для любой системы передачи информации характерны следующие действующие лица: объекты А и Б, обменивающиеся информацией (будем называть их Алиса и Боб — Алиса передает информацию Бобу), и некто Е, пытающийся перехватить эту информацию (в дальнейшем — Ева). Задача заключается в том, чтобы исключить возможность расшифровки информации Евой. Однако на практике это жесткое требование заменяется более мягким: необходимо сделать расшифровку сообщения достаточно трудной для Евы.
Классический подход состоит в том, что ключ, использующийся как для шифровки, так и для расшифровки сообщения, должен быть известен только Алисе и Бобу. Такие системы называются криптосистемами с закрытым ключом. Надежность процедуры шифрования доказана только для метода «одноразовых блокнотов», предложенного в 1917 году Гильбертом Вернамом (Gilbert Vernam). Идея его состоит в том, что Алиса и Боб обмениваются набором общих секретных ключей, каждый из которых используется для шифрования только одного сообщения. Ключи генерируются случайно и никакой информации не несут. Процесс шифровки состоит в том, что каждый символ исходного сообщения «складывается» с соответствующим символом ключа (так что ключ должен быть достаточно длинным, а сообщение — достаточно коротким). В «докомпьютерное» время ключи хранили в блокнотах с отрывными листами (отсюда и название метода). Каждый лист блокнота уничтожался после использования.
В применении к системам телекоммуникаций возникает проблема обеспечения секретности во время обмена ключами («блокнотами»), поскольку ключ должен быть доставлен получателю сообщения заранее и с соблюдением строгой секретности. Иначе говоря, конфиденциально обменяться сообщениями позволяют ключи, но как обменяться самими ключами с обеспечением секретности? Сформулированную таким образом проблему называют проблемой распространения ключа.
Если используется постоянный закрытый ключ, то расшифровка сообщения зависит от вычислительной мощности системы и времени. В США, например, для шифрования используется стандарт DES (Data Encryption Standard), разработанный в 1977 году. Он основан на 56-битном ключе, при помощи которого можно закодировать 64 бит информации. На этом стандарте основывается защита банковских транзакций, паролей Unix-систем и других секретных данных. Поскольку длина ключа меньше, чем длина кодируемого сообщения, то механизм защиты не является абсолютно надежным. Если попытаться угадать ключ методом проб и ошибок, нужно перебрать 256 всевозможных значений. И хотя этот объем вычислений очень велик, в настоящее время уже имеются данные о возможности взлома подобных систем. Рекордное время составляет 22 часа 15 минут при распределенной обработке информации в компьютерной сети ().
Теория шифрования с использованием открытого ключа была создана Уэтфилдом Диффи (Whitfield Diffie) и Мартином Хеллманом (Martin Hellman) в 1976 г. В этой системе Боб имеет общедоступный код для шифрования и закрытый код для расшифровки сообщений. Криптосистемы с открытым ключом основываются на так называемых односторонних функциях:
по некоторому x легко вычислить функцию f(x), но зная f(x) трудно вычислить х.
Первый алгоритм, основанный на теории Диффи-Хеллмана, был предложен Роном Райвестом (Ron Rivest), Эди Шамиром (Adi Shamir) и Леонардом Эдлманом (Leonard Adleman) в 1977 г (RSA-алгоритм). Он основан на разложении простого числа на множители. Известно, что вычислить произведение двух простых чисел легко. В то же время, обратная задача – разложение числа на простые множители, достаточно трудоемка, поскольку время вычислений экспоненциально возрастает при увеличении количества битов в исходном числе. Хотя в настоящее время не опубликованы быстрые алгоритмы решения задачи разложения числа на простые множители, нельзя утверждать, что они не существуют вовсе. Кроме того, вычислительная мощность компьютерных систем постоянно возрастает, поэтому сложность задачи не означает ее неразрешимость. Так, компания RSA, основанная вышеперечисленными авторами алгоритма, предлагает всем желающим разложить на простые множители представленные ею числа. Один из последних отчетов компании посвящен разложению числа, состоящего из 155 цифр. Эта задача требует 35,7 процессорных года, что примерно эквивалентно 8000 MIPS-лет3; в реальном времени потребовалось 3,7 месяца благодаря распределенной обработке информации в компьютерной сети.
Таким образом, на настоящий момент единственно надежным методом шифрования является метод «одноразового блокнота», поскольку доказана его безусловная секретность, то есть секретность по отношению к шпиону, который обладает неограниченными временем и вычислительной мощностью. На пути к достижению такого уровня секретности, стоит проблема распространения ключа: Алиса и Боб должны обменяться ключом, сохранив его в полном секрете. Одним из ее решений является разработанный Чарльзом Беннетом (Charles Bennett) и Джилом Брассардом (Gilles Brassard) протокол квантового распространения ключа (quantum key distribution).

Режимы шифрования

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

Соглашения и термины

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

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

Далее будут рассмотрены пять режимов шифрования так, как они представлены в документе [1], изданном НИСТ США и озаглавленном "Рекомендации для режимов шифрования с блочным шифром". Это отнюдь не единственный документ изданный НИСТ касательно режимов шифрования. До этого был издан документ, описывающий четыре режима для блочного шифра DES, а также другой документ – для тройного DES (Triple DES algorithm или TDEA), в котором описано семь режимов, три из которых являются лишь вариацией на тему тех же режимов, что были описаны для DES. Основным достоинством последнего изданного документа [1] является во-первых то, что его рекомендации относятся к любому, одобренному НИСТ блочному шифру, и во-вторых в нём описан ещё один режим шифрования – пятый. Вот эти режимы:

ECB (Electronic Code Book) – електронная кодовая книга

CBC (Cipher Block Chaining) – сцепление блоков по шифротексту

CFB (Cipher Feed Back) – обратная загрузка шифротекста

OFB (Output Feed Back) – обратная загрузка выходных данных.

CTR (Counter) – шифрование со счётчиком

Электронная кодовая книга



Данный режим является электронным аналогом режима, использовавшегося агентами для отправки зашифрованного сообщения ещё в начале XX века. Агент получал блокнот, каждая страница которого содержала уникальную последовательность – код с помощью которого и зашифровывалось сообщение. После использования такая страница вырывалась из блокнота и уничтожалась. При необходимости сообщение дополнялось так, чтоб на вырываемых страничках не оставалось не использованного кода. Принимающая сторона имела копию блокнота, поэтому, при условии синхронного использования страниц такой режим шифрования обеспечивал как зашифрование так и расшифрование сообщений. В ECB использованию одной страницы кодовой книги при зашифровании соответствует применение к входным данным преобразования функцией , а при расшифровании - . Обоим сторонам для того, чтобы синхронизироваться достаточно договориться о значении секретного ключа K . Вобще этот режим является самым простым и первым приходящим на ум способом использования блочного шифра для шифрования сообщений. Он проиллюстрирован на рис.1.



Рис. 1. Режим шифрования електронная кодовая книга – ECB.

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

ECB зашифрование: , где j=1…n

ECB расшифрование: , где j=1…n

В уравнениях приняты следующие обозначения:

Pj

– очередной, j-ый блок открытого текста (на рисунке – PLAINTEXT).

Cj

– очередной, j-ый блок шифротекста (на рисунке – CIPHERTEXT).

Таким образом шифрование происходит блоками, соответствующими размеру входных/выходных данных для функций и . Блоки шифруются отдельно и независимо друг от друга, что позволяет делать это параллельно. Это достоинство режима ECB и его простота скрадываются двумя значительными недостатками. Первый – то, что длина сообщения должна быть кратна длине блока входных данных блочного шифра, то есть всё сообщение либо можно разбить на целое число таких блоков, либо необходимо каким-то образом дополнять последний блок не несущими информацию данными. Второй недостаток ещё более существенный. Поскольку при зашифровании очередной блок шифротекста полностью определяется только соответствующим блоком открытого текста и значением секретного ключа K, то одинаковые блоки открытого текста будут преобразовываться в этом режиме в одинаковые блоки шифротекста. А это иногда нежелательно, так как может дать ключ к анализу содержания сообщения. Например, если шифруются данные на жёстком диске, то пустое пространство будет заполнено одинаковыми байтами, оставшимися там от форматирования диска. А значит по шифротексту можно будет догадаться о размере полезной информации на диске. В таких случаях нужно применять другие режимы шифрования.




Сцепление блоков по шифротексту



В режиме шифрования CBC происходит "сцепливание" всех блоков сообщения по шифротексту. Как это достигается – видно из рисунка 2, иллюстрирующего этот режим шифрования.

Как видно из рисунка в алгоритме шифрования на вход функции каждый раз подаётся результат суммирования по модулю 2 открытых данных очередного блока сообщения (на рисунке – PLAINTEXT) и выходных данных (на рисунке – OUTPUT BLOCK) функции для предыдущего блока. Поскольку выходные данные функции для очередного блока идут прямо на выход алгоритма CBC, то есть являются шифротекстом этого блока и одновременно поступают на вход этой же функции для зашифрования последующего блока, то говорят, что происходит сцепление блоков по шифротексту. Первый блок открытых данных суммируется с т.н. вектором инициализации, речь о котором пойдёт ниже. Пока же достаточно понимать, что этот вектор инициализации становится известен как отправителю, так и получателю в самом начале сеанса связи (поэтому зачастую его называют просто синхропосылкой). Расшифрование происходит, соответственно, в обратном порядке – сначала к шифротексту применяют функцию , а затем суммируют с предыдущим блоком шифротекста для получения на выходе алгоритма очередного блока открытого текста. Первый блок открытого текста, опять же, восстанавливается с помощью вектора инициализации. Таким образом весь алгоритм может быть выражен в виде уравнений следующим образом:

CBC зашифрование:

CBC зашифрование:

В уравнениях приняты следующие обозначения:

IV

– вектор инициализации (на рисунке – Initialization Vector);

Pj

– очередной, j-ый блок открытого текста.

Cj

– очередной, j-ый блок шифротекста.

Поскольку, как наглядно следует из рисунка, в режиме CBC при зашифровании каждая итерация алгоритма зависит от результата предыдущей итерации, то зашифрование сообщения не поддаётся расспараллеливанию. Однако в режиме расшифрования, когда весь шифротекст уже получен, функции вполне можно исполнять параллельно и независимо для всех блоков сообщения. Это даёт значительный выигрыш по времени. В этом режиме стоит остановиться ещё на одной детали. Дело в том, что последний блок шифротекста, который получается на выходе алгоритма режима CBC зависит как от ключа блочного шифра и вектора инициализации, так и (что важнее в данном случае) от всех бит отрытого текста сообщения. А это означает, что этот последний блок шифротекста можно использовать как своего рода идентификатор сообщения. Такой идентификатор не даёт постороннему наблюдателю никакой информации о содержимом всего сообщения в целом, и в то же время, практически однозначно определяет его (сообщение). Более того подделать этот идентификатор без знания ключа шифрования K так же трудно, как и правильно угадать сам ключ. Этот идентификатор широко используется для аутентификации сообщений и отправителей и носит название MAC (Message Authentication Code), в русскоязычной литературе – КАС (код аутентификации сообщения).




Обратная загрузка шифротекста



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

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

Таким образом, длина всего сообщения теперь должна быть кратна не b а s, что означает меньшее количество бит необходимое для выравнивания сообщения. Варьируя величину s можно изменять скорость работы прогаммы, реализующей режим шифрования CFB. Например, если известно, что пропускная способность канала передачи данных ограничена (или программа выдаёт текст сообщения для зашифрования с определённой скоростью), тогда, с учётом этих ограничений, можно подобрать такое значение s, что пропускная способность канала будет использоваться наиболее эффективно (либо текст сообщения будет обрабатываться с оптимальной скоростью). Но за всё приходиться платить – и теперь, поскольку за одну итерацию алгоритма шифрования преобразуется меньшее число бит, то таких итераций потребуется больше. Отношение характеризует количество "холостой" работы блочного шифра.


Уравнения режима шифрования CFB приведены ниже:

CFB зашифрование:

-----------------------------------------------------

CFB расшифрование:

В уравнениях приняты следующие обозначения:

IV

– вектор инициализации;

Pj

– очередной, j-ый блок открытого текста.

Cj

– очередной, j-ый блок шифротекста.

LSBm (

X) - m младших бит (less significant bits) двоичного числа X

MSBm (

X) - m старших бит (most significant bits) двоичного числа X

X

| Y – конкатенция битовых строк, представленных числами X и Y,

напр. 01 | 1011 = 011011

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



Обратная загрузка выходных данных



Режим OFB, как и CFB является поточным, то есть функция вызывается в алгоритме до суммирования с порцией открытого текста. Но на этот раз на вход подаётся не шифротекст с предыдущей итерации, а просто её же выходные данные. Иллюстрация режима приведена на рисунке 4. То есть происходит как бы зацикливание функции . В такой ситуации становится важным однократное использование вектора инициализации. И вот почему. Допустим два различных сообщения шифруются в режиме OFB с использованием одного и того же вектора инициализации. Тогда, если противнику становится известен какой-либо j-ый блок открытого текста первого сообщения, то, имея j-ый блок шифротекста он легко может вычислить Oj – выходные данные , а поскольку они зависят только от вектора инициализации, который одинаков для обоих сообщений, то можно утверждать, что и во втором сообщении это будет тот же Oj , отсюда, имея j-ый блок шифротекста второго сообщения противник тутже получит открытый текст j-го блока второго сообщения. Поэтому в алгоритме OFB необходимо избегать не только повторения векторов инициализации, но и того, что бы любой j-ый блок входных данных функции для одного сообщения не использовался как вектор инициализации для другого сообщения.


Ниже приведены уравнения для за- и расшифрования в режиме OFB:

OFB зашифрование:

-----------------------------------------------------

OFB расшифрование:

В уравнениях приняты следующие обозначения:

IV

– вектор инициализации;

Pj

– очередной, j-ый блок открытого текста.

Cj

– очередной, j-ый блок шифротекста.

MSBr (

X) - r старших бит (most significant bits) двоичного числа X

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



Шифрование со счётчиком



В потоковом режиме шифрования со счётчиком на каждой итерации алгоритма шифрования на вход функции подаётся некое случайное значение Т. Эти входные данные должны быть различны для всех итераций алгоритма в которых блочный шифр использует один и тот же ключ шифрования, поэтому генератор таких значений иногда называют счётчиком (что даёт наиболее простой способ генерации уникальных значений T). На самом деле требование уникальности входных данных функции при определённом значении K будет удовлетворено и в случае использования ГПК (генератора псевдослучайных кодов), но тогда необходим начальный вектор инициализации для ГПК со стороны отправителя и получателя сообщений. Режим шифрования CTR проиллюстрирован на рисунке 5.

Таким образом шифротекст в алгоритме режима CTR получается суммированием по модулю 2 очередного блока открытого текста с выходными данными функции . На вход функции подаётся очередное значение Tj счётчика блоков сообщения. Расшифрование происходит также путём суммирования по модулю 2 очередного блока шифротекста и результата преобразования функцией очередного значения счётчика Tj. Обе операции за- и расшифрования в режиме CTR можно производить параллельно и независимо для всех блоков. Кроме того в этом режиме также отсутствует проблема последнего блока. Это видно из уравнений режима CTR:


CTR зашифрование:

---------------------------------------------------

CTR расшифрование:

В уравнениях приняты следующие обозначения:

Pj

– очередной, j-ый блок открытого текста.

Cj

– очередной, j-ый блок шифротекста.

MSBr (

X) - r старших бит ( most significant bits) двоичного числа X

Режим CTR обладает всеми достоинствами режима ECB (параллельное исполнение, простота и возможность непосредственного за- и расшифрования любого блока сообщения по отдельности и независимо от других блоков). Но кроме того, режим CTR исправляет все недостатки шифрования в режиме электронной кодовой книги: одинаковые блоки открытого текста теперь уже не будут преобразованы в одинаковые блоки шифротекста; отпадает необходимость дополнения последнего блока шифротекста. К тому же в этом режиме (как в любом поточном режиме) используется только функция зашифрования , а для некоторых блочных шифров (например для AES – нового американского стандарта блочного шифра), это даёт некоторый выигрыш в производительности. Вот почему этот режим зачастую является наиболее эффективным.



Вектор инициализации



В таких режимах шифрования, как CBC, CFB и OFB на вход функций и подаётся вектор инициализации (IV). Причём как отправитель, так и получатель в начале сеанса связи должны иметь один и тот же IV. Значение IV вовсе не обязано быть секретным и вполне может быть передано вместе с первым блоком шифротектса. Что действительно важно, так это то, что в режимах CBC и CFB это значение должно быть непредсказуемым, а в режиме OFB – уникальным.

Непредсказуемости в режимах CBC и CFB можно достичь несколькими способами. Например, можно подвергнуть преобразованию той же функцией значение какого-либо счётчика (скажем счётчика сообщений). Или использовать ГПК для генерации псевдослучайной последовательности нужной длины.

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




Накопление ошибок в различных режимах шифрования



Прежде всего – что такое ошибка. Ошибкой в бите данных будем называть подмену бита со значением "1" на бит "0" и наоборот. Далее обсудим как такая ошибка может повлиять на результат применения алгоритма шифрования в различных режимах, когда она возникает в шифротексте, векторе инициализации или значении счётчика Tj в режиме CTR.

В любом режиме ошибка в пределах блока (или порции – для CFB) шифротекста ведёт к неправильному расшифрованию этого блока. Так, в режимах CFB, OFB и CTR ошибочным на выходе будет тот же бит, остальные биты останутся невредимыми. В режимах же ECB и CBC повреждённым, в зависимости от силы преобразования используемого блочного шифра, может стать любой бит с вероятностью повреждения .

В режимах ECB, OFB и CTR ошибка в бите отдельного блока шифротекста на повлияет на другие блоки при расшифровании. В режиме CBC такая ошибка приведёт к ошибке в том же бите при расшифровании следующего блока сообщения. Остальных блоков эта ошибка не коснётся. Другое дело режим CFB: здесь ошибка в одном бите порции шифротекста распространится на следующих порций шифротекста (b – длина блока входных данных функции ; s – длина порции шифротекста). К тому же при расшифровании измениться с вероятностью теперь может любой бит этих порций.

В режиме CTR ошибка в бите счётчика Tj приведёт к возможности изменения любого бита соответствующего блока шифротекста с вероятностью .

Ошибка в бите вектора инициализации также повлияет на результаты расшифрования. Так, в режиме OFB ошибка в одном бите вектора инициализации при расшифровании приведёт к полностью неверным результатам. В режиме же CFB эта ошибка при расшифровании заденет как минимум первую порцию сообщения, а как максимум (где b,s – то же, что раньше, а i – номер ошибочного бита слева) порций сообщения. Для обоих этих режимов повреждённым в затронутых блоках (порциях для CFB) может оказаться любой бит с вероятностью . В режиме CBC ошибка в бите вектора инициализации приведёт к неправильному расшифрованию лишь первого блока, да и то ошибочным окажется только один бит – остальные останутся неповреждёнными. Отсюда следует, что режим CBC подвержен нарушению защиты в случае преднамеренного изменения бита в векторе инициализации с целью изменить содержание сообщения. Поэтому в этом режиме необходимо обеспечить целостность вектора инициализации. Режимы OFB и CTR также подвержены нарушению целостности сообщения, но для них это становится возможным уже при преднамеренном изменении бита любого блока шифротекста. Поэтому в этих режимах должна быть обеспечена целостность блоков шифротекста при передаче. То же касается и режима CFB, хотя в этом режиме для любой порции шифротекста (кроме последней) нарушение её целостности может быть обнаружено по возникновению ошибок при расшифровании последущих порций шифротекста.


Таблица отражает эффект распространения ошибки во всех пяти режимах шифрования.

Эффект распространения ошибки

Режим шифрования

Эффект от ошибки в бите шифротекста

Эффект от ошибки в i-том бите вектора инициализации IV

ECB

ОЛБ при расшифровании блока

Не используется

CBC

ОЛБ при расшифровании блока

ООБ при расшифровании блока

ООБ при расшифровании блока

CFB

ООБ при расшифровании блока

ОЛБ при расшифровании блоков

ОЛБ при расшифровании блоков

OFB

ООБ при расшифровании блока

ОЛБ при расшифровании блоков

CTR

ООБ при расшифровании блока

Ошибка в счётчике ведёт к ОЛБ при расшифровании блока

В таблице приняты следующие сокращения:

ОЛБ – ошибка в любом бите, то есть повреждённым при расшифровании с вероятностью может оказаться любой бит блока (или порции).

ООБ – ошибка в одном бите, то есть при расшифровании повреждается один бит, находящийся в той же позиции, что и бит вызвавший ошибку.

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



Список использованной литературы

Recommendation for Block Cipher Modes of Operation. NIST Special Publication 800-38A. Technology Administration U.S.Department of Commerce. 2001 Edition

Защита информации в компьютерных системах и сетях. Под ред. В.Ф.Шаньгина.-М.:Радио и связь, 1999.-328с.

Communication theory of secrecy systems. C.E.Shennon.Bell System Technical Journal, vol.28, 1949.

Страничка классических блочных шифров. А.Винокуров.

Введение в криптографию. Под общ. ред. В.В.Ященко.-M.: МЦНМО: "ЧеРо", 2000.

Симметричная (секретная) методология

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

Безопасно создается, распространяется и сохраняется симметричный секретный ключ.

Отправитель создает электронную подпись с помощью расчета хэш-функции для текста и присоединения полученной строки к тексту

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

Отправитель передает зашифрованный текст. Симметричный секретный ключ никогда не передается по незащищенным каналам связи.

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

Получатель отделяет электронную подпись от текста.

Получатель создает другую электронную подпись с помощью расчета хэш-функции для полученного текста.

Получатель сравнивает две этих электронных подписи для проверки целостности сообщения (отсутствия его искажения)

Доступными сегодня средствами, в которых используется симметричная методология, являются:

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

Сети банкоматов (ATM Banking Networks). Эти системы являются оригинальными разработками владеющих ими банков и не продаются. В них также используются симметричные методологии.

Асимметричная (открытая) методология

В этой методологии ключи для шифрования и расшифровки разные, хотя и создаются вместе. Один ключ делается известным всем, а другой держится в тайне. Хотя можно шифровать и расшифровывать обоими ключами, данные, зашифрованные одним ключом, могут быть расшифрованы только другим ключом.
Все асимметричные криптосистемы являются объектом атак путем прямого перебора ключей, и поэтому в них должны использоваться гораздо более длинные ключи, чем те, которые используются в симметричных криптосистемах, для обеспечения эквивалентного уровня защиты. Это сразу же сказывается на вычислительных ресурсах, требуемых для шифрования, хотя алгоритмы шифрования на эллиптических кривых могут смягчить эту проблему. Брюс Шнейер в книге "Прикладная криптография: протоколы, алгоритмы и исходный текст на C" приводит следующие данные об эквивалентных длинах ключей.

Длина симметричного ключа	Длина открытого ключа
56 бит	384 бит
64 бита	512 бит
80 бит	768 бит
112 бит	1792 бита
128 бит	2304 бита

Для того чтобы избежать низкой скорости алгоритмов асимметричного шифрования, генерируется временный симметричный ключ для каждого сообщения и только он шифруется асимметричными алгоритмами. Само сообщение шифруется с использованием этого временного сеансового ключа и алгоритма шифрования/расшифровки, описанного в пункте 2.1.1.1. Затем этот сеансовый ключ шифруется с помощью открытого асимметричного ключа получателя и асимметричного алгоритма шифрования. После этого этот зашифрованный сеансовый ключ вместе с зашифрованным сообщением передается получателю. Получатель использует тот же самый асимметричный алгоритм шифрования и свой секретный ключ для расшифровки сеансового ключа, а полученный сеансовый ключ используется для расшифровки самого сообщения.
В асимметричных криптосистемах важно, чтобы сеансовые и асимметричные ключи были сопоставимы в отношении уровня безопасности, который они обеспечивают. Если используется короткий сеансовый ключ ( например, 40-битовый DES), то не имеет значения, насколько велики асимметричные ключи. Хакеры будут атаковать не их, а сеансовые ключи. Асимметричные открытые ключи уязвимы к атакам прямым перебором отчасти из-за того, что их тяжело заменить. Если атакующий узнает секретный асимметричный ключ, то будет скомпрометирован не только текущее, но и все последующие взаимодействия между отправителем и получателем.

Порядок использования систем с асимметричными ключами:

Безопасно создаются и распространяются асимметричные открытые и секретные ключи (см. раздел 2.2 ниже). Секретный асимметричный ключ передается его владельцу. Открытый асимметричный ключ хранится в базе данных X.500 и администрируется центром выдачи сертификатов (по-английски - Certification Authority или CA). Подразумевается, что пользователи должны верить, что в такой системе производится безопасное создание, распределение и администрирование ключами. Более того, если создатель ключей и лицо или система, администрирующие их, не одно и то же, то конечный пользователь должен верить, что создатель ключей на самом деле уничтожил их копию.

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

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

Теперь нужно решить проблему с передачей сеансового ключа получателю сообщения.

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

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

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

Теперь шифруется сеансовый ключ с использованием асимметричного алгоритма шифрования-расшифровки и асимметричного ключа получателя (полученного от CA и расшифрованного).

Зашифрованный сеансовый ключ присоединяется к зашифрованному тексту (который включает в себя также добавленную ранее электронную подпись).

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

Получатель выделяет зашифрованный сеансовый ключ из полученного пакета.

Теперь получателю нужно решить проблему с расшифровкой сеансового ключа.

Получатель должен иметь асимметричный открытый ключ центра выдачи сертификатов (CA).

Используя свой секретный асимметричный ключ и тот же самый асимметричный алгоритм шифрования получатель расшифровывает сеансовый ключ.

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

Получатель отделяет электронную подпись от исходного текста.

Получатель запрашивает у CA асимметричный открытый ключ отправителя.

Как только этот ключ получен, получатель расшифровывает его с помощью открытого ключа CA и соответствующего асимметричного алгоритма шифрования-расшифровки.

Затем расшифровывается хэш-функция текста с использованием открытого ключа отправителя и асимметричного алгоритма шифрования-расшифровки.

Повторно вычисляется хэш-функция полученного исходного текста.

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

Алгоритм обмена ключами

Как отмечено выше, алгоритм обмена ключами KEA разработан специалистамиАНБ и используется для организации распределения ключей шифрования MEKпри информационном обмене и для рассылки секретных ключей пользователям.Основным достоинством KEA является тот факт, что обе стороны могут вычислитьодин и тот же TEK самостоятельно, используя два случайных числа (A и B),собственные параметры P, Q, G и открытый ключ абонента. Когда KEA используетсяпри информационном обмене, принимающая сторона может получить все значения,необходимые для расшифрования сообщения, вместе с принятым сообщением.

Рис. 3.
Основные функции алгоритма KEA показаны на Рис.3. Заметим, что в данномалгоритме значения P, Q и G, используемые Алисой для первоначальной генерацииTEK, а Бобом для генерации TEK при получении сообщения, не передаются поканалам связи и одинаковы для всех пользователей.
Алгоритм обмена ключами KEA применим как в приложениях типа электроннойпочты, так и при информационном обмене между абонентами, логически и/илифизически соединенными между собой в режиме реального времени.
Необходимо заметить, что одно и то же сообщение, адресованное разнымабонентам, зашифровывается с использованием одного ключа MEK, однако этотключ должен быть свернут с помощью различных TEK, соответствующих получателямданного сообщения. Приложение - адресат должно просмотреть сообщение инайти TEK, предназначенный для данного пользователя, развернуть MEK и расшифроватьполученное сообщение.

Алгоритмы шифрования

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

Асимметричные алгоритмы

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

Тип	Описание
RSA	Популярный алгоритм асимметричного шифрования, стойкость которого зависит от сложности факторизации больших целых чисел.
ECC (криптосистема на основе эллиптических кривых)	Использует алгебраическую систему, которая описывается в терминах точек эллиптических кривых, для реализации асимметричного алгоритма шифрования. Является конкурентом по отношению к другим асимметричным алгоритмам шифрования, так как при эквивалентной стойкости использует ключи меньшей длины и имеет большую производительность. Современные его реализации показывают, что эта система гораздо более эффективна, чем другие системы с открытыми ключами. Его производительность приблизительно на порядок выше, чем производительность RSA, Диффи-Хеллмана и DSA.
Эль-Гамаль.	Вариант Диффи-Хеллмана, который может быть использован как для шифрования, так и для электронной подписи.

Атаки на алгоритмы

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

Периодическое повторение одних и тех же значений алгоритмами генерации случайных чисел, которые получили широкое распространение в криптографии.

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

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

Кроме того, иногда в российских журналах или телеконференциях в сети Internet и FIDOnet можно прочитать сообщения об оптимизации существующих стандартов (например, ГОСТ 28147-89 или DES), которые якобы не снижают надежности самих стандартов, а скорость работы при этом возрастает на один-два порядка. К таким сообщениям надо относиться с определенной степенью скептицизма. Выгоды от применения "оптимизированных" алгоритмов сомнительны, а вот вероятность фальсификации документов, подписанных с их помощью, увеличивается.

Атаки на аппаратное обеспечение.

Некоторые системы, в особенности, коммерческие, в вопросах безопасности полагаются на защищённое от несанкционированного доступа аппаратное обеспечение – карточки с микропроцессором (smart card), электронные бумажники, защитные заглушки и т.д. Эти системы могут предполагать, что общедоступные терминальные устройства никогда не попадут не в те руки или "не те руки" не будут обладать достаточными знаниями или оборудованием для атаки на аппаратное обеспечение. Хотя аппаратное обеспечение безопасности и является важным компонентом многих надёжных систем, мы не доверяем системам, надёжность которых базируется исключительно на предположениях о защищённости от несанкционированного доступа. Нам редко встречались работоспособные системы защиты от несанкционированного доступа, а инструменты преодоления такой защиты совершенствуются постоянно. Когда мы разрабатываем системы, использующие элементы защиты от несанкционированного доступа, мы обязательно встраиваем дополнительные механизмы обеспечения безопасности на случай, если система защиты от несанкционированного доступа не сработает.
Хронометрические атаки (timing attack) наделали много шума в прессе в 1995 году: закрытые ключи RSA могут быть восстановлены измерением относительных интервалов времени, затраченных на произведение криптографических операций. Эти атаки были успешно применены к карточкам с микропроцессорами и другим средствам надёжной идентификации, а также к серверам электронной коммерции в Сети. Counterpane, в числе других, обобщила эти методы, включая атаки на системы путём измерения уровня потребления энергии, излучения и других побочных каналов и применила их против многих алгоритмов, как с открытым ключом, так и симметричных, в "надёжных" системах идентификации. Однако мы нашли средства идентификации, вытянуть из которых секретный ключ, наблюдая за побочными каналами, нам не удалось. Связанное с этим направление исследований рассматривало анализ ошибок: преднамеренно спровоцированные ошибки криптографического процессора с целью определения секретных ключей. Эффект от таких атак может быть огромным.

Атаки на цифровую подпись

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

Атаки на криптографические модели.

Криптографическая система может быть сильна лишь настолько, насколько таковыми являются алгоритмы шифрования, алгоритмы цифровой подписи, односторонние хэш-функции и коды идентификации сообщений, на которые она опирается. Взломайте что-нибудь одно и вы взломаете систему. И как можно построить слабую структуру из крепких материалов, так и возможно построить слабую криптографическую систему из надежных алгоритмов и протоколов.
Мы часто находим системы, которые "аннулируют гарантию" своей криптографии неправильным использованием последней: не проверяя размеры значений, повторно используя случайные параметры, которые повторно использовать никогда нельзя, и т.д. Алгоритмы шифрования не всегда обеспечивают целостность данных. Протоколы обмена ключами не гарантируют получение обеими сторонами одного и того же ключа. В недавнем исследовательском проекте мы нашли, что некоторые (не все) системы, использующие связанные ключи могут быть взломаны, даже если каждый отдельный ключ безопасен. Безопасность – нечто намного большее, чем простое использование алгоритма и ожидание получить работоспособную систему. Даже хорошие инженеры, известные компании и большие усилия не гарантируют устойчивой реализации; наша работа над алгоритмом шифрования в цифровой сотовой связи в США подтвердила это.
Генераторы случайных чисел – ещё одно место, в котором часто ломаются криптографические системы. Хорошие генераторы случайных чисел сложны в разработке, так как их надёжность часто зависит от особенностей аппаратного и программного обеспечения. Многие из проверенных нами продуктов используют плохие. Криптография может быть сильной, но если генератор случайных чисел выдаёт слабые ключи, то систему взломать гораздо проще. Другие продукты используют надёжные генераторы случайных чисел, но не используют достаточно случайности для обеспечения надёжной криптографии.
Недавно Counterpane опубликовала новый класс атак на генераторы случайных чисел (), основанный на нашей работе над коммерческими моделями. Одна из самых неожиданных находок была в том, что определённые генераторы случайных чисел могут быть надёжными при использовании с одной целью, но ненадёжными для другой; обобщение анализа надёжности опасно.
В результатах другого исследования мы рассматривали взаимодействие между двумя, поодиночке надёжными криптографическими протоколами. Мы показывали, как по заданному надёжному протоколу построить другой надёжный протокол, который взломает первый при использовании с теми же ключами на том же устройстве.

Атаки на криптографию.

Порой продукты имеют изъяны в криптографической системе. Некоторые полагаются на собственные алгоритмы шифрования. Они неизменно оказываются очень слабыми. Counterpane имеет определённые достижения в области взлома известных алгоритмов шифрования, но среди "самодельных" таких достижений гораздо больше. Секретность алгоритма не является большим препятствием для анализа – в любом случае, потребуется лишь несколько дней для инженерного анализа криптографического алгоритма из исполняемого кода. Одна из проанализированных нами систем, стандарт электронной почты S/MIME 2, использовала относительно устойчивую конструкцию, но реализованную со слабым криптографическим алгоритмом. Система шифрования DVD выбрала слабый алгоритм и сделала его ещё слабее.
Мы встречали много других криптографических ошибок: реализации, повторяющие "уникальные" случайные величины, алгоритмы цифровой подписи, недостаточно тщательно проверяющие параметры, хэш-функции, изменённые так, что теряются самые важные их свойства. Мы встречали протоколы, которые использовались не так, как это было предусмотрено разработчиками и протоколы, "оптимизированные", по-видимому, тривиальными способами, что полностью лишило их надёжности.

Атаки на криптосистему

Под криптосистемой понимается не только используемый алгоритм выработки и проверки цифровой подписи, но также механизм генерации и распределения ключей и ряд других важных элементов, влияющих на надежность криптосистемы. Ее надежность складывается из надежности отдельных элементов, составляющих эту криптосистему. Поэтому в некоторых случаях нет необходимости атаковать алгоритм. Достаточно попытаться атаковать один из компонентов криптосистемы. Например, механизм генерации ключей. Если датчик случайных чисел, реализованный в криптосистеме для генерации ключей, недостаточно надежен, то говорить об эффективности такой системы не приходится. Даже при наличии хорошего алгоритма ЭЦП.
Для алгоритмов, основанных на открытых ключах, например, RSA или Эль-Гамаля, существует ряд математических проблем, которые не всегда учитываются при построении криптосистемы. К таким моментам можно отнести выбор начальных значений, на основе которых создаются ключи. Есть определенные числа, которые позволяют очень быстро вычислить секретный ключ ЭЦП. В то же время правильный выбор начальных значений позволяет гарантировать невозможность "лобовой" атаки в течение нескольких сотен лет при современном развитии вычислительной техники.

Атаки на модели доверия.

Многие из более интересных наших атак были направлены на модели доверия, лежащие в основе системы: кому или чему доверяет системы, каким образом и до какой степени. Простые системы, такие как программы шифрования содержимого жёстких дисков или продукты для обеспечения секретности телефонных переговоров, обладают простыми моделями доверия. Сложные системы, такие как системы электронной коммерции и многопользовательские системы безопасности электронной почты, имеют сложные (и тонкие) модели доверия. Программа для работы с электронной почтой может использовать невзламываемое шифрование, но пока ключи не подтверждены достоверным источником (или пока такое подтверждение не может быть проверено), система остаётся уязвимой. Некоторые коммерческие системы могут быть взломаны путём сговора продавца и покупателя, или двух разных покупателей. Другие системы делают неявные предположения о инфраструктуре обеспечения безопасности, не заботясь о проверке подлинности этих предположений. Если модель доверия не документирована, инженер может неосознанно изменить её на стадии разработки продукта и, тем самым, скомпрометировать систему обеспечения безопасности.
Многие программные системы делают неверные предположения относительно компьютеров, на которых они запущены, – они предполагают, что компьютер надёжен. Такие программы часто могут быть взломаны "троянскими конями" - программами, которые подсматривают пароли, читают открытые сообщения или обходят систему безопасности иным путём. Системы, работающие через вычислительную сеть, должны предусматривать дефекты систем безопасности, вызываемые сетевыми протоколами. Компьютеры, подключённые к Internet также уязвимы. Криптография может оказаться неуместной, если её можно обойти, воспользовавшись ненадёжностью сети. И не существует программного обеспечения, устойчивого к декомпиляции.
Часто система разрабатывается с расчётом на одну модель доверия, а реализуется с другой. Решения, принятые в процессе разработки могут быть полностью проигнорированы к моменту продажи конечному потребителю. Система, надёжная в случае использования надёжными операторами на компьютерах, находящихся под полным контролем компании, использующей систему, может оказаться ненадёжной, если операторы – временные работники с предельно низким жалованьем, а компьютеры не заслуживают доверия. Хорошие модели доверия работают даже тогда, когда одно из предположений о доверии перестаёт быть верным.

Атаки на пароли.

Многие системы взламываются из-за того, что полагаются на пароли, созданные пользователями. Предоставленные сами себе, люди не склонны к выбору надёжных паролей. Если заставить их использовать надёжные пароли, то они будут их забывать. Когда пароль становится ключом, то, обычно, проще и быстрее угадать пароль, нежели подобрать ключ – мы встречали доскональные системы, терпевшие на этом пути неудачу. Некоторые интерфейсы пользователя только усугубляют проблему, ограничивая длину пароля восемью символами, преобразовывая всё к нижнему регистру и т.д. Даже идентификационная фраза (многословный вариант пароля) может оказаться ненадёжной: поиск среди фраз из 40 символов обычно гораздо проще поиска среди произвольных ключей длиной 64 бита. Нам также встречались системы восстановления ключей, которые дискредитировали надёжные сеансовые ключи использованием слабых паролей для восстановления ключа.

Атаки на пользователей

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

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

Атаки на реализации.

Многие системы рушились из-за ошибок в реализации. Некоторые системы не убеждаются в уничтожении открытого текста после шифрования. Другие системы используют временные файлы, чтобы защититься от потерь данных, связанных с крахом системы, или виртуальную память, чтобы расширить объём доступной памяти; эти возможности могут случайно оставить открытый текст валяющимся на жёстком диске. В особых случаях операционная система может оставить ключи на жёстком диске. В одном из рассмотренных продуктов использовалось специальное окно для ввода пароля. Пароль оставался в памяти окна даже после его закрытия. И не важно, насколько хороша была криптография продукта, – он был взломан через интерфейс пользователя.
Другие системы терпели поражение от менее явных проблем. Иногда одни и те же данные шифровались двумя разными ключами, одним сильным и одним слабым. Другие системы использовали главные ключи и, затем, одноразовые сеансовые ключи. Мы взломали их с помощью частичной информации о разных ключах. Мы также встречали системы с неадекватными механизмами защиты главных ключей, ошибочно полагающихся на надёжность сеансовых ключей. Жизненно важно перекрыть все возможные пути изучения ключа, а не только самые очевидные.
Системы электронной коммерции часто идут на компромисс в вопросах реализации с целью обеспечения простоты использования. Здесь мы находили скрытые слабые места, появившиеся из-за того, что разработчики не продумывали тщательно влияние этих компромиссов на безопасность. Наверное, проводить согласование счетов раз в день проще, но какой вред может нанести злоумышленник за несколько часов? Возможно ли переполнение механизмов контроля, с целью скрыть личность злоумышленника? Некоторые системы хранят скомпрометированные ключи в рабочих списках (hotlists) – атака на такие списки может быть очень плодотворной. Другие системы могут быть взломаны посредством replay-атак: повторным использованием старых сообщений или их частей с целью обмана различных механизмов.
Системы, которые допускают восстановление ключей в экстренной ситуации, предоставляют ещё одно направление для атаки. Хорошие криптографические системы разрабатываются с таким расчётом, чтобы время жизни ключа было как можно короче. Восстановление ключей зачастую сводит на нет усилия по повышению надёжности, заставляя ключ существовать дольше, чем требуется. Более того, базы данных восстановления ключей являются источниками уязвимостей сами по себе и должны разрабатываться и реализовываться с учётом требований безопасности. В одном из рассмотренных продуктов дефект базы данных восстановления ключей давал преступникам возможность для мошенничества с возможностью свалить всё на законных пользователей.

Атаки на реализацию

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

Секретный ключ ЭЦП хранится на жестком диске.

После завершения работы системы ЭЦП, ключ, хранящийся в оперативной памяти, не затирается.

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

Открыт доступ к "черным спискам" скомпрометированных ключей.

Отсутствует контроль целостности программы генерации или проверки ЭЦП, что позволяет злоумышленнику подделать подпись или результаты ее проверки.

В качестве примера атаки на реализации систем ЭЦП можно назвать случай, описанный в середине 90-х годов в отечественной прессе и связанный с устанавливаемой "закладкой" в широко распространенную программу PGP.
Вопросы, касающиеся атак на аппаратную реализацию, в данной публикации рассматриваться не будут в связи с тем, что в России практически нет средств, реализующих цифровую подпись на аппаратном уровне. Можно добавить, что существуют варианты атак на аппаратные элементы хранения ключей ЭЦП (таблетки Touch Memory, смарт-карты и т.п.). Такого рода атаки получили очень широкое распространение в последнее время.

Атаки на восстановление после сбоя.

Сильные системы проектируются с таким расчётом, чтобы не дать небольшим проблемам с системой безопасности стать большими. Восстановление ключа к одному файлу не должно давать злоумышленнику возможности читать все файла на жёстком диске. Хакер, разобравший смарт-карту не должен иметь возможности найти пути к взлому других смарт-карт в системе. В многопользовательской системе знание секретов одного не должно компрометировать других.
Многие системы по умолчанию находятся в небезопасном режиме. Если функция системы безопасности не работает, большинство людей просто отключают её и занимаются своими делами. Если система проверки кредитных карточек в реальном времени отключена, придётся воспользоваться менее надёжной "бумажной" системой. Аналогично, порой бывает возможно устроить атаку отката версии (version rollback attack) после того, как она была модернизирована для усовершенствования системы безопасности: требование обратной совместимости позволяет злоумышленнику вынудить использовать старый, менее надёжный протокол.
Другие системы не имеют возможности "на ходу" восстановиться после аварии. Если система безопасности взломана, то пути её исправить нет. Для систем электронной торговли, порой насчитывающих миллионы пользователей, это может оказаться чрезвычайно разрушительным. Такие системы должны быть готовы ответить на атаку и модернизировать систему безопасности, не выключая всю систему. Фраза "и компания сворачивается" - не то, что Вы хотели бы поместить в бизнес-план. Хороший проект системы учитывает действия на случай обнаружения атаки и вырабатывает пути локализации повреждения и восстановления после атаки.

Цифровая подпись

Для контроля целостности передаваемых сообщений, обеспечения подлинностии невозможности отрицания авторства технология Fortezza использует алгоритмцифровой подписи Digital Signature Algorithm (DSA) и алгоритм хешированияSecure Hash Algorithm (SHA-1), соответствующие стандарту NIST Digital SignatureStandard (DSS).
Процесс генерации цифровой подписи показан на Рис.4.

Рис.4.
После вычисления хэш-функции сообщения, 20-байтный хэш-блок преобразуетсяс помощь алгоритма DSA в цифровую подпись сообщения размером 40 байт. Необходимообратить внимание на различия в использовании параметров P, Q и G в алгоритмахраспределений ключей KEA и цифровой подписи DSA. При проверке цифровойподписи послания Алисы Боб должен иметь доступ к значениям P, Q и G Алисы.Эти параметры должны распространяться либо в заголовке сообщения, либовместе с открытым ключем Алисы. (В целях снабжения каждого пользователянабором собственных значений P, Q и G прикладная библиотека CI_Libraryимеет соответствующие функции загрузки этих значений.) Такое различие виспользовании этих параметров связано с возможностью DSA, в отличии отKEA, поддерживать информационный обмен между пользователями различных "доменов",которые могут различаться процедурами распространения и сертификации ключей.
На момент создания технологии Fortezza не существовало правительственныхили промышленных стандартов временных меток цифровой подписи. Для "привязки"сообщений ко времени их создания применяется дополнительная процедура вычисленияхэш-функции от хэш-блока сообщения и текущего времени, взятого из надежногоисточника (например, криптокарты Fortezza). Необходимо заметить, что значенияP, Q и G, используемые алгоритмом DSA при вычислении подписи с применениемвременных меток, являются общими для всех карт Fortezza и записываютсяв память производителем криптокарты. Поскольку проверка цифровой подписив случае применения временной метки связана с необходимостью синхронизацииисточников времени, вычислением времени доставки сообщения и рядом другихсложностей, использование временных меток в технологии Fortezza не являетсяобязательным.

Хэш-функции

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

Тип	Описание
MD2	Самая медленная, оптимизирована для 8-битовых машин
MD4	Самая быстрая, оптимизирована для 32-битных машин Не так давно взломана
MD5	Наиболее распространенная из семейства MD-функций. Похожа на MD4, но средства повышения безопасности делают ее на 33% медленнее, чем MD4 Обеспечивает целостность данных Считается безопасной
SHA (Secure Hash Algorithm)	Создает 160-битное значение хэш-функции из исходных данных переменного размера. Предложена NIST и принята правительством США как стандарт Предназначена для использования в стандарте DSS

Хэш-функция

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

Хранение ключей

Согласно правилу Киркхоффа, сформулированному на рубеже 19 и 20 веков, надежность (стойкость) шифра и, как следствие, стойкость цифровой подписи, должна определяться только секретностью ключа, используемого для шифрования или подписи сообщения. Как следствие, секретные ключи никогда не должны храниться в явном виде на носителях, которые могут быть скопированы. Во многих существующих разработках этим условием пренебрегают, оставляя защиту секретных ключей на совести пользователя системы ЭЦП. В некоторых случаях, разработчики предлагают варианты хранения на носителях, которые, по их словам, трудно копируются. Например, таблетки Touch Memory, смарт-карты или бесконтактные карты Proximity. Однако в последнее время за рубежом участились случаи "удачных" атак на такие носители. Эти случаи преимущественно зафиксированы за рубежом, но российские "умельцы" ни в чем не уступают своим западным коллегам, и можно предсказать, что скоро случаи попыток "взлома" аппаратных носителей будут зафиксированы и в России.
Для повышения надежности таких схем хранения рекомендуется секретные ключи шифровать на других ключах, которые в свою очередь, могут быть тоже зашифрованы. Самый последний ключ в этой иерархии называется главным или мастер-ключом и не должен шифроваться. Однако к нему предъявляются очень жесткие требования к хранению в защищенной части компьютера или аппаратуры, реализующей функции цифровой подписи.

История создания криптокарты Fortezza

Технология "Fortezza Cryptographic Card", разработанная вАНБ США, представляет собой стандартное устройство PC-card (раньше этостандарт назывался PCMCIA), предназначенное для реализации аутентификациии шифрования в соответствии со стандартами правительства США. Карты Fortezzaприменяются в системе электронной связи Defence Message System (DMS) МОСША, в поисковой системе Intelink разведывательного сообщества правительстваСША, использующей технологии WWW, а также в других правительственных системах[5].
Работы по созданию Fortezza были начаты в 1991 году в рамках программыPre Message Security Protocol (PMSP) [6]. Перед специалистами АНБ былапоставлена задача разработать технологию защиты информации, не имеющейгрифа секретности, но являющейся служебной тайной организации. Первоначальнойцелью этого проекта являлось создание недорогого устройства, выполненногов стандарте "smart card" и обеспечивающего: целостность данных,шифрование данных, идентификацию и аутентификацию источника данных. Кромеэтого, необходимо было предусмотреть возможность совместимости с существующимистандартами (например, с протоколом распространения ключей X.509), обеспечитьработу мобильных пользователей, предоставить средства расширяемости архитектурыдля поддержки потенциально большого числа пользователей (до 4-х миллионов).Первоначальными областями применения технологии Fortezza виделись защитаэлектронной почты и другого электронного информационного обмена, осуществляемогопо открытым каналам связи, а также контроль доступа к системам и их компонентам.
За время развития технология несколько раз меняла свое название. Какуже говорилось, в 1991 году программа Fortezza называлась Pre Message SecurityProtocol, а само криптографическое устройство разрабатывалось в соответствиисо стандартом "smart card". В 1993 году название программы былоизменено на "MOSAIC", тип криптографического устройства измененна PC Card, а сама PC-карта получила название "Tessera Crypto Card".Затем, в 1994 году, программа была влита в объединенный проект АНБ и Агентстваинформационных систем МО США (DISA) Multi-Level Information Systems SecurityInitiative (MISSI). После этого название технологии было изменено на "Fortezza"и PC-карта переименована в "Fortezza Crypto Card".
Технология Fortezza обладает двумя важными свойствами, делающими возможнымее широкое распространение (если только это распространение не оказываетсяв сфере действия экспортных ограничений). Первым таким свойством является"персонализация" средств обеспечения безопасности. Каждый пользовательснабжается индивидуальным криптографическим устройством, PC-картой. ЭтаPC-карта содержит уникальную для каждого конкретного лица ключевую информациюи связанные с ней данные, а также выполняет заложенные в нее криптографическиеалгоритмы. Создатели карты Fortezza проделали большую работу по разработкесложной системы генерации, распределения и управления криптографическимиключами. Особое внимание было уделено контролю целостности данных картыи распространению требуемой криптографической и системной информации.
Вторым свойством является наличие открытого прикладного программногоинтерфейса (API). Аппаратные и программные спецификации карты разрабатывалисьс учетом требований к открытой системе. Это позволяет осуществлять простуюинтеграцию технологии Fortezza в большинство аппаратных платформ, коммуникационныхсредств, операционных систем, пакетов прикладных программ и сетевых протоколови архитектур. Кроме этого, подход Fortezza избавляет разработчиков программныхсредств от необходимости встраивать в прикладные программы сложные криптографическиеподсистемы. Достаточно воспользоваться PC-картой Fortezza, которой можноуправлять через API CI_Library [7].

Электронные подписи и временные метки

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

Тип	Комментарии
DSA (Digital Signature Authorization)	Алгоритм с использованием открытого ключа для создания электронной подписи, но не для шифрования. Секретное создание хэш-значения и публичная проверка ее - только один человек может создать хэш-значение сообщения, но любой может проверить ее корректность. Основан на вычислительной сложности взятия логарифмов в конечных полях.
RSA	Запатентованная RSA электронная подпись, которая позволяет проверить целостность сообщения и личность лица, создавшего электронную подпись. Отправитель создает хэш-функцию сообщения, а затем шифрует ее с использованием своего секретного ключа. Получатель использует открытый ключ отправителя для расшифровки хэша, сам рассчитывает хэш для сообщения, и сравнивает эти два хэша.
MAC (код аутентификации сообщения)	Электронная подпись, использующая схемы хэширования, аналогичные MD или SHA, но хэш-значение вычисляется с использованием как данных сообщения, так и секретного ключа.
DTS (служба электронных временных меток)	Выдает пользователям временные метки, связанные с данными документа, криптографически стойким образом.

Криптографические функции карты Fortezza

Алгоритм шифрования, применяемый в технологии Fortezza, известен подназванием SKIPJACK [8]. Этот алгоритм разработан специалистами АНБ и отвечаетстандарту депонирования ключей Escrowed Encryption Key Standard. SKIPJACKявляется блочным шифром с размером блока 8 байт, использующим симметричныеключи (т.е. для зашифрования и расшифрования применяется один и тот жеключ). Шифрование по алгоритму SKIPJACK в карте Fortezza осуществляетсяс помощью специализированного криптографического микропроцессора CAPSTONE,выполненного по RISC-технологии. Такие микропроцессоры выполняют те жефункции, что и микропроцессоры CLIPPER, применяемые для реализации алгоритмаSKIPJACK в устройствах голосовой (телефонной) связи. Обсуждение деталейреализации SKIPJACK не представляется возможным, т.к. этот алгоритм являетсязасекреченным.

Рис. 1.
В технологии Fortezza ключ шифрования данных называется Message EncryptionKey (MEK). В дополнении к этому ключу может использоваться также векторинициализации Initialization Vector (IV), который фактически является дополнительнымвходным параметром при шифровании данных. Стандартный режим алгоритма Fortezzaтребует обязательного использования IV всеми участниками информационногообмена. Это означает, что для расшифрования сообщения принимающая сторонадолжна либо иметь возможность сгенерировать точно такой же IV, которыйиспользовался отправляющей стороной при зашифровании сообщения, либо IVдолжен быть передан вместе с сообщением.
Алгоритм шифрования SKIPJACK имеет три режима работы: Electronic Codebook(ECB), Output Feedback (OFB) и Cipher Block Chaining (CBC). По умолчанию,алгоритм Fortezza использует режим CBC. В этом режиме все 8-байтные блокиоткрытого текста, кроме первого, используются для выполнения операции XORс блоком зашифрованного текста, полученным на предыдущем шаге работы алгоритмас использованием MEK. Вектор IV применяется для зашифрования первого блокаоткрытого текста.
На показан процесс посылки Алисой секретного сообщения Бобу.Для того, чтобы злоумышленник смог расшифровать сообщение Алисы, ему необходимознать не только MEK, но и IV. При этом, компрометация IV не столь существенна,если злоумышленник не обладает MEK.
Распределение ключей шифрования MEK основано на применении разработанногов АНБ алгоритма обмена ключами Key Exchange Algorithm (KEA), который посылаетзашифрованный MEK с каждым сообщением. Поскольку обмен ключами KEA интегрированв технологию Fortezza, ключи шифрования могут меняться от сообщения к сообщениюили от сеанса к сеансу. Алгоритм KEA использует для шифрования MEK специальныйключ, названный Token Encryption Key (TEK). Необходимо иметь в виду, чтов приложениях, использующих технологию Fortezza, TEK может быть использованпри шифровании данных как альтернатива ключа шифрования MEK, однако MEKне может быть использован для защиты TEK в процессе обмена ключами.



Рис. 2.

Шифрование с открытым ключем в стандартном режиме алгоритма Fortezzaиспользуется только для обмена ключами с использованием KEA и для цифровойподписи сообщений (включая временные метки). В описании алгоритма Fortezzaобычно используют следующие обозначения: 20-байтный закрытый ключ называется"X", 128-байтный открытый ключ называется "Y", P иQ - большие простые числа (секретные), G - простое число по модулю P*Q(общедоступное).

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

Криптография сегодня

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

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

Sub rosa

Информация предоставлена , сервер

Вопрос защиты переписки от несанкционированного доступа стар,
как мир, и напрямую связан с вопросом защиты нашей privacy. Люди,
эти странные существа, почему-то упорно не хотят, чтобы их письма
читали. А другие люди и правительственные учреждения многих стран
почему-то упорно желают их прочесть. Зачем нужно защищать свою
переписку от чужих глаз законопослушному гражданину, спросит автора
читатель. А за тем же, зачем вы, пользуясь обычной почтой, отправляете
обычно письма в конверте, а не почтовой открыткой.
Существует довольно много способов защиты вашей электронной почты
от чужих глаз. Автор предлагает вам выбрать подходящий, либо продолжать
сообщать всем заинтересованным лицам информацию о своих семейных,
финансовых и прочих делах. Вам решать:)
Юридические и политические аспекты использования криптографических систем в России вынесены автором на . Приглашаю резидентов РФ и всех заинтересованных людей ознакомиться с ней.
Pretty Good Privacy (PGP)
Очень сильное средство криптографической защиты. Сила PGP не в том, что
никто не знает, как ее взломать иначе как используя "лобовую атаку" (это не сила, а условие существования хорошей программы для шифровки), а в превосходно продуманном и чрезвычайно мощном механизме обработки ключей (см. ниже), быстроте, удобстве и широте распространения. Существуют десятки не менее сильных алгоритмов шифровки, чем тот, который используется в PGP, но популярность и бесплатное распространение сделали PGP фактическим стандартом для электронной переписки во всем
мире.
Обычные средства криптографии (с одним ключом для шифровки
и дешифровки) предполагали, что стороны, вступающие в переписку,
должны были в начале обменяться секретным ключом, или паролем,
если хотите, с использованием некоего секретного канала (дупло,
личная встреча etc.), для того, чтобы начать обмен зашифрованными
сообщениями. Получается замкнутый круг: чтобы передать секретный

ключ, нужен секретный канал. Чтобы создать секретный канал, нужен

ключ.

Разработанная Филипом Циммерманном программа PGP относится

к классу систем с двумя ключами, публичным и секретным. Это означает,

что вы можете сообщить о своем публичном ключе всему свету, при

этом пользователи программы смогут отправлять вам зашифрованные

сообщения, которые никто, кроме вас, расшифровать не сможет. Вы

же их расшифровываете с помощью вашего второго, секретного ключа,

который держится в тайне. Публичный ключ выглядит примерно так

:

-----BEGIN PGP PUBLIC KEY BLOCK-----

Version: 2.6.3i

mQCNAzF1IgwAAAEEANOvroJEWEq6npGLZTqssS5EScVUPVaRu4ePLiDjUz6U7aQr

Wk45dIxg0797PFNvPcMRzQZeTxYl0ftyMHL/6ZF9wcx64jyLH40tE2DOG9yqwKAn

yUDFpgRmoL3pbxXZx9lO0uuzlkAz+xU6OwGx/EBKYOKPTTtDzSL0AQxLTyGZAAUR

tClCb2IgU3dhbnNvbiA8cmpzd2FuQHNlYXR0bGUtd2Vid29ya3MuY29tPokAlQMF

EDF2lpI4h53aEsqJyQEB6JcD/RPxg6g7tfHFi0Qiaf5yaH0YGEVoxcdFyZXr/ITz

rgztNXRUi0qU2MDEmh2RoEcDsIfGVZHSRpkCg8iS+35sAz9c2S+q5vQxOsZJz72B

LZUFJ72fbC3fZZD9X9lMsJH+xxX9CDx92xm1IglMT25S0X2o/uBAd33KpEI6g6xv

-----END PGP PUBLIC KEY BLOCK-----

Вы можете опубликовать свой публичный ключ на вашей Web странице

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

вашего публичного ключа и отправит его вам. Прочесть его сможете

только вы с использованием секретного ключа. Даже сам отправитель

не сможет расшифровать адресованное вам сообщение, хотя он сам

написал его 5 минут назад. И самое приятное. На сегодня даже самым

мощным компьтерам в требуются века, чтобы расшифровать сообщение, зашифрованное с помощью PGP!

Программа PGP широко доступна в

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

Резиденты США по закону должны пользоваться либо бесплатной версией 2.6.2 , которую можно загрузить с сайта , либо только что вышедшей великолепной , написанной для различных платформ. PGP 5.0 имеет ограниченный срок бесплатного пользования (2 месяца), хотя при желании это ограничение можно обойти. Читайте


, там все описано, стоит лишь ввести ключевые слова Re crack PGP 5.0 ;)

Для всех тех, кто постоянно проживает за пределами США, главный сайт расположен . Последняя легально экспортированная версия на сегодня - это версия 2.6.3i (знак i после версии означает international). Ее также можно скачать (323К). Несмотря на запрещение экспорта версии PGP 5.0, она по старой доброй традиции была немедленно проэкспортирована из США. Поскольку незаконным является только сам экспорт, но не использование программы, автор рад сообщить вам, что версию 5.0 можно спокойно скачать с европейских сайтов

или (3.5 MB).

Сам по себе экспорт PGP из США в 1991 году, распространение программы по всему миру, судебное преследование автора, юридические хитрости, недавно использованные для законного экспорта в Европу версии 5.0 в печатном виде, и другие связанные с PGP моменты представляют из себя историю весьма занимательную. Читайте об этом на официальном сайте .

Теперь практические вопросы использования PGP. В то время как PGP 5.0 представляет из себя полноценную, имеющую графический интерфейс, программу для Windows 95 и Макинтоша, пользователи, которые по той или иной причине предпочитают использовать версии 2.xx, будут иметь дело с чисто текстовой программой, весьма неудобной в использовании. Хорошая новость: для таких версий

PGP написано множество plug-ins и front ends, делающих использование

PGP в Widows 95 делом элементарным. Часть из них собрана в

директории архива , но лучшие из опробованных автором являются следующие:

(2.43M),выпускаемый . Серьезный front end со множеством функций.

(80K), очень милая программа с набором функций, способным удовлетворить подавляющее большинство пользователей. После загрузки принимает вид такого окна:

Оба продукта шифруют и дешифруют как данные из clipboard'а, так и файлы на диске.

Напоминаю, что для пользования любым из plug-ins, front ends и shells с версиями 2.xx (но не версией 5.0, она содержит все необходимые файлы!) нужен сам файл , т.к. программы-надстройки саму PGP не содержат, так что не забудьте скачать и его.


Зашифровка информации в изображении и звуке

Этот класс продуктов позволяет прятать ваши сообщения в файлы

.bmp, .gif, .wav и предназначен для тех случаев, когда вы не хотите,

чтобы у кого-либо создалось впечатление, то вы пользуетесь средствами

криптографии. Пример подобной программы -

(273К). Программой очень легко пользоваться.

Внешне графический файл остается практически неизменным, меняются

лишь кое-где оттенки цвета. Для большей безопасности следует использовать неизвестные

широкой публике изображения, изменения в которых не бросятся

в глаза с первого взгляда, а также изображения с большим количеством

полутонов и оттенков. Использовать картину Танец Матисса - идея

плохая, т.к. все знают, как она выглядит, и кроме того она содержит

большие зоны одного цвета. А вот фотография вашего песика вполне

подойдет. Pассмотрим пример:

Левое изображение (8.9K) не содержит зашифрованной информации, правое (11.2K) содержит текст этой главы. Поразительно, правда? Нет практически никаких отличий. Соотношение между размером изображения и размером текстового файла, который можно спрятать, зависит от конкретного изображения. Иногда размер текстового файла даже превышает размер графического. Программа может использовать несколько разных сильных алгоритмов шифровки по выбору пользователя, включая довольно сильный алгоритм 3DES.

Зашифровка с помощью архиватора Pkzip

Знакомое имя, не правда ли?

позволяет архивировать

файлы с защитой паролем. Синтаксис команды описан в самом файле,

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

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


весьма удобным и быстрым способом защиты информации, хотя и обладающим

описанным выше "семейным" недостатком всех систем криптозащиты

с одним ключом.

Программы взлома, которые можно позаимствовать (требует, чтобы защищенный

паролем архив содержал как минимум 3 файла, 46K) или (24K), используют

один из двух подходов по выбору пользователя. Они либо подбирают

пароль с использованием большого словаря, либо атакуют в лоб (brute

force), перебирая все возможные комбинации. Согласно исследованиям

психологов, большинство мужчин в качестве пароля используют короткие

слова из ненормативной лексики, а женщины - имена любимых мужчин

или детей. Так что если ваша жена использует пароль Vasya, а вас

зовут Петя, это повод задуматься;) Отсюда простой вывод: используйте

пароль, который вряд ли есть в словаре, а главное - длинный (до

24 знаков), и содержащий цифры, специальные символы (?!$ etc.).

Для лобовой атаки (подбор комбинации из всех возможных) со скоростью

200 000 комбинации в секунду (примерно соответствует возможностям

PC Pentium 100) для пароля из 6 знаков расклад таков:

Набор символов	Максимальное время
только цифры	5.0 секунд
только строчные буквы	25.7 минуты
только символы	1.8 часа
строчные и заглавные буквы	27.5 часа
строчные, заглавные, цифры	3.3 дня
строчные, заглавные, цифры, символы	42.5 дня

А если длина пароля не шесть, а 24 символа? Считайте сами. Тысячелетия.

Защита документов MS Word паролем

Не используйте этот метод. Никогда. Взлом настолько прост, что

изготовитель коммерческого пакета для восстановления паролей,

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

циклы, чтобы замедлить ее работу для создания впечатления сложности

поставленной задачи.

Copyright © 1997

Криптокарта FORTEZZA - правительственные технологии в коммерческих приложениях

(обзор по материалам открытой печати)
,
17июня 1996 года компания Netscape Communications Corporation анонсировалавыпуск бета-версии SSLRef 3.0 - средства разработки приложений, обеспечивающихзащиту информационного обмена в среде Internet/Intranet с использованиемоткрытого протокола SSL 3.0 [1]. Компания Netscape начала деятельностьпо стандартизации протокола SSL (Secure Sockets Layer) еще в октябре 1994года. Группе инженерной поддержки сети Internet (IETF) в качестве основытребований к безопасности информационного обмена, обеспечиваемой на транспортномуровне, был предложен протокол SSL версии 2. При этом, было выполнено одноиз основных условий, предъявляемых к "кандидату на стандарт"- наличие коммерческой реализации протокола. Первым поколением продуктов,поддерживающих протокол SSL, стали Netscape Navigator 2.0, Netscape CommerceServer 1.0 и Netscape News Server 1.0.
Основным отличием текущей, третьей, версии протокола SSL является поддержкабольшего количества алгоритмов и аппаратных средств обмена ключевой информациейи шифрования, в том числе и технологии Fortezza, разработанной специалистамиАНБ США [2]. Поддержка криптокарты Fortezza в программных продуктах семействаNetscape была запланирована более года назад. В октябре 1995 года вице-президентNetscape Марк Андриссен (Mark Andreessen) заявил, что поддержка технологииFortezza позволит укрепить позиции компании в качестве ведущего поставщикапрограммных продуктов, использующих Web-технологии, как для федеральногоправительства США, так и для коммерческих организаций [3]. Результаты незаставили себя ждать: Netscape стала первой компанией, которой правительствоСША в июле 1996 с.г. предоставило право распространять по сети Internetпрограммное обеспечение, подлежащее экспортным ограничениям [4]. NetscapeNavigator и Netscape FastTrack Server стали первыми программными продуктами,использующими алгоритм RC4 с длиной ключа 128 бит, которые американскиепользователи могут получить по сети Internet.
В настоящее время число компаний, поддерживающих протокол SSL, значительноувеличилось. Среди них: Apple Computer, Inc., Digital Equipment Corporation,IBM, MasterCard International Inc., Microsoft Corporation, Motorola, Novell,Inc., Siemens Nixdorf, Silicon Graphics, Inc., Sun Microsystems, Inc.,Visa International и др. Существуют также и некоммерческие реализации,например WWW-сервер Apache-SSL. Широкое распространение протокола SSL делаетвозможным и необходимым более детальное ознакомление с одним из его средств- криптокартой Fortezza.

Криптосистемы

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

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

Механизмы аутентификации

Эти механизмы позволяют проверить подлинность личности участника взаимодействия безопасным и надежным способом.

Тип	Описание
Пароли или PIN-коды (персональные идентификационные номера)	Что-то, что знает пользователь и что также знает другой участник взаимодействия. Обычно аутентификация производится в 2 этапа. Может организовываться обмен паролями для взаимной аутентификации.
Одноразовый пароль	Пароль, который никогда больше не используется. Часто используется постоянно меняющееся значение, которое базируется на постоянном пароле.
CHAP (протокол аутентификации запрос-ответ)	Одна из сторон инициирует аутентификацию с помощью посылки уникального и непредсказуемого значения "запрос" другой стороне, а другая сторона посылает вычисленный с помощью "запроса" и секрета ответ. Так как обе стороны владеют секретом, то первая сторона может проверить правильность ответа второй стороны.
Встречная проверка (Callback)	Телефонный звонок серверу и указание имени пользователя приводит к тому, что сервер затем сам звонит по номеру, который указан для этого имени пользователя в его конфигурационных данных.

Методология с использованием ключа

В этой методологии алгоритм шифрования объединяет ключ с текстом для создания шифртекста. Безопасность систем шифрования такого типа зависит от конфиденциальности ключа, используемого в алгоритме шифрования, а не от хранения в тайне самого алгоритма. Многие алгоритмы шифрования общедоступны и были хорошо проверены благодаря этому (например, DES).
Но основная проблема, связанная с этой методологией, состоит в том, как сгенерировать и безопасно передать ключи участникам взаимодействия. Как установить безопасный канал передачи информации между участниками взаимодействия до передачи ключей?
Другой проблемой является аутентификация. При этом существуют две серьезных проблемы:

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

Когда участники взаимодействия получают ключи, откуда они могут узнать, что эти ключи на самом деле были созданы и посланы уполномоченным на это лицом?

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

Термин	Значение	Замечания
Симметричная методология	Используется один ключ, с помощью которого производится как шифрование, так и расшифровка с использованием одного и того же алгоритма симметричного шифрования. Этот ключ передается двум участникам взаимодействия безопасным образом до передачи зашифрованных данных.		Часто называется методологией с секретным ключом.
Асимметричная методология	Использует алгоритмы симметричного шифрования и симметричные ключи для шифрования данных Использует алгоритмы асимметричного шифрования и асимметричные ключи для шифрования симметричного ключа. Создаются два взаимосвязанных асимметричных ключа. Симметричный ключ, зашифрованный с использованием одного асимметричного ключа и алгоритма асимметричного шифрования, должен расшифровываться с использованием другого ключа и того же алгоритма шифрования. Создаются два взаимосвязанных асимметричных ключа. Один должен быть безопасно передан его владельцу, а другой - тому лицу, которое отвечает за хранение этих ключей (CA - сертификационному центру ключей), до начала их использования.		Часто называется методологией с открытым ключом
Секретный ключ(1)	Симметричная методология	Используется один ключ, с помощью которого производится как шифрование, так и расшифровка. См. выше
Секретный ключ(2)	Секретный ключ симметричного шифрования	Симметричный секретный ключ
Секретный ключ(3)	Секретный ключ асимметричного шифрования	Асимметричный секретный ключ Асимметричные ключи создаются парами, так как связаны друг с другом. Выражение "секретный ключ" часто используют для одного из пары асимметричных ключей, который должен держаться в секрете. Асимметричный секретный ключ не имеет ничего общего с симметричным секретным ключом.
Открытый ключ (1)	Асимметричная методология	Использует пару ключей, которые совместно создаются и связаны друг с другом. Все, что зашифровано одним ключом, может быть расшифровано только другим ключом этой пары.
Открытый ключ (2)	Открытый ключ асимметричного шифрования	Асимметричные ключи создаются парами, каждый из двух ключей связан с другим. Выражение "открытый ключ" часто используют для одного из пары асимметричных ключей, который должен быть всем известен.
Сеансовый ключ	Симметричный (секретный) ключ шифрования	Используется в асимметричной методологии для шифрования самих данных с помощью симметричных методологий. Это просто симметричный секретный ключ (см. выше)
Алгоритм шифрования	Математическая формула	Для симметричных алгоритмов требуются симметричные ключи. Для асимметричных алгоритмов требуются асимметричные ключи. Вы не можете использовать симметричные ключи для асимметричных алгоритмов и наоборот.
Секретные криптосистемы	Используют симметричные алгоритмы и симметричные (секретные) ключи для шифрования данных.
Открытые криптосистемы	Использует асимметричные алгоритмы и асимметричные ключи для шифрования сеансовых ключей. Используют симметричные алгоритмы и симметричные (секретные) ключи для шифрования данных.

Методы защиты информации в канале связи

Методы защиты информации в канале связи можно разделить на две группы:

основанные на ограничении физического доступа к линии и аппаратуре связи;

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

Методы первой группы в основном находят применение в системах правительственной связи, где осуществляется контроль доступа к среде передачи данных.
Методы второй группы направлены на обратимое изменение формы представления передаваемой информации. Преобразование должно придавать информации вид, исключающий ее восприятие при использовании аппаратуры, стандартной для данного канала связи. При использовании же специальной аппаратуры восстановление исходного вида информации должно требовать затрат времени и средств, которые по оценке владельца защищаемой информации делают бессмысленным для злоумышленника вмешательство в информационный процесс.
При защите обмена данными решающее значение имеет форма представления сигнала в канале связи.
Следует учесть, что деление на "аналоговый" или "цифровой" сигнал условно. Для некоторых вариантов механизмов защиты информации требуется взаимная синхронизация и обмен служебными посылками между взаимодействующей аппаратурой защиты, т.е. присутствует цифровой режим, однако, поскольку этот режим не связан непосредственно с речевым обменом, требования к его скоростным характеристикам достаточно свободны.
С другой стороны, символьный (цифровой) обмен в протяженных каналах всегда осуществляется через модемное преобразование в виде аналогового сигнала.
Попробуем провести краткий анализ вариантов угроз информации в канале связи. Для удобства анализа проведем классификацию канала связи по степени защищенности (защиты) передаваемой информации.
Полученные результаты сведем в таблицу 1. На рисунках 1, 2 изобразим структурные схемы передачи данных для соответствующих каналов на примере взаимодействия ОО (КСЗИ) с АТС и удаленным ОО (КСЗИ).

Класс защиты канала связи
Варианты угроз информации

Открытый канал	Защита информации основана на ограничении доступа к линии. Возможно несанкционированное подключение к линии. Возможен перехват: При использовании услуги "Междугородная связь по паролю" возможно перехватить этот пароль, так как он передается с помощью DTMF; Управляющей информации для/от АТС; Всех данных, передаваемых по каналу связи, вне зависимости от используемой технологии передачи; Управляющей информации ОО (удаленное управление ОО, сигнализацией и т.д. Особенно небезопасен перехват команд отключения для некоторых видов охранной сигнализации). Возможен перехват/модификация трафика и его полный анализ.
Полузакрытый канал (закрывается только информация, управляющая информация передается в открытом виде).	Защита информации основана как на ограничении доступа к линии, так и на КЗИ. Данные закрываются с использованием КСЗИ (по ГОСТ 28147-89 в любом режиме). Возможно несанкционированное подключение к линии. Возможем перехват: при использовании услуги "Междугородная связь по паролю" также возможно перехватить этот пароль (если он набирался в открытом режиме); управляющей информации для/от АТС; момента установления защищенного соединения (возможен перехват ключей); открытых данных/разговора. Возможен перехват трафика но анализ только управляющей информации и открытых данных (опять проблема перехвата команд отключения систем охранной сигнализации).

<
Таблица 1. Анализ вариантов угроз информации в канале связи.

Структурная схема передачи данных в открытом канале показана на рисунке 1.



Рисунок 1. Передача данных в открытом канале данных.



Рисунок 2. Передача данных в полузакрытом канале данных.

Примечание:

А2 - алгоритм 2, К2 - ключ алгоритма А2.

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

По сравнению с канальным, сквозное шифрование характеризуется более сложной работой с ключами, поскольку каждая пара пользователей должна быть снабжена одинаковыми ключами, прежде чем они смогут связаться друг с другом. А поскольку криптографический алгоритм реализуется на верхних уровнях модели OSI, приходится также сталкиваться со многими существенными различиями в коммуникационных протоколах и интерфейсах сети доступа (для примера: отправитель - канал ТЧ, получатель - 2B+D). Все это затрудняет практическое применение сквозного шифрования.

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

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

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


При этом злоумышленник может проводить анализ только открыто передаваемых данных, но не может нелегально использовать линию связи.

Структурная схема передачи данных в закрытом канале показана на рисунке 3.

Кратко опишем механизм взаимодействия КСЗИ и АТС (удаленной КСЗИ) в предложенном методе.

При занятии линии (получении сигнала вызова от АТС) происходит автоматический переход в закрытый режим связи (А1, К1). После перехода в закрытый режим, абонентский комплект (АК) или криптографический модуль перед АК АТС аутентифицирует КСЗИ. Данный шаг необходим для устранения возможности несанкционированного использования линии. После проведения аутентификации возможен выход из закрытого режима.

При вызове со стороны вызывающего абонента, АТС принимает адресную информацию, устанавливает соединение.

При ответе удаленной КСЗИ возможны два варианта: аутентификации удаленной КСЗИ и переход в закрытый режим (А2, К2) либо переход в закрытый режим (А2, К2) и аутентификация удаленной КСЗИ.

Аутентификация удаленной КСЗИ необходима для противодействия атаке, при которой удаленная КСЗИ злоумышленника при помощи перекоммутации выдает себя за КСЗИ легального пользователя.



Рисунок 3. Передача данных в закрытом канале данных (закрываются все данные).

Примечание:

А1 - алгоритм 1, К1 - ключ алгоритма А1;

А2 - алгоритм 2, К2 - ключ алгоритма А2.

После удачной аутентификации удаленной КСЗИ также возможен выход из защищенного режима (отказ от вхождение в защищенный режим).

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

Предъявляемые требования к взаимодействию криптоалгоритмов можно описать с помощью логического выражения:

[(А1=А2)∪(А1 А2)])∩(К1≠К2)=True

Модернизация шифра с простым вероятностным механизмом.

Copyright © Titov Oleg, 2001, .
Одним из перспективных способов повышения стойкости известных шифров является задание неопределенности хода шифрования информации. Эта идея может быть реализована путем введения случайных данных в преобразуемое сообщение. "Подмешивание" случайных данных к шифруемому сообщению позволяет задать вероятностный характер операций преобразования и тем самым повысить вычислительную стойкость криптосистемы.
Пусть E есть b-битовая функция шифрования, P есть p-битовый блок открытого текста и R - r-битовый случайный блок, где b=r+p. Подадим на вход шифрующей функции блок B = R | P , где знак "|" обозначает конкатенацию двоичных векторов R и P:
P -> B = R | P -> C = E( B, K ),
где K - ключ шифрования. Для шифрования больших объемов данных исходный текст разбивается на блоки длиной p-бит и с каждым из них проводятся вышеуказанные операции. Для каждого такого блока в простых вероятностных шифрах генерируется новый случайный вектор R. В модернизированном простом вероятностном шифре для второго и далее блоков не генерируется случайный вектор R, а случайные биты берутся из предыдущего зашифрованного блока по следующей схеме.
Пусть P=P1|P2|P3|...|Pn - преобразуемое исходное сообщение, R - случайный r-битовый вектор, тогда
B1 = R | P1 , C1' | C1 = E( B1, K ), Bi = Ci-1 | Pi , Ci' | Ci = E( Bi, K ), C=C1' | C2' | ... | Cn' | Cn
где i изменяется от 2 до n, Ci' - p-битовый вектор, Ci - r-битовый вектор.
В результате мы избавляемся от главного недостатка простых вероятностных шифров - увеличение размера зашифрованного текста в сравнении с незашифрованым в b/p раз. Переход от случайных бит к псевдослучайным, при наличии "хорошей" функции E, не является существенным недостатком, т.к. в существующих криптографических системах используются именно псевдослучайные биты.

Подпись документов при помощи криптосистем с открытыми ключами

Поиски методов, устраняющих указанные выше недостатки, велись по нескольким направлениям. Наиболее впечатляющих результатов добились криптографы-математики Уитфилд Диффи (W. Diffie) и Мартин Хеллман (M. Hellman), а также Ральф Меркль (Ralph Merkle), которые в конце 70-х годов опубликовали результаты своих исследований. В своих работах авторы показали, что существует возможность построения криптосистем, не требующих передачи секретного ключа между абонентами, участвующими в обмене защищаемой информацией. В таких криптосистемах нет необходимости и в арбитрах. Суть разработанного подхода заключается в том, что в обмене защищаемыми документами каждый абонент использует пару взаимосвязанных ключей - открытый и секретный. Отправитель подписываемого документа передает получателю открытый ключ. Он может это сделать любым несекретным способом или поместить ключ в общедоступный справочник. При помощи открытого ключа получатель проверяет подлинность получаемой информации. Секретный ключ, при помощи которого подписывалась информация, хранится в тайне от всех.
Можно заметить, что в данной схеме абоненты используют различные ключи, что не позволяет мошенничать ни одной из сторон. Подробный анализ цифровой подписи на основе криптосистем с открытыми ключами показывает, что она полностью удовлетворяет требованиям, предъявляемым к ней и указанным в начале статьи. В настоящий момент широкого известны цифровые подписи, построенные по алгоритмам RSA, Эль-Гамаля, Шнорра, Рабина и математического аппарата эллиптических кривых.

Подпись документов при помощи симметричных криптосистем

Первые варианты цифровой подписи были реализованы при помощи симметричных криптосистем, в которой абоненты, участвующие в обмене сообщениями, используют один и тоже секретный ключ для простановки и проверки подписи под документом. В качестве алгоритма криптографического преобразования может использоваться любая из симметричных криптосистем, обладающая специальными режимами функционирования (например, DES, ГОСТ 28147-89 и т.п.).
Процедура подписи документов при помощи симметричной криптосистемы может выглядеть следующим образом:

1. Алекс и Юстас обладают одинаковым секретным ключом K.
2. Алекс зашифровывает цифровое сообщение, используя ключ K, и посылает зашифрованное сообщение Юстасу. При этом, как уже отмечалось, используется криптосистема, обладающая специальными механизмами функционирования, например ГОСТ 28147-89 в режиме выработки имитовставки.
3. Юстас расшифровывает сообщение при помощи ключа K.
Так как только Алекс и Юстас обладают секретным ключом, то тем самым обеспечивается гарантия, что сообщение подписано именно Алексом, а не стариком Мюллером. Однако, данная схема применима только в тех сетях, в которых можно дать стопроцентную гарантирую надежности каждого из абонентов, т.к. в обратном случае существует потенциальная возможность мошенничества со стороны одного из абонентов, владеющих секретным ключом.
Для устранения указанного недостатка была предложена схема с доверенным арбитром. В данной схеме помимо Алекса и Юстаса существует арбитр - радистка Кэт. Она может обмениваться сообщениями и с Алексом, и с Юстасом, и владеет секретными ключами обоих - KА и KЮ. Процедура подписания документов в данной схеме выглядит следующим образом:

1. Алекс зашифровывает сообщение, используя ключ KА, и посылает его Кэт.
2. Кэт расшифровывает сообщение, также используя ключ KА.
3. Расшифрованное сообщение Кэт зашифровывает на ключе Юстаса KЮ.
4. Данное сообщение Кэт посылает Юстасу.
5. Юстас расшифровывает сообщение, полученное от Кэт, используя ключ KЮ.
Насколько эффективна данная схема? Рассмотрим ее с учетом вышеуказанных требований, предъявляемых к цифровой подписи.
Во-первых, Кэт и Юстас знают, что сообщение пришло именно от Алекса. Уверенность Кэт основана на том, что секретный ключ KА имеют только Алекс и Кэт. Подтверждение Кэт служит доказательством Юстасу. Во-вторых, только Алекс знает ключ KА (и Кэт, как доверенный арбитр). Кэт может получить зашифрованное сообщение на ключе KА только от Алекса. Если Мюллер пытается послать сообщение от имени Алекса, то Кэт сразу обнаружит это на 2-м шаге. В-третьих, если Юстас пытается использовать цифровую подпись, полученную от Кэт, и присоединить ее к другому сообщению, выдавая его за сообщение от Алекса, это выявляется. Арбитр может потребовать от Юстаса данное сообщение и затем сравнивает его с сообщением, зашифрованном на ключе KА. Сразу выявляется факт несоответствия между двумя сообщениями. Если бы Юстас попытался модифицировать присланное сообщение, то Кэт аналогичным способом выявила бы подделку. В-четвертых, даже если Алекс отрицает факт посылки подписанного сообщения, подтверждение от Кэт говорит об обратном.
В случае возникновения спорных ситуаций, например, связанных с отказом отправителя от факта подписания документа, используются услуги третьей, независимой стороны, так называемого арбитра, который расследует каждую такую ситуацию и принимает решение в пользу одной из сторон, участвующих в обмене данными.
Можно заметить, что самым критичным звеном этой схемы является именно арбитр. Во-первых, он должен быть действительно независимой ни от кого стороной. А во-вторых, арбитр должен быть абсолютно безошибочным. Ошибка в рассмотрении даже одной из нескольких тысяч спорных ситуаций подорвет доверие не только к арбитру, но и ко всем предыдущим подписанным документам, достоверность которых удостоверялась арбитром.
Именно поэтому, несмотря на теоретическую возможность применения симметричных криптосистем, на практике для выработки подписи они не используются, поскольку требуют дорогостоящих и громоздких мероприятий по поддержанию достаточного уровня достоверности передаваемых данных.

Подводные камни безопасности в криптографии.

Перевод –
Журнальные статьи любят описывать криптографические продукты в терминах алгоритмов и длины ключей. Алгоритмы благозвучны: их описание может быть немногословным и их легко сравнивать друг с другом. "128-битные ключи означают высокую степень защиты". "Тройной DES означает высокую степень защиты". "40-битные ключи означают низкий уровень защиты". "2048-битный RSA лучше 1024-битного RSA".
Но в действительности всё не так просто. Более длинные ключи не всегда означают лучшую защиту. Сравним криптографический алгоритм с замком на Вашей входной двери. Большинство дверных замков имеют четыре металлических штифта, каждый из которых может находиться в одном из десяти положений. Ключ устанавливает штифты в особой комбинации. Если ключ установит их все правильно, замок откроется. Таким образом, может быть только 10000 различных ключей и взломщик, готовый испробовать все 10000, обязательно попадёт к Вам в дом. Но улучшенный замок с десятью штифтами, дающий 10 миллиардов возможных ключей, возможно, не сделает Ваше жилище безопаснее. Взломщики не испытывают каждый возможный ключ (атака "в лоб"); большинство даже не настолько хитры, чтобы взломать замок (криптографическая атака на алгоритм). Они разбивают окна, выбивают двери, переодеваются полицейскими или отнимают ключи под дулом пистолета. Одна шайка похитителей предметов искусства обходила домашние системы безопасности, пропиливая стены дома цепной пилой. Лучшие замки не спасут от таких атак.
Сильная криптография значит очень много, когда всё сделано верно, но панацеей она не является. Сосредоточение на криптографических алгоритмах, сопряжённое с игнорированием остальных аспектов безопасности похоже на защиту дома не постройкой забора вокруг него, а установкой огромного столба в надежде, что противник налетит прямо на него. Сообразительный нападающий просто обойдёт алгоритмы.
Counterpane (имеется ввиду Counterpane Internet Security, Inc.) потратила много лет на разработку, анализ и взлом криптографических систем. Пока мы занимаемся исследованием опубликованных алгоритмов и протоколов, большая часть нашей работы состоит в проверке реальных продуктов. Мы разрабатывали и анализировали системы, которые защищают секреты, обеспечивают конфиденциальность и правомочность, способствуют коммерции. Мы работали с программным обеспечением, автономным аппаратным обеспечением и всем, что стоит между ними. Мы взламывали некоторые алгоритмы, но почти всегда находились способы атаки, позволяющие полностью обойти сами алгоритмы. Мы не пытаемся пробовать каждый возможный ключ или даже искать недостатки в алгоритмах. Мы используем ошибки в проектировании, реализации и установке. Иногда мы изобретаем новый способ взлома системы, но, по большей части, мы используем те же старые ошибки, которые разработчики повторяют снова и снова.

Построение надёжных криптографических систем.

Разработчики систем безопасности занимают то, что прусский генерал Карл фон Клаушвиц (Carl von Clausewitz) назвал "позицией в осаде". Хорошая система безопасности должна защищать от любых возможных атак, пусть даже неизвестных на данный момент. Злоумышленники, с другой стороны, должны найти лишь одну ошибку для того, чтобы система была взломана. И они могут мошенничать, сговариваться, дожидаться, пока развитие технологии предоставит им новые инструменты. Они могут атаковать систему способом, о котором разработчик и не подозревал.
Построение надёжной криптографической системы - из разряда того, что сделать плохо легко, а хорошо – очень трудно. К сожалению, большинство людей не видят разницы. В других областях теории вычислительных систем функциональность служит для того, чтобы отличать хорошее от плохого: хороший алгоритм сжатия работает лучше плохого, плохой архиватор выглядит хуже при сравнительном анализе его возможностей. В криптографии – иначе. Только тот факт, что шифрующая программа работает, не означает, что она надёжна. Так случается с большинством продуктов: кто-то читает "Прикладную криптографию", выбирает алгоритм и протокол, удостоверяется в работоспособности и считает, что дело сделано. Но всё не так просто – функциональность не равноценна качеству и непродолжительное тестирование всегда выявляет дефекты системы безопасности. Слишком много продуктов идут на поводу у моды – они используют надёжную криптографию, сами надёжными не являясь.
Оригинал статьи (In English) .

Правовые аспекты

Данный вопрос достаточно сложен для того, чтобы подробно рассмотреть его со всех сторон. Постараюсь вкратце коснуться основных моментов. Одно из первых упоминаний о электронной цифровой подписи в отечественных законах приведено в Гражданском Кодексе (ст.160, п.2), согласно которому при совершении сделок допускается применение ЭЦП лишь в случаях и в порядке, предусмотренных законом, иными правовыми актами или соглашениями сторон.
В 1995 году был принят Федеральный Закон "Об информации, информатизации и защите информации". В пункте 3 статьи 5 говорится, что юридическая сила документа может подтверждаться электронной цифровой подписью. При этом "юридическая сила электронной цифровой подписи признается при наличии в автоматизированной информационной системе программно-технических средств, обеспечивающих идентификацию подписи установленного режима их использования". Однако "право удостоверять идентичность электронной цифровой подписи осуществляется на основании лицензии" (п.4).
Можно заметить, что и Гражданский Кодекс и Закон "Об информации, информатизации и защите информации" лишь подтверждают возможность применения ЭЦП, но никаким образом не регламентируют случаи и порядок ее использования. Эти задачи возлагаются на дополнительные правовые акты. Однако, никаких подзаконных актов, кроме наделавшего много шума Указа Президента № 334 от 3 апреля 1995 года, до сих пор не разработано. В Государственной Думе давно ждут рассмотрения Законы "Об электронном документе" и "Об электронной цифровой подписи". Но рассмотреть их планируется не ранее конца текущего года. А если учесть предстоящие выборы, то можно с уверенностью сказать, что о данных законопроектах заговорят не ранее 2000 года. Поэтому необходимо заметить, что для обеспечения юридической значимости цифровой подписи необходимо, чтобы в договоре об обмене электронными документами между сторонами была обязательно расписана процедура "порядка согласования разногласий". Без этой процедуры суд вправе не принимать в качестве доказательства документы, подписанные электронной цифровой подписью (Письмо Высшего Арбитражного Суда РФ от 19 августа 1994 г. № С1-7/ОП-587).
В Указе Президента от 3 апреля, в п.2 говорится о том, что использовать в информационно-телекоммуникационных системах средства ЭЦП, не имеющих сертификата Федерального агентства правительственной связи и информации (ФАПСИ), запрещено. Однако самое большое противоречие вызывает пункт 4, в котором запрещается деятельность нелицензированных ФАПСИ юридических и физических лиц, связанных с разработкой, реализацией, производством и эксплуатацией шифровальных средств (в т.ч. и систем цифровой подписи). Т.е. согласно данному пункту запрещено использовать системы цифровой подписи даже в домашних условиях. Однако статья 6 Закона "Об информации, информатизации и защите информации" говорит о том, что собственник информационного ресурса имеет право сам устанавливать правила защиты своей информации.
Известны и другие противоречия в законодательстве, связанном с цифровой подписью. Разрешить некоторые из них трудно без участия квалифицированных юристов. Хочется надеяться, что в ближайшие годы будут устранены имеющиеся правовые противоречия и разработаны новые законодательные акты, в полной мере удовлетворяющие требованиям пользователей и веяниям современных информационных технологий.
Хочется отметить работы, ведущиеся в этой области в Ассоциации Документальной Электросвязи. Во-первых, в Комитете по защите информации ведутся работы по реализации защищенной электронной почты X.400, невозможной без ЭЦП. Работы в области правового обеспечения ЭЦП ведутся также в Комитетах по электронному ведению бизнеса и Комитете по стандартизации.

Предупреждение атак или обнаружение атак.

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

Распределение ключей

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

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

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

Подтверждение подлинности абонентов в последнем случае может осуществляться следующим образом:

Непосредственно между абонентами. Данный метод применяется в том случае, если абонентов всего двое. Для обмена ключами в данном случае может быть использован алгоритм распределения ключей, например, разработанный в 1976 году криптографами Диффи и Хеллманом. Существуют и другие варианты обмена ключами. Например, при помощи симметричных криптосистем или фельдъегерской службы. Однако, в распределенных сетях, насчитывающих не один десяток абонентов, такие варианты не применимы из-за возникающих сложностей.

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

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

Распространение ключей

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

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

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

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

X.509 предполагает, что пользователь уже имеет доступ к открытому ключу CA. Как это осуществляется, в нем не определяется.

Компрометация центра сертификации ключей весьма реальная угроза. Компрометация CA означает. Что все пользователи этой системы будут скомпрометированы. И никто не будет знать об этом. X.509 предполагает, что все ключи, включая ключи самого CA, хранятся в безопасном месте. Внедрение системы справочников X.509 (где хранятся ключи) довольно сложно, и уязвимо к ошибкам в конфигурации. В настоящее время слишком мало людей обладают техническими знаниями, необходимыми для правильного администрирования таких систем. Более того, понятно, что на людей, занимающих такие важные должности, может быть оказано давление.

CA могут оказаться узким местом. Для обеспечения устойчивости к сбоям X.509 предлагает, чтобы база данных CA была реплицирована с помощью стандартных средств X.500; это значительно увеличит стоимость криптосистемы. А при маскараде под CA будет трудно определить, какая система была атакована. Более того, все данные из базы данных CA должны посылаться по каналам связи каким-то образом.

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

Сеансовые ключи, несмотря на то, что шифруются, все-таки передаются по незащищенным каналам связи.

Несмотря на все эти серьезные недостатки пользователь должен неявно доверять асимметричной криптосистеме.

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

Процедура	Комментарии
Физическая раздача ключей	Курьеры и ручная выдача - вот два распространенных примера этой процедуры. Конечно, из них двоих лучше ручная выдача. Серьезные организации имеют инструкции, описывающие порядок выдачи ключей. Раздача ключей может аудироваться и протоколироваться, но это все-таки не защитит ее до конца от компрометации отдельными людьми. Используется как симметричными, так и асимметричными криптосистемами. Несмотря на заявления о том, что в асимметричных криптосистемах не возникает проблем, связанных с физической доставкой ключей, на самом деле они есть. X.509 предполагает, что создатель ключей будет передавать асимметричный секретный ключ пользователю (и/или асимметричный открытый ключ CA) физически безопасным способом, и что предприняты соответствующие меры физической безопасности, чтобы защитить создателя и проводимые им операции с данными от атак.
Выдача общего ключа участникам взаимодействия центром выдачи ключей	Может использоваться как симметричными, так и асимметричными криптосистемами. Так как при данном способе каждый пользователь должен каким-то образом безопасно взаимодействовать с центром выдачи ключей в самом начале работы, то это просто еще один случай, когда начальный обмен ключами является проблемой. Если центр скомпрометирован, то обеспечение безопасности последующих запросов на выдачу ключей проблематично, а безопасность ранее выданных ключей зависит от криптосистемы.
Предоставление центром сертификации ключей доступа к открытым ключам пользователей и выдача секретных ключей пользователям	Используется асимметричными криптосистемами. Пользователи должны доверять всей этой системе. Всего лишь одна успешная атака компрометирует всю систему. Иерархическая система аттестации ключей приводит к появлению большего числа потенциальных уязвимых мест - CA должен публиковать свой асимметричный открытый ключ и предоставлять его сертификат, выданный CA более высокого уровня. Асимметричные секретные ключи CA должны храниться в безопасном месте, так как их компрометация может привести к успешным атакам, которые нельзя будет обнаружить.
Сеть доверия	Используется в асимметричных криптосистемах. Пользователи сами распространяют свои ключи и следят за ключами других пользователей; доверие заключатся в неформальном способе обмена ключами.
Метод Диффи-Хеллмана	Обмен секретным ключом по незащищенным каналам связи между двумя пользователями, которые до этого не имели общего секретного ключа. Не может использоваться для шифрования или расшифровки сообщений. Основывается на сложности взятия логарифма в конечных полях. При правильном выборе достаточно больших элементов полей решить проблему расчета дискретного логарифма невозможно. Уязвим к атаке "активное вмешательство в соединение". Запатентован PKP (Public Key Partners)

Реализации

Описание Fortezza является интересным само по себе, однако как пользователей,так и исследователей этой технологии не могут не заинтересовать прикладныеаспекты конкретных разработок. В таблице 2 содержатся основные параметры3-х известных автору реализаций технологии Fortezza на основе информации,полученной по сети Internet.

Название, характеристики

Фирма-производитель Mykotronx, Inc.357 Van Ness Way Suite 200 Torrance,CA, USA 90501 Rainbow TechnologiesCorporate Headquarters50 Technology DriveIrvineCA 92618 iPower Business UnitNational Semiconductor 1090 Kifer Road, Mail Stop16-225, Sunnyvale, CA 94086-3737 Интерфейс PC ISA bus PCMCIA 2.1 Type 1 PC Card Type II Поддерживаемые платформы (наличие средств разработки приложений) DOS
Windows 3.1
Windows 95
Windows NT
SCO ODT DOS
Windows 3.1
Windows 95
Windows NT
Apple Macintosh
SCO ODT
UNIX-HP/UX
IBM AIX
SUN OS и Solaris DOS
Windows 3.1
Windows 95*
Windows NT*
Apple Macintosh7.x*
OSF*
UNIX*
IBM AIX*
HPBLS* Производительность:
шифрование
цифровая подпись
верификация подписи
хэширование
> 1.4 Мбайт/с
23 мс
39 мс
н/д
> 1.1 Мбайт/с
67 мс
н/д
н/д
2 Мбайт/с
<50 мс
<100 мс
2 Мбайт/с Электропитание:
напряжение
мощность
+5В
н/д
+5В 605 мВт
(62.5 мВт**)
+5В
< 1Вт Источник информации Таблица 2. Характеристики производимых криптокарт Fortezza
Примечания: * - в будущем, ** - в режиме standby, н/д - нет данных.

MykotronxFortezza ISA Bus Rainbow Fortezza Crypto Card
National Fortezza Crypto

Рекомендации и выбор вида шифра для применения в сети доступа

,

Вісник українського будинку економічних та науково-технічних знань. #3, 2005
Основное требование, предъявляемое к выбору алгоритмов криптографической защиты информации при канальном шифровании заключается в возможности закрытия нефиксированных объемов передаваемой информации с минимальными временными задержками.
Так как для передачи данных и речевых сообщений могут используются каналы недостаточно высокого качества, то любая криптографическая система, увеличивающая и без того нередкие ошибки, неприменима - неразмножение криптографическим алгоритмом ошибок, вносимых каналом связи.
При использовании сквозного шифрования требования к неразмножению криптоалгоритмом ошибок, вносимых каналом связи не столь важно. При сквозном шифровании на нижестоящих уровнях выполняется помехоустойчивое кодирование. Но криптоалгоритмы сквозного шифрования должны кроме закрытия передаваемой информации давать возможность надежной аутентификации.
Требования, предъявляемые к выбору алгоритмов криптографической защиты информации при сквозном шифровании:
Интерактивные данные закрывать с минимальной временной задержкой.
К закрытию неинтерактивных данных особых требований не предъявляется.
При комбинированном шифровании работа с ключами ведется так: КСЗИ и АК АТС отвечают за ключи, используемые при канальном шифровании, а о ключах, применяемых при сквозном шифровании, заботятся сами пользователи. Применяются потоковые (можно потоковый (наложение гаммы) режим работы блочного шифра), сверточные шифры
Основным недостатком потоковых шифров является необходимость передачи информации для начальной инициализации (синхропосылка) перед заголовком сообщения, которая должна быть принята до расшифровывания любого сообщения. Это связано с тем, что синхропосылка может также являться и секретным ключом (частью секретного ключа). Передача синхропосыки в виде, в котором она будет применяться в алгоритме шифрования по каналу передачи данных может создать угрозу криптографической стойкости системы, и поэтому всегда необходимо применять дополнительный ключ, с помощью которого сихропосылка будет закрываться, либо использовать в алгоритме шифрования ключезависимую модификацию синхропосылки, как это реализовано в ГОСТ 28147-89.
В ГОСТ 28147-89 синхропосылка (начальное заполнение) передается в открытом виде, но в алгоритме шифрования используется результат преобразования начального заполнения по циклу 32-З: Ω0 = Ц32-3(S), где Ω0 - вектор начального заполнения рекуррентного генератора последовательности чисел (РГПЧ), Ц32-3 - базовый цикл зашифрования, S - синхропосылка.
На основании приведенных рассуждений получим следующие результаты:
Канальное шифрование - потоковые шифры (потоковый режим работы блочного шифра может не подойти).

Сквозное шифрование:

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

Для закрытия неитерактивных данных могут подойти как сверточные шифры (для упрощения конструкции КСЗИ) так и блочные шифры.

Криптосистемы с открытым ключом могут использоваться для механизмов аутентификации КСЗИ и ключевого обмена между КСЗИ.

Security Pitfalls in Cryptography

by Bruce Schneier

Cryptography Consultant

e-mail:

Copyright Counterpane Internet Security, Inc., 2001

Сертификаты

Как следует из сказанного выше, в технологии Fortezza должен существоватьпротокол, регламентирующий выдачу и распространение открытых ключей пользователей.Открытые ключи ассоциируются с их владельцами с помощью так называемых"сертификатов". Сертификат представляет собой структуру данных,связывающую идентификатор пользователя, открытые ключи, предназначенныедля алгоритмов KEA и DSA, а также информацию о лице, выдавшем сертификат.С целю защиты от подделки сертификат защищается цифровой подписью выдавшегосертификат лица. Сертификаты и пары секретных/открытых ключей образуютоснову системы управления ключами технологии Fortezza.
В качестве основы системы аутентификации Fortezza использует схему аутентификациисертификатов X.509 и соглашения о наименовании объектов X.500. ТехнологияFortezza различает две структуры сертификатов. Под "сертификатом Fortezza"понимается внутренняя структура данных технологии Fortezza, под "сертификатомX.509" - блок данных стандарта X.509, содержащийся в сертификате Fortezza(см. Рис.5.).
2820 байт

метка

флажки

размер

DSA

KEA

DSA

DSA

DSA

DSA

DSA

KEA

KEA

KEA

KEA

KEA

сертификат

данных

Private (X)

Private (X)

размер PG

размер Q

P

Q

G

размер PG

размер Q

P

Q

G

X.509

32

16

4

48

48

4

4

128

48

128

4

4

128

48

128

2048 байт

Рис. 5.
Каждый сертификат Fortezza состоит из двух пар открытых/секретных ключей(одна из них предназначена для использования в KEA, другая - в DSA) и соответствующихим значений параметров P, Q и G. Сертификат X.509 содержит открытые составляющиеэтих ключей. Открытые ключи всегда доступны пользователю карты. Ключи хранятсяв закодированном виде: секретные - с помощью локальных ключей пользователяKs (ключ Ks имеет размер 80 бит, находится в специальном регистре криптокартыи становится доступным после успешного ввода PIN пользователя), открытые- с помощью ASN.1. Поле данных размером 2048 байт, зарезервированное длясертификата X.509, может использоваться для хранения любой информации (биометрическихданных, фотоизображений), если только такие "сертификаты" неиспользуются в криптографических функциях. Приложения могут загружать этиданные в энергонезависимую память карты и сохранять их там продолжительноевремя.
Сертификаты X.509 могут быть размещены в базу данных специализированного"сертификационного сервера" (нескольких серверов) или распределеныпо сети и сохранены локально в картах всех участников информационного обмена.Единственным условием является доступность сертификата для криптографическихфункций приложений Fortezza. Некоторые приложения позволяют включать сертификатотправителя в заголовок сообщения, предоставляя получателю возможностьдинамически создавать локальную базу сертификатов абонентов. Такая локальнаябаза может служить своего рода "кэшем" сертификатов, что делаетвозможным посылку сообщений без обращения к серверу сертификатов. Однако,долгое использование локальной базы может привести к устареванию содержащихсяв ней сертификатов.
Таблица 1 содержит описание всех криптографических функций.
Криптографическая функцияНазваниеРазмер параметровСтандартОбмен открытыми ключамиKEAсекретный ключ 160 битмодифицированный Diffie-Helman Шифрование сообщенийSKIPJACKключ 80 битNSA / FIPS 185Цифровая подписьDSAмодуль 1024 бит NIST FIPS 186ХэшированиеSHA-1160 битNIST FIPS 180-1Временные меткинет160 битFortezzaПароль пользователяPIN4-12 байтFortezzaСертификатнет2820 байтиспользуется CCITT X.509
Таблица 1. Криптографические функции Fortezza.

Симметричные алгоритмы

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

Тип	Описание
DES (Data Encryption Standard)	Популярный алгоритм шифрования, используемый как стандарт шифрования данных правительством США. Шифруется блок из 64 бит, используется 64-битовый ключ (требуется только 56 бит), 16 проходов Может работать в 4 режимах: Электронная кодовая книга (ECB-Electronic Code Book ) - обычный DES, использует два различных алгоритма. Цепочечный режим (CBC-Cipher Block Chaining), в котором шифрование шифрование блока данных зависит от результатов шифрования предыдущих блоков данных. Обратная связь по выходу (OFB-Output Feedback), используется как генератор случайных чисел. Обратная связь по шифратору (CFB-Cipher Feedback), используется для получения кодов аутентификации сообщений.
3-DES или тройной DES	64-битный блочный шифратор, использует DES 3 раза с тремя различными 56-битными ключами. Достаточно стоек ко всем атакам
Каскадный 3-DES	Стандартный тройной DES, к которому добавлен механизм обратной связи, такой как CBC, OFB или CFB Очень стоек ко всем атакам.
FEAL (быстрый алгоритм шифрования)	Блочный шифратор, используемый как альтернатива DES Вскрыт, хотя после этого были предложены новые версии.
IDEA (международный алгоритм шифрования)	64-битный блочный шифратор, 128-битовый ключ, 8 проходов Предложен недавно; хотя до сих пор не прошел полной проверки, чтобы считаться надежным, считается более лучшим, чем DES
Skipjack	Разработано АНБ в ходе проектов правительства США "Clipper" и "Capstone". До недавнего времени был секретным, но его стойкость не зависела только от того, что он был секретным. 64-битный блочный шифратор, 80-битовые ключи используются в режимах ECB, CFB, OFB или CBC, 32 прохода
RC2	64-битный блочный шифратор, ключ переменного размера Приблизительно в 2 раза быстрее, чем DES Может использоваться в тех же режимах, что и DES, включая тройное шифрование. Конфиденциальный алгоритм, владельцем которого является RSA Data Security
RC4	Потоковый шифр, байт-ориентированный, с ключом переменного размера. Приблизительно в 10 раз быстрее DES. Конфиденциальный алгоритм, которым владеет RSA Data Security
RC5	Имеет размер блока 32, 64 или 128 бит, ключ с длиной от 0 до 2048 бит, от 0 до 255 проходов Быстрый блочный шифр Алгоритм, которым владеет RSA Data Security
CAST	64-битный блочный шифратор, ключи длиной от 40 до 64 бит, 8 проходов Неизвестно способов вскрыть его иначе как путем прямого перебора.
Blowfish.	64-битный блочный шифратор, ключ переменного размера до 448 бит, 16 проходов, на каждом проходе выполняются перестановки, зависящие от ключа, и подстановки, зависящие от ключа и данных. Быстрее, чем DES Разработан для 32-битных машин
Устройство с одноразовыми ключами	Шифратор, который нельзя вскрыть. Ключом (который имеет ту же длину, что и шифруемые данные) являются следующие 'n' бит из массива случайно созданных бит, хранящихся в этом устройстве. У отправителя и получателя имеются одинаковые устройства. После использования биты разрушаются, и в следующий раз используются другие биты.
Поточные шифры	Быстрые алгоритмы симметричного шифрования, обычно оперирующие битами (а не блоками бит). Разработаны как аналог устройства с одноразовыми ключами, и хотя не являются такими же безопасными, как оно, по крайней мере практичны.

Список литературы

1. Bruce Schneier. Applied Cryptography, Second edition. John Wiley & Sons, 1996
2. Брюс Шнайер. Слабые места криптографических систем. "Открытые системы", №1, 1999.
3. Ю. Мельников. Электронная цифровая подпись: всегда ли она подлинная? Банковские технологии, №5, 1995.

Стандарты

В России в 1994 году были приняты стандарты ГОСТ Р 34.10-94 "Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.11-94 " Криптографическая защита информации. Функция хэширования". Чем могут помочь пользователю данные стандарты? Во-первых, они должны гарантировать криптостойкость, т.е. надежность реализованных по ним алгоритмов. Во-вторых, применение стандартов должно обеспечить совместимость продуктов различных производителей. Однако есть и проблемы при использовании принятых стандартов.
Стандарты ГОСТ Р 34.10-94 и ГОСТ Р 34.11-94 описывают лишь процедуры выработки и проверки ЭЦП и хэш-функции. За пределами их рассмотрения остается такой важный вопрос, как распространение и генерация ключей, защита от несанкционированного доступа к ключевой информации и т.д. Поэтому зачастую продукты, реализующие один и тот же стандарт, несовместимы между собой. На российском рынке средств защиты информации существует несколько известных систем, в которых реализованы указанные стандарты (Верба-О, Криптон и т.д.), но между собой эти системы не совместимы.
Как уже отмечалось, использование стандарта должно гарантировать, что документы, подписанные при помощи ГОСТ Р 34.10-94, теоретически не могут быть подделаны за приемлемое для злоумышленника время. Однако на практике дело не всегда обстоит таким образом. Связано это с тем, что стандарт описывает алгоритм математическим языком, в то время как пользователи сталкиваются уже с его реализацией. А при реализации могут быть допущены различные ошибки, которые сводят на нет все достоинства алгоритма. Кроме того, эффективное применение систем ЭЦП зависит от их правильной эксплуатации. Например, хранение секретных ключей для генерации цифровой подписи на доступном всем жестком диске позволяет злоумышленнику получить к ним доступ и в дальнейшем подделывать документы, подписанные на этих ключах.
Поэтому далеко не всегда указанные системы обеспечивают необходимый уровень защищенности.

Требования пользователей

Если обратиться к документации на различные системы, реализующие ЭЦП, то можно заметить, что производители, особенно в России, уделяют максимум внимания математическим аспектам реализованных алгоритмов. Десятки страниц посвящены тому, какова криптостойкость алгоритма и сколько лет потребуется злоумышленнику на подделку подписанного документа. Но как ни парадоксально это прозвучит, на практике пользователей очень мало волнуют эти вопросы. Если система реализует некоторый стандарт, то для конечного пользователя этого факта достаточно. Тем более что проверить правильность приводимых в документации выкладок сможет только квалифицированный математик-криптограф, которых в России очень мало. В первую очередь пользователи интересуются потребительскими свойствами предлагаемых систем, возможностям их встраивания в уже существующую технологию обработки информации и т.п. Рассмотрим более подробно эти и другие вопросы, задаваемые пользователями при приобретении систем, реализующих электронную цифровую подпись.
Скорость - это один из основных параметров, на которые следует обращать внимание при выборе системы цифровой подписи. Особенно в системах связи, в которых осуществляется очень интенсивный обмен данными и передаваемая информация должна защищаться от подделки. Данный параметр слагается из двух составляющих: скорости генерации подписи и скорости ее проверки, и существенно зависит от скорости выработки хэш-функции, а также типа ЭВМ, на которой осуществляется генерация или проверка ЭЦП.
Немаловажным параметром является длина подписи. Например, в системах диспетчерского управления, в которых постоянно передается большое число переменных малой длины, использование российского стандарта для подписи всех данных неэффективно.
Поскольку при приобретении системы цифровой подписи, как правило, у заказчика уже сложилась информационная инфраструктура, то очень часто на первое место выходит вопрос об интеграции приобретаемой системы в принятую технологию обработки информации. Например, если в качестве средства отправки электронной почты используется Microsoft Outlook, то необходимо, чтобы система ЭЦП могла быть встроена в эту почтовую программу. Такую возможность предлагают многие зарубежные и некоторые российские системы ЭЦП, например, PGP (Pretty Good Privacy), которая также может быть встроена в почтовую программу Eudora, наравне с Microsoft Outlook, широко распространенную в России. Если система ЭЦП не поддерживает используемое у заказчика программное обеспечение (например, потому что оно разработано самим заказчиком), то поставщик должен поставлять интерфейс (API) для встраивания возможностей работы с цифровой подписью в систему заказчика. Такую возможность предлагают многие российские производители (например, МО ПНИЭИ, ЛАН КРИПТО, НИП "Информзащита"). Причем желательно, чтобы данный интерфейс существовал для различных операционных систем и платформ (Windows NT, Windows 9x, MS DOS, HP UX, AIX и т.д.).
Необходимо обратить внимание на предлагаемые механизмы или меры защиты от несанкционированного доступа к системе электронной цифровой подписи. Должны быть предусмотрены действия, выполняемые в случае компрометации ключей одного из пользователей (например, занесение их в "черные списки" и рассылка всем пользователям системы). Кроме того, должна контролироваться целостность как системы ЭЦП в целом, так и ее компонентов (например, журналов регистрации действий). В документации на некоторые российские системы ЭЦП есть рекомендации по применению систем защиты информации от несанкционированного доступа. Данные системы, в частности, позволяют ограничить круг лиц, имеющих право запуска системы цифровой подписи. Одной из таких систем является сертифицированная в Гостехкомиссии России система Secret Net, разработанная Научно-инженерным предприятием "Информзащита".
Немаловажным аспектом является юридическая поддержка предлагаемого решения. Если предложение системы ЭЦП исходит от компании-разработчика программного обеспечения, то она должна предоставить проект договора об обмене электронными документами с использованием ЭЦП. Если же компания предлагает обслуживание с применением систем ЭЦП, то следует внимательно ознакомиться с текстом заключаемого договора. В таком договоре или его проекте должно быть предусмотрено решение следующих вопросов:

Наличие процедуры урегулирования конфликтных ситуаций;

Описание состава комиссии, расследующей возникающие конфликты;

Ответственность сторон (в т.ч. и фирмы-разработчика).

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

Окончательный выбор системы ЭЦП может быть определен наличием или отсутствием следующих дополнительных возможностей:

Постановка нескольких подписей под одним документом и их выборочная проверка;

Хранение цифровой подписи не только в подписываемом документе, но и в отдельном файле;

Использование командной строки для работы с системой ЭЦП;

Подпись и проверка группы файлов;

Постановка и проверка подписи под заданными фрагментами (полями) документа;

Выработка и проверка групповой подписи;

Совместное использование функций шифрования и цифровой подписи;

Постановка подписи и ее проверка для участка оперативной памяти;

Архивация использованных ключей;

И т.д.

Выбор параметров криптографических алгоритмов и ключей

Потоковые шифры основываются на псевдослучайных (случайных) ключевых последовательностях - сгенерированных определенным образом последовательностях символов с заданными свойствами непредсказуемости (случайности) появления очередного символа. Генераторы ключевых последовательностей обычно базируются на комбинациях регистров сдвига и нелинейных булевых функциях.
Генераторы ключевых последовательностей характеризуются:

периодом повторения последовательности;

статистическими свойствами порождаемых последовательностей;

криптографической стойкостью генератора ключевой последовательности.

Если используется потоковое шифрование, тогда минимальный период должен удовлетворять условию: TΩ>>Tmax * V * n,(1)

где TΩ - минимальный период повторения последовательности,

Tmax - максимальное время непрерывной работы КСЗИ,

V - скорость передачи в канале связи,

t - разрядность последовательности на выходе генератора ключевой последовательности.
Безопасность любого алгоритма сосредоточена в ключе. Если используется криптографически слабый процесс для генерации ключей, то криптосистема в целом слаба. Злоумышленнику не нужно криптоанализировать алгоритм шифрования, он может криптоанализировать алгоритм генерации ключей.
Теоретически, любой шифровальный алгоритм с использованием ключа может быть вскрыт методом перебора всех значений ключа. Если ключ подбирается методом грубой силы (brute force), требуемая мощность компьютера растет экспоненциально с увеличением длины ключа. Ключ длиной в 32 бита требует 232 (около 109) шагов.
Тогда минимальную длину ключа в битах Nmin можно вычислить по формуле:
(2)
где T - время жизни передаваемых данных (определяется в соответствии с законодательством по степени секретности передаваемых данных). Хотя информация может устареть сразу после передачи ее по каналу связи. В этом случае время жизни передаваемых данных должно выбираться не менее 48 часов.


V - скорость подбора ключей, зависит от класса алгоритма шифрования и используемых злоумышленником ресурсов и может колебаться от 103 до 106 и выше, при использовании суперЭВМ либо распределенных вычислений.

- оператор округления до ближайшего большего целого.

Следует учесть, что некоторые алгоритмы могут иметь эквивалентные ключи (в иностранной литературе их называют ключи-дополнения) K* такие, что выполняется равенство:

f −1(C, K)=f −1(C, K*)=f*(C, K*)=P, (3)

где f* - функция, при использовании эквивалентного ключа K* , дающая такой же результат, как и функция расшифрования f −1 алгоритма.

При этом может оказаться, что злоумышленнику требуется перебрать только некоторую часть множества ключей.

Пример для режима наложения гаммы:

f(P, K)=P⊕Γ=C , тогда легальный пользователь вычислит f −1(C, K)=C⊕Γ=P .

Злоумышленник может найти такой ключ и вычислить

В данном случае, эквивалентным ключом является инверсия основного ключа, а f* - инверсия функции сложения по модулю 2.

В итоге злоумышленнику необходимо вместо 2m операций перебора выполнить 2m-1 операций, где m - разрядность ключевой комбинации.

С учетом вышесказанного перепишем формулу (2) в виде:

(4)

Ψ - коэффициент, учитывающий наличие эквивалентных ключей. Для алгоритмов шифрования на основе гаммирования Ψ=2÷3 .

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

Следует учесть, что вычислительная мощь вычислительных средств удваивается каждые 18÷24 месяцев (Δt = 1,5÷2 года) - эмпирический закон Мура. Если необходимо, чтобы ключи были устойчивы к вскрытию грубой силой в течение 5 лет, то необходимо соответствующим образом планировать использование ключей.

С учетом вышесказанного перепишем формулу (4) в виде:

(5)


где [T']=[год]

Δt - срок, за который вычислительная мощь вычислительных средств удваивается (параметр удвоения), год.

Следует учесть, что параметр Δt нужно время от времени пересматривать, особенно в периоды смены поколений микросхем и внедрения новых достижений в технологии.

Пока обоснованным выглядит представление динамики роста вычислительной мощи со следующими значениями параметра удвоения: Δt = 2 года в период с 1971 г. по 1993 г., Δt = 4 года в период с 1993 г. по 1999 г. и Δt = 0.6 года от 1999 г.

Но эти числа дают только часть ответа. Дело в том, что машина заведомо раскрывающая ключ за год, имеет 8% шанс раскрыть ключ за месяц. Если при этом ключ меняют 1 раз в месяц, то есть 8% вероятность раскрыть ключ еще во время его использования.

Более того, пусть есть машина, отыскивающая ключ за месяц, а ключ меняется каждый час. Несмотря на то, что вероятность найти данный ключ за час всего 0,14%, вероятность найти правильный ключ до его смена за месяц использования такой схемы = 63%, причем эта цифра не зависит от частоты смена ключа.

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

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

в данной статье аспекты показывают,

Описанные в данной статье аспекты показывают, что выбор системы электронной цифровой подписи - непростая задача, решению которой необходимо уделить серьезное внимание. Не существует готовых рецептов. Правильный выбор - это не просто просмотр рекламных буклетов, полученных на выставке, или ознакомление с Web-сервером поставщика системы ЭЦП. Это кропотливый процесс, в котором должно учитываться множество факторов. Это и необходимость интеграции в принятую технологию обработки информации, и необходимость наличия сертификата ФАПСИ, и алгоритм распределения ключей, и т.д.
Сделайте правильный выбор - и Ваша информация будет надежно защищена от подделки.

Защита информации в сети доступа

,

Вісник українського будинку економічних та науково-технічних знань. #3, 2005
Среди всего многообразия способов несанкционированного перехвата информации особое место занимает анализ трафика в сети доступа, поскольку сеть доступа - самый первый и самый удобный источник связи между абонентами в реальном масштабе времени, и при этом самый незащищенный.
Сеть доступа имеет еще один недостаток с точки зрения безопасности - возможность перехвата речевой информации из помещений, по которым проходит телефонная линия, и где подключен телефонный аппарат (далее оконечное оборудование (ОО)), даже тогда, когда не ведутся телефонные переговоры. Для такого перехвата существует специальное оборудование, которое подключается к телефонной линии внутри контролируемого помещения или даже за его пределами. Требования к оборудованию противодействия данных угрозам описывают НД ТЗІ 2.3-002-2001, НД ТЗІ 2.3-003-2001, НД ТЗІ 4.7-001-2001 и некоторые другие нормативные документы.
В общем случае от ОО к АТС и обратно передаются:

сигналы управления и сигнализации стандартного оборудования (ТА, модем и т.д.);

сигналы передачи данных, речь;

сигналы сигнализации и управления нестандартного оборудования (охранная, пожарная сигнализация и др.).

Инсталляция центра сертификации

Для создания центра будем использовать адаптированный набор скриптов, написанных Ralf S. Engelschall.
Загрузите архив по ссылке http://slil.ru/25110674.
#tar -xjf CA_clean.tar.bz2 #cd CA_clean #export CAHOME=`pwd` #echo ${CAHOME}
Отредактируйте файл ca.conf под свои нужды:
[req] distinguished_name =req_distinguished_name x509_extensions = v3_ca prompt = no [req_distinguished_name] C= UA ST = UA L = Kiev O = GPAHARENKO-UA OU = ROOTCA CN = ca.gpaharenko.com.ua emailAddress = gpaharenko@gpaharenko.ua [v3_ca] basicConstraints = CA:true nsComment = "CA certificate of GPAHARENKO" nsCertType = sslCA, emailCA subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always
В скрипте createca.sh срок жизни сертификата равен 10 лет, вы можете изменить его в соответствии с вашей политикой. В этом же файле устанавливается длина ключа сертификата.
Генерируем корневой сертификат:
#./createca.sh Generating RSA private key, 4096 bit long modulus ...++ .................................................................................++ e is 65537 (0x10001) Enter pass phrase for ca.key: Verifying - Enter pass phrase for ca.key: Enter pass phrase for ca.key: #
Один и тот же пароль необходимо ввести 3 раза. Создаются файлы ca.key - закрытый ключ сертификата, ca.crt - корневой сертификат, ca.pfx - для некоторых приложений может понадобиться сертификат в таком формате.
#openssl x509 -text -in ca.crt |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb:24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit):
#openssl rsa -text -in ca.key |head -5 Enter pass phrase for ca.key: writing RSA key Private-Key: (4096 bit) modulus: 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4:

#openssl x509 -text -in ca.pfx -inform der |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb: 24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit):

Уточняем срок действия списка отозваных сертификатов в carevoke.config: #cat carevoke.config |grep default_crl default_crl_days = 365

Создаем пустой пока еще revocation list:

#./createcrl.sh Using configuration from carevoke.config Enter pass phrase for ./ca.key: #ls crl.pem crl.pem #openssl crl -text -in crl.pem |head -10 Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Last Update: Oct 31 14:03:21 2007 GMT Next Update: Oct 30 14:03:21 2008 GMT No Revoked Certificates. Signature Algorithm: sha1WithRSAEncryption #

Далее создавать серверные и клиентские сертификаты можно по следующей схеме. Создается пустая папка. В ней файл openssl.conf с шаблоном сертификата:

#cat SERVERS/sales/openssl.conf [ req ] default_bits = 1024 distinguished_name = req_distinguished_name prompt = no req_extensions = v3_req

[ req_distinguished_name ] C = UA ST = UA L = Kiev O = GPAHARENKO-UA OU = SALES CN = sales.gpaharenko.com.ua emailAddress = gpaharenko@gpaharenko.com.ua

[ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash

Если сертификат клиентский, необходимо также указать пароль для закрытых ключей сертфиката в файле pass. По умолчанию в pkcs12 они шифруются DES3. Создадим серверный сертификат:

#./createserver.sh SERVERS/sales/ Generating RSA private key, 1024 bit long modulus .....++++++ ...++++++ e is 65537 (0x10001) writing RSA key CA signing: SERVERS/sales//server.csr -> SERVERS/sales//server.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'sales.gpaharenko.ua' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 29 14:27:03 2012 GMT (1825 days)


Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales//server.crt CA cert SERVERS/sales//server.crt: OK

Серверный сертификат server.crt:

#openssl x509 -text -in SERVERS/sales/server.crt |head -15 Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 14:27:03 2007 GMT Not After : Oct 29 14:27:03 2012 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=SALES, CN=sales.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b: #

Закрытый ключ серверного сертификта server.key:

#openssl rsa -text -in SERVERS/sales/server.key |head -5 writing RSA key Private-Key: (1024 bit) modulus: 00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b: 18:ed:30:b0:1f:81:a3:5f:fa:40:8f:47:3f:ff:84: 1a:36:ac:c4:02:88:e5:ce:79:f0:e2:26:e8:86:1e:

После этого можно подготовить архив со всеми необходимыми файлами и передать их системному администратору сервера:

#./bundleserver.sh SERVERS/sales/ #tar -tzf SERVERS/sales/deploy.tar.gz SERVERS/sales//server.crt SERVERS/sales//server.key ca.crt crl.pem #

Аналогично создается клиентский сертификат. Главное не забыть указать пароль, которым будет зашифрован сертификат.

#echo "gpaharenko" > SERVERS/sales/gleb/pass #./createclient.sh SERVERS/sales/gleb/ Generating a 512 bit RSA private key ......++++++++++++ ...................................++++++++++++ writing new private key to 'SERVERS/sales/gleb//client.key' ----- CA signing: SERVERS/sales/gleb//client.csr -> SERVERS/sales/gleb//client.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'gpakharenko' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 30 14:34:08 2008 GMT (365 days)


Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales/gleb//client.crt CA cert SERVERS/sales/gleb//client.crt: OK

Кроме файлов .crt и .key создается файл pkcs12, который, в основном, используется клиентскими программами.

#openssl pkcs12 -info -in SERVERS/sales/gleb/client.p12 Enter Import Password: MAC Iteration 2048 MAC verified OK PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag Bag Attributes localKeyID: 47 F2 5A 86 BB 3B BF DB BD 5C DA 87 D4 3F 27 59 67 A5 16 B8 friendlyName: my_client_certificate subject=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=SALES/CN=gpakharenko/emailAddress= gpaharenko@gpaharenko.ua issuer=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAdd ress=gpaharenko@gpaharenko.ua

Упаковуем клиентский сертификат:

#./bundleclient.sh SERVERS/sales/gleb/ #tar -tzf SERVERS/sales/gleb/deploy.tar.gz SERVERS/sales/gleb//client.p12 ca.crt crl.pem #

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

#./createclient.sh SERVERS/sales/blocked/ Generating a 512 bit RSA private key ...++++++++++++ ............++++++++++++ writing new private key to 'SERVERS/sales/blocked//client.key' ----- CA signing: SERVERS/sales/blocked//client.csr -> SERVERS/sales/blocked//client.crt: Using configuration from ca.config Enter pass phrase for ./ca.key: Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'UA' stateOrProvinceName :PRINTABLE:'UA' localityName :PRINTABLE:'Kiev' organizationName :PRINTABLE:'GPAHARENKO-UA' organizationalUnitName:PRINTABLE:'SALES' commonName :PRINTABLE:'blocked' emailAddress :IA5STRING:'gpaharenko@gpaharenko.ua' Certificate is to be certified until Oct 31 09:50:04 2008 GMT (365 days)

Write out database with 1 new entries Data Base Updated CA verifying: SERVERS/sales/blocked//client.crt CA cert SERVERS/sales/blocked//client.crt: OK #./revoke.sh SERVERS/sales/blocked/client.crt Using configuration from carevoke.config Enter pass phrase for ./ca.key: Revoking Certificate 03. Data Base Updated Using configuration from carevoke.config Enter pass phrase for ./ca.key: #

Можем убедиться, что в обновленном файле crl.pem содержится сертификат с номером 3:

#openssl crl -text -in crl.pem | head -8 Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Last Update: Nov 1 09:50:26 2007 GMT Next Update: Oct 31 09:50:26 2008 GMT Revoked Certificates: Serial Number: 03 # #openssl x509 -text -in SERVERS/sales/blocked/client.crt | head -4 Certificate: Data: Version: 1 (0x0) Serial Number: 3 (0x3)

#

Краткая справка об инфраструктуре открытых ключей и OpenSSL

Желающим глубоко изучить теорию открытых ключей рекомендую обратиться к книге Брюса Шнайера "Прикладная криптография". Остальным предлагаю бегло напомнить основные понятия.
Существует два основных класса криптографических алгоритмов - симметричные и ассиметричные. В симметричных для шифрования и дешифрования сообщения используется один и тот же ключ. В ассиметричных разные. Тот которым расшифровывают сообщения называется закрытым ключем, ключ для шифрования называется открытым. Поэтому раздел криптографии изучающий свойства открытых ключей получил название криптография открытого ключа. С помощью открытых и закрытых ключей можно подписывать документы. Для этого рядом с ключем сохраняют данные о владельце ключа и полученный файлы называется сертификатом. Вся система взаимотношений между владельцами сертификатов построена на доверии к определенным пользователям. Их подписи общеизвестны, и они подписывают сертификаты других членов, подтверждая тем самым достоверность открытого ключа и хранящихся вместе с ним данных о владельце. Для того что бы система не была скомпрометирована, пользователи принимают только сертификаты с подписями доверенных членов. Приведем более строгую терминологию:
Инфраструктура открытого ключа (PKI) является системой цифровых сертификатов, центров сертификации (ЦС), которая производит проверку и подтверждение подлинности каждой из сторон, участвующих в электронной операции, с помощью криптографии открытых ключей.
Сертификат открытого ключа, обычно называемый просто сертификатом - это документ с цифровой подписью, связывающий значение открытого ключа с удостоверением пользователя, устройства или службы, которым принадлежит соответствующий закрытый ключ.
Центр Сертификации (Certification Authority, CA) является пакетом программного обеспечения, принимающим и обрабатывающим запросы на выдачу сертификатов, издающим сертификаты и управляющим выданными сертификатами.
Корневой сертификат - сертификат принадлежащий Центру Сертификации, с помощью которого проверяется достоверность других выданных центром сертификатов.

Список отозванных сертификатов - список скомпрометированных или недействительных по какой либо другой причине сертификатов.

Отличительное имя (Distinguished Name, DN) - данные о владельце сертификата. Включают CN (Common Name), OU (Organization Unit), O (Organization), L (Locality), ST (State or province), C (Country name).

Электронная цифровая подпись (ЭЦП)- реквизит электронного документа предназначенный для удостоверения источника данных и защиты данного электронного документа от подделки.

Схема электронной подписи обычно включает в себя:

алгоритм генерации ключей пользователя;

функцию вычисления подписи;

функцию проверки подписи.

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

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

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

Итого у центра сертификации имеется:

закрытый ключ

корневой сертификат (хранящий в себе открытый ключ);

список отозванных (скомпрометированных) сертификатов

У клиентов:

закрытый ключ;

сертификат, подписанный корневым;

корневой сертификат для проверки того, что сертификаты других пользователей выданы его доверенным центром;

список отозванных (скомпрометированных) сертификатов.

Создание корневого сертификата включает:

Генерацию закрытого ключа.

Генерацию открытого ключа и его подпись с помощью закрытого.

Создание обычного сертификата включает:

Генерацию закрытого ключа.

Создание запроса на подпись сертификата.

Подпись запроса в центре сертификации о получение сертификата.

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

OpenSSL - набор криптографических программ и библиотек - предоставляет средства для управления сертификатами и закрытыми ключами. Синтаксис вызова его функций openssl имя_команды параметры. Наиболее часто встречаемые параметры - это -in имя_файла - файл, который обрабатывается, и -text - отобразить информацию о файле в текстовом формате. Основные команды:

rsa	Работа с ключами
x509	Работа с файлами сертификатов в формате PEM
pkcs12	Работа с файлами сертификатов в формате PKCS12
crl	Работа со списком отозванных сертификатов

Примеры использования:

Отобразить информацию о закрытом ключе:

#openssl rsa -text -in ca.key Enter pass phrase for ca.key: writing RSA key: Private-Key: (4096 bit) modulus: 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4: 9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00: 85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:

Отобразить информацию о сертификате в формате PEM:

#openssl x509 -text -in ca.crt Certificate: Data: Version: 3 (0x2) Serial Number: b5:b5:a9:0e:3d:ed:fb:24 Signature Algorithm: sha1WithRSAEncryption Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Validity Not Before: Oct 31 13:57:31 2007 GMT Not After : Oct 28 13:57:31 2017 GMT Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): 00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df: 81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00: 21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4: 9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00: 85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:

Детальную информацию Вы можете получить из документации OpenSSL.

Практическое руководство по созданию центра сертификации

Глеб Пахаренко (Gleb Pakharenko), gpaharenko at gmail com

Предварительная подготовка

Данный этап включает оценку числа клиентов, спецификацию требуемых типов сертификатов, требования к их стойкости и времени жизни. На выходе желательно получить предварительные версии Certificate Policy и Certificate Practic. Возможно, это будет один совмещенный документ. В Certificate Policy описываются общая архитектура центра сертификации, ответственные лица, процедуры первоначальной генерации корневого сертификата, резервного копирования, обстоятельства отзыва ключей, механизм передачи сертификатов клиентам (внутренним и внешним). В Certificate Statement описываются типы сертификатов, необходимые атрибуты и расширения, уточнения процедур передачи отзыва, перевыдачи, сроки жизни. Предусмотрите также действия в случае компрометации центра. Желательно систематизировать именование полей сертификатов, к примеру, в качестве OU можно использовать общепринятое название отдела. В Интернете можно найти множество примеров данных документов.
В статье у нас будет только 2 типа сертификатов: клиентский и серверный. Серверный предназначен для аутентификации веб-серверов. Клиентский используется для аутентификации клиента при доступе к веб-ресурсу.
Таким образом, в нашем конкретном случае необходимо ответить на следующее:

длина ключа корневого сертификата;

длина ключа серверного сертификата;

длина ключа клиентского сертификата;

срок действия корневого сертификата;

срок действия серверного сертификата;

срок действия клиентского сертификата;

срок действия revocation list;

сроки проводения резервного копирования и восстановления;

ответственные лица и подразделения компании, связанные с деятельностью центра сертификации;

пароль для корневого сертификата.

Рекомендую выработать общие правила для настройки авторизации X509 и параметров SSL на серверах компании. В документе можно описать разрешенные криптоалгоритмы, версии SSL, глубину верификации цепочки сертификатов, какие данные о сертификате клиента следует отображать в журналах.
Из опыта рекомендую назначить системных администраторов ответственными за внедрение, безопасное хранение, своевременное обновление серверных сертификатов данных серверов. Использование материальных носителей при передаче сертификатов создает избыточную нагрузку на ответственных за выдачу. Как вариант можно использовать разные каналы связи, сертификат по e-mail, пароль по телефону, sms. Большинство пользователей клиентских сертификатов не в состоянии самостоятельно сгенерировать запрос на подпись, поэтому ключи для них нужно создавать самим. При экспорте клиентам нужен файл в pkcs12 формате, администраторам серверов файлы ключа и сертификата в формате PEM. Необходимо следить за временем на машине центра сертификации, т.к. неточность грозит тому, что сертификат может быть недействителен некоторое время после выдачи. Компьютер центра желательно отключить от сети. Передачу сертификатов можно осуществлять на flash-носителе.

скрипт для упаковки необходимых для

Краткое описание файлов:

bundleclient.sh	скрипт для упаковки необходимых для отправки клиенту файлов
bundleserver.sh	скрипт для упаковки необходимых для отправки клиенту файлов
ca.conf	файл с параметрами корневого сертификата
ca.crt	корневой сертификат
ca.db.certs	Каталог, где хранятся выданные сертификаты
ca.key	закрытый ключ сертификата
ca.pfx	корневой сертификат в специальном формате
carevoke.config	файл с параметрами отзыва сертификатов
createca.sh	скрипт создания корневого сертификата
createclient.sh	скрипт создания клиентского сертфиката
createcrl.sh	скрипт создания списка отозваных сертификатов
createserver.sh	скрипт создания серверного сертификата
crl.pem	список отозваных сертификатов
revoke.sh	скрипт отзыва сертификата
sign1.sh	Скрипт, подписывающий серверные сертификаты
signclient.sh	Скрипт, подписывающий клиентские сертификаты

В каталоге, в котором будет лежать серверный сертификат, необходимо поместить файл с параметрами openssl.conf.
В каталоге, в котором будет лежать клиентский сертификат, необходимо поместить файл с параметрами openssl.conf и файл с паролем pass.

К созданию центра сертификации необходимо

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

Проверка алгоритмов асимметрического шифрования:

Подписывание Проверка За секунду подп. За секунду пров. rsa 512 bits 0.0036s 0.0003s 281.4 3221.7 rsa 1024 bits 0.0184s 0.0009s 54.3 1072.9 rsa 2048 bits 0.1105s 0.0032s 9.0 315.6 rsa 4096 bits 0.7414s 0.0112s 1.3 89.4
dsa 512 bits 0.0032s 0.0038s 311.3 261.3 dsa 1024 bits 0.0093s 0.0116s 107.5 86.4 dsa 2048 bits 0.0309s 0.0377s 32.4 26.5

Результат работы тестов скорости

Алгоритм 8 байт 64 байта 256 байт 1024 байта 8192 байт
md2 291.38k 817.15k 1109.67k 1218.56k 1256.11k mdc2 868.57k 911.02k 914.01k 915.11k 917.50k md4 4417.91k 24808.28k 51404.97k 70189.40k 78168.06k md5 3905.61k 21142.91k 41515.69k 55489.54k 59091.63k hmac(md5) 1536.42k 10381.81k 27585.13k 46119.35k 57671.68k sha1 2458.59k 11965.97k 21560.58k 26889.22k 29143.66k rmd160 2032.99k 9523.48k 16568.15k 20547.81k 22220.11k rc4 28775.08k 39239.02k 41210.52k 41862.98k 41454.25k des cbc 7586.90k 8411.44k 8580.28k 8627.29k 8612.52k des ede3 2866.13k 3031.96k 3050.92k 3074.74k 3058.35k idea cbc 4948.09k 5743.19k 5760.09k 5744.67k 5723.48k rc2 cbc 2982.04k 3220.39k 3256.32k 3263.49k 3268.61k rc5-32/12 cbc 19108.39k 24151.19k 24906.75k 25154.90k 25212.25k blowfish cbc 11018.91k 12881.27k 12925.01k 12972.37k 13047.13k cast cbc 10943.48k 12674.30k 12877.74k 12994.56k 13011.63k



    Работа с информацией: Безопасность - Защита - Софт - Криптография

• Информационная безопасность
  
• Аспекты информационной безопасности
  
• Системы информационной безопасности
  
• Софт и информационная безопасность
  
• IInternet Information Services
  
  
• Защита и безопасность
  
• Защита с Firewall
  
• Атаки и информационная безопасность
  
• Информационная безопасность в интернет
  
  
• Борьба с вирусами
  
• Антивирусы против вирусов
  
• Хакеры и информационная безопасность
  
  
• Криптография
  

---

---