Blockchain for multi-domain command and control targeting

To successfully plan and execute today’s complex military operations in defense of a nation’s interests requires timely, accurate, trusted and unambiguous communications up, down, and across an extended chain-of-command spanning multi-national air, ground, sea, space and cyber forces. Blockchain can facilitate and accelerate these multi-domain command and control (MDC2) operations by providing assured, cross-domain digital identities and policy-compliant information sharing for the target planning process.

Trusted targeting-related information can be generated and compliantly shared amongst all members of a targeting team and its supported mission commanders using in combination both a domain-spanning blockchain identification network and a domain-spanning blockchain targeting network to coordinate and control policy-compliant target production and to issue, hold, present, and verify signed credentials asserting participant and target entity attributes.

The problem: Stove-piped targeting people, processes, systems and data

Targeting, as defined in Joint Publication 3-60, is the process of selecting and prioritizing targets and matching the appropriate response to them. It is a multi-disciplinary process, requiring participation from multiple joint force staff elements and components along with numerous nonmilitary agencies to:

  • Decide which targets to engage
  • Decide how best to engage them to achieve the desired effect within political, technical, and operational constraints
  • Detect their current location with sufficient confidence
  • Deliver the appropriate effects
  • Assess the effects of the engagement

The targeting process is severely hampered by multiple stovepipes inherent to its disparate participants — participants from different nations, different organizations, different operational domains (air, space, sea, cyber), using different automated systems operating on different networks with different classification, clearance levels and security policies attempting to generate, share, plan, and act on classified target information.

As described in a previous article, typically, coalition-specific networks and computing infrastructure are stood-up to facilitate communication between co-located joint targeting team members. Appropriately classified information flows into and out of these joint infrastructures in a controlled manner via traditional cross-domain guards connected to each participant’s non-shared national networks. But as I point out in this article regarding cross-domain security, traditional guard solutions suffer a number of drawbacks including lack of trusted end-to-end information provenance for the information exchanged. For mission critical targeting processes, trustworthy source information and decision provenance is vital.

Contributing to a lack of trust is the difficulty providing trusted digital identities for the entities — person and non-person — communicating across domain boundaries. Trusted digital identity is the linchpin for all authentication and authorization decisions and enables other critical security services (non-repudiation, integrity and encryption). Traditional centralized public key infrastructure (PKI) solutions with their domain-specific certification authorities (CA) don’t lend themselves well to cross-domain spanning use cases.

Additional complications arise from the need to protect sensitive identifying information across security domains — the subject identifying information included in CA-issued certificates issued for classified networks can themselves be classified and thus unable to be shared across security domains.

These shortcomings discourage and limit cohesive, coordinated targeting information generation, collection and sharing, preventing the development of a trusted common operational picture of a target and limiting situational awareness of the targeting process itself. All of which combine to increase the potential of developing sub-optimal targeting solutions that could lead to mission failure.

The blockchain-enabled MDC2 targeting solution

Blockchain in conjunction with W3C Verifiable Credentials, can provide a common root of trust that spans these stove-piped MDC2 targeting processes and participants. The proposed blockchain-based solution is composed of three major components:

1. Unclassified multi-domain targeting blockchain consortium

A permissioned, private, unclassified targeting consortium blockchain spanning all participating security domains provides a trusted common operational picture (COP) for the targets and situational awareness (SA) of the targeting process itself. Any proposed change to a target is endorsed and distributed using this targeting blockchain network. Targeting guidance and policies such as target selection standards (TSS) are enforced via smart contracts and endorsement policies.

For example, a target proposed to be added to the high-payoff target list would first require endorsement per the endorsement policy. The endorsers would execute smart contracts using classified input argument values and queries to systems of record to verify that the TSS had been satisfied and generate an unclassified ledger transaction read/write set of approval and other unclassified metadata. The unclassified data would be committed to the targeting consortium blockchain nodes located in all domains and provide immutable provenance of the decision.

2. Classified verifiable credentials and unclassified verifiable presentations

Classified targeting information is assuredly and selectively shared via digitally signed W3C Verifiable Credentials issued to each target entity’s digital identity to assert its targeting-process constructed attributes. A target by JP 3-60 definition is “an entity or object that performs a function for the adversary considered for possible engagement or action”. The MDC2 Targeting process progressively constructs a logical representation of a target entity, populating relevant attributes using various systems and artifacts. These target attributes would be asserted in the form of verifiable credentials.

These verifiable credentials would provide the basis for generating verifiable presentations and zero-knowledge proofs (ZKP) to selectively share appropriately classified information within and across security domains. For example, unclassified verifiable presentations generated from classified credentials asserting high payoff target lists, target selection standards, and commander’s intent/objectives could be shared across lower classification security domain networks.

3. Unclassified multi-domain self-sovereign identity network

A permissioned, public, unclassified blockchain identity network spans all participating domains and provides unclassified trusted digital identities and public key enablement (PKE) for all participating entities (person and non-person) including target entities. Using blockchain-enabled self-sovereign identity (SSI, or decentralized PKI), an unclassified W3C Decentralized Identifier (DID) is assigned to each entity, immutably bound to its public key and other unclassified metadata in its DID document, and distributed via blockchain ledger to all identity network nodes located across all participating security domains without the use of third-party CAs.

Because DID and DID documents are by design intended to contain only unclassified information, they may be freely distributed across security domains via the blockchain identity network thus providing a common all-domain root of trust for digital identity and PKE. DID documents specify a DID’s authentication and authorization mechanisms and also enable discovery and communication with an entity via its blockchain published service endpoints. Service endpoints located on each network domain would provide the means to access an entity’s corresponding classification of verifiable credentials, presentations, and other information.

For example, a target entity would have a service endpoint located on both an unclassified network and classified network. Unclassified information about the target could be obtained from its Unclassified Service Endpoint on the unclassified network. Classified information about the target could be obtained via its Classified Service Endpoint on the classified network. Unclassified verifiable presentations of a classified target attribute would be distributed via cross-domain guard and made available on the unclassified domain via the unclassified service endpoint.

The figure below illustrates how a smart contract on the targeting blockchain enforces target selection standards for a proposed target/weapon system combination:

1. A target team member submits a transaction proposal for a target (identified by its DID) to be considered eligible for attack using a specific weapon system (identified by the weapon system’s DID) to endorsing nodes of the targeting blockchain network.

2. The targeting blockchain network’s chaincode uses the two DID arguments to query the target’s and the weapon system’s service endpoints for the specific information required to enforce the TSS policy.

3. The service endpoints return verifiable presentations of required attributes sharing only the minimum assertions required by the chaincode.

Not shown in the figure, the chaincode validates the verifiable presentation signatures using public keys from the identity ledger keyed to the DIDs, uses the attribute information to validate target eligibility using the chaincode’s business logic, generates an unclassified ledger read/write set with the determination, and returns a signed endorsement. Then, also not shown, the signed endorsements are collected and submitted to the blockchain orderer for distribution throughout the cross-domain targeting blockchain network nodes for commit.

4. The targeting blockchain ledger peer nodes issue notifications upon commit.

5. After receiving a commit notification, the target team member issues a verifiable credential asserting that the target is eligible for attack by that weapon system. The assertion includes the authorizing blockchain transaction ID and other supporting data for complete provenance. The target entity holds this verifiable credential along with all other credentials that have been issued to it asserting its various attributes.

Unclassified verifiable presentations of this classified verifiable credential may be generated and transferred to unclassified domain service endpoints (not shown).

MDC2 Targeting Chart

The value to you

Blockchain-enabled MDC2 Targeting can facilitate, accelerate, and secure MDC2 targeting processes by providing assured, trusted identity and credentials for all targeting entities throughout their lifecycle. Targeting policies are enforced by smart contracts and endorsement policies on a cross-domain targeting consortium blockchain. Targeting information is selectively exchanged across domains via verifiable credentials and verifiable presentations and accessed via same-domain service endpoints.

A separate cross-domain blockchain identity network provides the root of trust for digital identities to PKE all participating entities (person and non-person including targets) in the targeting process who issue, hold, present and verify verifiable credentials and their presentations without spillage of sensitive identifying information.

Together, these solution elements provide the targeting team and their supported mission commanders with a trusted, verifiable end-to-end provenance for all target-related data and policy-based decisions within and across disparate security domains. This blockchain-based solution provides cross-domain, cross-national, cross-functional, cross-organizational targeteers and consumers of targeting information with a trusted common operational picture of each target and its attributes, accurate situational awareness of the targeting process itself, and assured enforcement of targeting and security policies. The operational outcome is an accelerated process with more accurate and effective targeting.

Explore more about how blockchain can be deployed as a MDC2 solution through the IBM Developer.

I look forward to more great conversations on the advantages of blockchain as a MDC2 solution.

Tags