Безопасное управление роботом на расстоянии с помощью Робономики

В прошлой статье мы рассказали о том как используем преимущества промышленных решений в инфраструктуре роботизированного умного дома. Мы показали как фреймворк ROS 2 и его middleware протокол обеспечивают автоматическое обнаружение устройств и интенсивное взаимодействие (в том числе в режиме реального времени) между ними в рамках локальной сети, что очень удобно. Однако, этот подход хорошо подходит в основном для, так называемой, Trusted Zone - той части компьютерной сети, где появление каких-то посторонних акторов является маловероятным. В этом случае мы доверяем всем работающим программам и можем не использовать шифрование подобно тому как оно не используется в рамках одного компьютера. когда программы обмениваются данными между собой.

Но что делать, если требуется обеспечить работу использующих ROS 2 устройств с каким-то внешним сервисом или обеспечить удалённое подключение к ним извне? В такие моменты возникает проблема безопасности - получив доступ к одному узлу ROS 2, сторонний сервис (а потенциально и злоумышленник) по сути получает доступ и ко всем другим узлам - он может полностью прослушивать весь внутренний трафик DDS и обращаться ко всем доступным сервисам системы.

Классический компромисс (trade-off) между безопасностью и скоростью/удобством разрешается разделением системы суверенного умного дома на две части - безопасную и небезопасную.

ROS 2 Security

В пространстве работы узлов ROS 2 выделить зону, к которой предъявляются особые требования безопасности, является довольно нетривиальной задачей. Стандартный пакет ROS 2 Security (sros2) является частью ros-core, на котором собраны все дистрибутивы ROS 2, и по мнению core-разработчиков он призван решить именно эту проблему. Он даёт возможность настроить относительно простую инфраструктуру публичных ключей (PKI) в рамках одной локальной сети. Для каждого узла ROS 2 задаются политики доступа к данным других узлов, а также набор стандартных для такого рода сценариев файлов - криптографических ключей и сертификатов. В ходе исполнения программы узлы “видят” только те источники данных, доступ к которым явно прописан в конфигурации на этапе запуска проекта. Однако, этот подход обладает большим минусом - весь трафик в системе шифруется, что может сказаться на быстродействии при той нагрузке на сеть, которую создаёт DDS. Придётся прописать все политики доступа и сгенерировать ключи для всех узлов. Это очень сложно настраивать и поддерживать.

Мосты

Другое решение заключается в создании так называемых шлюзов, которые передают нужные данные, сохраняя всё остальное приватным. Как правило, это достигается при помощи тоннелей VPN или SSH. В безопасном пространстве обмена данными создаётся отдельный узел, имеющий публичный адрес для подключения извне. В этом случае управление безопасностью осуществляется на уровне только этого узла (по сути являющегося окном во внешний мир), не затрагивая все остальные. Данный подход применён в проектах Husarnet, DDS Router и Zenoh Bridge, но и он не лишён недостатков. В этом случае вам нужно создать защищённый канал связи, который жёстко привязан к IP-адресу или доменному имени контрагента, а они имеют свойство меняться, блокироваться и подвергаться атакам. В те времена, когда создавался SSH, об этом никто не думал. Также SSH в значительной степени опирается на систему управления доступом операционной системы, со всеми присущими ей недостатками.

Вот как пользователи обычно подключаются к своим роботам удаленно. Этот подход имеет некоторые недостатки. Он требует публичного IP или/и DNS имени, которые могут быть заблокированы в некоторых странах. Это также требует хранения приватных ключей в потенциально небезопасных местах (например, на диске в директории ~/.ssh).

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

Web3 Решение

Проблему можно обойти с помощью технологий одноранговых сетей, на которых построен Robonomics. Децентрализованное облако является в этом случае очень защищённой таблицей маршрутизации, адресами контрагентов в которой являются публичные ключи узлов. Вам нужен локальный узел Robonomics и знание о том какой публичный ключ у вашего контрагента, чтобы далее не зависеть от системы DNS (включая регистраторов доменных имён и серверов) и блокировок IP-адресов. Библиотека libp2p, которую использует Robonomics, может использовать разные транспортные протоколы для доставки сообщений.

Также с появлением и распространением технологий Web3 мир узнал о гораздо более дружественных с точки зрения UX способах управления критически важной информацией, к которой безусловно относятся приватные ключи доступа. Одним из таких новшеств является так называемая мнемоническая фраза или seed - последовательность из 12 или 24 слова, широко применяющая для создания аккаунтов в децентрализованных сетях. Дополнительная безопасность этого метода заключаются в том, что seed появляется в момент инициализации и записывается единожды на внешнем носителе (например, на бумаге), после чего применяется только в случае восстановления аккаунта. Из мнемонической фразы формируется мастер-ключ, из которого в свою очередь может быть создана произвольная иерархия ключей для самых разных задач (см. Hierarchical deterministic keys). Это значительно упрощает управление ключами и их восстановление в случае компрометации. Злоумышленник может получить доступ к какой-то одной паре ваших ключей (используемых в текущий момент), но это не даст ему возможности извлечь информацию о других ключах, генерированных из мнемонической фразы. Также с помощью функции soft derived key можно подтвердить владение корневым аккаунтом, не раскрывая его.

Удалённое подключение в Home Assistant

Рассмотрим процесс подключения подробнее. Децентрализованное приложение Robonomics (DApp) работает непосредственно в вашем браузере, оно не требует от Вас установки какого-либо дополнительного программного обеспечения или необходимости хранить ключи в файловой системе в окружении огромного количества программ, в безопасности которых Вы не можете быть уверены. Администрирование ключей доступа осуществляется через расширение Polkadot JS, а также с помощью внешнего аппаратного хранилища ключей (например, Polkadot Vault) для дополнительной надёжности. Помимо специализированного программного обеспечения для взаимодействия с Robonomics, DApp также включает в себя легковесную libp2p-ноду, с помощью которой и происходит подключение к Home Assistant.

Владелец подписки Robonomics Web Service управляет правами доступа к инфраструктуре умного дома через так называемого контроллера - аккаунта, который управляет всей чувствительной информацией в зашифрованном виде в цифровом двойнике. Расшифровать эти данные могут только пользователи добавленные в подписку. Помимо ключей доступа, в Цифровом двойнике хранится также конфигурация DApp и, так называемый, мультиадрес libp2p, к которому DApp подключается для установления безопасного подключения. Мультиадрес - одно из тех нововведений, которое делает подход libp2p столь уникальным и гибким. Это специальный формат адреса для узлов, который предполагает наличие многих IP-адресов, транспортных и сетевых идентификаторов, протоколов и портов, по которым можно связаться с конкретным узлом. Полный перечень поддерживаемых протоколов представлен в спецификации.

Итак, добавленный в подписку пользователь извлекает из цифрового двойника Robonomics мультиадрес и устанавливает защищённое соединение с известным только ему Peer ID.

Удалённое подключение в ROS 2

Таким же образом можно воспользоваться существующими возможностями Robonomics и для подключения к роботам. Для достижения этой цели в рамках Robonomics Grant Program командой Robossembler был разработан Proof of Concept проект Robonomics Bridge . Этот мост позволяет соединить ваши узлы ROS 2 с каким-либо внешним сервисом, удалённым рабочим местом или аналогичной ROS 2 системой.

Иллюстрация того как может выглядеть дистанционное управление домашним роботом в случае с ROS 2. Такой подход даёт ряд существенных преимуществ: нет потребности в публичном IP, доступ к роботу есть даже через сетевые экраны (NAT), приватные криптографические ключи не хранятся на диске и надёжно защищены.

Использующийся в ROS 2 протокол DDS естественным образом сочетается с libp2p благодаря тому, что использует похожую модель издатель-подписчик для взаимодействия узлов. С помощью Robonomics bridge можно декларативно сконфигурировать узлы ROS 2 и их интерфейсы - топики, сервисы, типы сообщений (например, с помощью eProsima Integration Service), через которые можно взаимодействовать с роботом извне. Также это позволяет включить дополнительный уровень безопасности при подключении к удалённому компьютеру. При этом сам механизм получения PeerID контрагента может быть таким же, как и в случае с Home Assistant - через запрос Digital Twin у узла Robonomics, с той лишь разницей, что вместо Home Assistant Server будет ROS 2 робот, а вместо libp2p-websocker-proxy подключённый к роботу Robonomics ROS 2 Wrapper.

Перспективы

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