1

I'm working a prototype based on Mint. Mint installed + installed and configured packages. This prototype is built on a rasp-like computer.

I plan:

  1. to clone disk on several other rasp-like machines.

  2. to encrypt (dm-crypt, LUKS) disk in order to hide the system & files.

I have noted that one cannot easily LUSK-encrypt an already installed system. Is there a blessed way to make the process "automatic"? I mean : a way to encrypt and copy the system in the same run.

3 Answers 3

2

It is possible to perform an in-place encryption but I would strongly suggest that you take a backup first. I wrote an experimental tool that I called inCrypt which can convert between raw (unencrypted), plain (dm-crypt) and LUKS formats.

Converting an unencrypted device to LUKS requires that any pre-existing data on the device needs to be shifted to leave a space of around 2MiB at the beginning so that a header can be installed there. Alternatively you can detach the header and store it on a separate device (such as a USB key).

If you use a detached LUKS header or choose plain-mode dm-crypt instead then there is no need to shift the data, it can be converted in-situ.

I wrote up the theory with examples here and you can also read about right-shifting and its inherent problems in this question.

To summarise, you can perform in-place encryption using dd to copy into a dm-crypt device mapper from the underlying raw device:

$ cryptsetup open "${raw_device}" crypt_device --type plain ${cryptsetup_args}
$ dd if="${raw_device}" conv=notrunc of=/dev/mapper/crypt_device
$ cryptsetup close crypt_device

(the variables are placeholders for you to supply the relevant parameters for your environment; it's more completely explained in the script and linked pages above)

This is a risky operation - if it fails part-way through (power loss, fat fingers, or for any other reason) then you are stuffed. Take a backup first.

Note that I used the words backup, experimental and theory. Caveat Emptor, and all that!

2
  • Thanks a lot. "If you use a detached LUKS header or choose plain-mode dm-crypt instead then there is no need to shift the data, it can be converted in-situ." Are you 100% sure of that ?
    – ArchiT3K
    Jul 31, 2015 at 8:54
  • Yes, but you should convince yourself of the fact. Read the paragraph 2.4 What is the difference between "plain" and LUKS format on the Cryptsetup FAQ.
    – starfry
    Jul 31, 2015 at 9:49
1

Perhaps the most straight forward way is to create and configure the master image with LUKS encryption enabled.

Of course, if you just clone this master disk all devices share the same encryption key - which is bad.

But you can reencrypt an already encrypted LUKS partition.

Thus, you could script the following workflow:

  1. dd the master image to a new drive /dev/sdX
  2. get the UUID of existing device: cryptsetup luksUUID /dev/sdXY
  3. reencrypt with: cryptsetup reencrypt /dev/sdXY
  4. reset UUID to old one: cryptsetup luksUUID --uuid $olduuid /dev/sdXY

The reset of the UUID is necessary because the grub config and/or initramfs (i.e. via dracut) has it baked in such that it's unlocked during boot.

Alternatively, you have to update the UUID in those places.


Depending on how often you want to clone your master image perhaps you want to use another process - since the cryptsetup reencrypt method isn't necessary the fastest one.

You could start with the master image that is again fully configured with LUKS encryption.

From that image you dump the partition table with sfdisk -d. Next you dump all unencrypted images into separate files (usually this would be just the boot partition). Finally, you cryptsetup open the system partition from the master image (e.g. via a loop device) and dump its content to another image file (say root.img).

With those pieces the clone procedure would look like this:

  1. partition the device with < part.dump sfdisk /dev/sX
  2. dd the unecrypted partition(s) to - say - /dev/sX1
  3. format the system partition: cryptsetup luksFormat --uuid $olduuid /dev/sXY
  4. open the new LUKS device
  5. dd the root.img to the new LUKS device
0

Unless it's LVM all data has to be moved to make room at the beginning for the LUKS header (2MiB). So it's not a straightforward / risk-free process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.