Cambridge boffins and Google unveil open-source OpenTitan chip – because you never know who you can trust OpenTitan – an open-source blueprint for a Root of Trust (RoT) system-on-chip based on RISC-V and managed by a team in Cambridge, UK – was teased by Google along with several partners today. Hardware RoT is a means of verifying the firmware and system software in a computing device has not been tampered with, enabling features …
Trustworthy hardware is in Google's own best interest. From their point of view, this is a way of neutralising the inbuilt advantage that Microsoft and Apple have from being literally in control of the hardware.
It leaves them all with no alternative but to compete for data, on level terms, in the online world - i.e. Google's home turf.
The problem with all of this Root of Trust stuff is that the most likely application will be to lock you out of your own device.
This may well be spun as being in the interests of "security", but in reality it will be to prevent users bypassing a lucrative monthly service charge or unbricking their devices when the supplier loses interest in supporting them.
Who, you might wonder, has the greatest interest in preventing you removing, say, egregious data slurping over which you have no control? And, indeed, who is the world's largest supplier of abandonware?
"the most likely application will be to lock you out of your own device"
Except that, as I can tell, the whole point of this project is that it is open so you (or 3rd parties that you trust) can independently verify that you can't be locked out of your own device at anyone's whim
or 3rd parties that you trust
The assumption behind RoT is that there are the criminal hackers and the "good guys" and it's simply a matter of separating goats from sheep. The proponents of this model, such as Microsoft, Google and Apple, work from the starting point that they are unquestionably the good guys and anyone attempting to thwart their plans is by definition a malefactor.
From the point of view of the consumer, all of these parties in fact offer a similar level of threat.
It's not a question of who you should trust, but who you may choose to trust on a single occasion for a single purpose. That is simply not facilitated by a model in which the control of a device that protects "secrets like encryption keys in a tamper-resistant way even for people with physical access" is in the hands of the key holder.
It may work for a large organisation whose products are exposed to the Internet and whose employees cannot necessarily be trusted, but the best protection for the end user is a physical switch labelled "mine" and "yours".
Google's application for this is to ensure that their servers are running the software they want them to run, not malware written by state-level attackers. This is a very good thing.
Google open-sourcing it will allow other cloud vendors to use it, which is a good thing. Note that the other cloud vendors will each have their own root of trust for their own servers.
It may also allow companies to use it. Although companies are likely to blindly trust their server manufacturer's root of trust used to sign the firmware from their server manufacturer, and the OS vendor's certificate used to sign the OS image from their OS vendor (MS, Red Hat, Ubuntu, etc), it still provides a much better level of assurance than they had before. This is a good thing.
This chip is unlikely to be used in many consumer devices. Because it's there to protect attacks against the motherboard firmware, and on a locked-down device it's awkward enough to change the firmware that it's not worth worrying about. Unless the attacker knows of a bug, changing the firmware requires connecting wires to the flash chip on the PCB, which is beyond the abilities of most people. The OpenTitan chip would provide protection against state-level attackers who have discovered suitable bugs, and want to write their malware to the firmware. However, it's an extra chip and more PCB space, which has a cost, and consumer device and IoT manufacturers will not want to pay extra for security.
"Secure boot", where end users can choose the CA they trust, is a really good idea that improves security against boot-time rootkits.
"Secure boot", where the hardware manufacturer chooses to only trust the Microsoft CA, and users can't add other CAs, is a really bad idea that locks in a Microsoft monopoly.
The thing to worry about is "who chooses which CAs to trust", not secure boot itself. And since this particular project is open-source, I don't think that's going to be a problem.
"The thing to worry about is "who chooses which CAs to trust", not secure boot itself."
True, if by "CA" you mean root cert. I don't actually trust any commercial CAs, and any cert I'd want to use for boot would be one that has been signed by the CA I personally run.
But I agree, if we can't use our own certs, this is a terrible thing -- but the secure boot installations that have come before haven't allowed for this, so I don't see why we can expect any differently moving forward. This is why being able to disable secure boot is one of my nonnegotiable requirements when buying a system.
I don't see how the implementation being open source affects this issue. Can you explain?
We are missing words like "cloud", "ai", and "blockchain". You can't possibly win a buzzword bingo without those words.
Also words like "leverage", which could have been leveraged into the announcement very easily.
"Growth" seems to be missing, and there is no "foundation".
We've got "partners", which is good; and "centric". And "diverse", which is very good. I love diversity.
But overall, it is a 4/10 could do better.
The way it's described, it sounds like a glorified Trusted Platform Module for smartphones.
That said, this could very well be used to prevent users from rooting their device and thereby preventing Google and other companies from tracking them (built-in or otherwise) through hosts file editing or modification.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
