1

Consider the following scenario. A company has several computers for each users on the same domain. They purchase an RSA certificate from a recognized authority which will be deployed with private / public key on all workstations. So all the stations have the same certificate and therefore the same public and private key.

Let's say that for the needs of an application, without going into details, there is a need to be able to hash data and to do this we would like to use HMAC-SHA256.

Is it possible, correct and secure to use the raw public key of the certificate (as a string) as the HMAC-SHA256 password?

Thus, only the holders of the certificate (of the public key) will be able to hash with this same password, in order to be able to compare their hash with each other.

In this diagram we trust that the certificate is internal, non exportable and deployed by an administrator. So external people could not access it.

Thanks for your advices.

Improve this question
1
  • 2
    Using a public key as a secret key is not a good idea.
    – user163495
    Feb 24, 2021 at 18:03

1 Answer 1

Reset to default
4

TL;DR: "Using a public key as a secret key is not a good idea. – MechMK1"

I think you're mis-understanding how certificates work.

which will be deployed with private / public key on all workstations. So all the stations have the same certificate and therefore the same public and private key.

It's not really "private" if every employee in your company has a copy of it. Non-exportable helps, but you should really be issuing a unique certificate to each device; imagine the mess you'll be in if one of your devices is stolen / hacked and you need to revoke the certificate!

Is it possible, correct and secure to use the raw public key of the certificate (as a string) as the HMAC-SHA256 password?

Remember that public keys are intended to be public. Even if you are intending to treat them as a super-secret value, there is no guarantee that all of the software that touches them will. Two examples:

  • When a publicly-trusted CA issues a cert, they log it to public Certificate Transparency servers. For example, here is the CT logs for all *.stackexchange.com certificates, notice how many dev., qa. and test. certs there are in that list? By clicking into any of those, you can get the public key. If your certs came from a public CA, then I'll bet you can find them on https://crt.sh as well. This is not considered a problem because publicly-trusted certs are intended to be public in all aspects except the private key.
  • When establishing a TLS 1.2 connection, the certificate (and public key within it) is sent un-encrypted over the internet (@dave_thompson_085 pointed out that in TLS 1.3 the certificate is encrypted).

Never assume that your certificates will be a secret.

So your question "Is it ok to use a public value as a password?" is a bit like "Is it ok to use my name as my banking password?; no, no it's not.

Sounds like you need to figure out a different way of (securely) distributing an HMAC key to your apps.

Improve this answer
3
  • 1
    Thx a lot. In fact, with your explaination, I can understand that it's not a good idea :) thx again. Best
    – Marc Alves
    Feb 24, 2021 at 18:27
  • 1
    TLS1.3 encrypts the certificates, and since publication in 2018 has now become fairly common, e.g. qualys ssl-pulse has it at 40% of 'most popular' websites. And for enterprise-internal apps the enterprise can make it 100% if they choose. But at least on Windows 'nonexportable' only applies to the privatekey not the cert.
    – dave_thompson_085
    Feb 25, 2021 at 2:09
  • @dave_thompson_085 Thanks! That's awesome to know. I personally haven't started seeing TLS 1.3 in my wiresharking.
    – Mike Ounsworth
    Feb 25, 2021 at 3:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .