3

I would like to learn how to develop software leveraging PKI smart cards. Ideally, I would use Microsoft Base Smart Card CSP, but I really just need the ability to store symmetric and asymmetric keys on the card securely, and to perform the associated functions, no matter the software requirements. I need the ability to write keys, and to encrypt/decrypt/sign/verify on the card. This should mean a writer, a card, and an SDK. It would be nice if the cards support ECC secp256k1, ECDSA, RSA 4096, AES, SHA256, etc... but I need to start somewhere.

I have following questions regarding smart card security:

  1. Are smart card readers typically also capable of writing to the card, or performing whatever administrative functions supported by the card? Or do I need a specific interface (software or hardware) for writing to a smart card.
  2. Do I need to be looking specifically for a cryptographic smart card, or do all cards support some cryptographic functions?
  3. It appears that there are differing contact patterns on different cards. Are there any competing standards for smart card security? I found ISO 7816, but no others.
  • 2
    Normally you don't write a key to the card. Instead the card generates a public/private key pair, and you can read the public key. The private key never leaves the card. – paj28 Sep 27 '15 at 4:35
  • Very cool, I did not know that, but it certainly makes sense. What about symmetric keys? – Smack Jack Sep 27 '15 at 5:20
  • There are variations of cards which will store data. – M15K Sep 30 '15 at 12:43
  • 1
    There is no such thing as a smart card "writer". A smart card "reader" is simply a device that sends APDUs (commands) to the card and gets the response, kinda like a network interface. Any writing would be done by the card's own software running on it. – André Borie Dec 27 '15 at 23:58
1

Have you ever built any PKI infrastructure before? The technical details are only a part of the story with PKI, some of the most important details are in the policies and procedures generated to support this system.

I can understand wanting to dive in and experience the technical aspect. I would recommend creating at least a two-tiered PKI with something like OpenSSL or even experimenting with GPG, since they are low barrier to entry. If you are really wanted to gain more experience with the Microsoft stack the Windows Server 2008 PKI and Certificate Security were an invaluable resource for me when I setup my first Windows based PKI.

The Federal Public Key Infrastructure guidelines are a great exercise in seeing how the policy side should look from a sideways glance. WARNING Do not try to emulate these too closely as it is turtles all the way down.

Once you understand how it is all put together you are really setting yourself up for steamrolling smart cards. Personally, I've always wanted to try to the ones which keep a portion of the application on the card to see how it actually works performance wise in a real environment.

That aside, I'm just a guy on the Internet and I would encourage you to follow your passion. Just keep in mind, there is a reason why PKI deployments command a high price.

  • All I need is hardware security for private and/or symmetric keys. Performing PKI in software, and how PKI works is not a concern. I guess this is the wrong place to be asking these questions. – Smack Jack Sep 28 '15 at 20:07
1

There are a lot of things that come into play when we deal with smartcard integration with PKI.

Keypair generation

A keypair may be generated outside the smartcard and later on stored on it. There are some thing that might be taken into consideration here:

  • What is the entropy used in generating the private key?
  • What happens with the private key that you generated outside the smartcard?

If you generate the keypair from inside the smartcard, you would not have to worry with any of these problems outlined above.

Cryptographic Operations

In order to make your smartcard usable with cryptographic available applications, you need to make it compliant with PKCS #11, which is a standard for interaction with "cryptographic tokens". Among other things, it determines a high level API between applications and these tokens (in our case, a smartcard) to use it for a wide range of cryptographic operations:

  • Encrypt
  • Decrypt
  • Sign
  • Verify signature
  • Wrap Key
  • Generate Keypair

See ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf for the whole list

If you focus first on PKCS #11, you will abstract the fact that you are dealing with a smartcard, but with a "cryptographic token" that supports a set of operations.

Now, to answer your questions:

  1. The name smartcard reader is misleading. What the smartcard reader does is send APDUs to the interface and expect responses. These APDUs may be either read or write commands;
  2. If what you want is play with PKI, then I would strongly suggest PKCS #11 smartcards. You would only have to interact with a high level API instead of low-level APDUs;
  3. The most widely adopted standard for contact smartcards is indeed ISO 7816. I am not aware of any other one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.