Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
From: cyphrpunk
Note that e-gold, which originally sold non-reversibility as a key benefit of the system, found that this feature attracted Ponzi schemes and fraudsters of all stripes, and eventually it was forced to reverse transactions and freeze accounts. It's not clear that any payment system which keeps information around to allow for potential reversibility can avoid eventually succumbing to pressure to reverse transactions. Only a Chaumian type system, whose technology makes reversibility fundamentally impossible, is guaranteed to allow for final clearing. And even then, it might just be that the operators themselves will be targeted for liability since they have engineered a system that makes it impossible to go after the fruits of criminal actions.
More to the point, an irreversible payment system raises big practical problems in a world full of very hard-to-secure PCs running the relevant software. One exploitable software bug, properly used, can steal an enormous amount of money in an irreversible way. And if your goal is to sow chaos, you don't even need to put most of the stolen money in your own account--just randomly move it around in irreversible, untraceable ways, making sure that your accounts are among the ones that benefit from the random generosity of the attack. The payment system operators will surely be sued for this, because they're the only ones who will be reachable. They will go broke, and the users will be out their money, and nobody will be silly enough to make their mistake again.
CP
--John
On 10/24/05, John Kelsey
More to the point, an irreversible payment system raises big practical problems in a world full of very hard-to-secure PCs running the relevant software. One exploitable software bug, properly used, can steal an enormous amount of money in an irreversible way. And if your goal is to sow chaos, you don't even need to put most of the stolen money in your own account--just randomly move it around in irreversible, untraceable ways, making sure that your accounts are among the ones that benefit from the random generosity of the attack.
To clarify one point, it is not necessary to have "accounts" in an ecash system. Probably the simpler approach is for a mint that has three basic functions: selling ecash for real money; exchanging ecash for new ecash of equal value; and buying ecash for real money. All ecash exchanges with the mint can be anonymous, and only when ecash is exchanged for real money does that side of the transaction require a bank account number or similar identifying information. In such a system, the ecash resides not in accounts, but in digital wallets which are held in files on end users' computers. The basic attack scenario then is some kind of virus which hunts for such files and sends the ecash to the perpetrator. If the ecash wallet is protected, by a password or perhaps a token which must be inserted, the virus can lie in wait and grab the ecash once the user opens the wallet manually. There are several kinds of malicious activities that are possible, from simply deleting the cash to broadcasting it in encrypted form such as by IRC. Perhaps it could even engage in the quixotic action of redistributing some of the cash among the users, but my guess is that pecuniary motivations would dominate and most viruses will simply do their best to steal ecash. Without accounts per se, and using a broadcast channel, there is little danger in receiving or spending the stolen money. Digital wallets will require real security in user PCs. Still I don't see why we don't already have this problem with online banking and similar financial services. Couldn't a virus today steal people's passwords and command their banks to transfer funds, just as easily as the fraud described above? To the extent that this is not happening, the threat against ecash may not happen either.
The payment system operators will surely be sued for this, because they're the only ones who will be reachable. They will go broke, and the users will be out their money, and nobody will be silly enough to make their mistake again.
They might be sued but they won't necessarily go broke. It depends on how deep the pockets are suing them compared to their own, and most especially it depends on whether they win or lose the lawsuit. As Steve Schear noted, there is a reasonable argument that a payment system issuer should not be held liable for the misdeeds of its customers. Jurisdictional issues may be important as well. Clearly anyone proposing to enter this business will have to accept the risk and cost of defending against such lawsuits as part of the business plan. CP
On Mon, Oct 24, 2005 at 02:58:32PM -0700, cyphrpunk wrote:
Digital wallets will require real security in user PCs. Still I don't see why we don't already have this problem with online banking and similar financial services. Couldn't a virus today steal people's passwords and command their banks to transfer funds, just as easily as the fraud described above? To the extent that this is not happening, the threat against ecash may not happen either.
Well, there have been several attacks of this kind against Russia's WebMoney system. One of the founders and first arbiters, Nikita Sechenko, wrote up the following text on his advocacy webpage owebmoney.ru (my translation): https://www.financialcryptography.com/mt/archives/000492.html It also contains somre relevant bits about governing an payment system based on pseudonymous accounts. I think, theirs is the most sophisticated account-based payment system in active use, complete with arbitration, messaging, billing, key certification, credit operations and credit history, and a lot more. -- Daniel
One intresting security measure protecting valuable digital assets (WM protects private keys this way) is "inflating" them before encryption. While it does not protect agains trojan applications, it does a surprisingly good job at reducing attacks following the key logging + file theft pattern. This security measure depends on two facts: storage being much cheaper than bandwidth and transmission of long files being detectable, allowing for detecting and thwarting an attack in progress. -- Daniel
Date sent: Tue, 25 Oct 2005 00:38:36 +0200
To: cyphrpunk
One intresting security measure protecting valuable digital assets (WM protects private keys this way) is "inflating" them before encryption.
While it does not protect agains trojan applications, it does a surprisingly good job at reducing attacks following the key logging + file theft pattern.
This security measure depends on two facts: storage being much cheaper than bandwidth and transmission of long files being detectable, allowing for detecting and thwarting an attack in progress.
How does one inflate a key?
-- Daniel
On 10/26/05, James A. Donald
How does one inflate a key?
Just make it bigger by adding redundancy and padding, before you encrypt it and store it on your disk. That way the attacker who wants to steal your keyring sees a 4 GB encrypted file which actually holds about a kilobyte of meaningful data. Current trojans can steal files and log passwords, but they're not smart enough to decrypt and decompress before uploading. They'll take hours to snatch the keyfile through the net, and maybe they'll get caught in the act. CP
participants (4)
-
cyphrpunk -
James A. Donald -
John Kelsey -
nagydani＠epointsystem.org