| Message ID | 20250305-initramfs-crypt-hook-patches-2-v4-2-4170912e5261@denx.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | initramfs-crypt-hook patch | expand |
> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Claudius Heine via lists.cip-project.org > Sent: Mittwoch, 5. März 2025 13:00 > To: cip-dev@lists.cip-project.org > Cc: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com>; Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com>; Claudius Heine <ch@denx.de> > Subject: [cip-dev] [PATCH v4 2/5] initramfs-crypt-hook: use static temporary encryption key > > Using a temporary random value for the temporary encryption key makes it impossible to continue encryption if it was aborted at a later date. > > Instead a static key can be used, which will allow the continuation of the encryption process. During that phase, an attacker could derive the volume key using that static key! e.g. `cryptsetup luksDump --dump-volume-key` > > Security wise the partially encrypted volume, with a static temporary encryption key can be considered the same as the un-encrypted partition that was there before the system has booted. So using a known temporary encryption key should not affect the system security in that way. For new devices, during device bootstrapping / setup that's probably true, but such assumption is not generalizable! But even if it was, once the device is in the field, probably sensitive data is added during onboarding or gathered during operation. Thus, once the volume key is retrieved (as described above) attackers could potentially unencrypt content after years, getting access to sensitive data which wasn't there initially. BR Alexander > > It is just important to let the re-encryption process properly finish until the temporary encryption key is removed. > > Signed-off-by: Claudius Heine <ch@denx.de> > --- > recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 7 ++++--- > recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb | 3 +-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > index ae0dcef4cb62a135beb6d4229237144b6d4edf8b..ea9b6352daadbea625d6168d1dc75ad616028fe0 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete > @@ -259,10 +259,11 @@ for partition_set in $partition_sets; do > watchdog_pid=$! > fi > > - # create random password for initial encryption > - # this will be dropped after reboot > + # use partuuid of the partition for initial encryption password, this key > + # will be removed after the reencryption has finished and the TPM2 token is > + # registered: > tmp_key=/tmp/"$(basename "$part_device")-lukskey" > - openssl rand -base64 32 > "$tmp_key" > + blkid -s PARTUUID -o value "$part_device" > "$tmp_key" > > case "${partition_format}" in > "reencrypt") > diff --git a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb > index df335c9f75d6e74b3e167689ec9c73dd3781a890..69d204e9539c2e5024db832e5b305fe73396317b 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb > +++ b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb > @@ -14,7 +14,6 @@ require recipes-initramfs/initramfs-hook/hook.inc > DEBIAN_DEPENDS .= ", \ > cryptsetup, \ > awk, \ > - openssl, \ > e2fsprogs, \ > tpm2-tools, \ > coreutils, \ > @@ -40,7 +39,7 @@ HOOK_ADD_MODULES = " \ > ecb aes_generic xts" > > HOOK_COPY_EXECS = " \ > - openssl mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ > + mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ > e2fsck resize2fs cryptsetup \ > tpm2_pcrread tpm2_testparms tpm2_flushcontext \ > /usr/lib/*/libgcc_s.so.1" > > -- > 2.47.2 >
Hi Alexander, On 2025-03-06 10:35 am, Heinisch, Alexander wrote: >> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Claudius Heine via lists.cip-project.org >> Sent: Mittwoch, 5. März 2025 13:00 >> To: cip-dev@lists.cip-project.org >> Cc: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com>; Gylstorff, Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com>; Claudius Heine <ch@denx.de> >> Subject: [cip-dev] [PATCH v4 2/5] initramfs-crypt-hook: use static temporary encryption key >> >> Using a temporary random value for the temporary encryption key makes it impossible to continue encryption if it was aborted at a later date. >> >> Instead a static key can be used, which will allow the continuation of the encryption process. > > During that phase, an attacker could derive the volume key using that static key! > e.g. `cryptsetup luksDump --dump-volume-key` > >> >> Security wise the partially encrypted volume, with a static temporary encryption key can be considered the same as the un-encrypted partition that was there before the system has booted. So using a known temporary encryption key should not affect the system security in that way. > > For new devices, during device bootstrapping / setup that's probably true, > but such assumption is not generalizable! > But even if it was, once the device is in the field, probably sensitive data is > added during onboarding or gathered during operation. > > Thus, once the volume key is retrieved (as described above) attackers could > potentially unencrypt content after years, getting access to sensitive data which > wasn't there initially. That is true, I wasn't considering that. I guess the only real option would be to try to use the TPM2 to generate a static key... I will have to research how that works. regards, Claudius > > BR Alexander > >> >> It is just important to let the re-encryption process properly finish until the temporary encryption key is removed. >> >> Signed-off-by: Claudius Heine <ch@denx.de> >> --- >> recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 7 ++++--- >> recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb | 3 +-- >> 2 files changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> index ae0dcef4cb62a135beb6d4229237144b6d4edf8b..ea9b6352daadbea625d6168d1dc75ad616028fe0 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete >> @@ -259,10 +259,11 @@ for partition_set in $partition_sets; do >> watchdog_pid=$! >> fi >> >> - # create random password for initial encryption >> - # this will be dropped after reboot >> + # use partuuid of the partition for initial encryption password, this key >> + # will be removed after the reencryption has finished and the TPM2 token is >> + # registered: >> tmp_key=/tmp/"$(basename "$part_device")-lukskey" >> - openssl rand -base64 32 > "$tmp_key" >> + blkid -s PARTUUID -o value "$part_device" > "$tmp_key" >> >> case "${partition_format}" in >> "reencrypt") >> diff --git a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb >> index df335c9f75d6e74b3e167689ec9c73dd3781a890..69d204e9539c2e5024db832e5b305fe73396317b 100644 >> --- a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb >> +++ b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb >> @@ -14,7 +14,6 @@ require recipes-initramfs/initramfs-hook/hook.inc >> DEBIAN_DEPENDS .= ", \ >> cryptsetup, \ >> awk, \ >> - openssl, \ >> e2fsprogs, \ >> tpm2-tools, \ >> coreutils, \ >> @@ -40,7 +39,7 @@ HOOK_ADD_MODULES = " \ >> ecb aes_generic xts" >> >> HOOK_COPY_EXECS = " \ >> - openssl mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ >> + mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ >> e2fsck resize2fs cryptsetup \ >> tpm2_pcrread tpm2_testparms tpm2_flushcontext \ >> /usr/lib/*/libgcc_s.so.1" >> >> -- >> 2.47.2 >>
On 06.03.25 11:11, Claudius Heine wrote: > Hi Alexander, > > On 2025-03-06 10:35 am, Heinisch, Alexander wrote: >>> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> >>> On Behalf Of Claudius Heine via lists.cip-project.org >>> Sent: Mittwoch, 5. März 2025 13:00 >>> To: cip-dev@lists.cip-project.org >>> Cc: Kiszka, Jan (FT RPD CED) <jan.kiszka@siemens.com>; Gylstorff, >>> Quirin (FT RPD CED OES-DE) <quirin.gylstorff@siemens.com>; Claudius >>> Heine <ch@denx.de> >>> Subject: [cip-dev] [PATCH v4 2/5] initramfs-crypt-hook: use static >>> temporary encryption key >>> >>> Using a temporary random value for the temporary encryption key makes >>> it impossible to continue encryption if it was aborted at a later date. >>> >>> Instead a static key can be used, which will allow the continuation >>> of the encryption process. >> >> During that phase, an attacker could derive the volume key using that >> static key! >> e.g. `cryptsetup luksDump --dump-volume-key` >> Good catch! >>> >>> Security wise the partially encrypted volume, with a static temporary >>> encryption key can be considered the same as the un-encrypted >>> partition that was there before the system has booted. So using a >>> known temporary encryption key should not affect the system security >>> in that way. >> >> For new devices, during device bootstrapping / setup that's probably >> true, >> but such assumption is not generalizable! >> But even if it was, once the device is in the field, probably >> sensitive data is >> added during onboarding or gathered during operation. >> >> Thus, once the volume key is retrieved (as described above) attackers >> could >> potentially unencrypt content after years, getting access to sensitive >> data which >> wasn't there initially. > > That is true, I wasn't considering that. > > I guess the only real option would be to try to use the TPM2 to generate > a static key... I will have to research how that works. > Exactly. The question is why we cannot generate the final key already before the encryption starts, ie. eliminate any temporary keys. Jan
diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete index ae0dcef4cb62a135beb6d4229237144b6d4edf8b..ea9b6352daadbea625d6168d1dc75ad616028fe0 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete @@ -259,10 +259,11 @@ for partition_set in $partition_sets; do watchdog_pid=$! fi - # create random password for initial encryption - # this will be dropped after reboot + # use partuuid of the partition for initial encryption password, this key + # will be removed after the reencryption has finished and the TPM2 token is + # registered: tmp_key=/tmp/"$(basename "$part_device")-lukskey" - openssl rand -base64 32 > "$tmp_key" + blkid -s PARTUUID -o value "$part_device" > "$tmp_key" case "${partition_format}" in "reencrypt") diff --git a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb index df335c9f75d6e74b3e167689ec9c73dd3781a890..69d204e9539c2e5024db832e5b305fe73396317b 100644 --- a/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb +++ b/recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb @@ -14,7 +14,6 @@ require recipes-initramfs/initramfs-hook/hook.inc DEBIAN_DEPENDS .= ", \ cryptsetup, \ awk, \ - openssl, \ e2fsprogs, \ tpm2-tools, \ coreutils, \ @@ -40,7 +39,7 @@ HOOK_ADD_MODULES = " \ ecb aes_generic xts" HOOK_COPY_EXECS = " \ - openssl mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ + mke2fs grep awk expr seq sleep basename uuidparse mountpoint \ e2fsck resize2fs cryptsetup \ tpm2_pcrread tpm2_testparms tpm2_flushcontext \ /usr/lib/*/libgcc_s.so.1"
Using a temporary random value for the temporary encryption key makes it impossible to continue encryption if it was aborted at a later date. Instead a static key can be used, which will allow the continuation of the encryption process. Security wise the partially encrypted volume, with a static temporary encryption key can be considered the same as the un-encrypted partition that was there before the system has booted. So using a known temporary encryption key should not affect the system security in that way. It is just important to let the re-encryption process properly finish until the temporary encryption key is removed. Signed-off-by: Claudius Heine <ch@denx.de> --- recipes-initramfs/initramfs-crypt-hook/files/local-top-complete | 7 ++++--- recipes-initramfs/initramfs-crypt-hook/initramfs-crypt-hook_0.6.bb | 3 +-- 2 files changed, 5 insertions(+), 5 deletions(-)