2.4.4 Device Hardware

This section's intended audience is those personnel who are responsible for hardware and mechanical quality. Guidance is available from the IoTSF [ref 44]¹ regarding Physical Security (part B) Secure Boot (part C) and Secure Operating Systems (part D).

Req No	Requirement	Compliance Class And Applicability	Primary Keyword	Secondary Keyword
2.4.4.1	The product’s processor system has an irrevocable hardware Secure Boot process.	Mandatory for all classes	System	Hardware
2.4.4.2	The product’s processor system has an irrevocable “Trusted Root Hardware Secure Boot”.	Mandatory for Class 2 and above	System	Hardware
2.4.4.3	The product’s processor boot process provides an appropriate level of trustworthiness by using a hardware root of trust to verify trusted boot or measured boot methods. This may be referred to as 'secure boot', but absolute security cannot be assured.	Mandatory for Class 3 and above	System	Hardware
2.4.4.4	The Secure Boot process is enabled by default.	Mandatory for all classes	System	Hardware
2.4.4.5	Any debug interface only communicates with authorised and authenticated entities on the production devices.(note: 2.4.4.6-8 should be considered as advisory) The functionality of any interface should be minimised to its essential task(s).	Mandatory for Class 1 and above	System	Hardware Software
2.4.4.6	The hardware incorporates protection against tampering and this has been enabled. The level of tamper protection must be determined by the risk assessment.	Mandatory for Class 1 and above	System	Hardware
2.4.4.7	The hardware incorporates physical, electrical and logical protection against tampering to reduce the attack surface. The level of protection must be determined by the risk assessment.	Mandatory for Class 2 and above	System	Hardware Physical
2.4.4.8	The hardware incorporates physical, electrical & logical protection against reverse engineering. The level of protection must be determined by the risk assessment.	Mandatory for Class 3 and above	System	Hardware
2.4.4.9	All communications port(s) which are not used as part of the product’s normal operation are not physically accessible or only communicate with authorised and authenticated entities.	Mandatory for Class 1 and above	System	Hardware Physical Software
2.4.4.10	All the product’s development test points are securely disabled or removed wherever possible in production devices.	Mandatory for Class 2 and above	System	Hardware Physical
2.4.4.11	Tamper Evident measures have been used to identify any interference to the assembly to the end user.	Mandatory for Class 2 and above	System	Hardware
2.4.4.12	Intentionally left blank to maintain requirement numbering	-
2.4.4.13	In production devices the microcontroller/ microprocessor(s) shall not allow the firmware to be read out of the products non-volatile [FLASH] memory. Where a separate non-volatile memory device is used the contents shall be encrypted.	Mandatory for Class 1 and above	System	Hardware
2.4.4.14	Where the product's credential/key storage is external to its processor, the storage and processor shall be cryptographically paired to prevent the credential/key storage being used by unauthorised software.	Mandatory for Class 1 and above	System	Hardware
2.4.4.15	Where a production device has a CPU watchdog, it is enabled and will reset the device in the event of any unauthorised attempts to pause or suspend the CPU’s execution.	Mandatory for Class 1 and above	System	Hardware
2.4.4.16	Where the product has a hardware source for generating true random numbers, it is used for all relevant cryptographic operations including nonce, initialisation vector and key generation algorithms.	Mandatory for Class 1 and above	System	Hardware Software
2.4.4.17	The product shall have a hardware source for generating true random numbers.	Mandatory for Class 2 and above	System	Hardware

Enhanced Privacy standard for Anonymous Signatures ISO/IEC20008 [https://www.iso.org/standard/57018.html] ↩

Footnotes​

Footnotes