The ROM code based root of trust necessary to hardening the embedded system does not enable IEC 62443 compliant security levels higher than SL 2 due to following limitations:
Issue | Functionality | Limitation | Workaround |
---|---|---|---|
Secure Console Mode | The ROM loader features a console mode that enables the handling of firmware programming and security configuration. If secure boot is enabled, the console mode transitions automatically to a secure console mode. The purpose of this transition is to minimize the surface that is exposed to the outside and to reduce the probability that a bug or feature can be used to circumvent security settings. | Due to a bug in the ROM code, not all non-secure console mode commands are disabled, which poses a residual risk that someone could exploit and manipulate RAM contents and register settings. | Do not expose the UART interface for the secure console mode outside the housing of the embedded system. |
External Flasher Tool | If secure boot is enabled, the secure console mode is limited to the UART interface for the purpose of security configuration only. Therefore, the machine-to-machine (M2M) interface via UART and Ethernet is not support for firmware programming. | The security configuration can be changed by the holder of the private master key. Disable secure boot temporarily to enable firmware programming using the console mode and external flasher tool. | |
Debug Interface Lock | The security configuration enables users to disable the debug interface of the device. | If secure boot is enabled, the debug interface for the application CPU is always disabled and locked regardless of the user's debug settings. | The security configuration can be changed by the holder of the private master key. Disable secure boot temporarily to enable debugging access. |
Defined Trust Anchors | User defined trust anchors enable binding a signed software to a device identity, e.g. product group, for secure boot. | Due to a bug in the sequence of the ROM code's signature verification, someone with expert knowledge and access to insides of the hardware could launch a sophisticated attack to manipulate the bindings. | Not relevant for IEC 62443 SL1 and SL 2. |
Hilscher Root Keys | Embedded in the ROM code are public root keys, generated by Hilscher, for contingency reasons, e.g. failure analyses. | Due to a bug, the Hilscher root keys can not be disabled by the user. If the root keys are not disabled, Hilscher can unlock the security settings of any device with a root certificate. | No workaround. |
Hilscher's V-Model for the bug fixing of the ROM code falls into three broad categories:
- Integration, test and verification at top-level simulation
- Engineering sample production with fixed ROM code
- Extensive testing of all modifications at silicon level
In line with the lead-time of typical production lots, Hilscher is going to inform customers until end of 2021 about the ROM code change by following the PCN guidelines of the JEDEC standard J-STD-046.