Other Plausible deniability when using GELI

chief

chief

Hello everyone,
I am looking for common thoughts on how plausible deniability is achieved in freebsd when using geli (or maybe zfs inline encryption) ?.
Coming from linux background, one would typically create efi, boot partition and store those on a usb stick or microSD.
Main drive would then be wiped and no partition would be created, raw disk would then be setup as encrypted disk with cryptsetup using aes-xts-plain64 with a password.
This would essentially make the main drive appear as a raw disk with no metadata, as required cipher params would be provided on the boot partition where they are initially configured in /etc/crypptab.

I am aware that there ways to attack this, such as evil maid, extracting keys from ram, as well as simple methods outlined in the attached comic, however in my opinion its better to have something than nothing. Nothing being metadata on disk giving away the use of encryption.

Wondering if anyone has done this in freebsd, let me know your thoughts, ideas on this.
 

Attachments

  • EFOZJSuMNXq9SY4VSpmMuynkwbkru-QLoemWAsRU7vg.jpg
    EFOZJSuMNXq9SY4VSpmMuynkwbkru-QLoemWAsRU7vg.jpg
    56.4 KB · Views: 260
chief said:
Thanks, are there any other freebsd tricks that can be added to what i mentioned ?
Click to expand...

Nothing special comes to mind. You probably know that you don't have to keep /boot mounted during operation (unless updating). So you can boot and then remove the USB stick from the running computer and swallow it or whatever is required. The running computer can then be more safely left behind.
 
The funny thing is you already added this very relevant xkcd.

Just think about how "plausible" it is to have an obviously used machine, but, what a miracle, there's just "random" garbage on the full harddisk. Spoiler: not plausible at all.

A way to get somewhat close to plausibility is to have a decoy system (unencrypted, normal partition table, bootloader and filesystem) and hide your encrypted container without any metadata somewhere inside the unallocated space of that regular filesystem. Of course, the decoy system must appear regularly used (lots of tell-tale signs if it isn't, like outdated software, old timestamps on ALL files, no logs, ...) and this comes with a very relevant technical problem: how would you prevent the filesystem to overwrite your encrypted container if there isn't any metadata anywhere?

In the real world, "plausible deniability" is a myth. Encryption with regular metadata is fine, it effectively prevents unauthorized access in typical cases of theft and similar. But there's nothing to help you if someone gets hold of you personally and is determined to get access "by all means".
 
cracauer@ said:
Moving /boot with the key setup to a USB stick works fine.
Click to expand...
JFTR, in the nowadays standard setup, /boot can happily reside inside the encrypted partition, just mark the container for decryption on boot (geli -g) by the bootloader (e.g. loader.efi or gptzfsboot).
 
zirias@ said:
JFTR, in the nowadays standard setup, /boot can happily reside inside the encrypted partition, just mark the container for decryption on boot (geli -g) by the bootloader (e.g. loader.efi or gptzfsboot).
Click to expand...
Is that supported in the iso installer or only manually ?
 
Back when I installed my system (11-CURRENT back then), this option didn't exist yet, so I'm not entirely sure, but I strongly assume this is the default setup created by the installer nowadays.
 
zirias@ said:
The funny thing is you already added this very relevant xkcd.

Just think about how "plausible" it is to have an obviously used machine, but, what a miracle, there's just "random" garbage on the full harddisk. Spoiler: not plausible at all.

A way to get somewhat close to plausibility is to have a decoy system (unencrypted, normal partition table, bootloader and filesystem) and hide your encrypted container without any metadata somewhere inside the unallocated space of that regular filesystem. Of course, the decoy system must appear regularly used (lots of tell-tale signs if it isn't, like outdated software, old timestamps on ALL files, no logs, ...) and this comes with a very relevant technical problem: how would you prevent the filesystem to overwrite your encrypted container if there isn't any metadata anywhere?

In the real world, "plausible deniability" is a myth. Encryption with regular metadata is fine, it effectively prevents unauthorized access in typical cases of theft and similar. But there's nothing to help you if someone gets hold of you personally and is determined to get access "by all means".
Click to expand...
Certainly the perfect secrecy only exists with the one time pads, with everything else there is the balance of risks. I agree with you hiding data in plain sight, eg in unused space however the line has to be drawn somewhere and for me that is too much effort.

Perhaps a better solution may be to use what those self exploding pagers used ?
 
chief said:
Is that supported in the iso installer or only manually ?
Click to expand...
I installed my 14.1 from the ISO choosing zfs root with geli encryption: /boot is just a normal directory inside / whilst /boot/efi is of course a mount point for /dev/gpt/efiboot0 .

Code: 
Filesystem          Type      1K-blocks      Used     Avail Capacity  Mounted on
zroot/ROOT/default  zfs       277723420   6492940 271230480     2%    /
devfs               devfs             1         0         1     0%    /dev
/dev/gpt/efiboot0   msdosfs      266144      1360    264784     1%    /boot/efi
procfs              procfs            8         0         8     0%    /proc
zroot/var/log       zfs         5237260      1920   5235340     0%    /var/log
zroot/tmp           zfs         5112428     20024   5092404     0%    /tmp
zroot               zfs       271230576        96 271230480     0%    /zroot
zroot/var/audit     zfs          102400        96    102304     0%    /var/audit
zroot/home          zfs       271230576        96 271230480     0%    /home
zroot/var/tmp       zfs         2096600       116   2096484     0%    /var/tmp
zroot/var/mail      zfs          102084       168    101916     0%    /var/mail
zroot/var/crash     zfs         2097152        96   2097056     0%    /var/crash
zroot/usr/src       zfs        18092520   1219336  16873184     7%    /usr/src
zroot/home/fmc000   zfs        47875460   3080292  44795168     6%    /home/fmc000
zroot/usr/ports     zfs         5157896   1536068   3621828    30%    /usr/ports

Code: 
zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:00:46 with 0 errors on Thu Sep 12 19:54:06 2024
config:

    NAME          STATE     READ WRITE CKSUM
    zroot         ONLINE       0     0     0
      nda0p4.eli  ONLINE       0     0     0

errors: No known data errors
 
fmc000 said:
I installed my 14.1 from the ISO choosing zfs root with geli encryption: /boot is just a normal directory inside / whilst /boot/efi is of course a mount point for /dev/gpt/efiboot0 .

Code: 
Filesystem          Type      1K-blocks      Used     Avail Capacity  Mounted on
zroot/ROOT/default  zfs       277723420   6492940 271230480     2%    /
devfs               devfs             1         0         1     0%    /dev
/dev/gpt/efiboot0   msdosfs      266144      1360    264784     1%    /boot/efi
procfs              procfs            8         0         8     0%    /proc
zroot/var/log       zfs         5237260      1920   5235340     0%    /var/log
zroot/tmp           zfs         5112428     20024   5092404     0%    /tmp
zroot               zfs       271230576        96 271230480     0%    /zroot
zroot/var/audit     zfs          102400        96    102304     0%    /var/audit
zroot/home          zfs       271230576        96 271230480     0%    /home
zroot/var/tmp       zfs         2096600       116   2096484     0%    /var/tmp
zroot/var/mail      zfs          102084       168    101916     0%    /var/mail
zroot/var/crash     zfs         2097152        96   2097056     0%    /var/crash
zroot/usr/src       zfs        18092520   1219336  16873184     7%    /usr/src
zroot/home/fmc000   zfs        47875460   3080292  44795168     6%    /home/fmc000
zroot/usr/ports     zfs         5157896   1536068   3621828    30%    /usr/ports

Code: 
zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:00:46 with 0 errors on Thu Sep 12 19:54:06 2024
config:

    NAME          STATE     READ WRITE CKSUM
    zroot         ONLINE       0     0     0
      nda0p4.eli  ONLINE       0     0     0

errors: No known data errors
Click to expand...
Thats good, thanks for checking
 
Zirias' advice is spot on. Before we all speculate about all this, we need to consider (a) how valuable the data on the target system is, and (b) who the attacker is. For example, if this system is used for international espionage or nuclear secrets, and the attacker is a nation state's intelligence agency, nothing we're discussing here is relevant. If the secret is naked pictures, and the attacker is an ex-partner who is not computer literate, just using a non-Windows file system (such as ZFS) and a reasonable user password is more than sufficient.

Any attacker who knows the slightest bit about how Unix-style systems use disks (partition, file system types, unallocated space, signatures of file systems and encrypted areas) will immediately recognize that the data for this system must be elsewhere. And if there is unpartitioned space on the hard disk (or the whole hard disk is unpartitioned and filled with seemingly random data), that will be the first thing they'll check. At that point, the xkcd or the so-called garden hose attack will succeed.

If the OP wants some security for their files, I would store them far away. For example on the other end of a long network connection, such as on a cloud service.
 
From Friday's post by the FreeBSD Foundation:

『… limited support for … disk encryption, … has slowed broader corporate adoption. By improving laptop compatibility, FreeBSD has the potential to become a robust, secure alternative to Linux and Windows in enterprise settings. …

『Enhancing laptop support will encourage more developers to adopt FreeBSD …

『… must offer a seamless experience

『… strong financial backing …』
 
Whole disk encryption is a great idea on laptops (and similar portable devices that are regularly lost in parking lots or stolen in coffee shops). It can be a good idea on home machines, depending on the tradeoff between convenience of booting versus likelihood of the disk drive or whole computer being stolen. In large data centers, its value is relatively low (since important data is separately encrypted anyway), but the relative cost and overhead is also low (the complexity is amortized over a very large number of disks), so it can be a net positive.

But "plausible deniability" a.k.a. duress mode is hard to get to work, and exceedingly hard to do right at the media level.
 
You need to know your threat to decide what defenses are appropriate and how likely they are to target the data or operators to get to it. Some users can keep personal operations private by turning down speakers or turning monitor far enough away from other people in the room that would not notice what they are in the presence of. Others need to go as far as multiple users need to provide personally known credentials to get into a system where it is restricted with timeouts and physical checkpoints so that only 1 person can be present to do it but multiple people have to sequentially do it for any progress.

Thinking about that reminds me of being in high school where kids installed and ran software and games on computers in class they weren't allowed to. I got locked out when 1/3rd+ of the class got locked out; no access means you will fail the class. Asked my teacher why I was locked out and was given the reason of "I didn't trust you" and was then given access again without further discussion. Doubt there was any program or trick classmates used that I didn't know about and I too did things I wasn't supposed to do but I did things like install better mouse software instead of installing+hiding a game. If I booted utilities on startup, they ran minimized until they could be properly hidden; teacher definitely knew to watch out for some windows appearing that were used to hide things but didn't watch the task bar too which probably helped me save a few of my friends from admin wrath. I think classmates got caught by admin reviewing deleted files and kids all started deleting stuff when crackdowns started happening.

In addition to geli and openzfs's encryption, there is also gbde. Beyond that there are plenty of file and stream based encryptors.

You can consider if you could get away with things like having an encrypted swap partition ready to manually mount that you just so happen to write other data in that scrambled looking space when not in use. Filesystem dates are harder to look for if there is no filesystem.

If wanting to hide something in plain sight while hoping you can easily extract the information while others will look past it, you may want to look into steganography though I don't know of anything that offers mounting+interacting with a filesystem in such a scenario so you would have to pull it out and put it away or roll your own interface to the data if one isn't found.

If using external media, some drive enclosures have capabilities to divide up a disk and represent pieces as their own drives which can be turned on+off. Using an iodd mini to install FreeBSD I find that the installer sometimes fails if seeing multiple disks, likely order dependent. I can use features of the drive to have an iso or img file be used to run the install as its own drive and have another file represent the drive it gets installed to; turning off visibility of install media and main drive containing all these file-backed drives allows successful boot after install. Similar things may be usable to try to hide visibility and access to what is really on the drive.
 
You must log in or register to reply here.
Back
Top