Re: Another Snake Oil Candidate
On Sep 12, 2007, at 1:56 AM, Aram Perez wrote: The IronKey appears to provide decent security while it is NOT plugged into a PC. But as soon as you plug it in and you have to enter a password to unlock it, the security level quickly drops. This would be the case even if they supported Mac OS or *nix. Yes- the IronKey like just about EVERY security product right now lacks a trusted path. However, they address this by suggesting that you: a. Use a "clean" PC to install your passwords into Mozilla's password manager, and b. use the mozilla's password manager from the USB device. This mitigates the lack of a trusted path between the user and the USB device. Granted the average user can't discern a "clean" machine from a "non- clean" machine. But, I think they've addressed your issue as best they can. The marketing is a bit over the top, but hardly snake oil. Bill p.s. I have no relationship with Ironkey. As I stated in my response to Jerry Leichter, in my opinion, their marketing department is selling snake oil. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How broad is the SPEKE patent.
You may want to look at EAP-PAX. We tried to engineer around the patent land mines in the field when we designed it. This of course doesn't mean that someone won't claim it infringes on something. We also have a proof (not yet published) of security in a random oracle model. Best, Bill p.s. EAP-PAX is work with my student T. Charles Clancy. On Nov 9, 2005, at 10:54 AM, Steven M. Bellovin wrote: In message <[EMAIL PROTECTED]>, "James A. Donald" writes: -- Does SPEKE claim to patent any uses of zero knowledge proof of possession of the password for mutual authentication, or just some particular method for establishing communications? Is there any way around the SPEKE patent for mutual authentication and establishing secure communications on a weak passphrase? It certainly doesn't claim EKE, by myself and Michael Merritt, since he and I invented the field. Of course, EKE is also patented. SRP is patented but royalty-free. Some of have claimed that it infringes the EKE patent; since I don't work for the EKE patent owner (Lucent), I've never tried to verify that. Radia Perlman and Charlie Kaufman invented PDM specifically as a patent-free method. However, the claim was made that it infringed the SPEKE patent. Since it wasn't patented, there was no one willing to spend the money on legal fees to fight that claim, per a story I heard. Have a look at http://web.archive.org/web/20041018153649/ integritysciences.com/history.html for some history. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
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
[EMAIL PROTECTED]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
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 attestation. The mechanism is different, but the end result is similar. 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 authentication, the distant end determines if they wish to communicate with you based on your identity. I just don't see remote attestation as providing control over your computer provided the user/owner has control over when and if remote attestation is used. Further, I can think of several instances where remote attestation is a good thing. For example, a privacy P2P file sharing network. You wouldn't want to share your files with an RIAA modified version of the program that's designed to break the anonymity of the network. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
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 don't understand why you say that. You can build perfectly good secure computing kernels that don't contain any support for remote attribution. It's all about who has control, isn't it? There is no control of your system with remote attestation. Remote attestation simply allows the distant end of a communication to determine if your configuration is acceptable for them to communicate with you. As such, remote attestation allows communicating parties to determine with whom they communicate or share services. In that respect, it is just like caller id. People should be able to either attest remotely, or block it just like caller id. Just as the distant end can choose to accept or not accept the connection. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
