The cost of "security"

[TomS_]

What about ::1, ff01::1 or ff02::1?

Still not related to the OS, and good luck reaching it beyond the local host. 

[TomS_]

I didn't read the whole thread but what I'd really like to know is this: WHY do these manufacturers make all of these devices so that they CAN be reprogrammed?  Why don't they just put all of the OS in ROM and then NO ONE could hack, not even the OEM.

So when they find a bug, rather than being able to issue a firmware update to fix it, you just end up with ewaste instead? Or buggy devices that remain vulnerable because they cant be fixed? Yea... no.

[madires]

What about ::1, ff01::1 or ff02::1?

Still not related to the OS, and good luck reaching it beyond the local host. 

ff02::1 is link-local. 

[peter-h]

you just end up with ewaste instead?

Which results in more hardware sold, which is a good thing, isn't

Almost nobody in the IT sphere does firmware updates more than a year or two out.

There is also a risk of bricking a whole load of boxes in one go, which is commercially too great a risk, so firmware updates would in any case be made available only to users who complain, and you tell them to go it gradually.

The box I am working on will certainly be able to download a new image from a private server, validate it, and flash it. I already have that working, except for the download.

[gmb42]

Usually the issue with the browsers, which use a pre-installed CA bundle from known authorities

This is on a tangent, but I sometimes wonder how easy it may be for an attacker to simply replace these certificates in somebody's Chrome etc installation, install a fake DNS server on their PC, and then use that to capture their banking credentials. The eventual defence would be only that setting up a new payee usually involves answering a phone call...

Users can be persuaded to install "bad" certificates themselves.  IMHO, this is the major problem with self-signed certs that are not installed by a management system (e.g. Group Policy) and have workflows that ask users to manually install a cert from a link.  Teaches them really bad behaviour.

And this is the problem: if you can't guarantee security of the client machine, any server certs stored on it are meaningless. And in most IOT scenarios this is difficult because getting onto the LAN is quite feasible, with an "inside job" attack (an email with a trojan, etc).

Agreed, and a there's a big difference here between a general purpose PC which as all the tools to install random CA certs but is also likely to have management software (e.g. AV etc) that tries to eliminate bad certs, and a specific device (IoT thing) that actually makes it difficult to modify the CA certs.

[peter-h]

Let's say you are doing MQTT so you are an MQTT client, and you are using AWS as the MQTT broker.

I hope I have the required proportion of correct corporate lingo

Am I right in that the client cannot do authentication with just one certificate, and needs to store the whole certificate chain (currently around 200k)?

This appears to be the case for every application where one is accessing any kind of "public" server - not least because their certs expire so fast so your only hope is to get the current one and check its signatures. Only with a private server, under your own control, can one make do with a single certificate.

This is very relevant to MbedTLS which needs 200k of RAM to do the above.

How do people deal with this, given how much IOT stuff has small CPUs? Perhaps they don't authenticate the server.

[tellurium]

Am I right in that the client cannot do authentication with just one certificate, and needs to store the whole certificate chain (currently around 200k)?

No, that is not correct.
AWS IoT demands two-way SSL.
Meaning, a client verifies server against the CA, plus it sends its own cert to the server - so a server can auth client on its side.
Thus, an AWS IoT client needs to store:
  - a CA bundle, that's basically one cert. Maybe two if you want to get fancy: one RSA, one EC
  - its own cert
  - its own private key

[NorthGuy]

Am I right in that the client cannot do authentication with just one certificate, and needs to store the whole certificate chain (currently around 200k)?

This is not a chain, but rather a collection. A collection of trusted certificate authorities.

When a peer passes you a certificate, there's no way for you to know if the certificate is real or not. To verify, the certificate is signed by a trusted authority, one of the many. You look up your own collection of the trusted authorities and find if the authority who signed the peer's certificate is in your collection. If it is not, you won't trust the certificate.

You can roll out your own certificate authority. Then you only need one trusted certificate in your list - your own. With that, you will trust the certificates you have issued by yourself, but will not trust anything else - such as Verisign certificates. This is because Verisign is not on the list of your trusted authorities. If you want to trust Verisign certificates, you must put Verisign's root certificate into your collection of trusted sources. The more sources you want to trust, the bigger is you trusted sources collection.

The collections included with browsers is a list of certificates of authorities which are commonly trusted. Whether you want to trust these authorities, it's up to you. Any of these certificate authorities can be hacked, commit fraud, or otherwise produce bad certificates. Although chance of this is very small, it's a risk for you because you have chosen to trust the bad authority.

[Kjelt]

Whether you want to trust these authorities, it's up to you. Any of these certificate authorities can be hacked, commit fraud, or otherwise produce bad certificates. Although chance of this is very small, it's a risk for you because you have chosen to trust the bad authority.

Diginotar anyone ?

[madires]

And don't forget CRLs (specifically ARLs)!

[IDEngineer]

The "S" in IOT stands for "Security".

[tellurium]

The "S" in IOT stands for "Security".

Nice joke, however I don't get those people who rant about lack of security in IoT.
IoT is not a particular technology to rant about it.
Likewise, one can say "The S in Internet stands for Security". Or, "The S in Microcontroller stands for security" .

[IDEngineer]

The point is, people need to have realistic expectations. IOT as typically architected is, almost by definition, insecure. If that's acceptable to you, fine. But don't complain later.

[mikerj]

The "S" in IOT stands for "Security".

Nice joke, however I don't get those people who rant about lack of security in IoT.
IoT is not a particular technology to rant about it.
Likewise, one can say "The S in Internet stands for Security". Or, "The S in Microcontroller stands for security" .

Because security on your toaster is a non-issue until it's made "smart" enough to be connected to the internet.  Would you want to wake up and find you've been subject to a Denial of Toast?

[peter-h]

The overriding issue here is that the trade mags need catchy headlines, and the internet needs loads of clickbait.

And "security" is always a good topic, along with "privacy" and all the great spinoffs, like google downranking search results which are not https. I think these days they are mostly removed altogether... why?? Stupidity. Need 10000 bit crypto because some academic showed that 1000 bits can be cracked (in 1000 years and only if you have 10TB of RAM and 1TB of known plaintext) Most editors are clueless and even the best ones are "failed engineers". People are going crazy over privacy these days. GDPR this and GDPR that.

The world has filled up with BS and IOT is just another load of BS.

Even in applications where IOT has value (not fridges or toasters), IOT boxes will never be secure enough over time to avoid IOT getting a really crappy reputation.

What are the views on dyndns? Some years ago that was all the rage, for servers on a dynamic IP. You still have to get the domain hosted somehow.

[madires]

What are the views on dyndns? Some years ago that was all the rage, for servers on a dynamic IP. You still have to get the domain hosted somehow.

There are still many DynDNS services (free and paid) to choose from. But you need to ask your ISP if any ports are blocked by default since they often block TCP 25 (SMTP) and other common sources of trouble.

[SiliconWizard]

Yeah. Of course the problem with DynDNS is that the service you chose may shut off unexpectedly and you'd lose access. There are usually very few guarantees.

[IDEngineer]

Yeah. Of course the problem with DynDNS is that the service you chose may shut off unexpectedly and you'd lose access. There are usually very few guarantees.

That will always be the weakness of depending upon outside third parties for access to your stuff.

There's an additional problem if you trust your data to the "cloud": Ownership and privacy. US courts have ruled that unless you directly control the equipment hosting your data, you "lose expectation" of privacy and have far weaker claims for infringement or undesired access. This is why attorney firms generally don't use "cloud storage" and still run their own in-house hardware - they understand the legal risks of not retaining control of their equipment and the data hosted on it.

I personally try very hard to not store my data on any sort of "cloud" services, and my company does the same. The expectation around here is that if we store data outside our own equipment it's likely to be publicly readable forever. Some of our customers use "cloud" type services but we almost always treat them as read-only from our perspective. If THEY choose to put data we've created for them on the "cloud" that's THEIR assumption of risk.

Bottom line: If you let some third party get between you and your property, you lose a lot of control/rights and assume a LOT of risks. Caveat emptor... "free" is almost never worth more than you paid for it.

[peter-h]

Of course the problem with DynDNS is that the service you chose may shut off unexpectedly and you'd lose access

Sounds like all of IT then

Almost nothing in IT just keeps running for ever. One can get very close to it running some private services, but servers need patching and general cleanups when logfiles overflow, certificates expire, etc. You can remove one of these (e.g. fronting with Cloudflare takes care of certificates) but you can't remove them all. It's a constant cost.

All very relevant to the private servers (with a public https front end) which most IOT needs. Got to be funded somehow, and it can't be funded by a stream of hardware sales.

I have had stuff running on in-house hardware and it isn't cheaper or more reliable. You need a really big UPS for a start. The one thing you do get that way is vast storage which would be expensive on virtual hosting (this is due to the pricing structures of hosting companies, presumably because they don't want BW to be eaten by hosting of p0rn videos, but bandwidth-based billing is a lot harder). Probably at the high end of corporate stuff one can make it work.

[SiliconWizard]

Which is why I suggested to stay away from all that if you can.

[Nominal Animal]

I much prefer a model where each internet-enabled device has a fixed address to a local host, and a pair of keys and passphrases used for encrypting that connection using a known-good algorithm (say, AES256) and identifying the other end, set only with physical access to the device.

Physical access itself would also need a simple key, perhaps one based on factory-fused chip ID or something.

At bootup, reset, or loss of connection, the device makes an initial (TCP) connection to the local host.  The device initiates a handshake with the host, ensuring that both ends know the shared secrets without transferring any of the secrets themselves, and transferring initial vectors for use in the encryption in a secure (un-overheardable, un-replayable) manner.  After this, this (TCP) connection is the only one that the device supports.  (Actually, having more than one allowed local host + gateway pairs, for failover purposes, would be nicer; with TCP connection attempts coming from the failover addresses only answered if there is no current connection or the current connection is stale/timeout.)

The device only needs to expose an UART (four pins: VCC, TX, RX, GND), and one could define a simple, compact format for transferring the configuration data.  Heck, a five-pin SPI might work even better (since it has a separate clock line).  One could then configure such devices using an USB-UART/USB-SPI cable, or even make a dedicated configuration device for field work.  Heck, it ought to be possible to combine even firmware updates to the format...  As an open one, many different devices could use the same format (and therefore config devices and software).

For catering to current practices, have the devices support DHCP, and be individually preprogrammed to use some Cloud host.

Why not?  Because us humans tend to be rather stupid, and equate security with secrecy, even though best security is the kind that is secure even when completely public (like AES encryption standard).

[tellurium]

For catering to current practices, have the devices support DHCP, and be individually preprogrammed to use some Cloud host.

What protocol would they (a device and a cloud) talk?

[Nominal Animal]

For catering to current practices, have the devices support DHCP, and be individually preprogrammed to use some Cloud host.

What protocol would they (a device and a cloud) talk?

Irrelevant with respect to security, since the point is that it is the underlying TCP transport that is encrypted with a symmetric cipher.

In other words, any protocol you want.  The only limitation is that individual logical messages do need to be padded to the cipher block size, or else you need to implement a transport (blocking) protocol on top of the data stream, so that one can construct a full cipher block with only partial data used.

I do have my own: a transport protocol that supports multiplexing multiple independent binary streams, and a list-based format to replace XML with something easier to produce and consume with minimal memory resources.  But these are a matter of use case, since they are all a trade between computational efficiency, protocol overhead, and personal taste.  (Some love netstrings and protocol buffers, others prefer stream formats.  HTTP and HTML are neither, with lots of historical baggage, and require surprisingly large amounts of RAM to properly support.)

[tellurium]

Irrelevant with respect to security, since the point is that it is the underlying TCP transport that is encrypted with a symmetric cipher.

No it is not irrelevant.

You're talking about a simple serial config protocol that many devices/vendors could employ and standardise on. I guess the same applies for the cloud? Then, a standard, well known, simple protocol should be employed for communication. And it does exist : it is called MQTT. Simple, low-overhead, etc etc. And if we're talking about standard MQTT, all your reasoning about custom self-made AES based security is irrelevant, cause you'd need to use TLS.

Of course you can roll out your own auth/encryption mechanism based on AES or whatever, and use you custom TCP server for communication, but I expect the only company that is going to use that, will be your own.

[Nominal Animal]

Irrelevant with respect to security, since the point is that it is the underlying TCP transport that is encrypted with a symmetric cipher.

No it is not irrelevant.

From my point of view it is, because the entire point is to avoid the costly and slow TLS connection setup, by using already existing symmetric cipher key pair, one key per direction.  You know, the one that can take a couple of seconds on an average 32-bit ARM MCU?  When you already have a shared secret per direction, the connection setup can be made much more lightweight using a suitable cryptographic hash.  You do need reliable random nonce generator (I recommend incremental counter and a unit-specific key, put through that same hash function), so it isn't trivial to do it right, but it worked sufficiently well before we standardized on SSL and then TLS.

MQTT ... use TLS

Yes, we absolutely must make all our devices trivially DDOS'able.

The entire point is to achieve security and robustness with currently available microcontrollers and their very limited resources.
TLS has an extremely high connection cost, and requires quite a lot of resources, which is exactly why they are not the best option for current microcontrollers.

That said, I wouldn't mind using MQTT on top of a TCP/IP connection encrypted with a suitable symmetric cipher and pre-shared keys.

I expect the only company that is going to use that, will be your own.

Why should I care?  I only care about the devices I use and rely on myself.  I was just describing what I personally prefer, because I know it works better than the alternatives.

It is people like you who insist on slow, bloated implementations that only seem to work in reality, because on paper they look so hip and cool.  Just like network router manufacturers who seem to hire highschoolers to fork a random Linux installation for their devices, cobbled together with spit and bubblegum, full of security holes and inane choices.  Very, very few companies actually use the people who know how to do that stuff, too.