Hi there!
I encountered the same issue as posted by Scott Maxwell on February 3th,
2006 to the wss4j-dev mailing list. The issue is related to encryption
using X.509 certificates containing the (critical) certifiacte extension
"KeyUsage". If such a certificate is used to encrypt e.g. a SOAP Body,
the encryption will fail, reporting a "wrong key usage". The reason for
this exception relies in the instantiation of a Cipher object with an
asymmetric algorithms in ENCRYPT_MODE. If the certificate used for
encryption includes the KeyUsage extension in this case, it has to
contain the "dataEncipherment" usage as will be explained later in this
email. The more appropriate "keyEncipherment" usage will result in the
aforementioned exception, though.
Scott's posting has become a bug report in the JIRA system (JIRA key:
WSS-34). The issue was closed after deciding not to fix it. The
arguments leading to this decision have been the following (provided by
Werner Dittmann):
- the W3C XML Encryption standard specifies a key transport mechanism
based on the RSA encryption schemes RSA/PCKS1_5 and RSA/OAEP
- the key transport in the W3C XML Encryption standard is _not_
qualified as key wrapping
- for key wrapping, the W3C XML Encryption standard specifies algorithms
which are based on symmetrical algorithms
I think this decision has to be revisited, because I feel that some
misleading usages of the terms "key transport" and "key wrapping"
especially appearing in the JCE API caused misunderstandings which
resulted in the - from my perspective - wrong decision to not adapt the
suggested fixes by Scott.
To make my viewpoint clear, I will start by describing, how the JCE
Cipher class considers the KeyUsage certificate extension when
initialising for encryption (deducted by simple tests with different
certificates):
- if the certificate contains no KeyUsage extension, the cipher will be
initialised in either ENCRYPT_MODE or WRAP_MODE
- if the certificate contains the KeyUsage extension, the cipher will be
initialise
+ if the KeyUsage "dataEncipherment" is set and the cipher should
work in ENCRYPT_MODE
or
+ if the KeyUsage "keyEncipherment" is set and the cipher should work
in WRAP_MODE
otherwise
+ a InvalidKeyException is thrown saying "Wrong key usage".
This behaviour of the JCE Cipher class reflects the certificate
extensions in a right and necessary way. However, the misleading point
here is the term "WRAP_MODE". Key wrapping is defined as the encryption
of keys using _symmetric_ algorithms. And in fact, for a bunch of
symmetric ciphers, specific schemes for key wrapping are available. The
latest example is the key wrapping scheme for the AES. This means, when
instantiating a symmetric cipher in ENCRYPT_MODE or in WRAP_MODE will
result in two different schemes, one for data encryption and the other
for key encryption.
Such a differentiation is not available for _asymmetric_ algorithms. The
same schemes are used for data encryption as for symmetric key
encryption. In order to distinguish the asymmetric encryption of
symmetric keys from key wrapping the term "key transport" is used
instead. Now it is clear, that the above arguments by Werner are all
true and it becomes furthermore obvious that the W3C XML Encryption
standard uses the terms "key wrapping" and "key transport" in the
aforementioned manner. However, Werner's arguments must be seen in
distinct light, to deduct the right consequences.
Since a TRANSPORT_MODE is not defined within the JCE, this leads to
misunderstandings when an asymmetric cipher should be used for key
transport. The JCE Cipher object has to be initiliased using the
WRAP_MODE. This will result in an asymmetric Cipher object that uses the
same encryption scheme as in ENCRYPT_MODE (this can be extracted e.g. in
the BC source code or it can be tested by simple programs using not so
random PRNGs), but considers the KeyUsage.keyEncipherment certificate
extension (if available) and ensures/enforces that only Key objects are
encrypted.
So, the replacement of ENCRYPT_MODE with WRAP_MODE and doFinale() with
warp()/unwrap() when using an asymmetric scheme for key transport is
defently the right way to go. It will be perfectly according to the W3C
XML Encryption standard and should not include further PCKS#8 or X.509
data handling (at least the X.509 handling is done by the Cipher class).
I really hope that you will reconsider the suggested changes by Scott,
since the correct consideration of _critical_ certificate extensions is
crucial to security. The JCE does recognize the certificate extensions
appropriatly, WSS4J doesn't.
BTW, my preferred solution would be an enhancement of the JCE APIs, in
order to distinguish key wrapping from key transport. I think such
differentiations will become more important in the future, since new
approaches known as "key encapsulation" are currently under development
and standardisation (within ISO) and which will cause even more
confusion if no clear terminology will be introduced at JCE level.
Cheers, Luigi.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
