Bug # 2267 and #24056

I will note that 24056 is basically  a duplicate of #2267 just stating the
case from the other side of the issue.

 

These two bugs exist solely because of the issues involved with crossing the
boundary between the script and the embedded code.  If the wrap and unwrap
operations are contained either only in script or only in the embedded code
then the wrapKey operation can be defined without resorting to the use of
the encryption operation.  

 

There are some security issues that I would like to have considered before
we just decide that we can make the statement that the encryption key usage
is required for doing key wrap.  Doing so means that one cannot protect a
key from possible exposure to the script (may not be considered to be an
issue by some but is by others).  Changing the definition of the wrap
function so that there are two different descriptions so that there is
effectively one for inside of the embedded system and one for crossing the
security boundary makes things slightly more complicated in description, but
addresses this problem.  

 

In looking at the question of modifying the description of the wrapKey and
unwrapKey methods, is it reasonable to be able to have a step which asks the
question:

 

X. If executing in embedded code and the wrappingKey is in embedded code
then ..

 

>From earlier messages from Ryan, I think that the answer would be yes as the
first statement is easy to check and the second have is going to be a
tautology because we don't reflect keys back into the script from the
embedded system.

 

If so then I would suggest  a modification to step 10.

 

10.  Encrypt bytes with the wrappingKey, with wrappingKey as key,
normalizedAlgorithm as algorithm, and with bytes as buffer

   1. If in the embedded code

                Execute the encrypt algorithm checking for the usage of
wrappingKey rather than key usage encrypt.

   2. If not in embedded code

                Execute the normal encrypt algorithm

 

Jim

 

Received on Friday, 24 January 2014 22:36:53 UTC