Facebook Acquires Server-Focused Security Startup 18
wiredmikey writes In a move to bolster the security of its massive global server network, Facebook announced on Thursday it was acquiring PrivateCore, a Palo Alto, California-based cybersecurity startup. PrivateCore describes that its vCage software transparently secures data in use with full memory encryption for any application, any data, anywhere on standard x86 servers. "I'm really excited that Facebook has entered into an agreement to acquire PrivateCore," Facebook security chief Joe Sullivan wrote in a post to his own Facebook page. "I believe that PrivateCore's technology and expertise will help support Facebook's mission to help make the world more open and connected, in a secure and trusted way," Sullivan said. "Over time, we plan to deploy PrivateCore's technology directly into the Facebook server stack."
Re:Just use OpenBSD. It's the sensible option. (Score:5, Insightful)
OpenBSD is security. Security is OpenBSD
If you think that choosing OpenBSD will magically produce secure setups, you are doomed.
While I acknowledge valuable security-related work in OpenBSD, a moto such as "Only two remote holes in the default install, in a heck of a long time!" is harmful PR speak. Who use an OS as in the default install, without touching any settings? Just configuring the network push you out of default install (and you win two more remotely-exploitable holes in DNS resolvers).
And we could also speak about the numerous "reliability fixes" that are often really security fixes you should install to remain secure.
Cannot spell 'hypervisor' without 'hype' (Score:1)
You can't spell 'hypervisor' without 'hype'. Before I even clicked on TFS link (sorry, /.) I knew I was going to see that this has something to do with VMWare and lo and behold:
PrivateCore was founded in 2011 by security industry veterans from the IDF, VMware and Google. In June 2014, the company raised $2.25 million in seed funding from Foundation Capital.
so you can encrypt your virtual machine... Ok, great, an extra level of encryption, but doesn't it still have to decrypt whatever it is trying to run on the processor, eventually an unencrypted instruction has to be read and executed, or do they now allow encrypted instructions to run within a virtual machine player? I don't think
Re: (Score:2)
But the funny thing is, Facebook doesn't run on virtual machines.
So I wonder what their plans are.
ARRRRRR! (Score:2)
I keep reading that as "Pirate Cove"...
Keys (Score:2)
They encrypt inside memory, but with what keys? How easily accessible are they?
The usual tradeoff here is choosing between something that can reboot unattended, but with private key easily accessible, or something that need a password to be entered on restart to decipher the private key
Re:Keys (Score:4, Interesting)
Pointless, 3rd party. (Score:1)
I believe that PrivateCore's technology and expertise will help support Facebook's mission to help make the world more open and connected, in a secure and trusted way," Sullivan said.
Pointless, unless you sell user information to third party company's that only this service.
Or is that the end goal here, make third party company's pay £££ to use PrivateCore?
Regardless, once that data is in the hands of "Marketing Company X", kind of defeats the security it had in the 1st place.
Oh and, noone is truly "connected" on facebook. Its just a phase in our current generation to feel "important", which Facebook is profiting from.
PrivateCore's product - likely the employees (Score:5, Interesting)
The goal of PrivateCore's product was to encrypt everything that's outside of the CPU core using software techniques. So once you've done an attested boot and gotten your crypto keys in order, from that point on anything outside the CPU socket is done in an encrypted manner (except I/O to the network I guess, but definitely hard disk and data going to the DRAM, etc.) Their important selling point here was that you could protect against cold boot attacks, DMA data dumps, data sniffers on the DRAM lines, etc [stanford.edu]. They also claim to have a secure hypervisor (preventing cross-VM thievery) because they've stripped it down to its bare bones, but I believe this ended up being a secondary concern.
Anyway, their goal was to have unencrypted data in the caches [stanford.edu], but encrypt the data before it leaves the chips and goes out to DRAM. Their page is mostly high-level marketing fluff, so if they were claiming to do more than this, I missed it. The hardware for encrypted DRAM accesses exists in specialized platforms (e.g. the XBox 360) but doesn't currently exist in commodity x86 server parts. As such, a friend and I sat down for an evening a while ago and tried to work out how they would do this without a DRAM controller that did the encryption for you.
Again, their goal is to have decrypted data in the caches, encrypted data in the DRAM. The crypto routines would have to be contained in software. The major difficulty is that the cache does whatever the cache wants, so it's really rather difficult to say "when this data is leaving the cache, call the software crypto routines." There is no good way for the hardware to tell you it's kicking data out of the cache. (There are academic proposals for this kind of information, but nothing currently exists.)
We thought up of a number of solutions and were able to validate our guesses against their patent submission [google.com]. I will gloss over some of the deeper details (such as methods for reverse engineering the cache's replacement policy).
The shortened version is:
1) Work on Intel cores that have >=30 MB of L3
2) Run a tiny hypervisor that fits into some small amount of memory (let's say 10MB)
3) Mark all data in the system that is not the hypervisor code pages are non-cacheable
4) The hypervisor also has the crypto routines, so all of these non-cacheable pages can now be software encrypted using the hypervisor's routines. The DRAM-resident data is now encrypted.
4a) Because these were marked as non-cacheable data, the hypervisor is still resident in the cache (it was never displaced).
5) Mark some remaining amount of space (let's say 20MB) of physical memory as cacheable. This physical memory currently contains no data at all.
6) When you want to run a program or an OS, have the hypervisor move that program's starting code into the 20-meg-range (decrypt it along the way) and set its virtual pages to point to that physical memory range
7) The program can now run because (at least some of its pages) are decrypted. They are also cacheable, so it will hit in the cache
8) When you try to access code or data that is still encrypted, it will cause a page fault
9) The hypervisor's page fault handler will get that encrypted data, decrypt it, and put it somewhere in the 20-meg-range
9a) If the 20 meg page is already full of decrypted data, you will have to re-encrypt some of it and spill it back to DRAM (like paging it out to disk).
Because you are only touching ~30 megs of physical memory that is marked as cacheable, you will "never" spill decrypted data to the DRAM. Essentially, they built a system that has 30 megs of main memory (that 30 megs is SRAM in the core), and DRAM is treated like disk/swap in a demand-paging system.
The reason I am convinced this is likely an acquisition-hire
Acquisition-hire: more proof (Score:3)
In summary: I don't believe that Facebook will be implementing this technique in their servers. If they really wanted encrypted DRAM, they would pay Intel or AMD to build a semi-custom processor [wired.com] with encryption techniques built into the DRAM controllers. They bought this company because they want to hire these guys who have a lot of kernel and hypervisor knowledge.
More proof to your hypothesis:Facebook is currently hiring kernel hackers [phoronix.com]. With a humorous "we gotta beat FreeBSD!" target, but still. BSD-jokes aside, it's another proof that they are interested in increasing kernel performance and thus people with very good low-level knowledge would be welcome, no matter these people's current product has very few practical application.
Re: (Score:2)
An other reason, as I mentioned above.
Facebook runs it's whole infrastructure on bare-metal with containers.
There are no hypervisors in use for most, if any, workload in their datacenter.