Jason Wessel
c0b514f1ac
The create-user-key-store.sh was changed in a number ways to improve the usability with other layers that will consume the key services provided by meta-secure-core. New features: * A safety check was added that keys can only be written to a fresh empty directory. * The script can be run non-iteractively or interactively for the ease of use. * gpg 1.x support and gpg 2.x support work with the passphrases * A keys.conf is generated to allow a single line to be written into the local.conf with all the keys. An interactive session looks like: ================================== ./create-user-key-store.sh -d /tmp/test KEYS_DIR: /tmp/test Enter RPM/OSTree GPG keyname (use dashes instead of spaces) [default: PKG-SecureCore]: PKG-Sample-Man Enter RPM/OSTree GPG e-mail address [default: SecureCore@foo.com]: sample.man@sample.com Enter RPM/OSTREE GPG comment [default: Signing Key]: Sample Signing Key Using boot loader gpg name: BOOT-Sample-Man Using boot loader gpg email: sample.man@sample.com Using boot loader gpg comment: Sample Signing Key Press control-c now if and use -bn -bm -bc arguments if you want different values other than listed above Enter RPM/OSTREE passphrase: abc1234 Enter IMA passphrase: 1234pass Enter boot loader GPG passphrase: bootup Enter boot loader locked configuration password(e.g. grub pw): root MASTER_KEYS_DIR = "/tmp/test" IMA_KEYS_DIR = "${MASTER_KEYS_DIR}/ima_keys" IMA_EVM_KEY_DIR = "${MASTER_KEYS_DIR}/ima_keys" RPM_KEYS_DIR = "${MASTER_KEYS_DIR}/rpm_keys" BOOT_KEYS_DIR = "${MASTER_KEYS_DIR}/boot_keys" MOK_SB_KEYS_DIR = "${MASTER_KEYS_DIR}/mok_sb_keys" SYSTEM_TRUSTED_KEYS_DIR = "${MASTER_KEYS_DIR}/system_trusted_keys" UEFI_SB_KEYS_DIR = "${MASTER_KEYS_DIR}/uefi_sb_keys" GRUB_PUB_KEY = "${MASTER_KEYS_DIR}/boot_keys/boot_pub_key" GRUB_PW_FILE = "${MASTER_KEYS_DIR}/boot_keys/boot_cfg_pw" OSTREE_GPGDIR = "${MASTER_KEYS_DIR}/rpm_keys" RPM_GPG_NAME = "PKG-Sample-Man" RPM_GPG_PASSPHRASE = "abc1234" RPM_FSK_PASSWORD = "1234pass" BOOT_GPG_NAME = "BOOT-Sample-Man" BOOT_GPG_PASSPHRASE = "bootup" OSTREE_GPGID = "PKG-Sample-Man" OSTREE_GPG_PASSPHRASE = "abc1234" OSTREE_GRUB_PW_FILE = "${GRUB_PW_FILE}" [ Issue: LINUXEXEC-2450 ] Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
meta-secure-core
This layer provides the following common and platform-specific security features:
UEFI Secure Boot
For x86 platform, UEFI secure boot is the industry standard defined in the UEFI spec, allowing images loaded by UEFI BIOS to be verified with the trusted key. Whenever this feature is enabled, the bootloader and kernel will be signed automatically during the build, implying the signed binaries are contained by the resulting RPM and rootfs image.
MOK Secure Boot
For x86 platform, MOK secure boot is based on the UEFI secure boot, adding the shim loader to chainloader the second-stage bootloader. Meanwhile, the shim will also install a protocol which permits the second-stage bootloader to perform similar binary validation, e.g, for linux kernel.
User key store
By default, the signing key used by UEFI/MOK secure boot is the sample key for the purposes of development and demonstration. It is not recommended that this sample key be used for a production device and should be replaced by a secret key owned by the user.
TPM 1.x
This feature enables Trusted Platform Module 1.x support, including kernel option changes to enable tpm drivers, and picking up TPM 1.x packages.
TPM 2.0
This feature enables Trusted Platform Module 2.0 support, including kernel option changes to enable tpm drivers, and picking up TPM 2.0 packages.
Trusted Platform Module (TPM 2.0) is a microcontroller that stores keys, passwords, and digital certificates. A discrete TPM 2.0 offers the capabilities as part of the overall platform security requirements.
Encrypted storage
This feature gives 2 types of granularity for storage encryption. Data volume encryption allows the user to create encryption partition with a passphrase typed by the end user. Root filesystem encryption enables the data encryption on the entire rootfs except the boot partition.
Both types of storage encryption are based on device-mapper crypt target, which provides transparent encryption of block devices using the kernel crypto API. Additionally, the utility cryptsetup is used to conveniently setup disk encryption based on device-mapper crypt target.
IMA
The Linux IMA subsystem introduces hooks within the Linux kernel to support measuring the integrity of files that are loaded (including application code) before it is executed or mmap()ed to memory. The measured value (hash) is then registered in a log that can be consulted by administrators.
To support proven integrity of the files, the IMA subsystem can interact with the TPM chip within the system to protect the registered hashes from tampering by a rogue administrator or application. The IMA subsystem, as already supported by the Linux kernel, supports reporting on the hashes of files and commands ran by privileged accounts (and more if you create your own measurement policies).
In addition, IMA appraisal can even register the measured value as an extended attribute, and after subsequent measurement(s) validate this extended attribute against the measured value and refuse to load the file (or execute the application) if the hash does not match. In that case, the IMA subsystem allows files and applications to be loaded if the hashes match (and will save the updated hash if the file is modified) but refuse to load it if it doesn't. This provides some protection against offline tampering of the files.
MODSIGN
This feature provides the signature check for loading a kernel module. The signing key must be authenticated by a system trusted key already imported to the system trusted keyring.
If the kernel module is not signed, or signed by a signing key not matching up an imported system trusted key, kernel would refuse to load such a kernel module.
RPM signing
This feature provides the integrity verification for the RPM package.
Building the meta-secure-core layer
This layer should be added to the bblayers.conf file. To enable certain feature provided by this layer, add the feature to the local.conf file.
A reference implementation based on this layer is available.