Good evening everyone and thanks for joining my talk on leveraging blockchain for secure and immutable updates in which we're going to see how you can use blockchain into your OTF firmware distribution infrastructure to make it more secure. So a bit about myself, I'm swapil Shinde. I was previously Google Summer of code mentee at OWAsp, Mlitch fellow at near protocol and LFX mentee at Linux kernel mentorship program. So before moving towards the problem, let's see some stats. Currently there are 15 billion IoT devices connected IoT devices as per 2023 report, and it will going to rise up to 30 billion IoT devices by 2030. So you can see with this much huge jump in the count considering the given time frame, there will be a lot more rise in security attacks cybersecurity attacks into these devices. So now moving towards some security attacks that are performed as per 2022 reports, you can see 77% increase in firmware blues attacks, which means the attacker compromises your update infrastructure and injects malicious code into your firmware and then the firmware is distributed into your IoT network. The second one is DDoS attack which means like the attacker performs distributed denial of service into your centralized server and then your server won't be able to serve the firmware updates to your IoT devices. And the third one is man in the middle attacks which are also increased day by day like your wireless connection between your IoT device and your server can be compromised because it's wireless and the attacker can spoof in between them and then can upload malicious code. I've linked the sources, you can go check out these reports in more detail for better understanding. So you can see also see a graph in which you can see IoT device is more serving in the consumer sector and you won't be pushing malicious update to your users. So you have to make sure that your update infrastructure is more secure and cannot be compromised easily. Now you can see there are two types of update techniques. The first one is like your IoT device will be connected to using a wire and then you upload your firmware using that wired connection which is much more secure. But it is not that practical because you won't be calling off all your devices and then updating them into your service center or giving the authority to your users to update, depending on your users to update your IoT devices. So this is not that practical. So the other way is doing it wirelessly which is the over the air updates. And the thing is that it is not that secure because obviously you are exposing ports, you are exposing wireless connection. So anyone can attack using their methods that they will be using. So you can see there's a potential risk that chances that your centralized server might get compromised, which is the worst you can do because it will be on your company if that happens. So we will be seeing how this can be solved using adding a third entity into your firmware update infrastructure. So let's see how your firmware update works. Your OTA works. First thing is you have your firmware instruction code written in any language, but mostly it is c or embedded c. So it is then compiled and linked to a single binary and then that binary file is uploaded to your OEM cloud server and then your IoT pulls your firmware update from that server and then installs it into itself. So let's see this in more detail. So the first thing is your vendor service, which is your company pushes the binary file to the server and then the server replies with the location of that firmware, a binary file. And then you push MQTT request call to your IoT devices that okay, there is a newer update, you can pull this update and you also send the URL for that update. Then now your IoT device knows where the binary files of your firmware update lies. Then it will pull the binary files and your firmware hash and then it will check if the like you can see in the next slide, it can check if the hash is valid and based on that it will make its decision to either install the new update or roll back to the previous updates. So let's see some of the security vulnerabilities that is used to exploit your OTA infrastructure. So the first one is man in the manual attack in which you have your IoT device and you have your OEM server. Then the attacker might try to spoof in between them because it's a wireless connection. And then your IoT device will think that okay, this is the original server and I should pull update from this server and then it unintentionally downloads the malicious update and thus compromising the IoT device. And the second one is distributed denial of service attack in which the attacker distributedly floods your server with multiple requests, thus ensuring your server to fulfill the request of the update from IoT devices. Trust delaying your IoT updates obviously that DDoS can be secured easily by whitelisting the IP addresses, but still the third one is which is the worst? It is centralized server got compromised, so now the attacker has compromised your centralized server and now it has access to all the functions that you can do to update your network or your IoT device. And from there the attacker can easily create a new update and push it to or even modify the current update and push it to the network of your Iot devices. So here you can see we have our vendor organization which pushes the update to the server and then IoT device will pull the updates from that server with the update hash. But this is centralized, why not replace it with blockchain? So we have the features, or, sorry, the advantages of the decentralized storage or computing at the same time. So for those who don't know about what blockchain is, let me give you a little touch up so that you are in the same pace for the next slides. Blockchain is basically a chain of blocks in which each block contains a data and plus the hash of that data. Then the next block will contain the data of itself and obviously the hash of the previous block. And if somebody tries to change the data in first block, then the hash will also be changed in the second block, thus invalidating your whole chain, like the chain reaction kind of thing. And basically this is not blockchain, this is just a ledger. And to make it blockchain, to add a network layer, to add a consensus mechanism, all this is handled by a piece of software called node. And this node is responsible for adding or mining new blocks to the ledger, or even deleting the blocks or even modifying the blocks. But obviously these last two features are not generally implemented into the blockchain. But you can easily do that by creating your own blockchain. Since this is just one node and it is centralized, you can connect it with multiple nodes. You can use multiple instances of same nodes. And all these nodes are connected with each other via a boot node and they are generally in sync. And this sync is ensuring and secured by a consensus mechanism, which can be a proof of work. It can be proof of stake or any other mechanism that is available out there. So let's see, if somebody attacks this first node and changes the data in this node, then your chain will be invalid and the node will try to sync the data from other nodes and other nodes will give the data back to this chain, and then this chain will recover automatically from that invalid insertion. So this is how it generally works. Now let's see, like, you know, what is blockchain, let's see why we are using it. What are the features it is providing us. So first one is obviously immutable ledger. So you have the ledger which is immutable and it is being insured via the blockchain node. And the second one is smart contract enforcement. So this smart contract thing is a feature introduced by Ethereum. It is basically, you can imagine it as a piece of code, which is responsible for changing the state of the ledger. And it acts as a plugin to your blockchain node or extension to your blockchain node. So how it is done is like you write a smart contract like trust or solidity. In Ethereum, you usually do it by solidity, and then you compile it to bytecode and then push that bytecode to your blockchain. So now you have all your functions. Your instruction that is written there, it is compiled to a bytecode and then you push it to the blockchain via transaction. And then the code is stored inside these blocks. And you can run that code by simply calling the transaction id of that block with the function that you want to run, plus the arguments you want to pass. And then any one of the minor nodes will take the transaction and run the code for you and change the state of the blockchain using the code that is written in that smart contract. So when the smart contract is run inside a minor node and it changes the state of the chain, the minor node will obviously circulate the newer state to all these other nodes. And this is how the smart contract is generally run into in the blockchain. So the feature of this smart contract is that you don't need external entity to external entity to run your code or to decide what should be added to the blockchain. Now the third thing is decentralized security. Obviously you have decentralized infrastructure in the blockchain and thus you get decentralized security which is like you are protected towards DDoS attack, because if you have thousands and thousands of nodes then it will require a lot of infrastructure power to the attacker to attack your infrastructure. Blockchain infrastructure. And obviously blockchain is quite slow in nature when you query it. So obviously it will going to take time to them to complete one request. Now let's see how you can implement this into your infrastructure. In this we will see how you can create your own blockchain and customize it according to your needs and then how you can integrate it with your old OTA infrastructure. So the first part is choosing a blockchain. In this you have two options. Like you can either go with public blockchains or private blockchains, a public blockchain, like if you upload any transaction to it, any data to it. Then your data will be stored in the public ledger so that anyone can see your data, which is not that much secure and you won't be wanting that thing to happen. So obviously you can create your own private network. So this can be done by these three options. You can use Ethereum's geth, which is go Ethereum implementation of Ethereum node in Golang. You can use that to create your own private blockchain by changing the Genesis block and the network ports and running your own internal infrastructure. Then you can use Hyperledger or polka dot substrate. So these two are more like frameworks. You can use them to create your own blockchain. You can write your own consensus mechanism. You can use the proof of work, consensus mechanism or proof of stake. So if you go with proof of work, you have to give much more compute power and thus you have to pay for your resource intensive use, which is not what you will be wanting. It is much more secure. But obviously based on your use case and your needs, you have to choose your consensus mechanism. So you can either develop your own or you can use any lightweight consensus mechanism that compromises over security. The hyperledger is developed and maintained by the Linux foundation using the Hyperledger foundation, and the substrate framework is developed by Polkadot. So you can go with either of them. It is totally fine Hyperledger fabric in that the most common language is Java, and in Polkadot substrate you have rust. So based on your preference, you can go with any of them. Okay, so here I've prepared a block diagram in which we are using Hyperledger fabric as our main blockchain. And then we have our vendor service and our IoT device. And all these three things are running in localhost. That's why you can see the ports, your IP being mentioned as localhost. So here the first thing we do is the push call to the blockchain. And before that we'll be assuming that we have deployed our smart contract or chain code in case of Hyperledger fabric. And your smart contract is deployed to the blockchain with three functions, which is your push function, then your verify function, and then your query function. So the push function can take data like your update name, your version name, version name for that update, and your firmware binary hash for that update. So using push call, you call that smart contract, the particular function which is push, and then you supply all these three arguments. Now your hash is stored into the blockchain. So simultaneously what you do is you push your binary file from the centralized server to your IoT device, and your IoT device will take that binary file and then calculates it hash. And also assuming that for this you have to modify the OTA library for this IoT device such that it supports calling the blockchain network or calling RPC or HTTPs endpoints. So from here, when the it device calculates the hash of that firmware, it queries the blockchain using a verify call, and that verify call takes the parameter which is the hash of that binary file with the version name that you are uploading. So now the smart contract will see if the hash is correct for that particular version and return if the hash is valid or not. So if it is invalid, then obviously rest of the things are same. The execution inside the IoT is same, it will reject the update and it will revert back to its original, sorry, the old firmware update. So this is how it works. You also have a blockchain explorer in which you can see all the blocks in real time. You can see all the transaction being happening in real time. So this is the overall infrastructure here is like the calls that we have written into the smart contract, so you can see in more detail and what these calls will be taking as parameters. So you can see your firmware hash in verifying the transaction id, then your transaction attributes and all these things. So now let's see how strong it is when somebody tries to attack into the infrastructure. So I guess the image is not loading correctly. Okay, so this image is taken from this research paper, and it is a very great research paper. You can read this and it mentions how you can transfer your infrastructure and add this blockchain to your OTA. So in the end they have mentioned what they have performed to check the security of this infrastructure. So they performed denial of service and man in the middle attack in the infrastructure. And they were unable to perform these two attacks into the system because if you perform man in the middle attack, then you upload your invalid, sorry, the malicious code into that IoT device. But that IoT device had already written instruction into the library that you have to query that blockchain to verify if this hash is correct for this current update or not, and obviously deny log service. If somebody do a DDoS attack, then you have a time constraint between your updates. Then the update will obviously fail and will revert back to the old updates. So they have also mentioned the performance and scalability vectors and how this infrastructure performed. So you can read this. Also you can see this is the Go ethereum implementation. This is the GitHub URL for it. This is for Hyperledger fabric and this is for the polka dot substrate. Now this is the overall explanation that I have to give. So yeah, you can also see the sources. You can check out this PPT and go to these individual sources and read it in more detail. Okay, so now I'll demonstrate the project my team is working on for a hackathon for the similar use case of securing OTA updates using blockchain. And in this project structure we have code for both vendor service as well as our chain. And you can see in this build this update CLI which is the CMD update CLI. This is our vendor service and this one is our chain. And our chain is already running because it takes time to initialize the chain and run it. And the CMD update CLI, it is a CLI but it also consists HTTP endpoints which you can query and do your transactions. And here you can see this chain is built using hypersdk which is developed by avalabs. And you can use Hyperledger as well or other frameworks also like polka dot substrate. But for this use case for the hackathon we are building it on hyper SDK. And here we can run our build update CLI chain. Watch just to see the transaction happening inside the chain. So okay, it is running and we will also start our server CLR. Okay, so now I'll go to my endpoints, HTTP endpoints and from here we can query our vendor service. And also since if you want to do transaction in the blockchain you should have a wallet but you cannot implement wallet inside your IoT device, but you can do it by creating a separate service which will handle the wallet thing and you can expose HTTP or RPC endpoints that your IoT device can call and do the transaction. For ethereum cases you can do similar with infura which is also the similar kind of service. And we have built this service inside the update CLI only. So if I go here you can see this hyper OTA. This library we built using elegant OTA which is this hyper OTA is basically fork of elegant OTA and we have changed some code to call our chain and then get the validation of that hash, binary hash and we will upload this into our ESP 32 which is here. Currently it is connected wired connection, but this wifi is connected to my home router because we connected this wiredly because we wanted to see the serial outputs of whether the update is happening or not. Okay, now I'll upload the initial code to my ESP 32. Okay, so it will take a little bit time. So till then I'll explain you some of the parts like how my system works. So here we'll call the chain with the binary file and then binary file will be uploaded to your ipfs, to our IPFS server. So IPFS basically is the decentralized storage and you can even in the presentation I explained you that your binary file will be uploaded to your centralized server. But to add more extra security layer you can move it to the decentralized storage so it becomes hard to gain access to that file. Once you upload that file you cannot change it and then your ipfs URL of that file will be uploaded to the chain with the hash of that file. Okay, so our code is uploaded, I'll just monitor it, it's reconnected. Okay, so our ESP 32 is successfully connected to my wifi router and since it is connected now we can begin our firmware update. So the first thing is creating a project inside the chain. So we'll just call it hyper updates and we'll upload it. Wait a second. Okay, the response is our transaction id of this data. So we can just call the chain using this transaction id and we'll get this data back. Now we'll create an updates to this transaction id so that this transaction id is basically pointing towards our project and our single project will have multiple updates for that. So that's why we are pointing it using transaction id, our device name and our version name with the binary file. So what we'll do is we'll just change something here, okay, we'll change this dot to plus, which means these consecutive dots will be now displayed as plus. We will compile it again and then what I'll do is I'll delete this firmware file and I'll copy it from the build. So the build is successful. We'll copy it and then we'll paste it here, move it here, name it to firmware bin. We did this because the PIO is like hidden directory so we can't actually see that from our postman. So now we'll go to documents platform I protection. Here you can see our binary file. So now we'll just create an update. And now this will be uploaded to the blockchain. First the binary file will be uploaded to decentralized storage which is ipfs. And then the URL of that binary file will be mapped into our chain data. And now to see what is stored inside the chain. We can even see it from here. You can see this transaction being happening in our chain and also we can see it from here by just calling this endpoint. So you can see this is the ipfs hash of our binary file. So we can just go to this hash and download, but we'll not do that here. And also this is the URL for this repository. We have our library for ESP 32. We have our chain code here. Okay, so now we'll call this endpoint which is the most important. Here we will add the transaction id of the update and then IP address of our device. Currently it is connected to our local host, which is this one. So we'll just make it like this only and then we'll just send it. Now if we see here, you can see the update is happening. And this was the URL called by our ESP 32 to the vendor service, sorry, the chain to get the valid transaction, sorry, the valid hash of this firmware update. So we pass that hash that we calculated inside our, inside our ESP 32 and then we send it to the chain and the response was valid and it successfully updated. And remember that I changed this dot to plus and now you can see it is serial outputting the plus symbol, which means the update is successful and to demonstrate some attacks. I cannot do that because this is still in development. But yeah, I cannot attack like the ipfs easily because my binary file is stored in ipfs. So I cannot change that. I cannot change any data inside the blockchain. So it is mostly secured. And you can obviously read this research paper to see the attacks that they performed and how they secured it. So thank you everyone for joining my talk. And if you still have any questions left, then you can just directly reach out to me by scanning this QR code you will get all my social handles. Or you can just directly type your question into the Conf 42 discord server and hope you enjoy rest of the conference. Thank you.