scox.info - Random Thoughts

To content | To menu | To search

Tag - pam_usb

Entries feed - Comments feed

Saturday, September 15 2007

Yet another release of pam_usb

By scox on Saturday, September 15 2007, 01:24 - security

Just a quick blog entry to introduce you to the new version of pam_usb (0.4.2), which I've just released a few minutes ago.

This release focuses on bugfixes and small enhancements. Here's a non exhaustive list of them:

  • Better hardware support: Thanks to user feedback, a lot of improvements have been made in hardware support. Now devices without vendor and model informations can be used for authentication.
  • Support for non USB devices: You can now use every kind of removable storage devices, such as SD or MMC cards.
  • Reduced writing to the device: Pads aren't updated everytime you authenticate anymore, but (by default) only once an hour. This feature can be turned off by setting pads_expiration to 0, or you can adjust it to a more suitable value (2h, 10m etc are valid options).
  • Many other smaller bugfixes and features have been included, such as the DBUS workaround and support for Python 2.5.

I'd like to thank all the users who contributed by sending their feedback and patches.

4 comments one trackback

Monday, April 9 2007

pam_usb: Finally a new release

By scox on Monday, April 9 2007, 22:22 - security

After way too much time, I have finally released pam_usb 0.4.0.

For those of you not familiar with the project, it "provides hardware authentication for Linux using ordinary USB Flash Drives".Basically, it makes applications such as GDM/KDM, gnome-screensaver/kscreensaver, su/sudo and so forth authenticate users using a USB stick instead of askingfor a password over and over. If you're lazy like me, you'll appreciate it.

So, what's new with this release ? Well, everything. For starters, I've rewritten everything from scratch. It contains many new features,including one time pads authentication and support for hardware detection throughHAL.

I've also written a set of tools in Python:

  • pamusb-agent, a daemon that can trigger actions (such as locking the screen) upon device authentication and removal.
  • pamusb-conf, a tool that can save you the hassle of editing pamusb.conf by hand. As for now, it supports the --add-device and --add-user options.

The project has now a brand new website powered by the Dokuwiki wiki engine.I have also reworked the documentation as the old one seemed to scare people. Someday I'll probably do a screencast to show how to setup pam_usb in 5 minutes. Until then, have fun with the documentation :)

26 comments 166 trackbacks

Sunday, April 8 2007

One Time Pads: The new authentication model of pam_usb

By scox on Sunday, April 8 2007, 22:46 - security

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.

17 comments 25 trackbacks