Подписание кода — это процесс цифровой подписи исполняемых файлов и сценариев для подтверждения автора программного обеспечения и гарантии того, что код не был изменен или поврежден с момента его подписания. В этом процессе используется криптографический хэш для проверки подлинности и целостности. [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]
Открытый ключ , используемый для аутентификации подписи кода, должен прослеживаться до доверенного корневого центра сертификации, предпочтительно с использованием безопасной инфраструктуры открытых ключей (PKI). Это не гарантирует, что самому коду можно доверять, а только то, что он получен из указанного источника (или, более явно, из определенного закрытого ключа ). [9] Центр сертификации обеспечивает корневой уровень доверия и может назначать доверие другим через прокси. Если пользователь доверяет ЦС, то он предположительно может доверять легитимности кода, подписанного ключом, сгенерированным этим ЦС или одним из его прокси. Многие операционные системы и платформы содержат встроенное доверие для одного или нескольких центров сертификации. В крупных организациях также обычным явлением является внедрение частного центра сертификации, внутреннего для организации, который предоставляет те же функции, что и общедоступные центры сертификации, но ему доверяют только внутри организации.
Сертификаты подписи кода расширенной проверки (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отображается как общее имя эмитента, идентифицируя его как сертификат подписи кода EV. Поле сертификата Subjectописывает SSL Corp как организацию. Code Signingотображается как единственное расширенное использование ключа X509v3.
Сертификат: Данные: Версия: 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 августа 20:29:13 2019 г. по Гринвичу Не после: 12 ноября 20:29:13 2022 г. по Гринвичу Предмет: 1.3.6.1.4.1.311.60.2.1.3 = США 1.3.6.1.4.1.311.60.2.1.2 = Невада streetAddress = 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 Доступ к информации органов власти: Эмитенты ЦС — 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 Developer ID. Приложению необходим действительный профиль или сертификат, чтобы оно могло работать на устройствах. [14]
Как и любую меру безопасности, подпись кода можно обойти. Пользователей можно обманом заставить запустить неподписанный код или даже запустить код, который отказывается проверять, и система остается безопасной только до тех пор, пока закрытый ключ остается закрытым. [15] [16]
Также важно отметить, что подписание кода не защищает конечного пользователя от каких-либо вредоносных действий или непреднамеренных ошибок в программном обеспечении со стороны автора программного обеспечения — оно просто гарантирует, что программное обеспечение не было изменено никем, кроме автора. Иногда песочницы не принимают сертификаты из-за ложной отметки времени или из-за чрезмерного использования оперативной памяти .
Microsoft реализует форму подписи кода (на основе Authenticode), предоставляемую для протестированных Microsoft драйверов. Поскольку драйверы работают в ядре, они могут дестабилизировать систему или открыть в системе дыры в безопасности. По этой причине Microsoft тестирует драйверы, представленные в ее программе WHQL . После прохождения драйвера Microsoft подписывает эту версию драйвера как безопасную. Только в 32-разрядных системах установка драйверов, не проверенных Microsoft, возможна после того, как вы согласитесь разрешить установку и получите приглашение, предупреждающее пользователя о том, что код не подписан. Для (управляемого) кода .NET существует дополнительный механизм, называемый строгой подписью имени , который использует открытые/закрытые ключи и хэш SHA -1 вместо сертификатов. Однако Microsoft не рекомендует использовать подпись строгого имени в качестве замены Authenticode. [17]
В контексте потребительских устройств, таких как игровые консоли , термин «неподписанный код» часто используется для обозначения приложения, которое не было подписано криптографическим ключом , обычно необходимым для принятия и выполнения программного обеспечения. Большинство консольных игр необходимо подписывать секретным ключом, разработанным производителем консоли, иначе игра не загрузится на консоли. Существует несколько методов выполнения неподписанного кода, включая программные эксплойты , использование модчипа , технику, известную как трюк подкачки, или запуск софтмода .
Поначалу может показаться неочевидным, почему простое копирование подписанного приложения на другой DVD не позволяет ему загрузиться. На Xbox причина этого в том, что исполняемый файл Xbox (XBE) содержит флаг типа носителя, который указывает тип носителя, с которого загружается XBE. Почти во всех программах Xbox это настроено таким образом, что исполняемый файл будет загружаться только с заводских дисков, поэтому простого копирования исполняемого файла на записываемый носитель достаточно, чтобы остановить выполнение программного обеспечения.
Однако, поскольку исполняемый файл подписан, простое изменение значения флага невозможно, поскольку это изменяет подпись исполняемого файла, что приводит к сбою проверки при проверке.