Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Titan: Better security through a tiny chip

android-developers.googleblog.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Building a Titan: Better security through a tiny chip

#31

Post by joshuamorton »

paulgerhardt wrote: post #20

I recently bought a few Titan products (the security key) - I was pretty bummed to find out that it had none of the features claimed by the Titan family. No Side Channel Attack resistance. No fuses to attest supply chain provenance or lifecycle. No direct connections for FIDO hardening. Apprantly the Titan keys given to Google employees were different than the Titan keys sold to the public. Themselves different from…

>fact that products sole purpose is to establish a secure chain of trust

I think the right way to explain it is that "Titan" is the project to establish a secure chain of trust from user to server and back, making sure that every piece of hardware and software (and every human in the chain) is what it says it is and is doing what its supposed to be doing.

From that perspective, the Titan M, titan key, and serverside titan chip[1] are all pieces of the same project.

[1]: https://cloud.google.com/blog/products/gcp/titan-in-depth-se...

Re: Building a Titan: Better security through a tiny chip

#32

Post by colemickens »

philip1209 wrote: post #2

So the new Pixel includes U2F hardware in the device? That's cool - apparently, the flagship Chromebook has dormant U2F hardware, too. Unfortunately, some providers (mainly Twitter) poorly implemented U2F by only allowing one device per account.

Wow, so after it took them years to get U2F, you can only enroll one device? Is it still setup to require that you activate SMS 2FA too (thereby backdooring your entire 2FA process). I swear, I don't understand how Twitter is so utterly useless at things like this.

Re: Building a Titan: Better security through a tiny chip

#33

Post by kbumsik »

mtgx wrote: post #14

> Titan M's CPU is an ARM Cortex-M3 microprocessor specially hardened against side-channel attacks and augmented with defensive features to detect and respond to abnormal conditions. It would be nice to see this being replaced by an an open-source RISC-V processor in the future, too.

I think it would be replaced by Cortex-M33, which has much higher security feature with TrustZone for microcontroller.

I personally don't see the benefit for us of using open-source processors by companies like Google. They are not going to open-source the design to the public anyway.

Re: Building a Titan: Better security through a tiny chip

#34

Post by jsjohnst »

m3rc wrote: post #17
krn wrote: post #15

How does the latest Google's hardware compare to the latest Apple's hardware in terms of security? Can Pixel and Pixelbook now be recommended to journalists[1] as reasonable alternatives to iPhone and iPad, or are Apple's products still much better in this regard? [1] https://techsolidarity.org/resources/basic_security.htm

I'm pretty sure the Pixel 2 had hardware keystore security on par with an iPhone 6/7, which is what that suggests.

GP didn’t ask “hardware keystore” and either way, it’s a false assumption you made. The Titan M is the first comparable chip, based on marketing speak, to Apple’s equivalent. Give it time to see if the marketing speak lives up to technical reality, but my guess at this point is that they’ll be roughly comparable now.

Re: Building a Titan: Better security through a tiny chip

#36

Post by camgunz »

monocasa wrote: post #25
Arnavion wrote: post #16

Earlier quoted context omitted.

It means the firmware does not have a heap for dynamic allocation, not that it's generating and executing code in buffers on the stack.

That also doesn't make sense. You commonly have a heap but no runtime allocation under such circumstances. MISRA, JSF C++, and even NASA code guidelines say no dynamic allocation after initialization . If it's written in C or C++, that's also crazy town, and you're pretty much guaranteed to have dangling pointers as auto allocated objects are left behind on old stack frames.

I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc. It's not like you're calling alloca and letting those pointers escape -- any (valid) pointer you might have is to a static allocation or memory mapped address.

C++ is a different game and I don't know anything about it though.

But yeah the way I read this is they don't use malloc, which is pretty standard. This is how I've heard it referred to many times, and nothing else makes any sense.

Re: Building a Titan: Better security through a tiny chip

#37

Post by camgunz »

monocasa wrote: post #30
ummonk wrote: post #29

Earlier quoted context omitted.

That isn’t really a heap then. Just normal static allocation.

Nah, you can still call malloc/new. Worked on a sweet RTOS that had tons of default overrides for new that ultimately let you define all layout from your top level module despite following these guidelines. Let you share tons of code across boards, but still make decisions like "this guy's buffers should be this big, and stored in this ram bank" all from the top level C++ file for each board. And it's definitely not…

Well but regardless, if you have a malloc or new implementation that uses a static buffer, then you're still not touching the heap. In fairness and as you point out, it's not the stack either, but they're obviously not letting stack allocations escape. Nothing would ever work.

Re: Building a Titan: Better security through a tiny chip

#38

Post by bitmapbrother »

krn wrote: post #15

How does the latest Google's hardware compare to the latest Apple's hardware in terms of security? Can Pixel and Pixelbook now be recommended to journalists[1] as reasonable alternatives to iPhone and iPad, or are Apple's products still much better in this regard? [1] https://techsolidarity.org/resources/basic_security.htm

The Pixel phones have been unhackable at Pwn2own events while iPhones fall like flies in the hands of the Chinese groups.

Re: Building a Titan: Better security through a tiny chip

#40

Post by jlgaddis »

tetrep wrote: post #4

> Finally, in the interest of transparency, the Titan M firmware source code will be publicly available soon. While Google holds the root keys necessary to sign Titan M firmware, it will be possible to reproduce binary builds based on the public source for the purpose of binary transparency. and > Transparency around every step of the design process — from logic gates to boot code to the applications — gives us confi…

> I'm really looking forward to what comes out of fuzzing that whole subsystem.

Surely Google uses (a portion of, at least) their massive compute resources to do exactly this sort of thing before these chips even get anywhere close to an assembly line or being built in to new devices? Is an independent security researcher going to be able to try anything Google themselves haven't already tried?

Or is it kind of like brute-forcing a 256-bit key where, no matter how much "firepower" you have available, you'll never come close to trying all possible combinations of inputs, etc.?

Post reply on HN