1

I have an existing Java web application running on Linux using embedded Jetty. The application is loaded using jsvc, which runs as root, listens on port 443, and relays requests to the Java app, which is run under a less privileged user "appname" on port 8443.

Currently, the application reads an encryption key from a file we'll call "secrets.properties". It is writable by "root", and readable by "appname" (technically, by members of the "appname" group). My preference, however, would be that the file is only readable by "root", and that jsvc reads the file and passes the contents of that file (or even just a single property) to the application. My goal is that if someone were able to subvert the app and gain system access with the app's "appname" account, that they couldn't retrieve the key.

Is that possible without having the key visible to someone running "ps -ex"?

phatfingers
  • 9,770
  • 3
  • 30
  • 44

1 Answers1

1

They may not be able to retrieve the key, but they would still be able to use it

Since the attacker now controls the application, they could send any messages they want and whatever is signing/encrypting them would, believing that the application was uncompromised , dutifully sign or encrypt them. There is little point in doing this if you are merely trying to authenticate data coming from the application.

No matter what, you'd be smart to revoke your keys if the server was compromised, so it doesn't save you their either.

Now, if your worried about the compromise of a long lived key allowing an attacker to read previously sent (but no longer stored in the app) messages , thats a different problem. I would suggest using a crypto system with perfect forward secrecy. TLS/SSL has this if you use authenticated Diffie-Helmen key exchange which are the schemes with ECDHE or DHE in them(e.g. ECDHE-ECDSA-AES128-GCM-SHA256 or TLS-DHE-RSA-with-AES-256-CBC-SHA)

If for some reason your still worried about keys being compromised, you could write a proxy. It either could run as root or run as a different group and have the key handed to it. For TLS/SSL this is easy. For some custom encryption/signing system, who knows . But again, there is very little reason to want to do this.

imichaelmiers
  • 3,449
  • 2
  • 19
  • 25
  • +1 for the well-thought-out ideas. My concern is the protection of data that is encrypted and stored in a database by an application server. There are multiple safeguards in place, including network and server firewalls, HIDS, monitored logging, periodic auditing and pen testing, strict access controls, derived keys per row, and well-known trustworthy administrators. Even a root-level compromise of the app server and database wouldn't be quite enough to decrypt existing data, but I don't want to give up any ground I don't need to, and that portion of the derived key is my focus of interest. – phatfingers May 02 '12 at 15:25
  • Ok, were dealing with data at rest encryption, I couldn't tell by your question so my answer was generic. No matter what you do, if the app is allowed to read the data, the attacker can read the data if they take control of the app. However, you could rate limit how many records the app can decrypt by making it all out to a separate app/proxy that ran in a different proces with privileges to access the keys. – imichaelmiers May 02 '12 at 17:02
  • Actually you'd probably not want to rate limit but rather deny all access if the requests go above a certain threshold. If you are really paranoid, you could invest in a hardware security module (HSM) and maybe program it to do this rate limitation. – imichaelmiers May 02 '12 at 17:03
  • Understood. If you're accepting sensitive data in plaintext and encrypting it, it's nearly impossible to get around the fact that the data exists in memory on that server in plaintext before its encrypted. It's worthwhile to be at least a little paranoid. I like the idea of an additional proxy layer so that the encryption key used for storage never exists in the DMZ. Ultimately, though, I think you're right. If I'm concerned about compromise of the key, then it needs to be moved outside of the app. – phatfingers May 02 '12 at 18:08