Completing login and key management (part 1.1)

diff --git a/doc/iotcloud.tex b/doc/iotcloud.tex
index acad12b9ce4cb0425fdd575d5ebfa9425df26e5a..f1a472a937897086d7b0aff7f2c32ba471c87e98 100644 (file)
--- a/doc/iotcloud.tex
+++ b/doc/iotcloud.tex
@@ -20,6 +20,57 @@ hash2(user id | password)
 Server has finite length queue of entries + max\_entry\_identifier +\r
 server login key\r
 \r
+\textbf{Login}\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$.\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.\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
+\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.\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
+\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