-
Quote
A SoC or Raspberry PI would triple/quadruple the BOM cost for the circuit
Are you sure? It looks like you can still get Model B+ Pis for under $30, and It would be "challenging" to put together a cpu+wiznet+magnetics+connectors for less than $10...
I have the same sort of aversion to designing in "module level" components, but I'm starting to feel like that's more habit than something I can really justify...QuoteWeird that such a common interface/protocol is still not mainstream good quality open source available
For small micrcontrollers, which were never a target for the protocols in question. The "big system" TCP/IP code is so common/open that I start to worry about lack of diversity in implementation :-(
-
For small microcontrollers, which were never a target for the protocols in question.
Indeed were ,past tense, the whole game has changed.
As the trend towards the (wrongly choosen name) "IoT" is now getting huge momentum, PoE is mature (so no mains connection needed anymore) and guestimates are that in 10 years time billions of small resource constrained devices will be networked my worst nightmare is that those constrained IP stacks will lack (proper) security , receive no security updates and that those $5-$10 IP connected gadgets will become the main entry point for hackers to gain access to your home network. And I am not alone, MacAfee has already written a report identifying this small embedded device security thread as one of the major threads for the coming years.
Also ARM has waken up and for instance bought a company with a constrained TLS implementation this year (Polar), so they can sell their Cortex cores with some decent IP stack (unfortunately only available for the full package expensive compiler licenses).
So if the BOM price is not a problem I can only advise for serious IP connected devices to:
- be built upon an OS with good support and security updates,
OR keep the whole "constrained devices network" fully seperated from the business/home network. -
Don't forget the SD card needed for the Raspberry Pi, the extra assembly steps, freedom of connector placement, etc. I already did the calculation (the potential customer initially wanted to use the Rpi) and a solution with a wiznet+microcontroller is much cheaper. And since the device is to be mass produced I'm not keen on relying on a single source module. I already got a problem with a different project where the manufacturer of a module made an incompatible new version after one year despite the promise to keep the modules available for at least 10 yearsQuoteA SoC or Raspberry PI would triple/quadruple the BOM cost for the circuit
Are you sure? It looks like you can still get Model B+ Pis for under $30, and It would be "challenging" to put together a cpu+wiznet+magnetics+connectors for less than $10...
Security will be adressed as well. IMHO the biggest problem is not space constrained devices but the fact that many developers and managers are totally clueless about security. Once the required functionality has been implemented the product goes into the shops. Hacking a wired or wireless home control system is a piece of cake. I agree this will get worse but we have seen the same with OS development and websites. In the beginning security wasn't considered and several wakeup calls where needed to get things right. The 'IoT' devices will go through a similar learning curve. -
Quote
single source module.
Single source module, single-source chip. What's the difference?
(although Wiznet, like FTDI, seems to do reasonable and useful things in their followon products...)
-
Chips are usually produced in larger quantities, are aimed at a wider audience and cost more to design than modules so chips ought to have a longer availability to recoup the engineering costs.
-
Using Linux or the Linux TCP/IP stack isn't an option on a microcontroller. There are not enough resources on a microcontroller to run that software. Besides that the Linux kernel source code is a complete mess so getting the TCP/IP stack out in one piece will be a large amount of work.
Since in my projects if the project outgrow a big AVR (like ATmega2560) I go directly to either Raspberry Pi 2 or Allwinner A31s (both rocking quad core Cortex-A7), Linux is usually a must-have anyway. And a networking requirement means the project immediately outgrows the AVR since I leave no networking communication unencrypted for security reasons, and AVR obvious cannot process proper SSL or IPSec even with Wiznet chipsets.
Unsecured IoT communication is a big no-no since one router breach and you are screwed. And I don't think a micro have enough oomph to run any good, proper cryptography. You can also look around for other chips that supports Linux like Samsung S3C2410 or Intel Quark (that one runs x86 by the way, and supports PCI Express so higher-grade computer-like parts can be used) -
There are a few microcontrollers with a crypto module, with AES and DES. Such as STM32F7.
And remember that Ethernet =/= Internet. There are a few advantages of Ethernet, such as speed, solid hardware and cheap cabling. -
Unsecured IoT communication is a big no-no since one router breach and you are screwed.
Explain how exactly...
Security is more than pouring some encryption over a solution and be done with it. As a rule of thumb: a system should remain secure (=detect fraud) when the encryption is broken. Security stands on 3 pillars: Authorisation, Authentification and Accounting; encryption isn't even mentioned specifically. -
Unsecured IoT communication is a big no-no since one router breach and you are screwed.
Explain how exactly...
Security is more than pouring some encryption over a solution and be done with it. As a rule of thumb: a system should remain secure (=detect fraud) when the encryption is broken. Security stands on 3 pillars: Authorisation, Authentification and Accounting; encryption isn't even mentioned specifically.
For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day. -
There are a few microcontrollers with a crypto module, with AES and DES. Such as STM32F7.
And remember that Ethernet =/= Internet. There are a few advantages of Ethernet, such as speed, solid hardware and cheap cabling.
Not much difference between Internet and Ethernet actually, since they all run TCP/IP and have largely the same threat model (e.g. a laptop can get breached in the same way) -
Just found this: a US$2 chip that have the same oomph of BBB and in a easy-to-solder TQFP package: Allwinner A13. Couple that chip to some DRAM, a microSD card (or eMMC), an Ethernet PHY chip and a bunch of 1117 regulators, you get a full blown Linux platform that runs proper security and cryptography stacks.
-
Now explain how this cannot happen when running Linux in the device.Unsecured IoT communication is a big no-no since one router breach and you are screwed.
Explain how exactly...
Security is more than pouring some encryption over a solution and be done with it. As a rule of thumb: a system should remain secure (=detect fraud) when the encryption is broken. Security stands on 3 pillars: Authorisation, Authentification and Accounting; encryption isn't even mentioned specifically.
For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day. -
Now explain how this cannot happen when running Linux in the device.Unsecured IoT communication is a big no-no since one router breach and you are screwed.
Explain how exactly...
Security is more than pouring some encryption over a solution and be done with it. As a rule of thumb: a system should remain secure (=detect fraud) when the encryption is broken. Security stands on 3 pillars: Authorisation, Authentification and Accounting; encryption isn't even mentioned specifically.
For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day.
I was saying that it is more difficult to set up proper cryptography stack on a micro. Linux can also be improperly configured but it is a lot easier to achieve the proper security stack than a micro since:- Linux's network stack is a lot better tested than whatever you can roll for yourself or used in chips like W5200 and friends - it is used in 95% of all servers worldwide
- Linux-based platform have easier to use, well tested security software like OpenSSL or OpenSwan
- In some cases you don't even need to write code to secure your entry points.
The last point can be proved using any of those setups:- Apache server + mod_ssl + mod_authnz_external + pwauth. mod_ssl will give your Apache Web server SSL support - making sure the communication cannot be eavesdropped, and mod_authnz_external + pwauth will allow you authenticate the connection using an encrypted (shadowed) password database (which is also the system's main user database, accessed vis PAM.) Your application code need to be Web based and served through the Apache server here.
- StrongSwan alone. This implements the IKEv2 VPN protocol which will authenticate both hosts of the connection as well as the user. It can carry any protocol safely.
- StrongSwan or OpenSwan alone. This implements a simpler IPSec protocol that authenticates both hosts of the connection. Your code need to be aware of this though.
- StrongSwan or OpenSwan + xl2tpd + pppd. This combo implements the L2TP/IPSec VPN protocol which have a similar but slightly weaker level of protection than IKEv2.
- pptpd + pppd. This implements PPTP VPN protocol. Not so useful now as PPTP is considered broken
-
Linux's network stack is a lot better tested than whatever you can roll for yourself or used in chips like W5200 and friends - it is used in 95% of all servers worldwide
95%? Really? I rather doubt it.QuoteLinux-based platform have easier to use, well tested security software like OpenSSL or OpenSwan
You choose OpenSSL as an example of well tested, secure software? Bwaaahahhahah. -
An encrypted path between an IoT device and a host can be achieved using a crypto engine in a microcontroller and at the 'other side' with much less chance of configuring it wrong or leaving other holes open. SSL is intended to connect securely between random hosts/devices. An IoT device in general does not do that; it usually is paired with one or more 'hosts' and does not have a user(interface) to supply credentials. All in all the security model is entirely different. The key problem with an IoT device is authentification. How can a host be sure it is talking to the right device and how can the IoT device be sure it is talking to the right host?
-
For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day.
In both your examples, the real security failure wasn't in the IOT device at all, but something else (the Wi-Fi router, laptop, or user for misconfiguring security on those devices).
I'm no security expert, but out of curiosity I searched and found examples of low-end MCUs running RSA and AES-128. Probably not fast, but an IOT device is not going to be transferring megabytes per second. I agree that if you roll your own, it's likely to be flawed, but that's not so bad if it's a secondary security method - because then it requires successful exploit of two different flaws, rather than just one. (Whereas with a router and IOT device both running Linux, and going without updates for years as is common for embedded devices, the likelihood of discovery of a a single flaw that works for both increases; especially with complex security methods. I wonder how many embedded Linux devices are still susceptible to Heartbleed?)
But honestly, if someone has breached my Wi-Fi or laptop, a scary but harmless light show would be the least of my worries. In fact it would be a welcome notification. I say leave the lights unprotected, let them function as a honeypot.
A heater is a more serious matter. But starting a fire? No heater should be capable of setting the room on fire, simply by commanding it to, period. Sane thermostatic limits should be built-in, hardwired, and functioning independently of the MCU. -
An encrypted path between an IoT device and a host can be achieved using a crypto engine in a microcontroller and at the 'other side' with much less chance of configuring it wrong or leaving other holes open. SSL is intended to connect securely between random hosts/devices. An IoT device in general does not do that; it usually is paired with one or more 'hosts' and does not have a user(interface) to supply credentials. All in all the security model is entirely different. The key problem with an IoT device is authentification. How can a host be sure it is talking to the right device and how can the IoT device be sure it is talking to the right host?
Any IKEv2, L2TP/IPSec and plain IPSec all have mandatory host authentication using a PKI (all three) or pre-shared key (L2TP/IPSec and plain IPSec), and HTTPS supports (optional) client certificate authentication which can also be used as a form of host authentication. Those are all tested and trusted methods. -
For example if Alice have an IoT capable room heater that is not properly secured. Mallory, walking by her apartment with his smartphone, can breach her Wi-Fi security (the router breach I am talking about), and then command the heater turn on full power if the heater is not properly secured. This will at least turn Alice's room into a sauna and take a huge chunk out of her electricity bill when she is back, or even set her room on fire. This is a double Authentication breach.
Or for some Internet-accessible IoT gadgets like Philips Hue, Mallory can spread a malware that detects the presence of such a gadget into Alice's laptop (thus bypassing the router which is also a firewall, effectively breaching it) and put on a freaky light show and scare the living s**t out of Alice in the least expected hour of day.
In both your examples, the real security failure wasn't in the IOT device at all, but something else (the Wi-Fi router, laptop, or user for misconfiguring security on those devices).
I'm no security expert, but out of curiosity I searched and found examples of low-end MCUs running RSA and AES-128. Probably not fast, but an IOT device is not going to be transferring megabytes per second. I agree that if you roll your own, it's likely to be flawed, but that's not so bad if it's a secondary security method - because then it requires successful exploit of two different flaws, rather than just one. (Whereas with a router and IOT device both running Linux, and going without updates for years as is common for embedded devices, the likelihood of discovery of a a single flaw that works for both increases; especially with complex security methods. I wonder how many embedded Linux devices are still susceptible to Heartbleed?)
But honestly, if someone has breached my Wi-Fi or laptop, a scary but harmless light show would be the least of my worries. In fact it would be a welcome notification. I say leave the lights unprotected, let them function as a honeypot.
A heater is a more serious matter. But starting a fire? No heater should be capable of setting the room on fire, simply by commanding it to, period. Sane thermostatic limits should be built-in, hardwired, and functioning independently of the MCU.
The big problem is that the Intranet IoT device could have defended itself but it didn't. Also some IoT gear establish connection (or even open listening ports) to the Internet so it have to defend itself.
It is possible for a heater to ignite itself without breaching the temperature control if the heater is not well maintained or some flammable material is put too close to it. -
Way to often you find an alarm system with a web interface using the default password.
They'll tell you it's safe because nobody can access the network.... Right... But what if an employee turn rogue?QuoteYou choose OpenSSL as an example of well tested, secure software? Bwaaahahhahah.
You say that, but because it is used widely they did find the bug. Which might not be the case with a proprietary implementation.
The bug might live for years before someone starts exploiting it, and then it's too late. -
Way to often you find an alarm system with a web interface using the default password.
They'll tell you it's safe because nobody can access the network.... Right... But what if an employee turn rogue?QuoteYou choose OpenSSL as an example of well tested, secure software? Bwaaahahhahah.
You say that, but because it is used widely they did find the bug. Which might not be the case with a proprietary implementation.
The bug might live for years before someone starts exploiting it, and then it's too late.
I support this.
Security system auditing have to be done on a source code level, and if you used the built in crypto engine of a MCU it is next to impossible to audit that, which will cause some security aware clients not to select your system. OpenSSL had a vulnerability but thanks to its being open source the bug is fixed within hours and within weeks everybody patched their OpenSSL installation. On the other side Microsoft Windows is always thought to have backdoors by NSA and that is for ages.
For security packages I would prefer using some tested and trusted, well audited open source products like OpenSSL (1.0.1g+), GnuTLS, StrongSwan, OpenSSH or GNU Privacy Guard, even though using those means I have to use a Linux-capable MCU. -
I second Nico, if you have a constrained device that only needs to communicate with a single or very restricted set of other constrained devices , you can implement a symmetric (PSK) key based security layer IF you know what you are doing (so stay close to the known security implementations/standards).
This means setting up sessions using good randoms on both sides and key derivation of the PSK, aka "known partners design patterns".
Using TLS is only valid if you need (open) access to a larger audience, even unknown third parties that you need to identify based on their certificate.
That automatically involves public key cryptography which uses lots of RAM due to the large keys (yes even with ECC it takes up a lot of RAM and cycles).
Using OpenSSL even with a supersmall ciphersuite like AES-CCM8 takes over 30kB flash and 10kB of RAM which can be reduced but takes up lots of time and again you exactly need to know what you are doing or you can introduce weaknesses.
So it all depends on the implementation/usage of the device if OpenSSL for instance makes sense or is just overkill.
The claim that OpenSSL is more safe because it is open source was a bit debunked IMO by the latest bug finds, they were introduced couple of years ago and nobody checked it or found it. It was introduced to the fault of 1 programmer, so there is no good review in place or testing or other kind of checks and balances. Because it is open source and used in a lot of systems you can be sure that hackers and government agencies are checking this code also and if they find something they are not going to share it.
-
I should link this. It is very important that you never apply this kind of security. Even tough it's tempting to use in embedded systems.
https://en.wikipedia.org/wiki/Security_through_obscurity
Example: using a magic packet is not security.
http://wiki.openwrt.org/toh/netgear/telnet.console
Deriving your password key from mac or name is not security. Even if nobody but the engineers know.
http://www.gnucitizen.org/blog/default-key-algorithm-in-thomson-and-bt-home-hub-routers/ -
The claim that OpenSSL is more safe because it is open source was a bit debunked IMO by the latest bug finds, they were introduced couple of years ago and nobody checked it or found it.
That's hardly an open source only problem. And they did find it, otherwise you wouldn't know about it
TBH as bad as that could have been it wasn't due to quick reactions when the problem was found, and OpenSSL does have a good track record. As much as I prefer OSS I'd say that is more important when making a decision on something like that.
-
I second Nico, if you have a constrained device that only needs to communicate with a single or very restricted set of other constrained devices , you can implement a symmetric (PSK) key based security layer IF you know what you are doing (so stay close to the known security implementations/standards).
This means setting up sessions using good randoms on both sides and key derivation of the PSK, aka "known partners design patterns".
Using TLS is only valid if you need (open) access to a larger audience, even unknown third parties that you need to identify based on their certificate.
That automatically involves public key cryptography which uses lots of RAM due to the large keys (yes even with ECC it takes up a lot of RAM and cycles).
Using OpenSSL even with a supersmall ciphersuite like AES-CCM8 takes over 30kB flash and 10kB of RAM which can be reduced but takes up lots of time and again you exactly need to know what you are doing or you can introduce weaknesses.
So it all depends on the implementation/usage of the device if OpenSSL for instance makes sense or is just overkill.
The claim that OpenSSL is more safe because it is open source was a bit debunked IMO by the latest bug finds, they were introduced couple of years ago and nobody checked it or found it. It was introduced to the fault of 1 programmer, so there is no good review in place or testing or other kind of checks and balances. Because it is open source and used in a lot of systems you can be sure that hackers and government agencies are checking this code also and if they find something they are not going to share it.
This is a kind of Security by Obscurity which is flat out useless if your communication channel is breached. When designing a security protocol you cannot assume the underlying communication channel is safe - instead you should always assume the channel is breached and all communication going over wire is transparent to everybody. This is why even for the most trusted channel at least some Diffie-Hellman is required. And since for IoT applications the controlee must make 100% sure who is controlling it.
Remember that any wireless solution can be listened to and analysed (a US$10 RTL-SDR dongle is enough to do this, and I have one.) Wired solutions are more difficult to breach but that does not mean nobody can sneak up to an unprotected section of your communication cable and attach a bug to it. -
I should link this. It is very important that you never apply this kind of security. Even tough it's tempting to use in embedded systems.
From a functional point of view: security is always obscurity. Either the encryption method is a secret (obscure) or the key is secret (obscure). Encryption systems needing to be open to the public is just a (strong) opinion. As others pointed out it doesn't help to prevent bugs. The fact is that an open encryption system takes a lot more CPU cycles than a proprietary one and either will be broken into at some point in the future due to increasing CPU power and analysis of encryption systems.
https://en.wikipedia.org/wiki/Security_through_obscurity
Anyway, you can use any encryption method you want in an IoT device. If someone is serious about hacking your system they'll have the flash contents read and then they'll have the encryption keys and encryption method. This would allow them to read and write messages as if they are the IoT device. However there are ways to implement a protocol in such a way that this is easy to spot.