Каждая часть информации может передаваться вместе с открытым ключом, или вместе с нашей подписью, или и то, и другое, для большего удобства.
Конечно, можно не разделять информацию на передаваемую с открытым ключом и передаваемую с подписью.
Но потом, каждый раз, когда мы отправляем подписанную информацию, мы отправляем одно и то же.
Это как если бы к каждому бумажному письму, которое мы отправляем (даже к короткому двухстрочному письму), мы добавляли бы дополнение типа «Привет! Это я, В.
Пупкин, которого вы встретили на Красной площади в Москве, где мы познакомились, потом зашли в ресторан, потом <.
> ».
Согласитесь, это немного неудобно.
Но вернемся к нашей информации, необходимой для проверки подписи.
Начнем с простого: информации, которая позволит нам узнать, кто сделал эту подпись.
Как мы уже договорились, асимметричное шифрование позволяет нам однозначно связать наш открытый ключ и полученную подпись.
Проблема в том, что сам открытый ключ представляет собой набор байтов.
Причём оно, конечно, связано с приватным, которым мы (то есть отправитель) владеем, но для получателя эта связь не очевидна.
У него есть набор байтов от В.
Пупкина, от И.
Петрова, от С.
Сидорова.
И от десятка других людей.
И как он может их идентифицировать? Ведите отдельный реестр для того, кому какой набор байт принадлежит? Что это такое, выясняется уже второй реестра (кроме того, где должно быть записано, с помощью какой хэш-функции какой хэш был сделан)! И снова неудобно! Это означает, что вам необходимо связать каждый публичный ключ с информацией о том, кому принадлежит этот ключ, и отправить все это в одном пакете.
Тогда проблема реестра решается сама собой — пакет (или, правильнее, контейнер) с открытым ключом можно просто посмотреть и сразу понять, кому он принадлежит. Но эту информацию еще нужно связать с подписью, полученной получателем.
Как это сделать? Необходимо построить еще один контейнер, на этот раз для передачи подписи, и продублировать в нем информацию о том, кто создал эту подпись.
Продолжая аналогию с красивым замком, напишем на ключе «Этот ключ открывает замок В.
Пупкина».
А на замке еще пишем «В.
Пупкин замок».
Имея такую информацию, получатель нашей шкатулки не будет вставлять в наш замок каждый из имеющихся у него ключей наугад, а возьмет наш ключ и тут же откроет его.
Теперь, используя переданную при проверке информацию, можно найти контейнер открытого ключа, взять оттуда ключ, расшифровать хеш и.
Что такое «и»? Ведь мы еще не решили задачу, как донести до получателя информацию о том, какая хеш-функция использовалась для хеша, но эта информация используется для проверки подписи.
необходимый ! Решение может быть довольно простым: поместите эту информацию в контейнер вместе с нашим открытым ключом.
Ведь именно комбинация «хеширование – шифрование результата хеширования» считается процедурой создания цифровой подписи, а ее результатом является подпись.
Это означает, что кажется вполне логичным объединить алгоритм шифрования хэша и хеш-функцию, с помощью которой он генерируется.
И эту информацию тоже нужно доставлять пакетом.
Теперь кратко вернемся к информации о подписывающем лице.
Какого типа информация должна быть? ПОЛНОЕ ИМЯ? Нет, там много В.
Пупкиных.
Полное имя + год рождения? Так что В.
Пупкиных тоже немало, рожденных в один день! Причем это мог быть Василий, Виктор или даже Василиса или Виктория Пупкины.
Это значит, что информации должно быть больше.
Их должно быть столько, чтобы совпадение всех параметров, по которым мы идентифицируем человека, было максимально невероятным.
Конечно, создать такой пакет информации возможно.
Просто с ним уже немного сложно работать.
В конце концов, наши контейнеры с открытыми ключами необходимо сортировать, хранить и использовать.
А если для каждого использования придется указывать пятьдесят параметров, то уже на втором контейнере станет понятно, что нужно что-то менять.
Решение этой проблемы, конечно же, было найдено.
Чтобы понять, что это было, обратимся к бумажному документу, который есть у каждого из нас: паспорту.
В нем вы сможете найти свое полное имя, дату рождения, пол и многое другую информацию.
Но, самое главное, в нем можно найти серию и номер.
И именно серия и номер являются той уникальной информацией, которую удобно учитывать и сортировать.
Кроме того, они существенно короче всей остальной информации вместе взятой, и в то же время все же позволяют идентифицировать человека.
Применяя тот же подход к контейнерам с открытыми ключами, мы получаем, что каждый контейнер должен иметь определенное число, уникальную для него последовательность символов.
Ээта последовательность символов обычно называется идентификатор , а сами контейнеры – сертификаты или просто ключи.
Вот тут-то и начинаются принципиальные различия идеологий OpenPGP и S/MIME+X.509. Чтобы кратко их понять, давайте вернемся к нашей аналогии с паспортом.
Вы можете использовать свой паспорт при покупке билетов, при оформлении документов, для оформления пропуска на любую территорию и даже на территорию других стран! То есть вы используете его для идентификации своей личности в самых разных, часто совершенно не связанных друг с другом местах, с разными людьми.
И везде принимают ваш паспорт. Гарантией того, что вы являетесь собой, является третья сторона в ваших отношениях с другими: государство.
Это тот, кто выдал вам паспорт, специально разработанный, подписанный и заверенный, и именно поэтому ваш паспорт является таким универсальным документом.
С другой стороны, среди друзей, или внутри компании, представиться просто необходимо так: «В.
Пупкин из вашей группы в институте» или «В.
Пупкин из отдела продаж».
И люди, с которыми вы соприкасаетесь в этом кругу, уже не нуждаются в третьем лице, они уже помнят Пупкина из группы, с которым учились пять лет, или Пупкина из отдела продаж, с которым они недавно сходили на обед, и предоставленной вами информации им вполне достаточно.
Эти два лагеря также можно разделить.
Сертификат X.509 похож на наш паспорт. Здесь сертификаты выдаются вам строго третьей стороной, гарантом вашей личности: центром сертификации (CA).
Лицо, получающее ваши подписи, всегда может обратиться в УЦ и запросить интересующую его информацию относительно этого конкретного сертификата.
PGP (и появившийся позже стандарт OpenPGP) был создан на основе так называемых сетей доверия.
Эта идея подразумевает, что подписями обмениваются люди, которым для своих отношений не нужна третья сторона, а нужна лишь защита от плохих людей.
Конечно, со временем такое деление стало весьма условным, поскольку на данный момент и S/MIME+X.509, и PGP могут использовать методы конкурирующего лагеря.
Но тем не менее стандарты развивались параллельно довольно долгое время и развились до такой степени, что взаимная совместимость между ними стала невозможной.
Стандарт S/MIME+X.509 стал более популярным стандартом, благодаря своей ориентированности на участие более компетентной третьей стороны, однако у PGP есть и ряд козырей за пазухой, с помощью которых он не только не умирает, но и продолжает успешно развиваться.
Более подробное обсуждение каждого из форматов, а также рекомендации о том, когда, где и какой из них использовать, вы можете прочитать в следующих статьях.
Часть 3 Теги: #ЭЦП #электронный документооборот #Криптография #электронная коммерция #бизнес #информационная безопасность #электронный документ #цифровая подпись #информационная безопасность
-
Рассматривая Дешевый Android-Планшет
19 Oct, 24 -
Мегафон - Работаем Над Ошибками?
19 Oct, 24 -
Создан Работающий Прототип Ховерборда
19 Oct, 24 -
Простое Управление Сетевыми Портами
19 Oct, 24 -
Простые Поисковые Расширения Для Firefox
19 Oct, 24
