Re: Cryptography and Site Security: Please critique my security idea

[Mark Reardon <riscorp () mindspring com>]

I would say this sounds complicated, and maybe unnecessarily so. Your users are allowed access. The issue is not 
keeping the file decryption key on the file server yet having it available to decrypt the files, when required. That 
makes this an exercise in track the key.

A simple solutions would be to make them enter a password. The hash (possibly with a custom permutation such as 
concatonating it with the server's domain name) of the password would be the secret key for symetric encryption. 

This means no password is saved on the system except in the session memory. It also allows you to change the password 
(and decrypt, re-encrypt your files) if you get concerned about the value of the hash becoming known. It also only uses 
one type of encryption, symetric.

If typing a password is too much (I also have users), have the user go to a key server with their browser. Have it set 
a domain cookie containing the key and then refer the browser to a different server in the domain where the encrypted 
files are located (the file server). 

The file server pulls the key from the cookie, decrypts the file, pass it to the user, and overwrite the cookie in 
memory. If the user selects another file, the cookie is available again, so repeat the process. This cookie is not 
available to servers outside the domain. Warning, the cookie and thus the key are maintained in the browser's memory.

If you really want to get tricky, have the browser receive the encrypted file and decrypt it with the information from 
the first server. Then the key is never on the file server.

In either case, use a non-public domain for the two sites and I doubt if too many hackers are going to figure it out.

Now, to look at what you have. I assume B is the private key of the key pair. I have difficulty following but it sounds 
like '1' is key A encrypted asymetrically with key B. Then the user provides both 1 and the public key to the 
application.

It is obscure but not 'tight' since anyone that gets the two pieces of information has the keys to the empire. They 
just may not know it.

It also uses asymetric encryption, which is expensive from a CPU view.

It is difficult to change the secret key since all users are holding its value encrypted with their private key.

My two cents.

Mark


-------Original Message-------
From: Robert Paris <rpjava () hotmail com>
Sent: 03/27/03 10:05 AM
To: webappsec () securityfocus com
Subject: Cryptography and Site Security: Please critique my security idea

>

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" )
   a. The user is assigned this key pair, but NOT given the key. We
      house the key internally.
4. Key "A" is encrypted separately for each key "B" ( called 
   file "1" )
5. User is given file "1"
6. The public key for each user's private key is stored on an internal
   server that is inaccessible from the server and vice versa
7. 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.
8. 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.
9. 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.
10. 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)
>

----
Mark Reardon
Reardon Information Security Corporation
156 Blue Sky Drive
Marietta, GA 30068
(770) 565-0544
(404) 444-0041 cell