Programmable hardware TOTP keys with the ability to synchronize time
We are pleased to announce a new line of programmable hardware TOTP keys from TOKEN2. The main innovation is the ability to synchronize the system clock hardware keys via the NFC API using special applications - at the moment is preparing a release for Android and Windows 10.There are no applications for iOS yet: despite the fact that NFC chips are physically present on the latest iPhone models, Apple does not yet provide a public API for their use.
What is it for?
Unlike mobile TOTP applications, hardware keys do not have the ability to synchronize time over NTP, over a cellular network or radio signal: the hardware keys of the device are completely isolated and autonomous, and use a clock on their board as a source of accurate time. In 1933-1934 physicists Scheibe and Adelsberger of the imperial Physics and Technology Institute in Berlin took up the possibilities of using the piezoelectric effect to measure time. It is this effect that underlies the system clock of the hardware keys. The accuracy of such hours varies from ± 0.3 to ± 1.1 s / day, depending on the quality. If for an ordinary wristwatch this accuracy is sufficient, in hardware keys the difference in time more than a certain limit may lead to a failure in activation and / or authentication. This limit depends on the specific system (for example, Microsoft Azure MFA allows up to 600 seconds bias to both sides) when it comes to first registering the hardware key. Further, the process of synchronizing the bias during the use of the key for entry is already clearly described in RFC 6238
RFC 6238 / 6. Resynchronization
Clock drifts
server, we set that a validator
“out of synch” before
being rejected.
')
This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. If the time step is
30 seconds as recommended
two time steps backward, then the maximum elapsed time drift would be
around 89 seconds, ie, 29 seconds in the calculated time step and
60 seconds for two backward time steps.
It is a validator against the
backward step
(for a total of 3 validations). Upon successful validation, the
drift for the token
in terms of the number of time steps. When a new OTP is received
after this step, you can validate the OTP with the current
timestamp adjusted with clock drifts
for the token.
Also, it’s not important.
(potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization
if the drift exceeds the allowed threshold. Additional
authentication measures should not be used
prover and explicitly resynchronize the clock drift between the
prover and the validator.
server, we set that a validator
“out of synch” before
being rejected.
')
This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. If the time step is
30 seconds as recommended
two time steps backward, then the maximum elapsed time drift would be
around 89 seconds, ie, 29 seconds in the calculated time step and
60 seconds for two backward time steps.
It is a validator against the
backward step
(for a total of 3 validations). Upon successful validation, the
drift for the token
in terms of the number of time steps. When a new OTP is received
after this step, you can validate the OTP with the current
timestamp adjusted with clock drifts
for the token.
Also, it’s not important.
(potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization
if the drift exceeds the allowed threshold. Additional
authentication measures should not be used
prover and explicitly resynchronize the clock drift between the
prover and the validator.
That is, if the authentication server complies with all RFC prescriptions, and if the key is used for authentication is not too rare, for example, at least a couple of times a year (the exact number can be calculated using an oscillator that takes into account the accuracy and the time offset allowed by the server) on the server side and problems should arise. When using keys in such conditions, the time synchronization function is basically not needed.
However, the time synchronization function can be useful in the following cases:
- If the server implementation of TOTP does not follow RFC6238 recommendation # 6. One example of such an implementation is DUO :
TOTP token drift and resynchronization are not supported. It is not necessary to work with the system to ensure that it can be verified.
- If a batch of hardware keys was purchased a long time ago, but they had to be activated only after some time - in this case there is simply no synchronization mechanism in many systems.
- If the hardware key is used to log in less often than needed for synchronization. For example, if a user wants to “copy” the same TOTP profile (or rather the secret key - shared secret) to two devices: a) to the mobile application on the phone for everyday use and b) to the programmable hardware key as a backup for a rainy day . Thus, if this rainy day comes in 3-4 years, the hardware token will no longer be used precisely because of the time difference. And the battery on the token, which has not been turned on for a long time, almost does not lose capacity. Consequently, in this case, it is enough just to “set” the clock on them in order to return them to the system.
Security analysis
As always, this kind of innovation is always based on a balance of comfort / convenience and level of security. Programmable keys with the ability to synchronize time, from attacks over the network (phishing, a man in the middle, etc. - in most cases our clients use TOTP tokens to protect against such attacks) are not an exception, they will certainly protect to the full, but This feature assumes a minor and purely theoretical probability of an attack by replay (attack) with the condition that attackers can:
This risk, as we see, can arise only if there is a physical access to the device, for example, the attack can be carried out by a colleague sitting next to and for some reason also knowing the password. But under these conditions, using classic TOTP tokens will lead to the same risk. By the way, the risk of compromising tokens with the time synchronization function is comparable to the risk of fido u2f devices - if an attacker temporarily and imperceptibly got access to the u2f key while having a password, he can log in with this key and add another (his) key and then, also imperceptibly, return the initial key to the owner — according to the specification, one account can have more than one u2f key, and any one can be used for parallel input. Factors like Perfect paper passwords are subject to the same risk.
As you can see, the attack is quite complex and unlikely, and in general, the risk level of using such tokens can be compared to using an application like Google Authenticator on a smartphone without a pin code, not having access to the network and which the user always carries with them.
For customers who still consider even this risk to be big enough, our recommendations on this matter are as follows:
- Get the first factor (password).
- Have physical access to the hardware key without the knowledge of the owner for quite a long time (see step 3.).
- Using the application, through NFC, transfer the time on the key forward to a specific date, and record a sufficient number of generated codes. The script will not implement this, since to generate codes, you need to press a physical button, and the current code is only peeked on the screen (it is not transmitted via NFC).
- Return time back ( so that the owner did not guess anything ).
- And finally, log in using the password (step 1) and one of the codes obtained in step 3.
This risk, as we see, can arise only if there is a physical access to the device, for example, the attack can be carried out by a colleague sitting next to and for some reason also knowing the password. But under these conditions, using classic TOTP tokens will lead to the same risk. By the way, the risk of compromising tokens with the time synchronization function is comparable to the risk of fido u2f devices - if an attacker temporarily and imperceptibly got access to the u2f key while having a password, he can log in with this key and add another (his) key and then, also imperceptibly, return the initial key to the owner — according to the specification, one account can have more than one u2f key, and any one can be used for parallel input. Factors like Perfect paper passwords are subject to the same risk.
As you can see, the attack is quite complex and unlikely, and in general, the risk level of using such tokens can be compared to using an application like Google Authenticator on a smartphone without a pin code, not having access to the network and which the user always carries with them.
For customers who still consider even this risk to be big enough, our recommendations on this matter are as follows:
- Restricting physical access to this type of keys is approximately the same as to bank cards (by the way, our keys are in the format of bank cards).
- Use programmable keys without time synchronization ( miniOTP-1 )
- Use programmable keys with the function of time synchronization, combined with the removal of the secret key. That is, when the time of the token changes, the seed will be reset and you will need to re-enter it (miniOTP-3, the model release date will be announced later)
Where can one buy?
Pre-order is open on our website. Use promo code HABR2019 for a 10% discount (the number of coupons is limited). Delivery by regular mail (SwissPost or La Poste France). Delivery to the CIS countries has not yet arisen.
Source: https://habr.com/ru/post/435858/
All Articles