Proof of Chain of Possession (POCOP) Tokens

Abstract

This document introduces a POCOP mechanism based on nested, chained HMACs constructions to provide chained authenticity and integrity protection.

Introduction

Bearer tokens are vulnerable at rest and in transit when an attacker is able to intercept a token to illegally access private information. In order to mitigate some of the risk associated with bearer tokens, proof-of-chain-of-possession may be used to authenticate the token. Chain-of-possession token is a chronological tamper-resistant record of all its possessors and the changes that have been made to it.

Concept

Chained-MACs-with-Multiple-Messages

The MAC_final value is calculated starting with HMAC root key K_root and the first message m₁, each MAC value being used as the HMAC key for the next message.

MAC_final = HMAC(...HMAC(HMAC(K_root, m₁), m₂,), ...m_n)

Google Macaroons are based on this construction.

Chained-MACs-with-Multiple-Keys

The MAC_final value is calculated starting with the first HMAC key K₁ and the root message m_root, each MAC value being used as the HMAC message for the next Key.

MAC_final = HMAC(K_n, ...HMAC(K₂, HMAC(K₁, m_root)))

This construction provides the basis of the POCOP mechanism.

Example 1 of Complex Chained Construction

MAC_final = HMAC(K_n, ...HMAC(HMAC(K₂, HMAC(HMAC(K₁, m₁), m₂)), ...m_n))

Example of client chaining with RS_1 and RS_2:

MAC_final = HMAC(K_{RS_2}, HMAC(HMAC(K_{RS_1}, HMAC(HMAC(K_client, m_client), m_{RS_1})), m_{RS_2}))

broken down into individual MACs

MAC = HMAC(K_client, m_client)

MAC = HMAC(MAC, m_{RS_1})

MAC = HMAC(K_{RS_1}, MAC)

MAC = HMAC(MAC, m_{RS_2})

MAC_final = HMAC(K_{RS_2}, MAC)

This complex construction with multiple messages and multiple keys is applicable to the JWT format.

Example 2 of Complex Chained Construction

MAC_AS = HMAC(K_AS, NONCE_AS || m_AS)
*
MAC_AS = HMAC(K_client, MAC_AS)
MAC_client = HMAC(K_client, MAC_AS || NONCE_client || m_client)
*
MAC_client = HMAC(K_{RS_1}, MAC_client)
MAC_{RS_1} = HMAC(K_{RS_1}, MAC_client || NONCE_{RS_1} || m_{RS_1})
*
MAC_{RS_1} = HMAC(K_{RS_2}, MAC_{RS_1})
MAC_final = HMAC(K_{RS_2}, MAC_{RS_1} || NONCE_{RS_2} || m_{RS_2})

Intermediate Conclusion

Nested, chained complex HMACs constructions applied on tokens, tickets, cookies and macaroons may be used to implement both new authorization protocols and to enhance existing ones.

POCOP Token Mechanism

The Chained-MACs-with-Multiple-Keys construction is used as the basis of the POCOP token mechanism.

The root message of the token must contain:

• The random NONCE to prevent replay attack.

• The claim that identifies who created the token.

• The timestamp of when the token was issued.

The claims can be chained using the Chained-MACs-with-Multiple-Messages construction. The complex combination of Chained-MACs-with-Multiple-Messages and Chained-MACs-with-Multiple-Keys constructions forms a basis of the Chained Credentials-Based Authorization mechanism.

Conclusion

...

Acknowledgment

Credits go to WG - User-Managed Access and Google Research Publications.