議定書

Jami account creation

A Jami account is defined by an RSA key pair with a key length of at least 4096 bits.

口座公開鍵の標準 x509 160 ビット指紋は RingIDと呼ばれます.

The account public key is used as the subject of an x509 certificate that must be valid, have the Certificate Authority flag set, and can be self-signed. This certificate is called the Jami account certificate.

口座証明書の対象 UID フィールドは,公钥指紋の六 दशमलव形式でなければならない.発行者 UID フィールドは,発行者公钥指紋の六 दशमलव形式でなければならない.

継続する

Persisting a Jami account private key and certificate is implementation defined.

Access to a saved Jami account private key must be authenticated and authorized. Authentication and authorization method to access the account private key is implementation defined.

Adding a device to a Jami account

RFC5280を参照してください

デバイスは,少なくとも 4096 ビットのキー長さの RSA キーペアによって定義されます.

デバイス証明書は,アカウントプライベートキーで署名されたデバイス公開鍵の対象となるx509証明書として定義されます.証明書は有効である必要があります.発行者 UIDフィールドはアカウント公開鍵の指紋の六桁形である必要があります.

デバイスのプライベートキーと証明書を保持することは実装定義です.保存されたデバイスのプライベートキーへのアクセスが認証されるべきです.デバイスのプライベートキーへのアクセスのための認証方法は実装定義です.

Removing a device from a Jami account

A device can be "removed" from a Jami account through revocation of the device certificate. Revoked device certificates are added to one or more standard x509 Certificate Revocation List (CRL). CRLs for revoked device must be valid and signed with the corresponding CA key, which is the Jami account private key.

アカウント転送形式

アカウントアーカイブ形式では,新しいデバイス証明書に署名するために,アカウントプライベートキーを送信するためにどのようにシリアライズするか定義します.

アカウントアーカイブは,次の構造を持つ暗号化された JSON オブジェクトです.

{
    "ringAccountKey": (PEM-encoded account private key string),
    "ringAccountCert": (PEM-encoded account certificate string),
    "ringAccountCRL": (PEM-encoded account CRL string)
}

JSON オブジェクトには,実装で定義されたキー値ペアが追加されることがあります.実装で定義されたキー名は"リング"から始まるべきではありません.

文字列 JSON オブジェクトは,以下のように定義されたキーを使用して暗号化されます:

salt = PIN + timestamp
key = argon2(password, salt)

PINは六位数でランダムな32ビット番号である場合",+"は文字列連鎖,タイムスタンプは現在の UNIXタイムスタンプで 1200 (20分) で割られ,パスワードはユーザーによって選択されたパスワードです.

ユーザは新しい物理デバイスに手動でコピーされる PIN をパスワードとともに表示する必要があります.

他の口座に連絡

ICE ディスクリプター交換と OpenDHT

  • 受信電話を聞く

デバイスは,受信電話を聞く OpenDHT 操作を実行することで,受信電話を聞く

h("コール"+デバイスID)

h は SHA1 で, "+" は文字列連鎖であり, deviceID は deviceID の六桁形である.

受信された OpenDHT 値が暗号化されていないか,適切に署名されていない場合は,削除する必要があります.この値は,呼び出しデバイスの公開鍵で暗号化され,OpenDHT 仕様に従って呼び出しデバイスのプライベート鍵で署名する必要があります.

  • 初回申し出を送信する

*RFC5245を参照してください.

RFC 5245 は,NAT 通過のためのプロトコルである ICE (インタラクティブ接続性確立) を定義する.

ICEはジャミで2つのデバイス間のピアツーピア通信を確立するために使用されています.

呼び出し装置は候補者を集め,ICEの仕様に従って初期オファーを作成し,ICEの交渉プロセスを開始します.

呼び出しデバイスは,暗号化された ICE オファー (初期オファー) を h("callto"+deviceID) にDHTに置く.

  • ICEシリーズ化形式

ICEメッセージは, [msgpack] (http://msgpack.org/) のデータフォーマットに従って,バイナリデータの一部分である.

このプロトコルは,次々にこの順にパッケージ化された msgpack 値の複合である.

  • データの残りの部分で使用される ICEメッセージ形式プロトコルバージョンを表示する整数.現在の定義プロトコルバージョンは 1.

  • ICE のローカルセッション ufrag と ICE のローカルセッション パスワード の 2 つの要素の文字列

  • ICEセッションの構成要素の数を示す整数

  • 文字列の配列,以前の番号エントリ,各文字列がICE候補者を記述する, [rfc5245,セクション 4.3]に記述された"a="行 (a="ヘッダなし) としてフォーマットする.

  • ** 返事を送る**

暗号化され署名された初期ICEオファー (リスニング操作を通じて) を受信すると,呼び出しデバイスは,初期オファーサインとして識別された呼び出しデバイスの認証チェックを実行する必要があります.承認規則は実装が定義されていますが,典型的な実装では,知られているまたは信頼される連絡先を承認します.

呼び出しデバイスが許可されていない場合,または実行された理由により呼び出しデバイスが受信接続要求を拒否した場合,呼び出しデバイスは初期オファーを無視し,イベントをログインすることができます.

呼び出しデバイスが呼び出し者に権限を与え,接続を受け入れたい場合は,ICE応答を作成し,ICE交渉プロセスを開始し,暗号化されたおよび署名されたICE応答を同じDHT鍵で送信する必要があります.

DTLS交渉

ピアツーピア通信チャンネルが確立された後,呼び出されたデバイスは,受信DTLS接続 (DTLSサーバーとして動作する) を聴き,呼び手は出回DTLS接続 (DTLSクライアントとして動作する) を起動します.

DTLS通信はRFC6347に準拠しなければならない (1).

ピアスのみはPFS暗号スイートをサポートする必要があります.サポートされる暗号スイートセットは実装定義されていますが,少なくともECDHE-AES-GCMを含む必要があります (TODO:サポートに推奨される正確なスイート指定).

DTLSの握手中に,両同級者はそれぞれのデバイス証明書チェーンを提供し,他の同級者を認証し,DHT ICE交換中に使用された公钥が同じかどうかを確認する必要があります.

SIP 呼び出し

See Important_RFC

暗号化され,認証されたピアツーピア通信チャンネルが利用可能になった後,SIPプロトコル 2 が利用され,通話とメッセージを送信する. DTLSチャンネルが確立された直ぐに,呼び手はSIP INVITE を送信する可能性があります.

SIPの実施はICEとSRTPを支える必要があります.

サポートされているコデックは実装定義ですが,Jami クライアントはOpus オーディオコードとH264 ビデオコデックをサポートする必要があります.

SIPとのメディア交渉において,SRTPは,各メディアおよび各交渉のための新しいランダムキーを使用して使用されなければならない. SIPとのメディア交渉において,ICEは使用されるべきである.

暗号原始

パスワードのストレッチ

*[Argon2仕様] (https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf) *

パスワードは,t_cost = 16,m_cost = 2^16 (64 MiB) を用いて,単线で512ビットハッシュを生成する.

検索結果は,要求されたキーサイズに応じて SHA{1, 256, 512} を使用して再びハッシュされます.

暗号化

提供されたキー (128, 192 または 256 ビット) を使って

暗号化には,各暗号化に対してランダム IV を使用して Nettle が実装した標準 AES-GCM を使用します.

テキストパスワードを使用する

パスワードは 256 ビットキーと 128 ビットランダムな塩を生成します

入力データは AES-GCM (上記を参照) を使用して暗号化され,生成された暗号文字の初めに塩が添付されます.

呼び出し中に

オーディオ/ビデオデータは,同類間の暗号化された RTP チャンネルを使用して交換されます.

このプロトコルは,次の暗号スイートでサポートされているクラシックなSRTPです.

  • Jami account force AES_CM_128_HMAC_SHA1_80

  • SIP は AES_CM_128_HMAC_SHA1_80 または AES_CM_128_HMAC_SHA1_32 を使用できます

呼び出しのマスターキーと塩は,各通話ごとに異なるランダム番号です.通話のマスターキーは通話のフルライブ中に恒定です.

The keys are exchanged using SDES method: keys are written into the SIP SDP messages during the SIP INVITE negotiation. When SDES is used, Ring forces the underlaying transport to be secure (encrypted) to not disclose these keys. Jami supports DTLS natively for SIP and Ring accounts for such. The call cannot be done if this condition is not fulfilled.