Crazy Rebel: викификация, оформление

2008-11-26T05:36:41Z

викификация, оформление

Новая статья

[[Категория:Учебники]]

{{Цикл/Электронные_подписи}}

:'''Новая серия!''' Разбираемся с электронной подписью и учимся использовать ее для защиты персональных документов

==Электронные подписи и цифровые сертификаты==

:'''ЧАСТЬ 1''' В наши дни никому нельзя доверять. Милая девушка из чата может легко оказаться бородатым мужчиной, а его сообщения – искусно подделанными зеленым человечком с Альфы Центавра. Избежать конфуза поможет электронная подпись – и '''Андрей Боровский''' сейчас расскажет, как именно.

::::''– Что ж, теперь, когда мы увидели друг друга, – сказал Единорог, – можем договориться: если ты будешь верить в меня, я буду верить в тебя! Идет?''

::::''– Да, если вам угодно, – отвечала Алиса.''

::::::'''Льюис Кэрролл, Алиса в Зазеркалье'''

Жизнь научных идей так же непредсказуема, как и человеческая. Мог ли сэр Эрнст Резерфорд в начале XX века
представить себе, что через каких-то пятьдесят лет профессия исследователя атомного ядра станет престижной и опасной?
Точно так же математики прошлого, изучавшие такие проблемы алгебры, как разложение чисел на простые множители, не могли предположить, что сфера их профессиональных интересов когда-нибудь
привлечет к себе внимание большого бизнеса, спецслужб и международного криминала.

Широкое распространение компьютеров в повседневной жизни
привело к не менее широкому распространению систем шифрования
и электронной подписи. Сегодня уже все знают, что электронная криптография предназначена не только для разведчиков и дипломатов. Не
все, однако, представляют себе, как пользоваться даже самыми простыми средствами защиты электронных документов, такими как цифровые сертификаты и удостоверяемые ими ключи. На сегодняшний
день наиболее широкое распространение получила технология удостоверения электронной подписи на основе системы PKI (Public Key
Infrastructure, Инфраструктура открытых ключей). В мире Linux (да и
не только) также набирает популярность система цифровых подписей
на основе GnuPG. Однако, то, что просто и удобно в Linux, может быть
совсем не простым в Windows с ее рудиментарной консолью. Если вы
хотите обмениваться безопасной почтой и документами с пользователями Windows, у вас есть два варианта действий – убедить их установить консольные программы безопасности, разработанные в соответствии с философией Linux, или воспользоваться сертификатами PKI
(их еще называют сертификатами X.509, по названию используемого
протокола). В этой статье речь пойдет именно о них. Администраторы
web-серверов также имеют дело с сертификатами PKI, в основном, в
связи с протоколом SSL. Мы поговорим о сертификатах с точки зрения «рядового пользователя ПК». Чтобы получить какую-либо пользу от сертификатов, даже рядовому пользователю необходимо знать, как
они работают.

===О терминологии===

Поскольку в этой статье речь пойдет о вещах, связанных с шифрованием, нельзя не коснуться вопроса о криптографической терминологии. Разные отечественные авторы применяют разную терминологию, а многочисленная переводная литература по шифрованию, над которой трудятся переводчики
разной квалификации и прилежания, только усиливает путаницу. Набора терминов, который бы нравился всем, не существует. Термины, используемые в этой статье, взяты из «Краткого словаря понятий,
сокращений и терминов PGP, криптографии и информационной безопасности», расположенного на
сайте http://www.pgpru.com/. Всех, кто желает прояснить для себя, чем расшифровка отличается от
дешифровки и что такое хеш-функция, равно как и всех, недовольных моей терминологией, я отсылаю к нему.

===Алиса, Боб и все-все-все===

Для правильного понимания работы цифровых сертификатов необходимо иметь, по крайней мере, общее представление о важной отрасли современной криптографии – шифровании с открытым ключом
(известным так же как «асимметричное шифрование»). В ассиметричном шифровании участвуют два ключа. То, что зашифровано одним
ключом, может быть расшифровано с помощью другого ключа (в некоторых алгоритмах, например, в популярном RSA, верно и обратное, то
есть выбор ключа для шифрования и расшифровывания может быть
произвольным, однако не все алгоритмы обладают этим свойством).
Важной особенностью алгоритмов асимметричного шифрования является то, что, зная один ключ, невозможно вычислить другой (так, по
крайней мере, должно быть). Что это дает пользователям компьютеров? Предположим, что некий пользователь (согласно одной из традиций, существующих в криптографической литературе, назовем этого
пользователя '''Алисой''') желает получать конфиденциальные сообщения.
С помощью программы асимметричного шифрования '''Алиса''' может
создать пару ключей. Один из этих ключей (секретный ключ, СК) '''Алиса'''
будет хранить в строжайшей тайне, а второй ключ (открытый ключ, ОК)
опубликует на своей страничке в Интернете. Если другой пользователь,
'''Боб''', захочет послать '''Алисе''' секретное письмо, он зашифрует его с
помощью ОК '''Алисы'''. Такое письмо можно будет расшифровать только
с помощью СК '''Алисы''' и никак иначе. Преимущество асимметричной
схемы заключается в том, что '''Бобу''' не нужно встречаться с '''Алисой''' для
обмена ключами. Даже если они раньше не были знакомы, они могут
начать конфиденциальную переписку (разумеется, для того, чтобы '''Боб'''
мог принимать конфиденциальные сообщения по этой схеме, у него
должна быть своя пара ключей СК/ОК). Впрочем, на практике асимметричные алгоритмы не используются напрямую для шифрования
сообщений.

Как уже отмечалось, в некоторых алгоритмах ОК и СК взаимозаменяемы (иными словами, то, что зашифровано с помощью
СК, может быть расшифровано с помощью ОК и никак иначе).
Взаимозаменяемость ключей позволяет использовать такие алгоритмы не только для шифрования, но и для электронной подписи.
Предположим, что '''Алиса''' посылает '''Бобу''' письмо, зашифрованное ее
секретным ключом с помощью алгоритма RSA. Поскольку это письмо
можно расшифровать только с помощью ОК '''Алисы, Боб''' может удостовериться, что автором письма является обладатель СК '''Алисы''' (то есть,
с высокой степенью вероятности, сама '''Алиса'''), а не кто-то другой. Это
и есть простейший вариант цифровой подписи. Заметим, что само
сообщение, зашифрованное с помощью СК '''Алисы''', не является секретным (ведь ОК '''Алисы''' доступен всем). Подпись удостоверяет только
подлинность сообщения.

Поскольку цифровая подпись предназначена не для обеспечения
конфиденциальности, а для подтверждения подлинности сообщения, в шифровании всего сообщения нет нужды. Вместо этого можно
создать цифровой отпечаток сообщения – некоторое количество битов
(меньшее, чем количество битов в сообщении), полученное таким
образом, что любое изменение в сообщении приведет к изменению
отпечатка (такие отпечатки создаются с помощью однонаправленных
хэш-функций, поэтому их называют хэш-значениями). Для того, чтобы
подписать свое письмо, '''Алиса''' получает его хэш-значение с помощью
одного из стандартных алгоритмов, шифрует это хэш-значение своим
СК и прикрепляет зашифрованное хэш-значение к своему сообщению.
Для того, чтобы удостовериться в авторстве сообщения, '''Боб''' должен
расшифровать его хэш-значение, используя ОК '''Алисы''', затем сравнить
расшифрованное значение со значением, вычисленным для сообщения с помощью того же алгоритма. Если какой-нибудь злоумышленник,
скажем, '''Зина''' (или '''Зиновий''', кому как нравится) изменит сообщение
'''Алисы, Боб''' обнаружит это, сравнив зашифрованное '''Алисой''' хэш-значение с тем, которое он вычислил (изменить электронную подпись
'''Зина''' не сможет, если только не знает СК '''Алисы'''). Следует признать,
что на практике все выглядит не так просто. Поскольку длина хэш-значения значительно меньше длины сообщения (в этом и заключается
смысл использования хэш-значений), одному хэш-значению соответствует более чем одно сообщение. Теоретически это означает, что '''Зина'''
может подобрать другое сообщение, имеющее то же хэш-значение, что
и сообщение '''Алисы''', прикрепить к этому сообщению подпись '''Алисы'''
и отправить его '''Бобу'''. Получив такое сообщение, '''Боб''' будет уверен,
что его автор – '''Алиса'''. Однако, поскольку хэш-функция, с помощью
которой получают хэш-значение сообщения, необратима, подобрать
документ с тем же хэш-значением можно только путем слепого перебора (что обычно очень трудно сделать). Впрочем, разработчики криптографических систем – тоже люди, и главное отличие человека от
Бога – способность ошибаться – присуще им, как и всем остальным.
На протяжении долгого времени для получения цифровых подписей
использовался алгоритм хэширования MD5, однако не так давно было
обнаружено, что он ненадежен. Оказалось, что во многих случаях
подобрать текст под заданное значение MD5, даже на не самом мощном ПК, можно за несколько минут. Сейчас алгоритм MD5 выводится
из употребления и заменяется алгоритмом SHA1, который, пока что,
считается надежным.

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

В схеме электронной подписи сообщений с помощью асимметричного шифрования возникает одна проблема, для решения которой и
предназначены цифровые сертификаты. Боб может доверять электронной подписи '''Алисы''', только если он уверен, что ОК, который он
использует для расшифровки хэш-значения, действительно принадлежит '''Алисе'''. Если ОК опубликован на домашней страничке '''Алисы''', то,
скорее всего, он действительно принадлежит ей. Но страничку '''Алисы'''
могут взломать злоумышленники, другие злоумышленники могут
открыть «псевдо-сайт» '''Алисы''' и выложить на нем свой ключ, и это не
говоря уже о том, что у '''Алисы''' может просто не быть своей домашней
странички. Для надежной связи с '''Алисой Бобу''' необходимо какое-то
удостоверение подлинности '''Алисиного''' ОК. Роль такого удостоверения
и играет цифровой сертификат. Цифровой сертификат удостоверяет
связь между открытым ключом и некоторым объектом. Объектами,
с которыми связывается открытый ключ, могут быть имя человека и
(или) адрес его электронной почты, доменное имя сайта или название
компании-разработчика ПО. Естественно, сертификат, удостоверяющий принадлежность открытого ключа некоей сущности, может быть
полезен только при том условии, что он выдан организацией, которой
доверяют все участники транзакции. Такие организации именуются в
англоязычных странах certificate authorities (CA), а у нас – центрами
сертификации или удостоверяющими центрами (УЦ). Для того, чтобы
добиться доверия '''Боба, Алиса''' должна заверить свой открытый ключ
сертификатом, выданным солидной организацией, которой доверяет
'''Боб''', и предоставить этот сертификат '''Бобу''' для того, чтобы он мог удостовериться в подлинности ее подписи.

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

===Структура цифрового сертификата===

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

[[Изображение:LXF93_RCA1.png|Рис. 1]]

'''Рис. 1. Структура сертификата PKI.'''

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

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

Хотя сертификаты и не гарантируют 100% надежности (а кто нам
вообще ее гарантирует в этом Мире?), существует надежная с практической точки зрения система защиты от подделки сертификатов. Речь идет о корневых сертификатах. Корневой сертификат (КС) является
корнем пути сертификации и содержит открытый ключ выпустившего
его УЦ. Корневой сертификат подписывается с помощью секретного
ключа того самого УЦ, чей открытый ключ он удостоверяет (поскольку открытый ключ в корневом сертификате подписан с помощью
соответствующего ему секретного ключа, такие сертификаты называют самоподписанными). Фактически КС удостоверяет сам себя,
поэтому проверить его достоверность с помощью какого-либо другого сертификата невозможно. Выигрыш от применения КС основан на
том, что один КС может использоваться для удостоверения подлинности многих клиентских сертификатов. В результате нам приходится доверять не миллионам сертификатов пользователей, а нескольким
десяткам КС (организовать надежное распространение нескольких КС
не так уж и трудно).

Каждый раз, когда ваша система удостоверяет пользовательский
сертификат, она использует для этого один из КС. Откуда берутся
корневые сертификаты в вашей системе? Обычно они поставляются
вместе с программным или аппаратным обеспечением (например, в
составе дистрибутивов web-браузеров и почтовых клиентов). Это,
конечно, означает, что разработчик или поставщик ПО и оборудования могут смошенничать с корневыми сертификатами, но они ведь
могут смошенничать и многими другими способами, поэтому если
вы вообще доверяете своим программам и устройствам, у вас нет
особых причин не доверять включенным в него КС. Хотя ваш браузер и почтовый клиент содержат множество предустановленных КС,
время от времени вы можете столкнуться с сертификатом, который
удостоверен УЦ, неизвестным вашей системе (иначе говоря, в системе не установлен КС удостоверяющего центра, выдавшего данный
сертификат). Встречая сертификат, для которого не предустановлен
КС, программы предупреждают вас об этом (Рис. 2). Для того, чтобы
система смогла проверить подлинность сертификата, вам придется
установить удостоверяющий его КС. Важно понимать, что система не
станет устанавливать новые КС автоматически (в этом и заключается
смысл предупреждающего сообщения, показанного на рисунке). Вы
сами должны решить, доверяете ли вы новому удостоверяющему
центру и (что еще важнее) источнику, из которого вы собираетесь
установить его КС.

[[Изображение:LXF93_RCA2.png|Рис. 2]]

'''Рис. 2. Предложение установить корневой сертификат.'''

Таким образом, получив подписанное сообщение и сертификат,
удостоверяющий цифровую подпись, адресат сообщения проверяет
подпись с помощью полученного сертификата, а сам сертификат – с
помощью установленного в его системе КС.

===Сертификаты в почтовых клиентах и Web-браузерах===

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

[[Изображение:LXF93_RCA3.png|Рис. 3]]

'''Рис. 3. Менеджер сертификатов ''Firefox''.'''

Для передачи сообщений, подписанных и зашифрованных с
помощью ключей и сертификатов PKI, используется протокол S/MIME. К подписанному сообщению протокол S/MIME прикрепляет
сертификат, удостоверяющий подпись, так что, получив подписанное письмо, вы получаете и открытый ключ его отправителя. Вы
можете зашифровать свой ответ, используя этот открытый ключ, и
снова передать зашифрованное сообщение по протоколу S/MIME.
Тот, кто подписал адресованное вам письмо, сможет расшифровать
ваш ответ с помощью своего секретного ключа. Поскольку асимметричные алгоритмы шифрования ресурсоемки, сам документ обыч-
но шифруется с помощью менее требовательного симметричного
алгоритма, а открытый ключ применяется только для шифрования
«симметричного» ключа.

В заключение этой вводной части рассмотрим фрагмент настоящего сертификата:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing
Authority/emailAddress=support@cacert.org
Validity
Not Before: Mar 30 12:29:49 2003 GMT
Not After : Mar 29 12:29:49 2033 GMT
Subject: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing
Authority/emailAddress=support@cacert.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
...

Этот сертификат является КС удостоверяющего центра CA Cert (обратите внимание, что УЦ выдает этот сертификат самому себе).
Как и все КС, этот сертификат обладает длительным сроком действия
(до 2033 года). Интересно также отметить, что сертификат был выпущен в 2003 году, то есть тогда, когда об уязвимости алгоритма MD5
еще не было известно, поэтому цифровая подпись сертификата получена с помощью алгоритма MD5, о чем свидетельствует строка

Signature Algorithm: md5WithRSAEncryption

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

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

LXF93:Электронные подписи - История изменений

Crazy Rebel: викификация, оформление