Подписание кода

Подписание кода — это процесс цифровой подписи исполняемых файлов и сценариев для подтверждения автора программного обеспечения и гарантии того, что код не был изменен или поврежден с момента его подписания. В этом процессе используется криптографический хэш для проверки подлинности и целостности. Подписание кода было изобретено в 1995 году Майклом Дойлом как часть подключаемого модуля браузера Eolas WebWish, который позволял использовать криптографию с открытым ключом для подписи программного кода загружаемого веб-приложения с использованием секретного ключа, чтобы интерпретатор кода подключаемого модуля мог затем используйте соответствующий открытый ключ для аутентификации кода, прежде чем разрешить ему доступ к API-интерфейсам интерпретатора кода.

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

Эффективность подписи кода как механизма аутентификации программного обеспечения зависит от безопасности ключей подписи. Как и в случае с другими технологиями инфраструктуры открытых ключей (PKI) , целостность системы зависит от защиты издателями своих личных ключей от несанкционированного доступа. Ключи, хранящиеся в программном обеспечении на компьютерах общего назначения, могут быть скомпрометированы. Поэтому более безопасно и рекомендуется хранить ключи в защищенных, защищенных от несанкционированного доступа криптографических аппаратных устройствах, известных как аппаратные модули безопасности или HSM .

Обеспечение безопасности

Многие реализации подписи кода предоставляют возможность подписывать код с использованием системы, включающей пару ключей, один открытый и один частный, аналогично процессу, используемому TLS или SSH . Например, в случае .NET разработчик использует закрытый ключ для подписи своих библиотек или исполняемых файлов при каждой сборке. Этот ключ будет уникальным для разработчика или группы, а иногда и для каждого приложения или объекта. Разработчик может либо создать этот ключ самостоятельно, либо получить его от доверенного центра сертификации (CA).

Подписание кода особенно ценно в распределенных средах, где источник данного фрагмента кода может быть не сразу очевиден — например, Java-апплеты , элементы управления ActiveX и другой активный код сценариев для веб-сайтов и браузеров. Еще одним важным применением является безопасное предоставление обновлений и исправлений для существующего программного обеспечения. Windows , Mac OS X и большинство дистрибутивов Linux предоставляют обновления с использованием подписи кода, чтобы гарантировать, что другие не смогут злонамеренно распространять код через систему исправлений. Это позволяет принимающей операционной системе проверить легитимность обновления, даже если оно было доставлено третьими лицами или физическим носителем (дисками).

Подписание кода используется в Windows и Mac OS X для аутентификации программного обеспечения при первом запуске , гарантируя, что программное обеспечение не было злонамеренно изменено сторонним дистрибьютором или сайтом загрузки. Эта форма подписи кода не используется в Linux из-за децентрализованного характера этой платформы, менеджер пакетов является преобладающим способом распространения для всех форм программного обеспечения (не только обновлений и исправлений), а также модели с открытым исходным кодом, позволяющей прямую проверку. исходного кода при желании. Дистрибутивы Linux на основе Debian (среди прочих) проверяют загруженные пакеты с использованием шифрования с открытым ключом.

Доверенная идентификация с использованием центра сертификации (CA)

Открытый ключ, используемый для аутентификации подписи кода, должен прослеживаться до доверенного корневого центра сертификации, предпочтительно с использованием безопасной инфраструктуры открытых ключей (PKI). Это не гарантирует, что самому коду можно доверять, а только то, что он получен из указанного источника (или, более явно, из определенного закрытого ключа ). Центр сертификации обеспечивает корневой уровень доверия и может назначать доверие другим через прокси. Если пользователь доверяет ЦС, то он, вероятно, может доверять легитимности кода, подписанного ключом, сгенерированным этим ЦС или одним из его прокси. Многие операционные системы и платформы содержат встроенное доверие для одного или нескольких центров сертификации. В крупных организациях также обычным явлением является внедрение частного центра сертификации, внутреннего для организации, который предоставляет те же функции, что и общедоступные центры сертификации, но ему доверяют только внутри организации.

Подписание кода расширенной проверки (EV)

Сертификаты подписи кода расширенной проверки (EV) подлежат дополнительной проверке и техническим требованиям. Эти рекомендации основаны на базовых требованиях и правилах расширенной проверки Форума CA/B. В дополнение к требованиям проверки, специфичным для EV, рекомендации по подписи кода EV предусматривают, что «закрытый ключ подписчика генерируется, хранится и используется в криптомодуле, который соответствует требованиям FIPS 140-2 уровня 2 или превосходит их».

Для некоторых приложений, например для подписи драйверов режима ядра Windows 10, требуется сертификат подписи кода EV. Кроме того, в журнале Microsoft IEBlog говорится, что программы Windows, «подписанные сертификатом подписи кода EV, могут немедленно установить репутацию с помощью служб репутации SmartScreen , даже если для этого не существует предварительной репутации». файл или издатель».

Образец сертификата подписи кода EV

Это пример декодированного сертификата подписи кода EV, используемого SSL.com для подписи программного обеспечения. SSL.com EV Code Signing Intermediate CA RSA R3 отображается как общее имя эмитента, идентифицируя его как сертификат подписи кода EV. Сертификат Subject Поле описывает SSL Corp как организацию. Code Signing отображается как единственное расширенное использование ключа X509v3.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d
    Signature Algorithm: sha256WithRSAEncryption
        Issuer:
            commonName                = SSL.com EV Code Signing Intermediate CA RSA R3
            organizationName          = SSL Corp
            localityName              = Houston
            stateOrProvinceName       = Texas
            countryName               = US
        Validity
            Not Before: Aug 30 20:29:13 2019 GMT
            Not After : Nov 12 20:29:13 2022 GMT
        Subject:
            1.3.6.1.4.1.311.60.2.1.3 = US
            1.3.6.1.4.1.311.60.2.1.2 = Nevada
            streetAddress             = 3100 Richmond Ave Ste 503
            businessCategory          = Private Organization
            postalCode                = 77098
            commonName                = SSL Corp
            serialNumber              = NV20081614243
            organizationName          = SSL Corp
            localityName              = Houston
            stateOrProvinceName       = Texas
            countryName               = US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c3:e9:ae:be:d7:a2:6f:2f:24 ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:36:BD:49:FF:31:2C:EB:AF:6A:40:FE:99:C0:16:ED:BA:FC:48:DD:5F
                
            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com
                
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.3
                Policy: 1.2.616.1.113527.2.5.1.7
                Policy: 1.3.6.1.4.1.38064.1.3.3.2
                  CPS: https://www.ssl.com/repository
                  
            X509v3 Extended Key Usage: 
                Code Signing
            X509v3 CRL Distribution Points: 
            
                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl
                  
            X509v3 Subject Key Identifier: 
                EC:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE
            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: sha256WithRSAEncryption
         17:d7:a1:26:58:31:14:2b:9f:3b ...

Альтернатива центрам сертификации

Другая модель — это модель доверия при первом использовании , в которой разработчики могут предоставить свой собственный самостоятельно сгенерированный ключ. В этом сценарии пользователю обычно приходится каким-то образом получать открытый ключ непосредственно от разработчика, чтобы убедиться, что объект принадлежит ему в первый раз. Многие системы подписи кода хранят открытый ключ внутри подписи. Некоторые программные платформы и ОС, которые проверяют подпись кода перед выполнением, позволят вам доверять этому разработчику с этого момента после первого запуска. Разработчик приложения может предоставить аналогичную систему, включив открытые ключи в программу установки. Затем ключ можно использовать для проверки того, что любые последующие объекты, которые необходимо запустить, такие как обновления, плагины или другое приложение, проверены как принадлежащие тому же разработчику.

Отметка времени

Отметка времени была разработана, чтобы обойти предупреждение о доверии, которое появится в случае истечения срока действия сертификата. По сути, отметка времени расширяет доверие к коду за пределы срока действия сертификата.

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

Подписание кода в Xcode

Разработчикам необходимо подписывать свои приложения iOS и tvOS перед их запуском на любом реальном устройстве и перед загрузкой в ​​App Store . Это необходимо, чтобы доказать, что разработчик владеет действительным идентификатором Apple Developer ID. Приложению необходим действительный профиль или сертификат, чтобы оно могло работать на устройствах.

Проблемы

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

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

Реализации

Microsoft реализует форму подписи кода (на основе Authenticode), предоставляемую для протестированных Microsoft драйверов. Поскольку драйверы работают в ядре, они могут дестабилизировать систему или открыть в системе дыры в безопасности. По этой причине Microsoft тестирует драйверы, представленные в ее программе WHQL . После прохождения драйвера Microsoft подписывает эту версию драйвера как безопасную. Только в 32-разрядных системах установка драйверов, не проверенных Microsoft, возможна после того, как вы согласитесь разрешить установку и получите приглашение, предупреждающее пользователя о том, что код не подписан. Для (управляемого) кода .NET существует дополнительный механизм, называемый строгой подписью имени , который использует открытые/закрытые ключи и хэш SHA -1 вместо сертификатов. Однако Microsoft не рекомендует использовать подпись строгого имени в качестве замены Authenticode.

Рабочая группа по подписи кода Форума CA/браузера решила, что с 1 июня 2023 года все сертификаты подписи кода (не только сертификаты EA) должны обязательно хранить секретный ключ на физическом носителе, например, в аппаратном криптомодуле, соответствующем минимум FIPS 140-2 уровня 2 или общих критериев EAL 4+. Впоследствии центральные органы опубликовали заявления о выполнении этого решения.

Неподписанный код в игровых и потребительских устройствах

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

Поначалу может показаться неочевидным, почему простое копирование подписанного приложения на другой DVD не позволяет ему загрузиться. На Xbox причина этого в том, что исполняемый файл Xbox (XBE) содержит флаг типа носителя, который указывает тип носителя, с которого загружается XBE. Почти во всех программах Xbox это настроено таким образом, что исполняемый файл будет загружаться только с заводских дисков, поэтому простого копирования исполняемого файла на записываемый носитель достаточно, чтобы остановить выполнение программного обеспечения.

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

См. также

• Цифровая подпись
• джейлбрейк iOS
• PlayStation Portable в домашних условиях
• Повышение привилегий
• Рутирование (ОС Android)
• Обход безопасности Symbian OS

Внешние ссылки

• Руководство по подписанию кода Apple
• Microsoft: введение в подпись кода
• Инфраструктура безопасности Debian
• HOWTO по сильному распределению