Few last fixes
This commit is contained in:
parent
2fd97644bd
commit
fe9fd3db96
1 changed files with 18 additions and 19 deletions
|
|
@ -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}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue