Understanding Security APIs - CrySyS Lab

Chapter 2
Origins of Security APIs
There are probably several hundred API designers at work today, and this figure will
grow as Security APIs become ubiquitous. However, their origins were in the hands
of only a few people: small teams of engineers and scientists, first in the US military,
and then in Automated Teller Machine (ATM) security. This brief survey attempts
to show a unifying logic behind the development of Security APIs (of course, history
is not as simple as this, and the individual motivations and perspectives of the
parties involved will not necessarily conform).
2.1 Beginnings
Security APIs were born in an age when dedicated hardware was necessary in order
to do cryptography. The major algorithm of the 70s and 80s – DES – was designed
to be efficient to implement in hardware. The computers of the day needed a simple
command set to govern communication with this hardware: it might consist of a
command to set the key, a command to encrypt, and one to decrypt. Here was the
first cryptographic API, though it could not yet be considered a Security API, as
there was no policy on usage to enforce.
As digital cryptographic equipment became smaller and more portable, the military
adopted in increasing numbers of roles, such as to secure battlefield communications
links. Whilst cipher rooms in embassies abroad would have good physical security,
the dynamic environment of the battlefield could not offer crypto equipment or the
keys within it any long-term safety. Tamper-resistance provided a partial solution
to the problems of battlefield capture.
The principle of tamper-resistance was part of military thinking for some time.
Military analogue and digital equipment was built with custom-marked components
for many years, which made reverse-engineering and re-commissioning of stolen or
damaged equipment harder. Tamper-resistance found further applications in nuclear
command and control. This was an issue of particular concern in the late 1960s;
17