Key Generation for TOTP in TLS

Question

So lately I've been studying the TLS Protocol. In particular, going through RFC 2246, section 7.4.7.1, i.e, RSA Encrypted Premaster Secret Message, I encountered:

If RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, encrypts it using the public key from the server’s certificate or the temporary RSA key provided in a server key exchange message, and sends the result in an encrypted premaster secret message. This structure is a variant of the client key exchange message, not a message in itself.

On the server side I have decrypted a “.key.enc” file using the server RSA private key. The output is as follows:

otpauth://totp/381151134?secret=X2WXGSZ5LSZ66TX6AGL4DIJ6XJAAEJQ2ZUJDM4KJFNWAJOD4GI7Q

I've also read that 46 bytes out of the 48 bytes are randomly generated. However, I believe I'm getting something wrong here since evidently there is no sign of 46 bytes of randomness in the output file.

As far as I know 381151134 is called a “label”, “TOTP” stands for “Time-based One-Time Passcode” and “OTPAUTH” determines the authentication scheme.

Can someone point out what I might be missing or getting wrong here?

---

Besides that, I have another related question:

The IBM Knowledge Center states…

For server authentication, the client uses the server's public key to encrypt the data that is used to compute the secret key.

… but they don’t provide any detailed information on how that’s done.

Can you additionally point me to a reference paper or some documentation that describes how the secret X2WXGSZ5LSZ66TX6AGL4DIJ6XJAAEJQ2ZUJDM4KJFNWAJOD4GI7Q is generated? I do know that this is Base32 encoding. However, I'm specifically asking about the steps before the encoding, possibly the use of a 256 bit output hash algorithm (such as SHA256) since there are 52 Base32 characters.

EDIT: Based on a comment my question seems vague in its current form. Further details:

I have been able to generate TOTP codes using the SECRET. I was able to authenticate to a server using the SECRET. Therefore, I guess the SECRET is a HMAC key. The main problem here however is that, how is the SECRET generated. Regarding the connection to TLS, the previous link from IBM Knowledge Center sounds informative. In addition, as I mentioned above the OTPAUTH link was encrypted with a RSA public key and sent to the server. I (may erroneously) believe this is part of the handshaking process in TLS

Answer 1

You seem to be confusing a few things here, mainly OTP schemes and TLS.
There really is no strong relation between the two, except for maybe the case that more often than not, you use OTP schemes over TLS.

---

The IBM Knowledge Center links makes a reference to the pre-master secret which is encrypted using the server's public key and then used (along with client's and server's nonces) to derive the actual master secret in TLS.

---

In OTP schemes, the shared secret is usually generated at random with the appropriate length and then encoded for better handling.

---

With common RSA connections, the server doesn't actually look at the pre-master secret and just takes what you give him. More often than not, he doesn't care what it actually is.

---

The fact that the OTPauth string was encrypted using the server's key was probably meant as a security measure to enforce access to the server's private key to be able to give out / verify OTPs. Or it may indeed as suggested be an try to let the client pick the shared OTP secret so not all clients are screwed in case of a partial leak of the secrets.

---

The numbers before the secret should encode usage parameters and / or give the secret a name for further processing.