Подпись кода - Code signing

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

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

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

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

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

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

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

Надежная идентификация с использованием центра сертификации (ЦС)

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

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

Сертификаты подписи кода с расширенной проверкой (EV) подлежат дополнительной проверке и техническим требованиям. Эти рекомендации основаны на базовых требованиях и рекомендациях по расширенной проверке CA / B Forum. В дополнение к требованиям к валидации, специфичным для 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отображается как commonName эмитента, идентифицируя его как сертификат подписи кода 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. Приложению необходим действующий профиль или сертификат, чтобы оно могло работать на устройствах.

Проблемы

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

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

Реализации

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

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

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

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

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

Смотрите также

использованная литература

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