Application Binding Protocol for Mobile Client Authenticity

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing communication systems between mobile clients and servers lack effective methods to verify the authenticity of client requests, allowing adversaries to impersonate legitimate clients and compromise data security.

Innovation Solution

The Application Binding Protocol (ABP) establishes a secure channel using self-signed certificates and asymmetric cryptography to verify the authenticity of mobile client requests, ensuring the origin is from a rightful mobile application by validating application and device measurements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If digital signature is used to sign HTTP messages, then authentication and message integrity are improved, but control on integrity and authenticity of the client to be verified by the server is not addressed

Engineering Contradiction:
Improvemessage authentication and integrityVSAvoidclient authenticity verification
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the authentication process into two distinct phases: a bootstrap phase for establishing trust through certificate exchange and registration, and a signing phase for verifying request authenticity. This segmentation allows the system to address both message integrity (through signing) and client authenticity (through bootstrap verification) as separate but complementary functions.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements a preliminary bootstrap phase where the client establishes its authenticity credentials before actual communication begins. The client obtains a certificate from a trusted authority, registers it with the server, and stores the server's public key in advance. This preliminary setup enables the server to verify both message signatures and client identity during subsequent interactions.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If OAuth 2.0 DPoP mechanism is used for proof-of-possession, then authenticity of OAuth tokens is improved, but use cases other than OAuth and authenticity of HTTP request body and headers are not addressed

Engineering Contradiction:
ImproveOAuth token authenticityVSAvoidHTTP request authenticity
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent creates a universal authentication framework that works with any HTTP-based communication, not just OAuth. The bootstrap phase establishes a certificate-based trust relationship that can protect any HTTP request and response, regardless of the authentication protocol used. The signing phase provides a general-purpose mechanism for verifying both headers and body integrity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent adopts and adapts the DPoP concept of proof-of-possession but extends it beyond OAuth tokens to certificate-based authentication. Instead of copying only the OAuth token verification mechanism, the patent creates a broader framework that uses digital certificates as the proof-of-possession credential, applicable to all HTTP communications.

Inventive Principle:
Principle #26Copying

3Ease of operation

If no client verification mechanism is implemented, then ease of operation is improved, but security against fake clients and data interception is worsened

Engineering Contradiction:
Improvecommunication simplicityVSAvoidclient authenticity and data security
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent implements self-service authentication where the client autonomously obtains its own certificate from a trusted authority and self-registers with the server during the bootstrap phase. The client also independently signs its own requests using its private key. This self-service approach maintains operational simplicity while establishing strong security credentials.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent introduces a trusted certificate authority as an intermediary that issues certificates to clients and whose public key is distributed to servers. This intermediary enables mutual authentication without requiring complex peer-to-peer verification mechanisms, maintaining ease of operation while ensuring security through the trusted third party.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP4576667A1System and method to bring authenticity in the communication between mobile client and server
Publication Date: 2025.06.25 THALES DIS FRANCE SA
  • EP4576667A1 patent drawingFigure 1
  • EP4576667A1 patent drawingFigure 2
  • EP4576667A1 patent drawingFigure 3A

AI summary

A system (100) and method (800) for verifying the authenticity of communication between a mobile client (102) and a server (106) includes creating (802) a self-signed application binding certificate (104), establishing (804) a secure channel to communicate the application binding certificate with an application binding service (302), validating (806) the application binding certificate by the application binding service to register a public key at the server, setting (807) a validity and expiration for the application binding service, and sending (808) validation of the binding to the client. The system and method after successful binding, can sign (810) all sensitive requests at an HTTP level by the application binding private key that is verified by the application binding service ensuring the request's origin from a rightful mobile application and return (812) a verification status and application binding public key Id by the application binding service to a Backend Service (312).