Security and Data Handling

Security & Transparency

• Open source mobile client (GitHub)
• Public security model and threat analysis
• Access-first authentication architecture
• Device-bound cryptographic authorization
• Short-lived, single-use authorization requests
• Secure key storage (Secure Enclave / Android Keystore)
• Aligned with OWASP security practices
• Reproducible build and release process
• Responsible vulnerability disclosure program

Security Principles

Toqen.app is designed with a security-first and data-minimization approach. The application processes only the data required to support authentication, access confirmation, and service security.

• Sensitive authentication secrets are kept on the user’s device where supported by the operating system.
• Authentication is based on device verification and cryptographic proof.
• Only the minimum data required to process and verify authentication requests is handled by backend services.
• Explicit user interaction is required for sensitive access actions.

Security Architecture

Toqen.app is designed so that authentication is performed using device-based cryptographic verification.

• Each device generates a unique cryptographic key pair during registration.
• Private keys remain stored on the device and are not shared with Toqen servers.
• Authentication is performed by signing a server-provided challenge.
• The server verifies the signature using the corresponding public key.

Device Security

• Private keys are stored using secure storage mechanisms provided by the operating system where available.
• Sensitive data is isolated from general application data where supported by the platform.
• Access to sensitive data may require device-level authentication such as biometrics or PIN, depending on device capabilities and user settings.
• The security of local data depends in part on the integrity and security state of the user’s device.

Data Protection and Encryption

• Sensitive data stored locally is protected using secure storage and encryption mechanisms supported by the platform.
• Communication between the application and backend services is protected using secure transport protocols.
• Encrypted vault mechanisms may be used to protect locally stored access-related data.

Authentication Flow

Authentication is performed through a challenge-response mechanism requiring explicit user interaction.

• A temporary authentication request is generated by a service.
• The device signs the challenge using its private key.
• The resulting signature is sent for verification.
• Access is granted only after successful verification and user confirmation.

Temporary Data

• Authentication requests and challenges are short-lived.
• Temporary tokens or request data expire automatically after a defined period.
• Expired authentication data is not intended for reuse.

Access Control

• Sensitive actions require explicit user approval.
• Access confirmation screens are designed to provide context before approval.
• Unauthorized or invalid access attempts are rejected by verification logic where applicable.

Server-Side Handling

• The server stores public keys and limited metadata required for verification and service security.
• Private keys are never intentionally transmitted to the server.
• Server-side systems are designed to validate requests, enforce request lifetimes, and reduce replay risks.

Security Limits and User Responsibility

No technical system can guarantee absolute security. The effectiveness of device protections depends on factors such as operating system security, device integrity, user configuration, and safe handling of authentication requests.

• Users are responsible for protecting their device, device unlock methods, and access credentials.
• Users should review authentication context before confirming access.
• Loss of device access may require recovery mechanisms where available.
• Compromised, modified, or insecure devices may reduce the effectiveness of application-level protections.

Security Updates

Security measures may be updated as the system evolves. Updates are intended to improve protection, maintain compatibility, and address newly identified risks.

Changes to this Policy

This policy may be updated to reflect changes in functionality, security measures, or legal requirements. The latest version will be published with an updated date.

Contact