0

Saved on device, I have TLS certificate private key, which I would like to encrypt with AES256; password will be simple PIN.

I would also like to use this same PIN as a secondary protection for some user actions. The salt and hash of this PIN will be saved on server. PIN will also serve as a secondary protection in authentication process.

What is your opinion on using this PIN to encrypt private key and also use it in other (authentication) ways? Since I want to keep it simple, I'd like to stick with one key if possible.

My thought is to use some sort of KDF (PBKDF2HMAC?) to stretch the simple PIN as the result password, but I am not sure if it is enough.

Edit: I should have mentioned that I am performing mutual certificate authentication, there goes the need for TLS certificate private key as mentioned in discussion below.

  • "Since I want to keep it simple" -- why? Basic principle: the easier it is for you, the easier it is for someone else. – schroeder Feb 1 at 21:47
  • Because of my users. I'd like to stick to ONE user's-memory-only secondary password (alphanumeric, possibly 8 characters max). – wtdmn Feb 1 at 21:52
  • Ok, then this is not your device and key, but this is user's data, key, and authentication? That's a pretty big detail to omit. I think you need to flesh out the details here. – schroeder Feb 1 at 22:06
  • Why are you getting users to encrypt their private key and decrypt it on the fly with user interaction? It sounds like you need a proper authentication process that can permit access and unlock sensitive data. – schroeder Feb 1 at 22:08
  • Ok, let me explain. I work with user-client TLS authentication certificates. I added this feature to encrypt client certificate with password, but now I am hesitant to use the same password user uses for secondary signing of some user operations. Complete process is: run program / enter PIN to decrypt certificate private key / start TLS between c-s / validate certificates etc. / authenticate by login - password - pin / authentication complete. – wtdmn Feb 1 at 22:16
0

The greatest weakness of this scheme is the use of a "simple pin". A simple pin will only give you as much protection as a simple pin can, regardless of whether you are using a KDF to expand it. If you only allow for 4-digit, numerical pins, then your KDF will only be able to produce 10^4 different keys, which is a trivial number to brute-force.

So in this case, if a client's device is compromised and the encrypted private key is taken, the encryption can be trivially broken. The only saving grace might be if the KDF was custom-made and kept secret, but the KDF being reverse engineered or being discovered in a compromise are both very real possibilities.

Using the PIN as a form of secondary authentication for certain actions is probably a much better application than encrypting the private key because you can enforce lockout if there are too many failures.

In general, key reuse is a red-flag for weak crypto-schemes and I would highly caution against it. I do not know all the details of your scheme though so I cannot comment much any further, but I hope this helps you learn about some of the things you should consider. Also here some obligatory wisdom that I hope you abide by as you develop your project: Don't roll your own crypto.

| improve this answer | |
  • Well. I got a couple of failsafes in case PIN gets cracked (there is also primary authentication and multiple count limiters for brute force, and two other "surprises"). I would never think about rolling my out crypto. – wtdmn Feb 2 at 0:33
  • My question is: in this case, do you advise (if impossible to encode private key with second, stronger password) to leave private key unencoded and use only the secondary PIN authentication on user actions? I suspected this, but I wasn't sure how easy it is to crack the AES with KDF and weak password. – wtdmn Feb 2 at 0:36
  • That is exactly what I thought. Other authentication features compensate the possible lost of primary key. Thanks for your answer. – wtdmn Feb 2 at 0:42
  • What you should ask yourself is whether you gain anything from encrypting the private key with the PIN. I think you do not gain any secrecy for the private key and you lose secrecy of the PIN as brute-forcing the encrypted private key will reveal the PIN. In my opinion, it is actually better to leave the private key unencrypted if these are your only options. A slightly better choice would be to encrypt it using a key obfuscated inside the client program although this will only prevent trivial attempts to obtain the private key – kansas_bulldog382 Feb 2 at 0:43
  • Thanks for the obfuscation idea. – wtdmn Feb 2 at 0:48
0

This answer is based on the discussion between Schroeder and wtdmn in the comments. Yes, the client's private key (corresponding to the client's public key in the client's certificate) will need to be decrypted in order for the client to establish a TLS connection with the server, using the client's certificate. But, once the client's private key is decrypted, why not use the client's certificate (along with the decrypted client's private key) to authenticate the client? See https://medium.com/@sevcsik/authentication-using-https-client-certificates-3c9d270e8326 for a good write-up of how authentication using client certificates works.

Then, the PIN to decrypt the client's private key is used only once - to decrypt the private key at the beginning of the process. So, the flow would be:

run program / enter PIN to decrypt certificate private key / start TLS between c-s / validate certificates etc. / authenticate using client certificate / authentication complete
| improve this answer | |
  • That is exactly what my scheme is, thanks for pointing it out. – wtdmn Feb 2 at 0:29

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.