example: secure computing kernel needed

[William Arbaugh]

>>
>
> 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 based on the software running on my machine,
> while strong authentication does not allow this.
>

That is the difference, but my point is that the result with respect to 
the control of your computer is the same. The distant end either 
communicates with you or it doesn't. In authentication, the distant end 
uses your identity to make that decision. In remote attestation, the 
distant end uses your computer's configuration (the computer's identity 
to some degree) to make that same decision.

> As a result, remote attestation enables some applications that strong
> authentication does not.  For instance, remote attestation enables DRM,
> software lock-in, and so on; strong authentication does not.  If you
> believe that DRM, software lock-in, and similar effects are 
> undesirable,
> then the differences between remote attestation and strong 
> authentication
> are probably going to be important to you.
>
> So it seems to me that the difference between authenticating software
> configurations vs. authenticating identity is substantial; it affects 
> the
> potential impact of the technology.  Do you agree?  Did I miss 
> something?
> Did I mis-interpret your remarks?
>

My statement was that the two are similar to the degree to which the 
distant end has control over your computer. The difference is that in 
remote attestation we are authenticating a system and we have some 
assurance that the system won't deviate from its programming/policy (of 
course all of the code used in these applications will be formally 
verified :-)). In user authentication, we're authenticating a human and 
we have significantly less assurance that the authenticated subject in 
this case (the human) will follow policy. That is why remote 
attestation and authentication produce different side effects enabling 
different applications: the underlying nature of the authenticated 
subject. Not because of a difference in the technology.

>
>
> P.S. As a second-order effect, there seems to be an additional 
> difference
> between remote attestation ("authentication of configurations") and
> strong authentication ("authentication of identity").  Remote 
> attestation
> provides the ability for "negative attestation" of a configuration:
> for instance, imagine a server which verifies not only that I do have
> RealAudio software installed, but also that I do not have any Microsoft
> Audio software installed.  In contrast, strong authentication does
> not allow "negative attestation" of identity: nothing prevents me from
> sharing my crypto keys with my best friend, for instance.
>

Well- biometrics raises some interesting Gattica issues.  But, I'm not 
going to go there on the list. It is a discussion that is better done 
over a few pints.

So to summarize- I was focusing only on the control issue and noting 
that even though the two technologies enable different applications 
(due to the assurance that we have in how the authenticated subject 
will behave), they are very similar in nature.


> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com