API-level attacks on embedded systems

Bond, Mike; Anderson, Ross

doi:10.1109/2.955101

Cited by 80 publications

(56 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The approach focuses on how confidence in protocol components can be traced across the deployment; it does not analyze vulnerabilities in the underlying behavior of the components (for example API attacks [4]) or their interaction (for example protocol analysis [5,2]), though such techniques could be used to inform the degree of confidence measure. A Needham-Schoeder style protocol deployment was analyzed in this framework.…”

Section: Discussionmentioning

confidence: 99%

Security Protocol Deployment Risk

Foley

Bella

Bistarelli

2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Security protocol participants are software and/or hardware agents that are-as with any system-potentially vulnerable to failure. Protocol analysis should extend not just to an analysis of the protocol specification, but also to its implementation and configuration in its target environment. However, an in-depth formal analysis that considers the behavior and interaction of all components in their environment is not feasible in practice.This paper considers the analysis of protocol deployment rather than implementation. Instead of concentrating on detailed semantics and formal verification of the protocol and implementation, we are concerned more with with the ability to trace, at a practical level of abstraction, how the protocol deployment, that is, the configuration of the protocol components, relate to each other and the overall protocol goals. We believe that a complete security verification of a system is not currently achievable in practice and seek some degree of useful feedback from an analysis that a particular protocol deployment is reasonable.

show abstract

Section: Discussionmentioning

confidence: 99%

Security Protocol Deployment Risk

Foley

Bella

Bistarelli

2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…We fear however that, while the sandboxing idea will stop most of the malware attacks targeted at the pre-hats versions of the underlying OS, a determined attacker working specifically against the multi-hat configuration will in most cases be able to bypass the protection, possibly using techniques inspired by the API attacks community [11]. There are just too many possible interactions if the machine must still be usable and user-friendly.…”

Section: One User Many Hatsmentioning

confidence: 99%

One User, Many Hats; and, Sometimes, No Hat: Towards a Secure Yet Usable PDA

Stajano

2006

Security Protocols

View full text Add to dashboard Cite

Abstract. How can we design a PDA that is at the same time secure and usable? In current implementations the two properties are mutually exclusive. Because normal users find password entry inconvenient, the balance usually shifts away from security, leaving the PDA vulnerable if lost or stolen. We begin by envisaging what an ideal PDA authentication mechanism might look like and by carefully examining alternatives to passwords such as tokens and biometrics. We then expose another aspect of the security vs. usability problem. In many cases, when we turn on our PDA, we only access functionality (dictionary, calculator, web browser. . . ) that requires no access to private data stored in the machine; why, then, should we pay the usability penalty of authentication in such cases? Moreover, we may want to grant another person temporary access to such "harmless" functionality, but without being forced to grant them unrestricted access to the whole machine. To solve this problem we describe a system in which we may assign more than one "hat" to the owner of this single-user device, with each hat having specific privileges. The machine supports concurrent graphical logins for several hats and a convenient mechanism to switch between them. There is also provision for a userid associated with "no hat", to which one can switch without the need for authentication, and which can access all the harmless functionality. This scheme turns out to be applicable and useful well beyond the limited realm of PDAs.

show abstract

“…To carry out this check, we maintain a list W of triples (h, h , w) such that the query O C WrapKey (h, h ) received the response w. 3 If the wrap submitted to O C UnwrapKey was indeed generated by the token, we know the contents of the wrap, so the new handle is given the same index of the originally wrapped handle. 4 If the wrap submitted to O C UnwrapKey was not generated by the token, then it was forged by the adversary. If the unwrapping key is compromised, then the new handle is assumed compromised and given index 0.…”

Section: Security Definitionmentioning

confidence: 99%

A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

Stanley-Oakes

2017

Financial Cryptography and Data Security

View full text Add to dashboard Cite

Abstract. Cryptographic APIs like PKCS#11 are interfaces to trusted hardware where keys are stored; the secret keys should never leave the trusted hardware in plaintext. In PKCS#11 it is possible to give keys conflicting roles, leading to a number of key-recovery attacks. To prevent these attacks, one can authenticate the attributes of keys when wrapping, but this is not standard in PKCS#11. Alternatively, one can configure PKCS#11 to place additional restrictions on the commands permitted by the API. Bortolozzo et al. proposed a configuration of PKCS#11, called the Secure Templates Patch (STP), supporting symmetric encryption and key wrapping. However, the security guarantees for STP given by Bortolozzo et al. are with respect to a weak attacker model. STP has been implemented as a set of filtering rules in Caml Crush, a software filter for PKCS#11 that rejects certain API calls. The filtering rules in Caml Crush extend STP by allowing users to compute and verify MACs and so the previous analysis of STP does not apply to this configuration. We give a rigorous analysis of STP, including the extension used in Caml Crush. Our contribution is as follows: (i) We show that the extension of STP used in Caml Crush is insecure.(ii) We propose a strong, computational security model for configurations of PKCS#11 where the adversary can adaptively corrupt keys and prove that STP is secure in this model. (iii) We prove the security of an extension of STP that adds support for public-key encryption and digital signatures.

show abstract

API-level attacks on embedded systems

Cited by 80 publications

References 9 publications

Security Protocol Deployment Risk

Security Protocol Deployment Risk

One User, Many Hats; and, Sometimes, No Hat: Towards a Secure Yet Usable PDA

A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

Contact Info

Product

Resources

About