WSS4J Encryption with certificate containing specific KeyUsages

[Luigi Lo Iacono <lo...@ccrl-nece.de>]

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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org