company_banner

IETF предложили новый стандарт для обмена сообщениями — что нужно знать

    Инженерный совет интернета (IETF) опубликовал черновик нового протокола — Message Layer Security (MLS). Его задача — обеспечить защищённую передачу сообщений между двумя устройствами. Он описывает абстрактные структуры данных, которые можно использовать не только в чат-приложениях, но и для работы с TLS 1.3 и JSON. Расскажем о принципах работы MLS.


    / фото 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), и он станет стандартом.



    Чем мы занимаемся в ИТ-ГРАД: • IaaSPCI DSS хостингОблако ФЗ-152



    Материалы из нашего блога о корпоративом IaaS:



    ИТ-ГРАД
    vmware iaas provider

    Comments 19

      +1
      А зачем очередному «безопасному» мессенджеру нужен номер телефона? Почему нельзя ограничиться одним логином?
        0
        Про номер телефона нет ни слова, ни в статье, ни в черновиках. Это у вас такая бессознательная реакция?
          0
          На самом деле есть, но просто как один из примеров «человеческого» идентификатора, который нужно сопоставлять с ключевой парой, идентифицирующей пользователя.
            0
            Я даже не заметил. Там основное было на счет связи один-к-одному, а какой идентификатор будет использоваться не акцентировалось.
            The basic function of the Authentication Service is to provide a
            trusted 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.
          –4
          Как обычно обоснуют тем, что нужно же как-то доступ восстанавливать в случае угона. Но мы-то знаем зачем.
            0
            Для справки — ваши «знания» для большинства абсолютно идентичны заявлениям производителей (т.е. не заслуживают доверия), даже хуже — у них хоть в теории есть что-то типа репутации, в отличии от.
            +1
            1. В статье описан не мессенджер, а протокол.
            2. Номер телефона там не нужен (хотя может использоваться).
            0

            Отличная замена Rich Communication Suite (который в свою очередь — замена SMS) будет отлично, если на законодательном уровне в EU это примут как стандарт для замены SMS

              0
              Отсутствие в рабочей группе людей из крупных телеком вендоров типа Nokia, Ericsson, Huawei не обнадеживает.
                0

                А зачем они там? Это больше про вендоров телефонов

                  0
                  Я думал вы писали замену СМС. Как вы представляете себе замену этой услуги без организации какой-то инфраструктуры, которую кто-то будет поддерживать и отвечать за ее соответствие стандарту.
                  В моем понимании, чтобы заменить СМС, нужно:
                  1. Глобальный идентификатор. С ним вроде все ок, есть е.164.
                  2. Провайдер, который будет поддерживать Authentication Service, который будет соответствовать протоколу и сможет связываться с любым другим провайдером для передачи ключей и добавления абонента.
                  4. Провайдер, который будет поддерживать Delivery Service, который будет соответствовать стандарту и сможет аутентифицировать получателей с помощью Authentication Service, и гарантировано доставлять сообщения с условием поддержки расширений.
                  А если будут только вендоры телефонов, то будет еще с десяток фейстаймов, а не СМС.
                    0

                    Посмотрите на RCS — там это уже работает. Стандарт — открытый, просто при наличии RCS на трубке канал СМС идёт туда + обратная совместимость.

                      0
                      Я о том и пишу. RCS продвигался GSMA, а том кроме вендоворов довольно весомое слово имеют операторы. Ну и GSMA его глобально утвердили. И его должен поддерживать провайдер.

                      Тут же пока рабочая группа ограничена учеными и несколькими людьми из интернет-компаний, всего 6 человек.
                0
                А для чего обязательно стардартом менять СМС? Чем мессенджеры не угодили?
                  +1
                  мессенджеров много, каждый использует свой протокол. слушать не удобно
                    0

                    RCS слушать можно, а то что в статье — нет

                      0
                      все предыдущие попытки сделать единый протокол для instant messaging закончились ничем (ну то есть протоколы-то сделали, но глобальной поддержки нет ни у кого) — что заставляет думать, что в этот раз получится?
                  0

                  1) тоже хотел написать про одновременное использование слов "безопасность" и "номер телефона" в одной статье


                  2)


                  ключевую пару Диффи-Хеллмана

                  Ну, такое...

                    0
                    Было бы интересно узнать, в чём несовместимость безопасности и номера телефона при end-to-end шифровании сообщений, особенно для большинства коммуникаций, где номер телефона секретом не является (клиент-фирма, фирма-фирма и большинство клиент-клиент для людей, не нарушающих закон и далеких от политики).

                  Only users with full accounts can post comments. Log in, please.