Re: [Qemu-devel] QEMU as a "virtual smart card"?

["Bud P. Bruegger" <bruegger@ancitel.it>]

On Wed, 2 Sep 2009 17:58:18 +0300
Blue Swirl <blauwirbel@gmail.com> wrote:

> On Wed, Sep 2, 2009 at 2:47 AM, Jamie Lokier<jamie@shareable.org>
> wrote:
> > Bud P. Bruegger wrote:
> >> At least looking naively at QEMU, it seems that its CPU and RAM are
> >> well protected from the host operating system--in a way to say
> >> make it practically impossible for some malware to extract the
> >> secret key used in a virtual machine.
> >
> > No, the CPU and RAM state inside QEMU is easily read from the host.
> > Just run a debugger and attach to the running QEMU process.  It's
> > not completely simple, but it's far from secure.
> 
> For additional complexity, the CPU registers, memory, instruction set
> and I/O could be encrypted but there is still a problem: where to
> store the keys. The keys could be handled by another host process,
> which could also try to attest that no debugger is attached (at least
> on that level of virtualization). Performance would suck of course and
> the attestation process could be fooled.

First of all thanks to everyone for the replies and advice.  

As for encryption of RAM and processor, wouldn't it be necessary to
decrypt things before using it and that would be visible to the
observer on the host machine?

While surely not bullet proof and impossible to crack, I thought that
there may be other ways of rising the hurdle quite a bit.  

Assume that I wanted to protect a secret algorithm in some C program.
Normally this is compiled into the machine code of a certain processor
and there are standard tools (disassembler, debugger) that can be used
to figure out what the secret algorithm does.  

A virtual machine has a virtual processor.  Assume now that I was to
shuffle around machine instructions both in the processor of the
virtual machine and in the back-end of my c-compiler.  I imagine that
it would be possible to automate this process (some refactoring tool?)
and to do some random shuffling.

At this point, I guess before looking at the code I'd have to create my
own tools (disassembler, debugger) before even starting to look at what
is happening.  

So maybe there would even be some more room to generate a "random
virtual processor" together with a "random C compiler".  Kind of like
generating a key pair :-)

That would still leave RAM unprotected, I guess...  But maybe there
could be a way of adding some "random" RAM/CPU combination with enough
entropy..

do you think that is a valid idea?

best cheers
-b