Technology Sharing: "Garbage In and Garbage Out" of Blockchain Technology

secondary title

Previously, we wrote an article introducing "the value that blockchain technology brings to different types of data", that is, the ability of blockchain to guarantee the source, immutability and authenticity of different data. In this article, we will continue to answer another question that is often (intentionally) ignored: how data interacts with the blockchain. Like so many other systems, blockchain technology is suffering from "garbage in, garbage out" (GIGO).

lie to the blockchain

previously postedpreviously postedArticles about data

In this study, we found that blockchain systems cannot ensure the authenticity of non-blockchain-natively generated and non-publicly available data, which unfortunately is the vast majority of such data globally. So, if someone (some device) submits fraudulent data to the blockchain, we can't be sure of its authenticity at all, and the result is that you keep submitting fake data to the blockchain history. So, you put the garbage on the chain, and the blockchain will return your garbage.

It is reported that there are many applications that ignore this problem nowadays, and usually they will add some technical layers to ensure the correctness of the data. Here are a few cases:Decentralized data market: use tokens to encourage companies to list and sell data——

How do you know the data you buy is real?Privacy Preserving Query: This service counts the number of HNWIs in a bank through a zero-knowledge range proof, so you can harvest a number without the bank submitting any customer data —

So how do you make sure the bank didn't falsify the entire customer database?

For publicly available data, you could design a game where players with bankrolls at risk challenge the authenticity of other players' data, much like Chainlink has designed. But as we said before, the vast majority of the world's data is not publicly available.Secure data at the source.

secondary title

Ensure the security of data sources

If we do not obtain data from the source, but through a third party or intermediary, then without trusting the intermediary, the authenticity of the data will no longer be credible. The more intermediaries involved in data management, the more you have to believe it, but if the number of intermediaries is large enough, the data may be generated by a random number generator.

• So, our goal is to get the data as close to the source as possible. For example:

• Instead of getting sales data from a retailer's database, start with point-of-sale hardware;

• Instead of subscribing to the weather forecast on the website, it is better to focus on the weather sensors that collect data;

But how to ensure data security from the source? Since most of the data in the world is generated or captured by devices, we can also describe this problem here as how to protect the data generated by devices. Now, we are faced with three potential points of failure:

• identity:identity:

• How do you know what device is generating data? Is it the temperature sensor you expected? Or a random number generator for a perpetrator?Processing and Transmission:

• Even if the source of the data is authentic and identifiable, how do you know that this data has not been altered, corrupted, or directly replaced during processing and transmission by the device (such as from a sensor to a communication module)?Digital/Analog Interface:

Let's solve these problems one by one.

a practical approach

• identity:

identity:

In order to ensure that the identity of the device that generates the data is protected, we can embed a set of public and private keys on the device, let the public key know and check the output of the actual device on site. This is a practical way to ensure that there is no problem with the identity of the hardware. —Of course, this is a relatively simple step.

• The tricky part is, how do you make sure this identity isn't stolen or only known to the device? A hardware module called "Secure Element" (Secure Element, SE) can be used here, which can generate a public-private key pair on the chip and is highly tamper-proof. Normally, this security module does only one thing: sign messages. - This is a great way to provide proof of identity. If you've ever held a credit card, or used a modern smartphone, you've already enjoyed the benefits of this element of security.
  

Processing and Transmission:

To secure the data processing and transmission logic, we employ a microcontroller (MCU) with a secure boot program (SB). You can think of the microcontroller here as a super simple computer.

SB ensures that only entities with the correct private key can load the application into the MCU. Instead, the application logic and associated validation can be shared with stakeholders in advance (or directly open-sourced), so that it can be validated after loading.

Next, and more critically, after the application has been thoroughly tested, we need to disable all modifications on the application and the MCU. This is to ensure that the logic of the application is completely immutable from now on, not even by the manufacturer.

• This solution also has some obvious disadvantages, such as the application cannot be updated afterward. But in contrast, we have obtained true device independence (combined with SE) without external interference, and have perfect determinism and immutability enough for us to trust.

Digital/Analog Interface

This problem is more difficult and cannot be solved by hardware embedded in the data acquisition and relay equipment. Often, innovative mechanisms must be devised to ensure that the interface is not interrupted, but this depends on each application. Let's take an example.

Suppose you have a refrigerated truck that serves a cold chain logistics company, and your daily job is to deliver fresh fish to local supermarkets. In order to keep fresh, fish must be kept within a certain temperature range. If the temperature is too high, the fish will deteriorate; if the temperature is too low, the taste and meat quality of the fish will deteriorate. To confirm that the logistics company complies with the contracted temperature range, the supermarket installs a temperature sensor on the truck.

But what if a truck driver turns up the temperature on his refrigeration unit to save money on electricity, and then removes the sensor and puts it in a cooler in the front of the vehicle? The sensor will never know that it has been moved, but continues to collect and report data that is constant within the contracted temperature range. That is, the sensor is tricked.

One way to mitigate this risk is to make the sensor also hardwired into the cooling unit, making it nearly impossible to remove it. However, this countermeasure can still be circumvented in some way, such as wrapping a bag of ice around the sensor, while the rest of the truck is still hotter than contracted.

Another, possibly better (and slightly more expensive) solution is to put a tamper-resistant seal on each pack of fish and put a temperature sensor on each pack. This way, if the driver wants to disassemble the temperature sensor, he has to tear the seal, which can easily be found to be in breach of a key clause of the contract.