Internet Engineering Task Force (IETF) P. Zimmermann
Request for Comments: 6189 Zfone Project
Category: Informational A. Johnston, Ed.
ISSN: 2070-1721 Avaya
J. Callas
Apple, Inc.
April 2011
ZRTP: Media Path Key Agreement for Unicast Secure RTP
Abstract
抽象
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature.
この文書はZRTP、IP（VoIP）のアプリケーション、ボイスオーバーのためのユニキャストセキュアリアルタイム転送プロトコル（SRTP）セッションを確立するためのセッションキーおよびパラメータに合意するメディアパスのDiffie-Hellman交換のためのプロトコルを定義します。 ZRTPプロトコルは、それがRTPと同じポート上で多重化されており、シグナリングプロトコルでのサポートを必要としないので、キーイングメディアパスです。 ZRTPは、公開鍵インフラストラクチャ（PKI）を想定またはエンドデバイス内の証明書の複雑さを必要としません。メディアセッションのために、ZRTPは、機密性、のman-in-the-middle（MITM）攻撃に対する保護、および、シグナリングプロトコルは、エンドツーエンドの完全性保護、認証を提供する場合にを提供します。 ZRTPは、セッション記述プロトコル（SDP）シグナリングチャネルを介して発見及び認証を提供する属性を利用することができます。ベストエフォートSRTPを提供するために、ZRTPは、通常のRTP / AVP（オーディオビジュアルプロファイル）のプロファイルを利用しています。 ZRTPは、音声メディアストリームが含まれており、オプションのデジタル署名を使用して音声を含まないセキュアメディアセッションをすることができ、メディアセッションを確保します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6189.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6189で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Overview ........................................................6
3.1. Key Agreement Modes ........................................7
3.1.1. Diffie-Hellman Mode Overview ........................7
3.1.2. Preshared Mode Overview .............................9
3.1.3. Multistream Mode Overview ...........................9
4. Protocol Description ...........................................10
4.1. Discovery .................................................10
4.1.1. Protocol Version Negotiation .......................11
4.1.2. Algorithm Negotiation ..............................13
4.2. Commit Contention .........................................14
4.3. Matching Shared Secret Determination ......................15
4.3.1. Calculation and Comparison of Hashes of
Shared Secrets .....................................17
4.3.2. Handling a Shared Secret Cache Mismatch ............18
4.4. DH and Non-DH Key Agreements ..............................19
4.4.1. Diffie-Hellman Mode ................................19
4.4.1.1. Hash Commitment in Diffie-Hellman Mode ....20
4.4.1.2. Responder Behavior in
Diffie-Hellman Mode .......................21
4.4.1.3. Initiator Behavior in
Diffie-Hellman Mode .......................22
4.4.1.4. Shared Secret Calculation for DH Mode .....22
4.4.2. Preshared Mode .....................................25
4.4.2.1. Commitment in Preshared Mode ..............25
4.4.2.2. Initiator Behavior in Preshared Mode ......26
4.4.2.3. Responder Behavior in Preshared Mode ......26
4.4.2.4. Shared Secret Calculation for
Preshared Mode ............................27
4.4.3. Multistream Mode ...................................28
4.4.3.1. Commitment in Multistream Mode ............29
4.4.3.2. Shared Secret Calculation for
Multistream Mode ..........................29
4.5. Key Derivations ...........................................31
4.5.1. The ZRTP Key Derivation Function ...................31
4.5.2. Deriving ZRTPSess Key and SAS in DH or
Preshared Modes ....................................32
4.5.3. Deriving the Rest of the Keys from s0 ..............33
4.6. Confirmation ..............................................35
4.6.1. Updating the Cache of Shared Secrets ...............35
4.6.1.1. Cache Update Following a Cache Mismatch ...36
4.7. Termination ...............................................37
4.7.1. Termination via Error Message ......................37
4.7.2. Termination via GoClear Message ....................37
4.7.2.1. Key Destruction for GoClear Message .......39
4.7.3. Key Destruction at Termination .....................40
4.8. Random Number Generation ..................................40
4.9. ZID and Cache Operation ...................................41
4.9.1. Cacheless Implementations ..........................42
5. ZRTP Messages ..................................................42
5.1. ZRTP Message Formats ......................................44
5.1.1. Message Type Block .................................44
5.1.2. Hash Type Block ....................................45
5.1.2.1. Negotiated Hash and MAC Algorithm .........46
5.1.2.2. Implicit Hash and MAC Algorithm ...........47
5.1.3. Cipher Type Block ..................................47
5.1.4. Auth Tag Type Block ................................48
5.1.5. Key Agreement Type Block ...........................49
5.1.6. SAS Type Block .....................................51
5.1.7. Signature Type Block ...............................52
5.2. Hello Message .............................................53
5.3. HelloACK Message ..........................................56
5.4. Commit Message ............................................56
5.5. DHPart1 Message ...........................................60
5.6. DHPart2 Message ...........................................62
5.7. Confirm1 and Confirm2 Messages ............................63
5.8. Conf2ACK Message ..........................................66
5.9. Error Message .............................................66
5.10. ErrorACK Message .........................................68
5.11. GoClear Message ..........................................68
5.12. ClearACK Message .........................................69
5.13. SASrelay Message .........................................69
5.14. RelayACK Message .........................................72
5.15. Ping Message .............................................72
5.16. PingACK Message ..........................................73
6. Retransmissions ................................................74
7. Short Authentication String ....................................77
7.1. SAS Verified Flag .........................................78
7.2. Signing the SAS ...........................................79
7.2.1. OpenPGP Signatures .................................81
7.2.2. ECDSA Signatures with X.509v3 Certs ................82
7.2.3. Signing the SAS without a PKI ......................83
7.3. Relaying the SAS through a PBX ............................84
7.3.1. PBX Enrollment and the PBX Enrollment Flag .........87
8. Signaling Interactions .........................................89
8.1. Binding the Media Stream to the Signaling Layer
via the Hello Hash ........................................90
8.1.1. Integrity-Protected Signaling Enables
Integrity-Protected DH Exchange ....................92
8.2. Deriving the SRTP Secret (srtps) from the
Signaling Layer ...........................................93
8.3. Codec Selection for Secure Media ..........................94
9. False ZRTP Packet Rejection ....................................95
10. Intermediary ZRTP Devices .....................................97
11. The ZRTP Disclosure Flag ......................................98
11.1. Guidelines on Proper Implementation of the
Disclosure Flag .........................................100
12. Mapping between ZID and AOR (SIP URI) ........................100
13. IANA Considerations ..........................................102
14. Media Security Requirements ..................................102
15. Security Considerations ......................................104
15.1. Self-Healing Key Continuity Feature .....................107
16. Acknowledgments ..............................................108
17. References ...................................................109
17.1. Normative References ....................................109
17.2. Informative References ..................................111
ZRTP is a key agreement protocol that performs a Diffie-Hellman key exchange during call setup in the media path and is transported over the same port as the Real-time Transport Protocol (RTP) [RFC3550] media stream which has been established using a signaling protocol such as Session Initiation Protocol (SIP) [RFC3261]. This generates a shared secret, which is then used to generate keys and salt for a Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from [PGPfone]. A reference implementation of ZRTP is available in [Zfone].
ZRTPは、メディアパスに呼設定時のDiffie-Hellman鍵交換を行う鍵合意プロトコルであり、シグナリングを用いて確立されているリアルタイムトランスポートプロトコル（RTP）[RFC3550]メディアストリームと同じポート上に搬送されますそのようなセッション開始プロトコル（SIP）などのプロトコル[RFC3261]。これは、セキュアRTP（SRTP）[RFC3711]セッションのキーと塩を生成するために使用される共有秘密を生成します。 ZRTPは[PGPfone]からアイデアを借ります。 ZRTPのリファレンス実装は、[Zfone]で入手可能です。
The ZRTP protocol has some nice cryptographic features lacking in many other approaches to media session encryption. Although it uses a public key algorithm, it does not rely on a public key infrastructure (PKI). In fact, it does not use persistent public keys at all. It uses ephemeral Diffie-Hellman (DH) with hash commitment and allows the detection of man-in-the-middle (MiTM) attacks by displaying a short authentication string (SAS) for the users to read and verbally compare over the phone. It has Perfect Forward Secrecy, meaning the keys are destroyed at the end of the call, which precludes retroactively compromising the call by future disclosures of key material. But even if the users are too lazy to bother with short authentication strings, we still get reasonable authentication against a MiTM attack, based on a form of key continuity. It does this by caching some key material to use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to Secure SHell (SSH). All this is done without reliance on a PKI, key certification, trust models, certificate authorities, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact, it does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream.
ZRTPプロトコルは、メディアセッションの暗号化には多くの他のアプローチに欠けているいくつかの素晴らしい暗号化機能を備えています。それは、公開鍵アルゴリズムを使用していますが、それは、公開鍵基盤（PKI）に依存しません。実際には、それがすべてで永続的な公開鍵を使用していません。これは、ハッシュコミットメントではかないディフィー・ヘルマン（DH）を使用して、ユーザーが読んで、口頭、電話で比較するための短い認証文字列（SAS）を表示することによって、のman-in-the-middle（MITM）攻撃の検出を可能にします。これは、キーが遡及キーマテリアルの将来の開示によってコールを損なう排除通話の終了時に破壊されている意味、完全転送秘密を持っています。しかし、ユーザーが短い認証文字列を気にするのが面倒であったとしても、我々はまだキーの連続の形に基づいて、MITM攻撃に対して合理的な認証を取得します。それはそれをシェル（SSH）を確保するために類似したキーの連続性を与え、秘密を共有し、次のコールのDHで混合すると、次の呼び出しで使用するために、いくつかのキーマテリアルをキャッシュすることでこれを行います。このすべては、PKI、鍵証明書、信頼モデル、認証局、または電子メールの暗号化の世界をbedevils鍵管理の複雑さに依存せずに行われます。また、鍵管理のためのSIPシグナリングに依存せず、実際には、それがすべてではすべてのサーバーに依存しません。それは、RTPパケットストリーム上純粋にピアツーピアの方法で、その鍵合意および鍵管理を行います。
ZRTP can be used and discovered without being declared or indicated in the signaling path. This provides a best effort SRTP capability. Also, this reduces the complexity of implementations and minimizes interdependency between the signaling and media layers. However, when ZRTP is indicated in the signaling via the zrtp-hash SDP attribute, ZRTP has additional useful properties. By sending a hash of the ZRTP Hello message in the signaling, ZRTP provides a useful binding between the signaling and media paths, which is explained in Section 8.1. When this is done through a signaling path that has end-to-end integrity protection, the DH exchange is automatically protected from a MiTM attack, which is explained in Section 8.1.1.
ZRTPはシグナリングパス内で宣言または指示されずに使用され、発見することができます。これは、ベストエフォート型のSRTP機能を提供します。また、これは実装の複雑さを低減し、シグナリングおよびメディア層の間の相互依存性を最小化します。 ZRTPがZRTPハッシュSDP属性を介したシグナル伝達に記載されている場合しかし、ZRTP追加の有用な特性を有しています。シグナリングにZRTP Helloメッセージのハッシュを送信することによって、ZRTPは、セクション8.1で説明されているシグナリングおよびメディアパスとの間の結合に有用で提供します。これは、エンドツーエンドの完全性保護を持っているシグナリングパスを介して行われた場合、DH交換が自動的に8.1.1項で説明されてMITM攻撃から保護されています。
ZRTP is designed for unicast media sessions in which there is a voice media stream. For multiparty secure conferencing, separate ZRTP sessions may be negotiated between each party and the conference bridge. For sessions lacking a voice media stream, MiTM protection may be provided by the mechanisms in Sections 8.1.1 or 7.2. In terms of the RTP topologies defined in [RFC5117], ZRTP is designed for Point-to-Point topologies only.
ZRTPは、音声メディアストリームが存在するユニキャストメディアセッションのために設計されています。マルチパーティのセキュアな会議のために、別々のZRTPセッションは、各当事者と会議ブリッジの間で交渉することができます。音声メディアストリームを欠くセッションに対して、MITM保護は、セクション8.1.1、または7.2でメカニズムによって提供されてもよいです。 [RFC5117]で定義されたRTPトポロジの観点から、ZRTPは、ポイントツーポイントトポロジのみのために設計されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL 「本書では[RFC2119]で説明されるように解釈されるべきです。
In this document, a "call" is synonymous with a "session".
この文書では、「コール」を「セッション」と同義です。
This section provides a description of how ZRTP works. This description is non-normative in nature but is included to build understanding of the protocol.
このセクションでは、ZRTPがどのように動作するかの説明を提供します。この説明は、本質的に非規範的であるが、プロトコルの理解を構築するために含まれています。
ZRTP is negotiated the same way a conventional RTP session is negotiated in an offer/answer exchange using the standard RTP/AVP profile. The ZRTP protocol begins after two endpoints have utilized a signaling protocol, such as SIP, and are ready to exchange media. If Interactive Connectivity Establishment (ICE) [RFC5245] is being used, ZRTP begins after ICE has completed its connectivity checks.
ZRTPは、標準RTP / AVPプロファイルを用いた従来のRTPセッションがオファー/アンサー交換で交渉されたのと同じ方法を交渉しています。 2つのエンドポイントは、SIPなどのシグナリングプロトコルを利用し、メディアを交換する準備が整いました後ZRTPプロトコルが開始されます。インタラクティブ接続確立（ICE）[RFC5245]を使用している場合、ICEは、その接続性チェックが完了した後、ZRTPが始まります。
ZRTP is multiplexed on the same ports as RTP. It uses a unique header that makes it clearly differentiable from RTP or Session Traversal Utilities for NAT (STUN).
ZRTPはRTPと同じポート上で多重化されています。それは、NAT（STUN）のためのRTPまたはセッショントラバーサルユーティリティから、それは明らかに微分可能になりユニークなヘッダを使用しています。
ZRTP support can be discovered in the signaling path by the presence of a ZRTP SDP attribute. However, even in cases where this is not received in the signaling, an endpoint can still send ZRTP Hello messages to see if a response is received. If a response is not received, no more ZRTP messages will be sent during this session. This is safe because ZRTP has been designed to be clearly different from RTP and have a similar structure to STUN packets received (sometimes by non-supporting endpoints) during an ICE exchange.
ZRTPサポートはZRTP SDP属性の存在によってシグナリングパスで発見することができます。しかし、これはシグナリングに受信されない場合は、エンドポイントは、まだ応答が受信されたかどうかを確認するためにZRTP Helloメッセージを送ることができます。応答が受信されない場合は、これ以上のZRTPメッセージは、このセッション中に送信されます。 ZRTPは、RTPとは明らかに異なるように設計されており、ICEの交換時（時々非対応エンドポイントで）受信したパケットをSTUNと同様の構造を有しているので、これは安全です。
Both ZRTP endpoints begin the ZRTP exchange by sending a ZRTP Hello message to the other endpoint. The purpose of the Hello message is to confirm that the endpoint supports the protocol and to see what algorithms the two ZRTP endpoints have in common.
どちらZRTPエンドポイントは、他のエンドポイントにZRTP Helloメッセージを送信することにより、ZRTP交換を開始します。 Helloメッセージの目的は、エンドポイントは、プロトコルをサポートしていることを確認し、2つのZRTPエンドポイントが共通しているアルゴリズムかを確認することです。
The Hello message contains the SRTP configuration options and the ZID. Each instance of ZRTP has a unique 96-bit random ZRTP ID or ZID that is generated once at installation time. ZIDs are discovered during the Hello message exchange. The received ZID is used to look up retained shared secrets from previous ZRTP sessions with the endpoint.
Helloメッセージには、SRTP設定オプションとZIDが含まれています。 ZRTPの各インスタンスは、インストール時に一度生成される一意の96ビットランダムZRTP IDまたはZIDを有しています。 ZIDsは、Helloメッセージの交換時に発見されています。受信ZIDを見上げるエンドポイントと前回ZRTPセッションから共有秘密を保持するために使用されます。
A response to a ZRTP Hello message is a ZRTP HelloACK message. The HelloACK message simply acknowledges receipt of the Hello. Since RTP commonly uses best effort UDP transport, ZRTP has retransmission timers in case of lost datagrams. There are two timers, both with exponential backoff mechanisms. One timer is used for retransmissions of Hello messages and the other is used for retransmissions of all other messages after receipt of a HelloACK.
ZRTP Helloメッセージに対する応答はZRTP HelloACKメッセージです。 HelloACKメッセージは、単にこんにちはの受信を確認します。 RTPは、一般的に最善の努力UDPトランスポートを使用しているので、ZRTPは、失われたデータグラムの場合は再送タイマを搭載しています。 2つのタイマー、指数バックオフメカニズムとの両方があります。一つのタイマーは、Helloメッセージの再送信のために使用され、他はHelloACKの受領後に他のすべてのメッセージの再送信のために使用されています。
If an integrity-protected signaling channel is available, a hash of the Hello message can be sent. This allows rejection of false ZRTP Hello messages injected by an attacker.
整合性が保護シグナリングチャネルが利用可能な場合は、Helloメッセージのハッシュを送信することができます。これは、攻撃者によって注入された偽のZRTP Helloメッセージの拒否することができます。
Hello and other ZRTP messages also contain a hash image that is used to link the messages together. This allows rejection of false ZRTP messages injected during an exchange.
こんにちは、他のZRTPメッセージも一緒にメッセージをリンクするために使用されるハッシュ画像が含まれています。これは、交換中に注入された偽のZRTPメッセージを拒否することができます。
After both endpoints exchange Hello and HelloACK messages, the key agreement exchange can begin with the ZRTP Commit message. ZRTP supports a number of key agreement modes including both Diffie-Hellman and non-Diffie-Hellman modes as described in the following sections.
両方のエンドポイントがこんにちは、HelloACKメッセージを交換した後、キー合意交換がメッセージをコミットZRTPで始めることができます。 ZRTPは、ディフィー・ヘルマンと、次のセクションで説明するように非のDiffie-Hellmanモードの両方を含む鍵合意モードの数をサポートしています。
The Commit message may be sent immediately after both endpoints have completed the Hello/HelloACK discovery handshake, or it may be deferred until later in the call, after the participants engage in some unencrypted conversation. The Commit message may be manually activated by a user interface element, such as a GO SECURE button, which becomes enabled after the Hello/HelloACK discovery phase. This emulates the user experience of a number of secure phones in the Public Switched Telephone Network (PSTN) world [comsec]. However, it is expected that most simple ZRTP user agents will omit such buttons and proceed directly to secure mode by sending a Commit message immediately after the Hello/HelloACK handshake.
両方のエンドポイントがこんにちは/ HelloACK発見ハンドシェイクを完了した、または参加者は、いくつかの暗号化されていない会話に従事した後、それは、後の呼び出しでまで延期することができる後にコミットメッセージを直ちに送信することができます。コミットメッセージは、手動でそのようなハロー/ HelloACK発見フェーズ後に有効になるGO SECUREボタンなどのユーザインタフェース要素によって活性化され得ます。これは、公共の場での安全な電話機の数のユーザー体験は、電話網（PSTN）世界[COMSEC]を交換エミュレートします。しかし、最も簡単なZRTPのユーザエージェントは、ボタンを省略し、直ちにこんにちは/ HelloACKハンドシェイクの後にコミットメッセージを送信することにより、モードを確保するために直接進むことが期待されます。
An example ZRTP call flow is shown in Figure 1. Note that the order of the Hello/HelloACK exchanges in F1/F2 and F3/F4 may be reversed. That is, either Alice or Bob might send the first Hello message. Note that the endpoint that sends the Commit message is considered the initiator of the ZRTP session and drives the key agreement exchange. The Diffie-Hellman public values are exchanged in the DHPart1 and DHPart2 messages. SRTP keys and salts are then calculated.
例えばZRTPコールフローを図F1 / F2及びF3 / F4にハロー/ HelloACK交換の順序を逆にしてもよいことに留意されたいが示されています。つまり、どちらかアリスまたはボブは最初のHelloメッセージを送信することがあります。コミットメッセージを送信するエンドポイントは、ZRTPセッションのイニシエータとみなされ、鍵合意交換を駆動していることに注意してください。 Diffie-Hellman公開値はDHPart1とDHPart2メッセージで交換されています。 SRTPキーと塩が計算されます。
The initiator needs to generate its ephemeral key pair before sending the Commit, and the responder generates its key pair before sending DHPart1.
イニシエータは、コミット送る前に、その短期キーペアを生成する必要があり、レスポンダはDHPart1を送る前に、その鍵ペアを生成します。
Alice Bob
| |
| Alice and Bob establish a media session. |
| They initiate ZRTP on media ports |
| |
| F1 Hello (version, options, Alice's ZID) |
|-------------------------------------------------->|
| HelloACK F2 |
|<--------------------------------------------------|
| Hello (version, options, Bob's ZID) F3 |
|<--------------------------------------------------|
| F4 HelloACK |
|-------------------------------------------------->|
| |
| Bob acts as the initiator. |
| |
| Commit (Bob's ZID, options, hash value) F5 |
|<--------------------------------------------------|
| F6 DHPart1 (pvr, shared secret hashes) |
|-------------------------------------------------->|
| DHPart2 (pvi, shared secret hashes) F7 |
|<--------------------------------------------------|
| |
| Alice and Bob generate SRTP session key. |
| |
| F8 Confirm1 (MAC, D,A,V,E flags, sig) |
|-------------------------------------------------->|
| Confirm2 (MAC, D,A,V,E flags, sig) F9 |
|<--------------------------------------------------|
| F10 Conf2ACK |
|-------------------------------------------------->|
| SRTP begins |
|<=================================================>|
| |
Figure 1: Establishment of an SRTP Session Using ZRTP
図1：ZRTPを使用してSRTPセッションの確立
ZRTP authentication uses a Short Authentication String (SAS), which is ideally displayed for the human user. Alternatively, the SAS can be authenticated by exchanging an optional digital signature (sig) over the SAS in the Confirm1 or Confirm2 messages (described in Section 7.2).
ZRTP認証は、理想的には、人間のユーザのために表示されるショート認証文字列（SAS）を使用します。あるいは、SAS（セクション7.2を参照）CONFIRM1又はConfirm2メッセージにSAS上にオプションのデジタル署名（SIG）を交換することによって認証することができます。
The ZRTP Confirm1 and Confirm2 messages are sent for a number of reasons, not the least of which is that they confirm that all the key agreement calculations were successful and thus the encryption will work. They also carry other information such as the Disclosure flag (D), the Allow Clear flag (A), the SAS Verified flag (V), and the
ZRTP CONFIRM1とConfirm2のメッセージは、彼らがすべての鍵合意の計算が成功したため、暗号化が動作することを確認することではなく、少なくともその理由の数のために送信されます。彼らはまた、そのような開示フラグ（D）のような他の情報、許可クリアフラグ（A）、SAS認証フラグ（V）、及びキャリー
Private Branch Exchange (PBX) Enrollment flag (E). All flags are encrypted to shield them from a passive observer.
構内交換機（PBX）入学フラグ（E）。すべてのフラグは、受動的観測からそれらを保護するために暗号化されています。
In the Preshared mode, endpoints can skip the DH calculation if they have a shared secret from a previous ZRTP session. Preshared mode is indicated in the Commit message and results in the same call flow as Multistream mode. The principal difference between Multistream mode and Preshared mode is that Preshared mode uses a previously cached shared secret, rs1, instead of an active ZRTP Session key as the initial keying material.
彼らは以前ZRTPセッションから共有秘密を持っている場合は事前共有モードでは、エンドポイントは、DH計算を省略することができます。事前共有モードは、マルチストリームモードと同じコール・フローにコミットメッセージおよび結果が示されています。マルチストリームモードと事前共有モードとの間の主な違いは、事前共有モードではなく、初期鍵材料としてアクティブZRTPセッション鍵の、以前にキャッシュされた共有秘密、RS1を使用することです。
This mode could be useful for slow processor endpoints so that a DH calculation does not need to be performed every session. Or, this mode could be used to rapidly re-establish an earlier session that was recently torn down or interrupted without the need to perform another DH calculation.
DHの計算は、すべてのセッションを実行する必要がないように、このモードでは、遅いプロセッサのエンドポイントのために有用である可能性があります。それとも、このモードでは、近年急速に別のDH計算を実行することなく、取り壊されたり中断された以前のセッションを再確立するために使用することができます。
Preshared mode has forward secrecy properties. If a phone's cache is captured by an opponent, the cached shared secrets cannot be used to recover earlier encrypted calls, because the shared secrets are replaced with new ones in each new call, as in DH mode. However, the captured secrets can be used by a passive wiretapper in the media path to decrypt the next call, if the next call is in Preshared mode. This differs from DH mode, which requires an active MiTM wiretapper to exploit captured secrets in the next call. However, if the next call is missed by the wiretapper, he cannot wiretap any further calls. Thus, it preserves most of the self-healing properties (Section 15.1) of key continuity enjoyed by DH mode.
事前共有モードでは、前進の秘密保持性を有しています。携帯電話のキャッシュは対戦相手によって捕獲されている場合は、共有秘密は、それぞれの新しいコールに新しいものに交換されているので、キャッシュされた共有秘密は、DHモードと同様に、先に暗号化された通話を回復するために使用することはできません。次のコールは、事前共有モードにある場合は、捕捉された秘密は、次の呼び出しを復号するためにメディア経路内に受動的盗聴者によって使用することができます。これは、次の呼び出しでキャプチャ秘密を悪用するアクティブなMITMの盗聴を必要とDHモードとは異なります。次の呼び出しは、盗聴者が見逃している場合は、彼はそれ以上の通話を盗聴することはできません。したがって、それはDHモードで楽しんでキーの連続の自己修復性（15.1）のほとんどを保持します。
Multistream mode is an alternative key agreement method used when two endpoints have an established SRTP media stream between them with an active ZRTP Session key. ZRTP can derive multiple SRTP keys from a single DH exchange. For example, an established secure voice call that adds a video stream uses Multistream mode to quickly initiate the video stream without a second DH exchange.
マルチストリーム・モードは、2つのエンドポイントがアクティブZRTPセッションキーを使用して、それらの間に確立SRTPメディアストリームを持っているときに使用される代替キー合意方式です。 ZRTPは、単一のDH交換から複数のSRTP鍵を導出することができます。例えば、ビデオストリームを追加する確立された安全な音声通話はすぐに二DH交換せずにビデオストリームを開始するために、マルチストリームモードを使用しています。
When Multistream mode is indicated in the Commit message, a call flow similar to Figure 1 is used, but no DH calculation is performed by either endpoint and the DHPart1 and DHPart2 messages are omitted. The Confirm1, Confirm2, and Conf2ACK messages are still sent. Since the cache is not affected during this mode, multiple Multistream ZRTP exchanges can be performed in parallel between two endpoints.
マルチストリームモードがコミットメッセージに示された場合に、図1と同様のコールフローが使用され、ないDH計算は、いずれかのエンドポイントによって実行されず、DHPart1とDHPart2メッセージが省略されています。 CONFIRM1、Confirm2、およびConf2ACKメッセージはまだ送信されます。キャッシュはこのモードの間に影響を受けないため、複数のマルチストリームZRTP交換は、2つのエンドポイント間で並列に実行することができます。
When adding additional media streams to an existing call, only Multistream mode is used. Only one DH operation is performed, just for the first media stream.
既存の通話に追加のメディアストリームを追加する場合、唯一のマルチストリームモードが使用されています。一つだけDH操作は、単に最初のメディアストリームのために、行われます。
This section begins the normative description of the protocol.
このセクションでは、プロトコルの規範的な説明を開始します。
ZRTP MUST be multiplexed on the same ports as the RTP media packets.
ZRTPは、RTPメディアパケットと同じポート上で多重化されなければなりません。
To support best effort encryption from the Media Security Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media lines in the initial offer/answer exchange. The ZRTP SDP attribute a=zrtp-hash defined in Section 8 SHOULD be used in all offers and answers to indicate support for the ZRTP protocol.
メディアセキュリティ要件[RFC5479]からベストエフォートの暗号化をサポートするために、ZRTPは最初のオファー/アンサー交換で通常のRTP / AVPプロファイル（AVP）メディアラインを使用しています。 ZRTP SDPは、第8項に定義されている= ZRTP-ハッシュがZRTPプロトコルのサポートを示すために、すべてのオファーとアンサーで使用されるべきである属性。
ZRTP can be utilized by endpoints that do not have a common signaling protocol but both support SRTP and are relying on a gateway for conversion. As such, it is not always possible for the signaling protocol to relay the zrtp-hash as can be done using SIP.
ZRTPは、共通のシグナリングプロトコルが、両方の支持SRTPを持っていないと変換するためのゲートウェイに依存しているエンドポイントによって利用することができます。このように、SIPを使用して行うことができるように、シグナリングプロトコルはZRTPハッシュを中継するために常に可能ではありません。
The Secure RTP/AVP (SAVP) profile MAY be used in subsequent offer/ answer exchanges after a successful ZRTP exchange has resulted in an SRTP session, or if it is known that the other endpoint supports this profile. Other profiles MAY also be used.
セキュアRTP / AVP（SAVP）プロファイルは、成功したZRTP交換は、SRTPセッションをもたらした後、後続のオファー/アンサー交換に使用してもよいし、他のエンドポイントは、このプロファイルをサポートしていることが分かっている場合。他のプロファイルを使用することもできます。
The use of the RTP/SAVP profile has caused failures in negotiating best effort SRTP due to the limitations on negotiating profiles using SDP. This is why ZRTP supports the RTP/AVP profile and includes its own discovery mechanisms.
RTP / SAVPプロファイルの使用は、SDPを使用して交渉プロファイル上の制限のために最善の努力をSRTPを交渉の失敗を引き起こしました。 ZRTPは、RTP / AVPプロファイルをサポートし、独自の検出メカニズムが含まれて理由です。
In all key agreement modes, the initiator SHOULD NOT send RTP media after sending the Commit message, and it MUST NOT send SRTP media before receiving either the Conf2ACK or the first SRTP media (with a valid SRTP auth tag) from the responder. The responder SHOULD NOT send RTP media after receiving the Commit message, and MUST NOT send SRTP media before receiving the Confirm2 message.
すべての鍵合意モードでは、イニシエータは、コミットメッセージを送信した後、RTPメディアを送るべきではありません、それは応答者から（有効SRTPの認証タグ付き）Conf2ACKまたは最初のSRTPメディアのいずれかを受信する前にSRTPメディアを送ってはいけません。応答者は、コミットメッセージを受信した後、RTPメディアを送るべきではありません、とConfirm2メッセージを受信する前にSRTPメディアを送ってはいけません。
During the ZRTP discovery phase, a ZRTP endpoint discovers if the other endpoint supports ZRTP and the supported algorithms and options. This information is transported in a Hello message, which is described in Section 5.2.
他のエンドポイントがZRTPおよびサポートされているアルゴリズムとオプションをサポートしている場合ZRTP発見フェーズ中に、ZRTPエンドポイントが検出されます。この情報は、セクション5.2で説明されたHelloメッセージに輸送されます。
ZRTP endpoints SHOULD include the SDP attribute a=zrtp-hash in offers and answers, as defined in Section 8.
ZRTPエンドポイントは、第8項に定義されているSDPは、オファーとアンサーに= ZRTP-ハッシュ属性含むべきです。
The Hello message includes the ZRTP version, Hash Type, Cipher Type, SRTP authentication tag type, Key Agreement Type, and Short Authentication String (SAS) algorithms that are supported. The Hello message also includes a hash image as described in Section 9. In addition, each endpoint sends and discovers ZIDs. The received ZID is used later in the protocol as an index into a cache of shared secrets that were previously negotiated and retained between the two parties.
HelloメッセージがサポートされていZRTPバージョン、ハッシュタイプ、暗号種別、SRTP認証タグタイプ、鍵合意の種類、及びショート認証文字列（SAS）アルゴリズムを含みます。また、セクション9に記載されているようにHelloメッセージは、各エンドポイントが送信しZIDsを検出し、ハッシュ画像を含みます。受信ZIDは、以前にネゴシエートと二者の間に保持された共有秘密のキャッシュに後プロトコルのインデックスとして使用されます。
A Hello message can be sent at any time, but it is usually sent at the start of an RTP session to determine if the other endpoint supports ZRTP and also if the SRTP implementations are compatible. A Hello message is retransmitted using timer T1 and an exponential backoff mechanism detailed in Section 6 until the receipt of a HelloACK message or a Commit message.
Helloメッセージはいつでも送ることができますが、通常、SRTP実装に互換性があれば、他のエンドポイントにもZRTPをサポートし、かどうかを判断するためにRTPセッションの開始時に送信されます。 Helloメッセージは、タイマT1とHelloACKメッセージの受信又はコミットメッセージまで、第6節に詳述指数バックオフ・メカニズムを使用して再送されます。
The use of the a=zrtp-hash SDP attribute to authenticate the Hello message is described in Section 8.1.
Helloメッセージを認証するために、A = ZRTPハッシュSDP属性の使用は、8.1節に記述されています。
If a Hello message, or any other ZRTP message, indicates that there is a synchronization source (SSRC) collision, an Error message (Section 5.9) MUST be sent with the Error Code indicating SSRC collision, and the ZRTP negotiation MUST be terminated. The procedures of RFC 3550, Section 8.2 [RFC3550], SHOULD be followed by both endpoints to resolve this condition, and if it is resolved, a new ZRTP secure session SHOULD be negotiated.
Helloメッセージ、または任意の他のZRTPメッセージは、同期ソース（SSRC）衝突があることを示している場合、エラーメッセージ（5.9節）は、SSRC衝突を示すエラーコードを送らなければなりません、とZRTP交渉を終えなければなりません。 RFC 3550、セクション8.2 [RFC3550]の手順は、この状態を解決するために、両方のエンドポイントに続いする必要があり、それが解決された場合、新しいZRTP安全なセッションが交渉されるべきです。
This specification defines ZRTP version 1.10. Since new versions of ZRTP may be developed in the future, this specification defines a protocol version negotiation in this section.
この仕様はZRTPバージョン1.10を定義します。 ZRTPの新しいバージョンは、将来開発される可能性があるので、本明細書は、このセクションのプロトコルバージョンネゴシエーションを定義します。
Each party declares what version of the ZRTP protocol they support via the version field in the Hello message (Section 5.2). If both parties have the same version number in their Hello messages, they can proceed with the rest of the protocol. To facilitate both parties reaching this state of protocol version agreement in their Hello messages, ZRTP should use information provided in the signaling layer, if available. If a ZRTP endpoint supports more than one version of the protocol, it SHOULD declare them all in a list of SIP SDP a=zrtp-hash attributes (defined in Section 8), listing separate hashes, with separate ZRTP version numbers in each item in the list.
各当事者は、彼らがHelloメッセージ（5.2節）でバージョンフィールドを介して支持ZRTPプロトコルのバージョンを宣言します。両当事者がそのHelloメッセージに同じバージョン番号を持っている場合は、プロトコルの残りの部分に進むことができます。利用可能な場合、そのHelloメッセージのプロトコルバージョン契約のこの状態に達し、両当事者を容易にするために、ZRTPは、シグナリング層で提供された情報を使用する必要があります。 ZRTPエンドポイントは、プロトコルの複数のバージョンをサポートしている場合、それは、各項目に別々ZRTPバージョン番号と、別のハッシュをリスト、（8節で定義された）SIP SDPをA = ZRTPハッシュ属性のリストにそれらすべてを宣言する必要がありますリスト。
Both parties should inspect the list of ZRTP version numbers supplied by the other party in the SIP SDP a=zrtp-hash attributes. Both parties SHOULD choose the highest version number that appears in both parties' list of a=zrtp-hash version numbers, and use that version for their Hello messages. If both parties use the SIP signaling in this manner, their initial Hello messages will have the same ZRTP version number, provided they both have at least one supported protocol version in common. Before the ZRTP key agreement can proceed, an endpoint MUST have sent and received Hellos with the same protocol version.
両当事者は、SIP SDP A = ZRTPハッシュ属性で他の当事者によって提供さZRTPバージョン番号のリストを検査する必要があります。両当事者は= ZRTPハッシュバージョン番号の両方の当事者のリストに表示され、最も高いバージョン番号を選択し、そのHelloメッセージのためにそのバージョンを使用する必要があります。両当事者は、このようにSIPシグナリングを使用している場合は、その最初のHelloメッセージは、同じZRTPバージョン番号を持っている彼らの両方が、少なくとも1つの共通のサポートされているプロトコルのバージョンを持って提供します。 ZRTP鍵合意を進めることができます前に、エンドポイントは送信され、同じプロトコルバージョンでハローズを受けていなければなりません。
It is best if the signaling layer is used to negotiate the protocol version number. However, the a=zrtp-hash SDP attribute is not always present in the SIP packet, as explained in Section 8.1. In the absence of any guidance from the signaling layer, an endpoint MUST send the highest supported version in initial Hello messages. If the two parties send different protocol version numbers in their Hello messages, they can reach an agreement to use a common version, if one exists. They iteratively apply the following rules until they both have matching version fields in their Hello messages and the key agreement can proceed:
シグナリング層はプロトコルのバージョン番号を交渉するために使用することが最良の方法です。 8.1節で説明したようただし、A = ZRTPハッシュSDP属性は、常にSIPパケットに存在しません。シグナリング層からの任意の指導がない場合には、エンドポイントは、最初のHelloメッセージに最高のサポートバージョンを送らなければなりません。 2人の当事者がそのHelloメッセージに異なるプロトコルバージョン番号を送信する場合が存在する場合、それらは、一般的なバージョンを使用することで合意に達することができます。両者が一致するバージョンフィールドを持つまで、彼らは繰り返し彼らのHelloメッセージに次のルールを適用し、鍵合意を進めることができます。
o If an endpoint receives a Hello message with an unsupported version number that is higher than the endpoint's current Hello message version, the received Hello message MUST be ignored. The endpoint continues to retransmit Hello messages on the standard retry schedule (Section 6).
エンドポイントは、エンドポイントの現在のHelloメッセージのバージョンよりも高くなっている、サポートされていないバージョン番号のHelloメッセージを受信した場合、O、こんにちは受信したメッセージは無視しなければなりません。エンドポイントは、標準の再試行スケジュール（第6節）にHelloメッセージを再送し続けています。
o If an endpoint receives a Hello message with a version number that is lower than the endpoint's current Hello message, and the endpoint supports a version that is less than or equal to the received version number, the endpoint MUST stop retransmitting the old version number and MUST start sending a Hello message with the highest supported version number that is less than or equal to the received version number.
エンドポイントは、エンドポイントの現在のHelloメッセージよりも低いバージョン番号のHelloメッセージを受信して、エンドポイントは、受信したバージョン番号以下のバージョンをサポートしている場合は、O、エンドポイントは、古いバージョン番号を再送停止しなければなりません。受信されたバージョン番号以下である最高のサポートされているバージョン番号とHelloメッセージの送信を開始しなければなりません。
o If an endpoint receives a Hello message with an unsupported version number that is lower than the endpoint's current Hello message, the endpoint MUST send an Error message (Section 5.9) indicating failure to support this ZRTP version.
エンドポイントは、エンドポイントの現在のHelloメッセージよりも低くなっている、サポートされていないバージョン番号のHelloメッセージを受信した場合、O、エンドポイントはこのZRTPバージョンをサポートするために失敗したことを示すエラーメッセージ（5.9節）を送らなければなりません。
The above comparisons are iterated until the version numbers match, or until it exits on a failure to match.
上記の比較は、バージョン番号が一致するまで反復されている、またはそれが失敗した場合に終了するまで一致します。
For example, assume that Alice supports protocol versions 1.10 and 2.00, and Bob supports versions 1.10 and 1.20. Alice initially sends a Hello with version 2.00, and Bob initially sends a Hello with version 1.20. Bob ignores Alice's 2.00 Hello and continues to send his 1.20 Hellos. Alice detects that Bob does not support 2.00 and she stops sending her 2.00 Hellos and starts sending a stream of 1.10 Hellos. Bob sees the 1.10 Hello from Alice and stops sending his 1.20 Hellos and switches to sending 1.10 Hellos.
例えば、アリスがプロトコルバージョン1.10および2.00をサポートしており、ボブはバージョン1.10および1.20をサポートすると仮定する。アリスは最初はバージョン2.00でのHelloを送信し、ボブは最初のバージョン1.20でのHelloを送信します。ボブはアリスの2.00こんにちはを無視し、彼の1.20 helloを送信し続けます。アリスはボブが2.00をサポートしていないことを検出し、彼女は彼女の2.00ハローズの送信を停止し、1.10ハローズのストリームの送信を開始します。ボブがアリスから1.10こんにちはを見て、1.10 helloを送信する彼の1.20ハローズとスイッチの送信を停止します。
At that point, they have converged on using version 1.10 and the protocol proceeds on that basis.
その時点で、彼らはそれに基づいて、バージョン1.10およびプロトコルが進行を使用して収束しました。
When comparing protocol versions, a ZRTP endpoint MUST include only the first three octets of the version field in the comparison. The final octet is ignored, because it is not significant for interoperability. For example, "1.1 ", "1.10", "1.11", or "1.1a" are all regarded as a version match, because they would all be interoperable versions.
プロトコルバージョンを比較すると、ZRTPエンドポイントを比較して、バージョンフィールドの最初の3つのオクテットを含まなければなりません。それは、相互運用性のために重要ではありませんので、最後のオクテットが、無視されます。例えば、「1.1」、「1.10」、「1.11」、またはそれらはすべて相互運用可能なバージョンになるので、「1.1A」は全て、バージョン一致とみなされます。
Changes in protocol version numbers are expected to be infrequent after version 1.10. Supporting multiple versions adds code complexity and may introduce security weaknesses in the implementation. The old adage about keeping it simple applies especially to implementing security protocols. Endpoints SHOULD NOT support protocol versions earlier than version 1.10.
プロトコルバージョン番号の変更は、バージョン1.10の後にまれされることが期待されます。複数のバージョンをサポートするコードの複雑さを追加し、実装におけるセキュリティ上の弱点を導入することができます。それをシンプルに保つことについての古い格言は、特にセキュリティプロトコルの実装に適用されます。エンドポイントは、バージョン1.10より前のバージョンのプロトコルをサポートすべきではありません。
A method is provided to allow the two parties to mutually and deterministically choose the same DH key size and algorithm before a Commit message is sent.
この方法は、二つの当事者が相互に確定コミットメッセージが送信される前に同じDHキーサイズおよびアルゴリズムを選択することを可能にするために提供されます。
Each Hello message lists the algorithms in the order of preference for that ZRTP endpoint. Endpoints eliminate the non-intersecting choices from each of their own lists, resulting in each endpoint having a list of algorithms in common that might or might not be ordered the same as the other endpoint's list. Each endpoint compares the first item on their own list with the first item on the other endpoint's list and SHOULD choose the faster of the two algorithms. For example:
各Helloメッセージは、そのZRTPエンドポイントの優先順にアルゴリズムを示します。エンドポイントは、または他のエンドポイントのリストと同じように注文できない場合があります共通アルゴリズムのリストを持つ各エンドポイントで、その結果、自分のリストのそれぞれから非交差の選択肢を排除します。各エンドポイントは、他のエンドポイントのリストの最初の項目で自分のリストの最初の項目を比較し、2つのアルゴリズムの高速化を選択する必要があります。例えば：
o Alice's full list: DH2k, DH3k, EC25
Oアリスの完全なリスト：DH2k、DH3k、EC25
o Bob's full list: EC38, EC25, DH3k
Oボブの完全なリスト：EC38、EC25、DH3k
o Alice's intersecting list: DH3k, EC25
アリスの交差リストO：DH3k、EC25
o Bob's intersecting list: EC25, DH3k
Oボブの交差リスト：EC25、DH3k
o Alice's first choice is DH3k, and Bob's first choice is EC25.
Oアリスの最初の選択肢はDH3kで、ボブの最初の選択肢は、EC25あります。
o Thus, both parties choose EC25 (ECDH-256) because it's faster.
それは高速ですので、Oこのように、両当事者は、EC25（ECDH-256）を選択します。
To decide which DH algorithm is faster, the following ranking, from fastest to slowest is defined: DH-2048, ECDH-256, DH-3072, ECDH-384, ECDH-521. These are all defined in Section 5.1.5.
最も遅いが定義されている最速のに、より高速であるDHアルゴリズム以下の順位を決定するには：DH-2048、ECDH-256、DH-3072、ECDH-384、ECDH-521。これらはすべて、第5.1.5項で定義されています。
If both endpoints follow this method, they may each start their DH calculations as soon as they receive the Hello message, and there will be no need for either endpoint to discard their DH calculation if the other endpoint becomes the initiator.
両方のエンドポイントが、この方法に従えば、彼らはHelloメッセージを受け取ると、彼らはそれぞれ、すぐに彼らのDHの計算を開始することができ、そして他のエンドポイントがイニシエータになった場合、エンドポイントのいずれかが自分のDH計算を破棄するために必要はありません。
This method is used only to negotiate DH key size. For the rest of the algorithm choices, it's simply whatever the initiator selects from the algorithms in common. Note that the DH key size influences the Hash Type and the size of the symmetric cipher key, as explained in Section 5.1.5.
この方法では、DHキーサイズを交渉するためにのみ使用されます。アルゴリズムの選択肢の残りの部分については、それは、イニシエータが共通のアルゴリズムから選択どんな単純です。セクション5.1.5で説明したように、DHキーサイズは、ハッシュタイプ及び対称暗号鍵のサイズに影響を与えることに留意されたいです。
Unfavorable choices will never be made by this method, because each endpoint will omit from their respective lists choices that are too slow or not secure enough to meet their security policy.
各エンドポイントがセキュリティポリシーを満たすのに十分確保遅すぎるかではない、それぞれのリストの選択肢から省略されますので、不利な選択肢は、この方法によって作られることはありません。
After both parties have received compatible Hello messages, a Commit message (Section 5.4) can be sent to begin the ZRTP key exchange. The endpoint that sends the Commit is known as the initiator, while the receiver of the Commit is known as the responder.
両当事者は、互換性のあるHelloメッセージを受信した後、コミットメッセージ（5.4節）はZRTP鍵交換を開始するために送信することができます。コミットの受信機は応答として知られているがコミット送信エンドポイントが、開始剤として知られています。
If both sides send Commit messages initiating a secure session at the same time, the following rules are used to break the tie:
両側が同時に安全なセッションを開始するメッセージをコミット送信する場合、次の規則がネクタイを破るために使用されます。
o If one Commit is for a DH mode while the other is for Preshared mode, then the Preshared Commit MUST be discarded and the DH Commit proceeds.
他の事前共有モードにある間に一方がDHモードである場合コミットO、次いで事前共有を捨てなければならないコミットおよびDHは、移行をコミット。
o If the two Commits are both Preshared mode, and one party has set the MiTM (M) flag in the Hello message and the other has not, the Commit message from the party who set the (M) flag MUST be discarded, and the one who has not set the (M) flag becomes the initiator, regardless of the nonce values. In other words, for Preshared mode, the phone is the initiator and the PBX is the responder.
O 2つのコミットは、事前共有モードの両方であり、一方の当事者は、HelloメッセージにMITM（M）フラグを設定しており、他方は、（M）を設定する当事者からのメッセージをコミットフラグを捨てなければなりませんしていない場合、および（M）フラグを設定していないものに関わらず、ノンス値、イニシエータとなります。換言すれば、事前共有モードのために、電話が開始され、PBXは、レスポンダです。
o If the two Commits are either both DH modes or both non-DH modes, then the Commit message with the lowest hvi (hash value of initiator) value (for DH Commits), or lowest nonce value (for non-DH Commits), MUST be discarded and the other side is the initiator, and the protocol proceeds with the initiator's Commit. The two hvi or nonce values are compared as large unsigned integers in network byte order.
2つのコミットはDHモードまたは両方の非DHのモードのいずれかの両方がある場合は、O、次いで（非DHコミットするための）最小HVIのメッセージ、または最低のナンス値（DHコミット用）（イニシエータのハッシュ値）の値をコミット廃棄および他の側面は、イニシエータであり、および開始剤の持つプロトコル進み、コミットされなければなりません。 2つのHVI又はノンス値はネットワークバイト順に大きい符号なし整数として比較されます。
If one Commit is for Multistream mode while the other is for non-Multistream (DH or Preshared) mode, a software error has occurred and the ZRTP negotiation should be terminated. This should never occur because of the constraints on Multistream mode described in Section 4.4.3.
1は、コミットした場合、他の非マルチストリーム（DHまたは事前共有）モード用で、ソフトウェアエラーが発生したとZRTPネゴシエーションが終了されるべきであるマルチストリームモードです。これは、4.4.3項で説明したマルチストリームモードでの制約のために発生することはありません。
In the event that Commit messages are sent by both ZRTP endpoints at the same time, but are received in different media streams, the same resolution rules apply as if they were received on the same stream. The media stream in which the Commit was received or sent will proceed through the ZRTP exchange while the media stream with the discarded Commit must wait for the completion of the other ZRTP exchange.
それらが同じストリームで受信されたかのようにメッセージが同時に両方ZRTPエンドポイントによって送信されたコミットが、異なるメディアストリームで受信された場合に、同じ解像度の規則が適用されます。廃棄コミット付きメディア・ストリームは、他ZRTP交換の完了を待つ必要がありながら、コミットが受信または送信されたメディアストリームはZRTP交換によって進行します。
If a commit contention forces a DH Commit message to be discarded, the responder's DH public value should only be discarded if it does not match the initiator's DH key size. This will not happen if both endpoints choose a common key size via the method described in Section 4.1.2.
コミット競合がDHを廃棄するメッセージをコミット強制した場合、それは、イニシエータのDHキーサイズと一致しない場合、応答者のDH公開値は破棄されなければなりません。両方のエンドポイントが4.1.2項で説明した方法を介して共通鍵のサイズを選択した場合、これは発生しません。
The following sections describe how ZRTP endpoints generate and/or use the set of shared secrets s1, auxsecret, and pbxsecret through the exchange of the DHPart1 and DHPart2 messages. This doesn't cover the Diffie-Hellman calculations. It only covers the method whereby the two parties determine if they already have shared secrets in common in their caches.
次のセクションでは、ZRTPエンドポイントが生成および/またはDHPart1とDHPart2メッセージの交換を介して共有秘密S1、auxsecret、およびpbxsecretのセットを使用する方法について説明します。これは、のDiffie-Hellman計算をカバーしていません。それだけで、彼らはすでに自分のキャッシュに共通する秘密を共有している場合は両当事者が決定する方式をカバーしています。
Each ZRTP endpoint maintains a long-term cache of shared secrets that it has previously negotiated with the other party. The ZID of the other party, received in the other party's Hello message, is used as an index into this cache to find the set of shared secrets, if any exist. This cache entry may contain previously retained shared secrets, rs1 and rs2, which give ZRTP its key continuity features. If the other party is a PBX, the cache may also contain a trusted MiTM PBX shared secret, called pbxsecret, defined in Section 7.3.1.
各ZRTPエンドポイントは、それが以前に他の相手と交渉した共有秘密の長期的なキャッシュを保持します。が存在する場合、相手のHelloメッセージで受信した相手のZIDは、共有秘密のセットを見つけるために、このキャッシュへのインデックスとして使用されています。このキャッシュエントリは、以前ZRTPにそのキーの連続性の機能を与える共有秘密、RS1とRS2を、保持含まれていてもよいです。相手がPBXである場合は、キャッシュも含まれていてもよい、信頼できるMITM PBXは、7.3.1項で定義され、pbxsecretと呼ばれる、秘密を共有しました。
The DHPart1 and DHPart2 messages contain a list of hashes of these shared secrets to allow the two endpoints to compare the hashes with what they have in their caches to detect whether the two sides share any secrets that can be used in the calculation of the session key. The use of this shared secret cache is described in Section 4.9.
DHPart1とDHPart2メッセージは、2つのエンドポイントが2つの側面が、セッション鍵の計算に使用することができます任意の秘密を共有するかどうかを検出するために、彼らはそれらのキャッシュに持っているものでハッシュを比較することができるように、これらの共有秘密のハッシュのリストが含まれています。この共有秘密キャッシュの使用は、セクション4.9に記載されています。
If no secret of a given type is available, a random value is generated and used for that secret to ensure a mismatch in the hash comparisons in the DHPart1 and DHPart2 messages. This prevents an eavesdropper from knowing which types of shared secrets are available between the endpoints.
指定された型の秘密が利用できない場合は、ランダムな値が生成され、DHPart1とDHPart2メッセージ内のハッシュ比較の不一致を確実にするためにその秘密のために使用されています。これは、エンドポイント間で利用可能な共有秘密のタイプを知ることから、盗聴を防止します。
Section 4.3.1 refers to the auxiliary shared secret auxsecret. The auxsecret shared secret may be defined by the VoIP user agent out-of-band from the ZRTP protocol. In some cases, it may be provided by the signaling layer as srtps, which is defined in Section 8.2. If it is not provided by the signaling layer, the auxsecret shared secret may be manually provisioned in other application-specific ways that are out of band, such as computed from a hashed pass phrase by prior agreement between the two parties or supplied by a hardware token. Or, it may be a family key used by an institution to which the two parties both belong. It is a generalized mechanism for providing a shared secret that is agreed to between the two parties out of scope of the ZRTP protocol. It is expected that most typical ZRTP endpoints will rarely use auxsecret.
4.3.1項は、補助共有秘密auxsecretを指します。 auxsecret共有秘密はZRTPプロトコルからアウトオブバンドのVoIPユーザエージェントによって定義されてもよいです。場合によっては、セクション8.2で定義されsrtps、としてシグナリング層によって提供されてもよいです。それはシグナリング層によって提供されない場合、auxsecret共有秘密は、手動で、このような二者間の事前の合意によってハッシュパスフレーズから計算又はハードウェアにより供給される帯域外の他のアプリケーション固有の方法でプロビジョニングすることができますトークン。それとも、それは両当事者の双方が属する機関で使用される家族の鍵となることがあります。それはZRTPプロトコルの範囲のうち2者間で合意された共有シークレットを提供するための一般的なメカニズムです。最も典型的なZRTPエンドポイントはめったにauxsecret使用しないことが期待されます。
For both the initiator and the responder, the shared secrets s1, s2, and s3 will be calculated so that they can all be used later to calculate s0 in Section 4.4.1.4. Here is how s1, s2, and s3 are calculated by both parties.
彼らはすべてのセクション4.4.1.4にS0を計算するために、後で使用できるように、イニシエータとレスポンダの両方のために、共有秘密S1、S2、S3が計算されます。ここで、S1、S2、およびS3は、両当事者によって計算されている方法です。
The shared secret s1 will be either the initiator's rs1 or the initiator's rs2, depending on which of them can be found in the responder's cache. If the initiator's rs1 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs1. If and only if that match fails, then if the initiator's rs2 matches the responder's rs1 or rs2, then s1 MUST be set to the initiator's rs2. If that match also fails, then s1 MUST be set to null. The complexity of the s1 calculation is to recover from any loss of cache sync from an earlier aborted session, due to the Two Generals' Problem [Byzantine].
共有秘密s1は、応答のキャッシュで見つけることができるそれらのどれに応じて、イニシエータのRS1またはイニシエータのRS2のいずれかになります。イニシエータのRS1は、応答者のRS1またはRS2と一致する場合、s1は、イニシエータのRS1に設定しなければなりません。そのマッチが失敗した場合のみとし、イニシエータのRS2は、応答者のRS1またはRS2に一致した場合場合、s1は、イニシエータのRS2に設定しなければなりません。その試合でも失敗した場合、s1がnullに設定しなければなりません。 S1の計算の複雑さが原因[ビザンチン]二人の将軍問題に、早く中止されたセッションからキャッシュの同期の損失から回復することです。
The shared secret s2 MUST be set to the value of auxsecret if and only if both parties have matching values for auxsecret, as determined by comparing the hashes of auxsecret sent in the DH messages. If they don't match, s2 MUST be set to null.
共有秘密S2はauxsecretの値に設定する必要がある場合とDHメッセージで送信auxsecretのハッシュを比較することによって決定されるように、両当事者は、auxsecretためのマッチング値を有する場合にのみ。それらが一致しない場合は、s2がnullに設定しなければなりません。
The shared secret s3 MUST be set to the value of pbxsecret if and only if both parties have matching values for pbxsecret, as determined by comparing the hashes of pbxsecret sent in the DH messages. If they don't match, s3 MUST be set to null.
共有秘密S3はpbxsecretの値に設定する必要がある場合とDHメッセージで送信pbxsecretのハッシュを比較することによって決定されるように、両当事者は、pbxsecretためのマッチング値を有する場合にのみ。それらが一致しない場合は、s3がnullに設定しなければなりません。
If s1, s2, or s3 have null values, they are assumed to have a zero length for the purposes of hashing them later during the s0 calculation in Section 4.4.1.4.
S1、S2、またはS3がNULL値を有する場合、それらは、セクション4.4.1.4においてS0計算中に、後でそれらをハッシュする目的のためにゼロの長さを有すると仮定されています。
The comparison of hashes of rs1, rs2, auxsecret, and pbxsecret is described in Section 4.3.1.
RS1、RS2、auxsecret、及びpbxsecretのハッシュの比較は、セクション4.3.1に記載されています。
Both parties calculate a set of non-invertible hashes (implemented via the MAC defined in Section 5.1.2.1) of shared secrets that may be present in each of their caches. These hashes are truncated to the leftmost 64 bits:
両当事者は、それらのキャッシュのそれぞれに存在することができる共有秘密の（セクション5.1.2.1で定義されたMACを介して実装される）、非可逆ハッシュのセットを計算します。これらのハッシュは、左端の64ビットに切り捨てられます。
rs1IDr = MAC(rs1, "Responder")
rs1IDr = MAC（RS1、 "返信"）
rs2IDr = MAC(rs2, "Responder")
rs2IDr = MAC（RS2、 "返信"）
auxsecretIDr = MAC(auxsecret, Responder's H3)
auxsecretIDr = MAC（auxsecret、レスポンダのH3）
pbxsecretIDr = MAC(pbxsecret, "Responder")
pbxsecretIDr = MAC（pbxsecret、 "返信"）
rs1IDi = MAC(rs1, "Initiator")
rs1IDi = MAC（RS1、 "イニシエータ"）
rs2IDi = MAC(rs2, "Initiator")
rs2IDi = MAC（RS2、 "イニシエータ"）
auxsecretIDi = MAC(auxsecret, Initiator's H3)
auxsecretIDi = MAC（auxsecret、イニシエータのH3）
pbxsecretIDi = MAC(pbxsecret, "Initiator")
pbxsecretIDi = MAC（pbxsecret、 "イニシエータ"）
The responder sends rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr in the DHPart1 message. The initiator sends rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi in the DHPart2 message.
レスポンダはDHPart1メッセージにrs1IDr、rs2IDr、auxsecretIDr、およびpbxsecretIDrを送信します。イニシエータはDHPart2メッセージにrs1IDi、rs2IDi、auxsecretIDi、およびpbxsecretIDiを送信します。
The responder uses the locally computed rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi to compare against the corresponding fields in the received DHPart2 message. The initiator uses the locally computed rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr to compare against the corresponding fields in the received DHPart1 message.
レスポンダは、局所的に計算rs1IDi、rs2IDi、auxsecretIDi、及びpbxsecretIDiが受信DHPart2メッセージの対応するフィールドと比較するために使用します。開始剤は、局所的に計算rs1IDr、rs2IDr、auxsecretIDr、及びpbxsecretIDrが受信DHPart1メッセージの対応するフィールドと比較するために使用します。
From these comparisons, s1, s2, and s3 are calculated per the methods described in Section 4.3. The secrets corresponding to matching hashes are kept while the secrets corresponding to the non-matching ones are replaced with a null, which is assumed to have a zero length for the purposes of hashing them later. The resulting s1, s2, and s3 values are used later to calculate s0 in Section 4.4.1.4.
これらの比較から、S1、S2、S3は4.3節で説明した方法ごとに計算されます。非マッチングのものに対応する秘密は、後でそれらをハッシュの目的のためにゼロの長さを有すると仮定されているヌルで置換されている間に一致ハッシュに対応する秘密が保持されます。得られたS1、S2、およびS3の値は、セクション4.4.1.4でS0を計算するために後で使用されます。
For example, consider two ZRTP endpoints who share secrets rs1 and pbxsecret (defined in Section 7.3.1). During the comparison, rs1ID and pbxsecretID will match but auxsecretID will not. As a result, s1 = rs1, s2 will be null, and s3 = pbxsecret.
例えば、秘密のRS1とpbxsecret（7.3.1項で定義される）を共有する2つのZRTPエンドポイントを考えてみましょう。比較の際、rs1IDとpbxsecretIDは一致しますが、auxsecretIDはしません。その結果、S1 = RS1、S2およびS3 = pbxsecret、nullになります。
A shared secret cache mismatch is defined to mean that we expected a cache match because rs1 exists in our local cache, but we computed a null value for s1 (per the method described in Section 4.3).
共有秘密キャッシュ不一致はRS1は、私たちのローカルキャッシュに存在しますが、我々は（4.3節に記載した方法につき）S1にnull値を算出しているため、我々はキャッシュの試合を予想することを意味すると定義されます。
If one party has a cached shared secret and the other party does not, this indicates one of two possible situations. Either there is a MiTM attack or one of the legitimate parties has lost their cached shared secret by some mishap. Perhaps they inadvertently deleted their cache or their cache was lost or disrupted due to restoring their disk from an earlier backup copy. The party that has the surviving cache entry can easily detect that a cache mismatch has occurred, because they expect their own cached secret to match the other party's cached secret, but it does not match. It is possible for both parties to detect this condition if both parties have surviving cached secrets that have fallen out of sync, due perhaps to one party restoring from a disk backup.
一方の当事者がキャッシュされた共有秘密を持っているし、相手がいない場合、これは、2つの可能な状況のいずれかを示します。いずれかのいくつかの事故によりそのキャッシュされた共有秘密を失ったMITM攻撃または正当な当事者の一方があります。おそらく彼らは、うっかり自分のキャッシュを削除したり、キャッシュが原因以前のバックアップコピーから自分のディスクを復元するために失われたり破壊されました。彼らは自分のキャッシュされた秘密は相手のキャッシュされた秘密と一致することを期待するので生き残ったキャッシュエントリを持つ当事者は簡単に、キャッシュの不一致が発生したことを検出することができるが、それは一致していません。両当事者は、ディスクバックアップからの復元1つのパーティにおそらく、同期がずれて下落しているキャッシュされた秘密を存続している場合は、両方の当事者がこの状態を検出することが可能です。
If either party discovers a cache mismatch, the user agent who makes this discovery must treat this as a possible security event and MUST alert their own user that there is a heightened risk of a MiTM attack, and that the user should verbally compare the SAS with the other party to ascertain that no MiTM attack has occurred. If a cache mismatch is detected and it is not possible to compare the SAS, either because the user interface does not support it or because one or both endpoints are unmanned devices, and no other SAS comparison mechanism is available, the session MAY be terminated.
いずれかの当事者がキャッシュの不一致が検出された場合は、この発見を行い、ユーザエージェントは、可能なセキュリティイベントとしてこれを扱わなければなりませんし、MITM攻撃の高まり危険性があることが、自分のユーザーに警告しなければならない、とユーザーが口頭でSASを比較するべきです他の当事者にはMITM攻撃が発生していないことを確認します。キャッシュの不一致が検出され、ユーザーインターフェイスがそれをサポートしていないか、一方または両方のエンドポイントが無人装置であり、他のSAS比較メカニズムが利用できないため、セッションが終了することができるいずれかのためには、SASを比較することはできませんされている場合。
The session need not be terminated on a cache mismatch event if:
セッションがあれば、キャッシュの不一致のイベントで終了する必要はありません。
o the mechanism described in Section 8.1.1 is available, which allows authentication of the DH exchange without human assistance, or
Oセクション8.1.1で説明されたメカニズムは、人間の援助なしDH交換の認証を可能にする、利用可能であり、又は
o any mechanism is available to determine if the SAS matches. This would require either circumstances that allow human verbal comparisons of the SAS or by use of the OPTIONAL digital signature feature on the SAS hash, as described in Section 7.2.
O任意の機構は、SASが一致するかどうかを決定するために利用可能です。これは、セクション7.2に記載されているように、SASまたはSASハッシュにオプションのデジタル署名機能を用いて、ヒト口頭での比較を可能にするいずれかの状況を必要とするであろう。
Even if the user interface does not permit an SAS comparison, the human user MUST be warned and may elect to proceed with the call at their own risk.
ユーザーインターフェイスはSASの比較を許可しない場合であっても、人間のユーザは警告されなければならないし、自分の責任で呼び出しを続行することを選択できます。
If and only if a cache mismatch event occurs, the cache update mechanism in Section 4.6.1 is affected, requiring the user to verify the SAS before the cache is updated. The user will thus be alerted of this security condition on every call until the SAS is verified.
キャッシュの不一致のイベントが発生した場合にのみ及び、4.6.1項のキャッシュ更新メカニズムが影響を受けている場合は、キャッシュが更新される前に、ユーザーが必要とすることはSASを確認します。 SASが確認されるまで、ユーザは、このようにすべての呼び出しで、このセキュリティ状態を警告します。
This is described in Section 4.6.1.1.
これは、セクション4.6.1.1に記載されています。
Here is a non-normative example of a cache-mismatch alert message from a ZRTP user agent (specifically, [Zfone]), designed for a desktop PC graphical user interface environment. It is by no means required that the alert be this detailed:
ここでは、デスクトップPCのグラフィカルユーザインタフェース環境用に設計されたZRTPユーザエージェントからのキャッシュ・不一致の警告メッセージ（具体的には、[Zfone]）、非規範的な例です。これは、アラートは、この詳細なことが要求されるものではありません。
We expected the other party to have a shared secret cached from a previous call, but they don't have it. This may mean your partner simply lost his cache of shared secrets, but it could also mean someone is trying to wiretap you. To resolve this question you must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper.
私たちは前の呼び出しからのキャッシュされた共有秘密を持っている相手に期待が、彼らはそれを持っていません。これはあなたのパートナーが簡単に共有秘密の彼のキャッシュを失っ意味するかもしれないが、それはまた誰かがあなたを盗聴しようとしている意味するかもしれません。この疑問を解決するために、あなたのパートナーと認証文字列をチェックする必要があります。それが一致しない場合、それは盗聴者の存在を示します。
If the alert is rendered by a robot voice instead of a GUI, brevity may be more important:
アラートが代わりにGUIのロボット声でレンダリングされている場合は、簡潔には、より重要であるかもしれません。
Something's wrong. You must check the authentication string with your partner. If it doesn't match, it indicates the presence of a wiretapper.
何かが間違っているのです。あなたはあなたのパートナーと認証文字列をチェックする必要があります。それが一致しない場合、それは盗聴者の存在を示します。
A mismatch of auxsecret is handled differently than a mismatch of rs1. An auxsecret mismatch is defined to mean that auxsecret exists locally, but we computed a null value for s2 (per the method described in Section 4.3). This mismatch should be made visible to whichever user has auxsecret defined. The mismatch should be made visible to both users if they both have auxsecret defined but they fail to match. The severity of the user notification is implementation dependent. Aborting the session is not required. If auxsecret matches, it should not excuse a mismatch of rs1, which still requires a strong warning to the user.
auxsecretの不一致は、RS1の不一致とは異なる方法で処理されます。 auxsecret不一致はそのauxsecretがローカルに存在を意味するように定義されたが、我々は（4.3節に記載した方法につき）S2にnull値を算出しています。このミスマッチは、定義されたauxsecretた方のユーザーに表示されるべきです。彼らの両方が定義auxsecretているが、それらが一致しない場合、ミスマッチは、両方のユーザーに表示されるべきです。ユーザ通知の重症度は実装依存です。セッションを中止する必要はありません。 auxsecret一致した場合、それはまだ、ユーザーへの強い警告を必要とRS1の不一致を、言い訳ではないはずです。
The next step is the generation of a secret for deriving SRTP keying material. ZRTP uses Diffie-Hellman and two non-Diffie-Hellman modes, described in the following subsections.
次のステップは、SRTPキーイング材料を導出するための秘密の世代です。 ZRTPは、ディフィー - ヘルマン、以下のサブセクションで説明した2つの非のDiffie-Hellmanモードを使用します。
The purpose of the Diffie-Hellman (either Finite Field Diffie-Hellman or Elliptic Curve Diffie-Hellman) exchange is for the two ZRTP endpoints to generate a new shared secret, s0. In addition, the endpoints discover if they have any cached or previously stored shared secrets in common, and it uses them as part of the calculation of the session keys.
ディフィー・ヘルマン（有限フィールドディフィー・ヘルマン又は楕円曲線ディフィー・ヘルマン鍵共有のいずれか）交換の目的は、二つのZRTPエンドポイントは、S0を新しい共有秘密を生成するためのものです。彼らは共通のいずれかのキャッシュまたは以前に格納された共有秘密を持っている場合、また、エンドポイントが発見し、それがセッションキーの計算の一部としてそれらを使用しています。
Because the DH exchange affects the state of the retained shared secret cache, only one in-process ZRTP DH exchange may occur at a time between two ZRTP endpoints. Otherwise, race conditions and cache integrity problems will result. When multiple media streams are established in parallel between the same pair of ZRTP endpoints (determined by the ZIDs in the Hello messages), only one can be processed. Once that exchange completes with Confirm2 and Conf2ACK messages, another ZRTP DH exchange can begin. This constraint does not apply when Multistream mode key agreement is used since the cached shared secrets are not affected.
DH交換が保持共有秘密キャッシュの状態に影響を与えるため、唯一のインプロセスZRTPのDH交換は2つのZRTPエンドポイント間の時間に発生する可能性があります。それ以外の場合は、競合状態とキャッシュの整合性の問題が発生します。複数のメディアストリームが（HelloメッセージにZIDsによって決定される）ZRTPエンドポイントの同じ対の間に並列に確立されている場合、一方のみを処理することができます。その交換がConfirm2とConf2ACKメッセージを完了すると、別のZRTPのDH交換を開始することができます。キャッシュされた共有秘密が影響を受けないので、マルチストリームモードキー契約が使用されている場合は、この制約は適用されません。
From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used.
送受信Helloメッセージにおけるアルゴリズムの交点から、開始剤が使用されるハッシュ、暗号、認証タグ、鍵合意の種類、およびSASタイプを選択します。
A Diffie-Hellman mode is selected by setting the Key Agreement Type in the Commit to one of the DH or Elliptic Curve Diffie-Hellman (ECDH) values from the table in Section 5.1.5. In this mode, the key agreement begins with the initiator choosing a fresh random Diffie-Hellman (DH) secret value (svi) based on the chosen Key Agreement Type value, and computing the public value. (Note that to speed up processing, this computation can be done in advance.) For guidance on generating random numbers, see Section 4.8.
ディフィー・ヘルマンモードは、セクション5.1.5の表からDH又は楕円曲線ディフィ - ヘルマン（ECDH）のいずれかの値にコミットにおける鍵協定の種類を設定することによって選択されます。このモードでは、鍵の合意は、イニシエータが選ばれた鍵合意Type値に基づいて、新鮮なランダムのDiffie-Hellmanの（DH）秘密値（SVI）を選択し、公共の値を計算することから始まります。 （処理をスピードアップすることに注意してください、この計算は、事前に行うことができます。）ガイダンスについては乱数を生成するには、4.8節を参照してください。
For Finite Field Diffie-Hellman, the value for the DH generator g, the DH prime p, and the length of the DH secret value, svi, are defined in Section 5.1.5.
有限フィールドディフィー - ヘルマン、DHジェネレータg、DH素数p、およびDH秘密値、SVIの長さの値については、セクション5.1.5で定義されています。
pvi = g^svi mod p
PVIがg ^モッズP部門を=
where g and p are determined by the Key Agreement Type value. The DH public value pvi value is formatted as a big-endian octet string and fixed to the bit-length of the DH prime; leading zeros MUST NOT be truncated.
gであり、pが鍵合意Type値によって決定されます。 DHパブリック値PVI値は、ビッグエンディアンオクテット文字列としてフォーマットされ、プライムDHのビット長に固定されています。先頭のゼロは切り捨ててはなりません。
For Elliptic Curve DH, pvi is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A [NIST-SP800-56A].
楕円曲線DHため、PVIは、NIST SP 800-56A [NIST-SP800-56A]の特定の部分を詳細に参照し、セクション5.1.5におけるECDH仕様に従って計算し、フォーマットされています。
The hash commitment is performed by the initiator of the ZRTP exchange. The hash value of the initiator, hvi, includes a hash of the entire DHPart2 message as shown in Figure 9 (which includes the Diffie-Hellman public value, pvi), and the responder's Hello message (where '||' means concatenation). The hvi hash is truncated to 256 bits:
ハッシュコミットメントはZRTP交換のイニシエータによって行われます。 、およびレスポンダのHelloメッセージは、（「||」連結を意味する）（PVIのDiffie-Hellman公開値を含む）は、図9に示すように、イニシエータ、HVIのハッシュ値は、全体DHPart2メッセージのハッシュを含みます。 HVIハッシュは256ビットに切り捨てられます。
hvi = hash(initiator's DHPart2 message ||
responder's Hello message)
Note that the Hello message includes the fields shown in Figure 3.
Helloメッセージは、図3に示すフィールドを含むことに留意されたいです。
The information from the responder's Hello message is included in the hash calculation to prevent a bid-down attack by modification of the responder's Hello message.
応答者のHelloメッセージからの情報は、応答者のHelloメッセージの変更により入札ダウン攻撃を防ぐために、ハッシュ計算に含まれています。
The initiator sends the hvi in the Commit message.
イニシエータは、コミットメッセージにHVIを送信します。
The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct Short Authentication String (SAS) (Section 7) in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. Without this hash commitment feature, a MiTM attacker would acquire both the pvi and pvr public values from the two parties before having to choose his own two DH public values for his MiTM attack. He could then use that information to quickly perform a bunch of trial DH calculations for both sides until he finds two with a matching SAS. To raise the cost of this birthday attack, the SAS would have to be much longer. The Short Authentication String would have to become a Long Authentication String, which would be unacceptable to the user. A hash commitment precludes this attack by forcing the MiTM to choose his own two DH public values before learning the public values of either of the two parties.
DH交換でハッシュのコミットメントを使用するには、SASが非常に短くすることができることを意味し、彼の攻撃、正しいショート認証文字列（SAS）（7節）を生成するために一つだけの推測に攻撃を制約します。 16ビットSASは、例えば、攻撃者が検出されないの65536のうち一つだけのチャンスを提供します。このハッシュコミットメント機能がない、MITM攻撃者は、彼のMITM攻撃のために彼自身の2つのDH公開値を選択する必要が前に2つの政党からのPVIとPVRパブリックの両方の値を取得します。彼は一致SASを持つ2つが見つかるまで、彼はその後すぐに、両側の試用DH計算の束を実行するために、その情報を使用することができます。この誕生日の攻撃のコストを上げるために、SASははるかに長くなければならないであろう。ショート認証文字列は、ユーザに受け入れられないロング認証文字列、になることだろう。ハッシュコミットメントは、両当事者のいずれかの公開値を学習する前に、彼自身の2つのDH公開値を選択するMITMを強制することで、この攻撃を排除します。
Upon receipt of the Commit message, the responder generates its own fresh random DH secret value, svr, and computes the public value. (Note that to speed up processing, this computation can be done in advance, with no need to discard this computation if both endpoints chose the same algorithm via Section 4.1.2.) For guidance on random number generation, see Section 4.8.
コミットメッセージを受信すると、レスポンダはSVR、独自の新鮮なランダムDH秘密値を生成し、公開値を計算します。 （この計算は、両方のエンドポイントは、セクション4.1.2を介して同一のアルゴリズムを選択した場合は、この計算を廃棄する必要なしに、事前に行うことができ、処理を高速化することに注意してください。）乱数生成のガイダンスについては、セクション4.8を参照してください。
For Finite Field Diffie-Hellman, the value for the DH generator g, the DH prime p, and the length of the DH secret value, svr, are defined in Section 5.1.5.
有限フィールドディフィー - ヘルマン、DHジェネレータg、DH素数p、およびDH秘密値、SVRの長さの値については、セクション5.1.5で定義されています。
pvr = g^svr mod p
PVR = G ^ SVRモッズP
The pvr value is formatted as a big-endian octet string, fixed to the bit-length of the DH prime; leading zeros MUST NOT be truncated.
PVR値が素数DHのビット長に固定されたビッグエンディアンオクテット文字列としてフォーマットされます。先頭のゼロは切り捨ててはなりません。
For Elliptic Curve DH, pvr is calculated and formatted according to the ECDH specification in Section 5.1.5, which refers in detail to certain sections of NIST SP 800-56A.
楕円曲線DHため、PVRは、NIST SP 800-56Aの特定の部分を詳細に参照し、セクション5.1.5におけるECDH仕様に従って計算し、フォーマットされています。
Upon receipt of the DHPart2 message, the responder checks that the initiator's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart2 message with a value of 1 or p-1 for g^svi mod p, which would cause a disastrously weak final DH result to be computed. If pvi is 1 or p-1, the user SHOULD be alerted of the attack and the protocol exchange MUST be terminated. Otherwise, the responder computes its own value for the hash commitment using the DH public value (pvi) received in the DHPart2 message and its own Hello message and compares the result with the hvi received in the Commit message. If they are different, a MiTM attack is taking place and the user is alerted and the protocol exchange terminated.
DHPart2メッセージを受信すると、イニシエータのDHパブリック値が1またはp-1に等しい応答をチェックされません。攻撃者は悲惨弱い最終DH結果を計算させるであろうG ^ SVI MOD pの1またはp-1の値と偽DHPart2メッセージを注入する可能性があります。 PVIが1またはp-1である場合、ユーザは、攻撃を警告されるべきであり、プロトコル交換を終了しなければなりません。そうでない場合、応答者はDHPart2メッセージと、自身のHelloメッセージで受信したDHパブリック値（PVI）を使用してハッシュコミットメントのために、独自の値を計算し、コミットメッセージで受信HVIとの結果を比較します。それらが異なる場合は、MITM攻撃が行われていると、ユーザーは警告やプロトコル交換が終了されます。
The responder then calculates the Diffie-Hellman result:
応答者はその後のDiffie-Hellman結果を計算します。
DHResult = pvi^svr mod p
DHResult PVI = ^ MODのp SVR
Upon receipt of the DHPart1 message, the initiator checks that the responder's DH public value is not equal to 1 or p-1. An attacker might inject a false DHPart1 message with a value of 1 or p-1 for g^svr mod p, which would cause a disastrously weak final DH result to be computed. If pvr is 1 or p-1, the user should be alerted of the attack and the protocol exchange MUST be terminated.
DHPart1メッセージを受信すると、イニシエータはレスポンダのDHパブリック値が1またはp-1に等しくないことをチェックします。攻撃者は悲惨弱い最終DH結果を計算させるであろうG ^ SVR MOD pの1またはp-1の値と偽DHPart1メッセージを注入する可能性があります。 PVRは、1またはp-1である場合、ユーザーは攻撃を警告しなければならないとプロトコル交換を終えなければなりません。
The initiator then sends a DHPart2 message containing the initiator's DH public value and the set of calculated shared secret IDs as defined in Section 4.3.1.
イニシエータは、4.3.1項で定義されているイニシエータのDH公開値と計算共有シークレットIDのセットを含むDHPart2メッセージを送信します。
The initiator calculates the same Diffie-Hellman result using:
開始剤は使用して同一のDiffie-Hellman結果を算出します。
DHResult = pvr^svi mod p
DHResult = PVR ^すべてのmodのp
A hash of the received and sent ZRTP messages in the current ZRTP exchange in the following order is calculated by both parties:
次の順序で現在ZRTP交換で受信され、送信されたZRTPメッセージのハッシュは、両当事者によって計算されます。
total_hash = hash(Hello of responder || Commit || DHPart1 || DHPart2)
total_hash =ハッシュ（ハローレスポンダの|| || || DHPart1 DHPart2をコミット）
Note that only the ZRTP messages (Figures 3, 5, 8, and 9), not the entire ZRTP packets, are included in the total_hash.
のみZRTPメッセージ（図3、図5、図8、図9）、全体ZRTPパケットは、total_hashに含まれていないことに留意されたいです。
For both the initiator and responder, the DHResult is formatted as a big-endian octet string and fixed to the width of the DH prime; leading zeros MUST NOT be truncated. For example, for a 3072-bit p, DHResult would be a 384 octet value, with the first octet the most significant. DHResult may also be the result of an ECDH calculation, which is discussed in Section 5.1.5.
イニシエータとレスポンダの両方について、DHResultはビッグエンディアンオクテット文字列としてフォーマットされており、プライムDHの幅に固定され、先頭のゼロは切り捨ててはなりません。例えば、3072ビットのpについて、DHResultは、最も重要な最初のオクテットと、384オクテット値であろう。 DHResultはまた、セクション5.1.5で説明されてECDH計算の結果であり得ます。
Key | Size of
Agreement | DHResult
------------------------
DH-3072 | 384 octets
------------------------
DH-2048 | 256 octets
------------------------
ECDH P-256 | 32 octets
------------------------
ECDH P-384 | 48 octets
------------------------
The authors believe the calculation of the final shared secret, s0, is in compliance with the recommendations in Sections 5.8.1 and 6.1.2.1 of NIST SP 800-56A [NIST-SP800-56A]. This is done by hashing a concatenation of a number of items, including the DHResult, the ZID's of the initiator (ZIDi) and the responder (ZIDr), the total_hash, and the set of non-null shared secrets as described in Section 4.3.
著者は、最終的な共有秘密の計算は、S0、セクション5.8.1およびNIST SP 800-56A [NIST-SP800-56A]の6.1.2.1の推奨事項を遵守していると考えています。これはセクション4.3で説明したようにDHResult、ZIDの開始剤（ZIDi）とレスポンダ（ZIDr）、total_hash、非ヌル共有秘密のセットを含む項目の数の連結をハッシュすることによって行われます。
In Section 5.8.1 of [NIST-SP800-56A], NIST requires certain parameters to be hashed together in a particular order, which NIST refers to as: Z, AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo. In our implementation, our DHResult corresponds to Z, "ZRTP-HMAC-KDF" corresponds to AlgorithmID, our ZIDi and ZIDr correspond to PartyUInfo and PartyVInfo, our total_hash corresponds to SuppPubInfo, and the set of three shared secrets s1, s2, and s3 corresponds to SuppPrivInfo. NIST also requires a 32-bit big-endian integer counter to be included in the hash each time the hash is computed, which we have set to the fixed value of 1 because we only compute the hash once. NIST refers to the final hash output as DerivedKeyingMaterial, which corresponds to our s0 in this calculation.
Z、AlgorithmID、PartyUInfo、PartyVInfo、SuppPubInfo、及びSuppPrivInfo：[NIST-SP800-56A]のセクション5.8.1において、NISTは、NISTはという特定の順序で一緒にハッシュされるべき特定のパラメータを必要とします。我々の実装では、我々のDHResultはZに対応する、「ZRTP-HMAC-KDF」はAlgorithmIDに対応し、私達のZIDiとZIDrはPartyUInfoとPartyVInfoに対応し、私達のtotal_hashはSuppPubInfoに対応し、三の共有秘密のセットはS1、S2、およびS3 SuppPrivInfoに対応しています。 NISTはまた、ハッシュに、我々は一度だけのハッシュを計算するために、我々は1の固定値に設定されているハッシュが計算されるたびに、含まれる32ビットのビッグエンディアン整数カウンタを必要とします。 NISTは、この計算に私達のS0に対応DerivedKeyingMaterial、最終ハッシュ出力を指します。
s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi || ZIDr || total_hash || len(s1) || s1 || len(s2) || s2 || len(s3) || s3)
S0 =ハッシュ（カウンタ|| || DHResult "ZRTP-HMAC-KDF" || ||ユダヤZIDr || || total_hash（S1）|| || S1のみ（S2）|| || S 2のみ（S3）として|| S3）
Note that temporary values s1, s2, and s3 were calculated per the methods described in Section 4.3. DHResult, s1, s2, and s3 MUST all be erased from memory immediately after they are used to calculate s0.
一時的な値は、S1、S2、およびS3は、4.3節で説明した方法ごとに計算されたことに注意してください。 DHResult、S1、S2、S3は、すべての彼らはS0を計算するために使用された直後にメモリから消去されなければなりません。
The length of the DHResult field was implicitly agreed to by the negotiated DH prime size. The length of total_hash is implicitly determined by the negotiated hash algorithm. All of the explicit length fields, len(), in the above hash are 32-bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (s1, s2, and s3) may have lengths of zero if they are null (not shared) and are each preceded by a 4-octet length field. For example, if s2 is null, len(s2) is 0x00000000, and s2 itself would be absent from the hash calculation, which means len(s3) would immediately follow len(s2). While inclusion of ZIDi and ZIDr may be redundant, because they are implicitly included in the total_hash, we explicitly include them here to follow NIST SP 800-56A. The fixed-length string "ZRTP-HMAC-KDF" (not null-terminated) identifies for what purpose the resulting s0 will be used, which is to serve as the key derivation key for the ZRTP HMAC-based key derivation function (KDF) defined in Section 4.5.1 and used in Section 4.5.3.
DHResultフィールドの長さは、暗黙のうちに交渉DHプライムサイズによって合意されました。 total_hashの長さは、暗黙のうちに交渉し、ハッシュアルゴリズムによって決定されます。明示的な長さフィールドのすべて、上記のハッシュでlenが（）、次のフィールドのオクテットの長さを与えて、32ビットのビッグエンディアンの整数です。彼らは（共有されていない）はnullであり、各々4オクテットの長さフィールドが先行している場合、いくつかの共有秘密のセットのメンバー（S1、S2、およびS3）がゼロの長さを有することができます。例えばs2がnullの場合、（S2）0x00000000のあるlenを、直ちにLENを（S2）に従うことになる自体がlen（S3）を意味し、ハッシュ計算に存在しないであろうS2のそれらは暗黙のうちにtotal_hashに含まれているためZIDiとZIDrを含めることは、冗長であるかもしれないが、我々は明示的にNIST SP 800-56Aに従うことをここに含まれています。固定長の文字列「ZRTP-HMAC-KDF」は（NOT NULLで終了）、得られたS0がZRTP HMACベースの鍵導出関数（KDF）用鍵導出鍵として機能するようにされており、使用されるどのような目的のために識別します4.5.1項で定義され、4.5.3で使用されます。
The authors believe ZRTP DH mode is in full compliance with two relevant NIST documents that cover key derivations. First, Section 5.8.1 of [NIST-SP800-56A] computes what NIST refers to as DerivedKeyingMaterial, which ZRTP refers to as s0. This s0 then serves as the key derivation key, which NIST refers to as KI in the key derivation function described in Sections 5 and 5.1 of [NIST-SP800-108], to derive all the rest of the subkeys needed by ZRTP. For ECDH mode, the authors believe the s0 calculation is also in compliance with Section 3.1 of the National Security Agency's (NSA's) Suite B Implementer's Guide to NIST SP 800-56A [NSA-Suite-B-Guide-56A].
著者はZRTP DHモードキー導出をカバーする2つの関連NIST文書に完全に準拠していると考えています。まず、[NIST-SP800-56A]のセクション5.8.1は、NISTがZRTPがS0というDerivedKeyingMaterial、というものを計算します。次いで、これをS0 ZRTPによって必要とされるサブキーのすべての残りの部分を導出するために、NISTはセクション5と[NIST-SP800-108]の5.1に記載のキー導出関数にKIなどを意味する鍵導出鍵として機能します。 ECDHモードでは、著者は、S0の計算は、NIST SP 800-56A [NSA-スイート-B-ガイド-56A]に国家安全保障局（NSA）の（NSAの）スイートBのImplementerのガイドの3.1節に準拠したもであると考えています。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP鍵導出関数（KDF）（セクション4.5.1）ZIDi、ZIDr、両当事者に知られているノンス値を含むべきである（[NIST-SP800-108]ガイドラインあたり）KDFコンテキストフィールドの使用を必要とします。その計算は、イニシエータのコミットメッセージと応答のHelloメッセージからノンス材料が含まれているためtotal_hashは、ノンス値としての資格。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context =（ZIDi || || ZIDr total_hash）
At this point in DH mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.
DHモードでこの時点では、2つのエンドポイントが定義され、S0があることを、今、ZRTPSessのキー派生と4.5.2のキーの残りの部分に進みます。
The Preshared key agreement mode can be used to generate SRTP keys and salts without a DH calculation, instead relying on a shared secret from previous DH calculations between the endpoints.
事前共有鍵合意モードではなく、エンドポイント間の前DH計算から共有シークレットに依存する、DH計算なしSRTPキーと塩を生成するために使用することができます。
This key agreement mode is useful to rapidly re-establish a secure session between two parties who have recently started and ended a secure session that has already performed a DH key agreement, without performing another lengthy DH calculation, which may be desirable on slow processors in resource-limited environments. Preshared mode MUST NOT be used for adding additional media streams to an existing call. Multistream mode MUST be used for this purpose.
この鍵合意モードは急速で遅いプロセッサ上のが望ましいかもしれない別の長いDH計算を実行せず、最近開始し、すでにDHキー契約を行ったセキュアなセッションを終了した2つの当事者間の安全なセッションを再確立するのに便利ですリソースが制限された環境。事前共有モードでは、既存の呼に追加のメディアストリームを追加するために使用してはいけません。マルチストリームモードでは、この目的のために使用しなければなりません。
In the most severe resource-limited environments, Preshared mode may be useful with processors that cannot perform a DH calculation in an ergonomically acceptable time limit. Shared key material may be manually provisioned between two such endpoints in advance and still allow a limited subset of functionality. Such a "better than nothing" implementation would have to be regarded as non-compliant with the ZRTP specification, but it could interoperate in Preshared (and if applicable, Multistream) mode with a compliant ZRTP endpoint.
最も深刻なリソースが制限された環境では、事前共有モードは、人間工学的に許容される制限時間内DH計算を行うことができないプロセッサと有用であり得ます。共有鍵材料は、手動で事前に二つのそのようなエンドポイント間でプロビジョニングと依然として機能の限られたサブセットを可能にすることができます。このような「何もないよりはまし」実装はZRTP仕様に準拠していないと見なさなければならないであろうが、それは対応ZRTPのエンドポイントとの事前共有（および該当する場合、マルチストリーム）モードで相互運用性があります。
Because Preshared mode affects the state of the retained shared secret cache, only one in-process ZRTP Preshared exchange may occur at a time between two ZRTP endpoints. This rule is explained in more detail in Section 4.4.1, and applies for the same reasons as in DH mode.
事前共有モードを保持共有秘密キャッシュの状態に影響を与えるため、一つだけで、プロセスZRTP事前共有交換は2つのZRTPエンドポイント間の時間に発生する可能性があります。この規則は、4.4.1項で詳しく説明し、DHモードと同様の理由で適用されています。
Preshared mode is only included in this specification to meet the R-REUSE requirement in the Media Security Requirements [RFC5479] document. A series of preshared-keyed calls between two ZRTP endpoints should use a DH key exchange periodically. Preshared mode is only used if a cached shared secret has been established in an earlier session by a DH exchange, as discussed in Section 4.9.
事前共有モードは、メディアセキュリティ要件[RFC5479]ドキュメント内のR-REUSEの要件を満たすために、この仕様に含まれています。 2つのZRTPエンドポイントとの間の事前共有キー付きコール一連の定期的DH鍵交換を使用する必要があります。 4.9節で述べたように、キャッシュされた共有秘密は、DH交換により、以前のセッションで確立されている場合は事前共有モードにのみ使用されます。
Preshared mode is selected by setting the Key Agreement Type to Preshared in the Commit message. This results in the same call flow as Multistream mode. The principal difference between Multistream mode and Preshared mode is that Preshared mode uses a previously cached shared secret, rs1, instead of an active ZRTP Session key, ZRTPSess, as the initial keying material.
事前共有モードは、コミットメッセージに事前共有キーに契約の種類を設定することによって選択されます。これは、マルチストリームモードと同じコールフローになります。マルチストリームモードと事前共有モードとの間の主な違いは、事前共有モードが初期キーイング材料として、代わりにアクティブZRTPセッション鍵、ZRTPSessの、以前にキャッシュされた共有秘密、RS1を使用することです。
Preshared mode depends on having a reliable shared secret in its cache. Before Preshared mode is used, the initial DH exchange that gave rise to the shared secret SHOULD have used at least one of these anti-MiTM mechanisms: 1) A verbal comparison of the SAS, evidenced by the SAS Verified flag, or 2) an end-to-end integrity-protected delivery of the a=zrtp-hash in the signaling (Section 8.1.1), or 3) a digital signature on the sashash (Section 7.2).
事前共有モードは、そのキャッシュに信頼性の高い共有秘密を持つに依存します。 SAS認証フラグによって証明SAS 1）口頭の比較、または2）AN：事前共有モードを使用する前に、共有秘密を生じた最初のDH交換は、これらの抗MITM機構の少なくとも一方を使用しているべきですシグナル伝達におけるA = ZRTPハッシュのエンドツーエンドの完全性保護配信sashashに（セクション8.1.1）、または3）のデジタル署名（セクション7.2）。
The Commit message (Figure 7) is sent by the initiator of the ZRTP exchange. From the intersection of the algorithms in the sent and received Hello messages, the initiator chooses a hash, cipher, auth tag, Key Agreement Type, and SAS Type to be used.
コミットメッセージ（図7）はZRTP交換のイニシエータによって送信されます。送受信Helloメッセージにおけるアルゴリズムの交点から、開始剤が使用されるハッシュ、暗号、認証タグ、鍵合意の種類、およびSASタイプを選択します。
To assemble a Preshared commit, we must first construct a temporary preshared_key, which is constructed from one of several possible combinations of cached key material, depending on what is available in the shared secret cache. If rs1 is not available in the initiator's cache, then Preshared mode MUST NOT be used.
事前共有コミット組み立てるには、まず共有秘密キャッシュに利用できるものに応じて、キャッシュされたキー材料のいくつかの可能な組み合わせのいずれかから構成され、一時preshared_keyにし、構築しなければなりません。 RS1は、イニシエータのキャッシュに使用できない場合は、事前共有モードを使用してはいけません。
preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || auxsecret || len(pbxsecret) || pbxsecret)
（（R1）R1 || ||のみ（auxsecret）|| || auxsecretのみ（pbxsecret）|| pbxsecretと称する）preshared_keyにハッシュ=
All of the explicit length fields, len(), in the above hash are 32- bit big-endian integers, giving the length in octets of the field that follows. Some members of the set of shared secrets (rs1, auxsecret, and pbxsecret) may have lengths of zero if they are null (not available), and are each preceded by a 4-octet length field. For example, if auxsecret is null, len(auxsecret) is 0x00000000, and auxsecret itself would be absent from the hash calculation, which means len(pbxsecret) would immediately follow len(auxsecret).
明示的な長さフィールドのすべて、上記のハッシュでlenが（）、次のフィールドのオクテットの長さを与えて、32ビットビッグエンディアン整数です。共有秘密（RS1、auxsecret、及びpbxsecret）のセットの一部のメンバーは、彼らが（利用できない）NULLの場合は、ゼロの長さを有していてもよく、そして各々4オクテットの長さフィールドが先行します。例えばauxsecretがnullである場合、LEN（auxsecret）が0x00000000のであり、それ自体をauxsecret LENを意味ハッシュ計算、（pbxsecret）は存在しないであろうことは、すぐにLEN（auxsecret）に従うことになります。
In place of hvi in the Commit message, two smaller fields are inserted by the initiator:
コミットメッセージにHVIの代わりに、2つのより小さなフィールドは、イニシエータによって挿入されます。
- A random nonce of length 4 words (16 octets).
- 長さのランダムなノンス4つのワード（16オクテット）。
- A keyID = MAC(preshared_key, "Prsh") truncated to 64 bits.
- 鍵ID = MAC（preshared_keyに、 "Prsh"）は、64ビットに切り捨てられます。
Note: Since the nonce is used to calculate different SRTP key and salt pairs for each session, a duplication will result in the same key and salt being generated for the two sessions, which would have disastrous security consequences.
注意：ナンスがセッションごとに異なるSRTPキーと塩のペアを計算するのに使用されているので、重複は悲惨なセキュリティ結果をもたらすことになる、二つのセッションのために生成されている同じキーと塩になります。
The responder uses the received keyID to search for matching key material in its cache. It does this by computing a preshared_key value and keyID value using the same formula as the initiator, depending on what is available in the responder's local cache. If the locally computed keyID does not match the received keyID in the Commit, the responder recomputes a new preshared_key and keyID from a different subset of shared keys from the cache, dropping auxsecret, pbxsecret, or both from the hash calculation, until a matching preshared_key is found or it runs out of possibilities. Note that rs2 is not included in the process.
応答者は、そのキャッシュ内のキーマテリアルをマッチングを検索するために、受信した鍵IDを使用しています。これは、応答者のローカルキャッシュに利用できるものに応じて、イニシエータと同じ式を使用してpreshared_keyに値と鍵IDの値を計算することによってこれを行います。局所的に計算された鍵IDがコミットで受信した鍵IDと一致しない場合、応答者はマッチングpreshared_keyになるまで、キャッシュから共有鍵、滴下auxsecret、pbxsecret、またはハッシュ計算の両方からの異なる部分集合から新しいpreshared_keyに及び鍵IDを再計算します見つかったか、それは可能性がなくなっています。 RS2は、プロセスに含まれていないことに注意してください。
If it finds the appropriate matching shared key material, it is used to derive s0 and a new ZRTPSess key, as described in the next section on shared secret calculation, Section 4.4.2.4.
それは適切なマッチング共有鍵材料を検出した場合、共有秘密計算は、セクション4.4.2.4に次のセクションで説明したように、S0および新しいZRTPSessキーを導出するために使用されます。
If the responder determines that it does not have a cached shared secret from a previous DH exchange, or it fails to match the keyID hash from the initiator with any combination of its shared keys, it SHOULD respond with its own DH Commit message. This would reverse the roles and the responder would become the initiator, because the DH Commit must always "trump" the Preshared Commit message as described in Section 4.2. The key exchange would then proceed using DH mode. However, if a severely resource-limited responder lacks the computing resources to respond in a reasonable time with a DH Commit, it MAY respond with a ZRTP Error message (Section 5.9) indicating that no shared secret is available.
応答者は、以前のDH交換からキャッシュされた共有秘密を持っていないと判断し、またはそれはその共有キーの任意の組み合わせで、イニシエータから鍵IDのハッシュが一致しなかった場合、それは自身のDHコミットメッセージで応答する必要があります。これは役割を逆になり、DHは4.2節で説明したように、常に「切り札」の事前共有がメッセージをコミットしなければなりませんコミットするので、レスポンダは、イニシエータになります。鍵交換は、DHモードを使用して進行します。厳しくリソースが制限された応答者がコミットDHと合理的な時間内に応答するためにコンピューティングリソースを欠いている場合しかし、それは何の共有秘密が利用できないことを示すZRTPエラーメッセージ（5.9節）で応答することができます。
If both sides send Preshared Commit messages initiating a secure session at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds.
双方が事前共有が同時に安全なセッションを開始するコミットメッセージを送信する場合、競合が解決されると、イニシエータ/レスポンダの役割はセクション4.2、及びプロトコルが進行するに従って決済されます。
In Preshared mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.
事前共有モードでは、両方のDHPart1とDHPart2メッセージがスキップされます。以下に説明するようにイニシエータからコミットメッセージを受信した後、応答者は、このストリームのSRTPキーを計算した後CONFIRM1メッセージを送信します。
Preshared mode requires that the s0 and ZRTPSess keys be derived from the preshared_key, and this must be done in a way that guarantees uniqueness for each session. This is done by using nonce material from both parties: the explicit nonce in the initiator's Preshared Commit message (Figure 7) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each session.
事前共有モードは、S0とZRTPSessキーがpreshared_keyに由来することを必要とし、これはセッションごとに一意性を保証した方法で行われなければなりません。これは、両当事者からノンス材料を使用して行われる：イニシエータの事前共有に明示ノンスは、メッセージ（図7）とレスポンダのHelloメッセージにおけるH3フィールド（図3）をコミット。このように、両当事者は、セッションごとに一意であることが結果の共有秘密を強制します。
A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated:
現在のメディアストリームの現在ZRTP交換で受信され、送信されたZRTPメッセージのハッシュを計算します。
total_hash = hash(Hello of responder || Commit)
total_hash =ハッシュ（応答者のこんにちは||コミット）
Note that only the ZRTP messages (Figures 3 and 7), not the entire ZRTP packets, are included in the total_hash.
なおのみZRTPメッセージ（図3および7）、全体ではなくZRTPパケットは、total_hashに含まれています。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP鍵導出関数（KDF）（セクション4.5.1）ZIDi、ZIDr、両当事者に知られているノンス値を含むべきである（[NIST-SP800-108]ガイドラインあたり）KDFコンテキストフィールドの使用を必要とします。その計算は、イニシエータのコミットメッセージと応答のHelloメッセージからノンス材料が含まれているためtotal_hashは、ノンス値としての資格。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context =（ZIDi || || ZIDr total_hash）
The s0 key is derived via the ZRTP key derivation function (Section 4.5.1) from preshared_key and the nonces implicitly included in the total_hash. The nonces also ensure KDF_Context is unique for each session, which is critical for security.
S0キーはpreshared_keyに暗黙的に含まtotal_hashナンスからZRTP鍵導出関数（4.5.1項）を介して導出されます。ナンスもKDF_Contextを確実に保障するために重要である、セッションごとにユニークです。
s0 = KDF(preshared_key, "ZRTP PSK", KDF_Context, negotiated hash length)
S0 = KDF（preshared_keyに、 "ZRTP PSK"、KDF_Context、ネゴシエートされたハッシュ長）
The preshared_key MUST be erased as soon as it has been used to calculate s0.
preshared_keyには、すぐにS0を計算するのに使用されているように消去されなければなりません。
At this point in Preshared mode, the two endpoints proceed to the key derivations of ZRTPSess and the rest of the keys in Section 4.5.2, now that there is a defined s0.
事前共有モードでは、この時点では、2つのエンドポイントが定義され、S0があることを、今、ZRTPSessのキー派生と4.5.2のキーの残りの部分に進みます。
The Multistream key agreement mode can be used to generate SRTP keys and salts for additional media streams established between a pair of endpoints. Multistream mode cannot be used unless there is an active SRTP session established between the endpoints, which means a ZRTP Session key is active. This ZRTP Session key can be used to generate keys and salts without performing another DH calculation. In this mode, the retained shared secret cache is not used or updated. As a result, multiple ZRTP Multistream mode exchanges can be processed in parallel between two endpoints.
マルチストリーム鍵合意モードは、エンドポイントのペア間で確立された追加のメディアストリームのためのSRTPキーと塩を生成するために使用することができます。 ZRTPセッションキーがアクティブであることを意味するエンドポイント間で確立されたアクティブSRTPセッションがある場合を除きマルチストリームモードを使用することができません。このZRTPセッション鍵は、他のDH計算を行うことなく、キーと塩を生成するために使用することができます。このモードでは、保持共有秘密キャッシュが使用または更新されません。結果として、複数ZRTPマルチストリームモード交換は2つのエンドポイント間で並列に処理することができます。
Multistream mode is also used to resume a secure call that has gone clear using a GoClear message as described in Section 4.7.2.1.
マルチストリームモードも、セクション4.7.2.1で説明したようにGoClearメッセージを使用して明らかになったセキュアな通話を再開するために使用されています。
When adding additional media streams to an existing call, Multistream mode MUST be used. The first media stream MUST use either DH mode or Preshared mode. Only one DH exchange or Preshared exchange is performed, just for the first media stream. The DH exchange or Preshared exchange MUST be completed for the first media stream before Multistream mode is used to add any other media streams. In a
既存の通話に追加のメディアストリームを追加する場合は、マルチストリームモードを使用しなければなりません。最初のメディアストリームは、DHモードまたは事前共有モードのいずれかを使用しなければなりません。唯一のDH交換または事前共有交換はちょうど最初のメディアストリームのために、行われます。マルチストリームモードは、任意の他のメディアストリームを追加するために使用される前に、DH交換又は事前共有交換は、最初のメディアストリームのために完了しなければなりません。で
Multistream session, a ZRTP endpoint MUST use the same ZID for all media streams, matching the ZID used in the first media stream.
マルチストリームセッション、ZRTPエンドポイントは、ZIDは、最初のメディアストリームに使用される一致、すべてのメディアストリームに対して同じZIDを使用しなければなりません。
Multistream mode is selected by the initiator setting the Key Agreement Type to "Mult" in the Commit message (Figure 6). The Cipher Type, Auth Tag Length, and Hash in Multistream mode SHOULD be set by the initiator to the same as the values as in the initial DH Mode Commit. The SAS Type is ignored as there is no SAS authentication in this mode.
マルチストリームモードがコミットメッセージに「のMult」（図6）の主契約タイプを設定イニシエータによって選択されます。初期DHモードと同様の値がコミットとして暗号種別、認証タグの長さ、及びマルチストリームモードでハッシュは同じにイニシエータによって設定されるべきです。このモードではSAS認証がないとSASタイプは無視されます。
Note: This requirement is needed since some endpoints cannot support different SRTP algorithms for different media streams. However, in the case of Multistream mode being used to go secure after a GoClear, the requirement to use the same SRTP algorithms is relaxed if there are no other active SRTP sessions.
注意：一部のエンドポイントが異なるメディアストリームのための異なるSRTPアルゴリズムをサポートすることはできませんので、この要件は必要とされています。他のアクティブなSRTPセッションが存在しない場合は、GoClear後のセキュア行くために使用されているマルチストリームモードの場合には、同じSRTPアルゴリズムを使用するための要件が緩和されます。
In place of hvi in the Commit, a random nonce of length 4 words (16 octets) is chosen. Its value MUST be unique for all nonce values chosen for active ZRTP sessions between a pair of endpoints. If a Commit is received with a reused nonce value, the ZRTP exchange MUST be immediately terminated.
コミット、長さのランダムなノンス4つのワード（16オクテット）でHVIの代わりに選択されます。その値は、エンドポイントのペア間の活性ZRTPセッションのために選択されたすべてのノンス値に対して一意でなければなりません。コミットを再利用したnonce値と受信された場合、ZRTP交換は直ちに終了しなければなりません。
Note: Since the nonce is used to calculate different SRTP key and salt pairs for each media stream, a duplication will result in the same key and salt being generated for the two media streams, which would have disastrous security consequences.
注：ナンスが各メディアストリームに対して異なるSRTPキーと塩の対を計算するために使用されているので、重複は悲惨なセキュリティ影響を有するであろう2つのメディアストリームのために生成される同じキーと塩をもたらすであろう。
If a Commit is received selecting Multistream mode, but the responder does not have a ZRTP Session Key available, the exchange MUST be terminated. Otherwise, the responder proceeds to the next section on shared secret calculation, Section 4.4.3.2.
コミットは、マルチストリームモードを選択する受信されたが、応答がZRTPセッションキーを用意していない場合は、交換を終えなければなりません。それ以外の場合は、共有秘密計算上の次のセクションへの応答進み、セクション4.4.3.2。
If both sides send Multistream Commit messages at the same time, the contention is resolved and the initiator/responder roles are settled according to Section 4.2, and the protocol proceeds.
両面マルチストリームが同時にコミットメッセージを送信する場合、競合が解決されると、イニシエータ/レスポンダの役割はセクション4.2、及びプロトコルが進行するに従って決済されます。
In Multistream mode, both the DHPart1 and DHPart2 messages are skipped. After receiving the Commit message from the initiator, the responder sends the Confirm1 message after calculating this stream's SRTP keys, as described below.
マルチストリームモードでは、両方のDHPart1とDHPart2メッセージがスキップされます。以下に説明するようにイニシエータからコミットメッセージを受信した後、応答者は、このストリームのSRTPキーを計算した後CONFIRM1メッセージを送信します。
In Multistream mode, each media stream requires that a set of keys be derived from the ZRTPSess key, and this must be done in a way that guarantees uniqueness for each media stream. This is done by using nonce material from both parties: the explicit nonce in the initiator's Multistream Commit message (Figure 6) and the H3 field in the responder's Hello message (Figure 3). Thus, both parties force the resulting shared secret to be unique for each media stream.
マルチストリームモードでは、各メディアストリームは、キーのセットがZRTPSessキーから導出されている必要があり、これは各メディアストリームのための一意性を保証した方法で行われなければなりません。これは、両当事者からノンス材料を使用して行われる：イニシエータのマルチストリームに明示的なノンスは、メッセージ（図6）とレスポンダのHelloメッセージにおけるH3フィールド（図3）をコミット。このように、両当事者は、各メディアストリームに対して一意であることが得られた共有秘密を強制します。
A hash of the received and sent ZRTP messages in the current ZRTP exchange for the current media stream is calculated:
現在のメディアストリームの現在ZRTP交換で受信され、送信されたZRTPメッセージのハッシュを計算します。
total_hash = hash(Hello of responder || Commit)
total_hash =ハッシュ（応答者のこんにちは||コミット）
This refers to the Hello and Commit messages for the current media stream, which is using Multistream mode, not the original media stream that included a full DH key agreement. Note that only the ZRTP messages (Figures 3 and 6), not the entire ZRTP packets, are included in the hash.
これは、こんにちはを参照し、マルチストリームモード、フルDHキー合意を含まない元のメディア・ストリームを使用している現在のメディアストリームのためのメッセージをコミットします。なおのみZRTPメッセージ（図3及び6）、全体ではなくZRTPパケットは、ハッシュに含まれています。
The ZRTP key derivation function (KDF) (Section 4.5.1) requires the use of a KDF Context field (per [NIST-SP800-108] guidelines), which should include the ZIDi, ZIDr, and a nonce value known to both parties. The total_hash qualifies as a nonce value, because its computation included nonce material from the initiator's Commit message and the responder's Hello message.
ZRTP鍵導出関数（KDF）（セクション4.5.1）ZIDi、ZIDr、両当事者に知られているノンス値を含むべきである（[NIST-SP800-108]ガイドラインあたり）KDFコンテキストフィールドの使用を必要とします。その計算は、イニシエータのコミットメッセージと応答のHelloメッセージからノンス材料が含まれているためtotal_hashは、ノンス値としての資格。
KDF_Context = (ZIDi || ZIDr || total_hash)
KDF_Context =（ZIDi || || ZIDr total_hash）
The current stream's SRTP keys and salts for the initiator and responder are calculated using the ZRTP Session Key ZRTPSess and the nonces implicitly included in the total_hash. The nonces also ensure that KDF_Context will be unique for each media stream, which is critical for security. For each additional media stream, a separate s0 is derived from ZRTPSess via the ZRTP key derivation function (Section 4.5.1):
イニシエータとレスポンダのための現在のストリームのSRTPキーと塩がZRTPセッションキーZRTPSessと暗黙のうちにtotal_hashに含まナンスを使用して計算されます。ナンスもKDF_Contextは、セキュリティのために重要である各メディアストリームのために一意であることを保証します。各追加のメディアストリームに対して、別々のS0はZRTP鍵導出関数（4.5.1項）を介しZRTPSessから誘導されます。
s0 = KDF(ZRTPSess, "ZRTP MSK", KDF_Context, negotiated hash length)
S0 = KDF（ZRTPSess、 "ZRTP MSK"、KDF_Context、ネゴシエートされたハッシュ長）
Note that the ZRTPSess key was previously derived from material that also includes a different and more inclusive total_hash from the entire packet sequence that performed the original DH exchange for the first media stream in this ZRTP session.
ZRTPSessキーが以前にも、このZRTPセッションの最初のメディアストリームの元のDH交換を行うパケット全体配列とは異なる、より包括的なtotal_hashを含む材料から誘導されたことに留意されたいです。
At this point in Multistream mode, the two endpoints begin key derivations in Section 4.5.3.
マルチストリームモードでは、この時点では、2つのエンドポイントは、第4.5.3項でキー導出を始めます。
To derive keys from a shared secret, ZRTP uses an HMAC-based key derivation function, or KDF. It is used throughout Section 4.5.3 and in other sections. The HMAC function for the KDF is based on the negotiated hash algorithm defined in Section 5.1.2.
共有秘密の鍵を導出するために、ZRTPは、HMACベースの鍵導出関数、またはKDFを使用しています。これは、4.5.3項全体と他のセクションで使用されています。 KDFのためのHMAC機能は、5.1.2項で定義されて交渉したハッシュアルゴリズムに基づいています。
The authors believe the ZRTP KDF is in full compliance with the recommendations in NIST SP 800-108 [NIST-SP800-108]. Section 7.5 of the NIST document describes "key separation", which is a security requirement for the cryptographic keys derived from the same key derivation key. The keys shall be separate in the sense that the compromise of some derived keys will not degrade the security strength of any of the other derived keys or the security strength of the key derivation key. Strong preimage resistance is provided.
著者はZRTP KDFは、NIST SP 800から108 [NIST-SP800-108]の推奨事項に完全に準拠していると考えています。 NIST文書のセクション7.5は同じ鍵導出鍵から導出暗号鍵のセキュリティ要件である「キー分離」を、記載されています。キーは、いくつかの派生キーの妥協が他の派生キーまたはキーの派生キーのセキュリティ強度のいずれかのセキュリティ強度を劣化させないという意味で独立したものでなければなりません。強いプリイメージ耐性が提供されます。
The ZRTP KDF runs the NIST pseudorandom function (PRF) in counter mode, with only a single iteration of the counter. The NIST PRF is based on the HMAC function. The ZRTP KDF never has to generate more than 256 bits (or 384 bits for Suite B applications) of output key material, so only a single invocation of the HMAC function is needed.
ZRTP KDFは、カウンタの単一の反復で、カウンタモードでNISTの擬似ランダム関数（PRF）を実行します。 NIST PRFは、HMAC関数に基づいています。 ZRTP KDFのでHMAC関数の単一の呼び出しが必要とされ、出力鍵材料の（スイートBアプリケーションまたは384ビット）より256ビットを生成しなければならないことはありません。
The ZRTP KDF is defined in this manner, per Sections 5 and 5.1 of [NIST-SP800-108]:
ZRTP KDFはセクション5と[NIST-SP800-108]の5.1当たり、このように定義されています。
KDF(KI, Label, Context, L) = HMAC(KI, i || Label || 0x00 || Context || L)
KDF（KI、ラベル、コンテキスト、L）= HMAC（KI、iはラベル|| 0x00の||コンテキスト|| Lを||）
The HMAC in the KDF is keyed by KI, which is a secret key derivation key that is unknown to the wiretapper (for example, s0). The HMAC is computed on a concatenated set of nonsecret fields that are defined as follows. The first field is a 32-bit big-endian integer counter (i) required by NIST to be included in the HMAC each time the HMAC is computed, which we have set to the fixed value of 0x000001 because we only compute the HMAC once. Label is a string of nonzero octets that identifies the purpose for the derived keying material. The octet 0x00 is a delimiter required by NIST. The NIST KDF formula has a "Context" field that includes ZIDi, ZIDr, and some optional nonce material known to both parties. L is a 32-bit big-endian positive integer, not to exceed the length in bits of the output of the HMAC. The output of the KDF is truncated to the leftmost L bits. If SHA-384 is the negotiated hash algorithm, the HMAC would be HMAC-SHA-384; thus, the maximum value of L would be 384, the negotiated hash length.
KDFでHMACを盗聴者に知られていない秘密鍵導出鍵であるKI、をキー（例えば、S0）。 HMACは、以下のように定義される非機密フィールドの連結セットで計算されます。最初のフィールドは、我々は一度だけHMACを計算するために、我々は0x000001の固定値に設定されたHMACにHMACが計算されるたびに含まれることがNISTによって必要とされる32ビットのビッグエンディアン整数カウンタ（I）、です。ラベルは、派生鍵素材のための目的を識別し、非ゼロのオクテット文字列です。オクテット0x00がNISTによって要求される区切り文字です。 NIST KDF式はZIDi、ZIDr、両当事者に知られているいくつかのオプションのノンス材料を含む「コンテキスト」フィールドを有しています。 Lは、HMACの出力のビットの長さを超えない、32ビットのビッグエンディアンの正の整数です。 KDFの出力は、左端のLビットに切り捨てられます。 SHA-384がネゴシエートハッシュアルゴリズムである場合、HMACはHMAC-SHA-384であろう。従って、Lの最大値は384、ネゴシエートされたハッシュの長さであろう。
The ZRTP KDF is not to be confused with the SRTP KDF defined in [RFC3711].
ZRTP KDFは[RFC3711]で定義されたSRTP KDFと混同されるべきではありません。
Both DH mode and Preshared mode (but not Multistream mode) come to this common point in the protocol to derive ZRTPSess and the SAS from s0, via the ZRTP Key Derivation Function (Section 4.5.1). At this point, s0 has been calculated, as well as KDF_Context. These calculations are done only for the first media stream, not for Multistream mode.
DHモードと事前共有モード（ただし、マルチストリームではないモード）の両方ZRTP鍵導出関数（4.5.1）を介して、S0からZRTPSessとSASを導出するためのプロトコルでは、この共通点に来ます。この時点で、S0はKDF_Contextだけでなく、計算されています。これらの計算は、最初のメディアストリームのためではなく、マルチストリームモードのために行われています。
The ZRTPSess key is used only for these two purposes: 1) to generate the additional s0 keys (Section 4.4.3.2) for adding additional media streams to this session in Multistream mode, and 2) to generate the pbxsecret (Section 7.3.1) that may be cached for use in future sessions. The ZRTPSess key is kept for the duration of the call signaling session between the two ZRTP endpoints. That is, if there are two separate calls between the endpoints (in SIP terms, separate SIP dialogs), then a ZRTP Session Key MUST NOT be used across the two call signaling sessions. ZRTPSess MUST be destroyed no later than the end of the call signaling session.
）1）マルチストリームモードでこのセッションに追加のメディアストリームを追加するための追加のS0キー（セクション4.4.3.2）を生成するため、及び2）pbxsecret（セクション7.3.1を生成する：ZRTPSessキーは、これらの2つの目的のためにのみ使用されそれは、将来のセッションで使用するためにキャッシュされる場合があります。 ZRTPSessキーは2つのZRTPエンドポイント間のセッションをコールシグナリングの持続時間の間に保持されます。それはその後、ZRTPセッションキーが2つのコールシグナリングのセッションにまたがって使用してはいけません（SIP用語で、別のSIPダイアログ）エンドポイントの間に2つの別々の呼び出しは、存在する場合、です。 ZRTPSessは遅くともコールシグナリングセッションの終わりよりも破壊されてはなりません。
ZRTPSess = KDF(s0, "ZRTP Session Key", KDF_Context, negotiated hash length)
ZRTPSess = KDF（S0、 "ZRTPセッションキー"、KDF_Context、交渉されたハッシュ長）
Note that KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate ZRTPSess.
KDF_Contextは、各メディアストリームに対して一意であるが、最初のメディアストリームがZRTPSessを計算するために許可されていることに注意してください。
There is only one Short Authentication String (SAS) (Section 7) computed per call, which is applicable to all media streams derived from a single DH key agreement in a ZRTP session. KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate sashash.
ZRTPセッションで、単一のDHキー合意から派生したすべてのメディアストリームに適用される唯一のショート認証文字列（SAS）の呼び出しごとに計算された（第7節）が、あります。 KDF_Contextは、各メディアストリームに対して一意であるが、最初のメディアストリームはsashashを計算することが許されます。
sashash = KDF(s0, "SAS", KDF_Context, 256)
sashash = KDF（S0、 "SAS"、KDF_Context、256）
sasvalue = sashash [truncated to leftmost 32 bits]
sasvalue = sashash [左端の32ビットに切り捨て]
Despite the exposure of the SAS to the two parties, the rest of the keying material is protected by the key separation properties of the KDF (Section 4.5.1).
両当事者へのSASの暴露にもかかわらず、キーイング材料の残りの部分は、KDF（4.5.1項）の主要な分離特性によって保護されています。
ZRTP-enabled VoIP clients may need to support additional forms of communication, such as text chat, instant messaging, or file transfers. These other forms of communication may need to be encrypted, and would benefit from leveraging the ZRTP key exchange used for the VoIP part of the call. In that case, more key material
ZRTP対応のVoIPクライアントは、テキストチャット、インスタントメッセージング、またはファイル転送などの通信の追加の形式をサポートする必要があるかもしれません。コミュニケーションのこれらの他の形態は、暗号化する必要があるかもしれない、とコールのVoIPの部分に使用ZRTP鍵交換を活用するの恩恵を受けるだろう。その場合には、より多くのキーマテリアル
MAY be derived and "exported" from the ZRTP protocol and provided as a shared secret to the VoIP client for these non-VoIP purposes. The application can use this exported key in application-specific ways, outside the scope of the ZRTP protocol.
派生とZRTPプロトコルから「エクスポート」とこれらの非VoIPの目的のためのVoIPクライアントに共有シークレットとして提供することができます。アプリケーションはZRTPプロトコルの範囲の外に、アプリケーション固有の方法でこのエクスポートされたキーを使用することができます。
ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash length)
ExportedKey = KDF（S0、 "エクスポートキー"、KDF_Context、ネゴシエートされたハッシュ長）
Only one ExportedKey is computed per call. KDF_Context is unique for each media stream, but only the first media stream is permitted to calculate ExportedKey.
一つだけExportedKeyは、コールごとに計算されます。 KDF_Contextは、各メディアストリームに対して一意であるが、最初のメディアストリームはExportedKeyを計算することが許されます。
The application may use this exported key to derive other subkeys for various non-ZRTP purposes, via a KDF using separate KDF label strings defined by the application. This key or its derived subkeys can be used for encryption, or used to authenticate other key exchanges carried out by the application, protected by ZRTP's MiTM defense umbrella. The exported key and its descendants may be used for as long as needed by the application, maintained in a separate crypto context that may outlast the VoIP session.
アプリケーションは、アプリケーションによって定義された別のKDFラベルの文字列を使用してKDFを経て、様々な非ZRTPの目的のために他のサブキーを導出するために、このエクスポートされたキーを使用することができます。このキーまたはその派生サブキーは、暗号化に使用される、またはZRTPのMITM防衛の傘によって保護されたアプリケーションによって行われ、他のキー交換を認証するために使用することができます。エクスポートされたキーおよびその子孫であればVoIPセッションを長持ちすることができる別の暗号コンテキストで維持アプリケーションによって必要とされるようにするために使用することができます。
At this point in DH mode or Preshared mode, the two endpoints proceed on to the key derivations in Section 4.5.3, now that there is a defined s0 and ZRTPSess key.
DHモードまたは事前共有モードでは、この時点では、2つのエンドポイントが定義されてS0とZRTPSessキーがあることを、今、4.5.3にキー導出するに進みます。
DH mode, Multistream mode, and Preshared mode all come to this common point in the protocol to derive a set of keys from s0. It can be assumed that s0 has been calculated, as well the ZRTPSess key and KDF_Context. A separate s0 key is associated with each media stream.
DHモード、マルチストリームモード、および事前共有モードでは、すべてのS0からキーのセットを導出するためのプロトコルでは、この共通点に来ます。 S0が同様に、ZRTPSessキーとKDF_Contextを計算されたものとすることができます。別S0キーは、各メディア・ストリームに関連付けられています。
Subkeys are not drawn directly from s0, as done in NIST SP 800-56A. To enhance key separation, ZRTP uses s0 to key a Key Derivation Function (Section 4.5.1) based on [NIST-SP800-108]. Since s0 already included total_hash in its derivation, it is redundant to use total_hash again in the KDF Context in all the invocations of the KDF keyed by s0. Nonetheless, NIST SP 800-108 always requires KDF Context to be defined for the KDF, and nonce material is required in some KDF invocations (especially for Multistream mode and Preshared mode), so total_hash is included as a nonce in the KDF Context.
NIST SP 800-56Aに行ったようサブキーは、S0から直接描かれているわけではありません。キー分離を強化するために、ZRTPは[NIST-SP800-108]に基づいて、鍵導出関数（4.5.1）をキーにS0を使用しています。 S0は既にその派生でtotal_hashが含まれているので、S0をキーKDFのすべての呼び出しでKDFコンテキストで再度total_hash使用するのは冗長です。それにもかかわらず、NIST SP 800から108は、常にKDFのために定義されるKDFコンテキストを必要とし、ノンス材料は（特にマルチストリームモードと事前共有モード）いくつかKDF呼び出しに必要とされるので、total_hashはKDFコンテキストにおけるナンスとして含まれます。
Separate SRTP master keys and master salts are derived for use in each direction for each media stream. Unless otherwise specified, ZRTP uses SRTP with no Master Key Identifier (MKI), 32-bit authentication using HMAC-SHA1, AES-CM 128 or 256-bit key length, 112-bit session salt key length, 2^48 key derivation rate, and SRTP prefix length 0. Secure RTCP (SRTCP) is also used, deriving the
別SRTPマスタ鍵とマスター塩は、各メディアストリームのための各方向で使用するために導出されます。特に断りのない限り、ZRTPはないマスターキー識別子（MKI）、HMAC-SHA1を使用して32ビットの認証、AES-CM 128または256ビットの鍵長、112ビットのセッション塩鍵長、2 ^ 48鍵導出率とSRTPを使用し、およびSRTPプレフィックスは長さ0セキュアRTCP（SRTCP）も導出、使用されています
SRTCP keys from the same master keys and salts as SRTP, using the mechanisms specified in [RFC3711], without requiring a separate ZRTP negotiation for RTCP.
RTCPのための別個のZRTPネゴシエーションを必要とせずに、[RFC3711]で指定されたメカニズムを使用して、SRTPと同じマスターキーおよびその塩からSRTCPキー、。
The ZRTP initiator encrypts and the ZRTP responder decrypts packets by using srtpkeyi and srtpsalti, while the ZRTP responder encrypts and the ZRTP initiator decrypts packets by using srtpkeyr and srtpsaltr. The SRTP key and salt values are truncated (taking the leftmost bits) to the length determined by the chosen SRTP profile. These are generated by:
ZRTP開始剤は、暗号化とZRTPレスポンダの暗号化とZRTP開始剤がsrtpkeyrとsrtpsaltrを使用してパケットを復号化しながらZRTPレスポンダは、srtpkeyiとsrtpsaltiを使用してパケットを復号化します。 SRTP鍵とソルト値は、選択されたSRTPプロファイルによって決定される長さに（左端のビットを取る）切り捨てられます。これらはによって生成されます。
srtpkeyi = KDF(s0, "Initiator SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyi = KDF（S0、 "イニシエータSRTPマスターキー"、KDF_Context、ネゴシエートされたAES鍵長）
srtpsalti = KDF(s0, "Initiator SRTP master salt", KDF_Context, 112)
srtpsalti = KDF（S0、 "イニシエータSRTPマスタ塩"、KDF_Context、112）
srtpkeyr = KDF(s0, "Responder SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyr = KDF（S0、 "レスポンダSRTPマスターキー"、KDF_Context、ネゴシエートされたAES鍵長）
srtpsaltr = KDF(s0, "Responder SRTP master salt", KDF_Context, 112)
srtpsaltr = KDF（S0、 "レスポンダSRTPマスタ塩"、KDF_Context、112）
The MAC keys are the same length as the output of the underlying hash function in the KDF and are thus generated without truncation. They are used only by ZRTP and not by SRTP. Different MAC keys are needed for the initiator and the responder to ensure that GoClear messages in each direction are unique and can not be cached by an attacker and reflected back to the endpoint.
MAC鍵はKDFで、基礎となるハッシュ関数の出力と同じ長さであり、したがって切り捨てずに生成されます。彼らはZRTPではなくSRTPによって使用されています。異なるMACキーは、各方向におけるGoClearメッセージは一意であり、攻撃者によってキャッシュされ、バックエンドポイントに反映されないことを保証するために、イニシエータとレスポンダーのために必要とされます。
mackeyi = KDF(s0, "Initiator HMAC key", KDF_Context, negotiated hash length)
mackeyi = KDF（S0、 "イニシエータHMACキー"、KDF_Context、ネゴシエートされたハッシュ長）
mackeyr = KDF(s0, "Responder HMAC key", KDF_Context, negotiated hash length)
mackeyr = KDF（S0、 "レスポンダHMACキー"、KDF_Context、ネゴシエートされたハッシュ長）
ZRTP keys are generated for the initiator and responder to use to encrypt the Confirm1 and Confirm2 messages. They are truncated to the same size as the negotiated SRTP key size.
ZRTPキーはCONFIRM1とConfirm2メッセージを暗号化するために使用するイニシエータとレスポンダに対して生成されます。彼らは交渉さSRTPキーサイズと同じサイズに切り捨てられます。
zrtpkeyi = KDF(s0, "Initiator ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyi = KDF（S0、 "イニシエータZRTPキー"、KDF_Context、ネゴシエートされたAES鍵長）
zrtpkeyr = KDF(s0, "Responder ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyr = KDF（S0、 "レスポンダZRTPキー"、KDF_Context、ネゴシエートされたAES鍵長）
All key material is destroyed as soon as it is no longer needed, no later than the end of the call. s0 is erased in Section 4.6.1, and the rest of the session key material is erased in Sections 4.7.2.1 and 4.7.3.
すべての主要材料は、遅くともコールの終了よりも、できるだけ早くそれはもはや必要とされて破壊されていません。 S0は、セクション4.6.1に消去され、セッションキーマテリアルの残りの部分は、セクション4.7.2.1および4.7.3で消去されます。
The Confirm1 and Confirm2 messages (Figure 10) contain the cache expiration interval (defined in Section 4.9) for the newly generated retained shared secret. The flagoctet is an 8-bit unsigned integer made up of these flags: the PBX Enrollment flag (E) defined in Section 7.3.1, the SAS Verified flag (V) defined in Section 7.1, the Allow Clear flag (A) defined in Section 4.7.2, and the Disclosure flag (D) defined in Section 11.
CONFIRM1とConfirm2メッセージ（図10）は、新たに共有秘密を保持し、生成のため（4.9節で定義された）キャッシュの有効期間が含まれています。 flagoctetは、これらのフラグで構成された8ビットの符号なし整数である：7.3.1項、セクション7.1で定義されたSAS認証フラグ（V）で定義された許可クリアフラグ（A）で定義されたPBX登録フラグ（E）セクション4.7.2、およびセクション11で定義された公開フラグ（D）。
flagoctet = (E * 2^3) + (V * 2^2) + (A * 2^1) + (D * 2^0)
flagotstet =（E * 2 ^ H）+（B * 2 ^ 2）+（A * 2 ^ 1）+（D * 2 ^ 0）
Part of the Confirm1 and Confirm2 messages are encrypted using full-block Cipher Feedback Mode and contain a 128-bit random Cipher FeedBack (CFB) Initialization Vector (IV). The Confirm1 and Confirm2 messages also contain a MAC covering the encrypted part of the Confirm1 or Confirm2 message that includes a string of zeros, the signature length, flag octet, cache expiration interval, signature type block (if present), and signature (Section 7.2) (if present). For the responder:
CONFIRM1とConfirm2メッセージの一部は、フルブロック暗号フィードバックモードを使用して暗号化され、128ビットのランダム暗号帰還型（CFB）初期化ベクトル（IV）を含有しています。 CONFIRM1とConfirm2メッセージは、ゼロの列を含むCONFIRM1またはConfirm2メッセージ、署名長、フラグオクテット、キャッシュの有効期間、署名型ブロック（存在する場合）、署名（セクション7.2の暗号化された部分を覆ってMACを含みます） （存在する場合）。応答者の場合：
confirm_mac = MAC(mackeyr, encrypted part of Confirm1)
confirm_mac = MAC（mackeyr、CONFIRM1の暗号化された部分）
For the initiator:
イニシエータの場合：
confirm_mac = MAC(mackeyi, encrypted part of Confirm2)
confirm_mac = MAC（mackeyi、Confirm2の暗号化された部分）
The mackeyi and mackeyr keys are computed in Section 4.5.3.
mackeyiとmackeyrキーは、セクション4.5.3で計算されています。
The exchange is completed when the responder sends either the Conf2ACK message or the responder's first SRTP media packet (with a valid SRTP auth tag). The initiator MUST treat the first valid SRTP media from the responder as equivalent to receiving a Conf2ACK. The responder may respond to Confirm2 with either SRTP media, Conf2ACK, or both, in whichever order the responder chooses (or whichever order the "cloud" chooses to deliver them).
レスポンダがConf2ACKメッセージまたは（有効SRTPの認証タグ付き）応答の最初のSRTPメディアパケットのいずれかを送信するときに交換が完了しています。イニシエータはConf2ACKを受信したことに相当するものとして応答者からの最初の有効なSRTPメディアを扱わなければなりません。応答は、応答の選択（又はいずれ注文「雲」がそれらを提供することを選択した）を注文する方で、SRTPメディア、Conf2ACK、またはその両方のいずれかでConfirm2に応答することができます。
After receiving the Confirm messages, both parties must now update their retained shared secret rs1 in their respective caches, provided the following conditions hold:
確認メッセージを受信した後、両当事者は今、それぞれのキャッシュにその保持共有秘密RS1を更新する必要があり、以下の条件のホールドを提供します：
(1) This key exchange is either DH or Preshared mode, not Multistream mode, which does not update the cache.
（1）この鍵交換は、DHまたは事前共有モードではなく、キャッシュを更新しないマルチストリームモード、のいずれかです。
(2) Depending on the values of the cache expiration intervals that are received in the two Confirm messages, there are some scenarios that do not update the cache, as explained in Section 4.9.
（2）2つの確認メッセージで受信されたキャッシュの有効期限の間隔の値に応じて、4.9節で説明したように、キャッシュを更新していないいくつかのシナリオがあります。
(3) The responder MUST receive the initiator's Confirm2 message before updating the responder's cache.
（3）レスポンダは、レスポンダのキャッシュを更新する前に、イニシエータのConfirm2メッセージを受信する必要があります。
(4) The initiator MUST receive either the responder's Conf2ACK message or the responder's SRTP media (with a valid SRTP auth tag) before updating the initiator's cache.
（4）イニシエータは、イニシエータのキャッシュを更新する前に、応答者のConf2ACKメッセージまたは（有効SRTPの認証タグ付き）応答のSRTPメディアのいずれかを受けなければなりません。
The cache update may also be affected by a cache mismatch, according to Section 4.6.1.1.
キャッシュの更新はまた、セクション4.6.1.1によると、キャッシュの不整合によって影響を受ける可能性があります。
For DH mode only, before updating the retained shared secret rs1 in the cache, each party first discards their old rs2 and copies their old rs1 to rs2. The old rs1 is saved to rs2 because of the risk of session interruption after one party has updated his own rs1 but before the other party has enough information to update her own rs1. If that happens, they may regain cache sync in the next session by using rs2 (per Section 4.3). This mitigates the well-known Two Generals' Problem [Byzantine]. The old rs1 value is not saved in Preshared mode.
DHモードの場合のみ、キャッシュに保持共有秘密RS1を更新する前に、各当事者は、まず自分の古いRS2及びRS2コピーへの古いRS1を破棄します。古いRS1は、一方の当事者が自分のRS1を更新した後であるため、セッションの中断のリスクのRS2に保存されますが、相手の前に自分のRS1を更新するのに十分な情報を持っています。その場合、彼らは（セクション4.3あたり）RS2を使用して次のセッションでキャッシュの同期を取り戻すことがあります。これは、[ビザンチン]よく知られている二人の将軍問題を軽減します。古いRS1の値は事前共有モードで保存されていません。
For DH mode and Preshared mode, both parties compute a new rs1 value from s0 via the ZRTP key derivation function (Section 4.5.1):
DHモードと事前共有モードでは、両当事者がZRTP鍵導出関数（4.5.1）を経由してS0から新しいRS1値を計算します。
rs1 = KDF(s0, "retained secret", KDF_Context, 256)
RS1 = KDF（S0、 "秘密保持"、KDF_Context、256）
Note that KDF_Context is unique for each media stream, but only the first media stream is permitted to update rs1.
KDF_Contextは、各メディアストリームに対して一意であるが、最初のメディアストリームはRS1を更新するために許可されていることに注意してください。
Each media stream has its own s0. At this point in the protocol for each media stream, the corresponding s0 MUST be erased.
各メディアストリームは、独自のS0を持っています。各メディアストリームのためのプロトコルのこの時点で、対応S0は消去されなければなりません。
If a shared secret cache mismatch (as defined in Section 4.3.2) is detected in the current session, it indicates a possible MiTM attack. However, there may be evidence to the contrary, if either one of the following conditions are met:
共有秘密キャッシュの不一致が（4.3.2項で定義されている）現在のセッションで検出された場合、それは可能なMITM攻撃を示します。以下のいずれかの条件が満たされている場合は、これに反する証拠があるかもしれません。
o Successful use of the mechanism described in Section 8.1.1, but only if fully supported by end-to-end integrity-protected delivery of the a=zrtp-hash in the signaling via SIP Identity [RFC4474] or better still, Dan Wing's SIP Identity using Media Path [SIP-IDENTITY]. This allows authentication of the DH exchange without human assistance.
まだ良いO成功8.1.1項で説明したメカニズムを使用するが、完全にSIPアイデンティティを介したシグナル伝達において、A = ZRTP-ハッシュのエンド・ツー・エンドの完全性保護された配信でサポートされている場合のみ、[RFC4474]や、ダン・ウイングさんメディアパス[SIP-IDENTITY]を使用してSIPアイデンティティ。これは人間の援助なしDH交換の認証を行うことができます。
o A good signature is received and verified using the digital signature feature on the SAS hash, as described in Section 7.2, if this feature is supported.
O良い署名が受信され、この機能がサポートされている場合、セクション7.2に記載されているように、SASハッシュのデジタル署名機能を使用して検証されます。
If there is a cache mismatch in the absence of the aforementioned mitigating evidence, the cache update MUST be delayed in the current session until the user verbally compares the SAS with his partner during the call and confirms a successful SAS verify via his user interface as described in Section 7.1. If the session ends before that happens, the cache update is not performed, leaving the rs1/rs2 values unmodified in the cache. Regardless of whether a cache mismatch occurs, s0 must still be erased.
前述の緩和的な証拠が存在しない場合にキャッシュの不一致がある場合は、ユーザが口頭で通話中に彼のパートナーでSASを比較して説明するように成功したSASは、彼のユーザインタフェースを介して確認する確認するまで、キャッシュの更新は、現在のセッションで遅延させなければなりませんセクション7.1インチそれが起こる前にセッションが終了した場合、キャッシュの更新は、キャッシュ内の未修正のRS1 / RS2値を残して、実行されません。かかわらず、キャッシュの不一致が発生するかどうかの、S0はまだ消去されなければなりません。
If no cache entry exists, as is the case in the initial call, the cache update is handled in the normal fashion.
何のキャッシュエントリが存在しない場合は、最初の呼び出しの場合のように、キャッシュの更新は、通常の方法で処理されます。
A ZRTP session is normally terminated at the end of a call, but it may be terminated early by either the Error message or the GoClear message.
ZRTPセッションは、通常、コールの終了時に終了したが、それはエラーメッセージやGoClearメッセージのいずれかによって早期に終了させることができます。
The Error message (Section 5.9) is used to terminate an in-progress ZRTP exchange due to an error. The Error message contains an integer Error Code for debugging purposes. The termination of a ZRTP key agreement exchange results in no updates to the cached shared secrets and deletion of all crypto context for that media stream. The ZRTP Session key, ZRTPSess, is only deleted if all ZRTP media streams that are using it are terminated.
エラーメッセージ（セクション5.9）エラーのために進行中ZRTP交換を終了するために使用されます。エラーメッセージは、デバッグ目的のために、整数エラーコードが含まれています。キャッシュされた共有秘密とそのメディアストリームのためのすべての暗号コンテキストの削除にありませんアップデートでZRTPキー合意交換結果の終了。それを使用しているすべてのZRTPメディアストリームが終了している場合ZRTPセッションキー、ZRTPSessは、のみ削除されます。
Because no key agreement has been reached, the Error message cannot use the same MAC protection as the GoClear message. A denial of service is possible by injecting fake Error messages. (However, even if the Error message were somehow designed with integrity protection, it would raise other questions. What would a badly formed Error message mean if it were sent to report a badly formed message? A good message?)
何の鍵合意に達しされていないため、エラーメッセージはGoClearメッセージとして同じMAC保護を使用することはできません。サービス拒否は、偽のエラーメッセージを注入することにより可能です。 （エラーメッセージが何とか完全性保護を用いて設計した場合でもしかし、それは他の問題を提起するだろう。それがひどく形成されたメッセージを報告するために送信された場合は不正な形式のエラーメッセージは何を意味するのでしょうか？良いメッセージを？）
The GoClear message (Section 5.11) is used to switch from SRTP to RTP, usually because the user has chosen to do that by pressing a button. The GoClear uses a MAC of the Message Type Block sent in the GoClear message computed with the mackey derived from the shared secret. This MAC is truncated to the leftmost 64 bits. When sent by the initiator:
GoClearメッセージ（セクション5.11）は、ユーザがボタンを押すことによってこれを行うために選択されている通常ため、SRTPからRTPへ切り替えるために使用されます。 GoClearは、共有秘密に由来マッキーで計算GoClearメッセージで送信されるメッセージタイプブロックのMACを使用します。このMACは、左端の64ビットに切り捨てられます。イニシエータによって送信された場合：
clear_mac = MAC(mackeyi, "GoClear ")
clear_mac = MAC（mackeyi、 "GoClear"）
When sent by the responder:
場合は、レスポンダによって送信されました：
clear_mac = MAC(mackeyr, "GoClear ")
clear_mac = MAC（mackeyr、 "GoClear"）
Both of these MACs are calculated across the 8-octet "GoClear " Message Type Block, including the trailing space.
これらのMACの両方は、末尾のスペースを含め、8オクテット「GoClear」メッセージタイプブロックにわたって計算されます。
A GoClear message that does not receive a ClearACK response must be resent. If a GoClear message is received with a bad MAC, ClearACK MUST NOT be sent and the GoClear MUST NOT be acted on by the recipient, but it MAY be processed as a security exception, perhaps by logging or alerting the user.
ClearACK応答を受信しないGoClearメッセージを再送する必要があります。 GoClearメッセージが悪いMACで受信された場合、ClearACKを送ってはいけませんとGoClearは、受信者によって作用してはならないが、それはおそらく、ログインするか、ユーザに警告することによって、セキュリティ例外として処理されてもよいです。
A ZRTP endpoint MAY choose to accept GoClear messages after the session has switched to SRTP, allowing the session to revert to RTP. This is indicated in the Confirm1 or Confirm2 messages (Figure 10) by setting the Allow Clear flag (A). If an endpoint sets the Allow Clear (A) flag in their Confirm message, it indicates that they support receiving GoClear messages.
ZRTPエンドポイントは、セッションがセッションはRTPに戻すことができ、SRTPに切り替わった後GoClearメッセージを受け入れることを選ぶかもしれません。これは、許可フラグクリア（A）を設定することによりCONFIRM1又はConfirm2メッセージ（図10）に示されています。エンドポイントは、その確認メッセージで許可クリア（A）フラグを設定した場合、それは彼らがGoClearメッセージを受信をサポートすることを示しています。
A ZRTP endpoint that receives a GoClear MUST authenticate the message by checking the clear_mac. If the message authenticates, the endpoint stops sending SRTP packets, and generates a ClearACK in response. It MUST also delete all the crypto key material for all the SRTP media streams, as defined in Section 4.7.2.1.
GoClearを受けZRTPエンドポイントはclear_macをチェックすることで、メッセージを認証しなければなりません。メッセージが認証した場合、エンドポイントは、SRTPパケットの送信を停止し、それに応答してClearACKを生成します。セクション4.7.2.1で定義されたように、それはまた、すべてのSRTPメディアストリームのためのすべての暗号化キーマテリアルを削除しなければなりません。
Until confirmation from the user is received (e.g., clicking a button, pressing a dual-tone multi-frequency (DTMF) key, etc.), the ZRTP endpoint MUST NOT resume sending RTP packets. The endpoint then renders to the user an indication that the media session has switched to clear mode and waits for confirmation from the user. This blocks the flow of sensitive discourse until the user is forced to take notice that he's no longer protected by encryption. To prevent pinholes from closing or NAT bindings from expiring, the ClearACK message MAY be resent at regular intervals (e.g., every 5 seconds) while waiting for confirmation from the user. After confirmation of the notification is received from the user, the sending of RTP packets may begin.
利用者からの確認が受信されるまで（例えば、など、デュアルトーン多重周波数（DTMF）キーを押すと、ボタンをクリックする）、ZRTPエンドポイントは、RTPパケットの送信を再開してはなりません。エンドポイントは、ユーザにメディアセッションがユーザからの確認のためにクリア・モードと待機に切り替わったことの表示をレンダリングします。このブロックは、ユーザまで敏感談話の流れは、彼はもはや暗号化によって保護されていますという通知を取ることを余儀なくされます。ユーザーからの確認を待っている間に期限切れから決算やNATバインディングからピンホールを防止するため、ClearACKメッセージは、定期的（例えば、5秒毎）に再送されるかもしれません。通知の確認がユーザから受信された後に、RTPパケットの送信を開始することができます。
After sending a GoClear message, the ZRTP endpoint stops sending SRTP packets. When a ClearACK is received, the ZRTP endpoint deletes the crypto context for the SRTP session, as defined in Section 4.7.2.1, and may then resume sending RTP packets.
GoClearメッセージを送信した後、ZRTPエンドポイントは、SRTPパケットの送信を停止します。 ClearACKが受信されると、ZRTPエンドポイントは、セクション4.7.2.1で定義されるように、SRTPセッションの暗号コンテキストを削除し、その後、RTPパケットの送信を再開することができます。
In the event a ClearACK is not received before the retransmissions of GoClear are exhausted, the key material is deleted, as defined in Section 4.7.2.1.
セクション4.7.2.1で定義されているGoClearの再送が排出される前にClearACKが受信されない場合には、キーマテリアルが、削除されます。
After the users have transitioned from SRTP media back to RTP media (clear mode), they may decide later to return to secure mode by manual activation, usually by pressing a GO SECURE button. In that case, a new secure session is initiated by the party that presses the button, by sending a new Commit message, leading to a new session key negotiation. It is not necessary to send another Hello message, as the two parties have already done that at the start of the call and thus have already discovered each other's ZRTP capabilities. It is possible for users to toggle back and forth between clear and secure modes multiple times in the same session, just as they could in the old days of secure PSTN phones.
ユーザーがバックRTPメディア（クリアモード）にSRTPメディアから移行した後、彼らは通常GO SECUREボタンを押すことにより、手動活性化によってモードを確保するために戻るには、後に決めることができます。その場合には、新しいセキュアなセッションは、新しいセッションキー交渉につながる、新しいコミットメッセージを送信することにより、ボタンを押すパーティによって開始されます。 2人の当事者がすでにコールの開始時にそれを行っているので、すでに互いのZRTP能力を発見したように、別のHelloメッセージを送信する必要はありません。ユーザーは、セキュアPSTN電話の昔にちょうど彼らが可能性として、同じセッションで前後に明確かつ安全なモード間を複数回切り替えることが可能です。
All SRTP session key material MUST be erased by the receiver of the GoClear message upon receiving a properly authenticated GoClear. The same key destruction MUST be done by the sender of GoClear message, upon receiving the ClearACK. This must be done for the key material for all of the media streams.
すべてのSRTPセッション鍵材料が正しく認証GoClearを受けてGoClearメッセージの受信機で消去されなければなりません。同じキー破壊ClearACKを受信すると、GoClearメッセージの送信者によって行われなければなりません。これは、メディアストリームのすべてのための重要な材料のために行われなければなりません。
All key material that would have been erased at the end of the SIP session MUST be erased, as described in Section 4.7.3, with the single exception of ZRTPSess. In this case, ZRTPSess is destroyed in a manner different from the other key material. Both parties replace ZRTPSess with a KDF-derived non-invertible function of itself:
ZRTPSessの唯一の例外で、セクション4.7.3で説明したように、SIPセッションの終了時に消去されていたであろうすべての主要材料は、消去されなければなりません。この場合、ZRTPSessは、他の鍵材料とは異なる方法で破壊されます。両当事者は、自身のKDF由来の非可逆機能をZRTPSessを置き換えます。
ZRTPSess = KDF(ZRTPSess, "New ZRTP Session", (ZIDi || ZIDr), negotiated hash length)
ZRTPSess = KDF（ZRTPSess、 "新ZRTPセッション"、（ZIDi || ZIDr）、ハッシュ長を交渉し）
ZRTPSess will be replaced twice if a session generates separate GoClear messages for both audio and video streams, and the two endpoints need not carry out the replacements in the same order.
セッションは、オーディオとビデオストリームの両方に別々のGoClearメッセージを生成した場合ZRTPSessは二回置き換えられます、そして2つのエンドポイントが同じ順序で置換を実行する必要はありません。
The destruction of key material meets the requirements of Perfect Forward Secrecy (PFS), but still preserves a new version of ZRTPSess, so that the user can later re-initiate secure mode during the same session without performing another Diffie-Hellman calculation using Multistream mode, which requires and assumes the existence of ZRTPSess with the same value at both ZRTP endpoints. A new key negotiation after a GoClear SHOULD use a Multistream Commit message.
ユーザが後でマルチストリームモードを使用して別のDiffie-Hellman計算を行うことなく同じセッション中にセキュアモードを-INITIATE再できるように鍵材料の破壊は、完全転送秘密（PFS）の要件を満たしているが、それでもZRTPSessの新しいバージョンを保存します両方ZRTPエンドポイントで同じ値を持つZRTPSessの存在を必要としとります。 GoClear後に新しい鍵交渉は、マルチストリームがメッセージをコミット使用すべきです。
Note: Multistream mode is preferred over a Diffie-Hellman mode since this does not require the generation of a new hash chain and a new signaling exchange to exchange new Hello Hash values.
注：これは、新しいハローハッシュ値を交換するために新たなハッシュチェーンの生成および新たなシグナリング交換を必要としないので、マルチストリームモードのDiffie-Hellmanモードよりも好ましいです。
Later, at the end of the entire call, ZRTPSess is finally destroyed along with the other key material, as described in Section 4.7.3.
セクション4.7.3で説明したように、後に、全体のコールの終了時に、ZRTPSessは、最終的には、他の主要材料と一緒に破壊されます。
All SRTP session key material MUST be erased by both parties at the end of the call. In particular, the destroyed key material includes the SRTP session keys and salts, SRTP master keys and salts, and all material sufficient to reconstruct the SRTP keys and salts, including ZRTPSess and s0 (although s0 should have been destroyed earlier, in Section 4.6.1). This must be done for the key material for all of the media streams. The only exceptions are the cached shared secrets needed for future sessions, including rs1, rs2, and pbxsecret.
すべてのSRTPセッション鍵材料は、コールの終了時に、両当事者によって消去されなければなりません。 S0は、セクション4.6で、以前に破壊されているべきであるが、特に、破壊された鍵材料は、（SRTPセッションキーと塩、SRTPマスタ鍵及び塩、及びZRTPSess含むSRTPキーと塩を再構築するのに十分なすべての材料、及びS0を含みます。 1）。これは、メディアストリームのすべてのための重要な材料のために行われなければなりません。唯一の例外はRS1、RS2、およびpbxsecretを含む将来のセッションのために必要なキャッシュされた共有秘密です。
The ZRTP protocol uses random numbers for cryptographic key material, notably for the DH secret exponents and nonces, which must be freshly generated with each session. Whenever a random number is needed, all of the following criteria must be satisfied:
ZRTPプロトコルは、特に新鮮に各セッションで生成されなければならDH秘密指数とナンスのために、暗号化キーマテリアルのために乱数を使用しています。乱数が必要とされるたびに、次の基準のすべてを満たす必要があります。
Random numbers MUST be freshly generated, meaning that they must not have been used in a previous calculation.
乱数はたて、彼らが前の計算で使用されていてはならないことを意味し、生成されなければなりません。
When generating a random number k of L bits in length, k MUST be chosen with equal probability from the range of [1 < k < 2^L].
長さLビットの乱数kを生成するとき、kは[1 <K <2 ^ L]の範囲から等しい確率で選択しなければなりません。
It MUST be derived from a physical entropy source, such as radio frequency (RF) noise, acoustic noise, thermal noise, high-resolution timings of environmental events, or other unpredictable physical sources of entropy. One possible source of entropy for a VoIP client would be microphone noise. For a detailed explanation of cryptographic grade random numbers and guidance for collecting suitable entropy, see [RFC4086] and Chapter 10 of "Practical Cryptography" [Ferguson]. The raw entropy must be distilled and processed through a deterministic random-bit generator (DRBG). Examples of DRBGs may be found in [NIST-SP800-90], in [Ferguson], and in [RFC5869]. Failure to use true entropy from the physical environment as a basis for generating random cryptographic key material would lead to a disastrous loss of security.
このような無線周波数（RF）ノイズ、音響ノイズ、熱雑音、環境イベント、又はエントロピーの他の予測不可能な物理ソースの高分解能タイミングとして、物理的なエントロピソースから導出されなければなりません。 VoIPクライアントのためのエントロピーの一つの可能なソースは、マイクのノイズになります。暗号グレード乱数と、適切なエントロピーを収集するためのガイダンスの詳細については、「実用的な暗号化」[ファーガソン]の[RFC4086]および第10章を参照してください。生のエントロピーは、決定論的ランダムビット発生器（DRBG）を介して蒸留し、処理されなければなりません。 DRBGsの例は、[ファーガソン]、および[RFC5869]に、[NIST-SP800-90]に見出すことができます。ランダムな暗号化キーマテリアルを生成するための基礎としての物理的な環境から真のエントロピーを使用しないと、セキュリティの悲惨な損失につながります。
Each instance of ZRTP has a unique 96-bit random ZRTP ID, or ZID, that is generated once at installation time. It is used to look up retained shared secrets in a local cache. A single global ZID for a single installation is the simplest way to implement ZIDs. However, it is specifically not precluded for an implementation to use multiple ZIDs, up to the limit of a separate one per callee. This then turns it into a long-lived "association ID" that does not apply to any other associations between a different pair of parties. It is a goal of this protocol to permit both options to interoperate freely. A PBX acting as a trusted man in the middle will also generate a single ZID and use that ZID for all endpoints behind it, as described in Section 10.
ZRTPの各インスタンスは、インストール時に一度生成される一意の96ビットランダムZRTP ID、またはZIDを有します。ローカルキャッシュに共有秘密を保持するルックアップするために使用されています。単一のインストールのための単一のグローバルZIDはZIDsを実装する最も簡単な方法です。しかし、具体的に呼び出し先ごとに別々の一方の限界まで、複数ZIDsを使用する実装のために除外されません。そして、これは、当事者の異なるペアの間に、他の団体には適用されません長寿命の「アソシエーションID」に変換します。自由に相互運用するために両方のオプションを可能にするために、このプロトコルの目標です。途中で信頼できる男として動作するPBXは、単一のZIDを生成し、第10項で説明したように、その背後にあるすべてのエンドポイント用のZIDことを使用します。
There is no protocol mechanism to invalidate a previously used ZID. An endpoint wishing to change ZIDs would simply generate a new one and begin using it.
以前に使用ZIDを無効にするには、noプロトコルメカニズムはありません。 ZIDsを変更したいエンドポイントは、単に新しいものを生成し、それを使用し始めるでしょう。
The ZID should not be hard coded or hard defined in the firmware of a product. It should be randomly generated by the software and stored at installation or initialization time. It should be randomly generated rather than allocated from a preassigned range of ZID values, because 96 bits should be enough to avoid birthday collisions in realistic scenarios.
ZIDは、ハードコードまたはハード製品のファームウェアで定義されるべきではありません。これは、ランダムにソフトウェアによって生成され、インストールや初期設定時に格納する必要があります。 96ビットは、現実的なシナリオで誕生日の衝突を回避するのに十分でなければならないので、それはランダムに生成されなくZID値の事前に割り当てられた範囲から割り当てられるべきです。
Each time a new s0 is calculated, a new retained shared secret rs1 is generated and stored in the cache, indexed by the ZID of the other endpoint. This cache updating is described in Section 4.6.1. For the new retained shared secret, each endpoint chooses a cache expiration value that is an unsigned 32-bit integer of the number of seconds that this secret should be retained in the cache. The time interval is relative to when the Confirm1 message is sent or received.
新しいS0が計算されるたびに、新しい保持共有秘密RS1が生成され、キャッシュに格納され、他のエンドポイントのZIDによってインデックスされます。このキャッシュの更新は、セクション4.6.1に記載されています。新しい保持共有秘密のために、各エンドポイントは、この秘密は、キャッシュに保持されなければならない秒数の符号なし32ビット整数であり、キャッシュの有効期限の値を選択します。時間間隔はCONFIRM1メッセージが送信または受信されたときに相対的です。
The cache intervals are exchanged in the Confirm1 and Confirm2 messages (Figure 10). The actual cache interval used by both endpoints is the minimum of the values from the Confirm1 and Confirm2 messages. A value of 0 seconds means the newly computed shared secret SHOULD NOT be stored in the cache, and if a cache entry already exists from an earlier call, the stored cache interval should be set to 0. This means if either Confirm message contains a null cache expiration interval, and there is no cache entry already defined, no new cache entry is created. A value of 0xffffffff means the secret should be cached indefinitely and is the recommended value. If the ZRTP exchange is Multistream mode, the field in the Confirm1 and Confirm2 is set to 0xffffffff and is ignored; the cache is not updated.
キャッシュ間隔はCONFIRM1とConfirm2メッセージ（図10）に交換されます。両方のエンドポイントによって使用される実際のキャッシュ間隔はCONFIRM1とConfirm2メッセージからの値の最小値です。 0秒の値が新たに算出された共有秘密は、キャッシュに格納されません。また、キャッシュエントリが既に以前の呼び出しから存在している場合、保存されたキャッシュ間隔はどちらかの確認メッセージがnullが含まれている場合これは、0に設定する必要があります意味しますキャッシュの有効期間は、すでに定義されたキャッシュエントリが存在しない、新たなキャッシュエントリが作成されません。値0xFFFFFFFFは秘密が無期限にキャッシュされるべきであることを意味し、推奨値です。 ZRTP交換は、マルチストリームモード、は0xffffffffに設定され、無視されCONFIRM1とConfirm2でフィールドがある場合は、キャッシュが更新されません。
The expiration interval need not be used to force the deletion of a shared secret from the cache when the interval has expired. It just means the shared secret MAY be deleted from that cache at any point after the interval has expired without causing the other party to note it as an unexpected security event when the next key negotiation occurs between the same two parties. This means there need not be perfectly synchronized deletion of expired secrets from the two caches, and makes it easy to avoid a race condition that might otherwise be caused by clock skew.
期限切れ間隔は間隔が経過したキャッシュから共有秘密の削除を強制するために使用する必要はありません。それはちょうど間隔は次のキー交渉が同じ2つの当事者間で発生したときに相手が予期しないセキュリティイベントとしてそれを注意させることなく、有効期限が切れた後に、共有秘密は、任意の時点でそのキャッシュから削除することができることを意味します。これは完全に2つのキャッシュから期限切れの秘密の削除が同期されない必要があることを意味し、それは簡単そうでないクロック・スキューが原因である可能性があり競合状態を回避することができます。
If the expiration interval is not properly agreed to by both endpoints, it may later result in false alarms of MiTM attacks, due to apparent cache mismatches (Section 4.3.2).
期限切れ間隔が適切に両方のエンドポイントが合意されていない場合、それは後でによる見かけ上のキャッシュの不一致（4.3.2項）にMITM攻撃の誤報をもたらし得ます。
The relationship between a ZID and a SIP AOR is explained in Section 12.
ZIDとSIP AORとの間の関係は、セクション12で説明されています。
It is possible to implement a simplified but nonetheless useful (and still compliant) profile of the ZRTP protocol that does not support any caching of shared secrets. In this case, the users would have to rely exclusively on the verbal SAS comparison for every call. That is, unless MiTM protection is provided by the mechanisms in Section 8.1.1 or 7.2, which introduce their own forms of complexity.
共有秘密のいずれかのキャッシュをサポートしていませんZRTPプロトコルの単純化されたが、それでも便利な（そしてまだ準拠）プロファイルを実装することが可能です。この場合、ユーザーはすべての呼び出しのための口頭SASの比較だけに頼らなければならないでしょう。 MITM保護が複雑、独自の形式を導入し、セクション8.1.1または7.2でのメカニズムによって提供されていない限り、それは、あります。
If a ZRTP endpoint does not support the caching of shared secrets, it MUST set the cache expiration interval to zero, and MUST set the SAS Verified (V) flag (Section 7.1) to false. In addition, because the ZID serves mainly as a cache index, the ZID would not be required to maintain the same value across separate SIP sessions, although there is no reason why it should not.
ZRTPエンドポイントが共有秘密のキャッシュをサポートしていない場合、それはゼロにキャッシュの有効期間を設定しなければなりませんし、falseにSAS確認済み（V）フラグ（7.1節）を設定しなければなりません。 ZIDは、主キャッシュインデックスとして機能するので、なぜそれがいけない理由はないもののほかに、ZIDは、別々のSIPセッション間で同じ値を維持するために必要とされないであろう。
Cacheless operation would sacrifice the key continuity (Section 15.1) features, as well as Preshared mode (Section 4.4.2). Further, if the pbxsecret is also not cached, there would be no PBX trusted MiTM (Section 7.3) features, including the PBX security enrollment (Section 7.3.1) mechanism.
キャッシュレス操作は、キーの連続性（15.1）の機能だけでなく、事前共有モード（4.4.2）を犠牲にします。 pbxsecretもキャッシュされていない場合また、何のPBXはないだろうPBXのセキュリティ登録（7.3.1）機構を備えたMITM（7.3節）の機能を、信頼されました。
All ZRTP messages use the message format defined in Figure 2. All word lengths referenced in this specification are 32 bits, or 4 octets. All integer fields are carried in network byte order, that is, most-significant byte (octet) first, commonly known as big-endian.
全てZRTPメッセージは図2で定義されたメッセージフォーマットを使用し、本明細書で参照される全てのワード長は32ビット、または4つのオクテットです。すべての整数フィールドは、それが最初に、一般的にビッグエンディアンとして知られ、最上位バイト（オクテット）で、ネットワークバイト順に搬送されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Not Used (set to zero) | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie 'ZRTP' (0x5a525450) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZRTP Message (length depends on Message Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ZRTP Packet Format
図2：ZRTPパケットフォーマット
The Sequence Number is a count that is incremented for each ZRTP packet sent. The count is initialized to a random value. This is useful in estimating ZRTP packet loss and also detecting when ZRTP packets arrive out of sequence.
シーケンス番号が送信された各ZRTPパケットに対してインクリメントされたカウントです。カウントはランダムな値に初期化されます。これはZRTPパケット損失を推定し、ZRTPパケットが順序が狂って到着したときも検出するのに有用です。
The ZRTP Magic Cookie is a 32-bit string that uniquely identifies a ZRTP packet and has the value 0x5a525450.
ZRTPマジッククッキーを一意ZRTPパケットを識別し、値0x5a525450を有する32ビットのビット列です。
Source Identifier is the SSRC number of the RTP stream to which this ZRTP packet relates. For cases of forking or forwarding, RTP, and hence ZRTP, may arrive at the same port from several different sources -- each of these sources will have a different SSRC and may initiate an independent ZRTP protocol session. SSRC collisions would be disruptive to ZRTP. SSRC collision handling procedures are described in Section 4.1.
ソース識別子は、このZRTPパケットが関係するRTPストリームのSSRC番号です。フォークまたは転送、RTP、ひいてはZRTPのケースでは、いくつかの異なるソースから同じポートに到着することができる - これらのソースのそれぞれは、異なるSSRCを有し、独立ZRTPプロトコルセッションを開始することができます。 SSRC衝突がZRTPに破壊的になります。 SSRC衝突取り扱い方法は、4.1節で説明されています。
This format is clearly identifiable as non-RTP due to the first two bits being zero, which looks like RTP version 0, which is not a valid RTP version number. It is clearly distinguishable from STUN since the Magic Cookies are different. The 12 unused bits are set to zero and MUST be ignored when received. In early versions of this spec, ZRTP messages were encapsulated in RTP header extensions, which made ZRTP an eponymous variant of RTP. In later versions, the packet format changed to make it syntactically distinguishable from RTP.
このフォーマットは、有効RTPのバージョン番号ではないRTPバージョン0、のように見えている、原因最初の2ビットはゼロであることに、非RTPとして明確に識別可能です。マジッククッキーが異なっているので、それはSTUNとは明確に区別されます。 12の未使用のビットはゼロに設定され、受信時に無視されなければなりません。この仕様の初期バージョンでは、ZRTPメッセージはZRTP RTPの同名変異体からなるRTPヘッダ拡張内に封入しました。それ以降のバージョンでは、パケットフォーマットは、RTPから、それは文法的に区別できるように変更しました。
The ZRTP messages are defined in Figures 3 to 17 and are of variable length.
ZRTPメッセージ17に図3で定義され、可変長されています。
The ZRTP protocol uses a 32-bit Cyclic Redundancy Check (CRC) as defined in RFC 4960, Appendix B [RFC4960], in each ZRTP packet to detect transmission errors. ZRTP packets are typically transported by UDP, which carries its own built-in 16-bit checksum for integrity, but ZRTP does not rely on it. This is because of the effect of an undetected transmission error in a ZRTP message. For example, an undetected error in the DH exchange could appear to be an active man-in-the-middle attack. A false announcement of this by ZRTP clients can be psychologically distressing. The probability of such a false alarm hinges on a mere 16-bit checksum that usually protects UDP packets, so more error detection is needed. For these reasons, this belt-and-suspenders approach is used to minimize the chance of a transmission error affecting the ZRTP key agreement.
RFC 4960で定義されるようZRTPプロトコルは、伝送エラーを検出するために各ZRTPパケットに、付録B [RFC4960]、32ビット巡回冗長検査（CRC）を使用します。 ZRTPパケットは、一般的に整合性のために、独自の内蔵の16ビットのチェックサムを運ぶUDP、によって輸送されるが、ZRTPはそれに依存しません。これはZRTPメッセージで検出されない伝送エラーの影響です。例えば、DH交換で検出されないエラーがアクティブman-in-the-middle攻撃のように見えることができます。 ZRTPクライアントによって、この偽の発表は、心理的に悲惨なことができます。より多くのエラー検出が必要とされているので、このような誤警報の確率は、通常、UDPパケットを保護し、単なる16ビットのチェックサムの上にかかっています。これらの理由から、このベルトとサスペンダー・アプローチはZRTP鍵合意に影響を与える送信エラーの可能性を最小限にするために使用されます。
The CRC is calculated across the entire ZRTP packet shown in Figure 2, including the ZRTP header and the ZRTP message, but not including the CRC field. If a ZRTP message fails the CRC check, it is silently discarded.
CRCは、CRCフィールドを含むZRTPヘッダとZRTPメッセージを含む、図2に示す全体ZRTPパケットにわたって計算されないが。 ZRTPメッセージがCRCチェックに失敗した場合、それを黙って破棄されます。
ZRTP messages are designed to simplify endpoint parsing requirements and to reduce the opportunities for buffer overflow attacks (a good goal of any security extension should be to not introduce new attack vectors).
ZRTPメッセージは、エンドポイントの解析要件を簡素化し、（任意のセキュリティ拡張機能の良い目標は、新しい攻撃ベクトルを導入しないようにする必要があります）バッファオーバーフロー攻撃の機会を減らすために設計されています。
ZRTP uses a block of 8 octets (2 words) to encode the Message Type. 4-octet (1 word) blocks are used to encode Hash Type, Cipher Type, Key Agreement Type, and Authentication Tag Type. The values in the blocks are ASCII strings that are extended with spaces (0x20) to make them the desired length. Currently defined block values are listed in Tables 1-6.
ZRTPは、メッセージタイプをエンコードするために8つのオクテット（2ワード）のブロックを使用します。 4オクテット（1ワード）のブロックは、ハッシュタイプ、暗号種別、鍵合意の種類、および認証タグのタイプをエンコードするために使用されます。ブロック内の値は、それらの所望の長さにするためにスペース（0x20の）で拡張されたASCII文字列です。現在定義されているブロックの値は、表1-6に記載されています。
Additional block values may be defined and used.
追加のブロックの値を定義して使用することができます。
ZRTP uses this ASCII encoding to simplify debugging and make it "Wireshark (Ethereal) friendly".
ZRTPは、デバッグを容易にし、それが「Wiresharkの（Etherealの）優しい」にするには、このASCIIエンコーディングを使用しています。
Currently, 16 Message Type Blocks are defined -- they represent the set of ZRTP message primitives. ZRTP endpoints MUST support the Hello, HelloACK, Commit, DHPart1, DHPart2, Confirm1, Confirm2, Conf2ACK, SASrelay, RelayACK, Error, ErrorACK, and PingACK message types. ZRTP endpoints MAY support the GoClear, ClearACK, and Ping messages. In order to generate a PingACK message, it is necessary to parse a Ping message. Additional messages may be defined in extensions to ZRTP.
現在、16個のメッセージタイプのブロックが定義されている - 彼らはZRTPメッセージプリミティブの集合を表します。 ZRTPエンドポイントはこんにちは、HelloACK、コミット、DHPart1、DHPart2、CONFIRM1、Confirm2、Conf2ACK、SASrelay、RelayACK、エラー、ErrorACK、およびPingACKメッセージの種類をサポートしなければなりません。 ZRTPエンドポイントはGoClear、ClearACK、とPingメッセージをサポートするかもしれません。 PingACKメッセージを生成するためには、pingメッセージを解析する必要があります。追加のメッセージがZRTPの拡張で定義されていてもよいです。
Message Type Block | Meaning
---------------------------------------------------
"Hello " | Hello Message
---------------------------------------------------
"HelloACK" | HelloACK Message
---------------------------------------------------
"Commit " | Commit Message
---------------------------------------------------
"DHPart1 " | DHPart1 Message
---------------------------------------------------
"DHPart2 " | DHPart2 Message
---------------------------------------------------
"Confirm1" | Confirm1 Message
---------------------------------------------------
"Confirm2" | Confirm2 Message
---------------------------------------------------
"Conf2ACK" | Conf2ACK Message
---------------------------------------------------
"Error " | Error Message
---------------------------------------------------
"ErrorACK" | ErrorACK Message
---------------------------------------------------
"GoClear " | GoClear Message
---------------------------------------------------
"ClearACK" | ClearACK Message
---------------------------------------------------
"SASrelay" | SASrelay Message
---------------------------------------------------
"RelayACK" | RelayACK Message
---------------------------------------------------
"Ping " | Ping Message
---------------------------------------------------
"PingACK " | PingACK Message
---------------------------------------------------
Table 1. Message Type Block Values
表1.メッセージタイプのブロック値
The hash algorithm and its related MAC algorithm are negotiated via the Hash Type Block found in the Hello message (Section 5.2) and the Commit message (Section 5.4).
ハッシュアルゴリズム及びそれに関連するMACアルゴリズムは、ハッシュタイプブロックを介して交渉されるHelloメッセージ（セクション5.2）とコミットメッセージ（5.4節）中に見出さ。
All ZRTP endpoints MUST support a Hash Type of SHA-256 [FIPS-180-3]. SHA-384 SHOULD be supported and MUST be supported if ECDH-384 is used. Additional Hash Types MAY be used, such as the NIST SHA-3 hash [SHA-3] when it becomes available. Note that the Hash Type refers to
すべてのZRTPエンドポイントは、SHA-256のハッシュの種類をサポートしなければならない[FIPS-180-3]。 SHA-384がサポートされるべきであり、ECDH-384が使用される場合にサポートしなければなりません。追加のハッシュタイプは、NIST SHA-3ハッシュ[SHA-3]、それが利用可能になるように使用することができます。ハッシュタイプを示すことに注意してください
the hash algorithm that will be used throughout the ZRTP key exchange, not the hash algorithm to be used in the SRTP Authentication Tag.
ZRTP鍵交換、ないSRTP認証タグで使用するハッシュアルゴリズム全体で使用されるハッシュアルゴリズム。
The choice of the negotiated Hash Type is coupled to the Key Agreement Type, as explained in Section 5.1.5.
第5.1.5項で説明したように交渉ハッシュタイプの選択は、主契約の種類に接続されています。
Hash Type Block | Meaning
----------------------------------------------------------
"S256" | SHA-256 Hash defined in FIPS 180-3
----------------------------------------------------------
"S384" | SHA-384 Hash defined in FIPS 180-3
----------------------------------------------------------
"N256" | NIST SHA-3 256-bit hash (when published)
----------------------------------------------------------
"N384" | NIST SHA-3 384-bit hash (when published)
----------------------------------------------------------
Table 2. Hash Type Block Values
表2.ハッシュタイプブロック値
At the time of this writing, the NIST SHA-3 hashes [SHA-3] are not yet available. NIST is expected to publish SHA-3 in 2012, as a successor to the SHA-2 hashes in [FIPS-180-3].
この記事の執筆時点では、NIST SHA-3のハッシュ[SHA-3]はまだ利用できません。 NISTは、[FIPS-180-3]でSHA-2ハッシュの後継として、2012年にSHA-3を公開することが期待されます。
ZRTP makes use of message authentication codes (MACs) that are keyed hashes based on the negotiated Hash Type. For the SHA-2 and SHA-3 hashes, the negotiated MAC is the HMAC based on the negotiated hash. This MAC function is also used in the ZRTP key derivation function (Section 4.5.1).
ZRTPネゴシエートハッシュタイプに基づいてハッシュをキー止めされているメッセージ認証コード（MAC）を利用します。 SHA-2、SHA-3ハッシュのために、ネゴシエートMACがネゴシエートハッシュに基づくHMACです。このMAC機能もZRTP鍵導出関数（セクション4.5.1）に使用されます。
The HMAC function is defined in [FIPS-198-1]. A discussion of the general security of the HMAC construction may be found in [RFC2104]. Test vectors for HMAC-SHA-256 and HMAC-SHA-384 may be found in [RFC4231].
HMAC関数は、[FIPS-198から1]で定義されています。 HMAC構造の一般的なセキュリティの議論は[RFC2104]に見出すことができます。 HMAC-SHA-256およびHMAC-SHA-384のためのテストベクトルは、[RFC4231]に見出すことができます。
The negotiated Hash Type does not apply to the hash used in the digital signature defined in Section 7.2. For example, even if the negotiated Hash Type is SHA-256, the digital signature may use SHA-384 if an Elliptic Curve Digital Signature Algorithm (ECDSA) P-384 signature key is used. Digital signatures are optional in ZRTP.
ネゴシエートされたハッシュタイプは、セクション7.2で定義されたデジタル署名に使用されるハッシュには適用されません。楕円曲線デジタル署名アルゴリズム（ECDSA）P-384の署名鍵が使用される場合、例えば、ネゴシエートハッシュタイプは、SHA-256であっても、デジタル署名は、SHA-384を使用してもよいです。デジタル署名はZRTPにオプションです。
Except for the aforementioned digital signatures, and the special cases noted in Section 5.1.2.2, all the other hashes and MACs used throughout the ZRTP protocol will use the negotiated Hash Type.
前述のデジタル署名、およびセクション5.1.2.2で述べた特別な場合を除き、他の全てのハッシュとMACはネゴシエートハッシュタイプを使用するZRTPプロトコルを通して使用されます。
A future hash may include its own built-in MAC, not based on the HMAC construct, for example, the Skein hash function [Skein]. If NIST chooses such a hash as the SHA-3 winner, Hash Types "N256", and "N384" will still use the related HMAC as the negotiated MAC. If an implementer wishes to use Skein and its built-in MAC as the negotiated MAC, new Hash Types must be used.
将来ハッシュはHMAC構築物、例えば、かせのハッシュ関数[かせ]に基づいていない、内蔵MACそれ自身を含んでもよいです。 NISTは、SHA-3の勝者、ハッシュタイプ「N256」などのハッシュ、および「N384」を選択した場合、まだ交渉さMACなどの関連HMACを使用します。実装はかせを使用したいと内蔵のMAC交渉さMACとした場合、新しいハッシュの種類を使用する必要があります。
While most of the hash and MAC usage in ZRTP is defined by the negotiated Hash Type (Section 5.1.2), some hashes and MACs must be precomputed prior to negotiations, and thus cannot have their algorithms negotiated during the ZRTP exchange. They are implicitly predetermined to use SHA-256 [FIPS-180-3] and HMAC-SHA-256.
ZRTP内のハッシュとMACの使用量のほとんどが交渉ハッシュタイプ（5.1.2項）で定義されている間、いくつかのハッシュとMACは、前の交渉に事前に計算されなければならないので、そのアルゴリズムはZRTP交換の際に交渉したことはできません。これらは暗黙SHA-256 [FIPS-180-3]およびHMAC-SHA-256を使用するように予め定められています。
These are the hashes and MACs that MUST use the Implicit hash and MAC algorithm:
これらは、暗黙のハッシュとMACアルゴリズムを使用しなければならないハッシュおよびMACは、次のとおりです。
The hash chain H0-H3 defined in Section 9.
セクション9で定義されたハッシュチェインH0-H3。
The MACs that are keyed by this hash chain, as defined in Section 8.1.1.
セクション8.1.1で定義されるように、このハッシュチェーンによってキーイングされたMAC。
The Hello Hash in the a=zrtp-hash attribute defined in Section 8.1.
8.1節で定義されたA = ZRTPハッシュ属性でこんにちはハッシュ。
ZRTP defines a method for negotiating different ZRTP protocol versions (Section 4.1.1). SHA-256 is the Implicit Hash and HMAC-SHA-256 is the Implicit MAC for ZRTP protocol version 1.10. Future ZRTP protocol versions may, if appropriate, use another hash algorithm as the Implicit Hash, such as the NIST SHA-3 hash [SHA-3], when it becomes available. For example, a future SIP packet may list two a=zrtp-hash SDP attributes, one based on SHA-256 for ZRTP version 1.10, and another based on SHA-3 for ZRTP version 2.00.
ZRTPは異なるZRTPプロトコルバージョン（4.1.1）を交渉するための方法を定義します。 SHA-256は、暗黙的ハッシュであり、HMAC-SHA-256はZRTPプロトコルバージョン1.10のために暗黙MACです。将来ZRTPプロトコルバージョンは、適切な場合、それが利用可能になったとき、そのようなNIST SHA-3ハッシュ[SHA-3]のように、暗黙のハッシュとして他のハッシュアルゴリズムを使用してもよいです。例えば、将来のSIPパケットは、2つのA = ZRTPハッシュSDPは、ZRTPバージョン1.10のためにSHA-256に基づくもの、及びZRTPバージョン2.00のためのSHA-3に基づいて、別の属性一覧表示することができます。
The block cipher algorithm is negotiated via the Cipher Type Block found in the Hello message (Section 5.2) and the Commit message (Section 5.4).
ブロック暗号アルゴリズムは、Helloメッセージ（セクション5.2）とコミットメッセージ（5.4節）に見出される暗号種別ブロックを介して交渉されます。
All ZRTP endpoints MUST support AES-128 (AES1) and MAY support AES-192 (AES2), AES-256 (AES3), or other Cipher Types. The Advanced Encryption Standard is defined in [FIPS-197].
すべてのZRTPエンドポイントは、AES-128（AES1）をサポートしなければならないとAES-192（AES2）、AES-256（AES3）、または他の暗号の種類をサポートするかもしれません。高度暗号化標準は、[FIPS-197]で定義されています。
The use of AES-128 in SRTP is defined by [RFC3711]. The use of AES-192 and AES-256 in SRTP is defined by [RFC6188]. The choice of the AES key length is coupled to the Key Agreement Type, as explained in Section 5.1.5.
SRTPにおけるAES-128の使用は、[RFC3711]で定義されます。 SRTPにおけるAES-192およびAES-256の使用は、[RFC6188]で定義されます。第5.1.5項で説明したようにAESキーの長さの選択は、主契約の種類に接続されています。
Other block ciphers may be supported that have the same block size and key sizes as AES. If implemented, they may be used anywhere in ZRTP or SRTP in place of the AES, in the same modes of operation and key size. Notably, in counter mode to replace AES-CM in [RFC3711] and [RFC6188], as well as in CFB mode to encrypt a portion of the Confirm message (Figure 10) and SASrelay message (Figure 16). ZRTP endpoints MAY support the TwoFish [TwoFish] block cipher.
他のブロック暗号は、同じブロックサイズやAESなどのキーのサイズを有するように支持することができます。実装されている場合、彼らは、操作とキーサイズの同じモードで、AESの代わりにZRTPまたはSRTPのどこでも使用することができます。なお、カウンタモード（図16）確認メッセージの部分（図10）とSASrelayメッセージを暗号化するために[RFC3711]及び[RFC6188]に、ならびにCFBモードでAES-CMを交換します。 ZRTPエンドポイントはいるTwoFish [いるTwoFish]ブロック暗号をサポートするかもしれません。
Cipher Type Block | Meaning
-------------------------------------------------
"AES1" | AES with 128-bit keys
-------------------------------------------------
"AES2" | AES with 192-bit keys
-------------------------------------------------
"AES3" | AES with 256-bit keys
-------------------------------------------------
"2FS1" | TwoFish with 128-bit keys
-------------------------------------------------
"2FS2" | TwoFish with 192-bit keys
-------------------------------------------------
"2FS3" | TwoFish with 256-bit keys
-------------------------------------------------
Table 3. Cipher Type Block Values
表3暗号タイプブロック値
All ZRTP endpoints MUST support HMAC-SHA1 authentication tags for SRTP, with both 32-bit and 80-bit length tags as defined in [RFC3711].
[RFC3711]で定義されるように全てZRTPエンドポイントは、32ビットと80ビット長のタグと、SRTPのためにHMAC-SHA1認証タグをサポートしなければなりません。
ZRTP endpoints MAY support 32-bit and 64-bit SRTP authentication tags based on the Skein hash function [Skein]. The Skein-512-MAC key length is fixed at 256 bits for this application, and the output length is adjustable. The Skein MAC is defined in Sections 2.6 and 4.3 of [Skein] and is not based on the HMAC construct. Reference implementations for Skein may be found at [Skein1]. A Skein-based MAC is significantly more efficient than HMAC-SHA1, especially for short SRTP payloads.
ZRTPエンドポイントはかせハッシュ関数[かせ]に基づいて、32ビットと64ビットのSRTP認証タグをサポートするかもしれません。かせ-512-MACキーの長さは、このアプリケーションのために256ビットに固定され、出力長さが調整可能です。かせMACは、セクション2.6および[かせ] 4.3で定義され、HMAC構築物に基づくものではありません。かせのためのリファレンス実装は、[Skein1]で見つけることができます。かせベースのMACは、特に短いSRTPペイロードのために、HMAC-SHA1よりも著しく効率的です。
The Skein MAC key is computed by the SRTP key derivation function, which is also referred to as the AES-CM PRF, or pseudorandom function. This is defined either in [RFC3711] or in [RFC6188],
かせMACキーはまた、AES-CM PRF、又は擬似ランダム関数と呼ばれてSRTP鍵導出関数によって計算されます。これは、[RFC3711]または[RFC6188]のいずれかに定義されています
depending on the selected SRTP AES key length. To compute a Skein MAC key, the SRTP PRF output for the authentication key is left untruncated at 256 bits, instead of the usual truncated length of 160 bits (the key length used by HMAC-SHA1).
選択されたSRTP AESキーの長さに応じました。かせMAC鍵を計算するために、認証キーのSRTP PRF出力代わりに160ビット（HMAC-SHA1で使用されるキーの長さ）の通常の切り捨て長さの256ビットに切り捨てられていないままです。
Auth Tag Type Block | Meaning
----------------------------------------------------------
"HS32" | 32-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"HS80" | 80-bit authentication tag based on
| HMAC-SHA1 as defined in RFC 3711.
----------------------------------------------------------
"SK32" | 32-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 32-bit MAC length.
----------------------------------------------------------
"SK64" | 64-bit authentication tag based on
| Skein-512-MAC as defined in [Skein],
| with 256-bit key, 64-bit MAC length.
----------------------------------------------------------
Table 4. Auth Tag Type Values
表4.認証タグタイプ値
Implementers should be aware that AES-GCM and AES-CCM for SRTP are expected to become available when [SRTP-AES-GCM] is published as an RFC. If an implementer wishes to use these modes when they become available, new Auth Tag Types must be added.
実装者は、SRTPのためのAES-GCMとAES-CCMは、[SRTP-AES-GCM]はRFCとして公開されたときに利用可能になると期待されていることに注意する必要があります。実装者は、彼らが利用可能になったときにこれらのモードを使用したい場合は、新しい認証タグタイプを追加する必要があります。
All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and MAY support EC25, EC38, and DH2k.
すべてのZRTPエンドポイントは、DH3kをサポートしなければならない事前共有をサポートする必要があり、EC25、EC38、およびDH2kをサポートするかもしれません。
If a ZRTP endpoint supports multiple concurrent media streams, such as audio and video, it MUST support Multistream (Section 4.4.3) mode. Also, if a ZRTP endpoint supports the GoClear message (Section 4.7.2), it SHOULD support Multistream, to be used if the two parties choose to return to the secure state after going Clear (as explained in Section 4.7.2.1).
ZRTPエンドポイントは、オーディオやビデオなどの複数の同時メディアストリームを、サポートしている場合、それは、マルチストリーム（4.4.3）モードをサポートしなければなりません。 ZRTPエンドポイントがGoClearメッセージ（セクション4.7.2）をサポートしている場合、両者は（セクション4.7.2.1で説明したように）クリアを予定した後、安全な状態に戻すことを選択した場合にも、それが使用されるように、マルチストリームをサポートする必要があります。
For Finite Field Diffie-Hellman, ZRTP endpoints MUST use the DH parameters defined in [RFC3526], as follows. DH3k uses the 3072-bit modular exponentiation group (MODP). DH2k uses the 2048-bit MODP group. The DH generator g is 2. The random Diffie-Hellman secret exponent SHOULD be twice as long as the AES key length. If AES-128 is used, the DH secret value SHOULD be 256 bits long. If AES-256 is used, the secret value SHOULD be 512 bits long.
次のように有限フィールドディフィー - ヘルマンため、ZRTPエンドポイントは、[RFC3526]で定義されたDHパラメータを使用しなければなりません。 DH3kは3072ビットべき乗剰余群（MODP）を使用します。 DH2kは、2048ビットのMODPグループを使用しています。 DHジェネレータgが2であるランダムのDiffie-Hellmanの秘密指数は倍の長AESキーの長さなどであるべきです。 AES-128が使用される場合、DH秘密値は、256ビット長であるべきです。 AES-256が使用される場合、秘密の値は512ビット長であるべきです。
If Elliptic Curve DH is used, the ECDH algorithm and key generation is from [NIST-SP800-56A]. The curves used are from [NSA-Suite-B], which uses the same curves as ECDSA defined by [FIPS-186-3], and can also be found in RFC 5114, Sections 2.6 through 2.8 [RFC5114]. ECDH test vectors may be found in RFC 5114, appendices A.6 through A.8 [RFC5114]. The validation procedures are from [NIST-SP800-56A], Section 5.6.2.6, method 3, Elliptic Curve Cryptography (ECC) Partial Validation. Both the X and Y coordinates of the point on the curve are sent, in the first and second half of the ECDH public value, respectively. The ECDH result returns only the X coordinate, as specified in SP 800-56A. Useful strategies for implementing ECC may be found in [RFC6090].
楕円曲線DHが使用される場合、ECDHアルゴリズムと鍵の生成は[NIST-SP800-56A]からのものです。使用される曲線は、[RFC5114]、[FIPS-186-3]によって定義ECDSAと同じ曲線を使用し、また、RFC 5114に見出すことができ、[NSAスイート-B]から2.8スルーセクション2.6です。 ECDHテストベクトルは、RFC 5114に見出すことができる、A.8 [RFC5114]を通してA.6を付録。検証手順は、[NIST-SP800-56A]、セクション5.6.2.6、方法3、楕円曲線暗号（ECC）部分検証からのものです。曲線上の点の両方のX及びY座標は、それぞれ、ECDH公開値の第一及び第二の半分に、送信されます。 SP 800-56Aで指定されECDH結果は、唯一のX座標を戻します。 ECCを実装するための有用な戦略は、[RFC6090]で見つけられるかもしれません。
The choice of the negotiated hash algorithm (Section 5.1.2) is coupled to the choice of Key Agreement Type. If ECDH-384 (EC38) is chosen as the key agreement, the negotiated hash algorithm MUST be either SHA-384 or the corresponding SHA-3 successor.
交渉されたハッシュアルゴリズム（セクション5.1.2）の選択は、主契約の種類の選択に接続されています。 ECDH-384（EC38）は、鍵合意として選択される場合、ネゴシエートハッシュアルゴリズムはSHA-384または対応するSHA-3後継者でなければなりません。
The choice of AES key length is coupled to the choice of Key Agreement Type. If EC38 is chosen as the key agreement, AES-256 (AES3) SHOULD be used but AES-192 MAY be used. If DH3k or EC25 is chosen, any AES key size MAY be used. Note that SRTP as defined in [RFC3711] only supports AES-128.
AESキーの長さの選択は、主契約の種類の選択に接続されています。 EC38は、鍵の合意として選択されている場合は、AES-256（AES3）が使用されるべきであるが、AES-192を使用することができます。 DH3kまたはEC25を選択した場合、任意のAES鍵のサイズを使用することができます。 [RFC3711]で定義されるようにそのSRTPを注意のみAES-128をサポートします。
DH2k is intended to provide acceptable security for low power applications, or for applications that require faster key negotiations. NIST asserts in Table 4 of [NIST-SP800-131A] that DH-2048 is safe to use through 2013. The security of DH2k can be augmented by implementing ZRTP's key continuity features (Section 15.1). DH2k SHOULD use AES-128. If an implementor must use slow hardware, DH2k should precede DH3k in the Hello message.
DH2kは、低消費電力アプリケーションのための、またはより高速なキー交渉を必要とするアプリケーションのための許容可能なセキュリティを提供することを意図しています。 NISTは、DH-2048 DH2kのセキュリティがZRTPのキー連続機能（セクション15.1）を実装することによって増強することができる2013を介して使用しても安全であること[NIST-SP800-131A]の表4にアサートします。 DH2kは、AES-128を使用すべきです。実装が遅いハードウェアを使用する必要がある場合、DH2kは、HelloメッセージにDH3kを前に置く必要があります。
ECDH-521 SHOULD NOT be used, due to disruptive computational delays. These delays may lead to exhaustion of the retransmission schedule, unless both endpoints have very fast hardware. Note that ECDH-521 is not part of NSA Suite B.
ECDH-521は、破壊的な計算の遅れが原因で使用されるべきではありません。両方のエンドポイントが非常に高速なハードウェアを持っていない限り、これらの遅延は、再送スケジュールの枯渇につながる可能性があります。 ECDH-521は、NSAスイートBの一部ではないことに注意してください
ZRTP also defines two non-DH modes, Multistream and Preshared, in which the SRTP key is derived from a shared secret and some nonce material.
ZRTPはまた、SRTP鍵は、共有秘密と、いくつかのノンス材料から誘導された二つの非DHモード、マルチストリーム及び事前共有を規定します。
The table below lists the pv length in words and DHPart1 and DHPart2 message length in words for each Key Agreement Type Block.
以下の表は、各キー契約タイプブロックのための言葉で言葉やDHPart1とDHPart2メッセージ長のPVの長さを示しています。
Key Agreement | pv | message | Meaning
Type Block | words | words |
-----------------------------------------------------------
"DH3k" | 96 | 117 | DH mode with p=3072 bit prime
| | | per RFC 3526, Section 4.
-----------------------------------------------------------
"DH2k" | 64 | 85 | DH mode with p=2048 bit prime
| | | per RFC 3526, Section 3.
-----------------------------------------------------------
"EC25" | 16 | 37 | Elliptic Curve DH, P-256
| | | per RFC 5114, Section 2.6
-----------------------------------------------------------
"EC38" | 24 | 45 | Elliptic Curve DH, P-384
| | | per RFC 5114, Section 2.7
-----------------------------------------------------------
"EC52" | 33 | 54 | Elliptic Curve DH, P-521
| | | per RFC 5114, Section 2.8
| | | (deprecated - do not use)
-----------------------------------------------------------
"Prsh" | - | - | Preshared Non-DH mode
-----------------------------------------------------------
"Mult" | - | - | Multistream Non-DH mode
-----------------------------------------------------------
Table 5. Key Agreement Type Block Values
表5.主要な契約タイプブロック値
The SAS Type determines how the SAS is rendered to the user so that the user may verbally compare it with his partner over the voice channel. This allows detection of a MiTM attack.
SASタイプは、ユーザーが口頭で音声チャネルを介して彼のパートナーとそれを比較することができるように、SASがユーザーにレンダリングされる方法を決定します。これは、MITM攻撃の検出を可能にします。
All ZRTP endpoints MUST support the base32 and MAY support the base256 rendering schemes for the Short Authentication String, and other SAS rendering schemes. See Section 4.5.2 for how the sasvalue is computed and Section 7 for how the SAS is used.
すべてのZRTPエンドポイントは、base32をサポートしなければならないし、ショート認証文字列、およびその他のSASレンダリングスキームのスキームをレンダリングbase256をサポートするかもしれません。 sasvalueはSASを使用する方法については計算され、第7節する方法については、セクション4.5.2を参照してください。
SAS Type Block | Meaning
---------------------------------------------------
"B32 " | Short Authentication String using
| base32 encoding
---------------------------------------------------
"B256" | Short Authentication String using
| base256 encoding (PGP Word List)
---------------------------------------------------
Table 6. SAS Type Block Values
表6. SASタイプブロック値
For the SAS Type of "B256", the most-significant (leftmost) 16 bits of the 32-bit sasvalue are rendered in network byte order using the PGP Word List [pgpwordlist] [Juola1][Juola2].
「B256」のSASタイプのために、32ビットsasvalueの（左端の）最上位16ビットは、PGP単語リスト[pgpwordlist] [Juola1] [Juola2]を使用して、ネットワークバイト順にレンダリングされます。
For the SAS Type of "B32 ", the most-significant (leftmost) 20 bits of the 32-bit sasvalue are rendered as a form of base32 encoding. The leftmost 20 bits of the sasvalue results in four base32 characters that are rendered, most-significant quintet first, to both ZRTP endpoints. Here is a normative pseudocode implementation of the base32 function:
「B32」、最上位（左端）のSASタイプの32ビットsasvalueの20ビットは、base32エンコードの形態としてレンダリングされます。両方ZRTPエンドポイントにレンダリングされた4つのbase32文字でsasvalue結果の左端の20ビット、最上位クインテットまず、。ここでbase32機能の規範的な擬似コードの実装は次のとおりです。
char[4] base32(uint32 bits)
{ int i, n, shift;
char result[4];
for (i=0,shift=27; i!=4; ++i,shift-=5)
{ n = (bits>>shift) & 31;
result[i] = "ybndrfg8ejkmcpqxot1uwisza345h769"[n];
}
return result;
}
This base32 encoding scheme differs from RFC 4648, and was designed (by Bryce Wilcox-O'Hearn) to represent bit sequences in a form that is convenient for human users to manipulate with minimal ambiguity. The unusually permuted character ordering was designed for other applications that use bit sequences that do not end on quintet boundaries.
このbase32符号化方式は、RFC 4648とは異なり、人間のユーザが最小の曖昧で操作するための便利な形式でビット列を表すために（ブライス・ウィルコックス - O'Hearnによって）設計されました。異常に置換さ文字の順序はクインテット境界で終了しないビットシーケンスを使用する他のアプリケーション用に設計されました。
The Signature Type Block specifies what signature algorithm is used to sign the SAS as discussed in Section 7.2. The 4-octet Signature Type Block, along with the accompanying signature block, are OPTIONAL and may be present in the Confirm message (Figure 10) or the SASrelay message (Figure 16). The signature types are given in the table below.
署名タイプブロックは署名アルゴリズムは、セクション7.2で説明したようにSASを署名するために使用されるかを指定します。 4オクテット署名タイプブロックは、添付の署名ブロックとともに、オプションで、確認メッセージ（図10）またはSASrelayメッセージ（図16）中に存在してもよいです。署名タイプは、以下の表に示されています。
Signature | Meaning
Type Block |
------------------------------------------------
"PGP " | OpenPGP Signature, per RFC 4880
|
------------------------------------------------
"X509" | ECDSA, with X.509v3 cert
| per RFC 5759 and FIPS-186-3
------------------------------------------------
Table 7. Signature Type Block Values
表7.シグニチャタイプのブロック値
Additional details on the signature and signing key format may be found in Section 7.2. OpenPGP signatures (Signature Type "PGP ") are discussed in Section 7.2.1. The ECDSA curves are over prime fields only, drawn from Appendix D.1.2 of [FIPS-186-3]. X.509v3 ECDSA Signatures (Signature Type "X509") are discussed in Section 7.2.2.
署名と署名キーのフォーマットに関する詳細は、7.2節に見ることができます。 OpenPGPのシグネチャ（署名タイプ「PGP」）は、セクション7.2.1に記載されています。 ECDSA曲線は[FIPS-186-3]の付録D.1.2から引き出され、唯一の素数フィールド上にあります。 X.509v3 ECDSA署名（シグニチャタイプ「X509」）は、セクション7.2.2に記載されています。
The Hello message has the format shown in Figure 3.
Helloメッセージは、図3に示すフォーマットを有しています。
All ZRTP messages begin with the preamble value 0x505a, then a 16-bit length in 32-bit words. This length includes only the ZRTP message (including the preamble and the length) but not the ZRTP packet header or CRC. The 8-octet Message Type follows the length field.
全てZRTPメッセージは、32ビットワードにおいて16ビット長次に、プリアンブル値0x505aで始まります。この長さは、（プリアンブル及び長さを含む）ZRTPメッセージではなくZRTPパケットヘッダやCRCのみを含みます。 8オクテットのメッセージタイプは、長さフィールドの後に続きます。
Next, there is a 4-character string containing the version (ver) of the ZRTP protocol, which is "1.10" for this specification. Next, there is the Client Identifier string (cid), which is 4 words long and identifies the vendor and release of the ZRTP software. The 256- bit hash image H3 is defined in Section 9. The next parameter is the ZID, the 96-bit-long unique identifier for the ZRTP endpoint, defined in Section 4.9.
次に、本明細書のために、「1.10」であるZRTPプロトコルのバージョン（版）を含有する4文字の文字列があります。次に、4つのワードの長さであり、ZRTPソフトウェアのベンダーとリリースを識別するクライアント識別子列（CID）、があります。 256ビットのハッシュ画像H3はセクション9で定義されている次のパラメータは、セクション4.9で定義され、ZID、ZRTPエンドポイントの96ビット長の一意な識別子です。
The next four bits include three flag bits:
次の4ビットは、三個のフラグビットを含みます。
o The Signature-capable flag (S) indicates this Hello message is sent from a ZRTP endpoint which is able to parse and verify digital signatures, as described in Section 7.2. If signatures are not supported, the (S) flag MUST be set to zero.
O署名対応フラグ（S）は、このHelloメッセージは、セクション7.2で説明したように、解析し、デジタル署名を検証することができるZRTPエンドポイントから送信されていることを示します。署名がサポートされていない場合、（S）フラグがゼロに設定されなければなりません。
o The MiTM flag (M) is a Boolean that is set to true if and only if this Hello message is sent from a device, usually a PBX, that has the capability to send an SASrelay message (Section 5.13).
MITMフラグ（M）O場合はtrueに設定され、このHelloメッセージをSASrelayメッセージ（セクション5.13）を送信する機能を有する装置、通常PBXから送信されている場合にのみブール値です。
o The Passive flag (P) is a Boolean normally set to false, and is set to true if and only if this Hello message is sent from a device that is configured to never send a Commit message (Section 5.4). This would mean it cannot initiate secure sessions, but may act as a responder.
パッシブフラグ（P）Oブールは、通常はfalseに設定されており、このHelloメッセージがコミットメッセージ（5.4節）を送信しないように設定されているデバイスから送信された場合にのみ、trueに設定されています。これは、安全なセッションを開始することはできませんが、応答者として作用する可能性を意味します。
The next 8 bits are unused and SHOULD be set to zero when sent and MUST be ignored on receipt.
次の8ビットは未使用であり、送信されて、領収書の上で無視しなければならない場合、ゼロに設定されるべきです。
Next is a list of supported Hash algorithms, Cipher algorithms, SRTP Auth Tag Types, Key Agreement Types, and SAS Types. The number of listed algorithms are listed for each type: hc=hash count, cc=cipher count, ac=auth tag count, kc=key agreement count, and sc=sas count. The values for these algorithms are defined in Tables 2, 3, 4, 5, and
次のサポートハッシュアルゴリズム、暗号アルゴリズム、SRTP認証タグタイプ、鍵合意の種類、およびSASの種類のリストがあります。 HC =ハッシュカウント、CC =暗号カウント、AC =認証タグカウント、KC =鍵合意数、およびSC = SASカウント：列挙されたアルゴリズムの数を種類ごとに記載されています。これらのアルゴリズムの値は、表2、3、4、5で定義され、そして
6. A count of zero means that only the mandatory-to-implement algorithms are supported. Mandatory algorithms MAY be included in the list. The order of the list indicates the preferences of the endpoint. If a mandatory algorithm is not included in the list, it is implicitly added to the end of the list for preference.
6.ゼロのカウントは、強制的に実装アルゴリズムがサポートされていることを意味します。必須のアルゴリズムは、リストに含まれるかもしれません。リストの順序は、エンドポイントの好みを示しています。必須アルゴリズムは、リストに含まれていない場合は、暗黙的に好みのリストの最後に追加されます。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H2 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H2 value is known to the receiving party later in the protocol.
メッセージの最後の64ビットMACはセクション5.1.2.2で定義されたMACアルゴリズムを使用して、MACを含まないメッセージ全体にわたって計算されます。 MACキーは、送信者のH2（第9条で定義されている）で、送信者のH2の値は、後のプロトコルで受信者に知られるまで、このようにMACは、受信側で確認することができません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Hello " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client Identifier (4 words) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H3 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|S|M|P| unused (zeros)| hc | cc | ac | kc | sc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithms (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Types (0 to 7 values) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Hello Message Format
図3：こんにちは、メッセージフォーマット
The HelloACK message is used to stop retransmissions of a Hello message. A HelloACK is sent regardless if the version number in the Hello is supported or the algorithm list supported. The receipt of a HelloACK stops retransmission of the Hello message. The format is shown in the figure below. A Commit message may be sent in place of a HelloACK by an Initiator, if a Commit message is ready to be sent promptly.
HelloACKメッセージは、Helloメッセージの再送信を停止するために使用されます。 HelloACKは、こんにちはでバージョン番号がサポートされている場合にかかわらず、送信またはアルゴリズムのリストがサポートされています。 HelloACKの領収書は、Helloメッセージの再送信を停止します。フォーマットは以下の図に示されています。 Aメッセージをコミットコミットメッセージを速やかに送ること準備ができている場合、イニシエータによってHelloACKの代わりに送信されることがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="HelloACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HelloACK Message Format
図4：HelloACKメッセージフォーマット
The Commit message is sent to initiate the key agreement process after both sides have received a Hello message, which means it can only be sent after receiving both a Hello message and a HelloACK message. There are three subtypes of Commit messages, whose formats are shown in Figures 5, 6, and 7.
双方がそれだけでHelloメッセージとHelloACKメッセージの両方を受信した後に送信することができる手段Helloメッセージを受信した後にコミットメッセージは、キー合意プロセスを開始するために送信されます。フォーマット図5、図6、図7に示されているコミットメッセージ、の3つのサブタイプが存在します。
The Commit message contains the Message Type Block, then the 256-bit hash image H2, which is defined in Section 9. The next parameter is the initiator's ZID, the 96-bit-long unique identifier for the ZRTP endpoint, which MUST have the same value as was used in the Hello message.
コミットメッセージは、次のパラメータは、イニシエータのZID、ZRTPエンドポイントの96ビット長の固有の識別子、持っている必要があり、セクション9で定義されたメッセージタイプブロックは、256ビットのハッシュ画像H2を含有しますHelloメッセージに使用されたのと同じ値。
Next, there is a list of algorithms selected by the initiator (hash, cipher, auth tag type, key agreement, sas type). For a DH Commit, the hash value hvi is a hash of the DHPart2 of the Initiator and the Responder's Hello message, as explained in Section 4.4.1.1.
次に、開始剤（ハッシュ、暗号、認証タグタイプ、キー合意、SASタイプ）によって選択されたアルゴリズムのリストがあります。 4.4.1.1項で説明したようにDHコミットするために、ハッシュ値HVIは、イニシエータとレスポンダのHelloメッセージのDHPart2のハッシュです。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H1 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H1 value is known to the receiving party later in the protocol.
メッセージの最後の64ビットMACはセクション5.1.2.2で定義されたMACアルゴリズムを使用して、MACを含まないメッセージ全体にわたって計算されます。 MACキーは、送信者のH1（第9条で定義されている）で、送信者のH1値が後でプロトコルで受信者に知られるまで、このようにMACは、受信側で確認することができません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=29 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| hvi (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DH Commit Message Format
図5：DHメッセージフォーマットをコミット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=25 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Mult" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Multistream Commit Message Format
図6：マルチストリームは、メッセージフォーマットをコミット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=27 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Commit " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H2 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ZID (3 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cipher algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auth tag type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Agreement Type = "Prsh" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| nonce (4 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyID (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Preshared Commit Message Format
図7：事前共有は、メッセージフォーマットをコミット
The DHPart1 message shown in Figure 8 begins the DH exchange. It is sent by the Responder if a valid Commit message is received from the Initiator. The length of the pvr value and the length of the DHPart1 message depends on the Key Agreement Type chosen. This information is contained in the table in Section 5.1.5. Note that for both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent.
図8に示さDHPart1メッセージは、DH交換を開始します。コミット有効なメッセージは、イニシエータから受信された場合には、レスポンダによって送信されます。 PVR値とDHPart1メッセージの長さの長さは、選択された鍵合意のタイプに依存します。この情報は、5.1.5項の表に含まれています。マルチストリーム及び事前共有モードの両方のために、何DHPart1又はDHPart2メッセージが送信されないであろうことに留意されたいです。
The 256-bit hash image H1 is defined in Section 9.
256ビットのハッシュ画像H1はセクション9で定義されています。
The next four parameters are non-invertible hashes (computed in Section 4.3.1) of potential shared secrets used in generating the ZRTP secret s0. The first two, rs1IDr and rs2IDr, are the hashes of the responder's two retained shared secrets, truncated to 64 bits. Next, there is auxsecretIDr, a hash of the responder's auxsecret (defined in Section 4.3), truncated to 64 bits. The last parameter is a hash of the trusted MiTM PBX shared secret pbxsecret, defined in Section 7.3.1.
次の4つのパラメータはZRTP秘密S0を生成する際に使用される可能性のある共有秘密の（セクション4.3.1で計算）は、非可逆ハッシュです。最初の二つ、rs1IDrとrs2IDrは、64ビットに切り捨てレスポンダの2つの保持共有秘密キーのハッシュです。次に、auxsecretIDr、64ビットに切り捨てられる（セクション4.3で定義された）レスポンダのauxsecretのハッシュがあります。最後のパラメータは、7.3.1項で定義された秘密pbxsecretを、共有し、信頼MITM PBXのハッシュです。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H0 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol.
メッセージの最後の64ビットMACはセクション5.1.2.2で定義されたMACアルゴリズムを使用して、MACを含まないメッセージ全体にわたって計算されます。 MACキーは、送信者のH0（セクション9で定義される）で、送信者のH0値は、後のプロトコルで受信者に知られるまで、このようにMACは、受信側で確認することができません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart1 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDr (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvr (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DHPart1 Message Format
図8：DHPart1メッセージフォーマット
The DHPart2 message, shown in Figure 9, completes the DH exchange. It is sent by the Initiator if a valid DHPart1 message is received from the Responder. The length of the pvi value and the length of the DHPart2 message depends on the Key Agreement Type chosen. This information is contained in the table in Section 5.1.5. Note that for both Multistream and Preshared modes, no DHPart1 or DHPart2 message will be sent.
図9に示さDHPart2メッセージは、DH交換を完了する。有効なDHPart1メッセージがレスポンダから受信した場合には、イニシエータによって送信されます。 PVI値とDHPart2メッセージの長さの長さは、選択された鍵合意のタイプに依存します。この情報は、5.1.5項の表に含まれています。マルチストリーム及び事前共有モードの両方のために、何DHPart1又はDHPart2メッセージが送信されないであろうことに留意されたいです。
The 256-bit hash image H1 is defined in Section 9.
256ビットのハッシュ画像H1はセクション9で定義されています。
The next four parameters are non-invertible hashes (computed in Section 4.3.1) of potential shared secrets used in generating the ZRTP secret s0. The first two, rs1IDi and rs2IDi, are the hashes of the initiator's two retained shared secrets, truncated to 64 bits. Next, there is auxsecretIDi, a hash of the initiator's auxsecret (defined in Section 4.3), truncated to 64 bits. The last parameter is a hash of the trusted MiTM PBX shared secret pbxsecret, defined in Section 7.3.1.
次の4つのパラメータはZRTP秘密S0を生成する際に使用される可能性のある共有秘密の（セクション4.3.1で計算）は、非可逆ハッシュです。最初の二つ、rs1IDiとrs2IDiは、64ビットに切り捨てイニシエータの2つの保持共有秘密キーのハッシュです。次に、auxsecretIDi、64ビットに切り捨てられた（セクション4.3で定義される）イニシエータのauxsecretのハッシュがあります。最後のパラメータは、7.3.1項で定義された秘密pbxsecretを、共有し、信頼MITM PBXのハッシュです。
The 64-bit MAC at the end of the message is computed across the whole message, not including the MAC, using the MAC algorithm defined in Section 5.1.2.2. The MAC key is the sender's H0 (defined in Section 9), and thus the MAC cannot be checked by the receiving party until the sender's H0 value is known to the receiving party later in the protocol.
メッセージの最後の64ビットMACはセクション5.1.2.2で定義されたMACアルゴリズムを使用して、MACを含まないメッセージ全体にわたって計算されます。 MACキーは、送信者のH0（セクション9で定義される）で、送信者のH0値は、後のプロトコルで受信者に知られるまで、このようにMACは、受信側で確認することができません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=depends on KA Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="DHPart2 " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Hash image H1 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs1IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rs2IDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| auxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pbxsecretIDi (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| pvi (length depends on KA Type) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: DHPart2 Message Format
図9：DHPart2メッセージフォーマット
The Confirm1 message is sent by the Responder in response to a valid DHPart2 message after the SRTP session key and parameters have been negotiated. The Confirm2 message is sent by the Initiator in response to a Confirm1 message. The format is shown in Figure 10. The message contains the Message Type Block "Confirm1" or "Confirm2". Next, there is the confirm_mac, a MAC computed over the encrypted part of the message (shown enclosed by "====" in Figure 10). This confirm_mac is keyed and computed according to Section 4.6. The next 16 octets contain the CFB Initialization Vector. The rest of the message is encrypted using CFB and protected by the confirm_mac.
CONFIRM1メッセージは、SRTPセッション鍵とパラメータ交渉された後、有効なDHPart2メッセージに応答してレスポンダによって送信されます。 Confirm2メッセージはCONFIRM1メッセージに応答して、イニシエータによって送信されます。フォーマットは、メッセージがメッセージタイプブロック「CONFIRM1」又は「Confirm2」を含む図10に示されています。次に、メッセージの暗号化部分にわたって計算confirm_mac、MACがある（「====」の図10で囲まれた示されています）。このconfirm_macはセクション4.6に従ってキー入力と計算されます。次の16個のオクテットはCFB初期ベクトルが含まれています。メッセージの残りの部分は、CFBを使用して暗号化し、confirm_macで保護されています。
The first field inside the encrypted region is the hash preimage H0, which is defined in detail in Section 9.
暗号化された領域内の最初のフィールドは、セクション9で詳細に定義されているハッシュプレイメージH0、です。
The next 15 bits are not used and SHOULD be set to zero when sent and MUST be ignored when received in Confirm1 or Confirm2 messages.
次の15ビットは使用されず、送信されCONFIRM1又はConfirm2メッセージで受信したときに無視されなければならない場合、ゼロに設定されるべきです。
The next 9 bits contain the signature length. If no SAS signature (described in Section 7.2) is present, all bits are set to zero. The signature length is in words and includes the signature type block. If the calculated signature octet count is not a multiple of 4, zeros are added to pad it out to a word boundary. If no signature is present, the overall length of the Confirm1 or Confirm2 message will be set to 19 words.
次の9ビットは、署名長を含みます。 （セクション7.2に記載）は、SAS署名が存在しない場合、すべてのビットはゼロに設定されています。署名の長さは言葉であり、署名タイプのブロックを含みます。計算されたシグニチャオクテットカウントが4の倍数でない場合、ゼロがワード境界にパッドをアウトに添加されます。何署名が存在しない場合、CONFIRM1又はConfirm2メッセージの全体の長さは、19ワードに設定されます。
The next 8 bits are used for flags. Undefined flags are set to zero and ignored. Four flags are currently defined. The PBX Enrollment flag (E) is a Boolean bit defined in Section 7.3.1. The SAS Verified flag (V) is a Boolean bit defined in Section 7.1. The Allow Clear flag (A) is a Boolean bit defined in Section 4.7.2. The Disclosure Flag (D) is a Boolean bit defined in Section 11. The cache expiration interval is defined in Section 4.9.
次の8ビットは、フラグのために使用されます。未定義のフラグがゼロに設定され、無視されます。 4つのフラグが現在定義されています。 PBX登録フラグ（E）は、セクション7.3.1で定義されたブールビットです。 SAS認証フラグ（V）は、セクション7.1で定義されたブールビットです。許可クリアフラグ（A）は、セクション4.7.2で定義されたブールビットです。公開フラグ（D）は、キャッシュの有効期間は、4.9節で定義されている節11に定義されたブールビットです。
If the signature length (in words) is non-zero, a signature type block will be present along with a signature block. Next, there is the signature block. The signature block includes the signature and the key (or a link to the key) used to generate the signature (Section 7.2).
（言葉で）署名の長さがゼロでない場合、署名タイプのブロックは、署名ブロックと一緒に存在するであろう。次に、署名ブロックがあります。署名ブロックは、署名及び署名（セクション7.2）を生成するために使用される鍵（または鍵へのリンク）を含みます。
CFB mode [NIST-SP800-38A] is applied with a feedback length of 128 bits, a full cipher block, and the final block is truncated to match the exact length of the encrypted data. The CFB Initialization Vector is a 128-bit random nonce. The block cipher algorithm and the key size are the same as the negotiated block cipher (Section 5.1.3) for media encryption. CFB is used to encrypt the part of the Confirm1 message beginning after the CFB IV to the end of the message (the encrypted region is enclosed by "====" in Figure 10).
CFBモード[NIST-SP800-38A]は128ビットのフィードバック長、完全な暗号ブロックが印加され、最終的なブロックが暗号化されたデータの正確な長さに一致するように切り捨てられます。 CFB初期化ベクトルは、128ビットのランダムなノンスです。ブロック暗号化アルゴリズムとキーサイズは、メディア暗号化のために交渉し、ブロック暗号（5.1.3項）と同じです。 CFBは、（暗号化された領域は、図10の「====」で囲まれている）メッセージの最後にCFB IV後に開始CONFIRM1メッセージの一部を暗号化するために使用されます。
The responder uses the zrtpkeyr to encrypt the Confirm1 message. The initiator uses the zrtpkeyi to encrypt the Confirm2 message.
レスポンダはCONFIRM1メッセージを暗号化するためにzrtpkeyrを使用しています。イニシエータはConfirm2メッセージを暗号化するためにzrtpkeyiを使用しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Confirm1" or "Confirm2" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| confirm_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| |
| Hash preimage H0 (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|E|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cache expiration interval (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 10: Confirm1 and Confirm2 Message Format
図10：CONFIRM1とConfirm2メッセージ形式
The Conf2ACK message is sent by the Responder in response to a valid Confirm2 message. The message format for the Conf2ACK is shown in the figure below. The receipt of a Conf2ACK stops retransmission of the Confirm2 message. Note that the first SRTP media (with a valid SRTP auth tag) from the responder also stops retransmission of the Confirm2 message.
Conf2ACKメッセージは、有効なConfirm2メッセージに応答してレスポンダによって送信されます。 Conf2ACKのメッセージフォーマットは、以下の図に示されています。 Conf2ACKの領収書はConfirm2メッセージの再送信を停止します。レスポンダから（有効SRTPの認証タグを有する）第SRTPメディアもConfirm2メッセージの再送を停止することに留意されたいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Conf2ACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Conf2ACK Message Format
図11：Conf2ACKメッセージフォーマット
The Error message is sent to terminate an in-process ZRTP key agreement exchange due to an error. The format is shown in the figure below. The use of the Error message is described in Section 4.7.1.
エラーメッセージは、エラーが原因で、プロセスZRTP鍵合意交換を終了するために送信されます。フォーマットは以下の図に示されています。エラーメッセージの使用は、セクション4.7.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=4 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Error " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Error Code (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Error Message Format
図12：エラーメッセージの形式
Defined hexadecimal values for the Error Code are listed in the table below.
エラーコードの定義済み進数の値を以下の表に記載されています。
Error Code | Meaning
-----------------------------------------------------------
0x10 | Malformed packet (CRC OK, but wrong structure)
-----------------------------------------------------------
0x20 | Critical software error
-----------------------------------------------------------
0x30 | Unsupported ZRTP version
-----------------------------------------------------------
0x40 | Hello components mismatch
-----------------------------------------------------------
0x51 | Hash Type not supported
-----------------------------------------------------------
0x52 | Cipher Type not supported
-----------------------------------------------------------
0x53 | Public key exchange not supported
-----------------------------------------------------------
0x54 | SRTP auth tag not supported
-----------------------------------------------------------
0x55 | SAS rendering scheme not supported
-----------------------------------------------------------
0x56 | No shared secret available, DH mode required
-----------------------------------------------------------
0x61 | DH Error: bad pvi or pvr ( == 1, 0, or p-1)
-----------------------------------------------------------
0x62 | DH Error: hvi != hashed data
-----------------------------------------------------------
0x63 | Received relayed SAS from untrusted MiTM
-----------------------------------------------------------
0x70 | Auth Error: Bad Confirm pkt MAC
-----------------------------------------------------------
0x80 | Nonce reuse
-----------------------------------------------------------
0x90 | Equal ZIDs in Hello
-----------------------------------------------------------
0x91 | SSRC collision
-----------------------------------------------------------
0xA0 | Service unavailable
-----------------------------------------------------------
0xB0 | Protocol timeout error
-----------------------------------------------------------
0x100 | GoClear message received, but not allowed
-----------------------------------------------------------
Table 8. ZRTP Error Codes
表8. ZRTPエラーコード
The ErrorACK message is sent in response to an Error message. The receipt of an ErrorACK stops retransmission of the Error message. The format is shown in the figure below.
ErrorACKメッセージは、エラーメッセージに応答して送信されます。 ErrorACKの領収書は、エラーメッセージの再送信を停止します。フォーマットは以下の図に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ErrorACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: ErrorACK Message Format
図13：ErrorACKメッセージフォーマット
Support for the GoClear message is OPTIONAL in the protocol, and it is sent to switch from SRTP to RTP. The format is shown in the figure below. The clear_mac is used to authenticate the GoClear message so that bogus GoClear messages introduced by an attacker can be detected and discarded. The use of GoClear is described in Section 4.7.2.
GoClearメッセージのサポートは、プロトコルではオプションであり、RTPにSRTPからスイッチに送信されます。フォーマットは以下の図に示されています。 clear_macは、攻撃者によって導入された偽のGoClearメッセージを検出して廃棄することができるようにGoClearメッセージを認証するために使用されます。 GoClearの使用は、セクション4.7.2に記載されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=5 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="GoClear " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clear_mac (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: GoClear Message Format
図14：GoClearメッセージフォーマット
Support for the ClearACK message is OPTIONAL in the protocol, and it is sent to acknowledge receipt of a GoClear. A ClearACK is only sent if the clear_mac from the GoClear message is authenticated. Otherwise, no response is returned. The format is shown in the figure below.
ClearACKメッセージのサポートは、プロトコルではオプションであり、GoClearの受信を確認するために送信されます。 GoClearメッセージからclear_macが認証された場合ClearACKにのみ送信されます。そうでなければ、何の応答が返されません。フォーマットは以下の図に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ClearACK Message Format
図15：ClearACKメッセージフォーマット
The SASrelay message is sent by a trusted MiTM, most often a PBX. It is not sent as a response to a packet, but is sent as a self-initiated packet by the trusted MiTM (Section 7.3). It can only be sent after the rest of the ZRTP key negotiations have completed, after the Confirm messages and their ACKs. It can only be sent after the trusted MiTM has finished key negotiations with the other party, because it is the other party's SAS that is being relayed. It is sent with retry logic until a RelayACK message (Section 5.14) is received or the retry schedule has been exhausted.
SASrelayメッセージは、ほとんどの場合、信頼できるMITMによってPBXに送信されます。これは、パケットへの応答として送信されていませんが、信頼できるMITM（7.3節）による自己開始したパケットとして送信されます。 ZRTPキー交渉の残りの部分は確認メッセージとそのACKの後、完了した後にのみ送信することができます。唯一それが中継されている相手のSASであるため、信頼できるMITMは、他の当事者との重要な交渉を終えた後に送信することができます。 RelayACKメッセージ（セクション5.14）が受信されるか、再試行スケジュールが排出されるまでには再試行ロジックを用いて送信されます。
If a device, usually a PBX, sends an SASrelay message, it MUST have previously declared itself as a MiTM device by setting the MiTM (M) flag in the Hello message (Section 5.2). If the receiver of the SASrelay message did not previously receive a Hello message with the MiTM (M) flag set, the Relayed SAS SHOULD NOT be rendered. A RelayACK is still sent, but no Error message is sent.
デバイスは、通常PBX、SASrelayメッセージを送信する場合、それは以前にHelloメッセージ（セクション5.2）にMITM（M）フラグを設定することにより、MITMデバイスとして自身を宣言しておく必要があります。 SASrelayメッセージの受信機は、以前MITM（M）フラグが設定されたHelloメッセージを受信しなかった場合、中継されたSASは、レンダリングされるべきではありません。 RelayACKはまだ送信されますが、エラーメッセージは送信されません。
The SASrelay message format is shown in Figure 16. The message contains the Message Type Block "SASrelay". Next, there is a MAC computed over the encrypted part of the message (shown enclosed by "====" in Figure 16). This MAC is keyed the same way as the confirm_mac in the Confirm messages (see Section 4.6). The next 16 octets contain the CFB Initialization Vector. The rest of the message is encrypted using CFB and protected by the MAC.
SASrelayメッセージフォーマットは、メッセージがメッセージタイプブロック「SASrelay」を含む図16に示されています。次に、メッセージ（図16に「====」で囲まれた図示）の暗号化された部分にわたって計算MACがあります。このMACは、確認メッセージでconfirm_macと同じようにキーが付いている（4.6節を参照してください）。次の16個のオクテットはCFB初期ベクトルが含まれています。メッセージの残りの部分は、CFBを使用して暗号化し、MACによって保護されています。
The next 15 bits are not used and SHOULD be set to zero when sent, and they MUST be ignored when received in SASrelay messages.
次の15ビットは使用されず、送信されたときにゼロに設定する必要があり、SASrelayメッセージで受信された場合、それらは無視しなければなりません。
The next 9 bits contain the signature length. The trusted MiTM MAY compute a digital signature on the SAS hash, as described in Section 7.2, using a persistent signing key owned by the trusted MiTM. If no SAS signature is present, all bits are set to zero. The signature length is in words and includes the signature type block. If the calculated signature octet count is not a multiple of 4, zeros are added to pad it out to a word boundary. If no signature block is present, the overall length of the SASrelay message will be set to 19 words.
次の9ビットは、署名長を含みます。 7.2節で説明したように、信頼できるMITMは、信頼MITMが所有する永続的な署名キーを使用して、SASのハッシュにデジタル署名を計算することができます。何SAS署名が存在しない場合、すべてのビットはゼロに設定されています。署名の長さは言葉であり、署名タイプのブロックを含みます。計算されたシグニチャオクテットカウントが4の倍数でない場合、ゼロがワード境界にパッドをアウトに添加されます。いかなる署名ブロックが存在しない場合、SASrelayメッセージの全体の長さは、19ワードに設定されます。
The next 8 bits are used for flags. Undefined flags are set to zero and ignored. Three flags are currently defined. The Disclosure Flag (D) is a Boolean bit defined in Section 11. The Allow Clear flag (A) is a Boolean bit defined in Section 4.7.2. The SAS Verified flag (V) is a Boolean bit defined in Section 7.1. These flags are updated values to the same flags provided earlier in the Confirm message, but they are updated to reflect the new flag information relayed by the PBX from the other party.
次の8ビットは、フラグのために使用されます。未定義のフラグがゼロに設定され、無視されます。 3つのフラグは、現在定義されています。公開フラグ（D）は、セクション4.7.2で定義されたブールビットを第11許可フラグをクリア（A）にある定義されたブールビットです。 SAS認証フラグ（V）は、セクション7.1で定義されたブールビットです。これらのフラグは、以前の確認メッセージで提供同じフラグに値を更新しているが、それらは他の当事者からのPBXによって中継された新しいフラグ情報を反映するように更新されます。
The next 32-bit word contains the SAS rendering scheme for the relayed sashash, which will be the same rendering scheme used by the other party on the other side of the trusted MiTM. Section 7.3 describes how the PBX determines whether the ZRTP client regards the PBX as a trusted MiTM. If the PBX determines that the ZRTP client trusts the PBX, the next 8 words contain the sashash relayed from the other party. The first 32-bit word of the sashash contains the sasvalue, which may be rendered to the user using the specified SAS rendering scheme. If this SASrelay message is being sent to a ZRTP client that does not trust this MiTM, the sashash will be ignored by the recipient and should be set to zeros by the PBX.
次の32ビットワードは、信頼MITMの反対側に他のパーティによって使用されるのと同じレンダリング方式なり中継sashash用SASレンダリング方式を含んでいます。 7.3節は、PBXがZRTPクライアントが信頼できるMITMとしてPBXに関してはかどうかを決定する方法を説明します。 PBXがZRTPクライアントはPBXを信頼していると判断した場合、次の8つのワードは、他の当事者から中継sashashが含まれています。 sashashの最初の32ビット・ワードは、指定されたSASレンダリング方式を使用してユーザにレンダリングされてもよいsasvalueを含んでいます。このSASrelayメッセージは、このMITMを信頼していないZRTPクライアントに送信されている場合、sashashは、受信者によって無視され、PBXによってゼロに設定する必要があります。
If the signature length (in words) is non-zero, a signature type block will be present along with a signature block. Next, there is the signature block. The signature block includes the signature and the key (or a link to the key) used to generate the signature (Section 7.2).
（言葉で）署名の長さがゼロでない場合、署名タイプのブロックは、署名ブロックと一緒に存在するであろう。次に、署名ブロックがあります。署名ブロックは、署名及び署名（セクション7.2）を生成するために使用される鍵（または鍵へのリンク）を含みます。
CFB mode [NIST-SP800-38A] is applied with a feedback length of 128 bits, a full cipher block, and the final block is truncated to match the exact length of the encrypted data. The CFB Initialization Vector is a 128-bit random nonce. The block cipher algorithm and the key size is same as the negotiated block cipher (Section 5.1.3) for media encryption. CFB is used to encrypt the part of the SASrelay message beginning after the CFB IV to the end of the message (the encrypted region is enclosed by "====" in Figure 16).
CFBモード[NIST-SP800-38A]は128ビットのフィードバック長、完全な暗号ブロックが印加され、最終的なブロックが暗号化されたデータの正確な長さに一致するように切り捨てられます。 CFB初期化ベクトルは、128ビットのランダムなノンスです。ブロック暗号化アルゴリズムとキーサイズは、メディア暗号化のために交渉ブロック暗号（5.1.3項）と同じです。 CFBは、（暗号化された領域は、図16に「====」で囲まれている）メッセージの最後にCFB IV後に開始SASrelayメッセージの一部を暗号化するために使用されます。
Depending on whether the trusted MiTM had taken the role of the initiator or the responder during the ZRTP key negotiation, the SASrelay message is encrypted with zrtpkeyi or zrtpkeyr.
信頼できるMITMがZRTPキーネゴシエーション中、イニシエータまたはレスポンダーの役割を取っていたかどうかに応じて、SASrelayメッセージがzrtpkeyiまたはzrtpkeyrで暗号化されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="SASrelay" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CFB Initialization Vector (4 words) |
| |
| |
+===============================================================+
| Unused (15 bits of zeros) | sig len (9 bits)|0 0 0 0|0|V|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rendering scheme of relayed SAS (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Trusted MiTM relayed sashash (8 words) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional signature type block (1 word if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| optional signature block (variable length) |
| . . . |
| |
| |
+===============================================================+
Figure 16: SASrelay Message Format
図16：SASrelayメッセージフォーマット
The RelayACK message is sent in response to a valid SASrelay message. The message format for the RelayACK is shown in the figure below. The receipt of a RelayACK stops retransmission of the SASrelay message.
RelayACKメッセージは、有効なSASrelayメッセージに応答して送信されます。 RelayACKのメッセージフォーマットは、以下の図に示されています。 RelayACKの領収書はSASrelayメッセージの再送信を停止します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="RelayACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: RelayACK Message Format
図17：RelayACKメッセージフォーマット
The Ping and PingACK messages are unrelated to the rest of the ZRTP protocol. No ZRTP endpoint is required to generate a Ping message, but every ZRTP endpoint MUST respond to a Ping message with a PingACK message.
pingとPingACKメッセージがZRTPプロトコルの残りの部分とは無関係です。いいえZRTPエンドポイントは、Pingメッセージを生成するのに必要とされないが、すべてのZRTPエンドポイントがPingACKメッセージとPingメッセージに反応しなければなりません。
Although Ping and PingACK messages have no effect on the rest of the ZRTP protocol, their inclusion in this specification simplifies the design of "bump-in-the-wire" ZRTP proxies (Section 10) (notably, [Zfone]). It enables proxies to be designed that do not rely on assistance from the signaling layer to map out the associations between media streams and ZRTP endpoints.
pingとPingACKメッセージがZRTPプロトコルの残りの部分に影響を及ぼさないが、本明細書におけるそれらの包含が「バンプ・イン・ザ・ワイヤ」ZRTPプロキシ（セクション10）の設計を簡素化（特に、[Zfone]）。これは、メディアストリームとZRTPエンドポイント間の関連をマップするために、シグナリング層からの支援に依存しないように設計することがプロキシを有効にします。
Before sending a ZRTP Hello message, a ZRTP proxy MAY send a Ping message as a means to sort out which RTP media streams are connected to particular ZRTP endpoints. Ping messages are generated only by ZRTP proxies. If neither party is a ZRTP proxy, no Ping messages will be encountered. Ping retransmission behavior is discussed in Section 6.
ZRTP Helloメッセージを送信する前に、ZRTPプロキシはRTPメディアストリームは、特定のZRTPエンドポイントに接続されている整理するための手段としてPingメッセージを送信することができます。 pingメッセージだけZRTPプロキシによって生成されます。いずれの当事者がZRTPプロキシである場合は、pingメッセージに遭遇されません。 pingの再送動作は、第6節で議論されます。
The Ping message (Figure 18) contains an "EndpointHash", defined in Section 5.16.
Pingメッセージ（図18）は、セクション5.16で定義された「EndpointHash」を含んでいます。
The Ping message contains a version number that defines what version of PingACK is requested. If that version number is supported by the Ping responder, a PingACK with a format that matches that version will be received. Otherwise, a PingACK with a lower version number may be received.
Pingメッセージは、要求されたPingACKのバージョンを定義し、バージョン番号が含まれています。そのバージョン番号は、pingの応答者、バージョンが受信されることと一致する形式でPingACKによってサポートされている場合。そうでない場合は、下位バージョン番号のPingACKが受信されてもよいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=6 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="Ping " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Ping Message Format
図18：Pingのメッセージフォーマット
A PingACK message is sent only in response to a Ping. A ZRTP endpoint MUST respond to a Ping with a PingACK message. The version of PingACK requested is contained in the Ping message. If that version number is supported, a PingACK with a format that matches that version MUST be sent. Otherwise, if the version number of the Ping is not supported, a PingACK SHOULD be sent in the format of the highest supported version known to the Ping responder. Only version "1.10" is supported in this specification.
PingACKメッセージは唯一のpingに応答して送信されます。 ZRTPエンドポイントがPingACKメッセージでpingに応答しなければなりません。 PingACKのバージョンでは、Pingメッセージに含まれている要求されました。そのバージョン番号がサポートされている場合は、そのバージョンに一致する形式でPingACKを送らなければなりません。 Pingのバージョン番号がサポートされていない場合はそれ以外の場合は、PingACKは、pingの応答者に知られている最高のサポートされるバージョンの形式で送ってください。唯一のバージョン「1.10」は、この仕様でサポートされています。
The PingACK message carries its own 64-bit EndpointHash, distinct from the EndpointHash of the other party's Ping message. It is REQUIRED that it be highly improbable for two participants in a call to have the same EndpointHash and that an EndpointHash maintains a persistent value between calls. For a normal ZRTP endpoint, such as a ZRTP-enabled VoIP client, the EndpointHash can be just the truncated ZID. For a ZRTP endpoint such as a PBX that has multiple endpoints behind it, the EndpointHash must be a distinct value for each endpoint behind it. It is recommended that the EndpointHash be a truncated hash of the ZID of the ZRTP endpoint concatenated with something unique about the actual endpoint or phone behind the PBX. This may be the SIP URI of the phone, the PBX extension number, or the local IP address of the phone, whichever is more readily available in the application environment:
PingACKメッセージは相手のPingメッセージのEndpointHashは異なる独自の64ビットEndpointHashを、運びます。呼び出し中の2人の参加者が同じEndpointHashを持っているとEndpointHashは、呼び出しの間の永続的価値を維持していることをすることは非常にありそうであることが要求されます。通常のZRTPエンドポイントの場合、このようZRTP対応のVoIPクライアントとして、EndpointHashだけで切り捨てZIDすることができます。そのようなその背後にある複数のエンドポイントを有するPBXとしてZRTPエンドポイントの場合、EndpointHashは、その背後にあるエンドポイントごとに異なる値でなければなりません。 EndpointHashは、PBXの背後にある実際のエンドポイントまたは電話に関するユニークなものとの連結ZRTPエンドポイントのZIDの短縮ハッシュすることをお勧めします。これは、アプリケーション環境でより容易に入手可能であるいずれかの電話のSIP URI、PBX内線番号、又は電話のローカルIPアドレスであってもよいです。
EndpointHash = hash(ZID || SIP URI of the endpoint)
EndpointHash =ハッシュ（エンドポイントのZID || SIP URI）
EndpointHash = hash(ZID || PBX extension number of the endpoint)
EndpointHash =ハッシュ（ZID || PBXエンドポイントの内線番号）
EndpointHash = hash(ZID || local IP address of the endpoint)
EndpointHash =ハッシュ（エンドポイントのZID ||ローカルIPアドレス）
Any of these formulae confer uniqueness for the simple case of terminating the ZRTP connection at the VoIP client, or the more complex case of a PBX terminating the ZRTP connection for multiple VoIP phones in a conference call, all sharing the PBX's ZID, but with separate IP addresses behind the PBX. There is no requirement for the same hash function to be used by both parties.
これらの式のいずれかがVoIPクライアントでZRTP接続、またはPBXのZIDを共有するすべてが、独立したとの電話会議で複数のVoIP電話用ZRTP接続を終了PBXのより複雑なケースを終了する単純なケースのための一意性を与えますIPは、PBXの後ろに対応しています。両当事者によって使用される同じハッシュ関数のための要件はありません。
The PingACK message contains the EndpointHash of the sender of the PingACK as well as the EndpointHash of the sender of the Ping. The Source Identifier (SSRC) received in the ZRTP header from the Ping packet (Figure 2) is copied into the PingACK message body (Figure 19). This SSRC is not the SSRC of the sender of the PingACK.
PingACKメッセージはPingACKの送信者のEndpointHashなどのPingの送信者のEndpointHashが含まれています。ソース識別子（SSRC）は、pingパケットからZRTPヘッダに（図2）PingACKメッセージの本文にコピーされ（図19）を与えました。このSSRCはPingACKの送信者のSSRCではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0 0 1 0 1 1 0 1 0| length=9 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="PingACK " (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version="1.10" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of PingACK Sender (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndpointHash of Received Ping (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Identifier (SSRC) of Received Ping (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: PingACK Message Format
図19：PingACKメッセージフォーマット
ZRTP uses two retransmission timers T1 and T2. T1 is used for retransmission of Hello messages, when the support of ZRTP by the other endpoint may not be known. T2 is used in retransmissions of all the other ZRTP messages.
ZRTPは、二つの再送タイマT1およびT2を使用します。 T1は、他のエンドポイントによってZRTPのサポートは知られていないかもしれないHelloメッセージの再送信のために使用されています。 T2は、他のすべてのZRTPメッセージの再送信に使用されています。
All message retransmissions MUST be identical to the initial message including nonces, public values, etc; otherwise, hashes of the message sequences may not agree.
すべてのメッセージの再送信は、ナンス、公開値などを含む最初のメッセージと同じでなければなりません。そうでない場合は、メッセージ・シーケンスのハッシュが一致しない場合があります。
Practical experience has shown that RTP packet loss at the start of an RTP session can be extremely high. Since the entire ZRTP message exchange occurs during this period, the defined retransmission scheme is defined to be aggressive. Since ZRTP packets with the exception of the DHPart1 and DHPart2 messages are small, this should have minimal effect on overall bandwidth utilization of the media session.
実際の経験は、RTPセッションの開始時にRTPパケットロスが極めて高くなることが示されました。全体ZRTPメッセージ交換は、この期間中に発生するので、定義された再送信方式は積極的であると定義されます。 DHPart1とDHPart2メッセージを除き、ZRTPパケットが小さいので、これはメディアセッションの全体的な帯域幅の使用率への影響は最小限必要があります。
ZRTP endpoints MUST NOT exceed the bandwidth of the resulting media session as determined by the offer/answer exchange in the signaling layer.
シグナリング層におけるオファー/アンサー交換によって決定されるようZRTPエンドポイントは、結果として得られるメディアセッションの帯域幅を超えてはなりません。
The Ping message (Section 5.15) may follow the same retransmission schedule as the Hello message, but this is not required in this specification. Ping message retransmission is subject to application-specific ZRTP proxy heuristics.
Pingメッセージ（セクション5.15）は、Helloメッセージと同一の再送スケジュールに従うことができるが、これは本明細書では必要とされません。 Pingメッセージの再送信は、アプリケーション固有のZRTPプロキシヒューリスティックの対象となります。
Hello ZRTP messages are retransmitted at an interval that starts at T1 seconds and doubles after every retransmission, capping at 200 ms. T1 has a recommended initial value of 50 ms. A Hello message is retransmitted 20 times before giving up, which means the entire retry schedule for Hello messages is exhausted after 3.75 seconds (50 + 100 + 18*200 ms). Retransmission of a Hello ends upon receipt of a HelloACK or Commit message.
こんにちはZRTPメッセージは200ミリ秒でキャッピング、すべての再送信後T1秒で始まり、倍の間隔で再送信されます。 T1は、50ミリ秒の推奨初期値を持っています。 HelloメッセージがHelloメッセージのための全体の再試行スケジュールが3.75秒（50 + 100 + 18 * 200ミリ秒）後に排出されることを意味し、あきらめる前に20回再送されます。こんにちはの再送信はHelloACKの受信時に終了するか、メッセージをコミットします。
The post-Hello ZRTP messages are retransmitted only by the session initiator -- that is, only Commit, DHPart2, and Confirm2 are retransmitted if the corresponding message from the responder, DHPart1, Confirm1, and Conf2ACK, are not received. Note that the Confirm2 message retransmission can also be stopped by receiving the first SRTP media (with a valid SRTP auth tag) from the responder.
DHPart2、つまり、唯一のコミット、および応答、DHPart1、CONFIRM1、およびConf2ACKから対応するメッセージは、受信されない場合Confirm2が再送信されている - ポストこんにちはZRTPメッセージはセッションイニシエータによって再送されています。 Confirm2メッセージ再送もレスポンダから（有効SRTPの認証タグを有する）第SRTPメディアを受信することによって停止させることができることに留意されたいです。
The GoClear, Error, and SASrelay messages may be initiated and retransmitted by either party, and responded to by the other party, regardless of which party is the overall session initiator. They are retransmitted if the corresponding response message ClearACK, ErrorACK, and RelayACK are not received.
GoClear、エラー、およびSASrelayメッセージが開始され、いずれかの当事者によって再送、およびかかわらず、全体的なセッションイニシエータである党の、他の当事者によって応答することができます。対応する応答メッセージClearACK、ErrorACK、およびRelayACKが受信されない場合、彼らは再送信されます。
Non-Hello (and non-Ping) ZRTP messages are retransmitted at an interval that starts at T2 seconds and doubles after every retransmission, capping at 1200 ms. T2 has a recommended initial value of 150 ms. Each non-Hello message is retransmitted 10 times before giving up, which means the entire retry schedule is exhausted after 9.45 seconds (150 + 300 + 600 + 7*1200 ms). Only the initiator performs retransmissions. Each message has a response message that stops retransmissions, as shown in the table below. The higher values of T2 means that retransmissions will likely occur only in the event of packet loss.
非こんにちは（および非のPing）ZRTPメッセージは1200ミリ秒でキャッピング、すべての再送信の後にT2秒から始まり、倍の間隔で再送信されます。 T2は150ミリ秒の推奨初期値を持っています。各非ハローメッセージ全体の再試行スケジュールは9.45秒（150 + 300 + 600 + 7 * 1200ミリ秒）後に排出されることを意味し、あきらめる前に10回再送されます。唯一のイニシエータは、再送信を行います。各メッセージは、以下の表に示すように、再送を停止応答メッセージを有しています。 T2の高い値は、再送信の可能性が高いパケットロスが発生した場合にのみ発生することを意味します。
Message Acknowledgement Message
------- -----------------------
Hello HelloACK or Commit
Commit DHPart1 or Confirm1
DHPart2 Confirm1
Confirm2 Conf2ACK or SRTP media
GoClear ClearACK
Error ErrorACK
SASrelay RelayACK
Ping PingACK
Table 9. Retransmitted ZRTP Messages and Responses
表9.再送ZRTPメッセージと応答
The retry schedule must handle not only packet loss, but also slow or heavily loaded peers that need additional time to perform their DH calculations. The following mitigations are recommended:
再試行スケジュールはまただけでなく、パケット損失が、そのDH計算を実行するために追加の時間を必要とする低速または負荷の大きいピアを処理する必要があります。以下の緩和策を推奨します。
o Slow or heavily loaded ZRTP endpoints that are at risk of taking too long to perform their DH calculation SHOULD use a HelloACK message instead of a Commit message to reply to a Hello from the other party.
Oの代わりにコミットメッセージのHelloACKメッセージを使用すべきである彼らのDH計算を実行するために時間がかかりすぎるのリスクがある低速または高負荷ZRTPエンドポイントは、他の当事者からこんにちはに返信します。
o If a ZRTP endpoint has evidence that the other party is a ZRTP endpoint, by receiving a Hello message or Ping message, or by receiving a Hello Hash in the signaling layer, it SHOULD extend its own Hello retry schedule to span at least 12 seconds of retries. If this extended Hello retry schedule is exhausted without receiving a HelloACK or Commit message, a late Commit message from the peer SHOULD still be accepted.
ZRTPエンドポイントは、相手がHelloメッセージやPingメッセージを受信することにより、またはシグナリング層でこんにちはハッシュを受信することにより、ZRTPエンドポイントであるという証拠を持っている場合は、O、それは少なくとも12秒にまたがるスケジュールを再試行し、独自のHelloを拡張する必要があります再試行の。これはこんにちはHelloACKを受けることなく、スケジュールが排出される再試行するか、またはメッセージをコミット拡張した場合は、ピアからの後半にコミットメッセージはまだ受け入れられるべきです。
These recommended retransmission intervals are designed for a typical broadband Internet connection. In some high-latency communication channels, such as those provided by some mobile phone environments or geostationary satellites, a different retransmission schedule may be used. The initial value for the T1 or T2 retransmission timer should be increased to be no less than the round-trip time provided by the communications channel. It should take into account the time required to transmit the entire message and the entire reply, as well as a reasonable time estimate to perform the DH calculation.
これらの推奨再送間隔は、典型的なブロードバンドインターネット接続のために設計されています。そのようないくつかの携帯電話環境または静止衛星によって提供されるもののようないくつかの高レーテンシ通信チャネルにおいて、異なる再送スケジュールを使用することができます。 T1又はT2の再送タイマの初期値は、通信チャネルによって提供される往復時間よりも小さいことがないように増加されなければなりません。それは考慮にDH計算を実行するために、メッセージ全体と全体の応答だけでなく、合理的な時間の見積もりを送信するのに必要な時間を取る必要があります。
ZRTP has its own retransmission schedule because it is carried along with RTP, usually over UDP. In unusual cases, RTP can run over a non-UDP transport, such as TCP or DCCP, which provides its own built-in retransmission mechanism. It may be hard for the ZRTP endpoint to detect that TCP is being used if media relays are involved. The ZRTP endpoint may be sending only UDP, but there may be a media relay along the media path that converts from UDP to TCP for part of the journey. Or, if the ZRTP endpoint is sending TCP, the media relay might be converting from TCP to UDP. There have been empirical observations of this in the wild. In cases where TCP is used, ZRTP and TCP might together generate some extra retransmissions. It is tempting to avoid this effect by eliminating the ZRTP retransmission schedule when connected to a TCP channel, but that would risk failure of the protocol, because it may not be TCP all the way to the remote ZRTP endpoint. It only takes a few packets to complete a ZRTP exchange, so trying to optimize out the extra retransmissions in that scenario is not worth the risk.
それは通常UDP上で、RTPと一緒に運ばれているのでZRTPは独自の再送スケジュールを持っています。珍しいケースでは、RTPは独自の内蔵における再送メカニズムを提供し、このようなTCPやDCCPなどの非UDPトランスポートを、上で実行することができます。 ZRTPエンドポイントがメディアリレーが含まれている場合は、TCPが使用されていることを検出することは難しいかもしれません。 ZRTPエンドポイントはUDPのみを送信することができるが、旅の一部のためにUDPからTCPに変換し、媒体経路に沿ってメディアリレーがあるかもしれません。 ZRTPエンドポイントがTCPを送信している場合や、メディアリレーは、TCPからUDPに変換される可能性があります。野生でこの経験的観察が行われています。 TCPが使用されている場合には、ZRTPとTCPは、一緒にいくつかの余分な再送信を生成することがあります。 TCPチャネルに接続されたときにZRTP再送スケジュールを排除することによって、この影響を避けるために魅力的ですが、それは、リモートZRTPエンドポイントへのすべての方法TCPではないかもしれないので、それは、プロトコルの失敗を危険にさらすだろう。それが唯一のようなシナリオでは、余分な再送信を最適化しようと、ZRTP交換を完了するために、いくつかのパケットを取ることは、リスクの価値ではありません。
After receiving a Commit message, but before receiving a Confirm2 message, if a ZRTP responder receives no ZRTP messages for more than 10 seconds, the responder MAY send a protocol timeout Error message and terminate the ZRTP protocol.
メッセージをコミット受け取った後、しかしZRTPの応答者が10秒以上何もZRTPメッセージを受信しない場合、Confirm2メッセージを受信する前に、レスポンダは、プロトコルのタイムアウトエラーメッセージを送信し、ZRTPプロトコルを終了することができます。
This section will discuss the implementation of the Short Authentication String, or SAS in ZRTP. The SAS can be verbally compared by the human users reading the string aloud, or it can be compared by validating an OPTIONAL digital signature (described in Section 7.2) exchanged in the Confirm1 or Confirm2 messages.
このセクションでは、ショート認証文字列、またはZRTPにおけるSASの実装について説明します。 SASは、口頭で声を出して、文字列を読み取る人間のユーザによって比較することができ、またはそれは（セクション7.2を参照）オプションのデジタル署名を検証することによって比較することができるCONFIRM1又はConfirm2メッセージで交換しました。
The use of hash commitment in the DH exchange (Section 4.4.1.1) constrains the attacker to only one guess to generate the correct SAS in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. How the hash commitment enables the SAS to be so short is explained in Section 4.4.1.1.
DH交換（セクション4.4.1.1）でハッシュのコミットメントを使用するには、SASが非常に短くすることができることを意味し、彼の攻撃、正しいSASを生成するための唯一の推測に攻撃を制約します。 16ビットSASは、例えば、攻撃者が検出されないの65536のうち一つだけのチャンスを提供します。どのようにハッシュのコミットメントは、SASがとても短いことを可能にすることは、セクション4.4.1.1で説明されています。
There is only one SAS value computed per call. That is the SAS value for the first media stream established, which is calculated in Section 4.5.2. This SAS applies to all media streams for the same session.
呼び出しごとに計算された唯一の1 SAS値があります。すなわち、セクション4.5.2で計算され確立された第一のメディアストリームのためのSAS値です。このSASは、同じセッションのすべてのメディアストリームに適用されます。
The SAS SHOULD be rendered to the user for authentication. The rendering of the SAS value through the user interface at both endpoints depends on the SAS Type agreed upon in the Commit message. See Section 5.1.6 for a description of how the SAS is rendered to the user.
SASは、認証のためにユーザにレンダリングされるべきです。両方のエンドポイントのユーザインタフェースを介してSAS値のレンダリングは、SASタイプコミットメッセージに合意に依存します。 SASは、ユーザーにレンダリングされる方法の詳細については、セクション5.1.6を参照してください。
The SAS is not treated as a secret value, but it must be compared to see if it matches at both ends of the communications channel. The two users verbally compare it using their human voices, human ears, and human judgement. If it doesn't match, it indicates the presence of a MiTM attack.
SASは、秘密の値として処理されていないが、通信チャネルの両端に一致するかどうかを確認するために比較されなければなりません。 2人のユーザが口頭で、それは彼らの人間の声、人間の耳、そして人間の判断を使用して比較します。それが一致しない場合は、MITM攻撃の存在を示しています。
It is worse than useless and absolutely unsafe to rely on a robot voice from the remote endpoint to compare the SAS, because a robot voice can be trivially forged by a MiTM. The SAS verbal comparison can only be done with a real live human at the remote endpoint.
ロボットの声が自明MITMによって偽造することができますので、SASを比較するために、リモートエンドポイントからのロボットの声に頼っても無駄よりも悪いと絶対に安全ではありません。 SAS口頭での比較だけでリモートエンドポイントで本物の人間で行うことができます。
The SAS Verified flag (V) is set based on the user indicating that SAS comparison has been successfully performed. The SAS Verified flag is exchanged securely in the Confirm1 and Confirm2 messages (Figure 10) of the next session. In other words, each party sends the SAS Verified flag from the previous session in the Confirm message of the current session. It is perfectly reasonable to have a ZRTP endpoint that never sets the SAS Verified flag, because it would require adding complexity to the user interface to allow the user to set it. The SAS Verified flag is not required to be set, but if it is available to the client software, it allows for the possibility that the client software could render to the user that the SAS verify procedure was carried out in a previous session.
SAS認証フラグ（V）は、SASの比較が成功したことを示すユーザに基づいて設定されます。 SAS認証フラグは、次のセッションのCONFIRM1とConfirm2メッセージ（図10）に確実に交換されます。換言すれば、各当事者は、現在のセッションの確認メッセージの前のセッションからSAS認証フラグを送信します。それは、ユーザーがそれを設定することができるように、ユーザインタフェースに複雑にすることが必要となるので、SAS確認済みフラグをセットすることはありませんZRTPエンドポイントを持っていることは完全に合理的です。 SAS確認済みフラグを設定する必要が、それは、クライアントソフトウェアが利用可能である場合、それは、クライアントソフトウェアはSASが、前のセッションで行われた手順を確認し、ユーザーにレンダリングすることができる可能性を可能にしていません。
Regardless of whether there is a user interface element to allow the user to set the SAS Verified flag, it is worth caching a shared secret, because doing so reduces opportunities for an attacker in the next call.
そうすることが次の呼び出しでの攻撃の機会を減らすためにかかわらず、ユーザーがSAS確認済みフラグを設定することを可能にするユーザインタフェース要素があるかどうかの、それは、共有秘密をキャッシュする価値があります。
If at any time the users carry out the SAS comparison procedure, and it actually fails to match, then this means there is a very resourceful MiTM. If this is the first call, the MiTM was there on the first call, which is impressive enough. If it happens in a later call, it also means the MiTM must also know the cached shared secret, because you could not have carried out any voice traffic at all unless the session key was correctly computed and is also known to the attacker. This implies the MiTM must have been present in all the previous sessions, since the initial establishment of the first shared secret. This is indeed a resourceful attacker. It also means that if at any time he ceases his participation as a MiTM on one of your calls, the protocol will detect that the cached shared secret is no longer valid -- because it was really two different shared secrets all along, one of them between Alice and the attacker, and the other between the attacker and Bob. The continuity of the cached shared secrets makes it possible for us to detect the MiTM when he inserts himself into the ongoing relationship, as well as when he leaves. Also, if the attacker tries to stay with a long lineage of calls, but fails to execute a DH MiTM attack for even one missed call, he is permanently excluded. He can no longer resynchronize with the chain of cached shared secrets.
任意の時点で、ユーザーはSASの比較手順を実行し、それが実際に一致しない場合、これは非常に機知にMITMがあることを意味します。これが最初の呼び出しである場合は、MITMは十分に印象的である最初の呼び出し、上がありました。それは、後の呼び出しで発生した場合、それはまた、セッション鍵が正しく計算され、また、攻撃者に知られていない限り、あなたはまったく音声トラフィックを行っていることができなかったので、MITMはまた、キャッシュされた共有秘密を知っていなければならないことを意味します。これは、MITMは、最初の共有秘密の最初の設立以来、すべての以前のセッションに存在している必要がありますを意味します。これは確かに機知攻撃です。それはすべてに沿って実際には2つの異なる共有秘密だったので、そのうちの一つを - それはまた、任意の時点で、彼はあなたの呼び出しの1にMITMとしての彼の参加を中止する場合は、プロトコルがキャッシュされた共有秘密は、もはや有効であることを検出しないことを意味しますアリスと攻撃、攻撃者とボブの間に他の間で。彼は、彼が離れたときだけでなく、継続的な関係に身を挿入したときに、私たちはMITMを検出するために、キャッシュされた共有秘密の連続性は、それが可能になります。攻撃者は呼び出しの長い系譜に滞在しようとしますが、一つでも不在着信のためにDH MITM攻撃を実行するのに失敗した場合にも、彼は永久に除外されています。彼はもはや、キャッシュされた共有秘密のチェーンと再同期することはできません。
A user interface element (i.e., a checkbox or button) is needed to allow the user to tell the software the SAS verify was successful, causing the software to set the SAS Verified flag (V), which (together with our cached shared secret) obviates the need to perform the SAS procedure in the next call. An additional user interface element can be provided to let the user tell the software he detected an actual SAS mismatch, which indicates a MiTM attack. The software can then take appropriate action, clearing the SAS Verified flag, and erase the cached shared secret from this session. It is up to the implementer to decide if this added user interface complexity is warranted.
ユーザーインターフェイス要素（すなわち、チェックボックスやボタンは）SAS確認済みフラグ（V）を、設定するためのソフトウェアを引き起こし、SASが成功した検証ソフトウェアを伝えるために、ユーザーを可能にするために必要とされている（私たちのキャッシュされたが、秘密の共有一緒に）次の呼び出しでSASの手順を実行する必要がなくなります。追加のユーザーインターフェイス要素は、ユーザーが、彼はMITM攻撃を示し、実際のSASの不一致が、検出されたソフトウェアを伝えてみましょうするために提供することができます。ソフトウェアは、SAS確認済みフラグをクリアし、適切な行動を取ると、このセッションからキャッシュされた共有秘密鍵を消去することができます。これは、この追加したユーザインタフェースの複雑さが保証されるかどうかを判断するために実装次第です。
If the SAS matches, it means there is no MiTM, which also implies it is now safe to trust a cached shared secret for later calls. If inattentive users don't bother to check the SAS, it means we don't know whether there is or is not a MiTM, so even if we do establish a new cached shared secret, there is a risk that our potential attacker may have a subsequent opportunity to continue inserting himself in the call, until we finally get around to checking the SAS. If the SAS matches, it means no attacker was present for any previous session since we started propagating cached shared secrets, because this session and all the previous sessions were also authenticated with a continuous lineage of shared secrets.
SASが一致した場合、それはまた、後で呼び出しのためにキャッシュされた共有秘密を信頼しても安全である意味何MITMは、存在しないことを意味します。不注意、ユーザーがSASをチェックする気にしない場合、それは我々がそこにあるかMITM、ではありませんので、我々は新しいキャッシュされた共有秘密を確立しない場合でも、私たちの潜在的な攻撃者が有してもよい危険性があるかどうかわからない意味しますその後のチャンスは我々が最終的にSASを確認するには周りを取得するまで、コールに自分自身を挿入して続行します。 SASが一致した場合、それはこのセッションおよび以前のすべてのセッションも共有秘密の連続系統を使用して認証されたので、我々は、キャッシュされた共有秘密を伝播し始めてから何の攻撃者が任意の前のセッションのために存在しないことを意味します。
In most applications, it is desirable to avoid the added complexity of a PKI-backed digital signature, which is why ZRTP is designed not to require it. Nonetheless, in some applications, it may be hard to arrange for two human users to verbally compare the SAS. Or, an application may already be using an existing PKI and wants to use it to augment ZRTP.
ほとんどのアプリケーションでは、ZRTPは、それを必要としないように設計されている理由であるPKI担保デジタル署名の追加の複雑さを回避することが望ましいです。それにもかかわらず、一部のアプリケーションでは、口頭でSASを比較するために、2人のユーザーのために手配するのは難しいかもしれません。または、アプリケーションは、既存のPKIを使用してZRTPを強化するためにそれを使用したいと考えてよいです。
To handle these cases, ZRTP allows for an OPTIONAL signature feature, which allows the SAS to be checked without human participation. The SAS MAY be signed and the signature sent inside the Confirm1, Confirm2 (Figure 10), or SASrelay (Figure 16) messages. The signature type (Section 5.1.7), length of the signature, and the key used to create the signature (or a link to it) are all sent along with the signature. The signature is calculated across the entire SAS hash result (sashash), from which the sasvalue was derived. The signatures exchanged in the encrypted Confirm1, Confirm2, or SASrelay messages MAY be used to authenticate the ZRTP exchange. A signature may be sent only in the initial media stream in a DH or ECDH ZRTP exchange, not in Multistream mode.
これらの場合を扱うために、ZRTPは、SASは、人間の参加なしに確認することを可能にするOPTIONAL署名機能を可能にします。 SASは、署名されてもよく、署名はCONFIRM1、Confirm2（図10）、又はSASrelay（図16）メッセージ内部送ら。署名タイプ（セクション5.1.7）、署名の長さ、及び署名（またはそれへのリンク）を作成するために使用される鍵は、すべての署名とともに送信されます。署名はsasvalueが由来する全体のSASハッシュ結果（sashash）にわたって計算されます。暗号化されたCONFIRM1、Confirm2、またはSASrelayメッセージでやり取り署名がZRTP交換を認証するために使用されるかもしれません。署名がないマルチストリームモードでは、DHまたはECDH ZRTP交換にのみ初期メディアストリームで送信されてもよいです。
Although the signature is sent, the material that is signed, the sashash, is not sent with it in the Confirm message, since both parties have already independently calculated the sashash. That is not the case for the SASrelay message, which must relay the sashash. To avoid unnecessary signature calculations, a signature SHOULD NOT be sent if the other ZRTP endpoint did not set the (S) flag in the Hello message (Section 5.2).
署名が送信されているが、両当事者がすでに独立sashashを算出しているため、署名されている材料、sashashは、確認メッセージでそれに送信されません。それはsashashを中継しなければならないSASrelayメッセージ、の場合はそうではありません。他のZRTPエンドポイントは、Helloメッセージ（セクション5.2）に（S）フラグを設定しなかった場合は、不必要な署名の計算を回避するために、署名を送るべきではありません。
Note that the choice of hash algorithm used in the digital signature is independent of the hash used in the sashash. The sashash is determined by the negotiated Hash Type (Section 5.1.2), while the hash used by the digital signature is separately defined by the digital signature algorithm. For example, the sashash may be based on SHA-256, while the digital signature might use SHA-384, if an ECDSA P-384 key is used.
デジタル署名に使用されるハッシュアルゴリズムの選択はsashashで使用されるハッシュとは無関係であることに留意されたいです。デジタル署名が使用するハッシュを別々にデジタル署名アルゴリズムによって定義されている間sashashは、ネゴシエートされたハッシュタイプ（セクション5.1.2）によって決定されます。 ECDSA P-384キーが使用される場合、デジタル署名は、SHA-384を使用するかもしれないが、例えば、sashashは、SHA-256に基づくことができます。
If the sashash (which is always truncated to 256 bits) is shorter than the signature hash, the security is not weakened because the hash commitment precludes the attacker from searching for sashash collisions.
（常に256ビットに切り捨てられる）sashashが署名ハッシュよりも短い場合、ハッシュコミットメントがsashashの衝突を探してから、攻撃者を排除するため、セキュリティが弱くなっていません。
ECDSA algorithms may be used with either OpenPGP-formatted keys, or X.509v3 certificates. If the ZRTP key exchange is ECDH, and the SAS is signed, then the signature SHOULD be ECDSA, and SHOULD use the same size curve as the ECDH exchange if an ECDSA key of that size is available.
ECDSAアルゴリズムは、OpenPGPの形式のキー、またはのX.509v3証明書のいずれかと共に使用することができます。 ZRTP鍵交換はECDHで、SASが署名されている場合、署名は、ECDSAであるべきであり、その大きさのECDSAキーが利用可能である場合ECDH交換と同じサイズの曲線を使用すべきです。
If a ZRTP endpoint supports incoming signatures (evidenced by setting the (S) flag in the Hello message), it SHOULD be able to parse signatures from the other endpoint in OpenPGP format and MUST be able to parse them in X.509v3 format. If the incoming signature is in an unsupported format, or the trust model does not lead to a trusted introducer or a trusted certificate authority (CA), another authentication method may be used if available, such as the SAS compare, or a cached shared secret from a previous session. If none of these methods are available, it is up to the ZRTP user agent and the user to decide whether to proceed with the call, after the user is informed.
ZRTPエンドポイントが（Helloメッセージにおいて（S）フラグを設定することによって証明）着信署名をサポートしている場合、OpenPGP形式で他のエンドポイントからのシグネチャを解析することが可能であるべきであり、のX.509v3形式でそれらを解析できなければなりません。着信署名がサポートされていない形式である、または信頼モデルが信頼導入または信頼できる認証局（CA）につながらない場合は利用可能な場合、他の認証方法は、SASのように、使用することができる比較、またはキャッシュされた共有シークレット前のセッションから。これらの方法のいずれもが使用できない場合は、ZRTPユーザエージェントとユーザが通知された後、呼び出しを続行するかどうかを決定するために、ユーザー次第です。
Both ECDSA and DSA [FIPS-186-3] have a feature that allows most of the signature calculation to be done in advance of the session, reducing latency during call setup. This is useful for low-power mobile handsets.
ECDSAとDSA [FIPS-186-3]の両方が署名計算のほとんどは、コールセットアップ中の待ち時間を低減する、セッションの前に行われることを可能にする機能を有しています。これは、低消費電力の携帯電話のために有用です。
ECDSA is preferred because it has compact keys as well as compact signatures. If the signature along with its public key certificate are insufficiently compact, the Confirm message may become too long for the maximum transmission unit (MTU) size, and UDP fragmentation may result. Some firewalls and NATs may discard fragmented UDP packets, which would cause the ZRTP exchange to fail. It is RECOMMENDED that a ZRTP endpoint avoid sending signatures if they would cause UDP fragmentation. For a discussion on MTU size and PMTU discovery, see [RFC1191] and [RFC1981].
それはコンパクトキー並びにコンパクト署名を持っているので、ECDSAが好ましいです。その公開鍵証明書とともに署名が十分にコンパクトである場合、確認メッセージが最大伝送単位（MTU）サイズのためにあまりにも長くなることがあり、およびUDP断片化は生じ得ます。一部のファイアウォールやNATはZRTP交換が失敗する原因と思われる、断片化されたUDPパケットを破棄してもよいです。彼らがUDPの断片化の原因となる場合ZRTPエンドポイントの回避が署名を送ることが推奨されます。 MTUサイズとPMTU検出についての議論に関しては、[RFC1191]と[RFC1981]を参照してください。
From a packet-size perspective, ECDSA and DSA both produce equally compact signatures for a given signature strength. DSA keys are much bigger than ECDSA keys, but in the case of OpenPGP signatures, the public key is not sent along with the signature.
パケットサイズの観点から、ECDSAとDSAの両方が与えられた署名強度に等しくコンパクト署名を生成します。 DSA鍵はECDSAキーよりもはるかに大きいですが、OpenPGPの署名の場合には、公開鍵は、署名と一緒に送られていません。
All signatures generated MUST use only NIST-approved hash algorithms, and MUST avoid using SHA1. This applies to both OpenPGP and X.509v3 signatures. NIST-approved hash algorithms are found in [FIPS-180-3] or its SHA-3 successor. All ECDSA curves used throughout this spec are over prime fields, drawn from Appendix D.1.2 of [FIPS-186-3].
生成されたすべての署名は唯一NISTが承認したハッシュアルゴリズムを使用しなければならない、とSHA1を使用して避けなければなりません。これは、OpenPGPのとのX.509v3署名の両方に適用されます。 NIST承認ハッシュアルゴリズムは[FIPS-180-3]またはそのSHA-3後継に見出されます。この仕様全体で使用されるすべてのECDSA曲線は、素体の上にある[FIPS-186-3]の付録D.1.2から引き出されます。
If the SAS Signature Type (Section 5.1.7) specifies an OpenPGP signature ("PGP "), the signature-related fields are arranged as follows.
SAS署名タイプ（セクション5.1.7）はOpenPGPの署名（「PGP」）を指定した場合、以下のように、署名関連フィールドが配置されています。
The first field after the 4-octet Signature Type Block is the OpenPGP signature. The format of this signature and the algorithms that create it are specified by [RFC4880]. The signature is comprised of a complete OpenPGP version 4 signature in binary form (not Radix-64), as specified in RFC 4880, Section 5.2.3, enclosed in the full OpenPGP packet syntax. The length of the OpenPGP signature is parseable from the signature, and depends on the type and length of the signing key.
4オクテット署名タイプブロックの後の最初のフィールドは、OpenPGPの署名です。この署名の形式とそれを作成するアルゴリズムは[RFC4880]で指定されています。署名がバイナリ形式で完全なOpenPGPのバージョン4シグネチャから構成されている（基数64ではない）、完全なOpenPGPのパケット構文で囲まれたRFC 4880のセクション5.2.3で指定されるように。 OpenPGPの署名の長さは、署名から解析可能であり、署名キーの種類と長さに依存します。
If OpenPGP signatures are supported, an implementation SHOULD NOT generate signatures using any other signature algorithm except DSA or ECDSA (ECDSA is a reserved algorithm type in RFC 4880), but MAY accept other signature types from the other party. DSA signatures with keys shorter than 2048 bits or longer than 3072 bits MUST NOT be generated.
OpenPGPの署名がサポートされている場合、実装は、DSAまたはECDSAを除く他の署名アルゴリズム（ECDSAは、RFC 4880で予約アルゴリズムの一種である）を使用して署名を生成するべきではなく、他の当事者から他の署名タイプを受け入れることができます。 2048ビット以上より3072ビットより短い鍵とDSA署名を生成してはなりません。
Implementers should be aware that ECDSA signatures for OpenPGP are expected to become available when the work in progress [ECC-OpenPGP] becomes an RFC. Any use of ECDSA signatures in ZRTP SHOULD NOT generate signatures using ECDSA key sizes other than P-224, P-256, and P-384, as defined in [FIPS-186-3].
実装は、OpenPGPのためのECDSA署名が進行中の作業[ECC-のOpenPGP]はRFCになったときに利用可能になると期待されることに注意すべきです。 [FIPS-186-3]で定義されるようZRTPにおけるECDSA署名の使用は、P-224以外ECDSA鍵サイズ、P-256およびP-384を使用して署名を生成するべきではありません。
RFC 4880, Section 5.2.3.18, specifies a way to embed, in an OpenPGP signature, a URI of the preferred key server. The URI should be fully specified to obtain the public key of the signing key that created the signature. This URI MUST be present. It is up to the recipient of the signature to obtain the public key of the signing key and determine its validity status using the OpenPGP trust model discussed in [RFC4880].
RFC 4880、セクション5.2.3.18は、OpenPGPの署名、優先キーサーバーのURIで、埋め込む方法を指定します。 URIは完全に署名を作成した署名鍵の公開鍵を取得するために指定する必要があります。このURIが存在しなければなりません。これは、署名鍵の公開鍵を取得して、[RFC4880]で説明したのOpenPGP信頼モデルを使用して、その有効性ステータスを決定するために、署名の受信者次第です。
The contents of Figure 20 lie inside the encrypted region of the Confirm message (Figure 10) or the SASrelay message (Figure 16).
確認メッセージの暗号化された領域内の、図20嘘の内容（図10）またはSASrelayメッセージ（図16）。
The total length of all the material in Figure 20, including the key server URI, must not exceed 511 32-bit words (2044 octets). This length, in words, is stored in the signature length field in the Confirm or SASrelay message containing the signature. It is desirable to avoid UDP fragmentation, so the URI should be kept short.
鍵サーバURIを含む、図20内のすべての材料の合計の長さは、511の32ビットワード（2044オクテット）を超えてはなりません。この長さは、言葉で、確認または署名を含むSASrelayメッセージに署名長さフィールドに格納されます。 UDPの断片化を避けることが望ましいので、URIを短くしてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "PGP " (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OpenPGP signature |
| (variable length) |
| . . . |
| |
+===============================================================+
Figure 20: OpenPGP Signature Format
図20：OpenPGPの署名フォーマット
If the SAS Signature Type (Section 5.1.7) is "X509", the ECDSA signature-related fields are arranged as follows.
SAS署名タイプ（セクション5.1.7）は、「X509」であれば次のように、ECDSA署名関連フィールドが配置されています。
The first field after the 4-octet Signature Type Block is the DER encoded X.509v3 certificate (the signed public key) of the ECDSA signing key that created the signature. The format of this certificate is specified by the NSA's Suite B Certificate and CRL Profile [RFC5759].
4オクテット署名タイプブロックの後の最初のフィールドは、署名を作成したECDSA署名鍵のDER符号化されたX.509v3証明書（署名された公開鍵）です。この証明書のフォーマットは、NSAのスイートB証明書とCRLプロフィール[RFC5759]で指定されています。
Following the X.509v3 certificate at the next word boundary is the ECDSA signature itself. The size of this field depends on the size and type of the public key in the aforementioned certificate. The format of this signature and the algorithms that create it are specified by [FIPS-186-3]. The signature is comprised of the ECDSA signature output parameters (r, s) in binary form, concatenated, in network byte order, with no truncation of leading zeros. The first half of the signature is r and the second half is s. If ECDSA P-256 is specified, the signature fills 16 words (64 octets), 32 octets each for r and s. If ECDSA P-384 is specified, the signature fills 24 words (96 octets), 48 octets each for r and s.
次の単語境界でのX.509v3証明書に続いて、ECDSA署名そのものです。このフィールドのサイズは、前述した証明書の公開鍵のサイズや種類によって異なります。この署名の形式とそれを作成するアルゴリズムは[FIPS-186-3]によって指定されます。署名は、先行ゼロのない切捨てと、ネットワークバイト順で、バイナリ形式、連結でECDSA署名出力パラメータ（R、S）から構成されています。署名の前半はRであり、後半はsです。 ECDSA P-256が指定されている場合、署名は、rおよびsのために16ワード（64オクテット）、32オクテットそれぞれを満たします。 ECDSA P-384が指定されている場合、署名は、rおよびsのために24ワード（96オクテット）、48オクテットそれぞれを満たします。
It is up to the recipient of the signature to use information in the certificate and path discovery mechanisms to trace the chain back to the root CA. It is recommended that end user certificates issued for secure telephony should contain appropriate path discovery links to facilitate this.
これは、バックルートCAにチェーンを追跡するための証明書とパス発見機構内の情報を使用して、署名の受信者に任されてセキュアなテレフォニーのために発行され、エンドユーザ証明書がこれを容易にするために適切なパスディスカバリのリンクが含まれている必要があることをお勧めします。
Figure 21 shows a certificate and an ECDSA signature. All this material lies inside the encrypted region of the Confirm message (Figure 10) or the SASrelay message (Figure 16).
図21は、証明書とECDSA署名を示しています。すべてのこの材料は、確認メッセージ（図10）またはSASrelayメッセージ（図16）の暗号化された領域内にあります。
The total length of all the material in Figure 21, including the X.509v3 certificate, must not exceed 511 32-bit words (2044 octets). This length, in words, is stored in the signature length field in the Confirm or SASrelay message containing the signature. It is desirable to avoid UDP fragmentation, so the certificate material should be kept to a much smaller size than this. End user certs issued for this purpose should minimize the size of extraneous material such as legal notices.
X.509v3証明書を含む、図21内のすべての材料の合計の長さは、511の32ビットワード（2044オクテット）を超えてはなりません。この長さは、言葉で、確認または署名を含むSASrelayメッセージに署名長さフィールドに格納されます。 UDPの断片化を避けることが望ましいので、証明書の材料はこれよりはるかに小さいサイズに抑える必要があります。この目的のために発行されたエンドユーザーの本命は、法的通知など異物の大きさを最小限に抑える必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Type Block = "X509" (1 word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signing key's X.509v3 certificate |
| (variable length) |
| . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ECDSA P-256 or P-384 signature |
| (16 words or 24 words) |
| . . . |
| |
+===============================================================+
Figure 21: X.509v3 ECDSA Signature Format
図21：のX.509v3 ECDSA署名フォーマット
It's not strictly necessary to use a PKI to back the public key that signs the SAS. For example, it is possible to use a self-signed X.509v3 certificate or an OpenPGP key that is not signed by any other key. In this scenario, the same key continuity technique used by SSH [RFC4251] may be used. The public key is cached locally the first time it is encountered, and when the same public key is encountered again in subsequent sessions, it's deemed not to be a MiTM attack. If there is no MiTM attack in the first session, there cannot be a MiTM attack in any subsequent session. This is exactly how SSH does it.
これは、SASに署名公開鍵をバックアップするためにPKIを使用するように、厳密には必要ありません。例えば、自己署名X.509v3証明書または他の任意のキーによって署名されていないのOpenPGPキーを使用することが可能です。このシナリオでは、SSH [RFC4251]で使用されるのと同じキー連続技術が使用されてもよいです。公開鍵は、ローカルにそれが検出された最初の時間をキャッシュされ、同じ公開鍵はその後のセッションに再び遭遇したとき、MITM攻撃ではないとみなされます。最初のセッションにはMITM攻撃が存在しない場合は、後続のセッションでMITM攻撃があることはできません。これはまさにSSHはそれをしない方法です。
Of course, the security rests on the assumption that the MiTM did not attack in the first session. That assumption seems to work most of the time in the SSH world. The user would have to be warned the first time a public key is encountered, just as in SSH. If possible, the SAS should be checked before the user consents to caching the new public key. If the SAS matches in the first session, there is no MiTM, and it's safe to cache the public key. If no SAS comparison is possible, it's up to the user, or up to the application, to decide whether to take a leap of faith and proceed. That's how SSH works most of the time, because SSH users don't have the chance to verbally compare an SAS with anyone.
もちろん、セキュリティはMITMは、最初のセッションで攻撃しなかったことを前提にかかっています。この仮定は、SSHの世界ではほとんどの時間を動作するようです。ユーザーは単にSSHのように、公開鍵が見つかった最初の時間を警告しなければなりません。可能であれば、SASは、新しい公開鍵をキャッシュするためにユーザーが同意する前にチェックする必要があります。 SASは、最初のセッションでは一致している場合、そこにはMITMされていない、そしてそれは、公開鍵をキャッシュしても安全です。何SASの比較が可能でない場合、それは信仰の飛躍を取ると、続行するかどうかを決定するために、ユーザーまで、またはアプリケーション次第です。 SSHのユーザーが口頭で誰とでSASを比較する機会を持っていないので、それは、SSHは、ほとんどの時間をどのように動作するかです。
For a phone that is SIP-registered to a PBX, it may be provisioned with the public key of the PBX, using a trusted automated provisioning process. Even without a PKI, the phone knows that the public key is the correct one, since it was provisioned into the phone by a trusted provisioning mechanism. This makes it easy for the phone to access several automated services commonly offered by a PBX, such as voice mail or a conference bridge, where there is no human at the PBX to do a verbal SAS compare. The same provisioning may be used to preload the pbxsecret into the phone, which is discussed in Section 7.3.1.
PBXにSIP登録されている電話の場合は、それが信頼された自動プロビジョニング・プロセスを使用して、PBXの公開鍵をプロビジョニングすることができます。でもPKIなしで、電話はそれが信頼できるプロビジョニングメカニズムによって電話にプロビジョニングされたため、公開鍵は、正しいものであることを知っています。これにより、簡単に電話が、音声メールまたは比較口頭でSASを実行するPBXに何の人間が存在しない会議ブリッジ、などの一般的にPBXが提供するいくつかの自動化されたサービスにアクセスできるようになります。同じプロビジョニングは、セクション7.3.1に記載されている電話、にpbxsecretをプリロードするために使用することができます。
ZRTP is designed to use end-to-end encryption. The two parties' verbal comparison of the short authentication string (SAS) depends on this assumption. But in some PBX environments, such as Asterisk, there are usage scenarios that have the PBX acting as a trusted MiTM, which means there are two back-to-back ZRTP connections with separate session keys and separate SASs.
ZRTPは、エンドツーエンドの暗号化を使用するように設計されています。短い認証文字列（SAS）の2人の当事者の口頭比較はこの仮定に依存します。しかし、アスタリスクなど、いくつかのPBX環境で、個別のセッション鍵と別々のSASとの2つのバックツーバックZRTP接続があることを意味信頼できるMITM、として機能PBXを持っている使用シナリオがあります。
For example, imagine that Bob has a ZRTP-enabled VoIP phone that has been registered with his company's PBX, so that it is regarded as an extension of the PBX. Alice, whose phone is not associated with the PBX, might dial the PBX from the outside, and a ZRTP connection is negotiated between her phone and the PBX. She then selects Bob's extension from the company directory in the PBX. The PBX makes a call to Bob's phone (which might be offsite, many miles away from the PBX through the Internet) and a separate ZRTP connection is negotiated between the PBX and Bob's phone. The two ZRTP sessions have different session keys and different SASs, which would render the SAS useless for verbal comparison between Alice and Bob. They might even mistakenly believe that a wiretapper is present because of the SAS mismatch, causing undue alarm.
例えば、ボブはそれはPBXの延長とみなされているように、彼の会社のPBXに登録されているZRTP対応のVoIP電話を持っていることを想像してみてください。その電話PBXに関連付けられていないアリスは、外部からのPBXをダイヤルする可能性がある、とZRTP接続は彼女の電話とPBXとの間で交渉されます。彼女はその後、PBXの会社ディレクトリからBobの拡張子を選択します。 PBXは、ボブの携帯電話に呼び出しを行う（インターネット経由でオフサイト、多くのマイル離れたPBXからであるかもしれない）と別のZRTP接続はPBXとボブの携帯電話との間で交渉されます。 2つのZRTPセッションは、異なるセッション鍵とアリスとボブの間で口頭での比較のためにSASは無用だろう違うのSASを、持っています。彼らは誤って盗聴者が不当なアラームを引き起こすため、SASのミスマッチの存在であると信じているかもしれません。
ZRTP has a mechanism for solving this problem by having the PBX relay the Alice/PBX SAS to Bob, sending it through to Bob in a special SASrelay message as defined in Section 5.13, which is sent after the PBX/Bob ZRTP negotiation is complete, after the Confirm messages. Only the PBX, acting as a special trusted MiTM (trusted by the recipient of the SASrelay message), will relay the SAS. The SASrelay message protects the relayed SAS from tampering via an included MAC, similar to how the Confirm message is protected. Bob's ZRTP-enabled phone accepts the relayed SAS for rendering only because Bob's phone had previously been configured to trust the PBX. This special trusted relationship with the PBX can be established through a special security enrollment procedure (Section 7.3.1). After that enrollment procedure, the PBX is treated by Bob as a special trusted MiTM. This results in Alice's SAS being rendered to Bob, so that Alice and Bob may verbally compare them and thus prevent a MiTM attack by any other untrusted MiTM.
ZRTPは、PBXは、PBX /ボブZRTPネゴシエーションが完了した後に送信され、セクション5.13、で定義されるように特別SASrelayメッセージにボブにそれを介して送信し、ボブにアリス/ PBX SASを中継有することによって、この問題を解決するための機構を有しています確認メッセージの後に。唯一のPBXは、（SASrelayメッセージの受信者に信頼される）特別な信頼できるMITMとして機能する、SASを中継します。 SASrelayメッセージは、確認メッセージが保護されている方法と同様に、含まれるMAC介し改ざんから中継されたSASを保護します。ボブのZRTP対応携帯電話ボブの電話が以前にPBXを信頼するように設定されていたという理由だけでレンダリングするための中継されたSASを受け入れます。 PBXとのこの特別の信頼関係は特別なセキュリティ登録手順（7.3.1）を介して確立することができます。その入学手続き後、PBXは、特別な、信頼できるMITMとしてボブによって処理されます。アリスとボブは口頭でそれらを比較するため、他の信頼できないMITMによってMITM攻撃を防ぐことができるようにこれは、アリスのSASがボブにレンダリングされることになります。
A real "bad-guy" MiTM cannot exploit this protocol feature to mount a MiTM attack and relay Alice's SAS to Bob, because Bob has not previously carried out a special registration ritual with the bad guy. The relayed SAS would not be rendered by Bob's phone, because it did not come from a trusted PBX. The recognition of the special trust relationship is achieved with the prior establishment of a special shared secret between Bob and his PBX, which is called pbxsecret (defined in Section 7.3.1), also known as the trusted MiTM key.
ボブは以前に悪者との特別な登録の儀式を行っていなかったので、本当の「悪い男」MITMは、MITM攻撃を仕掛けるとボブにアリスのSASを中継するために、このプロトコルの機能を利用することはできません。それは、信頼できるPBXから来なかったので、中継されたSASは、ボブの電話によってレンダリングされません。特別な信頼関係の認識はまた、信頼できるMITMキーとして知られている（第7.3.1項で定義される）pbxsecretと呼ばれるボブと彼のPBX間の特別な共有秘密、の前に設立、で達成されます。
The trusted MiTM key can be stored in a special cache at the time of the initial enrollment (which is carried out only once for Bob's phone), and Bob's phone associates this key with the ZID of the PBX, while the PBX associates it with the ZID of Bob's phone. After the enrollment has established and stored this trusted MiTM key, it can be detected during subsequent ZRTP session negotiations between the PBX and Bob's phone, because the PBX and the phone MUST pass the hash of the trusted MiTM key in the DH message. It is then used as part of the key agreement to calculate s0.
PBXはに関連付けながら、信頼MITMキーは、PBXのZIDでこのキーを（ボブの携帯電話のために一度だけ行われる）最初の登録時に特別なキャッシュに格納され、ボブの携帯電話の仲間することができますボブの携帯電話のZID。登録が設立され、この信頼さMITMキーを格納した後、PBXと電話がDHメッセージに信頼さMITMキーのハッシュを渡す必要がありますので、それは、PBXとボブの携帯電話との間に、後続のZRTPセッションネゴシエーション中に検出することができます。次に、それをS0を計算するための鍵合意の一部として使用されます。
The PBX can determine whether it is trusted by the ZRTP user agent of a phone. The presence of a shared trusted MiTM key in the key negotiation sequence indicates that the phone has been enrolled with this PBX and therefore trusts it to act as a trusted MiTM. During a key agreement with two other ZRTP endpoints, the PBX may have a shared trusted MiTM key with both endpoints, only one endpoint, or neither endpoint. If the PBX has a shared trusted MiTM key with neither endpoint, the PBX MUST NOT relay the SAS. If the PBX has a shared trusted MiTM key with only one endpoint, the PBX MUST relay the SAS from one party to the other by sending an SASrelay message to the endpoint with which it shares a trusted MiTM key. If the PBX has a (separate) shared trusted MiTM key with each of the endpoints, the PBX MUST relay the SAS to only one endpoint, not both endpoints.
PBXは、それが携帯電話のZRTPのユーザエージェントによって信頼されているかどうかを判断することができます。キーネゴシエーションシーケンス内の共有、信頼MITMキーの存在は、携帯電話は、このPBXに登録されていることを示し、したがって、信頼できるMITMとして機能することを信頼します。他の二つのZRTPのエンドポイントと鍵合意の際、PBXは、一つだけのエンドポイント、またはどちらのエンドポイントを、両方のエンドポイントとの共有、信頼MITMキーを有することができます。 PBXはどちらのエンドポイントとの共有、信頼MITMキーを持っている場合、PBXは、SASを中継してはなりません。 PBXが唯一のエンドポイントを1つの共有、信頼MITMキーを持っている場合、PBXは、信頼できるMITMキーを共有するエンドポイントにSASrelayメッセージを送信することによって、他の一方の当事者からSASをリレーしなければなりません。 PBXは、エンドポイントのそれぞれと（別）共有信頼MITMキーを持っている場合、PBXは、一方のエンドポイントではなく、両方のエンドポイントにSASを中継しなければなりません。
Note: In the case of a PBX sharing trusted MiTM keys with both endpoints, it does not matter which endpoint receives the relayed SAS as long as only one endpoint receives it.
注：PBXの共有の場合は、両方のエンドポイントとのMITMキーを信頼し、限り唯一のエンドポイントがそれを受け取る中継されたSASを受信するエンドポイントは関係ありません。
The relayed SAS fields contain the SAS rendering type and the complete sashash. The receiver absolutely MUST NOT render the relayed SAS if it does not come from a specially trusted ZRTP endpoint. The security of the ZRTP protocol depends on not rendering a relayed SAS from an untrusted MiTM, because it may be relayed by a MiTM attacker. See the SASrelay message definition (Figure 16) for further details.
中継SASフィールドは、SASのレンダリングのタイプと完全sashashが含まれています。それは特別に信頼さZRTPエンドポイントから来ない場合は受信機は絶対に中継されたSASをレンダリングしてはなりません。それはMITM攻撃者によって中継することができるので、ZRTPプロトコルのセキュリティは、信頼できないMITMから中継されたSASをレンダリングしていないに依存します。詳細についてSASrelayメッセージ定義（図16）を参照してください。
To ensure that both Alice and Bob will use the same SAS rendering scheme after the keys are negotiated, the PBX also sends the SASrelay message to the unenrolled party (which does not regard this PBX as a trusted MiTM), conveying the SAS rendering scheme, but not the sashash, which it sets to zero. The unenrolled party will ignore the relayed SAS field, but will use the specified SAS rendering scheme.
キーがネゴシエートされた後、アリスとボブの両方が同じSASのレンダリング方式を使用することを保証するために、PBXはまた、SASのレンダリング方式を伝える、（信頼できるMITMとしてこのPBXを考えていない）未登録者にSASrelayメッセージを送信し、しかし、それはゼロに設定していないsashash、。未登録の当事者は、中継されたSASのフィールドを無視しますが、指定されたSASのレンダリング方式を使用します。
It is possible to route a call through two ZRTP-enabled PBXs using this scheme. Assume Alice is a ZRTP endpoint who trusts her local PBX in Atlanta, and Bob is a ZRTP endpoint who trusts his local PBX in Biloxi. The call is routed from Alice to the Atlanta PBX to the Biloxi PBX to Bob. Atlanta would relay the Atlanta-Biloxi SAS to Alice because Alice is enrolled with Atlanta, and Biloxi would relay the Atlanta-Biloxi SAS to Bob because Bob is enrolled with Biloxi. The two PBXs are not assumed to be enrolled with each other in this example. Both Alice and Bob would view and verbally compare the same relayed SAS, the Atlanta-Biloxi SAS. No more than two trusted MiTM nodes can be traversed with this relaying scheme. This behavior is extended to two PBXs that are enrolled with each other, via this rule: In the case of a PBX sharing trusted MiTM keys with both endpoints (i.e., both enrolled with this PBX), one of which is another PBX (evidenced by the M-flag) and one of which is a non-PBX, the MiTM PBX must always relay the PBX-to-PBX SAS to the non-PBX endpoint.
これは、この方式を使用して2つのZRTP対応のPBXを通るルートの呼び出しをすることが可能です。アリスは、アトランタで彼女のローカルPBXを信頼し、そしてボブはビロクシーで彼の地元のPBXを信頼ZRTPエンドポイントであるZRTPエンドポイントであると仮定します。コールは、ボブにアリスからアトランタPBXへビロクシーPBXにルーティングされます。アリスは、アトランタに登録されているため、アトランタはアリスにアトランタ - ビロクシーSASを中継だろう、とボブはビロクシに登録されているため、ビロクシーはボブにアトランタ - ビロクシーSASを中継します。 2台のPBXは、この例では、相互に登録されると仮定されていません。アリスとボブの両方が表示し、口頭で同じ中継されたSAS、アトランタ - ビロクシーSASを比較します。いいえつ以上の信頼できるMITMノードは、この中継スキームで移動することはできません。この動作は、このルールを介して、相互に登録されている2台のPBXに拡張される：PBXの場合によって証明別のPBX（そのうちの1つは、両方のエンドポイント（すなわち、このPBXに登録両方）との信頼できるMITMキーを共有しますMフラグ）との一方が、MITM PBXは常に非PBXエンドポイントへのPBX対PBX SASを中継しなければならない非PBXです。
A ZRTP endpoint phone that trusts a PBX to act as a trusted MiTM is effectively delegating its own policy decisions of algorithm negotiation to the PBX.
信頼できるMITMとして動作するようにPBXを信頼ZRTPエンドポイントの電話が効果的にPBXにアルゴリズムの折衝の独自の政策決定を委任されます。
When a PBX is between two ZRTP endpoints and is terminating their media streams at the PBX, the PBX presents its own ZID to the two parties, eclipsing the ZIDs of the two parties from each other. For example, if several different calls are routed through such a PBX to several different ZRTP-enabled phones behind the PBX, only a single ZID is presented to the calling party in every case -- the ZID of the PBX itself.
PBXは、2つのZRTPエンドポイント間で、PBXにそのメディアストリームを終了したとき、PBXは、互いに両者のZIDsを食、両当事者に独自ZIDを提示します。 PBX自体のZID - いくつかの異なる呼び出しがPBXの背後にあるいくつかの異なるZRTP対応携帯電話に、このようなPBX経由でルーティングされている場合たとえば、単一のZIDは、すべての場合には、発呼者に提示されます。
The next section describes the initial enrollment procedure that establishes a special shared secret, a trusted MiTM key, between a PBX and a phone, so that the phone will learn to recognize the PBX as a trusted MiTM.
次のセクションでは、電話が信頼できるMITMとしてPBXを認識することを学ぶだろうように、PBXと電話機の間で、特別な共有秘密は、信頼できるMITMキーを設定する初期登録手順を説明します。
Both the PBX and the endpoint need to know when enrollment is taking place. One way of doing this is to set up an enrollment extension on the PBX that a newly configured endpoint would call and establish a ZRTP session. The PBX would then play audio media that offers the user an opportunity to configure his phone to trust this PBX as a trusted MiTM. The PBX calculates and stores the trusted MiTM shared secret in its cache and associates it with this phone, indexed by the phone's ZID. The trusted MiTM PBX shared secret is derived from ZRTPSess via the ZRTP key derivation function (Section 4.5.1) in this manner:
PBXとエンドポイントの両方が登録が行われている際に知っておく必要があります。これを行う1つの方法は、新しく設定されたエンドポイントが呼び出すとZRTPセッションを確立するPBXに登録拡張子を設定することです。 PBXは、ユーザーに信頼さMITMとしてこのPBXを信頼するように彼の電話を設定する機会を提供していますオーディオメディアを再生します。 PBXは、信頼できるMITMがキャッシュに秘密を共有し、携帯電話のZIDによってインデックス付け、この携帯電話に関連付ける計算し、格納します。信頼MITM PBX共有秘密は、このようにZRTP鍵導出関数（4.5.1項）を介しZRTPSessから誘導されます。
pbxsecret = KDF(ZRTPSess, "Trusted MiTM key", (ZIDi || ZIDr), 256)
pbxsecret = KDF（ZRTPSess、 "信頼MITMキー"、（ZIDi || ZIDr）、256）
The pbxsecret is calculated for the whole ZRTP session, not for each stream within a session, thus the KDF Context field in this case does not include any stream-specific nonce material.
pbxsecretは、このように、この場合のKDFコンテキストフィールドは、任意のストリーム固有のノンス物質を含まない、セッション内全体ZRTPセッションのではなく、各ストリームについて計算されます。
The PBX signals the enrollment process by setting the PBX Enrollment flag (E) in the Confirm message (Figure 10). This flag is used to trigger the ZRTP endpoint's user interface to prompt the user to see if it wants to trust this PBX and calculate and store the pbxsecret in the cache. If the user decides to respond by activating the appropriate user interface element (a menu item, checkbox, or button), his ZRTP user agent calculates pbxsecret using the same formula, and saves it in a special cache entry associated with this PBX.
PBXは、確認メッセージ（図10）でPBX登録フラグ（E）を設定することにより登録プロセスに信号を送ります。このフラグは、それがこのPBXを信頼し、キャッシュ内のpbxsecretを計算して保存したいかどうかを確認するために、ユーザーに促すためにZRTPエンドポイントのユーザー・インタフェースを起動するために使用されます。ユーザーが適切なユーザーインターフェイス要素（メニュー項目、チェックボックス、またはボタン）を活性化することによって応答することを決定した場合、彼のZRTPユーザエージェントは、同じ式を使用してpbxsecret計算し、このPBXに関連付けられている特殊なキャッシュエントリに保存します。
During a PBX enrollment, the GoClear features are disabled. If the (E) flag is set by the PBX, the PBX MUST NOT set the Allow Clear (A) flag. Thus, (E) implies not (A). If a received Confirm message has the (E) flag set, the (A) flag MUST be disregarded and treated as false.
PBXの登録時には、GoClear機能が無効になっています。 （E）フラグがPBXで設定されている場合、PBXはクリアを許可（A）フラグを設定してはいけません。このように、（E）は意味しない（A）。受信確認メッセージは、（E）フラグが設定されている場合は、（A）フラグを無視し、偽として扱わなければなりません。
If the user elects not to enroll, perhaps because he dialed a wrong number or does not yet feel comfortable with this PBX, he can simply hang up and not save the pbxsecret in his cache. The PBX will have it saved in the PBX cache, but that will do no harm. The SASrelay scheme does not depend on the PBX trusting the phone. It only depends on the phone trusting the PBX. It is the phone (the user) who is at risk if the PBX abuses its MiTM privileges.
ユーザーがいない、彼は間違った番号をダイヤルしたか、まだこのPBXと快適に感じていないかもしれないので、登録することを選択した場合、彼は単純にハングアップし、彼のキャッシュにpbxsecretを保存することはできません。 PBXは、PBXのキャッシュに保存されていますが、それは何の害を行いません。 SASrelay方式は、携帯電話を信頼PBXに依存しません。それだけでPBXを信頼携帯電話に依存します。それはMITM権限PBX侵害の場合危険にさらされている携帯電話（利用者）です。
An endpoint MUST NOT store the pbxsecret in the cache without explicit user authorization.
エンドポイントは、明示的なユーザー認証なしでキャッシュにpbxsecretを格納してはなりません。
After this enrollment process, the PBX and the ZRTP-enabled phone both share a secret that enables the phone to recognize the PBX as a trusted MiTM in future calls. This means that when a future call from an outside ZRTP-enabled caller is relayed through the PBX to this phone, the phone will render a relayed SAS from the PBX. If the SASrelay message comes from a MiTM that does not know the pbxsecret, the phone treats it as a bad-guy MiTM, and refuses to render the relayed SAS. Regardless of which party initiates any future phone calls through the PBX, the enrolled phone or the outside phone, the PBX will relay the SAS to the enrolled phone.
この登録プロセスの後、PBXとZRTP対応携帯電話は、今後の呼び出しに信頼できるMITMとしてPBXを認識するために電話を可能に秘密を共有する両方。これは、外ZRTP対応の発信者から将来のコールがこの電話にPBX経由で中継されたときに、電話がPBXから中継されたSASをレンダリングすることを意味します。 SASrelayメッセージがpbxsecretを知らないMITMから来た場合は、電話の悪いやつMITMとして扱い、それを、とは中継されたSASをレンダリングすることを拒否します。かかわらず、PBX、登録電話または外部の電話を通じて、将来の携帯電話の通話を開始する当事者の、PBXは、登録電話にSASを中継します。
This enrollment procedure is designed primarily for phones that are already associated with the PBX -- enterprise phones that are "behind" the PBX. It is not intended for the countless outside phones that are not registered to this PBX's SIP server. It should be regarded as part of the installation and provisioning process for a new phone in the organization.
PBX「後ろに」ある企業の携帯電話 - この登録手順は、主に、既にPBXに関連付けられている携帯電話のために設計されています。それは、このPBXのSIPサーバに登録されていない無数の外で携帯電話向けではありません。これは、組織内の新しい携帯電話のインストールとプロビジョニングプロセスの一部としてみなされるべきです。
There are more streamlined methods to configure ZRTP user agents to trust a PBX. In large scale deployments, the pbxsecret may be configured into the phone by an automated provisioning process, which may be less burdensome for the users and less error prone. This specification does not require a manual enrollment process. Any process that results in a pbxsecret to be computed and shared between the PBX and the phone will suffice, as long as the user is made aware that this puts the PBX in a position to wiretap the calls.
PBXを信頼するZRTPのユーザーエージェントを設定するには、より合理的な方法があります。大規模な展開では、pbxsecretは、ユーザーが少ないエラープローンにはあまり負担することができる自動化されたプロビジョニング・プロセスによって携帯電話に構成されてもよいです。この仕様は、手動登録プロセスを必要としません。 pbxsecretもたらす任意のプロセスが計算されていれば、ユーザが認識されているように、これはコールを盗聴する位置にPBXを置くことは、十分でPBXと電話との間で共有されます。
It is recommended that a ZRTP client not proceed with the PBX enrollment procedure without evidence that a MiTM attack is not taking place during the enrollment session. It would be especially damaging if a MiTM tricks the client into enrolling with the wrong
ZRTPクライアントはMITM攻撃は、登録セッション中に行われていないことを示す証拠なしPBX登録手続きを進めないことをお勧めします。 MITMトリック場合、それは間違って登録にクライアント特に有害だろう
PBX. That would enable the malevolent MiTM to wiretap all future calls without arousing suspicion, because he would appear to be trusted.
PBX。彼は、信頼できると思われるので、それには、疑いを喚起することなく、将来のすべての通話を盗聴するために邪悪なMITMを可能にします。
This section discusses how ZRTP, SIP, and SDP work together.
このセクションではZRTP、SIP、およびSDPはどのように連携するかについて説明します。
Note that ZRTP may be implemented without coupling with the SIP signaling. For example, ZRTP can be implemented as a "bump in the wire" or as a "bump in the stack" in which RTP sent by the SIP User Agent (UA) is converted to ZRTP. In these cases, the SIP UA will have no knowledge of ZRTP. As a result, the signaling path discovery mechanisms introduced in this section should not be definitive -- they are a hint. Despite the absence of an indication of ZRTP support in an offer or answer, a ZRTP endpoint SHOULD still send Hello messages.
ZRTPは、SIPシグナリングとのカップリングなしで実現されてもよいことに留意されたいです。例えば、ZRTPは「ワイヤでバンプ」として、またはRTPは、SIPユーザエージェント（UA）によって送られた「スタックにバンプ」として実現することができるZRTPに変換されます。これらのケースでは、SIP UAはZRTPの知識がないだろう。その結果、このセクションで紹介シグナリングパスディスカバリメカニズムは、決定的ではありません - 彼らはヒントです。申し出または回答でZRTPサポートの表示の有無にかかわらず、ZRTPエンドポイントは、まだHelloメッセージを送るべきです。
ZRTP endpoints that have control over the signaling path include a ZRTP SDP attributes in their SDP offers and answers. The ZRTP attribute, a=zrtp-hash, is used to indicate support for ZRTP and to convey a hash of the Hello message. The hash is computed according to Section 8.1.
シグナリングパスを管理しているZRTPエンドポイントがZRTP SDPは、そのSDPオファーとアンサーの属性があります。 ZRTP属性、= ZRTP-ハッシュは、ZRTPのサポートを示すために、そしてHelloメッセージのハッシュを伝えるために使用されます。ハッシュはセクション8.1に従って計算されます。
Aside from the advantages described in Section 8.1, there are a number of potential uses for this attribute. It is useful when signaling elements would like to know when ZRTP may be utilized by endpoints. It is also useful if endpoints support multiple methods of SRTP key management. The ZRTP attribute can be used to ensure that these key management approaches work together instead of against each other. For example, if only one endpoint supports ZRTP, but both support another method to key SRTP, then the other method will be used instead. When used in parallel, an SRTP secret carried in an a=keymgt [RFC4567] or a=crypto [RFC4568] attribute can be used as a shared secret for the srtps computation defined in Section 8.2. The ZRTP attribute is also used to signal to an intermediary ZRTP device not to act as a ZRTP endpoint, as discussed in Section 10.
別に8.1節に記載の利点から、この属性の潜在的な用途の数があります。シグナリング要素はZRTPエンドポイントによって利用することができる場合に知りたいときに有用です。エンドポイントがSRTP鍵管理の複数の方法をサポートする場合にも便利です。 ZRTP属性は、これらの鍵管理アプローチはお互いに一緒に働く代わりのことを確実にするために使用することができます。例えば、1つしかない場合、エンドポイントはZRTPをサポートしていますが、両方のキーSRTPに別の方法をサポートし、その後、他の方法が代わりに使用されます。並行して使用される場合、SRTPの秘密は、A = keymgt [RFC4567]または=暗号[RFC4568]で運ば属性は、セクション8.2で定義されたsrtps計算のための共有秘密として使用することができます。 ZRTP属性はまた、セクション10で説明したように、ZRTPエンドポイントとして機能しない中間ZRTP装置に信号を送るために使用されます。
The a=zrtp-hash attribute can only be included in the SDP at the media level since Hello messages sent in different media streams will have unique hashes.
異なるメディアストリームで送信されたHelloメッセージは、ユニークなハッシュを持つことになりますので、A = ZRTP-ハッシュ属性は、メディアレベルでのSDPに含めることができます。
The ABNF for the ZRTP attribute is as follows:
次のようにZRTP属性のABNFは、次のとおりです。
zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
ZRTP属性= "A = ZRTP-ハッシュ：" ZRTP-バージョンZRTPハッシュ値
zrtp-version = token
ZRTPバージョン=トークン
zrtp-hash-value = 1*(HEXDIG)
ZRTPハッシュ値= 1 *（HEXDIG）
Here's an example of the ZRTP attribute in an initial SDP offer or answer used at the media level, using the <allOneLine> convention defined in RFC 4475, Section 2.1 [RFC4475]:
ここではRFC 4475で定義された<allOneLine>大会、セクション2.1 [RFC4475]を使用して、メディアのレベルで使用される初期SDPのオファーや解答でZRTP属性の例です：
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=audio 3456 RTP/AVP 97 33 a=rtpmap:97 iLBC/8000 a=rtpmap:33 no-op/8000 <allOneLine> a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2 df881ae642c371ba46df </allOneLine>
V = 0 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = C = IN IP4 client.biloxi.example.com T = 0、M =オーディオ3456 RTP / AVP 97 33 = rtpmap：97 iLBCの/ 8000 = rtpmap：33無OP / 8000 <allOneLine> A = ZRTPハッシュ：1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2 df881ae642c371ba46df </ allOneLine>
A mechanism for carrying this same zrtp-hash information in the Jingle signaling protocol is defined in [XEP-0262].
ジングルシグナリングプロトコルで同じZRTPハッシュ情報を搬送するための機構は、[XEP-0262]で定義されています。
It should be safe to send ZRTP messages even when there is no evidence in the signaling that the other party supports it, because ZRTP has been designed to be clearly different from RTP, having a similar structure to STUN packets sent during an ICE exchange.
ZRTPは、ICEの交換中に送信されたパケットをSTUNと類似の構造を有する、RTPとは明らかに異なるように設計されていますので、相手がそれをサポートしていることをシグナリングにおける証拠がない場合でも、ZRTPメッセージを送信するために安全でなければなりません。
Tying the media stream to the signaling channel can help prevent a third party from inserting false media packets. If the signaling layer contains information that ties it to the media stream, false media streams can be rejected.
シグナリングチャネルにメディアストリームを結ぶことは誤ったメディアパケットを挿入するから、第三者を防ぐことができます。シグナリング層がメディアストリームにそれを結びつける情報が含まれている場合は、偽のメディアストリームを拒絶することができます。
To accomplish this, the entire Hello message (Figure 3) is hashed, using the hash algorithm defined in Section 5.1.2.2. The ZRTP packet framing from Figure 2 is not included in the hash. The resulting hash image is made available without truncation to the signaling layer, where it is transmitted as a hexadecimal value in the SIP channel using the SDP attribute a=zrtp-hash, defined in this specification. Assuming Section 5.1.2.2 defines a 256-bit hash length, the a=zrtp-hash field in the SDP attribute carries 64 hexadecimal digits. Each media stream (audio or video) will have a separate Hello message, and thus will require a separate a=zrtp-hash in an SDP attribute. The recipient of the SIP/SDP message can then use this hash image to detect and reject false Hello messages in the media channel, as well as identify which media stream is associated with this SIP call. Each Hello message hashes uniquely, because it contains the H3 field derived from a random nonce, defined in Section 9.
これを達成するために、全体のHelloメッセージ（図3）は、セクション5.1.2.2で定義されたハッシュアルゴリズムを使用して、ハッシュされます。図2からZRTPパケットフレーミングはハッシュに含まれていません。結果として得られるハッシュ・イメージは、それがSDPは、本明細書で定義され= ZRTPハッシュを、属性を使用してSIPチャネルに16進数の値として送信されるシグナリング層に切り捨てずに利用可能となります。セクション5.1.2.2は、256ビットのハッシュ長を定義すると仮定すると、SDP属性でA = ZRTPハッシュフィールドは64桁の16進数を運びます。各メディアストリーム（オーディオまたはビデオ）は、独立したHelloメッセージを持つことになりますので、SDP属性で別のA = ZRTP-ハッシュが必要になります。 SIP / SDPメッセージの受信者は、その後、検出および拒否ハロー偽メッセージをメディアチャネルで、ならびにこのSIP呼に関連付けられているメディアストリームを識別するために、このハッシュ画像を使用することができます。それはセクション9で定義されたランダムなノンス由来H3のフィールドが含まれているので、各Helloメッセージは、一意ハッシュ。
The Hello Hash as an SDP attribute is not a REQUIRED feature, because some ZRTP endpoints do not have the ability to add SDP attributes to the signaling. For example, if ZRTP is implemented in a hardware bump-in-the-wire device, it might only have the ability to modify the media packets, not the SIP packets, especially if the SIP packets are integrity protected and thus cannot be modified on the wire. If the SDP has no hash image of the ZRTP Hello message, the recipient's ZRTP user agent cannot check it, and thus will not be able to reject Hello messages based on this hash.
いくつかのZRTPエンドポイントは、SDPは、シグナリングに属性を追加する機能を持っていないので、SDP属性としてこんにちはハッシュは、REQUIRED機能ではありません。 ZRTPは、ハードウェアバンプ・イン・ワイヤ装置に実装されている場合、例えば、それだけSIPパケットが完全性が保護され、従ってに変更することができない場合は特に、メディアパケットを修正する能力ではなく、SIPパケットがあるかもしれませんワイヤー。 SDPはZRTP Helloメッセージのないハッシュイメージを持っていない場合は、受信者のZRTPのユーザエージェントは、それをチェックすることはできませんので、このハッシュに基づいて、Helloメッセージを拒否することはできません。
After the Hello Hash is used to properly identify the ZRTP Hello message as belonging to this particular SIP call, the rest of the ZRTP message sequence is protected from false packet injection by other protection mechanisms, such as the hash chaining mechanism defined in Section 9.
ハローハッシュが正しく、この特定のSIPコールに属するものとしてZRTP Helloメッセージを識別するために使用された後、ZRTPメッセージシーケンスの残りの部分は、セクション9で定義されたハッシュチェーン機構として、他の保護機構により偽パケット注入から保護されます。
An attacker who controls only the signaling layer, such as an uncooperative VoIP service provider, may be able to deny service by corrupting the hash of the Hello message in the SDP attribute, which would force ZRTP to reject perfectly good Hello messages. If there is reason to believe this is happening, the ZRTP endpoint MAY allow Hello messages to be accepted that do not match the hash image in the SDP attribute.
そのような非協力的なVoIPサービスプロバイダとしてのみシグナリング層を、制御し、攻撃者は、完璧なHelloメッセージを拒否するようZRTPを強制するSDP属性にHelloメッセージのハッシュを破壊することにより、サービスを拒否することができるかもしれません。これが起こっていると信じる理由がある場合は、ZRTPエンドポイントは、HelloメッセージはSDP属性にハッシュ画像と一致しないことが受け入れできるようにすることができます。
Even in the absence of SIP integrity protection, the inclusion of the a=zrtp-hash SDP attribute, when coupled with the hash chaining mechanism defined in Section 9, meets the R-ASSOC requirement in the Media Security Requirements [RFC5479], which requires:
SIP完全性保護の欠如、A = ZRTPハッシュSDP属性を含める、セクション9で定義されたハッシュチェーン機構に結合され、中に必要とする、メディアセキュリティ要件[RFC5479]におけるR-ASSOC要件を満たします：
...a mechanism for associating key management messages with both the signaling traffic that initiated the session and with protected media traffic. It is useful to associate key management messages with call signaling messages, as this allows the SDP offerer to avoid performing CPU-consuming operations (e.g., Diffie-Hellman or public key operations) with attackers that have not seen the signaling messages.
セッションを開始し、保護されたメディアトラフィックとシグナリングトラフィックの両方で鍵管理メッセージを関連付けるための...メカニズム。なお、これは、SDPオファーは、CPUを消費する操作を実行回避することを可能にするように、コールシグナリングメッセージと鍵管理メッセージを関連付けることが有用である（例えば、ディフィー・ヘルマン鍵または公開鍵操作）シグナリングメッセージを見ていない攻撃者です。
The a=zrtp-hash SDP attribute becomes especially useful if the SDP is integrity-protected end-to-end by SIP Identity [RFC4474] or better still, Dan Wing's SIP Identity using Media Path [SIP-IDENTITY]. This leads to an ability to stop MiTM attacks independent of ZRTP's SAS mechanism, as explained in Section 8.1.1.
SDPは、まだ完全性保護されたエンドツーエンドのSIPアイデンティティ[RFC4474]以上であると、A = ZRTPハッシュSDP属性は、メディアパス[SIP-IDENTITY]を使用して、ダン・ウィングのSIPアイデンティティ特に便利になります。これは、8.1.1項で説明したようにMITMは、ZRTPのSAS機構の独立した攻撃を停止する能力につながります。
8.1.1. Integrity-Protected Signaling Enables Integrity-Protected DH Exchange
8.1.1. 整合性が保護シグナリングは、整合性が保護DH交換を可能に
If and only if the signaling path and the SDP is protected by some form of end-to-end integrity protection, such as one of the abovementioned mechanisms, so that it can guarantee delivery of the a=zrtp-hash attribute without any tampering by a third party, and if there is good reason to trust the signaling layer to protect the interests of the end user, it is possible to authenticate the key exchange and prevent a MiTM attack. This can be done without requiring the users to verbally compare the SAS, by using the hash chaining mechanism defined in Section 9 to provide a series of MAC keys that protect the entire ZRTP key exchange. Thus, an end-to-end integrity-protected signaling layer automatically enables an integrity-protected Diffie-Hellman exchange in ZRTP, which in turn means immunity from a MiTM attack. Here's how it works.
それはいずれかによって改ざんすることなく、A = ZRTPハッシュ属性の配信を保証することができるようにシグナリングパスとSDPは、例えば、上記の機構の一つとして、エンドツーエンドの完全性保護の何らかの形で保護されている場合にのみサードパーティ、およびエンドユーザーの利益を保護するために、シグナリング層を信頼する十分な理由がある場合、鍵交換を認証し、MITM攻撃を防止することが可能です。これは口頭全体ZRTP鍵交換を保護するMACキーのシリーズを提供するために、セクション9で定義されたハッシュチェーン機構を使用して、SASを比較するためにユーザを必要とせずに行うことができます。したがって、エンドツーエンドの完全性保護シグナリング層は自動的に順番にMITM攻撃から免疫を意味ZRTPにおける完全性保護のDiffie-Hellman交換を可能にします。ここでは、それがどのように動作するかです。
The integrity-protected SIP SDP contains a hash commitment to the entire Hello message. The Hello message contains H3, which provides a hash commitment for the rest of the hash chain H0-H2 (Section 9). The Hello message is protected by a 64-bit MAC, keyed by H2. The Commit message is protected by a 64-bit MAC, keyed by H1. The DHPart1 or DHPart2 messages are protected by a 64-bit MAC, keyed by H0. The MAC protecting the Confirm messages is computed by a different MAC key derived from the resulting key agreement. Each message's MAC is checked when the MAC key is received in the next message. If a bad MAC is discovered, it MUST be treated as a security exception indicating a MiTM attack, perhaps by logging or alerting the user, and MUST NOT be treated as a random error. Random errors are already discovered and quietly rejected by bad CRCs (Figure 2).
整合性が保護SIP SDPは、全体のHelloメッセージにハッシュコミットメントが含まれています。 Helloメッセージは、ハッシュチェーンH0-H2（第9）の残りのハッシュコミットメントを提供H3を含んでいます。 Helloメッセージは、H2をキー64ビットMACによって保護されています。コミットメッセージは、H1をキー64ビットMACによって保護されています。 DHPart1又はDHPart2メッセージはH0をキー64ビットMACによって保護されています。確認メッセージを保護するMACは、得られた鍵合意に由来する異なるMAC鍵によって計算されます。 MACキーは、次のメッセージで受信されたときに各メッセージのMACがチェックされます。悪いMACが発見された場合、それはおそらく、ログインするか、ユーザに警告することにより、MITM攻撃を示すセキュリティ例外として扱わなければならない、とランダムエラーとして扱われてはなりません。ランダム誤差は、すでに発見され、静かに悪いのCRC（図2）によって拒否されています。
The Hello message must be assembled before any hash algorithms are negotiated, so an implicit predetermined hash algorithm and MAC algorithm (both defined in Section 5.1.2.2) must be used. All of the aforementioned MACs keyed by the hashes in the aforementioned hash chain MUST be computed with the MAC algorithm defined in Section 5.1.2.2, with the MAC truncated to 64 bits.
任意のハッシュアルゴリズムがネゴシエートされる前に、Helloメッセージはそう暗黙所定のハッシュアルゴリズムとMACアルゴリズム（両方ともセクション5.1.2.2で定義される）を使用する必要があり、組み立てられなければなりません。 MACは、64ビットに切り捨てられると、前述のハッシュ・チェーン内のハッシュをキー前述MACの全ては、セクション5.1.2.2で定義されたMACアルゴリズムを用いて計算されなければなりません。
The Media Security Requirements [RFC5479] R-EXISTING requirement can be fully met by leveraging a certificate-backed PKI in the signaling layer to integrity protect the delivery of the a=zrtp-hash SDP attribute. This would thereby protect ZRTP against a MiTM attack, without requiring the user to check the SAS, without adding any explicit signatures or signature keys to the ZRTP key exchange and without any extra public key operations or extra packets.
メディアセキュリティ要件[RFC5479] R-既存の要件を完全にA = ZRTPハッシュSDP属性の配信を保護するインテグリティにシグナリング層内の証明書バックアップPKIを利用することによって満たすことができます。これによりZRTP鍵交換に明示的な署名又は署名キーを追加することなく、任意の余分な公開鍵操作または余分なパケットなしで、SASを確認するようにユーザに要求することなく、MITM攻撃に対してZRTPを保護します。
Without an end-to-end integrity-protection mechanism in the signaling layer to guarantee delivery of the a=zrtp-hash SDP attribute without modification by a third party, these MACs alone will not prevent a MiTM attack. In that case, ZRTP's built-in SAS mechanism will still have to be used to authenticate the key exchange. At the time of this writing, very few deployed VoIP clients offer a fully implemented SIP stack that provides end-to-end integrity protection for the delivery of SDP attributes. Also, end-to-end signaling integrity becomes more problematic if E.164 numbers [RFC3824] are used in SIP. Thus, real-world implementations of ZRTP endpoints will continue to depend on SAS authentication for quite some time. Even after there is widespread availability of SIP user agents that offer integrity protected delivery of SDP attributes, many users will still be faced with the fact that the signaling path may be controlled by institutions that do not have the best interests of the end user in mind. In those cases, SAS authentication will remain the gold standard for the prudent user.
第三者によって変更することなく、A = ZRTPハッシュSDP属性の配信を保証するために、シグナリング層内のエンド・ツー・エンドの完全性保護メカニズムがなければ、これらのMACだけではMITM攻撃を防ぐことはできません。その場合には、ZRTPのSAS内蔵のメカニズムは、まだ鍵交換を認証するために使用する必要があります。この記事の執筆時点では、非常に少数の展開のVoIPクライアントは、SDP属性の送達のためのエンドツーエンドの完全性保護を提供する完全実装SIPスタックを提供します。 E.164番号[RFC3824]はSIPで使用される場合にも、エンドツーエンドシグナリングの完全性がより問題となります。このように、ZRTPエンドポイントの実世界での実装はかなりの時間のためにSAS認証に依存していきます。 SDP属性の完全性を保護配信を提供するSIPユーザエージェントの広範な利用可能性があっても後に、多くのユーザーはまだシグナリングパスを念頭に置いて、エンドユーザの最善の利益を持っていない機関によって制御することができるという事実に直面することになります。これらのケースでは、SAS認証は慎重なユーザーのためのゴールドスタンダードのままになります。
Even without SIP integrity protection, the Media Security Requirements [RFC5479] R-ACT-ACT requirement can be met by ZRTP's SAS mechanism. Although ZRTP may benefit from an integrity-protected SIP layer, it is fortunate that ZRTP's self-contained MiTM defenses do not actually require an integrity-protected SIP layer. ZRTP can bypass the delays and problems that SIP integrity faces, such as E.164 number usage, and the complexity of building and maintaining a PKI.
でも、SIPの完全性保護せずに、メディアのセキュリティ要件[RFC5479] R-ACT-ACT要件はZRTPのSASメカニズムによって満たすことができます。 ZRTPは整合性が保護SIP層から利益を得ることができるが、ZRTPの自己完結型のMITMの防御は、実際に整合性が保護SIP層を必要としないということは幸運です。 ZRTPは、E.164番号の使用、および建物の複雑さとPKIを維持するような整合性が直面SIP遅延や問題を回避することができます。
In contrast, DTLS-SRTP [RFC5764] appears to depend heavily on end-to-end integrity protection in the SIP layer. Further, DTLS-SRTP must bear the additional cost of a signature calculation of its own, in addition to the signature calculation the SIP layer uses to achieve its integrity protection. ZRTP needs no signature calculation of its own to leverage the signature calculation carried out in the SIP layer.
これとは対照的に、DTLS、SRTP [RFC5764]はSIP層におけるエンドツーエンドの完全性保護に大きく依存するように見えます。さらに、DTLS-SRTPは、SIP層は、その完全性保護を実現するために使用する署名計算に加えて、独自のの署名計算の追加費用を負担しなければなりません。 ZRTPは、SIP層で行われる署名の計算を活用するためにそれ自身の署名の計算を必要としません。
The shared secret calculations defined in Section 4.3 make use of the SRTP secret (srtps), if it is provided by the signaling layer.
それは、シグナリング層によって提供されている場合、セクション4.3で定義された共有秘密計算は、SRTPの秘密（srtps）を利用します。
It is desirable for only one SRTP key negotiation protocol to be used, and that protocol should be ZRTP. But in the event the signaling layer negotiates its own SRTP master key and salt, using the SDP Security Descriptions (SDES [RFC4568]) or [RFC4567], it can be passed from the signaling to the ZRTP layer and mixed into ZRTP's own shared secret calculations, without compromising security by creating a dependency on the signaling for media encryption.
一つだけSRTP鍵ネゴシエーションプロトコルが使用されることが望ましく、そのプロトコルはZRTPでなければなりません。イベントでは、シグナリング層は、自身のSRTPマスターキーと塩、SDPセキュリティ記述（SDES [RFC4568]）を使用するか、[RFC4567]を交渉する。しかし、それは、シグナリングからZRTP層に渡され、ZRTP自身の共有秘密に混入することができますメディア暗号化のためのシグナル伝達に対する依存関係を作成することによって、セキュリティを損なうことなく、計算、。
ZRTP computes srtps from the SRTP master key and salt parameters provided by the signaling layer in this manner, truncating the result to 256 bits:
ZRTPは、256ビットの結果を切り捨て、このように、シグナリング層によって提供されるSRTPマスターキーと塩パラメータからsrtpsを計算します。
srtps = KDF(SRTP master key, "SRTP Secret", (ZIDi || ZIDr || SRTP master salt), 256)
srtps = KDF（SRTPマスターキー、 "SRTPの秘密"、（ZIDi || || ZIDr SRTPマスター塩）、256）
It is expected that the srtps parameter will be rarely computed or used in typical ZRTP endpoints, because it is likely and desirable that ZRTP will be the sole means of negotiating SRTP keys, needing no help from [RFC4568] or [RFC4567]. If srtps is computed, it will be stored in the auxiliary shared secret auxsecret, defined in Section 4.3 and used in Section 4.3.1.
それはそうとZRTPは、SRTP鍵を交渉[RFC4568]か[RFC4567]からの助けを必要としない唯一の手段となることが望ましいので、srtpsパラメータはめったに計算していないか、典型的なZRTPエンドポイントで使用されることが期待されます。 srtpsが計算されている場合は、4.3節で定義され、4.3.1項で使用される、補助共有秘密auxsecretに保存されます。
Codec selection is negotiated in the signaling layer. If the signaling layer determines that ZRTP is supported by both endpoints, this should provide guidance in codec selection to avoid variable bitrate (VBR) codecs that leak information.
コーデック選択は、シグナリング層で交渉されます。シグナリング層はZRTPが両方のエンドポイントによってサポートされていると判断した場合、これは、情報を漏洩可変ビットレート（VBR）コーデックを回避するために、コーデック選択のガイダンスを提供すべきです。
When voice is compressed with a VBR codec, the packet lengths vary depending on the types of sounds being compressed. This leaks a lot of information about the content even if the packets are encrypted, regardless of what encryption protocol is used [Wright1]. It is RECOMMENDED that VBR codecs be avoided in encrypted calls. It is not a problem if the codec adapts the bitrate to the available channel bandwidth. The vulnerable codecs are the ones that change their bitrate depending on the type of sound being compressed.
音声がVBRコーデックで圧縮されたとき、パケット長は、圧縮された音の種類に応じて異なります。これは関係なく、暗号化プロトコルは[Wright1]使用されているものの、パケットが暗号化されている場合でも、コンテンツに関する多くの情報をリークします。 VBRコーデックは暗号化された呼び出しで回避することが推奨されます。コーデックが利用可能なチャネル帯域幅にビットレートを適応させるかどうかは問題ではありません。脆弱なコーデックは圧縮されている音の種類に応じて、そのビットレートを変更するものです。
It also appears that voice activity detection (VAD) leaks information about the content of the conversation, but to a lesser extent than VBR. This effect can be mitigated by lengthening the VAD hangover time by a random amount between 1 and 2 seconds, if this is feasible in your application. Only short bursts of speech would benefit from lengthening the VAD hangover time.
また、音声アクティビティ検出（VAD）は、会話の内容に関する情報をリークすることが表示されますが、VBRよりも程度は低いです。これは、アプリケーションで実現可能である場合には、この効果は、1と2秒の間のランダムな量だけVAD二日酔い時間を長くすることによって緩和することができます。スピーチの唯一の短いバーストは、VADの二日酔い時間を長くするの恩恵を受けるだろう。
The security problems of VBR and VAD are addressed in detail by the guidelines in [VBR-AUDIO]. It is RECOMMENDED that ZRTP endpoints follow these guidelines.
VBRとVADのセキュリティ問題は[VBR-AUDIO]のガイドラインにより詳細に対処されています。 ZRTPエンドポイントは、これらのガイドラインに従うことをお勧めします。
An attacker who is not in the media path may attempt to inject false ZRTP protocol packets, possibly to effect a denial-of-service attack or to inject his own media stream into the call. VoIP, by its nature, invites various forms of denial-of-service attacks and requires protocol features to reject such attacks. While bogus SRTP packets may be easily rejected via the SRTP auth tag field, that can only be applied after a key agreement is completed. During the ZRTP key negotiation phase, other false packet rejection mechanisms are needed. One such mechanism is the use of the total_hash in the final shared secret calculation, but that can only detect false packets after performing the computationally expensive Diffie-Hellman calculation.
メディアパスではなく、攻撃者がサービス拒否攻撃を行うためにか、呼び出しに彼自身のメディアストリームを注入するために、おそらく、偽ZRTPプロトコルパケットを注入しようとすることができます。 VoIPは、その性質により、サービス拒否攻撃の様々な形態を招き、このような攻撃を拒否するプロトコル機能を必要とします。偽のSRTPパケットを簡単に鍵合意が完了した後にのみ適用することができSRTPの認証タグフィールドを介して拒否されることがありますが。 ZRTP鍵ネゴシエーションフェーズ中に、他の偽のパケット棄却メカニズムが必要とされています。そのような機構の1つは、最終的な共有秘密計算でtotal_hashの使用であるが、それは唯一の計算コストのDiffie-Hellman計算を実行した後、偽のパケットを検出することができます。
A lot of work has been done on the analysis of denial-of-service attacks, especially from attackers who are not in the media path. Such an attacker might inject false ZRTP packets to force a ZRTP endpoint to engage in an endless series of pointless and expensive DH calculations. To detect and reject false packets cheaply and rapidly as soon as they are received, ZRTP uses a one-way hash chain, which is a series of successive hash images. Before each session, the following values are computed:
作品の多くは、特にメディアパスに含まれていない攻撃者からの、サービス拒否攻撃の分析に行われています。このような攻撃は無意味で高価なDHの計算の無限のシリーズに従事しZRTPエンドポイントを強制的に偽ZRTPパケットを注入することがあります。すぐにそれらが受信されると、安価かつ迅速偽のパケットを検出すると拒否するには、ZRTPは、連続したハッシュ一連の画像である一方向ハッシュチェーンを使用しています。各セッションの前に、次の値が計算されます：
H0 = 256-bit random nonce (different for each party)
H0 = 256ビットのランダムなノンス（各当事者に異なります）
H1 = hash (H0)
H1 =ハッシュ（H0）
H2 = hash (H1)
H2 =ハッシュ（H1）
H3 = hash (H2)
H3 =ハッシュ（H2）
This one-way hash chain MUST use the hash algorithm defined in Section 5.1.2.2, truncated to 256 bits. Each 256-bit hash image is the preimage of the next, and the sequence of images is sent in reverse order in the ZRTP packet sequence. The hash image H3 is sent in the Hello message, H2 is sent in the Commit message, H1 is sent in the DHPart1 or DHPart2 messages, and H0 is sent in the Confirm1 or Confirm2 messages. The initial random H0 nonces that each party generates MUST be unpredictable to an attacker and unique within a ZRTP session, which thereby forces the derived hash images H1-H3 to also be unique and unpredictable.
この一方向ハッシュチェーンは、256ビットに切り捨てセクション5.1.2.2で定義されたハッシュアルゴリズムを使用しなければなりません。各256ビットのハッシュ画像は、次のプレイメージであり、画像のシーケンスをZRTPパケット列に逆の順序で送信されます。 H3がHelloメッセージで送信されたハッシュ画像は、H2は、H1はDHPart1又はDHPart2メッセージで送信されたコミットメッセージで送信され、H0はCONFIRM1又はConfirm2メッセージで送信されます。各当事者が生成する初期ランダムH0のナンスはそれによってユニークで予測不可能であることが導出されたハッシュ画像H1-H3を強制ZRTPセッション内で攻撃者と一意に予測不可能でなければなりません。
The recipient checks if the packet has the correct hash preimage, by hashing it and comparing the result with the hash image for the preceding packet. Packets that contain an incorrect hash preimage MUST NOT be used by the recipient, but they MAY be processed as security exceptions, perhaps by logging or alerting the user. As long as these bogus packets are not used, and correct packets are still being received, the protocol SHOULD be allowed to run to completion, thereby rendering ineffective this denial-of-service attack.
パケットはそれをハッシュし、前のパケットのハッシュ画像と結果を比較することによって、正しいハッシュプレイメージを持っている場合、受信者がチェックします。間違ったハッシュプレイメージが含まれているパケットは、受信者が使用してはいけませんが、彼らはおそらく、ログインするか、ユーザに警告することによって、セキュリティ例外として処理されてもよいです。これらの偽のパケットが使用されず、正しいパケットがまだ受信されている限り、プロトコルがそれによって無効このサービス拒否攻撃をレンダリング、完了まで実行を許可されるべきです。
Note that since H2 is sent in the Commit message, and the initiator does not receive a Commit message, the initiator computes the responder's missing H2 by hashing the responder's H1. An analogous interpolation is performed by both parties to handle the skipped DHPart1 and DHPart2 messages in Preshared (Section 3.1.2) or Multistream (Section 3.1.3) modes.
H2は、コミットメッセージで送信され、そしてイニシエータがコミットメッセージを受信しないので、イニシエータはレスポンダのH1をハッシュすることによってレスポンダの欠落H2を計算することに留意されたいです。類似の補間は事前共有（3.1.2）またはマルチストリーム（3.1.3）モードでスキップDHPart1とDHPart2メッセージを処理するために、両当事者によって行われます。
Because these hash images alone do not protect the rest of the contents of the packet they reside in, this scheme assumes the attacker cannot modify the packet contents from a legitimate party, which is a reasonable assumption for an attacker who is not in the media path. This covers an important range of denial-of-service attacks. For dealing with the remaining set of attacks that involve packet modification, other mechanisms are used, such as the total_hash in the final shared secret calculation, and the hash commitment in the Commit message.
一人でこれらのハッシュイメージはそれが存在するパケットの内容の残りの部分を保護していないので、この方式では、攻撃者がメディアパスではなく、攻撃者のための合理的な仮定である合法的な政党からのパケットの内容を変更することはできません想定しています。これは、サービス拒否攻撃の重要な範囲をカバーしています。パケット修飾を伴う攻撃の残りの組に対応するため、他のメカニズムは、最終的な共有秘密計算でtotal_hash、コミットメッセージ内のハッシュコミットメントとして、使用されています。
Hello messages injected by an attacker may be detected and rejected by the inclusion of a hash of the Hello message in the signaling, as described in Section 8. This mechanism requires that each Hello message be unique, and the inclusion of the H3 hash image meets that requirement.
セクション8で説明したようにハロー攻撃者によって注入メッセージは、この機構は、各Helloメッセージが一意であることが必要であり、H3ハッシュ画像の包含を満たし、シグナル伝達におけるHelloメッセージのハッシュを含めることによって検出され、拒否されてもよいですその要件。
If and only if an integrity-protected signaling channel is available, the MACs that are keyed by this hash chaining scheme can be used to authenticate the entire ZRTP key exchange, and thereby prevent a MiTM attack, without relying on the users verbally comparing the SAS. See Section 8.1.1 for details.
および完全性保護シグナリングチャネルが利用可能である場合にのみ場合、スキーム連鎖このハッシュをキーとしているMACは口頭SASを比較ユーザーに頼ることなく、全体ZRTP鍵交換を認証し、それによってMITM攻撃を防止するために使用することができます。詳細については、セクション8.1.1を参照してください。
Some ZRTP user agents allow the user to manually switch to clear mode (via the GoClear message) in the middle of a secure call, and then later initiate secure mode again. Many consumer client products will omit this feature, but those that allow it may return to secure mode again in the same media stream. Although the same chain of hash images will be reused and thus rendered ineffective the second time, no real harm is done because the new SRTP session keys will be derived in part from a cached shared secret, which was safely protected from the MiTM in the previous DH exchange earlier in the same session.
一部ZRTPユーザエージェントは、ユーザが手動で安全な通話の途中で（GoClearメッセージを介して）クリア・モードに切り替え、その後再び安全モードを開始することを可能にします。多くの消費者向けクライアント製品は、この機能を省略したが、それは同じメディア・ストリームに再びモードを確保するために返すことができるようにするものでしょう。ハッシュ画像の同じチェーンが二度目効果がなくなるので、再利用とされますが、新たなSRTPセッション鍵を安全に、前にMITMから保護したキャッシュされた共有シークレット、から部分的に導出されるため、何の実害が行われません以前同じセッションでDH交換。
This section discusses the operation of a ZRTP endpoint that is actually an intermediary. For example, consider a device that proxies both signaling and media between endpoints. There are three possible ways in which such a device could support ZRTP.
このセクションでは、実際に仲介されZRTPエンドポイントの操作について説明します。例えば、エンドポイント間のシグナリングおよびメディアの両方をプロキシデバイスを考えます。このようなデバイスはZRTPをサポートする可能性があった3つの方法があります。
An intermediary device can act transparently to the ZRTP protocol. To do this, a device MUST pass non-RTP protocols multiplexed on the same port as RTP (to allow ZRTP and STUN). This is the RECOMMENDED behavior for intermediaries as ZRTP and SRTP are best when done end-to-end.
中間デバイスは、ZRTPプロトコルに透過的に行動することができます。これを行うには、デバイスは、（ZRTPとSTUNを許可するように）RTPと同じポート上で多重非RTPプロトコルを渡す必要があります。エンドツーエンドをやったときにZRTPとSRTPは最高です、これは仲介するための推奨動作です。
An intermediary device could implement the ZRTP protocol and act as a ZRTP endpoint on behalf of non-ZRTP endpoints behind the intermediary device. The intermediary could determine on a call-by-call basis whether the endpoint behind it supports ZRTP based on the presence or absence of the ZRTP SDP attribute flag (a=zrtp-hash). For non-ZRTP endpoints, the intermediary device could act as the ZRTP endpoint using its own ZID and cache. This approach SHOULD only be used when there is some other security method protecting the confidentiality of the media between the intermediary and the inside endpoint, such as IPsec or physical security.
中間デバイスは、ZRTPプロトコルを実装し、中間デバイスの背後にある非ZRTPエンドポイントに代わってZRTPエンドポイントとして作用することができます。仲介者は、その背後にあるエンドポイントがZRTP SDP属性フラグ（A = ZRTPハッシュ）の有無に基づいてZRTPをサポートするかどうかをコールごとに決定することができます。非ZRTPエンドポイントの場合、中間デバイスは、独自のZIDとキャッシュを使用してZRTPエンドポイントとして作用することができます。そのようなIPSecまたは物理的なセキュリティなどの中間と内部エンドポイントとの間の媒体の機密性を保護するいくつかの他のセキュリティ方法がある場合、このアプローチは、使用されるべきです。
The third mode, which is NOT RECOMMENDED, is for the intermediary device to attempt to back-to-back the ZRTP protocol. The only exception to this case is where the intermediary device is a trusted element providing services to one of the endpoints -- e.g., a Private Branch Exchange or PBX. In this mode, the intermediary would attempt to act as a ZRTP endpoint towards both endpoints of the media session. This approach MUST NOT be used except as described in Section 7.3 as it will always result in a detected MiTM attack and will generate alarms on both endpoints and likely result in the immediate termination of the session. The PBX MUST uses a single ZID for all endpoints behind it.
推奨されていない第三のモードは、バック・ツー・バックするZRTPプロトコルを試みる仲介装置のためのものです。例えば、構内交換機またはPBX - 仲介装置は、エンドポイントの1つにサービスを提供する信頼できる要素である。この場合の唯一の例外です。このモードでは、仲介者は、メディアセッションの両方のエンドポイントへのZRTPエンドポイントとして機能しようとしていました。このアプローチは、それが常に検出されたMITM攻撃になりますし、エンドポイントとのセッションの即時終了でありそうな結果の両方でアラームが生成されますよう、セクション7.3に記載されている場合を除き使用してはいけません。 PBXのMUSTは、その背後にあるすべてのエンドポイントの単一ZIDを使用しています。
In cases where centralized media mixing is taking place, the SAS will not match when compared by the humans. This situation can sometimes be known in the SIP signaling by the presence of the isfocus feature tag [RFC4579]. As a result, when the isfocus feature tag is present, the DH exchange can be authenticated by the mechanism defined in Section 8.1.1 or by validating signatures (Section 7.2) in the Confirm or SASrelay messages. For example, consider an audio conference call with three participants Alice, Bob, and Carol hosted on a conference bridge in Dallas. There will be three ZRTP encrypted media streams, one encrypted stream between each participant and Dallas. Each will have a different SAS. Each participant will be able to validate their SAS with the conference bridge by using signatures optionally present in the Confirm messages (described in Section 7.2). Or, if the signaling path has end-to-end integrity protection, each DH exchange will have automatic MiTM protection by using the mechanism in Section 8.1.1.
人間によって比較した場合、集中メディアミキシングが行われている場合には、SASは一致しません。この状況は、時々isfocus特徴タグ[RFC4579]の存在によってSIPシグナリングに知ることができます。 isfocus機能タグが存在する場合、結果として、DH交換は、セクション8.1.1で定義された機構によって、または確認またはSASrelayメッセージに署名（セクション7.2）を検証することによって認証することができます。例えば、アリス、ボブ、およびキャロルはダラスの会議ブリッジでホストされている3参加者との音声会議通話を検討します。 3つのZRTP暗号化されたメディアストリーム、各参加者とダラスの間に1つの暗号化されたストリームがあります。それぞれ異なるSASを持つことになります。各参加者は、（セクション7.2を参照）確認メッセージ中に任意に存在するシグネチャを使用して、会議ブリッジとそのSASを検証することができるであろう。シグナリングパスは、エンドツーエンドの完全性保護を持っている場合は、各DH交換は、セクション8.1.1にメカニズムを使用して自動MITM保護を持っています。
SIP feature tags can also be used to detect if a session is established with an automaton such as an Interactive Voice Response (IVR), voicemail system, or speech recognition system. The display of SAS strings to users should be disabled in these cases.
SIP機能タグは、セッションは、このような対話型音声応答（IVR）、ボイスメールシステム、または音声認識システムなどオートマトンで確立されているかどうかを検出するために使用することができます。ユーザーへのSAS文字列の表示は、これらの場合に無効にする必要があります。
It is possible that an intermediary device acting as a ZRTP endpoint might still receive ZRTP Hello and other messages from the inside endpoint. This could occur if there is another inline ZRTP device that does not include the ZRTP SDP attribute flag. An intermediary acting as a ZRTP endpoint receiving ZRTP Hello and other messages from the inside endpoint MUST NOT pass these ZRTP messages.
ZRTPエンドポイントとして機能する中間デバイスは、まだ内部エンドポイントからZRTPこんにちは、他のメッセージを受け取る可能性があることも可能です。 ZRTP SDP属性フラグが含まれていない他のインラインZRTP装置がある場合にこれが起こり得ます。内部エンドポイントからZRTPこんにちは、他のメッセージを受信ZRTPエンドポイントとして仲介の演技は、これらのZRTPメッセージを渡してはなりません。
There are no back doors defined in the ZRTP protocol specification. The designers of ZRTP would like to discourage back doors in ZRTP-enabled products. However, despite the lack of back doors in the actual ZRTP protocol, it must be recognized that a ZRTP implementer might still deliberately create a rogue ZRTP-enabled product that implements a back door outside the scope of the ZRTP protocol. For example, they could create a product that discloses the SRTP session key generated using ZRTP out-of-band to a third party. They may even have a legitimate business reason to do this for some customers.
ZRTPプロトコル仕様で定義されたバックドアはありません。 ZRTPの設計者はZRTP対応製品にバックドアを阻止したいと思います。しかし、実際のZRTPプロトコルにおけるバックドアの欠如にもかかわらず、ZRTPの実装はまだ故意ZRTPプロトコルの範囲外でバックドアを実装し、不正なZRTP対応の製品を作成する可能性があることを認識しなければなりません。例えば、彼らは、アウトオブバンド第三者にZRTPを使用して生成さSRTPセッションキーが記載されている製品を作成することができます。彼らはいくつかの顧客のためにこれを行うには、正当な業務上の理由であってもよいです。
For example, some environments have a need to monitor or record calls, such as stock brokerage houses who want to discourage insider trading, or special high-security environments with special needs to monitor their own phone calls. We've all experienced automated messages telling us that "This call may be monitored for quality assurance". A ZRTP endpoint in such an environment might unilaterally disclose the session key to someone monitoring the call. ZRTP-enabled products that perform such out-of-band disclosures of the session key can undermine public confidence in the ZRTP protocol, unless we do everything we can in the protocol to alert the other user that this is happening.
例えば、一部の環境では、自分の電話を監視する監視する必要性や特別なニーズを持つようにインサイダー取引を阻止したいの株式証券会社、または特別な高セキュリティ環境として、レコードのコールを、持っています。我々は、すべての「このコールは品質保証のために監視することができる」ということを告げて自動化されたメッセージを経験しました。このような環境でのZRTPエンドポイントは、一方的に電話を監視し、誰かにセッションキーを開示することがあります。私たちはこれが起こっている他のユーザーに警告するためのプロトコルでは、我々はできる限りのことを行う場合を除き、セッション鍵の、このようなアウトオブバンドの開示を行うZRTP対応製品は、ZRTPプロトコルに対する国民の信頼を損なうことができます。
If one of the parties is using a product that is designed to disclose their session key, ZRTP requires them to confess this fact to the other party through a protocol message to the other party's ZRTP client, which can properly alert that user, perhaps by rendering it in a graphical user interface. The disclosing party does this by sending a Disclosure flag (D) in Confirm1 and Confirm2 messages as described in Section 5.7.
当事者の一方がそのセッションキーを開示するように設計されている製品を使用している場合は、ZRTPは、おそらくレンダリングすることにより、適切に、そのユーザーに警告することができ、相手のZRTPクライアントにプロトコルメッセージを通じて相手にこの事実を告白するためにそれらを必要としそのグラフィカル・ユーザー・インターフェースインチ開示者は、セクション5.7に記載したようにCONFIRM1とConfirm2メッセージに開示フラグ（D）を送信することによってこれを行います。
Note that the intention here is to have the Disclosure flag identify products that are designed to disclose their session keys, not to identify which particular calls are compromised on a call-by-call basis. This is an important legal distinction, because most government sanctioned wiretap regulations require a VoIP service provider to not reveal which particular calls are wiretapped. But there is nothing illegal about revealing that a product is designed to be wiretap-friendly. The ZRTP protocol mandates that such a product "out" itself.
コールは、コールごとに侵害された特定のかを特定するのではなく、ここでの意図は開示フラグは、セッション鍵を開示するように設計されている製品を識別するために持っていることに注意してください。ほとんどの政府認可盗聴規制は、特定の通話が盗聴されている明らかにしないためにVoIPサービスプロバイダを必要とするため、これは重要な法的な区別です。しかし、製品が盗聴フレンドリーになるように設計されていることが明らかになった程度違法なものは何もありません。このような製品「アウト」自体ZRTPプロトコル義務付け。
You might be using a ZRTP-enabled product with no back doors, but if your own graphical user interface tells you the call is (mostly) secure, except that the other party is using a product that is designed in such a way that it may have disclosed the session key for monitoring purposes, you might ask him what brand of secure telephone he is using, and make a mental note not to purchase that brand yourself. If we create a protocol environment that requires such back-doored phones to confess their nature, word will spread quickly, and the "invisible hand" of the free market will act. The free market has effectively dealt with this in the past.
あなたはノーバックドアでZRTP対応の製品を使用しますが、独自のグラフィカル・ユーザー・インターフェースはあなたに電話を伝えた場合には、それがかもしれないことを他の当事者は、このような方法で設計された製品を使用していることを除いて、（主に）安全である可能性がありますあなたは彼が使用している安全な電話のどのブランド彼に尋ねると、そのブランドを自分で購入しない精神的なメモを作るかもしれませんが、監視の目的のためにセッションキーを開示しています。私たちはその性質を告白するようなバックdoored電話を必要とプロトコル環境を作成する場合、単語が急速に普及し、自由市場の「見えざる手」は動作します。自由市場は、効果的に、過去にこれを扱ってきました。
Of course, a ZRTP implementer can lie about his product having a back door, but the ZRTP standard mandates that ZRTP-compliant products MUST adhere to the requirement that a back door be confessed by sending the Disclosure flag to the other party.
もちろん、ZRTPの実装者は、彼の製品は、バックドアを持っ偽ることができますが、ZRTP準拠の製品は、バックドアを相手に公開フラグを送信することにより、告白する要件に準拠する必要がありますZRTP標準義務付け。
There will be inevitable comparisons to Steve Bellovin's 2003 April fool joke, when he submitted RFC 3514 [RFC3514], which defined the "Evil bit" in the IPv4 header, for packets with "evil intent". But we submit that a similar idea can actually have some merit for securing VoIP. Sure, one can always imagine that some implementer will not be fazed by the rules and will lie, but they would have lied anyway even without the Disclosure flag. There are good reasons to believe that it will improve the overall percentage of implementations that at least tell us if they put a back door in their products, and may even get some of them to decide not to put in a back door at all. From a civic hygiene perspective, we are better off with having the Disclosure flag in the protocol.
彼は「悪意」のパケットのために、IPv4ヘッダに「悪のビットを」定義されたRFC 3514 [RFC3514]を、提出したときに、スティーブBellovin氏の2003年のエイプリルフールのジョークに必然的な比較があります。しかし、我々は、同様のアイデアが実際のVoIPを確保するためのいくつかのメリットを持つことができることを提出します。確かに、人は常にいくつかの実装は、規則でfazedされず、あるだろうと想像することができますが、彼らも公開フラグなしでとにかく嘘をついていると思います。それは彼らが彼らの製品にバックドアを置けば、少なくとも教えて実装の全体的な割合を向上させる、とさえ全くバックドアに入れてしないことを決定するためにそれらのいくつかを得ることと信じる十分な理由があります。市民の衛生の観点から、我々は、プロトコルに公開フラグを持つほうが良いでしょう。
If an endpoint stores or logs SRTP keys or information that can be used to reconstruct or recover SRTP keys after they are no longer in use (i.e., the session is active), or otherwise discloses or passes SRTP keys or information that can be used to reconstruct or recover SRTP keys to another application or device, the Disclosure flag D MUST be set in the Confirm1 or Confirm2 message.
もしエンドポイント店舗やログ、彼らが使用されなくなった後に再構築するか、SRTPキーを回復するために使用することができないSRTPキーや情報を（すなわち、セッションがアクティブである）、またはその他記載されているかに使用することができますSRTPキーや情報を渡します。別のアプリケーションまたはデバイスにSRTP鍵を再構成または回復、開示フラグDはCONFIRM1又はConfirm2メッセージに設定されなければなりません。
Some implementers have asked for guidance on implementing the Disclosure flag. Some people have incorrectly thought that a connection secured with ZRTP cannot be used in a call center, with voluntary voice recording, or even with a voicemail system. Similarly, some potential users of ZRTP have over considered the protection that ZRTP can give them. These guidelines clarify both concerns.
いくつかの実装は、公開フラグを実装する上での指針を求めています。一部の人々は間違ってZRTPで保護された接続は、自主的な音声録音で、あるいはボイスメールシステムで、コール・センターで使用することができないと考えています。同様に、ZRTPのいくつかの潜在的なユーザーがオーバーZRTPがそれらを与えることができる保護を考えました。これらのガイドラインは、両方の懸念を明確にします。
The ZRTP Disclosure flag only governs the ZRTP/SRTP stream itself. It does not govern the underlying RTP media stream, nor the actual media itself. Consequently, a PBX that uses ZRTP may provide conference calls, call monitoring, call recording, voicemail, or other PBX features and still say that it does not disclose the ZRTP key material. A video system may provide DVR features and still say that it does not disclose the ZRTP key material. The ZRTP Disclosure flag, when not set, means only that the ZRTP cryptographic key material stays within the bounds of the ZRTP subsystem.
ZRTP開示フラグのみZRTP / SRTPストリーム自体を司ります。これは、基礎となるRTPメディアストリームを管理、また実際のメディア自体はありません。その結果、まだモニタリング、通話録音、ボイスメール、またはその他のPBXの機能を呼び出し、電話会議を提供してZRTPを使用するPBXは、それがZRTPキー材料を開示していないと言います。ビデオシステムは、DVR機能を提供し、まだそれがZRTPキー材料を開示していないことを言うかもしれません。設定されていないZRTP開示フラグは、ZRTP暗号鍵材料はZRTPサブシステムの境界内にとどまることだけを意味します。
If an application has a need to disclose the ZRTP cryptographic key material, the easiest way to comply with the protocol is to set the flag to the proper value. The next easiest way is to overestimate disclosure. For example, a call center that commonly records calls might choose to set the Disclosure flag even though all recording is an analog recording of a call (and thus outside the ZRTP scope) because it sets an expectation with clients that their calls might be recorded.
アプリケーションがZRTP暗号化キーマテリアルを開示する必要がある場合は、プロトコルに準拠する最も簡単な方法は、適切な値にフラグを設定することです。次の最も簡単な方法は、開示を過大評価することです。それは、そのコールが記録される可能性があることをクライアントと期待を設定するので、全ての記録は、コール（従って外部ZRTPスコープ）のアナログ記録であっても、例えば、一般にコールを記録するコールセンターは、公開フラグを設定することを選択するかもしれません。
Note also that the ZRTP Disclosure Flag does not require an implementation to preclude hacking or malware. Malware that leaks ZRTP cryptographic key material does not create a liability for the implementer from non-compliance with the ZRTP specification.
ZRTPの公開フラグがハッキングやマルウェア排除するために実装を必要としないことにも注意してください。 ZRTP暗号化キーマテリアルをリークマルウェアはZRTP仕様に非準拠の実装のための責任を作成しません。
A user of ZRTP should note that ZRTP is not a panacea against unauthorized recording. ZRTP does not and cannot protect against an untrustworthy partner who holds a microphone up to the speaker. It does not protect against someone else being in the room. It does not protect against analog wiretaps in the phone or in the room. It does not mean your partner has not been hacked with spyware. It does not mean that the software has no flaws. It means that the ZRTP subsystem is not knowingly leaking ZRTP cryptographic key material.
ZRTPのユーザーがZRTPが不正記録に対する万能薬ではないことに注意してください。 ZRTPはしていませんし、スピーカーにマイクを保持している信頼できない相手に対して保護することはできません。これは、部屋にいる他の誰かを防ぐことはできません。これは、携帯電話や室内でのアナログ盗聴を防ぐことはできません。それはあなたのパートナーがスパイウェアにハッキングされていないという意味ではありません。これは、ソフトウェアが何の欠陥がないことを意味するものではありません。それはZRTPサブシステムが故意にZRTP暗号化キーマテリアルが漏れていないことを意味します。
The role of the ZID in the management of the local cache of shared secrets is explained in Section 4.9. A particular ZID is associated with a particular ZRTP endpoint, typically a VoIP client. A single
共有シークレットのローカルキャッシュの管理にZIDの役割は、4.9節で説明されています。特定のZIDは、特定のZRTPエンドポイント、通常のVoIPクライアントに関連付けられています。独身者
SIP URI (also known as an Address-of-Record, or AOR) may be hosted on several different soft VoIP clients, desktop phones, and mobile handsets, and each of them will have a different ZID. Further, a single VoIP client may have several SIP URIs configured into its profiles, but only one ZID. There is not a one-to-one mapping between a ZID and a SIP URI. A single SIP URI may be associated with several ZIDs, and a single ZID may be associated with several SIP URIs on the same client.
（また、アドレス・オブ・レコード、またはAORとして知られている）のSIP URIは、いくつかの異なるソフトVoIPクライアント、デスクトップの電話、携帯電話上でホストされて、それぞれが異なるZIDを持つことになります。さらに、単一のVoIPクライアントはそのプロファイルに設定され、いくつかのSIP URIを持っているかもしれませんが、一つだけZID。 ZIDとSIP URI間の1対1のマッピングはありません。単一のSIP URIは、いくつかのZIDsに関連付けることができる、単一のZIDは、同じクライアント上にいくつかのSIP URIに関連付けられてもよいです。
Not only that, but ZRTP is independent of which signaling protocol is used. It works equally well with SIP, Jingle, H.323, or any proprietary signaling protocol. Thus, a ZRTP ZID has little to do with SIP, per se, which means it has little to do with a SIP URI.
それだけでなく、ZRTPが使用されるシグナリングプロトコルとは無関係です。これは、SIP、ジングル、H.323、または任意の独自のシグナリングプロトコルと等しく良好に機能します。したがって、ZRTP ZIDは、SIP URIとはほとんどを持っていることを意味する、それ自体はSIP、とはほとんどされています。
Even though a ZID is associated with a device, not a human, it is often the case that a ZRTP endpoint is controlled mainly by a particular human. For example, it may be a mobile phone. To get the full benefit of the key continuity features, a local cache entry (and thus a ZID) should be associated with some sort of name of the remote party. That name could be a human name, or it could be made more precise by specifying which ZRTP endpoint he's using. For example "Jon Callas", or "Jon Callas on his iPhone", or "Jon on his iPad", or "Alice on her office phone". These name strings can be stored in the local cache, indexed by ZID, and may have been initially provided by the local user by hand. Or the local cache entry may contain a pointer to an entry in the local address book. When a secure session is established, if a prior session has established a cache entry, and the new session has a matching cache entry indexed by the same ZID, and the SAS has been previously verified, the person's name stored in that cache entry should be displayed.
ZIDがデバイスではなく、人間に関連付けられているにもかかわらず、それはしばしばZRTPエンドポイントが特定の人間によって主に制御される場合です。例えば、それは携帯電話であってもよいです。キーの連続機能、ローカル・キャッシュ・エントリ（したがってZID）の完全な利益を得るために、相手の名前のいくつかの並べ替えに関連付けする必要があります。この名前は、人間の名前かもしれない、またはそれは彼が使っていたZRTPエンドポイントを指定することで、より正確に作ることができます。例えば、「ジョン・カラス」、または「自分のiPhone上のジョン・カラス」、または「彼のiPadのジョン」、または「彼女のオフィス電話機のアリス」。これらの名前の文字列は、ZIDによってインデックス付け、ローカルキャッシュに格納することができ、最初は手でローカルユーザによって提供されている可能性があります。またはローカル・キャッシュ・エントリは、ローカルアドレス帳のエントリへのポインタが含まれていてもよいです。セキュアなセッションが確立されると前のセッションがキャッシュエントリを確立しているし、新しいセッションが同じZIDによってインデックスを付け、一致するキャッシュエントリを持ち、SASが以前に検証された場合、そのキャッシュエントリに保存されている人の名前がなければなりません表示されました。
If the remote ZID originates from a PBX, the displayed name would be the name of that PBX, which might be the name of the company who owns that PBX.
リモートZIDは、PBXから発信した場合、表示された名前は、そのPBXを所有している会社の名前であるかもしれない、そのPBXの名前になります。
If it is desirable to associate some key material with a particular AOR, digital signatures (Section 7.2) may be used, with public key certificates that associate the signature key with an AOR. If more than one ZRTP endpoint shares the same AOR, they may all use the same signature key and provide the same public key certificate with their signatures.
それは特定のAORといくつかの重要な材料を関連付けることが望ましい場合は、デジタル署名（セクション7.2）AORと署名鍵を関連付けた公開鍵証明書を用いて、使用することができます。複数のZRTPのエンドポイントを共有した場合と同じAOR、それらはすべて同じ署名鍵を使用し、その署名と同じ公開鍵証明書を提供することができます。
This specification defines a new SDP [RFC4566] attribute in Section 8.
この仕様は、第8章の新しいSDP [RFC4566]属性を定義します。
Contact name: Philip Zimmermann <prz@mit.edu>
担当者名：フィリップ・ツィンマーマン<prz@mit.edu>
Attribute name: "zrtp-hash"
属性名：「ZRTP-ハッシュ」
Type of attribute: Media level
属性の種類：メディアレベル
Subject to charset: Not
文字セットの件名：ありません
Purpose of attribute: The 'zrtp-hash' indicates that a UA supports the ZRTP protocol and provides a hash of the ZRTP Hello message. The ZRTP protocol version number is also specified.
属性の目的：「ZRTP-ハッシュは、」UAがZRTPプロトコルをサポートし、ZRTP Helloメッセージのハッシュを提供することを示しています。 ZRTPプロトコルバージョン番号も指定されています。
Allowed attribute values: Hex
許可された属性値：六角
This section discuses how ZRTP meets all RTP security requirements discussed in the Media Security Requirements [RFC5479] document without any dependencies on other protocols or extensions, unlike DTLS-SRTP [RFC5764] which requires additional protocols and mechanisms.
このセクションでは、ZRTPは、追加のプロトコルやメカニズムを必要とDTLS、SRTP [RFC5764]とは異なり、他のプロトコルや機能拡張に依存せずにメディアのセキュリティ要件[RFC5479]文書で説明するすべてのRTPのセキュリティ要件を満たしているかdiscuses。
R-FORK-RETARGET is met since ZRTP is a media path key agreement protocol.
ZRTPメディアパス鍵合意プロトコルであるので、R-フォークリターゲットが満たされます。
R-DISTINCT is met since ZRTP uses ZIDs and allows multiple independent ZRTP exchanges to proceed.
ZRTPはZIDsを使用して、複数の独立したZRTP交換が進行することを可能にするので、R-DISTINCTが満たされます。
R-HERFP is met since ZRTP is a media path key agreement protocol.
ZRTPメディアパス鍵合意プロトコルであるので、R-HERFPが満たされています。
R-REUSE is met using the Multistream and Preshared modes.
R-REUSEは、マルチストリームと事前共有モードを使用して満たされます。
R-AVOID-CLIPPING is met since ZRTP is a media path key agreement protocol.
ZRTPメディアパス鍵合意プロトコルであるので、R-AVOIDクリッピングが満たされています。
R-RTP-CHECK is met since the ZRTP packet format does not pass the RTP validity check.
ZRTPパケットフォーマットは、RTPの妥当性チェックに合格していないので、R-RTP-CHECKが満たされています。
R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and responses (Section 8.1).
R-ASSOCを招き、応答（セクション8.1）におけるA = ZRTPハッシュSDP属性を使用して満たされます。
R-NEGOTIATE is met using the Commit message.
Rネゴシエーションがコミットメッセージを使用して満たされます。
R-PSTN is met since ZRTP can be implemented in Gateways.
ZRTPをゲートウェイに実装することができるので、R-PSTNが満たされます。
R-PFS is met using ZRTP Diffie-Hellman key agreement methods.
R-PFSはZRTPのDiffie-Hellman鍵の方法を使用して満たされています。
R-COMPUTE is met using the Hello/Commit ZRTP exchange.
R-COMPUTEはこんにちは/ ZRTP交換をコミット使用して満たされています。
R-CERTS is met using the verbal comparison of the SAS.
R-CERTSは、SASの口頭比較を使用して満たされます。
R-FIPS is met since ZRTP uses only FIPS-approved algorithms in all relevant categories. The authors believe ZRTP is compliant with [NIST-SP800-56A], [NIST-SP800-108], [FIPS-198-1], [FIPS-180-3], [NIST-SP800-38A], [FIPS-197], and [NSA-Suite-B], which should meet the FIPS-140 validation requirements set by [FIPS-140-2-Annex-A] and [FIPS-140-2-Annex-D].
ZRTPは、関連するすべてのカテゴリでのみFIPS認定のアルゴリズムを使用しているためR-FIPSが満たされています。著者はZRTPは[NIST-SP800-56A]、[NIST-SP800-108]、[FIPS-198から1]、[FIPS-180-3]、[NIST-SP800-38A]、[FIPS-に準拠していると考えていますFIPS-140 FIPS-140-2-アネックス-A]および[FIPS-140-2-アネックス-D]で設定された検証要件を満たさなければならない197]、および[NSAスイート-B]。
R-DOS is met since ZRTP does not introduce any new denial-of-service attacks.
ZRTPが新しいサービス拒否攻撃を導入しないため、R-DOSが満たされています。
R-EXISTING is met since ZRTP can support the use of certificates or keys.
ZRTPは、証明書やキーの使用をサポートすることができますので、Rは、既存の満たされています。
R-AGILITY is met since the set of hash, cipher, SRTP authentication tag type, key agreement method, SAS type, and signature type can all be extended and negotiated.
ハッシュのセット、暗号、SRTP認証タグタイプ、鍵共有方法、SASタイプ、署名タイプがすべての拡張とネゴシエートすることができるので、R-AGILITYが満たされています。
R-DOWNGRADE is met since ZRTP has protection against downgrade attacks.
ZRTPはダウングレード攻撃に対する保護を持っているので、R-ダウングレードが満たされています。
R-PASS-MEDIA is met since ZRTP prevents a passive adversary with access to the media path from gaining access to keying material used to protect SRTP media packets.
ZRTPは、SRTPメディアパケットを保護するために使用される鍵材料にアクセスするから媒体経路へのアクセスを受動攻撃を防止するので、R-PASS-媒体が満たされます。
R-PASS-SIG is met since ZRTP prevents a passive adversary with access to the signaling path from gaining access to keying material used to protect SRTP media packets.
ZRTPは、SRTPメディアパケットを保護するために使用される鍵材料にアクセスするからシグナリング経路へのアクセスを受動攻撃を防止するので、R-PASS-SIGが満たされます。
R-SIG-MEDIA is met using the a=zrtp-hash SDP attribute in INVITEs and responses.
R-SIG-MEDIAを招き、応答で、A = ZRTPハッシュSDP属性を使用して満たされます。
R-ID-BINDING is met using the a=zrtp-hash SDP attribute (Section 8.1).
R-ID結合は、A = ZRTPハッシュSDP属性（セクション8.1）を使用して満たされます。
R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs and responses.
R-ACT-ACTを招き、応答で、A = ZRTPハッシュSDP属性を使用して満たされます。
R-BEST-SECURE is met since ZRTP utilizes the RTP/AVP profile and hence best effort SRTP in every case.
ZRTPは、すべてのケースでRTP / AVPプロフィールので、ベストエフォートSRTPを利用しているためR-BEST-SECUREが満たされています。
R-OTHER-SIGNALING is met since ZRTP can utilize modes in which there is no dependency on the signaling path.
ZRTPがシグナリング経路には依存関係が存在しないモードを利用することができるので、R-OTHER-シグナリングが満たされます。
R-RECORDING is met using the ZRTP Disclosure flag.
R-記録はZRTP開示フラグを使用して満たされます。
R-TRANSCODER is met if the transcoder operates as a trusted MitM (i.e., a PBX).
トランスコーダは（即ち、PBX）信頼のMitMとして動作する場合にR-トランスコーダは満たされます。
R-ALLOW-RTP is met due to ZRTP's best effort encryption.
R-ALLOW-RTPが原因ZRTPのベストエフォート型の暗号化に満たされています。
This document is all about securely keying SRTP sessions. As such, security is discussed in every section.
この文書は、すべてについてしっかりSRTPセッションをキーイングされます。そのため、セキュリティはすべてのセクションで説明されています。
Most secure phones rely on a Diffie-Hellman exchange to agree on a common session key. But since DH is susceptible to a MiTM attack, it is common practice to provide a way to authenticate the DH exchange. In some military systems, this is done by depending on digital signatures backed by a centrally managed PKI. A decade of industry experience has shown that deploying centrally managed PKIs can be a painful and often futile experience. PKIs are just too messy and require too much activation energy to get them started. Setting up a PKI requires somebody to run it, which is not practical for an equipment provider. A service provider, like a carrier, might venture down this path, but even then you have to deal with cross-carrier authentication, certificate revocation lists, and other complexities. It is much simpler to avoid PKIs altogether, especially when developing secure commercial products. It is therefore more common for commercial secure phones in the PSTN world to augment the DH exchange with a Short Authentication String (SAS) combined with a hash commitment at the start of the key exchange, to shorten the length of SAS material that must be read aloud. No PKI is required for this approach to authenticating the DH exchange. The AT&T TSD 3600, Eric Blossom's COMSEC secure phones [comsec], [PGPfone], and the GSMK CryptoPhone are all examples of products that took this simpler lightweight approach. The main problem with this approach is inattentive users who may not execute the voice authentication procedure.
最も安全な携帯電話は、共通のセッション鍵に合意するのDiffie-Hellman交換に依存しています。 DHは、MITM攻撃を受けやすいので、しかし、DH交換を認証する方法を提供するのが一般的です。いくつかの軍事システムでは、これを一元管理PKIに裏打ちされたデジタル署名に依存することによって行われます。業界での経験の十年は、一元的に管理のPKIを展開すると、痛みとしばしば無益経験をすることができますことを示しています。 PKIは、あまりにも乱雑であり、それらを始めるためにあまりにも多くの活性化エネルギーを必要とします。 PKIを設定すると、機器プロバイダーのための実用的ではないこれは、それを実行するために誰かを必要とします。サービスプロバイダは、キャリアのように、この道をベンチャーかもしれないが、それでもあなたは、クロスキャリア認証、証明書失効リスト、およびその他の複雑さに対処する必要があります。セキュアな商用製品を開発する場合は特に全くのPKIを避けるためにはるかに簡単です。それは読まなければならないSAS材料の長さを短くするために、鍵交換の開始時にハッシュコミットメントと組み合わせるショート認証文字列（SAS）とDH交換を強化するためにPSTNの世界では、商用セキュアな電話のため、より一般的です声を出して。何PKIは、DH交換を認証するためのこのアプローチのために必要とされません。 AT＆T TSD 3600、エリック・ブロッサムのCOMSEC安全な携帯電話[COMSEC]、[PGPfone]、およびGSMK CryptoPhoneこのシンプルな軽量なアプローチを取った製品のすべての例です。このアプローチの主な問題は、音声認証手順を実行しない場合があり不注意ユーザーです。
Some questions have been raised about voice spoofing during the short authentication string (SAS) comparison. But it is a mistake to think this is simply an exercise in voice impersonation (perhaps this could be called the "Rich Little" attack). Although there are digital signal processing techniques for changing a person's voice, that does not mean a MiTM attacker can safely break into a phone conversation and inject his own SAS at just the right moment. He doesn't know exactly when or in what manner the users will choose to read aloud the SAS, or in what context they will bring it up or say it, or even which of the two speakers will say it, or if indeed they both will say it. In addition, some methods of rendering the SAS involve using a list of words such as the PGP word list[Juola2], in a manner analogous to how pilots use the NATO phonetic alphabet to convey information. This can make it even more complicated for the attacker, because these words can be worked into the conversation in unpredictable ways. If the session also includes video (an increasingly common usage scenario), the MiTM may be further deterred by the difficulty of making the lips sync with the voice-spoofed SAS. The PGP word list is designed to make each word phonetically distinct, which also tends to create distinctive lip movements. Remember that the attacker places a very high value on not being detected, and if he makes a mistake, he doesn't get to do it over.
いくつかの質問には、短い認証文字列（SAS）の比較の際に音声なりすましについて提起されています。しかし、これは単に音声偽装（おそらくこれは「リッチ・リトル」攻撃と呼ばれることができる）の練習だと思うのは間違いです。人の声を変更するためのデジタル信号処理技術がありますが、それはMITM攻撃者が安全に携帯電話の会話に侵入し、ちょうどいい瞬間に自分のSASを注入することができるという意味ではありません。彼はまさにとき、またはユーザーが声を出してSASを読むために選択するか、どのような文脈で、彼らはそれを言うだろう2つのスピーカーのどちらも、それを持ち出すか、それを言うか、だろう、あるいはもし実際に彼らの両方何的には知りませんそれを言うだろう。また、SASをレンダリングするいくつかの方法は、パイロットが情報を伝達するためにNATO音標文字を使用する方法と同様の方法で、[Juola2ようなPGP単語リストなどの単語のリストを使用することを含みます。これらの言葉は、予測不可能な方法で会話に加工することができるので、これは、攻撃者にとって、それはさらに複雑にすることができます。セッションは、ビデオ（ますます一般的な使用シナリオ）を含む場合、MITMはさらに、音声偽装SASと唇の同期を行うことの難しさによって抑止することができます。 PGPの単語リストは、また、独特の唇の動きを作成する傾向が音声的に異なる各単語を作るために設計されています。攻撃者が検出されていない上、非常に高い価値を置き、彼は間違いを犯した場合、彼はそれを上に行うために取得しないことに注意してください。
A question has been raised regarding the safety of the SAS procedure for people who don't know each other's voices, because it may allow an attack from a MiTM even if he lacks voice impersonation capabilities. This is not as much of a problem as it seems, because it isn't necessary that users recognize each other by their voice. It is only necessary that they detect that the voice used for the SAS procedure doesn't match the voice in the rest of the phone conversation.
それは、彼が音声偽装能力を欠いていてもMITMからの攻撃を許す可能性があるので質問は、互いの声を知らない人のためのSAS手順の安全性について提起されてきました。ユーザーが自分の声で互いを認識している必要はないので、これは、それはそうと、問題の限りではありません。彼らがSASの手続きのために使用される音声は、電話の会話の残りの部分で音声と一致していないことを検出することのみが必要です。
Special consideration must be given to secure phone calls with automated systems that cannot perform a verbal SAS comparison between two humans (e.g., a voice mail system). If a well-functioning PKI is available to all parties, it is recommended that credentials be provisioned at the automated system sufficient to use one of the automatic MiTM detection mechanisms from Section 8.1.1 or Section 7.2. Or rely on a previously established cached shared secret (pbxsecret or rs1 or both), backed by a human-executed SAS comparison during an initial call. Note that it is worse than useless and absolutely unsafe to rely on a robot voice from the remote endpoint to compare the SAS, because a robot voice can be trivially forged by a MiTM. However, a robot voice may be safe to use strictly locally for a different purpose. A ZRTP user agent may render its locally computed SAS to the local user via a robot voice if no visual display is available, provided the user can readily determine that the robot voice is generated locally, not from the remote endpoint.
特別な配慮が2人（例えば、ボイスメールシステム）との間で口頭SASの比較を行うことができない自動化されたシステムとの電話通話を確保するために与えられなければなりません。うまく機能PKIは、すべての当事者に利用可能である場合は、資格情報は、セクション8.1.1または7.2からの自動MITM検出メカニズムのいずれかを使用するのに十分な自動化されたシステムでプロビジョニングすることをお勧めします。または最初の通話中に、人間が実行SASの比較に裏打ちされた以前に確立されたキャッシュされた共有秘密（pbxsecretまたはRS1あるいはその両方）、に依存しています。ロボットの声が自明MITMによって偽造することができますので、SASを比較するために、リモートエンドポイントからのロボットの声に頼っても無駄よりも悪いと絶対に安全ではないことに注意してください。しかし、ロボットの声は、異なる目的のために厳密にローカルで使用しても安全かもしれません。視覚的ディスプレイが利用できない場合ZRTPユーザエージェントは、容易にロボットの音声ではなく、リモートエンドポイントから、局所的に生成されていることを決定することができるユーザを設け、ロボット声を介してローカルユーザへのローカル計算SASをレンダリングすることができます。
A popular and field-proven approach to MiTM protection is used by SSH (Secure Shell) [RFC4251], which Peter Gutmann likes to call the "baby duck" security model. SSH establishes a relationship by exchanging public keys in the initial session, when we assume no attacker is present, and this makes it possible to authenticate all subsequent sessions. A successful MiTM attacker has to have been present in all sessions all the way back to the first one, which is assumed to be difficult for the attacker. ZRTP's key continuity features are actually better than SSH, at least for VoIP, for reasons described in Section 15.1. All this is accomplished without resorting to a centrally managed PKI.
MITM保護に人気があり、現場で実証済みのアプローチはピーター・ガットマンは「赤ちゃんアヒルの」セキュリティモデルを呼び出すことが好きSSH（セキュアシェル）[RFC4251]で使用されています。 SSHは、当方は一切の攻撃者が存在しないと仮定したときに、最初のセッションでは、公開鍵を交換することで関係を確立し、これにより、後続のすべてのセッションを認証することができます。成功のMITM攻撃者は、すべてのセッションに戻って、攻撃者にとって困難であると仮定される最初の1、すべての方法存在している必要があります。 ZRTPの主要な継続性機能は、少なくともVoIPのため、セクション15.1で説明する理由のために、実際にSSHよりも優れています。このすべては、集中管理されたPKIに頼ることなく達成されます。
We use an analogous baby duck security model to authenticate the DH exchange in ZRTP. We don't need to exchange persistent public keys, we can simply cache a shared secret and re-use it to authenticate a long series of DH exchanges for secure phone calls over a long period of time. If we verbally compare just one SAS, and then cache a shared secret for later calls to use for authentication, no new voice authentication rituals need to be executed. We just have to remember we did one already.
私たちは、ZRTPでDH交換を認証するために類似した赤ちゃんアヒルのセキュリティモデルを使用します。我々は、単に共有秘密をキャッシュし、長期間にわたって安全な電話のためのDH交換の長いシリーズを認証するために、それを再使用することができ、永続的な公開鍵を交換する必要はありません。私たちは、口頭だけの1 SASを比較して、後で共有秘密をキャッシュした場合、認証に使用するために呼び出す、新しい音声認証の儀式は、実行する必要はありません。私達はちょうど私たちはすでに1をやった覚えておく必要があります。
If one party ever loses this cached shared secret, it is no longer available for authentication of DH exchanges. This cache mismatch situation is easy to detect by the party that still has a surviving shared secret cache entry. If it fails to match, either there is a MiTM attack or one side has lost their shared secret cache entry. The user agent that discovers the cache mismatch must alert the user that a cache mismatch has been detected, and that he must do a verbal comparison of the SAS to distinguish if the mismatch is because of a MiTM attack or because of the other party losing her cache (normative language is in Section 4.3.2). Voice confirmation is absolutely essential in this situation. From that point on, the two parties start over with a new cached shared secret. Then, they can go back to omitting the voice authentication on later calls.
一方の当事者がこれまでにこのキャッシュされた共有秘密を失った場合、それはDH交換の認証に使用できなくなりました。このキャッシュの不一致の状況がまだ生き残っ共有秘密キャッシュエントリを持つ当事者によって検出することは容易です。それはどちらか、一致しないMITM攻撃または片側がある場合は、その共有の秘密のキャッシュエントリを失ってしまいました。キャッシュの不一致がキャッシュの不一致が検出されたことをユーザに警告し、不一致が原因MITM攻撃であるため、または他の当事者の彼女を失った場合、彼は区別するために、SASの口頭での比較を行う必要があることをしなければなりません発見するユーザーエージェントキャッシュ（規範的言語は、セクション4.3.2です）。音声確認は、このような状況では必要不可欠です。その時点から、両当事者は、新しいキャッシュされた共有秘密をやり直します。その後、彼らは後に通話に音声認証を省略に戻ることができます。
Precautions must be observed when using a trusted MiTM device such as a trusted PBX, as described in Section 7.3. Make sure you really trust that this PBX will never be compromised before establishing it as a trusted MiTM, because it is in a position to wiretap calls for any phone that trusts it. It is "licensed" to be in a position to wiretap. You are safer to try to arrange the connection topology to route the media directly between the two ZRTP peers, not through a trusted PBX. Real end-to-end encryption is preferred.
そのような信頼されたPBXとして信頼MITM装置を使用する場合、セクション7.3に記載されるように注意が、観察されなければなりません。あなたが本当にそれを信頼するすべての携帯電話へのコールを盗聴する立場にあるので、このPBXは、信頼できるMITMとしてそれを確立する前に損なわれないことを信頼していることを確認します。盗聴する立場にあることを「ライセンスを取得」されます。あなたがメディアに直接2つのZRTPピア間のルートへの接続トポロジを手配しようとする方が安全です、ない、信頼できるPBX経由。実エンド・ツー・エンドの暗号化が好ましいです。
The security of the SAS mechanism depends on the user verifying it verbally with his peer at the other endpoint. There is some risk the user will not be so diligent and may ignore the SAS. For a discussion on how users become habituated to security warnings in the PKI certificate world, see [Sunshine]. Part of the problems discussed in that paper are from the habituation syndrome common to most warning messages, and part of them are from the fact that users simply don't understand trust models. Fortunately, ZRTP doesn't need a trust model to use the SAS mechanism, so it's easier for the user to grasp the idea of comparing the SAS verbally with the other party;
SASメカニズムのセキュリティは、他のエンドポイントで彼のピアと口頭でそれを検証し、ユーザーに依存します。ユーザーがそう勤勉されず、SASを無視するかもしれないいくつかのリスクがあります。ユーザーは、PKI証明書の世界ではセキュリティ警告に慣れになる方法についての議論については、[サンシャイン]を参照してください。その論文で議論する問題の一部は、ほとんどの警告メッセージに共通慣れ症候群からであり、それらの一部は、ユーザーが簡単に信頼モデルを理解していないという事実からです。幸い、ZRTPは、SASのメカニズムを使用するための信頼モデルを必要としないので、ユーザは、相手と口頭でSASを比較する考えを把握することは簡単です。
it's easier than understanding a trust model, at least. Also, the verbal comparison of the SAS gets both users involved, and they will notice a mismatch of the SAS. Also, the ZRTP user agent will know when the SAS has been previously verified because of the SAS verified flag (V) (Section 7.1), and only ask the user to verify it when needed. After it has been verified once, the key continuity features make it unnecessary to verify it again.
それは、少なくとも、信頼モデルを理解するよりも簡単です。また、SASの口頭での比較は、両方のユーザーが関与して取得し、彼らは、SASの不一致に気づくでしょう。また、ZRTPユーザエージェントは、SASが以前ためにSASで検証されたときを知っているフラグ（V）（7.1節）を検証し、のみ必要なときにそれを検証するために、ユーザーに求めます。それは、一度確認された後、キーの連続機能は再びそれを確認することが不要になります。
The key continuity features of ZRTP are analogous to those provided by SSH (Secure Shell) [RFC4251], but they differ in one respect. SSH caches public signature keys that never change, and uses a permanent private signature key that must be guarded from disclosure. If someone steals your SSH private signature key, they can impersonate you in all future sessions and can mount a successful MiTM attack any time they want.
ZRTPのキー連続機能は、SSH（セキュアシェル）[RFC4251]で提供されるものに類似しているが、それらは一つの点で異なります。 SSHは決して変わらない公開署名鍵をキャッシュ、および開示から守られなければならない永久的な秘密署名鍵を使用しています。誰かがあなたのSSH秘密署名鍵を盗んだ場合、彼らは彼らが望む任意の時間を将来のすべてのセッションであなたを偽装することができますし、成功したMITM攻撃を仕掛けることができます。
ZRTP caches symmetric key material used to compute secret session keys, and these values change with each session. If someone steals your ZRTP shared secret cache, they only get one chance to mount a MiTM attack, in the very next session. If they miss that chance, the retained shared secret is refreshed with a new value, and the window of vulnerability heals itself, which means they are locked out of any future opportunities to mount a MiTM attack. This gives ZRTP a "self-healing" feature if any cached key material is compromised.
ZRTPは秘密セッションキーを計算するために使用される対称鍵材料をキャッシュし、これらの値は、各セッションで変化します。誰かがあなたのZRTPは秘密のキャッシュを共有盗んだ場合、彼らは非常に次のセッションでは、MITM攻撃を仕掛けるための1つのチャンスを得ます。彼らはそのチャンスを逃した場合は、保持、共有秘密は、新しい値で更新され、脆弱性の窓は、彼らがMITM攻撃を仕掛けるために、任意の将来の機会からロックアウトされていることを意味する、自分自身を癒します。これはZRTPにキャッシュされたキーマテリアルが侵害された場合、「自己修復」機能を提供します。
A MiTM attacker must always be in the media path. This presents a significant operational burden for the attacker in many VoIP usage scenarios, because being in the media path for every call is often harder than being in the signaling path. This will likely create coverage gaps in the attacker's opportunities to mount a MiTM attack. ZRTP's self-healing key continuity features are better than SSH at exploiting any temporary gaps in MiTM attack opportunities. Thus, ZRTP quickly recovers from any disclosure of cached key material.
MITM攻撃者は、常にメディアパスでなければなりません。すべての呼び出しのためのメディアパスであることはシグナリングパスであることよりも、多くの場合困難であるため、これは、多くのVoIP利用シナリオで、攻撃者にとって大きな作業負担を提示します。これはおそらく、MITM攻撃を仕掛けるために攻撃者の機会でカバレッジギャップが作成されます。 ZRTPの自己回復キーの継続性機能は、MITM攻撃の機会に任意の一時的なギャップを悪用でSSHよりも優れています。したがって、ZRTPはすぐにキャッシュされたキー材料の任意の開示から回復します。
In systems that use a persistent private signature key, such as SSH, the stored signature key is usually protected from disclosure by encryption that requires a user-supplied high-entropy passphrase. This arrangement may be acceptable for a diligent user with a desktop computer sitting in an office with a full ASCII keyboard. But it would be prohibitively inconvenient and unsafe to type a high-entropy passphrase on a mobile phone's numeric keypad while driving a car. Users will reject any scheme that requires the use of a passphrase on such a platform, which means mobile phones carry an elevated risk of compromise of stored key material, and thus would especially benefit from the self-healing aspects of ZRTP's key continuity features.
SSHなどの永続的な秘密署名鍵を使用するシステムでは、格納された署名鍵は、通常、ユーザが提供する高エントロピーパスフレーズを必要とする暗号化によって開示から保護されます。この配置は、フルASCIIキーボードでオフィスに座ってデスクトップコンピュータと勤勉なユーザーのために許容可能です。しかし、車を運転中の携帯電話のテンキーの高エントロピーのパスフレーズを入力するために法外不便や危険なことでしょう。ユーザーは携帯電話が格納されたキーマテリアルの妥協の高いリスクを伴うため、特にZRTPのキーの連続機能の自己回復の面から利益を得るであろう意味なプラットフォーム、上のパスフレーズを使用する必要が任意のスキームを拒否します。
The infamous Debian OpenSSL weak key vulnerability [dsa-1571] (discovered and patched in May 2008) offers a real-world example of why ZRTP's self-healing scheme is a good way to do key continuity. The Debian bug resulted in the production of a lot of weak SSH (and TLS/SSL) keys, which continued to compromise security even after the bug had been patched. In contrast, ZRTP's key continuity scheme adds new entropy to the cached key material with every call, so old deficiencies in entropy are washed away with each new session.
悪名高いDebianのOpenSSLの弱いキー脆弱性[DSA-1571]（2008年5月に発見し、パッチを適用）ZRTPのセルフヒーリング方式は、キーの連続を行うには良い方法である理由の実際の例を提供しています。 Debianのバグはバグが修正されていた後でさえも、セキュリティを侵害し続け弱いSSH（およびTLS / SSL）キー、たくさんのが産生されました。 ZRTPのキーの連続方式は、すべての呼び出しでキャッシュされたキーマテリアルに新しいエントロピーを追加これとは対照的に、エントロピーのように古い欠陥がそれぞれの新しいセッションで洗い流されます。
It should be noted that the addition of shared secret entropy from previous sessions can extend the strength of the new session key to AES-256 levels, even if the new session uses Diffie-Hellman keys no larger than DH-3072 or ECDH-256, provided the cached shared secrets were initially established when the wiretapper was not present. This is why AES-256 MAY be used with the smaller DH key sizes in Section 5.1.5, despite the key strength comparisons in Table 2 of [NIST-SP800-57-Part1].
それは、新しいセッションがより大きくないのDiffie-Hellman鍵を使用している場合でも、前のセッションからの共有秘密のエントロピーの添加は、AES-256レベルに新しいセッションキーの強度を拡張することができることに留意すべきであるDH-3072またはECDH-256、盗聴者が存在しないとき、最初に確立されたキャッシュされた共有シークレットを提供します。 AES-256は[NIST-SP800-57-その1]の表2の鍵強度の比較にもかかわらず、セクション5.1.5に小さいDHキーサイズで使用することができる理由です。
Caching shared symmetric key material is also less CPU intensive compared with using digital signatures, which may be important for low-power mobile platforms.
キャッシング共有対称鍵材料は、低電力モバイル・プラットフォームのために重要であるかもしれないデジタル署名を使用して比較し、より少ないCPU集約的です。
Unlike the long-lived non-updated key material used by SSH, the dynamically updated shared secrets of ZRTP may lose sync if traditional backup/restore mechanisms are used. This limitation is a consequence of the otherwise beneficial aspects of this approach to key continuity, and it is partially mitigated by ZRTP's built-in cache backup logic (Section 4.6.1).
従来のバックアップ/復元メカニズムが使用されている場合は、SSHで使用される長寿命の非更新された鍵材料とは異なり、ZRTPの動的に更新共有秘密は、同期を失う可能性があります。この制限は、キーの連続性に対するこのアプローチのそれ以外の有益な態様の結果であり、それは部分的にZRTPの内蔵キャッシュのバックアップ・ロジック（4.6.1項）によって軽減されます。
The authors would like to thank Bryce "Zooko" Wilcox-O'Hearn and Colin Plumb for their contributions to the design of this protocol. Also, thanks to Hal Finney, Viktor Krikun, Werner Dittmann, Dan Wing, Sagar Pai, David McGrew, Colin Perkins, Dan Harkins, David Black, Tim Polk, Richard Harris, Roni Even, Jon Peterson, and Robert Sparks for their helpful comments and suggestions. Thanks to Lily Chen at NIST for her assistance in ensuring compliance with NIST SP800-56A and SP800-108.
著者は、このプロトコルの設計への貢献のためにブライス「Zooko」ウィルコックス・O'Hearnとコリン・プラムに感謝したいと思います。また、ハル・フィニー、ヴィクトルKrikun、ヴェルナーDittmann、ダン・ウィング、サーガルパイ、デビッドマグリュー、コリンパーキンス、ダンハーキンズ、デビッド・ブラック、ティムポーク、リチャード・ハリス、ロニでも、ジョンピーターソン、ロバート・スパークスのおかげで彼らの役に立つコメントについてそして、提案。 NIST SP800-56AとSP800-108の遵守を確保する上で彼女の援助のためのNISTのリリー・チェンに感謝します。
The use of one-way hash chains to key HMACs in ZRTP is similar to Adrian Perrig's TESLA protocol [TESLA].
ZRTPの重要HMACsへの一方向ハッシュチェーンの使用はエイドリアンPerrigのTESLAプロトコル[TESLA]に似ています。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.およびM.古城、 "インターネット鍵交換のためのより多くのモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）"、RFC 3526、2003年5月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231] Nystrom、M.、 "識別子とHMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512のテストベクター"、RFC 4231、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]カラス、J.、Donnerhacke、L.、フィニー、H.、ショー、D.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 4880、2007年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114] Lepinski、M.とS.ケント、 "IETF標準を使用するための追加のDiffie-Hellmanのグループ"、RFC 5114、2008年1月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]ウイング、D.、フライドポテト、S.、Tschofenig、H.、およびF. Audet、 "要件とメディアセキュリティ管理プロトコルの分析"、RFC 5479、2009年4月。
[RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[RFC5759] Solinas、J.とL.チーグラー、 "スイートB証明書と証明書失効リスト（CRL）プロフィール"、RFC 5759、2010年1月。
[RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure RTP", RFC 6188, March 2011.
[RFC6188]マグリュー、D.、 "セキュアRTPにおけるAES-192およびAES-256を使用する"、RFC 6188、2011年3月。
[FIPS-140-2-Annex-A] "Annex A: Approved Security Functions for FIPS PUB 140-2", NIST FIPS PUB 140-2 Annex A, January 2011.
[FIPS-140-2-別館-A] "付録A：FIPS PUB 140-2のために承認されたセキュリティ機能"、NIST FIPS PUB 140-2附属書A、2011年1月。
[FIPS-140-2-Annex-D] "Annex D: Approved Key Establishment Techniques for FIPS PUB 140-2", NIST FIPS PUB 140-2 Annex D, January 2011.
[FIPS-140-2-別館-D] "附属書D：FIPS PUB 140-2のために鍵確立手法を承認"、NIST FIPS PUB 140-2附属書D、2011年1月。
[FIPS-180-3] "Secure Hash Standard (SHS)", NIST FIPS PUB 180-3, October 2008.
[FIPS-180-3]、NIST FIPS PUB 180-3の、2008年10月 "ハッシュ規格（SHS）を固定します"。
[FIPS-186-3] "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3, June 2009.
[FIPS-186-3] "デジタル署名標準（DSS）"、NIST FIPS PUB 186- 3 2009年6月。
[FIPS-197] "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001.
[FIPS-197] "のAdvanced Encryption Standard（AES）"、NIST FIPS PUBの197、2001年11月。
[FIPS-198-1] "The Keyed-Hash Message Authentication Code (HMAC)", NIST FIPS PUB 198-1, July 2008.
[FIPS-198から1] "鍵付きハッシュメッセージ認証コード（HMAC）"、NIST FIPSパブ198から1 2008年7月。
[NIST-SP800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, 2001 Edition.
[NIST-SP800-38A] Dworkin、M.、 "操作のブロック暗号モードのための勧告" は、NIST Special Publication 800-38A、2001版。
[NIST-SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800- 56A Revision 1, March 2007.
、は、NIST Special Publication 800- 56Aリビジョン1、2007年3月[NIST-SP800-56A]バーカー、E.、ジョンソン、D.、およびM. SMID、 "離散対数暗号を使用してペアワイズ鍵確立スキームのための勧告"。
[NIST-SP800-90] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90 (Revised), March 2007.
、は、NIST Special Publication 800-90（改正）、2007年3月[NIST-SP800-90]バーカー、E.およびJ.ケルシー、 "確定的ランダムビットジェネレータを使用して乱数生成のための勧告"。
[NIST-SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800- 108, October 2009.
[NIST-SP800-108]チェン、L.、 "擬似ランダム関数を使用した鍵導出のための勧告"、は、NIST Special Publication 800- 108、2009年10月。
[NSA-Suite-B] "NSA Suite B Cryptography", NSA Information Assurance Directorate, NSA Suite B Cryptography.
[NSA-スイート-B] "NSAスイートB暗号化"、NSAの情報保証理事、NSAスイートB暗号化。
[NSA-Suite-B-Guide-56A] "Suite B Implementer's Guide to NIST SP 800-56A", Suite B Implementer's Guide to NIST SP 800-56A, 28 July 2009.
[NSA-スイート-B-ガイド-56A] "NIST SP 800-56AにスイートBのImplementerのガイド"、NIST SP 800-56AにスイートBインプリメンターズ・ガイド、2009年7月28日。
[TwoFish] Schneier, B., Kelsey, J., Whiting, D., Hall, C., and N. Ferguson, "Twofish: A 128-Bit Block Cipher", June 1998, <http://www.schneier.com/paper-twofish-paper.html>.
【いるTwoFish]シュナイアー、B.、ケルシー、J.、ホワイティング、D.、ホール、C.、およびN.ファーガソン、 "Twofishは128ビットのブロック暗号"、1998年6月、<HTTP：//www.schneier .COM /紙-twofishです-paper.html>。
[Skein] Ferguson, N., Lucks, S., Schneier, B., Whiting, D., Bellare, M., Kohno, T., Callas, J., and J. Walker, "The Skein Hash Function Family, Version 1.3 - 1 Oct 2010", <ht tp://www.skein-hash.info/sites/default/files/ skein1.3.pdf>.
[かせ]ファーガソン、N.、Lucks、S.、シュナイアー、B.、ホワイティング、D.、ベラー、M.、河野、T.、カラス、J.、およびJ.ウォーカー、「かせハッシュ関数族、バージョン1.3 - 2010" 年10月1日、<HT TP：//www.skein-hash.info/sites/default/files/ skein1.3.pdf>。
[pgpwordlist] "PGP Word List", December 2010, <http://en.wikipedia.org/ w/index.php?title=PGP_word_list&oldid=400752943>.
[pgpwordlist] "PGP単語リスト"、2010年12月、<http://en.wikipedia.org/ワット/ index.phpを？タイトル= PGP_word_list＆oldid = 400752943>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003.
[RFC3514] Bellovin氏、S.、 "IPv4のヘッダのセキュリティ・フラグ"、RFC 3514、2003年4月1日。
[RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004.
[RFC3824]ピーターソン、J.、劉、H.、ユー、J.、およびB.キャンベル、RFC 3824、2004年6月 "セッション開始プロトコル（SIP）とE.164番号を使用します"。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonenと、T.とC. Lonvick、 "セキュアシェル（SSH）プロトコルアーキテクチャ"、RFC 4251、2006年1月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475]スパークス、R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]ジョンストン、A.、およびO.レヴィン、 "セッション開始プロトコル（SIP）呼制御 - ユーザエージェントのための会議"、BCP 119、RFC 4579、2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]マグリュー、D.およびE.レスコラ、「データグラムトランスポート層セキュリティ（DTLS）セキュアリアルタイム転送プロトコル（SRTP）のための鍵を確立するための拡張」、RFC 5764、2010年5月。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5869] Krawczyk、H.、およびP. Eronen、 "HMACベースの抽出物と、拡大鍵導出関数（HKDF）"、RFC 5869、2010年5月を。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]マグリュー、D.、Igoe、K.、およびM.ソルター、 "基礎楕円曲線暗号アルゴリズム"、RFC 6090、2011年2月。
[SRTP-AES-GCM] McGrew, D., "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", Work in Progress, January 2011.
[SRTP-AES-GCM]マグリュー、D.、 "AES-GCMおよびSecure RTP（SRTP）でAES-CCM認証暗号"、進歩、2011年1月での作業。
[ECC-OpenPGP] Jivsov, A., "ECC in OpenPGP", Work in Progress, March 2011.
[ECC-のOpenPGP] Jivsov、A.、 "OpenPGPのでECC"、進歩、2011年3月に作業。
[VBR-AUDIO] Perkins, C. and J. Valin, "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Work in Progress, December 2010.
[VBR-AUDIO]パーキンス、C.とJ. Valinは、「セキュアRTPと可変ビットレート・オーディオの使用のためのガイドライン」、進歩、2010年12月での作業。
[SIP-IDENTITY] Wing, D. and H. Kaplan, "SIP Identity using Media Path", Work in Progress, February 2008.
[SIP-IDENTITY]ウイング、D.およびH.カプラン、 "メディアのパスを使用してSIPアイデンティティ"、進歩、2008年2月に作業。
[NIST-SP800-57-Part1] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57 - Part 1 Revised March 2007.
[NIST-SP800-57-パート1]バーカー、E.、バーカー、W.、バリ、W.、ポーク、W.、およびM. SMID、 "キー管理のための提言 - パート1：一般（改訂）"、NIST特別刊行物800-57 - 2007年3月改訂パート1。
[NIST-SP800-131A] Barker, E. and A. Roginsky, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A January 2011.
[NIST-SP800-131A]バーカー、E.およびA. Roginsky、 "暗号アルゴリズムと鍵の長さの移行のための勧告"、は、NIST Special Publication 800-131A 2011年1月。
[SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer Security Resource Center Cryptographic Hash Project.
[SHA-3]「暗号ハッシュアルゴリズムコンクール」、NISTコンピュータセキュリティリソースセンター暗号学的ハッシュプロジェクト。
[Skein1] "The Skein Hash Function Family - Web site", <http://www.skein-hash.info/>.
[Skein1] "かせハッシュ関数ファミリ - Webサイト"、<http://www.skein-hash.info/>。
[XEP-0262] Saint-Andre, P., "Use of ZRTP in Jingle RTP Sessions", XSF XEP 0262, August 2010.
[XEP-0262]サンアンドレ、P.、 "ジングルRTPセッションにおけるZRTPの使用"、XSFのXEP 0262、2010年8月。
[Ferguson] Ferguson, N. and B. Schneier, "Practical Cryptography", Wiley Publishing, 2003.
[ファーガソン]ファーガソン、N.およびB.シュナイアー、 "実用的な暗号化"、ワイリー出版、2003。
[Juola1] Juola, P. and P. Zimmermann, "Whole-Word Phonetic Distances and the PGPfone Alphabet", Proceedings of the International Conference of Spoken Language Processing (ICSLP-96), 1996.
【Juola1] Juola、P.及びP.ツィンマーマン、「トータル・ワード表音距離とPGPfoneアルファベット」、音声言語処理（ICSLP-96）、1996年国際会議の議事録。
[Juola2] Juola, P., "Isolated Word Confusion Metrics and the PGPfone Alphabet", Proceedings of New Methods in Language Processing, 1996.
[Juola2] Juola、P.、「孤立単語の混乱メトリックとPGPfoneアルファベット」、言語処理、1996年に新しいメソッドの議事。
[PGPfone] Zimmermann, P., "PGPfone", July 1996, <http://philzimmermann.com/docs/pgpfone10b7.pdf>.
[PGPfone]ツィンマーマン、P.、 "PGPfone"、1996年7月、<http://philzimmermann.com/docs/pgpfone10b7.pdf>。
[Zfone] Zimmermann, P., "Zfone Project", 2006, <http://www.philzimmermann.com/zfone>.
[Zfone]ツィンマーマン、P.、 "Zfoneプロジェクト"、2006年、<http://www.philzimmermann.com/zfone>。
[Byzantine] "The Two Generals' Problem", March 2011, <http:// en.wikipedia.org/w/ index.php?title=Two_Generals%27_Problem&oldid=417855753>.
[ビザンチン] "二人の将軍問題"、2011年3月、<のhttp：// en.wikipedia.org/w/ index.phpのタイトル= Two_Generals％27_Problem＆oldid = 417855753>。
[TESLA] Perrig, A., Canetti, R., Tygar, J., and D. Song, "The TESLA Broadcast Authentication Protocol", October 2002, <h ttp://www.ece.cmu.edu/~adrian/projects/tesla-cryptobytes/ tesla-cryptobytes.pdf>.
【TESLA】Perrig、A.、カネッティ、R.、Tygar、J.、およびD.ソング、 "TESLAブロードキャスト認証プロトコル" 2002年10月、<時間TTP：//www.ece.cmu.edu/~adrian /プロジェクト/テスラ-cryptobytes /テスラ-cryptobytes.pdf>。
[comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices Version 1.2", <http://www.comsec.com/vp1-protocol.pdf>.
[COMSEC]ブロッサム、E.、 "ボイスプライバシーデバイスバージョン1.2のためのVP1プロトコル"、<http://www.comsec.com/vp1-protocol.pdf>。
[Wright1] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations", Proceedings of the 2008 IEEE Symposium on Security and Privacy 2008, <http://cs.jhu.edu/~cwright/oakland08.pdf>.
[Wright1]ライト、C.、バラード、L.、Coull、S.、Monrose、F.、およびG.マッソン、 "あなたができるなら、私のスポット：暗号化されたVoIP通話で話されたフレーズを暴く"、2008 IEEEシンポジウムセキュリティとプライバシー2008、<http://cs.jhu.edu/~cwright/oakland08.pdf>。
[Sunshine] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", USENIX Security Symposium 2009, <http://lorrie.cranor.org/pubs/sslwarnings.pdf>.
[サンシャイン]サンシャイン、J.、Egelman、S.、Almuhimedi、H.、アトリ、N.、およびL. Cranor、 "クライング・ウルフ：SSL警告効果の実証的研究"、USENIXセキュリティシンポジウム2009、<のhttp：/ /lorrie.cranor.org/pubs/sslwarnings.pdf>。
[dsa-1571] "Debian Security Advisory - OpenSSL predictable random number generator", May 2008, <http://www.debian.org/security/2008/dsa-1571>.
[DSA-1571] "Debianセキュリティ勧告 - OpenSSLの予測可能な乱数生成器"、2008年5月、<http://www.debian.org/security/2008/dsa-1571>。
Authors' Addresses
著者のアドレス
Philip Zimmermann Zfone Project Santa Cruz, California
フィリップ・ツィンマーマンZfoneプロジェクトサンタクルス、カリフォルニア州
EMail: prz@mit.edu URI: http://philzimmermann.com
電子メール：prz@mit.edu URI：http://philzimmermann.com
Alan Johnston (editor) Avaya St. Louis, MO 63124
アラン・ジョンストン（エディタ）アバイアセントルイス、MO 63124
EMail: alan.b.johnston@gmail.com
メールアドレス：alan.b.johnston@gmail.com
Jon Callas Apple, Inc.
ジョン・カラスアップル社
EMail: jon@callas.org
メールアドレス：jon@callas.org