diff --git a/doc/Makefile b/doc/Makefile index 1e072224..5a42bb13 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -34,4 +34,5 @@ $(SPEC_OUT) : $(SPEC_TEX) $(SPEC_EXTRA) $(SPEC_COMMIT) spec: $(SPEC_OUT) clean: - rm -r $(BUILD_DIR)/* + rm -rf $(BUILD_DIR)/* $(OPCODES) \ + *.aux *.bbl *.blg *.log *.out *.pdf *.run.xml *-blx.bib *.toc diff --git a/doc/riscv-crypto-spec.bib b/doc/riscv-crypto-spec.bib index 023091d6..1ade646f 100644 --- a/doc/riscv-crypto-spec.bib +++ b/doc/riscv-crypto-spec.bib @@ -79,6 +79,9 @@ @misc{cryptoeprint:2020:930 note = {\url{https://eprint.iacr.org/2020/930}}, } + +% Note: The ASHES'20 published version is SaNeMa20 + @misc{cryptoeprint:2020:866, author = {Markku-Juhani O. Saarinen and G. Richard Newell and Ben Marshall}, title = {Building a Modern TRNG: An Entropy Source Interface for RISC-V}, @@ -803,14 +806,14 @@ @Misc{ NI19 year = {2019} } -@Misc{ NICC19, +@Misc{ NICC20, author = {{NIST} and {CCCS}}, title = {Implementation Guidance for {FIPS} 140-2 and the Cryptographic Module Validation Program}, howpublished = {CMVP Update}, - month = {December}, - url = {https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Module-Validation-Program/documents/fips140-2/FIPS1402IG.pdf}, - year = {2019} + month = {August}, + url = {https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips140-2/FIPS1402IG.pdf}, + year = {2020} } @Misc{ NS15, @@ -905,15 +908,33 @@ @Misc{ Sa19 year = {2019} } -@Misc{ Sa20, +@InProceedings{ Sa20, author = {Markku-Juhani O. Saarinen}, - title = {A Lightweight ISA Extension for AES and SM4}, - howpublished = {To appear in SECRISC-V 2020. arXiv:2002.07041}, + title = {A Lightweight ISA Extension for {AES} and {SM4}}, + booktitle = {First International Workshop on Secure RISC-V Architecture + Design Exploration (SECRISC-V'20)}, url = {https://arxiv.org/abs/2002.07041}, - month = {March}, + publisher = {IEEE}, + month = {August}, + pages = {To appear}, year = {2020} } + +@InProceedings{ SaNeMa20, + author = {Markku-Juhani O. Saarinen and G. Richard Newell and Ben + Marshall}, + title = {Building a Modern {TRNG}: An Entropy Source Interface for + {RISC}-{V}}, + booktitle = {4th Workshop on Attacks and Solutions in Hardware Security + (ASHES’20), November 13, 2020, Virtual Event, USA.}, + doi = {10.1145/3411504.3421212}, + publisher = {ACM}, + url = {https://eprint.iacr.org/2020/866}, + month = {November}, + year = 2020 +} + @Misc{ Sc99, author = {Werner Schindler}, title = {Functionality classes and evaluation methodology for diff --git a/doc/tex/appx-entropy.tex b/doc/tex/appx-entropy.tex index c3ab3f22..1d51192d 100644 --- a/doc/tex/appx-entropy.tex +++ b/doc/tex/appx-entropy.tex @@ -3,6 +3,7 @@ \section{Entropy Source: Rationale and Discussion} \label{sec:entropy-appendix} + The security of cryptographic systems is based on secret bits and keys. To prevent guessing, these bits need to be random, so they come from True Random Number Generators (TRNGs). @@ -15,18 +16,23 @@ \subsection{Standards and Terminology} A driving design goal for our architecture was for it to be easy to implement, yet compatible with current versions of FIPS 140-3 \cite{NI19} and NIST SP 800-90B \cite{TuBaKe+18}, significantly - updated standards that only became requirements in 2020. Naturally, + updated standards that are only coming into use in 2020. Naturally, the architecture should also support other RNG frameworks such as - German AIS 20 / AIS 31 \cite{KiSc01,KiSc11,BS13} which is widely used + German AIS 20 / 31 \cite{KiSc01,KiSc11} which is widely used in Common Criteria evaluations. + These standards set many of the technical requirements for the design, + and we use their terminology if possible. Note that FIPS 140-3 / + SP 800-90B (our main target) imposes requirements on min-entropy, while + AIS-31 discusses Shannon entropy as well. + These standards set many of the technical requirements for the design, and we use their terminology if possible. The delineation of various components is illustrated in Figure \ref{fig:rng_tikz}. - \paragraph{Entropy Source (ES)} + \subsubsection{Entropy Source (ES)} \label{sec:intro-es} Physical sources of true randomness are called Entropy Sources (ES) \cite{TuBaKe+18}. They are built by sampling and processing data @@ -34,9 +40,10 @@ \subsection{Standards and Terminology} are directly based on natural phenomena and are subject to environmental conditions (which may be adversarial), they require features and sensors that monitor the ``health'' and quality of those - sources. + sources. See Section \ref{sec:security-controls} for a discussion about + such security controls. - \paragraph{Conditioning} + \subsubsection{Conditioning} \label{sec:intro-cond} Raw physical randomness (noise) sources are rarely statistically perfect and some generate very large amounts of bits, which need to be @@ -48,11 +55,13 @@ \subsection{Standards and Terminology} Non-cryptographic conditioners and extractors such as von Neumann's ``debiased coin tossing'' \cite{Ne51} are easier to implement - efficiently but may reduce entropy content much more than hashes. + efficiently but may reduce entropy content (in individual bits removed) + more than cryptographic hashes which mix the input entropy very efficiently. However, they are not based on computational hardness assumptions and - are therefore inherently more future proof. + are therefore inherently more future proof. See Section + \ref{sec:noncrypto} for a more detailed discussion. - \paragraph{Pseudorandom Number Generator (PRNG)} + \subsubsection{Pseudorandom Number Generator (PRNG)} \label{sec:intro-prng} Pseudorandom Number Generators (PRNGs) use deterministic mathematical formulas to create a large amount of random numbers from a smaller @@ -68,18 +77,17 @@ \subsection{Standards and Terminology} from it. This is a security problem since knowledge of the state allows the attacker to compute future or past outputs. - \paragraph{Deterministic Random Bit Generator (DRBG)} + \subsubsection{Deterministic Random Bit Generator (DRBG)} \label{sec:intro-drbg} Cryptographic PRNGs are also known as Deterministic Random Bit Generators (DRBGs), a term used by SP 800-90A \cite{BaKe15}. A strong cryptographic algorithm such as AES \cite{NI01} or SHA-2/3 \cite{NI15,NI15A} is used to produce random bits from a seed. The secret - seed material is acting as a cryptographic key; determining the seed + seed material is like a cryptographic key; determining the seed from the DRBG output is as hard as breaking AES or a strong hash function. This also illustrates that the seed/key needs to be long enough and - come from a trusted Entropy Source. The DRBG can be frequently - refreshed or ``reseeded.'' - + come from a trusted Entropy Source. The DRBG should still be frequently + refreshed (reseeded) for forward and backward security. \begin{figure}[tb] \centering @@ -103,7 +111,7 @@ \subsection{Specific Rationale and Considerations} purposes of forward security. Without a polling-style mechanism the entropy source could hang for - thousands of cycles under some circumstances. The \mnemonic{WFI} mechanism + thousands of cycles under some circumstances. The \mnemonic{wfi} mechanism (at least potentially) allows energy-saving sleep on MCUs and context switching on a higher-end CPUs. @@ -114,15 +122,15 @@ \subsection{Specific Rationale and Considerations} The 16-bit bandwidth was a compromise motivated by the desire to provide redundancy in the return value, some protection against - potential Power/EM leakage (further alleviated by the 2:1 - cryptographic conditioning), and the desire to have all of the - bits ``in the same place'' on both RV32 and RV64 architectures for - programming convenience. + potential Power/EM leakage (further alleviated by the 2:1 cryptographic + conditioning discussed in Section \ref{sec:req-entropy}), and the desire + to have all of the bits ``in the same place'' on both RV32 and RV64 + architectures for programming convenience. \paragraph{(Sect. \ref{sec:req-es}) \S E1, Entropy Requirement:} - Rather than attempting to mathematically define the properties that the - entropy source output must satisfy, we define that it should be good - enough to pass an evaluation and certification when conditioned + Rather than attempting to mathematically define the properties that the + entropy source output must satisfy, we define that it should + pass SP 800-90B evaluation and certification when conditioned cryptographically (``perfectly'') in ratio 2:1. This is our ``safety margin'' for non-cryptographic conditioners. @@ -147,20 +155,26 @@ \subsection{Specific Rationale and Considerations} is needed to prevent information leakage between different entities that possibly share the same entropy source. It also significantly simplifies certification and vendor-independent driver development. - The \verb|PollEntropy| instruction itself can be later expanded + The \mnemonic{pollentropy} instruction itself can be later expanded to support non-IID sources (e.g. via a different immediate constant). \paragraph{(Sect. \ref{sec:req-es}) \S E3, Secret State Requirement:} - DRBGs can be used to feed other DRBGs but of course that does not + DRBGs can be used to feed other (virtual) DRBGs but that does not increase the absolute amount of entropy in the system. The entropy source must be able to support current and future security - standards and applications. - - The 256-bit level is quite arbitrary but maps to - ``Category 5'' of Post-Quantum Cryptography standards (See section 4.A.5 + standards and applications. The 256-bit requirement maps to + ``Category 5'' of NIST Post-Quantum Cryptography (4.A.5 ``Security Strength Categories'' in \cite{NI16}) and TOP SECRET schemes in Suite B and the newer U.S. Government CNSA Suite \cite{NS15}. + {\em Source anonymization.} + In some cases, an entropy source (or the circuit that interfaces it) + may have a uniquely identifiable hardware ``signature.'' This can be + harmless or even useful in some applications (as random sources may + exhibit PUF-like features) but highly undesirable in others (anonymized + virtualized environments and enclaves). A DRBG masks such + statistical features. + \paragraph{(Sect. \ref{sec:security-controls}) Security Controls:} Our approach is informed by the experience of designing and implementing cryptographic protocols. Some of the most devastating practical attacks @@ -189,9 +203,9 @@ \subsection{Specific Rationale and Considerations} The role of the RISC-V ISA implementation is to try to ensure that the hardware-software interface minimizes avenues for adversarial information flow; all status information that is unnecessary in normal operation - should be eliminated. We specifically urge implementors against creating + should be eliminated. We specifically urge implementers against creating unnecessary information flows (``status oracles'') via the custom bits - or to allow the instruction to disable or affect the TNRG output in any + or to allow the instruction to disable or affect the TRNG output in any significant way. All information flows and interaction mechanisms must be considered from an adversarial viewpoint and implemented only if they are truly necessary and their security impact can be fully understood. @@ -200,7 +214,7 @@ \subsection{Specific Rationale and Considerations} The polling mechanism can be modeled as a rejection sampler; such a timing oracle can reveal information about the noise source and the rejection criteria, but usually not the random output itself. - Or are these correlated, and are countermeasures necessary? + If these are correlated, additional countermeasures are necessary. \paragraph{(Sect. \ref{sec:security-controls}) \S T1, On-demand testing:} Interaction with hardware self-test mechanisms @@ -216,10 +230,13 @@ \subsection{Specific Rationale and Considerations} should be aimed at damage control -- to prevent weak crypto keys from being generated. - There may be requirements for signaling of alarms; AIS 31 specifies - ``noise alarms'' that can go off with non-negligible probability - even if the device is functioning correctly; these can't be fatal - but can be signaled with \verb|BIST|. + The statistical nature of some tests makes ``type-1'' false + positives a possibility. There may also be requirements for signaling + of non-fatal alarms; AIS 31 specifies ``noise alarms'' that can go off + with non-negligible probability even if the device is functioning + correctly; these can be signaled with \verb|BIST|. + There rarely is anything that can or should be done about a non-fatal + alarm condition in an operator-free, autonomous system. The state of statistical runtime health checks (such as counters) is potentially correlated with some secret keying material, hence @@ -235,27 +252,14 @@ \subsection{Specific Rationale and Considerations} a \emph{fault attack} \cite{KaScVe13} and therefore should be addressed as a system integrity failure rather than as a diagnostic issue. -\subsection{Implementation Strategies} - - As a general rule, RISC-V specifies the ISA only. We provide some - additional requirements so that portable, vendor-independent middleware - and kernel components can be created. The actual hardware - implementation and certification is left to vendors and circuit designers; - the discussion in this section is purely informational. - - While we do not require entropy source implementations to be - certified designs, we do expect that they behave in a compatible manner - and do not create unnecessary security risks to users. Self-evaluation - and testing following appropriate security standards is usually needed - to achieve this. NIST has made its SP 800-90B\cite{TuBaKe+18} min-entropy - estimation package freely available; see - \url{https://github.com/usnistgov/SP800-90B_EntropyAssessment}. - Similar free tools are also available for AIS 31 \cite{KiSc11}: - \url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_testsuit_zip}. + Security architects will understand to use + permanent or hard-to-recover ``security-fuse'' lockdowns only if the + threshold of a test is such that the probability of false-positive is + negligible over the entire device lifetime. +\subsection{Implementation Strategies} - \paragraph{Entropy Flow} When considering implementation options and trade-offs one must look at the entire information flow since each step is interconnected. @@ -267,18 +271,36 @@ \subsection{Implementation Strategies} \item {\bf Continuous health tests} ensure that the noise source and its environment meet their operational parameters. \item {\bf Non-cryptographic conditioners} remove much of the bias - and correlation in input noise: Output entropy $>4$ bits/byte. + and correlation in input noise: Output entropy $\gg 4$ bits/byte. \item {\bf Cryptographic conditioners} produce nearly full entropy output, completely indistinguishable from ideal random. \item {\bf DRBG} takes in $\geq 256$ bits of seed entropy as keying material and uses a ``one way'' cryptographic process to rapidly - generate bits on demand (without revealing the seed or the state). + generate bits on demand (without revealing the seed/state). \end{enumerate} Steps 1-4 (possibly 5) are considered to be part of the Entropy - Source (ES) and provided by the \verb|PollEntropy| instruction. + Source (ES) and provided by the \mnemonic{pollentropy} instruction. Adding the software-side cryptographic steps 5-6 and control logic complements it into a True Random Number Generator (TRNG). - This information flow is illustrated by Figure \ref{fig:rng_tikz}. +% This information flow is illustrated by Figure \ref{fig:rng_tikz}. + + As a general rule, RISC-V specifies the ISA only. We provide some + additional requirements so that portable, vendor-independent middleware + and kernel components can be created. The actual hardware + implementation and certification is left to vendors and circuit designers; + the discussion in this section is purely informational. + + While we do not require entropy source implementations to be + certified designs, we do expect that they behave in a compatible manner + and do not create unnecessary security risks to users. Self-evaluation + and testing following appropriate security standards is usually needed + to achieve this. NIST has made its SP 800-90B\cite{TuBaKe+18} min-entropy + estimation package freely available\footnote{EntropyAssessment: + \url{https://github.com/usnistgov/SP800-90B_EntropyAssessment}} and + similar free tools are also available\footnote{(In German) + AIS 31-Implementierung in JAVA: + \url{https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_31_testsuit_zip}} + for AIS 31 \cite{KiSc11}. \subsubsection{Noise Sources} \label{sec:noise-sources} @@ -334,8 +356,8 @@ \subsubsection{Noise Sources} noisy diodes. Shot noise sources are often more resistant to temperature changes than ring oscillators. Some of these generators can also be fully implemented with standard - cells (The Rambus / Inside Secure generic TRNG IP \cite{Ra20} is described - as a Shot Noise generator). + cells (The Rambus / Inside Secure generic TRNG IP \cite{Ra20} is + described as a Shot Noise generator). \paragraph{Other types of noise.} It may be possible to certify more exotic noise sources and designs, @@ -348,9 +370,9 @@ \subsubsection{Noise Sources} \subsubsection{Samplers and GetNoise} It is necessary to verify that the noise source and sampler output - matches with their stochastic models. We note that this is - usually done in a laboratory setting since NIST SP 800-90B \cite{TuBaKe+18} - urges implementors to protect the source in production devices. + matches with their stochastic models. This is usually + done in a laboratory setting since NIST SP 800-90B \cite{TuBaKe+18} + requires that the noise source in protected in production devices. We are leaving access as a vendor-specific matter but we urge them to protect the raw source and to make it unavailable to casual users. @@ -360,6 +382,11 @@ \subsubsection{Samplers and GetNoise} for the raw output and also anticipates that the actual interfaces ``will depend on the entropy source deployed.'' + Building data paths to make the raw noise available through the ISA + would be problematic as it is unclear how to ``sample'' + possibly up to several gigabits of information per second in a way + that is appropriately representative of its properties. + \begin{quote} \emph{``The vendor may use special methods (or devices, such as an oscilloscope) that require detailed knowledge of the source to @@ -368,15 +395,9 @@ \subsubsection{Samplers and GetNoise} the statistical properties of the noise source or explain how to account for any change in the source’s statistical characteristics [...]''} - \flushright -- FIPS 140 Implementation Guidance, 2019 \cite{NICC19} + \flushright -- FIPS 140 Implementation Guidance, 2020 \cite{NICC20} \end{quote} - Building data paths to make the raw noise available through the ISA - would be problematic as it is unclear how to ``sample'' - possibly up to several gigabits of information per second in a way - that is appropriately representative of its properties. SP 800-90B - notes that it is permitted that such an interface be available only in - ``test mode'' and that it is disabled when the source is operational. \subsubsection{Continuous Health Tests} @@ -392,7 +413,7 @@ \subsubsection{Continuous Health Tests} in a way that a specific number of samples guarantees a state flush (no hung states). We suggest flush size $W \leq 1024$ to match with the NIST SP 800-90B required tests (See Section 4.4 in - \cite{TuBaKe+18}). + \cite{TuBaKe+18}). The state is also fully zeroized in a system reset. \underline{Rationale:} The two mandatory tests can be built with minimal circuitry. @@ -400,13 +421,12 @@ \subsubsection{Continuous Health Tests} repetition count, window count, and sample count. Repetition count is reset every time the output sample value changes; if the count reaches a certain cutoff limit, a noise alarm - (\verb|BIST|) or failure (\verb|DEAD|) is signaled. - Window counter is used to save every $W$'th output (typically - $W \in { 512, 1024 }$.) The frequency of this - reference sample in the following window is counted; cutoff values - are defined in the standard. We see that the structure of the - mandatory tests is such that, if well implemented, no information is - carried beyond a limit of $W$ samples. + (\verb|BIST|) or failure (\verb|DEAD|) is signaled. Window counter is + used to save every $W$'th output (typically $W \in { 512, 1024 }$.) + The frequency of this reference sample in the following window is + counted; cutoff values are defined in the standard. We see that the + structure of the mandatory tests is such that, if well implemented, + no information is carried beyond a limit of $W$ samples. Section 4.5 of \cite{TuBaKe+18} explicitly permits additional developer-defined tests and several more were defined in early @@ -445,8 +465,9 @@ \subsubsection{Non-cryptographic Conditioners} The approach taken in this interface is to allow a combination of non-cryptographic and cryptographic filtering to take place. The first stage (hardware) merely needs to be able to distill the entropy - comfortably above 4 bits per byte, and to guarantee that the samples - are independent (IID). + comfortably above 4 bits per byte (Sect. \ref{sec:req-entropy}, + Entropy) and to guarantee that the samples are independent + (Sect. \ref{sec:req-iid}, IID). \begin{itemize} \item One may take a set of bits from a noise source and XOR them @@ -455,20 +476,22 @@ \subsubsection{Non-cryptographic Conditioners} lends itself well to analysis and entropy estimation \cite{Da02}. \item The von Neumann extractor \cite{Ne51} looks at consecutive pairs of bits, rejects 00 and 11, and outputs 0 or 1 for - 01 and 10, respectively. It will cut down the number of bits to - less than 25\% but the output is provably unbiased (assuming - independence). + 01 and 10, respectively. It will reduce the number of bits to + less than 25\% of original but the output is provably unbiased + (assuming independence). \item Blum's extractor \cite{Bl86} can be used on sources whose behavior resembles $n$-state Markov chains. If its assumptions hold, it also removes dependencies, creating an IID source. \item Other linear and non-linear correctors such as those discussed by Dichtl and Lacharme \cite{La08}. - \item One may also implement a full cryptographic conditioner - in the entropy source hardware, even though the software driver - is required to implement one too. \end{itemize} + Note that the hardware may + also implement a full cryptographic conditioner to in the entropy + source, even though the software driver still needs + a cryptographic conditioner too (Sect. \ref{sec:req-state}). + \underline{Rationale:} The main advantage of non-cryptographic filters is in their energy efficiency, relative simplicity, and amenability to mathematical @@ -510,28 +533,29 @@ \subsubsection{Cryptographic Conditioners} For many low-power targets constructions such as Intel's \cite{Me18} and AMD's \cite{AM17} hardware AES CBC-MAC conditioner would be too complex and expensive to implement solely to serve - \verb|PollEntropy|. On the other hand, simpler non-cryptographic + \mnemonic{pollentropy}. On the other hand, simpler non-cryptographic conditioners may be too wasteful on input entropy if very high-quality - random output is required -- ARM TrustZone TRBG \cite{AR17} - outputs 10Kbit/sec at 200 MHz. Hence a resource-saving compromise is + random output is required -- ARM TrustZone TRBG \cite{AR17} outputs + only 10Kbit/sec at 200 MHz. Hence a resource-saving compromise is made between hardware and software generation that allows an implementation to use the RISC-V cryptographic ISA. -% Even if a DRBG seed obtains a sufficient amount of entropy in total, -% some bits may be more important than others. For example, the IV values -% of a counter-mode DRBG are less important than the key bits; -% if an adversary knows the key bits then the IV (counter value) is -% easy to determine. The inverse is not true. Cryptographic -% conditioning is required to spread the entropy across all bits. +% Even if a DRBG seed obtains a sufficient amount of entropy in total, +% some bits may be more important than others. For example, the IV values +% of a counter-mode DRBG are less important than the key bits; +% if an adversary knows the key bits then the IV (counter value) is +% easy to determine. The inverse is not true. Cryptographic +% conditioning is required to spread the entropy across all bits. + \subsubsection{The Final Random: DRBGs} \label{sec:drbgs} All random bits reaching end users and applications must come from a cryptographic DRBG. These are generally implemented by the driver - component in software. The RISC-V AES and SHA instruction set - extensions should be used if available since they - offer additional security features such as timing attack resistance. + component in software. The RISC-V AES and SHA instruction set extensions + should be used if available, since they offer additional + security features such as timing attack resistance. Currently recommended DRBGs are defined in NIST SP 800-90A (Rev 1) \cite{BaKe15}: \verb|CTR_DRBG|, \verb|Hash_DRBG|, and \verb|HMAC_DRBG|. @@ -539,8 +563,8 @@ \subsubsection{The Final Random: DRBGs} components and the DRBG as a whole. These are significantly easier to implement in software than in hardware. In addition to the directly certifiable SP 800-90A DRBGs, a Linux-style random pool construction - based on ChaCha20 \cite{Mu20} can be used, or an appropriate - construction based on SHAKE256 \cite{NI15}. + based on ChaCha20 \cite{Mu20} can be used, or an appropriate construction + based on SHAKE256 \cite{NI15}. These are just recommendations; programmers can adjust the usage of the CPU Entropy Source to meet future requirements. @@ -549,13 +573,19 @@ \subsubsection{The Final Random: DRBGs} \subsection{Quantum vs Classical Random} \label{sec:quantum} + \begin{quote} + {\it ``The NCSC believes that classical RNGs will continue to + meet our needs for government and military applications for the + foreseeable future.''} + \flushright -- U.K. QRNG Guidance, March 2020 \cite{NC20}. + \end{quote} + A Quantum Random Number Generator (QRNG) is a TRNG whose source of randomness can be unambiguously identified to be a \emph{specific} quantum phenomenon such as quantum state superposition, quantum state entanglement, Heisenberg uncertainty, quantum tunneling, spontaneous emission, or radioactive decay \cite{IT19}. - Direct quantum entropy is theoretically the best possible kind of entropy. A typical TRNG based on electronic noise is also largely based on quantum phenomena and is equally unpredictable - the difference @@ -571,27 +601,20 @@ \subsection{Quantum vs Classical Random} This security model means that many of the available QRNG devices do not use cryptographic conditioning and may fail - cryptographic statistical requirements \cite{HuHe20}. Hence they should - perhaps be considered to be entropy sources instead. + cryptographic statistical requirements \cite{HuHe20}. Many implementers + may consider them to be entropy sources instead. - Relatively little research has gone into QNRG implementation security, + Relatively little research has gone into QRNG implementation security, but many QRNG designs are arguably more susceptible to leakage than classical generators (such as ring oscillators) as they tend to employ external components and mixed materials. - \begin{quote} - {\it ``The NCSC believes that classical RNGs will continue to - meet our needs for government and military applications for the - foreseeable future.''} - \flushright -- U.K. QRNG Guidance, March 2020 \cite{NC20}. - \end{quote} - \paragraph{Post-Quantum Cryptography.} - The classical/quantum origin of randomness is not relevant in NIST + The classical/quantum origin of randomness is not important in NIST Post-Quantum Cryptography (PQC) \cite{NI16}. Recall that cryptography aims to protect the confidentiality and integrity of data itself and does not place any requirements on the physical communication - channel (like QKD). Classical good-quality TRNGs are perfectly fine + channel (like QKD). Classical good-quality TRNGs are perfectly suitable for generating the secret keys for PQC protocols that are hard for quantum computers to break, but implementable on classical computers. What matters in cryptography is that the secret keys have enough true diff --git a/doc/tex/sec-entropy-source.tex b/doc/tex/sec-entropy-source.tex index 93c13a08..ce71955f 100644 --- a/doc/tex/sec-entropy-source.tex +++ b/doc/tex/sec-entropy-source.tex @@ -1,26 +1,25 @@ %\section{The Entropy Source Interface} \label{sec:entropy-source} - The RISC-V True Random Number Generator (TRNG) ISA Extension is primarily - an Entropy Source (ES) interface. A valid implementation should satisfy - properties that allow it to be used to \emph{seed} standard and - nonstandard cryptographic DRBGs of virtually any state size and security - level. + The proposed RISC-V TRNG ISA is primarily an Entropy Source (ES) + interface. A valid implementation should satisfy properties that allow + it to be used to \emph{seed} standard and nonstandard cryptographic + DRBGs of virtually any state size and security level. The purpose of this baseline specification is to guarantee that a simple, device-independent driver component (e.g. in Linux kernel, embedded - firmware, or a cryptographic library) can use the instruction to + firmware, or a cryptographic library) can use the ISA instruction to generate truly random bits. See Appendix \ref{sec:entropy-appendix} for rationale and further discussion. This section is also supported by - \cite{cryptoeprint:2020:866}. + \cite{SaNeMa20}. \subsection{PollEntropy Instruction} \label{sec:es-pollentropy} - The ISA-level interface consists of a single instruction, \mnemonic{pollentropy} that returns a 32/64-bit value in a CPU register. - It is invoked in {\bf Machine Mode}. + It is invoked in {\bf Machine Mode} (which may be the only mode) as + follows: \begin{cryptoisa} pollentropy rd, imm // Get randomness. imm=0 for baseline operation @@ -35,6 +34,17 @@ \subsection{PollEntropy Instruction} \verb|ES16| (01), indicating successful polling, or with {\bf no} entropy and one of three polling failure statuses \verb|BIST| (00), \verb|WAIT| (10), or \verb|DEAD| (11), discussed below. +% See Tables \ref{tab:rdbits} and \ref{tab:opstbits} for further +% information. + + The sixteen bits of randomness in \verb|rd[15:0]|=\verb|seed| polled + with \verb|ES16| status {\bf must be cryptographically conditioned} + before they can be used as (up to 8 bits of) keying material. See Section + \ref{sec:req-es}. + + For the purposes of interoperable, baseline functionality, \verb|imm = 0|. + Nonzero values of \verb|imm| are reserved for future use; the behavior + described here may not apply when \verb|imm| $\neq$ 0. \begin{center} \begin{tabular}{ccl} @@ -77,8 +87,8 @@ \subsection{PollEntropy Instruction} means that a sufficient amount of entropy is not yet available. This is not an error condition and may (in fact) be more frequent than ES16, since true entropy sources may not have very high bandwidth. - If polling in a loop, we suggest calling WFI (wait for interrupt) - before the next poll. + If polling in a loop, we suggest calling \mnemonic{wfi} (wait for + interrupt) before the next poll. \item[11] \underline{\tt DEAD} is an unrecoverable self-test error. This may indicate a hardware @@ -122,26 +132,29 @@ \subsection{Polling Mechanism with WFI} We specifically recommend against busy-loop polling on this instruction as it may have relatively low bandwidth. Even though no specific interrupt - sequence is specified, it is required that the \mnemonic{WFI} (wait for + sequence is specified, it is required that the \mnemonic{wfi} (wait for interrupt) instruction is available and does not trap on systems that - implement \mnemonic{pollentropy}. The RISC-V ISA allows \mnemonic{WFI} to be - implemented as a \mnemonic{NOP}. + implement \mnemonic{pollentropy}. The RISC-V ISA allows \mnemonic{wfi} to be + implemented as a \mnemonic{nop}. As a minimum requirement for portable drivers, a \verb|WAIT| or - \verb|BIST| from \mnemonic{pollentropy} should be followed by a WFI before - another \mnemonic{pollentropy} instruction is issued. There is - no need to poll after a \verb|DEAD| state. + \verb|BIST| from \mnemonic{pollentropy} should be followed by a + \mnemonic{wfi} before another \mnemonic{pollentropy} instruction is + issued. There is no need to poll after a \verb|DEAD| state. To guarantee that no sensitive data is read twice and that different callers don't get correlated output, it is suggested that hardware - implements ``wipe-on-read'' on the randomness pathway during each read - (successful poll). For the same reasons, only complete and fully - processed randomness words shall be made available via + implements ``wipe-on-read'' on the randomness + pathway during each read (successful poll). For the same reasons, only complete + and fully processed randomness words shall be made available via \mnemonic{pollentropy} (no half-conditioned buffers or even full buffers in \verb|WAIT| state -- even if they are to be ignored by compliant callers). \subsection{Entropy Source Requirements} \label{sec:req-es} +\label{sec:req-entropy} +\label{sec:req-iid} +\label{sec:req-state} Output \verb|SEED| from \mnemonic{pollentropy} is not necessarily fully conditioned randomness due to hardware limitations of smaller, @@ -167,8 +180,8 @@ \subsection{Entropy Source Requirements} \item[\S E2] {\bf I.I.D. Requirement.} The output must be \emph{Independent and Identically Distributed} - (IID), meaning that the output distribution does not change over time - and that output words do not convey information about each other. + (IID), meaning that the output distribution does not deteriorate over + time and that output words do not convey information about each other. This requirement is satisfied if the construction of the physical source and sampling mechanism suggests nothing against the IID assumption and the IID tests in Section 5 of NIST SP 800-90B \cite{TuBaKe+18} are @@ -178,14 +191,13 @@ \subsection{Entropy Source Requirements} A \mnemonic{pollentropy} implementation can also output fully conditioned, perfectly distributed numbers. However, it is required that if a DRBG is used as a source, it must have an internal state with at least 256 bits - of secret entropy. In general, any implementation of \mnemonic{pollentropy} - that limits the security strength shall not reduce it to less than - 256 bits. + of secret entropy (Example: a CTR\_DRBG built from AES-128 is never + sufficient). In general, any implementation of \mnemonic{pollentropy} that + limits the security strength shall not reduce it to less than 256 bits. \end{itemize} - \subsection{Security Controls (Tests)} \label{sec:security-controls} @@ -198,7 +210,7 @@ \subsection{Security Controls (Tests)} adversarial control over the entropy output or ts generation mechanism. Many of the security controls built into the device are called ``health - checks''. Health checks can take the form of + checks.'' Health checks can take the form of integrity checks, start-up tests, and on-demand tests. These tests can be implemented in hardware or firmware; typically both. Several are mandated by standards such as NIST SP 800-90B \cite{NI19}. The choice @@ -209,9 +221,8 @@ \subsection{Security Controls (Tests)} Health checks are not intended for hardware diagnostics but for detecting security issues -- hence the default action should be aimed at damage control (prevent weak crypto keys from being - generated). Additional ``debug'' mechanisms for raw noise sources - or additional control may be implemented if necessary, but those should - not be available when the device is in production use. + generated). Additional ``debug'' mechanisms may be implemented if + necessary, but then the device must be outside production use. \begin{itemize} @@ -225,11 +236,10 @@ \subsection{Security Controls (Tests)} \item[\S T2] {\bf Continuous checks.} If an error is detected in continuous tests or environmental sensors, - the entropy source will enter a no-output state. We define that a + the entropy source will enter a no-output state. We define that a non-critical alarm is signaled if the entropy source returns to \verb|BIST| state from live (\verb|WAIT| or \verb|ES16|) states. - Such a \verb|BIST| alarm should be latched until polled at least once. - + Such a \verb|BIST| alarm should be latched until polled at least once. Critical failures will result in \verb|DEAD| state immediately. A hardware-based continuous testing mechanism must not make statistical information externally available, and it must be zeroized periodically or @@ -239,18 +249,18 @@ \subsection{Security Controls (Tests)} Since the security of most cryptographic operations depends on the entropy source, a system-wide ``default deny'' security policy approach is appropriate for most entropy source failures. - A hardware test failure should result in at least in \verb|DEAD| state - and possibly reset/halt. The entropy source (or its cryptographic client - application) \emph{must not} be allowed to run if its secure operation - can't be guaranteed. + A hardware test failure should at least result in the \verb|DEAD| + state and possibly reset/halt. It's a show stopper: The entropy + source (or its cryptographic client application) \emph{must not} be + allowed to run if its secure operation can't be guaranteed. \end{itemize} - The statistical nature of some tests makes ``type-1'' false - positives a possibility. Security architects will understand to use - permanent or hard-to-recover ``security-fuse'' lockdowns only if the - threshold of a test is such that the probability of false-positive is - negligible over the entire device lifetime. +% The statistical nature of some tests makes ``type-1'' false +% positives a possibility. Security architects will understand to use +% permanent or hard-to-recover ``security-fuse'' lockdowns only if the +% threshold of a test is such that the probability of false-positive is +% negligible over the entire device lifetime. diff --git a/doc/tex/sec-profiles.tex b/doc/tex/sec-profiles.tex index 50d89558..74098c6c 100644 --- a/doc/tex/sec-profiles.tex +++ b/doc/tex/sec-profiles.tex @@ -23,7 +23,7 @@ \multicolumn{3}{c}{Vector Profiles} \\ & \#1 & \#2 & \#3 & \#1 & \#2 & \#3 \\ \hline -GetEntropy & x & x & x & x & x & x \\ +PollEntropy & x & x & x & x & x & x \\ Bitmanip Instructions & x & x & x & & & \\ Scalar SHA2 & x & & x & & & \\ Scalar AES & x & & x & & & \\ @@ -41,7 +41,7 @@ \label{tab:profiles} \end{table} -The scalar profiles all implement the GetEntropy feature and +The scalar profiles all implement the PollEntropy feature and shared Bitmanip instructions. Profile $1$ includes the scalar AES/SHA2 extensions, while Profile $2$ includes the scalar SM3/SM4 extensions. @@ -53,4 +53,4 @@ (Profile 1), the ``all-round'' instructions (Profile 2), or both (Profile 3). -All vector profiles implement the GetEntropy feature. +All vector profiles implement the PollEntropy feature.