more comments

[iotcloud.git] / doc / iotcloud.tex

\documentclass[11pt]{article}\r
\newcommand{\tuple}[1]{\ensuremath \langle #1 \rangle}\r
\usepackage{color}\r
\usepackage{amsthm}\r
\newtheorem{theorem}{Theorem}\r
\newtheorem{defn}{Definition}\r
\newcommand{\note}[1]{{\color{red} \bf [[#1]]}}\r
\r
\begin{document}\r
\section{Approach}\r
\r
\subsection{Keys}\r
\r
Each device has: user id + password\r
\r
Server login is:\r
hash1(user id), hash1(password)\r
\r
Symmetric Crypto keys is:\r
hash2(user id | password)\r
\r
Server has finite length queue of entries + max\_entry\_identifier +\r
server login key\r
\r
\textbf{Login}\r
\note{Look at formal algorithm descriptions elsewhere, this is just informal prose...  It really needs to be more precise...}\r
\r
\begin{enumerate}\r
\item In the beginning, there are $d$ devices. Each of the \r
devices has a randomly/user-chosen self-generated $m$-bit user \r
identification $i$ and $n$-bit password $p$.\note{All devices being known in the beginning seems unreasonable...How about 1 device initially, and devices can be added at any time...}\r
\item Each device registers these $i$ and $p$ with the server. \r
The server appends ‘salt’ values, $k$-bit random strings $s1$ \r
and $s2$, and generate hash values $j=h(i+s1)$ and \r
$o=h(p+s2)$ for each $i$ and $p$. All $s1$, $s2$, $j$ and $o$ \r
are then stored in the database.\note{Are these the same $i$ and $p$ as below, if so, you just gave away the password}\r
\item Device to server validation is done by checking the hash values \r
$j\textsc{\char13}$ and $o\textsc{\char13}$ from $i\textsc{\char13}$ and \r
$p\textsc{\char13}$ that are given by users at login time against \r
$i$ and $p$ that are stored in the database.\r
\end{enumerate}\r
\r
\textbf{Symmetric Keys}\r
\note{The user uses the same username/key to log into all devices}\r
\begin{enumerate}\r
\item In the beginning, there are $d$ devices. Each of the \r
devices has a randomly/user-chosen self-generated $m$-bit user \r
identification $i$ and $n$-bit password $p$. These $i$ and $p$ \r
are used for device login on server.\r
\item All of $d$ agree on a hash function $h$ that is not known by \r
the server.\note{Doesn't make sense to agree on a hash function...People have a shared key.}\r
\item A symmetric key for each device is generated by applying $h$\r
to the value $(i + p)$ that gives $SK=h(i + p)$.\r
\item This value $SK$ is pre-known and pre-stored by all other \r
devices prior to operation of the data structure.\r
\end{enumerate}\r
\r
\textbf{Data Structure on Server}\r
\note{Define server state as an appropriate tuple and then give pseudocode here for updating that tuple...}\r
\begin{enumerate}\r
\item Server maintains a finite length $q$-entry FIFO queue \r
$Q=\{0, 1, …, q-1\}$. It has a head and a tail pointers that keep track \r
of head and tail slots.\r
\item Server records a max entry identifier $max$ as a limit for $q$. \r
It keeps track that $q \leq max$ at all times. When $q=max$, the queue \r
mechanism allows this sequence of events when there is a new slot added:\r
\begin{enumerate}\r
\item Pointer for entry $0$ now points to entry $1$, making it the new \r
entry $0$.\r
\item Entry $0$ is expunged from the queue.\r
\item New entry is added to the end of the queue, making it entry $q$.\r
\item Pointer for entry $q-1$ is advanced to entry $q$, making it the new \r
entry $q-1$.\r
\end{enumerate}\r
\item For client login, server maintains a table with values $i$, $p$,\r
$s1$, and $s2$ that are generated when device registers itself on server \r
for the first time.\r
\end{enumerate}\r
\r
\subsection{Entry layout}\r
Each entry has:\r
\begin{enumerate}\r
\item Sequence identifier\r
\item Random IV (if needed by crypto algorithm)\r
\item Encrypted payload\r
\end{enumerate}\r
\r
Payload has:\r
\begin{enumerate}\r
\item Sequence identifier\r
\item Machine id (most probably something like a 64-bit random number \r
that is self-generated by client)\r
\item HMAC of previous slot\r
\item Data entries\r
\item HMAC of current slot\r
\end{enumerate}\r
\r
A data entry can be one of these:\r
\begin{enumerate}\r
\item All or part of a Key-value entry\r
\item Slot sequence entry: Machine id + last message identifier \r
\newline {The purpose of this is to keep the record of the last slot \r
from a certain client if a client's update has to expunge that other \r
client's last entry from the queue. This is kept in the slot until \r
the entry owner inserts a newer update into the queue.}\r
\item Queue state entry: Includes queue size \newline {The purpose \r
of this is for the client to tell if the server lies about the number \r
of slots in the queue, e.g. if there are 2 queue state entry in the queue, \r
e.g. 50 and 70, the client knows that when it sees 50, it should expect \r
at most 50 slots in the queue and after it sees 70, it should expect \r
50 slots before that queue state entry slot 50 and at most 70 slots. \r
The queue state entry slot 70 is counted as slot number 51 in the queue.}\r
\end{enumerate}\r
\r
\subsection{Live status}\r
\r
Live status of entries:\r
\begin{enumerate}\r
\item Key-Value Entry is dead if either (a) there is a newer key-value pair or (b) it is incomplete.\r
        \r
\item Slot sequence number (of either a message version data\r
or user-level data) is dead if there is a newer slot from the same machine.\r
\r
\item Queue state entry is dead if there is a newer queue state entry.\r
{In the case of queue state entries 50 and 70, this means that queue state \r
entry 50 is dead and 70 is live. However, not until the number of slotes reaches \r
70 that queue state entry 50 will be expunged from the queue.}\r
\end{enumerate}\r
\r
When data is at the end of the queue ready to expunge, if:\r
\begin{enumerate}\r
\item The key-value entry is not dead, it must be reinserted at the\r
beginning of the queue.\r
\r
\item If the slot sequence number is not dead, then a message sequence\r
entry must be inserted.\r
\r
\item If the queue state entry is not dead, it must be reinserted at the\r
beginning of the queue.\r
\end{enumerate}\r
\r
\r
\paragraph{Reads:}\r
Client sends a sequence number.  Server replies with either: all data\r
entries or all newer data entries.\r
\r
\paragraph{Writes:}\r
Client sends slot, server verifies that sequence number is valid,\r
checks entry hash, and replies with an accept message if all checks\r
pass.  On success, client updates its sequence number.  On failure,\r
server sends updates slots to client and client validates those slots.\r
\r
\paragraph{Local state on each client:}\r
A list of machines and the corresponding latest sequence numbers.\r
\r
\paragraph{Validation procedure on client:}\r
\begin{enumerate}\r
\item Decrypt each new slot in order.\r
\item For each slot:\r
    (a) check its HMAC, and\r
    (b) check that the previous entry HMAC field matches the previous\r
    entry.\r
\item Check that the last message version for our machine matches our\r
last message sent.\r
\item For all other machines, check that the latest sequence number is\r
at least as large (never goes backwards).\r
\item That the queue has a current queue state entry.\r
\item That the number of entries received is consistent with the size\r
specified in the queue state entry.\r
\end{enumerate}\r
\r
Key-value entries can span multiple slots.  They aren't valid until\r
they are complete.\r
\r
\subsection{Resizing Queue}\r
Client can make a request to resize the queue. This is done as a write that combines:\r
  (a) a slot with the message, and\r
        (b) a request to the server\r
\r
\subsection{Formal Guarantees}\r
\r
\textit{To be completed ...}\r
\r
\begin{defn}[System Execution]\r
Formalize a system execution as a sequence of slot updates...  There\r
is a total order of all slot updates.\r
\end{defn}\r
\r
\begin{defn}[Transitive Closure]\r
Define transitive closure relation for slot updates...  There is an\r
edge from a slot update to a slot receive event if the receive event\r
reads from the update event.\r
\end{defn}\r
\r
\begin{defn}[Suborder]\r
Define suborder of total order.  It is a sequence of contiguous slots\r
updates (as observed by a given device).\r
\end{defn}\r
\r
\begin{defn}[Prefix of a suborder]\r
Given a sub order $o=u_{i},u_{i+1},...,u_j, u_{j+i},..., u', ...$ and\r
a slot update $u'$ in $o$, the prefix of $o$ is a sequence of all\r
updates that occur before $u'$ and $u'$.\r
\end{defn}\r
\r
\begin{defn}[Consistency between a suborder and a total order]\r
A suborder $o$ is consistent with a total order $t$, if all updates in $o$ appear in $t$ and they appear in the same order.\r
\end{defn}\r
\r
\begin{defn}[Consistency between suborders]\r
Define notion of consistency between suborders...  Two suborders U,V\r
are consistent if there exist a total order T such that both U and V\r
are suborders of T.\r
\end{defn}\r
\r
\begin{defn}[Error-free execution]\r
Define error-free execution --- execution for which the client does\r
not flag any errors...\r
\end{defn}\r
\r
\begin{theorem} Error-free execution of algorithm ensures that the suborder\r
for node n is consistent with the prefix suborder for all other nodes\r
that are in the transitive closure.\r
\end{theorem}\r
\begin{proof}\r
\textit{TODO}\r
\end{proof}\r
\r
\begin{defn}[State of Data Structure]\r
Define in terms of playing all updates sequentially onto local data\r
structure.\r
\end{defn}\r
\r
\begin{theorem}\r
Algorithm gives consistent view of data structure.\r
\end{theorem}\r
\begin{proof}\r
\textit{TODO}\r
\end{proof}\r
\r
\subsection{Future Work}\r
\paragraph{Support Messages}\r
  A message is dead once receiving machine sends an entry with a newer\r
  sequence identifier\r
\r
\paragraph{Persistent data structures}\r
        Root object w/ fields\r
        Other objects can be reachable from root\r
        Each object has its own entries\r
        Dead objects correspond to dead \r
\r
\paragraph{Multiple App Sharing}\r
\r
Idea is to separate subspace of entries...  Shared with other cloud...\r
\end{document}\r