Resolve and prioritize cybersecurity research problems for distributed observing systems

Statement of Work
Project Title: Blockchain Distributed Ledger for Space Resource Access Control
Future Earth-observing (EO) space systems will provision control over distributed assets to
dynamically compose functional capabilities (sensing, processing, transmission, etc.)
within a federation of systems. For example, commercial firms Planet Labs and Capella
host web-based APIs that allow customers to task and retrieve imagery from their
satellite constellations. However, managing an increasing variety of functional
capabilities among a growing set of providers poses a challenge to control access to
space-based resources with autonomous operating modes. A distributed ledger
(blockchain) may provide a robust and transparent record of resource provision
requests and grants in a distributed system.
The New Observing Strategies Testbed (NOS-T) is a computational platform for
prototyping and maturing new EO technology [1]. It provides a publish-subscribe
interface using the Message Queuing Telemetry Transport (MQTT) protocol to
exchange messages among member applications (nodes) as components of an EO
system. Test case executions use messages to test new EO concepts and operating
modes in a virtual environment.
This project proposes to apply a distributed ledger (blockchain) within the context of a
distributed EO system. The blockchain is represented as one or more nodes that
participate in a test case execution. Other applications representing components of
the federated EO system (e.g., satellite operators, customers, etc.) interact with the
blockchain application to request and grant access to resources.
Blockchain technology enables zero-trust cybersecurity protections for data stored in
immutable ledgers where users (members) can trust that data comes from authentic
instruments. This data stored in ledgers provides significant protection making it much
more difficult for adversaries to gain illicit access. Each participating organization
authenticates users through API functions, establishing different roles that categorize
access through fully automated governance policies that appropriately limit access to
data and services. All organizational users and/or instruments must be invited,
authenticated and characterized by role before joining the network in a permissioned
blockchain.
In order to bring zero-trust identity to space based instruments and application services,
we propose to build a secure instrument registration and a blockchain-based access
control overlay to help manage assets and services (resources) using a consensus
based transaction protocol. We plan to use a hyperledger permissioned blockchain
capability to support user/instrument registration that will enable transaction processing
for users and instruments.
All registered instrument IDs, application and/or user IDs will be recorded in the
immutable ledgers by each participating organization. After instruments are
authenticated, attribute-based access control (ABAC), role-based access control
(RBAC), and connectors will be implemented between instruments and the blockchain
network. The RBAC rule will be used to categorize users into different roles, such as
operators or guests. For example, only governors can update transactions, and guests
can only query transactions or send transactions. ABAC will be used to categorize
instruments or resources into different attributes based on the data types in
accordance with requirements. The target ecosystem will maintain the listed
functionality:
● Maintenance of all data transaction information in blockchain and improved
data quality/provenance through distributed ledgers of audit logs.
● Zero-trust instrument registrations.
● Increased security through fine-grained attribute-based access control. A
designed access control rules for various instruments.
● API functionality for different UI interfaces.
● A gRPC connector between an instrument and blockchain network.
When MQTT protocol exchanges messages among member applications (nodes) as
components of an EO system, its broker can call a function of a smart contract API (by
generating a transaction) to verify registered instruments or users in the blockchain. This
latter records the requested versifications on the blockchain and demonstrates that the
broker has started the authentication request. When an NOS-T manager application
orchestrates test run executions, it should have smart contracts to query the blockchain
ledgers for registered instruments, users, resource access controls.
Assume that over the classic MQTT software, the broker has high-level software called
IoT application, which is in charge of carrying out some operations of the
authentication procedure or checking the resource access controls.