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

Задание

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

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

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

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

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

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

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

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

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

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.

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

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

Серийный номер #12345678

Идентификатор алгоритма подписи 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

Открытый ключ субъекта 0100111001001000110000000110001

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

Значение: 010011110100100101000001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/PKI

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

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

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

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

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

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

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

.        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

Отечественный программный комплекс управления сертификатами открытых ключей. Все криптографические процедуры реализованы в соответствии с российскими стандартами: ГОСТ 28147-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, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Menus, Wcrypt2, StdCtrls, unit2, sertif, Users, KeysForm, Verific, NewUser, DatM, Expo, Proc, Unit6, DatBase;= class(TForm): TMainMenu;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;Button1Click (Sender: TObject);GenKeyClick (Sender: TObject);VerifyClick (Sender: TObject);ExitClick (Sender: TObject);N3Click (Sender: TObject);N2Click (Sender: TObject);N4Click (Sender: TObject);FormClose (Sender: TObject; var Action: TCloseAction);ArchiveClick (Sender: TObject);

{Private declarations}

{Public declarations};: TMainF;

{$R *.dfm}TMainF. Button1Click (Sender: TObject);s, s1, s2: string;, f2: Boolean;;TMainF. GenKeyClick (Sender: TObject);. Button3. Enabled:= false;. Show;;TMainF. VerifyClick (Sender: TObject);. Show;;TMainF. ExitClick (Sender: TObject);. Close;;TMainF.N3Click (Sender: TObject);.pFIBDataSet1. Active:= true;. Show;;TMainF.N2Click (Sender: TObject);. SerN:= GetserNom;. IdAlgS:= 'GOST open key';. Izd:= 'GOST';. Org:= 'Org';. User:= 'User';. OpKU:= «;. SignAlg:= 'sign algoritm';. Edit2. Text:= DatM. User;. SpeedButton2. Enabled:= false;. SpeedButton3. Enabled:= false;. Show;;TMainF.N4Click (Sender: TObject);. Show;;TMainF. FormClose (Sender: TObject; var Action: TCloseAction);.pFIBDatabase1. Connected:= false;;TMainF. ArchiveClick (Sender: TObject);.pFIBDataSet1. Active:= true;. Show;;.

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

KeysForm;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, Menus, Proc, Wcrypt2, ComCtrls, Expo;= class(TForm): TButton;: TComboBox;: TButton;: TLabel;: TMemo;: TLabel;: TLabel;: TEdit;: TUpDown;: TCheckBox;: TButton;Button1Click (Sender: TObject);FormActivate (Sender: TObject);Button2Click (Sender: TObject);Button3Click (Sender: TObject);

{Private declarations}

{Public declarations};: TKeys;Math;

{$R *.dfm}createCont (nameCon: String);cont: PChar;, con: string;: PHCRYPTPROV;

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

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

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

//if length (edtCont. Text) = 0 then:=nameCon;:= Con;:= StrAlloc (length(name) + 1);(cont, name);

// пытаемся подключиться к контейнеруnot CryptAcquireContext (@hContext, cont, nil, PROV_RSA_FULL, 0) then // если не удалось подключиться

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

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

//error:= GetLastError;(' Ошибка создания контейнера:', mtInformation, [mbOK], 0);;MessageDlg (' Создан контейнер с именем ' + name,, [mbOK], 0);MessageDlg ('Подключились к контейнеру '+name, mtInformation, [mbOK], 0);;GenKey (s:string); // (Sender: TObject);: PChar;, KeyL1, KeyLS: string;: HCRYPTPROV;, SignKey: HCRYPTKEY;, keyLen: DWORD;. ReportMemo. Clear;

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

if length(s) = 0 then:= nil:= s;:= StrAlloc (length(err) + 1);(cont, err);;:= IntToStr (Keys. UpDown2. Position);(@hProv, cont, nil, PROV_RSA_FULL, 0);:= strtoint(KeyLS);Keys. CheckBox2. Checked then:= keyLen shl 16;not CryptGenKey (hProv, AT_SIGNATURE, flag, @SignKey) thenint64 (GetLastError) of_INVALID_HANDLE: err:= 'ERROR_INVALID_HANDLE';_INVALID_PARAMETER: err:= 'ERROR_INVALID_PARAMETER';_BAD_FLAGS: err:= 'NTE_BAD_FLAGS';_BAD_ALGID: err:= 'NTE_BAD_ALGID';_BAD_UID: err:= 'NTE_BAD_UID';_FAIL: err:= 'NTE_FAIL';err:= 'Unknown error';;('Ошибка создания ключа подписи: ' + err, mtError, [mbOK], 0);. ReportMemo. Lines. Add('');. ReportMemo. Lines. Add ('Создан ключ подписи:');

flag:= 4;not CryptGetKeyParam (SignKey, KP_KEYLEN, @keyLen, @flag, 0) then;('Ошибка получения длины ключа: ' + err,, [mbOK], 0);Keys. ReportMemo. Lines. Add (' длина ключа - ' + inttostr(keyLen));:= 4;not CryptGetKeyParam (SignKey, KP_ALGID, @keyLen, @flag, 0) then;('Ошибка получения длины ключа: ' + err, mtError, [mbOK], 0);Keys. ReportMemo. Lines. Add (' алгоритм - ' + inttostr(keyLen));;;(hProv, 0);;TKeys. Button1Click (Sender: TObject);: string;Keys. ConComboBox. Text<>'' then:=ConComboBox. Text;(s);. Items. Add(s);. Button2. Enabled:= true;(' Введите имя контейнера', mtInformation, [mbOK], 0);;TKeys. FormActivate (Sender: TObject);. ReportMemo. Clear;. Button2. Enabled:= false;;TKeys. Button2Click (Sender: TObject);, l: String;:= ConComboBox. Text;:= IntToStr (UpDown2. Position);Length(s)=0 then(' Введите имя контейнера', mtInformation, [mbOK], 0);;begin(s);. Enabled:= true;;;TKeys. Button3Click (Sender: TObject);. ComboBox1. Text:= Keys. ConComboBox. Text;. Show;;.

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

NewUser;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ComCtrls, StdCtrls, Buttons, Expo, Sertif, Proc, ExtCtrls, Wcrypt2, DatM, expOp, Users, AddUsers;= class(TForm): TEdit;: TButton;: TEdit;: TUpDown;: TButton;: TEdit;: TLabel;: TLabel;: TLabel;: TButton;: TSpeedButton;: TPanel;: TLabel;: TLabel;: TLabel;: TDateTimePicker;: TDateTimePicker;: TMemo;: TSaveDialog;: TOpenDialog;: TSpeedButton;: TSpeedButton;: TEdit;: TEdit;: TLabel;SpeedButton1Click (Sender: TObject);FormActivate (Sender: TObject);Button1Click (Sender: TObject);Button2Click (Sender: TObject);Button3Click (Sender: TObject);SpeedButton2Click (Sender: TObject);SpeedButton3Click (Sender: TObject);

{Private declarations}

{Public declarations};: TNewU;

{$R *.dfm}TNewU. SpeedButton1Click (Sender: TObject);. SerNom. Text:= DatM. SerN;.p1:= DateToStr (PerS. DateTime);.p2:= DateToStr (PerEnd. DateTime);. Show;;TNewU. FormActivate (Sender: TObject);;. Enabled:= DatM.flag;;TNewU. Button1Click (Sender: TObject);(Edit1. Text);;TNewU. Button2Click (Sender: TObject);: string;:= IntToStr (UpDown1. Position);Length (Edit1. Text)=0 then(' Введите имя контейнера', mtInformation, [mbOK], 0);;begin(Edit1. Text, l);. Enabled:= true;;;TNewU. Button3Click (Sender: TObject);, S, path: String;: PChar;: string;: HCRYPTPROV;: ALG_ID;: HCRYPTHASH;, f1: file;: DWORD;: array [0..511] of byte;: PBYTE;:string;:integer;: HCRYPTKEY;, textsize: DWORD;: PBYTE;: PBYTE;:array [0..9] of char;:integer;: TextFile;. Lines. Add ('Серийный номер ' + DatM. SerN);1. Lines. Add ('Идентификатор алгоритма подписи '+ DatM. IdAlgS);. Lines. Add ('Имя издателя '+DatM. Izd);. Lines. Add ('Период действия');. Lines. Add ('c '+DateToStr (PerS. DateTime)+ ' 00:00:00');. Lines. Add ('до '+DateToStr (PerEnd. DateTime)+ ' 00:00:00');. Lines. Add ('Имя субъекта '+ DatM. Org+' '+ DatM. User);. Lines. Add ('Открытый ключ субъекта '+ DatM. OpKU);. Lines. Add ('Подпись УЦ алгоритм: '+ DatM. SignAlg);:= ExtractFilePath (Application. ExeName)+'temp.txt';(ft, path);(ft);i:= 0 to 6 do:= Memo1. Lines[i];(ft, s);;

s:= 'Открытый ключ субъекта '+ DatM. OpKU;(ft, s);:= 'Подпись УЦ алгоритм: '+ DatM. SignAlg;(ft, s);(ft);AdmKey. Text='' then('Не выбран ключ подписи!!!', mtWarning, [mbOK], 0);;begin:= CALG_SHA;:= AdmKey. Text;:= StrAlloc (length(name) + 1);(cont, name);not CryptAcquireContext (@hProv, cont, nil, PROV_RSA_FULL, 0) then('Ошибка открытия контейнера!!!', mtError, [mbOK], 0);;;not CryptCreateHash (hProv, alg, 0, 0, @hash) then('Ошибка создания хеш-объекта!!!', mtError, [mbOK], 0);;;SaveDialog1. Execute then begin:=SaveDialog1. FileName;. Text:= str;:=pos ('.cer', str);posn <> 0 then delete (str, posn, 4);. FileName:=str;(f1, SaveDialog1. FileName+'.cer');(f1, 1);:= ExtractFileName(path);:=pos ('.', str);posn <> 0 then delete (str, 1, posn-1)str:='';i:=0 to length(str) - 1 do[i]:=str [i+1];i:=length(str) to 9 do[i]:=#0;(F1, format, 10);(f1, alg, 4);(f2, path);(f2, 1);:= FileSize(f2);(f1, size, 4);not eof(f2) do(f2, buf{^}, 512, size);(f1, buf, size);not CryptHashData (hash, @buf, size, 0) then('Ошибка при хешировании!!!', mtError, [mbOK], 0);;;;(f2);not CryptSignHash (hash, AT_SIGNATURE, nil, 0, nil, @size) then

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

CloseFile(f1);;;(signature, size);not CryptSignHash (hash, AT_SIGNATURE, nil, 0, signature, @size) then('Ошибка при подписании хеша!!!', mtError, [mbOK], 0);(f1);;;(f1, size, 4);(f1, signature^, size);(f1);not CryptDestroyHash(hash) then('Ошибка при уничтожения хеша!!!', mtError, [mbOK], 0);;not CryptReleaseContext (hProv, 0) then

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

end;

 // уничтожаем хеш-объект и освобождаем контекст(hash);(hProv, 0);

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

SpeedButton3. Enabled:= true;;;TNewU. SpeedButton2Click (Sender: TObject);. ComboBox1. Text:= Edit1. Text;. Show;;TNewU. SpeedButton3Click (Sender: TObject);. Path:= ExtractFileName (Edit4. Text);. Edit2. Text:= DatM. SerN;. Edit1. Text:= DatM. Org;. Edit3. Text:= DatM. Path;.pFIBDataSet1. Active:= true;. Show;;.

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

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

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

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

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

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