Войти
Подпись кода - это процесс цифровой подписи исполняемых файлов и скриптов чтобы подтвердить автора программного обеспечения и гарантировать, что код не был изменен или поврежден с момента его подписания. В процессе используется криптографический хэш для проверки подлинности и целостности.
Подписание кода может предоставить несколько ценных функций. Чаще всего подписывание кода используется для обеспечения безопасности при развертывании; в некоторых языках программирования его также можно использовать для предотвращения конфликтов пространств имен. Почти каждая реализация подписи кода будет предоставлять своего рода механизм цифровой подписи для проверки личности автора или системы сборки и контрольную сумму для проверки того, что объект не был изменен. Его также можно использовать для предоставления информации о версиях объекта или для хранения других метаданных об объекте.
Эффективность подписи кода как механизма аутентификации для программного обеспечения зависит от безопасности лежащих в основе ключей подписи. Как и в случае с другими технологиями инфраструктуры открытых ключей (PKI), целостность системы зависит от защиты своих секретных ключей издателями от несанкционированного доступа. Ключи, хранящиеся в программном обеспечении на компьютерах общего назначения, подвержены взлому. Следовательно, более безопасно и лучше всего хранить ключи в защищенных, защищенных от взлома, криптографических аппаратных устройствах, известных как аппаратные модули безопасности или HSM.
Многие реализации подписи кода предоставляют способ подписи кода с использованием системы, включающей пару ключей, один открытый и один частный, аналогично процессу, используемому TLS или SSH. Например, в случае.NET разработчик использует закрытый ключ для подписи своих библиотек или исполняемых файлов при каждой сборке. Этот ключ будет уникальным для разработчика или группы, а иногда и для каждого приложения или объекта. Разработчик может либо сгенерировать этот ключ самостоятельно, либо получить его в доверенном центре сертификации (CA).
Подписание кода особенно ценно в распределенных средах, где источник данной части кода может быть не сразу очевидным - например, Java-апплеты, элементы управления ActiveX и другой активный код сценариев веб-сайтов и браузеров. Еще одно важное применение - безопасное предоставление обновлений и исправлений для существующего программного обеспечения. Windows, Mac OS X и большинство дистрибутивов Linux предоставляют обновления с использованием подписи кода, чтобы гарантировать, что другие не могут злонамеренно распространять код через систему исправлений. Это позволяет операционной системе-получателю проверить, является ли обновление законным, даже если обновление было доставлено третьими сторонами или физическим носителем (дисками).
Подпись кода используется в Windows и Mac OS X для аутентификации программного обеспечения, гарантируя, что программное обеспечение не было злонамеренно подделано сторонним дистрибьютором или сайтом загрузки. Эта форма подписи кода не используется в Linux из-за децентрализованного характера этой платформы, где менеджер пакетов является преобладающим способом распространения для всех форм программного обеспечения (не только обновлений и исправлений), а также модель с открытым исходным кодом, позволяющая при желании напрямую проверить исходный код. Дистрибутивы Linux на основе Debian (среди прочего) проверяют загруженные пакеты с использованием криптографии с открытым ключом.
Открытый ключ , используемый для аутентификации подписи кода, должен быть прослежен до доверенного корневого центра сертификации, предпочтительно с использованием безопасной инфраструктуры открытого ключа (PKI). Это не гарантирует, что самому коду можно доверять, а только то, что он исходит из указанного источника (или, точнее, из определенного закрытого ключа ). ЦС обеспечивает корневой уровень доверия и может назначать доверие другим через прокси. Если пользователь доверяет CA, то он предположительно может доверять легитимности кода, подписанного ключом, сгенерированным этим CA или одним из его прокси. Многие операционные системы и платформы содержат встроенное доверие для одного или нескольких центров сертификации. Для крупных организаций также обычным делом является внедрение частного центра сертификации, внутреннего по отношению к организации, который предоставляет те же функции, что и общедоступные центры сертификации, но ему доверяют только внутри организации.
Сертификаты подписи кода расширенной проверки (EV) подлежат дополнительной проверке и техническим требованиям,. Эти рекомендации основаны на основных требованиях и рекомендациях по расширенной проверке CA / B Forum. В дополнение к требованиям к валидации, характерным для EV, в рекомендациях по подписанию кода EV указано, что «закрытый ключ подписчика генерируется, хранится и используется в криптомодуле, который соответствует требованиям FIPS 140-2 уровня 2 или превышает их»
Некоторым приложениям, таким как подписывание драйверов режима ядра Windows 10, требуется сертификат подписи кода EV. Кроме того, Microsoft IEBlog заявляет, что программы Windows, «подписанные сертификатом подписи кода EV, могут немедленно установить репутацию с помощью служб репутации SmartScreen, даже если для этого файла или издателя не существует предыдущей репутации».
Это пример сертификата подписи декодированного кода EV, используемого SSL.com для подписи программного обеспечения. SSL.com EV Code Signing Intermediate CA RSA R3отображается как commonName эмитента, идентифицируя его как сертификат подписи кода EV. Поле Subjectсертификата описывает SSL Corp как организацию. Подписание кодапоказано как единственное использование расширенного ключа 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 organizationName = SSL Corp localityName = Houston stateOrProvinceName = Texas countryName = US Срок действия Не раньше: 30 августа 20:29:13 2019 GMT Не после: 12 ноября : 29: 13 2022 GMT Тема: 1.3.6.1.4.1.311.60.2.1.3 = US 1.3.6.1.4.1.311.60.2.1.2 = Адрес улицы Невады = 3100 Richmond Ave Ste 503 businessCategory = Почтовый индекс частной организации = 77098 commonName = SSL Corp serialNumber = NV20081614243 organizationName = SSL Corp localityName = Houston stateOrProvinceName = Texas countryName = US Информация об открытом ключе субъекта: Алгоритм открытого ключа: 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 Авторитет y Доступ к информации: CA Issuers - 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 Использование: Подписание кода X509v3 Точки распространения CRL: Полное имя: 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...
Другая модель заключается в том, что разработчики могут предоставить свой собственный самогенерируемый ключ. В этом сценарии пользователю обычно необходимо каким-либо образом получить открытый ключ непосредственно от разработчика, чтобы убедиться, что объект принадлежит им в первый раз. Многие системы подписи кода хранят открытый ключ внутри подписи. Некоторые программные среды и ОС, которые проверяют подпись кода перед выполнением, позволяют вам доверять этому разработчику с этого момента после первого запуска. Разработчик приложения может предоставить аналогичную систему, включив в программу установки открытые ключи. Затем ключ можно использовать для гарантии того, что все последующие объекты, которые необходимо запустить, такие как обновления, плагины или другое приложение, проверены как исходящие от того же разработчика.
Отметка времени была разработана, чтобы обойти предупреждение о доверии, которое появляется в случае истекшего сертификата. Фактически, отметка времени расширяет доверие к коду за пределы срока действия сертификата.
В случае, если сертификат должен быть отозван из-за компрометации, конкретная дата и время компрометирующего события станут часть записи об отзыве. В этом случае отметка времени помогает определить, был ли код подписан до или после взлома сертификата.
Разработчикам необходимо подписать свои приложения для iOS и tvOS перед их запуском на любом реальном устройстве и перед загрузкой в App Store. Это необходимо, чтобы доказать, что у разработчика есть действующий идентификатор разработчика Apple. Приложению необходим действующий профиль или сертификат, чтобы оно могло работать на устройствах.
Как и любую другую меру безопасности, подписание кода можно обойти. Пользователей можно обманом заставить запустить неподписанный код или даже запустить код, который отказывается проверять, и система остается защищенной только до тех пор, пока закрытый ключ остается закрытым.
Также важно отметить, что подписывание кода делает не защищать конечного пользователя от любых злонамеренных действий или непреднамеренных ошибок программного обеспечения со стороны автора программного обеспечения - он просто гарантирует, что программное обеспечение не было изменено кем-либо, кроме автора. Иногда системы песочницы не принимают сертификаты из-за ложной отметки времени или из-за чрезмерного использования ОЗУ.
Microsoft реализует предоставленную форму подписи кода (на основе Authenticode) для драйверов, протестированных Microsoft. Поскольку драйверы запускаются в ядре, они могут дестабилизировать систему или открыть в системе бреши в безопасности. По этой причине Microsoft тестирует драйверы, представленные в своей программе WHQL. После прохождения драйвера Microsoft подписывает эту версию драйвера как безопасную. Только в 32-разрядных системах установка драйверов, не прошедших проверку Microsoft, возможна после принятия разрешения на установку в виде подсказки, предупреждающей пользователя о том, что код не подписан. Для (управляемого) кода.NET существует дополнительный механизм, называемый Strong Name Signing, который использует открытые / закрытые ключи и хэш SHA -1 вместо сертификатов. Однако Microsoft не рекомендует использовать строгую подпись имен в качестве замены Authenticode.
В контексте потребительских устройств, таких как игровые консоли термин «неподписанный код» часто используется для обозначения приложения, которое не было подписано с помощью криптографического ключа, обычно необходимого для принятия и выполнения программного обеспечения. Большинство консольных игр должны быть подписаны секретным ключом, разработанным производителем консоли, иначе игра не загрузится на консоли. Существует несколько методов получения кода без знака для выполнения, включая программные эксплойты, использование modchip, метод, известный как трюк подкачки или запуск softmod.
Сначала может показаться не очевидным, почему простое копирование подписанного приложения на другой DVD не позволяет ему загрузиться. На Xbox причина этого заключается в том, что исполняемый файл Xbox (XBE) содержит флаг типа носителя, который указывает тип носителя, с которого можно загружать XBE. Почти во всем программном обеспечении Xbox это установлено так, что исполняемый файл будет загружаться только с заводских дисков, поэтому простого копирования исполняемого файла на записываемый носитель достаточно, чтобы остановить выполнение программного обеспечения.
Однако, поскольку исполняемый файл подписан, простое изменение значения флага невозможно, так как это изменяет подпись исполняемого файла, что приводит к сбою проверки при проверке.
