Biometric Session Tokens Preventing Man-in-the-Middle Attacks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing secure communication systems over networks are vulnerable to man-in-the-middle attacks, which can compromise user authentication and data integrity due to reliance on static credentials and public key impersonation.
Innovation Solution
The implementation of dynamic biometrics tokens, where biometrics information is used to generate unique hashes for encrypting and authenticating communications between clients and servers, ensuring that only genuine public keys are used, thereby preventing MITM attacks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If static credentials and public keys are used for authentication, then the authentication process is simple and fast, but the system becomes vulnerable to man-in-the-middle attacks and credential hijacking
Solution Approach 1:
The patent applies dynamics by transitioning from static credentials to dynamic biometric tokens that change with each authentication session. The server generates a unique biometric token for each user session, and the client encrypts session data using this dynamic token. This ensures that even if credentials are intercepted, they cannot be reused for MITM attacks, as each session has a fresh token derived from the user's biometric data.
Solution Approach 2:
The patent changes the authentication parameter from static public keys to dynamic biometric tokens. The biometric token is generated fresh for each session and incorporates the user's biometric characteristics. This parameter change makes it impossible for attackers to use captured tokens for subsequent attacks, as each token is unique to its session and cannot be replicated.
2Reliability
If biometric tokens are generated for each session, then MITM attacks are prevented, but the system complexity and computational overhead increase
Solution Approach 1:
The system implements self-service by having the client device perform the encryption operation locally using the biometric token. The client generates the encryption key pair and encrypts session data using the server's biometric token, then sends only the encrypted data to the server for validation. This shifts the computational burden to the client's local resources, reducing server complexity while maintaining high security.
Solution Approach 2:
The patent introduces an intermediary mechanism where the biometric token acts as a mediator between the client and server. Instead of direct public key exchange that is vulnerable to MITM, the biometric token serves as a secure intermediary that both parties trust. The server generates the token, the client uses it to encrypt data, and the server validates the encrypted data, creating a secure intermediary channel that prevents direct attacker interpolation.
3Ease of operation
If traditional session tokens are used, then the authentication flow is straightforward, but the tokens are prone to hijacking and simulation by attackers
Solution Approach 1:
The patent applies copying by having the client create a copy of the session data encrypted with the biometric token. The client encrypts a copy of the session data using the server's biometric token and sends this encrypted copy to the server for validation. This copying mechanism ensures that even if the original session token is intercepted or simulated, the encrypted copy with the biometric token provides authentication security, as the biometric token cannot be copied or simulated without the user's biometric data.
Data Source
AI summary
Communications between a client and an application server can be authenticated based on biometrics information about a user. After basic client authentication by the application server, the application server queries a biometrics server that has user biometrics information. The biometrics server provides the biometrics information to the application server in the form of a hash and the application server stores it in an application database for future comparison. The application server sends an unencrypted token to the client. The client queries biometrics information from the biometrics servers, which is provided in a hash. The client uses the biometrics information to encrypt the unencrypted token received from the application server and sends the encrypted token to the application server for validation. The application server hashes the encrypted token received from the client and compares it to the hash stored in the application database. If the hashes match, the communications are authenticated. The process can be repeated for subsequent tokens until the customer logs out.