group message web service: group communication services ... · provides an answer to the following...

Group Message Web Service: Group communication services for next-generation devices

Kapali Viswanathan; Amitabh Saxena HP Laboratories HPL-2010-171R1 Keyword(s): Group messaging, web service, address-based capability, publish-subscribe, cryptography Abstract: Existing group comm unication technologies do not aim at addressing security concerns in environments where non-tech-savvy end-users d ecide security configurations. This docum ent provides an answer to the fo llowing question: how to realize an intuitive and end-user configurable secure groupcommunication mechanism? We introduce a group comm unication service ca lled Group Messaging Web Service (GM WS). Clients access GMW S using a ran ge of devices like m obile dev ices, personal co mputers, an d web-connected printers. GMW S facilitates s eamless device-g roup communications in a secure and transpa rent m anner. GMW S will ena ble s peedy crea tion of m any rich user e xperiences involving multiple users and devices such as web-enabled mobile devices.

External Posting Date: March 12, 2012 [Fulltext] Approved for External Publication

Internal Posting Date: March 12, 2012 [Fulltext]

Copyright 2012 Hewlett-Packard Development Company, L.P.

Group Message Web Service: Groupcommunication services for next-generation

devicesDesign Document

Kapali Viswanathan Amitabh [email protected] [email protected]

HP Labs India, Bangalore

October 22, 2010

1

Contents

1 Introduction 4

2 GMWS Architecture 52.1 Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Read and Write (RW) cells . . . . . . . . . . . . . . . . 72.1.2 R cells . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 W cells . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 System Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Forwarders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Cell-to-Cell Forwarding . . . . . . . . . . . . . . . . . . . . . . 122.6 Discovering Links . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 GMWS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7.1 RW-Cell API . . . . . . . . . . . . . . . . . . . . . . . 132.7.2 R-Cell API . . . . . . . . . . . . . . . . . . . . . . . . 142.7.3 W-Cell API . . . . . . . . . . . . . . . . . . . . . . . . 142.7.4 Common API . . . . . . . . . . . . . . . . . . . . . . . 14

3 Remote invocation controls in GMWS 153.1 Read Access Control . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Granting Read Ability . . . . . . . . . . . . . . . . . . 163.1.2 Revoking Read Ability . . . . . . . . . . . . . . . . . . 16

3.2 Write Ability Control . . . . . . . . . . . . . . . . . . . . . . . 173.2.1 Granting Write Ability . . . . . . . . . . . . . . . . . . 173.2.2 Revoking Write Ability . . . . . . . . . . . . . . . . . . 18

3.3 Transferring Capabilities . . . . . . . . . . . . . . . . . . . . . 18

4 Summary 19

5 Realizing group communications using simple cell structures 205.1 Standalone cell . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Network of cells . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Example Usecase . . . . . . . . . . . . . . . . . . . . . . . . . 22

A RW-Cell Security Reduction 26A.1 Security requirement of E . . . . . . . . . . . . . . . . . . . . 26A.2 Pseudo-Random Permutation . . . . . . . . . . . . . . . . . . 27

Page 2 Group Messaging Web Service

B R-Cell and W-Cell Security Reductions 29B.1 Security of Public Key Encryption . . . . . . . . . . . . . . . . 29B.2 Security of The Hash Function . . . . . . . . . . . . . . . . . . 30B.3 Security of R-Cells . . . . . . . . . . . . . . . . . . . . . . . . 30


1 Introduction

Existing group communication technologies do not aim at addressing se-curity concerns in environments where non-tech-savvy end-users decide se-curity configurations. This document provides an answer to the followingquestion: how to realize an intuitive and end-user configurable secure group-communication mechanism?

We introduce a group communication service called Group MessagingWeb Service (GMWS). Clients access GMWS using a range of devices likemobile devices, personal computers, and web-connected printers. GMWSfacilitates seamless device-group communications in a secure and transparentmanner. GMWS will enable speedy creation of many rich user experiencesinvolving multiple users and devices such as web-enabled mobile devices.

Web-based publish-subscribe mechanism can provide efficient, scalable,and extensible group communication framework. Our solution extends theconcept for Capability-based addressing [1, 2] to realize secure publish-subscribemechanism. We introduce a novel concept and data-structure called a cell,which is central to our contributions and novelty. A cell can be visualized asa virtual wire that can be shared by two or more user devices. The users canintuitively control the interactions of their devices with various groups byconnecting or disconnecting the virtual wires to their devices. Our solutionpromotes scalable, secure, and low-latency communications for serving mil-lions of devices. We have not found a comparable concept or implementationin the literature.

Capability-based addressing can allow end users to control the ability ofother users to reach them. In the traditional approach for access control,anybody can reach the users but the users are expected to provide filters (oraccess control rules like allow and deny) to control in-coming communica-tions. Our solution is radically different and tackles the problem head-on.The best solution is to have a primary defense such that unintended com-munications do not reach the devices. Filtering communications can still beuseful as a secondary defense.

An analogy for understanding GMWS is to visualize a digital equivalentof anonymous Post Boxes or Dead letter box,which are a means to exchangemessages using some apriori shared secret information such as a random boxnumber. More concretely, it provides a large number of communication cells ,which is a pair of random addresses – one for the input and the other forthe output. The protocols guarantee that no entity, except the GMWS, cancompute (or find) one address given the other.

GMWS is agnostic of access control mechanisms such as ACLs, user-names, and passwords. In order to control access to its resources for unidenti-


Figure 1: High-level architecture of GMWS

fied and arbitrary entities, GMWS only uses cell and queue addresses. Thus,GMWS can co-exist with various access control mechanisms.

2 GMWS Architecture

This section shall describe the basic components of the GMWS architecture.Figure 1 gives the high-level architecture of the system. GMWS hosts acollection of cells (virtual wires) that are can be remotely used by variousdevices and applications through our client API (GMWC API). We presentlysupport the use of XMPP/BOSH1 over HTTPS2 but we can support otherprotocols as well with minimal modifications .

figure 1 shows the software architecture for the server and the devices.The systems assumes one or more servers, which can be hosted in a singleserver machines or in a server farm. We shall assume the existence of asingle server for the sake of simplicity. The server is uniquely identified byits physical address such as the URL of the web-server that it includes. Thesystem assumes many client devices, which can be other server machines,personal computers, laptops, netbooks, printers, or mobile devices.

In addition to hosting a web-server, the server shall include an instanceof GMWS. The GMWS shall provide two major services, namely: Capa-bility Generation Service and messaging service. Cells are generated usingthe Capability Generation Service and the generated Cells are employed touse the messaging service. The system protocols (see Section 2.2) crypto-graphically ensure that Cells that are not generated using the CapabilityGeneration Service cannot be employed to derive intended services from theMessaging Service. In other words, when the Messaging Service is invokedusing cells that are not generated by the Capability Generation Service, themessages shall be dropped by the Messaging Service with a high probability.The system protocols also ensure that Capability Generation Service and

1http://xmpp.org/about-xmpp/technology-overview/bosh/2http://en.wikipedia.org/wiki/HTTP_Secure


http://xmpp.org/about-xmpp/technology-overview/bosh/

http://en.wikipedia.org/wiki/HTTP_Secure

Figure 2: High-level illustration of a cell

the Messaging Service shall be asynchronous services without requiring theuse of any joint state information. This design facilitates a highly scalabledeployment strategies for GMWS.

The rest of this section is organized as follows. Section 2.1 shall pro-vide a detailed discussion on the Cell data structure and the types of Celldata structures. Section 2.2 shall introduce the system protocols that linkthe GMWS Capability Generation Service and GMWS Messaging Service.Sections 2.3 and 2.4 shall introduce the Queue and the Forwarder data struc-tures of the GMWS. Sections 2.5 and 2.6 introduce the notion of Cell-to-Cellforwarding and link discovery functions of GMWS. These notions allow ex-tensible use of cells by various applications. Finally, Section 2.7 summarizesthe GMWS API that have been designed. The GMWS API is meant to beremotely invoked by GMWC (or Group Messaging Web Clients).

2.1 Cells

A cell is defined as a pair of addresses (or ports): an Input Address (IA)and an Output Address (OA). Each address is a k-bit number for somesecurity parameter k. Messages are sent to the input address and retrievedfrom the output address. That is, knowledge of IA gives the ability to writeto the cell, while knowledge of OA gives the ability to read from the cell. Itis not possible to read from or write to a cell without knowing OA or IArespectively. Figure 2 shows a cell.

Relationship between IA and OA: The IA and OA of a cell are math-ematically related as follows: Let (G, E ,D) be a deterministic symmetricencryption scheme with key, plaintext and ciphertext sizes of k bit each. LetK ← G(r) for r ∈R {0, 1}k be a k-bit uniformly chosen key. Then any cell


(IA,OA) must satisfy the relation OA = EK(IA). The key K is known onlyto the GMWS.

Cell Spaces: Cells are contained in what we call cell spaces. A cell space isthe set of cells that were generated by a unique key K. Recall that K definesa mapping between these sets and is used by the Capability Generation andMessaging services. Although different cell spaces can draw their addressesfrom the same set of numbers (i.e., the set Z2k , where k = log2K), thecell address pairs are logically unique addresses because each value of K isexpected to define a unique plaintext-ciphertext pair for secure symmetric keyencryption algorithms such as AES3. In other words, if (IA1, OA1) ∈ CS1 and(IA2, OA2) ∈ CS2, where CS1 and CS2 are two cell spaces with respectiveunique keys, then the condition (IA1 = IA2) and (OA1 = OA2) cannot occurdue to the property of the symmetric key encryption algorithm.

GMWS has three types of cells, each with a different access control struc-ture. They are Read/Write Access Control (RW), Read Access Control (R)and Write Access Control (R) cells. Each type is associated with an inde-pendent cell space and an independent key. Each of these three types shallnow be described.

2.1.1 Read and Write (RW) cells

RW cells are present in a cell space with a key K0 selected uniformly. Inan RW cell, both IA and OA appear like a pair of pseudo-random numbers.An RW cell can be obtained by making a GetCell query to the GMWS. TheGMWC can then choose to share either IA or OA with other entities. Ifit shares IA, it realizes read control. Alternatively, when it shares OA, itrealizes write control. Thus, RW mode allows both read and write control.

2.1.2 R cells

R cells are defined in a cell space with a key K1 selected uniformly. In anR cell, the IA is computed as IA = H(PK), where H : {0, 1}∗ 7→ {0, 1}k isa one-way hash function and PK is a well-formed public key. This publickey can be standard PKI-based, identity-based [3, 4] or certificateless [5](the GMWS does not care about the nature of this public key). Any entityknowing the private key corresponding to PK can obtain the OA of thiscell via a GetOA query to the GMWS (described later). R cells realizepublic write and restricted read because only the entity knowing OA canread messages from the cell. This is similar to an email system.

3http://en.wikipedia.org/wiki/Advanced_Encryption_Standard


http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

Figure 3: Cell generation functions for the three cell types.

Figure 4: Queries for obtaining cells of each type.

2.1.3 W cells

W cells are defined in a cell space with a key K2 selected uniformly. A Wcell is the dual of an R cell. In this, the OA of a cell is computed as OA =H′(PK), where H′ : {0, 1}∗ 7→ {0, 1}k is a one-way hash function and PK isa well-formed public key. Anyone knowing the private key corresponding toPK can obtain the IA of the cell using a GetIA query (described later). Wcells realize public read and restricted write because only the entity knowingIA can write to the cell. This is similar to a blog.

Figure 3 summarizes the three types of cells. The system provides meth-ods for obtaining a cell of each type. The methods are summarized in 4, anddescribed in detail in 2.7.

2.2 System Protocols

Four system protocols are defined on the three types of cells to link the twoservices of GMWS, namely Capability Generation and Messaging, in a pre-dictable manner. The four protocols are shown in Figure 5. The interactionbetween any pair of entity in the figure is assumed to be asynchronous. Nev-ertheless, the system protocols ensure that these asynchronous interactionsare ordered. For example, in the protocol for granting RW-Read ability, Bobcannot read messages from Alice (Steps 5 and 6) without receiving the readability from Alice (Step 3). Alice cannot successfully send messages to aparticular cell (Step 4) or share a particular cell with Bob (Step 3), before


Figure 5: System protocols in clockwise order starting from top-left portionof image: (a) Granting RW-Read Ability by sharing OA; (b) Granting RW-Write Ability by sharing IA; (c) Controlling read ability on a public cellsusing GetIA query; and, (d) Controlling write ability on a public cell usingGetOA query.


the particular cell was generated by the Capability Generation Service (Steps1 and 2). The beauty of this protocol sequence is that no interactions areneeded between the Capability Generation Service and the Messaging Ser-vice. They just need to be configured so that they share a secret key beforethe generation and messaging operations commence. This makes GMWShighly scalable.

When the messaging service receives (IA,m) on its input, it mechanicallycomputes OA = AESK(IA) and forwards the message to that output. If thatoutput has a queue attached (see Section 2.3), then the message enters thatqueue. If that output is attached to forwarding cell (see Section 2.5), themessage is forwarded to the input address of the forwarding cell. Other-wise, the message is silently dropped. Since the messaging load on GMWSis only one encryption for each message assuming no cell-to-cell forwarding,the latency and throughput experienced by the client communications canbe minimal. Additionally, resource constrained devices such as smart phonescan host network services associated with the queue on GMWS without car-rying the risk of denial of service attacks – GMWS can protect its clientsfrom denial-of-service attacks from unknown devices. We call this proactivecontrol. GMWS also provides reactive control on communications becauseof the ability to revoke granted abilities (refer to discussion on revocation inSections 3.1 and 3.2). Thus, if a friendly device that has ability to write toa device commences denial-of-service attacks4 on that device, the device canrevoke the ability of that friendly device to write to it.

2.3 Queues

Queues are FIFO structures and are used to retrieve messages from one ormore cells. A queue is identified by a k-bit number known as the queueaddress (QA). A queue can be (un)subscribed to one or more cells byspecifying the corresponding (QA,CellType,OA) tuple using Subscribe,Unsubscribe queries to the GMWS. When the queue is subscribed to acell, then all messages coming out of that cell are stored in the queue forlater retrieval. If there is no queue subscribed to the cell, then the messagesare silently dropped.

Note that it is not possible to retrieve messages from cells directly. In-stead, a queue must to be used as an intermediary. A client can retrievemessages from the queue QA by making a Read(QA) query. Since the QAsshall be a secret known only to one receiving entity, GMWS does not nec-

4This could be due to insecure device configuration and virus attacks on friendly de-vices.


Figure 6: High-level illustration of message flow in GMWS

essarily require usernames and passwords for its internal access control. Inother words, secret QAs allow GMWS to be agnostic about user access con-trol concerns.

2.4 Forwarders

While a queue is used to collect messages coming out from several cells (viatheir OAs), a forwarder sends a single message to several cells (via theirIAs). Similar to queues, a forwarder is defined using a k-bit number calledthe forwarding address (FA). A forwarder can be (un)linked from oneor more cells by specifying the corresponding (FA,CellType, IA) tuple inLink, Unlink queries to the GMWS. When a forwarder is linked to somecells, then all messages sent to the forwarder will be sent to all those cells.On the other hand, if there is no cell linked, then the message is silentlydropped. The GMWS provides the GroupSend(FA,m) query for sendingmessage m to forwarder FA.

In addition to sending messages via forwarders, it is also possible to sendmessage directly to cells by specifying the OAs via a Write query. Figure 6shows the flow of messages in GMWS.


2.5 Cell-to-Cell Forwarding

Only RW-cells allow cell-to-cell forwarding. In this, a message coming from,say OA1, of one cell can be forwarded to, say IA2, of another cell. The linkconnecting OA1 to IA2 is known as a C-Link. In order to make or breakthis C-Link, the client must not only provide (OA1, IA2), but also proveownership of the cell corresponding to OA1, which we call the sending cell.Ownership of a cell is proven by providing both its addresses. Thus, theclient must provide ((IA1, OA1), IA2). We call this forward linking, becausethe owner of the sending cell controls the links. When making a C-Link,the system provides a mechanism to assign a label in four possible waysdepending on a global setting. These are: (1) system-generated randomlabel, (2) name specified by link creator, (3) the username of the link creator,and (4) no label is assigned (anonymous links). Each is designed to cater tospecific needs of the application. If a label is attached to a C-Link, then thislabel is appended to all messages passing on this link.

2.6 Discovering Links

The system allows following queries to discover various links: (1) aGetOAs(QA∗)query takes in aQA∗ and outputs allOA(s) linked toQA∗, (2) aGetIAs(FA∗)query takes in a FA∗ and outputs all IA(s) linked to FA∗, and (3) aGetCLinks(IA∗, OA∗)query takes in a valid RW cell (IA∗, OA∗) and outputs all IA(s) linked tothis cell. The queries are designed such that they don’t leak any informationthat was not known earlier.

The above three queries are important because clients need not storemeta-data related to their cells, links, and groups. Instead, they can gettheir network meta-data from the forwarding networks stored on GMWS.The rules for link formation and queries are structured so that GMWS shallnot leak such meta-data to unauthorized entities. But, definition an entityknowing the input and output address of a cell is authorized to know theinput addresses of all cells connected to its cell. Nevertheless, knowing boththe input and output addresses of a cell shall not help the entity in knowingthe queue addresses that receive forwarded messages from that cell.

2.7 GMWS API

This section discusses the queries (or remote invocations) supported by GMWS.The queries are classified based on the type of cells they target, namely: RW-Cells, R-Cells and W-Cells. The queries common to these three types of cellsare listed under the name Common API . Additionally, the invocations in the


APIs for RW-Cells, R-Cells, and W-Cells define the Capability GenerationService while those in the Common API define the Messaging Service (seeFigure 1).

Query security: The set of defined queries require the following minimumsecurity5:

1. All queries require a one-way authenticated channel, such that the re-sponses can be ascertained to be from the GMWS. That is, all clientsmust be able to authenticate messages from and to the server but theserver need not authenticate the messages from and to the clients. Cellsand secret queue addresses allow this relaxation.

2. All queries except GetCell, GetIA and GetOA require a confidentialchannel for sending and receiving by the server and the client.

3. GetCell queries require a confidential channel for receiving.

In our case, we will use SSL/TLS to achieve the above security. A securityanalysis is given in the Appendix.

2.7.1 RW-Cell API

This is available only for RW cells.

• GetCell: An RW cell can be obtained via a GetCell query. On re-

ceiving this query, the GMWS server generates IA$← {0, 1}k and sets

OA← EK0(IA). It returns (IA,OA) as the RW cell.

• MakeCLink((IAS, OAS), IAR): If (IAS, OAS) is a valid sending cell,this query creates a forward C-Link with (IAS, OAS) as the sendingcell and IAR as the (IA of the) receiving cell.

• RemoveCLink((IAS, OAS), IAR): If (IAS, OAS) is a valid RW-celland a C-Link between OAS, IAR exists, this query removes the link.

• GetCLinks(IAS, OAS): If (IAS, OAS) is a valid RW-cell, the serverreturns a list of all the IA(s) linked to this cell.

5Minimum security is a notion for setting the minimal expectations on the implemen-tation and deployment of GMWS for it to be secure.


2.7.2 R-Cell API

This is available only for R-cells. In the following, we consider a public keyto comprise not only of the key material but also an algorithm description.Therefore, a public key PK is a tuple (Algorithm, Key).

• GetOA(PK): An R-cell can be obtained via a GetOA(PK) query.If PK is not a well-formed public key, the GMWS server returns anerror. Otherwise, it computes IA = H(PK), OA = EK1(IA) andCOA = EncryptPK(OA). It sends COA as its response to the query.

Let SK be the private key corresponding to PK. If the receiver knowsSK, it can compute OA = DecryptSK(COA) and IA = H(PK). Thenthe pair (IA,OA) is an RAC cell.

2.7.3 W-Cell API

This is available only for W cells. As before, a public key contains both thekey material and an algorithm description.

• GetIA(PK): A W cell can be obtained via a GetIA(PK) query. IfPK is not a well-formed public key, the GMWS server returns an error.Otherwise, it computes OA = H′(PK), IA = DK2(OA) and CIA =EncryptPK(IA). It sends CIA as its response to the query.

Let SK be the private key corresponding to PK. If the receiver knowsSK, it can compute IA = DecryptSK(CIA) and OA = H′(PK). Thenthe pair (IA,OA) is a W cell.

2.7.4 Common API

In the following, the possible values of CellType are RW, R and W.

• Subscribe(QA,CellType,OA): The server subscribes queue QA to aCellType cell with output address OA. If the queue is already sub-scribed to that cell, the server returns an error.

• Unsubscribe(QA,CellType,OA): The server unsubscribes queue QAfrom a CellType cell with output address OA. If the queue is notsubscribed to that cell, the server returns an error.

• Link(FA,CellType, IA): The server links forwarder FA to a CellTypecell with input address IA. If the forwarder is already linked to thatcell, the server returns an error.


• Unlink(FA,CellType, IA): The server unlinks forwarder FA from aCellType cell with input address IA. If the forwarder is not linked tothat cell, the server returns an error.

• Send(CellType, IA,m): The server computes OA = EK(IA) for K ∈{K0, K1, K2}, where K is selected based on CellType (see above). Ifthere are no queues subscribed to the CellType cell with output addressOA, the message m is silently dropped, otherwise it is forwarded to allqueues subscribed to this cell. The queues store these messages alongwith CellType, OA for later retrieval.

• GroupSend(FA,m): The server sends m to all the cells linked to FA.If there are no cells linked, the message is silently dropped.

• Read(QA): The server returns all the messages stored in the queuesince the last read along with the corresponding CellType and OA.

• GetSubs(QA): The server returns the CellType and IAs of all cellssubscribed to QA.

• GetLinks(FA): The server returns the CellType and OAs of all cellslinked to FA.

3 Remote invocation controls in GMWS

GMWS provides remote invocation (or query) controls for read and write(equivalently receive and send). These controls allows entities to limit theability of other entities to: (a) send messages itself or another resource; or,(b) receive messages from itself or another resource.6

3.1 Read Access Control

Example: Let A be some resource such as a server that occasionally broad-casts updates. By allowing some entity to receive the broadcasts, A grantsread ability to that entity. In our example, A grants read ability to B.

Initial setup: A sends its updates to a secret and randomly selected for-warder FAA. That is, an updatem is sent by making aGroupWrite(FAA,m)

6The ‘read’ and ‘write’ functionalities in our case can be considered analogous to therecvmsg() and sendmsg() functions in Unix sockets.


query to the GMWS. Furthermore, B listens to its secret queue QAB for re-ceiving messages from A (and other entities). That is, B receives updates bymaking a Read(QAB) query to the GMWS.

3.1.1 Granting Read Ability

This process has two steps: (1) generating a read capability; and, (2) in-stalling that capability. These are discussed below.

Generating read capability: When A wishes to grant read access to B,it first generates a read capability for B. This is done as follows:

1. A makes a GetCell query to obtain a random RW cell (IA′, OA′).

2. A makes a Link(FAA, CellType.RW, IA′) query to link this cell with

FAA.

3. A stores the pair (B, IA′) in a local database.

OA′ is the read capability.

Installing the capability: The capability OA′ is installed as follows:

1. A transfers the capability OA′ to B in a secure manner. The R and WCells corresponding to A and B are used for this purpose.

2. B makes a Subscribe(QAB, CellType.RW,OA′) query to subscribe to

the RW cell with output address OA′.

After this step, all updates sent by A will be received by B until A revokesthe above capability. Thus, A has provided read ability to B. See Figure 7for a sketch of the above protocols.

3.1.2 Revoking Read Ability

If at some point, A decides to revoke the read ability granted to B, it can doso by revoking the capability sent to B. This is done as follows:

Revoking read capability:

1. A obtains the entry (B, IA′) from its database.

2. A makes a Unlink(FAA, CellType.RW, IA′) query to unlink the RW

cell with input address IA′ from FAA.

After these actions are performed by A, the capability OA′ is rendered uselesssince B can no longer receive A’s updates.


Figure 7: Use of read access control

3.2 Write Ability Control

Example: A is a server that accepts requests and would like to control whocan make these requests. By allowing an entity to send requests, A grantswrite access to that entity. In our example, A grants write access to C.

Initial setup: A receives requests from a secret queue QAA. That is, arequest is received by making a Read(QAA) query on the GMWS. Further-more, C writes to a secret forwarder FAC to write to A. That is, C will sendrequest r by making a GroupWrite(FAC , r) query to the GMWS.

3.2.1 Granting Write Ability

This process has two steps: (1) generating the write capability; and, (2)installing this capability. These are discussed below.

Generating write capability: When A wishes to grant write access toC, it first generates a write capability for C. This is done as follows:

1. A makes a GetCell query to obtain a random RW cell (IA′′, OA′′).

2. A makes a Subscribe(QAA, CellType.RW,OA′′) query to subscribe to

this cell.


3. A stores the pair (C,OA′′) in a local database.

IA′′ is the write capability.

Installing the capability: The capability IA′′ is installed as follows:

1. A transfers the capability IA′′ to C in a secure manner. As before, theR and W cells corresponding to A and C can be used for this purpose.

2. C makes a Link(FAC , CellType.RW, IA′′) query to link to the RW cell

with input address IA′′.

After this step, any requests sent by C will be received by A until A revokesthis capability. Thus, C has write ability to A. Note that C can send directlyvia IA′′ or via its forwarder FAC .

3.2.2 Revoking Write Ability

If at some point, A decides to revoke the write ability granted to C, it cando so by revoking the capability sent to C. This is done as follows:

Revoking write capability:

1. A obtains the entry (C,OA′′) from its database.

2. A makes a Unsubscribe(QAA, CellType.RW,OA′′) query to unsub-

scribe from the RW cell with output address OA′′.

After this, the capability IA′′ becomes useless since C can no longer use thisability to send requests to A.

3.3 Transferring Capabilities

In the above, A sends a capability to B, which can be done out-of-bandlike encrypted emails and so on. However, GMWS provides a way to sendsuch capabilities provided the public keys of the entities are known. In thefollowing, PKA, PKB are certified public keys of A,B respectively, whichthey will use to communicate via GMWS.


Initialize: This step is done before any capability transfer can take place.

1. A makes GetOA(PKA) query to get the R cell (IARA, OA

RA). Similarly

B obtains (IARB, OA

RB).

2. A,B use secret queue addresses QA∗A, QA∗B respectively which they will

use for capability transfer.

3. A,B make Subscribe(QA∗A, CellType.R,OARA), Subscribe(QA∗B, CellType.R,QA

RB)

queries respectively.

Capability Transfer: Let c be a capability (e.g. OA′) that A wishes totransfer to B. This is done as follows:

1. A constructs m1 = (A, c) and makes a WritePub(PKB,m1) query.

2. B receives (CellType.R,OARB,m1) via QA∗B and parses m1 as (A, c).

3. B selects a random nonce n, constructsm2 = n and makes aWritePub(PKA,m2)query. Note that this query can be made over an insecure channel.

4. A receives (CellType.R,OARA,m2) via QA∗A and parses m2 as n.

5. A constructsm3 = Hash(n, c) and makes aWritePub(PKB,m3) query.Note that this query can be made over an insecure channel.

6. B receives (CellType.R,OARB,m3) via QA∗B and verifies that m3 =

Hash(n, c).

After the above protocol, B assumes the capability c to be authentic. Thisconcludes our protocol descriptions.

4 Summary

We have described GMWS, a capability-based publish-subscribe service withsome interesting features and many interesting extensions and applications.GMWS can create an ecosystem for HP by bridging the gap between devices,web-services, peer-to-peer/peer-to-group resource and information sharing,security, and usability. The most immediate consequence of using GMWSwould rich device group interactions – today the state-of-the-art has onlymanaged to achieve secure device to cloud interactions. HP can now have anoption to leverage the current trends in cloud computing to its advantage byhaving a devices-cloud focus.


The rich extensibility and user experience remarkably comes with solidsecurity understanding. In fact, GMWS is an extensible messaging systemwith inbuilt security. This outcome is by design as we believe that the bestsecurity mechanisms as those that are invisible to its users. We have at-tempted to provide formal security reductions from the security properties ofGMWS to the security properties of underlying security algorithms such asthe Advanced Encryption Standard7 and Secure Hash Algorithm8. Such anattempt may provide useful insights for bridging the research literature forcomputer access security and cryptography, which have seldom synergizedinto useful mechanisms for end-users.

We have successfully prototyped the Capability Generation Service usingthe Scala programming language and the open-source BouncyCastle Cryp-tography API. We are commencing GMWS system prototyping.

5 Realizing group communications using sim-

ple cell structures

A cell is unaware of its configuration by its user. The following are possibleconfigurations for a cell by its users (clients that receive (IA,OA) informationfrom the server).

1. (Standalone cell) It can send its outputs to one or more queues andreceive inputs from many sources that possess IA information.

2. (Network of cells) It can send its outputs to one or more queues orcells and it can receive inputs from other cells and from other sourcesthat possess IA information.

For group formation and group control, standalone cells are essential. Net-work of cells can utilize standalone cells to form controlled networks, whichcan result in complex esgroup structures.

5.1 Standalone cell

Suppose that n GMWS users (or clients) wish to agree on a secret cell (orcommunication point or rendevouz) using the services of GMWS. What pro-tocol can they follow?

Let N .= {1, · · · , n} and {yi | ∀i ∈ N} be the set of user public keys.

Let (RIi = H(yi), ROi) and (WIi,WOi = H(yi)) be the respective read and

7http://en.wikipedia.org/wiki/Advanced_Encryption_Standard8http://en.wikipedia.org/wiki/Secure_Hash_Algorithm


http://en.wikipedia.org/wiki/Advanced_Encryption_Standard

http://en.wikipedia.org/wiki/Secure_Hash_Algorithm

write cells9. In Step 1, one of the n users sends a CreateGroup command

1. ∃1i ∈ N → GMWS : CreateGroup({yj|∀j ∈ N})2. GMWS → {RIj | ∀j ∈ N} : MakeGroup((IA,OA), FA, {yj}, r

| (IA,OA)← GetCell(),

FA← Link(FA,CellType.R, {RIj | ∀j ∈ N}),r ← Random())

3. ∀j ∈ N → GMWS : Subscribe(OA,CellType.RW , Qi)

4. ∀j ∈ N → GMWS : GroupSend(FA,Accept(H(IA,OA, yj, r), j, r))

Protocol 1: GMS Group Creation Protocol

to GMWS for creating a group by identifying the group members, includingitself, with a set of public keys. In response to this message, the GMWScreates a cell (IA,OA), henceforth called group cell using the GetCell(.)query on itself and a forwarder address FA using the Link(.) query on itself.In Step 2, GMWS sends a MakeGroup command to the clients representingeach group member with the indicated inputs. The random number r servesthe group identifier for the group members. In Step 3, each group memberattaches its queue to the output of the group cell using the Subscribe queryon GMWS. In Step 4, each group member signals its intention to acceptthe group configuration and its subscription to the group cell by sending anAccept message to the group defined by FA, which they received in Step2. The hash function output can be checked by others usign their secretgroup cell addresses. It is possible to merge Steps 3 and 4 into a singlecommunication as an optimization as these two steps are asynchronous.

5.2 Network of cells

A cell in network configuration can be used for group communications by con-necting multiple cells to a single cells input or by connecting the output of asingle cell to the inputs of multiple cells. The merit of this configuration isthat it can provide fine-grained control on revoking the sending or receivingcapability from individual senders/receivers without having to disturb theconfiguration of other senders and receivers. It can also formalize the role ofgroup manager(s), who can grant or revoke capability to send to or receive

9GMWS getIA and getOA queries guarantee that the entity knowing the private keyxi corresponding to yi is the only entity that can know ROi and WOi – we assume thatthe client would not deliberately leak these secret values in its own interest.


from the group to individual senders/receivers. The demerit of this configu-ration is that it needs two or more address decryptions (or translations) tooccur before the message is delivered to one or more queues. Additionally,because users can configure cells so that cell loops can be formed, messagescan be forwarded from cell to cell indefinitely thus wasting server resources,delaying delivery of messages, or delivering multiple copies of a message thatwas sent only once. The server can remedy the first problems by provisioninga time-to-live on every message entering the server so that it can only visit afinite number of cells before the server drops the message. The server or clientcan remedy the last problem by filtering multiple copies of a single messageusing a unique message identifier. The delay problem can be remedied bycarefully constructing networks to avoid loops.

5.3 Example Usecase

The power of cells, cell-to-cell forwarding, and queues can be summarized bydescribing a simple structure for a complex group communication pattern.Let A B and C belong to the group managed by G1. Let D and E belong toa group managed by G2. Let all communications from G1 reach G2 such thatno communication from G2 can reach any entity in G1 including G1. Also,assume that G1 wishes to grant B the ability to write to its group but notthe ability to read from its group. How can G1 and G2 form such arbitraryand complex cascade of complex groups at runtime without involving anyexpert?

We claim that G1 and G2 can just collaboratively draw their groups inorder to generate the respective GMWS rules for their group communications!Although we have not yet developed such a convenient tool for G1 and G2yet, we can describe the drawing that they will have to make as shown inFigure 8. The syntax for the drawing is as follows:

• G1 generates cells 1, 2, 3, 4, 5, and 6 using the GMWS CapabilityGeneration Service.

– G1 shares IA1 (for cell 1) with A, IA2 with B, and IA3 with C.

– G1 creates a forward link from the outputs of cells 1, 2, and 3 tothe input of cell 4, which is its group control cell. Note that onlyG1 can create these forward links. Thus A, B, and C can writeto its group.

– G1 creates forward links from the output of cell 4 to the inputs ofcells 5 and 6, which are the group read control cells.


Figure 8: Hierarchical groups with complex requirements and a simple draw-ing

– G1 shares the output addresses OA5 and OA6 with A and C re-spectively via individually confidential channels. Thus only A andC can read the communications from A, B, and C.

• G2 generates cells 7, 8, 9, 10, 11, and 12.

– G2 shares IA7, IA8, and IA9 with D, G1, and E respectively.

– G1 creates a forward link from cell 4 to cell 8 using IA8, whichwas shared by G2.

– G2 creates forward links from the outputs of cells 7, 8, and 9 tothe input of cell 10, which is its group control cell. Note that onlyG2 can create these forward links. Thus D, E, and members ofG1 can write to its group.

– G2 creates forward links from the output of cell 10 to the inputsof cells 11 and 12, which are the group read control cells.

– G2 shares the output addresses OA11 and OA12 with D and Erespectively via individually confidential channels. Thus only Dand E can read the communications from D, E, and members ofG1.

• Whenever G1 wishes to terminate its agreement with G2 it can destroythe forward link between cells 4 and 8, which is purely under its control.


• Whenever G2 wishes to terminate its agreement with G1 its can de-stroy the forward link between cells 8 and 10, which is purely under itscontrol.

• G1 and G2 can revoke the ability of its members by destroying thelinks under their respective controls.

• G1 and G2 can individually add and remove members to its groupswithout having to synchronize such information with other group mem-bers. This is newly found power in secure group communications.

Although we have depicted organized groups in the above example, itis also possible to have unorganized groups such as in social networks. Inthis case, every individual will have to control its ability to send to and toreceive from a randomly formed group (or clique, as it is called in socialnetworks). This is an interesting and complex problem that shall be thesubject of another report.

Acknowledgments

We thank Alan Karp for his support for our ideas. He introduced us tothe important theories behind capability-based access control, which werecompletely new to us that we had to unlearn more than we had to learn. Dueto his mentoring, we now feel that we may have discovered (or rediscovered)an important link between access control and cryptography.

We thank Prith Banerjee for directing us to Alan Karp. Our sincerethanks goes to Sudhir Dixit, who supported this work in many dimensions asthe lab director. Our discussions with Jim Waldron (GNBU/PSG, Houston)provided us with the ability and inspiration to explain our system in simplelanguage, which we now feel is fundamentally important for improving thechances for success. We thank Jim for sharing his feedbacks on the ideas.

Last but not the least, we thank colleagues at HPL India, who listenedpatiently to our ramblings and still provided valuable suggestions and com-ments.

References

[1] R. S. Fabry. Capability-based addressing. Commun. ACM, 17(7):403–412, 1974.


[2] Andrew S. Tanenbaum, Sape J. Mullender, and Robbert van Renesse.Using sparse capabilities in a distributed operating system. In ICDCS,pages 558–563, 1986.

[3] Dan Boneh and Matthew Franklin. Identity-based encryption from theweil pairing. SIAM J. Comput., 32(3):586–615, 2003.

[4] Adi Shamir. Identity-based cryptosystems and signature schemes. InProceedings of CRYPTO 84 on Advances in cryptology, pages 47–53, NewYork, NY, USA, 1985. Springer-Verlag New York, Inc.

[5] Sattam S. Al-Riyami and Kenneth G. Paterson. Certificateless public keycryptography. In Chi-Sung Laih, editor, ASIACRYPT, volume 2894 ofLecture Notes in Computer Science, pages 452–473. Springer, 2003.


Appendix

A RW-Cell Security Reduction

We define the security of RW-Cells using Game RW below. The game cap-tures both read and write control and intuitively requires that given IA orOA, it should be infeasible for someone to guess the other. A possible wayto model this would be to give the attacker the following: (1) some ran-dom valid (IA,OA) pairs, (2) some random IAs, and (3) some random OAs.Then require him guess one of the following: (1) a new valid (IA,OA) pair,(2) an OA corresponding to given IAs, or (3) an IA corresponding to thegiven OAs. Observe that requirements (2) and (3) are redundant because ifthe attacker guesses, say, OA′ corresponding to a given IA′, then (IA′, OA′)form a valid new pair, which he can output as requirement (1). Finally, notethat requiring the attacker to guess, say, an IA for the given OAs is morerestrictive than requiring him to use OAs of his own choice. Therefore, toobtain the strongest security, we allow the attacker to generate any valid(IA,OA) pair that he has not queried.

Game RW

1. Initialize: The challenger selects security parameter k and a key K0 ∈R

{0, 1}k. It gives k to the attacker.

2. Queries: The attacker makes at most n GetCell queries: The chal-lenger responds as described in Section 2.7.1. That is, it generates

IA$← {0, 1}k, sets OA← EK0(IA) and responds with (IA,OA).

3. Output: The attacker outputs a pair (IAA, OAA) and wins the game ifthis pair was not output in the queries phase and OA = EK0(IA).

Define AdvrwA,n(k) = Pr[A wins Game RW]. The RW cell space is said to bebroken if AdvrwA,n(k) is non-negligible in k.

A.1 Security requirement of ERoughly speaking, we require EK0 to be a bijection, trapdoor computableand trapdoor invertible. Furthermore we need it to be non-computable andnon-invertible without the trapdoor K0. Specifically, we use the followinggame for the security of E . The game is similar to that of a MAC for securityagainst existential forgery.


Game ENC

1. Initialize: The challenger selects security parameter k andK ∈R {0, 1}k.It gives k to the attacker.

2. Queries: The attacker makes at most n ENC(m) queries for ms of hischoice. It obtains c = EK(m).

3. Output: The attacker outputs a pair (cA,mA). It wins if cA = EK(mA)and mA was never queried.

Define AdvencA,n(k) = Pr[A wins Game ENC].

A.2 Pseudo-Random Permutation

A pseudo-random permutation (PRP) is a map P : {0, 1}k×{0, 1}k 7→ {0, 1}ksuch that for all K ∈ {0, 1}, the map PK : x 7→ P (K, x) is a bijection andan attacker cannot distinguish the output of PK() (given oracle access) fromthat of a random permutation of k-bit strings (see below).

PRP security: The security of a PRP is defined using Game PRP.

Game PRP

1. Initialize: The challenger selects bit b ∈R {0, 1} uniformly and a se-curity parameter k. If b = 1, the attacker selects K ∈R {0, 1}k andsets F() = PK(). Otherwise it sets F() to be a random permutation ofk-bit strings.

2. Queries: The attacker makes at most n PRP(m) queries for m ∈{0, 1}k. The challenger responds with F(m).

3. Output: The attacker outputs a bit a and wins if a = b

Define AdvprpA,n(k) = |Pr[A wins Game PRP]−1/2|. P is said to be brokenif AdvprpA,n(k) is non-negligible in k.

Lemma 1. AdvprpA,n(k) ≥ 12

∣∣∣AdvEA,n(k)− 12k−n

∣∣∣.Proof. Let E = P . Given an attacker A for Game ENC with advantageAdvencA,n(k), we can construct a PRP attacker B. B simulates the challenger ofGame ENC with A. When A makes a ENC(m) query, B makes a PRP(m)query and returns the result to A. When A outputs a (cA,mA) pair suchthat cA = EK(mA) and mA was never queried by A, then B makes a PK(mA)query to obtain cB. If cB = cA, then B outputs 1, otherwise it outputs 0.


If the bit b selected by the PRP challenger was 0, then with high proba-bility cA 6= cB. Specifically, for n queries by A, Pr[cA = cB|b = 0] = 1

2k−n .

Note that by definition, AdvEA,n(k) = Pr[cA = cB|b = 1]. Now,

AdvprpB,n(k) ≥∣∣∣∣Pr[(cA = cB ∧ b = 1) ∨ (cA 6= cB ∧ b = 0)]− 1

2

∣∣∣∣=

∣∣∣∣Pr[cA = cB|b = 1] · Pr[b = 1] + Pr[cA 6= cB|b = 0] · Pr[b = 0]− 1

2

∣∣∣∣=

∣∣∣∣∣AdvEA(k)

2+

1− 12k−n

2− 1

2

∣∣∣∣∣=

1

2

∣∣∣∣AdvEA(k)− 1

2k − n

∣∣∣∣Theorem 1. AdvrwA,n(k) = AdvencA,n(k).

Proof. Let A be an attacker that wins Game RW with probability ε. UsingA, we construct another attacker B that breaks E (under Game ENC) withthe same probability.

B simulates the attacker of F and obtains k. It simulates the challengerof GMWS with A and gives k to A. It answers A’s queries as follows:

1. When A makes the ith GetCell query, B generates a random stringmi and makes a F(mi) query to its challenger to obtain ci = F(mi).It returns (IAi, OAi) = (mi, ci) to A.

Finally A outputs (IAA, OAA).

1. If A outputs valid (IAA, OAA) pair that was not output of a GetCellquery, then B returns (mB, cB) = (IAA, OAA) to its challenger.

2. If A outputs valid (IAA, OAA) where OAA was output from a GetOAor if IAA was output from a GetIA query, then B returns (mB, cB) =(IAA, OAA) to its challenger.

3. Otherwise B outputs failure and terminates.

Clearly, the simulation that A sees is indistinguishable from a real in-stance of Game RW. Therefore, Pr[A wins] = ε. Also note that if A wins,then B also necessarily wins. Therefore, Pr[B wins] = ε. Finally, note thatB makes n1 queries to its challenger. This completes the proof.


B R-Cell and W-Cell Security Reductions

We only prove the security of R-cells. The security of W-cells then followsfrom a symmetric argument. We define the security of R-Cells using GameB below.

Game R

1. Initialize: The challenger selects security parameter k and a key K1 ∈R

{0, 1}k. It also selects a target public key PKT$← G ′(k) of an IND-

CPA secure asymmetric encryption scheme (G ′, E ′,D′). It gives k, PKT

to the attacker along with the description of (G ′, E ′,D′).

2. Queries: The attacker makes at most n GetOA(PK) queries. Thechallenger responds as described in Section 2.7.2. That is, if PK isa well-formed public key, then it computes IA = H(PK) and OA =EK1(IA). It responds with COA = EncryptPK(OA), otherwise it re-sponds with an error.

3. Output: The attacker outputs OAA and wins if OAA = EK1(H(PKT )).

Define AdvrA,n(k) = Pr[A wins Game R]. The RW cell space is said to bebroken if AdvrA,n(k) is non-negligible in k.

B.1 Security of Public Key Encryption

We define the security of (G ′, E ′,D′) using a new notion IND-CPA2, which isequivalent to IND-CPA. Both are described below.

IND-CPA for asymmetric encryption:

Game CPA

1. Initialize: The challenger selects security parameter k and a target

public key PKT$← G ′(k). It gives k, PKT to the attacker.

2. Challenge: A sends two equal length messages (m∗L, m∗R). ChallengerC chooses b ∈R {L,R} and responds with c∗ = E ′PKT

(m∗b).

3. Output: A outputs a ∈ {L,R} and wins if a = b.

Define AdvcpaA (k) =∣∣∣Pr[A wins Game CPA]− 1

2

∣∣∣Page 29 Group Messaging Web Service

IND-CPA2 for asymmetric encryption:

Game CPA2

1. Initialize: The challenger selects security parameter k, a target public

key PKT$← G ′(k) and b ∈R {L,R}. It gives k, PKT to the attacker.

2. Challenge queries: A makes at most n queries as follows: A sendstwo equal length messages (m∗L, m∗R). Challenger C responds withc∗ = E ′PKT

(m∗b).

3. Output: A outputs a ∈ {L,R} and wins if a = b.

Define Advcpa2A,n (k) =∣∣∣Pr[A wins Game CPA2]− 1

2

∣∣∣Lemma 2. AdvcpaA (k) ≤ Advcpa2A,n (k) ≤ n · AdvcpaA (k).

We leave the proof as an exercise.

B.2 Security of The Hash Function

A hash function is formally defined as a family of functions {Hk}k∈N, wherefor each k,Hk : {0, 1}∗ 7→ {0, 1}k defines a mapping between arbitrary stringsto k-bit strings. We require the hash function to be collision resistant, whichis defined using the following game.

Game CR

1. Initialize: The challenger selects security parameter k and gives it tothe attacker.

2. Output: A outputs m1,m2 ∈ {0, 1}∗ and wins if Hk(m1) = Hk(m2).

Define AdvcrA (k) = Pr[A wins Game CR]

B.3 Security of R-Cells

Lemma 3. AdvrA,n(k) ≤ Advcpa2A,n (k) + AdvencA,n(k) + AdvcrA (k)

Proof. We prove the security of R-cells using a sequence of games G0 andG1 described below.

Game G0:


This game is exactly the same as Game R. In particular, whenever Amakes a GetOA(PKT ) query, we compute OA = EK1(H(PKT )) andresponds with EncryptPKT

(OA).

Therefore,Pr[A wins Game G0] = AdvrA,n(k) (1)

.Now consider Game G1 below, where we slightly modify the challenger.

Game G1

1. Initialize: As in Game R. The challenger additionally selects a randomOA′ ∈R {0, 1}k.

2. Queries: The attacker makes at most nGetOA(PK) queries. If PK 6=PKT , the challenger responds as described in Section 2.7.2. That is,if PK (6= PKT ) is a well-formed public key, then it computes OA =EK1(H(PK)). It responds with COA = EncryptPK(OA), otherwise itresponds with an error. On the other hand, if PK = PKT , then itresponds with COA = EncryptPKT

(OA′).

3. Output: The attacker outputs a pair (OAA) and wins the game ifOAA = EK1(H(PKT )).

Observe that the only difference between Games G0 and G1 is that in theformer, the challenger behaves correctly, while in the latter, the challengerencrypts a random value instead of the correct OA. If an attacker can dis-tinguish between the two games, then we can use this attacker to win GameCPA2 with the same advantage as follows:

We play the attacker of Game CPA2 and the challenger for a distinguisherof Games G0 and G1. Let OA,OA′ be as defined above. Whenever thedistinguisher makes a GetOA(PKT ) query, we make a CPA2 challenge queryon (OA,OA′) and respond with whatever we receive. If the CPA2 challengerselected b = L, then the resulting game is identical to Game G0, otherwiseit is identical to Game G1. Consequently, any attacker who can distinguishbetween the two games can be used to win Game CPA2. Therefore,

|Pr[A wins Game G0]− Pr[A wins Game G1]| ≤ Advcpa2A,n (k) (2)

Finally observe that an attacker who can win Game G1 can be used towin one of Game ENC or Game CR as follows.


We play the attackers of Games ENC and CR and the challenger forGame G1. Let k be the common security parameter for Games ENC andCR and let K be the key selected by the challenger of Game ENC. We defineK1 = K, H = Hk and select a k-bit string OA′ ∈R {0, 1}k. We then generate

a random public key PKT$← G ′(k) and give k, PKT to the G1 attacker.

When the G1 attacker makes a GetOA(PK) query, we proceed as follows:

1. If PK is not well-formed, we return an error.

2. If PK = PKT , we return COA = EncryptPKT(OA′).

3. We define IA = Hk(PK) and OA = EK(IA). The latter is computedby making an ENC(IA) query to the challenger of Game ENC. Finally,we return COA = EncryptPK(OA) and store the value PK.

Finally, the G1 attacker outputs OAA. If OAA is winning configuration ofGame G1, we continue, otherwise, we report an error and exit. By definition,the G1 attacker wins if OAA = EK(Hk(PKT )).

Given that the G1 attacker has won, one of the following mutually exclu-sive events must have occurred:

1. The G1 attacker did not make any GetOA(PK) query such thatHk(PK) = Hk(PKT ). Consequently, we did not make any ENC(Hk(PKT ))query to the challenger of Game ENC. This implies that (c,m) =(OAA,Hk(PKT )) is a winning configuration of Game ENC. We return(c,m) and win Game ENC.

2. The G1 attacker made one of more GetOA(PK) queries such thatHk(PK) = Hk(PKT ). This implies that (PK,PKT ) is a collision ofHk. We return this tuple and win Game CR.

This implies that when the G1 attacker wins Game G1, we win eitherGame ENC or Game CR. Consequently,

Pr[A wins Game G1] ≤ AdvencA,n(k) + AdvcrA (k) (3)

From Equations 1, 2 and 3, it follows that:

AdvrA,n(k) ≤ Advcpa2A,n (k) + AdvencA,n(k) + AdvcrA (k) (4)

This completes the proof.


group message web service: group communication services ... · provides an answer to the following...

Documents