id: Гость   вход   регистрация
текущее время 22:26 22/08/2019
Автор темы: gegel, тема открыта 20/11/2013 11:41 Печать
Категории: инфобезопасность, защита email
http://www.pgpru.com/Форум/Криптография/АналогPGPСОбеспечениемОтрицаемостиИНаперёдЗаданнойСекретностиОффлайн
создать
просмотр
ссылки

Аналог PGP с обеспечением отрицаемости и наперёд заданной секретности оффлайн?


Обсуждение в соседней теме натолкнуло на мысль: существует ли решение, аналогичное PGP и обеспечивающее для оффлайн-сообщений конфиденциальность и аутентификацию, но плюс отрицаемость и наперед заданную секретность (PFS), ну, и, желательно, тихое уведомление о прессинге. Нашел похожий вопрос на crypto.stackexchange: похоже, что готовых решений пока нет. Возможно, где-то на pgpru это уже обсуждалось, или что-то уже появилось?



 
На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Комментарии
— gegel (27/11/2013 22:58, исправлен 27/11/2013 23:04)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Может ли Алиса к предопределённым gx подбирать такие y, чтобы получить осмысленный результат во всей последующей переписке?

Я вот как раз об этом тоже сегодня думал. И, похоже, таки не может за реальное время. Со всеми вытекающими...


PS: Спасибо за викиразметку. Извините, учту на будущее.

— unknown (28/11/2013 10:04, исправлен 28/11/2013 12:42)   профиль/связь   <#>
комментариев: 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, и отрицаемость, и сокрытие факта связи, и автор известный. Правда, протокол старый, надо смотреть новые публикации по теме.
Чуть новее — filePrivate Authentication. Martın Abadi, также упоминаемый авторами OTR.
P.S.: Последняя работа по fileOTR. Что-то там для защиты от MITM наворотили много подписей, в частности обе стороны подписывают и gx, и gy. Тогда опять получается, что и от факта связи не отвертеться, а при использовании помеченного PRNG, тогда и содержимое переписки может стать доказуемо записываемо для предъявления третьей стороне?


Или я опять чего-то не понимаю…

— gegel (01/12/2013 16:00, исправлен 01/12/2013 16:09)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Unknown, я нашел время тщательно разобрать публикации по вашим ссылкам: исходную и поправленную версии OTR, аутентификации по SKEME и описанную Abadi. В отличие от двух последних протоколов, не нашел формального доказательства стойкости OTR. Разрабочики OTR заточили его под IM, отсюда сложности с аутентификацией. Появилась идея "скрестить" SKEME и OTR, максимально адаптировав к модели общения через email при сохранении всех заявленных свойств этих протоколов.


Основные отличия от оригинального OTR:

  • для аутентификации DH-секретов используется долговремнный результат SKEME вместо кучи хитрых хешей от половинок DH;
  • использованные ключи заменяются хешами, т.о. окно колючей имеет односторонюю PFS

Основные отличия от оригинальной SKEME:

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

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:

  • выбирает и сохраняет случайные a, x, t
  • подсчитывает ha=HASH(a), X=gx, X'=ENCt(X)
  • A->B: PKEB {ha, X'}

2.B:

  • выбирает и сохраняет случайные b, y
  • подсчитывает Y=gy
  • B->A: PKEA {b, Y}

3.A:

  • подсчитывает и сохраняет k = a xor b
  • подсчитывает t'=ENCk(t), s=Yx, ks=HMAC1(s), ka=HMAC2(ks)
  • сохраняет ks, ka вместе с индексом 0
  • A->B: PKEB{a, t'}
  • удаляет a, x, t

4.B:

  • проверяет HASH(a)==ha
  • подсчитывает и сохраняет k = a xor b
  • подсчитывает t=DECk(t'), X=DECt(X'), s=Xy, ks=HMAC1(s), ka=HMAC2(ks)
  • сохряняет ka в очереди на 2 сообщения (будет опубликовано через одно сообщение)
  • удаляет b, y
  • шифрует текст: msg=ENCks (text)
  • аутентифицирует сообщение: mac=HMACka(msg || ...)
  • B->A: msg, ..., mac (PGP тут и далее не используется)
  • заменяет ks=HMAC3(ks), ka=HMAC2(ks), сохраняет вместе с индексом 1

5.A:

  • проверяет mac==HMACka(msg || ...) для текущего и старого ключей ka, хешируя последний от текущего индекса вверх
  • читает text=DECks(msg)
  • заменяет использованные ks=HMAC3(ks), ka=HMAC2(ks), сохраняет вместе с инкрементированным индексом использованного ключа

PS: во всех сообщениях, начиная со второго, запускаются параллельные нити DH, аналогичные описанным выше (но без согласования k=a xor b, т.к. k согласовывается однажды и является долговременным на всю беседу), для последующих одноразовых ключей, т.е. в течение установившегося сеанса связи каждое сообщение содержит 4 нити (три для для различных фаз DH-согласования последовательных одноразовых секретов и одну – собственно для текста). Аутентифицируется все сообщение целиком: (X'n+3, Yn+2, t'n+1, msgn), macn

— unknown (01/12/2013 19:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Интересно, спасибо. Надо будет посмотреть, подумать. Может как-то найдётся время разобрать последний OTR и выяснить его стойкость к вбрасыванию детерминированных псевдослучайных помеченных параметров, закинуть этот вопрос в рассылку и заодно обсудить альтернативные протоколы.
— unknown (02/12/2013 13:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Что-то это мне напоминает: Fully Deniable Mutual Authentication Protocol Based on RSA Signature.
— gegel (02/12/2013 15:34)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Спасибо за очередную ссылку. Уже мозги кипят от такого количества информации в абсолютно новой для меня теме. Но тяжелое детство с ордой безжалостных репетиторов закалило. Надеюсь, крышу не снесет :)
PS:
...разобрать последний OTR и выяснить его стойкость к вбрасыванию детерминированных псевдослучайных помеченных параметров...


Просмотрел с этой точки зрения: таки стойкий. Дело в том, что единственным вбрасываемым параметром, явно используемым противоположной стороной, есть next_dh. Он возводится в степень, и если противоположная сторона тот час удаляет экспоненту, то вбрасывающий, не зная ее, никак не может показать связь между своим next_dh и полученным общим секретом (для этого ему необходимо решить задачу дискретного логарифмирования).
Есть еще один подозрительный момент на этапе AKE: использование подписей. Пока не осознал, чем это может быть чревато, но во всяком случае, общий секрет на выходе AKE, похоже, можно связать с публичным ключом одного из участников при компрометировании второго до окончания AKE.
— gegel (24/12/2013 23:31)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
После изучения кучи работ по взаимной аутентификации (спасибо unknown) созрело очень простое решение, пригодное для адаптации OTR к высоколатентной среде Email.
Как отмечают сами авторы OTR (fileраздел 6),их протокол неудобен для почты из-за интерактивных процедур начального согласования ключей и аутентификации (fileSIGMA IKE требует четыре прохода и SMP – еще четыре (fileAppendix A)). Появилась идея сократить количество проходов IKE всего до двух «холостых» сообщений (запроса на отрицаемую беседу и разрешения) и полностью отказаться от SMP за счет использования идентификации участников по PGP PKI (использование PGP вполне естественно для Email, в отличие от IM). В предлагаемом варианте за основу взята SKEME, а также fileпротокол 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-ключей одного или обоих участников при наличии частично надежного дополнительного канала (прослушиваемый телефон) при взаимном недоверии сторон;

– простое в использовании, скрытое и недоказуемое уведомление получателя о принуждении на определенном этапе переписки с помощью запоминаемых секретных фраз, опять же, при взаимном недоверии сторон.
— unknown (25/12/2013 09:50)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
A->B: PKE B (X, Pub A)

B->A: PKE A (Y, Fig B)


Что такое Fig?
— gegel (25/12/2013 10:40)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Извиняюсь, имелся в виду отпечаток публичного ключа. Вообще там могут быть любые идентификаторы участников, имеющие отношение к их приватным ключам. Я исходил из того, что если Алиса – инициатор, то Боб может не иметь ее публичного ключа, поэтому есть смысл вложить его в первое сообщение. Боб может вложить только отпечаток своего ключа с целью идентификации своего сообщения как ответа на запрос Алисы (т.к. понятно, что Алиса уже имеет сам ключ Боба).
— unknown (25/12/2013 11:39, исправлен 25/12/2013 11:50)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Ну тогда ida или просто A — как известное имя, чтобы знать, от кого запрос.



Так всё-таки к публичным только наверное?



Если стороны заранее не знают (отпечатков) открытых ключей друг друга, то возможен MITM. Ну или просто будет разговор Боба непонятно с кем, кто выдаёт себя за Алису.

— gegel (25/12/2013 12:18, исправлен 25/12/2013 12:26)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Ну тогда ida или просто A — как известное имя, чтобы знать, от кого запрос.

Да, именно так.


Так всё-таки к публичным только наверное?

Просто я рассматриваю публичный+приватный ключи как единое целое. Конечно, id указывает на публичный ключ и показывает факт владения соответствующим приватным.


Если стороны заранее не знают (отпечатков) открытых ключей друг друга, то возможен MITM. Ну или просто будет разговор Боба непонятно с кем, кто выдаёт себя за Алису.

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

— unknown (25/12/2013 15:36, исправлен 25/12/2013 16:53)   профиль/связь   <#>
комментариев: 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 .


На всякий случай лучше проверять на соответствующих шагах, что: idAidBr1r2

— gegel (25/12/2013 20:45)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Обычно принято в ответ частично включать предыдущий запрос


Именно это мне очень не хотелось бы делать (если можно): не особо хочется отсылать обратно возможно вброшенное значение.

В протоколе Abadi запрос в ответ включается, но подчеркнуто, что протокол для "честных" участников. В SKEME – нет.
Ваш вариант похож на SKEME, но с объединенными этапами.

Всё-таки, как конкретно r1 и r2 получаются — не совсем понятно


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

Все эти извращения понадобились мне для максимального сокращения фазы аутентификации и использования PGP. В моем случае:
1. Алиса отсылает запрос на беседу, используя PGP.
2. Боб отсылает разрешение на беседу, используя PGP

3. Теперь каждый участник может отсылать другому шифротекст (он и есть r) без использования PGP. Т.к. шифротекст создан со случайным непресказуемым IV, он неотличим от рандома.

В предложенном Вами варианте три предварительных прохода с использованием PGP, но по окончанию обеспечивается полная уверенность участников друг в друге (классический подход, всяко надежно). Я предлагаю начинать общение еще до фактического завершения аутентификации как таковой, но вот хочу выяснить, на сколько это противоречит канонам и чем чревато.
— unknown (26/12/2013 09:59, исправлен 26/12/2013 11:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

В моём варианте, Алиса убеждается в правильности согласования параметров с Бобом уже по его ответу на втором шаге.


Алиса может отправить сообщение SE-MDC, шифрованное ключом s уже вместе с третьим шагом. Боб проверяет правильность третьего шага от Алисы через PKE-MDC и если проверка проходит, то он может расшифровывать сообщение GnuPG SE-MDC, посланное Алисой на этом же шаге параллельно.


Теперь каждый участник может отсылать другому шифротекст (он и есть r) без использования PGP. Т.к. шифротекст создан со случайным непресказуемым IV, он неотличим от рандома.

Этого и хотелось избежать, чтобы не надо было самому городить аутентифицированное симметричное шифрование. А так есть тоже самое что PKE-MDC, только SE-MDC (symmetric encryption) от GnuPG.
Ну можно на третьем шаге перейти и на самопальное аутентифицированное шифрование с ключом s, если вас формат GnuPG чем-то не устраивает.


Т.е., пусть уж рэндомные числа (nonce) останутся не более чем рэндомными числами для проверки запросов через MDC и HMAC, а шифрованные сообщения пойдут отдельно после согласования. Число шагов, заметьте — такое же.



Как минимум, replay-атаками.

— gegel (26/12/2013 11:02, исправлен 26/12/2013 11:26)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Этого и хотелось избежать, чтобы не надо было самому городить аутентифицированное симметричное шифрование.

А придется. Дело в том, что приведенный фрагмент – это лишь начало протокола, а дальше будет классический OTR (ведь нужна PFS), как описано в fileразделе 4.1.
Это старый протокол OTR, а в новом изменили (добавили) SIGMA-аутентификацию из-за обнаруженной identity misbinding атаки. Мой вариант аутентификации с использованием PGP устойчив к этой атаке (mdc препятствует подмене идентификатора), но не был использован в OTR, как я понял, из-за нежелания смешивать PGP с IM.
Я попытаюсь расписать весь протокол отрицаемого шифрования Email, как я его вижу в целом, тогда будет более понятнее общая идея, что, возможно, оправдает средства.


Число шагов, заметьте — такое же.

Сходу не понял, сейчас попытаюсь осознать, что с чем объединять.


Как минимум, replay-атаками

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

На страницу: 1, 2, 3, 4, 5, ... , 16, 17, 18, 19, 20 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3