Подписание кода — это процесс цифровой подписи исполняемых файлов и скриптов для подтверждения автора программного обеспечения и гарантии того, что код не был изменен или поврежден с момента его подписания. В этом процессе используется криптографический хэш для проверки подлинности и целостности. [1] Подписание кода было изобретено в 1995 году Майклом Дойлом как часть подключаемого модуля браузера Eolas WebWish, который позволял использовать криптографию с открытым ключом для подписи загружаемого программного кода веб-приложения с использованием секретного ключа, поэтому интерпретатор кода подключаемого модуля мог затем использовать соответствующий открытый ключ для аутентификации кода, прежде чем предоставить ему доступ к API интерпретатора кода. [2]
Подписание кода может предоставить несколько ценных функций. Наиболее распространенное использование подписи кода — обеспечение безопасности при развертывании; в некоторых языках программирования ее также можно использовать для предотвращения конфликтов пространств имен. Почти каждая реализация подписи кода будет предоставлять некий механизм цифровой подписи для проверки личности автора или системы сборки, а также контрольную сумму для проверки того, что объект не был изменен. Ее также можно использовать для предоставления информации о версии объекта или для хранения других метаданных об объекте. [3]
Эффективность подписи кода как механизма аутентификации для программного обеспечения зависит от безопасности базовых ключей подписи. Как и в случае с другими технологиями инфраструктуры открытых ключей (PKI) , целостность системы зависит от защиты издателями своих закрытых ключей от несанкционированного доступа. Ключи, хранящиеся в программном обеспечении на компьютерах общего назначения, подвержены компрометации. Поэтому более безопасно и лучше всего хранить ключи в защищенных, защищенных от несанкционированного доступа криптографических аппаратных устройствах, известных как аппаратные модули безопасности или HSM . [4]
Многие реализации подписи кода предоставят способ подписать код с помощью системы, включающей пару ключей, один открытый и один закрытый, аналогично процессу, используемому TLS или SSH . Например, в случае .NET разработчик использует закрытый ключ для подписи своих библиотек или исполняемых файлов каждый раз, когда он их собирает. Этот ключ будет уникальным для разработчика или группы, а иногда и для каждого приложения или объекта. Разработчик может либо сгенерировать этот ключ самостоятельно, либо получить его из доверенного центра сертификации (CA). [5]
Подписание кода особенно ценно в распределенных средах, где источник данного фрагмента кода может быть не сразу очевиден - например, Java-апплеты , элементы управления ActiveX и другой активный веб- и браузерный скриптовый код. Другое важное применение - безопасное предоставление обновлений и исправлений для существующего программного обеспечения. [6] Windows , Mac OS X и большинство дистрибутивов Linux предоставляют обновления с использованием подписи кода, чтобы гарантировать, что другие не смогут злонамеренно распространять код через систему исправлений. Это позволяет принимающей операционной системе проверить, что обновление является законным, даже если обновление было доставлено третьими лицами или физическими носителями (дисками). [7]
Подписание кода используется в Windows и Mac OS X для аутентификации программного обеспечения при первом запуске, гарантируя, что программное обеспечение не было злонамеренно изменено сторонним дистрибьютором или сайтом загрузки. Эта форма подписания кода не используется в Linux из-за децентрализованной природы этой платформы, менеджер пакетов является преобладающим способом распространения для всех форм программного обеспечения (не только обновлений и исправлений), а также из-за модели с открытым исходным кодом, позволяющей при желании напрямую проверять исходный код. Дистрибутивы Linux на основе Debian (среди прочих) проверяют загруженные пакеты с помощью криптографии с открытым ключом. [8]
Открытый ключ, используемый для аутентификации подписи кода, должен прослеживаться до доверенного корневого центра сертификации CA, предпочтительно с использованием защищенной инфраструктуры открытых ключей (PKI). Это не гарантирует, что самому коду можно доверять, а только то, что он исходит из указанного источника (или, более явно, из определенного закрытого ключа ). [9] CA обеспечивает уровень корневого доверия и может назначать доверие другим через доверенное лицо. Если пользователь доверяет CA, то он, по-видимому, может доверять легитимности кода, подписанного ключом, сгенерированным этим CA или одним из его доверенных лиц. Многие операционные системы и фреймворки содержат встроенное доверие для одного или нескольких центров сертификации. Также обычным делом для крупных организаций является внедрение частного CA, внутреннего для организации, который предоставляет те же функции, что и открытые CA, но он доверен только внутри организации.
Сертификаты подписи кода расширенной проверки (EV) подлежат дополнительной проверке и техническим требованиям. Эти руководящие принципы основаны на базовых требованиях и руководящих принципах расширенной проверки CA/B Forum. В дополнение к требованиям проверки, специфичным для EV, руководящие принципы подписи кода EV предусматривают, что «закрытый ключ подписчика генерируется, хранится и используется в криптомодуле, который соответствует или превосходит требования FIPS 140-2 уровня 2». [10]
Некоторые приложения, такие как подписание драйверов режима ядра Windows 10, требуют сертификата подписи кода EV. [11] Кроме того, в блоге Microsoft IEBlog говорится, что программы Windows, «подписанные сертификатом подписи кода EV, могут немедленно устанавливать репутацию в службах репутации SmartScreen , даже если для этого файла или издателя ранее не существовало репутации». [12]
Это пример декодированного сертификата подписи кода EV, используемого SSL.com для подписи программного обеспечения. SSL.com EV Code Signing Intermediate CA RSA R3отображается как commonName эмитента, идентифицируя его как сертификат подписи кода EV. SubjectПоле сертификата описывает SSL Corp как организацию. Code Signingотображается как единственное X509v3 Extended Key Usage.
Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d Алгоритм подписи: sha256WithRSAEncryption Эмитент: commonName = SSL.com EV Code Signing Intermediate CA RSA R3 Название организации = SSL Corp localityName = Хьюстон stateOrProvinceName = Техас Название страны = США Действительность Не раньше: 30 августа 2019 20:29:13 GMT Не позже: 12 ноября 20:29:13 2022 GMT Предмет: 1.3.6.1.4.1.311.60.2.1.3 = США 1.3.6.1.4.1.311.60.2.1.2 = Невада Адрес улицы = 3100 Richmond Ave Ste 503 businessCategory = Частная организация почтовый индекс = 77098 commonName = SSL Corp серийный номер = NV20081614243 Название организации = SSL Corp localityName = Хьюстон stateOrProvinceName = Техас Название страны = США Информация о публичном ключе субъекта: Алгоритм открытого ключа: rsaEncryption Открытый ключ: (2048 бит) Модуль: 00:c3:e9:ae:be:d7:a2:6f:2f:24 ... Экспонента: 65537 (0x10001) Расширения X509v3: Идентификатор ключа авторизации X509v3: keyid:36:BD:49:FF:31:2C:EB:AF:6A:40:FE:99:C0:16:ED:BA:FC:48:DD:5F Доступ к информации органов власти: Эмитенты CA - URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt OCSP - URI: http://ocsps.ssl.com Политики сертификата X509v3: Политика: 2.23.140.1.3 Политика: 1.2.616.1.113527.2.5.1.7 Политика: 1.3.6.1.4.1.38064.1.3.3.2 CPS: https://www.ssl.com/repository Использование расширенного ключа X509v3: Подписание кода Точки распространения CRL X509v3: Полное имя: URI:http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl Идентификатор ключа субъекта X509v3: EC:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE Использование ключа X509v3: критическое Цифровая подпись Алгоритм подписи: sha256WithRSAEncryption 17:d7:a1:26:58:31:14:2b:9f:3b ...
Другая модель — это модель доверия при первом использовании , в которой разработчики могут выбрать предоставление собственного сгенерированного ключа. В этом сценарии пользователю обычно приходится получать открытый ключ каким-либо образом непосредственно от разработчика, чтобы впервые убедиться, что объект принадлежит ему. Многие системы подписи кода сохраняют открытый ключ внутри подписи. Некоторые программные фреймворки и ОС, которые проверяют подпись кода перед выполнением, позволят вам доверять этому разработчику с этого момента после первого запуска. Разработчик приложения может предоставить аналогичную систему, включив открытые ключи в установщик. Затем ключ можно использовать для того, чтобы гарантировать, что все последующие объекты, которые необходимо запустить, такие как обновления, плагины или другое приложение, проверены как поступающие от того же разработчика.
Временная отметка была разработана для обхода предупреждения о доверии, которое появится в случае просроченного сертификата. По сути, временная отметка расширяет доверие к коду за пределы срока действия сертификата. [13]
В случае, если сертификат должен быть отозван из-за компрометации, конкретная дата и время события компрометации станут частью записи отзыва. В этом случае отметка времени помогает установить, был ли код подписан до или после компрометации сертификата. [13]
Разработчикам необходимо подписать свои приложения iOS и tvOS перед запуском их на любом реальном устройстве и перед загрузкой их в App Store . Это необходимо для доказательства того, что разработчик владеет действительным идентификатором разработчика Apple. Для запуска приложения на устройствах необходим действительный профиль или сертификат. [14]
Как и любая мера безопасности, подпись кода может быть обманута. Пользователи могут быть обмануты и запущены неподписанным кодом или даже кодом, который отказывается проходить проверку, и система остается безопасной только до тех пор, пока закрытый ключ остается закрытым. [15] [16]
Также важно отметить, что подписание кода не защищает конечного пользователя от какой-либо вредоносной деятельности или непреднамеренных ошибок программного обеспечения со стороны автора программного обеспечения — оно просто гарантирует, что программное обеспечение не было изменено никем, кроме автора. Иногда системы-песочницы не принимают сертификаты из-за ложной временной метки или из-за избыточного использования оперативной памяти .
Microsoft реализует форму подписи кода (основанную на Authenticode), предоставляемую для проверенных Microsoft драйверов. Поскольку драйверы работают в ядре, они могут дестабилизировать систему или открыть ее для уязвимостей безопасности. По этой причине Microsoft тестирует драйверы, представленные в ее программе WHQL . После того, как драйвер прошел проверку, Microsoft подписывает эту версию драйвера как безопасную. Только на 32-разрядных системах установка драйверов, не проверенных Microsoft, возможна после согласия разрешить установку в приглашении, предупреждающем пользователя о том, что код не подписан. Для кода .NET (управляемого) существует дополнительный механизм, называемый Strong Name Signing , который использует открытые/закрытые ключи и хэш SHA -1 вместо сертификатов. Однако Microsoft не рекомендует полагаться на Strong Name Signing в качестве замены Authenticode. [17]
Рабочая группа по подписи кода Форума CA/Browser решила, что с 1 июня 2023 года все сертификаты подписи кода (не только EA) должны требовать хранения закрытых ключей на физическом носителе, например, в аппаратном криптографическом модуле, соответствующем как минимум FIPS 140-2 Level 2 или Common Criteria EAL 4+. [18] Впоследствии центры сертификации опубликовали заявления о соблюдении этого решения. [19] [20] [21] [22] [23] [24] [25]
В контексте потребительских устройств, таких как игровые консоли , термин «неподписанный код» часто используется для обозначения приложения, которое не было подписано криптографическим ключом , обычно требуемым для принятия и выполнения программного обеспечения. Большинство консольных игр должны быть подписаны секретным ключом, разработанным производителем консоли, иначе игра не будет загружаться на консоль (как для обеспечения блокировки поставщика, так и для борьбы с пиратством программного обеспечения). Существует несколько методов получения неподписанного кода для выполнения, которые включают в себя программные эксплойты , использование модчипа , технику, известную как трюк с подкачкой, или запуск софтмода .
Поначалу может показаться неочевидным, почему простое копирование подписанного приложения на другой DVD не позволяет ему загрузиться. На Xbox причина этого в том, что исполняемый файл Xbox (XBE) содержит флаг типа носителя, который указывает тип носителя, с которого загружается XBE. Почти во всем программном обеспечении Xbox это установлено таким образом, что исполняемый файл будет загружаться только с дисков заводского производства, поэтому простого копирования исполняемого файла на записываемый носитель достаточно, чтобы остановить выполнение программного обеспечения.
Однако поскольку исполняемый файл подписан, простое изменение значения флага невозможно, поскольку это изменяет подпись исполняемого файла, что приводит к тому, что он не проходит проверку.
(Раздел 1.2.2) [...] Начиная с 1 июня 2023 г. для сертификатов подписи кода центры сертификации ДОЛЖНЫ гарантировать, что закрытый ключ подписчика генерируется, хранится и используется в подходящем аппаратном криптографическом модуле, который соответствует требованиям, указанным в разделе 6.2.7.4.1, или превосходит их, используя один из методов, указанных в пункте 6.2.7.4.2.