Мегаобучалка Главная | О нас | Обратная связь


Анализ подсистемы проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф»



2020-03-17 155 Обсуждений (0)
Анализ подсистемы проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф» 0.00 из 5.00 0 оценок




 

Важными инструментами безопасности являются процедуры, позволяющие убедиться в целости и аутентичности данных. Проанализируем подсистему проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф».

Способ, позволяющий шифровать сообщения, обмениваясь ключами по открытым каналам связи, был придуман в середине 70-х годов прошлого столетия, а в начале восьмидесятых появился первый реализующий его алгоритм - rsa. Теперь пользователь может сгенерировать два связанных между собой ключа - ключевую пару [8]. Один из этих ключей по несекретным каналам рассылается всем, с кем пользователь хотел бы обмениваться конфиденциальными сообщениями. Этот ключ называют открытым (англ. public key). Зная открытый ключ пользователя, можно зашифровать адресованное ему сообщение, но расшифровать его позволяет лишь вторая часть ключевой пары - закрытый ключ (private key). При этом открытый ключ не дает возможности вычислить закрытый: такая задача, хоть и разрешима в принципе, но при достаточно большом размере ключа требует многих лет машинного времени. Для сохранения конфиденциальности получателю необходимо лишь хранить в строгом секрете свой закрытый ключ, а отправителю - убедиться, что имеющийся у него открытый ключ действительно принадлежит адресату [9].

Так как для шифрования и расшифровки используются различные ключи, алгоритмы такого рода назвали асимметричными. Наиболее существенным их недостатком является низкая производительность - они примерно в 100 раз медленнее симметричных алгоритмов [10]. Поэтому были созданы криптографические схемы, использующие преимущества как симметричных, так и асимметричных алгоритмов:

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

-  небольшой по размерам симметричный ключ шифрования шифруется при помощи асимметричного алгоритма с использованием открытого ключа адресата и в зашифрованном виде пересылается вместе с сообщением;

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

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

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

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

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

Каждый криптопровайдер располагает базой данных, в которой хранятся долговременные ключи пользователей. База данных содержит один или более контейнеров ключей [12]. Пользователь может создать несколько контейнеров с различными именами (именем контейнера по умолчанию является имя пользователя в системе).

Подключение к контейнеру производится одновременно с получением контекста криптопровайдера при вызове функции cryptacquirecontext - имя контейнера ключей передается функции вторым ее аргументом. Если второй аргумент содержит пустой указатель (nil), то используется имя по умолчанию, то есть имя пользователя. В том случае, если доступ к контейнеру не нужен, можно передать в последнем аргументе функции флаг crypt_verifycontext; при необходимости создать новый контейнер используется флаг crypt_newkeyset; а для удаления существующего контейнера вместе с хранящимися в нем ключами - crypt_deletekeyset.

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

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

- провайдер - дескриптор криптопровайдера, полученный в результате обращения к функции cryptacquirecontext;

-  алгоритм - указывает, какому алгоритму шифрования будет соответствовать создаваемый ключ. Информация об алгоритме, таким образом, является частью описания ключа. Каждый криптопровайдер использует для обмена ключами и подписи строго определенные алгоритмы. Так, провайдеры типа prov_rsa_full, к которым относится и microsoft base cryptographic provider, реализуют алгоритм rsa;

-  флаги - при создании асимметричных ключей управляет их размером. Используемый нами криптопровайдер позволяет генерировать ключ обмена ключами длиной от 384 до 512 бит, а ключ подписи - от 512 до 16384 бит. Чем больше длина ключа, тем выше его надежность, поэтому не рекомендуется для использования ключ обмена ключами длиной менее 512 бит, а длину ключа подписи не рекомендуется делать меньше 1024 бит. По умолчанию криптопровайдер создает оба ключа длиной 512 бит [14]. Необходимую длину ключа можно передать в старшем слове параметра флаги:

-  ключ - в случае успешного завершения функции в этот параметр заносится дескриптор созданного ключа.

В поле "Контейнер" можно указать имя контейнера ключей; если оставить это поле пустым, будет использован контейнер по умолчанию. После генерации ключа в memo-поле выводится отчет о его параметрах. Для этого используется функция cryptgetkeyparam (ключ, параметр, буфер, размер, флаги). Чтобы получить информацию о требуемом параметре, нужно через второй аргумент функции передать соответствующую константу: kp_algid - идентификатор алгоритма, kp_keylen - размер ключа, и т. д.

 

procedure tgenerateform.okbtnclick(sender: tobject); cont: pchar; : string; : hcryptprov; , signkey: hcryptkey;

flag, keylen: dword;

{если ни один ключ не выбран - выход}

if not (kekcheckbox.checked or skcheckbox.checked) then exit;

{считываем имя контейнера} length(containeredit.text) = 0 cont := nil := containeredit.text; := stralloc(length(err) + 1); (cont, err); ; (@hprov, cont, nil, prov_rsa_full, 0);

{генерация ключа обмена ключами (key exchange key)} kekcheckbox.checked then

{считываем длину ключа и помещаем ее в

старшее слово параметра ФЛАГИ} := strtoint(keyexchlenedit.text);

flag := keylen shl 16; not cryptgenkey(hprov, at_keyexchange, flag, @keyexchkey) then

{обработка ошибок}.lines.add(''); .lines.add('Создан ключ обмена ключами:'); := 4; not cryptgetkeyparam(keyexchkey, kp_keylen, @keylen, @flag, 0) then

{обработка ошибок}reportmemo.lines.add(' длина ключа - ' + inttostr(keylen)); := 4; not cryptgetkeyparam(keyexchkey, kp_algid, @keylen, @flag, 0) then

{обработка ошибок}reportmemo.lines.add(' алгоритм - ' + algidtostr(keylen));

{функция algidtostr здесь не приводится. Она состоит из единственного

оператора case, отображающего целый идентификатор алгоритма в строку}

end; ;

{генерация ключа подписи (signature key)} skcheckbox.checked then

{выполняется аналогично генерации ключа обмена ключами};

cryptreleasecontext(hprov, 0);

end;

 

При экспорте данные ключа сохраняются в одном из трех возможных форматов:

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

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

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

Экспорт ключей в CryptoAPI выполняется функцией cryptexportkey (экспортируемый ключ, ключ адресата, формат, флаги, буфер, размер буфера):

- экспортируемый ключ - дескриптор нужного ключа;

-  ключ адресата - в случае сохранения открытого ключа должен быть равен нулю (данные не шифруются);

-  формат - указывается один из возможных форматов экспорта (publickeyblob, privatekeyblob, simpleblob);

-  флаги - зарезервирован на будущее (должен быть равен нулю);

-  буфер - содержит адрес буфера, в который будет записан ключевой blob (binary large object - большой двоичный объект);

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

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

Запросить у криптопровайдера дескриптор самого экспортируемого ключа позволяет функция cryptgetuserkey (провайдер, описание ключа, дескриптор ключа). Описание ключа - это либо at_keyexchange, либо at_signature.

texportform.okbtnclick(sender: tobject); cont: pchar; : string; : hcryptprov; , expkey: hcryptkey; : pbyte; : dword; : file;

hash: hcrypthash;

{если ни один ключ не выбран - выход}

if not (kekcheckbox.checked or skcheckbox.checked) then exit;

{если нужен пароль, т.е. экспортируется ключевая пара целиком}

if passwedit.enabled and (passwedit.text <> passw2edit.text) then

begin ('Ошибка при вводе пароля! Повторите ввод.', mterror, [mbok]., 0); ; ;

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

если нужен ключ шифрования - создаем его на основании пароля

{ключ обмена ключами} kekcheckbox.checked then

{получаем дескриптор ключа} (hprov, at_keyexchange, @key);

{определяем размер буфера для экспорта ключа}

if (whatradiogroup.itemindex = 0) then (key, 0, publickeyblob, 0, nil, @buflen) cryptexportkey(key, expkey, privatekeyblob, 0, nil, @buflen); (pbuf, buflen);

{экспортируем данные} (whatradiogroup.itemindex = 0) then (key, 0, publickeyblob, 0, pbuf, @buflen) cryptexportkey(key, expkey, privatekeyblob, 0, pbuf, @buflen);

{освобождаем дескриптор ключа обмена ключами

(сам ключ при этом не уничтожается)} (key); .title := 'Укажите файл для сохранения ключа обмена ключами';

if savedialog1.execute then (f, savedialog1.filename); (f, 1); (f, pbuf^, buflen); (f); ('Ключ обмена ключами успешно сохранен', mtinformation, [mbok]., 0); ; true; {keyexchange}

{ключ подписи} skcheckbox.checked then

{аналогично ключу обмена ключами}

until true; {signature}

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

после чего освобождаем контекст криптопровайдера

… ;

 

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

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

Выводы

1. Проведён поэтапный анализ ООО «ЦЗИ «Гриф».

2. В результате анализа функциональной структуры построена функциональная модель предприятия.

.   Выявлены основные цели, стоящие перед предприятием, и способы их достижения. Построено дерево целей.

.   Выявлены основные проблемные ситуации и определены методы их разрешения.

.   Выбрана проблемная ситуация для решения в дипломном проекте.

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

2.
Анализ угроз информационной безопасности обособленного подразделения ООО «ЦЗИ «ГРИФ»



2020-03-17 155 Обсуждений (0)
Анализ подсистемы проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф» 0.00 из 5.00 0 оценок









Обсуждение в статье: Анализ подсистемы проверки целостности и аутентичности информации ООО «ЦЗИ «Гриф»

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

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



©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (155)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.011 сек.)