and
> Transparency around every step of the design process — from logic gates to boot code to the applications — gives us confidence in the defenses we're providing for our users. We know what's inside, how it got there, how it works, and who can make changes.
This should be a boon for security researchers! I'm really looking forward to what comes out of fuzzing that whole subsystem. I imagine attacks against the secure enclave would be a lot easier to perform (and ideally, report to Apple) if it was feasible to attack it with pure software.
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.?
Google and Titan are a large part of this effort and it will be great for security researchers.
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 the Titan M used in Servers and Phones and now Chromebooks. None of this would matter so much other than the fact that products sole purpose is to establish a secure chain of trust and starts out the gate broken with ambiguous or misleading claims.
This is frustrating because the Titan M is an absolutely brilliant device, with some real advancements to normalize embedded security, including an SPI interposer to monitor communications (a real leap forward) - and should not at all be conflated with a generic, whitelabeled, non-hsm product that makes no claims whatsoever.
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...
1) Titan for GCP servers: https://cloud.google.com/blog/products/gcp/titan-in-depth-se... (custom hardware, custom software)
2) Security key: https://cloud.google.com/titan-security-key/ ("built with a hardware chip that includes firmware engineered by Google" - seemingly stock hardware, custom software)
3) Titan M mobile: (TFA, custom hardware/software like #1 but for mobile)
Unfortunately, some providers (mainly Twitter) poorly implemented U2F by only allowing one device per account.
Looks like the security boundary is around the chip itself, so any bus level security would be application specific.
very explicit threat-modeling with the FBI in mind
Google is part of this effort, more likely that you can get hands on some of the tech threw this project.
Also, the Bluetooth Titan Security Key has its own battery since it nees to be able to power the BT radio when it's not connected to anything else. So if you accidentally hit its button while you pull it out of your pocket, it can start transmitting.
In the case of the USB-C and USB Security Keys, (a) they are powered off of the USB bus, and have no batteries, so they are inactive when they are not powered up, and (b) all U2F keys don't need to to look like a keyboard (e.g., be a USB HID device). So random strings showing up when you accidentally touch a U2F key is never a thing. The issue with Yubikeys is that the can be both a U2F security key as well as a traditional HOTP token. If you disable the HOTP feature in a Yubikey device (using the Yubikey personalization tool), the problem of random HOTP passwords showing up in tweets, etc., goes away.
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.
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.
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.
> 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.
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.
What advantages does these Titan chips offer over the existing trustzone technology.
Plus, they want a full, open source, verifiable system which isn't possible with ARM IP.
It would be nice to see this being replaced by an an open-source RISC-V processor in the future, too.
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.
You can have branches, you just need to take the same branches regardless of the input.
Google is helping with this effort and it will be RISC-V enclave.
https://motherboard.vice.com/en_us/article/mb4zy3/transparen...
