toward a taxonomy of communications security models

Toward a Taxonomy of Communications Security Models

PROOFS 2012Leuven, Belgium

Mark BrownRedPhone SecuritySaint Paul, MN [email protected]

mailto:[email protected]

• Introduction• What are security requirements?

• Problem• What organization of requirements

can prevent surprises?

• Solution• Our idea “toward” organizing the

subject matter

• Examples• AES Example• Analyzing Axioms and Assumptions

Outline

Introduction

Sep 13, 2012 (C) RedPhone Security 2012 2

• This research sponsored by Joint Tactical Radio System (JTRS)• $6BB R&D spend over 15 year lifetime• Performers include: DoD, Primes, Security contractors, NSA, etc.

• MLS Remote Administration Project• Secure the multi-level operation of the JTRS radiosets (MLS)• Allow for “system high” remote administration• Implement “on a chip”:

• SSL/TLS protocol • Suite B cryptography• Classic MLS flows

• We identified an absence of security requirements


Our Context and Project

Introduction

What are “security requirements”?

General Requirements Existed• Thousands of pages of requirements and specifications• Criticized by US Government Accounting Office • Included lists of things developers must do and not do

We found no clear specification of “What must the system do in order to be secure?”

We took up the task of “security requirements”• Describing the system and its security in plain language• Identifying assumptions• Documenting “shall nevers”• Modeling the system and its attackers• Finding proofs• Deliver not merely our judgment of “it’s secure” but

assurance


Missing Security Requirements

Introduction

What subject matter is included in “security requirements”• How shall it be organized? • What system / layer boundaries and granularity?

(Littlewood, et al. 1993)• How to deal with assumptions?

What formal model(s) can assure a secure system?Really? Consider:• Covert channels (multi-level secure)• Side channels (cryptographic cores)• Untrusted toolchain, fabrication, distribution

(refinement)• Classical concerns (bypass, subversion, reverse

engineering, assurance of “no backdoors”, etc.)


Our Challenge

Problem

Hard cases: full attack code is not present at time of evaluation, but emerges operationally (when the system is used in a particularly bad way).

• Our first topic is operational requirements. “All of the systems met or came close to meeting most of their documented requirements,” Mike began. Actually, the program office designed the systems to the specifications it was given and was largely successful in doing so. “Yet,” he continued, “in operational testing, these systems demonstrated little useful military capability.”

• In operational test and evaluation, our focus is necessarily on answering the question: “Is a unit’s ability to accomplish its mission improved when equipped with a system?” and much less so on answering the question: “Does this system meet its system specifications?” In this case, the systems under test contributed little to improve mission accomplishment.

(continued…)Sep 13, 2012 (C) RedPhone Security 2012 6

Meaningful Requirements (1)

Problem

• I attribute this lack of demonstrated military utility in large measure to the established system requirements and specifications not being descriptive of a meaningful and useful operational capability. In my view, the system requirements document did not sufficiently link its largely technical specifications to desired operational outcomes. The requirements and specifications were necessary, but well short of sufficient, to assure military utility.

• This situation is not unique to this program. Program requirements must be operational in nature and clearly linked to a useful and measurable operational capability. Contract specifications must be both necessary and sufficient to assure operational effectiveness in combat.


Meaningful Requirements (2)

Problem

March 2011 Testimony to the House Armed Services Subcommittee on Tactical Air and Land Forces. Emphasis added, and names omitted.

• Security asserts what cannot be (nonexistence)– Cannot be done, accomplished, known, …– Granted a context in which the secured acts might otherwise

occur…– Granted the correct functioning of a system– So, security models typically assume “No Other Changes”

• Security-assertions…– Take the form “shall never”– Concern survival or basic enterprise functioning– Include: secrecy, integrity, availability, authenticity, authorization,

audit, and assurance– Argue for the priority of some concern over other concerns

(Waever)– Involve cost-risk “tradeoffs” (Schneier)

• System-assertions take the form “shall”


Shall vs. Shall Never

Problem

• Need to bound “totality,” “attacker” and “feasible”• Of course we cannot disable the laws of Physics for our devices• Cryptography relies upon P vs. NP to describe

what cannot be computed (or guessed)• The “shall nevers” seem also to be related to

what cannot happen, even when forced / brute-forced

• Idea: Turing’s dissertation explores what cannot be computed (Entscheidungsproblem)• Turing’s “oracle” supplies true/false answers• Turing Degrees are hierarchical

Can we identify security oracles that “cannot be computed”? These will determine the organization of our security requirements


What “Shall Never Be Computed”

Solution


System Taxonomy (1)

Solution


System Taxonomy (2)

Solution

8. Culture: Defines “valuable” and owns requirements

Taxonomy supports several analyses• Shalls located within each Epoch arise from one

science• Shall-nevers for any Epoch may be restated as

safety properties on the higher Epoch(s)• Epochs circumscribe a maximum attack surface

and allow better attack analysis of information flow across Epochs

Taxonomy gives a place for every requirement• Simplifies literature search to one science or

discipline• Helps detect omitted requirements

(Every assertion/assumption has meaningful context)

• “Brackets” expectations of what the data should mean


Benefits of this Solution

Solution

0. Physics

1. Timed Logic (TC)

2. Algorithm (P)

3. Separation (NP)

4. Protocol (DY)

5. Subject (TT)

6. Resource (DB)

7. Cost / Efficiency

8. Culture

You Build the Zoo, We Give Taxonomy• Originating new math theorems remains a

human endeavor, as does originating:• Algorithms• Optimizations• Computing architectures• Logic computation technologies, e.g.

semiconductive, optical, quantum• Composing systems remains an engineering

task for humans• Selecting optimal subspecies• Composing algorithms• Designing the environment (habitat)


Why “Taxonomy”?

Solution

0. Physics

1. Timed Logic (TC)

2. Algorithm (P)

3. Separation (NP)

4. Protocol (DY)

5. Subject (TT)

6. Resource (DB)


8. Culture

• NOT: a list of security do’s and don’t’s (TCSEC, CC, …)

• Organizes assertions and assumptions (Landwehr)• Provides hierarchical levels of granularity

• Addresses Rushby’s “low levels” of granularity• Addresses Payne et al.’s “comprehensive” levels of

requirements scope• Can convey shall’s and shall-never’s (Littlewood et al.)

• We want to speak about behavior that cannot occur• Identifies a wider range of security disciplines

• From cultural givens (8) to physical environment (0)• Expressive over Laprie et al.’s taxonomy of faults

• Many more references provided in full paper…


Prior Work (short list)

Solution

• Start with a Formal Model• Survey the literature, find a mission and sponsor• Populate all Epochs 1-7 with your system components• Develop components and models of system Epochs• Wrap each Epoch’s model with an appropriate Attacker

• Analyze each Epoch, e.g.:• (above) Covert channel analysis, including boundary

questions• (below) Refinement problems, including subversion &

bypass• (within) Correctness, side channels, redundancy,

certification• Find proofs

• Add assumptions (may become assertions) as needed• Eliminate assumptions except on E0 and E8


How to Use this Solution

Solution


Examples

Examples

1. An AES Example2. How to break a “Universally Valid” secure system,

(Why axioms are really just assumptions)3. Typical Assumptions, in Taxonomy


AES (1)

Examples

0. Physics

1. Timed Logic (TC)

2. Algorithm (P)

3. Separation (NP)

4. Protocol (DY)

5. Subject (TT)

6. Resource (DB)


8. Culture

AES – E3•aes( pt, key): ct

•pt from E4,5,6•key from E4•ct to E2,1,0

•Asserts: •aes in NP (cryptanalysis)•refinement (correct, optimized)•round counter state•pt, key, ct safety properties

•Assumes: E0,1,2, and E4,5,6,7,8

Composing cryptographic primitives (E3) into a session-based protocol (E4) can reduce the practicality of side channel attacks. Why?– Allows anonymous attackers?

(E4/5 mutual authentication protocol )– Which parties can authenticate?

(E5/6 oracle can eliminate most attackers)

– Which parties should access specific high value information? (E6/7 eliminates spurious communications)


AES (2)

Examples

0. Physics

1. Timed Logic (TC)

2. Algorithm (P)

3. Separation (NP)

4. Protocol (DY)

5. Subject (TT)

6. Resource (DB)


8. Culture


A Little Play on Peano (1)

Examples

Really? How could an attacker break a math axiom?


A Little Play on Peano (2)

Examples

1. Identity ConstantsEvery group (algebraic structure) operation can be eliminated

when one input is set to the identity value. An Attacker may cut a wire, inject a fault, overwrite a constant, or omit a zeroization step.

• 0 – Addition, XOR, Subtraction / 1 – Multiplication2. Reflexivity (Memory)

When an attacker alters state, reflexivity fails3. Associativity / Commutivity / Transitivity

When an attacker alters state, equality inferences do not hold4. Closure

An attacker may inject a buffer overflow, or benefit from undetected overflow and wrapping conditions

5. Successor function Memory addresses arithmetic typically is not closed under succession

• Our theorem prover (PVS) could not envision corrupted state in our system• Naïve models do not change “the wrong” state location• Naïve models generate no malicious writes (wrong value)

• Attacks are generally excluded from models• Reflexivity equality (a = a) holds against fault injections,

etc• Symmetric equality (a=b b=a) holds against protocol

replay attacks and man-in-the-middle attacks• Transitive equality (a=b, b=c a=c) holds against broken,

bypassed, cut or fault-injected comparator hardware

• So we used wrappers to express attackers’ capability


Peano Axioms Cannot Be Silenced (3)

Examples


Taxonomized Assumptions

Examples

0. PhysicsDevice theft, fault injection, reverse engineering, FIB, laser cutter

1. Timed Logic (TC)Power attacks, hybrid attacks, memory/value observation and alteration

2. Algorithm (P)Refinement errors, out-of-spec inputs, state corruption

3. Separation (NP)Cryptanalyticweakness, key entropy or key property failures

4. Protocol (DY)Protocol weakness, man-in-middle, replay,

5. Subject (TT) Malicious users, non-human / automated users

6. Resource (DB) Inaccuracies, deceit, impersonation, social engineering

7. Cost / Efficiency Wasteful use, injected components, maliciously bogus message, flooding attempt

8. CultureInjustice, unfairness / inequality, bad law, faulty process of law or enforcement

There could not be any…Which ones are you making?

Summary• Requirements can be operationalized either as

assumptions or as assertions• Attackers break assumptions• Engineers make assertions

• for a system• within an Epoch

• We must organize requirements to discover our hidden assumptions (Husserl’s epoche)

• This work proposes a taxonomy for modeling secure communications systems

Toward a Taxonomy of Communications Security Models

THANK YOU!

Mark BrownRedPhone SecuritySaint Paul, MN [email protected]

mailto:[email protected]

toward a taxonomy of communications security models

Documents