Dennis M. Volpano

A sound type system for secure flow analysis

Ensuring secure information flow within programs in the context of multiple sensitivity levels has been widely studied. Especially noteworthy is Denning’s work in secure flow analysis and the lattice model [6][7]. Until now, however, the soundness of Denning’s analysis has not been established satisfactorily. We formulate Denning’s approach as a type system and present a notion of soundness for the system that can be viewed as a form of noninterference. Soundness is established by proving, with respect to a standard programming language semantics, that all well-typed programs have this noninterference property.

Secure information flow in a multi-threaded imperative language

Previously, we developed a type system to ensure secure information flow in a sequential, imperative programming language [VSI96]. Program variables are classified as either high or low security; intuitively, we wish to prevent information from flowing from high variables to low variables. Here, we extend the analysis to deal with a multithreaded language. We show that the previous type system is insufficient to ensure a desirable security property called noninterference. Noninterference basically means that the final values of low variables are independent of the initial values of high variables. By modifying the sequential type system, we are able to guarantee noninterference for concurrent programs. Crucial to this result, however, is the use of purely nondeterministic thread scheduling. Since implementing such scheduling is problematic, we also show how a more restrictive type system can guarantee noninterference, given a more deterministic (and easily implementable) scheduling policy, such as round-robin time slicing. Finally, we consider the consequences of adding a clock to the language.

A Type-Based Approach to Program Security

This paper presents a type system which guarantees that well-typed programs in a procedural programming language satisfy a noninterference security property. With all program inputs and outputs classified at various security levels, the property basically states that a program output, classified at some level, can never change as a result of modifying only inputs classified at higher levels. Intuitively, this means the program does not “leak” sensitive data. The property is similar to a notion introduced years ago by Goguen and Meseguer to model security in multi-level computer systems [7]. We also give an algorithm for inferring and simplifying principal types, which document the security requirements of programs.

Probabilistic noninterference in a concurrent language

The authors previously give a type system that guarantees that well-typed multi-threaded programs are possibilistically noninterfering. If thread scheduling is probabilistic, however, then well-typed programs may have probabilistic timing channels. They describe how they can be eliminated without making the type system more restrictive. They show that well-typed concurrent programs are probabilistically noninterfering if every total command with a high guard executes atomically. The proof uses the concept of a probabilistic state of a computation, following the work of Kozen (1981).

Eliminating covert flows with minimum typings

A type system is given that eliminates two kinds of covert flows in an imperative programming language. The first kind arises from nontermination and the other from partial operations that can raise exceptions. The key idea is to limit the source of nontermination in the language to constructs with minimum typings, and to evaluate partial operations within expressions of try commands which also have minimum typings. A mutual progress theorem is proved that basically states that no two executions of a well-typed program can be distinguished on the basis of nontermination versus abnormal termination due to a partial operation. The proof uses a new style of programming language semantics which we call a natural transition semantics.

Verifying secrets and relative secrecy

Systems that authenticate a user based on a shared secret (such as a password or PIN) normally allow anyone to query whether the secret is a given value. For example, an ATM machine allows one to ask whether a string is the secret PIN of a (lost or stolen) ATM card. Yet such queries are prohibited in any model whose programs satisfy an information-flow property like Noninterference. But there is complexity-based justification for allowing these queries. A type system is given that provides the access control needed to prove that no well-typed program can leak secrets in polynomial time, or even leak them with nonnegligible probability if secrets are of sufficient length and randomly chosen. However, there are well-typed deterministic programs in a synchronous concurrent model capable of leaking secrets in linear time.

Safety versus Secrecy

Safety and secrecy are formulated for a deterministic programming language. A safety property is defined as a set of program traces and secrecy is defined as a binary relation on traces, characterizing a form of Noninterference. Safety properties may have sound and complete execution monitors whereas secrecy has no such monitor.

Secure introduction of one-way functions

Conditions are given under which a one-way function can be used safely in a programming language. The security proof involves showing that secrets cannot be leaked easily by any program meeting the conditions unless breaking the one-way function is easy. The result is applied to a password system where passwords are stored in a public file as images under a one-way function.

Language Issues in Mobile Program Security

Many programming languages have been developed and implemented for mobile code environments. They are typically quite expressive. But while security is an important aspect of any mobile code technology, it is often treated after the fundamental design is complete, in ad hoc ways. In the end, it is unclear what security guarantees can be made for the system. We argue that mobile programming languages should be designed around certain security properties that hold for all well-formed programs. This requires a better understanding of the relationship between programming language design and security. Appropriate security properties must be identified. Some of these properties and related issues are explored.

On the Complexity of ML Typability with Overloading

We examine the complexity of type checking in an ML-style type system that permits functions to be overloaded with different types. In particular, we consider the extension of the ML type system proposed by Wadler and Blott in the appendix of [WB89], with global overloading only, that is, where the only overloading is that which exists in an initial type assumption set; no local overloading via over and inst expressions is allowed. It is shown that under a correct notion of well-typed terms, the problem of determining whether a term is well typed with respect to an assumption set in this system is undecidable. We then investigate limiting recursion in assumption sets, the source of the undecidability. Barring mutual recursion is considered, but this proves too weak, for the problem remains undecidable. Then we consider a limited form of recursion called parametric recursion. We show that although the problem becomes decidable under parametric recursion, it appears harder than conventional ML typability, which is complete for DEXPTIME [Mai90].