Setting up a laptop: Difference between revisions

From Alpine Linux
m (→‎Creating GPG keys: update recommendation)
(replace /etc/init.d with rc-service)
 
(83 intermediate revisions by 8 users not shown)
Line 6: Line 6:


*Deniable full disk encryption
*Deniable full disk encryption
*Two factor authentication (physical (USB key), mind)  
*Two factor authentication (physical object (USB key), mind)  
*Encrypted swap and hibernation
*Encrypted swap and hibernation
*Encrypted home on top of encrypted drive
*Encrypted home on top of encrypted drive
Line 15: Line 15:
== Rubberhose Attack ==
== Rubberhose Attack ==


Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death.  See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article].  We try to present [https://en.wikipedia.org/wiki/Deniable_encryption  deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario.  In this article we use the words plausible deniability interchangeably with deniable encryption.  To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk.  We will not cover steganography where we dilute the randomness into the facade.  The addition is welcomed in this article.  It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim.  Deniable encryption requires you not put encrypted as an entry title to your bootloader.  There shouldn't be an entry for your facade bootloader to the encrypted drive.
Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death.  See [https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis Wikipedia article].  We try to present [https://en.wikipedia.org/wiki/Deniable_encryption  deniable encryption (Wikipedia)] to avoid a rubberhose attack scenario.  In this article we use the words plausible deniability interchangeably with deniable encryption.  To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk.  The keys should be stored using steganography where we dilute the randomness into the facade.  It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim.  Deniable encryption requires you not put encrypted as an entry title to your bootloader.  There shouldn't be an entry for your facade bootloader to the encrypted drive.


== Why full disk? ==
== Why full disk? ==
Line 21: Line 21:
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it.  Is the drive just random noise, broken, or is it really encrypted?  The other reason is that it implies that everything is protected.
The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it.  Is the drive just random noise, broken, or is it really encrypted?  The other reason is that it implies that everything is protected.


But there could be problems if not done right.  For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][http://man7.org/linux/man-pages/man8/cryptsetup.8.html]  To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.
But there could be problems if not done right.  For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option <code>--header <path></code> is not presented.[https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/][https://man7.org/linux/man-pages/man8/cryptsetup.8.html]  To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.


If you did deniable encryption incorrectly, it is possible to erase and restore the header.  This presents an opportunity to improve obfuscation.  When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely.  If you plug in the USB key, it will restore back the header.  cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.
If you did deniable encryption incorrectly, it is possible to erase and restore the header.  This presents an opportunity to improve obfuscation.  When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely.  If you plug in the USB key, it will restore back the header.  cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.
Line 42: Line 42:
The first part is to erase the drive with random noise but in practical time.  There are many techniques to do this but should be done in one day or two minimum.
The first part is to erase the drive with random noise but in practical time.  There are many techniques to do this but should be done in one day or two minimum.


You can use shred or dd to accomplish this depending on your needs and the availability of entropy.  Some techniques take longer.  Cryptologist Bruce Schneier recommended 7 times with specified pattern.  See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article].  For practical purposes, we just do it random in one pass.   
You can use shred or dd to accomplish this depending on your needs and the availability of entropy.  Some techniques take longer.  Cryptologist Bruce Schneier recommended 7 times with specified pattern.  See [https://en.wikipedia.org/wiki/Data_erasure Wikipedia Article].  For practical purposes, we just do it random in one pass.  It should be random so that the facade of random noise hides the encrypted data which resembles noise.


To list the drives on the system do <code>fdisk -l</code>.   
To list the drives on the system do <code>fdisk -l</code>.   
Line 66: Line 66:
Then, to generate a key:
Then, to generate a key:


   openssl rand -base64 128 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/2a667ec72774b0d5
   export GPG_TTY=$(tty) && openssl rand -base64 512 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/$(openssl rand -hex 12)


(Make sure your usb is mounted on /mnt/usb first.)
(Make sure your usb is mounted on /mnt/usb first.)


The long file name comes from <code>openssl rand 8 -hex</code> so that we enhance plausible deniability.  The attacker cannot determine the purpose of the key.  Is it used for GitHub? for Email?
The long file name comes from <code>openssl rand -hex 12</code> so that we enhance plausible deniability.  The attacker cannot determine the purpose of the key.  Is it used for GitHub? for Email?


The first part will produce 128 random bytes in wrap it in base64.  The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor.  For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives.  After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.
The first part will produce 512 random bytes in wrap it in base64.  The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor.  For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives.  After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.


You can replace aes above with the ones listed in <code>gpg --version</code>.
You can replace aes above with the ones listed in <code>gpg --version</code>.


There should be a password generated for the swap.  This is to resume for your hibernate.  If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.
There should be a password generated for the swap.  This is to resume for your hibernate.  If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.
== Hiding the keys using steganography ==
''WARNING:'' This section is considered experimental.  It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks.  The tool and dependencies need to be packaged together.  We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt.  Steghide automatically uses 128-bit AES in CBC mode to encrypt data.  This can be change if you don't like or trust AES with the -e option.  Use <code>steghide encinfo</code> for other ciphers and modes.
Fortunately, Alpine has a package for steganography called steghide.  To install steghide do:
  apk add steghide
You will place the keyfile in an image file.  The facade image file should be large enough that there is no apparent discernible difference between the original and the modified.  Do not use a small image with a small filesize.
As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable.  Use another format like .au/.wav or another steganography utility that handles mp3s.  The mp3/wav should be fairly large enough to dilute the header.  So, something with long content is suitable.
There are two basic commands to use with steghide embed and extract,
To embed do:
  steghide embed -ef key.gpg -cf image.jpg
To extract do:
  steghide extract -xf key.gpg -sf image.jpg
To get a file list of files to ship out, use:
  apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide


== Full disk encryption with with cryptsetup-luks volumes ==
== Full disk encryption with with cryptsetup-luks volumes ==
Line 86: Line 112:
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption.  Windows is also acceptable even better.  The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.
For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption.  Windows is also acceptable even better.  The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.


There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on a external device.
There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.


==== Luks ====
==== Luks ====
Line 165: Line 191:
=== Choosing ciphers ===
=== Choosing ciphers ===


When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use.  The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks.  The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>.  Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel.  Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and recommends Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary]  If it is hardware accelerated, it will save battery life and minimize CPU usage.
When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use.  The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks.  The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by <code>cat /proc/cpuinfo</code>.  Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel.  Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[https://en.wikipedia.org/wiki/Cipher_security_summary]  If it is hardware accelerated, it will save battery life and minimize CPU usage.


Another advantage of using a public vetted cipher is that it provides confidence that it works.
For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].


Generally speaking, the swap partition should use a fast cipher.
For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].


'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about AES encryption.
Generally speaking, the swap partition should use a fast cipher.  You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.


=== Getting the available ciphers ===
'''IMPORTANT:''' Please read the [[Setting_up_a_laptop#Important_notes | Important notes]] section for details about the problems with AES encryption.


  cryptsetup benchmark
If you don't trust AES shills and endorsed by the NSA, you can try another different one.  Another advantage of using a public vetted cipher is that it provides confidence that it works.


The top set is associated with the hashing algorithmsThe bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.
Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>.  KHAZAD itself is insecureWikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]


'''IMPORTANT: do not use sha1 as the hashing algorithm.'''  It already has already been compromised.
For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]


For some ciphers weakness also see [https://en.wikipedia.org/wiki/Cipher_security_summary Cipher security summary (Wikipedia)].
'''IMPORTANT: Do not use sha1 as the hashing algorithm.'''  It already has already been compromised.


For some hash function weaknesses also see [https://en.wikipedia.org/wiki/Hash_function_security_summary Hash function security summary (Wikipedia)].
=== Getting the available ciphers ===


To check the availability of a cipher or hash function use:
To check the availability of a cipher or hash function use:
   find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort
   find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort


To check if a cipher is loaded use:
To check if a cipher is loaded and passed its own tests use:
   cat /proc/crypto
   cat /proc/crypto


<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like Anubis.  The cipher should also have CBS and/or XTS block cipher mode of operation to encrypt larger block sizes.  AES for example has a block size of 128. 
To test some popular ciphers and hashes do:


To test if the unpopular but uncracked cipher works use sometime like:
   cryptsetup benchmark
   cryptsetup benchmark --cipher anubis


If you don't trust AES shills and endorsed by the NSA, you can try another different one.
The top set is associated with the hashing algorithms.  The bottom set are the ciphers.  Use the commands below but replace the cipher and/or hash algorithm with your preferences.


Something like KHAZAD wouldn't work on <code>cryptsetup benchmark</code>.  KHAZAD itself is insecureWikipedia reported 5 out of 8 rounds been cracked.[https://en.wikipedia.org/wiki/KHAZAD]
<code>cryptsetup benchmark</code> actually doesn't show all the ciphers like AnubisThe cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizesAES for example has a block size of 128.


For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[https://en.wikipedia.org/wiki/Advanced_Encryption_Standard]  In theory it takes exponential time complexity with best attack to crack 128-bit AES according to Wikipedia,[https://en.wikipedia.org/wiki/Cipher_security_summary] but it could be cracked in a few minutes according to Halderman et. al. with a cold boot side channel attack. [https://citp.princeton.edu/research/memory/ See FAQ section].
To test if the unpopular but uncracked cipher works use sometime like:
  cryptsetup benchmark --cipher anubis


=== General steps for cryptsetup ===
=== General steps for cryptsetup ===
Line 225: Line 251:
| 2
| 2
| Create and format the luks device
| Create and format the luks device
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/2a667ec72774b0d5</nowiki></code>
| <code><nowiki>cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/$(ls)</nowiki></code>
|-
|-
| 3
| 3
| Open the luks device
| Open the luks device
| <code><nowiki>cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root</nowiki></code>
| <code><nowiki>cryptsetup --key-file /mnt/usb/$(ls) luksOpen /dev/sda1 root</nowiki></code>
|-
|-
| 4
| 4
Line 265: Line 291:
| 1
| 1
| Open the ''plain dm-crypt'' device generating no metadata
| Open the ''plain dm-crypt'' device generating no metadata
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root</nowiki></code>
| <code><nowiki>cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/$(ls) /dev/sda pvroot</nowiki></code>
|-
|-
| 2
| 2
Line 317: Line 343:
   rc-update add dmcrypt boot
   rc-update add dmcrypt boot


==== /etc/init.d/dmcrypt ====
==== dmcrypt ====
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.
The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in ''/etc/conf.d/dmcrypt''.


Line 378: Line 404:


To recover from the ''plain dm-crypt'':
To recover from the ''plain dm-crypt'':
   cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/2a667ec72774b0d5 /dev/sda root
   cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/$(ls) /dev/sda root
   vgchange -ay vgroot
   vgchange -ay vgroot
   lvchange -ay vgroot/root
   lvchange -ay vgroot/root
Line 387: Line 413:


We will setup the /mnt/root encrypted partition:
We will setup the /mnt/root encrypted partition:
   apk add --root=/mnt/root --initdb $(cat /etc/apk/world)
   apk add --root=/mnt/root --initdb $(cat /etc/apk/world) --keys-dir /etc/apk/keys --repositories-file /etc/apk/repositories


Then, enable edge repositories in both files including community and testing:
Then, enable edge repositories in both files including community and testing:
Line 399: Line 425:
   apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi
   apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi
   apk add --root=/mnt/root sudo nano
   apk add --root=/mnt/root sudo nano
   apk add --root=/mnt/root linux-hardened
   apk add --root=/mnt/root linux-lts


Then, you need to mount your usb on to /boot:
Then, you need to mount your usb on to /boot:
Line 444: Line 470:
   sudo setup-xorg-base
   sudo setup-xorg-base
   sudo apk search xf86-video | sort
   sudo apk search xf86-video | sort
   # pick your video driver
   # pick your xf86 video driver
   sudo apk add xf86-video-adi
   sudo apk add xf86-video-amdgpu
   # pick your opengl driver
   # install the mesa driver
  sudo apk search mesa-dri* | sort
   sudo apk add mesa-dri-gallium  
   sudo apk add mesa-dri-ati  


Then, keep piling on:
Then, keep piling on:
   sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4
   sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat
   sudo apk add font-noto-emoji terminus-font leafpad xsetroot # See [[Emojis]] to complete installation
   sudo apk add font-noto-emoji font-terminus leafpad xsetroot # See [[Emojis]] to complete installation
   sudo apk add xf86-input-mouse xf86-input-keyboard
   sudo apk add xf86-input-libinput # or -evdev if libinput doesn't work


Then, set the desktop:
Then, set the desktop:
Line 470: Line 495:
== Hacking mkinitfs to support cryptsetup with GPG keys ==
== Hacking mkinitfs to support cryptsetup with GPG keys ==


You may want to hack the mkinitfs init script and rebuild the package depending on what methods you useYou could possibly have a complex way to hide your GPG keys (again enhancing plausible deniability) with steganography or extend it with three-factor authentication which adds biometrics along side with mind and physical.
This section describes how to assemble a custom initscript chain in multiple partsIt could be extended with three-factor authentication which adds biometrics along side with mind and physical object.
 
Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded.  This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.
 
Here is the steps required so that the facade initscripts and dependencies are free from encryption.
* You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below.  You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.
* You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.


See [https://github.com/alpinelinux/mkinitfs/tree/master https://github.com/alpinelinux/mkinitfs/tree/master], in particular mkinitfs.in and nlplug-findfs.c.
Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:
* You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.
* You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.
* You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.


You will modify /usr/share/mkinitfs/initramfs-init to add cryptsetup-gpg support. Then, you reinstall your kernel and it should automatically place the init script to your boot device. Also save a backup of this script in case a new version destroys it.  It is recommended that your boot scripts do not directly refer to the key to preserve plausible deniability which can be achieved by additional prompts and regular expression and possibly store the key on another USB thumb drive or alternative device separate from the bootloader to have true two factor authenticationYou don't want to give hint that this random data which some might jump to conclusion to as being key is associated with the boot process just because many people have duplicated the instructions in adding full disk encryption.  You will manually call the cryptsetup command possibly or the renamed version of it.  Once you present a password prompt immediately at the boot process, it invites the rubberhoser.
You need to create a custom init continuation script:
* Your initscript should drop into single mode which you will mount the encrypted path manually.
* You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.
* You will run the custom init continuation script manually.
* This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdiskThis will then automate the mounting of the encrypted driveThis resume continuation script should handle both cold boot and hibernate.
* You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.


The encrypted bootloader or init scripts could possibly be designed to immediately boot to the facade partition but then special secret unique boot selection keypresses to present the special menu go redirect towards the encrypted partition but not explicitly saying that it is encrypted.
If you use a USB keyboard, you will unlock the encrypted devices in early userspace. You will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs.  You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized <code>/etc/mkinitfs/features.d/usb-keyboard.modules</code>.  It should be separate from usb.modules because apk updates may overwrite it.  Use the <code>lsmod</code> utility from the kmod package to find what drivers your USB keyboard uses.


Also, you may want to rename dm-crypt, cryptroot, cryptdm to alias to an identifier facade and possibly rename the modules and folders and cryptsetup (which may require a recompile)Again, we do not want to present hints to motivate the attacker of the possibility that such an encrypted device exists to avoid the rubberhose attack.
You need to generate the final mkinitfs.
First you need the kernelversion to pass into mkinitfs.  To obtain that information do <code>ls /lib/modules</code> which will show some folders.  Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:


If your device uses plain dm-crypt, it needs the initscript modified near the nlplug-findfs commands. The line could be found in [https://github.com/alpinelinux/mkinitfs/blob/e95fe8f4fadcf6b496ba8198f091fe04d16ec203/initramfs-init.in#L392 initramfs-init.in at line 392 (on GitHub)], or call it manually.
  sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion


Encrypted hibernate also needs GPG key support.  Maybe change [https://github.com/alpinelinux/mkinitfs/blob/e95fe8f4fadcf6b496ba8198f091fe04d16ec203/initramfs-init.in#L403 initramfs-init.in at line 403 (on GitHub)], or call it manually.
The $HOMEDIR should be replaced with the full path if you are not root.


==  Install the bootloader in the USB thumb drive ==
==  Install the bootloader in the USB thumb drive ==
Line 502: Line 542:
   nano /boot/grub/grub.cfg
   nano /boot/grub/grub.cfg


'''You need to customize the initramfs in order to use GPG keys since there is no support from it.'''  The steps here below assumes that these custom initramfs features have been implemented.
'''You need to customize the initramfs in order to use GPG keys since there is no support from it.'''   
 
The steps here below assumes that these custom initramfs features have been implemented
 
The following boot loader settings is '''not sufficient''' for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu.  To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned.  These configurations should be considered an intermediate form for used in debugging purposes.  In addition, the attacker just can inspect grub.cfg files directly.


The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.
The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.
Line 624: Line 668:
=== USB key udev rule ===
=== USB key udev rule ===


You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key.  When you come back on, you should do 2 factor authentication to restore back everything.  Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.
You need to add a new [[udev]] rule that will suspend-to-ram or hibernate and log off once you pull the USB key.  When you come back on, you should do 2 factor authentication to restore back everything.  Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.


To find out the details of your USB do:
To find out the details of your USB do:
Line 683: Line 727:


== Extending battery life ==
== Extending battery life ==
'''WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.'''


=== ACPI ===
=== ACPI ===
Line 763: Line 809:


   sudo rc-update add cpufreqd
   sudo rc-update add cpufreqd
=== LCD screen refresh rate ===
The refresh rate sets the maximum framerate.  The more frames pushed the more energy consumed on the battery.  You want this adjusted dynamically per certain events.  For gaming, you want it to be the highest as possible for the laptop and vsync off.  For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply.  You can adjust the framerate with xrandr.  For movies and YouTube, you want 60FPS and vsync on.


== Hacking the kernel ==
== Hacking the kernel ==
Line 797: Line 847:
You also need to add those services:
You also need to add those services:


   rc-update add chrony
   rc-update add chronyd
   rc-update add wpa-supplicant
   rc-update add wpa_supplicant
   rc-update add dhcpcd
   rc-update add dhcpcd
   rc-update add networkmanager
   rc-update add networkmanager
Line 804: Line 854:
To start the services manually (or just reboot):
To start the services manually (or just reboot):


   /etc/init.d/chrony start
   rc-service chronyd start
   /etc/init.d/wpa-supplicant start
   rc-service wpa_supplicant start
   /etc/init.d/dhcpcd start
   rc-service dhcpcd start
   /etc/init.d networkmanager start
   rc-service networkmanager start


== Additional tools ==
== Additional tools ==
Line 819: Line 869:
=== secure-delete ===
=== secure-delete ===


Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands?  This maybe could work who knows?
Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands?  This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.


To install secure-delete do:
To install secure-delete do:
Line 825: Line 875:
   sudo apk add secure-delete
   sudo apk add secure-delete


smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete]  If you use the vanilla kernel, this may work.  If you use grsecurity, it will automatically sanitize memory [unconfirmed if enabled] when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]
smem only works for unused ram.[https://github.com/gordonrs/thc-secure-delete]  If you use the vanilla kernel, this may work.  If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory]


Close all important programs then call smem.
Close all important programs then call smem.
Line 853: Line 903:
If you lose or break your USB key, that is it and you cannot decrypt your drive.  It would be wise to make a backup of it.
If you lose or break your USB key, that is it and you cannot decrypt your drive.  It would be wise to make a backup of it.


I don't know if suspend-to-ram or hibernate sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack.  This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor]  This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor].  This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux.  TRESOR doesn't work with DMA attack.  The 32-bit version of TRESOR has only a key size of 128.  The AES-NI version of TRESOR has a largest key size of 256 bit.  See [[Setting_up_a_laptop#Getting_the_available_ciphers | Getting the available ciphers]] for the number of rounds cracked.
By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack.  This has been covered by the TRESOR kernel patch.[https://en.wikipedia.org/wiki/TRESOR][https://www1.cs.fau.de/tresor]  This patch hasn't been updated since the 4.x kernel series.[https://www1.cs.fau.de/tresor].  This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux.  TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.303.3053&rep=rep1&type=pdf] The 32-bit version of TRESOR has only a key size of 128.  The AES-NI version of TRESOR has a largest key size of 256 bit.  See [[Setting_up_a_laptop#Choosing_ciphers | Choosing ciphers]] for the number of rounds cracked.


Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [http://moongate.ydns.eu/amnesia.html]
Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [https://moongate.ydns.eu/amnesia.html]


Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.
Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[https://en.wikipedia.org/wiki/Cold_boot_attack] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.
If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop.  This guide doesn't protect you from that possibility.  If you do not want to be rubberhosed, don't possess those devices.
Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:
Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[https://en.wikipedia.org/wiki/DMA_attack]
Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.
You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any.  For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[https://youtu.be/XfUlRsE3ymQ]


[[Category:Installation]]
[[Category:Installation]]
[[category: desktop]]

Latest revision as of 10:16, 17 November 2023

This material is work-in-progress ...

Do not follow instructions here until this notice is removed.
(Last edited by Sertonix on 17 Nov 2023.)

This guide is about a project to create a secured laptop. For this project we take in consideration ways to extend battery life. It covers tools and daemons that are must haves for a laptop setup.

Guide features

  • Deniable full disk encryption
  • Two factor authentication (physical object (USB key), mind)
  • Encrypted swap and hibernation
  • Encrypted home on top of encrypted drive
  • Memory sanitation
  • Dynamic power modes
  • Feature keys support

Rubberhose Attack

Just a reminder that all attacks are subjected to the Rubberhose Attack dilemma, you either give up your encryption keys or be tortured with a rubberhose with the possibly of death. See Wikipedia article. We try to present deniable encryption (Wikipedia) to avoid a rubberhose attack scenario. In this article we use the words plausible deniability interchangeably with deniable encryption. To achieve this we use a facade and require no metadata fingerprints to expose or hint of encrypted or hidden containers or hint as in detect of existence of an encrypted disk. The keys should be stored using steganography where we dilute the randomness into the facade. It also requires you not to brag about encryption or mention it because that is an invitation for the attacker to torture the victim. Deniable encryption requires you not put encrypted as an entry title to your bootloader. There shouldn't be an entry for your facade bootloader to the encrypted drive.

Why full disk?

The full disk encryption provides sort of some plausible deniability or a valid alibi that you didn't encrypt it. Is the drive just random noise, broken, or is it really encrypted? The other reason is that it implies that everything is protected.

But there could be problems if not done right. For example, cryptsetup does leave a plaintext marking or some hints by default that it has been encrypted when using luks/luks2 mode if a detached header with option --header <path> is not presented.[1][2] To gain credibility that we didn't really do the encryption, you have to wipe the +3 MiB region based on the number of key slots used; or store the headers on an external device.

If you did deniable encryption incorrectly, it is possible to erase and restore the header. This presents an opportunity to improve obfuscation. When you pull out the USB key, it should erase the header but store it on the USB key atomically as in completely. If you plug in the USB key, it will restore back the header. cryptsetup has luks actions luksHeaderBackup and luksHeaderRestore to do this.

Starting at the beginning

Grab a USB thumb drive with Alpine. Set it up as usual but don't let it touch your drive yet. Then, install all the tools into memory ramdisk but not in the hard drive yet. The hard drive will be obliterated.

You will then install Alpine using the steps:

First you need WiFi, to get it run do the command below but say no or skip the hard drive setup stuff:

 setup-alpine

Then, you need to install some tools into RAM temporarly:

 apk add e2fsprogs grub grub-bios grub-efi mkinitfs nano

Randomizing the drive with pseudorandom urandom entropy

The first part is to erase the drive with random noise but in practical time. There are many techniques to do this but should be done in one day or two minimum.

You can use shred or dd to accomplish this depending on your needs and the availability of entropy. Some techniques take longer. Cryptologist Bruce Schneier recommended 7 times with specified pattern. See Wikipedia Article. For practical purposes, we just do it random in one pass. It should be random so that the facade of random noise hides the encrypted data which resembles noise.

To list the drives on the system do fdisk -l.

IMPORTANT: make sure you wipe the right specific drive.

To wipe the disk with random entropy do:

 dd if=/dev/urandom of=/dev/sda

Creating GPG keys

As of this time, Alpine's mkinitfs does only one factor authentication with passphrase. You need to manually edit the initramfs-init.in in mkinitfs to support two factor authentication using cryptsetup.

After you have scrambled the drive, you want to create your GPG keys. You will use these keys to set the password(s) for your cryptsetup-luks partitions. These keys should be stored on a USB thumb drive or other memory device but should not be on the USB boot thumb drive or on the encrypted drive. The key should be a random 128 bit key wrapped in GPG and protected with a password.

If you are using x, you need to do sudo apk add pinentry-gtk to display password prompt properly for the next step.

To install openssl and gpg do:

 apk add openssl gnupg

Then, to generate a key:

 export GPG_TTY=$(tty) && openssl rand -base64 512 | gpg --symmetric --cipher-algo aes --armor > /mnt/usb/$(openssl rand -hex 12)

(Make sure your usb is mounted on /mnt/usb first.)

The long file name comes from openssl rand -hex 12 so that we enhance plausible deniability. The attacker cannot determine the purpose of the key. Is it used for GitHub? for Email?

The first part will produce 512 random bytes in wrap it in base64. The random data will be piped to gpg which will wrap it in AES as ciphertext which again gets wrapped in base64 ascii armor. For every partition including swap in some cases, you should create more gpg keys and store them in your USB thumb drives. After you have produced your gpg keys, you will then use them as a password for cryptsetup/luks.

You can replace aes above with the ones listed in gpg --version.

There should be a password generated for the swap. This is to resume for your hibernate. If you don't want to hibernate, then password is not required and all you need to do is to create/format the partition each time you boot without a password or with a one time random password.

Hiding the keys using steganography

WARNING: This section is considered experimental. It requires the tool and the dependencies to be placed on another USB separate from the key files, the bootloaders, and encrypted disks. The tool and dependencies need to be packaged together. We decentralize these components so that the attacker doesn't connect the dots easily or immediately jumps to the conclusion for the requirements to decrypt. Steghide automatically uses 128-bit AES in CBC mode to encrypt data. This can be change if you don't like or trust AES with the -e option. Use steghide encinfo for other ciphers and modes.

Fortunately, Alpine has a package for steganography called steghide. To install steghide do:

 apk add steghide

You will place the keyfile in an image file. The facade image file should be large enough that there is no apparent discernible difference between the original and the modified. Do not use a small image with a small filesize.

As mentioned previously luks headers could be 3MB large or more and an jpeg image file is not suitable. Use another format like .au/.wav or another steganography utility that handles mp3s. The mp3/wav should be fairly large enough to dilute the header. So, something with long content is suitable.

There are two basic commands to use with steghide embed and extract,

To embed do:

 steghide embed -ef key.gpg -cf image.jpg

To extract do:

 steghide extract -xf key.gpg -sf image.jpg

To get a file list of files to ship out, use:

 apk info -L libgcc libmcrypt libmhash libstdc++ libjpeg-turbo steghide

Full disk encryption with with cryptsetup-luks volumes

Partitioning scheme

This section presents a conceptual layout. It should not be a knee-jerk approval to automatically use the partition tool which would compromise your plausible deniability.

For the facade, we use an Ubuntu Live CD (or less skilled distro) to present the impression that we are not sophisticated or tech savvy enough to implement encryption. Windows is also acceptable even better. The immutable Live CD and immutable partition ensures that you are not compromised by a third party attacker that implants evidence.

There could be possibly two bootloaders, one for the facade and the other to the encrypted drive stored on an external device.

Luks

Plausible deniability only works if you can demonstrate no existence of partitions 2, 3, 4 and no fingerprints/plaintext introduced by cfdisk and cryptsetup-luks. Use something like TestDisk, fdisk -l, or gparted and a disk editor (hex editor for disks).

# Name Mount point Notes
1 facade / (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.
2 swap It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.
3 root /
4 rescue / This should contain the Alpine image.

Plain dm-crypt

Plausible deniability only works if you are able to present #2 as being unused space or untampered. To check use something like TestDisk, gparted and a disk editor (hex editor for disks).

# Name Mount point Notes
1 facade / (optional) The facade partition contains a pristine normal operating system or Ubuntu Live CD image to lure the attacker in attempt to boost the confidence of the attacker convincing them that there is no encryption on the device.
2 vgroot
2_1 vgroot-root /
2_2 vgroot-swap It should be the same size as your ram for x86_64. Rationale: it should contain the whole ram image.
2_3 vgroot-rescue / This should contain the Alpine image.

Installing cryptsetup

To install cryptsetup you need the package below

 apk add cryptsetup

Choosing ciphers

When you create your luks drives, you need to decide on the type of ciphers and hashing techniques to use. The ciphers that you want to use are ones are up to you, but it should be one that is hasn't been cracked yet or has not suffered a lot of cryptanalysis attacks. The ones that you might want to use is AES which is hardware accelerated in some Intel CPUs that have the AES-NI cpuflag which you can check by cat /proc/cpuinfo. Also consider the ciphers that are SIMD optimized such as serpent and twofish that are available in the Linux kernel. Also consider ciphers that are unpopular but known to be secure such as Blowfish (which Wikipedia claims to be attacked and the author recommended Twofish).[3] If it is hardware accelerated, it will save battery life and minimize CPU usage.

For some ciphers weakness also see Cipher security summary (Wikipedia).

For some hash function weaknesses also see Hash function security summary (Wikipedia).

Generally speaking, the swap partition should use a fast cipher. You want to lower the latency or delay of the memory subsystem as a consequence of being encrypted.

IMPORTANT: Please read the Important notes section for details about the problems with AES encryption.

If you don't trust AES shills and endorsed by the NSA, you can try another different one. Another advantage of using a public vetted cipher is that it provides confidence that it works.

Something like KHAZAD wouldn't work on cryptsetup benchmark. KHAZAD itself is insecure. Wikipedia reported 5 out of 8 rounds been cracked.[4]

For AES-128 7 out of 10, AES-192 8 out of 12, AES-256-bit 9 out 14 rounds have been cracked according to Wikipedia.[5]

IMPORTANT: Do not use sha1 as the hashing algorithm. It already has already been compromised.

Getting the available ciphers

To check the availability of a cipher or hash function use:

 find $(find /lib/modules -name "crypto" -type d) -type f -name "*.ko" | sort

To check if a cipher is loaded and passed its own tests use:

 cat /proc/crypto

To test some popular ciphers and hashes do:

 cryptsetup benchmark

The top set is associated with the hashing algorithms. The bottom set are the ciphers. Use the commands below but replace the cipher and/or hash algorithm with your preferences.

cryptsetup benchmark actually doesn't show all the ciphers like Anubis. The cipher should also have CBC and/or XTS block cipher mode of operation to encrypt larger block sizes. AES for example has a block size of 128.

To test if the unpopular but uncracked cipher works use sometime like:

 cryptsetup benchmark --cipher anubis

General steps for cryptsetup

Original method with fdisk with no plausible deniability

In this method --type luks is implied which generates metadata.

If you want plausible deniability for luks, you need to pass --header <path> to all the luks commands, where <path> is a unix path like /mnt/usb/d6ae10eda66704c8. The random name comes from openssl rand -hex 8. The header is transferred to the external device (but no mention of the key slot area but ciphertext being transferred) in the man page. The information in that file should be obfuscated with encryption if there is plaintext or fingerprint in it just in case. Then, it should be decrypted when reused.

You need to install cfdisk if you prefer the interactive ncurses console method:

 apk add cfdisk
# Step Command
1 Use cfdisk to create partitions. Make two partitions--a system partition and a swap partition cfdisk
2 Create and format the luks device cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda1 /mnt/usb/$(ls)
3 Open the luks device cryptsetup --key-file /mnt/usb/$(ls) luksOpen /dev/sda1 root
4 Format the decrypted drive with filesystem mkfs.ext4 /dev/mapper/root
5 Create the mount point mkdir -p /mnt/root
6 Mount the root partition mount /dev/mapper/root /mnt/root
7 Create swap cryptsetup -c blowfish -h sha256 -d /dev/urandom --key-file /mnt/usb/59022506d9f4a714 create swap /dev/sda2
8 Use swap mkswap /dev/mapper/swap && swapon /dev/mapper/swap

Improved method with plausible deniability

This method requires lvm2. To install:

 apk add lvm2
# Step Command
1 Open the plain dm-crypt device generating no metadata cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/$(ls) /dev/sda pvroot
2 Physical volume create with LVM pvcreate /dev/mapper/pvroot
3 Volume group create with LVM vgcreate vgroot /dev/mapper/pvroot
4 Logical volume create the swap volume with LVM lvcreate -L 4G vgroot -n swap
5 Logical volume create the root volume with LVM lvcreate -L 2T vgroot -n root
6 Logical volume create the rescue volume with LVM lvcreate -L 110M vgroot -n rescue
7 Format the root volume with filesystem mkfs.ext4 /dev/mapper/vgroot-root
8 Format the swap volume and activate it mkswap /dev/mapper/vgroot-swap && swapon /dev/mapper/vgroot-swap
9 Format the rescue volume with filesystem mkfs.ext4 /dev/mapper/vgroot-rescue
10 Create mount point for root volume mkdir -p /mnt/root
11 Mount the root volume mount /dev/mapper/vgroot-root /mnt/root

Configuring OpenRC dmcrypt and setting up fstab

You need to tell OpenRC init scripts to decrypt the volumes. See /etc/conf.d/dmcrypt.

You need to add the service to boot well because it needs to decrypt the root volume before OpenRC starts running commands from it. So you need to do:

 rc-update add dmcrypt boot

dmcrypt

The dmcrypt OpenRC service will attempt to decrypt the drive using information provided in /etc/conf.d/dmcrypt.

For luks:

Contents of /etc/conf.d/dmcrypt

# Mounting root may not be necessary since it is already mounted. target=root source='/dev/sda1' key='/mnt/usb/2a667ec72774b0d5' swap=swap source='/dev/sda2' key='/mnt/usb/59022506d9f4a714'

For plain dm-crypt:

Contents of /etc/conf.d/dmcrypt

# Mounting root is likely not required since you already mounted it before OpenRC starts to do its thing. target=root source='/dev/sda' key='/mnt/usb/2a667ec72774b0d5' options='--type plain --cipher aes-cbc-essiv:sha256 --key-size 256' swap=swap source='/dev/sda2' key='/mnt/usb/59022506d9f4a714' pre_mount='vgchange -ay vgroot ; lvchange -ay vgroot/swap'

dm-crypt will just mount the encrypted plain dm-crypt drive or the luks partition. What you need to do next is set up fstab located at /etc/fstab. Examples are shown below.

/etc/fstab

To mount plain dm-crypt device with fstab:

Contents of /etc/fstab

/dev/sdb /boot ext4 defaults 0 0 /dev/mapper/root / ext4 defaults 0 1 /dev/mapper/swap none swap sw 0 0

To mount lvm volumes with fstab:

Contents of /etc/fstab

/dev/sdb /boot ext4 defaults 0 0 /dev/mapper/vgroot-root / ext4 defaults 0 1 /dev/mapper/vgroot-swap none swap sw 0 0

How to recover from a bad setup

Many times you will not get it right perfectly the first try. To recover from this situation, you need to reopen the plain dm-crypt drive or the luks drive and then remount everything back.

To recover from luks:

 cryptsetup --key-file /mnt/usb/2a667ec72774b0d5 luksOpen /dev/sda1 root
 mkdir -p /mnt/root
 mount /dev/mapper/root /mnt/root

To recover from the plain dm-crypt:

 cryptsetup open --type plain --cipher aes-cbc-essiv:sha256 --key-size 256 --key-file /mnt/usb/$(ls) /dev/sda root
 vgchange -ay vgroot
 lvchange -ay vgroot/root
 mkdir -p /mnt/root
 mount /dev/mapper/vgroot-swap /mnt/root

Next step: Full blown Alpine installation

We will setup the /mnt/root encrypted partition:

 apk add --root=/mnt/root --initdb $(cat /etc/apk/world) --keys-dir /etc/apk/keys --repositories-file /etc/apk/repositories

Then, enable edge repositories in both files including community and testing:

 nano /etc/apk/repositories /mnt/root/etc/apk/repositories

Then, copy the necessary files:

 cp /etc/resolv.conf /mnt/root/etc

Then, install the basic utils:

 apk add --root=/mnt/root dhcpcd chrony networkmanager wireless-tools wpa_supplicant
 apk add --root=/mnt/root grub mkinitfs e2fsprogs grub-bios grub-efi
 apk add --root=/mnt/root sudo nano
 apk add --root=/mnt/root linux-lts

Then, you need to mount your usb on to /boot:

 mount /dev/sdb /boot

Edit grub:

 nano /boot/grub/grub.cfg

Then, install grub on the usb:

 grub-install --force /dev/sdb

Then, prepare chroot:

 mount --bind /dev /mnt/root/dev
 mount --bind /sys /mnt/root/sys
 cp /etc/reslov.conf /mnt/root/etc

Then, chroot:

 chroot /mnt/root /bin/sh

Set the root administrator password:

 passwd

The root password should be very difficult to deter you from using it and force you to use sudo

Edit sudo so that wheel group has administrative :

 EDITOR=nano visudo

Set:

 ## Uncomment to allow members of group wheel to execute any command       
 %wheel ALL=(ALL) ALL                                                 

Then, add wheel (administrator) user:

 useradd -m myname
 usermod -a -G video,audio,wheel myname

log in that user:

 su myname

Then, update and upgrade it

 sudo apk update
 sudo apk upgrade

Then, setup xorg:

 sudo setup-xorg-base
 sudo apk search xf86-video | sort
 # pick your xf86 video driver
 sudo apk add xf86-video-amdgpu
 # install the mesa driver
 sudo apk add mesa-dri-gallium  

Then, keep piling on:

 sudo apk add firefox dwm xfce4-terminal alsa-utils keepassx xfce4 xchat
 sudo apk add font-noto-emoji font-terminus leafpad xsetroot # See Emojis to complete installation
 sudo apk add xf86-input-libinput # or -evdev if libinput doesn't work

Then, set the desktop:

 nano .xinitrc

Put both but comment with a # one of them if you don't want it,

 #while true; do xsetroot -name "$( date +"%a %b %d %I:%M:%S %Y" )" ; sleep 1; done &
 #exec dwm
 exec xfce4-session

For the above xsetroot statement used to provide information in the statusbar for dwm, consider adding information about the battery level. This information can be found in sysfs at /sys/class/power_supply/BAT0/.

 sync
 sudo reboot

Hacking mkinitfs to support cryptsetup with GPG keys

This section describes how to assemble a custom initscript chain in multiple parts. It could be extended with three-factor authentication which adds biometrics along side with mind and physical object.

Most entry to secure systems are not fully automated or do not allow things to quickly pass through freely and often guarded. This process may seem like a hassle, but it should dissuade the rubberhosers from jumping to the conclusion of the possibility of the existence of a encrypted drive.

Here is the steps required so that the facade initscripts and dependencies are free from encryption.

  • You will separate and archive cryptsetup, ciphers kernel modules, hash function kernel modules, and any additional obfuscation dependencies, and another continuation initscript discussed below. You need to make sure that you copy /etc/mkinitfs/mkinitfs.conf to your home directory and strip out those features without those modules.
  • You will hide this archive in a mp3 file with another tool you will package or you can use steghide's .au/.wav support, but .au seems too conspicuous or strange by current trends.

Here we try to clean up the facade so that it presents itself as free without cryptography. You need the following changes to your initramfs to avoid a sensitive rubberhoser:

  • You will delete everything in the custom initramfs-init referring to encryption. This includes cryptroot, cryptdm, crypt-anything, etc init options.
  • You need to delete references in nlplug-findfs to cryptsetup and recompile the mkinitfs package.
  • You could program the init script to boot into a facade partition but drop into sh if a hidden special keypress sequence is met.

You need to create a custom init continuation script:

  • Your initscript should drop into single mode which you will mount the encrypted path manually.
  • You will manually steg-unhide the encrypted archive hidden in the mp3 file and extract it to the ramdisk.
  • You will run the custom init continuation script manually.
  • This custom init continuation will automate the process of extracting the gpg keys from another device and image files into the ramdisk. This will then automate the mounting of the encrypted drive. This resume continuation script should handle both cold boot and hibernate.
  • You will finish resuming running the other half of mkinitfs-init or specifically where the points after where it typically will mount cryptsetup and hibernate devices.

If you use a USB keyboard, you will unlock the encrypted devices in early userspace. You will need to either compile the USB keyboard drivers in the kernel or you need to add additional modules when generating the mkinitfs. You will need the hid, hid-generic, ehci-hcd, uhci-hcd, usbcore driver and add those paths in a customized /etc/mkinitfs/features.d/usb-keyboard.modules. It should be separate from usb.modules because apk updates may overwrite it. Use the lsmod utility from the kmod package to find what drivers your USB keyboard uses.

You need to generate the final mkinitfs. First you need the kernelversion to pass into mkinitfs. To obtain that information do ls /lib/modules which will show some folders. Once you found it pass it to mkinitrafs by doing and replacing kernelversion below:

 sudo mkinitramfs -i $HOMEDIR/initramfs-init -c "$HOMEDIR"/mkinitfs.conf kernelversion

The $HOMEDIR should be replaced with the full path if you are not root.

Install the bootloader in the USB thumb drive

To install grub, you need to install grub on the ramdisk first on the host.

 apk add grub

To get a list of partitions

 fdisk -l

Mount the boot partition in /boot

 mount /dev/sdb /boot

Make changes to grub's configuration

 nano /boot/grub/grub.cfg

You need to customize the initramfs in order to use GPG keys since there is no support from it.

The steps here below assumes that these custom initramfs features have been implemented.

The following boot loader settings is not sufficient for deniable encryption because it exposes the fact that an encrypted drive exists because an attacker can discover that encryption was used through the edit option of the grub menu. To protect yourself from a rubberhose attack, you really need to customize the initramfs so that references to anything mentioning encryption, ciphers, hashing are not explicitly mentioned. These configurations should be considered an intermediate form for used in debugging purposes. In addition, the attacker just can inspect grub.cfg files directly.

The following are just examples to just get it working but should be modified so that it doesn't hint to the rubberhoser of a hidden partition or encrypted partitions.

The entry should look like:

For 'luks'

Contents of /boot/grub/grub.cfg

default=0 timeout=0 menuentry 'Windows 10' { set root=(hd0,2) chainloader +1 } menuentry 'Alpine Linux' { set root=(hd1,1) linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda1 cryptdm=root initrd /initramfs-hardened } menuentry 'Alpine Linux (Rescue)' { set root=(hd1,1) linux /vmlinuz-hardened root=/dev/mapper/root rw modules=sd-mod,usb-storage,ext4,dm-crypt,aes-x86_64,sha256-mb cryptroot=/dev/sda4 cryptdm=root initrd /initramfs-hardened } if keystatus; then if keystatus --ctrl; then set timeout=-1 else set timeout=0 fi fi

For 'plain dm-crypt':

The stock mkinitfs may not support plain dm-crypt. It looks like it only supports luks. Customization of the initramfs is required.

Contents of /boot/grub/grub.cfg

default=0 timeout=0 menuentry 'Windows 10' { set root=(hd0,2) chainloader +1 } menuentry 'Alpine Linux' { set root=(hd1,1) linux /vmlinuz-hardened root=/dev/mapper/vgroot-root rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=root initrd /initramfs-hardened } menuentry 'Alpine Linux (Rescue)' { set root=(hd1,1) linux /vmlinuz-hardened root=/dev/mapper/vgroot-rescue rw modules=sd-mod,usb-storage,ext4,dm-crypt,dm-mod,dm-snapshot,aes-x86_64,sha256-mb cryptroot=/dev/sda cryptdm=rescue initrd /initramfs-hardened } if keystatus; then if keystatus --ctrl; then set timeout=-1 else set timeout=0 fi fi

The source code of grub could possibly be modified and recompiled to use other non-standard keys. See [6]. Ideally, it should be not so obvious or accessible for the attacker.

The above grub.cfg is applied to the USB bootloader. For the facade bootloader, you just want the Windows 10 or Ubuntu entry, nothing more.

For the modules parameter, you need to add your crypto modules. Use find /lib/modules/ -name "*aes*" where aes is the basename for your cipher or hash algorithm Use blkid to obtain the UUID of your device

Install it to your USB thumb drive

 grub-install /dev/sdb

Home mounting with eCryptfs

We use eCryptfs to encrypt home. The rationale for having another encrypted file system is that if you leave your laptop unattended on break or accidentally leave your USB key in, your data will not be accessible. The other rationale is that if another person wants to use your computer, you can just log off and the data will be kept hidden and encrypted. When you log off due to inactivity, your home directory will be unmounted and encrypted. eCryptfs will encrypt/decrypt the filename and the contents and will sit on top of ext4 which sits on top of luks.

To install ecryptfs-utils:

 sudo apk add ecryptfs-utils

This does one factor authentication mostly with just the password, but it should be modified to use the USB key too. You need to reconfigure pam with the pam_usb.so which is not in Alpine aports.

You need to use the pam_ecryptfs PAM module.

Locking it down

Many times you will leave your laptop behind with people you trust. The following tools will help lock down the system.

physlock

This will auto lock the tty and when you return will prompt for password.

To install physlock:

 sudo apk add physlock

It is currently bugged. See [7]. physlock likely doesn't do two-factor authentication but it should.

You need to create custom script that will monitor idle time in TTY then call physlock. You load this script when you log on.

xscreensaver

This will lock you out of xserver

To install xscreensaver:

 sudo apk add xscreensaver

USB key udev rule

You need to add a new udev rule that will suspend-to-ram or hibernate and log off once you pull the USB key. When you come back on, you should do 2 factor authentication to restore back everything. Hibernation and suspend-to-ram might mitigate cold-boot attack (but unlikely see notes at the bottom of the page) to extract plaintext private data and encryption keys in memory.

To find out the details of your USB do:

 udevadm monitor --udev -p

The output should look like:

UDEV  [181762.722853] add      /devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc (block)
ACTION=add
DEVLINKS=/dev/disk/by-id/usb-Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0 /dev/disk/by-path/pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0 /dev/disk/by-uuid/5A96-03E4
DEVNAME=/dev/sdc
DEVPATH=/devices/pci0000:00/0000:00:13.2/usb2/2-5/2-5:1.0/host6/target6:0:0/6:0:0:0/block/sdc
DEVTYPE=disk
ID_BUS=usb
ID_FS_TYPE=vfat
ID_FS_USAGE=filesystem
ID_FS_UUID=5A96-03E4
ID_FS_UUID_ENC=5A96-03E4
ID_FS_VERSION=FAT32
ID_INSTANCE=0:0
ID_MODEL=MSFT_NORB
ID_MODEL_ENC=MSFT\x20NORB\x20\x20\x20\x20\x20\x20\x20
ID_MODEL_ID=1645
ID_PATH=pci-0000:00:13.2-usb-0:5:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_13_2-usb-0_5_1_0-scsi-0_0_0_0
ID_REVISION=PMAP
ID_SERIAL=Kingston_MSFT_NORB_MSFTLAKDA300EB3021790009-0:0
ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009
ID_TYPE=disk
ID_USB_DRIVER=usb-storage
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=Kingston
ID_VENDOR_ENC=Kingston
ID_VENDOR_ID=0951
MAJOR=8
MINOR=32
SEQNUM=2027
SUBSYSTEM=block
USEC_INITIALIZED=1762722168

You want to extract the ID_SERIAL_SHORT=MSFTLAKDA300EB3021790009 or whatever is associated with your USB thumb drive.

You need pm-utils for ps-suspend. So to install it do:

 sudo apk add pm-utils

You will create a udev rules so that when you pull out the USB, it will suspend-to-ram or you can use your own script. To do that create a file with the following contents:

Contents of /etc/udev/rules.d/50-usb-thumb-drive.rules

ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="MSFTLAKDA300EB3021790009", RUN+="/usr/sbin/pm-suspend"

Extending battery life

WARNING: If you do not use the proper mitigation for cold boot attack, you are better off auto-shutdowning the laptop instead of using suspend or hibernate.

ACPI

ACPI is a good daemon to use to execute certain scripts when laptop events are triggered.

To install ACPI do:

 apk add acpi

The events to pay attention to are:

Event ACPI Event What your script should do
lid close log off ttys and suspend-to-ram. ALSA should either set the volume to 0 for the sound card or the sound driver be unloaded. It might be a good idea to kill or mute any music or movie players if the sound loops loudly after lid open.
lid open lock all ttys and all xservers should be locked, possibly reinitialize ALSA and the sound system.
tapped power button lock all ttys and suspend-to-ram
held power button hibernate
unplugged power should switch to 'conservative' cpufreq governor at above 25% power ; 'powersave' governor at 25%. set hdparam spindown rate lower.
plugged power should switch to 'performance' governor. disable hdparam spindown.

The purpose of the power governor is to regulate the running frequency (GHz) of the processor.

Certain event handlers are are managed through laptop-mode-tools. If you don't want the dependency, then you could write ACPI handler scripts.

acpi_listen can be used to retrieve the event name.

TODO: put scripts below

Adjusting the backlight dynamically

The backlight may be controlled using sysfs. The setting is a descendant of /sys/class/backlight/. The feature may allow you to echo a value to it. Use trial and error to discover the values.

The adjustment of the backlight should be function of battery life. So if it is like 33% battery life, you want to run it near lowest settings but readable. For 50 percent battery energy maybe 40% light. For 90% battery maybe 75% light.

hdparm

To install hdparam do:

 sudo apk add hdparm

The settings that laptop-mode-tools messes with is the -S or the spindown timeout. It was also hinted that acoustic setting -M is associated with the speed meaning that louder is faster and quieter is slower which could contribute to the amount of energy used or reduced.

Again you want something like laptop-mode-tools or ACPI to dynamically adjust the settings based on ACPI events.

laptop-mode-tools

This is currently not in aports but worthy mentioning. It should really be packaged. This is a set of scripts to define a power policies. You can manage all the settings in one place here like the hard drive idle spindown time, CPU governor control, dynamic LCD backlight behavior based on running on battery or AC power supply.

cpufreqd

This is a useful daemon for regulating power.

To install cpufreqd do:

 sudo apk add cpufreqd

Make sure you add the service:

 sudo rc-update add cpufreqd

LCD screen refresh rate

The refresh rate sets the maximum framerate. The more frames pushed the more energy consumed on the battery. You want this adjusted dynamically per certain events. For gaming, you want it to be the highest as possible for the laptop and vsync off. For battery use and traveling, you want it capped at 60 FPS/60 Hz or lower but dynamically adjust when you plug in the AC power supply. You can adjust the framerate with xrandr. For movies and YouTube, you want 60FPS and vsync on.

Hacking the kernel

You should refer to the Custom Kernel page for details.

Hibernation

See Hibernation to prevent data loss.

WiFi management

Since you are using WiFi, you need a better WiFi management to quickly find open access WiFi access points. We don't have all day to debug complexities of WiFi settings while away from home.

To install NetworkManager do:

 sudo apk add networkmanager

To find WiFi access points use the nmtui ncurses interface.

You also need other programs so install them as well:

 apk add wpa-supplicant dhcpcd chrony macchanger wireless-tools iputils

What these programs do:

  • wpa-supplicant -- for WPA encryption
  • dhcpcd -- for getting a dynamic IP address
  • chrony -- for fixing the time with the atomic clock
  • wireless-tools -- for additional information
  • macchanger -- for protecting against WiFi access discrimination or increased anonymity. (optional)
  • iputils -- for the ping command (optional)

You also need to add those services:

 rc-update add chronyd
 rc-update add wpa_supplicant
 rc-update add dhcpcd
 rc-update add networkmanager

To start the services manually (or just reboot):

 rc-service chronyd start
 rc-service wpa_supplicant start
 rc-service dhcpcd start
 rc-service networkmanager start

Additional tools

actkbd

To control the sound with fn function keys, you need this daemon. It is currently not in aports. You could override the design and meaning of those keys with your own scripts and utilities. This daemon gives you that freedom.

If your laptop contains a brightness key, you want to set that up with this program. See also Adjusting the backlight dynamically.

secure-delete

Want to prevent cold-boot attack or decrypted keys in memory falling in the wrong hands? This maybe could work who knows? From research from cold boot attack, the data can actually stay in memory in minutes, just enough time for a hacker to copy the contents of the memory to a USB thumb drive.

To install secure-delete do:

 sudo apk add secure-delete

smem only works for unused ram.[8] If you use the vanilla kernel, this may work. If you use grsecurity, it will automatically sanitize memory if you enable it (but not enabled by default in the Alpine hardened kernel) when the memory page is freed.[9]

Close all important programs then call smem.

You call smem in your shutdown script or auto-logoff script.

You can call create a OpenRC shutdown script to run smem when most programs and services are closed. This will erase all your sensitive plaintext private data just in case.

You may want to create a wrapper script to call smem after your program closes.

You need to write a custom script that does the following:

 * kill all running processes associated with your user account
 * auto logoff terminals
 * for the last terminal closed including all idle xservers, unmount your user home
 * (optional) use smem to wipe all your plaintext private data in memory after all closed programs in case of cold boot attack

Sharing presentations over HDMI

If you want to use your laptop to share presentation over HDMI connection, you need libxinerama and xrandr.

To install libxinerama and xrandr do:

 sudo apk add libxinerama xrandr

Important notes

If you lose or break your USB key, that is it and you cannot decrypt your drive. It would be wise to make a backup of it.

By default, suspend-to-ram or hibernate will not sufficiently clear the AES encryption keys off ram in those phases which would invite a cold boot attack. This has been covered by the TRESOR kernel patch.[10][11] This patch hasn't been updated since the 4.x kernel series.[12]. This patch currently only works on 32-bit x86 Linux with SSE and MMX, and on processors with the AES-NI instruction set for x86_64 Linux. TRESOR doesn't work with DMA attack, but it can be mitigated by disabling DMA.[13] The 32-bit version of TRESOR has only a key size of 128. The AES-NI version of TRESOR has a largest key size of 256 bit. See Choosing ciphers for the number of rounds cracked.

Loop-Amnesia works with LoopAES and is only for 64 bit Linux and only supports 128 bit keys but can result in data loss if their recommendations are not followed. [14]

Please read the Wikipedia article on Cold Boot Attack especially the mitigation section.[15] Full disk encryption will not protect your data especially for older hardware if you do not have the proper mitigation (implying not full proof) prerequisites such as a patched kernel, memory scrambling, permanent memory module mounting for example.

If you have a different but fully encrypted device like iPad, you still can be rubberhosed or interrogated with a perfect deniable encrypted laptop. This guide doesn't protect you from that possibility. If you do not want to be rubberhosed, don't possess those devices.

Additional tips to mitigate against a DMA Attack to exfiltrate encryption keys:

Disable DMA in the BIOS and set the password for the BIOS according to Wikipedia.[16]

Blacklist kernel modules that use DMA and any unused expansion modules (FireWire, CardBus, ExpressCard, Thunderbolt, USB 3.0, PCI Express and hotplug modules) that use DMA.

You may need a custom (or customize a) BIOS or use Intel TXT or TPM which will authenticate the boot devices or boot from specific serial numbers not just any. For cold boot attack, it is not required to remove the RAM but to to slow down the rate of decay of the RAM module with liquid air in addition an USB thumb drive containing an encryption key retriever bypassing the operating system.[17]