PKCS#11. Possibility of performing Ecryption/Decryption in hardware












4















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.










share|improve this question



























    4















    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.










    share|improve this question

























      4












      4








      4


      1






      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.










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 14 '18 at 10:24









      Henadzi MatutsHenadzi Matuts

      556




      556
























          2 Answers
          2






          active

          oldest

          votes


















          3














          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 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?







          share|improve this answer
























          • 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



















          3














          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.






          share|improve this answer
























          • 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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          3














          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 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?







          share|improve this answer
























          • 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
















          3














          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 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?







          share|improve this answer
























          • 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














          3












          3








          3







          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 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?







          share|improve this answer













          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 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?








          share|improve this answer












          share|improve this answer



          share|improve this answer










          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



















          • 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













          3














          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.






          share|improve this answer
























          • 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
















          3














          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.






          share|improve this answer
























          • 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














          3












          3








          3







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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



















          • 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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Bressuire

          Vorschmack

          Quarantine