Получение сертификата x.509 и личная безопасность

Проблема в том, как увязать внутреннюю учетную запись с сертификатом, что бы сертификат заработал.

Сертификат всегда ассоциируется с явным 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, как таковой, вообще не оговаривает, какие данные в рамках заданных полей в него можно кодировать, оставляя этот вопрос на усмотрение стандартов и реализаций.

где применяется формат X.509, вроде тех же S/MIME или SSL, таких ограничений не накладывают, а вот реализации — могут.

The code doesn't currently take note of the permitted

symmetric encryption algorithms as supplied in the
SMIMECapabilities signed attribute. this means the user
has to manually include the correct encryption algorithm.
It should store the list of permitted ciphers in a
database and only use those.

Да, похоже такое ограничение конкретно для 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 оказывается серийный номер данного сертификата, программа выводит предупреждение.

Доброго времени суток.

Получив S/MIME- или PEM-подписанное письмо

Что такое PEM подписанное письмо?

Если же сертификат отправителя не несёт доверенной подписи УЦ, а подписан УЦ, открытого ключа которого нет в хранилище мэйл-клиента (то есть данный УЦ не имеет априорного доверия), либо вообще имеет только автоподпись, мэйл-клиент не может определить подлинность сообщения,

Если я получил письмо подписанное сертификатом УЦ которого нет вхранилище браузера или майл-клиента, но УЦ существует. Я должен вручную установить сертификат УЦ, если я верно рассуждаю. В данном случае уровень доверия решается опять же мной лично? Есть ли способ все таки проверить подлинность?

PEM (Privacy Enhanced Mail) — аналог S/MIME, форматировавший сообщение не в MIME, а непосредственно в тело сообщения, как ранние версии PGP. Ныне почти не используется.

По второму пункту Ваши рассуждения верны. Вы сами должны установить корневой сертификат УЦ (с его сайта, вероятно). И надеяться, что полученная копия не подменена. :) Некоторые УЦ позволяют сверять отпечатки своих корневых сертификатов по телефону.

На мой взгляд, PKI основанное на X.509 — пустая трата денег. Нет такой ситуации, когда X.509 — правильное решение какой-то проблемы безопасности. Использовать сертификаты X.509 приходится только тогда, когда кто-то (обычно госструктуры) этого требует.
Ни один УЦ внесенный в список браузеров и почтовых клиентов не заслуживает никакого доверия (вы договор прочитайте — и поймете, что деньги они просят ни за что: это просто рэкет)
В своей практике я сталкивался только с двумя людьми, которые пользовались почтой S/MIME, и в обеих случаях это было связано с их работадателем — государством (США и Республики Ирландии, соответственно). PGP распространено значительно больше (скорее всего на несколько порядков).
В случае SSL статистика есть: примерно 99% всех https серверов работают с либо само-подписанными сертификатами, либо с сертификатами "непризнанных" УЦ, которых в списках браузеров при установки нет.
Пользуются услугами "признанных" УЦ в основном банки и страховые компании (а также преступники занимающиеся phishing-ом, и некоторые лохи), для которых сертификат — электронный эквивалент гранитно-мраморной облицовки офиса: показательная трата денег в целях подачи сигналов респектабельности. К безопасности это не имеет никакого отношения, что прекрасно иллюстрирует размер колоссальных убытков от phishing.

На мой взгляд, PKI основанное на X.509 — пустая трата денег.

<...>

Как говорится, привет от Иана Григга. :)