Linux has built in encryption for several years now, yet enterprises still struggle with encryption on Linux laptops.  Why is that? To answer this question, let’s first review the disk encryption capabilities that are built into Linux:

1)      dm-crypt (https://en.wikipedia.org/wiki/Dm-crypt)

dm-crypt is a transparent disk encryption subsystem within the Linux kernel. It is a block device based abstraction that can be inserted on top of other block devices, like disks.  It is therefore, an ideal technology to be used for FDE (Full Disk Encryption).  The actual encryption is not built into dm-crypt, but rather it utilizes cryptographic routines (e.g.  AES)  from the kernel’s Crypto API.

2)      LUKS (https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)

LUKS (Linux Unified Key Setup) is a disk encryption specification that details a platform-independent standard on-disk format for use in various tools  (i.e. a standard encryption header), which provides the basis for implementing password management. LUKS operates on Linux and is based on an enhanced version of cryptsetup that uses dm-crypt as the disk encryption backend.

Together, dm-crypt and LUKS form the basis for a simple “standalone” password authenticated FDE application; this, however, is not an enterprise grade solution. (Read more about the scenarios, advantage and disadvantages of native Linux FDE at https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system)

Here is what our customers told us they needed for their data-at-rest protection for Linux, which they could not get from dm-crypt and LUKs alone:

1)      Centralized Compliance view of encrypted devices:  The ability to go to a console to see if a Linux laptop in their organization is encrypted and compliant with their encryption policy. The laptop communicates its encryption status (for all disks) to the central console on a configured time interval. Thereby, if a laptop goes missing, the IT department would have proof of its encryption state for the auditors.

2)      Centralized password & key management of encrypted system: Overall password recovery, operations & management of the encrypted Linux device from a central console is essential. The console should also be able to provide central backup of the encryption keys and recovery info.

3)      Pre-Boot Authentication with Active Directory (AD) Credentials:  The ability to use an AD username and password to authenticate at pre-boot. That is, actually have an AD server participate in the pre-boot authentication by utilizing pre-boot networking.  This is a significant improvement over native Linux implementation which requires having a pre-boot password and sometimes different password for each volume on the system etc. and doesn’t support AD.

4)     Root Volume Encryption:  Root volume encryption, data volume encryption and encrypting swap partition are all needed, however protecting the root volume with Linux native FDE is generally quite convoluted thus necessitating an improved mechanism.

5)      Initial Online Encryption: Have the ability to encrypt pre-installed Linux laptops without having to back-up data up, wipe the disk and re-install Linux with encryption enabled.

6)      Crypto-erasing a comprised device: Having a simple mechanism to cryptographically erase all data when a device is compromised, or is to be repurposed. This operation should also be recorded for compliance reasons.

AND

            Having the ability to manage all the above for Windows and macOS, too, from a single console, because they dread deploying a different management solution for each OS type.

This is where our new SecureDoc for Linux comes in – SecureDoc for Linux for physical workstations is a close relative to SecureDoc CloudVM for Linux for virtualized machines.  It builds on the capabilities available in Linux (such as dm-crypt), and adds a layer of manageability that scales at an enterprise level. So to answer the question I posed at the beginning of this blog, “Enterprises still struggle with encryption on Linux laptops. Why is that?”, the answer is quite simple – enterprises have been struggling because of a lack of management and compliance capabilities available in their current solution sets.

It is still in the early days but, in conjunction with our central SES encryption management server, we can already do everything on the list above.  If you would like to learn more or perform an evaluation, please contact us at info@winmagic.com