diff options
| -rw-r--r-- | ma/safety_reset.tex | 34 |
1 files changed, 19 insertions, 15 deletions
diff --git a/ma/safety_reset.tex b/ma/safety_reset.tex index 2aa27c8..a308910 100644 --- a/ma/safety_reset.tex +++ b/ma/safety_reset.tex @@ -779,23 +779,27 @@ flaw in Apple's iPhone SoC first-stage ROM bootloader\footnote{ flaw allows an attacker to circumvent these checks, booting code not authorized by Apple on a USB-connected iPhone, compromising Apple's chain of trust from ROM loader to userland right at its root. }, that allows a full compromise of any iPhone before the iPhone X. iPhone 8, one of the affected models, is still being -manufactured and sold by Apple today\footnote{ - i.e. at the time this paragraph was written, on %FIXME -}. In another instance, Samsung put a flaw in their secure-world firmware used for protection of sensitive credentials -in their mobile phone SoCs in % FIXME year % . -If both of these very large companies have trouble securing parts of their secure embedded software stacks measuring a -mere few hundred bytes in Apple's case or a few kilobytes in Samsung's, what is a smart electricity meter manufacturer +manufactured and sold by Apple until April 2020. In another instance in 2016 researchers found multiple flaws in the +secure-world firmware used by Samsung in their mobile phone SoCs. The flaws they found were both severe architectural +flaws such as secret user input being passed through untrusted userspace processes without any protection and shocking +cryptographic flaws such as CVE-2016-1919\footnote{\url{http://cve.circl.lu/cve/CVE-2016-1919}}\cite{kanonov01}. And +Samsung is not the only large multinational corporation having trouble securing their secure world firmware +implementation. In 2014 \textcite{rosenberg01} found an embarrassing integer overflow flaw in the low-level code +handling untrusted input in Qualcomm's QSEE firmware. For an overview of ARM TrustZone including a survey of academic +work and past security vulnerabilities of TrustZone-based firmware see \textcite{pinto01}. + +If all of these very large companies have trouble securing parts of their secure embedded software stacks measuring a +mere few hundred bytes in Apple's case or a few kilobytes in Qualcomm's, what is a smart electricity meter manufacturer to do? For their mass-market phones, these two companies have R\&D budgets that dwarf some countries' national budgets. -% FIXME hyperbole? -% FIXME cite -Since thorough formal verification of code is not yet within reach for either large-scale software development or -code heavy in side-effects such as embedded firmware or industrial control software\cite{pariente01} -the two most effective measures for embedded security is reducing the amount of code on one hand, and labour-intensively -checking and double-checking this code on the other hand. A smart electricity manufacturer does not have a say in the -former since it is bound by the official regulations it has to comply with, and will almost certainly not have sufficient -resources for the latter. -% TODO expand? +Since thorough formal verification of code is not yet within reach for either large-scale software development or code +heavy in side-effects such as embedded firmware or industrial control software\cite{pariente01} the two most effective +measures for embedded security is reducing the amount of code on one hand, and labour-intensively checking and +double-checking this code on the other hand. A smart electricity manufacturer does not have a say in the former since it +is bound by the official regulations it has to comply with, and will almost certainly not have sufficient +resources for the latter. We are left with an impasse: Manufacturers in this field likely do not have the saftey +resources to keep up with complex standards requirements. At the same time they have no option to reduce the scope of +their implementation to alleviate the burden on firmware security. \subsection{Attack avenues in the smart grid} |