Thank you for visiting!
My little window on internet allowing me to share several of my passions
Categories:
- OpenBSD
- vdcron
- My Sysupgrade
- FreeBSD
- Nas
- DragonflyBSD
- fapws
- Alpine Linux
- Openbox
- Desktop
- Security
- nvim
- yabitrot
- nmctl
- Tint2
- Firewall
- VPN
- Project Management
- Hifi
- Alarm
Most Popular Articles:
Last Articles:
Easily have encrypted files on OpenBSD
Posted on 2023-08-21 19:43:00 from Vincent in OpenBSD
Since OpenBSD 7.3 the installation process allow you to encrypt your whole disk.
This is a nice security feature that most persons will activate on their laptop. Your CPU will increase effort to encrypt and decrypt all those files residing on your systems.
I don't know the real impact, but I estimate (via a simple and empiric measure) that full encryption could add an extra charge of 25% on my machine and thus on my battery.
This blog is for persons having an old and/or weak battery laptops running OpenBSD.
Introdution
Basically the goal will be to define an encrypted filesystem for all files requiring such feature.
All the rest of OpenBSD remains standard, thus unencrypted.
Create a RAID filesystem during installation process
During the installation process, define an extra filesystem.
For that you have to enter in the DISKLABEL process and put RAID as filesystem type for one filesystem.
In the following example, I've added a filesystem "j". It will most probably be another letter in your case.
sd0> a j
offset: [213969647]
size: 20G
FS type: [4.2BSD] RAID
Once the DISKLABEL finalized, you can continue by typing
sd0> w
sd0> q
You have to define your own filesystems and their respective sizes.
You can be inspired by what the installation process proposes for your specific situation. You note those different values on a paper, then interrupt the process (ctrl-c) and restart it by typing "install". Once you arrive to the disk layout, enter into the manual process of DISKLABEL
For the rest, just follow the installation processes.
Create an encrypted filesystem
After having rebooted on your brand new OpenBSD system, you can encrypt your filesystem
Please adapt the disk in the following command to your own case !!!
# bioctl -c C -l sd0j softraid0
New passphrase:
Re-type passphrase:
sd1 at scsibus2 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd1: 19445MB, 512 bytes/sector, 39824607 sectors
softraid0: CRYPTO volume attached as sd1
Type a strong but well defined password. There is no way to recover it in case you forget it !!!!
So be very smart with this password.
As you can see, a pseudo disk sd1 has been created. Once again, depending on your specific case, this could be sd2 or sd3, ... Does not matter, but adapt this value in further commands
Then we will create a filesystem on this encrypted pseudo disk.
# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
# fdisk -iy sd1
# newfs sd1c
Here I'm creating the filesystem on the whole sd1 pseudo disk as mapped to letter "c".
At this stage, you can mount or umount it as a usual filesystem by refering to /dev/sd1c.
In case you have umounted it, you must also remove his pseudo disk by doing:
bioctl -d sd1
Mounting and umounting this new encrypted filesystem
mounting
To mount it, you have to do it in 2 steps:
# bioctl -c C -l sd0j softraid0
password:
softraid0: CRYPTO volume attached as sd1
There you must insert the password as defined during the setup process. And bioctl will reply to you which pseudo disk was created. In this case sd1
Then you can mount it:
# mount /dev/sd1c /enc
Your files will be present in /enc like any other filesystem.
To avoid troubles and to facilitate the scripting of such mount process, you can use the DUID of your disk.
this value can be retrieved via the command disklabel:
# disklabel sd0 | grep duid
duid: 0a7595940be2dcc9
In such case, you can perform:
/sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0
If you want to script this whole process, you could have something like this:
#!/bin.sh
# enc_mount.sh
doas /sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0 > /tmp/softraid_tmp
device=$(grep "attached" /tmp/softraid_tmp | cut -d' ' -f6)
if [ "$device" = "" ]; then
cat /tmp/softraid_tmp
else
mv /tmp/softraid_tmp /tmp/softraid
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
echo "device:$device"
doas /sbin/mount /dev/${device}c /enc
fi
Please note that I will use this script with my standard user. This explain the usage of doas
%obsd:~/.local/bin $ enc_mount.sh
Passphrase:
device:sd1
%obsd:~/.local/bin $
unmounting
To unmount, you have to unmount the filsystem and release the pseudo disk created:
# umount /enc
# bioctl -d sd1
Similarly, we could have such script to umount and remove the pseudo disk:
#!/bin/sh
# enc_umount.sh
set -e
doas /sbin/umount /enc
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
doas /sbin/bioctl -d $device
Please note that I'm using the file created during the pseudo disk creation in order to know which is this pseudo disk reference.
How much impact has an encrypted filesystem on your machine ?
This is a tricky question on which different responses can be provided.
On my side, I'm interested to save my CPU and thus my battery by avoiding decryption/encryption on none critical files.
Imagine you manage audio file or video files, let's see how this impact your CPU.
Since I'm on a laptop, I make sure the CPU is at the "low consumption" mode before each execution.
In this case I'm building a file of 1.500MB.
%obsd:~ $ apm
Battery state: low, 36% remaining, 64 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (400 MHz)
%obsd:~ $ time dd if=/dev/random of=bigfile bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 11.851 secs (132711408 bytes/sec)
0m12.03s real 0m00.00s user 0m11.62s system
%obsd:~ $
%obsd:~ $ apm
Battery state: low, 36% remaining, 46 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (2701 MHz)
%obsd:~ $ apm
Battery state: low, 36% remaining, 64 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (400 MHz)
%obsd:~ $ cd /enc
%obsd:/enc $ time dd if=/dev/random of=bigfile bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 15.107 secs (104114858 bytes/sec)
0m15.28s real 0m00.00s user 0m14.14s system
My encrypted filesystem is mounted on /enc.
I've not print out the apm command between each trials, but I did to make sure that the CPU was always at his "low mode" before the run.
| file size (MB) |standard |encrypted |delta |
|----------------|---------|----------|-------|
| 1500 | 11,851 | 15,107 |27,47 %|
| 500 | 4 | 5,237 |30,93 %|
| 200 | 1,528 | 2,049 |34,10 %|
| 100 | 0,777 | 0,953 |22,65 %|
| 50 | 0,379 | 0,587 |54,88 %|
This is not a real scientific case, but we can see that the delta is approximately 25%. I do not take into account the measure for the file of 50MB which is too small and measure can be altered via many other events occurring on the machine.
So I conclude, this is not scientific, that the encryption a full disk could eat 25% of my CPU and thus probably same ratio for on my battery.
This is probably not fully exact, but via this measure we see that the extra charge caused by the encryption is not negligible (few percent).
As suggested by Solene in Mastodon, I share with you the results based on Wh consumption.
So, what I do is getting the "Watt hour" remaining before and after the file's creation
to avoid side's effect, I did the following script which will launch each commands as soon as possible.
sysctl hw | grep "remaining capacity" ; time dd if=/dev/random of=bigfile bs=1M count=1500 ; sysctl hw | grep "remaining capacity"
This generate such output:
hw.sensors.acpibat0.watthour3=17.09 Wh (remaining capacity), OK
hw.sensors.acpibat1.watthour3=9.87 Wh (remaining capacity), OK
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 12.156 secs (129385069 bytes/sec)
0m12.39s real 0m00.00s user 0m11.56s system
hw.sensors.acpibat0.watthour3=17.09 Wh (remaining capacity), OK
hw.sensors.acpibat1.watthour3=9.77 Wh (remaining capacity), OK
As you can see, my T460 has 2 batteries, so I add both deltas. In this case the test took 0.10Wh.
| file size (MB) |standard Wh |encrypted Wh | delta |
|----------------|------------|-------------|-------|
| 5500 | 0.25 | 0.34 | 36 % |
| 3500 | 0.11 | 0.23 | 109 % |
| 1500 | 0.05 | 0.11 | 120 % |
Bellow 1500MB measures where too close to 0 and not significant.
My machine has AES enabled:
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
Now let's see the impact on a "read".
sysctl hw | grep "remaining capacity" ; time dd if=bigfile of=/dev/null bs=1M ; sysctl hw | grep "remaining capacity"
Measures are:
| file size (MB) |standard Wh |encrypted Wh | delta |
|----------------|------------|-------------|-------|
| 5500 | 0.08 | 0.15 | 87 % |
| 3500 | 0.00 | 0.00 | 0 % |
Read a file of 3.5GB is not measurable. Without encryption is take less than 1 seconds and with encryption is take a bit more than 1 second.
With 3 trials to read a file of 5.5GB, we can see that there is a delta of +-80% of Wh usage.
Add files of /etc in my encrypted filesystem.
Thanks to the script enc_mount.sh and enc_umount.sh, we can mount and umount such encrypted filesystem with a normal user.
Most of the files my encrypted filesystem will received are private documents and files.
But we could add files coming from /etc like hostname file for you wifi connection.
Let's see how to manage this for the hostname.iwm0 file containing the wifi passwords.
In this case my enc_mout.sh script becomes:
#!/bin/sh
# enc_mount.sh
doas /sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0 > /tmp/softraid_tmp
device=$(grep "attached" /tmp/softraid_tmp | cut -d' ' -f6)
if [ "$device" = "" ]; then
cat /tmp/softraid_tmp
else
set -e
mv /tmp/softraid_tmp /tmp/softraid
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
echo "device:$device"
doas /sbin/mount /dev/${device}c /enc
echo "adapt /etc/hostname.iwm0"
doas ~/.local/bin/enc_switch_file.sh /etc/hostname.iwm0
echo "netstart iwm0"
doas ifconfig iwm0 -joinlist
doas sh /etc/netstart iwm0
fi
You can see the last part of the script adding execution of enc_switch_file.sh and restart of my iwm0 interface.
This enc_switch_file.sh could be like this:
#!/bin/sh
# enc_switch_file.sh
if [ -f "/enc$1" ]; then
if [ -f "$1" ]; then
cp -a "$1" "$1_bkp"
rm "$1"
fi
ln -s "/enc$1" "$1"
else
echo "/enc$1 does not exists. Abandonned"
exit 1
fi
So, it take a backup of your /etc file and create a link to your file located in /enc.
I prefer to use symbolink links so, visually, I see immediately the situation.
And the enc_umount.sh script becomes like this:
#!/bin/sh
# enc_umount.sh
set -e
doas /sbin/umount /enc
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
doas /sbin/bioctl -d $device
echo "adapt /etc/hostname.iwm0"
doas ~/.local/bin/enc_uswitch_file.sh /etc/hostname.iwm0
echo "netstart iwm0"
doas ifconfig iwm0 -joinlist
doas sh /etc/netstart iwm0
Compared to previous enc_umount.sh script, I've added enc_uswitch_file.shs and restart of my wifi connections
In this case, enc_uswitch_file.sh is like this:
#!/bin/sh
#enc_uswitch_file.sh
if [ -h "$1" ]; then
if [ -f "$1_bkp" ]; then
rm "$1"
cp -a "$1_bkp" "$1"
else
echo "No backup file available. Link removed"
rm "$1"
fi
else
echo "$1 does not exists. Abandonned"
exit 1
fi
In short, this script remove the link to /enc and restore the _bkp file via a "cp -a".
Conclusions
We saw that it's not that complex to build an encrypted filesystem if it's planned since the installation process.
We can see that full disk encryption has an effect on hardware resources of our laptop. So the life of the battery.
Thanks to doas, it's possible to keep the usage of such encrypted filesystem to the end user.
We saw that such encrypted filesystem can contain some specific files located in /etc.
Once again, I'm amazed to see how simple, yet flexible, OpenBSD is.
1. From pirmd on Mon Jan 1 12:07:12 2024
Hello Vincent, thank you for your inspiring writeup. I'm wondering if you might have further good advice on how to ease backing-up the pseudo-disk where encrypted data lives ? (with FDE for instance I can automatically rsync any data to a remote FDE-encrypted NAS)
2. From Vincent on Wed Jan 3 23:47:43 2024
Thanks Pirmd for your feedback. Concerning the backup, I would suggest dump/restore. But, once mounted, it behave like your FDE and you can rsync where you want.