Offline Data Verification of Blockchain for IoT Devices

[kanad]

TLDR:

• The Internet of Things (IoT) needs data security at three critical points: point of generation, storage and usage. This paper proposes Secure Element and Blockchain based Stratagem (SEBS) as a method of securing all three points.
• When implementing SEBS or in other scenarios where Blockchain is used as Service, remote resource constrained devices cannot directly communicate with the blockchain, so an intermediary is required to receive data from the blockchain and trigger actions based on it.
• This is an issue since placing trust on the intermediary becomes imperative.
• The proposed algorithm called Secure Element based Offline Verification Algorithm (SEOVA) solves this issue with a double signature algorithm implemented using a secure element. SEOVA allows offline verification of blockchain data. Using SEOVA, a remote constrained device is able to verify blockchain data without placing trust on the intermediary or connecting to the blockchain.

Core Research Question:

How do you verify if data received through an intermediary by a remote IoT device really belongs on or comes from the blockchain?

Citation:

V. Deshpande, T. Das, H. Badis and L. George, “SEBS: A Secure Element and Blockchain Stratagem for Securing IoT,” 2019 Global Information Infrastructure and Networking Symposium (GIIS), Paris, France, 2019, pp. 1-7, doi: 10.1109/GIIS48668.2019.9044957.

Background:

Figure 1: A typical IoT ecosystem secured by blockchain (as a service)

• In the context of IoT, a reliable automatic decision with high accuracy can be taken only if the sensor data is secured at 1. generation 2. storage and 3. usage.
• This is a tricky task as IoT devices/sensors are constrained with limited processing power, memory, battery autonomy, storage, etc.
• Further, in the IoT domain, the environment is completely heterogeneous making it extremely difficult to implement a single security protocol across all remote entities.
• Nonetheless, the problem has been solved partially with the effective use of blockchain as secure and persistent storage for critical IoT data.
• Given the overhead of the blockchain, in most of the IoT scenarios, blockchain is used as a service (BaaS)
• Thus for Remote IoT Devices (RID), the data requested from blockchain is transmitted, in most cases, through an intermediary. (See Figure 1).
• This makes trusting the intermediary mandatory since there is no way for the RID to verify the data and its authenticity without directly connecting to the blockchain.
• Another issue is RIDs lack resources to carry out cryptography-intensive tasks apart from the obvious incapability of being able to connect to the blockchain directly.
• Furthermore, a list of all miner/verifier nodes has to be maintained and continuously updated via a secure channel for undertaking the traditional online blockchain data verification procedure.

Summary:

• Secure Element based Offline Verification Algorithm (SEOVA) is a novel algorithm to test Blockchain data affiliation i.e. to determine if the data coming from Blockchain through an intermediary (like in case of BaaS, RIDs), really belongs to the Blockchain.
• In SEOVA, the authors propose to alter the commonly used single signature process in blockchain data verification in favor of a novel double signature block formation process in conjunction with the apt use of Secure Element to implement the same.
• Secure Element is a tiny secure microcontroller with a “secure by design” architecture. It is commonly used for providing Trusted Execution Environment (TEE) and Trusted Storage Environment (TSE).
  • Secure Element applications include: chip based credit/debit cards, biometric identity cards, biometric passports, etc.

Figure 2: SEOVA Architecture-

Secured by Secure Element installed on each miner/verifier for the blockchain.

• Fig 2. Depicts the architecture for implementing SEOVA, during the instantiation, 2 private keys (validator key PV, blockchain key PB) and supporting codes are securely injected into the Secure Element. PV is the unique private key for the particular validator and PB is the shared private key common to all validators of the blockchain. The corresponding public key (PuB) of PB is injected into the Secure Element of the concerned RIDs.
• Even if the authors propose sharing of a common private key, this process is secure and the instantiation of Secure Element is assumed to be carried out in a safe environment. Moreover, once instantiated, the possessor of the Secure Element can not copy nor extract the shared blockchain private key.
• Since the key used is asymmetric, attacks on ECC signature for getting the right key would take provably longer time than the life cycle of the IoT ecosystem in which it is being deployed.
• The process for SEOVA starts at the validator’s end. When new data D is to be added to the blockchain, the validator creates a new block B containing this data. This block is then signed by its dedicated SE twice (i.e. with PV and PB). This double signed block Bs² then disseminated across all the participating nodes,verified and finally added to the blockchain after consensus.
• On the RID, when blockchain block is received, the RID needs to only verify the signature with PuB, irrespective of the size of the blockchain network, block size and the number of verfiers/miners.

Method:

To measure the timing overhead, authors created a testbed consisting of Remote IoT Device, Blockchain nodes, and Secure Elements. They used ArduinoNano 3.0 and Raspberry Pi 2 Model B as Remote IoT Device. For the Blockchain node, they used Dell XPS with an Intel i7-8550U processor. For Secure Element, they used Multos M5-P19. To quantize the timing overhead, they performed 100 iterations of ECDSA signature and verification on each device. The averaged results with standard deviation were used.

Results:

At the RID level, usage of SEOVA leads to reducing the memory and processing overhead since all cryptography-intensive tasks are delegated to Secure Element. Further, since Secure Element has a dedicated crypto-processor, the whole signature/verification operations are 25x to 31x faster compared to their native implementation on a standard RID, not to mention the added advantage of TEE and TSE, protecting the keys. On the cost axis, since an additional hardware element is installed, depending on the security requirements (EAL1-EAL7), the cost increases by $0.50 to $10.00.

Key Takeaways:

• An innovative lightweight algorithm called SEOVA is proposed to verify whether data belongs to the blockchain when received through an unsecured/untrusted channel, at RID.
• Performance evaluation showed that the SEOVA proposition can increase the performance of critical security operations by as much as 31 times, all while reducing computational and memory overheads while guaranteeing TEE and TSE.

Implications and Follow-ups:

SEOVA’s approach has a wide range of advantages against the traditional online blockchain data verification procedure:

• No need for a trusted intermediary.
• No need to connect to Blockchain for verification. (Offline verification)
• No overhead on RID as calculation-intensive tasks delegated to Secure Element Validators cannot leak or copy PB given SE’s secure by design architecture.
• No need to change key when validators maintaining blockchain change their individual PV OR new validators are added/removed.
• Secure Element can be programmed to detect hardware tampering attempts and will subsequently cease to function if tampered with.
• Identity theft of validators through leaked PV-PB is effectively prevented as keys inside SE cannot be replicated.

The authors propose to comprehensively expand this work for its implementation with smart contracts and other distributed ledger technologies.

Applicability:

The research work can be applied to any comprehensive security strategy in a resource constrained IoT environment.

[jmcgirk]

@kanad thank you so much for posting your research - I understand you focused on section of your research in this summary. Could you tell us a little bit about the rest of the paper and maybe discuss some of the most promising applications for this level of security for IoT devices.

[kanad]

@jmcgirk Thank you for your interest. There are two parts of the paper. The one explained above is the second part focusing on the way to verify the blockchain data in an offline manner. The first part focuses on holistic security of IoT data. Any data can said to be truly secured IFF it is secured at 3 points 1. Point of generation, 2. Point of Storage, 3. Point of Usage.

Since in IoT, the network is so heterogenous, we cannot really implement protocol/network level security reliably as there are various impediments like low processing power, different processor architectures, different access control policies, etc. Hence, an add-on system is proposed.

Using blockchain system as an add-on to secure IoT data has been proposed in many research works but from our point of view, it solves only the Point 2 security. Hence we proposed a stratagem (strategy) to holistically secure all the 3 critical point at once without much increase in overhead. This stratagem is based on blockchain placed at higher level while Secure Element technology at lower level, near to the resource constrained IoT devices.

[Larry_Bates]

This is fascinating! @kanad do you think there would be a way to use open source collaboration or something of that nature to create a less centralized intermediary in the initial framework? I am not sure if that was something covered in the paper as a potential path for research, but do you see that as being less centralized, or is the single point of an intermediary in this framework effectively centralized no matter how it’s deployed? I have not really seen a solution for data ingestion that removes an intermediary, and even the SEOVA comes after the intermediary step, unless I am missing something. Is it physically possible to ingest data without a single ingestion point inherently centralizing the process?

[kanad]

@Larry_Bates Thank you for your intriguing questions and apologies for the delay for my response.
Your proposition is very interesting and I do agree that having one intermediary would centralize the system. However, the intermediary here is more like party responsible for a part of the IoT devices depending on BaaS. So inherently, there should be more than one intermediary for the whole system instead of one. I do agree that, the paper does not elaborate on this part so it may not be clear for readers.

Regarding your second query, you are absolutely correct, it is very hard to decentralize the data ingestion. I thought of this point earlier and it was subsequently solved using multiple ingestion points and a common transaction pool mechanism. The process is elaborated in the context of Demand-Response of Energy using blockchain here. Maybe I can write another summary on how we did it for easy understanding of readers.

[Larry_Bates]

Is there a copy of the linked article that is not behind a paywall by chance? I do not have a subscription that particular journal.

[kanad]

@Larry_Bates Sure, here it is: Blockchain Based Decentralized Framework for Energy Demand Response Marketplace.

[Larry_Bates]

This is a really cool solution as a proposal! Do you believe it would be resistant to Powerhammer attacks? I don’t think it would be something that the average attacker would be able to pull-off, but most likely a state actor executing such an attack and in that regard not a huge risk at scale. I am just interested to see what you think about the potential damage of that type of attack on your proposed framework and if it’s already robust enough to resist the Powerhammer?

[kanad]

@Larry_Bates Thanks for your interesting question. Power hammer attacks are mainly used for data theft from air-gapped systems. For our use case, we are trying to bring in transparency and indirectly more data visibility, so attacks like power hammer do not implicate our system as we ourselves want more data visibility, transparency.

On other hand, if there is some crucial/private data stored on the nodes maintaining the blockchain, the probability of success of attacks like power hammer depends on how secure the facility hosting the node is. Clearly, our solution does not establish any safeguards regarding such attacks as this something out of the scope for the paper :)

[Larry_Bates]

I figured considering the “offline data verirification” process was effectively the same as being “air-gapped”, this attack might be something that could be a potential problem for this type of validation if the attack becomes more complex. Obviously the framework cannot consider every variable at every moment of creation, so I understand why it’s not necessarily within the scope of the paper.

Considering any line of transmission that can be used to “receive” and also involves transistors can have the polarity reversed to “transmit”, the Powerhammer attack as a form of “data gathering” could effectively be used to “alter data” if the conditions are met, and thus an off-line validator could be subject to attack via Powerhammer. Obviously that is a super-theoretical vector, but I posed it for the sake of ensuring that it’s considered as a potential Advanced Persistent Threat as the Powerhammer attack has been spotted in the wild.

[kanad]

@Larry_Bates Apologies, I mislinked your question with the DR paper. Yes, I agree such an attack can potentially become a problem if it is more complex in nature. However, I also believe, using a certified Secure Element should alleviate concerns up to some degree at least since data coming from blockchain is already signed, so tampering should be easily detectable.

[Larry_Bates]

Your response makes me think that “tamper-evident” is a better approach to security than attempting to achieve “tamper-proof”.

[kanad]

@Larry_Bates Within that little quotes, you perfectly summed up everything about my opinion

[Gearlad]

Interesting post @kanad! Offline verification of blockchain data is awesome and could be super useful for such a large number of application scenarios such as in an agricultural case where it is difficult to provide immediate internet access for devices placed in remote areas. IoT merged with blockchain has infinite possibilities. We’re currently gathering resources for a proposed SCRF AIoT Blockchain project. Please let us know if this sounds like a project you’d be interested in.

[Albert]

This paper elaborates on a novel idea that can tackle the obstacle the current IoT field is facing. Taking my personal experience as an example; there is a lab in NTU setting up an array of underwater microphones to detect the traces of white dolphins. They connect all of the microphones to an intermediary to send back the data to the server located on the coast.

The reason they use intermediary gathering data collected from those IoT devices is because of several reasons. First, because the microphone array is located 3 kilometers from the coastline, the only way to sending data to the server on the coast is via antennas. However, setting up antennas on the ocean surface with such an unstable climate situation is complex work. What’s more, after setting it up, it’s hard to maintain especially since the cross-strait is where typhoons usually occur in Summer. Second, the data collected by the microphones is too big. A compress process is necessary before sending the data via an antenna. As the paper mention, the environment deploying those IoT devices is usually very harsh, for the lab the IoT devices are hundreds of miles underwater in an airtight capsule, which makes deploying any device bigger, therefore, more powerful than a raspberry pi impossible, not to mention a device that is capable of carrying out the implementation of security protocol across all remote entities. Additionally, provided that the framework isn’t using blockchain as a storage device, the only available storage will be on the Remote IoT Devices, take raspberry pi as an example that is 32GB the maximum size for the SD card on board, that is insufficient.

Thus, with the traditional approach, if such a framework wants to put their data on the blockchain, the only choice will be recycling the old infrastructure, and upgrade all of the hardware until it’s powerful enough to implement security protocol across all remote entities. Nevertheless, if the method, Secure Element based Offline Verification Algorithm (SEOVA), introduces by the author is adopted, there is no need for any update in the aspect of hardware of the Remote IoT Devices if its already using the Secure Element based hardware, the only modification should be done is on the blockchain side for the validator using the new double signature block formation process and upgrading its hardware into Secure Element which can detect hardware tampering attempts promising a more trustable environment to run the blockchain program. On the other hand, it also removes the need of placing trust in the intermediary and also lifts all of the heavy computation from the ledge device. The only responsibility of the Remote IoT Devices is only collecting data, which ensures it’s could be as light weighted as possible. Most importantly, it still assures the data is legitimately coming from the blockchain.