Sécurité et traitement des données

Sécurité et transparence

• Client mobile open source (GitHub)
• Modèle de sécurité public et analyse des menaces
• Architecture d’authentification access-first
• Autorisation cryptographique liée à l’appareil
• Demandes d’autorisation à usage unique et de courte durée
• Stockage sécurisé des clés (Secure Enclave / Android Keystore)
• Aligné sur les pratiques de sécurité OWASP
• Processus de build et de publication reproductible
• Programme de divulgation responsable des vulnérabilités

Principes de sécurité

Toqen.app est conçu selon une approche axée sur la sécurité et la minimisation des données. L’application traite uniquement les données nécessaires pour prendre en charge l’authentification, la confirmation d’accès et la sécurité du service.

• Les secrets d’authentification sensibles sont conservés sur l’appareil de l’utilisateur lorsque le système d’exploitation le permet.
• L’authentification repose sur la vérification de l’appareil et une preuve cryptographique.
• Seules les données minimales nécessaires au traitement et à la vérification des demandes d’authentification sont gérées par les services backend.
• Une interaction explicite de l’utilisateur est requise pour les actions d’accès sensibles.

Architecture de sécurité

Toqen.app est conçu pour que l’authentification soit réalisée à l’aide d’une vérification cryptographique liée à l’appareil.

• Chaque appareil génère une paire de clés cryptographiques unique lors de l’enregistrement.
• Les clés privées restent stockées sur l’appareil et ne sont pas partagées avec les serveurs de Toqen.
• L’authentification est réalisée en signant un challenge fourni par le serveur.
• Le serveur vérifie la signature à l’aide de la clé publique correspondante.

Sécurité de l’appareil

• Les clés privées sont stockées à l’aide de mécanismes de stockage sécurisé fournis par le système d’exploitation lorsque disponibles.
• Les données sensibles sont isolées des données générales de l’application lorsque la plateforme le permet.
• L’accès aux données sensibles peut nécessiter une authentification au niveau de l’appareil, comme la biométrie ou un code PIN, selon les capacités de l’appareil et les paramètres de l’utilisateur.
• La sécurité des données locales dépend en partie de l’intégrité et de l’état de sécurité de l’appareil de l’utilisateur.

Protection et chiffrement des données

• Les données sensibles stockées localement sont protégées par des mécanismes de stockage sécurisé et de chiffrement pris en charge par la plateforme.
• Les communications entre l’application et les services backend sont protégées par des protocoles de transport sécurisés.
• Des mécanismes de coffre chiffré peuvent être utilisés pour protéger les données d’accès stockées localement.

Flux d’authentification

L’authentification est effectuée au moyen d’un mécanisme challenge-response nécessitant une interaction explicite de l’utilisateur.

• Une demande d’authentification temporaire est générée par un service.
• L’appareil signe le challenge à l’aide de sa clé privée.
• La signature résultante est envoyée pour vérification.
• L’accès n’est accordé qu’après une vérification réussie et une confirmation de l’utilisateur.

Données temporaires

• Les demandes d’authentification et les challenges ont une durée de vie courte.
• Les jetons temporaires ou les données de demande expirent automatiquement après une période définie.
• Les données d’authentification expirées ne sont pas destinées à être réutilisées.

Contrôle d’accès

• Les actions sensibles nécessitent une approbation explicite de l’utilisateur.
• Les écrans de confirmation d’accès sont conçus pour fournir du contexte avant l’approbation.
• Les tentatives d’accès non autorisées ou invalides sont rejetées par la logique de vérification lorsque cela s’applique.

Traitement côté serveur

• Le serveur stocke les clés publiques et des métadonnées limitées requises pour la vérification et la sécurité du service.
• Les clés privées ne sont jamais intentionnellement transmises au serveur.
• Les systèmes côté serveur sont conçus pour valider les demandes, appliquer leur durée de vie et réduire les risques de rejeu.

Limites de sécurité et responsabilité de l’utilisateur

Aucun système technique ne peut garantir une sécurité absolue. L’efficacité des protections de l’appareil dépend de facteurs tels que la sécurité du système d’exploitation, l’intégrité de l’appareil, la configuration de l’utilisateur et la gestion sûre des demandes d’authentification.

• Les utilisateurs sont responsables de la protection de leur appareil, de leurs méthodes de déverrouillage et de leurs identifiants d’accès.
• Les utilisateurs doivent examiner le contexte d’authentification avant de confirmer l’accès.
• La perte d’accès à l’appareil peut nécessiter des mécanismes de récupération lorsqu’ils sont disponibles.
• Les appareils compromis, modifiés ou non sécurisés peuvent réduire l’efficacité des protections au niveau de l’application.

Mises à jour de sécurité

Les mesures de sécurité peuvent être mises à jour à mesure que le système évolue. Ces mises à jour visent à améliorer la protection, à maintenir la compatibilité et à traiter les risques nouvellement identifiés.

Modifications de cette politique

Cette politique peut être mise à jour pour refléter les changements de fonctionnalité, de mesures de sécurité ou d’exigences légales. La dernière version sera publiée avec une date mise à jour.

Contact