Secure the HMAC shared secret by encrypting the authorization hash with RSA


I am considering building an API system that uses HMAC. The server and client will have a shared secret, the client will sign the requests, the server will validate, and proceed if all is well. The trouble with this sort of system is that the secret has to be stored in a way where it can be retrieved, such as a database. If someone were to steal the secret, they have the key needed to do basically anything that user is authorized to do.

I was thinking that there must be a more secure alternative. Are there any flaws with using RSA?

  1. Client has the "public" key instead of a shared secret. (The public key must still be kept secret for my use case.)
  2. Client will hash the message with SHA-1 or whatever as normal.
  3. Instead of adding the hash to the message directly, the hash will be encrypted via it's public key, and then sent with the message.
  4. Server has the "private" key (to decrypt messages) but has no knowledge of the "public" key. (This is the part that makes this more secure than the normal approach. If the database is stolen, no keys are stolen that can impersonate a user.)
  5. Server will decrypt the hash and validate the message as normal.

Is there anything wrong with this approach? Are there known implementations of this or something similar?

It depends on the asymmetric cryptosystem you chose:

(EC)Diffie-Hellman: It does not work. Publickey is directly derived from the privatekey via the generator, e.g. [d]G = Q

RSA: Usually people chose fixed publickeys like 0x010001. This is done for efficiency reasons. If you take a large enough, fully random e and derive d from it there is no possibility to calculate p and q given d and N OR e and N. Actually they are pretty equally then and the label private and public don't make much sense anymore. All that relies on a smmyetrical property of RSA. Be sure not to walk into textbook RSA issues. And be sure to ask enough clever people about it, this is just my thoughts on it.