На чтение 4 мин. Просмотров 46 Опубликовано 15.12.2019
Содержание
- Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
- Поиск панели управления Java
- Параметры защиты от смешанного кода в панели управления Java
Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
Этот раздел касается:
- Платформы: Все платформы
- Версии Java: 7.0, 8.0
ПРИЗНАКИ
При запуске апплета или приложения Java появляется диалоговое окно с предупреждением системы безопасности:
Заблокировать запуск потенциально небезопасных компонентов?
Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности. Свяжитесь с поставщиком приложения и убедитесь в отсутствии попыток несанкционированного доступа.
Подписанные приложения и апплеты Java Web Start, содержащие подписанные и неподписанные компоненты, могут быть потенциально небезопасными, если смешанный код не был намеренно использован поставщиком приложения. Начиная с выпуска Java SE 6 Update 19 при работе с программой, которая содержит подписанные и неподписанные компоненты, отображается диалоговое окно с предупреждением.
Если в диалоговом окне безопасности нажать кнопку Да, запуск потенциально небезопасных компонентов будет заблокирован, после чего возможно завершение работы программы. Если нажать кнопку Нет, выполнение приложения или апплета продолжится.
Предупреждение отображается по умолчанию, но существуют параметры для изменения этой настройки.
Способ обработки программ со смешанным кодом можно настроить с помощью панели управления Java.
Поиск панели управления Java
Параметры защиты от смешанного кода в панели управления Java
- В панели управления Java перейдите на вкладку Дополнительно.
- Разверните параметр Проверка безопасности смешанного кода (Из песочницы — Доверенный) в разделе Безопасность.
Доступны четыре уровня управления.
Включить – отображать предупреждение при необходимости
Это настройка по умолчанию. Когда возникает потенциальный риск для безопасности, отображается диалоговое окно. При нажатии кнопки Да выполнение потенциально небезопасных компонентов блокируется, после чего возможно завершение работы программы. Если нажата кнопка Нет, выполнение приложения или апплета продолжится с применением необходимых мер защиты (обнаруженные позднее пакеты или ресурсы с одинаковыми именами, но разными уровнями доверия, например, подписанные или неподписанные, не будут загружены).
Включить – скрыть предупреждение и выполнять с применением мер защиты
При выборе этого параметра диалоговое окно с предупреждением не отображается. Код выполняется так же, как и при нажатии кнопки Нет в диалоговом окне с предупреждением.
Включить – скрыть предупреждение и не выполнять недоверенный код
При выборе этого параметра диалоговое окно с предупреждением не отображается, а код выполняется так же, как и при нажатии кнопки Да в диалоговом окне с предупреждением.
Отключить проверку
Использовать этот параметр не рекомендуется. Этот параметр полностью отключает проверку смешанного доверенного и недоверенного кода, допуская выполнение потенциально небезопасного кода без применения мер защиты.
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».
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.
ВОПРОС ПО МАЙНКРАФТУ
Профи
(617),
на голосовании
6 лет назад
Дополнен 6 лет назад
После java.net.ConnectException:Conection Resfused: connect пишет Обновлениее серверов
Дополнен 6 лет назад
Ошибочка
Голосование за лучший ответ
A tales of small KIDZ
Мастер
(1215)
6 лет назад
Ты готов заплатить 100 рублей, какому-то чуваку, за то, что он просто покажет тебе, как починить лаунчер?
Cergius KlimkovichПрофи (617)
6 лет назад
Послушай мою ситуацию, я играю с друзьями в кс, майн и много других игр, и я не могу зайти на тот сервак. знаешь как обидно когда они там ржут, веселятся, а я сижу в одиночестве и не могу зайти? Да я готов заплатить 100 рублей, я много искал в интернете, прежде чем написать этот вопрос.
Ярослав Падусенко
Ученик
(112)
6 лет назад
у меня тоже такое было только с Т-лаунчером. Я помню что просто переустанавливал лаунчер и пробовал установить более старые версии джавы (если была самая новая), и вроде помогло! пеййер: Р61411560
Содержание
- File signature verification failed Serious Sam 4 – как исправить
- Причины ошибки верификации
- Как решить проблему
- Нехватка оперативной памяти
- Invalid File Signature Error #6
- Comments
- Invalid File Signature Error when submitting an image to the eyes service.
- Log Output
- Error Message
- Footer
- excelReader.Error : Invalid file signature in xls..but reads same in xlsx file #83
- Comments
- Builds broken because package signature file entry is invalid #2523
- Comments
- java security signatureexception invalid file sign
- Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
- Поиск панели управления Java
- Параметры защиты от смешанного кода в панели управления Java
File signature verification failed Serious Sam 4 – как исправить
Многие пользователи после запуска четвертой части Serious Sam 4 получают ошибку с сообщением: «File signature verification failed (Content/SeriousSam4/00_All.gro).» Сегодня в статье попробуем разобраться в чём причина бага и дадим полезные рекомендации по исправлению. В первую очередь отметим, что краши и вылеты наблюдаются у пользователей операционных систем Windows 7, 8 и Виста, что можно попробовать сделать в этом случае напишем ниже.
Пример скрина с ошибкой
Причины ошибки верификации
File signature verification failed – означает ошибку проверки подписи файла. Если вы скачивали игру через официальный лаунчер(Эпик геймс или Стим) то возможно игра не докачала нужные компоненты или последнее обновление. Дополнительно можно сверить целостность компонентов, об этом мы расскажем ниже.
Однако, если вы скачали пиратскую сборку – её могли взломать, что и вызвало сбой при проверке. В этом случае мы рекомендуем просто поискать рабочую сборку на другом сайте.
Как решить проблему
Самое первое, что нужно проверить – есть ли свежая версия драйверов под вашу видеокарту. Две крупнейшие компании AMD и Nvidia регулярно обновляют драйвера для всех своих графических чипов. Естественно на новые модели драйвера выходят чаще. По официальным данным минимальные требования для видеокарты: NVIDIA GTX 780 или AMD Radeon R9 280.
Всем, кто приобретал и устанавливал Сэма через площадку Steam, поможет следующая пошаговая инструкция:
- Откройте Стим и перейдите в Библиотеку с установленными играми.
- Далее ищем в списке Serious Sam 4, нажимаем правой кнопкой мыши и выбираем Свойства.
- Затем переключаемся на вкладку Локальные файлы и нажимаем «Проверить целостность файлов игры».
- Если вы уже делали это, тогда рекомендуем переустановить игрушку. В свойствах выбираем «Удалить».
- Затем идем на жесткий диск, где установлен Стим. Переходим в раздел SteamLibrary, далее в steamapps и common. Тут удаляем папку Serious Sam 4.
- Устанавливаем Сэма в библиотеке по новой и пробуем запустить.
Стоит отметить, что наибольшее количество вылетов и крашей было замечено у пользователей с ОС Windows 7,8 и Vista при прохождении Главы 00 и следующих за ней. По заверениям разработчиков официальной поддержки этих систем в последней версии видеоигры нет. В этом случае можно попробовать запустить .exe ярлык из корневой папки. По клику правой кнопкой мыши по ярлыку выбирайте «Запустить от имени администратора». Так же рекомендуем выставить выставить API Vulkan в настройках графики или наоборот переключится на DirectX.
Мы рекомендуем обновиться до 10й версии Виндовс 64 разрядности. Разработка новых программ, игрушек и софта в первую очередь ведется и тестируются под свежую версию операционной системы. Плюс на неё регулярно выходят апдейты, где устраняются проблемы с совместимостью. Для системы Windows 10 необходимо зайти в центр обновления и проверить установлено ли накопительное обновление за сентябрь и октябрь 2020.
Нехватка оперативной памяти
В некоторых случаях из-за загрузки оперативной памяти вас тоже может выкинуть при прохождении. Если на вашем компьютере установлено меньше 4гб оперативной памяти исправить зависания и вылеты можно увеличив файл подкачки. Как это правильно сделать можно посмотреть в видео инструкции ниже. Это помогает загружать объемные текстуры, анимацию и звуки на жесткий диск, высвобождая ресурсы ОЗУ вашего компьютера.
Источник
Invalid File Signature Error when submitting an image to the eyes service.
- When looking at the tests that are in queue, the test remains in progress.
- While in progress, there does not appear to be a timeout to abort the test consistently. I’ve witnessed this once where it aborts the test in progress.
- A co worker has been able to successfully submit but in an inconsistent fashion.
- When there is an error on his end, it is the same error and log output that I have.
- Best we can tell is that there’s a problem on the service end.
- This issue may be related to the eyes utils module.
Log Output
Error Message
The text was updated successfully, but these errors were encountered:
Hi, thanks for the feedback, apologies for the late reply. A few points:
At the moment, tests in Applitools do not time out on their own. They end when there’s either a call to close or abortIfNotClosed. See example here:
https://applitools.com/resources/tutorial/screenshots/javascript
Regarding the invalid signature, we haven’t encountered any such thing before. Can you create a example test which reproduces the problem?
@joeHillman Following up? Does this still happen? Can you send me an example test which reproduces the issue?
Haven’t had the cycles for this work lately, though I think I’ll be picking it back up over the next week or two. Will let you know what I find. Thanks @danielputerman.
I am also hitting the same issue
The concern is that this test used to passed before. This is just a png image.
Ok looks like I found the reason. I downloaded the file and it seems like the png is corrupted. 
Still it would be nice to have proper stack traces to the line that threw the error in the test (Mocha)
Hi @mekdev, cool. I was suspecting this was the reason, thanks for updating.
I’ll see what we can do about the stack trace of course.
© 2023 GitHub, Inc.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Источник
excelReader.Error : Invalid file signature in xls..but reads same in xlsx file #83
ftype = Path.GetExtension(filename);
if (ftype == «.xls»)
<
// Reading from a binary Excel file (’97-2003 format; *.xls)
excelReader = ExcelReaderFactory.CreateBinaryReader(stream);
>
else
<
// Reading from a OpenXml Excel file (2007 format; *.xlsx)
excelReader = ExcelReaderFactory.CreateOpenXmlReader(stream);
>
The text was updated successfully, but these errors were encountered:
Any fix for this? CreateBinaryReader should read a .xls file, but I get the ExceptionMessage = «Error: Invalid file signature.» message.
@eastwood84 There has been a lot of fixes for .xls compatibility in the recent 3.0 prereleases. Are you using the latest prerelease version of ExcelDataReader?
If you have an xls still not loading in the latest version, any chance you could upload it here or in a new issue ticket?
It seems to be the same issue that I have. It would be nice to get it fixed though
Any chance to share the xls? If not, just the first 8 bytes of the file would help immenselyt (f.ex from a hexviewer or something). Need something to go on here
I seem to be getting the same error with the most recent nuget package (3.0.0).
The first 8 bytes of the file are
The bytes seem to be reversed.
Disregard my last comment. It seems my problem was i needed to seek to the beginning of the stream before trying to use the stream to create the reader.
Thanks for the update @johnboker, I was about to reopen the issue, but keeping it closed unless we get more feedback/reports.
I can think of two other situations where this could happen:
- When using CreateBinaryReader with an .xlsx (use CreateReader instead)
- On big endian machines (f.ex Xbox, or some odd Mono platforms — not supported!)
The only way to get a HeaderException(«Invalid file signature.») is when these bytes do not match. The reverse order has to do with endian-ness.
Relating to your situation, it’s a valid question whether to support loading from the middle of a stream, or to assume the stream always represents an entire workbook. Right now there is some inconsistency: ExcelDataReader probes for format/version at the current stream position, but then rewinds to the beginning of the stream before parsing the detected format
So, if we want to keep it reading from the current position, wouldn’t it make sense just to rewind 8 bytes to be at the start when the method was called?
Источник
Builds broken because package signature file entry is invalid #2523
As discussed on this appveyor forum, AppVeyor builds recently started breaking for me. Feodor Fitsner kindly came up with a minimal repro that suggests that the .NET Core 2.1 packages on nuget.org have bad signatures.
Repro
Create a test-nuget.csproj file with these contents:
Rename or remove your %userprofile%.nugetpackages folder.
Restore packages for test-nuget.csproj using msbuild:
This produces these errors:
Interestingly, this only repros while there are multiple target frameworks specified. Reducing it to just netcoreapp2.1 eliminates the error.
The text was updated successfully, but these errors were encountered:
@rohit21agrawal @nkolev92 any idea what would cause these errors?
Also adding @mmitche @leecow and @vitek-karas in case there is something wrong with the packages we pushed to nuget.org.
CC: @dtivel @PatoBeltran for signing issues
Did some digging cause this looks weird, if you do a NuGet.exe verify -signatures on the package, for example Microsoft.NETCore.App 2.1.0, you get the same error message.
This seems to suggest that there is something wrong with this package.
The reason why it fails with multitargetting is because of the fallback folders.
When you cross-target 2.x and 1.x, the new fallback folder from C:Program FilesdotnetsdkNuGetFallbackFolder is not used.
When you target 2.x only, then the package is consumed from the fallback folder, instead of downloading it and installing in the global packages folder.
- The multi-targeting scenario is by design because NuGet needs to download that package.
- Rest of it suggests that the package is not signed correctly.
@dtivel @PatoBeltran will be able to give more info on the 2nd one.
This is really odd. Why would it start now? 2.1.0 is ages old. Was there a change in nuget?
WIth nuget.exe 4.6.2.5055 I get a successful verification
Did some investigation in this with @nkolev92. It seems like the fallback folder in C:Program FilesdotnetsdkNuGetFallbackFolder is being used as a source and the package in there has the signature entry compressed.
This repros with any version of nuget greater than 4.6.2 (4.6.2 has a worse error experience, but the package errors out). If you test this with the same package from nuget.org the verification succeeds, therefore this tells us that the packages in the fallback folder are the ones that are bad.
NuGet tools do not create any compressed signatures, which tells us that there was something that modified the packages after they where signed.
@livarcocc is sdk doing anything with the packages after signing that could have modified the compression metadata of the signature entry in the packages?
The fallback folder is used as a source if your application targets netcoreapp 1.1 or 1.0. Yes, the lzma compresses all files, however, we have been doing that for quite some time now.
@PatoBeltran we are going to need help to figure out what we are doing wrong here. Is it a file that we are not expanding correctly?
We also ran an additional exercise to validate packages hash from extracted SHA512 file vs generating SHA512 hash from nupkg in dotnet fallback folder and all these package validation failed which suggest either dotnet is not extracting nupkg correctly in fallback folder or they are creating a new nupkg in fallback folder.
The right expectation here is that dotnet has single nupkg for each of their package, which is extracted into fallback folder using NuGet and keep the same nupkg there or publish the same nupkg to NuGet.org or any other feed. At no point in time, there should be another nupkg generated for the same package (on the fly or anything) after the original nupkg has been extracted in fallback folder.
What’s happening here? Now I’m seeing this error in VS itself, blocking intellisense and builds:
Error occurred while restoring NuGet packages: The package signature file entry is invalid. The central directory header field ‘compression method’ has an invalid value (8).
I am going to move this issue over to NuGet, where we can get quicker and better answers to this.
Источник
java security signatureexception invalid file sign
Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
Этот раздел касается:
При запуске апплета или приложения Java появляется диалоговое окно с предупреждением системы безопасности:
Заблокировать запуск потенциально небезопасных компонентов?
Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности. Свяжитесь с поставщиком приложения и убедитесь в отсутствии попыток несанкционированного доступа.
Подписанные приложения и апплеты Java Web Start, содержащие подписанные и неподписанные компоненты, могут быть потенциально небезопасными, если смешанный код не был намеренно использован поставщиком приложения. Начиная с выпуска Java SE 6 Update 19 при работе с программой, которая содержит подписанные и неподписанные компоненты, отображается диалоговое окно с предупреждением.
Если в диалоговом окне безопасности нажать кнопку Да, запуск потенциально небезопасных компонентов будет заблокирован, после чего возможно завершение работы программы. Если нажать кнопку Нет, выполнение приложения или апплета продолжится.
Предупреждение отображается по умолчанию, но существуют параметры для изменения этой настройки.
Способ обработки программ со смешанным кодом можно настроить с помощью панели управления Java.
Поиск панели управления Java
Параметры защиты от смешанного кода в панели управления Java
- В панели управления Java перейдите на вкладку Дополнительно.
- Разверните параметр Проверка безопасности смешанного кода (Из песочницы — Доверенный) в разделе Безопасность.
Доступны четыре уровня управления.
Включить – отображать предупреждение при необходимости
Это настройка по умолчанию. Когда возникает потенциальный риск для безопасности, отображается диалоговое окно. При нажатии кнопки Да выполнение потенциально небезопасных компонентов блокируется, после чего возможно завершение работы программы. Если нажата кнопка Нет, выполнение приложения или апплета продолжится с применением необходимых мер защиты (обнаруженные позднее пакеты или ресурсы с одинаковыми именами, но разными уровнями доверия, например, подписанные или неподписанные, не будут загружены).
Включить – скрыть предупреждение и выполнять с применением мер защиты
При выборе этого параметра диалоговое окно с предупреждением не отображается. Код выполняется так же, как и при нажатии кнопки Нет в диалоговом окне с предупреждением.
Включить – скрыть предупреждение и не выполнять недоверенный код
При выборе этого параметра диалоговое окно с предупреждением не отображается, а код выполняется так же, как и при нажатии кнопки Да в диалоговом окне с предупреждением.
Отключить проверку
Использовать этот параметр не рекомендуется. Этот параметр полностью отключает проверку смешанного доверенного и недоверенного кода, допуская выполнение потенциально небезопасного кода без применения мер защиты.
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: исключение в потоке «main» java.security.SignatureException: ошибка декодирования байтов подписи
- Ошибка при проверке подписи ECDSA в Java с помощью BouncyCastle
- JWT signature fails when using algorithms other than RSA #1210
- Comments
- steps to reproduce
- java security signatureexception invalid file sign
- Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
- Поиск панели управления Java
- Параметры защиты от смешанного кода в панели управления Java
Ошибка при проверке подписи 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 байта).
Может кто-нибудь указать мне, что мне здесь не хватает?
РЕДАКТИРОВАТЬ: решение
Как указал Питер Деттман в своем ответе, signature был неправильно отформатирован (также было неверно содержимое), чтобы его можно было вычислить методом verify() . Вот хороший объяснение, которое в основном говорит, что:
При кодировании в DER эта (подпись) становится следующей последовательностью байтов:
0x30 b1 0x02 b2 (vr) 0x02 b3 (vs)
- b1 — однобайтовое значение, равное длине в байтах оставшегося списка байтов (от первого 0x02 до конца кодирования);
- b2 — однобайтовое значение, равное длине (vr) в байтах;
- b3 — однобайтовое значение, равное длине в байтах (vs);
- (vr) — знаковое прямое кодирование значения «r» минимальной длины;
- (vs) — это знаковое прямое кодирование значения «s» минимальной длины.
Применяя это изменение, signature увеличивается до 70 байт, и выполнение не выдает ошибок.
Источник
JWT signature fails when using algorithms other than RSA #1210
I encountered a problem in JWT signature verification with OxAuthCryptoProvider. It seems it only succeeds when the algorithm is RSA based, not with HS and EC algos
I was able to reproduce in 3.1.x and 4.0. The following is an example based on SCIM RP keys but passport RP can also be used.
steps to reproduce
Pick a key from scim-rp.jks, eg. b290d965-5fc9-409b-8c77-bb04982d0944_sig_es256 and export the private key (download my keystore here):
# /opt/jre/bin/java -cp ‘/home/jetty/lib/*’ org.gluu.oxauth.util.KeyExporter -keystore scim-rp.jks -keypasswd secret -alias b290d965-5fc9-409b-8c77-bb04982d0944_sig_es256 -exportfile scim-private-key.pem
Generate a JWT and sign with the private key (use this javascript file or python file as guide). I used both to test.
Verify the signature of the token. I used jython for agility (paste the token obtained in the RHS of jwt variable below):
The call to check returns False and oxauth.log shows:
If I change, say, to key 4c0ef252-909f-4674-92da-ea8168c9767c_sig_rs256 , export private key, and change algorithm in scripts, the validation passes.
The text was updated successfully, but these errors were encountered:
It’s bug, for EC algorithm signature is not transcoded and therefore verification fails. Both jwt.io and nimbus confirmed it.
Fixed it with ada654d . Not closing it yet, we must carefully cover it with tests.
I’ve fixed oxauth cryptoProvider and oxauth ecdsaSigner. At least now JWT created by third-party lib is verified successfully by jwt.io, nimbus, oxauth cryptoProvider and oxauth ecdsaSigner.
However after full re-build and tests re-run we got 58 test failures. (Which can be seen here: https://ox.gluu.org/jenkins/job/oxAuth_4.1_LDAP/259/)
That makes me think that we have bug in JWT generation for EC algorithms as well. To check it I performed following:
- take static JWT -> validate by nimbus, oxauth cryptoProvider and oxauth ecdsaSigner
- generate JWT by nimbus -> validate by nimbus, oxauth cryptoProvider and oxauth ecdsaSigner
- generate JWT by oxauth -> validate by nimbus, oxauth cryptoProvider and oxauth ecdsaSigner
It gives full picture of compatibility and whether generator and verifier works correctly.
It means that we spot another bug. Now during signing with EC algorithms (and this is the reason of 58 test failures).
Источник
java security signatureexception invalid file sign
Ошибка. Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности.
Этот раздел касается:
При запуске апплета или приложения Java появляется диалоговое окно с предупреждением системы безопасности:
Заблокировать запуск потенциально небезопасных компонентов?
Среда Java обнаружила компоненты приложений, которые могут указывать на наличие угроз безопасности. Свяжитесь с поставщиком приложения и убедитесь в отсутствии попыток несанкционированного доступа.
Подписанные приложения и апплеты Java Web Start, содержащие подписанные и неподписанные компоненты, могут быть потенциально небезопасными, если смешанный код не был намеренно использован поставщиком приложения. Начиная с выпуска Java SE 6 Update 19 при работе с программой, которая содержит подписанные и неподписанные компоненты, отображается диалоговое окно с предупреждением.
Если в диалоговом окне безопасности нажать кнопку Да, запуск потенциально небезопасных компонентов будет заблокирован, после чего возможно завершение работы программы. Если нажать кнопку Нет, выполнение приложения или апплета продолжится.
Предупреждение отображается по умолчанию, но существуют параметры для изменения этой настройки.
Способ обработки программ со смешанным кодом можно настроить с помощью панели управления Java.
Поиск панели управления Java
Параметры защиты от смешанного кода в панели управления Java
- В панели управления Java перейдите на вкладку Дополнительно.
- Разверните параметр Проверка безопасности смешанного кода (Из песочницы — Доверенный) в разделе Безопасность.
Доступны четыре уровня управления.
Включить – отображать предупреждение при необходимости
Это настройка по умолчанию. Когда возникает потенциальный риск для безопасности, отображается диалоговое окно. При нажатии кнопки Да выполнение потенциально небезопасных компонентов блокируется, после чего возможно завершение работы программы. Если нажата кнопка Нет, выполнение приложения или апплета продолжится с применением необходимых мер защиты (обнаруженные позднее пакеты или ресурсы с одинаковыми именами, но разными уровнями доверия, например, подписанные или неподписанные, не будут загружены).
Включить – скрыть предупреждение и выполнять с применением мер защиты
При выборе этого параметра диалоговое окно с предупреждением не отображается. Код выполняется так же, как и при нажатии кнопки Нет в диалоговом окне с предупреждением.
Включить – скрыть предупреждение и не выполнять недоверенный код
При выборе этого параметра диалоговое окно с предупреждением не отображается, а код выполняется так же, как и при нажатии кнопки Да в диалоговом окне с предупреждением.
Отключить проверку
Использовать этот параметр не рекомендуется. Этот параметр полностью отключает проверку смешанного доверенного и недоверенного кода, допуская выполнение потенциально небезопасного кода без применения мер защиты.
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».
Источник
