Abstract: The DMT is a currently operating digital bank with anonymous accounts. While it has many nice features, it suffers from a number of drawbacks, mainly having to do with its design as a single, closed, centralized system. We examine the possibilities this design allows for a malicious bank to take advantage of its users. While the DMT claims that this is acceptable because it is unavoidable in banking, we show that this is false, by outlining schemes involving independent parallel or distributed systems. These solutions require less trust than the DMT, often without being any more mathematically complex.
Gender neutral pronouns are used because most individuals being referred to are not only gender-ambiguous, but specifically assumed to be completely anonymous and represented only by keypairs.
This was originally published under the nym Rational Anarchist, which I used on LFC's Dodge City site before I was kicked off for not toeing the boss's line. The site and LFC are now defunct.
This was written in 2002. The DMT's cryptographic protocols may have been changed since then, I have not checked.
Details of the DMT can be found at the following links. All textual quotations are from these pages, authored by J. Orlin Grabbe:
The author is a programmer with degrees in math and computer science, and an interest in cryptography, digital cash, and cryptoanarchy. He wrote this piece because he thinks it is a shame that these people who share his goal of freedom, whose hearts are in the right place, are working so hard to implement a flawed vision. It is especially sad because they don't appear to be compromising because better solutions are too difficult or too costly, but just because their perspective is off. His hope is that this critique will encourage the architects of the DMT to rethink their vision, and ensure that potential users of the DMT understand exactly what the level of security they are proveably getting is, and how easy it is to make such systems more secure.
In this paper, we will often consider the possibility that the bank will act maliciously, that is in a way which takes advantage of its depositors. There are several possible objections to this. One is for the bank to claim that they will not act maliciously. But it is unreasonable for them to expect other people to trust them as they trust themselves. Even if the creators are trustworthy, a single malicious employee, if highly placed or working in a sensitive area, may be able to compromise that trust. Another objection, which the DMT makes, is:
So what it boils down to, is the customer is really at risk only from bank fraud--the bank takes the money and runs, or turns over the customer's money to the government. But this same risk exists with digital cash: a digital cash-issuing bank can simply repudiate the coins it issued, or turn over the customer's account to the government. A customer always has to evaluate the trustworthiness of anyone, including any bank or similar entity, with whom he forms a financial relationship. This fact of life has gone unchanged for thousands of years.
Citing past technological inadequacies is no excuse for current behavior. While it may be true that trust has been necessary for thousands of years, this "fact of life" (like several others) has been radically changed by the discovery of cryptography. In a well-designed system, no single institution ever need be trusted. Given that I propose simple alternative schemes in this paper which require much less trust than the DMT, the argument that there is no other choice is erroneous. It is one thing for traditional banks to rely on trust, but the DMT wishes to be a non-traditional, secure, cryptography-based, anonymous bank. Given that aim, why not fully embrace the technology and achieve the maximum possible security, rather than relying on flawed characteristics (like centralization) of the outdated models which they purport to be making obsolete?
The most powerful general response to objections about this sort of analysis is that whether or not a particular institution can be trusted, in evaluating a scheme we should act as though it cannot. Whenever possible, we should design cryptographic systems so that minimal trust is necessary. I consider trust in online banking to be analogous to secrecy for cryptographic algorithms - an unreliable commodity whose necessity should be minimized and that should be dispensed with as soon as technology permits. While the current founders and operators of the DMT may be trustworthy and reliable, future implementations, incarnations, or generations of owners may not be. Thus it is far better to rely on an inherently secure design when possible, and I shall demonstrate that in this case, the possibility exists.
Trust is sometimes necessary. A good chain of trust has the property that if a single link is trustworthy, the chain is secure, and the chain has enough links that it is extremely likely that one is secure. A decent network of trust has the property that if a majority of the nodes are trustworthy, the network is secure, and the network has enough nodes that it will be difficult to subvert a majority. A bad trust system has the property that if a single link is untrustworthy, the system is insecure. Note that the key properties in the previous two definitions result in a bad trust system if the chain or network size is 1, as with the DMT. Another way of phrasing this is that a good trust system is robust: even if many members are subverted, the system remains secure.
Public key cryptographic protection of an account is less worthwhile when only the DMT verifies account information. The DMT suggests that this protection ensures that only the holder of the private key can access the account. This statement is misleading. A more accurate one is: "No one but the holder of the private key can convince the DMT that they own the given account." Given that the requirement for account access is not proof in the sense of convincing an objective observer, but merely convincing the DMT, the asymmetric cryptosystem used loses much of its power. It has the nice property that an eavesdropper on the connection cannot later fake account information, nor can traditional identiy theft occur, which is certainly an advantage over traditional systems. However, if the bank is malicious, account information need not be faked. The most powerful property of the public-key system is wasted, namely that the holder of a private key can convince not just the DMT, but any objective observer that ze holds it.
The DMT might argue that while their protocols don't involve convincing an objective observer, in case of a dispute about an account, a user could do so. However, note that all a user can do is prove that ze owns the private key associated with a given public key. While the DMT uses public keys as account ID's, they unilaterally control the database where all accounts are stored, and those accounts are encrypted with their keys, so there is no way for an observer to know that a given public key has any associated DMT-account properties (such as dollar balance). Thus the DMT can, at any time, change account information, fake withdrawals, or simply make accounts disappear, and it is impossible for anyone to prove that they have done so.
They might reply "Trust us, because there is no other answer" (in fact, they have), yet there are extremely simple methods for solving this problem (Scheme 1, Parallel Banking). The DMT might respond that reputation is the answer: if they take their users money, they will not be considered trustworthy and continue to get depositors. This point has some truth but some weaknesses. How would a DMT depositor complain? Ze is anonymous and ze may not wish to be known as a DMT user. Thus using zis real-world reputation to back zis claims may not be acceptable. In a world where online reputations are solid and common, ze can use reputation to make the claims, but that still associates that reputation with the DMT. Anonymity has been compromised. And since there is no proof of any transactions with the DMT, only reputation can be used to back a complaint. Reputation should only be used for proof as a last resort.
While the threat of reputational harm might stay the hand of a prudent predator bank, if the situation is right (the money is large or the risk of getting caught is believed to be small), reputation may not be sufficient disincentive. And if bank theft occurs, reputational revenge may be little consolation to the victim. In schemes with provability, more definite redress can be counted on. The possibility of occasional prudent theft makes evaluating the trustworthiness of an institution difficult. A solution to this problem, Parallel Banking, is given later.
If the user does not trust the DMT, the fact that all accounts are maintained by a single organization compromises anonymity. The DMT may not know who owns any account (or they may, depending on access method), but they can trace the flow of money through all accounts. When person A transfers money from account A1 to Person B in account B1, A does not know who B is. The DMT does not know who B is. But it does know that money has gone from A1 to B1. It knows if money then goes to C1, and D1, and so forth. When combined with some knowledge about the real-world details of money entering and leaving the system, this results in some significant information leakage. This is easy solved by Scheme 2, Distributed Banking. We shall examine the defense of this property given by the DMT in their papers.
First of all, for the paranoid, the chain can be broken simply by withdrawing the account balance in the form of digital coins, and then later depositing these coins into new accounts.
Except, as the DMT frequently points out when justifying the design and implementation of their system, there are no such digital coin systems right now. Besides, digital coins are not needed to break the chain, only a non-monopolistic system.
Secondly, the advantage of the anonymous account system is it allows for nonhomogeneous account sizes--not just for the fixed sizes of digital coins. This means, for example, that there might be only one account of size $50,000 at a particular time in the DMT system. It is naive to think that anonymizing, say, the account number will deceive anyone into believing that the sudden appearance of the balance number "50,000" might not involve this same account. (This problem does not arise in the system described here, except for transfers into or out of the DMT system. However, a malicious bank would attempt to do traffic analysis on its own operations.)
This does not strike at the crux of the issue at hand. Anonymity is compromised because all accounts and transactions are handled by a single, monolithic entity, not just because accounts which allow for nonhomogeneous sizes are used. Even in an account based system, good user software may break up accounts into homogenous sized accounts for the reasons stated. This is an advantage of the account system, that it allows the flexibility to choose homogenous account sizes or not, as the user desires. But the problem is not the account system, it is that as long as there is a banking monopoly there will be no anonymity.
The difference in the case of homogeneous digital coins, of say size $100, is there will be many of them, and so the size anonymity relies on large numbers. (Otherwise, the blinding doesn't work.) By definition, nonhomogeneous accounts allow for unique balance sizes, and hence cannot rely on the same "hidding in the crowd" large number effect. "
Security loss is being defended by convenience gain, which does not change the fact of insecurity.
But in the DMT anonymous account system, if operated by a malicious bank, it would see chains of the form
H(x)--> x --> H(y) --> y --> y withdraws digital coins.
And it would not know who x and y are. (And when the system is operated as intended, the anonymous chain disappears entirely.)
It is true that this is what the system sees. But the statement that "it would not know who x and y are" is true only if entrances and exits to the system are anonymous. Yet the whole point of the DMT is that transactions in the real world are rarely anonymous. Wire transfers have an associated real-world bank and account number. Postal money orders may be traceable to the originating post office, and can be dusted for fingerprints. Handwriting analysis can be done. Some of these leaks are avoidable, but with extra effort that would be unnecessary if the DMT was actually an anonymous system as it claimed. This is why a Scheme 2 system is essential. Without Scheme 2 or digital coins, the DMT knows the entrance to system, the exit to system, and the chain in between, which is far from anonymous. Its true that it does not know who the account holders in between are, but knowing the flow leaks a lot of information.
Moreover, the chain H(x)--> x --> H(y) --> y, if maintained by the bank, really proves nothing whatsoever. Suppose the bank claims that, "See this $X account in Bank A, and this $X account in Bank B? Well, it came from the following chain:
$X in Bank A --> H(x) --> x --> H(y) --> y --> $X in Bank B.
The owner of the $X in Bank B could simply retort that the bank's claim is a fabrication, that the real chain is "W-->Y-->Z." Anyone can produce numbers and hash values. The point is that no transaction within the system is associated with any personal identifying information, and there is no way to distinguish one computer-generated number of the same form from another one.
As with other areas of the DMT, it is true that there is no proveability in these claims. But what if the bank isn't trying to prove anything, merely leaking information to those who are willing to trust them about it, or using the information for their own advantage? There are lots of ways in which money flow information can be useful to malicious parties. Accounts connected by such a chain are likely to be, in some way, associated, and being able to make such an association is contrary to the principles of anonymity. The issue is leakage, not proof.
As we have previously noted, in the current DMT system, there is no proveability of DMT transactions or account totals, and thus nothing to prevent the DMT from stealing money, closing accounts, or faking transfers. The user then has no recourse, as there is no way for them to prove what has happened to an objective third party. Scheme 1 offers one potential solution to the theft problem with the use of multiple banks, but no third parties or proveability beyond the banking system. Scheme 3, the use of receipts, is another solution, which allows proof of theft to objective observers, even with a centralized bank, as long as there are arbitrators or courts which have power over the DMT. The DMT has shied away from proveability, perhaps because it appears to be the opposite of anonymity, as it exposes information. However, if a trusted third party exists, users can enjoy proveability without revealing information to anyone but the third party.
Why is h(y), the hash of the public key (which is also used as the account number) used as the deposit ID for incoming transfers?
the customer (or someone on the customer's behalf) contacts DMT and claims the deposit by showing a pre-image of the deposit identification number (note that the identification number could be stolen, but only the customer knows the pre-image); the DMT then issues the customer an account, using the pre-image as the account number.
While this does verify the issuer of the deposit ID, using the hashed public key leaks some information. For example, if the depositor ever comes across a public key (perhaps while reading files on someones computer, compromising a connection, etc.), they can hash that key and see whether its the one they deposited to. This leakage is small but unnecessary. There are two ways to fix it.
First, one could make an internal transfer to a new account after every transaction. In the current DMT system, this adds no privacy from the bank, but it does add some from whoever knows the deposit ID. In a Scheme 2 system, this transfer could be secure. However, unless this is made part of the DMT specification, user software may not implement this post-deposit shuffle, resulting in frequent insecurity. Shuffling accounts, particularly through Scheme 2 banks, may also have transaction fees.
Second, rather than presenting h(pub key) as the deposit ID, simply use h(pub_key || r) where r is randomly generated by claimant. To claim, the claimant presents the pre-image, pub_key || r, the bank verifies the hash, extracts the public key (which was padded to a known length) and does a challenge-response on the key (as in the current system). Now this hash leaks no information about the associated public key to the depositor, who will never know r. No one who spies on the claim can fake ownership of the account, because they can't answer the challenge-response. And only a few lines of code need be changed.
It is disturbing that this is both a trivial change and a well-known cryptoraphic technique, yet not part of the DMT protocol.
A centralized system such as the DMT can be shut down by DOS attacks, malicious governments or service providers, or physical severation of connections (wirecutter DOS). It takes a small number of such attacks to bring down the system. The DMT is above the radar, making it a large target. In contrast, distributed systems such as those described below have no single point of vulnerability, are below the radar, and difficult to shut down. Hydra-like, they will pop up again wherever encrypted communications are allowed.
The DMT has a stated policy of allowing only a single deposit before an account is claimed. This allows denial of service attacks. A malicious adversary who sees the deposit ID can deposit 1$ before the real deposit is made, thus preventing the legitimate deposit.
The Browser Database: Each browser is protected by a password. Entering the correct password gives you access to your accounts and account data. When a transaction is initiated with the server, the server verifies that the browser is a DMT browser.
This paragraph suggests that only authorized browsers may connect. If the banking standard is secure, this is unnecessary from a security standpoint. The most obvious reason to do it is that the banking client may be valuable, and by maintaining a monopoly on it the bank can make additional money. Another is that the bank may wish to prevent certain uses of or interactions with its system. A robust system should not require this measure. In general, a closed standard reflects poorly on the system, and advances the interests of the server at the expense of its clients.
The DMT description documents make few mentions of the methods used to contact the bank. From the description, it sounds as though an encrypted but direct connection was the method expected to be used by the client software. This leaks information about the time and duration of connections to outside parties, and it leaks the senders IP address to the bank. This is a huge amount of anonymity loss, and would enable a malicious bank to frequently obtain geographic information and sometimes the exact identity of the owner (or a small set of possibilities). As is the common thread in this paper, there are solutions to this.
Anonymous email through mixmaster-type systems plus nym-based aliases is one of the most obvious ways of secure contact, but the several steps necessary for challenge-response will take a while (perhaps days) Low latency anonymous communications channels are needed (systems like Onion Routing), or even a small number of connection anonymizers that can be used like anonymous remailers. These would have the good trust property that if a single connection anonymizer was trustworthy, the parties to a communication will not be known. The DMT, as a good-faith gesture in anonymity, could write open-source connection anonymizers and allow anyone to run them. If running the anonymizers is costly enough to need charging for, DMT payments could conveniently be used. Anonymity in payments could be preserved through a digital-coin like system where an anonymizer performs a blind signature on tokens that can be spent to pay for a connection.
While such things are not strictly within the purvey of the bank or the definition of a secure banking system, they are key security issues which should be mentioned. Distributing direct-connection client software without providing means for connection anonymization is saying, again "well folks, you're going to have to trust us". It also leaks some information to outside parties. Suppose packets to the DMT are monitored for source IP address, and a malicious adversary Madver wishes to obtain the physical identity of DMT client. Ze convinces that client to make a transfer to Madver's DMT account. By repeatedly polling the DMT to see when the payment is available, Madver can learn approximately what time the payment was made (depending on allowed polling frequency and transaction clearance times). Combined with zis knowledge of source IP addresses and connection times, this should enable zim to reduce the possibilities for the clients identity greatly. A repeat of this technique or other narrowing methods can easily finish the job.
Note: These solutions are not described in full detail, as their purpose is to demonstrate simple, effective alternatives to the DMT's design. The ideas presented are not particularly original or groundbreaking, merely applications of the principles of security to the problem at hand. If there is further interest in them and more complete descriptions are desired, the author is prepared to flesh out the outlines given.
Our first scheme is a solution to the problem of the DMT ignoring its own protocols for account access. In this system, we have several independently owned and operated DMT-like banks acting in parallel, verifying transactions. When a user makes a transaction, ze connects to all banks in the system. For a transaction to work and be updated in the database, most of these banks must agree[1]. Because of the precise mathematical nature of cryptograhic account access verification, unless a connection has been compromised, a bank has gone rogue, or the user is making intentional errors, all of the banks will agree. Thus disagreement should be extremely rare and very noteworthy.
If user maliciousnesss is a problem (perhaps a large group of users agree to make their transactions with a certain bank often fail), a secure broadcast system, ie one which takes a single connection and turns it into multiple ones, can be used. In this system, the user connects to a single broadcast node, which connects to all of the banks. This adds no security for the user, but it does let each of the banks be sure that they know what every other bank is seeing. Thus each bank can issue its own challenge, and all can verify the user responses. Each individual bank will know with certainty that the holder of the private key has authorized each transaction, because it has seen the response to its own challenge. As broadcasting is so simple, it should not be difficult for the banks to ensure the security of such a system.
It should never be in the interest of a non-majority group of banks to disagree spuriously, as it will injure their reputuation and accomplish nothing. As for whether it is in the interest of a majority to cheat, note that even if 40% of the banks disagree on a transaction, and the transaction goes through, this disagreement will have harmed the reputation of the entire banking group, since disagreements should never happen with honest banks. And the honest minority has some proveability to an objective third party:
If a challenge is met incorrectly, and 60% of the banks pass it, the honest minority can say to an arbitrator "They cheated on this transaction. Ask them to show you all the succesful challenge-responses for the transaction." If the challenge response system includes date/time/transaction # information, the cheating majority cannot do so[2]. Even if all the banks are malicious, the user could request that the arbitrator pose this question.
If a correct transaction is denied, it is more difficult to prove the error. The honest minority can show the succesful challenge-response sequences to the arbitrator, but ze has no way of telling that they were not made up after the fact by the user in cahoots with the minority. They prove that the transaction should go through, but not that the majority were dishonest. Still, since a correct transaction is verifiable by anyone, as long as there are a reasonable number of alternative institutions to bring a dispute to, it will be essentially impossible to deny a legitimate user the right to make transactions with zis account.
While large, dishonest coalition of banks can cause problems in this system, subversion is much more difficult than the monolithic DMT with its single point of failure. Add Scheme-3 receipts and it becomes essentially impossible.
This scheme is a solution to the problem of anonymity. Again, we multiply the number of banks. However, these banks are each independent in the sense of having different accounts (as well as different ownership as in Scheme 1). The banks work via an identical cryptographic scheme as the DMT. We can make a good chain of trust when we require anonymity by moving money through many banks. As long as one of the banks refuses to disclose the association between an incoming transaction to an outgoing transaction, anonymity is preserved. Note that its important to have homogenous account sizes for these transactions, otherwise they are linked by virtue of their amount.
Essentially, if we wish to hide money, we lead it on a dance. We break it up into many homogenous pieces, and shuffle them through a network of minibanks, then reassemble them into several DMT accounts. This system has the negative attribute that if a single bank wishes to steal the money, it can do so. However, since the money is in small chunks, it can be fed through as a slow, steady stream, never risking very much at a time. Also the minibanks will have reputations, and a receipt system such as in Scheme 3 can be used to eliminate this danger. If minibanks have a large flow and a small balance, it will never be the economically correct decision to confiscate their accounts (unless they are about to close). Because we are dealing with an electronic system, this shuffling process can easily be automated. This process is essentially the same as the digital mix systems described by Chaum and others, except that paying for mix services is easy because the datum being mixed is money (no additional digital cash infrastructure is necessary).
Note that because these banks need no interaction with the physical world, they should be quite easy to write and maintain. The DMT does all the hard stuff like receiving wire-transfers, so these minibanks need only talk to institutions that use the same banking protocols. They can charge tiny fees for their services. Their money can even be stored in correspondent accounts with the DMT (or multiple such banks if they exist, which is preferable). What this means is that when you transfer money to minibank A, you actually transfer money from your DMT account to the minibank's DMT account. The minibank then creates an internal account for you. This means that the money of all depositors to minibank A is comingled in A's DMT account, which makes flow tracking impossible. Essentially the minibanks are serving the function of confusing the hash chain mentioned, by putting little pieces of money into big piles and then taking it apart again.
As a demonstration of good-faith in anonymity, the DMT could help stimulate the creation of these minibanks, by releasing the source code for all of their cryptographic procedures and protocols, and ensuring that the DMT is convenient for use by automated banking programs as well as individual users.
A signed digital receipt proves cryptographically that one or more parties agreed to a certain piece of information. Receipts can be used to add proveability to a digital banking scheme. After each transaction, both parties sign the receipt which contains the account balance, account number, and a monotonically increasing receipt number[3]. If there is a dispute about the account, the user and bank can go to a trusted arbitrator and present their most recent receipt. Since signatures are unforgeable, this greatly reduces the possibility of bank fraud. Unfortunately, it leaks a lot of information. Either party can present these receipts to anyone else to prove that the account had a certain balance at a certain time. This can be prevented by, rather than signing the receipt directly, encrypting the receipt with the arbitrator's public key, then signing it. Now the receipt is only readable by the arbitrator. As long as the arbitrator is honest, and has a way to make zis decision matter (such as substantial reputation), this will increase the safety of an account at a single, centralized bank.
Note, however, that in a sense this just removes the point of failure from the bank to the arbitrator. Following the logic of the previous schemes, we can address this by using multiple arbitrators. An m-out-of-n encryption scheme can be used so that the receipt can be decoded by any m out of the chosen n arbitrators. Now there must be m dishonest arbitrators to leak information, and there must not exist m honest arbitrators for a user to be denied a legitimate claim.
In a sense, these receipts are no different than digital cash. Each one is essentially just an alternative form of accounting than the transaction/DB system the DMT uses. Both are systems of proving ownership and amount of the account, just to different parties. These receipts provide redundancy to a centralized system. A receipt signed by a bank for $1000 in an account is like a bank draft, as it essentially says "If an abitration process verifies that this receipt is correct and that no newer receipt exists, I will pay $1000 to whoever has the private key associated with the account."
The process of storing account information can be separated from the process of verifying transactions to increase security. Account information storage can be parallelized just like transaction verification and arbitration, and distributed as well. The data can be partitioned so that no single node knows the details of any account or transaction. Seperating the two aspects of banking makes subversion less likely[4]. There is some sense in which all banking really is just a secure method of storing and changing a single field of data (account balance).
If we combine the previous schemes, we get a parellel, distributed, highly redundant system with proveability that is extremely robust. A large network of transaction verification, account storage, and receipt storage nodes would exist, plus associated connection anonymizers. All transactions are done in parallel with multiple verifiers and multiple storers. Different nodes are picked each time, which reduces the information exposed to any one node. The nodes maintain a reputation system among themselves, malicious nodes are distrusted. Because majorities are required for transactions, it will be difficult for malicious nodes to subvert transactions. There is no single point of attack to close down the system, and no single place to monitor for incoming transactions.
The fact that this author, who is an amateur, can not only identify these issues but propose solutions speaks poorly of the design of the Digital Monetary Trust. Many of the problems seem to stem from the same basic root. Put simply, the DMT seems to have been constructed under the paradoxical belief that its users will be cynical enough to want to move money into cyberspace, untouchable by governments and fraudsters, yet naive enough to completely trust a single, centralized, monolithic organization to keep that money safe. While we could speculate at length on why, we will simply say that this demonstrates for the zillionth time the need for substantial independent review in cryptosystems.
On the plus side, the DMT's pro-anonymity stance is great, and they should be commended for helping to advance the cause of cryptoanarchy with a real product. By providing a conduit between the real world and digital cash, they make it easier for systems such as I've sketched to be useful. The DMT may be far from the ideal achievable by current technology, but it is at least a step in the right direction. The level of anonymity and security which the DMT provides, while insufficient as a place to put substantial amounts, should be sufficient for smaller transactions without extreme anonymity requirements. This author wishes the project the best of luck in its endeavour.
[1] Note that if all banks must agree, any rogue bank can deny service when it wants. In general, the more agreement necessary, the harder it is for a false transaction to happen, but the easier it is to deny a true transaction. Thus a simple majority provides a good balance. However, note that each time a rogue bank does this, it accrues substantial suspicion.
[2] If the challenge-responses are arbitrary, as in the current DMT system, then response pairs from past sessions can be "replayed" to an arbitrator.
[3] This receipt number is instead of a timestamp, which would leak information to the arbitrator. The receipt number needs to increase as time goes on, so the arbitrator can determine which is the most recent, but it can do so in random or abitrary steps, as order is all that matters.
[4] Thanks to Simon F. for some of this.
Here are a couple indexes to anonymous distributed systems.