• 4 Posts
  • 887 Comments
Joined 2 years ago
Cake day: June 9th, 2023
  • Akasazh@feddit.nltoTechnology@lemmy.world•Chromecast (2nd gen) and Audio cannot Cast in 'Untrusted' outage [U]English
    7·
    6 days ago

    The following is a copy paste of a reddit comment, displayed in full so no more clicks go to that site. It’s insightful and explains why this takes a while to fix:

    As this outage drags on, lots of us are wondering what’s taking Google so long. Certificate expirations are usually resolved in minutes, so why is this different? Although I briefly spoke to that in my other post and elaborated in the comments, I know folks are still looking for answers. TL;DR

    Google will either need to put in over a month of effort to build and test a new Chromecast update to renew the key, or they will have to coordinate internally between what’s left of the Chromecast team, the Android team, the Chrome team, the Google Home team, and iOS app developers to push out new releases, which almost always take several days to build and test. I expect them to do the latter. A server-side fix is not possible. Background

    First, it’s important to understand how Chromecasts work in a broad sense. A Chromecast is basically a glorified web browser, capable of loading web pages and displaying them full-screen on a TV. When you press the “Cast” button on your phone or computer, that device (the sender) uses a proprietary network protocol called CastV2 to connect to your Chromecast (the receiver) and send it the URL to load, along with extra information like what account to use and what video to play. The Chromecast then loads that URL and streams the media entirely on its own.

    Any device at all can be a sender: although Google provides official senders for Android (inside a system component called Google Play Services), Chrome, and iOS (as a downloadable SDK that developers can include in their apps), there are plenty of unofficial ones too. VLC has its own sender implementation, for example, as does Home Assistant.

    The same is not true for receivers. Because Google went to all the effort of building the Cast ecosystem and getting content providers on board, they don’t want other companies creating Chromecast clones and piggybacking on their hard work. This is where device authentication, the antagonist of our story, comes in. When a sender connects to a receiver, it has the option of asking that receiver to prove that it’s an authentic Google device. The receiver will then create a cryptographic signature using a key that was installed at the factory when it was manufactured. That key is in turn signed by a higher-level key (the certificate authority) only known to Google. Since knockoff devices don’t have access to Google’s certificate authority, they can’t sign their keys the same way.

    [Note that, although a device authentication certificate is like those used by TLS/SSL, it’s not technically a “TLS certificate” because it is not used to establish a TLS connection. The CastV2 TLS connection uses a separate self-signed certificate that isn’t relevant to the security model.] Key expiration

    Every key in this system comes with some additional metadata called a certificate. Among other things, a key’s certificate specifies when the key expires. Most cryptographic libraries will by default reject a signature if the key that created it has expired. Note that this is the only effect of expiration. A key doesn’t magically become unusable once it expires, and all your Chromecast 2s are still happily signing device authentication requests using their expired keys. But, because Google’s senders use standard cryptographic libraries, they no longer see those signatures as valid.

    This wasn’t always the case: the original device authenticator code in Chrome, circa 2013, did not check expiration dates at all, which makes sense for certificates you never intend to renew. Unfortunately, a change in 2016 replaced most of the custom code with calls to standard libraries that do check expiration. Based on the code review comments, it appears that no one at Google noticed the mistake at the time.

    The Chromecast 2 and Chromecast Audio certificate authorities expired two days ago, within seconds of each other. Thanks to the excellent research of /u/meatbox in my other post, we know that more expirations are coming up: the Chromecast Ultra and Google Home CAs will expire in March 2026, and the Google Home Mini CA will expire in January 2027. So how will Google fix this? Why Google won’t renew the certificate

    When a key expires, the solution is almost always to renew it—replace its certificate with a new one, signed by the same CA, that has a later expiration date. But the situation here isn’t so simple: after renewing the expired CA, Google would also have to renew every key signed by it—meaning the factory-provisioned key on every Chromecast 2 and Chromecast Audio in the world. There are lots of obstacles to that:

    It won't reach everyone. Many people have factory reset their devices as a result of this issue, and there are likely at least some Chromecast 2s still sitting unopened in boxes. None of those devices have a way to reach the internet unless the Google Home app can set them up, which it can't right now because it checks key expiration. So a device update alone is not enough: at a minimum, the Google Home app would also need an update.
It's hard. The final update for the Chromecast 2 was built on October 1st, 2021. Google has shut down the Chromecast product line and presumably disbanded the Chromecast teams. Their internal OS build infrastructure has almost certainly been decommissioned. Just bringing back the infrastructure would likely take upwards of a week, and that's not to mention actually making the changes, which wouldn't be at all trivial. Device authentication keys were never meant to be changed, so they're stored on a read-only partition and there's no code in the Chromecast OS to renew them. It's possible Google could piggyback on some server-side infrastructure used by Android-based Cast devices for certificate issuance, but they'd still need to build a renewal client into the Chromecast OS, which is quite different from Android. Designing and building that would likely take at least two weeks.
It's risky. Replacing a key, especially one on a read-only factory partition, carries lots of risk. The process must be built so it can withstand interruption (e.g. someone unplugging the device) at any point in the process while still being secure (i.e. not issuing a certificate to any device that isn't a genuine Chromecast). Code like that takes a long time to test and validate, so add another couple weeks to the timeline.
It doesn't help security. Renewing the certificate brings no security benefit, as a hypothetical renewal service would issue a new certificate to anyone in possession of an old, expired one. That's in contrast to certificate renewal for websites, for example, where you need to prove continued control over your domain in order to renew its certificate.

    Of course, this is all speculation—I have no insider information. Perhaps Google is at this very moment dusting off the old Chromecast OS build infrastructure and preparing a special version of the Google Home app that can get a Chromecast on Wi-Fi to receive an update. I find that highly unlikely, though. What they’ll do instead

    What they did before 2016, of course! Since key expiration is checked only by the senders, Google can update all their senders to ignore expiration when performing device authentication. This is really how it should have been all along, since these keys are supposed to last for an indefinite period. Chrome already has code to fetch a Certificate Revocation List (CRL) for device authentication, which lets Google mark specific keys as compromised, so Google wouldn’t give up any control by removing expiration checks.

    However, even this will probably take about a week, since it requires updates to senders like Chrome and Android. Luckily, Google Play Services, where the Android Cast SDK lives, can be updated independently of the OS, and Google obviously has full control over Chrome releases. But since many teams within the company will need to collaborate, creating and testing such updates isn’t a one-day thing.

    iOS is another matter, though. My understanding is that, since Google doesn’t control any centrally-updated component of iOS like they do Android, they instead give each Cast-enabled app its own copy of the sender code. So, if they release a new iOS SDK, we’ll still have to wait for each content provider (Netflix, Hulu, etc) to update their apps before the fix takes effect. Hopefully most will do it promptly, but there’ll probably always be some old unsupported apps that are broken for good.

    The only faster option for Google would have required some foresight on their part: client features like device authentication, which aren’t crucial to a product’s core functionality and carry a risk of breaking, often have remote “kill switches” built in that let the vendor disable them temporarily with a server-side change. But if one of those existed, I’m sure Google would have already flipped it. I didn’t see evidence of any way to disable device authentication in the Chrome source code. Google Play Services does have a toggle, which is what the workaround I posted uses, but I haven’t seen evidence of a way for Google to toggle it remotely.