Название работы	Кол-во страниц	Размер
Правовое регулирование применения электронной цифровой подписи	1	60.44kb.
Об электронной цифровой подписи	1	170.67kb.
Современные симметричные и ассиметричные криптосистемы	1	90.33kb.
Современные симметричные и ассиметричные криптосистемы	1	224.22kb.
Закон РФ от 10. 01. 2002 №1-фз "об электронной цифровой подписи"	1	187.08kb.
Положение о порядке разбора конфликтных ситуаций связанных с использованием...	1	63.34kb.
Закон республики беларусь 28 декабря 2009 г. №113-з об электронном...	1	176.76kb.
Лабораторная работа «Взаимодействие с Cryptoapi. Криптопровайдеры»	1	298.11kb.
Лабораторная работа №2 криптографические методы обеспечения подлинности...	1	261.16kb.
Лабораторная работа Лабораторная работа Основы теории множеств	7	1675.01kb.
Лабораторная работа №14 Электронная цифровая подпись	1	100.85kb.
Математические методы защиты информации	1	42.89kb.
Викторина для любознательных: «Занимательная биология»	1	9.92kb.

Лабораторная работа №5
Программирование под CryptoAPI

ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

Введение 3

Алгоритмы электронной цифровой подписи 5

Алгоритм электронной цифровой подписи RSA 6

Алгоритм электронной цифровой подписи DSA 8

Хэш-функции 9

ПРОГРАММИРОВАНИЕ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ, ИСПОЛЬЗУЯ CRYPTOAPI 1.0

Функции CryptoAPI 1.0 9

Функции обеспечения криптопровайдера 10

Функции управления и обмена ключевой информацией 10

Функции шифрования данных 11

Функции хэширования и электронной цифровой подписи 11

ОПИСАНИЕ ФУНКЦИЙ CRYPTOAPI 1.0 НЕОБХОДИМЫХ ДЛЯ ВЫПОЛНЕНИЯ ЛАБОРАТОРНОЙ РАБОТЫ

Описание функций CryptiAPI 11

• 
  CryptAcquireContext
  
• 
  CryptReleaseContext
  
• 
  CryptGetUserKey
  
• 
  CryptGenKey
  
• 
  CryptExportKey
  
• 
  CryptlmportKey
  
• 
  CryptCreateHash
  
• 
  CryptHashData
  
• 
  CryptSignHash
  
• 
  CryptDestroyHash
  
• 
  CryptVerifySignature
  

p

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

и хранение документов, убыстряется их поиск. Но при этом возникает проблемы аутентификации
автора документа и самого документа, т. е. установления подлинности автора и отсутствия

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

Целью аутентификации электронных документов является их защита от возможных видов
злоумышленных действий, к которым относятся:

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

• 
  маскарад - абонент С посылает документ абоненту В от имени абонента А;
  

• 
  ренегатство - абонент А заявляет, что не посылал сообщения абоненту В, хотя на самом
  деле послал;
  

• 
  подмена - абонент В изменяет или формирует новый документ и заявляет, что получил его
  

от абонента А;

• повтор - абонент С повторяет ранее переданный документ, который абонент А посылал

абоненту В.

•
Эти виды злоумышленных действий могут нанести существенный ущерб банковским и

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

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

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

Цифровая подпись представляет собой относительно небольшое количество дополнительной цифровой информации, передаваемой вместе с подписываемым текстом. Система ЭЦП включает две процедуры: 1) процедуру постановки подписи; 2) процедуру проверки подписи. В процедуре постановки подписи используется секретный ключ отправителя сообщения, в процедуре проверки подписи - открытый ключ отправителя.

При формировании ЭЦП отправитель прежде всего вычисляет хэш-функцию h(M)

подписываемого текста М. Вычисленное значение кэш-функции h(M) представляет собой один короткий блок информации т, характеризующий весь текст М в целом. Затем число m шифруется секретным ключом отправителя. Получаемая при этом пара числе представляет собой ЭЦП для данного текста М.

При проверке ЭЦП получатель сообщения снова вычисляет хэш-функции m=h(M) принятого

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

Принципиальным моментом в системе ЭЦП является невозможность подделки ЭЦП

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

В качестве подписываемого документа может быть использован любой файл. Подписанный

файл создается из неподписанного путем добавления в него одной или более электронных

подписей.

Желательно, чтобы каждый подписанный файл содержал следующую информацию:

• 
  дату подписи;
  
• 
  срок окончания действия ключа данной подписи;
  
• 
  информацию о лице, подписавшем файл (Ф.И.О., должность, краткое наименование
  фирмы);
  
• 
  идентификатор подписавшего (имя открытого ключа);
  
• 
  собственно цифровую подпись.
  

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

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

В принципе, можно найти другой текст, который дает то же самое значение хэш-функции, но изменить в нашем тексте десять-двадцать байт так, чтобы текст остался полностью осмысленным, да еще и изменился в выгодную нам сторону (например, уменьшил сумму к оплате в два раза) -чрезвычайно сложно. Именно для устранения этой возможности хэш-функции создают такими же сложными как и криптоалгоритмы - если текст с таким же значением хэш-функции можно будет подобрать только методом полного перебора, а множество значений будет составлять как и для блочных шифров 2³²-2¹²⁸ возможных вариантов, то для поиска подобного текста злоумышленнику «потребуются» миллионы лет.

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

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

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

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

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

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

• 
  задача факторизации (разложения на множители) больших целых чисел;
  
• 
  задача дискретного логарифмирования
  

Таблица. Основные алгоритмы ЭЦП.

Тип Комментарии
DSA (Digital Signature Authorization)	Алгоритм с использованием открытого ключа для создания электронной подписи, но не для шифрования. Секретное создание хэш-значения и публичная проверка ее - только один человек может создать хэш-значение сообщения, но любой может проверить ее корректность. Основан на вычислительной сложности взятия логарифмов в конечных полях.
RSA	Запатентованная RSA электронная подпись, которая позволяет проверить целостность сообщения и личность лица, создавшего электронную подпись. Отправитель создает хэш-функцию сообщения, а затем шифрует ее с использованием своего секретного ключа. Получатель использует открытый ключ отправителя для расшифровки хэша, сам рассчитывает хэш для сообщения, и сравнивает эти два хэша.
MAC (код аутентификации сообщения)	Электронная подпись, использующая схемы хэширования, аналогичные MD или SHA, но хэш-значение вычисляется с использованием как данных сообщения, так и секретного ключа.
DTS (служба электронных временных меток)	Выдает пользователям временные метки, связанные с данными документа, криптографически стойким образом.

Алгоритм цифровой подписи RSA

Первой и наиболее известной во всем мире конкретной системой ЭЦП стала система RSA, математическая схема которой была разработана в 1977 г. В Массачусетском технологическом институте США.

Сначала необходимо вычислить пару ключей (секретный ключ и открытый ключ). Для этого
отправитель (автор) электронных документов вычисляет два больших простых числа Р и Q, затем
находит их произведение N=P*Q и значение функции ц(N)=(P-1)(Q-1).

Далее отправитель вычисляет число Е из условий: Е

Пара чисел (E,N) является открытым ключом. Эту пару чисел автор предает партнерам по
переписке для проверки его цифровых подписей. Число D сохраняется автором как секретный ключ
для подписывания.

Допустим, что отправитель хочет подписать сообщение М перед его отправкой. Сначала сообщение М (блок информации, файл, таблица) сжимают с помощью хэш-функции h(-) в целое число m:

m = h(М)

Затем вычисляют цифровую подпись S под электронным документом М, используя хэш-значение m и секретный ключ D:

S=m^D(mod N).

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

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

m'=S^E(mod N)

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

m=h(M)

Если соблюдается равенство вычислительных значений, т. е. S^E(mod N) = h(M), то получатель признает пару (M,S) подлинной. Доказано, что только обладатель секретного ключа D может сформировать цифровую подпись S по документу М, а определить секретное число D по открытому числу Е не легче, чем разложить модуль на множители.

Кроме того, можно строго математически доказать, что результат проверки цифровой подписи S будет положительным только в том случае, если при вычислении S был использован секретный ключ D, соответствующий открытому ключу Е. Поэтому открытый ключ Е иногда называют «идентификатором» подписавшего. Недостатки алгоритма цифровой подписи RSA.

1. 
   При вычислении модуля N, ключей Е и D для системы цифровой подписи RSA
   необходимо проверять большое количество дополнительных условий, что сделать
   практически трудно. Невыполнение любого из этих условий делает возможным
   фальсификацию цифровой подписи со стороны того, кто обнаружит такое
   невыполнение. При подписании важных документов нельзя допускать такую
   возможность даже теоретически.
   
2. 
   Для обеспечения криптостойкости цифровой подписи RSA по отношению к
   попыткам фальсификации на уровне, например, национального стандарта США на
   шифрование информации (алгоритм DES), т. е. 10¹⁸, необходимо использовать при
   вычислениях N, D и Е целые числа не менее 2⁵¹² (или около 10¹⁵⁴) каждое, что
   требует больших вычислительных затрат, превышающих на 20...30%
   

вычислительные затраты других алгоритмов цифровой подписи при сохранении

того же уровня криптостойкости.

3. Цифровая подпись RSA уязвима к так называемой мультипликативной атаке. Иначе

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

Пример.

Допустим, что злоумышленник может сконструировать три сообщения M₁,M2 и М₃, у которых хэш-значения

m₁=h(M₁), m2=h(M₂), m₃=h(M₃), причем m₃=m₁*m₂ (mod N) Допустим также, что для двух сообщений M1 и М2 получены законные подписи

S₁ = m₁d (mod N) и S₂=m₂d (mod N)

Тогда злоумышленник может легко вычислить подпись S₃ для документа М₃, даже не зная секретного ключа D:

S₃=S₁*S₂(mod N)

Действительно:

S₁*S₂ (mod N) = m₁D * m₂D (mod N) = (m₁m₂)D(mod N) = m₃D(mod N) = S₃

Алгоритм цифровой подписи DSA
Алгоритм цифровой подписи DSA (Digital Signature Algorithm) предложен в 1991 г. в НИСТ
США для использования в стандарте цифровой подписи DSS (Digital Signature Standart). Алгоритм
DSA является развитием алгоритмов цифровой подписи Эль Гамаля и К. Шнорра.

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

целые числа: G и Р - простые числа, L бит каждое (512 $ L $ 1024); q - простое число длиной 160
бит (делитель числа (Р-1)). Числа G, P, q являются открытыми и могут быть общими для всех
пользователей сети.

Отправитель выбирает случайное целое число X, l

ключом отправителя для формирования электронной цифровой подписи.

Затем отправитель вычисляет значении

Y=G^X mod P

Число Y является открытым ключом для проверки подписи отправителя. Число Y передается

всем получателям документов. Этот алгоритм также предусматривает использование односторонней
функции хэширования h(-). В стандарте DSS определен алгоритм безопасного хэширования SHA
(Secure Hash algorithm).

Для того, что подписать документ М, отправитель хэширует его в целое хэш-значение m:

m=h(M), 1

затем генерирует случайное целое число К, 1

r=(G mod P) mod q.

Затем отправитель вычисляет с помощью секретного ключа X целое число s:

s = ((m + r * Х)/К) mod q

Пара чисел r и s образует цифровую подпись S=(r,s) под документом М.

Таким образом, подписанное сообщение представляет собой тройку чисел [M,r,s].

Получатель подписанного сообщения [M,r,s] проверяет выполнение условий 0

Затем получатель вычисляет значение: m = (1/S)mod q, хэш-значение m=h(M) и числа u₁ = (m*w) mod q, u₂=(r*w) mod q.

Далее получатель с помощью открытого ключа Y вычисляет значение v=((G_u1*Y_u2) mod P) mod q и проверяет выполнение условия v=r.

Если условие v=r выполняется, тогда подпись S=(r,s) под документом М признается

получателем подлинной.

Можно строго математически доказать, что последнее равенство будет выполняться тогда, и только тогда, когда подпись S(r,s) под документом М получена с помощью именно того секретного ключа X, из которого был получен открытый ключ Y. Таким образом, можно надежно удостовериться, что отправитель сообщения владеет именно данным секретным ключом X (не раскрывая при этом значения ключа X) и что отправитель подписал именно данный документ М.

По сравнению с алгоритмом цифровой подписи Эль Гамаля алгоритм DSA имеет следующие основные преимущества:

1. 
   При любом допустимом уровне стойкости, т. е. при любой паре чисел G и Р (от 512
   до 1024 бит), числа q, X, r, s имеют длину по 160 бит, сокращая длину подписи до
   320 бит.
   
2. 
   Большинство операций с числами К, r, s, X при вычислении подписи производится
   по модулю числа q длиной 160 бит, что сокращает время вычисления подписи.
   

3. При проверке подписи большинство операций с числами u₁, u₂, v, w также
производится по модулю числа q длиной 160 бит, что сокращает объем памяти и
время вычисления.

Недостатком алгоритма DSA является то, что при подписывании и при проверке подписи приходится выполнять сложные операции деления по модулю q:

s = ((m + r * Х)/К) mod q

w=l (mod q), что не позволяет получать максимальное быстродействие.

Следует отметить, что реальное исполнение алгоритма DSA может быть ускорено с помощью выполнения предварительных вычислений. Заметим, что значение r не зависит от сообщения М и его хэш-значения т. Можно заранее создать строку случайных значений К и затем для каждого из этих значений вычислить значения r. Можно также заранее вычислить обратные значения К-1 для каждого из значений К. Затем, при поступлении сообщения М, можно вычислить значение s для данных значений r и К-1. Эти предварительные вычисления значительно ускоряют работу алгоритма DSA.

Хэш - функции

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

Хэш-функция предназначена для сжатия подписываемого документа М до нескольких десятков или сотен бит. Хэш-функция п(-) принимает в качестве аргумента сообщение (документ) М произвольной длины и возвращает хэш-значение h(M)=H фиксированной длины. Обычно хэшированная информация является сжатым довичным представлением основного сообщения произвольной длины. Следует отметить, что значение хэш-функции h(M) сложным образом зависит от документа М и не позволяет восстановить сам документ М.

Хэш-функция должна удовлетворять целому ряду условий:

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

Большинство хэш-функций строится на основе однонаправленной функции f(-), которая образует выходное значение длиной п при задании двух входных значений длиной п. Этими входами являются блок исходного текста Mi и хэш-значение Hi-1 предыдущего блока текста: Hi=f(Mi,Hi-l).

Хэш-значение, вычисляемое при вводе последнего блока текста, становится хэш-значением всего сообщения М.

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

Таблица. Основные алгоритмы хэширования.

Тип Описание
MD2	Самая медленная, оптимизирована для 8-битовых машин
MD4	Самая быстрая, оптимизирована для 32-битных мащин
MD5	Наиболее распространенная из семейства MD-функций. Похожа на MD4, но средства повышения безопасности делают ее на 33% медленнее, чем MD4 Обеспечивает целостность данных Считается безопасной
SHA (Secure Hash Algorithm)	Создает 160-битное значение хэш-функций из исходных данных переменного размера. Предложена NIST и принята правительством США как стандарт Предназначена для использования в стандарте DSS

Программирование цифровых подписей в CryptoApi 1.0.

CryptoApi 1.0 - это интерфейс для Win 32 программ обеспечивающий доступ данных программ к алгоритмам шифрования. При этом приложения не обязательно должны знать об алгоритме реализации этого метода и тем самым облегчается реализация самих программ. При этом за написание самого алгоритма отвечает сама фирма разработчик алгоритма или фирма Micrsoft. Помимо этого может быть обеспечен доступ к аппаратным средствам шифрования. Написание программ становится простым и удобным. Чтобы сменить алгоритм шифрования достаточно поменять определенные параметры вызова функции, что гораздо проще, чем писать заново программу шифрования. Тем более сам алгоритм шифрования может публично не публиковаться, и следовательно собственная реализация данных алгоритмов становится очень сложной.
Реализация алгоритмов шифрования обеспечивается с помощью специальных служб, называемых криптопровайдерами (Cryptographic Service Provider (CSP)). Криптопровайдеры представляют из себя библиотеки (обычно DLL), имеющие стандартные для всех криптопровайдеров внешние функции, обеспечивающие реализацию всех необходимых функций шифрования, и сопутствующих им функций.

Функции CryptoAPI

Среди всего множества функций можно выделить основные группы:

Функции обеспечения криптопровайдера. Включают создание и управление криптопровайдерами, включая настройку их операций.

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

- Функции шифрования данных. Обеспечивают операции шифрования и расшифровки.

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

Функции обеспечения криптопровайдера

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

Функция
Краткое описание

CryptDeriveKey	Создает ключ, получаемый из пароля
CryptDestroyKey	Уничтожает ключ
CryptDuplicateKey	Делает точную копию ключа и его характеристик
CryptExportKey	Экспортирует ключ из криптопровайдера в ключевой блоб в памяти приложения
CryptGenKey	Создает случайный ключ
CryptGenRandom	Генерирует случайный блок данных
CryptGetKeyParam	Получает параметры ключа
CryptGetUserKey	Получает дескриптор обмена или электронной подписи
CryptlmportKey	Импортирует ключ из ключевого блоба в криптопровайдер
CryptSetKeyParam	Устанавливает параметры ключа

Функции шифрования данных

Данные функции реализуют операции шифрования и расшифровки. Следующая таблица кратко описывает каждую функцию.

Функция

Краткое описание

Функция

Краткое описание

CryptCreateHash	Создает «пустой»объект хэша
CryptDestroyHash	Уничтожает объект хэша
CryptDuplicateHash	Дублирует объект хэша
CryptGetHashParam	Получает параметры объекта хэша
CryptHashData	Хэширует блок данных, добавляя хэш к указанному объекту хэша
CryptHashSessionKey	Хэширует сессионный ключ и добавляет значение хэша к указанному объекту хэша
CryptSerHashParam	Устанавливает параметры объекта хэша
CryptSiqnHash	Подписывает указанный объект хэша
CryptVerifySignature	Проверяет цифровую подпись

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

Все функции работы с CryptoAPI имеют прототир функции в модуле Wincrypt.h, библиотека advapi32.dll.

Для своей работы требуют WindowsNT/2000 (Windows NT 4.0 SP4 или старше) или Windows 95/98 (Windows 95 OSR2 или старше, или Windows 95 и Internet Explorer 3.02 или старше).

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

Функция выполняет две операции. Сначала она пытается найти криптопровайдер с характеристиками, описанными в параметрах dwProvType и pszProvider. Если криптопровайдер найден, то функция пытается найти ключевой контейнер в рамках криптопровайдера в соответствии с именем, указанным pszContainer параметром.

Эта функция также может использоваться для создания и уничтожения ключевых контейнеров в зависимости от значения параметра dwFlags.

BOOL WINAPI CryptAcquireContext (

HCRYPYPROV *phProv, //out

LPCSTR pszContainer, //in

LPCSTR pszProvider, //in

DWORD dwProvType, //in

DWORD dwFlags //in

) ;
Параметры

phProv

Указатель на дескриптор криптопровайдера (CSP).

pszContainer

Имя ключевого контейнера. Это указатель на строку, заканчивающуюся нулем, идентифицирующую ключевой контейнер. Если в dwFlags установлен флаг CRYPT_VERIFYCONTEXT, то pszContainer Должен быть равен NULL.

Если данные параметр - NULL, то будет использовать имя по умолчанию. Криптопровайдеры

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

Указатель на строку, заканчивающуюся нулем, содержащую имя криптопровайдера. Если

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

определены следующие типы криптопровайдеров:

PROV_RSA_FULL PROV_RSA_SIG PROVJDSS PROV_DSS_DH PROV_DH_SCHANNEL PROV_FORTEZZA PROV_MS_EXCHANGE

PROV_RSA_SCHANNEL PROV_SSL

dwFlags

Параметр имеет нулевое или одно из следующих значений:

Значение dwFlags Описание
CRYPTVERIFYCONTEXT	Если флаг установлен, то приложение не имеет доступа к секретным ключам ключевого контейнера. Флаг предназначен для использования с приложениями, целью которых является проверка цифровой подписи. Операции, обычно необходимые в этом случае, получение дескрипторов открытых ключей, хэширование ипроверка подписи.
CRYPTNEWKEYSET	Если флаг установлен, то будет создан новый ключевой контейнер с именем, соответствующим pszContainer. Если pszContainer - NULL, то будет создан ключевой контейнер с именем, заданным по умолчанию.
CRYPTMACHINEKEYSET	По умолчанию ключи сохраняются в разделе HKEYCURRENTUSER системного реестра. Флаг CRYPTMACHNEKEYSET может использоваться при вызове CryptAcquireContext с флагом CRYPTNEWKEYSET или CRYPT JDELETEKEYSET, в этом случае ключи будут сохранены в разделе HKEYLOCALMACHINE системного реестра.
CRYPTDELETEKEYSET	Если флаг установлен, то ключевой контейнер, соответствующий pszContainer, удаляется. Если pszContainer - NULL, то удаляется ключевой контейнер с именем, заданным по умолчанию. Все ключевые пары в ключевом контейнере также уничтожаются. Когда флаг CRYPTDELETEKEYSET установлен, значение, возвращенное в phProv, не определено и функция CryptReleaseContext не должна вызываться повторно.

Возвращаемое значение

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

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

BOOL CryptReleaseContext (

HCRYPTPROV hProv, //in

DWORD dwFlags - //in

) ;

Параметры hProv

Дескриптор криптопровайдера, полученный приложением через вызов функции CryptAcqireContext

dwFlags

Значение флагов. Это параметр зарезервирован для будущего использования и должен быть нулевым.

Возвращаемое значение

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

Функция CryptGetUserKey возвращает дескриптор одной из постоянных ключевых пар.

BOOL CryptGetUserKey (

HCRYPTPROV hProv, //in

DWORD dwKeySpec, //in

HCRYPTKEY *phllserKey

//out

BOOL CryptGetUserKey ( HCRYPTPROV hProv, DWORD dwKeySpec, HCRYPTKEY *phUserKey

); Параметры

//in //in

//out

Значение dwFlags

Описание

CRY PTEXPORTABLE

Если этот флаг установлен, то ключ сессии может быть

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

CRYPTPREGEN Этот флаг определяет инициализацию генерации пар Диффи-Хеллман и DSS/ Флаг используется только с криптопровайдерами, поддерживающими Диффи-Хеллмана/DSS алгоритмы.

phKey

Адрес, по которому функция копирует дескриптор произведённого ключа.

Возвращаемое значение

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

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

BOOL CryptGetUserKey (

HCRYPTPROV hKey, // in

HCRYPTPROV hExpKey, //in

DWORD dwBlodType. //in

DWORD dwFlags //in

BYTE *pbData, //out

DWORD dwDataLen. // in, out

) ;

.Параметры

hKey

Дескриптор экспортируемого ключа.

hExpKey

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

dwBlobType

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

следующие типы ключевых блобов:

• 
  SIMPLEBLOB - используется для экспорта сессионных ключей;
  
• 
  PUBLICKEYBLOB - используется для экспорта открытых ключей ключевых пар подписи или
  обмена ключами;
  
• 
  PUBLICKEYBLOBEX - используется для обмена значениями Р, G, и (G^) mod P в обмене
  ключами по алгоритму Диффи-Хеллмана;
  
• 
  PRIVATEKEYBLOB - используется для транспортировки пары открытый/секретный ключи.
  

dwFlags

Значение флагов. Этот параметр зарезервирован для будущего использования и должен быть

нулевым.

pbData

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

pdwDataLen

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

буфере pbData. После её исполнения параметр будет установлен числом байтов данных параметра,

скопированных в буфер pbData.

Если буфер, соответствующий pbData, недостаточно большой, чтобы в него копировать

запрошенные данные, будет возвращен код ошибки ERROR_MORE_DATA через функцию

SetLastError. В этом случае требуемый размер буфера возвращается в pdwDataLen.

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

Возвращаемое значение

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

Функция CryptlmportKey используется для импорта криптографического ключа из ключевого блоба в контейнер криптопровайдера.

BOOL CryptoImportKey

HCRYPTPROV hProv, // in

CONST BYTE *pbData, //in

DWORD dwDataLen. //in

HCRYPTPROV MmpKey, //in

DWORD dwFlags. //out

HCRYPTPROV *phKey, // in, out

) ;

Параметры

hProv

Дескриптор криптопровайдера. Указанный дескриптор получается через запрос к функции

CryptAcquireContext.

PbData

Буфер, содержащий ключевой блоб. Этот блоб был произведен функцией CryptExportKey данным

криптопровайдером или иным криптопровайдером, исполняющим на удаленном компьютере.

Ключевой блоб состоит из стандартного заголовка и зашифрованного ключа. .

pdwDataLen

Длинна ключевого блоба (в байтах).

MmpKey

Дескриптор ключа, на котором осуществляется снятие криптографической защиты импортируемого

ключа. Значение этого параметра должно соответствовать значению hExpKey ,

Определенному для функции CryptExportKey при создании ключевого блоба.

Если ключевой блоб зашифрован на ключевой паре обмена ключей (например, SIMPLEBLOB), этот

параметр должен быть дескриптором на ключ обмена.

Если ключевой блоб зашифрован на сессионном ключе, этот параметр должен содержать

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

Если ключей блоб не зашифрован (например, PUBLICKEYBLOB), то этот параметр не используется и

должен быть установлен в ноль.

dwFlags

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

(публичный/секретный ключи) импортируется в криптопровайдер (в форме PRIVATEKEYBLOB). В

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

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

phKey

Адрес, по которому функция копирует дескриптор импортированного ключа.

Возвращаемое значение

При успешном завершении функции возвращает TRUE, в противном случае возвращается FALSE.

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

получен через функцию GetLastError.

Функция CryptCreateHash используется для инициализации объекта хэширования потока данных. Функция возвращает дескриптор объекта хэширования. Этот дескриптор используебтся в последующих вызовах CryptHashData и CryptHashSessionKey для хэширования потока данных и сессионных ключей.

BOOL CryptCreateHash (

HCRYPTPROV hProv, // in

ALGJD hProv, // in

HCRYPTKEY hKey, // in

DWORD dwFlags, // in

HCRYPTPROV *phHesh, //out

hProv

Дескриптор ключевого контейнера криптопровайдера. Указанный дескриптор получается через

запрос к функции CryptAcquireContext.

Algid

Идентификатор используемого алгоритма хэширования. Значение параметра зависит от

используемого криптопровайдера.

В криптопровайдерах Microsoft определены следующие алгоритмы хэширования:

CALGHMAC	Алгоритм хэширования НМАС
CALGMAC	Message Authentication Code
CALGMD2	Алгоритм хэширования MD2
CALGMD5	Алгоритм хэширования MD5
CALGSHA	US DSA Secure Hash Algorithm
CALGSHA1	Аналогичен CALGSHA
CALGSSL3SHAMD5	SАутентификация клиента в SSL3

Параметры

hHasn

Дескриптор объекта функции хэширования, значение которой будет подписано.

dwKeySpec

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

sDescription

Последовательность, описывающая подписываемые данные. Текст описания добавляется к
объекту hHash перед тем, как будет произведена подпись. Всякий раз, когда подпись проверяется
(CryptVerifySignature), та же самая последовательность описания должна быть определена. Это
гарантирует, что и подписывающая сторона, и проверяющая знают то, что подписывается или
проверяется. Если последовательность описания не включается в подпись, этот параметр может
быть NULL.

dwFlags

Значения флагов. Этот параметр зарезервирован для будущего использования и должен быть нулевым.

pbSignature

Адрес буфера, через который возвращается значение подписи.

Если через этот параметр передается NULL, то подпись не вычисляется. В этом случае требуемый размер буфера (в байтах) возвращается через параметр pdwSigLen.

pdwSigLen

Адрес длины данных подписи. При вызове функции указанный параметр содержит число байтов в буфере pbSignature. После ее исполнении параметр будет установлен числом байтов данных, скопированных в буфер pbSignature.

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

Возвращаемое значение

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

После завершения работы приложения с объектами хэширования все они должны быть уничтожены функцией CryptDestroyHash

BOOL CryptDestroyHash ( HCRYPTHASH hHash //in);

Параметры

hHash

Дескриптор разрушаемого объекта функции хэширования.

Функция CryptVerifySignature осуществляет проверку цифровой подписи, соответствующей объекту функции хэширования.

BOOL CryptVerifySignature (

HCRYPTHASH hHash, //in

CONST BYTE *pbSignature, //in

DWORD dwSigLen, //in

HCRYPTKEY hPubKey, //in

LPCWSTR sDescription, //in

DWORD dwFlags //in );

Параметры

hHash

Дескриптор объекта функции хэширования, подпись которого проверяется.

pbSignature

Буфер, содержащий значение проверяемой подписи.

dwSigLen

Длина (в байтах) значения подписи.

hPubKey

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

sDescription

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

Значение флагов. Этот параметр зарезервирован для будущего использования и должен быть нулевым.

Возвращаемое значение

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

Комментарии: Функция CryptVerifySignature выполняет следующие внутренние шаги.

1. 
   Если параметр описания sDescription поддержан, он добавляется к объекту
   функции хэширования.
   
2. 
   Объект функции хэширования «закрывается», и значение функции хэширования
   извлекается.
   
3. 
   Значение функции хэширования дополняется, как это требуется алгоритмом
   подписи.
   

4. Осуществляется проверка подписи, используя открытый ключ hPubKey.

Если подпись, переданная через буфер pbSignature и вычисленное значение подписи не совпадают, возвращается код ошибки NTE_BAD_SIGNATURE.

После выполнения проверки подписи приложение не может добавлять новые данные к объекту функции хэширования. Приложение должно разрушить объект функции хэширования через вызов функции CryptDestroyHash.

Контрольные вопросы

1. 
   Основные виды атак, создающие сомнение в подлинности присылаемых документов
   
2. 
   Что такое ЭЦП?
   
3. 
   Сфера применения ЭЦП.
   
4. 
   Пример применения ЭЦП.
   
5. 
   Как обеспечивается проверка подлинности сообщения, подписанного ЭЦП?
   
6. 
   Назовите основные этапы создания ЭЦП.
   
7. 
   Назовите основные алгоритмы создания электронной подписи.
   
8. 
   Принципы создания цифровых подписей алгоритмом RSA.
   
9. 
   Принципы создания цифровых подписей алгоритмом DSA.
   
10. 
    Что такое хэш-функция?
    
11. 
    Назовите несколько алгоритмов хэширования и дайте им краткую характеристику.
    12. Назначение CryptoAPI?
    

13. 
    Основные группы функций CryptoAPI и их назначение.
    
14. 
    Назначение функций получения контекста криптопровайдера.
    
15. 
    Назначение функций генерации ключей.
    
16. 
    Какие действия необходимо совершить для получения значения хэш-функции.
    
17. 
    Основные функции CryptoAPI, необходимые для создания ЭЦП.
    
18. 
    Основные функции CryptoAPI для проверки подлинности ЭЦП.
    
19. 
    Назовите порядок вызова функций CryptoAPI, необходимых для создания и
    проверки подлинности ЭЦП.