1 Introduction:
The Multi-Agent Model
Mobile
agents (MAs) are an approach to distributed computing employing the mobile code
concept. An MA is an autonomous entity, which is composed of code, data and
state information. They visit hosts (e.g., servers) possibly using an
itinerary, perform some execution on those hosts using their codes and migrate
with their state information from host to host. They act on behalf of their
owners (i.e., senders). They are autonomous in the sense that they have all the
knowledge needed to perform the assigned task on behalf of their owners. There
are several application areas of MA systems (e.g., e-commerce and network
management). Despite the benefits of MA paradigm such as being able to operate
in disconnected mode in mobile computing and localized computation, which is
realized by moving the code to data in contrast to the opposite in distributed
client/server computing, there are two critical issues in the MA paradigm:
security and interoperability among different MA systems. The security issue we
address here is the problem of protecting
MAs against malicious hosts.
In
the classical MA model, a single MA performs a
single task, which we call a mission.
The term mission is the counterpart of the term session in client/server computing. A mission can represent any
session that carries out a computation such as a database search, a network
management activity or an e-commerce task, etc., using MAs. Figure 1.1 (a)
illustrates the single agent model by showing a mission being carried out by an
MA called Alice. The mission must be accomplished by visiting several hosts,
which requires process migration from host to host. Alice computes (e.g., is
being executed) in these hosts and returns home at the end of a successful
mission in this case. Note that the illustration in Figure 1.1 (a) is a
simplified generic case of a mission. It may not be necessary for an MA to
return home and a same host might be visited multiple times in the same
mission.
One
of the open research issues in this single MA architecture model is the ability
of computing with secrets in the public domain. In our recent work [1] on the
design of an architecture for Mobile Agent Collaboration and Execution Support
(MACES) system, we address this security issue as well as the problem of
interoperability. In this architecture, we presented a multi-agent model for MAs.
The multi-agent paradigm fits well with the concept of protection of an application as a whole. It is more difficult to
compromise a task if the task is split into multiple collaborating agents. In
the context of data secrecy, this is also referred to as information dispersal for security, which has been widely studied.
The new definition of MA autonomy takes the form: “A group of agents is called
‘autonomous’ if they have the knowledge necessary to perform a single task, and
they communicate and cooperate to perform that well-defined single task during
a mission.”
Figure
1.1 (b) illustrates the model using the agents Alice, Bob, and Carol executing
on three hosts A, B, and C respectively. In the model, we call one of the
agents the master agent (distinguished
by double circles in the figure), who actually visits the set of hosts that are
necessary to complete the mission. This set of hosts is called the itinerary of
the mission. The other agents are called support
agents, who visit only the hosts outside of the itinerary of the master
agent. Note that, the model that we describe here is the most generic
multi-agent model. Variations of the model admit more than one master agent.
In
Figure 1.1 (b), observe that these three hosts A, B, and C reside in three
different network domains, A, B, and C respectively, which are shown as dashed
ovals.
Note
that the figure shows a snapshot of the agents at a specific time, therefore
migration of the autonomous group of agents is not shown. In fact, the
migration of an agent or agents in a group is more complicated in this model
and requires support from an underlying system that is aware of the underlying
network topology. The details of this MACES [1] system, such as determining the
path of a single agent of a group or realizing the domain boundaries of the
hosts involved in a mission, are outside the scope of this paper and are under
active research. For now, we assume the existence of such a system.
Although
the MA paradigm opens many interesting applications, to validate it as an
alternative to traditional client/server computing, one must address its
security issues. In particular, it should demonstrate the ability to compute
with secrets in remote public domains.
A good example of the need for this is digitally signing a contract for
e-commerce applications with MAs as shown in the paper by Sanders and Tschudin
[2]. We call this problem remote digital
signing. This paper proposes a multi-agent architecture and a solution to
this problem. The techniques we explore and analyze are based on information
dispersal in distributed system security terms as well as multisignatures and
secret splitting in cryptographic terms. The idea is to devise a secure way of
sharing secret keys among members of a multi-agent group and signing with
shares for easy verification.
In
the next section we summarize the remote digital signing problem along with the
related work that addresses the problem. In Section 3, we present background
information on multiple cryptography, on which the proposed solution for remote
digital signing is based. Sections 4 present the secret splitting schemes using
RSA and El Gamal cryptosystems, which can be employed by MAs using the
multi-agent model. Section 5 presents a complete example of signing and verification
of a document, employing the techniques given in Section 4. Section 6 presents
the utilization of key certificates and introduces the limited-liability key
concept for further protection of MA users’ long-term keys. Section 7 concludes
the paper.
2 Related Work
Sander
and Tschudin introduced the concept of Mobile Cryptography in 1998 [2]. The
idea is to encrypt agents as a whole and apply computing with encrypted
functions and data. Although it is limited to polynomial and rational
functions, this is a good example of a software solution to the MA security
problem that is based solely on cryptography. In the same paper they also
introduced the concept of “undetachable digital signatures.” They point out
that this is a possible realization of
“… an agent would like to use the secret in public e.g., to compute the
digital signature of an order form but without disclosing the secret needed to
do so.” They provide a solution using rational functions. They also point out
that the scheme on which their proposal is based has been successfully
attacked.
Kotzanikolaou
et al. proposed a solution [3] to the problem introduced by Sander and
Tschudin. They use RSA [4], which is based on exponential functions rather than
rational functions. However, as the term “undetachable digital signatures”
implies, the solution given in [3] requires that the signature be generated by
the user (i.e., owner of the agent) and given to the agent before the mission takes place. This contradicts MA autonomy. This
is due to the fact that the purchase decision has to be made strictly before
negotiation with the sellers. User constraints, which have to be signed before
these negotiations, therefore need to be pure
data. However, it is desirable that a decision function be executed after or
during the negotiation or bargaining process. This means that agents should be
capable of deciding what to buy, where to buy, under what conditions, price,
type of payment, delivery options, etc. For example, the user demand should be
able to be stated as flexibly as possible with “I would like to purchase as
many blank rewritable CDs as possible and I’ve got $100.” The result of the
decision function will have a direct effect of the contract to be signed.
Therefore what we need is to make the agents capable of computing with secrets
in public as the quoted sentence in the previous paragraph implies. Without
this capability, either the user must have a perfect knowledge of market
conditions that might change rapidly, or user interaction during the mission is
necessary. In the former case it is highly possible that the mission may fail,
in the latter, autonomy is sacrificed. The problem arises from the fact that a
malicious host should not be able to manipulate or directly use the agent in
order to sign “arbitrary” documents. On the other hand, agents should also be
capable of preparing the documents to be signed. The challenge is to resolve
this contradiction.
3 Multiple Cryptography
Multiple
cryptography, as the name implies, covers the cryptosystems that deal with more
than two parties as opposed to the classical cryptography where there are only
two parties: the one who encrypts or signs and the other who decrypts or
verifies. In fact, there are many real-world applications that have multiple parties
involved. For example, in a banking application, electronic fund transfers
require approvals of bank officials of different ranks. Usually, at least two
people are involved for a single transaction.
Our
focus in this paper is on multiple digital signatures or multisignatures, which is a special case
of multiple cryptography. Boyd, in [5] shows the generalization of RSA
and use it as a multisignature scheme. A brief explanation of Boyd’s work,
which is related to our application is given in Section 4.
Multiple
cryptography, in general, is intended for classical applications (e.g., a
banking application). In these applications, shareholders are usually
individuals who represent an organization or a company. There is an important
distinction between these applications and the MA applications. MAs are nothing
but software entities. They are neither organizations nor individuals.
Moreover, they are owned by individuals or organizations. In fact, it can be
argued that, the MA owner and a bank have some kind of resemblance. So, the
officials of the bank and the MA perform similar operations when signing a
document. While this is not wrong, the actual difference comes from the fact
that, MA owners are active players, while organizations or companies like a bank
are not. A bank is actually an abstraction and cannot for example sign a
document. But in the case of a human MA owner, this individual can equally sign
documents him/herself. Also, the shareholders do not always exist. They are
created when necessary and after they complete their work they cease to exist.
In addition to the threshold schemes like Shamir’s [6], techniques
which are known as threshold cryptography
for the purpose of not only sharing keys but also being able to
compute with them without a central authority, have been proposed. A threshold
multisignature scheme, for example, has been given by Frankel and Desmedt [7].
Nevertheless, threshold schemes do not have specific advantages over simple
secret splitting techniques we are using, with MAs. While it is feasible to use
these secret splitting schemes to both share the keys and compute with them, it
is also feasible to come up with very simple techniques to create multiple
combinations of keys for providing fault-tolerance. On the other hand, in our
application, secret splitting has two important advantages: simplicity and
ubiquity. We use very simple
secret splitting schemes, which use only addition and multiplication. The
secret splitting schemes we use require nothing but the implementations of the
standard public key cryptosystems, namely, de facto industry standard RSA and
the official Digital Signature Standard (DSS), which is based on El Gamal
public key scheme. So, these schemes do not need any new algorithms or an
implementation of those algorithms. It should also be noted that what makes it
possible to use these simple secret splitting schemes with the El Gamal
cryptosystem and DSS is the unique property of the application that the whole
secrets and all of the shares are to be computed and known by the MA owner;
therefore it is possible to perform computations in advance to be used later
when the complete signature is computed. Details of these computations are
given in Section 5.
4 Key Splitting and Signature Generation
Boyd, by using the multiplicative property of RSA, showed that the
classical RSA is actually a specialization of a general multisignature scheme
[5]. For an RSA implementation for sequential signing, we will use this
property. Boyd, in [8] also mentions about a similar technique, which enables
to perform signature generation in parallel. This is the RSA part of the
techniques we will use in parallel signing. Note that, both techniques use
nothing but original RSA signing and verification algorithms. In the following
subsections we present techniques to do the same with El Gamal Cryptosystem,
which again use original signing and verification procedures, by using a
property that is unique to MAs, as explained.
4.1
Using El Gamal Public Key Cryptosystem
Here
we use a variant of the original El Gamal signature scheme as given in Kaufman
et al [9]. There are two reasons to do this. First is, this scheme is simpler
and it is easy to compute with partial keys. The other reason is that, the
scheme is actually the El Gamal version used in DSS, which in turn is based on
the original idea introduced by El Gamal [10]. So this scheme will enable us an
easy transition from El Gamal to DSS, which has been published as a standard.
The transition is given in Section 4.1.3. The El Gamal variant that we use is
summarized below [9]:
·
Long term
public key: <g, p, T>, secret key: S, where gS
mod p = T
·
For a
message m choose random number Sm compute 
, and message digest dm (digest of m | Tm)
·
Sign
with X = Sm + dm S mod (p
– 1),
·
Verify
by 
4.1.1 Signing in Sequence with El Gamal Signature
Scheme
The
El Gamal cryptosystem uses a pair of private keys as opposed to RSA’s single
key. The first one is the long term key as in the RSA. The second is a
short-term, per session, private key for each message to be signed with the
long-term key. We split up both of these keys as follows:
Long-term
key: 
Short-term
key:
.
Here
we assume again that our MA group consists of three agents, namely, Alice, Bob
and Carol. Alice is the master and the others are support agents.
To sign a
message, Alice computes the message digest 
and signs with
Then,
she sends her partial signature to Bob. Bob, upon receiving Alice’s signature 
, further signs it with his portions of partial
keys as
Carol does
the same on 
, which represent the partial signature generated by Alice
and Bob,
Unfortunately,
this last equation above, unlike the RSA counterpart, is not equal to the
signature X, although the last term
of the equation is nothing but the last term of the original signing equation:
.
This
leads us to the observation that the difference between the target signature X
and the signature generated by the three agents Xc is
Since
the right hand side of the equation consists only of constants and partial private keys, it can easily be
computed and given to agents before the agents are sent out to the network.
This ability is unique to the
application that we consider in this paper. In the classical applications of
digital multisignatures and threshold signatures, it is not possible to perform
the same computation since the signatories are distinct parties and the secrets
they share cannot exist in a single site as a whole. So the last agent in the
row, Carol, sends the partial signature Xc
to Alice. Alice computes X, the
target complete signature by using the equation above. The general difference
equation for n signatories (e.g., agents) is
4.1.2 Signing in Parallel with El Gamal Signature
Scheme
Signing
in parallel with the same variant of El Gamal cryptosystem is also possible and
even easier. For this purpose we split up the keys as follows:
Long-term
key: 
Short-term
key: 
Then,
each agent is given the partial keys. They sign independently of each other as
and
the support agents send their partial signatures to the master agent. Together
with the master agent’s signature, the server combines the partial signatures
and obtains the complete signature as follows
The
scheme can be generalized to n
signatories in the obvious way.
4.1.3 Transition from El Gamal Cryptosystem to
Digital Signature Standard
Due
to space considerations, we will neither provide the details of DSS nor the details
of the signature generation by partial keys. However, we will give the
differences between the El Gamal scheme presented in previous sections and DSS.
The signing
equation in DSS is given by
where
is the multiplicative
inverse of 
. Therefore it can be calculated in advance and instead of
splitting up 
we can just as easily split up 
.
Signing in Sequence with DSS
The key
splitting is performed as follows:
Long-term
key: 
Short-term
key (inverse):
.
The
signing process is very similar to El Gamal as in Section 5.2. However the
difference in this case is given by
For n signatories
(i.e., agents), the general difference equation is
The difference from Section 4.1.1 here is mainly the term 
, which is the per session public key.
Signing in Parallel with DSS
The
key splitting, signing and signature combination calculations here are very
similar to those in Section 4.1.2. However, the combined value is not equal to
the target complete signature X.
Therefore we call this value X’ and
the difference is given by
For
n signatories (i.e., agents), the
general difference equation is
5
The Overall System for Remote Digital Signing
As seen in section 4, there are two
major multi-signature schemes: sequential and parallel. Figures 5.1 and 5.2
provide the overall system of signing and verification processes as part of an
MA mission, for sequential and parallel signature generation schemes,
respectively. In this section, we discuss these protocols, compare them with
respect to assumptions made and the analysis of attacks possible against each
scheme.
Please
note that, in this paper we do not address fully the overall security issues
necessary for a whole MA mission. Signature generation is actually an integral
part of the whole mission. However we provide the protection mechanisms when
necessary in addition to the signature generation process to make this process
more meaningful.
In
both of the protocols, the first part is to obtain the bid of the server along
with the signature for this offer and then verify this signature in steps 1
through 4. After Alice obtains server’s signature, she sends it to both Bob and
Carol. Signature verification is carried out by both Bob and Carol
independently on different hosts in different domains. It would not make sense
to let Alice verify the signature since Alice is under complete control of the
very same host that made the offer.
Step
5 in Figure 5.1 contains the contract preparation process done by Bob. The
protocol assumes that Host B does not have any interest in forging the
computation as does Host A. Although the chances are low, this assumption is
not enough for a convincing level of security, since a denial-of-service attack
by Host B is possible. This is due to the drawback of this protocol that there
is no way to check whether the contract signed by the first agent in the row is
correct. This is true regardless of the fact that the decision function is
executed in cooperation with all the members of the group. However, this
drawback does not make the protocol totally inappropriate because even an
attack cannot be prevented, it would be detected in Step 11 when the host
attempts to verify the signature. Nevertheless, it is not possible to tell
which host is cheating. The parallel signature generation scheme does not have
this drawback as we see next.
In
Figure 5.2, Step 5 states that all agents prepare the contract to be signed.
This is possible since Bob and Carol receive the server’s offer from Alice.
Furthermore, any decision function that needs to be executed to reach the
decision for actual purchase is shared by three agents and executed in
cooperation. However, it is also possible for any one agent to prepare the
contract and communicate it to the others. Once the contract is obtained either
way, agents sign it with their shares of the private key for the chosen
algorithm as described in section 4. Step 6 says that Bob and Carol send their
signatures back to Alice, and in Step 7, Alice combines them to obtain the
fully signed contract. This means that combining the partial signatures takes
place in the host where Alice resides. This is because there is no trusted
authority to ask for this computation. But for the application under
consideration, there is no need for it, either, since there is no known attack
possible.
6 Using Limited-liability Keys and Public Key
Certificates
Our
multi-agent model provides a high level of security by making it difficult to
compromise all the agents, which together form an autonomous group. However,
the
secret, which is a private key of the agent owner, is an extremely sensitive
piece of information. Revealing user’s shopping preferences or losing
electronic cash is certainly undesirable, but in essence a part of our daily
lives since we have just enough security to protect these valuables. It is
always possible that these could be lost or stolen. But a forged signature
under a document may mean “anything” and may not be tolerable or acceptable. So
even a very small chance of the whole group of agents being compromised may not
be acceptable since the consequence of this malicious action is revealing the
private key of the user. Therefore we define two types of public/private key
pairs as follows.
Long-term public/private
key pairs: These are the
long-term keys, which are created, registered and assigned to the user (who
becomes the owner of the keys) by a Certificate Authority (CA). The lifetime of
these keys are again decided by the same authority.
Limited-liability
public/private key pairs:
These are the short-term keys, which are created by the very same user (owner
of the keys). Since the creators of the keys are the users themselves they also
are the authority to decide the lifetime of the keys.
There are two limitations that can
be imposed on the limited-liability keys. The first one is the lifetime of the
key and the second one is what can be done (i.e., signed) with these keys. Both
of these limitations can be flexible or restrictive and is up to the owner of
the keys. For example, the lifetime of a key may vary from a single MA mission,
which may be limited to a couple of minutes, to a total of a couple of days
that spans several different missions. Liability definition says what exactly
can be signed with these keys. For example, a typical definition may say that
these keys can only be used in an e-commerce transaction and the amount that
could be involved in such a transaction cannot exceed $500. The other type of
limitation that can be imposed is the type of the transaction. For example, it can
be stated that, with these keys only one mobile phone, one color printer or one
DVD player purchase contract can be signed.
The
problem with this scheme is the authenticity of this new pair of keys. One
possible solution would be to register this pair of new keys with a CA and
obtain a certificate, or ask the CA directly for a pair of new keys.
Nevertheless, this solution does not make much sense, since this introduces an
overhead of obtaining a new key for every single transaction from a CA, which could
easily become unmanageable. Instead, the user creates this key and a
certificate for this key by using his/her long-term key. The idea is that the
user obtains only a single public key and a certificate for it from a CA. Using
this certificate and public key, it is possible for the very same user to
create and use unlimited number of other public keys. The key point here is
that these new keys are certified by their owners. That is, the user in essence
becomes a CA for the agents he/she sends on missions.
It
may seem at first that the scheme explained in this section provides enough
security for the limited-liability private key. This is due to the fact that
what can be signed by this key is restricted by the certificate provided for
it. However, it is not so for two reasons. First problem is the same problem
that the undetachable signature schemes have as explained in section 2, which
is the difference between the limitation of what can be signed and what
actually is signed. The second problem is that an attack is possible by any
host visited. Any such host for example might learn the complete
limited-liability private key from agent Alice, and then can sign a contract to
sell something. Also, even if the support agents are involved in the decision
function to be executed, this is not enough since the single agent who
possesses the complete key could be manipulated. The long and the short of it
is that this scheme when used alone could open a can of worms. Therefore, the
limited-liability keys are protected by splitting them up and giving them to
members of a group of MAs. Their usage, on the other hand, is protected by the
certificate created by the user using the long-term key.
The
complete protocol for using the certificates and limited-liability keys for
agents is given in Figure 6.1. In the protocol, P and S represent the
long-term public and private keys respectively and p and s represent the
limited-liability keys. The protocol assumes that user already has P and S. Note that P, S, p
and s, are symbols for the private
and public keys, for example in the case
of
RSA, P and p indicate (E, N) and (e, n) respectively. The
certificate contains p and the
description of the liability. Any document, which is signed with s and therefore can be verified by p, should conform to this description to
be valid.
Note
that a certificate chain that would also include CA's certificate for (P, S)
rules out the necessity for the server to connect the CA and ask for
verification.
Now
let’s look at what can and cannot be accomplished with these limited time and
liability keys and what can go wrong. The analysis involves three parties that
can act maliciously; agent owner, the host to which a signature is provided,
and third parties, which could presumably acquire the limited-liability private
key. Since the private/public key pair is arbitrary, meaning that they are
neither created nor registered by a CA, the host on which the transaction took
place may sign a contract that states that the agent purchased 500 mobile phones
for the price of $100 each. Since the host also knows the credit card
information of the user, it can perform a transaction and bill the user’s
credit card for this transaction. The solution to the dispute requires the
proof of the user’s demand for this kind of purchase. But the certificate which
is signed by user’s long-term private key pair states that the transaction
amount may not exceed $500 and it is only valid for a purchase of a single
mobile phone. Therefore there is no way for the host to prove such claim.
Now,
suppose that a third party was able to compromise all the agents in a group and
therefore acquire the limited-liability key. Then this party could sign an
arbitrary contract on behalf of the user by masquerading as the user. In this case,
however, it is not possible to bind the user to this contract since there is no
certificate signed by the user using the long-term private key. So, such signed
document is invalid because the user can deny it rightfully.
Third
attack involves a malicious user, and is known as non-repudiation problem. The
user cannot deny a contract that states a purchase demand that conforms what is
stated in the certificate signed by the user’s long-term private key. This is
what we expect since this is the aim of the certificate and is completely
legitimate. Also, the user cannot deny the legitimacy of a contract by claiming
that the contract was signed after the limited-liability key had been expired.
That is because agents are supposed to check whether the expiration date and
time has passed. On the other hand, as
explained in the previous paragraph, the user can deny any illegitimate
contract signed by the limited-liability key that does not conform to the
certificate. Similarly, the user can use the limited-liability key to sign a
document that does not conform to the definition of the liability and then deny
its correctness. But, because this key is not registered by any central
authority, it is not possible to present a CA certificate for this key. So, it
is the responsibility of the party to check the legitimacy of the key by either
asking for a CA certificate or directly checking the legitimacy of the key by
asking the CA.
7 Conclusion
This
paper carefully examines the implementation of remote digital signing, which is
a special case of computing with secrets in the public domain, within a larger
picture of supporting multi-agent computing. The solution approach is based on
secret sharing and the concept of protection as a whole. In addition to well-known multiplicative and additive
properties of the RSA, similar techniques with El Gamal public-key
cryptosystem are demonstrated to show their applicability in the MA
systems. Although
threshold multisignature schemes fit well into the application, it may not be
feasible and even reasonable to provide the implementations of these schemes to
the MAs. Moreover, the advantage of the
techniques we presented in this paper is that they use nothing but original
signing and verification algorithms of RSA and DSS, which are well known and
widely used. In this sense, these simple schemes address the ubiquity in a
large scale MA execution environment like the Internet.
The
MA security problem is not limited to signature generation, however. In fact,
signing a document is supposed to be a part of an MA mission. A complete
solution to the problem of protection against malicious hosts is still to be
addressed in our future work. The novel ideas to secure the execution of agents
using a multi-agent model were presented previously [1]. However, as we have
presented in this paper, even the most challenging part of the problem,
computing with secrets by MAs, is feasible using the multi-agent model.
It
is shown that both parallel and sequential signature generation schemes are possible.
There are important properties of each scheme. The former one provides data
integrity since each agent in the group signs the original document, therefore
can check its integrity. However, in this scheme there is no confidentiality
for the document to be signed. The latter scheme provides data confidentiality
only if signing process begins at the server, where the master agent is being
executed. The other hosts, where the support agents are running, can not see
the document in clear, assuming the partially signed documents have enough
strength against cryptanalysis. The schemes presented in this paper address
authenticity rather than data confidentiality.
References
1.
Onbilger, O.K., Newman, R., Chow, R., “A
Distributed and Compromise-tolerant Mobile Agent Protection Scheme,” In
Proceedings of International Conference
on Intelligent Agents, Web Technologies and Internet Commerce – IAWTIC 2001,
pp. 394-400.
2.
Sander, T., Tschudin, C.F., “Protecting mobile
agents against malicious hosts,” Mobile
Agents and Security, LNCS 1419, pp. 44-60, 1998.
3.
Kotzanikolaou, P., Burmester, M.,
Chrissikopoulos, V., “Secure Transactions with Agents in Hostile Environments,”
LNCS 1841, pp.289-297, Springer 2000.
4.
Rivest, R.L., Shamir, A., Adleman, L., “A Method
for Obtaining Digital Signatures and Public-Key Cryptosystems,” Communications of the ACM, v.21, n.2, pp.
120-126, 1978.
5.
Boyd, C., “Some Applications of Multiple Key
Ciphers,” LNCS 330, Advances in
Cryptology, EUROCRYPT’88 Proceedings, 1988.
6.
Shamir, A., “How to Share a Secret,” Communications of the ACM, v.22, n.11, November 1979.
7.
Frankel, Y., Desmedt, Y.G., “Parallel Reliable
Threshold Multisignature,” Tech. Report: Department of E.E. and C.S. University
of Wisconsin-Milwaukee, TR-92-04-02, April 1992.
8.
Boyd, C., “Digital Multisignatures,” Cryptography and Coding, pp. 241-246,
1989.
9.
Kaufman, C., Perlman, R., Speciner, M., Network
Security, (Prentice Hall, 1995).
10. El
Gamal, T., “A Public Key Cryptosystem and a Signature Scheme Based on Discrete
Logarithms,” IEEE Transactions on
Information Theory, Vol. IT-31, No. 4, July 1985.