Распределенные системы хранения: Аудит целостности многочисленных экземпляров, часть 2

(Окончание, начало см. https://rusrim.blogspot.com/2020/04/1.html )

Секреты
Если операция аудита не предполагает скачивание всего контента, то в её ходе аудитор должен затребовать выполнение хранящей реплику системой вычислений, при которых:

• Система хранения не знает результат заранее;


• В качестве исходных данных используется часть реплики (метод PoP) или вся реплика (метод PoR).

Таким образом, например, не является адекватным запрос у хранилища реплик хеша контента, поскольку хранилище могло бы предварительно вычислить и сохранить хэш, а не контент.

PoP-системы могут, например, удовлетворить эти требования посредством запроса хеша случайного диапазона байтов в контенте. PoR-системы могут, например, удовлетворить эти требования, посылая случайное число-нонс, который хранилище реплик должно присоединить к контенту перед его хешированием. Важно, чтобы в случае, если аудитор заранее вычисляет и сохраняет эти случайные значения, они сохранялись в тайне от хранилища реплик. Если хранилище реплик обнаружит их, оно может заранее вычислить ответы на будущие запросы аудита и незаметно для аудиторов уничтожить контент.

К сожалению, невозможно полностью исключить вероятность того, что хранилище реплик или сговорившиеся друг с другом хранилища реплик скомпрометируют хранилище, содержащее предварительно вычисленные аудитором значения. В идеальном случае аудитор должен генерировать случайные значения при каждой операции аудита, а не вычислять их предварительно. Увы, это обычно возможно только в том случае, если аудитор имеет доступ к реплике, хранящейся в защищённом от модификации доверенном хранилище (см. выше). В архитектуре взаимного аудита, используемой системой LOCKSS, узлы действительно имеют доступ к реплике, хотя и не в надёжном хранилище, поэтому используемые системой случайные одноразовые нонсы генерируются заново для каждого аудита.

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

Сравнение аудита динамических и статических данных

В контексте электронной сохранности, проверяемые реплики можно считать статичными или, по крайней мере, только пополняемыми. В статье рассматривается гораздо более сложная проблема аудита реплик, которые являются динамическими и могут обновляться с течением времени. В разделе 3.2 своей статьи Линь Янфей и др. обсуждают ряд методов для аутентифицированных структур данных (authenticated data structures, ADS), позволяющих проводить эффективный аудит динамических данных (см. https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.5356 ):

«Существует три основных ADS-структуры: аутентифицированный список с пропусками на основе рейтинга (rank-based authenticated skip list, RASL),  хеш-дерево Меркля (Merkle hash tree, MHT) и таблица версий блоков данных в модифицируемом файле (map version table, MVT).»

Методы

Линь Янфей и др. в таблице 4 дают сводное описание семи методов:

Поля таблицы: название схемы; вид аутентифицированной структуры данных; публичная проверяемость, работа с динамическими данными, особенности реализации – Н.Х.

Как можно видеть, лишь четыре из семи методов удовлетворяют обоим их требованиям, и если я правильно интерпретирую выделенные в цитате слова:

«… итоговое сравнение всех существующих схем аудита реплицированного владения данными (replicated data possession) ... приведено в таблице 4.»

То все они PoP-типа, а не PoR.

Как насчет блокчейна?

В проходящих сегодня дискуссиях по вопросу проверки целостности неизбежно всплывает идея использования блокчейна. Недавний пример – научно-исследовательская статья Начикета Тапаса (Nachiket Tapas) и др. «Публично проверяемое облачное хранилище на основе блокчейна» (Blockchain-Based Publicly Verifiable Cloud Storage, см. https://ieeexplore.ieee.org/document/8784090 ). В аннотации сказано:

«Использование облачных хранилищ, в связи с растущей популярностью решений «интернета вещей», неуклонно расширяется и начинает играть всё более критически-важную роль для сервисов и коммерческих организаций. В свете этой тенденции клиенты облачных услуг всё больше зависят (и, соответственно, ставятся на карту их интересы) от постоянной добросовестности и надлежащего поведения поставщиков.

Это доверие может оказаться необоснованным, учитывая то, что данные являются «новым золотом», и злонамеренный интерес на стороне поставщика может привести к незаконному присвоению, изменению, сокрытию данные или к отказу в доступе.

Ключ к решению этой проблемы заключается в выявлении и разработке протоколов, документирующих, как минимум, все взаимодействия между клиентами и поставщиками, и сделать собранную контрольную информацию широко доступной, поддающейся аудиту - следовательно, обеспечить её доказуемость.

В данной статье представлены предварительные результаты соответствующего исследования, включающие, в частности, сценарии, модели угроз, архитектуру, протоколы взаимодействия и гарантии безопасности предлагаемого решения на основе блокчейна.»

На рис.: Данные о майнерах криптовалюты Ether по состоянию на 15 февраля 2020 года, которые показывают высокую степень централизации

Как обычно, Тапас и др. просто предполагают, что блокчейн Ethereum неподвержен модификациям  (см. на эту тему https://blog.dshr.org/2019/07/blockchain-briefing-for-dod.html ), безопасен и всегда доступен, несмотря на то, что его безопасность опирается на  его децентрализацию ( https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274 ), которой на самом деле нет. Поскольку инфраструктура, на которой базируется выстроенное ими здание, на практике не обеспечивает условий, от которых зависит работоспособность их решения, на практике оно не обеспечит гарантий безопасности, о которых они заявляют.

Все, что они хотят получить от блокчейна Ethereum, может быть обеспечено посредством использования того же рода проверяемых журналов аудита, что используются в концепции «прозрачности сертификатов» (см. https://ieeexplore.ieee.org/document/8784090 ; существует соответствующий стандарт RFC 6962 «Прозрачность сертификатов» (Certificate Transparency), см. https://tools.ietf.org/html/rfc6962 - Н.Х.), что позволяет избежать проблем, имеющихся у публичных блокчпейнов (см. https://blog.dshr.org/2018/12/blockchain-whats-not-to-like.html ). При этом, однако, возникнут непреодолимые, при скорости транзакций в промышленных облачных решениях, проблемы масштабирования.

Дэвид Розенталь (David Rosenthal)

Источник: DSHR's Blog
https://blog.dshr.org/2019/11/auditing-integrity-of-multiple-replicas.html