Об очень шпионском методе аутентификации

    Итак, мы засылаем супер-секретных агентов Алису и Боба во вражескую страну под прикрытием. В процессе миссии им предстоит связаться и работать вместе, обмениваться информацией, обычные шпионские дела. Конечно, все это нужно делать с соблюдением всех возможных правил и техник безопасности.


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


    Но как тогда им опознать своего товарища по штабу?


    КДПВ


    TL;DR — изобретаем механизм аутентификации пользователей с помощью стеганографии для воображаемого трехсимвольного агентства несуществующей страны.


    О волках и овечьих шкурах


    Прикрытие есть прикрытие, поэтому ни Алиса, ни Боб не должны вызывать никакими своими действиями подозрения. Правильное планирование подразумевает паранойю о постоянной слежке за ними на всех возможных уровнях. В данном посте не будет рассматриваться задача непосредственного обмена информацией (она заслуживает своей отдельной серии), но лишь способ удостовериться, что она передается тем, кем надо, тому, кому надо.


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


    Что делать?


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


    Посмотрим хотя бы на такую сцену: два человека в длинных пальто сходятся в публичном месте и обмениваются очень странными фразами. Если инициирующая фраза и ответ верны, то аутентификация прошла успешно, а люди обмениваются папками с пометкой "Top Secret" и расходятся в неизвестных направлениях.


    Сразу очевиден недостаток такой схемы — фразы надо хранить в секрете и часто менять, что не очень-то и просто на вражеской территории. При этом для того, чтобы не быть произнесенными случайно и не привести к случаю с КДПВ, они делаются довольно выделяющимися и случайными, а значит, могут выдать агентов, их произносящих.



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



    Стеганография (опять?)


    Ежу понятно, что возможность скрыть одно в другом в такой ситуации выглядит как никогда привлекательно. И в самом деле, даже описанный метод является ее подвидом — кодовые фразы можно рассматривать как контейнеры со всего одним битом информации внутри.


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


    А о чем тогда?


    В отличие от криптограмм, стегоконтейнеры обладают очевидным преимуществом — контекстом применения. Любой текст, изображение, аудиофайл и пр. помимо очевидного содержимого несет также возможность его естественного обсуждения и может быть отправлен не просто так с бухты-барахты, а в процессе не вызывающего подозрения диалога.


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


    • А -> Б: миловидное сообщение с запросом стеганографического контейнера определенных параметров;
    • Б: выбирает контейнер C, соответствующий запрошенному контексту и параметрам;
    • Б: аналогичным образом создает сообщение M;
    • Б -> А: C' = Embed(C, M, K);
    • А: Проверяет C' на соответствие поставленным параметрам;
    • А -> Б: M' = Extract(C', K);
    • Б: Проверяет, совпадают ли M и M'.

    Такой протокол обладает очевидными недостатками — Алиса и Боб должны обладать как общим ключом, так и функциями встраивания и извлечения. Их компрометация может привести к возможности детального анализа метода аутентификации противника и поставит под угрозу как других пользователей, так и сам штаб. Надо что-то исправлять.


    Исполнитель не черепашка


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


    Ну не прелесть ли?


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


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


    Для встраивания же данных нам нужна последовательность формы: (f1, S1, i, D1), (f2, S2, j, D2)..., где:


    • Di — некоторая часть встраиваемых данных;
    • i, j — индексы элементов контейнера;
    • fi: (State, Element, D) -> (State, Element) — функция встраивания;
    • Si — некоторое состояние, контекст операции, (El', S[i+1]) = fi(Si, El, Di).

    Для извлечения не нужно хранить части данных (К.О.), поэтому достаточно троек: (g1, S1, I1), (g2, S2, I2)... с аналогичными значениями, только gi: (State, Element) -> (State, D).


    Все это можно изобразить симметричной диаграммой ниже. Если по каким-то причинам понятности достичь мне не удалось, то не страшно, просто читай дальше.


    Ну или не более


    Видно, что функция встраивания имеет большее число степеней свободы. В отличие от своей сестры, она модифицирует контейнер, при этом делает это на основе двух независимых элементов — встраиваемых данных и элемента. Благодаря, или, точнее, из-за этого возможно два глобальных подхода к реализации алгоритма стеганографии такой системой:


    1. Выбрать наиболее оптимальные в соответствии с функцией встраивания индексы элементов для изменения (наименее заметные или его не требующие его вовсе) и передавать образованную последовательность привязанной к определенному контейнеру. При таком подходе требуется их изолировать друг от друга до возникновения необходимости проведения встраивания с использованием классических методов типа шифрования и прочих защищенных носителей;
    2. Найти такие метод разбиения контейнера на элементы и функцию встраивания, что любое ожидаемое их изменение ею будет равноценно незаметным. В этом случае последовательность не зависит от контейнера и может быть создана хоть полностью случайным генератором. Минусом идут меньшая гибкость и отсутствие контроля худшего случая. С другой стороны, такой подход проще и удобнее при применении в поле, поэтому ниже я буду использовать именно его.

    Если для алгоритма не требуется состояние, то все вышесказанное остается в силе, просто без одной буквы и блока на диаграмме. Без него даже проще, на самом деле.


    И зачем оно нам?


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


    Добавляем асимметричность


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


    То есть, мы можем взять последовательность встраивания, добавить новые операции, перемешать это все, да так, что результат останется тем же. Разве что, при наличии состояния, нужно будет его отслеживать и добавлять отдельно необходимые изменения в последовательность. Именно поэтому без него проще, да.


    Так или иначе, после подобного замешивания и зашумления даже сам встраивающий уже не сможет понять, что же он такого, собственно, встраивает: любая последовательность из N операций будет представлять N! потенциально встраиваемых сообщений — по одному на каждую перестановку встраиваемых частей. При этом само N находится под большим вопросом. Поэтому можно звать такие последовательности открытыми — они не дают никакой информации ни о встраиваемом сообщении, ни об используемом алгоритме и ключе.


    При извлечении информации же нам очень важен как порядок (для восстановления того самого верного сообщения из всех возможных), так и количество извлекаемых частей, поэтому извлекающие последовательности остаются неизменяемыми с момента появления на свет. Так как они неявно содержат информацию об используемом ключе, генераторе и алгоритме, их, как животных из красной книги, нужно хранить и беречь. И держать в секрете.


    При чем тут асимметричность? Дело в том, что теперь каждой извлекающей последовательности сопоставляется бесконечное число встраивающих. А восстановление одной по другой — в общем случае задача неразрешимая.


    Эксплуатируем


    Забываем про любую около-математику и возвращаемся к исходной задаче — как же нам заслать Алису с Бобом на вражескую территорию, чтобы:


    • в лицо друг друга не знали
    • никаких секретных алгоритмов на руках не имели
    • но могли удостовериться друг в друге при связи по открытому каналу?

    Ну с первым пунктом все понятно, мы просто им не даем никакой явной информации друг о друге, никаких общих ключей. Для второго нужно вспомнить описание протокола повыше. Теперь мы можем исключить из использования непосредственно алгоритмы Embed и Extract, представляющие потенциальную гостайну и все такое. И, с учетом сказанного, для третьего можно составить следующий двухэтапный протокол.


    Выработка аутентификационной информации до начала миссии со штабом в роли доверенной стороны Трента:


    • Т: выбирает секретный алгоритм и секретный ключ K, создает с их помощью:
      • извлекающую последовательность Ex;
      • подходящий для проведения аутентификации (ниже) контекст Ctx;
    • Т -> А: Ctx, Ex;
    • Т: используя Ex и созданный контекст, генерирует:
      • не использованное ранее для выбранных агентов сообщение M из числа частей |Ex|;
      • одноразовую последовательность Em, делая ее открытой описанным выше методом;
    • Т -> Б: Em, h(M), при желании создает дополнительные наборы.

    Таким образом, у Алисы оказывается лишь одна последовательность на все случаи жизни и контекст будущего контакта, а Боб становится счастливым обладателем набора одноразовых последовательностей и хэшей сообщений, ими встраиваемых.


    Протокол аутентификации уже во время миссии выглядит так:


    • А -> Б: инициирующее сообщение IM на основе контекста Ctx с описанием контейнера;
    • Б: выбирает подходящий C ~ IM;
    • Б -> А: C' = Em( C );
    • А: проверяет на соответствие C' ~ IM (так как изменения незаметны, должно сохраниться);
    • А -> Б: M' = Ex( C' ), помечает M' как использованное;
    • Б: проверяет, h(M') == h(M), уничтожает Em, h(M).

    Внимательный читатель заметит, что до проведения протокола что Алиса, что Боб обладают просто набором информации, которая сама по себе ничего не значит ни для них, ни для потенциального противника, и лишь во время проведения "играет красками".


    Каждый открытый набор Боба используется только раз, что контролируется предпоследним шагом Алисы. При встрече ранее использованного M (а значит, и невидимой ею Em) другим лицом она понимает, что один из ее "соратников" — фальшивка.


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



    Окей, вот так вот это все выглядит слишком сложным и непонятным. Кто-нибудь до сюда добрался?


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


    Высокие технологии


    Итак, осталось лишь написать все необходимое для проведения протокола. Ну не руками ведь все делать (хотя и так можно). И сегодня жертвой моего кода станет… крутит колесо фортуны… Джава? Ну и ладно, заодно все в STL'е будет, ничего искать не придется.


    Начнем с необходимого API. Для работы необходимо лишь определить класс массива элементов контейнера с возможностью получать и изменять элементы по индексу:


    class MyContainer implements StegoContainer<MyElement> {
        public MyElement get(int i) {
            // получить i-й элемент
        }
        public void set(int i, MyElement v) {
            // задать i-й элемент
        }
        public int size() {
            // получить количество элементов
        }
    }

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


    StegoMachine<MyState, MyElement> myMachine = new StegoMachine(
        initialState, new MyContainer<MyElement>(/* загружаем контейнер */)
    );
    final StegoEmbed myEmbed = (st, el, dp) -> {
        // встраивание части данных dp в элемент el при состоянии st
    };
    final StegoExtract myExtract = (st, el) -> {
       // извлечение части данных из el при состоянии st
        return dp;
    };
    
    // Встраиваем части сообщения
    MyDataPart part = /* Создаем элемент данных */;
    myMachine.exec(1337, myEmbed, part);
    //...
    
    // Получаем состояние для изменения/сброса, если хотим
    // сохранить изменения перед другими операциями
    State currState = myMachine.getState();
    //...
    
    // Извлекаем части сообщения
    part = myMachine.exec(80085, myExtract);
    //...
    
    // Получаем контейнер для перезаписи или еще чего
    MyContainer container = (MyContainer) myMachine.getContainer();

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


    Генераторы последовательностей могут работать как угодно и не обладают общим API. Частью данных может являться в общем случае вообще что угодно, от одиноких битов до наскальной живописи в отдельной кодировке.


    Пример реализации


    О методе


    В качестве примера реализации, с использованием созданных интерфейсов я реализовал простой алгоритм из семейства LSB для растровых изображений со сжатием без потерь. Их элементами являются пиксели, не имеющие соседов по младшему биту всех компонент RGB. Функция встраивания работает с одинокими битами исходных данных и просто изменяет младший бит значения одной из компоненты (на какую укажет индекс).


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


    Тем не менее, это очень простой метод, не советую его использовать настоящим шпионам.


    О хэшах


    Так как текст имеет свойство искажаться в зависимости от симулируемой личности агента (некоторые не ставят заглавные, другие любят ставить смайлики и пр, третьи вообще неграмотны), то для расчета хэша я предлагаю использовать sha256, но только от печатных слов, переведенных в нижний регистр:


    h("Hello world?...") == h("hello, world!11")

    Об интерфейсе


    Программный комплекс состоит из двух частей — одна для генерации последовательностей и прочих хэшей для Трента, другая для проведения встраивания и проверки полученных сообщений на соответствие.


    Работа с обеими происходит из командной строки посредством ее аргументов и потоков ввода-вывода, других интерфейсов не завезли (страх и ужас). Все-таки быть что работником штаба, что шпионом — означает иметь какую-никакую квалификацию. Ну а если нет — все равно покажу на примере.


    Вот так выглядит хэлп

    Скриншот usage



    Что им всем делать-то?


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


    Например, пусть Боб будет фрилансером, занимающимся графикой, а Алиса — его заказчиком. Аутентификация же будет происходить под видом заказа создания графики / дизайна / чего-нибудь еще.


    Сообщаем эту полезную информацию обоим и возвращаемся к самому протоколу. Подготовим заранее подходящее встраиваемое сообщение M.txt, минимизируя число знаков в нем: "отлично мне подходит куда перечислять деньги". Генерируем Em и Ex с помощью утилиты для Трента:


    Trent@HQWorkstation:~$ java -jar HQUtil.jar -ex $(stat -c%s "M.txt") 4096  > Ex.txt
    Trent@HQWorkstation:~$ cat Ex.txt | java -jar HQUtil.jar -em "$(cat M.txt)" 0.25 4096 > Em.txt
    Trent@HQWorkstation:~$ cat M.txt | java -jar HQUtil.jar -h > hash.bin

    Тут $(stat -c%s "M.txt") возвращает размер сообщения в байтах, а 4096 — ограничение для диапазона генерируемых индексов (чтобы позволить использовать контейнеры поменьше). Аналогично, $(cat M.txt) используется для передачи самого сообщения в параметр командной строки. В принципе, можно обойтись и без баша, используя свой ручной труд, но кому как удобнее.


    Ex.txt передается Алисе, Em.txt и hash.bin — Бобу. Теперь представим, что агенты успешно внедрились и хотят связаться друг с другом — переходим к выполнению протокола. Боб размещает свое резюме или предложение работы на какой-нибудь бирже, а Алиса начинает общение:


    Алиса: Привет, я нашла тебя на %фриланс_бирже%
    Алиса: Мне нужно качественное изображение красного зонта на боку, с металлической ручкой. Сможешь сделать?
    Боб: Хорошо, как дойдут руки

    Боб ищет изображение зонтика, может быть даже рисует сам, если душа творческая, немного сжимает / накладывает ватермарку (или что там нынче фрилансеры делают) и выполняет:


    Bob@PC:~$ cat Em.txt | java -jar SpyUtil.jar -e umbrella.png

    Подождав некоторое время, симулируя работу, если в реальности ее не делал, он отправляет Алисе полученный контейнер, естественно, придерживаясь контекста:


    Боб: Сделал, вот превью, полную версию отправлю после оплаты

    Передает зонтик с сообщением, 670кб


    Та, в свою очередь, извлекает хранимое внутри сообщение:


    Alice@PC:~$ cat Ex.txt | java -jar SpyUtil.jar -e umbrella.png
    отлично мне подходит куда перечислять деньги

    Превращает набор слов в нормальное предложение и отправляет его Бобу:


    Алиса: Отлично, мне подходит, куда перечислять деньги?
    

    Тот проверяет верность сообщения:


    Bob@PC:~$ java -jar SpyUtil.jar -c hash.bin "Отлично, мне подходит, куда перечислять деньги?"
    Отлично, мне подходит, куда перечислять деньги? - Correct
    

    И продолжает непринужденное общение, если все окей. Весь диалог со стороны наблюдателя выглядит как-то так:


    Гифка на 500 килобайт


    Понятное дело, что ничего подозрительного контр-разведка во всем этом перехваченным не найдет. На самом деле, даже методы стегоанализа в таком случае далеко не всегда будут применяться — ну заказал кто-то за 5 баксов картинку зонта, нашли, чем удивить интернет. Вычислительные ресурсы и люди не бесконечны, чтобы каждую такую ситуацию проверять. Аутентификация же прошла успешно, занавес.


    -> GitHub

    Поддержать автора
    Поделиться публикацией

    Комментарии 24

      +2
      Возможно эта статья непринужденный способ передачи дешифратора. Компетентным органам имеет смысл задуматься.
        0

        В контексте Хабра целью является добыча кармы

          +1

          Да ну, что с ней потом делать-то?

          0
          А не проще было Алисе послать Бобу сообщение — «У вас продается славянский шкаф»?
            0

            Проще, конечно, но метод обладает кучей недостатков, которые я, среди прочего, описал в посте

              0

              Алиса размещает на продавательной площадке предмет, знакомый по фотографии Бобу. Отзывом служит предложенная Бобом цена. или интервал между сообщениями.
              Кстати, когда вижу объявление вида "отдам бесплатно пластиковые бутылочки" с фотографиями, мне начинает казаться, что эта схема уже работает.

                0

                Это обычные кодовые фразы, существует и работает (в газетах в частности). Минусы все еще никуда не исчезли)

            0
            Да, да, я читал внимательно, в меру своей базы знаний. Можете считать мой коммент «репликой из зала». Но есть уйма возможностей идентификации и более простыми способами. И даже добавить уникальный «водяной знак» это тоже один из многих способов.
            В данном же случае, понятно, вы продемонстрировали ещё один способ.
            (кажется этот ответ не в ту ветку заслал ??)
              0

              Так точно, сэр, и у всех свои недостатки
              Про ветку не страшно — тут пока не намечается оживленной дискуссии, чтобы это помешало кому-то)

              0
              Мне кажется, штаб Трента сломает мозг если Алиса будет продавцом мороженного, а Боб — мойщиком окон…
                +1

                Сайты знакомств, паблики и сообщества, форумы по интересам, посты на хабре… В конце-концов, мойщик окон может пойти купить себе мороженого


                Вот уж что-что, а найти повод для начала общения в наше время крайне легко)

                  +1
                  Так-то оно так, но вы ведь ставите условие:

                  мы просто им не даем никакой явной информации друг о друге, никаких общих ключей

                  Боюсь, Боб заработает ангину прежде чем найдёт свою Алису… :)
                    0

                    Ну совсем никакой не знать они не могут — иначе тут и вариант из поста не пройдет, столетями будут искать друг-друга на фриланс-биржах)


                    Надо искать компромис: и внешность с именами да явками не разглашать, и уж на волю судьбы их встречу не отпускать

                    +1

                    Мойщик окон вполне может заказать у мороженщицы, которая по вечерам фрилансит артом, рекламный зонтик с надписью "ты туда не ходи, ты сюда ходи Обойдите это место стороной — вверху Боб моет окна, телефон 223-322-2323"

                  0
                  Поскольку я все же осилил пройти через все описание автора краткий итог:
                  Автор придумал свой вариант пороговой схемы разделения секрета (2,2) и предлагает его использовать в двусторонней аутентификации.
                  Центр генерирует некоторый секрет и делит его по схеме на две части.
                  До обмена сообщениями первый участник (А) получает только свою часть, а второй (Б) свою часть и способ проверки (хэш).
                  Во время обмена Б отправляет А свою часть, А собирает секрет и отправляет его Б, Б проверяет.
                  Первая пересылка маскируется стеганкой, вторая маскируется тем, что общий секрет выбран так, что похож на нормальную ответную реплику.
                  Надежность схемы разделения мне разбирать лень, но, честно говоря, но по косвенным признакам она не похожа на безопасную, хотя могу ошибаться.
                  Глобально алгоритм лучше чем аутентификация плейнтекстом, но, я думаю, что хуже, чем классические challenge–response.
                    0

                    Близко, но не совсем. Точнее, если уж рассматривать как схему разделения секрета (не совсем идеально подходит под определение, но я не боец за чистоту расы), то все правильно до слов "первая пересылка"


                    Дело в том, что пересылка не просто "маскируется стеганкой" — часть секрета буквально является передаваемым контейнером. То есть, Боб владеет своей частью (Em), но ничего не может с ней поделать, пока Алиса не выберет форму (то самое изображение зонтика), в которой хочет получить ее отражение (Em©). Ее же частью является метод извлечения (Ex) неизвестной Бобу информации, которую тот может проверить благодаря хэшу. Самим секретом является та самая замаскированная ответная реплика, тут все снова верно.


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


                    Про надежность — готов ответить на любые вопросы. Я общительный человек, и меня очень радует, что кто-то разбирает мои каракули. А сам протокол, вообще говоря, как раз находится в категории "вывоз-ответ" — секретные данные никуда не передаются и живут лишь на машинах Алисы и Боба — поэтому я не особо понял, к чему последнее замечание)

                      0
                      Как будто владея набором байт, который является частью из классической схемы разделения можно что-то сделать до обмена сообщениями. Вот никак не вижу усиления от того, что стеганка используется как часть секрета.

                      Давайте посмотрим на такую ситуацию — некоторая служба знает алгоритм (Керкгоффс), предполагает что некоторые Алиса и Боб шпионы, но не имеет доступа к их данным, только к обмену. Они видят что А и Б обменялись картинкой и репликой. В этот момент им нужно щелкнуть переключателем, чтобы разорвать связь А и Б (забанить на площадке общения, как вариант). Теперь кто угодно, знающий ответную реплику, может выдавать себя за А. Да, можно запастись миллионом исходных фраз. Но очевидным улучшением будет идея не заготавливать такие фразы, а иметь возможность проверять это как-то на лету. И тут мы получаем самую обычную PKI с сертификатами и подписями, которую можно использовать для любого алгоритма взаимной аутентификации.

                      Я не очень понимаю назначение вашего протокола, в плане какой недостаток он нивелирует? Общий секрет все равно есть, просто в производном виде. MITM как работал, так и работает.

                        0
                        кто угодно, знающий ответную реплику, может выдавать себя за А

                        Это, конечно же, неверно. Я даже расписал, почему. Во-первых, любая последовательность Em и соответствующий отпечатоп h(M) Боба одноразовые, поэтому знание M противнику ничего не даст — набор данных уже был использован. Во-вторых, никто не мешает ему провести потом повторные раунды аутентификации, так как единственной Ex Алисы сопоставлено бесконечное множество его частей. В-третьих, само построение протокола скрывает шаги аутентификации, поэтому у третьей стороны в общем случае нет способа понять, для кого и когда дергать рубильник. А даже если каким-то образом и поняли — в общем случае нет возможности определить, какая часть диалога содержит передаваемый Бобом контейнер (от текста до ссылки на ютуб), а какая — извлеченную из него информацию Алисой (ответную "реплику", которой может быть и не текст вовсе)


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

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


                        в плане какой недостаток он нивелирует

                        В классических системах с открытым ключом передаваться между сторонами будет около-случайный набор байт, который сам по себе содержит информацию о связи двух лиц, а именно — они хотят что-то скрыть от посторонних, а сама форма данных может даже раскрывать сампротокол. Я стараюсь решить именно эту задачу, не давая наблюдателю абсолютно никакой информации об обмене информации

                          0
                          одноразовые, поэтому знание M противнику ничего не даст — набор данных уже был использован.

                          Я понимаю, что можно взять миллион вариантов для M, но не вижу смысла тратить место, если PKI решает все это проще.

                          у третьей стороны в общем случае нет способа понять, для кого и когда дергать рубильник

                          При таком доверии к стеганке — просто в первом же сообщении отправляйте секретные данные. Сам факт использования стеганки будет означать, что А и Б из одного агентства. Если кто-то из них левый человек, то либо данные не будут извлечены, либо не будут положены — хуже не сделается.

                          В классических системах с открытым ключом передаваться между сторонами будет около-случайный набор байт, который сам по себе содержит информацию о связи двух лиц, а именно — они хотят что-то скрыть от посторонних, а сама форма данных может даже раскрывать сампротокол. Я стараюсь решить именно эту задачу, не давая наблюдателю абсолютно никакой информации об обмене информации

                          Если цель такая, то прошу прощения, я думал тут речь о криптографии. А придумывать системы которые базируются на неразглашении алгоритма можно по 10 штук за час.
                            0
                            базируются на неразглашении алгоритма

                            Алгоритм открыт, неизвестны лишь части Алисы и Боба. Не знаю, что в моей фразе могло навести на эту мысль. Невозможность определения проведения протокола не означает, что он секретен, лишь что был правильно выполнен. Скрытый канал Эль Гамаля тоже нельзя просто так отличить от обычной подписи, например, но мы его не записываем в категорию "не криптографии"


                            Я понимаю, что можно взять миллион вариантов для M, но не вижу смысла тратить место, если PKI решает все это проще

                            Использование PKI легко определить даже на глаз, она решает задачу явной аутентификации, а не скрытой


                            просто в первом же сообщении отправляйте секретные данные

                            Для этого как раз потребуется держать общий ключ и, что важнее, алгоритм в секрете. Я думал, тут речь о криптографии)

                              0
                              В-третьих, само построение протокола скрывает шаги аутентификации, поэтому у третьей стороны в общем случае нет способа понять, для кого и когда дергать рубильник.


                              Вот эти строки навели на мысли. Потому что из текущего описания мне понятно в какой момент дергать рубильник. Неизвестно только если вы скрываете алгоритм.

                              Использование PKI легко определить даже на глаз, она решает задачу явной аутентификации, а не скрытой

                              Если посылки запихнуть в стегу, то будет не видно по вашей логике.

                              Для этого как раз потребуется держать общий ключ и, что важнее, алгоритм в секрете. Я думал, тут речь о криптографии)

                              О том и речь, что сейчас я вижу базу вашего алгоритма именно в этом.
                                0
                                Потому что из текущего описания мне понятно в какой момент дергать рубильник

                                И в какой же? Ну вот дернул я рубильник по предложению, когда Алиса ответила своему заказчику на картинку с зонтом (потому что "как в примере"), своровал какое-то сообщение. На следующий день оказалось, что это просто левый человек зонт заказал, а Алиса не агент (и таких миллионы). Или еще хуже — она агент и сбежала от такой явной атаки за границу. И кого я кому я навредил в итоге?


                                Не просто так привел пример со скрытым каналом ведь: никто не будет "дергать рубильник" на каждую электронную подпись просто потому, что в ней может что-то быть, верно?


                                Если посылки запихнуть в стегу, то будет не видно по вашей логике.

                                В третий (с учетом одного в самом посте) раз говорю — так делать нельзя. Для этого придется хранить метод стеганографии в тайне, что, как мы уже выяснили. Тут нет нигде моей логики, протокол разрабатывался как раз для избавления от таких требований


                                я вижу базу вашего алгоритма именно в этом

                                Каждый художник видит как хочет, конечно, но в моем описании нет требования хранить в секрете что-либо, кроме частей Алисы и Боба, поэтому претензии не ко мне. Сам протокол открыт, части закрыты, все равно определить, происходит диалог или аутентификация, нельзя

                          0
                          Вот никак не вижу усиления от того, что стеганка используется как часть секрета

                          Усиление заключается в двух факторах. Первый — Алиса контролирует выбор формы передачи секрета. В какой-нибудь схеме Шамира у нее не оставалось бы контроля над тем, что присылает Боб — это всегда была бы просто его число, хоть головой об стену бейся


                          Второй — если Боб стал злоумышленником (противник соблазнил женщинами и деньгами), то он может атаковать часть Алисы после проведения аутентификации, имея на руках как свою часть в явном виде, так и восстановленный секрет. Именно поэтому я сделал акцент на невозможности восстановления по Em как Ex, так и самого секрета M, который содержится в отображении части Боба и не несет никакой информации о части Алисы

                        0

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


                        Диаграмма

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое