Добавлен сценарий PKI для Робономики

docs/technologies/robonomics.md

@@ -25,7 +25,7 @@ title: 'Сеть Робономики'
 
 ### Индексация блокчейна Робономики на базе SubQuery
 
-Быстрый просмотр транзакций конкретных транзакций datalog/launch/rws/digital_twin. Будет полезно для популяризации парачейна робономики и увеличения скорости отслеживания определённых транзаций. Например, транзакций с запуском определённых роботов - в `identity` которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов.
+Быстрый просмотр транзакций конкретных паллет `datalog`, `launch`, `rws`, `digital twin`. Будет полезно для популяризации Робономики и увеличения скорости отслеживания определённых транзакций. Например, транзакций с запуском определённых роботов - в `identity` которых есть ссылка на заводской серийный номер и версию КД. Данные роботы публикуют отчёты о завершённых операциях, по которым можно запросить обучение своей модели. Производителям будет удобно отслеживать всех выпущенных и подключенных к Робономике роботов.
 
 
 ### Federated learning для роботов-манипуляторов по имеющимся мета-данным
@@ -33,18 +33,42 @@ title: 'Сеть Робономики'
 Порядок федеративного обучения для сети передачи навыков
 
 1. Робот или пользователь публикует в `Datalog` сообщение с initial model hash и другими мета-данными для локального обучения модели
-2. Другие подобные роботы отслеживают такого рода сообщения (подобность можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера)
+2. Другие подобные роботы отслеживают такого рода сообщения (подобие можно определять по identity-записям со ссылкой на версию манипулятора и его драйвера)
 3. Если найдена запись в `Datalog` с предложением инициировать локальное обучение на своих данных, то робот начинает обучение
-3. После завершения обучения в `Datalog` этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла
-4. Робот, запустивший федеративное обучение, отслеживает `Datalog` других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл
+4. После завершения обучения в `Datalog` этого робота публикуется ссылка на патч к инициирующей модели со ссылкой на исходную транзакцию объявления и DID-адрес файла
+5. Робот, запустивший федеративное обучение, отслеживает `Datalog` других подобных роботов, покупает обнаруженные патчи к модели, усредняет их и запускает повторный цикл
 
 ### Проверка соответствия робота спецификации производителя
 
-Для корректного обмена навыками между роботами необходимо обеспечить механизм подтверждения, что программно-аппаратное обеспечение роботов соответствует друг другу и передача данных между ними имеет смысл. В этом фреймворке предлагается способ проверки соответствия с помощью подтверждения производителем робота. Производитель оборудования является наиболее осведомлённой стороной в вопросах спецификации выпускаемого робота. В рассматриваемом сценарии производитель робота предоставляет покупателю робота возможность самостоятельно создать identity запись под своим аккаунтом.
-1. Для этого производитель прикладывает к каждому выпускаемому роботу уникальный ключ, известный только производителю и покупателю. При производстве роботов производитель создаёт пулл NFT и при передаче прав на роботов передаёт этот NFT покупателю. По владельцам данного NFT можно индексировать блокчейн.
-2. Покупатель вводит данный ключ и свой публичный ключ акканута в блокчейн на сайте производителя и получает на свой адрес токены для интеграции робота в сеть блокчейн
-3. Пользователь робота, если хочет участвовать в сети обмена данными, создаёт identity запись (`setIdentity`) с указанием конкретной модели робота и версии драйвера и направляет запрос на подтверждение (`requestJudgement`)
+Для корректного обмена навыками между роботами необходимо обеспечить механизм подтверждения, что программно-аппаратное обеспечение роботов соответствует друг другу и передача данных между ними имеет смысл. Далее представлен способ проверки соответствия с помощью подтверждения производителем робота. Производитель оборудования является наиболее осведомлённой стороной в вопросах спецификации выпускаемого робота. В рассматриваемом сценарии производитель робота предоставляет покупателю робота возможность самостоятельно создать identity запись под своим аккаунтом.
+1. Для этого производитель прикладывает к каждому выпускаемому роботу уникальный ключ или `NFT`, известный только производителю и покупателю. При производстве роботов производитель создаёт пул таких ключей и при продаже передаёт их покупателям.
+2. Покупатель вводит данный ключ и свой публичный ключ аккаунта в блокчейн на сайте производителя, после чего получает на свой адрес токены для интеграции робота в сеть блокчейн
+3. Пользователь робота, если хочет участвовать в сети обмена данными, создаёт identity запись (`setIdentity`) с указанием конкретной модели робота, версии драйвера и направляет запрос на подтверждение (`requestJudgement`)
 4. Производитель находит событие JudgementRequested, где указана информация о версии робота и его встроенном программном обеспечении, сопоставляет эту информацию с своим приватным реестром ключей/адресов и подтверждает корректность (`provideJudgement`)
 5. С помощью self-hosted или предоставляемого производителем сервиса индексирования блокчейна (SubQuery в Substrate или TheGraph в Ethereum) владельцы роботов могут видеть опубликованные задания на обучение для таких же роботов и принимать участие в программах улучшения.
 
 Таким образом производитель может легко запускать программы лояльности и улучшения качества обслуживания для тех клиентов, которые предоставляют возможность совершенствовать обучаться с помощью их данных.
+
+### Сеть Робономики как инфраструктура открытых ключей (PKI) для кибер-физических систем
+
+> Восстание машин отменяется - всё будет под контролем!
+
+Дизайн ROS2 предлагает достаточно надёжную модель управления узлами, основанную на классической PKI, где все узлы могут безопасно обмениваться данными с помощью выпущенных удостоверяющим центром сертификатов. Данная модель безопасности надстраивается над имеющимися в операционной системе правами доступа, а значит и наследует их риски:
+- root является самым привилегированным пользователем, от которого зависят все остальные пользователи системы, поэтому большинство векторов атаки на информационные системы строятся на том, чтобы заполучить root-доступ и соответствующие ему привилегии
+- любое изменения настроек прав доступа пользователей требует root
+- нельзя контролировать какие конкретно изменения сделает пользователь.
+
+Блокчейн предлагает новое решение. Теперь узлы *кибер-физических систем* (CPS) могут взаимодействовать друг с другом без доверенных центров. Предлагается модель управления доступом к автономным CPS через блокчейн Робономики. 
+
+Такая схема работы даёт следующие возможности:
+- не нужно полагаться на системных администраторов, обладающих привилегированным доступом к файловой системе на самом низком уровне
+- верифицированное сообществом разработчиков или аудиторов безопасности обновление firmware с помощью хеша или контрольной суммы, указанной в транзакции
+- возможность управления CPS с помощью мультиподписей, голосований DAO, рынков или сетей оракулов с согласованием множества заинтересованных лиц
+- устойчивость к компрометации отдельных пользователей
+- взаимодействие автономных CPS без постоянного подключения к сети Робономики с помощью генерации сертификатов `под задачу`, то есть индивидуально для каждого акта взаимодействия с соответствующими ограничениями доступа и сроком действия.
+
+#### Сценарий использования
+
+В момент прошивки или ввода в эксплуатацию CPS в аппаратно защищённую от записи ПЗУ оборудования записываются спецификации сети для запуска узла Робономики и идентификационные данные CPS (например, идентификатор `NFT` как право собственности на робота, чтобы иметь возможность передать это право другим пользователям, не меняя конфигурацию самого робота). Далее отключаются или минимизируются возможности взаимодействия по сети, кроме блокчейн: SSH, последовательный порт и все другие интерфейсы, включая графический. CPS приватно создаёт аккаунт, публикует открытый ключ (либо передаёт его корневому узлу для внесения в конфигурацию `Digital twin`), подключается к сети и начинает отслеживать команды от владельца или контрагентов.
+
+Для изменения политик управления доступом, заданных в блокчейне, можно использовать пакет [ROS2 Security](https://github.com/ros2/sros2), добавив в него возможность применять криптографические механизмы Substrate. ROS2 Security позволяет создавать [хранилище ключей](http://docs.ros.org/en/rolling/Tutorials/Security/The-Keystore.html), привязывать ключи к узлам ROS2 и задавать соответствующие политики доступа к топикам, сервисам и действиям. Хранилище представляет из себя директорию с т.н. [enclaves](https://design.ros2.org/articles/ros2_security_enclaves.html) (*анклавы безопасности*) для задания политик управления - процессов или групп процессов с едиными правилами доступа. `enclave` может быть задан для каждого отдельного узла ROS2 в момент его запуска. ROS2 Security можно подключить к узлу Робономики, чтобы создавать необходимые для взаимодействия `enclave`. *Транзакция может служить источником данных для формирования сертификата*. Тело транзакции преобразовывается в `enclave` и используется в DDS для защищённого обмена данными с другими узлами ROS2 или иными агентами. Например, чтобы обеспечить [безопасное взаимодействие агентов](http://docs.ros.org/en/rolling/Tutorials/Security/Security-on-Two.html), не подключённых к сети Робономики на постоянной основе. После получения транзакции агенты создают у себя анклавы с параметрами доступа к внутренней информации и сроком действия. Когда агенты обмениваются данными в пределах срока действия сертификата, то могут использовать аутентификацию DDS без необходимости доверять единому удостоверяющему центру и использовать сертификаты с большим сроком действия.