Статус: Новичок
Группы: Участники
Зарегистрирован: 22.09.2021(UTC) Сообщений: 5
|
Здравствуйте! Помогите разобраться с вопросом импорта закрытого ключа из файла по ГОСТ Р 34.11-2012/34.10-2012 256 бит. Искал на форуме решения, но всё равно не понятно, почему ключ не читается? Использую следующее окружение: Код:Debian GNU/Linux 11
openjdk version "1.8.0_302"
OpenJDK Runtime Environment (build 1.8.0_302-b08)
OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mode)
jcp-2.0.41789
Например, получил ключ с помощью openssl, который настроен на ГОСТ. Код:# openssl ciphers | tr ':' '\n' | grep GOST
GOST2012-GOST8912-GOST8912
GOST2001-GOST89-GOST89
// Создание ключей по алгоритму подписи 1.2.643.7.1.1.3.2 (ГОСТ Р 34.11-2012/34.10-2012 256 бит)
# openssl req -x509 -newkey gost2012_256 -pkeyopt paramset:A -nodes -keyout keyA.pem -out certA.pem
# openssl x509 -outform der -in certA.pem -out certA.crt
Пытаюсь прочитать закрытый ключ keyA.pem из файла по алгоритму подписи ГОСТ Р 34.10-2012 с ключом 256 (1.2.643.7.1.1.1.1) с помощью провайдера BouncyCastle Security Provider v1.60. Код:# java -cp .:dependencies/* PKeyReader /distrib/cert/test/keyA.pem 1.2.643.7.1.1.1.1 BC certA.zip (2kb) загружен 0 раз(а).
+ key factory: java.security.KeyFactory@340f438e
algorithm: 1.2.643.7.1.1.1.1
provider: BC version 1.6
+ pkcs8 encoded key spec: java.security.spec.PKCS8EncodedKeySpec@30c7da1e
format: PKCS#8
Exception in thread "main" java.security.spec.InvalidKeySpecException: encoded key spec not recognized: DEF length 39 object truncated by 9
at org.bouncycastle.jcajce.provider.asymmetric.util.BaseKeyFactorySpi.engineGeneratePrivate(Unknown Source)
at org.bouncycastle.jcajce.provider.asymmetric.ecgost12.KeyFactorySpi.engineGeneratePrivate(Unknown Source)
at java.security.KeyFactory.generatePrivate(KeyFactory.java:366)
at PKeyReader.main(PKeyReader.java:62)
Возможно ли прочитать ключ в PrivateKey таким образом? Код:
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import java.io.IOException;
import java.net.URISyntaxException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.Security;
import java.security.KeyFactory;
import java.security.NoSuchAlgorithmException;
import java.security.PrivateKey;
import java.security.interfaces.RSAPublicKey;
import java.security.spec.InvalidKeySpecException;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;
import java.util.Base64;
/**
* Чтение закрытого ключа из файла.
*/
public class PKeyReader {
/**
* Попытка прочитать закрытый ключ из файла
* @param путь к ключу
* @param алгоритм
* @param провайдер (опциональный)
*/
public static void main(String[] args) throws Exception {
if (args.length < 2) {
System.out.println("input error: skipped required parameters.");
System.out.println(" java .:dependences/* Main [key path] [algorithm] {provider}");
return;
}
Security.addProvider(new BouncyCastleProvider());
String privateKeyPath = args[0];
String algorithm = args[1];
String provider = args.length > 2 ? args[2] : "";
String privateKeyContent = new String(Files.readAllBytes(Paths.get(privateKeyPath)));
privateKeyContent = privateKeyContent.replace("-----BEGIN PRIVATE KEY-----", "").replace("-----END PRIVATE KEY-----", "").replaceAll("\\s", "");
System.out.println(privateKeyContent);
KeyFactory kf = null;
if (provider.isEmpty())
kf = KeyFactory.getInstance(algorithm);
else
kf = KeyFactory.getInstance(algorithm, provider);
System.out.println("+ key factory: " + kf);
System.out.println(" algorithm: " + kf.getAlgorithm());
System.out.println(" provider: " + kf.getProvider());
byte[] privData = Base64.getDecoder().decode(privateKeyContent);
PKCS8EncodedKeySpec keySpecPKCS8 = new PKCS8EncodedKeySpec(privData);
System.out.println("+ pkcs8 encoded key spec: " + keySpecPKCS8);
System.out.println(" format: " + keySpecPKCS8.getFormat());
PrivateKey privKey = kf.generatePrivate(keySpecPKCS8);
System.out.println("+ private key: " + privKey);
}
}
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Добрый день. Что-то эту тему проглядел. Импорта куда? Опишите какую задачу решаете.
Как я понимаю, импортировать таким способом ключ в КриптоПро невозможно. КриптоПро CSP не выпускает реальный ключ "наружу" (и через большинство интерфейсов не принимает реальный ключ "извне") - при поиске контейнера КриптоПро по сертификату в результате в классе PrivateKey находится идентификатор закрытого ключа вместо реального закрытого ключа. Аналог как в раздевалке берется пальто с прилавка и дается в руки номерок вместо пальто. Соответственно при использовании класса PrivateKey для подписания/шифрования также расчет на то, что там идентификатор, а не сам ключ. По идентификатору КриптоПро находит у себя закрытый ключ (по номерку находится пальто). Импорт ключа из PrivateKey просто не поддерживается: выходит что вместо номерка пихаете еще одно пальто.
В теории способ перенести ключ openssl в КриптоПро есть: средствами openssl нужно зашифровать ключ в формат P12/PFX, с алгоритмом шифрования гост-89 и маками гост-2012 512 бит (согласно рекомендациям ТК26), затем использовать p12utility для переноса ключа из pfx в контейнер КриптоПро. Один из JCP/JCSP к слову умеет читать PFX с ключами гост-2012, но мне сложно подсказать какие там алгоритмы обертки ключа принимаются.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.09.2021(UTC) Сообщений: 5
|
Спасибо за ответ! Отличный пример с раздевалкой, сразу становится всё на свои места. ))) Сразу было понятно, что импорт не поддерживается штатными средствами. Цитата:Импорта куда? Опишите какую задачу решаете. Задача решалась в рамках интеграции с адаптером СМЭВ, импорт ключей в JCP контейнер. Проблема решилась путём копирования Rutoken в HDImageStore в контрольной панели, для получения псевдонима подписи.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.09.2021(UTC) Сообщений: 5
|
Ещё пару вопросов: - p12utility есть ли аналоги этой утилиты в Linux? - ошибка тестирования подписи закрытого ключа в настройках информационной системы (ИС) адаптера СМЭВ. Ситуация такая, скопировал каталог HDImageStore с 6 файлами в другой каталог docker контейнера, где настроил адаптер СМЭВ и Крипто Про JCP. Когда проверяю подпись в настройках ИС, получаю сообщение, Провайдер JCP - OK Открытый ключ - OK Тестирование подписи закрытого ключа - FAIL. При этом подпись работает на виртуалке, где есть Rutoken (который скопирован в HDImageStore). Копировал в каталог /var/opt/cprocsp/keys/root/TEST.000 Это тоже связано с тем, что копируется ид закрытого ключа?
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Цитата:- p12utility есть ли аналоги этой утилиты в Linux? Мне не попадались на глаза. По внешнему анализу под Windows утилита самодостаточная (КриптоПро CSP не требуется), но запрашивает у Майкрософт КриптоАпи случайные данные, поэтому для портирования в Linux явно понадобится другой надежный источник случайных чисел. Скорее всего с этим проблем - к чему ее привязать на разномастных Linux тот еще вопросик. Автор: lightness - ошибка тестирования подписи закрытого ключа в настройках информационной системы (ИС) адаптера СМЭВ. Ситуация такая, скопировал каталог HDImageStore с 6 файлами в другой каталог docker контейнера, где настроил адаптер СМЭВ и Крипто Про JCP. Когда проверяю подпись в настройках ИС, получаю сообщение, Провайдер JCP - OK Открытый ключ - OK Тестирование подписи закрытого ключа - FAIL. При этом подпись работает на виртуалке, где есть Rutoken (который скопирован в HDImageStore). Копировал в каталог /var/opt/cprocsp/keys/root/TEST.000 Это тоже связано с тем, что копируется ид закрытого ключа? Про ид закрытого ключа скорее речи нет - в папке в файле name.key указывается дружественное имя контейнера и может фигурировать контрольная сумма от него, так что при копировании папки это должно сохранится. Для флешек может фигурировать метка флешки и volumeid. Для токена его серийный номер. Для двух HDIMAGE не припомню чтобы были какие отличия, но могу ошибаться. Можно сравнить какие fqcn у контейнера в одном месте и в другом. Если отличаются, то связка сертификата и контейнера после копирования стала неверна и нужно по-новой связать сертификат и контейнер. Правда, как это выглядит в JCP подсказать не смогу, другой alias это станет или что еще. Если вообще не видно контейнера... На первый взгляд путь правдоподобный. Может еще быть пользователь не тот (путь для root, а приложение от чьего имени выполняется? ), либо нет прав у пользователя на этот каталог.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.09.2021(UTC) Сообщений: 5
|
Цитата:Может еще быть пользователь не тот (путь для root, а приложение от чьего имени выполняется? ), либо нет прав у пользователя на этот каталог Приложение адаптера запускаю под root, и криптоконтейнер настраивал для root.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 22.09.2021(UTC) Сообщений: 5
|
Спасибо большое за развёрнутый ответ!
Стало понятно, что подпись можно настроить в докер контейнере независимо от rutoken.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close