Can Blockchain Strengthen IoT Device Security?
In spite of the potential of the Internet of Things (IoT), development seems to be dragging. The hype is huge, but the current state of IoT (to the consumer) does not seem to extend far beyond toying with lights, cameras, or household appliances from smartphone apps. In a world where the term Big Data carries so much weight, one would expect more from what is a goldmine of information.
A large part of the problem stems from security. The consequences of a breach of a central repository of data collected by IoT devices could be disastrous. Compromising such a database could give a hacker incredibly in-depth information about an individual, gleaned from the various sensors set up around their home, or on a grander scale, sensitive data pertaining to stock levels and shipping schedules of a wholesaler or agglomerations of confidential medical records from hospitals.
Research revealed that 90% of consumers believe that such connected devices are going to be a major security issue, a statistic which may be deterring the adoption of IoT by companies and individuals alike. It’s perhaps wise, then, to consider, in these early stages, how to prevent shaping a future that will lead to such single points of failure (as time goes on and the networks are deployed, it will become exponentially harder to tweak the underlying architecture). The answer seems apparent: avoid building such vulnerable platforms altogether.
Changing the Architecture of IoT
The very raison d’être of blockchain technology is to disrupt such structures. Distributed ledgers expunge the notion of centralisation, instead spreading multiple copies of a database across nodes in a network.
From a security standpoint, this dwarfs incumbent platforms: should one wish to attack the network, it is no longer a case of gaining access to a server. Successfully ‘hacking’ a blockchain requires a Sybil attack, whereby the malicious actor owns 51% of nodes and can falsify transactions or data – anything less will simply mismatch with the majority’s records, and get rejected. For properly engineered Proof-of-Work or Proof-of-Stake blockchains, the feasibility of such an attack is logistically impossible. From a logistical perspective, this p2p (or most likely machine-to-machine) approach for sharing data between devices further reduces attack vectors like man-in-the-middle attacks, since the information being transferred does not pass through a central hub.
This distributed method of managing the flow of data is also vital to the long-term scalability of IoT networks: as IoT devices proliferate in homes and in businesses, we’re going to see a strain on the network, leading to congestion as more and more are connected and routed through a centralised server.
Syncing With the Blockchain
The caveat we’ve seen thus far in the use of blockchains in IoT has been the requirement for nodes to store full copies of the ledger. Take the Bitcoin blockchain, for instance: to run a full node, the user needs to download a 200+ GB database of previous transactions. If smart devices are to interface seriously with a blockchain, there need to be efficient methods of doing so that don’t involve dedicating memory and bandwidth to syncing incoming blocks.
Bitcoin’s UTXO model allows for the creation of SPV (or Simple Payment Verification) wallets – instead of storing copies of the blockchain, they can make calls to full nodes that do, and obtain the information pertaining only to the wallet in question. These so-called light walletscan be run on lower-spec devices, and do not require nearly as many resources to operate.
For IoT use-cases, wherein one would want devices to not only verify transactions but to execute smart contracts, a light wallet would be highly desirable. They can allow even relatively simplistic sensors to sync with the blockchain, and then provide improved security through decentralised storage as outlined above.
Making Blockchain-Supported IoT a Reality
It would be unrealistic to say we’re there already, though.
In spite of the potential of the Internet of Things (IoT), development seems to be dragging. The hype is huge, but the current state of IoT (to the consumer) does not seem to extend far beyond toying with lights, cameras, or household appliances from smartphone apps. In a world where the term Big Data carries so much weight, one would expect more from what is a goldmine of information.
A large part of the problem stems from security. The consequences of a breach of a central repository of data collected by IoT devices could be disastrous. Compromising such a database could give a hacker incredibly in-depth information about an individual, gleaned from the various sensors set up around their home, or on a grander scale, sensitive data pertaining to stock levels and shipping schedules of a wholesaler or agglomerations of confidential medical records from hospitals.
Research revealed that 90% of consumers believe that such connected devices are going to be a major security issue, a statistic which may be deterring the adoption of IoT by companies and individuals alike. It’s perhaps wise, then, to consider, in these early stages, how to prevent shaping a future that will lead to such single points of failure (as time goes on and the networks are deployed, it will become exponentially harder to tweak the underlying architecture). The answer seems apparent: avoid building such vulnerable platforms altogether.
Changing the Architecture of IoT
The very raison d’être of blockchain technology is to disrupt such structures. Distributed ledgers expunge the notion of centralisation, instead spreading multiple copies of a database across nodes in a network.
From a security standpoint, this dwarfs incumbent platforms: should one wish to attack the network, it is no longer a case of gaining access to a server. Successfully ‘hacking’ a blockchain requires a Sybil attack, whereby the malicious actor owns 51% of nodes and can falsify transactions or data – anything less will simply mismatch with the majority’s records, and get rejected. For properly engineered Proof-of-Work or Proof-of-Stake blockchains, the feasibility of such an attack is logistically impossible. From a logistical perspective, this p2p (or most likely machine-to-machine) approach for sharing data between devices further reduces attack vectors like man-in-the-middle attacks, since the information being transferred does not pass through a central hub.
This distributed method of managing the flow of data is also vital to the long-term scalability of IoT networks: as IoT devices proliferate in homes and in businesses, we’re going to see a strain on the network, leading to congestion as more and more are connected and routed through a centralised server.
Syncing With the Blockchain
The caveat we’ve seen thus far in the use of blockchains in IoT has been the requirement for nodes to store full copies of the ledger. Take the Bitcoin blockchain, for instance: to run a full node, the user needs to download a 200+ GB database of previous transactions. If smart devices are to interface seriously with a blockchain, there need to be efficient methods of doing so that don’t involve dedicating memory and bandwidth to syncing incoming blocks.
Bitcoin’s UTXO model allows for the creation of SPV (or Simple Payment Verification) wallets – instead of storing copies of the blockchain, they can make calls to full nodes that do, and obtain the information pertaining only to the wallet in question. These so-called light walletscan be run on lower-spec devices, and do not require nearly as many resources to operate.
For IoT use-cases, wherein one would want devices to not only verify transactions but to execute smart contracts, a light wallet would be highly desirable. They can allow even relatively simplistic sensors to sync with the blockchain, and then provide improved security through decentralised storage as outlined above.
Making Blockchain-Supported IoT a Reality
It would be unrealistic to say we’re there already, though.
Blockchain technology remains to be perfected, and has yet to solve certain issues that would prevent it from handling a fully-functional IoT infrastructure:
Blockchain is still an incredibly nascent field, and its energy consumption needs to be tackled before we can see real adoption (Proof-of-Stake is currently being explored, which may remedy this)There’s a further question with regards to privacy of the data being shared: by definition, a blockchain is a public database. Second-layer solutions for the storage and transmission of information (that don’t compromise its privacy) are needed to cater to use cases where this must be kept confidentialAnother major issue facing blockchain tech is scalability: for IoT purposes, it is crucial that transactions are as close to instant as possible – if you’re dealing with a high-throughput of data, it needs to constantly stream. Consider the importance of, for instance, monitoring vital signs of a hospitalised patientThere is yet to be a blockchain iteration that can handle a large amount of transactions per second – one need only look to Ethereum’s gridlock in the wake of CryptoKitties’ release to see this. That said, a number of solutions are being worked on around the globe to combat this issue (Sharding/Plasma on Ethereum or the Lightning Network on Bitcoin are just a few examples)
But, as the technology matures, the future looks bright for IoT and blockchain technologies, which could clearly be highly complementary. In one corner is an increasing amount of sophisticated devices that can collect and relay information to a server, and in the other is a secure network eliminating traditional attack vectors associated with centralised databases. The merging of the two domains, once the kinks are ironed out, promises to revolutionise an innumerable amount of industries.
Blockchain is still an incredibly nascent field, and its energy consumption needs to be tackled before we can see real adoption (Proof-of-Stake is currently being explored, which may remedy this)There’s a further question with regards to privacy of the data being shared: by definition, a blockchain is a public database. Second-layer solutions for the storage and transmission of information (that don’t compromise its privacy) are needed to cater to use cases where this must be kept confidentialAnother major issue facing blockchain tech is scalability: for IoT purposes, it is crucial that transactions are as close to instant as possible – if you’re dealing with a high-throughput of data, it needs to constantly stream. Consider the importance of, for instance, monitoring vital signs of a hospitalised patientThere is yet to be a blockchain iteration that can handle a large amount of transactions per second – one need only look to Ethereum’s gridlock in the wake of CryptoKitties’ release to see this. That said, a number of solutions are being worked on around the globe to combat this issue (Sharding/Plasma on Ethereum or the Lightning Network on Bitcoin are just a few examples)
But, as the technology matures, the future looks bright for IoT and blockchain technologies, which could clearly be highly complementary. In one corner is an increasing amount of sophisticated devices that can collect and relay information to a server, and in the other is a secure network eliminating traditional attack vectors associated with centralised databases. The merging of the two domains, once the kinks are ironed out, promises to revolutionise an innumerable amount of industries.
Forwarded from Data Science
Blockchain Applications in IoT
Blockchain is no longer in its infancy, but it’s still very new. Similar statements can be made about the Internet of Things (IoT). The buzz around blockchain applications in IoT, however, is far more recent. The union of the two verges on the untested—and currently, the unapplied.
Despite the fog of confusion and misinformation around blockchain, it has exciting potential applications in IoT. Ranging from secure device communication (and device identity validation) to distributed data creation and automated data selling, blockchain applications in IoT have many possible benefits—the keyword here, however, is possible.
Many if not all of these possible applications have yet to make it out of a pilot test—or even a laboratory setting. Some roadblocks remain before blockchain applications in IoT can become a scalable standard.
A problem of longevity
he first of these challenges is longevity. Many IoT sensors are designed to be operational in the field for years. Some last for a decade. On the other side is blockchain, whose overall market environment is still highly volatile.
An IoT solution requires reliability, scalability, and endurance to succeed. And we know IoT works. Blockchain, on the other hand, is a much more experimental and episodic technology. It’s basically unproven. Blockchain flares up but then drops off a cliff while IoT grows our food and manages our logistics year in and year out.
Assuming we resolve the underlying tension between the two verticals—and provided we decide to unite blockchain and IoT—we run into another problem. The pre-existing blockchains and their associated host companies are volatile, tied to speculation, and untested. When weighing the risk, you need to look no further than this article on how 46 percent of all initial Coin Offerings (ICOs) have already failed.
So we’re left with the solution of building our own, which can be costly and prohibitively time-consuming. On the cost side, now seems like the time to mention the Hyperledger Fabric Project: an open-source, blockchain-based project from IBM Digital Asset. Hyperledger is configurable and relatively simple to get started with. It’s probably one of the best ways to build a blockchain application on your own.
Even with Hyperledger building, your own blockchain is no easy task, especially since you’ll have to find engineers who are experts on both blockchain and IoT so that they can make intelligent decisions about the entanglement of the two.
Between downright scams and well-intentioned-but-flawed projects, it can be hard to distinguish real from fake. And do you have the resources and time to build your own?
A gap in the chain: human error
he second challenge is security. “Poor security” may sound like a counter-intuitive drawback, since blockchain is supposed to solve all of your security issues. But a blockchain is only as secure as its cryptography. Unfortunately, it’s still people writing the code, and engineers mess up sometimes.
Take Iota, for example—probably the prime example of ‘blockchain’ meshed with IoT. (I say “Blockchain” in quotes because really Iota uses directed asymmetric graphs). With a market capitalization hovering around $1.5 billion, it would be easy to assume that Iota is free from bugs, security holes, and crazy code. That assumption would be wrong.
The Iota affair has been hashed out all over the internet, so to keep it short: Iota did the one thing you should never do in computer security. They rolled their own crypto, which opened them up to a set of collision attacks that would let people steal or give Iota to people illicitly. Additionally, the system itself is based on a ternary rather than a binary system, which slows down their code and makes normal cryptographic functions harder to use. If it can even be hard to trust the poster child of blockchain and IoT, who can you trust?
Blockchain is no longer in its infancy, but it’s still very new. Similar statements can be made about the Internet of Things (IoT). The buzz around blockchain applications in IoT, however, is far more recent. The union of the two verges on the untested—and currently, the unapplied.
Despite the fog of confusion and misinformation around blockchain, it has exciting potential applications in IoT. Ranging from secure device communication (and device identity validation) to distributed data creation and automated data selling, blockchain applications in IoT have many possible benefits—the keyword here, however, is possible.
Many if not all of these possible applications have yet to make it out of a pilot test—or even a laboratory setting. Some roadblocks remain before blockchain applications in IoT can become a scalable standard.
A problem of longevity
he first of these challenges is longevity. Many IoT sensors are designed to be operational in the field for years. Some last for a decade. On the other side is blockchain, whose overall market environment is still highly volatile.
An IoT solution requires reliability, scalability, and endurance to succeed. And we know IoT works. Blockchain, on the other hand, is a much more experimental and episodic technology. It’s basically unproven. Blockchain flares up but then drops off a cliff while IoT grows our food and manages our logistics year in and year out.
Assuming we resolve the underlying tension between the two verticals—and provided we decide to unite blockchain and IoT—we run into another problem. The pre-existing blockchains and their associated host companies are volatile, tied to speculation, and untested. When weighing the risk, you need to look no further than this article on how 46 percent of all initial Coin Offerings (ICOs) have already failed.
So we’re left with the solution of building our own, which can be costly and prohibitively time-consuming. On the cost side, now seems like the time to mention the Hyperledger Fabric Project: an open-source, blockchain-based project from IBM Digital Asset. Hyperledger is configurable and relatively simple to get started with. It’s probably one of the best ways to build a blockchain application on your own.
Even with Hyperledger building, your own blockchain is no easy task, especially since you’ll have to find engineers who are experts on both blockchain and IoT so that they can make intelligent decisions about the entanglement of the two.
Between downright scams and well-intentioned-but-flawed projects, it can be hard to distinguish real from fake. And do you have the resources and time to build your own?
A gap in the chain: human error
he second challenge is security. “Poor security” may sound like a counter-intuitive drawback, since blockchain is supposed to solve all of your security issues. But a blockchain is only as secure as its cryptography. Unfortunately, it’s still people writing the code, and engineers mess up sometimes.
Take Iota, for example—probably the prime example of ‘blockchain’ meshed with IoT. (I say “Blockchain” in quotes because really Iota uses directed asymmetric graphs). With a market capitalization hovering around $1.5 billion, it would be easy to assume that Iota is free from bugs, security holes, and crazy code. That assumption would be wrong.
The Iota affair has been hashed out all over the internet, so to keep it short: Iota did the one thing you should never do in computer security. They rolled their own crypto, which opened them up to a set of collision attacks that would let people steal or give Iota to people illicitly. Additionally, the system itself is based on a ternary rather than a binary system, which slows down their code and makes normal cryptographic functions harder to use. If it can even be hard to trust the poster child of blockchain and IoT, who can you trust?
4 Infamous IoT Hacks and Vulnerabilities
IoT devices are growing exponentially in numbers, but along with growth comes growing pains in securing these devices. We have yet to find a silver bullet to solving IoT security, and consumers and enterprises alike are worried about potential risks involved in implementing an IoT solution, or purchasing a consumer device like a smart lock.
And rightly so. We’ve seen some pretty scary instances of hacking into IoT devices, from smart home products for children to the takedown of the internet. Here are 5 infamous IoT hacks to teach us how important it is to build security into devices in the future.
Mirai DDoS Botnet
Arguably the most infamous IoT botnet attack, the Mirai DDoS (which means distributed denial of service) botnet successfully slowed down or fully stopped the internet for nearly the entire East Coast. The tech company Dyn got the worst of it.
The botnet was able to scan big blocks of the internet for open Telnet ports and log in to them using 61 username/password combos that are frequently used as the default for these devices. Using this strategy, the hacker, a Rutgers University student, was able to amass a botnet army.
Thankfully the botnet was not deployed under malicious intent (apparently they had been trying to gain an advantage in the computer game Minecraft), but it goes to show how potentially dangerous the vulnerabilities in IoT devices can be if accessed.
If you’re looking for a deeper dive into how this was pulled off, Incapsula put together a great analysis of the Mirai botnet code.
Jeep and a Virtual Carjacking
Back in 2016, two hackers, Charlie Miller and Chris Valasek, successfully took control control of a Jeep Cherokee in a completely virtual carjacking. Don’t worry, the driver was in on it to demonstrate the importance of building in security measures.
After finding a vulnerability in the vehicle, the hackers took control of the vents, radio, windshield wipers and more, all while the driver was in motion. Soon after, Miller and Valasek’s faces came up on the car’s digital display – and the driver lost control of his vehicle’s brakes, accelerator, and steering. Eventually they were able to make the vehicle come to a full stop.
The duo released a full list of the most hackable cars, prompting automakers to patch up some software and encourage users to frequently update their systems.
Owlet WiFi Heart Monitor for Babies
Owlet is a heartbeat-monitoring sensor that babies wear in a sock. The device relays heartbeat data wirelessly to a nearby hub, and parents can set up an alert to their smartphones if anything is out of the ordinary.
Seems like it would bring a lot of peace of mind. However, it was discovered that the network linking the WiFi hub to the device is completely unencrypted and doesn’t require any authentication to access. That means that someone can hack into the system if they’re in the range and prevent alerts from being sent out to parent. Yikes.
Devil’s Ivy & the Rube-Goldberg Attack
This year, Wired reported on an increasingly popular, although elaborate, IoT hack known as the Rube-Goldberg Attack. It uses a vulnerability called Devil’s Ivy and works something like this:
The attack starts by targeting a security camera that is vulnerable to an inveterate IoT bug known as Devil’s Ivy.
The attacker finds such a vulnerable camera that’s on the public internet to start the attack.
The attackers uses the Devil’s Ivy exploit to factory reset the camera and take over root access, giving them full control over it.
Exploiting an IP camera can give a hacker complete access to the video feed inside a company building, for example, where they can pick up on employee access/security codes, schedules of security officers, and more.
Really, really bad, right? Researchers at Senrio actually did a public demonstration of this kind of chained attack, hoping to raise awareness about the urgency of addressing the IoT security crisis.
IoT devices are growing exponentially in numbers, but along with growth comes growing pains in securing these devices. We have yet to find a silver bullet to solving IoT security, and consumers and enterprises alike are worried about potential risks involved in implementing an IoT solution, or purchasing a consumer device like a smart lock.
And rightly so. We’ve seen some pretty scary instances of hacking into IoT devices, from smart home products for children to the takedown of the internet. Here are 5 infamous IoT hacks to teach us how important it is to build security into devices in the future.
Mirai DDoS Botnet
Arguably the most infamous IoT botnet attack, the Mirai DDoS (which means distributed denial of service) botnet successfully slowed down or fully stopped the internet for nearly the entire East Coast. The tech company Dyn got the worst of it.
The botnet was able to scan big blocks of the internet for open Telnet ports and log in to them using 61 username/password combos that are frequently used as the default for these devices. Using this strategy, the hacker, a Rutgers University student, was able to amass a botnet army.
Thankfully the botnet was not deployed under malicious intent (apparently they had been trying to gain an advantage in the computer game Minecraft), but it goes to show how potentially dangerous the vulnerabilities in IoT devices can be if accessed.
If you’re looking for a deeper dive into how this was pulled off, Incapsula put together a great analysis of the Mirai botnet code.
Jeep and a Virtual Carjacking
Back in 2016, two hackers, Charlie Miller and Chris Valasek, successfully took control control of a Jeep Cherokee in a completely virtual carjacking. Don’t worry, the driver was in on it to demonstrate the importance of building in security measures.
After finding a vulnerability in the vehicle, the hackers took control of the vents, radio, windshield wipers and more, all while the driver was in motion. Soon after, Miller and Valasek’s faces came up on the car’s digital display – and the driver lost control of his vehicle’s brakes, accelerator, and steering. Eventually they were able to make the vehicle come to a full stop.
The duo released a full list of the most hackable cars, prompting automakers to patch up some software and encourage users to frequently update their systems.
Owlet WiFi Heart Monitor for Babies
Owlet is a heartbeat-monitoring sensor that babies wear in a sock. The device relays heartbeat data wirelessly to a nearby hub, and parents can set up an alert to their smartphones if anything is out of the ordinary.
Seems like it would bring a lot of peace of mind. However, it was discovered that the network linking the WiFi hub to the device is completely unencrypted and doesn’t require any authentication to access. That means that someone can hack into the system if they’re in the range and prevent alerts from being sent out to parent. Yikes.
Devil’s Ivy & the Rube-Goldberg Attack
This year, Wired reported on an increasingly popular, although elaborate, IoT hack known as the Rube-Goldberg Attack. It uses a vulnerability called Devil’s Ivy and works something like this:
The attack starts by targeting a security camera that is vulnerable to an inveterate IoT bug known as Devil’s Ivy.
The attacker finds such a vulnerable camera that’s on the public internet to start the attack.
The attackers uses the Devil’s Ivy exploit to factory reset the camera and take over root access, giving them full control over it.
Exploiting an IP camera can give a hacker complete access to the video feed inside a company building, for example, where they can pick up on employee access/security codes, schedules of security officers, and more.
Really, really bad, right? Researchers at Senrio actually did a public demonstration of this kind of chained attack, hoping to raise awareness about the urgency of addressing the IoT security crisis.
IoTers, thank you for your activity!😉
I sent a course for IoT Beginners to our chat👌
I sent a course for IoT Beginners to our chat👌
Forwarded from Data Science
Forwarded from Deleted Account
A technical question;
What is the difference between PWM and Analog output
What is the difference between PWM and Analog output