Security (finished) Quantum Computing The Swarm

• Mandatory Access Control (MAC) • Contrast: Discretionary Access Control (DAC)

1. Recall: Mandatory Access Control (MAC) CS194-24 • Mandatory Access Control (MAC) Advanced Operating Systems – “A Type of Access control by which the operating system constraints the ability of a subject or initiator to access Structures and Implementation or generally perform some sort of operation on an object or target.” Lecture 25 From Wikipedia – Subject: a process or thread Security (finished) – Object: files, directories, TCP/UDP ports, etc – Security policy is centrally controlled by a security policy Quantum Computing administrator: users not allowed to operate outside the The Swarm policy – Examples: SELinux, HiStar, etc. May 5th, 2014 • Contrast: Discretionary Access Control (DAC) Prof. John Kubiatowicz – Access restricted based on the identity of subjects and/or groups to which they belong – Controls are discretionary – a subject with a certain access permission is capable of passing that permission on to any other subject – Standard UNIX model 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.2 Recall: Signatures/Certificate Authorities How to perform Authorization for Distributed Systems? • Can use Xpublic for person X to define their identity – Presumably they are the only ones who know Xprivate. – Often, we think of Xpublic as a “principle” (user) Different • Suppose we want X to sign message M? – Use private key to encrypt the digest, i.e. H(M)Xprivate Authorization – Send both M and its signature: Domains » Signed message = [M,H(M)Xprivate] – Now, anyone can verify that M was signed by X » Simply decrypt the digest with Xpublic • Issues: Are all user names in world unique? » Verify that result matches H(M) – No! They only have small number of characters • Now: How do we know that the version of Xpublic that »   we have is really from X??? – Answer: Certificate Authority » However, someone thought their friend was » Examples: Verisign, Entrust, Etc. and I got very private email intended for someone else… – X goes to organization, presents identifying papers – Need something better, more unique to identify person » Organization signs X’s key: [ Xpublic, H(Xpublic)CAprivate] • Suppose want to connect with any server at any time? » Called a “Certificate” – Before we use Xpublic, ask X for certificate verifying key – Need an account on every machine! (possibly with » Check that signature over Xpublic produced by trusted different user name for each account) authority – OR: Need to use something more universal as identity • How do we get keys of certificate authority? » Public Keys! (Called “Principles”) – Compiled into your browser, for instance! » People are their public keys 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.3 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.4

2. Distributed Access Control Analysis of Previous Scheme Access Control List (ACL) for X: • Positive Points: File X ACL verifier – Identities checked via signatures and public keys Owner Key: Hash, Timestamp, R: Key: 0x546DFEFA34… » Client can’t generate request for data unless they have 0x22347EF… Signature (owner) RW: Key: 0x467D34EF83… private key to go with their public identity » Server won’t use ACLs not properly signed by owner of file RX: Group Key: 0xA2D3498672… – No problems with multiple domains, since identities Server 1: Domain 2 Group designed to be cross-domain (public keys domain neutral) Read GACL • Revocation: Client 1 Group ACL: – What if someone steals your private key? Domain 1 GACL verifier Key: 0xA786EF889A… » Need to walk through all ACLs with your key and change…! Hash, Timestamp, » This is very expensive Signature (group) Key: 0x6647DBC9AC… – Better to have unique string identifying you that people Server 2: Domain 3 place into ACLs » Then, ask Certificate Authority to give you a certificate • Distributed Access Control List (ACL) matching unique string to your current public key – Contains list of attributes (Read, Write, Execute, etc) » Client Request: (request + unique ID)Cprivate; give server with attached identities (Here, we show public keys) certificate if they ask for it. » ACLs signed by owner of file, only changeable by owner » Key compromisemust distribute “certificate revocation”, » Group lists signed by group key since can’t wait for previous certificate to expire. – ACLs can be on different servers than data – What if you remove someone from ACL of a given file? » Signatures allow us to validate them » If server caches old ACL, then person retains access! » ACLs could even be stored separately from verifiers » Here, cache inconsistency leads to security violations! 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.5 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.6 Analysis Continued Reprise: Distributed Decision Making • Who signs the data? • Why is distributed decision making desirable? – Or: How does client know they are getting valid data? – Fault Tolerance! – Signed by server? – Group of machines comes to decision even if one or more fail » What if server compromised? Should client trust server? » Simple failure mode called “failstop” (is this realistic?) – Signed by owner of file? – After decision made, result recorded in multiple places » Better, but now only owner can update file! » Pretty inconvenient! • Two-Phase Commit protocol does this – Signed by group of servers that accepted latest update? – Stable log on each machine tracks whether commit has happened » If must have signatures from all servers  Safe, but one » If a machine crashes, when it wakes up it first checks its log to bad server can prevent update from happening recover state of world at time of crash » Instead: ask for a threshold number of signatures – Prepare Phase: » Byzantine agreement (in a moment) can help here » The global coordinator requests that all participants will promise to • How do you know that data is up-to-date? commit or rollback the transaction – Valid signature only means data is valid older version » Participants record promise in log, then acknowledge – Freshness attack: » If anyone votes to abort, coordinator writes “Abort” in its log and » Malicious server returns old data instead of recent data tells everyone to abort; each records “Abort” in log » Problem with both ACLs and data – Commit Phase: » E.g.: you just got a raise, but enemy breaks into a server » After all participants respond that they are prepared, then the and prevents payroll from seeing latest version of update coordinator writes “Commit” to its log – Hard problem » Then asks all nodes to commit; they respond with ack » Needs to be fixed by invalidating old copies or having a trusted group of servers (Byzantine Agrement?) » After receive acks, coordinator writes “Got Commit” to log – Log helps ensure all machines either commit or don’t commit 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.7 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.8

3. Distributed Decision Making Discussion (Con’t) Byzantine General’s Problem • Undesirable feature of Two-Phase Commit: Blocking Lieutenant – One machine can be stalled until another site recovers: » Site B writes “prepared to commit” record to its log, sends a “yes” vote to the coordinator (site A) and crashes Retreat! » Site A crashes Attack! Lieutenant » Site B wakes up, check its log, and realizes that it has voted “yes” on the update. It sends a message to site A asking what happened. At this point, B cannot decide to General abort, because update may have committed » B is blocked until A comes back Malicious! Lieutenant – A blocked site holds resources (locks on updated items, pages pinned in memory, etc) until learns fate of update • Byazantine General’s Problem (n players): – One General • Alternative: There are alternatives such as “Three – n-1 Lieutenants Phase Commit” which don’t have this blocking problem – Some number of these (f) can be insane or malicious • What happens if one or more of the nodes is • The commanding general must send an order to his n-1 malicious? lieutenants such that: – IC1: All loyal lieutenants obey the same order – Malicious: attempting to compromise the decision making – IC2: If the commanding general is loyal, then all loyal lieutenants obey the order he sends 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.9 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.10 Byzantine General’s Problem (con’t) Administrivia • Impossibility Results: • Don’t forget Group evaluations! – Cannot solve Byzantine General’s Problem with n=3 – Please get them in promptly because one malicious player can mess up things – Want all of them by this weekend General General » Including lab 4: Will post survey sooner rather than later Attack! Attack! Attack! Retreat! • Final: Tuesday May 13th Lieutenant Lieutenant Lieutenant Lieutenant – 310 Soda Hall Retreat! Retreat! – 11:30—2:30 – With f faults, need n > 3f to solve problem – Bring calculator, 2 pages of hand-written notes • Various algorithms exist to solve problem • Review Session – Original algorithm has #messages exponential in n – Sunday 5/11 – Newer algorithms have message complexity O(n2) – 4-6PM, 405 Soda Hall » One from MIT, for instance (Castro and Liskov, 1999) • Final Topics: • Use of BFT (Byzantine Fault Tolerance) algorithm – Focus on second half of term, but still need to be responsible – Allow multiple machines to make a coordinated decision for first half of term material even if some subset of them (< n/3 ) are malicious – Everything up to last Wednesday! • Watch for Piazza Survey – Try to figure out what we should do with labs Request Distributed – What worked, what didn’t…. Decision 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.11 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.12

4. Trusted Computing • Problem: Can’t trust that software is correct – Viruses/Worms install themselves into kernel or system without users knowledge – Rootkit: software tools to conceal running processes, files or system data, which helps an intruder maintain access to a system without the user's knowledge – How do you know that software won’t leak private information or further compromise user’s access? • A solution: What if there were a secure way to validate Trusted Computing all software running on system? – Idea: Compute a cryptographic hash of BIOS, Kernel, crucial programs, etc. – Then, if hashes don’t match, know have problem • Further extension: – Secure attestation: ability to prove to a remote party that local machine is running correct software – Reason: allow remote user to avoid interacting with compromised system • Challenge: How to do this in an unhackable way – Must have hardware components somewhere 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.13 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.14 TCPA: Trusted Computing Platform Alliance Trusted Platform Module • Idea: Add a Trusted Platform Module (TPM) Functional Non-volatile Volatile Units Memory Memory • Founded in 1999: Compaq, HP, IBM, Intel, Microsoft Random Num Endorsement Key RSA Key Slot-0 • Currently more than 200 members Generator (2048 Bits) … SHA-1 Storage Root Key RSA Key Slot-9 • Changes to platform Hash (2048 Bits) PCR-0 – Extra: Trusted Platform Module (TPM) HMAC Owner Auth … Secret(160 Bits) PCR-15 – Software changes: BIOS + OS RSA Encrypt/ Decrypt Key Handles • Main properties RSA Key Auth Session Generation Handles – Secure bootstrap – Platform attestation • Cryptographic operations – Protected storage – Hashing: SHA-1, HMAC – Random number generator • Microsoft version: – Asymmetric key generation: RSA (512, 1024, 2048) ATMEL TPM Chip – Palladium (Used in IBM equipment) – Asymmetric encryption/ decryption: RSA – Note quite same: More extensive Symmetric encryption/ decryption: DES, 3DES (AES) – hardware/software system • Tamper resistant (hash and key) storage 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.15 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.16

5. TCPA: PCR Reporting Value TCPA: Secure bootstrap Platform Configuration Register extended value present value measured values Option Hash Concatenate Hardware Memory TPM ROMs • Platform Configuration Registers (PCR0-16) – Reset at boot time to well defined value BIOS OS boot BIOS OS Application Network – Only thing that software can do is give new block loader measured value to TPM » TPM takes new value, concatenates with old value, Root of trust in then hashes result together for new PCR integrity New OS Component • Measuring involves hashing components of software measurement TPM • Integrity reporting: report the value of the PCR measuring – Challenge-response protocol: Root of trust in reporting integrity reporting storing values Challenger nonce Trusted Platform Agent logging methods TPM SignID(nonce, PCR, log), CID 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.17 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.18 Implications of TPM Philosophy? • Could have great benefits – Prevent use of malicious software – Could help protect privacy of data • What does “trusted computing” really mean? – You are forced to trust hardware to be correct! – Could also mean that user is not trusted to install their own software • Many in the security community have talked about potential abuses – These are only theoretical, but very possible Quantum Computing – Software fixing » What if companies prevent user from accessing their websites with non-Microsoft browser? » Possible to encrypt data and only decrypt if software still matches  Could prevent display of .doc files except on Microsoft versions of software – Digital Rights Management (DRM): » Prevent playing of music/video except on accepted players » Selling of CDs that only play 3 times? 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.19 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.20

6. Can we Use Quantum Mechanics to Compute? Quantization: Use of “Spin” • Weird properties of quantum mechanics? North – Quantization: Only certain values or orbits are good » Remember orbitals from chemistry??? Representation: Spin ½ particle: – Superposition: Schizophrenic physical elements don’t |0> or |1> (Proton/Electron) quite know whether they are one thing or another • All existing digital abstractions try to eliminate QM – Transistors/Gates designed with classical behavior – Binary abstraction: a “1” is a “1” and a “0” is a “0” South • Quantum Computing: Use of Quantization and Superposition to compute. • Particles like Protons have an intrinsic “Spin” when defined with respect to an external • Interesting results: magnetic field – Shor’s algorithm: factors in polynomial time! • Quantum effect gives “1” and “0”: – Grover’s algorithm: Finds items in unsorted database in time proportional to square-root of n. – Either spin is “UP” or “DOWN” nothing between 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.21 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.22 Kane Proposal II (First one didn’t quite work) Now add Superposition! • The bit can be in a combination of “1” and “0”: – Written as: = C0|0> + C1|1> – The C’s are complex numbers! Single Spin – Important Constraint: |C0|2 + |C1|2 =1 Control Gates • If measure bit to see what looks like, – With probability |C0|2 we will find |0> (say “UP”) Inter-bit – With probability |C1|2 we will find |1> (say “DOWN”) Control Gates • Is this a real effect? Options: Phosphorus – This is just statistical – given a large number of protons, a Impurity Atoms fraction of them (|C0|2 ) are “UP” and the rest are down. – This is a real effect, and the proton is really both things until you try to look at it • Bits Represented by combination of proton/electron spin • Reality: second choice! • Operations performed by manipulating control gates – There are experiments to prove it! – Complex sequences of pulses perform NMR-like operations • Temperature < 1° Kelvin! 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.23 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.24

7. Implications: A register can have many values Spooky action at a distance • Implications of superposition: • Consider the following simple 2-bit state: = C00|00>+ C11|11> – An n-bit register can have 2n values simultaneously! – Called an “EPR” pair for “Einstein, Podolsky, Rosen” – 3-bit example: • Now, separate the two bits: = C000|000>+ C001|001>+ C010|010>+ C011|011>+ C100|100>+ C101|101>+ C110|110>+ C111|111> Light-Years? • Probabilities of measuring all bits are set by coefficients: – So, prob of getting |000> is |C000|2, etc. • If we measure one of them, it instantaneously sets other one! – Suppose we measure only one bit (first): – Einstein called this a “spooky action at a distance” » We get “0” with probability: P0=|C000|2+ |C001|2+ |C010|2+ |C011|2 – In particular, if we measure a |0> at one side, we get a |0> at the other (and vice versa) Result: = (C000|000>+ C001|001>+ C010|010>+ C011|011>) • Teleportation » We get “1” with probability: P1=|C100|2+ |C101|2+ |C110|2+ |C111|2 – Can “pre-transport” an EPR pair (say bits X and Y) Result: = (C100|100>+ C101|101>+ C110|110>+ C111|111>) – Later to transport bit A from one side to the other we: • Problem: Don’t want environment to measure before » Perform operation between A and X, yielding two classical bits ready! » Send the two bits to the other side – Solution: Quantum Error Correction Codes! » Use the two bits to operate on Y » Poof! State of bit A appears in place of Y 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.25 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.26 Model? Operations on coefficients + measurements Security of Factoring • The Security of RSA Public-key cryptosystems Input Output depends on the difficult of factoring a number N=pq Unitary Complex Transformations Measure Classical (product of two primes) State Answer – Classical computer: sub-exponential time factoring • Basic Computing Paradigm: – Quantum computer: polynomial time factoring – Input is a register with superposition of many values • Shor’s Factoring Algorithm (for a quantum computer) » Possibly all 2n inputs equally probable! Easy 1) Choose random x : 2  x  N-1. – Unitary transformations compute on coefficients » Must maintain probability property (sum of squares = 1) Easy 2) If gcd(x,N)  1, Bingo! » Looks like doing computation on all 2n inputs simultaneously! Hard 3) Find smallest integer r : xr  1 (mod N) – Output is one result attained by measurement Easy 4) If r is odd, GOTO 1 • If do this poorly, just like probabilistic computation: – If 2n inputs equally probable, may be 2n outputs equally Easy 5) If r is even, a = x r/2 (mod N)  (a-1)(a+1) = kN probable. Easy 6) If a = N-1 GOTO 1 – After measure, like picked random input to classical function! 7) ELSE gcd(a ± 1,N) is a non trivial factor of N. – All interesting results have some form of “fourier transform” Easy computation being done in unitary transformation 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.27 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.28

8. Shor’s Factoring Algorithm ION Trap Quantum Computer: Promising technology k\/ 1 \/ \ k\   k/ x Top / Cross- Sectional k r 1 k w r y \/ x \/ View  w r 1 w  0 y ( ) • IONS of Be+ trapped in w\ Quantum Fourier w0 x/ oscillating quadrature field – Internal electronic modes of IONS used for quantum bits Transform 0 1 k – MEMs technology r r r – Target? 50,000 ions • Finally: Perform measurement – ROOM Temperature! – Find out r with high probability • Ions moved to interaction regions Top View – Get |y>|aw’> where y is of form k/r and w’ is related – Ions interactions with one Proposal: NIST Group another moderated by lasers 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.29 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.30 Vision of Quantum Circuit Design Important Measurement Metrics • Traditional CAD Metrics: – Area » What is the total area of a circuit? » Measured in macroblocks (ultimately m2 or similar) – Latency (Latencysingle) » What is the total latency to compute circuit once Schematic Capture Classical Control » Measured in seconds (or s) QEC Insertion (Graphical Entry) Partitioning Teleportation Network – Probability of Success (Psuccess) Layout » Not common metric for classical circuits OR Network Insertion » Account for occurrence of errors and error correction Error Analysis … • Quantum Circuit Metric: ADCR Custom Layout and Optimization – Area-Delay to Correct Result: Probabilistic Area-Delay metric Scheduling Area  Latencysingle CAD Tool – ADCR = Area  E(Latency) = Implementation Psuccess – ADCRoptimal: Best ADCR over all configurations • Optimization potential: Equipotential designs Quantum Assembly – Trade Area for lower latency (QASM) – Trade lower probability of success for lower latency 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.31 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.32

9. How to evaluate a circuit? Quantum CAD flow • First, generate a physical instance of circuit – Encode the circuit in one or more QEC codes QEC Insert Input Circuit QEC – Partition and layout circuit: Dependant of layout heuristics! Circuit Optimization » Create a physical layout and scheduling of bits Synthesis Fault-Tolerant Tolerant Fault » Yields area and communication cost Circuit ReSynthesis (ADCRoptimal) (No layout) Normal Vector Monte Carlo: Monte Carlo: n times single pass Teleportation Mapping, Circuit Communication Network Scheduling, Partitioning Estimation Insertion Classical control Functional Partitioned ReMapping • Then, evaluate probability of success System Circuit Output Layout – Technique that works well for depolarizing errors: Monte Carlo » Possible error points: Operations, Idle Bits, Communications – Vectorized Monte Carlo: n experiments with one pass Hybrid Fault – Need to perform hybrid error analysis for larger circuits Analysis Error Analysis Complete Layout • Finally – Compute ADCR for particular result Most Vulnerable Circuits Psuccess – Repeat as necessary by varying parameters to generate ADCRoptimal ADCR computation 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.33 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.34 Area Breakdown for Adders Investigating 1024-bit Shor’s • Full Layout of all Elements – Use of 1024-bit Quantum Adders • Error Correction is not predominant use of area – Optimized error correction – Only 20-40% of area devoted to QEC ancilla – For Optimized Qalypso QCLA, 70% of operations for QEC – Ancilla optimization and Custom Network Layout ancilla generation, but only about 20% of area • Statistics: • T-Ancilla generation is major component – Often overlooked – Unoptimized version: 1.351015 operations • Networking is significant portion of area when allowed – Optimized Version 1000X smaller to optimize for ADCR (30%) – QFT is only 1% of total execution time – CQLA and QLA variants didn’t really allow for much flexibility 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.35 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.36

10. 1024-bit Shor’s Continued The Swarm • Circuits too big to compute Psuccess – Working on this problem • Fastest Circuit: 6108 seconds ~ 19 years – Speedup by classically computing recursive squares? • Smallest Circuit: 7659 mm2 – Compare to previous estimate of 0.9 m2 = 9105 mm2 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.37 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.38 Meeting the needs of the Swarm Examples Cloud Services • eWallpaper: – Real-Time scheduling of resources Personal – Secure loading of code Swarm – Privacy maintenance of collected information, communication • Teleconference on nearest wall: – Automatic location of resources » Display, Microphone, Camera, Routers Metropolitan » Resources for transcoding, audio transcription » Positional tracking Middleware – QoS-guaranteed network path to other side • Support for the Swarm: • UnPad: – Discover and Manage resource – Resource location and allocation » Displays, Microphones, Cameras, etc – Integrate sensors, portable devices, cloud components » High-performance streaming of data from the network – Guarantee responsiveness, real-time behavior, throughput – ID-Based personalization – Self-adapt to adjust for failure and provide performance » RFID, Cellphone connection, other methods for root keys predictability » Targeted advertisement, personalized focus on – Deep archival storage  permanent digital history of activity – Secure, high-performance, durable, available data 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.39 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.40

11. Separating Resource Allocation Brokering Service: from Resource Usage The Hierarchy of Ownership Resource Allocation • Discover Resources in “Domain” And Parent – Devices, Services, Other Brokers Distribution Broker – Constraints: Ownership, Access Control Monolithic CPU and Resource Two-Level Scheduling • Allocate and Distribute Resources to Scheduling Components that need them Application Specific Sibling Local – Dynamically optimize execution Scheduling Broker Broker – Hand out Service-Level Agreements (SLAs) to Software Components • Split monolithic scheduling into two pieces: – Deny admission to application – Course-Grained Resource Allocation and Distribution components when violate existing » Chunks of resources (CPUs, Memory Bandwidth, QoS to Services) Child agreements » Ultimately a hierarchical process negotiated with service Broker providers • Resources described via declarative – Fine-Grained (User-Level) Application-Specific Scheduling language: properties + requirements » Applications allowed to utilize their resources in any way they – Model of cyber-physical interactions see fit – Requirements for usage » Performance Isolation: Other components of the system cannot – Constraints placed on other resources interfere with Cells use of resources 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.41 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.42 Resource Container: the Cell Applications are Interconnected Graphs of Services • Properties of a Cell – A user-level software component with guaranteed resources Secure Device Real-Time Drivers – Has full control over resources it owns (“Bare Metal”) Cells Channel Secure – Contains at least one memory protection domain (possibly (Audio, Secure Channel Video) more) Channel Parallel Library File Core Application – Contains a set of secured channel endpoints to other Cells Service – Hardware-enforced security context to protect the privacy • Component-based model of computation of information and decrypt information (a Hardware TCB) – Applications consist of interacting components • Each Cell schedules its resources exclusively with – Explicitly asynchronous/non-blocking application-specific user-level schedulers – Components may be local or remote – Gang-scheduled hardware thread resources (“Harts”) • Channel Interface  Service API, Security Boundary – Virtual Memory mapping and paging – Channels are points at which data may be compromised – Storage and Communication resources – Channels define points for QoS constraints » Cache partitions, memory bandwidth, power or energy – Fault tolerance and adaptation by evolving connections – Use of Guaranteed fractions of system services 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.43 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.44

12. Impact on the Programmer Space-Time Partitioning  Cell • Connected graph of Cells  Object-Oriented Programming – Lowest-Impact: Wrap a functional interface around channel Space » Cells hold “Objects”, Secure channels carry RPCs for “method calls” Time – Greater Parallelism: Event triggered programming • Applications compiled from abstract graph description • Spatial Partition: • Partitioning varies over time – Independent of location or identity of services Performance isolation • Shared services complicate resource isolation: – Fine-grained multiplexing and – Each partition receives a guarantee of resources – How to ensure each client gets well-defined fraction of service? vector of basic resources » Resources are gang-scheduled » A number HW threads – Distributed resource attribution (application as distributed graph) • Controlled multiplexing, not » Chunk of physical memory » A portion of shared cache uncontrolled virtualization Application A » A fraction of memory BW • Partitioning adapted to the » Shared fractions of services system’s needs Shared File Service – Use of Virtualization extensions (e.g. Vt-x) Application B 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.45 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.46 An Application Model DataCentric Vision • Hardware resources are a commodity Channel – Computation resource fails? Get another Sensors Real-Time with – Sensor fails? Find another Components Aggregation Transform SwarmLet and Archive – Change your location? Find new resources (“The Application”) Distributed • All that really matters is the information Archival – Integrity, Privacy, Availability, Durability • A Swarm Application is a Storage Connected graph of Components – Hardware to prevent accidental information leakage – Globally distributed, but locality and QoS aware • We need a new Internet for the Internet of Things – Avoid Stovepipe solutions through reusability – Communication and Storage are really duals • Many components are Shared Services written by – Why separate them? programmers with a variety of skill-sets and motivations – Well-defined semantics and a managed software version scheme – Service Level Agreements (SLA) with micropayments • Many are “Swarmlets” written by domain programmers – They care what application does, not how it does it 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.47 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.48

13. The Universal Data Plane Location-Independent Secure Log Cloud Services Cloud Services TimeStamped Stream of Data Secure Long Archival Storage and Proxy Term Archive Optimized Streaming • Multi-Source, Multi-Sink Secure Log – Append-only with timestamps and QoS specifications – Only authorized writers can append information – Only authorized readers can read data (random access) Aggregate/Filter • Low-functionality sensors can operate through proxy Personal Universal Tivo – Sign, Encrypt, Route – proxies can be deployed with sensors Cache • Transparent, Long-term Archival Storage – Support for Transactions, Indexing, Random Access 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.49 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.50 Log-Structured Communication Peer-to-Peer overlays for Is the New Universal Primitive! Object Location and Routing • Location-Independent routing to Logs by Identifier – Identifiers Represent Sinks and/or Sources of Data and Service are provided by discovery mechanism GUID Service – Routing optimized by Swarm-Routing Stack (SRS) (adapts to failure and topology changes) 1 • QoS specifications with respect to latency and/or BW Service – TimeStamps used for “deliver-by” scheduling (i.e. pTides) Service DOLR – QoS attached to sources and/or sinks (state in network) Service • Data Commitment and Archiving performed securely GUID2 – No single node can prevent or authorize changes Service GUID1 – Data encrypted and users authenticated at all times • Secure level of indirection – Data reordered by timestamps (subject to constraints) – Automatic adaptation to underlying topology • Commitment leaders and/or elements at tail of log found via automatic routing 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.51 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.52

14. QoS Routing Constraints are Integral to Model Time-Based Log Use Cases 1. Short-term archived stream of information – Authenticated channel of data bits ordered by timestamp – Data expires after specified time period Physical Network 2. Log-structured storage – Infrastructure provides associative lookup from log » Older entries read directly from the underlying infrastructure – Easy to provide object storage via copy-on-write • Physical Routing  Overlay Networks – Aware of topology and time of flight through nodes 3. Externally Consistent Transactions – Can Utilize physical QoS when available (i.e AVB) – Commitment order based on timestamps • Location-independent Routing through Overlay – Automatic mechanism for aborting transactions that would – Including Services (Log commit) Along Path violate serialization (i.e. Spanner) • Collaborative functionality runs on through overlay – Multi-stream transactions possible – Byzantine Commitment/Archiving 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.53 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.54 Online Deep Archival Storage Trusted Swarm Platform (Using Erasure Codes such as Reed-Solomon) Decrypt Encrypt Signature, Policy Signature, Policy Version, GUID Version, GUID • External Data Encrypted Distributed Public Key All The Time Infrastructure • Only decrypted in “Data Jails” (trusted platform) – Build in hardware or in software with secure attestation – Data leaving cell automatically reencrypted • Trusted Platform given keys to do its work – Keys never given out to application software • Similar idea: Hardware micropayment support 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.55 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.56

15. The Internet for the IoT Conclusion (1/2) • Duality between communication and storage • Distributed identity – Use cryptography (Public Key, Signed by PKI) – Why explicitly distinguish them? • Distributed storage example – The “Data Grid” equivalent to the “Power Grid” – Revocation: How to remove permissions from someone? – All data is read-only and time stamped when it enters the – Integrity: How to know whether data is valid grid and preserved as long as it stays in the grid – Freshness: How to know whether data is recent • Location Independent routing provides convenient glue for • Byzantine General’s Problem: distributed decision making with malicious failures constructing Swarm applications – One general, n-1 lieutenants: some number of them may be – Endpoints can be services, sensors, or archival objects malicious (often “f” of them) – All non-malicious lieutenants must come to same decision – Automatically locate close objects with given endpoint – If general not malicious, lieutenants must follow general • Dynamic Optimization: Gain advantages normally available – Only solvable if n  3f+1 only to large internet providers • Trusted Hardware – A secure layer of hardware that can: – Generate optimized multicast networks when necessary » Generate proofs about software running on the machine – Construct content distribution networks (CDNs) on the fly » Allow secure access to information without revealing keys to (potentially) compromised layers of software • Security, authentication, privacy, micropayments – Cannonical example: TPM 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.57 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.58 Conclusion (2/2) • Quantum Computing – Using interesting properties of physics to compute – Noise is one of the most complex aspects – At a stage where Computer Aided Design (CAD) makes sense – Quantum Circuit Metric: ADCR » Area-Delay to Correct Result: Probabilistic Area-Delay metric » ADCR = Area  E(Latency) ADCRoptimal: Best ADCR over all configurations • Services for the Swarm: Good Bye! – Use of Resources negotiated hierarchically – Underlying Execution environment guarantees QoS – New Resources constructed from Old ones: » Aggregate resources in combination with QoS-Aware Scheduler » Result is a new resource that can be negotiated for – Continual adaptation and optimization • Let’s give a hand to Palmer and Vedant – the labs wouldn’t exist without them! 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.59 5/5/14 Kubiatowicz CS194-24 ©UCB Fall 2014 Lec 25.60