Электронная цифровая подпись для чайников: с чем ее есть, и как не подавиться.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как водится у людей, к чему-то единому прийти так и не смогли, и образовалось два больших лагеря — формат OpenPGP и формат S/MIME + X.509.

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

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

Каждую из частей информации можно передать вместе с открытым ключом, или вместе с нашей подписью, а можно и с тем и с тем, для большего удобства. Конечно, можно не разделять информацию на передаваемую с открытым ключом и передаваемую с подписью. Но тогда каждый раз отправляя подписанную информацию мы отправляем одно и то же. Как если бы к каждому отправляемому нами бумажному письму (даже короткому, в две строки), мы бы прикладывали дополнение вида «Здравствуйте! Это я, В. Пупкин, которого вы встречали на Красной площади Москвы, где мы и познакомились, потом пошли в ресторан, потом <…>». Согласитесь, слегка неудобно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

А почему бы не сделать так, чтобы способ шифрования был сразу известен всем, но расшифровать наши данные было бы нельзя без какого-то ключа? Ведь ключ (в отличие от всего алфавита) маленький, его достаточно легко сделать новый, если что (опять же, в отличие от переработки всего алфавита), легко спрятать. Наиболее наглядно плюсы ключевых систем показывает следующий пример: получателю надо прочитать сосланное вами сообщение. Обычное, на бумаге. Допустим, вы используете секретный алфавит. Тогда, чтобы прочитать сообщение, получатель должен знать алфавит, иметь большой пыльный талмуд, в котором описаны способы расшифровки (ведь алфавит должен быть сложным, чтобы быть надежным) и понимать, как же с этим талмудом работать. С ключами же все проще: вы кладете сообщение в коробку с замком, а получателю достаточно просто вставить подходящий ключик, а знать, как же устроен замок ему совершенно но нужно.
Итак, общеизвестные «алфавиты» и ключи — механизм, существенно более удобный, чем просто алфавиты. Но как же так зашифровать, чтобы все расшифровывалось простым ключом? И вот тут нам на помощь приходит математика, а конкретнее – математические функции, которые можно использовать для замены наших исходных символов на новые.

Вспомним же, что такое функция. Это некоторое соотношение, по которому из одного числа можно получить другое. Зная x и подставляя его в известное нам соотношение y=A*x, мы всегда получим значение y. Но ведь, как правило, верно и обратное: зная y, мы можем получить и x.
Как правило, но далеко не всегда. Для многих зависимостей получить y легко, тогда как x – уже очень трудно, и его получение займет продолжительное время. Вот именно на таких зависимостях и базируется используемое сейчас шифрование.

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

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

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

Пример использования асимметричного шифрования [Wikipedia]
e — открытый ключ получателя B
d — закрытый ключ получателя B
m — исходная информация отправителя A
c — зашифрованная исходная информация

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


Пример применения комбинированной системы [Wikipedia]

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

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

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

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

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

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

Рассмотрение начнем с S/MIME. Сделаем это, во-первых, потому, что данный формат, как я уже говорил, существенно более распространен, а главное: он поддерживается на уровне Windows (а Windows, как ни крути, самая распространенная операционная система), а также многими программами, которые под Windows работают. Ну а во-вторых — данный формат с юридической точки зрения позволяет (в рамках нашего государства, естественно) существенно больше.

Какой самый простой и распространенный способ передать информацию другому человеку? Конечно же, это — электронная почта. Берем письмо, цепляем к нему файлы и отправляем. И тут нам с цифровой подписью в формате S/MIME особенно везет: все распространенные почтовые клиенты умеют как принимать сообщения с цифровой подписью, так и отправлять их. При этом подписывается все письмо целиком, включая присоединенные к письму файлы.


Страница центра управления безопасностью Outlook 2007

И все бы хорошо, вот только для того, чтобы отправить письмо с подписью надо иметь программу, которая осуществляет работу с криптографией (криптопровайдер или cryptographic service provider, CSP), и сертификат определенного назначения и связанный с ним закрытый ключ. Назначение сертификата — это та область, в которой он может быть использован. Подробнее о назначениях сертификатов мы поговорим позже, а для текущей задачи нам, собственно говоря, нужен сертификат для защиты электронной почты (email protection certificate).

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

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

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

Сам же сертификат удостоверяющего центра, по-хорошему, тоже должен быть защищен. А значит, и подписан. Кем? Более высоко стоящим удостоверяющим центром. А тот, в свою очередь, еще более вышестоящим. И такая цепочка может быть очень длинной. Чем же она заканчивается?
А заканчивается она самоподписанным сертификатом удостоверяющего центра. Такой сертификат подписан закрытым ключом, связанным с ним же. Приводя аналогию, это как справка о занимаемой должности и зарплате генерального директора. «Данной справкой Иванов И.И., генеральный директор ООО „Одуванчик“ удостоверяет, что Иванов И.И. занимает в данной организации должность генерального директора и получает зарплату в размере ####### рублей». Чтобы данной справке верить, вы должны верить самой фирме ООО «Одуванчик», причем вера эта не подкрепляется никакой третьей стороной.
Так же и с корневыми сертификатами (т.е. сертификатами удостоверяющих центров). Самоподписанные сертификаты тех удостоверяющих центров, которым вы доверяете, должны лежать в специальном хранилище в системе, которое называется «Доверенные корневые центры сертификации». Но перед тем, как попасть туда, их надо как-то получить. И это — самое слабое звено в системе. Сам самоподписанный сертификат подделать, так же, как и пользовательский, не получится, зато замечательно получится подменить при передаче. Значит, передача должна осуществляться по защищенному от подмены каналу.
Чтобы избежать, по возможности, подобных трудностей, Microsoft выбрала несколько удостоверяющих центров и включила их сертификаты прямо в установку Windows (это Thawte, VeriSign и другие). Они уже есть у вас на компьютере и их не надо ниоткуда получать. А значит и подменить их можно только, если у вас на компьютере живет троян (или у нехорошего человека должен быть администраторский доступ к вашему компьютеру), а говорить об использовании цифровой подписи в таком случае несколько бессмысленно. Кроме того, эти удостоверяющие центры широко известны и много кем используемы, и простая подмена их сертификатов приведет к множеству ошибок в работе, скажем, сайтов, чьи сертификаты выданы этими удостоверяющими центрами, что, в свою очередь, достаточно быстро наведет на мысль о том, что что-то здесь не чисто.

Кстати, о самоподписанных сертификатах: такой сертификат можно создать и для собственного пользования, а не только для удостоверяющего центра. Естественно, такой сертификат наследует все минусы сертификатов подобного типа, но для проверки того, стоит ли использовать цифровую подпись в переписке, или лучше так обойтись он отлично подходит. Для создания подобных сертификатов можно использовать программу, входящую в состав средств Microsoft Office (Цифровой сертификат для проектов VBA), или же, для лучшей настройки назначения и прочих полей данного сертификата, программу стороннего производителя, например КриптоАрм, который даже в бесплатной своей версии позволяет такие сертификаты создавать.


Просмотр самоподписанного сертификата средствами системы Windows

Итак, мы выбираем некий устраивающий нас обоих удостоверяющий центр, получаем на нем сертификаты (для чего заполняем форму на сайте, предоставляем необходимые документы и платим деньги, если потребуется), или создаем себе самоподписанный сертификат и… Собственно говоря, все. Теперь мы можем с помощью нашего почтового клиента (того же Outlook’а) отправлять и принимать подписанные и зашифрованные сообщения.

Для использования стандарта OpenPGP все и проще и сложнее. Для использования данного стандарта все так же необходимы криптопровайдер, пара из открытого и закрытого ключа и программа, осуществляющая непосредственно подписание и шифрование. Для OpenPGP все эти компоненты могут быть как платными, так и бесплатными. С бесплатными больше мороки по установке, а с платными меньше, но принципы и у тех, у тех одинаковы.
Следуя уже использованной последовательности описания, начнем с программы, с которой вы и будете контактировать больше всего: почтовым клиентом. Использование чистого Outlook’а здесь уже невозможно, по причине незнания им о стандарте OpenPGP, а значит надо либо переходить на клиент, который стандарт знает, либо использовать плагины к Outlook’у, или же даже осуществлять работу с подписями и шифрованием через копирование информации во внешние программы. Как пример почтовых клиентов, работающих со стандартом OpenPGP, можно привести Mozilla Thunderbird к которому, кстати, все равно нужен плагин или же The Bat!, умеющий в версии Profissional работать со стандартом OpenPGP сам по себе.


Главные экраны почтовых клиентов Mozilla Thunderbird и The Bat!

Плагины, необходимые для работы со стандартом OpenPGP в почте, также можно найти как платные, так и бесплатные. Платные плагины поставляются вместе с платными же версиями программы PGP, а как пример бесплатного плагина можно привести плагин Enigmail для все того же Thunderbird.


Дополнения, появляющиеся в почтовом клиенте после установки Enigmail

Криптопровайдеры же здесь все так или иначе бесплатные. Можно использовать криптопровайдер, поставляющийся в составе даже бесплатной версии программы PGP, а можно использовать GnuPG.


Страница управления ключами GnuPG

Здесь, пожалуй, стоит немного предостеречь тех, кто погонится за бесплатностью и открытостью кода. Большинство подобных приложений действительно работают и выполняют свои функции, но есть ряд проблем, характерных для всех них. И особенно весомо звучит проблема недостаточного тестирования и проблема проработки пользовательских интерфейсов. Обе эти проблемы коренные для свободного ПО по самой его сути: разработка ведется «всем миром» (или отдельной группой), а значит у проектов в большинстве случаев нету общего идеолога, нету общего конструктора, дизайнера и т.п. В итоге, зачастую получается ситуация «что выросло — то выросло», а это не всегда удобно чисто с функциональной точки зрения. Тестирование тоже, как правило, ведется «всем миром», а не профессиональными тестировщиками, над которыми нависает злой руководитель, поэтому багов в итоговую версию попадает больше. Кроме того, если обнаружен баг, который может привести к потере вашей информации, спросить бывает некого: ПО-то бесплатное и открытое, и финансовой или юридической ответственности перед вами точно никто не несет. Впрочем, не стоит обольщкться, с платным ПО ситуация ровно такая же, хотя в редких случаях возможны варианты. К сожалению, эти случаи относятся, скорее, к компаниям-партнерам и корпоративным клиентам, поэтому для нас, простых пользователей, можно с тем же успехом считать, что вариантов нет.
При этом я ни в коей мере не хочу умолять достоинства такого рода софта. Вообще-то, рассматривая и платные, и бесплатные программы, работающие с криптографией, можно заметить, что первой проблеме — багам — данный софт практически (за редким исключением, которым просто не надо пользоваться) не подвержен. А вот вторая — ужасающие с точки зрения пользователя интерфейсы — касается, как ни странно, почти всех. И если причиной такой ситуации для свободного ПО может быть принято как раз «что выросло — то выросло» (скажем, у замечательной во всех отношениях программы TrueCrypt, являющейся де-факто стандартом в области шифрования данных, интерфейс ужасающ для человека, не очень глубоко разбирающегося в вопросе), то аналогичную ситуацию с платным ПО можно объяснить, пожалуй, только тем, что криптография, как направление разработки, обычно рассматривается по остаточному принципу. Исключения из этих правил встречаются и там, и там, но большее число исключений лично мне, все же, встречалось в лагере платного ПО.

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

Все, как и в случае S/MIME, вышеописанного набора действий вам уже хватит для достижения поставленной нами цели: обмена подписанной и зашифрованной почтой.

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

источник: habrahabr.ru

Реклама

2 Responses to Электронная цифровая подпись для чайников: с чем ее есть, и как не подавиться.

  1. Татьяна says:

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

  2. misha says:

    спасибо огромное!!! Очень толковая статья!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: