Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
We repeatedly hear news of hacking of passwords from PW database (server side) but nothing about hacking of server's RSA private key (not asking regarding finding p and q for a given public modulus N), why?
Please someone explain how and where server's RSA private key is stored & used w.r.t authentication and any other details if any which makes server's RSA private key safe from hackers?
I need answer w.r.t password based authenticated key exchange protocol using RSA.
For best security, the private key should be held in an HSM (or Smart Card implementing a minimal HSM). It is hard to extract the private key from that, especially remotely, except for a bug or backdoor in the configuration or implementation of the HSM. That's because all good signature (resp. encryption) algorithms have the property that no matter how many signatures (resp. decryptions) one obtains, it is impossible to deduce the private key or a complete functional equivalent of that.
The HSM is also valuable because it is security evaluated, including against side-channel attacks like timing, and intrinsically invulnerable to others (like, leaks from one VM to another due to supervisor bugs, or physical CPU cache states). An HSM typically comes with means to enforce administrator/operator roles; put the HSM (typically, by default) in a safe (non-operative) mode; zeroise sensitive data on some attacks; do encrypted backups of keys; sometime, log operations. Also, some HSMs provide a significant performance boost compared to software-only solutions.
However, an attacker that gets root access to an host with HSM while it is operative, can potentially make signatures or decryptions (the HSM only makes it necessary for the attacker to have a few HSM-specialized skills). Therefore, an undetected persistent intrusion on a machine using an HSM is nearly as good to an attacker as getting the private key; and in most signature cases, revoking the private key is necessary if an attacker had even temporary access to it, so the fact that the private key can't be extracted is moot.
In SSH public-key authentication, there are two pairs of keys involved.
Put together, this means an attacker would have to hack into each client system to gain access to the server for that user, rather than hacking into the server directly. It's a lot more work than hacking the server side.
However, it means that now the client system must be fortified against attack, especially for a high-value user (such as a system administrator with privileged access on a server once authenticated) who holds literally the keys to the kingdom ;-) on the client/workstation. This is mitigated in most cases by requiring the private key on the client to itself be encrypted with a passphrase, which is only feasible where the user in question is an individual person and not a mechanized account or "bot".
There are also "hardened" or "locked-down" systems where it is impossible to remove keys from the server - the keys need to be generated & stored elsewhere, and the server only allows a small whitelist of programs to use them after it imports them.
Even if one does obtain the key, they should also be password-protected, and obtaining that password would be difficult to guess/bruteforce if done properly.
Leaks of server private keys probably do happen. But they don't get as much publicity.
When a password database has leaked, many sites decide to force users to change their password. Obviously this generates more publicity than if the site silently replace their secret key without forcing users to change their password. Depending on your point of view, this may make sense or not. There are certainly scenarios where a leaked private key would make it much more important for users to change their password than a leaked password database would.
There is a few reasons why leaking a password database is more likely to happen than leaking a private key.
First of all SSL may be terminated on separate hardware from the actual application. A weakness is more likely to be present in the application than in the SSL implementation due to the application often being more complicated than the SSL protocol and due to the application not having been reviewed as carefully.
If a weakness is found in the application, but SSL is terminated on another computer, then that weakness won't give access to the private key. Moreover even if it was on the same computer, then in some deployments the private key is placed in secured hardware such that even the SSL implementation doesn't have full access to the secret key.
Additionally password databases can leak due to SQL injection vulnerabilities, but those don't give access to the SSL secret keys.
If the secret key is leaked, the administrator can contact the CA to have the certificate revoked. In principle that will stop the threat posed by the leak.
However as soon as the secret key has been leaked, it could possibly be abused in mitm-attacks. Such a mitm-attack could give the attacker access to passwords in clear text. That makes password obtained this way easier to exploit than one from a leaked password database, because anybody with just a bit of a clue will hash passwords before storing them.
On the other hand using brute force on a leaked password database is likely to reveal at least a few clear text passwords, and those can be abused without needing to mount a mitm-attack in the first place.
So there are reasons for requiring users to change their password in either case, which of the two incidents would be worst depends on many other factors including the strength of the password. A strong password will remain secure even in case of a leaked password database (unless the password database is stored unencrypted), but if a mitm-attack is performed using a leaked private key, the strength of the password makes no difference.
