Nonce-Based Identity Verification via Push Notification Channels

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing authentication methods for client applications face challenges in ensuring secure communication with servers, particularly for third-party applications, as they may expose tokens to extraction by attackers and struggle with obtaining authentication due to lack of authorization and one-way secure channels.

Innovation Solution

A system where a client electronic device generates and manages nonces, using a secure and authenticated communication channel to authenticate with a server, leveraging a push mechanism to securely transmit and verify nonces, ensuring only authenticated devices receive the decryption key, thus establishing a secure channel for service requests.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a token is bundled with the application, then identity verification can be performed, but the token may be extracted by attackers and used for spoofing

Engineering Contradiction:
Improveidentity verificationVSAvoidtoken extraction and spoofing
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The authentication system is divided into two separate channels: a one-way secure authenticated channel from device to server for obtaining tokens, and a separate service request channel. The token itself is segmented from the application binary, stored securely in the device, and only transmitted through the secure channel when needed, preventing extraction from the application itself.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The operating system's push notification service acts as an intermediary that establishes the secure authenticated channel between the device and server. This intermediary manages the authentication process, verifies device identity, and securely delivers tokens to the application without exposing them in the application binary.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If third-party applications are permitted to communicate with servers, then service functionality is enabled, but authentication security may be compromised

Engineering Contradiction:
Improvethird-party application supportVSAvoidauthentication security
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The secure authenticated channel mechanism is designed as a universal system that works for all applications on the device, whether native or third-party. The operating system's push notification service provides a common authentication infrastructure that all applications can use, ensuring consistent security standards across different application types.

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

Solution Approach 2:

The system implements a feedback mechanism where the server sends a push notification back to the device through the secure channel to confirm token delivery. This two-way verification ensures that the application receiving the token is indeed the legitimate application on the authenticated device, preventing unauthorized use by third-party applications.

Inventive Principle:
Principle #23Feedback

3Reliability

If a one-way secure authenticated channel is used from device to server, then token delivery is secure, but two-way verification is not achieved

Engineering Contradiction:
Improvetoken delivery securityVSAvoidchannel architecture
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system transitions from a static one-way channel to a dynamic two-way communication process. The initial secure channel flows from device to server for token request, then dynamically reverses direction when the server sends the push notification back to the device, creating an adaptive bidirectional verification system without requiring a permanently established two-way secure channel.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP3602991B1Mechanism for achieving mutual identity verification via one-way application-device channels
Publication Date: 2022.02.02 GOOGLE LLC
  • EP3602991B1 patent drawingFigure 1
  • EP3602991B1 patent drawingFigure 2
  • EP3602991B1 patent drawingFigure 3

AI summary

To authenticate a service request, a first server receives a handshake request from a client application (202). The first server transmits a first nonce to the client application (203). The first server sends a second nonce and the handshake request to a second server (204). The first server stores a result of an operation performed on the nonces (205). The client application receives a push notification with the second nonce from the second server via a secure and authenticated communication channel (207). The client application also performs an operation on the nonces to generate a candidate result, which it sends to the first server (209). If the candidate result matches the stored result, the first server will send the client application a token that grants access to a service (210, 211). The operation on the nonces can include the encryption of the first nonce using the second nonce.