Add a -t option to the 'luks unlock' command to allow a TKey to be used
to unlock a disk. The password is used as the user-supplied secret (USS)
in this case.
Series-to: concept
Cover-letter:
luks: Integrate support for a TKey
This series illustrates how to use a Tillitis TKey to unlock an
encrypted disk. This has the advantage that the key depends on a
physical key in the user's posession as well as the usual passphrase.
The TKey handles the key derivation, so this series includes logic to
skip that step when a TKey is used.
The 'luks unlock' command provides a -t flag to use a TKey.
It also provides a small pytest fix to ease conflicts with Labgrid
integration.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Series-links: 1:63
Add documentation for the new LUKSv2 feature and update LUKSv1 to
mention the more common algorithm.
Update the tests to use LUKSv2 for mmc12
Series-to: concept
Series-cc: heinrich
Cover-letter:
luks: Provide support for LUKSv2
Modern systems mostly use LUKSv2 as it is more secure that v1. This
series provides an implementation of this feature, making use of the
existing 'luks unlock' command.
One interesting part of this series is a converter from JSON to FDT, so
that U-Boot's existing ofnode interface can be used to access the
hierarchical data in JSON text. This obviously results in quite a bit
of new code, but it is more robust than trying to parse the text
directly using strstr(), etc. The choice of JSON for LUKS was presumably
made with larger code bases in mind, rather than a firmware
implementation.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Series-links: 1:58
Provide a function which can detect a LUKS partition. Add a test, using
mmc11
Series-to: concept
Cover-letter:
luks: Provide basic support for unlocking a LUKS1 partition
With full-disk encryption (FDE) it is traditional to unlock a LUKS
partition within userspace as part of the initial ramdisk passed to
Linux. The user is prompted for a passphrase and then the disk is
unlocked.
This works well but does have some drawbacks:
- firmware has no way of knowing whether the boot will success
- the 'passphrase' prompt comes quite late in the boot, which can be
confusing for the user
- specifically it is not possible to provide an integrated 'boot' UI in
firmware where the user can enter the passphrase
- in a VM environment, the key may be known in advance, but there is no
way to take advantage of this
- it is not possible to use an encryted disk unless also using a ramdisk
This series makes a small step towards improving U-Boot in this area. It
allows a passphrase to be checked against a LUKS1-encrypted partition.
It also provides read-only access to the unencrypted data, so that files
can be read.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a new 'luks unlock' command which can unlock a LUKS1 partition,
given a passphrase.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Extract the full information for version 2, which is JSON format. Show
this with the 'luks info' command.
Use the mmc12 disk to check this.
Require the JSON for LUKS.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'luks' command which allows querying a partition to see if it is
encrypted using LUKS, as well as showing information about a LUKS
partition.
Provide some documentation and a test.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
