From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjYzP-0001ud-Bt for qemu-devel@nongnu.org; Fri, 04 Sep 2009 09:38:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjYzK-0001qF-KW for qemu-devel@nongnu.org; Fri, 04 Sep 2009 09:38:06 -0400 Received: from [199.232.76.173] (port=40936 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjYzK-0001q9-IF for qemu-devel@nongnu.org; Fri, 04 Sep 2009 09:38:02 -0400 Received: from relay2.ancitel.it ([194.177.104.129]:59842) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjYzK-0001gz-15 for qemu-devel@nongnu.org; Fri, 04 Sep 2009 09:38:02 -0400 Date: Fri, 4 Sep 2009 15:40:39 +0200 From: "Bud P. Bruegger" Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"? Message-ID: <20090904154039.09fd1cad@bud-laptop> In-Reply-To: <20090904131228.GH23700@csclub.uwaterloo.ca> References: <20090831180825.6ed2ea55@bud-laptop> <20090901234716.GB1321@shareable.org> <20090903170931.1e7d5772@bud-laptop> <20090904131228.GH23700@csclub.uwaterloo.ca> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: Blue Swirl , Forrester , John@csclub.uwaterloo.ca, qemu-devel@nongnu.org > 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