From: william(at)elan.net [mailto:william(_at_)elan(_dot_)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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg