Разработка системы генерации и проверки подлинности сертификата открытого ключа

Задание

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

1. Генерация пары ключей (открытого и закрытого) администратора для подписывания сертификата

2. Ведение списка пользователей и их сертификатов (создание, удаление, редактирование)

3. Для каждого нового пользователя создание контейнера ключей и генерация пары ключей — открытого и закрытого.

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

5. Проверка подлинности сертификата, присланного для проверки. Проверка актуальности сертификата (т.е. проверка того, что текущая дата меньше конечного срока действия сертификата)

6. Возможность просмотра всех полей сертификата пользователя

7. При окончании срока действия перемещение сертификата в архив сертификатов. Ведение архива сертификатов

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

1. Инфраструктура открытых ключей PKI

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

1.1 Основные компоненты PKI

Основными компонентами PKI являются:

· Удостоверяющий центр

· Регистрационный центр

· Реестр сертификатов

· Архив сертификатов

· Пользователи

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

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

Основные функции УЦ:

· Генерация своего секретного ключа и формирование самоподписанного сертификата

· Выпуск (т.е. создание и подписывание) сертификатов подчиненных и / или связанных УЦ и сертификатов открытых ключей пользователей

· Ведение базы данных изданных сертификатов и реестра аннулированных сертификатов

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

Регистрационный центр (РЦ) является необязательным компонентом PKI. Регистрационный центр выполняет функции:

· регистрации пользователей,

· взаимосвязи пользователей с УЦ

· проверки информации, которая заносится в сертификат.

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

Реестр сертификатов — это база данных, где хранятся действующие сертификаты и списки аннулированных сертификатов. Термин «реестр» введен в практику Законом РФ «Об электронной цифровой подписи». Реестр обеспечивает хранение и распространение сертификатов, управляет внесениями изменений в сертификаты, предоставляет информацию о текущем статусе сертификата.

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

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

1.2 Структура сертификатов открытых ключей по стандарту Х.509

Формат сертификата открытого ключа определен в рекомендациях Х.509 Международного Союза по телекоммуникациям (ITU).

Структура сертификата

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

Поле Версия определяет версию стандарта Х.509, которая определяет состав сертификата. В настоящее время общепринятой является версия 3.

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

Поле Идентификатор алгоритма подписи указывает алгоритм ЭЦП, который использован для защиты сертификата, например DSA с SHA-1 или RSA с MD5.

Поле Расширения содержит информация о правах доступа к той или иной системе.

Пример сертификата:

Серийный номер #12 345 678

Идентификатор алгоритма подписи GOST open key

Имя издателя C=RU, org=ACME

Период действия c 01.01.2000 00:00:00

до 31.12.2003 00:00:00

Имя субъекта C=RU, org=ACME, cn=UserName

Открытый ключ субъекта 100 111 001 001 000 115 118 192 721 920

Подпись УЦ алгоритм: GOST P34.10−94 sign algoritm

Значение: 10 011 110 100 100 100 128 768

1.3 Архитектура PKI

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

Иерархическая архитектура

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

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

Сетевая архитектура

Независимые удостоверяющие центры взаимно сертифицируют друг друга, то есть выпускают сертификаты друг для друга. Взаимно сертифицированные УЦ объединяются в пары взаимной сертификации.

Доверяющая сторона знает открытый ключ ближайшего к ней УЦ, обычно того, кто выпустил для нее сертификат. Доверяющая сторона проверяет сертификат, выстраивая цепочку доверия от известного ей УЦ, которому она доверяет. Например, отправитель сообщения знает открытый ключ подписи УЦ3, а получатель — открытый ключ подписи УЦ4. В сетевой архитектуре всегда существует несколько цепочек сертификатов от получателя к отправителю сообщения. В данном примере самая короткая цепочка такая: получатель сообщения проверяет сертификат отправителя, выпущенный УЦ3, затем сертификат УЦ3, выпущенный УЦ5, и сертификат УЦ5, выпущенный УЦ4. УЦ4 — это удостоверяющий центр, которому получатель доверяет.

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

Гибридная архитектура

Для связывания разнородных инфраструктур открытых ключей недавно была предложена гибридная или мостовая архитектура. При использовании такой архитектуры соединение различных PKI независимо от их архитектуры достигается введением нового УЦ, называемого мостовым. Единственным назначением мостового УЦ является установление связей между различными PKI.

В отличие от сетевого УЦ мостовой центр не выпускает сертификаты непосредственно для пользователей, а в отличие от корневого УЦ в иерархической PKI — не выступает в качестве узла доверия.

Все пользователи PKI рассматривают мостовой УЦ как посредника. Мостовой УЦ устанавливает отношения «равный с равным» между различными корпоративными PKI. Если PKI является иерархической, мостовой УЦ устанавливает связь с корневым УЦ. Если PKI является сетевым, мостовой УЦ устанавливает связь с одним из УЦ сети. В любом случае УЦ, который вступает в отношения с мостовым, называется главным.

Главные УЦ в каждой PKI выпускают сертификат для мостового УЦ, и таким образом между различными PKI образуется взаимная сертификация.

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

1.4 Программные средства поддержки PKI

Entrust/PKI

Компания Entrust Technologies — наиболее известный производитель программных средств поддержки PKI. Основное предложение компании — семейство программных продуктов Entrast/PKI, предназначенное для организации собственных удостоверяющих центров и развертывания PKI. Поддерживаемые платформы — Windows NT, Sun Solaris, HP-UX, AIX.

Entrast/PKI состоит из семи основных компонентов:

1. Entrast/Authority — основной компонент системы, организующий УЦ. Используется для создания сертификатов, генерации ключей и управления ключами и сертификатами.

2. Directory — организует базу данных сертификатов открытых ключей и списков аннулированных сертификатов.

3. Entrast/RA — выполняет функции регистрационного центра

4. Entrast/Auto RA — автоматический регистрационный центр, регистрация и аутентификация пользователей без участия администратора.

5. Entrast/Profile Server — хранение профилей пользователей

6. Entrast/Timestamp — реализует защищенное проставление меток даты-времени

7. Entrast/Intelligence — обеспечивает связь Entrust-совместимых приложений с основными компонентами Entrust

Baltimore UniCert

Продукт компании Baltimore Technologies LTD. Программный комплекс UniCert 5.0 обеспечивает работу корпоративного УЦ, поддерживает аутентификацию, управление ключами, функции неотказуемости в различных приложениях. Программный комплекс разделяется на базовое ПО — UniCert Core, и продвинутое ПО — UniCert Advanced.

RSA Keon

Продукт компании RSA Security Inc. состоит из нескольких программных модулей: Keon Certification Authority 6.5, Registration Authority, WebCentry, Key Recovery Module, Secure E-mail Module. Является самым дешевым вариантов из зарубежных программных продуктов.

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

VCERT PKI

Отечественный программный комплекс управления сертификатами открытых ключей. Все криптографические процедуры реализованы в соответствии с российскими стандартами: ГОСТ 28 147–89, ГОСТ Р34.10−94 и международными рекомендациями. Система реализована для платформы Windows NT, 95/98. Разработчики — МО ПНИЭИ и ООО «Валидата».

КриптоПро

Отечественное семейство программных продуктов. Основной компонент — КриптоПро УЦ, удостоверяющий центр, в свою очередь состоящий из нескольких компонент. Продукт сертифицирован ФАПСИ. Разработчик — компания «Крипто-Про» и государственный НТЦ «Атлас».

2. Описание логики работы программы

3. Описание интерфейса

Подменю Сертификат включает в себя список Проверка и Архив сертификатов.

Подменю Администрирование включает в себя Генерацию ключа и Базу Данных.

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

Рисунок 1. Главная форма Рисунок 2. Форма генерации и экспорта ключа для подписи Рисунок 3. Форма экспорта ключа Форма База Данных Содержит Таблицу для работы с БД. Здесь можно редактировать БД — создавать, редактировать и удалять пользователей. Поле Архив — указание, входит ли сертификат в архив — если да, то его значение 1, если нет-то 0.

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

Рисунок 6. Форма создания нового пользователя Рисунок 7. Форма добавления нового сертификата генерация сертификат ключ подлинность Рисунок 8. Форма просмотра списка сертификатов На Форме проверки сетрификата необходимо проверить подпись сертификата. Потом можно проверить его актуальность. Если срок действия истек, то можно добавить этот сертификат в архив. Также можно просмотреть друние поля сертификата.

Рисунок 9. Форма проверки сетрификата Рисунок 10. — Форма просмотра полей сертификата Рисунок 11. Архив

4. Листинг программы

4.1 Модуль главной формы FormMain

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Menus, Wcrypt2, StdCtrls, unit2, sertif, Users, KeysForm, Verific, NewUser, DatM, Expo, Proc, Unit6, DatBase;

type

TMainF = class (TForm)

MainMenu1: TMainMenu;

Certificate: TMenuItem;

Verify: TMenuItem;

Archive: TMenuItem;

Admin: TMenuItem;

GenKey: TMenuItem;

Exit: TMenuItem;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

procedure Button1Click (Sender: TObject);

procedure GenKeyClick (Sender: TObject);

procedure VerifyClick (Sender: TObject);

procedure ExitClick (Sender: TObject);

procedure N3Click (Sender: TObject);

procedure N2Click (Sender: TObject);

procedure N4Click (Sender: TObject);

procedure FormClose (Sender: TObject; var Action: TCloseAction);

procedure ArchiveClick (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

MainF: TMainF;

implementation

{$R *.dfm}

procedure TMainF. Button1Click (Sender: TObject);

var s, s1, s2: string;

f1, f2: Boolean;

begin

end;

procedure TMainF. GenKeyClick (Sender: TObject);

begin

Keys. Button3. Enabled:= false;

Keys. Show;

end;

procedure TMainF. VerifyClick (Sender: TObject);

begin

Form3. Show;

end;

procedure TMainF. ExitClick (Sender: TObject);

begin

MainF. Close;

end;

procedure TMainF. N3Click (Sender: TObject);

begin

UsersForm.pFIBDataSet1. Active:= true;

UsersForm. Show;

end;

procedure TMainF. N2Click (Sender: TObject);

begin

DatM. SerN:= GetserNom;

DatM. IdAlgS:= 'GOST open key';

DatM. Izd:= 'GOST';

DatM. Org:= 'Org';

DatM. User:= 'User';

DatM. OpKU:= «;

DatM. SignAlg:= 'sign algoritm';

NewU. Edit2. Text:= DatM. User;

NewU. SpeedButton2. Enabled:= false;

NewU. SpeedButton3. Enabled:= false;

NewU. Show;

end;

procedure TMainF. N4Click (Sender: TObject);

begin

BD. Show;

end;

procedure TMainF. FormClose (Sender: TObject; var Action: TCloseAction);

begin

DM.pFIBDatabase1. Connected:= false;

end;

procedure TMainF. ArchiveClick (Sender: TObject);

begin

Ar.pFIBDataSet1. Active:= true;

Ar. Show;

end;

end.

4.2 Модуль формы KeysForm

unit KeysForm;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, Menus, Proc, Wcrypt2, ComCtrls, Expo;

type

TKeys = class (TForm)

Button1: TButton;

ConComboBox: TComboBox;

Button2: TButton;

Label1: TLabel;

ReportMemo: TMemo;

Label3: TLabel;

Label4: TLabel;

KeyLEdit2: TEdit;

UpDown2: TUpDown;

CheckBox2: TCheckBox;

Button3: TButton;

procedure Button1Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

Keys: TKeys;

implementation

uses Math;

{$R *.dfm}

procedure createCont (nameCon: String);

var cont: PChar;

name, con: string;

hContext: PHCRYPTPROV;

begin

// Выполняем создание контейнера или подключение к нему

// Имя контейнера берем из объекта EdtCont

// имя контейнера con

//if length (edtCont. Text) = 0 then

con:=nameCon;

name:= Con;

cont:= StrAlloc (length (name) + 1);

StrPCopy (cont, name);

// пытаемся подключиться к контейнеру

if not CryptAcquireContext (@hContext, cont, nil, PROV_RSA_FULL, 0) then

begin // если не удалось подключиться

// создаем новый контейнер с введенным именем

if not CryptAcquireContext (@hContext, cont, nil, PROV_RSA_FULL,

CRYPT_NEWKEYSET) then

begin

//error:= GetLastError;

MessageDlg (' Ошибка создания контейнера:', mtInformation, [mbOK], 0);

Exit;

end

else MessageDlg (' Создан контейнер с именем ' + name,

mtInformation, [mbOK], 0);

end

else MessageDlg ('Подключились к контейнеру '+name, mtInformation, [mbOK], 0);

end;

procedure GenKey (s:string); // (Sender: TObject);

var

cont: PChar;

err, KeyL1, KeyLS: string;

hProv: HCRYPTPROV;

KeyExchKey, SignKey: HCRYPTKEY;

flag, keyLen: DWORD;

begin

Keys. ReportMemo. Clear;

{"считываем" имя контейнера}

if length (s) = 0 then

cont:= nil

else

begin

err:= s;

cont:= StrAlloc (length (err) + 1);

StrPCopy (cont, err);

end;

KeyLS:= IntToStr (Keys. UpDown2. Position);

CryptAcquireContext (@hProv, cont, nil, PROV_RSA_FULL, 0);

keyLen:= strtoint (KeyLS);

if Keys. CheckBox2. Checked then

begin

flag:= keyLen shl 16;

if not CryptGenKey (hProv, AT_SIGNATURE, flag, @SignKey) then

begin

case int64 (GetLastError) of

ERROR_INVALID_HANDLE: err:= 'ERROR_INVALID_HANDLE';

ERROR_INVALID_PARAMETER: err:= 'ERROR_INVALID_PARAMETER';

NTE_BAD_FLAGS: err:= 'NTE_BAD_FLAGS';

NTE_BAD_ALGID: err:= 'NTE_BAD_ALGID';

NTE_BAD_UID: err:= 'NTE_BAD_UID';

NTE_FAIL: err:= 'NTE_FAIL';

else err:= 'Unknown error';

end;

MessageDlg ('Ошибка создания ключа подписи: ' + err, mtError, [mbOK], 0);

end

else

begin

Keys. ReportMemo. Lines. Add ('');

Keys. ReportMemo. Lines. Add ('Создан ключ подписи:');

flag:= 4;

if not CryptGetKeyParam (SignKey, KP_KEYLEN, @keyLen, @flag, 0) then

begin

GetLastError;

MessageDlg ('Ошибка получения длины ключа: ' + err,

mtError, [mbOK], 0);

end

else Keys. ReportMemo. Lines. Add (' длина ключа — ' + inttostr (keyLen));

flag:= 4;

if not CryptGetKeyParam (SignKey, KP_ALGID, @keyLen, @flag, 0) then

begin

GetLastError;

MessageDlg ('Ошибка получения длины ключа: ' + err, mtError, [mbOK], 0);

end

else Keys. ReportMemo. Lines. Add (' алгоритм — ' + inttostr (keyLen));

end;

end;

CryptReleaseContext (hProv, 0);

end;

procedure TKeys. Button1Click (Sender: TObject);

var

s: string;

begin

if Keys. ConComboBox. Text<>'' then

begin

s:=ConComboBox. Text;

createCont (s);

ConComboBox. Items. Add (s);

Keys. Button2. Enabled:= true;

end

else

MessageDlg (' Введите имя контейнера', mtInformation, [mbOK], 0);

end;

procedure TKeys. FormActivate (Sender: TObject);

begin

Keys. ReportMemo. Clear;

Keys. Button2. Enabled:= false;

end;

procedure TKeys. Button2Click (Sender: TObject);

var

s, l: String;

begin

s:= ConComboBox. Text;

l:= IntToStr (UpDown2. Position);

if Length (s)=0 then

begin

MessageDlg (' Введите имя контейнера', mtInformation, [mbOK], 0);

Exit;

end

else begin

GenKey (s);

Button3. Enabled:= true;

end;

end;

procedure TKeys. Button3Click (Sender: TObject);

begin

Exp. ComboBox1. Text:= Keys. ConComboBox. Text;

Exp. Show;

end;

end.

4.3 Модуль формы NewUser

unit NewUser;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ComCtrls, StdCtrls, Buttons, Expo, Sertif, Proc, ExtCtrls, Wcrypt2, DatM, expOp, Users, AddUsers;

type

TNewU = class (TForm)

Edit1: TEdit;

Button1: TButton;

UKeyL: TEdit;

UpDown1: TUpDown;

Button2: TButton;

Edit2: TEdit;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Button3: TButton;

SpeedButton1: TSpeedButton;

Panel1: TPanel;

Label6: TLabel;

Label5: TLabel;

Label7: TLabel;

PerS: TDateTimePicker;

PerEnd: TDateTimePicker;

Memo1: TMemo;

SaveDialog1: TSaveDialog;

OpenDialog1: TOpenDialog;

SpeedButton2: TSpeedButton;

SpeedButton3: TSpeedButton;

Edit4: TEdit;

AdmKey: TEdit;

Label4: TLabel;

procedure SpeedButton1Click (Sender: TObject);

procedure FormActivate (Sender: TObject);

procedure Button1Click (Sender: TObject);

procedure Button2Click (Sender: TObject);

procedure Button3Click (Sender: TObject);

procedure SpeedButton2Click (Sender: TObject);

procedure SpeedButton3Click (Sender: TObject);

private

{Private declarations}

public

{Public declarations}

end;

var

NewU: TNewU;

implementation

{$R *.dfm}

procedure TNewU. SpeedButton1Click (Sender: TObject);

begin

Certifikat. SerNom. Text:= DatM. SerN;

DatM.p1:= DateToStr (PerS. DateTime);

DatM.p2:= DateToStr (PerEnd. DateTime);

Certifikat. Show;

end;

procedure TNewU. FormActivate (Sender: TObject);

begin

Randomize;

Button3. Enabled:= DatM. flag;

end;

procedure TNewU. Button1Click (Sender: TObject);

begin

createCont (Edit1. Text);

end;

procedure TNewU. Button2Click (Sender: TObject);

var

l: string;

begin

l:= IntToStr (UpDown1. Position);

if Length (Edit1. Text)=0 then

begin

MessageDlg (' Введите имя контейнера', mtInformation, [mbOK], 0);

Exit;

end

else begin

GenKeyOp (Edit1. Text, l);

SpeedButton2. Enabled:= true;

end;

end;

procedure TNewU. Button3Click (Sender: TObject);

var

FName, S, path: String;

cont: PChar;

Name: string;

hProv: HCRYPTPROV;

alg: ALG_ID;

hash: HCRYPTHASH;

f2, f1: file;

size: DWORD;

buf: array [0.511] of byte;

signature: PBYTE;

str:string;

posn:integer;

key: HCRYPTKEY;

test, textsize: DWORD;

buf2: PBYTE;

signkey: PBYTE;

format:array [0.9] of char;

i:integer;

ft: TextFile;

begin

Memo1. Lines. Add ('Серийный номер ' + DatM. SerN);

Memo1. Lines. Add ('Идентификатор алгоритма подписи '+ DatM. IdAlgS);

Memo1. Lines. Add ('Имя издателя '+DatM. Izd);

Memo1. Lines. Add ('Период действия');

Memo1. Lines. Add ('c '+DateToStr (PerS. DateTime)+ ' 00:00:00');

Memo1. Lines. Add ('до '+DateToStr (PerEnd. DateTime)+ ' 00:00:00');

Memo1. Lines. Add ('Имя субъекта '+ DatM. Org+' '+ DatM. User);

Memo1. Lines. Add ('Открытый ключ субъекта '+ DatM. OpKU);

Memo1. Lines. Add ('Подпись УЦ алгоритм: '+ DatM. SignAlg);

path:= ExtractFilePath (Application. ExeName)+'temp.txt';

AssignFile (ft, path);

Rewrite (ft);

for i:= 0 to 6 do

begin

s:= Memo1. Lines[i];

Writeln (ft, s);

end;

s:= 'Открытый ключ субъекта '+ DatM. OpKU;

Writeln (ft, s);

s:= 'Подпись УЦ алгоритм: '+ DatM. SignAlg;

Writeln (ft, s);

CloseFile (ft);

if AdmKey. Text='' then

begin

MessageDlg ('Не выбран ключ подписи!!!', mtWarning, [mbOK], 0);

exit;

end

else begin

alg:= CALG_SHA;

Name:= AdmKey. Text;

cont:= StrAlloc (length (name) + 1);

StrPCopy (cont, name);

if not CryptAcquireContext (@hProv, cont, nil, PROV_RSA_FULL, 0) then

begin

MessageDlg ('Ошибка открытия контейнера!!!', mtError, [mbOK], 0);

exit;

end;

if not CryptCreateHash (hProv, alg, 0, 0, @hash) then

begin

MessageDlg ('Ошибка создания хеш-объекта!!!', mtError, [mbOK], 0);

exit;

end;

if SaveDialog1. Execute then begin

str:=SaveDialog1. FileName;

Edit4. Text:= str;

posn:=pos ('.cer', str);

if posn <> 0 then delete (str, posn, 4);

SaveDialog1. FileName:=str;

AssignFile (f1, SaveDialog1. FileName+'.cer');

rewrite (f1, 1);

str:= ExtractFileName (path);

posn:=pos ('.', str);

if posn <> 0 then delete (str, 1, posn-1)

else str:='';

for i:=0 to length (str) — 1 do

format[i]: =str [i+1];

for i:=length (str) to 9 do

format[i]: =#0;

BlockWrite (F1, format, 10);

BlockWrite (f1, alg, 4);

AssignFile (f2, path);

reset (f2, 1);

size:= FileSize (f2);

BlockWrite (f1, size, 4);

while not eof (f2) do

begin

BlockRead (f2, buf{^}, 512, size);

BlockWrite (f1, buf, size);

if not CryptHashData (hash, @buf, size, 0) then

begin

MessageDlg ('Ошибка при хешировании!!!', mtError, [mbOK], 0);

exit;

end;

end;

CloseFile (f2);

if not CryptSignHash (hash, AT_SIGNATURE, nil, 0, nil, @size) then

begin

MessageDlg ('Ошибка при определении размера подписи!!!', mtError, [mbOK], 0);

CloseFile (f1);

exit;

end;

GetMem (signature, size);

if not CryptSignHash (hash, AT_SIGNATURE, nil, 0, signature, @size) then

begin

MessageDlg ('Ошибка при подписании хеша!!!', mtError, [mbOK], 0);

CloseFile (f1);

exit;

end;

BlockWrite (f1, size, 4);

BlockWrite (f1, signature^, size);

CloseFile (f1);

if not CryptDestroyHash (hash) then

begin

MessageDlg ('Ошибка при уничтожения хеша!!!', mtError, [mbOK], 0);

end;

if not CryptReleaseContext (hProv, 0) then

begin

MessageDlg ('Не удалось освободить контекст!!!', mtError, [mbOK], 0);

end;

MessageDlg ('Файл подписан успешно!!!', mtInformation, [mbOK], 0);

end;

// уничтожаем хеш-объект и освобождаем контекст

CryptDestroyHash (hash);

CryptReleaseContext (hProv, 0);

// теперь можно внести данные в БД

SpeedButton3. Enabled:= true;

end;

end;

procedure TNewU. SpeedButton2Click (Sender: TObject);

begin

Form4. ComboBox1. Text:= Edit1. Text;

Form4. Show;

end;

procedure TNewU. SpeedButton3Click (Sender: TObject);

begin

DatM. Path:= ExtractFileName (Edit4. Text);

AdUser. Edit2. Text:= DatM. SerN;

AdUser. Edit1. Text:= DatM. Org;

AdUser. Edit3. Text:= DatM. Path;

AdUser.pFIBDataSet1. Active:= true;

AdUser. Show;

end;

end.

Библиографический список

1. Столингс, В. Криптография и защита сетей [Текст] /Вильям Столлингс. — М.: Издательский дом «Вильямс», 2001. — 685 с.

2. Калинина Н. А. Методы и средства защиты информации: Методические указания по выполнению курсовой работы для студентов специальностей 220 400 «Программное обеспечение вычислительной техники и автоматизированных систем» очной, очной ускоренной и заочной форм обучения, 552 800 «Информатика и вычислительная техника» очной формы обучения / Составитель Н. А. Калинина. — Красноярск: СибГТУ, 2008. — 18 с.

3. Калинина Н. А. Методы и средства защиты информации: учебное пособие для студентов специальности 230 105 «Программное обеспечение вычислительной техники и автоматизированных систем» очной, очной ускоренной и заочной форм обучения / Н. А. Калинина. — Красноярск: СибГТУ, 2009. — 196 с.

4. СТП 3.4.204−01. Стандарт предприятия. Требования к оформлению текстовых документов. — Красноярск: СибГТУ, 2001. — 46 с.

5. FIBPlus 6.9.6 Руководство разработчика.