Building Zero Trust Computing Applications Using RAET Samuel M. Smith Ph.D.

Founder ProSapien sam@prosapien.com OpenWest 2017 Thursday July 13 Session 10:30 a.m. Room 300 C

Shameless Plug Al - Automated Reasoning Distributed Consensus - Blockchain Reputation - Identity 110T - Ephemeral Edge Computing @ProSopien T =N 000 g x A dr s ()= S §i P e o m = mo Lk S fasllod §cE

pr s “‘,:,, o —-r.”' B == S i ‘Y!‘‘’‘ - L‘“,( ) ‘ - " e B+ |\ 3 N3 F ey (* ; -\ EF . RS Ll Bl . - S be i B e

“ 2] : Zero” Trust Computing? No such thing as zero trust Really its diffuse trust zero trust term used in 2013NIST report Diffuse trust perimeter-less security NIST: Developing a Framework to Improve Critical Infrastructure Cybersecurity 04/08/2013 Zero Trust Model for Information Security, Forrester Research. http:/jcsr.nist.govicyberframework/rfi_comments/o40813_forrester_research.pdf ‘httpsilfwww.nist.govicyberframework Zero Trust Networks 2017 Gilman & Barth https:/fwww.amazon.com/Zero-Trust-Networks-Building-Untrusted/dp/1491962194/ref=sr_1_1? s=books&ie=UTF8&qid=1499871379&sr=t-1&keywords=zero+trust+networks

Cellular distributed topology. 5 ,g*‘{-'\gn‘, P 7 N 6 “Think clandestine spy ring or resistance organization” &< ! ‘ ,?, % fi!@“ bt . . . . o ‘§ o il 551 Defeating each node requires an independent exploit. Wi 8 !f o gl L e

Caveats. i

No single point of failure - “Universal root privileges"

No common mode failures — “Exploit to attain root privileges” Vs The system is trustworthy as long as some majority of nodes are not exploited. Distributed consensus is the key to achieving diffuse trust \@ Peer cooperation versus hierarchical control f

Diffuse Trust , Cellular distributed topology. P ’*fl'\"" “Think clandestine spy ring or resistance organization” ‘\~A l?( gw‘,‘% Defeating each node requires an independent exploit. %f«fi/)@/) Caveats. w No single point of failure - “Universal root privileges" No common mode failures — “Exploit to attain root privileges” vs The system is trustworthy as long as some majority of nodes are not @ exploited. Distributed consensus is the key to achieving diffuse trust \g Peer cooperation versus hierarchical control f)(' f IS

Distributed Consensus Enables diffuse trust systems using de-centralized computing infrastructure Allows secure infrastructure outside a firewall by distributing the attack surface. Enables the replacement of strongly controlled computing infrastructure with weakly controlled computing infrastructure that may be more secure. Enables computation in the “fog” vs computation in the “cloud”. Enables new disruptive business models

Distributed Consensus Types Proof of Work: Simple, highly inefficient, high latency, low throughput Proof of Stake: More complex, more efficient, lower latency, higher throughput (Asymmetric Proof of Work) Byzantine Agreement: Most complex, most efficient, lowest latency, highest throughput. (Byzantine Fault Tolerant) Hybrid: Side chains, anchoring,

Zero Trust Computing Security, Privacy, Agency Diffuse trust perimeter-less security model

Diffuse trust perimeter-less security principles The network is always hostile, internally & externally; Locality is not trustworthy. Every network interaction or data flow must be authenticated and authorized using best practice cryptography. Inter-host communication must be end-to-end signed/encrypted and data must be stored signed/encrypted; Data is signed/encrypted in motion and at rest. Policies for authentication and authorization must be dynamically modified based on behavior. Policies must be governed by distributed consensus.

DJB NacCL Cipher Suite Best of breed Crypto Library is NaCl. Designed by Daniel J. Bernstein, http://nacl.cr.yp.to LibSodium: https://www.gitbook.com/book/jedisct1/libsodium/details Python: LibNacl: https://github.com/saltstack/libnacl Ed25519 (EdDSA) Signatures Curve25519 (X25519) Diffie-Hellman Key Exchange XSalsa20/20 Stream Cipher Encryption poly1305 Message Authentication Code CurveCP Protocol https://curvecp.org

NaCL: One True Cipher Suite lan Grigg: *In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work... Picking curve25519 xsalsa20 poly 1305 is good enough for that One True CipherSuite motive alone... it's an innovation! Adopt it Matthew Green: "Any potential ‘up my sleeve' number should be looked at with derision and thoroughly examined (Schneier thinks that the suggested NIST ECC curves are probably compromised by NSA using 'up my sleeve’ constants). This is why I think we all should embrace DJB's Curve25519." WOIfSSL: *Curve25519 so far is destroying the key agreement and generation benchmarks of previous curves, putting up numbers for both key agreement and generation that are on average 86 percent faster than those of NIST curves.” Adam Langley: *Of the concrete implementations of Diffie-Hellman, curve25519 is the fastest, common one.” Dan Bernstein: "An attacker who spends a billion dollars on special-purpose chips to attack Curve25519, using the best attacks available today, has about 1 chance in 1,000,000,000,000,000,000,000,000,000 (27 0s) of breaking Curve25519 after a year of computation.”

Modern Crypto: Elliptic Curves y'=x*+ax+b modp R=P+Q R=P+P=2P . ‘ e —t i T Yo 3 A

Modern Crypto: ECC Diffie-Hellman Key Exchange Given elliptic curve polynomial coefficients a, b, mod prime Alice and Bob exchange public keys A and 8. p and, generator point G on curve. Alice generates shared secret key S, point on curve, from (Public, private) key pair (K, k) where K =kG, Alice’s private key a and Bob’s public key B. kis random number, means ECC scalar multiplication by adding G, k times S=aB=abG scalar multiplication is commutative Kis another point on the curve Bob generates shared secret key S, point on curve, from Bob’s private key b and Alice’s public key A. Alice picks private key , random number, and generates public key A, point on curve. A =aG S=bA=baG Bob pick private key b, random number, and generates S =baG =abG public key B, point on curve. B = bG Now S can be used as source of shared secret to encrypt/ decrypt messages between Alice and Bob.

RAET Reliable Asynchronous Event Transport https://github.com/RaetProtocol/raet End-to-End Encryption and Signing with: NaCl, X22519, CurveCP Handshake, Curve22519, Salsa20/20 Poly1305 Python with LibNacl, loflo UDP for interhost communication Unix domain sockets for interprocess communications Presence Support Truly asynchronous architecture with non-blocking 1/0 Peer-to-peer bidirectional Curve-CP handshake

Curve-CP Handshake Confidentiality against espionage Integrity against corruption and forgery Some availability against sabotage Server authentication Client authentication Replay attack protection Man-in-the-middle attack protection Passive forward secrecy Active forward secrecy

RAET Metaphor W

RAET Transactions

Join: Exchange long term public keys both signing and encryption.

Configurable to be compatible with multi-factor authentication Allow: Curve-CP handshake

exchange short term ephemeral encryption keys (diffie-hellman) Message: Exchange messages

Header is compact text, JSON, or Msgpack

Body is raw, JSON, or Msgpack

Max message size up to 67,107,840 bytes

Message bodies are encrypted

Heady + Body are signed Alive: Presence heartbeat

RAET Key & Channel Management Pend, Accept, Reject Name, Role, Mode Mutability

Many-to-many Many-to-many-to-many T [ o /- > = - [ /7N Wote ), [ Node |, / VR - \ [ @) I M C(C B [ — / PR . T < e (. / 7 ) E3— =) () NS T T v 71 b i we| N/ [ oae i\ \ e, | S Host Vi \ Host \b\;::;,;, "' 4 N Node Node 4,/ T —— T Host [ Host [T N . Logically concurrent flows of execution Performance and Reliability Concurre.nt data flows Service flows

Asynchronous Optimized Computation Coroutines are the fundamental units of logically concurrent computation Host CPUVM Core Core Core Core Minimizes context switch overhead

Host PUNM Process T —— Process poca |, XU ] pcr f (Y protol [ sl fo—— schedler su | N Por ) sk Stack Tlow Stk Tlow J ) A ) pouer = e 4 S e - VAR AR\ VRN VAR A\ / / (o) v y A X \ SN D . .

Ve Y|l e Wers Y|l 6.8 Wes Fas)

Enables coroutine-to-coroutine communication both intra-process, inter-process and inter-host

Tuple: (datashare name, UXD name, UDP name, channel name) JSON: { "route": { "sre": [“"peter.piper.picked", "pepper", "peck", "garden"], "dst": ["suzy.sand.sell”, "shell”, "shore", "sea"] } "tag": "commerce.hot", "stamp": "20170125T13:45:62.340123UTC", "data": { “quantity”: 5, “price”: 1.50 } ¥

https://github.com/RaetProtocol/raet Peer-to-peer exchange of long term keys with multiple levels of control over how the exchange occurs. Peer-to-peer implementation of the CurveCP handshake that allows for either side of a pair of hosts to initiate the handshake and resolves simultaneous CurveGP handshakes. Exchanges name, role, and mode identifiers. Completed handshake authenticates the name for data flow routing, the role for authorization, and the mode for how the node operates on a given channel. Extensible protocol that makes a trade-off on the side of simplicity and ease of debugging with a flexible header and a flexible data body. The header by defauilt is ascii readable and achieves compactness using a default value policy. This makes the ascii header on average about the same size as a ful binary header. Because the header is not fixed it is easily extensible and future proof. Using routed data flows on top of the RAET channel credentials enables a data flow router to easily implement authorization policy. Where Authorization is per data flow address. Dynamic authorization policy can be easily implemented via a lookup table associated with each router.

Hyperledger Plenum RBFT Python Implementation Plenum RBFT https://github.com/hyperledger/indy-plenum https://github.com/evernym/plenum/wiki Digital Signatures (no Macs) so don’t need digests.

Uses RAET (Reliable Asynchronous Event Transport) protocol https://github.com/RaetProtocol/raet