13:51 Центр сертификации | |
| В криптографии , сертификат орган или орган по сертификации ( CA ) является объектом , который выдает цифровые сертификаты . Цифровой сертификат удостоверяет право собственности на открытый ключ по имени субъекта сертификата. Это позволяет другим (доверяющим сторонам) полагаться на подписи или утверждения, сделанные в отношении закрытого ключа, который соответствует сертифицированному открытому ключу. CA действует как доверенная третья сторона, которой доверяют как субъект (владелец) сертификата, так и сторона, полагающаяся на сертификат. Формат этих сертификатов определяется стандартом X.509 . Одним из наиболее распространенных применений для центров сертификации является подписание сертификатов, используемых в HTTPS , протоколе безопасного просмотра для World Wide Web . Другое распространенное использование - выдача удостоверений личности национальными правительствами для использования при электронном подписании документов. Стандарты валидации Коммерческие центры сертификации, которые выпускают основную часть сертификатов для серверов HTTPS, обычно используют метод проверки домена для проверки подлинности получателя сертификата. Методы, используемые для проверки домена, различаются между ЦС, но в целом методы проверки домена предназначены для доказательства того, что заявитель сертификата контролирует данное доменное имя, а не какую-либо информацию о личности заявителя. Многие центры сертификации также предлагают расширенную проверку(EV) сертификаты как более строгая альтернатива проверенным сертификатам домена. Расширенная проверка предназначена для проверки не только контроля доменного имени, но и дополнительной идентификационной информации, которая должна быть включена в сертификат. Некоторые браузеры отображают эту дополнительную идентификационную информацию в зеленом поле в строке URL. Одним из ограничений EV как решения слабых сторон валидации домена является то, что злоумышленники могут по-прежнему получать проверенный сертификат домена для домена-жертвы и развертывать его во время атаки; если это произошло, разница, наблюдаемая для пользователя-жертвы, будет заключаться в отсутствии зеленой полосы с названием компании. Возникает вопрос, могут ли пользователи распознать это отсутствие как признак того, что атака выполняется: тест с использованием Internet Explorer 7в 2009 году было показано, что отсутствие предупреждений IE7 об EV не было замечено пользователями, однако текущий браузер Microsoft, Edge , показывает значительно большую разницу между EV и сертификатами, подтвержденными доменом, с сертификатами, подтвержденными доменом, с полой серой блокировкой. Слабые стороны валидации Проверка домена страдает от определенных структурных ограничений безопасности. В частности, он всегда уязвим для атак, которые позволяют злоумышленнику наблюдать за проверками домена, отправляемыми ЦС. Они могут включать атаки на протоколы DNS, TCP или BGP (в которых отсутствует криптографическая защита TLS / SSL) или компрометация маршрутизаторов. Такие атаки возможны либо в сети около ЦС, либо вблизи самого домена жертвы. Один из наиболее распространенных методов проверки домена включает отправку электронного письма, содержащего токен аутентификации или ссылку на адрес электронной почты, который, вероятно, будет нести административную ответственность за домен. Это может быть технический адрес электронной почты, указанный в записи WHOIS домена , или административный адрес электронной почты, например admin @, administrator @, webmaster @, hostmaster @ или postmaster @ в домене. Некоторые центры сертификации могут принимать подтверждение, используя root @, info @ или support @ в домене. Теория проверки домена заключается в том, что только законный владелец домена сможет читать электронные письма, отправленные на эти административные адреса. Реализации проверки доменов иногда были источником уязвимостей безопасности. В одном случае исследователи безопасности показали, что злоумышленники могут получить сертификаты для сайтов веб-почты, потому что ЦС был готов использовать адрес электронной почты, например ssladmin@domain.com, для domain.com , но не все системы веб-почты зарезервировали имя пользователя «ssladmin» для предотвращения. злоумышленники от регистрации его. До 2011 года не было стандартного списка адресов электронной почты, который можно было бы использовать для проверки домена, поэтому администраторам электронной почты не было ясно, какие адреса необходимо зарезервировать. В первой версии Базовых требований к форуму CA / Browser , принятой в ноябре 2011 года, указан список таких адресов. Это позволило почтовым хостам зарезервировать эти адреса для административного использования, хотя такие меры предосторожности все еще не универсальны. В январе 2015 года финн зарегистрировал имя пользователя «hostmaster» в финской версии Microsoft Live и смог получить сертификат, подтвержденный доменом для live.fi, несмотря на то, что он не являлся владельцем доменного имени. Криптография с открытым ключом может использоваться для шифрования данных, передаваемых между двумя сторонами. Обычно это может происходить, когда пользователь входит на любой сайт, который реализует протокол HTTP Secure . В этом примере давайте предположим, что пользователь входит в систему на домашней странице своего банка www.bank.example для осуществления онлайн-банкинга. Когда пользователь открывает домашнюю страницу www.bank.example, он получает открытый ключ вместе со всеми данными, отображаемыми их веб-браузером. Открытый ключ может быть использован для шифрования данных от клиента к серверу, но безопасная процедура состоит в том, чтобы использовать его в протоколе, который определяет временный общий симметричный ключ шифрования; сообщения в таком протоколе обмена ключами могут быть зашифрованы открытым ключом банка таким образом, что только банковский сервер имеет закрытый ключ для их чтения. Затем остальная часть сообщения продолжается с использованием нового (одноразового) симметричного ключа, поэтому, когда пользователь вводит некоторую информацию на страницу банка и передает страницу (отправляет информацию обратно в банк), тогда данные, введенные пользователем, на страницу будет зашифрован их веб-браузером. Поэтому, даже если кто-то может получить доступ к (зашифрованным) данным, которые были переданы от пользователя на www.bank.example, такой перехватчик не сможет их прочитать или расшифровать. Этот механизм безопасен, только если пользователь может быть уверен, что это банк, который он видит в своем веб-браузере. Если пользователь вводит www.bank.example, но его связь перехвачена, и фальшивый веб-сайт (притворяющийся веб-сайтом банка) отправляет информацию о странице обратно в браузер пользователя, фальшивая веб-страница может отправить фальшивый открытый ключ. пользователю (для которого поддельный сайт владеет соответствующим закрытым ключом). Пользователь заполнит форму со своими личными данными и отправит страницу. Поддельная веб-страница получит доступ к данным пользователя. Это то, что механизм центра сертификации предназначен для предотвращения. Центр сертификации (ЦС) - это организация, которая хранит открытые ключи и их владельцев, и каждая сторона в сообщении доверяет этой организации (и знает свой открытый ключ). Когда веб-браузер пользователя получает открытый ключ от www.bank.example, он также получает цифровую подпись ключа (с дополнительной информацией в так называемом X.509).сертификат). Браузер уже обладает открытым ключом CA и, следовательно, может проверять подпись, доверять сертификату и открытому ключу в нем: поскольку www.bank.example использует открытый ключ, который сертифицирует центр сертификации, поддельный www.bank.example можно использовать только тот же открытый ключ. Поскольку подделка www.bank.example не знает соответствующего закрытого ключа, она не может создать подпись, необходимую для проверки ее подлинности. Хранение ключей Злоумышленник, похитивший закрытые ключи центра сертификации, может подделать сертификаты, как если бы они были ЦС, без необходимости постоянного доступа к системам ЦС. Таким образом, кража ключей является одним из основных рисков, от которого сертифицирующие органы защищаются. Публично доверенные центры сертификации почти всегда хранят свои ключи в модуле аппаратной безопасности (HSM), который позволяет им подписывать сертификаты с помощью ключа, но в целом предотвращает извлечение этого ключа с помощью как физического, так и программного управления. Центры сертификации обычно принимают дополнительные меры предосторожности, чтобы сохранить ключ для своих долгосрочных корневых сертификатов в HSM, который находится в автономном режиме.За исключением случаев, когда необходимо подписать краткосрочные промежуточные сертификаты. Промежуточные сертификаты, хранящиеся в онлайн-HSM, могут выполнять ежедневную работу по подписанию сертификатов конечных объектов и обновлению информации об отзыве. Центры сертификации иногда используют церемонию ключей при создании ключей подписи, чтобы гарантировать, что ключи не подделаны и не скопированы. | |
|
| |
| Всього коментарів: 0 | |