For those interested in related work, Mark Currie designed and patented one around 2008 that intercepts logins, injects correct credentials, and handles the TLS on a USB device. He described it to us on Schneier's blog as follows:
"The device is a small USB gadget that effectively acts as a SSL proxy, allowing it to have direct and first access to the clear text data to and from the host. It has a small user interface so it can accept (and optionally store) specific user input (PINs, passwords, credit card no, etc) and display specific user/server output data fields. This allows it to insert either pre-stored or on-demand passwords etc. into the outgoing stream. It also allows specific confirmation data fields from the server to be displayed e.g. a beneficiary account no., balance amount, etc.
So the actual passwords are only available in the comms path and PC-side in SSL-encrypted form and any confirmation fields (beneficiary account no., balance amount) are confirmed to the user via the integrated display just before being SSL-encrypted, so they cannot be manipulated before going to the server.
In terms of inserting a password, it automatically detects the standard HTML password form field and the corresponding response message (used by all secure web servers), and substitutes a dummy password for a real one. I have confirmed that this function works on all the major web sites e.g. PayPal, Amazon, E-Bay, Google, LinkedIn, etc. and at least four banks that I have checked (probably most).
For displaying server confirmations, it might require a little help from the host server in terms of detecting the HTML display field, or else it would need to store a profile for each website (not ideal). However, it costs the host service very little to tweak a bit of HTML.
I agree with you whole-heartedly about the user being in the loop. That is what my aim was with this device – The gadget directly authenticates the server through normal SSL and displays the server validity directly to the user via the integrated display. In Internet banking the main threat is the beneficiary account number. As long as the user is satisfied that the account number displayed on the device is correct then it cannot be manipulated other than by breaking the SSL crypto. In this it is almost identical to the IBM ZTIC. The difference is that it also allows the user’s password to be sent securely to the bank and therefore does not require the use of a client cert (so no private key needed)."
"The device is a small USB gadget that effectively acts as a SSL proxy, allowing it to have direct and first access to the clear text data to and from the host. It has a small user interface so it can accept (and optionally store) specific user input (PINs, passwords, credit card no, etc) and display specific user/server output data fields. This allows it to insert either pre-stored or on-demand passwords etc. into the outgoing stream. It also allows specific confirmation data fields from the server to be displayed e.g. a beneficiary account no., balance amount, etc.
So the actual passwords are only available in the comms path and PC-side in SSL-encrypted form and any confirmation fields (beneficiary account no., balance amount) are confirmed to the user via the integrated display just before being SSL-encrypted, so they cannot be manipulated before going to the server.
In terms of inserting a password, it automatically detects the standard HTML password form field and the corresponding response message (used by all secure web servers), and substitutes a dummy password for a real one. I have confirmed that this function works on all the major web sites e.g. PayPal, Amazon, E-Bay, Google, LinkedIn, etc. and at least four banks that I have checked (probably most).
For displaying server confirmations, it might require a little help from the host server in terms of detecting the HTML display field, or else it would need to store a profile for each website (not ideal). However, it costs the host service very little to tweak a bit of HTML.
I agree with you whole-heartedly about the user being in the loop. That is what my aim was with this device – The gadget directly authenticates the server through normal SSL and displays the server validity directly to the user via the integrated display. In Internet banking the main threat is the beneficiary account number. As long as the user is satisfied that the account number displayed on the device is correct then it cannot be manipulated other than by breaking the SSL crypto. In this it is almost identical to the IBM ZTIC. The difference is that it also allows the user’s password to be sent securely to the bank and therefore does not require the use of a client cert (so no private key needed)."