Recently the UK news outlets and media feeds have moved their focus from Brexit onto 5G. One of the biggest topics of conversation has been the use of Huawei as a supplier and concerns about the risk to national security and intellectual property (IP) of allowing such use (see above). What are the risks inherent in such a deployment, and what mitigations can the UK take to ameliorate such concerns?
Many parts of the UK industry, both public and private sector, have been arguing for some time that the release of 5G technology is a crucial step in our evolution to a digital economy, and the reality is that such a transition will need to utilise equipment from the ‘big three’ of cellular communications – that is Huawei, Nokia or Ericsson. The arguments for Huawei are around cost and the fact that they already have a presence in our existing 3G and 4G infrastructure. The cost of replacing the existing hardware would be punitive, at least according to the UK Government. But is that the only option? Can we avoid throwing the baby out with the bathwater and still assuage the concerns of the anti-Huawei lobbyists?
The components that will be used in the upcoming 5G infrastructure consist of two parts – hardware and software. The first thing to bear in mind is that hardware components on their own pose little risk. Indeed, Huawei themselves do not manufacture hardware at the chip level – and their branded hardware – be that cell phones or network components – contain thousands of components produced in China and other locations (such as Taiwan), with only a small percentage actually being designed by Huawei.
The main risk comes from the software associated with these components. Software exists at three levels which are: (going from lowest to highest level) Microcode, Firmware and application software. Microcode was invented by Maurice Wilkes, a British Computer Scientist, in the fifties, although it was popularised by the IBM System 360 in the sixties. Microcode is used to define or augment the instructions provided by a given CPU. Modern x86 processors (such as those developed by Intel and AMD) still use microcode, and updates can be delivered by application software, often the operating system. Intel has used Microcode updates to fix bugs in their CPUs, and recent updates were released to try and mitigate the Spectre and Meltdown exploits.
Firmware is the next level up, it provides various functions from a basic abstraction layer, through APIs (application programming interfaces) to a full-blown OS (such as Intel’s Minix based management engine (IME) built into many Intel supplied PC motherboards). Firmware is currently receiving a lot of attention from security researchers looking at exploits such as BadUSB (where a humble USB stick/ thumb drive can pretend to be another device and literally hack your hardware as soon as its plugged in).
My definition of application software is necessarily broad – I include the operating system, applications plus any scripts and configuration files necessary to allow a device to perform the task(s) it was designed to do. Many appliances and embedded systems (such as network devices, firewalls, routers and suchlike) often use open-source software as the main OS due to considerations around cost and licensing. However many manufacturers use patched versions of such software, and if those patches are not made public they can become a security risk themselves.
Mitigating the risk
Mitigations need to be focussed at each of the software layers discussed above. Microcode is the most difficult potential risk to mitigate – by its nature, it is very hardware-specific and in reality, it is unlikely anyone will be able to produce alternative microcode except the hardware manufacturers themselves. The only realistic mitigation is to audit any microcode updates and to use automated testing to ensure that any changes do not compromise the operation or security of the system.
Firmware can be replaced – indeed there is an initiative within the open-source movement to provide FOSS (free and open-source software) alternatives to many proprietary firmware solutions including the firmware (aka BIOS) software for a selection of PC motherboards. As far as network appliances are concerned there are several leading solutions for SDN (software-defined networking) based on, and available as, open-source code.
Many network component suppliers utilise open-source based solutions as their main operating system and network stack – most of these are based on Linux technology.
Finally, the hardware designs themselves should be audited and reviewed – most of the Huawei SoC (system on a chip) solutions use CPU designs from ARM – a formerly UK based and owned processor design company – which was recently purchased by the Japanese owned Softbank group. Most of Huawei’s designs are created by HiSilicon, one of its subsidiaries.
Network hardware is quickly becoming ubiquitous and an increasing number of components are available from sources in China. Trying to compete with that by manufacturing components in the UK is a non-starter as well as the wrong direction to focus our attention and resources. The way to ensure we manage both national security and IP is to focus on the weakest link – the software components. As part of their recommendation to the UK Government, the National Cyber Security Centre (NCSC) said, in highlighting Huawei as an HRV (high risk vendor):
“Our experience has shown that Huawei’s cybersecurity and engineering quality is low and its processes opaque. For example, the HCSEC Oversight Board raised significant concerns in 2018 about Huawei’s engineering processes. Its 2019 report confirmed that “no material progress” had been made by Huawei in the remediation of technical issues reported in the 2018 report and highlighted “further significant technical issues” that had not previously been identified.”
In summary, the UK Government should ensure that any hardware that is purchased has open specifications and designs that can be easily audited and is also compatible with FOSS solutions. As discussed above, Microcode needs to be freely available, auditable and test cases should be created and automated. Firmware should be based on open-source software with as few modifications and patches as possible to make it easily supported and updated. Initially, there will be a need to utilise the firmware supplied by the manufacturer but there should be plans in place to replace it with Uk created, or even better, open-sourced code.
As for the application-level code again it should be open source wherever possible. Many hardware vendors already use open source code for their consumer-level equipment, this just requires that similar code is used in their enterprise hardware – some of the biggest suppliers do this already.
Finally, some of the responsibility for protecting UK IP from data loss and theft must be devolved to users and corporations. Virtual private networks (VPNs) and data encryption must be used much more widely to ensure that if security issues are found and exploited in the network stack, the data that is carried over those links will still be protected.
A focus on purchasing and deploying open hardware that is compatible with FOSS components and utilising UK resources to create NCSC audited and approved firmware, operating system and application stack would maximise the use of available resources and provide the optimal solution to protecting Uk national security and IP.
Douglas Millward is a highly experienced consultant and systems architect, having worked for some of the largest consulting companies in the world. He is also a qualified higher education lecturer and is currently creating learning materials and delivering courses for Udemy, Kaplan International and the University of Essex Online. Many of the topics covered in this article are covered in a programme of learning he has developed called HANDS-ON, of which the first module covering hardware is available on Udemy now at the link below: