RFC4344 日本語訳
4344 The Secure Shell (SSH) Transport Layer Encryption Modes. M.Bellare, T. Kohno, C. Namprempre. January 2006. (Format: TXT=27521 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Bellare Request for Comments: 4344 T. Kohno Category: Standards Track UC San Diego C. Namprempre Thammasat University January 2006
Bellareがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4344年のT.河野カテゴリ: 標準化過程UCサンディエゴC.Namprempreタマサート大学2006年1月
The Secure Shell (SSH) Transport Layer Encryption Modes
セキュア・シェル(セキュアシェル (SSH))トランスポート層暗号化モード
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.
研究者は、現在のSSH Transportプロトコルの認証された暗号化部分がいくつかの攻撃に被害を受け易いと発見しました。
This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey.
このドキュメントは、Secureシェル(SSH)輸送プロトコルのために新しい左右対称の暗号化メソッドを説明して、SSH実装はどれくらい頻繁にrekeyを与えるべきであるかに関して特定の推薦を与えます。
Table of Contents
目次
1. Introduction ....................................................2 2. Conventions Used in This Document ...............................2 3. Rekeying ........................................................2 3.1. First Rekeying Recommendation ..............................3 3.2. Second Rekeying Recommendation .............................3 4. Encryption Modes ................................................3 5. IANA Considerations .............................................6 6. Security Considerations .........................................6 6.1. Rekeying Considerations ....................................7 6.2. Encryption Method Considerations ...........................8 Normative References ...............................................9 Informative References ............................................10
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. Rekeyingします…2 3.1. 最初に、Rekeying推薦…3 3.2. 第2Rekeying推薦…3 4. 暗号化モード…3 5. IANA問題…6 6. セキュリティ問題…6 6.1. 問題をRekeyingします…7 6.2. 暗号化メソッド問題…8 標準の参照…9 有益な参照…10
Bellare, et al. Standards Track [Page 1] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[1ページ]。
1. Introduction
1. 序論
The symmetric portion of the SSH Transport Protocol was designed to provide both privacy and integrity of encapsulated data. Researchers ([DAI,BKN1,BKN2]) have, however, identified several security problems with the symmetric portion of the SSH Transport Protocol, as described in [RFC4253]. For example, the encryption mode specified in [RFC4253] is vulnerable to a chosen-plaintext privacy attack. Additionally, if not rekeyed frequently enough, the SSH Transport Protocol may leak information about payload data. This latter property is true regardless of what encryption mode is used.
SSH Transportプロトコルの左右対称の部分は、プライバシーとカプセル化されたデータの保全の両方を提供するように設計されました。 しかしながら、研究者([DAI、BKN1、BKN2])はSSH Transportプロトコルの左右対称の部分といくつかの警備上の問題を同一視しました、[RFC4253]で説明されるように。 例えば、[RFC4253]で指定された暗号化モードは選ばれた平文プライバシー攻撃に被害を受け易いです。 さらに、十分頻繁に「再-合わせ」られないなら、SSH Transportプロトコルはペイロードデータに関して情報を漏らすかもしれません。 どんな暗号化モードが使用されているかにかかわらずこの後者の特性は本当です。
In [BKN1,BKN2], Bellare, Kohno, and Namprempre show how to modify the symmetric portion of the SSH Transport Protocol so that it provably preserves privacy and integrity against chosen-plaintext, chosen- ciphertext, and reaction attacks. This document instantiates the recommendations described in [BKN1,BKN2].
[BKN1、BKN2]では、Bellare、河野、およびNamprempreが、どのようにSSH Transportプロトコルの左右対称の部分を変更するかを示すので、それは選ばれた平文の、そして、選ばれた暗号文、および反応攻撃に対してプライバシーと保全を証明可能に保持します。 このドキュメントは[BKN1、BKN2]で説明された推薦を例示します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The used data types and terminology are specified in the architecture document [RFC4251].
中古のデータ型と用語はアーキテクチャドキュメント[RFC4251]で指定されます。
The SSH Transport Protocol is specified in the transport document [RFC4253].
SSH Transportプロトコルは運送書類[RFC4253]で指定されます。
3. Rekeying
3. Rekeyingします。
Section 9 of [RFC4253] suggests that SSH implementations rekey after every gigabyte of transmitted data. [RFC4253] does not, however, discuss all the problems that could arise if an SSH implementation does not rekey frequently enough. This section serves to strengthen the suggestion in [RFC4253] by giving firm upper bounds on the tolerable number of encryptions between rekeying operations. In Section 6, we discuss the motivation for these rekeying recommendations in more detail.
[RFC4253]のセクション9は伝えられたデータのあらゆるギガバイトの後にそのSSH実装rekeyを示します。 しかしながら、[RFC4253]はSSH実装が十分頻繁にどんなrekeyもしないなら起こるかもしれないすべての問題について議論しません。 このセクションは、操作を「再-合わせ」ることの間の暗号化の許容できる数で堅い上限を与えることによって[RFC4253]での提案を強化するのに役立ちます。 セクション6では、私たちは、さらに詳細に推薦を「再-合わせ」ながら、これらに関する動機について議論します。
This section makes two recommendations. Informally, the first recommendation is intended to protect against possible information leakage through the MAC tag, and the second recommendation is intended to protect against possible information leakage through the block cipher. Note that, depending on the block length of the
このセクションは2つの推薦状をします。 非公式に、最初の推薦がMACタグを通した可能な情報漏出から守ることを意図して、2番目の推薦がブロック暗号を通した可能な情報漏出から守ることを意図します。 ブロック長に依存するそれに注意します。
Bellare, et al. Standards Track [Page 2] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[2ページ]。
underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or vice versa.
基本的なブロック暗号と暗号化されたパケットの長さ、最初の推薦は2番目の推薦に取って代わるかもしれませんか、逆もまた同様です。
3.1. First Rekeying Recommendation
3.1. 最初に、Rekeying推薦
Because of possible information leakage through the MAC tag, SSH implementations SHOULD rekey at least once every 2**32 outgoing packets. More explicitly, after a key exchange, an SSH implementation SHOULD NOT send more than 2**32 packets before rekeying again.
MACタグ、少なくともSSH実装SHOULD rekeyを通した可能な情報漏出、かつての2つの**32出発しているパケット毎。 より明らかに、SSH実装SHOULD NOTは再び「再-合わせ」る前に、主要な交換の後に、2**32パケット以上を送ります。
SSH implementations SHOULD also attempt to rekey before receiving more than 2**32 packets since the last rekey operation. The preferred way to do this is to rekey after receiving more than 2**31 packets since the last rekey operation.
また、2以上を受け取る前に、SSH実装SHOULDは最後のrekey操作以来の**32のパケットをrekeyに試みます。 2**31パケット以上を受けた後に、最後のrekey操作以来rekeyにはこれをする都合のよい方法があります。
3.2. Second Rekeying Recommendation
3.2. 第2Rekeying推薦
Because of a birthday property of block ciphers and some modes of operation, implementations must be careful not to encrypt too many blocks with the same encryption key.
ブロック暗号といくつかの運転モードの誕生日の特性のために、実装は、同じ暗号化キーであまりに多くのブロックを暗号化しないように慎重でなければなりません。
Let L be the block length (in bits) of an SSH encryption method's block cipher (e.g., 128 for AES). If L is at least 128, then, after rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4) blocks before rekeying again. If L is at least 128, then SSH implementations should also attempt to force a rekey before receiving more than 2**(L/4) blocks. If L is less than 128 (which is the case for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, although it may be too expensive to rekey every 2**(L/4) blocks, it is still advisable for SSH implementations to follow the original recommendation in [RFC4253]: rekey at least once for every gigabyte of transmitted data.
LがSSH暗号化メソッドのブロック暗号(例えば、AESのための128)のブロック長(ビットの)であることをさせてください。 次に、「再-合わせ」た後にLが少なくとも128であるなら、SHOULD NOTが再び「再-合わせ」る2つ以上の**(L/4)ブロック以上前に暗号化するSSH実装です。 また、Lが少なくとも128であるなら、当時のSSH実装は、2つ以上の**(L/4)ブロック以上を受け取る前にrekeyを強制するのを試みるべきです。 Lが128(3DESや、Blowfishや、キャスト-128や、IDEAなどの、より古い暗号のためのケースである)未満であるなら、それは2つの**(L/4)ブロック毎にrekeyに高価過ぎるかもしれませんが、次に、SSH実装が[RFC4253]でオリジナルの推薦に続くのは、まだ賢明です: 伝えられたデータのあらゆるギガバイトのために少なくとも一度rekeyします。
Note that if L is less than or equal to 128, then the recommendation in this subsection supersedes the recommendation in Section 3.1. If an SSH implementation uses a block cipher with a larger block size (e.g., Rijndael with 256-bit blocks), then the recommendations in Section 3.1 may supersede the recommendations in this subsection (depending on the lengths of the packets).
この小区分における推薦がLが128以下であるならセクション3.1で推薦に取って代わることに注意してください。 SSH実装が、より大きいブロック・サイズ(例えば、256ビットのブロックがあるラインダール)があるブロック暗号を使用するなら、セクション3.1における推薦はこの小区分における推薦に取って代わるかもしれません(パケットの長さによって)。
4. Encryption Modes
4. 暗号化モード
This document describes new encryption methods for use with the SSH Transport Protocol. These encryption methods are in addition to the encryption methods described in Section 6.3 of [RFC4253].
このドキュメントはSSH Transportプロトコルとの使用のための新しい暗号化メソッドを説明します。 これらの暗号化メソッドは[RFC4253]のセクション6.3で説明された暗号化メソッドに加えています。
Bellare, et al. Standards Track [Page 3] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[3ページ]。
Recall from [RFC4253] that the encryption methods in each direction of an SSH connection MUST run independently of each other and that, when encryption is in effect, the packet length, padding length, payload, and padding fields of each packet MUST be encrypted with the chosen method. Further recall that the total length of the concatenation of the packet length, padding length, payload, and padding MUST be a multiple of the cipher's block size when the cipher's block size is greater than or equal to 8 bytes (which is the case for all of the following methods).
[RFC4253]から、SSH接続の各方向への暗号化メソッドが互いの如何にかかわらず稼働しなければならなくて、暗号化が有効であるときにパケット長と、詰め物の長さと、ペイロードと、それぞれのパケットの分野を水増しするのが選ばれたメソッドで暗号化されたに違いないと思い出してください。 暗号のブロック・サイズが8バイト(以下のメソッドのすべてのためのケースである)以上であるときに、長さを水増しすることでのペイロード、および詰め物がそうしなければならないパケット長の連結の全長が暗号のブロック・サイズの倍数であるとさらに思い出してください。
This document describes the following new methods:
このドキュメントは以下の新しいメソッドを説明します:
aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode twofish128-ctr OPTIONAL Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr OPTIONAL Serpent in SDCTR mode, with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode, with 128-bit key
SDCTRモードによるSDCTRモードtwofish128-ctr OPTIONAL TwofishによるSDCTRモードフグ-ctr OPTIONAL Blowfishによる256ビットの主要な3des-ctr RECOMMENDED Three主要な3DESと192ビットの主要なaes256-ctr RECOMMENDED AESと128ビットの主要なaes192-ctr RECOMMENDED AESがあるSDCTRモードによるaes128-ctr RECOMMENDED AES(ラインダール); SDCTRモードによる256ビットの主要なserpent128-ctr OPTIONAL Serpentと192ビットの主要なtwofish256-ctr OPTIONAL Twofish、SDCTRモードによるSDCTRモードcast128-ctr OPTIONALキャスト-128による256ビットの主要な考え-ctr OPTIONAL IDEAがある192ビットの主要なserpent256-ctr OPTIONAL Serpentと128ビットの主要なserpent192-ctr OPTIONAL Serpent、128ビットのキーがある128ビットの主要なtwofish192-ctr OPTIONAL Twofishと共に
The label <cipher>-ctr indicates that the block cipher <cipher> is to be used in "stateful-decryption counter" (SDCTR) mode. Let L be the block length of <cipher> in bits. In stateful-decryption counter mode, both the sender and the receiver maintain an internal L-bit counter X. The initial value of X should be the initial IV (as computed in Section 7.2 of [RFC4253]) interpreted as an L-bit unsigned integer in network-byte-order. If X=(2**L)-1, then "increment X" has the traditional semantics of "set X to 0." We use the notation <X> to mean "convert X to an L-bit string in network- byte-order." Naturally, implementations may differ in how the internal value X is stored. For example, implementations may store X as multiple unsigned 32-bit counters.
ラベル<暗号>-ctrは、ブロック暗号<暗号>が「stateful-復号化カウンタ」(SDCTR)モードで使用されることになっているのを示します。 Lがビットの<暗号>のブロック長であることをさせてください。 stateful-復号化カウンタモードで、送付者と受信機の両方が内部のL-ビットカウンタX.を維持します。Xの初期の値はネットワークバイトオーダーにおけるLで噛み付いている符号のない整数として解釈された初期のIVであるべきです([RFC4253]のセクション7.2で計算されるように)。 Xが-1と等しいなら(2**L)、「増分X」には、「0へのセットX」の伝統的な意味論があります。 私たちは、「ネットワークバイトオーダーにおけるL-ビット列にXを変換します」と意味するのに記法<X>を使用します。 当然、内部の値Xがどう保存されるかに実装は異なるかもしれません。 例えば、実装は複数の未署名の32ビットのカウンタとしてXを保存するかもしれません。
To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each blocks of length L), the encryptor first encrypts <X> with <cipher> to obtain a block B1. The block B1 is then XORed with P1 to generate the ciphertext block C1. The counter X is then incremented, and the process is repeated for each subsequent block in order to generate
パケットP=P1を暗号化するために||P2||...||… どこP1、P2、Pnはそれぞれであるか。Pn、(長さL)、ブロックの暗号化する人は、最初に、ブロックB1を入手するために<暗号>で<X>を暗号化します。 そして、ブロックB1は暗号文ブロックがC1であると生成するP1とXORedです。 次に、カウンタXが増加されて、プロセスがそれぞれのその後のブロックに繰り返される、生成する。
Bellare, et al. Standards Track [Page 4] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[4ページ]。
the entire ciphertext C=C1||C2||...||Cn corresponding to the packet P. Note that the counter X is not included in the ciphertext. Also note that the keystream can be pre-computed and that encryption is parallelizable.
全体の暗号文CはC1と等しいです。||C2||...||カウンタXがP.Noteですが、暗号文に含まれていて、パケットに対応するCn。 また、keystreamをあらかじめ計算できて、その暗号化がparallelizableであることに注意してください。
To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also maintains its own copy of X) first encrypts its copy of <X> with <cipher> to generate a block B1 and then XORs B1 to C1 to get P1. The decryptor then increments its copy of the counter X and repeats the above process for each block to obtain the plaintext packet P=P1||P2||...||Pn. As before, the keystream can be pre-computed, and decryption is parallelizable.
暗号文Cが=C1であると解読するために||C2||...||Cn、decryptor(また、それ自身のXのコピーを維持する)は最初に、P1を手に入れるためにブロックB1と次にXORs B1をC1に生成するために<暗号>で<X>のコピーを暗号化します。 decryptorは、次に、カウンタXのコピーを増加して、各ブロックが平文パケットP=P1を入手するように、上のプロセスを繰り返します。||P2||...||Pn。 従来と同様、keystreamをあらかじめ計算できます、そして、復号化はparallelizableです。
The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes.
"aes128-ctr"メソッドは128ビットのキー[AES]があるAES(エー・イー・エス、以前ラインダール)を使用します。 ブロック・サイズは16バイトです。
At this time, it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged.
このとき、aes128-ctrはREQUIREDになるように将来の仕様は促進されそうでしょう。 このアルゴリズムの実装は非常に強く奨励されます。
The "aes192-ctr" method uses AES with 192-bit keys.
"aes192-ctr"メソッドは192ビットのキーがあるAESを使用します。
The "aes256-ctr" method uses AES with 256-bit keys.
"aes256-ctr"メソッドは256ビットのキーがあるAESを使用します。
The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). The block size is 8 bytes. This algorithm is defined in [DES].
"3des-ctr"メソッドが3主要な三重のDESを使用する、(暗号化、-、解読する、-、暗号化、)、キーの最初の8バイトが最初の暗号化に使用されるところの復号化のための次の8バイト、および最終的な暗号化のための以下の8バイト。 これは24バイトの重要なデータ(168ビットは実際にそこに使用される)を必要とします。 ブロック・サイズは8バイトです。 このアルゴリズムは[DES]で定義されます。
The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER]. The block size is 8 bytes. (Note that "blowfish-cbc" from [RFC4253] uses 128-bit keys.)
「フグ-ctr」メソッドは256ビットのキー[シュナイアー]があるBlowfishを使用します。 ブロック・サイズは8バイトです。 ([RFC4253]からの「フグ-cbc」が128ビットのキーを使用することに注意してください。)
The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The block size is 16 bytes.
"twofish128-ctr"メソッドは128ビットのキー[TWOFISH]があるTwofishを使用します。 ブロック・サイズは16バイトです。
The "twofish192-ctr" method uses Twofish with 192-bit keys.
"twofish192-ctr"メソッドは192ビットのキーがあるTwofishを使用します。
The "twofish256-ctr" method uses Twofish with 256-bit keys.
"twofish256-ctr"メソッドは256ビットのキーがあるTwofishを使用します。
The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] with 128-bit keys. The block size is 16 bytes.
"serpent128-ctr"メソッドは128ビットのキーがあるSerpentブロック暗号[SERPENT]を使用します。 ブロック・サイズは16バイトです。
The "serpent192-ctr" method uses Serpent with 192-bit keys.
"serpent192-ctr"メソッドは192ビットのキーがあるSerpentを使用します。
Bellare, et al. Standards Track [Page 5] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[5ページ]。
The "serpent256-ctr" method uses Serpent with 256-bit keys.
"serpent256-ctr"メソッドは256ビットのキーがあるSerpentを使用します。
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. The block size is 8 bytes.
「考え-ctr」メソッドはIDEA暗号[シュナイアー]を使用します。 ブロック・サイズは8バイトです。
The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys [RFC2144]. The block size is 8 bytes.
"cast128-ctr"メソッドは128ビットのキー[RFC2144]があるキャスト-128暗号を使用します。 ブロック・サイズは8バイトです。
5. IANA Considerations
5. IANA問題
The thirteen encryption algorithm names defined in Section 4 have been added to the Secure Shell Encryption Algorithm Name registry established by Section 4.11.1 of [RFC4250].
セクション4で定義された13の暗号化アルゴリズム名が.1セクション4.11[RFC4250]によって確立されたSecureシェルEncryption Algorithm Name登録に加えられます。
6. Security Considerations
6. セキュリティ問題
This document describes additional encryption methods and recommendations for the SSH Transport Protocol [RFC4253]. [BKN1,BKN2] prove that if an SSH application incorporates the methods and recommendations described in this document, then the symmetric cryptographic portion of that application will resist a large class of privacy and integrity attacks.
このドキュメントはSSH Transportプロトコル[RFC4253]のための追加暗号化メソッドと推薦について説明します。 [BKN1、BKN2]は、SSHアプリケーションが本書では説明されたメソッドと推薦を取り入れるとそのアプリケーションの左右対称の暗号の部分が多人数のクラスのプライバシーと保全攻撃に抵抗すると立証します。
This section is designed to help implementors understand the security-related motivations for, as well as possible consequences of deviating from, the methods and recommendations described in this document. Additional motivation and discussion, as well as proofs of security, appear in the research papers [BKN1,BKN2].
このセクションは作成者がセキュリティ関連の動機を理解している助けに設計されています、逸脱する可能な結果と同様に本書では説明されたメソッドと推薦。 セキュリティの証拠と同様に、追加動機と議論は研究論文[BKN1、BKN2]に載っています。
Please note that the notion of "prove" in the context of [BKN1,BKN2] is that of practice-oriented reductionist security: if an attacker is able to break the symmetric portion of the SSH Transport Protocol using a certain type of attack (e.g., a chosen-ciphertext attack), then the attacker will also be able to break one of the transport protocol's underlying components (e.g., the underlying block cipher or MAC). If we make the reasonable assumption that the underlying components (such as AES and HMAC-SHA1) are secure, then the attacker against the symmetric portion of the SSH protocol cannot be very successful (since otherwise there would be a contradiction). Please see [BKN1,BKN2] for details. In particular, attacks are not impossible, just extremely improbable (unless the building blocks, like AES, are insecure).
それに注意してください、概念、[BKN1、BKN2]の文脈での「立証」は習慣指向の減少者セキュリティのものです: また、攻撃者が、あるタイプの攻撃(例えば、選ばれた暗号文攻撃)を使用することでSSH Transportプロトコルの左右対称の部分を壊すことができると、攻撃者はトランスポート・プロトコルの基本的なコンポーネント(例えば、基本的なブロックの暗号かMAC)の1つを壊すことができるでしょう。 私たちが基本的なコンポーネント(AESやHMAC-SHA1などの)が安全であるという妥当な想定をするなら、SSHプロトコルの左右対称の部分に対する攻撃者はそれほどうまくいっているはずがありません(そうでなければ、矛盾があるでしょう、したがって)。 詳細に関して[BKN1、BKN2]を見てください。 特に、攻撃は、不可能でなくて、ただ非常にありそうもないです(ブロックがAESのように不安定でない場合)。
Note also that cryptography often plays only a small (but critical) role in an application's overall security. In the case of the SSH Transport Protocol, even though an application might implement the symmetric portion of the SSH protocol exactly as described in this document, the application may still be vulnerable to non-protocol-
また、その暗号がしばしばアプリケーションの総合的なセキュリティにおける小さくて(重要)の役割だけを果たすことに注意してください。 アプリケーションがそうするかもしれませんが、SSH Transportプロトコルの場合では、ちょうど説明されるとしての本書では、アプリケーションがまだ被害を受け易いかもしれないSSHプロトコルの左右対称の部分を実装してください、非、-議定書を作ってください、-
Bellare, et al. Standards Track [Page 6] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[6ページ]。
based attacks (as an egregious example, an application might save cryptographic keys in cleartext to an unprotected file). Consequently, even though the methods described herein come with proofs of security, developers must still execute caution when developing applications that implement these methods.
ベースの攻撃(ひどい例として、アプリケーションはcleartextに保護のないファイルに暗号化キーを保存するかもしれません)。 その結果、ここに説明されたメソッドはセキュリティの証拠と共に来ますが、これらのメソッドを実装するアプリケーションを開発するとき、開発者はまだ警告を実行しなければなりません。
6.1. Rekeying Considerations
6.1. 問題をRekeyingします。
Section 3 of this document makes two rekeying recommendations: (1) rekey at least once every 2**32 packets, and (2) rekey after a certain number of encrypted blocks (e.g., 2**(L/4) blocks if the block cipher's block length L is at least 128 bits). The motivations for recommendations (1) and (2) are different, and we consider each recommendation in turn. Briefly, (1) is designed to protect against information leakage through the SSH protocol's underlying MAC, and (2) is designed to protect against information leakage through the SSH protocol's underlying encryption scheme. Please note that, depending on the encryption method's block length L and the number of blocks encrypted per packet, recommendation (1) may supersede recommendation (2) or vice versa.
このドキュメントのセクション3は2つの「再-合わせ」る推薦状をします: (1) 少なくとも一度あらゆる2**32のパケット、および(2)が、ある数の暗号化されたブロック(例えば、(L/4)がブロック暗号のブロック長Lが少なくとも128ビットであるなら妨げる2**)の後にrekeyするrekey。 推薦(1)と(2)に関する動機は異なっています、そして、私たちは順番に各推薦を考えます。 簡潔に、(1)はSSHプロトコルの基本的なMACを通した情報漏出から守るように設計されています、そして、(2)は、SSHプロトコルの基本的な暗号化体系を通した情報漏出から守るように設計されています。 暗号化メソッドのブロック長Lとパケット単位で暗号化されたブロックの数によって、推薦(1)は推薦(2)に取って代わるかもしれませんか、または逆もまた同様です。
Recommendation (1) states that SSH implementations should rekey at least once every 2**32 packets. If more than 2**32 packets are encrypted and MACed by the SSH Transport Protocol between rekeyings, then the SSH Transport Protocol may become vulnerable to replay and re-ordering attacks. This means that an adversary may be able to convince the receiver to accept the same message more than once or to accept messages out of order. Additionally, the underlying MAC may begin to leak information about the protocol's payload data. In more detail, an adversary looks for a collision between the MACs associated to two packets that were MACed with the same 32-bit sequence number (see Section 4.4 of [RFC4253]). If a collision is found, then the payload data associated with those two ciphertexts is probably identical. Note that this problem occurs regardless of how secure the underlying encryption method is. Also note that although compressing payload data before encrypting and MACing and the use of random padding may reduce the risk of information leakage through the underlying MAC, compression and the use of random padding will not prevent information leakage. Implementors who decide not to rekey at least once every 2**32 packets should understand these issues. These issues are discussed further in [BKN1,BKN2].
推薦(1)は、SSH実装が少なくとも一度あらゆる2*をrekeyするべきであると述べます。*32パケット。 次に、SSH Transportプロトコルがrekeyingsの間のSSH Transportプロトコルによる2**暗号化された32のパケットとMACedより再演するために被害を受け易くなるかもしれなくて、再注文が攻撃されるなら。 これは、敵が、同じメッセージが一度より多いと受け入れるか、またはメッセージが不適切であると受け入れるように受信機に納得させることができるかもしれないことを意味します。 さらに、基本的なMACはプロトコルのペイロードデータに関して情報を漏らし始めるかもしれません。 さらに詳細に、敵は同じ32ビットの一連番号があるMACedであった2つのパケットに関連づけられたMACsの間の衝突を探します([RFC4253]のセクション4.4を見てください)。 衝突が見つけられるなら、それらの2つの暗号文に関連しているペイロードデータはたぶん同じです。 基本的な暗号化メソッドがどれくらい安全であるかにかかわらずこの問題が起こることに注意してください。 また、無作為の詰め物の暗号化、MACing、および使用が基本的なMACを通した情報漏出の危険を減少させるかもしれない前にペイロードデータを圧縮しますが、無作為の詰め物の圧縮と使用が情報漏出を防がないことに注意してください。 少なくともかつてのrekeyへの2つの**32パケット毎ではなく、決める作成者がこれらの問題を理解するべきです。 [BKN1、BKN2]で、より詳しくこれらの問題について議論します。
One alternative to recommendation (1) would be to make the SSH Transport Protocol's sequence number more than 32 bits long. This document does not suggest increasing the length of the sequence number because doing so could hinder interoperability with older versions of the SSH protocol. Another alternative to recommendation (1) would be to switch from basic HMAC to a another MAC, such as a
推薦(1)への1つの選択肢はSSH Transportをプロトコルの長さ32ビット以上の一連番号にするだろうことです。 このドキュメントは、そうするのがSSHプロトコルの旧式のバージョンで相互運用性を妨げるかもしれないので一連番号の長さを増強するのを示しません。 推薦(1)への別の代替手段はaなどの別のMACを基本的なHMACからaに切り換えるだろうことです。
Bellare, et al. Standards Track [Page 7] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[7ページ]。
MAC that has its own internal counter. Because of the 32-bit counter already present in the protocol, such a counter would only need to be incremented once every 2**32 packets.
自分自身のを内部にするMACが反対します。 カウンタがプロトコル、カウンタが一度増加されるように必要とするだけであるそのようなものに既にあらゆる2**を提示する32ビット32のパケットのために。
Recommendation (2) states that SSH implementations should rekey before encrypting more than 2**(L/4) blocks with the same key (assuming L is at least 128). This recommendation is designed to minimize the risk of birthday attacks against the encryption method's underlying block cipher. For example, there is a theoretical privacy attack against stateful-decryption counter mode if an adversary is allowed to encrypt approximately 2**(L/2) messages with the same key. It is because of these birthday attacks that implementors are highly encouraged to use secure block ciphers with large block lengths. Additionally, recommendation (2) is designed to protect an encryptor from encrypting more than 2**L blocks with the same key. The motivation here is that, if an encryptor were to use SDCTR mode to encrypt more than 2**L blocks with the same key, then the encryptor would reuse keystream, and the reuse of keystream can lead to serious privacy attacks [SCHNEIER].
推薦(2)は、SSH実装は同じキー(Lが少なくとも128であると仮定する)で2つ以上の**(L/4)ブロック以上を暗号化する前のrekeyがそうするべきであると述べます。 この推薦状は、暗号化メソッドの基本的なブロック暗号に対して誕生日の攻撃の危険を最小にするように設計されています。 例えば、敵が同じキーでおよそ2つの**(L/2)メッセージを暗号化できるなら、理論上のプライバシー攻撃はstateful-復号化カウンタモードに反対しています。 これらの誕生日の攻撃のために、作成者が大きいブロック長がある安全なブロック暗号を使用するよう非常に奨励されます。 さらに、推薦状(2)は、同じキーで2つ以上の**Lブロック以上を暗号化するのから暗号化する人を保護するように設計されています。 ここの動機は次に、暗号化する人がkeystreamを再利用して、keystreamの再利用が暗号化する人が同じキーで2つ以上の**Lブロック以上を暗号化するのにSDCTRモードを使用することであったなら重大なプライバシー攻撃[シュナイアー]につながることができるということです。
6.2. Encryption Method Considerations
6.2. 暗号化メソッド問題
Researchers have shown that the original CBC-based encryption methods in [RFC4253] are vulnerable to chosen-plaintext privacy attacks [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption methods described in Section 4 of this document were designed to be secure replacements to the original encryption methods described in [RFC4253].
研究者は、[RFC4253]のオリジナルのCBCベースの暗号化メソッドが選ばれた平文プライバシー攻撃[DAI、BKN1、BKN2]に被害を受け易いのを示しました。 このドキュメントのセクション4で説明された新しいstateful-復号化カウンタモード暗号化メソッドは、[RFC4253]で説明されたオリジナルの暗号化メソッドとの安全な交換になるように設計されました。
Many people shy away from counter mode-based encryption schemes because, when used incorrectly (such as when the keystream is allowed to repeat), counter mode can be very insecure. Fortunately, the common concerns with counter mode do not apply to SSH because of the rekeying recommendations and because of the additional protection provided by the transport protocol's MAC. This discussion is formalized with proofs of security in [BKN1,BKN2].
不当(keystreamが繰り返すことができる時としてのそのようなもの)に使用されると、カウンタモードが非常に不安定である場合があるので、多くの人々がカウンタのモードベースの暗号化体系を避けます。 幸い、カウンタモードに従った共通の関心事は「再-合わせ」る推薦のためトランスポート・プロトコルのMACによって提供された追加保護のでSSHに適用されません。 この議論は[BKN1、BKN2]でセキュリティの証拠で正式にされます。
As an additional note, when one of the stateful-decryption counter mode encryption methods (Section 4) is used, then the padding included in an SSH packet (Section 4 of [RFC4253]) need not be (but can still be) random. This eliminates the need to generate cryptographically secure pseudorandom bytes for each packet.
追加注意として、次にSSHパケット([RFC4253]のセクション4)に含まれていた詰め物はそうである必要はありません。(その時、stateful-復号化カウンタモード暗号化メソッド(セクション4)の1つは使用されています)。(まだ、あることができます) 無作為です。 これは各パケットのために暗号で安全な擬似ランダムバイトを生成する必要性を排除します。
One property of counter mode encryption is that it does not require that messages be padded to a multiple of the block cipher's block length. Although not padding messages can reduce the protocol's network consumption, this document requires that padding be a multiple of the block cipher's block length in order to (1) not alter
カウンタモード暗号化の1つの特性はメッセージがブロック暗号のブロック長の倍数に水増しされるのが必要でないということです。 メッセージを水増ししないとプロトコルのネットワーク消費を抑えることができますが、このドキュメントが、詰め物がブロック暗号のブロック長の倍数であることを必要とする、(1)は変わりません。
Bellare, et al. Standards Track [Page 8] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[8ページ]。
the packet description in [RFC4253] and (2) not leak precise information about the length of the packet's payload data. (Although there may be some network savings from padding to only 8-bytes even if the block cipher uses 16-byte blocks, because of (1) we do not make that recommendation here.)
[RFC4253]のパケット記述と(2)はパケットのペイロードデータの長さに関する正確な情報を漏らしません。 (ブロック暗号が16バイトのブロックを使用しても8バイトだけにそっと歩くのからのいくつかのネットワーク貯蓄があるかもしれませんが、(1)のために、私たちはここでそれを推薦にしません。)
In addition to stateful-decryption counter mode, [BKN1,BKN2] describe other provably secure encryption methods for use with the SSH Transport Protocol. The stateful-decryption counter mode methods in Section 4 are, however, the preferred alternatives to the insecure methods in [RFC4253] because stateful-decryption counter mode is the most efficient (in terms of both network consumption and the number of required cryptographic operations per packet).
stateful-復号化カウンタモードに加えて[BKN1、BKN2]は安全な状態でもう一方について証明可能に説明します。SSH Transportプロトコルとの使用のための暗号化メソッド。 stateful-復号化カウンタモードが最も効率的であるので(ネットワーク消費と1パケットあたりの必要な暗号の操作の数の両方に関する)、しかしながら、セクション4のstateful-復号化カウンタモードメソッドは[RFC4253]の不安定なメソッドへの都合のよい代替手段です。
Normative References
引用規格
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", Federal Information Processing Standards Publication 197, November 2001.
2001年11月の[AES]米国商務省標準技術局、「エー・イー・エス(AES)」連邦政府の情報処理規格公表197。
[DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", Federal Information Processing Standards Publication 46-3, October 1999.
[DES]米国商務省標準技術局、「データ暗号化規格(DES)」、連邦政府の情報処理規格公表46-3、1999年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]アダムス(C.、「キャスト-128暗号化アルゴリズム」、RFC2144)は1997がそうするかもしれません。
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250] レーティネンとS.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコル規定番号」、RFC4250、1月2006日
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、1月2006日
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: Protocols algorithms and source in code in C", Wiley, 1996.
[シュナイアー]シュナイアー、B.、「適用された暗号第2版:」 「アルゴリズムとソースがCで中でコード化するプロトコル」、ワイリー、1996。
[SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A proposal for the Advanced Encryption Standard", NIST AES Proposal, 1998.
[蛇]のアンダーソンとR.とBiham、E.とクヌーセン、L.、「蛇:」 「エー・イー・エスのための提案」、NIST AES Proposal、1998。
Bellare, et al. Standards Track [Page 9] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[9ページ]。
[TWOFISH] Schneier, B., et al., "The Twofish Encryptions Algorithm: A 128-bit block cipher, 1st Edition", Wiley, 1999.
[TWOFISH]シュナイアー、B.、他、「Twofish暗号化アルゴリズム:」 「最初のEdition、128ビットのブロック、解いてください」、ワイリー、1999
Informative References
有益な参照
[BKN1] Bellare, M., Kohno, T., and Namprempre, C., "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol", Ninth ACM Conference on Computer and Communications Security, 2002.
[BKN1]BellareとM.と河野、T.とNamprempre、C.、「セキュアシェル (SSH)の認証された暗号化:」 「セキュアシェル (SSH)バイナリーパケットプロトコルを証明可能に修理します」、コンピュータと通信秘密保全に関する第9ACMコンファレンス、2002。
[BKN2] Bellare, M., Kohno, T., and Namprempre, C., "Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm", ACM Transactions on Information and System Security, 7(2), May 2004.
[BKN2] BellareとM.と河野、T.とNamprempre、C.、「セキュアシェル (SSH)を壊して、証明可能、修理すると、暗号化体系は認証されました」。 「その時が暗号化するエンコードとMACパラダイムのケーススタディ」(情報に関するACMトランザクションとシステムセキュリティ、7(2))は、2004がそうするかもしれません。
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to the ietf-ssh@netbsd.org email list, 2002.
W.、「SSH2プロトコルに対する攻撃」というDaiが ietf-ssh@netbsd.org にメールする[DAI]はリスト、2002をメールします。
Bellare, et al. Standards Track [Page 10] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[10ページ]。
Authors' Addresses
作者のアドレス
Mihir Bellare Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404
Mihir Bellareコンピュータサイエンス学部と工学カリフォルニア大学サンディエゴ校9500のギルマンは運転します、ラ・ホーヤM.C.0404、カリフォルニア92093-0404
Phone: +1 858-534-8833 EMail: mihir@cs.ucsd.edu
以下に電話をしてください。 +1 858-534-8833 メールしてください: mihir@cs.ucsd.edu
Tadayoshi Kohno Department of Computer Science and Engineering University of California at San Diego 9500 Gilman Drive, MC 0404 La Jolla, CA 92093-0404
忠義河野コンピュータサイエンス学部と工学カリフォルニア大学サンディエゴ校9500のギルマンは運転します、ラ・ホーヤM.C.0404、カリフォルニア92093-0404
Phone: +1 858-534-8833 EMail: tkohno@cs.ucsd.edu
以下に電話をしてください。 +1 858-534-8833 メールしてください: tkohno@cs.ucsd.edu
Chanathip Namprempre Thammasat University Faculty of Engineering Electrical Engineering Department Rangsit Campus, Klong Luang Pathumthani, Thailand 12121
Chanathip Namprempreタマサート大学工学部電気工学部のRangsitキャンパス、Klong Luang Pathumthani、タイ12121
EMail: meaw@alum.mit.edu
メール: meaw@alum.mit.edu
Bellare, et al. Standards Track [Page 11] RFC 4344 SSH Transport Layer Encryption Modes January 2006
Bellare、他 規格はセキュアシェル (SSH)トランスポート層暗号化モード2006年1月にRFC4344を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Bellare, et al. Standards Track [Page 12]
Bellare、他 標準化過程[12ページ]
一覧
スポンサーリンク