Certifying information flow properties of programs

Abstract

Interesting program properties other than func-

Semantics and Program Analysis of Computationally Secure Information Flow

“…There exists quite a large body of literature studying different instances of secure information flow, e.g., [3,4,5,7,10,11,12,13,14,15,16]. With the notable exception of [15,16], security is defined through noninterference, i.e., it is required that the public outputs of the program do not contain any information (in the information-theoretic sense) about the confidential inputs.…”

Assumptions and Guarantees for Compositional Noninterference

“…Information Flow Security for Concurrent Programs: To our knowledge, the first approach to information flow analysis for concurrent programs is proposed by Andrews and Reitman [7], [44]. It considers a flow logic that supports the derivation of noninterference proofs for programs.…”

“…Their work initiated a long line of research on noninterference-like properties, culminating in frameworks for comparing and engineering such security properties (see, e.g., [4], [5], [6]). Even earlier, Reitman and Andrews proposed an information flow analysis for concurrent programs [7], but they did not yet provide a soundness proof or precise claim about which security property their analysis enforces. These shortcomings were overcome 17 years later by Volpano and Smith [8].…”

“…Some approaches do not support a compositional analysis [7], [9], although compositionality is essential for making the analysis scale. The existing approaches either are overly restrictive or do not have satisfactory semantic foundations (e.g., [7], [10], [11]).…”

“…Some approaches do not support a compositional analysis [7], [9], although compositionality is essential for making the analysis scale. The existing approaches either are overly restrictive or do not have satisfactory semantic foundations (e.g., [7], [10], [11]). There are three main facets of the former deficiency: too conservative assumptions about the environment of the thread under analysis (e.g., [8], [12], [13], [14]), severe restrictions on the communication between threads (e.g., [15], [16], [17]), or assumptions about the run-time environment which do not match existing implementations (e.g., [18], [19]).…”