id: Гость   вход   регистрация
текущее время 17:14 29/03/2024
Автор темы: 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 След.
Комментарии
— SATtva (25/11/2013 08:29, исправлен 25/11/2013 08:34)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если Ева контролирует трафик обоих, то, боюсь, что-то отрицать не получится, даже без его расшифровки.

Это не так.


Ну, тогда вместо ЭЦП Алиса может зашифровать текст публичного ключ Боба + версию протокола своим закрытым ключом (надеюсь, в OpenPGP это возможно) и вложить в сообщение: та же подпись, но без меток времени.

Нельзя. И такой финт работал бы только для ключей RSA. OpenPGP предписывает использование меток времени для всех подписей, так что либо надо подделывать время, либо как-то обходиться без подписей, либо использовать их так, чтобы это не вышло боком.


Самое смешное, что в gpg2 есть специальный отладочный параметр --faked-system-time, в который можно было бы передать 0, однако программа этот параметр почему-то не воспринимает (может, лично у меня, хотя в 2.0.22 должно работать).

— unknown (25/11/2013 09:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
2 /comment73795 и в дополнение к /comment73796.

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

Ещё раз, если у сторон заранее отсутствует предрасшаренный секрет, то за счёт подписей при согласовании, если Алиса раскроет отрицаемую переписку с Бобом:

  1. Боб не сможет отрицать факт переписки с Алисой (поэтому не важно, что одна из сторон запишет в аутентифицирующий пароль).
  2. Боб не сможет отрицать, что он согласился именно на режим отрицаемой переписки.
  3. Если Алиса проставит криптоштампы времени у доверенной третьей стороны, то Боб не сможет отрицать, что переписка происходила в какое-то другое, более позднее время.
  4. Боб может отрицать только содержимое переписки: утверждать, что его тексты были отредактированы или полностью сочинены Алисой.
  5. П.4 не работает, если Алиса сливает переписку наблюдателю сразу же в реальном времени, каким-то образом доказывая ему, что она получила письмо от Боба вот только что и у неё не было времени его подменить.
— gegel (25/11/2013 18:42, исправлен 25/11/2013 18:46)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
>Если Ева контролирует трафик обоих, то, боюсь, что-то отрицать не получится, даже без его расшифровки.
<Это не так.

Тогда я, наверное, неверно понимаю термин "отрицаемость" – какая модель угроз подразумевается?


Возможна ли отрицаемость для Алисы:
– если Ева просто контролирует трафик ее и Боба?
– если Боба позже принуждают к сотрудничеству?
– если он изначально злонамеренній и скооперирован с Евой?


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

Возможно, так получится этому противостоять (считаем k хешем от компроментирующего заявления):


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


Задача: сгенерировать общий секрет, чтобы включать его в неподписанные PGP-сообщения для своей аутентификации друг перед другом. Так, чтобы Ни Алиса, ни Боб не смогли доказать кому-либо еще, что вторая сторона владеет этим секретом или принимала участие в его выработке, но сами в этом были уверены.


0. Боб генерирует случайное число k, подписывает и отсылает его Алисе. Это единственное сообщение, связывающее его с Алисой. Только она может получить k, и она будет уверенна, что получила его именно от Боба. Третей стороне k неизвстно. Задача протокола – сделать так, чтобы Боб (случайно, позже под нажимом или изначально злонамеренно) не смог позже связать ни факт, ни контекст беседы с Алисой с этим k, но сам мог идентифицировать Алису. То же касается Алисы.


Примечание: предполагаем, что метка времени обнулена, и Боб всегда может утверждать, что посылал Алисе это сообщение и k ранее совсем в другом контексте. Алиса может утверждать, что она это сообщение не получала и k никогда не видела.


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


2. Боб получает h, но не уверен, что его послала Алиса, и не уверен, что факт владения h не скомпроментирует его позже. Он сохраняет его в секретном месте, генерирует свое случаное число rb, сохраняет сам и отсылает Алисе. Он уверен, что только Алиса может получить это число. Ева может перехватить сообщение, подменить его, но не прочитать.


3. Алиса получает число rb от Боба, но она не уверена, что его послал Боб, и не уверена, что факт владения этим числом не скомпроментирует ее позже. Алиса банально ксорит полученное число rb со своим ra, получает s. Т.к. она уверена, что свое число случайное, то и s будет случаен. Теперь Алиса отсылает свое случайное число ra Бобу и тот час удаляет и его, и число rb, полученное от Боба.


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


5. В итоге у Алисы и Боба могут быть различные s (если внедрилась Ева), но если они одинаковые, то Ева о них гарантированно ничего знать не может. Также Ева ничего не знает о числе k, подписанном Бобоб. Алиса и Боб вычисляют MAC m от результата s, в качестве ключа используют k. Т.к. s случаен и для Алисы, и для Боба (как показано выше), то и m будет случаен. На шаге 1 Алиса не сможет подсунуть вместо случайного такое число, чтобы затем, реверсировав mac, доказать связь m и k. Ни Боб, ни Алиса не смогут показать связь k и m, т.к. число m было рандомизировано другим участником, и связать его с ним невозможно.


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

— unknown (26/11/2013 10:22, исправлен 26/11/2013 13:02)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Похоже на бит-коммитмент (multibit, string-commitment) на хэшах для совместного выведения секрета. С учётом того, что принято инициирующей стороной назначать Алису, можно нагляднее переписать так, вообще без использования подписи в вашем п.0:


  1. Alice: Generate RA. Send AliceBob: Encrypt_PKB (A ║ H(RA)).
  2. Bob: Decrypt_SKB (A ║ H(RA)). Generate RB. Send BobAlice: Encrypt_PKA (B ║ H(RB) ║ H(RA)).
  3. Alice: Decrypt_SKA (B ║ H(RB) ║ H(RA)). Send AliceBob: Encrypt_PKB (A ║ H(RB) ║ RA).
  4. Bob: Decrypt_SKB (A ║ H(RB) ║ RA). Check H(RA) = RA. Compute R = RBRA. Send BobAlice: Encrypt_PKA (B ║ H(RA) ║ RB).
  5. Alice: Decrypt_SKA (B ║ H(RA) ║ RB). Check H(RB) = RB. Compute R = RARB.

Кое-что по теории есть fileздесь. На стр. 12-14 такие протоколы критикуются как проблемные. Но в чём м.б. проблема в данном случае — сказать затрудняюсь. М.б. частичный MITM?


Отдельную ссылку на то, что это всё напоминает, вынес в /comment73841.

— SATtva (26/11/2013 16:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тогда я, наверное, неверно понимаю термин "отрицаемость" – какая модель угроз подразумевается?

Я рассматриваю по аналогии с OTR: отрицается не факт совершения беседы, а содержимое диалога, т.е. ни одна из сторон не может доказать третьей стороне, что собеседник действительно писал такое. Прослушивание OTR-трафика не позволяет внешнему наблюдателю утверждать что-либо о его содержании. Если Ваша модель допускает контроль Евы над каналами обоих собеседников, то более сильной отрицаемости (отрицание факта беседы) Вы всё равно не добьётесь даже с помощью Tor, ибо атака на подтверждение трафика.

Возможна ли отрицаемость для Алисы:
– если Ева просто контролирует трафик ее и Боба?
По содержанию беседы — да, по факту беседы — нет.

– если Боба позже принуждают к сотрудничеству?
По содержанию беседы — да, по факту беседы — возможно, если в протоколе вообще не применяются ЭЦП.

– если он изначально злонамеренній и скооперирован с Евой?
Ни по содержанию, ни по факту беседы.
— gegel (27/11/2013 01:51, исправлен 27/11/2013 11:48)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

/comment73839

М.б. частичный MITM?

Мне тоже так показалось. Терию почитаю, спасибо.


/comment73790:

С отрицаемостью вроде как всё хорошо. Даже как-то подозрительно и не верится, что всё так просто оказалось.

Не все так хорошо на самом деле, принимая во внимание тезизы ниже:


/comment73850:

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

/comment73766:

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

Но пессимистическая нота: данная схема, к сожалению, обеспечивает только отвязку беседы от ее инициализации и от публичных ключей участников. Но, в отличие от OTR, вся беседа в смысле отрицаемости является единым целым: если один из участников докажет авторство хотя бы одного любого сообщения (по содержанию, уникальной информации, известной только другой стороне и т.п.), то автоматически докажет авторство всех его сообщений. Или я ошибаюсь, и предложенная Вами схема ( /comment73788 ) поможет этого избежать?
Возможно, поможет параллельная PFS с помощью пошаговой DF, но не уверен, что все так просто будет. Как бы в итоге не получился тот же OTR. Что еще раз подтверждает его уникальность.

— Гость (27/11/2013 02:40)   <#>
gegel, в структуре wiki цитаты ставятся от корня домена, вот так:
((/comment73790)) или ((/comment73790 какие-то слова)).
На печати будет:
Вместо круглых скобок всегда можно использовать квадратные.
— unknown (27/11/2013 10:47, исправлен 27/11/2013 11:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Поможет скорее схема /comment73839 (чуть доработанный вариант вашей же идеи), там вообще нет использования каких-либо подписей изначально. Только шифрование на публичный ключ другой стороны, но обязательно с использованием опции MDC. Вроде, включением повторных H в ответы на запрос, можно даже избежать MITM, но это всё наброски на коленке и бездоказательно. В вышеприведённой работе вроде как указанно, что при соблюдении всех условий с биткоммитментом такие схемы аутентификации работают, но есть отсылки к другим работам, надо разбирать, где там м.б. узкие места.


Если канал совсем анонимный, а всю почту они сливают куда-то на файлообменники и их обратно не отследить, то Еве вроде как ловить нечего.


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


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


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


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


P.S.: Кажется, составляя этот комент, я поломал все ваши и свои предыдущие наивные протоколы. Не изобретайте протоколы на коленке шифрпанковским способом. Пусть этим занимаются теоретики.

— unknown (27/11/2013 12:50, исправлен 27/11/2013 12:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Посмотрел протоколы fileOTR и fileSKEME. Там всё тоже самое. Если провокатор Алиса инициализирует какой-нибудь генератор случайных чисел хэшем своего закрытого ключа и будет брать во всех сеансах связи параметры с этого генератора, а затем в ходе сеанса связи раскроет всю эту схему третьему лицу или группе лиц вместе со своим закрытым ключом и они вступят в переписку с Бобом от её имени, то они могут убедиться, что переписка с Бобом была подлинной, на другом конце линии им отвечает Боб.


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


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

— SATtva (27/11/2013 13:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Новостные заголовки через пару дней: "ШОК!!! Участники проекта pgpru.com взломали протокол OTR".
— unknown (27/11/2013 13:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А нечего было такие провокационные вопросы задавать :D
— SATtva (27/11/2013 14:08)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если серьёзно, то возможен ли вообще совместный протокол, при котором стороны не могут заложить такую бомбу в передаваемые параметры? Насколько понимаю, такой риск есть везде, где участники используют случайные числа — по факту, они могут оказаться не столь уж случайными.
— unknown (27/11/2013 14:14, исправлен 27/11/2013 14:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я сейчас пытаюсь что-то ответить, попутно мучаясь с местной вики-разметкой. Следите за дальнейшими событиями. Хотя, может мне стоит просто получше выспаться и не торопиться с выводами…


Cейчас думаю над началом сеанса в OTR:

We want repudiability: no one should be able to prove Alice sent any particular message, whether she actually did, or not. For this reason, we never use a digital signature to prove Alice’s authorship of any message. The only data we ever sign are Alice’s values of gxA in the Diffie-Hellman protocol. Everyone, including Bob and Eve, can then be assured that Alice was really the one who chose the value of xA that produced gxA, but that is all they know. Bob, on the other hand, has extra information: xB, and with it the shared secret gxA xB. We will use this shared secret next to prove Alice’s authorship of the message to Bob, and only to Bob.

— unknown (27/11/2013 14:32, исправлен 27/11/2013 14:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Большая группа народу может совместно создать некий секрет R, подписать его всеми своими подписями. На основе этого секрета создать совместно управляемый ключ некой Алисы (журналистки, подставной пособницы преступника и др.), а хэшем закрытой части этого ключа (со вставленной строкой, например "Gotcha, Bob! We are anonymous avengers with real keys 0xXXXXXXX!") инициализировать генератор псевдослучайных чисел, с которого отправлять все параметры Бобу. Так, параметр, XA для gXA будет связан с этим генератором, Боб ответит gXB. У обеих сторон будет вычислен сеансовый ключ gXA XB. Но псевдо-Алиса сможет доказать, что он состоит из помеченного XA.


Дальше надо подумать…

— unknown (27/11/2013 14:56, исправлен 27/11/2013 21:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Так OTR шифрует сессии, отлично, все помеченные параметры от ГПСЧ Алисы идут в сообщения, да ещё и связываются между собой:

A → B : gx1
B → A : gy1
A → B : gx2, E(M1, k11 )
B → A : gy2, E(M2, k21 )
A → B : gx3, E(M3, k22 )
where kij = H(gxi yj ), the result of a 128-bit hash, such as truncated SHA-1 [22]

Глава "4.3 Authentication" в прямом и переносном смысле слова — ключевая.


A → B: Sign(gx1 , kA ), KA
B → A: Sign(gy1 , kB ), KB
Where ka , KA are Alice’s private and public long-lived
signature keys, and kb , KB are Bob’s.

Обе стороны могут подсунуть на подпись друг другу помеченный секрет. Q.E.D.: В лучшем (для стойкости OTR) случае Алиса может доказать, что переписывалась с Бобом или Боб — что с Алисой, если кто-то из них подсуетился заранее. В худшем — подлинность содержимого сообщений, но это пока не вполне ясно.


Дальше, они из него же выводят MAC:


We only need to use a digital signature on the initial key exchange. In further key exchanges, we use MACs to authenticate a new key using an old, known-authentic shared secret. That is, a protocol message looks like:
gxi+1, E(Mr , kij ),
MAC({gxi+1, E(Mk , kij )}, H(kij))

2 SATtva:

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

Похоже, что нет. И похоже, что это серьёзно.


2 gegel /comment73795:

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

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


P.S.: Надо ещё последнюю версию протокола поковырять.
P.S.S.: Последняя версия в данном вопросе от первой, описанной в исходной работе, ничем существенно не отличается. Стороны всё равно обмениваются подписанными параметрами для вывода совместного секрета DH и получают связанную цепочку сообщений, ключей и MAC, только более сложным способом. Если злонамеренная сторона шлёт все параметры из детерминированного ГПСЧ, а затем раскрывает его алгоритм и ключ (выведенный из своего секретного ключа OTR), то фактически она доказывает и авторство второй стороны, и подлинность содержимого записанной переписки. Протокол соцмиллионера там сбоку-припёку и обычно используется только как доп. проверка. Плохо, что по последней версии нормальной работы нет.
P.S.S.: Насчёт доказательства подлинности содержимого пока сомнения остаются. Первый обмен по DH выдаст общий gxy, на составных частях которого будут красоваться подписи обеих сторон и подставной x из детерминированного ГПСЧ. На всех последующих — выведение MAC'ов, ключей и пр. будут влиять предопределённые x, но y Алиса может выбирать свободно вместо Боба. Может ли Алиса к предопределённым gx подбирать такие y, чтобы получить осмысленный результат во всей последующей переписке? Если может, не нарушая связности протокола со своим ГПСЧ — то тогда она может подделывать переписку, значит содержимое переписки останется отрицаемым. Если не может (и ей нужен реальный Боб) — то тогда отрицаемость действительно теряется и становится доказываемой третьей стороне. Методы с групповой генерацией секрета Алисы, также как и методы с последующей попыткой связаться участникам группы с Бобом через раскрытый ключ Алисы — это вообще отдельные сценарии, ограниченной, скажем так, неотрицаемости содержимого.

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