pkcs11 — archive

comments # 5 - FW: [pkcs11-comment] Secure data re-encryption

From: Robert Relyea <[email protected]>
To: [email protected]
Date: Wed, 22 Jan 2014 19:40:00 -0000

On 01/22/2014 04:57 AM, Griffin, Robert wrote: To be deferred to v3.0? I would think so. We already have an API to do what he wants for CSPs (namely keys) called wrap/unwrap. It's not clear it make sense for other objects (if you have permission to decrypt, doing the decrypt/encrypt in token doesn't buy you a lot). bob Regards, Bob From: [email protected] [ mailto:[email protected] ] On Behalf Of Griffin, Robert Sent: Mittwoch, 8. Januar 2014 12:44 To: [email protected] Subject: [pkcs11] FW: [pkcs11-comment] Secure data re-encryption From: [email protected] [ mailto:[email protected] ] On Behalf Of Jaroslav Imrich Sent: Donnerstag, 26. Dezember 2013 22:20 To: [email protected] Subject: [pkcs11-comment] Secure data re-encryption Hello all, I would like to open discussion about secure data re-encryption and the ways it can be handled with PKCS#11 API. Let's say there are some data encrypted with symmetric key A and for some reason (i.e. key life-time ended, encryption algorithm is not considered secure anymore etc.) there is a need to re-encrypt data with key B. What options does PKCS#11 API provide? OPTION #1: Decrypt data with key A and C_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal functions and then encrypt data with key B and C_EncryptInit/C_Encrypt/C_DecryptUpdate/C_DecryptFinal functions. Advantages: - uses current well known PKCS#11 API Disadvantages: - possible security issues - plaintext is unnecessarily exposed to the host memory - communication overhead - plaintext needs to be exchanged twice between cryptoki app and cryptoki module OPTION #2: Let's say new PKCS#11 function(s) for data re-encryption would be introduced. It should take ciphertext created with key A as an input and provide ciphertext created with key B as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducing C_DecryptEncryptUpdate function with behavior similar to C_DecryptVerifyUpdate (it would most likely have similar pipelining issues too). Advantages: - Eliminates disadvantages of OPTION #1: - decrypted plaintext does not need to be exposed to the host memory because implementation where plaintext never leaves secure device is possible - performance should be increased because 50% less data needs to be exchanged between cryptoki app and cryptoki module/device Disadvantages: - new method(s) need to be introduced in PKCS#11 API Personaly I would definitely like to see API for secure date re-encryption introduced. What are your opinions? Does anyone else miss API for secure data re-encryption? -- Kind Regards Jaroslav Imrich www.pkcs11interop.net Attachment: smime.p7s Description: S/MIME Cryptographic Signature