Как подписать код программы

Содержание

С 2014 г. для запуска приложения Java в веб-браузере необходимо получить цифровой сертификат и «подписать» код программы. Это относится к размещаемым на web-странице приложениям типа апплет, выполненным в виде jar файла. Но, если можно подписать апплет, то, следовательно, можно подписать и обычное десктопное (desktop) Java-приложение, выполненное в виде jar. И не обязательно, чтобы этот jar был исполняемым; он может выполнять функции java-библиотеки.

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

Но, вот закрытый код в виде jar-файла следует каким-либо образом защитить; это можно сделать с использованием цифровой подписи. Конечно, цифровая подпись не защитит код от взлома – файл можно декомпилировать, внести изменения и снова собрать. Но после таких махинаций цифровая подпись станет недействительной, и автор может либо предъявить претензии, либо откреститься от непредусмотренных кодом действий. То есть, автор не будет нести ответственность перед пользователем за модифицированное приложение.

Как подписать документ в программе eParakstītājs

В данной статье будет рассмотрен вопрос цифровой подписи jar файлов.

Самоподписанный сертификат

Для подписи jar файла будем использовать утилиту jarsigner, которая входит в комплект поставки JDK (Java Development Kit). Первое, что нам нужно – это получить цифровой сертификат. Мудрить долго не будем и воспользуемся самоподписанным сертификатом, который сами же и создадим с помощью утилиты keytool. О том, как создать самоподписанный сертификат, а также опции утилиты keytool подробно описано здесь. Не будем повторяться и выполним следующую команду :

C:Program FilesJavajdk1.8.0_161bin>keytool -v -genkey -dname «CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF» -alias codesigner -storetype jks -keystore keystore.jks -validity 365 -keyalg RSA -keysize 2048 -storepass mystorepass -keypass mykeypass Generating 2 048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 365 days for: CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [Storing keystore.jks] Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using «keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12».

При выполнении данной команды будет создано хранилище keystore.jks с сертификатом, алиас которого ‘codesigner’. Если хранилище keystore.jks было создано ранее, то в него будет добавлен новый сертификат. Для доступа к хранилищу и сертификату определены соответствующие пароли : mystorepass и mykeypass.

Проект приложения

В качестве примера для тестирования подписи jar файла создадим проект certificate-reader в IDE Eclipse, представленный на следующем скриншоте. В проект включим класс CertificateReader, позволяющий выполнять чтение сертификатов хранилища. Описание данного класса приведено здесь. Поэтому, на описании и функциональных возможностях класса останавливаться не будем, а сразу же создадим исполняемый модуль certificate-reader.jar, который будем «подписывать».

Как подписать программу цифровой подписью

В проект включены три командных bat-файла, которые можно использовать для старта самого приложения из командной строки, подписи файла и проверки цифровой подписи файла, а также хранилище keystore.jks с самоподписанным сертификатом.

Файл MANIFEST.MF до подписи

Первое, на что следует обратить внимание в jar файле, так это на содержимое манифеста META-INF/MANIFEST.MF, который включает только наименование основного класса, имеющего метод main для старта приложения :

Manifest-Version: 1.0 Class-Path: . Main-Class: com.labir.CertificateReader

Примечание : jar-файл – это архив, который можно открыть любым из архиваторов, например 7-zip. Кроме этого содержимое архива включает директорию META-INF с файлом манифеста MANIFEST.MF.

Утилита формирования подписи, jarsigner

После того, как jar файл подготовлен, переходим к подписи файла с использованием утилиты jarsigner, входящей в комплект JDK. Утилита jarsigner является инструментом для решения двух задач :

подпись архива java (файл jar);
проверка подписи файлов jar.

Цифровая подпись представляет строку битов, которая вычисляется из некоторых данных («подписываемые» данные) с помощью закрытого ключа. Отличительные характеристики цифровой подписи :

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

Чтобы генерировать цифровые подписи jar файлов jarsigner использует ключ и сертификат хранилища, который является базой данных закрытых ключей, аутентифицирующих соответствующие открытые ключи. Для создания и администрирования хранилища используется утилита keytool.

Файл jar с цифровой подписью включает копию сертификата от хранилища для открытого ключа, соответствующего закрытому ключу, используемому для подписи файла. Утилита jarsigner проверяет цифровую подпись файла jar, используя размещенный внутри файла сертификат.

Команда подписи файла jar

При подписи файла утилите jarsigner в качестве опций необходимо указать хранилище ключей и сертификатов -keystore, пароль хранилища -storepass и пароль закрытого ключа -keypass, файл jar и псевдоним сертификата. Следующая команда сформирует цифровую подпись файла certificate-reader.jar и разместит ее внутри архива :

>»C:/Program Files/Java/jdk1.8.0_161/bin/»jarsigner.exe -verbose -keystore keystore.jks -storepass mystorepass -keypass mykeypass certificate-reader.jar codesigner Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) updating: META-INF/MANIFEST.MF adding: META-INF/CODESIGN.SF adding: META-INF/CODESIGN.RSA adding: com/ adding: com/labir/ signing: com/labir/CertificateReader$1.class signing: com/labir/CertificateReader$2.class signing: com/labir/CertificateReader.class jar signed. Warning: No -tsa or -tsacert is provided and this jar is not timestamped.

Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2019-04-16) or after any future revocation date.

При формировании цифровой подписи jarsigner вывел в консоль дополнительную информацию, связанную с указанием внесения изменений в файл META-INF/MANIFEST.MF и добавлением двух файлов (META-INF/CODESIGN.SF, META-INF/CODESIGN.RSA). Далее приводятся наименования файлов (классов), для которых сформированы подписи. Обратите внимание, что алиас сертификата ‘codesigner’ в наименованиях добавленных файлов сокращен до восьми символов CODESIGN.

MANIFEST.MF после подписи

После подписи jar файла содержимое манифеста изменилось добавлением 3-х дайджестов :

Manifest-Version: 1.0 Class-Path: . Main-Class: com.labir.CertificateReader Name: com/labir/CertificateReader$2.class SHA-256-Digest: dMd0CV9qRF4KUznsnNFo1slW0g6U1zwRn3jM4PVjjw8= Name: com/labir/CertificateReader$1.class SHA-256-Digest: UhMt98YW190OqDiV1NExH4eCMZtzto0vjzEnPpME9rg= Name: com/labir/CertificateReader.class SHA-256-Digest: jtwnwiYnLa+qY3F2N5105qa+oWM/FNonBtBQtal+tx8=

CODESIGN.SF

Файл CODESIGN.SF содержит дайджесты манифеста и файлов архива jar.

Signature-Version: 1.0 SHA-256-Digest-Manifest-Main-Attributes: QjbCmYJbFmnmqyFWabrHW2Jd7kwYt GnzIHhXpBF4UWM= SHA-256-Digest-Manifest: AfgfUrLzD7tMXju3Io/DU0iTeRMoCgybFeV/J4fVGO0= Created-By: 1.8.0_161 (Oracle Corporation) Name: com/labir/CertificateReader$2.class SHA-256-Digest: neEYk0uhwtFOKOk/Vr3pGBDnzGn0qahBg8TupL4M7tI= Name: com/labir/CertificateReader$1.class SHA-256-Digest: BqfYq26UnpZjz9thlc+oDbuijR35VSiwnbnlVl+z/qM= Name: com/labir/CertificateReader.class SHA-256-Digest: C4vnZjuC2OYkg7qMAPjoMhdsLZJDq6YyHvrqHWWjThA=

CODESIGN.RSA

Файл CODESIGN.RSA содержит цифровой сертификат RSA, используемый в криптографии с открытым ключом.

Проверка подписи файла с использованием jarsigner

Чтобы выполнить проверку цифровой подписи jar файла с помощью утилиты jarsigner необходимо использовать опцию -verify. Следующая команда демонстрирует проверку «действительной» подписи файла certificate-reader.jar.

> «C:/Program Files/Java/jdk1.8.0_161/bin/»jarsigner.exe -verify -verbose -certs certificate-reader.jar Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) s 400 Mon Apr 16 12:00:56 MSK 2018 META-INF/MANIFEST.MF X.509, CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [certificate is valid from 16.04.18 12:00 to 16.04.19 12:00] [CertPath not validated: Path does not chain with any of the trust anchors] 550 Mon Apr 16 12:00:56 MSK 2018 META-INF/CODESIGN.SF 1352 Mon Apr 16 12:00:56 MSK 2018 META-INF/CODESIGN.RSA 0 Mon Apr 16 11:07:32 MSK 2018 com/ 0 Mon Apr 16 11:07:32 MSK 2018 com/labir/ sm 765 Mon Apr 16 11:08:38 MSK 2018 com/labir/CertificateReader$1.class X.509, CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [certificate is valid from 16.04.18 12:00 to 16.04.19 12:00] [CertPath not validated: Path does not chain with any of the trust anchors] sm 1424 Mon Apr 16 11:08:38 MSK 2018 com/labir/CertificateReader$2.class X.509, CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [certificate is valid from 16.04.18 12:00 to 16.04.19 12:00] [CertPath not validated: Path does not chain with any of the trust anchors] sm 8177 Mon Apr 16 11:08:38 MSK 2018 com/labir/CertificateReader.class X.509, CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [certificate is valid from 16.04.18 12:00 to 16.04.19 12:00] [CertPath not validated: Path does not chain with any of the trust anchors] s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope — Signed by «CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF» Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 2048-bit key jar verified. Warning: This jar contains entries whose certificate chain is not validated. This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate’s expiration date (2019-04-16) or after any future revocation date.

Программная проверка подписи

Выполним проверку цифровой подписи файла программным способом. Для этого необходимо только прочитать файлы архива jar. Если один из файлов будет изменен и его подпись будет недействительной, то чтение завершится вызовом исключения SecurityException.

Следующий пример демонстрирует проверку подписанного файла.

import java.io.IOException; import java.io.InputStream; import java.util.Enumeration; import java.util.jar.JarEntry; import java.util.jar.JarFile; public class SignVerify < private final String jar_path = «D:/certificate-reader.jar»; SignVerify () < try < JarFile jfile = new JarFile(jar_path); System.out.println(«verify = » + jarVerify(jfile)); >catch (IOException e) <> > private static boolean jarVerify(JarFile jar) throws IOException < Enumerationentries = jar.entries(); while (entries.hasMoreElements()) < JarEntry entry = entries.nextElement(); System.out.println(«entry.name = » + entry.getName()); try < byte[] buffer = new byte[16384]; InputStream is = jar.getInputStream(entry); while ((is.read(buffer,0,buffer.length)) != -1)< // Только чтение, которое может вызвать // SecurityException, если цифровая подпись // нарушена. >> catch (SecurityException se) < System.err.println(«SecurityException : » + se.getMessage()); return false; >> return true; > public static void main(String[] args) throws IOException < new SignVerify(); System.exit(0); >>

При чтении архивного файла в консоль выведена следующая информация :

entry.name = com/ entry.name = com/labir/ entry.name = com/labir/CertificateReader$1.class entry.name = com/labir/CertificateReader$2.class entry.name = com/labir/CertificateReader.class entry.name = META-INF/CODESIGN.RSA entry.name = META-INF/CODESIGN.SF entry.name = META-INF/MANIFEST.MF verify = true

Если подпись файла окажется недействительной, то в консоли будет выведено сообщение об ошибке. Чтобы убедиться в этом достаточно внести изменение в один из дайджестов манифеста и снова запустить пример.

В примере можно организовать дополнительную проверку, связанную, например, с сертификатом (файлом .RSA). Здесь все зависит от Вашего опыта и желания блокировать выполнение измененного приложения/библиотеки.

Скачать пример

Исходный код рассмотренного на странице примера подписи jar файла с использованием утилиты jarsigner в виде проекта IDE Eclipse можно скачать здесь (21.2 Kб).

Источник: java-online.ru

Обзор подписывания кода

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

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

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

Преимущества подписания кода

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

Например, предположите, что пользователь дает разрешение приложения SurfWriter получать доступ к элементу цепочки для ключей. Каждый раз, когда SurfWriter пытается получить доступ к тому элементу, система должна определить, является ли это действительно тем же приложением, запрашивающим доступ. Если приложение подписывается, система может идентифицировать приложение с уверенностью. Если разработчик обновляет приложение и подписывает новую версию с тем же уникальным идентификатором, система распознает обновление как то же приложение и предоставляет ему доступ, не запрашивая проверку от пользователя. С другой стороны, если SurfWriter повреждается или взламывается, подпись больше не соответствует предыдущую подпись; система обнаруживает изменение и отказывает в доступе к элементу цепочки для ключей.

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

Все виды кода могут быть подписаны, включая инструменты, приложения, сценарии, библиотеки, плагины и другие «подобные коду» данные.

Подписывание кода имеет три отличных цели. Это может привыкнуть к:

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

Чтобы позволить подписанному коду выполнить эти цели, подпись кода состоит из трех частей:

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

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

Чтобы узнать больше, как подпись кода используется для определения степени доверия кода со знаком в определенной цели, посмотрите Требования Кода .

Обратите внимание на то, что подписывание кода имеет дело прежде всего с рабочим кодом. Несмотря на то, что это может использоваться для обеспечения целостности сохраненного кода (на диске, например), это — вторичное использование.

Для осознавания использования подписывания кода необходимо знать о некоторых вещах, которые не может сделать подписание:

Это не может гарантировать, что часть кода свободна от уязвимостей системы обеспечения безопасности.
Это не может гарантировать, что приложение не загрузит небезопасный или измененный код — такой как недоверяемые плагины — во время выполнения.
Это не технология управления цифровыми правами (DRM) или защиты от копирования. Несмотря на то, что система могла решить, что копия Вашего приложения не была должным образом подписана Вами, или что его защита от копирования была взломана, таким образом делая подпись недопустимой, нет ничего, чтобы препятствовать тому, чтобы пользователь выполнил приложение так или иначе.

Цифровые подписи и код со знаком

Как объяснено в Обзоре безопасности, цифровая подпись использует шифрование с открытым ключом для обеспечения целостности данных. Как подпись, записанная с чернилами на бумаге, цифровая подпись может использоваться, чтобы идентифицировать и аутентифицировать подписывающее лицо. Однако цифровую подпись более трудно подделать и идет один шаг вперед: это может гарантировать, что не были изменены данные со знаком. Это несколько походит на разработку бумажной проверки или денежного перевода таким способом, которым, если кто-то изменяет записанную сумму денег, водяной знак с «Недопустимым» текстом становится видимым на бумаге.

Требования кода

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

Подписывающее лицо может указать требования при подписании кода; такие требования упоминаются как внутренние требования. Верификатор может считать любые внутренние требования прежде, чем решить, как обработать код со знаком. Однако это до верификатора для решения что требования использовать. Например, Safari мог потребовать, чтобы плагин был подписан Apple, чтобы быть загруженным, независимо от того, включала ли подпись того плагина внутренние требования.

Одна главная цель подписей кода состоит в том, чтобы позволить верификатору идентифицировать код (такой как программа, плагин или сценарий), чтобы определить, является ли это тем же кодом, который верификатор видел прежде. Критерии, используемые для создания этого определения, упоминаются как определяемое требование кода. Например, определяемое требование для Почты Apple могло бы быть, «был подписан Apple, и идентификатор com.apple.Mail «.

Чтобы видеть, как это работает на практике, предположите, что пользователь дал разрешение к Почтовому приложению Apple получать доступ к элементу цепочки для ключей. Цепочка для ключей использует определяемое требование Почты для идентификации его: цепочка для ключей записывает идентификатор ( com.apple.Mail ) и подписывающее лицо приложения (Apple) для идентификации программы позволило получать доступ к элементу цепочки для ключей. Каждый раз, когда Почта пытается получить доступ к этому элементу цепочки для ключей, цепочка для ключей смотрит на подпись Почты, чтобы удостовериться, что программа не была повреждена, что идентификатор com.apple.Mail , и что программа была подписана Apple. Если все проверяет, цепочка для ключей предоставляет Почтовый доступ к элементу цепочки для ключей. Когда Apple выпускает новую версию Почты, новая версия включает подпись, поставленную Apple, идентифицирующим приложение как com.apple.Mail . Поэтому, когда пользователь устанавливает новую версию Почты, и это пытается получить доступ к элементу цепочки для ключей, цепочка для ключей распознает обновленную версию как ту же программу и не предлагает пользователю проверку.

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

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

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

Роль доверия подписыванию кода

Доверие определяется политикой. Политика доверия безопасности определяет, должны ли определенные идентификационные данные быть приняты для разрешения чего-то, такого как доступ к ресурсу или службе. Различные части OS X имеют различные политики и делают это определение по-другому. Например, специализированное клиентское приложение могло бы включать ряд корневых сертификатов, которым это доверяет при передаче с определенным набором серверов. Если бы к тем тем же серверам получили доступ с помощью веб-браузера, Однако этим корневым сертификатам не доверяли бы.

Почти таким же способом много частей OS X (цепочка для ключей OS X и родительский контроль, например) не заботятся о том, какой объект подписал приложение; они заботятся только, изменилось ли подписывающее лицо с прошлого раза была проверена подпись. Они используют определяемое требование подписи кода с этой целью.

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

Можно изменить полицейских подписывания кода OS X с spctl(8) команда.

Источник: spec-zone.ru

Подпись кода

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

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

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

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

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

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

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

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

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

Подписание кода расширенной проверки (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 как организацию. Подписание кода показано как единственное использование расширенного ключа 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.

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

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

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

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

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

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

Подпись кода в Xcode

Разработчикам необходимо подписать свои приложения для 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 это установлено так, что исполняемый файл будет загружаться только с заводских дисков, поэтому простого копирования исполняемого файла на записываемый носитель достаточно, чтобы остановить выполнение программного обеспечения.

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

См. Также

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

Ссылки

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

Руководство по подписанию кода Apple
Введение Microsoft в подписание кода
Инфраструктура безопасности Debian
Strong Distribution HOWTO

Источник: alphapedia.ru