Sanket.Chat
Безопасность: шифрование

Сквозное шифрование по Signal Protocol и повсеместное применение AES-256

SANKET (Sanket.Chat) от Tosh Defence обеспечивает сквозное шифрование каждого сообщения, реакции и зашифрованной широковещательной рассылки с помощью Signal Protocol через официальную, независимо проверенную библиотеку libsignal от Signal, используя протокол согласования ключей PQXDH и Double Ratchet с SPQR. Для файлов, кадров вызовов, передачи вызовов, локального хранилища и каждого сеанса TLS, завершающегося на серверах развёрнутой системы, используется AES-256 без возможности перехода на AES-128 и без режима совместимости.

Политика разработки SANKET - использовать AES-256 или отклонять операцию; это правило закреплено в коде. Если шифрование нельзя выполнить точно по проекту, операция отклоняется, а не выполняется с ослабленной защитой.

Сообщения: Signal Protocol без изменений

Sanket использует официальную библиотеку libsignal от Signal для шифрования всех сообщений; на iOS, Android, настольных платформах и сервере применяется один и тот же выпуск библиотеки. Платформа не содержит повторной реализации Signal Protocol или альтернативного шифра для сообщений.

Сеансы устанавливаются с помощью PQXDH, постквантового расширения X3DH, сочетающего согласование ключей на основе X25519 с инкапсуляцией по алгоритму Kyber. Затем сообщения шифруются с помощью Double Ratchet: ключ каждого сообщения разворачивается в ключ AES-256, ключ HMAC-SHA256 и вектор инициализации; сообщение шифруется с помощью AES-256 и проходит проверку подлинности с помощью HMAC-SHA256, после чего ключ удаляется. Параллельно в каждом сеансе работает разреженный постквантовый механизм Double Ratchet от Signal.

Резервный механизм намеренно не предусмотрен

Клиент отказывается отправлять сообщение, если шифрование с помощью libsignal невозможно. Устройства, не публикующие ключ идентификации libsignal, пропускаются: сообщение не отправляется им в открытом виде. Устаревшие маркеры открытого текста отклоняются, а сервер не принимает наборы ключей, не соответствующие формату libsignal. Передача содержимого сообщений в открытом виде или с использованием альтернативного шифра не предусмотрена.

Группы без общего ключа

Групповые сообщения шифруются путём попарной рассылки: устройство отправителя отдельно шифрует сообщение для каждого доверенного устройства каждого участника, используя для каждого устройства отдельную сессию libsignal. При изменении состава группы повторное создание ключей не требуется, а исключённый участник просто перестаёт входить в список получателей рассылки.

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

Файлы и звонки

Содержимое, имена и типы вложений шифруются на устройстве с помощью AES-256-GCM с отдельным случайным 256-битным ключом для каждого файла; этот ключ передаётся внутри сообщения libsignal.

Голосовая и видеосвязь защищены на двух уровнях. Кадры каждого участника шифруются сквозным образом с помощью AES-256-GCM с использованием отдельного ключа для каждого отправителя. Ключ обновляется каждые 200 миллисекунд, что даёт пять новых ключей шифрования кадров в секунду для каждого отправителя. При каждом подключении или выходе участника создаётся новый случайный ключ. Между устройством и медиасервером SRTP допускает только AEAD_AES_256_GCM. Медиасервер пересылает зашифрованные кадры, которые не может расшифровать; архитектура исключает запись звонков на стороне сервера.

  • AES-256-GCM для каждого файла
  • Ключи вызова для каждого отправителя, а не общий ключ для всей конференции
  • Пять ключей для шифрования кадров в секунду на каждого отправителя
  • Только SRTP с AES-256-GCM

Передача и хранение данных

Каждое соединение клиентского приложения использует TLS 1.3 с TLS_AES_256_GCM_SHA384 либо TLS 1.2 с ECDHE и AES-256-GCM, если этого требуют сетевые стеки платформы. AES-128, ChaCha20, наборы шифров в режиме CBC и статический RSA исключены, а гибридная постквантовая группа X25519MLKEM768 предлагается первой. Каждое одобренное устройство также может подтверждать свою подлинность с помощью собственного клиентского сертификата при взаимной аутентификации по TLS.

На устройствах локальные базы данных шифруются с помощью AES-256 и защищаются от подмены с помощью HMAC-SHA256, а на телефонах хранилище протокола и секретные данные устройства шифруются ключом, защищённым аппаратными средствами Secure Enclave, StrongBox или доверенной среды исполнения.

Техническое подтверждение

Изучите подробности в техническом документе Sanket

Все утверждения на этой странице подробно изложены в общедоступном техническом документе Sanket по безопасности и архитектуре. Его можно читать бесплатно и без регистрации.

Часто задаваемые вопросы

Часто задаваемые вопросы

Задайте вопрос нашей команде

Использует ли SANKET протокол Signal Protocol?

Да. Sanket шифрует все сообщения на каждой платформе с помощью официальной библиотеки libsignal от Signal, используя протокол согласования ключей PQXDH и механизм Double Ratchet с SPQR. Платформа не содержит собственной реализации протокола.

Использует ли SANKET шифрование сообщений по AES-256?

Да. Для сообщений в libsignal используется AES-256-CBC с HMAC-SHA256; для файлов, кадров звонков, передачи звонков, локального хранения и TLS - AES-256-GCM. Резервного перехода на AES-128 нет.

Голосовые и видеозвонки защищены сквозным шифрованием?

Да. Кадры звонка защищены сквозным шифрованием AES-256-GCM с использованием ключей для каждого отправителя, передаваемых через libsignal. Для каждого отправителя создаётся 5 новых ключей кадров в секунду. Трафик передаётся внутри протокола SRTP, допускающего только AES-256-GCM.

Реакции и широковещательные сообщения зашифрованы?

Да. Реакции и зашифрованные широковещательные сообщения передаются как сообщения libsignal и, как и все остальные сообщения, защищены сквозным шифрованием. Приоритет широковещательного сообщения, крайний срок подтверждения и срок действия также входят в зашифрованные данные.

Использует ли SANKET ключи отправителя для групп?

Нет. SANKET шифрует групповые сообщения отдельно для каждого доверенного устройства каждого участника, используя для каждого устройства отдельный сеанс libsignal, поэтому общего группового ключа нет.

Какие версии TLS поддерживает Sanket?

Предпочтителен TLS 1.3, исключительно с TLS_AES_256_GCM_SHA384. TLS 1.2 допускается только с ECDHE и AES-256-GCM. Версии ниже TLS 1.2 не допускаются, а гибридный постквантовый обмен ключами X25519MLKEM768 предлагается в первую очередь.

Прошла ли libsignal аудит?

Да. SANKET построена на независимо аудированной библиотеке libsignal проекта Signal, а протокол PQXDH прошёл формальный анализ.

Обсудите криптографию SANKET с нашими инженерами

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