Разработка системы генерации и проверки подлинности сертификата открытого ключа
Инфраструктура открытых ключей PKI. Преимущество сетевой архитектуры. Программные средства поддержки PKI. Описание логики работы программы. Форма генерации и экспорта ключа для подписи, создания нового пользователя, добавления нового сертификата.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 22.07.2012 |
| Размер файла | 450,8 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Задание
Необходимо разработать систему генерации и проверки сертификата открытого ключа с использованием функций 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.
Поле Расширения содержит информация о правах доступа к той или иной системе.
Пример сертификата:
Серийный номер #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 традиционно использовали два типа архитектур: иерархическую и сетевую. В последнее время в связи с необходимостью объединения разнородных структур получила распространение гибридная архитектура.
Иерархическая архитектура
Удостоверяющие центры (УЦ) организуются иерархически под управлением корневого удостоверяющего центра, который выпускает самоподписанный сертификат и сертификаты для подчиненных удостоверяющих центров. Каждый удостоверяющий центр может подписывать сертификаты УЦ, находящихся ниже его по иерархии. В иерархической 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
Отечественный программный комплекс управления сертификатами открытых ключей. Все криптографические процедуры реализованы в соответствии с российскими стандартами: ГОСТ 28147-89, ГОСТ Р34.10-94 и международными рекомендациями. Система реализована для платформы Windows NT, 95/98. Разработчики - МО ПНИЭИ и ООО «Валидата».
КриптоПро
Отечественное семейство программных продуктов. Основной компонент - КриптоПро УЦ, удостоверяющий центр, в свою очередь состоящий из нескольких компонент. Продукт сертифицирован ФАПСИ. Разработчик - компания «Крипто-Про» и государственный НТЦ «Атлас».
2. Описание логики работы программы
Размещено на http://www.allbest.ru/
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. Калинина Н.А. Методы и средства защиты информации: Методические указания по выполнению курсовой работы для студентов специальностей 220400 «Программное обеспечение вычислительной техники и автоматизированных систем» очной, очной ускоренной и заочной форм обучения, 552800 «Информатика и вычислительная техника» очной формы обучения / Составитель Н.А. Калинина. - Красноярск: СибГТУ, 2008. - 18 с.
3. Калинина Н.А. Методы и средства защиты информации: учебное пособие для студентов специальности 230105 «Программное обеспечение вычислительной техники и автоматизированных систем» очной, очной ускоренной и заочной форм обучения / Н.А. Калинина. - Красноярск: СибГТУ, 2009. - 196 с.
4. СТП 3.4.204-01. Стандарт предприятия. Требования к оформлению текстовых документов. - Красноярск: СибГТУ, 2001. - 46 с.
5. FIBPlus 6.9.6 Руководство разработчика.
Размещено на Allbest.ru
Подобные документы
Анализ характеристик средств криптографической защиты информации для создания электронной цифровой подписи. Этапы генерации ключевого контейнера и запроса при помощи Удостоверяющего центра с целью получения сертификата проверки подлинности клиента.
реферат [604,6 K], добавлен 14.02.2016Закон "Об электронной подписи". Определение, технологии применения и принципы формирования электронной подписи. Стандартные криптографические алгоритмы. Понятие сертификата ключа подписи и проверка его подлинности. Системы электронного документооборота.
презентация [219,0 K], добавлен 19.01.2014История электронной подписи в мире. Создание электронной цифровой подписи в электронном документе с использованием закрытого ключа. Модели атак и их возможные результаты. Алгоритм генерации ключевых пар пользователя. Новые направления в криптографии.
курсовая работа [106,1 K], добавлен 07.06.2014Основные алгоритмы реализации электронной цифровой подписи. Понятие секретного и открытого ключа. Программные модули, сроки действия и порядок функционирования электронной подписи. Технология работы с информационной системой "ЭЦП", перспективы развития.
курсовая работа [1,1 M], добавлен 07.12.2010Назначение электронной цифровой подписи. Использование хеш-функций. Симметричная и асимметричная схема. Виды асимметричных алгоритмов электронной подписи. Создание закрытого ключа и получение сертификата. Особенности электронного документооборота.
реферат [43,2 K], добавлен 20.12.2011Блок-схема работы программы генерации ключевой информации, внешний вид ее основного окна. Построение гистограмм распределения элементов и проверки серий. Тестирование программы на работоспособность и возможность получения криптографически стойких ключей.
презентация [561,0 K], добавлен 16.10.2013Обзор области генерации сетевого трафика. Описание выбранных методов, моделей, алгоритмов решения задач. Создание модели поведения пользователя, распределение количества посещённых страниц сайта. Выбор средств реализации программного продукта (проекта).
курсовая работа [1,3 M], добавлен 30.06.2017Обмен информации, защищенной от фальсификаций и незаконных пользователей. Распределение секретных ключей с помощью системы с открытым ключом. Разработка модулей системы генерации ключей и обмена конфиденциальной информацией для группы пользователей.
курсовая работа [2,0 M], добавлен 17.11.2011Разработка криптографического алгоритма программы ручного шифра по таблице Виженера. Разработка программы, выполняющей шифрование и расшифрование. Особенности использования в качестве ключа самого открытого текста. Алгоритмы решения "обратных" задач.
курсовая работа [45,0 K], добавлен 13.11.2009Понятие фрактала, принципы создания изображения. Разработка алгоритма и режимов генерации ландшафта. Описание программы FracLandscapes.exe. в среде разработки Delphi 10. Примеры построения ландшафта с использованием различных режимов и количества изгибов.
курсовая работа [688,9 K], добавлен 04.05.2014
