По настоящему распределённый сетевой ресурс
03.11.2021
|
velkin
 |
Читал статью:
P2P — Следующий этап развития информационных систем
И задумался, а как сделать ресурс по настоящему распределённым.
В идеале имеем равноправные узлы, которые могут обмениваться друг с другом данными.
Центра нет, когда одному из узлов нужны данные, он забирает их с других узлов напрямую.
Но что если:
1) На узле C стоит запрет на становление сервером.
2) А узел D находится за NAT.
Тогда картина получения данных выглядит вот так.
А данные с других узлов можно получать лишь так.
Чтобы C и D могли обменяться данными нужен посредник и это может быть как узел A, так и узел B.
Предположим:
1) A доверенный узел не искажающий данные.
2) B недоверенный узел возможно искажающий, а возможно и не искажающий данные.
И вот тут до меня дошло, что централизованные сервисы не учитывают атаку посредника.
Потому решив проблему атаки посредника для централизованных сетевых ресурсов решим её же и для распределённых.
С ходу в голову пришло такое решение.
1) Каждый клиент имеет уникальный идентификатор.
2) Создаём пару ключей открытый и закрытый на каждом клиенте.
3) Отправляем ключ каждого клиента для расшифровки другим клиентам напрямую или через ну очень очень доверенный узел.
4) При отправке сообщений шифруем его ключом для шифрования с содержимым "идентификатор + данные об изменениях".
5) Сообщение проходит через посредника, расшифровывается на клиенте, и если идентификатор совпал, тогда данные добавляются, но всё равно с пометкой от кого они непосредственно пришли.
Но даже если удастся сохранить целостность, ведь данные об изменениях могут иметь глобальные порядковые номера изменений (тема блокировок), то посредник может просто не переправлять сообщения. С другой стороны можно воспользоваться несколькими посредниками, например, узлами A и B и сравнить пришедшие данные.
И вопросы:
1) Кто что думает по этому поводу?
2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
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) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
| 03.11.2021 3 комментария |
V>3) Отправляем ключ каждого клиента для расшифровки другим клиентам напрямую или через ну очень очень доверенный узел.
Это может работать в не очень большой сети, но глобально не масштабируется.
V>2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
Советую почитать, как это сделано в работающих системах. Для передачи данных — TOR и подобные, для хранения — IPFS, FileCoin и подобные.
V>И вопросы:
V>1) Кто что думает по этому поводу?
V>2) Как бы вы решали проблему атаки посредника, когда данные одного клиента хранятся у другого?
Это хорошо известная проблема доверия. У неё есть всего несколько известных решений:
1. PKI: ключи выдаются неким доверенным центром; можно построить иерархию доверенных центров и соответствующую ей иерархию ключей.
MITM предотвращается тем, что злонамеренного участника мы дисквалифицируем через процедуру отзыва ключа.
2. PGP: ключи генерируются локально; решение о доверии или недоверии конкретному ключу принимает каждый конкретный пользователь; есть способ обмена информацией о том, кому доверяют те, кому доверяете вы (что-то типа социальной сети). "Консенсус" формируется вручную. Злонамеренного участника мы дисквалифицируем при помощи peer-to-peer обмена, т.е. если я поймал его на внесении деструктивных изменений, то я отказываю в доверии его ключу, и об этом узнают все, кто доверяет мне.
3. Blockсhain: ключи генерируются локально; внесение изменений — дорогостоящий процесс, требующий proof of work. Консенсус формируется автоматически. Если злонамеренный участник пытается внести изменение, которое не подтверждается другими участниками, то его ветка блокчейна дискриминируется и в общий пул не попадает.
1. Авторитетная организация, в HTTPS применяется этот подход, когда вы доверяете авторитетной организации Letsencrypt и другая сторона предъявляет вам публичный ключ, подписанный этой авторитетной организацией. Минус в централизованности.
2. Web of Trust, в GPG применяется этот подход. Когда вы знаете, кому доверяют ваши друзья и вы доверяете этим людям тоже. Это распределённая система но успеха не получила. Хотя, имхо, в основном из-за неудачной реализации. Если добавить сюда геймификацию, ачивки, то юзеры с удовольствием начнут проверять ключи друг друга.
3. Вы проверяете публичный ключ по другому каналу. Эта схема получила распространение в мессенджерах вроде Whatsapp, Telegram, Signal, но на практике ей мало кто пользуется.