diff --git a/chapter-epa/chapter.tex b/chapter-epa/chapter.tex index a5d9315..7859ebc 100644 --- a/chapter-epa/chapter.tex +++ b/chapter-epa/chapter.tex @@ -114,9 +114,10 @@ unclear on the exact mechanism of key derivation, in previous versions of the st random salt, and the healthcare ID number of the enrolled person was used in SHA256-HKDF. The specification requires that a new root key is generated once a year, but as far as we can tell, record key rollover is not done automatically but is only meant to be done when the \emph{user} requests it, and old root keys must be retained forever to ensure old -records can be accessed. +records can be accessed. Through this lack of automatic key rollover combined with the need to retain root keys +indefinitely, attack surface is maximized and incremental compromises of the system over long time spans become possible. -\subsection{Related Work} +\subsection{Previous Analyses} \emph{gematik}, the state-owned company specifying the system, commissioned several security assessments of the system relating to the key escrow service. @@ -158,12 +159,14 @@ surface \cite{ Our first concern is the system's general approach of using a key escrow service instead of securely storing the keys inside the system's already existing smart card infrastructure. Like any other key escrow system, this key escrow -service poses a centralized security risk. The system's designers made this decision since it was deemed important that -access to an encrypted record can be restored quickly after an insurance ID card is lost, without requiring the +service poses a centralized security risk. The system's designers made this decision since it was considered important +that when an encrypted record must be restored after an insurance ID card is lost, it can be re-created without the cooperation of the healthcare providers holding the primary copies of the person's medical records. \subsection{Cryptographic Design} +\todo{Feedback from HS3 reviewer: I feel that this section is a mix-up of critique on the cryptographic design and the + approach to privacy protection and data minimisation. How are they linked? I'm missing some discussion here.} The system's overall cryptographic design is intentionally kept simple. The standard explicitly mentions that symmetric primitives have been preferred over asymmetric primitives in the core key escrow functions due to the risk of an attack on asymmetric primitives in the long term. Notably, other advanced cryptographic techniques such as secret sharing @@ -178,19 +181,16 @@ For instance, the system leaks a person's insurance ID number to the key escrow requested. Along with the timing and frequency of these requests, this leaks information on the person's condition to the key escrow service in an identifiable way. -% TODO I feel that this section is a mix-up of critique on the cryptographic design and the approach to privacy -% protection and data minimisation. How are they linked? I'm missing some discussion here. - \subsection{A Realistic Attacker Model} -We observe that the system as a whole does not appear to be designed to defend against well-resourced adversaries. The -series of practical attacks that have been demonstrated on the system confirm this impression. In -\textcite{tschirsichKonnteBisherNoch2024} summarize a series of successful attacks. Attacks include social engineering -resulting in access to copies of smartcards enabling accessing patient records, using misconfigured Konnektor VPN -appliances with their LAN DMZ and authentication interface exposed on the public internet, circumventing video-based -authentication processes resulting in duplicate file keys being provided, classis SQL injection on a backend service -maintaining an authentication database, accessing all national patient records through brute-force enumeration of weak -identifiers, and several more. +We observe that the system as a whole does not appear to be designed to defend against well-resourced adversaries. A +series of demonstrated practical attacks on the system, none of which required advanced capabilities, confirm this +impression. In \textcite{tschirsichKonnteBisherNoch2024} summarize a series of successful attacks. Attacks include +social engineering resulting in access to copies of smartcards enabling accessing patient records, using misconfigured +Konnektor VPN appliances with their local network DMZ and authentication interface exposed on the public internet, +circumventing video-based authentication processes resulting in duplicate file keys being provided, classis SQL +injection on a backend service maintaining an authentication database, accessing all national patient records through +brute-force enumeration of weak identifiers, and several more. We believe that a system like this must be designed to withstand well-resourced adversaries such as foreign secret services, since the medical data stored in such as information on chronic illness, sexually transmittable disease or @@ -207,19 +207,20 @@ the extraction of any patient records being processed in plaintext inside these Physical security has received some consideration in the system's specification. First, smart cards are used extensively for authentication. Second, Hardware Security Modules are used in key locations of the system to process some -cryptographic secrets. The core of the system's key escrow service is implemented inside an HSM. However, it is notable -that the actual security level required for this HSM is only FIPS 140-2 level 3 -\cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}. FIPS 140-2 is a US government -standard that used to be popular for the specification of HSMs. However, not only has FIPS 140-2 been made obsolete by -FIPS 140-3 in 2019 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2019}, its security -level 3 mostly provides logical separation of cryptographic functions from other logic and is not very meaningful in the -context of physical attacks. The only physical requirement of FIPS 140-2 level 3 is that the HSM has a hard, opaque -coating. This coating is specified to be tamper-evident, but notably no active tamper detection or response features are -required by this standard~\cite{andersonSecurityEngineeringGuide2020}. In contrast to the newer FIPS 140-3 standard and -the related ISO/IEC 19790 \cite{ISOIEC19790} as well as ISO/IEC 24759 \cite{ISOIEC24759} standards, FIPS 140-2 does not -make any particular requirements regarding resistance to side-channel attacks. The lack of tamper response, unspecified -resistance to side-channel attacks and the fact that the ePA specification only requires the long-lived key escrow root -key inside the HSM to have 256 bits of entropy lead to an unsatisfactory overall constellation. +cryptographic secrets. The core of the system's key escrow service is implemented inside an HSM that is part of a +redundant HSM cluster. However, it is notable that the actual security level required for this HSM is only FIPS 140-2 +level 3 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}. FIPS 140-2 is a US +government standard that used to be popular for the specification of HSMs. However, not only has FIPS 140-2 been made +obsolete by FIPS 140-3 in 2019 \cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2019}, +its security level 3 mostly provides logical separation of cryptographic functions from other logic and is not very +meaningful in the context of physical attacks. The only physical requirement of FIPS 140-2 level 3 is that the HSM has a +hard, opaque coating. This coating is specified to be tamper-evident, but notably no active tamper detection or response +features are required by this standard~\cite{andersonSecurityEngineeringGuide2020}. In contrast to the newer FIPS 140-3 +standard and the related ISO/IEC 19790 \cite{ISOIEC19790} as well as ISO/IEC 24759 \cite{ISOIEC24759} standards, FIPS +140-2 does not make any particular requirements regarding resistance to side-channel attacks. The lack of tamper +response, unspecified resistance to side-channel attacks and the fact that the ePA specification only requires the +long-lived key escrow root key inside the HSM to have 256 bits of entropy lead to an unsatisfactory overall +constellation. \section{Conclusion} diff --git a/chapter-introduction/chapter.tex b/chapter-introduction/chapter.tex index a296b9c..f49a3f2 100644 --- a/chapter-introduction/chapter.tex +++ b/chapter-introduction/chapter.tex @@ -262,13 +262,6 @@ dissipation by two orders of magnitude. Based on the current state of the field of hardware security, we deduce three overarching research questions for this thesis that progress from theory to practical deployment. -% Research questions: -% 1. can hsm w/o proprietary mesh? -% 2. how do meshes look like in practice? -% 3. can we improve monitoring? -% 4. can we solve power transfer issue -% 5. applications -% \begin{enumerate} \item What is the state of the art in commercial tamper sensing mesh implementations? \item What are criteria and approaches for the design of secure tamper sensing meshes? @@ -314,13 +307,46 @@ Distribution (QKD) networks using trustable physically secured relay nodes and i elaborate how datacenter-scale Secure Multiparty Computation (SMPC) clusters can be created using IHSM enclosures with commercial server hardware. +\section{Contributions} + +Through this thesis, we make contributions advancing the state of hardware securty across several related sub-fields. +Our contributions include: + +\begin{enumerate} + \item We conduct the first large-scale survey of tamper sensing measures in the real world, analyzing approximately + 30 devices. + \item From our real world observations, we systematize tamper sensing mesh construction techniques and we provide a + list of criteria improving mesh security. + \item We experimentally analyze the impact of Computed Tomography (CT) imaging on mesh security. + \item We propose the IHSM, a new concept for HSM design based on a rotating mesh that increases payload size and + power dissipation capacity while simultaneously allowing for simpler meshes constructed from standard + components. + \item We show experimental results on IHSM mesh performance obtained with a prototype IHSM. + \item We introduce an algorithm for the automatic layout of tamper-sensing meshes and its implementation on top of a + popular, open-source Electronic Design Automation (EDA) tool. + \item We introduce a high-fidelity mesh monitoring approach that uses Time-Domain Reflectometry (TDR). + \item We show a low-cost implementation of our TDR monitoring approach. + \item We evaluate the performance of our TDR monitoring implementation and demonstrate its response to a large + set of attacks. We show that it reliably distinguishes identical copies of the same mesh specimen, suggesting + PUF-like behavior. + \item We introduce a generalized design approach for low-loss planar inductors that out-peform prior approaches in + parasitic capacitance, self-resonant frequency and rotational symmetry. + \item We apply our design approach to the problem of Wireless Power Transfer to the rotating mesh of an IHSM. + \item We conduct an exhaustive experimental evaluation of the rotational symmetry of a large set of planar WPT + inductors created using our approach. + \item We analyze physically secure Quantum Key Distribution relays as an IHSM use case and develop a low-loss fiber + optic passthrough that supports an additional, secondary, independently rotating mesh shielding the shaft + passthrough of the IHSM's primary mesh. + \item We explore IHSMs for co-located high performance Multiparty Computation (MPC) setups. We demonstrate a + fan-driven IHSM mesh concept for high-availability scenarios that removes motors as a single point of failure + while providing sufficient airflow for cooling high-power server components. +\end{enumerate} + We chose to publish all of our research as open source and unencumbered by patents to enable widespread adoption. IHSMs can be custom built with only basic manufacturing capabilities at small scale and enable the deployment of secure computation in insecure places even to small organizations such as university research departments, NGOs and small businesses. -\section{Conclusion} - Looking at the practice of applied hardware security, we observe that despite ample availability of commercial solutions promising easy hardware security, clearly there is still a lack of solutions that provide the adaptability necessary for some real use cases at low enough cost. By publishing the tamper-sensing technology we developed during the making of