Understanding Security APIs - CrySyS Lab

customise existing transaction sets. Whilst there are only a handful of HSM
manufacturers, there are a multitude of product integrators. The HSM manufacturers
licence out development kits themselves, and may do some of their
own product integration for larger clients.
• End User Corporations are those that buy an HSM solution for a standard
application, or commission a product integrator to make a specialist solution.
The employees of the company will likely interact with the API using some
host software supplied with it in the case of PKI solutions, or written by an
in-house programming team in the case of more specialist APIs. There may
be only one or two people in the corporation with a technical understanding
of the API, who will be responsible for maintaining the corporation’s host
software. The role of the in-house programmers is usually not to replace the
key management facilities – but to supply a further abstracted and simplified
API to other programmers. These simplified APIs are usually not security
critical and repackage only common commands (e.g. encryption, decryption,
signing). Alternatively the in-house team might make facilities available to
employees via a graphical interface. Note that the scope of API repackaging
may only cover the more basic commands; HSM manufacturers tend to keep
master key handling procedures – initialisation, cloning of modules, and recovery
from backup – quite distinct from those used by the normal applications
which interact with the HSM.
• Employees
Employees at corporations that use cryptographic equipment (excluding programmers
themselves) may end up interacting with the Security API every
day. For example, staff at a certification authority that produces certificates
in correspondence with paper forms will be interacting with the Security API
to make every signature, as well as for authentication of their identity. Some
staff may even be aware of high-level rules enforced by the Security API, e.g.
bank tellers will be aware that money cannot be created nor destroyed – just
transferred between accounts. The interface presented to the staff members
themselves can also be considered a Security API if it has particular visible
policies controlling how the staff process sensitive information. Examples of
policies at this level are the anonymisation of individuals in research databases,
and account management functionality for bank tellers. This sort of high level
API was once attacked when an unscrupulous teller discovered that address
changes were not audited by the API. He first changed a customer’s address
to his own, reissued a card and PIN, then changed the address back again.
43