Здравствуйте.

Предполагается использование КриптоПро JCP для обеспечения закрытого обмена.
На КриптоПро CSP все решалось использованием классических выховов CAPI.

HCRYPTPROV hProv; (PROV_GOST_2001_DH)
HCRYPTKEY *hKey;
LPBYTE *pbPubKey;
LPDWORD cbPubKey;
ALG_ID aiSrcKey;
LPSTR szDHOID;
LPSTR szHashOID;

CryptGenKey(hProv, aiSrcKey, CRYPT_PREGEN, hKey1);
CryptSetKeyParam(*hKey1, KP_X, NULL,0);
CryptExportKey(*hKey1, 0, PUBLICKEYBLOB, 0, pbEPubKey, &cbEPubKey);

//-----------------------------------------------------------------------------------------------------------//

ImportPublicKey(hProv, hKey1,hKEK, pbPubKey2, cbPubKey2,aiKey2, szDHOID2,szHashOID2);

Отталкиваясь от документации по JAVA и КриптоПРо мы попытались реализовать следующую конструкцию.

java.security.KeyStore hdImageStore = java.security.KeyStore.getInstance("HDImageStore");
hdImageStore.load(null, null);

java.security.PrivateKey senderKey = (java.security.PrivateKey) hdImageStore.getKey("signkey", null);
java.security.cert.X509Certificate publicSenderCert = (java.security.cert.X509Certificate) hdImageStore.getCertificate("signkey");

final byte[] sv = {0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11};
final javax.crypto.KeyAgreement senderKeyAgree = javax.crypto.KeyAgreement.getInstance("GOST3410DH");
senderKeyAgree.init(senderKey, new javax.crypto.spec.IvParameterSpec(sv), null);
senderKeyAgree.doPhase(publicSenderCert, true);
javax.crypto.SecretKey sk = senderKeyAgree.generateSecret("GOST28147");

Все отрабатывается нормально, но alisaSecret.getEncoded() возвращает NULL;
Не совсем понятно с установкой параметров, в данной реализации как мы поимаем беруться текущие.

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

Спасибо.

Спасибо, Ольга.

В принципе это мы и ожидали. Но проверить не смогли и не можем т.к.
cipher.init(javax.crypto.Cipher.WRAP_MODE, secretKey, new javax.crypto.spec.IvParameterSpec(sv));
приводит к
java.lang.UnsupportedOperationException
at javax.crypto.CipherSpi.engineGetKeySize(DashoA13*..)
at javax.crypto.Cipher.b(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)......

Вот весь кусочек кода-

CertificateFactory cf = CertificateFactory.getInstance("X509");
java.security.cert.Certificate cert = null;
java.io.FileInputStream fis = new java.io.FileInputStream("c:\\T3.cer");
cert = cf.generateCertificate(fis);
java.security.PublicKey pk = cert.getPublicKey();

final javax.crypto.KeyGenerator kg = javax.crypto.KeyGenerator.getInstance("GOST28147");
final javax.crypto.SecretKey key = kg.generateKey();

final byte[] sv = {0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11};
java.security.KeyStore hdImageStore = java.security.KeyStore.getInstance("HDImageStore");
hdImageStore.load(null, null);

java.security.PrivateKey senderKey = (java.security.PrivateKey)hdImageStore.getKey("signkey", null);
java.security.cert.X509Certificate publicSenderCert = (java.security.cert.X509Certificate) hdImageStore.getCertificate("signkey");

//выработка ключа согласования для зашифрования ключа key
final javax.crypto.KeyAgreement senderKeyAgree = javax.crypto.KeyAgreement.getInstance("GOST3410DH");
senderKeyAgree.init(senderKey, new javax.crypto.spec.IvParameterSpec(sv), null);
senderKeyAgree.doPhase(pk, true);
final javax.crypto.SecretKey secretKey = senderKeyAgree.generateSecret("GOST28147");

//создание шифратора
javax.crypto.Cipher cipher = javax.crypto.Cipher.getInstance("GOST28147/PRO_EXPORT/NoPadding");
cipher.init(javax.crypto.Cipher.WRAP_MODE, secretKey, new javax.crypto.spec.IvParameterSpec(sv));
final byte[] wrap = cipher.wrap(key);

И наконец в этом алгоритме создания сессионного ключа на этапе согласования НЕОБХОДИМ открытый ключ другой стороны, который как мы понимаем как раз и будет использоваться для расшифрации wrap, что в принципе ОТЛИЧАЕТ его от формирования сессионного ключа через блок функций
CryptGenKey(hProv, aiSrcKey, CRYPT_PREGEN, hKey1);
CryptSetKeyParam(*hKey1, KP_X, NULL,0);
CryptExportKey(*hKey1, 0, PUBLICKEYBLOB, 0, pbEPubKey, &cbEPubKey);

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

Спасибо. Будем смотреть.

В новом CSP SDK (который, к сожалению, пока не выложен) есть примеры правильного (кроссплатформенного) согласования ключей, выработки и обмена общим симметричным ключом, зашифрования и расшифрования на нём. В readme.txt есть рецепт использования на Unix. Рецепт для Windows:
1. Создать контейнер Sender с ключом обмена и сертификатом, без пароля (например, веб-формой на тестовом УЦ).
2. Создать контейнер Responder с ключом обмена и сертификатом, без пароля (например, веб-формой на тестовом УЦ).
3. ExportInFile Sender
4. ExportInFile Responder
5. создать файл source.txt
6. EncryptFile
7. DecryptFile
Создание сертификатов, а не просто контейнеров с ключами принципиально. Примеры поддерживают и работу без сертификатов, но это нерекомендованный способ, т.к. он не защищает открытых ключей и не является кроссплатформенным, кроме того он не поддерживается КриптоПро JCP. В примерах КриптоПро JCP (подходящая сборка которых тоже не выложена) есть полностью аналогичные примеры. Они поддерживают встречную работу. Примеры из SDK приложил.

Отредактировано пользователем 2 марта 2009 г. 18:59:51(UTC)  | Причина: Не указана