by Mario de la Haba Navarro (Decentralized Security), Pablo Sánchez-Serrano (University of Malaga), and Isaac Agudo (Decentralized Security and University of Malaga)

A recurring security issue in software is protecting cryptographic material, especially for cloud-hosted or internet-facing applications, where the risk of key compromise is higher. One solution is using a Hardware Security Module (HSM), which secures keys and performs cryptographic operations without exposing them. However, HSMs are typically closed source, making security evaluations difficult, and may not support the latest cryptographic methods. For over three years, we've been developing an open-source modular platform to build an HSM for Ethereum clients, a crucial part of the blockchain infrastructure.

Relying on security through obscurity is an approach that can present significant risks. Security by obscurity is based on the premise that a system is more secure if the details of its implementation are unknown. However, this approach can be problematic because if implementation details are discovered, the security of the system may be compromised. There are many examples in the literature of closed systems that were immediately broken once the source code was recovered, but even without the source code, a side-channel can compromise the security of the system. In September 2024, a researcher from NinjaLab published EUCLEAK [L1], an attack that affects ECC keys in the Infineon SLE78 secure element. This is the main component on many different hardware authentication tokens, such as the Yubikey 5 tokens, one of the most widespread FIDO hardware tokens. This is not an isolated example – in 2017, researchers from Masaryk University presented ROCA [R1], an attack affecting the Infineon M7892 B11 chip due to a vulnerability in another closed-source library, this time affecting RSA keys. This shows that despite the risk, the industry is still supporting closed-source and hardware products.

The use of a Hardware Security Module (HSM) is widespread in the modern internet, as many cloud providers already provide some kind of key-management systems based on an HSM. Also, the use of HSM is a requirement in many critical systems, e.g. Root Certification Authorities. However, in the current blockchain security landscape there are not many examples of the use of HSMs, and most of them focus on protecting the private keys of the user wallets [2], leaving the keys of the validator nodes aside. We focused on the blockchain scenario because a blockchain client is a heavily exposed piece of software that is commonly run in the cloud. Also, there is an inherent economical risk associated with blockchain clients, because they need to have access to the cryptographic keys that are used to move funds, so an attacker compromising the machine could use them to empty the victim’s wallet.

If we focus on the Ethereum blockchain, there is another incentive for trying to come up with an open-source HSM – the cryptographic algorithms they use are evolving faster than commercial products. Current consensus protocol makes use of Boneh-Lynn-Shacham (BLS) signatures, which is not a widely used industry standard and hence not supported by traditional HSMs. To the best of our knowledge there is only one HSM manufacturer that claims to support this type of signature [L2], but as with many HSMs, its implementation is closed source. The next generation consensus protocol will probably make use of Zero Knowledge Proof (ZKP) protocols, so the HSM should evolve in sync with the network. Then it is not only a matter of having a more transparent HSM but also a more agile one.

Our goal in this project was to provide the base for an open-source HSM, using a low-cost hardware board, so that anyone can use it with their Ethereum node, without the cost of the hardware being a limitation. This means that developers and security experts can examine the code, identify potential vulnerabilities and contribute to improving the security of the implementation. In addition, we implemented our code using a hardware development kit that provides an open hardware design, allowing the community to also improve the hardware part. In Figure 1 we can see the two different scenarios that we have considered when developing our project: a node operator with physical access to the node (Staker A), and a node operator running the node in the cloud (Staker B). In the first case, the HSM would be physically connected to the node, whereas in the second case the HSM would need to connect to the node over the internet, using either a cellular connection or the internet connection of the node operator. For each scenario we tested a different hardware. We chose Nordic Semmiconductors Development Kits as they provide a wide range of boards based on the ARM Cortex-M33 CPU (e.g. nRF5340 DK, nRF9160 DK and rRF7002 DK), with full support for ARM TrustZone technology. Also, they provide an excellent SDK based on the open-source RTOS Zephyr OS [L3], clear and concise documentation and a very strong community.

Figure 1: Different deployment scenarios for the HSM in Ethereum.
Figure 1: Different deployment scenarios for the HSM in Ethereum.

This project was funded by the Ethereum Foundation[L4] and has been developed in collaboration between Decentralized Security [L6]  and NICS Lab [L7]. All the code and more technical details can be found in the Github repository [L5].

Links: 
[L1] https://ninjalab.io/eucleak/ 
[L2] https://www.securosys.com/ethereum-2.0-bls-on-securosys-hsm 
[L3] https://zephyrproject.org/ 
[L4] https://blog.ethereum.org/2021/02/09/esp-staking-community-grantee-announcement 
[L5] https://github.com/decentralizedsecurity/bls-hsm 
[L6] https://decentralizedsecurity.es 
[L7] https://www.nics.uma.es 

References: 
[1] M. Nemec et al., “The return of coppersmith’s attack: practical factorization of widely used RSA moduli,” ACM CCS , 2017. doi: 10.1145/3133956.3133969
[2] W. Shbair, E. Gavrilov, et al., “HSM-based key management solution for Ethereum blockchain,” in IEEE Int. Conf. on Blockchain and Cryptocurrency, 2021.

Please contact: 
Isaac Agudo, Founder of Decentralized Security, 
Researcher at NICS Lab, University of Málaga
This email address is being protected from spambots. You need JavaScript enabled to view it.

Next issue: January 2025
Special theme:
Large-Scale Data Analytics
Call for the next issue
Image ERCIM News 139
This issue in pdf

 

Image ERCIM News 139 epub
This issue in ePub format

Get the latest issue to your desktop
RSS Feed