Cryptography and Site Security: Please critique my security idea

From: Robert Paris <rpjava(at)hotmail.com>
Date: Thu Mar 27 2003 - 10:05:15 EST

('binary' encoding is not supported, stored as-is)

My company is going to have an application that houses and shares internal documents through an extranet. There has been a concern by the network administrators that even with a firewall, someone might get direct access to the server (housing these documents) whether through hacking or otherwise. If they did, they'd have access to all the documents. So I came up with the following solution, which I'd like some critique on:

1. A symmetric (secret) key ( Key "A" ) is created
2. All files to be managed are encrypted with key "A"
3. Each user is assigned an asymmetric (public-private key pair) key ( Key "B" )
4. The user is assigned this key pair, but NOT given the key. We house the key internally.
5. Key "A" is encrypted separately for each key "B" ( called file "1" )
6. User is given file "1"
7. The public key for each user's private key is stored on an internal server that is inaccessible from the server and vice versa
8. When the app/web server is started up, the application is in a "turned off" state. This is because no public keys have loaded. There is one page only that is accessible and it is locked to two IPs (both internal). This page allows an authenticated user to upload the public keys in to applciation memory. This must happen after every restart or the site is unusable.
9. The first time a user ever logs in to the site, they must give username, password and upload file "1". This file "1" (after being verified through message digest) is then stored in the user's cookie. After this, they log in with username and password.
10. After user log-in, file "1" is sent to the server, and opened with the proper public key (in memory) and stored in session memory only. During this session, if this user wishes to download a document, this now decrypted key "A" will be used to decrypt the file and send the decrypted stream to the user. The file remains encrypted on the server. As well, the in-memory key "A" is used for encryption when they upload a file.
11. All communication is HTTPS, 128.

As well, I am considering putting a lifespan on the private/public key pair that is used to encrypt the symmetric key that is stored (encrypted) in the user's cookie. What I would do (and I don't have this 100% down) is, if the lifespan is past, create a new key once (for that old key) and use that new key to encrypt the symmetric key and save that to their cookie. So even if they gave the original file to someone (along with username and pass), it'd no longer be useful. I'm not 100% sure how to make this work correctly or even if it's a good idea.

Please let me know:

1. What are the weaknesses of this architecture?
2. What performance hits will this cause?
3. What are some alternative/better ways to achieve this?

Some major concerns/limitations:
1. We must use the browser as the thin client and it may be IE/Netscape or even something else (as long as cookeis and HTTPS 128 are enabled) on windows, linux, unix, mac/osX.

2. Our users will not be willing to do anything more inconvenient than that one time uploading of the encrypted key. And if possible to do less, they'd prefer this. Especially since they'd prefer a way to have it accessible from any computer not just one with the key (although I'm not sure I think that's the best idea) Received on Thu Mar 27 10:53:59 2003