Получение сертификата x.509 и личная безопасность
Возможно ли получить сертификат x.509, самостоятельно создав пару ключей, а центру сертификации предоставив только открытый ключ?
На публичных серверах сертификатов, например http://www.trustcenter.de, предлагает создать сразу пару ключей. Мне кажется это как-то не очень конфиденциально и приватно, ведь они могут у себя оставить копию закрытого ключа, и теоретически, потом силовые органы могут потребовать его у этого
центра сертификации...
Ссылки
[link1] https://keyserver-beta.pgp.com
[link2] http://www.pgpru.com/apg/
[link3] http://www.securityspace.com/s_survey/sdata/200507/ru/certca.html
[link4] http://www.freessl.ru/
[link5] http://lists.gnupg.org/pipermail/gnupg-announce/2005q3/000200.html
[link6] http://www.pgpru.com/keyserver/
[link7] http://vologda.allbusiness.ru/NewsAM/NewsAMShow.asp?ID=19793
[link8] http://region.adm.nov.ru:8080/web/web.pressday.show?AWhat=2&Aid=423973
[link9] http://www.rosalcohol.ru/site.php?id=3934&table=bmV3c192aW5v
Всё не так. Когда Вы проходите процедуру зачисления в PKI удостоверяющего центра, Ваш браузер (т.е. MS Crypto API) генерирует пару ключей, формирует пакет запроса, куда включаются все записи создаваемого сертификата — Ваше имя, мэйл и прочее — подписывает запрос закрытым ключом и вместе с открытым отправляет его в центр сертификации. Тот проводит проверку достоверности представленных данных и, если всё в порядке, издаёт сертификат в формате Х.509, заверяет его собственным закрытым ключом и передаёт сертификат Вам. Закрытый ключ не покидает системное хранилище сертификатов Windows Вашего компьютера.
Спасибо!
Получается, что всем, даже бесплатным центрам сертификации, выдающим сертификат X.509, можно доверять безоговорочно?
Формат Х.509 — неплохой формат, но он подходит только для узких и, как сегодня модно говорить, вертикально интегрированных организаций. X.509 PKI — хорошая модель для корпоративной среды, но не для публичной электронной почты.
Мэтт Блейз как-то сказал, что удостоверяющий центр из мира X.509 защитит вас от всех, от кого он не захочет брать денег. В общем это справедливое наблюдение, ведь крупные УЦ — это, прежде всего, коммерческие организации, где издание сертификатов — основной вид бизнеса.
Достоверность сертификата X.509 обеспечивает всего одна подтверждающая подпись — подпись самого УЦ. Здесь нет аккумуляции доверия, как PGP Web of Trust. Такая система может быть легко скомпрометирована: прямой взлом, подкуп, угроза могут заставить УЦ заверить поддельный сертификат, и Ваша программа его с аппетитом слопает (если Вы доверяете самому УЦ), потому что доверие наследуется только от одного издателя.
Что касается бесплатных сертификатов (и вообще сертификатов Class 1), с ними дело обстоит ещё хуже. Для выдачи коммерческих сертификатов (Class 2 и выше) применяются довольно сложные и весьма надёжные процедуры проверки личности пользователя, вплоть до того, что он должен лично прибыть в офис УЦ, предъявить минимум два различных удостоверения личности с фотографией, доказать, что имеет доступ к своему почтовому ящику, документально подтвердить все прочие сведения, входящие в сертификат, и только тогда УЦ заверит сертификат своей подписью. Хотя это не исключает возможность сговора злоумышленника и УЦ, однако делает почти невозможным несанкционированние получение злоумышленником сертификата на чужое имя.
Но процедура проверки личности для получения сертификатов Class 1 слишком проста — в большинстве случаев она вообще отсутствует. Пользователь через интернет запрашивает УЦ подписать сертификат с представленным именем и email. Имя удостоверяющий центр вообще не волнует; на email он высылает простой запрос, который пользователь должен подтвердить, пройдя по определённой ссылке. Вот и всё. Ничто не мешает злоумышленнику послать такой же запрос, перехватить письмо, отправленное УЦ в ящик пользователя, и самостоятельно выполнить подтверждение; в будущем останется только перехватывать направляемые пользователю письма.
В действительности, новый сервис PGPCorp — PGP Global Directory[link1] выполняет ровно ту же работу, но с ключами PGP. Однако, это лишь справочник, не претендующий на роль УЦ.
Можно ли самостоятельно издать сертификат с помощью какой-либо программы, для использования в рамках предприятия и в целях создания внутреннего электронного документооборота, где системный администратор сети являлся бы «центром сертификации»?
Я имею в виду сертификат X.509, с которым работает Outlook.
В OpenSSL можно. Так обычно и делают. С чем конкретно работает Outlook не знаю.
Ещё есть open source пакет X CA специально для развёртывания комплексных PKI X.509. На sg.net поищите.
Интересен вопрос статистики. Ести ли данные о том, какой криптосистеме люди в большинстве отдают препочтение? PGP, встроенным средствам Windows (при получении сертификатов) или есть еще какие-либо популярные системы. Я имею в виду не корпоративные сети, а обычных пользователей интернет.
Статистики не знаю (и вряд ли такая есть), но навярняка не ошибусь, если предположу, что большинство не пользуются ничем.
Да и не нужна она вообще в данном случае. Как "средняя температура больного по госпиталю".
А какие люди? "Простые пользователи"? А если простой пользователь работает с "не-WIndows" – OC? Он уже "непростым" что-ли становится? А если он разработчик ПО (допустим бесплатного), имеющий свой сервер (а не только сайт) в Интернете? Где грань между разными группами пользователей и их интересами?
У всех свои требования. Как их усреднить-то?
Здравствуйте!
1. Со страницы http://parom.org/scripts/SSLclient.html я получил сертификат в виде файла client.pfx, файл мне прислали на почтовый ящик. Насколько я понял в данном случае произошла не генерация ключей на моем компьютере, а именно сам сервис прислал мне этот сертификат. После создания сертификата я на экране монитора получил страницу, с паролем к сертификату, а так же какой-то код, о назначении которого я не знаю. Скажите что это за код может быть и действительно ли в данном случае генерация закрытого ключа произошла не на моей машине?.
2. Я проинсталлировал этот сертификат и добавил его в хранилище сертификатов ОС. Но воспользоваться им не могу. С списке сертификатов Outlook Express (сервис – параметры – вкладка безопасность – сертификаты) сертификат появился. По кнопке «просмотр» установлены все политики применения, в том числе защищенная почта. Однако в том списке сертификатов, в котором производится выбор сертификатов для использования (сервис – учетные записи – свойства учетной записи – вкладка безопасность – выбрать) список пуст.
3. Как войти в хранилище сертификатов Windows?
Заранее спасибо, с уважением.
По одному вопросу № 2 разобрался самостоятельно. Дело оказалось в том, что сертификат ассоциируется с e-mail, а у меня учетная запись хоть и связана с моим e-mail, но в корпоративной сети обозначена по другому. Проблема в том, как увязать внутреннюю учетную запись с сертификатом, что бы сертификат заработал.
И сертификат, и открытый ключ, и закрытый. В отличие от того, как это делается правильно (см. начало топика). По правде говоря, некоторые УЦ генерируют коммерческие сертификаты высоких классов самостоятельно и передают их клиенту при личном визите. Но в данном случае эта практика ещё ненадёжней, чем даже использование паролей, сгенерированных онлайн[link2], в критических приложениях.
Хотя этот сертификат и можно запросить через ssl-защищённое соединение, всё равно
а) ключевая пара генерируется сервером (возможность депонирования)
б) сертификат высылается в письме с паролем, указанным открытым текстом!
Стоит перехватить это письмо, и вся будущая переписка будет скомпрометирована. Т.е. этот сервис проваливает весь смысл S/MIME ещё в самом начале.
В итоге вся эта защита абсолютно иллюзорна. Поставщик не входит в число напрямую доверенных браузером, так что использование подобного сертификата не несёт и малейших удобств хотя бы от наследования доверия идентификации. С тем же успехом можете поставить себе помянутый X CA и выпустить самоподписанный сертификат, но так Вы хотя бы будете уверенны, что копии закрытого ключа ни у кого не осталось. Да и сам ключ сможете сделать хоть на 4096 бит. :)
Проверил. Пароля там не увидел — он письмом пришёл, а этот код — просто технические параметры сертификата плюс модуль RSA и цифровая подпись. Просто для красоты, никакого практического смысла эта писанина не несёт.
Импортировали его в хранилище личных сертификатов? Откройте Пуск > Настройка > Панель управления > Свойства обозревателя > Содержание > Сертификаты. Если во вкладке Личные Вашего сертификата нет, импортируйте его повторно, отметив в мастере импорта "Поместить все сертификаты в следующее хранилище", выбрав по кнопке Обзор "Личное".
Ещё одна возможная причина — у Вас может отставать системный таймер. В этом случае сертификат ещё как бы не вступил в действие. Проверьте, правильно ли установлено время и дата.
Спасибо. Во всем разобрался. Нашел более надежный источник получения сертификата. https://www.thawte.com/cgi/enroll/personal/step1.exe
Сертификат всегда ассоциируется с явным email, в этом его назначение, в ином случае не происходило бы наследования доверия. В Outlook вроде бы есть расширения для связывания сертификата с определённой записью в Exchange, но как это работает, я не проверял, и есть ли что-то подобное в Outlook Express — не знаю (хотя наверняка и нету).
Вот еще какой вопрос. Где то в документации встречал, что при работе с Outlook Express имеет место ограничение на длину ключа. Вопрос в том, имеет ли ограничение место при работе с ms Outlook? Какой программой лучше пользоваться в плане большей безопасности, или все равно?
Сертификат от Thawte до подтверждения Вашей личности поручителями (в терминологии Thawte они именуются "нотариусами") не будет содержать имени. Такая же ситуация имеет место с CACert. (В CACert и Thawte реализованы похожие схемы распределённой верификации.) Сертификат Class 1 с именем и по достаточно надёжной схеме зачисления можно получить в trustcenter.de.
В PGP используется шифрование информации сеансовым симметричным ключом, с последующим шифрованием симметричного ключа по ассиметричной схеме (если не рассматривать частные случаи использования только симметричного шифрования). Какова ситуация в системе с сертификатами X.509? Используется такая же схема, или там информация шифруется только ассиметричным ключом?
То же самое, что в OpenPGP.
"Чистое" шифрование с открытым ключом никогда не применяется в прикладных криптосистемах. Изредка — в протоколах, да и то для аутентификации. Причина — не только неоправданная вычислительная нагрузка: тот же RSA вскрывается по известному открытому или подобранному шифртексту, можно шифровать только блок данных, не превышающий длину ключа и т.д. Если же открытый ключ зашифровывает непредсказуемый симметричный ключ, это снимает отмеченные проблемы.
Мне доводилось работать с сертификатами через OpenSSL. Интересно, что длину ассиметричного ключа для сертификатов Х509 можно выбирать любой – хоть десятки тысяч битов. Так, для экспериментов, возможность любопытная.
При этом все нормально шифруется-проверяется (именно командами OpenSSL, обычные почтовые клиенты и сертификационные центры могут такой нестандартный сертификат не принять).
А вот симметричный алгоритм жестко задан стандартом – только 3DES и никакого другого. Не знаю, может в новых реализациях OpenSSL допускается что-то новое, но я сомневаюсь.
Это, видимо, особенность OpenSSL, т.е. самого приложения. Стандарты, где применяется формат X.509, вроде тех же S/MIME или SSL, таких ограничений не накладывают, а вот реализации — могут. Как в старых версиях Internet Explorer, где из-за требований американского экспортного режима применялся только 40-битовый RC4. ITU-T Х.509, как таковой, вообще не оговаривает, какие данные в рамках заданных полей в него можно кодировать, оставляя этот вопрос на усмотрение стандартов и реализаций.
Да, похоже такое ограничение конкретно для S/MIME ([-des] [-des3] [-rc2-40] [-rc2-64] [-rc2-128]) ничем не обоcновано. При том, что в этой же версии OpenSSL для других типов шифрования (кроме S/MIME) работают и другие, более современные шифры.
http://eprint.iacr.org/2005/067.pdf
Генерируем пару сертификатов (подписанный-фальшивый) с MD5-коллизиями.
Как происходит проверка подлинности цифрового сертификата X.509 при
получении письма от ранее неизвестного адресата? Там что то говорится о наследовании доверия от поставщика.
Я могу вручную поставить определенный уровень доверия, но вручную это
вручную, т.е. в этом нет никакого смысла. Происходит ли какая-либо автоматическая проверка через центр сертификации, как это происходит и как я могу проследить, прошла ли такая сверка?
Этот же вопрос было бы интересно знать по работе https (ssl) – вопрос
доверия сайтам.
Спасибо.
Сертификаты X.509 помимо автоподписи несут подпись доверенного удостоверяющего центра, выпустившего данный сертификат. Именно подпись УЦ, согласласно философии PKI, придаёт сертификату свойство достоверности, поскольку УЦ выступает в роли независимого поручителя в том, что данный сертификат принадлежит предполагаемому владельцу, и тот располагает соответствующим закрытым ключом.
Открытые ключи большинства крупнейших УЦ поставляются в составе дистрибутивов браузеров и мэйл-клиентов, что обеспечивает прямое доверие корневым сертификатам PKI. Получив S/MIME- или PEM-подписанное письмо, Ваш мэйл-клиент импортирует сертификат отправителя и сверяет с него ЭЦП с помощью априорно доверенного открытого ключа соответствующего удостоверяющего центра.
Если подпись на сертификате верна, мэйл-клиент считает сертификат отправителя достоверным, а содержание подписанного сообщения — подлинным. Если подпись неверна или повреждена — мэйл-клиент сигнализирует об этом факте, свидетельствующем о возможной попытке подделать сообщение. Если же сертификат отправителя не несёт доверенной подписи УЦ, а подписан УЦ, открытого ключа которого нет в хранилище мэйл-клиента (то есть данный УЦ не имеет априорного доверия), либо вообще имеет только автоподпись, мэйл-клиент не может определить подлинность сообщения, предоставляя пользователю решать самому (мэйл-клиент в этом случае может только судить о целостности сообщения, исходя из состояния цифровой подписи отправителя).
Вы можете самостоятельно выбирать, доверяете ли Вы тому или иному удостоверяющему центру и выпущенным им сертификатам; либо можете запретить наследование доверия для конкретного пользовательского сертификата, если по каким-то причинам считаете его поддельным или скомпрометированным.
SSL-сертификаты — это те же X.509 с несколько иными полями, поэтому к ним применяются такие же правила. Если сервер поддерживает SSL-шифрование, то при обращении к нему клиента, сервер передаёт ему свой сертификат. Клиент проводит проверку, аналогичную описанной выше. Однако следует помнить, что SSL лишь защищает от перехвата трафик, передаваемый между клиентом и сервером, а X.509 только препятствует спуфингу, т.е. атакам по типу "человек в середине" и подделке адресов защищённых сайтов. Сертификат не является поручительством в доверии серверу: его оператор волен выдать третьей стороне весь переданный трафик без всякого ведома пользователя.
... Забыл отметить, что кроме проверки подписи УЦ с полученного сертификата, клиентская программа, запросив от УЦ реестр аннулированных сертификатов (CRL, адрес которого, как правило, указан в самом сертификате отправителя письма или SSL-сертификате), проверяет, не был ли он аннулирован отправителем или самим удостоверяющим центром. В случае, если в запрошенном CRL оказывается серийный номер данного сертификата, программа выводит предупреждение.
Доброго времени суток.
Что такое PEM подписанное письмо?
Если я получил письмо подписанное сертификатом УЦ которого нет вхранилище браузера или майл-клиента, но УЦ существует. Я должен вручную установить сертификат УЦ, если я верно рассуждаю. В данном случае уровень доверия решается опять же мной лично? Есть ли способ все таки проверить подлинность?
PEM (Privacy Enhanced Mail) — аналог S/MIME, форматировавший сообщение не в MIME, а непосредственно в тело сообщения, как ранние версии PGP. Ныне почти не используется.
По второму пункту Ваши рассуждения верны. Вы сами должны установить корневой сертификат УЦ (с его сайта, вероятно). И надеяться, что полученная копия не подменена. :) Некоторые УЦ позволяют сверять отпечатки своих корневых сертификатов по телефону.
На мой взгляд, PKI основанное на X.509 — пустая трата денег. Нет такой ситуации, когда X.509 — правильное решение какой-то проблемы безопасности. Использовать сертификаты X.509 приходится только тогда, когда кто-то (обычно госструктуры) этого требует.
Ни один УЦ внесенный в список браузеров и почтовых клиентов не заслуживает никакого доверия (вы договор прочитайте — и поймете, что деньги они просят ни за что: это просто рэкет)
В своей практике я сталкивался только с двумя людьми, которые пользовались почтой S/MIME, и в обеих случаях это было связано с их работадателем — государством (США и Республики Ирландии, соответственно). PGP распространено значительно больше (скорее всего на несколько порядков).
В случае SSL статистика есть: примерно 99% всех https серверов работают с либо само-подписанными сертификатами, либо с сертификатами "непризнанных" УЦ, которых в списках браузеров при установки нет.
Пользуются услугами "признанных" УЦ в основном банки и страховые компании (а также преступники занимающиеся phishing-ом, и некоторые лохи), для которых сертификат — электронный эквивалент гранитно-мраморной облицовки офиса: показательная трата денег в целях подачи сигналов респектабельности. К безопасности это не имеет никакого отношения, что прекрасно иллюстрирует размер колоссальных убытков от phishing.
Как говорится, привет от Иана Григга. :)
!!(green)
© Нильс Фергюссон, Брюс Шнайер "Практическая криптография"
!!
Неправда Ваша!
По поводу статистики смотрим сюда: Secure Server Survey[link3]
Бесплатные SSL сертификаты для тестирования[link4]
На мой взгляд сертификаты X.509 все таки довольно удобная вещь. Пользователь практически избавлен от, все таки нужно признать, достаточно сложной первоначальной настройки приложений на основе стандарта OpenPGP, создания и подписи ключей и т.п., хотя конечно не избавлен от процедуры получения самого сертификата. Однако это все таки много менее гибкая система и на мой взгляд больше подходит, простите за слишком утрированное выражение, "домохозяйкам". Для обеспечения более надежной защиты информации, а так же более гибкой настройки самой системы защиты лучший выбор – приложения на основе стандарта OpenPGP, к тому же в конечном счете позволяющие достичь не меньшего (и даже большего) уровня автоматизации чем защита почты с помощью сертификатов X.509. Ну и конечно же OpenPGP предоставляет много дополнительных функций, обеспечивающих использование "хоть куда".
А можно проверить подпись письма с подписью s/mime читая его в браузере через web? Ведь браузеры то же имеют сертификаты известных центров, выдающих сертификаты.
В браузере Вы не читаете письма, Вы лишь просматриваете веб-страницы своей почтовой службы, которая превращает MIME-форматированное сообщение в воспринимаемый браузером HTML-код (попутно насовав в него рекламы и ненужных трёхэтажных меню). Сам браузер не имеет таких возможностей, чем, собственно, и отличается от мэйл-клиента.
В принципе то, о чём Вы говорите, возможно, если непосредственно почтовый сервис имеет поддержку S/MIME. Mail.ru отображает состояние цифровой подписи S/MIME (зашифрованное сообщение она показать не сможет, потому что сервер не располагает Вашим закрытым ключом, чтобы его расшифровать). Только можно ли доверять этому индикатору? Вообще-то он может показывать всё, что угодно и что захочется администратору сервера. Мэйл-клиент же, скачав письмо к Вам в компьютер, проводит проверку подписи именно у Вас, что всё-таки располагает к большему доверию.
Какая тут неправда? Все сходится. Посмотрите список CA в любом браузере или почтовом клиенте, и убедитесь сами, что по данной статистике меньше 1% всех SSL-сайтов сертифицированы <<правильно>>.
Удобство и безопасность — вещи трудносовместимые. Но не только в этом дело. То, что по умолчанию в некоторые почтовые клиенты уже встроена поддержка S/MIME — следствие коррупции.
Сертификат X.509 — в лучшем случае эквивалент гранитно-мраморной облицовки офиса и золотого ролекса на запястье(*), а в худшем случае просто выброшенные деньги. Безопасности он вам не прибавит по сравнению с самоподписанным сертификатом.
(*) Заметим, что сертификаты X.509 особенно популярны среди банков и страховых компаний, точно так же, как и гранитно-мраморная облицовка оффиса. По той же самой причине. Это — некий сигнал респектабельности, рассчитаный на <<Неужели я понесу свои денежки в банк, у которого даже на сертификат нет денег?>>.
Налицо подмена понятий. Нельзя недостатки конкретной реализации стандарта OpenPGP сравнивать с X.509 "вообще". В X.509 точно так же, как и в OpenPGP создается пара ключей. Только в X.509 открытый ключ, как правило, заверяется всего одной подписью (CA), а в OpenPGP – многими (WoT). Хотя в обеих стандартах можно делать наоборот.
Что самое смешное, X.509 разрабатывался изначально для автоматизированного, промышленного и крупнокорпоративного применения (серверы, платежные системы), openPGP – больше для индивидуального.
Но каждую электронную финансовую систему или систему документооборота все равно разрабатывают с нуля, Шнайер-Фергюссон рекомендуют использовать самостоятельно спроектированные сертификаты на основе ключей с добавленными полями. И критикуют X.509 за полный бардак в этом формате.
Кроме того наличие неких независимых центров заверения сертификатов для разворачивания инфраструктуры PKI действительно себя не оправдало.
Классические случаи: люди получали сертификаты Microsoft по липовым документам и на основе этого могли (если бы успели) заверять свои программы.
Иногда, в нарушение правил можно было получить сертификат даже по телефонному звонку. Как после этого можно доверять центрам сертификации?
Не надо абсолютизировать и совмещать. Продуктивнее использовать шкалу "удобство-безопасность". Сами по себе X.509 мало от чего защищают. Но зато и сужают круг мошенников, и увеличивают количество оставляемых ими следов, чем существенно удешевляют процедуру их поиска и помещения в тюрьму надолго. Использование правильных криптосредств увеличивает безопасность коммуникаций, но ценой затрат клиента. Какой рынок у таких средств? Сколько клиентов готовы на установку у себя дополнительных средств и на обучение работы с ними? Что они получат взамен? Уменьшение вероятности разборок с банком? Но как убедить суд в том, что процедура подписания сертификата была проведена как положено?
Не проще ли, вообще не используя никаких криптосредств, общаться лично?
Это самый безопасный и самый неудобный способ. Но есть государства, где навязываемые криптосредства, ещё опаснее, неудобнее и дороже.
ivlad, в данном случае речь шла о выборе системы защиты для потенциально желающего защитить свою почту пользователя. Unknown и Д. Надь дали хорошую пищу для размышлений.
Elk очень хорошо подитожил, это лишь проблема выбора адэкватного решения, я согласен. Но я просто не хочу приводить в сотый раз мнение Шнайера, он целые главы своих книг посвятил критике системы PKI и я с ним согласен (редко когда бывает наоборот). Его мнение просто уничижительно: сертификаты это иллюзия безопасности и часто лишь средство обмана покупателей липовым доверием и тому есть множество почти анекдотических примеров. Сертификаты хорошо работают на бумаге, но в реальном мире слишком много способов их обойти.
В принципе, в сертификатах нет ничего плохого, если бы они не претендовали на решение слишком многих задач. Мы не можем оперативно проверить, отозван сертификат или нет, не можем проверить по каким законам он выдавался.
Возможно, когда-нибудь сертифицирующие центры будут чем-то вроде нотариальных контор, но я сильно в этом сомневаюсь.
А разве не существует CRL?
Деятельность сертификационных центров проверяется аудиторами.
А что касается PGP — здесь понятия CRL вообще нет.
Yuri,
Например? У каких аудиторов я могу подробнее узнать о деятельности, скажем, Verisign? Публикуется ли эта информация открыто, есть ли, например, статистика по качеству: сколько сертификатов было выдано, сколько из них оказались поддельными, список таких сертификатов? И т.д.
Да, данная информация открыто публикуется.
Отчет о проверки VeriSign'а доступен здесь:
https://cert.webtrust.org/SealFile?seal=304&file=pdf
Списки отозванных сертификатов также открыто доступны. :-)
--
Yuri
Народ, читайте Шнайера хотя бы иногда. Он часто говорит дело, даже в ущерб собственному бизнесу.
Ему наверное было бы тоже выгоднее заниматься сертификатами и прочими необременительными источниками получения прибыли под маркой консультаций в области ИБ. Только у бизнеса, связанного с сертификатами, плохая репутация. У кого нет под рукой книг, вот цитаты (я не могу напечать все, там еще много интересного):
#========
Хорошая книжка. Позавчера заказал себе в bolero.ru и не очень дорого.
... Спасибо, что название поправили, а то еще кто-нибудь себе не то закажет, хотя у Шнайера все книжки хорошие.
Кстати, после "прикладной" – "секреты" и "практическая" сначала показались скучными, все это сто раз вроде уже известно и в CRYPTOGRAMM печаталось, но только со временем понимаешь, насколько глубокие и проницательные вещи там изложены таким простым языком. (Мне никто не платит за рекламу. Это я сам так считаю)
Вопрос к владельцам русского издания "практической...":
Есть ли там предметный указатель?
Дело в том, что я в свое время заказал из Москвы "Прикладную..." так как даже с доставкой из России в Канаду это было значительно дешевле, чем купить оригинал. Но в русском издании (Wiley & Триумф, Москва, 2002) нет предметного указателя, и поэтому пользоваться книгой как справочником (для чего я ее, собственно, и купил) не очень удобно. И качество перевода иногда хромает, но так как я читал (из библиотеки) оригинал, это меня не сильно смущает (хотя понятия "множитель" и "делитель" путаются регулярно, что, конечно, раздражает). Но без предметного указателья ценность книги существенно падает.
Вообще, я согласен с Unknown, что Шнайера надо слушать и читать. Даже если я не во всем с ним согласен, мало кто так глубоко обдумывает проблемы инфо-безопасности и так чесно и понятно их излогает. Насчет X.509 — у нас нет с ним разногласий. :-)
Недоверяете VeriSign/Thawte/TrustCenter и другим центрам? Нет проблем, удалите их сертификаты из браузеров. Сделайте свой корпаративный/банковский центр сертификации и выдавайте сертификаты сотрудникам/клиентам банка. Добавьте корневой сертификат своего центра в браузер, и вы будете доверять всем интранет сайтам компании/банка. Какие проблемы?
По поводу Джоан Робинсон и ее сертификата. Если сомневаетесь, дык позвоните своей подруге и уточните fingerprint сертфиката. Какие проблемы?
Теперь рассмотрим PGP web of trust. Вы получили емейл от Васи Пупкина с цифровой подписью. А как проверить что этот ключ был сгенерен самим Пупкиным а не каким-нибудь прыщавым студентом? Хорошо, будет это ключ подписан ключами Иванова Ивана Ивановича и Вовочкой. А как проверить что эти ключи не были сгенерены тем же самым студентом? А можно еще взять базу по прописке и нагенерить стоооооолько ключей...
Хорошо, вы говорите что должна быть цепочка доверия, т.е. A доверяет B, B доверяет C, C доверяет D, etc; в таком случае A доверяет D... Здесь слишком много промежуточных звеньев... Какими критериями пользовался C подписывая ключ D? Проверял ли он/оона fingerprint ключа по телефону? Знает ли он/она лично D? На практике это работает только в узком кругу и с цепьями доверия небольшой длины...
Практический пример: я скачиваю из интернета новую версию GPG 1.4.2. Win32 binary подписан ключом некого Werner Koch (gnupg sig) <dd9jn@gnu.org>. Ключ проэкспайрился 30.12.2003. Версия 1.4.2 вышла 27.07.2005.
Я не знаю лично ни одно из тех кто подписал ключ Вернера. Среди моих знакомых использующих PGP/GPG нет никого кто знает лично одно из тех кто подписал ключ Вернера... Цепи доверия нет.
Вопрос: доверять ли мне этому релизу GPG?
Где гарантии того что скачал я этот билд именно с настоящего сайта www.gnupg.org, и это все (включая public key servers на которых я получил этот ключ) не дело рук того самого прыщавого студента который работает сисадмином сети домашнего интернета?
PS. У меня нет времени на то чтобы самостоятельно изучать исходники...
У меня ровно такой же вопрос...
http://lists.gnupg.org/piperma.....e/2005q3/000200.html[link5]
[quote:ec40b1ee6d="Werner Koch"]From time to time I prolong the expiration date; thus
Есть! Хотя книга совсем небольшая, зачем он там? Я даже в "прикладной" помню на какой странице что искать.
"Практическая" на справочник вообще не тянет, это вам не "прикладная" и не HAC. В ней мало материала и собраны лишь весьма оригинальные мысли авторов по некоторым аспектам. Ее ценность IMHO только в этом.
Да, ценники на книги у вас просто убийственные, может google сможет сделать полную online-библиотеку для научных книг (наподобие citeseer)? (Опять copyright тормозит прогресс). Потому что теже издания Springer в России малодоступны для заказа по ценам и неудобны по онлайн-подписке.
Боюсь, что тоже. Переводчики может и старались, но явно спешили. В "практической" есть и опечатки и сдвоенные абзацы.
Шнайер именно к этому и призывает, разве вы не поняли? Пусть банк отвечает за свои сертификаты сам, если он широко известен, то все проблемы с безопасностью сертификатов пусть отражаются на его репутации. Нечего будет перекладывать ответственность на посторонний ЦС.
Вообще, лучше никому не давать ключи от своей квартиры и отвечать за них самому, но если временно очень нужно, то дайте их проверенным близким людям – друзьям, родственникам, хорошим соседям.
Но дадите ли вы ключи кому-то, кто рекламирует себя как "супер-пупер-доверенный" центр?
Дык, а зачем тогда вообще CA?
Чтобы понавешать на ее ключ кучу ненужного и потенциального недостоверного мусора, обозвать это сертификатом, который якобы что-то удостоверяет и взять за это деньги?
Мы с ней и так сгенерим ключики, мило поболтаем по телефону насчет шестнадцатиричных отпечатков, не привлекая к помощи никакой CA.
Не забывайте еще, что X.509 разрабатывался очень плохо, это пример того, как не надо делать стандарты.
В мире нет ничего совершенного. И у Шнайера есть скептицизм по поводу сетей PGP, он так же как и Вы считает, что они слишком сложны для правильного применения простыми пользователями. Но такова цена безопасности.
Ключевое слово Win32. Сколько из-за него проблем. В Linux вам бы такой вопрос даже в голову бы не пришел. Там все уже придумано за вас.
В составе ОС есть пакет debian-keyring, ключи из которого занимают самый высокий рейтинг в сети доверия. Все разработчики Open Source повязаны этой сетью друг с другом. Через любой пакет из вашего дистрибутива свободной ОС вы можете дотянуться до ключа разработчика gpg. Плюс есть еще масса параллельных способов, списков рассылки. Да сходите в Интернет-кафе, там ключи сверьте (предварительно избавьтесь от слежки).
Осените себя святым пингвином, вступите в ряды религиозных фанатиков Open Source и найдите местную подпольную ячейку этой всемирной сети. Кодовое слово – LUG (Linux Users Group). Через нее вы сможете протянуть сеть доверия до других пользователей этой ОС (если они этого хотят) и протянуть независимые цепочки до ключей разработчиков.
Да, проблема в том, что PGP разрабатывался когда-то как революционный и полузапрещенный продукт. Такой же повстанческий настрой сохраняется отчасти и в GNU/GPL/Open Source движении. Можно признать, что идеологически это не подходит простым нормальным пользователям (не энтузиастам, не параноикам, не фанатам, не членам небольших групп). Поэтому, несколько нонконформистская модель доверия сетей PGP не поможет вам связаться с Васей Пупкиным и Машей Дудкиной. Проще уговорить их пару раз щелкнуть мышкой для получения сертификата.
Но если сравнивать все достоинства и недостатки, модель PGP лучше, чем PKI. Ей есть место и в частном применении и в бизнесе. А разработка и безопасная эксплуатация некоммерческих Linux-дистрибутивов, ядра Linux, напрямую с ней связана.
Где гарантии, что сертификат, выданный этому сайту настоящий? Где гарантии, что сайт не взломан? Где гарантии, что сертификат не похищен?
Вот еще пример использования gpg:
Например, Linux пакеты распространяются не только с официальных сайтов, но и с сотен зеркал.
Их нередко взламывают, но это не несет серьезной угрозы.
Зеркалирование часто осуществляется и в бесплатной и ненадежной локальной сети и на своем винчестере, можно обмениваться пакетами на носителях с "неблагонадежными людьми". Любой носитель или сайт, даже сделанный "прыщавым админом местной локалки" воспринимается как зеркало официального (или его часть), но благодаря системе подписей всех пакетов ОС Linux, вы можете быть уверены, что никто вам ничего не подменил.
Эта система может и неидеальна, но в течении многих лет показала гораздо большую безопасность, чем сертификация сайтов. Проверено практикой.
Действительно, в мире X.509 для Вас бы такой вопрос и не встал, раз каждый сертификат отслеживается по одной линии сертификации к (не) доверенному корню. С PGP D доверяет не только C, но, наверняка, ещё и F, G, K и, быть может, V, к каждому из которых A может найти альтернативные пути подтверждения. A не обязяна полагаться лишь на практику заверения C (в отличие от Х.509, где у Вас просто нет выбора), поскольку маловероятно, чтобы все C, F, G, K и V были псевдонимами одного лица и заверили такой же липовый ключ D. Если так, то C, F, G, K и V наверняка не несут независимых подтверждающих подписей. Или несут от других псевдонимов, а те — от третьих, и мы получаем всю Сеть доверия, состоящую из ключей прыщавого админа (или АНБ)? Вспоминая старика Окамма, допущу, что маловероятно.
Она есть. В разделе Keyserver[link6] для этой цели есть ряд специальных инструментов. Наверняка Вы сможете проследить хотя бы несколько цепочек доверия от своего ключа или ключей каких-то авторитетных пользователей к ключу Вернера Коха.
Yuri,
Это больше похоже на описание системы, чем на аудиторский отчёт.
Ну раз Вы так против сети доверия PGP, а доверяете лишь X.509, то никто не запрещает Вам заверить ключ PGP сертификатом X.509. Читайте раздел руководства "управление ключами".
...и волки сыты и овцы целы.
А в разве в PGP нельзя создать такую структуру? Прихожу я в банк с дискетой на которой мой открытый ключ, показываю паспорт, банк ставит на мой ключ свою ЭЦП и делов то, разницы нет.
А если некто из банка выдаст Ваш сертификат еще кому-то, т.е. выдавать вообще ничего нельзя, только подписывать, Вы неверно выразились.
Постановка вопроса в данном ракурсе (в сравнении с банком) некорректна. Вы уж если сравниваете X/509 и PGP, то делайте это в одной плоскости, а то как приемущества PKI так банк, а как письмо Васи Пупкина, так сразу о прыщавых студентах.
Еще по поводу сертификатов X/509, раз уж пошел такой диалог. Используются они таким образом, что доверие наследуется от сертификата, установленного в браузере. А ведь нет никаких гарантий, что сертификат установленный в браузере "тот самый", Вы проверяли? Откуда доверие? А если я работаю с сертификатом который в браузере не предустановлен, Вы должны его установить сами, например с сайта скачать (опять же откуда доверие?), а после Вы забудете об этой секундной операции и будете пребывать в уверенности что сертификат настоящий (такова психология), а там может лажа самая натуральная. Одним словом при очень высоких требованиях к безопасности переписки хоть в случае PGP, хоть в случае X.509 & PKI нужна очень доскональная проверка, вплоть до поездки и обмена ключами при личной встрече в случае PGP или командировки в УЦ и личной встречей с его персоналом в случае PKI (что по моему менее надежно), т.к. билет на самолет окажется дешевле, чем потеря целого состояния или появление дезинформации в политической деятельности например. Так уж лучше тогда выбирать PGP, все таки и сервис побольше и светится в УЦ не нужно да еще денги платить, полюс имеется сеть доверия. А сеть все таки работает весьма убедительно, если даже Вы лично не знаете подписавших ключ людей, можете проверить отпечатки и посмотреть кто подписал ключ, насколько известен человек, который вряд ли захочет портить себе репутацию не глядя подписывая неизвестные ключи, кем подписаны ключи подписавших в свою очередь, словом насколько разветвлена сеть, тут чем дольше в лес, тем больше дров, а в случае переписки с людьми активно использующими PGP эта сеть может оказаться практически бесконечной – настоящая паутина, и вряд ли какой-либо студент нагенерирует такую сеть самостоятельно. Если Вы используете защиту почты при частной переписке, вряд ли кто будет утяжелять вопросы доверия работая хоть с PGP хоть с X/509, а о подлоге в таких случаях чаще можно догадаться, в конченом счете позвоните по телефону своему другу и сверьте отпечаток, если переписка серьезна, то Вы это сделаете. А если Вы переписываетесь с друзьями, то чаще можете обменяться бесплатными ключиками лично.
И я уже не вспоминаю о длине ключей, которые в X/509 как правило не превышают 1024 бит, ну может и настанут лучшие времена…
Вообще здесь такая теория: ставим кубики вертикально, один на другой (X/509) и стреляем из рогатки, каков результат – при попадании в один из кубиков падает все что выше (в сети PKI все что ниже, но принцип один). В сети доверия кубики лежат гораздо более сложной структурой, и в большей степени горизонтально, да еще и цепляются друг за друга случайным образом, недаром это сеть а не вертикальная структура, каков будет результат…сказать трудно, но однозначно менее разрушительным.
Вообще я думаю, что в будущем нас возможно ожидает нечто вроде электронной паспортизации, в которой государственный УЦ (например местное отделение МВД или нотариальная контора, о чем писал unknown) будет обеспечивать получение электронного удостоверения, а местный же сервер, ключ которого заверен вышестоящими гос. структурами, будет доступен для скачивания с него заверительных сертификатов. Самый главный сертификат будет выдаваться тем же отделением, что бы не качать его откуда не поподя. Но все это сильно напоминает X/509, достаточно одной коррумпированной личности и появление левых сертификатов обеспечено.
Вообще, если не считать огромное приймуществo в установленной базе ПО, то у PKI&X.509 нет никаких приймуществ по сравнению с PGP WoT. Любая схема осуществимая при помощи X.509 также осуществима при помощи PGP. Обратное утверждение, однако, неверно.
Система PKI также страдает проблемой глобального секрета. Ключ УЦ является таковым. То есть его стоимость является суммой стоимостей всех ключей и по мере увеличения числа пользователей постоянно возрастает. То есть мы быстро достигаем ситуации, когда игра во взлом, воровство или покупку данного ключа уже стоит свечь. Государственный УЦ должен будет тратить все возрастающие средства на защиту своего ключа. И этим затратам нет предела и конца! Так что разумное государство в такие игры играть скорее всего не станет (хотя на разумность государства рассчитывать не всегда приходится).
У PGP WoT с масштабируемостью нет таких проблем.
Государства очень часто оказываются в ситуации, когда огромные расходы не в интересах государства, но в интересах принимающих за него решения. Любой повод перекачивания налоговых денег в частные карманы имеет шанс на реализацию, и к сожалению, государственный УЦ — прекрасная возможность для такой халявы. Так что несмотря на все разумные аргументы против, такой урод к сожалению имеет некоторые шансы на рождение и дальнейшую жизнь (до неминуемого обвала системы из-за утечки глобального секрета).
Но несовершенства представительной демократии (или не-демократии — это несущественно) уже не относятся к теме форума. :-)
К великому сожалению.
Не надо путаницы в понятиях. Страна – это мы (когда не на службе), но государство всегда – они. Все решения, принимаемые государством, принимаются ими в своих интересах. Задача населения – поставить госслужащих в такие условия, чтобы интересы государства по-возможности приближались к интересам страны.
С этим я полностью согласен, но нинкто ничего не перепутал.
А вот это — неверно. Финансирование дорогостоящих, заведомо провальных программ за счет разорения гос. казны — не в интересах государства, но очень часто в интересах его представителей. Такая практика может кончится даже крахом государства (см. бСССР). Об интересах страны и их соответствии интересам государства в данном случае речь не идет.
Учреждение государственного УЦ приведет к возрастающим затратам на защиту закрытого ключа корневого сертификата. При том, что эту гонку вооружений можно только проиграть. Это — ни коем образом не в интересах государства. Зато те, кто предоставляют услуги по защите ключей, очень здорово на этом будут зарабатывать, и платить нужные откаты. Те, кто принимают решение за государство — богатеют, а государство беднеет.
Стране это тоже нинчего хорошего не принесет, но это уже другой вопрос и это не политический форум.
Ничего не понимаю...
Просто пишется, что мой ключ не найден: Key not found: "0x500B8987"
И как я могу проверить цепочку доверия, если я ни одного ключа не подписал?
0x500B8987 Нашелся с первой же попытки на keyserver.kjsl.com
Вы подписать по идее должны уже после того как провели проверку. В конечном счете можете подписать ключ известного человека, который прочно заверен, или проверить сеть доверия от ключа этого человека. Там ведь написано (обычно Вашего), но не (Обязательно Вашего). Но если Ваша переписка стоит $ миллион, то лучше пожалуй ключами обменяться лично (мое мнение), и фактор здесь даже не только тот – доверять сети доверия или нет.
Традиции бСССР продолжаются. Только пока не в области государственной цифровой сертификации. Так, немного помельче.
Вот мне кажется образец случая, о котором говорит Д. Надь.
В порядке оффтопика и не для обсуждения в этой ветке можете посмотреть ссылки на скандальные попытки введения криптозащиты в кассовых аппаратах. Много шума наделали в начале года. Приходите вы в магазин, платите деньги в кассу и не подозреваете, что там ГОСТ внутри!
http://vologda.allbusiness.ru/.....sAMShow.asp? ID=19793[link7]
http://www.business-magazine.ru/news/different/176644/
http://www.usinsk.info/printarticle1838.html
http://region.adm.nov.ru:8080/.....w? AWhat=2&Aid=423973[link8]
http://smi.kuban.info/article/9292/1002/
http://www.rosalcohol.ru/site......4&table=bmV3c192aW5v[link9]
Если я заведу ящик на Safe-mail.net и буду пользоваться web-доступом и POP/SMTP (без PKI), то какова вероятность перехвата моей почты на отрезке Я-Сервер?
Я ничего не понимаю в этих сертификатах и это для меня китайская грамота. Допустим, Web-почта с SSL Server Certificate Issued by Equifax. Это надежно или могут перехватить письма в то время, когда их читаю/пишу? Когда заходишь на стр., то браузер серт. предлагает просмотреть. Ну там даты и еще какая-то лабуда, мне непонятная.
Вы ставите вопрос слишком обще. (Например, непонятно, какова ценность Ваших писем, от кого Вы их желаете защитить, даже каким пользуетесь браузером, какой веб-почтой и как открываете её страницу — всё это существенно, как и многое другое.) С уверенностью отвечу так: взлом SSL-защищённого трафика представляется наименее вероятным вектором атаки. Значительно проще скорее всего внедрить в Вашу систему трояна или, скажем, организовать pharming-атаку, изменив DNS-запись почтового сервера и перенаправив Вас на подставной.
Из всей этой "лабуды" для Вас действительно важны две вещи:
1. Кому выдан сертификат. Это поле Issued To:Common Name, и в нём должен быть указан точный URL (то бишь адрес) Вашего почтового сайта. Если браузер предупреждает, что это поле не соответствует адресу сайта, это первый повод для беспокойства. (В действительности, это совсем не обязательно означает факт проведения атаки. Но если администрация сайта не способна грамотно настроить SSL, доверять такому сайту не стоит — наверняка там полно других дыр.)
2. Кем выдан сертификат. Поле Issued By:Common Name. Что-либо здесь проверять не нужно, но если браузер сообщает, что сертификат выдан удостоверяющим центром, не входящим в список доверенных, и Вы не способны установить подлинность сертификата УЦ, это тоже повод для подозрений. Впрочем, здесь всё зависит от Вашего уровня экспертизы и ценности писем.
Здравствуйте!
Некоторые сертификаты сайтов, например сертификат webmoney Transfer, содержит несколько записей сертификата. При этом в их свойствах указаны разные организации. То же самое касается сертификатов УЦ, правда организация там всегда одна, но разные отпечатки у разных записей. Это означает, что один и тот же сертификат подписан несколько раз разными ключами?
И попутно еще один вопрос. Скажите, чем принципиально (технически) отличается VPN соединение от обычного SSL соединения. Можно ли рассматривать VPN соединение как частный случай SSL, применяемый между провайдером и клиентом (или между двумя клиентами)?
Про SSL – очень коротко и доступно – скачайте, пожалуйста, файл с хорошо известного всем сайта сертификации http://www.thawte.com/
http://www.thawte.adgrafics.net/ssl_ru.pdf (283 КБ) (на русском)
Там схема и основные принципы.
Если чужими словами, то:
По VPN хорошо изложено на (со схемой):
http://www.nestor.minsk.by/sr/2005/03/050315.html
Сам путаюсь! :D
Добрый день!
Для возможности работы в системе WM из под Linux я зарегистрировался в системе способом light. В связи с этим возникло несколько вопросов.
После регистрации я стал обладателем сертификата x.509, который после резервного копирования из Firefox представлен у меня в виде файла *.p12, а после резервного копирования из IE я получил файл формата *.pfx (на всякий случай сделал и такую операцию).
1. Чем отличаются эти файлы (сертификат то один)?
2. Насколько безопасно хранилище сертификатов Software Security Device, где оказался мой сертификат (Firefox), и насколько безопасно хранилище сертификатов IE (отсек личных сертификатов).
Теперь главный вопрос.
Зашифрован ли секретный ключ сертификата паролем? Или же пароль вводится только для доступа к хранилищу сертификатов, в то время как сам закрытый ключ существует в незашифрованном виде? Дело в том, что при работе в Firefox я сразу получал доступ к кошельку, без ввода пароля, пока не настроил хранилище на работу через пароль.
1. Просто разные расширения. Экспорт в любом случае происходит в формате PKCS#12.
2. Хралище IE — это системное приложение, привилегии определяются и исполняются на уровне ОС, так что если Вы доверяете системе, можете доверять и ему. В Firefox хранилище может быть опционально зашифровано мастер-паролем. Причём расшифрование может происходить как на весь сеанс работы, так и одномоментно только для использования сертификата. В идеале, конечно, стоит разместить сертификат на смарт-карте: и Windows, и Firefox это позволяют.
Как я уже отметил, и в системной хранилище Windows (IE), и в Firefox, контроль доступа осуществляется только на уровне хранилища (более дробно — на уровне отсеков в IE), но не на уровне индивидуальных элементов — паролей, там, сертификатов. Просто в Firefox можно зашифровать хранилище целиком. А в системное хранилище ОС и так зашифровано, но схема шифрования весьма запутанна и для меня мало понятна.
В целом как я понимаю суть та же, что и в OpenPGP, где я подписываю открытый ключ, т.е. издаю сертификат подписи и прикрепляю его к открытому ключу пользователя, которым заверяю его открытый ключ. Каким образом данная подпись распространяется на закрытый ключ той пары, открытый ключ которой подписан? Для этого созданы перекрестные подписи? Есть ли они в сертификатах x.509? Или считается, что если открытый ключ подписан, то сертификат подписи автоматически распространяется и на закрытый ключ?
И дополнительно хочу поинтересоваться. Существует ли практика подписывания файлов (например дистрибутивов программ) непосредственно в УЦ, т.е. закрытым ключом УЦ, или как правило для этого организация получает свой сертификат с наследованным от УЦ доверием и уже с его помощью ставит ЭЦП?
А они математически связаны. Хотя, конечно, ничто не мешает Вам сделать несовместимые друг с другом открытый и закрытый ключи, только проку от них никакого не будет.
Кстати, такая же ситуация с ключами OpenPGP. Не путайте открытые и закрытые ключи с базовыми ключами и подключами. Первые в рамках протокола связаны только номерами ID (чтоб программа знала, какой закрытый ключ использовать для зашифрованного сообщения). Вторые — базовые ключи открытые и открытые подключи — действительно заверяются перекрёстными подписями во избежание подмены.
Корневой ключ УЦ применяется только для заверения других сертификатов — это требование формата X.509. Технически, УЦ может создать специальный code-signing-сертификат, заверить его корневым ключом, и уже его использовать для подписания программ.