2008 International Symposium on Ubiquitous Multimedia Computing
Secure Mobile Content Delivery Architecture in Hybrid Network Environment Chih-Lin Hu, Chien-An Cho and Po-Jung Wang Department of Communication Engineering National Central University Taoyuan, Taiwan, R.O.C.
[email protected]; {955003020, 945003013}@cc.ncu.edu.tw Interface
Abstract
Secure access control
This paper proposes a secure mobile content delivery architecture in an integrated, hybrid network environment. Its design comprises device discovery, asynchronous content delivery, secure access control and virtual file system with dynamic reference mapping mechanisms, which are able to alleviate several inherent limitations in wireless and mobile networks. It thus enables mobile handheld devices to escape from mobility confinement and to transfer media contents in an efficient, energy-saving and secure manner. Our prototype implementation shows that the developed mechanism is feasible and ease of use: it effects the secure ubiquitous content delivery services in hybrid network environments.
HTTP
UPnP middleware
TCP/IP protocol suite
Interface
FS OS H/W
Figure 1. Functional stack design.
Specifically, it is prerequisite to employ a device discovery technique to find neighbor networked devices within a network domain [1]. The Universal Plug and Play (UPnP) device architecture is used to this end [5]. Our companioned work has fulfilled an AV media content sharing framework in home networks [3]. The work in this paper relieves the location restriction in [3], apart from local area network to anywhere. In addition, the design of home server in this architecture is on behalf of mobile content provider in support of the asynchronous mobile content delivery. In terms of energy saving and mobility concerns, the asynchronous delivery model has thrice benefits. First, a home server in the wired network can provide higher data throughput and shorten the transmission duration. Second, the mobile content provider can avoid long transmission duration and so reduce energy expense. Finally, both the mobile content provider and the receiver can get rid of the movement confine from a single-hop transmission range. The stationary home server is reachable by the receiver and in turn processes the follow-up. Moreover, we develop a transaction-based secure access control scheme among the mobile content provider, receiver and home server by means of a simple double key identification scheme with a pair of provider key and transaction key. Furthermore, the home server employs a virtual file system with dynamic reference mapping to support secure file operations. For each transaction, the home server prepares a temporary location ref-
1 Introduction Toward an integrated, hybrid network environment, there exist multiple wireless networks around users’ surroundings. In practice, an wireless/mobile handheld device (MHD) often has at least dual or triple network connectivity modules. A typical example is the sort of mobile phones that have 3G, Wi-Fi, and Bluetooth functions. An MHD can attach to multiple network contexts simultaneously; that is, it can concurrently run different network services on different networks. These network services might be further integrated to come up another collaborative network services, yet to be the future dimension for developing new, potential ubiquitous information services. Our work proposes a secure mobile content delivery architecture in a hybrid network environment. Consider several characteristics and weaknesses in wireless and mobile networks, such as low transmission throughput, limited energy capacity, limited transmission range, and lack of mobility support. The architecture design comprises four basic components: device discovery, asynchronous mobile content delivery, transaction-based secure access control and management, and virtual file system, as shown in Figure 1.
978-0-7695-3427-5/08 $25.00 © 2008 IEEE DOI 10.1109/UMC.2008.22
Content delivery service
Interface
Virtual FS
69
erence where the receiver can make a connection to fetch a media object. The home server can thus protect the file system from possible threats. In the rest of this article, Section 2 describes the architecture design, Section 3 manifests the prototype development, and conclusions are given in Section 4.
broswe
5 4 3 2 1
transaction
4 3 2
5 4 3 2 1
5
Home server
P＇ and T＇s Signatures P-key
Provider
move 5 4 3 2 1
1 Receiver
Device and Service Discovery
Our design adopts the UPnP protocol stack, including addressing, discovery, description and control layers without eventing and presentation, to develop a discovery protocol. Specifically, after UPnP hosts get IP addresses in the same network domain by using DHCP or Auto-IP, they proceed to discover each other. The UPnP discovery is based on the SSDP [2] with no need of centralized configuration and management. A UPnP device periodically advertises its the appearance on a well-known multicast address/port. The location header in an advertisement message specifies the description URL of UPnP root device. A UPnP device uses a description to present its services in XML format. So, interested UPnP devices can fetch and parse the description, and know what services the device offers. The UPnP control is customized according to the SOAP [6] that integrates both HTTP and XML to provide a Web-based messaging and controlling mechanism. The UPnP Forum has standardized several device control profiles to make consensus on the activities of different device categories. However, mobile content delivery service is not included yet. Rather, this architecture adopts a "customized control profile" for requirements on content browse and meta-data retrieval. Noteworthily, the SOAP messaging rests on reliable network connections with higher computation overhead. In fact, it is advisable for Web services, but not for general ordinary remote network services, especially in unreliable wireless and mobile network environments as considered. Our design thus merely employs the UPnP control layer in both mobile content provider and receiver that interconnect in a small network domain, but not in the far home server. Our work further devises an RPC-like content delivery service on the home server across the wide area networks.
2.2
Secure transaction process VFS with dynamic URL reference (Session deadline, Intermission interval)
transaction T-key
2 Architecture Design 2.1
Repository
Figure 2. Secure mobile content delivery. developers’ and users’ demands. We develop a virtual file system instead for better media content management. To keep from possible security threats, the location reference of media item can be assigned with a "garbled" string, mapped to the real one in the native file system. The below is a basic meta-data structure in our design.
(1) Direct downloading The mobile content receiver browses the content directory service of the mobile content provider, and then obtains a list of "shared" media objects. It accordingly acts an HTTP GET to the reference from which an indicated media object is downloaded. (2) Redirect downloading The provider queries its home server about a meta-data list of location references to media objects stored there. The provider forwards the receiver a "working list" of indicated media objects it redirects the receiver to download from the home server. As in Figure 2, only object 1 is delivered by the provider, though objects 2 and 3 are locally available. The receiver downloads objects 2, 3, 4 and 5 from the home server, by another network. (3) Continual downloading This method supports mobile content delivery after mobility or connection reestablishment by either the mobile content provider or receiver. While the receiver keeps the working list assigned by the preceding redirect downloading process, it can still download indicated media contents till those location references are invalidated by the home server. Note that redirect and continual downloading procedures are subject to a secure transaction scheme, as will be jointly detailed later.
Asynchronous Content Delivery
Figure 2 depicts the secure mobile content delivery in this mechanism. There are three basic delivery services with complementary usages. In addition, a content directory service is designed to render the content presentation. Content directory service It summarizes all shared media items into meta-data. Consider the native file system, on an MHD platform, is usually too simple and insecure to satisfy
2.3
Secure Access Control
The following describes transaction processing, double key identification, and virtual file system with dynamic reference mapping mechanisms.
70
2.3.1 Transaction Process
DigestURL_Raw_1 := "/RPCAction?File=#{FileName}& User=#{RecvName}&Key=#{P-Key}" DigestURL_Raw_2 := "/RPCAction?File=#{FileName}& User=#{RecvName}&Key1=#{P-Key}&Key2=#{T-Key}" By comparing URL to DigestURL_Raw, the URL refers to the host that runs RPCAction routine upon the target files. The HostURLBase designates the host’s location reference,
This architecture imposes a secure transaction process with authorization and authentication. When the provider commences a redirect downloading process, a secure transaction process is initialized. The home server manages the transaction process and statuses in a centric fashion. A transaction process is assigned with a transaction or session deadline before that the receiver can perform plural continual downloadings to complete the working list. Thus, a secure transaction is effective from the moment at which the provider informs both its home server and the receiver till the end of the last media item is downloaded completely, except that any of the following situations occurs: any participant aborts the transaction process; the associated session deadline expires; the intermission between two successive continual downloadings exceeds the serving interval.
of home server or mobile content provider, depending on which downloading method is used. Here are some statements below. A difference between DigestURL_Raw_0 and _1 is the value of User field that means where an RPC action originates from. The value of Key=#{P-Key} in DigestURL_Raw_1 means that this RPC action is committed by the provider. The pair of P-Key and T-Key in DigestURL_Raw_2 means both the provider and home server commit themselves to this RPC action for the receiver. For instance, continual downloading is such a case.
2.3.2 Secure Access with Double Key Identification
2.3.3 Virtual File System and Reference Mapping
A simple double key identification scheme with a pair of symmetric keys is designed for the home server to ascertain whether a receiver is trusty or not. Provider key (P-Key) is pre-determined and kept secure by the mobile content provider. It maintains the trustiness between it and its home server. Transaction key (T-Key) is dynamically generated by the home server whenever a new transaction is initialized. It is transient and effective to the end of the session deadline. This key is used in the transaction between the mobile content receiver and home server. This architecture adopts an RPC-like model to conduct the transaction process among home server, mobile content provider and receiver. Two field entities, identifier and signature, are specified below to facilitate the resolution of authentication and authority on RPC sender and receiver. The identifier is not exposed under the URL expression. It is added in the DigestURL_Raw expression that is further hashed by MD5 function to generate a signature. Both P-Key and T-Key values are unique in the meanwhile of a transaction process; so is the resultant signature. The RPC receiver can thus believe the sender to be trustworthy.
This framework uses a directory-based mapping scheme [4]. Every file or directory inside has a meta-data record in a structure analogous to that in Section 2.2 with extension for file management. The home server marshals meta-data records for a specific directory tree. Especially, the URL element is determinant. There are two variants: Actual URL: It refers to the logic path in the native system, e.g., URL := /URLBase/AV_Dir/Picture/My.jpeg. Virtual URL: It refers to a temporary, symbolic location reference, e.g., URL := /URLBase/PicXXX.jpeg, dynamically generated by reference mapping service. The virtual file system resolves the mapping as it gets a virtual URL. As direct downloading, the mobile content provider serves the receiver a working list of actual URLs. As redirect or continual downloading, the provider appeals to the home server for a new working list where meta-data records include virtual URLs. The provider sends the new one to the receiver which can so download indicated contents. The virtual file system does not has a pre-determined reference pool. Every reference is generated dynamically and formed in a garbled string. The location reference is kept in a working list pertaining to the transaction. All location references associated with a transaction process will be in vain, while the transaction is finished or terminated. It is viewed as transaction validity. Thus, this scheme can not only keep the system robust against possible security threats, but significantly have no burden on the receiver that still performs media downloading via HTTP GET.
Identifier := #{P-Key} | ( #{P-Key} & #{T-Key} ) Signature := MD5( #{DigestURL_Raw} ) DigestURL_Raw element has three compositions, DigestURL_Raw_(0|1|2), to support different sorts of RPC
invocations. The first two are sent from the provider to the home server; the last is sent from the receiver, through the provider, to the home server. The provider subscribes MD5( DigestURL_Raw_(0|1|2) ) at the end of the URL expression.
3 Prototype Demonstration
URL := "HostURLBase/RPCAction?File=#{FileName}& User=#{UserName}&Signature=#{Signature}" DigestURL_Raw_0 := "/RPCAction? User=#{ProviderName}&Key=#{P-Key}"
The prototype framework comprises the UPnP stack and RPC-like Web service modules. The UPnP stack is imple-
71
Receiver
Provider
sponse of a directory list of meta-data records, arranged by the content directory service with virtual URLs. Then, the provider can do Redirect action to notify the receiver of preparing a redirect downloading transaction, and forward it a newly working list of indicated metadata records. The receiver is to do ApplyForDownload or ApplyForBatchDownload action in advance of retrieving files from the home server. It informs the provider a list of media objects it wants to access from the home server. When the provider gets this list, it applies its signature MD5(DigestURL_Raw_1) onto every URL and in turn submits an ApplyForPermission request to the home server. The home server generates a transaction key and initializes a secure transaction process to deal with this request. It also assigns a temporary URL to every URL by dynamic mapping. The transaction key and a list of temporary URLs are replied to the provider. The provider further applies a joint signature MD5(DigestURL_Raw_2) onto every temporary URL . Then, it sends the receiver a final working list as a reply to ApplyForDownload action. The receiver now starts to perform DownloadFile actions to asynchronously retrieve media objects.
Home Server
Direct Downloading Browse
self-checking
Re: Working list [A-URL] Download File Redirect Downloading transaction
Redirect
Browse
preparation
Re: Directory list
Re: Working list [A-URL/V-URL] Apply for Downloading Files
Re: Working list [V-URL]
Apply for Permission Re: Temporary URLs & Transaction keys
Download File and File Transfer
Figure 3. Interactive flowcharts. mented in Java programming language. A developer has no porting and dependency issues on target platforms with Java Virtual Machine. All RPC-like interaction processes between the mobile content provider and its home server are developed by using Web technologies: all interactive messages are represented in XML conventions. On the other hand, the mobile content receiver requires a tiny customization software installed to be able to interact with the home server over the HTTP communication protocols. Therefore, any networked devices having TCP/IP connectivity, Web server or client, and XML functions can perform the mobile content delivery service in this framework. According to the RPC procedures for establishment of a secure mobile content delivery service on the developed platform, Figure 3 depicts two interactive procedures in direct and redirect downloading cases, to better grasp demonstration presentation and the usages of RPC actions. In case of direct downloading, the receiver invokes a Browse action on the provider and receives the response of a working list of meta-data records, arranged by the content directory service with actual URLs. The receiver applies HTTP GET iteratively to download media objects. Browse:
4 Conclusion The proposed software architecture is able to make networked devices interconnected and to enable secure mobile content delivery anywhere in an integrated network playground. We have described the design and development of UPnP discovery, efficient content delivery service, secure transaction-based access control and management, and virtual file system with dynamic reference mapping. An RPCbased experimental prototype is successfully demonstrated.
References [1] W. K. Edwards. Discovery systems in ubiquitous computing. IEEE Pervasive Computing, pages 70–77, April-June 2006. [2] Internet-Draft. Simple service discovery protocol/1.0 operating without an arbiter. IETF Internet-Draft draft-cai-ssdp-v103.txt, October 1999. [3] W.-S. Liao, Y.-J. Huang, and C.-L. Hu. Mobile media content sharing in upnp-based home network environment. In Proceedings of the 2007 IEEE/IPSJ SAINT Workshop of Ubiquitous Networking and Enablers to Context-Aware Services, Jan. 2007. [4] UPnP Forum. UPnP av contentdirectory:2 service template version 1.01. May , 2006. [5] UPnP Forum. UPnP device architecture 1.0 version 1.0.1. December 2003. [6] W3C Consortium. Simple object access protocol. W3C Consortium: www.w3.org/TR.2000/NOTE-SOPA-20000508, May 2000.
Download File: HTTP GET /AV_Dir/Music/Track1.mp3 HTTP/1.1 HOST: 140.115.152.2:50988
In case of redirect downloading, the provider invokes a Browse action on the home server and receives the re-
72
