Graham Steel
A security API allows untrusted code to access sensitive resources in a secure way. It is the interface between processes running with different levels of trust. Examples of security APIs include the interface between the tamper-resistant chip on a smartcard (trusted) and the card reader (untrusted), the interface between a cryptographic Hardware Security Module (trusted) and the client machine (untrusted), and the Google maps API (an interface between a server, trusted by Google, and the rest of the Internet).
The crucial aspect of a security API is that it is designed to enforce a policy, i.e. no matter what sequence of commands in the interface are called, and no matter what the parameters, certain security properties should continue to hold. This means that if the less trusted code turns out to be malicious (or just faulty), the carefully designed API should prevent compromise of critical data.
For a full introduction to the subject, see chapter 18 of Anderson's Security Engineering [1, Chapter 18], which is available online.
No, we consider a cryptographic API to just provide cryptographic functionality. A crypto API becomes a security API when it is designed to enforce a policy, i.e. that no matter what sequence of commands in the interface are called, certain `good properties' remain true. In the case of a cryptographic API, the property might be that the true value of sensitive keys remains unknown to the calling application.
No, though they are closely related. Security protocols are short programs that describe how principals may communicate securely over an insecure network, usually using cryptography. If one considers the (possibly malicious) calling application to be the untrusted network, the security API can be considered to be a set of protocols, which the malicious application might call in any order to effect an attack.
An API attack is a sequence of commands which breaks the security policy of the interface.
Yes, many. See for example the work of Longley and Rigby [16], Anderson & Bond, [4] Bond [3], Clayton and Bond [5], Clulow [6,7], Berkman and Ostrovsky [2], Cortier & Keighren & Steel [9], and Delaune & Kremer & Steel [11].
These attacks are not just academic examples - attacks on the APIs of Hardware Security Modules (HSMs) used in the cash machine network have been used in large scale fraud (see for example this Wired article). As a result of attacks like these, the Payment Card Industry (PCI) standard for HSMs (April 2009) now mandates the absence of such attacks (see requirement B9 here - "The HSM's functionality shall not be influenced by logical anomalies such as (but not limited to) unexpected command sequences, unknown commands, commands in a wrong device mode and supplying wrong parameters or data which could result in the HSM outputting the clear-text PIN or other sensitive information."
These attacks differ in particular in the amount of off-line (i.e. not talking to the API) brute force cryptanalysis that is required to complete the attack. Some authors distinguish between a `pure API attack' or `logical attack', where all the attacker needs to do is send commands and do some trivial processing on the output, and other kinds of API attack, where some degree of brute-force cryptanalysis is required.
In formal security analysis, we use the techniques of mathematical logic to model an API, its security policy, and an attacker, and try to find (or prove the absence of) certain classes of attack. This idea comes from existing work in formal analysis of security protocols, which itself is related to formal program analysis.
Generally, researchers have first constructed abstract models of APIs and the attacker following the approach of Dolev and Yao [12]. These models are typically constructed `by hand' from the API specification, and are written in some logic such as first-order Horn clauses or rewrite rules. The search for an attack usually consists of the testing to see if some secret term can become known to the intruder. This can be mechanised as the reachability of a certain state an model checker, or the derivability of a certain term in an automated theorem prover [18,20,10,9,8,19].
Another method that has been used in particular for PIN processing APIs involves modelling the API and the intruder as a Markov decision process, and looking for attacks with the probabilistic model checker PRISM. You can read more about that on the PRISM case-study page.
Yes, formal API analysis has lead to the discovery of new attacks, e.g. [14,11,15], and some proofs of security e.g. [10,9,2,3,1].
It is similar, but typically throwing an API problem at a security protocol analyser produces poor results. The reasons are:
Security API models typically contain global non-monotonic mutable state, which much be modelled accurately to get reasonable precision (i.e. not too many false attacks).
Security APIs typically consist of many dozens of functions which may be called in any order. Security protocols usually consist of half a dozen or so messages in a given sequence. Thus the abstractions which can be used to keep the search space manageable, and the search techniques and tools, are different. APIs usually include several commands which share the same cryptographic keys, which is problematic for composition results which would allow the comands to me analysed in a more modular way.
In API analysis we are typically interested in concrete implementations using particular cryptographic algorithms which may have algebraic properties and susceptibility to certain brute-force attacks. In security protocol analysis we typically assume cryptographic functions are `perfect' or at least IND-CCA. This assumption might not be applicable to APIs used in e.g. pay TV decoders or low power smartcards.
It is a close match - you can regard the code implementing Alice's role in a protocol as offering a security API. If we carry out the analysis with `holes' in the code for arbitrary untrusted code, a la Myers et al [17] we can imagine the holes being filled by the malicious calling application. This is the approach used e.g. by Fournet et al. There are differences though, and not just in scale: in API analysis, we are often concerned with low level key-management commands, i.e. generating, exporting, importing and using keys, possibly to encrypt other keys. Protocols implementation analysis typically excludes these operations (e.g [13]).
Below is my bibliography on API analysis - this is fairly large but by no means complete.