How does HSBC's "Secure Key" actually work?

  • 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?

    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?

    @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.

    Mine (for CIB, not HSBC) lists two patent numbers on the back side: 4.599.489 & 4.609.777. From the latter it seems to be generating codes depending on real time.

  • D.W.

    D.W. Correct answer

    9 years ago

    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.

    Often the latter approach will involve a variant of Lagrange polynomial interpolation, 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, 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.

    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, 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.

    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

    It's definitely not 2, my accounts would have locked me out a long time ago if it was.

    @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?

    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.

    @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.

    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.

    The methods described above are called HOTP (HMAC-based One-time Password) and TOTP (Time-based One-time Password).

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM