[要約] RFC 6189は、ユニキャストセキュアRTPのためのメディアパスキー合意プロトコルであるZRTPについての要約と目的を提供しています。このRFCの目的は、セキュアな通信を確保するために、RTPセッションの鍵交換を行うためのプロトコルを定義することです。
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
ZRTP：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.
このドキュメントでは、メディアパスDiffie-Hellman ExchangeのプロトコルであるZrtpを定義し、セッションキーと、Voice over IP（VOIP）アプリケーションのユニキャスト安全なリアルタイムトランスポートプロトコル（SRTP）セッションを確立するためのパラメーターを定義しています。ZRTPプロトコルは、RTPと同じポートで多重化されており、シグナリングプロトコルでサポートを必要としないため、Media Path Keyingです。ZRTPは、公開キーインフラストラクチャ（PKI）を想定していないか、エンドデバイスの証明書の複雑さを必要としません。メディアセッションでは、ZRTPは機密性、中間者（MITM）攻撃に対する保護、およびシグナリングプロトコルがエンドツーエンドの完全性保護、認証を提供する場合に提供します。ZRTPは、セッション説明プロトコル（SDP）属性を利用して、シグナリングチャネルを介して発見と認証を提供できます。Best Effects 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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）に依存していません。実際、永続的なパブリックキーはまったく使用していません。ハッシュのコミットメントを備えたEphemeral Diffie-Hellman（DH）を使用し、ユーザーが電話で読み取り、口頭で比較できる短い認証文字列（SAS）を表示することにより、中間（MITM）攻撃を検出できます。それは完全な前方の秘密を持っています。つまり、キーはコールの終わりに破壊され、将来のキー資料の開示による遡及的に妥協を妨げます。しかし、ユーザーが短い認証文字列を気にするにはあまりにも怠zyであっても、キーの連続性の形式に基づいて、MITM攻撃に対する合理的な認証を取得します。これは、次のコールで使用する重要な資料をキャッシュし、次のコールのDH共有シークレットと混合し、セキュアシェル（SSH）に類似した重要な連続性プロパティを与えます。これはすべて、PKI、主要な認定、信頼モデル、証明書当局、または電子メール暗号化の世界を悩ませる主要な管理の複雑さに依存せずに行われます。また、主要な管理の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-HASH SDP属性を介したシグナル伝達でZRTPが示されている場合、ZRTPには追加の有用な特性があります。シグナリングでZRTPハローメッセージのハッシュを送信することにより、ZRTPは、セクション8.1で説明されているシグナリングパスとメディアパスの間に有用な結合を提供します。これがエンドツーエンドの整合性保護を備えたシグナリングパスを介して行われると、DH交換はMITM攻撃から自動的に保護されます。これはセクション8.1.1で説明されています。
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].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" 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セッションが標準のRTP/AVPプロファイルを使用してオファー/回答交換でネゴシエートされるのと同じように交渉されます。ZRTPプロトコルは、2つのエンドポイントがSIPなどのシグナル伝達プロトコルを使用し、メディアを交換する準備ができてから始まります。Interactive Connectivity Indecivity（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 SDP属性の存在により、ZRTPサポートはシグナリングパスで発見できます。ただし、これが信号で受信されていない場合でも、エンドポイントはZRTP Helloメッセージを送信して、応答が受信されるかどうかを確認できます。応答が受信されない場合、このセッション中にZRTPメッセージは送信されません。ZRTPはRTPとは明らかに異なるように設計されており、氷の交換中に受信したスタンパケットと同様の構造を受け取ったスタンパケットと同様の構造を持っているため、安全です。
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があります。ZIDは、Hello Message Exchangeで発見されます。受信した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メッセージは、Helloの受領を単に確認するだけです。RTPは一般的に最良のUDPトランスポートを使用しているため、ZRTPにはデータグラムが失われた場合に再送信タイマーがあります。2つのタイマーがあり、どちらも指数関数的なバックオフメカニズムを備えています。1つのタイマーは、Helloメッセージの再送信に使用され、もう1つはHellocackを受信した後、他のすべてのメッセージの再送信に使用されます。
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.
整合性保護されたシグナリングチャネルが利用可能な場合、ハローメッセージのハッシュを送信できます。これにより、攻撃者が注入した誤ったzrtpハローメッセージを拒否できます。
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.
両方のEndPoints Exchange Helloと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.
コミットメッセージは、両方のエンドポイントがHello/Helloack Discoveryの握手を完了した直後に送信される場合があります。または、参加者が暗号化されていない会話に従事した後、コールの後半まで延期される場合があります。コミットメッセージは、GOセキュアボタンなど、ユーザーインターフェイス要素によって手動でアクティブになる場合があります。これにより、公開された電話ネットワーク（PSTN）World [COMSEC]にある多くの安全な電話のユーザーエクスペリエンスがエミュレートされます。ただし、ほとんどの単純なZRTPユーザーエージェントは、このようなボタンを省略し、Hello/Hellockの握手の直後にコミットメッセージを送信することにより、セキュアモードに直接進むことが期待されています。
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コールのフローの例を図1に示します。F1/F2およびF3/F4のHello/Hellock Exchangeの順序が逆になる可能性があることに注意してください。つまり、アリスまたはボブのいずれかが最初のハローメッセージを送るかもしれません。コミットメッセージを送信するエンドポイントは、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 Authenticationは、人間のユーザーに理想的に表示される短い認証文字列（SAS）を使用します。あるいは、SASは、CONDICE1またはciend2メッセージのSAS上でオプションのデジタル署名（SIG）を交換することで認証できます（セクション7.2で説明）。
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 Private Branch Exchange (PBX) Enrollment flag (E). All flags are encrypted to shield them from a passive observer.
ZRTP CONDICE1およびCONDICE2メッセージはいくつかの理由で送信されますが、少なくともすべての主要な合意計算が成功し、したがって暗号化が機能することを確認しているということです。また、開示フラグ（d）、許可クリアフラグ（a）、SAS検証フラグ（v）、プライベートブランチエクスチェンジ（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.
Presharedモードでは、エンドポイントが以前のZRTPセッションから共有秘密がある場合、DH計算をスキップできます。プリショアドモードはコミットメッセージに示されており、MultiStreamモードと同じコールフローが表示されます。MultiStreamモードとPresharedモードの主な違いは、Presharedモードが、アクティブな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.
Presharedモードには、秘密のプロパティがあります。携帯電話のキャッシュが対戦相手によってキャプチャされた場合、DHモードのように、共有された秘密が新しい通話の新しいコールで新しいものに置き換えるため、キャッシュされた共有秘密を使用するために以前の暗号化された呼び出しを回復することはできません。ただし、キャプチャされた秘密は、次の呼び出しがPresharedモードである場合、メディアパスの受動的な盗聴者によって次の呼び出しを復号化するために使用できます。これはDHモードとは異なり、次の呼び出しでキャプチャされた秘密を活用するためにアクティブなMITM盗聴者が必要です。ただし、次の呼び出しが盗聴者によって見逃された場合、彼はそれ以上の呼び出しを盗聴することはできません。したがって、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.
MultiStreamモードは、2つのエンドポイントにアクティブなZRTPセッションキーを使用して確立されたSRTPメディアストリームが確立されている場合に使用される代替キー契約法です。ZRTPは、単一のDH交換から複数のSRTPキーを導出できます。たとえば、ビデオストリームを追加する確立された安全な音声通話は、Multistreamモードを使用して、2回目のDH Exchangeなしでビデオストリームをすばやく開始します。
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.
Multistreamモードがコミットメッセージに示されている場合、図1と同様のコールフローが使用されますが、EndPointによってDH計算は実行されません。DHPART1およびDHPART2メッセージは省略されます。CONDIL1、CONDIME2、および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.
既存の呼び出しにメディアストリームを追加すると、MultiStreamモードのみが使用されます。最初のメディアストリームのためだけに、1つの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）メディアラインを使用します。セクション8で定義されているZRTP SDP属性A = ZRTP-HASHは、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-hashを中継することは常に可能ではありません。
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.
SECURE RTP/ AVP（SAVP）プロファイルは、ZRTP交換が成功した後、その後のオファー/回答交換で使用される場合があります。他のプロファイルも使用できます。
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を使用した交渉プロファイルの制限により、Best Effective 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メディアを送信してはなりません。また、conf2ackまたは最初のSRTPメディア（有効なSRTP AUTHタグを使用）をレスポンダーから受信する前にSRTPメディアを送信してはなりません。Responderは、コミットメッセージを受信した後にRTPメディアを送信しないでください。また、CONDIF2メッセージを受信する前に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属性a = Zrtp-hashを含める必要があります。
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）アルゴリズムが含まれます。Helloメッセージには、セクション9で説明されているハッシュ画像も含まれています。さらに、各エンドポイントはZIDを送信および発見します。受信したZIDは、以前に交渉され、2つの当事者間で保持されていた共有秘密のキャッシュへのインデックスとしてプロトコルの後半で使用されます。
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.
ハローメッセージはいつでも送信できますが、通常、RTPセッションの開始時に送信されて、他のエンドポイントがZRTPをサポートするかどうか、またSRTP実装が互換性があるかどうかを判断します。Hello Messageは、Timer T1と、Helloackメッセージまたはコミットメッセージの受信までセクション6で詳述されている指数関数的バックオフメカニズムを使用して再送信されます。
The use of the a=zrtp-hash SDP attribute to authenticate the Hello message is described in Section 8.1.
a = zrtp-hash sdp属性の使用は、helloメッセージを認証するためにセクション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.
ハローメッセージ、または他の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エンドポイントがプロトコルの複数のバージョンをサポートする場合、SIP SDP a = zrtp-hash属性（セクション8で定義）のリストにそれらをすべて宣言する必要があります。リスト。
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-Hash属性の相手が提供するZRTPバージョン番号のリストを検査する必要があります。両当事者は、a = zrtp-hashバージョン番号の両当事者のリストに表示される最高のバージョン番号を選択し、Helloメッセージにそのバージョンを使用する必要があります。両方の当事者がこの方法でSIPシグナリングを使用している場合、彼らの最初のハローメッセージは、両方とも少なくとも1つのサポートされたプロトコルバージョンを共通している場合、同じZRTPバージョン番号を持つでしょう。ZRTPキー契約が進む前に、エンドポイントが同じプロトコルバージョンでHellosを送信して受信している必要があります。
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-hash sdp属性は常にSIPパケットに存在するとは限りません。シグナリングレイヤーからのガイダンスがない場合、エンドポイントは最初のHelloメッセージで最高のサポートバージョンを送信する必要があります。2つの当事者が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).
o エンドポイントが、エンドポイントの現在のハローメッセージバージョンよりも高いサポートされていないバージョン番号を持つハローメッセージを受信した場合、受信したハローメッセージは無視する必要があります。エンドポイントは、標準の再試行スケジュール（セクション6）でハローメッセージを引き続き再送信し続けています。
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.
o エンドポイントがエンドポイントの現在のハローメッセージよりも低いバージョン番号を持つハローメッセージを受信し、エンドポイントが受信バージョン番号以下のバージョンをサポートする場合、エンドポイントは古いバージョン番号の再送信を停止する必要があります。受信したバージョン番号以下のサポートされているバージョン番号を持つハローメッセージの送信を開始します。
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.
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.
たとえば、Aliceがプロトコルバージョン1.10および2.00をサポートしており、Bobがバージョン1.10と1.20をサポートしていると仮定します。アリスは当初、バージョン2.00でハローを送信し、ボブは最初はバージョン1.20でハローを送信します。ボブはアリスの2.00 Helloを無視し、1.20 Hellosを送り続けています。アリスは、ボブが2.00をサポートしていないことを検出し、2.00 Hellosの送信を停止し、1.10 Hellosのストリームの送信を開始します。ボブはアリスから1.10 Helloを見て、1.20 Hellosの送信を停止し、1.10 Hellosの送信に切り替えます。
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.
コミットメッセージが送信される前に、2つの関係者が同じ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キーサイズの交渉にのみ使用されます。アルゴリズムの選択の残りの部分では、それは単にイニシエーターが共通のアルゴリズムから選択するものではありません。DHキーサイズは、セクション5.1.5で説明されているように、ハッシュタイプと対称暗号キーのサイズに影響することに注意してください。
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メッセージを受け取った後、ZRTPキー交換を開始するためにコミットメッセージ（セクション5.4）を送信できます。コミットを送信するエンドポイントはイニシエーターとして知られていますが、コミットの受信者はレスポンダーとして知られています。
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.
o 1つのコミットがDHモードの場合、もう1つのコミットはPresharedモードの場合、Preshared Commitを破棄し、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つのコミットが両方ともプレッシャーモードであり、1つの当事者がHelloメッセージにMITM（M）フラグを設定し、もう1つの当事者が（M）フラグを設定したパーティーからのコミットメッセージを破棄し、1つは廃棄する必要があります。（M）フラグを設定していない人は、NonCE値に関係なく開始者になりません。言い換えれば、Presharedモードの場合、電話はイニシエーターであり、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.
o 2つのコミットがDHモードまたは非DHモードの両方のいずれかである場合、最も低いHVI（イニシエーターのハッシュ値）値（DHコミットの場合）のコミットメッセージ、または最低のNonCE値（非DHコミットの場合）が必要です。廃棄され、反対側はイニシエーターであり、プロトコルはイニシエーターのコミットを進めます。2つのHVIまたはNonCE値は、ネットワークバイトの順序で大きな署名されていない整数と比較されます。
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つのコミットがMultiStreamモードの場合、もう1つは非マルチストリーム（DHまたはPRESHARED）モードの場合、ソフトウェアエラーが発生し、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 Exchangeを介して進行しますが、メディアストリームは廃棄されたコミットとともに他の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コミットメッセージを強制する場合、Responderの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の計算をカバーしません。それは、2つの当事者がキャッシュで共通の秘密をすでに共有しているかどうかを決定する方法をカバーします。
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は、このキャッシュのインデックスとして使用され、存在する場合は共有された秘密のセットを見つけます。このキャッシュエントリには、以前に保持されていた共有シークレットRS1およびRS2が含まれている場合があり、ZRTPに重要な連続性機能が与えられます。相手がPBXの場合、キャッシュには、セクション7.3.1で定義されているPBXSecretと呼ばれる信頼できるMITM PBX共有秘密も含まれている場合があります。
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つのエンドポイントがハッシュをキャッシュに比較できるようにして、セッションキーの計算で使用できる秘密を共有できるかどうかを検出します。。この共有秘密キャッシュの使用については、セクション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の共有秘密は、ZRTPプロトコルのVOIPユーザーエージェントの外れていることによって定義される場合があります。場合によっては、セクション8.2で定義されているSRTPSとして信号層によって提供される場合があります。シグナリングレイヤーによって提供されていない場合、AuxSecretの共有秘密は、2つの当事者間の事前の合意によってハッシュされたパスフレーズから計算された、またはハードウェアによって提供されたなど、バンド外の他のアプリケーション固有の方法で手動でプロビジョニングされる場合がありますトークン。または、それは2つの当事者の両方が属する機関が使用する家族の鍵かもしれません。これは、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.
イニシエーターとレスポンダーの両方について、共有秘密S1、S2、およびS3が計算され、後でセクション4.4.1.4でS0を計算するためにすべて使用できます。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は、Responderのキャッシュにあるものに応じて、イニシエーターのRS1またはイニシエーターのRS2のいずれかです。イニシエーターのRS1がレスポンダーのRS1またはRS2と一致する場合、S1はイニシエーターのRS1に設定する必要があります。その一致が失敗した場合にのみ、イニシエーターのRS2がレスポンダーのRS1またはRS2と一致する場合、S1はイニシエーターのRS2に設定する必要があります。その一致も失敗した場合、S1をnullに設定する必要があります。S1計算の複雑さは、2人の将軍の問題[ビザンチン]のために、以前の中止されたセッションからのキャッシュ同期の損失から回復することです。
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は、DHメッセージで送信されたAuxSecretのハッシュを比較することによって決定されるように、両当事者が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は、DHメッセージで送信されたPbxSecretのハッシュを比較することによって決定されるように、両当事者が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にヌル値がある場合、セクション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、 "responder"）
rs2IDr = MAC(rs2, "Responder")
rs2idr = mac（rs2、 "responder"）
auxsecretIDr = MAC(auxsecret, Responder's H3)
auxsecretidr = mac（auxsecret、responder's h3）
pbxsecretIDr = MAC(pbxsecret, "Responder")
pbxsecretidr = mac（pbxsecret、 "responder"）
rs1IDi = MAC(rs1, "Initiator")
rs1idi = mac（rs1、 "initiator"）
rs2IDi = MAC(rs2, "Initiator")
rs2idi = mac（rs2、 "initiator"）
auxsecretIDi = MAC(auxsecret, Initiator's H3)
auxsecretidi = mac（auxsecret、イニシエーターのH3）
pbxsecretIDi = MAC(pbxsecret, "Initiator")
pbxsecretidi = mac（pbxsecret、 "initiator"）
The responder sends rs1IDr, rs2IDr, auxsecretIDr, and pbxsecretIDr in the DHPart1 message. The initiator sends rs1IDi, rs2IDi, auxsecretIDi, and pbxsecretIDi in the DHPart2 message.
Responderは、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を共有する2つのZRTPエンドポイントを考慮してください（セクション7.3.1で定義）。比較中、RS1IDとPBXSeCretidは一致しますが、AuxSeCretidはそうではありません。その結果、S1 = RS1、S2はヌル、S3 = PBXSecretになります。
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がローカルキャッシュに存在するためキャッシュマッチを予想することを意味すると定義されていますが、S1のヌル値を計算しました（セクション4.3で説明した方法ごと）。
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つが、いくつかの事故によってキャッシュされた共有秘密を失っています。おそらく、彼らは以前のバックアップコピーからディスクを復元したため、キャッシュを誤って削除するか、キャッシュが失われたり破壊されたりしました。生き残ったキャッシュエントリを持っているパーティーは、キャッシュの不一致が発生したことを簡単に検出できます。なぜなら、彼らは自分のキャッシュされた秘密が相手のキャッシュされた秘密と一致することを期待しているからですが、それは一致しません。両方の当事者が、おそらくディスクのバックアップから回復した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攻撃が発生していないことを確認する他の当事者。ユーザーインターフェイスがサポートしていないため、または1つまたは両方のエンドポイントが無人デバイスであり、他の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が局所的に存在することを意味するように定義されていますが、S2のヌル値を計算しました（セクション4.3で説明した方法に従って）。この不一致は、ユーザーが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は、次のサブセクションで説明されているDiffie-Hellmanと2つの非ディフィーヘルマンモードを使用します。
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.
Diffie-Hellman（有限フィールドDiffie-HellmanまたはElliptic Curve Diffie-Hellmanのいずれか）の目的は、2つの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交換は保持されている共有秘密キャッシュの状態に影響するため、2つのZRTPエンドポイントの間に1つのインプロセスZRTP DH交換のみが発生する可能性があります。それ以外の場合、人種条件とキャッシュの整合性の問題が発生します。同じペアのZRTPエンドポイント（HelloメッセージのZIDで決定）の間に複数のメディアストリームが並行して確立されると、1つだけが処理できます。その交換がCONDIME2およびCONF2ACKメッセージで完了すると、別のZRTP DH交換が開始されます。この制約は、キャッシュされた共有秘密が影響を受けないため、MultiStream Modeキー契約を使用する場合は適用されません。
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.
送信されたハローメッセージのアルゴリズムの交差点から、イニシエーターはハッシュ、暗号、認証タグ、キー契約タイプ、および使用する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または楕円曲線Diffie-Hellman（ECDH）値の1つにコミットされたキー契約タイプを設定することにより、Diffie-Hellmanモードが選択されます。このモードでは、主要な契約は、選択されたキー契約タイプの値に基づいて、新鮮なランダムdiffie-hellman（dh）Secret Value（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.
有限フィールドDiffie-Hellmanの場合、DHジェネレーターG、DHプライムP、およびDH秘密値の長さであるSVIの値は、セクション5.1.5で定義されています。
pvi = g^svi mod p
pvi = g^svi mod 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はキー契約タイプ値によって決定されます。DH Public Value PVI値は、Big-Endian Octet Stringとしてフォーマットされ、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は計算され、セクション5.1.5のECDH仕様に従ってフォーマットされます。これは、NIST SP 800-56A [NIST-SP800-56A]の特定のセクションを詳細に参照しています。
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 Exchangeのイニシエーターによって実行されます。イニシエーターのハッシュ値、HVIには、図9（Diffie-Hellman Public Value、PVIを含む）に示すように、DHPART2メッセージ全体のハッシュを含み、ResponderのHelloメッセージ（ '||'は連結を意味します）が含まれています。HVIハッシュは256ビットに切り捨てられます。
hvi = hash(initiator's DHPart2 message || responder's Hello message)
hvi = hash（イニシエーターのdhpart2メッセージ||レスポンダーのハローメッセージ）
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.
ResponderのHelloメッセージからの情報は、Responderの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 Exchangeでのハッシュコミットメントの使用は、攻撃者を1つの推測に制約して、攻撃で正しい短い認証文字列（SAS）（セクション7）を生成します。つまり、SASは非常に短くなります。たとえば、16ビットのSASは、攻撃者に65536のうち、検出されていない可能性が1つだけに提供されます。このハッシュコミットメント機能がなければ、MITM攻撃者は、MITM攻撃に対して自分の2つのDHパブリックバリューを選択する前に、2つの当事者からPVIとPVRの両方のパブリックバリューを取得します。その後、彼はその情報を使用して、一致するSAで2つを見つけるまで、両側に対して多くの試行DH計算を迅速に実行できました。この誕生日攻撃のコストを引き上げるには、SASはもっと長くなければなりません。短い認証文字列は、ユーザーには受け入れられない長い認証文字列になる必要があります。ハッシュコミットメントは、MITMに2つの当事者のいずれかの公開価値を学ぶ前に、自分の2つのDHパブリックバリューを選択することを強制することにより、この攻撃を妨げます。
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.
コミットメッセージを受信すると、レスポンダーは独自のランダムDHシークレット値、SVRを生成し、パブリック値を計算します。（処理をスピードアップするために、この計算を事前に実行できることに注意してください。両方のエンドポイントがセクション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.
有限フィールドDiffie-Hellmanの場合、DHジェネレーターG、DHプライムP、およびDHシークレット値の長さであるSVRの値は、セクション5.1.5で定義されています。
pvr = g^svr mod p
pvr = g^svr mod 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は計算され、セクション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メッセージを受信すると、Responderは、イニシエーターのDHパブリックバリューが1またはP-1に等しくないことを確認します。攻撃者は、g^svi mod pに対して1またはp-1の値で誤ったDHPART2メッセージを注入する可能性があります。PVIが1またはP-1の場合、ユーザーは攻撃について警告する必要があり、プロトコル交換を終了する必要があります。それ以外の場合、Responderは、DHPART2メッセージと独自のHelloメッセージで受信したDH Public Value（PVI）を使用して、ハッシュコミットメントに対して独自の価値を計算し、結果をCommitメッセージで受信したHVIと比較します。それらが異なる場合、MITM攻撃が行われ、ユーザーが警告され、プロトコル交換が終了します。
The responder then calculates the Diffie-Hellman result:
レスポンダーは、diffie-hellmanの結果を計算します。
DHResult = pvi^svr mod p
dhresult = pvi^svr mod p
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に等しくないことを確認します。攻撃者は、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^svi 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 = hash（Responderのこんにちは||コミット|| 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の計算は、NIST SP 800-56A [NIST-SP800-56A]のセクション5.8.1および6.1.2.1の推奨事項に準拠していると考えています。これは、セクション4.3で説明されているように、dhresult、initiator（zidi）およびResponder（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.
[NIST-SP800-56A]のセクション5.8.1では、NISTでは特定のパラメーターを特定の順序でハッシュする必要があります。NISTは、Z、Algorithmid、PartyUinfo、PartyVinfo、Suppbubinfo、およびSuppprivinfoと呼びます。実装では、dhresultはzに対応し、「zrtp-hmac-kdf」はアルゴリズムに対応し、zidiとzidrはpartyuinfoとpartyvinfoに対応し、Total_hashはSuppubinfoに対応し、3つの共有秘密S1、S2、およびS3suppprivinfoに対応します。また、NISTでは、ハッシュが計算されるたびに32ビットのビッグエンディアン整数カウンターをハッシュに含める必要があります。これは、ハッシュを1回だけ計算するため、固定値1に設定しました。NISTとは、この計算でS0に対応する最終的なハッシュ出力をDerivedKeyingMaterialとして指します。
s0 = hash(counter || DHResult || "ZRTP-HMAC-KDF" || ZIDi ||
ZIDr || total_hash || len(s1) || s1 || len(s2) ||
s2 || len(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.
セクション4.3で説明した方法に従って、一時的な値S1、S2、およびS3が計算されたことに注意してください。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ビットのビッグエンディアン整数であり、その後のフィールドのオクテットに長さを与えます。共有秘密のセット（S1、S2、およびS3）の一部のメンバーは、null（共有されていない）であり、それぞれ4オクテットの長さのフィールドが先行する場合、ゼロの長さを持っている場合があります。たとえば、S2がnullの場合、Len（S2）は0x00000000であり、S2自体はハッシュ計算に存在しません。つまり、Len（S3）はすぐにLen（S2）に続きます。ZidiとZidrを含めることは冗長性があるかもしれませんが、それらはTotal_hashに暗黙的に含まれているため、Nist SP 800-56Aに従うためにここに明示的にそれらを含めます。固定長文字列「Zrtp-HMAC-KDF」（nullターミネートされていない）は、結果のS0がどの目的で使用されるかについて識別します。セクション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は、zrtpがS0と呼ぶnistがderivedkeyingmaterialと呼ぶものを計算します。このS0は、[nist-sp800-108]のセクション5および5.1で説明されているキー導出関数のKIと呼ばれるキー派生キーとして機能し、ZRTPが必要とする残りのサブキーをすべて導出します。ECDHモードの場合、著者は、S0計算がNIST SP 800-56A [NSA-SUITE-B-GUIDE-56A]の国家安全保障局（NSA）スイートB実装者のガイドガイドのセクション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、および両当事者に知られているNonCE値を含むKDFコンテキストフィールド（[NIST-SP800-108]ガイドラインごと）の使用が必要です。。Total_Hashは、InitiatorのコミットメッセージとResponderのHelloメッセージからのNONCEマテリアルが含まれていたため、NONCE値としての資格があります。
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つのエンドポイントは、Zrtpsessのキー導出と、セクション4.5.2の残りのキーの派生に進みます。これにより、S0が定義されています。
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.
Presharedキー契約モードを使用して、DH計算なしでSRTPキーと塩を生成できます。代わりに、エンドポイント間の以前のDH計算から共有された秘密に依存します。
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つの当事者間の安全なセッションを迅速に再確立するのに役立ちます。リソース制限環境。既存の呼び出しに追加のメディアストリームを追加するために、Presharedモードを使用しないでください。この目的には、MultiStreamモードを使用する必要があります。
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計算を実行できないプロセッサでは、Presharedモードが役立つ場合があります。共有されたキー資料は、2つのそのようなエンドポイント間で事前に手動でプロビジョニングされ、機能の限られたサブセットを許可する場合があります。このような「Nothing than Nothing」の実装は、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.
Presharedモードは保持されている共有秘密キャッシュの状態に影響するため、2つのZRTPエンドポイントの間に1つのインプロセスZRTP Preshared Exchangeのみが発生する可能性があります。このルールについては、セクション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.
Presharedモードは、メディアセキュリティ要件[RFC5479]ドキュメントのRリューズ要件を満たすために、この仕様にのみ含まれています。2つのZRTPエンドポイント間の一連のプレシャードキーの呼び出しは、定期的にDHキー交換を使用する必要があります。セクション4.9で説明されているように、Presharedモードは、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.
Presharedモードは、コミットメッセージで主要な契約タイプをPresharedに設定することにより選択されます。これにより、MultiStreamモードと同じコールフローが発生します。MultiStreamモードとPresharedモードの主な違いは、Presharedモードが、アクティブなZRTPセッションキーであるZRTPSESS（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).
Presharedモードは、キャッシュに信頼できる共有秘密を持つことに依存します。Presharedモードを使用する前に、共有秘密を生み出した最初のDH交換は、これらの反MITMメカニズムの少なくとも1つを使用する必要がありました。1）SASの口頭比較、SAS検証旗、または2）Sashashのデジタル署名（セクション7.2）のシグナリング（セクション8.1.1）、または3）のA = Zrtp-Hashのエンドツーエンドの整合性保護配信
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 Exchangeのイニシエーターによって送信されます。送信されたハローメッセージのアルゴリズムの交差点から、イニシエーターはハッシュ、暗号、認証タグ、キー契約タイプ、および使用する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 Commitを組み立てるには、まず、共有シークレットキャッシュで利用可能なものに応じて、キャッシュされたキーマテリアルのいくつかの可能な組み合わせの1つから構築された一時的なPreshared_keyを構築する必要があります。RS1がイニシエーターのキャッシュで利用できない場合、Presharedモードを使用してはなりません。
preshared_key = hash(len(rs1) || rs1 || len(auxsecret) || auxsecret ||
len(pbxsecret) || pbxsecret)
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語のランダムな非CE（16オクテット）。
- A keyID = MAC(preshared_key, "Prsh") truncated to 64 bits.
- keyID = 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.
注：NonCEは、各セッションの異なるSRTPキーと塩のペアを計算するために使用されるため、複製は2つのセッションで同じキーと塩が生成されるため、悲惨なセキュリティの結果をもたらします。
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.
Responderは、受信したKeyIDを使用して、キャッシュで重要なキーマテリアルを検索します。これは、Responderのローカルキャッシュで利用可能なものに応じて、イニシエーターと同じ式を使用してPreshared_key値とKeyID値を計算することで行います。ローカルに計算されたkeyIDがコミットの受信したKeyIDと一致しない場合、レスポンダーは、キャッシュから共有キーの異なるサブセットから新しいpreshared_keyとkeyIDを再構成し、auxsecret、pbxsecret、またはその両方を削除します。見つかったか、可能性がなくなっています。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.
適切な一致する共有キー資料が見つかった場合、共有秘密計算に関する次のセクションで説明されているように、S0と新しいZrtpsessキーを導出するために使用されます。セクション4.4.2.4。
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交換からキャッシュされた共有秘密を持っていないと判断した場合、またはイニシエーターからのKeyIDハッシュを共有キーの任意の組み合わせと一致させることができない場合、独自のDHコミットメッセージで応答する必要があります。これは役割を逆転させ、レスポンダーはイニシエーターになります。なぜなら、DHのコミットは、セクション4.2で説明されているように、常にPresharedコミットメッセージを「トランプ」しなければならないからです。キーエクスチェンジは、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.
双方が、安全なセッションを同時に開始するPRESHAREDコミットメッセージを送信すると、競合は解決され、イニシエーター/レスポンダーの役割はセクション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.
Presharedモードでは、DHPART1メッセージとDHPART2メッセージの両方がスキップされます。イニシエーターからコミットメッセージを受信した後、レスポンダーは、以下で説明するように、このストリームのSRTPキーを計算した後、CONDIM1メッセージを送信します。
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.
Presharedモードでは、S0とZrtpsessキーをPreshared_keyから導出する必要があります。これは、各セッションの一意性を保証する方法で行う必要があります。これは、両当事者のNonCEマテリアルを使用することによって行われます。イニシエーターのPRESHAREDコミットメッセージの明示的なNonCE（図7）とResponderのHelloメッセージ（図3）のH3フィールド。したがって、両当事者は、結果として得られる共有秘密を、各セッションで一意にすることを強制します。
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 = hash（responderのこんにちは||コミット）
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、および両当事者に知られているNonCE値を含むKDFコンテキストフィールド（[NIST-SP800-108]ガイドラインごと）の使用が必要です。。Total_Hashは、InitiatorのコミットメッセージとResponderのHelloメッセージからのNONCEマテリアルが含まれていたため、NONCE値としての資格があります。
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からZrtpキー導出関数（セクション4.5.1）を介して導出され、attotal_hashに暗黙的に含まれるnoncesが導出されます。また、noncesは、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.
Presharedモードのこの時点で、2つのエンドポイントは、Zrtpsessのキー導出に進み、セクション4.5.2のキーの残りの部分に進みます。これにより、S0が定義されています。
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.
MultiStreamキー契約モードを使用して、エンドポイントのペア間に確立された追加のメディアストリームのSRTPキーと塩を生成できます。エンドポイント間にアクティブなSRTPセッションが確立されていない限り、MultiStReamモードは使用できません。つまり、ZRTPセッションキーがアクティブであることを意味します。この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.
MultiStreamモードは、セクション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 Multistream session, a ZRTP endpoint MUST use the same ZID for all media streams, matching the ZID used in the first media stream.
既存の呼び出しにメディアストリームを追加する場合、MultiStreamモードを使用する必要があります。最初のメディアストリームは、DHモードまたはPresharedモードのいずれかを使用する必要があります。最初のメディアストリームのためだけに、1つのDH ExchangeまたはPreshared Exchangeのみが実行されます。DH ExchangeまたはPreshared Exchangeは、MultiStreamモードを使用して他のメディアストリームを追加する前に、最初のメディアストリームに対して完了する必要があります。MultiStreamセッションでは、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.
MultiStreamモードは、Initiatorによって選択され、キー契約タイプをコミットメッセージの「マルチ」に設定します（図6）。マルチストリームモードの暗号タイプ、AUTHタグの長さ、およびハッシュは、イニシエーターによって、初期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アルゴリズムをサポートできないため、この要件が必要です。ただし、GoClearの後にMultiStreamモードが安全になるために使用される場合、他のアクティブなSRTPセッションがない場合、同じ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.
コミットではHVIの代わりに、長さ4語（16オクテット）のランダムなノンセが選択されます。その値は、エンドポイントのペア間のアクティブなZRTPセッションに選択されたすべてのNonCE値に対して一意でなければなりません。再使用された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.
注：NonCEは、各メディアストリームの異なる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.
MultiStreamモードを選択してコミットを受信したが、レスポンダーに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.
MultiStreamモードでは、DHPART1メッセージとDHPART2メッセージの両方がスキップされます。イニシエーターからコミットメッセージを受信した後、レスポンダーは、以下で説明するように、このストリームのSRTPキーを計算した後、CONDIM1メッセージを送信します。
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.
MultiStreamモードでは、各メディアストリームでは、キーのセットをZrtpsessキーから導出する必要があります。これは、各メディアストリームの一意性を保証する方法で実行する必要があります。これは、両当事者のNonCEマテリアルを使用することによって行われます。イニシエーターのマルチストリームコミットメッセージ（図6）の明示的なNonCEと、ResponderのHelloメッセージ（図3）のH3フィールド。したがって、両当事者は、結果として生じる共有秘密を、各メディアストリームに対してユニークであることを強制します。
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 = hash（responderのこんにちは||コミット）
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キー契約を含む元のメディアストリームではなく、MultiStreamモードを使用している現在のメディアストリームのHelloとコミットメッセージを指します。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、および両当事者に知られているNonCE値を含むKDFコンテキストフィールド（[NIST-SP800-108]ガイドラインごと）の使用が必要です。。Total_Hashは、InitiatorのコミットメッセージとResponderのHelloメッセージからのNONCEマテリアルが含まれていたため、NONCE値としての資格があります。
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に暗黙的に含まれるNoncesを使用して計算されます。また、noncesは、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 Exchangeを実行したパケットシーケンス全体とは異なる包括的なTotal_hashも含まれる素材から以前に導出されていたことに注意してください。
At this point in Multistream mode, the two endpoints begin key derivations in Section 4.5.3.
この時点でMultiStreamモードでは、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）を実行し、カウンターの1回の反復のみを実行します。NIST PRFは、HMAC関数に基づいています。ZRTP KDFは、出力キーマテリアルの256ビット（またはスイートBアプリケーションの384ビット）を生成する必要はないため、HMAC関数の単一の呼び出しのみが必要です。
The ZRTP KDF is defined in this manner, per Sections 5 and 5.1 of [NIST-SP800-108]:
ZRTP KDFは、[NIST-SP800-108]のセクション5および5.1に従って、この方法で定義されています。
KDF(KI, Label, Context, L) = HMAC(KI, i || Label || 0x00 || Context || L)
kdf（ki、label、context、l）= hmac（ki、i || label || 0x00 || context || 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によってキー化されています。KIは、盗聴者（たとえば、S0）に知られていない秘密キー派生キーです。HMACは、次のように定義されている非秘密フィールドの連結セットで計算されます。最初のフィールドは、HMACが計算されるたびにHMACに含める必要がある32ビットのビッグエンディアン整数カウンター（i）です。HMACを1回しか計算しないため、0x000001の固定値に設定しました。ラベルは、派生したキーイング材料の目的を識別する一連のゼロオクテットです。Octet 0x00は、NISTが必要とする区切り文字です。NIST KDFフォーミュラには、Zidi、Zidr、および両当事者に知られているいくつかのオプションのNonCe資料を含む「コンテキスト」フィールドがあります。lは32ビットのビッグエンディアン陽性整数であり、HMACの出力のビットの長さを超えないようにします。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モードとPresharedモード（マルチストリームモードではなく）の両方が、ZRTPキー派生関数（セクション4.5.1）を介してZrtpsessとSASをZrtpsessとSASを導出するために、プロトコルのこの共通点に登場します。この時点で、S0はKDF_Contextと同様に計算されています。これらの計算は、MultiStreamモードではなく、最初のメディアストリームに対してのみ行われます。
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.
ZRTPSESSキーは、これら2つの目的でのみ使用されます。1）このセッションにメディアストリームを追加するための追加のS0キー（セクション4.4.3.2）を生成し、PBXSeCret（セクション7.3.1）を生成するために2）これは、将来のセッションで使用するためにキャッシュされる可能性があります。ZRTPSESSキーは、2つのZRTPエンドポイント間のコールシグナリングセッションの期間中に保持されます。つまり、エンドポイント間に2つの個別の呼び出しがある場合（SIPの用語では、SIPダイアログを個別に）、2つのコールシグナリングセッションでZRTPセッションキーを使用しないでください。Zrtpsessは、コールシグナリングセッションの終了までに破壊する必要があります。
ZRTPSess = KDF(s0, "ZRTP Session Key", KDF_Context, negotiated hash length)
zrtpsess = kdf（s0、 "zrtp session key"、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.
通話ごとに計算された短い認証文字列（SAS）（セクション7）は1つだけです。これは、ZRTPセッションの単一のDHキー契約から派生したすべてのメディアストリームに適用されます。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が2つの当事者にさらされているにもかかわらず、キーイング材料の残りの部分は、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 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キー交換を活用することで恩恵を受けるでしょう。その場合、ZRTPプロトコルからより多くの重要な資料を導き出し、「エクスポート」し、これらの非VOIP目的でVOIPクライアントの共有秘密として提供される場合があります。アプリケーションは、ZRTPプロトコルの範囲外で、アプリケーション固有の方法でこのエクスポートキーを使用できます。
ExportedKey = KDF(s0, "Exported key", KDF_Context, negotiated hash length)
ExportedKey = KDF（S0、 "Exported Key"、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.
コールごとに計算されるのは1つの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モードまたはPresharedモードのこの時点で、2つのエンドポイントは、セクション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モード、MultiStreamモード、およびPresharedモードはすべて、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はS0を使用して[NIST-SP800-108]に基づいてキー派生関数（セクション4.5.1）をキーにします。S0は既にその派生にTotal_hashを含んでいたため、S0がキーを着たKDFのすべての呼び出しで、KDFコンテキストでTotal_Hashを再度使用することが冗長です。それにもかかわらず、NIST SP 800-108は常にKDFのKDFコンテキストを定義する必要があり、いくつかのKDFの呼び出し（特にMultiStreamモードとPresharedモードの場合）ではNonCeマテリアルが必要であるため、Total_HashはKDFコンテキストでNonCEとして含まれます。
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 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.
個別のSRTPマスターキーとマスターソルトは、各メディアストリームの各方向で使用するために導出されます。特に指定されていない限り、ZRTPは、マスターキー識別子（MKI）なしでSRTP、HMAC-SHA1、AES-CM 128または256ビットキー長、112ビットセッションソルトキー長、2^48キー誘導レートを使用して32ビット認証を使用します。、およびSRTPプレフィックスの長さ0。セキュアRTCP（SRTCP）も使用され、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レスポンダーは、SRTPKEYIおよびSRTPSALTIを使用してパケットを解読し、ZRTPレスポンダー暗号化とZRTPイニシエーターはSRTPKEYRおよびSRTPSALTRを使用してパケットを飾り付けます。SRTPキーと塩の値は、選択したSRTPプロファイルによって決定される長さに切り捨てられます（左端のビットを取ります）。これらは次のように生成されます。
srtpkeyi = KDF(s0, "Initiator SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyi = kdf（s0、 "initiator srtpマスターキー"、kdf_context、ネゴシエートAESキー長）
srtpsalti = KDF(s0, "Initiator SRTP master salt", KDF_Context, 112)
srtpsalti = kdf（s0、 "initiator srtpマスターソルト"、kdf_context、112）
srtpkeyr = KDF(s0, "Responder SRTP master key", KDF_Context, negotiated AES key length)
srtpkeyr = kdf（s0、 "Responder srtpマスターキー"、kdf_context、ネゴシエートAESキー長）
srtpsaltr = KDF(s0, "Responder SRTP master salt", KDF_Context, 112)
srtpsaltr = kdf（s0、 "Responder srtp Master Salt"、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によっては使用されません。イニシエーターとレスポンダーには、各方向のGoClearメッセージが一意であり、攻撃者によってキャッシュできず、エンドポイントに反射することができないことを確認するために、異なるMacキーが必要です。
mackeyi = KDF(s0, "Initiator HMAC key", KDF_Context, negotiated hash length)
mackeyii = kdf（s0、 "initiatator hmac key"、kdf_context、ネゴシエートハッシュ長）
mackeyr = KDF(s0, "Responder HMAC key", KDF_Context, negotiated hash length)
Mackeyr = kdf（S0、 "Responder HMAC Key"、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キーは、InitiatatorとResponderがCONDICE1およびciend2メッセージを暗号化するために使用するために生成されます。それらは、ネゴシエートされたSRTPキーサイズと同じサイズに切り捨てられます。
zrtpkeyi = KDF(s0, "Initiator ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyi = kdf（s0、 "initiatator zrtp key"、kdf_context、ネゴシエートAESキー長）
zrtpkeyr = KDF(s0, "Responder ZRTP key", KDF_Context, negotiated AES key length)
zrtpkeyr = kdf（s0、 "Responder zrtp key"、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.
CONDIM1およびCONDICE2メッセージ（図10）には、新しく生成された保持された共有シークレットのキャッシュ有効期限間隔（セクション4.9で定義）が含まれています。Flagoctetは、これらのフラグで構成される8ビットの署名されていない整数です。セクション7.3.1で定義されているPBX登録フラグ（E）、セクション7.1で定義されたSAS検証フラグ（v）、セクション4.7.2、およびセクション11で定義されている開示フラグ（d）。
flagoctet = (E * 2^3) + (V * 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:
CONDIME1およびciend2メッセージの一部は、フルブロック暗号フィードバックモードを使用して暗号化され、128ビットのランダム暗号フィードバック（CFB）初期化ベクター（IV）が含まれています。CONSIFE1およびciend2メッセージには、ゼロの文字列、署名長、フラグオクテット、キャッシュの有効期限間隔、署名タイプブロック（存在する場合）、および署名（セクション7.2を含むConfism1またはcundile2メッセージの暗号化された部分をカバーするMacも含まれています（セクション7.2）） （存在する場合）。レスポンダーの場合：
confirm_mac = MAC(mackeyr, encrypted part of Confirm1)
cundile_mac = mac（mackeyr、cundile1の暗号化された部分）
For the initiator:
イニシエーターの場合：
confirm_mac = MAC(mackeyi, encrypted part of Confirm2)
cundile_mac = mac（mackeyi、cundile2の暗号化された部分）
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 AUTHタグを使用）を送信すると、交換が完了します。イニシエーターは、最初の有効なSRTPメディアをResponderからのconf2ackの受信に相当するものとして扱う必要があります。Responderは、Responderが選択した順序で（または「クラウド」がそれらを配信することを選択した順序であれば、SRTPメディア、conf2ack、またはその両方でcusment2に応答する場合があります。
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またはPresharedモードのいずれかです。
(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) セクション4.9で説明されているように、2つの確認メッセージで受信されたキャッシュの有効期限間隔の値に応じて、キャッシュを更新しないシナリオがいくつかあります。
(3) The responder MUST receive the initiator's Confirm2 message before updating the responder's cache.
(3) レスポンダーは、レスポンダーのキャッシュを更新する前に、イニシエーターのCONDICE2メッセージを受信する必要があります。
(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) イニシエーターは、イニシエーターのキャッシュを更新する前に、Responderのconf2ackメッセージまたはResponderの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を破棄し、古いRS1をRS2にコピーします。古いRS1は、一方の当事者が自分のRS1を更新した後、他の当事者が自分のRS1を更新するのに十分な情報を持っている前にセッション中断のリスクがあるため、RS2に保存されます。それが起こった場合、RS2を使用して次のセッションでキャッシュ同期を取り戻すことができます（セクション4.3ごと）。これは、有名な2人の将軍の問題[ビザンチン]を軽減します。古いRS1値は、Presharedモードでは保存されません。
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キー派生関数を介してS0から新しいRS1値を計算します（セクション4.5.1）：
rs1 = KDF(s0, "retained secret", KDF_Context, 256)
rs1 = kdf（s0、 "Retained Secret"、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 ID [RFC4474]以上のシグナリングにおけるA = ZRTP-HASHのエンドツーエンドの整合性保護送信によって完全にサポートされている場合にのみ、Dan WingのSIPメディアパスを使用したアイデンティティ[sip-identity]。これにより、人間の援助なしで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セッションキーZrtpsessは、使用しているすべてのZRTPメディアストリームが終了した場合にのみ削除されます。
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は、共有秘密から派生したMackeyで計算された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-OCTETの「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.
クリアラック応答を受け取らないGoClearメッセージはresする必要があります。GoClearメッセージが悪いMACで受信された場合、クリアラックを送信してはならず、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エンドポイントは、セッションがSRTPに切り替えられた後、GoClearメッセージを受け入れることを選択できます。これにより、セッションがRTPに戻ることができます。これは、許可されたクリアフラグ（a）を設定することにより、CONDIME1またはCONDICE2メッセージ（図10）に示されています。エンドポイントが確認メッセージに許容クリアフラグを設定すると、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パケットの送信を停止し、応答してクリアックを生成します。また、セクション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バインディングが期限切れになったりするのを防ぐために、ユーザーからの確認を待っている間、クリアラックメッセージが定期的に（5秒ごとに）resすることがあります。ユーザーから通知の確認が受け取られた後、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パケットの送信を停止します。クリアックが受信されると、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.
GoClearの再送信が使い果たされる前にクリアラックを受け取っていない場合、セクション4.7.2.1で定義されているように、重要な資料が削除されます。
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.
ユーザーがSRTPメディアからRTPメディア（クリアモード）に移行した後、通常はGOセキュアボタンを押して手動でアクティブ化してセキュアモードに戻ることを決定する場合があります。その場合、新しいCommitメッセージを送信することにより、ボタンを押したパーティーによって新しい安全なセッションが開始され、新しいセッションキーネゴシエーションにつながります。2つの当事者はすでにコールの開始時にそれを行っているため、互いのZRTP機能を発見しているため、別のハローメッセージを送信する必要はありません。ユーザーは、昔ながらの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メッセージの受信機によって消去される必要があります。同じ重要な破壊は、クリアラックを受け取ったときに、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:
SIPセッションの終了時に消去されるすべての重要な資料は、Zrtpsessの単一を例外として、セクション4.7.3で説明するように消去する必要があります。この場合、Zrtpsessは他の重要な材料とは異なる方法で破壊されます。両当事者は、ZRTPSESSをそれ自体のKDF由来の非変性機能に置き換えます。
ZRTPSess = KDF(ZRTPSess, "New ZRTP Session", (ZIDi || ZIDr), negotiated hash length)
zrtpsess = kdf（zrtpsess、 "new zrtp session"、（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.
Zrtpsessは、セッションがオーディオストリームとビデオストリームの両方に対して個別のGoClearメッセージを生成すると2回交換され、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.
重要な資料の破壊は、完全な前方秘密（PFS）の要件を満たしていますが、それでもZrtpsessの新しいバージョンを保持しているため、ユーザーは、MultiStreamモードを使用して別のDiffie-Hellman計算を実行せずに同じセッション中にセキュアモードを再開できます。、両方のzrtpエンドポイントで同じ値でzrtpsessの存在を必要とし、想定しています。GoClearの後の新しい重要な交渉は、MultistReamのコミットメッセージを使用する必要があります。
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.
注：MultiStreamモードは、新しいハッシュチェーンの生成と新しいシグナリング交換の生成を必要としないため、新しいハローハッシュ値を交換する必要がないため、MultiStramモードが推奨されます。
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セッションキー資料は、コールの終了時に両当事者によって消去される必要があります。特に、破壊されたキー材料には、SRTPセッションキーと塩、SRTPマスターキーと塩、およびZRTPSESSおよびS0を含む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 Secret ExponentsおよびNoncesには、暗号化キー資料に乱数を使用します。乱数が必要なときはいつでも、次の基準のすべてを満たす必要があります。
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クライアントのエントロピーの可能なソースの1つは、マイクノイズです。暗号化グレードの乱数と適切なエントロピーを収集するためのガイダンスの詳細な説明については、[RFC4086]および「実用的な暗号」[ファーガソン]の第10章を参照してください。生のエントロピーは、決定論的なランダムビットジェネレーター（DRBG）を介して蒸留し、処理する必要があります。DRBGの例は、[Nist-SP800-90]、[Ferguson]、および[RFC5869]に見られる場合があります。ランダムな暗号化キーマテリアルを生成するための基礎として物理的環境から真のエントロピーを使用しないと、セキュリティの悲惨な喪失につながります。
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は、ZIDを実装する最も簡単な方法です。ただし、Calleeごとに別のZIDの限界まで、複数のZIDを使用するための実装が特に排除されていません。これにより、異なるパーティーのペア間の他の関連付けには適用されない長寿命の「関連性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を無効にするプロトコルメカニズムはありません。ZIDを変更したいエンドポイントは、単に新しいものを生成して使用を開始します。
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.
キャッシュ間隔は、CONDICE1およびciend2メッセージで交換されます（図10）。両方のエンドポイントで使用される実際のキャッシュ間隔は、CONDICE1およびciend2メッセージの値の最小値です。0秒の値は、新しく計算された共有秘密をキャッシュに保存しないことを意味し、キャッシュエントリが以前の呼び出しから既に存在する場合、保存されたキャッシュ間隔を0に設定する必要があります。キャッシュの有効期限間インターバルで、キャッシュエントリは既に定義されておらず、新しいキャッシュエントリは作成されません。0xffffffffの値は、秘密が無期限にキャッシュされるべきであり、推奨値であることを意味します。ZRTP ExchangeがMultiStreamモードの場合、CONSIFS1およびCHANDICE2のフィールドは0xFFFFFFFFに設定され、無視されます。キャッシュは更新されません。
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).
有効期限間隔が両方のエンドポイントによって適切に合意されていない場合、明らかなキャッシュの不一致により、後でMITM攻撃の誤ったアラームが発生する可能性があります（セクション4.3.2）。
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エンドポイントが共有秘密のキャッシュをサポートしていない場合、キャッシュの有効期限間隔をゼロに設定する必要があり、SAS検証（v）フラグ（セクション7.1）をfalseに設定する必要があります。さらに、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セキュリティ登録（セクション7.3.1）メカニズムを含むPBX信頼できる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 Magic Cookieは、ZRTPパケットを一意に識別する32ビット文字列で、値0x5A525450を持っています。
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.
この形式は、最初の2つのビットがゼロであるため、非RTPとして明確に識別できます。これは、有効なRTPバージョン番号ではないRTPバージョン0のように見えます。マジッククッキーは異なるため、スタンとはっきりと区別できます。12の未使用のビットはゼロに設定されており、受信したときに無視する必要があります。この仕様の初期バージョンでは、ZRTPメッセージがRTPヘッダー拡張機能にカプセル化され、ZRTPがRTPの同名のバリアントになりました。後のバージョンでは、パケット形式が変更され、RTPと構文的に区別できるようになりました。
The ZRTP messages are defined in Figures 3 to 17 and are of variable length.
ZRTPメッセージは、図3〜17で定義されており、長さは可変です。
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.
ZRTPプロトコルは、各ZRTPパケットでRFC 4960、付録B [RFC4960]で定義されているように、32ビット環状冗長チェック（CRC）を使用して、伝送エラーを検出します。ZRTPパケットは通常、UDPによって輸送されます。UDPは、独自の組み込みの16ビットチェックサムを整合して整合しますが、ZRTPはそれに依存していません。これは、ZRTPメッセージの検出されない伝送エラーの影響のためです。たとえば、DH Exchangeの検出されないエラーは、中間の積極的な攻撃のように見える可能性があります。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は、ZRTPヘッダーとZRTPメッセージを含むが、CRCフィールドを含むものではなく、図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-OCTET（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は、このASCIIエンコードを使用してデバッグを簡素化し、「Wireshark（Ethereal）フレンドリー」にします。
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エンドポイントは、Hello、Helloack、Commid、DHPART1、DHPART2、CONDIM1、CONDIME2、CONF2ACK、SASRELAY、RELAYACK、ERROR、ERRORACK、およびPINGACKメッセージタイプをサポートする必要があります。ZRTPエンドポイントは、GoClear、クリアラック、および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アルゴリズムは、ハローメッセージ（セクション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 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エンドポイントは、SHA-256のハッシュタイプをサポートする必要があります[FIPS-180-3]。SHA-384をサポートする必要があり、ECDH-384を使用する場合はサポートする必要があります。NIST SHA-3ハッシュ[SHA-3]など、追加のハッシュタイプを使用できます。ハッシュタイプは、SRTP認証タグで使用されるハッシュアルゴリズムではなく、ZRTPキーエクスチェンジ全体で使用されるハッシュアルゴリズムを指すことに注意してください。
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で定義されているデジタル署名で使用されるハッシュには適用されません。たとえば、交渉されたハッシュタイプがSHA-256であっても、デジタル署名は、楕円曲線デジタル署名アルゴリズム（ECDSA）P-384署名キーが使用される場合、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に記載されている特別なケースを除き、ZRTPプロトコル全体で使用される他のすべてのハッシュとMACは、ネゴシエートされたハッシュタイプを使用します。
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コンストラクト、たとえばSkein Hash関数[Skein]に基づいていない独自の組み込みMACが含まれる場合があります。NistがSHA-3の勝者のようなハッシュを選択した場合、ハッシュタイプ「N256」、および「N384」は、関連するHMACをネゴシエートされたMACとして使用します。実装者がSkeinとその組み込みの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-hash属性のhello hash。
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パケットには、ZRTPバージョン1.10のSHA-256に基づいた2つのA = ZRTP-HASH SDP属性をリストする場合があります。
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]で定義されています。AESキー長の選択は、セクション5.1.5で説明されているように、キー契約タイプに結合されます。
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.
AEと同じブロックサイズとキーサイズの他のブロック暗号がサポートされる場合があります。実装されている場合、それらは、同じ動作モードとキーサイズで、AESの代わりにZRTPまたはSRTPのどこでも使用できます。特に、[RFC3711]および[RFC6188]でAES-CMを置き換えるカウンターモード、およびCFBモードでは、確認メッセージの一部（図10）とSASRELAYメッセージ（図16）を暗号化するためのCFBモードです。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].
すべてのZRTPエンドポイントは、[RFC3711]で定義されている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エンドポイントは、Skein Hash関数[Skein]に基づいて、32ビットおよび64ビットのSRTP認証タグをサポートできます。Skein-512-MACキーの長さは、このアプリケーションの256ビットに固定されており、出力の長さは調整可能です。Skein Macは、[Skein]のセクション2.6および4.3で定義されており、HMACコンストラクトに基づいていません。Skeinの参照実装は、[skein1]で見つけることができます。Skeinベースの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], 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).
Skein Macキーは、AES-CM PRFまたは擬似ランダム関数とも呼ばれるSRTPキー導出関数によって計算されます。これは、選択したSRTP AESキー長に応じて、[RFC3711]または[RFC6188]で定義されます。Skein 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]がRFCとして公開されている場合、SRTPのAES-GCMおよびAES-CCMが利用可能になると予想されることに注意する必要があります。実装者がこれらのモードが利用可能になったときに使用したい場合は、新しいAUTHタグタイプを追加する必要があります。
All ZRTP endpoints MUST support DH3k, SHOULD support Preshared, and MAY support EC25, EC38, and DH2k.
すべてのZRTPエンドポイントは、DH3Kをサポートし、Presharedをサポートする必要があり、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エンドポイントがオーディオやビデオなどの複数の同時メディアストリームをサポートする場合、Multistream（セクション4.4.3）モードをサポートする必要があります。また、ZRTPエンドポイントがGoClearメッセージ（セクション4.7.2）をサポートする場合、2つの当事者が明確になった後に安全な状態に戻ることを選択した場合（セクション4.7.2.1で説明したように）、Multistreamをサポートする必要があります。
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.
有限フィールドDiffie-Hellmanの場合、Zrtpエンドポイントは、[RFC3526]で定義されたDHパラメーターを次のように使用する必要があります。DH3Kは、3072ビットモジュラー指数グループ（MODP）を使用します。DH2Kは2048ビットMODPグループを使用します。DHジェネレーターGは2です。ランダムDiffie-Hellman Secret Exponentは、AESキーの長さの2倍の長さでなければなりません。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]からのものです。使用される曲線は[NSA-Suite-B]からのもので、[FIPS-186-3]で定義されたECDSAと同じ曲線を使用し、RFC 5114、セクション2.6〜2.8 [RFC5114]にもあります。ECDHテストベクトルは、RFC 5114、付録A.6からA.8 [RFC5114]に記載されている場合があります。検証手順は、[NIST-SP800-56A]、セクション5.6.2.6、方法3、楕円曲線暗号化（ECC）部分検証からのものです。曲線上のポイントのxとyの両方の座標は、それぞれECDH公共値の前半と後半に送信されます。ECDH結果は、SP 800-56Aで指定されているように、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は、[NIST-SP800-131A]の表4で、DH-2048は2013年まで安全であると主張しています。DH2Kのセキュリティは、ZRTPの主要な連続性機能を実装することで増強できます（セクション15.1）。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キーが共有秘密といくつかの非CE材料から導出される2つの非DHモード、MultistreamとPresharedも定義します。
The table below lists the pv length in words and DHPart1 and DHPart2 message length in words for each Key Agreement Type Block.
以下の表には、PVの長さをWordsとDHPART1およびDHPART2メッセージの長さを、各キー契約タイプブロックの単語で示します。
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をサポートする必要があり、Short認証文字列およびその他のSASレンダリングスキームのBase256レンダリングスキームをサポートする場合があります。SASValueの計算方法については、SASの使用方法についてはセクション7を参照してください。
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 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].
表6. SASタイプの「B256」のSASタイプの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:
SASタイプの「B32」の場合、32ビットのSASValueの最も重要な（左端の）20ビットは、Base32エンコードの形としてレンダリングされます。SASValueの左端20ビットの結果、最初に最も重要なQuintetが両方のZRTPエンドポイントにレンダリングされる4つのBase32文字が得られます。これは、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とは異なり、（Bryce Wilcox-O'Hearnによって設計され、人間のユーザーが最小限の曖昧さで操作するのに便利な形式でビットシーケンスを表すように設計されました。異常に並べ替えられた文字順序は、Quintetの境界で終了しないビットシーケンスを使用する他のアプリケーション向けに設計されました。
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-OCTETの署名タイプブロックと付随する署名ブロックはオプションであり、確認メッセージ（図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 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.署名タイプブロック値署名および署名キー形式の追加詳細は、セクション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メッセージは、プリアンブル値0x505Aで始まり、32ビット単語で16ビットの長さから始まります。この長さには、ZRTPメッセージ（前文と長さを含む）のみが含まれますが、ZRTPパケットヘッダーまたはCRCは含まれません。8-OCTETメッセージタイプは、長さフィールドに従います。
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.
次に、ZRTPプロトコルのバージョン（Ver）を含む4文字の文字列があります。これは、この仕様の「1.10」です。次に、クライアント識別子文字列（CID）があります。これは4ワードの長さで、ZRTPソフトウェアのベンダーとリリースを識別します。256ビットハッシュ画像H3はセクション9で定義されています。次のパラメーターは、セクション4.9で定義されているZRTPエンドポイントの96ビットロングの一意の識別子であるZIDです。
The next four bits include three flag bits:
次の4つのビットには、3つのフラグビットが含まれます。
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 署名対応フラグは、セクション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).
o MITMフラグ（M）は、このハローメッセージがデバイス（通常はPBX）から送信された場合にのみ、SASRELAYメッセージを送信する機能がある場合にのみ、ブール値です（セクション5.13）。
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.
o パッシブフラグ（P）は通常、falseに設定されているブール波であり、このハローメッセージがコミットメッセージを送信しないように構成されているデバイスから送信された場合にのみTRUEに設定されます（セクション5.4）。これは、安全なセッションを開始できないことを意味しますが、レスポンダーとして機能する可能性があります。
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 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.
次は、サポートされているハッシュアルゴリズム、暗号アルゴリズム、SRTP AUTHタグタイプ、主要な合意タイプ、およびSASタイプのリストです。リストされているアルゴリズムの数は、各タイプのリストがリストされています：HC =ハッシュカウント、CC = CIPHEカウント、AC = AUTHタグカウント、KC =キー契約カウント、およびSC = SASカウント。これらのアルゴリズムの値は、表2、3、4、5、および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メッセージの再送信を停止します。形式を以下の図に示します。commedメッセージを迅速に送信する準備ができている場合、イニシエーターによってHellocackの代わりにコミットメッセージが送信される場合があります。
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：Hellockメッセージ形式
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メッセージを受け取った後に重要な契約プロセスを開始するために送信されます。つまり、HelloメッセージとHelloackメッセージの両方を受信した後にのみ送信できます。コミットメッセージには3つのサブタイプがあり、その形式は図5、6、および7に示されています。
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.
コミットメッセージには、メッセージタイプブロック、次にセクション9で定義されている256ビットハッシュ画像H2が含まれます。次のパラメーターは、ZRTPエンドポイントの96ビットロングの一意の識別子であるイニシエーターのZIDです。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.
次に、イニシエーター（Hash、Cipher、Auth Tag Type、Key Asmort、SASタイプ）によって選択されたアルゴリズムのリストがあります。DHコミットの場合、ハッシュ値HVIは、セクション4.4.1.1で説明されているように、イニシエーターの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：PRESHAREDコミットメッセージフォーマット
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の表に含まれています。MultistReamモードとPresharedモードの両方で、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で計算）です。最初の2つのRS1IDRとRS2IDRは、64ビットに切り捨てられたレスポンダーの2つの保持された共有秘密のハッシュです。次に、64ビットに切り捨てられた、応答者の補助区分（セクション4.3で定義）のハッシュである補助金があります。最後のパラメーターは、セクション7.3.1で定義されている信頼できるMITM PBX共有シークレットPBXSecretのハッシュです。
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の表に含まれています。MultistReamモードとPresharedモードの両方で、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で計算）です。最初の2つのRS1IDIとRS2IDIは、64ビットに切り捨てられたイニシエーターの2つの保持された共有秘密のハッシュです。次に、64ビットに切り捨てられたイニシエーターの補助区分（セクション4.3で定義）のハッシュであるAuxSecretidiがあります。最後のパラメーターは、セクション7.3.1で定義されている信頼できるMITM PBX共有シークレットPBXSecretのハッシュです。
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.
SRTPセッションキーとパラメーターがネゴシエートされた後、有効なDHPART2メッセージに応じて、ResponderによってCONDIM1メッセージが送信されます。CONDIME2メッセージは、CONDIFE1メッセージに応じてイニシエーターによって送信されます。形式を図10に示します。メッセージには、メッセージタイプブロック "Confism1"または "Confism2"が含まれています。次に、メッセージの暗号化された部分に計算されたMacであるCONDICE_MACがあります（図10の「====」で囲まれています）。このCONDIM_MACは、セクション4.6に従ってキー化および計算されます。次の16個のオクテットには、CFB初期化ベクトルが含まれています。メッセージの残りの部分は、CFBを使用して暗号化され、CONDIF_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ビットは使用されておらず、送信時にゼロに設定する必要があり、CONDIM1またはCONDIME2メッセージで受信した場合は無視する必要があります。
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ビットには、署名長が含まれています。SAS署名（セクション7.2で説明）が存在しない場合、すべてのビットはゼロに設定されます。署名長は言葉で、署名タイプブロックが含まれています。計算された署名のオクテット数が4の倍数ではない場合、ゼロを追加してワード境界にパッドアウトします。署名が存在しない場合、CONDIME1またはciend2メッセージの全長が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で定義されているブールビットです。Allow Clearフラグ（a）は、セクション4.7.2で定義されているブールビットです。開示フラグ（d）は、セクション11で定義されているブールビットです。キャッシュの有効期限間隔は、セクション4.9で定義されています。
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は、CFB IVの後に始まるCONDICE1メッセージの部分をメッセージの最後まで暗号化するために使用されます（暗号化された領域は、図10の「====」で囲まれています）。
The responder uses the zrtpkeyr to encrypt the Confirm1 message. The initiator uses the zrtpkeyi to encrypt the Confirm2 message.
ResponderはZrtpkeyrを使用して、cundile1メッセージを暗号化します。イニシエーターはZrtpkeyiを使用して、cundile2メッセージを暗号化します。
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：CONDIM1およびCOMIND2メッセージ形式
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メッセージは、有効な確認2メッセージに応じて応答者によって送信されます。conf2ackのメッセージ形式を以下の図に示します。conf2ackの受領は、cundile2メッセージの再送信を停止します。Responderからの最初のSRTPメディア（有効なSRTP AUTHタグを使用）は、CONDIF2メッセージの再送信も停止することに注意してください。
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：メッセージメッセージ形式をfackします
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.
エラーコードの定義された16進数を以下の表に示します。
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メッセージのサポートはプロトコルでオプションであり、SRTPからRTPに切り替えるために送信されます。形式を以下の図に示します。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.
クリアックメッセージのサポートはプロトコルではオプションであり、GoClearの受領を確認するために送信されます。GoClearメッセージからのClear_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=3 words |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type Block="ClearACK" (2 words) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ClearACK Message Format
図15：クリアックメッセージ形式
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の残りの主要な交渉が完了した後にのみ送信できます。信頼できるMITMが相手との重要な交渉を終了した後にのみ送信できます。これは、相手のSASが中継されているためです。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をレンダリングしてはなりません。リラヤックはまだ送信されていますが、エラーメッセージは送信されません。
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メッセージ形式を図16に示します。メッセージには、メッセージタイプブロック「SASRELAY」が含まれています。次に、メッセージの暗号化された部分に計算されたMacがあります（図16の「====」で囲まれています）。このMACは、確認メッセージのcidence_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ビットには、署名長が含まれています。信頼できるMITMは、セクション7.2で説明されているように、信頼できる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）は、セクション11で定義されているブールビットです。許容フラグ（a）は、セクション4.7.2で定義されているブールビットです。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ビットワードには、リレーしたSashashのSASレンダリングスキームが含まれています。これは、信頼できるMITMの反対側の相手が使用する同じレンダリングスキームです。セクション7.3では、PBXがZRTPクライアントがPBXを信頼できるMITMと見なすかどうかを決定する方法について説明します。PBXがZRTPクライアントがPBXを信頼すると判断した場合、次の8つの単語には相手から中継されたSashashが含まれています。Sashashの最初の32ビットワードには、指定されたSASレンダリングスキームを使用してユーザーにレンダリングできるSASValueが含まれています。このMITMを信頼していないZRTPクライアントにこのSasRelayメッセージが送信されている場合、Sashashは受信者によって無視され、PBXによってZerosに設定される必要があります。
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は、メッセージの最後までCFB IVの後に始まるSASRELAYメッセージの部分を暗号化するために使用されます（暗号化された領域は、図16の「====」で囲まれています）。
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.
ZRTPキーネゴシエーション中に信頼できるMITMがイニシエーターまたはレスポンダーの役割を果たしたかどうかに応じて、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.
リラヤックメッセージは、有効なSASRELAYメッセージに応じて送信されます。リラヤックのメッセージ形式を以下の図に示します。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：リラヤックメッセージ形式
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プロトコルの残りの部分とは無関係です。pingメッセージを生成するためにzrtpエンドポイントは必要ありませんが、すべての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プロキシは、特定のZRTPエンドポイントに接続されているRTPメディアストリームを整理する手段としてPingメッセージを送信する場合があります。pingメッセージは、zrtpプロキシによってのみ生成されます。どちらの当事者がZRTPプロキシでない場合、pingメッセージは発生しません。Pingの再送信の動作については、セクション6で説明します。
The Ping message (Figure 18) contains an "EndpointHash", defined in Section 5.16.
pingメッセージ（図18）には、セクション5.16で定義されている「エンドポインタッシュ」が含まれています。
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 Responderによってサポートされている場合、そのバージョンが受信される形式の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.
ピンガックメッセージは、pingに応じてのみ送信されます。zrtpエンドポイントは、pingackメッセージを使用してpingに応答する必要があります。要求されたPingackのバージョンは、Pingメッセージに含まれています。そのバージョン番号がサポートされている場合、そのバージョンに一致する形式のPingackを送信する必要があります。それ以外の場合、PINGのバージョン番号がサポートされていない場合、Ping Responderに知られている最高のサポートバージョンの形式でPingackを送信する必要があります。この仕様ではバージョン「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メッセージのエンドポインタッシュとは異なる独自の64ビットのエンドポインタッシュがあります。コールの2人の参加者が同じEndpointhashを持っていることは非常にありそうにないこと、そしてエンドポインタッシュが呼び出しの間に持続的な値を維持することが必要です。ZRTP対応VOIPクライアントなどの通常のZRTPエンドポイントの場合、Endpointhashは単なる切り捨てられたZIDになります。その背後に複数のエンドポイントがあるPBXなどのZRTPエンドポイントの場合、エンドポインタッシュは、その背後にある各エンドポイントの明確な値でなければなりません。Endpointhashは、PBXの背後にある実際のエンドポイントまたは電話についてユニークなものと合わせて、ZRTPエンドポイントのZIDの切り捨てられたハッシュであることをお勧めします。これは、アプリケーション環境でより容易に利用できる方が、電話のSIP URI、PBX拡張番号、または電話のローカルIPアドレスである場合があります。
EndpointHash = hash(ZID || SIP URI of the endpoint)
endpointhash = hash（zid || sip uri of the endpoint）
EndpointHash = hash(ZID || PBX extension number of the endpoint)
endpointhash = hash（zid || pbx拡張エンドポイントの数）
EndpointHash = hash(ZID || local IP address of the endpoint)
endpointhash = hash（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接続を終了する単純なケース、または電話会議で複数のVOIP電話のZRTP接続を終了するPBXのより複雑なケースで、すべてがPBXのZIDを共有しますが、個別のものであるが、別々PBXの背後にあるIPアドレス。同じハッシュ関数が両方の当事者が使用する要件はありません。
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.
ピンガックメッセージには、ピンガックの送信者のエンドポインタイと、pingの送信者のエンドポインタッシュが含まれています。pingパケット（図2）からZRTPヘッダーで受信したソース識別子（SSRC）が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は、2つの再送信タイマー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.
すべてのメッセージ再送信は、Nonces、Public Valuesなどを含む最初のメッセージと同一でなければなりません。それ以外の場合、メッセージシーケンスのハッシュは同意しない場合があります。
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.
Hello ZRTPメッセージは、T1秒から始まり、再送信ごとに2倍になる間隔で再送信され、200ミリ秒のキャッピングが行われます。T1の推奨初期値は50ミリ秒です。Helloメッセージはあきらめる前に20回再送信されます。つまり、Helloメッセージの再試行スケジュール全体が3.75秒（50 100 18*200 ms）後に使い果たされます。Helloの再送信は、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.
ポストヘロZRTPメッセージは、セッションイニシエーターによってのみ再送信されます。つまり、commit、dhpart2、およびconfirm2のみが再送信されます。Responderから最初のSRTPメディア（有効なSRTP AUTHタグを使用）を受信することにより、CONSIFS2メッセージの再送信も停止できることに注意してください。
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メッセージは、どちらの当事者がセッション全体のイニシエーターであるかに関係なく、いずれかの当事者によって開始および再送信され、相手によって応答される場合があります。対応する応答メッセージクリアラック、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秒と2倍に始まる間隔で再送信されます。T2の推奨初期値は150ミリ秒です。各非ヘッロメッセージは、あきらめる前に10回再送信されます。つまり、9.45秒（150 300 600 7*1200ミリ秒）後に再試行スケジュール全体が使い果たされます。イニシエーターのみが再送信を実行します。下の表に示すように、各メッセージには再送信を停止する応答メッセージがあります。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 DH計算を実行するのに時間がかかりすぎるリスクがあるゆっくりと重度のロードされたZRTPエンドポイントは、コミットメッセージの代わりにHelloackメッセージを使用して、相手からHelloに返信する必要があります。
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.
o ZRTPエンドポイントに、相手がハローメッセージまたはpingメッセージを受信するか、シグナリングレイヤーでハローハッシュを受信することにより、相手がZRTPエンドポイントであるという証拠がある場合、少なくとも12秒にスパンする独自のHello Retryスケジュールを拡張する必要があります。再試行。この拡張されたHello Retryスケジュールがhellocackまたはコミットメッセージを受信せずに使い果たされた場合、ピアからの遅いコミットメッセージはまだ受け入れられるはずです。
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.
ZRTPには、通常はUDPよりもRTPと一緒に運ばれるため、独自の再送信スケジュールがあります。異常な場合、RTPは、独自の組み込み再送信メカニズムを提供するTCPやDCCPなどの非UDPトランスポートを実行できます。ZRTPエンドポイントが、メディアリレーが関与している場合、TCPが使用されていることを検出するのは難しい場合があります。ZRTPエンドポイントはUDPのみを送信している可能性がありますが、旅の一部でUDPからTCPに変換するメディアパスに沿ってメディアリレーがある場合があります。または、ZRTPエンドポイントがTCPを送信している場合、メディアリレーはTCPからUDPに変換されている可能性があります。野生ではこれについての経験的観察がありました。TCPが使用される場合、ZRTPとTCPは一緒にいくつかの余分な再送信を生成する可能性があります。TCPチャネルに接続するとZRTP再送信スケジュールを排除することでこの効果を回避するのは魅力的ですが、TCPがリモートZRTPエンドポイントに至るまでずっとない可能性があるため、プロトコルの障害が危険にさらされます。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.
コミットメッセージを受信したが、confirm2メッセージを受信した後、ZRTPレスポンダーがZRTPメッセージを10秒以上受信しない場合、レスポンダーはプロトコルタイムアウトエラーメッセージを送信して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は、文字列を声に出して読んでいる人間のユーザーが口頭で比較することができます。また、CONDICE1またはCONDIME2メッセージで交換されたオプションのデジタル署名（セクション7.2で説明）を検証することで比較できます。
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 Exchange（セクション4.4.1.1）でのハッシュコミットメントの使用により、攻撃者は攻撃で正しいSASを生成するために1つの推測のみに制限されます。つまり、SASは非常に短くなります。たとえば、16ビットのSASは、攻撃者に65536のうち、検出されていない可能性が1つだけに提供されます。ハッシュのコミットメントにより、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.
通話ごとに計算されたSAS値は1つだけです。これが、セクション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検証済みのフラグは、次のセッションのCONDICE1およびciend2メッセージ（図10）で安全に交換されます。言い換えれば、各当事者は、現在のセッションの確認メッセージで、前のセッションからSAS検証済みフラグを送信します。ユーザーが設定できるようにするためにユーザーインターフェイスに複雑さを追加する必要があるため、SAS検証済みフラグを設定しないZRTPエンドポイントを持つことは完全に合理的です。SAS検証済みのフラグは設定する必要はありませんが、クライアントソフトウェアが利用できる場合、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が以前のすべてのセッションに存在していたに違いないことを意味します。これは確かに機知に富んだ攻撃者です。それはまた、彼がいつでもあなたの呼び出しの1つへのMITMとしての参加をやめた場合、プロトコルはキャッシュされた共有秘密がもはや有効ではないことを検出することを意味します。アリスと攻撃者の間、そして攻撃者とボブの間の間の間。キャッシュされた共有秘密の連続性により、彼が進行中の関係に自分自身を挿入したときと彼が去るときにMITMを検出することができます。また、攻撃者がコールの長い系統にとどまることを試みますが、1回の不在着信でも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の確認が成功し、ソフトウェアがSAS検証フラグ（V）を設定します（キャッシュされた共有秘密と一緒に）次の呼び出しでSAS手順を実行する必要性を解消します。追加のユーザーインターフェイス要素を提供して、ユーザーが実際のSASの不一致を検出したソフトウェアに伝えさせることができます。これはMITM攻撃を示しています。その後、ソフトウェアは適切なアクションを実行し、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.
ほとんどのアプリケーションでは、PKIが支援するデジタル署名の追加の複雑さを回避することが望ましいため、ZRTPはそれを必要としないように設計されています。それにもかかわらず、一部のアプリケーションでは、2人の人間のユーザーがSASを口頭で比較する手配をするのは難しいかもしれません。または、アプリケーションはすでに既存の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を人間の参加なしにチェックできます。SASに署名され、sign1、cundile2（図10）、またはsasrelay（図16）のメッセージ内で送信されます。署名タイプ（セクション5.1.7）、署名の長さ、および署名の作成（またはそれへのリンク）の作成に使用されるキーはすべて、署名とともに送信されます。署名は、SASValueが導出されたSASハッシュ結果（Sashash）全体で計算されます。暗号化されたCONDICE1、CONDIME2、またはSASRELAYメッセージで交換された署名を使用して、ZRTP交換を認証することができます。署名は、DHまたはECDH ZRTP Exchangeの初期メディアストリームでのみ送信され、MultiStreamモードではありません。
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を計算しているため、確認メッセージに送られません。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）によって決定され、デジタル署名で使用されるハッシュはデジタル署名アルゴリズムによって個別に定義されます。たとえば、SashashはSHA-256に基づいている場合がありますが、ECDSA P-384キーが使用される場合、デジタル署名はSHA-384を使用する場合があります。
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ビットに切り捨てられている）が署名ハッシュよりも短い場合、ハッシュのコミットメントが攻撃者がサシャシュの衝突を検索することを妨げるため、セキュリティは弱まりません。
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は、断片化されたUDPパケットを破棄し、ZRTP交換が失敗する可能性があります。ZRTPエンドポイントがUDPの断片化を引き起こす場合、署名の送信を避けることをお勧めします。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-OCTET署名タイプブロックの後の最初のフィールドは、OpenPGP署名です。この署名の形式とそれを作成するアルゴリズムは、[RFC4880]によって指定されます。署名は、完全なOpenPGPパケット構文に囲まれたRFC 4880、セクション5.2.3で指定されているように、バイナリ形式の完全なOpenPGPバージョン4署名（RADIX-64ではなく）で構成されています。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になると利用可能になると予想されることに注意する必要があります。ZRTPでのECDSAシグネチャの使用は、[FIPS-186-3]で定義されているように、P-224、P-256、およびP-384以外のECDSAキーサイズを使用して署名を生成してはなりません。
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 Trustモデルを使用してその有効性ステータスを決定するのは、署名の受信者次第です。
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-OCTET署名タイプブロックの後の最初のフィールドは、署名を作成した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が指定されている場合、署名は16ワード（64オクテット）、それぞれ32個のオクテットをRおよびSで埋めます。ECDSA P-384が指定されている場合、署名は24ワード（96オクテット）、それぞれ48個のオクテットをRおよびSで埋めます。
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.
PKIを使用してSASに署名する公開キーをバックアップすることは厳密に必要ではありません。たとえば、自己署名の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を口頭で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に登録されている電話の場合、信頼できる自動化されたプロビジョニングプロセスを使用して、PBXの公開鍵でプロビジョニングされる場合があります。PKIがなくても、携帯電話は、信頼できるプロビジョニングメカニズムによって電話にプロビジョニングされたため、公開キーが正しいものであることを知っています。これにより、携帯電話は、PBXには、口頭SAS比較を行うためにPBXに人間がいないため、PBXが一般的に提供するいくつかの自動化されたサービスに簡単にアクセスできます。同じプロビジョニングを使用して、PBXSecretを電話にプリロードすることができます。これについては、セクション7.3.1で説明します。
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）の両当事者の口頭比較は、この仮定に依存します。しかし、Asteriskなどの一部のPBX環境では、PBXが信頼できるMITMとして機能する使用法シナリオがあります。つまり、個別のセッションキーと個別のSASを持つ2つの連続したZRTP接続があります。
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に登録されているZRTP対応VOIP電話があることを想像してください。そうすれば、PBXの拡張と見なされます。電話がPBXに関連付けられていないアリスは、外側からPBXをダイヤルする可能性があり、ZRTP接続が彼女の電話とPBXの間でネゴシエートされます。次に、PBXの会社ディレクトリからBobの拡張機能を選択します。PBXは、ボブの電話（インターネットを介してPBXから何マイルも離れたオフサイトである可能性があります）に電話をかけ、PBXとBoBの電話の間で別のZRTP接続がネゴシエートされます。2つのZRTPセッションには異なるセッションキーと異なるSASSがあり、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リレーをAlice/PBX SASにBOBにリレーすることにより、この問題を解決するメカニズムがあり、PBX/BOB ZRTP交渉が完了した後に送信されるセクション5.13で定義されている特別なSASRELAYメッセージでBOBに送信します。確認メッセージの後。特別な信頼できるMITM（SASRELAYメッセージの受信者によって信頼される）として機能するPBXのみがSASを中継します。SASRELAYメッセージは、確認メッセージの保護方法と同様に、含まれているMacを介したリレーのSASが改ざんから保護されます。BobのZrtp対応電話は、Bobの電話が以前にPBXを信頼するように構成されていたために、レンダリングのためにリレーしたSASを受け入れます。PBXとのこの特別な信頼関係は、特別なセキュリティ登録手順を通じて確立できます（セクション7.3.1）。その登録手順の後、PBXはBOBによって特別な信頼できるMITMとして扱われます。これにより、アリスのSASがボブにレンダリングされるため、アリスとボブは口頭でそれらを比較し、他の信頼できないMITMによるMITM攻撃を防ぐことができます。
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をボブにリレーすることはできません。ボブは以前に悪人と特別な登録儀式を行っていなかったからです。リレーされたSASは、信頼できるPBXからのものではなかったため、ボブの電話でレンダリングされません。特別な信頼関係の認識は、ボブと彼の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.
信頼できるMITMキーは、初期登録時に特別なキャッシュに保存できます（ボブの電話では1回だけ実行されます）。ボブの電話のZid。登録がこの信頼できるMITMキーを確立および保存した後、PBXと電話はDHメッセージの信頼できるMITMキーのハッシュを渡す必要があるため、PBXとBoBの電話の間の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として機能すると信頼しています。他の2つのZRTPエンドポイントとのキー契約の間、PBXには、両方のエンドポイント、1つのエンドポイントのみ、またはどちらのエンドポイントでも共有された信頼できるMITMキーを持つ場合があります。PBXがどちらのエンドポイントでも共有された信頼できるMITMキーを持っている場合、PBXはSASを中継してはなりません。PBXが1つのエンドポイントのみを備えた共有信頼されたMITMキーを持っている場合、PBXは、信頼できるMITMキーを共有するエンドポイントにSASRELAYメッセージを送信することにより、SASを1つのパーティから他のパーティにリレーする必要があります。PBXが各エンドポイントと（個別の）共有MITMキーを持っている場合、PBXはSASを両方のエンドポイントではなく、1つのエンドポイントのみにリレーする必要があります。
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.
注：両方のエンドポイントを持つ信頼できるMITMキーを共有するPBXの場合、1つのエンドポイントがそれを受信する限り、どのエンドポイントがリレーした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レンダリングタイプと完全なサシャッシュが含まれています。レシーバーは、特別に信頼できるZRTPエンドポイントから来ていない場合、リレーしたSASを絶対にレンダリングしてはなりません。ZRTPプロトコルのセキュリティは、MITM攻撃者によって中継される可能性があるため、信頼されていない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はSASRELAYメッセージを未登録当事者に送信します（このPBXは信頼できるMITMとは見なされません）、SASレンダリングスキームを伝えます。しかし、それがゼロに設定するサシャシュではありません。侵入されていない当事者は、中継された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対応PBXSを介してコールをルーティングすることができます。アリスはアトランタで彼女の地元のPBXを信頼するZRTPエンドポイントであり、ボブはビロクシで彼の地元のPBXを信頼するZRTPエンドポイントであると仮定します。この呼び出しは、アリスからアトランタPBX、ビロクシPBX、ボブまでルーティングされます。アトランタはアリスがアトランタに登録されているため、アトランタ・ビロクシ・サスをアリスに中継し、ビロクシはボブがビロクシに登録されているため、アトランタ・ビロクシ・サスをボブに中継します。この例では、2つのPBXが互いに登録されているとは想定されていません。アリスとボブの両方が、同じリレーしたSAS、アトランタ・ビロクシSASを見て、口頭で比較しました。この中継スキームでは、2つの信頼できるMITMノードを通過できます。この動作は、このルールを介して互いに登録されている2つのPBXに拡張されます。両方のエンドポイントを持つ信頼できるMITMキーを共有する場合（つまり、このPBXに登録）、その1つは別のPBXです（m-flag）およびそのうちの1つは非PBXです。MITMPBXは、常に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.
PBXが信頼できるMITMとして機能することを信頼する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は2つの当事者に独自のZIDを提示し、2つの当事者のZIDを互いに覆います。たとえば、このようなPBXを介してPBXの背後にあるいくつかの異なるZrtp対応電話にルーティングされると、あらゆる場合に1つのZIDのみが呼び出し当事者に表示されます - 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.
次のセクションでは、PBXと電話の間の特別な共有秘密である信頼できるMITMキーを確立する最初の登録手順について説明し、電話が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はオーディオメディアを再生し、ユーザーがこのPBXを信頼できるMITMとして信頼するように携帯電話を構成する機会を提供します。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は、セッション内の各ストリームについてではなく、ZRTPセッション全体で計算されます。したがって、この場合のKDFコンテキストフィールドには、ストリーム固有のNonCe材料は含まれません。
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は、確認メッセージにPBX登録フラグ（E）を設定することにより、登録プロセスを信号します（図10）。このフラグは、ZRTPエンドポイントのユーザーインターフェイスをトリガーするために使用され、ユーザーにこのPBXを信頼し、PBXSecretをキャッシュに計算して保存するかどうかを確認するように促します。ユーザーが適切なユーザーインターフェイス要素（メニュー項目、チェックボックス、またはボタン）をアクティブにして応答することを決定した場合、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はAllow Clear（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を信頼する電話のみに依存します。PBXがMITM特権を乱用した場合、危険にさらされているのは電話（ユーザー）です。
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対応の電話はどちらも、電話が将来の呼び出しでPBXを信頼できるMITMとして認識できるようにする秘密を共有します。これは、外部のZRTP対応発信者からの将来の呼び出しがPBXを介してこの電話に中継されると、電話がPBXからリレーしたSASをレンダリングすることを意味します。SASRELAYメッセージがPBXSecretを知らないMITMから来た場合、電話はそれを悪いGuy 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.
ZRTPユーザーエージェントをPBXを信頼するように構成するためのより合理化された方法があります。大規模な展開では、PBXSecretは自動化されたプロビジョニングプロセスによって電話に設定される場合があります。この仕様では、手動登録プロセスは必要ありません。PBXと電話の間でPBXSecretを計算および共有するプロセスは、ユーザーが通話を盗聴するポジションに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 PBX. That would enable the malevolent MiTM to wiretap all future calls without arousing suspicion, because he would appear to be trusted.
ZRTPクライアントは、登録セッション中にMITM攻撃が行われないという証拠なしに、PBX登録手順を進めないことをお勧めします。MITMがクライアントをだまして間違った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は「ワイヤーのバンプ」として、またはSIPユーザーエージェント（UA）から送信されたRTPが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エンドポイントには、SDPのオファーと回答にZRTP SDP属性が含まれます。ZRTP属性、A = ZRTP-HASHは、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の別の方法をサポートする場合、代わりにもう1つの方法が使用されます。並行して使用する場合、a = keymgt [rfc4567]またはa = crypto [rfc4568]属性に搭載されたsrtpの秘密は、セクション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.
A = Zrtp-Hash属性は、さまざまなメディアストリームで送信されたHelloメッセージには一意のハッシュがあるため、メディアレベルのSDPにのみ含めることができます。
The ABNF for the ZRTP attribute is as follows:
ZRTP属性のABNFは次のとおりです。
zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value
zrtp-version = token
zrtp-hash-value = 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、セクション2.1 [RFC4475]で定義されている<Alloneline>コンベンションを使用して、メディアレベルで使用された最初の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>
A mechanism for carrying this same zrtp-hash information in the Jingle signaling protocol is defined in [XEP-0262].
Jingleシグナル伝達プロトコルでこの同じZrtp-Hash情報を運ぶためのメカニズムは、[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は、氷交換中に送信されたスタンパケットと同様の構造を持つ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.
これを達成するために、セクション5.1.2.2で定義されているハッシュアルゴリズムを使用して、Helloメッセージ全体（図3）がハッシュされます。図2のZRTPパケットフレーミングは、ハッシュに含まれていません。結果のハッシュ画像は、シグナルレイヤーに切り捨てられずに利用可能になります。ここでは、この仕様で定義されているSDP属性a = Zrtp-hashを使用してSIPチャネルの16進値として送信されます。セクション5.1.2.2で256ビットハッシュの長さを定義していると仮定すると、SDP属性のA = ZRTP-HASHフィールドには64匹の16進数桁があります。各メディアストリーム（オーディオまたはビデオ）には個別のハローメッセージが表示されるため、SDP属性に個別のa = zrtp-hashが必要です。SIP/SDPメッセージの受信者は、このハッシュ画像を使用して、メディアチャネルで誤ったハローメッセージを検出および拒否し、このSIPコールに関連付けられているメディアストリームを特定できます。セクション9で定義されているランダムなノンセから派生したH3フィールドが含まれているため、各ハローメッセージは一意にハッシュします。
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属性としてのHello Hashは必要な機能ではありません。たとえば、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.
Hello Hashがこの特定の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サービスプロバイダーなどの信号層のみを制御する攻撃者は、SDP属性のHelloメッセージのハッシュを破損することでサービスを拒否できる場合があります。これが起こっていると信じる理由がある場合、ZRTPエンドポイントは、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整合性保護がない場合でも、セクション9で定義されているハッシュチェーンメカニズムと組み合わせた場合、A = Zrtp-Hash SDP属性を含めることは、メディアセキュリティ要件[RFC5479]のRアソック要件を満たしています。：
...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を消費する操作（Diffie-Hellmanや公開キー操作など）の実行を避けることができないため、SDP提供者はシグナリングメッセージを見ていない攻撃者と関連付けることができます。
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.
a = zrtp-hash sdp属性は、SDPがSIP ID [RFC4474]またはさらに良いことに整合性で保護されている場合、メディアパスを使用したダンウィングのSIPアイデンティティ[SIP-Identity]を使用する場合に特に役立ちます。これは、セクション8.1.1で説明されているように、ZRTPのSASメカニズムとは無関係にMITM攻撃を停止する能力につながります。
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.
シグナリングパスとSDPが、上記のメカニズムの1つなど、何らかの形のエンドツーエンドの整合性保護によって保護されている場合にのみ、A = Zrtp-hash属性の提供を改ざんせずに保証できる場合にのみ第三者であり、エンドユーザーの利益を保護するために信号層を信頼する正当な理由がある場合、主要な交換を認証し、MITM攻撃を防ぐことができます。これは、セクション9で定義されたハッシュチェーンメカニズムを使用して、ZRTPキー交換全体を保護する一連のMACキーを提供することにより、ユーザーがSASを口頭で比較することを要求することなく実行できます。したがって、エンドツーエンドの整合性保護シグナル層は、ZRTPでの整合性保護されたdiffie-hellman交換を自動的に可能にします。これは、MITM攻撃からの免疫を意味します。これがどのように機能しますか。
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メッセージにはH3が含まれています。これには、ハッシュチェーンH0-H2の残りの部分にハッシュコミットメントが提供されます（セクション9）。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は、セクション5.1.2.2で定義されたMACアルゴリズムで計算する必要があり、MACは64ビットに切り捨てられます。
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-Hash SDP属性の配信を整合性に保護するためにシグナリング層の証明書が支援するPKIを活用することにより、完全に満たすことができます。これにより、ユーザーがSASをチェックすることなく、ZRTPキーエクスチェンジに明示的な署名や署名キーを追加せず、追加の公開キー操作や追加のパケットなしでZRTPをMITM攻撃から保護します。
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-Hash SDP属性の提供を保証するために、これらのMacだけではMITM攻撃を防ぎません。その場合、ZRTPの組み込みのSASメカニズムは、キーエクスチェンジを認証するためにまだ使用する必要があります。この執筆時点で、展開されたVoIPクライアントは、SDP属性の提供にエンドツーエンドの整合性保護を提供する完全に実装されたSIPスタックを提供する非常に少数のVoIPクライアントを提供しています。また、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の構築と維持の複雑さなど、整合性が直面する遅延と問題をバイパスできます。
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.
1つのSRTPキーネゴシエーションプロトコルのみが使用されることが望ましいため、そのプロトコルはZRTPである必要があります。しかし、シグナリング層が独自のSRTPマスターキーと塩を交渉した場合、SDPセキュリティ記述（SDE [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は、この方法でシグナリング層によって提供されるSRTPマスターキーと塩パラメーターからSRTPを計算し、結果を256ビットに切り捨てます。
srtps = KDF(SRTP master key, "SRTP Secret", (ZIDi || ZIDr || SRTP master salt), 256)
srtps = kdf（srtpマスターキー、「srtp secret」、（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エンドポイントで計算または使用されることはめったにないと予想されます。SRTPが計算された場合、セクション4.3で定義され、セクション4.3.1で使用された補助共有秘密補助金に保存されます。
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よりも低い範囲であるように見えます。この効果は、アプリケーションで実現可能な場合、VAD二日酔い時間を1〜2秒の間のランダムな量だけ長くすることで軽減できます。短いスピーチのバーストだけが、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 AUTHタグフィールドを介して簡単に拒否される可能性がありますが、これは重要な契約が完了した後にのみ適用できます。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:
特にメディアパスにいない攻撃者から、サービス拒否攻撃の分析に関する多くの作業が行われました。このような攻撃者は、誤ったZRTPパケットを注入して、ZRTPエンドポイントに無限の無意味で高価なDH計算の無限のシリーズに従事させる可能性があります。ZRTPは、誤ったパケットが受信されるとすぐに安価かつ迅速に検出および拒否するために、一連のハッシュチェーンを使用します。これは、一連の連続したハッシュ画像です。各セッションの前に、次の値が計算されます。
H0 = 256-bit random nonce (different for each party)
H0 = 256ビットランダムなnonce（各パーティで異なる）
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.
この一方向ハッシュチェーンは、セクション5.1.2.2で定義されたハッシュアルゴリズムを使用して、256ビットに切り捨てられなければなりません。各256ビットハッシュ画像は次の画像のプリイメージであり、ZRTPパケットシーケンスで一連の画像が逆順序で送信されます。ハッシュ画像h3はhelloメッセージで送信され、h2はコミットメッセージで送信され、h1はdhpart1またはdhpart2メッセージで送信され、h0はcundile1またはcundile2メッセージで送信されます。各当事者が生成する最初のランダムH0ノンセスは、攻撃者にとって予測不可能であり、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を計算します。類似の補間は、両方の当事者によって実行され、Preshared（セクション3.1.2）またはMultiStream（セクション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で説明されているように、攻撃者によって注入されたハローメッセージは、シグナリングにハローメッセージのハッシュを含めることにより検出および拒否される場合があります。その要件。
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を使用してZRTPキー交換全体を認証し、それによってSASを口頭で比較することなく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メッセージを介して）クリアモードに手動で切り替えることができ、後でセキュアモードを再度開始できます。多くの消費者クライアント製品はこの機能を省略しますが、それを許可するものは同じメディアストリームで再びセキュアモードに戻ることができます。同じハッシュ画像のチェーンは再利用され、2回目は効果がありませんが、新しい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プロトコルに透過的に作用できます。これを行うには、デバイスはRTPと同じポートで多重化されていない非RTPプロトコルを渡す必要があります（ZRTPとSTUNを許可するため）。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-HASH）の存在または不在に基づいて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.
推奨されない3番目のモードは、中間デバイスがZRTPプロトコルを連続して試みることです。このケースの唯一の例外は、仲介デバイスがエンドポイントの1つにサービスを提供する信頼できる要素である場合です。たとえば、プライベートブランチエクスチェンジやPBXです。このモードでは、仲介者はメディアセッションの両方のエンドポイントに向けてZRTPエンドポイントとして機能しようとします。このアプローチは、セクション7.3で説明されている場合を除き、常に検出されたMITM攻撃をもたらし、両方のエンドポイントでアラームを生成し、セッションの即時終了をもたらす可能性が高いため、使用してはなりません。PBXは、その背後にあるすべてのエンドポイントに単一の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つの暗号化されたストリームがあります。それぞれに異なるSAがあります。各参加者は、確認メッセージにオプションで存在する署名（セクション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 HelloおよびInside Endpointから他のメッセージを受け取る可能性があります。これは、ZRTP SDP属性フラグを含まない別のインラインZRTPデバイスがある場合に発生する可能性があります。ZRTP Helloを受信する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 OutBandからサードパーティへの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.
当事者の1つがセッションキーを開示するように設計された製品を使用している場合、ZRTPは、相手のZRTPクライアントへのプロトコルメッセージを通じて相手にこの事実を告白することを要求します。グラフィカルユーザーインターフェイスで。開示当事者は、セクション5.7で説明されているように、CONDIM1およびCONDICE2メッセージで開示フラグ（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対応製品を使用している可能性がありますが、独自のグラフィカルユーザーインターフェイスが通話が（ほとんど）安全であることを示している場合、相手はそれができるような方法で設計された製品を使用していることを除いて、監視目的でセッションキーを開示したことで、彼が使用している安全な電話のブランドを彼に尋ね、そのブランドを自分で購入しないように精神的なメモを作ることができます。そのような後退した携帯電話が自分の性質を告白する必要があるプロトコル環境を作成すると、言葉は迅速に広がり、自由市場の「目に見えない手」が行動します。自由市場は、過去にこれを効果的に扱ってきました。
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]を提出したとき、スティーブベロビンの2003年のエイプリルフールジョークとの避けられない比較があります。しかし、同様のアイデアが実際にVoIPを保護するためのメリットを持つことができると提出します。確かに、一部の実装者はルールに恥ずかしくなく、嘘をつくことはないと想像することができますが、開示フラグがなくてもとにかく嘘をついていたでしょう。少なくとも彼らが製品に裏口を置いているかどうかを少なくとも伝える実装の全体的な割合を改善すると信じる正当な理由があり、それらの一部がバックドアにまったく入れないことを決定するかもしれません。市民の衛生的な観点からは、プロトコルに開示フラグがあることをお勧めします。
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をCONDICE1またはciend2メッセージに設定する必要があります。
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メディアストリームや実際のメディア自体を管理するものではありません。その結果、ZRTPを使用するPBXは、電話会議を提供したり、通話監視、通話録音、ボイスメール、またはその他の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 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.
共有秘密のローカルキャッシュの管理におけるZIDの役割については、セクション4.9で説明しています。特定のZIDは、特定のZRTPエンドポイント、通常はVOIPクライアントに関連付けられています。単一のSIP URI（レコードアドレスまたはAORとも呼ばれます）は、いくつかの異なるソフトVoIPクライアント、デスクトップ電話、モバイルハンドセットでホストされ、それぞれに異なるZIDがあります。さらに、単一のVOIPクライアントには、プロファイルにいくつかのSIP URIが構成されている場合がありますが、ZIDは1つだけです。ZIDとSIP URIの間に1対1のマッピングはありません。単一のSIP URIはいくつかのZIDに関連付けられている可能性があり、単一の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、Jingle、H.323、または独自のシグナル伝達プロトコルでも同様に機能します。したがって、ZRTP ZIDはSIP自体とはほとんど関係がありません。つまり、SIP URIとはほとんど関係がありません。
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エンドポイントを指定することで、より正確にすることができます。たとえば、「Jon Callas」、「iPhoneのJon Callas」、「Jon on彼の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>
Attribute name: "zrtp-hash"
属性名：「Zrtp-hash」
Type of attribute: Media level
属性のタイプ：メディアレベル
Subject to charset: Not
charsetの対象：そうではありません
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-HASH」は、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.
このセクションでは、DTLS-SRTP [RFC5764]とは異なり、他のプロトコルや拡張機能に依存せずに、メディアセキュリティ要件[RFC5479]ドキュメントで議論されているすべてのRTPセキュリティ要件をどのように満たしているかを発見します。
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はZIDを使用し、複数の独立したZRTP交換が続行できるため、R-Distinctが満たされます。
R-HERFP is met since ZRTP is a media path key agreement protocol.
ZrtpはMedia Path Key Ammortionプロトコルであるため、R-Herfpが満たされます。
R-REUSE is met using the Multistream and Preshared modes.
R-Reuseは、MultistReamおよびPresharedモードを使用して満たされます。
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チェックが満たされます。
R-ASSOC is met using the a=zrtp-hash SDP attribute in INVITEs and responses (Section 8.1).
r-assocは、招待状と応答でa = zrtp-hash sdp属性を使用して満たされます（セクション8.1）。
R-NEGOTIATE is met using the Commit message.
r-negotiateは、コミットメッセージを使用して満たされます。
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は、hello/commit zrtp Exchangeを使用して満たされます。
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-に準拠していると考えています。197]、および[NSA-SUITE-B]。[FIPS-140-2-Annex-A]および[FIPS-140-2-Annex-D]によって設定されたFIPS-140検証要件を満たす必要があります。
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.
Hash、Cipher、SRTP認証タグタイプ、キー契約方法、SASタイプ、および署名タイプのセットをすべて拡張してネゴシエートできるため、Rアヒーリティが満たされます。
R-DOWNGRADE is met since ZRTP has protection against downgrade attacks.
ZRTPはダウングレード攻撃から保護されているため、R-DownGradeが満たされています。
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-Mediaが満たされています。
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-hash sdp属性を使用して満たされます。
R-ID-BINDING is met using the a=zrtp-hash SDP attribute (Section 8.1).
r-idバインディングは、a = zrtp-hash sdp属性（セクション8.1）を使用して満たされます。
R-ACT-ACT is met using the a=zrtp-hash SDP attribute in INVITEs and responses.
r-act-actは、招待状と応答でa = zrtp-hash 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-Signalingが満たされます。
R-RECORDING is met using the ZRTP Disclosure flag.
R-Recordingは、ZRTP開示フラグを使用して満たされます。
R-TRANSCODER is met if the transcoder operates as a trusted MitM (i.e., a PBX).
トランスコダーが信頼できるMITM（すなわち、PBX）として動作する場合、Rトランススコーダーが満たされます。
R-ALLOW-RTP is met due to ZRTP's best effort encryption.
ZRTPの最良の努力暗号化により、R-Allow-RTPが満たされます。
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 Exchangeに依存しています。しかし、DHはMITM攻撃の影響を受けやすいため、DH交換を認証する方法を提供することは一般的な慣行です。一部の軍事システムでは、これは中央管理PKIに裏打ちされたデジタル署名に応じて行われます。10年間の業界経験により、中央に管理されたPKIを展開することは、苦痛でしばしば無駄な経験になる可能性があることが示されています。PKIはあまりにも乱雑で、アクティベーションエネルギーが必要になりすぎて開始できます。PKIをセットアップするには、誰かがそれを実行する必要がありますが、これは機器プロバイダーにとって実用的ではありません。キャリアのようなサービスプロバイダーは、このパスを冒険するかもしれませんが、それでも、クロスキャリア認証、証明書の取り消しリスト、およびその他の複雑さに対処する必要があります。特に安全な商用製品を開発する場合、PKIを完全に回避することははるかに簡単です。したがって、PSTNの世界の商業的な安全な電話では、キーエクスチェンジの開始時にハッシュコミットメントを組み合わせた短い認証文字列（SAS）でDH交換を強化し、読み取る必要があるSAS材料の長さを短縮することがより一般的です。声を出して。DH交換を認証するためには、このアプローチにはPKIは必要ありません。AT＆T TSD 3600、Eric BlossomのCOMSEC SECURE PHONE [COMSEC]、[PGPFONE]、およびGSMKクリプトフォンはすべて、このより単純な軽量アプローチをとった製品の例です。このアプローチの主な問題は、音声認証手順を実行しない場合がある不注意なユーザーです。
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音声アルファベットを使用して情報を伝える方法に類似した方法で、PGPワードリスト[Juola2]などの単語のリストを使用することが含まれます。これらの言葉は予測不可能な方法で会話に取り組むことができるため、これは攻撃者にとってさらに複雑になる可能性があります。セッションにビデオ（ますます一般的な使用シナリオ）も含まれている場合、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.
お互いの声を知らない人のためのSAS手順の安全性に関する質問が提起されました。なぜなら、彼が音声変容能力を欠いていても、MITMからの攻撃を許可する可能性があるからです。ユーザーが自分の声でお互いを認識する必要がないため、これは見た目ほど問題ではありません。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検出メカニズムの1つを使用するのに十分な自動システムで資格情報をプロビジョニングすることをお勧めします。または、最初の呼び出し中に人間が実行した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（Secure Shell）[RFC4251]によって使用されます。PeterGutmannは「Baby Duck」セキュリティモデルと呼んでいます。SSHは、攻撃者が存在しないと仮定したときに、最初のセッションでパブリックキーを交換することで関係を確立します。これにより、その後のすべてのセッションを認証できます。成功したMITM攻撃者は、すべてのセッションに最初のセッションに遡り、攻撃者にとって困難であると想定されている必要があります。ZRTPの主要な連続性機能は、セクション15.1で説明されている理由により、少なくともVOIPの場合、実際には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 Exchangeを認証します。永続的なパブリックキーを交換する必要はありません。共有された秘密をキャッシュして再利用して、長期にわたって安全な電話の長いDH交換を認証することができます。1つのSASだけを口頭で比較してから、認証に使用するために後で電話をかけるために共有秘密をキャッシュする場合、新しい音声認証の儀式を実行する必要はありません。私たちはすでにそれをしたことを覚えておく必要があります。
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.
セクション7.3で説明されているように、信頼できるPBXなどの信頼できるMITMデバイスを使用する場合、予防策を遵守する必要があります。このPBXは、信頼できるMITMとして確立する前に、このPBXが侵害されないことを本当に信頼してください。これは、それを信頼する電話を盗聴する立場にあるからです。盗聴する立場にあることは「ライセンス」されています。信頼できるPBXを使用するのではなく、2つのZRTPピア間でメディアを直接ルーティングするために、接続トポロジを手配しようとする方が安全です。実際のエンドツーエンドの暗号化が望ましい。
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証明書の世界でセキュリティ警告に慣れる方法についての議論については、[Sunshine]を参照してください。その論文で議論されている問題の一部は、ほとんどの警告メッセージに共通する慣習症候群からのものであり、それらの一部は、ユーザーが単に信頼モデルを理解していないという事実からのものです。幸いなことに、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検証フラグ（V）（セクション7.1）のためにSASが以前に検証されたことを知り、必要に応じて検証するようユーザーに依頼します。一度検証された後、主要な連続性機能により、再度検証する必要はありません。
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（Secure Shell）[RFC4251]によって提供されるものに類似していますが、1つの点で異なります。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].
以前のセッションから共有秘密エントロピーを追加すると、新しいセッションがDH-3072またはECDH-256以外のDiffie-Hellmanキーを使用している場合でも、新しいセッションキーの強度をAES-256レベルに拡張できることに注意してください。盗聴者が存在しなかったときに、キャッシュされた共有秘密が最初に確立された場合。これが、[NIST-SP800-57-PART1]の表2の主要な強度比較にもかかわらず、セクション5.1.5のDHキーサイズが小さい場合にAES-256を使用する理由です。
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.
著者は、このプロトコルの設計に貢献してくれたBryce "Zooko" Wilcox-O'HearnとColin Plumbに感謝したいと思います。また、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、およびRobert Sparksに感謝します。と提案。NIST SP800-56AおよびSP800-108のコンプライアンスを確保するための支援をしてくれたNistのLily Chenに感謝します。
The use of one-way hash chains to key HMACs in ZRTP is similar to Adrian Perrig's TESLA protocol [TESLA].
ZRTPのキーHMACSに一方向ハッシュチェーンを使用することは、エイドリアンペリグのテスラプロトコル[Tesla]に似ています。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Kojo、「インターネットキーエクスチェンジ（IKE）のためのよりモジュラー指数（MODP）Diffie-Hellmanグループ」、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.、Frederick、R。、およびV. Jacobson、「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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGPメッセージ形式」、RFC 4880、2007年11月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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. Kent、「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] Wing、D.、Fries、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. Zieglar、「Suite 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] McGrew、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-ANNEX-A] "Annex A：FIPS Pub 140-2の承認されたセキュリティ関数、Nist Fips Pub 140-2 Annex 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-ANNEX-D] "Annex D：FIPS Pub 140-2の承認された主要な設立テクニック"、Nist Fips Pub 140-2 Annex D、2011年1月。
[FIPS-180-3] "Secure Hash Standard (SHS)", NIST FIPS PUB 180-3, October 2008.
[FIPS-180-3]「Secure Hash Standard（SHS）」、Nist Fips Pub 180-3、2008年10月。
[FIPS-186-3] "Digital Signature Standard (DSS)", NIST FIPS PUB 186- 3, June 2009.
[FIPS-186-3]「Digital Signature Standard（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 Pub 198-1、2008年7月。
[NIST-SP800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation", NIST Special Publication 800-38A, 2001 Edition.
[NIST-SP 800-38A] DWORKIN、MD。、「操作のブロックモードの推奨」、NIST Special Publication 800-38A、2001 Edition。
[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-SP800-56A] Barker、E.、Johnson、D。、およびM. Smid、「離散対数暗号化を使用したペアワイズの主要確立スキームの推奨」、NIST Special Publication 800-56A Revision 1、2007年3月。
[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-SP800-90] Barker、E。およびJ. Kelsey、「決定論的なランダムビットジェネレーターを使用した乱数生成の推奨」、NIST Special Publication 800-90（改訂）、2007年3月。
[NIST-SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800- 108, October 2009.
[NIST-SP800-108] Chen、L。、「擬似ランダム関数を使用したキー派生の推奨」、NIST Special Publication 800-108、2009年10月。
[NSA-Suite-B] "NSA Suite B Cryptography", NSA Information Assurance Directorate, NSA Suite B Cryptography.
[NSA-SUITE-B]「NSA Suite B Cryptography」、NSA Information Assurance Directorate、NSA Suite B Cryptography。
[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-SUITE-B-GUIDE-56A]「Suite B実装者のNIST SP 800-56Aのガイド」、Suite B実装者のGuide Guide Guide of Nist SP 800-56A、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] Schneier、B.、Kelsey、J.、Whiting、D.、Hall、C。、およびN. Ferguson、「Twofish：A 128ビットブロック暗号」、1998年6月、<http：//www.schneier.com/paper-twish-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>.
[Skein] Ferguson、N.、Lucks、S.、Schneier、B.、Whiting、D.、Bellare、M.、Kohno、T.、Callas、J。、およびJ. Walker、 "The Skein Hash Functionファミリー、バージョン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 Word List"、2010年12月、<http://en.wikipedia.org/ w/index.php？title = pgp_word_list＆oldid = 400752943>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Peterson、J.、Liu、H.、Yu、J。、およびB. Campbell、「セッション開始プロトコル（SIP）でE.164番号を使用」、RFC 3824、2004年6月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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、「The Secure Shell（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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、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] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）のキー管理拡張機能」、RFC4567、2006年7月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（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] Johnston、A。およびO. Levin、「セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議」、BCP 119、RFC 4579、2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] McGrew、D。およびE. Rescorla、「Datagram Transport Layer Security（DTLS）拡張機能を確立するためのextension」、安全なリアルタイム輸送プロトコル（SRTP）のキーを確立する」、2010年5月、RFC 5764。
[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] McGrew、D.、Igoe、K。、およびM. Salter、「基本楕円曲線暗号化アルゴリズム」、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] McGrew、D。、「AES-GCMおよびAES-CCM 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] Perkins、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] Wing、D。およびH. Kaplan、「Media Pathを使用したSIP ID」、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-Part1] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「キー管理の推奨 - パート1：一般（改訂）」、Nist特別出版800-57-パート1 2007年3月改訂。
[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] Barker、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] "The Skein Hash Functionファミリー - 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] Saint-Andre、P。、「Jingle 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。and P. Zimmermann、「全単語の音声距離と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] Zimmermann、P。、 "Pgpfone"、1996年7月、<http://philzimmermann.com/docs/pgpfone10b7.pdf>。
[Zfone] Zimmermann, P., "Zfone Project", 2006, <http://www.philzimmermann.com/zfone>.
[Zfone] Zimmermann、P。、 "Zfone Project"、2006、<http://www.philzimmermanman.com/zfone>。
[Byzantine] "The Two Generals' Problem", March 2011, <http:// en.wikipedia.org/w/ index.php?title=Two_Generals%27_Problem&oldid=417855753>.
[ビザンチン]「2人の将軍の「問題」、2011年3月、<http：// en.wikipedia.org/w/ index.php？title = 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.、Canetti、R.、Tygar、J。、およびD. Song、「The Tesla Broadcast Authentication Protocol」、2002年10月、<h ttp：//www.ece.cmu.edu/~adrian/プロジェクト/tesla-cryptobytes/tesla-cryptobytes.pdf>。
[comsec] Blossom, E., "The VP1 Protocol for Voice Privacy Devices Version 1.2", <http://www.comsec.com/vp1-protocol.pdf>.
[comsec] Blossom、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] Wright、C.、Ballard、L.、Coull、S.、Monrose、F。、およびG. Masson、「可能であれば：暗号化された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>.
[Sunshine] Sunshine、J.、Egelman、S.、Almuhimedi、H.、Atri、N.、およびL. Cranor、「Crying Wolf：SSL警告有効性の経験的研究」、Usenix Security Symposium 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 Security Advisory-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
Alan Johnston (editor) Avaya St. Louis, MO 63124
アラン・ジョンストン（編集者）アヴァヤ・セントルイス、ミズーリ63124
EMail: alan.b.johnston@gmail.com
Jon Callas Apple, Inc.
Jon Callas Apple、Inc。
EMail: jon@callas.org