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

["Oscar K So Jr." <oscar.so@oracle.com>]

Hi Michael,


On 08/ 7/13 10:49 AM, Michael StJohns wrote:
> Hi Oscar
>
> On 8/6/2013 7:47 PM, Oscar K So Jr. wrote:
> > Michael,
> >
> > Here is my thinking.....
> > In addition to all of your proposed solution, would a signed 
> > application with authenticated PKCS#11 API calls work ?
> >
> > I got this idea from the CK_JAVA_MIDP_SECURITY_DOMAIN attribute.
> >
> > This attribute has ONE of the following values:
> > DOMAIN_UNSPECIFIED (i.e. unsigned application)
> > DOMAIN_MANUFACTURER (i.e. Apple iPhone)
> > DOMAIN_OPERATOR (i.e. AT&T phone company)
> > DOMAIN_THIRD_PARTY (i.e. developer like you and me)
> > The value refer to the signer of the certificate of the application.
> > If we determine a group of PKCS#11 API calls which can only be called 
> > or accessed if the application is signed by a trusted Root CA, we can 
> > limit the attacker from calling these PKCS#11 API(s) even the 
> > attacker knows the password of CKU_USER. The attacker's application 
> > is not signed, and therefore, access denied.
>
> I think what you're suggesting is some sort of stronger authentication 
> for PKCS11 than just PINs.  I started to sketch out something like 
> this, but decided it was definitely a 3.0 or later set of changes.
Definitely, after 3.0.

> 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...!!!


>   Do a C_Login with the signature over that challenge as well as an 
> identifier to indicate which of the identities (e.g public keys or 
> certs) that the token has that should be used to verify the signature.
>
> Other approaches may be possible as well without perturbing the 
> current API too much.
>
> > Anyway, I would be scared to learn that an attacker has already 
> > gotten control of my HSM, decrypted all of my information, and backed 
> > it up somewhere. Do you have such experience in the past ?
>
> That's not actually the problem I'm trying to solve.  PKCS11 has 
> reasonably good protections for what I call primary keys - keys that 
> are generated on the HSM or loaded explicitly.  They can have the 
> appropriate CKA_PRIVATE and CKA_SENSITIVE and CKA_EXTRACTABLE values 
> set in a manner that I'm pretty sure they can't be extracted.
>
> It's the secondary keys that are bothering me

Question: are the secondary keys wrapped with the primary key ?

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.

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


--

Best,
Oscar