2.1.

SSA and DDDAS

Space situation awareness (SSA) is considered as an important frontier because of the increased congestion of satellites vital for strategic decisions, communications, and weather/terrestrial observations.¹² Since the number of satellites in orbit continues to grow exponentially, it is required to ensure that all spacecraft on-orbit work as intended to successfully accomplish their missions. The SSA environment generally consists of two major areas: satellite operations and space weather. The satellite operations are focused on the local perspective to enable continuous operations by understanding the space environment and build models to support satellite health monitoring (SHM). SSA is a systems design, which utilizes data collected from ground and other space assets for RSO tracking, imaging, and collision avoidance.^6,13,14 The key components of SSA include RSO tracking and characterization, SHM and communication, information management, sensing, navigation, and data visualization.^6,15 To address SATCOM challenge that requires cognitive spectrum management and agile waveform adaptation solutions, a game theory-enabled high-level anti-interference strategy was proposed to solve interference in congested space environment.¹⁶ To support space defense analysis and mission trade-off investigations, a satellite orbital testbed for space sensor resource allocation is developed and evaluated for pursuit-evasion game theoretic sensor management.¹²

DDDAS is a conceptual framework that synergistically combines models and data in order to facilitate the analysis and prediction of physical phenomena.^6,9 In an SSA application, DDDAS is a variation of adaptive state estimation that uses computational feedback rather than physical feedback to enhance the information content of measurements. The feedback loops in DDDAS include a data assimilation loop and a sensor reconfiguration loop. The data assimilation loop calculates the physical system simulation using sensor data error to ensure that the trajectory of the simulation more closely follows the trajectory of the physical system. As a fundamental aspect of DDDAS, the sensor reconfiguration loop seeks to manage the physical sensors in order to enhance the information content of the collected data. The simulation based on computational feedback process guides the sensor reconfiguration and the data collection, and in turn, improves the accuracy of the physical system environmental assessment (e.g., space weather and RSO tracking). For sensor management, DDDAS develops runtime software methods for real-time control such as AC.

2.2.

Access Control Mechanism

An AC mechanism, which specifies admittance to certain resources or services, contributes to the protection, security, and privacy for IT systems. As a fundamental mechanism to enable security in computer systems, AC is the process that decides who is authorized to have what communication rights on which objects with respect to some security models and policies.¹⁷ An effective AC system is designed to satisfy the main security requirements, such as confidentiality, integrity, and availability. In general, a comprehensive AC system addresses three main security issues: authentication, authorization, and accountability.¹⁸ Authentication is the method of validating identity based on registered entity’s information. Authorization involves the following phases: defining a security policy (set of rules), selecting an AC model to encapsulate the defined policy, implementing the model, and enforcing the access rules.¹⁸ Accountability employs audit logs to associate subjects with functions.

The AC mechanism incorporates two aspects: the AC model and architecture. The role-based access control (RBAC)¹⁹ model provides a framework that authorizes user’s access to resources based on functions. In an RBAC model, permissions are assigned to each agent’s role according to organizational functionality definition, and ARs are indirectly granted by associating a user with certain specified role. The functional role acts as an intermediary to bring users and permissions together. The RBAC model supports principles, such as least privilege, partition of administrative functions, and separation of duties, and has widely been used in computer systems.²⁰ For example, the RBAC model implemented in Internet of things (IoT) networks adopts a Web of things framework,^21,22 which is a service-oriented approach, to enforce AC policies on the smart things via a web service application. However, current RBAC models are not able to address the key issues of implementing RBAC in a highly distributed network environment, such as self-management to handle the explosion of roles in complex and ambiguous space scenarios and autonomy to support physical objects through device-to-device communication.

Compared to the RBAC model, the attribute-based access control (ABAC)^23,24 model defines permissions based on any security relevant characteristics, known as attributes. In the ABAC, AC policies are defined by directly associating predefined attributes with subjects, resources, and conditions, respectively. Given all the attributes assignments, a policy rule, which is a Boolean function, decides whether to grant the subject’s access to the resource under specific conditions. The ABAC model eliminates the definition and management of static roles used in the RBAC model. Hence, ABAC also eliminates the need for the administrative tasks for user-to-role assignment and permission-to-role assignment.²³ To address the weaknesses of the RBAC model in a highly distributed network environment, an ABAC extension to the AWS-IoTAC model was proposed to enhance the flexibility of AC in cloud-enabled IoT platform.²⁵ An efficient elliptic curve cryptography-based authentication and the ABAC policy together was proposed to solve the resource-constrained problem of a perception layer.²⁶ Although the ABAC is more manageable and scalable than the RBAC by providing finer-grained AC policies that involve multiple subject and object attributes, specifying a consistent definition of the attributes within a single domain or across multiple domains could significantly increase the effort and complexity of policy management as the number of devices grow, and a user-driven and delegation strategies are not supported with the ABAC model. Hence, the attribute-based proposal is not suitable for large-scale distributed network scenarios.

Capability-based access control (CapAC) utilizes the concept of capability that contains rights granted to the entity holding it.¹⁸ The capability is defined as tokens, tickets, or keys that give the possessor permission to access an entity or object in a computer system.²⁷ The CapAC has been implemented in many large-scale projects, such as IoT@work.²⁸ However, the direct application of the original concept of CapAC model in a distributed network environment has raised several issues, such as capability propagation and revocation. To tackle these challenges, a secure identity-based capability (SICAP) system¹⁷ was proposed to provide a prospective capability-based AC mechanism in distributed networks. Using an exception list, the SICAP enables monitoring, mediating, and recording capability propagations to enforce security policies as well as achieving rapid revocation capability.¹⁷ By introducing a delegation mechanism for the capability generation and propagation process, a capability-based context-aware access control (CCAAC) model was proposed to enable contextual awareness in federated devices.²⁹ A federated delegation mechanism enables the CCAAC model has great advantages in terms of addressing scalability and heterogeneity issues in IoT networks. As a user-driven AC model, the CapAC supports machine-to-machine communication and presents great scalability and flexibility to deal with spontaneous and dynamic changes in distributed network environment. However, management of capability propagation becomes difficult without a proper delegation and revocation mechanism.

At the architecture level, the AC solutions are categorized as either the centralized or the decentralized approach. In a centralized AC architecture, the key components, such as authorization policy management and policy decision-making, employ a centralized authority. Outsourcing computational intensive tasks to a back-end cloud or a gateway relieves smart device from the burden of handling AC related functionalities. The approaches in Refs. 25, 26, 29, and 30 are centralized methods. The centralized AC solutions present many advantages, such as easy to adapt existing AC model and simple security policy management. However, enforcing AC on the centralized architecture also suffers from several data management drawbacks, such as single point of failure, performance bottleneck, and privacy issues.

To address the drawbacks in the centralized AC solutions, designing a decentralized AC mechanism supports SSA performance. A distributed capability-based access control (DCapAC) mechanism was proposed that directly deploys AC on resource-constrained devices.³¹ The DCapAC allows smart devices to autonomously make decisions on ARs based on an authorization policy, and it has advantages in scalability and interoperability. To address challenges such as scalability, granularity, and dynamicity in AC strategies for SSA systems, a federated capability-based access control (FedCAC) model is proposed to enable an effective AC mechanism to devices, services, and information in large-scale SSA systems.³² Migrating part of the centralized authorization validation tasks to local devices helps the FedCAC to be lighter and context-awareness enabled. The decentralized AC approach presents advantages, such as supporting user-driven security mechanism and not relying on centralized trust authority. Nonetheless, the decentralized approach also brings many issues, such as requiring a complex AC mechanism and introducing overhead such as in SATCOM.

2.3.

Blockchain and Smart Contract

The blockchain technology, which was initially introduced by Nakamoto in 2008,¹¹ has demonstrated its success in decentralization of digital currency and payment like bitcoin. A blockchain is a replicated public database (ledger) that records, stores, and updates all data as chained blocks. It is a public ledger that provides a verifiable, append-only chained data structure of transactions. Enforcing the consensus mechanism on a peer-to-peer network framework, the blockchain is essentially a decentralized architecture that does not rely on a centralized authority. The transactions are approved by a large amount of distributed nodes called miners and recorded in timestamped blocks, where each block is identified by a cryptographic hash and chained to preceding blocks in a chronological order. Blockchain uses a consensus mechanism, which is enforced on miners, to maintain the sanctity of the data recorded on the blocks. Thanks to the trustless proof mechanism running on miners across networks, users can trust the system of the public ledger stored worldwide on many different nodes maintained by “miner-accountants,” as opposed to having to establish and maintain trust with a transaction counter-party or a third-party intermediary.³³ Thus blockchain is considered an ideal decentralized architecture to ensure distributed transactions between all participants in a trustless environment.

Emerging from the smart property, a “smart contract” allows users to achieve agreements among parties and supports a variety of flexible transaction types through blockchain networks. Using cryptographic and security mechanisms, smart contract combines protocols with user interfaces to formalize and secure relationships over computer networks.³⁴ A smart contract includes a collection of predefined instructions and data that have been saved at a specific address of a blockchain as a Merkle hash tree, which is a constructed bottom-to-up binary tree data structure. Since smart contracts are developed as scripts and stored on the blockchain, each smart contract has a unique address that resides on the blockchain. Through exposing public functions or application binary interfaces (ABIs), a smart contract interacts with users to offer a predefined business logic or contract agreement.

Through encapsulating operational logic as a bytecode and performing turing complete computation on distributed miners, a smart contract allows the user to trans-code more complex business models as new types of transactions on a blockchain network. A smart contract provides a promising solution to allow the implementation of more flexible and complex applications far beyond cryptocurrencies, such as data provenance, resource sharing, and dynamic spectrum access. The blockchain and smart contract-enabled security mechanism for applications has been a hot research topic and some efforts have been reported recently, e.g., smart surveillance system,^35,36 social credit system,³⁷ identity authentication,³⁸ and AC.^39,40 The research reported by Mital et al.⁴¹ presents the potential role, capabilities and value of blockchain, and smart contract usage within constellation and swarm satellite architectures. The blockchain and smart contract together are promising toward providing a decentralized solution to allow more flexible and fine-grained AC models on space applications.

3.1.

BlendCAC System Architecture for SSA

Inspired by the smart contract and blockchain technology, a decentralized federated capability-based AC framework for SSA systems, called BlendCAC, is introduced in this paper, and a prototype of the proposal is implemented in a physical network environment to verify the efficiency and effectiveness on a simulated space network scenario. Figure 2 illustrates the proposed BlendCAC system architecture for SSA, which is intended to function in a scenario including multiple isolated space service domains without preestablishing a trust relationship.

Fig. 2

System architecture of BlendCAC.

In the proposed AC framework shown in Fig. 2, each domain master works as a certificate authority to provide identity authentication services and enforces delegated security policies to manage domain related space object functions and services. Both satellites and GSs could become domain masters. The identification authentication and access authorization policies are transcoded to the smart contracts and deployed across the blockchain network, and identity validation, authorization delegation, and AR verification are developed as service applications running on both domain masters and RSOs in the space network. The operation and communication modes are listed as follows.

3.2.

Identification Authentication

Authentication is the mechanism of validating identity information of entities. The overall purpose of an authentication strategy is to allow multiple entities to communicate with each other in a trustworthy way in a trustless network environment. Inspired by the idea of bubble of trust, all members in a bubble zone can trust each other.³⁸ The scheme in Fig. 3 illustrates the proposed authentication approach and all the phases of the ecosystem’s life cycle. The involved phases in an authentication process is as follows:

Fig. 3

Virtual trust zone mechanism for authentication: (a) initialization, (b) create virtual trust zone, (c) join virtual trust zone, and (d) identity authentication.

Through clustering the nodes into different virtual trust zones, the application domains become isolated. Only those authenticated entities are allowed to communicate with group members of their zones, whereas any entities outside of the zones are considered as suspicious and prevented from being connected to any group members in the zones.

3.3.

Capability Token Structure

In the access authorization scenarios, the entities are categorized as subjects or objects. Subjects are defined as entities who request services from the service providers, whereas objects are referred to as entities who offer the resources or services. Entities could be either human operators or RSOs like satellites. Since the identity registration and authentication processes are mainly performed on domain masters, a profile database that is used for recording the profile of each group member is constructed and maintained by the domain master. In the profile databased, all registered entities are associated with a globally unique VID, which is used as the prime key for searching entities’ profile information. As each entity has at least one main account indexed by its address in the blockchain network, the blockchain account address is used to represent the VID for profiling register entities.

In general, the capability specifies which subject can access resources at a target object by associating subject, object, actions, and condition constraints. The identity-based capability structure is defined as a hash table, which is represented as follows:

In the AC system, the elements in OP set can be represented as actions, such as $\{\text{read}\}$, $\{\text{write}\}$, $\{\text{read};\text{write}\}$, or $\{\mathrm{NULL}\}$. If $\mathrm{OP}=\{\mathrm{NULL}\}$, any operation conducted on the resource is not allowed. $C$ is defined as a context constraints set, such as $C=\{C1,C2\}$ or $C=\{\mathrm{NULL}\}$. If $C=\{\mathrm{NULL}\}$, no context constraint is considered in the AR validation process.

3.4.

Capability-Based Access Right Authorization

The capability token structure and the related operations are transcoded to a smart contract that is deployed on the blockchain network, and the AR authorization is implemented as a policy-based decision-making service running on the domain master. As shown in Fig. 4, a comprehensive capability-based AR authorization procedure consists of four steps: capability generation, AR validation, capability delegation, and revocation.

Fig. 4

Flowchart of the capability-based AR authorization.

4.1.

Authentication Certificate and Capability Token Structure

The proposed identity authentication and AC models have been transcoded to smart contracts using solidity,⁴⁵ which is a contract-oriented, high-level language for implementing smart contracts. With Truffle,⁴⁶ which is a world class development environment, testing framework, and asset pipeline for Ethereum, contract source codes are compiled to Ethereum virtual machine bytecode and migrated to the Ethereum blockchain network.

To implement a BlendCAC system on RSOs without introducing significant overhead over SATCOM and computation, delegation certificate and capability token data structure is represented in JSON⁴⁷ format. Compared to XML-based language for AC, such as XACML and SAML, JSON is lightweight and suitable for resource constrained platforms.

Figure 5(a) demonstrates an example of the authentication certificate, and the data fields in the data structure are described as follows:

Figure 5(b) presents an example of the capability token data used in the AC mechanism. A brief description of each field is provided as follows:

Fig. 5

Token data structure used in BlendCAC: (a) authentication certificate and (b) capability token.

After a smart contract has been successfully deployed on the blockchain network, all nodes in the network could interact with the smart contract using address of the contract and the ABI definition, which describes the available functions of the contract.

4.2.

Identity Authentication Policy Service

The identity authentication mechanism based on the virtual trust zone is implemented as a set of service interface functions, which are executed by the smart contract to enforce the authentication policy. Algorithm 1 illustrates the virtual trust zone construction process. The function createVZone() receives the inputs of the string VZoneID and returns the VZone creation result. The process first checks the entity address so that the supervisor or the valid masters are allowed to create a new VZone. The existing virtual trust zones could be deleted either by the supervisor or masters who have created the VZones, and the revocation process is illustrated in Algorithm 2.

Algorithm 1

Create virtual trust zone

Algorithm 2

Revoke virtual trust zone

After the virtual trust zones have been constructed by masters, other nodes could send registration requests to the masters for joining the virtual trust zone. Algorithm 3 describes the process of how a node becomes a member of a VZone. Once the Vnode of the applicant has been recorded in the blockchain, he/she could communicate with other nodes in the same VZone. The associated trust relationship between a node and the VZone could be revoked either through leave request sent by the node, or directly be removed by the supervisor and the master of the VZone. Algorithm 4 explains the operation to remove a node from a virtual trust zone.

The identity verification is enforced based on service providing scenarios. As a service provider received a service request from an entity, he/she just queries entity’s Vnode data in the blockchain and verifies the identification by simply checking whether or not the entity has the same VZoneID. The requests from non-VZone entities are directly rejected.

Algorithm 3

Join virtual trust zone

Algorithm 4

Leave virtual trust zone

4.3.

Access Authorization Service

The access authorization and validation policy is enforced as a web service application, which emulates the space service scenarios among satellites and GSs. The test application is developed on the Flask framework⁴⁸ using Python. The Flask is a microframework for Python based on Werkzeug, Jinja 2, and good intentions. The lightweight and extensible microarchitectures make the Flask a preferable web solution on resource constrained devices.

Web service application in the BlendCAC system consists of two parts: client and server. The client performs operations on resource by sending data request to the server, whereas the server provides REST-ful API for the client to obtain data or perform operations on the resource at the server side. A capability-based AC scheme is enforced at the server side by performing AR validation on the service provider. The AR validation process is launched after a request containing the client’s identity is received by the server. Figure 6 shows a block diagram with the steps to process an authorization request.

Fig. 6

Access authorization process of BlendCAC.

5.1.

Testbed Setup

The mining task is performed on a system with stronger computing power, such as a laptop or a desktop. Two miners are deployed on a laptop and other four miners are distributed on four desktops. Table 1 describes configuration of nodes used in the experiments. In our system, the laptop acts as a cloud computing server, whereas all desktops work as fog computing nodes to take role of domain masters. Each miner uses two CPU cores for mining. The edge computing services are deployed on two Raspberry Pi 3 Model B. Since the Raspberry Pi is not powerful enough to carry out mining task, so all Raspberry Pi devices function as nodes to participate in the private blockchain network without mining. All devices use Go-Ethereum⁵¹ as the client application to work on the blockchain network.

Table 1

Configuration of experimental nodes.

5.2.

Experimental Results

To verify the effectiveness of the BlendCAC approach against unauthorized access requests, a service access experiment is carried out on a simulated SATCOM network. In the simulation environment, the edge devices represent satellites and the server is the ground communication receiving data, such as space imagery. In the test scenario, one Raspberry Pi 3 device works as the client and another works as the service provider. The identity authentication results are shown in Figs. 7(a) and 7(b). Figure 7(a) demonstrates that the node “0xaa09c6d65908e54bf695748812c51d8f2ceea0f5” successfully passed the authentication process executed on the server with the same VZoneID. Figure 7(b) shows a failed authentication scenario caused by communicating with entity who belongs to a different virtual trust zone.

Fig. 7

Examples of experimental results of the BlendCAC system: (a) identity authentication succeed, (b) identity authentication failed, (c) access authorization succeed, and (d) access authorization failed.

Given the access authorization process shown in Figs. 7(c) and 7(d), when any of the steps in the authorization procedure fails, the running process immediately aborts instead of continuing to step through all the authorization stages. As shown in Fig. 7(d), the server stopped the authorization process due to the failure in verifying the granted actions or the conditional constraints that are specified in the AR list. Consequently, the client node received a deny access notification from the server and cannot read the requested data. In contrast, Fig. 7(c) presents a successful imagery data request example, in which the whole authorization process is accomplished at the server side without any error. Finally, the client successfully retrieves the imagery data from the service provider.

5.3.

Performance Evaluation

In the simulation environment, two Raspberry Pi devices emulate satellites to provide on-orbit observations while a desktop computer serves as a GS to perform ground observations. One Raspberry Pi device is adopted to play the role of the client while another Raspberry Pi and desktop computer are service providers, and an Ethernet is used to simulate SATCOM communication channel. To measure the general cost incurred by the proposed BlendCAC scheme both on the space (e.g., satellite) devices’ processing time and the network communication delay, 100 test runs have been conducted based on the proposed test scenario, where the client sends a data query request to the server for an access permission. This test scenario is based on an assumption that the subject has joined the virtual trust zone and has been assigned a valid capability token when it performs the action. Therefore, all steps of identity authentication and authorization validation must be processed on the server side so that the maximum latency value is computed.

5.3.1.

Computational overhead

According to the results shown in Fig. 8, the average total delay time caused by the BlendCAC operation of retrieving data from the client to server is 250 ms on satellites. Since the GSs have much more computation capacity than the satellites, the execution time of the whole data querying process on the ground communication is about 60 ms. The total delay includes the round trip time (RTT), time for querying capability data from the smart contract, time for parsing JSON data from the request, and time for identity authentication and the AR validation. The token processing task is mainly responsible for fetching token data from the smart contract and introduces the highest workload among the AC operation stages. As the most computing intensive stage, the execution time of token processing is about 60 ms on the satellite, and the same operation on the ground communication only needs 10 ms.

Fig. 8

Computation time for each stage in BlendCAC.

The entire AC process is divided into two steps, identity authentication and capability token verification. Since the identity authentication process needs to interact with smart contract twice for querying VZone and Vnode data separately, identity authentication processing time is 152 ms, which is almost twice as much as that of execution on capability-based AC stage: 63 ms. The execution time of the AC process is about 214.5 ms ($152+62.5$) on satellites, which accounts for almost 86% of the entire data service processing time.

5.3.2.

Communication overhead

Due to the high overhead introduced by querying token data from the smart contract in token processing stage, a token data caching solution is introduced in the BlendCAC system to reduce the network latency. When the client sends a service request to the server, the service provider extracts cached token data from the local storage to valid authorization. The service providers regularly update cached token data by checking smart contract status. The token synchronization time is consistent with the block generation time, which is about 15 s in the Ethereum blockchain network. Simulating a regular service request allows us to measure how long it takes for the client to send a request and retrieve the data from the server.

Figure 9 shows the overall SATCOM communication latency incurred and compares the execution time of the BlendCAC and a benchmark without any AC enforcement (BwoAC). At the beginning, a long SATCOM delay is observed in the first service request scenario, in which the service provider communicated with the smart contract and cached the token data. However, by processing the local cached token data for authorization validation, the SATCOM latency decreases quickly and becomes stable during the subsequent service requests. At the satellite device, the BwoAC takes an average of 35 ms for fetching requested data versus the BlendCAC that has an average of 44 ms. The results demonstrate that the proposed BlendCAC scheme only introduces about 9 ms extra latency. The overhead in terms of delay by the AC enforcement is even more trivial on ground communication nodes. The average time for querying data with AC is about 26 ms, which is almost the same as the average time of querying data without AC. However, the benefit of the secure BlendCAC outweighs the small latency cost.

Fig. 9

SATCOM latency of BlendCAC.

5.4.

Discussion

The experimental results demonstrate that the proposed BlendCAC strategy is effective and efficient to protecting the space devices and services from an unauthorized access request. Compared to centralized AC solutions, the BlendCAC scheme has the following advantages:

Although the proposed BlendCAC mechanism has demonstrated these attractive features, using blockchain to enforce AC policy in space systems, it also incurs new challenges in performance and security. The transaction rate is associated with confirmation time of the blockchain data, which depends on the block size and the time interval between the generations of new blocks. Thus the latency for transaction validation may not be able to meet the requirement in real-time SSA scenarios. In addition, as the amount of transactions increases, the blockchain becomes large. The continuously growing data introduce more overhead on storage and computing resources of each client, especially for resource constrained devices. Furthermore, the blockchain is susceptible to majority attack (also known as 51% attacks), in which once an attacker takes over 51% computing power of network by colluding selfish miners, they are able to control the blockchain and reverse the transactions. Finally, since the blockchain data are open to all nodes joined the blockchain network, such a property of transparency inevitably brings privacy leakage concerns. More research efforts are necessary to improve the trade-off when applying the BlendCAC in practical scenarios.