По настоящему распределённый сетевой ресурс
От: 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) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.