Digital Marketplace Security Requirements Alisdair McDiarmid
James Irvine
Institute for Communications and Signal Processing, University of Strathclyde, Glasgow, United Kingdom Email:
[email protected]
Institute for Communications and Signal Processing, University of Strathclyde, Glasgow, United Kingdom Email:
[email protected]
Abstract— Future generations of mobile systems will require novel call management strategies. The Digital Marketplace uses a market approach to manage network services, in which operators bid to provide connectivity to users. To operate successfully, the Digital Marketplace protocols must be designed securely. In this paper, we provide a threat analysis, and identify the security requirements to counter these threats.
I. I NTRODUCTION Now that the third generation of mobile telephony has been standardised and is in the deployment stage, researchers are looking to future directions in mobile network service provision. Beyond 3G, there are a huge number of new challenges to face. Users will desire access to more diverse services, which will cause increasing demands on the network. The trend to higher throughput access, with more data and video usage, will force a move to environment-optimised air interfaces and smaller cell sizes. Current call management architectures are insufficiently flexible to cope with these changes. One solution to this problem is to enable a free market in network services. The Digital Marketplace is a middleware which does this; it introduces the concept of a market channel across which auctions for service contracts are conducted[1]. This increased granularity of service provision allows each mobile user to receive network connectivity from many independent network operators. Correctly implemented, the Digital Marketplace creates a freely-operating market, which optimally and fairly allocates network resources. The move towards a radically different model of network access has many consequences. There will be a significant increase in the number of active participants, due to the required low cost of entry to the market on the supply side. Many of these new actors have no long-term contractual relationship with each other; therefore, they depend on the protocol to provide security against potential attackers. Presented here is a comprehensive threat
analysis of the Digital Marketplace, and subsequently a set of security requirements for future implementation. II. D IGITAL M ARKETPLACE O PERATION Consider a mobile user who wishes to initiate a communications session. The user’s terminal scans radio channels, seeking a marketplace channel broadcast signal. Once the market is located, the terminal transmits a session contract stating quality and price requirements. The market operator forwards this request to the user’s service provider, which then enters the marketplace to negotiate on behalf of the user. Registered network operators propose sealed bids on the contract tenders, and the service provider selects those which best match the requirements. Each network operator has a market reputation, based on how well it has previously fulfilled its contract requirements; this is taken into account in the selection process, and is updated after every session. The organisation of the Digital Marketplace is shown in figure 1. DIGITAL MARKETPLACE ASA
MULTI AGENT SYSTEM
NA NA
SA
QoS Contract: Bit rate Corruption Delay
SA Agent Interactions A MA M
NA
& Monitoring Parameters
NA
WLAN RADIO RADIO
Radio
RADIO
CELLULAR NETWORK
LMC
RADIO
RADIO
CELLULAR NETWORK
UNATTACHED TERMINALS
Fig. 1.
RADIO
RADIO
Digital Marketplace organisation
III. A DVERSARY M ODEL There are four participant classes in the Digital Marketplace: mobile user, service provider, network operator, and market operator. With the exception of the market operator, all participants must view all other participants as potential adversaries. As it has no direct financial interest in the operation of the market, we consider the market operator to be a neutral party in this model. Normally, there is no motive for it to execute attacks against other parties; nor does any other party have a motive to attack it. However, it is important to realise that the market operator should not be trusted because of this lack of motive: if it works in collusion with another party, it is in a position of power and should be regarded as potentially dangerous. We characterise each participant class according to the model proposed by Salter et al.[2]: in terms of their resources, risk tolerance, and objectives. This analysis provides a reference position from which we can analyse security threats, taking into account the capabilities and motivations of each attacker. Adversary
Resources
Risk
Objectives
Service Provider Network Operator Mobile User
High Medium Low
Medium Low High
Increase profit Harm competitors Cheaper service
TABLE I A DVERSARY C HARACTERISATION
Resources are estimated based on the size of each entity. There are likely to be relatively few service providers, due to the relatively high cost of attracting customers; comparatively, there will be a large number of network operators, as the barrier to market entry is designed to be low; but clearly, there will be more mobile users than network operators. Therefore, the service providers are likely to have the most financial resources, followed by the smaller network operators, and the individual mobile users. As the service provider is entirely dependent on its users for revenue, it has a great deal to lose if the user detects any unfair behaviour. However, this could plausibly be blamed on a billing error, and as long as the user is compensated, little is likely to be lost. In comparison, the network operator has only a very fleeting relationship with the user: if they are caught cheating, the Digital Marketplace’s reputation system will come into play, and the network operator will subsequently find it difficult to gain service contracts. Finally, other
mobile users have nothing to lose from manipulating the marketplace to their advantage, so their risk tolerance is high. The most likely objectives of each attacker are obviously financial. Service providers and network providers both want to increase profit; both could do so by colluding with other parties to manipulate the marketplace. Malicious mobile users want network services for free, or a reduced cost. From this model, it is clear that the least dangerous adversaries are likely to be mobile users, due to their low resources and unlikely motivation. The next most likely attackers are the network operators, who have higher resources and attainable objectives. Larger service providers have the most to gain, and the most resources with which to launch attacks. Therefore, the protocol security measures must be most effective against attacks from service providers. IV. T RUST In this analysis, we assume no real trust exists between any of the parties. In practice, the user may trust the service provider, but none of the other parties are likely to trust each other. This causes particular difficulties for the service provider, who does not trust the market operator, but depends on its honesty for the marketplace to function. The market operator is in the position of most power: it introduces all of the market participants to each other, and so is in a perfect position to execute man in the middle attacks. V. S ESSION O PERATION The Digital Marketplace protocol has been outlined in previous work[3]. The sequence of interactions in a bidding protocol session is given below, and in figure 2. A. Contract Tendering User Terminal Agent (UTA) makes a connection request to the Market Agent (MA). The request includes the network address of the User Home Agent (UHA), and a session contract. MA forwards the contract to the UHA, including the network location of the marketplace, and a list of network agents (NAs). B. Agent Migration UHA migrates a Service Provider Agent (SPA) with the contract to the marketplace. C. Contract Transformation SPA analyses the session contract, and creates a flow contract.
D. Flow Contract Forwarding
VI. S ECURITY T HREATS
SPA selects the most suitable bid(s), based on price, quality, and network operator reputation.
In order to define the requirements for secure operation of the marketplace, we must first determine the important threats which exist in a protocol session. Below is a representative set of such attacks; some minor attacks with equivalent consequences for security are omitted for clarity. Threats are listed here with reference to the bidding protocol stage; see section V for more details on each stage.
G. Bid Acceptance
A. Contract Tendering
SPA informs the winning NAs of acceptance. NAs confirm to the UTA that the flows are established.
1) Spoofing: An attacker makes a request to MA, using another user’s identifier and UHA location. The attacker receives service, while the other user pays. 2) Replay: An attacker re-transmits a previously-sent connection request. The first user receives unwanted service, and has to pay for it. 3) Collusion: MA could modify the session contract in transit, favouring network operators it colludes with. For example, the MA may know that its colluders can provide better quality-of-service than other network operators, and therefore increase the QoS requirements in the contract accordingly.
SPA then forwards copies of the flow contract to NAs. E. Bidding NAs calculate their commitments, and make appropriate bids. F. Bid Selection
H. Flow Release At the end of the session, the UTA releases each flow, informing the SPA and NA. I. Commitment Reporting NAs and users report commitment fulfilment to the MA. J. Reputation Update MA updates reputations.
B. Agent Migration
K. Session Termination NAs inform the SPA of end of session. SPA updates the UHA with billing information. SPA is removed from the marketplace by the UHA.
6
7
,
7
9
!
-
'
"
#
.
$
/
"
'
(
%
&
0
'
(
%
)
*
"
+
+
'
#
&
$
"
2
%
%
&
'
'
(
#
1
'
3
#
3
"
!
4
'
!
)
!
*
'
3
"
3
+
+
/
'
'
#
(
0
C. Contract Transformation 1) Collusion: SPA could modify the flow contract to favour network operators it colludes with. For example, the contract could have more strict quality-of-service requirements for non-colluding NAs.
:
8
1) Collusion: The list of NAs is given to SPA by MA; MA could exclude non-colluding NAs, therefore removing them from the bidding process.
%
&
D. Flow Contract Forwarding
1) Collusion: SPA could remove NAs from the list, restricting bids to those in collusion with it.
E. Bidding
Fig. 2.
5
Digital Marketplace protocol operation
1) Spoofing: Bids could be placed falsely on behalf of an NA, causing it to either lose reputation or money. 2) Modification: Bids could be modified in transit, by another NA, MA, or SPA. For example, the SPA may modify a bid, and later claim that commitments were not fulfilled, damaging the NA’s reputation. 3) Delayed Bidding: NAs could wait for other bids to be placed, checking their values, in order to outbid competitors.
4) Bid Repudiation: NA could place an aggressive bid, which may have quality of service levels it later finds it cannot meet. It may then claim that the bid was placed by an attacker, and refuse to supply service. Alternatively, it may supply service, and claim that the bid was modified by an attacker, so that failure to meet quality-of-service requirements is not punished.
These security threats can be countered by fulfilling certain security requirements. Therefore, if these requirements are met, the Digital Marketplace protocol will function securely. Each of the requirements deals with a particular class of security threat: these classes are authenticity, secrecy, collusion, and reputation.
F. Bid Selection
A. Authenticity
1) Collusion: SPA could ignore bids from noncolluding NAs, or simply favour bids from colluding NAs. As the bids are sealed, other actors in the marketplace would be unaware of this collusion.
The majority of the security threats identified above are related to falsification of identity. Therefore, one of the most important security requirements is for message authenticity. This requirement for authentication covers the spoofing, replay, and bid repudiation attacks. Therefore, recipients of messages must be able to determine the true sender, ensure that the message was not resent by a third party, and be able to demonstrate this authenticity so as to remove the possibility of bid retraction. Given the transitory nature of the marketplace, and the need for a short negotiation process, these requirements are nontrivial to meet. Requirement 1 The UHA and SPA must be able to authenticate messages purported to be sent by a mobile user; the SPA must be able to authenticate bids from NAs; the NAs must be able to authenticate bid acceptance from the SPA; and the NAs must be able to authenticate the user for flow release.
G. Bid Acceptance 1) Spoofing: An attacker could falsely inform the winning NA, or the UTA, of bid acceptance. This would lead to service being provided, paid for either by the network operator or the user, depending on the billing model. H. Flow Release 1) Spoofing: An attacker could falsely release the flow, leading to loss of connectivity for the end user. I. Commitment Reporting 1) Reputation Manipulation: An NA may claim that commitments are fulfilled, even if they were not. It may simply only report cases which would enhance or maintain its reputation. 2) Reputation Manipulation: The user may claim that commitments are not fulfilled, in order to purposely damage the network operator’s reputation. The motive for this may be collusion with other network operators. 3) Spoofing: A third-party attacker may claim that an NA’s commitments were not fulfilled, leading to a lowering of reputation. J. Reputation Update 1) Collusion: MA could collude with NAs to maintain a high reputation, even if commitments are not met. For example, the MA could disregard any commitment reports which would adversely affect the NAs’ reputations. K. Session Termination 1) Spoofing: An attacker could falsely report the session termination, leading to loss of connectivity.
VII. S ECURITY R EQUIREMENTS
B. Secrecy We assume that every actor can read all network traffic sent over the market channel. This exposes secrecy issues in several of the protocol stages. The sealed bid auction method has previously been selected due to short negotiation overheads[4]: without bid secrecy, this auction process cannot function. Requiring secrecy of messages defeats the delayed bidding attack. Requirement 2 All messages must be readable only by their intended recipients. C. Collusion Detection Many of the noted attacks on the Digital Marketplace all require collusion between two or more actors. Collusion is extremely difficult to engineer out of a system, but it can be detected. For the marketplace to operate freely, all possible colluding partnerships must be detectable: that is, between network operators, between network operators and the market operator, between network operators and the service provider, and between the service provider and the market operator.
Requirement 3 All marketplace participants must be able to detect collusion: between network operators; between the market operator and network operators; between the service provider and network operators; and between the service provider and the market operator. D. Reputation Finally, the reputation system can be manipulated by several parties. Network operators can game the system to inflate their reputation; service providers can misapply the network operators’ reputations, either to profit directly or to maintain collusion with an operator. Either of these actions adversely affects the operation of the marketplace; network operators and users will both lose out, and the market will not function fairly and efficiently. Requirement 4 The marketplace system must ensure that network operators’ reputations are updated and used fairly. VIII. F UTURE W ORK There are several directions for future research from this point. As explained above, we have assumed no trust relationships exist in the marketplace; however, it is possible that service providers, market operators, and larger network operators could form trusting contractual relationships. It would be interesting to examine the effect this would have on security in the marketplace protocol. Clearly, an open problem for research is in meeting the requirements specified here. There are several technical challenges to doing so, and in many cases compromises will have to be made. Several of the requirements have no obvious solution; meeting the requirements would be a technical achievement in itself, while also demonstrating the viability of the Digital Marketplace protocol.
IX. C ONCLUSIONS The Digital Marketplace has the potential to revolutionise service provision beyond 3G. Improved competition in a freely-operating market leads to increased efficiency. Combined with a lowered barrier to entry, this will allow the mobile services market to provide greater economy for the end user. However, without addressing the security concerns described in this paper, the protocol would be vulnerable to collusion, corruption, and disruption. Countering these threats is therefore of vital importance to the success of the Digital Marketplace. In section VI, we presented a comprehensive analysis of threats to the Digital Marketplace protocol, examining and classifying security issues. Each class of issue is addressed by one of the security requirements described in section VII. Therefore, if the requirements for authenticity, secrecy, collusion detection, and reputation fairness can be met, the Digital Marketplace will operate securely and fairly for all participants. R EFERENCES [1] Gwena¨el Le Bodic, Demessie Girma, James Irvine, and John Dunlop, “Dynamic 3G Network Selection for Increasing the Competition in the Mobile Communications Market,” in Proceedings of 52nd Vehicular Technology Conference, pp. 1064– 1071, September 2000. [2] Chris Salter, O. Sami Saydjari, Bruce Schneier, and Jim Wallner, “Towards a Secure System Engineering Methodology,” in Proceedings of the 1998 Workshop on New Security Paradigms, pp. 2–10, September 1998. [3] James Irvine, “Adam Smith Goes Mobile: Managing Services Beyond 3G with the Digital Marketplace,” Invited Paper to European Wireless 2002, February 2002. [4] Gwena¨el Le Bodic, Demessie Girma, James Irvine, and John Dunlop, “An Agent-Based Middleware for Enhancing Mobile Communications Infrastructure and Provision of Services in Emerging Systems,” in Proceedings of SOMAS Workshop, July 2000.
