Trust No One: Giving institutions full control over their data

Welcome to METACO TALKS – Live conversations with the people operating at the frontier of crypto innovation: entrepreneurs, bankers, investors, fund administrators, traders, analysts and other crypto and digital asset market participants. Our objective is to help the broader ecosystem navigate this complex environment and unlock the market opportunity.

This event is hosted by METACO – the leading provider of security-critical infrastructure enabling financial institutions to enter the digital asset ecosystem.

Our guest for this episode is Peter DeMeo, Global Lead at IBM Crypto Asset Solutions for institutional custody, exchange wallets, and tokenization which require advanced secure private key management. Peter is responsible for market development, technology roadmaps, and building sales and services infrastructure.

On the show, we discussed about the cutting-edge IBM infrastructure that allows institutions to retain full privacy and control of their data, from confidential computing capabilities to ‘Keep Your Own Key’ (KYOK) encryption, which allows financial institutions to retain sole access to their crypto keys, meaning by engineering design, IBM does not have access to clients’ keys.

Disclaimer: This is not investment advice.

Full transcript

[00:00:52] The cutting-edge IBM infrastructure

[00:10:51] Confidential computing capabilities

[00:21:49] Operational assurance vs technical insurance

[00:31:31] What banks underestimate when building a digital asset stack

 

Seamus: [00:00:00] Welcome to Metaco Talks. I’m Seamus Donoghue, the VP of Strategic Alliances at Metaco. If it’s the first time you’re joining METACO Talks, it is a bi-weekly podcast where we invite thought leaders in the digital space to discuss their operations, current events, and the opportunities in an exponential future.

Today’s topic is giving institutions full control over the data. To discuss this, we’re joined by Peter DeMeo, the Head of Digital Asset Infrastructure, IBM systems. He globally leads IBM systems, crypto asset solutions for institutional custody, exchange wallets and tokenization – which requires advanced, secure, private key management. He’s responsible for market development, technology roadmaps and building sales and service infrastructure.

Welcome, Peter.

Peter: Thank you very much. I feel like a startup inside the big blue!

Seamus: Well, that’s a good place to start. The big blue has been around since 1911, so 110 years. It is not necessarily a startup in terms of age, but clearly what you do is probably in that context is a very new, modern thing. It will great to hear how you got into digital assets and also this journey with IBM.

Peter: Sure, thank you. First thing I want to say is that this is not a talk about Hyperledger fabric! Most people associate IBM and blockchain with our Hyperledger fabric and permissioned blockchains and things like that.

That all started back in 2016. I personally got into the permissioned blockchain space also in about 2017. Then towards the end of 2017 with all the ICOs and everything else, I’m like, digital assets seems it’s a lot more exciting than permissioned blockchains and supply chain and tracking flowers and whatever; this ICO stuff’s kind of fun. I didn’t do any of it because I wasn’t really understanding a whole lot at the time, but it was really fascinating.

In the beginning of 2018, I started to pay attention to all of those exchange hacks. It was funny, just leading up to this talk, I was reminded that the thing that got me into this is the thing that keeps me into this. There was an article recently, Tuesday, if you remember the New Zealand crypto exchange called Cryptopia, 1.5 million people that were using that exchange – it was hacked and everyone lost their money. The same story you hear all the time. But what’s really interesting to hear was that prior to the collapse, if you like, one of the staffers persuaded the Cryptopia management to discuss security related matters, and essentially enabled that person to ultimately get access to the private key of wallets. As we know, there’s an omnibus model at exchanges. If you have the key high enough in the hierarchy, you’ve got everything right. Sure enough, that person made unauthorized copies and put it on a USB device and went home and did some damage.

This story has happened so many times. We hear a lot about North Korea or others hacking these exchanges and so forth, but I think the insider threat is something that a lot of folks maybe don’t pay a lot of attention to. That’s really where my interest in all this came in.

IBM of course is a big company, and we deal with regulated institutions. When you’re talking about keys, in a traditional regulated institution keys are just something you use to process stuff when it’s no big deal. But in digital assets, and especially crypto, blockchain native, the keys are the money. All of a sudden you’re using traditional technology to store money, versus how it would be done in a regular fiat based world.

Amazon is the world’s largest vault, if you will. There are more funds on Amazon, I dare say, than anywhere else in the world, all in. Yet most of that is quite frankly vulnerable. I’m not taking a dig at Amazon here, but I’m just saying on any public cloud, it’s sitting on infrastructure that someone else owns, someone else maintains. You have no idea how that is being maintained. You just have to hope, and that’s where my interests lie.

IBM, we have technology that introduces this notion of technical assurance. I’ll talk a little bit more about this later on. But generally this, technology prevents you from being evil. We just assume everybody’s evil. How can IBM technology make a difference in this digital assets space? By protecting databases, by protecting wallets, by protecting processing information, obviously private keys and things of that nature – in a way where others who are not supposed to have access, just can’t get it. How do we avoid creating honeypots of key material? Honeypots of funds essentially. We do all of these things.

In 2018, I realized we’re sitting on all this technology, we’re not really using it for this. I made a pitch to the General Manager of The IBM Systems Mainframe Organization, Ross Morey. I was given a slot by the Head of Research who was taking a bet on me, Donna Dillenberger. She said, “You can take my slot at his briefing. Go in there and pitch that you can get FinTech startups to buy mainframes,” to protect Bitcoin on a crypto exchange.

Well, I was fortunate because I was able to do that, and given license and resources to go build a business inside of IBM Systems for the sole purpose of applying technology that we had and then helping to shape how that technology evolves, and new technologies, so that they can all come together to bring to bear our capabilities into digital asset, open finance – which is where I think we are headed.

Someone mentioned to me yesterday in the meeting we were having, when we think about where financial services is going, it just means more keys, more private keys. It’s not going the other direction. If you can’t look after the basic fundamental thing of a private key, then you’re going to have a hard time making it in this next generation that’s coming.

IBM, I think we’re very fortunate that this big company, at least took notice and said: we can invest one or two people and see what happens; if they are onto something then we’ll support them, if they’re not they can go look for a new job. That’s basically how I got started in 2018. Then 2018, 2019, 2020, here we are halfway through 2021 and a lot of things have really evolved. I’m happy to say we have had quite a bit of success here. I think the most important success is that when it comes to these large banking institutions that are already IBM clients, at least, because of our brand, I can get the meeting. I can at least have a conversation with them, and we talk about key management. It’s like, yep, they get it, I get it. We can have that talk and see where things go.

On top of that, we made a conscious decision that we would never compete with our clients. Whilst yes, we can build a custody solution from scratch – we certainly have the expertise to do that – we choose not to. We want to work with companies like METACO, who bring the thought leadership, bring, if you will, the street cred to this market, and then support you in being able to be successful. Your success is our success, and that follows and we all grow together. I think it’s good, quite frankly, because we need these kinds of successes to really help the community, which is fairly conservative. What I mean by that, the regulated community, to understand that you can safely handle digital assets. You can safely operate against digital health. It’s a long way to go.

The biggest thing that I tell people when it comes to proposals is this: this represents a fundamental sea change of operations. It is a transformational change. When you adopt digital assets, you are moving from what you’ve been comfortable with for the last 50 years into something completely different. It’s not like getting some kind of point solution and bringing that in-house and doing a proof of concept and showing and impressing all your friends that you can do this. That’s not the point. In every one of these large institutions, you have a handful of people that “get it”. They have to have their own internal advocacy. They have to be able to, if you will, not sell the message, but also train and enable these other organization people to make sure that they’re able to actually deliver on how to safely operate with digital assets.

This is beyond custody and keys, of course. This is business processes, this is risk and compliance, this is tying into the existing backend systems like core banking systems, everything else/ That’s extremely hard to do. You’re going to need to have companies that can come in and help you do it all, and be successful not just in being able to prove to somebody that you can custody a private key, but rather how you can revolutionize this entire industry and provide access to financial services in ways that heretofore are not even possible in the traditional financial services world.

We have this vision of, we’re on this journey, we’re going to change the world one big financial solution after another. This is why we’re having this talk today. This is why I’m all geared up and passionate about this space, because I think we’re on a mission. We’re going to get.

Seamus: [00:10:51] Great share about the mission and the background. Why don’t we get a little bit into the meat of it? We often hear about things like confidential computing. I would say, my observation generally is the market doesn’t always think too deeply about security. It is kind of a good enough approach. When you go to a client, how do you differentiate what you can offer in this space versus a relatively crowded market in terms of, let’s say key management and the solutions in the market?

Peter: There’s a lot of different ways to look after keys. You have hardware secure enclaves to store the whole key in. you have, let’s go ahead and slice the key up using something called a sham or secret sharing, and then take these pieces and store them in different places, then bring them back together and just use it to sign a transaction. You even have something called multi-party computation, which basically is involving key shards. In this case, everybody has their own that gets generated locally, and they don’t have to come together in order to sign a transaction. It’s kind of like voodoo magic.

Any and all of these different ways are ways for people to securely sign a transaction, because as we all know, in a blockchain if someone else has access to your key material and they sign on your behalf, you’re not getting it back.

This presents, I think, a very challenging problem for confidential computing in general. Confidential computing is relatively new. It’s all moving towards something called zero trust architecture or zero trust infrastructure. Today, the public clouds all have their own variations and approaches to confidential computing. You have things like trusted execution environments, like Intel software guard extensions, Google has confidential VMs, you have nature enclaves over at AWS. At IBM you have something called Hyperprotect. Hyperprotect is built on Linux-only versions of mainframes, called Linux 1’s. That’s all they do, just Linux. T these are just different ways to get to the same place.

Most confidential computing does a few things. It protects data at rest, it protects data in flight, and then it protects data in use. If I have something I’m doing compute on it and I want to make sure no one else is doing compute on it, I need to figure out a way to protect it while computing. All of the leading confidential computing vendors out there support all three of these; and do it differently, different price points, et cetera. We go one step beyond that. We have, I would like to call it data across. We have the ability to protect data as well as business processes across platforms.

What I could do is just give you an illustration of that, if you don’t? Let’s do it. I’m going to share a slide. Let’s go through an example of what I mean when I say sharing across. Let me know if you can see the slide.

This is going to be a business process flow. We’re going to say, we’re going to go ahead and design it around how do you approve let’s say a digital asset custody transaction? We have somebody that’s responsible for defining what we call a policy. With that policy, we can pull in existing rule sets and workflows to build upon it. We can say: who’s authorized to do what as relates to this workflow? We can bring in various pricing Oracles and other sources of data. We can integrate it into any money laundering solutions as well. We can go ahead and have it define with each group, let’s say a large institution, compliance, risk operations, they maybe have their own bespoke rules that they want to implement, maybe they’ll operate in quorums when it comes to doing authorizations. Finally, you need to tie all this stuff; as I mentioned earlier, it’s just like backend systems. You have to integrate all of these things.

Then this business process flow itself has to be audited and non-repeatable. Today you have solutions out there, rules, engines and things like that, that will allow you to do that. A lot of times they’re somewhat working with just one solution; other times they’re going across solutions. Data across for us is the ability to ensure that a business workflow like this is also subject to confidential computing. I’ll show you why that’s important.

Let’s just say that that business workflow is running in some kind of commodity system out there on some public cloud, doesn’t really matter which. There’s a system administrator for that cloud that has a responsibility to maintain the infrastructure that that policy is running on, that policy engine. What happens if you have an evil administrator also working at the same public cloud, or perhaps someone that works at the company that is responsible for the rules engine itself? Either way, sends an email to their good friend, the system administrator. Of course they’re going to open that email, because they’re good friends, right? Why wouldn’t you. In doing so, let’s say that it had some malware in there and now we have what’s called a system takeover event.

The evil administrator now has the credentials in order to run commands on behalf of the system administrator. Now, in this case, the system administrator has no idea. But when the evil administrator runs this command, which is a Docker permission escalation exploit, the evil administrator now has the same capabilities as the system administrator. In a sense, they have access to the keys, so they can then do stuff. Well, what they can do is go ahead and get access to that business process.

With that access – going back to this process – what happens now, if the person who’s responsible for defining and operating that business process flow is evil, what things can they do? Well, they can go ahead and they can change who’s involved, who’s authorized. In terms of the approvers, they can reduce them from the quorums to maybe just the person themselves. All of these things are really bad, because you have the ability to change the policy, because you have access. You’re evil, and malware and all that kind of stuff.

What can we do as a way to prevent that from occurring?

One thing we can do is take this workflow, this, this policy, we can set it in stone. We can set it in stone, so that way it cannot be changed. That will go ahead. provide the ability to separate controls. The people that maintain the policy are not the ones who then execute the policy. If you want to make a change, you have to basically redo it because that policy is now code. The policy is a binary image.

We’ve solved the problem, right? Maybe not. Because, what if the evil person is the person actually deploying the policy as code? Then what? Now you’ve got another problem. You’ve put a back door into this image, and now no one has any idea because it’s just a bunch of 0’s and 1’s. You could build it with a backdoor, or later on, depending on where you deploy it, you could swap it out.

You’ve got two problems you have to deal with. I think this is where confidential computing comes in. How do you solve for this? Let’s take the second problem first and the first problem second, because we’re IBM and that’s how we operate!

If I want to prevent somebody from swapping out that image, that compliance as code, what can I do? I can put it into a confidential computing enclave. At IBM, this is called a Hyperprotect virtual server. Again, this is where the differentiation appears, but you can do this on it any of the major clouds. Where we are slightly different is that in our enclaves, they’re designed with technical assurance, meaning that administrators do not even have a command line, do not have a secure shell. They have no ability to get in there and do stuff. They can’t swap it out. There’s no access to memory, no access to the operating system, the processor state. Even if you try to dump the memory, it’s all encrypted; you don’t have access to it. From a development perspective, you don’t have to do anything special. It’s just Linux, you just deploy into that environment and IBM takes care of the rest.

This is how we solve the problem of, if you put it someplace where nobody can change it, how do you solve the problem to ensure that originally there was no backdoor put into that image? Let’s take a look at that. The first problem, we solve with something we call a secure build server. This is unique to IBM, no one else can do this. The reason for that is that we can build any kind of sized application stack in one of these enclaves because there’s 16 terabytes in size.

Now, you use a signing key. Let’s say the bank, because this is about the bank controlling their own data, for example. The bank has a signing key. They own it. They can verifiably sign any image. Anybody can do that, that’s nothing special. But if the bank wanted to prove to a regulator exactly what was in that image – because what we’re talking about is deploying code that operates against funds, so it does matter if you want to prove to a regulator that in fact there is no backdoor, that you are deploying what you think you are deploying, we have this thing called a manifest. That’s that little green thing in the middle of the enclave. The manifest is all the executables that are part of that application that’s being built. That manifest is where technical assurance comes in. It is now available to an auditor, your regulator, whomever. They will go ahead, review it, sign off, then it gets pushed to the place where it can’t be changed.

This is how confidential computing ensures that applications, databases, wallets, and even business processes are hardened. Therefore, the ability for insiders to act is significantly reduced. This is where IBM, I believe contributes to this industry the most.

Seamus: [00:21:49] Maybe just to emphasize, I think a lot of firms will promise operational assurance. You’re talking about technical insurance. What are the key differences of that?

Peter: That’s a great question. Let’s do that in the context of key management as well. When you say operational assurance, you mean you have policies and procedures in place to make sure that bad people don’t do bad things. I should say bad people, because our perspective is that all administrators can be corrupted. You’re talking vast sums of money, and people who have access to it who are not usually well-paid. Guess what, there’s a built-in incentive here, folks, so just understand what you’re facing.

You want an ability to get away from operations. You don’t want to rely on goodwill. You want technology to get in the way. We saw that if you deploy your applications in Hypertech virtual servers, if you use this secure build server, you have technical assurance to ensure that your applications, your databases, your wallets, and your policies are not going to get messed up even when you deploy them.

That leaves us with one other area that we should probably talk about. That is the private key. How can a bank control the private key in a way that’s technically assured? Let’s think about how you might be able to do that. I’ll just share one more slide if you don’t mind.

This is how we do key management a little bit differently than most. In IBM, a little history lesson, we invented something called the hardware security module (HSM). That was done because we invented the automated teller machine, where you go and you type in a pin code from a card with a magnetic strip that we invented, that allows you to get money out of the automated teller machine. We created the entire thing. What we realized back in the 1970s when we did, is that you’re going to have billions of these pin codes – are you going to put them in this little thing called a hardware security module? Answer, no, you’re not. What you’re going to do is you’re going to design this thing in a way that you don’t have to do that.

What we did was we designed it in a way that you store one key. That’s something called a master key. In this slide here, you see it’s a blue key.

Before I talk about how we use that, let me talk to you about how we get it there. That blue key is what’s called technically assured. If anybody tries to get access to that, I will soon as show you what can happen. Generally speaking, it’s not good. But it’s a little bit of James Bond technology. The master key, therefore is not extractable. IBM administrators in the cloud, your system, administrators on premise do not have access to it. Guaranteed. This is another thing that we can say. It’s been rated as the highest commercially available hardware security module on the market today. Fifth 140_2 Level 4, and soon Fifth 140_3 Level 4.

In order the blue key into the domain of the hardware security module, we have these things in my hand, which are also part of our hardware security modules. These are smart card hardware security modules. What you do, you take one of these and you generate a number, a random number. You have a true random number generator. Then you basically transfer that number and it gets assembled into that blue master key. We put it together as the summation of the numbers that we got from these smart cards that we have in a ceremony. This is where the technical assurance comes in. As you know it from METACO and your banks, they’re the ones that actually own these smart cards. METACO has the ability now, to say we have no access to your keys, because they’re the ones that own the smart cards.

When they create the master key, the next thing we do with it is something called external envelope encryption. That’s a triple E. All it really means is this: I have my master key which never leaves, I generate some Bitcoin seed or other, then we literally wrap it. We envelope wrap it, if you will. We transfer that into what’s called a secure key AES 256-bit secure key. From there we store it in something called a cryptogram, which does additional things like encrypt metadata, and that’s where it stays. The key material is designed to be stored outside of the HSM, which is different and therefore massively scale. One master key can generate and encrypt an infinite number of private keys. One. That’s pretty cool.

Let’s take a look at an example of how it works. Inside the secure element of HSM, we wrap it, we then transfer it into a cryptogram and we push that in something we call nearline stuff. Nearline storage is another concept from the 1970s. it basically means the data is an inaccessible state and stays there until you need it, and you can get it without having humans. I say that because when we think about cold storage, cold storage involves humans. That’s the whole point. We’ve got something offline, we need to bring it online, usually there’s a human involved. Where there’s humans, there’s internal tech vectors.

If you can get the signing done through policy, like we talked about, that hardened policy, and you don’t need humans, you can reduce the number of opportunities to have an attack from an insider. That’s what we do with this nearline storage concept.

Another thing that’s cool about it is, if the bank is using a custody platform, like METACO, if the bank ever wants to prevent access by the custody plan, all they have to do is zero out that master key and now access is frozen.

Increasingly, and Seamus I think you know this, we see, especially with the Harmonize product, the ability to orchestrate across multiple custody platforms. The ability then to use this master key concept to provide ultimate control to the bank becomes very helpful, because if every one of the custody platforms has been generating their key material and signing using the master key, all you have to do when it comes time to switch from one to another is to simply rewrap the wallets with the new master key and then zero out the old one. Now you have transferred assets from one provider to the other, without having to go on chain, without having to introduce counterparty risk, and without having to pay anything – which is quite useful.

This is how IBM’s technology can be used to facilitate essentially a trend, which ultimately is a multi-platform capability. The big banks, they want to reduce the risk. They’ve got all the risks and yet they don’t own the assets. If they’re going to go ahead and do that with multiple providers in case something goes wrong, then it’s a good way to give them control and retain control over all of them. They can do that with these smart cards.

I’ll close by saying one little thing that seals the deal for us. When it comes time to protecting the key material, what we do is we protect the master. We are certified by NIST for any one of these attack vectors. This is legit. If I have an electromagnetic attack, a voltage attack, a drilling attack, an x-ray proton beam attack; in a hundred nanoseconds that key is zero out, effectively putting everything that was encrypted by that master key as frozen. You don’t lose it, it’s just frozen. 100%, nobody is going to get your keys.

If you need to redo it, you just simply get another domain, get your smart cards out, and you have a ceremony and reestablish that, and you’re back in business. There you have it. This is how IBM provides technical assurance to keys, technical assurance to business processes, technical assurance to applications, technical assurance to databases; and does so in a way that events insiders from being successful in their attacks. We believe institutions that are regulated require this level of protection.

Seamus: [00:31:31] I think it’s a strong message, giving clients control and eliminating the need to trust. It’s very powerful in this context. There are a lot of other questions I have, we’re running a little bit short on time. I want to talk about the keep your own keys, the bring your own seed concept; but we’ll have to save that for another time.

I’d like to wrap it up, you talk a lot of institutions. In closing, the banks or larger institutions that are building in this space, where did they get wrong? Or what did they underestimate once they started the journey to build a digital asset stack?

Peter: That’s a great question. What they think they can do is contract with a FinTech company and the job is done. Most FinTech companies, unfortunately, really don’t have a good understanding of what it’s like to deal with a regulator. While you have their best shot from a policy perspective, how you can operate, do compliance, KYC, et cetera; when you are facing the regulator, they ask a lot of hard questions. All of the custodians that became in the US national banks through the OCC – and we know this firsthand because we work with them – they all learn this, that it’s a lot harder than you think. Certainly, the FinTechs have a lot to learn when they start to become banks and regulated institutions themselves. But the regulated institutions on the other hand, coming from the other direction, certainly understand what it’s like to deal with regulators, but they just have no way of translating those obligations into this new tech, because they don’t even understand it. Even those that do understand it, it’s like you’re dealing with out of the box appliances. How do you change the tech so that it conforms with what the regulators are requiring, so that we can do business?

The good story there is a lot of this is starting to happen. Just recently we saw in DeFi, the lending platform, AVI, are they pro? Even these DeFi platforms (decentralized, no way regulators can touch me), they realized you can’t stick your head in the sand forever. You have to come out and you have to deal with regulation. You have to deal with regulators. You have got to create products that can do KYC and AML. AVI, for example, is teeing up are they pro – which essentially is a pre-KYC way to interact with that platform, creating a walled garden approach or whatever. But institutional DeFi itself is coming.

A lot of the big banks don’t have yet, depending on the jurisdiction, authority to deal with cryptocurrencies. But cryptocurrencies are only part of the spectrum. In the middle of the spectrum, you have tokenized assets, that are stocks, bonds, corporate bonds. There’s plenty of use cases, at least in the corporate bond type of thing. Then of course, there’s digital securities on the far other end of the spectrum, which definitely blockchain, native assets is maybe sometime in the future.

Right now, the closest I’d say to a digital security is a fractional NFT, which I think very few people understand actually is that. We’ll see where the regulators come. But ultimately if you’re in an institution that is regulated, you’ve got to figure out how to deal with all this stuff. You’re going to need technology, and you’re going to need thoughtfulness, and you’re going to need advisory, and you’re going to need companies like IBM, but frankly, they bring all this stuff together and enable you as a regulated institution to get onto this journey. As I mentioned before, it is transformational change journey going from today’s operations, to bring in these FinTechs, but in a way that is compliant and works.

This is why IBM is still relevant to this space, because we understand the regulated world. That’s what we do. We work with FinTechs, like yourselves, to be coming together and to provide that whole new operating experience for these large banks, as well as some of the FinTech custodians that are becoming banks. it’s really interesting.

Seamus: [00:36:03] Well, I think we’re out of time. Peter, thanks. That’s a great way to sum it up or wrap it up. I would say, the good thing is that these are recorded and if people want to go back, there’s a lot of granular, a lot of detail, if they want to dig into it again. The recordings are on our website and all the major podcast platforms that could do that.

Thanks again for joining us, Peter. We’ll have you back again to go into more detail. The rest of you, everybody else, see you in two weeks. Thanks for joining!

Peter: Thank you.