March 06, 2014
Eat this, Bitcoin -- Ricardo now has cloud!
Ricardo is now cloud-enabled.
Which I hasten to add, is not the same thing as cloud-based, if your head is that lofty. Not the same thing, at all, no sir, feet firmly placed on planet earth!
Here's the story. Apologies in advance for this self-indulgent rant, but if you are not a financial cryptographer, the following will appear to be just a lot of mumbo jumbo and your time is probably better spent elsewhere... With that warning, let's get our head up in the clouds for a while.
As a client-server construction, much like a web arrangement, and like Bitcoin in that the client is in charge, the client is of course vulnerable to loss/theft. So a backup of some form is required. Much analysis revealed that backup had to be complete, it had to be off-client, and also system provided.
That work has now taken shape and is delivering backups in bench-conditions. The client can backup its entire database into a server's database using the same point-to-point security protocol and the same mechanics as the rest of the model. The client also now has a complete encrypted object database using ChaCha20 as the stream cipher and Poly1305 as the object-level authentication layer. This gets arranged into a single secured stream which is then uploaded dynamically to the server. Which latter offers a service that allows a stream to be built up over time.
Consider how a client works: Do a task? Make a payment? Generate a transaction!
Remembering always it's only a transaction when it is indeed transacted, this means that the transaction has to be recorded into the database. Our little-database-that-could now streams that transaction onto the end of its log, which is now stream-encrypted, and a separate thread follows the appends and uploads additions to the server. (Just for those who are trying to see how this works in a SQL context, it doesn't. It's not a SQL database, it follows the transaction-log-is-the-database paradigm, and in that sense, it is already stream oriented.)
In order to prove this client-to-server and beginning to end, there is a hash confirmation over the local stream and over the server's file. When they match, we're golden. It is not a perfect backup because the backup trails by some amount of seconds; it is not therefore /transactional/. People following the latency debate over Bitcoin will find that amusing, but I think this is possibly a step too far in our current development; a backup that is latent to a minute or so is probably OK for now, and I'm not sure if we want to try transactional replication on phone users.
This is a big deal for many reasons. One is that it was a quite massive project, and it brought our tiny startup to a complete standstill on the technical front. I've done nothing but hack for about 3 months now, which makes it a more difficult project than say rewriting the entire crypto suite.
Second is the reasoning behind it. Our client side asset management software is now going to be using in a quite contrary fashion to our earlier design anticipations. It is going to manage the entire asset base of what is in effect a financial institution (FI), or thousands of them. Yet, it's going to live on a bog-standard Android phone, probably in the handbag of the Treasurer as she roves around the city from home to work and other places.
Can you see where this is going? Loss, theft, software failure, etc. We live in one of the most crime ridden cities on the planet, and therefore we have to consider that the FI's entire book of business can be stolen at any time. And we need to get the Treasurer up and going with a new phone in short order, because her customers demand it.
Add in some discussions about complexity, and transactions, and social networking in the app, etc etc and we can also see pretty easily that just saving the private keys will not cut the mustard. We need the entire state of phone to be saved, and recovered, on demand.
But wait, you say! Of course the solution is cloud, why ever not?
No, because, cloud is insecure. Totally. Any FI that stores their customer transactions in the cloud is in a state of sin, and indeed it is in some countries illegal to even consider it. Further, even if the cloud is locally run by the institution, internally, this exposes the FI and the poor long suffering customer to fantastic opportunities for insider fraud. What I failed to mention earlier is that my user base considers corruption to be a daily event, and is exposed to frauds continually, including from their FIs. Which is why Ricardo fills the gap.
When it comes to insider fraud, cloud is the same as fog. Add in corruption and it's now smog. So, cloud is totally out, or, cloud just means you're being robbed blind like you always were, so there is no new offering here. Following the sense of Digicash from 2 decades earlier, and perhaps Bitcoin these days, we set the requirement: The server or center should not be able to forge transactions, which, as a long-standing requirement (insert digression here into end-to-end evidence and authentication designs leading to triple entry and the Ricardian Contract, and/or recent cases backing FIs doing the wrong thing).
To bring these two contradictions together however was tricky. To resolve, I needed to use a now time-honoured technique theorised by the capabilities school, and popularised by amongst others Pelle's original document service called wideword.net and Zooko's Tahoe-LAFS: the data that is uploaded over UDP is encrypted to keys only known to the clients.
And that is what happens. As my client software database spits out data in an append-only stream (that's how all safe databases work, right??) it stream-encrypts this and then sends the stream up to the server. So the server simply has to offer something similar to the Unix file metaphor: create, read, write, delete *and append*. Add in a hash feature to confirm, and we're set. (It's similar enough to REST/CRUD that it's worth a mention, but different enough to warrant a disclaimer.)
A third reason this is a big deal is because the rules of the game have changed. In the 1990s we were assuming a technical savvy audience, ones who could manage public keys and backups. The PGP generation, if you like. Now, we're assuming none of that. The thing has to work, and it has to keep working, regardless of user foibles. This is the Apple-Facebook generation.
This benchmark also shines adverse light on Bitcoin. That community struggles to deal with theft, lurching from hack to bug to bankruptcy. As a result of their obsession over The Number One Criminal (aka the government) and with avoiding control at the center, they are blinded to the costly reality of criminals 2 through 100. If Bitcoin hypothetically were to establish the user-friendly goal that they can keep going in the face of normal 2010s user demands and failure modes, it'd be game over. They basically have to handwave stuff away as 'user responsibility' but that doesn't work any more. The rules of the game have changed, we're not in the 1990s anymore, and a comprehensive solution is required.
Finally, once you can do things like cloud, it opens up the possibilities for whole new features and endeavours. That of course is what makes cloud so exciting for big corporates -- to be able to deliver great service and features to customers. I've already got a list of enhancements we can now start to put in, and the only limitation I have now is capital to pay the hackers. We really are at the cusp of a new generation of payment systems; crypto-plumbing is fun again!
February 26, 2014
How MtGox Failed the Five Parties Governance Test
This was a draft of an article now published in Bitcoin Magazine. That latter is somewhat larger, updated and has some additional imagery.
MtGox, the Bitcoin exchange, is in the news again, this time for collapsing. One leaked report maintains that MtGox may only have 2,000 Bitcoins in reserve over against 744,408 BTC in liabilities - which indicates a reserve of less than 1%.
MtGox originally claimed that their troubles stem from a long-term exploit of the evil malleability bug, which was exploited by means of repeated double spending through an algorithm. However a loss of 99.7% of their reserves cannot be attributed to some mere market timing bug. It is clear that the failure of MtGox is a failure of governance.
Trust Shall Not Live by Tech Alone
One of the temptations for applied cryptographers is to think that we can solve all problems with clever mathematics and inspired code. Thus there has been much discussion over the past two decades about using cryptography to build trust models that work for untrusted parties over the Internet.
This hope in cryptography is misplaced, and often dangerously so. In the first generation of the Internet, SSL was promoted to solve the trust and security problem. However, it failed to do that. Although it secured the line of communications, it left the end-points open to attack, and failed to solve the problem of knowing who the person at an end-point really is.
As history shows, and MtGox confirms, the end-point security question is by far the dominating one, and thus we saw the rise of phishing attacks, “man in the browser” attacks, and server breaches throughout the 2000’s. Yet, SSL remains synonymous with Internet e-commerce security, and its very domination is a blindness that attackers benefit from.
Bitcoin can be broadly described as an attempt to solve the problem of governance of a centralised issuer of currency through technology. By using a common protocol to manage a public blockchain, we can make sure everyone follows the rules and make it technically impossible to issue more Bitcoins than the protocol has decreed shall ever exist.
However, like SSL, Bitcoin’s solution to the issuance problem has left open the weaker parts of the system to continued attack. In order to provide useful Bitcoin services, businesses must hold the users’ Bitcoins and/or their cash in trust. These businesses, such as exchanges, brokerages, online wallets, retail, etc, are at risk from insider theft, external hacking and loss through poor accounting.
Bitcoin’s brilliant design for issuance governance may have obscured a complete lack of protection for end-point governance.
How can a user trust a person to protect his or her value?
This is not a new problem for finance. It is called the “agency problem” in reference to the fact that an agent acts for the user as a trusted intermediary. Institutions in the finance space have been dealing with the issue of trusted intermediaries for millennia. This field is broadly called “governance” and has many well known methods for achieving accountability and reliability for fiduciary institutions.
Drawing from “Financial Cryptography in Seven Layers,” Governance includes the following techniques:
- Escrow of value with trusted third parties. For example, funds underlying a dollar currency would be placed in a bank account.
- Separation of powers: routine management from value creation, authentication from accounting, systems from marketing.
- Dispute resolution procedures such as mediation, arbitration, ombudsman, judiciary, and force.
- Use of third parties for some part of the protocol, such as creation of value within a closed system.
- Auditing techniques that permit external monitoring of performance and assets.
- Reports generation to keep information flowing to interested parties. For example, user-driven display of the reserved funds against which a currency is backed.
As technologists, we strive to make the protocols that we build as secure and self-sustaining as possible; our art is expressed in pushing problem resolution into the lower layers. This is an ideal, however, to which we can only aspire; there will always be some value somewhere that must be protected by non-protocol means.
Our task is made easier if we recognise the existence of this gap in the technological armoury, and seek to fill it with the tools of Governance. The design of a system is often ultimately expressed in a compromise between Governance and the lower layers: what we can do in the lower layers, we do; and what we cannot is cleaned up in Governance.
The question then is how to bring those practices into a digital accounting and payment system.
To address this weakness of customer escrowed funds, back in the late 1990’s we developed a governance technique for digital currency that we called the “Five Parties Governance Model.” (This model was built into the digital currency platform that we designed for exchange, called “Ricardo”.)
The five parties model shares the responsibility and roles for protection of value amongst five distinct parties involved in the transactions. Although originally designed to protect an entire digital issuance, a problem that Bitcoin addressed with its public blockchain and its absence of an asset redemption contract, this technique can be broadly applied to many problems such as that which has brought MtGox down.
The Five Parties Model (5PM)
In terms of a cryptocurrency issuance with a single issuer (Ricardo model), the Five Parties Model looks like this (Figure 1).
Issuer. The Issuer is the institution guaranteeing the contract with the User. This is the person or entity ultimately responsible for the assets and whether the governance succeeds or fails.
In the present case, MtGox is the contractual party that is guaranteeing to deliver an exchange of value, and in the mean time keep those values secure. In Ricardo the Issuer is the party who defines and offers the contract for a particular issuance, which contract creates the rules that govern the five parties.
As can be seen from the following screen capture taken from the Internet Archive, MtGox did in fact have a contract with the users to fully reserve their internal Bitcoin and currency accounts:
However, as an Issuer, MtGox appears to have failed to implement internal controls to put the other four parties into place.
Trustee. In a digital value scenario, there is always a Trustee role that controls creation or release of long-term funds. For MtGox, this Trustee might be the person who signs off on outgoing wires and outgoing Bitcoin payments, or it might be the person who creates or deletes the derivative monetary units (BTC,LTC,EUR,USD,etc) inside the exchange’s books.
For a cryptocurrency that contracts to an underlying asset, the Trustee’s account, sometimes known as the Mint account, is the only one that has the ability to create or destroy digital units of value, as that underlying asset pool increases or decreases. For a cryptocurrency without a contractual underlying, the protocol itself can stand in the person’s stead by employing an algorithm such as Bitcoin’s mining rewards program.
Manager. The manager is the person or entity, usually an employee of the Issuer, who asks the Trustee to perform the big controlled operations: create or destroy digital assets, or deposit or withdraw physical ones, in order to reflect the overall pattern of trading activities.
The Manager typically works on a daily trading basis. As funds come in and go out, some of these request match each other. For a perfect balance, nothing needs to be done, but normally there is an overall flow in one direction or another. As trading balances build up or draw down, the Manager asks the Trustee to authorise the conversion of daily trading assets against the long-term reserves.
In the MtGox context, when BTC is flowing out and cash is flowing in, the Manager would ask the Trustee to release the BTC from the cold wallets, and would deliver cash into the long-term sweep accounts held at bank under the Trustee’s control. The Trustee would control that action by looking at the single transfer into the sweep account to confirm the transaction is backed by assets.
In the context of an issuance of digital gold, the Manager might receive an inflow of a 1kg physical bar. The Manager must bail the physical gold into the vault, and present the receipt to the Trustee. With that receipt in hand, and any other checks desired, the Trustee can now release 1kg of freshly-minted digital gold to the Manager’s Account.
The Manager is in this way guarded by the Trustee, but it works the other way as well. In a well-governed system, the Trustee can only direct value to be sent to the Manager. In this way, the Trustee cannot steal the value under trust, without conspiring with the Manager; a well-run business will keep these two parties at a distance and bound to govern each other by various techniques such as professional conduct codes.
For example, Ricardo has an ability to lock the Mint’s account together with the Manager’s account in this fashion. Bitcoin lacks account-control features, but there is no reason that MtGox could not have implemented account-control for their internal Bitcoin accounts.
Operator / Escrow / Vault. For a cryptocurrency, the operator is the part of the business ensuring that the servers and the software are running and properly doing their job. By outsourcing this to a third party, we add another degree of separation of powers to the governance model.
In the case of Ricardo and similar contractually-controlled issuances, there is generally a single server cluster that maintains the accounts. The sysadmin for this server controls the accounts and ensures that no phantom accounts or transactions are let in; software designs assist by including techniques such as triple entry accounting, which guarantees that only original users can create signed instructions to transfer value with their private keys.
For the physical side of a digital issuance such as gold, a vault fills the operator role. In the case of GoldMoney.com the vault operator is ViaMat. They don’t do anything with the client’s gold unless they receive a signed instruction from the Trustee. They just keep thieves from physically stealing it.
Bitcoin is very different in this respect in that it creates the public blockchain as the accounting mechanism. In this case, the operator role is not outsourced to one party, rather it is spread across the miners, the software and the development team, presenting a very strong governance equation over operator malfeasance.
For a business such as MtGox, the operators or escrows are two-fold. On the one part is the bank providing accounts, and especially the primary account holding long term cash reserves. On the other part, as an exchange provider, is the set of cold wallets holding long term BTC.
The Fifth Party - The Public as Auditor. The final and most important element of the Five Parties Model is the role of the Public as auditor.
Typically, the role of audit is to examine the books to validate that the other parties are indeed doing their job. As is covered elsewhere (Audit), paid auditors have a long-term conflict of interest, which has been at the root of several notable disasters in the last decade - the failure of Enron, the wholesale bankruptcy of banking in 2007 financial crisis, the collapse of AIG, none of which auditors rang the bell for.
Auditors, as well as being conflicted, are also expensive, which leads to the search for alternates. Once we have mined the cryptographic techniques available to us, we are still left with a set of things we cannot control so easily. What then?
Introducing you, the user, or the Public. You do not have a conflict of interest, in that it is your value at risk, and you have a strong interest in seeing that the other four parties are doing their job properly. Which then begs the question of how you, the public, can audit anything, when audit almost by definition means seeing that which cannot be seen?
The answer is to make that which was previously unseen, seen. Some examples of digital currencies that have supported audit by you the Public include:
- e-gold.com published a real time balance sheet of their digital issuance.
- Goldmoney.com publishes their physical gold as held by their vault operators, and auditors publish the monthly report.
- Bitcoin publishes the blockchain.
- Ricardo publishes the balances of the Trustee and Manager accounts.
Two-Sided Variation on the Five Parties Model
The Five Parties Model is just and exactly that - a model. Which means there are variations and limitations, and a business must modify it to suit. For example, many businesses in the space have not one but two bases of value to control: an underlying asset and a digital issuance. Bitcoin Exchanges fall into this category, for example.
When an Issuer is backing the digital currency with a reserve asset, both of these assets need to be protected. To do this, we utilise two instances of the Five Parties Model in a mirrored pair. In each, the Issuer and the Public act as parties on both sides, whereas the Trustee, the Operator and the Manager may be duplicated (or not). Figure 3 shows an arrangement where a single Manager works with mirrored Operators and Trustees.
An exchange such as MtGox would have had an even more complicated regime. For every one of their assets - BTC, Altcoins, USD, EUR, JPY, etc, they would have needed to delegate operators, trustees and managers. We as users expect they did that, which then leaves us with a question -- what went wrong?
MtGox Failed Because Nobody Was Watching Them
We can now measure MtGox against the governance picture drawn above. Although originally developed for an issuance, the model applies wherever there is an important asset to protect.
As a business, the role of Issuer is relatively easy to identify - the company MtGox itself. Their terms and conditions constituted a clear contract between themselves and the users, where MtGox would hold the user’s Bitcoin assets in reserve.
Likewise, the Operator for cash is clear: the banks holding the long-term value are presumably identifiable via incoming and outgoing wires. MtGox had transactions going in and out for some time, so Managers are in evidence. The Operator for the long-term BTC cold wallets is the Bitcoin network itself.
What about Trustees? Although MtGox has repeatedly placed blame on their in-house operations team for various hacks and bugs, it is rather more likely that they fell short on the appointment and management of Trustees.
Somehow, the Management created for themselves 744,408 BTC on their internal books against an underlying reserve of only 2,000 actual Bitcoins, which should have been an obvious disaster to all. If this is the case, this suggests that no Trustees were appointed at all, and Managers were essentially uncontrolled.
Finally, the Public as auditor is not in evidence. MtGox on their website did not show the balances of any of their major asset classes, nor provide any easy way to ensure that their parties are doing their job.
Ideally, MtGox would have displayed a balance sheet with references to cold wallets on one side, and their internal Bitcoin/Altcoin balances on the other side. The former is checkable via the blockchain, the latter could be made available by the operator, and periodically audited to ensure the code providing the balance query was accurate.
With this information, you the Public as individuals or as media or other observers can verify that things are as they should be, and if not, sound the alarm! That’s what Twitter is for, that’s what sites such as DGCMagazine.com, CoinDesk.com and BitcoinMagazine are for.
Under such circumstances failure might be expected and indeed may be inevitable. As MtGox did not have a sufficient governance model in place, we might have been disconcerted to learn that more than $300 million worth of Bitcoin managed to disappear, but we should also be aware that we may ultimately blame our own failure to insist on good governance.
What other players in the Bitcoin world will fall for the same lack of care? You, the fifth party, the auditing Public would be well advised to review all of your Bitcoin partners to see what forms of governance they use, and to choose wisely. It is your value at risk, and demanding quality governance such as is outlined above is your right.