Why all the fuss about Huawei?
A review of the UK Government’s position on Huawei, and a subsequent educated guess at the real reason there is so much fuss over it by other Government(s).
Anyone watching recent headlines will know that there appears much concern and controversy by other Government(s) over the UK Government’s choice to continue industrial relations with Huawei.
I very recently had cause to begin development of an app exclusively for use on Huawei mobile phones, due to a particular model having hardware enabling 3D virtual capabilities previously unseen in studios, far less portable devices.
I bought this phone for a quarter of the price of the best known US competitor’s prime offering, which does not have the capability.
Hence my own interest in Huawei.
Without their ground-breaking technology, my own intention to develop something ground-breaking with it could not exist.
Anything threatening our ability to innovate with Huawei is of special concern to me, and anyone else wishing to do similar, and ultimately everyone likely to benefit from those things, i.e. the public.
Especially now as we are looking to strengthen business relationships and create innovation where possible on all fronts, following our recent cooling of political relations with the EU.
So I spent some time with my 20+ year old Systems Architect / Systems Engineer hat on, to review one of the principal artifacts, to try to make some sense of the various informations and mis-informations floating about.
The source of information I mean is the UK Government’s own “Huawei cyber security evaluation centre oversight board: annual report 2019”.
I found it at the following link :-
Huawei cyber security evaluation centre oversight board: annual report 2019
In that 46 page document, having read the whole thing through to get a complete picture for context, a number of key statements become apparent.
The ones that most interested me, with my simplest interpretation of the conclusions drawn for the convenience of folks who might not have the time or wish to dredge through the document itself like I did, are as follows:
“This is the fifth annual report from the Huawei Cyber Security Evaluation Centre (HCSEC) Oversight Board. HCSEC is a facility in Banbury, Oxfordshire, belonging to Huawei Technologies (UK) Co Ltd (Huawei UK), whose parent company, Huawei Technologies Co Ltd, is a Chinese headquartered company which is now one of the world’s largest telecommunications providers”
…A relationship already exists between the UK Government, and Huawei.
“HCSEC has been running for eight years. It opened in November 2010 under a set of arrangements between Huawei and Her Majesty’s Government (HMG) to mitigate any perceived risks arising from the involvement of Huawei in parts of the United Kingdom’s (UK) critical national infrastructure. HCSEC provides security evaluation for a range of products used in the UK telecommunications market. Through HCSEC, the UK Government is provided with insight into Huawei’s UK strategies and product ranges. The UK’s National Cyber Security Centre (NCSC, and previously Government Communications Headquarters (GCHQ)), as the national technical authority for information assurance and the lead Government operational agency on cyber security, leads for the Government in dealing with HCSEC and with Huawei more generally on technical security matters”
“2018 is the fifteenth year of the Government’s active management of Huawei’s presence in the UK’s telecommunications networks”
…The relationship is long-standing, and involves folk of the world-renowned GCHQ ilk, and Huawei, forming the partnership known as the HCSEC.
“In 2018, HCSEC fulfilled its obligations in respect of the provision of software engineering and cyber security assurance artefacts to the NCSC and the UK operators as part of the strategy to manage risks to UK national security from Huawei’s involvement in the UK’s critical networks;
However, as reported in 2018, HCSEC’s work has continued to identify concerning issues in Huawei’s approach to software development bringing significantly increased risk to UK operators, which requires ongoing management and mitigation;”
…The HCSEC has to regularly justify its activities to the NCSC, of the UK Government.
“It should be noted that HCSEC’s 2018 budget is 160% of the 2017 budget, although a proportion of this is related to moving costs and other one-off charges”
…Duly noted. The activities of HCSEC are costing more than expected, hence the reason they will be particularly under pressure to justify their activities.
From the document section titled “Configuration Management”;
“•Configuration management of virtual machines used during the build process is poor. Specifically, virtual machines were not clean at build start, with many containing (sometimes irrelevant) source code, artefacts of previous builds and other detritus.
• Configuration management of the build environment — including toolchains — is poor and sometimes non-existent. Tools are installed multiple times in a build environment, or in environments where they are not needed. Many tools are significantly out of support and have undesirable properties, for example non-deterministic compilation or optimization based on environment variable values.
• Configuration management of source code is poor. This manifests in two broad areas. Firstly, configuration management is not applied consistently between development teams. Product code is managed differently to platform code and both are managed differently to third-party components. Secondly, the integration into the overall product architecture is very poor, with multiple copies and versions of components, apparently identically versioned components containing significant differences, circular dependencies between components and some components regressing in version between overall product increments.”
…There are concerns over Huawei’s configuration management processes.
In my experience, configuration management concerns are normal in software intensive development. There is no such thing as a company developing software with wholly satisfactory configuration management techniques; it does not exist.
Configuration management in any activity is a trade-off, between the rate of development, the cost of development, and the eventual quality of the product.
Configuration management techniques by definition tie up software development processes so that they can be monitored and controlled in ever finer detail. Historically, it has been possible, especially in isolated military and aviation systems, to tie down code development such that it need never be updated, or if it ever is, it is done under extremely well controlled processes, literally; one carefully hand-crafted line at a time, and only after masses of peer reviews.
Configuration management acceptable to “Production” code as it is traditionally known in defence environments would not be tolerable in a commercial software development environment. Whether we like it or not, most commercial code now, for example, Microsoft Windows, has to be released long before it can be fully debugged. In fact, feedback made either consciously or unconsciously by the end users running into problems has become an integral part of the debugging process.
These apparent exponential leaps in the rate of development of new products, are obviously scaring the pants off of traditional configuration management folks.
The Huawei products in question are not specifically military products. There are many drivers, both technical and commercial, of development, and it is almost impossible to monitor and control all of them.
It would be helpful to compare our configuration management concerns of Huawei with those that surely also exist with the products of companies like Microsoft, with their Windows product.
That is before we even get to talking about the elephant in the room, of deliberate “Back doors”, through which eavesdropping by various parties could theoretically be possible, as seems to be implied by the wave of scare-mongering that appears to be going on.
The closest I could see to any such discussion in the NCSC document is the last sentence of this paragraph, which I have highlighted in bold:
“Poor software engineering and cyber security processes lead to security and quality issues, including vulnerabilities. The number and severity of vulnerabilities discovered, along with architectural and build issues, by the relatively small team in HCSEC is a particular concern. If an attacker has knowledge of these vulnerabilities and sufficient access to exploit them, they may be able to affect the operation of the network, in some cases causing it to cease operating correctly. Other impacts could include being able to access user traffic or reconfiguration of the network elements. However, the architectural controls in place in most UK operators limit the ability of attackers to engender communication with any network elements not explicitly exposed to the public which, with other measures in place, makes exploitation of vulnerabilities harder. These architectural controls and the operational and security management of the networks by the UK operators will remain critically important in the coming years to manage the residual risks caused by the engineering defects identified. These findings are about basic engineering competence and cyber security hygiene that give rise to vulnerabilities that are capable of being exploited by a range of actors. NCSC does not believe that the defects identified are a result of Chinese state interference.”
…In other words, the Chinese Government is not suspected of any wrong-doing here, at least not by NCSC, the UK government IT security experts.
“•There were over 5000 direct invocations of 17 different safe memcpy()-like functions and over 600 direct invocations of 12 different unsafe memcpy()-like functions. Approximately 11% of the direct invocations of memcpy()-like functions are to unsafe variants.
• There were over 1400 direct invocations of 22 different safe strcpy()-like functions and over 400 direct invocations of 9 different unsafe strcpy()-like functions. Approximately 22% of the direct invocations of strcpy()-like functions are to unsafe variants.
• There were over 2000 direct invocations of 17 different safe sprintf()-like functions and almost 200 direct invocations of 12 different unsafe sprintf()-like functions. Approximately 9% of the direct invocations of sprintf()-like functions are to unsafe variants.”
…These types of errors are apparent in any software which is generated automatically from higher level tools, such as is common practice in Model Based Systems Engineering (MBSE). This is a technique with which I am well familiar, and which when all is said and done, enables very sophisticated software functionality to be created rapidly, by a very few developers with the right specialist skills.
Indeed, this is the same technique as I intended to employ in the Huawei app of my own development, which I mentioned earlier.
The concern over the tools being used is further expressed by the following:
“Huawei’s configuration management improvements, which have been driven by the UK community since 2010, have not been universally applied across product and platform development groups or across configuration item types (source code, build tools, build scripts etc). Without good configuration management, there can be no end-to-end integrity in the products as delivered by Huawei, and limited confidence in Huawei’s ability to understand the content of any given build or in their ability to perform true root cause analysis of identified issues”.
It should be pretty apparent to anyone, that at the level of scrutiny being applied, inspecting every line, every function call in the code, it would be extremely difficult if not impossible for code enabling any kind of back-door activity to somehow slip under the radar of HCSEC, or subsequently, NCSC.
The main concern of HCSEC appears to be things like long term maintainability, and vulnerability of the software.
“Huawei continues to use an old and soon-to-be out of mainstream support version of a well-known and widely used real time operating system supplied by a third party. Huawei has separately purchased a premium long-term support agreement from the vendor to address vulnerabilities in a commercially viable manner in the future, but the underlying cyber security risks brought about by the single memory space, single user context security model remain. NCSC believes there is currently no credible plan to reduce the risk in the UK of the use of this real time operating system. Huawei’s own equivalent operating system is subject to many of the same Huawei development processes as other components and NCSC currently has insufficient evidence to make a judgement on the software engineering quality and cyber security implications of this component. Furthermore, it employs more modern memory and security models and so integration with the existing product running on the operating system brings risk. This means that moving to this real time operating system may not improve the situation long-term, while bringing integration risk to the UK operators. Work continues between Huawei, HCSEC, the UK operators and NCSC to develop a realistic plan to reduce the long-term risk in the UK networks due to the use of this old, third-party real time operating system. However, NCSC remains concerned about the time elapsed since discovery of this issue without a credible plan being presented.”
…In other words, HCSEC cannot guarantee if Huawei products will be reliable in the future, as their development processes do not enable the future to be guaranteed.
Nothing is new here.
Who can predict the future of any development?
All we can do is use the information of our specialists to give their expert opinion on whether or not all is well.
Reading the report, using my experience of projects in progress, all is as well as can be expected with Huawei, in the middle of what is a very complex development.
It would be crazy to consider throwing away all of the investment already made in the project of this partnership of the UK Government with Huawei, especially as we are likely to reap huge benefits from the additional capabilities apparent in Huawei products.
There appear no more security concerns here associated with Huawei, than those we already know about, with things like MS Windows.
In fact, there are less, as the materials reviewed pretty much eliminate any suspicions that malicious parties could somehow insert malicious code.
Can we really say the same about Microsoft, Facebook, or Google?
Maybe someone else can take the time to research that question.
It won’t be me.
The simple fact is, Huawei are winning against all of their competitors, by pure innovation.
Isn’t that what capitalism is supposed to be all about?
Huawei are beating those who claim capitalism as their core values, at their own game, and the losers will do anything to try avoid losing, even if it means ditching capitalism.
As mentioned at the start of this article, I had some plans to do some new business using some unique technology in certain models of Huawei mobile phones.
Those plans have been shelved, since a certain external party put a sudden, decisive stop to my activities in that area, as well as ruining my business, and possibly also my future as a PhD Candidate Researcher, and a Chartered Engineer, in fact my whole ability to innovate, at the very time when our economy needs innovation, in preparation for our new status as independent of the EU.
Could these be the very same forces as those trying to smear Huawei?
My thoughts on that, and the details of the obstruction I’ve experienced, in direct contravention of the UK Protection of Trading Interests act, are likely to be revealed in my next article.
Watch this space.
The follow-up is has been written now, it is here.