The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
-
-
@dianea As much as I love the idea, users contemplating it should be aware that a real forensic expert would have little trouble finding evidence of this, and it might result in additional obstruction charges.
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
-
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
@dianea hm... just gave me an idea - I was thinking it'd be cool to have your sensitive stuff mounted on a separate filesystem from your regular home. But even with encryption it'd be easy to spot.
How about a filesystem that's interleaved with an existing filesystem? E.g. both in one partition, but using alternating blocks, or alternating extents.
I suppose once you create something like that, people will know to look for it.
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
@vampirdaddy GrapheneOS has a duress unlock option. I believe it works on screen unlock.
-
-
@dianea As much as I love the idea, users contemplating it should be aware that a real forensic expert would have little trouble finding evidence of this, and it might result in additional obstruction charges.
Yes, a standard login screen was designed for a civilized society, tested by countless thousands of security researchers. It is obvious there's a login screen. They are almost useless against metal chairs and a rubber hose wielded by angry detectdives...
Even better solution, but customized for a COVERT one user login:
In these uncertain times, a workaround can be covertly implemented. Just before the login screen starts, echo the text artwork of a normal boot and what looks like a kernel panic to the screen. Make it look convincing. Redirect all further text input/output to null. When the correct password is entered, the normal kernel/init will bring the system up.
Sure, entering a password will spike the power consumption up while it crunches numbers and an astute detective may notice that. So run a loop of instructions to keep a core busy. Maybe bang on the address bus a bit to make it look like a runaway oops.
The detective will ask what's up with this, so make him feel important by asking if he can fix it. Make the detective feel important. Put any NPD personality the detective has in a positive mood. Social engineering 101.
-
@vampirdaddy GrapheneOS has a duress unlock option. I believe it works on screen unlock.
@EdBruce @vampirdaddy @jgilbert @tom
Yes, and the GraphineOS duress password method works well. But only in civilized times. Not against detectives with metal chairs and a rubber hose.
You'll need to hide the login screen with the artwork of a kernel panic. Make it look convincing. Make the detective feel important, ask him if he can fix it. Butter that NPD personality up he surely has. You might not get your phone or computer back, but you'll live another day.
-
-
Destruction of evidence, etc.
Nope, that's not what you want to do._Regular_ shutdown mechanics (regular closing of network connections, unmounting filesystems, clearing of open cryptosystems) or plain shutdown should be argumentable, though, as that is fully reversible (if someone +cough+ would be willing to).
One problem, though: the module won't help if one's asked to unlock the lock screen.
@vampirdaddy @jgilbert @tom @dianea pam does the check for screen unlock too so it'll work there. The duress password is what you put on the post-it. And you make it cry for help (send network notif), wipe keys, snapshot and backup, and shutdown.
Zfs can send incrementals of encrypted volumes without having the key. The data is not destroyed, just locked by a key that is no longer on the device.
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea One useful addition to this would be a password that does an immediate wipe.
There are situations where that is indeed what you want, while that is extremely conspicuous, if the wipe is irreversible, there isn't much that your captors can do about it afterwards, and it's an option that should be available to users.
For systems that store their disk encryption key in a TPM, you could do this by just destroying the key (though I'm not sure whether PAM would even run in an encrypted disk scenario, I know far too little about how this works on Linux specifically).
-
R ActivityRelay shared this topic on
-
The PAM Duress is a module designed to allow users to generate 'duress' passwords that when used in place of their normal password will execute arbitrary scripts.
This functionality could be used to allow someone pressed to give a password under coercion to provide a password that grants access but in the background runs scripts to clean up sensitive data, close connections to other networks to limit lateral movement, and/or to send off a notification or alert (potentially one with detailed information like location, visible wifi hot-spots, a picture from the camera, a link to a stream from the microphone, etc). You could even spawn a process to remove the pam_duress module so the threat actor won't be able to see if the duress module was available.
@dianea I would like to see devices with fingerprint ID provide for a duress finger. And for devices with FaceID to support a duress face. Perhaps sticking out your tongue could wipe the device and trigger a factory reset.
-
-
@vampirdaddy @jgilbert @tom @dianea pam does the check for screen unlock too so it'll work there. The duress password is what you put on the post-it. And you make it cry for help (send network notif), wipe keys, snapshot and backup, and shutdown.
Zfs can send incrementals of encrypted volumes without having the key. The data is not destroyed, just locked by a key that is no longer on the device.
@AMS @vampirdaddy @jgilbert @tom @dianea If only OpenZFS encryption was stable
That's really cool & something I would really like to have once OpenZFS no longer has issues with losing encrypted datasets. -
@AMS @vampirdaddy @jgilbert @tom @dianea If only OpenZFS encryption was stable
That's really cool & something I would really like to have once OpenZFS no longer has issues with losing encrypted datasets.@jackemled @AMS @jgilbert @tom @dianea
Or instead of zfs-send you use rsync (over SSH if crypto is needed)? -
@jackemled @AMS @jgilbert @tom @dianea
Or instead of zfs-send you use rsync (over SSH if crypto is needed)?@vampirdaddy @AMS zfs-send & rsync are two different things with different uses, but do similar things. Both do unidirectional syncs, but rsync is for files only & optionally (SSH by default) uses encryption in transit. zfs-send is for copying a snapshot or the current state of the entire filesystem or specific datasets within it, & those datasets either have or do not have encryption on the disk. If the dataset is encrypted, then the generated snapshot file will contain only encrypted data; if not, then only plaintext data. If the snapshot is streamed to a remote OpenZFS filesystem through SSH, then there is additional encryption in transit equivalent to the default settings for most rsyncs, since both use SSH.
OpenZFS filesystem or dataset encryption is unstable right now & can cause data loss because of keys being dropped & stuff if some storage devices don't appear to the computer in the right order or never appear at all or something. We're talking about at rest encryption, not in transit encryption.
-
@vampirdaddy @AMS zfs-send & rsync are two different things with different uses, but do similar things. Both do unidirectional syncs, but rsync is for files only & optionally (SSH by default) uses encryption in transit. zfs-send is for copying a snapshot or the current state of the entire filesystem or specific datasets within it, & those datasets either have or do not have encryption on the disk. If the dataset is encrypted, then the generated snapshot file will contain only encrypted data; if not, then only plaintext data. If the snapshot is streamed to a remote OpenZFS filesystem through SSH, then there is additional encryption in transit equivalent to the default settings for most rsyncs, since both use SSH.
OpenZFS filesystem or dataset encryption is unstable right now & can cause data loss because of keys being dropped & stuff if some storage devices don't appear to the computer in the right order or never appear at all or something. We're talking about at rest encryption, not in transit encryption.
@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.
This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.
-
@vampirdaddy @AMS What AMS means is that you can wipe the keys from your device & still be able to send the state of your OpenZFS filesystem to a remote even though you don't have the keys anymore. So you can simply have your keys backed up somewhere else, then in an emergency wipe them from the local device (so your filesystem can't be read) & zfs-send to a remote incase you never get the local device back from police or a thief or whoever is taking it. That way you can secure your data without having to wait for the backup to complete first like with most filesystems, simply do the backup second.
This is really cool to me because delta syncing encrypted data is hard, but the way ZFS snapshots work means you're actually copying only new blocks, not actual changes, & those blocks can contain changes.
@vampirdaddy @AMS It also means less time until the filesystem is secured, but if you use SSH you still have to wait for the send to complete before you can delete your SSH keys. Maybe a solution would be to use TLS to an open & write only fileserver so SSH keys can be deleted earlier, maybe something like a pastebin.
-
@vampirdaddy @AMS It also means less time until the filesystem is secured, but if you use SSH you still have to wait for the send to complete before you can delete your SSH keys. Maybe a solution would be to use TLS to an open & write only fileserver so SSH keys can be deleted earlier, maybe something like a pastebin.
@jackemled @vampirdaddy In my case, backup service is a single use key limited only being able to send snapshots, no shell, no recv, not used for anything else. And the duress lock sends a burndown (wipe key from backup endpoint) and wipes that local key after the backup completes.
