Разработка кроссплатформенной системы end-to-end зашифрованной связи на основе каналов данных WebRTC

0. Установка WSS соединение

Статус сервера

Установка WSS соединение

При открытии веб-сайта клиент устанавливает защищённое соединение с сервером по протоколу WSS (WebSocket Secure), который обеспечивает безопасность на основе системы центров сертификации (CA).

В данной выпускной квалификационной работе (ВКР) для защищённой связи между клиентом и сервером используется SSL-сертификат Let’s Encrypt, чья система центров сертификации представляет собой единую глобальную цепочку доверия, что предотвращает атаки «человек посередине» (MITM).

В реальной производственной среде для защиты от возможных атак «человек посередине» со стороны иностранных центров сертификации рекомендуется использовать сертификаты, выданные Russian Trusted Root CA.

При успешном установлении защищённого соединения статус «Статус сервера» отображается зелёным цветом.

1. Создание нового пользователя

Пароль:

1. Создание нового пользователя

  1. Пользователь вводит пароль, который используется как секрет для симметричного шифрования закрытых ключей ECDSA и ECDH в локальном хранилище браузера (localStorage) по алгоритму AES-GCM 256-bit. Это предотвращает несанкционированное использование учётной записи лицами, имеющими доступ к браузеру, но не знающими пароль.
  2. При нажатии кнопки «Создать» клиент запрашивает у сервера ID пользователя.
  3. Сервер отправляет клиенту сгенерированный ID пользователя.
  4. Клиент генерирует пары ключей ECDSA и ECDH, подписывает полученный от сервера ID пользователя закрытым ключом ECDSA, после чего отправляет серверу: открытый ключ ECDSA, открытый ключ ECDH и подпись ID пользователя.
  5. Сервер проверяет подпись ID пользователя с помощью открытого ключа ECDSA клиента. При успешной проверке сервер сохраняет ID пользователя, открытый ключ ECDSA и открытый ключ ECDH клиента.
  6. После получения от сервера подтверждения об успешной проверке клиент шифрует закрытые ключи ECDSA и ECDH введённым паролем и сохраняет их вместе с открытыми ключами в localStorage для последующего использования.
  7. В реальной производственной среде для обработки информации необходимо использовать алгоритмы ГОСТ: например, для симметричного шифрования применять алгоритм Кузнечик вместо AES-GCM, для электронной подписи на эллиптических кривых — ГОСТ Р 34.10-2012/2018 вместо ECDSA, для согласования ключей на эллиптических кривых — ГОСТ Р 34.10-2012/2018 вместо ECDH.

2. Выбор пользователя


ID пользователя:

2. Выбор пользователя

  1. Здесь происходит загрузка пользователя из локального хранилища localStorage.
  2. После ввода пароля программа пытается расшифровать закрытые ключи ECDSA и ECDH. При успешной расшифровке клиент подписывает свой ID пользователя закрытым ключом ECDSA и отправляет серверу подпись вместе с ID пользователя.
  3. Сервер по ID пользователя загружает ранее сохранённый открытый ключ ECDSA, проверяет подпись ID пользователя. При успешной проверке сервер добавляет пользователя в список онлайн и отправляет клиенту подтверждение.
  4. После получения подтверждения клиент отображает ID пользователя на экране зелёным цветом.

3. Получение списка онлайн-пользователей

3. Получение списка онлайн-пользователей

  1. После успешной загрузки ID пользователя становится доступным получение списка онлайн-пользователей с сервера.
  2. После выбора целевого пользователя для соединения запускается процесс установки WebRTC-соединения с ним (четвертый шаг).

4. Установка WebRTC-соединения

к пользователю:

4. Установка WebRTC-соединения

  1. Инициатор WebRTC (тот, кто нажимает кнопку «Подключиться») называется Caller, а принимающая сторона — Callee. offer и answer являются служебными данными, необходимыми для установки WebRTC-соединения.
  2. Caller создаёт P2P-соединение RTC, генерирует offer, подписывает свой ID пользователя закрытым ключом ECDSA и отправляет серверу подпись ID, offer.
  3. Сервер передаёт клиенту Callee по WSS: подпись ID Caller, открытый ключ ECDSA Caller, открытый ключ ECDH Caller и offer.
  4. Callee создаёт P2P-соединение RTC по offer, генерирует answer, проверяет подпись ID Caller по его открытому ключу ECDSA, подписывает свой ID пользователя закрытым ключом ECDSA и отправляет серверу подпись ID и answer.
  5. Сервер передаёт клиенту Caller по WSS: подпись ID Callee, открытый ключ ECDSA Callee, открытый ключ ECDH Callee и answer.
  6. Caller завершает установку WebRTC-соединения с Callee и проверяет подпись ID Callee по его открытому ключу ECDSA.
  7. В данном процессе передача открытых ключей, offer и answer осуществляется по защищённому протоколу WSS, что предотвращает атаки «человек посередине» со стороны третьих лиц.

5. Аутентификация Out-of-Band (OOB)


ECDSA:
ECDH:

ECDSA:
ECDH:
  1. Как указано в конце четвертого шага, обмен ключами по протоколу WSS защищает только от атак «человек посередине» со стороны третьих лиц, но не позволяет доказать достоверность самого сервера. Фактически через интернет невозможно создать абсолютно доверенную систему: кто бы вы ни доверяли, тот может вас предать. Сервер может выступать как активный посредник (MITM), а система сертификации CA, на которую опирается WSS, может быть использована США в своих интересах.
  2. Открытый исходный код также не решает этой проблемы полностью. HTML-код клиента открыт, можно с помощью хэша SHA проверить неизменность страницы, чтобы сервер не внедрил вредоносный JavaScript для кражи закрытых ключей. Однако невозможно гарантировать, что реальный серверный код совпадает с опубликованным открытым кодом.
  3. Самостоятельный сервер решает проблему MITM со стороны стороннего сервера, а самоподписанные сертификаты устраняют риск использования американской системы CA. Однако для обычного пользователя создание собственного сервера слишком сложно и увеличивает стоимость защиты.
  4. WebRTC используется для организации пирингового (P2P) соединения и снижения нагрузки на сервер, ECDH — для сквозного шифрования и обеспечения конфиденциальности. При симметричном NAT у обоих узлов прямое P2P-соединение через STUN невозможно, поэтому трафик передается через TURN-сервер. Как STUN, так и TURN используют шифрование WebRTC (DTLS+SRTP), но при злонамеренном поведении сервера атака MITM остается возможной.
  5. Поэтому в данной ВКР безопасная передача сообщений не основана на механизмах WebRTC, CA или доверии к серверу. Вместо этого применяется механизм аутентификации вне канала OOB (Out-of-Band Authentication). Такой механизм используется в популярных E2EE-мессенджерах: WhatsApp, Telegram, Signal. Например, в Telegram при установке секретного чата отображаются четыре эмодзи; совпадение эмодзи гарантирует безопасность соединения.
  6. При установке WebRTC-соединения сервер передает каждому клиенту открытые ключи ECDSA и ECDH другой стороны. После успешной проверки подписи по открытому ключу ECDSA рядом с ID пользователя появляется знак «✅». Затем клиенты вычисляют хэш SHA-256 от открытых ключей ECDSA и ECDH (отпечаток ключа) и по нему генерируют эмодзи для визуальной проверки.
  7. Стороны должны проверить отпечатки ключей офлайн или по заранее проверенному каналу. Только после подтверждения совпадения связь считается безопасной. Также независимо проверяется MD5-хэш веб-страницы на соответствие открытому коду. Это два единственных момента, на которые нужно доверять: даже если все остальные каналы скомпрометированы, связь останется безопасной.
  8. В реальной производственной среде вместо хэш-функции SHA-256 необходимо использовать отечественный алгоритм Стрибог (ГОСТ Р 34.11-2012).

7. Открытый текст

7. Открытый текст

Здесь отображается открытый текст в коммуникации WebRTC, включая открытый текст, отправленный из формы данной области, а также исходный формат зашифрованного текста, отправленного из формы нижней области.

8. Зашифрованное сообщение

8. Зашифрованное сообщение

Здесь отображается расшифрованное зашифрованное сообщение. Код проверяет, является ли формат JSON и содержит ли поле type значение encryptedMessage. При соответствии открытый текст расшифровывается и показывается в данной области.