# How does a key wrapping like RFC 3394 secure my cryptographic keys?

So I'm messing around in the BouncyCastle library with the RFC 3394 AES Key Wrap engine and I'm trying to understand the benefit of it.

The problem I'm running into is how to store keys securely on a device like a phone or even a laptop or desktop. I need to wrap the keys so that anyone snooping around in memory can't just get those keys. RFC 3394 looks as though it's designed to help with that issue.

I can just do

$$\bar k = \operatorname{wrap}_{k^*, IV}(k)$$

and store $\bar k$ instead of $k$, and use

$$k = \operatorname{unwrap}_{k^*, IV}(\bar k)$$

to retrieve $k$ again when I need it.

I've written this code in C# to test it out. This seems to work okay, except for the fact that I'm trying to understand how this is more secure. At some point I have to store the key encryption key $k^*$ in memory, and it seems to me that any hacker who could get their hands on $k^*$ now has their hands on the encryption keys.

So how does this secure the encryption keys in memory?

-
I edited your question to remove the source code and instead add some formulas, as the actual code is not relevant for your question (and we want it here more on the theoretic level). – Paŭlo Ebermann Oct 31 '11 at 16:08
Ah thanks Paulo. :) – hobeau Oct 31 '11 at 17:11

## 1 Answer

Yes, you are correct; the keywrap algorithm assumes that you have one long term secure key, which you can use to protect other keys. The writers of RFC 3394 assume that you do have a secure key-encrypting-key (KEK).

This doesn't appear to be a valid assumption in your case. In your case, you need to do cryptographical operations even though someone can assume your entire memory space; this sounds like you need White Box cryptography.

-
Thanks for your answer poncho, It looks like whitebox is mostly obfuscation. I was hoping that there was a more secure solution for encrypting a key. Does this not exist? – hobeau Oct 31 '11 at 17:42
Well, no, there isn't, at least, not if you are living in a "fishbowl" environment where the someone can look in at any time. Conventional cryptography assumes that there is some information (key) that an attacker does not know; a fishbowl doesn't have any place to store one securely. – poncho Oct 31 '11 at 19:50
There are many hardware solutions to the fishbowl problem, including TPM chips and security tokens. Basically, they provide some bit of secure hardware that can hold a KEK or equivalent. – David Schwartz Nov 3 '11 at 4:48