Below is a transcription of a conversation between Alex Davies, CTO of Jump Trading Group, and Conor Patrick, CTO of Cordial Systems. Together Alex & Conor share their wisdom following extensive tenures working in both traditional financial markets and the emerging asset class of digital assets. Here are some of the questions and topics which are critical to evaluate for any financial institution looking to hold digital assets or cryptocurrencies as part of their business operations.
In the traditional business we don’t custody anything and we are dealing with trusted counterparties within relatively stable systems. Crypto is entirely unique and since we got into this new asset class early that necessitated building everything pretty much from scratch. In those early days we had a number of cryptocurrencies which quickly increased in value and suddenly there was a need to figure out how to secure these digital assets in a more scalable and fitting way. We have encountered a number of technical and operational challenges along the way - as have other financial institutions when getting setup in the crypto space - however the firm has been able to successfully navigate a path that works for the business and our risk teams. This has been a real journey in and of itself as there is no cross-pollination with our traditional business - the crypto business is a separate entity and we use almost nothing there that we would also use in our traditional business. Very different markets.
When trading the crypto markets you quickly become aware of the concept of a “private key”. That is the fundamental cryptographic material which you need to keep secret to avoid anyone moving cryptocurrencies on your behalf - whether by operational error or more malicious means. We were not in the business of high security, and the fundamental problem was in figuring out how to restrict access to sensitive systems and sensitive material in our cryptocurrency teams. There was never going to be a happy medium between the traditional and crypto business. So it was separated, which has complexity and downsides which wasn’t easy but definitely the right thing to do. Back then we were also using commercial SaaS solutions which ended up getting acquired out of the market, so there was a fire drill where we were given a short period of time to get off the platform and setup a new operating model pretty quickly.
First is to make the keys themselves difficult to walk off with. You don’t want to store them in memory, on a disk, or in some manner that can be easily accessed. Equally, you don’t want to go so far down that road that you end up with an ultra secure but ultimately unusable brick - the private key still needs to routinely perform signature operations, for us that’s at least hundreds of times per day. A common mistake, therefore, is to do something clever with the keys which make the keys impossible to obtain but then that might make the interface highly complicated or highly repetitive.
I’m a big believer of the idea that the human factors matter. It’s easy to build a system in this space that will fail because humans are presented with an impossible interface or presented with the same repetitive task 1,000 times a day with same output… if you do these things then a malicious transaction will eventually be signed, by human error for example. This is much harder to solve than a problem just thinking about private key safety as you are more in the detail and have to think about what you’re doing from a business point of view; rather than a theoretical cryptography stand point.
MPC is critical, it solves a bunch of problems but isn’t a silver bullet. If you have some sort of remote signer then MPC can help with keeping the key in multiple distributed shares, which is better than running the risk of a single piece of material in memory being lost and producing a devastating scenario of key loss. So you’re solving for a custody problem where a malicious transaction shows up, or some insider is trying to get hold of the key. A classic configuration, such as 3 machines with different key shares, is effective at stopping a single machine memory dump and making it harder for an attacker as they need to execute code and get things signed by those key shares. However, it is ineffective at stopping a system admin walking off with the keys. Making access to a machine difficult is irrelevant if a system admin can walk in to update the software, send something and get it signed.
Thats the missing bit with MPC - no business logic that stops you signing anything and in custody operations or trade settlements you need that. In other words, you could distribute your key across a 1,000 places and no one walks home with it but if you sign something bad then it’s game over. At some point the incremental benefit of splitting the key is 0 whereas on the business logic side you are approaching the maxim value of the key. My experience is it’s difficult to get that right, easy to do disproportionate security in one area that is not balanced or ignores another part of the problem.
Yes, you’re in a world where policies are essential. These should be part of your authentication and authorization. Authenticating a user’s identity and establishing whether they have the correct credentials to perform a certain action. Exact details are internal but fair to say many technologies exist that are much stronger than traditional username and password or normal corporate authentication. You need to be aware of the risk of malware on devices, also risk of being tricked where you are presented with a man-in-the-middle attack where they change what you see… we’ve done a good job managing this with Cordial Treasury.
Then you want rules around how assets move around, whether that be only to a small list of destination addresses, setting a maximum notional amount to send a particular counterparty, whether you want a 4-eyes or 6 eyes check and whatever else. It’s clear to see how this is valuable, however there is a big risk which is a bit more subtle. Namely that if a privileged actor on your side, or even your vendor if using a SaaS based solution, can change the policy at will then the whole thing is largely moot. So you need to figure out a way to distribute the policy engine. That way you do not rely on your system admin and you definitely should not rely on a vendor to host your policies and do this for you - you’re basically back to trusting them with the private key and to use it correctly.
The way that Cordial Treasury tackles this problem is the correct way - policies are distributed between secure machines on the customer side to remove both vendor threat and customer insider threat. There aren’t many options and even less which are suitable for Jump, particularly as we are high frequency. If doing a few transactions a day then the problem is easier, you can simply have a multi signature setup and do a 6 eyes checks. However, if you’re doing lots of transactions then that just doesn’t work, you need automation in the policy engine that can express business logic. Otherwise someone won’t notice the bad transaction in some wall of relatively small transactions… Cordial Treasury solves that problem well and is very important to our business.
Exactly. I would not recommend that. It’s not scalable. It might be ok for testnets or some new thing of low value however a browser wallet type of solution is just not suitable for this kind of long term storage or large amounts of assets within the enterprise setting.… the risks are significant. An enterprise offering needs to decouple identity away from the private key that controls the cryptocurrencies or digital asset of value. Typically that identity piece is authenticated with Webauthn. Also, if you’re running a large organisation then people come and go and there is a need to rotate things. If you’re a home user then you don’t need to worry about it, but institutions do. In industry we see variable security posture, some are hyper paranoid and some are storing private keys in AWS secret manager… we are trying to find the optimum rather than the extreme.
Don’t build it yourself, it’s a huge amount of work. There’s a range of services on the market and you'd be well advised to talk to them. My advice is if you are thinking about the private key then you will solve that problem, it’s easy to solve it. If you are talking about MPC and policies, then my advice on policies is to think about the human factors and developers in this system. Build what works for your users and devs, otherwise you haven’t solved the problem - you have security theatre doing something complicated, or even doing something weird. You can’t outsource that since by definition you need to know your own business and reverse engineer the solution from that.
I can only speak about our problem, we are at the extreme end of needing control and want to do things internally, we must have full visibility and trust no one. For some organisations these constraints may not be sensible or can be relaxed a bit. In that scenario you should be thinking how you can co-host the solution which doesn’t make you heavily dependent on the vendor like a simple co-signer solution would. Generally, I’m less excited about fully managed… the traditional finance ecosystem has that but crypto doesn’t and i'm excited to see growth in that area as the opportunity with keys is to allow innovation in this space to do better. I don’t know what the final version looks like but it will be a shame if 2 entities have 50% market share each and you just plug into their API.
