Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Token-Based Multiparty Password Authenticated Key Retrieval Process

IP.com Disclosure Number: IPCOM000238619D
Original Publication Date: 2014-Sep-05
Included in the Prior Art Database: 2014-Sep-05
Document File: 4 page(s) / 118K

Publishing Venue

Linux Defenders

Related People

Pablo Guerrero: AUTHOR

Abstract

A process to allow a user with a password P, to retrieve a secret key (or any other strong secret) K with the help of multiple independent servers. The secrecy of P and K is preserved if at least one server is not compromised by an attacker. It’s based on single use pre-calculated tokens and additional measures to prevent denial of service attacks. Unlike the alternatives, it’s not covered by patents and it can be used freely, which makes it an interesting solution in many use cases.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 29% of the total text.

Page 01 of 4

 Token-Based Multiparty Password Authenticated Key Retrieval Process

Pablo Guerrero - siriux@gmail.com - http://greenentropy.com - August 2014

Motivation and previous work

A Password Authenticated Key Retrieval (PAKR) process is any process that allows a client to retrieve a large key, only knowing a password that it's easier to remember than the key. A simple PAKR process would be to authenticate to a server (or any other system) using the password, and receive the key encrypted by the password. This is secure, simple and efficient, as long as you assume that the server has not been compromised by an attacker. Otherwise, the password and the key can be compromised.

Even if the server doesn't store the password in plain text, an attacker with access to the server can easily recover it. The reason is that usual passwords have low entropy, to make them easy to remember, and that allows to easily find the password using offline brute force.

A PAKR process that can resist the attack of one or more servers without compromising the key or the password, would greatly improve the client security in this scenario. At least three different processes, based on the use of multiple independent servers, have been already proposed to solve this problem.

The first one is based on exponentiation, where the client recovers a high entropy key using N different servers and it's password. This system can resist the attack of N - 1 servers while still preserving the password and key secrecy. The problem is that it's covered by at least the patent US7359507 and there have been serious doubts about it's security ("Security Analysis of Password- Authenticated Key Retrieval", Shin - Kobara).

The second one is based on an equality comparison of a secret by two servers without revealing any additional information to any party. This system is much simpler and requires less work on the client, but it's covered by the patent US7725730 and it's only valid for two servers.

The third one is based on splitting the entropy of the password into pieces to independently authenticate to different servers that have shares of the key. This process is covered by the patent US6959394 and I have serious doubts of it's security in the real world if multiple servers are compromised, as the entropy of each piece is really small.

Therefore, a solution based on a different process (not covered by patents), that can securely solve the problem for N servers would be really interesting, specially for the Open Source community.

Proposed Process

The proposed process is based on single use pre-calculated tokens, that allow a client that knows a password P, a single try to retrieve a key (or any other strong secret) K with the help of N independent servers. N-1 servers can be compromised by an attacker without compromising the security of P or K.


Page 02 of 4

First we will show the process using a single token. Then, we will address the problem of having a single token and how to avoid...