Threshold Signature

Migration of security applications to the cloud poses unique challenges in key management and protection: asymmetric keys which would previously have resided in tamper-resistant, on-premise Hardware Security Modules (HSM) now must either continue to reside in non-cloud HSMs (with attendant communication and integration issues) or must be removed from HSMs and exposed to cloud-based threats beyond an organisation’s control, e.g. accidental loss, warranted seizure, theft etc.

Multiparty computation (MPC) techniques offer non-traditional alternatives for addressing these problems - in particular, threshold signature schemes allow ‘signing power’ to be distributed between a number of parties, such that a certain quorum of the parties are required to collaborate to generate valid signatures, i.e. signing power is distributed in the form of a number of shares. This allows resilience against theft, hardware/software compromise, warranted seizure etc. of any of the shares. However, multiparty or threshold signature schemes are highly complex in comparison to traditional schemes and make several new security assumptions – key generation transcripts may be hundreds of megabytes in length and involve secret sharing, commitments, zero-knowledge proofs and more. Implementing and managing this complexity, along with verifying the security of MPC-generated keys is not trivial.

After implementing a classical (Damgard) threshold RSA signature scheme, we were faced with the challenge of recording and verifying the protocol operation, along with reaching consensus between parties at various stages of the protocol. The challenges faced seem remarkably well-suited to the properties offered by a permissioned blockchain (consensus, immutable history, resilience), so we implemented the threshold RSA signature scheme using the Tendermint consensus engine as our underlying ‘blockchain’. This allowed us to configure per-key permissioned blockchains with the signing parties working as individual blockchain nodes to generate and use a key – every transaction, signing request etc. was stored and agreed upon as a blockchain transaction, allowing easy consensus and auditing. As a front-end to our blockchain signing system, we build a PKCS#11 frontend, allowing our blockchain threshold signer to be used directly from Adobe Reader, with the resulting RSA signatures being indistinguishable from traditional ones.

Watch our interactive demo Explore
Schedule a live demo Schedule
Get in contact with a specialist Contact us