Toward a Taxonomy of Communications Security Models

1. Toward a Taxonomy of Communications Security Models PROOFS 2012 Leuven, Belgium Mark Brown RedPhone Security Saint Paul, MN USA mark@redphonesecurity.com

2. Introduction Outline • 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 (C) RedPhone Security 2012

3. Introduction Our Context and Project • 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 What are “security requirements”? (C) RedPhone Security 2012

4. Introduction Missing 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 (C) RedPhone Security 2012

5. Problem Our Challenge 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.) 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). (C) RedPhone Security 2012

6. Problem Meaningful Requirements (1) • 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…) (C) RedPhone Security 2012

7. Problem Meaningful Requirements (2) • 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. March 2011 Testimony to the House Armed Services Subcommittee on Tactical Air and Land Forces. Emphasis added, and names omitted. (C) RedPhone Security 2012

8. Problem Shall vs. Shall Never • 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” (C) RedPhone Security 2012

9. Solution What “Shall Never Be Computed” • 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 (C) RedPhone Security 2012

10. Solution System Taxonomy (1) (C) RedPhone Security 2012

11. Solution System Taxonomy (2) 8. Culture: Defines “valuable” and owns requirements (C) RedPhone Security 2012

12. Solution Benefits of this Solution • 0. Physics • Timed Logic (TC) • Algorithm (P) • Separation (NP) • Protocol (DY) • Subject (TT) • Resource (DB) • Cost / Efficiency • Culture 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 (C) RedPhone Security 2012

13. Why “Taxonomy”? 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) Solution • 0. Physics • Timed Logic (TC) • Algorithm (P) • Separation (NP) • Protocol (DY) • Subject (TT) • Resource (DB) • Cost / Efficiency • Culture Sep 13, 2012 (C) RedPhone Security 2012 13

14. Solution Prior Work (short list) • 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… (C) RedPhone Security 2012

15. Solution How to Use this 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 (C) RedPhone Security 2012

16. Examples Examples An AES Example How to break a “Universally Valid” secure system,(Why axioms are really just assumptions) Typical Assumptions, in Taxonomy Sep 13, 2012 (C) RedPhone Security 2012 16

17. AES (1) Examples • 0. Physics • Timed Logic (TC) • Algorithm (P) • Separation (NP) • Protocol (DY) • Subject (TT) • Resource (DB) • Cost / Efficiency • 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 Sep 13, 2012 (C) RedPhone Security 2012 17

18. AES (2) 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) Examples • 0. Physics • Timed Logic (TC) • Algorithm (P) • Separation (NP) • Protocol (DY) • Subject (TT) • Resource (DB) • Cost / Efficiency • Culture Sep 13, 2012 (C) RedPhone Security 2012 18

19. Examples A Little Play on Peano (1) Really? How could an attacker break a math axiom? (C) RedPhone Security 2012

20. A Little Play on Peano (2) Examples • Identity Constants • Every 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 – Multiplication • Reflexivity (Memory) When an attacker alters state, reflexivity fails • Associativity / Commutivity / TransitivityWhen an attacker alters state, equality inferences do not hold • ClosureAn attacker may inject a buffer overflow, or benefit from undetected overflow and wrapping conditions • Successor functionMemory addresses arithmetic typically is not closed under succession Sep 13, 2012 (C) RedPhone Security 2012 20

21. Examples Peano Axioms Cannot Be Silenced (3) • 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 (C) RedPhone Security 2012

22. Examples Taxonomized Assumptions There could not be any… Which ones are you making? • 0. PhysicsDevice theft, fault injection, reverse engineering, FIB, laser cutter • Timed Logic (TC)Power attacks, hybrid attacks, memory/value observation and alteration • Algorithm (P)Refinement errors, out-of-spec inputs, state corruption • Separation (NP)Cryptanalyticweakness, key entropy or key property failures • Protocol (DY)Protocol weakness, man-in-middle, replay, • Subject (TT)Malicious users, non-human / automated users • Resource (DB)Inaccuracies, deceit, impersonation, social engineering • Cost / EfficiencyWasteful use, injected components, maliciously bogus message, flooding attempt • CultureInjustice, unfairness / inequality, bad law, faulty process of law or enforcement (C) RedPhone Security 2012

23. 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

24. Toward a Taxonomy of Communications Security Models THANK YOU! Mark Brown RedPhone Security Saint Paul, MN USA mark@redphonesecurity.com