Information BarrierCan people trust equipment when they don’t trust each other?
Scope of the project
A technical project to develop an information barrier – a system which allows the operator to verify only the information they have been told about an item and learn nothing else in the process – and which two parties can trust without having to trust each other. This particular system was designed to analyse gamma radiation from an object and to confirm to the operator whether the radiation was consistent with the presence of Plutonium with a high content of 239Pu, without revealing potentially sensitive details about the object that could be present in the gamma radiation data.
We built up to this point over three phases: first, we built a simple system that could detect the presence of a radioactive source; second, the system was modified such that it could make a judgement about the ratio of two radioactive sources present in an object; and finally we used the lessons learned in that process to design and build a system that could determine the isotopic ratio of plutonium in a measured sample, compare that against a preset threshold and communicate a final ‘pass/not pass’ result to the operator.
Relevance to nuclear warhead arms control verification
Information barriers are systems that might be used in nuclear weapon verification activities to prevent the release of proliferative or other sensitive information. To be useful, the parties involved need to be confident that the information barrier is working as it should and hasn’t been modified. Otherwise, one party cannot be certain that its sensitive information is protected and the other party cannot be certain that results are truthful. If either party distrusts the equipment, it is unlikely to be used in the verification process and so important information may not be verified. The need for mutual confidence is a major challenge to realising the use of information barrier concepts in practice.
Whilst the scientific challenge of detecting Pu behind an information barrier itself is interesting, this project was not focused on radiation detection and analysis. Instead we chose to focus on what would be required for all parties involved to build and maintain the confidence in the equipment, especially when it might be deployed in sensitive facilities. This meant working to understand what it might mean for two parties to build and maintain confidence in equipment in practice, regardless of the level of trust between the parties, alongside ensuring sufficient technical functionality of the equipment for our results to be meaningful.
The project has provided a much greater awareness of the level of understanding that interested parties must maintain concerning the purpose and operational context, the design and the operational deployment procedures of the system, if they are to build and maintain confidence in equipment.
There is no one solution for achieving confidence. Each potential solution to one part of the challenge may have consequences which affect other parts of the confidence building process and so the solution chosen should ensure a workable balance is found throughout the system.
We have found it necessary to refer back to overall the technical verification objectives to ask whether and how the IB can be used to verify the information required. We have found it necessary to make no assumptions about measured objects and so develop a data analysis method that only uses declared information. In this way, the requirement for mutual confidence has affected the method used to analyse the data to determine whether Plutonium is present and whether the isotopic ratio between the isotopes is greater than the preset threshold
In order to consider options for building and maintaining confidence we have been required to think about how the rules and regulations of potential deployment locations place restrictions on the actions of those who wish to maintain that confidence. We have found that software and hardware need to be designed to be interrogated in a way that fits with the deployment restrictions – which means that there needs to be dialogue between technology developers and facility operators from the beginning. Specialist facilities may operate specific rules and restrictions and may qualify equipment, actions and operations only under certain conditions. Because of this generic technical solutions may not be applicable without modification.
Regarding the software used in the IB, we have found that the intent of software should be made clear from the beginning of the project in order to make interrogation simpler when it comes to building confidence.
Without considering each of the factors above – the data analysis method, the design of the software and hardware, and the deployment process (including location specific restrictions) it may be very difficult to build and maintain confidence in the equipment. Most importantly the interaction between these requires attention because of the impact each may have on the others.
For this project, some of the challenges that need to be overcome were exacerbated by the design of the equipment because progress was built upon successful elements of the design from earlier phases; as the project developed it became apparent that some of the earlier design successes were less suited to the new challenge of analysing Plutonium data. Some of the challenges we faced therefore may not have been present, at least not to such an extent, had the design process started over from scratch. Nevertheless, the experience only reinforced the need to understand each of the above mentioned factors when building confidence in the system.
- Project Concepts
- Technical Design Documents
- Final Design
- Instrument Testing and Verification
- Project Analysis
The documents in this section provide an introduction to the project. The general concept is discussed along with some of the design features that were stipulated at the beginning of the project in the belief that they would make confidence building more achievable.
A set of high level requirements is present here, which formally captures the broad requirements that must be met in order to achieve the aims of the project
An introduction to the approach used to analyse gamma radiation is also presented. We believe the approach outlined enables the IB to determine whether ‘weapons grade’ plutonium is present in a sample of material without revealing anything else about the material or object presented for measurement.
The Information Barrier includes custom built electronics with bespoke software. The IB was designed specifically to only perform the intended analysis functions – those set out in the IB data analysis algorithm document. In order to be successful, the other criteria laid out in the high level requirements should also be met.This section contains the details of how the concept was developed into an engineering project.
The project used System Engineering principles to expand the concept of operations and high level requirements to provide a detailed set of engineering requirements which formally describe what the information barrier needs to do and against which success could be determined.
Because the aim of the project was to identify and explore the challenges to building and maintaining confidence, we have not focussed on the production of a fully qualified system. Instead we have been content with the project finishing at the end of the prototype development stage, since we believe those challenges are sufficiently evident at this stage. From the perspective of the documentation presented here, this means that some of the determinants of success that arose through use of systems engineering principles have not been reached. Nevertheless, systems engineering has been helpful in allowing challenges to be investigated whilst balancing resources to meet our overall objective
This section also includes greater detail of how one might analyse radiometric data based only on the declared information,
The data analysis method needs to be turned into software code to be embedded on the IB hardware. At its highest level, the the software requirement was exactly this – perform the analysis as laid out in the data analysis algorithm documents The software requirements specification captures that requirement formally in much more detail. The Ada design document then details how the software was designed to meet the requirements.
The final technical design includes design drawings for the hardware and the bespoke written software code. Both elements are found here.
In order to build confidence, all interested parties need to be content with how the equipment should be built and how it should operate. By providing the design, the software code, and details of the analysis functions, the design can be openly understood by all parties. Built instruments are open to interrogation to ensure they are built correctly and deviation from the design found in a manufactured IB could be questioned.
A note regarding the software
The data analysis method was developed into two different versions of software with each being written in a different language. This allowed different approaches to software authentication to be considered. At this point, only the Ada version of the software code is available for publication
The Ada Software was written in tandem with the development of the proposed analysis method (in order that we had operating prototypes to use and test). It was also written in anticipation of some of the processing limitations put in place by the chosen microprocessor. Though complete, in terms of being able to execute the intended functions, as a prototype it is a work in progress to some extent. . As such, some elements of the code may not be optimal for the intended function and so could be improved in a wholesale revamp of the IB, if started from scratch. For instance, some early elements of the code have been kept though turnover of personnel resulted in the loss of some of the early software design decisions which led to that code being written as presented.
For a final product (as opposed to our prototype), the software would need to be written following the proposed authentication method. Nevertheless, for understanding the challenges to building confidence and for identifying confidence building methods, we can say that the code published here is the agreed code – so long as the code on a manufactured IB is the same as this code, it can be said to be correct. The authentication method should be able to show whether the code on the IB is the same.
A point to note regarding IB naming conventions on the hardware technical documents
The nomenclature on a number of the documents here is inconsistent. Some documents refer to ‘Phase II’, others to ‘Phase III’, or even ‘Mark III’. Whilst Phase III an Mark III are simply interchangeable names, the Phase II drawings were first produced for an earlier iteration of the IB, before it was developed to measure plutonium, and these elements of the design were simply reused for Phase III. All documents presented here are the correct versions.
No files found in this folder.
The IB has been evaluated and tested in a number of ways to ensure that it works correctly and is capable of fulfilling its intended purpose. In this section, documents related to those tests are published.
The method proposed for authenticating the software on the IB is presented here. The purpose of authentication is to ensure that the software operates as intended, that it correctly analyses the input data, and to ensure no extraneous code has been inserted without approval of all stakeholders in the design.
A report on how well the method and software performed when the method was applied to a demonstrative section of the prototype IB code is also found here. The recommendations and observations from these reports would need to be considered when producing a final (as opposed to prototype) version of the software code.
The software has also been evaluated and tested to ensure it correctly fulfils the requirement set.
Software testing, both for quality and authentication purposes, has been performed on a subset of the entirety of the software. This was done as a proof of principle on some of the primarily analytical tasks the IB is due to perform on data. The sections chosen are representative of the entire code and the principles could be applied in the same manner to the whole code.
For the purposes of this project – learning lessons concerning the building and maintaining of confidence, this approach was deemed to be sufficient. However, it is also a good example of why the IB should not be considered ready for operational deployment. The entirety of the code and the overall performance of the IB have not been sufficiently evaluated to ensure that the level of quality necessary for production has been achieved at this stage of the development process.