Partioning, layout and encryption (w passfile)

[Frice]

I'm sitting here planning my install, at least the partitioning layout. And I'm trying to get my head around a few things.

The plan is to use 2 disks. I have 2x 120GB available. First thought was to put them in a RAID and then CRYPT that one. I've seen a couple of examples/guides doing that, but the official documentation says it's not supported »»». I'll go with the FAQ. So, 2 disks, both encrypted: 1 with the system (2 partitions: 1 small + 1 w all partitions) - the other one just mounted on it (2 partitions: /altroot + 1 big), and I can make a script to rsync my backups instead. I guess disk#2 can be decrypted and mounted an rc-file using the: -p passfile.

Something like:

# disk#1
a: /            # 123m (just to match disk#2)
d: /            # 123m
   /the/other
   /partitions

# disk#2
a: /altroot     # 123m
d: /            # mounted on disk#1

// 123m is just for the example

Since /altroot is on the other disk (as recommended), and the disk is encrypted. Should I mount it in the rc-file together with the unlocking?, or can it go into /etc/fstab?

- - -

The other thing is, the passfile. I've really tried to search/find guides and examples around, but only found 2. To unlock disk#2, I can put the passfile in: /root/foo/disk2.pfile. But how to unlock disk#1… Can I use the passfile option for that one as well? Is the system able to read a passfile on boot inside the crypted partition (ie probing function), or does it need to sit on an uncrypted partition? Or how can I get disk#1 to unlock on boot, without typing or keydisk?

The idea is to use the server either as a mailserver @home, or as a backup server @neighbour (or another location). A keydisk doesn't feels like an option. I want to have a solution that can handle both disks, but neither the FAQ or the bioctl(8) are using that in any examples.

What's the preferred way to manage/reboot a server remotely (ssh)? Any ideas?

- - -

> “It's currently only possible to boot from RAID1 and crypto volumes on i386, amd64 and sparc64.” — faq14.html#softraid

Perhaps I can't use FDE using my old Mac G4 (macppc)? Then, what's the minimum I need unencrypted?


Sorry if I've mixed up or missed anything. Please correct me if so.

[lifewoutmilk]

What's the point of disk encryption, if all the keys for decryption are stored on the disk unencrypted? Sounds like a waste of time.

[jggimi]

...1 with the system (2 partitions: 1 small + 1 w all partitions)...

I don't understand what this intends.

---

When the softraid device is to be used, bioctl(8) or the bootloader will require a passphrase - entered by the operator at the console or terminal, or obtained from a "passfile" stored on a disk.

Optionally a "keydisk" may be used.


My understanding is that the best practice for both passfile and keydisk is to use external drives, such as USB sticks, should either be operationally necessary.

---

I've never used a passfile, nor have I used a keydisk.

[Frice]

Thanks for your replies…

Originally Posted by lifewoutmilk

What's the point of disk encryption, if all the keys for decryption are stored on the disk unencrypted? Sounds like a waste of time.

Well, that's a part of my question, and why I don't feel that keydisk is an option. With a passfile, if it has to go on an uncrypted partition… I would be able to store it elsewhere - put it in place before reboot, and delete when I'm done. That was at least the idea if there aren't any other good options to manage the server remotely.

Originally Posted by jggimi

I don't understand what this intends.

I meant 2 disks, both with a small partition and one big. The small partition on disk#2 for /altroot and on disk#1 - incase I need it for the passfile, or I can put other stuff on it. The large partition on disk#1 with the system, and on disk#2 just one big one to mount on the system (for backups/syncs).

Originally Posted by jggimi

When the softraid device is to be used, bioctl(8) or the bootloader will require a passphrase - entered by the operator at the console or terminal, or obtained from a "passfile" stored on a disk.

Optionally a "keydisk" may be used.

Yes, it's just that there will be no operator on the other side if I put it @neighbour. So finding a solution that I can reboot over ssh and get it to unlock is what I'd need, if possible.

Originally Posted by jggimi

My understanding is that the best practice for both passfile and keydisk is to use external drives, such as USB sticks, should either be operationally necessary.

I've seen an example using the passfile stored in /root to be able to automatically unlock the other disk. So if the first disk is encrypted as well, that one is safe. It's just the first one. Perhaps using an unencrypted disk/partition, and the like above - get the file before reboot and delete afterwards?

But then, that thing about what systems/platforms that can('t) unlock. If macppc can't do it - a semi-encrypted system would be able to reboot normally? and I can unlock the rest manually from my ssh connection?

And there are no other remote solutions? Like GNU/Linux are using dropbear, tinyssh etc. (Here's a Debian example.)

Best thing would be if there were like a “cryptreboot”, who asked for the password before reboot instead of when booting.

[e1-531g]

Originally Posted by lifewoutmilk

What's the point of disk encryption, if all the keys for decryption are stored on the disk unencrypted? Sounds like a waste of time.

I also don't see use case. Well, maybe if somebody has SSD, after some time he/she could sell it somebody and want to make sure that there would be any traces of useful data. SSDs have relatively large space reserved for relocations, because memory cells can be destroyed by frequently writing to them. There could be relocated data, which can't be destroyed by simply zeroing by dd, but probably can be accessed if somebody would hack SSD's firmware.
I can think about a few use cases where it can by useful if somebody stores it on Pendrive.
1. Somebody steals your laptop. You don't want to disclose your secrets to this person. The thief probably would not bother to steal Pendrive, so your data is safe from disclosure.
2. You are crossing the border. Border agent wants your password to the encrypted partition. You don't want to disclose information. If your secret is a passphrase, you can give it to them, but you won't.
If your secret is on Pendrive stored somewhere else (i.e. your lawyer has it), you can't give it to the border agent.
You have a higher probability of success to make through border when you can't provide this secret compared to when you can but just don't want to.

[Frice]

Originally Posted by e1-531g

I also don't see use case. Well, maybe if somebody has SSD, after some time he/she could sell it somebody and want to make sure that there would be any traces of useful data. SSDs have relatively large space reserved for relocations, because memory cells can be destroyed by frequently writing to them. There could be relocated data, which can't be destroyed by simply zeroing by dd, but probably can be accessed if somebody would hack SSD's firmware.
I can think about a few use cases where it can by useful if somebody stores it on Pendrive.
1. Somebody steals your laptop. You don't want to disclose your secrets to this person. The thief probably would not bother to steal Pendrive, so your data is safe from disclosure.
2. You are crossing the border. Border agent wants your password to the encrypted partition. You don't want to disclose information. If your secret is a passphrase, you can give it to them, but you won't.
If your secret is on Pendrive stored somewhere else (i.e. your lawyer has it), you can't give it to the border agent.
You have a higher probability of success to make through border when you can't provide this secret compared to when you can but just don't want to.

Thanks for the input. This is not a laptop that will be stolen &/or pass a border. And the plan is to get some solution, so I can have the keys here or elsewhere, meaning if I pass that border, they won't be available.

SSDs have relatively large space reserved for relocations, because memory cells can be destroyed by frequently writing to them. There could be relocated data, which can't be destroyed by simply zeroing by dd, but probably can be accessed if somebody would hack SSD's firmware.

I'm not sure, but using hdparm(8) (unfortunately, Linux only) you can reset the disk (aka “factory reset”).
“… all its cells will be marked as empty …” »»
Some Rescuedisks have that feature bundled. Also saw this guide to about over-provisioning. But a reset should do it just to null the blocks/cells.

[jggimi]

When looking at encryption for protecting privacy, consider two types of data:

1. Data in Motion.
2. Data at Rest.

Disk encryption systems protect only the second category: Data at Rest. The primary value of disk encryption is to protect information privacy in the event of physical loss or theft -- common with portable devices (laptops, netbooks, tablets, phones).

• It will not protect you from data exposure while the system is running, or in any standby or suspended operation, since data is in plaintext to be available to the OS and applications.

And crossing borders? In this day and age, I have no interest in testing encryption mechanisms with any nation's immigration or customs services. I will ONLY cross a border with completely clean devices that have no personal information on them, encrypted or plaintext. NONE WHATSOEVER.

[e1-531g]

Originally Posted by Frice

I'm not sure, but using hdparm(8) (unfortunately, Linux only) you can reset the disk (aka “factory reset”).
“… all its cells will be marked as empty …” »»
Some Rescuedisks have that feature bundled. Also saw this guide to about over-provisioning. But a reset should do it just to null the blocks/cells.

SSDs have large reserved space for reallocated sectors. At least some of these cells could be still be read even after reallocation. I doubt "factory reset" tries to clear them. SSDs have complicated code in firmware and at least some of them could be hacked (or bypassed by ports like UART, JTAG). Even HDD have enough computing Power to run Linux
http://spritesmods.com/?art=hddhack&page=7
Zeroing out (or doing "factory reset") should be enough if data is not so sensitive, but if you want to be sure just do this:
Backblaze: How to securely recycle or dispose of your SSD

[unixpwl]

Originally Posted by Frice

Best thing would be if there were like a “cryptreboot”, who asked for the password before reboot instead of when booting.

This response is a bit late, but last year I created a tool that does exactly this:

https://phantomno.de/cryptreboot

It asks for a passphrase and reboots the system afterward, automatically unlocking the drive on startup using in-memory initramfs patching and kexec. Without explicit consent, no secrets are stored on disk, even temporarily.

Cryptreboot currently supports Debian-based Linux distributions, but if OpenBSD implements a mechanism similar to kexec, then I believe it could be ported.

A side note: I found this post while searching for "cryptreboot" on Google, sometime after releasing the tool. I think it's awesome that you envisioned both the behavior and name of this tool over 6 years ago!