Embed Size (px)
Citation preview
End-to-End Confidentiality for a Message Warehousing Service Using Identity-Based
Encryption Yuecel Karabulut#1, Harald Weppner#2, Ike Nassi#3, Anusha Nagarajan*1, Yash Shroff*2, Nishant Dubey*3,
Shields*4 #SAP Office of the Chief Scientist, SAP Labs
Palo Alto, CA, USA [email protected] [email protected]
[email protected] *Carnegie Mellon University
Pittsburgh, PA, USA [email protected] [email protected]
[email protected] [email protected]
Abstract— More and more classes of devices become capable of connecting to the Internet. Due to the observation that a point-to-point communication is insufficient for many non-interactive application integration scenarios we assume the existence of a logically centralized message warehousing service, which clients can use to deposit and retrieve messages. The particular challenge in this context is that a client depositing messages can only describe eligible receiving clients using their characterizing attributes and does not know their specific identities. The depositing client still wants to prevent exposure of the message content to the message warehousing service. We explore how this many-to-many integration between devices and enterprise systems can achieve end-to-end information confidentiality using a solution based on Identity-Based Encryption.
I. INTRODUCTION Software as a Service (SaaS) is a model of software
deployment where an application is hosted as a service typically provided to clients as a web-based service. A SaaS provider is responsible to manage the program operation and data to ensure that clients have continuous access to the service.
We have implemented a specific kind of software service, namely a Message Warehousing Service (MWS). It has two primary operations to deposit and retrieve messages alongside a set of administrative operations to manage client identities. The MWS provide services to clients acting in two roles: a depositing client (DC) and a retrieving client (RC). It is the responsibility of the DC to instruct the MWS what criteria a RC has to meet to become a RC for a given message.
The main security requirement of our application is to achieve message confidentiality in a scenario where a DC does not know the specific identities of eligible RCs. One of the key constraints for the underlying message exchange model is for the DC to have the ability to send information
confidentially, i.e. the MWS should not possess the ability to read a deposited message, but have enough information to manage access control, i.e. grant clients the role of a RC for any deposited message. Another constraint is the computational ability of a client to send messages securely.
We present a security solution in order to address the security requirement and the constraints discussed above. Our solution employs a unique combination of Identity Based Encryption (IBE) [2] and symmetric cryptography. Although IBE has been mainly used for encrypting e-mails, we show how IBE can be used for enterprise applications deployed as software services running in the Cloud. Instead of using identities we use a set of attributes that assists in categorizing a set of eligible RCs. According to our approach a DC encrypts a message using the public key derived from an attribute which is a prominent characteristic of the authorized RC.
We believe that traditional certificate based public-key cryptosystems [7][8] are not useful in dynamic contexts like our application, mainly because of two reasons. First, most present day clients do not have the capability to handle the public key certificates due to limited bandwidth and low processing power. Furthermore, deploying public key infrastructures and managing certificates is expensive and difficult. Second, due to the dynamic and flexible nature of the policies and attributes describing clients, we have to assume that clients are not aware of the specific identities of the eligible recipients of a message. Our approach allows DCs to deposit messages to be retrieved by multiple RCs without knowing their identity.
The rest of the paper is organized as follows. Section II describes the underlying application scenario. Section III discusses the security and operational requirements derived from the application scenario. In Section IV we revisit the
Tyelisa
978-1-4244-6523-1/10/$26.00 © 2010 IEEE ICDE Workshops 201033
Identity Based Encryption. Section V presents the design and architecture of our solution. The implementation is described in Section VI. Section VII is dedicated to related work. Finally, Section VIII concludes the paper and discusses future work.
II. APPLICATION SCENARIO To explain our solution approach, we consider an
application scenario where the depositing client is an embedded system such as an electric or water meter that is capable of electronically submitting meter readings and other information bundled as messages. We will further be using the example of smart meters as a representation of a class of embedded systems we will simply refer to as a “smart device” from here on.
While analyzing the scenario it was observed that messages from a smart device may be relevant to multiple stakeholders in the Utilities industry value chain, e.g. to the meter operator to ensure correct operation of the meter, to the energy retailer to bill the customer to the local grid operator to analyze the grid status and to the energy consumer to monitor detailed resource usage.
Since there are no real-time requirements and both smart devices and enterprise applications acting as clients are typically unreachable because they are located behind firewalls the general architecture involves an intermediary, the MWS. It is positioned as a logically centralized solution to which all clients have access.
In Figure 1, a hypothetical full-service energy, water and gas retailer named C-Services generates the consolidated utility bills for each apartment that has water, electricity, and gas meters. C-Services will require messages from all classes of meters and thus requires access to all meter messages. In the same sense, Electric & Gas Company may have access to messages from electric and gas meters; whereas Water & Resources Company will only be allowed to view messages from the water meter.
Fig. 1 Utility company scenario
In such a case the smart devices, would be depositing clients (DC) and the C-Service and related Energy & resource companies are the Receiving Clients (RC).
As mentioned earlier, the unique aspect of this model is that the smart devices do not know the identity of the utility companies, when depositing a message to the MWS.
III. REQUIREMENTS We distinguish between two kinds of requirements:
Security requirements and operational requirements. Security requirements are following: i. Message confidentiality: The MWS should thus
unable to read the message contents, but should still have sufficient information for identifying the authorized receiving clients.
ii. Message integrity: The MWS must be able to thwart the tampering of messages from depositing clients i.e. tampered messages from smart devices should be detectable.
iii. Access rights revocation: When access to a message for a receiving client is revoked, e.g. because an access policy has changed, the affected client should not be able to access future messages sent by that particular smart device. In the scenario outlined in Section II, C-Services may decide to discontinue its service for the apartment complex. In such a case the messages that arrive from smart devices belonging to this apartment complex should no longer be accessible to C-Services.
Operational requirements are following: iv. Scalability: We assume a very large number of smart
devices and a large number of other classes of clients. The anticipated security solution is expected to address the scalability in the design of the system.
v. Dynamic recipients: The model should provide enough flexibility for smart devices to send messages to potential clients who are not yet a part of the service environment. In the case of our application scenario an energy management company may join in the future.
IV. IDENTITY-BASED ENCRYPTION REVISITED Identity Based Encryption (IBE) [2] is a public
cryptosystem based on elliptic curves, in which any arbitrary string can be used as a public key. The encryption key of a message is based on this public key, which can be represented by this very fact. The string may take any form such as an email address, ‘[email protected]’, or even a sentence, ‘this_paper_is_based_on_IBE!'. When a public key is mapped to an email address or any representation of identity it is then considered to be IBE. If the string describes an attribute that the message represents, it is called Attribute-Based Encryption (ABE). Many approaches to IBE have been suggested Adi Shamir first proposed it in 1984, but very few have been adopted. The most popular approach currently is with the help of bilinear pairings on elliptic curves and pairing algorithms. The most prominent algorithms presently at use is, Weil Pairing and Tate Pairing, where the latter is more efficient in terms of generation of pairs. Boneh and Franklin developed an encryption scheme in 2001 based on Weil paring, which has been used as a basis for this system.
The fundamental structure of IBE consists of four basic algorithms: setup, encryption, key extraction, and decryption. Within the setup algorithm, a trusted party generates system parameters which are publically known, with the help of
34
master secret which is held by the party. In normal cases, the trusted party is referred to as, a Private Key Generator (PKG), and acts as a key escrow service, which is in charge of public parameters. The next step is to encrypt messages with the use of the public parameters and a pubic ID. To decrypt a message, a private key is required from the PKG, where user authentication may occur. The PKG uses the key extraction algorithm, in order to extract the required private keys. Once the private key is obtained from the PKG, users can proceed to the decryption phase. The following describes a more detailed description of the algorithms as per Boneh & Franklin’s paper [2].
• Setup: This algorithm is required by the PKG to initialize the IBE environment. The environment consists of several parameters including a Base-point (P), Master Secret (s) and elliptic curve equation. Based on this, a Public key for the entire environment is generate (sP), where the master key cannot be extracted even with the knowledge of the Base Point.
• Encrypt: For a message cipher text to be generated, the message, a public key is generated based on the parameters mentioned above (QID), and a random integer (r). The random number is attached to the system parameter (P), to create rP. The sender then generates the ciphertext as follows:
C = (U, V) = (rP, E {M, h [e (QID, sP) r]}) Here C is the ciphertext, E represents any encryption
algorithm, such as DES or Blowfish and e represents the Weil pairing function.
• Extract: The extract algorithm occurs at the PKG, when a private key (sQID) is required. The algorithm uses the generated system parameters, the master secret and the public ID as inputs to this algorithm.
• Decrypt: The decryption is possible with the help of the private key (sQID) obtained from the PKG, and U from the original cipher text. Another component that is required is the corresponding decryption algorithm (D). The following describes the equation required to generate the message M: M = D{ V, h[e(sQID, U)]}
V. DESIGN Since a receiver’s specific identity is not known, we
propose using attributes that characterize the potential eligible receiving clients. The smart devices, however, will be aware of the attributes related to their recipients. These attributes persist even when Receiving Clients (RCs) change over a period of time. We formulate these attributes in the form of strings. Identity Based Encryption provides us with a way of encrypting messages from smart devices with a public key generated using this attribute-derived string.
A. Solution Overview The system proposed consists of four entities - Smart
Device (SD), Message Warehousing Service (MWS), Private Key Generator (PKG) and the Receiving Client (RC). The
Smart device in this case represents the Depositing Client (DC). Before transactions between involved parties can occur, a relationship between the SD, MWS and PKG has to take place. This may be in the form of a contract or license that all parties accept.
Fig. 2 Private key retrieval A high level diagram of our model is shown in Figure 2.
The smart device generates encrypted messages and deposits them using the MWS. The message is encrypted with a public key derived from an attribute which is a prominent characteristic of the authorized receiving client. In our Utilities scenario, a company serving an apartment complex in the Silicon Valley will have an attribute ‘ELECTRIC-<APTCOMPLEXNAME>-SV-CA’. The encrypted message is sent through a transmission protocol to the MWS. A Message Authentication Code (MAC) is sent along with the encrypted message, which is used by the MWS to authenticate smart devices and verify message integrity. To verify message integrity the MWS and SD share keys at registration/licensing of each SD. The initial key exchange is out of scope and not further discussed.
The MWS is the central repository where all messages are stored. The encrypted message is then stored in a data store along with the attribute string used to encrypt the message, once the MAC has been authenticated and verified. MWS maintains access policies, which governs access to messages. It maintains a mapping between identities of RCs and its attributes. If a RC wants to retrieve a message encrypted using a particular attribute, his identity must map to that attribute. The attribute is not revealed to the RC, so that even after revocation of a particular RC, modifications to smart devices are not required.
The RC has to authenticate itself with MWS for retrieving a message. Once authenticated, it can retrieve the encrypted messages. Along with the encrypted messages the MWS will generate and transmit a ticket to the receiving client (RC). This ticket is encrypted with a key shared between MWS and PKG. RC uses this ticket to authenticate itself with PKG. To provide a further layer of security, the attributes are contained inside this ticket so that RC does not know attributes assigned to him. The PKG fetches the attributes within the ticket, generates the private keys corresponding to these attributes and transmits them over a secure channel.
35
Fig. 3 High-Level Architecture
B. High-Level Architecture Figure 3 depicts the high-level architecture of our solution.
The functions of the architectural components are explained below.
Smart Device (SD): This component uses the public parameters from the PKG and an attribute describing an eligible receiver to generate a public key. The attribute that will be used will include a nonce, e.g. ELECTRIC-APT.COMPLEX.NAME-SV-CA-123141311231123464. The nonce (here: 123141311231123464) will aid in revocation at later stages. The SD will also transmit a MAC generated using a symmetric key that it shared during registration with MWS.
Smart Device Authenticator (SDA): This component authenticates the SD by examining the Message Authentication Code. The SDA utilizes a key management service to obtain the corresponding key related to identity of a SD. Once a SD is authenticated, the encrypted message is stored in the message database. If a message is not authenticated properly, the message is discarded and optionally an alert is sent to the administrator.
Message Database (MD): The message database stores all the messages that are authenticated along with the attributes and optionally the PKG parameters. The MD is managed by the message management system.
Message Management System (MMS): This component is the core of the MWS-RC as it has access to the Policy and Message Databases. It is responsible for maintaining and retrieving messages from the message database depending on identity-attribute mapping maintained in the policy database. The MMS is also responsible for maintaining the identity-attribute mappings in the policy database.
Policy Database (PD): It stores policies and identity-attribute mappings.
Token Generator (TG): This component generates a ticket, which a RC uses to authenticate with PKG. This ticket is encrypted using a secret key shared between RC and the PKG.
User Database: It is used by the Gatekeeper to authenticate RCs. It stores RC identities and their hashed passwords. It may contain additional information, depending on requirements.
Gatekeeper: The gatekeeper is responsible for handling communication between the RC and the core Message Warehousing System (MWS). The main role of the Gatekeeper is to authenticate the user and establish a secure channel of communication between RC and MWS. To help this Gatekeeper utilizes the User Database. Once a user is authenticated, the Gatekeeper contacts the Message Management System and notifies a RC’s request.
Private Key Generator: This component maintains a master secret key. It shares a secret key with the Token Generator. It authenticates the RC using a ticket issued by the Token Generator. Once authenticated, it generates the parameter required by the RC to build a private key which he can use to decrypt the message.
C. Protocol Overview The aim of this protocol is to achieve end-to-end
confidentiality between DCs and eligible RCs. It makes sure that nobody else other than the intended recipients can decrypt the message, especially MWS. But MWS still has enough information to grant intended recipients access to the encrypted message. We have used DES encryption method throughout this protocol. The public-private keys are based on Identity Based Encryption. It handles RC revocation and makes sure that a private key can only be used once. The protocol is based on following assumptions:
i. SD and RC are registered with the MWS, have associated unique identities as well as attributes describing them.
ii. SD and MWS share a secret key, which is used by SD to generate a Message Authentication Code and by MWS to confirm message authenticity and integrity.
iii. SD knows the attributes of intended recipients for a message it generates and has the ability to encrypt the message using these attributes.
iv. RC and PKG share a secret key. This key is used by MWS to generate a ticket, which is used by PKG to authenticate RC.
v. PKG stores the master secret key, which is required for generating the private key corresponding to a public key.
The protocol has three main phases: • SD - MWS phase • MWS - RC phase • RC- PKG phase
36
Fig. 4 Protocol Interactions
D. Detailed Protocol In Section C, we outlined the secure messaging protocol. In
this section we discuss the details of protocol phases. 1) Notation
• SD: Smart Device • MWS: Message Warehousing System • RC: Receiving Client • PKG: Private Key Generator • P, sP: IBE Public Parameters • HashPassword: Hash of RC’s password • PubKRC: Public key of RC • SecKRC-PKG = Session Key between RC and PKG • SecKMWS-PKG = Secret Key between MWS and PKG • s: Master secret key known by PKG only • T: Timestamp • IDSD: Identity of SD • MAC: HK (SecKSD-MWS, rP || C || Nonce || IDSD || T) • r: Random value • A: RC’s attribute • I: SHA1(A || Nonce) • K: e(sP, rI) • C: E(K,M) • M: Message • ID: Identity of RC • Ticket: E (SecKMWS-PKG, (AID || A || SecKRC-PKG)) • Token: E(PubKRC , [SecKRC-PKG || Ticket]) • Authenticator: E (SecKRC_PKG, ID || T) • sI: Private key
2) Protocol Interactions Figure 4 shows a basic UML Diagram portraying the
communication that occurs within the model. We assume that the initial interaction between the PKG and SD occurred during the registration of the device. In this section we discuss the protocol interactions during the main operational phases.
SD – MWS Phase: We assume that SD shares a secret key with MWS. This
key is used to compute the MAC. The MAC serves the purpose of integrity and authentication.
• For every message, SD generates a random value r.
• SD knows the attribute A of the message that it generates. It generates a Nonce and computes a hash I of the string A||Nonce. The purpose of using a nonce is to facilitate revocation of RC. It makes sure that a fresh public-private key pair is generated for every message.
• SD generates a public key, K = e^(sP, rI) • Smart Device uses DES to encrypt the message M
with key K, which results in ciphertext C. • SD computes a Message Authentication Code (MAC)
of rP || C || (A || Nonce) || IDSD || T. • SD sends rP || C || (A || Nonce) || IDSD || T || MAC to
MWS. • SD Authenticator component of MWS knows the
symmetric key shared with SD. On receiving this, SD Authenticator computes a MAC of rP || C || (A || Nonce) || IDSD || T. If it matches the MAC appended at the end, it authenticates the SD and also ensures message integrity.
• Once authenticated, rP || C || (A || Nonce) is stored in the Message Database.
MWS – RC Phase: • RC authenticates with MWS to obtain messages
meant for it. It computes a hash of its password and generates a nonce N. It then encrypts IDRC || T || N using DES symmetric encryption algorithm with hashed password as the key. The timestamp T prevents replay attacks.
• RC sends IDRC || PubKRC || E(HashPassword , IDRC || T || N) to MWS. IDRC is the identity of RC, which is known to MWS.
• The Gatekeeper component of MWS receives this information from RC. It retrieves the hashed password from the User Database and decrypts the cipher text received. If the IDRC in the decrypted message matches the IDRC sent out in the open text, RC is authenticated. The Gatekeeper then forwards the request to the Message Management System (MMS) component of the MWS.
• The MMS accesses the Policy Database, which maintains a mapping (see Table 1) between RC's identity (IDRC) and the attributes {A1, A2...An} to which RC has access. It also contains an 'Attribute ID - Attribute' mapping. The reason for doing so is relevant for the next step. Once MMS figures out the attributes, it fetches all those records from the Message Database in which the attribute field matches the corresponding attributes fetched from Policy Database.
• The Token Generator component of MWS generates a token which is a DES cipher text of a ticket and a session key SecKRC-PKG between RC and PKG, encrypted with the public key PubKRC of RC. We assume that MWS shares a secret key SecKMWS-PKG with PKG. The Ticket is a DES cipher text of the session key SecKRC-PKG encrypted with the secret key SecKMWS-PKG It also contains an 'Attribute ID -
37
Attribute' pairing. The purpose of this pairing is that we do not want RC to know his attribute A. Thus, attribute A is encrypted inside the ticket and AID is sent to the RC in plain text.
• The Token Generator passes this token to the Gatekeeper which then forwards it to RC.
• The MMS passes rP|| C || (AID || Nonce) || N to the Gatekeeper which then forwards it to RC.
TABLE 1
Identity – Attribute Mapping Identity Attribute Attribute ID IDRC1 A1 1 IDRC1 A2 2 IDRC2 A1 3 IDRC3 A3 4 IDRC4 A4 5
RC – PKG Phase:
• RC receives the token from PKG and decrypts it using its private key, to obtain the session key SecKRC-PKG and the ticket.
• RC prepares Authenticator. Authenticator is the DES cipher text of IDRC || T. T is timestamp, which is used to maintain freshness and prevent replay attacks.
• RC sends IDRC || Ticket || Authenticator to PKG. • PKG decrypts the ticket using the secret key
SecKMWS-PKG that it shares with MWS, to obtain the session key SecKRC-PKG It also obtains the Attribute ID-Attribute mapping from the ticket. It then decrypts the authenticator to obtain IDRC and authenticates RC. It sends a confirmation to RC.
• RC now starts sending AID||Nonce to PKG. PKG replaces AID with A to obtain A||Nonce. It then generates a hash I of A||Nonce and sends back sI to RC.
• Using bi-linear pairing (e^(rP,sI) -> e^(sP,rI)), RC is able to generate the private key and decrypt the cipher C to obtain the original message M.
VI. IMPLEMENTATION We implemented a prototype as a proof of concept, which
uses the basic architecture that was mentioned above. The prototype was designed in Perl due to the availability of a wrapper function available for the PBC (Pairing Based Cryptosystem) library created by Ben Lynn [10]. The library uses the Pairing Based Encryption scheme that was created by Boneh & Franklin in 2001, which uses pairings of elliptic curves for finite fields (Weil Pairing). Another reason for using Perl was the variety of Crypt libraries that exist for symmetric and asymmetric keys. Additionally, the Catalyst web framework was used to develop our prototype web application due to its ease of use.
A. Protocol Interactions
The system does not explicitly encompass certain components described in the architecture, but does solve the problem mentioned. Instead of databases, flat files are used and time synchronization is not taken into consideration. Thus, no timestamps are included in the implementation of the system. Asymmetric public and private keys are also hardcoded into the system. The unique identifier mentioned in the protocol is also not implemented, and is left open so it can be handled in the future when the requirement arises. Libraries
Several libraries were used to implement the prototype. The core of the system was a free C library called “PBC (Pairing Based Cryptography) library” which was developed by Ben Lynn. A Perl wrapper library, Crypt::PB was used to provide compatibility with our present environment. The rest of the system uses the following libraries:
• Perl Catalyst 5.5 Web Framework • Perl DES Cryptography libraries • Perl Digest SHA1/MD5
B. Implemented Components This section discusses the different components that were
used in the system and their internal workings. Smart Device (SD): The Smart device currently takes the
message and an attribute input that should be used to encrypt a message. It then extracts the public key from the attribute based on the parameters that should be received from the PKG or stored locally on the system. Presently, this module generates the parameters similar to the PKG, which can be modified to initialize these values from the PKG. The SD then proceeds to generate a nonce, which is used to extract the public key from the parameters. Once this is done, the message is encrypted and sent to the MWS-SD server, in a serialized format. A Controller was created for this module in the Catalyst framework, which would let the inputs from the system be taken from a HTML form.
Message Warehousing Service – SD (MWS-SD): This module is a simple server that listens for messages on a particular port. Once a message is obtained it is saved to a text file. Depending on the version of the prototype that is being used, a key management system has also been integrated into this component that checks the corresponding smart device, and authenticates it with a Message Authentication Code.
Message Warehousing Service – Client (MWS-Client): This component is another server that listens for connections from the client. An access list exists on the system that authenticates a user, and assigns an attribute to the user. Depending on a client’s request, it transmits the messages to the client with a ticket, which is used by the PKG. The ticket is encrypted by a shared key between the MWS and the PKG that is currently hardcoded into the system. The ticket may be placed inside a token if required.
PKG: This component waits for a request for private keys from the Receiving Client. Once a connection is established, the token is checked to make sure that it was received from the MWS server. Once this authentication step is completed, private keys are generated and transmitted to the client. The
38
PKG is also responsible for generating the system parameters that should be used by the complete system. It stores the master secret key that is used for this approach, which is currently hardcoded into the system.
Fig. 5 Smart device user interface
C. Operation For the system to work, four servers are required to be
started up. For convenience, all ports and IP addresses are hardcoded into the system with an option of passing port numbers and IP addresses to it from a command console. The only constraint that exists is the fact that the MWS servers must run on the same machine due to the location of the flat files being utilized. A future consideration would be to move to database system that will be easier to access. A shared directory for the systems would suffice for the moment. Once all servers are running, a simple browser can access a webpage that provides login for the client and access to the Smart Device is provided. Options for attributes are currently saved in a template on the system and can be changed as required. A smart device would generate messages depending on events and schedules, but for demonstration purposes this input is provided by a user on behalf of a smart device via the web application. Fig. 5 shows the graphical interface of the smart device. A timestamp is automatically generated and appended to the message on transmission. A client interface also exists, which allows clients to login and view all messages on a server.
VII. RELATED WORK To the best of our knowledge, no other IBE based security
solutions for message warehousing as a service exist. However, some related work on the application of IBE is available. [6] is the closest to our work and proposes a key-policy attributed based encryption solution using IBE. According to this approach, ciphertexts are labeled with sets of attributes and private keys are associated with access structures that control which ciphertexts a user is able to decrypt. Our work adopts the solution presented in [6] and applies a variation of it to Message Warehousing as a Service. The work in [1] employs IBE to develop a public key based cryptographic scheme that allows keyword searching on encrypted data by adopting the IBE scheme. The authors in [3] employ IBE to develop a role-based secure messaging for an
health care application scenario. The work in [4] uses IBE to develop a secure communication inside a distributed system.[5] presents an identity-based broadcast encryption scheme.
VIII. CONCLUSION AND FUTURE WORK We have presented the design and implementation of our
solution which provides end-to-end message confidentiality in a scenario where message senders and message receivers communicate through a message warehousing service which is deployed as a SaaS. Our solution uses a combination of Identity Based Encryption (IBE) [2] and symmetric cryptography. We utilized IBE to encrypt messages using attributes describing eligible recipients. We have successfully used these attributes to implement access control, as demonstrated in the prototype. Our concept work and implementation need to be extended to provide a more complete solution.
The system does not take into consideration the initial setup between SD, MWS and the PKG. There is a possibility in the future that a choice between PKGs and smart devices may preference one from another. In such a case, a model of trust between the three parties may have to pre-exist. In such a case, an SD may have to notify the MWS of a preferred PKG, and also notify it of related system parameters that will be required by the RC. It will also be necessary for the SD to receive system parameters more securely in case a compromised PKG tries to take advantage. These considerations are related to the IBE model, and as the model evolves, the system may have to adapt.
The attributes that are currently used can be improved by considering an access policy, similar to XACML standards. In such a case, enhanced policies can be generated which may be able to give the Smart Device some additional power in determining the set of eligible receiving clients. Currently the policies are enforced by the PKG which may be required to take a larger role in the policy process.
Another future feature would be to divide a message into segments, where each segment has a different attribute assigned. In such a case a message may provide three parts to a message, such as the total consumption in a day, error notifications and events that may have occurred. Each part may be important to different service providers, and a case may arise where sharing of this information would break confidentiality.
The authentication of smart devices is performed by using Message Authentication Codes, which are generated using shared keys between the MWS and each SD during initialization. There may be a possibility of the SD to use IBE and the ID of the MWS to sign a message.
The basic architecture the MWS should be enhanced so that it can easily encompass Web Security standards such as SAML and XACML. A more distributed infrastructure can also be proposed, so the MWS-SD and MWS-Client can be located in different areas, and when required pull messages. In such a case, distribution points can be considered to improve the scalability of the system. This is beyond the scope of the
39
system, as it dwells into the architecture of the MWS system but should be carefully considered for later stages.
Currently, the capabilities to provide access lies exclusively with the MWS. Thus, the PKG has no decision-making powers, which may make the system vulnerable if policy conflicts occur at the MWS. To avoid this certain policies may have to be placed at the PKG that would prevent such problems. A form of threshold cryptography may also be considered, to create a distributed PKG, instead of a key escrow.
The current prototype uses flat files instead of database management systems such as MYSQL. It would definitely be advantageous for a system as it would open the doors for many added features, such as enhanced policies, detailed SD/Client tables and message tables. This would allow clients to select the corresponding message they wish to view from corresponding attributes. Each policy that a client opts for may be a separate account, helping to keep the multi-tenant approach of SaaS unharmed. The attribute identifier referred to in the protocol will help to avoid third parties learning of the attributes that are used during encryption, which would prevent future attacks. The smart device currently generates the parameters as the PKG does, which is not helpful in our case. It would be easier if the SD obtains the parameters and uses it later to gain access to the pairing required. Client authentication is also an important aspect that should be considered at later dates.
REFERENCES [1] Brent R. Waters, Dirk Balfanz, Glenn Durfee, and D. K.
Smetters. Building an Encrypted And Searchable Audit Log, 11th Annual Network and Distributed Security Symposium (NDSS’04), 2004 February, San Diego, CA, USA.
[2] D. Boneh and M. Franklin. Identity-based encryption from the Weil pairing. SIAM Journal of Computing, Vol. 32, No. 3, pp. 586-615, 2003.
[3] Marco Casassa Mont, Pete Bramhall, Keith Harrison: A Flexible Role-based Secure Messaging Service: Exploiting IBE Technology for Privacy in Health Care. DEXA Workshops 2003: 432-437
[4] Tyron Stading: Secure Communication in a Distributed System Using Identity Based Encryption, Proceedings of the 3rd International Symposium on Cluster Computing and the Grid, May 2003, Tokyo, Japan.
[5] Xinjun Du, Ying Wang, Jiangua Ge, and Yumin Wang: An ID-Based Broadcast Ecnryption Scheme for Key Distribution, IEEE Transactions on Broadcasting, Vol. 51, No. 2, June 2005.
[6] Vipul Goyal, Omkant Pandey, Amit Sahai, Brent Waters. Attribute Based Encryption for Fine-Grained Access Control of Encrypted Data., 13th ACM Computer and Communications Security (CCS), Oct-Nov 2006, Alexandria, VA, USA.
[7] Yuecel Karabulut and Joachim Biskup, A Hybrid PKI Model with an Application for Secure Mediation, 16th Annual IFIP WG 11.3 Working Conference on Data and Application Security, July 2002, Cambridge, United Kingdom.
[8] Yuecel Karabulut and Ike Nassi: Secure Enterprise Service Consumption for SaaS Technology Platforms, 1st IEEE Workshop on Information and Software as Services, March 2009, Shanghai, China.
40
