"...Titan cryptographically associates the log messages with successive values of a secure monotonic counter maintained by Titan, and signs these associations with its private key. This binding of log messages with secure monotonic counter values ensures that audit logs cannot be altered or deleted without detection, even by insiders with root access to the relevant machine."
If you trust the software you booted (which seems to be the main feature), why would you need a hardware module to sign your logs? I.e. what additional attack scenarios does hardware-based log signing prevent?
The best security is like an onion. Let's say something goes wrong/funky and you're concerned an outside actor may have somehow gained access to the "secure" system. Can you trust your logs?
The log signing prevents undetected tampering after-the-fact; the goal is to make it readily apparent when log messages are altered or deleted, even by parties with root access.
Pardon my ignorance in hardware matters, but I would assume Google gets these manufactured via a third-party.
What would be the process for verifying that the chip itself has not been compromised during manufacture?
Is this a hardware + software verification combo, so a tainted chip would not be recognized as valid by the software - so you'd need to compromise both to bypass?
Typically, a digital chip such as this is designed with Verilog (or VHDL in europe) for RTL. Most hardware compilers then also provide test vectors (for registers and logic) and built in boundary scan through SPI. When contracting the chip your in-house design software then generates GDS (semiconductor mask design format) which you provide to the vendor. Even without obfuscation, it would be enormously difficult to reverse engineer enough of the design to pass the boundary scan test vectors. Certainly, after manufacture you can decap and check that the product matches the mask.
There are various extra design and production steps I'd go through for crypto verification and test, but it would be difficult to fake a chip if they allow verification after SMT on the PCB. After that, physical access and fairly sophisticated methods could bypass it, but you're already trusting TehGoog... so NoSuchAgency shouldn't be your concern.
I'm not sure what Google does, but there are companies out there that help detect counterfeit hardware in bulk parts shipments. They will chose random samples from a batch and crack them open to compare with what they expect.
Assuming you use Intel chips, how do you manage to trust the firmware/ME from them? Do you write your own BIOS to ensure that it is safe? Or do you use ARM/PowerPC/other ISA and have an entirely open source stack?
Does the Titan assume no phyiscal access? And if you do assume someone could steal the chip/try to reverse engineer the chip, do you have anything in it to stop an adversery? I would wonder if there would be a private/nation state agency would want access to certain secrets so bad that they would try to alter it physically, rather then through root access.
Both the Titan chip and all software that runs on it are designed entirely in-house, so we have full control over the stack. And we do have physical tampering countermeasures in place.
This looks like a pretty cool project. How much research went into creating Titan? Why did Google decide to create a custom hardware-based solution (Titan) instead of using something off the shelf, like Intel's Secure Boot?
With Titan we know exactly how it is designed and how it'll behave. Titan is also platform-agnostic; it can work in many environments that Secure Boot cannot. Secure Boot also doesn't get us nifty features like tamper-evident logging or hardware root-of-trust.
Edit: See [0] where Titan was first briefly introduced earlier this year, for an image of it attached to one of our custom networking cards.
Great question. We are working on it. LOAS is about server or device credentials that only will be issued if Titan will pass the validation of bios firmware.
When asked about releasing a paper a few months ago at Next, it didn't sound like a high priority, maybe because it wasn't too exciting or not too many people would be interested. I disagree, but perhaps, if enough people ask Niels or whoever else makes the call, something might happen.
> Once Titan has booted its own firmware in a secure fashion, it will turn its attention to the host’s boot firmware flash, and verify its contents using public key cryptography. Titan can gate PCH/BMC access to the boot firmware flash until after it has verified the flash content, at which point it signals readiness to release the rest of the machine from reset
Can I serve a different firmware image after the verification goes through and the PCH starts loading the flash? :)
If the flash chip holding the boot firmware isn't really a flash chip, then indeed this could present an issue. However, since Titan interposes between flash and the PCH/BMC, it can observe the bytes actually being served.
Titan is just one of several measures we take to harden our stack, and helps us be confident in the software we run. It's a good point though, there are no absolutes in security.
"Neither Amazon.com nor Microsoft - which hold 41 percent and 13 percent of cloud market share, respectively, according to Synergy Research Group - have said if they have similar features."
We've actually got Titan earring swag we'll hopefully start distributing at upcoming recruiting / customer events, so images may start cropping up in short order.
Hey there, I am one of the authors behind this blog. How about we will share our Titan earrings swag instead for your close examination? We fixed captions on the blog, thanks for pointing it out.
I've heard about this chip, but I still don't get what specific scenarios it's designed to prevent compared to "traditional" secure boot. The article lists a lot of things Titan does without going into what practical benefits all of those features offer compared to the current industry practices.
A couple practical benefits of Titan is that we can use it in many different environments where traditional secure boot is not available. For example, we're using it in both servers and in our custom networking card.
In addition, traditional secure boot doesn't give us a hardware root of trust, nor does it enable tamper-evident logging.
Titan is not a protection against National Security Letters, it's a protection against hacking. NSA, China, and Russia have all successfully hacked Google or Google accounts in the past.
National Security Letters can be challenged in court. You fight legal attacks with legal defenses. You fight technical attacks with technical defenses. Although swapping them does give rise to some interesting techniques. Legally challenging technical attacks can be tricky due to jurisdiction, but it would be cool if Google could at least try suing the countries that attacked them. Technical defenses against legal attacks can also sometimes work, by building systems where the company themselves don't have access, such as E2E crypto.
News like this make me sad. google is becoming a government agency-like customised fortress from the cold war, and general computing gets phased out, just like Cory Doctorow said.[^1]
Technologically, it's fantastic, but I do not welcome the philosophy it's bringing.
I agree with Doctorow that it is a problem if I the consumer am prevented from making my computer do what I want by secure boot.
But Titan doesn't really have that problem. Google owns the computers, and Google can make the computers do what they want because they have the signing keys.
If Titan-controlled devices were sold to consumers with no way to disable it, that would be a problem.
"...Titan cryptographically associates the log messages with successive values of a secure monotonic counter maintained by Titan, and signs these associations with its private key. This binding of log messages with secure monotonic counter values ensures that audit logs cannot be altered or deleted without detection, even by insiders with root access to the relevant machine."