Disk Encryption can eliminate booting from other OS's to get access to the local disk. It can also require a password on boot
Disk Encryption allows you transparently encrypt the writable portion of the local storage medium. In case a device or storage medium gets stolen, no data can be read. Furthermore, disk encryption prevents "evil maid" type attacks where somebody might try to modify the contents of the local storage medium after hours by booting with another OS. Nevertheless, people may wonder - why? Thin Client type devices and VDI endpoints are not supposed to store personal information. Now that is certainly true, but there is still some data that you may or may not define to be worth of protecting, such as your Citrix URL, or private certificates to get onto the network. When switched on, NoTouch will encrypt the writable part of the disk. It will not encrypt the Linux kernel and firmware.
Disk Encryption in NoTouch is part of the "Disk Encryption (Endpoint)" upgrade package and license. It was added in NoTouch OS 2.40.4282. It works on both PC and Raspberry Pi devices.
Contents
- 1 Configuration
- 2 Change behavior
- 3 Relation to High Security Edition (ESs images)
- 4 Additional notes
Configuration
In the "Security" section, you'll find three parameters that govern the encryption behavior. Note: On the client, you may need to click "All" first to see the Security section button.
- Disk encryption. This is the master switch for disk encryption. You need to turn it on to take advantage of the functionality.
- Passphrase method. Encryption needs a pass phrase. This parameter governs what kind of passphrase is being used.
- User input. The user will be asked to type in this machine's encryption passphrase at every boot.
- System. The system will choose a passphrase out of various system-specific components. While obviously not as secure as storing it in a user's brain, it still fends off casual attackers and allows for enhanced security at zero impact in convenience as no passphrase needs to be typed in.
- Encrypted container size. The size of the encrypted area on disk. The default of 100 MB is more than enough in most cases. Only if you store custom modules that exceed this, you may need to increase the container size. Beware, larger container sizes affect boot-up performance, especially on Raspberry Pi.
Change behavior
Changing the parameters will lead to changes at next boot. For example, if you change to "user input" from "system", the system will at next boot ask for the new passphrase to be used. Similarly, the container will grow or shrink, the former leading to potentially long boot times (definitely avoid the gigabyte-type containers on Raspberry Pi!) - if the system can not fulfill a grow or shrink request because there is not enough free space (grow), or already too much used space in the container (shrink), then the request will simply be ignored until conditions have changed.
If you disable encryption, the change will happen immediately during system runtime to avoid another unlocking procedure.
If encryption is enabled on a system that does not have the "ENC" license, the disk will not be encrypted and a warning dialog will appear when booting up. The warning dialog must be dismissed by the user.
Relation to High Security Edition (ESs images)
This disk encryption functionality is the next-generation functionality and designed to supersede the ESs-based functionality. The earlier functionality was based on setting up a PC using the installer, whereas the new functionality can be switched on conveniently at system runtime, and also supports the Raspberry Pi. Also, it only supported "user input".
A system set up earlier with ESs will continue to work if updated to a new EEs with Disk Encryption but will pull an ENC license.
Additional notes
Changing the passphrase method or container size is only available in "new generation" OS images (Full 64-bit x64 and Raspberry Pi), not in the older k206, k305, k4xx_amd64.
Disk Encryption in use - aes-xts-plain64