Amir Herzberg wrote:
>I'm not sure I agree with your last statement. Consider a typical PC
>running some insecure OS and/or applications, which, as you said in earlier
>post, is the typical situation and threat. Since the OS is insecure and/or
>(usually) gives administrator priviledges to insec
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 cha
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
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 pro
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 machine
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 authentica
| >>> 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. Y
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
I agree with everything you say, David, until here.
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 at
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 *
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
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 of secure computing kernels.
I
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 buil
On Sun, 14 Dec 2003, Jerrold Leichter wrote:
>Which brings up the interesting question: Just why are the reactions to TCPA
>so strong? Is it because MS - who no one wants to trust - is involved? Is
>it just the pervasiveness: Not everyone has a smart card, but if TCPA wins
>out, everyone wil
| When it comes to the PC's operating system,
| there is apparently no economic way to achieve
| what you suggest - ensuring that it hasn't
| been tampered with - so few bother to worry
| about it. If more security is desired, the
| preferred method is to bypass the PC's OS
| completely.
...which
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 E
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 a
"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.
It is and it has been. Just not s
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.
I think PC banking is an argument *again
At 12:02 PM 12/10/2003 -0500, John S. Denker wrote:
Previous discussions of secure computing technology have
been in some cases sidetracked and obscured by extraneous
notions such as
-- Microsoft is involved, therefore it must be evil.
-- The purpose of secure computing is DRM, which is
intri
On Wed, 10 Dec 2003, John S. Denker wrote:
> Scenario: You are teaching chemistry in a non-anglophone
> country. You are giving an exam to see how well the
> students know the periodic table.
> -- You want to allow students to use their TI-83 calculators
> for *calculating* things.
> --
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
"John S. Denker" wrote:
> I leave it as an exercise for the reader to design a
> calculator with a secure kernel that is capable of
> certifying something to the effect that "no apps and
> no data tables (except for ones with the following
> hashes) have been accessible during the last N hours."
23 matches
Mail list logo
