The Yaksha security system

The
Yal(sha
Security
Heralding future reusabJe security systems,
the Yaksha security infrastructure provides
multiple security functJons~authentJcatJon,
digita signatures, key exchange, and key escrow.
Th
Security System
Ravi Ganesan
"'.
:
."
:.'."
• :.
i'..~:
:
•
.
Hindu methology, Yakshas are "good" demigods who guard the
ates of heaven. They are extremely flexible and have the power to
"ansform themselves into other forms, such as birds and tigers. In
esigning the security infrastructure that will guard the gates
:';:
: :.7:'ii!gi~:~i{÷ :':k.':h':"
""
to
our
"
e m e r g i n g information infrastructure, it is i m p o r t a n t
that we look for similar flexibility. T h e Yaksha security system is a security technology [4, 5] capable of
reusing a single security infrastructure to p e r f o r m
various security f u n c t i o n s - - a u t h e n t i c a t i o n , key
exchange, digital signatures, and key escrow. This
article describes how the Yaksha security system can
be used for key escrow.
It is c o m m o n l y accepted that encrypted c o m m u n i cations and data storage make up an essential comp o n e n t of our e m e r g i n g information infrastructure.
Somewhat m o r e controversial is the concept that certain third p a r t i e s m o t h e r than those c o m m u n i c a t i n g
or storing information---may have a legitimate right.to
seek access to the information without the active
cooperation of the participants. Clearly, encrypting
information being c o m m u n i c a t e d or stored could
put the third parties at a significant disadvantage.
Techniques for providing secure communications
and storage with intentional b a c k d o o r s that allow
legitimate third parties access to the information fall
into the b r o a d category of what may be described as
key escrow systems• T h r o u g h o u t this article, we use the
t e r m authority synonymously with legitimate third party.
When the authority is the government and the participants are citizens, the entire concept is fairly controversial, as has been well documented in the pages of this
magazine [12] and other publications. In this context,
the system that dominates the discussion is the so-called
Escrow Encrypuon Standard or Clipper System [3]. An
COMMUNICATIONS
OF
THE
ACM
Mal°ch 1996/~,ot. 3,),
*~ No. 3
55
analogous (and in our opinion, less controversial) situation exists when the information is owned by an organization or corporation, the participants are employees, and
the third parties are legitimate organizational or corporate authorities. T h e term "corporate key escrow" is
loosely used to describe this situation.
Several key escrow systems have been proposed in recent years, and in this issue of Communications, Denning
and Branstad [3] present an excellent s u m m a r y and taxo n o m y of these various systems. Each of these systems
approaches the problem using a different underlying
technical approach, as well as from what can be described
as a different philosophical stance. T h e Yaksha system has
its own philosophical stance, beginning with a different set
o f assumptions about the requirements than m a n y of the
other systems. T h e article begins with a s u m m a r y of key
requirements driving the design of the system, provides
some necessary background, describes the general system,
shows example applications for telephony, email, and
data storage, and finally summarizes our conclusions.
Requirements
Two c o m m o n l y accepted requirements essentially define
key escrow systems:
• T h e system should provide an authority the ability to
access encrypted information without the cooperation
o f the participants.
• T h e "backdoor" inherent in the system should not be
usable by an unauthorized third party.
Although we view the requirements discussed in the tbllowing paragraphs as important, they are not necessarily
c o m m o n l y accepted.
Requirement: Authorities should have access only to shortterm session keys, not go long-term user secrets. [n most cryptographic systems, each user has a long-term private secret.
In public-key c r y p t o g r a p h y [10], this would be the user's
"private key." In a third-party authentication system [7],
this would be the long-term secret shared between the
user and the third-party server. For communications security, these long-term private secrets are typically used to
negotiate a short-lived session key that in turn is used for
encrypting a given session or conversation. I f a legitimate
authority seeks to eavesdrop on a conversation, one of two
things can happen:
• T h e key escrow system allows the authority to discover
the user's long-term private secret, t h r o u g h which the
authority can learn the session key for a given conversation and proceed to eavesdrop.
• T h e key escrow system allows the authority to recover
the session key for a particular conversation, but not the
long-term private secret. T h e authority can still eavesd r o p successfully, but the long-term private secret is
sale.
Key escrow systems should be designed a r o u n d the latter
approach o f revealing only short-lived session keys. We
believe this is important for several reasons:
• Since the long-term private secret is never revealed to
anyone, it can be reused ~or other functions, such as
S~
March 1996/Vol.39, No. 3 ~ O I 4 M I ~ W l C A ' r l O N I O i l T i l l A C M
digital signatures. In systems in which an authority can
access this long-term secret, reusing the long-term private secret to generate digital signatures gives the authority the power to forge signatures.
• Revealing only session keys, in o u r opinion, provides a
finer level of granularity of control. For instance, in
such systems, one could implement such policies as:
T h e authority can eavesdrop on all o f J o h n Doe's conversations, except those he has with his wife or lawyer;
or T h e corporation can decrypt all of J o h n Doe's files
saved between March 1994 and September 1994, but
not files saved before or after those dates. To our mind,
escrow systems represent a compromise between an
individual's right to privacy and an authority's right to
eavesdrop. Revealing session k e y s - - a s opposed to longterm private secrets--provides m o r e opportunities for
compromise.
• T h e compromise is not permanent. T h a t is, in systems
in which long-term private secrets ave revealed, the
compromise o f the user's secret is permanent. At some
point, the user must get a new private key, or if the key
is e m b e d d e d in a chip in a cellular phone, a new chip.
O n the other hand, revealing session keys does not compromise the long-term integrity o f the p e r m a n e n t secret. So, once the period o f "legal eavesdropping" is
over, the user does not have to be issued a new private
secret.
We note, however, that delivery of session keys to an authority requires the escrow server to be on-line. But we
are not suggesting that the escrow agent inspect the contents o f any messages; in a practical system, it is unlikely
that the agent would have any access to the actual message
stream, and the agent's participation would be limited to
playing a role in setting up the parameters for a session.
While the justification for this requirement is g r o u n d e d
in a debatable philosophical stance, the next requirement
is based on something m o r e c o n c r e t e - - m o n e y .
Requirement: It is ve*~y desirable that the key escrow system
reuse the security infrastructure necessary for other secu,rity fu, nclions, such as key exchange, digital signatures, and authentication.
In theory, it is possible there could be distinct security
infrastructures for different security functions. Examples
include long-term private secrets to:
• Authenticate yourself (prove your identity) to a bank
teller machine;
• Sign a document;
• Perform key exchange for encrypting conversations;
and
• Mlow you to participate in a key escrow system.
T h e problem with such all a r r a n g e m e n t is cost. Each o f
these separate keys has an associated infrastructure for
generating keys, resetting keys when needed, revoking
keys, and so on. From a user perspective, it may well be
the case that the distinct infi-astructures translate into distinct keys to r e m e m b e r or n u m e r o u s smartcards to carry.
Finally, quite apart from cost, multiple systems increase
complexity, which significantly affects the ability to maintain the desired security functionality.
The
Requirement: A key escrow system should be implementable
in either hardware or software, should apply to both computer
communications and telephony, and should be usable both for
citizen-government and for employee-organization situations so it
has universal applicability.
This requirement is important for two reasons:
• As we discussed, reusing security infrastructures is beneficial, and it may not be cost-effective to have multiple
infrastructures for different types of key escrow.
• T h e r e is a clear convergence between telephony and
c o m p u t e r communications, and it will become increasingly impractical to treat these situations differently;
there is little logic, for instance, in treating voice conversations differently from on-line chat.
Is it possible to design a system that meets all these requirements? We believe the answer is yes, and this article
describes one system that attempts to meet most of them.
Yaksha
T h e Yaksha system is based on a variant of the RSA [9]
public-key cryptosystem. In public-key cryptography,
each user has a long-term private secret key and an associated public key. In the RSA system, the private key of user
Alice is a n u m b e r d(, and her public key is a pair of numbers (ea,na). Similarly, user Bob has a private key db and a
public key (et,,nt,). To encrypt a message M, Alice would
typically use some encryption function E and a session key
k to compute a ciphertext C = E(M,k). To send the message to Bob, she would further encrypt the session key k
using Bob's public key and a function known as m o d u l a r
exponentiation, that is K = U ~' m o d nb. She would then
send Bob (C,K). Bob would first recover k using his private
key, that is k = K db mod rib, and can then decrypt the message using a decryption function D, that is M = D(C,k).
In this scenario, Alice and Bob are using a shared session key k for encrypting communications. Recovering M
from C without knowledge ofk will be very difficult. Such
systems, sometimes known as conventional, or single-key,
cryptography, are very efficient c o m p a r e d to public-key
cryptography. T h e Data Encryption Standard (DES) [10]
is a widely used example. Alice and Bob are, however,
using public-key cryptography to exchange the shared
session key. In o u r example, Alice encrypts the session key
with Bob's public key and sends it to him. Due to the
properties inherent in public-key cryptography, recovering k from K requires knowledge of Bob's private key,
which only he knows.
This system achieves privacy using the conventional
cryptosystem and key exchange using a public key cryptosystem. How does an authority eavesdrop? One approach
would be to split Bob's private key into multiple pieces at
key-generation time and escrow it with multiple agencies.
U p o n getting legal sanction, the authority would collect
the pieces, recreate Bob's private key, and then use it to
recover the session key k. As discussed earlier, at this point
Bob's private key is no longer private. T h e approach Yaksha uses focuses on revealing the session key k to the authority, thus achieving the authority's objective without
compromising the user's long-term private key.
At the heart of our system is an on-line security server,
Yakllha
security
Sysl
henceforth called the Yaksha server, which interacts ~
users to perform various functions. Each user has a ld]
term private secret no one else, including the Y a k s h a
server, knows or can ever reconstruct. This is truly a privaie secret. T h e Yaksha server maintains for each user (or
entity) another long-term private secret. This secret is
known only to the Yaksha server and is never disclosed to
anyone, including the user or authorities. T h e Yaksha
server then interacts with users to perform a n u m b e r of
security functions:
• Providing credentials to authenticate users to other entities;
• Creating j o i n t digital signatures;
• Exchanging session keys in a secure fashion; and
• Acting as a key escrow agent.
This system, which uses a variant of the RSA system,
works as follows: as in the RSA system, user Alice has, as
her public key the pair (e,,,na). Unlike the traditional RSA
system, however, the Yaksha system uses two distinct private keys--Alice's private key, denoted by d,a, and the
Yaksha server's corresponding key for Alice, d e n o t e d by
day. These two new private keys are related to the original
RSA private key da by the mathematical relation d(,, ×
day = d(~ m o d na. For a more complete discussion of this
variant and its security properties, please see [ 1,4, 5]. This
simple, yet powerful, primitive can be used in a variety of
complex ways.
In the Yaksha system, each user i has his or her own
private key dii, and the Yaksha server maintains a corresponding diy. T h e system can now perform several security functions:
Digital Signatures. Ganesan and Yacobi [5] show how
the user can interact with the server to sign a message M.
Namely, user Alice performs S 1 = M (l'' mod na and sends
S1 to the Yaksha server. T h e Yaksha server uses d(,y to
complete the signature, that is S = Sld"y mod na. Now S is
Alice's signature on message M and is indistinguishable
from a regular RSA signature. Such a system is of practical
importance because by using an on-line server for each
signature, we have instant revocation in case a user's private secret is compromised, have a central place to maintain audit trails, and can also (subject to certain restrictions) allow the user's private portion da(, to be a short
memorizable password. T h e last function is critical to implementing digital signatures in an era when smartcards
and smartcard readers are not yet ubiquitous. In [5], it is
mathematically proven that breaking this system is equivalent to breaking RSA, even in the presence of an active
adversary. It is also shown that neither the user nor the
server can use knowledge of its private key to determine
the private key of the other party; hence the degree of
trust in the server is minimized. See [5] for more details.
Authentication. Several authentication protocols are
possible using the Yaksha system; we will not describe any
in detail here. T h e interested r e a d e r is referred to
Ganesan [4], which shows how the Yaksha server can be
integrated into the Kerberos [8] third-party authentication system to remove some of the greatest weaknesses of
the latter.
JILl
UNIC.A'I'IONIli OP TII!
A|N
March 1996/VoL39, No. 3
S
Key
E x c h a n g e . T h e key e x c h a n g e system we describe
h e r e is chosen to m a k e key escrow possible. W h e n Alice
wishes to c o m m u n i c a t e in private with Bob, she first uses
the Yaksha system to n e g o t i a t e a s h a r e d session key. She
does this by s e n d i n g a message to the Yaksha server, exp r e s s i n g h e r desire to c o m m u n i c a t e with Bob. T h e Yaksha
server g e n e r a t e s a r a n d o m session key k a n d c o m p u t e s
C, = k (l'~'×~" m u d na a n d Ct) = k d~'×~ m u d no. It sends Ca to
Alice a n d Cb to Bob. Alice recovers k using h e r own private
key d(,,, that is k = C(,~l"' m u d n(,. Similarly, Bob w o u l d recover k = Ci,a~'~'m u d no. At this point, Alice a n d Bob have
the session key k, a n d the Yaksha server would d e s t r o y its
copy o f the session key, p r e s u m a b l y inside the safe confines o f a t a m p e r - r e s i s t a n t chip. F o r reasons o f brevity, we
gloss o v e r the fact that in practice k w o u l d be e n c o d e d as
p a r t o f a message with a definite s t r u c t u r e a n d a n u m b e r
o f o t h e r attributes, such as the time stamp. This fact has an
i m p o r t a n t implication: W h e n Alice successfully recovers k
from C~,, she has p r o o f that Ca was i n d e e d sent by the
Yaksha server.
Key
Escrow. At the e n d o f the key e x c h a n g e protocol,
the Yaksha server, which g e n e r a t e d the session key, is in a
position to p r o v i d e this key to an authority. This ability
forms the basis by which Yaksha can be used as an escrow
system. Observe, however, that u n d e r no circumstances
can the Yaksha server c o m p r o m i s e the user's l o n g - t e r m
private secret, b e c a u s e the Yaksha server does n o t know
this secret. M o r e details a r e p r o v i d e d in the n e x t section.
In practice, these protocols would be significantly embellished. F o r instance, it is critical that the session key k
he e n c o d e d in a d a t a s t r u c t u r e with p r e d i c t a b l e structure.
It is also likely that the message s t r u c t u r e s will contain
time stamps. We note, however, that the t r a d i t i o n a l n o t i o n
o f public-key certificates [6], which p r o v i d e a m e c h a n i s m
for a u s e r to retrieve a n o t h e r user's public key in a secure
tashion, is c o m p l e m e n t a r y to Yaksha a n d would be used
as p a r t o f the Yaksha system.
Using Yaksha for Key Escrow
T h e following p a r a g r a p h s describe how t h r e e very different key escrow p r o b l e m s can be solved using the s a m e
Yaksha i n f r a s t r u c t u r e . Because o u r goal is to illustrate the
concepts, we do not describe several details, some o f
which have significant security implications.
Telephony
O u r first e x a m p l e is t e l e p h o n y . Since in this m o d e l b o t h
parties a r e on-line at the s a m e time, the key e x c h a n g e
p r o t o c o l d e s c r i b e d previously can be used exactly as
stated. Alice indicates to the Yaksha server a desire for
secure c o m m u n i c a t i o n s with Bob. T h e Yaksha server distributes C,, to Alice a n d Cb to Bob, who each r e c o v e r k a n d
use it for e n c r y p t i n g the conversation. In practice, the
transaction would be t r a n s p a r e n t to the user, who might,
tor instance, simply pick up the p h o n e , dial *007 a n d t h e n
Bob's n u m b e r , a n d n e v e r notice a n y t h i n g else. T h e key
e x c h a n g e a n d o t h e r o p e r a t i o n s would be h a n d l e d as p a r t
o f call set-up, a n d the Yaksha s e r v e r would he j u s t o n e
m o r e o f the m a n y intelligent c o m p u t e r s now a t t a c h e d to
the p h o n e n e t w o r k to p r o v i d e special services.
$8
March 1996/Vol. gg, No. 3 ~ u ~ a r ~ N s
~
Tm acM
W h e n an a u t h o r i t y wishes to tap a p h o n e line, a r e q u e s t
R is signed a n d sent to the Yaksha server• I f it is d e s i r e d
that m u l t i p l e authorities m u s t c o o p e r a t e to tap a line, we
can r e q u i r e that R be s i g n e d by m u l t i p l e authorities. Observe that the authorities a r e themselves p a r t o f the Yaksha system. Each a u t h o r i t y has its own private key dAl, dA2,
. . . . a n d the Yaksha server keeps a c o r r e s p o n d i n g dAly,
dA2y . . . .
C o r r e s p o n d i n g public keys (eAt,IrA l), ( e A 2 , / ' / A 2 ) ,
• . . exist in t h e system. So it, for instance, certain types o f
taps r e q u i r e the signatures o f a u t h o r i t i e s A 1 a n d A2, the
r e q u e s t sent to the Yaksha s e r v e r can be o f the f o r m (R d~'
m o d nA 1)aA~ rood 7/.A2.T h e Yaksha s e r v e r can a u t h e n t i c a t e
a n d r e c o v e r the r e q u e s t using dA ly, dA2y. . . . a n d the corres p o n d i n g public keys (CAl,nAl), (eA2,nA2) • . . T h e r e q u e s t R
can take on several forms, so, for instance, it may o r d e r
the Yaksha s e r v e r to p r o v i d e session keys for all f u t u r e
conversations Alice carries out, o r it m a y ask for only certain types o f conversations. T h e key p o i n t to note is that
the d e s i g n p r o v i d e s t r e m e n d o u s flexibility, so a wide variety o f u n d e r l y i n g policies can be i m p l e m e n t e d . F u r t h e r ,
the policies can be c h a n g e d easily without h u g e c h a n g e s to
the system. F o r instance, if public policy were to c h a n g e to
r e q u i r i n g four c o o p e r a t i n g a u t h o r i t i e s instead o f two, o r if
the identities o f the a u t h o r i t i e s s h o u l d change, m i n o r
changes to the system p a r a m e t e r s achieve the goal. T h e
fact that c h a n g e s can be m a d e easily m a y n o t be o f g r e a t
theoretical interest, b u t as is often o b s e r v e d in practice, it
is on such m u n d a n e issues as ease o f ability to c h a n g e that
the security o f systems rests.
It is w o r t h o b s e r v i n g that a p a r t o f the system r e q u i r e s
Bob's t e l e p h o n e to r e c o v e r k f r o m Ct, in a fashion t h a t
e n s u r e s p r o o f that Cb was g e n e r a t e d by the Yaksha server.
T h i s observation m e a n s it is possible to p r e v e n t a d i s h o n est (trying to c h e a t the key escrow system) Alice from carr y i n g o u t a secure c o n v e r s a t i o n with an h o n e s t (playing by
the rules) Bob.
Email
We chose email as o u r next e x a m p l e b e c a u s e it has a fund a m e n t a l s t r u c t u r a l difference f r o m t h e p r e v i o u s e x a m p l e
in the r e q u i r e m e n t s , n a m e l y that the u n d e r l y i n g messaging is o f a s t o r e - a n d - f o r w a r d n a t u r e in which the s e n d e r
a n d receiver a r e not b o t h on-line at the s a m e time. C u r r e n t systems [6] for secure email a r e g e n e r a l l y b a s e d on
having t h e s e n d e r , say Alice, s e n d i n g the receiver, say
Bob, the following construct:
{E(M,k), k e~' m u d n~, S, Alice'sCertificate}
T h e c o n s t r u c t has f o u r pieces:
• T h e message M is e n c r y p t e d with a session key k g e n e r a t e d by Alice.
• T h e session key k is e n c r y p t e d with Bob's public key
eb,nb. O n receiving the message, Bob will use his p r i v a t e
key db to r e c o v e r this session key k a n d will then use k to
r e c o v e r 34 from E(M,k).
• Next, a hash, o r f i n g e r p r i n t , H(M), o f the message is
signed by Alice to g e n e r a t e h e r s i g n a t u r e S, t h a t is S =
(H(M)) (l" m u d ha. T h e hash of the message is used in lieu
o f the message itself for reasons, o f efficiency.
• Finally, Alice's certificate (which is simply h e r public
key, in t u r n signed by a universal a u t h o r i t y ) is enclosed.
Tho
Bob can retrieve Alice's public key from her certificate
a n d use it to verify h e r signature o n the hash.
I n k e e p i n g with o u r g e n e r a l policy of i n t e g r a t i n g Yaksha
with existing systems (see [4], where Yaksha is a d d e d to
Kerberos) as o p p o s e d to creating a fresh system from
scratch, we a t t e m p t to reuse these constructs to the e x t e n t
possible. We see the system w o r k i n g as fbllows:
• Alice sends the Yaksha server S1 = H(M) 4. a n d indicates that the i n t e n d e d recipient is Bob.
• T h e Yaksha server c o m p u t e s S = Sla'~~ m o d na a n d replies to Alice with the message S, kd,,Ce. m o d na, kd* x~',
m o d nt, T h e first p o r t i o n is simply the completed RSA
signature for Mice o n the message M. T h e second portion is decrypted by Mice using da~ to recover k. Alice
will use this k to e n c r y p t the message M, that is E(M,k).
T h e third p o r t i o n is sent o n to Bob by Alice without
modification.
• So the message Alice sends Bob is: {E(M,k),ka~~×~', m o d
½,S,Alice'sCertificate}. Except for the second field, this is
exactly equivalent to the construct Mice would have sent
Bob in a non-Yaksha system.
• W h e n Bob receives this message, he verifies Alice's sign a t u r e exactly as in a non-Yaksha system, b u t to recover
the session key k he uses dbb, that is k = (kdt~xet' mo d no)dl'l'
m o d rib.
Since the Yaksha server has the session key k, the actual
escrow process is identical to that described in the telephony example. Some a d d e d benefits to this system are that
it is now possible to make each user's private l o n g - t e r m
secret
dii a fairly short, memorizable password; see [4] for
m o r e details. F r o m the s t a n d p o i n t of message structure,
the new system is identical to the existing standards [10].
I n fact, it is worth observing that interoperability between
Yaksha a n d non-Yaksha systems is relatively easy. If Bob is
n o t a part of the system, his c o r r e s p o n d i n g Yaksha key dt~
is simply set to one. Bob will not notice the difference, a n d
the escrow will still work. We reiterate that we are glossing
over some details essential to secure functioning; for instance, the hash sent by Alice to the Yaksha server should
have some specific structure so that the Yaksha server can
authenticate Alice before r e s p o n d i n g .
Encrypted File Storage
As with c o m m u n i c a t i o n s , it is b e c o m i n g increasingly necessary to provide c o m p u t e r users with access to e n c r y p t e d
files or data storage, a n d escrow m e c h a n i s m s are needed.
I n addition to the usual reasons for a n authority to be able
to retrieve this data without the user's cooperation, m o r e
o r d i n a r y reasons, like access to a critical file in a co-worker's absence, also come into play. Using Yaksha to meet
this r e q u i r e m e n t is fairly straightforward; one can think of
countless variations. We describe o n e such possibility,
which assumes the existence of a file server process that is
a n entity i n d e p e n d e n t of the user. T h e system works as
follows:
• Alice sends the Yaksha server the n a m e of the e n c r y p t e d
file server F where she wants to store the file.
• T h e Yaksha server sends Mice a storage key k e n c r y p t e d
Ynkghn
Socui,
ity
with the Yaksha server's key for the file se
k d*~xeF m o d
II F .
• Alice sends the file server the file a n d th
storage key; note Alice does n o t know the . . . . . s~ ,,~y• T h e file server recovers the storage key using its own
private key dFr , encrypts the file with the storage key k,
a n d stores the e n c r y p t e d file E(File,k) a n d the e n c r y p t e d
storage key k d'~×e~ m o d n r.
• W h e n Alice wants the file, she simply sends it a signed
a n d time-stamped request Q, which she signs by interacting with the Yaksha server. T h e file server can verify
the signature o n the request, recover k from E l'~×'' m o d
nF, decrypt the file, a n d send it to Alice.
• W h e n a n authority wants a file, the authority interacts
with the Yaksha server a n d sends a duly signed request
R to the file server. T h e file server uses the public key(s)
of the authority(ies) to verify the signature o n the request, recover the session key, decrypt the file, a n d send
it to the authority.
T h e basic idea is that the file server will only e n c r y p t files
u s i n g a key it gets from Yaksha. It t h e n stores this key in
a n e n c o d e d form with the file itself. Note that in practice
such a system would have provisions for m u t u a l authentication a n d e n c r y p t e d c o m m u n i c a t i o n s between the users
a n d the file servers, a n d most likely would require a
signed hash of the file also be stored. All of these functions
can be achieved by r e u s i n g the Yaksha infrastructure.
Observe that we require the file server process to have a
l o n g - t e r m private secret key dFr , which it must keep in
persistent storage. We anticipate that in a practical system,
this key a n d the functions p e r f o r m e d with it will h a p p e n
inside the safe confines of a tamper-resistant chip. Using a
tamper-resistant chip is n o t particularly onerous, especially since we do n o t r e q u i r e the storage key for each file
to be stored inside the chip. Several variations on this
t h e m e are possible.
Conclusions
T h e Yaksha system requires the presence of an on-line
server. I n the c u r r e n t climate of cheap a n d ubiquitous
c o m m u n i c a t i o n s , this is (in almost all cases) not a problem.
I n telephony, for example, on-line servers that provide
intelligent services are already ubiquitous. Also consider
that today, most credit-card transactions result in access to
r e m o t e c o m p u t e r systems. T h u s , a s s u m i n g the existence
of a n on-line service seems to be reasonable; we also ass u m e that the Yaksha server itself will be m a i n t a i n e d in a
secure fashion. We expect the use of tamper-resistant
chips to play a significant role here. For instance, we expect that the Yaksha server's portions of user keys div will
be e n c r y p t e d u s i n g some sort of master key, which veould
itself always be stored inside a tamper-resistant chip, a n d
that all the functions p e r f o r m e d will h a p p e n inside this
chip. Given that today's technology allows for systems
where every user has a tamper-resistant chip, we do not
believe it is too o n e r o u s for a few servers to have such
chips.
T h e question t h e n arises: Can colluding cheaters defeat
the Yaksha key escrow system? T h e answer is yes; we do
n o t know of any key escrow system that d e t e r m i n e d colCOMMUNICATION| ~
THE ACM March 1996/Vol.39, No. 3
$9
CALL FOR PAPERS
N
Third IEEE International'Symposium on
Requirements Engineering
J a n u a r y 5-8, 1997 * Annapolis, Maryland, USA
The ! 997 symposium will be held in four exquisite 18th-century
inns clustered in the beautiful colonial seaport of Annapolis on
the scenic shores of Chesapeake Bay. It will bring together
researchers and practitioners for an exchange of ideas and
experiences, The program will consist of invited talks, paper
presentations, panels, tutorials, working groups, demonstrations,
and a doctoral consortium. The program will also include a
parallel industrial track with presentations on industry problems
and experiences, transferable technology, and commercial tools.
Papers describing original research in requirements engineering
are invited. Symposium organizers extend a special invitation for
paper submission and participation to researchers and practitioners working in high assuranee, safety-critical and missioncritical systems, and formal approaches to requirements.
Authors should submit six (6) copies of each full paper (no
email or FAX) to the Program Chair. Papers must not exceed
6000 words and must be accompanied by full contact information including name, address, email address, and telephone and
FAX numbers. Authors should also submit the title, abstract, and
classifications of each paper by email to the Program Chair a
month before the paper is due along with full contact information. All papers must be classified according to the symposium
classification scheme. For a full call for papers, including the
classification scheme, contact the Program Chair, use anonymous
FTP from cs.toronto.edu (/dist/ISRE97/CFP), or see the WWW
page at http://www.itd,nrl.navy.mil/conf/lSRE97. Developers or
researchers wishing to present in the industrial track should
submit an abstract to the Industrial Chair. Students interested in
presenting at the doctoral consortium should send an extended
abstract to the Doctoral Consortium Chair by Sept. 15, 1996.
IMPORTANT
April 1, 1996:
May 1, 1996:
July 1, 1996:
September 1,
DATES:
Title, abstract, and classifications due
Full papers, industry abstracts due
Notification of acceptance
1996: Camera-ready copy due
FOR MORE INFORMATION, CONTACT:
Connie Heitmeyer, General Chair
Code 5546, Naval Research Lab, Wash., DC 20375
(202) 767-3596; heitmeyer@itd.nrl.navy.mil
John Mylopoulos, Program Chair
Dept. Computer Sci., Univ. of Toronto, 6 King's College
Rd., Rm 283, Toronto, Ontario Canada M5S 3H5
(416) 978-5180; fax (416) 978-1455
jm @ cs.toronto.edu
Stuart Faulk, Industrial Chair
Kaman Sciences; (202) 404-6292
faulk@itd.nrl.navy.mil
Myla Archer, Doctoral Consortium Chair
Naval Research Lab; (202) 404-6304
archer @itd.nrl.navy.mil
Sponsored by
~
1"-,lIEEE
L,,OMPUTER
SOCIETY
~0YEARS OF SERVICE * 1 9 ~ 6-1 9 9 6
4 ~
IEI~E
l u d i n g cheaters c a n n o t defeat. T h e i n t e n t here, as in similar systems, is to m a k e it difficult to cheat. We believe this
issue is probably a dd r e ssab l e at the level o f d e t e c t i n g
c h e a t i n g a nd d e n y i n g service to cheaters. T h i s is practical
in m a n y situations, a l t h o u g h an e x p l a n a t i o n o f the techniques is b e y o n d the scope o f this article.
T h e system we describe can be used f or m a n y d i f f e r e n t
p r o b l e m d o m a i n s , such as secure transmission o f movies
o r software b e t w e e n i n f o r m a t i o n p r o v i d e r s an d set-top
boxes in users' homes. T h e key p o i n t in o u r m i n d is that
the Yaksha system is a single versatile security infrastructure that can be r e u s e d for m y r i a d security functions.
While n o t e m p h a s i z e d today, the security in f ra s tr uc ture s
that will thrive in the f u t u r e will h a v e the attribute o f
b e i n g reusable.
Finally, we reiterate that flexibility is the single most
i m p o r t a n t factor in a key escrow system. Successful key
escrow systems r e p r e s e n t a c o m p r o m i s e b e t w e e n an individual's rights a nd an a u t h o r i t y ' s right to know. T h e Yaksha system p r o v i d e s a flexible alternative that can be
a d a p t e d to m a n y situations.
Acknowledgment
I w o u l d like to t ha nk D o r o t h y D e n n i n g for h a n d l i n g this
article for this special section a n d for h e r c o n t i n u i n g interest in this work.
References
1. Boyd, C. Digital Multisignatures, Cryptographyand Coding. Clarendon Press, Oxford, 1989. H.J. Beker and F.C. Piper, Eds.
2. Denning, D. To tap or not to tap. Commun. ACM 36, 3 (Mar.
1993).
3. Denning, D., and Branstad, D. A taxonomy for key-escrow
encryption systems. Connmun. ACM 39, 3 (Mar. 1996).
4. Ganesan, R. Yaksha: Augmenting Kerberos with public-key
cryptography. In Proceedings of the Internet Society Symposium
on Network and Distributed Systems Security, (Feb.) 1995.
5. Ganesan, R., and Yacobi, Y. A secure joint signature and key
exchange system. Bellcore TM-24531, Oct. 1994.
6. Kent, S. Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate Based Key Management, Internet RFC
1422, Feb. 1993.
7. Needham, R.M., and Schroeder, M.D. Using encryption for
authentication in large networks of computers. Commun.
ACM 21, I2 (Dec. 1978).
8. Neuman, B.C., and Ts'o, T. Kerberos: An authentication service for computer networks. IEEE Commun. (Sept. 1994).
9. Rivest, R., Shamir, A., and Adelman, L. On digital signatures
and public-key cryptography. Commun. ACM 27, 7 (July
1978).
10. Schneier, B. Applied Cuptography: Protocols, Algorithms and
Source Code in C. Wiley, New York, 1994.
About the Author:
RAVI GANESAN is Vice President for Information Technology
at Bell Atlantic and is with The Johns Hopkins University. Author's Present Address: Bell Atlantic, 1320 North Courthouse
Road, Arlington, VA 22304; email: ravi.ganesan@bell-atl.com
IEEE ComputerSocietyTC on Software Engineering
In cooperation with
ACM SIGSOFT,IFIPWG 2.9 (SoftwareRequirements)
6Q
March1996/Vo1.39,No. 3 C O M M , U l a ~ . A 1 t l O l ~
¢HUM
~M
©ACM 0002-0782/96/0300 $3.50