SIMATIC IOT2050 Secure Boot, OP-TEE, and TPM: Field Reference

SIMATIC IOT2050 Security Architecture Overview

The SIMATIC IOT2050 is Siemens' industrial IoT gateway for OT/IT convergence, built on the Texas Instruments AM6528 Sitara SoC (dual-core Arm Cortex-A53 at 1.0 GHz with Cortex-R5F MCU islands). The platform ships with a Yocto-based Linux image (Example Image) that supports container runtimes, OPC UA, Modbus TCP, S7, and PROFINET stacks via the optional IOT2050-SM MODULE. From a security architecture standpoint the device sits in an awkward place: it is an "edge" device that ingests plant-floor data and is therefore expected to support modern secure-boot, measured-boot, and key-storage primitives, yet the silicon-to-firmware support for those primitives has lagged behind the platform's release schedule.

Three primitives dominate the field question on this platform:

• Secure boot — verification of bootloader, OP-TEE, kernel, and rootfs by a hardware root of trust anchored in eFuse.
• OP-TEE (Open Portable Trusted Execution Environment) — a TEE OS for Arm TrustZone that hosts trusted applications (TAs) for key sealing, attestation, and secure storage.
• TPM 2.0 — a discrete or firmware TPM providing PCRs, sealed keys, and NV storage per TCG specifications.

On the first IOT2050 hardware revision, none of the three are available as a fully-integrated, production-grade option out of the box. The root cause is a combination of silicon behavior on the AM6528 and the dependency chain required to make any of these primitives trustworthy on that silicon. This reference walks through the constraints, the upstream work that is gating the fix, and the field workarounds that engineers can apply today.

Secure Boot Status on the AM6528

The AM6528 uses the TI Primary Bootloader (PSL) and a signed-second-stage flow that chains into U-Boot. The hardware root of trust is a fused OEM key stored as PK_HASH in the EFUSE block. For secure boot to be meaningful at the OS level, the chain must verify, in order:

1. Initial ROM bootloader (immutable, in TI mask ROM).
2. U-Boot SPL / secondary bootloader (signed with OEM key).
3. OP-TEE core image (signed, loaded into TrustZone secure RAM).
4. Linux kernel FIT image (signed).
5. Root filesystem (dm-verity for integrity, optional dm-crypt with sealed keys for confidentiality).

The TI Processor SDK for the related AM64X family documents this flow in detail, including the dm-verity / dm-crypt options, kernel debug disable, and OP-TEE porting prerequisites. Although the IOT2050 uses the AM6528 (AM65x family), the architectural flow and dependency list are shared. See: TI Processor SDK AM64X — Secure Boot.

The challenge on the IOT2050 has not been the ROM/U-Boot piece — TI's flow supports signed U-Boot on AM65x — but the OP-TEE piece that sits between the bootloader and the kernel. OP-TEE itself must be loaded into TrustZone SRAM and authenticated. Doing that correctly while keeping the secure world's memory intact against Linux-side attacks requires silicon behavior that, per the platform's release communication, was still in development when the IOT2050 shipped in its first hardware revision. A new hardware revision was targeted for release beginning of 2022 to address the gap.

OP-TEE and the RAM-Protection Problem

OP-TEE is the de-facto TEE OS for Arm TrustZone on Linux platforms. Its core runs in secure world; its trusted applications (TAs) execute from secure memory and expose services to the normal world via the TEE Client API. The OP-TEE/optee_os project is the upstream; its concepts overview explains the standard boot ordering: secure bootloader → OP-TEE core in secure RAM → nonsecure bootloader → nonsecure kernel. The OP-TEE secure boot issue #2478 tracks platform enablement for similar Cortex-A SoCs and is a useful thread for engineers reproducing the chain on AM65x.

On the AM6528, the unresolved piece at the time of the original IOT2050 release was the protection of OP-TEE's secure-world RAM after the normal-world kernel has started. Once the kernel takes ownership of the DRAM controller and paging, secure-world memory is not independently protected unless the platform's TrustZone Address Space Controller (TZASC) is configured and locked by a chain that the normal world cannot rewrite. On AM65x this requires a closed-bootloader chain (signed SPL → signed U-Boot → signed OP-TEE) plus a TZASC configuration that the upstream OP-TEE build does not yet finalize for this SoC.

The thread at the Trusted Firmware mailing list (tf-a, April 2021) discusses the underlying TF-A / OP-TEE in-RAM protection work that the AM65x family depends on. Until that work lands in the upstream OP-TEE build and the corresponding TI port, the IOT2050 cannot guarantee that OP-TEE state survives a Linux-side compromise. This is why the field question keeps returning: even if you can boot OP-TEE, you cannot trust it after boot.

TPM 2.0 Options on IOT2050

A discrete TPM 2.0 (SPI or I2C interfaced, TCG-compliant) is the most common fallback when secure boot and TEE are unavailable. The IOT2050 main board does not populate a TPM header by default, and the design does not include a firmware TPM (fTPM) in the secure enclave equivalent of what AMD or Intel x86 platforms provide. Field options observed in industrial deployments:

A discrete SPI TPM is only as secure as the platform that hosts it. Without secure boot, an attacker with physical access can reflash the bootloader and read the TPM-unsealed data the next time the system boots. The TPM therefore has to be deployed together with a verifiable boot chain — otherwise it is a more expensive way to store a key in cleartext on flash.

Disk Encryption Without a Hardware Root of Trust

The original field complaint is that LUKS / dm-crypt keys cannot be stored safely on the IOT2050. The default example image uses an unencrypted rootfs; if you re-deploy with LUKS, the key must live somewhere on the device. The candidates and their failure modes:

Until the platform gains a closed-boot chain, any "encrypted at rest" deployment on the IOT2050 should be paired with an OS-level tamper response. The recommended interim posture is:

• Mount / as read-only (squashfs + overlay) with logs streamed off-box.
• Do not persist LUKS keys locally; rely on physical access controls and remote attestation.
• If a TPM is added, treat its PCRs as advisory, not authoritative, until secure boot is in place.

TI Processor SDK Secure Boot Reference

For engineers designing the firmware layer that the IOT2050 will eventually run, TI's secure-boot documentation for the AM64X family is the closest published reference. The SDK enumerates the engineering checklist that maps directly onto AM65x bring-up:

• Enable dm-verity / dm-crypt for rootfs integrity and confidentiality.
• Set or disable the root account password and remove default credentials.
• Disable kernel CONFIG_DEBUG_* options that leak kernel state (CONFIG_DEBUG_KERNEL, CONFIG_KGDB, CONFIG_MAGIC_SYSRQ).
• Read the OP-TEE porting guide and turn off developer options in production builds (CFG_TEE_CORE_LOG_LEVEL=0).
• Disable kernel printk on production consoles to prevent KASLR and address leaks.
• Sign all FIT images with a customer-specific key; never reuse the TI development keys.
• Blow the JTAG-disable eFuse once the image is signed.

Source: TI Processor SDK AM64X — Secure Boot, §3.3.2.

Transferring these steps to the IOT2050 requires building a custom Yocto layer that pulls optee_os, optee_client, optee_test, and signing the resulting artifacts with a customer key. The signing flow uses TI's ti-sysfw and u-boot's mkimage with FIT image descriptors. Engineers reproducing this on the IOT2050 should track the upstream OP-TEE secure boot discussion for AM65x patches.

Sample FIT image descriptor (illustrative)

/dts-v1/;
/ {
    description = "IOT2050 signed kernel + rootfs";
    #address-cells = <1>;
    images {
        kernel {
            data = /incbin/("zImage");
            type = "kernel";
            arch = "arm64";
            os = "linux";
            compression = "none";
            load = <0x80080000>;
            entry = <0x80080000>;
            signature {
                algo = "sha256,rsa2048";
                key-name-hint = "customer-key";
                sign-images = "kernel", "fdt";
            };
        };
        fdt {
            data = /incbin/("iot2050.dtb");
            type = "flat_dt";
            arch = "arm64";
            compression = "none";
        };
    };
    configurations {
        default = "conf-1";
        conf-1 {
            description = "Production signed boot";
            kernel = "kernel";
            fdt = "fdt";
            signature {
                algo = "sha256,rsa2048";
                key-name-hint = "customer-key";
                sign-images = "fdt", "kernel";
            };
        };
    };
};

Cross-Platform Comparison

For context, the secure-boot posture of comparable industrial SoCs used in gateways and edge controllers:

The i.MX 8M Plus uses NXP's High Assurance Boot (HAB) / Advanced HAB (AHAB) with a closed boot chain that signs OP-TEE before normal-world U-Boot. The STM32MP1 platform documents OP-TEE integration in the ST OP-TEE concepts page. Engineers evaluating the IOT2050 against alternative gateways should weigh these platforms against it when the security requirement includes hardware-rooted measured boot.

Interim Mitigations and Field Practices

While the platform-level secure-boot chain is being completed, the following mitigations reduce (but do not eliminate) the residual risk on production IOT2050 deployments:

1. Sealed enclosures and tamper-evident fasteners. Physical access is the simplest attack vector; lock down the cabinet and use serialized tamper seals.
2. UEFI / bootloader password and console disable. The AM6528 supports a U-Boot password; combine with CONFIG_BOOTDELAY=-1 and disabled serial console on production units (CONFIG_SERIAL_PRESENT=y, but stdin/stdout/stderr redirected to /dev/null in production env).
3. Read-only rootfs. Mount / as squashfs + overlay; stream logs to remote syslog only.
4. Remote attestation via OPC UA or Siemens Industrial Edge. When the device authenticates to a higher-level trust broker, the broker can detect reflashed units by comparing device certificate fingerprints.
5. Key escrow on a separate HSM. Do not store LUKS keys on the IOT2050 at all; decrypt rootfs from the network on first boot and re-encrypt per session.
6. Disable JTAG in production OTP. Blow the JTAG-disable eFuse on AM65x once the image is signed.
7. Unique per-device SSH host keys and certificates. Provisioned at manufacturing time, so a reflashed unit cannot impersonate the original.
8. Network segmentation. Place the IOT2050 behind a cell-level firewall with explicit allowlists to the SCADA / MES tier.

Commissioning and Verification Procedure

When the closed boot chain becomes available, use this commissioning procedure to verify it on a new IOT2050 unit:

1. Fuse the OEM public-key hash (PK_HASH) per the TI secure-boot procedure; record the fuse value in the asset register.
2. Sign the SPL, U-Boot proper, OP-TEE, and FIT image with the matching private key using mkimage -f fit-image.its fit-image.itb.
3. Provision a TPM 2.0 module on the SPI header; verify with ls /dev/tpm* and tpm2_getcap properties-fixed.
4. Configure LUKS key in /etc/crypttab as luks,tpm2-device=... using systemd-cryptenroll --tpm2-device=/dev/tpm0 --tpm2-pcrs=0,4,7,14 /dev/sdaX.
5. Boot once with the PCR baseline; seal the key against PCR 0, 4, 7, 14 (typically PCR 0 = firmware, 4 = bootloader, 7 = secure-boot policy, 14 = measured kernel).
6. Verify with bootctl status and tpm2_pcrread sha256:0,4,7,14; both should match the expected policy.
7. Trigger a tamper event (reflash signed boot only, do not break the chain) and confirm LUKS fails to unseal — proving the policy is bound to the chain.
8. Trigger an unsigned-boot event and confirm the device refuses to boot (ROM / SPL abort).
9. Record TPM endorsement key certificate in the device's asset record.

Troubleshooting Matrix

Field-Proven Caveats

• Per-device keys matter. Even with a closed boot chain, a single shared signing key across a fleet means a single leaked key compromises every unit. Provision a unique PK_HASH per device family at minimum, and ideally a per-device intermediate key.
• Fit image signature verification is not the same as full chain verification. The first link that fails to authenticate must abort the entire boot, not warn and continue. Validate the abort behavior with a deliberately corrupted image during FAT.
• OP-TEE logging leaks. Even with CFG_TEE_CORE_LOG_LEVEL=0, panic paths can still dump memory. Audit panic handlers before declaring OP-TEE production-ready.
• TPM PCR reset on firmware update. Updating U-Boot or OP-TEE re-measures PCRs and breaks LUKS unseal. Plan a re-seal procedure with systemd-cryptenroll --wipe-slot=tpm2 + reseal in maintenance windows.
• Supply chain risk. Siemens currently ships the IOT2050 with development keys in the public Example Image. These must be replaced before any deployment is considered "secure."
• Hardware revision drift. If you order a 2022-revision unit expecting the closed-boot chain, verify the SKU revision against the current Siemens product page; do not assume availability.

FAQ