Центры сертификации и цепочки доверия

Асимметричное шифрование полезно только в том случае, если Вы можете доверять тому, что открытый ключ действительно принадлежит нужному Вам лицу или организации. Без механизма доверия злоумышленник может перехватить Ваш запрос на получение чьего-либо открытого ключа и подставить собственный — это классическая атака «человек посередине». Инфраструктура открытых ключей (PKI) решает эту проблему, вводя центр сертификации (CA) — доверенную третью сторону, которая ставит цифровую подпись на certificate, связывая открытые ключи с подтверждёнными личностями. Если Вы доверяете CA, Вы можете доверять всем, чьи данные он подтвердил.

Центр сертификации (CA) — это организация, которая выдаёт цифровые certificate после проверки личности или организации, запросившей certificate. CA подписывает каждый certificate своим закрытым ключом, поэтому любой, кто доверяет CA, может проверить подлинность certificate с помощью открытого ключа CA. Существуют два типа: публичные CA (например, DigiCert, GlobalSign и Let's Encrypt), корневые certificate которых заранее установлены в операционных системах и браузерах; и частные (внутренние) CA, которые организации запускают самостоятельно для выдачи внутренних certificate (для VPN, внутренних служб и устройств).

Корневой CA — высший уровень иерархии PKI. certificate корневого CA являются самоподписанными — не существует более высокой инстанции, которая могла бы их подтвердить. Вместо этого корневым certificate доверяют потому, что поставщики операционных систем (Microsoft, Apple, Mozilla) тщательно проверяют корневые CA в рамках строгих аудитов и заранее устанавливают их certificate в хранилища доверенных certificate. В хранилище доверия обычного браузера находится примерно 130–150 доверенных корневых CA. Если корневой CA скомпрометирован, под сомнение попадает каждый выданный им certificate. Поэтому закрытые ключи корневых CA хранятся в автономных аппаратных модулях безопасности (HSM), изолированных от сетей.

Корневые CA редко выдают certificate конечным субъектам напрямую. Вместо этого они создают промежуточные CA (также называемые подчинёнными CA), выдавая certificate операторам промежуточных CA. Затем промежуточные CA выдают certificate конечным субъектам, например certificate серверов HTTPS. Такая иерархия делегирования выполняет несколько задач: защищает закрытые ключи корневого CA, сохраняя их в автономном режиме (если промежуточный CA скомпрометирован, отзывается только его цепочка certificate, а не весь корневой CA); позволяет создавать специализированные CA для разных задач (подпись кода и TLS); и поддерживает организационную иерархию в частной PKI.

Цепочка certificate (или цепочка доверия) — это последовательность certificate от certificate конечного субъекта до доверенного корневого CA. Для обычного веб-сайта HTTPS цепочка выглядит так: certificate конечного субъекта (например, *.google.com) → certificate промежуточного CA (например, Google Trust Services WR2) → certificate корневого CA (например, Google Trust Services LLC). Когда Ваш браузер открывает сайт, он проверяет всю эту цепочку: убеждается, что подпись каждого certificate создана уровнем выше, а корневой CA находится в хранилище доверия. Любое нарушение цепочки вызывает ошибку certificate.

Когда двум отдельным иерархиям PKI требуется установить взаимное доверие, они используют перекрёстную сертификацию. Каждый CA выдаёт certificate корневому CA другой иерархии, устанавливая доверие в обоих направлениях. Мостовой CA — это центральный узел, который выполняет перекрёстную сертификацию с несколькими доменными CA, создавая сеть доверия между разными организациями или государственными ведомствами. Федеральный мостовой CA US соединяет несколько государственных систем PKI. Перекрёстной сертификацией сложно управлять, но она необходима при объединении организаций или установлении доверия между ведомствами без перехода к единой иерархии.

Регистрационный центр (RA) — это организация, которая выполняет проверку личности от имени CA, но сама не выдаёт certificate. RA получает запросы на certificate, проверяет личность заявителя (с помощью проверки документов, подтверждения домена или личной проверки — в зависимости от типа certificate) и передаёт одобренные запросы в CA для подписания. Такое делегирование позволяет CA увеличить объём выдачи certificate, не выполняя все проверки самостоятельно. В корпоративной PKI RA может быть отделом HR или службой поддержки IT, которая проверяет запросы сотрудников на certificate.

CA предлагают certificate с разными уровнями проверки, отражающими тщательность проверки личности заявителя. Проверка домена (DV): CA проверяет только то, что заявитель контролирует домен (автоматически, занимает несколько минут, используется Let's Encrypt). Проверка организации (OV): CA проверяет юридическое существование организации (от 1 до 3 рабочих дней). Расширенная проверка (EV): наиболее тщательная проверка — юридическая личность, физический адрес и фактическая деятельность (от 1 до 2 недель; используется для отображения зелёного названия компании в адресной строке браузера). DV достаточно для базового шифрования, а EV подходит для важных целей, например банковских сайтов.

Закрепление certificate — это метод, при котором приложение запрограммировано доверять только определённому certificate или CA, а не любому certificate от любого доверенного корневого CA. Это предотвращает атаки MITM, даже если злоумышленник получит поддельный certificate от доверенного CA. Мобильные приложения и приложения, требующие повышенной безопасности, используют закрепление, чтобы принимать только certificate собственных серверов. Недостаток состоит в том, что при истечении срока действия закреплённого certificate или его замене приложение перестаёт работать до обновления. HPKP (закрепление открытого ключа HTTP) было механизмом закрепления на уровне браузера, от которого отказались из-за риска неправильного развертывания.

Организации запускают собственный частный CA для внутренних задач, связанных с certificate: аутентификации клиентов VPN, выдачи certificate внутренним службам HTTPS, подписи кода и аутентификации устройств. Microsoft Active Directory Certificate Services (AD CS) — наиболее распространённый частный CA в корпоративной среде. certificate внутреннего CA необходимо распространить на все устройства и браузеры, которым требуется доверять certificate, выданным внутри организации, обычно с помощью групповой политики. Частные CA не могут выдавать certificate, которым доверяет общедоступный интернет: они применяются только на устройствах организации, где установлен корневой certificate частного CA.

Компрометация DigiNotar (2011) — важнейший инцидент с CA, который необходимо знать кандидатам на Security+. Голландский CA DigiNotar был взломан злоумышленниками, выдавшими поддельные certificate для Google, Mozilla и государственных доменов. В Иране их использовали для атак «человек посередине» на граждан. В результате все основные разработчики браузеров и операционных систем немедленно удалили DigiNotar из своих хранилищ доверенных корневых certificate, аннулировав все certificate, когда-либо выданные DigiNotar. Через несколько недель DigiNotar обанкротился. Этот инцидент показал, что компрометация CA имеет катастрофические последствия, а также объяснил, почему теперь необходимы DNS-записи CAA, прозрачность certificate и многофакторная аутентификация для систем CA.

Проверьте, насколько хорошо Вы понимаете концепции CompTIA Security+ (SY0-701) из этого урока.

В этом уроке Вы узнали: Certificate Authorities связывают открытые ключи с подтверждёнными идентификациями; цепочка доверия идёт от конечного объекта через промежуточные CA к самоподписанному корневому центру; Root CAs хранятся в автономном режиме в HSM и заранее считаются доверенными операционными системами; а компрометация CA (DigiNotar) может сделать недействительными миллионы сертификатов. Далее мы рассмотрим структуру X.509 Certificate.