Flexible Information-Flow Control

As more and more sensitive data is handled by software, its trustworthinessbecomes an increasingly important concern. This thesis presents work on ensuringthat information processed by computing systems is not disclosed to thirdparties without the user\u27s permission; i.e. to prevent unwanted flows ofinformation. While this problem is widely studied, proposed rigorousinformation-flow control approaches that enforce strong securityproperties like noninterference have yet to see widespread practical use.Conversely, lightweight techniques such as taint tracking are more prevalent inpractice, but lack formal underpinnings, making it unclear what guarantees theyprovide.This thesis aims to shrink the gap between heavyweight information-flow controlapproaches that have been proven sound and lightweight practical techniqueswithout formal guarantees such as taint tracking. This thesis attempts toreconcile these areas by (a) providing formal foundations to taint trackingapproaches, (b) extending information-flow control techniques to more realisticlanguages and settings, and (c) exploring security policies and mechanisms thatfall in between information-flow control and taint tracking and investigating whattrade-offs they incur

A Principled Approach to Securing IoT Apps

IoT apps are becoming increasingly popular as they allow users to manage their digital lives by connecting otherwise unconnected devices and services: cyberphysical “things” such as smart homes, cars, or fitness armbands, to online services such as Google or Dropbox, to social networks such as Facebook or Twitter. IoT apps rely on end-user programming, such that anyone with an active account on the platform can create and publish apps, with the majority of apps being created by third parties.We demonstrate that the most popular IoT app platforms are susceptible to attacks by malicious app makers and suggest short and longterm countermeasures for securing the apps. For short-term protection we rely on access\ua0control and suggest the apps to be classified either as exclusively private or exclusively public, disallowing in this way information from private sources to flow to public sinks.For longterm protection we rely on a principled approach for designing information flow controls. Following these principles we define projected security, a variant of noninterference that captures the attacker’s view of an app, and design two mechanisms for enforcing it. A static enforcement based on a flow-sensitive type system may be used by the platform to statically analyze the apps before being published on the app store. This enforcement covers leaks stemming from both explicit and implicit flows, but is not expressive enough to address timing attacks. Hence we design a second enforcement based on a dynamic monitor that covers the timing channels as well

Assumptions and guarantees for compositional noninterference

The idea of building secure systems by plugging together "secure" components is appealing, but this requires a definition of security which, in addition to taking care of top-level security goals, is strengthened appropriately in order to be compositional. This approach has been previously studied for information-flow security of shared-variable concurrent programs, but the price for compositionality is very high: a thread must be extremely pessimistic about what an environment might do with shared resources. This pessimism leads to many intuitively secure threads being labelled as insecure. Since in practice it is only meaningful to compose threads which follow an agreed protocol for data access, we take advantage of this to develop a more liberal compositional security condition. The idea is to give the security definition access to the intended pattern of data usage, as expressed by assumption-guarantee style conditions associated with each thread. We illustrate the improved precision by developing the first flow-sensitive security type system that provably enforces a noninterference-like property for concurrent programs. \ua9 2011 IEEE

Analysis of Key Wrapping APIs:Generic Policies, Computational Security

International audienceWe present an analysis of key wrapping APIs with generic policies. We prove that certain minimal conditions on policies are sufficient for keys to be indistinguishable from random in any execution of an API. Our result captures a large class of API policies, including both the hierarchies on keys that are common in the scientific literature and the non-linear dependencies on keys used in PKCS#11. Indeed, we use our result to propose a secure refinement of PKCS#11, assuming that the attributes of keys are transmitted as authenticated associated data when wrapping and that there is an enforced separation between keys used for wrapping and keys used for other cryptographic purposes. We use the Computationally Complete Symbolic Attacker developed by Bana and Comon. This model enables us to obtain computational guarantees using a simple proof with a high degree of modularity

A Provably Secure PKCS#11 Configuration Without Authenticated Attributes

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