太原理工大學信息工程學院 郭曉莉
近年來,移動計算的發展催生了大量情境感知的服務,服務方會通過感知用戶情境信息,主動為用戶提供切合情境的服務,如智能手機上的應用Googl e Lat it ude,Four squar e等LBS應用使服務方感知移動用戶的位置信息來提供與用戶所在環境相合的服務;移動社交網絡應用服務方通過感知移動用戶的喜好信仰等信息讓用戶體驗進行移動式社交。
然而,服務方所感知信息為用戶敏感信息,服務獲得這些信息同時,并未征得用戶的信任及授權。在未經授權的情況下,服務方通過定位位置傳輸設備等方式訪問到原始的位置等敏感數據,擅自獲取用戶敏感信息,并計算推理獲取的與位置信息相關的個人隱私信息,如利用位置信息向用戶散播惡意廣告,獲取用戶政治觀點,生活方式等隱私信息,導致用戶的隱私被泄露。所以,移動用戶在獲取情境感知服務前如何保護位置屬性的隱私成為了我們迫切需要解決的問題。怎樣對敏感數據進行訪問控制,即應如何定義敏感信息,如何制定訪問控制策略,如何對隱私受保護的服務過程進行建模成為近年來研究熱點。
一些作者針對傳統的Or BAC模型,添加了準許情境,指明了最相關的需求:準許,精確,臨時義務和目的。動態情境可被主要隱私原則充分表現,如圖1所示。
這種方式使用準許情境、基于精確性的對象層次、用戶聲明情境的目的、訪問敏感信息后的臨時義務這四點保護用戶隱私:
準許情境:是隱私喜好的相關參數。它允許當數據擁有者的個人數據被訪問時通知他。
基于精確性的對象層次:在精確性方面,定義位置數據視圖,集合所有訂閱者位置信息。私有實體不同等級的精確度。從集合初始收集的實體的根視圖到集合由此衍生的具有不同精確度的實體。

圖1
用戶聲明情境的目的:訂閱者,作為訂閱者角色,在位置信息被服務提供者訪問前定義它的目的,訂閱者是聲明情境的角色。利用情境定義角色,服務提供者是此情境下的接受者。
訪問敏感信息后的臨時義務:服務提供者應通知運營者在30秒內進一步使用隱私數據。
通過上述方式,可以有效地保護移動用戶自身的隱私,但同時也帶來系統復雜等缺點。
另外一些作者則改進P3P(Pl at f or m f or Pr i vacy Pr ef er ences)策略[2],在手機的安全框架內使用。服務提供商可在Web服務內發布P3P策略,要求移動客戶端提供用戶喜好。對數據的訪問控制包括用戶喜好,身份映射。由安全框架提供一種機制逐步地在參與者之間建立信任。通過取得策略信息與服務提供商交互。
隱私系統交互步驟如圖2所示。

圖2
首先移動設備向Web服務請求實時密鑰,然后Web服務發送挑戰請求、策略并詢問用戶喜好。移動客戶端發送挑戰應答和策略文件中獲取的身份的哈希值。Web服務用改進的哈希值作為密鑰加密實時密鑰,發送實時密鑰應答。加密的實時密鑰在移動客戶端用改進的哈希值作為解密密鑰進行解密。實時密鑰用作解密加密數據。
目前來針對移動安全隱私的研究方向,主要研究Web服務端和手機客戶端的通信方式或者通信模塊。試圖通過改善通信模塊等方式改善隱私問題。本文基于之前的通信問題,提出設立第三方權威模塊,從而解決移動隱私安全泄露問題。
本文提出的第三方安全隱私模塊由政府或權威機構設立。每當服務端和手機端產生隱私信息資源索求時,由手機端將安全隱私信息發往第三方。由第三方確認。
該模塊設計思路如下:
(1)對所有服務端進行分類:
將服務端的隱私保護能力分為強和弱。并定期對相應的企業服務端進行檢測,重新排定強弱判定。
(2)根據企業隱私保護能力不同設定不同處理方案:
對于隱私保護能力強的服務端。第三方模塊直接將用戶隱私信息傳輸過去,由服務端自行判斷。對于隱私能力保護弱的服務端。則由第三方模塊代替其對用戶隱私信息進行處理判定。企業可以提前在第三方模塊內上傳自己對于用戶隱私信息的處理模塊。約定使用的程序語言和輸入輸出即可。因此用戶的隱私信息不會傳輸到企業服務端。在被相應的處理模塊處理后信息直接反饋至客戶端,如圖3所示。
隨著手機移動端的發展。對于移動安全隱私的保護必將愈來愈重要。本文提出由政府或權威機構制作第三方模塊解決安全問題。雖然可以保護用戶的隱私安全,但會導致整體通信結構復雜化等缺陷。但隨著隱私安全保護的發展,必將出現更加安全,便捷的隱私安全保護方案。
[1]Ajam N,Cuppens-Boulahia N,Cuppens F.Contextual Privacy Management in Extended Role Based Access Control Model[J].Lecture Notes in Computer Science,2009.
[2]Arunkumar S,Raghavendra A,Weerasinghe D,et al.Policy extension for data access control[J]. Secure Network Protocols IEEE Workshop on,2010:55-60.