Министерство образования РФ
Дагестанский Государственный Технический Университет
Факультет: Информатики и Управления
Кафедра: ПОВТиАС
КУРСОВАЯ РАБОТА
по дисциплине:
«ТРП
»
на тему:
«Зашита данных-Цифровая подпись»
Выполнил:
Ст-нт 4-го курса
группы №3042
Велибеков А.У.
Приняла:
Гаджимирзоева Г.И.
Махачкала 2004 г
Аннотация
Данная курсовая работа посвящена решению задачи защиты информации. В работе содержится описание алгоритма
RSA
и рабочая программа, реализующая данный алгоритм. Пояснительная записка к курсовой работе содержит:
__ рисунока;
__ страниц машинописного текста.
Содержание
Введение__________________________________________ 4
Задание____________________________________ 5
Теоретические сведения___________________________ 6
Алгоритмы: американские разработки____________________
6
Алгоритмы: российские разработки______________________
7
Цифровая подпись и криптосистемы с ключом общего пользования.
8
Неотрицаемые цифровые подписи_______________________
10
Слепые подписи____________________________________
12
Полностью слепые подписи
______________________________
12
Слепые подписи
_______________________________________
13
Атаки на цифровую подпись__________________________
15
Можно ли подделать ЭЦП?___________________________
18
Стандарты
__________________________________
18
З А К Л Ю Ч Е Н И Е_______________________________ 20
Список использованной литературы__________________ 21
Приложение к курсовой работе____________________ 22
Введение
Идея цифровой подписи как законного средства подтверждения подлинности и авторства документа в электронной форме впервые была явно сформулирована в 1976 году в статье двух молодых американских специалистов по вычислительным наукам из Стэнфордского университета Уитфилда Диффи (Witfield Diffie) и Мартина Хеллмана (Martin Hellman).
Суть цифровой подписи состоит в том, что для гарантированного подтверждения подлинности информации, содержащейся в электронном документе, а также для возможности неопровержимо доказать третьей стороне (партнеру, арбитру, суду и т. п.), что электронный документ был составлен именно конкретным лицом или по его поручению и именно в том виде, в котором он предъявлен, автору документа предлагается выбрать свое индивидуальное число (называемое обычно индивидуальным ключом, паролем, кодом и т. д.) и каждый раз для "цифрового подписывания" сворачивать (замешивать) этот свой индивидуальный ключ, хранимый в секрете от всех, с содержимым конкретного электронного документа. Результат такого "сворачивания" - другое число - может быть назван цифровой подписью данного автора под данным конкретным документом.
- электронная цифровая подпись
— набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания
- закрытый ключ электронной цифровой подписи
— последовательность электронных цифровых символов, известная владельцу регистрационного свидетельства и предназначенная для создания электронной цифровой подписи с использованием средств электронной цифровой подписи;
- открытый ключ электронной цифровой подписи
— последовательность электронных цифровых символов, доступная любому лицу и предназначенная для подтверждения подлинности электронной цифровой подписи в электронном документе.
Контрольные суммы, контроль CRC, хэширование и цифровая подпись – базовые средства аутентификации при цифровой передаче данных.
Задание
Цифровая подпись
1. Формирование цифровой подписи.
2. Контроль цифровой подписи.
3. Алгоритмы формирования цифровой подписи.
4. Стандарты в области цифровой подписи.
5. Дополнительные функциональные возможности в цифровой подписи.
Теоретические сведения
Алгоритмы: американские разработки
Сопоставим теперь некоторые конкретные алгоритмы цифровой подписи и выясним их преимущества и недостатки в различных ситуациях.
Для удобства оценки основных свойств того или иного алгоритма мы будем сравнивать его основные характеристики:
- длину ключей,
- длину цифровой подписи,
- сложность (время) вычисления,
- сложность (время) проверки подлинности цифровой подписи, при условии, что уровень стойкости подписи по отношению к любым методам фальсификации не ниже 1021
. За "базовую" длину ключей и длину самой цифровой подписи примем 64 байта.
RSA.
Первым по времени изобретения конкретным алгоритмом цифровой подписи был разработанный в 1977 году в Массачусетском технологическом институте алгоритм RSA.
Алгоритм RSA основывается на том математическом факте, что задача дискретного логарифмирования при выборе целого параметра n в виде произведения двух различных простых чисел примерно равных по порядку величины, т.е.
n = p*q
становится не менее сложной, чем разложение n на эти простые множители, а последняя задача давно (еще со времен Архимеда и Евклида) известна в математике как сложная.
По современным оценкам сложность задачи разложения на простые множители при целых числах n из 64 байт составляет порядка 1017
- 1018
операций, т. е. находится где-то на грани досягаемости для серьезного "взломщика". Поэтому обычно в системах цифровой подписи на основе алгоритма RSA применяют более длинные целые числа n (обычно от 75 до 128 байт).
Это соответственно приводит к увеличению длины самой цифровой подписи относительно 64-байтного варианта примерно на 20% -100% (в данном случае ее длина совпадает с длиной записи числа n), а также от 70% до 800% увеличивает время вычислений при подписывании и проверке.
Кроме того, при генерации и вычислении ключей в системе RSA необходимо проверять большое количество довольно сложных дополнительных условий на простые числа p и q (что сделать достаточно трудно и чего обычно не делают, пренебрегая вероятностью неблагоприятного исхода - возможной подделки цифровых подписей), а невыполнение любого из них может сделать возможным фальсификацию подписи со стороны того, кто обнаружит невыполнение хотя бы одного из этих условий (при подписывании важных документов допускать, даже теоретически, такую возможность нежелательно).
В дополнение ко всем этим алгоритмическим слабостям метода RSA следует также иметь в виду, что он защищен патентом США и поэтому любое его использование на территории США или западноевропейских стран требует приобретения соответствующей лицензии на использование, стоимость которой на 100 пользователей составляет $5000.
Алгоритмы: российские разработки
Нотариус.
В 1991 году самым распространенным персональным компьютером в СССР был AT/286 12 МГц, и мы в своих ранних алгоритмических разработках должны были максимально упростить лучшие из известных тогда алгоритмов цифровой подписи, чтобы их программная реализация позволяла вычислять и проверять подпись под электронными документами за разумное время, скажем, 1-2 секунды, при размере документа до 10 Кбайт. Упрощения, конечно, не должны были снижать стойкости алгоритма.
Первым результатом нашей работы был созданный в конце 1992 года аналог алгоритма Эль Гамаля "Нотариус-1
". Главное отличие "Нотариус-1" состояло в том, что вместо обычной операции умножения целых чисел по модулю большого простого p, как это делается у Эль Гамаля, в нем использовалась похожая операция, которая, обеспечивая точно такой же уровень стойкости, что и умножение по модулю простого числа, гораздо эффективнее выполнялась на распространенных процессорах Intel, Motorola и др.
Затем аналогичным образом был усовершенствован алгоритм DSA, который послужил основой для алгоритма цифровой подписи, названного "Нотариус-D
". Реализация этого алгоритма на процессоре Intel 486DX4/100 позволила довести время подписывания электронного документа объемом 1 Кбайт вместе с предварительной обработкой перед подписыванием (так называемым хешированием) до 0,014 с, а время проверки подписи - до 0,027 с. Для документа объемом 100 Кбайт время подписывания составляет 0,124 с., время проверки - 0,138 с. Длина подписи 40 байт, стойкость - 1021
.
Совместное использование наших идей и идей немецкого криптографа Клауса Шнорра (Klaus Shnohrr), предоставившего нам право использования своего алгоритма на территории стран СНГ, привело к разработке в 1996 году усовершенствованного алгоритма "Нотариус-S
", который при сохранении стойкости подписи позволил сократить ее длину еще на 32,5%. Для базового варианта с ключами из 64 байт длина подписи сократилась относительно DSA и "Нотариуса-D" с 40 до 27 байт. Соответственно уменьшилось время вычисления и проверки подписи.
Эти алгоритмические разработки позволили нам предложить пользователю широкий выбор программ с длинами цифровой подписи от 16 до 63 байт и уровнями стойкости соответственно от 1014
(или несколько дней работы сети из нескольких десятков персональных компьютеров) до 1054
(или более 100 млрд. лет непрерывной работы любой мыслимой вычислительной системы обозримого будущего).
Цифровая подпись и криптосистемы с ключом общего пользования.
Если использовать алгоритмы хэширования вместе с криптосистемами с ключом общего пользования, то можно создать цифровую подпись, гарантирующую подлинность полученного набора данных, аналогично тому, как рукописная подпись, подтверждает аутентичность напечатанного документа. Криптосистема с ключом общего пользования - это метод, позволяющий осуществлять кодирование и декодирование информации, с помощью двух исходных ключей: ключа общего пользования, свободно передаваемого всем желающим, и личного ключа, известного только его владельцу.
Смысл ключа и пароля примерно одинаков. Допустим, Том желает, чтобы Сэм мог отправить ему зашифрованный документ, и оба они не хотели бы рисковать, передавая пароль или ключ по линиям связи, так как в этом случае он может быть кем-то перехвачен. Тогда Том может передать Сэму свой ключ общего пользования. Используя этот ключ, Сэм шифрует документ и отправляет его Тому. Том дешифрует документ с помощью своего личного ключа. Это единственный ключ, с помощью которого можно восстановить документ, зашифрованный с применением ключа общего пользования, принадлежащего Тому. Тот факт, что ключ общего пользования Тома может стать кому-то известен, не имеет особого значения, потому что он абсолютно бесполезен для расшифровки документа. А личный ключ, известный одному лишь Тому, по открытым линиям связи не передавался; теоретически том хранит его только в собственной памяти и наоборот, работа других криптосистем с ключом общего пользования строится на обратном принципе: Сэм шифрует документ с помощью своего личного ключа и передает свой ключ общего пользования Тому, с помощью которого тот мог бы расшифровать этот документ. Существующие ныне криптосистемы с ключом общего пользования, такие, например, как система RSA (сокращение, составленное из первых букв фамилий трех создателей этого алгоритма), широко используются.
Как же осуществляется цифровая подпись
? Рассмотрим еще один пример. Допустим, Сэм собирается отправить Тому контракт или номер своей кредитной карточки в цифровом виде. Для подтверждения подлинности этих документов Тому необходима цифровая подпись Сема. Сначала Сэм отправляет свой документ. Затем использует алгоритм хэширования для вычисления идентификатора этого документа, шифрует хэшированное значение с помощью своего личного ключа и отправляет его Тому. Это и есть цифровая подпись Сэма. Том с помощью того же алгоритма хэширования сначала вычисляет идентификатор принятого документа. Затем он расшифровывает значение, которое получил от Сэма, используя предоставленный Сэмом ключ общего пользования. Если два значения хэширования совпали, Том не только узнает, что этот документ подлинный, но и то, что подпись Сэма действительна. Понятно, что проведение коммерческих транзакций по такому сценарию значительно безопаснее, чем с использованием подписи от руки на бумаге, которую можно подделать. А если сведения, передаваемые Сэмом Тому, конфиденциальны (например, содержат номер кредитной карточки), то и их можно зашифровать так, чтобы прочитать их смог только Том.
Процесс создания цифровой подписи на сообщении и процесс ее верификации отражены на рисунках 1 и 2. На первом этапе создается цифровая характеристика сообщения (собственно подпись или хэш), затем она шифруется секретным ключом пользователя. Текст сообщения, цифровая подпись и сертификат пользователя отправляются адресату.
Принимающая сторона создает собственную версию цифровой подписи на основе тела полученного сообщения, расшифровывает открытым ключом отправителя приложенную цифровую подпись и затем их сравнивает. Совпадение цифровых подписей гарантирует, что сообщение не было изменено в процессе передачи.
Во-первых,
цифровая подпись должна подтверждать, что подписывающее лицо не случайно подписало электронный документ. Во-вторых,
цифровая подпись должна подтверждать, что только подписывающее лицо, и только оно, подписало электронный документ. В-третьих,
цифровая подпись должна зависеть от содержания подписываемого документа и времени его подписания. В-четвертых
, подписывающее лицо не должно иметь возможности в последствии отказаться от факта подписи документа.
Неотрицаемые цифровые подписи
Обычные цифровые подписи могут быть точно скопированы. Иногда это свойство полезно, например, при распространении публичных заявлений. В другой раз это может оказаться проблемой. Вообразите личное или деловое письмо, подписанное цифровой подписью. Если распространяется множество копий этого документа, каждая из которых может быть проверена кем угодно, то это может привести к замешательству или шантажу. Лучшим решением является цифровая подпись, правильность которой может быть доказана получателю, но которая не позволит получателю показать третьей стороне полученное сообщение без согласия разрешения лица, подписавшего сообщение.
Alice Software Company (Компания программного обеспечения Алисы) распространяет продукт DEW (Do-Everything-Word, Делая со словом что угодно). Для гарантии отсутствия вирусов каждая копия содержит цифровую подпись. Однако создатели хотят, чтобы только легальные покупатели продукта, а не компьютерные пираты могли проверить подпись. В то же время, если обнаруживаются копии DEW, содержащие вирус, у Alice Software Company не должно быть возможности отрицать правильную подпись.
Неотрицаемые подписи удобны для решения подобных задач. Как и обычная цифровая подпись, неотрицаемая цифровая подпись зависит от подписанного документа и закрытого ключа человека, подписавшего документ. Но, в отличие от обычных цифровых подписей, неотрицаемая подпись не может быть проверена
без разрешения подписавшего.
Хотя для этих подписей можно было бы подобрать название получше, например, "непередаваемые подписи", существующее название обусловлено тем обстоятельством, что если Алисе придется либо подтвердить, либо отрицать подпись - может быть в суде - она не сможет ложно отрицать свою настоящую подпись. Несмотря на сложность математики основная идея проста:
(1) Алиса предъявляет Бобу подпись.
(2) Боб создает случайное число и посылает его Алисе.
(3) Алиса выполняет вычисления, используя случайное число и свой закрытый ключ, и посылает Бобу результат. Алиса может выполнить эти вычисления только, если подпись правильна.
(4) Боб проверяет это.
Также существует дополнительный протокол, позволяющий Алисе доказать, что она не подписывала документ, и не допускающий возможности ложно отказаться от подписи.
Боб не может повернуться и убедить Кэрол, что подпись Алисы правильна, потому что Кэрол не знает, что числа Боба случайны. Он может легко без помощи Алисы изложить протокол на бумаге и послать результат Кэрол. Кэрол может удостовериться в правильности подписи Алисы только, если она сама выполнит этот протокол с Алисой.
Это решение не совершенно. Иво Десмедт и Моти Юнг (Moti Yung) показали, что в некоторых случаях Боб может убедить Кэрол в правильности подписи Алисы.
Например, Боб покупает легальную копию DEW. Он может подтвердить подпись под программным продуктом, когда захочет. Тогда, Боб может убедить Кэрол, что он работает на Alice Software Company, и продать ей пиратскую копию DEW. Когда Кэрол попытается подтвердить подпись Боба, он одновременно подтверждает подпись у Алисы. Когда Кэрол посылает ему случайное число, он отправляет его Алисе. Ответ Алисы он пересылает Кэрол. Кэрол убеждается в том, что она - легальный покупатель, хотя она таковым не является.
Несмотря на это у неотрицаемых подписей множество применений, во многих случаях Алиса не хочет, чтобы кто угодно мог проверить ее подпись. Она может не хотеть, чтобы подпись под ее личной корреспонденцией могла быть проверена журналистами, чтобы ее письма были опубликованы и подтверждены независимо от контекста, или просто, чтобы нельзя было обнаружить изменения в письмах, сделанные ею позже. Если она подписывает информацию, которую она продает, то она не хочет, чтобы кто-то, не заплатив за информацию, мог подтвердить ее достоверность. Защитить свои права Алиса может, контролируя тех, кто проверяет ее подпись.
Ряд вариантов неотрицаемых подписей отделяет связь между подписавшим и сообщением от связи между подписавшим и подписью. В одной схеме кто угодно может проверить, что подпись действительно была создана ее автором, а для проверки правильности подписи для данного сообщения требуется сотрудничество подписавшего.
Близким понятием является доверительная неотрицаемая подпись. Представьте, что Алиса работает на Toxins, Inc., и передает обличающие документы в газету, используя протокол неотрицаемой подписи. Алиса может подтвердить свою подпись только репортеру газеты и никому больше. Однако негодяй Боб подозревает, что источником документов является Алиса. Он требует, чтобы Алиса использовала протокол снятия подписи, чтобы очистить свое имя, а Алиса отказывается. Боб настаивает, что единственной причиной отказа Алисы является ее виновность, и убивает ее.
Доверительные неотрицаемые подписи похожи на обычные неотрицаемые подписи за исключением протокола снятия подписи, который может быть запущен только Трентом. Только Трент, а не Боб может потребовать от Алисы использовать протокол снятия. И если Трент представляет судебную систему, то он использует этот протокол только для разрешения формального спора.
Слепые подписи
Важным свойством протоколов цифровой подписи является знание подписывающим содержания подписываемого документа. Это хорошее свойство, даже когда хочется обратного.
Мы можем пожелать, чтобы люди подписывали документы, даже не зная их содержания. Существуют способы, когда подписывающий может не точно, но почти
знать, что он подписывает. Но все по порядку.
Полностью слепые подписи
Боб - государственный нотариус. Алиса хочет, чтобы он подписал документ, не имея ни малейшего представления о его содержании. Боб не отвечает за содержание документа, он только заверяет, что нотариально засвидетельствовал его в определенное время. Он собирается действовать по следующему плану:
(1) Алиса берет документ и умножает его на случайное число. Это случайное число называется маскирующим множителем.
(2) Алиса посылает замаскированный документ Бобу.
(3) Боб подписывает замаскированный документ.
(4) Алиса удаляет маскирующий множитель, получая оригинальный документ, подписанный Бобом.
Этот протокол работает только, если функция подписи и умножение коммутативны. Если нет, то помимо умножения существуют и другие способы изменить документ. А сейчас, для простоты математики остановимся на умножении.
Может ли боб смошенничать? Может ли он получить какую-нибудь информацию о том, что пописывает? Если множитель осторожности действительно случаен и делает замаскированный документ действительно случайным, то нет. Замаскированный документ, подписываемый Бобом на этапе, (2) ничем не похож на оригинальный документ Алисы. Замаскированный документ с подписью Боба на нем на этапе (3) ничем не похож на подписанный документ этапа (4). Даже если Боб заполучит документ со своей подписью после окончания протокола, он не сможет доказать (себе или кому-то другому), что он подписал его в этом конкретном протоколе. Он знает, что его подпись правильна. Он может, как и любой другой, проверить свою подпись. Однако, у него нет никакой возможности связать подписанный документ и любую информацию, полученную при выполнении протокола. Если он подписал, используя этот протокол, миллион документов, у него не будет способа узнать, когда какой документ он подписал. Полностью слепые подписи обладают следующими свойствами:
1. Подпись Боба под документом правильна и служит доказательством того, что Боб подписал этот документ. Она убедит Боба в том, что он подписал этот документ, когда документ будет впоследствии показан Бобу. Она также обладает всеми свойствами цифровых подписей.
2. Боб не может связать подписанный документ с процессом подписания документа. Даже если у него хранятся записи обо всех сделанных им слепых подписях, он не сможет определить, когда он подписал конкретный документ.
У Евы, находящейся между Алисой и Бобом и следящей за протоколом, информации еще меньше, чем у Боба.
Слепые подписи
С помощью протокола полностью слепых подписей Алиса может заставить Боба подписать что-нибудь вроде: "Боб должен Алисе миллион долларов", "Боб должен Алисе своего первого ребенка", "Боб должен Алисе ящик шоколада". Возможности бесконечны, и поэтому во многих приложениях этот протокол бесполезен.
Однако, существует способ, с помощью которого Боб может узнать, что он подписывает, вместе с тем сохраняя полезные свойства слепых подписей. Центральным моментом этого протокола является техника "разрезать и выбрать". Рассмотрим следующий пример. Множество людей каждый день въезжают в некую страну, и Департамент иммиграции хочет удостовериться, что они не ввозят кокаин. Служащие могут обыскивать каждого, но вместо этого используется вероятностное решение - обыскивается каждый десятый въезжающий. Подвергается досмотру имущество одного человека из десяти, остальные девять пропускаются беспрепятственно. Постоянные контрабандисты в большинстве случаев проскакивают незамеченными, но с вероятностью 10 процентов их ловят. И если судебная система работает эффективно, наказание за единственную поимку на месте преступления более чем перевешивает выгоды девяти удачных попыток.
Если Департамент иммиграции захочет повысить вероятность поимки контрабандистов, служащим придется обыскивать больше людей, захочет понизить вероятность - можно будет обыскивать меньше людей. Управляя вероятностями, можно контролировать эффективность протокола при поимке контрабандистов.
Протокол слепой подписи работает аналогичным образом. Боб получает большую пачку различных замаскированных документов. Он откроет, например, все кроме одного и затем подпишет последний.
Посмотрите на замаскированный документ как на лежащий в конверте. Процесс маскировки документа можно рассматривать как помещение документа в конверт, а процесс удаления множителя маскировки - как вскрытие конверта. Когда документ спрятан в конверт, никто не сможет его прочитать. Документ подписывается с помощью кусочка копировальной бумаги, помещенной в конверт: Когда подписывающий ставит свою подпись на конверте, с помощью кусочка копировальной бумаги эта подпись ставится и под документом.
В следующем сценарии действует группа агентов контрразведки. Их личности засекречены, даже само Управление контрразведки не знает, кто они такие. Директора Управления хочет выдать каждому агенту подписанный документ следующего содержания: "Податель этого подписанного документа, (вставьте имя, под которым действует агент), обладает полной дипломатической неприкосновенностью". У каждого из агентов есть свой список псевдонимов, поэтому Управление не может просто раздать подписанные документы. Агенты не хотят передавать свои псевдонимы в Управление, так как враг мог вскрыть компьютер Управления. С другой стороны, Управление не хочет слепо подписывать документы, предоставленные агентом. Хитрый агент может представить сообщение, подобное следующему: "Агент (имя) вышел в отставку, и ему назначена ежегодная пенсия в миллион долларов. Подписано, Президент". В этом случае могут быть полезны слепые подписи.
Предположим, что у каждого агента по 10 псевдонимов, выбранных ими самими и больше никому неизвестных. Предположим также, что агентам все равно, под каким именем они получат дипломатическую неприкосновенность. Также предположим, компьютер управления называется Agency's Large Intelligent Computing Engine (Большая Интеллектуальная Вычислительная Машина Управления), или ALICE, а нашим конкретным агентом является Bogota Operations Branch (Сектор операций в Боготе): ВОВ.
(1) ВОВ готовит п
документов, каждый из которых использует различный псевдоним, дающих ему дипломатическую неприкосновенность.
(2) ВОВ маскирует каждый из документов отличным маскирующим множителем .
(3) ВОВ отправляет п
документов ALICE.
(4) ALICE случайным образом выбирает п-1
документ и просит ВОВ'а прислать маскирующий множитель для каждого из выбранных документов.
(5) ВОВ посылает ALICE соответствующие маскирующие множители.
(6) ALICE открывает (т.е., удаляет маскирующий множитель) п-1
документ и убеждается в том, что они корректны - и не являются разрешением на выплату пенс
(7) ALICE подписывает оставшийся документ и посылает его ВОВ'у.
(8) Агент удаляет маскирующий множитель и читает свой новый псевдоним: "Малиновая полоса." Подписанный документ дает ему дипломатическую неприкосновенность под этим именем.
Этот протокол надежно защищен от мошенничества ВОВ'а. Чтобы смошенничать, он должен точно угадать, какой документ ALICE не будет проверять. Вероятность этого - 1 шанс из п -
не слишком велика. ALICE знает это и чувствует себя уверенно, подписывая документ, который она не сможет проверить. Для этого документа рассматриваемый протокол полностью совпадает с предыдущим протоколом полностью слепой подписи, сохраняя все свойства анонимности.
Существует трюк, который еще больше уменьшает вероятность мошенничества ВОВ'а. На этапе (4) ALICE случайным образом выбирает п/2
документов для проверки, и ВОВ присылает ей соответствующий маскирующие множители на этапе (5). На этапе (7) ALICE перемножает все непроверенные документы и подписывает получившийся мегадокумент. На этапе (8) ВОВ удаляет все маскировочные множители. Подпись ALICE будет правильной, только если ею подписано произведение п/2
идентичных документов. Чтобы смошенничать, ВОВ'у нужно точно угадать, какое подмножество документов будет проверять ALICE. Вероятность этого гораздо ниже, чем вероятность угадать единственный документ, который ALICE не проверяла.
ВОВ может смошенничать по-другому. Он может создать два различных документа, один из которых ALICE согласна подписать, а другой - нет. Затем он может попытаться найти два различных маскирующих множителя, которые преобразуют указанные документы к одинаковому виду. Таким образом, если ALICE захочет проверить документ, ВОВ передаст ей маскирующий множитель, преобразующий документ к невинному виду. Если ALICE не захочет просмотреть документ и подпишет его, он применит тот маскирующий множитель, который преобразует замаскированный подписанный документ в документ, являющийся целью мошенничества. Хотя теоретически это и возможно, математика конкретных алгоритмов делает пренебрежимо малой вероятность для ВОВ'а найти такую пару. Действительно, она может быть столь низкой, как и вероятность Боба, создать необходимую подпись под произвольным документом самостоятельно.
Атаки на цифровую подпись
Пользователю системы электронной цифровой подписи необходимо знать, каким образом злоумышленник может осуществить атаку на ЭЦП. В документации на многие системы цифровой подписи очень часто упоминается число операций, которые надо осуществить для перебора всех возможных ключей. Однако это только один из возможных вариантов реализации атак. Квалифицированный злоумышленник далеко не всегда использует такой "грубый" перебор (brute force search) всех возможных ключей.
Рассмотрим подробнее некоторые из типов атак.
Специалистам российского Федерального агентства правительственной связи и информации (ФАПСИ) удалось выявить при анализе одной из отечественных систем цифровой подписи интересное статистическое искажение. Злоумышленник (сотрудник отдела информатизации финансовой организации, в которой была внедрена данная система) исправил в исполняемом ЕХЕ-модуле программы проверки правильности цифровой подписи символьную строку "ПОДПИСЬ НЕКОРРЕКТНА" на символьную строку "ПОДПИСЬ КОРРЕКТНА". В результате вообще перестали фиксироваться документы с неверными цифровыми подписями, и, следовательно, в электронные документы стало можно вносить произвольные изменения уже после их подписания электронной цифровой подписью.
Возможность генерации одинаковой хэш-функции для двух различных документов. Такое событие называется "коллизией" и надежный алгоритм хэш-функции должен противостоять такого рода "неприятностям".
Главным условием правильного функционирования компьютерной системы является обеспечение защиты от вмешательства в процесс обработки информации тех программ, присутствие которых в компьютерной системе не обязательно. Среди подобных программ, в первую очередь, следует упомянуть компьютерные вирусы. Однако имеются вредоносные программы еще одного класса. От них, как и от вирусов, следует с особой тщательностью очищать свои компьютерные системы. Это так называемые программные закладки
, которые могут выполнять хотя бы одно из перечисленных ниже действий:
- Вносить произвольные искажения в коды программ, находящихся в оперативной памяти компьютера (программная закладка первого типа);
- Переносить фрагменты информации из одних областей оперативной или внешней памяти компьютера в другие (программная закладка второго типа);
- Искажать выводимую на внешние компьютерные устройства или канал связи информацию, полученную в результате работы других программ (программная закладка третьего типа).
Существуют 4 основных способа воздействия программных закладок на цифровую подпись:
- искажение входной информации (изменяется поступающий на подпись электронный документ);
- искажение результата проверки истинности цифровой подписи (вне зависимости от результатов работы программы цифровая подпись объявляется подлинной);
- навязывание длины электронного документа (программе цифровой подписи предъявляется документ меньшей длины, чем на самом деле, и в результате цифровая подпись ставится только под частью исходною документа);
- искажение программы цифровой подписи (вносятся изменения в исполняемый код программы с целью модификации реализованного алгоритма).
Поскольку давать конкретные оценки возможностей потенциальных мозговых ресурсов взломщика системы цифровой подписи - дело весьма сложное и неблагодарное, мы будем просто исходить из предположения, что он располагает полной информацией о наилучших известных мировой науке методах решения данной задачи.
Далее, если взломщик располагает вычислительной системой общей мощностью, скажем, 1 миллиард (109
) операций в секунду, а это мощность современного суперкомпьютера типа Cray-3, то
- за сутки непрерывной работы такой системы может быть решена задача сложностью около 100 триллионов (или 1014
) операций,
- за месяц - около 3.1015
,
- за год - около 3.1016
,
- за десять лет - около 3.1017
,
- за тридцать лет - около 1018
операций.
Таким образом, даже если допустить, что потенциальный взломщик цифровой подписи располагает вычислительной системой, эквивалентной по мощности тысяче (103
) суперкомпьютеров типа Cray-3, на выполнение вычислений объемом 1021
операций ему потребовалось бы не менее тридцати лет непрерывной работы системы, а значит, цифровая подпись с надежностью не менее 1021
может считаться практически неподделываемой.
В этом месте автору обычно задают вопрос: "А что, если специальным службам известны более быстрые методы решения задачи фальсификации цифровых подписей?"
В настоящее время ответ на него оказывается довольно простым. Если вы боитесь, что обычно предлагаемого при длине ключей 64 байта запаса надежности в 1018
-1021
недостаточно, применяйте алгоритмы с более длинными ключами. Современные процессоры класса Intel 486 и Pentium позволяют за доли секунды вычислять и проверять цифровые подписи с ключами длиной до 512 байт, а стойкость большинства широко применяемых методов цифровой подписи при такой длине ключей заведомо превосходит все разумные требования (более чем 1050
).
Итак, мы видим, что современные общепризнанные принципы построения системы цифровой подписи просты и изящны:
- методы вычисления и проверки цифровых подписей всех пользователей системы одинаковы, всем известны и основываются на широко известных математических задачах,
- методы вычисления ключей проверки цифровых подписей из индивидуальных ключей подписывания одинаковы для всех и хорошо известны, их надежность также основывается на широко известных математических задачах,
- индивидуальные ключи подписывания выбираются самими пользователями по случайному закону из множества всех возможных ключей,
- при конкретном алгоритме цифровой подписи его стойкость может быть оценена без привлечения какой-либо "закрытой" информации на основе только известных математических результатов и разумных допущений о вычислительных мощностях потенциального взломщика, поскольку она базируется на общедоступных теоретических результатах по оценке сложности широко известных вычислительных задач.
Можно ли подделать ЭЦП?
При правильном хранении закрытого ключа его владельцем – нет. Выполняйте рекомендации по хранению и использованию ключа, содержащиеся в документации к клиентскому комплекту – и вы будете гарантированы от подделки вашей ЭЦП. На сегодняшний день на Земле не существует вычислительных мощностей, способных в сколько-нибудь приемлемые сроки взломать криптографию ЭЦП, и в ближайшие десятилетия это будет также невозможно.
В 1995 году был принят Федеральный Закон "Об информации, информатизации и защите информации". В пункте 3 статьи 5 говорится, что юридическая сила документа может подтверждаться электронной цифровой подписью. При этом "юридическая сила электронной цифровой подписи признается при наличии в автоматизированной информационной системе программно-технических средств, обеспечивающих идентификацию подписи установленного режима их использования"
. Однако "право удостоверять идентичность электронной цифровой подписи осуществляется на основании лицензии"
(п.4).
Как показывает практика, алгоритмы с открытым ключом очень неэффективны из-за низкой скорости обработки большого объема данных. Для уменьшения времени на генерацию и проверку подписи, а также для сокращения ее размера применяется специальный механизм, называемый хэш-функцией (hash function), который является отображением подписываемого сообщения в строку фиксированной длины, много меньшей размера самого сообщения. Вместо подписи самого документа подписывается хэш-функция этого документа. Аналогичным образом проверяется подпись не самого документа, а его хэш-функции.
Стандарты
ГОСТ 34.10.
Стандарт на электронную подпись ГОСТ 34.10 был опубликован Госстандартом РФ в мае 1994 года и вступил в действие с 1 января 1995 года. В предварительном варианте он был введен как ведомственный стандарт на цифровую подпись ЦБ РФ и использовался в этом качестве с сентября 1993 года по декабрь 1994 года. Алгоритмы вычисления и проверки подписи в ГОСТ 34.10 устроены аналогично алгоритму DSA, но хэширование выполняется другим, существенно более медленным способом. К сожалению, разработчики допустили целый ряд ошибок, которые есть даже в официальном тексте стандарта. Поэтому при реализации следует быть внимательным и не всегда следовать формальному тексту.
В России в 1994 году были приняты стандарты ГОСТ Р 34.10-94 "Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.11-94 " Криптографическая защита информации. Функция хэширования". Чем могут помочь пользователю данные стандарты? Во-первых,
они должны гарантировать криптостойкость, т.е. надежность реализованных по ним алгоритмов. Во-вторых,
применение стандартов должно обеспечить совместимость продуктов различных производителей. Однако есть и проблемы при использовании принятых стандартов.
Стандарты ГОСТ Р 34.10-94
и ГОСТ Р 34.11-94
описывают лишь процедуры выработки и проверки ЭЦП и хэш-функции. За пределами их рассмотрения остается такой важный вопрос, как распространение и генерация ключей, защита от несанкционированного доступа к ключевой информации и т.д. Поэтому зачастую продукты, реализующие один и тот же стандарт, несовместимы между собой. На российском рынке средств защиты информации существует несколько известных систем, в которых реализованы указанные стандарты (Верба-О, Криптон и т.д.), но между собой эти системы не совместимы.
Как уже отмечалось, использование стандарта должно гарантировать, что документы, подписанные при помощи ГОСТ Р 34.10-94, теоретически не могут быть подделаны за приемлемое для злоумышленника время. Однако на практике дело не всегда обстоит таким образом. Связано это с тем, что стандарт описывает алгоритм математическим языком, в то время как пользователи сталкиваются уже с его реализацией. А при реализации могут быть допущены различные ошибки, которые сводят на нет все достоинства алгоритма. Кроме того, эффективное применение систем ЭЦП зависит от их правильной эксплуатации. Например, хранение секретных ключей для генерации цифровой подписи на доступном всем жестком диске позволяет злоумышленнику получить к ним доступ и в дальнейшем подделывать документы, подписанные на этих ключах.
Поэтому далеко не всегда указанные системы обеспечивают необходимый уровень защищенности.
З А К Л Ю Ч Е Н И Е
Курсовая работа может быть полезна при изучение курсов связанных с ЭВМ, она окажется полезной для специалистов, сталкивающихся в своей работе с кодированием информации на ЭВМ.
В результате выполнения данной курсовой работы я узнал много нового касающегося как программирования, так и методов кодирования информации. Работа была очень интересной, хотя временами и возникали некоторые трудности.
Описанные в данной курсовой работе аспекты показывают, что выбор системы электронной цифровой подписи - непростая задача, решению которой необходимо уделить серьезное внимание. Не существует готовых рецептов. Правильный выбор - это не просто просмотр рекламных буклетов, полученных на выставке, или ознакомление с Web-сервером поставщика системы ЭЦП. Это кропотливый процесс, в котором должно учитываться множество факторов. Это и необходимость интеграции в принятую технологию обработки информации, и необходимость наличия сертификата ФАПСИ, и алгоритм распределения ключей, и т.д.
Выполнение данной курсовой работы закрепило теоретические знания по данной дисциплине, способствовало приобретению навыков формализации и составления алгоритмов решения криптографических задач, а также дало опыт практического решения криптографических задач, что являлось ее целью.
Сделайте правильный выбор - и Ваша информация будет надежно защищена от подделки.
Список использованной литературы
1.
Б. Анин «Защита компьютерной информации», Санкт-Петербург, 2000
2.
Брюс Шнайер. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на Си. – М.: Издательство ТРИУМФ, 2002.
3.
Ю. Мельников. Электронная цифровая подпись: всегда ли она подлинная? Банковские технологии, №5, 1995.
4.
http://www.kinnet.ru
5.
http://www.citforum.ru
6.
http://kiev-security.org.ua
7.
http://www.study.centersti.com
Приложение к курсовой работе
ПРОГРАММА РЕАЛИЗАЦИИ АЛГОРИТМА RSA
Файл FGIntPrimeGeneration.PAS
Unit FGIntPrimeGeneration;
Interface
Uses Windows, SysUtils, Controls, FGInt;
Procedure PrimeSearch(Var GInt : TFGInt);
Implementation
{$H+}
Procedure PrimeSearch(Var GInt : TFGInt);
Var
temp, two : TFGInt;
ok : Boolean;
Begin
If (GInt.Number[1] Mod 2) = 0 Then GInt.Number[1] := GInt.Number[1] + 1;
Base10StringToFGInt('2', two);
ok := false;
While Not ok Do
Begin
FGIntAdd(GInt, two, temp);
FGIntCopy(temp, GInt);
FGIntPrimeTest(GInt, 4, ok);
End;
FGIntDestroy(two);
End;
End.
Файл FGIntRSA.PAS
Unit FGIntRSA;
Interface
Uses Windows, SysUtils, Controls, FGInt;
Procedure RSAEncrypt(P : String; Var exp, modb : TFGInt; Var E : String);
Procedure RSADecrypt(E : String; Var exp, modb, d_p, d_q, p, q : TFGInt; Var D : String);
Procedure RSASign(M : String; Var d, n, dp, dq, p, q : TFGInt; Var S : String);
Procedure RSAVerify(M, S : String; Var e, n : TFGInt; Var valid : boolean);
Implementation
{$H+}
Procedure RSAEncrypt(P : String; Var exp, modb : TFGInt; Var E : String);
Var
i, j, modbits : longint;
PGInt, temp, zero : TFGInt;
tempstr1, tempstr2, tempstr3 : String;
Begin
Base2StringToFGInt('0', zero);
FGIntToBase2String(modb, tempstr1);
modbits := length(tempstr1);
convertBase256to2(P, tempstr1);
tempstr1 := '111' + tempstr1;
j := modbits - 1;
While (length(tempstr1) Mod j) <> 0 Do tempstr1 := '0' + tempstr1;
j := length(tempstr1) Div (modbits - 1);
tempstr2 := '';
For i := 1 To j Do
Begin
tempstr3 := copy(tempstr1, 1, modbits - 1);
While (copy(tempstr3, 1, 1) = '0') And (length(tempstr3) > 1) Do delete(tempstr3, 1, 1);
Base2StringToFGInt(tempstr3, PGInt);
delete(tempstr1, 1, modbits - 1);
If tempstr3 = '0' Then FGIntCopy(zero, temp) Else FGIntMontgomeryModExp(PGInt, exp, modb, temp);
FGIntDestroy(PGInt);
tempstr3 := '';
FGIntToBase2String(temp, tempstr3);
While (length(tempstr3) Mod modbits) <> 0 Do tempstr3 := '0' + tempstr3;
tempstr2 := tempstr2 + tempstr3;
FGIntdestroy(temp);
End;
While (tempstr2[1] = '0') And (length(tempstr2) > 1) Do delete(tempstr2, 1, 1);
ConvertBase2To256(tempstr2, E);
FGIntDestroy(zero);
End;
Procedure RSADecrypt(E : String; Var exp, modb, d_p, d_q, p, q : TFGInt; Var D : String);
Var
i, j, modbits : longint;
EGInt, temp, temp1, temp2, temp3, ppinvq, qqinvp, zero : TFGInt;
tempstr1, tempstr2, tempstr3 : String;
Begin
Base2StringToFGInt('0', zero);
FGIntToBase2String(modb, tempstr1);
modbits := length(tempstr1);
convertBase256to2(E, tempstr1);
While copy(tempstr1, 1, 1) = '0' Do delete(tempstr1, 1, 1);
While (length(tempstr1) Mod modbits) <> 0 Do tempstr1 := '0' + tempstr1;
If exp.Number = Nil Then
Begin
FGIntModInv(q, p, temp1);
FGIntMul(q, temp1, qqinvp);
FGIntDestroy(temp1);
FGIntModInv(p, q, temp1);
FGIntMul(p, temp1, ppinvq);
FGIntDestroy(temp1);
End;
j := length(tempstr1) Div modbits;
tempstr2 := '';
For i := 1 To j Do
Begin
tempstr3 := copy(tempstr1, 1, modbits);
While (copy(tempstr3, 1, 1) = '0') And (length(tempstr3) > 1) Do delete(tempstr3, 1, 1);
Base2StringToFGInt(tempstr3, EGInt);
delete(tempstr1, 1, modbits);
If tempstr3 = '0' Then FGIntCopy(zero, temp) Else
Begin
If exp.Number <> Nil Then FGIntMontgomeryModExp(EGInt, exp, modb, temp) Else
Begin
FGIntMontgomeryModExp(EGInt, d_p, p, temp1);
FGIntMul(temp1, qqinvp, temp3);
FGIntCopy(temp3, temp1);
FGIntMontgomeryModExp(EGInt, d_q, q, temp2);
FGIntMul(temp2, ppinvq, temp3);
FGIntCopy(temp3, temp2);
FGIntAddMod(temp1, temp2, modb, temp);
FGIntDestroy(temp1);
FGIntDestroy(temp2);
End;
End;
FGIntDestroy(EGInt);
tempstr3 := '';
FGIntToBase2String(temp, tempstr3);
While (length(tempstr3) Mod (modbits - 1)) <> 0 Do tempstr3 := '0' + tempstr3;
tempstr2 := tempstr2 + tempstr3;
FGIntdestroy(temp);
End;
If exp.Number = Nil Then
Begin
FGIntDestroy(ppinvq);
FGIntDestroy(qqinvp);
End;
While (Not (copy(tempstr2, 1, 3) = '111')) And (length(tempstr2) > 3) Do delete(tempstr2, 1, 1);
delete(tempstr2, 1, 3);
ConvertBase2To256(tempstr2, D);
FGIntDestroy(zero);
End;
Procedure RSASign(M : String; Var d, n, dp, dq, p, q : TFGInt; Var S : String);
Var
MGInt, SGInt, temp, temp1, temp2, temp3, ppinvq, qqinvp : TFGInt;
Begin
Base256StringToFGInt(M, MGInt);
If d.Number <> Nil Then FGIntMontgomeryModExp(MGInt, d, n, SGInt) Else
Begin
FGIntModInv(p, q, temp);
FGIntMul(p, temp, ppinvq);
FGIntDestroy(temp);
FGIntModInv(q, p, temp);
FGIntMul(q, temp, qqinvp);
FGIntDestroy(temp);
FGIntMontgomeryModExp(MGInt, dp, p, temp1);
FGIntMul(temp1, qqinvp, temp2);
FGIntCopy(temp2, temp1);
FGIntMontgomeryModExp(MGInt, dq, q, temp2);
FGIntMul(temp2, ppinvq, temp3);
FGIntCopy(temp3, temp2);
FGIntAddMod(temp1, temp2, n, SGInt);
FGIntDestroy(temp1);
FGIntDestroy(temp2);
FGIntDestroy(ppinvq);
FGIntDestroy(qqinvp);
End;
FGIntToBase256String(SGInt, S);
FGIntDestroy(MGInt);
FGIntDestroy(SGInt);
End;
Procedure RSAVerify(M, S : String; Var e, n : TFGInt; Var valid : boolean);
Var
MGInt, SGInt, temp : TFGInt;
Begin
Base256StringToFGInt(S, SGInt);
Base256StringToFGInt(M, MGInt);
FGIntMod(MGInt, n, temp);
FGIntCopy(temp, MGInt);
FGIntMontgomeryModExp(SGInt, e, n, temp);
FGIntCopy(temp, SGInt);
valid := (FGIntCompareAbs(SGInt, MGInt) = Eq);
FGIntDestroy(SGInt);
FGIntDestroy(MGInt);
End;
End.
Файл Unit1.pas
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs,
FGInt, FGIntPrimeGeneration, FGIntRSA, StdCtrls;
type
TForm1 = class(TForm)
Edit1: TEdit;
Label1: TLabel;
CheckBox1: TCheckBox;
Label2: TLabel;
Edit2: TEdit;
CheckBox2: TCheckBox;
Button1: TButton;
Label3: TLabel;
Label4: TLabel;
Label5: TLabel;
Label6: TLabel;
Label7: TLabel;
Label8: TLabel;
Label9: TLabel;
Label10: TLabel;
Label11: TLabel;
Label12: TLabel;
Edit3: TEdit;
Label13: TLabel;
Button2: TButton;
Label14: TLabel;
Label15: TLabel;
Label16: TLabel;
Label17: TLabel;
Button3: TButton;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
n, e, d, dp, dq, p, q, phi, one, two, gcd, temp, nilgint : TFGInt;
test, signature : String;
ok : boolean;
st: string;
tx: text;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject);
begin
if CheckBox1.Checked then
Base10StringToFGInt(Edit1.Text, p) else
Base256StringToFGInt(Edit1.Text, p);
if CheckBox2.Checked then
Base10StringToFGInt(Edit2.Text, q) else
Base256StringToFGInt(Edit2.Text, q);
PrimeSearch(p);
PrimeSearch(q);
if CheckBox1.Checked then
FGIntToBase10String(p, st) else
FGIntToBase256String(p, st);
Edit1.Text:=st;
if CheckBox2.Checked then
FGIntToBase10String(q, st) else
FGIntToBase256String(q, st);
Edit2.Text:=st;
FGIntMul(p, q, n);
p.Number[1] := p.Number[1] - 1;
q.Number[1] := q.Number[1] - 1;
FGIntMul(p, q, phi);
FGIntToBase10String(n, st);
Label5.Caption:=st;
FGIntToBase10String(phi, st);
Label6.Caption:=st;
Base10StringToFGInt('14486581214143', e);
Base10StringToFGInt('1', one);
Base10StringToFGInt('2', two);
FGIntGCD(phi, e, gcd);
While FGIntCompareAbs(gcd, one) <> Eq Do
Begin
FGIntadd(e, two, temp);
FGIntCopy(temp, e);
FGIntGCD(phi, e, gcd);
End;
FGIntDestroy(two);
FGIntDestroy(one);
FGIntDestroy(gcd);
FGIntModInv(e, phi, d);
FGIntModInv(e, p, dp);
FGIntModInv(e, q, dq);
p.Number[1] := p.Number[1] + 1;
q.Number[1] := q.Number[1] + 1;
FGIntDestroy(phi);
FGIntDestroy(nilgint);
FGIntToBase256String(e, st);
Label8.Caption:=st;
FGIntToBase10String(d, st);
Label10.Caption:=st;
end;
procedure TForm1.Button2Click(Sender: TObject);
var prom: string;
begin
test := Edit3.Text;
RSAEncrypt(test, e, n, test);
Label11.Caption:=test;
PGPConvertBase256to64(test,prom);
Label17.Caption:=prom;
RSADecrypt(test, d, n, Nilgint, Nilgint, Nilgint, Nilgint, test);
Label12.Caption:=test;
end;
procedure TForm1.Button3Click(Sender: TObject);
begin
AssignFile(tx,'key.txt');
ReWrite(tx); CloseFile(tx);
Append(tx);
FGIntToBase256String(n, st);
ConvertBase256to64(st, st);
WriteLn(tx,st);
FGIntToBase256String(e, st);
ConvertBase256to64(st, st);
WriteLn(tx,st);
FGIntToBase256String(d, st);
ConvertBase256to64(st, st);
WriteLn(tx,st);
CloseFile(tx);
end;
end.
Результат выполнения программы: