WWPass technology in depth

Overview

WWPass may be considered a third-party identity provider. Other examples of third-party identity protocols include OpenID Connect, SAML, and CAS. OAuth, in some contexts, may also be used as part of an identity solution.

A third-party identity provider stores user-related data and provides controlled access to that data to external Service Providers (Relying Parties).

WWPass differs from traditional identity providers in the following key aspects:

• It heavily relies on a hardware crypto token. A token can be implemented as a special secure hardware device or as a WWPass Key app on a smartphone using a hardware-backed keystore.
• There is no single set of user data known to the Identity Provider and distributed among Service Providers; instead, each user / Service Provider pair has its own fully isolated Data Container.
• There are no restrictions on user data format - serialization and data structure are fully defined by the Service Provider, which remains the data owner.

In this sense, WWPass may be considered a per-user secure storage utility for Service Providers.

Another important feature of WWPass is token management:

• Issuance and revocation of cryptographic tokens may be performed by the user without active involvement from WWPass.

WWPass transaction steps

Every user account (keyset) is assigned a unique User Identifier (UserID) - a randomly generated value. The UserID is stored in the token memory and can be read only by the WWPass core network.

Every Service Provider is assigned a unique Service Provider Identifier (SpID) - also a randomly generated value.

A typical WWPass transaction consists of the following steps:

1. The user hardware crypto token (or hardware-backed keystore on the user's smartphone) and WWPass perform mutual authentication.

   As a result, the UserID becomes known to WWPass.

2. The Service Provider and WWPass perform mutual authentication.

   As a result, the SpID becomes known to WWPass.

3. The UserID / SpID pair is used to calculate the address of the corresponding Data Container.

4. Read / Write access to the Data Container is performed:

   • Read operation: the content of the Data Container is sent from the WWPass storage to the Service Provider
   • Write operation: the Service Provider sends user data to the selected WWPass Data Container

Authentication details: Service Provider / WWPass

Mutual authentication between a Service Provider and WWPass uses the SSL protocol with both server-side and client-side certificates. The resulting SSL/TLS connection is encrypted, and all subsequent data exchange is secured.

To participate in WWPass transactions, a Service Provider must be registered in the WWPass network.

During registration, the Service Provider is assigned:

• a unique Service Provider Identifier (SpID)
• a unique human-readable Service Provider name

The Service Provider name is usually (but not necessarily) based on the Service Provider’s URL.

After registration, the Service Provider receives an X.509 certificate signed by the WWPass Certificate Authority (CA). This certificate is used for mutual authentication with WWPass.

Authentication details: User

Token / WWPass

The user owns a hardware crypto token. The token can be implemented either as a special secure hardware device or as a WWPass Key app on a smartphone using a hardware-backed keystore.

Mutual authentication between the Token and WWPass is implemented according to GlobalPlatform Secure Channel Protocol 03 (see Secure Channel Protocol 03 GlobalPlatform Card Specification v2.2 - Amendment D - 1.0). The protocol is based on a pre-shared secret key.

As a result of mutual authentication, a new session key is generated, which protects all further data exchange between the Token and WWPass.

Access code (PIN or Password)

Hardware token authentication is a mandatory first factor in WWPass authentication (something the user has).

A Service Provider may additionally require two-factor authentication. In this case, successful token authentication is followed by manual entry of an Access code (something the user knows).

WWPass implements the Secure Remote Password (SRP) protocol (see SRP Official site and RFC 2945).

In the context of WWPass authentication, SRP has specific characteristics. SRP starts after token authentication, meaning that the user account is already identified.

As a result, a traditional username is not required, and a predefined constant string is used instead in SRP calculations.

Data Container access

Data container

The Data Container storage is designed to be secure in several aspects:

• Data is encrypted at rest. The encryption key can be derived only in the presence of a valid user token.
• The Data Container identifier (address) cannot be used to identify either the user or the Service Provider to whom the Data Container belongs.
• Data Containers are stored in a geographically dispersed manner.

Data Container address calculation

As a result of successful authentication of the Token and the Service Provider, WWPass obtains the corresponding UserID and SpID.

The Data Container address is calculated as a one-way function of the concatenation of (UserID | SpID). To calculate the Data Container address, WWPass uses asymmetric encryption with a predefined public key.

This key pair was created specifically for this purpose during key generation. The public key is a lifetime constant of the WWPass service. The private key of this pair is not used during normal operation and is not required to be retained.

Alternatively, Zp encryption (raising p to the power of the concatenated (UserID | SpID)) may be used for one-way address calculation.

Data Container encryption

Regardless of whether the Data Container content is encrypted by the Service Provider, it is always additionally encrypted by WWPass before being sent to the storage subsystem.

WWPass uses another public key, belonging to a different key pair, to encrypt the concatenation (UserID | SpID). The resulting value is used to construct an AES key to encrypt the data. When data is read back, the same calculations are performed to restore the encryption key.

It is important to note that data at rest is therefore encrypted. The encryption key is not stored in WWPass permanently and is available only as a result of successful authentication of both the Service Provider and the Token.

Alternatively, the Data Container encryption key may be calculated as a hash of the concatenation (UserID | SpID).

Dispersed data storage

WWPass stores Data Containers in a 12-node dispersed data storage system using Reed–Solomon 6-out-of-12 encoding.

This design allows WWPass to continue operating in the event of loss or compromise of fewer than six storage nodes.

It is important to note that Data Containers are geographically distributed across multiple locations worldwide.

In specific implementations, data distribution may be limited by country or regional boundaries.

Alternatively, the standard 6-out-of-12 Reed–Solomon scheme may be reduced to configurations such as 2-out-of-3 nodes, depending on deployment requirements.

Ticket as a transaction identifier

Mutual authentication in the pairs (User ⬄ WWPass) and (Service Provider ⬄ WWPass) is not sufficient to uniquely associate a user session with a Service Provider session.

Because communication between users and Service Providers is many-to-many, WWPass requires an additional mechanism to identify a specific interaction session.

This role is fulfilled by a Ticket, which acts as a transaction identifier.

What is a Ticket

The term Ticket was borrowed from the Kerberos protocol, although the underlying mechanism is different.

A Ticket is a small piece of information exchanged between the User, the Service Provider, and WWPass.

Its formal representation is:

<spname:>[pc:]<nonce>@<issuer>

Where:

• <spname> is the registered human-readable name of the Service Provider, presented to the user in the consent dialog
• p is optional; when present, it indicates that two-factor authentication (Access code) is required
• c is optional; when present, it indicates that the transaction involves client-side encryption
• <nonce> stands for “number used once” and is a random sequence of hexadecimal digits
• <issuer> is the WWPass network node where the Ticket was created

Example:

example.com:0be4a4c407f021a6e39032755fec65611ed6c758e7ead6309412c0cbb966fa08bd887c421b3d@WWPass_srv15:16032

Counter-Clockwise scheme

In the Counter-Clockwise scheme, the authentication process is initiated by the Service Provider.

1. The user starts authentication by pressing a button in a client application (for example, a web page in a browser). When appropriate, the Service Provider requests a ticket when the web page is displayed in the browser. The ticket is presented as a QR code and can be scanned with the WWPass Key app on a mobile device.
2. The Service Provider connects to WWPass, authenticates itself, and requests a Ticket.
3. WWPass generates a new Ticket containing the Service Provider name and stores an association between the Ticket and the corresponding Service Provider Identifier (SpID).
4. The Service Provider passes the Ticket to the client application.
5. The client application downloads the Ticket into the Token.
6. Depending on the Token’s ability to display the Service Provider name (for example, a Token on a smartphone), a Consent dialog is shown either on the Token screen or on the terminal display.
7. After user confirmation, the Token authenticates to WWPass, establishes an encrypted channel, and sends the UserID and the Ticket.
8. WWPass uses the Ticket to identify the specific user-Service Provider session, determines the corresponding Data Container, and provides the Service Provider with read/write access to it.

The Ticket is used as a transaction identifier between the Service Provider and WWPass for subsequent data exchange within this session.

Clockwise scheme

In the Clockwise scheme, the authentication process is initiated by the User through the Token.

1. The user starts authentication by pressing a button in a client application (for example, a web page in a browser).
2. The Service Provider name is downloaded into the Token, and the user is presented with a Consent dialog (“Allow authentication into — Yes / No”).
3. If the user confirms, the Token authenticates to WWPass and sends the Service Provider name and UserID.
4. WWPass generates a Ticket using the received Service Provider name and stores an association between the Ticket and the UserID.
5. The Ticket is returned to the Token.
6. The Token passes the Ticket to the terminal application, from where it is received by the Service Provider.
7. The Service Provider authenticates to WWPass and presents the Ticket.
8. WWPass verifies that the Service Provider name contained in the Ticket corresponds to the authenticating Service Provider and, if valid, grants read/write access to the corresponding Data Container.

Token management. Token life-cycle.

WWPass tokens can be implemented as a set of special secure hardware devices or as a WWPass Key app on a smartphone using hardware-backed keystore.

Hardware Tokens - WWPass Keyset

Each user account (keyset) may include multiple Tokens that share the same UserID. Each Token in the keyset provides access to the same user data defined by this UserID.

These Tokens collectively form a keyset. The user may deactivate any Token in the keyset or add new Tokens at any time.

To support mutual authentication with WWPass, each Token has two lifetime constants:

• TokenID — a value unique across the entire WWPass network, used as Key Diversification Data according to GlobalPlatform terminology
• TokenSecret — a pre-shared secret used for mutual authentication according to GlobalPlatform Secure Channel Protocol 03

Each Token also stores two additional parameters that are common to the entire keyset:

• UserID
• UserDataEncryptionKey

Blank token

WWPass cryptographic Tokens are based on Java Card microcomputers (see the Java Card Platform Specification).

During manufacturing, a WWPass application (cardlet) is installed on the Java Card. At this stage, the device is considered a blank WWPass Token.

Pre-personalization

The next step is pre-personalization.

A blank Token is connected to the WWPass network, which allocates and installs the TokenID and TokenSecret on the device.

Pre-personalization is performed in a secure factory environment.

Personalization

Tokens that contain UserID and UserDataEncryptionKey are considered personalized.

The UserDataEncryptionKey may be used by certain applications to perform cryptographic operations on the user terminal.

Pre-personalized Tokens are delivered to end users.

Subsequent actions depend on whether the Token is:

• the first Token in a new keyset, or
• an additional Token being added to an existing keyset

Activating a new keyset

When activating a new keyset, a pre-personalized Token connects to the WWPass network via the user terminal.

WWPass allocates a new unique UserID and stores it in the Token memory.

The Token then generates a random UserDataEncryptionKey. This value is not known to the WWPass network.

Adding a Token to an existing keyset

Adding a Token to an existing keyset involves:

• one already personalized Token, and
• one pre-personalized Token

The procedure is coordinated by the WWPass network.

1. The personalized Token connects to WWPass via the user terminal and performs mutual authentication.
2. WWPass generates a random symmetric encryption key and sends it to the Token.
3. The Token encrypts the (UserID, UserDataEncryptionKey) bundle using the received symmetric key.
4. The encrypted bundle is temporarily stored in the User Terminal memory.
5. The user disconnects the personalized Token and connects the pre-personalized Token.
6. After mutual authentication with WWPass, the pre-personalized Token:
   • downloads the encrypted (UserID, UserDataEncryptionKey) bundle from the User Terminal memory
   • receives the symmetric encryption key from WWPass via an encrypted channel
   • decrypts the bundle and stores UserID and UserDataEncryptionKey in its memory

Token - WWPass Key app

The WWPass Key app is installed on a user's smartphone. The app acts as a Token and uses a hardware-backed keystore to generate and securely store cryptographic keys.

Every user account can have only one active WWPass Key app that shares the same UserID. When the key is restored or transferred to a new device, the previously active app instance is automatically deactivated, ensuring that only one device remains active for that UserID.

To support mutual authentication with WWPass, each WWPass Key app (same as hardware Token) stores four parameters:

• TokenID
• TokenSecret
• UserID
• UserDataEncryptionKey

Activating a new WWPass Key app

The procedure of a new WWPass Key app activation is similar to the personalization of the first token in a keyset. The process is coordinated by the WWPass network.

1. The user creates an Access code (PIN).
2. The WWPass Key app connects to the WWPass network. WWPass allocates a new unique UserID and sets the corresponding constants in the WWPass Key app memory. The WWPass Key app generates a random UserDataEncryptionKey. This value is not known to the WWPass network.

Creating a WWPass Key app backup

The procedure is coordinated by the WWPass network.

1. The user submits an email address and verifies it via validation email.

An email can be used to back up only one WWPass Key at a time. If the same email address is used to create a backup for another WWPass Key, the previous backup is erased.

2. The active WWPass Key app connects to WWPass and performs mutual authentication. The user enters their Access code (PIN).
3. WWPass app generates a symmetric encryption key from the Access code (PIN) and sends it to the WWPass Key app.
4. The WWPass Key app encrypts the (UserID, UserDataEncryptionKey) bundle using the generated symmetric key. The encrypted bundle is stored in the WWPass network and can be used to restore the WWPass Key.

Recovering the WWPass Key app from backup

The procedure is coordinated by the WWPass network.

1. The user submits an email address and verifies it via validation email.
2. The user enters their Access code (PIN).
3. The WWPass Key app:
   • downloads the encrypted (UserID, UserDataEncryptionKey) bundle from the WWPass network.
   • generates a symmetric encryption key from the Access code (PIN).
   • decrypts the bundle with that key and stores UserID and UserDataEncryptionKey in its memory.