N232-094 TITLE: Blockchain-based, Highly Secure, Decentralized, and Immutable (DSI) Network System Protocol for Multifunction Advanced Data Link (MADL)
OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Advanced Computing and Software;FutureG;Integrated Network Systems-of-Systems
OBJECTIVE: Design and develop a secure blockchain-based system for manned aerial platform air-to-air and air-to-ground secure communication.
DESCRIPTION: The manned aerial platform can share information two ways in combat across radio datalinks and other innovations to pass targeting data, conduct surveillance, and execute attacks; however, there is the problem of detectability by the adversaries. Radio frequencies emit an electronic signature, which can emit a potentially detectable radio frequency signal. Radio interference, jamming attempts, and electronic warfare are all obstacles to maintaining secure and undetected air-to-air and air-to-ground communication.
Another important challenge is the lack of trust between communication networks that can negatively affect the activities and interaction, as well as leading to casualties, security breaches, and other irreversible consequences. To reduce the negative effects and influence of adversarial participants in the network interaction, the Navy requires the development and demonstration of a highly-secured, decentralized, permissionless, and immutable network system protocol to integrate with the manned aerial platform's Multifunction Advanced Data Link (MADL). The network privacy and security can be achieved for air-to-air and air-to-ground networks by mitigating the link attack and detecting malicious nodes, since it can achieve a consensus without introducing a third party.
The main goal of this SBIR topic is to design and develop a low-latency and high-reliability communication blockchain-based network protocol, while taking into account the specifics of the network, the high dynamics of network topology changes and the exchange of large numbers of data.
1. Analyze the indicators of reliability, sustainability, and resource provisioning of the infrastructure facilities of the systems. The solution should maintain and not degrade current standards of bandwidth for IEEE KuBand (e.g., 548 Mbps upload and 1 Gbps download speeds).
2. Design and develop a model for the interaction of the technology in the system to ensure stable and reliable delivery of information, as well as when organizing interaction between objects of mobile edge computing and the infrastructure of the operator�s network core.
3. Design and develop a complex mathematical model of the system, taking into account the interconnection of objects and channels for air-to-air and air-to-ground information transmission.
4. Evaluate performance of the developed framework for heterogeneous scenarios.
PHASE I: Design, develop, and demonstrate a zero trust, blockchain-based, decentralized, permissionless, and immutable network communications method to integrate with the manned aerial platform's MADL that can sustain the minimum data rate of 1 Gbps. Provide simulation and experimental proof-of-concept demonstration on this blockchain-based communication's security relative to that without the blockchain protocol. The Phase I effort will include prototype plans to be developed under Phase II.
PHASE II: Develop, build, demonstrate, and validate a prototype network communications method based on Phase I. Develop a network infrastructure and perform testing to explore the limits of operational reliability and latency. Experimentally demonstrate that the prototype meets or exceeds the performance specifications stated in the Description. Demonstrate the security superiority of this blockchain-based data link quantitatively relative to that of the conventional link without the blockchain protocol. Provide a production cost model.
PHASE III DUAL USE APPLICATIONS: Pursue commercialization of the technologies developed in Phase II for potential government and commercial applications. Government applications include rapid concept development and maturation for emerging military missions. There are potential commercial applications in Private sector use in telecommunication and local, urban communication that would benefit from this game-changing technology due to its blockchain-based, highly secure, decentralized, and immutable network system protocol for multifunction advanced data link.
REFERENCES:
KEYWORDS: Blockchain; Highly Secure; Decentralized; Immutable; Network System; Protocol; Multifunction data link
** TOPIC NOTICE ** |
The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoD 23.2 SBIR BAA. Please see the official DoD Topic website at www.defensesbirsttr.mil/SBIR-STTR/Opportunities/#announcements for any updates. The DoD issued its Navy 23.2 SBIR Topics pre-release on April 19, 2023 which opens to receive proposals on May 17, 2023, and closes June 14, 2023 (12:00pm ET). Direct Contact with Topic Authors: During the pre-release period (April 19, 2023 through May 16, 2023) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. Once DoD begins accepting proposals on May 17, 2023 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period. SITIS Q&A System: After the pre-release period, until May 31, (at 12:00 PM ET), proposers may submit written questions through SITIS (SBIR/STTR Interactive Topic Information System) at www.dodsbirsttr.mil/topics-app/ by logging in and following instructions. In SITIS, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing. Topics Search Engine: Visit the DoD Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoD Components participating in this BAA.
|
| 5/24/23 | Q. | This topic frequently references creating a "permissionless" blockchain solution, but the intent of the topic implies that a "permissioned" solution is more apt to develop a secure blockchain-based system for manned aerial platform air-to-air and air-to-ground secure communication. Why is the direction to create a "permissionless" solution? Can a "permissioned" solution be proposed instead? |
| A. | While there are many different types of blockchains (e.g., centralized, decentralized, permissioned, permissionless, public, private, consortium), this SBIR N232-094 requires the use of your permissionless blockchain solution. Your permissionless blockchain-based solution would allow any distributed Internet of Battlefield Things (IoBT) platform to join and participate within drop-in, drop-out changing battlefield networks. Unquestionably, the feature that makes your proposed permissionless blockchain-based solution so attractive for any drop-in or drop-out IoBT platform is the immutable public ledger that can be contributed to by any IoBT platform. Each data transfer (referred to as transactions) between IoBT platforms is recorded in the ledger, which is publicly viewable. Furthermore, these transactions cannot be altered once they are submitted or removed. There is no IoBT network centralized authority that guarantees the integrity of the transactions; this is instead handled via distributed consensus of the participating IoBT platforms in the blockchain IoBT network using your specific permissionless blockchain-based solution consensus algorithm. Hence, a single IoBT platform alone cannot edit the ledger, shut down the network or alter its protocols are perhaps the biggest advantages of using you permissionless blockchain-based solution in the IoBT networks. Information is not stored in any one central repository, thereby making the public record secure, reliable and accessible to all IoBT platforms. For this reason, your "permissionless" blockchain solution would also be considered virtually unhackable since an attacker would have to attack 51% of the network to override your permissionless blockchain-based solution consensus algorithm. | |
| 5/19/23 | Q. | Besides the required decentralized and immutable network system protocol, does the topic require any proactive defending or monitoring strategies, such as machine learning-based anomaly detection for anti-jamming or false data injection scenarios? |
| A. | a) Packet Delivery Ratio at Various Speeds (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack)
b) Average Network Delay at Various Speeds (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) c) Network Jitter at Various Speeds (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) d) Routing Overhead at Various Speeds (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) e) Packet Delivery Ratio with Varied Node Density (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) f) Packet Delivery Ratio with Varied Pause Time (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) g) Average Network Delay Pause Time (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) h) Network Jitter with Varied Pause Time (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) i) Routing Overhead with Varied Pause Time (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) j) Throughput with Varied Number of Malicious Nodes k) Throughput Available for an Urban Military Operation under Threat l) Average Network Delay with Varied Node Density (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack). m) Network Jitter with Varied Node Density (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack/ Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack). n) Routing Overhead with Varied Node Density (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack/ Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack). o) Packet Delivery Ratio with Varied Network Loading (Black-Hole Attack / Masquerading Attack / Replay Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) p) Average Network Delay with Varied Network Loading (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) q) Network Jitter with Varied Network Loading (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) r) Routing Overhead with Varied Network Loading (Black-Hole Attack / Masquerading Attack / Replay Attack / Quantum Attack / Fork Attack / Eavesdropping Attack / Brute Force Attack / Password Guessing Attack / Known-key Attack) Reference: 1] �Cryptographic support for secure logs on untrusted machines,� in USENIX Security Symposium, San Antonio, USA, Jan 1998. [Online]. Available: https://www.usenix.org/conference/7th-usenix-security-symposium/cryptographic-support-secure-logs-untrusted-machines |
|
| 5/19/23 | Q. | As we know, most communication efficiency systems/applications are constrained and sensitive to the power supply while supporting mission-based needs, including ensuring stable and reliable delivery of information, as well as organizing interaction between the objects of mobile edge computing and the infrastructure of the operator�s network core. Adding cyber-resilient software or hardware embedded (e.g., public key cryptography, PoC algorithm) in aerial platforms would definitely increase the consumption and lifespan of decentralized aircraft nodes. What level of power consumption/system performance increase is acceptable, and any specific quantitative restriction? |
| A. | � Size, Weight and Power and Cost (SWaP-C) � 1) Neuromorphic processing � Intel Loihli hardware, LAVA software; 2) Raspberry Pi 4 Model B boards as edge devices with ZPiE open-source library. ZPiE: Zero-knowledge Proofs in Embedded systems, GitHub, https://github.com/xevisalle/zpie; and 3) NVIDIA Jetson modules
� Interoperable with NSA-approved Commercial Solutions for Classified (CSfC) solutions that use two layers of commercial encryption. � The Inter-Blockchain Communication Protocol (IBC) is a protocol to handle authentication and transport of data between two blockchains. IBC requires a minimal set of functions, specified in the Interchain Standards (ICS). https://github.com/cosmos/ibc |
|
| 5/19/23 | Q. | Since different manned aerial platforms may have different requirements of command-and-control communications, besides the IEEE Ku-band standard, are there any additional requirements of the latency and bandwidth range for two indicated network sub-domains of aircraft? Is there any other network parameter that we should also take into consideration while designing the prototype? Does the prototype require to be performed in real-timely? |
| A. | a) Response Time
b) Transfer Time c) Speed Tests d) Transaction Arrival Rate e) Transaction Speed f) Network Bandwidth- (100%) traffic load, one with 15% extra (115%) traffic load, and one with 30% extra (130%) traffic load. g) Relay Capacity with =89% accuracy 95% of the time IPV6, multicast consensus protocol (consensus algorithms and consensus protocols are interchangeable) |
|
| 5/19/23 | Q. | In our decentralized solution, we�d like to focus on the resource utility estimation, minimal delay of the decentralized platform (e.g., commit transaction time, chain finality time), plus some security analysis (e.g., data integrity percentage, attack identification rate/time). Are these evaluation metrics within the scope of this topic? Or any other preferred analytics/metrics of system quantity and security-related characteristics to evaluate? |
| A. | a) Packet Delivery Ratio at Various Speeds (1000 transactions/sec)
b) Average Network Delay at Various Speeds (1000 transactions/sec) c) Network Jitter at Various Speeds (1000 transactions/sec) d) Routing Overhead at Various Speeds (1000 transactions/sec) e) Packet Delivery Ratio with Varied Node Density (20-100 nodes per area) f) Average Network Delay with Varied Node Density (20-100 nodes per area) g) Network Jitter with Varied Node Density (20-100 nodes per area h) Routing Overhead with VariedNode Density (20-100 nodes per area) i) Packet Delivery Ratio with Varied Network Loading (5-30 connections). j) Average Network Delay with Varied Network Loading (5-30 connections) k) Network Jitter with Varied Network Loading (5-30 connections) l) Routing Overhead with Varied Network Loading (5-30 connections) m) Packet Delivery Ratio with Varied Pause Time (5-30 seconds) n) Average Network Delay with Varied Pause Time (5-30 seconds) o) Network Jitter with Varied Pause Time (5-30 seconds) p) Routing Overhead with Varied Pause Time (5-30 seconds) q) Throughput Available for an Urban Military Operation |
|
| 5/19/23 | Q. | From decentralized microservices� perspectives, different aircraft platforms or functionalities (e.g., command and control collaboration, radiolocation updating) may require different types of encryption strategies and distributive databases to achieve consensus among the participated inter-system nodes. So, does this topic requires an All-in-One blockchain-based engine to satisfy all types of the communications (such as text, voice, or video)? Any specific service (e.g., voice data communication) is preferred in this Phase I work? |
| A. | Response exceeds the character limit for this application. Extended response is available at https://navysbir.com/n23_2/n232-094-QA2-ext.pdf | |
| 5/19/23 | Q. | As this topic mentioned, the proposed decentralized platform should have the capacity of securing and improving the performance of low-latency and high-reliability communication for MADL in air-to-air and air-to-ground scenarios. As we understand, MADL is a Ku-band-based fast-switching narrow directional communications data link between stealth aircraft (e.g., F-35). Since we may not have the real-world MADL data from a mature military aerial platform (e.g., F-35, F-22 Raptors, or fourth-generation aircraft) in the Phase I period, will it be accepted for a simulated Ku-band signal data as a starting point for the decentralized security analysis? |
| A. | Much of the performance and specification details of the Multifunction Advanced Data Link (MADL) system are classified.
For MADL, the privacy of aircraft track histories is mandatory and only accessible to authorized entities. Naval aircraft data is controlled, classified information, and confidentiality is required for data accessing and sharing during Air Traffic Service (ATS) operations.
The Multifunction Advanced Data Link (MADL) was originally developed as the intra/inter-flight data link for the F-35 Program. MADL uses line-of-sight communications between pairs of airplanes using a Ku-band based fast switching narrow directional communications data link between aircraft. At any given instant, half of the aircraft are transmitting and half of the aircraft are receiving. In the first slot of any given time frame, any particular transmitting aircraft A is sending a narrow beam of information to only one other receiving aircraft, B. In the second slot of that same time frame, B will transmit over a narrow beam back to A. In the next frame, partners are changed: A may now form a beam towards aircraft C, B may now be receiving a signal from aircraft D. Each aircraft will cycle through some small number of partners, and then repeat the cycle indefinitely. A Blockchain-enabled decentralized microservices framework for MADL should be proposed to secure flight data accessing and sharing among aircraft and Air Traffic Service (ATS) providers, based on your blockchain like solution and microservices technologies in a hierarchical edge-fog-cloud computing paradigm:
|
|
| 5/9/23 | Q. | 1. Are there any hardware or software limitations specific to the manned aerial platforms that we should consider when developing the blockchain-based communication protocol?
2. Could you provide information on the current encryption and security standards employed for MADL? Should our proposed blockchain-based solution align with these existing standards, or do you have additional requirements to establish a zero trust environment? 3. What are the expected operating conditions for the manned aerial platforms, such as altitude, distance from ground stations, and geographic locations, that may impact the performance of the communication protocol? 4. Could you provide information on the specific data types and formats that the communication protocol should support? Are there any requirements concerning data prioritization or quality of service that we should consider? 5. Are there any regulatory or compliance requirements that our blockchain-based solution must adhere to, particularly in the context of a zero trust approach? 6. Do you have any preferred programming languages, development platforms, or tools that you would like us to use for implementing the proposed solution? |
| A. | Extended response is available at navysbir.com/n23_2/n232-094-QA-ext.pdf | |
| 5/1/23 | Q. | As a true blockchain network is very expensive to operate, with many other disadvantages, such as high latency, high use of computation power ( thus energy ),
and involvement of many nodes, is it necessary to use a "standard" or "typical" blockchain in this program or just the concept? We have a better solution: similar to blockchain in terms of large-scale, distributed, multi-nodes, mesh network. However, It is different from blockchain where we use more efficient distributed and reliable protocols than "standard" blockchains. We have PoC that demonstrated secure, low-latency, and high-reliability communication. We can meet "zero trust, decentralized, permissionless, and immutable network communications" those requirements but it is not "standard blockchain-based", Would you consider a "blockchain-like" solution? |
| A. | Yes. Provided your "blockchain-like" solution includes: 1) A zero trust, decentralized, permissionless, and immutable network communications method to integrate with the manned aerial platform's MADL that can sustain the minimum data rate of 1 Gbps; 2) An adversary observing a protocol exchange cannot learn anything about the value of the secret physically unclonable functions (PUFs) response, even if the adversary knows the value of the public key n; 3) An adversary cannot determine whether a node it currently holds was a part of any past or future protocol exchange it has recorded, even if the adversary knows the value of the node�s PUF response; 4) The adversary cannot determine whether a certain public key n was used in the protocol exchange; 5) A successful protocol execution serves as an implicit way of authenticating the veri?er. This lets the two parties create a secure data channel; and 6) An adversary cannot break the forward and backward privacy property. | |
| 4/26/23 | Q. | Are blockchain solutions exclusively considered to address the challenges identified under this topic? |
| A. | Yes. The main goal of this SBIR topic is to design and develop a low-latency and high-reliability communication blockchain-based network protocol, while taking into account the specifics of the network, the high dynamics of network topology changes and the exchange of large numbers of data. This SBIR is requesting a zero trust, blockchain-based, decentralized, permissionless, and immutable network communications method to integrate with the manned aerial platform's MADL that can sustain the minimum data rate of 1 Gbps. |