If I have a cryptosystem built around PGP/GnuPG, I can keep my secrets safe by using an OpenPGP smart card and storing my private keys there. If I'm instead using DJB's NaCl, is there any sort of programmable smart card that I can use to store my private keys and also the NaCl code that operates on them?

I've read about Java Cards, but it seems that the only way to put your own code onto them was through the now defunct MUSCLE project, so that doesn't seem to be a viable approach. I'd love to heard that I'm wrong about this though, as it otherwise seemed promising.

My goal is ultimately to have some degree of trusted encryption on my cell phone (a BlackBerry 10, but a solution that works for Android and iPhone would be ideal), so I'm not tied to smart cards exactly, but just the idea of offloading the private key part of the encryption onto a trusted device. If there's some way to load NaCl onto a tiny linux device and talk to that from my blackberry through NFC, that would work too. All suggestions are welcome.

1 Answer 1


These days, Java Cards have competition: .NET Cards. The main principle is the same: user-provided code runs in a virtual machine hosted by the card itself. Your main problem will be of performance.

An important part of why such programmable cards are believed to be "secure" relies on this VM: the applicative code cannot escape the VM boundaries; for instance, it won't have a buffer overflow or be able to read or write arbitrary bytes in RAM. This feature comes at a heavy price: all the applicative code is interpreted. A smart card is already quite underpowered (a good smart card may feature, say, a 50 MHz ARM-like CPU) but the interpretation implies an additional slowdown factor of 10x or 20x, meaning that any cryptography you would like to perform on such a system will be slow as Hell.

To cope with that, these smart cards include hardware accelerators, i.e. native code and dedicated circuitry to do some specific operations, usually RSA. So such a card can still compute a 2048-bit RSA signature in less than a second, a performance which is quite a feat, given the hardware. But you won't have an accelerator for a not-yet-mainstream curves like the ones in NaCl -- you usually don't have accelerator for any curve at all.

Smart cards try to achieve tamper resistance: a secret stored in such a card should remain secret, even if it is stolen and the thief tries to pry it open. This kind of security tends to come at a heavy price. It may also be quite overkill in your case.

  • Do you have experience with the .NET cards? Can one write programs for them that will interact with a normal SmartCard reader? The page says that the card can support PKCS#11, so I assume that the answer is yes, but if you have first-hand experience with this, I'd like to hear about it.
    – tsuraan
    Commented Sep 20, 2013 at 21:03
  • I have not tried that specific feature yet, but as far as I understand, custom code works on APDU. PKCS#11 is higher-level than that, and deals only with crypto; the PKCS#11 library (the one provided by the card vendor) works by sending APDU to the card. With Windows, APDU can be sent with SCardTransmit() (from the system DLL winscard); on Linux, it seems that a PC/SC driver is to be used, e.g. from MUSCLE. Are you sure it is dead ? The mailing-list seems quite active.
    – Tom Leek
    Commented Sep 20, 2013 at 22:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .