so session authentication is vulnerable to trojans ... somewhat akin to man-in-the-middle attacks ... where the authentication porition is distinct from the operations to be performed.

the eu finread terminal
http://www.garlic.com/~lynn/subpubkey.html#finread

is somewhat countermeasure to that. each individual transaction is authenticated ... the finread terminal contains self-contained, independent keypad (for PIN "something you know" authentication), display (so the value of the transaction you are authenicating is the value you see), and reader (for the token "something you have" authentication). 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor

every transaction requires newly displayed value on the finread value and re-entry of PIN in response.

the eu finread terminal standard calls for certified terminal ... which may benefit the person buying/owning the terminal. this is countermeasure to compromises of the environment where the authentication is taking place.

however, one of the things allowed for in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

is that a token can digitally sign a transaction (as "something you have" authentication) and the environment that the authentication takes place in can also digitally sign the transaction. this is a countermeasure to "copy" &/or counterfeit terminals ... aka the finread standard calls for terminals to meet a certain anti-fraud specifications ... but doesn't mandate a mechanism for proving that a finread certified terminal was actually used for any particular operation (a counterfeit finread terminal may still trivially contain a trojan).

a digitally signing token (single factor "something you have" authentication) can be certified (to the satisfaction of relying parties) that it only operates when there has been additional authentication, aka the token requies correct PIN ("something you know") before operation. The validation of a digital signature then can be taken as imply both "something you have" authentication as well as "something you know" authentication (i.e. two-factor authentication).

that normal PC end-point environments have been known to be trivially vulnerable to viruses and trojans for a long time. a certified eu finread terminal is countermeasure to such viruses and trojans by providing a separate secure environment where authentication takes place (as countermeasure to widespread viruses and trojans in the pc environment).

however, the eu finread terminal specification didn't mandate any provisions for proving that such a certified terminal was actually in use ... as a countermeasure to counterfeit terminals. x9.59 standard provided provisions for both digital signing by the authentication token as well as provisions for digital signing by the authentication environment.

one of the issues in previous comments (in other threads) about "yes card" attacks ... was that some authentication environment was compromised (either evesdropping in the physical area of the authentication or via compromised or counterfeit terminals). The result of the evesdropping was then used to create the counterfeit "yes cards" which were then used as far away as possible. This two-step process by the crooks was a countermeasure to rapid identification and elimination of the compromised authentication environment (and any associated compromised or counterfeit terminal).
This maximized the non-trivial investment to compromise the
authentication environment (and maximize the fraud return-on-investment).

another countermeasure has been privately owned PDA or cellphone devices for use in authenticated transactions (to unfamiliar terminals that may be compromised or counterfeit) ... assuming they have similar attack countermeasure properties as found in eu finread terminals. one of the more recent issues as that as PDAs and cellphones become more sophisticated, it seems to also be increasing their susceptibility to virus and trojan.

misc. past posts related to "yes cards"
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

vis-a-vis security is harder than you think

long series of postings (dating back to ancient history) on the evils of buffer overflows and that common C language environments are especially vulnerable to coding mistakes that result in buffer overflows.
http://www.garlic.com/~lynn/subpubkey.html#overflow

and of course long series of postings regarding SSL (also dating back to ancient history) ... especially SSL digital certificates ... and frequently that they have more contributed more to the feeling of "comfort" (than any actual security)
http://www.garlic.com/`lynn/subpubkey.html#sslcert

oh, for a little drift, some additional, recent comments regarding attacks on the "authentication environment" ... as opposed to attacks on the actual authentication ... and countermeasures.
http://www.garlic.com/~lynn/2006h.html#14 Security

Some quick comments:

1. The URL http://www.hecker.org/mozilla/foundation-activities will always give the latest version of my Mozilla Foundation reports.

2. I can't speak for Red Hat and Sun, but I don't think that their support of ECC is motivated solely by US government business. As Bob Relyea noted in his presentation, as crypto implementations move to higher key sizes ECC has a decided advantage over RSA in terms of relative performance.

3. I'm not a lawyer so can't give a definitive opinion, but my understanding is that the basic ECC algorithms are not encumbered by patents; rather the ECC-related patents are for specific ECC implementation techniques. (For more information see the Wikipedia article on ECC and the separate Wikipedia article on ECC patents.) To my knowledge the ECC code going into NSS (and hence into Mozilla-based products) is based on public domain ECC algorithms, and of course that code will be released under the standard Mozilla MPL/GPL/LGPL licensing scheme. So in that sense it will be just as free and open as the implementations for RSA, SHA-1, AES, and so on.

1. fixed above, thanks!

2, 3. OK, my perspective is perhaps coloured by the experiences we had in the Cryptix group a few years back. Then, when esteemed cryptoplumber Paulo Barreto implemented EC in Java, he found that the non-patented set was so slow as to be completely uninteresting. Or so I recall... I guess Bob Relyea will have the last word when the code is done and some basic benchmarks can be cranked up.