По настоящему распределённый сетевой ресурс
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 03.11.21 01:53
Оценка:
Читал статью:
P2P — Следующий этап развития информационных систем

И задумался, а как сделать ресурс по настоящему распределённым.

В идеале имеем равноправные узлы, которые могут обмениваться друг с другом данными.
равноправный узел A - B равноправный узел
                  | X |
равноправный узел C - D равноправный узел

Центра нет, когда одному из узлов нужны данные, он забирает их с других узлов напрямую.
  A        B        C        D
A - B    A - B    A   B    A   B
| \        / |    | /        \ |
C   D    C   D    C - D    C - D

Но что если:
1) На узле C стоит запрет на становление сервером.
2) А узел D находится за NAT.

Тогда картина получения данных выглядит вот так.
   в сети A - B в сети
          | X |
не сервер C   D за nat

А данные с других узлов можно получать лишь так.
  A        B        C        D
A - B    A - B    A   B    A   B
| \        / |    | /        \ |
C   D    C   D    C   D    C   D

Чтобы C и D могли обменяться данными нужен посредник и это может быть как узел A, так и узел B.

Предположим:
1) A доверенный узел не искажающий данные.
2) B недоверенный узел возможно искажающий, а возможно и не искажающий данные.

И вот тут до меня дошло, что централизованные сервисы не учитывают атаку посредника.

Атака посредника(Man in the middle (MITM)) — вид атаки в криптографии и компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом.

Взять тот же форум, администратор или даже модератор с соответствующими привилегиями могут менять сообщения пользователей, стирать их или напротив писать от чужого имени всё, что вздумается.

Потому решив проблему атаки посредника для централизованных сетевых ресурсов решим её же и для распределённых.

С ходу в голову пришло такое решение.
1) Каждый клиент имеет уникальный идентификатор.
2) Создаём пару ключей открытый и закрытый на каждом клиенте.
3) Отправляем ключ каждого клиента для расшифровки другим клиентам напрямую или через ну очень очень доверенный узел.
4) При отправке сообщений шифруем его ключом для шифрования с содержимым "идентификатор + данные об изменениях".
5) Сообщение проходит через посредника, расшифровывается на клиенте, и если идентификатор совпал, тогда данные добавляются, но всё равно с пометкой от кого они непосредственно пришли.

Но даже если удастся сохранить целостность, ведь данные об изменениях могут иметь глобальные порядковые номера изменений (тема блокировок), то посредник может просто не переправлять сообщения. С другой стороны можно воспользоваться несколькими посредниками, например, узлами A и B и сравнить пришедшие данные.

И вопросы:
1) Кто что думает по этому поводу?
2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
Re: По настоящему распределённый сетевой ресурс
От: wildwind Россия  
Дата: 03.11.21 07:02
Оценка: 6 (1)
Здравствуйте, velkin, Вы писали:

V>3) Отправляем ключ каждого клиента для расшифровки другим клиентам напрямую или через ну очень очень доверенный узел.


Это может работать в не очень большой сети, но глобально не масштабируется.

V>2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?


Советую почитать, как это сделано в работающих системах. Для передачи данных — TOR и подобные, для хранения — IPFS, FileCoin и подобные.
Re: По настоящему распределённый сетевой ресурс
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.11.21 06:03
Оценка: 18 (1)
Здравствуйте, velkin, Вы писали:

V>И вопросы:

V>1) Кто что думает по этому поводу?
V>2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
Это хорошо известная проблема доверия. У неё есть всего несколько известных решений:
1. PKI: ключи выдаются неким доверенным центром; можно построить иерархию доверенных центров и соответствующую ей иерархию ключей.
MITM предотвращается тем, что злонамеренного участника мы дисквалифицируем через процедуру отзыва ключа.
2. PGP: ключи генерируются локально; решение о доверии или недоверии конкретному ключу принимает каждый конкретный пользователь; есть способ обмена информацией о том, кому доверяют те, кому доверяете вы (что-то типа социальной сети). "Консенсус" формируется вручную. Злонамеренного участника мы дисквалифицируем при помощи peer-to-peer обмена, т.е. если я поймал его на внесении деструктивных изменений, то я отказываю в доверии его ключу, и об этом узнают все, кто доверяет мне.
3. Blockсhain: ключи генерируются локально; внесение изменений — дорогостоящий процесс, требующий proof of work. Консенсус формируется автоматически. Если злонамеренный участник пытается внести изменение, которое не подтверждается другими участниками, то его ветка блокчейна дискриминируется и в общий пул не попадает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: По настоящему распределённый сетевой ресурс
От: vsb Казахстан  
Дата: 11.11.21 07:47
Оценка:
Вопрос доверия к публичному ключу вроде достаточно старый и способов его организации не очень много.

1. Авторитетная организация, в HTTPS применяется этот подход, когда вы доверяете авторитетной организации Letsencrypt и другая сторона предъявляет вам публичный ключ, подписанный этой авторитетной организацией. Минус в централизованности.

2. Web of Trust, в GPG применяется этот подход. Когда вы знаете, кому доверяют ваши друзья и вы доверяете этим людям тоже. Это распределённая система но успеха не получила. Хотя, имхо, в основном из-за неудачной реализации. Если добавить сюда геймификацию, ачивки, то юзеры с удовольствием начнут проверять ключи друг друга.

3. Вы проверяете публичный ключ по другому каналу. Эта схема получила распространение в мессенджерах вроде Whatsapp, Telegram, Signal, но на практике ей мало кто пользуется.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.