The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Secure, Sandboxed, Client/Server Architecture

A few years ago, I participated in a roundtable discussion with some members of the federal intelligence community, where they described some of their software needs. In particular, they were looking for a secure project artifact/document management system. For example, a forensic investigator might be asked to provide comments about a photograph or a document. Individual investigators would have access to only the specific data necessary for their portion of the investigation. The whole collection of documents and artifacts would only be accessible to the lead investigator.

Last year, I wrote a blog post with a few more details about the requirements (as well as other potential customers outside of the intelligence community). The blog post is here:

http://benjismith.net/index.php/2006/06/13/biz-idea-04-project-artifact-management/

I've been thinking about the difficulty of implementing that kind of functionality in a client/server type of application (either through a web GUI or with a native rich client interface), where all data is centrally stored in a database somewhere.

The really tricky part is that the system admins who maintain the server (and the database) must not be able to access any of the data, no matter what DB credentials they possess. Not only should they be prevented from accessing sensitive documents, but they must also be prevented from knowing the project structure, the names & profile details of user accounts, or the assignment of project tasks to different investigators.

I know many databases provide row-level and table-level encryption, but then that begs the question of where to store the public/private keys. Obviously, keeping public/private keys in a config file on the server would be pointless. And keeping access credentials in a server-side session object is no good, because a privileged administrator could easily access the contents of the session variables.

I'm sure there are industry-standard ways of accomplishing this level of security, but I'm no security expert, so I would probably make critical design mistakes if I actually designed this software. (Incidentally, I'm NOT currently working on this software, or planning on working on it right now. I've just been thinking about the challenges it presents.)

So, how would you approach designing an application architecture to meet these needs? Is it really as tricky as I think it is, or am I stupidly forgetting some simple security principle?

Incidentally, don't think in terms of any specific platform (PHP, .Net, C++). It doesn't really matter.
BenjiSmith Send private email
Thursday, August 23, 2007
 
 
Industry standard is to ignore the problem until a load of backup tapes go missing!
Encryption is the obvious way to go, you can encrypt keys on the server with a user supplied passwd.  You would have to do the decryption in a client side applet if you don't trust the server.
Read some of Bruce Shneier's stuff on "programming satan's computer" = how to do security when you can't trust the enviroment you are running on.
Martin Send private email
Thursday, August 23, 2007
 
 
Here are some rules that would secure your system.
- users must have a clearance level.
- the file system should be at the highest user clearance level. Key stores files should not be accessible to everybody but restricted to the highest clearance people only. Admin activities should go through an API. To avoid having high clearance admins, the system could require multiple person  to authorize sensitive admin activities.
- only the highest clearance users should be able to have command line on the database. Everybody else should view the database through APIs only (stored procs). The APIs should filter data and authorize user actions based on clearance.
Dino Send private email
Thursday, August 23, 2007
 
 
My experience working with government agencies is that even people with a TS clearance are not given access to data unless they have need-to-know for that data.

Simply saying that the admins need TS clearance isn't good enough (or so I was told by the people at the intel roundtable). It must be physically impossible for admins to access the data, even if they have root access to admin the server hardware & software.

(BTW, I have no security clearance myself, so my knowledge about the intel community is purely anecdotal and based on some close professional associations over the years.)
BenjiSmith Send private email
Thursday, August 23, 2007
 
 
Not avoiding the problem by simply saying the admins must have clearance is a good start.
Stopping the admins getting at the data is much trickier, especially if they have physical access to the box.
Generally this is done with logging all the admin actions (orange book).
Martin Send private email
Thursday, August 23, 2007
 
 
It can be solved using public key/private key architecture. The following steps are what I can think about:

It is assumed that every one has his private key which is not known to other people. Their public keys are open for everyone.

1. The document owner chooses the keyword and encrypts the document using AES. He then uploads the file to the server.
2. The document owner selects the recipient list, which comprises the people who have the privilege to read the file. He encyrpts the keyorwd using each one's public key. After that, the recipient list is also uploaded to the server.
3. When the server receives a request from a member, it sends the documents, as well as the recipient list entry (encrypted password) to the person.
4. The requester first decrypts the password using his private key, then decrypts the document using the password.

In the whole process, the server only serves as a common storage. It does not perform any decryption/encryption. The administrator could dip into the communication, but it won't know anything since the key is not transported.
Glitch
Thursday, August 23, 2007
 
 
This is a fascinating problem and I fear that the human factors will make it fragile.

Of course, it is the admin people who make most secure systems fragile, or loss of keys in the field.

Rather than relying on a simple key, however it is stored, I always like the three vector method:

1) What you know (password)
2) What you have (token)
3) What you are (biometric)

It is harder to compromise this combination, and also harder to lose everything, by accident, force or social engineering.
Entries of Confusion Send private email
Friday, August 24, 2007
 
 
Some random thoughts:

There are various USB devices that will store X509 certificates for public key encryption - these work pretty well and are directly supported within Windows. These also have built in password protection so you have two factor authentication directly in the device. Of course, if you misplace the device then your data is now completely inaccessible!

Public key encrytion algorithms are pretty slow and as the private key lives on the device and can't be retrieved this makes it even slower. So a sensible approach would be to use the asymmetric encryption to protect a key for a symmetric algorithm that is the stored with the data.

I think there are even hard disks announced which have symmetric encryption built in.
Arethuza Send private email
Friday, August 24, 2007
 
 
The loss of key(s) issue will always be hard to solve.

It is unlikely to be acceptable to say that loss of key *really* means loss of data, with absolutely no (computationally feasible) way to recover [1].

So, the keys will have to be stored somewhere, or at least some "back door" will have to exist. Either way, you just move the problem up the chain and now you have to worry about how to protect the skeleton key/back door.

[1] Sadly, I think that the stories (in books, films and tv) about the NSA having computers that can crack sensible keys are largely exaggerated. There is no "decrypt" button, in the same way that there is no "enhance" button to recover fingerprints from a grainy cctv image ;-)
Entries of Confusion Send private email
Friday, August 24, 2007
 
 
Take a look at Trusted Solaris & Trusted Solaris Extensions.

http://en.wikipedia.org/wiki/Trusted_Solaris
*myName Send private email
Friday, August 24, 2007
 
 
I remember reading some MSDN articles last year about SQL Server 2005 and, with certificates, protect the data from the dba. I might be mis-remembering the gist of them (or since they were pre-release articles wishful dreaming by the vendor), but it was during a research project to look into securing passwords and sensitive info in the database in the event that the db or back up tapes were compromised. The PHB's requirements basically made such impossible, so it died.

Reading your article, you're describing the access control portion of a case management system. Although your "annual revenue target" is on the low side of a single installation of most case management systems. The FBI blew several hundred million dollars on one that got scrapped.

Keywords: Mandatory Access Control. Discretionary Access Control. Key recovery.

From memory, the rainbow books describe how you really need to have a security officer who handles keys, and has no other access. I forget which one went into more details. The military has spent a lot of time working out some of these protocol issues, so to avoid inventing the wheel, you might want to spend some time reading.
http://www.fas.org/irp/nsa/rainbow.htm
Peter Send private email
Monday, August 27, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz