Calculated Secure Processes Michael J. Banks Jeremy L. Jacob York - - PowerPoint PPT Presentation

calculated secure processes
SMART_READER_LITE
LIVE PREVIEW

Calculated Secure Processes Michael J. Banks Jeremy L. Jacob York - - PowerPoint PPT Presentation

Calculated Secure Processes Michael J. Banks Jeremy L. Jacob York Doctoral Symposium 4 November 2010 Whats this talk about? Formal methods are used in software development when the behavioural correctness of systems is paramount.


slide-1
SLIDE 1

Calculated Secure Processes

Michael J. Banks Jeremy L. Jacob York Doctoral Symposium 4 November 2010

slide-2
SLIDE 2

What’s this talk about?

Formal methods are used in software development when the behavioural correctness of systems is paramount. Specification What properties should a system possess? Verification Does a system satisfy its specification? How can we use formal methods to construct secure software?

◮ Confidential (sensitive or valuable) information must be

protected from being disclosed to untrusted users

◮ We aim to guarantee information flow security

slide-3
SLIDE 3

Communicating Sequential Processes (CSP)

Background

CSP is a well-known process algebra for specifying systems:

◮ originally due to Hoare; revised by Hoare, Brooks, Roscoe ◮ a process interacts with environment by performing events ◮ process semantics given by a model (traces, failures, . . . )

CSP Notation

a → S engage in event ‘a’, then behave as process S S ⊓ T non-deterministic choice between S and T S ✷ T deterministic choice between S and T S ; T behave as S until it terminates, then behave as T

slide-4
SLIDE 4

Users, Observations and Information Flow

A motivational example

Consider the process specification: M (h → l → M) ⊓ (k → Stop) Suppose that:

◮ user Low can observe ‘l’ events only; ◮ Low has complete knowledge of M’s structure; and ◮ Low must be unable to establish if ‘h’ occurs

Question: is M secure?

slide-5
SLIDE 5

Users, Observations and Information Flow

A motivational example

Consider the process specification: M (h → l → M) ⊓ (k → Stop)

Question: is M secure?

If Low observes l, it can calculate that M’s trace must be in:

{h, l, h, l, h, h, l, k}

and so Low can infer that (at least one) ‘h’ must have occurred!

slide-6
SLIDE 6

The <P, Q> operator

We limit the flow of information to Low by inserting alternative “cover story” behaviours consistent with Low’s observations.

◮ Cover stories represent non-confidential behaviours ◮ Idea: If Low cannot rule out all cover stories, it cannot

establish that any confidential activity has taken place We write <P, Q>, where:

◮ P is a process specifying confidential behaviours ◮ Q is a process specifying cover story behaviours ◮ and Low must be unable to distinguish P from Q

slide-7
SLIDE 7

Applying <P, Q> to Processes

The semantics of <P, Q>(S) are defined by algebraic laws.

Law 3 (carry prefix; confidential not applicable)

provided P cannot perform an ‘a’ event:

<P, Q>(a → S) a → <P, Q>(S) Law 4 (extension by cover story)

provided S can behave as X:

<a → X, b → Y>(a → S)

  • a → <a → X, b → Y>(S)

b → Y ; <a → X, b → Y>(S “after” X)

slide-8
SLIDE 8

Securing M

Continuing the example

Low cannot deduce the occurrence of ‘h’ immediately before ‘l’: P h → l → Skip Q l → Skip Applying the algebraic laws, we calculate M′ = <P, Q>(M): M′ = <P, Q>((h → l → M) ⊓ (k → Stop))

=

  • h → l → M′ ✷ l → M′ ⊓ k → Stop

Is M′ secure?

If Low observes l, the trace of M′ must be a member of:

{h, l, h, l, h, h, l, k, l, l, k}

and Low can no longer infer that ‘h’ has occurred.

slide-9
SLIDE 9

Verifying Security

with respect to <P, Q>

Applying <P, Q> to a process S yields a secure process with respect to the confidentiality property encoded by P, Q.

Theorem

Given any Low-observation of <P, Q>(S), Low can never establish (with certainty) that a P activity has taken place.

Definition

S is secure (with respect to P, Q) provided <P, Q>(S) = S But adding cover stories may violate functional requirements.

slide-10
SLIDE 10

Related Work

Classical notion of information flow security is noninterference:

◮ Low can learn nothing about high-level user’s activities ◮ Often too strong for practical software development! ◮ Our notion of confidentiality is weaker than noninterference

We have not considered factors outside the model:

◮ probability of confidential behaviours, relative to cover stories ◮ timing of events ◮ power consumption

(We need a richer CSP semantic model to reason about these.)

slide-11
SLIDE 11

Conclusion

Contribution

◮ An operator for rewriting CSP processes to ensure they

satisfy confidentiality properties

◮ Encoding confidentiality properties via processes is original

Future work

◮ How can application of the operator be automated? ◮ Refinement reduces non-determinism within processes, but

doing so may introduce new sources of information flow!

slide-12
SLIDE 12
  • Finally. . .

Thanks for listening!

Slides and paper are available at: http://www-users.cs.york.ac.uk/~mbanks/