When it comes to semiconductor manufacturing both board assembly and board test are controlled by the original equipment manufacturer (OEM), but while these final stages are a relatively small portion of the manufacturing chain, they do contain their own security risks which can be as consequential as the risks during IC manufacture.
Given the similarity, many of the mitigations recommended for OEMs are similar to those recommended for IC manufacturers.
When it comes to board assembly, for example, this stage is similar to where IC manufacturers assemble the package, although this deals with mounting the package to a PCB, rather than placing a die inside the package. After the PCB is assembled, then the whole unit is normally placed in an enclosure.
Security starts with the basics including physical and network security, although this is hugely variable and very much depends upon the individual contractor being considered. Cost is often a significant factor in determining the amount of security deployed.
During the board assembly stage, the most significant threats are device theft, device analysis, and modification.
Theft: A significant theft could occur for the purposes of resale, especially with generic devices that are not tailored to a particular OEM. However, while prevention may be challenging, detection is relatively easy by monitoring batch sizes and incoming/outgoing inventory. Of more concern is if an attacker can obtain a large batch of devices and then modify them (such as adding or changing code) before reselling the devices to end users. Over-programming of this nature can be avoided if parts are delivered with secure boot configured and enabled as this will cause any modified / incorrectly signed code to be rejected.
Figure 1: OEMs are responsible for securing the final two stages of the IC lifecycle: board assembly and board test. Source: Silicon Labs
Device analysis: It is often more difficult for an attacker to get hold of ICs from board test than during the package assembly stage and, even if this happens, there is relatively little useful information available. Should any attacker wish to obtain hardware it is a simple matter for them to purchase an example of the system once it becomes commercially available. In fact, this (unpreventable) situation may be more useful to the attacker as, when the device is offered for sale, it contains programming as well.
Hardware modification: Modifying a PCB without detection is extremely hard to do, especially as visual inspection or simple probing tests can easily detect modifications. It is more possible that modifications to a limited number of boards could escape detection, but this limited attack is extremely difficult to perform.
Board test: Board testing at the assembly contractor is analogous to package testing performed during IC manufacture and, therefore, the threats are similar. Often, contractors work with multiple customers meaning that it is common for test equipment to be used by multiple people which increases the risk of security breaches. This is especially true with board manufacturers, so segregating access is a significant challenge.
There is also a significant risk of exposing confidential data at final test, although this depends on the individual product architecture and the way in which the test routines are configured. If the IC has sufficient security capabilities, then a final test regime that completely protects data within the test environment could be achieved.
Figure 2: Board assembly is quite similar to package assembly in IC production stage. Source: Silicon Labs
Malicious code injection: The easiest way to alter a product during test is non-physical and relates to modifying or replacing software. This is especially risky as secure boot enabling and application programming happen at the same time, giving an attacker the opportunity to inject malicious code and leave secure boot disabled. Sample testing (for secure boot status) is an effective way of addressing this. A further mitigation is to have the IC manufacturer programme the device and enable secure boot, preventing malicious code injection at board test. However, board test should verify that secure boot is enabled to detect any issues at the IC manufacturer. This is a good example of how IC manufacturers and board testers can work together to create mitigations to make attacks difficult, if not impossible.
Of course, secure boot only remains secure while the private key is secret. Therefore, these should be kept securely in a hardware security module (HSM) and never exported. Authority to sign keys must be controlled and restricted and for the best security, require two individuals to authenticate, removing the ability for individuals to change code alone.
Identity extraction: Often, credentials such as cryptographic keys and certificates are injected at board test which provides an opportunity for attackers to attempt to gain access to this sensitive data. Provisioning this information securely is both challenging and subtle. The ability to achieve this depends upon the device’s capabilities, what level of physical and IT security is in place and the way the provisioning method is constructed. The scale and cost of the manufacturing operation overlay further challenges. Even with all due care being taken, there remains potential for some flaws in the system.
In short, equipping devices with identities is relatively simple but providing them with robust, secure identities at the scale required, and a cost which is realistic is hugely challenging.
However, if the system is well-designed and private keys are never outside secure key storage then attackers should not be able to access the information they need to forge credentials.
Silicon Labs, for example, stores the private key that we use to generate device certificates in a Trusted Platform Module (TPM) on a PC that is hardened to physical and logical attack and located in an access-restricted cage in the site’s data centre.
Further, those keys are heavily restricted and are applicable to just one production batch. They are also duration limited, created just before testing and deleted immediately afterwards. Should a key be compromised, all associated end products can have their credentials revoked, indicating they cannot be trusted.
Similarly, all devices that support secure key storage generate their private keys on-board, and ensure keys remain in the secure store. Any devices that cannot support secure key storage require keys to be injected, making them more vulnerable to an attacker. So that certificates for relatively insecure devices are not passed off as credentials for high-security devices, all certificates include an indication of the strength of storage used for its private key.
Any test system used by an OEM should limit physical access and be hardened against any modification. All data/usage should be logged, security should be reviewed on a regular schedule and IT controls should be developed and strictly enforced. This would likely include the removal of communal logins and prevention from connecting to the internet. All of this must be checked regularly to ensure that it has not been changed.
By implementing these measures attackers will be prevented from gaining access to a test system, removing their ability to do anything untoward. Also, these measures allow test machines to be allocated to specific customers and/or purchase orders, providing another layer of security. Further enhancement is possible using techniques such as penetration testing, to identify and fix vulnerabilities before they can be exploited.
Any sensitive keys stored within IT systems need proper handling and control – including a secret key store and appropriate access restrictions. Monitoring should be implemented to detect any unexpected operations and, if necessary, appropriate mitigation steps should be taken.
If OEMs would prefer to outsource credential provisioning infrastructure, several silicon vendors offer secure programming services.
Extraction of confidential information
If confidential information is programmed during board test, then there is a chance that the keys or proprietary algorithms could be read by infiltrating the test equipment. To guard against this, the recommendations made for board test should be implemented. If a programming service is used, then the risk is not eliminated, but it is moved to the package test stage.
It is possible to protect confidential information when a test system is breached, provided that the correct set of security features are in place. To achieve this, a central, secured machine is needed as well as a device with a secure engine that can confirm the device’s state without any influence from the test system – and by a method that is verifiable by the central machine.
In this approach, the board tester programmes the IC, enables secure boot, and locks the device and then requires the device to confirm its (locked) state. Should the tester be compromised in some way and not perform correctly, the central machine will detect this within the attested information.
Once the central machine confirms a proper configuration on the device, it can perform a key exchange with the now trusted application and then transfer any confidential information over a secure channel. Using this process, the test system (and therefore an attacker) cannot see or alter the confidential information.
OEMs and security
The responsibility for securing a product lies with the OEM, but many of the challenges they face are almost identical to those faced by silicon vendors. Security and defence against attack begins with basic measures including physical and network security – along with a well-designed end product. Beyond that, adopting the principles used by silicon vendors can enhance security significantly.
Silicon vendors can be useful allies as they offer outsourcing of services and capabilities that OEMs can use to reduce the cost and complexity of securing manufacturing environments.
Implementing these techniques now contributes to security for all connected devices and working in partnership with robust systems, silicon vendors and OEMs can deliver a highly secure Internet of Things (IoT).
Author details: Joshua Norem is a senior systems engineer at Silicon Labs
