<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">On a Concept of Scalable Security: PKI-based Model using Additional Cryptographic Modules</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Bogdan</forename><surname>Księżopolski</surname></persName>
							<email>bogdan@kft.umcs.lublin.pl</email>
							<affiliation key="aff0">
								<orgName type="department">Faculty of mathematics, physics and computer science</orgName>
								<orgName type="institution">M. Curie-Skłodowska University</orgName>
								<address>
									<addrLine>Pl. M. Curie-Skłodowskiej 1</addrLine>
									<postCode>20-031</postCode>
									<settlement>Lublin</settlement>
									<country key="PL">Poland</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Zbigniew</forename><surname>Kotulski</surname></persName>
							<email>zkotulsk@ippt.gov.pl</email>
							<affiliation key="aff1">
								<orgName type="department" key="dep1">Institute of Fundamental Technological Research of PAS</orgName>
								<orgName type="department" key="dep2">Institute of Telecommunications of WUT</orgName>
								<address>
									<addrLine>Świętokrzyska 21, Nowowiejska 15/19</addrLine>
									<postCode>00-049, 00-665</postCode>
									<settlement>Warsaw, Warsaw</settlement>
									<country>Poland, Poland</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">On a Concept of Scalable Security: PKI-based Model using Additional Cryptographic Modules</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">FFE7CF8225B01F2DDFC34165512C1581</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T11:14+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><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></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><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 <ref type="bibr" target="#b11">[12,</ref><ref type="bibr" target="#b13">14,</ref><ref type="bibr" target="#b15">16]</ref>. 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 <ref type="bibr" target="#b0">[1]</ref>. 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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Security services and supporting elements</head><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 <ref type="bibr" target="#b0">[1,</ref><ref type="bibr" target="#b1">2]</ref>. 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 <ref type="table" target="#tab_0">1</ref>. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Protocol/service accountability</head><p>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 <ref type="bibr" target="#b2">[3,</ref><ref type="bibr" target="#b3">4,</ref><ref type="bibr" target="#b4">5,</ref><ref type="bibr" target="#b5">6,</ref><ref type="bibr" target="#b6">7]</ref>. In the article we will focus on two groups of solutions: services based on PKI <ref type="bibr">[1, 3 4, 9, 10, 13, 15]</ref> and independent cryptographic modules <ref type="bibr" target="#b3">[4]</ref>. 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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">The concept of scalable security</head><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</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">General requirements</head><p>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 security 1 . 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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Parameters of the scalable security</head><p>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 parameters 2 :</p><p>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;</p><p>x is a concrete security service;</p><p>x ij ω is the weight describing an average cost of loses after successful attack for a given service; ω ∈ (0,1)</p><formula xml:id="formula_0">x ij</formula><p>L is a value of security elements for a given service; L ∈ (0, 1)   x ij P is the probability of attack on a given service; P ∈ (0, 1) Z is a convergence exponent of the security elements. Z ∈ (1, 25)</p><formula xml:id="formula_1">∑∑∑ − = a i Z x ij x ij x ij b j x ij x ij c x x ij S L P L F ) ( )] 1 ( [ ) ( ω ω ω (1)</formula><p>The three primary parameters in the equation ( <ref type="formula">1</ref>) are:</p><p>1. The protection level: ;</p><p>x ij L 2. The risk of attack on a given service:</p><formula xml:id="formula_2">[ ; )] 1 ( x ij x ij P − ω 3. The dependence (coefficient) of security elements: Z x ij x ij x ij L ) ω ω ( ;</formula><p>Each of the above parameters in the formula ( <ref type="formula">1</ref>) is calculated for all cryptographic protocols, all subprotocols of these protocols and all steps of the subprotocols. 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 <ref type="table" target="#tab_1">2</ref>, 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 . The individual contribution of particular services is defined in percent.</p><p>x ij L Security dependencies of the security elements (Table <ref type="table" target="#tab_1">2</ref>) 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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Impact of successful attack</head><p>The parameters, which are set up during the risk calculation are the weights for particular services . These weights indicate the average loses caused by a successful attack.</p><p>x ij ω</p><p>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:</p><p>The direct parameters:</p><p>x ij LZ are the assets gained during a successful attack on a given security elements (100% is the compromise of the whole protocol);</p><p>x ij F are the financial losses during a successful attack on given security elements (100% is the total financial loss); The indirect parameters:</p><p>x ij α are the financial costs, which are necessary for repairing the damages gained during a successful attack (100% is the maximal cost);</p><p>x ij β 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 ( ) we use a combination of the parameters described above. Thus, the parameter describes the influence of potential harm of a given threat to compromise the whole process. The describes direct financial losses during the attack on the particular step of the protocol.</p><formula xml:id="formula_3">x ij ω LZ x ij x ij F</formula><p>The next parameters are connected with an indirect impact of the successful attack. The first group of parameters ( ) 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 ( .) describes the loss of the company securities or a company reputation.</p><formula xml:id="formula_4">x ij α x ij β</formula><p>By combination of all the mentioned parameters we obtain the impact of an attack in a particular process:</p><formula xml:id="formula_5">x ij x ij x ij x ij x ij LZ F ) ( α β ω + + =</formula><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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Usage of the scalable security model: e-auction</head><p>The concept of scalable security can be realized for different types of cryptographic protocols <ref type="bibr" target="#b7">[8,</ref><ref type="bibr" target="#b8">9]</ref>. 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 <ref type="bibr" target="#b8">[9]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1">The e-auction model</head><p>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 (O 1 , ... ,O N ), 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 O N 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 O N , 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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2">Security of a chosen sub-protocol</head><p>As we mentioned, we present usage of the scalable security for the subprotocol of notification of electronic auction. The protocol (see Fig. <ref type="figure" target="#fig_0">1</ref>) can be notified by any person, which obtained suitable authorizations in the subprotocol of certification. Step 1:</p><p>In the first step, F sends to GAP, signed digitally (SK F ) as well as coded (PK GAP ) the following information: his registration number (NR F ), his time stamp (T NRF ), the conditions of auction (WP F ), and his individual number (N F ).</p><p>Step 2:</p><p>The central auction agency (GAP) verifies the registration number of F, (NR F ) and validity of his timestamp. After positive authorization, GAP generates the individual number of auction (N P ) and the pair of keys for the concrete auction, (SK P ,PK P ). The private key of auction (SK P ) is divided into parts by using the threshold scheme of secret sharing. Secret is divided into three parts, designed for F( SK P(F) ), for GAP (SK P(GAP) ) and for bidders in the auction (SK P(OF) ). Each part is necessary to reproduce the private key (SK P ).</p><p>Step 3: GAP sends digitally signed (SK GAP ) and encrypted (PK F ), the part of the secret designed for F (SK P(F) ).</p><p>Step 4: GAP publishes, for example on WWW site, the number of auction (N P ), conditions of it (WP F ) and the public key of the auction (PK P ).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.3">Results</head><p>The Step 1, which must be executed, defines weights, which describe the risk " " 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 <ref type="table" target="#tab_2">3</ref> we present the values of weights for a given subprotocol.</p><p>x ij ω  During the Step 2, we define security elements, which realize chosen security elements (Table <ref type="table" target="#tab_3">4</ref>). 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 <ref type="table" target="#tab_4">5</ref>). Those values are constant for a given process. Step 1</p><p>Step 2</p><p>Step 3</p><p>Step 4 P I 0,8 0,3 0,3 0,7 P C 0,7 0,9 0,8 0 P NRS 0,4 0 0,2 0,6 The last parameter is a parameter of function convergence whose characteristics are shown in Fig. <ref type="figure" target="#fig_2">2</ref>. In the described subprotocol, the value of parameter Z = 3 was chosen.</p><formula xml:id="formula_6">P</formula><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 <ref type="formula">1</ref>. The results of calculations are presented in Table <ref type="table" target="#tab_5">6</ref>. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Conclusions</head><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. 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 <ref type="bibr" target="#b16">[17]</ref>, which can decrease system performance and, as a result, its security.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Fig. 1 .</head><label>1</label><figDesc>Fig. 1. A diagram of the subprotocol of the electronic auction notification</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Fig. 2 .</head><label>2</label><figDesc>Fig. 2. Characteristic of the convergence parameter.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_0"><head>Table 1 .</head><label>1</label><figDesc>Characteristics of the security services</figDesc><table><row><cell>Group of services</cell><cell>Name of the service</cell><cell></cell><cell>Characteristics</cell></row><row><cell>Integrity</cell><cell>Integrity of data</cell><cell></cell><cell>Prevention against improper informa-</cell></row><row><cell></cell><cell></cell><cell></cell><cell>tion modification or destruction</cell></row><row><cell></cell><cell cols="2">Non-repudiation of</cell><cell>Non-repudiation of sending a mes-</cell></row><row><cell></cell><cell>action</cell><cell></cell><cell>sage (the fact of communication)</cell></row><row><cell></cell><cell cols="2">Non-repudiation of</cell><cell>Non-repudiation of sender's identity</cell></row><row><cell>Non-repudiation</cell><cell>sender</cell><cell></cell><cell>and the fact of sending a message by the sender</cell></row><row><cell></cell><cell cols="2">Non-repudiation of</cell><cell>Non-repudiation of receiver's identity</cell></row><row><cell></cell><cell>receiver</cell><cell></cell><cell>and the fact of receiving a message by</cell></row><row><cell></cell><cell></cell><cell></cell><cell>the receiver</cell></row><row><cell>Confidentiality</cell><cell>Confidentiality</cell><cell cols="2">of Guarantee of only authorized infor-</cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head>Table 2 .</head><label>2</label><figDesc>Security dependencies describing possible security services and security elements that realize them.</figDesc><table><row><cell></cell><cell>1</cell><cell>2</cell><cell>3</cell><cell>4</cell><cell>5</cell><cell>6</cell><cell>7</cell><cell>8</cell><cell>9</cell></row><row><cell>Integrity of</cell><cell>Digital</cell><cell>Key</cell><cell>Certificate</cell><cell>Directory</cell><cell>TTP to TTP</cell><cell>PKG</cell><cell></cell><cell></cell><cell></cell></row><row><cell>data (I)</cell><cell>Signatures</cell><cell>management</cell><cell>management</cell><cell>services</cell><cell>interopera-</cell><cell>L_I6=10%</cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell>L_I1=50%</cell><cell>L_I2=10%</cell><cell>L_I3=10%</cell><cell>L_I4=5%</cell><cell>bility</cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>L_I5=15%</cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Non-</cell><cell>Digital</cell><cell>Time-</cell><cell>Key</cell><cell>Certificate</cell><cell>Audit</cell><cell>Non-</cell><cell>Directory</cell><cell>Information</cell><cell>PKG</cell></row><row><cell>repudiation</cell><cell>Signatures</cell><cell>stamping</cell><cell>management</cell><cell>management</cell><cell>L_NRM5=</cell><cell>repudiation</cell><cell>services</cell><cell>repository</cell><cell>L_NRM9=</cell></row><row><cell>of action</cell><cell>L_NRM1=</cell><cell>L_NRM2=</cell><cell>L_NRM3=</cell><cell>L_NRM4=</cell><cell>5%</cell><cell>PKI</cell><cell>L_NRM7=</cell><cell>L_NRM8=</cell><cell>10%</cell></row><row><cell>(NRM)</cell><cell>30%</cell><cell>15%</cell><cell>10%</cell><cell>10%</cell><cell></cell><cell>L_NRM6=</cell><cell>5%</cell><cell>5%</cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>10%</cell><cell></cell><cell></cell><cell></cell></row><row><cell>Non-</cell><cell>Digital</cell><cell>Time-</cell><cell>Key</cell><cell>Certificate</cell><cell>Audit</cell><cell>Non-</cell><cell>Directory</cell><cell>Information</cell><cell>PKG</cell></row><row><cell>repudiation</cell><cell>Signatures</cell><cell>stamping</cell><cell>management</cell><cell>management</cell><cell>L_NRS5=</cell><cell>repudiation</cell><cell>services</cell><cell>repository</cell><cell>L_NRS9=</cell></row><row><cell>of sender</cell><cell>L_NRS1=</cell><cell>L_NRS2=</cell><cell>L_NRS3=</cell><cell>L_NRS4=</cell><cell>5%</cell><cell>PKI</cell><cell>L_NRS7=</cell><cell>L_NRS8=</cell><cell>10%</cell></row><row><cell>(NRS)</cell><cell>30%</cell><cell>15%</cell><cell>10%</cell><cell>10%</cell><cell></cell><cell>L_NRS6=</cell><cell>5%</cell><cell>5%</cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>10%</cell><cell></cell><cell></cell><cell></cell></row><row><cell>Non-</cell><cell>Digital</cell><cell>Time-</cell><cell>Key</cell><cell>Certificate</cell><cell>Audit</cell><cell>Non-</cell><cell>Directory</cell><cell>Information</cell><cell>PKG</cell></row><row><cell>repudiation</cell><cell>Signatures</cell><cell>stamping</cell><cell>management</cell><cell>management</cell><cell>L_NRR5=</cell><cell>repudiation</cell><cell>services</cell><cell>repository</cell><cell>L_NRR9=</cell></row><row><cell>of receiver</cell><cell>L_NRR1=</cell><cell>L_NRR2=</cell><cell>L_NRR3=</cell><cell>L_NRR4=</cell><cell>5%</cell><cell>PKI</cell><cell>L_NRR7=</cell><cell>L_NRR8=</cell><cell>10%</cell></row><row><cell>(NRR)</cell><cell>30%</cell><cell>15%</cell><cell>10%</cell><cell>10%</cell><cell></cell><cell>L_NRR6=</cell><cell>5%</cell><cell>5%</cell><cell></cell></row><row><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>10%</cell><cell></cell><cell></cell><cell></cell></row><row><cell>Confidenti-</cell><cell>Encryption</cell><cell>Key</cell><cell>Certificate</cell><cell>SSS</cell><cell>Directory</cell><cell>PKG</cell><cell></cell><cell></cell><cell></cell></row><row><cell>ality of data</cell><cell>L_C1=50%</cell><cell>management</cell><cell>management</cell><cell>L_C4=15%</cell><cell>services</cell><cell>L_C6=10%</cell><cell></cell><cell></cell><cell></cell></row><row><cell>(C)</cell><cell></cell><cell>L_C2=10%</cell><cell>L_C3=10%</cell><cell></cell><cell>L_C5=5%</cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Authoriza-</cell><cell>Registration</cell><cell>Digital</cell><cell>Key</cell><cell>Certificate</cell><cell>TTP to TTP</cell><cell>Directory</cell><cell>Authoriza-</cell><cell>AA</cell><cell></cell></row><row><cell>tion of</cell><cell>L_Au1=</cell><cell>Signatures</cell><cell>management</cell><cell>management</cell><cell>interopera-</cell><cell>services</cell><cell>tion PKI</cell><cell>L_Au8=</cell><cell></cell></row><row><cell>parties of</cell><cell>20%</cell><cell>L_Au2=</cell><cell>L_Au3=</cell><cell>L_Au4=</cell><cell>bility</cell><cell>L_Au6=5%</cell><cell>L_Au7=</cell><cell>10%</cell><cell></cell></row><row><cell>protocol</cell><cell></cell><cell>20%</cell><cell>10%</cell><cell>10%</cell><cell>L_Au5=</cell><cell></cell><cell>10%</cell><cell></cell><cell></cell></row><row><cell>(Au)</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell>10%</cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Manage-</cell><cell>Registration</cell><cell>Authoriza-</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>ment of</cell><cell>L_MP1=</cell><cell>tion PKI</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>privileges</cell><cell>50%</cell><cell>L_MP2=</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>(MP)</cell><cell></cell><cell>50%</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Network</cell><cell>Crowds</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>anonymity</cell><cell>L_AA1=</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>(AN)</cell><cell>100%</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Anonymity</cell><cell>Individual</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>of sender</cell><cell>numbers</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>(AM)</cell><cell>L_AM1=</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell>100%</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>Anonymity</cell><cell>Broadcast-</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>of receiver</cell><cell>ing</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell>(AR)</cell><cell>L_AR1=</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row><row><cell></cell><cell>100%</cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell><cell></cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_2"><head>Table 3 .</head><label>3</label><figDesc>The values of weights for a given subprotocol</figDesc><table><row><cell></cell><cell>Step 1</cell><cell>Step 2</cell><cell>Step 3</cell><cell>Step 4</cell></row><row><cell>I C NRS ω ω ω Au ω SS ω MP ω</cell><cell>0.5 0.7 0.3 0 0 0</cell><cell>0.4 0.7 0 0.7 0.3 0.3</cell><cell>0.3 0.5 0.3 0 0 0</cell><cell>0.3 0 0.3 0 0 0</cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_3"><head>Table 4 .</head><label>4</label><figDesc>Security elements for a given subprotocol.</figDesc><table /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_4"><head>Table 5 .</head><label>5</label><figDesc>The values of probability in a given subprotocol.</figDesc><table /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_5"><head>Table 6 .</head><label>6</label><figDesc>The values of security levels for particular steps and whole subprotocol</figDesc><table><row><cell></cell><cell>Step1</cell><cell>Step2</cell><cell>Step3</cell><cell>Step4</cell><cell>Total</cell></row><row><cell>A</cell><cell>0.12351</cell><cell>0.37268</cell><cell>0.12502</cell><cell>0.00869</cell><cell>0.62991581</cell></row><row><cell>B</cell><cell>0.29296</cell><cell>0.77342</cell><cell>0.25435</cell><cell>0.04784</cell><cell>1.36858231</cell></row><row><cell>C</cell><cell>0.02675</cell><cell>0.04318</cell><cell>0.02131</cell><cell>0.00659</cell><cell>0.09785187</cell></row></table></figure>
		</body>
		<back>

			<div type="availability">
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Availability Availability of services</head></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Security requirements for egovernment services: a methodological approach for developing a common PKI-based security policy</title>
		<author>
			<persName><forename type="first">C</forename><surname>Lambrinoudakis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Gritzalis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Dridi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Pernul</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer Communication</title>
		<imprint>
			<biblScope unit="volume">26</biblScope>
			<biblScope unit="page" from="1873" to="1883" />
			<date type="published" when="2003">2003</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<monogr>
		<title level="m">NIST: Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories</title>
				<imprint>
			<date type="published" when="2004">2004</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><forename type="first">A</forename><surname>Patel</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Gladychev</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Katsikas</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Gritzalis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Lekkas</surname></persName>
		</author>
		<title level="m">KEYSTONE project, Support for Legal Framework and Anonymity in the KEYSTONE Public Key Infrastructure Architecture</title>
				<imprint>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">On Automatic Secret Generation and Sharing for Karin-Greene -Hellman Scheme</title>
		<author>
			<persName><forename type="first">K</forename><surname>Kulesza</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Z</forename><surname>Kotulski</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Artificial Intelligence and Security in Computing Systems</title>
				<editor>
			<persName><forename type="first">J</forename><surname>Sołdek</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">L</forename><surname>Drobiazgiewicz</surname></persName>
		</editor>
		<imprint>
			<publisher>Kluwer</publisher>
			<date type="published" when="2003">2003</date>
			<biblScope unit="page" from="281" to="292" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Security for Application Service Providers</title>
		<author>
			<persName><forename type="first">J</forename><surname>Groves</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Network Security</title>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="page" from="6" to="9" />
			<date type="published" when="2001-01-01">January 1, (2001</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<monogr>
		<idno>ISO/IEC 11770-3</idno>
		<title level="m">Key management-Part 3: Mechanisms using asymmetric techniques</title>
				<imprint>
			<date type="published" when="1999">1999</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<idno>ETSI TS 102 042</idno>
		<title level="m">Policy requirements for certification authorities issuing public key certificates</title>
				<imprint>
			<date type="published" when="2002">2002</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<title level="m" type="main">A Discussion of Cryptographic Protocols for Electronic Voting</title>
		<author>
			<persName><forename type="first">L</forename><surname>Barlow</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2003">2003</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">Cryptographic protocol for electronic auctions with extended requirements</title>
		<author>
			<persName><forename type="first">B</forename><surname>Księżopolski</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Z</forename><surname>Kotulski</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Annales UMCS Informatica v</title>
		<imprint>
			<biblScope unit="volume">2</biblScope>
			<date type="published" when="2004">2004</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">Personalised cryptographic key generation based on Face Hashing</title>
		<author>
			<persName><forename type="first">A</forename><surname>Teoh</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><surname>Ngo</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Goh</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer &amp; Security</title>
		<imprint>
			<biblScope unit="volume">23</biblScope>
			<biblScope unit="page" from="606" to="614" />
			<date type="published" when="2004">2004</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">Generation of key pre-distribution schemes using secret sharing schemes</title>
		<author>
			<persName><forename type="first">G</forename><surname>Saez</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Discrete Applied Mathematics</title>
		<imprint>
			<biblScope unit="volume">128</biblScope>
			<biblScope unit="page" from="239" to="249" />
			<date type="published" when="2003">2003</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<analytic>
		<title level="a" type="main">Security Application Service Providers</title>
		<author>
			<persName><forename type="first">J</forename><surname>Groves</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Network Security</title>
		<imprint>
			<biblScope unit="page" from="6" to="9" />
			<date type="published" when="2001">2001</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
	<note>Issue 1</note>
</biblStruct>

<biblStruct xml:id="b12">
	<analytic>
		<title level="a" type="main">Crowds: Anonymity for Web Transaction</title>
		<author>
			<persName><forename type="first">M</forename><surname>Reiter</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Rubin</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">ACM Transaction on Inf formation and System Security</title>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="66" to="92" />
			<date type="published" when="1998">1998</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<analytic>
		<title level="a" type="main">Advanced security techniques for network protection</title>
		<author>
			<persName><forename type="first">M</forename><surname>Merabti</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Q</forename><surname>Shi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Oppliger</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer Communications</title>
		<imprint>
			<biblScope unit="volume">23</biblScope>
			<biblScope unit="page" from="151" to="158" />
			<date type="published" when="2000">2000</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b14">
	<analytic>
		<title level="a" type="main">Efficient user identification scheme with key distribution preserving anonymity for distributed computer networks</title>
		<author>
			<persName><forename type="first">W</forename><surname>Tzong-Sun</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Chien-Lung</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer &amp; Security</title>
		<imprint>
			<biblScope unit="volume">23</biblScope>
			<biblScope unit="page" from="120" to="125" />
			<date type="published" when="2004">2004</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b15">
	<analytic>
		<title level="a" type="main">Technologies for Trust in Electronic Commerce</title>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">A</forename><surname>Patton</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Josang</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Electronic Commerce Research</title>
		<imprint>
			<biblScope unit="volume">4</biblScope>
			<biblScope unit="page" from="9" to="21" />
			<date type="published" when="2004">2004</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b16">
	<analytic>
		<title level="a" type="main">An empirical investigation of network attacks on computer system</title>
		<author>
			<persName><forename type="first">S</forename><surname>Moitr</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Konda</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computer &amp; Security</title>
		<imprint>
			<biblScope unit="volume">23</biblScope>
			<biblScope unit="page" from="43" to="51" />
			<date type="published" when="2004">2004</date>
			<publisher>Elsevier</publisher>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
