Cryptographically Secure Information Flow Control on Key-Value Stores

Waye, Lucas; Buiras, Pablo; Arden, Owen; Russo, Alejandro; Chong, Stephen

doi:10.1145/3133956.3134036

Cited by 8 publications

(8 citation statements)

References 50 publications

(62 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There is a significant body of work on embedding IFC in Haskell [3,17,22,27,38,41,43,48,[50][51][52]. Most of which falls into the category of "monadic" IFC libraries in which the code that is subject to IFC enforcement is written using a specialized interface exported by the library.…”

Section: Implementations Of Ifc In Haskellmentioning

confidence: 99%

Multi-Execution Lattices Fast and Slow

Algehed¹,

Flanagan²

2021

Preprint

View full text Add to dashboard Cite

Methods for automatically, soundly, and precisely guaranteeing the noninterference security policy are predominantly based on multi-execution. All other methods are either based on undecidable theorem proving or suffer from false alarms. The multi-execution mechanisms, meanwhile, work by isolating security levels during program execution and running multiple copies of the target program, once for each security level with carefully tailored inputs that ensure both soundness and precision. When security levels are hierarchically organised in a lattice, this may lead to an exponential number of executions of the target program as the number of possible ways of combining security levels grows. In this paper we study how the lattice structure for security levels influences the runtime overhead of multi-execution. We additionally show how to use Galois connections to gain speedups in multi-execution by switching from lattices with high overhead to lattices with low overhead. Additionally, we give an empirical evaluation that corroborates our analysis and shows how Galois connections have potential to speed up multi-execution. REVIEW OF THE MULTI-EXECUTION FRAMEWORKA (join semi-)lattice L is a set L with a transitive, reflexive, and antisymmetric order ⊑ that has a least element ⊥ and is such that any two elements ℓ, ∈ L have a least upper bound ℓ ⊔ ∈ L. For a finite subset ⊆ L we write for the least upper bound of all elements in . For example, the two-point lattice has L = {L, H}, L denotes public information and H denotes secret information. Public information can flow to secret information so ⊑ is the smallest reflexive relation such that L ⊑ H. Finally, this means that L ⊔ L = L and ℓ ⊔ = H if either ℓ or is H.Following Algehed and Flanagan [2] we consider batch-job programs from labeled sets to labeled sets and let , , range over partial recursive functions from P ( × L) to P ( × L) for some set of inputs and outputs . This is a convenient formalism, as it allows us to succinctly state the core definitions that allow us to reason about multi-execution. The following definitions (from [2]) are sufficient to precisely define Noninterference.Definition 2.1. Assume ℓ ∈ L and , ⊆ × L for some , define the projection of at ℓ as (we write the pair ( , ) as ):We say that and are ℓ-equivalent, meaning they look the same to an observer at level ℓ, written ∼ ℓ , if and only if their ℓprojections are the same:The projection ↓ ℓ of at ℓ is precisely all the information in that is visible to ℓ. Likewise, this means that if two sets and look the same to ℓ, then they are ℓ-equivalent. The definition of noninterference meanwhile is that is noninterfering if it does not reveal more about its inputs than what one can know by looking at the input. In other words, if two inputs and differ only in values that are secret to an observer at level ℓ, they are ℓ-equivalent, then ( ) and ( ) should also be ℓ-equivalent.Definition 2.2 (Noninterference). We say that program : P ( × L) → P ( × L) is noninterfering if it preserves ℓ-equivalence....

show abstract

Section: Implementations Of Ifc In Haskellmentioning

confidence: 99%

Multi-Execution Lattices Fast and Slow

Algehed¹,

Flanagan²

2021

Preprint

View full text Add to dashboard Cite

show abstract

“…LIO's current label and clearance label draw inspiration from work on Mandatory Access Control (MAC) operating systems [Bell and LaPadula 1973], including Asbestos [Efstathopoulos et al 2005], HiStar [Zeldovich et al 2006], and Flume [Krohn et al 2007]. The baseline LIO approach has been extended in several interesting ways [Buiras et al , 2015Russo 2015;Waye et al 2017], including to other languages [Heule et al 2015].…”

Section: Related Workmentioning

confidence: 99%

LWeb: information flow security for multi-tier web applications

Parker

Vazou

Hicks

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

This paper presents LWeb, a framework for enforcing label-based, information flow policies in database-using web applications. In a nutshell, LWeb marries the LIO Haskell IFC enforcement library with the Yesod web programming framework. The implementation has two parts. First, we extract the core of LIO into a monad transformer (LMonad) and then apply it to Yesod's core monad. Second, we extend Yesod's table definition DSL and query functionality to permit defining and enforcing label-based policies on tables and enforcing them during query processing. LWeb's policy language is expressive, permitting dynamic per-table and per-row policies. We formalize the essence of LWeb in the λ LWeb calculus and mechanize the proof of noninterference in Liquid Haskell. This mechanization constitutes the first metatheoretic proof carried out in Liquid Haskell. We also used LWeb to build a substantial web site hosting the Build it, Break it, Fix it security-oriented programming contest. The site involves 40 data tables and sophisticated policies. Compared to manually checking security policies, LWeb imposes a modest runtime overhead of between 2% to 21%. It reduces the trusted code base from the whole application to just 1% of the application code, and 21% of the code overall (when counting LWeb too).A promising solution to these problems is embodied in the LIO system for Haskell. LIO is a drop-in replacement for the Haskell IO monad, extending IO with an internal current label and clearance label. Such labels are lattice ordered (as is typical [Denning 1976]), with the degenerate case being a secret (high) label and public (low) one. LIO's current label constitutes the least upper bound of the security labels of all values read during the current computation. Effectful operations such as reading/writing from stable storage, or communicating with other processes, are checked against the current label. If the operation's security label (e.g., that on a channel being written to) is lower than the current label, then the operation is rejected as potentially insecure. The clearance serves as an upper bound that the current label may never cross, even prior to performing any I/O, so as to reduce the chance of side channels. Haskell's clear, type-enforced separation of pure computation from effects makes LIO easy to implement soundly and efficiently, compared to other dynamic enforcement mechanisms. This paper presents LWeb, an extension to LIO that aims to bring its benefits to Haskell-based web applications. This paper presents the three main contributions of our work.First, we present an extension to a core LIO formalism with support for database transactions. Each table has a label that protects its length. In our implementation we use DC labels , which have both confidentiality and integrity components. The confidentiality component of the table label controls who can query it (as the result may reveal something about the table's length), and the integrity component controls who can add or delete rows (since both may change the ...

show abstract

“…Defensive mechanisms are proposed to protect private data from leakage including cryptography methods [38], access control [33] and information flow control [35] [15] [55]. Cryptography approaches provide a secure way to prevent the eavesdropping attack by encrypting the sensitive data, but the misuse and extra overhead limit their reliability and practicality [143]. Access control based permission framework is an effective mechanism on limiting third-party app's access to sensitive data.…”

Section: Introductionmentioning

confidence: 99%

Information flow based defensive chain for data leakage detection and prevention: a survey

Xi,

Chen,

Zhang

et al. 2021

Preprint

View full text Add to dashboard Cite

Mobile and IoT applications have greatly enriched our daily life by providing convenient and intelligent services. However, these smart applications have been a prime target of adversaries for stealing sensitive data. It poses a crucial threat to users' identity security, financial security, or even life security. Research communities and industries have proposed many Information Flow Control (IFC) techniques for data leakage detection and prevention, including secure modeling, type system, static analysis, dynamic analysis, etc. According to the application's development life cycle, although most attacks are conducted during the application's execution phase, data leakage vulnerabilities have been introduced since the design phase. With a focus on lifecycle protection, this survey reviews the recent representative works adopted in different phases. We propose an information flow based defensive chain, which provides a new framework to systematically understand various IFC techniques for data leakage detection and prevention in Mobile and IoT applications. In line with the phases of the application life cycle, each reviewed work is comprehensively studied in terms of technique, performance, and limitation. Research challenges and future directions are also pointed out by consideration of the integrity of the defensive chain. CCS Concepts: • Security and privacy → Software security engineering; Logic and verification; Information flow control;• Software and its engineering → Software development process management.

show abstract

Cryptographically Secure Information Flow Control on Key-Value Stores

Cited by 8 publications

References 50 publications

Multi-Execution Lattices Fast and Slow

Multi-Execution Lattices Fast and Slow

LWeb: information flow security for multi-tier web applications

Information flow based defensive chain for data leakage detection and prevention: a survey

Contact Info

Product

Resources

About