Цифровые подписи на Java –

Введение

Кто из нас не посещал ebay, amazon, чтобы купить что-нибудь, или его личный банковский счет, чтобы проверить это. Считаете ли вы, что эти сайты достаточно безопасны для размещения ваших личных данных, таких как (номер кредитной карты или номер банковского счета и т. Д.)?

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

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

Введение

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

SSL обеспечивает безопасный канал между двумя устройствами, работающими по сетевому соединению. Одним из обычных примеров SSL является обеспечение безопасной связи между веб-браузерами и веб-серверами.

Обзор

В этом уроке мы узнаем о механизме цифровой подписи и о том, как мы можем реализовать его с помощьюАрхитектуры криптографии Java (JCA) . Мы рассмотрим пару ключей , Дайджест сообщений, Шифр, хранилище ключей, сертификат, и Подпись API JCA.

Мы начнем с понимания того, что такое цифровая подпись, как создать пару ключей и как сертифицировать открытый ключ в центре сертификации (ЦС). После этого мы рассмотрим, как реализовать цифровую подпись с использованием низкоуровневых и высокоуровневых API JCA.

. Безопасность За пределами Ядра Java

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

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

И, на платформе Java – обычно это означает Spring Security . Фреймворк является частью экосистемы Spring, но на самом деле его можно использовать вне приложения pure Spring.

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

Конечно, Spring Security подробно освещается в серии учебных пособий , а также в руководстве по курсу Learn Spring Security .

Загрузка KeyStore

Java хранит доверенные сертификаты в специальном файле под названием cacerts которая живет в нашей папке установки Java.

Начнем с чтения этого файла и загрузки его в KeyStore:

Пароль по умолчанию для этого KeyStore есть “changeit” , но это может быть по-другому, если он был ранее изменен в нашей системе.

После загрузки KeyStore будет держать наши доверенные сертификаты, а затем, мы увидим, как их читать.

Особенности языка

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

• Статическая типизация данных: Java-это статически типизированный язык, который уменьшает возможности обнаружения ошибок, связанных с типом, во время выполнения
• Модификаторы доступа: Java позволяет нам использовать различные модификаторы доступа, такие как public и private, для управления доступом к полям, методам и классам
• Автоматическое управление памятью: Java имеет управление памятью на основе сбора мусора , что освобождает разработчиков от управления этим вручную
• Проверка байт-кода: Java является скомпилированным языком, что означает, что он преобразует код в байт-код, не зависящий от платформы, и среда выполнения проверяет каждый байт-код, загружаемый для выполнения

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

1. Определение Цифровой Подписи

Цифровая подпись-это метод обеспечения:

• Целостность: сообщение не было изменено при передаче
• Подлинность: автор сообщения действительно тот, за кого они себя выдают
• Неотрицание: автор сообщения не может позже отрицать, что они были источником

2. Отправка Сообщения с цифровой подписью

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

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

3. Получение и проверка Цифровой подписи

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

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

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

API JSSE

API безопасности Java широко используют шаблон Factory design.

На самом деле все создается с помощью фабрики в JSSE.

Архитектура безопасности в Java

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

Основные принципы безопасности в Java определяются совместимыми и расширяемымипровайдерамиреализациями . Конкретная реализация Провайдера может реализовывать некоторые или все службы безопасности.

Например, некоторые из типичных услуг, которые может реализовать Поставщик , являются:

• Криптографические алгоритмы (такие как DSA, RSA или SHA-256)
• Средства генерации, преобразования и управления ключами (например, для ключей, специфичных для алгоритма)

Java поставляется с многими встроенными поставщиками . Кроме того, приложение может настроить несколько поставщиков в порядке предпочтения.

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

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

Сертификаты чтения из указанного KeyStore

Мы будем использовать PKIXПараметерс класс, который занимает KeyStore в качестве параметра конструктора:

PKIXПараметерс класс обычно используется для проверки сертификата, но в нашем примере мы просто использовали его для получения сертификатов от наших KeyStore .

При создании экземпляра PKIXПараметы , он строит список ТрастАнчор которые будут содержать доверенные сертификаты, присутствующие в нашем KeyStore .

ТрастАнчор экземпляр просто представляет собой доверенный сертификат.

Цифровой сертификат и идентификатор открытого ключа

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

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

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

X. 509 является наиболее используемым форматом сертификата, и он поставляется либо в двоичном формате (DER), либо в текстовом формате (PEM). JCA уже предоставляет реализацию для этого через класс X509Certificate .

Частные ключи

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

1. SSLSocketFactory

javax.net.ssl.SSLSocketFactory используется для создания объектов SSLSocket .

Этот класс содержит три группы API.

Первая группа состоит из одного статического метода getDefault () , используемого для извлечения экземпляра по умолчанию, который, в свою очередь, может создавать экземпляры SSLSocket .

Вторая группа состоит из пяти методов, которые можно использовать для создания экземпляров SSLSocket :

• Сокет createSocket(String host, int-порт)
• Сокет createSocket(String host, int port, InetAddress clientHost, int clientPort)
• Сокет createSocket(хост InetAddress, порт int)
• Сокет createSocket(InetAddress host, int port, InetAddress clientHost, int clientPort)
• Socket createSocket(сокет, строковый хост, порт int, логическая автоклюзия)

Мы можем использовать этот класс напрямую, получив экземпляр по умолчанию или используя объект javax.net.ssl. SSLContext, который содержит методы для получения экземпляра SSLSocketFactory .

2. SSLSocket

Этот класс расширяет класс Socket и обеспечивает безопасный сокет. Такие сокеты являются обычными потоковыми сокетами.

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

Экземпляры SSLSocket создают SSL-соединение с именованным хостом на указанном порту.

Это позволяет привязать клиентскую сторону соединения к заданному адресу и порту.

3. SSLServerSocket Factory

Класс SSLServerSocketFactory очень похож на SSLSocketFactory с той разницей, что он создает экземпляры SSLServerSocket вместо экземпляров SSLSocket .

По сходству методы называются createServerSocket аналогично классу SSLSocketFactory .

4. SSLServerSocket

Класс SSLServerSocket аналогичен классу SSLSocket . Методы класса SSLServerSocket являются подмножеством методов класса SSLSocket . Они действуют на противоположной стороне SSL-соединения

Криптография

Криптография является краеугольным камнем функций безопасности в целом и в Java. Это относится к инструментам и методам безопасной связи в присутствии противников .

Пример SSL

Давайте приведем пример того, как мы можем создать защищенное соединение с сервером:

В случае, если мы получим ошибку “javax.net.ssl.SSLHandshakeException: sun.security.validator.Исключение ValidatorException: ошибка построения пути PKIX: sun.security.provider.certpath.Исключение SunCertPathBuilderException: не удается найти допустимый путь сертификации к запрошенному целевому объекту при установлении SSL-соединения” , это указывает на то, что у нас нет открытого сертификата сервера, который мы пытаемся подключить в хранилище доверия Java.

Хранилище доверия-это файл, содержащий доверенные сертификаты, которые Java использует для проверки защищенных соединений.

Чтобы решить эту проблему, у нас есть несколько вариантов:

• добавьте открытый сертификат сервера в файл по умолчанию cacertstruststore , используемый Java. при инициировании SSL-соединения
• Установите javax.net.ssl.trustStore переменная среды, указывающая на файл truststore, чтобы приложение могло получить этот файл, содержащий открытый сертификат сервера, к которому мы подключаемся.

Шаги по установке нового сертификата в хранилище доверия Java по умолчанию следующие:

Управление парами клавиш

Поскольку цифровая подпись использует закрытый и открытый ключи, мы будем использовать классы JCA PrivateKey и PublicKey для подписи и проверки сообщения соответственно.

Чтение сертификатов от KeyStore по умолчанию

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

Если мы не предоставим KeyStore очевидно, что тот же самый из предыдущей главы будет использоваться по умолчанию:

В приведеном выше примере мы использовали X509ТрустМенагер , который является специализированным ТрастМенагер используется для аутентификация удаленной части системы соединения SSL .

Обратите внимание, что такое поведение может зависеть от конкретной реализации JDK, спецификация не определяет, что должно произойти в случае init ()KeyStore параметр нулевой .

1. Криптография Java

Архитектура криптографии Java (JCA) предоставляет платформу для доступа и реализации криптографических функций в Java, включая:

• Цифровые подписи
• Дайджесты сообщений
• Симметричные и асимметричные шифры
• Коды аутентификации сообщений
• Генераторы ключей и ключевые фабрики

Самое главное, что Java использует реализации Provider на основе для криптографических функций.

Кроме того, Java включает в себя встроенные поставщики для часто используемых криптографических алгоритмов, таких как RSA, DSA и AES, и это лишь некоторые из них. Мы можем использовать эти алгоритмы для обеспечения безопасности данных в состоянии покоя, в использовании или в движении.

2. Загрузка закрытого ключа для подписи

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

Использование хранилища ключей API и предыдущий файл хранилища ключей, sender_keystore.p12, мы можем получить объект PrivateKey :

2. Криптография на практике

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

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

Итак, давайте посмотрим, как мы можем сделать это на Java:

Здесь Дайджест сообщений – это криптографический сервис, который нас интересует. Мы используем методgetInstance(), чтобы запросить эту услугу у любого из доступных поставщиков безопасности .

4. Загрузка открытого ключа для проверки

Имея доступ к открытому ключу, получатель может загрузить его в свое хранилище ключей с помощью команды importcert :

И используя Хранилище ключей API, как и раньше, мы можем получить Открытый ключ экземпляр:

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

Инфраструктура Открытых Ключей

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

Корневые сертификаты

Корневой сертификат CA — это сертификат CA, который представляет собой самозаверяющий сертификат. Этот сертификат представляет объект, который выдает сертификат и известен как Центр сертификации или CA, такой как VeriSign, Thawte и т. Д.

Цифровая подпись С Дайджестом сообщений и Классами Шифров

Как мы уже видели, цифровая подпись основана на хэшировании и шифровании.

Обычно мы используем класс MessageDigest с SHA или MD5 для хэширования и класс Cipher для шифрования.

Теперь давайте начнем внедрять механизмы цифровой подписи.

1. Генерация хэша сообщения

Сообщение может быть строкой, файлом или любыми другими данными. Итак, давайте возьмем содержимое простого файла:

Теперь, используя Дайджест сообщений, давайте использовать метод digest для генерации хэша:

Здесь мы использовали алгоритм SHA-256, который является наиболее часто используемым. Другие альтернативы-MD5, SHA-384 и SHA-512.

2. Инструменты Java для PKI

В Java есть несколько действительно удобных инструментов для облегчения доверенного общения:

• Существует встроенный инструмент под названием “keytool” для создания и управления хранилищем ключей и хранилищем доверия
• Существует также еще один инструмент “jarsigner”, который мы можем использовать для подписи и проверки файлов JAR

Аутентификация

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

Центры сертификации

Компании, которые будут подписывать сертификаты для вас, такие как VeriSign, Thawte, Commodo, GetTrust. Кроме того, многие компании и учреждения действуют как свои собственные CA, либо создавая полную реализацию с нуля, либо используя опцию с открытым исходным кодом, такую ​​как OpenSSL.

Цифровая подпись С использованием класса подписи

До сих пор мы использовали низкоуровневые API для создания вашего собственного процесса проверки цифровой подписи. Это помогает нам понять, как он работает, и позволяет нам настроить его.

Однако JCA уже предлагает выделенный API в виде класса Signature .

1. Аутентификация на Java

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

В то время как несколько поставщиков предоставляют свои модули входа в систему, Java имеет некоторые доступные по умолчанию для использования:

• Krb5LoginModule , для проверки подлинности на основе Kerberos
• JndiLoginModule , для аутентификации на основе имени пользователя и пароля, поддерживаемой хранилищем LDAP
• KeyStoreLoginModule , для аутентификации на основе криптографического ключа

1. Подписание сообщения

Чтобы начать процесс подписания, мы сначала создаем экземпляр класса Signature . Для этого нам нужен алгоритм подписи. Затем мы инициализируем Подпись с помощью нашего закрытого ключа:

Алгоритм подписи, который мы выбрали, SHA256withRSA в этом примере , представляет собой комбинацию алгоритма хеширования и алгоритма шифрования. Другие альтернативы включают, в частности, SHA1withRSA , SHA1withDSA и MD5withRSA .

Далее мы приступаем к подписанию массива байтов сообщения:

Мы можем сохранить подпись в файл для последующей передачи:

2. Вход в систему по примеру

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

Этот модуль отвечает за получение имени пользователя и пароля от пользователя и проверку его с помощью службы каталогов, настроенной в JNDI:

Здесь мы используем экземплярLoginContextдля выполнения входа в систему . LoginContext принимает имя записи в конфигурации входа в систему — в данном случае это “Образец”. Кроме того, мы должны предоставить экземпляр CallbackHandler , используя модуль Login , который взаимодействует с пользователем для получения таких сведений, как имя пользователя и пароль.

Давайте взглянем на нашу конфигурацию входа в систему:

Достаточно просто, это предполагает, что мы используем JndiLoginModule в качестве обязательного Модуля входа в систему .

2. Проверка подписи

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

Затем мы инициализируем объект Signature для проверки, вызывая метод initVerify , который принимает открытый ключ:

Затем нам нужно добавить полученные байты сообщений в объект подписи, вызвав метод update :

И, наконец, мы можем проверить подпись, вызвав метод verify :

Безопасная Связь

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

Цепочка сертификатов

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

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

1. Поддержка Java для безопасной связи

Java предоставляет API для защиты сетевой связи с шифрованием, целостностью сообщений и аутентификацией как клиента, так и сервера :

• SSL/TLS: SSL и его преемник, TLS, обеспечивают безопасность ненадежной сетевой связи с помощью шифрования данных и инфраструктуры открытых ключей. Java обеспечивает поддержку SSL/TLS через SSLSocket , определенный в пакете ” java.security.ssl “.
• SASL: Уровень простой аутентификации и безопасности (SASL) является стандартом для аутентификации между клиентом и сервером. Java поддерживает SASL как часть пакета ” java.security.sasl “.
• GGS-API/Kerberos: Универсальный API службы безопасности (GSS-API) обеспечивает единый доступ к службам безопасности через различные механизмы безопасности, такие как Kerberos v5. Java поддерживает GSS-API как часть пакета ” java.security.jgss “.

Контроль Доступа

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

1. Управление доступом на Java

Мы можем добиться контроля доступа в Javaс помощью классовПолитикииразрешений, опосредованных черезSecurityManagerкласс . Менеджер безопасности является частью пакета ” java.lang ” и отвечает за обеспечение проверки контроля доступа в Java.

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

Во время выполнения кода, если среда выполнения обнаруживает запрос на защищенный ресурс, Менеджер безопасностипроверяет запрошенноеРазрешениена соответствие установленнойПолитике через стек вызовов. Следовательно, он либо предоставляет разрешение, либо выдает SecurityException .

2. Инструменты Java для политики

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

Java поставляется с “инструментом политики”, графической утилитой для создания файлов политики.

3. Контроль Доступа С Помощью Примера

Давайте посмотрим, как мы можем ограничить доступ к ресурсу, такому как файл в Java:

Здесь мы используем Security Manager для проверки нашего запроса на чтение файла, завернутого в FilePermission .

Но/| Менеджер безопасности делегирует этот запрос Контроллеру доступа . Контроллер доступа внутренне использует установленную Политику для принятия решения.

Давайте рассмотрим пример файла политики:

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

Стоит отметить, что Security Manager может не быть установлен по умолчанию в Java. Мы можем гарантировать это, всегда начиная Java с параметра:

XML-подпись

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

Команды хранилища ключей

Создание хранилища ключей, ключей и запросов сертификатов

Импортные сертификаты

Экспортные сертификаты

Проверить / Список / Просмотр сертификатов

Удалить сертификаты

Изменить пароли

1. XML-подпись в Java

Java API поддерживает создание и проверку XML-подписей в соответствии с рекомендуемыми рекомендациями. API цифровой подписи Java XML инкапсулирован в пакет ” javax.xml.crypto “.

Сама подпись-это просто XML-документ. XML-подписи могут быть трех типов:

• Отсоединенный: Этот тип подписи находится поверх данных, которые являются внешними по отношению к элементу подписи.
• Охват: Этот тип подписи находится поверх данных, которые являются внутренними для элемента подписи.
• Заключенный: Этот тип подписи находится над данными, содержащими сам элемент подписи.

Конечно, Java поддерживает создание и проверку всех вышеперечисленных типов XML-подписей.

2. Создание XML-подписи

Теперь мы закатаем рукава и сгенерируем XML-подпись для наших данных. Например, мы можем отправить XML-документ по сети. Следовательно, мы хотели бы, чтобы ваш получатель мог проверить его целостность .

Итак, давайте посмотрим, как мы можем достичь этого в Java:

Чтобы уточнить, мы генерируем XML-подпись для наших данных, присутствующих в файле “data.xml”. Между тем, есть несколько вещей, которые следует отметить в этом фрагменте кода:

• Во-первых, XMLSignatureFactory является заводским классом для создания XML-подписей
• XML-подпись требует SignedInfo объекта, над которым он вычисляет подпись
• XML-подпись также нуждается в KeyInfo , которая инкапсулирует ключ подписи и сертификат
• Наконец, XML-подпись подписывает документ, используя закрытый ключ, инкапсулированный как DOMSignContext

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

Codesign.sf

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

Manifest.mf после подписи

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

Как правильно проверить эп в java?

CMSSignedData pkcs7 = new CMSSignedData(bytesArray)

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

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

При формировании цифровой подписи jarsigner вывел в консоль дополнительную информацию, связанную
с указанием внесения изменений в файл META-INF/MANIFEST.MF и добавлением двух файлов (META-INF/CODESIGN.SF,
META-INF/CODESIGN.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 2021 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 2021 META-INF/CODESIGN.SF
        1352 Mon Apr 16 12:00:56 MSK 2021 META-INF/CODESIGN.RSA
           0 Mon Apr 16 11:07:32 MSK 2021 com/
           0 Mon Apr 16 11:07:32 MSK 2021 com/labir/

sm      765 Mon Apr 16 11:08:38 MSK 2021 
                       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 2021 
                        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 2021 
                        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 (2021-04-16) or 
after any future revocation date.
   

В случае, если цифровая подпись окажется «недействительной», то можно увидеть следующее
сообщение :

Проверка «недействительной» подписи заканчивается вызовом исключения типа SecurityException.

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

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

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

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

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

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

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

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

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

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

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

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

Файл manifest.mf до подписи

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

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

Заключение

В этой статье мы впервые рассмотрели, как работает цифровая подпись и как установить доверие к цифровому сертификату. Затем мы реализовали цифровую подпись, используя классы Message Digest, | Cipher, и Signature из архитектуры криптографии Java.

Мы подробно рассмотрели, как подписывать данные с помощью закрытого ключа и как проверить подпись с помощью открытого ключа.

Как всегда, код из этой статьи доступен на GitHub .

. Заключение

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

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

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

Заключение

В этой статье мы представили SSL и API JSSE, который реализует SSL для Java. Используя SSL и JSSE, мы можем сделать ваши Java-приложения и связь между приложениями и внутри приложения более безопасными.

Как всегда, код, представленный в этой статье, доступен на Github .