Author Topic: Embedded IoT device check  (Read 2233 times)

0 Members and 1 Guest are viewing this topic.

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Embedded IoT device check
« on: January 17, 2023, 10:04:38 am »
Hi,

I'm quite new to the security stuff. We have an IoT device under development and I feel like I'm still doing some things cargo cult way, which I don't like. So would greatly appreciate a sanity check into the fundamental ideas (and smaller details, too). Anything weird or incorrect, please make a comment. I hope this is helpful to others, too, since the internet has a lot of information about configuring server infrastructure for things like HTTPS, but little about IoT client devices (but many small startups selling complete secure MQTT over TLS library solutions; but for now, we want to gain understanding and do it ourselves using widely used libraries, instead of building trust to small unknown companies).


* The device actually needs bidirectional exchange of data (information / commands) between the server ("cloud") and device, this is not an "IoT for fun" coffeemaker
* The device is complex enough that remote firmware update is essential
* Payloads are from a few bytes to a few hundred bytes per second. Latency of messages or opening the socket is irrelevant.
* Primary threat model is taking control of someone's device, feeding it unwanted commands directly, or by replacing the firmware with a malicious version
* Forward secrecy is good to have, but being able to decipher collected data years or decades later is not catastrophic (the old information is not that sensitive).

* Device only implements TLS client, and never acts as server
* Device only connects via a single TCP socket to an MQTT broker managed by us
* MQTT is used for user access control on per-topic basis (e.g., only client ABCD1234 can subscribe and publish to private/ABCD1234/#)
* Device firmware update is performed using MQTT messages, subject to the same access control

* We generate our own CA certificate (one with multiple broker domain names? Or multiple CA certs, one for each possible broker domain name?)
* During firmware flashing, each device is generated with unique 32-bit device_id, and unique private key
* Private key is not stored anywhere else except device flash (production flashing/testing PC can pipe the key to the SWD programmer software in order to not store it on disk, or even airgapping this production PC is possible).
* Getting to the private key of the device is possible with physical access to the debug pins, but with physical access, one could replace the whole device with another legitimate device under their control anyway, so leaking the private key only sacrifices the forward secrecy of that single device
* During flashing, CSR and public key are generated from the private key.
* CSR will stay unchanged for the whole product lifetime, right?
* In case new CA certs need to be installed, new client public keys can be generated based on the stored CSRs, and client public certs updated without ever touching the private key, right?
* Common Name of client certificate = unique 32-bit device ID (which also appears in mqtt topic name)
* Server which collects data and controls all the devices, has its own public and private key. The safety of this server and its key management is possibly the most important part of the whole shebang, right?
* Another threat model to be taken seriously is firmware bug allowing extraction of private key, which resides in memory. (MCU in question has no MMU, so all the code needs to be written carefully.)
* Although one would need to gain some kind of access to the devices to be able to exploit the bug. With DNS poisoning, one could get the devices to connect to a false broker, but not having the correct broker's private key, the authentication of the server would fail and the exposure area for the firmware would be greatly limited, no?

* Protocol is TLS1.3 only, getting rid of all obsolete/unsafe cipher suites.
* Client will only support the only "MUST" ciphersuite of TLS1.3 specification, namely TLS_AES_128_GCM_SHA256
* I assume TLS_AES_128_GCM_SHA256 is considered safe. I assume it offers some resource savings over TLS_AES_256_GCM_SHA384 given CPU and memory constraints. (Have not tested yet, though.)
* Interwebz says TLS_AES_128_GCM_SHA256 has a 128-bit key (source: IBM). Internetz also says TLS1.3 has minimum key size of 256 bits (source: IBM). These are in contradiction. I have no idea what components there are in a key and how the "key size" is defined. Binary key files are always significantly longer but they contain some metadata etc. Maybe I should not care and just call the functions with the correct arguments, but I'm just wondering.

* MCU is Cortex-M4 at 64MHz
* For encryption, available ROM is ~120k and RAM is ~50k
* mBEDTLS is being used
* It seems I can quite easily fit the ROM and RAM targets so far.

* RFC8446 says: "A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates)
* Does this imply I have to enable RSA support in mBEDTLS anyway (MBEDTLS_RSA_C)?
* As all certificates are managed by us, they should be EC, for memory savings if nothing else, right?
* In such case, would it be OK not to support RSA certificates in the client code? (I don't care if the device does not adhere to TLS RFC, as long as it practically interoperates correctly with the server and all-EC certs managed by us).
* EC certificates can be generated with gazillion of elliptic curves (openssl ecparam -list_curves), most of which are not available on the client (MBEDTLS_ECP_XXXX_ENABLED: Enables specific curves within the Elliptic Curve module.)
* Do we need to generate the certs (CA, broker, client) with such curve that is enabled in MBEDTLS_ECP_XXXX, and if yes, what curve is deemed sufficient / commonly used / functional / safe?
* RFC8446 says: "A TLS-compliant application MUST support digital signatures with ... ecdsa_secp256r1_sha256". This is also available in mBEDTLS. However, secp256r1 does not appear in the output of "openssl ecparam -list_curves" (OpenSSL 1.1.1f  31 Mar 2020). Does this mean OpenSSL is not TLS1.3 compliant, or that I don't understand what I am reading, and any other curve does fine for authentication, too?

* What else?
« Last Edit: January 17, 2023, 10:08:12 am by Siwastaja »
 

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #1 on: January 20, 2023, 08:08:39 am »
So far, I have everything running solidly, so a few comments.

* Handshake is just around 2 seconds on Cortex-M4 @ 64MHz, not a big deal
* I can now confirm IBM claiming TLS_AES_128_GCM_SHA256 uses 128-bit key is wrong. TLS_AES_128_GCM_SHA256 has 256-bit key.
* I now know that a typical private EC key file contains private key, public key, and metadata (simple integer) that enumerates the EC curve used, encoded using ASN.1 standard (basically a simple binary length-type-content encoding). Rest is headers.
* I modified mBEDTLS code to accept raw private key because nRF52 only has 128 bytes of non-volatile user registers in a separate flash region (something called "fuses" on some other MCUs). 51 bytes of key file is just too much when the actual key is just 32 bytes. Client supports only one curve, no need to communicate this.
* mBEDTLS generates public key out of private key if it's missing from the file, eyeballing it this takes just a few hundred milliseconds.
 

Offline bitwelder

  • Frequent Contributor
  • **
  • Posts: 962
  • Country: fi
Re: Embedded IoT device check
« Reply #2 on: January 20, 2023, 02:11:39 pm »
My 2 eurocent comment: Ensure that mbedTLS has a robust implementation of the security protocols.
E.g. check that it is not one of the versions that has an open CVE case: https://www.cvedetails.com/google-search-results.php?q=mbedtls
 
The following users thanked this post: Siwastaja, DiTBho

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #3 on: January 21, 2023, 03:29:06 pm »
My 2 eurocent comment: Ensure that mbedTLS has a robust implementation of the security protocols.
E.g. check that it is not one of the versions that has an open CVE case: https://www.cvedetails.com/google-search-results.php?q=mbedtls

That's a good point, and it actually follows that one needs to monitor such security reports regularly. It's not a fire-and-forget thing. I see no way around this.
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 341
  • Country: au
Re: Embedded IoT device check
« Reply #4 on: March 10, 2023, 07:46:47 am »
That's... a lotta questions.  Some general notes:

  • Run a MITM on yourself and see what happens, e.g. mitmproxy.  You should be hardcoding ("pinning") your CA certs and not trusting any others, also make sure that the client fully verifies the certs and the FQDN in them.  The majority of Android apps, which is what we have the most data for, don't do any verification so they'll connect to anything with a cert at any location and declare it's secure.
  • Don't get too caught up with algorithms and key sizes and everything else.  I could run a TLS 1.0 connection from 30-odd years ago and it'd be more secure than about 80% of the stuff out there because it never checks which certs it's getting or which FQDN it's connecting to vs. the one in the cert and a bunch of other stuff.  Get your basic checks right and you'll be doing better than most of the stuff out there.
  • If you're finding TLS 1.3 confusing, consider dropping back to TLS 1.2, which is no more or less secure than 1.3 if you're using a correctly-implemented version.  TLS 1.3 has the dual problems that it was optimised to make things easier for large content providers like Google so it offloads a lot of work onto the client, and it has every idea that every person in the standards group ever had added to it, making it incredibly complex to work with.
  • Again because this is important, don't get caught up with algorithms and key sizes and other distractions.  An attacker couldn't care less what algorithm you use, they'll take advantage of the fact that you aren't checking a certificate or something similar.  Crypto is bypassed, not attacked, so make sure they can't bypass your crypto.
 

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #5 on: March 10, 2023, 11:10:03 am »
  • If you're finding TLS 1.3 confusing, consider dropping back to TLS 1.2, which is no more or less secure than 1.3 if you're using a correctly-implemented version.  TLS 1.3 has the dual problems that it was optimised to make things easier for large content providers like Google so it offloads a lot of work onto the client, and it has every idea that every person in the standards group ever had added to it, making it incredibly complex to work with.

Are you sure about that? To me, TLS1.3 was a huge simplification because of removal of all the deprecated and dangerous stuff. What do you mean with offloading work to client, what extra work there is compared to TLS1.2?
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 341
  • Country: au
Re: Embedded IoT device check
« Reply #6 on: March 11, 2023, 10:11:44 am »
In an attempt to speed up the first connection to the server, TLS 1.3 hacked around the protocol to try and get 1RTT if possible (there's even a very unsafe 0RTT that you shouldn't use).  However to do this the client has to guess at what the server may want, which means performing speculative, and expensive, keyex negotiations that will get thrown away by the server if you guessed wrong, and running speculative hashing with multiple algorithms until you can find out what the server is going to do.  It also "simplified" the cipher suites by making everything negotiable a la carte via protocol extensions, which is actually a lot more complex than suites which give you everything in one place up front.

In terms of removing unused stuff, if you run AES + SHA-2 + some keyex of your choice that's all you need for TLS 1.2, the stuff that was removed was legacy cruft from 20-30 years ago that hopefully no-one was using any more anyway.
 

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #7 on: March 11, 2023, 12:37:12 pm »
Oh. Embedded client can just support the only must-have cipher suite, and every server must accept that, it's mandated by specification, and by specification, this speculative choice can't fail. I don't think it can get any simpler than that. With TLS1.2, you did not have that possibility, one more negotiation step was always needed.

Supporting only one saves quite some program memory. Servers of course have to support all the should-have suites (was there five, IIRC?), but that is no problem, they always do.

I did use this approach, and it seems to work as expected. What is wrong with this?

I was just very surprised at your comment that TLS1.3 added all sort of committee stuff because that's polar opposite to every other resource I have read and my own observations, too. To me TLS1.3 just seems to be a cleanup of TLS1.2, also with simplified negotiation with one less step. But maybe if you are implementing a server from scratch and want to support all optional extensions, maybe this is different?
« Last Edit: March 11, 2023, 12:56:50 pm by Siwastaja »
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 341
  • Country: au
Re: Embedded IoT device check
« Reply #8 on: March 13, 2023, 01:02:40 am »
That's because you've seen the sales pitch telling you how wonderful it is, not been part of the standards process or heard implementation experience.  There's a rather nice crypto book that was published a year or two back which, among other things, covers TLS 1.3, and on reading that chapter I thought "you've never actually done anything with TLS 1.3 have you, you're just explaining how the crypto in the spec is supposed to work".

To give one example, when Google Chrome, the worlds most widely-used browser, connects, it guesses a keyex that isn't the mandatory-to-implement (MTI) one but instead uses an also-ran that happens to work if what you're connecting to is something run by Google (when I say also-ran I'm not putting it down, it's a nice design, just not the MTI one).  So if you connect to a standards-conformant implementation Chrome sends an incorrectly-guessed keyex, the server tells it to try again, and then it restarts a second time with the MTI keyex.  At this point you've already done the round trips of TLS 1.2 and twice as much crypto and you're only just getting into the TLS 1.3 handshake.  Next, Chrome prefers another also-ran cipher/MAC combo that requires a full rekey on each packet sent or received and isn't supported in most hardware (presumably Google have some way of accelerating this on their servers).  There's quite a long list of this stuff.
 

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #9 on: March 16, 2023, 10:08:07 am »
That's because you've seen the sales pitch telling you how wonderful it is

Wrong assumption. I always skip the sales pitches because I loathe them. My main resource has been mBEDTLS and its (nearly nonexistent) documentation, and Googling every acronym possible, often leading to helpful technical posts in Stack Overflow/Exchange. To me, being able to see "dropped by TLS1.3" in 95% of the acronyms helped tremendously when choosing what to configure. For you as a security implementation expert, it was probably obvious even without googling which acronyms are old or dangerous.

The only thing that left bad taste to me was PSA. I still have no freaking idea what this is and why it is mandatory in TLS1.3. Because there were nearly a hundred of acronyms to Google, I had a rule that if there is no technical explanation to found within 1-2 minutes, I have to go forward. For PSA, I only found pure marketing bullshit (sales pitches), not even a description of its technical scope. I found out it's a layer for "demystification", but how this exactly demystifies anything remained a mystery. I have a working mbedtls implementation and it has one extra psa init call that would not be required with TLS1.2.


I don't understand how a stupid (maybe nontechnical for a reason) design choice by Google Chrome would affect an embedded client design. I don't think finding the list of must-have ciphersuites (1) was that difficult. Obviously in resource constrained embedded client I only support that one, and because it's mandatory for server to implement, I don't see how this guess could ever go wrong.
« Last Edit: March 16, 2023, 10:11:19 am by Siwastaja »
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 2145
  • Country: fi
  • Embedded SW/HW.
Re: Embedded IoT device check
« Reply #10 on: March 16, 2023, 10:50:04 am »
How about this:

- Each device is given a unique (ie. a preshared) symmetric 256-bit key at the factory.
- The device and the server are using this preshared symmetric secret for encrypting and decrypting when communicating with each other.
- The device may also use this same preshared key for encrypting all sensitive data that is at rest in the device.
- The device will announce its identity to the server (in clear text) when it connects to the server.
- After announcing its identity to the server, the rest of the communication will take place using the symmetric encryption.
- The preshared keys can be changed per device in the field if needed.
- Any leaked keys will only affect individual devices.
- The devices can be blacklisted very easily.
- No requirement for complex handshaking, very easy to understand and debug.
- Depends on the security of the AES block encryption, and preshared keys ie. the server shall not be compromised.
- KISS.
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 341
  • Country: au
Re: Embedded IoT device check
« Reply #11 on: March 17, 2023, 03:48:35 pm »
That sounds a bit like the LoRaWAN crypto design.  That's actually a pretty nice system for embedded/IoT use since it was specifically designed for that use rather than for protecting credit cards typed into web pages (which was what SSL was intended for) and then expanded to pretty much everything else, including a lot of stuff that it's really not very good at.

So yeah, if you can go with a greenfields design use the LoRaWAN crypto mechanisms.  For one thing when you look at it you'll see it actually does what you need for IoT/embedded device management, unlike TLS which just gives you some tools to build an apparently secure pipe and the rest is up to you.
 

Online SiwastajaTopic starter

  • Super Contributor
  • ***
  • Posts: 8090
  • Country: fi
Re: Embedded IoT device check
« Reply #12 on: March 18, 2023, 07:33:20 am »
I find that idea funny because Nominal Animal suggested usage of PSK a while back (maybe a year already?) on the Microcontroller forum, and oh boy the amount of backlash. "Boohoo, do not invent your own security, the only way to have security is to run TLS with the usual default settings". I think the final conclusion was that PSK is acceptable if you use the TLS libraries to do it, using the TLS-PSK mode.

I always kept the PSK idea open but I wanted to try if negotiating session keys like TLS "normally" does is too much of computational burden. It wasn't, so :-//

I don't need forward security (security of old recorded data in case of later key leakage, if I got it right), but it does not hurt, either.
« Last Edit: March 18, 2023, 07:35:58 am by Siwastaja »
 

Offline 5U4GB

  • Frequent Contributor
  • **
  • Posts: 341
  • Country: au
Re: Embedded IoT device check
« Reply #13 on: April 12, 2023, 08:17:49 am »
I find that idea funny because Nominal Animal suggested usage of PSK a while back (maybe a year already?) on the Microcontroller forum, and oh boy the amount of backlash. "Boohoo, do not invent your own security, the only way to have security is to run TLS with the usual default settings".

Oh, that's normal, the security industry has more in common with the fashion industry than the computer industry.  You should have seen the backlash when someone in the FreeBSD forums proposed displaying the initial password rather than blanking it when you first install the OS on a server.  Apparently there are people building rack-mount servers while riding public trams where people can look over their shoulders or something, because the overwhelming final decision was that zer passwords MUST BE BLANKT AT ALL TIMES!!

I suspect those shouting the loudest about the necessity of blanking the password weren't even born yet when the actual reason for doing it, not having them appear on the ASR-33 in the shared terminal room that you used to log into the PDP-7, was still a thing.

In this case, the right thing to do is ignore the shouting and use the appropriate tool for the job.  Most of the time it's not TLS, a resource-heavy, CPU-intensive certificate-based means of setting up an allegedly but typically not authenticated pipe from A to B.
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 3640
  • Country: gb
  • Doing electronics since the 1960s...
Re: Embedded IoT device check
« Reply #14 on: April 16, 2023, 06:51:06 pm »
Just some across this thread. WOW!

Siwastaja is way more clever than I am; I barely understand most of the details.

I am finishing the development of a C user-programmable product which can do basically the same stuff, also with MbedTLS. But it is non application specific. It doesn't have MQTT up and running but there is some code out there. It was done in ST Cube IDE and the ST port of LWIP comes with a sample MQTT module. So if somebody wants MQTT I can pay someone to tidy this up.

As Siwastaja correctly identifies, you should never run a server on an IOT box, because you can never achieve the level of security needed to withstand the 1Hz-10Hz china/russia hacking frequency. I run a number of little websites and this is the typical attack rate. Unsuccessful so far, afaik, because it uses robust code (Linux/Centos, Apache/nginx, etc) which an IOT box isn't going to have the benefit of.

I have TLS 1.2 in there. 1.3 removes a lot of crypto which is still widely used, so it would be dumb to use 1.3 unless you also support 1.2 but then the old crypto suites have to be left in there :) It is also very new.

I think 5U4GB has hit the nail on the head in so many ways. Most internet security stuff is BS. Everybody is an expert. Perfectly good stuff is obsolete, deprecated, insecure. DES is crap (does anyone really know how much known plaintext you need for any remotely viable (non NSA) attack on DES?), PPTP is crap (likewise). Almost nobody (more like literally nobody) attacks the crypto. They hack other stuff. 99.9% of users won't have physical (access) security, so they have no security at all. Somebody can walk in (if applicable, with a yellow jacket) and install a wifi AP and a DNS spoofer; then they can carry on in a car in the car park outside.

Many years ago I used to make DES line encryptors. No key management; just plain DES, shared key. Banks used them. Later they went to RSA, to generate a new key every so often. Anything stronger, they could not get an export license for it. All kinds of solutions evolved for tamper-proofing; some really esoteric like storing the key in a module, glass envelope with a fine wire in the glass, breaking the glass wiped the key. This is still used today for serious stuff. Nobody quite trusts "hardened" smartcard chips.

In testing, it was found some big-name websites use "deprecated" hashes on their certificates. Some certs in the cacert.pem file are really old, so you have to keep those ancient hashes.

But if you run your own server (the "mqtt broker") you have far more latitude on the details. Actually, who will care how you do it? You could use aes256 and a shared key :) Cisco uses aes128 in their https session crypto!

Good going to do PK in 2 secs on a 64MHz Cortex 4. Mine (also C4), 168MHz, takes about 3 secs to do RSA. But that's irrelevant for most IOT data acquisition applications. MbedTLS is a big collection of crypto and probably not optimised. And I have hardware aes which is far faster than the rest of the code...

To authenticate the peer (the mqtt server) you need to store secret stuff in the IOT box, obviously, and that will remain a vulnerability for ever. The C4 is not really secure even at L2 security. And if you set L2, this is not reversible, so you get huge political risks with big customers finding a problem. Although a remote firmware update should still work, from a boot loader.

MbedTLS uses about 200k of code and 50k of RAM. This RAM usage is non-deterministic because you can never get the upper bound on the worst-case crypto suite usage. I have a win32 build of the same tls 1.2 code so if there is a problem out there, we can simulate with that. Currently it seems a 48k block (for the MbedTLS private heap) is enough, and this is chucked away reliably after each TLS session ends, so no possibility of TLS heap fragmentation getting out of hand. In theory...

If your product / application is valuable, it will be attacked and it will be hacked, because you can't stop somebody getting one and disassembling it.

Remote firmware upgrades are another interesting area. Obviously they can't be automatic (windoze-style) because

- your company won't likely have the resources for the rigorous testing
- if you sell 10k of these at $100 each to one customer, and they all get bricked, your company will be fcukd

I have an remote firmware update path but it uses an http server, with the LAN the box is on being accessed via a VPN (obviously). This is easy, safe customer-politically, safe security-wise, and costs nothing. More clever ways, used with e.g. phones, is to distribute updates so problems first appear in geographical areas where the users are mostly poor and won't shout much. I have a plan for something like that, with firmware uploaded to the peer server, but the clients getting new firmware only by box S/N [range], whereby large users can be excluded. This is reasonable since large users tend to run the same feature set and if it works it will run for ever. Updates would be needed only if the user finds a bug. And a client, behind NAT, will never get hacked, so no need for "security updates". Anyway, one must assume LWIP and MbedTLS are insecure

- the code is written by amateurs
- the code is tiny compared to the "heavy duty" server solutions
- most IOT is not on open ports so gets little or no attack exposure
- it is open source so any back doors are wide open

I am on the LWIP and MbedTLS mailing lists and I see real BS stuff on the latter (the former is almost dead now; the coders have got girlfriends long ago and moved on) where they are doing stuff like zero-filling buffers between sessions... Who is going to exploit that? In IOT, non open source, the chances of an attacker successfully running code of their choice is nil. I mean, you don't have a web page on it with a memory hex dump feature ;) These people are running out of ideas, but in reality a client will be unhackable, and if it was a server it would be mega vulnerable to DOS (there is no firewall, and if you implement one it will still flood from any gigabit LAN, been around this block due to the vulnerability to broadcasts but you can't block them all because you need ARP and possibly PnP / auto detect.

Your server will obviously get attacked and that will be a weak point. And if you use e.g. some AWS MQTT "cloud service" and AWS one day send you an email saying "we have detected fraud on your account; we have closed it" and you discover you can't phone them, can't email them, can't write to them, can't visit them, and your business model is now totally sunk (this happened to someone I know and got sorted only because his brother knew a director of Amazon).

Good luck :)

Yes, when it comes to crypto, everybody is an expert :)
« Last Edit: April 16, 2023, 06:57:36 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline redkitedesign

  • Regular Contributor
  • *
  • Posts: 111
  • Country: nl
    • Red Kite Design
Re: Embedded IoT device check
« Reply #15 on: April 17, 2023, 08:27:23 am »
I see a lot of discussion in this thread about the level 5-7 of the OSI network model.

But I see two items unmentioned:

But what is your layer 1-2 connection method?
What are your expected attackers?

I've worked on IoT devices that used GPRS (2G mobile data), directly connecting to a Telco provided VPN. That leaves very little room for attackers on the device side, the only feasible entrance is the portal hosted in a datacentre. Given that the data send by these devices (streetlights) was not sensitive nor secret, no further security was added to the telemetry.

But if you want to protect against state level enemies, you cannot trust the telco either. So that's a different ballgame...
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 3640
  • Country: gb
  • Doing electronics since the 1960s...
Re: Embedded IoT device check
« Reply #16 on: April 17, 2023, 08:49:13 am »
Quote
directly connecting to a Telco provided VPN

That's pretty good. I have not seen that before.

My box may be used with a 4G "router" also, like the RUT240. It would be logging onto the server (if MQTT, the "broker").

What VPN did you use? Where would you find the VPN sourcecode to run in the IOT device? Stuff like IPSEC/L2TP is incredibly complicated and even VPN router manufacturers struggle with it. In general, something like a site-site VPN can be successfully configured only between two identical routers from the same vendor. I've done this many times e.g. Draytek-Draytek but it tends to work only between same models. And then the "teleworker" end may work if android v10 not v6, ios may or may not work, windows10 may while win7 doesn't.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: us
Re: Embedded IoT device check
« Reply #17 on: April 17, 2023, 05:41:14 pm »
* Interwebz says TLS_AES_128_GCM_SHA256 has a 128-bit key (source: IBM). Internetz also says TLS1.3 has minimum key size of 256 bits (source: IBM). These are in contradiction. I have no idea what components there are in a key and how the "key size" is defined. Binary key files are always significantly longer but they contain some metadata etc. Maybe I should not care and just call the functions with the correct arguments, but I'm just wondering.

I believe someone got confused here.  The closest thing to a requirement for that in TLS 1.3 applies to key sizes for asymmetric keys like RSA or ECDSA.  All of the potentially weak symmetric ciphers and operating modes were just removed as you noted.

Quote
   Applications SHOULD also enforce minimum and maximum key sizes.  For
   example, certification paths containing keys or signatures weaker
   than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure
   applications.

So it's not a specific limit, but rather a recommendation that implementations adopt key size limits, and gives two examples for specific key types.
 

Offline redkitedesign

  • Regular Contributor
  • *
  • Posts: 111
  • Country: nl
    • Red Kite Design
Re: Embedded IoT device check
« Reply #18 on: April 18, 2023, 07:56:04 am »
Quote
directly connecting to a Telco provided VPN
What VPN did you use? Where would you find the VPN sourcecode to run in the IOT device?

The provider was that British company named after a russians favorite drink.

However, there was not need to run VPN code in the device. The Telco runs the VPN, the device gets an (10/8) IP, and can only route packets to our server, which also has a network interface (physical or virtual, there is room for VPN code in a server) on that network.

And that's all there is; so you could argue that the IoT device was not even on a VPN, but on an actual seperate network (of course, the provider uses an IP network....). The IoT device had no option to connect the the outside internet (only to the manufacturers servers). The servers could (and would!) connect to the internet, but those are easier to secure. (And update!)
 

Online nfmax

  • Super Contributor
  • ***
  • Posts: 1554
  • Country: gb
Re: Embedded IoT device check
« Reply #19 on: April 18, 2023, 08:02:54 am »
Quote
directly connecting to a Telco provided VPN
What VPN did you use? Where would you find the VPN sourcecode to run in the IOT device?

The provider was that British company named after a russians favorite drink.

However, there was not need to run VPN code in the device. The Telco runs the VPN, the device gets an (10/8) IP, and can only route packets to our server, which also has a network interface (physical or virtual, there is room for VPN code in a server) on that network.

And that's all there is; so you could argue that the IoT device was not even on a VPN, but on an actual seperate network (of course, the provider uses an IP network....). The IoT device had no option to connect the the outside internet (only to the manufacturers servers). The servers could (and would!) connect to the internet, but those are easier to secure. (And update!)

Andrews & Arnold will do this sort of thing as well - with their SIM your mobile device gets an address on 'your' network.
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 3640
  • Country: gb
  • Doing electronics since the 1960s...
Re: Embedded IoT device check
« Reply #20 on: April 18, 2023, 08:19:44 am »
Yes I use A&A as the ISP. The 3G/4G backup does work, though only for a single subnet (not an issue here).

I am not surprised it was Vodafone; they do lots of corporate stuff.

But in the end all this hangs together only if you have physical security. It's actually hard to hack a mobile data connection. I know we hear stories about it but it isn't viable in this case. After all, the telco puts you behind NAT (by default; you could have a server on a fixed IP, but why??) so nobody can attack you anyway, and when your client is dialling out, you are using TLS, aren't you? You are checking the server cerftificate and then encrypting the data. That protects against DNS spoofing.

I think the vulnerability in all this "amateur open source crypto" stuff like MbedTLS and LWIP is the same old stuff i.e. sending in malformed packets. But that works on Windoze (because so many people have disassembled it) and it works on open source stuff (because you don't need to disassemble it) which was badly written. Where will they start with your embedded product?
« Last Edit: April 18, 2023, 09:58:10 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline redkitedesign

  • Regular Contributor
  • *
  • Posts: 111
  • Country: nl
    • Red Kite Design
Re: Embedded IoT device check
« Reply #21 on: April 18, 2023, 04:32:41 pm »
Where will they start with your embedded product?

With a sample of the product from E-bay. Look at hack-a-day, plenty of examples of embedded products that have been opened, a SWD interface hacked to them and the firmware altered or replaced.

Granted, usually the original firmware is not recovered (but might be available if there is an update the user can apply) but once you know the MCU, the function, and some educated guesses you can get quite some knowledge of a device. Given that its probably already a few years old, all the recently found bugs in e.g. mDNS, LWIP or other popular packages are unfixed.

Not worth it to turn off a few streetlights. But to enter all pre 2020 cars of a brand well known for its quality luxury cars, who have good resale value in the east?

Nah, embedded product are really hard to secure. Its a multi level, multi-direction task, probably even multi-disciplinary. And the tech-buzzwords (TLS, SHA, AES etc) are just buzzwords.
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 3640
  • Country: gb
  • Doing electronics since the 1960s...
Re: Embedded IoT device check
« Reply #22 on: April 18, 2023, 09:41:19 pm »
Sure, it depends on whether anybody can be bothered.

With a car security system, of course they can and will be bothered.

With some obscure industrial product, where is the reward? Also in the B2B sphere the "reward" is likely to be distributed so no single body will be that bothered.

I know a scenario (won't post details because it's hard to anonymise) where ripping off one product would be worth roughly GBP 3 million, over past 15 years. And it was very easy to rip off. But nobody ripped it off. Why not?? Well, all the users are industrial companies, and lots of them. Zero interest there...

The important thing in an internet box is that somebody can't trash them all remotely. But if it is a client (HTTP, HTTPS, MQTT, whatever), behind NAT, how can they? To be honest, these applications could just all use a shared key :)
« Last Edit: April 18, 2023, 09:49:54 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline redkitedesign

  • Regular Contributor
  • *
  • Posts: 111
  • Country: nl
    • Red Kite Design
Re: Embedded IoT device check
« Reply #23 on: April 19, 2023, 08:33:52 am »
But nobody ripped it off. Why not?? Well, all the users are industrial companies, and lots of them. Zero interest there...
Absence of evidence is not evidence of absence.

Stuxnet showed that a single industrial application (a factory in a remote country) and be interesting enough for a actor to create a threath. You can become collateral damage.

Quote
The important thing in an internet box is that somebody can't trash them all remotely. But if it is a client (HTTP, HTTPS, MQTT, whatever), behind NAT, how can they? To be honest, these applications could just all use a shared key :)

NAT is nice defense mechanism, signing key's are too. Good defense is multi layered, defense in depth.

But if all boxes are behind the same NAT, with the same key, trashing one box is as difficult as trashing them all. Not sharing key prevents that scenario.
 

Online peter-h

  • Super Contributor
  • ***
  • Posts: 3640
  • Country: gb
  • Doing electronics since the 1960s...
Re: Embedded IoT device check
« Reply #24 on: April 19, 2023, 05:46:07 pm »
NAT prevents the attacker reaching your box to start with. Your box can be really totally insecure but it will be fine. Look at how much stuff you have on your home LAN, all behind NAT.

Everything else, like certificates, assumes the basic TCP stack etc, is sound, and that cannot be assured by a long way. TLS 1.3 sounds wonderful but if LWIP can be crashed by some malformed packet, creating a DOS attack vector?

I still believe it will be extremely hard to run code of the attacker's choosing on your custom-developed (not some linux box etc) IOT box, if it has no file system, etc.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf