Understanding Security APIs - CrySyS Lab

Chapter 3
Origins of Security API Attacks
This chapter summarises the history of discovery and publication of API attacks
on HSMs. It explains what an API attack is, how the attacks were discovered, and
shows the core ideas behind them. The attacks described have been built up into
the toolkit described in section 7.2. For simplicity, the story of their discovery is
told only in the context of financial security systems, though the same techniques
have been successfully applied to a range of other non-financial applications.
3.1 Early Security API Failures
Anderson was one of the first to introduce hardware security module failures to
the academic community. After spending a number of years working in financial
security, in 1992 he became involved in a class action law suit in the UK, pertaining
to so-called ‘phantom withdrawals’: unexplained losses of money from customer
accounts. Anderson condensed much of his understanding into an academic paper
“Why Cryptosystems Fail” [3]. This paper focussed on the known failure modes
of ATM banking systems, including several procedural and technical failures in the
use of security modules. A cryptographic binding error was typical of the failures
Anderson described:
“One large UK bank even wrote the encrypted PIN to the card strip. It took the criminal
fraternity fifteen years to figure out that you could change the account number
on your own card’s magnetic strip to that of your target, and then use it with your
own PIN to loot his account.”
However, the paper stopped short of including a description of what we would nowadays
call an API attack. Several years later, Anderson described in “Low Cost Attacks
on Tamper Resistant Devices” [6], an incident where a dangerous transaction
was deliberately added to a security module API.
Many banks at the time calculated customer PINs by encrypting the customer’s
Primary Account Number (PAN) with a secret key, then converting the resulting
21