Напомним про основную задачу:

Изучить, как хранить данные IoT на комбинации on-chain (Ethereum Blockchain) и off-chain хранилищ (IPFS и Ethereum Swarm) в зашифрованном виде и использовать их в модели публикации-подписки в режиме реального времени без использования каких-либо протоколов M2M, таких как MQTT или CoAP. Оценить производительность этой системы с точки зрения количества транзакций, которые могут быть выполнены в секунду и оптимизировать ее работу.

В предыдущей части:
Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1

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

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

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

Краткое содержание данной части статьи:

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

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

В следующей статье:

В главе 6 мы проводим эксперименты по хранению данных с использованием традиционных баз данных, а также предложенной системы с использованием Ethereum Blockchain, IPFS и Swarm. Чтобы понять стоимость безопасности IoT, мы проводим эксперименты по оценке производительности предложенной системы.

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

---

Глава 4. Технология IoT  

4.1 Системы и протоколы IoT

Традиционно устройства "Информации о вещах" соединяются друг с другом по сети с помощью ряда клиент-серверных протоколов обмена сообщениями, также называемых протоколами "машина-машина" (M2M). CoAP (Constrained Application Protocol), MQTT (Message Queuing Telemetry Transport) и HTTP являются наиболее используемыми среди множества доступных протоколов M2M.

4.1.1 Протоколы M2M

 IoT-устройства используют протоколы M2M для связи с другими устройствами, часто с другими устройствами, которые подключаются к реальным базам данных, веб-интерфейсам API или дисплеям. Для этого требуется сервер, на котором работает брокер сообщений, и несколько клиентов, которые подключаются и получают данные от сервера и других клиентов по выделенным каналам. Это могут быть модели запрос-ответ (HTTP, CoAP) или публикация-подписка (MQTT, AMQP).

Однако сообщения могут также передаваться между устройствами с помощью смарт-контрактов, отправляющих сообщения с использованием блокчейна Ethereum. Централизованный сервер больше не требуется, если мы используем Ethereum вместо того, чтобы полагаться на M2M.

4.2 IoT-устройства

Одноплатные компьютеры с низким энергопотреблением используются для вычислительных операций Edge, таких как вывод данных на ЖК-дисплеи и сбор данных с датчиков. Популярные устройства включают Raspberry Pi, Arduino, а также многие другие устройства от известных производителей, таких как Intel и Nvidia.

4.2.1 Raspberry Pi 3

Raspberry Pi (используемая версия - 3B) — это дешевый,
размером с кредитную карту компьютер общего назначения с четырехъядерным
процессором ARM Cortex A53 с частотой 1,2 ГГц и 1 ГБ оперативной памяти. На нем
могут работать многие ОС на базе linux, такие как Raspbian (ОС Linux по
умолчанию от Adafruit, производителя Raspberry Pi) и сторонние ОС, такие как
Ubuntu Snappy Core, Windows IOT Core и RISC OS. Устройство также предоставляет
набор заголовков ввода-вывода общего назначения, которые могут быть
использованы для подключения нескольких датчиков и устройств отображения, что
делает его подходящим кандидатом для использования в нашей статье. Устройство
не имеет BIOS (Basic Input/Output System) и может быть загружено с
флэш-накопителя USB или внешнего жесткого диска. Однако стандартным способом
установки ОС и загрузки системы является карта micro SD.

4.2.2 Rasbpian

В качестве ОС на базе Linux-ядра для Raspberry Pi используется Raspbian Stretch Lite. Это позволяет нам запускать все - от языков программирования общего назначения, таких как Python и C, до двоичных файлов для запуска блокчейна и другого программного обеспечения для хранения данных, а также пользовательского кода. Для Raspbian также доступна полная, настольная версия (Raspbian Stretch). На рисунке 4.1 показан Raspberry Pi 3 (модель B), подключенный к источнику питания.

4.2.3 Вводы/выводы общего назначения

Модель raspberry pi 3B+ имеет 40 выводов ввода/вывода общего назначения (GPIO), используемых для различных целей, таких как чтение данных, обеспечение напряжения 3v3 или 5V или разрешение последовательных протоколов, таких как I2C.

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

1. GPIO заголовки для отправки или получения данных

2. Заземление

3. Штырьки 3v3 или 5V для питания.

На рисунке 4.2 показаны различные типы контактов, имеющихся в raspberry pi и необходимых для различных целей.

4.2.4 Цифровой датчик влажности и температуры

Такие датчики, как цифровой датчик влажности и температуры (DHT11), используются для сбора телеметрических данных, в данном случае показаний температуры и влажности, которые считываются скриптами python, запущенными на raspberry pi, с помощью сигналов, полученных с выводов GPIO, предусмотренных на устройстве.

4.2.5 СВЕТОДИОД RGB

Светодиод RGB может светиться индивидуально красным, синим или зеленым цветом или группами, обеспечивая различные цвета. Он может быть запрограммирован модулями GPIO на языке C/ Python и доступен как часть ОС Raspbian. Подача питания на заголовок GPIO, который подключен к соответствующему по цвету контакту светодиода, приводит к отображению этого цвета.

4.2.6 I2C LCD

I2C - это последовательный протокол, с помощью которого маломощные устройства, такие как ЖК-дисплей, могут взаимодействовать с главным устройством (raspberry pi) через контакты ввода/вывода общего назначения. ЖК-дисплей с матрицей 16x2 и подключенным I2C используется для отображения последних данных, сохраненных в блокчейне, и используется в демонстрационных целях.

4.2.7 Аппаратный модуль безопасности

Крошечные устройства Edge, такие как Raspberry Pi 3, практически не обеспечивают безопасности. Основным механизмом хранения данных является карта micro SD, которую можно легко извлечь, а данные, включая ключи шифрования, могут быть легко украдены, так как данные хранятся в открытом виде. Также отсутствует хранилище для конфиденциальных данных, таких как секретные ключи для облачных API или ключи шифрования, используемые для аутентификации. Дополнительные аппаратные модули безопасности, также называемые модулями доверенной платформы (TPM), могут быть использованы для преодоления некоторых из вышеуказанных проблем безопасности. В данной статье использовался Zymkey 4i, который является дополнительным модулем для Raspberry Pi.

4.3 Безопасность IoT

Ожидается, что в ближайшие годы устройства IoT будут оказывать огромное экономическое воздействие, а их количество будет расти в геометрической прогрессии. Это создает огромный стимул для хакеров пытаться похитить конфиденциальную информацию для продажи или других злонамеренных целей. Устройства, подключенные к Интернету, уязвимы для серьезных проблем, если они недостаточно защищены. Другой проблемой, с которой сталкиваются эти устройства, является их слабые возможности обработки и памяти. Мы используем комбинацию криптографии с открытым ключом, симметричного шифрования и хэширования для безопасной передачи ключей между устройствами, а также для шифрования и подписи телеметрических данных.

4.3.1 TPM  

Trusted Platform Module (также называемый TPM или ISO/IEC 11889) - это международный стандарт для защищенного микроконтроллера, который защищает оборудование с помощью встроенных криптографических ключей. Этот стандарт был впервые разработан Trusted Computing Group (TCG), а затем стандартизирован Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC) в 2009 году. Текущая версия стандарта - TPM 2.0.

Для использования в raspberry pi рассматривались два TPM: Optiga TPM от Infineon и Zymkey 4i от Zymbit security. В конечном итоге для использования с raspberry pi был выбран Zymkey 4i, поскольку он имеет гораздо лучшую поддержку для настройки, шифрования и установки LUKS. 4i - это текущая версия TPM, в то время как 3i и 2i - более старые версии продукта.  

Zymbit 4i используется в качестве TPM для raspberry pi и показан на рис. 4.6. Он занимает первые 10 выводов GPIO, включая один вывод 3v3, 2 вывода 5V, 2 вывода Ground, GP104 и шину I2C. Перед его установкой на Raspberry Pi сначала активируется опция сопряжения I2C. Наконец, устанавливаются необходимые программные модули, необходимые для доступа к аппаратным ключам, хранящимся на устройстве TPM. После завершения установки корневая файловая система шифруется с помощью LUKS и dm-crypt с использованием закрытого аппаратного ключа, хранящегося на TPM. 

Ключи блокировщика данных

Zymkey 4i, предоставляет пару открытых и закрытых ключей ECDSA для генерации и проверки подписи, а также два ключа - односторонний и общий. Односторонний ключ используется для блокировки конфиденциальных файлов, таких как секретные ключи к машине, в то время как общий ключ используется для шифрования данных, сохраненных в облачных сервисах, таких как Azure и Amazon Web Services (AWS).

Настройка объединенного ключа Linux

 Носитель информации (в данном случае SD-карта) полностью зашифрован с помощью LUKS (Linux Unified Key Setup) и dm-crypt. Реализация dm-crypt использует один мастер-ключ для шифрования/дешифрования содержимого файловой системы, разделяемого несколькими пользователями или сервисами. Более того, этот единственный мастер-ключ необходимо часто менять, чтобы избежать взлома. Это не всегда возможно, поэтому в альтернативе LUKS используется иерархическая система управления ключами, которая упрощает управление ключами для каждой службы/пользователя, предоставляя им доступ к службам и отзывая их при необходимости. Однако все ключи шифруются с помощью единого мастер-ключа, который должен храниться в памяти устройства. Поскольку SD-карту можно легко извлечь и получить доступ к ней, главный ключ подвергается риску кражи. Аппаратный модуль безопасности/ TPM решает эту проблему, блокируя главный ключ LUKS с помощью ключа шифрования, хранящегося в аппаратном обеспечении.

Глава 5. Предлагаемая система

5.1 Архитектура системы

Предлагаемая система, описанная в разделе 5.1, состоит из ряда приложений, работающих на локальной машине (майнерские узлы), единственной целью которых является подтверждение транзакций, вызываемых заданными методами в смарт-контракте. Для сбора показаний будет использоваться один из raspberry pi под названием IoT Producer. IoT Producer запускает geth в легком режиме, swarm и ipfs для отправки данных в остальную сеть. Другой raspberry pi, называемый IoT Consumer, используется для получения данных из сети и отправки их другим сервисам, API или ЖК-дисплеям. Взаимодействие между узлами geth, ipfs и swarm происходит децентрализованно и распределенно.

Рисунок 5.1 поясняет различные компоненты, используемые для построения предлагаемой системы

5.1.1 Локальная машина

Тестовая машина для проверки операций майнинга представляет собой ноутбук с процессором Core i7-7700HQ с частотой 2,8 ГГц с 4 физическими ядрами и 16 ГБ оперативной памяти. На этой машине работают два майнерских узла geth (для резервирования). Один из узлов майнера выделяет определенный процент (25%) своих ресурсов для обслуживания запросов от легких узлов geth.

5.1.2 Edge узлы IoT

Установлены два одинаковых Raspberry Pi, каждый из которых служит для разных целей. Один из raspberry pi используется для считывания данных с датчиков, а другой - для вывода данных с датчиков на устройство отображения или на внешний API.

Используемая модель raspberry pi - Pi 3 Model B с четырехъядерным процессором ARM Cortex A53 с частотой 1,2 ГГц и 1 ГБ оперативной памяти DDR2. В качестве носителя информации используется SD-карта 32 ГБ класса 10, зашифрованная с помощью LUKS и dm-crypt. На устройствах установлена операционная система Raspbian Stretch Lite.

IoT Producer

IoT Producer используется для считывания данных со всех датчиков, шифрования и хранения данных в предлагаемой сети. Узел Geth, работающий на этой машине, является легким узлом, который зависит от внешнего майнингового узла для получения полной информации о блоках в цепи. Ethereum используется только для хранения ссылок на данные, собранные системой. Он настроен так, чтобы иметь возможность подключаться к экземплярам swarm или IPFS, или даже запускать свои собственные экземпляры для хранения фактических данных в зашифрованном виде.

Для тестирования и демонстрационных целей цифровой датчик влажности и температуры (DHT11) подключен к raspberry pi к контакту GPIO22 для данных, 3v3 для напряжения и контакту заземления.

Потребитель IoT (Consumer)

IoT Consumer используется для демонстрационных целей в данной статье. Как и IoT Producer, он подключается к внешнему swarm или ipfs или запускает свои собственные экземпляры вместе с легкой версией geth. Он извлекает необходимую ссылку из блокчейна Ethereum и запрашивает содержимое ссылки из swarm или IPFS.

Два IoT-устройства подключены к IoT Consumer для тестирования и демонстрации. Одно из них трехцветный светодиод, который подключен к контактам GPIO4, GPIO3 и GPIO2 потребителя, а также к контакту "земля". контакт. Второе устройство - I2C LCD, которое подключено к контактам SDA1 и SCL1 шины I2C, 3v3 для питания и штырь заземления. 

5.2 Алгоритм безопасности

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

 5.2.1 Используемые алгоритмы криптографии

Криптография с открытым ключом

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

Рон Ривест, Ади Шамир и Леонард Адлеман разработали алгоритм RSA, который использует пару открытого и закрытого ключей для шифрования и расшифровки данных. Он также может использоваться для проверки подписей. Открытый ключ получателя используется для шифрования данных на машине, которая генерирует данные, которые затем могут быть использованы получателем для расшифровки данных с помощью его закрытого ключа. Из-за ограничений на размер полезного сообщения он обычно используется для передачи симметричных ключей шифрования.

Пары открытого и закрытого ключей длиной 2048 бит генерируются всеми Raspberry Pis в сети, и открытые ключи отправляются на хост-машину.

Уравнение 5.1 описывает шифрование симметричного ключа с использованием открытого ключа Raspberry Pi.

Уравнение 5.2 описывает передачу зашифрованного симметричного ключа от хоста к pi.

Уравнение 5.3 описывает расшифровку симметричного ключа с помощью закрытого ключа raspberry pi.

В данной работе мы шифруем полученный симметричный ключ с помощью AES-ключа TPM и расшифровываем его только тогда, когда это необходимо. только в случае необходимости. Это описано в уравнении 5.4.

Симметричное шифрование

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

Advanced Encryption Standard (AES) использует сильный секретный ключ для шифрования фактических данных. Мы используем этот алгоритм для шифрования и хранения данных в Swarm или IPFS. Поскольку предлагаемая система требует совместного использования одного и того же ключа многими устройствами, в данной статье было рассмотрено использование криптографии с открытым ключом.  

Хост-машина генерирует 256-битный ключ AES и отправляет его всем машинам raspberry pi, подключенным к сети.

Малинки шифруют и хранят эти секретные ключи в своих файловых системах и используют их для отправки полезной нагрузки в зашифрованном виде в системы хранения данных.

IoTProducers шифруют и отправляют данные, как показано на рисунке 5.5

IoTConsumers расшифровывают и используют данные, как показано в 5.6

Хеширование

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

Хеширование — это процесс генерации набора символов, которые могут однозначно идентифицировать определенный вход. В криптографии они используются в основном для генерации подписи под большим вводом и шифрования с помощью закрытого ключа отправителя, который может быть расшифрован только с помощью открытого ключа отправителя, что гарантирует подлинность отправителя. Алгоритмы безопасного хэширования (серия SHA), дайджест сообщений (серия MD, например MD5) и код аутентификации хэш-сообщений (HMAC) являются одними из популярных алгоритмов хэширования.  

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

Уравнение 5.7 описывает процесс генерации подписи с использованием общего секретного ключа, шифра и вектора инициализации, сгенерированного в процессе шифрования AES и алгоритма SHA256.

Уравнение 5.8 описывает процесс проверки путем сравнения сохраненной подписи и сгенерированного MAC-кода на принимающей стороне.

5.2.2 Частная PKI

Инфраструктура открытых ключей (PKI) — это формальная структура, которая представляет собой политику и процедуры, необходимые для управления и распространения цифровых сертификатов и помощи в шифровании с использованием открытых ключей. Ее основная цель - обеспечить безопасную передачу электронной информации. PKI состоит из центра сертификации, центра регистрации и центрального каталога.

PKI используется для аутентификации пользователей услуг и предотвращения атак типа "человек посередине" в сетях. PKI предполагает использование внешней третьей стороны, которой доверяют во всем мире, для подписания цифровых сертификатов в формате X.509. SSL/ TLS используют этот формат для цифровых сертификатов, который, в свою очередь, является основой для стандарта HTTPS.

Частные PKI обычно используются для защиты коммуникаций между локальными устройствами. В нашей статье есть пример использования, когда мы должны подключиться к узлу IoT Consumer, который запускает endpoints geth и swarm. Внешние API или другие устройства, такие как другой Raspberry Pi, к которому подключено ЖК-устройство (называемое узлом LCD), используемое для отображения текущих показаний температуры и влажности. Для предотвращения несанкционированного доступа и шифрования данных между узлом 39 IoT Consumer и узлом Display мы создали частную PKI для подписания цифровых сертификатов и маршрутизации всех соединений через обратный прокси-сервер. Настройка PKI, используемая в данной статье, показана на рисунке 5.2.

1. Сгенерируйте ключ для закрытого корневого ЦС (центр сертификации) и надежно храните его.

2. Сгенерируйте цифровой сертификат для нашего корневого ЦС и самоподпишите его собственным ключом.

3. На узле IoT Consumer сгенерируйте ключ устройства или используйте ключ TPM.

4. Сгенерируйте запрос на подписание сертификата (CSR) для устройства.

5. Отправьте CSR (Certificate Signing Request) в корневой центр сертификации для подписания.

6. Корневой ЦС подписывает и возвращает цифровой сертификат, используя свой личный ключ.

7. Ключ устройства и сертификат используются для настройки обратного прокси-сервера Nginx для защиты конечных точек geth, swarm и ipfs.

Обратный прокси

Обратный прокси — это промежуточный сервер, который перехватывает все или большинство запросов в зависимости от их использования. Эти перехваченные запросы затем направляются на нужный внутренний сервер. В нашем случае мы запускаем обратный прокси на IoT Consumer, который использует сертификаты, подписанные нашей частной PKI, и позволяет HTTPS-коммуникацию между нашим узлом LCD и IoT Consumer. Таким образом, узел LCD может подключаться к конечным точкам geth, swarm и ipfs и безопасно получать данные. Nginx является популярным вариантом сервера и может быть настроен для использования в качестве обратного прокси.

5.2.3 Аппаратная безопасность с помощью TPM

TPM используется для усиления относительно слабой защиты базового Raspberry Pi. Он обеспечивает аппаратный уровень корня доверия в системе, используя уникальный элемент системы, который не может быть воспроизведен кем-либо, кто пытается это сделать. Обычно он используется для защиты секретных ключей, хранящихся в устройстве, а также для полного шифрования файловой системы и расшифровки только при подключении устройства к системе. Zymkey 4i (TPM) взаимодействует с raspberry pi через интерфейс I2C.

TPM обычно обеспечивает следующие функции.

1. Генератор случайных чисел

2. Генерация или блокировка/разблокировка криптографических ключей

3. Полное шифрование диска

Первым шагом в настройке TPM является его сопряжение с Raspberry Pi. Этот процесс сопряжения использует несколько уникальных функций хоста raspberry pi и TPM и генерирует уникальный идентификатор устройства, который связывает TPM с хостом. При правильном сопряжении на хосте raspberry pi запускается Linux systemd сервис zkifc. Он используется для обеспечения доступа к ключам, хранящимся на TPM, через интерфейс I2C, а все соединения между TPM и I2C шифруются. После завершения привязки, установки всех приложений и готовности к развертыванию, TPM можно перевести в режим постоянной привязки, который фиксирует TPM на raspberry pi и не может быть привязан к другим raspberry pi в будущем. Это навсегда отключает raspberry pi в случае несанкционированного вмешательства или удаления TPM.

На рисунке 5.3 показаны различные функции, предлагаемые типичным TPM.

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

5.2.4 Шифрование корневого файла с помощью LUKS

Корневая файловая система в Raspberry Pi не очень безопасна. SD-карта может быть легко отсканирована, а конфиденциальные данные, такие как общие ключи, могут быть легко украдены. Эффективным решением является шифрование всей корневой файловой системы с помощью Linux Unified Key Setup и dm-crypt.

На рисунке 5.4 показано, как легко можно считать SD-карту и украсть конфиденциальные данные.

Последовательность загрузки обычного LUKS  

1. Ядро инициализирует initramfs - одиночный архив, загружаемый в основную память во время запуска.

2. initramfs представляет ключ расшифровки LUKS

3. LUKS расшифровывает корневую файловую систему.

Есть несколько проблем с вышеописанной процедурой, когда речь идет о Raspberry Pi. Во-первых, здесь нет специального кольца для хранения криптографических ключей, доступного в других операционных системах. Во-вторых, конфиденциальные ключи не должны храниться открытым текстом на съемной SD-карте. Чтобы решить эти проблемы, используется TPM с LUKS для более безопасной последовательности загрузки. На рисунке 5.5 показана зашифрованная файловая система.

Последовательность загрузки LUKS с TPM

1. Ядро инициализирует initramfs

2. initramfs передает заблокированный ключ LUKS на TPM

3. TPM проверяет подпись ключа и расшифровывает ключ LUKS.

4. Разблокированный ключ LUKS используется для расшифровки корневой файловой системы.

На рисунке 5.6 показано, как корневая файловая система
разбивается на зашифрованные блоки и как мастер-ключи и ключи пользователей
защищаются TPM.

Хранилище данных для ключей

Эта функция позволяет хранить все общие секретные ключи в зашифрованном виде. Секретные ключи, передаваемые на raspberry pi (процесс описан в разделе 5.2.5), шифруются с помощью ключа AES, жестко закодированного в аппаратном обеспечении TPM. Zymkey 4i предоставляет модуль python под названием zymkey, который получает доступ к AES-ключу TPM, шифрует или расшифровывает секретный ключ и блокирует его на raspberry pi. Заблокированный ключ затем используется для передачи зашифрованных данных по сети.

AES-ключ TPM используется для шифрования и расшифровки фактического секретного ключа AES и объясняется в уравнении 5.9 и уравнении 5.10.

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

5.2.5 Программная безопасность

Для защиты raspberry pi можно использовать несколько простых методов, каждый из которых оказывает одинаково значительное влияние на повышение общей безопасности устройства.

Изменение пароля по умолчанию

Пароль по умолчанию на raspberry pi - raspberry. Согласно исследованию, IoT-устройства легко взламываются из-за неправильной настройки, при которой часто оставляют учетные данные по умолчанию. Первоочередной задачей после настройки raspberry pi должно быть изменение пароля по умолчанию на более надежный.

Замена пользователя по умолчанию

Для дальнейшего повышения безопасности добавляется новый пользователь и удаляется пользователь по умолчанию pi. Еще одна возможность, которую следует рассмотреть, - запрашивать пароль при выполнении команды sudo в терминале, которая в raspbian по умолчанию отключена.

Установка брандмауэра

По умолчанию на raspberry pi не установлен брандмауэр. Uncomplicated Firewall (ufw) может быть установлен очень легко в любой ОС на базе Linux, и ОС raspbian не отличается от нее. Все порты, кроме тех, которые нам необходимы, например, для выполнения удаленных вызовов процедур, сетевого взаимодействия между узлами geth, swarm или ipfs, выборочно включены.

Передача симметричных ключей

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

1. Сгенерируйте пару открытых и закрытых ключей RSA на Raspberry Pi.

2. Передайте открытый ключ на хост-машину, генерирующую симметричный ключ, используя защищенный канал, например Secure Copy (SCP) или Secure File Transfer Protocol (sftp).

3. Сгенерируйте хэш подписи для ключа

4. Зашифруйте симметричный ключ с помощью открытого ключа raspberry pi.

5. Передайте зашифрованный симметричный ключ обратно на raspberry pi.

6. Расшифруйте симметричный ключ с помощью закрытого ключа raspberry pi.

7. Проверьте подпись, сохраненную в расшифрованном тексте.

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

Отключите RPC на geth и swarm, если они не требуются.

Удаленные вызовы процедур используются удаленными клиентами для подключения к узлам geth/swarm и получения или отправки на них информации. Однако наше приложение для хранения данных работает на том же узле, что и IoT Producer, и нам не нужен внешний клиентский доступ для подключения к IoT Producer. Вместо этого Geth и Swarm должны использовать конечную точку IPC, которая в целях безопасности обеспечивает вызовы только с локального хоста.

5.3 Проектирование программного обеспечения

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

5.3.1 Последовательность шагов

Шаги по сбору и получению данных датчика после
применения шифрования, проверки или расшифровки описаны в следующих разделах.
Рисунок 5.7 описывает эти шаги на самом базовом уровне.

5.3.2 Сбор данных с датчика

Алгоритм 1 объясняет общие шаги, выполняемые на
стороне производителя для сбора данных с датчика, подписания и шифрования
сгенерированной полезной нагрузки. Затем данные сохраняются в IPFS или Swarm, а
полученный хэш файла хранится в Ethereum.

5.3.3 Получение сенсорных данных

Алгоритм 2 объясняет шаги, выполняемые на стороне потребителя для получения файлов-хэшей из Ethereum, получения зашифрованной полезной нагрузки из Swarm или IPFS и, наконец, расшифровки и проверки этой полезной нагрузки.  

5.3.4 Логические функции смарт-контракта

В этом разделе подробно описана логика, используемая в смарт-контракте для определения контроля доступа, хранения и извлечения файлов-хэшей для полезной нагрузки, загруженной в IPFS или Swarm.

Структура для хранения собранных данных

Хотя только хэш файла является частью struct, он был
оставлен для будущих улучшений, если это потребуется.

В очень ранней версии смарт-контракта использовался приведенный ниже тип данных struct.

указатель на данные

Целочисленное значение, ID используется в качестве указателя для ссылки на наши текущие показания, хранящиеся/извлекаемые смарт-контрактом.

Маппинг от указателя к структуре и зарегистрированным адресам

Маппинг определяется как sensorStore от ID к SensorData struct. Другое отображение хранит зарегистрированные адреса IoT-устройств, которым разрешено записывать или считывать данные в систему

Конструктор для инициализации идентификатора

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

Модификатор, позволяющий только владельцу смарт-контракта регистрировать и снимать с регистрации идентификаторы

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

События для регистрации регистрации и изменения состояния

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

Функция для получения текущего идентификатора

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

Функция для увеличения текущего идентификатора

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

Функция для установки файлового хэша SensorData

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

Функция для получения последнего файлового хэша SensorData

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

Функция для получения хэша файла SensorData по любому идентификатору

Этот метод работает аналогично описанному выше, но извлекает значение, связанное с ID, переданным в функцию

Методы регистрации и снятия с регистрации устройств IoT

Следующие методы объясняют, как проверить, зарегистрировано ли устройство, и вызвать методы register или deregister для любого устройства; доступ к ним может получить только владелец контракта. Метод "devicePresent" возвращает, зарегистрировано ли устройство в системе. Методы "registerDevice" и "deregisterDevice" используются для регистрации и отмены регистрации IoT-устройства с помощью смарт-контракта соответственно.

Предоставленные конечные точки HTTP используются в IPFS и Swarm для хранения и получения полезной нагрузки. Модуль requests в python используется для отправки POST и GET запросов от систем хранения. Хранение данных сводится к простому POST-запросу, как объясняется в алгоритме 3. Запрос GET извлекает полезную нагрузку из системы, используя хэш файла в качестве входных данных, что объясняется в алгоритме 4.

5.3.6 Формат полезной нагрузки

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

5.4 Реализация

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

5.4.1 Настройка среды

Python 3 используется для написания скриптов, взаимодействующих с IoT-устройствами, блокчейном Ethereum, IPFS и Swarm. Его менеджер пакетов pip3 установлен на всех используемых нами устройствах. Среда, используемая в наших тестовых устройствах, приведена в таблице 5.2. Truffle (приложение Node.js) используется для создания, компиляции и развертывания смарт-контрактов на основе Solidity.

5.4.2 Двоичные файлы программного обеспечения

Для локальной машины (amd64), а также для узлов IoT (arm) загружаются предварительно собранные двоичные файлы Geth. Чтобы обеспечить единообразие, на всех устройствах используются одинаковые версии. Пакеты Ethereum-Swarm легко доступны для Ubuntu, но не для Raspberry Pi 3.

Raspberry pi 3B не имеет аппаратного обеспечения для сборки этих двоичных файлов из исходного кода Golang. К счастью, язык программирования Go предоставляет отличные инструменты для кросс-компиляции. Локальная машина используется для сборки двоичных файлов роя, которые были установлены на raspberry pis.

В таблице 5.3 представлена информация о различных
версиях geth, swarm и IPFS, использованных в данной статье.

5.4.3 Модули Python

Поскольку в работе широко используется python 3, несколько сторонних модулей python используются для доступа к блокчейну, записи данных в ipfs или шифрования и расшифровки данных. В таблице 5.4 описаны все модули python, используемые в данной статье.

5.4.4 Методы оценки

После настройки сети производительность системы будет проверена с точки зрения количества транзакций в секунду (TPS), стоимости одной транзакции, использования процессора и памяти. Для тестирования TPS генерируется набор данных из 5000 записей, отформатированных в формате данных Payload, описанном в п. 5.3.6.

Три категории тестов проводятся как с Ethereum, так и с Swarm/ IPFS.

1. Данные сохраняются в Swarm/ IPFS и измеряется время записи. Хеши файлов хранятся в текстовом файле и используются при тестировании производительности чтения.

2. Данные хранятся в Swarm/ IPFS, а полученный хэш файла сохраняется в Ethereum с помощью функции смарт-контракта. Измеряется время чтения и записи.

3. Данные хранятся в Swarm/IPFS в зашифрованном виде. Полученный хэш файла сохраняется и извлекается при необходимости. Алгоритм шифрования, используемый во всех тестах, - AES-CBC с PKCS padding. Используемый ключ имеет размер 256 бит.

Настройка

Необходимо создать частную сеть, состоящую как минимум из 3 узлов - "полного" майнерского узла с "легкими" узлами IoT-производителя и IoT-потребителя.

Эти шаги описывают процесс создания частной сети Ethereum.

1. Инициализируйте каталог данных, который будет содержать данные цепочки с нашим файлом genesis.json.

2. Создайте новую учетную запись для всех узлов.

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

4. Сохраните информацию об узле (admin.nodeInfo.enode) статического узла на всех узлах с помощью файла staticnodes.json.

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

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

7. Подождите несколько минут после начала майнинга, чтобы майнер заработал немного Ether.

8. Переведите часть добытого эфира на узел администратора.

9. Скомпилируйте смарт-контракт и разверните его с узла администратора.

10. Зарегистрируйте узлы, которые имеют право отправлять и получать данные из сети, используя администратора.

Тестирование

Для тестирования Ethereum основные параметры могут быть измерены как для хэша файла, так и для полезной нагрузки. На основные счета на всех узлах системы передаются по 100 Ethereum для проведения этих экспериментов.

1. Стоимость, понесенная за транзакцию

2. Время, затраченное на транзакцию Метод набора данных

3. Время, затраченное на извлечение одной записи

4. Использование процессора и оперативной памяти

5. Среднее время создания блока

6. Средний хэшрейт сети

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

5.4.5 IPFS и Swarm

Тестирование IPFS и Swarm может быть выполнено с использованием аналогичных методов. Нижеприведенные параметры учитываются при тестировании их индивидуальной производительности в предлагаемой системе.

Настройка частной сети Swarm

Swarm тесно связан с Ethereum и должен использовать тот же сетевой идентификатор, который использовался в Ethereum для создания частной сети.

Для настройки Swarm для нашего использования можно выполнить следующие шаги: 

1. Экспортируйте переменную окружения BZZKEY, содержащую адрес кошелька узла geth, на котором настраивается Swarm.  

2. Создайте доверенный загрузочный узел, к которому могут подключаться другие узлы, называемые peers. Одному из узлов майнера поручено функционировать в качестве загрузочного узла.

3. Запустите узел роя, используя тот же сетевой идентификатор, который использовался для Ethereum, и файл geth.ipc для подключения к пространству имен Ethereum (служба ENS для различения peers). Скрипт запуска должен содержать флаг nodiscover, чтобы предотвратить попытки других пиров подключиться к сети.

4. Проверьте, могут ли другие пиры подключиться с помощью консоли swarm. (admin.peers перечисляет все peers, которые в настоящее время подключены к узлу).

Настройка частной сети IPFS

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

Эти шаги описывают, как настроить частную сеть IPFS.

1. Инициализируйте все узлы с пользовательскими каталогами данных. Этот процесс генерирует 2048-битную пару ключей RSA и идентификатор узла (полезен для подключения к другим узлам).

2. Сгенерируйте ipfs-swarm.key, который будет использоваться для аутентификации и разрешения доступа к сети.  

3. Удалите все существующие загрузочные узлы.

4. Добавьте на узлы в качестве загрузочных узлов только сгенерированные идентификаторы сверстников.

5. Запустите все демоны IPFS и проверьте, могут ли файлы, хранящиеся на одном узле, быть прочитаны с других узлов.

Тестирование

1. Время, затрачиваемое на вставку одной записи полезной нагрузки

2. Время, затрачиваемое на извлечение одной записи полезной нагрузки

3. Использование процессора и оперативной памяти

---

Продолжение следует...

Предыдущая часть статьи: Безопасное хранение данных IoT в частном блокчейне Ethereum. Часть 1