42

My bank has recently sent me a Digipass/Secure Key, which looks like a tiny calculator. You press the green button to turn it on, type a PIN to unlock it, then press the green button again to generate a 6-digit code that you type when logging in.

However, I don't actually understand how this device increases security. I'm assuming every device is linked to a person's account. But there is no communication from the device. I can press the button 10 times and generate 10 different codes, any of which seem to work.

How does the bank know the code is genuine?

DisgruntledGoat
  • 524
  • 1
  • 4
  • 9
  • 1
    Do you put your card in it? Or there is a serial number on it you gave to the bank so they know what the PRNG is seeded to? – ewanm89 Nov 12 '12 at 01:22
  • @ewanm89 And anyone else who doesn't know what they look like - http://i.telegraph.co.uk/multimedia/archive/01844/PF-HSBC-Secure-Key_1844367c.jpg – BrownEyes Nov 21 '13 at 09:33
  • @scorpion there are two different types in user in the UK by various banks. They look similar but work it different ways. 1) put there card in type in the pin, card verifies it and spots out a cryptographical prng generated output only valid for given nonce. Server runs same algorithm and verifies answers match. 2) works the same way but smartcard chip already embedded doing away with the external card reader. – ewanm89 Nov 21 '13 at 10:08
  • Mine (for CIB, not HSBC) lists two patent numbers on the back side: 4.599.489 & 4.609.777. From the [latter](https://patents.google.com/patent/US4599489A/en?oq=4%2c599%2c489) it seems to be generating codes depending on real time. – Sz. Jul 12 '18 at 15:37

3 Answers3

46

There are two standard ways to build such a device:

  • Time-based. The device has a secret key K (known only to the device and to your bank). When you press the button, The device computes F(K, T) (where T is the current time) and outputs it as a 6-digit code.

    Your bank, which also knows K, can compute the same function. To deal with the fact that the clocks might not be perfectly synchronized, the bank will compute a range of values and test whether the 6-digit code you provide falls anywhere in that range. In other words, the bank might compute F(K, T-2), F(K, T-1), F(K, T), F(K, T+1), F(K, T+2), and if the code you provide matches any of those 5 values, the bank accepts your login.

    I suspect this is not how your device works, since your device always gives you a different value every time you press the button.

  • Sequence-based. The device has a secret key K (known only to the device and to your bank). It also contains a counter C, which counts how many times you have pressed the button so far. C is stored in non-volatile memory on your device. When you press the button, the device increments C, computes F(K, C), and outputs it as a 6-digit code. This ensures that you get a different code every time.

    The bank also tracks the current value of the counter for your device, and uses this to recognize whether the 6-digit code you provided is valid. Often, the bank will test a window of values. For instance, if the last counter value it saw was C, then the bank might compute F(K, C+1), F(K, C+2), F(K, C+3), F(K, C+4) and accept your 6-digit code if it matches any of those four possibilities. This helps ensure that if you press the button once and then don't send it to the bank, you can still log on (you aren't locked out forevermore). In some schemes, if there is a gap in codes (e.g., because you pressed the button a few times and then didn't send the code to the bank), you will need to enter two consecutive valid codes before the bank will log you on.

Based upon what you've told us, I would hypothesize that your device is probably using the sequence-based approach.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • Often the latter approach will involve a variant of [Lagrange polynomial interpolation](http://en.wikipedia.org/wiki/Lagrange_polynomial), which allows a root polynomial to be derived from a set of `n+1` points, where `n` is the order of the polynomial. The input `x` will progress in a defined way and produce modular output. Given appropriately large coefficients on each term, the cracking such a sequence becomes akin to a semiprime integer factorisation. Furthermore, it allows the sequence to recover in cases where a large number of skipped entries are used, without resorting to brute-force. – Polynomial Nov 12 '12 at 07:07
  • @Polynomial, I confess you lost me. I hadn't heard of anything like that being used in this context, and I'm skeptical whether it would be secure, but I'll withhold judgement until I see the details. Do you have a pointer to a more detailed explanation? I'm not familiar with that kind of thing used in this context, but I'd be interested to learn more if you can suggest any readings with more information. – D.W. Nov 12 '12 at 07:51
  • I don't have a direct reference to anything like that off the top of my head - the technique has a real name which eludes me at the moment. Think of its security model as an extension of RSA's - modular exponentiation of large values. The only major difference here is that a sequence is produced with properties that allow full coefficient recovery if you know a partial set of coefficients and a number of points on the curve. – Polynomial Nov 12 '12 at 08:47
  • @Polynomial, if you are talking about secret sharing, I don't think it has any relevance here (as far as I know). Are you sure it is used in this context? If you have any citations that indicate that secret sharing techniques are being used to generate the sequence of random values from hardware tokens, please do share the citation or pointer -- I'd be very interested -- but lacking that, I'm pretty skeptical. – D.W. Nov 12 '12 at 09:07
  • It's not about secret sharing, it's about authentication. If the device has a pre-programmed set of large coefficients for a polynomial, a modulus, and a known input value (e.g. current time or an increment) then the coefficients and modulus become the shared secret. As long as the bank knows the modulus and coefficients, it is capable of both verifying an individual value in the sequence (given a known input) and identifying the input given a sufficient set of outputs. A third party cannot compute the outputs with their own Lagrange interpretation due to the unknown modulus and limited inputs – Polynomial Nov 12 '12 at 10:20
  • 2
    It's definitely not 2, my accounts would have locked me out a long time ago if it was. – Inverted Llama Nov 12 '12 at 12:14
  • @Polynomial: *"A third party cannot compute the outputs with their own Lagrange interpretation due to the unknown modulus"* - Actually, this is not true. It's possible to recover the unknown modulus, given enough outputs. Therefore, the construction you describe would not be a secure way to build a hardware token. I certainly hope no one is using something like this, because it's insecure. Are you sure this scheme is used in practice? If so, do you know by who/which devices? – D.W. Nov 12 '12 at 17:50
  • It's definitely not 2: When you press the button you often get the same number. And I sometimes happily click away at it many times before entering a number. If you think about it, in real world terms, 2 is a terrible solution. A user could easily irreversibly make the secure key worthless by entering their pin and pressing generate key 10 times. – Django Reinhardt Nov 01 '13 at 01:26
  • @DjangoReinhardt: It's still reversible as long as the server is willing to search for the next valid counter that matches the given OTP. It takes barely a second to test 1000 different counter values; the site could also have a separate "resync" page with anti-DoS to test ~5000 before giving up. – user1686 Dec 15 '14 at 12:43
  • I don't use HSBC, but in another security token, it works like this: first you need to input a security OTP sent to your phone, then the device would generate a new password. I guess it would be a combination of OTP with method 2, which is more secure. – Hoàng Long Jun 13 '16 at 07:27
  • The methods described above are called HOTP (HMAC-based One-time Password) and TOTP (Time-based One-time Password). – Joe Nov 16 '19 at 12:28
9

If you want an 'open' explanation of how the One-Time-Password is derived you can read about the Oath standard and the specification for the algorithm here, https://openauthentication.org/specifications-technical-resources/. The Vasco/Digipass product supports this specification, and it may be used by your token in this case, however they do support other OTP generation algorithms.

Typically the serial number of the token is maintained as a record in the authentication server database, and the serial number is assigned to a username. The serial number is also matched to a 'seed' value, which when combined through the algorithm with the time/sequence value derives the OTP.

Also, you were able to punch in a PIN over and over and be authenticated because the authentication server will allow for a couple of minutes of clock drift. The token you have has a clock built in to generate the time based component. The server generates values for a range of time. It then can see which code you submit, and write a drift value to your record. Some systems will have a 'next-tokencode' mode, which is used if the clocks drift too far apart. The system will ask you to submit two values and see if they are correct and in the proper order, over a larger 'range' of time. If the values are correct the authentication server can write the clock drift value to the record.

Moshe Katz
  • 1,331
  • 1
  • 11
  • 17
Fearmonger
  • 121
  • 2
  • The link above does not work anymore. I presume it's now http://www.openauthentication.org/specification (without the `s` at the end) – T. Junghans Oct 08 '15 at 08:32
  • @TJ. Looks to me like both your link and the link in the original post now redirect to a third location. – Moshe Katz Jan 13 '16 at 17:53
4

I think this question lends itself to a very high level overview of how multi-factor authentication (MFA) works. Of course, we have to skim over lots and lots of technical detail.

In short, here is what happens:

  1. The bank programs the token with a unique encryption key. (In this case your Digipass token is made by Vasco, but there are many other companies that make similar tokens, which are "something you have" with regards to multiple factor authentication).

  2. The token will generate a series of characters that are derived from the encryption key, current time, and (optionally) other various factors.

  3. Since the bank knows the (unique) encryption key, and all other other factors that the token uses, they can reverse-engineer the input to find out who "owns" that token. If the owner of the token matches the owner of the bank account that is being logged-in to, then the login is authentic.

There are many variations on this central theme, but in general they always involve "something you have" (a physical token, or a smartphone app), a secret key stored within the token, and a mathematical algorithm to produce the output.

Often, time is a critical factor in generating the output. Depending on the algorithm, the output may be different every single time (in your case), or it may only vary occasionally (e.g. Every hour).

scuzzy-delta
  • 9,303
  • 3
  • 33
  • 54