House of Commons - Defence - Written Evidence

Select Committee on Defence Written Evidence

Further memorandum from Scottish Campaign for Nuclear Disarmament

In 1988 an Audit Office report into the Trident programme said:

The report pointed out that at the time the Director General Strategic Weapon Systems was having difficulty recruiting suitable staff. In 1994 the Defence Minister said that software development work had been completed using a mix of internal expertise and specialist contractor support. [26]

1. RELIANCE ON US SOFTWARE

The designers of the Trident D5 adopted a systems-wide approach to meet the accuracy specifications of the missile. They studied and modelled each factor that could reduce accuracy and created a substantial complex of software, computer models and data. [27]These are not static but are regularly updated. While the UK does produce some software for the British Trident system, much of it is of US origin.

The Applied Physics Laboratory of John Hopkins University in Maryland (APL) evaluates the UK Trident missile system. [28]APL designed the systems used to monitor missile tests and they analyse all British tests. [29]Additional analysis is carried out by Charles Stark Draper Laboratories, who make the missile guidance system.

The Trident Fire Control hardware is manufactured by General Dynamics Defense Systems (GDDS). The US Navy regularly places contracts with GDDS for updates of software for the UK fire control system. [30]

K Department of the Naval Surface Warfare Centre at Dahlgren in Virginia develop and test the targeting and fire control software for Trident. The contractor who supports K Department is required to:

"co-ordinate the development of fire control specifications for the United States and United Kingdom SLBM systems and support specification testing..." …

The models referred to are at the heart of the Trident system. [32]They were used for shore-based targeting and performance assessment. In addition parts of these models are integrated into the fire control software on Trident submarines.

In the British software facility programmers maintain, update and modify US codes and models for inclusion in the suite of codes for the UK Trident system. [33]

2. VALIDATION OF US SOFTWARE IN THE UK

When asked about the verification of US fire control software, Des Browne said:

Adam Ingram was asked about US software for the shore-based system and said:

Work on software for Trident is carried out in the Corsham Computer Centre also referred to as the Corsham Software Facility. [36]This is an underground complex close to Basil Hill Barracks in Wiltshire. Mass Consultants Ltd manage the IT system in the centre, on behalf of the Strategic Systems Integrated Project Team. [37]Analysts who assess the performance and effectiveness of Trident use the IT facilities in centre. [38]

The one company in the UK with expertise in analysing SLBM trajectories was Hunting Engineering Ltd. The company changed its name to INSYS and then to Lockheed Martin UK. They now are a subsidiary of the US firm with the main Trident contract.

Some of the validation will be carried out at Corsham but other work is probably contracted out to Lockheed Martin UK.

3. REMOVAL OF CLASSIFIED ITEMS FROM US SOFTWARE

British experts will be hampered in their attempt to validate the software by the constraints of US security restrictions. The Joint Strike Fighter deal showed the difficulties of purchasing equipment which is dependent on sensitive American software. In the case of Trident the US does supply the software codes, but not in their original complete form.

A substantial proportion of US nuclear targeting information is classified so that only US citizens can see it. The Chief of Staff has issued a directive specifying how classified items should be removed from nuclear targeting information, in a process called sanitising, before it is handed to the Corsham Computer Centre, the London targeting centre or the British contingent at Strategic Command in Omaha. [39]

The contractor at Dahlgren has to check that any software handed to Britain has been sanitized, as part of the Quality Assurance (QA) process:

This implies that the process is as follows:

1. US contractors produce software items for the US Trident system.

2. US-only items are removed from the code, data tables and instruction manuals.

3. A US contractor verifies that these items have all been removed.

4. The cut-down software is handed to the Corsham Computer Centre.

5. Corsham and Lockheed Martin UK check that the software works.

6. The software is issued to submarines, the London Targeting Centre and/or the Corsham Computer Centre as appropriate.

4. IMPLICATIONS FOR THE INDEPENDENCE OF UK TRIDENT

From the perspective of Washington it would be desirable to create the impression that Britain can use Trident independently while at the same time maintaining a veto over actual use. One particular concern will be the potential for Britain to launch 144 nuclear warheads at the United States.

How could the software stop a Trident launch?

General restrictions

Preventing the use in all circumstance except tests, or preventing the missiles from being fired Westward, towards the US from the normal patrol areas, should be possible.

Restricting the system to only NATO or joint US/UK plans

The fire control system can probably distinguish an independent British plan from a NATO or Anglo-American plan. Any allied or joint plan would have to be deconflicted. This is a process of integrating two plans to ensure that they do not undermine each other's effectiveness. For example debris in the fallout cloud from the explosion of a British nuclear explosion could cripple a US nuclear weapon and prevent it from detonating. For reasons of complexity and classification it is not possible to run a US attack plan through the British computer system. Deconflicting can only be carried out by running the British plan through the main US nuclear planning system at Strategic Command in Omaha. [41]This deconflicting process is likely to leave a trace in the data which could be detected by the fire control software on the submarine. If the software can distinguish a NATO plan from an independent one, then it could possibly prevent the independent plan from being implemented.

Restricting use by manipulating weather data

A NATO or Anglo-American plan would probably use US weather data. The fire control system requires details of weather over the target area if it is to achieve the desired level of accuracy. For an attack on Russia a large amount of data is required on wind speed and air density at various altitudes. This data has to be transmitted over VLF. It is compressed and formatted in the US into Ballistic Parameters (Balpars). [42]These are transmitted every 12 hours. There are similar mechanisms for producing detailed weather data when Trident is being retargeted against specific targets. [43]It is possible that information could be contained within Balpars or other weather data that would have the effect of switching on or off the UK fire control system.

If the US tampered with the software would we find out?

The US Navy asked Mountain State Information Systems to check the security of the US Trident software. The company's description of this work reveals that this was a complex task for which they had to develop new techniques. This suggests that if the US programmers tried to hide commands within the software it would not be easy for British experts to find them.

The task is made particularly difficult because of the holes in the code, data and manuals where items have been removed for reasons of security. This means that there will be parts of the UK software which do not make sense. But the US manufacturers will not be able to explain the anomalies because the missing material is classified.

As the software has a mixture of cut-down US components and British elements it will be a difficult task to get it to work. This is probably the main focus of the British software effort. Checking to see if the Americans have crippled the code is probably not a priority.

This does not establish that the software has been crippled, but does suggest that it could be. The only way that Britain can guarantee that the Trident software has not been modified would be to produce it all ourselves. But we do not currently have the expertise to do this.

19 January 2007

29 September 1998: UK 534 software changes;

1 September 1999: Development and testing of UK 534 rev 1 software and documentation;

1 September 1999: Develop and test 534 software to support UK missile tests;

8 December 2000: Collection of data for UK 538 software pre Formal Qualifications Testing;

22 May 2001: Review and production of documentation for UK 837 software;

31 May 2001: UK 838 software upgrade;

20 November 2001: Follow-on software and maintenance for UK X38 software;

29 April 2002: Development, integration and maintenance of UK X38 software;

21 October 2002: Design and development of UK X39 and documentation for UK X38;

16 December 2002: Independent Validation and Verification of UK X38 software;

31 March 2004: Development of UK 539 software;