re:
E-commerce in crisis: When SSL isn't safe
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.h
tml?s=feature

the PC end-point vulnerability has been long recognized ... that is part of the early motivation for the EU FINREAD terminal standard.
http://www.garlic.com/~lynn/subpubkey.html#finread

FINREAD moved authentication out of vulnerable PCs into a trusted authentication environment as well as providing mechanism for supporting transaction-based authentication (each transaction/operation is explicitly authentication) as opposed to just simple session authentication (with possibly encryption wrapper for security).

The recent discussion is that if you have a separate trusted authentication environment for authentication (based on digital signature authentication) then there are some additional benefit to relying parties to also have the trusted authentication environment also digitally signing the operation (so the relying party has some proof that a trusted authentication environment was in use as opposed to some compromised/counterfeit authentication environment).
http://www.garlic.com/~lynn/aadsm23.htm#12 Court rules email addresses are not signatures
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures

with respect about to earlier comment about having a token that requires a digital signing hardware token to have correct (human) PIN entry .... would allow a relying party to be able to associate a specific digital signature with some human operation (PIN entry), if the relying party had some way of knowing that the hardware token being used, in facted, required PIN entry.

Issues addressed by the EU finread terminal standard was to eliminate PC virus/trojan from logging the PIN value and then replaying the PIN values to the hardware token (w/o the users knowledge). The EU finread terminal standard provided from a countermeasure to the PC virus/trojan replaying PIN entries. However, the EU finread terminal standard didn't actually require the terminal to also digitally sign the transaction (providing an indication to the relying party that an finread terminal was actually being used ... as opposed to some counterfeit environment). For financial transactions, the terminal also displayed the value of the transaction being sent to the token for signing (as countermeasure to virus/trojan displaying values different than what are in the actual transaction)

There is an issue with the relying party knowing the operational characteristics of the hardware token being used for a digital signature (w/o which the relying party has no mechanism to know whether PIN-entry was even required ... or even if a hardware token is being used). The relying party having knowledge of the hardware token operational characteristics allows for some evaluation of whether it was actual simple one-factor authentication ("something you have") ... or if possibly additional authentication factors were involved (multi-factor authentication).

There is also an issue with the relying party having knowledge of the operational characteristics of any kind of terminal (or other digital signing environment) that also digitally signs the operation. This provides the relying party with basis for doing further trust evaluation (like whether there was possibility that virus/trojan entered the PIN).

Finally with respect to comment about associating PIN-entry with indication of any "human intent" (read, understood, approves, aggress, and/or authorizes)
http://www.garlic.com/~lynn/aadsm23.htm#11 Court rules email addresses are not signatures

The relying party having knowledge of the hardware token may have some basis for assuming that the digital signature implies that (the correct) PIN was entered. Having the 2nd digital signature from the terminal provides some basis for assuming that the PIN entry actually involved human interaction. That ties the token's digital signature to some human interaction. However, there is still no tie between the human interaction and read, understood, approves, aggrees, and/or authorizes.

However, if the relying party has knowledge of the terminal environment (that also digitally signs the operation), then there may be some basis for assuming that the terminal had displayed a message requesting the person to enter their PIN if they agreed with the operation (and critical pieces of the transaction is also displayed), and that the PIN was entered after the message was displayed. There is now some basis for the relying party to assume that the human interaction (PIN entry) was in response asking if the person agreed.

Early in the AADS chip strawman
http://www.garlic.com/~lynn/index.html#aads

and X9.59 work,
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

we realized that transactions needed to be directly signed, that it should be possible for the digital signing (terminal) environment to also sign the transactions, and that the relying party needed to have access to both the token operational characteristics as well as any terminal environment operation characteristics (in order to correctly interpret and evaluate any meaning attached to the digital signatures ... as well as dynamic adaptive risk assesement).

this was one of the issues over the years involving the "yes card" technology ... the token is authenticated separately from the transaction operations ... opening various kinds
of mitm-attacks
http://www.garlic.com/~lynn/subpubkey.html#mitm
or various kinds of other end-point vulnerabilities. some recent postings on "yes card" technology
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views
http://www.garlic.com/~lynn/aadsm22.htm##41 FraudWatch Chip&PIN

and is the issue in the SSL-evading trojans:
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

again, another example where the end-point is authenticated separately from the actual operations ... creating additional cracks and vulnerabilities that may be exploited (MITM-attacks and/or interception and modification).

of course, in the AADS model ... the relying party could obtain online access to all of this information for correctly interpreting digital signatures ... in a digital certificateless paradigm
http://www.garlic.com/~lynn/subpubkey.html#certless

we also talked to some of the people behind the X.509V3 digital certificate work and pointed out that such useful integrity information might be significantly more interesting to a relying party than anything that might be found a CPS statement.

another on the subject:

Trusted Web Sites Not Always Trustworthy, Says Noted Computer Security Researcher
http://biz.yahoo.com/prnews/060505/sff027.html?.v=48

with respect to today's news articles on chip&pin fraud
http://www.garlic.com/~lynn/aadsm23.htm#16
http://www.garlic.com/~lynn/aadsm23.htm#17

a post in the original thread
http://www.garlic.com/~lynn/aadms22.htm#40 FraudWatch - Chip&Pin

about chip&pin not being useable on the Internet because of vulnerabilities ... possibly similar skimming related vulnerabilities (for replay attacks).

Note that some of the vulnerabilities mentioned in this thread are similar to those faced when deploying corporate vpn for access by traveling and at-home employees.

some of this first showed up when employees would attach dial-up modems to their PCs and work and dial the internet. these PCs (when also connected to the internal corporate intra-net) allowed attackers to bridge attacks thru the dial-up connection, bypassing the corporate firewalls.

later with off-site VPN connections, the remote employee PCs required an internet connection in order to tunnel the VPN connection into the corporate network. Lots of personal PC VPN software added all sorts of countermeasures attempting to keep attackers from using the PC to bridge into the corporate network (bypassing corporate firewalls).

a lot of these corporate VPN-related countermeasures (attempting to prevent attackers from using employee's PC internet connection to bridge into the corporate network) ... have been specifically directed at virus/trojan related vulnerabilities.

Perhaps its time for people to start avoiding hotel chains.

Recently I decided to spend the weekend in an upscale resort community in the U.S. When I had reduced the number of candidates to only a few I called to find out price and availability. While I had the local reservation person (often the hotel clerk on duty) on the phone I inquired if I could pay for the deposit by money order and the room bill in cash, as I had grown wary of being tracked in commercial data bases. To my surprise most agreed. One hotel clerk expressed the same concerns. He even promised to place a 72-hour hold on room (I was making the reservation well in advance of occupancy) in order for my money order to arrive by post. Now if only the money order could be digital and available for immediate deposit by the hotel that would be a big advantage...

One innovative payment service in the U.S. is 'My ICIS' http://www.myicis.com/ They allow clients to create and maintain pseudonymous accounts from which they can issue electronic money orders. These MOs can be printed on an ordinary ink jet, trimmed to appropriate size of a standard check and deposited into a consumer or commercial account along with other checks and cash. Self-printed checks can occasionally raise some eyebrows at the teller but are perfectly legal. Its not recommended that they be deposited via an ATM. Banks often send ATM deposits to an automated processing center which can reject checks that do not have the bank routing information printed in magnetic ink (even if they are legal under Federal Clearinghouse rules). My ICIS accounts can be funded via e-gold.

Virtual credit cards, depending upon how they are funded may also be a privacy advocate's friend in these and similar situations.

For those who missed the subtle news, the 'defeat' of John Gilmore's suit against the FAA, Homeland Security and Southwest airlines, that insisted passengers present a government-issued ID before being allowed through airport security checkpoints and to board, was in some ways a victory. The judge ruled that passengers could not be required to show ID if they submitted to a more through inspection (what is commonly called being a 'Selectee').