Few last fixes

1 files changed, 18 insertions, 19 deletions

diff --git a/paper/safety-reset-paper.tex b/paper/safety-reset-paper.tex
index 732387a..f2004c6 100644
--- a/paper/safety-reset-paper.tex
+++ b/paper/safety-reset-paper.tex
@@ -75,7 +75,7 @@ frequency modulation channel is robust and can be used even during an ongoing at
 the \emph{safety reset} controller, an attack mitigation technique that is compatible with most smart meter and IoT
 device designs. A safety reset controller is a separate controller integrated to the device that awaits an out-of-band
 reset command transmitted through GFM. Upon reception of the reset command, it puts the device into a safe state (e.g.
-\emph{relay on} or \emph{light on}) that interrupts attacker control over the device. The safety reset controller is
+\emph{heater off} or \emph{light on}) that interrupts attacker control over the device. The safety reset controller is
 separated from the system's main application controller and itself does not have any conventional network connections to
 reduce attack surface and cost.
 
@@ -600,29 +600,27 @@ correction~\cite{mackay01} and some cryptography. The goal of our PoC cryptograp
 sender of an emergency reset broadcast to authorize a reset command to all listening smart meters. An additional
 constraint of our setting is that due to the extremely slow communication channel all messages should be kept as short
 as possible. The solution we chose for our PoC is a simplistic hash chain using the approach from the Lamport and
-Winternitz One-time Signature (OTS) schemeS~\cite{lamport02,merkle01}. Informally, the private key is a random
+Winternitz One-time Signature (OTS) schemes~\cite{lamport02,merkle01}. Informally, the private key is a random
 bitstring. The public key is generated by recursively applying a hash function to this key a number of times. Each smart
 meter reset command is then authorized by disclosing subsequent elements of this series. Unwinding the hash chain from
 the public key at the end of the chain towards the private key at its beginning, at each step a receiver can validate
 the current command by checking that it corresponds to the previously unknown input of the current step of the hash
-chain. Replay attacks are prevented by the device memorizing the most recent valid command. Keys revocation is supported
-by designating the last key in the chain as a \emph{revocation key} upon whose reception the client devices advance
-their local hash ratchet without taking further action.  This simple scheme does not afford much functionality but it
-results in very short messages and removes the need for computationally expensive public key cryptography inside the
-smart meter.
+chain. Replay attacks are prevented by the device memorizing the most recent valid command.  This simple scheme does not
+afford much functionality but it results in very short messages and removes the need for computationally expensive
+public key cryptography inside the smart meter.
 
-Formally, we can describe our simple cryptographic protocol as follows. Given an $n$-bit cryptographic hash function $H
+Formally, we can describe our simple cryptographic protocol as follows. Given an $m$-bit cryptographic hash function $H
 : \{0,1\}^*\rightarrow\{0,1\}^m$ and a private key $k_0 \in \{0,1\}^m$, we construct the public key as
 $k_{n_\text{total}} = H^{n_\text{total}}(k_0)$ where $H^n(x)$ denotes the $n$-times recursive application of $H$ to
-itself, i.e.\ $\underbrace{H(H(\hdots H(}_{n\;\text{times}}x)))$. $q$ is the total number of signatures that the system can
-issue. $n_\text{total}$ must be chosen with adequate safety margin to account for unpredictable future use of the
-system. The choice of $n_\text{total}$ is of no consequence when a device checks reset authorization, but key generation
-time grows linearly with $n_\text{total}$ since $H$ needs to applied $n_\text{total}$ times. In practice, given the
-speed of modern computers, values of $n_\text{total} > 10^9$ should pose no problem during key generation. For public
-key $k_{n_\text{total}}$, the system can authorize up to $n_\text{total}$ commands by successively disclosing the $k_i$
-starting at $i=n-1$ and counting down until finally disclosing $k_0$. Since we only want to transmit a single bit of
-information, we do not need any payload. Instead, we simply send a message $m =  (k_i)$ consisting solely of $k_i$. The
-receiver of a message $m$ can check that the message is a legitimate command by checking $\exists i<q: H^i(m) =
+itself, i.e.\ $H(H(\hdots H(x)))$. $n_\text{total}$ is the total number of signatures that the system can
+issue over its lifetime. $n_\text{total}$ must be chosen with adequate safety margin to account for unpredictable future
+use of the system. The choice of $n_\text{total}$ is of no consequence when a device checks reset authorization, but key
+generation time grows linearly with $n_\text{total}$ since $H$ needs to applied $n_\text{total}$ times. In practice,
+given the speed of modern computers, values of $n_\text{total} > 10^9$ should pose no problem during key generation. For
+public key $k_{n_\text{total}}$, the system can authorize up to $n_\text{total}$ commands by successively disclosing the
+$k_i$ starting at $i=n-1$ and counting down until finally disclosing $k_0$. Since we only want to transmit a single bit
+of information, we do not need any payload. Instead, we simply send a message $m =  (k_i)$ consisting solely of $k_i$.
+The receiver of a message $m$ can check that the message is a legitimate command by checking $\exists i<q: H^i(m) =
 k_\text{last}$ where $k_\text{last}$ is the last valid command that was received. $q$ is the maximum lookup depth that
 the device will accept as valid. To conserve processing power, $q$ should be chosen to be much smaller than
 $n_\text{total}$. Choosing $q$ too small, a device might become out of sync with the transmitter when it is disconnected
@@ -641,7 +639,8 @@ $k_i$ alternatingly. For odd $i$, $k_i$ is a reset command and for even $i$, $k_
 trigger a safety reset, the utility transmits the next unused $k_{2i+1}$. The utility may transmit this command repeatedly
 to also reset devices that have come online only after earlier transmissions have started. After a sufficient number of
 devices have performed a safety reset, the utility then transmits the next disarm command, $k_{2i}$. When devices
-receive the disarm command, they still update the last received command, but they do not perform any other action.
+receive the disarm command, they still update the last received command, but they do not perform any other action. The
+initial private key, $k_0$, is a \emph{disarm} key.
 
 The reason for interleaving two commands in this way is to prevent a specific attack scenario in which an attacker first
 observes a safety reset command being transmitted, and then at a later time gains access to a large load that could act
@@ -787,5 +786,5 @@ Source code and EDA designs are available at the public repository listed at the
 \center{
     \footnotesize
     \center{This is version \texttt{\input{version.tex}\unskip} of this paper, generated on \today.}
-}
+    \center{Source files and associated data for this work can be found in the git repository at the following URL: (URL elided for blind peer review)} }
 \end{document}