HashiCorp Vault for Crypto-Agility

The Spanish financial services company Banco Santander is doing research into cryptocurrency and blockchain. While there are a lot of buzzwords in the industry like crypto-agility, Przemyslaw Siemion and Pedro Garcia show how they actually got agile with cryptography using HashiCorp Vault.

Speakers: Przemyslaw Siemion, Pedro Garcia

»Transcript

Przemyslaw Siemion:

Welcome to our presentation at HashiConf Europe. We are presenting the research lab of crypto and blockchain of Banco Santander. 

We want to talk about the buzzword crypto-agility, the problem behind this buzzword, and the solutions that people in the industry are seeking. We want to show you one specific example. 

Let's look at the agenda of the talk. First, we want to explain why we're here, guys from a bank, talking about secret-management technologies. We want to tackle the buzzword — crypto-agility — and identify the problem. And we want to look at a very specific, tiny,tangible example of the problem and demonstrate how you can solve it using software like HashiCorp Vault. 

This is something we did last year.  Together with HashiCorp engineers, we created a couple of plugins., That was a great experience, but it's a portal to a new dimension of problems. Let's treat this as a little fragment of a whole new category of problems that we need to face.

»Why Blockchain?

First of all, why are people from a bank here talking about this? The reason is blockchain technology has been around for over ten years. Even the first iteration —software hacked away in a garage — has accumulated value, has sustained relentless attacks on the open internet — and has proved sustainable. Even not mentioning the market cap of things like Bitcoin and Ethereum, that together are around a trillion dollars, just the fact that you can use the internet as your ledger if you combine cryptographic engineering with human engineering — if you incentivize properly — is amazing. This, of course, was not going to go unnoticed.

So for ten years, people all over have been waking up to this new reality. You have both commercial and institutional banks experimenting with this technology. This technology seems to be here to stay— like the internet has proven not to be a fad. But now it brings for us a raft of problems that we need to tackle. And, of course, where you have a problem, you have potential solutions. So, we observe a new breed of software that tries to mitigate the gap.

»Santander’s Blockchain Engagement

Santander has been serious about blockchain technology. I should mention that in 2019, we issued $20 million bonds using Ethereum — completely legal bonds denominated in USD. Quite recently, we facilitated — together with Goldman Sachs and Societe Generale — an issuance to the tune of 100 million Euros by the European Investment Bank. And you can imagine that this is the tip of the iceberg. If we can pull those things off, there is a lot of work under the surface that we possibly can't speak about. There is nothing showy, but there is a lot of work going on. That's why we're here.

»The Great Mismatch

Blockchain seems to be serious. Santander is serious about blockchain. What's the problem then? The problem is the mismatch between the creativity and open-mindedness of — let's call them crypto banks that created blockchain — and the noble conservatism of cybersecurity. 

When you look at that, on the right-hand side, you have the crypto rebels, the originators of blockchain that continue to innovate and continue to come up with new ideas. They are using elliptic curve cryptography, but in the most innovative ways. They say, “let's use Schnorr signatures, instead of ECDSA signatures. Let's use the ECDSA signatures, but let us handle them differently or let us use multi-party computing — this is the flavor of the month in the crypto exchanges world. Or let us use zero-knowledge proofs, so that the balances are not really exposed on a chain.”  

Then when you talk about those things to any real professional in cybersecurity, their reaction's going to be, "Don’t!." Because their questions would be, "But is it FIPS compliant? And is it happening in a secure place? What is the perimeter security?"

To get an idea, the process of cryptographic technology getting certified and approved and accepted tales anywhere from 6 to 12 years — looking at RSA, looking at ECDSA. And eventually, on top of that, the very distributed nature of blockchain is a bit of a nightmare — or at least is a new challenge — because blockchain by design — those technologies are to be spread across the globe, to be distributed, to be shared. 

While one of the pillars of cybersecurity is that I execute my cryptographic operations preferably in an HSM — which is like a steel box that nobody has access to and if you try to x-ray it, it explodes. So, we have this mismatch. You need the glue, you need something to connect those worlds. And this is where a new breed of software is showing up. 

This is a big topic: the whole aspect of delivery across geographies, locations, and clouds begs for a whole presentation itself. Let us focus on a very specific problem of signing Ethereum transactions, though, so that we see a real problem and a real solution. We see how software, like HashiCorp Vault, can help you solve problems that you have on hand. 

»Ethereum Transactions

Let us look at the Ethereum transaction. The Ethereum asset is like Bitcoin Ethereum is controlled by a private key. And the shadow of the private key — the hash of the public key — is imprinted onto the asset. When you want to manipulate the asset, you're sending a command, — called a, transaction for some reason — then you sign it with a private key. But now it goes to the blockchain and blockchain needs to verify the validity of the signature. In the normal world, when we sign some electronic document, we go to a registry of public keys. And we verify if, indeed, the public key of somebody who claimed to have signed it matches, creates the signature that is on the document.

Now in blockchain, you don't have a public key registry, so the philosophy is different. Well, what Ethereum does‚— what Bitcoin does — is it takes the transaction, it takes the signature, and tries to recreate the public key from the signature.  Which is almost possible. And from this public key, it recreates the address and compares with the address that is on the asset. Verification is pseudo-anonymous and you go away without any public key registry. It is very clever and it does not work — at least not quite.

The reason is some specific features of an elliptic curve — ECDSA signatures. Any elliptic curve signature is basically a riddle and ECDSA is just one.  You have others, like Schnorr signatures. BLS signatures are getting popular. 

One specific thing about an ECDSA signature is that the riddle that you play a signature against is that you use the hash of the document and the public key and the numbers from the signature to get a point on the elliptic curve. And you take the x-coordinate of this point and you compare this x-coordinate to one of the original numbers. And if they match — if they are equal — you say, "Hey, the signature is correct, because coming up with a pair of numbers that would fit into this riddle and make it comply is next to impossible, unless you know the private key."

Alas, elliptic curves are symmetric. There is not just one point with this x-coordinate. For x-coordinates of a specific value — small r — you have two points. When you try to do elliptic curve ECDSA key recovery, you hit an ambiguity because you don't know which point you should use. Starting from the x-coordinate, I can identify point capital R and from this, I can build my public key and I'm good. But you don't know which of the two points are R prime.

»The Bitcoin/Etherium Solution

You could do trial and error, but blockchain is skimpy on computational resources. Instead, the originators of Bitcoin and by extension, Ethereum, came up with a different idea. They said, "To our signature — our transaction — let's add  a flag that says, take the upper R or take the lower r." It's the third parameter. It's the parameter V that you can see on the slide.

That's cute, but if you look at the standard issue signature that you can get from an HSM, it's missing. It's a new thing. HSMs cannot produce this for you, not yet, not all of them. The industry is playing catch up, of course,  but your generic HSM can't give you this format of a transaction. 

What happens now? Instead of HSMs, people use software to sign Ethereum transactions. This means private keys that control assets of potentially very high value are in memory. And because of the distributed nature of blockchain, also possibly in many places. That's bad. That's very insecure, and that's happening.

»The “Adapter” Solution

What could we do about this? Well, in principle — as you may have seen from the equations — if you know the public key, and if you have the signature, you are in a position to calculate whether V should be up or down.

It's possible to take the HSM, generic vanilla ECDSA signature, take the signer's public key, the message, and from this, you can calculate your capital R — the point on the elliptic curve. And you can verify if it's an up one or a down one, which allows you to calculate the V. On the algorithmic side, this is not very complicated if you know a little bit about elliptic curves. The problem is where to execute such code? 

»Pragmatically Speaking, What Do We Need?

What we really need is not only being smart enough to pull this trick off, but software that speaks to the HSMs, to get us the vanilla signature in a secure way without the private key leaving the HSM at any point. We need software that can collect the public keys in a smooth, permissioned manner. We need software that can execute our little piece of code in a secure way.

We need the software to allow us to operate on elliptic curve arithmetics. It needs to have great support in terms of libraries. And of course, it all needs to be wrapped in a consistent system of permissions and policies. If we had such software, and if we could embed our little piece of code in such software, that would be great, wouldn't it? 

It turns out HashiCorp Vault fits the bill very nicely. And I will hand over to Pedro to give you some details about our little plugin that solves exactly the problem described. Thank you.

Pedro Garcia:

Hello everyone. My name is Pedro Garcia, I'm part of Przemyslaw’s  research team. I will try to give you an overview of how our plugin looks on the inside. I will try to show you a couple of snippets of the code that we built inside HashiCorp Vault and you will see that the process that Przemyslaw has told you about is not a complex process if you know what you're looking for and what you're doing.

»Plugin Functionalities

First, let's get started at the beginning, which is the functionalities of our plugin. In this case, we have four functionalities —  all of them permissioned because all of them are only allowed for users. Each user has its own product key. For example, the first functionality is creating a private key. When that user has already created a private key, he can access the address that is like an alias in Ethereum that you are shown on the network with.

Second, whenever someone wants to send funds to you or to contact you through a smartphone, it needs to route your alias to know who to contact. Thirdly, our plugin is able to perform a signature in the standard ECDSA format. And the fourth thing is transforming this format to the Ethereum standard format. Let's get started, but first let's talk about the external libraries that we are using.

»Plugin Dependencies

In this case, for the cryptography handling, we are using a couple of external libraries. The first one would be the Bitcoin library for ECDSA handling, for the arithmetic. The second one would be the Ethereum library for handling the transactions — the hash; how the hash of the transaction is performed and all those things. We found this part pretty straightforward to implement, using HashiCorp Vault. That’s because with other key management that we have used in the past, when you need to get an external library, you cannot import it like you would do in a normal code — you need to build it yourself. But with HashiCorp Vault, this part was straightforward.

»Signing Process Demo

Let's get started with the code. When you want to perform the signing process the first thing that you need to do is gather all the information. In this case — as you can see — it's getting the public key as an X and Y coordinate, and also the hash of the transaction. As you can also see, we are using the external library from Ethereum to get the hash of this transaction because we're wrapping up the transaction and we are getting the hash following the same algorithm.

Once you have these two things, we can go for the next step. In this case, we have done a mock-up of how a natural HSM would perform the signature. This could be also done with an external HSM. But in this case, we wanted to keep the whole lifecycle inside HashiCorp Vault. We performed actually getting the key, signing the transaction in the code, and then converting it into an array of bytes. But, again, you can do it with an external HSM.

Once you have the signature in the standard ECDSA format, you can go to the next stepwhich is — first of all — extracting the RNS values from the signature. Once you have these RNS values, you need to also calculate the inverse of S because we will need it on the next and last step. That is where the actual magic happens, where we get these values that Przemyslaw told us about.

This last step is mainly performing the function that you see on this slide to calculate the R point. And in this case — when we already have this R point — you need to go for the Y-coordinate of the point and to get the first bit of it. And that is the value that we are looking for. There are a couple of steps, but none of them is very complex. They are some standard multiplication and additions to get the expected R point.

And to double check — I wanted to include both signature formats. You have seen the whole process. You can now probably understand much better the actual difference between them:. how the RNS values — which are in green and blue respectively in both of them — are the same — and how we need to calculate the V value. 

Probably you have realized that the V value is not zero or one, that is what I have said in the previous slide. This is because the Ethereum team decided that they wanted it to be 27 or 28 respectively, to V and to C  in hex. It doesn't matter if they get a zero or a one, they add up 27 from the plugin. And this would be the explanation of the actual plugin.

Przemyslaw Siemion:

What we have seen is an example of a glue code that finds its place in the framework that provides permissioning, policies, and proper deployment. And it solves one tiny problem between the blockchain world and the existing infrastructure.

Of course, you may say this is a stop gap because the HSM industry is catching up and those functionalities are getting onboarded. But the point here is that it's a neverending story. And the creativity on the blockchain side is I'd say an order of magnitude  greater than the appetite for the catch-up game in the HSM industry. So, we are going to need this kind of software for a good while, not to mention the aspect of distributing cryptographic services, which begs for another presentation. 

I hope you liked this. You may Google the code, it's all tangible, it's all accessible. Thank you very much.