avef, здравствуйте еще раз.
Мы, вероятно, вас несколько запутали конфликтующими вопросами, попробую прояснить ситуацию. Ситуация такова:
- Есть WCF-сервис на базе .NET, использующий Крипто-Про .NET и Крипто-Про CSP. Сервис имеет два endpoint, один с шифрованием/подписью RSA, второй с шифрованием/подписью ГОСТ:
Цитата: <binding name="WS2007HttpBinding_RSA" maxReceivedMessageSize="8000000">
<security>
<message clientCredentialType="Certificate" negotiateServiceCredential="false" algorithmSuite="Default" establishSecurityContext="false" />
</security>
</binding>
<binding name="WS2007HttpBinding_GOST" maxReceivedMessageSize="8000000">
<security>
<message clientCredentialType="Certificate" negotiateServiceCredential="false" algorithmSuite="BasicGost" establishSecurityContext="false" />
</security>
</binding>
- Данный сервис успешно работает с клиентами на платформе .NET, использующими такую же связку. Пример запроса приложен
- Мы пытаемся реализовать клиент для данного сервиса на Java. Вот на этом этапе возникли проблемы.
Согласно спецификациям WSS-Security (в варианте, используемом WCF), отправитель шифрует/подписывает сообщения следующим образом (упрощенно):
- подписывает сообщение своим закрытым ключом
- генерирует сессионный ключ
- шифрует подписанное сообщение сессионным ключом
- шифрует сессионный ключ на открытом ключе получателя (вот в этой части возникает вопрос)
- отправляет получателю результат шагов 3 и 4 + какой-то идентификатор открытого ключа получателя (в нашем случае, отпечаток)
Получатель, в свою очередь, расшифровывает сессионный ключ своим закрытым ключом, расшифровывает сообщение, проверяет подпись и обрабатывает его.
Собственно, на п.4 у нас и возникла проблема.
В приложенном примере видны следующие элементы:
Код: <e:EncryptedKey Id="uuid-5cad7fa5-cd35-4fd4-9fcd-e566f09b6002-1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">F0ZHj2VbkApmQDYUxqbg2aGzydg=</o:KeyIdentifier>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>MIGkMCgEILyF8HHZ4IrfkmLDRneMTYICP3exkRomhOtsKm5nlvZbBAS1wlrmoHgGByqFAwICHwGgYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAS5Rxzdo+E9fVQf9UsKCSmERrZWT7uocFUP51yEIDKr99r8EPW+wSc0xuSBLu//IZJe2MWERNkqxLSKlCnrRyAAQI3nG4QdtncSQ=</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
<sc:DerivedKeyToken u:Id="_0" Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512">
<o:SecurityTokenReference k:TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
<o:Reference ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" URI="#uuid-5cad7fa5-cd35-4fd4-9fcd-e566f09b6002-1"/>
</o:SecurityTokenReference>
<sc:Nonce>6duu1lhbcg0M6JIT/jgVDQ==</sc:Nonce>
</sc:DerivedKeyToken>
<sc:DerivedKeyToken u:Id="_2" Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411" xmlns:sc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512">
<o:SecurityTokenReference k:TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" xmlns:k="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
<o:Reference ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" URI="#uuid-5cad7fa5-cd35-4fd4-9fcd-e566f09b6002-1"/>
</o:SecurityTokenReference>
<sc:Nonce>Yo0zWywt+IEHdwZEFTr4Mw==</sc:Nonce>
</sc:DerivedKeyToken>
Видно, что зашифрованный ключ (EncryptedKey) ссылается на открытый ключ сервера (F0ZHj2VbkApmQDYUxqbg2aGzydg= - это отпечаток сертификата X.509 сервера). Однако, как именно происходит шифрование - неясно. Поиск по Namespace urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 приводит нас в
драфт RFC, секция 6.6:
Цитата:6.6. GOST R 34.10-2001-based Key Transport Algorithm in
EncryptionMethod
The key transport alogorithm based on VKO GOST R 34.10-2001,
specified in [CPALGS], is public key encryption algorithms, that MUST
be used for key encryption/decryption only.
The identifier for the key transport algorithm based on VKO
GOST R 34.10-2001 is:
urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001
Цитата: The CipherValue for such encrypted key is the base64 encoding of the
[X.208-88] DER encoding of a GostR3410-KeyTransport structure (see
section 4.2.1 of [CPCMS]).
Указанный документ [CPCMS] (
RFC 4990), в свою очередь, ссылается на некий VKO GOST R 34.10-2001, описанный в
RFC 4357, описывающий его. Но каким образом реализовать это в Java - не совсем ясно.
Собственно, наши вопросы:
- Как правильно реализовать данную схему в клиенте на JCP? Как именно с помощью Крипто-Про JCP зашифровать сессионный ключ?
- Как правильно создать ключи Derived key? (namespace urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411; тут как раз возникает вопрос об алгоритме P_GOSTR3411)
Заранее благодарны за ответ.
Отредактировано пользователем 10 января 2013 г. 17:21:27(UTC)
| Причина: Не указана
Вложение(я):
dotNETClientGOSTCryptoRequest.xml
(12kb) загружен 7 раз(а).У Вас нет прав для просмотра или загрузки вложений. Попробуйте зарегистрироваться.
