SSL-аутентификация путем сравнения отпечатка сертификата?

Вопрос для всех экспертов SSL:

У нас есть встроенное устройство с небольшим веб-сервером, и мы можем установить на нем собственные самоподписанные сертификаты SSL. Клиент написан в .NET(но это не имеет большого значения).

Как я могу аутентифицировать устройство в .NET? Достаточно ли сравнить отпечаток сертификата с известной записью в базе данных?

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

Или мне нужно создать собственную цепочку доверия, создать собственный собственный корневой сертификат CA, подписать сертификат веб-сервера и установить его на клиенте?

Ответ 1

То, что вы предлагаете, в принципе в порядке. Это, например, используется во время ключевых подписей сторон. Здесь участники обычно просто обменивают свое имя и отпечатки своих открытых ключей и убеждаются, что лицо на вечеринке действительно является тем, кого он/она требует. Просто проверка отпечатков пальцев намного проще, чем проверка длинного открытого ключа.

Другим примером является так называемая самостоятельная сертифицирующая файловая система. Здесь снова только хэши открытых ключей обмениваются по защищенному каналу. (I.e. эти хэши встроены в URL-адреса.) В этой схеме открытые ключи не нужно отправлять безопасно. Получателю нужно только проверить, что хэш открытых ключей сопоставляет хеши, встроенные в URL-адреса. Конечно, получатель также должен убедиться, что эти URL-адреса получены из надежного источника.

Эта схема и то, что вы предлагаете, проще, чем использование CA. Но есть недостаток. Вы должны убедиться, что ваша база данных с хешей является подлинной. Если ваша база данных большая, то это будет очень сложно. Если вы используете CA, вам нужно только убедиться, что корневые ключи аутентичны. Это обычно значительно упрощает управление ключами и, конечно же, является одной из причин, почему схемы на основе СА более популярны, чем, например, самоподтверждающая файловая система, упомянутая выше.

Ответ 2

Таким же образом вы не должны и не должны считать два объекта равными только потому, что их хэш-коды подобраны, вы не должны считать сертификат подлинным только потому, что его отпечаток появляется в списке "известного сертификата" отпечатки пальцев".

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

Ответ 3

Short:

Ну, в теории вы тогда делаете именно то, что делает Центр сертификации для вас. Так что все должно быть хорошо.

дольше:

Когда Центр сертификации подписывает ваш запрос с открытым ключом/сертификатом/сертификатом, он не подписывает все данные сертификата. Но только вычисленное значение хэша для всех данных сертификата. Это уменьшает подпись.

Если вы не хотите создавать свой собственный СА или использовать коммерческий/бесплатный, сравнивая отпечаток пальца с тем, которому вы доверяете, вы получите вторую наиболее надежную конфигурацию. Наиболее надежным решением могло бы быть сравнение всего сертификата, так как также защищает вас от атак с хеш-атаками.

Как заявили другие ребята, вы должны обязательно использовать безопасный/безопасный алгоритм хэширования. SHA-1 больше не защищен.

более подробная информация по этой теме: