prevent unauthorized physical access to data in use?

[adrelanos]

Hi!

For servers (in the cloud) it would be quite useful, if there was some
way to prevent attackers with physical access to read data, i.e. to make
the hardware somehow untrusted.

Is this conceptually possible?

I found a product which claims this.

> PrivateCore vCage [1] is the first hypervisor to transparently protect
any virtual machine while in use on commodity x86 servers. By encrypting
data during program execution, vCage’s software-only full-memory
encryption protects data from unauthorized physical access and malicious
hardware devices. vCage bridges the gap between data at rest and data in
transit protection, making it safe to run any virtual machine, anywhere
and on demand.

A part form some PR messages, I didn't find any discussions about this
product. Do you know how it works? Is it snake oil or a legitimate concept?

Could you do something similar with Qubes OS?

Cheers,
adrelanos

[1] http://privatecore.com/vcage/

[Joanna Rutkowska]

On 05/07/13 14:26, adrelanos wrote:
> Hi!
>
> For servers (in the cloud) it would be quite useful, if there was some
> way to prevent attackers with physical access to read data, i.e. to make
> the hardware somehow untrusted.
>
> Is this conceptually possible?
>
> I found a product which claims this.
>
>> PrivateCore vCage [1] is the first hypervisor to transparently protect
> any virtual machine while in use on commodity x86 servers. By encrypting

> data during program execution, vCage=92s software-only full-memory

> encryption protects data from unauthorized physical access and malicious
> hardware devices. vCage bridges the gap between data at rest and data in
> transit protection, making it safe to run any virtual machine, anywhere
> and on demand.
>
> A part form some PR messages, I didn't find any discussions about this
> product. Do you know how it works? Is it snake oil or a legitimate concept?
>
> Could you do something similar with Qubes OS?
>
> Cheers,
> adrelanos
>
> [1] http://privatecore.com/vcage/
>

AFAIU this is an extension of one of the idea described in this post:

http://theinvisiblethings.blogspot.com.au/2011/12/trusted-execution-in-untrusted-cloud.html

... by implementing the DRAM encryption in the hypervisor (instead of b
the CPU).

AFAIU this all makes any sense only if their hypervisor sources gets
published together with the resulting binaries, so that Remote
Attestation could make any sense (we need to put some meaning to the PCR
values that RA returns).

Another thing is that we need a secure trusted boot for this (Intel
TXT), which, AFAIU, we still don't... Anybody saw an STM in practice? Is
Intel STM Writing Guide spec finally public? I will be happy to comment
on it once it becomes public...

In any case, this is a very interesting project. But Qubes OS is a
different project, and has different goals (it's a desktop platform, not
server), and so we don't plan to include such hypervisor anytime soon.
Although, theoretically, thanks to our new Qubes Odyssey architecture,
we should be able to do that easily, if such hypervisor was publicly
available.

joanna.

[inf...@gmail.com]

On 07/05/13 16:07, Joanna Rutkowska wrote:

...

AFAIU this is an extension of one of the idea described in this post:

http://theinvisiblethings.blogspot.com.au/2011/12/trusted-execution-in-untrusted-cloud.html

"In practice this comes down to also trusting the US government :)"

...
In any case, this is a very interesting project.

This is a really interesting idea, but a Three Letter Agency is a pretty hard adversary, even for TPMs, and even if there is no co-operation from the Cloud provider (or CPU mfr)

Apropos, some people might be interested in the legal/policy report mentioned in this news story. It points out that because of an unnoticed addition of three words ("remote computing services") in a 2008 law, US Cloud companies can be compelled to install secret permanent facilitates for mass-surveillance inside the datacentre (in hardware and/or the software fabric). Previous such US laws for continuous surveillance only affected telcos/ISPs (of course PATRIOT s.215 can also be used to get at defined chunks of data)

CB

[Joanna Rutkowska]

On 05/07/13 17:26, inf...@gmail.com wrote:
> On 07/05/13 16:07, Joanna Rutkowska wrote:
>> ...
>> AFAIU this is an extension of one of the idea described in this post:
>>
>> http://theinvisiblethings.blogspot.com.au/2011/12/trusted-execution-in-untrusted-cloud.html
>>
>
> "In practice this comes down to also trusting the US government :)"
>
>> ...
>> In any case, this is a very interesting project.
>
> This is a really interesting idea, but a Three Letter Agency is a pretty
> hard adversary, even for TPMs, and even if there is no co-operation from
> the Cloud provider (or CPU mfr)
>
> Apropos, some people might be interested in the legal/policy report

> mentioned in this <http://www.bbc.co.uk/news/technology-21263321> news

> story. It points out that because of an unnoticed addition of three
> words ("remote computing services") in a 2008 law, US Cloud companies
> can be compelled to install secret permanent facilitates for

> mass-surveillance *inside* the datacentre (in hardware and/or the
> software fabric). Previous such US laws for *continuous* surveillance

> only affected telcos/ISPs (of course PATRIOT s.215 can also be used to
> get at defined chunks of data)
>

Generally, for any OS or computing platform, there remain at least thing
we always need to trust. This is the CPU. So, before we can have open
source, 3D-printed, DIY processors, we will always need to trust the US
government (or any other government where the processor design and
manufacturing is to be conducted).

<digression>
This, of course, brings a question of what processors should be used in
those first 3D printers that will create the first open source
processors? As well as on the desktop computers which will be used for
creation and review of the design? Can they be trusted not to introduce
backdoors into the printed processors?

In practice I think creation of such backdoors would be Very Difficult,
so I personally wouldn't loose much sleep about that possibility. But
theoretically it's an interesting problem of how the mankind cannot
really never(?) fully escape from the trap of proprietary software
hardware...
</>

More on CPU backdoors (if one wants to waste more time on unsolvable
problems, rather doing something useful, such as contributing to the
Qubes OS ;):

http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html

joanna.

[Joanna Rutkowska]

On 05/08/13 01:32, adre...@gmail.com wrote:
> On Tuesday, May 7, 2013 3:38:33 PM UTC, joanna wrote:

> How do we get open source hardware backdoor free 3D-printers in the first
> place?

>
>
>> <digression>
>> This, of course, brings a question of what processors should be used in
>> those first 3D printers that will create the first open source
>> processors? As well as on the desktop computers which will be used for
>> creation and review of the design? Can they be trusted not to introduce
>> backdoors into the printed processors?
>>
>> In practice I think creation of such backdoors would be Very Difficult,
>> so I personally wouldn't loose much sleep about that possibility. But
>> theoretically it's an interesting problem of how the mankind cannot
>> really never(?) fully escape from the trap of proprietary software
>> hardware...
>> </>
>>
>> More on CPU backdoors (if one wants to waste more time on unsolvable
>> problems, rather doing something useful, such as contributing to the
>> Qubes OS ;):
>>
>>
>> http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html
>>
>>

> Maybe not unsolvable in theory? It could be solved using "trusting trust"?
>
> http://cm.bell-labs.com/who/ken/trust.html
>
> "trusting trust"... That's the theory how to get a backdoor free compiler.

Really? How?

> Do we even have trusted compilers yet? Did ever someone very our open
> source compilers are backdoor free?
>

Probably not. But compiler, theoretically at least, you can write
yourself, in machine code (although this begs a question of do we have a
trusted editor? :P). A processor we cannot make ourselves (yet).

j.

[adrelanos]

Joanna Rutkowska:

>> "trusting trust"... That's the theory how to get a backdoor free compiler.
>
> Really? How?

I think that's best explained in this blog post:
https://www.schneier.com/blog/archives/2006/01/countering_trus.html

[inf...@gmail.com]

Thank you very much for this reference
(BTW http://www.dwheeler.com/trusting-trust/ mentions application to 3D
printing at bottom)

CB

[Joanna Rutkowska]

Processor is not a compiler, so I don't really see how the trick
presented by David Wheeler could be used to figure out if we have a
backdoored processor?

But, of course, Wheeler's technique is very brilliant in that how it not
requires the two compilers used in the experiment to produces the same
output for a given input (very real assumption, of course).

joanna.

[cprise]

On 5/7/13 11:38 AM, Joanna Rutkowska wrote:

Generally, for any OS or computing platform, there remain at least thing
we always need to trust. This is the CPU. So, before we can have open
source, 3D-printed, DIY processors, we will always need to trust the US
government (or any other government where the processor design and
manufacturing is to be conducted).

Israel and India are other countries where Intel designs and manufactures its processors. I'm not sure about AMD.

Where IC printers are concerned, I think there is substantially less risk of foul play. There are too many possible permutations of physical design for malware to be able to compromise the IC without side-effects and outright malfunctions in a significant number of cases. At that point, you have technically astute users motivated to communicate and uncover the cause of the odd behavior. And let us not assume that IC printers will be capable of producing details so small they cannot be effectively examined by the operators with microscopes; Even if the IC is 3D, it can be examined as each layer is printed.

Conventionally manufactured chips are a much bigger potential problem: They are the essence of the 'black box', and just having an inside track on their unintended quirks could be used to compromise systems.

In practice I think creation of such backdoors would be Very Difficult,
so I personally wouldn't loose much sleep about that possibility. But
theoretically it's an interesting problem of how the mankind cannot
really never(?) fully escape from the trap of proprietary software
hardware...
</>

It wouldn't be difficult at all for a conventional manufacturer to put backdoors into a CPU or something like iAMT. It only needs to be a simple entry point into the system. It doesn't have to carry around any comprehensive code supporting state or criminal operations. And it doesn't have to be used for any significant amount of time (if ever) to be effective... even if its just one of those contingencies that help ruthless people sleep at night.

OTOH, I believe there are practical ways of addressing the OP's question if we assume the chips are OK or at least not a primary threat. Such measures wouldn't have to be perfect to provide some mitigation. Perhaps something like TRESOR in combination with having most RAM dedicated to encrypted swap.

[adrelanos]

Joanna Rutkowska:

> On 05/10/13 17:43, adrelanos wrote:
>> Joanna Rutkowska:
>>>> "trusting trust"... That's the theory how to get a backdoor free compiler.
>>>
>>> Really? How?
>>
>> I think that's best explained in this blog post:
>> https://www.schneier.com/blog/archives/2006/01/countering_trus.html
>>
>
> Processor is not a compiler, so I don't really see how the trick
> presented by David Wheeler could be used to figure out if we have a
> backdoored processor?

Well, if you don't see it, I must have seen a connection where isn't
one. My idea was: you use once process A which might have a backdoor to
produce output X, then use processor B, which might have a different
backdoor but not the same backdoor and create output Y. Then compare
output X and Y. If it matches, everything is fine.

But you're right, after reading your blog post, they could send an
activation sequence first. So I was wrong.

> But, of course, Wheeler's technique is very brilliant in that how it not
> requires the two compilers used in the experiment to produces the same
> output for a given input (very real assumption, of course).

I believe this is sarcasm?

g++ and microsoft cl.exe most likely produce very different output.
Maybe wheeler suggested using less popular, less complex and more simple
compilers? And it's not limited to C. If there are many simple compilers
which can produce machine code able to run on real hardware, that could
do the trick to get an initial most-likely backdoor free environment.

[Joanna Rutkowska]

On 05/23/13 18:35, adrelanos wrote:
> Joanna Rutkowska:
>> On 05/10/13 17:43, adrelanos wrote:
>>> Joanna Rutkowska:
>>>>> "trusting trust"... That's the theory how to get a backdoor free compiler.
>>>>
>>>> Really? How?
>>>
>>> I think that's best explained in this blog post:
>>> https://www.schneier.com/blog/archives/2006/01/countering_trus.html
>>>
>>
>> Processor is not a compiler, so I don't really see how the trick
>> presented by David Wheeler could be used to figure out if we have a
>> backdoored processor?
>
> Well, if you don't see it, I must have seen a connection where isn't
> one. My idea was: you use once process A which might have a backdoor to
> produce output X, then use processor B, which might have a different
> backdoor but not the same backdoor and create output Y. Then compare
> output X and Y. If it matches, everything is fine.
>
> But you're right, after reading your blog post, they could send an
> activation sequence first. So I was wrong.
>
>> But, of course, Wheeler's technique is very brilliant in that how it not
>> requires the two compilers used in the experiment to produces the same
>> output for a given input (very real assumption, of course).
>
> I believe this is sarcasm?
>

No, it's not.

> g++ and microsoft cl.exe most likely produce very different output.
> Maybe wheeler suggested using less popular, less complex and more simple
> compilers? And it's not limited to C. If there are many simple compilers
> which can produce machine code able to run on real hardware, that could
> do the trick to get an initial most-likely backdoor free environment.
>

I think you misunderstood my statement above. Please re-read and observe
the "not" in "how it not requires"...

joanna.

[Joanna Rutkowska]

On 05/23/13 18:35, adrelanos wrote:

> Joanna Rutkowska:
>> > On 05/10/13 17:43, adrelanos wrote:
>>> >> Joanna Rutkowska:
>>>>> >>>> "trusting trust"... That's the theory how to get a backdoor free compiler.
>>>> >>>
>>>> >>> Really? How?
>>> >>
>>> >> I think that's best explained in this blog post:
>>> >> https://www.schneier.com/blog/archives/2006/01/countering_trus.html
>>> >>
>> >
>> > Processor is not a compiler, so I don't really see how the trick
>> > presented by David Wheeler could be used to figure out if we have a
>> > backdoored processor?
> Well, if you don't see it, I must have seen a connection where isn't
> one. My idea was: you use once process A which might have a backdoor to
> produce output X, then use processor B, which might have a different
> backdoor but not the same backdoor and create output Y. Then compare
> output X and Y. If it matches, everything is fine.

The point is: processors are not, these days, are not used to "produce
output" anymore. They are used to _run_ programs. And what is the
"output" of running Windows 7? We don't live in a batch-processing world
anymore.

joanna.