diff options
Diffstat (limited to 'ma/safety_reset.tex')
| -rw-r--r-- | ma/safety_reset.tex | 99 |
1 files changed, 96 insertions, 3 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex index dea5ceb..28dfa39 100644 --- a/ma/safety_reset.tex +++ b/ma/safety_reset.tex @@ -358,18 +358,111 @@ protection. Code secrecy should be of no concern\cite{schneier01} here but besid preferences about this due to fear of copyright infringement. \section{The theory of endpoint safety} +\label{sec_criteria} In order to gain anything by adding our reset controller to the smart meter's already complex design we must satisfy two -conditions. +interrelated conditions. \begin{enumerate} -\item \textbf{security} means our reset controller itself does not have any exploitable flaws -\item \textbf{safety} menas our reset controller will perform its job as intended +\item \textsc{security} means our reset controller itself does not have any remotely exploitable flaws +\item \textsc{safety} menas our reset controller will perform its job as intended \end{enumerate} +Note that our \textsc{security} property includes only remote exploitation, and excludes any form of hardware attack. +Even though most smart meters provide some level of physical security, we do not wish to make any assumptions on this. +In the following section we will elaborate our attacker model and it will become apparent that sufficient physical +security to defend against all attackers in our model would be infeasible, and thus we will design our overall system +to remain secure even assuming some number of physically compromised devices. % FIXME expand \subsection{Attack characteristics} +The attacker model these two conditions must hold under is as follows. We assume three angles of attack: Attacks by the +customer themselves, attacks by an insider within the metering systems controlling utility company and lastly attacks +from third parties. Examples for these third parties are hobbyist hackers or outside cyber-criminals on the one hand, +but also other companies participating in the smart grid infrastructure besides the utility company such as intermediary +providers of meter-reading services. + +Due to the critical nature of the electrical grid, we have to include hostile state actors in our attacker model. When +acting directly, these would be classified as third-party attackers by the above schema, but they can reasonably be +expected to be able to assume either of the other two roles as well e.g. through infiltration or bribery. +\textcite{fraunholz01} in their elaboration of their generalized attacker model give some classification of attackers +and provide a nice taxonomy of attacker properties. In their threat/capability rating, criminals are still considered +to have higher threat rating than state-sponsored attackers. The New York Times reported in 2016 that some states +recruit their hacking personnel in part from cyber-criminals. If this report is true, in a worst-case scenario we have +to assume a state-sponsored attacker to be the worst of both types. Comparing this against the other attacker types in +\textcite{fraunholz01}, this state-sponsored attacker is strictly worse than any other type in both variables. We are +left with a highly-skilled, very well-funded, highly intentional and motivated attacker. + +Based on the above classification of attack angles and our observations on state-sponsored attacks, we can adapt +\textcite{fraunholz01} to our problem, yielding the following new attacker types: + +\begin{enumerate} + \item \textbf{Utility company insiders controlled by a state actor} + We can ignore the other internal threats described in \textcite{fraunholz01} since an insider cooperating with a + state actor is strictly worse in every respect. + \item \textbf{State-sponsored external attackers} + A state actor can obviously directly attack the system through the internet. + \item \textbf{Customers controlled by a state actor} + A state actor can very well compromise some customers for their purposes. They might either physically + infiltrate the system posing as legitimate customers, or they might simply deceive or bribe existing customers + into cooperation. + \item \textbf{Regular customers} + Though a hostile state actor might gain control of some number of customers through means such as voluntary + cooperation, bribery, infiltration, they are limited in attack scale since they do not want to arouse premature + attention. Though regular customers may not have the motivation, skill or resources of a state-sponsored + attacker, potentially large numbers of them may try to attack a system out of financial incentives. To allow for + this possibility, we consider regular customers separate from state actors posing as customers in some way. +\end{enumerate} + +\subsection{Overall structural system security} +Considering overall security, we first introduce the \emph{reset authority}, a trusted party acting as the single +authority for issuing reset commands in our system. In practice this trusted party may be part of the utility company, +part of an external regulatory body or a hybrid setup requiring both to cooperate. We assume this party will be designed +to be secure against all of the above attacker types. The precise design of this trusted party is out of scope for this +work but we will list some practical suggestions on how to achieve security below. % FIXME do the list +% FIXME put up a large box on this limitation + +Using an asymmetric cryptographic design centered around the \emph{reset authority}, we rule out all attacks except for +denial-of-service attacks on our system by any of the four attacker types. All reset commands in our system originate +from the \emph{reset authority} and are cryptographically secured to provide authentication and tamper detection. +Under this model, attacks on the electrical grid components between the \emph{reset authority} and the customer device +degrade into man-in-the-middle attacks. To ensure the \textsc{safety} criterion from \ref{sec_criteria} holds we must +% FIXME check whether this \ref displays as intended +make sure our cryptography is secure against man-in-the-middle attacks and we must try to harden the system against +denial-of-service attacks by the attacker types listed above. Given our attacker model we cannot fully guard against +this sort of attack but we can at least choose a commmunication channel that is resilient against denial of service +attacks under the above model. + +Finally, we have to consider the issue of hardware security. We will solve the problem of physical attacks on some small +number of devices by simply not programming any secret information into these devices. This also simplifies hardware +production. From consideration in this work we explicitly rule out any form of supply-chain attack as +out-of-scope. +% FIXME include considerations on production testing somewhere (is the device working? is the right key programmed?) + \subsection{Complex microcontroller firmware} +The \textsc{security} property from \ref{sec_criteria} is in a large part reliant on the security of our reset +controller firmware. The best method to increase firmware security is to reduce attack surface by limiting external +interfaces as much as possible and by reducing code complexity as much as possible. +% FIXME formalize this as something like "Design Goal DG-023-42-1" ? +If we avoid the complexity of most modern microcontroller firmware we gain another benefit beyond implicitly reduced +attack surface: If the resulting design is small enough we may attempt formal verification of our security property. +Though formal verification tools are not yet suitable for highly complex tasks they are already barely adequate for +small amounds of code and simple interfaces. + \subsection{Modern microcontroller hardware} +Microcontrollers have gained enormously in both performance/efficiency as well as in peripheral support. Alas, these +gains have largely been driven by insatiable customer demand for faster, more powerful chips and for a long time +security has not been considered important outside of some specific niches such as smartcards. Traditionally a +microcontroller would spend its entire lifetime without ever being exposed to any networks. Though this trend has been +reversing with the increasing adoption of internet-of-things things % FIXME is this pun ok? +and more advanced security features have started appearing in general-purpose microcontrollers, most still lack even +basic functionality as far as computer security is concerned. + +One of the components lacking from most microcontrollers is strong memory protection or even a memory mapping unit as +it is found in all modern computer processors and SoCs for applications such as smartphones. Without an MPU/MPU some +mitigations for memory safety violations cannot be implemented. Thus it is very important to ensure memory safety in +microcontroller firmware through tools such as defensive coding, extensive testing and formal verification. + +%FIXME stopped writing here, continue + \subsection{Regulatory and economical constraints} \subsection{Safety vs. Security: Opting for restoration instead of prevention} \subsection{Technical outline of a safety reset} |