0,0
рейтинг
24 июня 2010 в 02:51

Разработка → Электронная подпись для чайников: с чем ее есть и как не подавиться. Часть 2

Часть 1

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



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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

Часть 3
Овчинников Василий @lol4ever
карма
25,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (27)

  • 0
    Спасибо за подробную статью. А не планируете рассказать о XML-DSig?
    • 0
      Планирую, но это, скажем так, некоторый шаг в сторону от изначального пути развития подписи. И про ее историю тоже. Просто сначала нужно закончить вводные статьи, а затем уже переходить к частностям
  • +1
    спасибо что пишете о сложном доступным языком
    буду рекомендовать читать интересующейся этой темой друзьям
    • 0
      Не за что, надеюсь, помогает :)
  • 0
    Из Вашей статьи не понятны некоторые моменты:
    Если захэшировать идентификатор вместе с остальными параметрами, тогда любой злоумышленник может скопировать Вашу и подпись, и подписыватся ей направо и налево. Какая же это секьюрность?
    Сертификат выдается перманентно или на сессию?
    Хотя бы в одном из представленных алгоритмов Третья сторона учавствует в процессе подписывания и сверки результата, или просто выдает сертфикаты?

    Еще, я бы посоветовал приводить хотябы простенькие математические формулы, все же строгость иногда полезнее сотни слов.
    • 0
      >>тогда любой злоумышленник может скопировать Вашу и подпись, и подписыватся ей направо и налево. Какая же это секьюрность?

      Подписать что-либо можно только закрытым ключём, который есть только у вас. В сертификате же содержится открытый ключ, который может только расшифровывать и не более.
      • 0
        Тогда зачем морока с хэшем, идентификатором и прочим?
        Если мы используем ассиметричное шифрование, то нам нужен только timestamp или еще, что-то для гарантии времени подписи, а все остальное по боку.
      • 0
        К тому же, я передаю свой публичный ключ со всем пакетом, что мешает злоумышленнику взять мою подпись и подложить свой публичный ключ?
        • 0
          Ибо левым публичным ключём вы не сможете расшифровать то, что было зашифровано моим закрытым. Т.е. не сможете расшифровать хеш, а значит и не сможете его проверить -> подпись недействительна.

          Единственное, если вы полностью замените всю подпись своей и подсунете свой сертификат. Но это уже будет именно ваш сертификат, а не первоначальный. Т.е. если изначально подпись была Васи Пупкина, то теперь будет Владимира Иванова. Соответственно, конечный человек, которому предназначался документ это дело узреет и поймёт, что он получил совсем не то, что ожидал от Васи, а какую-то левую хрень от Владимира…

          Есть ещё конечно вариант, что в своём сертификате вы как хитрый злоумышленник подпишитесь так же Васей Пупкиным, чтобы конечный адресат ничего не заподозрил. И чтобы это было невозможно, как раз и используют «третью сторону» в виде удостоверяющего центра, который не подтвердит валидность вашего фиктивного сертификата, и конечный адресат опять же поймёт, что получил какую-то хрень, вместо оригинала.
          Как-то так =)
          • 0
            Не понятно. Если сертификат это идентификатор, тогда я могу использовать: чужое имя, чужой сертификат. Т.е. я использую расшифрованную подпись и подписываю ей свой злоумышленный документ, при этом все выглядит как надо, кроме использования другого ключа для шифрования\расшифрования.
            Я знаю как это обойти и сделать секьюрно, но об этом нет ни слова в статье. В связи с чем у меня и возникли вопросы, которые озвучены в первом комментарии. Я считаю, что тема статьи раскрыта не полностью.
            • 0
              Ну, во-первых, к вопросу подмены. Можно подробнее? Как планируется обходить удостоверяющий центр, который подтверждает валидность сертификата?

              И во-вторых, это всего-лишь вторая статья в цикле статей, о чём говорится как в начале таковой, так и в конце… Ждём следующих ;) Там возможно будут ответы на ваши вопросы…
              • –1
                Как планируется обходить удостоверяющий центр, который подтверждает валидность сертификата?

                В статье проведена аналогия между номером и серией паспорта и сертификатом. Возьмем ее в основу.
                Допустим я перехватываю подписанный пакет, извлекаю его содержимое и имею на руках: сертификат, чужой публичный ключ, хэш функцию и захэшированный документ.
                Дальше я шифрую своим ключом: хэш функцию, хэш, сертификат и отсылаю все это дело Вам, с моим публичным ключом, представившись как lol4ever. Вы расшифровываете пакет и спрашиваете в центре: «А у lol4ever действительно сертифика с номером XXXX», они отвечают: «Да, все верно, данный пользователь имеет именно этот сертификат». Вы удостоверившись, в том, что документ был подписан именно lol4ever. Я злорадно потираю руки. Profit!
                Вот как работает алгоритм описанный в статье.
                • 0
                  Что-то мне подсказывает, что не так то просто создать свой сертификат «с номером ХХХХ». Что удостоверяющие центры тоже не дураки… Но утверждать не буду… =)

                  Тут уже и мне интересно, что скажет автор статьи, каким образом защищена эта часть, ибо ну не может же быть всё так просто %)
                  • 0
                    Так а зачем мне его создавать, если этот сертификат есть в сообщении? Я его не создаю, я его копирую. И да, я уверен, что не все так просто, и что все там защищено в определенной степени. Но меня волнует вопрос, почему этого нет в статье? Ведь без этого статья в большей степени является водой, чем полезным материалом.
                    Вообще странно, что стало модно писать кучу статей прелюдий, чтобы потом напсиать суть. Я считаю, что статья должна быть полноценной, т.е полностью покрывать определенный аспект, тут я этого не вижу.
                    • 0
                      Дык ещё в самом начале я написал, что ежели вы перешифруете всё это дело своим ключём, то и сертификат нужен будет ваш, т.к. первоначальный сертификат может расшифровать только зашифрованное мной (моим закрытым ключём, который есть только у меня).

                      А просто скопировав сертификат, вы не сможете перешифровать данные так, чтобы они были дешифрованы ключём из этого же сертификата.

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

                      P.S. Кол-во слов «открытый» просто зашкаливает %) Но не смог по-другому выразить мысль…
                      • 0
                        Так стоп, это уже Ваши домыслы, причем мне они не ясны. В статье картинка с тремя полями, одно из полей это «Информация о владельце». Я могу ее просто скопировать. Причем тут шифрование? Оно тут вообще не вяжется. Давайте математику включим:
                        E1(H) — хэш зашифрованный приватным ключом 1. Я ее дешифрую публичным ключом 2: D2(E1(H)) = H. На этом этапе у меня есть: F — хэш функция, H — хэш, P2- публичный ключ(чужой). Достаем подпись: F(H) = S. Хотя подпись можно было не создавать. Выбираем жертву и отсылаем ей сообщение M(P4, E3(H), F). Где P4 — это мой публичный ключ, а E3 это сообщение которое зашифровано приватным ключом 3(моим). Что в данном случае может сделать третья сторона? Как она докажет, что мой пакет не легитимен?
                        • 0
                          *«подпись не создавать» читать как «подпись не доставать» :)
                          • 0
                            если я правильно понял, то новый сертификат будет выдан на ваше имя, и врядли вы сможете доказать (центру сертификации) что вы Вася Пупкин с такими-то личными данными, центр на то и центр сертификации, что бы подтвердить вашу личность.
                          • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Ну это же для «чайников» пишут! Зачем им формулы да подробности — не поймут ведь!
    • 0
      Вы слегка торопите события. Все, что вы сейчас спросили, безусловно, важные вещи, вот только одно но: это уже подробности одного из форматов, а о них в следующей статье
  • 0
    Кстати, есть ли возможность использовать ЭЦП в Chrome при использовании gmail?
    • 0
      Хм. А поконкретнее? Подписывать сами письма? Вроде б в гмайле такого еще нет (исторически не пользуюсь гмайлом, поэтому точно сказать не могу). А сами отправляемые файлы подписывать — да легко
      • 0
        Аналог https://addons.mozilla.org/ru/firefox/addon/592/
        • 0
          Почитал про аддон. Специфичная штука, работает странно, хотя никакой принципиальной сложности в поддержке работы с S/MIME для почты нет.

          А на тему поддержки работы хромом — вопрос, скорее, к гуглу. С помощью скриптов реализовать «прямую» поддержку S/MIME очень сложно, так что навряд ли она появится. Если уж потребовалась работа с ЭЦП и шифрованием в почте, то лучше пользоваться почтовыми клиентами
  • 0
    На одном дыхании прочил обе части. Шикарные статьи в которых выносится проблематика и решение, прекрасные и ненавязчивые аналогии, да и вообще всё очень прекрасно расписано. Надеюсь тему не забросите и продолжите писать. Читать очень интересно. Спасибо огромное.
    • 0
      Не за что.
      Не заброшу, в ближайшие пару дней будет следующая статья

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.