Skip to main content

How WWPass works

WWPass / many_vs_one

WWPass provides a convenient and secure way of authentication and data storage for both end users and companies. Currently, every one of us has dozens of bank and loyalty cards, an overweight keychain, and lots and lots of Internet registrations. Every time we need to authenticate ourselves, either physically or on-line, we are forced to provide a card or a login/password pair. Every day we must make an unpleasant choice between the insecurity of a single universal password, or the inconvenience of hundreds of different cryptographically strong passwords that are impossible to remember. At the same time, the organizations with which we authenticate collect private information about us. They may keep the information private, use it for marketing purposes, sell it, or allow it to be compromised. We have no control over how our private data is used.

WWPass provides an answer to many of these security threats.

Safe deposit box: two key approach​

WWPass / two_keys_approach

The core concept in a WWPass solution is the "Data Container", which is analogous in the non-computer world to a safe deposit box. Using a safe deposit box a customer can store precious personal or sensitive items. In real life this safe deposit box "can be opened only with production of an assigned key, the bank's own guard key, the proper signature, and perhaps a code of some sort" http://en.wikipedia.org/wiki/Safe_deposit_box.

When using a WWPass Data Container a user can store valuable information in digital form. In the digital world WWPass provides a unique key to every user (UserID) and another unique key for the Service Provider (we call this key a SPID - Service Provider ID). The Service Provider is a network application and may be a mail server, an on-line retail shop, a corporate web page, a vending machine, a bank, or any other application requiring authentication. WWPass provides a separate "deposit box" (Data Container) which corresponds to each user registration at a particular Service Providers web site or application (i.e. for each UserID/SPID pair). To open this box, two keys are needed: first the user’s key (containing the UserID) and second, the Service Providers key (containing the SPID). Thus the user’s data, which belongs to different Service Providers will never intersect, and therefore be totally independent. A user’s activity cannot be tracked and personal information that the user chooses to give to one Service Provider will never be given to any other Service Providers without express permission.

For an even greater level of security users may be asked to provide an Access Code (analogous to smart cards PIN) in addition to their key (utilizing two-factor authentication).

So here’s how a WWPass-enabled model works for a website login:

  • The User requests to be logged in to a Service Provider's web site
  • The Service Provider communicates with the WWPass data center and provides its key (SPID)
  • The Service Provider asks the User to provide a key (UserID) to WWPass
  • WWPass uses both keys to open the corresponding "Data Container" and passes the contents to the Service Provider

WWPass / web_auth

WWPass Keys​

In the digital world keys may be copied in the same way as in real life. When a fraudster (hacker) gets a key replica, it is possible for the user not to notice the existence of a second key for some period of time. WWPass puts an enormous effort into preventing unauthorized key copies. User keys (actually UserIDs) are secret data elements and are stored in a special secure hardware device called a “WWPass Key”. These WWPass Keys are constructed with well-known "smart card" technology that is widely used in chip cards and mobile phone SIM cards http://www.smartcardbasics.com One WWPass Key (and in some cases a single Access Code (PIN)) can actually replace most existing cards, keys and login-password pairs for a WWPass-enabled User authenticating to a WWPass-enabled site.

Digital world: encryption & data dispersion​

WWPass encrypts all data; every data container is ciphered with its individual cipher key. Thus not only is all the data stored by WWPass unreadable, but there is no single secret "cipher key" which, when revealed, helps to decode all WWPass information.

WWPass / dispersed_data

Another enhancement of securing digital data is data dispersion. In order to survive a single storage node fault WWPass distributes data content over multiple geographic locations. Every data container is converted into twelve pieces and stored at twelve different data centers. The redundancy implemented by a data dispersion algorithm allows WWPass to restore user data if any of six locations are available. At the same time if a hacker managed to gain access to less than six chunks of information, say five or less, it would be impossible to restore any of the original data. WWPass uses Reed-Solomon redundancy code (6,12) to implement this feature. The idea was proposed by M. Rabin “Efficient dispersal of information for security, load balancing, and fault tolerance” http://dl.acm.org/citation.cfm?id=62050, and implemented in RAID6 and in a number of cloud storage projects. http://tahoe-lafs.org/trac/tahoe-lafs

Zero knowledge policy​

Zero knowledge is one of the main principles of the WWPass architecture. This principle enforces that all users are anonymous to WWPass with no knowledge of any data stored in a WWPass data container. WWPass can assert to its Service Providers that, "when the owner of this particular key visited your web site previously, you (the Service Provider) asked WWPass to store the following bytes." IDs are not stored in the WWPass core system, so it is impossible to find out the owner of particular data container. Generally speaking this “zero knowledge” principle is the ultimate solution to insider security breaches and leaks (back doors).

As a side effect WWPass cannot do much when a user loses his/her hardware device. The user is empowered to perform all key operations: revoke lost keys, create new keys etc. Moreover, WWPass provides the user with two types of devices: the first is called "WWPass Key" and is intended for everyday use, while second, "Service Key", performs only key management tasks.

WWPass participants​

WWPass participants are shown in the following picture:

WWPass / participants

There are three parties in a WWPass model: A Service Provider with an Application or web service, a User with a user terminal, and the WWPass Core Service.

  • "User Terminal" is a user desktop/laptop at home or office, retail store checkout, vending machine, etc. To start a WWPass transaction, the User should connect his/her WWPass Key to the user terminal.
  • WWPass core network provides mutual authentication service between all participants and store the user’s private data in a secure dispersed data container (which is encrypted, fragmented and dispersed throughout the WWPass data centers).
  • Service Provider Application actually means network servers (such as Web sites, Cloud services, VPNs, Remote Desktops)

WWPass core network structure​

Digging deeper into the WWPass core network, the following components can be found:

WWPass / core_structure

  • Service Provider Front-ends (SPFE) and User Front-ends (UserFE) are network entities responsible for Service Provider and User authentication. User Access Code is also checked here. SPFE transmits the Data Container contents between the Service Providers and WWPass Storage.
  • Data Miners communicate with storage nodes and disperse Data Containers on write commands and assemble them back on read commands. Data miners are responsible for preserving data integrity, for error detection and correction.
  • Storage Nodes are a set of geographically dispersed servers that store data.

It is important to note that there may be multiple Front Ends and Data Miners running concurrently. Thus it is what makes WWPass core network architecture a reliable system without single point of failure.

More on WWPass Keys​

WWPass Keys use a well-known "smart card" technology which is widely used in bank chip cards and mobile phone SIMs. These “Java Cards”, employed by WWPass are a form of smart cards, and are able to perform most crypto operations – symmetric and asymmetric cipher, digital signature, message integrity check, etc. Because Java Cards can execute Java code they are very flexible and can easily be adapted to most kinds of protocols or technologies. Java Cards are cryptographically strong; therefore It is impossible for an intruder (hacker) to read the contents of the cards memory to get access to crypto keys or other secrets.

Java cards are an industrial standard with many cards available on the market. This makes WWPass’ technology inexpensive and robust while providing the highest level of data protection. When used as bank cards or SIMs, smart cards are usually mounted on modules with eight gold-plated contacts and then implanted into a piece of plastic. Some cards may use so called “contactless” interfaces, like that of transportation cards used widely all around the world.

In order to connect a smart card to a computer, small and simple devices called “smart card readers” are used. Unfortunately there are few computers equipped with smart card readers at the moment. To mitigate the lack of readers WWPass provides a combination of smart cards and readers. Due to well established industry sources of advanced Java Cards, WWPass can foresee multiple form factors and interfaces for our keys, including bare plastic cards, NFC tokens, USB keys and others.

Access Code as a second authentication factor​

Authentication strength is usually improved with additional factors. According to Service Provider request, WWPass could ask the user to manually enter an Access Code in addition to their WWPass Key. An important difference is that the user provides the Access Code only to WWPass, not to every Service Provider. Thus it is not necessary to create and remember many passwords. It is similar in functionality to a bank card PIN, where the PIN refers to the card, not to an ATM where it is used. According to the zero-knowledge principle WWPass cannot assist a user if he/she forgets their Access Code. However using both their WWPass Key and their Service Key, a user can reset the forgotten Access Code.

Technically WWPass employs the SRP (Secure Remote Password) protocol. The protocol is now widely used for strong network authentication and is described in RFC-2945 and is ISO - standardized (ISO/IEC 11770-4).

According to Kim Cameron’s article The Laws of Identity, “Technical identity systems must only reveal information identifying a user with the user’s consent.”

That means that every act of user identification should be done under the full consent and control of the user. To take it one step further, “should the user decide to supply identity information, there must be no doubt that it goes to the right place”.

WWPass follows this principle. The name of the Service Provider is presented to the user in every WWPass transaction. The transaction starts on User explicit confirmation only.

Authentication ticket: how to associate Service Provider with the User​

In order to provide a proper Data Container, WWPass needs to associate a particular user with a specific Service Provider. To do this a temporary transaction identifier called a “ticket” is employed. A WWPass ticket combines a long random number - “nonce” (number used once), with the Service Provider name and some housekeeping information.

The ticket is issued by the WWPass core service upon the request of the Service Provider. The Service Provider transmits the ticket to the user. This ticket is downloaded into the WWPass hardware WWPass Key. The user sees the Service Provider name, which is piggybacking on the ticket, through the authentication dialog and confirms the transaction. Next the WWPass Key starts the authentication process with the WWPass core network. Upon success an encrypted communication channel is created between the WWPass Key and the WWPass User Front End. The ticket and the UserID are transmitted secretly using this secure channel back to WWPass. Now WWPass can determine the SPID, which corresponds only to the requesting Service Provider.

Having both keys – SPID and UserID, WWPass calculates the Data Container address and its encryption key. With the address available the data is ready to be transmitted to the Service Provider. WWPass authenticates WWPass Keys according to the GlobalPlatform 2.2.1 standard (Secure Channel version 2).

Zero knowledge: how to name & store data​

Only when WWPass has both the UserID and the SPID, can it store and retrieve information from the data container. A straightforward approach would be to use a concatenation of the UserID and the SPID as a container identifier (or filename, or key) and to store the Service Provider data as is. If WWPass could guard our storage media from the outside world, this solution might be safe. However if the storage media itself could be subject to criminal investigation, lots of information could be harvested. Existing UserIDs would be extracted from the container identifiers as well as their combinations with SPIDs. This would allow user activities at various web sites to be tracked.

To protect IDs in a data container WWPass uses a transformation for identifiers; this is in fact a “one-way injective function”. This means WWPass applies a specific function to the UserID/ SPID combination to create a unique container identifier. “One-way” means that it is practically impossible to “invert” the transformation and to get back the UserID and SPID.

WWPass could use hash functions, but unfortunately they do not guarantee uniqueness. What is needed is a kind of “Injective” transformation. At least two functions are known to have this property. The first is a power function modulo prime number (used in e.g. Diffie- Hellman key exchange algorithm). Another solution is to use an RSA algorithm for public-key encryption. Provided the private key is intentionally destroyed this encryption becomes one-way.

Both mentioned functions work in modulo arithmetic, with relatively big numbers. Treated as bit strings, those numbers hold concatenations of the UserID and SPID. Spare bits available in the strings allow WWPass to use additional parameters – e.g. container names. This way multiple named data containers for each User/Service Provider combination may be provisioned.

Encryption is highly desirable to prevent malicious investigation of the storage media. While Reed-Solomon dispersion can be considered as a way to keep data secret per se (see How to share a secret), WWPass also encrypts all data containers. Every data container is ciphered with a key obtained as a hash of the SPID and UserID concatenation.

WWPass continuously checks the integrity and corrects errors without any knowledge of the customer’s data. WWPass iterates over available cryptic names of containers, to determine if a chunk is lost on a particular storage node and restores it properly using Reed- Solomon algorithm.

To summarize how WWPass handles customer’s data: container name and content are ciphered. Ciphered data is disseminated using Reed-Solomon dispersion techniques. The keys used to access data are unique for each container and become known to WWPass only during the active phase of a transaction, when the SPID and the UserID are available. It is impossible to calculate who the owner of particular data container is or to decipher its contents because IDs are not stored anywhere in WWPass outside of a transaction. Thus a high level of privacy is maintained as it is not possible to track the personal activity of a user.

Zero knowledge: I lost my key (and forgot my Access code)​

User anonymity comes at a price: WWPass can do nothing in cases where a user loses his/her WWPass Key or forgets an access code. If there is no way to restore the key, all data contained by WWPass are lost forever. There is no means for WWPass or the Service Provider to get the users lost credentials back. This approach leaves it completely up to the user to be fully responsible for the safe backup of their WWPass membership.

WWPass provides two types of Keys: a “WWPass Key” for everyday needs, and a “Service Key”, which is bound to the user account. The Service Key cannot be used for e-shopping or corporate site login. However it is this Service Key which can revoke/disable a lost WWPass Key and provide the necessary data to create a new WWPass Key. If the user forgets an access code, the old access code cannot be recovered: WWPass operates only with derivative values. By using both keys (Service Key and WWPass Key), the user can reset and redefine the access code for use across all WWPass-enabled Service Providers.

WWPass Applications: How to use WWPass technology​

WWPass concentrates its efforts on secure authentication and storage technologies holding several important patents for this technology.

WWPass has also a number of out-of-the-box solutions, which include:

  • CMS authentication modules
  • VPN hardware token login
  • signed and encrypted e-mail
  • encrypted cloud storage with fine-grained access rights

The variety of applications was made possible due to low level, "binary" nature of WWPass architecture. WWPass provides a robust and easy to use SDK to allow third-party Service Providers and developers to implement WWPass support into their applications.