diff options
Diffstat (limited to 'ma/safety_reset.tex')
| -rw-r--r-- | ma/safety_reset.tex | 85 |
1 files changed, 74 insertions, 11 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex index 28dfa39..5d25e8a 100644 --- a/ma/safety_reset.tex +++ b/ma/safety_reset.tex @@ -454,17 +454,22 @@ security has not been considered important outside of some specific niches such 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. +basic functionality found in processors for computers or smartphones. 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 +mitigations for memory safety violations cannot be implemented. This and the absence of virtualization tools such as +ARM's TrustZone make hardening microcontroller firmware a big task. 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 +In our design we achieve simplicity on two levels: One, we isolate the very complex metering firmware from our reset +controller by having both run on separate microcontrollers. Two, we keep the reset controller firmware itself extremely +simple to reduce attack surface there. \subsection{Regulatory and economical constraints} \subsection{Safety vs. Security: Opting for restoration instead of prevention} + + \subsection{Technical outline of a safety reset} \section{Communication channels on the grid} @@ -502,23 +507,79 @@ microcontroller firmware through tools such as defensive coding, extensive testi \chapter{Future work} \section{Technical standardization} +The description of a safety reset system provided in this work could be translated into a formalized technical standard +with relatively low effort. Our system is very simple compared to e.g. a full smart meter communication standard and +thus can conceivably be described in a single, concise document. The much more complicated side of standardization would +be the standardization of the backend operation including key management, coordination and command authorization. + \section{Regulatory adoption} +Since the proposed system adds significant cost and development overhead at no immediate benefit to either consumer or +utility company it is unlikely that it would be adopted voluntarily. Market forces limit what long-term planning utility +companies can do. An advanced mitigation such as this one might be out of their reach on their own and might require +regulatory intervention to be implemented. To regulatory authorities a system such as this one provides a powerful +primitive to guard against attacks. Due to the low-level approach our system might allow a regulatory authority to +restore meters to a safe state without the need of fine-grained control of implementation details such as application +network protocols. + +A regulatory authority might specify that all smart meters must use a standardized reset controller that on command +resets to a minimal firmware image that disables external communication, continues basic billing functions and enables +any disconnect switches. This system would enable the \emph{reset authority} to directly preempt a large-scale attack +irrespective of implementation details of the various smart meter implementations. + +Cryptographic key management for the smart reset system is not much different to the management of highly privileged +signing keys as they are used in many other systems already. If the safety reset system is implemented with a +regulatory authority as the \emph{reset authority} they would likely be able to find a public entity that is already +managing root keys for other government systems to also manage safety reset keys. Availability and security requirements +of safety reset keys do not differ significantly from those for other types of root keys. + \section{Practical implementation} + + \section{Zones of trust} In our design, we opted for a safety reset controller % FIXME is "safety reset" the proper name here? We need some sort of branding, but is this here really about "safety"? in form of a separate micocontroller entirely separate from whatever application microcontroller the smart meter design -is already using. - -This design nicely separates the meter into an untrusted application (the core microcontroller) and the trusted reset -controller. Since the interface between the two is simple and logically one-way, it can be validated to a high standard -of security. +is already using. This design nicely separates the meter into an untrusted application (the core microcontroller) and +the trusted reset controller. Since the interface between the two is simple and logically one-way, it can be validated +to a high standard of security. Despite these security benefits, the cost of such a separate hardware device might prove high in a mass-market rollout. In this case, one might attempt to integrate the reset controller into the core microcontroller in some way. Primarily, -there would be two ways to accomplish this. -% separate die/submodule -% trustzone +there would be two ways to accomplish this. One is a solution that physically integrates an additional microcontroller +core into the main application microcontroller package either as a submodule on the same die or as a separate die in a +multi-chip module (MCM) with the main application microcontroller. A full-custom solution integrating both on a single +die might be a viable path for very large-scale deployments, but will most likely be too expensive in tooling costs +alone to justify its use. More likely for a medium- to large-scale deployment (millions of meters) would be a MCM +integrating an off-the-shelf smart metering microcontroller die with the reset controller running on another, much +smaller off-the-shelf microcontroller die. This solution might potentially save some cost compared to a solution using a +discrete microcontroller for the reset controller. + +The more likely approach to reducing cost overhead of the reset controller would be to employ virtualization +technologies such as ARM's TrustZone in order to incorporate the reset controller firmware into the application firmware +on the same chip without compromising the reset controller's security or disturbing the application firmware's +operation. + +TrustZone is a virtualization technology that provides a hardware-assisted privileged execution domain on at least one +of the microcontrollers cores. In traditional virtualization setups a privileged hypervisor is managing several +unprivileged applications sharing resources between them. Separation between applications in this setup is longitudinal +between adjacent virtual machines. Two applications would both be running in unprivileged mode sharing the same cpu and +the hypervisor would merely schedule them, configure hardware resource access and coordinate communication. This +longitudinal virtualization simplifies application development since from the application's perspective the virtual +machine looks very similar to a physical one. In addition, in general this setup reciprocally isolates two applications +with neither one being able to gain control over the other. + +In contrast to this, a TrustZone-like system in general does not provide several application virtual machines and +longitudinal separation. Instead, it provides lateral separation between two domains: The unprivileged application +firmware and a privileged hypervisor. Application firmware may communicate with the hypervisor through defined +interfaces but due to TrustZone's design it need not even be aware of the hypervisor's existence. This makes a perfect +fit for our reset controller. The reset controller firmware would be running in privileged mode and without exposing any +communication interfaces to application firmware. The application firmware would be running in unprivileged mode +without any modification. The main hurdles to the implementation to a system like this are the requirement for a +microcontroller providing this type of virtualization on the one hand and the complexity of correctly employing this +virtualization on the other hand. Virtualization systems such as TrustZone are still orders of magnitude more complex to +correctly configure than it is to simply use separate hardware and secure the interfaces in between. + +\chapter{Conclusion} \newpage \appendix @@ -539,4 +600,6 @@ there would be two ways to accomplish this. \chapter{The ethics and security implications of centralized crackdown on energy theft} +% 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} |