1 / 23

Language-Based Information-Flow Security

Language-Based Information-Flow Security. Richard Mancusi CSCI 297. References. Andrei Sabelfeld, Andrew C. Myers. Language-Based Information-Flow Security. IEEE Journal on Selected Areas in Communication, special issue on Formal Methods for Security, 21(1), January 2003, pages 5-19.

anana
Download Presentation

Language-Based Information-Flow Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Language-Based Information-Flow Security Richard Mancusi CSCI 297

  2. References Andrei Sabelfeld, Andrew C. Myers. Language-Based Information-Flow Security. IEEE Journal on Selected Areas in Communication, special issue on Formal Methods for Security, 21(1), January 2003, pages 5-19

  3. Information-Flow • “Access control checks place restrictions on the release of information but not its propagation.” • “Information controlled by a confidentiality policy cannot flow to a location where that policy is violated.” • “…practical methods for controlling information flow have eluded researchers for some time.”

  4. Symptoms of the Problem • SAIC Break-in Stresses Intertwined Nature of Physical and IT Security “A break-in at a government contractor's offices has opened 45,000 former and current employees and stockholders up to identity theft.” SecurityInfoWatch.com, Feb 22, 2005 • U.P.S. Loses A Shipment Of Citigroup Client Data “…box of computer tapes containing information on 3.9 million customers was lost on May 2 by United Parcel Service…” The New York Times, June 7, 2005 • Security Breach Could Expose 40M To Fraud, “…the security breach involves a computer virus that captured customer data…” The Washington Post, June 18, 2005

  5. Standard Security Methods • Computer systems have relied upon weak ad-hoc security mechanisms • Access control (i.e., file protections, ACL’s) • Firewalls • Antivirus software • “Access does not control how the data is used after it is read from the file”

  6. Terminology • Confinement “…the ability to prevent capabilities (and hence authority) from being transmitted improperly.” • Noninterference A clear separation of confidential data from public data.

  7. Covert Channels Signal mechanisms which are not intended to transfer information about a computing system Implicit flows Termination channels Power channels Timing channels Terminology

  8. Implicit flows result from the control structures of the program Problematic for security levels “Confidentiality can be obtained by by ensuring that the process sensitivity label remains high throughout the rest of the program.” H := H mod 2; L := 0; if ( H == 1 ) L := 1 Implicit Flows

  9. Semantics-Based Security For a given semantic model, noninterference is formalized as follows: C is secure iff Which reads: “If two input states share the same low values, then the behaviors of the program executed on these states are indistinguishable by the attacker.

  10. In Other Words… Indicates the absence of any dependency between the program values which operate within a higher security context and the program values which have a lower security context.

  11. Security-Type System • Mathematically, a language—typing rules–can be defined which encapsulates the security context of a program. • With a security-type system in place, static checks can be performed upon programs to identify any security issues.

  12. For Example:

  13. Research Trends • Expanding the expressiveness underlying the language. • Exploring security-related concurrency issues • Analyzing convert channels • Refining security policies

  14. Language-based Information Flow Research

  15. Language Expressiveness • Policies which use language constructs such as procedures and functions can guaranteed to noninterference within the parameters of specific security type systems. • Polymorphic concepts can be extended to a type system. This means that generic constructs can be created which depend upon the security context. Proveable.

  16. Language Expressiveness • Exceptions under normal circumstances can result in nonlocal transfer of control, creating implicit flows. Restrictive type systems are possible which limit the security concerns. [Volpano and Smith] • Systems have been created demonstrating Java objects can enforce noninterference.

  17. Concurrency • The higher security portions of the program must be protected at all times. (simple) Example: h := 0; l := h; With concurrency, values must be protected at all times. enter_critical(); h := 0; l := h; exit_critical()

  18. Concurrency • Thread security is tied to timing issues and probability. Example: (if h = 1 then C else skip); l := 1 || l := 0 Variations of security levels must be protected during context swaps (difficult)

  19. Covert Channels • Timing attacks against SSL encryption Encryption attacks are possible because the timing of failure with different values can lead an attacker to understand the true value of a key. Prevent attacks by equalizing the time for successful and failed decryption.

  20. Security Policies • Systems which allow downgrading of secure channels are subject to exploitation. • Example: Password-checking programs • The security is only as good as the algorithm which guards the passwords. • Concept of approximate noninterferance.

  21. Challenges • System-wide security • The integration of language flow and system-wide Information Flow control. • Certifying Compilation • Move security checking into Java arena, to perform static analysis on the byte code prior to execution.

  22. Challenges • Dynamic Policies • Not realistic to assume information-flow policies are available at compile time. • Runtime policies create an additional channel which needs protection. • Restrictions placed in languages to deal with the problems may become too restrictive for extensive use.

  23. Conclusions • End-to-end security is not capable with existing practices. • Static analysis of type systems are possible. • Something needs to be done with Jif compilers which support languages that are not “security-expressive” enough. • There is a lot of ongoing research to be concluded.

More Related