Designated Verifier Signature

# Introduction

In a classic digital signature scheme, the global community is capable of verifying a signature. In a designated verifier signature scheme (DVS), only the designated verifier has this capability. In a classic DVS scheme, the signer themselves “designates” the entity that has the capability of verifying their signature. In a pure identity-based signature scheme, a Trusted Authority (TA) is introduced, and is responsible for issuing secret signing keys to all participants. In our proposed scheme, it is this TA, not the signer, that designates the verifier, and to this end the TA issues the designated verifier with its own secret. Finally, we propose a variation that supports non-repudiation, plus a hardware-free multi-factor signature capability.

MIRACL Trust DVS allows clients to leverage MFA technology for the implementation of non-repudiative digital cryptographic signatures ensuring transaction and data integrity.

DVS can be used either through MIRACL Trust MFA web JS library or mobile SDKs. In both cases, transaction or data to be signed are cryptographically hashed. The end user is then asked to enter their PIN which is used to re-create the Client Secret from the client token. The Client Secret is then used to sign the previously generated hash. Lastly, end-user identity, signed hash and original transaction or data are sent to clients infrastructure for storage. For signature validation, clients back-end infrastructure calls MIRACL API endpoint providing end-user identity and signed hash.

# Flow

The diagram below describes the signing and verification flow. Note that steps 1. and 2. can vary depending on implementation and business logic.

  1. End-user created transaction / data is sent to the client’s back-end application.
  2. Back-end application validates transaction and creates digital transaction, document or data.
  3. Back end sends data/transaction, a sha256 hash of the data and a timestamp back to the client application.
  4. The client application validates the received hash and displays data / transaction to the end user and asks them to enter their PIN, which is used to complete the Client Secret. Client Secret is then used to digitally sign the transaction / data hash.
  5. The signature is verified by the following steps:
    a. Client app sends the end-user identity and signed hash to the back-end application.
    b. Back-end application validates signed hash and verifies the signature with MIRACL Trust MFA.
    c. MIRACL Trust MFA platform returns verification result to the back end.
    d. Verification result is communicated to the client application. If the verification result is negative, the end user is asked to enter their PIN again. After 3 successive failed attempts, the end-user identity and Client Secret are revoked.
  6. The back-end application persists transaction / data and signed hash as appropriate.