<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>On a Concept of Scalable Security: PKI-based Model using Additional Cryptographic Modules</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Bogdan Księżopolski</string-name>
          <email>bogdan@kft.umcs.lublin.pl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Zbigniew Kotulski</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Faculty of mathematics, physics and computer science, M. Curie-Skłodowska University</institution>
          ,
          <addr-line>Pl. M. Curie-Skłodowskiej 1, 20-031 Lublin</addr-line>
          ,
          <country country="PL">Poland</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Institute of Fundamental Technological Research of PAS</institution>
          ,
          <addr-line>Świętokrzyska 21, 00-049 Warsaw</addr-line>
          ,
          <institution>Poland and Institute of Telecommunications of WUT Nowowiejska 15/19</institution>
          ,
          <addr-line>00-665 Warsaw</addr-line>
          ,
          <country country="PL">Poland</country>
        </aff>
      </contrib-group>
      <fpage>221</fpage>
      <lpage>232</lpage>
      <abstract>
        <p>Public services called „e-anything” (e-government, e-banking, ecommerce, etc.) meet many different barriers, which reduce their efficient applicability. One of them is requirement of assurance of the information security when it is transmitted, transformed, and stored in the electronic service. It is possible to provide an appropriate level of security applying the present-day information technology. However, the level of the protection of information is often much higher than it is necessary to meet potential threats. Since the level of security strongly affects the performance of whole system, the excessive protection decreases the system's reliability and availability and, as a result, its global security. In this paper we present a model of scalable security for digital information transmission systems (being usually the crucial part of e-service). In our model the basic element of the security is the Public Key Infrastructure (PKI) enriched by specific cryptographic modules.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Advanced teleinformatic technologies nowadays provide a wide range of possibilities
of development of industry or institutions of public services. The high stress is put on
the development of well-available information services called “e-anything”, like
egovernment, e-money, and e-banking. These mentioned processes are fulfilled mainly
in an electronic way, thanks to which one can increase their availability, cutting down
the expenses at the same time.</p>
      <p>
        Implementation of these services is connected with the choice of a proper level of
security of information sent between parties of protocols [
        <xref ref-type="bibr" rid="ref12 ref14 ref16">12, 14, 16</xref>
        ]. Among
teleinformatic technologies and cryptographic modules there are such, which assure
different information security services e.g.: confidentiality, integrity, non-repudiation, and
anonymity of data. The important problem seems to be the establishing an appropriate
the level of information security fulfilled by services in a given protocol. Every use of
any Internet service is connected with information exchange, which in the case of
successful attack causes different threats to the whole process. This problem can be
solved by estimating the security levels for each phase of the protocol [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Such an
approach seems to be only a partial solution, because using a given specific service
one can send information of different level of threats. A common practice is to use
exaggerated means to ensure information security, which decreases efficiency, system
availability and introduces redundancy. Another effect of exaggeration of security
mechanisms is increasing the system complexity, which later influences
implementation of a given project in practice, imposing restrictions that decrease their
functionality.
      </p>
      <p>The adequate solution such a case seems to be the introduction of scalable security
model for the protocols, which can change security level depending on particular
conditions that take place at a moment and in a given external conditions. In the paper
we present a mechanism, which can modify the level of information security for each
phase of protocol. The parameters, which influence modification of the security level,
are: the risk of a successful attack, probability of a successful attack and
independence of the security elements. The used security elements, which take care of the
protection of information, are based mainly on PKI services and cryptographic
modules.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Security services and supporting elements</title>
      <p>
        In practice, realization of the electronic processes is connected with fulfilment of a
number of legal and technical standards. While projecting the systems, we can take
care of different security services [
        <xref ref-type="bibr" rid="ref1 ref2">1, 2</xref>
        ]. Among them we can enumerate:
confidentiality of data, integrity of data, anonymity of the parties of protocols, non-repudiation
of a sender and/or a receiver, authorization, secure data storage, management of
privileges, public trust, and network and protocol/service accountability. Every security
service has its own characteristics. A systematic presentation of the security services
is given in Table 1.
      </p>
      <sec id="sec-2-1">
        <title>Characteristics</title>
        <p>Prevention against improper
information modification or destruction
Non-repudiation of sending a
message (the fact of communication)
Non-repudiation of sender’s identity
and the fact of sending a message by
the sender
Non-repudiation of receiver’s identity
and the fact of receiving a message by
the receiver
Guarantee of only authorized
infor</p>
      </sec>
      <sec id="sec-2-2">
        <title>Authorization</title>
      </sec>
      <sec id="sec-2-3">
        <title>Privileges</title>
      </sec>
      <sec id="sec-2-4">
        <title>Anonymity</title>
      </sec>
      <sec id="sec-2-5">
        <title>Availability</title>
      </sec>
      <sec id="sec-2-6">
        <title>Public trust</title>
      </sec>
      <sec id="sec-2-7">
        <title>Secure storage</title>
      </sec>
      <sec id="sec-2-8">
        <title>Accountability</title>
        <p>data</p>
        <sec id="sec-2-8-1">
          <title>Authorization parties of protocol of</title>
        </sec>
        <sec id="sec-2-8-2">
          <title>Management of privileges</title>
        </sec>
        <sec id="sec-2-8-3">
          <title>Network anonymity</title>
        </sec>
        <sec id="sec-2-8-4">
          <title>Anonymity of sender</title>
        </sec>
        <sec id="sec-2-8-5">
          <title>Anonymity of receiver</title>
        </sec>
        <sec id="sec-2-8-6">
          <title>Availability of services</title>
        </sec>
        <sec id="sec-2-8-7">
          <title>Trust between parties of protocol storage of</title>
        </sec>
        <sec id="sec-2-8-8">
          <title>TTP trust</title>
        </sec>
        <sec id="sec-2-8-9">
          <title>Secure data</title>
        </sec>
        <sec id="sec-2-8-10">
          <title>Network accountability</title>
        </sec>
        <sec id="sec-2-8-11">
          <title>Protocol/service accountability</title>
          <p>
            mation access and disclosure
Correct authorization of the parties of
protocol is required to realize the
steps of protocol
The function of a party in the
protocol depends on his certain defined
permission level
Hiding the fact that there was a data
exchange (hiding the information
flow, hiding the network traffic)
Hiding the identity of message sender
(without network anonymity)
Hiding the identity of message
receiver (without network anonymity)
Ensuring timely and reliable access to
services and data and use of
information
Possibility of public verification of
action in protocol between parties of
protocol
Possibility of public verification of
action in protocol with TTP usage
Confidential and permanent storage
of information, available for legal
users
Events in network are registered to
restore past threats
Steps of protocols (access to services)
are registered to restore past threats
The postulated system conditions, which are described by the security services, can
be fulfilled with many different security elements. To achieve an appropriate level of
security we can use different mechanisms [
            <xref ref-type="bibr" rid="ref3 ref4 ref5 ref6 ref7">3, 4, 5, 6, 7</xref>
            ]. In the article we will focus
on two groups of solutions: services based on PKI [
            <xref ref-type="bibr" rid="ref1 ref10 ref13 ref15 ref9">1, 3 4, 9, 10, 13, 15</xref>
            ] and
independent cryptographic modules [
            <xref ref-type="bibr" rid="ref4">4</xref>
            ]. The detailed descriptions of the used security
mechanisms can be found in the literature, e.g., in the articles cited in the
bibliography of this paper.
3
          </p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>The concept of scalable security</title>
      <p>The realization of electronic process is dependent of a proper level of security.
During the projecting of mentioned process the security mechanisms are established.
They are usually overestimated according to real risk. One can notice that there are
differences connected with information sent in the same electronic process. They
concern different threats, which in the case of successful attack will affect the parties
of a protocol. In a case of small threat, there is a great possibility of decreasing
redundant resources of information security, which in fact will improve efficiency of
the protocol, system availability and, as a consequence, will increase its security
3.1</p>
      <p>General requirements
Secure electronic processes are based on cryptographic protocols. Application of
properly designed cryptographic protocol introduces many security services, which
enable reliable realization of the electronic process. The protocols realize security
services by means of various security elements: e.g. PKI-based services and
cryptographic modules. The usage of these security elements is strictly defined in the steps
of cryptographic protocols. As a result of that, any modification of their content is
forbidden; otherwise it will ruin the whole concept of the protocols, what in fact
negates an idea of scalable security.</p>
      <p>Te solution of that contradiction is creating different protocols realizing the same
service, applied on different level of security1. To precise a certain electronic service
one constructs a protocol according to well-defined security requirements. Some
security elements can be configured before the real process implementation, while the
others introduced in a dynamic process of the system tuning. This can be done by
using some unchangeable security elements whose change is critical for the
processes.
3.2</p>
      <p>Parameters of the scalable security
The security level of an electronic process can depend on several different factors.
The security can be modified by means of their proper choice. In the presented model
of the scalable security, the resultant protection of information is the following
function of three primary parameters2:
1 For simplicity, when we will change the element which is not important for the protocol’s
functionality, but important for its security, we will call it a new protocol.
2 s is the security level, which is realized by a given version of cryptographic protocol;
i is a number of subprotocols in a given protocol;
j is a number of steps of parameters in a given subprotocol;
x is a concrete security service;
ωixj is the weight describing an average cost of loses after successful attack for a given service;
ω ∈ (0,1)
Lx is a value of security elements for a given service; L ∈ (0, 1)</p>
      <p>ij
Pijx is the probability of attack on a given service; P ∈ (0, 1)
Z is a convergence exponent of the security elements. Z ∈ (1, 25)
a
i
b</p>
      <p>c
j</p>
      <p>x
FS = ∑ ∑ ∑ (Lij )[ω ixj (1 − Pijx )](
x
ω ixj Lixj Z</p>
      <p>)
ω ixj
The three primary parameters in the equation (1) are:
1. The protection level: Lixj ;
2. The risk of attack on a given service: [ω ixj (1 − Pijx )] ;</p>
      <sec id="sec-3-1">
        <title>3. The dependence (coefficient) of security elements: (</title>
        <p>ω ixj Lixj ) Z ;
ω ixj
(1)
Each of the above parameters in the formula (1) is calculated for all cryptographic
protocols, all subprotocols of these protocols and all steps of the subprotocols.</p>
        <p>Trust Time- Information Audit TTP to TTP
between stamping repository L_PTA3=
interoperaparts of L_PTA1= L_PTA2= 20% bility
protocol 30% 30% L_PTA4=
(PTA) 20%
TTP trust Time- Information Audit TTP to TTP Notary
(PTT) stamping repository L_PTT3= interopera- L_PTT5=</p>
        <p>L_PTT1= L_PTT2= 10% bility 30%
30% 20% L_PTT4=</p>
        <p>10%
Secure Encryption Time- Key Certificate Non- Information Directory Audit PKG
storage of L_SS1=30% stamping management management repudiation repository services L_SS8=5% L_SS9=5%
data (SS) L_SS2=10% L_SS3=10% L_SS4=10% PKI L_SS6=15% L_SS7=5%</p>
        <p>L_SS5=10%
Network Logging Audit Encryption Digital Information
account- L_NA1= L_NA2= L_NA3= Signatures repository
ability (NA) 50% 20% 10% L_NA4= L_NA5=</p>
        <p>10% 10%
Proto- Logging Audit Encryption Digital Information
col/service L_PA1= L_PA2= L_PA3= Signatures repository
account- 50% 20% 10% L_PA4= L_PA5=
ability (PA) 50% 10%</p>
        <p>The first parameter defines the protection level for a given cryptographic service in
a given step of subprotocol. This is a sum of chosen security elements, which
guarantee security of a given service.</p>
        <p>The second parameter shows a risk of attack on a given security service. This is a
multiplication of average losses made by successful attack and probability of attack
on a given security service.</p>
        <p>The third parameter describes independence of security elements used to gain a
proper protection level. The security elements are mutually connected; missing some
protection of information mechanisms in one subprotocol (e.g., at the beginning of
the protocol) strongly influences the security of other subprotocols. The level of
convergence can also be changeable; it depends on, e.g., a number of subprotocols and
the security level.</p>
        <p>The security level of electronic processes mainly depends on the used elements of
protection of information required by the security services. In this paper, the security
elements are based on PKI services and cryptographic modules. In Table 2,
dependences of security services and security mechanisms are presented. Every security
service can be realized by different security mechanisms. Security level of a given
protocol will depend, among other things, on an appropriate selection of the elements.
For every security elements their contribution to the global protection of services is
defined as Lixj . The individual contribution of particular services is defined in
percent.</p>
        <p>Security dependencies of the security elements (Table 2) are only an example. It
can be created in a free way using different security mechanisms. The value of the
parameter L is constant for particular security requirements. Creating the
cryptographic protocol on a different level of protection, we do not modify this parameter.
3.3</p>
        <p>Impact of successful attack</p>
        <p>The parameters, which are set up during the risk calculation are the weights for
particular services ωixj . These weights indicate the average loses caused by a
successful attack.
In the risk modelling, the impact is the result of an information security incident,
caused by a threat, which affects assets. In the presented model of scalable security
the resultant impact is obtained by combination of two kinds of impact, caused by
direct and indirect reasons. Below we present the parameters used during the impact
calculation:
The direct parameters:</p>
        <p>LZixj are the assets gained during a successful attack on a given security elements
(100% is the compromise of the whole protocol);</p>
        <p>Fijx are the financial losses during a successful attack on given security elements
(100% is the total financial loss);
The indirect parameters:</p>
        <p>α ixj are the financial costs, which are necessary for repairing the damages gained
during a successful attack (100% is the maximal cost);</p>
        <p>β ixj are the losses of the value of the company shares or the company reputation
(100% is the maximal market loss).</p>
        <p>To calculate the impact of a successful attack (ωixj ) we use a combination of the
parameters described above. Thus, the parameter LZ ixj describes the influence of
potential harm of a given threat to compromise the whole process. The Fijx describes
direct financial losses during the attack on the particular step of the protocol.</p>
        <p>The next parameters are connected with an indirect impact of the successful attack.
The first group of parameters (α ixj ) is connected with the indirect financial losses,
which must be taken after successful attack on the system. Those financial losses are
due to damage and repairing of the information systems. The second group of
parameters ( β ixj .) describes the loss of the company securities or a company reputation.</p>
        <p>By combination of all the mentioned parameters we obtain the impact of an attack
in a particular process:</p>
        <p>ω ixj = (Fijx + β ixj +α ixj ) LZ ixj</p>
        <p>The impact parameter is a changeable part of the Equation (1) for a particular
processes, because losses connected with a successful attack can be different for a
concrete information process.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Usage of the scalable security model: e-auction</title>
      <p>
        The concept of scalable security can be realized for different types of cryptographic
protocols [
        <xref ref-type="bibr" rid="ref8 ref9">8, 9</xref>
        ]. In this paper we present an example, which implements the idea of
scalable security for the electronic auction. The considered e-auction model is
formulated as the cryptographic protocol [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ].
4.1
      </p>
      <p>The e-auction model
The analysed protocol of e-auction consists of four subprotocols: certification,
notification of auction, notification of the offer, and the choice of the offer. In protocol take
part N bidders (O1, ... ,ON), third trustworthy person that is GAP (central auction
agency) as well as firm, which wants to announce the auction.</p>
      <p>The first step of protocol is verification by GAP, the participants taking part in
eauction, that is the bidders ON as well as firm F which wants to announce the auction
(the subprotocol of certification). The next step is notification to GAP the auction by
verified firm F. GAP publishes the conditions of notified auction, giving all
requirements notified by F (the subprotocol of notification of auction). In the next step,
person wanting to take part in auction, after the earlier verification, sends his offer to
GAP (the subprotocol of notification of the offer). The last subprotocol is executed
after elapsing of time for notification of offers, then the firm F as well as bidders ON,
send their parts of secret (needed to read offers) to GAP. After decoding them, they
will be sent to firm F, where victorious offer will be chosen. In the same subprotocol,
the firm F sends information about the victorious offer to GAP, and then it will be
published to (be generally known) public message (the subprotocol of choice of the
offer).</p>
      <p>The communication between participants of the protocol is safe. We achieve it
thanks to using public key cryptography, where every participant of the protocol
possesses his private key (SK) as well as public key (PK). Those practical keys are
not permanent; their validity ends with the validity of the registration number, which
is achieved in the subprotocol of certification.
4.2</p>
      <p>Security of a chosen sub-protocol</p>
      <p>As we mentioned, we present usage of the scalable security for the subprotocol of
notification of electronic auction. The protocol (see Fig.1) can be notified by any
person, which obtained suitable authorizations in the subprotocol of certification.</p>
      <p>F
Input =(NRF,SKF,TNRF ,WPF )
KG NF</p>
      <p>GAP</p>
      <p>WWW
2a. If (NRF, TNRF) = TRUE
2b. KG NP, (SKP,PKP)
2c. SKP = SKP(F) + SKP(GAP) + SKP(OF)
4. NP, WPF, PKP
Fig. 1. A diagram of the subprotocol of the electronic auction notification
Such a person, called F, should possess the registration number NRF, his time stamp
TNRF, private key SKF as well as conditions of notified auction WPF . F generates with
the help of the generator of random numbers (KG), his individual number NF.
Step 1:
In the first step, F sends to GAP, signed digitally (SKF) as well as coded (PKGAP) the
following information: his registration number (NRF), his time stamp (TNRF), the
conditions of auction (WPF), and his individual number (NF).</p>
      <p>Step 2:
The central auction agency (GAP) verifies the registration number of F, (NRF) and
validity of his timestamp. After positive authorization, GAP generates the individual
number of auction (NP) and the pair of keys for the concrete auction, (SKP,PKP). The
private key of auction (SKP) is divided into parts by using the threshold scheme of
secret sharing. Secret is divided into three parts, designed for F( SKP(F)), for GAP
(SKP(GAP)) and for bidders in the auction (SKP(OF)). Each part is necessary to
reproduce the private key (SKP).</p>
      <p>Step 3:
GAP sends digitally signed (SKGAP) and encrypted (PKF), the part of the secret
designed for F (SKP(F)).</p>
      <p>Step 4:
GAP publishes, for example on WWW site, the number of auction (NP), conditions of
it (WPF) and the public key of the auction (PKP).
4.3</p>
      <p>Results
The Step 1, which must be executed, defines weights, which describe the risk „ω ixj ”
for particular security services in all the steps of subprotocol. In the described case
the defined weights are constant for a given process. If any security service is not
required in a given step, the weight of described risk is equal to zero. In Table 3 we
present the values of weights for a given subprotocol.</p>
      <p>PI
PC
PNRS
PAu
PSS
PMP</p>
      <p>During the Step 2, we define security elements, which realize chosen security
elements (Table 4). This element is changeable for every version of described
subprotocols. In the paper we describe three versions of the subprotocol, the first, basic (“A”),
and others, with larger number of security elements (“B”) and smaller number of
security elements (“C”).</p>
      <p>During the Step 3, we set up probability of attack on a particular services in
described steps of protocol. (Table 5). Those values are constant for a given process.</p>
      <p>The last parameter is a parameter of function convergence whose characteristics are
shown in Fig. 2. In the described subprotocol, the value of parameter Z = 3 was
chosen.</p>
      <p>In the last Step 4, checking the security level of the particular version of the
subprotocol, we calculate the value of the function F, see Equation 1. The results of
calculations are presented in Table 6.</p>
    </sec>
    <sec id="sec-5">
      <title>Conclusions</title>
      <p>Analysis of this paper shows that we three versions of described subprotocol, each
with different level of protection. The basic level (“A”) is much higher than the level
with a few security elements (“C”). Thus, the level (“C”) could be used only in a case
of transporting unimportant data. The version with the highest security level (“B”),
guarantee the strongest protection of the subprotocol. This version is adequate for
transmission of critical data between the parties of the protocol.</p>
      <p>
        The prior setting up different security levels for all subprotocols in the whole
eauction protocol helps us to change particular versions of subprotocol, creating freely
scalable with respect to the security level, final version of the protocol. Such a
possibility can be useful in a case of modifying the security levels in particular phases of
subprotocol [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ], which can decrease system performance and, as a result, its
security.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Lambrinoudakis</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gritzalis</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dridi</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pernul</surname>
          </string-name>
          , G.:
          <article-title>Security requirements for egovernment services: a methodological approach for developing a common PKI-based security policy</article-title>
          .
          <source>Computer Communication</source>
          <volume>26</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2003</year>
          )
          <fpage>1873</fpage>
          -
          <lpage>1883</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>NIST</given-names>
            <surname>: Volume</surname>
          </string-name>
          <string-name>
            <surname>I</surname>
          </string-name>
          :
          <article-title>Guide for Mapping Types of Information and Information Systems to Security Categories (</article-title>
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Patel</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gladychev</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Katsikas</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gritzalis</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lekkas</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>KEYSTONE project, Support for Legal Framework and Anonymity in the KEYSTONE Public Key Infrastructure Architecture (</article-title>
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Kulesza</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kotulski</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          :
          <article-title>On Automatic Secret Generation and Sharing for Karin-Greene - Hellman Scheme</article-title>
          . In: J.
          <string-name>
            <surname>Sołdek</surname>
          </string-name>
          , L. Drobiazgiewicz, (ed.):
          <source>Artificial Intelligence and Security in Computing Systems</source>
          , Kluwer (
          <year>2003</year>
          )
          <fpage>281</fpage>
          -
          <lpage>292</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Groves</surname>
          </string-name>
          , J.:
          <article-title>Security for Application Service Providers</article-title>
          .
          <source>Network Security, Issue</source>
          <volume>1</volume>
          ,
          <string-name>
            <surname>January</surname>
            <given-names>1</given-names>
          </string-name>
          , (
          <year>2001</year>
          )
          <fpage>6</fpage>
          -
          <lpage>9</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6. ISO/IEC 11770-
          <article-title>3: Key management-Part 3: Mechanisms using asymmetric techniques (</article-title>
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. ETSI TS 102 042:
          <article-title>Policy requirements for certification authorities issuing public key certificates (</article-title>
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Barlow</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>A Discussion of Cryptographic Protocols for Electronic Voting (</article-title>
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Księżopolski</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kotulski</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          :
          <article-title>Cryptographic protocol for electronic auctions with extended requirements; Annales UMCS Informatica v</article-title>
          .
          <volume>2</volume>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Teoh</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ngo</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goh</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Personalised cryptographic key generation based on Face Hashing; Computer &amp; Security 23</article-title>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <fpage>606</fpage>
          -
          <lpage>614</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Saez</surname>
          </string-name>
          , G.:
          <article-title>Generation of key pre-distribution schemes using secret sharing schemes</article-title>
          .
          <source>Discrete Applied Mathematics</source>
          <volume>128</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2003</year>
          )
          <fpage>239</fpage>
          -
          <lpage>249</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Groves</surname>
          </string-name>
          , J.:
          <article-title>Security Application Service Providers. Network Security, Issue 1</article-title>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2001</year>
          )
          <fpage>6</fpage>
          -
          <lpage>9</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Reiter</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rubin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Crowds: Anonymity for Web Transaction</article-title>
          .
          <source>ACM Transaction on Inf formation and System Security</source>
          , Vol.
          <volume>1</volume>
          , No.
          <volume>1</volume>
          (
          <year>1998</year>
          )
          <fpage>66</fpage>
          -
          <lpage>92</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Merabti</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shi</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oppliger</surname>
          </string-name>
          , R.:
          <article-title>Advanced security techniques for network protection</article-title>
          .
          <source>Computer Communications</source>
          <volume>23</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2000</year>
          )
          <fpage>151</fpage>
          -
          <lpage>158</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Tzong-Sun</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chien-Lung</surname>
          </string-name>
          , H.:
          <article-title>Efficient user identification scheme with key distribution preserving anonymity for distributed computer networks</article-title>
          .
          <source>Computer &amp; Security</source>
          <volume>23</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <fpage>120</fpage>
          -
          <lpage>125</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Patton</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Josang</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Technologies for Trust in Electronic Commerce</article-title>
          .
          <source>Electronic Commerce Research</source>
          ,
          <volume>4</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <fpage>9</fpage>
          -
          <lpage>21</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Moitr</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Konda</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>An empirical investigation of network attacks on computer system</article-title>
          .
          <source>Computer &amp; Security</source>
          <volume>23</volume>
          .
          <string-name>
            <surname>Elsevier</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <fpage>43</fpage>
          -
          <lpage>51</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>