テクニカル概要

概念

ジャミアカウント

  • Jamiアカウントは,RSA不対称鍵ペア**をベースとした暗号化Jami Identityによって定義され, **[RFC 5280]によって定義された x.509証明書で管理されます.

  • ジャーミは,RSAキーと証明書を生成および管理するためにgnutlsライブラリを使用します.

ジュミ証明書

  • これはジャミユーザの身分を表しています

  • 口座作成時に生成される

  • ジャミ口座の公開鍵を 含んでいる

  • この公認書のSHA-1指紋 (160ビット) はJamiIdです.

  • CA (組織から) によって署名された.

  • 対象 UID フィールドは JamiId の六桁形である必要があります.

  • 発行者 UID フィールドは,発行者の公钥指紋 (CA) の六点式形式である.

  • ランダム RSAキーペアで少なくとも4096ビット長さ

デバイス証明書

  • これはジャミを操るのに使われた特定の装置のアイデンティティです

  • 装置ごとに1個

  • ランダムで4096ビット長さ

  • 公開鍵の SHA-1 指紋は DeviceIdになります.

  • ジュミ証明書を作った私钥で署名しなければならない

  • 対象 UID フィールドは,DeviceIdの六桁形である.

  • 発行者 UID フィールドは,発行者公钥指紋 (JamiId) の六点式形式である.

用途

  • ジュミール・イン・ザ・ジャミール

    • 口座デバイスのリストが公開され,すべてのデバイスがアカウント変更 (すなわちデバイスを追加または撤回) に同期するように聞く DHT キーです.

  • Jami証明書 RSA キーは,DHT で送信されたメッセージの署名/暗号化/解読のための長期鍵として使用されます.

    • 受信メッセージやデバイス証明書のサインオフとデコードを出すためのプライベートキー.

    • メッセージ暗号化のための公開鍵 (これは受信者の公開鍵を使用してメッセージを発行者によって行われます).

  • デバイスの証明書の撤回によって,Jamiアカウントからデバイスを"削除"することができます.

    • 撤回されたデバイス証明書は,標準 x509 証明書の撤回リスト (CRL) に追加されます.

    • 撤回されたデバイスのCRLは有効で,相応のCAキーで署名されなければなりません.

長期保存

  • なぜデータを保存する?

    • 申請開始ごとに 証明書とキーペアを 読み込む必要がある.

    • 安全な方法で他の信頼できるデバイスから共有される 情報を必要とします

    • すべてのプラットフォームはデータを保存する安全な方法を提供していないが,ジャミはアカウント作成中にユーザー定義されたパスワードを使用してメモリの外に保存されたデータを暗号化することによってこの事実をサポートします.

  • これらのファイルは,ユーザデバイスに保存されます (詳細については,以下を参照してください):

    • 密封されたファイルで,個人アカウントのデータが含まれています.

    • 公認証連鎖はCRTファイルとして

    • デバイスのプライベートキー

ジャーミアーカイブ (export.gz)

  • プライベート口座のデータを含んでいる

  • デバイスが作成または撤回されたときに現在 DHT ネットワークで送信されます.

  • JSONの圧縮と暗号化されたファイルです

  • 現在の形式は (いつでも変更可能)

{
  ringCaKey: <base64 serialized PEM-encoded CA private key>,
  ringAccountKey: <base64 serialized PEM-encoded Jami private key>
  ringAccountCert: <base64 serialized PEM-encoded Jami certificate (public key)>,
  ethKey: <base64 serialized of the optional 160-bits Etherium key used to register the JamiId on a public blockchain>,
  ringAccountCRL: <base64 serialized of packet list of revoked device certificates PEM-encoded>,
  ringAccountContacts: <JSON dictionary to export trusted user contacts>
}

  • JSON バイトストリームは \ * gzip \ * アルゴリズムを使用して圧縮されます.

  • その後,gzipストリームは 256-bitのキーで AES-GCM-256対称暗号を使用して暗号化されます.

    • このキーは, [Argon2] (パスワード拡張および正常化) を使用して,ユーザーに提供されたパスワード,PINとタイムスタンプから得られます.

salt = PIN + timestamp
key = argon2(password, salt)
  argon2 is the argon2i algorithm using t_cost = 16, m_cost = 2^16 (64 MiB), mono-threaded, to generate a 512-bits key and then hashed with SHA-256 to generate a 256-bits key.
  PIN is a random 32bits number in hexadecimal form.
  + is string concatenation operator.
  timestamp is the current UNIX timestamp divided by 1200 (20 minutes).
  password is a user-chosen password (given at account creation).

  • ユーザは新しい物理デバイスに PIN を示し,デバイス作成プロセスを完了するためにパスワードとともに手動でコピーする必要があります.

  • 注: DHT または他の場所からファイルを輸出する際,デモンが最初にアーカイブを更新し,最新の連絡先を書き込む.これは,輸出時にパスワードが必要になる理由です (これは他の場所でのアーカイブのコピーではありません)

ジャーミデバイス証明書チェーン (ring_device.crt)

  • PEM形式

  • デバイス証明書と親証明書 (Jamiデバイス証明書と親証明書) を含む

デバイスのプライベートキー (ring_device.key)

  • PEM形式

  • ファイルシステムにこのファイルを保護させます

DHTネットワーク

専用 [Jami 分布ネットワーク] リング_ディストリビューテッド_ネットワーク "wikilink") ページ.

連絡要求

  • Deprecated in favor of "Conversation requests"

Conversation request

  • Max 64k (a DHT value)

  • Contains a conversation Id

  • Contains the sender URI

  • Can contains optional metadatas (avatar/profile)

瞬間の メッセージ

  • Mostly used to initiate connections with ICE candidates

  • Can transmit some SIP messages, however SIP channel is preferred

  • SIP messages can be read status, location sharing, messages notifications.

出発・入場電話

  • ユーザの連絡先アドレス (すなわち IPアドレス) は,同類のみに与えられます.

    • われが仲間を呼ぶ時,

    • 信頼される同僚が電話をする時 (入ってくる電話)

  • 特定のデバイスに連絡する方法の組み合わせのすべては,ICEメッセージでまとめられています.

    • *RFC 5245 *は,NATの通行のためのプロトコルであるICE (インタラクティブ接続施設) を定義している.

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

連絡を出す

  1. 呼び出し装置は,候補者を集め,ICEの仕様に従って 初次オファーを作成します.

  2. 呼び出し装置は,暗号化された ICE オファー (初期オファー*) を: h("callto:"+DeviceID ) にDHTに配置する. h は SHA1, + は文字列連鎖, DeviceID は六桁形である.

  3. 呼叫装置は 仲間からの答えを待っている 独自の ICE候補者リストを持っています

  4. ピアレスポンスで 電話機は ICEの交渉を開始します

  5. 交渉が成功すれば,クライアント側でのDTLSセッションの設置が作成されたICEソケット上に続行する (下記を参照).

受信電話を聞く

  1. デバイスは,聴く OpenDHT操作を実行して,入力式を入力式に聴く. h("コール:"+DeviceID ) , h は SHA1, + は文字列連鎖, DeviceID は六桁形である.

  2. ICE Initial Offer受付時に,呼び出されたデバイスは**をピア (以下を参照) のセキュリティ検証を行う必要があります.

  3. セキュリティ検証が成功すれば 呼び出されたデバイスは ICE交渉を開始します

  4. 交渉が成功すれば,プロセスは作成されたICEソケット (以下を参照) の上でサーバー側DTLSセッションを設置する上で継続されます.

  • 注: OpenDHT は OpenDHT プロトコルで指定されているように,適切に暗号化または署名されていない値を落とします.

ICE シリアライゼーション形式

  • ICEの通信は,次の形式で設定された電話中に同級者の間で交換される.

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

<8-bits unsigned integer> giving the version of ICE message format protocol used for the rest of the data,
<C++ std::pair of string> of the ICE local session ufrag and the ICE local session password,
<8-bits unsigned integer> giving the number of components in the ICE session,
<array of string> of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)

  • 現在の定義プロトコルは 1:

仲間 の 安全 確認

  • 暗号化され署名された初期ICEオファー (リスニング操作を通じて) を受信すると,呼び出すデバイスは,初期オファー署名者として識別された呼び出すデバイスの認証チェックを実行する必要があります.

  • 許可規則は実装定義ですが,典型的な実装では,知られたまたは信頼された連絡先を許可します.

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

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

DTLS交渉

  • ICEプロトコルによってピアツーピア通信チャンネルが確立された後,呼び出されたデバイスは,ICEソケットの反対側でクライアント側 DTLSセッションを起動する一方,ICEソケットのサーバー側 DTLSセッションを起動します.

  • DTLS通信は RFC6347 gnutls ライブラリを使用してコンプライアンスの.

  • 呼び出しの匿名性を保つために,ペア証明書の素文で表示されないように,セッション握手を2回行う.

  1. 匿名モードで初めて握手して 安全で匿名な輸送をします

  2. 証明書モードで2度目の握手 仲間のアイデンティティを証明する

  • PFS暗号セットのみがサポートされています.

    • サポートされる暗号スイートセットは実装定義だが,少なくとも ECDHE-AES-GCMを含むべきである.

    • 暗号の実際のスイート (グヌットル形式) は:

      • 匿名ステップ: SECURE192:-KX-ALL:+ANON-ECDH:+ANON-DH:+SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION

      • ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎ ◎

SIP信号

  • DTLSセッションで電話を信号する際に使用されます (vcard,メディア交渉,ハングアップ,インスタントメッセージ,...)

  • 暗号化され,認証されたピアツーピア通信チャンネルが利用可能になったら, [SIP プロトコル] (https://tools.ietf.org/html/rfc3261) は電話とメッセージを送信するために使用されなければならない.

  • DTLSチャンネルが確立された直ぐに SIP INVITE を送信する可能性があります.

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

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

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

存在

  • Sent on the DHT

  • DeviceAnnouncement (contains device hash + public key)

セキュリティ / プライバシー

呼び出しの際には,Eliptic Curve Diffie-Hellman キー交渉が異なる.外通のメッセージングには,単一の RSA-4096 が使用されます.使用されている暗号化ライブラリは GNUTLS です.

詳細:

  • [技術概要]Jami内の概念とプロトコルに関する技術/技術概要