Practice Cryptography!

We currently have 1-factor authentication (something you have) with our VISA and MasterCard debit cards for small purchases. Go into a Wendy's or a Jack In The Box, and pull out your VISA card, and they'll run it and hand it back, then hand you the receipt, no signature needed.

Banks (and the PIN-based systems) are two-factor authentication: you have the card, and you also know the PIN to the card. This is why 'smart cards' are so popular -- they're a means of authenticating authorizations to move money with two-factor authentication (credential and knowledge).

Some people have already come out with a means to get the knowledge out of the loop -- they use fingerprints to unlock the credentials (smart cards) which contain the e-banking capabilities. I'm not entirely sure this is a good idea, honestly, but I can see where it might be necessary.

But atop all of this, we have only one single credential that we can hand to someone else electronically, and prove that we have the secret information associated with that credential which proves that we (in a perfect world) are the owner of the credential in question. And we usually don't even have that -- the servers do, but the clients don't, or don't bother, or don't consider it useful, or the banks don't make it happen, or many other things.

So, we need to come up with a credential with a useful and easy user interface, that is secure enough to meet banking requirements. I'm thinking, for some reason, a USB thumb drive with cryptographic hardware built-in.

(Why USB? Well, let's see... all modern computers have it, where very few modern computers have smart card readers. Keyfobs are very easy to put on a keychain. USB devices are going down in price. USB devices aren't stuck in any given form factor. Imagine a calculator-looking thing that had a USB Type A male connector, ready to slot into a vendor's device with a type A female connector. Plug it in, negotiate prices, the user gets the "invoice" onto his own system, and then cryptographically signs it with a key that's known to the bank -- after unlocking the device with his own PIN. And it could double as a portable media player, too. :) )

In order to do this, though, we would need to define a USB standard for cryptographic operations to be performed by a token in a platform-independent fashion. (I'm thinking along the lines of the OpenSSL CRYPTO interface, but even that's not sufficient. PKCS#11 is DEFINITELY not sufficient. However, I'd advocate supporting both of those interfaces as well to get maximum market penetration.)

There are some new modes of encryption which allow for other information to be embedded into the message other than just the message itself, that these interfaces (when they were designed) didn't take into account. So, such a protocol would need to be extensible with a graceful fallback to an older protocol version if the application that's trying to use it doesn't have all the facilities it desires in the latest version of the protocol.

(Can you spot the flaw and pedantry in the above paragraph? :) )

I would much prefer that a specific set of capabilities be exported to the application in string form (CAN_CREATE_RSA1024, CAN_CREATE_RSA2048, CAN_STORE_CERTIFICATES, CAN_CREATE_CERTIFICATE_REQUESTS, etc). This would allow the stream ciphers to be separated from the block ciphers, and would allow the block ciphers to be separated from the asymmetric ciphers, and would allow all of them to be separated from the modes within which they can can be used -- logically separating all so that they can be queried individually, and the best match found.

I don't know. I'm not in a hardware-protocol creation mindset at this moment. Just some thoughts.