Case Study: MULTOS Certification Authority

"I've never seen such a clean handover of deliverables", Andy Calvert, Security Development Manager, Mondex.

"This project has provided further evidence for the benefits of formality, in terms of rigour and dependability", John Beric, Head of Security, Mondex.

Project Background
The Multi-Application Operating System (MULTOS) is a smart-card operating system that allows several applications to reside on a single smart card. A key security concern is the prevention of forging smart cards and applications. To this end, the data that is used to enable smart cards and applications includes digital certificates, which are signed by the MULTOS Certification Authority (CA).

Project Success Factors
This was a very successful development. The number of system faults is very low compared with systems developed using less formal approaches. The delivered system satisfies its users, performs well, and is highly reliable. In the first year after acceptance, during which the system was in productive use, the customer found only four faults. Of course, Praxis High Integrity Systems corrected them as part of their warranty. This rate, 0.04 defects per thousand lines of code, is far better than the industry average for new developments. Indeed, we understand this defect rate to be 2.5 times better than the defect rate for the space shuttle software!

The delivered system contained about 100,000 lines of code. Overall productivity of the development — taking into account all project activities, including requirements, testing, and management — was 28 lines of code per day — three times the industry norm. Fault fixing constituted a relatively small part of the effort; this contrasts with many critical projects where fixing of late-discovered faults takes a large proportion of project resources.

Only four faults with the system were found by the customer in its first year of productive use.

• This rate, 0.04 defects per KLOC, is far better than the industry average for new developments.
• Overall productivity of the development was 28 lines of code per day — three times the industry norm.
• Fault fixing constituted a relatively small part of the effort; this contrasts with many critical projects.
• The delivered system satisfies its users, performs well, and is highly reliable.

The software developed for the CA has a slightly novel architecture. The following requirements were addressed:

• Availability. The software is designed to run uninterrupted, and cannot be upgraded or even restarted without significant effort. Avoiding memory-leaks and unexpected behaviour (e.g. exceptions) was therefore a major goal. The system is also designed to withstand the total failure of one or more machines in the tamper-proof environment.
• COTS. The developers decided to use as little off-the-shelf software as possible, since the security and failure properties of such components could not be depended upon. For instance, we chose to design and implement our own inter-process communications and remote procedure call mechanisms, rather than relying on a COTS solution.
• Lifetime. The system has an expected lifespan of decades. Fast-moving development techniques or technologies (i.e. those that weren't likely to be in fashion next year) were rejected.
• Separation of Security Concerns. Each part of the system was classified as security enforcing, security-related or not secure. In particular, the entire graphical user interface (GUI) and the software outside of the tamper-proof environment are considered insecure. The GUI is dumb in that it knows nothing of the application. All data coming from the GUI is considered insecure, and is rigorously validated by the system. Data displayed on the GUI was carefully analysed as having no threat to security.
• Throughput. The CA is required to generate certificates at a significant rate. This entailed the provision of specialized cryptographic hardware and required concurrency to be employed in some particularly time-consuming operations.