Java security signatureexception invalid file sign как исправить

Security is already a tough topic, but I’m disappointed to see the most popular solution is to delete the security signatures. JCE requires these signatures. Maven shade explodes the BouncyCastle jar file which puts the signatures into META-INF, but the BouncyCastle signatures aren’t valid for a new, uber-jar (only for the BC jar), and that’s what causes the Invalid signature error in this thread.

Yes, excluding or deleting the signatures as suggested by @ruhsuzbaykus does indeed make the original error go away, but it can also lead to new, cryptic errors:

java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available

By explicitly specifying where to find the algorithm like this:

SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");

I was able to get a different error:

java.security.NoSuchProviderException: JCE cannot authenticate the provider BC

JCE can’t authenticate the provider because we’ve deleted the cryptographic signatures by following the suggestion elsewhere in this same thread.

The solution I found was the executable packer plugin that uses a jar-in-jar approach to preserve the BouncyCastle signature in a single, executable jar.

UPDATE:

Another way to do this (the correct way?) is to use Maven Jar signer. This allows you to keep using Maven shade without getting security errors. HOWEVER, you must have a code signing certificate (Oracle suggests searching for «Java Code Signing Certificate»). The POM config looks like this:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>org.bouncycastle:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>your.class.here</mainClass>
                    </transformer>
                </transformers>
                <shadedArtifactAttached>true</shadedArtifactAttached>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>sign</id>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>/path/to/myKeystore</keystore>
        <alias>myfirstkey</alias>
        <storepass>111111</storepass>
        <keypass>111111</keypass>
    </configuration>
</plugin>

No, there’s no way to get JCE to recognize a self-signed cert, so if you need to preserve the BouncyCastle certs, you have to either use the jar-in-jar plugin or get a JCE cert.

Security is already a tough topic, but I’m disappointed to see the most popular solution is to delete the security signatures. JCE requires these signatures. Maven shade explodes the BouncyCastle jar file which puts the signatures into META-INF, but the BouncyCastle signatures aren’t valid for a new, uber-jar (only for the BC jar), and that’s what causes the Invalid signature error in this thread.

Yes, excluding or deleting the signatures as suggested by @ruhsuzbaykus does indeed make the original error go away, but it can also lead to new, cryptic errors:

java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available

By explicitly specifying where to find the algorithm like this:

SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");

I was able to get a different error:

java.security.NoSuchProviderException: JCE cannot authenticate the provider BC

JCE can’t authenticate the provider because we’ve deleted the cryptographic signatures by following the suggestion elsewhere in this same thread.

The solution I found was the executable packer plugin that uses a jar-in-jar approach to preserve the BouncyCastle signature in a single, executable jar.

UPDATE:

Another way to do this (the correct way?) is to use Maven Jar signer. This allows you to keep using Maven shade without getting security errors. HOWEVER, you must have a code signing certificate (Oracle suggests searching for «Java Code Signing Certificate»). The POM config looks like this:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>org.bouncycastle:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>your.class.here</mainClass>
                    </transformer>
                </transformers>
                <shadedArtifactAttached>true</shadedArtifactAttached>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>sign</id>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>/path/to/myKeystore</keystore>
        <alias>myfirstkey</alias>
        <storepass>111111</storepass>
        <keypass>111111</keypass>
    </configuration>
</plugin>

No, there’s no way to get JCE to recognize a self-signed cert, so if you need to preserve the BouncyCastle certs, you have to either use the jar-in-jar plugin or get a JCE cert.

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

Этот раздел касается:

• Платформы: Все платформы
• Версии Java: 7.0, 8.0

ПРИЗНАКИ

При запуске апплета или приложения Java появляется диалоговое окно с предупреждением системы безопасности:

Заблокировать запуск потенциально небезопасных компонентов?

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

Подписанные приложения и апплеты Java Web Start, содержащие подписанные и неподписанные компоненты, могут быть потенциально небезопасными, если смешанный код не был намеренно использован поставщиком приложения. Начиная с выпуска Java SE 6 Update 19 при работе с программой, которая содержит подписанные и неподписанные компоненты, отображается диалоговое окно с предупреждением.

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

Способ обработки программ со смешанным кодом можно настроить с помощью панели управления Java.

Поиск панели управления Java

Параметры защиты от смешанного кода в панели управления Java

1. В панели управления Java перейдите на вкладку Дополнительно.
2. Разверните параметр Проверка безопасности смешанного кода (Из песочницы — Доверенный) в разделе Безопасность.

Доступны четыре уровня управления.

Включить – отображать предупреждение при необходимости

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

Включить – скрыть предупреждение и выполнять с применением мер защиты

При выборе этого параметра диалоговое окно с предупреждением не отображается. Код выполняется так же, как и при нажатии кнопки Нет в диалоговом окне с предупреждением.

Включить – скрыть предупреждение и не выполнять недоверенный код

При выборе этого параметра диалоговое окно с предупреждением не отображается, а код выполняется так же, как и при нажатии кнопки Да в диалоговом окне с предупреждением.

Отключить проверку

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

When verifying a signature using Signature.verify I receive an «Invalid encoding for signature» exception. When verifying same signature using Azure service, the signature is verified.

I have a hash-data (SHA-256), a public key, and a signature that I’m trying to verify. The signature was received using com.microsoft.azure.keyvault.KeyVaultClient.sign method, with signing algorithm «ES256».

This works (using ES256 algorithm) :

This fails (certificate holds same public key that is stored in Azure keyvault):

Expected result — true (signature is verified)

I get the following exception (I know it is not much to go by) and I would guess it may have to do with how JSch uses BASE64 encoding/decoding. Can someone confirm that the following openjdk behaviour does not affect this library?

From https://bugs.openjdk.java.net/browse/JDK-8174719
( Java8u121: signature.verify throws exception Invalid encoding for signature )

valeriep Valerie Peng added a comment — 2017-02-27 18:05 — edited
Thanks for the clarification.
Based on the provided info, I think the trailing 0s are introduced during the BASE64 encoding process.
The BASE64 decoding process didn’t correctly strip off these trailing 0s.
You should use the «=» pad char or keep track of how long the original byte[] is when doing your BASE64 encoding/decoding.
The byte[] passed into Signature.verify(byte[]) call needs to be exactly the bytes returned by Signature.sign(). It cannot contain any extra bytes. There is no problem with the current implementation. The earlier implementation in JDK 8u112 is incorrect and although we try our best to maintain backward compatibility, we have to fix this to ensure that signature verification is done properly.

This will be closed as «Not an Issue» or «Will Not Fix».

Ошибка при проверке подписи ECDSA в Java с помощью BouncyCastle

Я протестировал решение для проверки подписи ECDSA (Как я могу получить объект PublicKey из байтов открытого ключа EC?), который отлично работает с данными.

И это код (который печатает true):

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

Новые данные выводят эту ошибку:

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

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

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

Может кто-то указать мне, что мне здесь не хватает?

EDIT: решение

Как указал Питер Деттман в своем ответе, signature не был правильно отформатирован (также содержимое было неверным) для вычисления методом verify() . Здесь — хорошее объяснение, в основном говорит, что:

При кодировании в DER эта (подпись) становится следующей последовательностью байтов:

0x30 b1 0x02 b2 (vr) 0x02 b3 (vs)

• b1 — однобайтовое значение, равное длине в байтах оставшегося списка байтов (от первого 0x02 до конца кодирования);
• b2 — однобайтовое значение, равное длине в байтах (vr);
• b3 — однобайтовое значение, равное длине в байтах (vs);
• (vr) — это подписанное кодирование большого числа знака «r» минимальной длины;
• (vs) — это подписанная big-endian кодировка значения s с минимальной длиной.

Применяя это изменение, signature растет до 70 байт, а выполнение не выдает ошибки.

Источник

Ошибка декодирования ECDSA: исключение в потоке «main» java.security.SignatureException: ошибка декодирования байтов подписи

Я пытаюсь проверить подпись ECDSA, используя java, ключ был создан с помощью golang:

подпись происходит здесь: (сообщение было закодировано golang, используя этот метод):

здесь происходит декодирование:

однако, к сожалению, программа не работает по следующим причинам:

Это вызывает интересную дилемму, поскольку Открытый ключ:

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

Ключ был сгенерирован правильно, и ASN.1 Parse правильно его декодирует. Почему Java не нравится мой код?

Кроме того, прошу прощения за плохой отступ.

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

Также очень неудобно печатать по одному байту в строке; рассмотрим Arrays.toString(byte[]) или шестнадцатеричный javax.xml.bind.DatatypeConverter.printHexBinary(byte[]) . И никогда (никогда) не пытайтесь преобразовать произвольные двоичные файлы, такие как криптографические подписи и другие криптообъекты, в Java String напрямую; это отличный способ уничтожить ваши данные. И, наконец, использование ECDSA (P384) с SHA1 фактически отбрасывает большую часть вашей безопасности, но оставьте это для другого стека после того, как ваш код заработает.

Java JCE определенно не ожидает подписи в формате JSON . поэтому json_response.getBytes(«UTF-8») заставляет меня нервничать в вашем вызове обновления.

@ lockcmpxchg8b + Формат JWS для подписи ECDSA — (base64url of) big-endian unsigned r, s фиксированной длины без метаданных, таких как теги, который является форматом, используемым PKCS11 и IINM P1363, и поддерживается Bouncy (но не SunEC) хотя по умолчанию не используется. Но JWA требует, чтобы хэш соответствовал кривой, поэтому ECDSA (P-384) требует SHA-384.

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

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

Источник

Ошибка при проверке подписи ECDSA в Java с помощью BouncyCastle

Я протестировал решение для проверки подписи ECDSA (Как я могу получить объект PublicKey из байтов открытого ключа EC?), который идеально работает с заданными данными.

И это код (который выводит true):

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

Новые данные выводят эту ошибку:

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

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

Последнее, что стоит упомянуть, это то, что в моей документации говорится, что подписи должно предшествовать поле с именем «R», которое «содержит координату x точки эллиптической кривой, полученной в результате умножения элемента генератора на эфемерный закрытый ключ» и его длина должна быть такой же, как у подписи (32 байта).