OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Griffin, Robert
Sent: Mittwoch, 8. Januar 2014 12:44
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] FW: [pkcs11-comment] Secure data re-encryption

 

 

 

From: pkcs11-comment@lists.oasis-open.org [mailto:pkcs11-comment@lists.oasis-open.org] On Behalf Of Jaroslav Imrich
Sent: Donnerstag, 26. Dezember 2013 22:20
To: pkcs11-comment@lists.oasis-open.org
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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]