hw_features.tex

\section{Hardware Security Features}
\label{sec:hw-features}

%\jw{TODO (not me lol): Basic hardware description and features here -- what do we have to work with on the board that's relevant to our design?}
%\jw{this is all I know how to talk about, I know next to nothing about this board but that's the high level :). Someone please add more details here about the board itself if you know what to talk about.}

In order to ensure secure operation even while attackers have physical access to the board, we have extensively explored hardware security protections and countermeasures to ``harden'' the embedded system against side-channel, injection, and other hardware attacks:
\iflong
\begin{itemize}
    \item Leverage both the true random number generator (TRNG) provided by the board as well as other potential high-entropy sources of randomness to serve as a seed for cryptographically secure pseudo-random number generators (CSPRNG), ensuring the highest "quality" of randomness possible for all relevant cryptographic algorithms;
    \item Implement ASLR-like memory layout randomization by randomizing offsets in the firmware binary to make it harder to perform attacks on our system;
    \item Employ audited, constant-time implementations of cryptography and other downstream-dependant libraries to ensure that it will be harder to limit the ability for attackers to leverage hardware-level timing and other side-channel attacks; and 
    \item Protect against fault injections, instruction skipping, clock glitching, and similar hardware-level attacks which attackers might leverage in an attempt to bypass security checks.
    \iflong
    More specifically:
    \begin{itemize}
        \item Dummy cryptographic verification and decryption operations randomly injected into each relevant check to frustrate power analysis on the cryptographic secrets;
        \item Inject random operations between checks to frustrate timing and glitching attacks;
        \item Perform multiple valid cryptographic checks and ensure that fallthroughs skip to errors to frustrate instruction glitching;
        \item For anything especially susceptible to replay attacks or brute-force (e.g. attempting to guess PINs or generating nonces), inject additional delays to slow down attempts.
    \end{itemize}
    \fi
    %\item if time alows, construct our own physically unclonable function (PUF) which essentially identify/fingerprint boards based on the variances in the manufacture of individual hardware components.
\end{itemize}
\else
This includes using cryptographically-secure random number generators (CSPRNGs) instead of hardware-based ``true'' random number generators (TRNGs) whenever possible, constant-time memory and cryptographic operations, clock glitching and other fault injection detection, memory layout randomization, and even power analysis obfuscations, where relevant.

To ensure that the necessary cryptographic secrets and other data stored on these boards remain tamper-proof and confidential, we store them in the 512 KB flash memory. Since this flash memory resides on-chip, this makes it near-impossible for attackers to probe the flash memory for its contents or overwrite it with its own values. \jw{MITRE Organizers also store the flags here, so we'd have worse problems if attackers were able to dump the flash.}
\fi

%% Hardware threat model 
% ===================================================
% Basically list all the potential inputs in this case
% What all ports are available on the board?
%% Some of the common areas we need to protect against
% ====================================================
% Fault Injections (Need to have additional failsafes, to prevent simple fault injections)
%% Some background reading: https://research.nccgroup.com/2021/07/08/software-based-fault-injection-countermeasures-part-2-3/
% https://www.trustedfirmware.org/docs/TF-M_fault_injection_mitigation.pdf
%% We can go fancy later
% Constant time implementations for all checks (to avoid Side Channel leakage)
% Need to make sure that our RNG is the strongest thing that we can make, can we have a special development team for that?
% Every security measure we have is just gonna be dependent on the RNG in the end. So we test that first. 
% Defenses that against FI
% Double/Triple/N number of checks to detect inconsitency
% Add a small random delay after check to confuse