ARGON cryptography (by alaric)
I thought I'd like to discuss the design decisions behind the rather brief description of the "security levels" mentioned on the MERCURY page. Don't worry, you don't need to go and read it first - I'll duplicate everything in this post.
To summarise, my design requirement was to implement a cryptograhic architecture for both communications and storage of sensitive data, which allows for:
- Both parties in a communication may have differing security requirements; the maximum of both need to be met
- Security levels need to be specified in a way that is future proof; eg, DES would have been unbreakable in World War II, but nowadays it should only be considered suitable for relatively unimportant data
- Physical communications links may have a certain element of external protection, rendering encryption an unnecessary burden; a cluster of servers locked in a highly screened server room together should be able to communicate sensitive data between each other in the clear, or with a fast lightweight encryption algorithm - after all, an assailant in the room with them could easily interfere with the machines themselves to get them to divulge their keys. However, the same information being shared across the public Internet would need heavy encryption, or be banned altogether.
- Communications links and data storage devices might have a maximum security level of information they can be trusted to at all, no matter how heavily encrypted it is, because any crypto algorithm is potentially breakable.
I decided to represent a "security level" as a natural number, rather than as the name of a crypto algorithm or any other such concrete description of a level of security. I decided that a security level of 1000 should mean that an assailant with equipment worth a million dollars would be able to break that security in about a day. A security level of 500 would mean either that it would cost $500,000 to break in a day, or a million dollars to break in half a day. And so on.
Obviously, with time, that million dollars can buy you more hardware, while also that million dollars being worth less due to inflation. Because of this, a security administrator for an ARGON cluster should make a yearly review of the state of the art in crypto technology (or perhaps trust some widely-trusted public body to do this, if security isn't all /that/ critical to this cluster), and rate each crypto algorithm module available to the cluster in terms of the approximate security level it would provide.
Cleartext over the public Internet would be implicitly rated as providing a security level of 0 - it costs nothing to 'break' cleartext. But cleartext over a trusted local area network would have a higher security level; perhaps it would cost a few thousand dollars to hire a industrial espionage agent to plant a logging device in your server room, or steal the machine's disks, so we might make a guess at the security provided by cleartext over the LAN at 5.
However, we trust the server room machines themselves to handle data up to level 1000; somebody with a million dollars to spend could probably infiltrate the server room and patch a backdoor into the system, via a tunnel through the firewall or a wireless Ethernet device, to gain complete control of one or more of the servers. This means that information requiring a protection level above 1000 simply cannot be trusted to these machines, no matter how it is encrypted in transit, for the machines themselves would still convert the information to plaintext in-memory for processing. Sure, the machines could store encrypted data without knowledge of the key - just as cryptography lets a network link like the Internet with a provided security level of 0 to carry information requiring level 1000 - but they can't process any information requiring a higher level of protection.
The desktop PCs in the office might be trusted to level 10 or 100, depending on the security awareness of employees and the intrusion protection of the building. So the company accounts file, requiring protection level 500, would never be stored on a desktop PC; not even if the entire server room was in chaos and the TUNGSTEN system desperately wanted to mirror imporatnt data that appeared to be in danger of loss out to other nodes. However, individual account transactions being fed into the accounts file, or accounting reports, with protection requirements in the 5-50 range, would be accepted from and allowed to be viewed on at least the better protected of the PCs.
So to summarise the use of encryption levels:
Every node, N, in the cluster has a maximum trust level MT(N). Every communication link L between nodes has a maximum trust level, MT(L), and a level of intrinsic protection, P(L). Every long-term data storage device, D, attached to a node has a maximum trust level MT(D). Every entity E has a required protection level, R(E) Every MERCURY interface I has a minimum required protection level specified by the server, R(I) When a MERCURY interface is invoked by a client, C, the client may also specify their own protection level required for this one request, R(C)
For a start, some restrictions based on maximum trust level: 1. No node N may mirror an entity E such that R(E) > MT(N) 2. No interface I may be accessed by a client C over a link L such that R(I) > MT(L) or R(C) > MT(L) 3. No entity E may be mirrored onto a disk D such that R(E) > MT(D)
Then some "common sense" restrictions to pick out potential security loopholes that could be set up by a careless administrator: 1. No entity E may provide an interface I such that R(I) > R(E) 2. No entity E can use an interface as a client C such that R(C) > R(E) 3. Therefore, no node N may either be client C or server providing interface I in any communication such that R(I) > MT(N) or R(C) > MT(N) 4. No node N may have a disk D such that MT(D) > MT(N) 5. Every node N must have a disk D such that MT(D) = MT(N), where it can store its core OS components (if they can't be trusted, the machine can't be trusted either) and to store any entities actually requiring the maximum protection level of the node.
Then we can mandate:
- When a client C invokes an interface I over link L, the communication protection level required for the communication, R, is the maximum of R(C) and R(I).
- If P(L) > R then no cryptography is required. If R > MT(L) then either a better link must be found, or the invocation disallowed on security grounds.
- If R > P(L), then an encryption algorithm providing security to level R - P(L) must be employed to protect the communications.
- A node mirroring an entity E must store it on a disk D such that MT(D) < R(E)
Pages: 1 2
ARGON, Crypto / security | alaric | 
Sun 8th Aug 2004 10:43 am
6 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
Subscribe
By Ben, Mon 9th Aug 2004 @ 10:01 am
"... if a client contacts with an outdated cluster ID, then the latest public key and node list can be returned to the client, signed with the private key matching the public key that client has."
As you state it, there is no way to recover gracefully from a key compromise. You have to update all cluster IDs on every potential client. In addition, key revocation would be difficult -- you can't just let the server say "key revoked, use another".
In effect, private keys need to be kept secret for ever, otherwise you subject yourself to man in the middle attacks. This is tricky, if you want to keep the public keys on servers connected to the outside world, which you need to do.
Maybe you could consider a hierarchy of keys, with a well known key signing key. This is only used to sign cluster keys, and is kept offline and very secure. This isn't too bad, as you only need to use it when you update cluster keys. So you would distribute the master key to all clients, and let the server update them on the latest cluster key whenever required. Perhaps the master key should be the one in the cluster ID?
An interesting question to ask is how would the scheme cope if you wanted to update the keys every month?
By alaric, Mon 9th Aug 2004 @ 11:07 am
Good point, I must admit I rather skimmed over the public key change management in my head while thinking about it.
One needs the cluster public key - that nodes have the private counterpart of - represented in the cluster ID, since nodes need to actively sign things with it to prove their identity; but since that key is, as you say, compromisable, I think there's no choice but to have at least a hash of the top secret cluster master key present in the ID as well. Then to send a client a new cluster public key, the master public key could be included along with the signed cluster public key, and the master public key can be checked against the hash.
How does that sound?
By Ben, Mon 9th Aug 2004 @ 2:05 pm
It sounds unnecessarily complex, but would work. But you now have two elements, the keys and the hash.
Why not just have the master public key, and get the server to return a key which is signed by that key? You can always cache it for efficiency, in your scheme you'll need to do that kind of thing anyway.
I feel slightly dubious about using hashes of keys, as it reduces the effective size a quite considerably, and a lot rests on the security of the hash algorithm. These haven't been studied as much as crypto algorithms.
But having said all that, you've still got the revocation and expiry problems. I can see that adding a key to the ID neatens up a lot of thing, but it's flying in the face of established key management principles.
By alaric, Mon 9th Aug 2004 @ 2:37 pm
The problem is, established key management principles have yet to be successfully scaled to the Internet. SSL uses a horrible system of trusted third parties, while PGP uses a network of introducers that would prevent anyone from accessing a resource they hadn't had personally referred to them by somebody. Established key management principles tend to have to deal with the current structure of the Internet, where resources are identified by short human readable strings such as URLs or email addresses, with no convenient way of attaching a public key.
There is a mention in Applied Cryptography somewhere of systems that use the address of a resource as a key, or embed a key in the address, but I can't find it now :-/ It's little more than a footnote anyway.
"Why not just have the master public key, and get the server to return a key which is signed by that key?"
As in, before communicating with any server, you first do a quick key-getting exchange with it? If that is what you mean, then that's sort of what I'm proposing anyway - the client tries, using the key it has already given to it in the address. If it's the wrong key, the server notes this and issues it a new public key, signed by the master key. The client updates its copy of the address. Indeed, should a client (somehow) come accross a cluster ID with no public key in, it could just ping the cluster with a null key, and then be given the most up to date key. The lazy update protocol used for this, as for when the list of IPs of nodes in a cluster changes, works by the cluster ID having a serial number that is incremented when the node list or the public key changes. This serial number is sent in every request from the client, and the server responds with up to date information if it needs to.
Storing a hash of the master public key rather than the master public key itself is just intended as a measure to keep cluster IDs down in size! 2048 bits = 256 bytes, and UDP packets can rarely be larger than 1500 bytes. I'd like an ARGON directory lookup protocol to be able to return an interface handle (cluster node IP list + public key + serial number + entity number + interface number + persona field + master public key or hash thereof) in a single UDP packet, like DNS does, to avoid it having to maintain costly session state for such a lightweight service.
Revocation isn't really doable without some kind of trusted place to store revocations... I'm dead set against trusted third parties for this stuff; humanity needs a way to do server authentication without them. Maybe a key expiry time needs to live in the cluster ID, too, and the cost of an exploited key will be that people who can spoof your nodes on the Internet can pretend to be them until the key expires.
If they could steal the private key from your nodes, though, maybe they could just directly infiltrate them anyway; perhaps effort is better spent making the nodes hard to infiltrate than making horrible compromises to shut the door once the horse has bolted 😉
By Ben, Mon 9th Aug 2004 @ 6:44 pm
Crypto is about planning for the worst case. Having no revocation seems a bit troublesome.
Hashes... yes, it will reduce the size of the UDP packet, but at the expense of a potential weakness. You don't quite know what will happen, and message digests are almost an unexplored frontier of crypto.
You can attach a key to a URL by putting a record in the DNS. As long as you trust DNS, that is. There are no easy answers to key management. It's often said that in crypto, the algorithms are easy, but it's the key management on which your scheme rests.
By alaric, Mon 9th Aug 2004 @ 7:15 pm
What supports revocation these days? I know that PGP keyservers can contain revocation certs, but you'll only see them if you check the keyserver - and most people only seem to contact the keyserver to fetch a key when they first want to communicate with somebody they've not got a key for.
I don't think TLS does revocation in practice, either; I've seen mention of revocation certificates in openssl, but I've never seen a mention of how they are broadcast to the world when a TLS identity cert is compromised!
How could we do revocation? By specifying, in the cluster ID, the contact details of a third party that should be checked with to see if the key you currently hold is outdated? How do we authenticate the third party? We still have the same problem...
One can base hash functions on well-studied crypto; use a trusted block cypher as your hash function. Run it in a feedback mode across the entire block, then take the final output block as your hash, and many other such tricks.
Bear in mind that all digital signing systems I've seen used in anger have relied on a hash function! Are you sure they're that untrustworthy?
If you can trust DNS, then you might as well trust everything anyway 🙂
Yep. I don't think there's a perfect solution anywhere - it's all tradeoffs. I plan to get rid of having to rely on third parties (which are a centralised high-risk attractive target for the forces of evil, and are performance bottlenecks, and there isn't one everyone will trust), at the cost of revocation not happening.
For a start, it won't be all that easy to leak the cluster private key. The system can guard it very jealously; there's no need for even an administrator to be allowed to read it. Perhaps nodes below a certain level of physical-security-trust might only keep it in RAM, and have to ask more trusted nodes to send it a copy of the key every time it boots up. The key only needs to be issued at all to nodes that are actually publicly visible. The page of RAM with it in can be locked so it's not swapped out. Indeed, the private key and the code that does encryption and signing with it might be put into a seperate address space to the rest of the system, and communicate via UNIX sockets.
Sites where security really matters are welcome to have military-style seperate crypto hardware attached to the server nodes, with the key buried inside in tamper-proof storage with a self destruct handle on the front and an armed guard.
Secondly, is stealing the cluster private key likely to be the weakest point? Most of the things you'd have to do to steal it are harder than just taking control of one or more nodes, anyway. The only times I've heard of TLS certificates needing revocation came down to social engineering attacks anyway ("Hi, Verisign, it's Bill Gates here... yeah, we need a new key pair, CN=*.microsoft.com... bill to the usual address, OK? Oh, can you email it to my, uh, home email address? billg20392@hotmail.com if you could?"). The way I plan to handle it, the only interaction the security administrator would have with the key management system is to provide the disk with the master private key on it (or, rather, the disk containing a string of bits the size of the master private key which, when XORed with another such string of bits kept in the cluster, produces the master private key, or one of those any-N-of-the-M-keys-will-do thingies) to cause a new cluster key to be generated. One would have to try hard to extract the actual cluster private key, by using low-level debugging systems, thus reducing the set of people who know how to do it that could be socially engineered, and reducing the chance of accidentally leaving a copy of it anywhere (no matter how hard you try).