> 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?
Building a Titan: Better security through a tiny chip
21–30 of 55 posts
Re: Building a Titan: Better security through a tiny chip
#22Is it made clear anywhere how memory for the Titan enclave works, and whether they've done something similar to Apple with encrypted memory busses?
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
#23I'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…
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> 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.
> 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> 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.
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> 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?
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> 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…
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
#28Re: Building a Titan: Better security through a tiny chip
#29Earlier 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.
Re: Building a Titan: Better security through a tiny chip
#30Earlier 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.
And it's definitely not stack allocated like the original point of this thread.