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

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

[Bud P. Bruegger]

Hello everyone,

we are thinking of a possibly "exotic" use of QEMU and would like to
ask your advice on whether we are going in the right direction.

We are pondering of how to use a virtual machine to have some security
features normally associated with hard tokens such as smart cards.  

In particular, one of the key concepts of smart cards is that they can
store secret keys that never leave the device but can only be used by a
trusted and protected internal CPU for encryption/signing.  

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.  

Is this a valid conception of what QEMU does?  How good is the
isolation of a virtual machine from the host operating system.  

We are also interested in the isolation of input devices, in
particularly the keyboard as to prevent PIN sniffing.  My "naive"
impression is that key logging for a PS/2 keyboard is probably more
difficult than with a USB keyboard.  Is there any thruth to my
misconception?

Finally one last question questions:

* Is there any way of getting exclusive access to an USB pen drive
from a virtual machine, preventing the host operating system to say take
an image of the content?

many thanks in advance for any input and illuminations!

-bud

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

[Laurent Vivier]

Le lundi 31 août 2009 à 18:08 +0200, Bud P. Bruegger a écrit :
> Hello everyone,
> 
> we are thinking of a possibly "exotic" use of QEMU and would like to
> ask your advice on whether we are going in the right direction.
> 
> We are pondering of how to use a virtual machine to have some security
> features normally associated with hard tokens such as smart cards.  
> 
> In particular, one of the key concepts of smart cards is that they can
> store secret keys that never leave the device but can only be used by a
> trusted and protected internal CPU for encryption/signing.  
> 
> 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.  
> 
> Is this a valid conception of what QEMU does?  How good is the
> isolation of a virtual machine from the host operating system.  
> 
> We are also interested in the isolation of input devices, in
> particularly the keyboard as to prevent PIN sniffing.  My "naive"
> impression is that key logging for a PS/2 keyboard is probably more
> difficult than with a USB keyboard.  Is there any thruth to my
> misconception?
> 
> Finally one last question questions:
> 
> * Is there any way of getting exclusive access to an USB pen drive
> from a virtual machine, preventing the host operating system to say take
> an image of the content?
> 
> many thanks in advance for any input and illuminations!

In fact, you want to do that: http://www.myglobull.com/ ?

Regards,
Laurent
-- 
--------------------- laurent@vivier.eu ----------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard

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

[Jamie Lokier]

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.

> Is this a valid conception of what QEMU does?  How good is the
> isolation of a virtual machine from the host operating system.

The virtual machine is an ordinary process in the host operating
system, so it's contents can be inspected just like any other host
process using debugging tools.

The point of a VM is to make sure things on the VM cannot inspect the
host or anything else running on the host, including other VMs, except
for what it's given access to...  It doesn't isolate the other way around.

However, you can still isolate using ordinary multi-user host process
protections, so unprivileged user A cannot access user B's VMs.  VMs
are no different from other processes in this respect.

> We are also interested in the isolation of input devices, in
> particularly the keyboard as to prevent PIN sniffing.  My "naive"
> impression is that key logging for a PS/2 keyboard is probably more
> difficult than with a USB keyboard.  Is there any thruth to my
> misconception?

None.  Key logging for PS/2 is easier than USB using radio antennae or
by inspecting the protocol or by looking at system calls relaying the
data, or even by looking at kernel memory buffers.

Maybe you meant that keylogging is more difficult for USB than PS/2?

> Finally one last question questions:
> 
> * Is there any way of getting exclusive access to an USB pen drive
> from a virtual machine, preventing the host operating system to say take
> an image of the content?

Yes against casually reading it, but no against a determined hacker,
who can examine everything which happens on the virtual machine,
including all I/O, if they have access to the host and suitable
permissions to access the VM's host process.

-- Jamie

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

[Paolo Bonzini]

> 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.

I don't understand: the host operating system, by definition, can see 
everything.  A privileged process (i.e. running as root) can always look 
at /dev/mem and read info about QEMU's CPU and RAM.

> We are also interested in the isolation of input devices, in
> particularly the keyboard as to prevent PIN sniffing.  My "naive"
> impression is that key logging for a PS/2 keyboard is probably more
> difficult than with a USB keyboard.  Is there any thruth to my
> misconception?

If you mean by cracking the keyboard itself, USB keyboards have a 
firmware while PS/2 keyboards have only some glue logic, so I'd tend to 
agree.  For PS/2 you would need physical access to the cable, after 
which all hopes are off anyway.  For software attacks (i.e. in the OS) I 
don't think there is any difference.

> * Is there any way of getting exclusive access to an USB pen drive
> from a virtual machine, preventing the host operating system to say take
> an image of the content?

Again, not if the attacker can run privileged processes on the host.

Paolo

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

[François Revol]

> > 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.
>
> I don't understand: the host operating system, by definition, can see
> everything.  A privileged process (i.e. running as root) can always
> look
> at /dev/mem and read info about QEMU's CPU and RAM.

Or attach gdb and step the whole thing or put breakpoints on
ReadPassword() :)

François.

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

[Blue Swirl]

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.

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

[Bud P. Bruegger]

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

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

[Blue Swirl]

On Thu, Sep 3, 2009 at 6:09 PM, Bud P. Bruegger<bruegger@ancitel.it> wrote:
> 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?

The translator will read (decrypt) the memory one instruction at a
time, but the instructions will be thrown away. The translated code in
TBs will be plain unencrypted host machine code. Someone could even
write a decompiler to reconstruct the unencrypted instructions based
on the machine code sequences in TBs.

> 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 :-)

There's still the translated output.

> 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..

RAM could be encrypted, for example MMU (preferably TLB based) could
be enhanced to decrypt/encrypt each page with a different key. The CPU
would need to see unencrypted data, but not all of it at the same
time.

> do you think that is a valid idea?

You could validate it with something simple, like by modifying a user
emulator so that code pages massaged with XOR still execute. Or
reverse the bits in a byte, turn the memory upside down so that
address 0 is actually (unsigned long)-1, etc.

I don't think this makes any sense from guest security point of view,
it's still just obscurity.

On the other hand, there is a new benefit when considering a hostile
guest case: even if the guest could break out from the the VM, the
twisted CPU would also see the host memory in a distorted way. And if
we perform the distortion twice by running QEMU inside another twisted
VM, the guest inside would have to break from a VM twice with no idea
of what kind of machine instructions could be executed in the middle
VM. Direct bypass to the real world would still be possible, though
the guest would still need to reverse both distortions while doing any
host memory writes.

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

[Paul Brook]

> Assume that I wanted to protect a secret algorithm in some C program.

You're never going to be able to do this. At best you're going to add a few 
levels of obfuscation. At worst you're going to give yourself a false sense of 
security, while actually making it easier to defeat.

The reason the Windows DRM stuff works is because it's protected by the lowest 
level of the OS/hardware, and that protection extends up the whole software 
stack. As soon as you loose this link (e.g. by running inside a virtual 
machine, or as a userspace application without host kernel magic) then you're 
vulnerable to anyone with a copy of gdb.

The whole point of a smartcard is that it's a black box where you can't 
observe its operation at all, only its output.

> 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.

This is no different from a simple bytecoded execution engine, and fairly 
straightforward to reverse-engineer. An experienced hacker will have no 
problem writing their own reverse engineering tools to strip away your 
obfuscation. Remember that your "encryption" is still native host code, with 
any keys plainly visible.

Paul

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

[Lennart Sorensen]

On Thu, Sep 03, 2009 at 05:09:31PM +0200, Bud P. Bruegger wrote:
> 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?

Well if you look at intel's current wireless chips, they have some
firmware that runs on them, but because the instruction set of that
processor is secret and the addresses of all the devices inside the chip
are secret, it would be very hard to reverse engineer the firmware and
hence make changes to it.  Not impossible of course, but very hard.

To some extent, if you want it secret, make a custom chip, not software.
Software can't be secret, only hard to get at.

-- 
Len Sorensen

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

[Bud P. Bruegger]

> Well if you look at intel's current wireless chips, they have some
> firmware that runs on them, but because the instruction set of that
> processor is secret and the addresses of all the devices inside the
> chip are secret, it would be very hard to reverse engineer the
> firmware and hence make changes to it.  Not impossible of course, but
> very hard.
> 
> To some extent, if you want it secret, make a custom chip, not
> software. Software can't be secret, only hard to get at.

Hmmm.  Hardware would surely be the best solution.  A hard smartcard
and lots of headaches are gone.  I'm looking at a temporary solution
where smartcards have not arrived yet (too slow, not in this year's
budget..) and where username pwd is an even worse idea ;-)

And soft credentials are difficult...

The plain old PKCS#12 would not survive a day in today's malware
environment.  It wouldn't even be worth-while using it..

I'm looking for a pragmatic way of getting something useful, very
difficult to exploit by malware and reasonably hard to not be figured
out right off.

Working on this, I feel like someone who wants to invent a perpetuum
mobile...

I'm wondering whether there would be a way of finding some framework in
which "puzzles" can be plugged in that bring the necessary obfuscation
and delay of being cracked.  The framework should use one puzzle to
protect the next (sequential instead of parallel cracking)...  

any ideas whether such a thing is even possible?

best cheers
-b

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

[Jamie Lokier]

Bud P. Bruegger wrote:
> any ideas whether such a thing is even possible?

There has been a theoretical breakthrough recently in encrypted
computation, where calculations are performed without even temporarily
decrypting the values, but that breakthrough would be extremely slow
(millions of times slower than a real machine) and is currently far
from practical.

-- Jamie