Nous sommes heureux d'annoncer la nouvelle gamme de clés matérielles programmables TOTP de TOKEN2. La principale innovation est la possibilité de synchroniser l'horloge système des clés matérielles via l'API NFC à l'aide d'applications spéciales - une version pour Android et Windows 10 est en cours de préparation.
Il n'y a pas encore d'applications pour iOS: malgré le fait que les puces NFC soient physiquement présentes sur les derniers modèles d'iPhone, Apple ne fournit pas encore d'API publique pour leur utilisation.
À quoi ça sert?
Contrairement aux applications mobiles TOTP, dans les clés matérielles, il n'y a aucun moyen de synchroniser l'heure via NTP, sur un réseau cellulaire ou un signal radio: les clés matérielles de l'appareil sont complètement isolées et autonomes, et utilisent l'horloge sur leur carte comme source d'heure précise. Dans les années 1933-1934. les physiciens Scheibe et Adelsberger de l'Institut impérial de physique et de technologie de Berlin ont saisi les possibilités d'utilisation de l'effet piézoélectrique pour mesurer le temps. C'est cet effet qui sous-tend l'horloge système des clés matérielles. La précision de ces montres varie de ± 0,3 à ± 1,1 s / jour, selon la qualité. Si cette précision est suffisante pour une montre-bracelet classique, dans les clés matérielles un décalage horaire supérieur à une certaine limite peut conduire à un refus d'activation et / ou d'authentification. Cette limite dépend du système spécifique (par exemple, Microsoft Azure MFA autorise jusqu'à 600 secondes de biais dans les deux directions) lorsqu'il s'agit du premier enregistrement d'une clé matérielle. De plus, le processus de synchronisation de décalage pendant l'utilisation de la touche pour entrer est déjà clairement décrit dans la
RFC 6238RFC 6238 / 6. ResynchronisationEn raison d'éventuelles dérives d'horloge entre un client et une validation
serveur, nous RECOMMANDONS que le validateur soit défini avec une limite spécifique
au nombre de pas de temps qu'un prouveur peut être "désynchronisé" avant
être rejeté.
Cette limite peut être définie à la fois en avant et en arrière à partir du
pas de temps à la réception de la valeur OTP. Si le pas de temps est
30 secondes comme recommandé, et le validateur est configuré pour accepter uniquement
deux pas de temps en arrière, alors la dérive maximale du temps écoulé serait
environ 89 secondes, soit 29 secondes dans le pas de temps calculé et
60 secondes pour deux pas de temps en arrière.
Cela signifierait que le validateur pourrait effectuer une validation par rapport au
heure actuelle, puis deux validations supplémentaires pour chaque étape en arrière
(pour un total de 3 validations). Une fois la validation réussie, le
le serveur de validation peut enregistrer la dérive d'horloge détectée pour le jeton
en termes de nombre de pas de temps. Lorsqu'un nouveau OTP est reçu
après cette étape, le validateur peut valider l'OTP avec le courant
horodatage ajusté avec le nombre de dérives d'horloge enregistrées
pour le jeton.
De plus, il est important de noter que plus un justificatif n'a pas envoyé
un OTP à un système de validation, plus (potentiellement) la
dérive accumulée de l'horloge entre le prouveur et le vérificateur. Dans un tel
Dans certains cas, la resynchronisation automatique décrite ci-dessus peut ne pas fonctionner
si la dérive dépasse le seuil autorisé. Supplémentaire
des mesures d'authentification doivent être utilisées pour authentifier en toute sécurité
prouveur et resynchroniser explicitement la dérive d'horloge entre le
prouveur et validateur.
Autrement dit, si le serveur d'authentification satisfait à toutes les exigences de la RFC, et si la clé n'est pas utilisée très rarement pour l'authentification, par exemple, au moins deux fois par an (le nombre exact peut être calculé en tenant compte de la précision de l'oscillateur et du décalage horaire autorisé par le serveur), alors les décalages temporels seront pris en compte côté serveur et aucun problème ne devrait survenir. Lorsque vous utilisez des clés dans de telles conditions, la fonction de synchronisation de l'heure n'est en principe pas nécessaire.
Cependant, la fonction de synchronisation horaire peut être utile dans les cas suivants:
- Si l'implémentation de serveur de TOTP ne suit pas la recommandation RFC6238 # 6. Un exemple d'une telle implémentation est DUO :
La dérive et la resynchronisation des jetons TOTP ne sont pas prises en charge. Par conséquent, les jetons TOTP importés peuvent ne pas fonctionner pour l'authentification avec Duo Security, ou peuvent ne pas fonctionner pour l'authentification après une période de temps variable ...
- Si un lot de clés matérielles a été acheté pendant longtemps, mais qu'elles n'ont dû être activées qu'après un certain temps - dans ce cas, il n'y a tout simplement pas de mécanisme de synchronisation dans de nombreux systèmes.
- Si le dongle est utilisé pour la connexion moins souvent que nécessaire pour la synchronisation. Par exemple, si un utilisateur souhaite «copier» le même profil TOTP (plus précisément, un secret partagé) sur deux appareils: a) sur une application mobile sur le téléphone pour un usage quotidien et b) sur une clé matérielle programmable comme sauvegarde, pour un jour de pluie . Ainsi, si ce jour de pluie arrive dans 3-4 ans, le jeton matériel ne peut plus être utilisé précisément en raison du décalage horaire. De plus, la batterie du token, qui ne s'est pas allumée depuis longtemps, ne perd presque pas de capacité. Par conséquent, dans ce cas, il est assez simple de «mettre» l'horloge sur eux pour les remettre en fonctionnement.
Analyse de sécuritéComme toujours, ce type d'innovation est toujours basé sur un équilibre entre confort / commodité et niveau de sécurité. Les clés programmables avec la possibilité de synchroniser le temps des attaques réseau (phishing, personnes au milieu, etc. - sont dans la plupart des cas que nos clients utilisent des jetons TOTP précisément pour se protéger contre de telles attaques), elles protégeront certainement entièrement, mais cette possibilité implique une probabilité négligeable et purement
théorique d'une attaque au moyen d'une attaque de rejeu (attaque de rejeu) à condition que les attaquants puissent:
- Obtenez le premier facteur (mot de passe).
- Avoir un accès physique à la clé matérielle à l' insu du propriétaire pendant une durée suffisamment longue (voir étape 3.).
- À l'aide de l'application, via NFC, traduisez l'heure de la clé vers l'avant à une date spécifique et enregistrez un nombre suffisant de codes générés. Cela ne fonctionnera pas avec un script, car pour générer des codes, vous devez cliquer sur le bouton physique, et le code actuel ne peut être vu qu'à l'écran (il n'est pas transmis via NFC).
- Renvoyez l'heure ( pour que le propriétaire ne devine rien ).
- Et enfin, connectez-vous en utilisant le mot de passe (étape 1) et l'un des codes reçus à l'étape 3.
Ce risque, comme nous le voyons, ne peut survenir que sous la condition d'un accès physique à l'appareil, par exemple, une attaque peut être effectuée par un collègue assis à proximité et, pour une raison quelconque, connaissant également le mot de passe. Mais dans de telles conditions, l'utilisation de jetons TOTP classiques entraînera le même risque. Soit dit en passant, le risque de compromettre les jetons avec la fonction de synchronisation horaire est comparable au risque des appareils fido u2f - si un attaquant a temporairement et imperceptiblement accès à une clé u2f tout en ayant un mot de passe, il peut se connecter au système avec cette clé et ajouter une autre (sa) clé et puis retournez tout aussi discrètement la clé d'origine au propriétaire - selon les spécifications, un compte peut avoir plus d'une clé u2f, et n'importe lequel peut être utilisé pour une connexion parallèle. Des facteurs tels que
les mots de passe papier parfaits sont au même risque.
Comme vous pouvez le voir, l'attaque est assez complexe et peu probable, et en général, le niveau de risque d'utilisation de tels jetons peut être comparé à l'utilisation d'une application telle que Google Authenticator sur un smartphone sans code PIN, sans accès au réseau et que l'utilisateur porte toujours avec lui.
Pour les clients qui considèrent encore que ce risque est assez important, nos recommandations à ce sujet sont les suivantes:
- Limiter l'accès physique à ce type de clés est à peu près le même que pour les cartes bancaires (au fait, nos clés sont au format de cartes bancaires).
- Utiliser des touches programmables sans fonction de synchronisation horaire ( miniOTP-1 )
- Utilisez des touches programmables avec une fonction de synchronisation de l'heure, combinée à la suppression de la clé secrète. Autrement dit, lorsque l'heure du jeton change, la graine sera réinitialisée et il sera nécessaire de la ressaisir (miniOTP-3, la date de sortie du modèle sera annoncée en plus)
Où acheter?La précommande est ouverte sur notre site Internet. Utilisez le code promotionnel
HABR2019 pour une remise de 10% (nombre limité de coupons). Livraison par courrier postal (SwissPost ou La Poste France). Avec la livraison dans les pays de la CEI, il n'y a toujours pas de problèmes.