RFC 8937 - Randomness Improvements for Security Protocols 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8937.html
タイトル : RFC 8937 - セキュリティプロトコルのランダム性向上
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] 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.

この文書はインターネット標準化過程（Standards Track）の仕様ではありません。情報提供のために公開されています。

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で入手できます。

著作権表示

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://trustee.ietf.org/license-info）に関するBCP 78とIETF Trustの法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

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

1. Introduction

1. はじめに

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.

安全で適切に実装された乱数生成器、または「暗号的に安全な」疑似乱数生成器（CSPRNG）は、同じ長さのランダムな文字列と区別がつかない出力を生成する必要があります。CSPRNGは、TLSおよび関連トランスポートセキュリティプロトコルのための重要な構成要素です。特にTLSはCSPRNGを使用して、一時鍵共有や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]に触発されたセキュリティプロトコルにおけるランダム性生成への改善を提案しています。具体的には、必要に応じて生のランダム性を使用する代わりに、例えば、エフェメラルキー共有を生成する際に、当事者の長期秘密鍵を用いた関数がエントロピープールに混ぜ合わされます。NAXOS鍵交換プロトコルでは、生のランダム値 x は H(x, sk) に置き換えられます。ここで、sk は送信者の秘密鍵です。残念なことに、秘密鍵がハードウェアセキュリティモジュール（HSM）内に隔離されていることが多いので、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）に置き換えるものであり、そのキーは生のランダム値および秘密鍵署名から導出されます。実装は、a) 秘密鍵への間接的なアクセスが可能で、CSPRNGのランダム性の保証が疑わしい場合、あるいは b) ランダム性に関する将来起こりうる問題に対してより強力な保証を提供したい場合に、この技術を適用すべきである（SHOULD）。おおよそ、提案された構成によって提供されるセキュリティ特性は以下の通りである。

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を完全に制御し、提案された構成のすべての出力を観察できる攻撃者 Adv は、秘密鍵を漏洩させることにおいて無視できないほどの優位性を得ることはない（サイドチャネル攻撃がない場合）。

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）の合意を表しています。

2. Conventions Used in This Document

2. この文書で使用されている規約

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]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Randomness Wrapper

3. ランダムネスラッパー

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 の出力を生成する暗号化ハッシュ関数とする。Extract(salt, IKM) をランダム性抽出関数（例えば HKDF-Extract [RFC5869]）とし、ソルトおよび入力キーイング材料 (IKM) パラメータを受け入れて、暗号化使用に適した L バイトの疑似乱数キーを生成するものとする。それは（長さ M の鍵としてのソルトのための）安全な PRF でなければならず、IKM の均一性を保持する必要があります（詳細は [SecAnalysis] を参照）。L は固定長であるべきです（SHOULD）。Expand(k, info, n) を可変長出力 PRF（例えば HKDF-Expand [RFC5869]）とし、L バイトの疑似乱数キー k、info 文字列、および出力長 n を入力とし、n バイトの出力を生成するものとする。最後に、tag1 を固定されたコンテキスト依存文字列、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出力と固定文字列 (tag1) に対する署名から派生したキーから n バイトの乱数を展開します。ランダムネスラッパーの呼び出しごとに "tag1" と "tag2" を生成して使用する方法については、セクション4を参照してください。Expand() は、n バイトの真のランダムな文字列と計算量的に区別できない文字列を生成します。したがって、この構成のセキュリティは、H(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 内で格納され使用されている場合、署名計算はその中に実装され、他のすべての操作（ハッシュ関数の計算、Extract 関数、および Expand 関数を含む）は 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) は、ランダムネスラッパーのライフタイム中に一度だけ計算すればよく、この計算における役割を超えて使用または公開されてはならない（MUST NOT）。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]）でなければならない（MUST）。あるいは、独立した（かつ完全に信頼できる）エントロピー源を使用しなければならない（MUST）。例えば、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 などのプロトコルの暗号操作に関しては無視できるほど小さい傾向がある（G' と G を比較した場合、HKDF-Extract と 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 出力と秘密鍵のみに依存するため、可能です。

4. Tag Generation

4. タグ生成

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.

両方のタグは、秘密鍵の他の利用者や所有者と衝突しないように生成されなければなりません（MUST）。これは、たとえば、秘密鍵を持つ 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.

tag1: 使用中の特定のデバイスとプロトコルに紐付けられた定数文字列。これにより、Sig(sk, tag1) のキャッシングが可能になります。デバイス固有の情報は、例えば、メディアアクセス制御（MAC）アドレスを含み得る。仮想環境での CSPRNG の使用例でセキュリティを提供するために、仮想マシンの異なるインスタンス間（スナップショットからクローンまたは復元されたものを含む）で各 tag1 値の一意性を確保するような、プロセスに固有のすべての利用可能な情報を組み込むことを推奨します（RECOMMENDED）。これは、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) の呼び出しごとに異なることが保証されている場合に、カウンタまたはタイマを使用して実装できます。

5. Application to TLS

5. TLSへの応用

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)

6. Implementation Guidance

6. 実装ガイダンス

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 は Extract 出力長、n は希望の量のランダム性です。いくつかのアプリケーションは、n がこの境界を超えることを必要とするかもしれません。ラッパーの実装は、G' を複数回呼び出して結果を連結することによってこのユースケースをサポートできます。

7. IANA Considerations

7. IANAの考慮事項

This document has no IANA actions.

この文書にはIANAの行動がありません。

8. Security Considerations

8. セキュリティに関する考慮事項

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] でセキュリティ分析が行われた。一般的に言えば、次のセキュリティ定理が証明されている：もし Adv が、ある特定のインスタンスで生成された署名または通常の乱数のうち片方だけを知ったとしても、我々のプリミティブに関するセキュリティ仮定の下では、ラッパー構成はランダムな文字列と区別できないランダム性を出力するはずである。

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.

構成内の署名、ならびにプロトコル自体の中では、セキュリティ保証が疑わしいエントロピー源からのランダム性を使用してはいけません（MUST NOT）。したがって、署名スキームは信頼できるエントロピー源（提案された構成で改善されている CSPRNG とは独立して）を使用するか、または決定論的である必要があります（MUST）。署名が確率的であり、弱いエントロピーを使用する場合、我々の構成は役に立たず、乱数再利用攻撃（repeat randomness attacks）に対して依然として脆弱です。そのような攻撃では、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.

提案された構成は、仮想マシンのスナップショットまたはプロセスフォーキングにより CSPRNG 状態がクローン化されている場合は、セキュリティの保証を提供することはできません（[MAFS2017]参照）。tag1 は、プロセス属性、仮想マシンユーザー情報などの環境に関するすべての利用可能な情報を組み込んでいることを推奨します（RECOMMENDED）。

9. Comparison to RFC 6979

9. RFC 6979との比較

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) をナンスとして使用して、[SP80090A] および [X962] の Annex D で記述されている HMAC_DRBG 擬似乱数生成器のインスタンスを決定論的に実体化することを推奨しています。本明細書で提供される構成 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 内で実行された場合、その違いは次のように現れます。[RFC6979] で記述されている HMAC_DRBG 構成は、署名生成のために HSM 内部に実装される可能性がありますが、一方、提案された構成は、HSM に実装された署名機能を呼び出すことを想定しています。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[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>.

[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>.

[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>.

[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>.

10.2. Informative References

10.2. 参考引用

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

[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>.

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に感謝します。私たちは、John Mattsson、Martin Thomson、および Rich Salz の入念な査読と有益なコメントに感謝します。

Authors' Addresses

著者の住所

Cas Cremers CISPA Saarland Informatics Campus Saarbruecken Germany

   Email: cremers@cispa.saarland

Luke Garratt Cisco Meraki 500 Terry A Francois Blvd San Francisco, United States of America

   Email: lgarratt@cisco.com

Stanislav Smyshlyaev CryptoPro 18, Suschevsky val Moscow Russian Federation

   Email: svs@cryptopro.ru

Nick Sullivan Cloudflare 101 Townsend St San Francisco, United States of America

   Email: nick@cloudflare.com

Christopher A. Wood Cloudflare 101 Townsend St San Francisco, United States of America

   Email: caw@heapingbits.net