Re: [pkcs11] General Philosophy - What starts in the HSM, stays in the HSM.

[Michael StJohns <msj@nthpermutation.com>]

On 8/7/2013 2:05 PM, Oscar K So Jr. wrote:
> Hi Michael,
>
>
> On 08/ 7/13 10:49 AM, Michael StJohns wrote:
> > Hi Oscar
> >
> >
> > One of the simpler protocols is to use a challenge/signature model.   
> > Do a call to C_GetAttributeValue for some global object that has a 
> > CKA_VALUE that changes everytime you query it.
> "CKA_VALUE that changes everytime you query it", sounds like 
> One-Time-Password (OTP) to me...!!!

Nope - the challenge isn't used directly as a password.  The mechanism 
for producing the challenge is perceptively random whereas the OTP is 
pseudo-random where both the source and destination are synchronized so 
they can both generate/verify the same data.

> > It's the secondary keys that are bothering me
>
> Question: are the secondary keys wrapped with the primary key ?

No.

Concrete example

On your HSM generate an EC P-256 key pair.

Receive an EC P-256 public key from an external entity.

Use that public key along with the private key of your P-256 key pair 
and the CKM_ECDH1_DERIVE mechanism with the CKD_SHA1 derive mechanism 
and a template where CKA_SENSITIVE=true, CKA_EXTRACTABLE=false, and 
CKA_PUBLIC=false to derive a 256 bit AES key.

Use that AES key for the next week or so to be the session key for a 
secure association with that external entity.

Sometime in the next week, an attacker gets access to the HSM (has the 
pin, has a comms path).  He then uses your P-256 private key along with 
the public key from the entity to do the same derive you did.  This time 
he either sets CKA_SENSITIVE=false or CKA_EXTRACTABLE=true (or both).   
This creates a second key which is mostly the same as your first key, 
except for the setting of privilege bits.   If the attacker created a 
non-sensitive key, he extracts the key material by doing 
C_GetAttributeValues, if the latter he loads a key (C_CreateObject) and 
wraps the newly derived key under that key (C_WrapKey).  Your attacker 
can now either insert traffic into the stream, or decrypt the traffic 
you're sending.



> If you look into Oracle Database TDE design:
> http://docs.oracle.com/cd/B28359_01/network.111/b28530/img/transdata.gif
> (http://docs.oracle.com/cd/B28359_01/network.111/b28530/asotrans.htm)
> Your primary key is the "Master Encryption Key" (MEK) in Oracle TDE's 
> Wallet
> Your secondary keys are the "Column Encryption Keys" in Oracle TDE's 
> Data Dictionary.
> When the Wallet is closed, the "Column Encryption Keys" are stored and 
> wrapped (encrypted) by MEK.
> When the data is being accessed (i.e. SELECT * FROM client_info;), the 
> Wallet will open, and the Column Encryption Keys are unwrapped by MEK, 
> and the Column Encryption Key will decrypt the column data and return 
> to the caller of the SQL SELECT statement.
> The Data Dictionary also has a Tablespace Encryption Key (same as 
> Column Encryption Key or secondary key) which is used to encrypt the 
> whole tablespace in Oracle database.
> Oracle TDE works with an HSM, and the Wallet can be securely stored 
> inside an HSM.
> Only the Wallet with MEK is stored inside an HSM 
> (http://www.thalesgroup.com/Press_Releases/090915_D3S_Thales_Hardware_Security_Modules_Now_Available_for_Oracle%C2%AE_Database_11g_Release_2/)
> The Data Dictionary (with wrapped secondary keys) are outside of HSM.

This is the wrapping key example rather than the derive key one.  I 
assume in this case that the MEK is in the HSM, has never left the HSM, 
and has a CKA_UNWRAP_TEMPLATE that sets CKA_SENSITIVE to true, 
CKA_EXTRACTABLE to false and CKA_PUBLIC to false (and has the 
appropriate CKA_OBJECT_CLASS and key types in the unwrap template). I 
also assume that the column encryption keys were originally generated in 
the HSM with CKA_EXTRACTABLE=true, but were deleted immediately after 
being wrapped by the MEK.

If you do it this way, AND you're sure the attacker can't get a copy of 
the column encryption key (e.g. C_CopyObject, or C_WrapKey with another 
key) between the time it's generated, wrapped and deleted, this is 
fairly secure.  The problem is that if your client system is hacked, you 
can't actually guarantee this....

Mike



> Best,
> Oscar
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> > - the results of a KDF operation, or the results of a Key Agreement 
> > (ECDH, DH) operation, and to a lesser extent the keys from an 
> > wrap/unwrap operation (because I didn't actually have space to store 
> > them internally all the time).
> >
> > Given the current interactions of key policies in PKCS11, I can't 
> > actually ensure that a derived key remains sensitive, private and 
> > non-extractable - because even if I set the derived key as such when 
> > I derive it the first time, if an attacker can get access to USE the 
> > module and the derivation key, he can re-derive that derived key but 
> > set the sensitive, private and extractable bits in a way he can 
> > extract the key data.  That applies to both the KDFs and to key 
> > agreement models.
> >
> > Similar problems exist with the key wrapping model.
> >
> > Mike
> >
> >
> >
> > > I guess it has to be an HSM in the network where application would 
> > > call this HSM's PKCS#11 API remotely...
> > >
> > > Best,
> > > Oscar
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that 
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php