The problem is that no matter what you do, the user ends up having to enter that passphrase or decrypt the wallet on their system. If that system is compromised then the malware has the same access as the user and unless they verify things on both sides (the system and the 2FA where the second signature is generated) that malware can still do its thing by interrupting the communication and letting the user think they are communicating with the second party while the malware is.
I think if we were to ignore the privacy part, since both Electrum and TrustedCoin would compromise privacy anyways.
Would it be better for TrustedCoin to be able to send a message containing the address to the user's 2FA app? Something like this[1] so it becomes more like a push notification. It eliminates the risks of having a malware, unless both the user's device and the computer are compromised. The main caveat that I can see from this is that it involves giving another party the transaction information which actually eliminates the privacy aspect completely at this point. At the same time, you can probably trust that the malware cannot modify whatever is displayed on the phone and that Authy or whichever provider is as trustworthy as TrustedCoin.
[1]
https://gemini.com/blog/introducing-authy-pushIf we are adding a new device requirement then it doesn't have to reduce privacy any more than it currently is. The setup could be like this (and works only for SegWit transactions since their txid doesn't change with signature):
1. The user creates a transaction, computes its transaction ID, signs it and sends it to the TrustedCoin servers to sign.
2. The TrustedCoin server does what it already does (verify tx,...) without signing. Instead it sends the transaction ID to that secondary device of the user (an SMS for instance) to verify before it signs it.
3. The user sees and verifies the txid is the same and approves it.
4. The TrustedCoin server receives the approval and signs the transaction and sends it back/broadcast it to the network.
To prevent the "middleman" from knowing the transaction ID and linking it to the phone owner for example we can send something else instead of the txid itself. It could be HMACSHA256 of the transaction ID by first communicating a "key" between the server and the user and compute the hash like this:
HMACSHA256(msg=txid, key=key)
Now the SMS contains a hash that can not be connected to user's tx without knowing that "hmac key" but the user can still verify it.
