M-PIN Authentication Protocol

Pairing-Based Crypto (PBC) is emerging as a solution to complex problems that have proven intractable to the standard mathematics of Public-Key Cryptography. An example of such a problem would be Identity-Based Encryption, whereby the identity of the end user can be used as their public key.

We have used PBC to develop a novel multi-factor zero knowledge authentication protocol called M-PIN. This is intended as a replacement for the typical username / password authentication mechanism. The benefits are that it is multi-factor (a simple PIN could be one factor), does not require a password database to be maintained and can be implemented fully in software. As it is zero-knowledge, the end user can prove possession of the issued secret key whilst revealing no details about this key.

# Distributed Trust Authorities and Client Token

The protocol requires the client to authenticate to the server using the key material provided by the system. The entity that provides the keys is called the Distributed Trusted Authority (DTA). Different organisations can run DTAs which produce unique keys for the server and client, thus ensuring there is no single point of trust nor associated security risk.

When a DTA starts, it independently generates a master key share which it stores in memory. The server requests a server key share from each DTA, which is a function of its master key share. The client requests a client key share from the DTA, which is a function of the master key share and the end user’s identity. This process is then repeated for a second DTA. At this stage the server and client now have key shares from two DTAs which can be combined. The client can now subtract a value from the client key, based on an entered PIN, resulting in a token which is one of the two factors; the other one being the PIN.

Because of the online nature of the M-PIN protocol and cryptography used, it is not possible to brute force the PIN. Therefore, it is not necessary to take specific measures to protect the token.

# Key Rotation

An extension to the M-PIN authentication protocol, Key Rotation handles the cases in which outdated Client Secrets are used for authentication. A Client Secret is considered outdated when one of the DTAs that issued it is no longer active.

When an end user authenticates with an outdated Client Secret, several steps are performed automatically:

  1. The end user is authenticated using the outdated Client Secret.
  2. A new secret is issued by active DTAs.
  3. The end user is authenticated using the new Client Secret.

Note that this all happens automatically without the end user noticing or being notified about it.

# Zero Knowledge Proof Authentication

The authentication process starts with the client sending the identity and a commitment value to the server. This value is a function of a large random number and the identity. The server generates another large number which it returns to the client as a challenge. The client then requests the PIN. The token and PIN are combined to form the client key, only in memory and never stored. Together with this client key and the two random numbers, a response is calculated which is sent to the server. The server uses the identity, server key, commitment, challenge value and client response to verify the client.

# Summary

Distribution of trust and zero-knowledge proof authentication are what differentiates MIRACL Trust® from other multi-factor authentication solutions, and what allows MIRACL to present itself as “zero-knowledge proof” authentication since no values are stored or exchanged in the authentication process.

The M-PIN protocol gives MIRACL Trust its core cryptographic properties, i.e. no critical information is ever transmitted or stored in whole form:

  • Client Secret shares are transmitted from two separate DTAs that can be under separated organisational control.

  • The combined Client Secret is turned into a token by subtraction of the PIN.

  • The PIN should not be stored anywhere. It should only exist in the end user’s mind.

  • During  authentication no critical credentials (PIN or client key) are transferred. The authentication server determines the validity of the reformed Client Secret (client token plus PIN) and therefore the end user’s identity solely by evaluating a numeric response from the client.

sequenceDiagram participant Client participant Server participant DTA1 participant DTA2 Note over DTA1,DTA2: DTA Initialization par DTA1->>DTA1: masterSecret1 = new_master_secret() and DTA2->>DTA2: masterSecret2 = new_master_secret() end Note over Server,DTA2: Authentication Server Initialization par Server->>DTA1: get_server_secret() activate DTA1 DTA1->>DTA1: serverSecret1 = new_server_secret_share(masterSecret1) DTA1-->>Server: serverSecret1 deactivate DTA1 and Server->>DTA2: get_server_secret() activate DTA2 DTA2->>DTA2: serverSecret2 = new_server_secret_share(masterSecret2) DTA2-->>Server: serverSecret2 deactivate DTA2 end Server->>Server: serverSecret = new_server_secret(serverSecret1,serverSecret2) Note over Client,DTA2: Client Secret Creation par Client->>DTA1: get_client_secret(id) activate DTA1 DTA1->>DTA1: clientSecret1 = new_client_secret(masterSecret1,id) DTA1-->>Client: clientSecret1 deactivate DTA1 and Client->>DTA2: get_client_secret(id) activate DTA2 DTA2->>DTA2: clientSecret2 = new_client_secret(masterSecret2,id) DTA2-->>Client: clientSecret2 deactivate DTA2 end Client->>Client: clientSecret = add_shares(clientSecret1,clientSecret2) Client->>Client: PIN Client->>Client: token = new_token(clientSecret,PIN) Note over Client,Server: User Authentication Client->>Client: PIN Client->>Client: x = get_random_number() Client->>Client: u = new_commitment(id,x) Client->>Server: get_challenge(id,u) activate Server Server->>Server: y = get_random_number() Server-->>Client: y Client-->>Client: v = new_response(id,PIN,token,x,y) Client->>Server: authenticate(v) Server->>Server: result = verify(id,y,u,v,serverSecret) Server-->>Client: result deactivate Server