Test of Functionality

The testing of the functionality of the processor was carried out by means of a set of about 35 test command files. Apart from inspection of the results of the modular exponentiation, it was checked if the output flags behaved in accordance to the specifications. The data to be exponentiated and the values of the keys (i.e. the modulus and the exponent) were chosen from two categories: The first category was a set of “extreme” values. For example, the

4.4. TEST AND PERFORMANCE 161

Figure 4.15: Example of a test command file.

smallest, and the largest, allowable value of the exponent and the modulus.

The second category was a set of randomly selected values. Furthermore, the second category contained a number RSA key pairs. Hereby, some of the tests comprised a real encryption and a decryption of a series of data values.

To check the results of the modular exponentiation a “reference” program was used. The reference program wasnot an implementation of the modular exponentiation method used by the processor. Instead a standard library routine was used. Hereby, it was ensured that errors in the method would not be inherited by the reference program.

The clocking frequencies chosen for the functionality test were rather low:

160 KHz for the data clock and 2 MHz for the system clock. This was done to ensure that failures would not be due to a too high clocking frequency. Later, when the working chips were found, the clocking frequencies were increased to measure the performance of these chips. The results of the performance

measurements are reported in the next subsection. The following tests were performed:

1. During a process of initialising the key, the response of the doneKey flag was inspected. After reseting the processor, the flag must be high.

Then, when the initialisation process is started, doneKey must go to a low level. Finally, when the key values have been shifted into the processor, and the processor have completed the internal initialisation process, the flag must go back to the high level.

2. Using the relatively simple GP interface, the functionality of the pro-cessor was tested. First, it was checked if data could be shifted into, and out from, the I/O register. Then, it was checked if an exponentia-tion process indeed was performed when the startExp input signal was activated. On an activation of the startExp signal, the doneExp flag must go low, and when the processor have completed the exponentia-tion, the flag must return to high. The correctness of the results of the exponentiation process was verified.

3. For the chips that passed the first two tests, a set of RSA encryption operations and decryption operation were performed. The idea of the test was to encrypt a large amount of random data and, then, after a decryption, to check if the data had changed. For each pair of en-cryption/decryption keys a total of 64,000 data blocks were processed.

However, instead of shifting 64,000 data blocks, each consisting of 561 bits, through the processor, a 64,000-fold encryption, followed by a 64,000-fold decryption, of a single random data block was performed.

Since the outcome of an encryption must look like a random num-ber, this test was comparable to shifting 64,000 random data blocks through the processor. Furthermore, if any of the intermediate results were erroneous, the final result would not be identical to the original data block. During these tests, the frequency of the system clock was increased to 25 MHz, and the frequency of the data clock was increased to 512 KHz.

4. The self-synchronising SLD interface was tested. Since the former tests would reveal failures in the operation of the modular exponentiation unit, this test was primarily aimed at a verification of the functionality

4.4. TEST AND PERFORMANCE 163 of the various configuration possibilities of the SLD interface. The SLD interface is described in Appendix E.

The test of the functionality implied that 8 of the 83 remaining chips were classified as working. Using the GP interface no failures were detected in the functionality of these 8 chips. There was, however, detected a failure in the expected functionality of the SLD interface. The failure was due to an error in the specification of the finite state machine that implemented the SLD interface protocol. So, the failure was reproduced in all of the 8

“working” chips. Fortunately, the GP interface was included in the design of the processor. Hence, it was still possible to use the processor for computing modular exponentials. As a consequence of the failing SLD interface, the processor was never embedded in an ISDN telephone.

The failure was detected when the processor was configured to the trans-mit and crypt mode. In this mode, the resulting 561 bits modular exponential is merged with a 79 bits synchronisation pattern, giving a total of 640 bits.

During a communication on an ISDN channel, these 640 bits is divided into 80 frames of 8 bits. Except from one frame, each of the 80 frames contains a synchronisation bit. In Table 4.3 the correct format of the output from the processor is shown together with the erroneous format actually produced by the chips. The 561 bits of the modular exponential is denoted c560c559. . . c0, wherec0 is the least significant bit. As seen in the table, the synchronisation pattern is correct in the erroneous format. Furthermore, the format of the frames numbered from 1 to 79 is correct. The failure is in the last frame:

Here a shift of the I/O register is missing in the specification of the control-ling state machine. The consequence is that bit c553 is represented twice in the output format and that the most significant bit c560 is lost.