> 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.<p>and<p>> 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.<p>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.
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.<p>No Side Channel Attack resistance.<p>No fuses to attest supply chain provenance or lifecycle.<p>No direct connections for FIDO hardening.<p>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 <i>sole purpose is to establish a secure chain of trust</i> and starts out the gate broken with ambiguous or misleading claims.<p>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.
Google has 3 Titans.<p>1) Titan for GCP servers: <a href="https://cloud.google.com/blog/products/gcp/titan-in-depth-security-in-plaintext" rel="nofollow">https://cloud.google.com/blog/products/gcp/titan-in-depth-se...</a> (custom hardware, custom software)<p>2) Security key: <a href="https://cloud.google.com/titan-security-key/" rel="nofollow">https://cloud.google.com/titan-security-key/</a> ("built with a hardware chip that includes firmware engineered by Google" - seemingly stock hardware, custom software)<p>3) Titan M mobile: (TFA, custom hardware/software like #1 but for mobile)
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?<p>[1] <a href="https://techsolidarity.org/resources/basic_security.htm" rel="nofollow">https://techsolidarity.org/resources/basic_security.htm</a>
So the new Pixel includes U2F hardware in the device? That's cool - apparently, the flagship Chromebook has dormant U2F hardware, too.<p>Unfortunately, some providers (mainly Twitter) poorly implemented U2F by only allowing one device per account.
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?
>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.<p>very explicit threat-modeling with the FBI in mind
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 bump it.
> For example, packing as many security features into Titan M's 64 Kbytes of RAM required all firmware to execute exclusively off the stack.<p>Do what now?<p>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.
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.<p>What advantages does these Titan chips offer over the existing trustzone technology.
> 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.<p>It would be nice to see this being replaced by an an open-source RISC-V processor in the future, too.
...that's made in China.<p><a href="https://motherboard.vice.com/en_us/article/mb4zy3/transparency-google-titan-security-keys-china" rel="nofollow">https://motherboard.vice.com/en_us/article/mb4zy3/transparen...</a>