В криптографии центр сертификации или центр сертификации ( CA ) — это объект, который хранит, подписывает и выдает цифровые сертификаты . Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата. Это позволяет другим (проверяющим сторонам) полагаться на подписи или утверждения о закрытом ключе, который соответствует сертифицированному открытому ключу. Центр сертификации действует как доверенная третья сторона, которой доверяет как субъект (владелец) сертификата, так и сторона, полагающаяся на сертификат. [1] Формат этих сертификатов определяется стандартом X.509 или EMV .
Одним из наиболее распространенных применений центров сертификации является подписание сертификатов, используемых в HTTPS , протоколе безопасного просмотра во Всемирной паутине. Другое распространенное использование — выдача удостоверений личности национальными правительствами для использования в электронной подписи документов. [2]
Доверенные сертификаты можно использовать для создания безопасных подключений к серверу через Интернет. Сертификат необходим для того, чтобы обойти злонамеренную сторону, которая находится на пути к целевому серверу, который действует так, как если бы он был целью. Такой сценарий обычно называют атакой «человек посередине» . Клиент использует сертификат ЦС для аутентификации подписи ЦС на сертификате сервера в рамках авторизации перед запуском безопасного соединения. [3] Обычно клиентское программное обеспечение, например браузеры, включает в себя набор доверенных сертификатов ЦС. Это имеет смысл, поскольку многим пользователям необходимо доверять своему клиентскому программному обеспечению. Вредоносный или скомпрометированный клиент может пропустить любую проверку безопасности и при этом обмануть своих пользователей, заставив их поверить в обратное.
Клиентами ЦС являются диспетчеры серверов, которые запрашивают сертификат, который их серверы будут выдавать пользователям. Коммерческие центры сертификации взимают плату за выдачу сертификатов, и их клиенты ожидают, что сертификат центра сертификации будет содержаться в большинстве веб-браузеров, поэтому безопасные соединения с сертифицированными серверами работают эффективно сразу после установки. Количество интернет-браузеров, других устройств и приложений, доверяющих определенному центру сертификации, называется повсеместностью. Mozilla , являющаяся некоммерческой организацией, выдает несколько коммерческих сертификатов CA для своих продуктов. [4] В то время как Mozilla разработала свою собственную политику, CA/Browser Forum разработал аналогичные рекомендации для доверия CA. Один сертификат ЦС может использоваться несколькими ЦС или их реселлерами . Сертификат корневого ЦС может служить основой для выдачи нескольких промежуточных сертификатов ЦС с различными требованиями проверки.
Помимо коммерческих центров сертификации, некоторые некоммерческие организации бесплатно выдают общедоступные цифровые сертификаты, например Let's Encrypt . Некоторые крупные компании, занимающиеся облачными вычислениями и веб-хостингом, также являются общедоступными центрами сертификации и выдают сертификаты службам, размещенным в их инфраструктуре, например IBM Cloud , Amazon Web Services , Cloudflare и Google Cloud Platform .
Крупные организации или государственные органы могут иметь свои собственные PKI ( инфраструктуру открытых ключей ), каждая из которых содержит свои собственные центры сертификации. Любой сайт, использующий самозаверяющие сертификаты, действует как собственный центр сертификации.
Коммерческие банки, выпускающие платежные карты EMV , регулируются Центром сертификации EMV, [5] платежными схемами, которые направляют платежные транзакции, инициированные в торговых терминалах ( POS ), в банк-эмитент карт для перевода средств с банковского счета держателя карты на банковский счет получателя платежа. Каждая платежная карта вместе с данными своей карты предоставляет в POS сертификат эмитента карты. Сертификат эмитента подписан сертификатом EMV CA. POS извлекает открытый ключ ЦС EMV из своего хранилища, проверяет сертификат эмитента и подлинность платежной карты перед отправкой запроса платежа в схему оплаты.
Браузеры и другие клиенты обычно позволяют пользователям добавлять или удалять сертификаты CA по своему желанию. Хотя сертификаты сервера обычно действуют в течение относительно короткого периода времени, сертификаты CA продлеваются [6] , поэтому для неоднократно посещаемых серверов менее подвержено ошибкам импорт и доверие к выданному CA, а не подтверждение исключения безопасности каждый раз, когда сервер сертификат продлевается.
Реже надежные сертификаты используются для шифрования или подписи сообщений. Центры сертификации также выдают сертификаты конечных пользователей, которые можно использовать с S/MIME . Однако для шифрования требуется открытый ключ получателя , и, поскольку авторы и получатели зашифрованных сообщений, очевидно, знают друг друга, полезность доверенной третьей стороны остается ограниченной проверкой подписи сообщений, отправленных в публичные списки рассылки.
Во всем мире бизнес центров сертификации фрагментирован: на внутреннем рынке доминируют национальные или региональные поставщики. Это связано с тем, что многие виды использования цифровых сертификатов, например, для юридически обязательных цифровых подписей, связаны с местным законодательством, правилами и схемами аккредитации центров сертификации.
Однако рынок серверных сертификатов TLS/SSL, которым доверяют во всем мире , в основном принадлежит небольшому числу транснациональных компаний. Этот рынок имеет значительные барьеры для входа из-за технических требований. [7] Хотя это и не требуется по закону, новые провайдеры могут пройти ежегодные проверки безопасности (например, WebTrust [8] для центров сертификации в Северной Америке и ETSI в Европе [9] ), чтобы быть включенными в качестве доверенного корня веб-браузером или Операционная система.
По состоянию на 24 августа 2020 года [обновлять]147 корневых сертификатов, представляющих 52 организации, являются доверенными в веб-браузере Mozilla Firefox , [10] 168 корневых сертификатов, представляющих 60 организаций, являются доверенными для macOS , [11] и 255 корневых сертификатов, представляющих 101 организацию. , доверяются Microsoft Windows . [12] Начиная с Android 4.2 (Jelly Bean), Android в настоящее время содержит более 100 центров сертификации, которые обновляются с каждой версией. [13]
18 ноября 2014 года группа компаний и некоммерческих организаций, в том числе Electronic Frontier Foundation, Mozilla, Cisco и Akamai, объявила о создании Let's Encrypt , некоммерческого центра сертификации, который предоставляет бесплатные сертификаты X.509 с проверкой домена , а также программное обеспечение для обеспечения установка и обслуживание сертификатов. [14] Let's Encrypt управляется недавно созданной Internet Security Research Group , калифорнийской некоммерческой организацией, признанной освобожденной от федеральных налогов. [15]
По данным Netcraft в мае 2015 года, отраслевого стандарта для мониторинга активных сертификатов TLS: «Хотя глобальная экосистема [TLS] является конкурентоспособной, в ней доминирует несколько крупных центров сертификации — на три центра сертификации (Symantec, Comodo, GoDaddy) приходится три С момента начала [нашего] исследования первое место удерживает Symantec (или VeriSign до того, как его купила Symantec), а в настоящее время на него приходится чуть менее Чтобы проиллюстрировать эффект различных методологий, среди миллиона самых загруженных сайтов Symantec выдала 44% действительных и надежных используемых сертификатов — значительно больше, чем ее общая доля на рынке». [16]
По данным независимой исследовательской компании Netcraft , в 2020 году «DigiCert станет крупнейшим в мире центром сертификации с высокой степенью надежности, занимающим 60% рынка сертификатов расширенной проверки и 96% сертификатов, проверенных организациями во всем мире. [17]
По состоянию на апрель 2023 года [обновлять]исследовательская компания W3Techs, которая собирает статистику использования центров сертификации среди 10 миллионов крупнейших веб-сайтов Alexa и 1 миллиона лучших веб-сайтов Tranco, перечисляет шесть крупнейших центров сертификации по абсолютной доле использования, как показано ниже. [18]
Коммерческие центры сертификации, которые выдают большую часть сертификатов для серверов HTTPS, обычно используют метод, называемый « проверкой домена », для аутентификации получателя сертификата. Методы, используемые для проверки домена, различаются в разных центрах сертификации, но в целом методы проверки домена предназначены для доказательства того, что соискатель сертификата контролирует данное доменное имя , а не какую-либо информацию о личности заявителя.
Многие центры сертификации также предлагают сертификаты расширенной проверки (EV) в качестве более строгой альтернативы сертификатам с проверкой домена. Расширенная проверка предназначена для проверки не только контроля над доменным именем, но и дополнительной идентификационной информации, которая будет включена в сертификат. Некоторые браузеры отображают эту дополнительную идентификационную информацию в зеленом поле в строке URL-адреса. Одним из ограничений EV как решения недостатков проверки домена является то, что злоумышленники все равно могут получить проверенный сертификат для домена-жертвы и развернуть его во время атаки; если бы это произошло, пользователь-жертва мог бы заметить разницу в отсутствии зеленой полосы с названием компании. Существует некоторый вопрос относительно того, смогут ли пользователи признать это отсутствие признаком продолжающейся атаки: тест с использованием Internet Explorer 7 в 2009 году показал, что отсутствие предупреждений EV в IE7 не было замечено пользователями, однако текущий браузер Microsoft , Edge , показывает значительно большую разницу между сертификатами EV и сертификатами, проверенными доменом: сертификаты, проверенные доменом, имеют полый серый замок.
Проверка домена страдает от определенных структурных ограничений безопасности. В частности, он всегда уязвим для атак, которые позволяют злоумышленнику наблюдать за проверками домена, которые отправляют центры сертификации. К ним могут относиться атаки на протоколы DNS, TCP или BGP (в которых отсутствует криптографическая защита TLS/SSL) или компрометация маршрутизаторов. Такие атаки возможны либо в сети рядом с ЦС, либо рядом с самим доменом-жертвой.
Один из наиболее распространенных методов проверки домена включает отправку электронного письма, содержащего токен аутентификации или ссылку на адрес электронной почты, который, вероятно, несет административную ответственность за домен. Это может быть адрес электронной почты технического контактного лица, указанный в записи WHOIS домена , или административный адрес электронной почты, например admin@ , администратор@ , веб-мастер@ , хостмастер@ или postmaster@ домена. [19] [20] Некоторые центры сертификации могут принимать подтверждение с использованием root@ , [ нужна ссылка ] info@ или support@ в домене. [21] Теория проверки домена заключается в том, что только законный владелец домена сможет читать электронные письма, отправленные на эти административные адреса.
Реализации проверки домена иногда были источником уязвимостей безопасности. В одном случае исследователи безопасности показали, что злоумышленники могли получить сертификаты для сайтов веб-почты, потому что центр сертификации был готов использовать адрес электронной почты, например [email protected], для домена.com, но не все системы веб-почты зарезервировали имя пользователя «ssladmin», чтобы предотвратить злоумышленникам от его регистрации. [22]
До 2011 года не существовало стандартного списка адресов электронной почты, который можно было использовать для проверки домена, поэтому администраторам электронной почты было неясно, какие адреса необходимо зарезервировать. В первой версии базовых требований CA/Browser Forum , принятой в ноябре 2011 года, был указан список таких адресов. Это позволило почтовым хостам зарезервировать эти адреса для административного использования, хотя такие меры предосторожности по-прежнему не являются универсальными. В январе 2015 года финн зарегистрировал имя пользователя «hostmaster» в финской версии Microsoft Live и смог получить подтвержденный доменом сертификат для live.fi, несмотря на то, что не был владельцем доменного имени. [23]
Центр сертификации выдает цифровые сертификаты , содержащие открытый ключ и личность владельца. Соответствующий закрытый ключ не доступен публично, но хранится в секрете конечным пользователем, сгенерировавшим пару ключей. Сертификат также является подтверждением или подтверждением со стороны ЦС того, что открытый ключ, содержащийся в сертификате, принадлежит лицу, организации, серверу или другому объекту, указанному в сертификате. Обязанностью ЦС в таких схемах является проверка учетных данных заявителя, чтобы пользователи и проверяющие стороны могли доверять информации в выданном сертификате. Для этого центры сертификации используют различные стандарты и тесты. По сути, центр сертификации отвечает за то, чтобы сказать: «Да, этот человек тот, кем он себя называет, и мы, центр сертификации, подтверждаем это». [24]
Если пользователь доверяет ЦС и может проверить подпись ЦС, он также может предположить, что определенный открытый ключ действительно принадлежит тому, кто указан в сертификате. [25]
Криптография с открытым ключом может использоваться для шифрования данных, передаваемых между двумя сторонами. Обычно это может произойти, когда пользователь входит на любой сайт, реализующий протокол HTTP Secure . В этом примере предположим, что пользователь входит на домашнюю страницу своего банка www.bank.example, чтобы воспользоваться онлайн-банкингом. Когда пользователь открывает домашнюю страницу www.bank.example, он получает открытый ключ вместе со всеми данными, которые отображает его веб-браузер. Открытый ключ можно использовать для шифрования данных, передаваемых клиентом на сервер, но безопаснее всего использовать его в протоколе, который определяет временный общий симметричный ключ шифрования; Сообщения в таком протоколе обмена ключами могут быть зашифрованы открытым ключом банка таким образом, что только банковский сервер имеет закрытый ключ для их чтения. [26]
Остальная часть связи затем продолжается с использованием нового (одноразового) симметричного ключа, поэтому, когда пользователь вводит некоторую информацию на страницу банка и отправляет страницу (отправляет информацию обратно в банк), тогда данные, которые пользователь ввел на страницу будут зашифрованы их веб-браузером. Таким образом, даже если кто-то сможет получить доступ к (зашифрованным) данным, которые были переданы пользователем на сайт www.bank.example, такой перехватчик не сможет их прочитать или расшифровать.
Этот механизм безопасен только в том случае, если пользователь может быть уверен, что в своем веб-браузере он видит именно тот банк. Если пользователь вводит www.bank.example, но его связь перехватывается и поддельный веб-сайт (который выдает себя за веб-сайт банка) отправляет информацию о странице обратно в браузер пользователя, поддельная веб-страница может отправить поддельный открытый ключ. пользователю (для которого поддельный сайт имеет соответствующий закрытый ключ). Пользователь заполнит форму со своими личными данными и отправит страницу. После этого поддельная веб-страница получит доступ к данным пользователя.
Именно это и призван предотвратить механизм центра сертификации. Центр сертификации (CA) — это организация, которая хранит открытые ключи и их владельцев, и каждая сторона связи доверяет этой организации (и знает ее открытый ключ). Когда веб-браузер пользователя получает открытый ключ от www.bank.example, он также получает цифровую подпись ключа (с некоторой дополнительной информацией в так называемом сертификате X.509 ). Браузер уже обладает открытым ключом ЦС и, следовательно, может проверить подпись, доверять сертификату и открытому ключу в нем: поскольку www.bank.example использует открытый ключ, заверенный центром сертификации, поддельный www.bank.example может использовать только один и тот же открытый ключ. Поскольку поддельный www.bank.example не знает соответствующего закрытого ключа, он не может создать подпись, необходимую для проверки его подлинности. [27]
Трудно гарантировать правильность соответствия между данными и объектом, когда данные передаются в центр сертификации (возможно, через электронную сеть), а также когда также предоставляются учетные данные лица/компании/программы, запрашивающей сертификат. Вот почему коммерческие центры сертификации часто используют комбинацию методов аутентификации, включая использование правительственных бюро, платежной инфраструктуры, баз данных и услуг третьих сторон, а также пользовательскую эвристику. В некоторых корпоративных системах для получения сертификата могут использоваться локальные формы аутентификации, такие как Kerberos , которые, в свою очередь, могут использоваться внешними проверяющими сторонами. Нотариусы обязаны в некоторых случаях лично знать сторону, подпись которой нотариально заверяется; это более высокий стандарт, чем тот, которого достигают многие центры сертификации. Согласно плану Американской ассоциации юристов по управлению онлайн-транзакциями, основные положения федеральных законов и законов штатов США, принятых в отношении цифровых подписей, заключаются в том, чтобы «предотвратить противоречивые и чрезмерно обременительные местные правила и установить, что электронные письменные документы удовлетворяют традиционным требованиям, связанным с бумажными документами». " Кроме того, статут США об электронной подписи и предлагаемый кодекс UETA [28] помогают гарантировать, что:
Несмотря на меры безопасности, принятые для правильной проверки личности людей и компаний, существует риск того, что один центр сертификации выдаст поддельный сертификат самозванцу. Также возможна регистрация физических лиц и компаний с одинаковыми или очень похожими названиями, что может привести к путанице. Чтобы свести к минимуму эту опасность, инициатива по прозрачности сертификатов предлагает проверять все сертификаты в общедоступном журнале, который невозможно подделать, что может помочь в предотвращении фишинга . [29] [30]
В крупномасштабных развертываниях Алиса может быть не знакома с центром сертификации Боба (возможно, у каждого из них есть разные серверы ЦС), поэтому сертификат Боба может также включать открытый ключ его ЦС, подписанный другим ЦС 2 , который, предположительно, узнаваем Алисой. Этот процесс обычно приводит к созданию иерархии или сетки центров сертификации и сертификатов центров сертификации.
Сертификат может быть отозван до истечения срока его действия, что означает, что он больше не действителен. Без отзыва злоумышленник сможет использовать такой скомпрометированный или неправильно выданный сертификат до истечения срока его действия. [31] Следовательно, отзыв является важной частью инфраструктуры открытых ключей . [32] Отзыв выполняется выдающим центром сертификации, который формирует криптографически заверенное заявление об отзыве. [33]
При распространении информации об отзыве среди клиентов своевременность обнаружения отзыва (и, следовательно, возможность злоумышленнику использовать скомпрометированный сертификат) снижает использование ресурсов при запросе статусов отзыва и проблемы конфиденциальности. [34] Если информация об отзыве недоступна (из-за аварии или атаки), клиенты должны решить, следует ли использовать отказоустойчивый сертификат и рассматривать сертификат как отозванный (и, таким образом, ухудшать доступность ) или отказоустойчивый и рассматривать его как неотозванным (и позволяет злоумышленникам обойти отзыв). [35]
Из-за стоимости проверок отзыва и влияния на доступность потенциально ненадежных удаленных служб веб-браузеры ограничивают выполняемые ими проверки отзыва и работают без сбоев там, где они это делают. [36] Списки отзыва сертификатов слишком затратны для повседневного использования, а протокол статуса онлайн-сертификатов создает проблемы с задержкой соединения и конфиденциальностью. Были предложены и другие схемы, позволяющие обеспечить отказоустойчивую проверку, но они еще не были успешно реализованы. [32]
Форум CA/Browser публикует «Базовые требования» — [42] список политик и технических требований, которым должны следовать центры сертификации. Это требование для включения в хранилища сертификатов Firefox [43] и Safari. [44]
Если центр сертификации можно взломать, то безопасность всей системы будет потеряна, что может привести к подрыву всех объектов, которые доверяют скомпрометированному центру сертификации.
Например, предположим, что злоумышленнику Еве удается заставить центр сертификации выдать ей сертификат, который утверждает, что представляет Алису. То есть в сертификате будет публично указано, что он представляет Алису, и может содержаться другая информация об Алисе. Некоторая информация об Алисе, например имя ее работодателя, может быть правдивой, что повышает доверие к сертификату. Однако у Евы будет важнейший закрытый ключ, связанный с сертификатом. Затем Ева могла использовать сертификат для отправки электронного письма с цифровой подписью Бобу, обманывая Боба, заставляя его поверить, что письмо было от Алисы. Боб может даже ответить зашифрованным электронным письмом, полагая, что его сможет прочитать только Алиса, тогда как Ева действительно сможет расшифровать его с помощью закрытого ключа.
Примечательный случай подрывной деятельности ЦС, подобный этому, произошел в 2001 году, когда центр сертификации VeriSign выдал два сертификата лицу, утверждавшему, что представляет Microsoft. Сертификаты имеют название «Корпорация Microsoft», поэтому их можно использовать, чтобы обмануть кого-либо, заставив поверить в то, что обновления программного обеспечения Microsoft исходят от Microsoft, хотя на самом деле это не так. Мошенничество было обнаружено в начале 2001 года. Microsoft и VeriSign предприняли шаги, чтобы ограничить последствия проблемы. [45] [46]
В 2008 году реселлер Comodo Certstar продал сертификат mozilla.com Эдди Ниггу, который не имел полномочий представлять Mozilla. [47]
В 2011 году поддельные сертификаты были получены от Comodo и DigiNotar , [48] [49] предположительно иранскими хакерами. Есть доказательства того, что поддельные сертификаты DigiNotar были использованы при атаке «человек посередине» в Иране. [50]
В 2012 году стало известно, что Trustwave выпустила подчиненный корневой сертификат, который использовался для прозрачного управления трафиком (человек посередине), что фактически позволяло предприятию перехватывать внутренний сетевой трафик SSL с использованием подчиненного сертификата. [51]
В 2012 году вредоносная программа Flame (также известная как SkyWiper) содержала модули, у которых была коллизия MD5 с действительным сертификатом, выданным лицензионным сертификатом Microsoft Terminal Server, который использовал сломанный алгоритм хеширования MD5. Таким образом, авторы смогли провести коллизионную атаку с хешем, указанным в сертификате. [52] [53]
В 2015 году китайский центр сертификации MCS Holdings, связанный с центральным реестром доменов Китая, выдал несанкционированные сертификаты для доменов Google. [54] [55] Таким образом, Google удалила MCS и корневой центр сертификации из Chrome и отозвала сертификаты. [56]
Злоумышленник, похитивший секретные ключи центра сертификации, может подделать сертификаты, как если бы они были сертификатами центра сертификации, без необходимости постоянного доступа к системам центра сертификации. Таким образом, кража ключей является одним из основных рисков, от которых защищаются органы сертификации. Центры сертификации, пользующиеся общественным доверием, почти всегда хранят свои ключи в аппаратном модуле безопасности (HSM), который позволяет им подписывать сертификаты с помощью ключа, но обычно предотвращает извлечение этого ключа с помощью как физических, так и программных средств контроля. Центры сертификации обычно принимают дополнительные меры предосторожности, сохраняя ключи своих долгосрочных корневых сертификатов в HSM, который хранится в автономном режиме , за исключением случаев, когда это необходимо для подписи промежуточных сертификатов с более коротким сроком действия. Промежуточные сертификаты, хранящиеся в онлайновом HSM, могут выполнять повседневную работу по подписанию сертификатов конечного объекта и поддержанию актуальности информации об отзыве.
Центры сертификации иногда используют церемонию ключа при создании ключей подписи, чтобы гарантировать, что ключи не будут подделаны или скопированы.
Критическая слабость способа реализации текущей схемы X.509 заключается в том, что любой центр сертификации, которому доверяет конкретная сторона, может затем выдавать сертификаты для любого домена по своему выбору. Такие сертификаты будут признаны доверяющей стороной действительными независимо от того, являются ли они законными и авторизованными или нет. [57] Это серьезный недостаток, учитывая, что наиболее часто встречающейся технологией, использующей X.509 и доверенные третьи стороны, является протокол HTTPS. Поскольку все основные веб-браузеры распространяются среди своих конечных пользователей с предварительно настроенным списком доверенных центров сертификации, число которых исчисляется десятками, это означает, что любой из этих предварительно утвержденных доверенных центров сертификации может выдать действительный сертификат для любого домена. [58] Реакция отрасли на это была приглушенной. [59] Учитывая, что содержимое предварительно настроенного списка доверенных центров сертификации браузера определяется независимо стороной, которая распространяет или вызывает установку приложения браузера, сами центры сертификации фактически ничего не могут сделать.
Эта проблема стала движущей силой разработки протокола аутентификации именованных объектов на основе DNS (DANE). Принятие DANE в сочетании с расширениями безопасности системы доменных имен (DNSSEC) значительно уменьшит, если не устранит, роль доверенных третьих сторон в PKI домена.
{{cite web}}
: CS1 maint: архивная копия в заголовке ( ссылка ){{cite journal}}
: Требуется цитировать журнал |journal=
( помощь )