What is Key Server in Cryptography? – At last we turn to key management. This is, without a doubt, the most difficult issue in cryptographic systems, which is why we left it to near the end. We’ve discussed how to encrypt and authenticate data, and how to negotiate a shared secret key between two participants. Now we need to find a way for Alice and Bob to recognize each other over the Internet. As you will see, this gets very complex very quickly. Key management is especially difficult because it involves people instead of mathematics, and people are much harder to understand and predict. Key management is in many ways a capstone to all we have discussed so far. Much of the benefit of cryptography is defeated if key management is done poorly.
What is Key Server in Cryptography
Before we start, let us make one thing clear. We talk only about the cryptographic aspects of key management, not the organizational aspects. The organizational aspects include things like a policy covering whom to issue keys to, which keys get access to which resources, how to verify the identity of the people who get keys, policies on the security of the stored keys, mechanisms for verifying that these policies are being adhered to, etc. Every organization will implement these differently, depending on their requirements and their existing organizational infrastructure. We focus only on parts that directly affect the cryptographic system.
One way to handle key management is to have a trusted entity to hand out
all the keys. We’ll call this entity the key server.
What is Key Server in Cryptography
The basic idea is simple. We assume that everybody sets up a shared secret key with the key server. For example, Alice sets up a key K A that is known only to her and to the key server. Bob sets up a key K B that is known only to him and to the key server. Other parties set up keys in the same fashion.
Now suppose Alice wants to communicate with Bob. She has no key she can use to communicate with Bob, but she can communicate securely with the key server. The key server, in turn, can communicate securely with Bob. We could simply send all the traffic to the key server and let the key server act as a giant post office. But that is a bit hard on the key server, as it would have to handle enormous amounts of traffic. A better solution is to let the key server set up a key K AB that is shared by Alice and Bob.
What is Key Server in Cryptography
This is the basic idea behind Kerberos, a widely used key management system. Kerberos is based on the Needham-Schroeder protocol.
At a very basic level, here is how it works. When Alice wants to talk to Bob, she first contacts the key server. The key server sends Alice a new secret key K AB plus the key K AB encrypted with Bob’s key K B . Both these messages are encrypted with K A , so only Alice can read them. Alice sends the message that is encrypted with Bob’s key, called the ticket, to Bob. Bob decrypts it and gets K AB , which is now a session key known only to Alice and Bob—and to the key server, of course.
One of the features of Kerberos is that the key server, called the KDC in Kerberos terminology, does not have to update its state very often. Of course, the key server has to remember the key that it shares with each user. But when Alice asks the KDC to set up a key between her and Bob, the KDC performs the function and then forgets all about it. It does not keep track of which keys between users have been set up. This is a nice property because it allows a heavily loaded key server to be distributed over several machines in a simple manner. As there is no state to be updated, Alice can talk to one copy of the key server one moment and to another copy the next moment.
It turns out that the cryptographic protocols needed for a Kerberos-style system are very complicated. Initially, designing such protocols looks quite easy to do, but even experienced cryptographers have published proposals, only to have them broken later on. The flaws that creep in are very subtle. We’re not going to explain these protocols here; they are too dangerous to experiment with and modify by hand. Even we shy away from designing this type of protocol anew. If you want to use a protocol of this sort, use the latest version of Kerberos. Kerberos has been around for quite a while, and many competent people have looked at it.
Sometimes it is not possible to use Kerberos. The protocol is far from simple, and it imposes some restrictions. Servers have to memorize all tickets that they have accepted, and every participant needs a reliable clock. There are several situations in which these requirements cannot be met. Further, we find it more informative to study a simpler design.
We can create a simpler and more robust solution if we don’t put so much emphasis on efficiency. It turns out to be especially useful to allow the key server to maintain state. Modern computers are far more powerful than they were in the days when Kerberos was first designed, and they should not have any trouble maintaining state for tens of thousands of participants. Even a very large system with 100,000 participants is not a problem: if each participant requires a 1 kilobyte state in the key server, storing all states requires only 100 megabytes of memory. The key server still needs to be fast enough to set up all the requested keys, but that too is much less of a problem with modern, fast computers.
We will only discuss the situation in which there is a single key server. There are techniques that you can use to distribute the key server state over several computers, but we won’t go into the details, because you really don’t want to have a key server for tens of thousands of participants; it’s too risky. The danger of large key servers is that all the keys are in a single place. That makes the key server a very attractive target for attack. The key server must also be online at all times, which means an attacker can always communicate with the key server at will. The current state of the art does not protect computers from network attacks very well, and putting all your keys in a single place is an invitation to disaster. For smaller systems, the total ‘‘value’’ of the keys kept by the key server is smaller, so this threat is reduced. 1 In the next few chapters we will explore a solution to the key management system that is better suited to very large systems. We will restrict our discussion of key servers to fairly small systems—up to a few thousand particiants or so.
What to Choose
If you want to implement a central key server, you should use Kerberos if possible. It is widely available and widely used.
In those situations where Kerberos is not suitable, you will have to design and build something like the solution we described, but that will be a major operation. For the most common type of cryptographic applications we have
seen, you should count on spending as much time on the key server system as you did on the entire application. Our discussion here should help guide your thinking.
If You Like This Please Comment Down For More Hacking Content Click Here