Authentication Proving Key Protection Against Brute Force

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing user authentication systems face challenges in securely storing and managing private keys, as they often require storing weak secrets, which can be vulnerable to brute force attacks, especially when short PIN codes are used.

Innovation Solution

A method and device where a protected key is stored instead of the proving key, transforming into a proving key only when the correct secret is provided, ensuring that even incorrect secrets produce a proving key that is computationally indistinguishable from the correct one, preventing brute forcing and maintaining security without storing the proving key on either the prover or verifier.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the weak secret is sent to the verifier and stored in a database, then the verifier can perform verification of the weak secret, but the system becomes vulnerable to brute force attacks especially with short PIN codes

Engineering Contradiction:
Improveauthentication verification capabilityVSAvoidbrute force attack vulnerability
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The invention extracts the weak secret from the verification process. Instead of storing or transmitting the weak secret to the verifier, only a protected version (protected proving key) is stored on the prover. The weak secret remains exclusively on the prover side, eliminating the verifier's exposure to brute force attacks while maintaining verification capability through the protected key.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The invention transforms the weak secret from a directly usable verification value into a protected proving key through a protection mechanism. This dimensional transformation means the weak secret exists in a protected state during storage and transmission, only becoming usable in its original form within the secure environment of the prover, thus adding a security dimension to the authentication flow.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Reliability

If the weak secret is used to encapsulate the private key on the prover side, then key integrity is ensured, but the private key becomes vulnerable to brute force after obtaining the encapsulated key

Engineering Contradiction:
Improvekey integrityVSAvoidbrute force vulnerability of private key
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The invention extracts the private key from direct exposure to the weak secret. Instead of using the weak secret to encapsulate/encrypt the private key, the system uses the protected proving key (which is itself protected by the weak secret) to derive the private key only within the secure prover environment. This separation ensures that even if the protected proving key is obtained, the private key remains protected.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The invention performs preliminary protection of the proving key before it is used to generate the private key. The weak secret protects the proving key in advance, and only the protected version is stored or transmitted. The actual private key generation happens later in a secure environment, ensuring that the private key is never exposed in a vulnerable state.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If the prover stores the proving key in plain, then authentication processing is simplified, but the proving key becomes vulnerable to unauthorized access and compromise

Engineering Contradiction:
Improveauthentication processing simplicityVSAvoidproving key compromise risk
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The invention extracts the plaintext proving key from storage and transmission. Instead of storing the proving key in plain, the system stores only the protected proving key on the prover and the verification key on the verifier. The plaintext proving key is never stored, only generated temporarily in memory during authentication operations, thus eliminating storage vulnerabilities while maintaining operational simplicity.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The invention introduces a protected proving key as an intermediary between the weak secret and the verification process. This intermediary protects the actual proving key during storage and transmission, acting as a secure mediator that enables authentication without exposing the sensitive proving key material.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If the verifier stores the verification key, then authentication verification is enabled, but the system requires secure key management infrastructure

Engineering Contradiction:
Improveauthentication verification capabilityVSAvoidkey management infrastructure complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The invention extracts the sensitive key management requirements from the verifier. Instead of requiring the verifier to store and manage both weak secrets and proving keys, the system only requires the verifier to store the public verification key, which cannot be compromised to reveal other keys. This extraction significantly reduces the verifier's key management infrastructure complexity.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP3224983B1A method and device for authentication
Publication Date: 2024.09.04 BELGIAN MOBILE ID NV
  • EP3224983B1 patent drawingFigure 1
  • EP3224983B1 patent drawingFigure 2

AI summary

A method for authenticating a prover to a verifier, the prover being provided with a proving key paired to a verification key registered with the verifier, wherein the proving key can be obtained by transforming a protected key and a secret (S) using a transformation (E), characterized in that the prover stores the protected key and does not store the corresponding proving key nor the corresponding verification key in clear, with the exception of storage in transient memory.