Войти
В криптографии, центр сертификации или центр сертификации (CA) - это организация, которая выдает цифровые сертификаты. Цифровой сертификат удостоверяет право собственности на открытый ключ названного субъекта сертификата. Это позволяет другим (полагающимся сторонам) полагаться на подписи или утверждения о закрытом ключе, который соответствует сертифицированному открытому ключу. ЦС действует как доверенная третья сторона - доверенная как субъектом (владельцем) сертификата, так и стороной, полагающейся на сертификат. Формат этих сертификатов определяется стандартом X.509 или EMV.
Одним из наиболее частых случаев использования центров сертификации является подписание сертификатов, используемых в HTTPS, протоколе безопасного просмотра во всемирной паутине. Другое распространенное использование - выдача удостоверений личности национальными правительствами для использования в документах с электронной подписью.
Доверенные сертификаты могут использоваться для создания безопасных соединений с сервером через Интернет. Сертификат необходим для обхода злоумышленника, который оказывается на пути к целевому серверу, который действует так, как если бы он был целью. Такой сценарий обычно называют атакой «злоумышленник посередине». Клиент использует сертификат CA для проверки подлинности подписи CA на сертификате сервера как часть авторизации перед запуском безопасного соединения. Обычно клиентское программное обеспечение, например браузеры, включает набор доверенных сертификатов ЦС. Это имеет смысл, поскольку многие пользователи должны доверять своему клиентскому программному обеспечению. Злонамеренный или скомпрометированный клиент может пропустить любую проверку безопасности и по-прежнему заставить своих пользователей поверить в обратное.
Клиентами CA являются супервизоры серверов, которые запрашивают сертификат, который их серверы будут предоставлять пользователям. Коммерческие центры сертификации берут деньги за выдачу сертификатов, и их клиенты ожидают, что сертификат центра сертификации будет содержаться в большинстве веб-браузеров, так что безопасные соединения с сертифицированными серверами будут эффективно работать сразу после установки. Количество интернет-браузеров, других устройств и приложений, доверяющих определенному центру сертификации, называется повсеместным распространением. Mozilla, которая является некоммерческой организацией, выдает несколько коммерческих сертификатов ЦС вместе со своими продуктами. В то время как Mozilla разработала свою собственную политику, CA / Форум браузеров разработали аналогичные рекомендации по доверию CA. Один сертификат CA может использоваться несколькими центрами сертификации или их торговыми посредниками. Сертификат корневого ЦС может быть основой для выдачи нескольких сертификатов промежуточного ЦС с различными требованиями к проверке.
Помимо коммерческих центров сертификации, некоторые некоммерческие организации бесплатно выдают цифровые сертификаты; яркими примерами являются CAcert и Let's Encrypt.
. Крупные организации или государственные органы могут иметь свои собственные PKI (инфраструктура открытых ключей ), каждая из которых содержит свои собственные центры сертификации. Любой сайт, использующий самоподписанные сертификаты, действует как собственный центр сертификации.
Коммерческие банки, которые выпускают платежные карты EMV, регулируются Центром сертификации EMV, схемами платежей, которые направляют платежные транзакции, инициированные в терминалах точек продаж (POS ), на Банк-эмитент карты для перевода средств с банковского счета держателя карты на банковский счет получателя платежа. Каждая платежная карта вместе с данными карты представляет в POS Сертификат эмитента карты. Сертификат эмитента подписан сертификатом ЦС EMV. POS извлекает открытый ключ EMV CA из своего хранилища, проверяет сертификат эмитента и подлинность платежной карты перед отправкой платежного запроса в схему оплаты.
Браузеры и другие виды клиентов, как правило, позволяют пользователям добавлять или удалять сертификаты CA по своему желанию. В то время как сертификаты сервера обычно действуют в течение относительно короткого периода, сертификаты ЦС дополнительно расширяются, поэтому для повторно посещаемых серверов меньше подвержены ошибкам импорт и доверие к выпущенному ЦС, а не подтверждение исключения безопасности каждый раз, когда сертификат сервера обновляется..
Реже для шифрования или подписи сообщений используются надежные сертификаты. Центры сертификации также выдают сертификаты конечных пользователей, которые можно использовать с S / MIME. Однако шифрование влечет за собой открытый ключ получателя, и, поскольку авторы и получатели зашифрованных сообщений, очевидно, знают друг друга, полезность доверенной третьей стороны остается ограниченной проверкой подписи сообщений, отправленных в общедоступные списки рассылки..
Во всем мире деятельность центров сертификации фрагментирована, на их внутреннем рынке доминируют национальные или региональные провайдеры. Это связано с тем, что многие виды использования цифровых сертификатов, такие как юридически обязательные цифровые подписи, связаны с местным законодательством, правилами и схемами аккредитации для центров сертификации.
Однако рынок глобально доверенных сертификатов серверов TLS / SSL в основном принадлежит небольшому количеству транснациональных компаний. Этот рынок имеет значительные барьеры для входа из-за технических требований. Хотя это не требуется по закону, новые поставщики могут выбрать ежегодный аудит безопасности (например, WebTrust для центров сертификации в Северной Америке и ETSI в Европе) для включения в качестве доверенного корня веб-браузер или операционная система.
По состоянию на 24 августа 2020 года 147 корневых сертификатов, представляющих 52 организации, являются доверенными в веб-браузере Mozilla Firefox, 168 корневых сертификатов, представляющих 60 организаций, доверяют macOS и 255 корневых сертификатов, представляющих 101 организацию, доверяют Microsoft Windows. Начиная с Android 4.2 (Jelly Bean), Android в настоящее время содержит более 100 центров сертификации, которые обновляются с каждым выпуском.
18 ноября 2014 г. группа компаний и некоммерческих организаций, включая Electronic Frontier Foundation, Mozilla, Cisco и Akamai, анонсировали Let's Encrypt, некоммерческий центр сертификации, который предоставляет бесплатные проверенные домены Сертификаты X.509, а также программное обеспечение для установки и обслуживания сертификатов. Let's Encrypt управляется недавно созданной Internet Security Research Group, калифорнийской некоммерческой организацией, признанной освобожденной от налогов в соответствии с Разделом 501 (c) (3).
Согласно NetCraft в мае 2015 года, отраслевой стандарт для мониторинга активных сертификатов TLS гласит: «Хотя глобальная экосистема [TLS] является конкурентоспособной, в ней доминирует несколько основных центров сертификации - три центра сертификации (Symantec, Comodo, GoDaddy) составляют три четверти всех выпущенных [ TLS] на общедоступных веб-серверах. Первое место занимала Symantec (или VeriSign до того, как она была приобретена Symantec) с самого начала [нашего] исследования, и в настоящее время на нее приходится чуть менее трети всех сертификатов. иллюстрируют влияние различных методологий, среди миллиона наиболее загруженных сайтов Symantec выпустила 44% действующих доверенных сертификатов, что значительно превышает ее общую долю рынка ».
Обновленное исследование W3Techs показывает, что IdenTrust, лицо, подписавшее Let's Encrypt остался самым популярным центром сертификации SSL, в то время как Symantec выпал из списка из-за того, что его услуги безопасности были приобретены DigiCert. Sectigo (ранее Comodo CA) является третьим по величине центром сертификации SSL с 17,7% рынка: Digicert поддерживает GeoTrust, Digicert, Thawte и RapidSSL.
| Ранг | Эмитент | Использование | Доля рынка |
|---|---|---|---|
| 1 | IdenTrust | 38.0% | 51,2% |
| 2 | DigiCert | 14,6% | 19,7% |
| 3 | Sectigo | 13.1% | 17,7% |
| 4 | GoDaddy | 5.1% | 6,9% |
| 5 | GlobalSign | 2,2% | 3,0% |
| 6 | Certum | 0,4% | 0,7% |
| 7 | Actalis | 0,2% | 0,3 % |
| 8 | Entrust | 0.2% | 0,3% |
| 9 | Secom | 0.1% | 0,3% |
| 10 | Let's Encrypt | 0,1% | 0,2% |
| 11 | Trustwave | 0,1% | 0,1% |
| 12 | WISeKey Group | < 0.1% | 0,1% |
| 13 | StartCom | < 0.1% | 0,1% |
| 14 | Сетевые решения | < 0.1% | 0,1% |
.
Коммерческие центры сертификации, которые выдают большую часть сертификатов для серверов HTTPS, обычно используют метод, называемый «проверка домена » для аутентификации получателя сертификата. Методы, используемые для проверки домена, различаются в зависимости от ЦС, но в целом методы проверки домена предназначены для доказательства того, что заявитель сертификата контролирует данное доменное имя, а не какую-либо информацию об идентичности заявителя.
Многие центры сертификации также предлагают сертификаты Extended Validation (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 @ в домене. Теория, лежащая в основе проверки домена, заключается в том, что только законный владелец домена сможет читать электронные письма, отправленные на эти административные адреса.
Реализации проверки домена иногда были источником уязвимостей безопасности. В одном случае исследователи безопасности показали, что злоумышленники могут получить сертификаты для сайтов веб-почты, потому что центр сертификации был готов использовать адрес электронной почты, например [email#160;protected] для domain.com, но не все системы веб-почты зарезервировали "ssladmin" имя пользователя, чтобы предотвратить его регистрацию злоумышленниками.
До 2011 года не существовало стандартного списка адресов электронной почты, которые можно было бы использовать для проверки домена, поэтому администраторам электронной почты было непонятно, какие адреса необходимо зарезервировать. В первой версии CA / Browser Forum Baseline Requirements, принятой в ноябре 2011 г., был указан список таких адресов. Это позволило почтовым хостам зарезервировать эти адреса для административного использования, хотя такие меры предосторожности все еще не универсальны. В январе 2015 года финн зарегистрировал имя пользователя hostmaster в финской версии Microsoft Live и смог получить подтвержденный доменом сертификат для live.fi, несмотря на то, что не являлся владельцем доменного имени..
ЦС выдает цифровые сертификаты, которые содержат открытый ключ и личность владельца. Соответствующий закрытый ключ не является общедоступным, но хранится в секрете конечным пользователем, создавшим пару ключей. Сертификат также является подтверждением или подтверждением CA того, что открытый ключ, содержащийся в сертификате, принадлежит лицу, организации, серверу или другому объекту, указанному в сертификате. Обязанность ЦС в таких схемах заключается в проверке учетных данных заявителя, чтобы пользователи и доверяющие стороны могли доверять информации в сертификатах ЦС. Для этого центры сертификации используют различные стандарты и тесты. По сути, центр сертификации отвечает за то, чтобы сказать: «Да, этот человек является тем, кем они являются, и мы, ЦС, подтверждаем это».
Если пользователь доверяет ЦС и может проверить подпись ЦС, то они также могут предположить, что определенный открытый ключ действительно принадлежит тому, кто указан в сертификате.
Криптография с открытым ключом может использоваться для шифрования данных, передаваемых между двумя сторонами. Обычно это может произойти, когда пользователь входит на любой сайт, который реализует протокол 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 не знает соответствующего закрытого ключа, он не может создать подпись, необходимую для проверки его подлинности.
Трудно гарантировать правильность соответствия между данными и субъект, когда данные представляются в СА (возможно, по электронной сети), и когда аналогично представлены учетные данные человека / компании / программы, запрашивающей сертификат. Вот почему коммерческие центры сертификации часто используют комбинацию методов аутентификации, включая использование государственных бюро, платежной инфраструктуры, баз данных и сервисов третьих сторон, а также пользовательской эвристики. В некоторых корпоративных системах локальные формы аутентификации, такие как Kerberos, могут использоваться для получения сертификата, который, в свою очередь, может использоваться внешними проверяющими сторонами. Нотариусы в некоторых случаях обязаны лично знать сторону, подпись которой нотариально удостоверяется; это более высокий стандарт, чем достигается многими центрами сертификации. Согласно плану Американской ассоциации юристов по управлению онлайн-транзакциями, основные положения федеральных законов и законов штатов США, принятые в отношении цифровых подписей, заключаются в том, чтобы «предотвратить противоречивые и чрезмерно обременительные местные правила и установить что электронные письма удовлетворяют традиционным требованиям, связанным с бумажными документами ». Кроме того, закон США об электронной подписи и предлагаемый код UETA помогают гарантировать, что:
Несмотря на меры безопасности, предпринятые для правильной проверки личности людей и компаний существует риск того, что один ЦС выдаст поддельный сертификат самозванцу. Также можно регистрировать физических лиц и компании с одинаковыми или очень похожими именами, что может привести к путанице. Чтобы свести к минимуму эту опасность, инициатива прозрачности сертификатов предлагает аудит всех сертификатов в общедоступном неподдельном журнале, что может помочь в предотвращении фишинга.
В крупномасштабных развертываниях Алиса может быть незнакома с центром сертификации Боба (возможно, каждый из них имеет свой сервер CA), поэтому сертификат Боба может также включать открытый ключ его CA, подписанный другим CA 2, который предположительно распознается Алисой. Этот процесс обычно приводит к иерархии или сети центров сертификации и сертификатов CA.
Список отзыва сертификатов (ARL) - это форма списка отзыва сертификатов (CRL), содержащего сертификаты, выданные центрам сертификации, в отличие от CRL, которые содержат отозванные сертификаты конечных объектов.
CA / Browser Forum публикует Базовые требования, список политик и технических требований, которым должны следовать центры сертификации. Это требование для включения в хранилища сертификатов Firefox и Safari.
Если CA может быть взломан, безопасность всей системы будет потеряна, что потенциально может нарушить объекты, доверяющие взломанному ЦС.
Например, предположим, что злоумышленнику, Еве, удается заставить ЦС выдать ей сертификат, который утверждает, что представляет Алису. То есть в сертификате будет публично заявлено, что он представляет Алису, и может быть включена другая информация об Алисе. Некоторая информация об Алисе, например имя ее работодателя, может быть правдой, что повышает надежность сертификата. Однако у Евы будет важнейший закрытый ключ, связанный с сертификатом. Затем Ева могла использовать сертификат для отправки Бобу электронной почты с цифровой подписью, обманывая Боба, заставляя его поверить в то, что письмо было от Алисы. Боб может даже ответить зашифрованным письмом, полагая, что его может прочитать только Алиса, когда Ева действительно сможет расшифровать его с помощью закрытого ключа.
Заметный случай подобной подрывной деятельности ЦС произошел в 2001 году, когда центр сертификации VeriSign выдал два сертификата лицу, заявившему, что он представляет Microsoft. Сертификаты носят название «Корпорация Microsoft», поэтому их можно использовать, чтобы заставить кого-то поверить в то, что обновления программного обеспечения Microsoft поступают от Microsoft, хотя на самом деле это не так. Мошенничество было обнаружено в начале 2001 года. Microsoft и VeriSign предприняли шаги для ограничения воздействия проблемы.
В 2011 году поддельные сертификаты были получены от Comodo и DigiNotar, предположительно иранскими хакерами. Есть свидетельства того, что поддельные сертификаты DigiNotar использовались в атаке типа «злоумышленник в середине» в Иране.
В 2012 году стало известно, что Trustwave выпустила подчиненный корневой сертификат, который был используется для прозрачного управления трафиком (человек посередине), что позволяет предприятию перехватывать внутренний сетевой трафик SSL с помощью подчиненного сертификата.
Злоумышленник, который украл сертификат закрытые ключи органа могут подделывать сертификаты, как если бы они были ЦС, без необходимости постоянного доступа к системам ЦС. Таким образом, кража ключей является одним из основных рисков, от которых защищаются центры сертификации. Публично доверенные центры сертификации почти всегда хранят свои ключи в аппаратном модуле безопасности (HSM), который позволяет им подписывать сертификаты ключом, но обычно предотвращает извлечение этого ключа с помощью физических и программных средств управления. Центры сертификации обычно принимают дополнительные меры предосторожности, сохраняя ключ для своих долгосрочных корневых сертификатов в HSM, который хранится в автономном режиме, за исключением случаев, когда необходимо подписывать более короткие промежуточные сертификаты. Промежуточные сертификаты, хранящиеся в онлайн-HSM, могут выполнять повседневную работу по подписанию сертификатов конечных объектов и обновлению информации об отзыве.
CA иногда используют церемонию ключа при генерации ключей подписи, чтобы гарантировать, что ключи не будут подделаны или скопированы.
Критическим недостатком способа реализации текущей схемы X.509 является то, что любой ЦС, которому доверяет конкретная сторона, может затем выдавать сертификаты для любого домен они выбирают. Такие сертификаты будут приниматься доверяющей стороной как действительные независимо от того, являются ли они законными и авторизованными или нет. Это серьезный недостаток, учитывая, что наиболее часто встречающейся технологией, использующей X.509 и доверенные третьи стороны, является протокол HTTPS. Поскольку все основные веб-браузеры распространяются среди своих конечных пользователей с предварительно настроенным списком доверенных центров сертификации, который исчисляется десятками, это означает, что любой из этих предварительно утвержденных доверенных центров сертификации может выдать действительный сертификат для любого домена. Реакция отрасли на это была приглушенной. Учитывая, что содержимое предварительно настроенного списка доверенных центров сертификации браузера определяется независимо стороной, которая распространяет или вызывает установку приложения браузера, сами центры сертификации фактически ничего не могут сделать.
Эта проблема является движущей силой разработки протокола аутентификации именованных объектов на основе DNS (DANE). Если он будет принят вместе с Расширениями безопасности системы доменных имен (DNSSEC), DANE значительно снизит, если не полностью устранит роль доверенных третьих сторон в PKI домена.
