Your MCU likely escaped the eMudhra intermediate CA compromise | Hacker News Reader

Your MCU likely escaped the eMudhra intermediate CA compromise

danielmangum.com

69 pointshasheddan28 comments

tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.

In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?

This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.

> sometimes due to real constraints

IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).

To be clear, I agree that it is not a valid excuse and pushback is warranted.

> physical security system

> can be trivially MITMed

Crazy how poor security can be even from a purported security vendor.

Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.

I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.

In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.

Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI? The vendor similarly has no interest in explaining its buyers how to do that so it can connect "securely" to their particular alarm monitoring service.

There are some goodish options for how we could secure communications with local network devices hosting simple configuration WebUIs, but the browser vendors have overwhelmingly demonstrated that they have no interest in any of them. So what you ship is HTTP, not even the self-signed certificate, that just gets scary messages.

(What the browser vendors seem to want, to be clear, is that your gadget reaches out securely to the Vendor Cloud^TM, and you similarly use your Google and Apple notarized smartphone to reach out to that same Cloud, so you can talk to the hardware sitting a meter away from you)

> Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI?

Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:

* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.

* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.

As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.

[1] https://elk-manuals.s3.amazonaws.com/M1XEP_v2_Installation_M... page 14

Fun fact: esp-idf includes an x509 Certificate Bundle API[0] that will pull in the entire Mozilla trust store by default. However, they will be stripped unless firmware calls `esp_crt_bundle_attach`. There is an issue[1] tracking removal of the eMudhra root CA certificate.

[0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...

[1] https://github.com/espressif/esp-idf/issues/19282

https://news.ycombinator.com/item?id=50166579 - “eMudhra intermediate CA compromise” - 947 points | 19 hours ago | 408 comments

https://news.ycombinator.com/item?id=50177916 - "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" - 604 points | 7 hours ago | 270 comments

Your device would also have to be pretty recent to ship any of these certs in a frozen cert store as they were only generated in April/May of 2025.

Of all the places for what is otherwise eMudhra's epic fail, various MCUs was the one place I thought perhaps there'd be some silver lining. Some interesting and good, for the hackers: to get to have some chance to see what their devices are doing, to man-in-the-middle those conversations home those devices in our homes are doing, and see what they are saying.

This fact alone though makes that very unlikely.

I don't think that applies here. The trust store contains the _root_ certificate, not these intermediates.

The main eMudhra root cert backing these intermediates is "emSign ECC Root CA - G3", which was issued back in 2018 and was widely trusted for TLS way before these intermediates were created. The certs were also cross-signed by Sectigo using their "AAA Certificate Services" which was issued in 2004 (!!!) and was trusted in TLS stores until 2025 (after that it got removed/demoted to email signing only, depending on the store).

Everything which trust one of those roots will trust the intermediates (putting aside revocation, CT checks, lack of ECC support, etc) so the window is much much longer. The AAA does expire at the end of 2028 though!

Yep, you're right. Can't edit my comment any more, but it is wrong. Thanks for the correction.

I must have missed when de facto definition of MCU started including being on the network and doing crypto :-)

IoT devices typically run on MCUs and they have WiFi connections, often. The price of MCUs with WiFi has gone down dramatically. Often $5 or less for a MCU capable of WiFi and usually Bluetooth. Think, ESP32-S3 and such.

Right, I'm used to the name referring to 8-bit parts without MMUs. How the times have changed...

8-bit parts are still around, but the cost savings often isn't worth it for smaller volume production compared to 32-bit MCUs. Easier development saves a lot of money. 32-bit parts are dirt cheap, and the varieties with built-in WiFi or Bluetooth or such are usually cheaper than separate MCU + radio + development to integrate the two. 8-bit flip-chip parts are even cheaper, but the bill of materials (BoM) savings aren't big enough to pay for the added engineering effort to use them for anything but the simplest tasks or the biggest volume products.

MCUs refers to all sorts these days.

For example, the RP2350 is a $1 MCU that includes 2x ARM Cortex-M33 cores or 2x Hazard3 RISC-V cores running at 150 MHz.

The RISC-V cores have M-mode and U-mode, and a Physical Memory Protection unit.

The ARM cores have a Security Attribution Map and an Implementation-Defined Attribution Unit which tags accesses to devices like GPIO/PWM/ADC/... based on the security level of the code performing that access. It also has 2 Double-Precision Coprocessors for each ARM core, one for secure and one for non-secure code. It also has secure boot support if you run its cores in ARM mode.

If we are using IBM's[1] definition, then MCU refers to Harvard architecture while MPU would be von Neumann.

However the wiki article for MCU says that it can refer to either, so I guess there isn't always a difference anymore depending on how you define it.

[1] https://www.ibm.com/think/topics/microcontroller-vs-micropro...

Renensas has 1Ghz Cortex-m85 MCU that i bet it runs much faster than some of old Cortex-A cores.

So MCUs or any embedded that doesn't get updates will likely only be good for up to the validity of the included CA root before bricking up?

These days thats up to 15 years. Talk about programmed obsolescence.

I think there's a real argument for trying to push "user must be able to control their device's trust anchors" as the next right to repair battle.

If you don't, you can never tell what a device is sending/receiving, and devices have a hardcoded end-of-life date where they become useless. Would love to see groups starting to push in this direction.

Ooh I like that in principle and, on paper, would be also a good opportunity to further decentralize the power root CAs have today.

Also would be quite complex for regular users to even grasp and then to choose their trust provider. Cynical me thinks this would just end up giving more power to the device manufacturers and centralize on handful of better known 'trust providers'. No non-techie person I know has heard of Verisign but everyone knows Meta.

If by "good" you mean vulnerable, that depends on how it keeps time.

If you can feed it a fake NTP server that's set in the past, then it could potentially stay vulnerable forever, especially if you're the one doing a MITM on it... otherwise attempts to contact third-party servers you're not masquerading as will likely fail due to expired certs (some time in 2028 IIRC for the eMudhra ones).

I really meant good as just working for their intended purpose before they become bricks because they can no longer make requests they 'require'.

But the fake NTP approach makes sense to fool them for either intended or vulnerable purposes.

> Mozilla has maintained a dedicated CA Certificate Program since the initial launch of Firefox

umm, they had already been maintaining the program for almost a decade at that point.

TL;DR: Your MCU likely doesn't have enough space to dedicate so much of it to a full CA store, so it is unlikely to trust those CAs (claims the post).

So many words for such a simple point/claim...

Reply on news.ycombinator.com