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

41–50 of 55 posts

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

#41

Post by aesh2Xa1 »

jlgaddis wrote: post #40
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…

It isn't so much one guy vs all of Google doing the work. It's more like the team that Google employs vs the entire rest of the infosec and academic community. This is a treasure.

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

#42

Post by ngngngng »

sigmar wrote: post #18

>Last, but not least, to prevent tampering, Titan M is built with insider attack resistance. The firmware on Titan M will never be updated unless you have entered your passcode, meaning bad actors cannot bypass your lock screen to update the firmware to a malicious version. very explicit threat-modeling with the FBI in mind

Why does this matter when a google device sends all information home and can be requested by the FBI with a sweeping gag order warrant? Seems like more security theater to me.

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

#43

Post by monocasa »

camgunz wrote: post #37
monocasa wrote: post #30

Earlier quoted context omitted.

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.

> Well but regardless, if you have a malloc or new implementation that uses a static buffer, then you're still not touching the heap.

What do you think the heap is on systems without an MMU?

> 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.

You can go for an awfully long time without knowing that you dangling pointers to auto allocated objects.

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

#44

Post by monocasa »

camgunz wrote: post #36
monocasa wrote: post #25

Earlier quoted context omitted.

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,…

> I don't know about "commonly". In my experience with embedded C, if you needed things you declared them statically and never used malloc.

I mean, it's common enough that MISRA, the JSF standard, and the NASA standard all specifically call it out to allow it under these conditions.

> 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.

You only need to call alloca on dynamically sized stack allocations. You can always leak pointers to fixed size objects by:

  void* woah_dont_do_this(void) {
    int value = 0;
    return &value;
  }
and boom, the pointer that gets returned is pointing at invalid memory. Of course, no one would write it like this, but it's way easier than you might think to accidentally do this once there's some abstraction.

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

#45

Post by snowwrestler »

bitmapbrother wrote: post #38
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.

No one even bothered to attack the Pixel at last year's Mobile Pwn2Own.

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

#46

Post by nickik »

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…

Check out this: https://keystone-enclave.org/

Google and Titan are a large part of this effort and it will be great for security researchers.

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

#47

Post by nickik »

amluto wrote: post #10

I hope Google sells these chips with a breakout board. Even better if you could order them with custom root signing keys

Look out for: https://keystone-enclave.org/

Google is part of this effort, more likely that you can get hands on some of the tech threw this project.

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

#48

Post by nickik »

ngngngng wrote: post #42
sigmar wrote: post #18

>Last, but not least, to prevent tampering, Titan M is built with insider attack resistance. The firmware on Titan M will never be updated unless you have entered your passcode, meaning bad actors cannot bypass your lock screen to update the firmware to a malicious version. very explicit threat-modeling with the FBI in mind

Why does this matter when a google device sends all information home and can be requested by the FBI with a sweeping gag order warrant? Seems like more security theater to me.

Even if assume Google sends stuff to the FBI. You still want secure hardware so that nobody else can get at your stuff.

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

#49

Post by nickik »

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.

You are in luck. That's pretty much what Keystone is. See: https://keystone-enclave.org/

Google is helping with this effort and it will be RISC-V enclave.

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

#50

Post by jor-el »

Can someone throw some light on why Google is not using ARM Trustzone technology? Many current Android OEMs are using it, particularly Samsung KNOX is security mechanism all built around trustzone technology.

What advantages does these Titan chips offer over the existing trustzone technology.

Post reply on HN