Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?
Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?
комментариев: 393 документов: 4 редакций: 0
Я вот как раз об этом тоже сегодня думал. И, похоже, таки не может за реальное время. Со всеми вытекающими...
PS: Спасибо за викиразметку. Извините, учту на будущее.
комментариев: 9796 документов: 488 редакций: 5664
А сегодня я проснулся и решил, что всё, что было написано мной вчера про OTR — полный бред. Т.е. принципы работы я понял может и правильно, а выводы сделал неверные.
В обеих версиях протокола и той, что в работе, и в последней на сайте, стороны только и делают, что согласовывают параметры по Диффи-Хеллману. Просто в последней версии с рядом дополнительных наворотов. Я вроде понял, как они работают, но не понял, от чего были введены такие усложнения.
В итоге, всё равно всё сводится к обычной схеме.
Алиса генерирует помеченный xA, посылает Бобу gxA, он в ответ генерирует xB, посылает gxB, каждый возводит полученный от другой стороны gx в свою степень x и обе стороны получают совместный секрет gxA xB. Обычный DH, который далее просто пошагово размазан по всему протоколу.
Из первого секрета стороны получают MAC, по которому ещё раз обмениваются новыми gxA и gxB для нового секрета. Так вот уже на этом этапе Алиса не имеет привязки сообщений к Бобу. Она просто считает, что раз никто, кроме них не знает текущий MAC, которым заверяется очередной обмен, то все параметры и сообщения идут от Боба. Но если она его знает, то никто не мешает ей самой себе прислать любой случайный gxB вместо Боба. От этого вычислится какой-то следующий случайный MAC и ключ, которым она сама себе «заверит» и зашифрует любое сообщение, якобы полученное от Боба.
Далее, каждая сторона в сообщение включает соответственно новые gxA или gxB, которые служат для выведения последующих совместных секретов, MAC'ов и ключей. Алиса может опять же присылать или записывать в свою переписку любые gxB, якобы полученные от Боба, заверять их предыдущими MAC, а получающимися случайными ключами и новыми MAC'ами создавать любые сообщения. То, что её ГПСЧ — предопределённый некоторым секретом — не имеет никакого значения. Она может подставлять любые gxB, которые никак не связаны ни с ней, ни с её ГПСЧ. Подгонять их ни под какой конкретный результат не нужно. Всю последующую сессию она может сочинять сама, как ей вздумается, выбирая gxB произвольным образом.
С отрицанием факта связи, по крайней мере в последней версии OTR — вроде также должно быть всё в порядке: стороны напрямую не подписывают свои параметры. Наконец, свой протокол OTR авторы считают слишком неподходящим для оффлайна и рекомендуют вместо него SKEME, который приблизительно похож на то, что я пытался изобразить в /comment73839. Там вроде как заявлено и PFS, и отрицаемость, и сокрытие факта связи, и автор известный. Правда, протокол старый, надо смотреть новые публикации по теме.
Чуть новее — Private Authentication. Martın Abadi, также упоминаемый авторами OTR.
P.S.: Последняя работа по OTR. Что-то там для защиты от MITM наворотили много подписей, в частности обе стороны подписывают и gx, и gy. Тогда опять получается, что и от факта связи не отвертеться, а при использовании помеченного PRNG, тогда и содержимое переписки может стать доказуемо записываемо для предъявления третьей стороне?
Или я опять чего-то не понимаю…
комментариев: 393 документов: 4 редакций: 0
Unknown, я нашел время тщательно разобрать публикации по вашим ссылкам: исходную и поправленную версии OTR, аутентификации по SKEME и описанную Abadi. В отличие от двух последних протоколов, не нашел формального доказательства стойкости OTR. Разрабочики OTR заточили его под IM, отсюда сложности с аутентификацией. Появилась идея "скрестить" SKEME и OTR, максимально адаптировав к модели общения через email при сохранении всех заявленных свойств этих протоколов.
Основные отличия от оригинального OTR:
Основные отличия от оригинальной SKEME:
x, y – DH-экспоненты (384 бита)
t,a,b,k – ключи (128 бит)
HASH(), HMACk() – урезанные хеши (128 бит)
ENCk (),DECk () – симметричное шифрование/дешифрование (AES CTR)
PKEA{} – PGP-шифрование публичным ключом A
g – генератор, возведение в степень – по модулю p (1024 бита)
Алиса и Боб имеют публичные PGP-ключи друг друга. Алиса инициирует связь.
Основная нить инициализации соединения:
1.A:
2.B:
3.A:
4.B:
5.A:
PS: во всех сообщениях, начиная со второго, запускаются параллельные нити DH, аналогичные описанным выше (но без согласования k=a xor b, т.к. k согласовывается однажды и является долговременным на всю беседу), для последующих одноразовых ключей, т.е. в течение установившегося сеанса связи каждое сообщение содержит 4 нити (три для для различных фаз DH-согласования последовательных одноразовых секретов и одну – собственно для текста). Аутентифицируется все сообщение целиком: (X'n+3, Yn+2, t'n+1, msgn), macn
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 393 документов: 4 редакций: 0
PS:
Просмотрел с этой точки зрения: таки стойкий. Дело в том, что единственным вбрасываемым параметром, явно используемым противоположной стороной, есть next_dh. Он возводится в степень, и если противоположная сторона тот час удаляет экспоненту, то вбрасывающий, не зная ее, никак не может показать связь между своим next_dh и полученным общим секретом (для этого ему необходимо решить задачу дискретного логарифмирования).
Есть еще один подозрительный момент на этапе AKE: использование подписей. Пока не осознал, чем это может быть чревато, но во всяком случае, общий секрет на выходе AKE, похоже, можно связать с публичным ключом одного из участников при компрометировании второго до окончания AKE.
комментариев: 393 документов: 4 редакций: 0
Как отмечают сами авторы OTR (раздел 6),их протокол неудобен для почты из-за интерактивных процедур начального согласования ключей и аутентификации (SIGMA IKE требует четыре прохода и SMP – еще четыре (Appendix A)). Появилась идея сократить количество проходов IKE всего до двух «холостых» сообщений (запроса на отрицаемую беседу и разрешения) и полностью отказаться от SMP за счет использования идентификации участников по PGP PKI (использование PGP вполне естественно для Email, в отличие от IM). В предлагаемом варианте за основу взята SKEME, а также протокол Abadi, но c оригинальными изменениями.
Unknown, огромная просьба взглянуть: возможно, подобный протокол уже публиковался. Кроме того, у меня нет опыта для каких-либо формальных доказательств заявленных функций протокола, а этого недостаточно для какого-либо доверия к нему, хотя интуитивно все выглядет надежно. Возможно, посоветуете способ как-то доказать или опровергнуть мои идеи и выводы.
Цель: сократить процедуру взаимной аутентификации с полной отрицаемостью до двух сообщений.
Новизна: выполнение Диффи-Хеллманн внутри PGP (без подписей, желательно в режиме --throw-keyid, целостность обеспечивается mdc).
Решение: X, Y – DH-паблик значения.
A->B: PKE B (X, Pub A)
B->A: PKE A (Y, Fig B)
На этом этапе обе стороны вычисляют общий секрет s. Участники пока не уверены, что у них одинаковый s (т.к. входящее сообщение могло быть отправлено третьей стороной). Но каждая сторона уверена в том, что:
а) полученное значение s может быть известно только второй стороне и никому другому (т.к. половинка секрета отправлялась через PGP конкретному адресату, и никак не могла попасть в чужие руки);
б) если кто-то докажет знание s, то он и есть нужный адресат (вытекает из предыдущего утверждения);
Далее: r1, r2 – уникальные случайные значения (в данном случае шифротекст, полученный с ключoм, выведенным из s и случайным IV).
A->B: r1, HMACs(r1)
B->A: r2, HMACs(r2)
Выводы:
1. Любая из сторон уже после первичного PGP-обмена может зашифровать сообщение и получить r, будучи уверенным, что никто, кроме второй стороны, не сможет его прочитать (обеспечивается конфиденциальность). Это вытекает из утверждения а).
2. Получатель, сверив MAC, уверен, что отправитель – нужный адресат и никто другой (обеспечивается аутентификация). Это исходит из утверждения б).
3. Уверенность получателя в личности адресата базируется на уверенности в том, что он отравлял первое PGP-сообщение только ему и никому другому. Но доказать это третьей стороне он не может, т.к., находясь вне контроля, вполне мог отправить это сообщение и кому-то еще, в т.ч. самому себе (обеспечивается отрицаемость факта беседы).
4. Отправитель уверен, что полученное в PGP-сообщении значение DH-паблик не может его скомпрометировать: при вычислении s оно возводится в степень приватной экспоненты (выбранной самим отправителем и доверяемо рандомной), т.е. для доказательства следов DH-паблик в s надо вычислить дискретный логарифм (обеспечивается устойчивость к вбрасываем значениям изначально злонамеренным контактом).
Если приведенный протокол не будет жестко раскритикован, покажу, как обеспечить malleability, repudiability и PFS (используя оригинальный протокол OTR), а также FS в пределах окна ключей (для обеспечения устойчивости сессии к потерям сообщений в условиях высоколатентной среды).
Также есть идеи:
– добавить механизм отрицаемой подписи (в том числе для обнаружения MitM при утечке приватных PGP-ключей одного или обоих участников при наличии частично надежного дополнительного канала (прослушиваемый телефон) при взаимном недоверии сторон;
– простое в использовании, скрытое и недоказуемое уведомление получателя о принуждении на определенном этапе переписки с помощью запоминаемых секретных фраз, опять же, при взаимном недоверии сторон.
комментариев: 9796 документов: 488 редакций: 5664
Что такое Fig?
комментариев: 393 документов: 4 редакций: 0
комментариев: 9796 документов: 488 редакций: 5664
Ну тогда ida или просто A — как известное имя, чтобы знать, от кого запрос.
Так всё-таки к публичным только наверное?
Если стороны заранее не знают (отпечатков) открытых ключей друг друга, то возможен MITM. Ну или просто будет разговор Боба непонятно с кем, кто выдаёт себя за Алису.
комментариев: 393 документов: 4 редакций: 0
Да, именно так.
Просто я рассматриваю публичный+приватный ключи как единое целое. Конечно, id указывает на публичный ключ и показывает факт владения соответствующим приватным.
Да, все так, ведь аутентификация полностью основана на PGP. Но представим реальную ситуацию, когда Алиса начинает беседу и хочет остаться псевдонимной (или раскрыться позже), но быть изначально уверенной в личности Боба. Она заводит новую ключевую пару, и должна вложить свой публичный ключ в сообщение для обеспечения возможности ответа. Т.к., начиная беседу с Бобом, она априори знает публичный ключ и отпечаток Боба, то Бобу достаточно вложить свой отпечаток (или другой id) для идентификации отправителя ответа.
К счастью, с предлагаемым протоколом в данной ситуации MitM невозможен, т.к. Алиса пишет Бобу, идентифицировав его публичный ключ. В этом сообщении уходит DH-половинка. Получить его может только Боб, и никто другой. Из этой половинки в дальнейшем выводится s. И если ее подменить, то позже аутентификация просто не пройдет.
комментариев: 9796 документов: 488 редакций: 5664
X = ga mod p
Y = gb mod p
s = KDF ( ga )b mod p = KDF ( gb )a mod p
Обычно принято в ответ частично включать предыдущий запрос:
A → B: PKEB (idA, X, r1)
B → A: PKEA (idB, X, Y, r1, r2, HMACs (idB, r1, r2) )
A → B: PKEB (idA, r1, r2, HMACs (idA, r2, r1) )
B → A: PKEB (idB, r1, r2, HMACs ( HMACs (r1), HMACs (r2) ) )Тогда четвёртый шаг даже не нужен.
Всё-таки, как конкретно r1 и r2 получаются — не совсем понятно. Если их можно выбирать произвольно, то всё упрощается. А как то хитро детерминированно от s — непонятно чем обосновать.
Алиса просто загадывает уникальный r1 в начале и никто кроме Боба не сможет вернуть ей правильный ответ, включающий в себя такой же r1, если mdc стойко защищает сообщения. Аналогично и Боб может получить только от Алисы правильно подтверждающий ответ на свой сразу же посланный r2 .
На всякий случай лучше проверять на соответствующих шагах, что: idA ≠ idB ≠ r1 ≠ r2
комментариев: 393 документов: 4 редакций: 0
Именно это мне очень не хотелось бы делать (если можно): не особо хочется отсылать обратно возможно вброшенное значение.
В протоколе Abadi запрос в ответ включается, но подчеркнуто, что протокол для "честных" участников. В SKEME – нет.
Ваш вариант похож на SKEME, но с объединенными этапами.
В моем варианте r1 и r2 – это уже шифротекст, получается, как обычно, шифрованием пользовательского сообщения ключом, выведенным с s. Фишка в том, что на этапе отсылки первого шифротекста аутентификация еще не завершена, и завершается для любой стороны только после получения первого шифротекста. Как показано выше, отсылать шифротекст при этом безопасно, т.к. дешифровать его может только получатель (хотя пока не известно, сможет ли – в случае внедрения третьей стороны).
Все эти извращения понадобились мне для максимального сокращения фазы аутентификации и использования PGP. В моем случае:
1. Алиса отсылает запрос на беседу, используя PGP.
2. Боб отсылает разрешение на беседу, используя PGP
3. Теперь каждый участник может отсылать другому шифротекст (он и есть r) без использования PGP. Т.к. шифротекст создан со случайным непресказуемым IV, он неотличим от рандома.
В предложенном Вами варианте три предварительных прохода с использованием PGP, но по окончанию обеспечивается полная уверенность участников друг в друге (классический подход, всяко надежно). Я предлагаю начинать общение еще до фактического завершения аутентификации как таковой, но вот хочу выяснить, на сколько это противоречит канонам и чем чревато.
комментариев: 9796 документов: 488 редакций: 5664
В моём варианте, Алиса убеждается в правильности согласования параметров с Бобом уже по его ответу на втором шаге.
Алиса может отправить сообщение SE-MDC, шифрованное ключом s уже вместе с третьим шагом. Боб проверяет правильность третьего шага от Алисы через PKE-MDC и если проверка проходит, то он может расшифровывать сообщение GnuPG SE-MDC, посланное Алисой на этом же шаге параллельно.
Этого и хотелось избежать, чтобы не надо было самому городить аутентифицированное симметричное шифрование. А так есть тоже самое что PKE-MDC, только SE-MDC (symmetric encryption) от GnuPG.
Ну можно на третьем шаге перейти и на самопальное аутентифицированное шифрование с ключом s, если вас формат GnuPG чем-то не устраивает.
Т.е., пусть уж рэндомные числа (nonce) останутся не более чем рэндомными числами для проверки запросов через MDC и HMAC, а шифрованные сообщения пойдут отдельно после согласования. Число шагов, заметьте — такое же.
Как минимум, replay-атаками.
комментариев: 393 документов: 4 редакций: 0
А придется. Дело в том, что приведенный фрагмент – это лишь начало протокола, а дальше будет классический OTR (ведь нужна PFS), как описано в разделе 4.1.
Это старый протокол OTR, а в новом изменили (добавили) SIGMA-аутентификацию из-за обнаруженной identity misbinding атаки. Мой вариант аутентификации с использованием PGP устойчив к этой атаке (mdc препятствует подмене идентификатора), но не был использован в OTR, как я понял, из-за нежелания смешивать PGP с IM.
Я попытаюсь расписать весь протокол отрицаемого шифрования Email, как я его вижу в целом, тогда будет более понятнее общая идея, что, возможно, оправдает средства.
Сходу не понял, сейчас попытаюсь осознать, что с чем объединять.
Фишка в том, что один и тот же ключ шифрования и аутентификации никогда не будет использован дважды.