Электронно-цифровая подпись

Санкт-Петербургский  Политехнический Государственный Университет

 

 

Факультет технической  кибернетики

Кафедра ИУС

 

 

 

 

 

 

 

 

 

Методы  и средства защиты КИ

Курсовая  работа по теме «Электронно-цифровая подпись»

 

 

 

 

 

 

 

 

 

 

Работу выполнил:

Капецкий Е.А.

Группа № 4084/11

 

Преподаватель:

 Медведев Г.А.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Санкт –  Петербург

2012

Введение

 

Итак, все чаще в кругах, работающих с документами все чаще звучат слова «электронный документ» и, связанное с ним почти неразрывно «электронная цифровая подпись», иначе — ЭЦП.

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

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

  Зачем нам вообще что-то подписывать?  Естественно, чтобы удостоверить, что мы ознакомились с содержимым, согласны (а иногда наоборот, не  согласны) с ним. А электронная  подпись еще и защищает наше  содержимое от подмены.

О сущности электронной подписи

 

В самом примитивном случае электронная  цифровая подпись. — результат хэш-функции. Что это такое лучше меня разъяснит википедиа, в нашем же случае главное, что с высокой степенью вероятности ее результат не повторяется для разных исходных данных, а также что результат этой функции мало того, что короче исходных данных, так еще по нему исходную информацию восстановить нельзя. Результат функции называют хэшем, а применение этой функции к данным называют хешированием. Грубо, можно назвать хэш функцию архивированием, в результате чего мы получаем очень маленькую последовательность байт, но восстановить исходные данные из такого «архива» нельзя.

  Итак, мы читаем файлик в память, хэшируем прочитанное. И что, уже получаем ЭЦП? Почти. Наш результат с большой натяжкой можно назвать подписью, но, все же, полноценной подписью он не является, потому что:

• Мы не знаем, кто сделал данную подпись
• Мы не знаем, когда была сделана подпись
• Сама подпись не защищена от подмены никак.
• Ну и да, хэш функций много, какая из них использовалась для создания этого конкретного хэша?

 

  Поэтому применять к хэшу слово «подпись» еще нехорошо, будем называть его дальше просто хэш.

  Вы посылаете ваш файл другому  человеку, допустим, по почте, будучи  уверенными, что он точно получит  и прочитает именно то, что  вы послали. Он же, в свою  очередь, тоже должен хэшировать ваши данные и сравнить свой результат с вашим. Если они совпали — все хорошо. Это значит что данные защищены? Нет.

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

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

  Но, пойдем дальше. Нам хочется  защитить наш результат хеширования  от подмены, чтобы каждый встречный  не мог утверждать, что это  у него правильный результат.  Для этого самое очевидное  что (помимо мер административного  характера)? Правильно, зашифровать.  А ведь с помощью шифрования  же можно и удостоверить личность  того, кто хэшировал данные! И сделать это сравнительно просто, ведь есть ассиметричное шифрование. Да, оно медленное и тяжелое, но ведь нам всего-то и надо — зашифровать маленькую последовательность байт. Плюсы такого действия очевидны — для того, чтобы проверить нашу подпись, надо будет иметь наш открытый ключ, по которому личность зашифровавшего (а значит, и создавшего хэш) можно легко установить.

  Суть этого шифрования в следующем:  у вас есть закрытый ключ, который  вы храните у себя. И есть  открытый ключ. Открытый ключ  вы можете всем показывать  и раздавать, а закрытый —  нет. Шифрование происходит с  помощью закрытого ключа, а  расшифровывание — с помощью  открытого.

Есть несколько путей  реализации шифрования:

• На основе алгоритмов симметричного шифрования. Данная схема предусматривает наличие в системе третьего лица — арбитра, пользующегося доверием обеих сторон. Авторизацией документа является сам факт зашифрования его секретным ключом и передача его арбитру.[
• На основе алгоритмов асимметричного шифрования. На данный момент такие схемы ЭП наиболее распространены и находят широкое применение.

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

Проблемы  в использовании цифровых подписей

 

  На основе вышеизложенного, можно увидеть что,  тут сразу же возникает проблема, а, на самом деле, даже не одна.

• Надо как-то передать наш открытый ключ, при этом его должна понять принимающая сторона.
• Надо как-то связать этот открытый ключ с нами, чтобы нельзя было его присвоить.
• Мало того, что ключ надо связать с нами, надо еще и понять, какой зашифрованный хэш каким ключом расшифровывать. А если хэш не один, а их, скажем, сто? Хранить отдельный реестр — очень тяжелая задача.

 

  Все это приводит нас к тому, что и закрытый ключ, и наш  хэш надо хранить в каких-то форматах, которые нужно стандартизировать, распространить как можно шире и уже тогда использовать, чтобы у отправителя и получателя не возникало «трудностей перевода». На текущий момент у этой трудности есть два параллельных решения: формат OpenPGP и формат S/MIME + X.509.

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

Информация  необходимая для верификации  и проверки подписей

 

  Начнем с простого: информация, которая позволит нам узнать, кто же сделал эту подпись. Как мы уже договорились, ассиметричное шифрование позволяет однозначно связать наш открытый ключ и полученную подпись. Беда в том, что сам по себе открытый ключ – набор байт. При этом он, конечно, связан с закрытым, которым мы (то есть отправитель) владеем, но связь эта для получателя неочевидна. У него есть набор байт от В. Пупкина, от И. Петрова, от С. Сидорова… И от десятка других людей. И как ему их идентифицировать? Держать отдельный реестр для того, кому какой набор байт принадлежит? Это что же, получается уже второй реестр (помимо того, где должно быть записано, с помощью какой хэш-функции какой хэш сделан)! И опять, неудобно!

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

  Но эту информацию все так  же надо связать с подписью, пришедшей получателю. Как это  сделать? Надо соорудить еще  один контейнер, на сей раз  для передачи подписи, и в  нем продублировать информацию  о том, кто эту подпись создавал.

Остается  проблема, как донести до получателя информацию о том, какая хэш-функция применялась для хэша, а ведь для проверки подписи эта информация необходима! Решить ее можно достаточно просто: положить эту информацию в контейнер вместе с нашим открытым ключом. Ведь именно связка «хэширование – шифрование результата хеширования» считается процедурой создания цифровой подписи, а ее результат – подписью. А значит, достаточно логичным представляется объединение в связку алгоритма шифрования хэша и хэш-функции, с помощью которой он сформирован. И доставлять эту информацию тоже надо в связке.

  Теперь, ненадолго вернемся к  информации о подписывающем. Какого рода эта информация должна быть? ФИО? Нет, В. Пупкиных много. ФИО + год рождения? Так и родившихся в один день В. Пупкиных тоже предостаточно! Более того, это может быть Василий, Виктор, или даже Василиса или Виктория Пупкины. Значит, информации должно быть больше. Ее должно быть столько, чтобы совпадение всех параметров, по которым мы идентифицируем человека, было максимально невероятным.

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

  Чтобы понять, в чем же оно  заключалось, обратимся к бумажному  документу, который есть у всех  нас: к паспорту. В нем можно  найти и ФИО, и дату рождения, и пол, и много другой информации. Но, главное, в нем можно найти  серию и номер. И именно серия  и номер являются той уникальной  информацией, которую удобно учитывать  и сортировать. Кроме того, они  существенно короче всей оставшейся  информации вместе взятой, и при  этом все так же позволяют  опознать человека.

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

О существующих решениях

 

  Вот здесь и начинаются принципиальные  различия в идеологиях OpenPGP и S/MIME + X.509. Для краткого понимания их, вернемся к нашей аналогии с паспортом.

  Паспорт вы можете использовать  при покупках билетов, при оформлении  документов, для выдачи пропуска  на какую-либо территорию и  даже на территории других  стран! То есть, вы используете  его для идентификации вашей  личности в самых различных,  зачастую абсолютно не связанных  друг с другом, местах, с самыми  различными людьми. И везде ваш  паспорт принимают. Гарантом того, что вы – это вы выступает  третья сторона в ваших взаимоотношениях  с другими: государство. Именно  оно выдало вам ваш паспорт,  специально оформленный, подписанный  и заверенный, и именно поэтому  ваш паспорт является таким  универсальным документом.

  С другой стороны, в кругу  друзей, или внутри компании вам  достаточно представиться так:  «В. Пупкин из твоей группы в институте» или же «В. Пупкин из отдела продаж». И людям, с которыми вы контактируете в этом кругу уже не нужна третья сторона, они и так помнят Пупкина из группы с которым проучились пять лет, или Пупкина из отдела продаж, с которым недавно ходили обедать, и предоставленной вами информации им вполне достаточно.

  Так же можно разделить и эти два лагеря:

  Сертификат X.509 – это аналог нашего  паспорта. Здесь сертификаты вам  выдаются суровой третьей стороной, гарантом вашей личности: Удостоверяющим  Центром (УЦ). Получающий ваши  подписи человек всегда может  обратиться в УЦ и спросить  интересующую его информацию  по вот этому конкретному сертификату.

PGP же (и стандарт OpenPGP, появившийся в дальнейшем) создавался на основе так называемых сетей доверия. Такая идея подразумевает, что обмениваются подписями люди, которым третья сторона для их взаимоотношений не нужна, а нужна только защита от нехороших лиц.

  Конечно, с течением времени  такое разделение стало уже  достаточно условным, так как  на данный момент и в S/MIME+X.509 и в PGP можно использовать методы  лагеря соперников. Но все же, стандарты достаточно продолжительное  время развивались параллельно  и развились до той степени,  что взаимная совместимость между  ними стала невозможной.

  Более популярным стандартном, в силу своей ориентированности на участие более компетентной третьей стороны, стал стандарт S/MIME + X.509, однако и у PGP есть некоторое количество козырей за пазухой, с помощью которых он не только не погибает, но и продолжает успешно развиваться.