One Time Pads: The new authentication model of pam_usb
By scox on Sunday, April 8 2007, 22:46 - security - Permalink
The way pam_usb performed authentication was inspired by smartcards: a private key was stored inside the device and the public part of the key inside the computer. The problem is that, unlike smartcards, the content of a USB device is readable meaning that the private key could be stolen by anyone borrowing your flash drive. Sure, the device is also identified by its manufacturer attributes (serial number and alike), but I'm pretty much sure those informations can be forged.
Knowing that the content of the USB device is unreliable (as it can be stolen), I came up with a different approach for authenticating a device called One Time Pads authentication. Basically, a pad is just a bunch of random bytes stored on both the USB device and the computer. Every time you authenticate, those pads are compared. If they match, access is granted and the pads are regenerated, otherwise access is denied.
This means that even if someone manages to fake your device's manufacturer attributes and to steal your pads, as soon as you authenticate the pads will be regenerated, making the one they have stolen invalid.It's like having a very long random generated one time password, except the fact you don't have to remember such password.
Let's see one time pads in action:
- First, just as our attacker, we start by stealing our own pad:
scox@helium ~ $ cp /media/disk/.pamusb/root.helium.pad /tmp- Then we authenticate. As you can see, the pads are verified, then updated:
scox@helium ~ $ su
* pam_usb vSVN
* Authentication request for user "root" (su)
* Device "sandisk" is connected (good).
* Performing one time pad verification...
* Verification match, updating one time pads...
* Access granted.- Now we are the attacker. We start by putting the stolen pad back into a device (assuming the device has the same serial number as ours) and try to authenticate:
scox@helium ~ $ cp /tmp/root.helium.pad /media/disk/.pamusb/
scox@helium ~ $ su
* pam_usb vSVN
* Authentication request for user "root" (su)
* Device "sandisk" is connected (good).
* Performing one time pad verification...
* Pad checking failed !
* Access denied.
Password: It may not be the safest authentication ever, but it's cheap (everyone has a USB flash drive nowadays), pretty much secure for common usage and avoids the hassle of remembering and typing passwords.I'll be releasing pam_usb 0.4.0 which contains one time pads authentication in the next few days, so stay tuned.
Comments
What happens if the attacker is the first one to autheniticate ? Imangine the following timeline:
As the pads won't match anymore, you will know that you have been compromised and you will be prompted for your usual password.
You can avoid this kind of problem by using two-factor authentication. In such case, you will be asked for a password before the USB authentication, which means that the attacker must know your password in order to update the pads.
Use 2 sticks. One holding the One Time Pad authentication and the other as a "Mold". Make the One Time Pad authentication time sensitive (really expiring after 2 minutes or 5 hours or 6 weeks) after which you can only use the "mold" together with the other usb stick to login. Both used seperate are useless (after expiration of the One Time Pad). Store them on different locations and you have your solution.
If flash drives are unique why not use that and store the One Time Pad on de hdd. Then there would be nothing to copy. The One Time Pad would still have to work as I wrote above. It still needs to expire.
I don't think pads should ever expire. Actually, they already do: as soon as you authenticate, the old pad isn't valid anymore.
I didn't understand the second comment about storing pads on the hard drive as they currently do. Pads are stored both on the flash drive and the hard drive and compared upon authentication.
I think it's a good project and I just got carried away by my enthousiasme.Forget about my second comment. It wasn't well thought out. Using just the flash drives unique ID to login (the pad on the hdd would be compared with just the unique ID on that flash drive) would make you loose a lot of flexibility.Looking forward to your next release.
Isn't writing one-time pad onto USB flash disk upon each authentication going to shorten its lifetime? And by how much, any estimates or experiences? I have been using old pam_usb 3.3 for some time now, had been happy with it, and now I am reluctant to upgrade given this sole issue. Please advise. Thank you.
I meant 0.3.3, sorry.
I assume it will shorten its lifetime, but i don't know how much. Anyway, I'm planning to introduce a new option to set how often pads should be updated (e.g., limit once everyday).
In the meantime, you could disable pads. I think pam_usb 0.4.x is more secure than 0.3.x even with pads disabled, because it does model/vendor/serial verification.
Variations on two-factor auth; How about, as with ssh key-based authentication, the /private/ key is locked with a password? or similarly the public copy of a pad may be password-encrypted.
That's two factor authentication which can already be achieved by coupling pamusb and pamunix in the PAM configuration.
It would be better to have a mix of the two methods: an ssl key together with pads. You see, not every single USB key out there has a serial number. Mine doesn't, and anybody who has a key of the same model could potentially forge the authentication.
Another thing you don't specify anywhere in the documentation, is if the authentication is restricted on localhost, or if it's available even to remote connections. I'd hate somebody logging in to my SSH as root without even bothering entering a password :) Please don't tell me to use SSL keys on ssh, I already do, but I found the example intriguing: just think about how many novice users intall every package on their distro and connect to the 'net without a proper firewall.
Even if someone has the same model as yours wouldn't have the same pads thus will be rejected in the authentication process.
My bad, I should've specified this in the documentation: the authentication is restricted to localhost. SSH won't authenticate someone through pam_usb. Even issueing commands such as "su" through SSH will ask for a passwod.
pam_usb assumes the existence of pmount on the system, but pmount is not listed in the requirements. Maybe you could correct that, and since pmount is nonstandard on many distributions, maybe you can find a way to replace it?
Fixed the documentation.
I'll try to find a way not to depend on pmount anymore, but the problem is mounting a volume requires root privilegies which will fail with screensavers and other applications running as user (and that's when pmount comes handy).
Good job!thank you Scox!
So say I manage to kill my one-time-pad accidentally. How do I force regenerating a new one?