1
$\begingroup$

I need help with the process/commands needed to implement the below functionality:

I'm modeling an OTP System, in which the user would request an OTP and the app will send him one. Later the user will use the OTP to use some functionality or something, and the OTP needs to be validated. Constraints:

  • The OTP cannot be stored in the Clear.
  • Need to use Thales payShield 9000, that I have available, sending HOST COMMANDS.

This is the process:

  • App A request an OTP using a User Account
  • App B Generates the OTP for that User Account and send it to App A
  • App B Can't store the OTP in clear, so it must use the HSM to, in some way, store the OTP that can be validated later
  • App A, later, sends the OTP to App B which validates it (using the HSM) and then procedes to send the approval to App A

My apologies if this doesn't make sense, and I don't have idea what I'm doing.

$\endgroup$
3
$\begingroup$

I do not fully understand the scheme you are describing, especially the interactions between your apps A and B. I'll try to describe a sensible HSM usage for a OTP based authentication.

I think you have a little misconception about how a typical OTP is usually handled. There is no need to store an OTP ever, it is always calculated upon use. The typical scenario is, that the user (his OTP calculating app) and the server both store a shared secret. From that secret and some additional information (like a timestamp if you use TOTP, or a counter if you use HOTP) the one time password is calculated using the HMAC algorithm.

This HMAC calculation can be done in software (if you use a normal app on your phone, like FreeOTP) or in hardware (like a PKCS#11 token) on both sides. The server side in your case, could use your HSM which stores the user's secrets to do the HMAC calculation. For a real massive multi user setting, you will probably have to create the shared secrets on the HSM dynamically from a master secret to overcome storage restrictions.

The specific procedure how you calculate your 6 digit (or whichever length you need) OTP ist outlined in the RFCs for HOTP and TOTP.

$\endgroup$
  • $\begingroup$ Thanks a lot! So you mean when I receive what the user typed, at the server side I would have an HMAC key cryptogram (encrypted with the HSM Local Master Key), and a HMAC (that was generated with the key and the OTP), and with that I would validate What the user typed using the HSM? if that's the case, would I need a different HMAC key for every "transaction"? $\endgroup$ – Gatitopo Jul 30 '17 at 6:04
  • 1
    $\begingroup$ Not exactly. You do not calculate an HMAC value from the OTP, but you derive the OTP from the HMAC. The calculation is more or less $HMAC(Secret, Timestamp) \rightarrow $ convert to decimal OTP. The HMAC key is different per user but static for each operation. The only thing that changes is the moving factor (timestamp or counter) $\endgroup$ – mat Jul 31 '17 at 7:55
  • $\begingroup$ I see. But the OTP I need is 6 decimal digits, and the resulting HMAC (even if I use SHA-1) is 40 hexadecimal digits. In my HSM the minimun length i can specify for SHA-1 Based HMAC, is 20 hexadecimal digits (10Bytes), so How can I use it to derive the OTP? if I lose the excess data, I won't be able to verify it later (because I will need the origial HMAC). $\endgroup$ – Gatitopo Aug 1 '17 at 13:58
  • $\begingroup$ I updated my answer with links to the relevant RFCs. $\endgroup$ – mat Aug 2 '17 at 7:51
0
$\begingroup$

Go for a time based OTP

otp = HMAC(secret, timestamp)

and on the server, check for a range of timestamps (the timestamp will not be exactly the same, checking on a range is reasonable)

This way the app doesn't have to ask for an OTP. It's basically the same approach used by some banking hardware tokens

Another possibility is to use a rolling code but you need to provide a sufficiently large window or you could end up out of sync

P.S. the first time you need to "pair" the app with the server to acquire the shared secret

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.