LUKS Encrypt Your Root File System on Raspberry Pi


#1

WHY ENCRYPT?

There are many reasons to encrypt the Root File System (RFS) on the Raspberry Pi, from keeping WiFi credentials immutable to keeping proprietary software and sensitive data from being cloned. For many Raspberry Pi configurations, only two partitions exist:

  • /boot on /dev/mmcblk0p1
  • / on /dev/mmcblk0p2

So it makes sense to encrypt the root partition as a way of encrypting everything.


INTRODUCING LUKS

LUKS (Linux Unified Key Setup) is the popular key management setup for dm-crypt, the de-facto standard for block device encryption with Linux.

LUKS provides a robust and flexible mechanism for multiple users (and services) to interface to and access Linux’s ‘dm-crypt’ infrastructure.

dm-crypt is a transparent disk encryption subsystem in Linux kernel versions 2.6 and later and is part of the device mapper infrastructure, and uses cryptographic routines from the kernel’s Crypto API. Both are widely used and understood in the IT community.

Weaknesses of single Master key

dm-crypt has a single Master Key that is used to encrypt / decrypt data in/out of the block. To ensure long term security and deal with changing authorized users/services, it would be necessary to change the Master Key frequently, and potentially share it with multiple users/services on a regular basis. Every new iteration of Master Key would require the underlying data block to be re-encrypted everytime. In real systems, touched by different users/services, this is impractical.

Hierarchical key management

A more practical solution is to have a hierarchical key management setup in which users/services are given User Keys that are used to release the MasterKey. User Keys can be easily changed and revoked, without having to re-encrypt the underlying data block.
The management of such a hirearchical key managers is the role of LUKS.

In this post we show how to use Zymkey to lock a User Key, that is subsequently used to unlock the Master Key and provide access to the Root File System. If you’d like to learn more about LUKS see the References at the bottom of this post.


SECURE STORAGE OF LUKS USER KEYS

The security efficacy of your LUKS encrypted RFS is highly dependent upon how the User Keys are generated and where they are stored.

Pi SD Card is NOT a secure storage location

The growing Raspberry Pi family is awesome and we love it! It is inexpensive, has an incredible amount of computing power for an embedded device and has a very robust software development ecosystem.

However, Raspberry Pi has an Achilles heel: the SD card is the primary software deployment media and it can be very easily removed and manipulated.

The natural inclination would be to encrypt the file system using LUKS on dm-crypt, but for unattended use across many deployed units the obvious question is: where is the LUKS key stored? Of course, it’s the file system. Even if you try to obfuscate it through various programmatic means, the key is still very vulnerable to attack.

Securing LUKS User Key with Zymkey Security Module.

Zymkey provides a general “locking” service whereby a block of plaintext data is encrypted and signed.

When used with LUKS, the User Key is sent to the Zymkey to be locked (encrypted and signed) when the file system is created. When the system boots and needs to decrypt the root file system, the locked LUKS key is “unlocked” (signature verified and contents decrypted) and presented to dm-crypt. If the key was unlocked successfully, the boot process continues normally. Here is the boot sequence with a LUKS/dm-crypt filesystem where the key is protected by Zymkey:

  1. The kernel initializes initramfs
  2. initramfs presents the locked LUKS key to Zymkey
  3. Zymkey validates the signature and decrypts the key *
  4. The decrypted key is presented to LUKS and the root file system is then decrypted

*requires that Zymkey operational status is “secure” or “dev_secure”


Zymkey Security Module fitted to Raspberry Pi

Zymkey Authenticates Host System Before Unlocking LUKS Key

One of the key features of Zymkey is to generate a unique Identity (ID) for the host system, based upon a fingerprint that measures specific system components. This fingerprinting process is used to “bind” together a specific Zymkey (root of trust, key store, crypto services), a specific host computer and a specific SD card. Once bound, these components form a permanent and immutable ID of the host system.

Each time the Pi boots, and at random intervals thereafter, the Zymkey rechecks the ID fingerprint. If any of the system components have changed the fingerprint changes and the system is deamed to have been compromised, authentication fails and all security services are shutdown. (more details on binding here).

Using this ID / Authentication feature, Zymkey can be used to protect LUKS User Keys in unattended applications, where it might be easy to remove and copy SD card content. (Zymkey also has other physical security features which are also used to lock/enable security services)


WHERE TO STORE YOUR LUKS ENCRYPTED RFS

LUKS is very versatile and can be applied to both SD Card and external storage media. Lets review the pro’s and cons of each option:

Option 1 - Convert existing SD Card to LUKS

Details

Converting the existing root file system on the SD card still requires an external device (e.g. USB flash drive) that is used as a temporary boot root file system: this provide an easier and lower risk means to convert and copy the original contents. The external devices needs to be a little larger than the existing root file system in order to store the old file system.

Pros:

  1. Less physical space requirements.
  2. Much less power required.

Cons:

  1. Conversion is more complex and time consuming than migrating to an external drive.
  2. Data space constraints.
  3. Write cycle constraints.
  4. Access speed constraints.

Process Steps:

  1. Make a tarball of the original root file system and store it on the external device
  2. Copy the original root file system files to the external device to form a temporary file system
  3. Boot to the temporary file system. Once booted, the temporary file system will:
    a. Create a LUKS key
    b. Lock the LUKS key with zymkey
    c. Create a LUKS volume on the original root partition
    d. Create an ext4 partition on the LUKS volume on the original root partition
    e. Untar the root file system tarball into the converted partition

Option 2 - Migrate existing SD card to external LUKS storage device.

Details

The existing root file system can be migrated to an external LUKS encrypted USB flash, hard drive or SSD.

Pros:

  1. External devices can hold much more data.
  2. Migration is easier and quicker than SD card conversion method.
  3. Some external devices have much faster data access than SD cards.
  4. Some external devices (e.g. HDD) can tolerate many more write cycles than an SD card.

Cons:

  1. For HDD and SSD and non-compact USB flash devices, there are additional power requirements.
  2. Except for compact USB flash devices, physical space requirements also increase. This may be especially important for the Raspberry Pi Zero family.

Process Steps:

  1. Create the LUKS key
  2. Lock the LUKS key
  3. Create a LUKS volume on an external USB device
  4. Create an ext4 partition on the LUKS volume
  5. Move the existing root file system to the LUKS volume on the external device
  6. Boot to the new root file system and erase the previous root volume

BUILDING YOUR LUKS ENCRYPTED RFS

Prerequisites

Make sure you have the Zymkey software suite already running and operational as well as insuring that your Zymkey is bound. Instructions [here]
(Getting Started with ZYMKEY 4i).

Option 1 - Convert existing SD Card to LUKS

Details

To convert your root file system to LUKS/dm-crypt, you will need to connect an external USB disk (as temporary storage). As mentioned previously, this is necessary because it is not possible to encrypt the partition in place, so the external disk is needed as temporary storage and a temporary root file system while the conversion takes place. The external disk needs to be at least twice as big as the root partition. Next, run the following script:

curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash

This script is parameterized, so if you have special requirements (e.g. root file system lives on /dev/mmcblk0p4), you can invoke it in the following fashion:

curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -x <path to external storage device (e.g. /dev/sdX> -m <source partition number>

In the above invocation with no parameters, the defaults are:

  1. Original root file system located on /dev/mmcblk0p2
  2. Temporary root file system/storage for original root tarball located on /dev/sda
  3. Temporary root file system takes up entirety of new device

The very first run of this script on a new temporary external USB disk could take a long time. Also, two reboots are required before the script is complete.

One thing to note is that, if the external storage device has an ext4 formatted partition with the original root file system partition (e.g. /dev/mmcblk0p2) on it, this script will use what is already on the external storage device to convert the SD card. This cuts down time for converting lots of Pi root file systems and allows the script to be used in a mass production deployment.

On a Pi3 with an attached USB SSD as the external device on a bare Jessie “full” version (~4GB), the first run of this script requires about an hour to complete the first phase. The second phase takes around 15 minutes.

The same platform with a Jessie “lite” version (~1.6GB) takes around 20 minutes for phase 1 and 5 minutes for phase 2.

Based on the above, using the formatted external device to convert subsequent units should only take 15/5 minutes.

Option 2 - Migrate existing SD card to external LUKS storage device.

Details

To migrate your root file system to an external USB device, you can run the following script:

curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_ext_rfs.sh | sudo bash

This script is parameterized, so if you have special requirements, you can invoke in the following fashion:

curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_ext_rfs.sh | sudo bash -s -- -x <path to external storage device (e.g. /dev/sdX> -p <destination partition number -s <max size of new root partition> -m <source partition number>

In the above invocation with no parameters, the defaults are:

  1. Original root file system located on /dev/mmcblk0p2
  2. New root file system located on /dev/sda1
  3. New root file system takes up entirety of new device

Please note that the new root file system should be at least a little larger in size than the original root partition

Running this script on a Pi Model 3 with a root partition of roughly 16GB (SanDisk Ultra Class 10) containing the base Jessie install plus the Zymkey software suite (~1GB) to a 32GB SanDisk Cruzer Fit takes around 30-40 minutes. The Zymkey’s LED flashes rapidly until the process has completed.


INTEGRATING LUKS INTO VOLUME MANUFACTURING WORKFLOW

The examples above are designed to help you get up and running with single and low volume applications.

If you require support in developing a high volume manufacturing encryption workflow then please contact us to discuss our OEM engineering services.


REFERENCES


Getting Started with ZYMKEY 4i
Getting Started with ZYMKEY 3i
Using the Real Time Clock (RTC) on Zymkey
Getting Started with ZYMKEY 2i
Using Perimeter Detect
Getting Started with ZYMKEY 4i
ZYMKEY 4i DOCUMENTATION
#2

#3

#4

#5

#6

#7

#8

#9

#10

Hi Zymbit and Community!

Before getting in any trouble (#noobAlert), how can I be sure that my PI respects the default assumptions of this guide? i.e. right from the beginning:

For many Raspberry Pi configurations, only two partitions exist:

/boot on /dev/mmcblk0p1
/ on /dev/mmcblk0p2

Here are the results for fdisk -l and df -h:

pi@uquizz:~ $ sudo fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/mmcblk0: 15 GiB, 16088301568 bytes, 31422464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000b7e73

Device         Boot   Start      End  Sectors  Size Id Type
/dev/mmcblk0p1         8192  2476562  2468371  1,2G  e W95 FAT16 (LBA)
/dev/mmcblk0p2      2476563 31116287 28639725 13,7G  5 Extended
/dev/mmcblk0p5      2482176  2547709    65534   32M 83 Linux
/dev/mmcblk0p6      2547712  2682879   135168   66M  c W95 FAT32 (LBA)
/dev/mmcblk0p7      2686976 31116287 28429312 13,6G 83 Linux


root@uquizz:/home/pi# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root           14G    6,1G  6,5G  49% /
devtmpfs           459M       0  459M   0% /dev
tmpfs              463M       0  463M   0% /dev/shm
tmpfs              463M     13M  451M   3% /run
tmpfs              5,0M    4,0K  5,0M   1% /run/lock
tmpfs              463M       0  463M   0% /sys/fs/cgroup
/dev/mmcblk0p6      66M     22M   45M  33% /boot
/dev/sda2           58G    692M   57G   2% /media/usb0
/dev/sda1          197M    197M   512 100% /media/usb1
tmpfs               93M       0   93M   0% /run/user/0
tmpfs               93M       0   93M   0% /run/user/1001
tmpfs               93M       0   93M   0% /run/user/109
tmpfs               93M       0   93M   0% /run/user/1000

Based on your answer I’ll feel confident with proceeding with the rest of the SD Card Conversion procedure

Raspbian Jesse installed with NOOBS 2.0.0 in last february.

Thanks for your answers,
Cheers


#11

Based on your configuration, it looks like your root file system is located at /dev/mmcblk0p7.

Before we get started, please backup your SD card if you need to save a custom image. If this is just a stock NOOBS image with nothing custom or proprietary, you can skip this step.

Next, install a USB flash or hard drive drive that is larger than your SD card. Since it looks like your card is 16GB, I would recommend at least a 32GB drive just to make sure, but I think you could get away with as little as 16GB. The encryption conversion procedure is going to destroy whatever is on that drive, so make sure that you get any valuable data off of it before proceeding. If the USB drive is the only external USB mass media drive installed, it will typically have a designation of /dev/sda, but just to make sure, you can run mount to check that this is true.

When all of the above is out of the way, you’ll want to run our conversion script, feeding in the necessary parameters. Assuming that your Linux partition is /dev/mmcblk0p7 and your temporary USB storage is at /dev/sda, run:
curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -x /dev/sda -m 7

As stated in the top post, this will take some time.

Please let us know how this works for you or if you get stuck along the way,

Scott


#12

Maybe a bit of overkill but I have a Pi3 with 1.8TB of root space:

whim@raspberrypi:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 10M 0 10M 0% /dev
tmpfs 185M 13M 173M 7% /run
/dev/dm-0 1.8T 1.2G 1.7T 1% /
tmpfs 462M 0 462M 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 462M 0 462M 0% /sys/fs/cgroup
/dev/mmcblk0p1 41M 28M 13M 70% /boot
whim@raspberrypi:~$ sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 1408 MB in 2.00 seconds = 703.89 MB/sec
Timing buffered disk reads: 118 MB in 3.02 seconds = 39.03 MB/sec

Instructions worked as shown on the second try. I did not record the issue on the first try.


#13

Hi @Scott_of_Zymbit

(Eventually got the RTC stable and correct time at each offline boot with the latest software (and a new CR1025 coin cell), now back to encryption :wink: )

With an external USB key SanDisk 64Go, appearing as:

Here are some logs, hopefully no big issues:

pi@____:~ $ curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -x /dev/sda -m 7
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9364  100  9364    0     0  22380      0 --:--:-- --:--:-- --:--:-- 22455
Usage: bash [-x <path to temp external storage dev (e.g. /dev/sdX>] [-m <src part num>]

Trying without the double dash ‘–’ did not work in a first attempt:

root@____:/home/pi# curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s  -x /dev/sda -m 7
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9364  100  9364    0     0  18342      0 --:--:-- --:--:-- --:--:-- 18324
++ id -u
+ '[' 0 '!=' 0 ']'
+ RFS_SRC_PART_NUM=2
+ getopts :x:s:p: o
+ shift 0
+ '[' -z ']'
+ echo 'No temporary volume name (/dev/...) specified. Defaulting to /dev/sda...'
No temporary volume name (/dev/...) specified. Defaulting to /dev/sda...
+ EXT_DEV=/dev/sda
+ SRC_RFS_PART=/dev/mmcblk0p2
+ EXT_TMP_PART=/dev/sda1
+ '[' '!' -e /dev/sda ']'
+ echo -n 'Stopping zkifc...'
Stopping zkifc...+ systemctl stop zkifc
+ sleep 10
+ echo done.
done.
+ mkdir -p /mnt/tmproot
+ mount /dev/sda1 /mnt/tmproot
+ '[' 0 '!=' 0 ']'
+ '[' '!' -f /mnt/tmproot/original_zk_root.tbz2 ']'
+ echo 'Distro tarball not found on tmp root fs. Installing crypto installer on /dev/sda.'
Distro tarball not found on tmp root fs. Installing crypto installer on /dev/sda.
+ install_init_cfg
+ echo 'Installing necessary packages...'
Installing necessary packages...
+ apt-get install -y zksaapps rsync
+ umount /dev/sda1
+ echo done.
done.
+ echo -n 'Formatting USB mass media on /dev/sda...'
Formatting USB mass media on /dev/sda...+ dd if=/dev/zero of=/dev/sda bs=512 count=1 conv=notrunc
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets (512 B) copiés, 0,00495271 s, 103 kB/s
+ sync
+ echo -e 'n\np\n\n\n\nw\n'
+ fdisk /dev/sda
Re-reading the partition table failed.: Périphérique ou ressource occupé
+ exit

(External peripheral or resource busy)

Then retrying the same is still running… I’ll let you know the finale:

pi@____:~ $ curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s  -x /dev/sda -m 7
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  9364  100  9364    0     0  24722      0 --:--:-- --:--:-- --:--:-- 24707
++ id -u
+ '[' 0 '!=' 0 ']'
+ RFS_SRC_PART_NUM=2
+ getopts :x:s:p: o
+ shift 0
+ '[' -z ']'
+ echo 'No temporary volume name (/dev/...) specified. Defaulting to /dev/sda...'
No temporary volume name (/dev/...) specified. Defaulting to /dev/sda...
+ EXT_DEV=/dev/sda
+ SRC_RFS_PART=/dev/mmcblk0p2
+ EXT_TMP_PART=/dev/sda1
+ '[' '!' -e /dev/sda ']'
+ echo -n 'Stopping zkifc...'
Stopping zkifc...+ systemctl stop zkifc
+ sleep 10
+ echo done.
done.
+ mkdir -p /mnt/tmproot
+ mount /dev/sda1 /mnt/tmproot
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
+ '[' 32 '!=' 0 ']'
+ echo 'Mounting failed. Installing crypto installer on /dev/sda.'
Mounting failed. Installing crypto installer on /dev/sda.
+ install_init_cfg
+ echo 'Installing necessary packages...'
Installing necessary packages...
+ apt-get install -y zksaapps rsync
+ umount /dev/sda1
umount: /dev/sda1: not mounted
+ echo done.
done.
+ echo -n 'Formatting USB mass media on /dev/sda...'
Formatting USB mass media on /dev/sda...+ dd if=/dev/zero of=/dev/sda bs=512 count=1 conv=notrunc
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets (512 B) copiés, 0,0163845 s, 31,2 kB/s
+ sync
+ echo -e 'n\np\n\n\n\nw\n'
+ fdisk /dev/sda
+ mkfs.ext4 -j /dev/sda1 -F
mke2fs 1.43.3 (04-Sep-2016)
+ mkdir -p /mnt/tmproot
+ mount /dev/sda1 /mnt/tmproot
+ echo -n 'Making a tarball of original root file system image...'
Making a tarball of original root file system image...+ tar cjpf /mnt/tmproot/original_zk_root.tbz2 --one-file-system /
tar: Suppression de « / » au début des noms des membres
tar: /root/.pm2/pub.sock : socket ignorée
tar: /root/.pm2/rpc.sock : socket ignorée
tar: /home/pi/.forever/sock/worker.1476804203342oOn.sock : socket ignorée
tar: /tmp/.vncserver-license/0.684 : socket ignorée
tar: /tmp/.X11-unix/X0 : socket ignorée
tar: /tmp/.vnc-vncservice/vncserver-x11.CtrlComms : socket ignorée
tar: Suppression de « / » au début des liens physiques
+ echo done.
done.
+ mk_SD_crfs_script
+ cat
++ uname -r
++ uname -r
++ uname -r
+ chmod +x /usr/local/bin/cfg_SD_crfs.sh
+ mk_SD_crfs_svc
+ cat
+ systemctl enable cfg_SD_crfs
Created symlink from /etc/systemd/system/multi-user.target.wants/cfg_SD_crfs.service to /etc/systemd/system/cfg_SD_crfs.service.
+ mk_zymkey_initramfs_hook
+ cat
+ chmod +x /etc/initramfs-tools/hooks/zymkey_cryptfs_cfg
+ systemctl disable zkifc
Removed symlink /etc/systemd/system/multi-user.target.wants/zkifc.service.
+ echo -n 'Creating installer partition on /dev/sda1...'
Creating installer partition on /dev/sda1...+ rsync -rlxp --info=progress2 / /mnt/tmproot
    162,167,481  77%   11.73MB/s    0:00:13 (xfr#3855, ir-chk=1000/6375)
skipping non-regular file "home/pi/.forever/sock/worker.1476804203342oOn.sock"
  2,574,773,546  93%    9.24MB/s    0:04:25 (xfr#33564, ir-chk=2050/44699)
skipping non-regular file "root/.pm2/pub.sock"
skipping non-regular file "root/.pm2/rpc.sock"
  2,598,023,802  94%    9.24MB/s    0:04:28 (xfr#34220, ir-chk=1313/44699)
skipping non-regular file "tmp/.X11-unix/X0"
skipping non-regular file "tmp/.vnc-vncservice/vncserver-x11.CtrlComms"
skipping non-regular file "tmp/.vncserver-license/0.684"
  5,729,903,597  99%    9.17MB/s    0:09:55 (xfr#126407, to-chk=0/161495)   
+ '[' '!' -f /mnt/tmproot/original_zk_root.tbz2 ']'
++ mount
++ grep ' / '
++ awk '{print $5}'
+ rfs_type=ext4
+ '[' ext4 '!=' ext4 ']'
+ rm -rf /mnt/tmproot/var/lib/zymbit/
+ cp -rpf /var/lib/zymbit/ /mnt/tmproot/var/lib/
+ '[' '!' -f /boot/config.txt ']'
+ sed -i 's/root=[^ ]*//' /boot/cmdline.txt
+ sed -i 's/  / /g' /boot/cmdline.txt
+ tr -d '\n'
+ mv /tmp/cmdline.txt /boot/cmdline.txt
+ echo ' root=/dev/sda1'
+ cp /etc/fstab /mnt/tmproot/etc
++ grep ' / ' /mnt/tmproot/etc/fstab
++ awk '{print $1}'
+ rfs=/dev/mmcblk0p7
+ sed -i //dev/mmcblk0p7/d /mnt/tmproot/etc/fstab
sed: -e expression n°1, caractère 4: caractères inutiles après la commande
+ grep -q '^/dev/sda1' /mnt/tmproot/etc/fstab
+ echo -e '\n# temp root fs\n/dev/sda1 /             ext4    defaults,noatime  0       1'
+ echo done.
done.
+ echo 'Rebooting to installer partition...'
Rebooting to installer partition...
+ reboot
Connection to ____.local closed by remote host.
Connection to ____.local closed.

HOWERVER, after reboot:

  • LED blinking rapidly, as if zymkey was not installed

  • with ~/getTime.py
    _

    import zymkey
    print('get_time(): ’ + str(zymkey.client.get_time()))

python getTime.py returns:

Traceback (most recent call last):
  File "getTime.py", line 1, in <module>
    import zymkey
  File "/usr/local/lib/python2.7/dist-packages/zymkey/__init__.py", line 7, in <module>
    client = Zymkey()
  File "/usr/local/lib/python2.7/dist-packages/zymkey/module.py", line 62, in __init__
    raise AssertionError('bad return code {!r}'.format(ret))
AssertionError: bad return code -111

Who may I check that encryption procedure succeeded?
do i need to through installation procedure once more?


#14

Hi again, @wiill
It looks like you found a bug in our script. This bug is fixed now, so if you repeat the command above (with the --), it should work for you.
curl -G https://s3.amazonaws.com/zk-sw-repo/mk_encr_sd_rfs.sh | sudo bash -s -- -x /dev/sda -m 7

I’m not sure why the Zymkey LED is blinking rapidly. I assume that you have rebooted your pi more than once and the same result occurs. If that’s true, could you please post the results of:
sudo systemctl status zkifc
and
sudo journalctl -u zkifc


#15

Hi @Scott_of_Zymbit,

I won’t thank you enough for your time and support, whatever the results on my side :wink:
After it seemed to have worked, now my raspi doesn’t boot anymore (maybe a reboot too many while the USB key was still plugged?)
I’m working mainly in headless, I will have to boot with a screen to have a closer look at what’s wrong during booting.
I probably will have to start all over (I did make an image before starting anything related to Zymkey, so that’s not really a problem, just takes some time)

I’m gonna be offline for a few weeks, but this project is only paused ;), I’ll get back to you as soon as I’m back myself with some more news and the results of your commands.

Maybe a last question before going away: my USB key storage appeared as follow in /dev BEFORE the SD card conversion procedure:

/dev/sda
/dev/sda1
/dev/sda2

I don’t know why it seems to be partitioned, and your script didn’t seem to care, but could that be a problem?

(ps: a little typo remaining in your last post, double “https://”?)


#16

@wiill,
Our script takes the USB disk in /dev/sda and wipes out all partitions. It then creates a single large partition which it uses for storing a tarball of the root file system on the SD card plus a temporary boot spot when it converts the SD card rootfs.

After the process completes successfully, you can leave the USB disk installed if you like.

I’m sorry to say this, but it sounds like you might have to start the process over with your pre-zymkey image. Please let me know when/how I can help further when you get back to this project.


#17

Hi, we have lots of Pis already out in the field using SD and USB storage and wish to go around installing the zymbit for file system encryption. Is there a method of encrypting the already established USB storage (which holds root) rather than your process here of converting the SD to USB then encrypt? Maybe you’ve mentioned it already and ive missed understood the guide so apologies in advance if I have.

Many thanks


#18

@chunkychicken
There are several options for ‘in-the-field’ installation, depending on your specific system configuration. (It’s probably better if we take this conversation offline, so as not expose your specifics).

In general temporary storage must be used for a backup of the original partition prior to encrypting a partition.

For the SD card conversion, the USB drive contents can be reused for faster SD card conversion, providing that there is not unique content for each unique pi.


#19

Hi,
Is it works only specific version of raspbian or should be work with all?
Because it’s not work for me width the newest Stretch and the older Jessie version.
newest: https:// downloads.raspberrypi .org/raspbian_lite_latest
older: https:// excellmedia.dl.sourceforge .net/project/raspbian/Raspbian-lite/2017-02-01-Raspbian-lite.zip

With the version 8 script run without error and successfully boot from usb but after another reboot it cannot start from SD card:
Errors at boot:

Waiting for root device.
Missing modules
/dev/mapper/cryptrfs does not exist

Don’t you have a step by step guide with versions what can be reproduced?
Hardware: RaspberryPi3, 16GB SD card, 32GB USB, partitions as you write.

Steps what I do:

Do I miss any steps or what can be wrong?

Thank’s for help!

The SD Card Conversion script has double https://


#20

@koltaig, the current Zymkey software only works with Jessie at the moment. We will have a Stretch release soon.