پروتکل

Jami account creation

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

اثر انگشت 160 بیت استاندارد x509 کلید عمومی حساب 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

*ببینید [RFC 5280]https://tools.ietf.org/html/rfc5280) *

یک ** دستگاه** توسط یک جفت کلید RSA با طول کلید حداقل 4096 بیت تعریف می شود.

گواهی ** دستگاه** به عنوان گواهی 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("دعوت"+آداپتور

جایی که h SHA1 است، "+" زنجیره ی رشته ای و deviceID شکل شش اعشاری دستگاه ID است.

ارزش های دریافت شده OpenDHT که رمزگذاری نشده یا به درستی امضا نشده اند باید حذف شوند. ارزش باید با کلید عمومی دستگاه که نامیده می شود رمزگذاری شده و با کلید خصوصی دستگاه تماس مطابق با مشخصات OpenDHT امضا شود.

** ارسال پیشنهاد اولیه**

*ببینید [RFC 5245]

RFC 5245 ICE (تأسيس ارتباطات تعاملی) را تعریف می کند، پروتکل برای عبور NAT.

ICE در جامی برای ایجاد ارتباط بین دو دستگاه استفاده می شود.

دستگاه تماس کاندیداها را جمع آوری می کند و پیشنهاد اولیه را مطابق با مشخصات ICE ایجاد می کند و روند مذاکره ICE را آغاز می کند.

دستگاه تماس، پیشنهاد ICE رمزگذاری شده (تعارف اولیه) را در DHT به h("کال"+دیواسیID) قرار می دهد که در آن deviceID شکل شش اعشاری از deviceID نامیده می شود.

فورت سریالیزاسیون ICE

پیام های ICE در میان همسالان در طول تنظیم تماس از فرمت زیر استفاده می شود. یک پیام ICE یک قطعه داده های دوگانه است که در فرمت داده های [msgpack] (http://msgpack.org/) است.

این پروتکل ترکیبی از ارزش های msgpack است که به ترتیب زیر بسته بندی شده است:

یک عدد کامل که نسخه پروتکل فرمت پیام ICE را برای بقیه داده ها استفاده می کند. نسخه پروتکل فعلی تعریف شده 1 است.
یک صف دو عنصر از رشته های جلسه محلی ICE ufrag و رمز عبور جلسه محلی ICE
یک عدد کامل که تعداد اجزای در جلسه ICE را نشان می دهد
یک صف از رشته، از ورودی های شماره قبلی، که هر رشته ای از کاندیدای ICE توصیف می کند، به شکل یک خط "a=" (بدون عنوان "a=") که در [rfc5245, بخش 4.3] توضیح داده شده است، شکل داده شده است.

** ارسال پاسخ**

هنگامی که پیشنهاد اولیه ICE رمزگذاری شده و امضا شده (به وسیله عملیات گوش دادن) دریافت می شود، یک دستگاه تماس گرفته باید چک مجوز دستگاه تماس را انجام دهد، که به عنوان امضا کننده پیشنهاد اولیه شناخته می شود. قوانین مجوز اجرا تعریف شده است، اما اجرای معمول اجازه تماس های شناخته شده یا قابل اعتماد را می دهد.

اگر دستگاه تماس مجاز نباشد یا اگر به دلایل مشخصی برای اجرای، دستگاه تماس گرفته درخواست اتصال درآمده را رد کند، دستگاه تماس گرفته باید پیشنهاد اولیه را نادیده بگیرد و ممکن است رویداد را ثبت کند.

اگر دستگاه تماس گرفته اجازه دهنده تماس گرفته و می خواهد اتصال را قبول کند باید پاسخ ICE را ایجاد کند، روند مذاکره ICE را آغاز کند و پاسخ ICE رمزگذاری شده و امضا شده را در همان کلید DHT ارسال کند.

مذاکره در مورد DTLS

هنگامی که یک کانال ارتباطی همتایان ایجاد شده است، دستگاه تماس گرفته شده برای اتصال های DTLS وارد شده (که به عنوان یک سرور DTLS عمل می کند) به آن گوش می دهد در حالی که تماس گیرنده یک اتصال DTLS خارج شده (که به عنوان یک مشتری DTLS عمل می کند) را آغاز می کند.

ارتباطات DTLS باید مطابق با RFC6347 باشد (1).

همتایان فقط باید سوئیت های سیفر PFS را پشتیبانی کنند. مجموعه سوئیت های سیفر پشتیبانی شده پیاده سازی تعریف شده است اما باید حداقل شامل ECDHE-AES-GCM باشد (TODO: سوئیت های دقیق توصیه شده را برای پشتیبانی مشخص کنید).

در طول دست دادن DTLS، هر دو همتایان باید زنجیره گواهینامه دستگاه خود را ارائه دهند و باید همتایان دیگر را تأیید کنند، و بررسی کنند که کلید عمومی آن همان کلید مورد استفاده در هنگام تبادل DHT ICE است.

تماس SIP

*ببینید مهم_RFC *

هنگامی که یک کانال ارتباطی همتایان رمزگذاری شده و معتبر در دسترس است، باید از پروتکل SIP 2 برای قرار دادن تماس و ارسال پیام استفاده شود. تماس گیرنده ممکن است بلافاصله پس از ایجاد کانال DTLS یک SIP INVITE ارسال کند.

اجرای SIP باید از ICE و SRTP حمایت کند.

کدک های پشتیبانی شده پیاده سازی تعریف شده است، اما مشتریان Jami باید کد صوتی Opus و کد ویدئویی H264 را پشتیبانی کنند.

SRTP باید هنگام مذاکره رسانه ای با SIP، با استفاده از یک کلید تصادفی جدید برای هر رسانه و هر مذاکره استفاده شود. ICE باید هنگام مذاکره رسانه ای با SIP استفاده شود.

ابتدایی های رمزنگاری

کشش رمز عبور

*ببینید [تفصیلات آرگون۲]https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf) *

رمز عبور با استفاده از argon2i با استفاده از t_cost = 16, m_cost = 2^16 (64 MiB) ، یک رشته ای کشیده شده است تا یک هش 512 بیت ایجاد شود.

سپس نتیجه دوباره با استفاده از SHA{1, 256, 512} بسته به اندازه کلید مورد نیاز هاش می شود.

رمزگذاری

استفاده از کلید ارائه شده (128, 192 یا 256 بیت)

رمزگذاری با استفاده از AES-GCM استاندارد که توسط Nettle با استفاده از یک IV تصادفی برای هر رمزگذاری اجرا شده است.

استفاده از رمز عبور متن

رمز عبور برای تولید یک کلید 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.