Live data from Hacker News

Building a Titan: Better security through a tiny chip

android-developers.googleblog.com

21–30 of 55 posts

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

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

Something I've been worried a bit about with RISC-V, hopefully someone can tell me why I'm wrong. If I were implementing some cryptography in assembly on x86 or ARM I would make every effort to avoid branches and use conditional moves instead so as to be more resistant to timing attacks. Is this actually a common technique in computer security? And does RISC-V suffer from not having conditional moves?

RISC-V is technically an ISA with a reference implementation. In theory and practice, it can be implemented as a low-power micro controller or augmented with additional instructions to play in the supercomputer space. Processors simply cannot avoid conditional moves, but they can choose not to speculatively execute after a jump before it knows the result of the jump condition.

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

#22
post #5

Is it made clear anywhere how memory for the Titan enclave works, and whether they've done something similar to Apple with encrypted memory busses?

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

Looks like the security boundary is around the chip itself, so any bus level security would be application specific.

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

#23
post #3

I've been using the Titan, my main feature request is to require a delay on pressing the large button to activate the beacon. Any time I pull it out of my pocket or bump it, it lights up and starts broadcasting. Yubico had this problem, there are images online of random keys showing up in tweets/social status updates etc. I just got their new usb-c nano, and they added a delay that helps out when you accidentally bum…

It’s not very well documented but you can change this feature of the Yubikey using the YubiKey Personalization tool:

https://support.yubico.com/support/solutions/articles/150000...

In addition to the two methods listed, you can also remove the feature completely by deleting the configuration of the OTP slot entirely.

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

#24
post #7

> For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack. Do what now? Edit: seriously what does that sentence mean? Executing off the stack is super dangerous. Even on an M3 you can (and should) setup the MPU to have a non executable stack.

The very next sentence doesn't make sense either:

> And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off.

Flash wear only occurs during erases, so... why does it matter to reduce wear in low-power mode? Why would they be writing to flash during normal operation, except perhaps an authentication counter?

One would hope that they're executing the program out of the flash (that they've previously verified and locked) rather than out of 'stack'. This isn't an operation that causes wear.

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

#25
post #7

> For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack. Do what now? Edit: seriously what does that sentence mean? Executing off the stack is super dangerous. Even on an M3 you can (and should) setup the MPU to have a non executable stack.

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.

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

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

Something I've been worried a bit about with RISC-V, hopefully someone can tell me why I'm wrong. If I were implementing some cryptography in assembly on x86 or ARM I would make every effort to avoid branches and use conditional moves instead so as to be more resistant to timing attacks. Is this actually a common technique in computer security? And does RISC-V suffer from not having conditional moves?

It'd be better to implement it with accumulation rather than conditional moves on all of those other platforms anyway.

You can have branches, you just need to take the same branches regardless of the input.

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

#27
post #7

> For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack. Do what now? Edit: seriously what does that sentence mean? Executing off the stack is super dangerous. Even on an M3 you can (and should) setup the MPU to have a non executable stack.

The very next sentence doesn't make sense either: > And to reduce flash-wear, RAM contents can be preserved even during low-power mode when most hardware modules are turned off. Flash wear only occurs during erases, so... why does it matter to reduce wear in low-power mode? Why would they be writing to flash during normal operation, except perhaps an authentication counter? One would hope that they're executing the p…

Maybe they're saying that the other low power mode would slurp all of sram into flash?

But that still doesn't make sense, SRAM lasts for years on a battery of you're not clocking it, and every little uC I know of that vaguely cares about power lets you do that. Why call it out. Hell, NES games keep their SRAM saves going for decades off a little coin cell.

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

#29

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.

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

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

#30
post #29

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.

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 stack allocated like the original point of this thread.

Post reply on HN