Lisa Rajbhandari
email: lisa.rajbhandari@hig.no

Einar Arthur Snekkenes
email: einar.snekkenes@hig.no

Mapping between Classical Risk Management and Game Theoretical Approaches

Keywords: Game theory, Risk management, Equilibrium, Strategies

In a typical classical risk assessment approach, the probabilities are usually guessed and not much guidance is provided on how to get the probabilities right. When coming up with probabilities, people are generally not well calibrated. History may not always be a very good teacher. Hence, in this paper, we explain how game theory can be integrated into classical risk management. Game theory puts emphasis on collecting representative data on how stakeholders assess the values of the outcomes of incidents rather than collecting the likelihood or probability of incident scenarios for future events that may not be stochastic. We describe how it can be mapped and utilized for risk management by relating a game theoretically inspired risk management process to ISO/IEC 27005. This shows how all the steps of classical risk management can be mapped to steps in the game theoretical model, however, some of the game theoretical steps at best have a very limited existence in ISO/IEC 27005.

Introduction

There are many classical risk management approaches and standards [START_REF] Campbell | A Classification Scheme for Risk Assessment Methods[END_REF], [START_REF] Vorster | A framework for comparing different information security risk analysis methodologies[END_REF] like NIST 800-30 [START_REF] Stoneburner | Risk Management Guide for Information Technology Systems[END_REF], RiskIT [START_REF]The Risk IT Framework[END_REF], ISO/IEC 27005 [START_REF]Information technology -Security techniques -Information security risk management. International Organization for Standardization[END_REF] and CORAS [START_REF] Soldal | A Guided Tour of the CORAS Method[END_REF]. For this paper, we consider the ISO/IEC 27005 [START_REF]Information technology -Security techniques -Information security risk management. International Organization for Standardization[END_REF] standard as it provides a clear description of the stages and terminologies of the risk management process.

In a typical classical risk assessment approach, the probabilities are usually guessed and not much guidance is provided on how to get the probabilities right. When coming up with probabilities, people are generally not well calibrated. Besides, history may not always be a very good teacher. The hypothesis of the paper is: 'Gathering representative probabilities for future events that may not be stochastic, is difficult. We claim it is a lot easier to obtain representative data on how stakeholders assess the values of the outcomes of events/incidents.' In a game theoretic approach, probabilities are obtained from the actual computation and analysis. Moreover, the strategy (mitigation measure to reduce risk) can be determined with respect to the opponent's strategy. When the risks are estimated more accurately, the effectiveness of the overall risk management approach increases.

The main contribution of this paper is to show that game theory can be integrated into classical risk management. For this, we provide a clear structure of both the classical risk management and game theoretical approaches. The intention is to enable the readers to have a better understanding of both methods.

We then describe how it can be mapped by relating a game theoretically inspired risk management process to ISO/IEC 27005. This shows how all the steps of ISO/IEC 27005 can be mapped to the steps in the game theoretical model; although some of the game theoretical steps at best have a very limited existence in ISO/IEC 27005.

The remainder of this paper is structured as follows. In Sect. 2, we present the state of the art and a summary of contributions. In Sect. 3, we first compare the top level perspectives of classical risk management and game theory. We then provide a more detailed mapping between the two approaches, identifying issues where a correspondence is missing. In Sect. 4, we discuss our findings. Conclusion and future work are given in Sect. 5.

State of the Art

The classical risk management approaches takes the perspective of the single player (individual, system, etc.) for which the risk analysis is being carried out. For example, in Probabilistic Risk Analysis (PRA), people and their actions and reactions are not given much importance [START_REF] Hausken | Probabilistic Risk Analysis and Game Theory[END_REF]. Thus, Hausken [START_REF] Hausken | Probabilistic Risk Analysis and Game Theory[END_REF] puts forward the way of merging PRA and game theory taking into account that, in risk assessment, the actions of the people affect each other. In addition, most of the classical risk assessment approaches are inclined to be rather subjective as the value of the probabilities of threats are either assumed or based on historical data. Taleb [START_REF] Nassim | The Black Swan: The Impact of the Highly Improbable[END_REF] has provided examples of Black Swan incidents that cannot be predicted accurately based on historical data.

In game theory, the incentives of the players are taken into consideration which is important in understanding the underlying motives for their actions. Liu and Zang [START_REF] Liu | Incentive-based modeling and inference of attacker intent, objectives, and strategies[END_REF] put forward the incentive-based modeling approach in order to understand attacker intent, objectives and strategies. Anderson and Moore [START_REF] Anderson | Information Security Economics -and Beyond[END_REF] also state the importance of incentives, as misaligned or bad incentives usually cause security failure.

Game theory helps to explore the behavior of real-world adversaries [START_REF] Jr | Game theory in an age of terrorism: How can statisticians contribute?[END_REF]. Cox has stated that, by using game theory, the adversarial risk analysis can be improved [START_REF] Cox | Game Theory and Risk Analysis[END_REF] as the actions of the attacker, which were regarded as random variables and judged from the defender's perspective, can be computed. QuERIES, a quantitative cybersecurity risk assessment approach, uses game theory for constructing and evaluating the attack/protect model [START_REF] Carin | Quantitative Evaluation of Risk for Investment Efficient Strategies in Cybersecurity: The QuERIES Methodology[END_REF], [START_REF] Carin | Cybersecurity Strategies: The QuERIES Methodology[END_REF].

While there are many papers discussing the use of game theory for specific application areas [START_REF] Carin | Cybersecurity Strategies: The QuERIES Methodology[END_REF], [START_REF] Jormakka | Modelling Information Warfare as a Game[END_REF], [START_REF] Roy | A Survey of Game Theory as Applied to Network Security[END_REF], we are aware of no works that integrate a risk management framework such as ISO/IEC 27005 and game theory.

Mapping between ISO/IEC 27005 and Game Theoretic Approach

In this section, we first compare the top level perspectives of classical risk management and game theory. We then provide a more detailed mapping between the two approaches, identifying issues where a correspondence is missing.

A Top Level Comparison

As stated above, there are many classical risk management approaches. To apply these approaches a clear understanding of the terminology and the overall process flow is necessary. We consider the risk management steps of the ISO/IEC 27005 [START_REF]Information technology -Security techniques -Information security risk management. International Organization for Standardization[END_REF] standard which is depicted in Fig. 1 (a). These steps can be iterated until the results are satisfactory. The input and output for each of these steps are given in ISO/IEC 27005 [START_REF]Information technology -Security techniques -Information security risk management. International Organization for Standardization[END_REF]. Game theory helps us to understand how the strategic interactions and interdependence among the rational players influence the outcomes they gain [START_REF] Watson | Strategy : An Introduction to Game Theory[END_REF], [START_REF] Ross | Game theory[END_REF]. The steps that we have identified are given in Fig. 1 (b). For each of the steps, we provide a short description. In addition, Fig. 2 depicts the input and output for each of the game theoretical steps.

1. The definition of scope of interest and assets that needs to be protected are identified by investigating the scenario. For the purpose of this paper, we choose the second alternative. 3. Once the players are identified, for each player we need to determine-3.1 Information they have when they make a decision.

Strategies or options related to the actions of the players to overcome

the threats or to gain opportunities. 3.3 Preferences of the players, which can be obtained by asking how they value the outcomes, as the choice of each option results in an outcome. It is conceivable that players value multiple orthogonal aspects of outcome (e.g. cash, trust, reputation and legal compliance). Thus, in many cases, it may be desirable to model outcomes as vectors. 3.4 Scale and weight should be defined so that the various outcomes can be compared. We can then rank the order of the preferences. 3.5 These preferences can then be represented by numbers which are known as payoffs/ utilities. Higher payoffs represent more preferred outcomes. The values are assigned considering the players' motivation, capabilities (e.g. resources to implement or defend the attack) and experiences. The players in general have the incentive to maximize their payoff. 4. The scenario can then be formulated in the normal (strategic) form. 5. The optimum strategies for each player can be identified. The combination of optimum or best strategies chosen by the players is the equilibrium and this specifies the outcome of the game to the players [START_REF] Rasmusen | Games and information: An introduction to game theory[END_REF].

The process is repeated as the players' options and their outcome valuation may change. Moreover, in the long run, the entire process should be repeated for effective risk management.

Mapping Individual Steps

Table 1 shows the result of the mapping between the risk management process of the ISO/IEC 27005 standard and the game theoretical steps. For each of the process of the ISO/IEC 27005 standard, the corresponding game theoretical steps are stated. The comparison is solely based on what is provided (process steps and terminologies) in the ISO/IEC 27005 standard. Both approaches are iterated until the result of the assessment is satisfactory.

The mapping shows that all the steps of ISO/IEC 27005 can be mapped to game theory. On the other hand, we have identified that some of the game theoretical steps like information gained, beliefs and incentives of the opposing players and optimization of the strategies by the players are not included in ISO/IEC 27005.

Discussion

In classical risk management, risk is calculated as a 'combination of the likelihood of an event and its consequence' [START_REF]ISO/IEC Guide 73. Risk management -Vocabulary -Guidelines for use in standards[END_REF]. The limitations in this approach are: (1) Probability is difficult to assess as the underlying process may not be stochastic. Even if the process is stochastic, lack of historical data makes the parameters of the distribution difficult to estimate. Moreover, it is not appropriate and rather subjective to use the historical data in some of the situations, for example in estimating the risk of a terrorist attack, war or extreme events (Black Swan events). ( 2) Probability also depends largely on the risk analyst's perception or expert elicitation. People are generally not well calibrated. Thus, it is subjective in most of the cases. (3) The beliefs and incentives of the opponent are not considered. These limitations might result in inappropriate choices and decisions, which can be overcome by using game theory.

The benefits of using game theory for risk management are: (1) The quality of data collected is likely to be better as no actuarial data is needed. It focuses on incentives, capabilities and experiences of the players rather than asking an expert for historically based probabilities. (2) Expert judgment on collected data can be audited as we can determine and investigate how the players assess the values of the outcomes, what information is available to them, and whether they (3) Probabilities are obtained from the actual computation and analysis. However, some of the limitations related to this approach are the players' limited knowledge about their own outcome(s) and the outcomes of others, and strategic uncertainty. ISO/IEC 27005 takes the perspective of the organization for which the risk assessment is being carried out and thus, the information gained, beliefs and incentives of the adversaries and optimization of the strategies by the players are not included. Game theory is compatible with classical risk management and can be integrated into ISO/IEC 27005. This integration will provide the risk analyst additional guidance on what issues to address in his analysis and how more auditable probability estimates can be obtained. This integration also shows that game theoretic framework can be used for the entire risk management process and not just for risk analysis.

Conclusion and Future Work

Clear structure for both the classical risk management and game theoretical approaches have been presented. The mapping shows that game theoretically inspired risk management process can be integrated into ISO/IEC 27005. With game theory, we can obtain representative data on how stakeholders assess the value of outcomes of incidents rather than collecting the probability of incident scenarios for future events that may not be stochastic. Moreover, game theory is a rigorous method for computing probability and also the risk analyst can achieve additional guidance on how more auditable probability estimates can be obtained. However, some steps of game theory are not included in the current version of ISO/IEC 27005.

For future work, the above approach will be explored with a comprehensive case study and extended to the iterative aspect of risk management. Moreover, we will investigate the feasibility of adopting our ideas in the context of ISO 31000.

Fig. 1 .

 1 Fig. 1. (a) Information Security Risk Management Process (taken from [8]) (b) Game Theoretical Steps

Fig. 2 .

 2 Fig. 2. Input and Output for Game Theoretical Steps

Table 1 .

 1 Mapping between ISO/IEC 27005 and Game Theoretic Approach

	ISO/IEC 27005 Process/ Terminology Game Theoretic Step/ Terminol-
				ogy
	Context		Setting the basic criteria	Scenario investigation (scope definition
	establishment Defining the scope &	& asset identification)
			boundaries	Player identification (good & bad guys)
			Organization for informa-
			tion security risk manage-
			ment (ISRM)
	Risk		Identification of assets	Included in scenario investigation
	identification Identification of threats	Determine the strategies for the bad
				guys
			Identification of existing	Identify implemented controls i.e. 'do
			controls	nothing' option for the good guys
			Identification of vulnerabil-	Options that can be exploited by
			ities	threats. Included while determining the
				strategies for the bad guys.
			Identification of conse-	Identify how the players value multiple
			quences	orthogonal aspects of outcomes. Identify
				the preferences.
	Risk		Assessment of consequences Define scale & weight for comparing
	estimation		outcomes, & ranking preferences.
				Represent by payoff/ utility (assign val-
				ues in each cell of the matrix).
			Assessment of incident like-	Computed probabilities for each of the
			lihood	strategies of both the players
			Level of risk estimation (list	Expected outcome for each of the strat-
			of risks with value levels as-	egy of the bad guy is the risk for good
			signed)	guy & vice versa.
	Risk		List of risks prioritized	Prioritize the expected outcome for both
	evaluation		the players.
	Risk		Risk treatment options-	Strategies (control measures) for the
	treatment	risk reduction, retention,	good guys; can be categorized into differ-
			avoidance & transfer	ent options based on the computed prob-
				abilities.
			Residual risks	Expected outcome of the game
	Risk		List of accepted risks based Strategies of the good guy (based on the
	acceptance	on the organization criteria organization criteria)
	Risk	Com-	Continual understanding of	Strategies of the good guy
	munication	the organization's ISRM
			process & results.
	Risk		Monitoring & review of risk Process is repeated as the players'
	Monitoring factors	options and their outcome valuation may
	& Review	Risk Management monitor-	change
			ing, reviewing & improving
			Not Included	Information gained by the opponent
			Not Included	Beliefs & incentives of the opponent
			Not Included	Optimization of the strategies

Acknowledgment: The work reported in this paper is part of the PETweb II project sponsored by The Research Council of Norway under grant 193030/S10. We would also like to thank the anonymous reviewers for their valuable comments and suggestions.


Mehdi Fallahpour
email: mfallahpour@uoc.edu

David Megías
email: dmegias@uoc.edu

High capacity FFT-based audio watermarking

This paper proposes a novel high capacity audio watermarking algorithm to embed data and extract it in a bit-exact manner based on changing the magnitudes of the FFT spectrum. The key idea is to divide the FFT spectrum into short frames and change the magnitude value of the FFT samples based on the average of the samples of each frame. Using the average of FFT magnitudes makes it possible to improve the robustness, since the average is more stable against changes compared with single samples. In addition to good capacity, transparency and robustness, this scheme has three parameters which facilitate the regulation of these properties. Considering the embedding domain, audio watermarking techniques can be classified into time domain and frequency domain methods. In frequency domain watermarking [1-7], after taking one of the usual transforms such as the Discrete/Fast Fourier Transform (DFT/FFT) [4-6], the Modified Discrete Cosine Transform (MDCT) or the Wavelet Transform (WT) from the signal [7], the hidden bits are embedded into the resulting transform coefficients. In [4-6], which were proposed by the authors of this paper, the FFT domain is selected to embed watermarks for making use of the translation-invariant property of the FFT coefficients to resist small distortions in the time domain. In fact, using methods based on transforms provides better perceptual quality and robustness against common attacks at the price of increasing the computational complexity.

In the algorithm suggested in this paper, we select the middle frequency band of the FFT spectrum (4-12 kHz) for embedding the secret bits. The selected band is divided into short frames and a single secret bit is embedded into each frame. Based on corresponding secret bit, all samples in each frame should be changed by the average of all samples or the average multiplied by a factor. If the secret bit is "0", all FFT magnitudes should be changed by the average of all FFT magnitudes in the frame. If the secret bit is "1", we divide the FFT samples into two groups based on the sequence and, then, we change the magnitude of the first group using a scale factor, α, multiplying the average of all samples and the magnitude of the second group multiplying (2α) by the average. These changes both in embedding "0" or "1", keep the average of the frame unchanged after embedding. Using the average of a frame is very useful to increase the robustness against attacks, whereas embedding a secret bit into a

single sample is usually fragile. In addition, using FFT magnitudes, sqrt(real ଶ + imag ଶ ), results in better robustness against attacks compared to using the real or the imaginary parts only. The Objective Difference Grade (ODG) has been used to evaluate the transparency of the proposed algorithm. The ODG is one of the output values of the ITU-R BS.1387 PEAQ standard, where ODG = 0 means no degradation and ODG = -4 means a very annoying distortion. Additionally, the OPERA software based on the ITU-R BS.1387 has been used to compute this objective measure of quality. The experimental results show that this method achieves a high capacity (about 0.5 to 4 kbps), provides robustness against common signal processing attacks and entails very low perceptual distortion (ODG is about -1). The proposed scheme is robust against several attacks such as AddDynNoise, ADDFFTNoise, Addnoise, AddSinus, Amplify, Invert, LSBZero, RC_HighPass, and RC_LowPass of the Stirmark Benchmark for Audio [START_REF]Stirmark Benchmark for Audio[END_REF] The method proposed in this paper has been compared with several recent audio watermarking strategies. Almost all the audio data hiding schemes which produce very high capacity are fragile against signal processing attacks. Because of this, it is not possible to establish a comparison of the proposed scheme with other audio watermarking schemes which are similar to it as capacity is concerned. Hence, we have chosen a few recent and relevant audio watermarking schemes in the literature. We compare the performance of the proposed watermarking algorithm and several recent audio watermarking strategies robust against the MP3 attack. [1, 8, 2, 4, 3] and the proposed scheme have capacity equal to 2, 2.3, 4.3, 2996, 689, and 506 to 4025 (bits per second) respectively, also transparency in term of Objective Difference Grade (ODG) is (-1.66 to -1.88), Not reported, Not reported, -0.6, Not reported and (-0.1 to -1.5). [START_REF] Xiang | Audio watermarking robust against time-scale modification and MP3 compression[END_REF][START_REF] Mansour | Data embedding in audio using time-scale modification[END_REF][START_REF] Li | Content based localized robust audio watermarking robust against time scale modification[END_REF] have low capacity but are robust against common attacks. [3] Evaluates distortion by using the mean opinion score (MOS), which is a subjective measurement, and achieves transparency between imperceptible and perceptible but not annoying (MOS = 4.7). Capacity, robustness and transparency are the three main properties of an audio watermarking scheme. Considering a trade-off between these properties is necessary. E.g. [START_REF] Xiang | Audio watermarking robust against time-scale modification and MP3 compression[END_REF] proposed a very robust, low capacity and high distortion scheme. However [START_REF] Garcia-Hernandez | Data hiding in audio signal using Rational Dither Modulation[END_REF] and the proposed scheme lead to high capacity and low distortion but they are not as robust as the low-capacity method described in [START_REF] Xiang | Audio watermarking robust against time-scale modification and MP3 compression[END_REF]. The scheme presented in [START_REF] Fallahpour | High capacity audio watermarking using FFTamplitude interpolation[END_REF], which was also proposed by the authors of this paper, has good properties, but the scheme proposed in this paper can manage the needed properties better since there are three useful adjustable parameters. For example, in the proposed scheme by using a frame size of d = 8 getting robustness against MP3-64 is straightforward. On the other hand, in [START_REF] Fallahpour | High capacity audio watermarking using FFTamplitude interpolation[END_REF], low bit rate MP3 compression was not considered. In short, we present a high-capacity watermarking algorithm for digital audio which is robust against common audio signal processing. A scaling factor, the frame size and the selected frequency band are the three adjustable parameters of this method which regulate the capacity, the perceptual distortion and the robustness of the scheme accurately. Furthermore, the suggested scheme is blind, since it does not need the original signal for extracting the hidden bits.

The experimental results show that this scheme has a high capacity (0.5 to 4 kbps) without significant perceptual distortion and provides robustness against common signal processing attacks such as added noise, filtering or MPEG compression (MP3).

Acknowledgement

This work is partially supported by the Spanish Ministry of Science and Innovation and the FEDER funds under the grants TSI2007-65406-C03-03 E-AEGIS and CONSOLIDER-INGENIO 2010 CSD2007-00004 ARES.


Muhammad Asim
email: muhammad.asim@philips.com

Luan Ibraimi
email: ibraimi@utwente.nl

Milan Petković
email: milan.petkovic@philips.com

Ciphertext-Policy Attribute-Based Broadcast Encryption Scheme

Keywords:

In this work, we design a new attribute-based encryption scheme with the revocation capability. In the proposed schemes, the user (broadcaster) encrypts the data according to an access policy over the set of attributes, and a list of the identities of revoked users. Only recipients who have attributes which satisfy the access policy and whose identity is not in the list of revoked users will be able to decrypt the message.The proposed scheme can be used for revocation of up to t users. The complexity of proposed schemes is dependent on the number of revoked users r, rather than on the total number n of users in the system. The security of the scheme has been proved under the Decisional Bilinear Diffie-Hellman (DBDH) assumption.

Introduction

In a broadcast encryption scheme with revocation capability, the sender (broadcaster) sends a ciphertext to a group of recipients such that only non-revoked users inside the group can decrypt the broadcasted content. Such a scheme allows the broadcaster to specify the list of revoked users who are not allowed to decrypt the digital content that is either broadcasted or placed in the organization's or public databases.

Efficient revocation of users in broadcast encryption schemes have achieved significant attention over the years as the revocation of the user is necessary and inevitable in numerous use cases. For example, in the domain of healthcare, privacy regulations such as healthcare insurance portability and accountability act (HIPAA) [START_REF]Summary of the HIPAA Privacy Rule[END_REF] give rights to patients to specify their consent policy. More specifically, individuals can request restrictions on the use and disclosure of health information. As a consequence, a doctor, who may be able to view the patient's data according to these regulations, may not be able to view the data. The revocation of a user also becomes important when an employee leaves the organization. Ideally the system should be able to revoke a user without (or minimally) affecting the non-revoked users.

Our Contributions.In this paper we propose a new ciphertext-policy attributebased broadcast encryption scheme. In our proposed scheme the encryptor encrypts the data according to the access policy τ and the list of the identities of revoked users. Only the users with the attribute set that satisfy the access policy τ and their identities are not in the list of revoked users would be able to decrypt the ciphertext. The proposed scheme is inspired by the Naor and Pinkas [START_REF] Naor | Efficient trace and revoke schemes[END_REF] scheme, which in turn uses a secret sharing technique to revoke users. We use this idea in the context of CP-ABE where only non-revoked users who satisfy the access policy will be capable to reconstruct the secret in the exponent and be able decrypt the ciphertext.

2 The Construction 1. Setup(k). The setup algorithm selects a bilinear group G 0 of prime order p and generator g. It also chooses a bilinear map ê :

G 0 × G 0 → G 1 and hash function H 1 : G 1 → {0, 1} l . Next to this, the setup picks α, β, x 1 , x 2 , • • • , x k ∈ Z p . For a set of attributes Ω = {a 1 , a 2 , ..., a k }, it sets T j = g xj (1 ≤ j ≤ k).
For the purpose of revocation, picks R ∈ Z p and generates a random polynomial P (z) = ã0 + ã1 z + ã1 z 2 + ... + ãt z t of degree t over Z p such that P (0) = R. Next, the setup algorithm generates N identifiers {I u1 , I u2 , • • • , I u N } and a share P (i) where 1 ≤ i ≤ N . In this paper, P (i) will be alternatively denoted by P (I ui ). The setup algorithm also computes t extra dummy shares which will be used when the number of revoked users is less than t. The public key-PK and master secret key-MK consist of the following components:

PK = ê(g, g) α , ê(g, g) β , {T j } k j=1 , {g P (Iui) } N i=1 , {g P (I dq ) } t q=1 MK = α, β, R = P (0), {x j } k j=1
2. KeyGeneration(MK, ω, I ui ). The key generation algorithm takes as input the attribute set ω the user has, and the identifier I ui assigned to the user.

The key generation algorithm first picks at random x,y ∈ Z p , and then computes the private key SK Iui,ω that consists of the following components:

SK Iui,ω = D (1) = g α-x-yP (0) , {D (2)
j = g x-β x j } aj ∈ω , D (3) = g yP (Iui) , D (4) = g y 3.
Encryption(m, τ, , PK). To encrypt a message m ∈ {0, 1} l , under the access policy τ over a set of attributes, and the set of revoked users = {I u1 , I u2 , • • • , I ut } the encryption algorithm picks at random s ∈ Z p , and assigns s î values (which are shares of s) to attributes in τ . For example the attributes are transformed into an access tree where the inner nodes represent an AND or OR boolean operators, and the leaf nodes are attributes. It assigns the value s to the root node. For AND node, it assigns a share to each child node, such as the sum of all shares is s. If the node is OR, it assigns the same value s to its child nodes. For the sake of simplicity, we mentioned only access policies which consist of AND and OR nodes, however, our scheme could also support threshold nodes or Out Of nodes. The resulted ciphertext consists of the following components:

CT τ, = C (1) = m ⊕ H 1 (ê(g, g) αs ), C (2) = ê(g, g) βs , C (3) = g s , {C (4) j,
î = g xj s î } a j, î∈τ , {C (5) i
= g sP (Iui) } Iui∈ 4. Decryption(CT τ, , SK Iu i ,ω ). The decryption algorithm takes as input the ciphertext CT τ, and the decryption key SK Iu i ,ω . It checks if the secret key SK Iu i ,ω related to the attribute set ω satisfies the access policy τ . If yes, then the algorithm chooses the smallest subset ω that satisfies τ and proceeds as follows:

Z (1) = C (2) aj ∈ω ê(D (2)
j , C (4) j,
î ) = ê(g, g) βs aj ∈ω ê(g

x-β x j , g xj s î ) = ê(g, g) xs Z (2) = ê(C (3) , D (3) ) λu • Iu j ∈ ê(C (5)
i , D (4) ) λu j = ê(g s , g yP (0) )

Z (3) = ê(D (1) , C (3) ) • Z (1) • Z (2) = ê(g, g) αs
The decryption algorithm recovers the message m as: m = C (1) ⊕ H 1 (Z (3) . Note:λ i 's in Z (2) are Lagrange coefficients λ i = j =i -j i-j . A revoked user will not be capable to compute Z (2) , hence it cannot recover the message m.

Security Proof

Theorem 1. Suppose the DBDH assumption holds. Then no polynomial adversary can break the CP-ABBE scheme with non-negligible advantage. The complete security proof will be provided in the full version of this paper.

Conclusions

In this work, we present a ciphertext-policy attribute-based broadcast encryption scheme. The proposed scheme has the capability to revoke users from a broadcasted message. The scheme could be used to revoke a limited number of users with fixed and small ciphertext size. The security has been proved under DBDH assumption.


de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Mobile Identity Management

Jaap-Henk Hoepman TNO, Groningen, The Netherlands Radboud University Nijmegen, The Netherlands jhh@cs.ru.nl

Abstract. Identity management consists of the processes and all underlying technologies for the creation, management, and usage of digital identities. Business rely on identity management systems to simplify the management of access rights to their systems and services for both their employees and their customers. Users may benefit from identity management to simplify logging in to websites and computer systems (single sign-on), as well as streamlining management of their personal information and preferences (user centricity).

Current systems for identity management only partially achieve these goals, and still suffer from several security, privacy and usability issues.

We will discuss how personal mobile devices (like mobile phones and PDA's) can be used to overcome this 'identity crisis', to increase the security, privacy and usability of identity management systems.

Short Biography. Jaap-Henk Hoepman is senior scientist computer security, privacy and identity management at TNO (the Dutch Organisation for Applied Scientific Research) and associate professor at the Radboud University Nijmegen, the Netherlands. His research into information security and cryptographic protocols is inspired by practical problems. He focuses on the design of secure and privacy friendly protocols for the Internet of Things. Apart from that he studies privacy and identity management. He speaks on these topics at national and international congresses and publishes papers in (inter)national journals. He also appears in the media as security expert, and writes about his research in the popular press. He is actively involved in the public debate concerning security and privacy in our society.


Kurt Dietrich

Johannes Winter

Granit Luzhnica

Siegfried Podesser
email: siegfried.podesser@iaik.tugraz.atgranit.luzhnica@student.tugraz.at

Johannes Dietrich

Winter

Implementation Aspects of Anonymous Credential Systems for Mobile Trusted Platforms

Anonymity and privacy protection are very important issues for Trusted Computing enabled platforms. Protection mechanisms are required in order to hide activities of the trusted platforms when performing cryptography based transactions over the Internet, which would otherwise compromise the platform's privacy and with it the users's anonymity. In order to address this problem, the Trusted Computing Group (TCG) has introduced two concepts addressing the question how the anonymity of Trusted Platform Modules (TPMs) and their enclosing platforms can be protected. The most promising of these two concepts is the Direct Anonymous Attestation (DAA) scheme which eliminates the requirement of a remote authority but includes complex mathematical computations. Moreover, DAA requires a comprehensive infrastructure consisting of various components in order to allow anonymous signatures to be used in real-world scenarios. In this paper, we discuss the results of our analysis of an infrastructure for anonymous credential systems which is focused on the Direct Anonymous Attestation (DAA) scheme as specified by the TCG. For the analysis, we especially focus on mobile trusted platforms and their requirements. We discuss our experiences and experimental results when designing and implementing the infrastructure and give suggestions for improvements and propose concepts and models for -from our point of view -missing components.

Introduction

The anonymity of trusted platforms is a crucial topic in Trusted Computing. The use of common digital signature schemes requires complex public-key infrastructures and allows adversaries to track and identify certain signing platforms. In order to address this problem, the TCG has introduced two schemes to protect the anonymity of Trusted Platform Modules (TPMs) and with it the anonymity of their host platforms and users. One of these schemes -the Privacy CA (PCA) scheme -relies on standard public-key infrastructures and performs the anonymization step in collaboration with a trusted third party. The other, from our point of view, more promising scheme is Direct Anonymous Attestation (DAA) which eliminates the requirement of a remote authority, but requires complex mathematical computations. Although large effort has been put into researching the efficient generation of anonymous signatures, little attention has been paid to the supporting infrastructures which are essential components for deploying anonymous credential technology in the field. When designing and developing infrastructures for the DAA scheme, one faces several obstacles.

The first problem is that different protocols exist. Different DAA schemes have been proposed, for example in [START_REF] Brickell | Direct Anonymous Attestation[END_REF], [START_REF] Mitchell | Direct Anonymous Attestation in Context[END_REF] and [START_REF] Chen | On the Design and Implementation of an Efficient DAA Scheme[END_REF]. These schemes are either variations of the original RSA-based DAA protocol or schemes based on different cryptographic primitives. Second, different clients have to be supported. DAA client platforms may range from server systems and desktop PCs, down to mobile phones or smart-cards. Each of these platforms has different processing capabilities and, therefore, different requirements on the used DAA scheme. The third obstacle is credential revocation. It is easy to see that revoking an anonymous credential is a complex task. Common approaches either involve revocation authorities or rogue tagging mechanisms. However, rogue-tagging typically implies drawbacks like high resource requirements that may not be available on mobile platforms. Suitable infrastructures that take all these issues into account are missing. In order to address these problems, we have designed and implemented a DAA infrastructure. Therefore, we introduce a Join protocol specification that supports the different variations of DAA schemes mentioned before. Moreover, we introduce an online revocation check mechanism that allows us to move the rogue tagging check from the client to a trusted third party.

Although research has been done focusing on specific problems of DAA on mobile platforms ( [START_REF] Dietrich | Anonymous Credentials for Java Enabled Platforms: A Performance Evaluation[END_REF], [START_REF] Wachsmann | Lightweight Anonymous Authentication with TLS and DAA for Embedded Mobile Devices[END_REF]) investigations of the feasibility of DAA with all its aspects in the sense of a complete infrastructure with revocation etc. are missing. However, such infrastructures are especially interesting when taking new applications of DAA in the mobile world, such as anonymous authentication via NFC [START_REF]Radio Frequency Identification: Security and Privacy Issues -6th International Workshop, RFIDSec 2010[END_REF] or transport layer security (TLS) [START_REF] Dietrich | Anonymous Client Authentication for Transport Layer Security[END_REF] into account. Therefore, we provide an investigation of the practicability and requirements of DAA and its infrastructure for mobile platforms. For our analysis, we have chosen the RSAbased DAA scheme as specified by the Trusted Computing Group (TCG) [START_REF]Trusted Computing Group: TCG Software Stack (TSS) Specification Version 1.2 Level[END_REF] as this is currently the only existing public version of a DAA scheme which is standardized by a public committee.

Related Work

Few publications can be found that address the topic of infrastructures for anonymous credentials. The most important one is the paper from Camenish et. al. [START_REF] Camenisch | Design and implementation of the idemix anonymous credential system[END_REF] which deals with the design and the implementation of the idmix credential system prototype. The publication addresses protocols and credentials used in the idmix system which is related to DAA.

The remainder of this article is organized as follows. We discuss the overall architecture of our implementation and give detailed results of the server and client components where we put special emphasis on the rogue tagging mechanism. Moreover, we discuss our proposed protocol with support for different types of clients and different schemes and we address the topic of credential revocation by proposing a modification of the online-certificate-status-protocol (OCSP).

Overview

The Direct Anonymous Attestation (DAA) scheme is a mechanism to provide trusted information to a challenger about a platform's integrity without compromising the platform's privacy. This can be achieved by applying an anonymous group signature on the attestation information provided by the TPM.

The DAA model involves three parties: the issuer or group manager, the signer (or client) and a verifier. The issuer manages the group and controls which platform may enter the group and creates a group credential for the entering platforms. Moreover, the issuer defines and publishes a set of group parameters which allows verifiers to validate signatures that have been created by group members.

Briefly summarized, an anonymous attestation scenario works as follows: on startup, the client platform which consists of a host (i.e. PC platform) and a TPM, executes a TCG based authenticated-boot and creates measurement values of the loaded software image, which are then stored in the TPM. The TPM now contains the current configuration of the platform. When the platform wants to prove this configuration to a remote platform, it generates a signature on these hash values with a so-called attestation key. The attestation key is a special RSA key which is created and used inside the TPM. The TPM ensures that the private parts of attestation keys acan not leave the TPM and that attestation keys are only used for signing configuration values. The platform sends the signed configuration values to the remote verifier which is then able to validate the local platform's configuration with the public part of the attestation key. Moreover, the remote platform can trust that the signature was generated in a genuine TPM by validating a DAA signature on the public attestation key.

For each attestation process, a new key has to be created and certified. This is where the DAA signature comes into play. Instead of sending the public-key to a Privacy CA every time, the TPM can locally certify its attestation key using an anonymous signature on the key. When using anonymous signatures to certify attestation key, the TPM first creates a temporary RSA key-pair. The public part of this temporary RSA key is locally signed with a DAA signature. Hence, the TPM is able to locally certify its temporary attestation key. This temporary attestation key is then used to create a signatures on the configuration values. When validating a signature over the configuration values, the remote verifier first has to verify the DAA group signature on the temporary attestation key. Before a TPM can create DAA signatures, it has to generate a private DAA-key f and execute the Join protocol with the group manager in order to receive a group-credential for f. Once the TPM has joined a group, it is able to generate DAA signatures to locally certify public-key held by the TPM.

In order to analyze the efficiency of the scheme on mobile platforms, we developed an infrastructure that provides issuer, client and verifier components. Our DAA infrastructure is based on a client-server architecture consisting of different components which include an issuer, a trusted-third party (TTP) for long term certification of the issuer's public-key, a DAA status responder and a certificate authority (CA) that issues credentials for the TTP, the responder and the revocation authority. Moreover, the CA issues credentials for all players in the infrastructure to enable end-point authentication for the transport layer security (TLS) endpoints. Furthermore, it provides the corresponding revocation information for all issued certificates. All communication is established using the TLS protocol in order to provide authenticity of the endpoints and confidentiality and integrity of the transmitted data. Although our design and proposed protocol aims at supporting different clients, our current implementation focuses on desktop systems and mobile phones.

The Issuer

The issuer is responsible for generating the group credentials and for issuing the credentials to client platforms. Before a client can join the group, it has to be authenticated, allowing only authorized clients from joining the group. Moreover, the issuer has to perform a rogue and revocation check of the client's TPM. Therefore, the issuer maintains a list with Endorsement Keys (EKs) for all the clients, which are allowed to join. However, there are some cases when the issuer would allow arbitrary clients to join. Therefore, we introduce two modes of operation for the issuer:

1. Public Access mode -Clients can join even if their EK is not on the issuer's list. Their key will be put on the list on the fly during execution of the join protocol in order to be able to monitor who is in the group. 2. Private Access mode -Only clients that have an authorized EK on the issuer's list can join and request the corresponding group credentials from the issuer.

In our approach, we focus on the DAA protocol discussed in [START_REF] Mitchell | Direct Anonymous Attestation in Context[END_REF] which is available on many different platforms [START_REF] Bichsel | Anonymous credentials on a standard java card[END_REF], [START_REF] Sterckx | Efficient Implementation of Anonymous Credentials on Java Card Smart Cards[END_REF], [START_REF] Dietrich | Anonymous Credentials for Java Enabled Platforms: A Performance Evaluation[END_REF].

Issuer Setup Protocol Before the issuer can start to operate, it has to generate its group credentials which is done during the setup phase where all parameters required for the issuer are generated. The parameters include values for exclusive use by the issuer (e.g. issuer's private key) and public values like the issuer's public-key. The public values also include a non interactive proof showing that the issuer's parameters have been generated correctly. Parameters are generated according the following protocol:

1. The issuer chooses a modulus n with length l n and primes p, q, p ′ , q ′ such that: n = pq, p = 2p ′ + 1, q = 2q ′ + 1 2. Next, it chooses random integers x 0 , x 1 , x z ∈ [1, p ′ q ′ ] and x ∈ [1, n] which will be used to generate the proof and computes S = x 2 mod n, Z = S xz mod n, R 0 = S x0 mod n and R 1 = S x1 mod n 3. The issuer produces a non-interactive proof that S, Z, R 0 and R 1 are computed correctly. (see [START_REF] Brickell | Direct Anonymous Attestation[END_REF] for more details) 4. It generates rouge tagging parameters by choosing random primes ρ, Γ and

γ ′ ∈ R Z * Γ , satisfying Γ = rρ + 1 such that r is an integer, ρ r, 2 lΓ -1 < Γ < 2 lΓ , 2 lρ-1 < ρ < 2 lρ and γ ′(Γ -1)/ρ ̸ ≡ 1 mod (Γ ).
Finally, the issuer calculates γ = γ ′(Γ -1)/ρ mod Γ 5. The public-key of the issuer is the tuple (n, S, Z, R 0 , R 1 , γ, Γ, ρ) and the private-key is the tuple (p ′ , q ′ ).

In addition to the public-key, the issuer computes a proof that the parameters of the public-key are generated correctly. This proof can be used to verify that the Z, R 0 , R 1 ∈ ⟨S⟩ and S ∈ QR n parameters are properly constructed. As the verification of the public-key proof is time and resource consuming, it may be delegated by a client to a trusted-third-party which verifies the proof and signs the group-key, thereby attesting the authenticity and the correctness of the key.

The Client

In our scenario, the mobile phone is a Java 2 MicroEdition (J2ME) application which runs on a mobile phone. These mobile platforms can be equipped with dedicated micro-controllers or software based TPMs as discussed in ([9], [START_REF] Dietrich | An Integrated Architecture for Trusted Computing for Java Enabled Embedded Devices[END_REF], [START_REF] Dietrich | An Integrated Architecture for Trusted Computing for Java Enabled Embedded Devices[END_REF]).

After computing the secret key f , the client may execute the join protocol with the issuer in order to obtain its credentials. Once the client has received the credentials, it is able to create DAA signatures on behalf of the group. Any verifier can verify these signatures with the issuer's -respectively the group'spublic-key. Prior to joining the group, the client has to verify the public-key of the issuer. It is very important to perform this step, since improperly generated issuer-parameters can cripple the anonymity protection of the DAA scheme [START_REF] Brickell | Direct Anonymous Attestation[END_REF]. Our client application delegates the computationally expensive parts of the issuer proof verification to a trusted third party (TTP). The steps done by the trusted third party are roughly: The TTP verifies the issuer's proof that Z, R 0 , R 1 ∈ ⟨S⟩ and that S is a quadratic residue mod (n). Then the TTP verifies that rouge tagging is set up correctly by checking whether ρ and Γ are primes, ρ | (Γ -1), ρ (Γ -1)/ρ and γ ρ ≡ 1 (mod Γ ). Finally, it checks if all parameters of the issuer's public-key have the required lengths.

Following these steps, the client has proof that all the issuer-parameters are computed correctly which implies that the security properties for the client still hold [3, page 9].

The Join Protocol

During the Join protocol, client and issuer exchange parameters. Some of these parameters are only temporary parameters which are used to derive other pa-rameters and others are credentials which are finally issued by the issuer to be stored as client-key and group credential. Moreover, we have modified the protocol in order to support different (i.e. future versions and devices that cannot rely on a trusted host platform like smart-cards) versions of the DAA scheme. The Join protocol works as follows:

1. The client sends the join command, version and hash of its public EK.

U = R f0 0 R f1 1 S ν ′ as well as a U = H(U ∥n e ) -The client sends ζ I = (H Γ (1∥bsn I )) (Γ -1)/ρ to its TPM.
-The TPM verifies that ζ ρ I ≡ 1 mod Γ holds and computes

N I = ζ (f0+f12 l f ) I
-Finally the client sends U, cnt, N I and a U to the issuer. 5. Upon reception of a U , the issuer computes a ′ U = H(U ∥n e ) -the client has proved that it is the owner of the EK if and only if a ′ U = a U holds. 6. Next, the issuer checks for the rogue tagging using N I (see section 4). 7. The issuer generates a random nonce n i of length l h and forwards it to the client. 8. The client needs to prove knowledge of f 0 , f 1 and ν ′ to the issuer.

-The TPM generates random numbers r f0 , r f1 of length

l f + l Φ + l H and r ν ′ of length l n + 2l Φ + l H . It then computes Ũ = R r f 0 0 R r f 1 1 S r ν ′ mod n -Client sends c h = H(n∥R 0 ∥R 1 ∥S∥U ∥ Ũ ∥n i )
to its TPM -The TPM generates a random nonce n t of length lΦ and computes the final hash c and values s f0 , s f1 , ν ′ as: c = H(c h ∥n t ), s f0 = r f0 +sf 0 , s f1 = r f1 +sf 1 and s ν ′ = r ν ′ + s • ν ′ -The client forwards c, n t , s f0 , s f1 , ν ′ to the issuer. 9. The issuer verifies the computations done by the client and its TPM.

-s f0 , S f1 must be of length

l f + l Φ + l H + 1. s ν ′ must have the length l n + 2l Φ + l H + 1. -The issuer computes Û = U -c R s f 0 0 R s f 1
1 S s ν ′ mod n and the proof if and only if c = H(H(n∥R 0 ∥R 1 ∥S∥U ∥ Û ∥n i )∥n t ) holds. 10. After verification of the client proofs, the issuer constructs a Camenisch-Lysyanskaya (CL) credential.

-The issuer first generates a random number ν of length l ν and calculates ν ′′ = ν + 2 lν -1 . Then the issuer selects a random prime e ∈ [2 le-1 , 2 le-1 + 2 l ′ e -1 ] and computes: Φ(n) = (p -1)(q -1) and d = e -1 mod Φ(n). -The issuer now calculates A = ( Z U S v ′′ ) d mod n and sends it to the client.

11. The client challenges the issuer to prove correct computation of A. In order to do so, the client sends a nonce n h of length l Φ . 12. The issuer generates a random r e ∈ [0, p ′ q ′ ] and computes à = ( Z U S v ′′ ) re mod n, c ′ = H(n∥Z∥S∥U ∥A∥ Ã∥n h ) and s e = r e -c ′ d -The response (c ′ , s e , A, e, ν ′′ ) is forwarded to the client. [START_REF] Sterckx | Efficient Implementation of Anonymous Credentials on Java Card Smart Cards[END_REF]. The client verifies the issuer's response and obtains its CL credential.

-To verify the issuer's response the client computes  = A c ′ ( Z U S v ′′ ) se mod n and c ′′ = H(n∥Z∥S∥U ∥A∥ Â∥n h ). The response is valid if and only if c ′′ = c ′ holds and if e is prime with e ∈ [2 le-1 , 2 le-1 + 2 l ′ e -1 ]. -Using ν ′′ the TPM computes ν = ν ′ + ν ′′ and then stores (f 0 , f 1 , ν ′′ ) as private-key.

Prototype Implementation of the Join Protocol

No defined application protocol for the DAA join step has been defined either by the authors of [START_REF] Brickell | Direct Anonymous Attestation[END_REF] or by the TCG. The TCG Trusted Software Stack specification includes provisions for basic support of the DAA join and sign commands of the TPM [START_REF]Trusted Computing Group: TCG Software Stack (TSS) Specification Version 1.2 Level[END_REF]. The basic DAA support specified in [START_REF]Trusted Computing Group: TCG Software Stack (TSS) Specification Version 1.2 Level[END_REF] only consists of an API interface without any kind of provisions for the application level network protocols required to execute the DAA join sequence between an issuer and a client platform.

Trusted Channel between Issuer-Service and Clients

For our prototype implementation, we developed a simple application protocol which allows the client to communicate with a DAA issuer over a TLS secured network connection. The application protocol discussed in this section describes a working prototype implementation which is intended to encourage a broader discussion of how a practical DAA issuer network service could look like.

The application protocol used by our prototype is a simple request response protocol based upon a series of simple ASN.1 messages exchanged over a trusted channel. In our prototype system, this trusted channel is established using a TLS protected TCP/IP network connection. Using TLS server authentication enables us to authenticate the DAA issuer service against the host willing to join the DAA group. The host can resort to standard PKI methods for verifying the identity of the DAA issuer based on its server certificate. On mobile platforms, the online certificate status protocol (OCSP) can be employed to delegate the possibly resource and communication intensive certificate validation step to a trusted third party.

Since different platforms have different strengths and computation powers and our implementation of the issuer should serve all of them, we support different versions of commands. As you can see from the join process section, the first message to be sent from the host to the issuer is the command message. This message includes the command which in that case is "join" and also the version of the join protocol.

In order to support multiple platforms and protocol we implement different forms of ASN.1 messages and differ them based on the used version. The first version would be e.g. "1.0" and the second one "1.1". Hence, whenever a client which can not handle the first option wants to join, it simply specifies which version it can handle or rather which it understands and then the issuer interacts with it in an appropriate form. Additionally the versioning scheme allows us to implement protocol changes in future while maintaining compatibility with existing clients.

Rogue Detection and Revocation

In order to detect and prevent compromised TPMs from joining or from signing messages, a rogue and revocation detection mechanism must be used. As mentioned in [START_REF] Brickell | Direct Anonymous Attestation[END_REF], if the secret of a TPM is revealed it is tagged as rogue and the values f 0 and f 1 are put on a blacklist. In order to check whether a TPM is rogue or not, the following steps have to be performed:

The host and the issuer separately compute

ζ I = (H Γ (1∥bsn I )) (Γ -1)/ρ . Then the client's TPM computes N I = ζ (f0+f12 l f ) I
and sends N I to the verifier. Now the verifier checks for all pairs (f 0 , f 1 ) on its blacklist whether

N I = ζ (f0+f12 l f ) I
holds, if a pair satisfying the equation is found the TPM is considered to be rogue.

The same procedure is used during the sign and verification process of a signature, allowing the verifier to check whether the TPM is rogue or not. Alternatively, the ζ V (ζ I ) can be chosen at random. In this case, ζ serves only for rogue detection. But if we derive it from the bsn, we would have the same ζ for the same bsn, and it would be possible to link different actions of the platform.

In case the issuer acts as verifier and uses the same bsn, the platform may be identified and its transactions may be linked, since ζ V = ζ I and can be linked to the identity, which should not be the case. The authors of [START_REF] Smyth | Direct Anonymous Attestation (DAA): Ensuring Privacy with Corrupt Administrators[END_REF] address this problem and propose a simple solution by changing the calculation of ζ V to:

ζ V = (H Γ (0∥bsn V )) (Γ -1)/ρ
In this case, the ζ V ̸ = ζ I so it is not possible to link the identity of the platform to the actions. The biggest problem here is how to gather information in order to assemble a blacklist. In [START_REF] Brickell | Direct Anonymous Attestation[END_REF][Page 14] it is mentioned that when a cer- tificate (A,e,ν) and the values f 0 and f 1 are found, they are tested whether

A e R f0 0 R f1 1 S ν ≡ Z (mod n) holds.
If so, they are put on the blacklist. However, there is no mechanism to get the parameters f 0 and f 1 . If somebody is able to extract them out of a TPM and uses them to impersonate another party there is no way to distinguish between the original platform and the impersonating platform. It is unlikely that the impersonator will publish the extracted secrets. Moreover, there is no way that a platform can check if its secrets have been extracted. Even if the owner of the platform somehow gets the information that the platform has been compromised, the secrets can not be extracted from the TPM in order to perform a self-revocation. There is no command for that action because the secret is supposed to never leave the TPM even if it is requested by the user [START_REF]TPM Main Specification Level 2 Version 1[END_REF] (for example, if the user wants to revoke the DAA credential if he notices that the TPM keys are compromised). The only way a user can delete its credentials is by performing a take-ownership where new secrets (f 0 , f 1 ) will be generated. However, if he did not extract and publish the old secrets, someone might use these secrets for signing on behalf of the group and there is no way to detect it since the pair (f 0 , f 1 ) is not in the blacklist. Hence, the extracted credentials cannot be revoked and remain valid.

Online Credential Revocation Check

In order to shift the computational effort from the mobile client to a more resourceful platform we introduce a modification of the Online Certificate Status Protocol (OCSP) [START_REF] Myers | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol -OCSP[END_REF]. OCSP allows to retrieve the status of a certificate from an online source, the OCSP responder. To achieve this, the OCSP request structure contains the CertID field consisting of hash algorithm identifier, hash of the issuer's name and the issuer's key, and the serial number of the requested certificate, we want to obtain the status of. A status may be good, revoked or unknown. A status may be good, revoked or unknown. We slightly modified the RFC2560 CertID structure to include the basename, the pseudonym ζ and a reference the issuer's public-key, which is used to obtain the group parameters. Figrue 1 illustrates the information flow in our modified variant of the OCSP protocol.

Fig. 1: Online Credential Status Reporting

Using the information provided in the modified CertID structure the responders checks if its black-list contains ζ and returns an appropriate OCSP status response. The authenticity and inbtegrity of the OCSP response can be verified using standard public-key signatures as discussed in RFC2560 [START_REF] Myers | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol -OCSP[END_REF].

Experimental Results

In this section, we discuss the results and setup of our infrastructure implementation. We tested the performance of the server (issuer) on a Sony Vaio VGN-NR11Z/S notebook and the client on a Nokia 5800 Express Music cell phone, a Frescale i.MX51 development board and an MSI U135 netbook. Table 1 shows the main characteristics of the testing devices. Overall performance evaluation of the DAA setup was done with the Sony Vaio notebook configured as server (issuer) and the Nokia mobile phone configured as client (host). The Freescale development board an the MSI netbook did not take part in the overall client/server performance evaluation. Instead the latter two devices were used to evaluate performance impact of using different Java virtual machine configurations as discussed later in section 5.2.

Overall client/server system performance

In the client/server performance test setup, both test devices were placed on the same local area network (LAN). Both the Nokia 5800 Express cell phone and the Sony Vaio notebook were connected to the test LAN using a wireless LAN access point. For this test. the issuer component was executed on a SUN Java 1.6 virtual machine configured with its installation default settings for Windows XP.

Modulus length

Join Performance Results

After the initial client and the server setup has been performed, the client can do the DAA join step. The performance results for joining a DAA group with empty blacklist shown below in table 2a include the network communication overhead. Since communication is done over network the results may vary in different connections with different strengths. These results were gained when performing joining with an empty blacklist. Hence, there is no rogue TPM on the list. for each pair (f 0 , f 1 ) on its blacklist. A single N I computation is very expensive, but overall cost increases linearly with the size of the blacklist. The more TPMs are on the list, the longer it takes to prove for any TPM whether it is rogue or not and the longer it takes to finish the join protocol. We measured the join process performance considering the effects of the rogue detection process. The tests were performed in a way that after each Join a new pair (f 0 , f 1 ) is inserted into the blacklist for the next Join. In table 2b we show the time required for a join with rogue TPMs in the blacklist. The length of modulus for these measurements was 2048. As visible in figure 3a, there is a nearly linear dependency between the number of TPMs on the rouge list and the total time required for the joining process. Given those results the amount of time required for each additional rouge TPM corresponds to approximately 14.7 milliseconds or equivalently to 1.47 seconds per 100 rouge TPMs. The biggest problem is that the rogue detection has to be performed when verifying signatures. Since a client should be able to verify signatures, it also should be able to check for rogue TPMs. We measured the execution time of the rogue detection depending on the number of TPMs in the blacklist on the Nokia mobile phone. The corresponding results can be found in table 2c and figure 3b.

Rogue Detection Performance

Assuming medium to large blacklist sizes it clearly becomes evident that rouge detection is an expensive operation which might not be feasible on batterypowered devices like mobile phones. Moreover the level of user acceptance for signature verification processes in the order of minutes is at least questionable.

Proof Verification As previously discussed, a proof that the parameters of the issuer's public-key are generated correctly, should be generated by the issuer. In order to prove that Z, R 0 , R 1 ∈ ⟨S⟩, a total of 3 • 160 = 420 relatively expensive calculations (verifications of bit-commitments) are required. Each of these calculations includes a modular exponentiation with an exponent ∈ [1, p ′ q ′ ] and also a modular multplication. The proof verification step requires significant compu-tational resources and takes significant time (≈ 99.44 s) even on the Sony Vaio platform used as issuer in our other experiments. On the Nokia mobile phone platform the verification time is far beyond any acceptability bounds (≈ 2399.24 s). The computing power of Java applications on mobile devices is clearly insufficient to verify this kind of proof. A viable solution for this case would be to delegate the verification step to a trusted third party.

Performance impact of different Java virtual machines

In the previous section we considered performance characteristics of a model realization of a DAA infrastructure based on a mobile phone acting as host and a notebook playing the part of the issuer. In this section, we briefly evaluate the impact of the Java virtual machine on the performance of the client side join process. In contrast to section 5.1 we ignore any server side computations and network overhead. Measurements shown in this section were performed using a special version of the client application which just instruments the client-side computations. We tested four combinations of Java virtual machines and just-in-time compiler settings which are intended to model typical JVMs found on mobile platforms. In order to produce comparable results for the tested platforms we used OpenJDK 1.6.0 as Java runtime environment. All cryptography related operations, including big number support was implemented with IAIK's JCE-ME 1 library. We tested the mixed-mode and interpreted Java VM configurations given in table 2. Figure 4 plots client-side computation times for repeated execution of the join process from within the same virtual machine instance. Table 2 gives average values for computation times. We decided to sample execution times for one particular VM configuration inside a loop from within a single VM invocation. This decision allows us to evaluate initial delays due to class loading and just-in-compilation. Three of the four VM configurations depicted in 4 exhibit relatively constant timing behavior with some minor jitter caused by other operating system processes interfering with our measurements. Only the Open-JDK "Shark" virtual machine exhibits great variations in join process execution times, caused by the relatively expensive just-in-time compilation steps done during the first few join process executions. As evident from figure 4 there is a huge performance gap almost in the range of one order of magnitude between Fig. 4: Join computation performance for different Java VM configurations the JIT (mixed mode) and the non-JIT (interpreted only) configurations on the Intel Atom platform. Interestingly the performance gap between the non-JIT and the JIT virtual machines on the ARM platform is by far smaller.

Conclusion

Based on the overall performance results of our implementation shown in section 5.1 we conclude that the most time-consuming part of the DAA protocol is the rogue detection. Even if rogue detection can be done relatively fast on desktop PCs and servers it still negatively affects the verification process which might be done on battery-powered mobile devices. Recalling from the test of the rogue TPMs, the time required by rouge checking process increases lineraly with the size of the black-list. For larger black-lists the time spent for rouge detection easily exceeds the actual signature verification time by orders of magnitude. The worst part is, that rouge detection has a big influence on mobile phones, even for small blacklists with sizes in the order of 30 rouge TPMs. Therefore, we conclude that delegating the validation of the rogue status to a third party is an unavoidable requirement.

Another open problem with rogue detection are the mechanisms and protocols used to report corrupted TPMs. The current implementation of DAA in TPM 1.2 implicitly anticipates compromise of the DAA private key as only revocation reason. Currently there is no method that enables a user to voluntarily report corruption of his platform without knowing the f value guarded by the TPM. Moreover the proof verification process required to check the validity of an issuer's public key requires impractical amount of storage and computational resources on mobile phones. This problem can be solved by off-loading the proof verification to a trusted third party. Finally the results from section 5.2 clearly show the impact of the choice of Java virtual machine on the performance of our purely Java-based prototype implementation.

Fig. 2 :

 2 Fig. 2: Join and rouge detection times

  As discussed earlier the issuer has to compute a rouge tagging value N I = ζ (f0+f12 l f ) I

Fig. 3 :

 3 Fig. 3: Join and verify performance

1

  See http://jce.iaik.tugraz.at/sic/Products/Mobile-Security/JCE-ME join computation time [s] Test run ARM Cortex-A8, OpenJDK Zero VM ARM Cortex-A8, OpenJDK Shark VM Intel Atom 450, OpenJDK Client VM (interpreted) Intel Atom 450, OpenJDK Client VM (mixed mode)

  2. The issuer receives the join command and tests if the requested version and DAA scheme are supported. When operating in Private Access mode (see section 2.1) the issuer now tests if the client's EK hash is on the list of allowed EK hashes. Regardless of the access mode the issuer requests the client to transmit its public EK. 3. The issuer chooses a random n e of length l Φ and encrypts it with the client's public EK. The encrypted n e and the issuer's basename bsn are sent back to the client. 4. The client needs to show proof of possession of the public EK -The client's TPM decrypts n e , picks a random ν ′ of length l n + l Φ and computes:

Table 1 :

 1 Testing devices (Roles: H = Host, I = Issuer)

	Device	Role CPU	Clock Freq. RAM OS
	Nokia 5800 Express Music H ARM11	434 MHz 128 MB Symbian 60v5
	Sony Vaio VGN-NR11Z/S I Intel Core 2 Duo	2.0 GHz 2 GB Windows XP
	i.MX51 EVK	H ARM Cortex-A8	800 MHz 512 MB Linux (Debian)
	MSI U135 netbook	H Intel Atom	1.2 GHz 1 GB Linux (SuSE)

Table 2 :

 2 Average timing values for client-side computations of the join process

Acknowledgments. We thank the anonymous reviewers for their helpful comments. This work has been supported in part by the European Commission through the FP7 programme under contract 257433 SEPIA.


Fuwen Liu

Hartmut Koenig

Cryptanalysis of a SIP Authentication Scheme

Keywords: SIP, VoIP, ECC, authentication, cryptanalysis

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

VoIP that delivers voice and multimedia over the Internet has gained large popularity nowadays. SIP is the dominant standard signaling protocol used for VoIP. It is defined by IETF (Internet Engineering Task Force) for the establishment, handling, and release of multimedia sessions among participants over the Internet [START_REF] Rosenberg | SIP -Session Initiation Protocol[END_REF]. Because of its flexibility and extensibility, SIP has been also adopted by 3GPP (Third Generation Partnership Project) as the signaling protocol for multimedia applications in 3G mobile networks as well [START_REF] Garcia-Martin | Private Header (P-Header) Extensions to the Session Initiation Protocol[END_REF]. Thus, SIP has become a key technology to support multimedia communications spanning wired and wireless networks.

Like any other services or protocols running in the hostile Internet environment, the SIP protocol is exposed to a wide range of security threats and attacks. Therefore, appropriate security measures have to be taken to protect SIP. The SIP protocol is based on request/response communication model like HTTP. This implies that a SIP client initiates a request on a SIP server and then waits for a response from the server. Mutual authentication between the SIP client and server is required to ensure the communication partner's identity is legitimate. SIP applies HTTP digest authentication [START_REF] Franks | HTTP Authentication: Basic and Digest Access Authentication[END_REF] by default to performing authentication. Unfortunately, it is a weak authentication that provides only one-way authentication (i.e. the client is authenticated to the server). This makes server spoofing attacks possible. Moreover, the scheme is vulnerable to the off-line dictionary attacks.

Several SIP authentication schemes have been proposed in order to overcome the security weaknesses of the original SIP authentication scheme. Yang et al. developed a secure SIP authentication scheme whose security relies on the difficulty of the discrete logarithm problem (DLP) [START_REF] Yang | Secure Authentication Scheme for Session Initiation Protocol[END_REF]. However, this scheme is not well suited to wireless network settings, where the computational power of devices and the bandwidth of the wireless links are limited. Durlanik [START_REF] Durlanik | Sogukpinar: SIP Authentication Scheme Using ECDH[END_REF] et al. presented an efficient SIP authentication scheme using elliptic curve cryptography (ECC) technologies, whose security is based on the elliptic curve discrete logarithm problem (ECDLP). Durlanik's scheme requires less computing power and lower network bandwidth than Yang's scheme, since ECC can achieve the same security level as the conventional cryptosystems by using significantly smaller keys. In 2009, Wu et al. [START_REF] Wu | A New Provably Secure Authentication and Key Agreement Protocol for SIP Using ECC[END_REF] introduced another SIP authentication scheme based on ECC, and proved its security using the Canetti-Krawczyk (CK) security model [START_REF] Canetti | Analysis of Key-exchange Protocols and Their Use for Building Secure Channels[END_REF]. The authors stated that the scheme is resilient to various known attacks, such as off-line dictionary attacks, man-in-themiddle attacks, and server spoofing attacks. However, Durlanik's and Wu's schemes have been broken meanwhile. Yoon et al. showed that both schemes are prone to offline dictionary attacks, Denning-Sacco attacks, and stolen-verifier attacks [START_REF] Yoon | A Secure and Efficient SIP Authentication Scheme for Converged VOIP Networks[END_REF]. They proposed another SIP authentication scheme that is supposed to withstand the aforementioned attacks. In this paper we reveal serious security vulnerabilities of Yoon's scheme, and demonstrate that it is actually insecure against off-line dictionary and partition attacks.

The remainder of the paper is organized as follows. Section 2 forms the preliminary that gives a short overview on the original SIP authentication procedure and the basic knowledge of elliptic curve cryptography (ECC). Next, Yoon's scheme is briefly presented in Section 3. A detailed cryptanalysis of Yoon's scheme is performed in Section 4. Some final remarks conclude the paper.

Preliminaries

This section first introduces the SIP authentication procedure. Then the elliptic curve cryptography (ECC) is briefly reviewed.

SIP Authentication Procedure

SIP uses a challenge-response based mechanism for authentication that is identical to the HTTP digest authentication. Figure 1 illustrates the SIP authentication mechanism. Prerequisite for the SIP authentication is that password and username of each client in the domain have been configured securely in the SIP server in advance, i.e. the SIP server knows the password and the username of each client. Once a SIP server receives a request, it challenges the client with a nonce to determine the client's identity. The client acknowledges the SIP server with a response which is computed by using his/her password and the nonce. The server validates the legitimacy of the client by verifying the received response. The SIP authentication procedure is detailed as follows. The CHALLENGE generated by the server contains a nonce and realm.

The former offers replay protection, since it is fresh for each session. The latter is the host or domain name of the server, and used to remind the client which username and password should be applied.

Client → Server: RESPONSE (nonce, realm, username, response)

The client acknowledges the server with the message RESPONSE containing nonce, realm, username, and response. The response is computed as follows: response = H(nonce, realm, username, password), where H(•) is a one-way hash function.

4. After receiving the RESPONSE message, the server retrieves the password of the client by referring to the username. The server computes H(nonce, realm, username, password) and compares it with the received response. If they match the client is authenticated.

In the SIP authentication scheme the password is never sent across the network in clear text. So an attacker cannot receive the password directly from the captured messages. But the scheme is insecure against off-line dictionary attacks, where an attacker searches for a password matching the recorded message from the password dictionary. This kind of attacks is difficult to detect and to foil because the adversary only needs to eavesdrop on the protocol messages. With a network sniffer tool, such as Wireshark [START_REF]Wireshark[END_REF], an attacker may easily capture the message RESPONSE (nonce, realm, username, response), when the protocol is running over the Internet. He/she can randomly select a password pw` from the password dictionary and calculate the hash function H(nonce, realm, username, pw` ). If the hash value does not match the response the attacker can select another password and repeat the procedure till the correct password is found. This attack can be completed in a reasonable time because a human-chosen password has low entropy. For an 8-character password, its entropy is less than 30 bits (i.e. 2 30 possible passwords) [START_REF] Burr | Electronic Authentication Guideline[END_REF].

In the SIP authentication scheme the client is authenticated to the server, whereas the client does not validate the identity of the server. Thus, the scheme is prone to server spoofing attacks. An attacker can forge the identity of the server and sends a CHALLENGE to the client. The honest client always acknowledges the server with a correct message RESPONSE when receiving the message CHALLENGE. After receiving the RESPONSE message, the attacker can launch an off-line dictionary attack as stated above to crack the password of the client.

Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) [START_REF] Hankerson | Guide to Elliptic Curve Cryptography[END_REF] uses elliptic curves over a finite field F p to construct the cryptosystem, where p is a large prime that is usually larger than 224 bits considering security requirements. Let E be an elliptic curve over F p , so E can be expressed using the Weierstrass equation as follows:

y 2 = x 3 + ax + b (1)
where a, b ∈ F p , and 4a 3 + 27b 2 ≠ 0 (mod p). A pair (x, y), where x, y ∈ F p , is a point on the curve if (x, y) satisfies equation [START_REF] Rosenberg | SIP -Session Initiation Protocol[END_REF]. The point at infinity denoted by O is on the curve. The set of points in E over finite field F p , denoted as E(F p ), can be expressed as follows:

E(F p )={(x,y) ∈ F p 2 : y 2 =x 3 + ax + b}∪{O } (2)
The number of points in E(F p ) is defined as the order of the curve E over F p . It is denoted by #E(F p ), which can be estimated by the following formula using Hasse's theorem.

P+ 1-2√p ≤ #E(F p ) ≤ p + 1 + 2√p (3)

Key generation in ECC

The elliptic curve domain parameters (p,a,b,P,n,h) are public, where p is a large prime number, a and b specifying an elliptic curve over F p , P is a base point in E(F p ) and has prime order n, h is the cofactor which is equivalent to #E(F p )/n. A private key is an integer k which is randomly selected from the interval [1, n-1], and the corresponding public key is Q = kP. Given domain parameters and Q, it is hard to determine k. This is called elliptic curve discrete logarithm problem (ECDLP). The ECC systems usually employ the standardized domain parameters which can be found in [START_REF]Certicom Research: SEC 2: Recommended Elliptic Curve Domain Parameters[END_REF].

Encoding elliptic curve points

The public key Q = kP is a point on the curve E which satisfies equation [START_REF] Rosenberg | SIP -Session Initiation Protocol[END_REF]. The point Q can be represented by a pair of field elements (x Q , y Q ), where x Q is the xcoordinate and y Q is the y-coordinate. To reduce the bandwidth required by transmitting point Q can be encoded in a compressed format which is composed of the x-coordinate x Q and an additional bit β to uniquely determine the y-coordinate y Q , i.e. (x Q, β), where β=0 or 1. Therefore one x-coordinate x Q exactly corresponds to two y-coordinates y Q , when the compressed point format is used. The number of x Q denoted as #x Q can be determined by the following equation when using Hasse theorem:

(p+1)/2-√p ≤ #x Q ≤ ( p+1)/2+√p (4)

Yoon's Authentication Scheme

This section briefly reviews Yoon's scheme used for SIP authentication. It consists of three phases: system setup phase, registration phase, and authentication phase.

A) System Setup Phase

In set up phase client and server determine the common elliptic curve domain parameters (p,a,b,P n,h) to be used for the system.

B) Registration Phase

Client and server execute the following steps over a secure channel to complete the registration procedure.

Client → Server: username, H(pw)

The client hashes the password pw. The result H(pw) together with the username are sent to the server over a secure channel.

The server computes V= H(pw)⊕H(username,se)

, where se is a secret key of the server. Then username and V are stored in the verification database table.

Here, the purpose of V is to prevent stolen verifier attacks.

C) Authentication Phase

Fig. 2 illustrates Yoon's SIP authentication scheme. It proceeds as follows.

Client → Server: REQUEST (username, cP⊕H(pw))

The client chooses a random integer c from the interval [1, n-1], computes the public key cP, and encrypts it with the hash value of the password by using the bit-wise exclusive-or (XOR) operation ⊕. The result cP⊕H(pw) and username are sent in message REQUEST to the server.

Server → Client: CHALLENGE (realm, sP, H(username,sk))

After receiving the REQUEST message the server derives the public key cP of the client by computing cP⊕H(pw)⊕H(pw). Then it generates a random integer s∈[1, n-1], and computes a common secret session key sk = scP and a message authentication code H(username,sk). Finally the server responds to the client with the CHALLENGE message (realm, sP, H(username,sk)).

Client→Server: RESPONSE (username, realm, H(username realm,sk))

After receiving the CHALLENGE message client computes the secret session key sk = scP. Thereafter it calculates the hash value H(username,sk) and veryfies it with the received one. If both values are unequal, the client aborts the protocol. Otherwise, the server is authenticated to the client. The client computes the message authentication code H(username,realm,sk), and sends it in the RESPONSE message to the server.

Server: Client authentication

When receiving the RESPONSE message the server computes the message authentication code H(username,realm,sk) and verifies whether it is equal to the received one. If they are not equal the server rejects the request. Otherwise, the client is authenticated to the server. The server accepts his/her request.

Yoon's scheme provides protection against server spoofing attacks due to the mutual authentication between client and server. The authors claim that the proposed scheme is secure against a variety of attacks, including replay attacks, off-line dictionary attacks, man-in-the middle attacks, modification attacks, Denning-Sacco attacks, and stolen-verifier attacks [START_REF] Yoon | A Secure and Efficient SIP Authentication Scheme for Converged VOIP Networks[END_REF]. It should be noted that the prevention of offline dictionary attacks is the central security requirement for a password-based authentication scheme. If the scheme is vulnerable to off-line dictionary attacks this implies that the password of a client is disclosed to attackers and the whole scheme is broken.

Client Server

REQUEST

H(pw)←V H(username,se) cp←cp H(pw) H(pw) s

Security Vulnerabilities of Yoon's Scheme

This section shows that an adversary can launch off-line dictionary attacks or partition attacks on Yoon's scheme by using the captured REQUEST message. The partition attack [START_REF] Bellovin | Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks[END_REF] is a special variant of the off-line dictionary attack in which an attacker can partition the password space into a valid and an invalid part by analyzing the eavesdropped protocol messages. Yoon's scheme is vulnerable to off-line dictionary attacks when the public key cP is encoded in an uncompressed format and to partition attacks when the public key cP is encoded in a compressed format. We analyze them separately in the following.

Off-line Dictionary Attacks

It is trivial for an attacker to capture the REQUEST message which contains the username of the client and the masked public key cP⊕H(pw). We assume that the public key cP is encoded in an uncompressed format (x,y). Accordingly, the masked public key is represented by the format (x⊕H(pw), y⊕H(pw)). An attacker can perform off-line dictionary attacks as follows.

1. The attacker chooses a candidate password pw i from the password dictionary D and computes H(pw i ). The password space of the dictionary D is expressed as |D|.

2. The attacker computes x i = x⊕H(pw)⊕H(pw i ) and y i = y⊕H(pw)⊕H(pw i ) in order to get a guessed point (x i ,y i ).

3. The attacker examines whether the point (x i ,y i ) is on the elliptic curve E. In other words: he/she checks whether a pair (x i ,y i ) satisfies equation (1) as described in Section 2.2. If the point (x i ,y i ) is not on the elliptic curve E the attacker can eliminate the guessed password pw i from the dictionary D and return to step 1. He/she repeats the above steps until a point on curve E is found. Finally, the attacker outputs the correct password pw.

Note that the attacker can always verify whether a guessed public key is on the curve because the elliptic curve domain parameters (p,a,b,P,n,h) is public available for their standardizations. The program to perform an off-line dictionary attack can be described as follows. An attacker can identify the correct password pw in a reasonable time by running the program because the password space |D| is usually less than 2 30 as stated in [START_REF] Burr | Electronic Authentication Guideline[END_REF].

Partition Attacks

Alternatively, the public key cP can be encoded in a compressed format (x,β), where β is 0 or 1. Accordingly the masked public key cP⊕H(pw) is represented by (x⊕ H(pw),β). Note that the masked public key can not be interpreted as (x, β⊕H(pw)) because β is just one bit lang. An adversary can launch a partition attack as follows:

1. Choose a candidate password pw i from the password dictionary D and compute H(pw i ).

Compute x i = x⊕H(pw)⊕H(pw i

) and α =x i 3 +ax i +b in order to check whether x i is a valid x-coordinator in the curve E in the next step.

3. Check whether α is a square in F p . If so x i is a valid x-coordinator in the curve E accordingly, and put pw i into the valid password set VP. Otherwise, put pw i into the invalid password set UVP.

4. Return to step 1.

The program to run a partition attack can be described as follows.

Program partition attack

Lessons learned

The aforementioned cryptanalysis demonstrates that Yoon's authentication scheme is insecure no matter how the public key is encoded (uncompressed or compressed format). The main reason is that ECC public key is encrypted directly with the hash value of the password. This inherently provides an attacker the chance to rule the invalid passwords out. He/she can use a guessed password to decrypt the masked public key, and check whether the decrypted result satisfies the elliptic curve equation. Thus, the public key cannot be directly encrypted with the password for a secure password based authentication scheme in the ECC domain. There is a need to revise Yoon's scheme to eliminate the security vulnerabilities. Certainly this means developing a new SIP authentication scheme. Designing a password-based authentication protocol is a challenging task since such protocols are easy vulnerable to off-line dictionary attacks. After many years' research, IEEE has standardized several password-based authentication protocols [START_REF]Password-Based Public-Key Cryptography[END_REF]. Although they can not be directly applied to SIP authentication, their authentication framework can be adapted to the SIP authentication.

Final Remarks

User authentication is an essential function in the SIP framework. Several schemes have been proposed to overcome the shortcomings of the original SIP authentication scheme. Yoon's authentication scheme is the newest that claims to be secure against various attacks. In this paper, we have demonstrated that Yoon's scheme is vulnerable to off-line dictionary and partition attacks. An attacker can recover the correct password in a reasonable time. Further research efforts are needed for developing a secure and efficient SIP authentication scheme.

Fig. 1 .

 1 Fig. 1. SIP Authentication Procedure 1. Client → Server: REQUEST The client invokes a REQUEST (e.g. SIP REGISTER message) and sends it to the server (e.g. SIP Registrar) 2. Server → Client: CHALLENGE (nonce, realm)The CHALLENGE generated by the server contains a nonce and realm.The former offers replay protection, since it is fresh for each session. The latter is the host or domain name of the server, and used to remind the client which username and password should be applied.

Fig. 2 .

 2 Fig. 2. Yoon's SIP authentication scheme

  . So the possibility that x i is a valid x-coordinate in the curve E over finite field F p is in the range [1/2-O(1/√p ), 1/2+O(1/√p)] because the total number of points in E(F p ) is nearly p. As a result, the adversary can reduce the possible password space by roughly half by running the above program. This means |VP| ≈ ½|D|, where |•| denotes the password space. After capturing log 2 |D| SIP communication sessions and executing the above program, the adversary can recover the correct password. Such an attack is feasible in practice. For example, it needs only 30 SIP communication sessions to crack the password for an 8-character password whose password space is |D| ≈ 2 30 .

	Input: D, (x⊕H(pw),β);
	Output: VP, UVP;
	begin
	1: for i=0 to |D|
	2: {
	3:	pw i ←D; // select password pw i from D
	4:	compute H(pw i );
	5: 6:	x i = x⊕H(pw)⊕H(pw i ); α=x i 3 +ax i +b;
	7:	if (α is a square) VP←pw i ;
	8:	else UVP←pw i ;
	9: }
	end.
	As stated in equation (4) of Section 2.2, the number of x i is in the interval [(p+1)/2-
	√p , ( p+1)/2+√p]