[Ищу] Система сертификатов

[poligon]

Ищу модуль или хак для vbulletin 3.8.x систему цифровых сертификатов для пользователей.

 

[Дмитрий Кесаев]

Давай подробнее, о чем речь... Что за "цифровые сертификаты"?

Если про это:

Спойлер

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

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

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

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

Рисунок 1. Структура сертификата PKI​

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

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

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

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

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

То накуя?

 

[poligon]

Давай подробнее, о чем речь... Что за "цифровые сертификаты"?
Если про это:

Спойлер

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

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

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

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

Рисунок 1. Структура сертификата PKI​

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

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

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

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

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

То накуя?

Да что то вроде этого. Доступ к форуму только по сертификатам ну и логин пароль естественно. Для закрытого форума.

 

[Дмитрий Кесаев]

Такого нет. Только на заказ.
Глянь в сторону этого:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

Я поднимал тему, но знаний не хватает(((
Как вариант.
При авторизации каждому раздать картинки...

 

[PHPCod3r]

Картинки это конечно интересно, но серты имхо лучше, правда действительно совсем не ясно как это можно реализовать

К примеру хочется такое:
Что бы были сертификаты причем у каждого пользователя свои пасс к серту, и доступ в раздел естествено только для тех у кого есть
валидный серт.

Может кто подскажет в какую сторону копать что бы этого добиться?

 

[poligon]

Картинки это конечно интересно, но серты имхо лучше, правда действительно совсем не ясно как это можно реализовать
К примеру хочется такое:
Что бы были сертификаты причем у каждого пользователя свои пасс к серту, и доступ в раздел естествено только для тех у кого есть
валидный серт.
Может кто подскажет в какую сторону копать что бы этого добиться?

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

 

[PHPCod3r]

poligon Вы бы хотя бы указали точную ссылку на тот сайт где такое лежит, может вместе удасться найти)