From 0908130e6fc412a0586357cd35aad24144d0b96c Mon Sep 17 00:00:00 2001 From: jaseg Date: Thu, 7 May 2020 12:46:27 +0200 Subject: ma: add figures, add some blurb on demonstrator --- ma/safety_reset.bib | 22 +++++ ma/safety_reset.tex | 235 +++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 238 insertions(+), 19 deletions(-) diff --git a/ma/safety_reset.bib b/ma/safety_reset.bib index f4496e0..b2358cd 100644 --- a/ma/safety_reset.bib +++ b/ma/safety_reset.bib @@ -952,4 +952,26 @@ url = {https://www.bmwi.de/Redaktion/DE/Publikationen/Studien/digitalisierung-der-energiewende-thema-1.pdf?__blob=publicationFile&v=4}, } +@Misc{easymeter01, + author = {{EasyMeter GmbH}}, + date = {2020}, + title = {Datenblatt Moderne Messeinrichtung Q3A Drehstromzähler}, +} + +@Misc{honeywell01, + author = {{Honeywell Smart Energy}}, + date = {2017}, + title = {Datasheet Honeywell REX2 smart meter}, + url = {https://www.elstersolutions.com/assets/products/products_elster_files/SEADSNAEN001017REX2.pdf}, +} + +@WWW{ifixit01, + author = {Miro Djuric}, + date = {2011}, + title = {Elster REX2 Smart Meter Teardown}, + url = {https://www.ifixit.com/News/14306/elster-rex2-smart-meter-teardown}, + organization = {iFixit}, + urldate = {2020-05-06}, +} + @Comment{jabref-meta: databaseType:biblatex;} diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex index 56dc541..8f8c956 100644 --- a/ma/safety_reset.tex +++ b/ma/safety_reset.tex @@ -55,7 +55,6 @@ \usepackage[draft=false,babel,tracking=true,kerning=true,spacing=true]{microtype} % optischer Randausgleich etc. % For german quotation marks -\newcommand{\foonote}[1]{\footnote{#1}} \newcommand{\degree}{\ensuremath{^\circ}} \newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}} @@ -759,6 +758,7 @@ Error correcting codes are a very broad field with many options for specializati more than a prototype in this thesis we chose to not expend resources on optimization too much and settled for a comparatively simple low-density parity check code. The state of the art has advanced considerably since the discovery of general LDPC codes. %FIXME cite +% FIXME LDPC is old, new is Reed-Solomon! The main areas of improvement are overhead and decoding speed. Since transmission length % FIXME have we defined this yet? in our system limits system response time but we do not have a fixed target there we can tolerate some degree of sub-optimal overhead. % FIXME get actual pröper numbers on our stuff vs. some state of the art citations. @@ -770,6 +770,7 @@ or C++ implementation that we can adapt to embedded firmware. LDPC codes are a p error-correcting codes and we had no particular difficulty finding either. \subsection{Cryptographic security} +\label{sec-crypto} Informally the system we are looking for can be modelled as consisting of three parties: The trusted \textsc{Transmitter}, one of a large number of untrusted \textsc{Receivers}, and an \textsc{Attacker}. These three play @@ -1247,13 +1248,8 @@ applying it to the test waveforms from \textcite{wright01}. In this test we got \label{freq_meas_rocof_reference} \end{figure} -% Easymeter teardown fixmes: -% FIXME include board composite img -% FIXME include xray composite -% FIXME include channel xray -% FIXME include power supply xray - \section{Channel simulation and parameter validation} +\label{sec-ch-sim} To validate all layers of our communication stack from modulation scheme to cryptography we built a prototype implementation in python. Implementing all components in a high-level language builds up familiartiy with the concepts @@ -1342,15 +1338,13 @@ indicates SER is related fairly monotonically to the signal-to-noise margins ins \end{figure} \begin{figure} - \begin{subfigure}{\textwidth} - \centering - \includegraphics{../lab-windows/fig_out/dsss_thf_amplitude_5678} - \label{dsss_thf_amplitude_5678} - \caption{ - \footnotesize SER vs.\ amplitude graph similar to fig.\ \ref{dsss_gold_nbits_overview} with dependence on - threshold factor color-coded. Each graph shows traces for a single DSSS symbol length. - } - \end{subfigure} + \centering + \includegraphics{../lab-windows/fig_out/dsss_thf_amplitude_5678} + \caption{ + SER vs.\ amplitude graph similar to fig.\ \ref{dsss_gold_nbits_overview} with dependence on threshold factor + color-coded. Each graph shows traces for a single DSSS symbol length. + } + \label{dsss_thf_amplitude_5678} \end{figure} \begin{figure} \ContinuedFloat @@ -1446,13 +1440,209 @@ indicates SER is related fairly monotonically to the signal-to-noise margins ins \section{Implementation of a demonstrator unit} %FIXME +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 +reset controller receives its commands over the grid frequency modulation system we outlined in this thesis. To keep +implementation cost low the reset controller is fed a simulation of a modulated grid frequency signal through a standard +\SI{3.5}{\milli\meter} audio jack\footnote{ + By generously cutting two PCB traces the meter we chose to use can be easily modified to provide strong galvanic + separation between grid and main application microcontroller. With this modification we have to supply power to its + main application MCU externally along with the JTAG interface. +}. + +\subsection{Selecting a smart meter for demonstration purposes} + +For our demonstrator to make sense we wanted to select a realistic reset target. In Germany where this thesis was +written a standards-compliant setup would consist of a fairly dumb smart meter and a smart meter gateway (SMGW) +containing all of the complex bidirectional protocol logic such as wireless or landline IP connectivity. The realistic +target for a setup in this architecture would be the components of an SMGW such as its communications modem or main +application processor. In the German architecture the smart meter does not even have to have a bi-directional data link +to the SMGW effectively mitigating any attack vector for remote compormise. + +Despite these considerations we still chose to reset the application MCU inside smart meter for two reasons. One is that +SMGWs are much harder to come by on the second-hand market. The other is that SMGWs are a particular feature of the +German standardization landscape and in many other countries the functions of an SMGW are integrated into the meter +itself. % FIXME citation + +In the end we settled on an Q3DA1002 three-phase 60A meter made by German manufacturer EasyMeter. This meter is typical +of what would be found in an average German household and can be acquired very inexpensively as new old stock on online +marketplaces. + +The meter consists of a plastic enclosure with a transparent polycarbonate top part and a grey ABS bottom part that are +ultrasonically welded shut. In the bottom part of the case a PCB we call the \emph{measurement} board is potted in +epoxide resin (see fig.\ \ref{easymeter_composites}). This PCB contains three separate energy measurement ASICs for the +three phases (see fig.\ \ref{easymeter_detail_xrays}). It also contains a capacitive dropper power supply for the meter +circuitry and external modules such as a SMGW. The measurement board through three infrared links (one per phase) +communicates with a smaller unpotted PCB we call the \emph{display} board in the top of the case. This PCB handles +measurement logging and aggregation, controls a small segment LCD displaying totals and handles the externally +accessible \si{\kilo\watt\hour} impulse LED and serial IR links. + +The measurement board does not contain any logging or outside communication interfaces. All of that is handled on the +display board by a Texas Instruments MSP430F2350 application MCU. This is a 16-bit RISC MCU with \SI{16}{\kilo\byte} +flash and \SI{2}{\kilo\byte} SRAM\footnote{ + The microcontroller might seem a bit overkill for such a simple application, but most of its \SI{16}{\kilo\byte} + program flash is in fact used. A casual glance with Ghidra shows that a large part of program flash is expended on + keeping multiple redundant copies of energy consumption aggregates including error recovery in case of data + corruption and some effort has even been made to guard against data corruption using simple non-cryptographic + checksums. Another large part of the MCU's firmware handles data transmission over the meter's externally accessible + IR link through Smart Message Language\cite{bsi-tr-03109-1-IVb}. +}. There is an I2C EEPROM that is used in conjunction with the microcontroller's internal \SI{256}{\byte} data flash to +keep redundant copies of energy consumption aggregates. On the side of the base board is a 14-pin header containing both +a standard TI MSP430 JTAG pinout and an UART serial link for debugging. Conveniently the JTAG port was left enabled by +fuse in our particular production unit. + +We chose to use this MSP430 series application MCU as our reset target. Though in this particular unit compromise is +impossible due to a lack of bi-directional communication links some of its sister models do contain bidirectional +communication links\cite{easymeter01} making compromise through communication interfaces at least a theoretical +possibility. In other countries meters with a similar architecture to the Q3DA1002 commonly include complex protocol +logic as part of the meter itself\cite{honeywell01,ifixit01}. As an example, the Honeywell REX2 uses a Maxim Integrated +71M6541 main application microcontroller along with a Texas Instruments CC1000 series radio transceiver and is +advertised to support both over-the-air firmware upgrades and a remotely accessible ``service control switch''. + +\begin{figure} + \centering + \begin{subfigure}{\textwidth} + \centering + \includegraphics[width=0.6\textwidth]{resources/easymeter_board_composite.jpg} + \label{easymeter_display_board_composite} + \caption{ + \footnotesize + Optical composite image of the display and data logging board in the top of the case. The six pins at the + top are the SPI chip-on-glass segment LCD. Of the eight pads on the left six are unused and two carry the + auxiliary power supply from the measurement board below. The bottom right section contains the + \si{\kilo\watt\hour} impulse LED and the angled IR communication LED. The flying wires + connect to the 14-pin JTAG and serial debug header. + } + \end{subfigure} + \begin{subfigure}{\textwidth} + \vspace{1cm} + \centering + \includegraphics[width=0.8\textwidth]{resources/easymeter_baseboard_composite.jpg} + \label{easymeter_measurement_board_composite} + \caption{ + \footnotesize + Composite microfocus x-ray image of the potted measurement module in the bottom of the case. The ovals on + the top left and right are power supply and data jumper connections for external modules such as SMGW + interfaces. The bright parts at the bottom are the massive screw terminals with integrated current shunts. + The circuitry right of the three independent measurement channels is the power supply circuit for the + display board. + } + \end{subfigure} + + \caption{ + Composite images of the circuit boards inside the EasyMeter Q3DA1002 "smart" electricity meter used in our + demonstration. + } + \label{easymeter_composites} +\end{figure} + +\begin{figure} + \centering + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\textwidth]{resources/easymeter_baseboard_channel.jpg} + \label{easymeter_channel_xray} + \caption{Microfocus x-ray of one channel's data acquisition circuit} + \end{subfigure}\hspace*{5mm} + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\textwidth]{resources/easymeter_baseboard_powersupply.jpg} + \label{easymeter_powersupply_xray} + \caption{Microfocus x-ray of the auxiliary power supply} + \end{subfigure} + + \caption{ + Microfocus x-rays of major sections of the EasyMeter Q3DA1002 measurement board + } + \label{easymeter_detail_xrays} +\end{figure} + +\subsection{Firmware implementation} +We based our safety reset demonstrator firmware on the grid frequency sensor firmware we developed in sec.\ +\ref{sec-fsensor}. We implemented DSSS demodulation by translating the python prototype code we developed in sec.\ +\ref{sec-ch-sim} to embedded C code. After validating the C translation in extensive simulations we integrated our code +with a reed-solomon implementation and a libsodium-based implementation of the cryptographic protocol we designed in +sec.\ \ref{sec-crypto}. % FIXME WIP + +To reprogram the target MSP430 microcontroller we ported over the low-level bitbang JTAG driver of +mspdebug\footnote{\url{https://github.com/dlbeer/mspdebug}}. + +For all computation-heavy high-level modules of our firmware such as the DSSS demodulator or the grid frequency +estimator we wrote test fixtures that allow the same code that runs on the microcontroller to be executed on the host +for testing. These test fixtures are very simple C programs that load input data from a file or the command line, run +the algorithm and print results on standard output. + +\section{Grid frequency modulation emulation} +To emulate a modulated grid frequency signal we superimposed a DSSS-modulated signal at the proper amplitude with +synthetic grid frequency noise generated according to the measurements we took in sec. \ref{sec-fsensor}. In this +primitive simulation we do not simulate the precise impulse response of the grid to a DSSS-modulated stimulus signal. +Our results still serve to illustrate the possibility of data transmission in this manner this impulse response can be +compensated for at the transmitter by selecting appropriate modulation parameters (e.g. chip rate and amplitude) and at +the receiver by equalization with a matched filter. + \section{Experimental results} - %FIXME +% FIXME \section{Lessons learned} - %FIXME +Before settling on the commercial smart meter we first tried to use an EVM430-F6779 smart meter evaluation kit made by +Texas Instruments. This evaluation kit did not turn out well for two main reasons. One, it shipped with half the case +missing and no cover for the terminal blocks. Because of this some work was required to maintain electrical safety. +Even after mounting it in an electrically safe manner since the main MCU is not isolated from the grid and the JTAG port +is also galvanically coupled the safety reset controller prototype would also have to be galvanically isolated to not +pose an electrical safety risk. The second issue we ran into was that the EVM430-F6779 is based around an MSP430F6779 +microcontroller. This microcontroller is a rather large part within the MSP430 series and uses a particularly new +revision of the CPU core and associated JTAG peripheral that are incompatible with all MSP430 programmers we tried to +use on it. mspdebug does not have support for it and porting TI's own JTAG programmer reference sources did not yield +any results either. Finally we tried an USB-based programmer made by TI themselves that turned out to either have broken +firmware or a hardware defect, leading to it frequently re-enumerating on the USB. + +Overall our initial assumption that a development kit would certainly be easier to program than a commercial meter did +not prove to be true. Contrary to our expectations the commercial meter had JTAG enabled allowing us to easily read out +its stock firmware without needing to reverse-engineer vendor firmware update files or circumventing code protection +measures. The fact that its firmware was only available in its compiled binary form was not much of a hindrance as it +proved not to be too complex and all we wanted to know could be found out with just a few hours of digging in Ghidra. + +In the firmware development phase our approach of testing every module individually (e.g. DSSS demodulator, Reed-Solomon +decoder, grid frequency estimation) proved to be very useful. In particular debugging benefited greatly from being able +to run a couple thousand tests within seconds. In case of our DSSS demodulator this modular testing and simulation +architecture allowed us to simulate many thousand runs of our implementation on test data and directly compare it to our +Jupyter/Python prototype (see fig.\ \ref{fw_proto_comparison}). Since we spent more time polishing our embedded C +implementation it turned out to perform much better than our initial python prototype. At the same time it shows +fundamentally similar response to its parameters. One significant bug we fixed in the embedded C version is the python +version's tendency towards incorrect decodings at even very large amplitudes. + +\begin{figure} + \centering + \begin{subfigure}{\textwidth} + \centering + \includegraphics[trim={0 4cm 0 0},clip]{../lab-windows/fig_out/dsss_thf_amplitude_56_jupyter_impl} + \caption{Python prototype} + \end{subfigure} + \begin{subfigure}{\textwidth} + \centering + \includegraphics[trim={0 4cm 0 0},clip]{../lab-windows/fig_out/dsss_thf_amplitude_56_fw_impl} + \caption{Embedded C implementation} + \end{subfigure} + + \caption{ + Symbol error rate plots versus threshold factor for both our python prototype (above) and our firmware + implementation of our demodulation algorithm. Note the slightly different threshold factor color scales. Cf.\ + fig.\ \ref{dsss_thf_amplitude_5678}. + } + \label{fw_proto_comparison} +\end{figure} + +In accordance with our initial estimations we did not run into any code space nor computation bottlenecks for chosing +floating-point emulation instead of porting over our algorithms to fixed-point calculations. The extremely slow sampling +rate of our systems makes even heavyweight processing such as FFT or our rather brute-force dynamic programming approach +to DSSS demodulation possible well within performance constraints. +Compiled code size of our firmware implementation is slightly larger than we would like at around \SI{64}{\kilo\byte} +for our firmware image including everything except the target microcontroller firmware image. See appendix +\ref{symbol_size_chart} for a graph illustrating the contribution of various parts of the signal processing toolchain to +this total. Overall the most heavy-weight operations by far are the SHA512 implementation from libsodium and the FFT +from ARM's CMSIS signal processing library. \chapter{Future work} \section{Technical standardization} @@ -1553,12 +1743,19 @@ correctly configure than it is to simply use separate hardware and secure the in %\includenotebook{Frequency sensor clock stability analysis}{gps_clock_jitter_analysis} %\includenotebook{DSSS modulation experiments}{dsss_experiments-ber} -\chapter{Demonstrator schematics and code} +\chapter{Demonstrator Resources} +\section{schematics and code} +% FIXME + +\chapter{Demonstrator Firmware Symbol Sizes} +\label{symbol_size_chart} +\includepdf[fitpaper]{resources/safetyreset-symbol-sizes.pdf} \chapter{Economic viability of countermeasures} \section{Attack cost} \section{Countermeasure cost} + % FIXME maybe include a standard for the technical side of a safety reset system here, e.g. in the style of an IETF draft? \end{document} -- cgit