1 MIDEP: Multiparty Identity Establishment Protocol for Decentralized Collaborative Services Rasib Khan and Ragib Hasan SECRETLab, Department of Computer and Information Sciences University of Alabama at Birmingham, AL, USA {rasib, ragib}@cis.uab.edu Abstract—Decentralized collaborative architectures are gain- ing popularity in all application areas, varying from peer-to- peer communication and content management to cloud and ubiquitous services. However, the public identity of the user is still a major concern, in terms of privacy, traceability, verifiability, masquerading, and other attacks in such environments. We demonstrate two new attacks, identity shadowing and the Man- in-the-Loop (MITL) attacks, which are applicable in particular to multiparty collaborative environments. In this paper, we propose MIDEP, a Multiparty IDentity Establishment Protocol for col- laborative environments. The proposed protocol allows a client to establish a secure, multiparty, probabilistic, temporal, verifiable, and non-traceable public identity with the collaborating peers in a decentralized architecture. MIDEP allows a client to avoid identity shadowing and protects the service from the resulting threats as well as from colluded information sharing among the collaborating peers. We illustrate how existing collaborative service frameworks can utilize MIDEP to securely establish the public identity prior to beginning the service session. A prototype implementation is utilized to perform extensive experimental analysis. Our results show that MIDEP is highly suitable in terms of overhead to ensure secure identity establishment for underlying decentralized collaborative services. Keywords-Collaborative, Decentralized, Multiparty, Identity Establishment, Security, Temporal, Non-Traceable, MIDEP I. I NTRODUCTION Decentralized collaborative architectures require multiple entities to interact and offer a collective service. A user interacts with multiple entities using the same public identity. In this work, we consider the public identity of the user as a unique representation using a username, signature, token, service identity, or a shared (public) key among the distributed and decentralized entities providing the service. Unfortunately, the use of the same identity across multiple service sites exposes the user to numerous threats from within the ser- vice network [1–3]. Decentralized service architectures with multiple cooperating entities allow a wider opportunity for an attacker to exploit the temporal nature of the service [4–7]. A malicious peer may perform masquerading attacks and session misdirection [4, 7]. An attacker may also track the user and violate the privacy of non-linkability [1, 8]. Collab- orative systems do not allow users to validate the number of parties involved in the multiparty protocol, exposing the user to session hijacks and replay attacks [9, 10]. Decentralized services may employ cloaking or anonymous identities using k-tokens [11]. Unfortunately, anonymous identities challenge the provability or auditing of the users with respect to the growing number of tokens over time [12–14]. The user’s service in collaborative systems (Figure 1) suffers from misdirection and colluded information sharing among the peers to exploit the identity of the user. We also introduce the concept of identity shadowing and man-in-the-loop (MITL) attacks, which are applicable to decentralized collaborative architectures involving more than two parties. Let us consider a 3-party protocol among A, B, and C, with each entity interacting with the other two. Each node assumes that its peers are reachable over a direct link or via the third node. In this context, we say that A suffers from identity shadowing for C on the indirect link A-B-C (Figure 2a). The identity shadow for the user can easily allow a malicious party to perform an MITL attack by intercepting the shadowed link (Figure 2b). We also emphasize the requirement of privacy of non-linkability as well as verifiability of the user’s identity for such service architectures. The focus of the problem is therefore not the authentication of anonymous users, but the establishment of a secure interactive public identity of the user at a given decentralized collaborative service site. In this paper, we introduce MIDEP, a secure Multiparty IDentity Establishment Protocol. MIDEP allows a user to establish a commonly agreed probabilistic public identity from a set of available options. We posit that MIDEP is suitable for decentralized collaborative systems for establishing temporal, non-traceable, and provable/auditable identities for its users. MIDEP can be used as an overlying layer with other collabo- rative service architectures to ensure protection from linkable identities, identity shadowing, masquerading, and colluded information sharing among the collaborating peers. MIDEP also allows an authorized auditing entity to validate the claim of usage of a particular service by a user at a later time. Our simulated results illustrate the practical feasibility of MIDEP in terms of the computational and temporal overhead for underlying decentralized collaborative services. Contributions: The contributions in this paper are as follows: 1) We introduce the concepts of identity shadowing and Man- in-the-Loop (MITL) attacks particular to decentralized col- laborative services and present a list of desired security properties to be preserved in such environments. 2) We propose the Multiparty IDentity Establishment Proto- col (MIDEP) for secure establishment of a user’s public identity for decentralized collaborative services. 3) We illustrate the suitability of MIDEP for collaborative services using a fully-functional prototype and extensive experimental analysis for the proposed protocol. The rest of the paper is organized as follows. Section II ex-
Rasib Khan and Ragib HasanSECRETLab, Department of Computer and Information Sciences
University of Alabama at Birmingham, AL, USA{rasib, ragib}@cis.uab.edu
Abstract—Decentralized collaborative architectures are gain-ing popularity in all application areas, varying from peer-to-peer communication and content management to cloud andubiquitous services. However, the public identity of the user is stilla major concern, in terms of privacy, traceability, verifiability,masquerading, and other attacks in such environments. Wedemonstrate two new attacks, identity shadowing and the Man-in-the-Loop (MITL) attacks, which are applicable in particular tomultiparty collaborative environments. In this paper, we proposeMIDEP, a Multiparty IDentity Establishment Protocol for col-laborative environments. The proposed protocol allows a client toestablish a secure, multiparty, probabilistic, temporal, verifiable,and non-traceable public identity with the collaborating peersin a decentralized architecture. MIDEP allows a client to avoididentity shadowing and protects the service from the resultingthreats as well as from colluded information sharing amongthe collaborating peers. We illustrate how existing collaborativeservice frameworks can utilize MIDEP to securely establish thepublic identity prior to beginning the service session. A prototypeimplementation is utilized to perform extensive experimentalanalysis. Our results show that MIDEP is highly suitable interms of overhead to ensure secure identity establishment forunderlying decentralized collaborative services.
Decentralized collaborative architectures require multipleentities to interact and offer a collective service. A userinteracts with multiple entities using the same public identity.In this work, we consider the public identity of the user asa unique representation using a username, signature, token,service identity, or a shared (public) key among the distributedand decentralized entities providing the service. Unfortunately,the use of the same identity across multiple service sitesexposes the user to numerous threats from within the ser-vice network [1–3]. Decentralized service architectures withmultiple cooperating entities allow a wider opportunity for anattacker to exploit the temporal nature of the service [4–7].
A malicious peer may perform masquerading attacks andsession misdirection [4, 7]. An attacker may also track theuser and violate the privacy of non-linkability [1, 8]. Collab-orative systems do not allow users to validate the number ofparties involved in the multiparty protocol, exposing the userto session hijacks and replay attacks [9, 10]. Decentralizedservices may employ cloaking or anonymous identities usingk-tokens [11]. Unfortunately, anonymous identities challengethe provability or auditing of the users with respect to thegrowing number of tokens over time [12–14].
The user’s service in collaborative systems (Figure 1) suffersfrom misdirection and colluded information sharing among thepeers to exploit the identity of the user. We also introduce theconcept of identity shadowing and man-in-the-loop (MITL)attacks, which are applicable to decentralized collaborativearchitectures involving more than two parties. Let us considera 3-party protocol among A, B, and C, with each entityinteracting with the other two. Each node assumes that itspeers are reachable over a direct link or via the third node.In this context, we say that A suffers from identity shadowingfor C on the indirect link A-B-C (Figure 2a). The identityshadow for the user can easily allow a malicious party toperform an MITL attack by intercepting the shadowed link(Figure 2b). We also emphasize the requirement of privacyof non-linkability as well as verifiability of the user’s identityfor such service architectures. The focus of the problem istherefore not the authentication of anonymous users, but theestablishment of a secure interactive public identity of the userat a given decentralized collaborative service site.
In this paper, we introduce MIDEP, a secure MultipartyIDentity Establishment Protocol. MIDEP allows a user toestablish a commonly agreed probabilistic public identity froma set of available options. We posit that MIDEP is suitable fordecentralized collaborative systems for establishing temporal,non-traceable, and provable/auditable identities for its users.MIDEP can be used as an overlying layer with other collabo-rative service architectures to ensure protection from linkableidentities, identity shadowing, masquerading, and colludedinformation sharing among the collaborating peers. MIDEPalso allows an authorized auditing entity to validate the claimof usage of a particular service by a user at a later time. Oursimulated results illustrate the practical feasibility of MIDEPin terms of the computational and temporal overhead forunderlying decentralized collaborative services.
Contributions: The contributions in this paper are as follows:
1) We introduce the concepts of identity shadowing and Man-in-the-Loop (MITL) attacks particular to decentralized col-laborative services and present a list of desired securityproperties to be preserved in such environments.
2) We propose the Multiparty IDentity Establishment Proto-col (MIDEP) for secure establishment of a user’s publicidentity for decentralized collaborative services.
3) We illustrate the suitability of MIDEP for collaborativeservices using a fully-functional prototype and extensiveexperimental analysis for the proposed protocol.
The rest of the paper is organized as follows. Section II ex-
2
U
P P P P
P P P P
P P P P
P P P P
i
m
User
Service Session
P = collaborating peer Pi = interacting peer Pm = malicious peer
Fig. 1: Applicability Scenario for MIDEP
plains the security challenges and desired security properties.Section III and Section IV presents the proposed protocol andthe security analysis respectively. The prototype implementa-tion is explained in Section V followed by the experimentalresults in Section VI. Finally, the related work and conclusionare presented in Section VII and Section VIII respectively.
II. SECURITY CHALLENGES
In this section, we discuss the possible threats and thedesired security properties for collaborative services.
A. Motivation
Peer-to-peer (P2P) and deterministic distributed systems(e.g. DHT) have been applied to numerous applications [4, 7,15, 16]. Various services have been ported to P2P to leveragethe collaborative nature of the framework [4–7, 17]. Ad-hoccloud frameworks can also utilize decentralized and collab-orative entities within the architecture [18, 19]. Ubiquitousenvironments are designed around decentralized architecturesfor providing collaborative services [8, 9]. Service compositionusing collaborative smart devices is the core concept behindpervasive and localized applications [20, 21]. Location-basedapplications also require the collaboration of decentralizedentities to provide the service [10, 22–24]. Unfortunately, suchsystems suffer from various shortcomings [25].
An example collaborative environment is illustrated in Fig-ure 1. A user U requests a decentralized collaborative servicefrom a set of peers P. The user communicates with peer Pi,and one of the peers, Pm, is malicious. The public identity/keyof the user may be distributed from a centralized point. Thisimposes a severe bottleneck in the performance of the system.Moreover, U ’s public identity can be traced to other servicesites, violating the privacy of non-linkability. Anonymousauthentication techniques allow a probable solution at the costof limited scalability and storage [13, 14, 26]. The user mayconsider sending the public key individually to all the cooper-ating peers. However, collaborative services require the peersto communicate among themselves. This introduces identityshadowing for U and can be exploited by Pm to performforging, masquerading, replay, or MITL attacks. Therefore, weposit that an overlying protocol is required for decentralizedservice-oriented architectures [8, 19, 27] to establish a secure,commonly agreed, probabilistic, non-linkable, and auditablepublic identity for the users.
B. Threat Model
In the context of this paper, we refer to the public identityas a unique representation of the user based on a username,signature, token, service identity, or a shared public key among
A B C A – B – C? B – C – A?
A – C – B?
B – A – C? C – B – A?
C – A – B?
(a) Identity Shadowing. Each of theentities suffer from identity shadowingon the indirect link to the third entity.
A B
C
M
Man-in-the-Loop
(b) Man-in-the-Loop (MITL). Mcan easily perform an MITL attackdue to identity shadowing from A.
Fig. 2: Probable Threats in Multi-Party Decentralized Services
the collaborative entities providing the service. As shown inFigure 2a, A is speaking to B and CA, and B is talking toCB . However, A cannot be assured that A and B are talkingto the same C, that is, CA and CB are the same. Here, wecan say that A suffers from identity shadowing of C becauseof B. The same applies for all other communication linkdirections, as shown in Figure 2a. An attacker can performpeer misdirection in the collaborative service [3, 28]. The man-in-the-loop (MITL) is a similar attack as man-in-the-middle.Identity shadowing within collaborative systems allows anattacker to become a part of the communication loop andperform an MITL attack (Figure 2b). Session hijacking refersto the exploitation of a service session which has been tiedto the identity of a user by taking advantage of the identityshadow [28, 29]. An attacker can also collude with a peer andhijack the session without the user’s knowledge.
An attacker can perform a replay attack to re-issue requestsby using a previously valid identity. The nonce is an effectiveway to prevent replay attacks. In this case, we refer to thereplay attacks in terms of the identity of the user [2, 3]. Amalicious entity may track the identity of a user across servicesites and exploit the privacy of non-linkable identities [1]. Anattacker can use the forged identity at a later time to request forthe services masquerading as the legitimate user [30, 31]. Amalicious user may take advantage of pseudonymous identitiesand deny the usage of the particular service at a given site. Thedenial of usage (DoU) is a crucial factor in terms of serviceaudit and digital forensic investigations. Collaborating peersmay perform colluded information sharing and share piecesof information together to exploit the user’s identity.
C. Security Properties
We define the following desired security properties fordecentralized collaborative service architectures.
[P1] A user must ensure that all collaborating peers are freefrom identity shadowing.
[P2] A user must be protected from peer misdirection andMITL in the collaborative framework.
[P3] A user must be protected from session hijacking, replayattacks, and identity masquerading from a malicious peer(s).
[P4] The user’s identity must ensure privacy of non-linkability.
[P5] The identity of the user must not be exposed withcolluded information sharing.
[P6] An authorized entity, if required, must be able to performpost-auditing of a user’s service identity.
3
MIDEP Client
Existing Service
Framework
MIDEP Collaborator
Existing Service
Framework
Ge
ne
rate
Tem
pID
MIDEP Execution
Temp
ID Estab
lishe
d R
equ
est
Tem
pID
Pro
vide Tem
pID
User Decentralized Entities
Collaborative Service Session
Fig. 3: Protocol Integration Point for MIDEP
III. MULTI-PARTY IDENTITY ESTABLISHMENT
In this section, we present the system model and protocoldescription for MIDEP.
A. System ModelThe Multi-party Identity Establishment Protocol (MIDEP)
is a supporting protocol for decentralized service-oriented ar-chitectures which involve more than two parties collaboratingto offer a particular service at a given site at a given time.The operational model assumes that all parties involved in theservice are capable of reaching each other over the network.MIDEP focuses on the agreement, establishment, and post-verification of a common temporal identity at the given site ofservice for a decentralized collaborative system. MIDEP doesnot include the process of authentication or authorization ofthe services. The user is assumed to possess a unique identifier(userID), based on which, the subsequent temporal identities(tempID) are generated.
MIDEP operates using the following entities: (a) a client isa user who is interested to establish a temporal, provable, andnon-traceable identity among the entities in a decentralizedcollaborative service, (b) collaborators are the entities whichare collectively providing the service, (c) for each of thecollaborators, the other collaborators are referred to as peers,and (d) an auditor is an authorized entity who can verifythe usage of the servicing identity for the client. A clientcan use MIDEP and userID to establish a commonly agreedtemporal identity among the collaborators. The collaboratorsalso communicate with their peers to ensure resistance tothe common attacks on the user’s identity in decentralizedcollaborative services. MIDEP can work with existing col-laborative services to provide secure identity establishmentbefore beginning a session. Service frameworks can requestfor a temporal identity using MIDEP as an overlay protocol,as shown in Figure 3.
B. Identity EstablishmentThe protocol sequence for MIDEP is illustrated in Figure 4
and described as follows.
(Step a) Key-Part Generation: The client possesses a uniqueuserID and uses the Shamir’s Secret Sharing algorithm todivide userID into N-pieces of IDparts [32]. At least K-piecesof IDparts are required to reconstruct userID.
(Step b) Send Key-Parts: The client then sends the identityoffer message, with M random pieces of IDparts to each of thecollaborators. Here, the value of M is such that (M∗XC < K),
(g) RESPOND Ack
(f) Send Temp_ID
(d) RESPOND [M+E*(X-1)] ID_Parts
(c) EXCHANGE E Random ID_Parts
(b) SEND M Random ID_Parts
1 X 2 (X-1)
User
(a) GENERATE N ID_Parts
(e) VERIFY Exchange CONSTRUCT Temp_ID
Collaborators
Fig. 4: The Multi-Party Identity Establishment Protocol
Algorithm 1 FUNC: BeginOffer()1: Comment: begins identity offer process2: Begin:3: IDparts[N ] = GenSecretShares(userID, N , K)4: for all X in Collaborators do5: OIDParts[M ] = GetRandParts(IDparts[ ], M )6: MType = “IDOffer”7: IDOfferMsg = CreateOfferMsg(MType,OIDParts[ ])8: SendMsg(X , IDOfferMsg)9: end for
Algorithm 2 FUNC: CreateMsg(MType, Parts[ ])1: Comment: creates returns MType message2: Return format: MType:MType, Size:Parts[ ].Size(), Parts:[part1...partM ]3: Begin:4: Msg = create new key-value list5: Msg.append(Mtype, MType)6: Msg.append(Size, Parts[ ].Size())7: for all P in Parts do8: Msg.append(P .Index(), P )9: end for
10: return Msg
where XC is the number of collaborators and K is theminimum number of IDparts required to reconstruct userID[32]. The operation performed by the client is described inAlgorithm 1. The client first obtains the list of all collabo-rators. The IDOffer message is then sent to each of thecollaborators and includes M random IDparts. The message isconstructed with the format described in Algorithm 2.(Step c) Exchange Key-Parts: The M-pieces received by eachcollaborator X may or may not have some common IDparts.Each of the collaborators then exchange E-pieces of IDpartswhich they have received from the client, where (E ≤ M ).Each of the collaborators X executes the exchange sequence asdescribed in Algorithm 3. Each collaborator obtains E randomIDparts and sends the IDExch message to the correspondingpeers, which is constructed using Algorithm 2.(Step d) Response Key-Parts: Each collaborator exchangesthe E IDparts with their peers and saves the newly receiveditems to create a set of R IDparts, where R = (M + (E ∗(X−1))). The collaborators then respond to the client with theidentity offer response message. The sequence of functions forthe collaborator is presented in Algorithm 4. Each collaboratordispatches a looped process to receive any exchange parts
4
Algorithm 3 FUNC: BeginExchange(IDOfferMsg)1: Comment: begins identity exchange process2: Begin:3: M = IDOfferMsg.Size()4: IDOffers[M ] = GetIDparts(IDOfferMsg)5: for all P in Peers do6: EIDparts[E] = GetRandParts(IDOffers[ ], E)7: MType = “IDExch”8: PartExchMsg = CreateMsg(MType,EIDparts[])9: SendMsg(P, PartExchMsg)
Algorithm 5 FUNC: ExchangeReceiverLoop()1: Comment: starts loop to receive IDparts sent from peers2: Begin:3: while !AllPeersExchangeCompleted() do4: ExchangeReceivedParts = ReceiveMessage()5: CurrMap.add(ExchangeReceivedParts)6: end while
Algorithm 6 FUNC: SendOfferResponse()1: Comment: sends offer response to MIDEP Client2: Begin:3: if AllPeersExchangeCompleted() then4: MType = “IDOfferResp”5: IDOfferRespMsg = CreateMsg(MType, CurrMap[ ])6: SendMsg(MIDEPClient, IDOfferRespMsg)7: end if
being sent from other peers, as shown in Algorithm 5. Thecollaborator maintains a map of the IDparts which werereceived from the client as well as from exchanging the IDpartswith the peers. Once the exchange process is completed withall of the peers, the collaborator sends the IDOfferRespresponse message to the client as shown in Algorithm 6.
(Step e) Exchange Verification: The R IDparts received bythe client from each of the collaborators are matched with theoriginal N IDparts to verify a valid exchange between eachof the collaborators. A successful verification is followed bythe construction of the tempID. The tempID is considered tobe T pieces of IDparts, where (1 ≤ T ≤ S), and S is thenumber of shared common IDparts among all the collabora-tors. The client executes the sequence of actions described inAlgorithm 7. A mismatch implies that there is a maliciouscollaborator attempting an MITL or peer misdirection attacktaking advantage of the identity shadowing. After all of thecollaborator responses have been processed, the commonlyshared IDparts are obtained from the map. If N is largeand M is too small, execution of MIDEP may result in nocommon IDparts. The client can then restart MIDEP to re-trythe identity establishment process.
(Step f) Temporal Identity Confirmation: The client sendsan identity finalized message to all the collaborators to notifythe tempID and the duration of time for which the tempID isvalid. In case the client wishes to continue the service sessionat the given site, the client may re-run MIDEP to create anothertempID or use a longer validity period. The sequence of actions
Algorithm 7 FUNC: VerifyExchange()1: Comment: verifies exchange and returns TempID[ ]2: Return format: Size:Parts[ ].Size(), Parts:[part1...partT ]3: Begin:4: IDpartMap = CreateMap(IDparts[ ])5: for all X in Collaborator do6: IDOfferRespMsg = ReceiveMessage()7: R = IDOfferRespMsg.Size()8: RIDparts[R] = GetIDparts(IDOfferRespMsg)9: /* check if IDparts belong to user */
10: isV alid = Validate(RIDparts[ ])11: if isV alid then12: for all P in RIDparts[ ] do13: InsertToMap(P , IDpartMap)14: end for15: else16: RestartMIDEP()17: end if18: end for19: /* obtain commonly shared IDparts */20: SharedIDparts[ ] = CheckMap(IDpartMap)21: if SharedIDparts[ ].Size() == 0 then22: RestartMIDEP()23: else24: TempID[ ] = GetRandParts(SharedIDparts[ ], T )25: end if26: return TempID[ ]
Algorithm 8 FUNC: IDFinalizer()1: Comment: begins identity finalize process2: Begin:3: TempID[] = VerifyExchange()4: MType = ”TempIDFinalized”5: TempIDMsg = CreateMsg(MType, TempID[ ])6: for all X in Collaborators do7: SendMsg(X , TempIDMsg)8: end for
is explained in Algorithm 8. The finalizer process on the clientis responsible for generating and sending the final tempID.At this point, MIDEP has securely established a commonpublic identity with the particular peers who are expected tocollaborate within the decentralized service framework. Anyparty, without receiving TempIDFinalized, should not beable to interact with the system and process the client’s requestfor the collaborative service.
(Step g) Identity Acknowledgment: After the collaboratorsreceive the identity finalized message, each of them respondwith an acknowledgement message to the client. The protocolsequence for MIDEP therefore finishes at this point.
C. Identity VerificationA client may be required to present a proof of usage for
a particular service to a certified auditor. The client presentsrandom (K−1) IDparts, the particular tempID, and the userIDto the auditor. The auditor uses the specific tempID and (K−1) IDparts, and uses Shamir’s Secret Sharing to reconstructthe client’s original userID [32]. A successful match verifiesthat the client had indeed used the decentralized service alongwith the collaborators at the given site. This verifiable identityalso ensures that the decentralized service architecture is notsusceptible to denial of usage (DoU) by the client.
IV. SECURITY ANALYSIS
In this section, we present the design and security analysisfor MIDEP in a decentralized collaborative environment.
Key Division Parameters: The client is required to preset thevalues of N and K. High values for N and K, with K ≈ N ,
5
will allow the client to have a wider choice for the M randomIDparts and will protect the client from colluded informationsharing attacks. Property P4 is thus satisfied.
Offer Size Adjustment: The value of K and M should be suchthat K � (M ∗XC). Keeping the number of offered pieceslow ensures minimum revelation of the IDparts. Properties P3and P5 are thus satisfied.
Provable Identity: The client places P protected pieces ofIDparts in a secure storage, where P ≥ (N−K+1) and neveruses P for any of the phases in MIDEP. The client presentsK IDparts to prove the identity in case of DoU. Therefore,|P | ≥ 1 ensures that there will be at least one piece requiredfor a successful reconstruction of userID and protects the clientfrom all-way colluded information sharing. Properties P4, P5,and P6 are thus satisfied.
Shared Secret Index Obfuscation: Reconstruction of userIDrequires N, K, and the index of each of the K IDparts. TheIDparts, N, K, and the index of the IDparts are all private inMIDEP. Therefore, an attacker still needs to try N !
(N−K)! ∗RL
number of combinations to guess the userID with knownvalues for N and K. Here, R is the representation format(binary, alpha-numeric), and L is the length of the key. E.g.,for N = K = 15 and K � (M ∗XC), there are more than(1.30 ∗ 1012) possible polynomial combinations. Property P3and P5 are thus enhanced.
Avoiding Identity Shadow: Unlike MIDEP, mutuallly verifiedprotocols will still suffer from identity shadowing, giventhat the collaborators do not agree on the identity duringthe process of identity establishment. Exchange verificationfrom the set of exchanged IDparts implies that each of thecollaborators and the client are communicating with the sameset of collaborators and peers, and therefore avoids the identityshadow. Properties P1, P2 and P3 are thus satisfied.
Outsider Collaborator Protection: The client offers theIDparts to each of the collaborators with probability:P (offer) = (N−M)!
N ! . The (trusted) collaborators exchangethe IDparts with probability P (exchange) = (M−E)!
M ! . E.g.,for N = 15, M = 3, and E = 2, P(offer) and P(exchange)are (3.66 ∗ 10−4 ∗ R−L) and (1.67 ∗ 10−1 ∗ R−L) respec-tively. The combined probability (P(offer) ∩ P(exchange)) is(6.11 ∗ 10−5 ∗ R−2L). An attacker needs to overcome theseodds to guess the IDparts corresponding to a valid collaborator.Properties P1, P2, and P3 are thus enhanced.
Privacy of Non-Linkability: The tempID allows an entity tointeract with a system without revealing the userID identity.Additionally, the tempID may be re-set at any time the clientdesires. These features allow protection against replay attacksand linkable identities. Property P4 is thus satisfied.
Enhancement of Non-Linkability: The client can use pro-gressive/degressive IDpart generation using different values ofN and K. This ensures a greater probabilistic protection of non-linkable privacy. The client can use (N = K) and (|P | ≥ 1)for (Min ≤ N ≤ Max) where (Min ≥ (1 + XC)) andMax depends on the computational feasibility of the auditor.Given Pn = (P(offer) ∩ P(exchange)) for each (N = K),the probability of guessing a traceable identity is (P(offer) ∩
MIDEP Client
List: Collaborator Observer
Process: Offer Handler
Process: Verification Engine
Library: Shamir’s Secret Share
Data Structure: Key Store
Network: Communication
Handler
Process: Identity Finalizer
Service Interface
(a) MIDEP Client
MIDEP Collaborator
List: Peer Observer Process: Exchange
Handler
Process: Verification Engine
Data Structure: Key Store
Network: Communication
Handler
Memory: Client ID Store
Service Interface
(b) MIDEP Collaborator
Fig. 5: MIDEP Prototype System Architecture
P(exchange))total = Π(Pn). This is much lower than 6.11 ∗10−5 ∗ R−2L (described earlier for N = 15,M = 3, E = 2)as it is the product of all possible cases of IDpart generation,offer, and exchange. The client can later present N, K, (K-P)IDParts, and P protected IDParts to prove the usage of userIDto an auditor. Properties P4, P5, and P6 are thus enhanced.
V. PROTOTYPE IMPLEMENTATION
In this section, we present the architecture and implemen-tation details for the MIDEP prototype.
MIDEP Client: The client had been implemented both as a PC(Java) and an Android application. The system architecture forthe implementation is shown in Figure 5a. The offer handlercreates the IDparts using an open source Shamir’s Secret Sharelibrary [33]. The key store is a placeholder for all the IDparts.The communication handler sends/receives messages to/fromthe collaborators. The collaborator observer keeps track ofthe collaborators and their status. The verification engine isresponsible for asserting the exchange process and invokesthe identity finalizer to confirm the tempID. The serviceinterface is the client’s internal communication channel foran underlying collaborative service framework which woulduse the tempID as the identity of the client.
MIDEP Collaborator: The collaborator had been imple-mented as a Java application. The implementation architec-ture is shown in Figure 5b. The communication handlerreceives/sends messages from/to the client and the peers. Theexchange handler executes the exchange process with thepeers. The peer observer and key store is used to keep trackof the incoming/outgoing IDparts. The verification engineconfirms the tempID, sends back the acknowledgement, andstores the tempID on the client ID store. The service interfaceis the collaborator’s internal hook to communicate with theunderlying service framework to support the establishment ofa temporal identity for a client.
VI. EXPERIMENTS AND RESULTS
In this section, we present the experimental evaluation forthe MIDEP prototype implementation.
A. Experimental SetupWe utilized the prototype implementation to perform ex-
perimental measurements and performance analysis. The PCclient was running on a dual core Intel Q9550 2.83 GHzmachine with 4 GB RAM and Ubuntu operating system. TheAndroid client was running on an ASUS Nexus 7 tablet with 1GB RAM and Quad-core 1.2 GHz Cortex-A9 processor. The
6
0
10
20
30
40
50
60
70
80
5 6 7 8 9 10 11 12 13 14 15
Tim
e (
mill
ise
con
ds)
N = K
(a) PC IDpart Generation
0
10
20
30
40
50
60
70
80
5 6 7 8 9 10 11 12 13 14 15
Tim
e (
mill
ise
con
ds)
N = K
(b) Android IDpart Generation
Fig. 6: IDpart Key Generation Time Measurements
0
10
20
30
40
50
60
70
5 6 7 8 9 10 11 12 13 14 15
Tim
e (
mill
ise
con
ds)
K
(a) PC Identity Verification
0
100
200
300
400
500
600
700
800
5 6 7 8 9 10 11 12 13 14 15
Tim
e (
mill
ise
con
ds)
K
(b) Android Identity Verification
Fig. 7: IDpart Key Combination Time Measurements
collaborators were running on Model-B Raspberry Pi-s with512 MB of RAM, 700 MHz Low Power ARM1176JZ-F pro-cessor, and 100 MB Ethernet port. The Raspberry Pi MIDEPcollaborators were connected over Ethernet to a Buffalo WZR-1750DHP Air Station wireless router. The PC and AndroidMIDEP clients were connected to the network over WiFi. Wealso implemented a PC and an Android identity verificationtool to be used by an auditor for userID verification.
B. Key GenerationWe measured the time taken for IDpart generation for both
the PC and Android MIDEP clients. The times were recordedfor 100 iterations for each value of N and K, where N = K ∈[5 . . . 15], and are illustrated in Figure 6a and 6b. The averagetimes for each of the cases are summarized in Table I. The PCwas more powerful than the Nexus 7 tablet, and maintaineda linear trend with increasing values of N and K. The PCclient, for most cases, took less than 5 ms for generating theIDparts. The range of average times lied between 1.473 ms and0.904 ms. The Android client was slower in computation andtook longer time with higher degrees of the polynomial. Thecomputation was still around 40 ms for most cases, with theaverage range between 32.731 ms and 5.640 ms. The resultsfor both cases show that the IDpart generation introduces aminimal overhead.
C. Key CombinationThe key combination for IDparts is required for identity
verification by an authorized MIDEP auditor. We implementedan auditing tool for identity verification for both PC andAndroid. The times were recorded for 100 iterations for eachvalue of K, where K ∈ [5 . . . 15], given that the IDparts weregenerated with N = K. The measured times are illustratedin Figure 7a and Figure 7b. The average times for each ofthe cases are summarized in Table I. The key combinationoperation requires the Lagrange basis polynomial computationfor the given degree of K and leads to a high utilization ofsystem memory. The general trend for the PC application was
N=KIDpart Generation (ms) Identity Verification (ms)PC Android PC Android
5 1.473 5.640 5.230 25.292
6 1.269 6.300 2.898 40.551
7 0.983 12.258 2.659 57.353
8 1.058 12.049 3.411 73.459
9 0.974 12.232 3.407 109.282
10 0.978 24.269 2.403 127.703
11 1.189 26.637 2.698 158.570
12 0.904 23.822 3.421 227.154
13 0.943 30.143 5.569 315.761
14 1.262 32.731 13.046 429.612
15 0.939 26.618 29.461 689.413
TABLE I: Average Times for IDpart Generation and IdentityVerification for PC and Android Clients
linear till the value of K = 13, being within 15 ms, with anaverage of 5.569 ms, after which the required time increasedto 29.461 ms. The Android verification tool showed a muchmore evident exponential pattern. The average time requiredtill K = 10 was less than 127.703 ms, which grew rapidlyto an average of 689.413 ms for K = 15. However, theverification tool will most likely be running on a PC with anauthorized auditor, in which case, the performance will barelyeffect the usability of the system.
D. Protocol ExecutionWe created a total of 20 protocol simulation scenarios with
varying number of Raspberry Pi collaborators (2 ≤ XC ≤ 5),offer sizes (2 ≤ M ≤ 5), and exchange sizes (1 ≤ E ≤ 5).Each of the 20 scenarios were executed for 100 iterations,for both the PC and Android MIDEP clients. We measuredthe time taken for the clients to establish a tempID usingMIDEP, that is, from generating the IDparts till the receipt ofthe acknowledgment from the collaborators. The simulationsummary is presented in Table II. The measured times for theclients are illustrated in Figure 8 and Figure 9.
For both the clients, we observed an increase in time withincreasing number of collaborators. The offer size (M) andexchange size (E) did not have much effect on the required
7
CaseOfferSize(M)
Exch.Size (E)
Collab.(XC )
PC Client Android ClientAvg. Time(ms)
Success(%)
Avg. Time(ms)
Success(%)
1 2 1, 1 2 69.49 100 135.73 100
2 3 1, 1 2 63.11 100 185.11 100
3 5 1, 1 2 61.79 100 157.24 100
4 5 3, 3 2 81.01 100 171.92 99
5 2 1, 1, 1 3 81.05 96 183.36 93
6 3 1, 1, 1 3 90.67 82 186.62 83
7 4 1, 1, 1 3 86.57 78 239.17 81
8 4 3, 3, 3 3 102.73 100 192.183 100
9 2 1, 1,1, 1
4 108.08 83 194.47 85
10 3 1, 1,1, 1
4 93.87 78 197.22 76
11 3 2, 2,2, 2
4 115.40 100 217.79 97
12 5 2, 2,2, 2
4 98.51 100 210.51 94
13 5 4, 4,4, 4
4 135.35 100 288.29 98
14 5 1, 2,3, 4
4 123.71 100 214.76 96
15 2 1, 1,1, 1, 1
5 125.39 82 207.61 82
16 3 1, 1,1, 1, 1
5 108.21 70 215.26 63
17 3 2, 2,2, 2, 2
5 136.29 100 233.29 95
18 5 2, 2,2, 2, 2
5 118.81 100 228.93 98
19 5 4, 4,4, 4, 4
5 155.38 100 253.26 98
20 5 1, 2,3, 4, 5
5 148.68 100 229.45 98
TABLE II: Simulated MIDEP Execution Results
time. The average times for the PC client varied between61.79 ms and 81.01 ms for 2 collaborators (cases 1 to 4).With 5 collaborators (cases 15 to 20), the average timesvaried between 108.21 ms and 155.38 ms. Given the limitedresources on the tablet compared to the PC, the Android clienthad a higher required time. The average measured times forthe Android client was between 135.73 ms and 185.11 msfor 2 collaborators (cases 1 to 4), and between 207.61 msand 282.25 ms for 5 collaborators (cases 15 to 20). Thewide variety of simulation scenarios show that MIDEP issuitable for collaborative service frameworks for establishingthe temporal identity for both desktop and mobile applications.
E. Successful Identity EstablishmentWe recorded the number of common IDparts (SharedID-
parts) obtained from the collaborator exchange. Having nocommon IDparts implies that it was a failed attempt to es-tablish a MIDEP identity. Table II summarizes the percentageof successful MIDEP identity establishments. Figure 10a andFigure 10b illustrates the the average and range of sharedIDparts obtained for each of the simulation scenarios.
We observed that M and E had varying effects with thenumber of collaborators (XC) on the success rate. The successrate for both the PC and Android MIDEP had similar results.For cases 1 to 4 (XC = 2), the success rate was at 100%.This is obvious as the 2 collaborators will always have sharedIDparts after a successful exchange. For (3 ≤ XC ≤ 5) ∈
Case
Shar
ed
IDp
arts
(a) PC MIDEP Client
Case
Shar
ed
IDp
arts
(b) Android MIDEP Client
Fig. 10: Case-wise Comparison of Shared IDparts
____ ____ ____ ____
XC = 2 XC = 3 XC = 4 XC = 5
(a) PC MIDEP Client
____ ____ ____ ____
XC = 2 XC = 3 XC = 4 XC = 5
(b) Android MIDEP Client
Fig. 11: ROC Curves for Collaborator Size (XC ) Prediction
Case[5 . . . 20], the success rate was lower with smaller valuesof M and E. Increasing the value of M with a fixed value forE reduced the success rate. An increase in the value of E ≥ 2drastically improved the success rate for all cases.
Cases 1 to 3 (M ∈ [2, 3, 5], E = 1, XC = 2) had twoSharedIDparts on average. Case 4 (M = 5, E = 3, XC = 2)resulted in a greater number of SharedIDparts with an averagebetween 5 and 6. Cases 5 to 7 (M ∈ [2, 3, 4], E = 1, XC = 3)had decreasing success rate. Case 8 (M = 4, E = 3, XC = 3)had 100% success rate, with an average of 6 SharedIDparts.Case 14 (M = 5, E ∈ [1 . . . 4], XC = 4) and case 20 (M =5, E ∈ [1 . . . 5], XC = 5) had different values of E for theeach collaborator, and still had a success rate of 100%, with5 and 8 SharedIDparts on average. The results show that thesuccess rate is directly proportional to M, E, and XC .
F. Collaborator PredictionGiven that M and S are known to the client, we analyzed the
suitability of MIDEP to identify unwanted collaborators usingour simulation results. We created a nominal logistic model topredict the number of collaborators (XC) using M, S, and M*Sas input variables. Figure 11 illustrates the receiver operationcharacteristic (ROC) curve for the sensitivity (true positive,TP) versus specificity (false positive, FP) of the model. Thesummary of the model is presented in Table III. The modelperformed similar for both clients (p < 0.0001) with M andM*S being primary indicators (p < 0.0001). The TP ratedecreased with increasing XC for the same number of cases.XC = 2 and XC = 3 had the highest enclosed ROC area andthe best prediction results. The ROC area and TP rate reducedfor XC = 4 and XC = 5. However, the area is still well abovethe marginal break-point. The results for XC = 2 and XC = 3compared to XC = 4 and XC = 5 depicts the necessityfor a larger number of cases with increasing collaborators.We believe that MIDEP can be applied for further machine
TABLE III: ROC and TP for Collaborator Size Prediction
learning techniques for adaptive security by predicting thenumber of peers within a collaborative system.
VII. RELATED WORK
Traditional key agreement protocols, unlike MIDEP, arenot suitable for decentralized collaborative environments [34].Token-based approaches for anonymity may provide a suitablesolution for collaborative frameworks [12, 14]. Unfortunately,such techniques are based on a centralized servers and havehigh costs for storage and scalability [11, 13, 26]. Accesscontrol in collaborative systems is also a crucial securitycomponent [35]. Most solutions depend on centralized and fed-erated systems for key-agreement and access control [36, 37].Conversely, MIDEP does not require centralized services forestablishment and verification of the public identity. Addition-ally, MIDEP allows flexible configurations as well as post-verification by authorized auditors. Biometrics, such as key-stroke dynamics, have also been proposed for collaborativesystems [38]. However, such systems are only suitable forhuman-interactive systems, suffer from varying precision, andrequire previous data to perform the verification. MIDEPfocuses on decentralized temporal identities, does not requireprior interactions, and ensures protection against the threatsemerging from identity shadowing in collaborative systems.
VIII. CONCLUSION
Decentralized collaborative environments have evolvedgreatly and been applied to various architectures and domains.In this paper, we proposed a Multiparty IDentity EstablishmentProtocol (MIDEP) for allowing a user to securely establisha public identity among multiple collaborating entities ina decentralized framework. The proposed protocol allows atemporal, non-linkable, verifiable, and probabilistic identityfor a servicing user, and protects an underlying decentralizedservice framework from identity exploitation attacks by mali-cious collaborating peers. Our simulations show that MIDEPcan be easily integrated with minimal overhead as an overlayprotocol with decentralized frameworks to establish a publicidentity for collaborative services. Our future work includesadaptation of MIDEP on top of existing decentralized collab-orative frameworks for ubiquitous and localized services.
ACKNOWLEDGMENT
This research was supported by a Google Faculty ResearchAward, the Department of Homeland Security Grant FA8750-12-2-0254, and by the National Science Foundation CAREERAward CNS-1351038.
REFERENCES[1] J. Kim, Z. Kim, and K. Kim, “A lightweight privacy preserving authentication and
access control scheme for ubiquitous computing environment,” in Proc. of ICISC.Springer Berlin Heidelberg, 2007.
[2] S.-Y. Chiou and Y.-H. Huang, “Mobile common friends discovery with friendshipownership and replay-attack resistance,” Wireless Networks, vol. 19, no. 8, 2013.
[3] G. Xiong, J. Tong, Y. Xu, H. Yu, and Y. Zhao, “A survey of network attacks basedon protocol vulnerabilities,” in Proc. of APWeb Workshops. Springer, 2014.
[4] R. Khan and R. Hasan, “SecP2PSIP: A Distributed Overlay Architecture for SecureP2PSIP,” in Proc. of ASE Cyber Security. ASE, May 2014.
[5] X. Zheng and V. Oleshchuk, “The design of secure and efficient p2psip commu-nication systems,” in Proc. of WISTP. Springer Berlin Heidelberg, 2010, vol.6033.
[6] I. Baumgart, “P2PNS: A Secure Distributed Name Service for P2PSIP,” in Proc.of PerCom. IEEE, Mar 2008.
[7] R. Ranjan, L. Zhao, X. Wu, A. Liu, A. Quiroz, and M. Parashar, “Peer-to-peercloud provisioning: Service discovery and load-balancing,” in Cloud Computing.Springer, May 2010.
[8] R. Khan, S. Zawoad, M. M. Haque, and R. Hasan, “Who, When, and Where?Location Proof Assertion for Mobile Devices,” in Proc. of DBSec. IFIP, July2014.
[9] F. Andreini, F. Crisciani, C. Cicconetti, and R. Mambrini, “A scalable architecturefor geo-localized service access in smart cities,” in Proc. of FutureNetw. IEEE,June 2011.
[10] Z. Zhu and G. Cao, “Toward privacy preserving and collusion resistance in alocation proof updating system,” IEEE TMC, vol. 12, no. 1, 2013.
[11] P. Kotzanikolaou, E. Magkos, N. Petrakos, C. Douligeris, and V. Chrissikopoulos,“Fair anonymous authentication for location based services,” in Data PrivacyManagement and Autonomous Spontaneous Security. Springer, 2013.
[12] J. Camenisch, S. Hohenberger, M. Kohlweiss, A. Lysyanskaya, and M. Meyerovich,“How to win the clonewars: Efficient periodic n-times anonymous authentication,”in Proc. of CCS. ACM, 2006.
[13] L. Nguyen and R. Safavi-Naini, “Dynamic k-times anonymous authentication,” inApplied Cryptography and Network Security, vol. 3531. Springer, 2005, pp. 318–333.
[14] M. H. Au, W. Susilo, Y. Mu, and S. Chow, “Constant-size dynamic k-timesanonymous authentication,” IEEE Systems Journal, vol. 7, no. 2, pp. 249–261,June 2013.
[15] G. Cordasco, L. Gargano, A. Negro, V. Scarano, and M. Hammar, “F-Chord:Improved uniform routing on Chord,” Networks, Wiley-Interscience, vol. 52, no. 4,Dec 2008.
[16] G. Danezis, C. Lesniewski-Laas, M. F. Kaashoek, and R. Anderson, “Sybil-resistantDHT routing,” in Proc. of ESORICS. Springer-Verlag, 2005.
[17] S. Ruj, M. Stojmenovic, and A. Nayak, “Decentralized access control withanonymous authentication of data stored in clouds,” IEEE TPDS, vol. 25:2, 2014.
[18] N. Fernando, S. Loke, and W. Rahayu, “Dynamic mobile cloud computing: Adhoc and opportunistic job sharing,” in Proc. of UCC. IEEE, 2011.
[19] G. N. C. Kirby, A. Dearle, A. Macdonald, and A. A. A. Fernandes, “Anapproach to ad hoc cloud computing,” Computing Research Repository (CoRR),vol. abs/1002.4738, 2010.
[20] J. Siebert, J. Cao, Y. Lai, P. Guo, and W. Zhu, “LASEC: A localized approach toservice composition in pervasive computing environments,” IEEE TPDS, vol. PP,no. 99, 2014.
[21] M. Shin, C. Cornelius, D. Peebles, A. Kapadia, D. Kotz, and N. Triandopoulos,“Anonysense: A system for anonymous opportunistic sensing,” Pervasive andMobile Computing, vol. 7, no. 1, pp. 16–30, 2011.
[22] M. Barak and S. Ziv, “Wandering: A web-based platform for the creation oflocation-based interactive learning objects,” Computers & Education, vol. 62, pp.159–170, Mar 2013.
[23] J. Brassil, R. Netravali, S. Haber, P. Manadhata, and P. Rao, “Authenticating amobile device’s location using voice signatures,” in Proc. of WiMob. IEEE, 2012.
[24] R. Khan, M. Haque, and R. Hasan, “A secure location proof generation schemefor supply chain integrity preservation,” in Proc. of HST. IEEE, 2013.
[25] D. S. Wallach, “A survey of peer-to-peer security issues,” in Proc of ISSS. SpringerBerlin Heidelberg, 2003, vol. 2609.
[26] J. Alwen, M. Hirt, U. Maurer, A. Patra, and P. Raykov, “Anonymous authenticationwith shared secrets,” International Association for Cryptologic Research CryptologyePrint Archive, p. 73, 2014.
[27] S. Karumanchi and A. C. Squicciarini, “In the wild: a large scale study of webservices vulnerabilities,” in Proc. of SAC. ACM, 2014.
[28] Y. Wang and J. Chen, “Hijacking spoofing attack and defense strategy based oninternet tcp sessions,” in Proc. of IMSNA, ser. IMSNA. IEEE, 2013.
[29] M. Johns, “Session hijacking attacks,” in Encyclopedia of Cryptography andSecurity, 2nd Ed., 2011, pp. 1189–1190.
[30] C. Zhang, J. Sun, X. Zhu, and Y. Fang, “Privacy and security for online socialnetworks: challenges and opportunities,” IEEE Network, vol. 24, no. 4, pp. 13–18,July 2010.
[31] C. Lu, “Detection and defense of identity attacks in p2p network,” in Advances inComputation and Intelligence. Springer Berlin Heidelberg, 2009, vol. 5821.
[32] A. Shamir, “How to share a secret,” Comm. of the ACM, vol. Vol. 2, no. 11, Nov1979.
[33] T. Tiemens, “Shamir Secret Sharing in Java,” http://sourceforge.net/projects/secretsharejava/.
[34] E. Rescorla, “RFC 2631: Diffie-Hellman Key Agreement Method,” Internet Engi-neering Task Force (IETF), 1999.
[35] W. Tolone, G.-J. Ahn, T. Pai, and S.-P. Hong, “Access control in collaborativesystems,” ACM Comput. Surv., vol. 37, no. 1, pp. 29–41, Mar 2005.
[36] Y.-F. Lu, P.-H. Lin, S.-S. Ye, R.-S. Wang, and S.-C. Chou, “A strong authenticationwith key agreement scheme for web-based collaborative systems,” in Proc. ofISPACS. IEEE, Nov 2012.
[37] A. Bouchami and O. Perrin, “Access control framework within a collaborative PaaSplatform,” in Enterprise Interoperability VI. Springer, 2014, pp. 465–476.
[38] R. Giot, M. El-Abed, and C. Rosenberger, “Keystroke dynamics authentication forcollaborative systems,” in Proc. of CTS. IEEE, May 2009, pp. 172–179.
