Damian Budd

B.Sc. Eng. (Hons) Electronic Engineer, Hobbyist and Private Pilot

Nanoteq / Prism Secure Solutions

Duration: April 1999 – March 2002

Position: Software Development Engineer

  • Software Development in C and C++ for the PC including Windows Programming with Visual C++ and MFC.

  • Embedded software in C and Assembly for security modules using 8051 derivatives.

  • Development of PCI cards for security modules.

  • Knowledge of encryption algorithms such as DES, RSA and Hashing algorithms e.g. SHA, MD5.

When I joined Nanoteq I had come from a company who's core expertise was mainly analogue electronics and specifically RF engineering and I was mainly skilled in hardware design with limited software skills. In complete contrast Nanoteq was a company consisting mainly of software engineers and their core expertise was software and crypto systems for banking institutions and electronic payments. Soon after joining them the company they sent me on a C language course to brush up my programming skills and within 3 months I was tapping keys like a seasoned programmer.

The first tasks I had to perform were modifications to existing pc applications and utilities to add new functions. The company had a strict policy of coding style, version control and team collaboration. All team members had to adhere to the same project folder structures on their machines. The company made use of Visual Source Safe for version control. Thus I was introduced to disciplined coding right from the beginning. I also wrote a number of DLLs to wrap around various crypto libraries that were used for testing software.

I was tasked with porting some embedded software to a new security module. A security module is a device that receives an encrypted data packet, decrypts it internally, performs some sort of transformation on it, re-encrypting it to a different format and then passing it on. The module holds internally the required encryption keys and is wrapped in a secure tamper foil and potted in epoxy resin. Any attempt to break into or cut the module open results in damage or destruction of the tamper foil where upon the module will automatically erase its encryption keys and memory. The company was developing a newer version of a particular security module using a newer processor and my task was to port existing software to the new platform. The then new processor was the Dallas DS5240 secure microprocessor which contains a DES engine. The DS5240 is an 8051 derivative and we were using the Keil uVision IDE and compiler. I had to port the boot-loader and application firmware to this device. At the time the latest version of Keil did not support this device as it was very new. Specifically the DS5240 had in excess of the standard 8051 64k of program memory space. Thus the program counter register was larger than 16 bits. Most of the existing Keil C library functions worked fine for this device except for switch statements. The Keil library used a lookup jump table for switch statements where the return address was loaded onto the stack and followed by a POP instruction. Needless to say the DS5240 POP'ed 3 bytes off the stack instead of 2 and everything immediately went south. To work around this I made use of the debugger in assembly view and identified the instructions in the C library that were responsible for switch statements. I copied the assembly instructions into a new source module and made a modification that would generate a 3 byte lookup vector, thus creating a custom library function. Hence before the processor executed the pop instruction the correct number of bytes would be placed onto the stack. I then built this function as a separate object library which I linked into the main build ahead of the standard C library and this circumvented the problem. The porting exercise also required writing various other functions in assembly language (for example to interface to the DES engine inside the DS5240) therefore making use of the C to assembly calling convention of the compiler. I also assisted in the development of PCI cards to interface this security module with a computer.

During my time with the company I became tired of only writing console applications and decided to teach myself Windows programming using the company's copy of the “Visual C++ in 21 days” book. Then after having demonstrated my ability to program for Windows I was tasked with porting a set of key management and configuration utilities which made use of the C-scape DOS graphical libraries. I had to create dialog box equivalent front ends for the utilities and then figure out how to link the high level C++ functions into the lower level functions which were written in C. There were also some other utilities that I wrote using Visual C++.

Another task I was given was to create some library functions to perform statistical measurements on random number generators. In crypto systems the security system is only as strong as the keys that are used in it and if there is anyway to predict a key value based on previous knowledge of the key generator then the system can be compromised. Ideally the key generator should generate completely random keys. There are some statistical measurements that can be performed on noise sources which assess the randomness and quality of the source. Having written up the functions, one day, being at a loose end, I decided to experiment with ASCII graphics in a DOS window. I generated graphs which visualised the output of the statistical functions. Initially this work of mine was frowned upon as being a waste of time, however soon my colleagues began to see the value in it and before long my ASCII graphics functions were being ported across multiple processing platforms and even into the security modules themselves to assess noise generator quality.

The company was bought out by another company called Prism Holdings and became known as Prism Secure solutions. The final project I worked on was a flash file system that had been written by a partner company in another project. The file system was full of bugs and I was tasked with “making it all work”. During this task I decided I wanted to move on and get more exposure to hardware design and work with analogue electronics again. It was around this time my friends in the audio business were getting their new business going and invited me to join them at GGAcoustics (see also the personal hobby project - 120W Amplifier).