
Google reveals its servers all contain custom security silicon - chris-at
http://www.theregister.co.uk/2017/01/16/google_reveals_its_servers_all_contain_custom_security_silicon/
======
sergiosgc
This is another signal of an interesting development on the hardware front.
What used to be decoupled, with some companies offering hardware, and
different companies buying hardware, is now coupled and hidden within these
mega-companies (Google, Amazon, FB).

Google is big enough to develop a trusted hardware solution for internal use
only, it has no financial need to sell it. Worse, due to competitiveness in
the cloud segment, it is dis-incentivized from selling the solution.

Amazon Glacier is another one. It's an interesting long-term storage solution,
whose hardware implementation is unavailable to the market, since AMZN can
better explore it as a service under AWS.

We are heading onto a more closed ecosystem than we are used to up until here.
The cloud, which gave us the immense positive benefit of moving all capex to
opex, is birthing this immense negative side effect of closing off hardware
implementations in favour of exploring the added value in the form of
services.

~~~
vgt
It's a sign of changing times indeed, but for the consumer's benefit.

It is absolutely in Google's best interests to externalize security for its
customers as a differentiator of Google Cloud. The parent article itself links
to the white paper that outlines how this is done for Google Cloud.

I understand how one may consider this a "closed ecosystem" from one
perspective. However, from a customer point of view any startup or mom-and-pop
can leverage these very complex and expensive world-class security
developments, whereas in the past this access has been reserved to the very
select few that could afford it. When the barrier to entry is lowered and
access is commoditized, customer wins.

(work at Google cloud)

~~~
sergiosgc
> However, from a customer point of view any startup or mom-and-pop can
> leverage these very complex and expensive world-class security developments,
> whereas in the past this access has been reserved to the very select few
> that could afford it.

I don't expect startups or mom-and-pop's to build internal clouds. I do expect
medium to large companies to do so. The current market turns innovations such
as these into competitive advantages of Google, instead of directly exposing
the innovation to the market and allowing incorporation of its advantage into
anyone's product. It's a less liquid market. Either you buy all of Google's
solution as a package, or you buy none. You can't pick, sort and mash a
solution of your own from disparate parts.

Note that Google here is just an example. All companies of similar size in IT
are doing the same, and strategically it is the correct option (for them). I'm
just stating that the overall result is sub-optimal through a collusion of
disparate factors.

~~~
digler999
> and strategically it is the correct option (for them).

I agree. Consider what's at stake for them. I can't even begin to wrap my head
around how bad that would be if an entire server farm got rooted. At least
defending a bank you know what the attacker's endgame is: steal money/SSN's.
If a server farm were hacked, you'd see identity theft, blackmail, massive
customer (and e-commerce) downtime, malware distribution, ddos/large botnets,
market manipulation (if you started spreading false news about a particular
company, at scale, on social media), perhaps brute-force RSA/SSL cracking. If
those guys got hacked, it could be an absolute shitstorm. So I dont blame them
at all for creating their own TPM or whatever.

------
NelsonMinar
This is what security looks like when your threat model is well funded
government agencies.

~~~
dx034
Exactly, and I think it's worth noting that they likely only apply this level
of security because of state actors. Which then shows that they are trying to
prevent eavesdropping by NSA & Co., they probably just realized too late how
far advanced they were.

~~~
a_imho
_Which then shows that they are trying to prevent eavesdropping by NSA & Co._

Why would the NSA eavesdrop on Google, they are in bed with them, aren't they?

~~~
euyyn
Snowden revealed the opposite: [https://cdn.grahamcluley.com/wp-
content/uploads/2013/10/nsa-...](https://cdn.grahamcluley.com/wp-
content/uploads/2013/10/nsa-postit.jpeg) NSA actively tries to eavesdrop on
Google.

~~~
dx034
And the chips are probably the reaction to exactly that slide. Not only
enabling SSL between datacentres, but verifying all code that servers run, to
avoid that the NSA can download private keys from Google servers just because
they handed an ESL to the datacentre operator.

Of course they can still use courts to get data directly from Google, but that
way they can always only target individuals or small groups, not whole
nations.

------
foobiekr
The actual document - [https://cloud.google.com/security/security-
design/](https://cloud.google.com/security/security-design/) \- was linked
previously.

It is interesting that they are doing some variant of trusted computing mostly
because their homogeneity would allow Google to build a robust containment
architecture with much more rigorous whitelisting and a robust SW distribution
rules that go beyond what a measuring host and local SW bundle verification
can do. So defense in depth.

We (skyport systems) do the same thing as a service for enterprises (we sell
and operate cloud-managed trusted systems as a service) and I will say it's
pretty hard to get people to think about depth and trustworthiness when the
entire security industry has trained CIOs to believe that all they need to do
is install some random agent on their VMs.

Good for Google.

------
tlb
"Before a decommissioned encrypted storage device can physically leave our
custody, it is cleaned using a multi-step process that includes two
independent verifications. Devices that do not pass this wiping procedure are
physically destroyed (e.g. shredded) on-premise"

Why not just shred all decommissioned disks? Someone must be buying them for
enough money that Google created a multi-step process for cleaning and
verifying them. Presumably Google keeps disks in commission until they're no
longer economic in their own operation.

So, does anyone know about the operation that makes profitable use of disks
that are no longer economic for Google?

~~~
phire
Probably because of the verification.

You can't really verify a shredding, the pile of shredded remains no-longer
has a serial number. I assume the cleaning process cryptographically verifies
the identify of the disk both before and after the wipe, making it impossible
to sneak a drive out.

For those drives which fail the cleaning process, they probably have a complex
process with multiple witnesses to ensure it actually gets shredded.

------
woliveirajr
> Disks get the following treatment:

> “We enable hardware encryption support in our hard drives and SSDs and
> meticulously track each drive through its lifecycle. Before a decommissioned
> encrypted storage device can physically leave our custody, it is cleaned
> using a multi-step process that includes two independent verifications.
> Devices that do not pass this wiping procedure are physically destroyed
> (e.g. shredded) on-premise.”

Interesting. There were discussions on the past on how to clean HDD, if
multiple-passes were really necessary or not.

Then SDD become the problem, since there is a interface between what you see
(from the OS) and where the data really is (inside those chips). Now Google
not only encrypts data before saving (that should be enough, no?) but also
tries to wipe using multiple passes and 2 verifications.

Wonder how many companies do that.

~~~
problems
If you use on-board crypto on most SSDs, there's a dedicated place for key
storage and using the SSD's onboard wipe feature just changes the key and
TRIMs the whole drive.

Most of these drives use cryptographic keys even if you don't use a password
on the device. Think about it as an SSD manufacturer - what's the easiest way
to wipe a drive? To actually go and zero out every cell on the disk or to
overwrite a very small cryptographic key with a new one - effectively
destroying the data without the need for any other write cycles to occur.

Pretty easy to verify - if you have an SSD with support for this, which most
do now.

~~~
throwawayish
> Think about it as an SSD manufacturer - what's the easiest way to wipe a
> drive?

That's not the reason why encryption is always on. Flash endurance is;
encrypting the data before FEC means that it will have a random distribution,
which avoids pathological worst cases with certain workloads. You _could_ also
use a different (cheaper) scrambler than AES (like CPUs do [1]), but since
encryption is a marketable feature...

[1] Which are _also_ switching to using AES and offering memory encryption in
current mainstream architectures.

~~~
problems
Ah, interesting. That's really cool. I guess it makes things easier for them
and better for their customers in several ways at once.

------
DanielDent
A lot of stuff from this made it's way into the chromebook. There's a verified
boot process, hardware assisted key management, rollback protection, ...

And it's all open source and nicely documented for anyone who cares to look.
With a bit of work you can actually create your own chain of trust and run
your own verified boot process.

It's very cool.

~~~
knowaveragejoe
What is this called? I'd like to look into it, but cursory searching is giving
me more vague results.

------
amelius
But if they don't own an IC fab, how do they know it is secure?

~~~
swegg
Basically splitting the trusted circuit and testing the parts separately. This
requires a trusted master circuit, but it can be arbitrarily small.

See
[https://perso.uclouvain.be/fstandae/PUBLIS/177.pdf](https://perso.uclouvain.be/fstandae/PUBLIS/177.pdf)

~~~
amelius
But what if the malicious code is time activated? (just an example)

~~~
swegg
This is actually addressed in the paper. Basically you can use testing to
detect the timebomb, up to a negligible probability.

This paper is approachable, it's understandable without too much background if
you're interested in the topic.

------
bogomipz
I was curious about this:

>"There's plenty more in the document, like news that Google's public cloud
runs virtual machines in a custom version of the KVM hypervisor."

Does anyone know if this "container inside kvm" is true of their internal
infrastructure as well or its just an extra layer of security for their public
facing cloud?

~~~
wmf
Internal Google stuff does not use KVM and that's one reason it took them a
while to offer VMs — they had little experience with it.

~~~
bogomipz
Do you or anyone else know if there is another reason for doing this besides
security?

~~~
wmf
I can't speak for Google, but there are several reasons. Docker and k8s are
not multitenant, so if you want to build a public k8s cloud you need a tenant
layer under it. That layer could also be containers (e.g. LXD), but then
you're talking about secure nested containers which was not really available
in November 2014.

~~~
bogomipz
Oh good insight. That makes a lot of sense. Thanks.

------
Duobix
I barely dug into the article when It came to me: Google just did a lockout
chip, 1980s Nintendo style.

~~~
na85
I suppose if you're looking for a sound bite, yes.

But whereas Nintendo's chip was DRM, this Google chip appears to be more about
determinism in boots and server provisioning, allowing them to immediately cut
out a server that appears malicious or that has been compromised.

I.e. pry open case to insert an implant, chip notices bios has been altered,
sends the "don't trust me" message to the network.

~~~
digi_owl
Makes me think of Intel's IME. It has legitimate uses on corporate desktops
and servers. But when it makes its way to consumer desktops it runs face first
into a massive conflict of interest.

~~~
kabdib
IME's huge problem is its shroud of secrecy. The CPU can do just about
anything on the bus, it has access to external ports, and the code it runs is
encrypted.

From the viewpoint of a government agency, that's a tremendous surveillance
enabler. It's really hard to imagine it's not been compromised.

------
gerbilly
Still it doesn't make me want to use their services.

They may indeed be really good at securing their data but 'their data'
ironically is derived from my emails and browsing history and that of my
friends.

