How to use an encrypted usb drive?

[f1-outsourcing]

Which version of pam_usb are you running?

new

Which distribution are you using?

new

Which login manager and desktop environment are you using?

new

What happened?

I was trying to use an automatically decrypted usb drive. I am experimenting a bit with the crypttab. How should I add a cryptsetup device? Something in /dev/mapper/xxxxxx

Output of "pamusb-check --debug whoami"

‎

Output of "w"

‎

Output of "loginctl"

‎

[mcdope]

No clue, never tried. Not even sure that's supported. But if you find out and give feedback I will be happy to include it in the documentation. Am Do., 9. März 2023 um 13:51 Uhr schrieb F1 Outsourcing Development < ***@***.***>:

…

Which version of pam_usb are you running? new Which distribution are you using? new Which login manager and desktop environment are you using? new What happened? I was trying to use an automatically decrypted usb drive. I am experimenting a bit with the crypttab. How should I add a cryptsetup device? Something in /dev/mapper/xxxxxx Output of "pamusb-check --debug whoami" ‎ Output of "w" ‎ Output of "loginctl" ‎ — Reply to this email directly, view it on GitHub <#190>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZI2U2FOT22IVPGCZ652BTW3HG4BANCNFSM6AAAAAAVVCMMZA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[f1-outsourcing]

pamusb only searches in /dev/ ? or can it be instructed to search in /dev/mapper or anywhere?

[f1-outsourcing]

Maybe delete this here and put in discussions? I am not really c programmer, but looks like this supports depends on udisk not?

[mcdope]

Yes, it does use UDisks. As long as UDisks picks up your crypto dev and recognizes it as removable it COULD work.

But totally untested.

[f1-outsourcing]

I removed everything from /etc/crypttab and /etc/fstab and did a

touch /etc/udisks2/tcrypt.conf

Now when I insert and remove the usb drive I am getting a prompt for the passphrase.

If I use udiskctl dump, I am getting such output

/org/freedesktop/UDisks2/block_devices/dm_2d4:
  org.freedesktop.UDisks2.Block:
    Configuration:              []
    CryptoBackingDevice:        '/org/freedesktop/UDisks2/block_devices/sdb3'
    Device:                     /dev/dm-4
    DeviceNumber:               64772
    Drive:                      '/'
    HintAuto:                   false
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          false
    HintSymbolicIconName:       
    HintSystem:                 true
    Id:                         by-id-dm-name-tcrypt-2067
    IdLabel:                    
    IdType:                     ntfs

However the pamusb-conf --add-device is not listing it

[mcdope]

What does cat /sys/block/XYZ/removable show? (replace XYZ with your dev)

I guess it's 0.

[f1-outsourcing]

Yes seems like it

lsblk --output NAME,KNAME,TYPE,SIZE,MOUNTPOINT
sda                 sda       disk   28.7G 
├─sda1              sda1      part      1G /run/media/xxx/xxxxxxxxxxx
├─sda2              sda2      part   26.3G /run/media/xxx/xxxxxxxxxxxxx
└─sda3              sda3      part    1.3G 
  └─tcrypt-2051_2   dm-0      crypt   1.3G 
    └─tcrypt-2051_1 dm-1      crypt   1.3G 
      └─tcrypt-2051 dm-2      crypt   1.3G /run/media/xxx/xxxxxxxxxxxxxx


[@fedora ~]$ cat /sys/block/sda/removable 
1
[@fedora ~]$ cat /sys/block/dm-2/removable 
0

Is it the responsibility of udisks2 to have this removable set by inheritance?

[mcdope]

Hmmm, you're not wrong imho. But then again, I assume there is a reason for it. Maybe it's because the crypt stuff doesn't support hotplug, to force a clean unmount?

But I found this discussion: https://unix.stackexchange.com/questions/613804/determine-if-a-given-path-is-on-a-removable-device-even-if-encrypted-via-bash

If you can find a reliable way to verify the crypt volume is on a removable disk via some shell magic, I will be happy to add support for that / translate it into code.

[f1-outsourcing]

I get the impression the removable is like the rotational and there is not a direct relationship with services on the device, or at least there should not be. I read some stuff that sometimes drivers incorrectly set this, so it could be they just forgot to implement this properly.

I noticed also that eg. the removable is not directly available on partitions, so it would be more logical to not even have this listed here at all. Maybe we should ask people at this udisk2 what supposed to be done. I could also be that it is required/expected/default of the kernel for such devices in the /dev/ root.

I am not entirely sure what you need in bash or how bash can help you. If I would do something starting fromt the information supplied by udisk, one can probably start with this path:

/org/freedesktop/UDisks2/block_devices/sda3

this will get you the partition truecrypt is on, and something like this will get you the parent device

basename "$(readlink -f '/sys/class/block/sda3/..')"

From which the removable state can be acquired.

I don't really understand what happens here, this could be related to possible hidden volumes. I am just testing with some basic setup. Otherwise I can't really explain why one crypted device generates these 3 mappings.

crw-------. 1 root root 10, 236 Mar 12 18:16 control
lrwxrwxrwx. 1 root root       7 Mar 12 18:21 tcrypt-2051 -> ../dm-2
lrwxrwxrwx. 1 root root       7 Mar 12 18:21 tcrypt-2051_1 -> ../dm-1
lrwxrwxrwx. 1 root root       7 Mar 12 18:21 tcrypt-2051_2 -> ../dm-0

Maybe a better approach would be to go the other way around? Get first all removable 'root' devices like /dev/sda, and then traverse the tree down to find possible mount points?

[mcdope]

"I am not entirely sure what you need in bash or how bash can help you. If I would do something starting fromt the information supplied by udisk, one can probably start with this path:"

The point of that was to find a way to reliably detect the removable bit. If I would have a starting point I could look into ways of adding such a detection and at least create an issue for it. But your suggestion looks already quite good anyway...

"Maybe a better approach would be to go the other way around? Get first all removable 'root' devices like /dev/sda, and then traverse the tree down to find possible mount points"

Maybe, but that would be quite a bit of work. Right now we just ask udisks for drives and check them for "removeability". If someone wants to do that change and submits a PR it could happen - but I wont spend any time on it.

I would suggest to just create another unencrypted partition for pam_usb. Few megs are enough and already kinda overprovisioned. Or get something like this: https://www.amazon.de/dp/B071DGR6W5 if you absolutely want the encryption but don't want to work on it either.

[f1-outsourcing]

I would suggest to just create another unencrypted partition for pam_usb. Few megs are enough and already kinda overprovisioned.

I have this currently

Or get something like this: https://www.amazon.de/dp/B071DGR6W5 if you absolutely want the encryption but don't want to work on it either.

I am struggling still a bit with the general idea of how to use encryption. I am not really looking for proprietary solutions. There are to many incidents with big nas, password etc companies

[mcdope]

I will keep this stuff in mind in case I become bored and have too much time ;-)

But since this is not my only project I'm currently not in position for a feature that size. Esp. considering that there are still some features missing from the backlog for 0.9.

[f1-outsourcing]

I think this pam_usb is quite a nice idea, I do not get why it is not by default in fedora, or why redhat is not supporting the development of it.

a I would like to use full disk encryption of the windows os on the laptop
b I would like to use full disk encryption of the linux os on the laptop[2]
c It would be nice if in public places I do not need to type a password on the keyboard
d It would be nice if one usb pen drive can be used for both linux and windows logon
e It would be nice if I only have to take one usb pen drive to unlock at boot and to login.
f To have good safe encryption, you need to use key files, passwords are just to short.
g It would be nice if the usb pen drive can easily be destroyed [1]
h It would be nice if the usb pen drive does not show any signs of being an auth token or encrypted

? The problem with c is that if I lose both laptop and key, everything is accessible, which makes the use of total disk encryption useless.
? Should I make it like this, that I can easily duplicate usb pen drives so when I lose one, I can easily recreate it. Or is it better to prepare a few up front.
? Is it even wise to combine the full disk encryption keys with the pam_usb device.
? Is it even possible to work with encryption keys and without passphrases.
? Maybe the usb pen drive can be put in a 'destroyed' state after boot/login so when the laptop is not cleanly shutdown, or the pen drive is suddenly removed it is useless. Only when a clean reboot/shutdown is done the pen drive is changed from a 'destroyed' state to a 're-usable' state.
? Maybe I can change keys every time after successful use, this would make a copy useless after a use cycle.

As you can see, I am clearly struggling with this concept. I guess you always need to find a compromise between such conflicting wishes, and probably a security expert knows best what to do here.

[1]
https://hackaday.com/2022/09/26/so-how-do-you-make-a-self-destructing-flash-drive/

[2]
https://tqdev.com/2022-luks-with-usb-unlock