From the background, we can see that there are 3 basic types of One-Time-Password (OTP).
Mathematical Algorithm Type
Time-Synchronized Type
Challenge Type
Now I'm going to address these in reverse order because I believe the second two have significant issues that would make them undesirable for our purposes.
Challenge OTP require that the user provide a series of Challenges and Responses to use for verification. The Challenges can be as simple as "What is your pets name?" or "What team won the 1968 World Series?". Now the user needs to provide quite a few of these so that when one is selected randomly from the list, it doesn't repeat too often and become obvious.
Challenge OTP won't work for us because we have to store all of the verification information in the /boot/initrd.img unencrypted. So if you lost your USB flash thumb drive, someone could loopback mount the initrd.img and gain access to the full list of Challenges and Responses. Or if you did encrypt it, you would have to leave the key for the encryption somewhere in the initrd.img filesystem or have the user enter it in addition to the Challenge/Response. Getting too cumbersome to be practical.
Time-Synchronized OTP has been pushed by companies like RSA, and has many uses. It basically works by requiring each user to carry a hardware token that gives a rotating "key" that changes with time (generally rotates every few seconds). So the user would enter his username & password then be prompted for the "key" from the token. If the "key" you provide matches what the system calculates itself then it lets you in.
While this is much better than just a simple password, it has a couple of flaws for our use. First, we can't always be sure that the system we're booting into has the correct time set in the BIOS. Without that the system will never calculate the same value that the hardware token will. Second, the hardware token becomes a second item to lose (the USB flash thumb drive is the first for our use) so most people would store them together. Maybe even on the same keychain. Which means if you lose your USB flash thumb drive, then you lose your hardware token with it, completely destroying any value of using it.
Mathematical Algorithm OTP works by calculating a password based on a mathematical formula. For example, a user might have a base password of "Password" and the mathematical formula was "day of the month" so on the first of the month the user would enter "Password01" for his password and "Password02" on the second. Generally the more complicated the formula the better. However if its too complicated then the user will need a hardware token to calculate it. So for our purposes, we need to keep the formula relatively simple so that it can be worked in your head. Something like (Day-of-month[1-31] * Month-of-Year[1-12] / Day-of-Week[1-7]) rounded to 2 decimal places. So on January 1, 2007 the password would be "Password1.00" and on February 1, 2007 the password would be "Password0.67".
Now to implement this for a DM-Crypt mounted partition like we use, we need to create a custom /etc/initramfs-tools/scripts/local-top/cryptroot script. The basic format for this script can be copied from /usr/share/initramfs-tools/scripts/local-top/cryptroot. Our Automated Installer currently creates a custom version of this script to add a 5 second delay for USB devices to be detected. If you look in that file, you will see a section of code that looks like:
if [ -n "$cryptkeyscript" ]; then
if [ ! -x "$cryptkeyscript" ]; then
echo "cryptsetup: error - $cryptkeyscript missing"
return 1
fi
$cryptkeyscript $cryptkey < /dev/console | $cryptcreate --key-file=-
else
$cryptcreate < /dev/console
fi
Now by creating and defining our own cryptkeyscript, we can add in our own password handling function. I haven't seen an example of a cryptkeyscript so I do not have one handy to show you but it is a bash script so it should be relatively easy to implement.
However, lets say we did. Does this increase our security significantly? I don't think so because the cryptkeyscript is unencrypted within the /boot/initrd.img filesystem so an attacker could figure out that portion and the only security left is how good the base password is.
Of course if I've missed anything I'm sure someone will chime in with corrections....
re: one-time passwords???
Short Answer:
Yes its possible and not very difficult.
Mkinitramfs from Initramfs-Tools is build on a modular structure so you can replace parts as you want.
Long Answer:
Wikipedia: One-Time-Passwords
From the background, we can see that there are 3 basic types of One-Time-Password (OTP).
Now I'm going to address these in reverse order because I believe the second two have significant issues that would make them undesirable for our purposes.
Challenge OTP require that the user provide a series of Challenges and Responses to use for verification. The Challenges can be as simple as "What is your pets name?" or "What team won the 1968 World Series?". Now the user needs to provide quite a few of these so that when one is selected randomly from the list, it doesn't repeat too often and become obvious.
Challenge OTP won't work for us because we have to store all of the verification information in the /boot/initrd.img unencrypted. So if you lost your USB flash thumb drive, someone could loopback mount the initrd.img and gain access to the full list of Challenges and Responses. Or if you did encrypt it, you would have to leave the key for the encryption somewhere in the initrd.img filesystem or have the user enter it in addition to the Challenge/Response. Getting too cumbersome to be practical.
Time-Synchronized OTP has been pushed by companies like RSA, and has many uses. It basically works by requiring each user to carry a hardware token that gives a rotating "key" that changes with time (generally rotates every few seconds). So the user would enter his username & password then be prompted for the "key" from the token. If the "key" you provide matches what the system calculates itself then it lets you in.
While this is much better than just a simple password, it has a couple of flaws for our use. First, we can't always be sure that the system we're booting into has the correct time set in the BIOS. Without that the system will never calculate the same value that the hardware token will. Second, the hardware token becomes a second item to lose (the USB flash thumb drive is the first for our use) so most people would store them together. Maybe even on the same keychain. Which means if you lose your USB flash thumb drive, then you lose your hardware token with it, completely destroying any value of using it.
Mathematical Algorithm OTP works by calculating a password based on a mathematical formula. For example, a user might have a base password of "Password" and the mathematical formula was "day of the month" so on the first of the month the user would enter "Password01" for his password and "Password02" on the second. Generally the more complicated the formula the better. However if its too complicated then the user will need a hardware token to calculate it. So for our purposes, we need to keep the formula relatively simple so that it can be worked in your head. Something like (Day-of-month[1-31] * Month-of-Year[1-12] / Day-of-Week[1-7]) rounded to 2 decimal places. So on January 1, 2007 the password would be "Password1.00" and on February 1, 2007 the password would be "Password0.67".
Now to implement this for a DM-Crypt mounted partition like we use, we need to create a custom /etc/initramfs-tools/scripts/local-top/cryptroot script. The basic format for this script can be copied from /usr/share/initramfs-tools/scripts/local-top/cryptroot. Our Automated Installer currently creates a custom version of this script to add a 5 second delay for USB devices to be detected. If you look in that file, you will see a section of code that looks like:
if [ -n "$cryptkeyscript" ]; then if [ ! -x "$cryptkeyscript" ]; then echo "cryptsetup: error - $cryptkeyscript missing" return 1 fi $cryptkeyscript $cryptkey < /dev/console | $cryptcreate --key-file=- else $cryptcreate < /dev/console fiNow by creating and defining our own cryptkeyscript, we can add in our own password handling function. I haven't seen an example of a cryptkeyscript so I do not have one handy to show you but it is a bash script so it should be relatively easy to implement.
However, lets say we did. Does this increase our security significantly? I don't think so because the cryptkeyscript is unencrypted within the /boot/initrd.img filesystem so an attacker could figure out that portion and the only security left is how good the base password is.
Of course if I've missed anything I'm sure someone will chime in with corrections....