[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Asrg] Patent Wednesday
> From: william(at)elan.net [mailto:william at elan.net]
> Interesting idea. Unclear on the counter thing though. Are
> you inclduding this on the "key" clear text? If yes, then
> user can easily temper with it and change so the counter data
> can not be trusted. If its not clear text, and is signed,
> then its necessary to include private key with user program
> and its the same problem as resourcefull hacker would find
> how to change it by reverse-engineering.
The key is included in the scope of the signature BUT the signature package
is assembled by the trusted hardware alone.
So the application presents H(m), the token calculates H( H(m), c) and signs
it.
> So if the counter can not be trusted, all we have is SecureID
> clone for email but that makes it possible for bad guy to
> have bought this "key" anonymously and start using it to send
> bad emails.
Yes, they can send a certain number of bad emails but they cannot send large
volumes and they cant send one email to many recipients if the email
recipient is in the scope of the signature.
> The only way to stop this would be with
> revocation and with real-time system that can monitor
> requests for revocation (which must be done for every
> message) and begin to respond negatively if they are too many
> (way beyond what was in the counter...).
Yes, a revocation scheme is probably a useful supplement if the tokens are
given out anonymously.
> Am I on the right track here on how it will have to be used?
Pretty much. It works a heck of a lot better for applications like cell
phone instant messaging etc where there are greenfield deployment
opportunities.
_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg