An Exploration of Blockchain Enabled Decentralized Capability based Access Control Strategy for Space Situation Awareness

An Exploration of Blockchain Enabled Decentralized Capability
based Access Control Strategy for Space Situation Awareness
Ronghua Xua
, Yu Chena*
, Erik Blaschb
, Genshe Chenc
a
Department of Electrical and Computer Engineering, Binghamton University, SUNY, Binghamton, NY, USA, 13902
b
The U.S. Air Force Research Lab, Rome, NY, USA, 13441
c
Intelligent Fusion Technology, Inc., Germantown, MD, USA, 20876
Abstract. Space situation awareness (SSA) includes tracking of active and inactive resident space objects (RSOs)
and space weather assessment through space environmental data collection and processing. To enhance SSA, the dy-
namic data-driven applications systems (DDDAS) framework dynamically couples on-line data with off-line models
to enhance system performance. Such as feedback control, sensor management, and communications reliability. For
information management, there is a need for identity authentication and access control strategy to ensure the integrity
of exchanged data as well as to grant authorized entities access right to data and services. Due to decentralization and
heterogeneity nature of SSA systems, it is very challenging to build a efﬁcient centralized access control system, which
could either be a performance bottleneck or the single point of failure. Inspired by the blockchain and smart contract
technology, this paper introduces BlendCAC, a decentralized authentication and capability-based access control mech-
anism to enable effective protection for devices, services and information in SSA networks. To achieve secure identity
authentication, the BlendCAC leverages the blockchain to create virtual trust zones, in which distributed components
could identify and update each other in a trustless network environment. A robust identity-based capability token
management strategy is proposed, which takes advantage of the smart contract for registration, propagation, and revo-
cation of the access authorization. A proof-of-concept prototype has been implemented on both resources-constrained
devices (i.e., Raspberry PI nodes) and more powerful computing devices (i.e., laptops), and is tested on a private
Ethereum blockchain network. The experimental results demonstrate the feasibility of the BlendCAC scheme to offer
a decentralized, scalable, lightweight and ﬁne-grained access control solution for space system towards SSA.
Keywords: Blockchain, Smart Contract, Decentralized Access Control, Dynamic Data-Driven Application System
(DDDAS), Space Situation Awareness (SSA).
*Correspondence: ychen@binghamton.edu
1 Introduction
Recent advances in Big Data (BD) have focused research on the volume, velocity, veracity, and
variety of dynamic data. These developments enable new opportunities in information manage-
ment, visualization, machine learning, and information fusion that have potential implications for
space situational awareness (SSA).1
In SSA systems, the space environmental data can be col-
lected and processed to determine object motions and models updates.2,3
A common example is
space tracking using electro-optical sensors.4
The key aspect for SSA is to track the many resi-
dent space objects (RSO), either satellites, debris, or space transportation support.5
To enable the
1
arXiv:1810.01291v1[cs.CR]1Oct2018

space environment assessment, many attributes are considered, including communications, space
weather, and conjunction analysis as well as using non-tradition data.6
As one of the most critical
research areas in SSA, there is a need for network management of the space surveillance net-
work.7,8
One development for resource management includes the dynamic data-driven application
system (DDDAS) framework whereby measurements are injected into the execution model to en-
hance system performance. The DDDAS integrates on-line data with the off-line models creating
a positive feedback loop, where the model judiciously guides the sensor selection, sensor data
collection, from which the sensor data improves the accuracy of the model.6
DDDAS technology can enhance the space network, where components interact and cooperate
with each other to build a big data platform to provide a wide rage of services.9
Thus, a huge num-
ber of entities, e.g., physical RSO and virtual services, connect and produce space environment
data that can be retrieved by users regardless of their location. To reduce data security risks such
as information theft and data alteration, and it requires that only authenticated and authorized en-
tities are allowed to access the data and use the services provided by the system. The conventional
access control approaches have been widely used in the IT ecosystem. However, the existing se-
curity solutions are not fully adapted to space ecosystem due to the constrained resources of space
objects and heterogeneity of the platforms. The combination of multiple security technologies and
solutions leads to extraordinary high overload on the system. Furthermore, today’s access control
solutions often rely on centralized architecture, which not only demonstrates enormous scalability
issues in an distributed environment composed of large number of nodes, but also can be a per-
formance bottleneck or the single point of failure. Consequently, it is necessary to propose new
access control solutions for SSA systems.
The blockchain protocol has been recognized as the potential candidate to revolutionize the
2

fundamentals of IT technology because of its many attractive features and characteristics, such
as supporting decentralization and anonymity maintenance,10
as well as a fundamental proto-
col of Bitcoin,11
the first digital currency. In this paper, a BLockchain-ENabled, Decentralized,
Capability-based Access Control (BlendCAC) scheme is proposed to enhance the security of space
applications. BlendCAC provides a decentralized, scalable, fine-grained and lightweight authen-
tication and access control mechanism to protect devices, services and information in space net-
works. To achieve secure identity authentication, a decentralized authentication mechanism is
implemented on the blockchain, and aims at creating virtual trust zones to allow all distributed
things to identify each other and communicate securely in the trustless network environment. An
identity-based capability token management strategy is presented and the federated authorization
delegation mechanism is illustrated. A proof-of-concept prototype has been tested on a private
Ethereum blockchain network, and the experimental results demonstrate the feasibility and effec-
tiveness of the proposed BlendCAC scheme.
The major contributions of this work are as follows:
1. Leveraging the blockchain and smart contract technologies, a decentralized access control
solution is proposed to address both the identity authentication and access authorization
issues in the distributed space network environment;
2. Using virtual trust zone, the authentication mechanism ensures that only authenticated enti-
ties in same domain could communicate with each other, meanwhile the capability-based ac-
cess control model provides a scalable, flexible, fine-grained and lightweight access scheme
for space applications;
3. A complete architecture of a blockchain-enabled decentralized access control system is prop-
3

erly designed, which includes identity authentication, capability token management and ac-
cess right validation. The data structures of identity certificate and capability token are
explained. The identity authentication algorithms and access right verification process are
discussed in detail; and
4. A concept-proof prototype based on smart contracts is implemented both on resource-constrained
edge devices and more powerful devices, and deployed on a local private Ethereum blockchain
network. A comprehensive experimental study has been conducted that evaluates the com-
putational and the financial cost of using the public blockchain.
The remainder of this paper is organized as follows: Section 2 gives a brief review on the state-
of-the-art research in access control and blockchain technology. Section 3 illustrates the details
of the proposed BlendCAC system and Section 4 explains the implementation of the proof-of-
concept prototype. The experimental results and evaluation are presented in Section 5. Finally, the
summary, current limitations and on-going efforts are discussed in Section 6.
2 Background Knowledge and Related Work
2.1 SSA and DDDAS
The SSA environment generally consists of two major area: satellite operations and space weather.
The satellite operations are focused on the local perspective to enable continuous operations by un-
derstanding the space environment and build models to support satellite health monitoring (SHM).
While SSA is a global perspective, and data collected from ground and other space assets are used
for RSO tracking, imaging and collision avoidance.6,12,13
The key components of SSA includes
4

RSO tracking and characterization, satellite health monitoring and communication, information
management sensing, navigation, and data visualization.6,14
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 SSA application, DDDAS is a
variation of adaptive state estimation that uses computational feedback rather than physical feed-
back to enhance the information content of measurements. The core feedback loops in DDDAS are
data assimilation loop and sensor reconfiguration loop. The data assimilation loop calculates the
physical system simulation by 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 in-
formation 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 sen-
sor management, DDDAS develops runtime software methods for real-time control such as access
control.
2.2 Access Control Mechanism
An Access Control (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.15
An effective AC system is designed to satisfy the main security requirements, such as confiden-
tiality, integrity and availability. In general, a comprehensive AC system addresses three main
5

security issues: Authentication, Authorization and Accountability.16
Authentication is the method
of validating identity based on registered entity’s information. Authorization involves the follow-
ing 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.16
The AC mechanism incorporates two aspects: the AC model and architecture. The Role-Based
Access Control (RBAC)17
model provides a framework that authorizes users access to resources
based on functions. In a RBAC model, permissions are assigned to each agent’s role according to
organizational functionality definition, and access rights are indirectly granted by associating a user
with certain specified role. The functional role acts as an intermediary to bring users and permis-
sions together. The RBAC model supports principles, such as least privilege, partition of admin-
istrative functions and separation of duties; and has been widely used in computer systems.18
For
example, the RBAC model implemented in IoT networks adopts a Web of Things (WoTs) frame-
work,19,20
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 the autonomy for the
physical objects through device-to-device communication.
Compared to the RBAC model, the Attribute-Based Access Control (ABAC),21,22
model de-
fines permissions based on any security relevant characteristics, known as attributes. In the ABAC,
AC policies are defined through 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
6

model. Hence, it also eliminates the need for the administrative tasks for user-to-role assignment
and permission-to-role assignment.21
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.23
An efficient Elliptic Curve Cryp-
tography (ECC)-based authentication and the ABAC policy together was proposed to solve the
resource-constrained problem of a perception layer.24
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 manage-
ment as the number of devices grow, and a user-driven and delegation strategy are not supported
by 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.16
The capability is defined as tokens, tickets, or keys that give the
possessor permission to access an entity or object in a computer system.25
The CapAC has been
implemented in many large-scale projects, like IoT@Work.26
However, the direct application of
the original concept of CapAC model in a distributed network environment has raised several
issues, like capability propagation and revocation. To tackle these challenges, a Secure Identity-
Based Capability (SICAP) System15
was proposed to provide a prospective capability-based AC
mechanism in distributed networks. By using an exception list, the SICAP enables monitoring,
mediating, and recording capability propagations to enforce security policies as well as achieving
rapid revocation capability.15
By introducing a delegation mechanism for the capability generation
and propagation process, a Capability-based Context-Aware Access Control (CCAAC) model was
7

proposed to enable contextual awareness in federated devices.27
Federated delegation mechanism
enables CCAAC model have 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
(M2M) communication, and presents great scalability and ﬂexibility to deal with spontaneous
and dynamic changes in distributed network environment. However, management of capability
propagation becomes difﬁcult without a proper delegation and revocation mechanism.
At the architecture level, the AC solutions are categorized as either the centralized or the decen-
tralized approach. In a centralized AC architecture, the key components, like authorization policy
management and policy decision making, employ a centralized authority. Outsourcing computa-
tional intensive tasks to a back-end cloud or a gateway relieves smart device from the burden of
handling AC related functionalities. The approaches in23,24,27,28
are centralized methods. The cen-
tralized 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, like single point of failure, performance bottleneck and
privacy issues.
To address the drawbacks in the centralized AC solutions, designing a decentralized AC mecha-
nism supports SSA performance. A distributed Capability-based Access Control (DCapAC) mech-
anism was proposed that directly deploy AC on resource-constrained devices.29
The DCapAC al-
lows smart devices to autonomously make decisions on access rights based on an authorization
policy, and it has advantages in scalability and interoperability. To address challenges like scala-
bility, granularity, and dynamicity in AC strategies for SSA systems; a Federated Capability-based
Access Control model (FedCAC) is proposed to enable an effective AC mechanism to devices,
services and information in large scale SSA systems.30
Migrating part of the centralized autho-
8

rization validation tasks to local devices helps the FedCAC to be lighter and context-awareness
enabled. The decentralized AC approach presents the advantages, like supporting User-driven se-
curity mechanism and not relying on centralized trust authority. Nonetheless, the decentralized
approach also brings many issues, such as requiring complex AC mechanism and introducing
overhead such as in satellite communications.
2.3 Blockchain and Smart Contract
The blockchain technology, which was initially introduced by Nakamoto in 2008,11
has demon-
strated 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 veriﬁable, append-only chained data structure of transactions.
Enforcing the consensus mechanism on a peer-to-peer network framework, the blockchain is es-
sentially 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 identiﬁed by a cryptographic hash and chained to preceding blocks
in a chronological order. Blockchain uses consensus mechanism, which is enforced on miners,
to maintain the sanctity of the data recorded on the blocks. Thanks to the trustless proof mech-
anism 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.31
Thus,
Blockchain is considered an ideal decentralized architecture to ensure distributed transactions be-
tween all participants in a trustless environment.
Emerging from the smart property, smart contract allows users to achieve agreements among
9

parties and supports variety of flexible transaction types through blockchain network. By using
cryptographic and security mechanisms, smart contract combines protocols with user interfaces to
formalize and secure relationships over computer networks.32
A smart contract includes a collec-
tion of pre-defined 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 in-
terfaces (ABIs), a smart contract interacts with users to offer predefined business logic or contract
agreement.
Through encapsulating operational logic as a bytecode and performing Turing complete com-
putation on distributed miners, a smart contract allows the user to trans-code more complex busi-
ness 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 be-
yond cryptocurrencies, such as data provenance, resource sharing and dynamic spectrum access,
etc. The blockchain and smart contract enabled security mechanism for applications has been a hot
research topic and some efforts have been reported recently, for example, smart surveillance sys-
tem,33,34
social credit system,35
identity authentication36
and access control.37,38
The blockchain
and smart contract together are promising towards providing a solution to allow more flexible and
fine-grained AC models on decentralized networks.
10

3 BlendCAC: A BLockchain-ENabled Decentralized CapAC Mechanism
3.1 BlendCAC System Architecture
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 pro-
totype of proposal is implemented in a physical network environment to verify the efficiency and
effectiveness on a simulated scenario of space network. Figure 1 illustrates the proposed Blend-
CAC system architecture for SSA, which is intended to function in a scenario including multiple
isolated space service domains without pre-establishing a trust relationship. In the proposed frame-
work, each domain master works as certificate authority to provide identity authentication services,
and enforces delegated security policies to manage domain related space objects and services. 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
access right verification are developed as service applications running on both domain masters and
resident space objects in the space network. The operation and communication modes are listed as
follows:
1. Identification Authentication: All entities must create at least one main account defined by
a pair of keys to join the blockchain network. Each account is uniquely indexed by its ad-
dress that is derived from his/her own public key. Thus, account address is ideal for identity
authentication in the BlendCAC system given assumption that authentication process is en-
sured by a blockchain network. In this scenario, a virtual trust zone is created by the domain
master, such that each object is allowed to communicate with objects in the same virtual
trust zone. Entity registration process uses account address as a VID, which are recored
11

Fig 1 System Architecture of BlendCAC.
in the profile database that is deployed on the domain master. New entity must send au-
thentication request to the domain master in order to join the virtual trust zone. Once the
identity information related to requester is verified, the domain master will create the ticket
for the registered entity by recording his/her blockchain account address and group ID in
the blockchain for authentication process when an service request happens. As a result, the
domain masters not only are responsible for identification authentication, but also are able
to enforce delegated authorization policies and perform decision-making to directly control
the objects or resources in virtual trust zone instead of depending on third parties.
2. Smart Contract Deployment: The smart contract, which carries out authentication and man-
ages federated delegation relation and capability tokens, must be developed and deployed
12

on the blockchain network by the policy owner. In the BlendCAC framework, the adminis-
trators of the DDDAS, who act as the data and policy owners, could deploy smart contracts
encapsulating authentication and authorization algorithms. After smart contracts have been
deployed successfully on the blockchain network, they become visible to the entire network
owing to the transparency and publicity properties of the blockchain protocol, which means
that all participants in the blockchain network can access transactions and smart contracts
recorded in the chain data. Thanks to the cryptographic and security mechanisms provided
by the blockchain network, smart contracts can secure any algorithmically speciﬁable proto-
cols and relationships from malicious interference by third parties under a trustless network
environment. After synchronizing the blochchain data, all nodes could access all transac-
tions and recent state of each smart contract by referring local chain data. Each node inter-
acts with the smart contract through the provided contract address and the Remote Procedure
Call (RPC) interface.
3. Capability Authorization: To successfully access services or resources at service providers,
an entity initially sends an access right request to the domain master to get a capability
token. Given the entity’s ticket, which is the authenticated identity information saved in the
blockchain, a decision making policy module running on the domain master evaluates the
access request by enforcing the authorization policies. If the access request is granted, the
domain master issues the capability token encoding the access right, and then launches a
transaction to update the token data in the smart contract. Once the transaction has been
approved and recorded in a new block, the domain master responses to the requester by
providing a smart contract address for the querying token data. Otherwise, the access right
13

request is rejected by returning denied acknowledgement.
4. Access Right Validation: The authorization validation process is performed at the object who
works as the local service provider on receiving a service request from the subject. Through
regularly synchronizing the local chain data with the blockchain network, a service provider
just simply checks the current state of the contract in the local chain to get a capability
token associated with the entity’s address. Considering the capability token validation and
access authorization process result, if the access right policies and conditional constraints are
satisfied, the service provider grants the access request and offers services to the requester.
Otherwise, the service request is denied.
To enable a scalable, distributed and fine-grained AC scheme for space networks, the proposed
BlendCAC is focused on three issues: the identification authentication, the identity-based capabil-
ity management, and the access right authorization.
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.36
The scheme in Figure 2 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:
• Initialization: As shown in Figure 2A, the connected things that belong to numerous dif-
ferent areas freely communicate with each other. All the objects in the network could be
14

Fig 2 Virtual Trust Zone Mechanism for Authentication.
15

categorized as either domain masters or service nodes. All the objects should use their main
blockchain account addresses as the virtual ID for authentication and AC purposes.
• Creation of Virtual Zones: The smart contract for authentication is created by administrators,
and deployed through transaction, as shown in Figure 2B. The master has to communicate
with the administrator to create the virtual trust zone for their domain. The master sends
a transaction that contains the master’s identifier as well as the identifier of the group to
be created. The administrator verifies the identity information of the master and sends the
transaction to the smart contract to create the virtual trust zone for the master. The blockchain
verifies the uniqueness of both of the group ID and the master’s Virtual ID. If all conditions
are satisfied, the smart contract generates a new virtual trust zone with an unique virtual zone
ID for the master and returns the smart contract address and authorized RPC for the master
to interact with.
• Join Virtual Trust Zone: Figure 2C demonstrates how nodes are associated with the virtual
trust zone. After a virtual trust zone has been created, the nodes in turn, send transactions
to the master in order to join their respective virtual trust zones. The domain master checks
the applicant’s identifier based on the registration policy. If all conditions are satisfied and
the applicant has never joined the zone before, the master interacts with the smart contract to
add the node to the virtual trust zone. As miners have verified the transaction and generated
a new block, the node joins the virtual trust zone successfully with an unique group ID.
• Identity Authentication: As all nodes’ group information are recored in the blockchain and
the identifier verification process is ensured by the smart contract, the identity authentication
is no longer relying on a third-party centralized trust authority. In Figure 2D, node 8 could
16

successfully talk to node 4 owning to the fact that they have the same Vzone ID. However,
the node 5 denies the connect request from node 4 because they do not share the same
Vzone ID, which means that they actually do not belong to the same virtual trust zone.
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, while 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, while objects are referred
to entities who offer the resources or services. Entities could be either human operators or resident
space objects, like satellites. Since the identity registration and authentication processes are mainly
performed on domain masters, a profile database that is used for recording 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 Virtual Identity (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 as-
sociating subject, object, actions and condition constraints. The identity-based capability structure
17

is deﬁned as a hash table which is represented as follows:
ICap = f(V IDS)→{V IDO, OP, C} (1)
where the parameters are:
• f: a one-way hash mapping function to establish relation between a subject and authorized
internal capability set;
• V IDS: the virtual ID of a subject that requests an access to a service or resource;
• V IDO: the virtual ID of an object that provides a service or resource;
• OP: a set of authorized operations, e.g. read, write, execute; and
• C: a set of context awareness information, such as time, location, etc.
In the AC system, the elements in OP set can be represented as actions, such as {Read},
{Write}, {Read; Write}, or {NULL}. If OP = {NULL}, any operation conducted on the
resource is not allowed. C is deﬁned as a context constraints set, like C = {C1, C2} or C =
{NULL}. If C = {NULL}, no context constraint is considered in the access right 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, while the access right (AR) authorization is implemented
as a policy-based decision making service running on the domain master. As shown by Figure
18

3, a comprehensive capability-based access right authorization procedure consists of four steps:
capability generation, access right validation, capability delegation and revocation.
1. Capability Generation: As one type of meta data to represent the access right, the capa-
bility ICap could be generated by associating a VID with an AR, thus the ICap has the
identified property to prevent forgery. After receiving an access request from a user, the
domain master generates a capability token based on the access right authorization policy,
and launches transactions to save a new token data to a smart contract. A large number of
ICap’s are grouped into the capability pools on the smart contract, which could be proofed
and synchronized among the nodes across the blockchain network.
2. Access Right Validation: After receiving the service request from a subject, the service
provider first fetches the capability token from the smart contract using the subject’s ad-
dress, then makes decisions on whether or not to grant an access to the service according to
the local AC policy. Implementing access right validation at the local service provider al-
lows smart objects to be involved in the AC decision making task, which is suitable to offer
a flexible and fine-grained AC service in distributed space networks.
3. Capability Revocation: The capability revocation considers two scenarios: partial access
right revocation and ICap revocation. In the system design, only the administrator or do-
main masters are allowed to perform revocation operation on the capability tokenized smart
contract. In the partial access right revocation process, the authorized entities could remove
part of the entries from AR to revoke the selected access rights. In case of ICap revocation,
through directly clearing the AR in ICap, the whole capability token becomes unavailable
to all associated entities.
19

Fig 3 Flowchart of the Capability-based Access Right Authorization.
4 Prototype Design
A proof-of-concept prototype system has been implemented in a real private Ethereum blockchain
network environment extending an SSA study.39
As the second biggest ledger in the world,
Ethereum is robust against attacks and data falsifications. In addition, transactions in Ethereum
adopt the Elliptic Curves Cryptography as the signature scheme, which represents robust and
lightweight properties for constrained devices. Furthermore, compared with other open blockchain
platforms, like Bitcoin and Hyperledger, Ethereum has a more matured ecosystem and is designed
to be more adaptable and flexible for the development of a smart contract and business logic.40
4.1 Authentication Certificate and Capability Token Structure
The proposed identity authentication and AC models have been transcoded to smart contracts us-
ing Solidity,41
which is a contract-oriented, high-level language for implementing smart contracts.
With Truffle,42
which is a world class development environment, testing framework and asset
pipeline for Ethereum, contract source codes are compiled to Ethereum Virtual Machine (EVM)
20

bytecode and migrated to the Ethereum blockchain network.
To implement a BlendCAC system on resident space objects without introducing significant
overhead over network communication and computation, delegation certificate and capability to-
ken data structure is represented in JSON43
format. Compared to XML-based language for AC,
like XACML and SAML, JSON is lightweight and suitable for resource constrained platforms.
Fig 4 Token Data Structure used in BlendCAC.
Figure 4(a) demonstrates an example of the authentication certificate, and the data fields in the
data structure are described as follows:
• vid : a 20-byte value to represent address of the certificate owner in the blockchain network;
21

• V Zone: a virtual trust zone data that has been created by the master, including
– V ZoneID: a string that is used for a virtual trust zone data uniquely represented; and
– master: a 20-byte value used to represent the blockchain account address of the entity
who created the virtual trust zone.
• V node: a set of identity information that has been associated to the node for authentication,
including
– V ZoneID: a string that is used to record the unique ID of a virtual trust zone, in which
the entity has participated; and
– node type: an integer to specify the role that the entity has been assigned in the virtual
trust zone, either the master or the follower.
Figure 4(b) presents an example of the capability token data used in the AC mechanism. A
brief description of each field is provided as follows:
• vid : a 20-byte value to represent address of the capability token owner in the blockchain
network;
• V Zone master : a 20-byte value used to record address of the master in the virtual trust
zone that entity has joined;
• id: the auto-incremented prime key to identify a capability token;
• initialized: a bool flag used for checking token initialized status;
• isV alid: a boolean flag signifying the enabled status to show whether or not the token is
valid;
22

• issuedate: for identifying the date and time when the token was issued;
• expireddate: the date and time when a token expires;
• authorization: a set of access right rules that the issuer has granted to the subject, including
– action: to identify a specific granted operation over the resource;
– resource: the resource in the service provider for which the operation is granted; in
this case, the resource is defined as the granted REST-ful API; and
– conditions: a set of conditions which must be fulfilled locally on the service provider
to grant the corresponding operation.
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 Application
Binary Interface (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 authenti-
cation policy. Algorithm 1 illustrates the virtual trust zone construction process. The function
createV Zone() receives the inputs of the string V ZoneID, and returns the V Zone creation re-
sult. The process firstly 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 by
Algorithm 2.
23

After the virtual trust zones have been constructed by masters, other nodes could send registra-
tion requests to the masters for joining the virtual trust zone. Algorithm 3 describes the process that
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 1 Create Virtual Trust Zone
Require: V ZoneID
1: entityAddr = msg.sender
2: if (entityAddr == supervisor) or (isV alidMaster(entityAddr) == true) then
3: if if(V zone[V ZoneID].master == address(0)) then
4: V zone[V ZoneID].uid+ = 1
5: V zone[V ZoneID].master = entityAddr
6: V node[entityAddr].V ZoneID = V zoneID
7: V node[entityAddr].node type = 1
8: returnTrue
9: else
10: returnFalse
11: end if
12: else
13: returnFalse
14: end if
24

Algorithm 2 Revoke Virtual Trust Zone
Require: V ZoneID
2: if entityAddr == supervisor then
3: if (entityAddr == supervisor) or ((isV alidMaster(entityAddr) == true) and
V zone[V ZoneID].master == entityAddr) then
4: curr master = V zone[V zoneID].master
5: V zone[V ZoneID].uid+ = 1
6: V zone[V ZoneID].master = address(0)
7: V node[entityAddr].V ZoneID = ””
9: returnTrue
10: else
11: returnFalse
12: end if
13: else
14: returnFalse
15: end if
Algorithm 3 Join Virtual Trust Zone
Require: V ZoneID
Require: nodeAddr
2: if (entityAddr == supervisor) or (entityAddr == V zone[V ZoneID].master) then
3: if V node[nodeAddr].nodetype == 0 then
4: V node[nodeAddr].V ZoneID = V zoneID
5: V node[nodeAddr].node type = 2
6: returnTrue
7: else
8: returnFalse
9: end if
10: else
11: returnFalse
12: end if
25

Algorithm 4 Leave Virtual Trust Zone
Require: V ZoneID
Require: nodeAddr
2: if (entityAddr == supervisor) or (entityAddr == V zone[V ZoneID].master) then
3: if V node[nodeAddr].nodetype == 2 then
4: V node[entityAddr].V ZoneID = ””
6: returnTrue
7: else
8: returnFalse
9: end if
10: else
11: returnFalse
12: end if
4.3 Access Authorization Service
The access authorization and validation policy is enforced as a web service application based on the
Flask framework44
using Python. The Flask is a micro-framework for Python based on Werkzeug,
Jinja 2 and good intentions. The lightweight and extensible micro architectures 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, while 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 access right
validation on the service provider. The access right validation process is launched after a request
containing the client’s identity is received by the server. Figure 5 shows a block diagram with the
steps to process an authorization request.
1. Check cached token data: After receiving a service request from a user, the service provider
ﬁrstly checks whether or not the token data associated with user’s address exists in the local
26

Fig 5 Access Authorization Process of BlendCAC.
database. If it is failed in searching the token data, the service provider can fetch the token
data from the smart contract through calling an exposed contract method and save token
data to the local database. Otherwise, the token data is directly reloaded from the local
token database for further validation. The service provider regularly synchronizes the local
database with the smart contract to ensure the token data consistence.
2. Verify token status: As a capability token has been converted to the JSON data, the ﬁrst
step of token validation is checking the current capability token status, such as initialized,
isValid, issuedate, and expireddate. If any status of a token is not valid, the authorization
process stops and sends deny access request acknowledgement back to the subject.
3. Check whether access is granted or not: The service provider will go through all access
rules in the access right set to guarantee that the request operation is permitted. The process
checks whether or not the REST-ful method used by the requester matches the authorized
27

action of current access rules and the value of the resource field is the same as the Request-
URI option used by the requester. If the current access rule verification failed, the process
skips to the next access rule for evaluation. If none of the access rules could successfully
pass the verification, the authorization validation process stops and denies the access request.
4. Verify the conditions: Even though the action on a target resource is permitted after the
access validation, the context-awareness constraints are necessary to be evaluated on the
local device by verifying whether or not the specified conditions in the token are satisfied.
The condition verification process goes through all constraints in the condition set to find
the matched ones. If no condition is fulfilled in the given local environment, the access right
validation process stops and denies access request.
5 Experimental Study
In order to evaluate the performance and the overhead of our AC scheme, the identity authen-
tication and access authorization are transcoded to separate smart contracts and enforced on the
experimental web service system. The profiles and policy rules management are developed by
using an embedded SQL database engine, called SQLite.45
The lower memory and computation
cost make the SQLite an ideal database solution to resource constrained system, like Raspberry Pi.
5.1 Testbed Setup
The mining task is performed on a system with stronger computing power, like a laptop or a desk-
top. 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, while all desktops work as fog computing nodes to take role of domain
28

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 the private blockchain network
without mining. All devices use Go-Ethereum46
as the client application to work on the blockchain
network.
Table 1 Conﬁguration of Experimental Nodes.
Node Device Lenovo P50 Dell Optiplex 760 Raspberry Pi 3 Model B
CPU 2.3 GHz Intel Core i7
(8 cores)
3 GHz Intel Core TM
(2 cores)
quad-core ARM Cortex
A53, 1.2GHz
Memory 16GB DDR3 4GB DDR3 1GB SDRAM
Storage 250G SSD+ 500G
HHD
250G HHD 32GB (microSD card)
Operation System Ubuntu 16.04 Ubuntu 16.04 Raspbian GNU/Linux 8
(jessie)
5.2 Experimental Results
To verify the effectiveness of the BlendCAC approach against unauthorized access request, a
service access experiment is carried out on a real network environment to simulate a space net-
work. 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 Rasp-
berry Pi 3 device works as the client and another works as the service provider. The identity
authentication results are shown in Figs. 6 (a)-(b). Figure 6 (a) demonstrates that the node
’0xaa09c6d65908e54bf695748812c51d8f2ceea0f5’ successfully passed the authentication process
executed on the server with the same VZoneID. Figure 6 (b) shows a failed authentication scenario
caused by communicating with entity who belongs to a different virtual trust zone.
29

Given the access authorization process shown in Figs. 6 (c)-(d), when any of the steps in the
authorization procedure is failed, the running process immediately abort instead of continuing to
step through all the authorization stages. As shown by Fig. 6(d), the server stopped the authoriza-
tion process due to the failure in verifying the granted actions or the conditional constraints that are
speciﬁed in the access right list. Consequently, the client node received a deny access notiﬁcation
from the server and cannot read the requested data. In contrast, Fig. 6(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 test scenario, two Raspberry Pi devices are adopted to play the roles of the client and the
service provider respectively. 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. 7, the average total delay time caused by the BlendCAC
operation of retrieving data from the client to server is 250 ms on edge devices. Since the fog nodes
30

Fig 6 Examples of Experimental Results of the BlendCAC System.
have much more computation capacity than the edge nodes do, the execution time of the whole data
querying process on the fog computing node 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 access right 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 edge device, and the same
operation on the fog nodes only needs 10 ms.
31

Fig 7 Computation Time for Each Stage in BlendCAC.
The entire AC process is divided into two steps, identity authentication and capability token
veriﬁcation. 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 access control stage: 63 ms.
The execution time of the AC process is about 214.5 ms (152 + 62.5) on edge, which is accounted
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
32

time is in consistence with the block generation time, which is about 15 seconds 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 8 shows the overall network latency incurred and compares the execution time of the
BlendCAC and a benchmark without any AC enforcement. At the beginning, a long 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, through processing the local cached token
data for authorization validation, the network latency decreases quickly and becomes stable at
a low level during the subsequent service requests. At the satellite edge device, the benchmark
without AC enforcement takes an average of 35 ms for fetching requested data versus that the
BlendCAC consumes on average of 44 ms. It means 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 fog computing 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.
5.3.3 Processing Overhead
The delegation certificate and capability token could be validated only if the related transactions to
the smart contract have been approved by miners and recorded to new blocks. Transaction rate is
proportional to the block generation time, which refers to the time consumed by the miners to verify
new blocks. Table 2 demonstrates the impacts of the number of miners on the blockchain network
as well as estimated financial cost for transactions. In each scenario, sixty blocks are appended
to the blockchain and the average block generation time is calculated. In initial, only two miners
run consensus algorithm. As more miners perform the proof of work, the block generation time
33

Fig 8 Network Latency of BlendCAC.
drops down and finally becomes stable. As shown by Table 2, the optimal number of miners to
get minimum block generation time is 6 in our private blockchain network. As a central part of
the Ethereum network, gas is used to pay for the computing resources consumed by miners. To
evaluate process overhead resulting from gas cost, 100 transactions that assign delegate certificate
and capability are created on the blockchain network, and the average gas cost for each transaction
is 169576.15 Wei (in Ethereum, 1 ether=1.0 × 1018
Wei), which is around $0.22 considered ETC
value during the writing of this paper (September 20, 2018) is 1 ETC = 212.77$.
Table 2 Impact of block generation and financial cost.
Time consumption of block generation
Number of miners 2 3 4 5 6 7
Time (ms) 16.07 15.65 13.58 9.37 7.73 7.95
Estimated financial cost of transaction
Gas (Wei) 159,544.25 ETC Price (USD) 212.77
Transaction fee (ETC) 0.0010853 Transaction fee (USD) 0.22
34

5.4 Discussion
The experimental results demonstrate that the proposed BlendCAC strategy is effective and effi-
cient to protecting the devices and services from an unauthorized access request. Compared to
centralized AC solutions, the BlendCAC scheme has the following advantages:
• Decentralized Architecture: Due to the decentralization provided by the blockchain tech-
nique, the proposed BlendCAC scheme allows masters to control their devices and resources
instead of depending on a centralized third authority to establish the trust relationship with
unknown nodes; thus, the bottleneck effect and the risk of malfunction resulting from cen-
tralized architecture are removed. Even in the worst case that a master is out of service, it has
limited impact on the authentication (apart from adding new nodes to a virtual trust zone).
• Edge Computing Driven Intelligence: Thanks to federated delegation mechanism and blockchain
technology, the BlendCAC framework provides a device-driven AC strategy that is suitable
for the distributed nature of space environment. Through transferring power and intelligence
from the centralized cloud server to the space network edge, smart objects are capable of
protecting their own resources, enforcing privacy, and securing user-defined data content,
which is meaningful to distributive, scalable, heterogeneous, and dynamic space scenarios;
• Fine Granularity: In the BlendCAC system, each entity uses its unique block-chain address
for identity authentication and joins the virtual trust zone, and a capability token is only
assigned to the authenticated entity. It is difficult for attackers to access services by using
fake identities. Enforcing access right validation on local service providers empowers those
smart devices to decide whether or not to grant access to certain services according to the lo-
35

cal environmental conditions. Fine-grained AC with lease privilege access principle prevents
privilege escalation, even if an attacker steals capability token; and
• Lightweight: Compared to XML-based language for AC, such as XACML, JSON is a
lightweight technology that is suitable for resource constrained platforms. Given the ex-
perimental results, our JSON based capability token structure introduces small overhead on
the general performance.
Although the proposed BlendCAC mechanism has demonstrated these attractive features, using
blockchain to enforce AC policy in space systems also incurs new challenges in performance and
security. The transaction rate is associated with conﬁrmation 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 introduces 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 selﬁsh miners, they are able to control the blockchain and reverse
the transactions. Finally, since the blockchain data is open to all nodes joined the blockchain net-
work, 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.
36

6 Conclusions
In this paper, we proposed a partially decentralized capability-based AC framework leveraging
the smart contract and blockchain technology, called BlendCAC, to handle the challenges in AC
strategies for SSA applications. A concept-proof prototype has been built in a SSA emulated phys-
ical network environment to verify the feasibility of the proposed BlendCAC scheme. The identity
authentication scheme and Capability-based access model are transcoded to smart contracts and
work on the private Ethereum blockchain network. The desktops and laptops serve as miners to
maintain the sanctity of transactions recorded on the blockchain, while Raspberry PI devices act
as edge computing nodes to access and to provide services. Extensive experimental studies have
been conducted and the results are encouraging. It validated that the BlendCAC scheme was able
to efficiently and effectively enforce AC authorization and validation in a distributed and trustless
network. This work has demonstrated that our proposed BlendCAC framework is a promising
approach to provide a scalable, fine-grained and lightweight access control for space network ap-
plications.
While the reported work has shown significant potential, there is still a long way towards
a complete decentralized security solution for real-world space scenarios. Deeper insights are
expected. Part of our on-going effort is focused on further exploration of the blockchain based
AC scheme for real-world space imagery access scenarios. Furthermore, designing a efficient
consensus mechanism to address current issues in blockchain, such as lower transaction rate and
51% attack, is another effort to enhance the blockchain network towards reliable SSA applications
of RSO tracking and space weather monitoring.
37

References
1 E. Blasch, M. Pugh, C. Sheaff, et al., “Big data for space situation awareness,” in Sensors
and Systems for Space Applications X, 10196, 1019607, International Society for Optics and
Photonics (2017).
2 P. Wheeler, R. Cobb, C. Hartsﬁeld, et al., “Satellite propulsion spectral signature detection
and analysis through hall effect thruster plume and atmospheric modeling,” in Infrared Sen-
sors, Devices, and Applications VI, 9974, 99740T, International Society for Optics and Pho-
tonics (2016).
3 R. F. Teehan, “Responsive space situation awareness in 2020,” tech. rep., AIR WAR COLL
MAXWELL AFB AL CENTER FOR STRATEGY AND TECHNOLOGY (2007).
4 B. Jia, K. D. Pham, E. Blasch, et al., “Cooperative space object tracking using space-based
optical sensors via consensus-based ﬁlters,” IEEE Transactions on Aerospace and Electronic
Systems 52(4), 1908–1936 (2016).
5 R. Oliva, E. Blasch, and R. Ogan, “Applying aerospace technologies to current issues using
systems engineering: 3rd aess chapter summit,” IEEE Aerospace and Electronic Systems
Magazine 28(2), 34–41 (2013).
6 E. Blasch, K. D. Pham, D. Shen, et al., “Dddas for space applications,” in Sensors and Sys-
tems for Space Applications XI, 10641, 1064108, International Society for Optics and Pho-
tonics (2018).
7 S. P. Chin, “Game-theoretic homological sensor resource management for ssa,” in Sensors
and Systems for Space Applications III, 7330, 73300O, International Society for Optics and
Photonics (2009).
38

8 J. A. Kennewell, B.-N. Vo, et al., “An overview of space situational awareness.,” in FUSION,
1029–1036 (2013).
9 E. Blasch, S. Ravela, and A. Aved, Handbook of Dynamic Data Driven Applications Systems,
Springer (2018).
10 M. Crosby, P. Pattanayak, S. Verma, et al., “Blockchain technology: Beyond bitcoin,” Applied
Innovation 2, 6–10 (2016).
11 S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” (2008).
12 H. Chen, G. Chen, E. Blasch, et al., “Comparison of several space target tracking ﬁlters,”
in Sensors and Systems for Space Applications III, 7330, 73300I, International Society for
Optics and Photonics (2009).
13 W. Faber, S. Chakravorty, and I. Hussein, “A randomized sampling based approach to multi-
object tracking with comparison to homht,,” in IAAS/AIAA Astrodynamics Specialists Con-
ference, (2015).
14 E. Blasch, “Enhanced air operations using jview for an air-ground fused situation awareness
udop,” in Digital Avionics Systems Conference (DASC), 2013 IEEE/AIAA 32nd, 5A5–1, IEEE
(2013).
15 L. Gong, “A secure identity-based capability system,” in Security and Privacy, 1989. Pro-
ceedings., 1989 IEEE Symposium on, 56–63, IEEE (1989).
16 A. Ouaddah, H. Mousannif, A. A. Elkalam, et al., “Access control in the internet of things:
Big challenges and new opportunities,” Computer Networks 112, 237–262 (2017).
17 R. S. Sandhu, E. J. Coyne, H. L. Feinstein, et al., “Role-based access control models,” Com-
puter 29(2), 38–47 (1996).
39

18 P. Samarati and S. C. de Vimercati, “Access control: Policies, models, and mechanisms,”
in International School on Foundations of Security Analysis and Design, 137–196, Springer
(2000).
19 L. M. S. De Souza, P. Spiess, D. Guinard, et al., “Socrades: A web service based shop ﬂoor
integration infrastructure,” in The internet of things, 50–67, Springer (2008).
20 P. Spiess, S. Karnouskos, D. Guinard, et al., “Soa-based integration of the internet of things
in enterprise services,” in Web Services, 2009. ICWS 2009. IEEE International Conference
on, 968–975, IEEE (2009).
21 E. Yuan and J. Tong, “Attributed based access control (abac) for web services,” in Web Ser-
vices, 2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on, (2005).
22 W. W. Smari, P. Clemente, and J.-F. Lalande, “An extended attribute based access control
model with trust and privacy: Application to a collaborative crisis management system,”
Future Generation Computer Systems 31, 147–168 (2014).
23 S. Bhatt, F. Patwa, and R. Sandhu, “Access control model for aws internet of things,” in
International Conference on Network and System Security, 721–736, Springer (2017).
24 N. Ye, Y. Zhu, R.-c. Wang, et al., “An efﬁcient authentication and access control scheme for
perception layer of internet of things,” Applied Mathematics & Information Sciences 8(4),
1617 (2014).
25 J. B. Dennis and E. C. Van Horn, “Programming semantics for multiprogrammed computa-
tions,” Communications of the ACM 9(3), 143–155 (1966).
26 S. Gusmeroli, S. Piccione, and D. Rotondi, “Iot@ work automation middleware system de-
40

sign and architecture,” in Emerging Technologies & Factory Automation (ETFA), 2012 IEEE
17th Conference on, 1–8, IEEE (2012).
27 B. Anggorojati, P. N. Mahalle, N. R. Prasad, et al., “Capability-based access control delega-
tion model on the federated iot network,” in Wireless Personal Multimedia Communications
(WPMC), 2012 15th International Symposium on, 604–608, IEEE (2012).
28 G. Zhang and J. Tian, “An extended role based access control model for the internet of things,”
in Information Networking and Automation (ICINA), 2010 International Conference on, 1,
V1–319, IEEE (2010).
29 J. L. Hern´andez-Ramos, A. J. Jara, L. Marın, et al., “Distributed capability-based access con-
trol for the internet of things,” Journal of Internet Services and Information Security (JISIS)
3(3/4), 1–16 (2013).
30 R. Xu, Y. Chen, E. Blasch, et al., “A federated capability-based access control mechanism for
internet of things (iots),” in Sensors and Systems for Space Applications XI, 10641, 106410U,
International Society for Optics and Photonics (2018).
31 M. Swan, Blockchain: Blueprint for a new economy, ” O’Reilly Media, Inc.” (2015).
32 N. Szabo, “Formalizing and securing relationships on public networks,” First Monday 2(9)
(1997).
33 D. Nagothu, R. Xu, S. Y. Nikouei, et al., “A microservice-enabled architecture for smart
surveillance using blockchain technology,” arXiv preprint arXiv:1807.07487 (2018).
34 S. Y. Nikouei, R. Xu, D. Nagothu, et al., “Real-time index authentication for event-oriented
surveillance video query using blockchain,” arXiv preprint arXiv:1807.06179 (2018).
41

35 R. Xu, X. Lin, Q. Dong, et al., “Constructing trustworthy and safe communities on a
blockchain-enabled social credits system,” arXiv preprint arXiv:1809.01031 (2018).
36 M. T. Hammi, B. Hammi, P. Bellot, et al., “Bubbles of trust: A decentralized blockchain-
based authentication system for iot,” Computers & Security 78, 126–142 (2018).
37 R. Xu, Y. Chen, E. Blasch, et al., “Blendcac: A smart contract enabled decentralized
capability-based access control mechanism for the iot,” Computers 2018, 7(3), 39; Access
on: http://www.mdpi.com/2073-431X/7/3/39 (2018).
38 R. Xu., Y. Chen, E. Blasch, et al., “Blendcac: A blockchain-enabled decentralized capability-
based access control for iots,” in the IEEE International Conference on Blockchain, Selected
Areas in IoT and Blockchain, IEEE (2018).
39 B. Liu, Y. Chen, D. Shen, et al., “An adaptive process-based cloud infrastructure for space
situational awareness applications,” in Sensors and Systems for Space Applications VII, 9085,
90850M, International Society for Optics and Photonics (2014).
40 “Ethereum Homestead Documentation.” http://www.ethdocs.org/en/latest/
index.html.
41 “Solidity.” http://solidity.readthedocs.io/en/latest/.
42 “Trufﬂe.” http://truffleframework.com/docs/.
43 D. Crockford, “Rfc 4627: The application/json media type for javascript object notation
(json), july 2006,” Status: INFORMATIONAL .
44 “Flask: A Pyhon Microframework.” http://flask.pocoo.org/.
45 “SQLite.” https://www.sqlite.org/index.html.
46 “Go-ethereum.” https://ethereum.github.io/go-ethereum/.
42

An Exploration of Blockchain Enabled Decentralized Capability based Access Control Strategy for Space Situation Awareness

More Related Content

What's hot (16)

Similar to An Exploration of Blockchain Enabled Decentralized Capability based Access Control Strategy for Space Situation Awareness (20)

More from eraser Juan José Calderón (20)

Recently uploaded (20)

An Exploration of Blockchain Enabled Decentralized Capability based Access Control Strategy for Space Situation Awareness