Исследование показало, что существует множество решений для каждого выбранного критерия, так что выбранные системы сильно отличаются, особенно по как по критериям однорангового подключения, доверия и целостности, так и отказоустойчивости и справедливости. Как и предполагалось, Dropbox имеет уязвимости, характерые для всего класса традиционных систем облачного хранения, касающихся доверия, целостности и отказоустойчивости. P2P система Storj лучше справляется с отказоустойчивостью путем разбиения данных на блоки и распределения их по децентрализованной сети в 3 копиях для обеспечения файловой целостности и доступности. Подводя итоги сравнительного анализа, можно с уверенностью утверждать, что классическая модель облачного хранения клиент-сервер не решает всех проблем и требований хранения и синхронизации файлов. Кроме того, нельзя сказать, что при построении P2P децентрализованной системы проблема центральной точки отказа будет полностью решена. Существуют определенные типы атак такие, как атаки Sybil, к которым пиринговые модели хранения являются уязвимыми, а традиционные клиент-сервер - нет.

2.4 Риски внедрения

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

«Sybil» атака

Известно, что одноранговые и другие децентрализованные распределенные системы особенно уязвимы к атакам типа sybil [41]. Суть атаки состоит в создании такого количества узлов, которые будут захватывать или удалять сообщения в сети. Узлы, соседи в децентрализованной сети, как правило, выбираются из равномерно распределенного пула по определенному ID, и большинство сообщений отправляются по крайней мере трем соседям. Если атакующий контролирует 50% узлов сети, он успешно изолирует только 12,5% честных узлов [16]. В то время как надежность и производительность в этом случае ухудшатся, сеть будет функционировать до тех пор, пока большая часть сети не будет состоять из злонамеренных узлов.

«Google» атака.

Термин «Google атака» был впервые введен разработчиком проекта Bitcoin Core Питером Тодд (Peter Todd) для описания координированной атаки на сеть крупной корпорацией или организацией, контролирующей большое количество вычислительных мощностей или места для хранения. Атака Google, является гипотетическим вариантом атаки Sybil, осуществляемой организацией с огромными ресурсами. Для примера была взята компания Google, которая на данный момент имеет наибольшее количество хранимых данных в «облаке». Судя по источникам [27], [28] и [29] Google в настоящий момент хранит примерно 8000 Пбайт данных. Концепция децентрализованного хранилища вводит понятие пользовательского пространства, или коллективное неиспользованное свободное пространство потребителей. Судя по источнику [27] пространство хранения в децентрализованной сети может увеличиться до 250 000 Пбайт, если пользователи начнут пользоваться такой системой в качестве основной облачной системой хранения. Но, даже если такая крупная компания, как Google приостановит все свои сервисы для атаки в сети, невозможно превзойти ресурсы пользовательского пространства, так как оно имеет перспективу в несколько раз превысить настоящее пространство компании Google. Несмотря на это, угроза «Google attack» существует и является риском для любой децентрализованной системы хранения, так как трудно предсказать действия атакующего, обладающей большими ресурсами. Единственной надежной защитой от атаки «Google» является создание сети , ресурсы которой будут находится на том же уровне, что и нападающей системы.

Атака «затмения» (Eclipse)

При данной атаке злоумышленник пытается изолировать узел или набор узлов таким образом, чтобы все исходящие подключения или сообщения касались вредоносных узлов. Атаки Eclipse являются трудно идентифицируемыми, поскольку вредоносные узлы, как правило, функционируют нормально, только «затмевая», то есть скрывая, некоторые важные сообщения или информацию. Данная проблема в современных децентрализованных системах хранения, как SIA и Storj решается путем использования хэшей в качестве открытых ключей для идентификации узлов. [16], [42]. Для того, чтобы «затмить» любой узел в сети, злоумышленник должен повторно генерировать пары ключей, пока не найдет три ключа, чьи хэши будут ближе к целевому узлу, чем любой другой добросовестный узел-сосед. Сложность данной атаки является пропорциональной количеству узлов в сети, так как по своей сути напоминает работу доказательства восстановимости [16]. Следовательно, лучшим способом защиты от атак типа Eclipse является увеличение числа узлов в сети. Для больших сетей атака «затмения» является становится слишком дорогой [15].

Выводы

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

Сравнительная характеристика традиционной и децентрализованной системы по выбранным критериям относительно безопасности хранения выявила несомненное преимущество Storj над Dropbox. Децентрализованная система Storj является более отказоустойчивой и предоставляет непрерывную доступность, гарантируя целостность данных путем аудитов данных. Также в сравнении с Dropbox децентрализованные системы на блокчейне, как Storj, полностью отказываются от посредника, контролирующего ключи шифрования, так как шифрование и деление файлов происходит на стороне клиента.

Глава 3. Отказоустойчивость децентрализованного хранилища на базе блокчейна

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

3.1 Способы поддержания избыточности данных

Провайдеры облачных услуг как правило владеют или арендуют серверы для хранения файлов своих клиентов. Обычно используется схема RAID (Redundant Array of Independent Disks -- избыточный массив независимых дисков) или несколько центров хранения данных для обеспечения большей отказоустойчивости сети. Говоря об одноранговых системах, схемы резервирования означают хранение отдельных избыточных частей данных, требуемых для восстановления любой из потерянных частей в случае отказа в работе одного узла. Если какой-либо из узлов покинул сеть, недостающие данные могут быть восстановлены с помощью избыточной информации. В децентрализованной сети с целью предотвращения перманентной потери данных в связи с отключением узла, на котором хранились данные, при заключении контракта хранения пользователь обязан включить в него схемы резервирования и уровень избыточности данных. Так как отдельная схема применяется только к частям данных, пользователь может выбрать несколько типов схем резервирования:

· Простое зеркалирование данных

Зеркалирование данных является самым простым способом поддержания избыточности данных путем создания резервных копий. Доступность части данных (шарды) обеспечивается путем схемы, напрямую зависящей от времени безотказной работы узла, в котором хранится данная шарда. Так как для сборки файла нужны все его части, доступность файла приравнивается доступности последней требуемой части. В случае сброса контракта (падения узла) резервная копия восстанавливается и для нее находится новое местоположение в сети.

· Удаляющее кодирования Рида-Соломна

Деление частей данных происходит по алгоритму Рида-Соломна. В статье “Network Coding for Distributed Storage Systems” [23] приведено объяснение преимущества удаляющего кодирования по сравнению с резервным копированием. В случае потери отдельной части, и файл, и часть будут восстановлены, после чего заключается новый контракт для отдельной шарды. Используя удаляющее кодирование файл размера М делится на k частей, затем из k частей создается n фрагментов и распространяются n нодам. Соответственно файл может быть восстановлен из k закодированных фрагментов. За счет возможности определения уровня толерантности к потере определённого числа частей данных удаляющее кодирование значительно снижает вероятность потери доступа к файлу.

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

3.2 Схемы взаимодействия узлов в децентрализованном хранилище

С целью проверки гипотезы о преимуществе децентрализованного хранилища на блокчейне над традиционным облачным хранилищем мной был проанализирован исходный код и разработаны модели алгоритмов поведения узлов в такой сети в виде схем последовательности в нотации UML. В данном параграфе будут описаны 5 сценариев взаимодействия узлов:

· Создание контракта хранения

· Выполнение контракта хранения

· Формирование избыточности файлов (резервное копирование)

· Проверка целостности и доступности данных (аудит файлов)

· Запрос данных

В децентрализованной сети взаимодействие происходит между узлом, предоставляющем место хранения, и узлом, который в свою очередь заимствует место для хранения собственных файлов посредством пользовательского интерфейса. Нотация UML позволяет наиболее точно отобразить взаимодействие узлов в виде отправки сообщений посредством пользовательского интерфейса, так как данный язык графического описания разработан для объектного моделирования в сфере разработки программного обеспечения и моделирования бизнес-процессов. Диаграммы последовательности используется для наглядного представления связи действующих лиц в рамках информационной системы. Для разработки схем последовательности в нотации UML было выбрано программное обеспечение Google Draw.io.

На схемах узел, предоставляющий место хранения - Farmer, а узел, заимствующий - Renter. Связь между узлами децентрализованной сети осуществляется посредством пользовательского интерфейса, на схеме - UI (User Interface). Далее приведены модели взаимодействия узлов в виде схем последовательности, отражающих сценарии согласования и выполнения контрактов хранения, формирование резервных копий файлов, аудита файлов и запроса данных. Стоит отметить, что коммуникации между узлами, приказанные ниже на схемах, происходят автоматически в децентрализованной системе через пользовательский интерфейс. От узла, заимствующего место, требуется регистрация в системе, означающая получение закрытого ключа для входа, и отправка данных на хранение после успешного поиска «соседей» и при заключении контракта системой. Узел, предоставляющий место хранения, должен в свою очередь регистрироваться в системе и предоставить место. Схемы разработаны с целью доказательства надежности и безопасности децентрализованной системы хранения данных, использующей блокчейн, как хранилище метаданных и пользовательский интерфейс для коммуникации между узлами.

3.2.1 Создание контракта хранения

Рисунок 10 Согласование контракта хранения

Создание контракта хранения представляет собой нахождение узла, которого удовлетворят предлагаемого узлом-арендующим условия контракта. Для начала со стороны узла, заимствующего место хранения, отправляется сообщение с целью публикации контракта. При получении запроса на публикацию контракта «Фермер» выполняет следующие действия:

1. Проверяет получен ли уже запрос на публикацию (Publish message) от данного узла, если да - сообщение ошибки покажется узлу, желающему хранить данные.

2. В случае, если узел-заимствующий не отправлял запрос на контракт ранее и условия контракта являются удовлетворительными «Фермер» отправляет сообщение предложения контракта (Offer message). Фермер также может по желанию изменить условия контракта, и затем отравить предложение. Операция происходит до тех пор пока условия контракта не станут приемлемыми для обоих сторон. При согласовании контракта, фермер отправляет в сообщении Offer следующие параметры: собственный ID и подпись, а также информацию о месте назначения платежа (“Renter” платит фермеру после каждого аудита данных). Если условия контракта, обозначенные в сообщении Offer являются удовлетворительными для «съемщика» он отправляет свою подпись, ждет подписи от фермера и после чего обе стороны сохраняют копию условий контракта в блокчейне. Тем самым контракт является согласованным после получения двух подписей и сохранения хэша данной транзакции в виде метаданных в блокчейне.

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

3.2.2 Выполнение контракта хранения (передача данных на хранение)

Рисунок 11 Передача данных на хранение

Выполнение контракта хранения является по сути передачей данных на хранение от узла-съемщика узлу-арендатору. Как только контракт подписан обеими сторонами (Рисунок 8.) со стороны узла-съемщика отправляется сообщения, включающее ссылку на контракт и саму шарду данных, отправляемую на хранение. Также в сообщении передачи (Consign) содержится дерево аудита, предназначенное для записи хэшей каждой проверки целостности данных. При получении вышеописанного сообщения «фермер» сверяет все хэши, чтобы удостовериться, что узел-съемщик имеет право хранить эти данные. После проверки узлу-заимствующему приходит сгенерированный криптографический токен (ключ) для открытия канала для непосредственной передачи данных на хранение. Фермер сохраняет у себя данные и автоматически делается запись хэша данной транзакции в блокчейне, после чего отправляет сообщение подтверждения узлу-съемщику, содержащее хэш транзакции. «Арендующий» сохраняет хэш транзакции в блокчейне после чего можно считать отправку данных успешной.

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

3.2.3Создание избыточности файлов (резервное копирование)

Рисунок 12 Создание резервных копий файлов

Поддержание избыточности, то есть резервное копирование, данных гарантирует отказоустойчивость системы. Для узла-съемщика желательно иметь несколько резервных копий каждой из шард в сети у нескольких фермеров в случае, если один из фермеров-контрактников покидает сеть, теряет данные или каким-то образом нарушает условия договора хранения. На Рисунке 10. Описан сценарий зеркалирования данных от оригинального фермера избыточному арендатору. До того, как происходит само зеркалирование данных, узел, заимствующий место хранения, должен согласовать условия договора хранения с избыточным фермером. Как только договор подписан обеими сторонами, арендующий узел отправляет сообщение (MIRROR) избыточному фермеру о необходимости копирования данных от другого фермера. После чего со стороны избыточного фермера отправляется запрос о передаче данных другому фермеру. В результате исходный фермер передает данные избыточному фермеру в виде сообщения о передаче (CONSIGN), содержащего шарду данных, хэш контракта и элементы дерева аудита. При получении набора данных в виде шарды избыточный фермер отправляет подтверждение узлу-съемщику об успешном зеркалировании данных. После того, как хэш транзакции данного резервирования данных записан локально в блокчейне каждой из сторон, процесс создания избыточности можно считать завершенным.

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

3.2.4 Проверка целостности и доступности файлов

Рисунок 13 Аудит файлов

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

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

3.2.5 Запрос данных

Для восстановления данных со стороны узла-съемщика отправляется сообщение о возвращении данных (RETRIEVE), содержащее хэш извлекаемых данных. При получении такого сообщения фермер сверяет подпись отправителя, проверяет контракт хранения по полученному хэшу и тем самым определяет имеет ли право отправитель получить требуемые данные. После проверки сообщения, фермер отправляет криптографический токен (ключ) для открытия канала для передачи данных и непосредственно передает требуемую шарду. Получив данные, арендующий узел проверяет целостность данных и отправляет сообщение подтверждения успешного восстановления данных фермеру. Процесс восстановления данных можно считать завершенным после того как хэш данной транзакции записан локально у обеих сторон.

Рисунок 14 Запрос данных

Проделав моделирование взаимосвязи узлов в децентрализованной сети можно убедиться в следующем:

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

· Запись каждой транзакции и изменения данных в блокчейне гарантирует, что ни одна итерация с файлом не может пройти незамеченной.

· Посредством регулярного аудита файлов пользователь может быть убежден в целостности собственных файлов.

Выводы

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

Говоря о способах резервирования для поддержания избыточности можно отметить, что оба способа (зеркалирование и удаляющее кодирование Рида-Соломна) поддерживают достаточную отказоустойчивость к потере данных. Децентрализованные системы на блокчейне дают пользователям возможность выбирать инструмент резервирования и тем самым человек сам в состоянии повысить вероятность восстановимости своих файлов, определяя степень избыточности по своему усмотрению.

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

Заключение

Главной проблемой современных облачных хранилищ является существование посредника, провайдера облачной услуги. Третья доверенная сторона, как правило, имеет доступ к данным, так как хранит ключи шифрования. Данные хранятся на централизованных серверах, которые являются привлекательными точками атак для злоумышленников. В таком случае безопасность и защищенность данных является под вопросом, а в наш век информатизации является важным фактором, как для индивидуальных пользователей, так и для крупных организаций. Данная ВКР исследует модель децентрализованного облачного хранилища данных на базе блокчейна, выявляя преимущества над традиционным облачным хранилищем в отношении безопасности данных с точки зрения конфиденциальности, доступности и целостности.

В ходе написания дипломной работы была изучена научная литература на тему блокчейна и хранилища данных как традиционного, так и децентрализованного. Были выявлены недостатки современных облачных решений, а также проведен обзор литературы и существующих решений, таких как SIA, Storj и MaidSafe. Также был проведен анализ методов обеспечения защищенности данных в децентрализованной среде и проведения проверок узлов и файлов на предмет восстановимости. Также был проведен сравнительный анализ традиционного и децентрализованного решения для хранения файлов в ходе которого было выявлено несомненное преимущество Storj над Dropbox в отношении отказоустойчивости и защищенности данных. Как предполагалось, децентрализованная система Storj является более отказоустойчивой и предоставляет непрерывную доступность, гарантируя целостность данных путем аудитов данных. Также в сравнении с Dropbox децентрализованные системы на блокчейне, как Storj, полностью отказываются от посредника, контролирующего ключи шифрования, так как шифрование и деление файлов происходит на стороне клиента.

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

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

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

· Для достижения надежности системы хранения должны быть децентрализованными и должны распределять информацию в зашифрованном виде между независимыми узлами хранения.

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

В ходе данной выпускной квалификационной работы были выполнены следующие задачи:

· Изучена научная литература, касающаяся тем технологии Блокчейн и хранилища данных;

· Исследованы существующие проекты распределенной сети хранения данных, такие как Storj, Maidsafe, Filecoin, Block-cloud;

· Проведен анализ методов обеспечения защищенности данных в децентрализованной среде на блокчейне;

· Разработаны модели традиционного и децентрализованного хранилища;

· Проведен сравнительный анализ традиционного и децентрализованного облачного хранилища на основе блокчейн;

· Разработаны модели сценариев взаимодействия узлов в виде схем последовательности в нотации UML пользователя.

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

Список литературы

1. Internet Live Stats [Электронный ресурс] - URL: http://www.internetlivestats.com/internet-users/

2. Воронцова Е.А., Мелешенко Е.Г. Блокчейн: панацея или угроза для хранения и передачи информации // Синергия наук. 2016. № 5. ? С. 93 ? 101. ? URL: http://synergy-journal.ru/archive/article0044

3. S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2009. - URL: https://bitcoin.org/bitcoin.pdf

4. V. Buterin. Secret sharing and erasure coding: A guide for the aspiring dropbox decentralizer. 2014. - URL: https://blog.ethereum.org/2014/08/16/secret-sharing-erasurecoding-guide-aspiring-dropbox-decentralizer/

5. Hitesh Malviya Reinventing Cloud with Blockchain // White Paper. 2016.

6. Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, Steven Goldfeder Bitcoin and Cryptocurrency Technologies. 2016. - 308 c.

7. Venkata Narasimha Inukollu1 , Sailaja Arsi1 and Srinivasa Rao Ravuri Security Issues Associated With Big Data In Cloud Computing // International Journal of Network Security & Its Applications (IJNSA) 2014. - Vol.6 - №3.

8. Tim Mather Cloud Computing and Privacy. 2009. - 335 с.

9. Michael Crosby, Nachiappan, Pradan Pattanayak, Sanjeev Verma, Vignesh Kalyanaraman AIR Applied Innovation Review Issue. 2016. - №2.

10. Fahmida Y. Rashid The dirty dozen: 12 cloud security threats [Электронный ресурс] // InfoWorld. 2016. (Дата обращения: 18.05.2017)

11. Zach Herbert Why blockchains are the future of cloud storage [Электронный ресурс] // Sia blog. 2017. (Дата обращения: 18.05.2017)

12. David Vorick Decentralization in Light of the Recent Amazon S3 Downtime [Электронный ресурс] // Sia blog. 2017. (Дата обращения: 18.05.2017)

13. Johnathan Howell Getting Started with Private, Decentralized Cloud Storage [Электронный ресурс] // Sia blog. 2017. (Дата обращения: 18.05.2017)

14. Shawn Wilkinson, Jim Lowry Metadisk: Blockchain-Based Decentralized File Storage Application // Whitepaper.2014.

15. Shawn Wilkinson Storj: A Peer-to-Peer Cloud Storage Network // Whitepaper 2014. - v1.01

16. Shawn Wilkinson Storj: A Peer-to-Peer Cloud Storage Network // Whitepaper.2016 - v2.0

17. Nick Lambert and Benjamin Bollen “The SAFE Network a New, Decentralised Internet” // Paper for the final symposium of the ADAM project. 2014.

18. Vitalik Buterin Merkling in Ethereum [Электронный ресурс] // Etherum blog. 2015. - URL: https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ (Дата обращения: 18.05.2017)

19. D. Cawrey. How bitcoins technology could revolutionize intellectual property rights [Электронный ресурс] // CoinDesk. 2014. - URL: http://www.coindesk.com/how-block-chaintechnology-is-working-to-transform-intellectual-property (Дата обращения: 18.05.2017)

20. M. Araoz. What is Proof of existence? [Электронный ресурс] - 2014. - URL: http://www.proofofexistence.com/about

21. Roy Thomas Architectural Styles and the Design of Network-based Software Architectures // DISSERTATION in Information and Computer Science Fielding. 2000.

22. Johanna Amann Redundancy and Access Permissions in Decentralized File Systems // Die Dissertation wurde bei der Technischen Universitat Muncheneingereicht und durch die Fakultat fur Informatik. 2011.

23. Alexandros G. Dimakis Network Coding for Distributed Storage Systems //

IEEE Transactions on Information Theory. 2010. - VOL. 56 - № 9.

24. Filecoin: A Cryptocurrency Operated File Storage Network. [Электронный ресурс] - 2014 - URL: filecoin.io

25. G. Hall. Storj core [Электронный ресурс] - 2016. - URL: http://storj.github.io/core/

26. V. Buterin A next-generation smart contract and decentralized application platform, (2014). URL https://github.com/ethereum/wiki/wiki/White-Paper

27. How Big Is The Cloud? [Электронный ресурс] / Storj: официальный сайт. - URL: http://blog.storj.io/post/95376799893/how-big-is-the-cloud. (Дата обращения: 16.05.2017).

28. Google's Datacenters on Punch Cards [Электронный ресурс] / WhatIf. - URL: https://what-if.xkcd.com/63/ (Дата обращения: 16.05.2017).

29. Colin Carson How Much Data Does Google Store? [Электронный ресурс] // Cirrus Insight. 2016. - URL: https://www.cirrusinsight.com/blog/much-data-google-store

(Дата обращения: 16.05.2017).

30. Burkhard Stiller Communication Systems VIII University of Zurich Department of Informatics. 2015. p.73-84.

31. Nick Lambert, Qi Ma and David Irvine Safecoin: The Decentralised Network Token. 2015.

32. Chunming Rong Beyond lightning: A survey on security challenges in cloud computing // Department of Electrical Engineering and Computer Science, University of Stavange. 2012.

33. Nir Kshetri Privacy and security issues in cloud computing: The role of institutions and institutional evolution // Bryan School of Business and Economics, The University of North Carolina. 2012.

34. Quick D and Choo K-K R. Google Drive: Forensic Analysis of Cloud Storage Data Remnants // Journal of Network and Computer Applications. 2013.

35. Jay J.Wylie, Michael W., Bigrigg, John D. Strunk Survivable Information Storage Systems // Computer. 2000. Volume 33, Issue 8, p. 61-68

36. Свон М. Блокчейн. Схема новой экономики. - М.: Издательство Олимп-Бизнес, 2017. - 240 с.

Course syllabus and readings [Электронный ресурс] // Bitcoin and Cryptocurrencies. 2016. - URL: https://crypto.stanford.edu/cs251/syllabus.html (Дата обращения: 16.05.2017).

37. Michael Crosby BlockChain Technology // Sutardja Center for Entrepreneurship & Technology Technical Report. 2015

38. William Mougayar The Blockchain is the New Database, Get Ready to Rewrite Everything [Электронный ресурс] // Brave New Coin. 2015. (Дата обращения: 16.05.2017).

39. Matt Asay Why your next storage solution may depend on blockchain [Электронный ресурс] // TechRepublic. 2016. (Дата обращения: 16.05.2017).

40. Bryan Betts Blockchain and the promise of cooperative cloud storage [Электронный ресурс] // ComputerWeekly. 2016. (Дата обращения: 16.05.2017).

41. Haifeng Yu, Michael Kaminsky, Phillip B., Gibbons Abraham Flaxman SybilGuard: Defending Against Sybil Attacks via Social Networks // Special Interest Group on Data Communication (SIGCOMM). 2006.

42. David Vorick Sia: Simple Decentralized Storage // Whitepaper. 2014

Размещено на Аllbеst.ru