1

On a Linux system I'm running an utility like this:

$ /usr/bin/myapp myprivatekey
Enter passphrase for the private key:...
...application runs and uses the private key

My understanding is that if I have a private key encrypted with a passphrase it is more secure than an unencrypted one because the private key cannot be accessed even if the user account is compromised. So if the private key is loaded by a process running as a different user and the passphrase is typed manually by the user then one cannot intercept the above passphrase. Please note that the /usr/bin/myapp can only be written by root.

On the other hand a colleague argues that, if the user account is compromised then the private key is compromised too even if it's protected by a passphrase, because if the account is compromised then the password typed by the user can be intercepted and one cannot be protect himself in such a situation.

Which one is correct? Is it possible to setup a system such that the private key is protected in the above situation?

Thanks!

1

if the private key is loaded by a process running as a different user and the passphrase is typed manually by the user then one cannot intercept the above passphrase

No, that's plain wrong. If the user account is compromised, the attacker has access to everything you type, click on, display, copy-paste, etc. An application can monitor inputs events such as key presses and clicks: that's how window managers, input methods key binding applications and screen recorders work. An application can monitor clipboard contents: that's how clipboard managers work. An application can monitor what is displayed: screenshot applications, again screen recorders, etc.

A trojan could also infect or replace your terminal emulator, your window manager, etc. If your account is compromised, you have no way to know what application you're really interacting with.

This does not mean that it's useless to put a passphrase on a key. Capturing the passphrase is extra work and not all malware is set up for that. The attacker won't get the passphrase if the attack is detected and expurged before you type it. The attacker also won't get the passphrase if they're only able to read files and not to run arbitrary code, for example if all they have access to is a backup of the files on your account, or they can only exploit a limited vulnerability in some sandbox (e.g. a web browser or a container) that lets them read arbitrary files, but not execute arbitrary code.

2

Is an encrypted private key which never leaves my home directory more secure than an unencrypted one?

Yes, it is more secure to use an encrypted private key than an unencrypted one.

The argument your colleague gives just shows that an encrypted private key is not completely secure. His argument does not mean that an encrypted private key is no more secure than an unencrypted one. In fact, the opposite is true because the encrypted private key does protect against certain attackers and situtations that the unencrypted key does not. For example, it protects against the situation where you accidentally upload it to your public github account or something. It also protects against a specific type of attacker who only has read access to your directories/files. Because of these types of attacker and situations exist the encrypted private key is more secure.

On the other hand, your colleague is correct that an attacker with local access who can run processes, keystroke recorders, etc on your system could still get your key. However, a local attacker is a very powerful type of attacker and in the presence of such an attacker it is difficult to protect your keys in general. However, one thing that could be used to protect keys in this situation of local attack is a separate physical factor like an RSA dongle.

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.