Practice Cryptography!

RFID is the new electronic read-only chip that can contain arbitrary data, such as a palette number, content name, content SKU, amount on palette, and so on. It's designed to be used for inventorying and logistics.

Except.

RFID tags can be cloned by a device that reads them, then broadcasts on the same frequency that the RFID tag itself would be induced to broadcast on.

RFID tags can be arbitrarily coded by such a device to perform active attacks against systems that use them. (SQL injection attacks and buffer overflows are only two of the types of attacks that RFID systems have to be aware of.)

So, we can't use them for their intended purpose of unique identification... or can we?

Certainly not as they stand -- but if each individual RFID tag had a public/private keypair associated with it, and there was a key exchange with the reader before the RFID's tag was read (kinda like SSL/TLS), then there would be less opportunity for such problems.

[This entire discussion came about because I got into a discussion of people implanting RFID chips into their hands or such, and I know someone who has two canine identification tags (essentially the same) embedded in his back.]

I really hate to bring up politics in this discussion, but there's always some form of it tainting any attempt to bring encryption out into the open and actually discuss it.

"Let them listen to me. I have nothing to hide." Hmmmm.... so you acknowledge that there's this nebulous 'them' that will wiretap you 'for your own good', or 'in the interests of national security', you don't have any idea who they are, and you don't know their motives. What if, for example, someone who looked in on you decided they were going to use your identity to commit some fraud -- or decided that they didn't like you, and hired someone to come smack you or make your working life difficult (I'm actually pulling examples out of history, here, the J. Edgar Hoover and the McCarthy eras, and I'm sure probably a lot more that I don't have).

Oh, you also don't mind your bank statements and checks being sent through the mail without an envelope, for any one of "them" to read. After all... who's to say that your neighbor's not one of "them", and knows anyway?

In practice, encrypting a message (or a stream of bits and bytes) is like folding up a piece of paper and putting it into an envelope. Instead of everything going by for just anyone to read, now suddenly "they" have to work harder at it, doing their jobs like they're supposed to, picking and choosing their threats and obtaining permission from the courts to open the mail.

That is why I would prefer to use encryption for everything, and that is why I think it's LONG past time that we should have made it an integral part of everything. But we can't do that as it stands... because none of the standards work. None of the proposals work. Nothing really works, in the system that we have... and so, we need to make it work. I'll find a way to make it work, if I have to, if nobody reads what I write here. This is far, far too important of an issue to buck any further -- it's gotta stop, and it's gotta stop here.

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.