[1] The client is NOT validating yet that the transaction built by the server is in fact what i asked the server to do.
If the server is compromised and we have [1] resolved, there is no much harm that an attacker could possible do in terms of stolen funds.
So, there is no such thing as "false validation".
If an attacker compromise our server and we don't have [1] implemented, the attacker can create a malicious transaction (changing the destination of the funds) then the client will sign (without validating) and funds will be lost.
If the transactions does not validate, the client won't sign it, so no funds lost.
I just want to clarify that even with [1] resolved, a user can still lose money if the server is compromised.
One method is to change the active key reported by the server for a given account name. The client has no way of knowing the mapping between human-readable account name to active public key. That would require the client to download and process the full blockchain which is not feasible for a mobile client.
Alternatively, we could take some notes from Ethereum and augment our consensus system to use a Merkle Patricia tree to represent the state of the entire database in periodic snapshots, commit the root hash of that database snapshot into the block headers, and have a super majority of the delegates confirm that snapshot as part of their block signing process, as I described
here; that coupled with further changes in block production procedure that make it possible for lightweight clients to
update the set of active delegates over time with minimal trust assuming they do not resync too infrequently, means that a lightweight client could verify proof of the existence of some state in the database (where the proof scales logarithmically with the number of keys in the database) in a very low trust manner. But that requires a lot of complicated changes and work, so we can't expect that anytime soon.
There is a much simpler way to protect against this threat however. First, would be to use the TOFU (trust on first use) security principle. The mobile wallet could automatically add to the contacts list any account name to whom the user sends funds. The mobile wallet would log the association between the account name and the owner/active public keys. If the active public key changes, the mobile wallet would require proof (the transaction signed by the owner key that changed the active key) from the server in order to update its local active public key associated with the account. If the server ever sends the mobile wallet an unsigned transaction where the active public key or owner public key associated to an account name that the user wants to send funds to is not the one stored in the local database of the mobile wallet, it would warn the user that the server is likely compromised and explain to the user how to proceed. Second, it should also be possible for the user to pin a contact as trusted (which would show up in the GUI in a special way when sending that account funds). Pinning a contact as trusted means that the user has manually verified the owner key of the account through out-of-band methods and trusts that is it correct (it could also mean that pinned accounts will keep their associated owner/active public key in the local database and that data cannot be garbage collected to save space like it could be possible with the auto-added contacts). A user may be more careful about sending funds to an unpinned account than a pinned account. For example, if they want to send a large amount of money to some unpinned account, they might first send a small amount, verify through outside channels (like in person or over the phone) that they received the payment, pin the account, and then send the rest of the larger sum of money.
The other method by which the user can lose money is through the server making it appear as if the user received funds (very similar to a double-spend attack). The attacker that compromised the server (say they were able to get the server's private SSL keys and man-in-the-middle or rather man-on-the-side attack the user's connection) could buy goods/services from the user (or exchange cryptocurrency for cash or other cryptocurrency) and make it appear as if the user received funds for the exchange. For example, the attacker could send a legitimate (properly signed) transaction to the user's address that was funded by withdrawing funds from an illegitimate balance (a balance that does not exist or does but has 0 funds in it). Without the Merkle Patricia tree discussed above, the user is forced to trust the server about the existence of balances in the consensus database.
Unfortunately there is no way to protect against this attack without the complex improvements to lightweight client validation that I discussed above. Fortunately, it is fairly difficult to pull off since it requires not just compromising the server but also compromising the specific victim (and the victim's internet connection) in a live environment usually with physical presence required by the attacker's agents (to actually buy the good/service in person). Also, the typical victim (a merchant) would usually be someone who is capable of running a full client.
Finally, this is not bringing up all of the other possible attacks that become possible when you want to move beyond simply transferring assets to other parties. For example, a light wallet that was capable of trading on the DEX would be very vulnerable to the server. The server could make the order book appear to the user in anyway it wanted. Fortunately, if it is too strange the user will become suspicious of the server, since the prices can only deviate from what user expects them to be so far before the user attempts to verify through other means. Still, small tweaks to the order book could allow the server to profit immensely by front running its users.
Topic: Mobile Wallet - Testers needed (Read 104463 times)
