Pull to refresh

Что означают для разработчиков новые требования к сертификатам подписи кода?

В декабре 2016 Совет безопасности центров сертификации (Certificate Authority Security Council — CASC) официально опубликовал новые минимальные требования к сертификатам подписи кода. Таким образом у центров сертификации (CA) впервые появляется набор унифицированных политик выпуска и управления, разработанных специально для подписи кода. С полным списком требований можно ознакомиться в этом документе: Минимальные требования к выпуску публичных доверенных сертификатов подписи кода и управлению ими.

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

Закрытые ключи должны храниться на криптографических аппаратных средствах
По мнению CASC, одной из самых распространенных причин взлома подписи является компрометация ключа. Так называется ситуация, когда злоумышленники получают доступ к закрытому ключу от законного и благонадежного издателя и используют его для подписи вредоносного файла, чтобы пользователи доверяли этому файлу и загружали его. Хранение ключей на защищенном криптографическом оборудовании, например USB-токенах или модуле аппаратной защиты (HSM), значительно снижает вероятность компрометации ключа в сравнении с хранением ключей на локальных компьютерах (наиболее популярным методом до введения новых требований).

Унифицированная и строгая проверка идентификационных данных

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

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

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

Информирование и реагирование на несанкционированное использование сертификата или подозрительный код

Помимо мер, направленных на предотвращение выдачи сертификатов, новые требования обязывают центры сертификации внедрить систему информирования о проблемах с сертификатами, которая позволит третьим сторонам (например, производителям антивирусного ПО, доверяющим сторонам или поставщикам ПО) предоставлять информацию «о предполагаемой компрометации закрытого ключа, несанкционированном использовании сертификата, использовании сертификата для подписи подозрительного кода, атаках с перехватом управления или других возможных методах мошенничества, компрометации, несанкционированного использования, ненадлежащего поведения, а также о любых других проблемах, связанных с сертификатами».

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

Новая система информирования означает, что даже если недобросовестному издателю удастся пройти процедуру проверки, о его сертификате вскоре будет получена соответствующая информация, после чего будет проведено расследование, и сертификат будет отозван.

Все центры сертификации должны предлагать временные метки

Еще одно новое требование, представляющее интерес для разработчиков, касается временных меток. Все центры сертификации теперь должны использовать службу временных меток, соответствующую стандарту RFC-3161 и доступную для всех клиентов, использующих подпись кода. Это означает, что доверенная временная метка может быть включена в каждую подпись. (Примечание. Компания GlobalSign всегда предоставляла временные метки клиентам, использующим подпись кода.)

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

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

Безопасное будущее для подписей кода

Новые стандарты и требования являются важным шагом на пути к сокращению случаев взлома подписей кода. Microsoft — это первый поставщик прикладного программного обеспечения, который принял эти рекомендации и начнет их применять с 1 февраля 2017 г. Все сертификаты подписи кода GlobalSign будут соответствовать новым требованиям до наступления этой даты.
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.