Add terminology notes
This commit is contained in:
parent
716f72d190
commit
1e8270a5f7
3 changed files with 87 additions and 1 deletions
|
|
@ -111,12 +111,19 @@ mid-2000s era slot machines in Germany that includes a tamper-sensing mesh, pres
|
|||
cloning. This device will also be analyzed later in this chapter.
|
||||
|
||||
\section{The Principles of Tamper-Sensing Mesh Construction and Monitoring}
|
||||
|
||||
\subsection{Security Mesh Manufacturing}
|
||||
|
||||
\subsection{Security Mesh Monitoring}
|
||||
|
||||
\subsection{Other Tamper Sensing Techniques}
|
||||
|
||||
\subsection{Hardware Security Module Applications}
|
||||
|
||||
\subsection{The Patent Landscape}
|
||||
|
||||
Tamper-sensing meshes can be implemented
|
||||
|
||||
\section{A Survey of Meshes in the Wild}
|
||||
|
||||
Concluding the brief history of tamper sensing meshes above, we find that they were initially developed for sensitive
|
||||
|
|
|
|||
|
|
@ -121,7 +121,77 @@ it can have gaps that allow for air flow between outside and inside, enabling ac
|
|||
cooling capability sharply increases computing power by increasing feasible payload power dissipation by
|
||||
two orders of magnitude.
|
||||
|
||||
\section{A note on terminology}
|
||||
|
||||
\section{Hardware Security Modules}
|
||||
|
||||
In this thesis, we use the term \emph{Hardware Security Module (HSM)} to refer to a security device that has the
|
||||
following three properties.
|
||||
|
||||
\begin{enumerate}
|
||||
\item A HSM targets the prevention of any conceivable physical attack. In particular, this includes intrusion attempts
|
||||
such as careful drilling or cutting into the device from any direction.
|
||||
\item A HSM includes tamper sensors that when triggered result in an active tamper response, usually deleting all
|
||||
cryptographic secrets and rendering the device inoperable.
|
||||
\item A HSM's tamper sensing and response subsystem is continuously powered from a backup power supply, usually a
|
||||
battery. Loss of power triggers the tamper response.
|
||||
\end{enumerate}
|
||||
|
||||
This use of the term \emph{HSM} aligns with common usage of the term both in the academic literature and in everyday
|
||||
conversation. Particularly the requirement of active tamper detection and response is crucial to distinguish a HSM from
|
||||
simpler devices such as TPMs, smart cards or secure enclaves in SoCs. Note that our use of the term HSM is slightly
|
||||
different from its use in government standards, from its use in the PCI (card payment industry asscociation) standards,
|
||||
and from its industry use.
|
||||
|
||||
In industry, the term HSM is often used for solutions that are only logically segregated and that do not include any
|
||||
particular defense against hardware attacks. Our conjecture is that this is a consequence of the standardization
|
||||
landscape, where for applications outside of card payment processing the US FIPS
|
||||
140-22~\cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002} standard was central to
|
||||
the industry. Despite encompassing both devices that include active tamper detection and response, FIPS 140-2 did not
|
||||
draw a distinction in its terminology between the two classes.
|
||||
|
||||
\paragraph{Use in government standards}
|
||||
|
||||
Under US national standard FIPS 140 in in its 2002 version
|
||||
2~\cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2002}, a HSM would be called a
|
||||
\emph{Multiple-Chip Cryptographic Module} that conforms to the standard's \emph{Security Level 4}. Interesting to note
|
||||
are that only security level 4 requires any active tamper detection and response, so its security levels 3 and below do
|
||||
not align with our HSM definition. Futher of note is that according to the standard, a single-chip solution does not
|
||||
require any tamper detection and response either to meet the standard's security level 4, which is in misalignment with
|
||||
our definition. The standard's 2019 updated version FIPS
|
||||
140-3~\cite{usnationalinstituteofstandardsandtechnologySecurityRequirementsCryptographic2019} defers to the
|
||||
international standards ISO/IEC 19790 and 24759.
|
||||
|
||||
ISO/IEC 19790~\cite{ISOIEC19790} and ISO/IEC 24759~\cite{ISOIEC24759} call what we call a HSM a \emph{Hardware
|
||||
Cryptographic Module} corresponding with the standards \emph{Security Level 4}. However, these standards only require
|
||||
active tamper detection and response when cryptographic secrets are transmitted in plaintext between chips.
|
||||
|
||||
\paragraph{Use in card payment processing (PCI SSC) standards}
|
||||
|
||||
The Payment Card Industry Security Standards Council (PCI SSC) is an association of credit card network operators that
|
||||
defines standards for all layes of card payment processing from card payment terminals in stores through the handling of
|
||||
payment data in online shop backend systems.
|
||||
|
||||
PCI SSC terminology aligns with our use and with common everyday use of the term HSM. In PCI SSC terminology, a HSM is a
|
||||
crytographic device that has active tamper detecion and response circuitry. However, PCI SSC terminology only differs
|
||||
from our use of the term HSM in one nuance: In PCI SSC terminology, a HSM is specifically a datacenter device used for
|
||||
backend processing of payment data. The general class of ``hardware devices performing some security function with or
|
||||
without particular physical security requirements'' that ISO/IEC 19790 and other standards call a \emph{Hardware
|
||||
Cryptographic Module}, in PCI SSC terminology is termed \emph{Secure Cryptographic Device (SCD)} in more recent standard
|
||||
versions, which was updated from the previous term \emph{Tamper-Resistant Security Module (TRSM)}. Other than HSMs, PCI
|
||||
SSC includes smartcards and card payment terminals in this category. Card payment terminals, referred to as
|
||||
\emph{Pin-Entry Device (PED)} in PCI SSC standards, have to include a surprising amount of active tamper detection and
|
||||
response functionality including partial coverage of areas like they system's main cryptographic processor and smart
|
||||
card reader by battery-backed tamper-sensing meshes.
|
||||
|
||||
\section{Tamper-Sensing Meshes}
|
||||
|
||||
In this thesis, we use the terms \emph{Tamper-Sensing Mesh} and \emph{Security Mesh} synonymous. We use both terms to
|
||||
refer to any electrical circuit whose path is laid out to cover a surface with the intent of detecting attempts at
|
||||
drilling, cutting or otherwise manipulating this surface. While the term \emph{Security Mesh} is more concise, it is
|
||||
less clear to people unfamiliar with the matter. It is also polysemous, and depending on context can also refer to woven
|
||||
or stamped metal meshes used as fences or as screens in front of windows to prevent break-in. As a result, it is harder
|
||||
to use in online searches, and when using Large Language Models (LLMs), it frequently leads to amusing hallucinations.
|
||||
|
||||
%In the early days of mass-market computing, the expectations towards this new tool were high. Even before people
|
||||
%realized the potential of computers and the internet for commercial gain, there was widespread optimism about the
|
||||
|
|
|
|||
11
main.bib
11
main.bib
|
|
@ -4505,7 +4505,6 @@
|
|||
author = {{National Institute of Standards and Technology (US)}},
|
||||
date = {2019},
|
||||
number = {error: 140-3},
|
||||
pages = {error: 140-3},
|
||||
institution = {{National Institute of Standards and Technology (U.S.)}},
|
||||
location = {Washington, D.C.},
|
||||
doi = {10.6028/NIST.FIPS.140-3},
|
||||
|
|
@ -5016,6 +5015,16 @@
|
|||
urldate = {2025-04-09}
|
||||
}
|
||||
|
||||
@standard{pcisecuritystandardscouncilPaymentCardIndustry2025,
|
||||
title = {Payment {{Card Industry PIN Transaction Security Device Testing}} and {{Approval Program Guide}}},
|
||||
author = {{PCI Security Standards Council}},
|
||||
date = {2025-06},
|
||||
url = {https://docs-prv.pcisecuritystandards.org/PTS/Supporting%20Document/PTS_Program_Guide_v2.2.pdf},
|
||||
urldate = {2025-08-22},
|
||||
pagetotal = {75},
|
||||
version = {2.2}
|
||||
}
|
||||
|
||||
@article{perrigTESLABroadcastAuthentication,
|
||||
title = {The {{TESLA Broadcast Authentication Protocol}}},
|
||||
author = {Perrig, Adrian and Canetti, Ran and Tygar, J D and Song, Dawn},
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue