Understanding Security APIs - CrySyS Lab
Understanding Security APIs - CrySyS Lab
Understanding Security APIs - CrySyS Lab
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
• To isolate and define the code which was security relevant, and to physically<br />
separate it into a device not under control of the system administrators.<br />
• To minimise the amount of security relevant code, and to keep the rules governing<br />
its use as simple as possible, so that it would be easier to avoid bugs.<br />
In practical terms, financial HSMs were entrusted with the secret keys used for<br />
deriving customer PINs from account numbers. Their policy was to ensure that all<br />
PINs stayed in encrypted form, and clear PINs would never be available to host<br />
programmers (they could only be sent in the clear to a secure printer locked in a<br />
cage). As HSMs began to move away from mainframes into high end servers, and<br />
onto the desks of operators, physical tamper-resistance was added to the logical<br />
<strong>Security</strong> API. These financial <strong>APIs</strong> are still in existence today, are used by banks all<br />
over the world, and have not been substantially redesigned since their first inception.<br />
2.3 The Present<br />
The next significant advance was when <strong>Security</strong> <strong>APIs</strong> were used to enforce more<br />
complex policies than just protecting secrecy of keys. The introduction of electronic<br />
credit tokens for prepayment services such as electricity meters (and most recently<br />
mobile phones) gave rise to a new application – credit dispensing. A <strong>Security</strong> API<br />
could have a policy allowing the repeated execution of a credit dispensing command,<br />
deducting an amount from a credit counter each time.<br />
The mid-nineties has seen new applications for <strong>Security</strong> <strong>APIs</strong>: securing certification<br />
authorities and internet payment infrastructures. In addition, embedded devices<br />
such as smartcards, which are much smaller and more numerous than hardware<br />
security modules (HSMs), are beginning to add policy enforcement to their <strong>APIs</strong>.<br />
So security and cryptography are no longer restricted to the military and banking<br />
worlds. Now that corporations and individuals have seized the initiative, wherever<br />
competition arises in life, the tools of the security world can go to work protecting<br />
people’s interests. <strong>Security</strong> considerations are about to become ubiquitous: every<br />
major operating system ships with substantial crypto facilities, and so do mobile<br />
phones. With the rise of wireless communications, we will see “home area networks”<br />
becoming established, and even washing machines and fridges will use embedded<br />
cryptographic controllers to communicate securely over the airwaves.<br />
–And with every application that uses security comes a ‘<strong>Security</strong> API’, forming the<br />
interface between the application code and the security relevant code.<br />
19