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 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 customers 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 customer infrastructure for storage. For signature validation, customer back-end infrastructure calls MIRACL API endpoint providing end-user identity and signed hash.

# Flow

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

  1. End-user created transaction / data is sent to the customer backend application.
  2. Backend application validates transaction and creates digital transaction, document or data.
  3. Backend 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 user and asks the end-user 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 backend application.
    b. Backend application validates signed hash and verifies the signature with MIRACL Trust MFA.
    c. MIRACL Trust MFA platform returns verification result to the backend.
    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 backend application persists transaction / data and signed hash as appropriate.