PKCS#11. Possibility of performing Ecryption/Decryption in hardware
Cheers. This is a copy of my question on crypto stack exchange.
I'm dealing with HSM via PKCS#11 C/Python interface. I'm wondering is it possible to do some C_Encrypt
/C_Decrypt
in hardware. By saying "in hardware" I mean encryption/decryption without exposing the result to the caller space. This is mostly aboud decryption as I want to call C_Decrypt
and leave the result inside the HSM as arbitrary data to do some other transformations on that data later, saying re-encrypting it on some other key. Thank you in advance.
encryption cryptography hardware pkcs#11
add a comment |
Cheers. This is a copy of my question on crypto stack exchange.
I'm dealing with HSM via PKCS#11 C/Python interface. I'm wondering is it possible to do some C_Encrypt
/C_Decrypt
in hardware. By saying "in hardware" I mean encryption/decryption without exposing the result to the caller space. This is mostly aboud decryption as I want to call C_Decrypt
and leave the result inside the HSM as arbitrary data to do some other transformations on that data later, saying re-encrypting it on some other key. Thank you in advance.
encryption cryptography hardware pkcs#11
add a comment |
Cheers. This is a copy of my question on crypto stack exchange.
I'm dealing with HSM via PKCS#11 C/Python interface. I'm wondering is it possible to do some C_Encrypt
/C_Decrypt
in hardware. By saying "in hardware" I mean encryption/decryption without exposing the result to the caller space. This is mostly aboud decryption as I want to call C_Decrypt
and leave the result inside the HSM as arbitrary data to do some other transformations on that data later, saying re-encrypting it on some other key. Thank you in advance.
encryption cryptography hardware pkcs#11
Cheers. This is a copy of my question on crypto stack exchange.
I'm dealing with HSM via PKCS#11 C/Python interface. I'm wondering is it possible to do some C_Encrypt
/C_Decrypt
in hardware. By saying "in hardware" I mean encryption/decryption without exposing the result to the caller space. This is mostly aboud decryption as I want to call C_Decrypt
and leave the result inside the HSM as arbitrary data to do some other transformations on that data later, saying re-encrypting it on some other key. Thank you in advance.
encryption cryptography hardware pkcs#11
encryption cryptography hardware pkcs#11
asked Nov 14 '18 at 10:24
Henadzi MatutsHenadzi Matuts
556
556
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.
BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯_(ツ)_/¯
but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D
.
My mail from 2013:
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 keyB
. What options does PKCS#11 API provide?
OPTION #1: Decrypt data with key
A
andC_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal
functions and then encrypt data with keyB
andC_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 keyB
as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducingC_DecryptEncryptUpdate
function with behavior similar toC_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?
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
add a comment |
No, PKCS#11
does not support what you need.
Nearest operation to your requirement is C_UnwrapKey
, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297923%2fpkcs11-possibility-of-performing-ecryption-decryption-in-hardware%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.
BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯_(ツ)_/¯
but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D
.
My mail from 2013:
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 keyB
. What options does PKCS#11 API provide?
OPTION #1: Decrypt data with key
A
andC_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal
functions and then encrypt data with keyB
andC_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 keyB
as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducingC_DecryptEncryptUpdate
function with behavior similar toC_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?
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
add a comment |
PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.
BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯_(ツ)_/¯
but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D
.
My mail from 2013:
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 keyB
. What options does PKCS#11 API provide?
OPTION #1: Decrypt data with key
A
andC_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal
functions and then encrypt data with keyB
andC_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 keyB
as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducingC_DecryptEncryptUpdate
function with behavior similar toC_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?
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
add a comment |
PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.
BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯_(ツ)_/¯
but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D
.
My mail from 2013:
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 keyB
. What options does PKCS#11 API provide?
OPTION #1: Decrypt data with key
A
andC_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal
functions and then encrypt data with keyB
andC_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 keyB
as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducingC_DecryptEncryptUpdate
function with behavior similar toC_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?
PKCS#11 does not provide such methods but certain HSM models allow you to extend their firmware with your own algorithms/mechanisms or even run your own application inside the device so there surely is a way to achieve what you want. Just not with PKCS#11 API.
BTW I've discussed exactly this scenario in pkcs11-comment mailing list of OASIS PKCS#11 Technical Committee back in 2013. Sadly I didn't receive any feedback ¯_(ツ)_/¯
but later when I wanted to join technical committee to work on this proposal I received pricelist with membership dues :D
.
My mail from 2013:
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 keyB
. What options does PKCS#11 API provide?
OPTION #1: Decrypt data with key
A
andC_DecryptInit/C_Decrypt/C_DecryptUpdate/C_DecryptFinal
functions and then encrypt data with keyB
andC_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 keyB
as an output. In other words it should decrypt and then encrypt data in one call. This can be achieved for example by introducingC_DecryptEncryptUpdate
function with behavior similar toC_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?
answered Nov 14 '18 at 23:18
jariqjariq
7,86322339
7,86322339
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
add a comment |
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
Wow. Thanks for your feedback. I hope they will introduce this king of scenario someday :)
– Henadzi Matuts
Nov 15 '18 at 7:59
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
As it looks like a pretty common case.
– Henadzi Matuts
Nov 15 '18 at 8:06
add a comment |
No, PKCS#11
does not support what you need.
Nearest operation to your requirement is C_UnwrapKey
, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
add a comment |
No, PKCS#11
does not support what you need.
Nearest operation to your requirement is C_UnwrapKey
, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
add a comment |
No, PKCS#11
does not support what you need.
Nearest operation to your requirement is C_UnwrapKey
, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.
No, PKCS#11
does not support what you need.
Nearest operation to your requirement is C_UnwrapKey
, which is used for creating a key object inside HSM using decrypting sent data using another key. But I don't think it satisfy your needs.
answered Nov 14 '18 at 12:05
AfshinAfshin
3,0811625
3,0811625
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
add a comment |
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
Yeah, I was looking about playing around with C_Unwrap. And I'ts the only option I have for now.
– Henadzi Matuts
Nov 15 '18 at 7:57
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297923%2fpkcs11-possibility-of-performing-ecryption-decryption-in-hardware%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown