summaryrefslogtreecommitdiff
path: root/ma/safety_reset.tex
diff options
context:
space:
mode:
Diffstat (limited to 'ma/safety_reset.tex')
-rw-r--r--ma/safety_reset.tex84
1 files changed, 67 insertions, 17 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex
index c50865f..3ac83e2 100644
--- a/ma/safety_reset.tex
+++ b/ma/safety_reset.tex
@@ -1674,8 +1674,54 @@ least significant bit of $n$ in our $H^n$ construction. In the chain of valid si
disarm signature. Reset and disarm signatures would alternate in this scheme. By skipping a disarm signature two resets
can still be triggered directly after one another.
-% FIXME diagram
-% FIXME include domain mechanism
+In practice it may be useful to have some control over which particular meters reset. An attack exploiting a particular
+network protocol implementation flaw might only affect one series of meters made by one manufacturer. Resetting
+\emph{all} meters may be too much in this case. A simple solution for this is to define adressable subsets of meters.
+``All meters'' along with ``meters made by manufacturer $x$'' and ``meters of model $y$'' are good choices for such
+scopes. On the cryptographic level the protocol state is simply duplicated for each scope. This incurs memory and
+computation overhead linear in the number of scopes. Device memory requirements are small at a few bytes only and
+computation is of no concern due to the very slow channel so this simple solution is adequate. The transmitter has to
+either store copies of all scope's keys or derive these keys from a root key using the scope's identifier. Keys are
+small and the transmitter would be using a regular server or hardware security module so either easily feasible.
+
+A diagram of the key structure in this key management scheme is shown in Figure \ref{fig:sig_key_chain}. The
+transmitter key management is shown in Figure \ref{fig:tx_scope_key_illu}. This scheme is simplistic but suffices for
+our prototype in Section \ref{sec-prototype} and may even be useful in a practical implementation. During
+standardization of a safety reset system the key management system would most likely have to be customized to the
+particular application's requirements. Developing an universal solution is outside the scope of this work.
+\begin{figure}
+ \centering
+ \begin{minipage}[c]{0.5\textwidth}
+ \includegraphics{resources/signature_key_chain}
+ \end{minipage}
+ \begin{minipage}[c]{0.45\textwidth}
+ \caption{
+ The hash chain between secret transmitter key and public device key. Each step represents one invocation of the
+ hash function. To generate a new chain a random transmitter key is generated, then hashed $n$ times to
+ generate the corresponding device key. A new trigger message can be generated by generating the key at depth
+ $m-1$ where $m$ is the height of the last used trigger, or $n$ initially. Every second trigger message is a
+ disarm message and every second one a reset message. Depending on which is needed the other one may be skipped.
+ }
+ \label{fig:sig_key_chain}
+ \end{minipage}
+\end{figure}
+
+\begin{figure}
+ \centering
+ \includegraphics{resources/transmitter_scope_key_illustration}
+ \caption{
+ An illustration of a key management system using a shared master key. The transmitter derives one secret key for
+ each adressable group from the master key. Then public device keys are generated like in Figure
+ \ref{fig:sig_key_chain}. Finally for each device the manufacturer picks the group public keys matching the
+ device. In this example one device is a series A meter made by manufacturer B so it gets provisioned with the
+ keys for the ``all devices'', ``manufacturer B'' and ``series A'' keys. The other device is also made by
+ manufacturer B but is a series C device so it gets provisioned with the ``all devices'', ``manufacturer B'' and
+ ``series C'' public device keys. In this example the transmitter stores (or is able to derive) all six shown
+ group keys, but each device only needs to store the three applying to it for the three scopes ``all devices'',
+ ``manufacturer'' and ``series''.
+ }
+ \label{fig:tx_scope_key_illu}
+\end{figure}
\chapter{Practical implementation}
@@ -1702,12 +1748,11 @@ transmission networks to characterize the operational state of the network.
From a superficial viewpoint measuring mains frequency might seem like a simple problem. Take the mains voltage
waveform, measure time between two rising-edge (or falling-edge) zero-crossings and take the inverse $f = t^{-1}$. In
-practice, phasor measurement units are significantly more complex than this. This discrepancy is due to the unhealthy
-% FIXME is this pun ok?
-combination of both high precision and quick response that is demanded from these units. High precision is necessary
-since variations of mains frequency under normal operating conditions are quite small--in the range of
-\SIrange{5}{10}{\milli\hertz} over short intervals of time. Relative to the nominal \SI{50}{\hertz} this is a derivation of
-less than \SI{100}{ppm} Relative to the corresponding \SI{20}{\milli\second} period that means a time derivation of
+practice, phasor measurement units are significantly more complex than this. This discrepancy is due to the combination
+of both high precision and quick response that is demanded from these units. High precision is necessary since
+variations of mains frequency under normal operating conditions are quite small--in the range of
+\SIrange{5}{10}{\milli\hertz} over short intervals of time. Relative to the nominal \SI{50}{\hertz} this is a derivation
+of less than \SI{100}{ppm} Relative to the corresponding \SI{20}{\milli\second} period that means a time derivation of
about $2 \mu\text{s}$ from cycle to cycle. From this it is already obvious why a simplistic measurement cannot yield the
required precision for manageable averaging times--we would need either a ADC sampling rate in the order of megabits or
for a reconstruction through interpolated readings an impractically high ADC resolution.
@@ -2077,7 +2122,7 @@ gold code looks to yield good enough performance at manageable data rates.
\begin{figure}
\centering
- \includegraphics{../lab-windows/fig_out/dsss_gold_nbits_overview}
+ \includegraphics[width=0.6\textwidth]{../lab-windows/fig_out/dsss_gold_nbits_overview}
\caption{
Symbol Error Rate (SER) as a function of transmission amplitude. The line represents the mean of several
measurements for each parameter set. The shaded areas indicate one standard deviation from the mean. Background
@@ -2095,14 +2140,18 @@ gold code looks to yield good enough performance at manageable data rates.
\begin{figure}
\centering
- \includegraphics{../lab-windows/fig_out/dsss_gold_nbits_sensitivity}
- \caption{
- Amplitude at a SER of 0.5\ in mHz depending on symbol length. Here we can observe an increase of sensitivity
- with increasing symbol length, but we can clearly see diminishing returns above 6 bit (63 chips). Considering
- that each bit roughly doubles overall transmission time for a given data length it seems lower bit counts are
- preferrable if the necessary transmitter power can be realized.
- }
- \label{dsss_gold_nbits_sensitivity}
+ \begin{minipage}[c]{0.5\textwidth}
+ \includegraphics{../lab-windows/fig_out/dsss_gold_nbits_sensitivity}
+ \end{minipage}
+ \begin{minipage}[c]{0.45\textwidth}
+ \caption{
+ Amplitude at a SER of 0.5\ in mHz depending on symbol length. Here we can observe an increase of sensitivity
+ with increasing symbol length, but we can clearly see diminishing returns above 6 bit (63 chips). Considering
+ that each bit roughly doubles overall transmission time for a given data length it seems lower bit counts are
+ preferrable if the necessary transmitter power can be realized.
+ }
+ \label{dsss_gold_nbits_sensitivity}
+ \end{minipage}
\end{figure}
\subsection{Sensitivity versus peak detection threshold factor}
@@ -2239,6 +2288,7 @@ the results for both are very close in absolute value.
\end{figure}
\section{Implementation of a demonstrator unit}
+\label{sec-prototype}
To demonstrate the viability of our reset architecture we decided to implement a demonstrator system. In this
demonstrator we use JTAG to reset part of a commodity smart meter from an externally-connected reset controller. The