W3C home > Mailing lists > Public > www-html-editor@w3.org > October to December 2003

Re: Protecting code and data in Windows

From: Steffen Dettmer <steffen@dett.de>
Date: Tue, 7 Oct 2003 09:48:31 +0200
To: secprog@securityfocus.com
Message-ID: <20031007094830.C3795@dx.net.de>

* Jesper Anderson wrote on Mon, Oct 06, 2003 at 16:22 +0200:
> On Sat, Oct 04, 2003 at 01:18:08PM +0500, Muzaffar Mahkamov wrote:
[Storing secret data in a way that no process can read it out]
> > 
> > You're right. The biggest issue here is the debugger. 
> 
> Nope. Can't be done. A software ICE debugger will be able to simply
> bypass all of that
[...]
> The only way to implement this is through the Trusted Computer
> Initiative (trusted by the VENDOR, not the OWNER), and that will in
> practice lock everyone but licensed developers out of developing
> *anything* for the OS. So, that is unlikely to happen. Plus, even that
> can be bypassed; although it's harder.
[...] 
> There is no way to block a determined attacker with physical access.
> None. It can't be done. It's possible to make it harder for them, and
> maybe, just maybe, make it so hard that it's not economically feasible
> to attack the system. 

If there is secret data (e.g. a cryptgraphic key) I also think
that it is not safe on such complex systems like Unix/Win. It can
be manipulated in numerous ways of course.

I think that is what hardware security modules are for. Used as
secret key store, one may allow functions to:

  - erase all data and create (or maybe load) a new key,
  - use this key for a cryptographic operation, e.g. encrypt,

but not a function to directly access the key or use it in any
other way.

An attacker can still gain profit; he can access this
functionality (in some way) - but it is not possible to get the
key. So, in this example, she would not be able to decrypt.
Surely there is another security module in a more secure
environment which offers a decrypt function to a box without
network.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
Received on Tuesday, 7 October 2003 17:31:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:53 UTC