Is there a way to make FOG compatible with LUKS encryption?

[george1421]

@sebastian-roth I’ll start digging into the kernel modules and what needs to be added to the inits to support LUKS. I did it once, so I’m guessing I can repeat the process.

I suppose I need to write a tutorial to that the content doesn’t get lost with time.

[Sebastian Roth]

@george1421 said in Is there a way to make FOG compatible with LUKS encryption?:

I’ll start digging into the kernel modules and what needs to be added to the inits to support LUKS. I did it once, so I’m guessing I can repeat the process.

Thanks heaps, that’d be great!

I suppose I need to write a tutorial to that the content doesn’t get lost with time.

Not sure if it’s worth it as I plan to add this stuff to the official configs.

[Sebastian Roth]

@george1421 I just found an older post in that same topic you linked with valuable information about this: https://forums.fogproject.org/post/128888

Edit: Do you remember why you added DM_SNAPSHOT, DM_BUFIO, DM_PERSISTENT_DATA and so on? My current config diff looks like this:

diff --git a/configs/kernelx64.config b/configs/kernelx64.config
--- a/configs/kernelx64.config
+++ b/configs/kernelx64.config
@@ -1324,7 +1324,7 @@ CONFIG_BLK_DEV_DM_BUILTIN=y
 CONFIG_BLK_DEV_DM=y
 # CONFIG_DM_DEBUG is not set
 # CONFIG_DM_UNSTRIPED is not set
-# CONFIG_DM_CRYPT is not set
+CONFIG_DM_CRYPT=y
 # CONFIG_DM_SNAPSHOT is not set
 # CONFIG_DM_THIN_PROVISIONING is not set
 # CONFIG_DM_CACHE is not set
@@ -3459,8 +3459,10 @@ CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_NULL2=y
 # CONFIG_CRYPTO_PCRYPT is not set
-# CONFIG_CRYPTO_CRYPTD is not set
+CONFIG_CRYPTO_CRYPTD=y
 CONFIG_CRYPTO_AUTHENC=y
+CONFIG_CRYPTO_SIMD=y
+CONFIG_CRYPTO_GLUE_HELPER_X86=y
 
 #
 # Public-key cryptography
@@ -3495,12 +3497,12 @@ CONFIG_CRYPTO_ECB=y
 # CONFIG_CRYPTO_LRW is not set
 # CONFIG_CRYPTO_OFB is not set
 # CONFIG_CRYPTO_PCBC is not set
-# CONFIG_CRYPTO_XTS is not set
+CONFIG_CRYPTO_XTS=y
 # CONFIG_CRYPTO_KEYWRAP is not set
 # CONFIG_CRYPTO_NHPOLY1305_SSE2 is not set
 # CONFIG_CRYPTO_NHPOLY1305_AVX2 is not set
 # CONFIG_CRYPTO_ADIANTUM is not set
-# CONFIG_CRYPTO_ESSIV is not set
+CONFIG_CRYPTO_ESSIV=y

 #
 # Hash modes
@@ -3551,7 +3553,7 @@ CONFIG_CRYPTO_SHA512=y
 #
 CONFIG_CRYPTO_AES=y
 # CONFIG_CRYPTO_AES_TI is not set
-# CONFIG_CRYPTO_AES_NI_INTEL is not set
+CONFIG_CRYPTO_AES_NI_INTEL=y
 # CONFIG_CRYPTO_BLOWFISH is not set
 # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
 # CONFIG_CRYPTO_CAMELLIA is not set

Edit2: BR2_PACKAGE_CRYPTSETUP is included in the official init configs already (32 bit, 64 bit and arm64). As well CONFIG_CRYPTO_AES is enabled in the official kernels (32 bit, 64 bit and arm64).

Edit3: I will add CONFIG_CRYPTO_AES_NI_INTEL (ref) for 32 bit and 64 bit - not available on arm64 as well as CONFIG_CRYPTO_XTS (ref) for all three platforms.

Edit4: Looks like we also need openssl binaries in the inits (ref. I will add that to the official inits.

@LuisTemporal I will add this stuff to the official kernel/init and push out a new test build soon.

[george1421]

@sebastian-roth I started researching this on thursday. i didn’t get very far but stopped after I found some basis info. This is a bit disjointed but it gave me some interesting clues.

linux on ARM
https://www.snbforums.com/threads/cryptsetup-kernel-modules.46607/
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m

CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_SHA256=m


# Modules for crypto device
dm-mod
dm-crypt
aes
twofish
sha256

https://wiki.gentoo.org/wiki/Dm-crypt

[*] Enable loadable module support
Device Drivers --->
    [*] Multiple devices driver support (RAID and LVM) --->
        <*> Device mapper support
        <*>   Crypt target support


[*] Cryptographic API --->
    <*> XTS support
    <*> SHA224 and SHA256 digest algorithm
    <*> AES cipher algorithms
    <*> AES cipher algorithms (x86_64)
    <*> User-space interface for hash algorithms
    <*> User-space interface for symmetric key cipher algorithms

Device Drivers --->
    [*] Block Devices ---> 
        <*> Loopback device support 
File systems ---> 
     <*> FUSE (Filesystem in Userspace) support 
[*] Cryptographic API ---> 
     <*> RIPEMD-160 digest algorithm 
     <*> SHA384 and SHA512 digest algorithms 
     <*> Whirlpool digest algorithms 
     <*> LRW support 
     <*> Serpent cipher algorithm 
     <*> Twofish cipher algorithm

Yes I remember there was something I needed to do with openssl in the inits and add in dm_crypt I think. I was going to open the init I had from that time to see if I put anything else in there.
I added “CONFIG_CRYPTO_AES_NI_INTEL” version because it can take advantage of the hardware crypto engine built into some intel processors.

[Sebastian Roth]

@george1421 Thanks! Looking through the kernel config again I saw CONFIG_CRYPTO_SHA256_SSSE3 and CONFIG_CRYPTO_SHA512_SSSE3. Do you think those would be helpful here as well?

The Gentoo wiki mentions TrueCrypt/VeraCrypt compatibility by adding “User-space interface…” as well as “FUSE (Filesystem in Userspace) support” options in the kernel. Anyone keen to use that as well?

@LuisTemporal I just compiled a fresh init and kernel for you to test. Download those, put on your FOG server and try working with those. Please let us know if it works or not.

[LuisTemporal]

@sebastian-roth @george1421 Thanks for the feedback, I will try to test the init and kernel you have provided and as soon as I do some tests I will let you know. Thanks

[LuisTemporal]

@luistemporal @Sebastian-Roth @george1421 I have renamed the init and kernel of my FOG server to .backup and added the new files, restarted the Apache service and changed the image type from “Raw Image” to “Single Disk”, and when I try to deploy the image on a new machine, I get the following error:

These are the commands I have executed on the FOG server:

  114  locate init.xz
  115  locate bzImage
  116  sudo mv /var/www/html/fog/service/ipxe/init.xz /var/www/html/fog/service/ipxe/init.xz.backup
  117  sudo mv /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage.backup
  118  sudo mv /home/administrator/bzImage-luks /var/www/html/fog/service/ipxe/bzImage
  119  sudo mv /home/administrator/init-luks.xz /var/www/html/fog/service/ipxe/init.xz
  120  sudo systemctl restart apache2.service 
  121  sudo systemctl status apache2.service 
  122  sudo chown -R fogproject:root /images/*
  123  sudo chmod a+rwx /images/*
  124  sudo systemctl restart apache2.service 
  125  history 

[LuisTemporal]

@luistemporal @Sebastian-Roth @george1421 I solved this error by re-capturing the image and re-deploying with “Single Disk”. The disk decrypts correctly on the cloned machine. The problem I have now is that the original machine is 34 GB and the cloned machine is 54 GB and there is unallocated disk space left. How could I extend the encrypted partition to fill the entire disk?

[Sebastian Roth]

@luistemporal said in Is there a way to make FOG compatible with LUKS encryption?:

The problem I have now is that the original machine is 34 GB and the cloned machine is 54 GB and there is unallocated disk space left. How could I extend the encrypted partition to fill the entire disk?

Now that part will definitely take some more work on the inits as we’d need to rework the resize functions and add LVM support. @Wayne-Workman said he might look into this but will take time.

[Sebastian Roth]

Just reviving this topic as it’s still not part of our official kernel config…

@george1421 Looking through the kernel config I saw CONFIG_CRYPTO_SHA256_SSSE3 and CONFIG_CRYPTO_SHA512_SSSE3. Do you think those would be helpful here as well?

The Gentoo wiki mentions TrueCrypt/VeraCrypt compatibility by adding “User-space interface…” as well as “FUSE (Filesystem in Userspace) support” options in the kernel. Anyone keen to use that as well?

@Wayne-Workman Do you think you’ll get to tackle the LVM implementation in the near future or should we toss that idea in favour of a next release?

[Wayne Workman]

@sebastian-roth said in Is there a way to make FOG compatible with LUKS encryption?:

@Wayne-Workman Do you think you’ll get to tackle the LVM implementation in the near future or should we toss that idea in favour of a next release?

I’ll start poking at some LVM bash scripts, though another release before LVM support would be preferred by me.

[Sebastian Roth]

@george1421 Ok, I added things with the latest commit to the official kernels. Let me know if you think there is anything else needed.