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