I really need to read the private key in order to export it to another device.
But when I try to do so I get:
pkcs11-tool.exe --read-object --type privkey --id 01 -l --pin XXXXXX
Using slot 0 with a present token (0x0)
sorry, reading private keys not (yet) supported
I guess so this is possible, and someday this will be addressed.
I see that this is casted here:
Any idea when this will be possible?
Don't expect this to happen soon. Most likely your token doesn't support export of a private key and most definitely there's currently nobody looking into implementing this for your card.
Hi @frankmorgner, why did you put this on close?
About the token: this is not a matter of having a token that don't support read.
This is not a token or card specific Issue. This is a software 'missing feature'.
Please see the code. It's just empty for this function:
/* TODO: -DEE should look at object class, and get appropriate values
* based on the object, and other attributes. For example EC keys do
* not have a VALUE But have a EC_POINT. DvO: done for RSA and EC public keys.
*/
if (clazz == CKO_PRIVATE_KEY) {
fprintf(stderr, "sorry, reading private keys not (yet) supported\n");
return 0;
}
Here is a matter that this feature is not yet coded and the code has a big "TODO" comment in it with even some tips about how to.
No sane token would allow exporting a private key - that's the whole point of using a token rather than just keeping the key somewhere on your disk.
If you generated a key on a token, and then want it copied somewhere else - you're out of luck, because that's one of the use cases that the tokens were supposed to prevent, not enable.
Perhaps the code should be edited to reflect this fact?
P.S. If you are aware of any token that allows exporting a private key - please do post here (I want to make sure I never buy it ;).
P.P.S. Some tokens (HSM, usually) allow exporting a private key wrapped with symmetric or asymmetric encryption (that's what I hoped to see in the C_WrapKey PR).
@frankmorgner you marked this issue as "help wanted". Do you really want help implementing something that all of the tokens I know of can't physically do (by design)?
The SmartCard-HSM allows exporting key material encrypted under a Device Key Encryption Key that needs to be defined when the device is initialized. You can then create an encrypted key backup or migrate keys from one device to another.
The functionality is part of OpenSC, provided by the sc-hsm-tool.
Handling key material in plain is a bad idea, as it defeats the purpose of using a token where key material is physically protected and access is controlled.
It is possible to implement key export in a reasonable way. If @maxcuttins implements this for PKCS#11 (or pkcs11-tool), I'm happy to review his pull request.
@maxcuttins what information is missing to you (i.e. why do you want to keep this issue open)?
The SmartCard-HSM allows exporting key material encrypted under a Device Key Encryption Key that needs to be defined when the device is initialized. You can then create an encrypted key backup or migrate keys from one device to another.
The functionality is part of OpenSC, provided by the sc-hsm-tool.
Handling key material in plain is a bad idea, as it defeats the purpose of using a token where key material is physically protected and access is controlled.
Well, this is exactly the reason behind my intention of read the key: I need to export to a virtual device.
At the very beginning my first intention was just export and convert the certificate in order to incorporate it directly in a signing application software. However use a virtual pkcs11 device seems even as good as well. I was reading about OpenCryptoky and softHSM few minutes ago.
However it's not clear to me how to accomplish the export of the key from the smartcard in order to virtualize them as far as I cannot access to those keys.
Any hints?
No sane token would allow _exporting_ a private key - that's the whole point of using a token rather than just keeping the key somewhere on your disk.
If you generated a key on a token, and then want it copied somewhere else - you're out of luck, because that's one of the use cases that the tokens were supposed to _prevent_, _not_ enable.
Ok ok, I see the point.
Perhaps the code should be edited to reflect this fact?
I think so, right now it seems that the feature is missing, while as far as I understand it's just not feasable.
P.S. If you are aware of _any_ token that allows exporting a private key - please do post here (I want to make sure I never buy it ;).
ahahahahaha ok ok ok :D
We I wrote that TODO comment. As others have said its not likely to be done.
If you have such a token and PKCS11 module you can submit PR to
pkcs11-tool or call PKCS11 from your own program. The info you want are
attributes of the private key object.
The vendor of such a token may have a utility to do what you want.
On Oct 31, 2018 12:06 PM, "Massimiliano Cuttini" notifications@github.com
wrote:
Hi @frankmorgner https://github.com/frankmorgner, why did you put this on
close?
About the token: this is not a matter of having a token that don't support
read.
This is not a token or card specific Issue. This is a software 'missing
feature'.
Please see the code. It's just empty for this function:
/* TODO: -DEE should look at object class, and get appropriate values
Here is a matter that this feature is not yet coded and the code has a big
"TODO" comment in it with even some tips about how to.
ā
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-434804568, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MeYznLPv00FN3XYPTxc7ohCasn6qks5uqfSjgaJpZM4YEiYL
.
@dengert: If you have such a token...
@frankmorgner: It is possible to implement key export in a reasonable way...
As I pointed out earlier, and was confirmed by @CardContact, the only tokens that may have this capability are HSM. SmartCard-HSM and YubiHSM2 are two examples I'm aware of. And even they do not allow export of a private key unless it is "wrapped", aka encrypted with a key that's either pre-defined (SmartCard-HSM) or specified (referred to) via a command parameter (YubiHSM2).
So, unless the token in question is an HSM - I stand by my statement that there is no "normal" token (like Yubikey, or CAC card, or a national eID card, or...) that would allow exporting an unencrypted private key, or provide capabilities for exporting encrypted private key.
The vendor of such a token may have a utility to do what you want.
Exactly - as we see for both SmartCard-HSM (sc-hsm-tool) and YubiHSM2 (yubihsm-shell).
Ok.
So my possibility to success in this operation is to make exactly the opposite.
Instead of try to read the private key, I need a new one to put in a virtual-HSM, I can export across my servers.
I have just installed softHSM and openSC and they start to talk.
pkcs11-tool --module /usr/lib64/libsofthsm2.so -l -t
Using slot 0 with a present token (0x0)
Logging in to "My token 1".
Please enter User PIN:
C_SeedRandom() and C_GenerateRandom():
seems to be OK
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
Signatures: not implemented
Verify (currently only for RSA)
No private key found for testing
Unwrap: not implemented
Decryption (currently only for RSA)
No errors
Now, it's not clear to me how I can download the privkey directly in the device from the provider.
Especially because all provider allow to renew or update new keys only by installing their own software.
So... probably I'm gonna hit a wall.
If you are going to put them into your servers (I assume not on a smart
card or hardware protected device) your security will depend on the
servers' security and its file system etc. And if all the servers have the
same key, one compromised server compromises all. Consider each server
havibg its own key.
This sounds the same as a web server and could use software generated keys.
i.e. OpenSSL.
You might want to look at hardware as suggested by others that can wrap a
key on the card and give you a wraped version to load in to another
hardware device. I believe Smartcard-HSM can do this.
Or if each server has its own key on a card so noneed to transport a key.
But card can fail so have a plan to issue new key on ney card fo a server.
The above is all standard PKI used by SSL/TLS, ssh, AD and others.
On Thu, Nov 1, 2018, 9:42 AM Massimiliano Cuttini <[email protected]
wrote:
Ok.
So my possibility to success in this operation is to make exactly the
opposite.
Instead of try to read the private key, I need a new one to put in a
virtual-HSM, I can export across my servers.I have just installed softHSM and openSC and they start to talk.
pkcs11-tool --module /usr/lib64/libsofthsm2.so -l -t
Using slot 0 with a present token (0x0)
Logging in to "My token 1".
Please enter User PIN:
C_SeedRandom() and C_GenerateRandom():
seems to be OK
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
Signatures: not implemented
Verify (currently only for RSA)
No private key found for testing
Unwrap: not implemented
Decryption (currently only for RSA)
No errorsNow, it's not clear to me how I can download the privkey directly in the
device from the provider.
Especially because all provider allow to renew or update new keys only by
installing their own software.
So... probably I'm gonna hit a wall.ā
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-435099356, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MTzFEymmZsAdhIPnGXEBfdNxbvUqks5uqySFgaJpZM4YEiYL
.
With the SmartCard-HSM we are currently working on an even smarter key management scheme.
Rather than having a Device Key Encryption Key shared between devices, you can create what we call a key domain. A key domain is a group of SmartCard-HSMs for which the device authentication public key has been certified by a group signer. The group signer attests, that a device is a member of the group and each device can valid it's peers attestation. That way you can establish mutual ephemeral key encryption keys between peers (using ECDH and CVCs) and use them to exchange key material.
The scheme provides for forward and backward secrecy and has been designed for an application that requires the generation and distribution of symmetric group keys for a group VPN.
If you are going to put them into your servers (I assume not on a smart card or hardware protected device) your security will depend on the servers' security and its file system etc.
Of course!
And if all the servers have the same key, one compromised server compromises all.
Not all the server will have this key. I need to replicate in order to have backup and high-availability.
Consider each server havibg its own key. This sounds the same as a web server and could use software generated keys. i.e. OpenSSL. You might want to look at hardware as suggested by others that can wrap a key on the card and give you a wraped version to load in to another hardware device.
No, it's not a web server, the only service will run this server is a bash script to "sign request" and it'll be access only by local connection with SSH. I need to duplicate this server across different datacenter as this server will not be exposed online. I just need to export/copy the keys. If I need to replicate all the pkcs11 environment this will not be an issue thanks to virtual HSM.
Of course I cannot plug a real SmartCard in all datacenter that we have.
This will be insane.
However... I guess that I'm not gonna to persuade my key provider to load its key on my virtual device. This is the real big issue right now. So I guess I'm working on a 'dream'
For a software only you may want to look a
https://github.com/opendnssec/SoftHSMv2
On Fri, Nov 2, 2018 at 4:50 AM Massimiliano Cuttini <
[email protected]> wrote:
If you are going to put them into your servers (I assume not on a smart
card or hardware protected device) your security will depend on the
servers' security and its file system etc.Of course!
And if all the servers have the same key, one compromised server
compromises all.Not all the server will have this key. I need to replicate in order to
have backup and high-availability.Consider each server havibg its own key. This sounds the same as a web
server and could use software generated keys. i.e. OpenSSL. You might want
to look at hardware as suggested by others that can wrap a key on the card
and give you a wraped version to load in to another hardware device.No, it's not a web server, the only service will run this server is a bash
script to "sign request" and it'll be access only by local connection with
SSH. I need to duplicate this server across different datacenter as this
server will not be exposed online. I just need to export/copy the keys. If
I need to replicate all the pkcs11 environment this will not be an issue
thanks to virtual HSM.Of course I cannot plug a real SmartCard in all datacenter that we have.
This will be insane.However... I guess that I'm not gonna to persuade my key provider to load
its key on my virtual device. This is the real big issue right now. So I
guess I'm working on a 'dream'ā
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-435326204, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MRMgzCbF0rQE66ulQjdbgpR0661Mks5urBVOgaJpZM4YEiYL
.
For a software only you may want to look a https://github.com/opendnssec/SoftHSMv2
ā¦
And this is exaclty what I did.
I already wrote this in this thread.
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-435099356
Well,
i have just read more about smartcards.
I always thought they were dummy flash cards. Instead they are really smart devices carring a chip onboard that have some application that are used to execute actions without need to share keys contained on the card.
So, this open to the possibility that every provider have it's own closed cards with ready-to-sign-application on-board that are responsible for signing and for renew certificates only for it's own provider. This means also that it's possibile also that these smartcards work ONLY if they are paired with the signing software you have to download from the provider website.
From this point of view, did someone know if the smartcards carry an open standard in signing, or if every provider carry it's own way to 'sign' documents with specific application on board that can be called only by closed provider software?
That is the purpose of APIs like PKCS#11, CSP Minidriver oder TokenD: Provide an uniform abstraction of the smart cards functions in order to perform cryptographic operations independent of the card API.
On the lowest API level (the APDU level) few standards exist (some ISO7816 stuff, PIV, eSignK, BSI TRs), but they are mostly geared towards specific (but potentially large) applications.
On the next higher layer (i.e. the PKCS#11 layer), keys, certificates and crypto operations are abstracted from the actual implementation on the smart card. Typically applications (like Firefox, Thunderbird, LibreOffice, XCA) can interact with the smart card via these interfaces and e.g. PKCS#11 defines the way to enumerate objects on the card, handle authentication and sessions as well as perform signing or encryption operations.
Think of a smart card as a separate computer with a very thin (and therefore robust and secure) communication interface. Key material never leaves the chip and is very well protected from disclosure by physical means. All cryptographic operations are performed on the chip.
Pull request #1393 will add most of the functionality needed to wrap private keys using PKCS#11 C_WrapKey method. This means encrypting the key using another key inside the card and outputting the cryptogram. Because our card (MyEID) doesn't support wrapping with RSA keys yet (it can only wrap with AES keys), we haven't implemented everything needed yet. But not much is missing from that. Basically not much more than adding function pkcs15_prkey_wrap into framework-pkcs15.c. It would be very similar to pkcs15_skey_wrap. After that, if a card or token supports it, wrapping support could be added to its driver.
Of course wrapping a private key is only allowed, if the key has been explicitly marked as extractable when it was generated or imported. All cards that I know either mark private keys as non extractable by default or do not allow extracting private keys at all.
It sounds like you are asking how to sign almost anything. At the smartcard
level the card uses RSA or ECC to sign a small piece of data usually a hash
of the overall thing you want to sign.
Other software not on the card does the hashing. Examples of things to
sign:
CA creates a certificate from a certificate request and signs it using CA
key to add the signature to make a certificate.
Signed e-mail.
PDF is signed.
Word doc can be signed.
SSH session
Authentication SSL/TLS.
In all the above cases the same low level operation can be done by a
smartcard.
The IETF has many standard that use some form of a signature for example:
https://tools.ietf.org/html/rfc5652 is used in many of the above.
Many of these RFCs are based on the PKCS* from RSA inc.
See the IETF has the PKI working group page: https://tools.ietf.org/wg/pkix/
On Fri, Nov 2, 2018 at 8:32 AM Massimiliano Cuttini <
[email protected]> wrote:
Well,
i have just read more smart cards.
They are really smart card device carring a chip onboard that have a
limited number of application that are used to execute actions without need
to share info contained on the card.So, this open to the possibility that every provider have it's own cards
with ready-to-sign-application on-board that are responsible for signing
and for renew certificates only for it's own provider. This means also that
it's possibile also that these smartcards work only if they are paired with
the signing software you have to download from the provider website.From this point of view, did someone know if the smartcards carry an open
standard in signing or if every provider carry it's own way to 'sign'
documents with specific application on board?ā
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-435381180, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MV5yvmV7tsOuLJpkipcQpkk5kTRMks5urEligaJpZM4YEiYL
.
One cert provider ships you a blank token that needs to be plugged in when you go to their site to retrieve your certificate. It only works on IE, using ActiveX. The certificate with PK is downloaded and written to the token.
I imagine using Fiddler (or another packet capturing tool) would enable one to intercept the key when it is being sent to the token. Unless the token accepts an encrypted PK and decrypts it internally before storing it.
Most likely the card generates the private key on the card that never
leaves the card. The card signs a certificate request containing the
public key.
The request is sent to the web site that creates a certificate and signs it
with the CA key.
No privite key is sent either way. This is standard PKI.
On Sat, Nov 17, 2018, 11:24 AM gaia <[email protected] wrote:
One cert provider ships you a blank token that needs to be plugged in when
you go to their site to retrieve your certificate. It only works on IE,
using ActiveX. The certificate with PK is downloaded and written to the
token.I imagine using Fiddler (or another packet capturing tool) would enable
one to intercept the key when it is being sent to the token. Unless the
token accepts an encrypted PK and decrypts it internally before storing it.ā
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OpenSC/OpenSC/issues/1522#issuecomment-439632967, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA00MQJ_AeAHksGlXXaG-n7zysKZi2oTks5uwEY7gaJpZM4YEiYL
.
I can provide the code to wrap/unwrap key for RSA in opensc library, if you are interested in
You said your goal was: "However it's not clear to me how to accomplish the export of the key from the smartcard in order to virtualize them as far as I cannot access to those keys."
In my option, the weakest part in your security model is protecting the keys in the virtual machines. In other words creating the key in a smartcard then exporting does not improve your security.
You may want to look at other options. Googling for: key management virtual cloud shows a number of products, services, consultants and advise from cloud operators like Oracle, Google and Microsoft. And it also includes some smartcard hardware based solutions from Gemalto
You can also Google for NIST key management virtual cloud to get additional guidance.
Also look at: https://github.com/CardContact closer too.
@hajikhorasani: That would be great. Do you have cards that support this feature?
@hhonkanen I can provide the source code for using in a Java Applet to unwrap a wrapped private key on card, also the proper codes for opensc library.
But exporting the private key depends on many conditions and capabilities of the card (hardware, JCVM and JCRE) and the applet.
@hajikhorasani Sounds good. Could you make a pull request for the OpenSC code?
We are going to add support for unwrapping private keys to MyEID card at some point. Of course we cannot use your Javacard implementation directly, because there is lots of applet specific code, but I'm sure it would be useful to look at it. Would you like to publish that on Github too?
@hhonkanen Sure I can make a pull request. But there is an under-develop and not yet finished implementation code for wrapping and unwrapping keys in the OpenSC library. Thus if you have a repository for your applet, it's better to make a pull request there.
FYI I've implemented the Unwrapkey feature, in isoApplet and OpenSC.
And yes, I like to publish that on Github at right places and projects.
Closing this issue due to inactivity. Please re-open the ticket if more input is available.
AFAIK ruToken ECP can export private keys if they were imported manually (not generated on the token) and were marked as exportable when being imported.
You should contact the vendor to get more input on exporting the key. If you have this information, we're happy to take pull requests for OpenSC to implement this.
@hhonkanen I can provide the source code for using in a Java Applet to unwrap a wrapped private key on card, also the proper codes for opensc library.
But exporting the private key depends on many conditions and capabilities of the card (hardware, JCVM and JCRE) and the applet.
ok Please provide me the java code to extract the key then
Most helpful comment
Most likely the card generates the private key on the card that never
leaves the card. The card signs a certificate request containing the
public key.
The request is sent to the web site that creates a certificate and signs it
with the CA key.
No privite key is sent either way. This is standard PKI.
On Sat, Nov 17, 2018, 11:24 AM gaia <[email protected] wrote: