Language Based Covert Channel Avoidance

<p>Common protection mechanisms fail to provide end-to-end security; programs with legitimate access to secret information are not prevented from leaking this to the world by accident or malice. Protecting the access to information is not enough to solve this problem. We have to ensure that the program uses the information in a secure way.</p> <p>Work on information flow security often ignores information flows through covert channels even though they pose a serious threat. In the first paper we present a framework for timing-aware information-flow type systems for a low-level language similar to a non-trivial subset of a sequential Java bytecode. The framework is parametrised over a time model of the instructions of the language and over the algorithm enforcing low-observational equivalence, used in the prevention of implicit and timing flows. This gives us the possibility to easily experiment with different time models. We argue that this is important for two reasons:</p> <p>1) different applications may have different thresholds for what is an acceptable covert channel, and</p> <p>2) different implementations of the same language may contain different possibilities of covert channels.</p> <p>In the second paper we investigate a threat to practical information flow security: the failure to include the runtime environment of a language into consideration.</p> <p>It is important that the assumptions that are made in the study of the core language are honoured by the runtime system, in which inevitably every program will be run.</p> <p>In particular, the second paper studies one commonly made assumption in analyses of Java that may be broken by the runtime environment: that pointers are opaque -- i.e., that the only properties that can be observed of pointers are the objects to which they point, and (at most) their equality. These assumptions often fail in practise. For example, various important operations in Java's standard API, such as hashcodes or serialisation, might break pointer opacity. As a result, static information-flow analyses, which assume pointer opacity risk being unsound in practise, since the pointer representation provides an unchecked implicit leak --- a covert channel via the state of the memory allocator. We investigate information flow in the presence of non-opaque pointers for an imperative language with records, pointer instructions and exceptions, and develop an information flow aware type system which guarantees noninterference.