ROM: Root of trust necessary to hardening the embedded system do not enable IEC 62443 compliant security levels higher than SL 2
Update : The reported known issues were fixed with netX 90 ROM Code Revision 0x2. For further information, see also PCN 220093 and Revision netX 90.
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 supported 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 in advance about the ROM code change by following the PCN guidelines of the JEDEC standard J-STD-046.