4 ms·

We're working on a similar problem at PrivateCore: Protecting VM data in-use on outsourced infrastructure. We're running a high-assurance, remotely attestable

by sweis 13y ago

We're working on a similar problem at PrivateCore: Protecting VM data in-use on outsourced infrastructure. We're running a high-assurance, remotely attestable hypervisor inside the CPU cache and encrypting all access to main memory. This protects against threats from the physical layer, like cold boot, DMA attacks, NVDIMMs, bus analyzers, etc. It's not quite what you're talking about in your Amazon and NSA scenario. Amazon doesn't let you bring your own hypervisor to run on bare metal and the NSA can compromise the CPU itself. However, our approach does give you assurance that someone with physical access can't easily snapshot your VM memory.

derefr 13y ago
> remotely attestable hypervisor How does this bit work, by the way? What's stopping an altered hypervisor from lying to say it's unaltered? (This is the classic "how do you verify a player on your FPS isn't running a bot instead of a game-client" problem in a nutshell.)
- sweis 13y ago
  Today we rely on the TPM to measure the state of the system using Intel TXT. These measurements are stored in platform configuration registers (PCRs) on the TPM device. There are known TPM and LPC bus vulnerabilities. That is why long-term we will move away from that dependency by utilizing upcoming CPU features.
e12e 13y ago
> our approach does give you assurance that someone with physical access can't easily snapshot your VM memory. But how do you know the VM (or rather the hypervisor for the vm) is running on physical hardware, and not in a hypervisor? I can't think of a way you could be certain of this remotely? Perhaps you could be on-site for the boot-up, and then rely on the fact that snapshotting is very hard -- but it sounds rather fragile... Still very interesting project! I've been thinking a bit on "running inside the L/1/2/3 chache"-lately - but I hadn't thought about the particular idea that you could treat RAM as "external" -- assuming you could guarantee that you're always in cache.
- sweis 13y ago
  You must first remotely attest the hypervisor using TXT before deploying a VM to run on it. Today, that attestation process relies on a TPM and a signed certificate chain baked in by the TPM manufacturer. This is standard stuff out of the Trusted Computing Group. One more thing to add, this isn't just a personal side project. We're a company and have a beta product deployed to early adopters.
  - e12e 13y ago
    I realized that you probably did have a product -- unfortunately that doesn't mean that the product works (not trying to imply anything about your product/company here; it's just (as you probably know) there many companies selling security solutions; and very few that seem to be selling security solutions that work...). Are you aware of: "Overcoming TPM by exploiting EFI overflow" http://www.youtube.com/watch?v=4bM3Gut1hIk&feature=player_detailpage&t=1655 and: "Coreboot/bios malware": http://www.youtube.com/watch?v=umBruM-wFUw&feature=player_detailpage&t=2297 It's an interesting use of TPM -- and sounds like a sound approach, assuming there aren't any bugs in the TPM software... which might be too big an assumption. I don't suppose any of your software is available as open source? Where can I/we learn more?
    - tptacek 13y ago
      I don't know anything about his product but let me just chime in here to say that Steve Weis is the real deal.
    - sweis 13y ago
      Hi. We're aware of TPM vulnerabilities. The one you link to is not relevant. However, there are attacks to extract EK private keys, which we know the cost of conducting. It's significantly higher than other low-cost attacks. We're also aware of vulnerabilities on the the LPC bus. The latter can be addressed with existing TPM 1.2 features -- although they aren't enabled by default. There are CPU features in the pipeline which may make the TPM unnecessary. We're also working on some new attestation techniques which may help. We measure and attest the state of the system with TXT. If that works as advertised, you would measure changes to the BIOS, SINIT, opt ROMs, ACM modules, etc.

by sweis 13y ago

derefr 13y ago

> remotely attestable hypervisor How does this bit work, by the way? What's stopping an altered hypervisor from lying to say it's unaltered? (This is the classic "how do you verify a player on your FPS isn't running a bot instead of a game-client" problem in a nutshell.)

sweis 13y ago
Today we rely on the TPM to measure the state of the system using Intel TXT. These measurements are stored in platform configuration registers (PCRs) on the TPM device. There are known TPM and LPC bus vulnerabilities. That is why long-term we will move away from that dependency by utilizing upcoming CPU features.

e12e 13y ago

> our approach does give you assurance that someone with physical access can't easily snapshot your VM memory. But how do you know the VM (or rather the hypervisor for the vm) is running on physical hardware, and not in a hypervisor? I can't think of a way you could be certain of this remotely? Perhaps you could be on-site for the boot-up, and then rely on the fact that snapshotting is very hard -- but it sounds rather fragile... Still very interesting project! I've been thinking a bit on "running inside the L/1/2/3 chache"-lately - but I hadn't thought about the particular idea that you could treat RAM as "external" -- assuming you could guarantee that you're always in cache.

sweis 13y ago
You must first remotely attest the hypervisor using TXT before deploying a VM to run on it. Today, that attestation process relies on a TPM and a signed certificate chain baked in by the TPM manufacturer. This is standard stuff out of the Trusted Computing Group. One more thing to add, this isn't just a personal side project. We're a company and have a beta product deployed to early adopters.
- e12e 13y ago
  I realized that you probably did have a product -- unfortunately that doesn't mean that the product works (not trying to imply anything about your product/company here; it's just (as you probably know) there many companies selling security solutions; and very few that seem to be selling security solutions that work...). Are you aware of: "Overcoming TPM by exploiting EFI overflow" http://www.youtube.com/watch?v=4bM3Gut1hIk&feature=player_detailpage&t=1655 and: "Coreboot/bios malware": http://www.youtube.com/watch?v=umBruM-wFUw&feature=player_detailpage&t=2297 It's an interesting use of TPM -- and sounds like a sound approach, assuming there aren't any bugs in the TPM software... which might be too big an assumption. I don't suppose any of your software is available as open source? Where can I/we learn more?
  - tptacek 13y ago
    I don't know anything about his product but let me just chime in here to say that Steve Weis is the real deal.
  - sweis 13y ago
    Hi. We're aware of TPM vulnerabilities. The one you link to is not relevant. However, there are attacks to extract EK private keys, which we know the cost of conducting. It's significantly higher than other low-cost attacks. We're also aware of vulnerabilities on the the LPC bus. The latter can be addressed with existing TPM 1.2 features -- although they aren't enabled by default. There are CPU features in the pipeline which may make the TPM unnecessary. We're also working on some new attestation techniques which may help. We measure and attest the state of the system with TXT. If that works as advertised, you would measure changes to the BIOS, SINIT, opt ROMs, ACM modules, etc.