/ фото Rama CC
Инженеры IETF выпустили два документа. Первый описывает требования к системе обмена сообщениями для реализации протокола MLS, а второй — сам протокол MLS.
Об архитектуре системы обмена сообщениями
Система обмена сообщениями (Messaging Service) включает в себя две службы, которые следят за безопасностью приема/передачи сообщений.
Первая — служба аутентификации (Authentication Service). Отвечает за сохранность личных данных — логина, номера телефона, а также уникальной пары ключей для идентификации клиентов.
Вторая — служба доставки (Delivery Service) — хранит и распределяет между клиентами ключи для обмена зашифрованными сообщениями. Служба доставки оперирует только теми данными, которые нужны для обмена сообщениями, и не трогает личные сведения об отправителях. Это ограничивает «след» метаданных на стороне сервера.
Во многих системах службы доставки и идентификации представлены одним логическим объектом или сервером. Однако в MLS это два отдельных компонента. Авторы решили разделить эти процессы, чтобы MLS можно было использовать вместе с открытыми протоколами авторизации, например OAuth.
Это дает еще одно преимущество. Даже если провайдер сервиса обмена сообщениями контролирует процессы аутентификации и доставки, метаданные будут надежно защищены. У провайдера не получится связать зашифрованные сообщения с открытыми ключами.
Как работает MLS
Пользователи системы обмена сообщениями объединяются в группы. Для создания группы участники «складывают» свои ключи UserInitKey и формируют секрет. UserInitKey представляет собой ключевую пару Диффи — Хеллмана и служит для инициализации отдельных пользователей.
Протокол задействует два типа двоичных деревьев. Первый — дерево Меркла (оно же дерево хешей) — служит для подтверждения подлинности операций, проводимых членами группы. Второй вид — Ratchet-дерево — используется для извлечения их секретов.
В группе можно проводить следующие базовые операции:
- Добавлять нового члена группы (создать диалог).
- Обновлять данные секрета участника группы.
- Удалять члена группы.
Если член группы А хочет создать диалог с B и C, он в первую очередь скачивает их ключи инициализации (InitKeys). После чего эти ключи используются для формирования сообщений GroupAdd, которые должны добавить членов B и C.
Сообщения GroupAdd рассылаются всей группе и обрабатываются по порядку B и C. Когда их ответы возвращаются к А, состояние группы обновляется и в нем отображаются «новоприбывшие». Любые другие сообщения, посылаемые участниками системы до принятия в группу, игнорируются.
В отличие от TLS и DTLS, новый протокол не содержит фазы «рукопожатия» как таковой. MLS использует так называемые сообщения рукопожатий (Handshake Messages). Участники переписки обмениваются ими каждый раз когда, нужно добавить или удалить нового члена группы.
Handshake Message инкапсулирует специальное сообщение об изменении состояния группы, а также включает в себя GroupInitKey, чтобы новый участник смог инициализироваться, и подписи одного из текущих членов группы вкупе с доказательством Меркла (чтобы убедиться в «подлинности» человека, поставившего подпись).
Что ждет MLS
В разработке архитектуры и требований к MLS приняли участие представители Google, Mozilla, Twitter, MIT, французского исследовательского института INRIA и платформы для общения Wire. Сам протокол создали люди из Cisco, Facebook, Google и Оксфордского университета.
/ фото Book Catalog CC
Судьбу протокола будут решать в следующем месяце, когда совет IETF соберется для очередного обсуждения черновых вариантов. Если все пойдет гладко, то через год MLS одобрят в IESG (Internet Engineering Steering Group), и он станет стандартом.
Чем мы занимаемся в ИТ-ГРАД: • IaaS • PCI DSS хостинг • Облако ФЗ-152
Материалы из нашего блога о корпоративом IaaS:
- Бессерверные вычисления в облаке — тренд современности или необходимость?
- Как разместить 100% инфраструктуры в облаке IaaS-провайдера и не пожалеть об этом
- Облачные технологии в финансовой сфере: опыт российских компаний
Комментарии (18)
shifttstas
30.08.2018 20:35Отличная замена Rich Communication Suite (который в свою очередь — замена SMS) будет отлично, если на законодательном уровне в EU это примут как стандарт для замены SMS
willyd
30.08.2018 20:55Отсутствие в рабочей группе людей из крупных телеком вендоров типа Nokia, Ericsson, Huawei не обнадеживает.
shifttstas
31.08.2018 15:01А зачем они там? Это больше про вендоров телефонов
willyd
31.08.2018 16:39Я думал вы писали замену СМС. Как вы представляете себе замену этой услуги без организации какой-то инфраструктуры, которую кто-то будет поддерживать и отвечать за ее соответствие стандарту.
В моем понимании, чтобы заменить СМС, нужно:
1. Глобальный идентификатор. С ним вроде все ок, есть е.164.
2. Провайдер, который будет поддерживать Authentication Service, который будет соответствовать протоколу и сможет связываться с любым другим провайдером для передачи ключей и добавления абонента.
4. Провайдер, который будет поддерживать Delivery Service, который будет соответствовать стандарту и сможет аутентифицировать получателей с помощью Authentication Service, и гарантировано доставлять сообщения с условием поддержки расширений.
А если будут только вендоры телефонов, то будет еще с десяток фейстаймов, а не СМС.shifttstas
31.08.2018 17:22Посмотрите на RCS — там это уже работает. Стандарт — открытый, просто при наличии RCS на трубке канал СМС идёт туда + обратная совместимость.
willyd
31.08.2018 17:36Я о том и пишу. RCS продвигался GSMA, а том кроме вендоворов довольно весомое слово имеют операторы. Ну и GSMA его глобально утвердили. И его должен поддерживать провайдер.
Тут же пока рабочая группа ограничена учеными и несколькими людьми из интернет-компаний, всего 6 человек.
Stas911
30.08.2018 21:31А для чего обязательно стардартом менять СМС? Чем мессенджеры не угодили?
LAG_LAGbI4
31.08.2018 13:15мессенджеров много, каждый использует свой протокол. слушать не удобно
Stas911
31.08.2018 18:08все предыдущие попытки сделать единый протокол для instant messaging закончились ничем (ну то есть протоколы-то сделали, но глобальной поддержки нет ни у кого) — что заставляет думать, что в этот раз получится?
mva
01.09.2018 09:021) тоже хотел написать про одновременное использование слов "безопасность" и "номер телефона" в одной статье
2)
ключевую пару Диффи-Хеллмана
Ну, такое...
Neuromantix
А зачем очередному «безопасному» мессенджеру нужен номер телефона? Почему нельзя ограничиться одним логином?
willyd
Про номер телефона нет ни слова, ни в статье, ни в черновиках. Это у вас такая бессознательная реакция?
ildarz
На самом деле есть, но просто как один из примеров «человеческого» идентификатора, который нужно сопоставлять с ключевой парой, идентифицирующей пользователя.
willyd
Я даже не заметил. Там основное было на счет связи один-к-одному, а какой идентификатор будет использоваться не акцентировалось.
The basic function of the Authentication Service is to provide atrusted mapping from user identities (usernames, phone numbers,
etc.), which exist 1:1 with Members, to identity keys, which may
either be one per Client or may be shared amongst the Clients
attached to a Member.
Stas911
Как обычно обоснуют тем, что нужно же как-то доступ восстанавливать в случае угона. Но мы-то знаем зачем.
roscomtheend
Для справки — ваши «знания» для большинства абсолютно идентичны заявлениям производителей (т.е. не заслуживают доверия), даже хуже — у них хоть в теории есть что-то типа репутации, в отличии от.
ildarz
1. В статье описан не мессенджер, а протокол.
2. Номер телефона там не нужен (хотя может использоваться).