id: Гость   вход   регистрация
текущее время 22:21 28/03/2024
создать
просмотр
ссылки

ZAS Communicator


ZAS Communicator Opensource Project: secure voice, file transfer and text chat.


http://www.zas-comm.ru


Комментарии, советы, предложения?


 
На страницу: 1, 2, 3, 4, 5, ... , 8, 9, 10, 11, 12 След.
Комментарии
— ZAS (18/07/2014 11:09)   <#>
"Мы чужие на этом празднике жизни.." © Он же.


Киса, позвольте спросить вас, как криптограф криптографа...

http://www.zas-comm.ru
— gegel (19/07/2014 14:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
он генерирует на разных машинах разные TOX ID, как и TorChat.

Торчат элементарно переносится копированием каталога \bin\Tor\hidden_service, содержащим приватный ключ и b32-отпечаток публичного. Думаю, с TOX ситуация аналогичная.
Возражений по существу протокола аутентификации не поступило. Очень хорошо.

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

Я так понимаю, это публичный ключ пользователя, который должен быть известен второй стороне, и вторая сторона должна доверять этому ключу (т.е. однозначно связать его с именем пользователя). Тут возникает вопрос: как вторая сторона впервые получает этот ключ? Если по постороннему доверенному каналу, то к чему тогда эта изюминка с поиском по ключевым словам, которой Вы так гордитесь? Если же через DHT после поиска, то как передается доверие к ключу?
Тут есть амбициозный вариант создать свою PKI (но тогда надо предусмотреть передачу подписей вместе с ключом и проверку цепочек), или же можно использовать PGP. Если Вы будете использовать PGP, то опишите, как именно планируете это делать.
Не подумайте, что я придираюсь к мелочам, но на практике ломать вашу IDEA и даже XTEA никто в здравом уме не станет, а вот на кривом протоколе аутентификации эксплоит будет использован сразу же при достижении проектом хоть какого-то уровня популярности.
— ZAS (19/07/2014 19:29)   <#>
открытого ключа проверки подписи этого пользователя


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


Публичный ключ проверки подписи связан с 256-битным userid пользователя: userid = hash(Key).
Нам нужно один раз убедиться что данный userid действительно соответствует тому пользователю, с кем мы общаемся. Для этого мы созваниваемся с этим пользователем по ZAS и сверяем наши userid (предполагается что опознаем друг друга). После чего обе стороны помещают проверенные userid в доверенный список.

То есть для доверенной связи с Васей Печкиным мне достаточно один раз проверить, что userid = 0x1234... это действительно Вася Печкин.


Тут возникает вопрос: как вторая сторона впервые получает этот ключ?


См. описание процедуры соединения. При установлении связи всегда стороны передают друг другу свои открытые ключи, по недоверенному каналу. Если мы уже сверяли userid, то достаточно проверить if(userid == hash(Key))... Если не сверили, всегда можно сверить.

Если по постороннему доверенному каналу, то к чему тогда эта изюминка с поиском по ключевым словам, которойВы так гордитесь?


Как я могу найти gegel в ZAS, не зная его userid? Только по ключевым словам в DHT.

Если же через DHT после поиска, то как передается доверие к ключу?


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

В дополнение к подписям, можно всегда сверить параметры текущего соединения, аналогично как делается в PGPhone и пр.

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


Идея PKI в принципе порочна и ненадежна. Не стоит недооценивать противника. Если есть концептуальная возможность что-то взломать, она уже задействована.

или же можно использовать PGP. Если Вы будете использовать PGP, то опишите, как именно планируете это делать.


Моя жизненная позиция – по возможности не зависеть от третьих сущностей.

Хотя, если есть любой канал, по которому можно гарантированно узнать, что gegel = userid 12345..., то можно воспользоваться этим каналом. Но, даже если мы точно знаем userid, все равно нужно найти текущие IP:port корреспондента. Это делается через DHT.
— gegel (19/07/2014 23:49, исправлен 19/07/2014 23:51)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
(предполагается что опознаем друг друга)

Я так понимаю, речь идет о биометрической (голосовой) идентификации путем сверки произносимых абонентами отпечатков сессионного ключа. Это стандартный подход, ОК. Единственное что – проверьте по своему заветному DiffieHellman.cpp: т.к. вызываемый абонент может в определенной степени влиять на общий секрет путем подбора y по известному X, то он может за разумное время подобрать такое Y, что скажем, 32 бита вашего отпечатка совпадут с заданными. Т.о. можно отмитмить соединение так, что произносимые короткие отпечатки совпадут. Обычно в таких случаях используют коммитмент или Y, или какого-то случайного мидификатора подсчета отпечатка. Надеюсь, Вы это учли, сейчас влом смотреть Ваш код.


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

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


В OnionPhone (проект в процессе) можно будет использовать 4 варианта аутентификации:
– голосом по отпечатку общего секрета;
– публичными DH-ключами + они могут быть подписаны PGP + могут передаваться в процессе соединения и автоматически сохраняться на диске; позже можно проверить подпись и вручную назначить уровень доверия к каждому ключу в адресной книге; + они могут быть переданы по другому доверяемому каналу и добавлены в книгу вручную.
– общим секретом (фразой) + скрытое уведомление под принуждением изменением части фразы;
– по onion-адресам (по Abadi, аналогично аутентификации в TorChat путем создания встречного соединения по указанному onion-адресу и обмена доказательствами).
Хотелось бы видеть возможность выбора и у Вас, и у TOX.

— ZAS (20/07/2014 01:16)   <#>
Надеюсь, Вы это учли, сейчас влом смотреть Ваш код.


Summary по ZAS аутентификации.
Посвящается тем, кто не читает то, о чем писали в треде много раз:

1. Sigma протокол. В ZAS каждый пользователь идентифицируется 256-битным userid. Это userid представляет собой хеш от открытого ключа пользователя. Чтобы иметь защищенную связь с Васей, достаточно знать факт, что данное userid принадлежит Васе. Достаточно один раз в этом убедиться. Неважно, каким cпособом. При личной встрече, биометрически, c помощью PGP, третьих доверенных лиц, PKI или голубиной почты. Как угодно.
Если я удостоверился, что Вася = userid 12345.. то я могу добавить запись "Вася = 12345..." в свой файл проверенных юзеров. Это делается кликом мышки.
(мой файл проверенных юзеров защищен от посторонней модификации моей подписью)
(проверенные и непроверенные юзера показываются разным цветом в списке)

2. Независимо от (1), всегда можно сверить отпечаток DH параметров, которые должны быть одинаковы у A и B.
Отпечаток = хеш от открытых значений { g,p, g^X, g^Y }.

Мне кажется, что (1) + (2) практически достаточно. Может быть полезно добавить еще один механизм аутентификации на основе pre-shared secret password с уведомлением о прессинге; cпасибо за мысль. Подумаю на эту тему.

(не знаю, какая модель security принята у TOX; навскидку не нашел вразумительного обьяснения).

http://www.zas-comm.ru
— gegel (20/07/2014 19:54)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Достаточно один раз в этом убедиться. Неважно, каким cпособом. При личной встрече, биометрически, c помощью PGP, третьих доверенных лиц, PKI или голубиной почты.

Пока что рассматриваем биометрический вариант: абоненты знают друг друга по голосу, устанавливают связь впервые. Какие Вы им даете рекомендации по сверке UserID, т.е. что конкретно кто должен произнести? Я так понимаю, у каждого на экране будут отображены UserID-ы: собственный и противоположной стороны. Что дальше? Кто и чей ИД должен зачитать?
Дело в том, что в данном случае тактика влияет на безопасность.
— ZAS (21/07/2014 00:54)   <#>
Пока что рассматриваем биометрический вариант: абоненты знают друг друга по голосу, устанавливают связь впервые. Какие Вы им даете рекомендации по сверке UserID, т.е. что конкретно кто должен произнести? Я так понимаю, у каждого на экране будут отображены UserID-ы: собственный и противоположной стороны. Что дальше?


Cтороны зачитывают оба userid по очереди. Группами по 32 бита. Сначала Вася зачитывает 32 бита от userid Пети, потом Петя зачитывает следующие 32 бита от userid Пети, потом опять Вася зачитывает очередные 32 бита от userid Пети, потом опять Петя зачитывает очередные 32 бита своего userid и.т.д. потом та же процедура сверки userid Васи.

http://www.zas-comm.ru
— Гость (21/07/2014 01:35)   <#>

А если противник, обладая голосовым банком данных, преварительно создал запись их голосов для фейковых отпечатков, он может устроить MITM. :)
— gegel (21/07/2014 15:36, исправлен 21/07/2014 15:37)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
обладая голосовым банком данных

Для этого даже не нужен банк данных.


Для лучшего понимания перепишем инструкция так:
"Стороны зачитывают начало (половину) чужого ИДа и конец своего."
Достаточно заставить их произнести полные ИДы Еве, и можно подставлять записи при MitM. Помню фильм, когда девушка в баре выуживала с парня по слову для построения фразы доступа, и никак не могла заставить произнести последнее дурацкое слово, неестественное для свидания.


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


Правильно будет отказаться от такого способа аутентификации (это лишь вводит в заблуждение пользователей) и оставить только озвучивание параметров соединения. Так сделано в ZRTP и всех VOIP-утилитах, его использующих. После биометрического подтверждения параметров друг другу MitM исключается, и тогда можно спокойно сохранить отпечатки текущих ключей как доверенные.
Причем еще правильнее озвучивать не публичные параметры (X и Y), как сделано у Вас, а хеш от общего секрета + дополнительные параметры, как сделано Циммерманном: если Алиса смогла зашифровать свой голос секретом, то понятно, что она его знает. И если она произнесла хеш секрета, то дополнительно ничем себя не скомпроментировала.
Но если Алиса произнесла публичные параметры (X, Y), то позже Боб-информант может предоставить судье-наблюдателю доказательство того, что зафиксированный судьей зашифрованный разговор был его и Алисы.

— ZAS (21/07/2014 19:01)   <#>
Aутентифицировать голосом постоянные параметры неразумно. Правильно будет отказаться от такого способа аутентификации и оставить только озвучивание параметров соединения.


Да, Вы правы. Тем более если параметры соединения верифицированы, то переданные по этому соединению userid можно считать тоже верифицированными.

Причем еще правильнее озвучивать не публичные параметры (X и Y), как сделано у Вас, а хеш от общего секрета + дополнительные параметры,


Это тоже учтем в следующем билде.

Спасибо за критику и дельные предложения.

http://www.zas-comm.ru
— ZAS (21/07/2014 20:37)   <#>
Достаточно заставить их произнести полные ИДы Еве, и можно подставлять записи при MitM.
т

Нет, не так.

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

http://www.zas-comm.ru
— Гость (21/07/2014 21:36)   <#>

Не обязательно. Если она подменяет только одну сторону, она сможет читать все сообщения, предназначенные этой стороне (но не её ответы абоненту).
— ZAS (21/07/2014 22:17)   <#>
Для того, чтобы Ева могла организовать MitM, ей нужно выдать cебя за A и за B.


Не обязательно. Если она подменяет только одну сторону, она сможет читать все сообщения, предназначенные этой стороне (но не её ответы абоненту).


Не получится. Такой вариант невозможен по сути протокола. Cекрет общий, аутентификация в обе стороны.

http://www.zas-comm.ru
— gegel (21/07/2014 23:11, исправлен 21/07/2014 23:15)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Для этого Еве придется произнести фиктивные сгенерированные ею userid голосом A и голосом B.

Ева генерирует фиктивные UserID, инициирует тестовые сессии с А и с Б, и А и Б произносят эти UserID в процессе первичной аутентификации с Е (правда, не ту половину, но все же).


Правда, проблема для Евы в том, что при этом А и Б сохраняют эти UserID, как принадлежащие Еве, и будут слегка удивлены, если потом будет совпадение. А если не сохранят (не добавят Еву в контакт-лист)?


Но это все так шатко выглядет, что лучше делать, как все (как Циммерманн в данном случае) и не искать приключений.

— Гость (21/07/2014 23:28)   <#>

Да, может быть. Я про верификацию PGP думал, когда писал.
На страницу: 1, 2, 3, 4, 5, ... , 8, 9, 10, 11, 12 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3