Presented at INMM in July 1998 (26th-30th), in Naples, Florida.

ABSTRACT

As the environment for conducting Safeguards grows increasingly hostile in some areas, the need to utilize reliable and secure instrumentation becomes crucial. A vulnerability assessment of the authentication system in GEMINI was undertaken as a Joint Programme by the US and Canadian Support Programs in support of the efforts of the International Atomic Energy Agency (IAEA). The actual assessment was performed by the Communications Security Establishment (CSE) and the Atomic Energy Control Board (AECB) of Canada. Substantial effort was expended in tracking this project with the goal of providing a template for future evaluations required by the IAEA. Conclusions drawn from this assessment emphasize the importance of supplementing strong cryptography with rigorous operation and inspection/maintenance procedures. This paper discusses the methodology behind a vulnerability assessment and its application to future technology evaluations.

INTRODUCTION

The "threat" against Safeguards instruments is quite sophisticated. One has no choice but to assume that the attacker has resources comparable to those of a government in carrying out the attack. These resources include financial capacity, technical knowledge and ability, and the capability to acquire and apply those resources in carrying out the attack. At the same time; however, the threat is restricted to those attacks which are undetectable in the normal course of a Safeguards inspection and review. Any attack that left evidence of the attack would immediately attract attention. For example, destruction or denial attacks are immediately obvious upon inspection and therefore are not included in the threat regime. Examples of attacks that are within the threat regime include tampering with the operational setup or parameters in a way that cannot be discovered in the normal course of inspection, substitution or modification of data collected from the instruments, substitution of the instruments themselves, synchronizing of activities to the sampling cycle of the instruments, and replacement of data after the inspection cycle.

VULNERABILITY ASSESSMENT PROCESS

A rigorous vulnerability assessment evaluates all aspects of a system's operational lifecycle in search of elements that might present an opportunity for an adversary to tamper with the system in a manner that cannot be detected during a normal Safeguards review. The assessment therefore necessarily evaluates both the data collection portion of the system and the data review portion of the system. The assessment includes, but is not limited to, an evaluation of the cryptographic techniques included in the system to protect the Safeguards data. Adversarial opportunities are equally likely to be presented by such elements as physical construction, physical signals, procedural assumptions, and operational implementation of features as they are by the cryptographic protections.

Historically, it is well known that the weaknesses of secure systems almost always occur in the implementation and operating procedures and assumptions. Nonetheless, these weaknesses are moot in the presence of physical vulnerabilities or weak cryptography. Consequently, the evaluation of GEMINI followed a very systematic and rigorous process. As represented in Figure 1, the vulnerability assessment process begins with a search for physical vulnerabilities, followed by a detailed verification of the cryptographic algorithms, and finally culminating in a thorough analysis of the implementation and operation of the system.

It is important that each of these analyses be conducted in the order shown to ensure that each succeeding assessment be placed on a firm operating foundation. In the absence of this precedence of approach, a great deal of work can be wasted. In the case of GEMINI, the Canadian assessment team followed this precedence rigorously to arrive at conclusions expeditiously.

Figure 1:
Steps in the Vulnerability Assessment Process

Physical Vulnerabilities

The GEMINI was thoroughly examined, prodded and explored to uncover any weaknesses in the enclosures and cabling. The sealed camera housing and main cabinet were examined for any access points that would permit insertion of probes, tools, or other devices that might interfere with operation or allow signal injection. Furthermore, GEMINI was systematically operated to determine if the system emitted any signals that might aid an attacker in synchronizing activities around times when the surveillance system was taking pictures. In particular, the assessors looked for systematic sound and thermal signatures that were correlated with the activity of the system.

Cryptographic Algorithms

Once it was determined that there were no physical vulnerabilities that would render the authentication meaningless, the authentication algorithms were examined in great detail to verify that the algorithms were exactly those specified in the documentation. The importance of this step must not be underestimated -- it is critical. Well known and thoroughly attacked algorithms have a much greater confidence of being secure than do new algorithms that have not been exposed to the attacks of the open cryptographic community. Nonetheless, it is essential that the algorithms that are actually implemented be verified to truly be those that have survived the open attacks.

The algorithm validation process consisted of a three step process. The first step was to verify that the MD5 hash function implemented in the digital camera was truly the MD5 function. To verify this, the Canadian team diligently reviewed all of the software in the camera that implemented the MD5 function, as well as the GEMINI Advanced Review Software (GARS) that uses BSAFE to re-create the digest. To further test the algorithm, the team created a completely independent version of MD5 and verified that the results of the camera algorithm and their independent version were identical. These tests concluded that the MD5 hash algorithm implemented in the camera and in GARS were in fact the actual MD5 algorithm and that the security attributed to that algorithm is therefore a feature of the GEMINI.

The next step was to verify that the RSA signing procedure was correctly implemented and that it was therefore truly the RSA method. To accomplish this the relevant camera software was thoroughly examined and found to contain the correct process. To verify its operation, a test simulation was established in which GEMINI data was authenticated using an independent implementation of the signing process and then submitted to GARS for authentication. This verified that GARS properly processes RSA authenticated data and rejects faulty data with an error message. Next, the signed pictures from the camera were verified to be properly authenticated by GARS. Since GARS was shown to correctly process properly authenticated images and to reject faulty data, the fact that GARS processed images from the camera verified that the RSA signing procedure was properly implemented.

The final step was to determine whether the key generation process was properly implemented in the camera. Since the strength of cryptographic techniques lies entirely in the keys, proper key production is paramount to the strength of the overall system. The analysis team examined the software that generates the keys and verified the correctness of the prime number generators and the modular exponentiation. Finding no weaknesses in the software, they then examined the method for generating random seeds. Since that mechanism depends upon physical noise characteristics, the Canadian team sampled the output to verify randomness. The assessment determined that the seed process does indeed produce numbers of randomness suitable for cryptographic purposes. Perhaps an even more important benefit to the IAEA came from the assessment teams efforts to characterize actions that might be taken that would either weaken or strengthen the key generation process.

With the completion of this phase of the assessment, it was determined that the algorithms implemented in both the GEMINI camera and the GARS review station were truly the MD5 and RSA algorithms described in the design, and that they therefore express the strength and robustness that those algorithms exhibit in the open literature. Consequently, it was not necessary to attempt to verify the security of the algorithms, since their security is well known and accepted.

Cryptographic Implementation and Operating Procedures

With the completion of the previous two phases of the assessment, it was known that the GEMINI had no physical vulnerabilities that would impact upon the security of the system and that the cryptographic algorithms had been verified to be the well known and accepted MD5 hash function and the RSA signing algorithm. With the baseline established, the primary effort could then be devoted to the area of greatest concern in every system - implementation and operation. The remainder of the assessment focused on procedures, key management, operational flow, and inherent assumptions.

Hardware and software were examined to determine whether either were likely to generate false alarms that would mislead an inspector into ignoring real alarms. During the course of the assessment, no false alarms were encountered. Then the complete list of error codes were examined to determine whether an adversary might gain useful information from the type, presentation, and frequency of different kinds of errors. Many different scenarios can cause the same hardware error. It was determined that when an error occurs it will be cleared during the normal operational cycle, causing only one scene to be missed consistent with the reported error. In the case of a fatal error that cannot clear, the GEMINI would never authenticate another scene. In these cases, there would be no ambiguity in the surveillance record for the inspector to resolve, and thus no opportunity for an adversary to tamper the system undetected.

Key management, being the most essential element of cryptographic security, was examined for weaknesses. A small window of opportunity was uncovered in this portion of the assessment. Fortunately, because of the constant interaction with Aquila during the process, this small window was easily closed.

The installation and setup procedures were examined to determine whether they left an opportunity for an adversary to tamper with the system during this time. Again, it was determined that there might be a small possibility that could easily be eliminated by Agency installation procedures.

CONCLUSIONS

The methodology for vulnerability assessment developed by the Communications Security Establishment (CSE) and the Atomic Energy Control Board (AECB) of Canada provides a model for both developers and for other vulnerability assessment activities. This methodology concentrates the focus of the assessment team on the entire system and the suite of potential vulnerabilities rather than concentrating all efforts on a single aspect of the operational security elements. At the same time, the methodology ensures that each security element receives the in-depth scrutiny and assessment that is warranted in order to expose any weaknesses.

The vulnerability assessment methodology covers all aspects of the Safeguards system including the physical protection, cryptography, operation, administration, and installation. The vulnerability and security aspects of any system specification are very difficult to explicitly describe. Consequently, these aspects often go unstated in the hopes that developers will simply understand what is needed. In the absence of explicit security requirements, developers of Safeguards systems can apply the elements of the Canadian assessment methodology to provide a security viewpoint on their products so that the vulnerability aspects can be addressed during the design phase rather than as unanticipated modifications later.