Виды структур баз данных (стр. 7 )

2.  Вычисляется дайджест m = h(M).

3.  Подпись считается верной, если выполняется сравнение:

Криптостойкость

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

23.  Функция хеширования SHA, Md5, Sha-1.

SHA-1

Secure Hash Algorithm 1 — алгоритм криптографического хеширования. Описан в RFC 3174. Для входного сообщения произвольной длины (максимум 264 − 1 бит) алгоритм генерирует 160-битное хеш-значение, называемое также дайджестом сообщения. Используется во многих криптографических приложениях и протоколах. Также рекомендован в качестве основного для государственных учреждений в США. Принципы, положенные в основу SHA-1, аналогичны тем, которые использовались Рональдом Ривестом при проектировании MD4.

Описание алгоритма

Одна итерация алгоритма SHA1

SHA-1 реализует хеш-функцию, построенную на идее функции сжатия. Входами функции сжатия являются блок сообщения длиной 512 бит и выход предыдущего блока сообщения. Выход представляет собой значение всех хеш-блоков до этого момента. Иными словами хеш блока Mi равен hi = f(Mi, hi − 1). Хеш-значением всего сообщения является выход после Сравнение SHA-1 с другими алгоритмами

Сравнение MD5 и SHA-1 являются, по сути, улучшенными продолжениями MD4.

Сходства:

1.  Четыре этапа.

2.  Каждое действие прибавляется к ранее полученному результату.

3.  Размер блока обработки равный 512 бит.

4.  Оба алгоритма выполняют сложение по модулю 232, они рассчитаны на 32-битную архитектуру.

Различия:

1.  В SHA-1 на четвертом этапе используется та же функция f, что и на втором этапе.

2.  В MD5 в каждом действии используется уникальная прибавляемая константа. В SHA-1 константы используются повторно для каждой из четырех групп.

3.  В SHA-1 добавлена пятая переменная.

4.  SHA-1 использует циклический код исправления ошибок.

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

6.  В MD5 четыре различных элементарных логических функции, в SHA-1 — три.

7.  В MD5 длина дайджеста составляет 128 бит, в SHA-1 — 160 бит.

8.  SHA-1 содержит больше раундов (80 вместо 64) и выполняется на 160-битном буфере по сравнению со 128-битным буфером MD5. Таким образом, SHA-1 должен выполняться приблизительно на 25 % медленнее, чем MD5 на той же аппаратуре.

Брюс Шнайер делает следующий вывод : «SHA-1 — это MD4 с добавлением расширяющего преобразования, дополнительного этапа и улучшенным лавинным эффектом. MD5 — это MD4 с улучшенным битовым хешированием, дополнительным этапом и улучшенным лавинным эффектом.»

MD5 (англ. Message Digest 5) — 128-битный алгоритм хеширования, разработанный профессором Ривестом из Массачусетского технологического института (Massachusetts Institute of Technology, MIT) в 1991 году. Предназначен для создания «отпечатков» или «дайджестов» сообщений произвольной длины. Является улучшенной в плане безопасности версией MD4.[1] Зная MD5-образ (называемый также MD5-хеш или MD5-дайджест), невозможно восстановить входное сообщение, так как одному MD5-образу могут соответствовать разные сообщения. Используется для проверки подлинности опубликованных сообщений путём сравнения дайджеста сообщения с опубликованным. Эту операцию называют «проверка хеша» (hashcheck). Описан в RFC 1321.
Алгоритм MD5

Схема работы алгоритма MD5

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

Ниже приведены 5 шагов алгоритма: Шаг 1. Выравнивание потока. Входные данные выравниваются так, чтобы их размер был сравним с 448 по модулю 512 (L’ = 512 × N + 448). Сначала дописывают единичный бит в конец потока, затем необходимое число нулевых бит (выравнивание происходит, даже если длина уже конгруэнтна — сравнима с 448). Шаг 2. Добавление длины сообщения. В оставшиеся 64 бита дописывают 64-битное представление длины данных (количество бит в сообщении) до выравнивания. Если длина превосходит 264 − 1, то дописывают только младшие биты. После этого длина потока станет кратной 512. Вычисления будут основываться на представлении этого потока данных в виде массива слов по 512 бит. Шаг 3. Инициализация буфера. Для вычислений инициализируются 4 переменных размером по 32 бита и задаются начальные значения шестнадцатеричными числами:

А =; В = 89 AB CD EF; С = FE DC BA 98; D =

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

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

·  Потребуются 4 функции для четырёх раундов. Введём функции от трёх параметров — слов, результатом также будет слово.

1 раунд .

2 раунд .

3 раунд .

4 раунд .

·  Определим таблицу констант T[1..64] — 64-элементная таблица данных, построенная следующим образом: T[i] = int( * | sin(i) | ), где = 232.[3]

·  Выровненные данные разбиваются на блоки (слова) по 32 бита, и каждый блок проходит 4 раунда из 16 операторов. Все операторы однотипны и имеют вид: [abcd k s i], определяемый как a = b + ((a + Fun(b, c,d) + X[k] + T[i]) < < < s), где X — блок данных. X[k] = M [n * 16 + k], где k — номер 32-битного слова из n-го 512-битного блока сообщения, и s — циклический сдвиг влево на s бит полученого 32-битного аргумента.

Шаг 4. Вычисление в цикле Заносим в блок данных элемент n из массива. Сохраняются значения A, B, C и D, оставшиеся после операций над предыдущими блоками (или их начальные значения, если блок первый).

AA = A; BB = B; CC = C; DD = D

Суммируем с результатом предыдущего цикла: A = AA + A; B = BB + B; C = CC + C; D = DD + D После окончания цикла необходимо проверить, есть ли ещё блоки для вычислений. Если да, то изменяем номер элемента массива (n++) и переходим в начало цикла.

Шаг 5. Результат вычислений

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

24.  Функция хеширования SHA-256< Ansix9.30.2.

SHA-2 (англ. Secure Hash Algorithm Version 2 — безопасный алгоритм хеширования, версия 2) — собирательное название однонаправленных хеш-функций SHA-224, SHA-256, SHA-384 и SHA-512. Хеш-функции предназначены для создания «отпечатков» или «дайджестов» сообщений произвольной битовой длины. Применяются в различных приложениях или компонентах, связанных с защитой информации.

Алгоритм

Общее описание

Схема одной итерации алгоритмов SHA-2

Хеш-функции семейства SHA-2 построены на основе структуры Меркла — Дамгарда (англ.).

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

Алгоритм использует следующие битовые операции:

·  ǁ — Конкатенация,

·  + — Сложение,

·  and — Побитовое «И»,

·  or — Побитовое «ИЛИ»,

·  xor — Исключающее «ИЛИ»,

·  shr — Логический сдвиг вправо,

·  rotr — Циклический сдвиг вправо.

В следующей таблице показаны некоторые технические характеристики различных вариантов SHA-2. «Внутреннее состояние» обозначает промежуточную хеш-сумму после обработки очередного блока данных:

Хеш-функция	Длина дайджеста сообщения (бит)	Длина внутреннего состояния (бит)	Длина блока (бит)	Максимальная длина сообщения (бит)	Длина слова (бит)	Количество итераций в цикле
SHA-256/224	256/224	256	512	264 − 1	32	64
SHA-512/384	512/384	512	1024	2128 − 1	64	80

25.  Электронная подпись.

Электро́нная цифрова́я по́дпись (ЭЦП) — реквизит электронного документа, предназначенный для защиты данного электронного документа от модификации, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе, [1] а также обеспечивает неотказуемость подписавшегося.

Общая схема

Существует несколько схем построения цифровой подписи:

·  На основе алгоритмов симметричного шифрования. Данная схема предусматривает наличие в системе третьего лица — арбитра, пользующегося доверием обеих сторон. Авторизацией документа является сам факт зашифрования его секретным ключом и передача его арбитру.[7]

·  На основе алгоритмов асимметричного шифрования. На данный момент такие схемы ЭЦП наиболее распространены и находят широкое применение.

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

Представим теперь готовую к передаче хеш-сумму в виде нескольких k-битных блоков hi, где k – это размер сообщений по алгоритму. Вычислим над каждым блоком значение si=((hi)d)mod n, где d – это закрытый ключ отправителя. Теперь сообщение, состоящее из блоков si можно "спокойно" передавать по сети. Никакой опасности по известным hi и si найти Ваш секретный ключ нет – это очень сложная задача. А вот любой получатель сообщения может легко прочесть исходное значение hi, выполнив операцию ((si)e)mod n = ((hi)d*e)mod n = hi – Ваш открытый ключ (e, n) есть у всех, возведение любого числа в степень (e*d) по модулю n дает исходное число. При этом никто другой, кроме Вас, не зная Вашего закрытого ключа d не может, изменив текст, а следовательно, и хеш-сумму, вычислить такие s'i, чтобы при их возведении в степень e получилась хеш-сумма h'i, совпадающая с хеш-суммой фальсифицированного текста. Манипуляции с хеш-суммой текста представляют из себя "асимметричное шифрование наоборот" : при отправке используется закрытый ключ отправителя, а для проверки сообщения – открытый ключ отправителя. Подобная технология получила название "электронная подпись". Информацией, которая уникально идентифицирует отправителя (его виртуальной подписью), является закрытый ключ d.

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

Назначение и применение ЭЦП

Цифровая подпись предназначена для аутентификации лица, подписавшего электронный документ[6]. Кроме этого, использование цифровой подписи позволяет осуществить:

·  Доказательное подтверждение авторства документа. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.

·  Контроль целостности передаваемого документа. При любом случайном или преднамеренном изменении документа изменится подпись, следовательно, она станет недействительной.

·  Защиту от изменений (подделки) документа.

·  Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, то владелец не может отказаться от своей подписи под документом.

Все эти свойства ЭЦП позволяют использовать её для следующих целей[8]:

·  Декларирование товаров и услуг (таможенные декларации)

·  Регистрация сделок по объектам недвижимости

·  Использование в банковских системах

·  Электронная торговля и госзаказы

·  Контроль исполнения государственного бюджета

·  В системах обращения к органам власти

·  Для обязательной отчетности перед государственными учреждениями

·  Организация юридически значимого электронного документооборота

·  В расчетных и трейдинговых системах

Использование хеш-функций

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

Также существуют другие преимущества использования хеш-функций вместе с ЭЦП:

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

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

·  Целостность. Без использования хеш-функции большой электронный документ в некоторых схемах нужно разделять на достаточно малые блоки для применения ЭЦП. При верификации невозможно определить все ли блоки получены и в правильном ли они порядке.

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

Модели атак и их возможные результаты

В своей работе Гольдвассер, Микали и Ривест описывают следующие модели атак, которые актуальны и в настоящее время[4]:

·  Атака с использованием открытого ключа. Криптоаналитик обладает только открытым ключом.

·  Атака на основе известных сообщений. Противник обладает допустимыми подписями набора электронных документов, известных ему, но не выбираемых им.

·  Адаптивная атака на основе выбранных сообщений. Криптоаналитик может получить подписи электронных документов, которые он выбирает сам.

Также в работе описана классификация возможных результатов атак:

·  Полный взлом цифровой подписи. Получение закрытого ключа, что означает полный взлом алгоритма.

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

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

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

Ясно, что самой «опасной» атакой является адаптивная атака на основе выбранных сообщений, и при анализе алгоритмов ЭЦП на криптостойкость нужно рассматривать именно ее (если нет каких-либо особых условий).

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

Подделка документа (коллизия первого рода)

Злоумышленник может попытаться подобрать документ к данной подписи, чтобы подпись к нему подходила. Однако в подавляющем большинстве случаев такой документ может быть только один. Причина в следующем:

·  Документ представляет из себя осмысленный текст.

·  Текст документа оформлен по установленной форме.

·  Документы редко оформляют в виде Plain Text — файла, чаще всего в формате DOC или HTML.

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

·  Случайный набор байт должен подойти под сложно структурированный формат файла.

·  То, что текстовый редактор прочитает в случайном наборе байт, должно образовывать текст, оформленный по установленной форме.

·  Текст должен быть осмысленным, грамотным и соответствующий теме документа.

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

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

Получение двух документов с одинаковой подписью (коллизия второго рода)

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

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

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

Использование ЭЦП. В России юридически значимый сертификат электронной подписи выдаёт удостоверяющий центр. Правовые условия использования электронной цифровой подписи в электронных документах регламентирует ФЕДЕРАЛЬНЫЙ ЗАКОН ОТ 10.01.2002 N 1-ФЗ «ОБ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ»

26.  Система шифрования Crypto Api. (http://www.cryptopro.ru/CryptoPro/documentation/capi.htm)

CryptoAPI — интерфейс программирования приложений, который обеспечивает разработчиков Windows-приложений стандартным набором функций для работы с криптопровайдером. Входит в состав операционных систем Microsoft. Большинство функций CryptoAPI поддерживается начиная с Windows 2000.

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

Windows API (application programming interfaces) — общее наименование целого набора базовых функций интерфейсов программирования приложений операционных систем семейств Windows и Windows NT корпорации «Майкрософт». Является самым прямым способом взаимодействия приложений с Windows. Для создания программ, использующих Windows API, «Майкрософт» выпускает SDK, который называется Platform SDK и содержит документацию, набор библиотек, утилит и других инструментальных средств.

Общие сведения

Windows API был изначально спроектирован для использования в программах, написанных на языке C (или C++). Работа через Windows API — это наиболее близкий к системе способ взаимодействия с ней из прикладных программ. Более низкий уровень доступа, необходимый только для драйверов устройств, в текущих версиях Windows предоставляется через Windows Driver Model.

[править] Версии

·  Win16 — первая версия Windows API для 16-разрядных версий Windows. Изначально назывался просто Windows API, затем стал называться Win16 для отличия от Win32.

·  Win32s — подмножество Win32, устанавливаемое на семейство 16-разрядных систем Windows 3.x и реализующее ограниченный набор функций Win32 API для этих систем.

·  Win32 — 32-разрядный API для современных версий Windows. Самая популярная ныне версия. Базовые функции этого API реализованы в DLL kernel32.dll и advapi32.dll; базовые модули GUI — в user32.dll и gdi32.dll. Win32 появился вместе с Windows NT и затем был перенесён (в несколько ограниченном виде) в системы серии Windows 9x. В современных версиях Windows, происходящих от Windows NT, работу Win32 GUI обеспечивают два модуля: csrss. exe (Client/Server Runtime Subsystem), работающий в пользовательском режиме, и win32k. sys в режиме ядра. Работу же системных Win32 API обеспечивает ядро - ntoskrnl. exe

·  Win64 — 64-разрядная версия Win32, содержащая дополнительные функции для использования на 64-разрядных компьютерах. Win64 API можно найти только в 64-разрядных версиях Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2008 R2 и Windows 7.

27.  Delphi и Windows Api для защиты секретов. (http://www.citforum.ru/security/articles/defense/)

Delphi и Windows API для защиты секретов (части 1,2,3)

Константин Виноградов, Лилия Виноградова, "Комиздат"

Как реализовать методы криптографической защиты информации при помощи подручных средств – Windows и Delphi

Часть 1

Мы вступили в цифровой век. На смену бумажным документам пришли электронные, а личные контакты все чаще уступают место переписке по e-mail. Поэтому «шпионские штучки» вроде паролей и шифровок становятся все более привычными и необходимыми инструментами безопасности.

Криптографические возможности Windows

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

Итак, ОС мы доверяем. Чтобы криптозащиту нельзя было «обойти» с другой стороны - к примеру, перехватить из незащищенной области памяти секретные пароли - криптографические функции должны быть частью операционной системы. В семействе Windows, начиная с Windows 95, обеспечивается реализация шифрования, генерации ключей, создания и проверки цифровых подписей и других криптографических задач. Эти функции необходимы для работы операционной системы, однако ими может воспользоваться и любая прикладная программа - для этого программисту достаточно обратиться к нужной подпрограмме так, как предписывает криптографический интерфейс прикладных программ (CryptoAPI).

Разумеется, по мере совершенствования Windows расширялся и состав ее криптографической подсистемы. Помимо базовых операций, в настоящее время в CryptoAPI 2.0 поддерживается работа с сертификатами, шифрованными сообщениями в формате PKCS #7 и пр.

Описание функций CryptoAPI, помимо специальных книг, можно найти в MSDN Library.

Взаимодействие с CryptoAPI

Функции CryptoAPI можно вызвать из программы, написанной на любимом многими (в том числе и авторами) языке С++. Тем не менее, Pascal де-факто признан стандартом в области обучения программированию. (Не будем спорить о том, хорошо это или плохо, чтобы не ввязываться в драку, пусть даже и виртуальную.) Кроме того, в ряде отечественных компаний Delphi является базовым средством разработки. Поэтому все примеры были реализованы в среде Delphi. Хотя в качестве инструмента можно было бы выбрать и MS Visual C++.

Код функций криптографической подсистемы содержится в нескольких динамически загружаемых библиотеках Windows (advapi32.dll, crypt32.dll). Для обращения к такой функции из прикладной программы на Object Pascal следует объявить ее как внешнюю. Заголовок функции в интерфейсной части модуля будет выглядеть, например, так:

function CryptAcquireContext (

phPROV: PHCRYPTPROV;

pszContainer: LPCTSTR;

pszProvider: LPCTSTR;

dwProvType: DWORD;

dwFlags: DWORD): BOOL; stdcall;

а в исполняемой части вместо тела функции нужно вписать директиву extern с указанием библиотеки, в которой содержится функция, и, возможно, ее имени в этой библиотеке (если оно отличается от имени функции в создаваемом модуле), например:

function CryptAcquireContext; external ‘advapi32.dll’

name 'CryptAcquireContextA';

Таким образом, имея описание функций CryptoAPI, можно собрать заголовки функций в отдельном модуле, который будет обеспечивать взаимодействие прикладной программы с криптографической подсистемой. Разумеется, такая работа была проделана программистами Microsoft, и соответствующий заголовочный файл (wincrypt. h) был включен в поставку MS Visual C++. К счастью, появилась и Delphi-версия (wcrypt2.pas). Ее можно найти здесь. Подключив модуль к проекту, вы сможете использовать не только функции CryptoAPI, но и мнемонические константы режимов, идентификаторы алгоритмов и прочих параметров, необходимых на практике.

И последнее замечание перед тем, как опробовать CryptoAPI в деле. Ряд функций был реализован только в Windows 2000. Но и на старушку Windows 98 можно найти управу: при установке Internet Explorer 5 интересующие нас библиотеки обновляются, позволяя использовать новейшие криптографические возможности. Нужно лишь задать для Delphi-проекта параметр условной компиляции NT5, после чего вызовы функций, появившихся лишь в Windows 2000, будут нормально работать.

Знакомство с криптопровайдерами

Функции CryptoAPI обеспечивают прикладным программам доступ к криптографическим возможностям Windows. Однако они являются лишь «передаточным звеном» в сложной цепи обработки информации. Основную работу выполняют скрытые от глаз программиста функции, входящие в специализированные программные (или программно-аппаратные) модули — провайдеры (поставщики) криптографических услуг (CSP - Cryptographic Service Providers), или криптопровайдеры (рис. 1).

Программная часть криптопровайдера представляет собой dll-файл, подписанный Microsoft; периодически Windows проверяет цифровую подпись, что исключает возможность подмены криптопровайдера.

Криптопровайдеры отличаются друг от друга:

·  составом функций (например, некоторые криптопровайдеры не выполняют шифрование данных, ограничиваясь созданием и проверкой цифровых подписей);

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

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

По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования - MD5 и SHA.

В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к уже известному нам типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы.

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

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

·  CryptEnumProviders (i, резерв, флаги, тип, имя, длина_имени) - возвращает имя и тип i-го по порядку криптопровайдера в системе (нумерация начинается с нуля);

·  CryptAcquireContext (провайдер, контейнер, имя, тип, флаги) - выполняет подключение к криптопровайдеру с заданным типом и именем и возвращает его дескриптор (контекст). При подключении мы будем передавать функции флаг CRYPT_VERIFYCONTEXT, служащий для получения контекста без подключения к контейнеру ключей;

·  CryptGetProvParam (провайдер, параметр, данные, размер_данных, флаги) - возвращает значение указанного параметра провайдера, например, версии (второй параметр при вызове функции - PP_VERSION), типа реализации (программный, аппаратный, смешанный - PP_IMPTYPE), поддерживаемых алгоритмов (PP_ENUMALGS). Список поддерживаемых алгоритмов при помощи этой функции может быть получен следующим образом: при одном вызове функции возвращается информация об одном алгоритме; при первом вызове функции следует передать значение флага CRYPT_FIRST, а при последующих флаг должен быть равен 0;