Adding test for encrypted cloud storage; Adding preparation timing test for Fidelius...
[iotcloud.git] / non_block_chain / doc / iotcloud_informal / iotcloud.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 % Short Sectioned Assignment
3 % LaTeX Template
4 % Version 1.0 (5/5/12)
5 %
6 % This template has been downloaded from:
7 % http://www.LaTeXTemplates.com
8 %
9 % Original author:
10 % Frits Wenneker (http://www.howtotex.com)
11 %
12 % License:
13 % CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
14 %
15 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
16
17 %----------------------------------------------------------------------------------------
18 %   PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
19 %----------------------------------------------------------------------------------------
20
21 \documentclass[paper=letter, fontsize=11pt]{scrartcl} % A4 paper and 11pt font size
22
23 \usepackage[T1]{fontenc} % Use 8-bit encoding that has 256 glyphs
24 \usepackage{fourier} % Use the Adobe Utopia font for the document - comment this line to return to the LaTeX default
25 \usepackage[english]{babel} % English language/hyphenation
26 \usepackage{amsmath,amsfonts,amsthm} % Math packages
27 \usepackage{graphicx}
28 \usepackage{lipsum} % Used for inserting dummy 'Lorem ipsum' text into the template
29 \usepackage{hyperref}
30 \usepackage{amssymb}
31 \usepackage{listings}
32 \usepackage[]{algorithm2e}
33 \usepackage{algpseudocode}
34 \usepackage{enumerate}
35 \usepackage[table,xcdraw]{xcolor}
36 \usepackage{sectsty} % Allows customizing section commands
37 \usepackage{float}
38 \usepackage{caption}
39 \usepackage{gensymb} % to used degree symbol 
40 \usepackage{siunitx} 
41 \usepackage{enumitem}
42
43 \usepackage[sc]{mathpazo}
44 \allsectionsfont{ \normalfont\scshape} % Make all sections the default font and small caps
45 \usepackage{fancyhdr} % Custom headers and footers
46 \pagestyle{fancyplain} % Makes all pages in the document conform to the custom headers and footers
47 \fancyhead{} % No page header - if you want one, create it in the same way as the footers below
48 \fancyfoot[L]{} % Empty left footer
49 \fancyfoot[C]{} % Empty center footer
50 \fancyfoot[R]{\thepage} % Page numbering for right footer
51 \renewcommand{\headrulewidth}{0pt} % Remove header underlines
52 \renewcommand{\footrulewidth}{0pt} % Remove footer underlines
53 \setlength{\headheight}{13.6pt} % Customize the height of the header
54
55 \numberwithin{equation}{section} % Number equations within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
56 \numberwithin{figure}{section} % Number figures within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
57 \numberwithin{table}{section} % Number tables within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
58
59 \setlength\parindent{0pt} % Removes all indentation from paragraphs - comment this line for an assignment with lots of text
60
61 %----------------------------------------------------------------------------------------
62 %   TITLE SECTION
63 %----------------------------------------------------------------------------------------
64 \newcommand{\horrule}[1]{\rule{\linewidth}{#1}} % Create horizontal rule command with 1 argument of height
65
66 \title{ 
67 \normalfont \normalsize 
68 \textsc{University of California Irvine} \\  % Your university, school and/or department name(s)
69 \textsc{Prgramming Language Research Group} \\ [25pt]
70 \horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule
71 \huge IoTCloud Version 2.0\\ % The assignment title
72 \horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule
73 }
74
75 \author{Authors} % Your name
76
77
78 \date{\normalsize\today} % Today's date or a custom date
79
80 \begin{document}
81
82 \maketitle % Print the title
83
84
85
86
87 %---------------------------------------------------------------------------------------
88 % Custom Stuff
89 %---------------------------------------------------------------------------------------
90 \newcommand{\tab}[1]{\hspace{.2\textwidth}\rlap{#1}}
91
92
93
94
95 \section{\textbf{Introduction}}
96
97 \section{\textbf{Device Approach}}
98
99 \subsection{\textbf{Records}}
100 Each record has the following information included in it:
101 \begin{itemize}
102     \item Machine ID of the device creating the record
103     \item The vector clock using the largest clock values from each device it knows and its own largest clock value incremented by 1.
104     \item Data payload
105     \item HMAC of the record.
106 \end{itemize}
107     
108 Records can be identified by the machine ID and the local machine clock, hereby referred to as the record ID.
109
110 \subsubsection{\textbf{Types of Payloads}}
111 The different types of record payloads are:
112 \begin{itemize}
113
114     \item Transactions
115         \begin{itemize}
116             \item Contains:
117             \begin{itemize}
118                 \item Transaction ID
119                 \item key-value pair gets (reads)
120                 \item A guard condition (boolean condition) that can be evaluated on the key-value gets.
121                 \item A set of key-value pairs that are to be updated if the guard condition is met.
122                 \item Can only get and set key-value pairs that are from 1 arbitrator.  Getting and/or setting key-value pairs from more than 1 arbitrator causes the transaction to be invalid and dead.
123             \end{itemize}
124         \end{itemize}
125     \item Commit notifications
126         \begin{itemize}
127             \item Contains the commit of a single transaction, the whole transaction.
128             \item There is 1 commit per transaction.
129             \item Generated by the arbitrator for the set of key-value gets and sets in the transaction.
130         \end{itemize}
131     \item Abort notifications
132         \begin{itemize}
133             \item Contains a transaction ID of an aborted transaction and the machine ID of the device that created that transaction.
134             \item Causes a transaction to be aborted, key-values not used in updates.
135         \end{itemize}
136     \item Data structure re-size notifications
137         \begin{itemize}
138             \item Contains new size of data structure (number of record allowed in the data structure or something like that).
139         \end{itemize}
140     \item Server sequence number confirmations.
141         \begin{itemize}
142             \item Contains a record ID and the server sequence number for that record that the server reported.
143             \item Created by any device if that device finds a record with a server sequence number that does not have a server sequence number conformation yet.
144         \end{itemize}
145     \item Delete notifications
146         \begin{itemize}
147             \item Contain the server sequence number of the record that was deleted.
148             \item Generated when a device deletes a record.
149         \end{itemize}
150     \item New Key notification
151         \begin{itemize}
152             \item Contains the name of a new key and the machine ID of the machine that is to arbitrate
153             \item Generated when a device generates a new (never used) key-value pair.
154         \end{itemize}
155 \end{itemize}
156
157 \subsection{\textbf{Pulling the data structure}}
158 To pull the latest version of the data structure the following is done:
159 \begin{enumerate}
160     \item Make a pull request to the server and get all the records sent back.
161     \item Separate the records by machine ID.
162     \item For each machine ID, order the records based on that machine IDs clock within each of the records.
163     \item Check the data structure for any malicious activity (discussed below)
164 \end{enumerate}
165
166 \subsection{\textbf{Updates}}
167 Updates take place as follows:
168 \begin{enumerate}
169     \item A device pulls the latest version of the data structure.  If the device cannot pull the latest version because of network connectivity or some other issues then that device will just work using the local copy of the data structure it has.
170     \item Check the pulled data structure for any malicious activity (as stated in a section below) if not done already.
171     \item Check if any records in the current server need to be deleted (have delete notifications in data structure but the delete never took place), if so then delete them.
172     \item Check that the size of the data structure will not exceed the max size when the new record is inserted.  If it does then prepare to delete records by inserting delete payloads in the new record (discussed below).
173     \item The device makes a record as follows:
174         \begin{enumerate}
175             \item Adds its machine ID.
176             \item Creates a vector clock using the largest clock values from each device it knows and its own largest clock value incremented by 1.
177             \item Fill the record payload section with the transactions and other types of payloads.
178             \item Fill the empty space of the record payload with server sequence number confirmations for records that have yet to have their server sequence numbers confirmed.
179             \item Fill the empty space of the record payload with rescued key-value pairs, transactions, ext (Discussed later).
180             \item Pad the record to be the same size for all records.
181             \item Calculate the HMAC of the record and add that to the record
182             \item Encrypt the record.
183         \end{enumerate}
184     \item Send the record to the server for insertion into the device's queue.
185     \item Issue any server commands such as deletes to the server.
186 \end{enumerate}
187
188 If there is a connectivity issue then all the records will be held by the local device until connection is resumed then pushed to the server in the order which they occurred.  Also the device can only delete records for which there is a server sequence number.  At some point the device could run out of records to delete (it hasn't connected to the server in a while) in which case the device will not be able to delete any records.
189
190 \subsection{\textbf{Deletions}}
191 When deciding which records to delete the following is to be done:
192 \begin{enumerate}
193     \item Order all the records in order based on their server sequence numbers
194     \item Calculate the difference between the current size of the data structure and the minimum size of the data structure (lets call this $m$). Note: count newly inserted records towards the total size of the data structure if doing deletes while doing updates.
195     \item Delete the oldest m records based on the ordering from step 1. 
196     \begin{itemize}
197         \item If a record to be deleted has live data in it then the whole data structure needs to be re-sized.
198     \end{itemize}
199 \end{enumerate}
200
201 Note this makes that size of the data structure be bounded:
202 If there are $n$ devices and the data structure has a minimum size of $m$.  Then the max size of the data structure is given by $m + n -1$ for the case when all the devices make an update at the same time.   
203
204 \subsection{\textbf{Reading a key-value pair}}
205 When getting a key-value pair the following is done:
206 \begin{enumerate}
207     \item A device pulls the latest version of the data structure.  If the device cannot pull the latest version because of network connectivity or some other issues then that device will just work using the local copy of the data structure it has.
208     \item Check the pulled data structure for any malicious activity (as stated in a section below) if not done already.
209     \item Find the transaction with the largest server sequence number that contains the key-value pair of interest (this is the latest value).
210 \end{enumerate}
211
212 \subsection{\textbf{Rescuing Transactions, Commits, Aborts, Ext}}
213 Data should be proactively rescued from the "oldest" records currently in the data structure.  Unused space in new records should be used to rescue data from old records so that when it comes time to delete the old records, there are no live pieces of data that need to be rescued.  When a piece of data is rescued, it is rescued with its vector clock as well (so that the time of that data can be saved).\\
214
215 When rescuing transactions and commits: only keep the key-value pair sets that do not have a newer key-value pair set (no other transaction/commits sets that key-value pair later in the future).  This means that transactions/commits can shrink in size.\\
216
217 When rescuing Key Value notifications: save the vector clock and the server sequence number of the notification in the rescued data.
218
219 When deciding which data to rescue the following is to be done:
220 \begin{enumerate}
221     \item Order all the records in order based on their server sequence numbers
222     \item Create an ordered list of currently live transactions, commits, aborts, ext from the oldest $n$ records from step one where the order is based on the age of the data (how old the record is).
223     \item Randomly select from the list of live transactions, commits, aborts, ext to save.  Save as much as can fit in the current new record.  The random selection could give higher probability to transactions, commits, aborts, ext from records that are to be deleted sooner.
224 \end{enumerate}
225
226 \subsection{\textbf{Checking the Data Structure}}
227 Checking the data structure for consistency is done as follows:
228 \begin{enumerate}
229     \item Verify that each record in the data structure has an HMAC that matches the data in the record.
230     \item Verify that the oldest record the server sent has a server sequence number that is equal to or less than the server sequence number in the most recent delete notification (currently live delete notification) + 1.
231     \item Make sure that for each device queue the difference between the vector clock value of the device queues clock is at most 1 between 2 consecutive messages for all records with server sequence numbers above the last deleted records server sequence numbers.
232     \item Verify that no currently live data Structure re-size notification is smaller than the last known data structure size.  Data structure can only grow in size.
233     \item Verify that all the server sequence numbers for the records that are currently present have unique numbers.
234     \item Verify that all the server sequence numbers for the records have a difference of 1 (no gaps) for all records with server sequence numbers above the last deleted records server sequence numbers.
235     \item Verify record server sequence numbers against the stated server sequence numbers in the server sequence number notification payloads (make sure the server is not changing the sequence number on the fly).
236 \end{enumerate}
237
238 \subsection{\textbf{The Arbitrator}}
239 The arbitrator can:
240 \begin{enumerate}
241     \item Send Commits
242     \item Send Aborts
243 \end{enumerate}
244
245 \subsubsection{\textbf{Commits}}
246 Commits have the following properties
247 \begin{itemize}
248     \item Agree with the ordering of the server sequence numbers most of the time.
249     \item Cannot commit an already aborted transaction.
250     \item Commits state the ordering of key-value pairs.
251     \item Can disagree with the ordering of server sequence numbers if arbitrator decides to do so.
252     \item Should occur frequently as to make sure that the commit order matches the server sequence ordering as closely as possible (prevent large divergence of the 2 orderings)
253 \end{itemize}
254     
255 \subsubsection{\textbf{Aborts}}
256
257 \begin{itemize}
258     \item Aborts are used to show which transactions have been aborted based on the arbitrators decision.
259     \item Aborts are considered live until an abort acknowledgement is presented.
260 \end{itemize}
261  
262 \subsection{\textbf{Setting Up New Keys (Choosing the Arbitrator)}}
263 Setting up new keys is done as follows:
264 \begin{enumerate}
265     \item Device wishes to generate new key
266     \item Device inserts a New Key notification into the data structure.
267 \end{enumerate}
268 In the case where multiple devices are creating the same key, the key with the smallest vector clock is the only valid one.  In the case of a concurrent vector clock, the smallest server sequence number notification is the valid one.
269     
270 \subsection{\textbf{Live Status}}
271 Live Status of entries:
272 \begin{enumerate}
273
274     \item Delete notifications
275         \begin{itemize}
276             \item Live if it deleted the largest known server sequence number to be deleted (most recent delete).
277         \end{itemize}
278     
279     \item Commit notifications
280         \begin{itemize}
281             \item Live until all the key-value pair sets in the transaction commit are dead.
282                 \begin{itemize}
283                     \item key-value pairs are dead when a commit for a transaction that sets the same key-value pair occurs with a larger vector clock.
284                 \end{itemize}
285         \end{itemize}
286     
287     \item Abort notifications
288         \begin{itemize}
289             \item Live until the device whos machine ID is in the abort notification makes an update to the data structure that contains a vector clock that is more in the future than the vector clock for this abort notification.
290         \end{itemize}
291     
292     \item Data structure re-size notifications
293         \begin{itemize}
294             \item Live if it contains the largest target size of the data structure.
295         \end{itemize}
296     
297     \item Server sequence number confirmations.
298          \begin{itemize}
299             \item Live until the record that this notification is reporting on is deleted.
300         \end{itemize}
301         
302     \item Transactions
303         \begin{itemize}
304             \item Is dead if it is invalid (contains keys-values for multiple arbitrators)
305             \item Live until a commit or abort notification for this transaction is generated.
306         \end{itemize}
307         
308     \item New Key notification
309         \begin{itemize}
310             \item Is dead if there exists a New Key notification that has a server sequence number that is smaller and the same key name.
311         \end{itemize}
312     
313 \end{enumerate}
314
315 \section{\textbf{Server Approach}}
316
317 The servers view of the system is in terms of data slots where each data slot holds a single record, has a monotonically increasing number associated with it (server sequence number) for the record that currently is present in that data slot and can be set or deleted.  A server may have a finite amount of memory which it can partition into slots, reusing memory that newly deleted slots used to occupy.
318
319 There are 3 types of requests from a device that the server must respond to:
320 \begin{enumerate}
321     \item Pull all current slots.
322     \item Put a new record in a slot.
323     \item Delete a slot.
324 \end{enumerate}
325
326 \subsection{\textbf{Pull all current slots}}
327 In this case the server will simply send back all active slots (slots that have data) in any order along with each slots server sequence number.  It is the job of the devices to order the slots.
328
329 \subsection{\textbf{Put a new record in a slot}}
330 In this case the server will:
331 \begin{enumerate}
332     \item Receive a record data from a device.
333     \item Put this record data in an empty slot.
334     \item Assign the just received record the next number in the server sequence numbers.
335 \end{enumerate}
336 If more than 1 put request is made at the same time, the server is free to order the requests however it wishes.
337
338 \subsection{\textbf{Delete a slot}}
339 In this case the server will delete the data in the slot that has the server sequence number that matches the server sequence number in the delete request.  The server could delay the delete if it wishes (if it has plenty of space for new slots).
340
341 \section{\textbf{Data Structure Abstraction}}
342 This section outlines the data structure abstraction that is provided to the IoT application.  It is similar to a hash table key-value store.
343
344 Operations on the key-value store:
345 \begin{itemize}
346     \item Put operation
347     \item Get operation
348     \item Check put status
349     \item Create New Key Operation. 
350 \end{itemize}
351
352 \subsection{\textbf{Put Operation}}
353 This operation is described as follows:
354 \begin{itemize}
355     \item Has the form:  put(Key-value-list, guard)
356     \item Updates the key-value pairs listed in the key-value list.
357     \item Has a boolean guard that is passed in that is able to read from keys that are associated with the same arbitrator as the keys being updated
358     \item Returns an ID for this put (Transaction ID) or an error code if put is formatted incorrectly.
359     \item Underlying action: Creates a transaction, creates a record and inserts that record in the data structure (doing deletes and other house keeping operations as needed).
360 \end{itemize}
361
362 \subsection{\textbf{Get Operation}}
363 \begin{itemize}
364     \item Has the form:  get(key-name)
365     \item Gets the current value of a key, also returns a machine ID for the arbitrator of that key.
366     \item Underlying action:  Does a pull from the server and resolves the latest value for the specified key (as mentioned above).  Also does house keeping work like key rescue and sequence number notification as needed.
367 \end{itemize}
368
369 \subsection{\textbf{Check put status}}
370 \begin{itemize}
371     \item Has the form of a callback.
372     \item Notifies the application of an aborted transaction.
373     \item Underlying action:  when an abort notification is received then the callback is called.  This is checked whenever this application makes changes to the data structure.
374 \end{itemize}
375
376 \subsection{\textbf{Create New Key Operation}}
377 \begin{itemize}
378     \item Has the form:  createKey(key-name, machine-id)
379     \item Creates a new key with an arbitrator at a specific machine ID
380     \item Underlying action: Creates a new key notification, creates a record and inserts that record in the data structure (doing deletes and other house keeping operations as needed).
381 \end{itemize}
382
383
384
385 \section{\textbf{System Guarantees}}
386 \begin{itemize}
387     \item Server cannot view data inside records
388     \item Server cannot forge or modify or create any records
389     \item Server cannot withhold any records
390     \item Server cannot reorder records that could not have been ordered differently due to network latency
391     \item Server cannot delete records unless told to do so.
392     \item There will always be an obvious key-value pair that is the latest key value pair.
393     \item The data structure is bounded in size such that $m$ is the minimum size of the data structure,  $n$ is the number of devices in the system and $s$ is the current size of the data structure: $m \leq s \leq (m+n-1)$
394     \item Data structure can only grow when there are too may key-value pairs (and aborts) than what fit in the current data structure size within reason.
395     \item No currently valid data can be lost by the system and go undetected.
396     \item Devices can operate offline and re-sync with the system and get a consistent view of the system
397     \item If the server tries to hold a device on an older version of the data structure, that device can eventually rejoin the main data structure without problems.
398     \item Devices that have a transaction aborted will be able to be notified about the abort indefinitely (no time frame when notification must be accepted).
399     \item Server cannot hold a device on an old version of the data structure and then move them to a newer version of the data structure without being detected (The server sequence numbers would reveal conflicts or gaps or both).
400
401 \end{itemize}
402     
403 \section{\textbf{System Correctness}}
404 The measures of correctness for the system are divided by context and the different system operations as follows:
405 \begin{itemize}
406     \item Data Integrity and Authentication
407     \item Ordering of Records
408     \item Data Structure Functions
409 \end{itemize}
410
411 \subsection{\textbf{Data Integrity and Authentication}}
412 The correctness of the cryptographic aspects of the data structure can be assumed provided that each record is encrypted with one of the client's key and the HMAC of each record does not indicate the data was tampered with. See section 2.7 for more details on how the data structure is verified.
413
414 \subsection{\textbf{Ordering of Records}}
415 The ordering of the records within the data structure is said to be correct if the total ordering derived from the records by the server sequence numbers does not conflict with the partial ordering derived from the vector clock.
416
417 \subsection{\textbf{Data Structure Functions}}
418 \subsubsection{\textbf{Put}}
419 \begin{itemize}
420      \item From the client side the put operation is said to be correct if the function returns a valid transaction ID for a successful operation or an error code for an unsuccessful operation.
421      \item From the server side the put operation is correct if the key-value pair changes only when the guard condition evaluates to true. The server should reply with either a transaction ID or and error code depending on the guard condition???
422 \end{itemize}
423
424 \subsubsection{\textbf{Get}}
425 \begin{itemize}
426      \item For the client the get operation is correct if it returns the value and arbitrator machine ID that corresponds with the input key. Or and error message if no key-value pair exists with that key??? In addition, if any housekeeping work is involved, the get operation must only rescue transactions with a live status. See section 2.10 for details on Live Status.
427      \item For the server a get operation is correct if the server returns a correctly ordered and untampered version of the data structure when the initial pull is done.
428 \end{itemize}
429
430 \subsubsection{\textbf{Create New Key}}
431 \begin{itemize}
432      \item The client correctly created a new key if it inserts a properly formatted new key notification into the data structure with a valid arbitrator machine ID.
433      \item The server is said to have correctly added a new key if a new key-value pair with the indicated arbitrator machine ID is inserted into the data structure. Or if it returns an error message for an invalid arbitrator machine ID??? What about collisions???
434 \end{itemize}
435
436
437 \end{document}