Как безопасно хранить данные с ненадежной стороной?

Алиса хочет хранить ключ: значение пары с Бобом. Цель упражнения состоит в том, чтобы Алиса могла использовать Боба в качестве надежного сервиса хранения данных, даже если Боб не заслуживает доверия. (Правильно реализованный) MAC/AEAD/Signature означает, что Боб не может вмешиваться в записи. Но обычной аутентификации недостаточно, чтобы гарантировать, что Боб вернет правильную запись, потому что она не мешает Бобу воспроизводить старые записи.

Вот пример. Предположим, что где-то среди ключ и стоимость — правильно реализованный безопасный аутентификатор, который Алиса может использовать для проверки полученных записей:

• наборы Алисы ключ1:значение1 с Бобом
  • Боб сохраняет его правильно
• Алиса позже перезаписывает ключ1 и наборы ключ1:значение2 с Бобом где значение2 != значение1
  • Когда Алиса спрашивает ключ1 от Боба она ожидает получить значение2
  • Но Боб мог сохранить и воспроизвести значение1
    • Проверка тега HMAC будет пройдена, поскольку обе записи были созданы Алисой.

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

Как Алиса может гарантировать, что она получит самую последнюю запись от Боба?

Другие цели/вопросы безопасности

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

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

От «Titanium: система обмена файлами, скрывающая метаданные» со злонамеренной безопасностью":

Кроме того, критически важна целостность, которая не обеспечена в [34]. Злоумышленники не должны иметь возможности писать другим пользователям файлы. Вредоносные серверы не должны обслуживать неправильные или устаревшие файлы, не будучи пойманным. Достижение целостности в присутствие злонамеренного противника является сложной задачей, а иногда невозможно. Например, в любой односерверной конструкции невозможно иметь целостность [36–41] против злонамеренных сервер, потому что сервер всегда может представлять разные версии файлов разным пользователям, что мы обсуждаем в §II-B.

Существует невозможный результат [36–41], говорящий о том, что односерверное хранилище системы не могут гарантировать целостность от вредоносных сервер, так как сервер всегда может представить старую версию хранения для определенных пользователей. Отдельная система, либо другой сервер [39] или блокчейн [40, 41], необходимо использовать для восстановления таких гарантии целостности.

Приведенные ссылки:

36. Д. Мазьер и Д. Шаша, «Создание безопасных файловых систем» из византийского хранилища, — в PODC № 02.
37. Дж. Ли, М. Крон, Д. Мазьер и Д. Шаша, «Безопасность» ненадежный репозиторий данных (SUNDR), в OSDI 04.
38. А. Дж. Фельдман, В. П. Зеллер, М. Дж. Фридман и Э. У. Фельтен, «SPORC: групповое сотрудничество с использованием ненадежных облачные ресурсы», в OSDI №10.
39. Н. Карапанос, А. Филиос, Р. А. Попа, С. Капкун, «Verena: сквозная защита целостности веб-приложений», в S&P № 16.
40. А. Томеску и С. Девадас, «Catena: Эффективная недвусмысленность через биткойн», в S&P №17.
41. Ю. Ху, С. Кумар и Р. А. Попа, «Призрак: к безопасная система обмена данными от децентрализованного доверия, — в НСДИ №20