any given
piece of data.
P
- Original Message -
From: Nomen Nescio [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 5:10 PM
Subject: Re: Cryptogram: Palladium Only
Peter N. Biddle wrote:
[...] You can still extract everything in Pd via a HW attack. [...]
How is this BORE resistant? The Pd security model is BORE resistant for a
unique secret protected by a unique key on a given machine. Your hack on
your machine won't let you learn the secrets on my
which isn't
debuggable), it is enforced.
P
- Original Message -
From: Ed Gerck [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, September 17, 2002 2:51 PM
Subject: Re: Cryptogram: Palladium Only for DRM
It may be useful to start off with the observation that Palladium
should let me do that.
P
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 17, 2002 10:54 AM
Subject: Re: Cryptogram: Palladium Only for DRM
David Wagner wrote:
I wasn't thinking of pure software solutions. I was thinking of a
combination
- Original Message -
From: Pete Chown [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 17, 2002 4:16 AM
Subject: Re: Cryptogram: Palladium Only for DRM
AARG!Anonymous wrote:
In addition, I have argued that trusted computing in general will work
very well with open
On Wed, 18 Sep 2002, Peter wrote:
Hi Pete - I'm confused. Are you suggesting that I should enjoy these
freedoms on SW which I don't have legal rights to?
In emergencies, yes. Remember the people trying to deal with
and organize the WTC rescue efforts, whose software kept rebelling
because of
Relevence to the Pd debate is that banks may in future insist on remote
attestation of users' software (however practically possible that is)
so
that they can attempt to dump yet more liability on their users
(Ladies and
gentlemen of the jury, Mr Doe's claim that he did not authorise this
It takes a lot for me to get cranky around here, but I'm afraid Aarg!
has done it.
AARG!Anonymous [EMAIL PROTECTED] writes:
Perry Metzger writes:
Why not simply design the OS so it is not a likely victim for viruses?
This is a general security problem, not one special to banking
Niels Ferguson [EMAIL PROTECTED] writes:
At 16:04 16/09/02 -0700, AARG! Anonymous wrote:
Nothing done purely in software will be as effective as what can be done
when you have secure hardware as the foundation. I discuss this in more
detail below.
But I am not suggesting to do it purely in
AARG!Anonymous wrote:
David Wagner writes:
Standard process separation, sandboxes, jails, virtual machines, or other
forms of restricted execution environments would suffice to solve this
problem.
Nothing done purely in software will be as effective as what can be done
when you have secure
At 16:00 17/09/02 +1200, Peter Gutmann wrote:
But I am not suggesting to do it purely in software. Read the Intel manuals
for their CPUs. There are loads of CPU features for process separation,
securing the operating system, etc. The hardware is all there!
There was a rather nice paper at Usenix
At 11:02 PM -0700 9/16/02, David Wagner wrote:
AARG!Anonymous wrote:
David Wagner writes:
Standard process separation, sandboxes, jails, virtual machines, or other
forms of restricted execution environments would suffice to solve this
problem.
Nothing done purely in software will be as
David Wagner wrote:
I wasn't thinking of pure software solutions. I was thinking of a
combination of existing hardware + new software: use the MMU to provide
separate address spaces, and use a secure VM or OS kernel to limit what
those processes can do. As far as I can see, this can provide
Niels Ferguson[SMTP:[EMAIL PROTECTED]] wrote:
Well, I'm tired of this. AARG, or whoever is hiding behind this pseudonym,
is obviously not reading the responses that I send, as he keeps asking
questions I already answered. I'm not going to waste more of my time
responding to this. This is
It may be useful to start off with the observation that Palladium will not be
the answer for a platform that *the user* can trust. However, Palladium
should raise awareness on the issue of what a user can trust, and what not.
Since a controling element has to lie outside the controled system,
At 01:07 PM 9/17/2002 -0700, [EMAIL PROTECTED] wrote:
As far as I know, banks assume that a certain percentage of their
transactions will be bad and build that cost into their business
model. Credit and ATM cards and numbers are as far from secure as could
be, far less secure than somebody
At 06:02 AM 9/17/2002 +, David Wagner wrote:
I wasn't thinking of pure software solutions. I was thinking of a
combination of existing hardware + new software: use the MMU to provide
separate address spaces, and use a secure VM or OS kernel to limit what
those processes can do. As far as I
At 1:07 PM -0700 on 9/17/02, [EMAIL PROTECTED] wrote:
As far as I know, banks assume that a certain percentage of their
transactions will be bad and build that cost into their business
model. Credit and ATM cards and numbers are as far from secure as
could be, far less secure than somebody
18 matches
Mail list logo
