Все возможные сферы применения ЭП приведены в таблице.

Рис. 13.2. Сферы применения электронной подписи

Начнем рассматривать с самых распространенных на данный момент.

1. Электронный документооборот. Технология ЭП широко используется в системах электронного документооборота различного назначения: внешнего и внутреннего обмена, организационно-распорядительного, кадрового, законотворческого, торгово-промышленного и прочего. Это продиктовано главным свойством электронной подписи – она может быть использована в качестве аналога собственноручной подписи и/или печати на бумажном документе. Во внутреннем документообороте ЭП используется, как средство визирования и утверждения электронных документов в рамках внутренних процессов. Например, во время согласования договора директор подписывает его ЭП, что значит, что договор утвержден и может быть передан в исполнение. При построении межкорпоративного документооборота ( B2 B) наличие ЭП является критически важным условием обмена, поскольку является гарантом юридической силы. Только в этом случае электронный документ может быть признан подлинным и использоваться в качестве доказательства в судебных разбирательствах. Подписанный усиленной электронной подписью документ также может длительное время храниться в цифровом архиве, сохраняя при этом свою легитимность.

2. Электронная отчетность для контролирующих органов. Многие компании, наверняка, уже оценили удобство сдачи отчетности в электронном виде. Современный подход к сдаче отчетности через интернет состоит в том, что клиент может выбрать любой удобный для себя способ: отдельное ПО, продукты семейства 1C, порталы ФНС, ФСС. Основа этой услуги –сертификат электронной подписи, который должен быть выпущен надежным удостоверяющим центром, метод же отправки не имеет решающего значения. Такая подпись нужна для придания документам юридической значимости.

3. Государственные услуги. Каждый гражданин Российской Федерации может получить электронную подпись для получения госуслуг. С помощью ЭП гражданин может заверять документы и заявления, отправляемые в ведомства в электронном виде, а так же получать подписанные письма и уведомления о том, что обращение принято на рассмотрение от соответствующих органов власти.
Пользователь имеет возможность подписать электронной подписью заявление, отправляемое в орган исполнительной власти (при готовности органа исполнительной власти принимать заявления, подписанные электронной подписью). При реализации этого механизма используются отечественные стандарты ЭП (ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001) и применяются сертифицированные в системе сертификации ФСБ России средства криптографической защиты информации, такие как «Aladdin e-Token ГОСТ» и «КриптоПро CSP», что дает основания считать данную подпись усиленной квалифицированной электронной подписью (Источник: портал Госуслуги). С 1 января 2013 года гражданам выдается универсальная электронная карта, в которую встроена усиленная квалифицированная электронная подпись. Универсальная электронная карта (УЭК) – пластиковая карта, представляющая собой уникальное идентификационное средство гражданина. Основное предназначение УЭК - дистанционный заказ, оплата и получение государственных услуг. В идеале карта заменяет множество документов, в том числе медицинский полис и страховое пенсионное свидетельство, объединяя идентификационную карту, электронный кошелёк с привязкой к банковскому счету, электронную подпись и даже проездной билет.

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

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

6. Документооборот с физическими лицами. Надо признать, данная сфера применения ЭП весьма специфична и пока редко используема, тем не менее, возможна. С помощью ЭП заверять различные документы могут физические лица. Благодаря этой возможности удаленные работники на основании договоров оказания услуг, например, могут выставлять акты приемки-сдачи работ в электронном виде.

Механизм ЭП

Обратимся непосредственно к механизму ЭП. Наибольшее распространение получили алгоритмы с использованием открытого ключа.

ЭП решает 2 задачи: определение авторства и неизменности документа. Существует множество алгоритмов, но все они направлены на их решение и имеют общую суть.

Предположим, что мы имеем сообщение M, открытый ключ K, закрытый ключ k и функцию f() с обратной ей F().

Рассмотрим механизм подписи.

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

Подписание происходит следующим образом:

¾ для данных вычисляется значение хеш-функции h=H(M),

¾ затем это значение шифруется с помощью закрытого ключа s=f(h,k).

Значение s и будет являться ЭП для сообщения M.

Для проверки подписи производятся следующие вычисления:

¾ вычисляется значение хеша для сообщения h=H(M),

¾ после чего с помощью открытого ключа расшифровывается значение s h’=F(s,K).

Если h’ = h, то подпись верна. В противном случае возможны 2 варианта: использовался неверный открытый ключ (то есть, авторство не определено) или сообщение было искажено.

То же самое, но в картинках:

Рис. 13.3. Схема подписания электронного документа и схема проверки электронной подписи

Зачем нужен сертификат?

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

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

1. Мы не знаем, кто сделал данную подпись

2. Мы не знаем, когда была сделана подпись

3. Сама подпись не защищена от подмены никак.

4. Хэш функций много, какая из них использовалась для создания этого конкретного хэша?

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

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

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

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

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

Приведем аналогию. У Вас есть отличный замок и два ключа к нему. Один ключ замок открывает (открытый), второй — закрывает (закрытый). Вы берете коробочку, кладете в нее какую-то вещь и закрываете ее своим замком. Так, как вы хотите, чтобы закрытую вашим замком коробочку открыл ее получатель, то вы открытый, открывающий замок, ключик спокойно отдаете ему. Но вы не хотите, чтобы вашим замком кто-то закрывал коробочку заново, ведь это ваш личный замок, и все знают, что он именно ваш. Поэтому закрывающий ключик вы всегда держите при себе, чтобы кто-нибудь не положил в вашу коробочку нечто иное и не говорил потом, что это вы это иное туда положили и закрыли своим замком.

И все бы хорошо, но тут сразу же возникает проблема, а, на самом деле, даже не одна.

1. Надо как-то передать наш открытый ключ, при этом его должна понять принимающая сторона.

2. Надо как-то связать этот открытый ключ с нами, чтобы нельзя было его присвоить.

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

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

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

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

Продолжая нашу аналогию с красивым замком (замок с двумя ключами, один – открывающий, другой - закрывающий), мы пишем на ключе «Этот ключ открывает замок В. Пупкина». А на замке тоже пишем «Замок В. Пупкина». Имея такую информацию, получатель нашей закрытой коробочки не будет каждый из имеющихся у него ключей вставлять наугад в наш замок, а возьмет наш ключ и сразу его откроет.

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

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

Рис. 13.4. Содержимое сертификата и контейнера цифровой подписи

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

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

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

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

Как мы видим, функции подписи, определенные в начале, выполняются. Но тут возникает следующий вопрос, кто гарантирует, что открытый ключ не был подменен при распространении (для тех, кто понимает, атака Man In The Middle) и мы общаемся с тем кем хотим, а не со злоумышленником, выдающим себя за другого? Ответ напрашивается сам – нам нужен некий авторитет, гарантирующий принадлежность ключей, и механизм их распространения. Данное решение было реализовано в виде инфраструктуры открытых ключей и сертификатов удостоверяющих центров. Тогда с сообщением передается не только подпись, но и сертификат, удостоверяющий её.

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

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

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

При этом Иван получает сертификат открытого ключа Семена, заверенный УЦ, а Семен – Ивана. Без этого их доверительное взаимодействие невозможно. Для обеспечения взаимного доверия между пользователями разных УЦ последние объединяются в иерархическую структуру:

Кроме того, УЦ1 и УЦ2 могут организовать взаимное доверие и обойтись без корневого УЦ.

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

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

¾ серийный номер сертификата;

¾ объектный идентификатор алгоритма электронной подписи;

¾ имя удостоверяющего центра;

¾ срок действия сертификата;

¾ имя владельца сертификата (имя пользователя, которому принадлежит сертификат);

¾ открытые ключи владельца сертификата (ключей может быть несколько);

¾ объектные идентификаторы алгоритмов, ассоциированных с открытыми ключами владельца сертификата;

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

Понятие «Проверка подписи» подразумевает проверку соответствия подписи документу, который подписан этой подписью. Если подпись соответствует документу, документ считается подлинным и корректным.

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

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

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

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

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

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