Здравствуйте, mikа, Вы писали:
M>Объясните мне на пальцах, как работает принцип этих сертификатов?
M>Линки тоже были бы сктати (но без всякой мути вроде OpenSSL).
M>Заранее благодарю.
Я, конечно, не специалист по безопасности, но кажется представляю...
Значит так:
1. Чтобы удостоверить подлинность сообщения, отправитель шифрует его (или его хэш — неважно) своим закрытым ключом, который есть только у него.
2. Чтобы получатель мог раскодировать это сообщение вместе с сообщением посылается открытый ключ.
И все бы хорошо, но ключ можно и подменить вместе с письмом.
Поэтому надо доказать подлинность и самого ключа.
3. По рекурсии ключ зашифровывается закрытым ключом, так же как и письмо. См. пункт 1
4. Так или иначе, чтобы раскрыть рекурсию на компе получателя должен быть хотя бы один открытый ключ, которому он доверяет. Такие ключи есть — они поставляются вместе с виндой. certmgr.exe поможет их посмотреть.
ИТОГО: к письму прилагается его зашифрованный хэш и сертификат x509, который представляет цепочку сертификатов, восходящую к какому-то корневому сертификату.
Сделать такой сертификат ручками невозможно, так как для этого нужно уже иметь доверяемый сертификат на компе получателя либо восходящий к таковому, поэтому такие сертификаты надо покупать у тех, кто это может сделать. Это например
www.verisign.com и
www.thawte.com.
Вот еще статеька по этому поводу, да и вообще там много чего есть... ну и гугль
Введение в криптографию
Cider
Здравствуйте, mikа, Вы писали:
M>Объясните мне на пальцах, как работает принцип этих сертификатов?
M>Линки тоже были бы сктати (но без всякой мути вроде OpenSSL).
M>Заранее благодарю.
"принцип сертификатов" работает
на пальцах:
сертификат::= { период действия; субъект; издатель; открытый ключ субъекта; другое инфо; ЭЦП издателя }
издатель == сертификат в "другом инфо" которого стоят соответствующие флажки
издатели::= { корневые; промежуточные }
корневые:
1) субъект==издатель
2) тело сертификата подписано приватным ключем соответствующим открытому в теле сертификата (само-подписанные).
промежуточные: все остальные издатели
проверка сертификата (уложить рекурсивно в процедуру построения цепочки сертификации от сертификата пользователя к доверенному корневому — для каждого сертификата в цепочке):
1) по времени действия
2) "математическая" — ЭЦП издателя
3) текущий статус — присутствует ли данный сертификат в списке отозванных (CRL) — распространяется издателем
4) контроль за непротиворечивостью "другого инфо" в данном месте цепочки сертификации
подробно: RFC3280
Удачи
