
A mysterious bug in the firmware of Google's Titan M chip - alexbakker
https://alexbakker.me/post/mysterious-google-titan-m-bug-cve-2019-9465.html
======
monocasa
Wow, I normally am all about how google handles security issues (they get
dragged through the mud for some Project Zero stuff), but this def did not get
handled well.

Super unclear communication, starting with "you're just using it wrong", more
than six month turn around, and even then at the end no clear explanation of
what went wrong with someone who was collaborating with you? That's amateur
hour security.

~~~
ignoramous
I'd pay to see Bryan Cantrill's reaction [0][1] to this: A seemingly
mysterious firmware bug of a secure element / trusted-execution-environment
but there's no knowing if there are more bugs (or, _shudder_ backdoors).

Since the source code isn't available for scrutiny (though Google has promised
_firmware transparency_ [2]), it is kind of difficult to tell what really went
wrong in the current reported case and what else possibly could go wrong given
the use-cases for it are far-reaching and sensitive: Google has advocated
StrongBox as a trustable companion that _could be_ used to attest user actions
on medical devices [3], for instance; or for use as an Identity verificafion
for documents such as Driving Licenses and Passports.

[0] [https://www.youtube-nocookie.com/embed/30jNsCVLpAE](https://www.youtube-
nocookie.com/embed/30jNsCVLpAE)

[1] [https://www.youtube-nocookie.com/embed/fE2KDzZaxvE](https://www.youtube-
nocookie.com/embed/fE2KDzZaxvE)

[2]
[https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m](https://www.youtube.com/watch?v=0uG_RKiDmQY?t=33m)

[3] [https://android-developers.googleblog.com/2018/10/android-
pr...](https://android-developers.googleblog.com/2018/10/android-protected-
confirmation.html)

~~~
sneak
More troubling to me than the closed source firmware is that the bug in TFA
seems like something that the most basic of a test suite should be catching.

It’s reminiscent of Apple’s “goto fail” lack of certificate checking - another
easily testable case that simply wasn’t.

The test authors don’t even need to be on the same team/manager. They can just
write black box tests to the spec, like the author of this post did.

I’m not even some big TDD guy. It just seems to me that in these core
security-critical libraries/functions that should be pretty side-effect-free
that you should have some basic “receive x, produce y” functional tests to
make sure the API is doing what it claims to do on the tin.

~~~
pvg
_the most basic of a test suite should be catching._

A most basic test suite is not likely to wait some arbitrary amount of time (2
seconds, as the author found by trial and error) between calls to the HSM.

~~~
sneak
The way I read the article was that it fails immediately, it just fails in a
different way after two seconds.

Perhaps catching the instantly reproducible failure before release would have
lead them to the root cause of both.

~~~
pvg
The images in the 'Digging deeper' section suggest otherwise. They appear to
show a successful run followed by one that fails because the 'encrypted' value
is garbage. Where am I missing the instantly reproducible failure?

------
_Microft
Could it be that the first excerpt
([https://github.com/beemdevelopment/Aegis/blob/def7c676148f26...](https://github.com/beemdevelopment/Aegis/blob/def7c676148f261c1adf28bf1fc3d9fc03a25985/app/src/main/java/com/beemdevelopment/aegis/crypto/KeyStoreHandle.java#L47-L67)
) should not have included the line with _.setIsStrongBoxBacked(true)_ yet?

 _Edit:_ funny: _0dd0adde_ looks a lot like _deadd00d_ (like "dead dude") with
a reversed byte order. If this is a coincidence?

 _Edit2:_
[https://www.bing.com/search?q=deadd00d](https://www.bing.com/search?q=deadd00d)

~~~
v64
Very interesting observation!

"Comments on a number of StackOverflow questions have pointed out that a fault
address of deadd00d indicates a deliberate VM abort."

That ending up in the ciphertext multiple times seems to point to some memory
corruption issue. It's also a good argument for using magic numbers that stand
out.

------
RedComet
Another case of Google not following their own rules. But they're happy to
hang others out to dry when they exceed 90 days.

~~~
bArray
Yep I fully agree, you can't hold others to a standard you're not willing to
hold yourself to. I specifically remember Microsoft begging for more time on a
bug.

Also if I understood it correctly, it seems as though some devices may require
a factory reset to apply the new firmware? If so, for a lot of devices this
still isn't fixed.

~~~
alexbakker
The big question is indeed how many devices got themselves into this 'bad
state'. Your guess is as good as mine.

------
alexbakker
Author here. I should have made this clear in the blog post, but I'd be
interested in seeing boot logs from Pixel 3 (or newer) devices. If the
firmware update failed on more devices than just mine, it would be good to
know about that. If you'd like to help, first make sure you're at least on the
December 2019 security update. To capture the log plug your phone into a
computer, run "adb reboot ; sleep 1 ; adb logcat | grep -i citadel" and turn
the phone back on. Wait for it to boot, unlock the SIM card and unlock the
screen. This should yield the version information of the firmware of Titan M.

~~~
alexandrerond
Mine got updated it seems

------
4cao
The most important takeaway is to stick to the 90-day disclosure policy. The
deadline is only credible when it's enforced, and on a number of occasions
Google have stated they believe so themselves. [1]

1\.
[https://www.google.com/search?q="deadline+exceeded"+"automat...](https://www.google.com/search?q="deadline+exceeded"+"automatically+derestricting")

------
kemonocode
The fact they still haven't gone around to open-sourcing the Titan M firmware
is, honestly, what worries me the most about this. It's probably going through
some _heavy_ internal auditing now, which is not the best approach, all things
considered.

------
tpmx
If I were an Android user: I'd feel good with how Google managed this one.

Regarding NSA vs Google (seems like after I commented on a corona virus thread
a few times, I was rate limited - editing existing comments still works
though):

@baybal2:

"NSA infiltrates links to Yahoo, Google data centers worldwide"

[https://www.washingtonpost.com/world/national-
security/nsa-i...](https://www.washingtonpost.com/world/national-security/nsa-
infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-
say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html)

"Googlers say “F __* you” to NSA, company encrypts internal network "

[https://arstechnica.com/information-
technology/2013/11/googl...](https://arstechnica.com/information-
technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-
network/)

@monocasa: Got a credible source?

~~~
monocasa
Google is part of PRISM and was (and probs still is) collaborating directly
with the government.

~~~
imglorp
Except for the 2013 "Oh shit" slide from the Snowden dump. At least part of
Google wasn't on board.

~~~
monocasa
That was MUSCULAR, not PRISM. It was to exceed the access that even PRISM gave
them.

~~~
lern_too_spel
PRISM doesn't give the government additional access to anything. It simply
ingests data that the FBI has already collected by wiretapping individuals
under investigation.

Edit (responding too fast):

> It by default gives government access without anyone at Google or anywhere
> else granting that access at time of use.

Where did you get that idea? All the documents show that it ingests data the
FBI already has, for individuals the companies already _manually_ approved
after potentially fighting about it with a judge. You simply made up an
illegal system out of whole cloth that wouldn't last a minute in court if
anybody challenged it, unlike the phone metadata program, which went through
two courts to conclude its illegality.

Edit 2:

> Page five lists the companies and page six lists the per company agreement
> date. Unless you're trying to argue that Google didn't respond to
> wiretapping requests from the FBI at all before 2009.

The FBI has to set up a system for canonicalizing and routing data from each
different company. Those dates list when the FBI did that for each company.
Since almost nobody (including suspected terrorists, apparently) uses Apple's
email service, their system was the lowest priority to support.

This is well documented, both in Snowden's documents and in documents the
government later declassified. Once again, if PRISM were as you described it,
it would be flagrantly illegal and shut down long before the phone metadata
program.

Edit 3:

iMessage was launched near the end of 2011, and FBI's DITU handles _content_
collection via wiretaps. When are you going to address the fact that the
program from your fever dreams is insanely illegal and that it doesn't match
any of the documents? If you would like me to respond normally, upvote my
comments, so I don't get rate-limited.

~~~
monocasa
It's automated systems for those requests. It by default gives government
access without anyone at Google or anywhere else granting that access at time
of use.

It does record the request though which is why NSA tried to exceed the bounds
of that with MUSCULAR.

Edit to respond to your edit: Page five lists the companies and page six lists
the per company agreement date. Unless you're trying to argue that Google
didn't respond to wiretapping requests from the FBI at all before 2009.

Edit 2 since apparently this is how we're doing this:

> Since almost nobody (including suspected terrorists, apparently) uses
> Apple's email service, their system was the lowest priority to support.

There's a fuck ton of metadata that iMessage reports back up; PRISM isn't just
about email. And yes, iPhones are the most common smartphone in the world. I
guarantee you that Apple isn't last because they were a low priority, that's
absolutely absurd.

Edit 3:

Your argument that "it would be illegal and shutdown like the other illegal
programs documented here if it were actually illegal" has to be one of the
hottest takes I've heard.

And the PRISM collection was part of what the Supreme Court dismissed not
because it isn't illegal, but because you can't prove that affected the
claimant personally without a breach to national security, so they can't prove
they have standing, so the case had to be dismissed.
[https://www.aclu.org/files/assets/amnesty_v_clapper_scotus_o...](https://www.aclu.org/files/assets/amnesty_v_clapper_scotus_opinion.pdf)

~~~
lern_too_spel
> they can't prove they have standing,

The plaintiffs in _Clapper v Amnesty_ would have standing if the program
worked as you described. No documents have ever been released saying the
program works as you described, including the documents Snowden leaked after
that case. If such docu6were released, the case would be relitigated. Here is
an article describing how it actually works, linking to multiple sources:
[https://www.cnet.com/news/no-evidence-of-nsas-direct-
access-...](https://www.cnet.com/news/no-evidence-of-nsas-direct-access-to-
tech-companies/)

> "it would be illegal and shutdown like the other illegal programs documented
> here if it were actually illegal"

How did _one_ illegal program turn into multiple "illegal _programs_ "? How do
you come up with this stuff?

~~~
monocasa
> The plaintiffs in Clapper v Amnesty would have standing if the program
> worked as you described.

No, because the way the system works is that information makes it's way to the
NSA on the presence of certain search terms and is prefiltered before it ends
up in their hands. The ruling by the supreme court in the case of PRISM is
that amnesty international can't prove that they were among the search terms
ever searched for, so they can't prove that they standing. Only if there was a
leak of the actual keys slated for collection (or if the NSA agreed to release
that, which would never happen), then they could relitigate.

This is in contrast to the bulk call data, where, because the NSA was
collecting from everyone who made calls, standing could be confirmed.

> How did one illegal program turn into multiple "illegal programs"?

I'm bundling it up with the other programs Snowden leaked.

~~~
lern_too_spel
> No, because the way the system works

That's not how the system works. The system allows collection of data to/from
_specific_ non-Americans outside the US. Amnesty International didn't know
that it was for specific individuals at the time they filed their suit, but
Snowden's leaks and later the DNI confirmed it.

> I'm bundling it up with the other programs Snowden leaked

Once again, only one of them (phone metadata collection) was illegal. The
other programs he leaked, including PRISM, are so legal that nobody with any
sense would attempt to challenge them.

------
aasasd
@alexbakker: could you please make code in the snippets wrap at least when
viewed on a phone? I gain nothing from them being non-wrapping, while having
to scroll back and forth to read. In each editor I've used, code soft-wraps at
screen edge, so I don't even understand where this trend came from.

~~~
qu4z-2
As a counterpoint, I always disable wrapping in my editor, as I find it much
less readable wrapped.

~~~
aasasd
Well, at least you're likely editing on the desktop. On a phone, reading code
listings is PDF all over again.

------
m3kw9
Maybe this mysterious “bug” is a backdoor

~~~
jasonvorhe
Maybe you should refrain from spreading rumors?

Hanlon's razor applies.

------
baybal2
I remind you, Google was one of the companies caught collaborating with NSA as
per NSA leak by Edward Snowden

~~~
shadowgovt
The Snowden leak indicated Google's internal network has been physically
compromised. That's the opposite of collaboration.

Google is still a big target for the NSA and other espionage organizations.

~~~
monocasa
Two separate programs. They collaborated with PRISM, and MUSCULAR hacked
Google to provide even more access than was negotiated.

~~~
snowwrestler
PRISM was just a fancy NSA source name for “the FBI serves warrants and
collects data on our behalf.”

~~~
monocasa
PRISM involved automated systems created by the various companies to comply
with FISA requests that could originate from the NSA but would be served by
the FBI.

~~~
lern_too_spel
No. The FBI issues Section 702 data requests for individual users to the
companies, whose lawyers manually review the requests and may dispute them
before a FISC judge. Only after the company approves the request do they start
sending data to the FBI's DITU. PRISM consumes the data from DITU's servers.

The system that sends new communications with the monitored individual to the
FBI is definitely automated, but configuring an account to be surveilled is a
manual process controlled by the company, not the FBI, and certainly not the
NSA. The reason you cannot provide documents that say otherwise is that they
don't exist. The reason those documents don't exist is that the program that
you've described is a conspiracy theory fiction.

[https://www.cnet.com/news/no-evidence-of-nsas-direct-
access-...](https://www.cnet.com/news/no-evidence-of-nsas-direct-access-to-
tech-companies/)

~~~
baybal2
> The reason those documents don't exist is that the program that you've
> described is a conspiracy theory fiction.

PRISM was once told to be a conspiracy theory fiction

~~~
lern_too_spel
> PRISM was once told to be a conspiracy theory fiction

PRISM as it actually is was never a conspiracy theory. PRISM as Greenwald
described it was and remains a conspiracy theory.

