RFC3711 日本語訳
3711 The Secure Real-time Transport Protocol (SRTP). M. Baugher, D.McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. (Format: TXT=134270 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Baugher
Request for Comments: 3711 D. McGrew
Category: Standards Track Cisco Systems, Inc.
M. Naslund
E. Carrara
K. Norrman
Ericsson Research
March 2004
Baugherがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3711年のD.マグリューカテゴリ: 2004年の標準化過程シスコシステムズのInc.M.ジーターE.カラーラのK.Norrmanエリクソンの研究行進
The Secure Real-time Transport Protocol (SRTP)
安全なリアルタイムのトランスポート・プロトコル(SRTP)
Status of this Memo
この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 (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).
このドキュメントはSecureレアル-時間Transportプロトコル(SRTP)、RTPレアル-時間Transport Controlプロトコル(RTCP)のためにRTP交通と、そして、コントロール交通に秘密性、通報認証、および反復操作による保護を提供できるレアル-時間Transportプロトコルのプロフィール(RTP)について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Goals and Features . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. SRTP Cryptographic Contexts. . . . . . . . . . . . . . . 7
3.2.1. Transform-independent parameters . . . . . . . . 8
3.2.2. Transform-dependent parameters . . . . . . . . . 10
3.2.3. Mapping SRTP Packets to Cryptographic Contexts . 10
3.3. SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
3.3.1. Packet Index Determination, and ROC, s_l Update. 13
3.3.2. Replay Protection. . . . . . . . . . . . . . . . 15
3.4. Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 記号法のコンベンション. . . . . . . . . . . . . . . . . 3 2。 目標と特徴. . . . . . . . . . . . . . . . . . . . . . 4 2.1。 特徴. . . . . . . . . . . . . . . . . . . . . . . . 5 3。 SRTP枠組み. . . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 RTP. . . . . . . . . . . . . . . . . . . . . . . 6 3.2を固定してください。 SRTPの暗号の文脈。 . . . . . . . . . . . . . . 7 3.2.1. 変換から独立しているパラメタ. . . . . . . . 8 3.2.2。 変換依存するパラメタ. . . . . . . . . 10 3.2.3。 暗号の文脈. 10 3.3にSRTPパケットを写像します。 SRTPパケット処理. . . . . . . . . . . . . . . . . 11 3.3.1。 パケットIndex Determination、およびROC、s_l Update。 13 3.3.2. 保護を再演してください。 . . . . . . . . . . . . . . . 15 3.4. 安全なRTCP. . . . . . . . . . . . . . . . . . . . . . . 15
Baugher, et al. Standards Track [Page 1] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[1ページ]。
4. Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. AES in Counter Mode. . . . . . . . . . . . . . . 21
4.1.2. AES in f8-mode . . . . . . . . . . . . . . . . . 22
4.1.3. NULL Cipher. . . . . . . . . . . . . . . . . . . 25
4.2. Message Authentication and Integrity . . . . . . . . . . 25
4.2.1. HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
4.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
4.3.1. Key Derivation Algorithm . . . . . . . . . . . . 26
4.3.2. SRTCP Key Derivation . . . . . . . . . . . . . . 28
4.3.3. AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
5. Default and mandatory-to-implement Transforms. . . . . . . . . 28
5.1. Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
5.2. Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
5.3. Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
6. Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
7. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Key derivation . . . . . . . . . . . . . . . . . . . . . 30
7.2. Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Message Integrity from Universal Hashing . . . . . . . . 31
7.4. Data Origin Authentication Considerations. . . . . . . . 31
7.5. Short and Zero-length Message Authentication . . . . . . 32
8. Key Management Considerations. . . . . . . . . . . . . . . . . 33
8.1. Re-keying . . . . . . . . . . . . . . . . . . . . . . . 34
8.1.1. Use of the <From, To> for re-keying. . . . . . . 34
8.2. Key Management parameters. . . . . . . . . . . . . . . . 35
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9.1. SSRC collision and two-time pad. . . . . . . . . . . . . 37
9.2. Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
9.3. Confidentiality of the RTP Payload . . . . . . . . . . . 39
9.4. Confidentiality of the RTP Header. . . . . . . . . . . . 40
9.5. Integrity of the RTP payload and header. . . . . . . . . 40
9.5.1. Risks of Weak or Null Message Authentication. . . 42
9.5.2. Implicit Header Authentication . . . . . . . . . 43
10. Interaction with Forward Error Correction mechanisms. . . . . 43
11. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
11.3. Re-keying and access control . . . . . . . . . . . . . . 45
11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
B.1. AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
4. 暗号の変換. . . . . . . . . . . . . 19 4.1を事前に定義しました。 暗号化. . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1。 カウンタモードによるAES。 . . . . . . . . . . . . . . 21 4.1.2. AESコネf8-モード. . . . . . . . . . . . . . . . . 22 4.1.3。 ヌル暗号。 . . . . . . . . . . . . . . . . . . 25 4.2. 通報認証と保全. . . . . . . . . . 25 4.2.1。 HMAC-SHA1。 . . . . . . . . . . . . . . . . . . . 25 4.3. 主要な派生. . . . . . . . . . . . . . . . . . . . . 26 4.3.1。 主要な誘導アルゴリズム. . . . . . . . . . . . 26 4.3.2。 SRTCPの主要な派生. . . . . . . . . . . . . . 28 4.3.3。 AES-CM PRF. . . . . . . . . . . . . . . . . . . 28 5。 デフォルトと実行するために義務的なTransforms28………5.1。 暗号化: AES-CMとヌル。 . . . . . . . . . . . . . . 29 5.2. 通報認証/保全: HMAC-SHA1。 . . . . . . 29 5.3. キー派生: AES-CM PRF. . . . . . . . . . . . . . . 29 6。 SRTP変換. . . . . . . . . . . . . . . . . . . . 29 7を加えます。 原理。 . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. 主要な派生. . . . . . . . . . . . . . . . . . . . . 30 7.2。 キーに塩味を付けさせます。 . . . . . . . . . . . . . . . . . . . . . . 30 7.3. 普遍的な論じ尽く. . . . . . . . 31 7.4すのからのメッセージの保全。 データ起源認証問題。 . . . . . . . 31 7.5. 短くて無長さの通報認証. . . . . . 32 8。 Key Management問題。 . . . . . . . . . . . . . . . . 33 8.1. .1に.348.1を再合わせます。 <From、再の合わせるTo>の使用。 . . . . . . 34 8.2. Key Managementパラメタ。 . . . . . . . . . . . . . . . 35 9. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 37 9.1. SSRC衝突と二度のパッド。 . . . . . . . . . . . . 37 9.2. 主要な用法。 . . . . . . . . . . . . . . . . . . . . . . . 38 9.3. RTP有効搭載量. . . . . . . . . . . 39 9.4の秘密性。 RTPヘッダーの秘密性。 . . . . . . . . . . . 40 9.5. RTPペイロードとヘッダーの保全。 . . . . . . . . 40 9.5.1. 弱いかヌルの通報認証のリスク。 . . 42 9.5.2. 暗黙のヘッダー認証. . . . . . . . . 43 10。 Forward Error Correctionメカニズムとの相互作用… 43 11。 シナリオ. . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1。 ユニキャスト。 . . . . . . . . . . . . . . . . . . . . . . . . 43 11.2. マルチキャスト(1人の送付者).44 11.3。 再の合わせるのとアクセスは.45 11.4を制御します。 基本的なシナリオ. . . . . . . . . . . . . . . 46 12の概要。 IANA問題。 . . . . . . . . . . . . . . . . . . . . . 46 13. 承認. . . . . . . . . . . . . . . . . . . . . . . 47 14。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 47 14.1。 引用規格. . . . . . . . . . . . . . . . . . 47 14.2。 有益な参照. . . . . . . . . . . . . . . . . 48付録A: インデックス決断. . . . . . . . . . 51付録Bのための擬似コード: ベクトル. . . . . . . . . . . . . . . . . . . . . 51B.1をテストしてください。 AES-f8はベクトルをテストします。 . . . . . . . . . . . . . . . . . . 51
Baugher, et al. Standards Track [Page 2] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[2ページ]。
B.2. AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
B.3. Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56
B.2。 AES-CMテストベクトル。 . . . . . . . . . . . . . . . . . . 52 B.3。 主要な派生テストベクトル。 . . . . . . . . . . . . . . 53人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 55の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 56
1. Introduction
1. 序論
This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, RTCP (the Real-time Transport Control Protocol) [RFC3350].
このドキュメントはSecureレアル-時間Transportプロトコル(SRTP)、RTP RTCP(レアル-時間Transport Controlプロトコル)[RFC3350]のためにRTP交通と、そして、コントロール交通に秘密性、通報認証、および反復操作による保護を提供できるレアル-時間Transportプロトコルのプロフィール(RTP)について説明します。
SRTP provides a framework for encryption and message authentication of RTP and RTCP streams (Section 3). SRTP defines a set of default cryptographic transforms (Sections 4 and 5), and it allows new transforms to be introduced in the future (Section 6). With appropriate key management (Sections 7 and 8), SRTP is secure (Sections 9) for unicast and multicast RTP applications (Section 11).
SRTPはRTPとRTCPの流れ(セクション3)の暗号化と通報認証に枠組みを提供します。 SRTPは1セットのデフォルトの暗号の変換(セクション4と5)を定義します、そして、それは新しい変換が将来(セクション6)導入されるのを許容します。 適切なかぎ管理(セクション7と8)で、ユニキャストとマルチキャストRTPアプリケーション(セクション11)に、SRTPは安全です(セクション9)。
SRTP can achieve high throughput and low packet expansion. SRTP proves to be a suitable protection for heterogeneous environments (mix of wired and wireless networks). To get such features, default transforms are described, based on an additive stream cipher for encryption, a keyed-hash based function for message authentication, and an "implicit" index for sequencing/synchronization based on the RTP sequence number for SRTP and an index number for Secure RTCP (SRTCP).
SRTPは高生産性と低いパケット拡大を達成できます。 SRTPは、異機種混在環境(ワイヤードで無線のネットワークのミックス)のための適当な保護であると判明します。 そのような特徴を得るために、デフォルト変換は説明されます、暗号化のための付加的なストリーム暗号、通報認証のための合わせられた細切れ肉料理のベースの機能、およびSRTPのためのRTP一連番号とSecure RTCPのための指数に基づく配列/同期のための「暗黙」のインデックス(SRTCP)に基づいて。
1.1. Notational Conventions
1.1. 記号法のコンベンション
The keywords "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]. The terminology conforms to [RFC2828] with the following exception. For simplicity we use the term "random" throughout the document to denote randomly or pseudo-randomly generated values. Large amounts of random bits may be difficult to obtain, and for the security of SRTP, pseudo-randomness is sufficient [RFC1750].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか? 用語は以下の例外がある[RFC2828]に従います。 または、簡単さに、私たちが手当たりしだいに指示するドキュメント中で「無作為」の用語を使用する、疑似である、無作為である、発生している値。 多量の無作為のビットは得るのが難しいかもしれません、そして、SRTPのセキュリティのために、疑似偶発性は十分です[RFC1750]。
By convention, the adopted representation is the network byte order, i.e., the left most bit (octet) is the most significant one. By XOR we mean bitwise addition modulo 2 of binary strings, and || denotes concatenation. In other words, if C = A || B, then the most significant bits of C are the bits of A, and the least significant bits of C equal the bits of B. Hexadecimal numbers are prefixed by 0x.
採用された表現がコンベンションによる、ネットワークバイトオーダーである、すなわち、最も噛み付かれた左(八重奏)は最もかなりのものです。 そしてXORで、私たちが、2進のストリングの添加法2をbitwiseすると言っている。|| 連結を指示します。 言い換えれば、CはAと等しいです。|| B、次に、Cの最も重要なビットはAのビットであり、Cの最下位ビットはB.のビットと等しいです。Hexadecimal番号は0xによって前に置かれています。
Baugher, et al. Standards Track [Page 3] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[3ページ]。
The word "encryption" includes also use of the NULL algorithm (which in practice does leave the data in the clear).
また、「暗号化」という言葉はNULLアルゴリズム(実際には明確にデータを残す)の使用を含んでいます。
With slight abuse of notation, we use the terms "message authentication" and "authentication tag" as is common practice, even though in some circumstances, e.g., group communication, the service provided is actually only integrity protection and not data origin authentication.
記法のわずかな乱用で、私たちは一般的な習慣のように用語「通報認証」と「認証タグ」を使用します、提供されたサービスがデータ起源認証ではなく、実際にいくつかの事情、例えば、グループコミュニケーションでの保全保護にすぎませんが。
2. Goals and Features
2. 目標と特徴
The security goals for SRTP are to ensure:
SRTPのセキュリティ目標は以下を確実にすることです。
* the confidentiality of the RTP and RTCP payloads, and
* そしてRTPとRTCPペイロードの秘密性。
* the integrity of the entire RTP and RTCP packets, together with
protection against replayed packets.
* 全体のRTPの保全と再演されたパケットに対する保護に伴うRTCPパケット。
These security services are optional and independent from each other, except that SRTCP integrity protection is mandatory (malicious or erroneous alteration of RTCP messages could otherwise disrupt the processing of the RTP stream).
これらのセキュリティー・サービスは、互いから任意であって、独立しています、SRTCP保全保護が義務的であるのを除いて(そうでなければ、RTCPメッセージの悪意があるか誤った変更はRTPの流れの処理を中断するかもしれません)。
Other, functional, goals for the protocol are:
プロトコルの他の、そして、機能的な目標は以下の通りです。
* a framework that permits upgrading with new cryptographic
transforms,
* 新しい暗号の変換でアップグレードすることを許可する枠組み
* low bandwidth cost, i.e., a framework preserving RTP header
compression efficiency,
* すなわち、低い帯域幅費用、RTPヘッダー圧縮効率を保存する枠組み
and, asserted by the pre-defined transforms:
そして、断言されて、事前に定義は変形します:
* a low computational cost,
* 低いコンピュータの費用
* a small footprint (i.e., small code size and data memory for
keying information and replay lists),
* 小さい足跡(情報と再生リストを合わせるためのすなわち、小さいコードサイズとデータメモリ)
* limited packet expansion to support the bandwidth economy goal,
* 帯域幅経済目標を支持するためにパケット拡大を制限しました。
* independence from the underlying transport, network, and physical
layers used by RTP, in particular high tolerance to packet loss
and re-ordering.
* 特定の高い寛容でRTPによって使用された基本的な輸送、ネットワーク、および物理的な層からパケット損失と再注文までの独立。
These properties ensure that SRTP is a suitable protection scheme for RTP/RTCP in both wired and wireless scenarios.
これらの特性は、SRTPがワイヤードなものと同様に無線のシナリオのRTP/RTCPの適当な保護計画であることを確実にします。
Baugher, et al. Standards Track [Page 4] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[4ページ]。
2.1. Features
2.1. 特徴
Besides the above mentioned direct goals, SRTP provides for some additional features. They have been introduced to lighten the burden on key management and to further increase security. They include:
上記のダイレクト目標以外に、SRTPはいくつかの付加的な機能に備えます。 かぎ管理での負担を軽くならせて、さらにセキュリティを上げるためにそれらを導入しました。 それらは:
* A single "master key" can provide keying material for
confidentiality and integrity protection, both for the SRTP stream
and the corresponding SRTCP stream. This is achieved with a key
derivation function (see Section 4.3), providing "session keys"
for the respective security primitive, securely derived from the
master key.
* 単一の「マスターキー」は秘密性のための材料と保全保護を合わせながら、提供されることができます、SRTPの流れと対応するSRTCPの流れのために。 これは主要な派生機能で達成されます(セクション4.3を見てください)、原始的で、マスターキーからしっかりと派生しているそれぞれのセキュリティに「セッションキー」を提供して。
* In addition, the key derivation can be configured to periodically
refresh the session keys, which limits the amount of ciphertext
produced by a fixed key, available for an adversary to
cryptanalyze.
* さらに、定期的にセッションキーをリフレッシュするために主要な派生を構成できて、暗号文の量は固定キーでその限界を起こしました、cryptanalyzeへの敵に、利用可能です。
* "Salting keys" are used to protect against pre-computation and
time-memory tradeoff attacks [MF00] [BS00].
* 「塩味を付けキー」は、プレ計算と時間メモリ見返り攻撃[MF00][BS00]から守るのに使用されます。
Detailed rationale for these features can be found in Section 7.
セクション7でこれらの特徴のための詳細な原理を見つけることができます。
3. SRTP Framework
3. SRTP枠組み
RTP is the Real-time Transport Protocol [RFC3550]. We define SRTP as a profile of RTP. This profile is an extension to the RTP Audio/Video Profile [RFC3551]. Except where explicitly noted, all aspects of that profile apply, with the addition of the SRTP security features. Conceptually, we consider SRTP to be a "bump in the stack" implementation which resides between the RTP application and the transport layer. SRTP intercepts RTP packets and then forwards an equivalent SRTP packet on the sending side, and intercepts SRTP packets and passes an equivalent RTP packet up the stack on the receiving side.
RTPはレアル-時間Transportプロトコル[RFC3550]です。 私たちはRTPのプロフィールとSRTPを定義します。 このプロフィールはRTP Audio/ビデオProfile[RFC3551]への拡大です。 明らかに述べられるところを除いて、そのプロフィールの全面はSRTPセキュリティ機能の添加で適用されます。 概念的に、私たちは、SRTPがRTPアプリケーションとトランスポート層の間にある「スタックでの隆起」実現であると考えます。 SRTPはスタックで受信側で送付側でRTPパケットを妨害して、次に、同等なSRTPパケットを進めて、SRTPパケットを妨害して、同等なRTPパケットを通過します。
Secure RTCP (SRTCP) provides the same security services to RTCP as SRTP does to RTP. SRTCP message authentication is MANDATORY and thereby protects the RTCP fields to keep track of membership, provide feedback to RTP senders, or maintain packet sequence counters. SRTCP is described in Section 3.4.
安全なRTCP(SRTCP)はSRTPがRTPに提供するようにRTCPへの同じセキュリティー・サービスを提供します。 SRTCP通報認証は、MANDATORYであり、その結果、会員資格の動向をおさえるか、RTP送付者にフィードバックを提供するか、またはパケット系列カウンタを維持するためにRTCP分野を保護します。 SRTCPはセクション3.4で説明されます。
Baugher, et al. Standards Track [Page 5] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[5ページ]。
3.1. Secure RTP
3.1. 安全なRTP
The format of an SRTP packet is illustrated in Figure 1.
SRTPパケットの形式は図1で例証されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion* Authenticated Portion ---+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++<+|V=2|P|X| CC|M| 太平洋標準時| 一連番号| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | タイムスタンプ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 同期ソース(SSRC)識別子| | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ソース(CSRC)識別子を寄付します。| | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP拡張子(OPTIONAL)| | + >+++++++++++++++++++++++++++++++++| | | ペイロード… | | | | +-------------------------------+ | | | | RTP詰め物| RTPパッドカウント| | + >+++++++++++++++++++++++++++++++++<+| ~ SRTP MKIの(任意)の~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 認証タグ(RECOMMENDED): | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +暗号化された部分*は部分を認証しました。---+
Figure 1. The format of an SRTP packet. *Encrypted Portion is the same size as the plaintext for the Section 4 pre-defined transforms.
図1。 SRTPパケットの形式。 *セクション4のための平文が変換を事前に定義したので、暗号化されたPortionは同じサイズです。
The "Encrypted Portion" of an SRTP packet consists of the encryption of the RTP payload (including RTP padding when present) of the equivalent RTP packet. The Encrypted Portion MAY be the exact size of the plaintext or MAY be larger. Figure 1 shows the RTP payload including any possible padding for RTP [RFC3550].
SRTPパケットの「暗号化された部分」は同等なRTPパケットのRTPペイロード(存在しているときそっと歩くRTPを含んでいる)の暗号化から成ります。 Encrypted Portionは平文の実寸であるかもしれないか、より大きいかもしれません。 図1はRTP[RFC3550]のためにどんな可能な詰め物も含むRTPペイロードを示しています。
None of the pre-defined encryption transforms uses any padding; for these, the RTP and SRTP payload sizes match exactly. New transforms added to SRTP (following Section 6) may require padding, and may hence produce larger payloads. RTP provides its own padding format (as seen in Fig. 1), which due to the padding indicator in the RTP header has merits in terms of compactness relative to paddings using prefix-free codes. This RTP padding SHALL be the default method for transforms requiring padding. Transforms MAY specify other padding methods, and MUST then specify the amount, format, and processing of their padding. It is important to note that encryption transforms
事前に定義された暗号化変換のいずれも少しの詰め物も使用しません。 これらに関しては、RTPとSRTPペイロードサイズはまさに合っています。 SRTP(次のセクション6)に加えられた新しい変換は、そっと歩くのが必要であり、したがって、より大きいペイロードを生産するかもしれません。 RTPは、それ自身が形式(図1で見られるように)を水増しするのを前提とします。(形式は、RTPヘッダーの詰め物インディケータのためコンパクト性に関して無接頭語のコードを使用することで詰め物に比例して長所を持っています)。 デフォルトがそっと歩くのを必要とする変換のためのメソッドであったならSHALLを水増しするこのRTP。 変換は、他の詰め物メソッドを指定するかもしれなくて、彼らの詰め物に次に、量を指定して、フォーマットして、処理されるのを指定しなければなりません。 暗号化が変形することに注意するのは重要です。
Baugher, et al. Standards Track [Page 6] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[6ページ]。
that use padding are vulnerable to subtle attacks, especially when message authentication is not used [V02]. Each specification for a new encryption transform needs to carefully consider and describe the security implications of the padding that it uses. Message authentication codes define their own padding, so this default does not apply to authentication transforms.
特に通報認証が使用されていないとき[V02]、詰め物が微妙な状態で被害を受け易いその使用は攻撃されます。 新しい暗号化変換のための各仕様は、慎重にそれが使用する詰め物のセキュリティ含意を考えて、説明する必要があります。 メッセージ確認コードがそれら自身の詰め物を定義するので、このデフォルトは認証変換に適用されません。
The OPTIONAL MKI and the RECOMMENDED authentication tag are the only fields defined by SRTP that are not in RTP. Only 8-bit alignment is assumed.
OPTIONAL MKIとRECOMMENDED認証タグはRTPにないSRTPによって定義された唯一の分野です。 8ビットの整列だけが想定されます。
MKI (Master Key Identifier): configurable length, OPTIONAL. The
MKI is defined, signaled, and used by key management. The
MKI identifies the master key from which the session
key(s) were derived that authenticate and/or encrypt the
particular packet. Note that the MKI SHALL NOT identify
the SRTP cryptographic context, which is identified
according to Section 3.2.3. The MKI MAY be used by key
management for the purposes of re-keying, identifying a
particular master key within the cryptographic context
(Section 3.2.1).
MKI(マスターキー識別子): 構成可能な長さ、OPTIONAL。 MKIはかぎ管理によって定義されて、示されて、使用されます。 MKIは特定のパケットを認証する、そして/または、暗号化するセッションキーが引き出されたマスターキーを特定します。 MKI SHALL NOTがSRTPの暗号の文脈を特定することに注意してください。(セクション3.2.3に従って、文脈は特定されます)。 MKI MAY、再の合わせることの目的のためのかぎ管理によって使用されてください、暗号の文脈(セクション3.2.1)の中で特定のマスターキーを特定して。
Authentication tag: configurable length, RECOMMENDED. The
authentication tag is used to carry message authentication
data. The Authenticated Portion of an SRTP packet
consists of the RTP header followed by the Encrypted
Portion of the SRTP packet. Thus, if both encryption and
authentication are applied, encryption SHALL be applied
before authentication on the sender side and conversely on
the receiver side. The authentication tag provides
authentication of the RTP header and payload, and it
indirectly provides replay protection by authenticating
the sequence number. Note that the MKI is not integrity
protected as this does not provide any extra protection.
認証タグ: 構成可能な長さ、RECOMMENDED。 認証タグは、メッセージ認証データを運ぶのに使用されます。 SRTPパケットのAuthenticated PortionはSRTPパケットのEncrypted Portionによって続かれたRTPヘッダーから成ります。 したがって、暗号化と認証の両方が適用されているなら、暗号化SHALLは認証の前に送付者側で適用されて、逆に受信機の上で面があります。 認証タグはRTPヘッダーとペイロードの認証を提供します、そして、それは一連番号を認証することによって、間接的に反復操作による保護を提供します。 MKIがこれが少しの特別な防護措置も提供しないので保護された保全でないことに注意してください。
3.2. SRTP Cryptographic Contexts
3.2. SRTPの暗号の文脈
Each SRTP stream requires the sender and receiver to maintain cryptographic state information. This information is called the "cryptographic context".
それぞれのSRTPストリームは、暗号の州の情報を保守するために送付者と受信機を必要とします。 この情報は「暗号の文脈」と呼ばれます。
SRTP uses two types of keys: session keys and master keys. By a "session key", we mean a key which is used directly in a cryptographic transform (e.g., encryption or message authentication), and by a "master key", we mean a random bit string (given by the key management protocol) from which session keys are derived in a
SRTPは2つのタイプのキーを使用します: セッションキーとマスターキー。 「セッションキー」で、私たちは直接暗号の変換(例えば、暗号化か通報認証)に使用されるキーを言っています、そして、「マスターキー」で、セッションキーがaで引き出される無作為のビット列(かぎ管理プロトコルで、与える)を言っています。
Baugher, et al. Standards Track [Page 7] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[7ページ]。
cryptographically secure way. The master key(s) and other parameters in the cryptographic context are provided by key management mechanisms external to SRTP, see Section 8.
暗号で道を保証してください。 SRTPへの外部のかぎ管理メカニズムで暗号の文脈のマスターキーと他のパラメタを提供します、とセクション8は見ます。
3.2.1. Transform-independent parameters
3.2.1. 変換から独立しているパラメタ
Transform-independent parameters are present in the cryptographic context independently of the particular encryption or authentication transforms that are used. The transform-independent parameters of the cryptographic context for SRTP consist of:
変換から独立しているパラメタは特定の暗号化か使用された認証変換の如何にかかわらず暗号の文脈に存在しています。 SRTPのための暗号の文脈の変換から独立しているパラメタは以下から成ります。
* a 32-bit unsigned rollover counter (ROC), which records how many
times the 16-bit RTP sequence number has been reset to zero after
passing through 65,535. Unlike the sequence number (SEQ), which
SRTP extracts from the RTP packet header, the ROC is maintained by
SRTP as described in Section 3.3.1.
* 32ビットの未署名のロールオーバーカウンタ(ROC)。(そのカウンタは、6万5535を通り抜けた後に16ビットのRTP一連番号が何回ゼロにリセットされたかを記録します)。 一連番号(SEQ)と異なって、ROCはセクション3.3.1で説明されるようにSRTPによって維持されます。SRTPはRTPパケットのヘッダーから一連番号を抽出します。
We define the index of the SRTP packet corresponding to a given
ROC and RTP sequence number to be the 48-bit quantity
私たちは、48ビットの量になるように与えられたROCとRTP一連番号に対応するSRTPパケットのインデックスを定義します。
i = 2^16 * ROC + SEQ.
iは2^16*ROC+SEQと等しいです。
* for the receiver only, a 16-bit sequence number s_l, which can be
thought of as the highest received RTP sequence number (see
Section 3.3.1 for its handling), which SHOULD be authenticated
since message authentication is RECOMMENDED,
* 受信機だけのために、16ビットの一連番号s_lに、通報認証がRECOMMENDEDであるので、どのSHOULDを認証するか。(最も高い容認されたRTP一連番号(取り扱いに関してセクション3.3.1を見る)としてそれを考えることができます)。
* an identifier for the encryption algorithm, i.e., the cipher and
its mode of operation,
* 暗号化アルゴリズム、すなわち、暗号、およびその運転モードのための識別子
* an identifier for the message authentication algorithm,
* 通報認証アルゴリズムのための識別子
* a replay list, maintained by the receiver only (when
authentication and replay protection are provided), containing
indices of recently received and authenticated SRTP packets,
* 最近のインデックスリストを含む受信機だけによって維持された再生リストは、SRTPパケットを受けて、認証しました。
* an MKI indicator (0/1) as to whether an MKI is present in SRTP and
SRTCP packets,
* MKIがSRTPとSRTCPパケットに存在しているかどうかに関するMKIインディケータ(0/1)
* if the MKI indicator is set to one, the length (in octets) of the
MKI field, and (for the sender) the actual value of the currently
active MKI (the value of the MKI indicator and length MUST be kept
fixed for the lifetime of the context),
* MKIインディケータは1つに設定されるか、そして、MKI分野の長さ(八重奏における)、および現在アクティブなMKIの(送付者のための)実価(文脈の生涯に修理されるようにMKIインディケータと長さの値を保たなければなりません)
* the master key(s), which MUST be random and kept secret,
* マスターキー。(そのマスターキーを無作為であり、秘密にしなければなりません)。
Baugher, et al. Standards Track [Page 8] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[8ページ]。
* for each master key, there is a counter of the number of SRTP
packets that have been processed (sent) with that master key
(essential for security, see Sections 3.3.1 and 9),
* 各マスターキーのために、そのマスターキーで処理された(発信します)SRTPパケットの数のカウンタがあります(セキュリティに不可欠です、セクション3.3 .1と9を見てください)。
* non-negative integers n_e, and n_a, determining the length of the
session keys for encryption, and message authentication.
* 暗号化、および通報認証のためのセッションキーの長さを測定する非負の整数n_e、およびn。
In addition, for each master key, an SRTP stream MAY use the following associated values:
さらに、各マスターキーのために、SRTPストリームは以下の関連値を使用するかもしれません:
* a master salt, to be used in the key derivation of session keys.
This value, when used, MUST be random, but MAY be public. Use of
master salt is strongly RECOMMENDED, see Section 9.2. A "NULL"
salt is treated as 00...0.
* aは、セッションキーの主要な派生に使用されるために塩をマスタリングします。 この値は、使用されると無作為でなければなりませんが、公共であるかもしれません。 マスター塩の使用は強くそうです。RECOMMENDED、セクション9.2を見てください。 「ヌル」の塩は00として処理されます…0.
* an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate",
where an unspecified value is treated as zero. The constraint to
be a power of 2 simplifies the session-key derivation
implementation, see Section 4.3.
* 中の整数、1、2、4、…、2^24を設定してください、そして、「主要な_派生_レート」(不特定の値がある)はゼロを扱いました。 セクション4.3は、2のパワーであるという規制がセッション主要な派生実装を簡素化するのを見ます。
* an MKI value,
* MKI値
* <From, To> values, specifying the lifetime for a master key,
expressed in terms of the two 48-bit index values inside whose
range (including the range end-points) the master key is valid.
For the use of <From, To>, see Section 8.1.1. <From, To> is an
alternative to the MKI and assumes that a master key is in one-
to-one correspondence with the SRTP session key on which the
<From, To> range is defined.
* <、To>値、生涯を指定して、範囲(範囲エンドポイントを含んでいる)の中で2つの48ビットのインデックス値で急送されたマスターキーに関してマスターキーは有効です。 <の使用に関しては、From(To>)はセクション8.1.1を見ます。 <、To>は、MKIへの代替手段であり、<FromでありTo>範囲が定義されるSRTPセッションキーとの-1つへの1つの通信にはマスターキーがあると仮定します。
SRTCP SHALL by default share the crypto context with SRTP, except:
以下を除いて、SRTCP SHALLはデフォルトで暗号文脈をSRTPと共有します。
* no rollover counter and s_l-value need to be maintained as the
RTCP index is explicitly carried in each SRTCP packet,
* ロールオーバーカウンタとどんなs_l-価値も、RTCPインデックスがそれぞれのSRTCPパケットで明らかに運ばれるので維持される必要がありません。
* a separate replay list is maintained (when replay protection is
provided),
* 別々の再生リストは維持されます(反復操作による保護を提供するとき)。
* SRTCP maintains a separate counter for its master key (even if the
master key is the same as that for SRTP, see below), as a means to
maintain a count of the number of SRTCP packets that have been
processed with that key.
* SRTCPはマスターキーのために別々のカウンタを維持します(マスターキーがSRTPのためのそれと同じであっても、以下を見てください)、そのキーで処理されたSRTCPパケットの数のカウントを維持する手段として。
Note in particular that the master key(s) MAY be shared between SRTP and the corresponding SRTCP, if the pre-defined transforms (including the key derivation) are used but the session key(s) MUST NOT be so shared.
事前に定義された変換(主要な派生を含んでいる)が使用されていますが、そのようにセッションキーを共有してはいけないなら、マスターキーがSRTPと対応するSRTCPの間で共有されるかもしれないことに特に注意してください。
Baugher, et al. Standards Track [Page 9] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[9ページ]。
In addition, there can be cases (see Sections 8 and 9.1) where several SRTP streams within a given RTP session, identified by their synchronization source (SSRCs, which is part of the RTP header), share most of the crypto context parameters (including possibly master and session keys). In such cases, just as in the normal SRTP/SRTCP parameter sharing above, separate replay lists and packet counters for each stream (SSRC) MUST still be maintained. Also, separate SRTP indices MUST then be maintained.
さらに、ケース(セクション8と9.1を見る)が彼らの同期ソース(RTPヘッダーの一部であるSSRCs)によって特定された与えられたRTPセッション以内のいくつかのSRTPストリームが暗号文脈パラメタの大部分を共有する(ことによるとマスターとセッションキーを含んでいて)ところにあることができます。 まだ各ストリーム(SSRC)のためのそのような場合ちょうど上で共有される正常なSRTP/SRTCPパラメタのような別々の再生リストとパケットカウンタを維持しなければなりません。 また、そして、別々のSRTPインデックスリストを維持しなければなりません。
A summary of parameters, pre-defined transforms, and default values for the above parameters (and other SRTP parameters) can be found in Sections 5 and 8.2.
セクション5と8.2で上記のパラメタ(そして、他のSRTPパラメタ)のためのパラメタ、事前に定義された変換、およびデフォルト値の概要を見つけることができます。
3.2.2. Transform-dependent parameters
3.2.2. 変換依存するパラメタ
All encryption, authentication/integrity, and key derivation parameters are defined in the transforms section (Section 4). Typical examples of such parameters are block size of ciphers, session keys, data for the Initialization Vector (IV) formation, etc. Future SRTP transform specifications MUST include a section to list the additional cryptographic context's parameters for that transform, if any.
変換部(セクション4)ですべての暗号化、認証/保全、および主要な派生パラメタは定義されます。 そのようなパラメタの典型的な例は暗号、セッションキー、初期設定Vector(IV)構成のためのデータなどのブロック・サイズです。 将来のSRTP変換仕様は、もしあればその変換のための追加暗号の文脈のパラメタをリストアップするためにセクションを含まなければなりません。
3.2.3. Mapping SRTP Packets to Cryptographic Contexts
3.2.3. SRTPパケットを暗号の文脈に写像します。
Recall that an RTP session for each participant is defined [RFC3550] by a pair of destination transport addresses (one network address plus a port pair for RTP and RTCP), and that a multimedia session is defined as a collection of RTP sessions. For example, a particular multimedia session could include an audio RTP session, a video RTP session, and a text RTP session.
1組の送付先輸送アドレス(RTPとRTCPのための1つのネットワーク・アドレスとポート組)によって各関係者のためのRTPセッションが定義されて[RFC3550]、マルチメディアセッションがRTPセッションの収集と定義されたと思い出してください。 例えば、特定のマルチメディアセッションはオーディオRTPセッション、ビデオRTPセッション、およびテキストRTPセッションを含むかもしれません。
A cryptographic context SHALL be uniquely identified by the triplet context identifier:
三つ子の文脈識別子によって特定されて、暗号の文脈SHALLは唯一以下の通りです。
context id = <SSRC, destination network address, destination transport port number>
文脈イド=<SSRC、送信先ネットワークアドレス、目的地輸送ポートナンバー>。
where the destination network address and the destination transport port are the ones in the SRTP packet. It is assumed that, when presented with this information, the key management returns a context with the information as described in Section 3.2.
送信先ネットワークアドレスと目的地輸送港がSRTPパケットのものであるところ。 この情報を与えるとき、かぎ管理がセクション3.2で説明されるように情報がある文脈を返すと思われます。
As noted above, SRTP and SRTCP by default share the bulk of the parameters in the cryptographic context. Thus, retrieving the crypto context parameters for an SRTCP stream in practice may imply a binding to the correspondent SRTP crypto context. It is up to the implementation to assure such binding, since the RTCP port may not be
上で述べたように、SRTPとSRTCPはデフォルトで暗号の文脈のパラメタの大半を共有します。 したがって、実際にはSRTCPストリームのための暗号文脈パラメタを検索すると、結合は通信員SRTP暗号文脈に含意されるかもしれません。 RTCPポートが保証しないのでそのような結合を保証するのは実装まで達しています。
Baugher, et al. Standards Track [Page 10] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[10ページ]。
directly deducible from the RTP port only. Alternatively, the key management may choose to provide separate SRTP- and SRTCP- contexts, duplicating the common parameters (such as master key(s)). The latter approach then also enables SRTP and SRTCP to use, e.g., distinct transforms, if so desired. Similar considerations arise when multiple SRTP streams, forming part of one single RTP session, share keys and other parameters.
RTPポートだけから直接推定可能です。 あるいはまた、かぎ管理は、別々のSRTPとSRTCP文脈を提供するのを選ぶかもしれません、一般的なパラメタをコピーして。(マスターキー(s))などのように。 そして、また、そう望まれているなら、後者のアプローチは使用、例えば、異なった変換へのSRTPとSRTCPを有効にします。 1つのただ一つのRTPセッションの一部を形成して、複数のSRTPストリームがキーと他のパラメタを共有するとき、同様の問題は起こります。
If no valid context can be found for a packet corresponding to a certain context identifier, that packet MUST be discarded.
ある文脈識別子に対応するパケットのためにどんな有効な文脈も見つけることができないなら、そのパケットを捨てなければなりません。
3.3. SRTP Packet Processing
3.3. SRTPパケット処理
The following applies to SRTP. SRTCP is described in Section 3.4.
以下はSRTPに適用されます。 SRTCPはセクション3.4で説明されます。
Assuming initialization of the cryptographic context(s) has taken place via key management, the sender SHALL do the following to construct an SRTP packet:
暗号の文脈の初期化がかぎ管理を通して行われたと仮定して、送付者SHALLはSRTPパケットを組み立てるために以下をします:
1. Determine which cryptographic context to use as described in
Section 3.2.3.
1. セクション3.2.3で説明されるようにどの暗号の文脈を使用したらよいか決定してください。
2. Determine the index of the SRTP packet using the rollover counter,
the highest sequence number in the cryptographic context, and the
sequence number in the RTP packet, as described in Section 3.3.1.
2. ロールオーバーカウンタ、暗号の文脈で最も高い一連番号、およびRTPパケットの一連番号を使用して、SRTPパケットのインデックスを決定してください、セクション3.3.1で説明されるように。
3. Determine the master key and master salt. This is done using the
index determined in the previous step or the current MKI in the
cryptographic context, according to Section 8.1.
3. マスターキーとマスター塩を決定してください。 これは暗号の文脈で前のステップか現在のMKIで決定しているインデックスを使用し終わっています、セクション8.1によると。
4. Determine the session keys and session salt (if they are used by
the transform) as described in Section 4.3, using master key,
master salt, key_derivation_rate, and session key-lengths in the
cryptographic context with the index, determined in Steps 2 and 3.
4. セクション4.3で説明されるようにセッションキーとセッション塩(それらが変換で使用されるなら)を決定してください、暗号の文脈でインデックスでマスターキー、マスター塩、主要な_派生_レート、およびセッションキー長を使用して、Steps2と3では、断固としています。
5. Encrypt the RTP payload to produce the Encrypted Portion of the
packet (see Section 4.1, for the defined ciphers). This step uses
the encryption algorithm indicated in the cryptographic context,
the session encryption key and the session salt (if used) found in
Step 4 together with the index found in Step 2.
5. RTPペイロードを暗号化して(定義された暗号に関してセクション4.1を見てください)、パケットのEncrypted Portionを生産してください。 このステップは暗号の文脈で示された暗号化アルゴリズムを使用します、とセッション暗号化キーとセッション塩(使用されるなら)はStep2で見つけられたインデックスに伴うStep4でわかりました。
6. If the MKI indicator is set to one, append the MKI to the packet.
6. If the MKI indicator is set to one, append the MKI to the packet.
7. For message authentication, compute the authentication tag for the
Authenticated Portion of the packet, as described in Section 4.2.
This step uses the current rollover counter, the authentication
7. For message authentication, compute the authentication tag for the Authenticated Portion of the packet, as described in Section 4.2. This step uses the current rollover counter, the authentication
Baugher, et al. Standards Track [Page 11] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 11] RFC 3711 SRTP March 2004
algorithm indicated in the cryptographic context, and the session
authentication key found in Step 4. Append the authentication tag
to the packet.
algorithm indicated in the cryptographic context, and the session authentication key found in Step 4. Append the authentication tag to the packet.
8. If necessary, update the ROC as in Section 3.3.1, using the packet
index determined in Step 2.
8. If necessary, update the ROC as in Section 3.3.1, using the packet index determined in Step 2.
To authenticate and decrypt an SRTP packet, the receiver SHALL do the following:
To authenticate and decrypt an SRTP packet, the receiver SHALL do the following:
1. Determine which cryptographic context to use as described in
Section 3.2.3.
1. Determine which cryptographic context to use as described in Section 3.2.3.
2. Run the algorithm in Section 3.3.1 to get the index of the SRTP
packet. The algorithm uses the rollover counter and highest
sequence number in the cryptographic context with the sequence
number in the SRTP packet, as described in Section 3.3.1.
2. Run the algorithm in Section 3.3.1 to get the index of the SRTP packet. The algorithm uses the rollover counter and highest sequence number in the cryptographic context with the sequence number in the SRTP packet, as described in Section 3.3.1.
3. Determine the master key and master salt. If the MKI indicator in
the context is set to one, use the MKI in the SRTP packet,
otherwise use the index from the previous step, according to
Section 8.1.
3. Determine the master key and master salt. If the MKI indicator in the context is set to one, use the MKI in the SRTP packet, otherwise use the index from the previous step, according to Section 8.1.
4. Determine the session keys, and session salt (if used by the
transform) as described in Section 4.3, using master key, master
salt, key_derivation_rate and session key-lengths in the
cryptographic context with the index, determined in Steps 2 and 3.
4. Determine the session keys, and session salt (if used by the transform) as described in Section 4.3, using master key, master salt, key_derivation_rate and session key-lengths in the cryptographic context with the index, determined in Steps 2 and 3.
5. For message authentication and replay protection, first check if
the packet has been replayed (Section 3.3.2), using the Replay
List and the index as determined in Step 2. If the packet is
judged to be replayed, then the packet MUST be discarded, and the
event SHOULD be logged.
5. For message authentication and replay protection, first check if the packet has been replayed (Section 3.3.2), using the Replay List and the index as determined in Step 2. If the packet is judged to be replayed, then the packet MUST be discarded, and the event SHOULD be logged.
Next, perform verification of the authentication tag, using the
rollover counter from Step 2, the authentication algorithm
indicated in the cryptographic context, and the session
authentication key from Step 4. If the result is "AUTHENTICATION
FAILURE" (see Section 4.2), the packet MUST be discarded from
further processing and the event SHOULD be logged.
Next, perform verification of the authentication tag, using the rollover counter from Step 2, the authentication algorithm indicated in the cryptographic context, and the session authentication key from Step 4. If the result is "AUTHENTICATION FAILURE" (see Section 4.2), the packet MUST be discarded from further processing and the event SHOULD be logged.
6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for
the defined ciphers), using the decryption algorithm indicated in
the cryptographic context, the session encryption key and salt (if
used) found in Step 4 with the index from Step 2.
6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for the defined ciphers), using the decryption algorithm indicated in the cryptographic context, the session encryption key and salt (if used) found in Step 4 with the index from Step 2.
Baugher, et al. Standards Track [Page 12] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 12] RFC 3711 SRTP March 2004
7. Update the rollover counter and highest sequence number, s_l, in
the cryptographic context as in Section 3.3.1, using the packet
index estimated in Step 2. If replay protection is provided, also
update the Replay List as described in Section 3.3.2.
7. Update the rollover counter and highest sequence number, s_l, in the cryptographic context as in Section 3.3.1, using the packet index estimated in Step 2. If replay protection is provided, also update the Replay List as described in Section 3.3.2.
8. When present, remove the MKI and authentication tag fields from
the packet.
8. When present, remove the MKI and authentication tag fields from the packet.
3.3.1. Packet Index Determination, and ROC, s_l Update
3.3.1. Packet Index Determination, and ROC, s_l Update
SRTP implementations use an "implicit" packet index for sequencing, i.e., not all of the index is explicitly carried in the SRTP packet. For the pre-defined transforms, the index i is used in replay protection (Section 3.3.2), encryption (Section 4.1), message authentication (Section 4.2), and for the key derivation (Section 4.3).
SRTP implementations use an "implicit" packet index for sequencing, i.e., not all of the index is explicitly carried in the SRTP packet. For the pre-defined transforms, the index i is used in replay protection (Section 3.3.2), encryption (Section 4.1), message authentication (Section 4.2), and for the key derivation (Section 4.3).
When the session starts, the sender side MUST set the rollover counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 (see security aspects below). The sender's packet index is then defined as
When the session starts, the sender side MUST set the rollover counter, ROC, to zero. Each time the RTP sequence number, SEQ, wraps modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32 (see security aspects below). The sender's packet index is then defined as
i = 2^16 * ROC + SEQ.
i = 2^16 * ROC + SEQ.
Receiver-side implementations use the RTP sequence number to determine the correct index of a packet, which is the location of the packet in the sequence of all SRTP packets. A robust approach for the proper use of a rollover counter requires its handling and use to be well defined. In particular, out-of-order RTP packets with sequence numbers close to 2^16 or zero must be properly handled.
Receiver-side implementations use the RTP sequence number to determine the correct index of a packet, which is the location of the packet in the sequence of all SRTP packets. A robust approach for the proper use of a rollover counter requires its handling and use to be well defined. In particular, out-of-order RTP packets with sequence numbers close to 2^16 or zero must be properly handled.
The index estimate is based on the receiver's locally maintained ROC and s_l values. At the setup of the session, the ROC MUST be set to zero. Receivers joining an on-going session MUST be given the current ROC value using out-of-band signaling such as key-management signaling. Furthermore, the receiver SHALL initialize s_l to the RTP sequence number (SEQ) of the first observed SRTP packet (unless the initial value is provided by out of band signaling such as key management).
The index estimate is based on the receiver's locally maintained ROC and s_l values. At the setup of the session, the ROC MUST be set to zero. Receivers joining an on-going session MUST be given the current ROC value using out-of-band signaling such as key-management signaling. Furthermore, the receiver SHALL initialize s_l to the RTP sequence number (SEQ) of the first observed SRTP packet (unless the initial value is provided by out of band signaling such as key management).
On consecutive SRTP packets, the receiver SHOULD estimate the index
as
i = 2^16 * v + SEQ,
On consecutive SRTP packets, the receiver SHOULD estimate the index as i = 2^16 * v + SEQ,
where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32)
such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC
+ s_l (see Appendix A for pseudocode).
where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32) such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC + s_l (see Appendix A for pseudocode).
Baugher, et al. Standards Track [Page 13] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 13] RFC 3711 SRTP March 2004
After the packet has been processed and authenticated (when enabled for SRTP packets for the session), the receiver MUST use v to conditionally update its s_l and ROC variables as follows. If v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, then s_l is set to SEQ if and only if SEQ is larger than the current s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is set to SEQ and ROC is set to v.
After the packet has been processed and authenticated (when enabled for SRTP packets for the session), the receiver MUST use v to conditionally update its s_l and ROC variables as follows. If v=(ROC-1) mod 2^32, then there is no update to s_l or ROC. If v=ROC, then s_l is set to SEQ if and only if SEQ is larger than the current s_l; there is no change to ROC. If v=(ROC+1) mod 2^32, then s_l is set to SEQ and ROC is set to v.
After a re-keying occurs (changing to a new master key), the rollover counter always maintains its sequence of values, i.e., it MUST NOT be reset to zero.
After a re-keying occurs (changing to a new master key), the rollover counter always maintains its sequence of values, i.e., it MUST NOT be reset to zero.
As the rollover counter is 32 bits long and the sequence number is 16 bits long, the maximum number of packets belonging to a given SRTP stream that can be secured with the same key is 2^48 using the pre- defined transforms. After that number of SRTP packets have been sent with a given (master or session) key, the sender MUST NOT send any more packets with that key. (There exists a similar limit for SRTCP, which in practice may be more restrictive, see Section 9.2.) This limitation enforces a security benefit by providing an upper bound on the amount of traffic that can pass before cryptographic keys are changed. Re-keying (see Section 8.1) MUST be triggered, before this amount of traffic, and MAY be triggered earlier, e.g., for increased security and access control to media. Recurring key derivation by means of a non-zero key_derivation_rate (see Section 4.3), also gives stronger security but does not change the above absolute maximum value.
As the rollover counter is 32 bits long and the sequence number is 16 bits long, the maximum number of packets belonging to a given SRTP stream that can be secured with the same key is 2^48 using the pre- defined transforms. After that number of SRTP packets have been sent with a given (master or session) key, the sender MUST NOT send any more packets with that key. (There exists a similar limit for SRTCP, which in practice may be more restrictive, see Section 9.2.) This limitation enforces a security benefit by providing an upper bound on the amount of traffic that can pass before cryptographic keys are changed. Re-keying (see Section 8.1) MUST be triggered, before this amount of traffic, and MAY be triggered earlier, e.g., for increased security and access control to media. Recurring key derivation by means of a non-zero key_derivation_rate (see Section 4.3), also gives stronger security but does not change the above absolute maximum value.
On the receiver side, there is a caveat to updating s_l and ROC: if message authentication is not present, neither the initialization of s_l, nor the ROC update can be made completely robust. The receiver's "implicit index" approach works for the pre-defined transforms as long as the reorder and loss of the packets are not too great and bit-errors do not occur in unfortunate ways. In particular, 2^15 packets would need to be lost, or a packet would need to be 2^15 packets out of sequence before synchronization is lost. Such drastic loss or reorder is likely to disrupt the RTP application itself.
On the receiver side, there is a caveat to updating s_l and ROC: if message authentication is not present, neither the initialization of s_l, nor the ROC update can be made completely robust. The receiver's "implicit index" approach works for the pre-defined transforms as long as the reorder and loss of the packets are not too great and bit-errors do not occur in unfortunate ways. In particular, 2^15 packets would need to be lost, or a packet would need to be 2^15 packets out of sequence before synchronization is lost. Such drastic loss or reorder is likely to disrupt the RTP application itself.
The algorithm for the index estimate and ROC update is a matter of implementation, and should take into consideration the environment (e.g., packet loss rate) and the cases when synchronization is likely to be lost, e.g., when the initial sequence number (randomly chosen by RTP) is not known in advance (not sent in the key management protocol) but may be near to wrap modulo 2^16.
The algorithm for the index estimate and ROC update is a matter of implementation, and should take into consideration the environment (e.g., packet loss rate) and the cases when synchronization is likely to be lost, e.g., when the initial sequence number (randomly chosen by RTP) is not known in advance (not sent in the key management protocol) but may be near to wrap modulo 2^16.
Baugher, et al. Standards Track [Page 14] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 14] RFC 3711 SRTP March 2004
A more elaborate and more robust scheme than the one given above is the handling of RTP's own "rollover counter", see Appendix A.1 of [RFC3550].
A more elaborate and more robust scheme than the one given above is the handling of RTP's own "rollover counter", see Appendix A.1 of [RFC3550].
3.3.2. Replay Protection
3.3.2. Replay Protection
Secure replay protection is only possible when integrity protection is present. It is RECOMMENDED to use replay protection, both for RTP and RTCP, as integrity protection alone cannot assure security against replay attacks.
Secure replay protection is only possible when integrity protection is present. It is RECOMMENDED to use replay protection, both for RTP and RTCP, as integrity protection alone cannot assure security against replay attacks.
A packet is "replayed" when it is stored by an adversary, and then re-injected into the network. When message authentication is provided, SRTP protects against such attacks through a Replay List. Each SRTP receiver maintains a Replay List, which conceptually contains the indices of all of the packets which have been received and authenticated. In practice, the list can use a "sliding window" approach, so that a fixed amount of storage suffices for replay protection. Packet indices which lag behind the packet index in the context by more than SRTP-WINDOW-SIZE can be assumed to have been received, where SRTP-WINDOW-SIZE is a receiver-side, implementation- dependent parameter and MUST be at least 64, but which MAY be set to a higher value.
A packet is "replayed" when it is stored by an adversary, and then re-injected into the network. When message authentication is provided, SRTP protects against such attacks through a Replay List. Each SRTP receiver maintains a Replay List, which conceptually contains the indices of all of the packets which have been received and authenticated. In practice, the list can use a "sliding window" approach, so that a fixed amount of storage suffices for replay protection. Packet indices which lag behind the packet index in the context by more than SRTP-WINDOW-SIZE can be assumed to have been received, where SRTP-WINDOW-SIZE is a receiver-side, implementation- dependent parameter and MUST be at least 64, but which MAY be set to a higher value.
The receiver checks the index of an incoming packet against the replay list and the window. Only packets with index ahead of the window, or, inside the window but not already received, SHALL be accepted.
The receiver checks the index of an incoming packet against the replay list and the window. Only packets with index ahead of the window, or, inside the window but not already received, SHALL be accepted.
After the packet has been authenticated (if necessary the window is first moved ahead), the replay list SHALL be updated with the new index.
After the packet has been authenticated (if necessary the window is first moved ahead), the replay list SHALL be updated with the new index.
The Replay List can be efficiently implemented by using a bitmap to represent which packets have been received, as described in the Security Architecture for IP [RFC2401].
The Replay List can be efficiently implemented by using a bitmap to represent which packets have been received, as described in the Security Architecture for IP [RFC2401].
3.4. Secure RTCP
3.4. Secure RTCP
Secure RTCP follows the definition of Secure RTP. SRTCP adds three mandatory new fields (the SRTCP index, an "encrypt-flag", and the authentication tag) and one optional field (the MKI) to the RTCP packet definition. The three mandatory fields MUST be appended to an RTCP packet in order to form an equivalent SRTCP packet. The added fields follow any other profile-specific extensions.
Secure RTCP follows the definition of Secure RTP. SRTCP adds three mandatory new fields (the SRTCP index, an "encrypt-flag", and the authentication tag) and one optional field (the MKI) to the RTCP packet definition. The three mandatory fields MUST be appended to an RTCP packet in order to form an equivalent SRTCP packet. The added fields follow any other profile-specific extensions.
Baugher, et al. Standards Track [Page 15] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 15] RFC 3711 SRTP March 2004
According to Section 6.1 of [RFC3550], there is a REQUIRED packet format for compound packets. SRTCP MUST be given packets according to that requirement in the sense that the first part MUST be a sender report or a receiver report. However, the RTCP encryption prefix (a random 32-bit quantity) specified in that Section MUST NOT be used since, as is stated there, it is only applicable to the encryption method specified in [RFC3550] and is not needed by the cryptographic mechanisms used in SRTP.
According to Section 6.1 of [RFC3550], there is a REQUIRED packet format for compound packets. SRTCP MUST be given packets according to that requirement in the sense that the first part MUST be a sender report or a receiver report. However, the RTCP encryption prefix (a random 32-bit quantity) specified in that Section MUST NOT be used since, as is stated there, it is only applicable to the encryption method specified in [RFC3550] and is not needed by the cryptographic mechanisms used in SRTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P| RC | PT=SR or RR | length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SSRC of sender | |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ sender info ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 1 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ report block 2 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ ... ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |V=2|P| SC | PT=SDES=202 | length | |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| | SSRC/CSRC_1 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ SDES items ~ |
| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| ~ ... ~ |
+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| |E| SRTCP index | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTCP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-- Encrypted Portion Authenticated Portion -----+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P| RC | PT=SR or RR | length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SSRC of sender | | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ sender info ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ report block 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ report block 2 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |V=2|P| SC | PT=SDES=202 | length | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | SSRC/CSRC_1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ SDES items ~ | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ ... ~ | +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | |E| SRTCP index | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTCP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-- Encrypted Portion Authenticated Portion -----+
Figure 2. An example of the format of a Secure RTCP packet, consisting of an underlying RTCP compound packet with a Sender Report and SDES packet.
Figure 2. An example of the format of a Secure RTCP packet, consisting of an underlying RTCP compound packet with a Sender Report and SDES packet.
Baugher, et al. Standards Track [Page 16] RFC 3711 SRTP March 2004
Baugher, et al. Standards Track [Page 16] RFC 3711 SRTP March 2004
The Encrypted Portion of an SRTCP packet consists of the encryption (Section 4.1) of the RTCP payload of the equivalent compound RTCP packet, from the first RTCP packet, i.e., from the ninth (9) octet to the end of the compound packet. The Authenticated Portion of an SRTCP packet consists of the entire equivalent (eventually compound) RTCP packet, the E flag, and the SRTCP index (after any encryption has been applied to the payload).
The Encrypted Portion of an SRTCP packet consists of the encryption (Section 4.1) of the RTCP payload of the equivalent compound RTCP packet, from the first RTCP packet, i.e., from the ninth (9) octet to the end of the compound packet. The Authenticated Portion of an SRTCP packet consists of the entire equivalent (eventually compound) RTCP packet, the E flag, and the SRTCP index (after any encryption has been applied to the payload).
The added fields are:
The added fields are:
E-flag: 1 bit, REQUIRED
The E-flag indicates if the current SRTCP packet is
encrypted or unencrypted. Section 9.1 of [RFC3550] allows
the split of a compound RTCP packet into two lower-layer
packets, one to be encrypted and one to be sent in the
clear. The E bit set to "1" indicates encrypted packet, and
"0" indicates non-encrypted packet.
E-flag: 1 bit, REQUIRED The E-flag indicates if the current SRTCP packet is encrypted or unencrypted. Section 9.1 of [RFC3550] allows the split of a compound RTCP packet into two lower-layer packets, one to be encrypted and one to be sent in the clear. The E bit set to "1" indicates encrypted packet, and "0" indicates non-encrypted packet.
SRTCP index: 31 bits, REQUIRED
The SRTCP index is a 31-bit counter for the SRTCP packet.
The index is explicitly included in each packet, in contrast
to the "implicit" index approach used for SRTP. The SRTCP
index MUST be set to zero before the first SRTCP packet is
sent, and MUST be incremented by one, modulo 2^31, after
each SRTCP packet is sent. In particular, after a re-key,
the SRTCP index MUST NOT be reset to zero again.
SRTCPは索引をつけます: SRTCPが索引をつけるREQUIREDは31ビット、SRTCPパケットのための31ビットのカウンタです。 インデックスはSRTPに使用される「暗黙」のインデックスアプローチと対照して各パケットに明らかに含まれています。 SRTCPインデックスを最初のSRTCPパケットを送る前にゼロに設定しなければならなくて、1つ増加しなければなりません、法2^31、それぞれのSRTCPパケットを送った後に。 再キーの後に、特に、再びSRTCPインデックスをゼロにリセットしてはいけません。
Authentication Tag: configurable length, REQUIRED
The authentication tag is used to carry message
authentication data.
認証タグ: 構成可能な長さ、REQUIRED、認証タグは、メッセージ認証データを運ぶのに使用されます。
MKI: configurable length, OPTIONAL
The MKI is the Master Key Indicator, and functions according
to the MKI definition in Section 3.
MKI: 構成可能な長さ、OPTIONAL MKIはMaster Key Indicatorであり、セクション3とのMKI定義に従って、機能します。
SRTCP uses the cryptographic context parameters and packet processing of SRTP by default, with the following changes:
SRTCPはデフォルトで以下の変化と共にSRTPの暗号の文脈パラメタとパケット処理を使用します:
* The receiver does not need to "estimate" the index, as it is
explicitly signaled in the packet.
* それがパケットで明らかに合図されるとき、受信機はインデックスを「見積もる必要はありません」。
* Pre-defined SRTCP encryption is as specified in Section 4.1, but
using the definition of the SRTCP Encrypted Portion given in this
section, and using the SRTCP index as the index i. The encryption
transform and related parameters SHALL by default be the same
selected for the protection of the associated SRTP stream(s),
while the NULL algorithm SHALL be applied to the RTCP packets not
to be encrypted. SRTCP may have a different encryption transform
* 事前に定義されたSRTCP暗号化はセクション4.1で指定されますが、このセクションで与えられているSRTCP Encrypted Portionの定義を使用するとしてそうであり、インデックスとしてSRTCPインデックスを使用するのは、iです。 暗号化は、関連SRTPの保護のために選択された同じくらいが流れであったならデフォルトでパラメタSHALLを変えて、関係づけて、コード化されないようにNULLアルゴリズムSHALLである間、RTCPパケットに適用されてください。 SRTCPは異なった暗号化を変形させるかもしれません。
Baugher, et al. Standards Track [Page 17] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[17ページ]。
than the one used by the corresponding SRTP. The expected use for
this feature is when the former has NULL-encryption and the latter
has a non NULL-encryption.
対応するSRTPによって使用されたものより。 この特徴の予想された使用は前者にはNULL-暗号化がある時です、そして、後者には、非NULLの暗号化があります。
The E-flag is assigned a value by the sender depending on whether the packet was encrypted or not.
値はパケットがコード化されたかどうかを当てにする送付者によってE-旗に割り当てられます。
* SRTCP decryption is performed as in Section 4, but only if the E
flag is equal to 1. If so, the Encrypted Portion is decrypted,
using the SRTCP index as the index i. In case the E-flag is 0,
the payload is simply left unmodified.
* E旗が1と等しい場合にだけ、SRTCP復号化はセクション4のように実行されます。 そうだとすれば、インデックスiとしてSRTCPインデックスを使用して、Encrypted Portionは解読されます。 E-旗が0であるといけないので、ペイロードは単に変更されていないままにされます。
* SRTCP replay protection is as defined in Section 3.3.2, but using
the SRTCP index as the index i and a separate Replay List that is
specific to SRTCP.
* SRTCP反復操作による保護がセクション3.3.2で定義されるようにありますが、SRTCPを使用して、インデックスとしてiとSRTCPに特定の別々のReplay Listに索引をつけてください。
* The pre-defined SRTCP authentication tag is specified as in
Section 4.2, but with the Authenticated Portion of the SRTCP
packet given in this section (which includes the index). The
authentication transform and related parameters (e.g., key size)
SHALL by default be the same as selected for the protection of the
associated SRTP stream(s).
* 事前に定義されたSRTCP認証タグはこのセクション(インデックスを含んでいる)でセクション4.2にもかかわらず、SRTCPパケットのAuthenticated Portionを与えていて指定されます。 認証は、関連SRTPの保護のために選択される同じくらいが流れであったならデフォルトでパラメタ(例えば、主要なサイズ)SHALLを変えて、関係づけました。
* In the last step of the processing, only the sender needs to
update the value of the SRTCP index by incrementing it modulo 2^31
and for security reasons the sender MUST also check the number of
SRTCP packets processed, see Section 9.2.
* また、法2^31と安全保障上の理由で送付者はパケットが処理したSRTCPの数をチェックしなければなりません、と処理の最後のステップ、それを増加することによってSRTCPインデックスの値をアップデートする送付者の必要性だけでは、セクション9.2は見ます。
Message authentication for RTCP is REQUIRED, as it is the control protocol (e.g., it has a BYE packet) for RTP.
それが制御プロトコル(例えば、それはBYEパケットを持っている)であるので、RTCPのための通報認証はRTPのためのREQUIREDです。
Precautions must be taken so that the packet expansion in SRTCP (due to the added fields) does not cause SRTCP messages to use more than their share of RTCP bandwidth. To avoid this, the following two measures MUST be taken:
注意しなければならないので、SRTCP(加えられた分野による)のパケット拡大はそれらのRTCP帯域幅のシェアほど使用するメッセージをSRTCPに引き起こしません。 これを避けるために、以下の2つの対策が実施されなければなりません:
1. When initializing the RTCP variable "avg_rtcp_size" defined in
chapter 6.3 of [RFC3550], it MUST include the size of the fields
that will be added by SRTCP (index, E-bit, authentication tag, and
when present, the MKI).
1. [RFC3550]の第6.3章で定義されたRTCPの可変「avg_rtcp_サイズ」を初期化するとき、それはSRTCP(インデックス、E-ビット、認証タグ、および現在のいつ、MKI)によって加えられる分野のサイズを含まなければなりません。
2. When updating the "avg_rtcp_size" using the variable "packet_size"
(section 6.3.3 of [RFC3550]), the value of "packet_size" MUST
include the size of the additional fields added by SRTCP.
2. 可変「パケット_サイズ」(.3セクション6.3[RFC3550])を使用することで「avg_rtcp_サイズ」をアップデートするとき、「パケット_サイズ」の値はSRTCPによって加えられた追加分野のサイズを含まなければなりません。
Baugher, et al. Standards Track [Page 18] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[18ページ]。
With these measures in place the SRTCP messages will not use more than the allotted bandwidth. The effect of the size of the added fields on the SRTCP traffic will be that messages will be sent with longer packet intervals. The increase in the intervals will be directly proportional to size of the added fields. For the pre- defined transforms, the size of the added fields will be at least 14 octets, and upper bounded depending on MKI and the authentication tag sizes.
これらの測定が適所にあると、SRTCPメッセージは割り当てられた帯域幅以上を使用しないでしょう。 加えられた分野のサイズのSRTCP交通への効果は、より長いパケット間隔と共にメッセージを送るということでしょう。 間隔の増加は加えられた分野のサイズに正比例するようになるでしょう。 あらかじめ定義された変換、少なくとも14の八重奏、および上側の境界がある依存が進行中であったなら分野がそうする付加のサイズのために、MKIと認証はサイズにタグ付けをします。
4. Pre-Defined Cryptographic Transforms
4. 事前に定義された暗号の変換
While there are numerous encryption and message authentication algorithms that can be used in SRTP, below we define default algorithms in order to avoid the complexity of specifying the encodings for the signaling of algorithm and parameter identifiers. The defined algorithms have been chosen as they fulfill the goals listed in Section 2. Recommendations on how to extend SRTP with new transforms are given in Section 6.
SRTPで使用できる頻繁な暗号化と通報認証アルゴリズムがある間、以下では、私たちが、アルゴリズムとパラメタ識別子のシグナリングにencodingsを指定する複雑さを避けるためにデフォルトアルゴリズムを定義します。 セクション2に記載された目標を実現させて、定義されたアルゴリズムは選ばれました。 セクション6で新しい変換でどうSRTPを広げるかにおける推薦を与えます。
4.1. Encryption
4.1. 暗号化
The following parameters are common to both pre-defined, non-NULL, encryption transforms specified in this section.
以下のパラメタはこのセクションで指定された両方の事前に定義されて、非NULLの暗号化変換に共通です。
* BLOCK_CIPHER-MODE indicates the block cipher used and its mode of
operation
* n_b is the bit-size of the block for the block cipher
* k_e is the session encryption key
* n_e is the bit-length of k_e
* k_s is the session salting key
* n_s is the bit-length of k_s
* SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a
non-negative integer, specified by the message authentication code
in use.
* BLOCK_CIPHER-MODEは、暗号が使用したブロックと運転モード*n_bがブロック暗号*k_eが暗号化の主要な*n_eがk_e*k_sのビット-長さであるセッションであるのでブロックのビット-サイズが主要な*n_sに塩味を付けさせるセッションがk_s*SRTP_PREFIX_LENGTHのビット-長さがkeystream接頭語の長さ(非負の整数)が使用中のメッセージ確認コードで指定した八重奏であるということであるということであるということであることを示します。
The distinct session keys and salts for SRTP/SRTCP are by default derived as specified in Section 4.3.
SRTP/SRTCPのための異なったセッションキーと塩はデフォルトでセクション4.3で指定されるように誘導されます。
The encryption transforms defined in SRTP map the SRTP packet index and secret key into a pseudo-random keystream segment. Each keystream segment encrypts a single RTP packet. The process of encrypting a packet consists of generating the keystream segment corresponding to the packet, and then bitwise exclusive-oring that keystream segment onto the payload of the RTP packet to produce the Encrypted Portion of the SRTP packet. In case the payload size is not an integer multiple of n_b bits, the excess (least significant) bits of the keystream are simply discarded. Decryption is done the same way, but swapping the roles of the plaintext and ciphertext.
SRTPで定義された暗号化変換はSRTPパケットインデックスと秘密鍵を擬似ランダムkeystreamセグメントに写像します。 それぞれのkeystreamセグメントは単一のRTPパケットをコード化します。 パケットをコード化する過程はパケットに対応するkeystreamセグメントを発生させるのから成ります、そして、そのkeystreamセグメントがその時、SRTPパケットのEncrypted Portionを生産するRTPパケットのペイロードにoringである状態で排他的なbitwiseされます。 ペイロードサイズがn_bビットの整数倍数でないといけないので、keystreamの余分な(最も重要でない)ビットは単に捨てられます。 復号化は、平文と暗号文の役割を同じようにしますが、交換しています。
Baugher, et al. Standards Track [Page 19] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[19ページ]。
+----+ +------------------+---------------------------------+
| KG |-->| Keystream Prefix | Keystream Suffix |---+
+----+ +------------------+---------------------------------+ |
|
+---------------------------------+ v
| Payload of RTP Packet |->(*)
+---------------------------------+ |
|
+---------------------------------+ |
| Encrypted Portion of SRTP Packet|<--+
+---------------------------------+
+----+ +------------------+---------------------------------+ | kg| -->、| Keystream接頭語| Keystream接尾語|---+ +----+ +------------------+---------------------------------+ | | +---------------------------------+ v| RTPパケットの有効搭載量|->(*) +---------------------------------+ | | +---------------------------------+ | | SRTPパケットのコード化された部分| <--+ +---------------------------------+
Figure 3: Default SRTP Encryption Processing. Here KG denotes the keystream generator, and (*) denotes bitwise exclusive-or.
図3: デフォルトSRTP暗号化処理。 ここで、KGがkeystreamジェネレータ、および(*)を指示する、指示、bitwiseする、排他的論理和。
The definition of how the keystream is generated, given the index, depends on the cipher and its mode of operation. Below, two such keystream generators are defined. The NULL cipher is also defined, to be used when encryption of RTP is not required.
インデックスを考えて、keystreamがどう発生するかに関する定義は暗号とその運転モードに依存します。 以下では、そのような2個のkeystreamジェネレータが定義されます。 また、NULL暗号は、RTPの暗号化が必要でないときに、使用されるために定義されます。
The SRTP definition of the keystream is illustrated in Figure 3. The initial octets of each keystream segment MAY be reserved for use in a message authentication code, in which case the keystream used for encryption starts immediately after the last reserved octet. The initial reserved octets are called the "keystream prefix" (not to be confused with the "encryption prefix" of [RFC3550, Section 6.1]), and the remaining octets are called the "keystream suffix". The keystream prefix MUST NOT be used for encryption. The process is illustrated in Figure 3.
keystreamのSRTP定義は図3で例証されます。 それぞれのkeystreamセグメントの初期の八重奏はメッセージ確認コードにおける使用のために控えられるかもしれません、keystreamが最後の予約された八重奏直後暗号化始めに使用したどの場合に。 初期の予約された八重奏は「keystream接頭語」([RFC3550、セクション6.1]の「暗号化接頭語」に混乱しない)と呼ばれます、そして、残っている八重奏は「keystream接尾語」と呼ばれます。 暗号化にkeystream接頭語を使用してはいけません。 過程は図3で例証されます。
The number of octets in the keystream prefix is denoted as SRTP_PREFIX_LENGTH. The keystream prefix is indicated by a positive, non-zero value of SRTP_PREFIX_LENGTH. This means that, even if confidentiality is not to be provided, the keystream generator output may still need to be computed for packet authentication, in which case the default keystream generator (mode) SHALL be used.
keystream接頭語の八重奏の数はSRTP_PREFIX_LENGTHとして指示されます。 keystream接頭語はSRTP_PREFIX_LENGTHの陽の非ゼロ値によって示されます。 これは、ジェネレータ出力がまだパケット認証のために計算される必要があるかもしれないkeystream、その場合デフォルトkeystreamジェネレータ(モード)SHALLが秘密性が提供されないつもりであってもさえ使用されることを意味します。
The default cipher is the Advanced Encryption Standard (AES) [AES], and we define two modes of running AES, (1) Segmented Integer Counter Mode AES and (2) AES in f8-mode. In the remainder of this section, let E(k,x) be AES applied to key k and input block x.
デフォルト暗号はエー・イー・エス(AES)[AES]です、そして、私たちはf8-モードでAES、(1)の区分されたInteger Counter Mode AES、および(2)AESを走らせる2つのモードを定義します。 このセクションの残りでは、E(k、x)がキーkと入力ブロックxに適用されたAESであることをさせてください。
Baugher, et al. Standards Track [Page 20] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[20ページ]。
4.1.1. AES in Counter Mode
4.1.1. カウンタモードによるAES
Conceptually, counter mode [AES-CTR] consists of encrypting successive integers. The actual definition is somewhat more complicated, in order to randomize the starting point of the integer sequence. Each packet is encrypted with a distinct keystream segment, which SHALL be computed as follows.
概念的に、カウンタモード[AES-CTR]は連続した整数をコード化するのから成ります。 実際の定義は、整数系列の出発点をランダマイズするためにいくらか複雑です。 各パケットは異なったkeystreamセグメントでコード化されて、どのSHALLが以下の通り計算されますか?
A keystream segment SHALL be the concatenation of the 128-bit output blocks of the AES cipher in the encrypt direction, using key k = k_e, in which the block indices are in increasing order. Symbolically, each keystream segment looks like
keystreamがAESの128ビットの出力ブロックの連結が中の暗号であったならSHALLを区分する、指示をコード化してください、主要なk=k_eを使用して、ブロックインデックスリストが増加するオーダーでどれであるかで。 象徴的に、それぞれのkeystreamセグメントに似ています。
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
E(k、IV)|| E(k、IV+1のモッズ風の2^128)|| E(k、IV+2のモッズ風の2^128)…
where the 128-bit integer value IV SHALL be defined by the SSRC, the SRTP packet index i, and the SRTP session salting key k_s, as below.
128ビットの整数がIV SHALLを評価するところでは、SSRC、SRTPパケットインデックスi、および主要なk_sに塩味を付けさせるSRTPセッションで定義されてください、下として。
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
IV=(k_s*2^16)XOR(SSRC*2^64)XOR(i*2^16)
Each of the three terms in the XOR-sum above is padded with as many leading zeros as needed to make the operation well-defined, considered as a 128-bit value.
上のXOR-合計における、それぞれの3つの用語が128ビットの値であるとみなされた操作を明確にするのが必要であるのと同じくらい多くの先行ゼロで水増しされます。
The inclusion of the SSRC allows the use of the same key to protect distinct SRTP streams within the same RTP session, see the security caveats in Section 9.1.
同じキーの使用は同じRTPセッション中にSSRCの包含で異なったSRTPの流れを保護できて、セクション9.1でセキュリティ警告を見てください。
In the case of SRTCP, the SSRC of the first header of the compound packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s SHALL be replaced by the SRTCP encryption session key and salt.
SRTCPの場合に、合成パケットの最初のヘッダーのSSRCを使用しなければなりません、i SHALL。31ビットのSRTCPインデックスとk_e、k_sがSHALLであったなら、SRTCP暗号化セッションキーと塩に取り替えてください。
Note that the initial value, IV, is fixed for each packet and is formed by "reserving" 16 zeros in the least significant bits for the purpose of the counter. The number of blocks of keystream generated for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream re-use, see below. The AES has a block size of 128 bits, so 2^16 output blocks are sufficient to generate the 2^23 bits of keystream needed to encrypt the largest possible RTP packet (except for IPv6 "jumbograms" [RFC2675], which are not likely to be used for RTP-based multimedia traffic). This restriction on the maximum bit-size of the packet that can be encrypted ensures the security of the encryption method by limiting the effectiveness of probabilistic attacks [BDJR].
初期の値(IV)が各パケットのために修理されていて、16のゼロがカウンタの目的のために最下位ビットで「予約」であることによって形成されることに注意してください。 IVのどんな一定の価値のためにも発生するブロックのkeystreamの数はkeystream再使用を避けるために2^16を超えてはいけなくて、以下を見てください。 AESには128ビットのブロック・サイズがあるので、2^16出力ブロックがkeystreamの23ビットが可能な限り大きいRTPパケット(RTPベースのマルチメディア交通に使用されそうにないIPv6"jumbograms"[RFC2675]を除いた)をコード化する必要があった2^を発生させるように十分です。 コード化できるパケットの最大のビット-サイズにおけるこの制限は、確率的な攻撃[BDJR]の有効性を制限することによって、暗号化方法のセキュリティを確実にします。
For a particular Counter Mode key, each IV value used as an input MUST be distinct, in order to avoid the security exposure of a two- time pad situation (Section 9.1). To satisfy this constraint, an implementation MUST ensure that the combination of the SRTP packet
特定のCounter Modeキーに関しては、入力として使用されるそれぞれのIV値は異なるに違いありません、2時間パッド状況(セクション9.1)のセキュリティ露出を避けるために。 この規制を満たすために、実現がそれを確実にしなければならない、SRTPパケットの組み合わせ
Baugher, et al. Standards Track [Page 21] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[21ページ]。
index of ROC || SEQ, and the SSRC used in the construction of the IV are distinct for any particular key. The failure to ensure this uniqueness could be catastrophic for Secure RTP. This is in contrast to the situation for RTP itself, which may be able to tolerate such failures. It is RECOMMENDED that, if a dedicated security module is present, the RTP sequence numbers and SSRC either be generated or checked by that module (i.e., sequence-number and SSRC processing in an SRTP system needs to be protected as well as the key).
ROCのインデックス|| SEQ、およびIVの構造に使用されるSSRCはそうです。どんな特定のキーにおいても、異なります。 Secure RTPに、このユニークさを確実にしないことは壊滅的であるかもしれません。 これはそのような失敗を許容できるかもしれないRTP自身のための状況と対照的になっています。 RTP一連番号とひたむきなセキュリティーモジュールが存在しているならSSRCがそのモジュールで発生するか、またはチェックされるのが、RECOMMENDED(すなわち、一連番号とSSRC処理は、SRTPシステムでキーと同様に保護される必要がある)です。
4.1.2. AES in f8-mode
4.1.2. f8-モードによるAES
To encrypt UMTS (Universal Mobile Telecommunications System, as 3G networks) data, a solution (see [f8-a] [f8-b]) known as the f8- algorithm has been developed. On a high level, the proposed scheme is a variant of Output Feedback Mode (OFB) [HAC], with a more elaborate initialization and feedback function. As in normal OFB, the core consists of a block cipher. We also define here the use of AES as a block cipher to be used in what we shall call "f8-mode of operation" RTP encryption. The AES f8-mode SHALL use the same default sizes for session key and salt as AES counter mode.
UMTS(3Gネットワークとしての普遍的なモバイルTelecommunications System)データをコード化するために、f8アルゴリズムとして知られている解決策([f8-a][f8-b]を見る)は見いだされました。 高いレベルでは、提案された計画はOutput Feedback Mode(OFB)[HAC]の異形です、より入念な初期化とフィードバック機能で。 正常なOFBのように、コアはブロック暗号から成ります。 また、私たちは、私たちが「f8-運転モード」RTP暗号化と呼ぶつもりであるものに使用されるためにここでAESの使用をブロック暗号と定義します。 AESがモードを打ち返すとき、AES f8-モードSHALLはセッションキーと塩に同じデフォルトサイズを使用します。
Figure 4 shows the structure of block cipher, E, running in f8-mode.
f8-モードへ駆け込んで、図4はブロック暗号、Eの構造を示しています。
Baugher, et al. Standards Track [Page 22] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[22ページ]。
IV
|
v
+------+
| |
+--->| E |
| +------+
| |
m -> (*) +-----------+-------------+-- ... ------+
| IV' | | | |
| | j=1 -> (*) j=2 -> (*) ... j=L-1 ->(*)
| | | | |
| | +-> (*) +-> (*) ... +-> (*)
| | | | | | | |
| v | v | v | v
| +------+ | +------+ | +------+ | +------+
k_e ---+--->| E | | | E | | | E | | | E |
| | | | | | | | | | |
+------+ | +------+ | +------+ | +------+
| | | | | | |
+------+ +--------+ +-- ... ----+ |
| | | |
v v v v
S(0) S(1) S(2) . . . S(L-1)
IV| +に対して------+ | | +--->| E| | +------+ | | m->(*)+-----------+-------------+-- ... ------+ | 'IV'| | | | | | j=1->(*)j=2->(*)…j=L-1->(*)| | | | | | | +->(*)+->(*)… +->(*)| | | | | | | | | v| v| v| v| +------+ | +------+ | +------+ | +------+ k_e---+--->| E| | | E| | | E| | | E| | | | | | | | | | | | +------+ | +------+ | +------+ | +------+ | | | | | | | +------+ +--------+ +-- ... ----+ | | | | | v v対S(0) S(1) S(2)Sに…(L-1)
Figure 4. f8-mode of operation (asterisk, (*), denotes bitwise XOR). The figure represents the KG in Figure 3, when AES-f8 is used.
図4f8-運転モード(アスタリスク(*)はbitwise XORを指示します)。 AES-f8が使用されているとき、図は図3にKGを表します。
4.1.2.1. f8 Keystream Generation
4.1.2.1. f8 Keystream Generation
The Initialization Vector (IV) SHALL be determined as described in Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP).
そして、初期設定Vector(IV)SHALL、セクション4.1.2で.2について説明するので断固としてください、(コネセクション4.1.2.3、SRTCP)
Let IV', S(j), and m denote n_b-bit blocks. The keystream, S(0) ||... || S(L-1), for an N-bit message SHALL be defined by setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0. For j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it is not already an integer) compute
'IVをさせてください'、S(j)、およびmはn_bビットのブロックを指示します。 keystream、S(0)||... || 'S(L-1)、N-ビットメッセージSHALLに関して、IV'=E(k_e XOR m、IV)、およびS(-1)=00を設定することによって、定義されてください。0. j=0、1。L=N/n_b(それが既に整数でないなら最も近い整数まで一周します)が計算するL-1
S(j) = E(k_e, IV' XOR j XOR S(j-1))
S(j)はEと等しいです。'(k_e、IV'XOR j XOR S(j-1))
Notice that the IV is not used directly. Instead it is fed through E under another key to produce an internal, "masked" value (denoted IV') to prevent an attacker from gaining known input/output pairs.
IVが直接使用されていないのに注意してください。 '代わりに、攻撃者が既知入力/出力組を獲得するのを防ぐために、内部の、そして、「仮面」の値(IV'を指示する)を生産するために別のキーの下でEを通してそれを与えます。
Baugher, et al. Standards Track [Page 23] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[23ページ]。
The role of the internal counter, j, is to prevent short keystream cycles. The value of the key mask m SHALL be
内部のカウンタの役割(j)は短いkeystreamサイクルを防ぐことです。 主要なマスクm SHALLの値
m = k_s || 0x555..5,
m=k_s|| 0×555。5,
i.e., the session salting key, appended by the binary pattern 0101.. to fill out the entire desired key size, n_e.
すなわち、バイナリパターン0101によって追加された、全体の必要な主要なサイズ、n_eに書き込んだキーに塩味を付けさせるセッション。
The sender SHOULD NOT generate more than 2^32 blocks, which is sufficient to generate 2^39 bits of keystream. Unlike counter mode, there is no absolute threshold above (below) which f8 is guaranteed to be insecure (secure). The above bound has been chosen to limit, with sufficient security margin, the probability of degenerative behavior in the f8 keystream generation.
送付者SHOULD NOTは2以上^を32ブロック発生させます(keystreamの2^39ビットを発生させるように十分です)。 カウンタモードと異なって、不安定に(安全な)なるように、絶対閾値は全く(below)に上f8が保証されるありません。 上のバウンドは、十分なセキュリティマージンでf8 keystream世代における、退化的な振舞いの確率を制限するために選ばれました。
4.1.2.2. f8 SRTP IV Formation
4.1.2.2. f8 SRTP IV Formation
The purpose of the following IV formation is to provide a feature which we call implicit header authentication (IHA), see Section 9.5.
以下のIV構成の目的は暗黙のヘッダー認証(IHA)を私たちが呼ぶ特徴に提供することです、セクション9.5は見ます。
The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following way:
128ビットSRTP IVは形成コネが以下の道であったならAES-f8 SHALLを妨げます:
IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC
IV=0x00|| M|| 太平洋標準時|| SEQ|| t|| SSRC|| ロック
M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from the cryptographic context.
M、PT、SEQ、TS、SSRC SHALL、RTPヘッダーから、取ってください。 ROCは暗号の文脈から来ています。
The presence of the SSRC as part of the IV allows AES-f8 to be used when a master key is shared between multiple streams within the same RTP session, see Section 9.1.
マスターキーが同じRTPセッション中に複数の流れの間で共有されるとき、IVの一部としてのSSRCの存在は、AES-f8が使用されるのを許容します、とセクション9.1は見ます。
4.1.2.3. f8 SRTCP IV Formation
4.1.2.3. f8 SRTCP IV Formation
The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the following way:
128ビットSRTCP IVは形成コネが以下の道であったならAES-f8 SHALLを妨げます:
IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC
IV=0。0 || E|| SRTCPインデックス|| V|| P|| RC|| 太平洋標準時|| 長さ|| SSRC
where V, P, RC, PT, length, SSRC SHALL be taken from the first header in the RTCP compound packet. E and SRTCP index are the 1-bit and 31-bit fields added to the packet.
どこ、V、P、RC、PT、長さ、SSRC SHALL、最初のヘッダーから、RTCP合成パケットで取ってくださいか。 EとSRTCPインデックスはパケットに加えられた1ビットの、そして、31ビットの分野です。
Baugher, et al. Standards Track [Page 24] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[24ページ]。
4.1.3. NULL Cipher
4.1.3. ヌル暗号
The NULL cipher is used when no confidentiality for RTP/RTCP is requested. The keystream can be thought of as "000..0", i.e., the encryption SHALL simply copy the plaintext input into the ciphertext output.
RTP/RTCPのための秘密性が全く要求されていないとき、NULL暗号は使用されています。 「000」としてkeystreamを考えることができます。すなわち、0インチと、暗号化SHALLは単に暗号文出力に平文入力をコピーします。
4.2. Message Authentication and Integrity
4.2. 通報認証と保全
Throughout this section, M will denote data to be integrity protected. In the case of SRTP, M SHALL consist of the Authenticated Portion of the packet (as specified in Figure 1) concatenated with the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M SHALL consist of the Authenticated Portion (as specified in Figure 2) only.
このセクション中では、Mは、保護された保全になるようにデータを指示するでしょう。 SRTPの場合では、M SHALLはROCと共に連結されたパケット(図1で指定されるように)のAuthenticated Portionから成ります、認証されたM=Portion|| ロック。 SRTCPの場合では、M SHALLはAuthenticated Portion(図2で指定されるように)だけから成ります。
Common parameters:
一般的なパラメタ:
* AUTH_ALG is the authentication algorithm
* k_a is the session message authentication key
* n_a is the bit-length of the authentication key
* n_tag is the bit-length of the output authentication tag
* SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
defined above, a parameter of AUTH_ALG
* AUTH_ALGによる認証アルゴリズム*kが通報認証の主要な*nが認証主要な*n_タグのビット-長さであるセッションが出力認証タグ*SRTP_PREFIX_LENGTHのビット-長さは上で定義されるようにkeystream接頭語の八重奏の長さです、AUTH_ALGのパラメタということであるということであるということです。
The distinct session authentication keys for SRTP/SRTCP are by default derived as specified in Section 4.3.
SRTP/SRTCPのための異なったセッション認証キーはデフォルトでセクション4.3で指定されるように引き出されます。
The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for any particular fixed value of the key.
値、n、n_タグ、およびSRTP_PREFIX_LENGTH MUSTでは、キーの値が修理されたあらゆる事項には、修理されてください。
We describe the process of computing authentication tags as follows. The sender computes the tag of M and appends it to the packet. The SRTP receiver verifies a message/authentication tag pair by computing a new authentication tag over M using the selected algorithm and key, and then compares it to the tag associated with the received message. If the two tags are equal, then the message/tag pair is valid; otherwise, it is invalid and the error audit message "AUTHENTICATION FAILURE" MUST be returned.
私たちは以下の認証タグを計算する過程について説明します。 送付者は、Mのタグを計算して、それをパケットに追加します。 SRTP受信機は、Mの上で選択されたアルゴリズムとキーを使用することで新しい認証タグを計算することによってメッセージ/認証タグ組について確かめて、次に、受信されたメッセージに関連しているタグとそれを比較します。 2個のタグが等しいなら、メッセージ/タグ組は有効です。 さもなければ、それは無効です、そして、「認証失敗」という誤り監査メッセージを返さなければなりません。
4.2.1. HMAC-SHA1
4.2.1. HMAC-SHA1
The pre-defined authentication transform for SRTP is HMAC-SHA1 [RFC2104]. With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL be 0. For SRTP (respectively SRTCP), the HMAC SHALL be applied to the session authentication key and M as specified above, i.e., HMAC(k_a, M). The HMAC output SHALL then be truncated to the n_tag left-most bits.
SRTPのための事前に定義された認証変換はHMAC-SHA1[RFC2104]です。 HMAC-SHA1、SRTP_PREFIX_LENGTH(図3)SHALL、0になってください。 SRTP(それぞれSRTCP)、HMAC SHALL、上で指定されるとしてセッション認証キーとMに適用されてください、すなわち、HMAC(k、M)。 HMACはSHALLを出力して、次に、n_タグ最も左のビットに先端を切られてください。
Baugher, et al. Standards Track [Page 25] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[25ページ]。
4.3. Key Derivation
4.3. 主要な派生
4.3.1. Key Derivation Algorithm
4.3.1. 主要な誘導アルゴリズム
Regardless of the encryption or message authentication transform that is employed (it may be an SRTP pre-defined transform or newly introduced according to Section 6), interoperable SRTP implementations MUST use the SRTP key derivation to generate session keys. Once the key derivation rate is properly signaled at the start of the session, there is no need for extra communication between the parties that use SRTP key derivation.
採用している(それは事前に定義された変換であるかセクション6によると、新たに導入されたSRTPであるかもしれません)暗号化か通報認証変換にかかわらず、共同利用できるSRTP実現は、セッションキーを発生させるのにSRTPの主要な派生を使用しなければなりません。 主要な派生率がセッションの始めでいったん適切に合図されると、SRTPの主要な派生を使用するパーティーの余分なコミュニケーションの必要は全くありません。
packet index ---+
|
v
+-----------+ master +--------+ session encr_key
| ext | key | |---------->
| key mgmt |-------->| key | session auth_key
| (optional | | deriv |---------->
| rekey) |-------->| | session salt_key
| | master | |---------->
+-----------+ salt +--------+
パケットインデックス---+ | +に対して-----------+ マスター+--------+ セッションencr_キー| ext| キー| |、-、-、-、-、-、-、-、-、--、>| 主要な管理|、-、-、-、-、-、-、--、>| キー| セッションauth_キー| (任意である、| | deriv|、-、-、-、-、-、-、-、-、--、>| rekey、) |、-、-、-、-、-、-、--、>|、| セッション塩_キー| | マスター| |---------->+-----------+ 塩+--------+
Figure 5: SRTP key derivation.
図5: SRTPの主要な派生。
At least one initial key derivation SHALL be performed by SRTP, i.e., the first key derivation is REQUIRED. Further applications of the key derivation MAY be performed, according to the "key_derivation_rate" value in the cryptographic context. The key derivation function SHALL initially be invoked before the first packet and then, when r > 0, a key derivation is performed whenever index mod r equals zero. This can be thought of as "refreshing" the session keys. The value of "key_derivation_rate" MUST be kept fixed for the lifetime of the associated master key.
少なくともある初期の主要な派生SHALLがSRTPによって実行されて、すなわち、最初の主要な派生はREQUIREDです。 暗号の文脈の「主要な_派生_レート」値に従って、主要な派生のさらなる応用は実行されるかもしれません。 主要な派生機能SHALLが初めは最初のパケット、前次にr>0であるときに時呼び出されて、インデックスモッズrがゼロと等しいときはいつも、主要な派生は実行されます。 セッションキーが「リフレッシュ」であるとしてこれを考えることができます。 関連マスターキーの生涯に修理されるように「主要な_派生_レート」の値を保たなければなりません。
Interoperable SRTP implementations MAY also derive session salting keys for encryption transforms, as is done in both of the pre- defined transforms.
また、共同利用できるSRTP実現は暗号化変換のためのキーに塩味を付けさせるセッションを引き出すかもしれません、あらかじめ定義された変換の両方でするように。
Let m and n be positive integers. A pseudo-random function family is
a set of keyed functions {PRF_n(k,x)} such that for the (secret)
random key k, given m-bit x, PRF_n(k,x) is an n-bit string,
computationally indistinguishable from random n-bit strings, see
[HAC]. For the purpose of key derivation in SRTP, a secure PRF with
m = 128 (or more) MUST be used, and a default PRF transform is
defined in Section 4.3.3.
mとnが正の整数であることをさせてください。 m-ビットxを考えて、擬似ランダム機能家族が合わせられた機能PRF(k、x)の1セットであるので、PRF(k、x)は(秘密)のランダムキーkに関するn-ビット列です、無作為のn-ビット列から計算上区別がつきません、と[HAC]は見ます。 SRTPでの主要な派生の目的のために、mがある安全なPRF=128(さらに)を使用しなければなりません、そして、PRFが変えるデフォルトはセクション4.3.3で定義されます。
Baugher, et al. Standards Track [Page 26] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[26ページ]。
Let "a DIV t" denote integer division of a by t, rounded down, and with the convention that "a DIV 0 = 0" for all a. We also make the convention of treating "a DIV t" as a bit string of the same length as a, and thus "a DIV t" will in general have leading zeros.
「DIV t」に概数に切り下げられたtによるaと「DIV0はすべてのaのために何0インチも等しい」コンベンションと共に整数分割を指示させてください。 また、私たちはaと同じ長さのしばらくストリングとして「DIV t」を扱うコンベンションを作ります、そして、その結果、一般に、「DIV t」には、先行ゼロがあるでしょう。
Key derivation SHALL be defined as follows in terms of <label>, an 8-bit constant (see below), master_salt and key_derivation_rate, as determined in the cryptographic context, and index, the packet index (i.e., the 48-bit ROC || SEQ for SRTP):
主要な派生SHALLは以下の通り暗号の文脈で決定するように<ラベル>、8ビットの定数(以下を見る)、マスター_塩、および主要な_派生_レートで定義されて、索引をつけます、パケットインデックス(すなわち、48ビットのROC| | SRTPのためのSEQ):
* Let r = index DIV key_derivation_rate (with DIV as defined above).
* rをインデックスDIVキー_派生_率(上で定義されるDIVと)との等しさにしてください。
* Let key_id = <label> || r.
* 主要な_イド=<に>をラベルさせてください。|| r。
* Let x = key_id XOR master_salt, where key_id and master_salt are
aligned so that their least significant bits agree (right-
alignment).
* xを主要な_イドXORマスター_塩との等しさにしてください、それらの最下位ビットが(正しい整列)に同意するように主要な_イドとマスター_塩が並べられるところで。
<label> MUST be unique for each type of key to be derived. We currently define <label> 0x00 to 0x05 (see below), and future extensions MAY specify new values in the range 0x06 to 0xff for other purposes. The n-bit SRTP key (or salt) for this packet SHALL then be derived from the master key, k_master as follows:
<ラベル>は、それぞれのタイプのキーが引き出されるためにユニークでなければなりません。 私たちは現在0×00から0×05に<ラベル>を定義します、そして、(以下を見てください)今後の拡大は他の目的として範囲0x06で新しい値を0xffに指定するかもしれません。 以下のマスターキー、k_から派生しているnビットのSRTPこのパケットSHALLに、主要な(または、塩)当時のマスター:
PRF_n(k_master, x).
PRF(k_マスター、x)。
(The PRF may internally specify additional formatting and padding of x, see e.g., Section 4.3.3 for the default PRF.)
(例えば、デフォルトPRFのためのセクション4.3.3は、PRFが内部的にxの追加形式と詰め物を指定するかもしれないのを見ます。)
The session keys and salt SHALL now be derived using:
セッションは、現在、SHALLを合わせて、塩味を付けさせます。使用することで、引き出されてください:
- k_e (SRTP encryption): <label> = 0x00, n = n_e.
- k_e(SRTP暗号化): 0×00、<ラベル>=nはn_eと等しいです。
- k_a (SRTP message authentication): <label> = 0x01, n = n_a.
- k(SRTP通報認証): 0×01、<ラベル>=nはnと等しいです。
- k_s (SRTP salting key): <label> = 0x02, n = n_s.
- k_s(キーに塩味を付けさせるSRTP): 0×02、<ラベル>=nはn_sと等しいです。
where n_e, n_s, and n_a are from the cryptographic context.
n_e、n_s、およびnが暗号の文脈から来ているところ。
The master key and master salt MUST be random, but the master salt MAY be public.
マスターキーとマスター塩は無作為であるに違いありませんが、マスター塩は公共であるかもしれません。
Note that for a key_derivation_rate of 0, the application of the key derivation SHALL take place exactly once.
0の主要な_派生_レートのために、主要な派生SHALLのアプリケーションがまさに一度行われることに注意してください。
The definition of DIV above is purely for notational convenience. For a non-zero t among the set of allowed key derivation rates, "a DIV t" can be implemented as a right-shift by the base-2 logarithm of
DIVの上の定義は純粋に記号法の便宜のためのものです。 許容主要な派生率のセットの中の非ゼロtに関しては、ベース-2対数は正しいシフトとして「DIV t」を実行できます。
Baugher, et al. Standards Track [Page 27] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[27ページ]。
t. The derivation operation is further facilitated if the rates are chosen to be powers of 256, but that granularity was considered too coarse to be a requirement of this specification.
t。 レートが256人の強国になるように選ばれているなら、派生操作はさらに容易にされましたが、その粒状はこの仕様の要件であるように思えないほど粗いと考えられました。
The upper limit on the number of packets that can be secured using the same master key (see Section 9.2) is independent of the key derivation.
同じマスターキー(セクション9.2を見る)を使用することで安全にすることができるパケットの数の上限は主要な派生から独立しています。
4.3.2. SRTCP Key Derivation
4.3.2. SRTCPの主要な派生
SRTCP SHALL by default use the same master key (and master salt) as SRTP. To do this securely, the following changes SHALL be done to the definitions in Section 4.3.1 when applying session key derivation for SRTCP.
SRTCP SHALLはデフォルトでSRTPとして同じマスターキーを使用します(塩を習得してください)。 しっかりとこれをするために、以下はSHALLを変えます。SRTCPのためにセッションの主要な派生を適用するときにはセクション4.3.1との定義にしてください。
Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting key.
SRTPインデックスを32ビットの量に取り替えてください: 0 || SRTCPはSRTCP暗号化キーのための<ラベル>=0×03、SRTCP認証キーのための<ラベル>=0×04に索引をつけて(すなわち、それを固定0ビットに取り替えて、E-ビットを除きます)、使用します、そして、<ラベル>はキーに塩味を付けさせるSRTCPのために0×05と等しいです。
4.3.3. AES-CM PRF
4.3.3. AES-CM PRF
The currently defined PRF, keyed by 128, 192, or 256 bit master key, has input block size m = 128 and can produce n-bit outputs for n up to 2^23. PRF_n(k_master,x) SHALL be AES in Counter Mode as described in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16), and with the output keystream truncated to the n first (left-most) bits. (Requiring n/128, rounded up, applications of AES.)
128ビットか192ビットか256ビットのマスターキーによって合わせられた現在定義されたPRFは入力ブロック・サイズm=128を持って、n上のためのn-ビット出力を2^23に起こすことができます。 PRF(k_マスター、x)SHALLは(x*2^16)と等しい主要なk_マスター、およびIVに適用されたセクション4.1.1で説明されるようにCounter ModeのAESであり、出力keystreamで最初(最もいなくなる)のビットにnに先端を切らせました。 (n/128、丸い上、AESのアプリケーションを必要とします。)
5. Default and mandatory-to-implement Transforms
5. デフォルトと実行するために義務的なTransforms
The default transforms also are mandatory-to-implement transforms in SRTP. Of course, "mandatory-to-implement" does not imply "mandatory-to-use". Table 1 summarizes the pre-defined transforms. The default values below are valid for the pre-defined transforms.
デフォルト変換もSRTPでの実行するために義務的な変換です。 もちろん、「実行するために義務的」は「使用するために義務的」を含意しません。 テーブル1は事前に定義された変換をまとめます。事前に定義された変換に、以下のデフォルト値は有効です。
mandatory-to-impl. optional default
implに義務的である、任意のデフォルト
encryption AES-CM, NULL AES-f8 AES-CM message integrity HMAC-SHA1 - HMAC-SHA1 key derivation (PRF) AES-CM - AES-CM
暗号化AES-CM、NULL AES-f8 AES-CMメッセージの保全HMAC-SHA1--HMAC-SHA1の主要な派生(PRF)AES-CM--AES-CM
Table 1: Mandatory-to-implement, optional and default transforms in SRTP and SRTCP.
テーブル1: 実行するために義務的である、SRTPとSRTCPでの任意、そして、デフォルト変換。
Baugher, et al. Standards Track [Page 28] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[28ページ]。
5.1. Encryption: AES-CM and NULL
5.1. 暗号化: AES-CMとヌル
AES running in Segmented Integer Counter Mode, as defined in Section 4.1.1, SHALL be the default encryption algorithm. The default key lengths SHALL be 128-bit for the session encryption key (n_e). The default session salt key-length (n_s) SHALL be 112 bits.
デフォルト暗号化がアルゴリズムであったならSegmented Integer Counter Modeでセクション4.1.1で定義されるようなSHALLを走らせるAES。 デフォルトキー長SHALLはセッション暗号化キーのために128によって噛み付かれます(n_e)。 デフォルトセッションは112がビットであったならキー長(n_s)SHALLに塩味を付けさせます。
The NULL cipher SHALL also be mandatory-to-implement.
NULLはSHALLを解きます、また、実行するには、義務的であってください。
5.2. Message Authentication/Integrity: HMAC-SHA1
5.2. 通報認証/保全: HMAC-SHA1
HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message authentication code. The default session authentication key-length (n_a) SHALL be 160 bits, the default authentication tag length (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero for HMAC-SHA1. In addition, for SRTCP, the pre-defined HMAC-SHA1 MUST NOT be applied with a value of n_tag, nor n_a, that are smaller than these defaults. For SRTP, smaller values are NOT RECOMMENDED, but MAY be used after careful consideration of the issues in Section 7.5 and 9.5.
デフォルトがメッセージ確認コードであったならコネセクション4.2.1、SHALLを定義するのによるHMAC-SHA1。 80ビットと、SRTP_PREFIX_LENGTH SHALLになってください。デフォルトセッション認証キー長(n)SHALL、160ビットになってください、デフォルト認証タグの長さ(n_タグ)のSHALL、HMAC-SHA1のためのゼロになってください。 事前に定義されたHMAC-SHA1 MUST NOTがn_タグ、およびnの値で適用されて、SRTCPに関して、さらに、それはこれらのデフォルトより小さいです。 SRTPのために、より小さい値は、NOT RECOMMENDEDですが、セクション7.5と9.5における、問題の熟慮の後に使用されるかもしれません。
5.3. Key Derivation: AES-CM PRF
5.3. キー派生: AES-CM PRF
The AES Counter Mode based key derivation and PRF defined in Sections 4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default method for generating session keys. The default master salt length SHALL be 112 bits and the default key-derivation rate SHALL be zero.
発生のためのデフォルト方法がセッションキーであったなら128ビットのマスターキー、SHALLを使用して、AES Counter Modeのベースの主要な派生とPRFはセクション4.3の.1〜4.3で.3を定義しました。 デフォルトは112ビットとデフォルトが主要な派生レートSHALLであったなら塩の長さのSHALLを習得します。ゼロになってください。
6. Adding SRTP Transforms
6. SRTPが変形すると言い足します。
Section 4 provides examples of the level of detail needed for defining transforms. Whenever a new transform is to be added to SRTP, a companion standard track RFC MUST be written to exactly define how the new transform can be used with SRTP (and SRTCP). Such a companion RFC SHOULD avoid overlap with the SRTP protocol document. Note however, that it MAY be necessary to extend the SRTP or SRTCP cryptographic context definition with new parameters (including fixed or default values), add steps to the packet processing, or even add fields to the SRTP/SRTCP packets. The companion RFC SHALL explain any known issues regarding interactions between the transform and other aspects of SRTP.
セクション4は変換を定義するのに必要である詳細のレベルに関する例を提供します。SRTP、仲間の標準の道のRFC MUSTに加えられる新しい変換がことであるときはいつも、書かれていて、まさにSRTP(そして、SRTCP)と共に新しい変換をどう使用できるかを定義してください。 RFC SHOULDが避けるそのような仲間はSRTPプロトコルドキュメントに重なります。 しかしながら、注意、新しいパラメタ(修理されるかデフォルト値を含んでいる)でSRTPかSRTCPの暗号の文脈定義を広げているか、パケット処理にステップを加えるか、またはSRTP/SRTCPパケットに分野を加えるのさえ必要であるかもしれません。 仲間RFC SHALLはSRTPの変換と他の局面との相互作用に関するどんな知られている問題についても説明します。
Each new transform document SHOULD specify its key attributes, e.g., size of keys (minimum, maximum, recommended), format of keys, recommended/required processing of input keying material, requirements/recommendations on key lifetime, re-keying and key derivation, whether sharing of keys between SRTP and SRTCP is allowed or not, etc.
SRTPとSRTCPの間のキーの共有が許されているか否かに関係なく、主要な生涯、再の合わせるおよび主要な派生のときに材料を合わせる入力の処理、要件/推薦をそれぞれの新しい変換ドキュメントSHOULDは主要な属性を指定して、推薦するか、または例えば、キー(最小の、そして、最大の、そして、お勧めの)のサイズ(キーの形式)は必要としましたなど。
Baugher, et al. Standards Track [Page 29] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[29ページ]。
An added message integrity transform SHOULD define a minimum acceptable key/tag size for SRTCP, equivalent in strength to the minimum values as defined in Section 5.2.
変換SHOULDが強さで最小の値に同等なSRTCPのためにセクション5.2で定義されるように最小の許容できるキー/タグサイズに定義する加えられたメッセージの保全。
7. Rationale
7. 原理
This section explains the rationale behind several important features of SRTP.
このセクションはSRTPのいくつかの重要な特徴の後ろで原理について説明します。
7.1. Key derivation
7.1. 主要な派生
Key derivation reduces the burden on the key establishment. As many as six different keys are needed per crypto context (SRTP and SRTCP encryption keys and salts, SRTP and SRTCP authentication keys), but these are derived from a single master key in a cryptographically secure way. Thus, the key management protocol needs to exchange only one master key (plus master salt when required), and then SRTP itself derives all the necessary session keys (via the first, mandatory application of the key derivation function).
主要な派生は主要な設立での負担を減少させます。 最大6個の異なったキーが暗号文脈単位で必要です。(SRTPとSRTCP暗号化が合わせて、塩味を付ける、SRTPとSRTCP認証キー)、唯一のこれらはaが暗号で道を保証する単一のマスターキーから派生しているコネです。 したがって、かぎ管理プロトコルは、1個のマスターキーだけを交換する必要があります、そして、(必要であったら、塩をマスタリングしてください)次に、SRTP自身はすべての必要なセッションキー(1番目を通した主要な派生機能の義務的な適用)を引き出します。
Multiple applications of the key derivation function are optional, but will give security benefits when enabled. They prevent an attacker from obtaining large amounts of ciphertext produced by a single fixed session key. If the attacker was able to collect a large amount of ciphertext for a certain session key, he might be helped in mounting certain attacks.
主要な派生機能の複数のアプリケーションが、任意ですが、可能にされると、セキュリティ利益を与えるでしょう。 彼らは、攻撃者が単一の固定セッションキーによって生産された多量の暗号文を得るのを防ぎます。 攻撃者が、あるセッションキーのために多量の暗号文を集めることができるなら、彼は上がっているある攻撃で助けられるでしょうに。
Multiple applications of the key derivation function provide backwards and forward security in the sense that a compromised session key does not compromise other session keys derived from the same master key. This means that the attacker who is able to recover a certain session key, is anyway not able to have access to messages secured under previous and later session keys (derived from the same master key). (Note that, of course, a leaked master key reveals all the session keys derived from it.)
主要な派生機能の複数のアプリケーションが、感染しているセッションキーが、他のセッションが同じマスターキーから得られたキーであると感染しないという意味で後方に提供して、セキュリティを送ります。 これは、メッセージに近づく手段を持つことができない状態でセッションキーがとにかくそうであることを確信しているaを回復できる攻撃者が下の前の、そして、後のセッションキーを固定したことを意味します(同じマスターキーから、派生します)。 (もちろん、漏らされたマスターキーがそれから得られたすべてのセッションキーを明らかにすることに注意してください。)
Considerations arise with high-rate key refresh, especially in large multicast settings, see Section 11.
セクション11は、問題がキーが特に大きいマルチキャスト設定でリフレッシュする高い率で起こるのを見ます。
7.2. Salting key
7.2. キーに塩味を付けさせます。
The master salt guarantees security against off-line key-collision attacks on the key derivation that might otherwise reduce the effective key size [MF00].
マスター塩はそうでなければ有効な主要なサイズ[MF00]を減少させるかもしれない主要な派生に対するオフライン主要な衝突攻撃に対して安全を保障します。
Baugher, et al. Standards Track [Page 30] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[30ページ]。
The derived session salting key used in the encryption, has been introduced to protect against some attacks on additive stream ciphers, see Section 9.2. The explicit inclusion method of the salt in the IV has been selected for ease of hardware implementation.
キーに塩味を付けさせるのが暗号化に使用して、導入された派生しているセッションは付加的なストリーム暗号に対するいくつかの攻撃から守ります、とセクション9.2は見ます。 IVの塩の明白な包含メソッドはハードウェア実装の容易さのために選択されました。
7.3. Message Integrity from Universal Hashing
7.3. 普遍的な論じ尽くすのからのメッセージの保全
The particular definition of the keystream given in Section 4.1 (the keystream prefix) is to give provision for particular universal hash functions, suitable for message authentication in the Wegman-Carter paradigm [WC81]. Such functions are provably secure, simple, quick, and especially appropriate for Digital Signal Processors and other processors with a fast multiply operation.
セクション4.1(keystream接頭語)で与えられているkeystreamの特定の定義は特定の普遍的なハッシュ関数への支給を与えることです、ウェッグマン-カーターパラダイム[WC81]における通報認証に適しています。 そのような機能は証明可能にそうです。安全です、簡単です、断食がある迅速で、デジタルシグナルプロセッサに特に適切で他のプロセッサは操作を掛けます。
No authentication transforms are currently provided in SRTP other than HMAC-SHA1. Future transforms, like the above mentioned universal hash functions, MAY be added following the guidelines in Section 6.
現在、認証変換を全くHMAC-SHA1以外のSRTPに提供しません。 上記の普遍的なハッシュ関数のように、今後の変換はセクション6のガイドラインに従うと言い足されるかもしれません。
7.4. Data Origin Authentication Considerations
7.4. データ発生源認証問題
Note that in pair-wise communications, integrity and data origin authentication are provided together. However, in group scenarios where the keys are shared between members, the MAC tag only proves that a member of the group sent the packet, but does not prevent against a member impersonating another. Data origin authentication (DOA) for multicast and group RTP sessions is a hard problem that needs a solution; while some promising proposals are being investigated [PCST1] [PCST2], more work is needed to rigorously specify these technologies. Thus SRTP data origin authentication in groups is for further study.
対状コミュニケーションに、保全とデータ発生源認証が一緒に提供されることに注意してください。 しかしながら、中では、キーがメンバーの間で共有されて、MACタグがそれを立証するだけであるパケットを送りますが、グループのメンバーが別のものをまねるメンバーに対して防がないシナリオは分類します。 マルチキャストとグループRTPセッションのためのデータ発生源認証(DOA)はソリューションを必要とする難問です。 いくつかの有望な提案が調査されている間[PCST1][PCST2]、より多くの仕事が、これらの技術をきびしく指定するのに必要です。 したがって、さらなる研究にはグループにおけるSRTPデータ発生源認証があります。
DOA can be done otherwise using signatures. However, this has high impact in terms of bandwidth and processing time, therefore we do not offer this form of authentication in the pre-defined packet-integrity transform.
DOAはそうでなければ、署名を使用し終わることができます。 しかしながら、これには、帯域幅と処理時間に関して強い衝撃があります、したがって、私たちは事前に定義されたパケット保全変換における、この形式の認証を提供しません。
The presence of mixers and translators does not allow data origin authentication in case the RTP payload and/or the RTP header are manipulated. Note that these types of middle entities also disrupt end-to-end confidentiality (as the IV formation depends e.g., on the RTP header preservation). A certain trust model may choose to trust the mixers/translators to decrypt/re-encrypt the media (this would imply breaking the end-to-end security, with related security implications).
RTPペイロード、そして/または、RTPヘッダーが操作されるといけないので、ミキサーと翻訳者の存在はデータ発生源認証を許しません。 また、これらのタイプの中くらいの実体が終わりから終わりへの秘密性を混乱させることに注意してください(IV構成が例えば、RTPヘッダー保存によるとき)。 確信している信頼モデルは、ミキサー/翻訳者がメディアを解読するか、または再暗号化すると信じるのを選ぶかもしれません(これが終わらせる終わりの壊れているセキュリティを含意するでしょう、関連するセキュリティ含意で)。
Baugher, et al. Standards Track [Page 31] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[31ページ]。
7.5. Short and Zero-length Message Authentication
7.5. 短くて無長さの通報認証
As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP. A full 80-bit authentication-tag SHOULD be used, but a shorter tag or even a zero-length tag (i.e., no message authentication) MAY be used under certain conditions to support either of the following two application environments.
図1に示されるように、認証タグはSRTPのRECOMMENDEDです。 完全な80ビットの認証タグSHOULDが使用されて、より短いタグだけかゼロ・レングスタグ(すなわち、通報認証がない)さえ、以下の2つのアプリケーション環境のどちらかをサポートするのに一定の条件の下で使用されるかもしれません。
1. Strong authentication can be impractical in environments where
bandwidth preservation is imperative. An important special
case is wireless communication systems, in which bandwidth is a
scarce and expensive resource. Studies have shown that for
certain applications and link technologies, additional bytes
may result in a significant decrease in spectrum efficiency
[SWO]. Considerable effort has been made to design IP header
compression techniques to improve spectrum efficiency
[RFC3095]. A typical voice application produces 20 byte
samples, and the RTP, UDP and IP headers need to be jointly
compressed to one or two bytes on average in order to obtain
acceptable wireless bandwidth economy [RFC3095]. In this case,
strong authentication would impose nearly fifty percent
overhead.
1. 強い認証は帯域幅保存が必須であるところで環境で非実用的である場合があります。 重要な特別なケースは無線通信システムです。(そこでは、帯域幅が不十分で高価なリソースです)。 研究は、あるアプリケーションとリンク技術のために、追加バイトがスペクトル効率[SWO]のかなりの減少をもたらすかもしれないのを示しました。 かなりの取り組みは、スペクトル効率[RFC3095]を改良するようにIPヘッダー圧縮のテクニックを設計させられています。 典型的な音声アプリケーションは20バイトのサンプルを作り出します、そして、RTP、UDP、およびIPヘッダーは許容できるワイヤレスの帯域幅経済[RFC3095]を得るために共同で1バイトか2バイトに平均的に圧縮される必要があります。 この場合、強い認証はおよそ50パーセントのオーバーヘッドを課すでしょう。
2. Authentication is impractical for applications that use data
links with fixed-width fields that cannot accommodate the
expansion due to the authentication tag. This is the case for
some important existing wireless channels. For example, zero-
byte header compression is used to adapt EVRC/SMV voice with
the legacy IS-95 bearer channel in CDMA2000 VoIP services. It
was found that not a single additional octet could be added to
the data, which motivated the creation of a zero-byte profile
for ROHC [RFC3242].
2. 認証タグによる拡張を収容できない固定幅の分野とのデータ・リンクを使用するアプリケーションに、認証は非実用的です。 これは何人かの重要な既存のワイヤレスのチャンネルのためのそうです。 例えば、無バイトヘッダー圧縮がレガシーでEVRC/SMV声を適合させるのに使用される、-95である、CDMA2000 VoIPサービスにおける運搬人チャンネル。 1つの追加八重奏もデータに追加できないのが見つけられました。(データはROHC[RFC3242]のための無バイトプロフィールの作成を動機づけました)。
A short tag is secure for a restricted set of applications. Consider a voice telephony application, for example, such as a G.729 audio codec with a 20-millisecond packetization interval, protected by a 32-bit message authentication tag. The likelihood of any given packet being successfully forged is only one in 2^32. Thus an adversary can control no more than 20 milliseconds of audio output during a 994-day period, on average. In contrast, the effect of a single forged packet can be much larger if the application is stateful. A codec that uses relative or predictive compression across packets will propagate the maliciously generated state, affecting a longer duration of output.
制限されたセットのアプリケーションに、短いタグは安全です。 例えば20ミリセカンドのpacketization間隔があるG.729オーディオコーデックなどの音声電話技術アプリケーションが32ビットの通報認証タグによって保護されたと考えてください。 首尾よく鍛造されるどんな与えられたパケットの見込みも2^32のうちの1であるだけです。 したがって、994日間の期間、敵は平均で20ミリセカンド未満のオーディオ出力を制御できます。 対照的に、アプリケーションがstatefulであるなら、単一の偽造パケットの効果ははるかに大きい場合があります。 パケットの向こう側に相対的であるか予言の圧縮を使用するコーデックは陰湿に生成している状態を伝播するでしょう、出力の、より長い持続時間に影響して。
Baugher, et al. Standards Track [Page 32] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[32ページ]。
Certainly not all SRTP or telephony applications meet the criteria for short or zero-length authentication tags. Section 9.5.1 discusses the risks of weak or no message authentication, and section 9.5 describes the circumstances when it is acceptable and when it is unacceptable.
確かに、どんなすべてのSRTPも電話アプリケーションも略して評価基準かゼロ・レングス認証タグに触れていません。 セクション9.5.1は弱いかいいえ、通報認証の危険について議論します、そして、それが許容できて、容認できないときに、セクション9.5は事情について説明します。
8. Key Management Considerations
8. Key Management問題
There are emerging key management standards [MIKEY] [KEYMGT] [SDMS] for establishing an SRTP cryptographic context (e.g., an SRTP master key). Both proprietary and open-standard key management methods are likely to be used for telephony applications [MIKEY] [KINK] and multicast applications [GDOI]. This section provides guidance for key management systems that service SRTP session.
現れているかぎ管理規格[マイキー]が、SRTPの暗号の文脈(例えば、SRTPマスターキー)を確立するためにあります[KEYMGT][SDMS]。 ともに独占、そして、オープンスタンダードかぎ管理メソッドは電話アプリケーション[マイキー][KINK]とマルチキャストアプリケーション[GDOI]に使用されそうです。 このセクションはそのサービスSRTPセッションのときにかぎ管理システムのための指導を提供します。
For initialization, an interoperable SRTP implementation SHOULD be given the SSRC and MAY be given the initial RTP sequence number for the RTP stream by key management (thus, key management has a dependency on RTP operational parameters). Sending the RTP sequence number in the key management may be useful e.g., when the initial sequence number is close to wrapping (to avoid synchronization problems), and to communicate the current sequence number to a joining endpoint (to properly initialize its replay list).
初期化において、RTPがかぎ管理で流れるので(その結果、かぎ管理はRTPの操作上のパラメタに依存を持っています)、共同利用できるSRTP実装SHOULDにSSRCを与えて、初期のRTP一連番号を与えるかもしれません。 そして、例えば、初期シーケンス番号が役に立つとき、かぎ管理でRTP一連番号を送るのがラッピング(同期問題を避ける)の近くで役に立つかもしれない、接合終点(適切に再生リストを初期化する)に現在の一連番号を伝えるために。
If the pre-defined transforms are used, SRTP allows sharing of the same master key between SRTP/SRTCP streams belonging to the same RTP session.
事前に定義された変換が使用されているなら、SRTPは、同じRTPセッションに属しながら、SRTP/SRTCPストリームの間で同じマスターキーを共有させます。
First, sharing between SRTP streams belonging to the same RTP session is secure if the design of the synchronization mechanism, i.e., the IV, avoids keystream re-use (the two-time pad, Section 9.1). This is taken care of by the fact that RTP provides for unique SSRCs for streams belonging to the same RTP session. See Section 9.1 for further discussion.
まず最初に、同期メカニズムのデザイン(すなわち、IV)がkeystream再使用(二度のパッド、セクション9.1)を避けるなら、同じRTPセッションに属するSRTPストリームを平等に割り当てるのは安全です。 RTPが同じRTPセッションに属するストリームのためにユニークなSSRCsに備えるという事実によってこれは世話をされます。 さらなる議論に関してセクション9.1を見てください。
Second, sharing between SRTP and the corresponding SRTCP is secure. The fact that an SRTP stream and its associated SRTCP stream both carry the same SSRC does not constitute a problem for the two-time pad due to the key derivation. Thus, SRTP and SRTCP corresponding to one RTP session MAY share master keys (as they do by default).
2番目に、SRTPと対応するSRTCPを平等に割り当てるのは安全です。 SRTPストリームとその関連SRTCPストリームがともに同じSSRCを運ぶという事実は主要な派生のため二度のパッドのために問題を構成しません。 したがって、1つのRTPセッションに対応するSRTPとSRTCPはマスターキーを共有するかもしれません(デフォルトでそうするように)。
Note that message authentication also has a dependency on SSRC uniqueness that is unrelated to the problem of keystream reuse: SRTP streams authenticated under the same key MUST have a distinct SSRC in order to identify the sender of the message. This requirement is needed because the SSRC is the cryptographically authenticated field
また、通報認証がkeystream再利用の問題に関係ないSSRCのユニークさに依存を持っていることに注意してください: 同じキーの下で認証されたSRTPストリームは、メッセージ送信者を特定するために異なったSSRCを持たなければなりません。 SSRCが暗号で認証された分野であるので、この要件が必要です。
Baugher, et al. Standards Track [Page 33] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[33ページ]。
used to distinguish between different SRTP streams. Were two streams to use identical SSRC values, then an adversary could substitute messages from one stream into the other without detection.
使用されて、異なったSRTPを見分けるのは流れます。2つのストリームが同じSSRC値を使用するなら、次に、敵は検出なしで1つのストリームからもう片方にメッセージを代入できるでしょうに。
SRTP/SRTCP MUST NOT share master keys under any other circumstances than the ones given above, i.e., between SRTP and its corresponding SRTCP, and, between streams belonging to the same RTP session.
そして、SRTP/SRTCP MUST NOTは、同じRTPセッションに属しながら、ストリームの間ですなわち上に与えられたものよりSRTPとその対応するSRTCPの間のいかなる他の状況でもマスターキーを共有します。
8.1. Re-keying
8.1. 再の合わせること
The recommended way for a particular key management system to provide re-key within SRTP is by associating a master key in a crypto context with an MKI.
特定のかぎ管理システムが中で再主要なSRTPを提供するお勧めの方法は暗号文脈でマスターキーをMKIに関連づけることです。
This provides for easy master key retrieval (see Scenarios in Section 11), but has the disadvantage of adding extra bits to each packet. As noted in Section 7.5, some wireless links do not cater for added bits, therefore SRTP also defines a more economic way of triggering re-keying, via use of <From, To>, which works in some specific, simple scenarios (see Section 8.1.1).
これには、簡単なマスターキー検索(セクション11でScenariosを見る)に備えますが、各パケットに付加的なビットを加える不都合があります。 セクション7.5に述べられるように、いくつかのワイヤレスのリンクは加えられたビットを満たしません、したがって、また、SRTPが<Fromの使用でTo>(いくつかの特定の、そして、簡単なシナリオで働いている)を再合わせながら、引き金となることの、より経済の方法を定義します(セクション8.1.1を見てください)。
SRTP senders SHALL count the amount of SRTP and SRTCP traffic being used for a master key and invoke key management to re-key if needed (Section 9.2). These interactions are defined by the key management interface to SRTP and are not defined by this protocol specification.
SRTP送付者SHALLはマスターキーに使用されるSRTPとSRTCPトラフィックの量を数えて、必要であるなら(セクション9.2)、再キーへかぎ管理を呼び出します。 これらの相互作用は、SRTPへのかぎ管理インタフェースによって定義されて、このプロトコル仕様で定義されません。
8.1.1. Use of the <From, To> for re-keying
8.1.1. <From、再の合わせるTo>の使用
In addition to the use of the MKI, SRTP defines another optional mechanism for master key retrieval, the <From, To>. The <From, To> specifies the range of SRTP indices (a pair of sequence number and ROC) within which a certain master key is valid, and is (when used) part of the crypto context. By looking at the 48-bit SRTP index of the current SRTP packet, the corresponding master key can be found by determining which From-To interval it belongs to. For SRTCP, the most recently observed/used SRTP index (which can be obtained from the cryptographic context) is used for this purpose, even though SRTCP has its own (31-bit) index (see caveat below).
MKIの使用に加えて、SRTPはマスターキー検索、<From、To>のために別の任意のメカニズムを定義します。 <From、To>はあるマスターキーが有効であり、暗号文脈の(使用されると)部分であるSRTPインデックスリスト(1組の一連番号とROC)の範囲を指定します。 現在のSRTPパケットの48ビットのSRTPインデックスを見ることによって、どれを決定するかによって対応するマスターキーを見つけることができる、From、-、それが属す間隔。 最も最近観測されたか、または使用されたSRTCPのために、SRTPインデックス(暗号の文脈から得ることができる)はこのために使用されます、SRTCPには、それ自身(31ビット)のインデックスがありますが(以下での警告を見てください)。
This method, compared to the MKI, has the advantage of identifying the master key and defining its lifetime without adding extra bits to each packet. This could be useful, as already noted, for some wireless links that do not cater for added bits. However, its use SHOULD be limited to specific, very simple scenarios. We recommend to limit its use when the RTP session is a simple unidirectional or bi-directional stream. This is because in case of multiple streams, it is difficult to trigger the re-key based on the <From, To> of a single RTP stream. For example, if several streams share a master
MKIと比較されたこのメソッドは各パケットに付加的なビットを加えないでマスターキーを特定して、生涯を定義する利点を持っています。 これはすでに言及したように加えられたビットを満たさないいくつかのワイヤレスのリンクの役に立つかもしれません。 しかしながら、それ、制限されていて、特定の、そして、非常に簡単なシナリオにSHOULDを使用してください。 私たちは、RTPセッションであるときに、使用を制限するのが、簡単な単方向か双方向のストリームであることを推薦します。 これは<に基づいて再主要なFromの引き金となるのが複数のストリームの場合に難しいからです、ただ一つのRTPストリームのTo>。 例えば、数個が流れるなら、マスターを共有してください。
Baugher, et al. Standards Track [Page 34] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[34ページ]。
key, there is no simple one-to-one correspondence between the index sequence space of a certain stream, and the index sequence space on which the <From, To> values are based. Consequently, when a master key is shared between streams, one of these streams MUST be designated by key management as the one whose index space defines the re-keying points. Also, the re-key triggering on SRTCP is based on the correspondent SRTP stream, i.e., when the SRTP stream changes the master key, so does the correspondent SRTCP. This becomes obviously more and more complex with multiple streams.
キー、あるストリームのインデックス系列スペースと、<From、To>値がどれであるかに基づくインデックス系列スペースの間には、簡単な1〜1つの通信がありません。 マスターキーがストリームの間で共有されるとき、その結果、かぎ管理はインデックススペースが再の合わせるポイントを定義するものとしてこれらのストリームの1つを指定しなければなりません。 また、SRTCPの再主要な引き金となることは通信員SRTPストリームに基づいています、すなわち、SRTPストリームがマスターキーを変えるので通信員SRTCPをすると。 これは複数のストリームで明らかにますます複雑になります。
The default values for the <From, To> are "from the first observed packet" and "until further notice". However, the maximum limit of SRTP/SRTCP packets that are sent under each given master/session key (Section 9.2) MUST NOT be exceeded.
<Fromのためのデフォルト値、To>は「最初の観測されたパケット」です、そして、「追って通知があるまで。」 しかしながら、それぞれの与えられたマスター/セッションキー(セクション9.2)の下で送られるSRTP/SRTCPパケットの最大の限界を超えてはいけません。
In case the <From, To> is used as key retrieval, then the MKI is not inserted in the packet (and its indicator in the crypto context is zero). However, using the MKI does not exclude using <From, To> key lifetime simultaneously. This can for instance be useful to signal at the sender side at which point in time an MKI is to be made active.
場合における<From、To>はキー検索として使用されて、次に、MKIはパケットに挿入されません(暗号文脈のインディケータはゼロです)。 しかしながら、<Fromを使用するToの>の主要な生涯をMKIを使用するのは同時に、除きません。 例えば、これは、MKIがアクティブにされることになっている時代の間、どのポイントで送付者側で合図するかために役に立つ場合があります。
8.2. Key Management parameters
8.2. Key Managementパラメタ
The table below lists all SRTP parameters that key management can supply. For reference, it also provides a summary of the default and mandatory-to-support values for an SRTP implementation as described in Section 5.
以下のテーブルはかぎ管理が提供できるすべてのSRTPパラメタをリストアップします。 また、参照のために、それはセクション5で説明されるようにデフォルトとサポートするために義務的な値の概要をSRTP実装に提供します。
Baugher, et al. Standards Track [Page 35] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[35ページ]。
Parameter Mandatory-to-support Default --------- -------------------- -------
パラメタのサポートするために義務的なデフォルト--------- -------------------- -------
SRTP and SRTCP encr transf. AES_CM, NULL AES_CM (Other possible values: AES_f8)
SRTPとSRTCP encr transf。 AES_cm、ヌルAES_cm(他の可能な値: AES_f8)
SRTP and SRTCP auth transf. HMAC-SHA1 HMAC-SHA1
SRTPとSRTCP auth transf。 HMAC-SHA1 HMAC-SHA1
SRTP and SRTCP auth params:
n_tag (tag length) 80 80
SRTP prefix_length 0 0
SRTPとSRTCP auth params: n_タグ(タグの長さ)80 80SRTP接頭語_長さ0 0
Key derivation PRF AES_CM AES_CM
主要な派生PRF AES_CM AES_CM
Key material params
(for each master key):
master key length 128 128
n_e (encr session key length) 128 128
n_a (auth session key length) 160 160
master salt key
length of the master salt 112 112
n_s (session salt key length) 112 112
key derivation rate 0 0
主要な材料params(各マスターキーのための): マスター塩の112 112n_s(セッション塩のキー長)112 112の主要な派生率0 0のマスターキー長さ128 128のn_e(encrセッションキー長)128 128n(authセッションキー長)160 160マスター塩のキー長
key lifetime
SRTP-packets-max-lifetime 2^48 2^48
SRTCP-packets-max-lifetime 2^31 2^31
from-to-lifetime <From, To>
MKI indicator 0 0
length of the MKI 0 0
value of the MKI
SRTCPパケットが生涯に最大限にしている生涯SRTPパケットが生涯に最大限にしている2^48 2^48 2^31 2^31を合わせてください、生涯、<From、MKI0 0の0 0の長さが評価するMKIのTo>MKIインディケータ
Crypto context index params:
SSRC value
ROC
SEQ
SRTCP Index
Transport address
Port number
暗号文脈インデックスparams: SSRC値のROC SEQ SRTCP Index TransportアドレスPort番号
Relation to other RTP profiles:
sender's order between FEC and SRTP FEC-SRTP FEC-SRTP
(see Section 10)
他のRTPとの関係は以下の輪郭を描きます。 FECとSRTP FEC-SRTP FEC-SRTPの間の送付者のオーダー(セクション10を見ます)
Baugher, et al. Standards Track [Page 36] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[36ページ]。
9. Security Considerations
9. セキュリティ問題
9.1. SSRC collision and two-time pad
9.1. SSRC衝突と二度のパッド
Any fixed keystream output, generated from the same key and index MUST only be used to encrypt once. Re-using such keystream (jokingly called a "two-time pad" system by cryptographers), can seriously compromise security. The NSA's VENONA project [C99] provides a historical example of such a compromise. It is REQUIRED that automatic key management be used for establishing and maintaining SRTP and SRTCP keying material; this requirement is to avoid keystream reuse, which is more likely to occur with manual key management. Furthermore, in SRTP, a "two-time pad" is avoided by requiring the key, or some other parameter of cryptographic significance, to be unique per RTP/RTCP stream and packet. The pre- defined SRTP transforms accomplish packet-uniqueness by including the packet index and stream-uniqueness by inclusion of the SSRC.
いずれも同じキーから生成されたkeystream出力を固定しました、そして、インデックスは一度単に暗号化するのにおいて使用されているに違いありません。 そのようなkeystream(暗号使用者によってふざけて「二度のパッド」システムと呼ばれる)を再使用して、真剣にセキュリティに感染することができます。 NSAのVENONAプロジェクト[C99]はそのような感染の歴史的な例を提供します。 自動かぎ管理が材料を合わせるSRTPとSRTCPを設立して、維持するのに使用されるのは、REQUIREDです。 この要件はkeystream再利用を避けることです。(それは、手動のかぎ管理で、より起こりそうです)。 その上、SRTPでは、「二度のパッド」は、RTP/RTCPストリームとパケット単位で特有になるようにキー、または暗号の意味のある他のパラメタを必要とすることによって、避けられます。 あらかじめ定義されたSRTP変換は、SSRCの包含でパケットインデックスとストリームユニークさを含んでいることによって、パケットユニークさを達成します。
The pre-defined transforms (AES-CM and AES-f8) allow master keys to be shared across streams belonging to the same RTP session by the inclusion of the SSRC in the IV. A master key MUST NOT be shared among different RTP sessions.
事前に定義された変換(AES-CMとAES-f8)は、IVでのSSRCの包含で同じRTPセッションに属しながら小川の向こう側に共有されるためにマスターキーを許容します。 異なったRTPセッションのときにマスターキーを共有してはいけません。
Thus, the SSRC MUST be unique between all the RTP streams within the same RTP session that share the same master key. RTP itself provides an algorithm for detecting SSRC collisions within the same RTP session. Thus, temporary collisions could lead to temporary two-time pad, in the unfortunate event that SSRCs collide at a point in time when the streams also have identical sequence numbers (occurring with probability roughly 2^(-48)). Therefore, the key management SHOULD take care of avoiding such SSRC collisions by including the SSRCs to be used in the session as negotiation parameters, proactively assuring their uniqueness. This is a strong requirements in scenarios where for example, there are multiple senders that can start to transmit simultaneously, before SSRC collision are detected at the RTP level.
その結果、SSRC MUST、同じRTPセッション中の同じマスターキーを共有するすべてのRTPストリームの間でユニークであってください。 RTP自身は同じRTPセッション中にSSRC衝突を検出するためのアルゴリズムを提供します。 その結果、一時的な衝突は一時的な二度のパッドに通じるかもしれなくて、不幸なイベントでは、そのSSRCsは時間内にのまたストリームには同じ一連番号があるポイントで衝突します。(確率およそ2^(-48))で、起こります。 したがって、かぎ管理SHOULDは交渉パラメタのようなセッションのときに使用されるためにSSRCsを含んでいるのによるSSRC衝突を避けるように注意します、それらのユニークさを予測して保証して。 これは例えば同時に伝わり始めることができる複数の送付者がいるシナリオの強い要件です、SSRC衝突がRTPレベルで検出される前に。
Note also that even with distinct SSRCs, extensive use of the same key might improve chances of probabilistic collision and time- memory-tradeoff attacks succeeding.
また、異なったSSRCsがあっても、同じキーの大規模な使用が確率的な衝突の機会を改良するかもしれなくて、時間メモリ見返りが成功を攻撃することに注意してください。
As described, master keys MAY be shared between streams belonging to the same RTP session, but it is RECOMMENDED that each SSRC have its own master key. When master keys are shared among SSRC participants and SSRCs are managed by a key management module as recommended above, the RECOMMENDED policy for an SSRC collision error is for the participant to leave the SRTP session as it is a sign of malfunction.
説明されていて、マスターキーが同じRTPセッションに属するストリームの間で共有されるかもしれませんが、各SSRCにはそれ自身のマスターキーがあるのが、RECOMMENDEDであるので。 マスターキーがSSRC関係者の中で共有されて、SSRCsが上で推薦されるようにかぎ管理モジュールで管理されるとき、SSRC衝突誤りのためのRECOMMENDED方針は関係者がそれが不調のサインであるのでSRTPセッションを残すことです。
Baugher, et al. Standards Track [Page 37] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[37ページ]。
9.2. Key Usage
9.2. 主要な用法
The effective key size is determined (upper bounded) by the size of the master key and, for encryption, the size of the salting key. Any additive stream cipher is vulnerable to attacks that use statistical knowledge about the plaintext source to enable key collision and time-memory tradeoff attacks [MF00] [H80] [BS00]. These attacks take advantage of commonalities among plaintexts, and provide a way for a cryptanalyst to amortize the computational effort of decryption over many keys, or over many bytes of output, thus reducing the effective key size of the cipher. A detailed analysis of these attacks and their applicability to the encryption of Internet traffic is provided in [MF00]. In summary, the effective key size of SRTP when used in a security system in which m distinct keys are used, is equal to the key size of the cipher less the logarithm (base two) of m. Protection against such attacks can be provided simply by increasing the size of the keys used, which here can be accomplished by the use of the salting key. Note that the salting key MUST be random but MAY be public. A salt size of (the suggested) size 112 bits protects against attacks in scenarios where at most 2^112 keys are in use. This is sufficient for all practical purposes.
マスターキーのサイズと暗号化のための塩味を付けキーのサイズに従って、有効な主要なサイズは決定しています(より上に、バウンドしています)。 どんな付加的なストリーム暗号も主要な衝突を可能にするのに平文ソースに関する統計的な知識を使用する攻撃と時間メモリ見返り攻撃[MF00][H80][BS00]に被害を受け易いです。 これらの攻撃は、平文の中で共通点を利用して、暗号解読者が多くのキーの上、または、多くのバイトの出力の上で復号化の計算量を清算する方法を提供します、その結果、暗号の有効な主要なサイズを減少させます。 インターネットトラフィックの暗号化へのこれらの攻撃と彼らの適用性の詳細に渡る分析を[MF00]に提供します。 どのm異なったキーでセキュリティシステムで使用されるか場合、SRTPの有効な主要なサイズは、概要において、使用されていて、それほど暗号の主要なサイズと等しくはありません。mの対数(ベースtwo)。 単に塩味を付けキーの使用で達成できる使用されるキーのサイズを増強することによって、そのような攻撃に対する保護を提供できます。 塩味を付けキーが無作為でなければなりませんが、公共であるかもしれないことに注意してください。 112ビットのサイズが守る(示唆)の塩のサイズはほとんどの2^では、112個のキーが使用中であるシナリオで攻撃されます。 これは実際上は十分です。
Implementations SHOULD use keys that are as large as possible. Please note that in many cases increasing the key size of a cipher does not affect the throughput of that cipher.
実装SHOULDはできるだけ大きいキーを使用します。 多くの場合、暗号の主要なサイズを増強するのはその暗号に関するスループットに影響しません。
The use of the SRTP and SRTCP indices in the pre-defined transforms fixes the maximum number of packets that can be secured with the same key. This limit is fixed to 2^48 SRTP packets for an SRTP stream, and 2^31 SRTCP packets, when SRTP and SRTCP are considered independently. Due to for example re-keying, reaching this limit may or may not coincide with wrapping of the indices, and thus the sender MUST keep packet counts. However, when the session keys for related SRTP and SRTCP streams are derived from the same master key (the default behavior, Section 4.3), the upper bound that has to be considered is in practice the minimum of the two quantities. That is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s) (previously stored and used keys MUST NOT be used again), or the session MUST be terminated. If a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not updated the master or session key prior to sending 2^48 SRTP (or 2^31 SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to the security policy of the RTCP sender how to behave, e.g., whether an RTCP BYE-packet should be sent and/or if the event should be logged.
事前に定義された変換におけるSRTPとSRTCPインデックスリストの使用は同じキーで機密保護することができるパケットの最大数を固定します。 この限界はSRTPストリームのための2^48のSRTPパケット、および2^31のSRTCPパケットに固定されています、SRTPとSRTCPが独自に考えられるとき。 例えば、再の合わせるため、この限界に達すると、インデックスリストのラッピングは同時に起こるかもしれません、そして、その結果、送付者はパケットカウントを保たなければなりません。 しかしながら、関連するSRTPとSRTCPストリームのためのセッションキーが引き出されるとき、同じマスターキー(デフォルトの振舞い、セクション4.3)、考えられなければならない上限から、実際には、2つの量の最小限は来ています。 すなわち、2^48のSRTPパケットか2^31のSRTCPパケットが同じキーで機密保護されたとき(どれが以前起こっても)、かぎ管理が新しいマスターキーを提供するために召集されなければなりませんか(再び以前、保存されて、中古のキーを使用してはいけません)、またはセッションを終えなければなりません。 または、RTCPの送付者が、SRTP(または、SRTCP)の送付者が2^48SRTPを送る前に主要なマスターかセッションをアップデートしていないと発見する、(2 ^31SRTCP) 同じSRTP(SRTCP)に属すパケットが流れて、RTCP送付者の安全保障政策まで、例えばどう振る舞うかがRTCP BYE-パケットを送るべきであり、イベントであるなら登録されるべきであるということです。
Baugher, et al. Standards Track [Page 38] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[38ページ]。
Note: in most typical applications (assuming at least one RTCP packet for every 128,000 RTP packets), it will be the SRTCP index that first reaches the upper limit, although the time until this occurs is very long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is enough to secure approximately 4 months of communication.
以下に注意してください。 ほとんどの主用途(12万8000のRTPパケットあたり少なくとも1つのRTCPパケットを仮定する)では、SRTCPインデックスになるでしょう上限に最初に達する、これが起こるまで、時間は非常に長いのですが: 200SRTCPパケット/秒のときにさえ、SRTCPの2^31インデックススペースは、およそ4カ月のコミュニケーションを保証するために十分です。
Note that if the master key is to be shared between SRTP streams within the same RTP session (Section 9.1), although the above bounds are on a per stream (i.e., per SSRC) basis, the sender MUST base re- key decision on the stream whose sequence number space is the first to be exhausted.
上の領域がストリーム(すなわち、SSRCあたりの)基礎あたりのaにありますが、マスターキーが同じRTPセッション(セクション9.1)中にSRTPストリームの間で共有されるつもりであるなら送付者の再重要な決定が一連番号スペースが消耗するべき第1であるストリームに基づいていなければならないことに注意してください。
Key derivation limits the amount of plaintext that is encrypted with a fixed session key, and made available to an attacker for analysis, but key derivation does not extend the master key's lifetime. To see this, simply consider our requirements to avoid two-time pad: two distinct packets MUST either be processed with distinct IVs, or with distinct session keys, and both the distinctness of IV and of the session keys are (for the pre-defined transforms) dependent on the distinctness of the packet indices.
主要な派生は固定セッションキーで暗号化されて、分析のために攻撃者にとって利用可能にされる平文の量を制限しますが、主要な派生はマスターキーの生涯を広げていません。 これを見るには、単に、二度のパッドを避けるという私たちの要件を考えてください: 2つの異なったパケットが、異なったIVs、または異なったセッションキー、および両方によるIVの明暸さで処理しなければならなくて、パケットインデックスリストの明暸さのセッションキーの(事前に定義された変換のための)扶養家族です。
Note that with the key derivation, the effective key size is at most that of the master key, even if the derived session key is considerably longer. With the pre-defined authentication transform, the session authentication key is 160 bits, but the master key by default is only 128 bits. This design choice was made to comply with certain recommendations in [RFC2104] so that an existing HMAC implementation can be plugged into SRTP without problems. Since the default tag size is 80 bits, it is, for the applications in mind, also considered acceptable from security point of view. Users having concerns about this are RECOMMENDED to instead use a 192 bit master key in the key derivation. It was, however, chosen not to mandate 192-bit keys since existing AES implementations to be used in the key-derivation may not always support key-lengths other than 128 bits. Since AES is not defined (or properly analyzed) for use with 160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes are used to pad shorter keys to 192 or 256 bits.
主要な派生で、有効な主要なサイズが高々マスターキーのものであることに注意してください、派生しているセッションキーがかなり長くても。 事前に定義された認証変換で、セッション認証キーは160ビットですが、マスターキーはデフォルトで128ビットにすぎません。 問題なしで既存のHMAC実装にSRTPのプラグを差し込まれることができるように[RFC2104]で、ある推薦に従うのをこのデザイン選択をしました。デフォルトタグサイズが80ビットであるので、それは、アプリケーションのために念頭にあって、また、セキュリティ観点から許容できた状態で考えます。 これに関する心配を持っているユーザは代わりに主要な派生に192ビットのマスターキーを使用するRECOMMENDEDです。 主要な派生に使用されるべき既存のAES実装がいつも128ビット以外のキー長をサポートするかもしれないというわけではないので、しかしながら、それは192ビットのキーを強制しないように選ばれました。 AESが使用のために160ビットのキーで定義されないので(または、適切に分析されます)、臨時のキーをそっと歩く体系が192ビットか256ビットの、より短いキーを水増しするのに使用されるのは、NOT RECOMMENDEDです。
9.3. Confidentiality of the RTP Payload
9.3. RTP有効搭載量の秘密性
SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e., ciphers able to efficiently seek to arbitrary locations in their keystream (so that the encryption or decryption of one packet does not depend on preceding packets). By using seekable stream ciphers, SRTP avoids the denial of service attacks that are possible on stream ciphers that lack this property. It is important to be aware that, as with any stream cipher, the exact length of the payload is revealed by the encryption. This means that it may be possible to
SRTPの事前に定義された暗号は"「探-可能」"ストリーム暗号(すなわち、効率的にそれらのkeystream(1つのパケットの暗号化か復号化がパケットに先行するのによらないように)の任意の位置に探すことができる暗号)です。 「探-可能」ストリーム暗号を使用することによって、SRTPはこの特性を欠いているストリーム暗号で可能なサービス不能攻撃を避けます。 ペイロードの正確な長さがどんなストリーム暗号のようにも暗号化で明らかにされるのを意識しているのは重要です。 それが可能であるかもしれないこの手段
Baugher, et al. Standards Track [Page 39] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[39ページ]。
deduce certain "formatting bits" of the payload, as the length of the codec output might vary due to certain parameter settings etc. This, in turn, implies that the corresponding bit of the keystream can be deduced. However, if the stream cipher is secure (counter mode and f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]), knowledge of a few bits of the keystream will not aid an attacker in predicting subsequent keystream bits. Thus, the payload length (and information deducible from this) will leak, but nothing else.
ペイロードのある「形式ビット」を推論してください、コーデック出力の長さが設定のあるパラメタなどのため異なるかもしれないとき これは、keystreamの対応するビットを推論できるのを順番に含意します。 ストリーム暗号は安全です。しかしながら、(カウンタモードとf8による、ある仮定で[BDJR][KSYH][IK)を証明可能に機密保護してください、keystreamの数ビットに関する知識がその後のkeystreamビットを予測する際に攻撃者を支援しないということです。 したがって、ペイロード長(そして、これから推定可能な情報)はしかし、漏出、他に何もがそうしないでしょう。
As some RTP packet could contain highly predictable data, e.g., SID, it is important to use a cipher designed to resist known plaintext attacks (which is the current practice).
あるRTPパケットが非常に予測できるデータ、例えばSIDを含むかもしれないので、知られている平文攻撃に抵抗するように設計された暗号(現在の習慣である)を使用するのは重要です。
9.4. Confidentiality of the RTP Header
9.4. RTPヘッダーの秘密性
In SRTP, RTP headers are sent in the clear to allow for header compression. This means that data such as payload type, synchronization source identifier, and timestamp are available to an eavesdropper. Moreover, since RTP allows for future extensions of headers, we cannot foresee what kind of possibly sensitive information might also be "leaked".
SRTPでは、ヘッダー圧縮を考慮するために明確でRTPヘッダーを送ります。 これは、立ち聞きする者にとって、ペイロードタイプや、同期ソース識別子や、タイムスタンプなどのデータが利用可能であることを意味します。 そのうえ、RTPがヘッダーの今後の拡大を考慮するので、私たちは、また、どういうことによると機密の情報が「漏らされるかもしれないか」を見通すことができません。
SRTP is a low-cost method, which allows header compression to reduce bandwidth. It is up to the endpoints' policies to decide about the security protocol to employ. If one really needs to protect headers, and is allowed to do so by the surrounding environment, then one should also look at alternatives, e.g., IPsec [RFC2401].
SRTPは安価のメソッドです。(ヘッダー圧縮はそのメソッドで帯域幅を減少させることができます)。 使うセキュリティプロトコルに関して決めるのは終点の方針まで達しています。 また、1つが本当にヘッダーを保護するのが必要であり、周囲の環境でそうすることができるなら、代替手段(例えば、IPsec[RFC2401])を見るべきです。
9.5. Integrity of the RTP payload and header
9.5. RTPペイロードとヘッダーの保全
SRTP messages are subject to attacks on their integrity and source identification, and these risks are discussed in Section 9.5.1. To protect against these attacks, each SRTP stream SHOULD be protected by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key, or a message authentication code with equivalent strength. Secure RTP SHOULD NOT be used without message authentication, except under the circumstances described in this section. It is important to note that encryption algorithms, including AES Counter Mode and f8, do not provide message authentication. SRTCP MUST NOT be used with weak (or NULL) authentication.
メッセージを条件としているSRTPが彼らの保全とソース識別のときに攻撃します、そして、セクション9.5.1でこれらの危険について議論します。 これらの攻撃、それぞれのSRTPストリームSHOULDから守るには、80ビットの出力タグと160ビットのキーか、同等な強さがあるメッセージ確認コードでHMAC-SHA1[RFC2104]によって保護されてください。 通報認証なしで使用されて、状況を除いて、このセクションで説明されて、RTP SHOULD NOTを固定してください。 AES Counter Modeとf8を含む暗号化アルゴリズムが通報認証を提供しないことに注意するのは重要です。 SRTCP MUST NOT、弱い(または、NULL)認証と共に使用されてください。
SRTP MAY be used with weak authentication (e.g., a 32-bit authentication tag), or with no authentication (the NULL authentication algorithm). These options allow SRTP to be used to provide confidentiality in situations where
SRTP MAY、弱い認証(例えば、32ビットの認証タグ)も、または認証(NULL認証アルゴリズム)なしで使用されてください。 これらのオプションは、SRTPが状況における秘密性にどこを提供するかに使用されるのを許容します。
* weak or null authentication is an acceptable security risk, and
* it is impractical to provide strong message authentication.
* *弱いかヌルの認証は許容できるセキュリティリスクです、そして、強い通報認証を提供するのは非実用的です。
Baugher, et al. Standards Track [Page 40] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[40ページ]。
These conditions are described below and in Section 7.5. Note that both conditions MUST hold in order for weak or null authentication to be used. The risks associated with exercising the weak or null authentication options need to be considered by a security audit prior to their use for a particular application or environment given the risks, which are discussed in Section 9.5.1.
これらの状態はセクションの下と、そして、セクション7.5で説明されます。 両方の状態が弱いかヌルの認証が使用されるために成立しなければならないことに注意してください。 リスクは彼らの特定用途か環境の使用の前にセキュリティ監査によって考えられるべき弱いかヌルの認証オプションの必要性を運動させると与える危険を関連づけました。(セクション9.5.1で危険について議論します)。
Weak authentication is acceptable when the RTP application is such that the effect of a small fraction of successful forgeries is negligible. If the application is stateless, then the effect of a single forged RTP packet is limited to the decoding of that particular packet. Under this condition, the size of the authentication tag MUST ensure that only a negligible fraction of the packets passed to the RTP application by the SRTP receiver can be forgeries. This fraction is negligible when an adversary, if given control of the forged packets, is not able to make a significant impact on the output of the RTP application (see the example of Section 7.5).
うまくいっている偽造のわずかな部分の効果がRTPアプリケーションがそのようなものであるので取るにたらないときに、弱い認証は許容できます。 アプリケーションが状態がないなら、単一の偽造RTPパケットの効果はその特定のパケットの解読に制限されます。 この条件のもとでは、認証タグのサイズは、SRTP受信機によってRTPアプリケーションに通過されたパケットの取るにたらない唯一の部分が偽造であるかもしれないことを確実にしなければなりません。 偽造パケットの支配力を与えるなら敵がRTPアプリケーションの出力のときに重要な影響を与えることができないとき(セクション7.5に関する例を見てください)、この断片は取るにたらないです。
Weak or null authentication MAY be acceptable when it is unlikely that an adversary can modify ciphertext so that it decrypts to an intelligible value. One important case is when it is difficult for an adversary to acquire the RTP plaintext data, since for many codecs, an adversary that does not know the input signal cannot manipulate the output signal in a controlled way. In many cases it may be difficult for the adversary to determine the actual value of the plaintext. For example, a hidden snooping device might be required in order to know a live audio or video signal. The adversary's signal must have a quality equivalent to or greater than that of the signal under attack, since otherwise the adversary would not have enough information to encode that signal with the codec used by the victim. Plaintext prediction may also be especially difficult for an interactive application such as a telephone call.
敵が暗号文を変更できるのが、ありそうもないときに、弱いかヌルの認証は許容できるかもしれません。それが明瞭な値に解読するそう。 1回の重要な例が敵がRTP平文データを取得するのが、難しい時です、入力信号を知らない敵が多くのコーデックに関して制御方法で出力信号を操作できないので。 多くの場合、敵が平文の実価を決定するのは、難しいかもしれません。 例えば、隠された詮索デバイスが、生の音声かビデオ信号を知るのに必要であるかもしれません。 敵の信号で品質は信号で、攻撃で同等であるかそれよりすばらしくならなければなりません、敵には、さもなければ、コーデックが犠牲者によって使用されている状態でその信号をコード化できるくらいの情報がないでしょう、したがって。 また、通話などの対話型アプリケーションには、平文予測も特に難しいかもしれません。
Weak or null authentication MUST NOT be used when the RTP application makes data forwarding or access control decisions based on the RTP data. In such a case, an attacker may be able to subvert confidentiality by causing the receiver to forward data to an attacker. See Section 3 of [B96] for a real-life example of such attacks.
RTPアプリケーションがデータを推進かRTPデータに基づくアクセス制御決定にすると、弱いかヌルの認証を使用してはいけません。 このような場合には、受信機がデータを攻撃者に転送することを引き起こすことによって、攻撃者は秘密性を打倒できるかもしれません。 そのような攻撃の現実の例に関して[B96]のセクション3を見てください。
Null authentication MUST NOT be used when a replay attack, in which an adversary stores packets then replays them later in the session, could have a non-negligible impact on the receiver. An example of a successful replay attack is the storing of the output of a surveillance camera for a period of time, later followed by the
(敵は反射攻撃でパケットを保存します)。反射攻撃であるときに、ヌル認証を使用してはいけなくて、次に、セッションのときに、より遅く、それらを再演して、受信機の上に非取るにたらない影響力を持つことができました。うまくいっている反射攻撃に関する例はしばらく、後で続かれた監視カメラの出力の保存です。
Baugher, et al. Standards Track [Page 41] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[41ページ]。
injection of that output to the monitoring station to avoid surveillance. Encryption does not protect against this attack, and non-null authentication is REQUIRED in order to defeat it.
監視を避けるためにモニタリングステーションに出力されたその注射。 暗号化はこの攻撃から守りません、そして、非ヌル認証は、それを破るREQUIREDです。
If existential message forgery is an issue, i.e., when the accuracy of the received data is of non-negligible importance, null authentication MUST NOT be used.
すなわち、受信データの精度が非取るにたらなく重要であるときに、実存的なメッセージ偽造が問題であるなら、ヌル認証を使用してはいけません。
9.5.1. Risks of Weak or Null Message Authentication
9.5.1. 弱いかヌルの通報認証のリスク
During a security audit considering the use of weak or null authentication, it is important to keep in mind the following attacks which are possible when no message authentication algorithm is used.
セキュリティ監査の間、弱いかヌルの認証の使用を考える場合、以下のどんな通報認証アルゴリズムも使用されていないとき可能な攻撃を覚えておくのは重要です。
An attacker who cannot predict the plaintext is still always able to modify the message sent between the sender and the receiver so that it decrypts to a random plaintext value, or to send a stream of bogus packets to the receiver that will decrypt to random plaintext values. This attack is essentially a denial of service attack, though in the absence of message authentication, the RTP application will have inputs that are bit-wise correlated with the true value. Some multimedia codecs and common operating systems will crash when such data are accepted as valid video data. This denial of service attack may be a much larger threat than that due to an attacker dropping, delaying, or re-ordering packets.
平文を予測できない攻撃者は、それが無作為の平文値に解読するそのように送付者と受信機の間に送られたメッセージを変更するか、またはまだいつもそれが無作為の平文値に解読する受信機ににせのパケットの流れを送ることができます。 この攻撃は本質的にはサービス不能攻撃です、RTPアプリケーションには、通報認証がないとき真の値で噛み付き的に関連する入力があるでしょうが。 そのようなデータが有効なビデオ・データとして認められるとき、いくつかのマルチメディアコーデックと共同運用システムがダウンするでしょう。 このサービス不能攻撃はパケットを下げるか、遅らせるか、または再注文している攻撃者によるそれよりはるかに大きい脅威であるかもしれません。
An attacker who cannot predict the plaintext can still replay a previous message with certainty that the receiver will accept it. Applications with stateless codecs might be robust against this type of attack, but for other, more complex applications these attacks may be far more grave.
平文を予測できない攻撃者は受信機がそれを受け入れるという確実性でまだ前のメッセージを再演できます。 状態がないコーデックがあるアプリケーションはこのタイプの攻撃に対して体力を要するかもしれませんが、他の、そして、より複雑なアプリケーションにおいて、これらの攻撃ははるかに荘重であるかもしれません。
An attacker who can predict the plaintext can modify the ciphertext so that it will decrypt to any value of her choosing. With an additive stream cipher, an attacker will always be able to change individual bits.
平文を予測できる攻撃者は、彼女のどんな値にも選ぶことを解読するように、暗号文を変更できます。 付加的なストリーム暗号で、攻撃者はいつも個々のビットを変えることができるでしょう。
An attacker may be able to subvert confidentiality due to the lack of authentication when a data forwarding or access control decision is made on decrypted but unauthenticated plaintext. This is because the receiver may be fooled into forwarding data to an attacker, leading to an indirect breach of confidentiality (see Section 3 of [B96]). This is because data-forwarding decisions are made on the decrypted plaintext; information in the plaintext will determine to what subnet (or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode (respectively, transport mode). When Secure RTP is used without
認証の不足のため、解読されましたが、非認証された平文でデータ推進かアクセス制御決定をするとき、攻撃者は秘密性を打倒できるかもしれません。 これは受信機がデータを攻撃者に転送するようにだまされるかもしれないからです、秘密性の間接的な不履行に通じて([B96]のセクション3を見てください)。 これは解読された平文でデータを転送する決定をするからです。 平文における情報は、平文が超能力[RFC2401]トンネルモードでどんなサブネット(処理する)に送られるかを(それぞれ、モードを輸送してください)決定するでしょう。 時Secure RTPが使用される
Baugher, et al. Standards Track [Page 42] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[42ページ]。
message authentication, it should be verified that the application does not make data forwarding or access control decisions based on the decrypted plaintext.
通報認証、アプリケーションがデータを推進か解読された平文に基づくアクセス制御決定にしないことが確かめられるべきです。
Some cipher modes of operation that require padding, e.g., standard cipher block chaining (CBC) are very sensitive to attacks on confidentiality if certain padding types are used in the absence of integrity. The attack [V02] shows that this is indeed the case for the standard RTP padding as discussed in reference to Figure 1, when used together with CBC mode. Later transform additions to SRTP MUST therefore carefully consider the risk of using this padding without proper integrity protection.
ある詰め物タイプが保全がないとき使用されるなら、そっと歩くのを必要とするいくつかの暗号運転モード、例えば、標準の暗号ブロック連鎖(CBC)は秘密性に対する攻撃に非常に敏感です。 攻撃[V02]は、本当に、これが図1に関して議論するようにそっと歩く標準のRTPのためのそうであることを示します、CBCモードと共に使用されると。 その後、追加をSRTP MUSTに変えてください、そして、したがって、慎重に適切な保全保護なしでこの詰め物を使用する危険を考えてください。
9.5.2. Implicit Header Authentication
9.5.2. 暗黙のヘッダー認証
The IV formation of the f8-mode gives implicit authentication (IHA) of the RTP header, even when message authentication is not used. When IHA is used, an attacker that modifies the value of the RTP header will cause the decryption process at the receiver to produce random plaintext values. While this protection is not equivalent to message authentication, it may be useful for some applications.
f8-モードのIV構成はRTPヘッダーの暗黙の認証(IHA)を与えます、通報認証が使用されてさえいないとき。 IHAが使用されているとき、RTPヘッダーの値を変更する攻撃者は受信機の復号化プロセスに無作為の平文値を生産させるでしょう。 この保護が通報認証に同等でない間、それはいくつかのアプリケーションの役に立つかもしれません。
10. Interaction with Forward Error Correction mechanisms
10. Forward Error Correctionメカニズムとの相互作用
The default processing when using Forward Error Correction (e.g., RFC 2733) processing with SRTP SHALL be to perform FEC processing prior to SRTP processing on the sender side and to perform SRTP processing prior to FEC processing on the receiver side. Any change to this ordering (reversing it, or, placing FEC between SRTP encryption and SRTP authentication) SHALL be signaled out of band.
デフォルト処理は、SRTP SHALLとのForward Error Correction(例えば、RFC2733)処理を使用するとき、SRTP処理の前に送付者側にFEC処理を実行して、FEC処理の前に受信機側にSRTP処理を実行することです。 いずれもこの注文(または、SRTP暗号化とSRTP認証の間にFECを置きながら、それを逆にする)SHALLに変化します。バンドから、合図されます。
11. Scenarios
11. シナリオ
SRTP can be used as security protocol for the RTP/RTCP traffic in many different scenarios. SRTP has a number of configuration options, in particular regarding key usage, and can have impact on the total performance of the application according to the way it is used. Hence, the use of SRTP is dependent on the kind of scenario and application it is used with. In the following, we briefly illustrate some use cases for SRTP, and give some guidelines for recommended setting of its options.
セキュリティが多くの異なったシナリオのRTP/RTCPトラフィックのために議定書を作るとき、SRTPを使用できます。 SRTPは特に主要な用法に関する多くの設定オプションを持っていて、それが使用されている方法によると、アプリケーションの総性能に影響力を持つことができます。 したがって、SRTPの使用はそれが使用されるシナリオとアプリケーションの種類に依存しています。 以下では、私たちは、簡潔に使用がSRTPのためにケースに入れるいくつかを例証して、オプションのお勧めの設定のためのいくつかのガイドラインを与えます。
11.1. Unicast
11.1. ユニキャスト
A typical example would be a voice call or video-on-demand application.
典型的な例は、音声通話かビデオ・オン・デマンドアプリケーションでしょう。
Baugher, et al. Standards Track [Page 43] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[43ページ]。
Consider one bi-directional RTP stream, as one RTP session. It is possible for the two parties to share the same master key in the two directions according to the principles of Section 9.1. The first round of the key derivation splits the master key into any or all of the following session keys (according to the provided security functions):
1つの双方向のRTPストリームを1つのRTPセッションと考えてください。 セクション9.1の原則によると、2回のパーティーが2つの方向と同じマスターキーを共有するのは、可能です。 主要な派生の最初のラウンドはマスターキーを以下のセッションキー(提供されたセキュリティ機能に従って)のいずれかすべてに分けます:
SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
SRTP_encr_キー、SRTP_auth_キー、SRTCP_encr_キー、およびSRTCP_auth主要です。
(For simplicity, we omit discussion of the salts, which are also derived.) In this scenario, it will in most cases suffice to have a single master key with the default lifetime. This guarantees sufficiently long lifetime of the keys and a minimum set of keys in place for most practical purposes. Also, in this case RTCP protection can be applied smoothly. Under these assumptions, use of the MKI can be omitted. As the key-derivation in combination with large difference in the packet rate in the respective directions may require simultaneous storage of several session keys, if storage is an issue, we recommended to use low-rate key derivation.
(簡単さのために、私たちはまた、誘導される塩の議論を省略します。) 多くの場合、このシナリオでは、それは、デフォルトがある単一のマスターキーを持つために十分でしょう。生涯。 これはキーの十分長い生涯とほとんどの実用的な目的のために適所にあるキーの最小のセットを保証します。 また、この場合、スムーズにRTCP保護を適用できます。 これらの仮定で、MKIの使用を省略できます。 パケットの大きな違いと組み合わせた主要な派生として、それぞれの方向へのレートは、ストレージが問題であるなら数個のセッションキーの同時のストレージを必要として、主要な派生を使用に安値で評定するかもしれません私たちが、勧めた。
The same considerations can be extended to the unicast scenario with multiple RTP sessions, where each session would have a distinct master key.
同じ問題をユニキャストシナリオに複数のRTPセッションで広げることができます。そこでは、各セッションが、異なったマスターキーを持っているでしょう。
11.2. Multicast (one sender)
11.2. マルチキャスト(1人の送付者)
Just as with (unprotected) RTP, a scalability issue arises in big groups due to the possibly very large amount of SRTCP Receiver Reports that the sender might need to process. In SRTP, the sender may have to keep state (the cryptographic context) for each receiver, or more precisely, for the SRTCP used to protect Receiver Reports. The overhead increases proportionally to the size of the group. In particular, re-keying requires special concern, see below.
送付者が処理する必要があるかもしれないSRTCP Receiver Reportsのことによると非常に多量のため、ちょうど(保護のない)のRTPのように、スケーラビリティ問題は大石で起こります。 SRTPでは、送付者は、状態が各受信機、または、よりまさにReceiver Reportsを保護するのに使用されるSRTCPのための(暗号の文脈)であると保たなければならないかもしれません。 オーバーヘッドはグループのサイズに比例して上がります。 特に、再の合わせるのは特別な関心を必要として、以下を見てください。
Consider first a small group of receivers. There are a few possible setups with the distribution of master keys among the receivers. Given a single RTP session, one possibility is that the receivers share the same master key as per Section 9.1 to secure all their respective RTCP traffic. This shared master key could then be the same one used by the sender to protect its outbound SRTP traffic. Alternatively, it could be a master key shared only among the receivers and used solely for their SRTCP traffic. Both alternatives require the receivers to trust each other.
1番目が受信機の小さいグループであると考えてください。 受信機の中にマスターキーの分配によるいくつかの可能なセットアップがあります。 ただ一つのRTPセッションを考えて、1つの可能性は受信機がセクション9.1に従ってそれらのすべてのそれぞれのRTCPトラフィックを保証するために同じマスターキーを共有するということです。 そしてときにこの共有されたマスターキーは外国行きのSRTPトラフィックを保護するのに送付者によって使用された同じ1つであるかもしれません。 あるいはまた、それは受信機だけの中で共有されて、唯一それらのSRTCPトラフィックに使用されるマスターキーであるかもしれません。 両方の代替手段は、互いを信じるために受信機を必要とします。
Considering SRTCP and key storage, it is recommended to use low-rate (or zero) key_derivation (except the mandatory initial one), so that the sender does not need to store too many session keys (each SRTCP stream might otherwise have a different session key at a given point
SRTCPと主要なストレージを考える場合、低率(または、ゼロ)の主要な_派生(義務的な初期のものを除いた)を使用するのはお勧めです、送付者があまりに多くのセッションキーを保存する必要はないように(そうでなければ、それぞれのSRTCPストリームが与えられたポイントで主要な異なったセッションを過すかもしれません。
Baugher, et al. Standards Track [Page 44] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[44ページ]。
in time, as the SRTCP sources send at different times). Thus, in case key derivation is wanted for SRTP, the cryptographic context for SRTP can be kept separate from the SRTCP crypto context, so that it is possible to have a key_derivation_rate of 0 for SRTCP and a non- zero value for SRTP.
中、SRTCPソースがいろいろな時間に発信するので時間 したがって、主要な派生がSRTPのために欲しいといけないので、SRTCP暗号文脈から別々にSRTPのための暗号の文脈を保つことができます、SRTCPのための0非ゼロの主要な_派生_レートにSRTPのための値を持っているのが可能であるように。
Use of the MKI for re-keying is RECOMMENDED for most applications (see Section 8.1).
MKIの再の合わせることの使用はほとんどのアプリケーションのためのRECOMMENDED(セクション8.1を見る)です。
If there are more than one SRTP/SRTCP stream (within the same RTP session) that share the master key, the upper limit of 2^48 SRTP packets / 2^31 SRTCP packets means that, before one of the streams reaches its maximum number of packets, re-keying MUST be triggered on ALL streams sharing the master key. (From strict security point of view, only the stream reaching the maximum would need to be re-keyed, but then the streams would no longer be sharing master key, which is the intention.) A local policy at the sender side should force rekeying in a way that the maximum packet limit is not reached on any of the streams. Use of the MKI for re-keying is RECOMMENDED.
以上が1SRTP/SRTCPがそれを流すより(同じRTPセッション中に)あれば、マスターキーを共有してください、ストリームの1つが最大数のパケットに達する前に再合わせて、マスターキーを共有して、すべてのストリームで引き起こさなければならない2^48SRTPパケット/2^31SRTCPパケット手段の上限。 (厳しいセキュリティ観点から、最大に達するストリームだけが、再合わせられる必要があるでしょう、しかし、次に、ストリームはもうマスターキーを共有していないでしょう(意志です)。) 送付者側のローカルの方針は最大のパケット限界にストリームのいずれでも達していない方法における「再-合わせ」ることを強制するべきです。MKIの再の合わせることの使用はRECOMMENDEDです。
In large multicast with one sender, the same considerations as for the small group multicast hold. The biggest issue in this scenario is the additional load placed at the sender side, due to the state (cryptographic contexts) that has to be maintained for each receiver, sending back RTCP Receiver Reports. At minimum, a replay window might need to be maintained for each RTCP source.
1人の送付者がいる大きいマルチキャストでは、小さいグループマルチキャストのような同じ問題は成立します。 このシナリオで最も大きい問題は送付者側に置かれた、追加負荷です、各受信機のために維持されなければならない状態(暗号の文脈)のため、RTCP Receiver Reportsを返送して。 最小限では、再生ウィンドウは、それぞれのRTCPソースに維持される必要があるかもしれません。
11.3. Re-keying and access control
11.3. 再の合わせるのとアクセスコントロール
Re-keying may occur due to access control (e.g., when a member is removed during a multicast RTP session), or for pure cryptographic reasons (e.g., the key is at the end of its lifetime). When using SRTP default transforms, the master key MUST be replaced before any of the index spaces are exhausted for any of the streams protected by one and the same master key.
再の合わせることはアクセスコントロール(例えば、マルチキャストRTPセッションの間メンバーを免職するとき)のためか純粋な暗号の理由ので起こるかもしれません(生涯の終わりに、例えばキーがあります)。 SRTPデフォルト変換を使用するとき、全く同じマスターキーによって保護されたストリームのどれかのためにインデックス空間のどれかを消耗させる前にマスターキーを取り替えなければなりません。
How key management re-keys SRTP implementations is out of scope, but it is clear that there are straightforward ways to manage keys for a multicast group. In one-sender multicast, for example, it is typically the responsibility of the sender to determine when a new key is needed. The sender is the one entity that can keep track of when the maximum number of packets has been sent, as receivers may join and leave the session at any time, there may be packet loss and delay etc. In scenarios other than one-sender multicast, other methods can be used. Here, one must take into consideration that key exchange can be a costly operation, taking several seconds for a single exchange. Hence, some time before the master key is exhausted/expires, out-of-band key management is initiated, resulting
範囲の外にかぎ管理再キーSRTP実装がありますが、マルチキャストグループのためにキーを管理する簡単な方法があるのは、どう明確であるか。 1送付者のマルチキャストでは、例えば、通常、新しいキーがいつ必要であるかを決定するのは、送付者の責任です。 送付者がセッションパケットの最大数を送りました、受信機が接合して、いなくなるとき時何時でも動向をおさえることができる1つの実体である、パケット損失、遅れなどがあるかもしれません。 1送付者のマルチキャスト以外のシナリオでは、他のメソッドを使用できます。 ここで、主要な交換が高価な操作であるかもしれないことを考慮に入れなければなりません、ただ一つの交換に数秒取って。 したがって、マスターキーが疲れ果てている/である前にいくらかの時間が期限が切れて、なって、バンドの外では、かぎ管理は着手されます。
Baugher, et al. Standards Track [Page 45] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[45ページ]。
in a new master key that is shared with the receiver(s). In any event, to maintain synchronization when switching to the new key, group policy might choose between using the MKI and the <From, To>, as described in Section 8.1.
新しいマスターキーでは、それは受信機と共有されます。 とにかく、新しいキーに切り替わるとき、同期を維持するために、グループ方針はMKIを使用して、<Fromを選ぶかもしれません、To>、セクション8.1で説明されるように。
For access control purposes, the <From, To> periods are set at the desired granularity, dependent on the packet rate. High rate re- keying can be problematic for SRTCP in some large-group scenarios. As mentioned, there are potential problems in using the SRTP index, rather than the SRTCP index, for determining the master key. In particular, for short periods during switching of master keys, it may be the case that SRTCP packets are not under the current master key of the correspondent SRTP. Therefore, using the MKI for re-keying in such scenarios will produce better results.
アクセス管理目的、<Fromにおいて、To>の期間はパケットレートに依存する必要な粒状で決められます。 SRTCPに、高い率再の合わせるのはいくつかの大きいグループシナリオで問題が多い場合があります。 言及されるように、SRTCPインデックスよりむしろSRTPインデックスを使用するのにおいて潜在的な問題があります、マスターキーを決定するために。 特に、そして、短い間マスターキーを切り換える間、通信員SRTPの現在のマスターキーの下にSRTCPパケットがないのは、事実であるかもしれません。 したがって、そのようなものでシナリオを再合わせるのにMKIを使用するのは好結果をもたらすでしょう。
11.4. Summary of basic scenarios
11.4. 基本的なシナリオの概要
The description of these scenarios highlights some recommendations on the use of SRTP, mainly related to re-keying and large scale multicast:
これらのシナリオの記述は再の合わせるのと大規模マルチキャストに主に関連するSRTPの使用にいくつかの推薦を強調します:
- Do not use fast re-keying with the <From, To> feature. It may, in
particular, give problems in retrieving the correct SRTCP key, if
an SRTCP packet arrives close to the re-keying time. The MKI
SHOULD be used in this case.
- <で速くFrom、Toを再合わせ>の特徴を使用しないでください。 それは正しいSRTCPキーを検索する際に問題を特に与えるかもしれません、SRTCPパケットが再の合わせる時間の近く間、到着するなら。 MKI SHOULD、この場合、使用されてください。
- If multiple SRTP streams in the same RTP session share the same
master key, also moderate rate re-keying MAY have the same
problems, and the MKI SHOULD be used.
- 同じRTPセッションにおける複数のSRTPストリームが同じマスターキーを共有して、また、5月を再合わせるレートを加減するなら、同じ問題、およびMKI SHOULDは使用されましたか?
- Though offering increased security, a non-zero key_derivation_rate
is NOT RECOMMENDED when trying to minimize the number of keys in
use with multiple streams.
- 増強されたセキュリティを提供しますが、複数のストリームで使用中のキーの数を最小にしようとするとき、非ゼロの主要な_派生_レートはNOT RECOMMENDEDです。
12. IANA Considerations
12. IANA問題
The RTP specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to transport methods. This profile registers the name "RTP/SAVP".
RTP仕様は、輸送メソッドを示すために、よりハイレベルの制御プロトコルによる使用のためのプロフィール名の登録、Session記述プロトコル(SDP)としてのそのようなものを設立します。 このプロフィールは"RTP/SAVP"という名前を登録します。
SRTP uses cryptographic transforms which a key management protocol signals. It is the task of each particular key management protocol to register the cryptographic transforms or suites of transforms with IANA. The key management protocol conveys these protocol numbers, not SRTP, and each key management protocol chooses the numbering scheme and syntax that it requires.
SRTPはかぎ管理プロトコルが示す暗号の変換を使用します。 それは変換の暗号の変換かスイートをIANAに登録するそれぞれの特定のかぎ管理プロトコルに関するタスクです。 かぎ管理プロトコルはSRTPではなく、これらのプロトコル番号を伝えます、そして、それぞれのかぎ管理プロトコルはそれが必要とするナンバリングスキームと構文を選びます。
Baugher, et al. Standards Track [Page 46] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[46ページ]。
Specification of a key management protocol for SRTP is out of scope here. Section 8.2, however, provides guidance on the parameters that need to be defined for the default and mandatory transforms.
SRTPのためのかぎ管理プロトコルの仕様がここに範囲の外にあります。 しかしながら、セクション8.2はデフォルトと義務的な変換のために定義される必要があるパラメタで指導を提供します。
13. Acknowledgements
13. 承認
David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this document but their valuable contributions are acknowledged here to keep the length of the author list down.
デヴィッドオラン(シスコ)とロルフ・ブロム(エリクソン)はこのドキュメントの共著者ですが、彼らの有価約因はここで作者リストの長さを抑えると承諾されます。
The authors would in addition like to thank Magnus Westerlund, Brian Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie- Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen Colin Perkins and Stephen Casner, the Transport and Security Area Directors, and Eric Rescorla for their reviews and support.
作者は彼らのレビューとサポートについてさらに、マグヌスWesterlund、ブライアン・ウィス、Ghyslainペレティア、モーガン・リンクヴィスト、ロバート・フェアリーCuninghame、エードリアンPerrig、AVT WG、コリン・パーキンス、スティーブンCasner、Transport、Security Areaディレクター、および特にエリック・レスコラ議長に感謝したがっています。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[AES] NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
http://www.nist.gov/aes/
[AES]NIST、「エー・イー・エス(AES)」、FIPSパブ197、 http://www.nist.gov/aes/
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
May 2000.
[RFC2828]Shirey(R.、「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-time Applications", RFC
3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", RFC 3551, July
2003.
[RFC3551]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
Baugher, et al. Standards Track [Page 47] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[47ページ]。
14.2. Informative References
14.2. 有益な参照
[AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode
Encryption", NIST, http://csrc.nist.gov/encryption/modes/
workshop1/papers/lipmaa-ctr.pdf
[AES-CTR] LipmaaとH.とRogawayとP.とD.ワグナー、「CTR-モード暗号化」、NIST、 http://csrc.nist.gov/encryption/modes/ workshop1/書類/lipmaa-ctr.pdf
[B96] Bellovin, S., "Problem Areas for the IP Security
Protocols," in Proceedings of the Sixth Usenix Unix
Security Symposium, pp. 1-16, San Jose, CA, July 1996
(http://www.research.att.com/~smb/papers/index.html).
[B96]Bellovin、S.、Sixth Usenix Unix Security SymposiumのProceedings、ページの「IPセキュリティー・プロトコルのための問題領域」 1-16と、サンノゼ(カリフォルニア)1996( http://www.research.att.com/~smb/papers/index.html )年7月。
[BDJR] Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A
Concrete Treatment of Symmetric Encryption: Analysis of DES
Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-
403, 1997.
[BDJR] Bellare、M.、デセイ、A.、Jokipii、E.、およびP.Rogaway、「左右対称の暗号化の具体的な処理:」 「OperationのDES Modesの分析」、Proceedings第38IEEE FOCS、ページ 394- 403, 1997.
[BS00] Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data
Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000,
LNCS 1976, pp. 1-13, Springer Verlag.
[BS00] BiryukovとA.とA.シャミル、「ストリーム暗号のためのCryptanalytic時間/メモリ/データ見返り」、Proceedings、ASIACRYPT2000、LNCS1976、ページ 1-13、よりバネのVerlag。
[C99] Crowell, W. P., "Introduction to the VENONA Project",
http://www.nsa.gov:8080/docs/venona/index.html.
[C99]クロウェル、W.P.、「VENONAプロジェクトへの紹介」、 http://www.nsa.gov:8080/docs/venona/index.html 。
[CTR] Dworkin, M., NIST Special Publication 800-38A,
"Recommendation for Block Cipher Modes of Operation:
Methods and Techniques", 2001.
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
38a.pdf.
[CTR] ドーキン、M.、NISTの特別な公表800-38A、「ブロックのための推薦は運転モードを解きます」。 2001の「方法とテクニック」、 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800- 38a. pdf。
[f8-a] 3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd
Generation Partnership Project; Technical Specification
Group Services and System Aspects; 3G Security;
Specification of the 3GPP Confidentiality and Integrity
Algorithms; Document 1: f8 and f9 Specification (Release
4).
[f8-a]3GPP t35.201V4.1.0(2001-12)仕様書の第3世代パートナーシッププロジェクト。 仕様書グループサービスとシステム局面。 3Gセキュリティ。 3GPP秘密性と保全アルゴリズムの仕様。 ドキュメント1: f8とf9 Specification(リリース4)。
[f8-b] 3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd
Generation Partnership Project; Technical Specification
Group Services and System Aspects; 3G Security; General
Report on the Design, Specification and Evaluation of 3GPP
Standard Confidentiality and Integrity Algorithms (Release
4).
[f8-b]3GPP TR33.908V4.0.0(2001-09)技術報告書の第3世代パートナーシッププロジェクト。 仕様書グループサービスとシステム局面。 3Gセキュリティ。 3GPPの標準の秘密性と保全アルゴリズム(リリース4)のデザイン、仕様、および評価に関する一般レポート。
[GDOI] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
Group Domain of Interpretation, RFC 3547, July 2003.
[GDOI] BaugherとM.とウィスとB.とHardjonoとT.とH.ハーニー、「解釈のグループドメイン、RFC3547、2003年7月。」
Baugher, et al. Standards Track [Page 48] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[48ページ]。
[HAC] Menezes, A., Van Oorschot, P. and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-
8523-7.
[HAC] メネゼス、A.はOorschotとP.とS.Vanstone、「適用された暗号のハンドブック」、CRCプレス、1997、ISBN0-8493- 8523-7をバンに積みます。
[H80] Hellman, M. E., "A cryptanalytic time-memory trade-off",
IEEE Transactions on Information Theory, July 1980, pp.
401-406.
[H80]ヘルマン、M.E.、「cryptanalytic時間メモリトレードオフ」、情報Theory、1980年7月、ページのIEEE Transactions 401-406.
[IK] T. Iwata and T. Kohno: "New Security Proofs for the 3GPP
Confidentiality and Integrity Algorithms", Proceedings of
FSE 2004.
[IK] T.磐田とT.河野: 「新しいセキュリティは3GPP秘密性と保全のためにアルゴリズムを検査する」FSE2004の議事。
[KINK] Thomas, M. and J. Vilhuber, "Kerberized Internet
Negotiation of Keys (KINK)", Work in Progress.
[ねじれます] 「キー(もつれ)のKerberizedインターネット交渉」というトーマス、M.、およびJ.Vilhuberは進行中で働いています。
[KEYMGT] Arrko, J., et al., "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Protocol
(RTSP)", Work in Progress.
[KEYMGT]Arrko、J.、他、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、ProgressのWork。
[KSYH] Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable
Security of KASUMI and 3GPP Encryption Mode f8",
Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp.
255-271, 2001.
[KSYH]カンとJ-S.とShinとS-U.とHongとD.とO.イーと「香住の証明可能なSecurityと3GPP Encryption Mode f8"、Proceedings Asiacrypt2001、Springer Verlag LNCS2248、ページ」 255-271, 2001.
[MIKEY] Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing",
Work in Progress.
et[マイキー]Arrko、J.、アル、「マイキー:」 「マルチメディアインターネットの合わせること」は進行中で働いています。
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of
Redundant Plaintext and Implications on Internet Security",
the Proceedings of the Seventh Annual Workshop on Selected
Areas in Cryptography (SAC 2000), Springer-Verlag.
[MF00]マグリュー(D.とS.Fluhrer)は、「余分な平文と含意の暗号化のときにインターネットセキュリティで攻撃します」、選択された領域における暗号(嚢2000)における、第7例年のワークショップの議事、追出石-Verlag。
[PCST1] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
and Secure Source Authentication for Multicast", in Proc.
of Network and Distributed System Security Symposium NDSS
2001, pp. 35-46, 2001.
中の[PCST1]PerrigとA.とカネッティとR.、TygarとD.とD.Song、「マルチキャストのための効率的で安全なソース認証」Proc NetworkとDistributed System Security Symposium NDSS2001、ページについて 35-46, 2001.
[PCST2] Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
Authentication and Signing of Multicast Streams over Lossy
Channels", in Proc. of IEEE Security and Privacy Symposium
S&P2000, pp. 56-73, 2000.
[PCST2] Perrig、A.、カネッティ、R.、Tygar、D.、およびD.Song、「マルチキャストの効率的な認証と調印は損失性チャンネルの上に流れます」、ProcでIEEE SecurityとPrivacy Symposium S&P2000、ページ 56-73, 2000.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999.
[RFC2675]ボーマンとD.とデアリングとS.とR.Hinden、「IPv6 Jumbograms」、RFC2675 1999年8月。
Baugher, et al. Standards Track [Page 49] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[49ページ]。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
Framework and Four Profiles: RTP, UDP, ESP, and
uncompressed (ROHC)", RFC 3095, July 2001.
[RFC3095] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、Fukuhsima、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮:」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP(ROHC)」、RFC3095、7月2001日
[RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
3242, April 2002.
[RFC3242]イェンソン、L-E.、およびG.ペレティア、「体力を要しているヘッダー圧縮(ROHC):」 「リンクレイヤはIP/UDP/RTPのためにプロフィールを補助した」RFC3242、2002年4月。
[SDMS] Andreasen, F., Baugher, M. and D. Wing, "Session
Description Protocol Security Descriptions for Media
Streams", Work in Progress.
「メディアの流れのためのセッション記述プロトコルセキュリティ記述」というAndreasen、F.、Baugher、M.、およびD.が翼をつけさせる[SDMS]は進行中で働いています。
[SWO] Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
wireless", Proc. PIMRC 2000, London, Sept. 2000.
[SWO] SvanbroとK.とWiorekとJ.とB.オリン、「Voice-over-IP過剰無線電信」、Proc。 PIMRC2000、ロンドン2000年9月。
[V02] Vaudenay, S., "Security Flaws Induced by CBC Padding -
Application to SSL, IPsec, WTLS...", Advances in
Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
[V02] Vaudenay、S.、「セキュリティー・フローはCBCでSSL、IPsec、WTLSに詰め物--アプリケーションを引き起こしました」…, Cryptology、EUROCRYPTでは、'02、LNCS2332、ページ'を進めます。 534-545.
[WC81] Wegman, M. N., and J.L. Carter, "New Hash Functions and
Their Use in Authentication and Set Equality", JCSS 22,
265-279, 1981.
[WC81]ウェッグマン、M.N.、J.L.カーター、および「認証とセット平等における新しいハッシュ関数と彼らの使用」、JCSS22、265-279、1981
Baugher, et al. Standards Track [Page 50] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[50ページ]。
Appendix A: Pseudocode for Index Determination
付録A: インデックス決断のための擬似コード
The following is an example of pseudo-code for the algorithm to determine the index i of an SRTP packet with sequence number SEQ. In the following, signed arithmetic is assumed.
↓これはアルゴリズムがインデックスを決定する中間コードに関する例です。一連番号SEQがあるSRTPパケットのi。 以下では、サインされた演算は想定されます。
if (s_l < 32,768)
if (SEQ - s_l > 32,768)
set v to (ROC-1) mod 2^32
else
set v to ROC
endif
else
if (s_l - 32,768 > SEQ)
set v to (ROC+1) mod 2^32
else
set v to ROC
endif
endif
return SEQ + v*65,536
(s_l<32,768)であるなら、ROC endif endifリターンSEQ+v*65,536にセットされて、(ROC-1)モッズ風のほかの2^32への(SEQ--s_l>32,768)セットvであるならほかの(ROC+1)モッズ風の2^32への(s_l--3万2768>SEQ)セットvであるならほかにROC endifにvを設定してください。
Appendix B: Test Vectors
付録B: テストベクトル
All values are in hexadecimal.
16進にはすべての値があります。
B.1. AES-f8 Test Vectors
B.1。 AES-f8テストベクトル
SRTP PREFIX LENGTH : 0
SRTPは長さを前に置きます: 0
RTP packet header : 806e5cba50681de55c621599
RTPパケットのヘッダー: 806e5cba50681de55c621599
RTP packet payload : 70736575646f72616e646f6d6e657373
20697320746865206e65787420626573
74207468696e67
RTPパケットペイロード: 70736575646f72616e646f6d6e657373 20697320746865206e65787420626573 74207468696e67
ROC : d462564a key : 234829008467be186c3de14aae72d62c salt key : 32f2870d key-mask (m) : 32f2870d555555555555555555555555 key XOR key-mask : 11baae0dd132eb4d3968b41ffb278379
ロック: d462564aキー: 234829008467be186c3de14aae72d62c塩のキー: 32f2870d主要なマスク(m): 32f2870d555555555555555555555555の主要なXOR主要なマスク: 11baae0dd132eb4d3968b41ffb278379
IV : 006e5cba50681de55c621599d462564a IV' : 595b699bbd3bc0df26062093c1ad8f73
IV: '006e5cba50681de55c621599d462564a IV': 595b699bbd3bc0df26062093c1ad8f73
Baugher, et al. Standards Track [Page 51] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[51ページ]。
j = 0 IV' xor j : 595b699bbd3bc0df26062093c1ad8f73 S(-1) : 00000000000000000000000000000000 IV' xor S(-1) xor j : 595b699bbd3bc0df26062093c1ad8f73 S(0) : 71ef82d70a172660240709c7fbb19d8e plaintext : 70736575646f72616e646f6d6e657373 ciphertext : 019ce7a26e7854014a6366aa95d4eefd
'j=0IV'xor j: 595b699bbd3bc0df26062093c1ad8f73 S(-1): '00000000000000000000000000000000 IV'xor S(-1) xor j: 595b699bbd3bc0df26062093c1ad8f73 S(0): 71ef82d70a172660240709c7fbb19d8e平文: 70736575646f72616e646f6d6e657373暗号文: 019ce7a26e7854014a6366aa95d4eefd
j = 1 IV' xor j : 595b699bbd3bc0df26062093c1ad8f72 S(0) : 71ef82d70a172660240709c7fbb19d8e IV' xor S(0) xor j : 28b4eb4cb72ce6bf020129543a1c12fc S(1) : 3abd640a60919fd43bd289a09649b5fc plaintext : 20697320746865206e65787420626573 ciphertext : 1ad4172a14f9faf455b7f1d4b62bd08f
'j=1IV'xor j: 595b699bbd3bc0df26062093c1ad8f72 S(0): '71ef82d70a172660240709c7fbb19d8e IV'xor S(0) xor j: 28b4eb4cb72ce6bf020129543a1c12fc S(1): 3abd640a60919fd43bd289a09649b5fc平文: 20697320746865206e65787420626573暗号文: 1ad4172a14f9faf455b7f1d4b62bd08f
j = 2 IV' xor j : 595b699bbd3bc0df26062093c1ad8f71 S(1) : 3abd640a60919fd43bd289a09649b5fc IV' xor S(1) xor j : 63e60d91ddaa5f0b1dd4a93357e43a8d S(2) : 220c7a8715266565b09ecc8a2a62b11b plaintext : 74207468696e67 ciphertext : 562c0eef7c4802
'j=2IV'xor j: 595b699bbd3bc0df26062093c1ad8f71 S(1): '3abd640a60919fd43bd289a09649b5fc IV'xor S(1) xor j: 63e60d91ddaa5f0b1dd4a93357e43a8d S(2): 220c7a8715266565b09ecc8a2a62b11b平文: 74207468696e67暗号文: 562c0eef7c4802
B.2. AES-CM Test Vectors
B.2。 AES-CMテストベクトル
Keystream segment length: 1044512 octets (65282 AES blocks)
Session Key: 2B7E151628AED2A6ABF7158809CF4F3C
Rollover Counter: 00000000
Sequence Number: 0000
SSRC: 00000000
Session Salt: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
Offset: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
Keystreamセグメントの長さ: 1044512の八重奏(65282AESブロック)のセッションKey: 2B7E151628AED2A6ABF7158809CF4F3Cロールオーバーカウンタ: 00000000一連番号: 0000SSRC: 00000000 セッション塩: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000(既に、移行する)は相殺します: F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
Counter Keystream
カウンタKeystream
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 E03EAD0935C95E80E166B16DD92B4EB4
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001 D23513162B02D0F72A43A2FE4A5F97AB
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002 41E95B3BB0A2E8DD477901E4FCA894C0
... ...
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF EC8CDF7398607CB0F2D21675EA9EA1E4
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00 362B7C3C6773516318A077D7FC5073AE
F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01 6A2CC3787889374FBEB4C81B17BA6C44
F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000E03EAD0935C95E80E166B16DD92B4EB4 F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001D23513162B02D0F72A43A2FE4A5F97AB F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002 41E95B3BB0A2E8DD477901E4FCA894C0… ... F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF EC8CDF7398607CB0F2D21675EA9EA1E4 F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00 362B7C3C6773516318A077D7FC5073AE F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01 6A2CC3787889374FBEB4C81B17BA6C44
Nota Bene: this test case is contrived so that the latter part of the keystream segment coincides with the test case in Section F.5.1 of [CTR].
背板嘆願: このテストケースが人為的であるので、keystreamセグメントの後半は[CTR]のセクションF.5.1のテストケースと一致しています。
Baugher, et al. Standards Track [Page 52] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[52ページ]。
B.3. Key Derivation Test Vectors
B.3。 主要な派生テストベクトル
This section provides test data for the default key derivation function, which uses AES-128 in Counter Mode. In the following, we walk through the initial key derivation for the AES-128 Counter Mode cipher, which requires a 16 octet session encryption key and a 14 octet session salt, and an authentication function which requires a 94-octet session authentication key. These values are called the cipher key, the cipher salt, and the auth key in the following. Since this is the initial key derivation and the key derivation rate is equal to zero, the value of (index DIV key_derivation_rate) is zero (actually, a six-octet string of zeros). In the following, we shorten key_derivation_rate to kdr.
このセクションはデフォルトキー派生機能のためのテストデータを提供します。(機能はCounter ModeでAES-128を使用します)。 以下では、私たちは16八重奏セッション暗号化キーと14八重奏セッション塩を必要とするAES-128 Counter Mode暗号と94八重奏のセッション認証キーを必要とする認証機能のための初期の主要な派生で下稽古します。 これらの値は暗号キー、暗号塩、および以下で主要なauthと呼ばれます。 これが初期の主要な派生であり、主要な派生率がゼロに合わせるために等しいので、(インデックスDIVキー_派生_率)の値はゼロ(実際にゼロの6八重奏のストリング)です。 以下では、私たちは主要な_派生_レートをkdrに短くします。
The inputs to the key derivation function are the 16 octet master key and the 14 octet master salt:
主要な派生機能への入力は、16八重奏マスターキーと14八重奏マスター塩です:
master key: E1F97A0D3E018BE0D64FA32C06DE4139
master salt: 0EC675AD498AFEEBB6960B3AABE6
マスターキー: E1F97A0D3E018BE0D64FA32C06DE4139は塩を習得します: 0EC675AD498AFEEBB6960B3AABE6
We first show how the cipher key is generated. The input block for AES-CM is generated by exclusive-oring the master salt with the concatenation of the encryption key label 0x00 with (index DIV kdr), then padding on the right with two null octets (which implements the multiply-by-2^16 operation, see Section 4.3.3). The resulting value is then AES-CM- encrypted using the master key to get the cipher key.
私たちは最初に、暗号キーがどう発生するかを示しています。 AES-CMのための入力ブロックは(インデックスDIV kdr)との暗号化の主要なラベル0x00の連結があるマスターの排他的なoring塩で発生します、八重奏がその時2ヌルがある右でそっと歩いて(セクション4.3.3は、どれが近く増える-2^16操作を実行するかを見ます)。 結果として起こる値は、当時のAES-CMによって暗号キーを手に入れるのにマスターキーを使用することでコード化されています。
index DIV kdr: 000000000000
label: 00
master salt: 0EC675AD498AFEEBB6960B3AABE6
-----------------------------------------------
xor: 0EC675AD498AFEEBB6960B3AABE6 (x, PRF input)
DIV kdrに索引をつけてください: 000000000000ラベル: 00 塩を習得してください: 0EC675AD498AFEEBB6960B3AABE6----------------------------------------------- xor: 0EC675AD498AFEEBB6960B3AABE6(x、PRF入力)
x*2^16: 0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
x*2^16: 0EC675AD498AFEEBB6960B3AABE60000(AES-CM入力)
cipher key: C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)
キーを解いてください: C61E7A93744F39EE10734AFE3FF7A087(AES-CM出力)
Baugher, et al. Standards Track [Page 53] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[53ページ]。
Next, we show how the cipher salt is generated. The input block for AES-CM is generated by exclusive-oring the master salt with the concatenation of the encryption salt label. That value is padded and encrypted as above.
次に、私たちは暗号塩がどう発生するかを示しています。 AES-CMのための入力ブロックは暗号化塩のラベルの連結があるマスターの排他的なoring塩で発生します。 その値は、同じくらい上で水増しされて、コード化されます。
index DIV kdr: 000000000000
label: 02
master salt: 0EC675AD498AFEEBB6960B3AABE6
DIV kdrに索引をつけてください: 000000000000ラベル: 02 塩を習得してください: 0EC675AD498AFEEBB6960B3AABE6
----------------------------------------------
xor: 0EC675AD498AFEE9B6960B3AABE6 (x, PRF input)
---------------------------------------------- xor: 0EC675AD498AFEE9B6960B3AABE6(x、PRF入力)
x*2^16: 0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
x*2^16: 0EC675AD498AFEE9B6960B3AABE60000(AES-CM入力)
30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
30CBBC08863D8C85D49DB34A9AE17AC6(AES-CM ouptut)
cipher salt: 30CBBC08863D8C85D49DB34A9AE1
塩を解いてください: 30CBBC08863D8C85D49DB34A9AE1
We now show how the auth key is generated. The input block for AES- CM is generated as above, but using the authentication key label.
私たちは現在、authキーがどう発生するかを示しています。 AES CMのための入力ブロックは、同じくらい上で発生しますが、認証の主要なラベルを使用しています。
index DIV kdr: 000000000000
label: 01
master salt: 0EC675AD498AFEEBB6960B3AABE6
-----------------------------------------------
xor: 0EC675AD498AFEEAB6960B3AABE6 (x, PRF input)
DIV kdrに索引をつけてください: 000000000000ラベル: 01 塩を習得してください: 0EC675AD498AFEEBB6960B3AABE6----------------------------------------------- xor: 0EC675AD498AFEEAB6960B3AABE6(x、PRF入力)
x*2^16: 0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)
x*2^16: 0EC675AD498AFEEAB6960B3AABE60000(AES-CM入力)
Below, the auth key is shown on the left, while the corresponding AES input blocks are shown on the right.
以下では、authキーが左で見せられますが、対応するAES入力ブロックは右で見せられます。
auth key AES input blocks CEBE321F6FF7716B6FD4AB49AF256A15 0EC675AD498AFEEAB6960B3AABE60000 6D38BAA48F0A0ACF3C34E2359E6CDBCE 0EC675AD498AFEEAB6960B3AABE60001 E049646C43D9327AD175578EF7227098 0EC675AD498AFEEAB6960B3AABE60002 6371C10C9A369AC2F94A8C5FBCDDDC25 0EC675AD498AFEEAB6960B3AABE60003 6D6E919A48B610EF17C2041E47403576 0EC675AD498AFEEAB6960B3AABE60004 6B68642C59BBFC2F34DB60DBDFB2 0EC675AD498AFEEAB6960B3AABE60005
主要なAESが入力したauthはCEBE321F6FF7716B6FD4AB49AF256A15 0EC675AD498AFEEAB6960B3AABE60000 6D38BAA48F0A0ACF3C34E2359E6CDBCE 0EC675AD498AFEEAB6960B3AABE60001E049646C43D9327AD175578EF7227098 0EC675AD498AFEEAB6960B3AABE60002 6371C10C9A369AC2F94A8C5FBCDDDC25 0EC675AD498AFEEAB6960B3AABE60003 6D6E919A48B610EF17C2041E47403576 0EC675AD498AFEEAB6960B3AABE60004 6B68642C59BBFC2F34DB60DBDFB2 0EC675AD498AFEEAB6960B3AABE60005を妨げます。
Baugher, et al. Standards Track [Page 54] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[54ページ]。
Authors' Addresses
作者のアドレス
Questions and comments should be directed to the authors and avt@ietf.org:
質問とコメントは作者と avt@ietf.org に向けられるべきです:
Mark Baugher Cisco Systems, Inc. 5510 SW Orchid Street Portland, OR 97219 USA
マークBaugherシスコシステムズInc.5510SWラン通りポートランド、または97219米国
Phone: +1 408-853-4418 EMail: mbaugher@cisco.com
以下に電話をしてください。 +1 408-853-4418 メールしてください: mbaugher@cisco.com
Elisabetta Carrara Ericsson Research SE-16480 Stockholm Sweden
Elisabettaカラーラエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 50877040 EMail: elisabetta.carrara@ericsson.com
以下に電話をしてください。 +46 8 50877040 メール: elisabetta.carrara@ericsson.com
David A. McGrew Cisco Systems, Inc. San Jose, CA 95134-1706 USA
デヴィッド・A.マグリュー・シスコシステムズInc.カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 301-349-5815 EMail: mcgrew@cisco.com
以下に電話をしてください。 +1 301-349-5815 メールしてください: mcgrew@cisco.com
Mats Naslund Ericsson Research SE-16480 Stockholm Sweden
Matsジーター・エリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 58533739 EMail: mats.naslund@ericsson.com
以下に電話をしてください。 +46 8 58533739 メール: mats.naslund@ericsson.com
Karl Norrman Ericsson Research SE-16480 Stockholm Sweden
カール・Norrmanエリクソン研究SE-16480ストックホルムスウェーデン
Phone: +46 8 4044502 EMail: karl.norrman@ericsson.com
以下に電話をしてください。 +46 8 4044502 メール: karl.norrman@ericsson.com
Baugher, et al. Standards Track [Page 55] RFC 3711 SRTP March 2004
Baugher、他 規格は2004年のSRTP行進のときにRFC3711を追跡します[55ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). 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.
Copyright(C)インターネット協会(2004)。 このドキュメントは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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baugher, et al. Standards Track [Page 56]
Baugher、他 標準化過程[56ページ]
一覧
スポンサーリンク
