[要約] RFC 8937は、セキュリティプロトコルのランダム性を向上させるためのガイドラインを提供します。その目的は、攻撃者による予測や操作を防ぎ、システムの安全性を高めることにあります。この文書は、暗号化、認証、セキュリティキー生成などの場面での利用が想定されています。
Internet Research Task Force (IRTF) C. Cremers
Request for Comments: 8937 CISPA
Category: Informational L. Garratt
ISSN: 2070-1721 Cisco Meraki
S. Smyshlyaev
CryptoPro
N. Sullivan
C. Wood
Cloudflare
October 2020
Randomness Improvements for Security Protocols
セキュリティプロトコルのランダム性向上
Abstract
概要
Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.
ランダム性は、トランスポート層セキュリティ（TLS）および関連セキュリティプロトコルのための重要な要素です。弱いまたは予測可能な「暗号的に安全な」擬似乱数ジェネレータ（CSPRNG）は悪意のある目的のために虐待または悪用され得る。CSPRNGをシードする最初のエントロピーソースもまた弱くても壊れている可能性があり、それはまた重要かつ全身的なセキュリティ上の問題につながる可能性があります。このドキュメントは、セキュリティプロトコルの実装の実装が長期秘密鍵を使用してCSPRNGを増強する方法について説明します。これにより、壊れた、またはその他の方法ではCSPRNGが壊れたか、その他の方法で変換されます。
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
この文書は、IRTFのCrypto Forum Research Group（CFRG）の製品です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットリサーチタスクフォース（IRTF）の製品です。IRTFはインターネット関連の研究開発活動の結果を発行しています。これらの結果は展開には適していない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）のCryptoフォーラム研究グループの合意を表しています。IRSGによる出版承認の文書は、インターネット規格のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8937.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8937で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
3. Randomness Wrapper
4. Tag Generation
5. Application to TLS
6. Implementation Guidance
7. IANA Considerations
8. Security Considerations
9. Comparison to RFC 6979
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
Secure and properly implemented random number generators, or "cryptographically secure" pseudorandom number generators (CSPRNGs), should produce output that is indistinguishable from a random string of the same length. CSPRNGs are critical building blocks for TLS and related transport security protocols. TLS in particular uses CSPRNGs to generate several values, such as ephemeral key shares and ClientHello and ServerHello random values. CSPRNG failures, such as the Debian bug described in [DebianBug], can lead to insecure TLS connections. CSPRNGs may also be intentionally weakened to cause harm [DualEC]. Initial entropy sources can also be weak or broken, and that would lead to insecurity of all CSPRNG instances seeded with them. In such cases where CSPRNGs are poorly implemented or insecure, an adversary, Adv, may be able to distinguish its output from a random string or predict its output and recover secret key material used to protect the connection.
安全で適切に実装された乱数ジェネレータ、または「暗号的に安全な」疑似ランダム数ジェネレータ（CSPRNGS）は、同じ長さのランダムな文字列と区別がつかない出力を生成する必要があります。CSPRNGSは、TLSおよび関連トランスポートセキュリティプロトコルのための重要な構成要素です。特定のTLSはCSPRNGSを使用して、一時鍵共有とClientHelloとServerHelloのランダムな値など、いくつかの値を生成します。[DebianBug]で説明されているDebianバグなどのCSPRNGの失敗は、安全でないTLS接続につながる可能性があります。CSPRNGはまた意図的に悪化させることができ、[DUALEC]を引き起こす可能性があります。初期エントロピーソースも弱くたり壊れたりすることができ、それはそれらに播種されたすべてのCSPRNGインスタンスの不安につながるでしょう。CSPRNGが不十分な場合や不安である場合、敵対的なADVは、その出力をランダムな文字列から区別したり、その出力を予測したり、接続を保護するために使用される秘密鍵素材を回復することができる可能性があります。
This document proposes an improvement to randomness generation in security protocols inspired by the "NAXOS trick" [NAXOS]. Specifically, instead of using raw randomness where needed, e.g., in generating ephemeral key shares, a function of a party's long-term private key is mixed into the entropy pool. In the NAXOS key exchange protocol, raw random value x is replaced by H(x, sk), where sk is the sender's private key. Unfortunately, as private keys are often isolated in Hardware Security Modules (HSMs), direct access to compute H(x, sk) is impossible. Moreover, some HSM APIs may only offer the option to sign messages using a private key, yet offer no other operations involving that key. An alternate, yet functionally equivalent construction, is needed.
この文書は、「ナクソストリック」[NAXOS]に触発されたセキュリティプロトコルにおけるランダム性生成への改善を提案している。具体的には、必要に応じて生のランダム性を使用する代わりに、例えば、エフェメラルキー共有を生成する際に、当事者の長期秘密鍵の機能がエントロピープールに混在しています。NAXOS鍵交換プロトコルでは、生のランダム値XはH（X、SK）に置き換えられます。ここで、SKは送信者の秘密鍵です。残念なことに、秘密鍵がハードウェアセキュリティモジュール（HSMS）で分離されることが多いので、Compute H（X、SK）への直接アクセスは不可能です。さらに、いくつかのHSM APIは、秘密鍵を使用してメッセージに署名するオプションのみを提供することができますが、そのキーを含む他の操作は提供されません。代替で機能的に等価な構造が必要です。
The approach described herein replaces the NAXOS hash with a keyed hash, or pseudorandom function (PRF), where the key is derived from a raw random value and a private key signature. Implementations SHOULD apply this technique a) when indirect access to a private key is available and CSPRNG randomness guarantees are dubious or b) to provide stronger guarantees about possible future issues with the randomness. Roughly, the security properties provided by the proposed construction are as follows:
本明細書に記載のアプローチは、NAXOSハッシュをキー付きハッシュ、または疑似ランダム関数（PRF）に置き換えられ、そのキーは生のランダム値および秘密鍵署名から導出される。民間鍵への間接アクセスが利用可能であり、CSPRNGランダム性保証が疑わしいかB）を提供する場合は、このテクニックA）を適用する必要があります。おおよそ、提案された構造によって提供されるセキュリティ特性は以下の通りである。
1. If the CSPRNG works fine (that is, in a certain adversary model, the CSPRNG output is indistinguishable from a truly random sequence), then the output of the proposed construction is also indistinguishable from a truly random sequence in that adversary model.
1. CSPRNGがうまく動作している場合（つまり、特定の敵対モデルでは、CSPRNG出力は真にランダムなシーケンスとは限定的ではありません）、提案された構造の出力もその有害モデルで本当にランダムなシーケンスと区別がつかない。
2. Adv with full control of a (potentially broken) CSPRNG and ability to observe all outputs of the proposed construction does not obtain any non-negligible advantage in leaking the private key (in the absence of side channel attacks).
2. （潜在的に壊れた）CSPRNGの完全な制御と提案された構造のすべての出力を観察する能力を完全に制御することで、秘密鍵を漏らしても無視できない利点は得られません（サイドチャネル攻撃がない場合）。
3. If the CSPRNG is broken or controlled by Adv, the output of the proposed construction remains indistinguishable from random, provided that the private key remains unknown to Adv.
3. CSPRNGがADVによって破損または制御されている場合、提案された構造の出力はランダムとは区別がつかないままで、秘密鍵はADVに未知のままである。
This document represents the consensus of the Crypto Forum Research Group (CFRG).
この文書は、Crypto Forum Research Group（CFRG）の合意を表しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The output of a properly instantiated CSPRNG should be indistinguishable from a random string of the same length. However, as previously discussed, this is not always true. To mitigate this problem, we propose an approach for wrapping the CSPRNG output with a construction that mixes secret data into a value that may be lacking randomness.
正しくインスタンス化されたCSPRNGの出力は、同じ長さのランダムな文字列と区別がつかないはずです。ただし、前述のように、これは必ずしも真実ではありません。この問題を軽減するために、秘密データをランダム性に欠けている可能性がある値にミックスする構造でCSPRNG出力を包むためのアプローチを提案する。
Let G(n) be an algorithm that generates n random bytes, i.e., the output of a CSPRNG. Define an augmented CSPRNG G' as follows. Let Sig(sk, m) be a function that computes a signature of message m given private key sk. Let H be a cryptographic hash function that produces output of length M. Let Extract(salt, IKM) be a randomness extraction function, e.g., HKDF-Extract [RFC5869], which accepts a salt and input keying material (IKM) parameter and produces a pseudorandom key of L bytes suitable for cryptographic use. It must be a secure PRF (for salt as a key of length M) and preserve uniformness of IKM (for details, see [SecAnalysis]). L SHOULD be a fixed length. Let Expand(k, info, n) be a variable-length output PRF, e.g., HKDF-Expand [RFC5869], that takes as input a pseudorandom key k of L bytes, info string, and output length n, and produces output of n bytes. Finally, let tag1 be a fixed, context-dependent string, and let tag2 be a dynamically changing string (e.g., a counter) of L' bytes. We require that L >= n - L' for each value of tag2.
g（n）を、nランダムバイト、すなわちCSPRNGの出力を生成するアルゴリズムであることを可能にする。次のように拡張されたCSPRNG G 'を定義します。 SIG（SK、M）を秘密鍵SKを与えられたメッセージMの署名を計算する機能とする。 Hを長さMの出力を生成する暗号化ハッシュ関数であることを、抽出物（Salt、Ikm）をランダム性抽出機能、例えばHKDF抽出物[RFC5869]、例えば塩および入力キーイング材料（IKM）パラメータを受け入れて製造する。暗号化使用に適したLバイトの疑似乱数キー。それは（長さMの鍵としての塩のための）安全なPRFでなければならず、IKMの均一性を保持する必要があります（詳細は[SecAnalysis]を参照）。 lは固定長さであるべきです。 expand（k、info、n）を可変長出力PRF、例えばHKDF-Expand [RFC5869]で、Lバイト、INFO文字列、および出力長Nの疑似ランダムキーKを入力し、出力を生成します。 nバイト最後に、TAG1を固定されたコンテキスト依存ストリング、およびLERのTAG2をL 'バイトの動的に変更された文字列（例えばカウンタ）とする。 TAG2の値ごとにL> = N - L 'を必要とします。
The construction works as follows. Instead of using G(n) when randomness is needed, use G'(n), where
建設は以下のように機能します。ランダム性が必要なときにg（n）を使用する代わりに、G '（n）を使用します。
G'(n) = Expand(Extract(H(Sig(sk, tag1)), G(L)), tag2, n)
Functionally, this expands n random bytes from a key derived from the CSPRNG output and signature over a fixed string (tag1). See Section 4 for details about how "tag1" and "tag2" should be generated and used per invocation of the randomness wrapper. Expand() generates a string that is computationally indistinguishable from a truly random string of n bytes. Thus, the security of this construction depends upon the secrecy of H(Sig(sk, tag1)) and G(L). If the signature is leaked, then security of G'(n) reduces to the scenario wherein randomness is expanded directly from G(L).
機能的には、これは、CSPRNG出力から派生したキーからNランダムバイトを展開し、固定文字列（TAG1）を介して署名します。Randomnessラッパーの呼び出しごとに "tag1"と "tag2"を生成して使用する方法については、セクション4を参照してください。expand（）Nバイトの真のランダムな文字列と計算的に区切らない文字列を生成します。したがって、この構造のセキュリティは、HのSECRECY（SIG（SK、TAG1））およびG（L）に依存する。シグネチャが漏洩した場合、G '（n）のセキュリティはシナリオに減少し、ランダム性はG（L）から直接拡張されます。
If a private key sk is stored and used inside an HSM, then the signature calculation is implemented inside it, while all other operations (including calculation of a hash function, Extract function, and Expand function) can be implemented either inside or outside the HSM.
秘密鍵SKがHSM内で格納され使用されている場合、署名計算はその中に実装され、他のすべての操作（ハッシュ関数の計算、抽出関数、および拡張機能を含む）はHSMの内部または外部のいずれかで実装できます。。
Sig(sk, tag1) need only be computed once for the lifetime of the randomness wrapper and MUST NOT be used or exposed beyond its role in this computation. Additional recommendations for tag1 are given in the following section.
SIG（SK、TAG1）は、ランダムネスラッパーの寿命に対して1回だけ計算され、この計算においてその役割を超えて使用または公開されてはならない。TAG1の追加の推奨事項は、次のセクションで示しています。
Sig MUST be a deterministic signature function, e.g., deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6979], or use an independent (and completely reliable) entropy source, e.g., if Sig is implemented in an HSM with its own internal trusted entropy source for signature generation.
SIGは、決定論的な署名機能、例えば、決定論的楕円曲線デジタル署名アルゴリズム（ECDSA）[RFC6979]、またはSIGが自身の内部信頼できるエントロピーを備えたHSMに実装されている場合には、独立した（および完全に信頼性の高い）エントロピー源を使用する必要があります。署名生成のためのソース
Because Sig(sk, tag1) can be cached, the relative cost of using G'(n) instead of G(n) tends to be negligible with respect to cryptographic operations in protocols such as TLS (the relatively inexpensive computational cost of HKDF-Extract and HKDF-Expand dominates when comparing G' to G). A description of the performance experiments and their results can be found in [SecAnalysis].
SIG（SK、TAG1）をキャッシュできるため、G（N）の代わりにG '（N）を使用する相対コストは、TLSなどのプロトコルの暗号操作に関して無視できるほど無視できる傾向がある（HKDFの比較的安価な計算コスト。G '~Gを比較すると、抽出とHKDF expandは展開します。性能実験およびそれらの結果の説明は[SecAnalysis]に見出すことができる。
Moreover, the values of G'(n) may be precomputed and pooled. This is possible since the construction depends solely upon the CSPRNG output and private key.
さらに、G '（N）の値は事前計算されてプールされてもよい。構造はCSPRNG出力と秘密鍵のみに依存するため、可能です。
Both tags MUST be generated such that they never collide with another contender or owner of the private key. This can happen if, for example, one HSM with a private key is used from several servers or if virtual machines are cloned.
両方のタグは、秘密鍵の他の候補者または所有者と衝突することは決してないように生成されなければなりません。これは、たとえば、秘密鍵を持つHSMが複数のサーバーから使用されている場合、または仮想マシンがクローンになっている場合に発生する可能性があります。
The RECOMMENDED tag construction procedure is as follows:
推奨タグ構築手順は次のとおりです。
tag1: Constant string bound to a specific device and protocol in use. This allows caching of Sig(sk, tag1). Device-specific information may include, for example, a Media Access Control (MAC) address. To provide security in the cases of usage of CSPRNGs in virtual environments, it is RECOMMENDED to incorporate all available information specific to the process that would ensure the uniqueness of each tag1 value among different instances of virtual machines (including ones that were cloned or recovered from snapshots). This is needed to address the problem of CSPRNG state cloning (see [RY2010]). See Section 5 for example protocol information that can be used in the context of TLS 1.3. If sk could be used for other purposes, then selecting a value for tag1 that is different than the form allowed by those other uses ensures that the signature is not exposed.
タグ1：定数文字列使用中の特定のデバイスとプロトコルにバインドされます。これにより、SIG（SK、TAG1）のキャッシングが可能になります。デバイス固有の情報は、例えば、メディアアクセス制御（MAC）アドレスを含み得る。仮想環境でのCSPRNGSの使用例でセキュリティを提供するために、仮想マシンの異なるインスタンス間で各TAG1値の一意性を確保するプロセスに固有のすべての利用可能な情報を組み込むことをお勧めします（クローン作成または回復されたものを含むものを含む）。スナップショット）。これは、CSPRNG状態のクローニングの問題に対処するために必要です（[RY2010]を参照）。TLS 1.3のコンテキストで使用できるプロトコル情報については、セクション5を参照してください。SKを他の目的に使用できる場合は、その他の用途で許可されているフォームとは異なるTAG1の値を選択すると、署名がさらされていないことが保証されます。
tag2: A nonce, that is, a value that is unique for each use of the same combination of G(L), tag1, and sk values. The tag2 value can be implemented using a counter or a timer, provided that the timer is guaranteed to be different for each invocation of G'(n).
TAG2：ノンス、つまり、G（L）、TAG1、SK値の同じ組み合わせの使用ごとに固有の値。TAG2値は、タイマーがG '（N）の呼び出しごとに異なることが保証されている場合に、カウンタまたはタイマを使用して実装できます。
The PRF randomness wrapper can be applied to any protocol wherein a party has a long-term private key and also generates randomness. This is true of most TLS servers. Thus, to apply this construction to TLS, one simply replaces the "private" CSPRNG G(n), i.e., the CSPRNG that generates private values, such as key shares, with
PRFランダムネスラッパーは、当事者が長期秘密鍵を有する任意のプロトコルに適用することができ、またランダム性を生成する。これはほとんどのTLSサーバーに当てはまります。したがって、この構造をTLSに適用するには、「プライベート」CSPRNG g（n）、すなわちキーシェアなどのプライベート値を生成するCSPRNGを単に置き換えます。
G'(n) = HKDF-Expand(HKDF-Extract(H(Sig(sk, tag1)), G(L)), tag2, n)
Recall that the wrapper defined in Section 3 requires L >= n - L', where L is the Extract output length and n is the desired amount of randomness. Some applications may require n to exceed this bound. Wrapper implementations can support this use case by invoking G' multiple times and concatenating the results.
セクション3で定義されているラッパーにはL> = N - L 'が必要なことを思い出し、ここでLは抽出出力長、Nは希望の量のランダム性です。いくつかのアプリケーションは、nを超えるようにNを必要とするかもしれません。ラッパーの実装は、G 'を複数回呼び出して結果を連結することによってこのユースケースをサポートできます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
A security analysis was performed in [SecAnalysis]. Generally speaking, the following security theorem has been proven: if Adv learns only one of the signature or the usual randomness generated on one particular instance, then, under the security assumptions on our primitives, the wrapper construction should output randomness that is indistinguishable from a random string.
[SecAnalysis]でセキュリティ分析を行った。一般的に言えば、次のセキュリティ定理は証明されています。ランダムな文字列
The main reason one might expect the signature to be exposed is via a side-channel attack. It is therefore prudent when implementing this construction to take into consideration the extra long-term key operation if equipment is used in a hostile environment when such considerations are necessary. Hence, it is recommended to generate a key specifically for the purposes of the defined construction and not to use it another way.
主な理由は、署名がさらされることを期待するかもしれませんが、サイドチャネル攻撃を介して行われます。したがって、このような考慮事項が必要な場合は、機器が敵対的な環境で使用されている場合、この構成を実装することは慎重に、機器が敵対的な環境で使用されている場合には、長期的なキー操作を考慮に入れることができます。したがって、定義された構造の目的のために特に鍵を生成することを推奨し、それを別の方法で使用しないことを推奨します。
The signature in the construction, as well as in the protocol itself, MUST NOT use randomness from entropy sources with dubious security guarantees. Thus, the signature scheme MUST either use a reliable entropy source (independent from the CSPRNG that is being improved with the proposed construction) or be deterministic; if the signatures are probabilistic and use weak entropy, our construction does not help, and the signatures are still vulnerable due to repeat randomness attacks. In such an attack, Adv might be able to recover the long-term key used in the signature.
建設内の署名、ならびにプロトコル自体の中では、疑わしいセキュリティ保証を使用してエントロピーソースからランダム性を使用してはいけません。したがって、シグネチャスキームは信頼できるエントロピーソース（提案された構造で改善されているCSPRNGとは独立して）または決定論的である必要があります。署名が確率的であり、弱いエントロピーを使用する場合、私たちの構造は助けを助けません、そして誘導性攻撃の繰り返しのために依然として脆弱です。そのような攻撃では、ADVはシグネチャで使用されている長期キーを回復できる可能性があります。
Under these conditions, applying this construction should never yield worse security guarantees than not applying it, assuming that applying the PRF does not reduce entropy. We believe there is always merit in analyzing protocols specifically. However, this construction is generic so the analyses of many protocols will still hold even if this proposed construction is incorporated.
このような条件下で、この構造を適用することは、PRFを適用することがエントロピーを減少させないと仮定して、それを適用しないよりも悪いセキュリティ保証をもたらすべきではありません。具体的にプロトコルを分析する際に常にメリットがあると考えています。しかしながら、この構造は一般的であるので、この提案された構造が組み込まれていても多くのプロトコルの分析がまだ成長するであろう。
The proposed construction cannot provide any guarantees of security if the CSPRNG state is cloned due to the virtual machine snapshots or process forking (see [MAFS2017]). It is RECOMMENDED that tag1 incorporate all available information about the environment, such as process attributes, virtual machine user information, etc.
Proposed Constructionは、仮想マシンのスナップショットまたはプロセスフォーキングによりCSPRNG状態がクローン化されている場合は、セキュリティの保証を提供することはできません（[MAFS2017]参照）。TAG1は、プロセス属性、仮想マシンユーザー情報などの環境に関するすべての利用可能な情報を組み込んでいることをお勧めします。
The construction proposed herein has similarities with that of [RFC6979]; both of them use private keys to seed a deterministic random number generator. Section 3.3 of [RFC6979] recommends deterministically instantiating an instance of the HMAC_DRBG pseudorandom number generator, described in [SP80090A] and Annex D of [X962], using the private key sk as the entropy_input parameter and H(m) as the nonce. The construction G'(n) provided herein is similar, with such difference that a key derived from G(n) and H(Sig(sk, tag1)) is used as the entropy input and tag2 is the nonce.
ここで提案されている構成は、[RFC6979]と類似している。どちらも秘密鍵を使用して決定論的乱数発生器をシードします。[RFC6979]のセクション3.3は、秘密鍵SKをENTROPY_INPUTパラメーター、H（M）として、[X962]の[SP80090A]と[X962]の[X962]、H（M）を使用して、[SP80090A]、[X962]のインスタンスを決定していることをお勧めします。本明細書で提供される構造G '（n）は類似しており、このような違いは、g（n）およびh（sig（sk、tag1））から導出されたキーがエントロピー入力として使用され、TAG2が無断であると類似している。
However, the semantics and the security properties obtained by using these two constructions are different. The proposed construction aims to improve CSPRNG usage such that certain trusted randomness would remain even if the CSPRNG is completely broken. Using a signature scheme that requires entropy sources according to [RFC6979] is intended for different purposes and does not assume possession of any entropy source -- even an unstable one. For example, if in a certain system all private key operations are performed within an HSM, then the differences will manifest as follows: the HMAC_DRBG construction described in [RFC6979] may be implemented inside the HSM for the sake of signature generation, while the proposed construction would assume calling the signature implemented in the HSM.
しかしながら、これら2つの構造を使用して得られた意味論およびセキュリティ特性は異なる。提案された建設は、CSPRNGが完全に壊れていても特定の信頼されたランダム性が残るようにCSPRNGの使用を改善することを目的としています。[RFC6979]に従ってエントロピーソースを必要とするシグネチャスキームを使用することは、異なる目的のために意図されており、エントロピーソースを所有していない - 不安定なものでもありません。たとえば、特定のシステムですべての秘密鍵操作がHSM内で実行された場合、その違いは次のようにマニフェストで表示されます。建設は、HSMに実装された署名を呼び出すと仮定します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869] Krawczyk、H.およびP. Eronen、「HMACベースの抽出と拡張キー派生機能（HKDF）」、RFC 5869、DOI 10.17487 / RFC 5869、2010年5月、<https：//www.rfc-編集者.org / info / rfc5869>。
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979] PornIn、T.、「デジタル署名アルゴリズム（DSA）および楕円曲線デジタル署名アルゴリズム（ECDSA）」、RFC 6979、DOI 10.17487 / RFC6979、<https：///www.rfc-の決定論的使用editor.org/info/rfc6979>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[DebianBug] Yilek, S., Rescorla, E., Shacham, H., Enright, B., and S. Savage, "When private keys are public: results from the 2008 Debian OpenSSL vulnerability", ICM '09, DOI 10.1145/1644893.1644896, November 2009, <https://pdfs.semanticscholar.org/fcf9/ fe0946c20e936b507c023bbf89160cc995b9.pdf>.
[DebianBug] Yilek、S.、Rescorla、E.、Shacham、H.、Enright、B.、S. Savage、「秘密鍵が公開されている場合：2008 Debian OpenSSLの脆弱性」、ICM '09、DOI 10.11452009年11月、<https://pdfs.semanticscholar.org/fcf9/ fe0946c20e936b907c023bbf89160cc995b9.pdf>。
[DualEC] Bernstein, D., Lange, T., and R. Niederhagen, "Dual EC: A Standardized Back Door", DOI 10.1007/978-3-662-49301-4_17, March 2016, <https://projectbullrun.org/dual-ec/documents/ dual-ec-20150731.pdf>.
[Dualec] Bernstein、D.、Lange、T.、R. Niederhagen、「デュアルEC：標準化されたバックドア」、DOI 10.1007 / 978-3-662-49301-4_17、2016年3月、<https：// ProjectBullRun.ORG / DUAL-EC /文書/ DUAL-EC-20150731.PDF>。
[MAFS2017] McGrew, D., Anderson, B., Fluhrer, S., and C. Schenefiel, "PRNG Failures and TLS Vulnerabilities in the Wild", January 2017, <https://rwc.iacr.org/2017/Slides/david.mcgrew.pptx>.
[MAFS2017] McGrew、D.、Anderson、B.、Fluhrer、S.、およびC.Schenefiel、「野生のPRNGの失敗とTLSの脆弱性」、2017年1月、<https：//rwc.iacr.org/2017/スライド/ david.mcgrew.pptx>。
[NAXOS] LaMacchia, B., Lauter, K., and A. Mityagin, "Stronger Security of Authenticated Key Exchange", DOI 10.1007/978-3-540-75670-5_1, November 2007, <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/strongake-submitted.pdf>.
[NAXOS]ラマッチ、B.、Lauter、K。、およびA.Mityagin、「認証鍵交換の強化されたセキュリティ」、2007年11月11日、<https：// www。microsoft.com/jaus-us/research/wp-content/uploads/2016/02/strongake-submitted.pdf>。
[RY2010] Ristenpart, T. and S. Yilek, "When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography", January 2010, <https://rist.tech.cornell.edu/papers/sslhedge.pdf>.
[RY2010] RistenPart、T.およびS. Yilek、「ランダム性が悪い場合：仮想マシンリセット脆弱性とヘッジ展開暗号化」、2010年1月、<https：//rist.tech.cornell.edu/papers/sslhedge.pdf>。
[SecAnalysis] Akhmetzyanova, L., Cremers, C., Garratt, L., Smyshlyaev, S., and N. Sullivan, "Limiting the impact of unreliable randomness in deployed security protocols", DOI 10.1109/CSF49147.2020.00027, IEEE 33rd Computer Security Foundations Symposium (CSF), Boston, MA, USA, pp. 385-393, 2020, <https://doi.org/10.1109/CSF49147.2020.00027>.
[SecAnalysis] Akhmetzyanova、L.、Cremers、C.、Garratt、L.、SmyShlyaev、S.、およびN.Sullivan、「展開されたセキュリティプロトコルの信頼性の低いランダム性の影響の制限」、DOI 10.1109 / CSF49147.2020.00027、IEEE 33RDコンピュータセキュリティ基礎シンポジウム（CSF）、Boston、MA、USA、PP。385-393,2020、<https://doi.org/10.1109/csf49147.2020.00027>。
[SP80090A] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Special Publication 800-90A Revision 1", DOI 10.6028/NIST.SP.800-90Ar1, June 2015, <https://doi.org/10.6028/NIST.SP.800-90Ar1>.
[SP80090A]国立標準化研究所、「決定論的ランダムビットジェネレータを使用した乱数生成の推奨事項、特別発表800-90Aリビジョン1」、DOI 10.6028 / NIST.SP.800-90AR1、<https：//doi.org/10.6028/nist.sp.800-90ar1>。
[X962] American National Standard for Financial Services (ANSI), "Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005, <https://www.techstreet.com/standards/ x9-x9-62-2005?product_id=1327225>.
[X962]米国金融サービス（ANSI）、「金融サービス業の公開鍵暗号化、楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、2005年11月、<https：//www.techstreet.com /標準/ x9-x9-62-2005？Product_ID = 1327225>。
Acknowledgements
謝辞
We thank Liliya Akhmetzyanova for her deep involvement in the security assessment in [SecAnalysis]. We thank John Mattsson, Martin Thomson, and Rich Salz for their careful readings and useful comments.
[SecAnalysis]のセキュリティ評価に深い関与のためにLiliya Akhmetzyanovaに感謝します。私たちは彼らの慎重な読みと役に立つコメントのために、Martin Thomson、そして豊かなSalzに感謝します。
Authors' Addresses
著者の住所
Cas Cremers CISPA Saarland Informatics Campus Saarbruecken Germany
Cas Cremers Cispa Saarland Informatics Campus Saarbrueckenドイツ
Email: cremers@cispa.saarland
Luke Garratt Cisco Meraki 500 Terry A Francois Blvd San Francisco, United States of America
Luke Garratt Cisco Meraki 500 Terry A Francois Blvdサンフランシスコ、アメリカ合衆国
Email: lgarratt@cisco.com
Stanislav Smyshlyaev CryptoPro 18, Suschevsky val Moscow Russian Federation
Stanislav Smyshlyaev Cryptopro 18、Suschevsky Val Moscowロシア連邦
Email: svs@cryptopro.ru
Nick Sullivan Cloudflare 101 Townsend St San Francisco, United States of America
Nick Sullivan Cloudflare 101 TownSend Stサンフランシスコ、アメリカ合衆国
Email: nick@cloudflare.com
Christopher A. Wood Cloudflare 101 Townsend St San Francisco, United States of America
Christopher A. Wood CloudFlare 101 TownSend Stサンフランシスコ、アメリカ合衆国
Email: caw@heapingbits.net