Documentation

Mistake on this page? Email us
Docs › Updating device firmware › Security › Securing Device Management Update on Linux

Securing Device Management Update on Linux

This guide provides an introduction to securing a system using Device Management Update on Linux. This is not a comprehensive guide to securing IoT Linux systems. Instead, it suggests some best practices and important considerations for mitigating several classes of threats:

  • Physical threats: Mitigate with a verified boot, whole-disk-encryption and tamper detection sensors.
  • Local execution threats: Mitigate with a verified boot, whole-disk-encryption and secured Linux best practices.
  • Remote threats: Mitigate with secured Linux best practices.
  • Threats against the update system itself: Mitigate with public key infrastructure, certificate delegation and revocation and whole-disk-encryption.

Audience

This guide is intended for a technical audience. You should be familiar with Device Management Update, Linux systems, cryptographic principles and networking.

Requirements

This guide assumes that you have already taken reasonable efforts, based on best practices, to secure the Linux system you are preparing. These include but are not limited to:

  • Enabling SELinux.
  • Removing any services that are not in use.
  • Removing any software that is not mandatory.
  • Removing telnet.
  • Removing X Windows, KDE, GNOME and other window management and desktop systems.
  • Removing SSH. If SSH is necessary:
    • Disable root login.
    • Only allow specified users.
    • Disable password login; enable public-key login.
    • Enforce SSH protocol version 2.
    • Show a security warning message at SSH login.
    • Log and report all SSH logins and login attempts.
  • Enabling and configuring iptables (firewall):
    • Enable iptables for IPv4 if IPv4 is in use. If IPv4 is not in use, disable IPv4 completely.
    • Enable iptables for IPv6 if IPv6 is in use. If IPv6 is not in use, disable IPv6 completely.
  • Disabling USB mass storage. When the Update client uses mass storage for firmware update, the mass storage should be mounted read-only and restricted so that only the update user can access it.
  • Disabling login for noncritical user accounts:
    • Set user shell to /sbin/nologin when available; otherwise, set it to /bin/false.
    • When user login must be possible, use one of the following:
      • Secure hardware tokens.
      • PAM's TOTP module to use time-based one-time passwords.
      • One-time passwords distributed to personnel one at a time on a per-device basis.
      • Try to avoid fixed, per-device passwords. Any of the above options is preferable.
    • Never use the same password or secret for more than one device.
  • Removing all unused accounts.
  • Monitoring and report user activities.
  • Partitioning the system to use read-only filesystems when possible:
    • /: read-only.
    • /boot: read-only.
    • /var: read/write.
    • /mnt/cache: read/write.

Physical security

For full security, consider physically securing the device. For example, you can use physical intrusion detection systems and remove physical USB ports.

Local security

The Linux system needs to use a secure boot system. This requires a device that supports secure boot, which may include TrustZone applications. In the Device Management Update architecture, this means:

  • The SoC's internal bootloader must authenticate a uBoot partition and then boot into it.
  • The uBoot partition should then authenticate a Linux image and boot into that image.
  • Authentication must use HMAC with SHA256 or better, or an asymmetric algorithm with SHA256, for example secp256r1+sha256 or rsa3072+sha256.
  • When using an asymmetric algorithm, the equivalent symmetric key strength must be 128 bits at minimum.

Tip: You can find a guide to verified boot using uBoot at LWN. An extensive guide with support for Arm-trusted firmware is available at Linaro.

Because it is difficult to authenticate a file system, you must use whole-disk-encryption to prevent tampering with the file system. This also reduces the possibility of reverse engineering and the exposure of potentially sensitive or confidential information.

Device Management Update security

Public key infrastructure

Device Management Update uses a set of public keys distinct from any other part of Device Management. We refer to these keys as the trust anchor. Certificates contain these keys, and the key configuration manager (KCM), in turn, stores the certificates. You can install these certificates in one of three ways:

  1. By the factory tool.
  2. By Device Management Update client.
  3. By the device application.

In the latter two cases, the certificates are deployed while the device is in the field. This requires validating the certificate before installation, exposing the risk that computing power could increase such that current certificates become possible to break over the lifetime of a device. NIST recommends that keys intended to last past 2030 should be rsa3072, secp256r1 or better. Device Management Update works with secp256r1.

Best practice suggests that the private key for the trust anchor should be stored in an HSM.

You can override the certificate fetch mechanism so that it does not use KCM. Instead, you install the certificates to a read-only partition by remounting read-write, writing the certificate and then remounting as read-only again. You need to override arm_uc_registered_certificate_api in update-client-hub/modules/control-center/source/arm_uc_certificate.c and provide a different certificate fetch API.

Certificate delegation

As mentioned above, best practice suggests placing a single long-life trust anchor on a device. Device Management Update client does not handle privilege delegation using certificate infrastructure. Instead, it expects to find all required certificates for validating an update using the ARM_UC_AddCertificate() API, which is implemented in arm_uc_registered_certificate_api->fetch().

You need to override the behavior of the activate script (pal_image_activate.sh) for that storage ID, so it performs the steps listed. Alternatively, it can delegate to an application that can perform those steps. Then, to perform privilege delegation, install certificates and CRLs using the following steps:

  1. Deliver the certificate/CRL using Device Management Update with a storage ID for certificates.
  2. Validate the signature of the new certificate using the trust anchor.
  3. Install the certificate into KCM using the ARM_UC_AddCertificate() API.
  4. If a CRL reports a subject that matches an existing certificate, it should be removed from KCM.

Manifests should always be signed with a different key from the private key of the trust anchor.

Storage

Device Management Update's trust anchor is based on one or more certificates. These certificates are trusted implicitly, and Device Management Update trusts any signature that can be verified with one of these certificates. As such, it is critical to protect the certificates' storage from any tampering: The partition that stores the certificates must either be encrypted or be on an encrypted disk.

You must encrypt the cache area for the same reasons as the bootable partition.

Previous Next