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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сертификат: Данные: Версия: 3 (0x2) Серийный номер: 59: 4e: 2d: 88: 5a: 2c: b0: 1a: 5e: d6: 4c: 7b: df: 35: 59: 7d Алгоритм подписи: sha256WithRSAEncryption Issuer: 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 ноября 20: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 = Nevada streetAddress = 3100 Richmond Ave Ste 503 businessCategory = Private Organization postalCode = 77098 commonName = SSL Corp serialNumber = NV20081614243 organizationName = SSL Corp localityName = штат Хьюстон OrProvinceName = Техас countryName = США Информация об открытом ключе субъекта: Алгоритм открытого ключа: 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 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 / репозиторий X509v 3 Расширенное использование ключа: Подпись кода 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 ...

Альтернатива ЦС

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

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

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

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

Вход в систему Xcode

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

Проблемы

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

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

Реализации

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

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

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

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

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

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

Рекомендации

  1. ^ «Введение в подписание кода».
  2. ^ Хендрик, Уильям (2015). «Полный обзор доверенных сертификатов - CABForum» (PDF). Получено 2015-02-26.
  3. ^ «Защита ваших закрытых ключей как лучший метод для сертификатов подписи кода» (PDF).
  4. ^ Хендрик, Уильям (17 июня 2011 г.). "Что такое подписывание кода?". Получено 26 февраля 2015.
  5. ^ «Цифровые подписи и установщик Windows».
  6. ^ https://wiki.debian.org/SecureApt
  7. ^ https://casecurity.org/wp-content/uploads/2013/10/CASC-Code-Signing.pdf
  8. ^ «Руководство по выпуску сертификатов подписи расширенного кода проверки и управлению ими» (PDF). CA / Форум браузеров. Получено 4 декабря 2019.
  9. ^ «Политика подписания драйверов». Microsoft. Получено 9 декабря 2019.
  10. ^ «Microsoft SmartScreen и сертификаты подписи кода с расширенной проверкой (EV)». Microsoft. Получено 9 декабря 2019.
  11. ^ а б Мортон, Брюс. «Подписание кода» (PDF). CASC. Получено 21 февраля 2014.
  12. ^ http://blog.trendmicro.com/fake-antivirus-solutions-increasingly-stolen-code-signing-certificates/
  13. ^ http://www.eweek.com/c/a/Security/Theres-A-Racket-Brewing-In-the-Code-Signing-Cert-Business/
  14. ^ Обход строгого имени: блог по безопасности .NET

внешняя ссылка