What essential differences exist between asymmetric key and symmetric key
crypto-protocols when it is necessary to support revocation of stolen keys?
a study in key distribution and revocation in both symmetric key and asymmetric key
crypto-protocols
Student name: XIAOCHUAN LUO (HILL)
ID No.:02037458
Lecturer: Bruce Christianson
Jo Spring
No. of words: 2970
Symmetric key and asymmetric key encryption and decryption are two different
cipher mechanisms. Although both of these two need key(s) to fulfill the whole cipher
process, the exact procedures are variable. One significant difference is the key
management issue. Symmetric key cipher needs only a key per session, whereas
asymmetric key cipher needs two keys in pair to complete an encryption-decryption
process; symmetric key cipher needs to make sure the key shared by two parties is
secure in any circumstance until the key is announced to revoke or expired; in contrast,
not every key out of two need to be secure in asymmetric cipher. The public key can
be retrieved by any party who wants to; however, the private key has to keep
confidential. “Key management is the bugaboo of encrypted enterprise networks” (F.
Simonds and J. Ranade 1996). To some extent, key and key management is a
relatively important issue through the cryptography concept.
Generally, key management could involve several parts, key generation, key
transport, key usage, and destroy of key. These parts consist of the lifecycle of key
(different authors may use different titles or names to define or describe the key
lifecycle, or, have variety of stages of the life cycle, however, the basic principle is the
same). Every part of the lifecycle has a close relationship to each other. Key
revocation is positioned between key usage and key destroy process, as the revocation
means the key has to be terminated unexpectedly, possibly because the key is
compromised and/or lost of confidentiality. Furthermore, the key revocation could
have several circumstances depending on the way that the key has been delivered in
different crypto-systems. “The strength of any cryptographic system rests with the key
distribution technique” (W. Stalling 1995). In other word, crypto-systems and key
distribution methods are essential to support the revocation. Hence the methods of
revoking a key are variable.
Briefly, this paper is bout to explore key distribution methods in both symmetric
and asymmetric systems respectively. Each method will be given an analysis of the
key revocation issue accordingly.
“All of cryptography depends on the distribution of cryptographic keys which
are either secret of need integrity” (D. Grover 1990). Although “symmetric key
encryption is perceived to have an extensive history” (A. J. Menezes et.al. 1997),
hence has a number of matured technologies, such as “high rates of data
throughput”(A. J. Menezes et.al. 1997), short length key, etc., it does have
disadvantages. In symmetric key system, only one key need to be used between two
parties, however, the key is shared by each other, thus the secrecy of the shared key is
essential. “The primary disadvantage of symmetric cryptography is the difficulty
distributing the secret keys” (J. Barkley 1994). the confidentiality of the whole
system rely on the secret key, once the key has lost the secrecy, the system is
vulnerable at all. To solve this problem, there are several options.
First, of course, is to deliver the key by a secure channel manually. The channel
can usually be a trusted person. Alternatively, the channel could be a physical secured
path, for example, a concrete tunnel. The secret key can then be delivered through the
tunnel to each node. However, the drawback is obvious, it is time consuming and
uneconomic. Furthermore, it seems impossible to be done in distributed systems as
every node in the systems may have a number of different secret keys correspondent
with different parties. Those keys can not be delivered by individual times and times
again.
Assume the two parties will be always loyal, hence once the trusted person has
compromised or the physical secured tube has been broken, the key need to be
revoked. The method is simple: two parties let each other know what was happened,
then choose another key and transfer it by another trusted person or by another
physical secured tunnel again. Hence the incident could happen again and again. Even
worse, a third party can intercept and modify or forge a fake revocation, and then send
to one of the party indicating a false revocation message. As there is no authentication
mechanism, and the revocation announcement in this situation can not be encrypted as
the key has compromised, the two parties have no other secret key to encrypt the
message. The third party can easily masquerade one party and retrieve all the
information he/she wants. This is the most vulnerable system as there is no
countermeasure towards lost of confidentiality; this is not a wise choice in nowadays
applications.
Second, apart from the physical delivery to the two parties, a “hierarchy” (J.
Barkley 1994) concept has introduced. The “hierarchy” (J. Barkley 1994) structure
means two parties do not exchange secret key directly. There are more than one key
involved when two end points communicate. Keys involved in the communication
have different power properties. Set the two parties involved in the communication as
A and B. A and B share a session key Ks, which is a short-life period key and can be
generated from either A or B. Ks is only used to encrypt the data and it is at the
bottom of the hierarchy structure. A and B share another key called master key or key
encrypting key Kk, which has long life period and positioned at the top of the Ks. Kk
is used to encrypt the session key Ks. Then the encrypted session key Ks can be
transferred electronically without manual delivery. The protocol can be described as
follows:
A: Ks
A- -B: EKk(Ks)
B: DKk(EKk(Ks))
B: Ks 
This protocol is illustrated in ANSI (American National Standards Institute)
standard X9.17 as “two tier model” (J. Barkley 1994). The advantage is by using a
longer life time key Kk, to encrypt the session key Ks for every single conversation,
then exchange the encrypted session key electronically, can reduce the possibility that
lost of secrecy. However, the problem is the master key Kk is also needed to be
delivered manually and for N conversations, there are N master keys to be transferred
prior the conversation begin. Hence the key revocation issue seems similar with the
situation mentioned above. As the session key has a very short life period, the

this paper will continue use the same symbols and expressions used in this example to illustrate the different
types of crypto-protocols thereafter.
possibility of lost secrecy of the session key is minimized comparing with the master
key. However, the risks do exist, although the session key revocation message can be
encrypted by the master key shared by the two parties, a third party can intercept the
revocation message and apply an active attack as the two parties can not detect the
modification. Once the master key has lost confidentiality, the whole systems
suddenly swap into a weak system and will be facing problems as same as the manual
delivery scenarios.
Thirdly, a Trusted Third Party (TTP) is introduced. The X9.17 standard
introduces two models with the third party involved: Key Distribution Centers and
Key Translation Centers. In these two models, Trusted Third Party C generates keys
for every session. Every end point share a unique key with C, C uses shared key to
encrypt the session key generated by itself and then send to the requester. End point
also uses the shared key with C to decrypt it in order to have the session key. The
whole process can be described as follow:
C: Ks
C--A: EKa(Ks)|| EKb(Ks)
A: DKa(EKa(Ks))
A: Ks
A- -B: EKs(P)||EKb(Ks)
B: DKb(EKb(Ks))
B: DKs(EKs(P))
C sends A two messages, one is encrypted with Ka and the other is encrypted
with Kb. When A receives these two, it can forward the second one directly to B in
order to let B know the session key Ks.
The Key Translation Center is slightly different with Key Distribution Center;
the center is not generating session keys for every request. The protocol described as
follow:
A: Ks
A- -C: EKa(Ks)
C:DKa(EKa(Ks))
C:EKb(Ks)
C- -A:EKb(Ks)
A- -B:EKb(Ks)
B: DKb(EKb(Ks))
B: Ks
The advantages of the key centers are “flexibility and efficiency” (A. J. Menezes
et.al. 1997). Users only need to exchange and store one master key (with the center)
rather than exchanging master key every conversation. The short come is cost,
“communication partners can reduce cost by first exchanging a KK(master key) with
the aid of a key center, then distributing DKs(session key) using the Point-to-Point
(two tier) approach” (J. Barkley 1994). Unfortunately, this protocol has not made
any change on supporting the good key revocation methods. Although this model
reduces the risk by managing the secret key issue in a KDC/KTC, the process of
delivering the secret key has not yet changed. Hence a third party can still be able to
intercept the revocation message and apply some modifications without notice.
Furthermore, the KDC/KTC is the weakest point, an intruder can make KDC/KTC
compromised and then the intruder can access all the process he/she wants. Originally,
to revoke a secret key is very simple when the system is secure, however, once the
key compromise scenario happened, it is hard to guarantee that there are no other
parties want to intercept or forge or masquerade information. Lack of authentication
mechanism is a significant drawback of symmetric key crypto-system.
It is obvious that by adding authentication mechanism in either key distribution
or key revocation process is a vital important issue in symmetric key crypto-system.
To implement this mechanism, it can be fulfilled by adding some random material
along with the message to provide such function. Message Authentication Code and
Hash function are two practical methods. They use certain algorithms to generate
random number, which is different in every transaction. The random number are never
about to be the same when the plain messages are different. This implementation can
reduce the risks against the third party’s active attack as once the message has been
modified, the results will be different when the receiver operate the MAC or Hash
function again. Set the revocation message as R, either A or B replies the revocation
as T, H refers to Hash function. The key revocation protocol under this circumstance
runs as follow:
C- -A: Eka (R || H(R))
A: Dka(Eka (R || H(R)))
A: H(R)^
A: check if H(R)=H(R)^
Message true, accept
Else
Discard and report.
A- -C: Eka(T|| H(T))
C: Dka(Eka(T|| H(T)))
C: H(T)^
C: check if H(T)=H(T)^
Message true, accept
Else
Discard and log
C: Ks
C--A: EKa(Ks)|| EKb(Ks)
A: DKa(EKa(Ks))
A: Ks
A- -B: EKs(P)||EKb(Ks)
B: DKb(EKb(Ks))
B: DKs(EKs(P))
More precisely, symmetric system can apply MAC or Hash function added into
every single message to provide the authentication not only in the key revocation.
In asymmetric key crypto-system, key management problem is totally different
comparing with the symmetric key crypto-system. Public key system has a key pair,
one is private, which has to be kept secure while the other one is public key which is
suppose to be shared by the public. For public key, because it is a public, this key is
designed to be exposed to publicity. Hence the confidentiality of the key described in
the symmetric key crypto-system is unsuitable to asymmetric crypto-system. In other
word, public key does not need to be concerned with the secrecy. The essential
important is the secrecy of private key. The key revocation issue in public key
crypto-system is mainly concerned with private key. As the private key and public key
are in pair to a particular node, once the private key lost confidentiality, the whole key
pair need to be replaced all together.
However, there are several different models involved in public key systems. The
models are categorized by the types of public key distribution. Therefore, the key
revocation methods are variable in different public key distribution scenarios.
Firstly, public key can be distributed by public announcement. This is the most
convenient way to implement public key distribution. Every user in a certain domain
simply broadcast their public key over the whole domain. It is to be described as
“uncontrolled public key distribution” (J. Barkley 1994). It has a huge weakness as
anyone can forge an announcement to declare that the public key of his/hers has
changed. Additionally, rest of the entities directly trust the announcement since there
is no mechanism to verify the announcement. Then the pretender can receive
messages from the others who want to communicate with the origins. This situation
will be continuing until the origin find out. Although public key system has a vital
advantage, which is digital signature function, it is useless when announcing a key
revocation as the private key has already compromised. Thus, the key revocation in
this scenario is uncontrolled as well.
Secondly, in order to improve this distribution method, public available
directory is introduced.
The available directory collects all the public keys in a certain domain instead of
every entity broadcast the public key in turn. Every entity has an entry in the directory,
thus reduce the possibility that anyone can forge an announcement and want to
pretend as someone else. Each entity access the directory to gain a public key which
belongs to the receiver. There seems no other way to alter public key, then avoiding
the enouncement fraud. Unfortunately, the weakness still remains. It somehow looks
no difference in revoking a private key comparing with the first one.
Thirdly, a higher stronger verification mechanism has applied, called public key
authority. The public key authority is somehow similar with the directory, but the
difference is public key authority provides a verification strategy against user, while
available directory has not. The so called verification strategy is an extra
authentication by applying a digital signature to authority’s reply. For example, end
point A wants to communicate with B, A sends a request to the authority, authority
replies a message including B’s public key and timestamp that are encrypted by using
authority’s private key Kau-, A receives the message and decrypts it by using
authority’s public key that A shares with authority. This step can make sure that the
reply is actually sending back from authority not someone else. Then A sends B a
message by using B’s public key to initial the conversation, B receives and then send
a request to authority to check. The authority also send back a message containing A’s
public key and timestamp encrypted by authority’s private key Ka- again. B received
it and decrypts it using the public key shared between B and the authority. At this
point, both A and B have each other’s public key and the communication can then be
established. The protocol is described as follow:
A- -Authority: request||Time1
Authority- -A: EKau-(Kb+||Time1)
A: DKau+( EKau-(Kb+||Time1))
A- -B: EKb+(Ida||Time2)
B- -Authority: request|| Time3
Authority- -B: EKau-(Ka+||Time3)
B: DKau+( EKau-(Ka+||Time3))
B- -A: EKa+(Time2||Time3)
A- -B: EKb+(Time3)
Time1, Time2, Time3 are here to distinct different responds as there may have
several requests send from different end points to authority. A timestamp can distinct
those respond respectively. So far so good, the public key distribution seems much
more better than before, however, a certain end point need to query the authority
every time when it wants to establish a new session with a new end point. “The public
key authority could be somewhat of a bottleneck in the system”.(B. Schneier 2000).
Further more, “the directory of names and public keys maintained by the authority is
vulnerable to tampering” (M. Y. Rhee 1994). As once the private key is compromised;
all the functions that can provide authentication in the public key crypto-system have
been restricted. The key revocation announcement can not be applied with digital
signature as the private key is not safe, furthermore, other entities who want to
communicate with this ends might not know this key pair has compromised, they
might continue to use the old public key. Thus a huge disaster will be brought in. The
intruder can then receive any message that is still encrypted by using the public key
out of the compromised key pair. Also, if the authority itself has been compromised,
the whole system will be exposed in danger.
Fourthly, a updated approach, is to use certificate as a token to establish
conversation without contacting the authority every time when new users are involved.
A certificate is “a public document containing information identifying a user, the
user’s public key, a time period during which the certificate is valid and other
information.” (J. Barkley 1994). The certificate can be managed by a proved trust
authority named Certification Authority (CA). In comparison of the public key
authority, end points do not need to obtain each other’s public key by enquiring the
public key authority, they can request a certificate issued by the certification authority
in advance, and store the certificate locally. The content of the certificate is slightly
different with the one issued by public key authority, containing ID information of the
requester and timestamp and the requester’s own public key rather than the receiver’s
public key. The whole content in the certificate is encrypted by authority’s private key.
Hence the authentication function is fulfilled. When two parties want to establish a
session, the sender transfer its certificate to the receiver first, as the certificate has
been signed by certification authority’s private key, the receiver can then believe that
the public key contained in the certificate is trustful. Receiver sends its own certificate
to the sender accordingly, then the sender can obtain receiver’s public key. The whole
process described as follow:
A- -Authority: EKau+(Ka+||IDa)
Authority- -A: EKau-(Ka+||IDa||Time1)
B- -Authority: EKau+(Kb+||IDb)
Authority- -B: EKau-(Kb+||IDb||Time2)
--------------------------------------------------A- -B: EKau-(Ka+||IDa||Time1)
B:
DKau+( EKau-(Ka+||IDa||Time1))
B- -A: EKau-(Kb+||IDb||Time2)
A:
DKau+( EKau-(Kb+||IDb||Time2))
The Time1 and Time2 are validated value, indicating the valid period of this
issued certificate. Certification Authority structured public key management is
considered as a very essential principle to nowadays applications. As fact, Public Key
Infrastructure (PKI) concept which is widely used in business application nowadays is
based on CA mode. “The integral internal component of a PKI is the Certification
Authority (CA), which acts as a trusted third party that vouches for the authenticity of
any party whose digital ID it has signed. Users can implicitly trust any Public Key
that has been signed by the CA” (e-certify firm 2004). The CA mode is the practical
mechanism that is currently implemented in the reality for public key crypto-system
involved scenarios.
In this CA model, the CA is not only in charge of issuing public certificate, but
also managing the revocation certificate as the same (It is possible that every entity
can generate the key pair on its own, however, managed by CA is an optimized
method as it can avoid intruder forging a revocation announcement in order to change
the key pair). As the certificates do not need to be issued only when they are needed,
they can be issued in advance. This theory provides the vital important functionality:
every entity can get both a public key certificate and a private key/key pair revocation
certificate prior to the entity really begin to involve in the communication. As a matter
of fact, “it is suggested that a key revocation certificate should be generated as soon as
the key pair is created” (P. Brooks 2000). As public key crypto-system can apply
digital signature by using private key, the certificates, no matter they are public key
certificates or key revocation certificates, are all having more confidentiality and
authentication. Furthermore, the CA can strength the certificate not only by add digital
signature, but also add the timestamp or nonce which have a periodical feature
enabled. Thus, the certificate can provide authentication with time function. Then it is
possible to “revoke the key, even without the secret key” (A. Engelfriet 1996).
Because although the intruder knows the private key, the entity who is suffering the
attack is still able to public their key revocation certificate, as there is a timestamp in
the certificate, indicating that this certificate was generated in advance when the
private key was still secure.; It means the private key will be not secure thereafter
once the revocation certificate has broadcasted. Then the key revocation certificate
will be stored on a list from CA called “Revocation Certificates List” (P. Brooks
2000), and the rest entities will check the list from CA in order to avoid using the
public key from the compromised key pair. This mechanism can avoid the revocation
fraud. This feature can make the whole system more stable and more secure.
Furthermore, several combination distribution methods are important as well, the
system will use symmetric encryption during each session, but delivering the secret
session key by using the asymmetric encryption. It will provide the speed of the
symmetric encryption and the digital signature authentication mechanism from
asymmetric encryption simultaneously. The key revocation issue in this circumstance
is relatively similar with the system mentioned in the CA model. As a matter of fact,
this combined model is running under the public key system. The entities can have
both public key certificate and key revocation certificate in advance before they start
to communicate.
This paper has generally reviewed the key distribution and key revocation issues
in both symmetric and asymmetric crypto-systems. Basically, the key distribution and
key revocation solve “how to deliver or revoke the key(s) securely and efficiently”
question. There are a number of different methods to distribute the key(s) while there
are various methods to revoke the key corresponding with different distribution
methods. The main concerns are the same: how to maxim the possibility of
confidentiality, integrity level and how to implement better authentication in order to
verify the entities’ real identifications. All the methods mentioned above are all based
on this principle. Only the level of the achievement may vary in different protocols.
The better protocols always have more features towards fulfilling confidentiality,
integrity and providing authentication mechanism. As a matter of fact, there is
absolutely no such a perfect system or mechanism that can fulfill all the requirements
related in the security area. Every new system or mechanism is beyond the older one,
having more advantages, and more secured features, however, it will always bring
new drawbacks as well. The crypto-system never stop developing and self-modifying
in order to suit with the more and more strictly requirements in the future.
References












Barkley, J. (1994) “Public Key Distribution”[www document].Retrieved 19-02-04
from
World
Wide
Web:
http://csrc.nist.gov/publications/nistpubs/800-7/figoneca
Barkley, J. (1994) “Secret Key Distribution”[www document].Retrieved 19-02-04
from World Wide Web: http://csrc.nist.gov/publications/nistpubs/800-7/node209.html
Brooks, P (2000), “Key Revocation”, [www document]. Retrieved 01-03-04 from World
Wide Web: http://www.ac.uk.pgp.net/pgpnet/secemail/q4/node9.html
E-certify (2004), “ Guide to Internet Security”, [www document]. Retrieved 24-02-04 from
World Wide Web: http://www.e-certify.com/library/cert_guide.html
Engelfriet A (1996), “PGP FAQ--Revoking a key”, [www document]. Retrieved 01-03-04
from World Wide Web: http://pgp.rasip.fer.hr/faqs/pgp/faq7.html
Grover. D (1990) “the Protection of Computer Software—its Technology and Applications”
Cambridge university Press: Cambridge p105
Menezes. A. J., Oorschot P. C. V., Vanstone S. A. (1997) “Handbook of Applied
Cryptography” (revised reprint with updates, originally issued in 1965 ) CRC Press: London
pp31-40
Rhee, M. Y. (1994), “Cryptograph and Secure Communications”, McGraw-Hill: Singapore
p461
Schneier, B (2000), “Secrets and Lies digital security in a networked world” John Wiley and
Sons: New York p215
Simonds. F and Ranade. J (1996), “Network Security” McGraw-Hill: New York p115
Stallings. W (1995), “Network and Internetwork Security Principles and Practice” Prentice
Hall: New Jersey p87
Stallings, W (2003) “Cryptography and Network Security Principles and Practices” 3rd
edition, Prentice Hall: New Jersey. Pp211-231, pp286-296