Challenges and enablers

Many of the challenges of the personal cloud will be similar to that of the other deployment models.

One example is allocating the services providing access to appropriate resources (service discovery) without user intervention. Some challenges may be implicitly solved by the properties of the underlying technology, e.g. privacy of historical data. Adding and removing visiting user’s services and devices in a personal cloud will require additional middleware related to security; in particular for appropriate authentication, identity and trust management.

Figure 32 Cloud deployment model including personal cloud

7.2.1 Challenges in the personal cloud

Authentication – Different devices may be part of the personal cloud, and they may differ in their capabilities. For example, some devices may not contain functionality and data to provide for strong user authentication.

Establishment of trust – Devices may be dispersed and prior to any action, trust must be established between them. Usually, a pairing process is performed when a user needs personal devices to communicate with each other (e.g. by using Bluetooth); a process that verifies that the user in fact has control of all concerned devices. Consequently, a trust model and an identity management scheme for the user and all devices are required. Efficient authentication schemes for heterogeneous devices must also be developed; this is somewhat a challenge, because different device types have different inherent identifiers, if any at all.

Data safety – Your personal data is something you want keep for yourself, so there are obviously privacy concerns when making all your personal data accessible from everywhere. When sharing with others, e.g. a visiting device, only specific resources should be accessible, and it should be possible to revoke a granted access to this device. There should be proper access control and data transferred should be encrypted. As hard drives may break down, there is also a risk of losing data. There should be redundancy related to storage.

Service discovery – Each personal cloud will require its own directory of services and management functions towards this. In addition, it is necessary to consider where remote services will be made available, and through what type of directories this should be listed; they should obviously not be listed in a public directory. It may be necessary to have local and remote service directories for each personal cloud.

Profile management – The user must have full control of available services and their interaction patterns. Therefore there must exist proper management services to achieve this.

Connecting devices across network boundaries – One of the challenges of establishing connections between devices on different private or public networks is to “circumvent” Network Address Translation (NAT) routers and firewalls in safe and secure manners.

Support for legacy devices and services – Encapsulation of legacy devices and services, in a way that the new security mechanisms of the personal cloud is enforced, also for devices and services that is not natively supported.

Service metadata exchange – Services must be able to communicate with the other services about what type of services they provide.

Uninterrupted real-time services – Services dependent on real-time media streams, such as audio or video telephony, may be interrupted when moving from one network to another, or if moved from one device to another. There should be a way for services to handover between different networks and between different devices.

7.2.2 Enablers for personal cloud

In 5.5, the general enablers for cloud computing were discussed. In this section we consider the additional enablers that are required to support the personal cloud, and some alternative implementations of them that already exist today. We will also pinpoint areas that lack supporting technologies today. Figure 33 illustrates some of the enablers for the personal cloud. As shown, the

personal cloud will depend on specific enablers, as well as general enablers already existing in the public clouds.

Authentication – The devices must be able to authenticate each other in a secure way, so no one can add an unfamiliar device eavesdropping and drain data from the personal cloud. Some personal devices, e.g. mobile phones, have capabilities which could make them suitable as an authentication token. Mobile phones also benefit from being personal, are always there, have many channels and embedded cryptographic functionality. This is further elaborated in section 7.4.5.

Identity management – Different devices may take an IdP role in different clouds, e.g. according to available authentication mechanisms. For the personal cloud a personal identity provider is providing both trust establishment, e.g. using OAuth, and secure authentication. This is further elaborated in section 7.4.2 and 7.4.3. Combining the mobile phone for authentication and a personal IdP into a mobile phone IdP is elaborated in section 7.5.

Interconnecting networks – The personal domain spans different networks and consist of resources located in different networks. Those networks could be LANs behind NAT-routers/firewalls. The networks should be able to interconnect, so there is a need for a LAN gateway service doing NAT-traversal. See also section 6.1. As communication between the networks take place on unsecure internet connections, there should be added a layer of confidentiality, by encrypting the traffic, this cloud be accomplished by using VPN tunnels.

Encrypted data – Encrypting data using asymmetric keys issued by the personal IdP will make it much harder to get hand on personal data.

Adding strong authentication and encrypting personal data, both stored data and data in transit, address the challenge about data safety. This makes it both harder to gain illegal access to personal data and if a personal device is lost or communication is eavesdropped, the data is unreadable without the proper keys. For securely storage there should be automatic backup / replication among several storage devices, and maybe there also should be support for an external storage service in the public cloud.

Device management – The public cloud needs proper management of devices. Functionality for discovering, registering and unregistering devices must be solved. One way to register a device should be to go to a specific URL on the Internet provided by the remote management facility. The public cloud should support temporary registration, for instance a PC on an internet café could be added for doing a SIP telephony conversation, but should be un-registered shortly after that conversation.

Remote management facility – Due to firewalls, services on a LAN could be blocked for outside connections, so there is a need for a facilitator, enabling management of devices and services behind a firewall from the outside, and this service should always be available on the Internet. This service could be considered a proxy server in the middle, and the parallel in peer-to-peer networks would be a supernode. OperaUnite is an example of a similar remote service facilitator, where local resources are made available on the Internet accessible from everywhere, through a URL, e.g.

http://home.toralux.operaunite.com/. This service should also be situated in the public cloud.

Local directories – On every LAN there is need for a discovery and local directory of resources, such as devices and services, running on those devices. If a supported device is connected to the LAN, it should register to the local directory. If there is no local directory, i.e. this is the first device on this specific LAN, it should, if

the device is capable of doing it, establish a local directory itself. See also section 6.2.

Global directory – There should also be a global directory which is available from everywhere and thus should be placed in the public cloud. This global directory should have an overview of the complete personal cloud, including all networks and devices taking part of it. Most devices have one or several identities, e.g. Bluetooth address, MAC address of the networking interface, etc. and there must for every device be established a device name alias specific for the personal cloud. The global directory could alternatively be served by infrastructure in the personal domain, and only made accessible from the Internet using the remote management facility.

Standardized interfaces or platforms – A common ontology of service types is required. There must be established standardized service interfaces and data formats to allow services to interoperate.

Some of these standardized service interfaces will be interfaces supporting administration and management of the personal cloud, while other service interfaces will support specific services, e.g.

streaming of video. Virtualization may be used to abstract away from differences in the devices’

underlying hardware architecture, to ease re-location of services from one device to another. For virtualization, see section 5.5.1.1.

Service-wrapping to add legacy support – To support legacy devices and services which are not adapted to work in the personal cloud, there should be a way to wrap those legacy services into personal cloud native interfaces compatible for consumption in the personal cloud. This could either be services on devices under directly control or it could also be personal services in the public cloud.

Service-wrapping allows controlling legacy service security within the personal cloud, to only grant access to parts of a service, concealing credentials and gives the possibility to both grant and revoke access without doing changes to the legacy service being wrapped.