Undeniable onion routing protocol with message creation time verification.pdf В [1] автором предложен распределённый протокол проведения соревнований CTF, основанных на решении заданий. Описанный протокол обладает серьёзным недостатком, а именно - полагается на рассылку меток времени добросовестными участниками. Недобросовестный участник, который не рассылает свои разрешения, все ещё имеет доступ к сети и может получать сообщения, если участвует в передаче сообщений других команд. Цель улучшения протокола безотказной луковой маршрутизации - сделать невозможным участие в соревновании команд, которые не ставят метки времени либо ставят некорректные метки под ответами других участников. Будем полагать, что каждый участник сети постоянно ожидает получения сообщений. Сформулируем требования к улучшенному протоколу: 1) каждый участник сети должен иметь возможность получать сообщения только в том случае, если участвует в качестве посредника при передаче сообщений других участников; 2) каждый участник сети должен иметь возможность получать сообщения только в том случае, если устанавливает корректные метки времени на все передаваемые им сообщения; 3) в результате работы протокола отправитель сообщения должен иметь временные метки от различных участников сети, подтверждающие время отправки исходного сообщения; 4) никто из участников, кроме отправителя и получателя, не должен иметь возможность прочитать или изменить передаваемое сообщение; 5) никто из участников не должен иметь возможность подделать чужую метку времени под передаваемым сообщением; 9 6) протокол должен делать крайне сложной и маловероятной атаку сговора с целью установки некорректных меток времени под сообщением; 7) протокол должен допускать особый режим работы, если нет гарантий, что получатель сообщения в данный момент подключён к сети, но при этом необходимо здесь и сейчас зафиксировать время создания сообщения. В свою очередь, получатель должен иметь возможность убедиться в подлинности временной метки под сообщением, которое он получит, когда восстановит доступ в сеть. Требования 1 и 2 необходимы для того, чтобы участники распределённой сети были заинтересованы в поддержании её работы. Требования 4 и 5 необходимы для защиты передаваемых сообщений и устанавливаемых под ними меток времени. Требование 6 служит для защиты от атаки сговора участников распределённой сети. Требование 7 необходимо, если данный протокол используется для проведения соревнований CTF, как в [1]. В этом случае необходимо уменьшить зависимость протокола от активного участия команды организаторов. Пусть Ea - шифрование на открытом ключе участника с идентификатором A; SA - подписание на закрытом ключе участника с идентификатором A; h - некоторая криптографическая хеш-функция. В случае, если y является конкатенацией байтового представления параметров x1,... , xt, будем допускать следующую запись для функций Ea, Sa, h: Еа(У) = Ea(X1, ... ,xt), £а(У) = Sa(X1, ... ,xt), h(y) = h(x1,... ,xt). Будем проводить сравнение значений времени с учётом временного окна w. Обозначим множество идентификаторов участников как U, |U | = n, где идентификаторы id е U - попарно различные числа. Функцию G(y) определим как в [1]: G(y) : N ^ U', U' = {u : u С U, |u| = t < n}. Введём функцию H(y) следующим образом: H(y) = [ro, (id1, Г1),..., (idt,rt)j, idi е G(y), idj < idi+1, i = 1,..., t - 1, ro = h(y), ri = h(y, idi), i = 1,..., t. Для удобства обозначим так же векторы идентификаторов участников и соответствующих им чисел: M = (id1,..., idt), R = (ro, Г1,..., rt). Будем говорить, что участник отключен от сети, если он не участвует в передаче сообщений либо искажает передаваемые им сообщения. Если все участники с идентификаторами id1,... , idt выступают в роли посредников при передаче сообщения, будем обозначать эти идентификаторы M1,... , Mt. Соответственно вектор M в этом случае запишется следующим образом: M = (M1,..., Mt). Пусть Алиса хочет послать сообщение m Бобу. При этом Алиса заинтересована в следующем: 1) она хочет убедиться в том, что все посредники, участвовавшие в передаче сообщения m, и получатель Боб честно выставляют метку времени (не завышают и не занижают время), когда выступают в роли посредника; 2) она хочет получить подтверждение времени создания сообщения m от других участников и предоставить его Бобу. Боб, в свою очередь, хочет быть уверенным, что Алиса его не обманывает и указанное время создания сообщения m верно с точностью до некоторого временного окна w. Будем предполагать, что все участники сети постоянно ожидают сообщений и не могут предсказать время, в которое они должны им прийти. Описание протокола: 1) Алиса считает H(m) = [r0, (M1, r1),..., (Mt, rt)]. 2) Алиса конструирует «луковицу», шифруя сообщение m следующим образом: Eb(Emi(.. .EMfc(EaEb(m),rfc),... ,n),ro). 3) Алиса отправляет Бобу Eb (Em! (. ..Емк (EaEb (m),rfc),... ,r^,ro), S^(m,t^),t^, где tA - текущее время Алисы. 4) Боб расшифровывает внешний слой луковицы: получает r0 и сообщение для первого посредника M1. Боб отправляет посреднику M1 Emi(... EMk(EaEb(m),rfc),... ,n), SA(m,tA),tA, Sb(r0,tB),tB. 5) Для i Е {1,..., k - 1} i-й посредник отсылает (i + 1)-му следующее сообщение: EMi(EMi+i(... EMk(EaEb(m),rfc),... ,ri+1),ri), Sa( m, tA), tA, Sb (r0, tB), tB, Sm1 (r1, t1), t1,..., Sm* (r*, t*), t*. 6) Последний посредник M^ отправляет Алисе EaEb(m), SA(m, tA), tA, Sb(r0,tB),tB, Smi(r1,t1),t1,..., SMk(rfc,tfc),tfc. 7) Алиса проверяет, что все метки времени SB(r0, tB), SMi(r*, t*), t*, i = 1,..., k - 1, имеют корректную подпись и указывают на адекватное время. Если проверки пройдены, Алиса посылает Бобу Eb(m), SA(m,tA),tA, Sb(r0,tB),tB, Smi(r1,t1),t1,..., SMk(rfc,tfc),tfc. Боб проводит проверку следующим образом. 1) Посчитать H(m) = [r0, (Mb n),... , (Mfc, rfc)]. 2) Проверить подписи временных меток Sa, SB, SMi, i = 1,... , k. 3) Проверить, что для значений времени в метках времени верны следующие равенства: tMi =w tMi+1, i Е {1, . . . , k - 1}, tMi =w tB, tB =w tA. 4) Если проверки пройдены, то считать, что сообщение m создано в момент времени tA. В случае, если Боб в данный момент не подключен к сети, а Алиса хочет засвидетельствовать факт создания сообщения m немедленно, можно внести следующие модификации в протокол. На шаге 2 внешний слой шифрования для Боба не включается. Последний шаг 7 протокола не зависит от времени, поэтому может быть выполнен, когда Боб снова подключится к сети. Проверка выполняется аналогично с учётом того, что временная метка Sb(r0,tB),ts отсутствует. Некоторые комментарии к протоколу. Функция H(m), аналогично функции G(m), имеет параметры n, t, k. В случе, если хотя бы один из первых k посредников из M отключен от сети, получение меток времени от этой цепочки посредников невозможно. Для того чтобы получить метку времени, необходимо выбрать k подключенных участников и сформировать луковицу согласно порядку в M. Таким образом, H(m) также имеет запас в (t - k) участников. Функция G(m) в составе функции H(m) нужна для того, чтобы случайным образом выбирать участников для выставления метки времени под сообщением m, тем самым сильно затрудняя возможность их предварительного сговора с целью установки ложной метки времени. Вектор R, получаемый функцией H(m), является вектором чисел, которые невозможно предсказать, не зная сообщения m. Это нужно для того, чтобы посредники имели возможность поставить временную метку на ri = h(m, idi), не зная самого сообщения m. Числа ri также используются в качестве Nonce, чтобы следующие посредники не могли определить предыдущих посредников, которые уже поставили свою метку времени на сообщение. Рассмотрим пример. Имеется множество участников U = {A, B, Mi, M2}, |U| = n = = 4, t = k = 2. Они подключены к сети, как показано на рис. 1. з Рис. 1. Пример работы протокола безотказной луковой маршрутизации с подтверждением времени создания сообщения Пусть участник A хочет послать сообщение m участнику B. Для этого ему необходимо вычислить H(m) = [г0, (Mi,ri), (M2,r2)]. Имеем следующую луковицу EB(EMl (EM2 (EaEb(m),r2),r1),r0). Подробно рассмотрим процесс передачи луковицы и выставления меток времени: 1) A ^ B : Eb(Em,(Em2(EaEb(m), Г2), ri), го), SA(m,tA),tA. 2) B ^ Mi : Em,(Em2(EaEb(m),r2),ri), SA(m,tA),tA, Sb(ro,tb),tB. 3) M1 ^ M2 : em2(eaeb(m),r2), SA SB (r0,tb ),tB, SMi (r1,tMi ),tMi. 4) M2 ^ A : eaeb (m), SA(m,tA),tA, sb(ro,tb),tB, smI (r1,tMi),tM l , SM2 (r2, ^M2 ) , ^M2 . 5) Проверка: tM2 =wtMl, tMl =wtB, tB=wt^. Если проверки пройдены: A ^ B : EB(m), ^^^ SB (r0,tb),tB, SMl (r1,tMl ),tMl, SM2 (r2,tM2 ) , £m2 . Описанный протокол может использоваться как протокол транспортного уровня в распределённой сети соревнования CTF следующим образом. Команда организаторов, согласно протоколу, осуществляет новостную рассылку во время соревнования. Если участник хочет получать новостную рассылку от организаторов, ему необходимо выступать в качестве посредника при передаче сообщений других участников, выставляя на них корректную метку времени. В противном случае участник не сможет получать новостную рассылку, что равносильно отключению от соревнования и техническому поражению. Каждый участник при получении ответа на задание должен доказать этот факт, отправив сообщение организаторам. Засвидетельствовать факт получения ответа в текущий момент времени можно с помощью модифицированного протокола, т. е. предполагая, что команда организаторов в данный момент может быть недоступна. Команды-соперники, выбранные в качестве посредников с помощью функции H (m), подтвердят факт создания сообщения в текущий момент времени. Итоговое сообщение вместе с метками времени может быть отправлено организаторам позже. По окончании соревнования организаторы смогут сформировать таблицу результатов с учётом времени получения ответов.

Скачать электронную версию публикации