qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: "Bud P. Bruegger" <bruegger@ancitel.it>
Cc: Blue Swirl <blauwirbel@gmail.com>,
	Forrester <forrester@ancitel.it>,
	John@csclub.uwaterloo.ca, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"?
Date: Fri, 4 Sep 2009 09:12:28 -0400	[thread overview]
Message-ID: <20090904131228.GH23700@csclub.uwaterloo.ca> (raw)
In-Reply-To: <20090903170931.1e7d5772@bud-laptop>

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

  parent reply	other threads:[~2009-09-04 13:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31 16:08 [Qemu-devel] QEMU as a "virtual smart card"? Bud P. Bruegger
2009-09-01 22:27 ` Laurent Vivier
2009-09-01 23:47 ` Jamie Lokier
2009-09-02 14:58   ` Blue Swirl
2009-09-03 15:09     ` Bud P. Bruegger
2009-09-03 18:51       ` Blue Swirl
2009-09-04 12:08       ` Paul Brook
2009-09-04 13:12       ` Lennart Sorensen [this message]
2009-09-04 13:40         ` Bud P. Bruegger
2009-09-05  2:21           ` Jamie Lokier
2009-09-02  6:58 ` [Qemu-devel] " Paolo Bonzini
2009-09-02  9:17   ` François Revol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090904131228.GH23700@csclub.uwaterloo.ca \
    --to=lsorense@csclub.uwaterloo.ca \
    --cc=John@csclub.uwaterloo.ca \
    --cc=blauwirbel@gmail.com \
    --cc=bruegger@ancitel.it \
    --cc=forrester@ancitel.it \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).