There was a recent discussion on Security Now about how nice it would be to have a Yubikey-like device that uses public key encryption to sign a provided string of text and thereby provide strong authentication without the need to share a secret key. Steve stated two problems: hardware limitations and driver problems. I don’t have a solution to the first problem, it’s up to somebody else to come up with a cheap USB device that can do public key encryption, but I think I have an idea for the second.

The cool thing about the Yubikey is that it shows up as a keyboard. It will work on any computer without the need to install drivers. But the keyboard driver is limited in its ability to receive data from the computer. There is, however, another widely available driver that does support two-way transfer: the Mass Storage Device.

Let’s say a company designs a USB flash drive that shows up on the computer with a number of folders: ’sign’, ‘encrypt’, ‘output’, for example. Copy a file into the ’sign’ folder, press a button on the drive, and a signed copy is placed in the ‘output’ folder. Now you have the ability to sign, encrypt, decrypt data on any computer. Encryption would require it to somehow manage public keys. Perhaps you could copy a file and a number (1+) of public keys to the ‘encrypt’ folder.

To use it as an authentication token:

1. A website provides you with a random string: “12345″
2. Copy it to a text file in the ’sign’ folder
   • To avoid replay attacks the URL should be appended or something
3. Press the button
4. Copy the contents of the signed result into a textarea (or upload it)

Of course, this could all be done automatically by an extension or the browser itself.

The important feature of this is it could be implemented now. It would not require the propagation of a new generic driver. The USB Mass Storage driver is available all the way back to Windows 98, default since XP, default since OS9, available in Linux since 2001. It is nearly as omnipresent as the keyboard driver. It also doesn’t make any assumptions about the algorithm used. There could exist PGP, S/MIME, symmetric key versions.

This is just a general sketch. I recognize some security concerns (malicious software could piggyback on the signing process to generate signed files). A more secure one might allow only one file to be written to the drive at a time, requiring user interaction to unlock it each time.

I have been thinking about the big deal in security at the moment: DNS spoofing. Everybody, it seems, is all caught up in trying to figure out how to add more bits. They want to make DNS replies harder to spoof.

It seems to me that they are missing the problem. The problem is the way DNS servers handle in-bailiwick additional records. If I request an NXDOMAIN from an ISP, I can be reasonable assured that a request will be made by the ISP to Google’s nameservers (which are probably already cached). I can then spam the ISP DNS server with fake replies hoping I stumble on the right combination of port and transaction ID. My replies will include a record for my NXDOMAIN and also an additional record giving new IP address for Google’s nameservers. From then on, the ISP will turn to my provided IP rather than Google. Eventually I can provide it with fake records for www.google.com and other useful subdomains.

My question: why should the ISP overwrite the information it has already cached? Additional records should be ignored unless they are needed for the current query (as in the case of glue).

I know this doesn’t prevent DNS spoofing, but it does significantly lower the value of the attack. You may be able to plant a record for as7230hf.google.com, but you won’t be able to overwrite their nameservers.

Maybe I’m missing something. Maybe there really is a critical reason to allow a nameserver to tell you that it isn’t where it is. But I don’t think so.