IoT Security Framework For Blockchain Apps

This framework is for the enterprise security of blockchain-based IoT applications. It covers the many different threat actors inherent in these modern applications. The most significant benefit of the framework is the quick and approachable way it moves anyone from novice to informed. There is much additional work to address all these threats, but you should quickly realise which ones could affect you and how.

This framework has been adopted by the Internet of Things Security Institute.

Indelible ledgers hold the value of each wallet

Smart Contracts codify business transaction logic

Unstoppable blockchains compute subsequent blocks regularly

Wallets of human or machine (IoT) clients provide their wallets to smart contracts for execution.

We present

1 — an overview of the technology domain and its challenges,

2 — a stack representing the technology, governance and business considerations,

3 — an enterprise-level framework for assessing security risks, and finally,

4 — a case study that uses this framework.

Blockchain Apps are applications built on decentralised indelible ledgers, first introduced by the Bitcoin cryptocurrency. Their crucial quality is the trustworthiness of the ledger. This quality allowed Bitcoin to claim its network represents a currency to be used on the internet.

Bitcoin’s ledger was implemented as a blockchain. Still, some newer cryptocurrencies use decentralised acyclic graphs (DAGs). Perhaps we should refer to ‘Indelible Ledger’ instead of ‘Blockchain’, but blockchain has become the terminology most closely associated with the technology. We use both interchangeably.

Ethereum introduced computation on the blockchain itself in the form of smart contracts. This led to blockchain applications (apps) where web applications interact with the smart contracts, which, in every block, are computed alongside currency transfer transactions.

Transactions are sometimes initiated manually by people but sometimes also automatically in the Internet of Things (IoT) context.

The entire network security is assessed, from cryptocurrency wallet, web application, blockchain transaction and the blockchain itself.

Reference Stack Architecture

Security Vulnerabilities of Blockchains

Security vulnerabilities come from many places — source code weaknesses, systems and network fragility, and the social consensus that secures a blockchain are just a few. This framework covers them all and guides how to assess, plan for and remediate each.

Before going through each threat in detail, consider the concerns for this technology solution stack.

Threat Landscape

Blockchain Governance

Blockchains, starting with Bitcoin, provide a reliable, indelible ledger platform required by the application. If the application does not require such a reliable, indelible ledger, it should be implemented with a relational database instead. To date, these ledgers have not been easily hacked or surreptitiously altered. Only new transactions may be added.

Governance ensures the future of a blockchain.

Tenancy Architecture Implications

Your application may be a tenant of a blockchain such as Ethereum, where your project has created its ERC20 token type, minted them and coded smart contracts in Selenium on Ethereum. Alternatively, your project may have implemented a dedicated blockchain. In either case, there is a reliance on the ongoing success of the blockchain. Will miners (proof-of-work) or validators (proof-of-stake) continue to be incentivised to create new blocks? This risk needs to be assessed and contingency plans prepared.

With COSMOS ecosystem blockchains, governance is generally on-chain. Any wallet containing sufficient coinage may propose a change to the network configuration or deployment of funds; Every wallet participating in staking funds to secure the network may vote on the proposal. This process is managed on-chain, meaning the mechanism to achieve this has already been developed as a smart contract and web application, leading to a verifiable result for all on-chain.

This security risk to the blockchain is more commercial and social than technical but needs assessing nonetheless.

Blockchain Network Decentralisation

Public blockchains, such as Bitcoin and Ethereum, rely on network decentralisation to maintain their independence from interested parties that may otherwise attack the blockchain by perverting the production of blocks in several ways. The idea is that a public, decentralised network creates a situation where everyone keeps an eye on everyone else to ensure the safety and trustworthiness of the network. If the network is compromised, those not involved in the compromise will suffer, so they are incentivised to ensure this does not occur.

Private blockchains dedicated to an application instead rely on organisational hierarchal discipline to ensure no shenanigans are at play in the production of blocks.

The risk of colluding network nodes

In decentralised networks, there is a risk that the degree of decentralisation will diminish when a group of miners or validators collude to attack the network. This is known as a 51% attack, where a collection of colluding miners or validators controlling more than 50% of the network can corruptly alter the blockchain. This risk needs to be managed by regularly monitoring the degree of decentralisation and putting measures in place to increase decentralisation where it is at risk.

Bridging Vulnerabilities

“No man is an Island” — John Donne.

New blockchains are appearing all the time. Many flounder; some prosper. Over time, the desire to integrate blockchains increased for many reasons.

Consider these -

Decentralised Finance (Defi), where financial instruments are implemented as smart contracts on decentralised blockchains; the liquidity of more established blockchains is often sought on new chains.

Centralised Cryptocurrency Exchanges (CEXs), such as Binance and Coinbase, provide facilities to exchange coins and tokens similarly to fiat currency exchanges. They achieve this on their in-house dedicated platform, where the organisation fully controls the funds they make available to their clients.

Decentralised Cryptocurrency Exchanges (DEXs) need to do this in an automated, decentralised manner, where smart contracts are used to exchange funds, sometimes across blockchains. For this to be possible, a cross-blockchain bridge has to be implemented. Since blockchains’ unique value is their reliability and trustworthiness in the blockchain’s issuance and transfer of funds between wallets, extending this facility to outside entities such as foreign blockchains brings attendant risks. Many, including Ethereum’s Vitalik Buterin, have warned against the inherent dangers of cross-blockchain bridges. By September 2022, there had already been many exploits with severe consequences.

Cryptocurrency Exchanges Hacks

Here is a list from HedgeWithCrypto.com.

Bridge Specific Hacks

It is taken from the Chainalysis’ report.

A cross-blockchain bridge should be considered an area of high risk and deserves a risk assessment.

The technology used to achieve a bridge bears heavily on the associated risk profile. For instance, COSMOS Ecosystem has introduced the Inter-Blockchain Communication (IBC) protocol to address this issue. This is a more reliable, better-designed approach than extant solutions that do not use IBC. Within the COSMOS, IBC has proven a reliable solution to cross-chain asset transfer, demonstrated by the Osmosis DEX and its ability to bridge assets to its OSMO chain.

Blockchain Implementation

Most blockchain implementations are modelled after Bitcoin, so let us consider Bitcoin.

Regardless of the great success of Bitcoin’s blockchain in delivering a reliable, indelible ledger, we should not neglect the possibility of that coding itself being vulnerable. All code may contain errors. Bitcoin’s architectural and cryptographic solutions are well considered and have stood the test of time with a financial bounty that has increased significantly every Bitcoin halving.

The Bitcoin blockchain continues to be regarded as 100% secure with no blockchain hacks. This is the basis of the technology it introduced, but all software can contain zero-day defects.

When Bitcoin was first deployed in January 2009, there would have been little reward for breaking the machine besides kudos amongst the cypherpunks. Now, there are billions, soon trillions, of dollars at stake. For instance, if one finds a way to derive the private key from a public wallet address, one could help oneself to any existing wallet. An interesting choice would be those associated with Satoshi Nakamoto, valued at millions of dollars and unused for many years. This would attract much attention, which may not be what the perpetrator would want! Since this cryptographic mechanism is now so trusted, there would be significant activity before the Bitcoin core maintainers start working on solutions if we accept that they believed in the hack. There are current concerns about the vulnerability of these cryptographic algorithms to quantum computers, and I think that, in time, Bitcoin will migrate to quantum-resilient cryptographic primitives.

I remember an early interview with Bitcoin core maintainers at a conference discussing the maintenance of Bitcoin core code. It was shared that, sometime earlier, a maintainer had noticed that there was no check in place for some aspects of introducing new transactions on the blockchain. This meant that transactions could be submitted that should fail to be introduced but wouldn’t be. This was fixed in the following release, but it was clear until that was the case that the blockchain itself was very vulnerable. This vulnerability seems so unlikely now, but the point is that zero-day vulnerabilities tend to exist in all code.

Smart Contract

The application’s core transactional logic is likely written as a smart contract in the blockchain’s scripting language. This is what enables contractual actions to run without intermediaries. This is the crucial innovation of smart contracts. “Rules without Rulers”, as someone said. Those who would interact with the smart contract inherently trust it. Trusting that it reliably does what it was designed to do but also trusting that it is not itself vulnerable to attack. So, this is another point of vulnerability within the technology stack. Smart contract code could have zero-day vulnerabilities, so past performance does not guarantee future security.

The Dao Dao Debacle

One of the first smart contracts, Decentralised Autonomous Organisations (DAOs), was “The Dao (of DAOs)” on the Ethereum blockchain. Someone, it is assumed, on reading the code, figured out a way to game the contract into providing their wallet with all the funds held in The Dao’s wallet. Ethereum was well embarrassed. What to do?

Much discussion and disagreement ensued. Some pushed for ‘Code Is Law’, so hard luck to those who invested; Others believed in restoring the funds via a change pushed to the miners. Ultimately, the Ethereum chain forked on the issue into Ethereum (ETH), where a fix was put in place to return the funds and Ethereum Classic (ETC), where no fix was implemented. There have been many hacks since then of smart contracts and bridges in particular, but pushing changes to restore funds is not in vogue. Either the funds stay stolen, or law enforcement chases down the culprits.

Code Review

Proving code to be correct is non-trivial, and automating code review is also non-trivial. Alan Turing proved in the Halting Problem that writing a program that detects if another program will halt (i.e., does not enter an infinite loop) is impossible. We take this as an indication that the generic case of program proving is impossible. The best practice in software engineering is peer code review (“code inspection”). IBM are the ‘OGs’ here, though they are probably not who are thought of initially. A case in point is that IBM has shown Code Inspections are more efficient and effective than creating dynamic unit test code. Code reviews and audits are a developing business as the programable blockchain space matures. Providing this service includes IBM and Consensus.

Writing smart contract code is specialised and, therefore, so is reviewing same.

Smart Contract code, whether executed by devices in the IoT or by human interaction, needs a risk assessment, and the engagement of a third party for code review should be considered.

Web Application

Particularly with human interaction, but sometimes where IoT devices are involved, access to the interaction with the smart contract is front-ended by a web application (web app). This is another vulnerability. The web app is being trusted not to act maliciously. The web server hosting the web app may also get compromised and a substitute, malicious web app planted. The web app and its hosting need a risk assessment.

Wallet Application

IoT Wallets

With IoT devices, the crypto wallet, specifically the wallet’s private key, is usually embedded within the device, along with the wallet logic to create and sign transactions. This is what it means to have an IoT blockchain.

Wallet — another meaning

From one perspective, a ‘wallet’ is simply the numeric identity used on the blockchain to hold (attribute) the value (coins) the blockchain manages. From another perspective, a ‘wallet’ is the software that prepares transactions to be submitted to the blockchain’s miners/validators.

End-user Wallets

A wallet is likely a browser extension such as MetaMask, Keplr or similar for web apps. On mobile phone devices, many crypto wallet apps are available. The funds (coins) are held on the blockchains, not within the wallets. The software wallets interrogate the blockchains to discover balances and transaction histories and prepare transactions to be sent to miners/validators. The private key for the associated wallet provides access to the funds held at the wallet addresses. Software wallets need access to that key to be able to sign transactions.

IoT Wallet Administration

IoT devices generally have the required private key embedded in the device, though other discovery schemes are possible.

Browser extensions and software wallet apps can either (i) have the private key held accessible to it, usually in encrypted form, or (ii) they can interact with a hardware wallet such as Ledger or Trezor, which stores the private key within the device but never reveals it. Instead, they sign tractions when the user authorises them through the hardware wallet’s user interface.

Particularly where the private key is held within the browser extension software or the mobile app,  private key loss and the attendant loss of funds are at risk.

This is another case needing risk assessment. Also, with IoT devices, a risk assessment is required for the possible loss of private keys from the device by capturing and analysing the device itself. This leads to the next topic of private key management. Does each IoT device have its own private key, and do clusters of devices share a pattern that might be used to guess private keys?

Private Keys Management

The most onerous and perilous aspect of cryptocurrency is the maintenance of private keys. This dynamic was introduced with the Bitcoin blockchain and is inherent in all cryptocurrencies. Corporate custodianship is replaced by the self-custody of the private keys that action wallets transfer on the blockchain ledger. Never before had cryptographic keys been used to entitle access to funds in such an absolute manner. Make no mistake. It differs from passwords used as an authentication scheme or account numbers used at high street banks. In both those situations, funds are not lost if you lose your password or bank account number. They are with cryptocurrency private keys. Forever.

Public Key Infrastructure (PKI)

The invention of public key cryptography, where a key pair, one private, one public, is used for private communications and non-repudiation of messages, led to the introduction of public key infrastructure (PKI), securing all manner of communications. In PKI, if keys are lost or certificates expire, a new key pair is generated and used in their place without any loss of infrastructure. It is true that if an individual or organisation encrypts a file with a key that is later lost, the data held in that file will likely be lost forever. Still, data often can be recreated, and this situation rarely leads to the absolute loss of funds. Consider PKI’s use in HTTPS protocol. The browser clients do not have any key-loss risk. They hardly have any key management to contend with either. Not so with cryptocurrency. Bitcoin recognises a wallet address as a number (public key) where it can identify if that number’s corresponding private key has been used to sign wallet transfer messages (transactions). If the private key has been used and sufficient funds are available at the wallet address, the transaction is allowed; otherwise, it isn’t. Bitcoin also issues new currency every block (about every 4 minutes) into the successful miner’s wallet address. According to the protocol, the new currency is a fixed amount that halves approximately every four years. The chain of these blocks is the Bitcoin ledger, which is unencrypted and viewable to everyone with an internet connection in its entirety.

Types of Loss

If the private key to a wallet is lost, so are the funds held at that wallet address. This is true in several ways. Not only in the sense that if the private key cannot be recovered, then neither can the funds in the corresponding wallet address, but also if the private key gets discovered by other parties, then those other parties may withdraw the funds from the wallet into another one that the perpetrator alone controls.

Custodianship Options

One may consider relinquishing control of the funds to engage in a banking-style relationship with an organisation holding the private keys to your cryptocurrency. You give over custody of your funds for the bank to custody them instead. This requires a high degree of trust, which sometimes proves ill-advised. Hence the cryptocurrency slogan, “Not your keys; not your crypto”.

There is no getting around it. Where there is a blockchain-based application, there is also the cryptographic private key management challenge. This attendant process needs documenting and rehearsing, including assessing every type of risk.

End-User Key Management

A single end-user holding cryptocurrency is an everyday use case and well documented, though not a situation without risks and frequent failures.

Key Management with Hierarchical Deterministic (HD) Wallets and Seed Phrases

Improvements to Bitcoin are proposed and managed through “Bitcoin Improvement Proposals” (BIPs) held on GitHub. One such is BIP32, “Hierarchical Deterministic (HD) Wallets”, attributed to Pieter Wuille in 2012 from the idea of Gregory Maxwell. BIP32 introduces the scheme where one seed number can be used to deterministically generate a tree of a maximum of 256 x (private, public) key pairs to be used as wallets. For an individual, this means only having to manage the single seed number, which simplifies key management. Another innovation is BIP39, where the seed number is represented as a list of natural, say English, language words from a predetermined numbered list of 2048 words. 2048 (decimal) is exactly 10 bits (2 ** 10), so a sequence of 12 words is exactly 120 bits, or 15 x 8-bit bytes, which can be used as the seed number for the HD wallet. These 12 words can now be used as the seed phrase for all the wallet addresses. Hardware and software HD wallets use this scheme in everyday use.

This now reduces the challenge to only securing a single 12-word phase rather than multiple long strings of digits.

Private Key Physical Security

There remain the same physical storage challenges and risks. Some techniques to consider are

• Indelible inks are used to write seed phrases on archival paper protected by plastic wrap.

• Seed phrases stamped out on stainless steel sheets.

• Safes and personal deposit boxes.

• Splitting phrases across multiple locations.

• Multiple-signature (multi-sig) arrangements, where an “n of m” allows access.

Size Considerations

Bitcoin’s original design targeted, perhaps a proof-of-concept, a ledger for making small online payments to websites. I doubt Satoshi was considering wallets to hold the high-value funds that Bitcoin does today. The cyberpunk triumph of securing funds using cryptography surely did not consider the perilous situation of having those funds forever at risk of private key management. We have improved the key management situation from Bitcoin’s very early days. However, we are still in a difficult place with our private key management, which either has to be impeccable or face the total loss of funds to lost wallets.

Market Models

Finally, where the application implements or makes use of tokens (or coins) as the digitisation of assets and the market for the tokens is traded on exchanges, there exist market risks to the liquidity and price of the tokens.

This might be considered a financial risk only and outside the security scope, but that is short-sighted. Where the application uses a dedicated asset, which is traded on exchanges, vulnerabilities of the market model for the purchase can create situations that create arbitrage opportunities that are exploited to devastating effect. This can severely affect liquidity, bringing an application down.

Flash Loan Attacks

Ever since finance went online and online currency exchanges were introduced, there have been risks from the combination of

1. Large pools of capital

2. Fast automated transactions

3. Arbitrage opportunities

4. Price fluctuation, caused by liquidity changes brought on by large transactions

Decentralised exchanges (DEX) and Defi increase this risk because of the opportunities for significant, very short-term (unsecured) loans, known as flash loans.

Speed is of the essence here. Flash loans occur in a single transaction block. They can, in the space of a single block,

• Take out a loan

• create an arbitrage opportunity

• exploit the opportunity

• Repay the loan

That’s a profit to the flash loan arbitrager and a loss to the market. Since this is automated, repeating the automation to devastating effects is straightforward.

Remember that the transaction block is the entire financial activity occurring on its blockchain for that period, and all transactions within the block can be sequenced.

As decentralised financial instruments get more complex and numerous, the opportunity for these types of attacks increases.

These arbitrages are generally known as attacks since they incorporate a degree of market manipulation, a criminal activity in the regulated financial industry.

Decentralised Apps can reduce the risk by becoming more sophisticated about price discovery.

1. Using decentralised, reliable price oracles

2. Having more frequent price discoveries

3. Using time-weighted average pricing.

Maximum Extractable Value (MEV)

It is a similar situation to MEV, which was initially an abbreviation for Miner Extractable Value (MEV), but little changes from proof-of-work (miners) to proof-of-stake (validators), so it is primarily considered to mean Maximum Extractable Value (MEV) now.

Within a single block, there is an opportunity for those creating the block to front-run trades. Say a large DEX purchase (swap) transaction is part of a block, reducing the amount of asset X. This will cause the price of X to increase. A sandwich attack places an X buy order immediately before the significant transaction and an equivalent X sell order immediately after. This way, the creator of the sandwich profits from the increased price. It is a way the miner or validator can maximise the value that they extract from the blocks they mine/validate, hence, MEV.

MEV is not an immediate security risk to a blockchain application. Still, it should be considered a financial risk that can be managed by the choice of technology deployed to miners/validators. For instance, if miners could not detect the number of transactions, they would not be able to create sandwich front running.

If you are interested in MEV, the MEV-Explore website provides some great information and charts, even though it is just for the Ethereum blockchain and limited to on-chain, using lower-bound estimates for a limited number of protocols and not including bandwidth exploits.

In addition to MEV, private order flow, while different to MEV, is also a consideration. It is another way that value can be extracted.

IoT Blockchain Security Reference Architecture

Below is the reference architecture for evaluating the security risk profile of IoT Blockchain Apps.

The layers most important to Blockchain app security are considered.

The nature of public blockchain technology leads to different risk profiles to traditional TCP/IP network architecture. There are new types of risk in the less mature areas of blockchain architecture.

Blockchain IoT Stack

Below, each aspect of this stack is considered, along with some significant threats, the attendant cyber procedures to consider, and possibly any cyber defence solutions and advanced features. This framework benefits IoT blockchain projects to assess and report on their security profile, ideally at the concept and planning project stages.

Case Study

Below is a case study that uses the framework to assess and report on the project’s security profile.

Background

Delivery Stage

Below, we present a blockchain application security case study as an example of the framework in use. A complete detailed analysis is out of scope; A document to the level we present would be used at the initial solution stage within a project. Once accepted, it would be detailed further as the solution design progresses.

Application Choice

We have established a new supply chain management application that uses IoT devices that follow the goods produced throughout their entire supply chain lifecycle. The application will develop its own public blockchain instead of sharing tenancy with others. This provides the case study with good coverage both of IoT and blockchain aspects.

Disclaimers

We have taken as inspiration an existing (October 2022) successfully deployed project. Any similarity should not be construed to imply the authors had any involvement with any current projects.

Application

Business Model — The development organisation is creating a generic blockchain-based solution for one of its customers. The plan is to make the technology and platform available to other customers. So, the design is for multiple customers, but initially, just one customer will use the solution.

Business Domain — Supply Chain Management, where, for each asset, the supply chain lifecycle details for that asset are captured as asset transactions on the blockchain, including date/time stamping, counterparties identification and weights and measures.

Workflow — A unique IoT device dongle is attached to the device at the earliest stage in the supply chain. At each subsequent phase of the supply chain, the blockchain is automatically updated with information captured at the source on encountering the dongle.

Benefits — The trustworthiness of the blockchain ledger increases business confidence and assurance of activities and provides timely information for all parties.

Web Portal — An internet-facing, corporate web portal provides authenticated access to inspecting the supply of goods. It examines the blockchain to discover goods, including their location and associated information.

Blockchain Economic Model — The initial VVV coin mint has allocations for development funds, treasury, customer (initial) funding and staking rewards. Blockchain transactions and smart contracts consume VVV coins. The customer has an ongoing cost to acquire VVV coins to fund the wallets of its dongles. VVV coin liquidity has been established on three public cryptocurrency exchanges. The staking nodes also require VVV coins to secure the network.

Blockchain — The blockchain code is developed in-house from the open-source COSMOS code base. This mature, highly regarded project has seen adoption by Binance, crypto.com and many others.

IoT Dongle — An always-on, IP-enabled device with a unique identity, its blockchain wallet address. The dongle holds the associated private key of its wallet address, encrypted and embedded within the device itself. The dongle is responsible for signing blockchain transactions from its wallet. The generic asset update pattern is this — the supply chain stations read the wallet address from the IoT dongle, may discover its status thus far from the device itself or the blockchain and prepare a blockchain transaction to update the then status, which the dongle needs to sign before the station submits the transaction to the blockchain. This proves the station encountered that dongle at that time at that point in the supply chain.

Solution Architecture

Governance

A blockchain governance model has been established, including the customer organisation, key industry bodies, and validating nodes. An on-chain voting system will be set to govern changes to the blockchain. New customers will be added to governance.

Concensus Algorithms

A proof-of-authority concensus algorithm has been designed. Nodes are incentivised through staking rewards. Partners have been established.

Blockchain Implementation

The new blockchain is being developed in-house from the COSMOS SDK open-source codebase with experienced software development staff.

Blockchain Bridges

No bridges to other blockchains are part of the solution initially.

Smart Contracts

The solution includes the development of several smart contracts that implement bespoke transactional behaviour between various actors along the supply chain. This protects the interests of all parties involved in the solution and increases confidence in the reliability of the blockchain ledger solution. The core set of smart contracts will be extended due to consultations with all the parties involved. The smart contract code will be available for review by all parties.

Web App

The development organisation develops the web portal app. It includes the core logic and facilities of the generic solution plus tailoring for each party involved. Authenticated access is required for some aspects, while others are public. It uses industry-standard language, development techniques and technical infrastructure.

A public blockchain explorer is available via the web portal app.

Wallet App

Generally, the application’s leading blockchain wallets are controlled by the private keys held within the IoT dongle, so there are no traditional web wallet apps or mobile wallet apps for these devices.

To fund the wallets of the IoT dongles, an administrative part of the web app interacts with an administrative wallet, implemented as a browser wallet to acquire funds from exchanges and deposit the same into the IoT dongle wallets.

Key Management

IoT dongles are manufactured with initial state (wallet address, private key) pairs. These are randomly created.

Maintenance of the dongle can introduce a newly refreshed key pair but cannot retrieve existing private keys. Thus, the dongle’s private key is never revealed, as with hardware wallets.

The web app includes management of the dongles, including a wallet address inventory.

Administrative funding wallets have their business processes defined, including using hardware wallets and archiving seed phrases.

Market Models

The VVV coin is the base currency introduced by the application. These coins are initially traded on three public exchanges to provide liquidity for their customers (s). Even though there was no business plan to develop and promote the coin, speculators are expected to purchase and hold the coin for expected gain.

The business holds an immense treasury of VVV coins for future work allocation on the blockchain and as a contingency for unexpected liquidity issues.

The solution allows for customers’ tailorings to include the creation of on-chain tokens and NFTs. This does not form part of the initial customer’s solution.

Case Study Security Assessment

Creative Commons Licensing Agreement

Attribution-NoDerivs CC BY-ND

Abbreviations and Terminology