Hi everyone. I’ve been trying to get this to work for a while, not had any luck… I want to encrypt my /dev/sdb1 with a passphrase but store that passphrase info on a usb stick (/dev/sdc1), the idea being if that USB stick isn’t present then the partition can’t be decrypted.
How can I go about doing this?
Thanks!!!
By first telling us which version of openSUSE you use. And then please add if you want to do this from a GUI environment and when yes, which one you use (KDE, Gnome, other).
It’s 12.3, I use KDE but I’m totally at home in a bash shell… not afraid of the command line 
I do not have a ready solution, but will throw in a few remarks to keep you busy until other people come with good solution 
You should be prepared not to use /dev/sdb, etc, but to use their equivalents as /dev/disk/by-id. That will identify the disk/partition more certain even when the /dev/sdn notations change (can easily happen when you have another device added).
I guess the best solution is in using udev rules. So that is a bit of study to do
This might be an introduction: Writing udev rules
On 2013-08-01 16:46, philr5150 wrote:
>
> Hi everyone. I’ve been trying to get this to work for a while, not had
> any luck… I want to encrypt my /dev/sdb1 with a passphrase but store
> that passphrase info on a usb stick (/dev/sdc1), the idea being if that
> USB stick isn’t present then the partition can’t be decrypted.
>
> How can I go about doing this?
I have seen partial descriptions of using something similar, but not the
same: the partition is encrypted with a long key held in a usb stick,
and a passphrase you type. The thief needs both to steal your data.
If you have a look at cryptsetup(8), section luksOpen, we read:
luksOpen <device> <name>
Opens the LUKS device <device> and sets up a map-
ping <name> after successful verification of the
supplied passphrase. If the passphrase is not
supplied via --key-file, the command prompts for
it interactively.
The <device> parameter can be also specified by
LUKS UUID in the format UUID=<uuid>, which uses
the symlinks in /dev/disk/by-uuid.
<options> can be --key-file, --keyfile-offset,
--keyfile-size, --readonly, --test-passphrase,
--allow-discards, --header, --key-slot, --master-
key-file].
Thus, the passphrase can be entered via “–key-file”, which is what you
want. You would have to mount it manually, though.
I have a set of scripts to access encrypted partitions, which maybe you
could adapt for use with --key-file. I do not know if the keyfile can be
supplied in the configuration files, perhaps. I should have a look at it.
But I do not see how to implement what I mentioned in my first
paragraph. :-?
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Hi Carlos.
I did have something like this working under Gentoo, however there was a timing issue with regard to mounting the USB stick so the key file could be read, accessing the encrypted drive and then mounting the encrypted drive. I’d always end up taking /home out of fstab and just mounting it manually after boot. Hadn’t thought of using UDEV (mainly because I know nothing about it )
It may not be possible to do what I want. The scenario you describe is exactly what I want to achieve though… at least I can trash the partition as I need until I get it working, it’s empty right now so no data to lose
Thanks!
On 2013-08-02 16:06, philr5150 wrote:
>
> Hi Carlos.
> I did have something like this working under Gentoo, however there was
> a timing issue with regard to mounting the USB stick so the key file
> could be read, accessing the encrypted drive and then mounting the
> encrypted drive. I’d always end up taking /home out of fstab and just
> mounting it manually after boot. Hadn’t thought of using UDEV (mainly
> because I know nothing about it )
>
> It may not be possible to do what I want. The scenario you describe is
> exactly what I want to achieve though… at least I can trash the
> partition as I need until I get it working, it’s empty right now so no
> data to lose
It also interests me, as something I want to know. But I would have to
create a test system somewhere to find out.
As to fstab, that’s doable but tricky. You can use “nofail” to delay
mounting. But then you need to log in as root to trigger the mounting
script, unless pam or something triggers it for you. I’m not familiar
with udev either.
Perhaps an ID card with a chip would be more interesting than an usb
stick. But I have never worked with them.
And, what really interests me is external file plus keyboard key.
Temporarily, you could use encrypted home with passphrase instead.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
Yeah, I’m really not sure this can be done the way I want.
What I’m looking for, ultimately, is this:
I have a USB stick in the USB port in my monitor. That gets mounted as /dev/sdc1.
The USB stick contains a file which holds the decryption key for /dev/sdb1.
During boot, the stick mounts, the key-file is read and passed to the “Enter passphrase” prompt (or some other mechanism, but whatever, it’s automatic).
/home mounts, everything boots.
The idea is that if the computer is stolen, the monitor would also have to be stolen AND have the usb cable connected to the computer for /home to be decrypted. The usb stick itself is physically extremely small and most likely wouldn’t be seen.
If the USB stick isn’t present, decryption is skipped and the system boots, but without /home.
On 2013-08-05 17:56, philr5150 wrote:
>
> Yeah, I’m really not sure this can be done the way I want.
>
> What I’m looking for, ultimately, is this:
> I have a USB stick in the USB port in my monitor. That gets mounted as
> /dev/sdc1.
> The USB stick contains a file which holds the decryption key for
> /dev/sdb1.
> During boot, the stick mounts, the key-file is read and passed to the
> “Enter passphrase” prompt (or some other mechanism, but whatever, it’s
> automatic).
> /home mounts, everything boots.
Yes, I understand, but you would have to code it yourself, I think. You
would have to create your own systemd service and script to mount the
external media (do not use /dev/sdc1, use its label), and if successful
then silently mount home. I suggest that if it fails it mounts an
alternative home to fool the thieves.
The manpage I cited hints at how it could be done.
Me, I would certainly want to be asked a passphrase too.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)