We sat down recently with our Head of Innovation, Dr Luke Riley, to ask him about the work our R&D team is doing to detect risks and, ultimately, improve blockchain for all users.
Why is key management integration important?
Many companies use cloud services to run their traditional web2 I.T. infrastructure; some even host their entire stack on a single cloud platform. However, if a company wants to incorporate blockchain technology, it may be limited to only adding new components on the same cloud platform. Many traditional cloud services are run on AWS, and as an AWS partner, we can assist companies in connecting their AWS cloud services to blockchain.
When connecting to blockchain systems, a key component is the security of the private keys used to sign transactions. Here at Quant, we do not manage the private keys of clients, and one possible way clients can securely manage their own private keys is to utilise AWS’s KMS. This is a FIPS 140-2 Level 2 security system, where private keys are generated in Hardware Security Models. These keys can never be taken out of the HSM, and for simplicity, these HSMs are hosted in AWS’s infrastructure. Note that we provide some clients with a higher level of security when required.
What AWS KMS integrations have you been working on recently?
Our most popular requests for AWS KMS integration have been for the Ethereum technology. We found this process to be smooth and easily modifiable for different EVM-based networks like Ethereum mainnet, Polygon mainnet, Avalanche c-chain, and XDC network.
Recently, we have been working on a project to perform the same integration for Substrate networks, such as Polkadot. This integration did not run as expected. While investigating why, we uncovered a bug related to blockchain accounts in Polkadotjs, which is Polkadot’s popular Javascript Software Development Kit.
What are blockchain accounts?
In a blockchain, all assets are assigned to an account. Each account contains an identifier (usually an address), a public key (a longer representation of the address) and a private key. The public and private keys are linked together mathematically. The exact way they are linked depends on a particular curve (and related constants). Polkadot supports the secp256k1 curve (same as Bitcoin and Ethereum), as well as the 25519 curve (also supported by the XRP Ledger).
What issue did your team discover?
We noticed that Polkadotjs’s deriveAddress function was not working correctly for the secp256k1 curve. Depending on how that function would be used, transaction signatures would be incorrect, or transactions could have been sent to the wrong addresses.
This was pointed out to Polkadotjs engineers, who promptly released a patch to upgrade their libraries to be secp256k1 compatible for this function now.
This shows the importance of choosing experts to work on blockchain systems to ensure that issues are solved before they represent a risk.
What led to the discovery of the issue?
Polkadotjs, like other blockchain SDKs, exposes a simple function allowing transactions to be easily signed without exposing users to the low-level cryptographic aspects of the signing process. Most Polkadot applications sign their transactions; however, these simple functions are not compatible with AWS KMS because the private keys need to remain in their related HSM, but HSM has no understanding of Polkadotjs and therefore cannot use it.
To resolve this, we had to create our own algorithm to perform all of the low-level cryptographic operations, e.g. encoding the transaction, creating the signature, decoding and decomposing the signature, creating a signed transaction object, and serialising it. Only when performing all of these low-level steps individually was this issue noticeable.
As this issue was not flagged up beforehand, I would conclude that no one else has attempted this particular integration before.
