Security Token Questions

K

Ken

Guest
I do business with a company that issues a security token, that when
used with a password, allows access to my account. I know it works and
has worked for years, but I was curious as to how it works:

The number the token generates changes every minute or so, so knowing
the number it generated a minute ago and the users password is of no
value unless used while the number is valid. My questions are:

How do they synchronize the timing of the token with that of the server
that receives it?

Since the token is good for several years before needing to be replaced,
how do they synchronize the generated number with the server?

I know this is an electronics newsgroup, but I thought if anyone knew
the answer to my questions, it would be here.
 
Ken <Ken@invalid.com> wrote:
I do business with a company that issues a security token, that when
used with a password, allows access to my account. I know it works and
has worked for years, but I was curious as to how it works:

The number the token generates changes every minute or so, so knowing
the number it generated a minute ago and the users password is of no
value unless used while the number is valid. My questions are:

How do they synchronize the timing of the token with that of the server
that receives it?

Since the token is good for several years before needing to be replaced,
how do they synchronize the generated number with the server?

I know this is an electronics newsgroup, but I thought if anyone knew
the answer to my questions, it would be here.
Click to expand...

The software does not accept only a single reply, but rather accepts
the numbers generated by the token at a range around the current time.
When you enter a code that was valid a minute ago, it does not reject
it but it accepts it and notes that the time in the token is apparently
a minute behind. The next time you use the token the range of time has
been shifted by a minute. This way the server "locks" to the drifting
time of the token. When you would not use it for a very long time it
could have drifted outside of the range, but in practice this does not
happen (the clock in the token is accurate enough).
 
In article <qm0apl$prq$1@dont-email.me>, Ken <Ken@invalid.com> wrote:
I do business with a company that issues a security token, that when
used with a password, allows access to my account. I know it works and
has worked for years, but I was curious as to how it works:

The number the token generates changes every minute or so, so knowing
the number it generated a minute ago and the users password is of no
value unless used while the number is valid. My questions are:

How do they synchronize the timing of the token with that of the server
that receives it?

Since the token is good for several years before needing to be replaced,
how do they synchronize the generated number with the server?

I know this is an electronics newsgroup, but I thought if anyone knew
the answer to my questions, it would be here.
Click to expand...

Take a look at writeups (e.g. Wikipedia) for TOTP (Time-based One-Time
Password).

To sum it up: the token dongle has its own time reference driven by a
stable oscillator (typically something like a watch-crystal). The
token's time is synchronized initially when it's first set up. It can
of course drift over time (initial tolerances, aging, temperature, and
so forth) just as a digital watch does.

The one-time password algorithm generates a unique password on a
fairly coarse time scale - e.g. once a minute. The server will
typically accept the validity of an OTP for longer than this e.g. for
an additional 30 seconds or a minute on either side of the "nominal"
minute. This allows for some amount of clock drift.

To deal with larger amounts of clock drift, the server can be
'adaptive'. That is, if it is offered a password which is (e.g.) "5
minutes out of date" or "5 minutes early", it may refuse it, but ask
the user to try again in another minute. If it receives several
one-minute passwords in a row, which are all valid but all "late" or
"early" by the same amount, the server can conclude that the
token-generator is valid but that its internal clock has drifted by
this amount. The server could then store the time offset along with
the token generator's ID - essentially resynchronizing itself with the
token generator.

A somewhat similar technique is often used for "rolling code" security
remote controls (e.g. car or garage door openers). If you accidentally
activate such a device while it's in your pocket, it can "waste" a
bunch of codes, and the car/garage receiver will still be expecting a
code that has already been used up. In order to resynchronize you can
push the remote button several times... a smart receiver will detect a
valid sequence of codes coming from a "later" point in the sequence it
was designed to accept, and will resynchronize.
 
Dave Platt wrote:
In article <qm0apl$prq$1@dont-email.me>, Ken <Ken@invalid.com> wrote:
I do business with a company that issues a security token, that when
used with a password, allows access to my account. I know it works and
has worked for years, but I was curious as to how it works:

The number the token generates changes every minute or so, so knowing
the number it generated a minute ago and the users password is of no
value unless used while the number is valid. My questions are:

How do they synchronize the timing of the token with that of the server
that receives it?

Since the token is good for several years before needing to be replaced,
how do they synchronize the generated number with the server?

I know this is an electronics newsgroup, but I thought if anyone knew
the answer to my questions, it would be here.

Take a look at writeups (e.g. Wikipedia) for TOTP (Time-based One-Time
Password).

To sum it up: the token dongle has its own time reference driven by a
stable oscillator (typically something like a watch-crystal). The
token's time is synchronized initially when it's first set up. It can
of course drift over time (initial tolerances, aging, temperature, and
so forth) just as a digital watch does.

The one-time password algorithm generates a unique password on a
fairly coarse time scale - e.g. once a minute. The server will
typically accept the validity of an OTP for longer than this e.g. for
an additional 30 seconds or a minute on either side of the "nominal"
minute. This allows for some amount of clock drift.

To deal with larger amounts of clock drift, the server can be
'adaptive'. That is, if it is offered a password which is (e.g.) "5
minutes out of date" or "5 minutes early", it may refuse it, but ask
the user to try again in another minute. If it receives several
one-minute passwords in a row, which are all valid but all "late" or
"early" by the same amount, the server can conclude that the
token-generator is valid but that its internal clock has drifted by
this amount. The server could then store the time offset along with
the token generator's ID - essentially resynchronizing itself with the
token generator.

A somewhat similar technique is often used for "rolling code" security
remote controls (e.g. car or garage door openers). If you accidentally
activate such a device while it's in your pocket, it can "waste" a
bunch of codes, and the car/garage receiver will still be expecting a
code that has already been used up. In order to resynchronize you can
push the remote button several times... a smart receiver will detect a
valid sequence of codes coming from a "later" point in the sequence it
was designed to accept, and will resynchronize.
Click to expand...
Very clever way of compensating for a time difference. Then are the
codes in all similar devices the same with respect to their code
sequence, just that each device started the sequence at a different time??
 
In article <qm0hul$8h5$1@dont-email.me>, Ken <Ken@invalid.com> wrote:

Very clever way of compensating for a time difference. Then are the
codes in all similar devices the same with respect to their code
sequence, just that each device started the sequence at a different time??
Click to expand...

Nope, not in the general case. Each individual device (or each
instance of a token-generating application on e.g. a smartphone) has
an individual secret (or secrets, if it's generating one-time
passwords for multiple services).

The service knows the secret for each device.

The one-time passwords (codes) are generated by a deterministic
process, which takes as input the time and the device secret. This
process is designed to be cryptographically strong... it's infeasible
to predict what one code will be, based on its predecessors, unless
you know the correct shared secret. It's also infeasible to "compute
back" and figure out the shared secret even if you know a large number
of the OTP codes that have been generated.

Thus, if you have two OTP generators, both generating codes for the
same service (for e.g. two different user-IDs), and both happen to
show a code of 123456 in this minute, it is extremely unlikely that
they'll display the same codes during the next minute.

You can, however, program two or more OTP generators with the same
shared secret, if you choose. For example, if you own a smartphone
and a tablet, you can sign up with a service that offers one-time-code
access, get your secret (some services deliver it as a scannable
barcode or QR code), and load the secret into an OTP-generating app on
both devices. These devices will then generate the same code
sequences and you can use either to authenticate.

The TOTP algorithm is standardized, so you can use different
OTP-generating dongles or apps based on a single shared secret, and
they'll all interoperate.

Different devices/apps can store their secrets differently. For
example, as I understand it, the Google Authenticator app for Android
stores the secrets in a smartphone's internal hardware-backed
keystore, and won't ever export them or back them up to a server. If
you lose or wipe the phone, all of the secrets are gone for good.

Other apps (e.g andOTP) store the secrets in the device's flash
memory, encrypted with a password that you must enter to use the app.
andOTP will allow you to export the secrets via email (after
encrypting them with a PGP key of your choice for security), and then
re-import them into a different phone or tablet.
 
On Thu, 19 Sep 2019 11:08:03 -0700, dplatt@coop.radagast.org (Dave
Platt) wrote:

To sum it up: the token dongle has its own time reference driven by a
stable oscillator (typically something like a watch-crystal).
Click to expand...

Tuning fork and watch quartz crystal oscillators out of fashion. The
better dongles use a MEMS RTC (real time clock) that has built in
temperature compensation via a lookup table. Drift is negligible:
<https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator>

I have a PayPal card by VeriSign, using OATH HOTP v2.1 that is crammed
into a credit card size sandwich with no lumps.
<http://blog.agm.me.uk/blog/uploaded_images/PayPaySecurityKey-706729.jpg>

More than you probably wanted to know:

"TOTP: Time-Based One-Time Password Algorithm"
<https://tools.ietf.org/html/rfc6238>

"HMAC-based One-time Password algorithm"
<https://en.wikipedia.org/wiki/HMAC-based_One-time_Password_algorithm>

"HOTP: An HMAC-Based One-Time Password Algorithm"
<https://tools.ietf.org/html/rfc4226>

The
token's time is synchronized initially when it's first set up. It can
of course drift over time (initial tolerances, aging, temperature, and
so forth) just as a digital watch does.

The one-time password algorithm generates a unique password on a
fairly coarse time scale - e.g. once a minute. The server will
typically accept the validity of an OTP for longer than this e.g. for
an additional 30 seconds or a minute on either side of the "nominal"
minute. This allows for some amount of clock drift.
Click to expand...

The authentication server does store the time offset. The real
question is how big a time step window does it allow for drift.
RFC6238 recommended time step is 30 seconds. All 4 of my key fobs are
set to 60 seconds.
"Validation and Time-Step Size"
<https://tools.ietf.org/html/rfc6238#section-5.2>
However, I've seen a few that are setup with absurdly long time steps.
My guess(tm) is the vendor doesn't want to deal with irate customers
who's cheap dongle suddenly doesn't work because of drift. In the
systems I've looked at, the server pre-calculates 2 previous and 2
later codes, all of which it will accept as valid. Sometimes it will
ask for the next code as a double check. With a 60 second time step,
these codes give a +/-4 minute window, which more than enough to deal
with any clock drift.



--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
Dave Platt <dplatt@coop.radagast.org> wrote:
You can, however, program two or more OTP generators with the same
shared secret, if you choose. For example, if you own a smartphone
and a tablet, you can sign up with a service that offers one-time-code
access, get your secret (some services deliver it as a scannable
barcode or QR code), and load the secret into an OTP-generating app on
both devices. These devices will then generate the same code
sequences and you can use either to authenticate.
Click to expand...

That works, but only when the device has accurate time synchronization
by another method. E.g. NTP.
If not, the times on the two devices will differ, and the algorithm
in the server that tracks the time offset will fail.
 
Jeff Liebermann <jeffl@cruzio.com> wrote:
Tuning fork and watch quartz crystal oscillators out of fashion. The
better dongles use a MEMS RTC (real time clock) that has built in
temperature compensation via a lookup table. Drift is negligible:
https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator
Click to expand...

Big fun when there is only a slight concentration of helium in the air!
 
On 20 Sep 2019 11:58:48 GMT, Rob <nomail@example.com> wrote:

Jeff Liebermann <jeffl@cruzio.com> wrote:
Tuning fork and watch quartz crystal oscillators out of fashion. The
better dongles use a MEMS RTC (real time clock) that has built in
temperature compensation via a lookup table. Drift is negligible:
https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator

Big fun when there is only a slight concentration of helium in the air!
Click to expand...

Yep, but it wasn't so "slight". The leak was about 120 liters of
liquid helium, which expands into 90,000 liters (or 90 cubic meters,
or 3,200 cubic feet) of helium gas. A typical MRI machine holds about
1,700 liters of liquid helium:
<https://www.usgs.gov/centers/nmic/helium-statistics-and-information>
<https://prd-wret.s3-us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/mcs-2019-heliu.pdf>
Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681

"iPhones Are Allergic to Helium"
<https://www.ifixit.com/News/iphones-are-allergic-to-helium>

Notice the size of the chip on the fingernail in the photo:
<https://www.sitime.com>


--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
Jeff Liebermann <jeffl@cruzio.com> wrote:
On 20 Sep 2019 11:58:48 GMT, Rob <nomail@example.com> wrote:

Jeff Liebermann <jeffl@cruzio.com> wrote:
Tuning fork and watch quartz crystal oscillators out of fashion. The
better dongles use a MEMS RTC (real time clock) that has built in
temperature compensation via a lookup table. Drift is negligible:
https://en.wikipedia.org/wiki/Microelectromechanical_system_oscillator

Big fun when there is only a slight concentration of helium in the air!

Yep, but it wasn't so "slight". The leak was about 120 liters of
liquid helium, which expands into 90,000 liters (or 90 cubic meters,
or 3,200 cubic feet) of helium gas. A typical MRI machine holds about
1,700 liters of liquid helium:
https://www.usgs.gov/centers/nmic/helium-statistics-and-information
https://prd-wret.s3-us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/mcs-2019-heliu.pdf
Incidentally, 90 cubic-meters at $7.57/cubic-meter = $681

"iPhones Are Allergic to Helium"
https://www.ifixit.com/News/iphones-are-allergic-to-helium
Click to expand...

That was the incident that made this wellknown, but others have tried
to replicate it and found it doesn't require nearly that high a
concentration! For example, see the youtube movie on the Applied Science
channel: https://www.youtube.com/watch?v=vvzWaVvB908
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top