Governement like classified information system

Question

I need to implement a classification system for my company, similar to the government's.

I'm working for a company working with the government. The classification system in my country isn't public so we can't just ask them how to do. We're required to create classification levels like: Top-Secret, Secret, Confidential, Restricted, Public) but with internal names (le, ld, lc, lb, la, "l" stands for "level") just as theirs. We can't know how the government does that, so I need your help to design such a system, talking about encryption, storage, sharing, authentication, ...

We simply need an equivalent system. Concerning the authentication, I've thought about using a PKI. Concerning the storage and redundancy, I've thought about an encrypted external HDD like a NAS/SAN (RAID + geographically distant/separated/isolated connected via a VPN. Levels are cumulative and not automatically deduced. To avoid risk of data loss and because it's needed by the laws in my country, I need to create a 6th level/SOS level (the highest level), to an anonymous which will be able to access and decrypt ANYTHING, and manage the system. "Anonymous" because it's not given to anyone, the "level" will be kept in 1 or more different safe and will be used if there is a system failure or if the government ask access to our data or to manage the system (because I will manage it but I don't have a high level).

I'm thinking about PKI to authenticate someone's identity and level. But then, the user need to decrypt the document. If a data is password based encrypted, it will be stored somewhere (maybe an etoken), if discovered the system is compromised. If I use levels PKI for encryption (1 private key for 1 level), a user which is granted multiple levels will have to store multiple private keys on his token.

Do you guys have an idea on how it's done by the government and their classification system? We have to basically do the same.

EDIT: Some parts of my question aren't clear enough or are bad explained. I've not edited my question based on the answers content, so I hope I didn't change the question because some answers are already really interesting.

Answer 1

Using PKI for access control is a bad idea. It is a very common mistake, everybody who works in the field of PKI makes that mistake, then learns from his errors.

In your situation, suppose that someone who has been cleared for access level 3 has been awarded a "level 3 certificate". This means that this individual has a private key K_s (e.g. on a smart card) and the corresponding public key K_p is in a certificate issued by the CA; the certificate is duly tagged as "level 3". The individual uses his private key and certificate for two purposes:

1. To authenticate with some systems which verify that the client's certificate is a valid "level 3" certificate.
2. To decrypt documents which have been encrypted with his public key.

Now it turns out that the individual was bribed by an evil competitor / government. His level 3 clearance must then be cancelled, of course. Unfortunately, this will not fare well with the two usages above:

1. The individual still has his token in his hands, and the token still works. In order to make the authentication fail, the certificate must be revoked. But revocation is asynchronous; it works with CRL and OCSP responses which have a finite but non negligible lifetime. Revocation will be effective only after a few hours or possibly days. I would not like to be the Security Officer who reports to the management that "the scoundrel has been identified and his certificate was revoked; he will no longer be able to connect and plunder files and spread chaos in our systems, starting... tomorrow. For today, he still can do all of that, and is currently doing it, and we cannot do anything about it because the CRL we issued earlier this morning is still acceptable for all servers".

2. For encryption, this is worse: revocation or not, you cannot enforce forgetfulness. The bad guy still has his token, thus he can still decrypt. To really prevent him from decrypting data, you must recover (and destroy) his token.

The above means that certificates are a poor location to encode authorization information.

A more robust way of doing things is the following:

• A certificate is for authentication only. A valid certificate, containing Bob's name and Bob's public key, is an assertion that Bob is in exclusive control of the corresponding private key. It does not state that Bob is a nice guy or has been cleared for any access level. When Bob turns out to be a spy, he is still Bob and still has his own private key. The certificate should be revoked when that "key ownership" property may be broken (e.g. Bob lost his token, and it may have fallen into other hands), but not in other situations. Loss of key ownership is almost always asynchronously discovered (Bob looks for his token and does not find it, so he assumes that he lost it previously), which is why the asynchronism of revocation is tolerable (i.e. we cannot do better anyway).

• All authorization data, including clearance levels, must be maintained "elsewhere", in a system that relevant systems (e.g. servers) can interrogate dynamically, to obtain fresh information at any time. In a Microsoft world, you would put Active Directory accounts in security groups, and removing access would become suppressing the group membership; the effect is immediate (for a more complex and flexible authorization management, see AzMan).

• Data shall not be encrypted with a recipient's public key until the last moment. E.g. you encrypt an email when you send it; you don't encrypt thousands of documents with a given user's public key "in advance". You must do such late encryption for two main reasons: because you cannot enforce forgetfulness (as seen above), and also because encrypted data is utterly lost when the corresponding private key becomes unavailable (e.g. Bob loses his token).

• Data, when stored, should probably still be encrypted, but with a locally known key, and that encryption is meant to avoid leaks when old disks or backups are discarded. The system which handles the data uses the "master key" to decrypt it and encrypt a copy of the data element with the public key of a given user, but just for that element, and only after having duly verified that right now, in the central authorization manager, the said user is allowed to see the document. Alternatively, the data element, once decrypted with the master key, is sent as is to the user through a protected tunnel (think SSL here) after having verified that the user is indeed at the other end (here goes the user certificate and its validation) and that the user is authorized to access that data element.

---

In fact, classification levels are only a very crude authorization system, and are not even the main source for authorization. When a document is "secret", it does not mean that every secret-cleared user may read it; it rather means that a given specific set of security features must be activated for that document (keep it in a safe, don't make copies, don't move it outside of a given building...). The relation between classification levels and authorization is one-way: to read "secret" documents, a user MUST have the "secret" level clearance (or higher), but that is not sufficient; the user must also be authorized (because of his role) to read that document. In a business context, this means that though both the Vice-President for Human Resources and the VP for Sales both have "top-secret" clearance, there is no automatic reason why the HR VP should be able to read top-secret Sales documents, and vice versa.

(In actual government / military contexts, it turns out that when papers are tagged "secret", with a very visible red banner or stamp, this mostly is meant so that the janitor does not discard the paper as garbage when he finds it on a desk in the evening.)

Answer 2

I assume every government can use a bit different classification system. But if I were you I would start with Security Policy Framework of UK government. I am pretty sure you will find there some useful information. Also ISO 27001 and related documents are very useful in this kind of search.

Answer 3

Every system is different. In the US, the civilian classifications of NIST are different from the classification system used by the military and intelligence agencies. If you have to meet the laws of your country, you really should look to your country's specific published policies.

And it gets more complex than you described. Top Secret generally means "need to know is restricted to a specific topic", so each classification needs to include the topic. One organization could have many different Top Secrets, such as Top Secret-Credit Cards, Top Secret-Clinical Trials, and Top Secret-Product X. Having Top Secret clearance to credit cards from your customers does not grant clearance to view the Top Secret formula for Product X, nor does it give access to the clinical trial data. A simple "5 is greater than 4" approach can't account for this.

But it sounds like despite all your various internal classifications, you need to have a "magic key" that allows a complete override of all of them for sufficiently high level legal requests. This can be accomplished using a key escrow encryption system. The way key escrow works is that everything is encrypted using a symmetric algorithm (like AES-256), and each item is encrypted with a unique AES key. That symmetric key is then encrypted with the appropriate public key for the classification required. It is also encrypted with the public escrow key, and both encrypted keys are kept with the document. Knowledge of either private key permits decryption of the AES key, and recovery of the original document.

Various security companies offer such functionality out of the box. RSA comes to mind, but I know they're not the flavor of the month given their potential involvement with the NSA. I recommend you seek out a product that performs key escrow, then have a serious discussion with the vendor's security engineers.