DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Installation and Upgrading

OpenBSD Installation and Upgrading Installing and upgrading OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 19th March 2017
Frice Frice is offline
Real Name: Eric
New User
 
Join Date: Mar 2017
Location: Sweden
Posts: 5
Default Partioning, layout and encryption (w passfile)

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:
HTML Code:
# 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.
__________________
[frice@...] ~$
Reply With Quote
  #2   (View Single Post)  
Old 19th March 2017
lifewoutmilk lifewoutmilk is offline
Awaiting Email Confirmation
 
Join Date: Mar 2017
Posts: 1
Default

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.
Reply With Quote
  #3   (View Single Post)  
Old 19th March 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
...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.
Reply With Quote
  #4   (View Single Post)  
Old 19th March 2017
Frice Frice is offline
Real Name: Eric
New User
 
Join Date: Mar 2017
Location: Sweden
Posts: 5
Default

Thanks for your replies…

Quote:
Originally Posted by lifewoutmilk View Post
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.

Quote:
Originally Posted by jggimi View Post
Quote:
...1 with the system (2 partitions: 1 small + 1 w all partitions)...
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).

Quote:
Originally Posted by jggimi View Post
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.

Quote:
Originally Posted by jggimi View Post
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.
__________________
[frice@...] ~$
Reply With Quote
  #5   (View Single Post)  
Old 19th March 2017
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

Quote:
Originally Posted by lifewoutmilk View Post
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.
__________________
Signature: Furthermore, I consider that systemd must be destroyed.
Based on Latin oratorical phrase

Last edited by e1-531g; 19th March 2017 at 07:46 PM. Reason: I didn't understand that keys would be on the same disc, so I edited answer.
Reply With Quote
  #6   (View Single Post)  
Old 19th March 2017
Frice Frice is offline
Real Name: Eric
New User
 
Join Date: Mar 2017
Location: Sweden
Posts: 5
Default

Quote:
Originally Posted by e1-531g View Post
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.

Quote:
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.
__________________
[frice@...] ~$
Reply With Quote
  #7   (View Single Post)  
Old 19th March 2017
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.


Last edited by jggimi; 19th March 2017 at 10:44 PM. Reason: typo
Reply With Quote
  #8   (View Single Post)  
Old 20th March 2017
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

Quote:
Originally Posted by Frice View Post
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
__________________
Signature: Furthermore, I consider that systemd must be destroyed.
Based on Latin oratorical phrase

Last edited by e1-531g; 20th March 2017 at 10:47 AM. Reason: added note and link about hdd
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
alpine with .pine-passfile support slowtechstef OpenBSD Packages and Ports 3 26th February 2016 10:30 PM
Partitions layout: Who is right? punk0x29a FreeBSD General 6 27th May 2013 06:45 PM
Security: Encryption: Disk Encryption eurovive Other BSD and UNIX/UNIX-like 17 6th March 2010 04:09 AM
Recommended Partition Layout MetalHead OpenBSD Installation and Upgrading 12 30th November 2008 10:08 AM
Keyboard Layout mfaridi FreeBSD General 6 26th June 2008 07:13 PM


All times are GMT. The time now is 01:08 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick