Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
my first problem is really that the description of what management wants is really a combination of objective and implementation.
Unless you have something better to work with than a dumb client browser
the servers would need to have all the necessary ingredients to decrypt the files. Given free rein on those servers an attacker will be able to decrypt the files.
The scheme you're proposing seems to presuppose much more intelligence on the client level than the simple browser platform provides -- unless you have sufficient control over your clients and can, for example, dictate a platform such as IE5+ with the Java 1.4 plugin.
Much of what your proposed scheme is doing can be achieved more simply, I think, by using secure HTTP with client-side certificates. Unfortunately although I've developed SSL and HTTPS applications I don't have experience with client-side certificates personally. Once the SSL connection has been set up, you have proof of the client identity (well, as long as their private key is safe) and all traffic will be encrypted. That doesn't address your problem of needing encrypted server-side files though.
you can encrypt a file with a secret (symmetric) session key, then create encrypted copies of this session key with each clients' public key (not necessarily the most intelligent scheme, but it's nice and easy for the purpose of this discussion).
Encryption would be simpler; if you keep a list of all clients' public keys, you can generate a symmetric session key, encrypt the file, the encrypt the session key with each client's public key in turn. Adding a new user would require the generation of encrypted session keys for that client. This can be done by sending the encrypted keys, together with the new client's public key, to an authorised user's client-side application. That application can decrypt the session keys using the user's private key, then encrypt them using the new client's public key and send them back to the server.
Bottom line is, you can fully achieve your goals only if you can use client-side applications or signed applets. Failing that, the best you can do is separate your authentication/key server(s) from your file server(s) and hope that a hacker won't get into both.
Performance should not be too bad for most purposes. As indicated by Karl, you would never encrypt a file using asymmetric encryption; rather, you'd generate and ecrypt a symmetric session key, then use the session key to encrypt the file using fast symmetric encryption.
Authorisation rules are simple to implement. If a client doesn't have access to a file, just don't generate a session key for that client. Any modifications to authorisation will necessarily involve an authorised client, which gives you a nice audit trail.
Only if users send their private key to the server in addition to their public key -- possible, if less than ideal.Originally posted by Robert Paris:
I don't see how this is true. I would not store the keys to decrpyt the files on the server, they'd only be done through the key sent by the logging in user and that key is stored only in memory.
It's not clear to me how exactly you'd send this file (except through a clumsy browse box) or what this would achieve over a client certificate. You need https anyway.I was thinking that I could send them (in the mail or email) a copy of the secret key encrypted with their private key, and then the login page would be a form with inputs for usernam, password and a "browse" input to find that encrypted file on their computer and send that to the server. How does this sound?
Correct. "Key A" is the session key, which should really be different every time, for every file. The "nuts" optionThe way I understand it: [...]
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Only if users send their private key to the server in addition to their public key -- possible, if less than ideal.
Where are these keys coming from anyway? Do you plan to store them on the client machine -- possibly (shudder) a cookie -- or have the clients merely authenticate and the keys served up by a separate key server? (then, inevitably, the system is only as hack-proof as the key server).
It's not clear to me how exactly you'd send this file (except through a clumsy browse box) or what this would achieve over a client certificate.
You don't... iff you use one single symmetric key to encrypt absolutely everything, as opposed to a separate session key for every file.Originally posted by Robert Paris:
Why would the private key need to be sent as well?
Hmmm. The urge to keep public keys secret is a bit of a code smell... never mind. I'm now finally getting my head around what you want to do exactly.The server will of course have the public keys to all the users' keys (in order to decrypt the symmetric key), but only in memory (when the system is started up, a user has to "turn on" the system by uploading the public keys in to memory through an HTTPS web browser).
Not so bad then. Of course one is prone to lose cookies sooner or later, but then you simply prompt for the file again.First: why is a browse input clumsy? It'd only happen the first time they log in, and is then cached in their cookie.
A client certificate allows strong authentication of a client as part of the SSL handshake. I agree that in your proposed scheme it wouldn't do a lot for you. You can probably embed a key in the certificate in theory but I wouldn't advocate it.Second: How would a certificate help? Can I put a symmetric key to decrypt files in a certificate?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Hmmm. The urge to keep public keys secret is a bit of a code smell... never mind.
Within the constraints you've got to work with, the scheme you've come up with actually is pretty good, provided that security needs are relatively modest.
The main Achilles heels are that you implicitly trust your own users...
a determined attacker compromising a running server can bypass security completely
The urge to keep public keys semi-secret arises from the fact that a public key plus the encrypted symmetric key gives immediate access to all the files. You're trying to make it that little bit harder for an attacker to get the two, even if (s)he gets through to a running server.Originally posted by Robert Paris:
Can you say a bit more about what you are thinking of here?
To some extent. You can do a little better -- giving each file a different session key and only creating decryption keys for users that actually have access to the file will lower the amount of trust you have to invest in each user. But to do that in a thin-client context, clients have to transfer their private keys to the server (rather than the encrypted session key). This is less alarming than it sounds and no less safe, or perhaps I should say no more unsafe.Isn't every security system in a thin-client-server setup in this same boat?
Once on the machine, there are a number of attacks I can think of. Restarting the server in debugging mode. Modifying the web-app and forcing a reload. Fiddle with the machine's network configuration and set up a man-in-the-middle. Forcing the application server to coredump and trawling through the heap for security-sensitive information (which is why passwords and keys should really always be char[] or byte[] so you can zap them -- remember, Strings are immutable).I don't see how [a determined attacker compromising a running server can bypass security completely]
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
In a watertight PKI, the public key can be fully public.
It also means that your infrastructure is less than ideal...
You can do a little better -- giving each file a different session key and only creating decryption keys for users that actually have access to the file will lower the amount of trust you have to invest in each user.
Once on the machine, there are a number of attacks I can think of...
Oh sure, it's a tiny ad, but under the right circumstances, it gets bigger.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|