供應鏈攻擊及保護「信任鏈」(只提供英文版本)
日期 : 2021年7月20日
機構 : 泰雷茲(Thales)集團
作者 : Mr. Welland Chu, Business Development Director, APAC 及 Mr. David Madden, Senior Business Development Director, Global
Introduction of “supply-chain attack”
Over the past decade, cyber security incidents which have caused devastating damages have largely been attributed to something called “supply-chain attacks”. These hacks include Stuxnet (first uncovered in 2010), Target (2013), SolarWinds (2020), as well as other incidents involving phishing and ransomware attacks. Supply-chain attacks happen when a malicious actor stealthily inserts malicious codes into a trusted piece of software code or hardware without the knowledge of its owner. The infected software or hardware then executes the malicious codes undeterred by the system as the system unwittingly believes it to be a trusted component.
The root cause
We learned that the Stuxnet incident was caused by a malware attack. The programmable logic controller (PLC), which was responsible for purifying the radioactive materials in Iran, had been loaded with malware-infected drivers. The nuclear centrifuge, which the compromised PLC was controlling, then began its path to self-destruct by spinning itself out of control, causing an unrepairable damage to the facility. For the case of Target, the Point-of-Sale (POS) system was compromised and allow malware to steal the customer credentials from the infected POS terminal, resulting in the largest data breach ever at that time, affecting over 40 million customers. As for SolarWinds, the IT monitoring and management tools vendor unwittingly sent out software updates to its customers that included malware infected code, allowing hackers to infiltrate the networks of over 18,000 customers. In all of these incidents, these supply-chain attacks were only possible because the hackers have successfully abused the trust the users have on their hardware or software which were deployed in their environments.
Can these hacks be stopped?
If supply-chain attacks are to be stopped, the supply-chain environment must be properly protected. Measures of protection include the use of Identity & Access management of the users, proper vetting of staff and third parties, source code scanning, third-party library scanning, and a secure Continuous Integration/Continuous Deployment (CI/CD) process environment. Readers may see that all of these security measures are undertaken to protect the crown jewel, which are the hardware devices and the software codes running on top of them. Therefore, an important step to take is to mandate the “white-listing” of all hardware and software with only genuine components being trusted and allowed to execute their intended functions. In such environments, devices will only run trustworthy firmware or application codes. Firmware or application codes will, at the same time, only allow themselves to be loaded in legitimate devices. This mutual authentication process thus provides the self-defense capability on every component and eliminates the risk of malware loaded into the system. The question now is: How can Trust be imbued into these systems from inception?
How to implement “Trust”
Integrity checking of firmware or application codes is required to ensure legitimacy of these components. Several technologies have been proposed to serve this purpose. These includes conventional methods such as checksums generated on the hardware / software components or application of symmetric cryptography. Other more exotic techniques such as steganography has also been proposed. However, for security controls to be widely accepted by the industry, the chosen technology must satisfy a number of criteria including an assurance that sufficient security is in place against known threats, high cost-effectiveness, high performance, high scalability, and ease of deployment. To this end, public key infrastructure (PKI) is a well-proven technology that ensures the authenticity of devices and relevant codes while meeting all of the above criteria. This approach leveraging PKI and digital identities, ensures that only trustworthy devices, firmware and application codes can run in a system. The idea is that each entity in the system (this includes the IC chip, device hardware, bootstrap, firmware and application code) is given a unique digital “birth certificate” which is signed by a trusted party (e.g. certificate authority). The digital signing process can be effected during the manufacturing stage using the manufacturer’s private key. For the software component, the firmware and application codes will be digitally signed by the original developers. When a device needs an update and a firmware/application code is going to be loaded into the device, the device will use the code signing certificates of the firmware/application code to verify the identities of the manufacturer / developer. The device will then check the integrity of the firmware/application codes to ensure the software has not been tampered, before the code is accepted and loaded onto itself. Examples of real use cases of this mutual authentication range from cloud deployment, container platform, aircraft engines to the mobile phones we use every day, see Figure 1 below for an overview of chain of trust (COT) among mobile devices and mobile apps.
Figure 1 - Mutual authentication with digital signature technique
Clearly, protecting COT and the cryptographic signing keys (private keys) is critical in any system. The private keys of hardware devices can usually be protected within the secure memory storage of the machine control unit. Manufacturers can centrally generate cryptographic keys before loading them into devices as part of the device provisioning process. The equipment deployed for this task should meet specific security standards, such as using Federal Information Processing Standards (FIPS)-certified hardware security modules (HSMs).
The role of HSM
According to NIST, a HSM is “a physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing”. Cryptographic operations such as key generation, encryption, decryption, and signature verification are typically hosted on the HSM device, and many implementations provide the additional benefit of hardware-accelerated mechanisms for cryptographic operations. The HSM has a special role for deployment on-premises, in the cloud and at the edge as it is in effect acting as the anchor of the “chain of trust”. This chain comprises of “Bootstrap”, “Firmware”, “OS/Applications”, “Communications”, and finally, “Data” as illustrated in Figure 2. Without the trust established at this foundation level, the trust of the whole system will be called into question.
Figure 2 - Chain of Trust
Hardware/software vendors should choose the HSM based on their business requirements covering operational needs and cyber security:
- Flexibility of deployment models: PCI-e card, Network based Appliance, HSM As-a-Service from the Cloud; this enables the users to leverage the efficiencies and scale and thus maximising their return of investment based on their business models.
- Universal client: users only need to work with one client and one set of API allowing the application to be interfaced with all of the different deployment models of HSMs; this helps shorten the time to value and minimise on-going support on the development codes.
- Ready to be deployed for hundreds of different PKI and cryptographic applications and use cases, including key and secrets management, IoT, Quantum Computing, blockchain, 5G, code signing, DevSecOps, cloud migration & machine identities,
Flexible deployment of HSMs (on-premises, in the cloud or at the edge) enables hardware manufacturers and software developers to undertake this transformation securely, by allowing the protection of data & applications wherever they may reside. Additionally a new type of identity is evolving to meet the needs of cloud models, called “machine identities” as coined by Gartner, to help protect devices & applications. Different deployment scenarios can be seen in the following diagram below:
Figure 3 - HSM deployment use cases
Conclusions
As our world becomes more connected, with applications running on-premises, in the cloud and everywhere in between, we must rethink our strategy of establishing and assuring trust. Anatomy of the recent “supply-chain attacks” indicates the hackers were targeting wider and lower in the platform stack. This article is intended to give readers some ideas on how the “chain of trust” can be established, how the root of trust can be anchored and thus enabling hardware manufacturers and software developers to implement a strategy of “defense in depth” and thereby achieving “Security by design”.
