Keywords

1 Introduction

The emergence of the cloud, network functional virtualisation (NFV), edge computing and IoT paradigms has necessitated the accountable collection of distributed logs and audit information over multiple administrative domains or trust realms and across service provision paths in complex ICT supply networks. There is an ever increasing need to develop scalable technologies that ensure the integrity of such critical information (log, audit data, etc.) to enforce accountability and non-repudiation while taking into account the scope of use of the corresponding services, network functions or devices.

Blockchains and other forms of distributed ledgers (the underlying technologies of the Bitcoin [1] cryptocurrency, Ethereum [2] and other applications including cryptocurrencies [3,4,5,6,7,8,9,10,11]) offer cryptographic irreversibility of recorded data agreed upon by consensus amongst a set of decentralised entities. This property is useful for reliably logging event information generated by virtualised functions with short-lived, stateless and on-demand instances that reside on cloud infrastructures. Industry verticals, such as financial services, telecommunications, energy and smart vehicles – to name a few – are looking into distributed ledger technologies (including but not restricted to blockchains) for improving the integrity and availability of their services, their cross-service data flow and secure information sharing.

1.1 Objectives

In this paper, we consider the application scenario of a firewall as a virtual network function (VNF) and demonstrate how blockchains can be utilised to design and implement the distributed event log architecture. Our main objectives in this context are:

  1. (1)

    to protect the integrity and confidentiality of important information of VNFs and IoT gateways such as events, configurations, policies, credentials, and so on;

  2. (2)

    to strengthen the authenticity, accountability and integrity of security policies, security capabilities and VNF and IoT gateways;

  3. (3)

    to reduce the risks of impersonation and privileged access abuse;

  4. (4)

    to reduce the difficulties of cryptographic key management, revocation and trust management complexities; and

  5. (5)

    to assess suitability and potential benefit of leveraging emerging technologies for multi-ledger and smart-contracts.

In this work-in-progress short paper, we consider the application scenario of a firewall as a VNF and demonstrate how a dual blockchain framework can be utilised to design and implement the distributed event log architecture. In general terms, we develop a multi-ledger model that protects the integrity of key information in a large-scale distributed computing systems and assures authenticity and accountability of modifications.

2 Proposed Dual Blockchain Framework

Use-Case Scenario Overview. A virtualised network function (VNF) is a software code, an instance of which can run inside a virtual machine, on top of actual physical hardware. A distributed stateless firewall abstracted as a firewall VNF can have multiple, possibly geographically dispersed, instances that can be spun up on demand. Each such instance logs events and incidents that it “sees”. These logs need to be cryptographically signed to preserve their integrity. However, due to the short-lived and volatile lifespans of such VNF instances, maintaining and sharing signing keys between all instances of the same VNF is challenging even when there are separate keys per domain.

Fig. 1.
figure 1

Event log report structure.

Full size image

In [12], we proposed a preliminary direction for accountability and integrity of data management making use of blockchains. In this paper, we describe an architecture for VNF logs that are verifiable in terms of integrity and authenticity. We propose the use of two blockchains for two separate purposes. The first blockchain is a permissioned blockchain used to verify the integrity of the data logged by individual firewall instances (called the i-Ledger from now on) while the second public blockchain helps with the verification of the authenticity of the logged data (called the a-Ledger hereafter). Due to the public nature of the second blockchain, the actual event log data is either not stored in it or stored with some confidentiality-preserving transformation (e.g., keyed hash, encryption). These two blockchains are not necessarily linked in terms of actual connectivity between nodes, but are semantically ‘linked’ during the data verification process since data on one blockchain needs to be cross-checked with the information recorded in the other to help verify consistency.

2.1 Event Log Reports

Central to the idea of the blockchain for integrity is the way a VNF instance generates an event log report. The events considered in this log are typically security incidents, but we use the general terminology – events – throughout this paper. The individual events are added as leaf nodes to a hash tree, e.g., a Merkle Tree [13]. The level of granularity of the events is configurable, i.e., a VNF may wish to combine multiple events together instead of writing one event as one leaf of the Merkle Tree. While for the rest of the paper we stick to Merkle Trees for the property of independent verification of sub-trees, any generalised hash tree satisfying the same property will suffice. The root of the Merkle Tree along with the entire tree structure is what constitutes a complete event log report, as illustrated in Fig. 1. The actual event data on the leaf nodes can be privacy sensitive. Information from hash trees can be trimmed, similar to the delete operation in our existing work – VIGraph [14], which uses generalised hash trees for selective disclosure of information.

2.2 System Overview

Figure 2 describes the overall system using a multi-domain scenario for the two blockchains involving three domains as well as an external notary. The blue lines indicate the topology of the i-Ledger whereas the red lines represent that of the a-Ledger. The domain on the left illustrates some of the actors in one organisational domain, such as the entities (VNFs in this case) that generate events and event log reports; the Life-cycle Event Manager (LEM) which generates events related to the life-cycle of entities; the log manager in charge of maintaining the i-Ledger and the notary in charge of maintaining the a-Ledger. The Domain security manager is responsible for controlling confidential data sharing policies and agreements, which we discuss later. The Auditor is responsible for cross-verifying the integrity and authenticity of events across the two blockchains.

Fig. 2.
figure 2

A multi-domain system overview. (Color figure online)

Full size image

2.3 Blockchain for Integrity – the i-Ledger

The purpose of verifying the integrity of a data log is to ensure the signature on the log is valid, and that the signing entity is an authorised entity, i.e., an authorised firewall instance, in our running use-case. With the traditional certificate authority (CA) based keys, a CA signs the public key of an entity. However, the traditional CA style architecture requires the presence of a centralised and trusted certificate authority. It also assumes the existence of long-lived public-private key pairs. Neither of these hold true in our architecture of the distributed VNFs spanning across organisations.

A VNF instance generates an ephemeral private key (could remain stored only in volatile memory), which is removed when the VNF instance spins down gracefully or crashes. The corresponding public key, however, lives on. In our architecture, each separate administrative domain has its own key manager and log manager. Either the log manager or the life-cycle event manager may provide the key management functionality, and thus we do not specify a key manager separately. This key-pair can be generated based on a Hardware Security Module or a Trusted Platform Module (HSM/TPM) backed seed, and the public key is registered with the key manager. A VNF instance collates its logs in a report (Fig. 1), adds a monotonically increasing numeric identifier and signs the Merkle Tree root and the numeric ID. This constitutes the main information for the block of varying size in this blockchain, illustrated in Fig. 3, with the event data in green signifying privacy sensitive information.

Fig. 3.
figure 3

Block structure for event log reports in i-Ledger. (Color figure online)

Full size image
Fig. 4.
figure 4

Operation of the i-Ledger.

Full size image

Due to the short-lived and resource-constrained nature of the VNF, it does not participate directly in reading from or writing to the blockchain. That task is delegated to the log manager of the domain. The pointer to the previous block and the block ID are, in turn, signed by the log manager that acts as a domain attester. The log managers across all the domains maintain the i-Ledger. The entire operation of the i-Ledger is shown in Fig. 4, involving three actors:

  1. (a)

    generating entity in the active domain (Domain A);

  2. (b)

    the active domain log manager; and

  3. (c)

    any other domain (Domain B) log manager.

A log manager runs a smart contract on the event log report before it accepts the block. Each log manager in each domain knows the identity (i.e., public key) of every other participating log manager from every other domain. Thus, the smart contract running on the log managers conceptually looks like the one illustrated in Fig. 5, encapsulated as the “Execute smart contracts” state in Fig. 4. The active domain contains the entity (i.e., VNF instance) that is attempting to write the report to the blockchain while the passive domain contains the log manager that accepts the event log report based on the acceptance of the valid identity of the active domain log manager.

Fig. 5.
figure 5

Smart contracts in the i-Ledger.

Full size image
Fig. 6.
figure 6

Operation of the a-Ledger.

Full size image

Confidential Information Sharing. The event data in the event log report could be considered privacy sensitive across different domains. Hence, if such an event log report is to be shared across domains, the leaf nodes are either removed from the tree structure while keeping their hashed parents intact; or the leaf nodes go through some confidentiality preserving transformation, e.g., symmetric key encryption where the relevant key is shared with authorised entities; or it could be attribute based encryption (ABE) where relevant entities have their access control policies defined in the ABE structure, in the keys (KP-APE) or in the ciphertexts (CP-ABE). This type of confidential information sharing policy is controlled the domain security manager as illustrated in Fig. 2.

2.4 Blockchain for Authenticity – the a-Ledger

The purpose of verifying the authenticity of the data log is to ensure that the publicly recorded log of the data (without details of the actual data to preserve confidentiality) corresponds to an actually recorded log in the i-Ledger that verifies it integrity. It also ensures that logs made by the same entity can be linked and their partial orders validated. Furthermore, with the records of life-cycle events, the a-Ledger allows a verifier to check that a specific log made by a specific VNF instance happened while it was active.

Fig. 7.
figure 7

Smart contracts in the a-Ledger.

Full size image

The entities maintaining this public a-Ledger are notaries that can exist in the aforementioned domains, but also in other unrelated domains, as shown in Fig. 2. For instance, the VNF use-case could exist in domains such as telecommunications carriers while notaries could exist in other external domains such as financial and legal institutions. Unlike the permissioned i-Ledger, the block in this a-Ledger is not equivalent to a single event log report. Instead, blocks in this blockchain contain single events from the event log report as well as entity life-cycle events. Any such event is recorded as a transaction and many such transactions form a block in this blockchain. In order to facilitate life-cycle event reporting, we have the life-cycle manager per domain, which is typically a virtual machine monitor that knows when a VNF instance is up or down.

The transaction for an event (i.e.., VNF generated event) is a tuple consisting of:

  1. (a)

    a specific event, E;

  2. (b)

    the monotonically increasing numeric identifier for the event specific to the generating entity, \(n_t\) at time t; and

  3. (c)

    the signature from the generating entity, \(sig_{entity}\).

The transaction for a life-cycle log is a tuple consisting of:

  1. (a)

    the life-cycle event (LE) to be recorded, e.g., \(LE_{start}\), \(LE_{end}\) and so on;

  2. (b)

    the public key of the entity whose life-cycle event is being recorded, i.e., \(pubK_{entity}\); and

  3. (c)

    the signature from the life-cycle manager, i.e., \(sig_{LEM}\).

The entire operation of the a-Ledger is shown in Fig. 6, involving three actors:

  1. (a)

    generating entity;

  2. (b)

    a notary in any domain; and

  3. (c)

    the life-cycle manager in the same domain as the generating entity.

The notaries run two smart contracts depending on the type of event being added, as shown in Fig. 7, encapsulated as the “Execute smart contracts” state in Fig. 6. To check the validity of the signature of a life-cycle manager, it is imperative that notaries know and store the identities of each life-cycle manager for every domain.

3 Related Work

Bozic et al. [15] present an on-going work on a blockchain-based mechanism to protect cloud and NFV orchestration operations, specifically the authentication of orchestration commands in the lifecycles of cloud services. The scheme proposed in [16] helps ensure the necessary integrity and confidentiality properties application provenance in a cloud environment. Rübsamen et al. presented, in [17], a system that uses distributed software agents for secure evidence collection to enable automated evaluation during cloud accountability audits. In [18], Redfield and Date proposed a system where data is signed on the device that generates it, transmitted from multiple sources to a server using a signature scheme, and stored with its signature on a database running a protocol for long-term archival systems that maintains the data integrity of the signature even over the course of changing cryptographic practices. Sanz et al. [19] proposed a framework for automatic performance evaluation of service function chaining in network function virtualisation. The paper in [20] described the idea of securing drone data collection and communication with a public blockchain for provisioning data integrity and cloud auditing. In [21], authors proposed an architecture to secure federated cloud networks by enforcing a global security policy on all network segments of a federation, and local security policies on each network of the federation. In the context of the IEC 61499 standard [22] for distributed control systems, the work in [23] proposed an ongoing research on the implementation of function blocks as smart contracts executed by a blockchain as well as the integration with the edge nodes that are responsible for process control. The work in [24] adopted blockchains to address the lack-of-trust problem by mapping a business process onto a peer-to-peer execution infrastructure that stores transactions in a blockchain. Amongst the various benefits of their approach, an audit trail for the complete collaborative business processes, for which payments, escrow, and conflict resolution can be enforced automatically. The authors presented the idea of using blockchain as a service for IoT and evaluates the performance of a cloud and edge hosted blockchain implementation in [25]. In [26], the authors proposed a blockchain-based architecture for the secure configuration management of virtualised network functions (VNFs), which provides immutability, non-repudiation, and auditability of the configuration update history as well as integrity and consistency of stored information; and the anonymity of VNFs, tenants, and configuration information. Authors in [27] presented an architecture of a collaborative mechanism using smart contracts to investigate the possibility of mitigating a DDoS attack in a fully decentralized manner whereby the service providers can not only signal the occurrence of attacks but also share detection and mitigation mechanisms. Xu et al. [28] proposed a blockchain-based solution for trust in virtual machine images to reduce the risk of DoS attacks and at the same time provide a signature verification service for Docker images. Kouzinopoulos et al. discussed, in [29], the benefits of using blockchains to strengthen the security of IoT networks through a resilient, decentralized mechanism for connected home use-case that enhances the network self-defense by safeguarding critical security-related data. Kataoka et al. presented [30] a ‘trust list’, which describes the distribution of trust among IoT-related stakeholders and provides autonomous enforcement of IoT traffic management at the edge networks by integrating blockchains and Software-Defined Networking (SDN). This, according to the authors, helps automating the process of doubting, verifying, and trusting IoT services and devices to effectively prevent attacks and abuses.

4 Conclusions and Future Work

The work-in-progress short paper presented a preliminary concept regarding the use of blockchains to provide accountability of events. Our running example use-case has been virtual firewalls instances as VNFs, but this architecture can be extended to other use cases with similar short-lived entities, e.g., various IoT and connect car scenarios. A number of avenues for future work exist, which include but are not limited to:

  1. (i)

    validating the proposed architecture with a proof-of-concept on blockchains with an abstraction for the virtual network functions;

  2. (ii)

    fully adopting a thorough security controls architecture utilising controls from the CSA Cloud Controls Matrix (e.g., CCM v3.0)Footnote 1 in order to build an actual working example of cloud-based virtual network functions with the proposed event logging architecture implemented on the two blockchains; and

  3. (iii)

    investigating the use of post-quantum signature schemes, e.g., Lamport or Merkle in the event log reports because their hash-tree like structures lend themselves well to such signatures.