Cryptography and Site Security: Please critique my security idea

From: Robert Paris (rpjava@hotmail.com)
Date: 03/25/03 

From: rpjava@hotmail.com (Robert Paris)
Date: 25 Mar 2003 11:57:28 -0800

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 application/web server is started up, the applciation is
in a
   "turned off" state. This is because no public keys have been given
to it.
   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
usernam,
   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.

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)

Relevant Pages

  • RE: Confused by CryptoAPI
    ... the server should not sign the KEY itself. ... would be able to decrypt it and recover the negotiated ... You use CryptImportKey to get a handle for the server's public key. ... you don't "encrypt" your symmetric key to be sent to the server; ...
    (microsoft.public.platformsdk.security)
  • Re: TIPS FOR THE NEWCOMER
    ... As long as the private key is readable by the ssh client when it comes ... When the ssh client connects to the server, ... private key which matches the public key. ...
    (SSH)
  • Re: How to encrypt/decrypt a file
    ... If the clients' don't need to decrypt the file at all, then either a server-side private key, ... I think the OP simply wants to encrypt the xml file to prevent the clients to edit the clear-text ... server. ... The client is given the public key so they can decrypt stuff the ...
    (microsoft.public.dotnet.security)
  • Re: SSL certificates and keys
    ... Is the server's public key contained in the ... Or it's only the ciphersuite that client and server ... and the certificate is used only for server ...
    (sci.crypt)
  • Cryptography and Site Security: Please critique my security idea
    ... get direct access to the server whether ... The public key for each user's private key is stored on an internal ... upload the public keys in to applciation memory. ... this now decrypted key "A" will be used to decrypt the ...
    (sci.crypt)