Hi,
I am trying to build MbedtLS 3.5.2 and get the below error:
mbedtls/library/psa_crypto_storage.c:23:23: psa/error.h: No such file or directory mbedtls/library/psa_crypto_storage.c:24:42: psa/internal_trusted_storage.h: No such file or directory
I searched all thru the directories and found error.h in mbetls directory but could not find internal_trusted_storage.h header file?
#if defined(MBEDTLS_PSA_ITS_FILE_C) #include "psa_crypto_its.h" #else /* Native ITS implementation */ #include "psa/error.h" #include "psa/internal_trusted_storage.h" #endif
Regards, Prakash
Hi Prakash,
It seems that you've disabled MBEDTLS_PSA_ITS_FILE_C but kept MBEDTLS_PSA_CRYPTO_STORAGE_C. MBEDTLS_PSA_CRYPTO_STORAGE_C is looking for something that provides the PSA ITS interface, which can either be built into your platform or provided by MBEDTLS_PSA_ITS_FILE_C. Per your other thread, you wanted to disable PSA crypto, so just disable MBEDTLS_PSA_CRYPTO_STORAGE_C.
Best regards,
May I ask a stupid question?
I have developed a product which uses MbedTLS 2.16. I am on this mailing list so I get to see the various updates since.
And I wonder: is there any point in upgrading?
If your embedded product is a client, and usually behind NAT (or an equivalent firewall) and accessing some private server (or a trusted public server) on a schedule of its own choosing, then the whole attack surface is minimal.
If your embedded product is a server, on a private LAN with no internet connection, then the attack surface is similarly negligible.
If your embedded product is a server and on an open port, it WILL get attacked within hours (if not minutes, especially if the DNS is published) and it WILL get hacked. For these applications you must use a heavy duty server e.g. Linux, Centos, etc, and the web server needs to be a similar thing e.g. Apache, NGINX, etc. Not some $5 chip running MbedTLS!
But I see updates like zeroing malloc'd buffers before doing a free() which is nice, but the relevance is zero because exploitation is possible only if an attacker is running code of his choice, and if he gets that far (on an embedded box sitting in some rack in a factory) then it is game over because obviously you have zero *physical* security!
I guess this question is sacrilege, so I am not expecting anyone to reply :) But if somebody does reply, I'd be interested in their take.
Basically, as you can see, I see the only valid applications for MbedTLS in scenarios where a) the box is a client and b) you control the other end's server (or, if you don't control it, you are prepared to periodically revisit your code and fix it whenever the server's owner has changed the crypto suite or whatever).
ISTM that the general drift in the IoT sphere is indeed along the lines I describe. It "incidentally" also delivers a revenue stream because you can charge the customer for that server ;) Whereas if you just sell a box, you have no business model for funding long term functionality.
Regards,
Peter
Hi Prakash,
It seems that you've disabled MBEDTLS_PSA_ITS_FILE_C but kept MBEDTLS_PSA_CRYPTO_STORAGE_C. MBEDTLS_PSA_CRYPTO_STORAGE_C is looking for something that provides the PSA ITS interface, which can either be built into your platform or provided by MBEDTLS_PSA_ITS_FILE_C. Per your other thread, you wanted to disable PSA crypto, so just disable MBEDTLS_PSA_CRYPTO_STORAGE_C.
Best regards,
-- Gilles Peskine Mbed TLS developer
On 13/03/2024 10:44, Satya Prakash Prasad via mbed-tls wrote:
Hi,
I am trying to build MbedtLS 3.5.2 and get the below error:
mbedtls/library/psa_crypto_storage.c:23:23: psa/error.h: No such file or directory mbedtls/library/psa_crypto_storage.c:24:42: psa/internal_trusted_storage.h: No such file or directory
I searched all thru the directories and found error.h in mbetls directory but could not find internal_trusted_storage.h header file?
#if defined(MBEDTLS_PSA_ITS_FILE_C) #include "psa_crypto_its.h" #else /* Native ITS implementation */ #include "psa/error.h" #include "psa/internal_trusted_storage.h" #endif
Regards, Prakash
On 13/03/2024 17:02, Peter wrote:
May I ask a stupid question?
I have developed a product which uses MbedTLS 2.16. I am on this mailing list so I get to see the various updates since.
And I wonder: is there any point in upgrading?
If your embedded product is a client, and usually behind NAT (or an equivalent firewall) and accessing some private server (or a trusted public server) on a schedule of its own choosing, then the whole attack surface is minimal.
Sorry, that's just not true. IoT devices are massively used as relays to attack local networks. Mirai (https://en.wikipedia.org/wiki/Mirai_(malware)) was a famous example recently, having infected millions of IP cameras. And this keeps happening https://thehackernews.com/2023/02/new-mirai-botnet-variant-v3g4.html and happening https://arstechnica.com/security/2023/11/thousands-of-routers-and-cameras-vulnerable-to-new-0-day-attacks-by-hostile-botnet/.
(…)
Basically, as you can see, I see the only valid applications for MbedTLS in scenarios where a) the box is a client and b) you control the other end's server (or, if you don't control it, you are prepared to periodically revisit your code and fix it whenever the server's owner has changed the crypto suite or whatever).
A lot of devices running Mbed TLS are small servers to which even smaller devices connect to (e.g. a WRT or similar linux server that acts as a gateway for a bunch of microcontrollers).
ISTM that the general drift in the IoT sphere is indeed along the lines I describe. It "incidentally" also delivers a revenue stream because you can charge the customer for that server ;) Whereas if you just sell a box, you have no business model for funding long term functionality.
Well, I'm an Arm employee and our revenue is basically from the sales of boxes. Upgradability is a thing we're throwing in for free. Mbed TLS is part of Arm's Platform Security Architecture (PSA) https://www.arm.com/architecture/security-features/platform-security reference implementation. The reason firmware update is part of PSA is that we don't want our customers/users to be the next Mirai victims.
Best regards,
On 13/03/2024 17:02, Peter wrote:
May I ask a stupid question?
I have developed a product which uses MbedTLS 2.16. I am on this mailing list so I get to see the various updates since.
And I wonder: is there any point in upgrading?
If your embedded product is a client, and usually behind NAT (or an equivalent firewall) and accessing some private server (or a trusted public server) on a schedule of its own choosing, then the whole attack surface is minimal.
Sorry, that's just not true. IoT devices are massively used as relays to attack local networks. Mirai (https://en.wikipedia.org/wiki/Mirai_(malware)) was a famous example recently, having infected millions of IP cameras. And this keeps happening https://thehackernews.com/2023/02/new-mirai-botnet-variant-v3g4.html and happening https://arstechnica.com/security/2023/11/thousands-of-routers-and-cameras-vulnerable-to-new-0-day-attacks-by-hostile-botnet/.
Surely IP cameras (those I have known) contain a server, which many users install on an open port. This was the principal usage model for the original AXIS cameras. You could even find them with a suitably formed google search!
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
( )
Basically, as you can see, I see the only valid applications for MbedTLS in scenarios where a) the box is a client and b) you control the other end's server (or, if you don't control it, you are prepared to periodically revisit your code and fix it whenever the server's owner has changed the crypto suite or whatever).
A lot of devices running Mbed TLS are small servers to which even smaller devices connect to (e.g. a WRT or similar linux server that acts as a gateway for a bunch of microcontrollers).
OK, but the that is either a vulnerable scenario, or the server is on some private LAN.
ISTM that the general drift in the IoT sphere is indeed along the lines I describe. It "incidentally" also delivers a revenue stream because you can charge the customer for that server ;) Whereas if you just sell a box, you have no business model for funding long term functionality.
Well, I'm an Arm employee and our revenue is basically from the sales of boxes. Upgradability is a thing we're throwing in for free. Mbed TLS is part of Arm's Platform Security Architecture (PSA) https://www.arm.com/architecture/security-features/platform-security reference implementation. The reason firmware update is part of PSA is that we don't want our customers/users to be the next Mirai victims.
My point is that most/all of the perceived vulnerability is present only if the system is stupidly set up (e.g. an embedded box is a server and on an open port). And a client accessible on an open port is just silly (pointless).
The situation we have now is that some customer, who does not understand the issues, will constantly be demanding the latest MbedTLS version, in the belief that the box you are selling is somehow "insecure".
And this is very hard to support if you are a small company, say < 1M sales. I reckon to go from v2 to v3 will cost some 5 digits in implementation and testing cost, and this is repeated a few times a year. But the extra security is *nil* unless the system is stupidly configured, and then the "box" will still be hacked, just a bit later, by somebody just a bit more clever than the last guy.
MbedTLS is open source which obviously has advantages, but also has huge disadvantages: everybody knows where to start hacking. At work we have an open source online shop (Magento) which has a poor hacking history (basically the only way to run it is to use a 3rd party payment processor so your shop never sees CC details, so there is nothing for the chinese/russian hackers to steal). All open source forums (e.g. PHP-BB) have been repeatedly hacked. Very little OS "internet" code is secure; just the heavy duty stuff, with huge user communities, seems to work well.
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
1. Attack server. 2. Use the server as a relay to attack clients that connect to it.
Or:
1. Attack some network equipment. 2. Spoof the server. 3. Use the spoofed server to attack clients that connect to it.
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
- Attack server.
The MbedTLS version is not connected with that, however.
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
- Spoof the server.
The MbedTLS version is not connected with that, either.
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
Upgrading MbedTLS implies endless upgrades - because a customer will find out that a later version is out. These are damn hard or impossible to deploy.
There is a commercial risk. Let me give you a real example. I sell a product which used to go out with a driver CD. (Now it doesn't because win7 and higher grabs it from the MS website). The customer found out that a particular driver (not previously needed) was not on the CD. We had to scrap a few k CDs (at GBP 0.40 each) and re-pack a few k units of finished stock with a new CD. I can't remember if the customer returned to us his entire warehouse stock for re-packing.
Now translate this to a firmware upgrade on an IOT device. *Obviously* (unless stupidly installed, e.g. on an open port) we cannot access it remotely. The customer has to do something. There are multiple ways e.g. the device checks an update server periodically (OTA is dangerous; you could brick the entire installed base if something goes wrong -> the end of your company). My product has a USB port with a filesystem behind it so a physical visit is needed. It also had an HTTP server for LAN (or direct laptop) config but this can't be on an open port for already discussed reasons, but is OK on a private LAN / remotely over a VPN (the HTTP server can be locked to a client IP e.g. the VPN terminator IP).
On Wed, Mar 13, 2024 at 2:56 PM Peter wrote:
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) ...
It is a non-trivial task to secure a server. If it was easy there wouldn't be news articles like https://www.cnn.com/2024/03/08/tech/microsoft-russia-hack/index.html Russian state-backed hackers gained access to some of Microsoft’s core software systems in a hack first disclosed in January,
... how could the camera be attacked? It will be behind NAT, for a start.
Ages ago I ran a TOR middle node on my home network. I noticed some strange traffic on my internal, **behind a NAT device**, network and found out that NAT wasn't the magical network protection device you seem to think it is. It turns out that loose source routing defeated NAT - see https://en.wikipedia.org/wiki/Loose_Source_Routing
And yes, *nobody* should be routing RFC-1918 address across the Internet, but you know what they say about theory and practice..
- Attack server.
The MbedTLS version is not connected with that, however.
This showed up in my inbox today: [SECURITY] [DSA 5639-1] chromium security update ... Security issues were discovered in Chromium, which could result in the execution of arbitrary code
Do you use a browser on the same machine that you upload photos to from your camera? If so, your camera is not behind a NAT and is directly connected to a possibly compromised server.
Does your browser have javascript enabled? Take a look at https://en.wikipedia.org/wiki/DNS_rebinding and play with https://lock.cmpxchg8b.com/rebinder.html
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Your browser PC is behind the same NAT - right? And there's no firewall or NAT device between your PC and whatever it is that's using the MbedTLS code - right?
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
"some network equipment" being the ISP supplied router/modem that connects your network to the Internet.
- Spoof the server.
The MbedTLS version is not connected with that, either.
I'd like to see your definition of "connected to." If the MbedTLS software doesn't connect to a server then why do you need TLS?
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
If nothing else, it helps sales. Tell me what product you sell -- I'll make sure that I never buy it.
Regards, Lee
On Wed, Mar 13, 2024 at 2:56?PM Peter wrote:
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) ...
It is a non-trivial task to secure a server. If it was easy there wouldn't be news articles like https://www.cnn.com/2024/03/08/tech/microsoft-russia-hack/index.html Russian state-backed hackers gained access to some of Microsofts core software systems in a hack first disclosed in January,
Sure, but how relevant is this to MbedTLS?
... how could the camera be attacked? It will be behind NAT, for a start.
Ages ago I ran a TOR middle node on my home network. I noticed some strange traffic on my internal, **behind a NAT device**, network and found out that NAT wasn't the magical network protection device you seem to think it is. It turns out that loose source routing defeated NAT - see https://en.wikipedia.org/wiki/Loose_Source_Routing
Clearly some attack on NAT is possible if you control the server which the client is connecting to, by sending malformed packets to the client during the time the NAT channel is open (it closes 180 secs after cessation of data, normally).
But you also need to know the holes in the client, so you can set up a way to run code of your choice on it (by sending it malformed packets). With Windoze there must be 1000 ways but with the average embedded box? It won't be open source ;) Most don't even have a filesystem (unless running Linux or similar) which can store code to run. I can see ways to set this up, by obtaining a client device and disassembling it, etc. It's a helluva stretch... and I'd say on most boxes (other than Linux stuff) there won't be any attack surface even if you did disassemble it. (Yes I know STM32 readout protection etc can be penetrated by VCC or clock or /NRST glitching).
And yes, *nobody* should be routing RFC-1918 address across the Internet, but you know what they say about theory and practice..
Sure.
- Attack server.
The MbedTLS version is not connected with that, however.
This showed up in my inbox today: [SECURITY] [DSA 5639-1] chromium security update ... Security issues were discovered in Chromium, which could result in the execution of arbitrary code
Do you use a browser on the same machine that you upload photos to from your camera?
I transfer photos from my phone to my PC via the home wifi. The phone is behind "NAT" of the telco if on 4G. But maybe I am not understanding you. If you built a camera with MbedTLS, it should still be a client. Do you mean the PC should be considered compromised, and then it could penetrate the camera (the phone) and run arbitrary code on the phone?
If so, your camera is not behind a NAT and is directly connected to a possibly compromised server.
Does your browser have javascript enabled? Take a look at https://en.wikipedia.org/wiki/DNS_rebinding and play with https://lock.cmpxchg8b.com/rebinder.html
Sure...
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Your browser PC is behind the same NAT - right? And there's no firewall or NAT device between your PC and whatever it is that's using the MbedTLS code - right?
I don't understand the config in this case.
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
"some network equipment" being the ISP supplied router/modem that connects your network to the Internet.
Sure; NAT could be buggy, especially in no-name chinese consumer kit.
- Spoof the server.
The MbedTLS version is not connected with that, either.
I'd like to see your definition of "connected to." If the MbedTLS software doesn't connect to a server then why do you need TLS?
It is true that a lot of applications can be done with a fixed key and just using AES for session crypto. But TLS is a standard way to do this stuff nowadays. People feel happy :) The fact that 99.99999% of data in IOT applications is of no value whatsoever is not relevant.
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
If nothing else, it helps sales. Tell me what product you sell -- I'll make sure that I never buy it.
Rather more constructively, can you suggest how to do OTA on a typical IOT box, in a way which runs no risk of blowing up my company? :)
My box does have means of uploading new firmware but obviously it is not possible to just do it remotely.
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
Peter
On Wed, Mar 13, 2024 at 6:43 PM Peter wrote:
On Wed, Mar 13, 2024 at 2:56?PM Peter wrote:
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) ...
It is a non-trivial task to secure a server. If it was easy there wouldn't be news articles like https://www.cnn.com/2024/03/08/tech/microsoft-russia-hack/index.html Russian state-backed hackers gained access to some of Microsoft’s core software systems in a hack first disclosed in January,
Sure, but how relevant is this to MbedTLS?
I was taking issue with your "... server (which has a properly secured user side)" which makes it sound trivially easy to secure a server.
... how could the camera be attacked? It will be behind NAT, for a start.
Ages ago I ran a TOR middle node on my home network. I noticed some strange traffic on my internal, **behind a NAT device**, network and found out that NAT wasn't the magical network protection device you seem to think it is. It turns out that loose source routing defeated NAT - see https://en.wikipedia.org/wiki/Loose_Source_Routing
Clearly some attack on NAT is possible if you control the server which the client is connecting to, by sending malformed packets to the client during the time the NAT channel is open (it closes 180 secs after cessation of data, normally).
Take another look at loose source routing - it's not an "attack on NAT" but a bypass of NAT: Loose source routing uses a source routing option in IP to record the set of routers a packet must visit.
Anyone can send traffic with that option and the 'set of routers a packet must visit' being a single IP address - the "outside" IP address of your NAT device and the destination address being something on your internal network.
- Attack server.
The MbedTLS version is not connected with that, however.
This showed up in my inbox today: [SECURITY] [DSA 5639-1] chromium security update ... Security issues were discovered in Chromium, which could result in the execution of arbitrary code
Do you use a browser on the same machine that you upload photos to from your camera?
I transfer photos from my phone to my PC via the home wifi. The phone is behind "NAT" of the telco if on 4G. But maybe I am not understanding you. If you built a camera with MbedTLS, it should still be a client. Do you mean the PC should be considered compromised, and then it could penetrate the camera (the phone) and run arbitrary code on the phone?
Yes. You've been using the browser on your PC. How do you know your PC hasn't been compromised? When the camera is talking to the PC there is nothing protecting the camera from the PC .. or anything else on the "internal" network behind the NAT device.
By the same token, you've probably been browsing the Internet on your phone. How do you know your phone hasn't been compromised? What's protecting all the devices on your home network when your phone is connected to your home wifi?
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Your browser PC is behind the same NAT - right? And there's no firewall or NAT device between your PC and whatever it is that's using the MbedTLS code - right?
I don't understand the config in this case.
Take the situation you must mentioned - I transfer photos from my phone to my PC via the home wifi. What's protecting the phone from your PC? Or what's protecting your PC from the phone since I'm betting you use a browser on both phone & PC. There's no NAT involved on your home wifi is there?
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
"some network equipment" being the ISP supplied router/modem that connects your network to the Internet.
Sure; NAT could be buggy, especially in no-name chinese consumer kit.
Wow, you sure have nat on the brain. I took "attack some network equipment" as total ownage of your Internet router. If I control your Internet router and can run whatever code on it I feel like, what could I do?
If you're having trouble answering that take a look at https://m.xkcd.com/341/ which is probably based on https://pete.ex-parrot.com/upside-down-ternet.html
- Spoof the server.
The MbedTLS version is not connected with that, either.
I'd like to see your definition of "connected to." If the MbedTLS software doesn't connect to a server then why do you need TLS?
It is true that a lot of applications can be done with a fixed key and just using AES for session crypto. But TLS is a standard way to do this stuff nowadays. People feel happy :) The fact that 99.99999% of data in IOT applications is of no value whatsoever is not relevant.
You kept repeating the MbedTLS version is not connected to that; it seems like the MbedTLS version isn't connecting to anything, so why run the MbedTLS software?
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
If nothing else, it helps sales. Tell me what product you sell -- I'll make sure that I never buy it.
Rather more constructively, can you suggest how to do OTA on a typical IOT box, in a way which runs no risk of blowing up my company? :)
I thought me avoiding insecure products was very constructive :)
My box does have means of uploading new firmware but obviously it is not possible to just do it remotely.
I have a ROKU box that manages to update itself without any interaction on my part, so clearly it _is_ possible. Maybe it's not possible for what you're selling, but that's why I would like to know what it is you're selling so I can avoid it.
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
So hire a contractor that knows how to do it. It can't be all that hard to find somebody competent.
Regards Lee
On Wed, Mar 13, 2024 at 6:43?PM Peter wrote:
On Wed, Mar 13, 2024 at 2:56?PM Peter wrote:
On 13/03/2024 18:25, Peter wrote:
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) ...
It is a non-trivial task to secure a server. If it was easy there wouldn't be news articles like https://www.cnn.com/2024/03/08/tech/microsoft-russia-hack/index.html Russian state-backed hackers gained access to some of Microsofts core software systems in a hack first disclosed in January,
Sure, but how relevant is this to MbedTLS?
I was taking issue with your "... server (which has a properly secured user side)" which makes it sound trivially easy to secure a server.
Well, you have to start somewhere. If you assume that every bit of kit is compromised then you might as well commit suicide :)
There should be no debate that it is easier to secure an industry-standar server (running on an open port) then to secure an IOT box (running on an open port, which I assert is simply dumb, for many reasons).
... how could the camera be attacked? It will be behind NAT, for a start.
Ages ago I ran a TOR middle node on my home network. I noticed some strange traffic on my internal, **behind a NAT device**, network and found out that NAT wasn't the magical network protection device you seem to think it is. It turns out that loose source routing defeated NAT - see https://en.wikipedia.org/wiki/Loose_Source_Routing
Clearly some attack on NAT is possible if you control the server which the client is connecting to, by sending malformed packets to the client during the time the NAT channel is open (it closes 180 secs after cessation of data, normally).
Take another look at loose source routing - it's not an "attack on NAT" but a bypass of NAT: Loose source routing uses a source routing option in IP to record the set of routers a packet must visit.
Sure, but those links also say that most routing kit chucks out those packets.
If this was a real "volume" issue on the internet, every PC, phone, etc, would be on a botnet by now :) They all rely on NAT working - either NAT on your home router, or the equivalent method at the mobile telco.
Anyone can send traffic with that option and the 'set of routers a packet must visit' being a single IP address - the "outside" IP address of your NAT device and the destination address being something on your internal network.
- Attack server.
The MbedTLS version is not connected with that, however.
This showed up in my inbox today: [SECURITY] [DSA 5639-1] chromium security update ... Security issues were discovered in Chromium, which could result in the execution of arbitrary code
Do you use a browser on the same machine that you upload photos to from your camera?
I transfer photos from my phone to my PC via the home wifi. The phone is behind "NAT" of the telco if on 4G. But maybe I am not understanding you. If you built a camera with MbedTLS, it should still be a client. Do you mean the PC should be considered compromised, and then it could penetrate the camera (the phone) and run arbitrary code on the phone?
Yes. You've been using the browser on your PC. How do you know your PC hasn't been compromised? When the camera is talking to the PC there is nothing protecting the camera from the PC .. or anything else on the "internal" network behind the NAT device.
By the same token, you've probably been browsing the Internet on your phone. How do you know your phone hasn't been compromised? What's protecting all the devices on your home network when your phone is connected to your home wifi?
If you assume that everything is compromised then I agree you have lost the battle...
- Use the server as a relay to attack clients that connect to it.
The MbedTLS version is not connected with that, either. Plus the clients will be behind NAT so how can that server attack them? It can do no more than a 3rd party attacking random IPs.
Your browser PC is behind the same NAT - right? And there's no firewall or NAT device between your PC and whatever it is that's using the MbedTLS code - right?
I don't understand the config in this case.
Take the situation you must mentioned - I transfer photos from my phone to my PC via the home wifi. What's protecting the phone from your PC? Or what's protecting your PC from the phone since I'm betting you use a browser on both phone & PC. There's no NAT involved on your home wifi is there?
Again, same comment about having lost the battle.
Or:
- Attack some network equipment.
The MbedTLS version is not connected with that, either.
"some network equipment" being the ISP supplied router/modem that connects your network to the Internet.
Sure; NAT could be buggy, especially in no-name chinese consumer kit.
Wow, you sure have nat on the brain. I took "attack some network equipment" as total ownage of your Internet router. If I control your Internet router and can run whatever code on it I feel like, what could I do?
If you're having trouble answering that take a look at https://m.xkcd.com/341/ which is probably based on https://pete.ex-parrot.com/upside-down-ternet.html
- Spoof the server.
The MbedTLS version is not connected with that, either.
I'd like to see your definition of "connected to." If the MbedTLS software doesn't connect to a server then why do you need TLS?
It is true that a lot of applications can be done with a fixed key and just using AES for session crypto. But TLS is a standard way to do this stuff nowadays. People feel happy :) The fact that 99.99999% of data in IOT applications is of no value whatsoever is not relevant.
You kept repeating the MbedTLS version is not connected to that; it seems like the MbedTLS version isn't connecting to anything, so why run the MbedTLS software?
A case can be legitimately made that an IOT client (behind NAT) should use TLS to access the server. This authenticates the server (the certificates can have a 100 year life, so you don't get the whole installed base exploding years after the last admin has left the company) and sets up encryption for the data.
A lot of people have done this by not using TLS and just encrypting the data using a shared key. That isn't much different from TLS with certs which are never updated, but that is just another discussion leading to shared keys requiring a similar level of long-term admin to certificates.
- Use the spoofed server to attack clients that connect to it.
The MbedTLS version is not connected with that, either.
So I still don't see where tightening MbedTLS security helps.
If nothing else, it helps sales. Tell me what product you sell -- I'll make sure that I never buy it.
Rather more constructively, can you suggest how to do OTA on a typical IOT box, in a way which runs no risk of blowing up my company? :)
I thought me avoiding insecure products was very constructive :)
My box does have means of uploading new firmware but obviously it is not possible to just do it remotely.
I have a ROKU box that manages to update itself without any interaction on my part, so clearly it _is_ possible. Maybe it's not possible for what you're selling, but that's why I would like to know what it is you're selling so I can avoid it.
What happens if/when ROKU publish a firmware update which bricks everything they have ever sold?
Obviously they do testing. They probably also do what phone mfgs do: deploy updates slowly, starting with poor countries ;)
Yes one needs a means of updating IOT boxes remotely. My box can do that but the RTOS task to do it is not enabled by default. But compared to your ROKU streaming device, mine can be used in lots of varying applications (I won't go into detail, especially as you have said you will not buy it ;)) so an update could trash one customer's application, and he won't be happy especially since with most of this stuff there is simply no way to track down problems (stuff simply stops working).
This (managing updates and patches and certificates etc) is actually a huge problem in IT, with some of the biggest IT disasters having been caused by certificate expiry. So an IOT box which, via being a *client*, needs no updates, potentially for decades, is hugely beneficial.
The thing I don't know the answer to is how would you design e.g. a heating controller which is remotely accessible. This has been done for decades (I used to do one in the 1980s which was accessed over a phone line modem, so the security was a) knowing the phone # and b) knowing the password) but how do people do it nowadays if the controller is a client, so there is no way to connect *to it* freely. I suspect it is either a server on an open port (with all the vulnerability issues) or the thing which the user's app connects to is not the IOT box but a copy of its config residing on the public server, which the IOT box retrieves periodically, say every 15 mins.
Another way would be to implement something like port knocking on it.
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
So hire a contractor that knows how to do it. It can't be all that hard to find somebody competent.
It *is* very hard to get someone who can dive into a box which took man-years to develop.
Peter
bringing this thread back to squarely on topic:
On Thu, Mar 14, 2024 at 3:56 AM Peter peter@peter2000.co.uk wrote:
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
So hire a contractor that knows how to do it. It can't be all that hard to find somebody competent.
It *is* very hard to get someone who can dive into a box which took man-years to develop.
How does one find a contractor that can help with integrating MBedTLS into their product?
Debian makes it easy - goto https://www.debian.org/ click on the "User Support" link then click on "you may hire a consultant to answer your questions or to maintain or add additional functionality to your Debian system."
Is there anything like that for MBedTLS?
Thanks, Lee
Hi Lee,
Trustedfirmware.org community project doesn't provide any contracting service or commercial support for the open source projects it hosts including Mbed TLS. However, there has been contractor engineers funded by organizations for Mbed TLS features they wanted done. I believe some of those engineers are registered in this mailing list and can probably get in touch with you seeing the message below or if you send a new message with the request.
Regards, Shebu Mbed TLS Technology Manager, Arm Ltd.
-----Original Message----- From: Lee via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Thursday, March 14, 2024 4:55 PM To: Peter peter@peter2000.co.uk Cc: mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Re: MBedTLS 3.5.2
bringing this thread back to squarely on topic:
On Thu, Mar 14, 2024 at 3:56 AM Peter peter@peter2000.co.uk wrote:
The wider issue is that this stuff is now so complex that only people who have spent years working with MbedTLS know how to do it, and know how to incorporate the MbedTLS updates.
So hire a contractor that knows how to do it. It can't be all that hard to find somebody competent.
It *is* very hard to get someone who can dive into a box which took man-years to develop.
How does one find a contractor that can help with integrating MBedTLS into their product?
Debian makes it easy - goto https://www.debian.org/ click on the "User Support" link then click on "you may hire a consultant to answer your questions or to maintain or add additional functionality to your Debian system."
Is there anything like that for MBedTLS?
Thanks, Lee -- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org
On 3/13/2024 10:25 AM, Peter via mbed-tls wrote:
Surely IP cameras (those I have known) contain a server, which many users install on an open port. This was the principal usage model for the original AXIS cameras. You could even find them with a suitably formed google search!
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
There is a classic saying in encryption: it is very easy for someone to design a new encryption algorithm that *they, themselves* don't see how to break.
Device security is a bit like that too. Just because you don't see how an attacker is going to break into your network does not mean nobody will. Lee and others already explained the multiple ways through which attackers could first penetrate a network, and then access devices. And attackers have absolutely done that in the past.
I very much like that the MbedTLS code is following best practice, such as zeroing fields that contained secrets before freeing them. Or the option to refer to keys by handles instead of having them stored in plain text in the applications' memory. Or chasing for side channels and closing them. That's hard, but it should be done.
Of course, most of the actual attacks on devices come down to simpler tricks, such as inserting an MITM and finding the secrets send by client to server, or phishing for credentials, or maybe finding the credentials in the user manual. Which means that we have to pay a lot of attention to configuration issues, certificate verification, key rotation, etc.
We need more attention, not less. Even if the devices are being a firewall -- and certainly if that "firewall" is the ISP-provided WiFi Router + NAT.
-- Christian Huitema
mbed-tls@lists.trustedfirmware.org
-
Christian Huitema -
Gilles Peskine -
Lee -
Peter -
Satya Prakash Prasad -
Shebu Varghese Kuriakose