Is it possible to generate highly secure IPv6 addresses quickly and without using a trusted central authority?

Yes, according to nChain blockchain researcher Mathieu Ducroux. It’s done by leveraging the proof-of-work (POW) on the Bitcoin network to bind a host’s IPv6 address to a Bitcoin public key, verifying identity while protecting addresses against spoofing attacks and maintaining privacy.

Ducroux presented his research paper, “IPv6 Bitcoin-Certified Addresses” (BCA), at the IEEE Future Networks World Forum last November in Baltimore. The paper and its ideas generated a lot of conversation among networking specialists both at the event and online.

The full paper is available for viewing and free download here, and it includes more technical details on how BCA is done.

The security/convenience tradeoff in IPv6 CGAs

“A well-known challenge in networking is the ability for hosts to generate their own address and verify those of others, without relying on a trusted authority,” Ducroux wrote in a LinkedIn post. “Compared to existing proposals, our solution is very lightweight, has no single point of failure, and provides strong security and privacy for hosts.”

One of IPv6’s built-in security features is Cryptographically Generated Addresses (CGAs). CGAs allow users to generate unique addresses from their (non-Bitcoin) public key, enhancing security and simplifying identity verification. They’re also useful for mobile device users since devices can continue receiving data even when moving between mobile networks.

CGAs come at a cost, though. The addresses must be generated by hashing the host’s public key and auxiliary parameters (depending on the level of security desired) using SHA-1 and the Secure Neighbor Discovery (SEND) protocol. This requires both time and computational resources to achieve, from a few seconds for a low-security parameter to several minutes for a higher one.

“The issue with CGA is that it trades security for performance without being able to offer a good balance between the two,” Ducroux wrote. “Additionally, the high computational cost of CGA generation disincentivizes hosts from changing their address frequently, which exposes them to privacy-related attacks.”

Users can get around this issue by using a trusted third-party authority to generate CGAs or by generating secure addresses before use. With BCA, this process is decentralized, doesn’t require third parties, and can work in real time.

Using Bitcoin’s POW, i.e., BCA, nChain demonstrated a technique that generated high-security IPv6 addresses in 0.0001 milliseconds, something that would have taken over 10 minutes using existing CGA methods for the same level of security.

nChain developed BCA prototypes and demos

Speaking to CoinGeek, Ducroux said nChain has implemented the BCA technique as a working prototype on the BSV blockchain. The Bitcoin R&D firm also filed a patent application for its process in February 2023.

Choosing the right blockchain to generate secure addresses is critical, he added.

“There are two factors to take into account when choosing the right blockchain to use in BCA. The first one is scalability. If we want all (IoT) devices to be able to generate their IPv6 addresses using BCA, our calculations showed that we need a blockchain that can sustain at least 10,000 transactions per second. Only BSV is designed to handle such a volume.”

Transaction costs are also a factor since they directly impact the cost of generating BCAs.

“This cost should be negligible for all users, ideally in the order of a fraction of a cent. Again, BSV is ideally suited to meet this requirement. Our prototype showed that it would cost only 0.04 cents of USD to generate 32,000 IPv6 addresses in BSV, which is enough addresses for the whole life of any standard device.”

Verifying a generated address with BCA is also straightforward, Ducroux said, as it only requires performing a hash computation. In addition, a blockchain that can store extra data can preserve internet certificates that identify devices.

Online discussion surrounding Ducroux’s paper noted that, while it isn’t specifically necessary to use BSV to bind a blockchain address to an IPv6 one using BCA, the above advantages (scalability, cost, data storage) would become important when implementing it.

“I predict that protocols like these will far outnumber Bitcoin’s financial use cases, to the point where people will stop thinking of it as only a financial payment system,” wrote Jason Lowery, Astronautical Engineer at the U.S. Space Force. “It is undeniably true that computer scientists are already learning to leverage Bitcoin as a reusable proof-of-work network, NOT a monetary/digital gold network.”

Ducroux added that nChain’s team has developed other methods to make IPv6 more useful when integrated with Bitcoin/BSV. These include an IP-to-IP payment demonstration, which later integrated BCA and was included in nChain’s presentation at the CCIOT conference in Okinawa last September.

Watch: Multicast & IPv6—here’s how they apply to Bitcoin

YouTube video

New to blockchain? Check out CoinGeek’s Blockchain for Beginners section, the ultimate resource guide to learn more about blockchain technology.

Thank you for engaging with us at SmartLedger through 'Secure, self-generated IPv6 addresses in split second using Bitcoin proof of work' - https://smartledger.solutions/secure-self-generated-ipv6-addresses-in-split-second-using-bitcoin-proof-of-work/. We hope you found the insights valuable.

For more thought leadership and updates, delve deeper into our resources and stay ahead with the latest innovations.

 

This post was originally published on this source site: this site

image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog
image-blog