At 04:20 30/12/2003, David Wagner wrote:
Ed Reed wrote:
There are many business uses for such things, like checking to see
if locked down kiosk computers have been modified (either hardware
or software),
I'm a bit puzzled why you'd settle for detecting changes when you
can prevent them. Any
Jerrold Leichter wrote:
| *Any* secure computing kernel that can do
| the kinds of things we want out of secure computing kernels, can also
| do the kinds of things we *don't* want out of secure computing kernels.
David Wagner wrote:
| It's not hard to build a secure kernel that doesn't provide
Ed Reed wrote:
There are many business uses for such things, like checking to see
if locked down kiosk computers have been modified (either hardware
or software),
I'm a bit puzzled why you'd settle for detecting changes when you
can prevent them. Any change you can detect, you can also prevent
I must confess I'm puzzled why you consider strong authentication
the same as remote attestation for the purposes of this analysis.
It seems to me that your note already identifies one key difference:
remote attestation allows the remote computer to determine if they wish
to speak with my
William Arbaugh writes:
If that is the case, then strong authentication provides the same
degree of control over your computer. With remote attestation, the
distant end determines if they wish to communicate with you based on
the fingerprint of your configuration. With strong
William Arbaugh wrote:
David Wagner writes:
As for remote attestion, it's true that it does not directly let a remote
party control your computer. I never claimed that. Rather, it enables
remote parties to exert control over your computer in a way that is
not possible without remote
| We've met the enemy, and he is us. *Any* secure computing kernel
| that can do
| the kinds of things we want out of secure computing kernels, can also
| do the
| kinds of things we *don't* want out of secure computing kernels.
|
| I don't understand why you say that. You can build
Remote attestation has use in applications requiring accountability of
the user, as a way for cooperating processes to satisfy themselves
that
configurations and state are as they're expected to be, and not
screwed
up somehow.
There are many business uses for such things, like checking to see
if
William Arbaugh wrote:
On Dec 16, 2003, at 5:14 PM, David Wagner wrote:
Jerrold Leichter wrote:
We've met the enemy, and he is us. *Any* secure computing kernel
that can do
the kinds of things we want out of secure computing kernels, can also
do the
kinds of things we *don't* want out
Jerrold Leichter wrote:
We've met the enemy, and he is us. *Any* secure computing kernel that can do
the kinds of things we want out of secure computing kernels, can also do the
kinds of things we *don't* want out of secure computing kernels.
I don't understand why you say that. You can build
I'm not sure why no one has considered the PC banking problem to be a
justification for secure computing. Specifically, how does a user know
their computer has not been tampered with when they wish to use it for
banking access.
Paul
John S. Denker wrote:
Previous discussions of secure computing
At 02:41 PM 12/14/2003 +, Dave Howe wrote:
Paul A.S. Ward wrote:
I'm not sure why no one has considered the PC banking problem to be a
justification for secure computing. Specifically, how does a user
know their computer has not been tampered with when they wish to use
it for banking
At 07:25 PM 12/11/2003 -0500, Paul A.S. Ward wrote:
I'm not sure why no one has considered the PC banking problem to be a
justification for secure computing. Specifically, how does a user know
their computer has not been tampered with when they wish to use it for
banking access.
actually the EU
13 matches
Mail list logo
