В предыдущих частях мы приблизительно разобрались, что же именно мы собираемся есть. Теперь, наконец, перейдем непосредственно к выбору блюда нам по вкусу. Здесь мы рассмотрим цели использования цифровой подписи, к какому лагерю примкнуть и в чем особенности использования каждого из вариантов, а также коснемся юридической подоплеки использования цифровых подписей. Параллельно, мы будем рассматривать возникающие в процессе вопросы и углублять те познания о работе механизма, которыми на данный момент обладаем.
Допустим, у вас возникло непреодолимое желание, а, может быть, насущная необходимость использовать цифровую подпись. Первый же всеобъемлющий вопрос, который вы должны себе задать: зачем? Если вы не можете более-менее однозначно на этот вопрос ответить, то подумайте дважды перед тем, как идти по пути использования этой технологии дальше. Ведь внедрение, а главное, использование цифровой подписи в любой ее ипостаси – достаточно трудоемкий процесс, поэтому если четкого понимания поставленных целей нет, лучше даже не браться.
Пусть, вы все же понимаете, что цифровая подпись вам просто необходима. И необходима она вам, естественно, для защиты вашей информации. Теперь рассмотрим ситуации, в которых возможно применять цифровую подпись и шифрование в порядке усложнения.
Начнем со сравнительно простого варианта: вы – частное лицо и хотите защитить отсылаемую вами по электронным источникам информацию от подмены, а также, может быть, и от прочтения посторонними людьми. Информацию вы отсылаете такому же обыкновенному человеку, с которым вы всегда можете договориться о том, как же будете защищать вашу информацию. Что же вам для этого необходимо?
Рассмотрение начнем с S/MIME. Сделаем это, во-первых, потому, что данный формат, как я уже говорил, существенно более распространен, а главное: он поддерживается на уровне Windows (а Windows, как ни крути, самая распространенная операционная система), а также многими программами, которые под Windows работают. Ну а во-вторых – данный формат с юридической точки зрения позволяет (в рамках нашего государства, естественно) существенно больше.
Какой самый простой и распространенный способ передать информацию другому человеку? Конечно же, это – электронная почта. Берем письмо, цепляем к нему файлы и отправляем. И тут нам с цифровой подписью в формате S/MIME особенно везет: все распространенные почтовые клиенты умеют как принимать сообщения с цифровой подписью, так и отправлять их. При этом подписывается все письмо целиком, включая присоединенные к письму файлы.
Рис. 1. Страница центра управления безопасностью Outlook 2007
И все бы хорошо, вот только для того, чтобы отправить письмо с подписью надо иметь программу, которая осуществляет работу с криптографией (криптопровайдер или cryptographic service provider, CSP), и сертификат определенного назначения и связанный с ним закрытый ключ. Назначение сертификата – это та область, в которой он может быть использован. Подробнее о назначениях сертификатов мы поговорим позже, а для текущей задачи нам, собственно говоря, нужен сертификат для защиты электронной почты (e-mail protection certificate).
Но вернемся к нашим потребностям. Где взять эту самую программу, криптопровайдер? На наше счастье, операционная система Windows не только поддерживает сам формат, но и содержит в себе набор криптопровайдеров, которые идут в комплекте с любой из версий системы абсолютно бесплатно, то есть даром. А значит, самое очевидное решение для данной ситуации – использовать именно их.
Итак, с криптопровайдером мы разобрались, но что же делать с сертификатом? В предыдущей части я говорил, что в процессе выдачи сертификатов участвует некая третья сторона – удостоверяющий центр, которая и осуществляет выпуск, непосредственно, сертификатов и удостоверение их содержимого и актуальности. Остановлюсь на этом моменте несколько подробнее, так как эти знания понадобятся нам в дальнейшем.
Подтверждением, что данный конкретный пользовательский сертификат корректен, и что содержимое в нем не было изменено, является все та же самая цифровая подпись, только подписывается уже удостоверяющий центр.
У удостоверяющего центра, также как и у пользователей, есть собственный сертификат. И вот именно с его помощью он подписывает выдаваемые им сертификаты. Эта процедура, во-первых, защищает выдаваемые удостоверяющим центром сертификаты от изменения (о чем я уже сказал выше), а во-вторых, однозначно показывает, какой именно удостоверяющий центр данный сертификат выдал. Как следствие, нехороший человек, конечно, может сделать полную копию вашего сертификата, с вашими именем, фамилией, даже любой дополнительной информацией, вот только подделать цифровую подпись удостоверяющего центра, не имея его закрытого ключа, для него будет практически невыполнимой задачей, а значит и распознать эту подделку будет не просто легко, а очень легко.
Сам же сертификат удостоверяющего центра, по-хорошему, тоже должен быть защищен. А значит, и подписан. Кем? Более высоко стоящим удостоверяющим центром. А тот, в свою очередь, еще более вышестоящим. И такая цепочка может быть очень длинной. Чем же она заканчивается?
А заканчивается она самоподписанным сертификатом удостоверяющего центра. Такой сертификат подписан закрытым ключом, связанным с ним же. Приводя аналогию, это как справка о занимаемой должности и зарплате генерального директора. «Данной справкой Иванов И.И., генеральный директор ООО «Одуванчик » удостоверяет, что Иванов И.И. занимает в данной организации должность генерального директора и получает зарплату в размере ####### рублей ». Чтобы данной справке верить, вы должны верить самой фирме ООО «Одуванчик», причем вера эта не подкрепляется никакой третьей стороной.
Так же и с корневыми сертификатами (т.е. сертификатами удостоверяющих центров). Самоподписанные сертификаты тех удостоверяющих центров, которым вы доверяете, должны лежать в специальном хранилище в системе, которое называется «Доверенные корневые центры сертификации». Но перед тем, как попасть туда, их надо как-то получить. И это – самое слабое звено в системе. Сам самоподписанный сертификат подделать, так же, как и пользовательский, не получится, зато замечательно получится подменить при передаче. Значит, передача должна осуществляться по защищенному от подмены каналу.
Чтобы избежать, по возможности, подобных трудностей, Microsoft выбрала несколько удостоверяющих центров и включила их сертификаты прямо в установку Windows (это Thawte , VeriSign и другие). Они уже есть у вас на компьютере и их не надо ниоткуда получать. А значит и подменить их можно только, если у вас на компьютере живет троян (или у нехорошего человека должен быть администраторский доступ к вашему компьютеру), а говорить об использовании цифровой подписи в таком случае несколько бессмысленно. Кроме того, эти удостоверяющие центры широко известны и много кем используемы, и простая подмена их сертификатов приведет к множеству ошибок в работе, скажем, сайтов, чьи сертификаты выданы этими удостоверяющими центрами, что, в свою очередь, достаточно быстро наведет на мысль о том, что что-то здесь не чисто.
Кстати, о самоподписанных сертификатах: такой сертификат можно создать и для собственного пользования, а не только для удостоверяющего центра. Естественно, такой сертификат наследует все минусы сертификатов подобного типа, но для проверки того, стоит ли использовать цифровую подпись в переписке, или лучше так обойтись он отлично подходит. Для создания подобных сертификатов можно использовать программу, входящую в состав средств Microsoft Office (Цифровой сертификат для проектов VBA), или же, для лучшей настройки назначения и прочих полей данного сертификата, программу стороннего производителя, например КриптоАрм, который даже в бесплатной своей версии позволяет такие сертификаты создавать.
Рис. 2. Просмотр самоподписанного сертификата средствами системы Windows
Итак, мы выбираем некий устраивающий нас обоих удостоверяющий центр, получаем на нем сертификаты (для чего заполняем форму на сайте, предоставляем необходимые документы и платим деньги, если потребуется), или создаем себе самоподписанный сертификат и… Собственно говоря, все. Теперь мы можем с помощью нашего почтового клиента (того же Outlook"а) отправлять и принимать подписанные и зашифрованные сообщения.
Для использования стандарта OpenPGP все и проще и сложнее. Для использования данного стандарта все так же необходимы криптопровайдер, пара из открытого и закрытого ключа и программа, осуществляющая непосредственно подписание и шифрование. Для OpenPGP все эти компоненты могут быть как платными, так и бесплатными. С бесплатными больше мороки по установке, а с платными меньше, но принципы и у тех, у тех одинаковы.
Следуя уже использованной последовательности описания, начнем с программы, с которой вы и будете контактировать больше всего: почтовым клиентом. Использование чистого Outlook"а здесь уже невозможно, по причине незнания им о стандарте OpenPGP, а значит надо либо переходить на клиент, который стандарт знает, либо использовать плагины к Outlook"у, или же даже осуществлять работу с подписями и шифрованием через копирование информации во внешние программы. Как пример почтовых клиентов, работающих со стандартом OpenPGP, можно привести Mozilla Thunderbird к которому, кстати, все равно нужен плагин или же The Bat! , умеющий в версии Profissional работать со стандартом OpenPGP сам по себе.
Рис. 3. Главный экран почтового клиента Mozilla Thunderbird
Рис. 4. Главный экран почтового клиента The Bat!
Плагины, необходимые для работы со стандартом OpenPGP в почте, также можно найти как платные, так и бесплатные. Платные плагины поставляются вместе с платными же версиями программы PGP , а как пример бесплатного плагина можно привести плагин Enigmail для все того же Thunderbird .
Рис. 5. Дополнения, появляющиеся в почтовом клиенте после установки Enigmail
Криптопровайдеры же здесь все так или иначе бесплатные. Можно использовать криптопровайдер, поставляющийся в составе даже бесплатной версии программы PGP , а можно использовать GnuPG .
Рис. 6. Страница управления ключами GnuPG
Здесь, пожалуй, стоит немного предостеречь тех, кто погонится за бесплатностью и открытостью кода. Большинство подобных приложений действительно работают и выполняют свои функции, но есть ряд проблем, характерных для всех них. И особенно весомо звучит проблема недостаточного тестирования и проблема проработки пользовательских интерфейсов. Обе эти проблемы коренные для свободного ПО по самой его сути: разработка ведется «всем миром» (или отдельной группой), а значит у проектов в большинстве случаев нету общего идеолога, нету общего конструктора, дизайнера и т.п. В итоге, зачастую получается ситуация «что выросло – то выросло», а это не всегда удобно чисто с функциональной точки зрения. Тестирование тоже, как правило, ведется «всем миром», а не профессиональными тестировщиками, над которыми нависает злой руководитель, поэтому багов в итоговую версию попадает больше. Кроме того, если обнаружен баг, который может привести к потере вашей информации, спросить бывает некого: ПО то бесплатное и открытое, и финансовой или юридической ответственности перед вами точно никто не несет. Впрочем, не стоит обольщаться, с платным ПО ситуация ровно такая же, хотя в редких случаях возможны варианты. К сожалению, эти случаи относятся, скорее, к компаниям-партнерам и корпоративным клиентам, поэтому для нас, простых пользователей, можно с тем же успехом считать, что вариантов нет.
При этом я ни в коей мере не хочу умолять достоинства такого рода софта. Вообще-то, рассматривая и платные, и бесплатные программы, работающие с криптографией, можно заметить, что первой проблеме – багам – данный софт практически (за редким исключением, которым просто не надо пользоваться) не подвержен. А вот вторая – ужасающие с точки зрения пользователя интерфейсы – касается, как ни странно, почти всех. И если причиной такой ситуации для свободного ПО может быть принято как раз «что выросло – то выросло» (скажем, у замечательной во всех отношениях программы TrueCrypt, являющейся де-факто стандартом в области шифрования данных, интерфейс ужасающ для человека, не очень глубоко разбирающегося в вопросе), то аналогичную ситуацию с платным ПО можно объяснить, пожалуй, только тем, что криптография, как направление разработки, обычно рассматривается по остаточному принципу. Исключения из этих правил встречаются и там, и там, но бо льшее число исключений лично мне, все же, встречалось в лагере платного ПО.
Но, вернемся к нашей почте. Остался нерешенным вопрос сертификата. «Проще и сложнее» живет именно здесь. Создать его вы можете прямо у себя на компьютере, не прибегая к услугам внешнего удостоверяющего центра, что, согласитесь, проще, чем отправлять запрос в какой-то удостоверяющий центр. Но отсюда и проблемы с данными сертификатами: они все самоподписанные, а значит, на них распространяются те же вопросы, которые мы рассматривали с самоподписанными сертификатами удостоверяющих центров. Второй пункт, собственно говоря, и является тем самым «сложнее».
Проблема доверия к сертификатам в данном лагере решается с помощью сетей доверия, принцип которых можно вкратце описать следующим образом: чем больше человек знают вас (ваш сертификат), тем больше оснований для доверия. Кроме того, облегчить решение проблемы передачи сертификата получателю могут публичные банки сертификатов, в недрах которых покопаться нехорошему человеку несколько сложнее, чем в передаваемой почте. В данный банк можно загрузить сертификат при его создании, а получателю просто передать, откуда ему следует этот сертификат забрать.
Сертификаты хранятся в некоторых хранилищах, которые создают на вашей машине программы для работы со стандартом OpenPGP, они обеспечивают доступ к ним. Об этом тоже не стоит забывать, ведь это означает, что получить доступ к этим сертификатам только лишь силами операционной системы без использования данных программ не получится.
Все, как и в случае S/MIME, вышеописанного набора действий вам уже хватит для достижения поставленной нами цели: обмена подписанной и зашифрованной почтой.
Итак, начало положено. Мы уже можем употребить первое, достаточно простое блюдо с приправой в виде цифровых подписей, но оно хорошо лишь для затравки и останавливаться на нем, естественно, не стоит. В дальнейших статьях мы будем разбирать все более и более сложные ситуации, и все больше и больше узнавать про особенности этой технологии.
(4,00 - оценили 18 чел.)
Сегодняшнюю небольшую запись я решил посветить теме создания электронной цифровой подписи средствами криптопровайдера «КриптоПРО». Речь пойдет о Bat файле, который можно будет использовать для автоматизации подписи электронных документов.
Для того что бы автоматизировать процесс подписывания электронных документов нам понадобится:
1) Крипто-ПРО CSP;
2) USB Ключ (например рутокен), вставленный в USB порт;
3) Блокнот (Notepad.exe);
4) Установленные сертификаты для Вашего ключа;
Камнем преткновения во всей этой истории является файл csptest.exe который находится в директории КриптоПро (по умолчанию C:\Program Files\Crypto Pro\CSP\csptest.exe ).
Откроем командную строку и выполним команду:
Cd C:\Program Files\Crypto Pro\CSP\ и csptest
Мы увидим все возможные параметры данного exe файла.
select from: -help print this help -noerrorwait do not wait for any key on error -notime do not show time elapsed -pause Wait for keyboard input after completion so that you may check memory and other resources usage -reboot Call DestroyCSProvider() of last used CSP at exit Services (cryptsrv*, HSM, etc) not affected -randinitДля того, что бы увидеть параметры той или иной глобальной опции, достаточно вызвать данный файл с этой опцией, например
Csptest -sfsign
Таким образом, чтобы подписать файл через cmd средствами csptest.exe нужно вызвать команду:
Csptest -sfsign -sign -in Dogovor.doc -out Dogovor.doc.sig -my ООО МоиПрограммы Иванов Иван Иванович
где:
-my
— Указывает владельца ключа;
-in
— Указывает какой файл нужно подписывать. Если файл находится не в папке с csptest то нужно указывать полный путь.;
-out
— Указывает имя файла подписи;
Проверить подпись можно на сайте Госулсуг по данной ссылке .
Скорей всего. Если сейчас загрузить данный файл на сайте госуслуги, то появится ошибка. Вызвано это тем, что необходима информация об удостоверяющем центре. Так же не будет лишней дата и время подписи документов. Для этого к нашей команде нужно добавить два параметра:
Csptest -sfsign -sign -in Dogovor.doc -out Dogovor.doc.sig -my ООО МоиПрограммы Иванов Иван Иванович -addsigtime -add
Если же нам нужна подпись в осоединенном формате, то добавим еще один параметр:
Csptest -sfsign -sign -in Dogovor.doc -out Dogovor.doc.sig -my ООО МоиПрограммы Иванов Иван Иванович -addsigtime -add -detached
Примечание:
Если подпись документа выполняется с ошибкой
Unable to open file
An error occurred in running the program.
.\signtsf.c:321:Cannot open input file.
Error number 0x2 (2).
Не удается найти указанный файл.
при вызове, как в последнем примере, и Вы уверены в правильности путей в параметре -in и -out, попробуйте создать подпись по первому примеру, а после выполнить команду с полным набором параметров!!!
Основную команду для подписи мы получили. Теперь немного упростим процедуру. Сделаем bat файл, при запуске которого будет подписывать файл Secret.txt, находящийся в тойже папке что и bat файл. Откроем блокнот и запишем слудующий код:
Chcp 1251 set CurPath=%cd% cd C:\Program Files\Crypto Pro\CSP call csptest -sfsign -sign -in %CurPath%\Secret.txt -out %CurPath%\Secret.txt.sig -my ООО МоиПрограммы Иванов Иван Иванович -addsigtime -add -detached cd %CurPath%
Нажимаем «Файл» -> «Сохранить как» -> ЗадаемИмя с.bat -> «Сохранить»
Собсвенно и все. Для справки:
chcp 1251
— Задает кодировку для CMD. Необходимо для валидной обработки русских букв в коде;
set CurPath=%cd%
— Сохраняет путь текущей директории CMD в переменную CurPath;
cd
— Задает текущий путь CMD;
call
— Запускает программу;
__________________________________________________________
Государственное образовательное Учреждение
Высшего профессионального образования
«САНКТ-ПЕТЕРБУРГСКИЙ
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНАЦИЙ
им. проф. М.А. БОНЧ-БРУЕВИЧА»
__________________________________________________________________________________________
В.П. Грибачев
Учебное пособие к лабораторным работам по защите информации.
Санкт-Петербург
Лабораторная работа №1
Исследование криптоалгоритма шифрования RSA .
Цель работы.
Исследование структуры алгоритма и методики практической реализации криптосистемы шифрования RSA.
Криптосистема RSA разработана Рональдом Райвестом, Ади Шамиром и Леонардом Адлеманом в 1972г. Система была названа по первым буквам их фамилий. Несмотря на сообщения последних лет об отдельных попытках успешного криптоанализа этого алгоритма, RSA по-прежнему остается одним из самых распространенных криптоалгоритмов. Поддержка RSA встроена в большинство распространенных браузеров (Firefox, IE), существует плагины RSA для Total Commandera и некоторых других ftp-клиентов. В нашей стране алгоритм не сертифицирован.
RSA относится к классу двухключевых криптосистем. Это означает, что алгоритм использует два ключа – открытый (Public) и секретный (Private).
Открытый ключ и соответствующий ему секретный вместе образуют ключевую пару (Keypair). Открытый ключ не требуется сохранять в тайне. В общем случае он публикуется в открытых справочниках и доступен всем желающим. Сообщение, зашифрованное на открытом ключе может быть расшифровано только на соответствующем ему парном закрытом ключе, и наоборот.
Криптостойкость RSA основана на задаче факторизации или разложения на множители двух больших чисел, произведение которых образует так называемый модуль RSA. Факторизация позволяет раскрыть секретный ключ, в результате чего появляется возможность расшифровки любого зашифрованного на этом ключе секретного сообщения. Однако в настоящее время считается математически не доказанным, что для восстановления открытого текста по зашифрованному необходимо непременно производить разложение модуля на сомножители. Возможно, в будущем найдется более эффективный способ криптоанализа RSA, основанный на других принципах.
Таким образом, криптостойкость RSA определяется используемым модулем.
Для обеспечения достаточной степени криптостойкости, в настоящее время рекомендуется выбирать длину RSA – модуля не менее 1024 бит, причем в связи с быстрым прогрессом компьютерной техники эта величина всё время растет.
Схема алгоритма шифрования данных RSA
Выбирают два случайных простых числа (p и q ) и вычисляют модуль:
Вычисляется функция Эйлера: φ (n )=(p -1)(q -1);
Случайным образом выбирается секретный ключ е , при этом должно выполняться условие взаимной простоты чисел е и φ (n ).
Вычисляют ключ дешифрования по формуле:
ed = 1 mod φ (n );
заметим, что d и n также должны быть взаимно простыми числами.
Для шифрования необходимо разбить сообщение на блоки одинаковой длинны. Число двоичных разрядов в блоке должно соответствовать числу разрядов модуля n .
Шифрование блока сообщения осуществляется по формуле:
C i =M i e mod n
Дешифрование каждого блока c i осуществляется по формуле:
M i = C i d mod n
Выбор d в качестве открытого ключа, а e в качестве секретного совершенно условный. Оба ключа совершенно равноправны. В качестве открытого ключа можно взять е , а в качестве закрытого – d .
Пример шифрования:
Выбираем р = 7 , q = 13 , модуль n = pq = 7·13 = 91;
Вычисляем функцию Эйлера φ (n ) = (p -1)(q -1) = (7-1)(13-1) = 72;
С учетом условий НОД(e , φ (n )) = 1 и 1 < e ≤ φ (n ), выбираем секретный ключ e = 5;
Исходя из условия ed = 1 mod φ (n ), вычисляем парный секретный ключ 5· d = 1 mod 72 , используя расширенный алгоритм Евклида, находим открытый ключ d = 29;
Берем открытое сообшение m = 225367 и разбиваем его на блоки одинаковой длинны m 1 = 22, m 2 = 53, m 3 = 67.
Шифруем: С 1 = 22 5 mod 91 = 29, C 2 = 53 5 mod 91 = 79, C 3 = 67 5 mod 91 = 58;
Расшифровываем: M 1 = 29 29 mod 91 = 22, M 2 = 79 29 mod 91 = 53, M 3 = 58 29 mod 91 = 67;
Методика выполнения работы.
Задание на выполнение работы выдается преподавателем после прохождения студентами собеседования по основам криптосистем с открытым ключом.
Цель и назначенные работы.
Описание алгоритма работы криптосистемы RSA,
Блок – схема алгоритма работы криптосистемы RSA,
Выводы: преимущества и недостатки криптосистемы RSA.
Лабораторная работа №2.
Исследование электронной цифровой подписи (ЭЦП) RSA .
Цель работы.
Исследование алгоритма электронной цифровой подписи (ЭЦП) RSA.
Основные теоретические положения.
Схема электронной цифровой подписи предназначена для обеспечения в электронных сетях защищенного документооборота, аналогично тому, как в сфере традиционного документооборота для защиты бумажных документов используются подписи и печати. Таким образом, технология ЭЦП предполагает наличие группы абонентов, посылающих друг другу подписанные электронные документы. ЭЦП обладает всеми свойствами настоящей подписи. Для того, чтобы стать абонентом системы ЭЦП, каждый пользователь должен создать пару ключей – открытый и закрытый. Открытые ключи абонентов могут быть зарегистрированы в сертифицированном удостоверяющем центре, однако в общем случае это не является обязательным условием взаимодействия абонентов системы ЭЦП.
В настоящее время системы ЭЦП могут строиться на различных алгоритмах двухключевой криптографии. Одним из первых для этих целей стал применяться алгоритм RSA. Помимо криптографического алгоритма, схема ЭЦП требует применения так называемых однонаправленных или хеш – функций. Хеш-функция называется однонаправленной, поскольку позволяет легко вычислять значение хеша от любого документа. При этом обратная математическая операция, то есть вычисление исходного документа по его хеш – значению представляет значительные вычислительные трудности. Из других свойств хеш – функций следует отметить, что выходные значения (хеш) всегда имеют строго определенную длину для каждого вида функций, кроме того, алгоритм вычисления хеш – функции построен таким образом, что каждый бит входного сообщения влияет на все биты хеша. Хеш является как бы сжатым «дайджестом» входного сообщения. Разумеется, учитывая, что существует бесконечное множество всевозможных сообщений, и что хеш имеет фиксированную длину, возможно существование не менее двух различных входных документов, которые дают одинаковые значения хешей. Однако, стандартная длинна хеша задается таким образом, чтобы при существующих вычислительных мощностях компьютеров нахождение коллизий, то есть различных документов, дающих одинаковые значения функций было вычислительно сложной задачей.
Таким образом, хеш – функция является некриптографическим преобразованием, позволяющим вычислить хеш для любого выбранного документа. Хеш имеет строго фиксированную длину и вычисляется таким образом, что каждый бит хеша зависит от каждого бита входного сообщения.
Существует достаточно большое разнообразие вариантов построения хеш – функций. Обычно они строятся на основе итеративной формулы, например, H i = h (H i -1 , M i ) , где в качестве функции h может быть взята некоторая легко вычисляемая функция шифрования.
На рисунке 1. изображена обобщенная схема ЭЦП на основе криптографического алгоритма RSA.
Алгоритм электронной цифровой подписи (ЭЦП) RSA
Действия абонента – отправителя сообщения.
Выбираются два больших и взаимно-простых числа p и q ;
Вычисляем модуль RSA. n = p * q ;
Определяем функцию Эйлера: φ (n )=(p -1)(q -1);
Выбираем секретный ключ e с учетом условий: 1< e ≤φ(n ),
HOD(e , φ(n ))=1;
Определяем открытый ключ d , с учетом условий: d < n , e * d ≡ 1(mod φ(n )).
Формирование ЭЦП
Вычисляем хеш сообщения М : m = h (M ).
Шифруем хеш сообщения на секретном ключе абонента – отправителя и отправляем полученную ЭЦП, S = m e (mod n ), абоненту – получателю вместе с открытым текстом документа М .
Проверка подлинности подписи на стороне абонента - получателя
Расшифровываем ЭЦП S c помощью открытого ключа d и получаем таким образом, доступ к хеш – значению, присланному абонентом – отправителем,.
Вычисляем хеш открытого документа m ’= h (M ).
Сравниваем хеш – значения m и m’, и делаем вывод, что ЭЦП достоверна, если m = m’.
Методика выполнения работы.
Задание на выполнение лабораторной работы выдается преподавателем после прохождения студентами собеседования по основам аутентификации данных и концепции формирования электронной цифровой подписи.
Порядок выполнения работы соответствует приведенному ниже практическому примеру формирования и проверки ЭЦП.
Пример вычисления и проверки ЭЦП.
Выбираются два больших и взаимно-простых числа 7 и 17;
Вычисляем модуль RSA. n =7*17=119;
Определяем функцию Эйлера: φ (n )=(7-1)(17-1)=96;
Выбираем секретный ключ e с учетом условий: 1< e ≤φ(n ), HOD(e , φ(n ))=1; e = 11;
Определяем открытый ключ d , с учетом условий: d < n , e * d ≡ 1(mod φ(n )); d =35;
В качестве открытого сообщения возъмем некоторую случайную последовательность чисел. М = 139 . Разобъем его на блоки. M 1 = 1, M 2 = 3, M 3 = 9;
Для вычисления хеш-значения применим формулу вычисления хеш – функции. Для упрощения расчетов предположим, что инициализационный вектор хеш - функции H 0 =5, а в качестве функции шифрования h будем использовать тот же RSA.
Вычислим хеш сообщения. H 1 =(H 0 + M 1 ) e mod n =(5+1) 11 mod 119=90; H 2 =(H 1 + M 2 ) e mod n =(90+3) 11 mod 119=53; H 3 = (H 2 + M 3 ) e mod n =(53+9) 11 mod 119=97; Таким образом, хеш данного открытого сообщения m = 97;
Создаем ЭЦП путем зашифровывания полученного хеш – значения. S = H e mod n = 97 11 mod 119 = 6;
Передаем по каналу связи открытый ключ d , текст сообщения М , модуль n и электронную цифровую подпись S.
Проверка ЭЦП на стороне получателя сообщения.
На стороне абонента – получателя подписанного сообщения с помощью открытого ключа получаем хеш – значение переданного документа. m ´ = S d mod n =6 35 mod 119 =97;
Вычисляем хеш переданного открытого сообщения, аналогично тому, как это значение вычислялось на стороне абонента – отправителя. H 1 =(H 0 + M 1 ) e mod n =(5+1) 11 mod 119=90; H 2 =(H 1 + M 2 ) e mod n =(90+3) 11 mod 119=53; H 3 = (H 2 + M 3 ) e mod n =(53+9) 11 mod 119=97; m = 97;
Сравниваем хеш-значение, вычисленное по переданному открытому документу и хеш-значение, извлеченное из ЭЦП. m = m ´ =97. Значение вычисленного хеша совпадает со значением хеша, полученным из ЭЦП, следовательно, получатель сообщения делает вывод, что полученное сообщение является подлинным.
Цель и назначение работы.
Описание алгоритма формирования ЭЦП RSA.
Блок – схема алгоритма формирования ЭЦП RSA.
Выводы: преимущества и недостатки ЭЦП RSA.
