通信学论文-对于一种保密增强的移动业务架构的研究.doc

通信学论文-对于一种保密增强的移动业务架构的研究摘要位置、现场和消息业务为出现的信息和通信业务提供了基本要素。然而，用户关心他们的实际位置、现场和联系地址信息是否暴露了，尤其对于那些不信任的第三方应用。我们提出了一种保密架构，可以实现与特定用户关联的业务和该用户自身之间的无连接性。这种架构基于一种保密业务和一种称为PRIVES的hash技术。关键词Parlay-X接口，hash，保密增强技术，第三方业务1引言下一代业务架构目标在于建立一类新的第三方业务、应用提供商和独立软件供应商，这些供应商可以通过OSA/Parlay这种开放的标准接口开发访问通信网络的新型业务。这些业务的成功要素在于他们的个性化，也就是能够考虑用户的选择、现场和位置等等。因此对于一个好的业务，用户不得不向基本上不信任的第三方暴露自己的个人信息。为了解决这些显然矛盾的需求，系统不得不集成保密和身份管理机制。我们集中讨论了用于Parlay组织指定的电信运营商的Web业务上下文中的位置保护、现场和地址保密等内容。文中介绍的保密架构专门应用于下一代移动网络和业务。内容主要包括两个部分：保密业务的规范，这些内容集成在电信业务架构中。一个轻量假名创建方案，在这个方案中用户可以控制链接等级，而且针对每一个应用可以进行优化。PET（PrivacyEnhancedTechnology，保密增强技术）主要解决四个基本的ISO需求：匿名、使用假名、无连接性和无观测性，这些需求也是许多处理地址保密、位置保密、业务接口保密或认证保密研究项目的课题。1.1Parlay-X概述Parlay-XWeb业务试图激励IT团体中的开发者去开发下一代网络应用，这些开发者没有必要是电话和电信方面的专家。Web业务的选择是通过商业利润来驱动，而不是通过先进的技术来驱动的。它的目的在于定义一套强有力但简单、高抽象和虚构的电信功能，这些功能可以使电信领域中的开发者能够快速理解和生成创新型的应用。到目前为止指定的接口有以下这些功能：第三方呼叫、短消息和多媒体消息、付费和计费管理、用户状态、终端位置和现场。在应用和业务之间定义的接口使用WSDL语言（Web业务定义语言）描述并且使用同步呼叫以及异步回叫。在许多带有EndUserIdentifier的身份X方法中，与保密相关的方法是用户的寻址。为了实现我们的保密方案，假名（hash值）也必须能够象合法的EndUserIdentifier一样得到承认。可以被保密增强的业务有位置、现场、消息、付费和呼叫控制。1.1.1位置业务应用要获得用户位置的时候就会用到这种业务。除了简单位置轮检之外，新版本的位置API包括更强大的功能，例如：当用户进入和离开一个区域后会产生通告消息，这个区域通过坐标系给出的半径和中心来确定，当位置变化后产生通告消息。在网络层中，定位是使用一些监听终端的邻近小区的信令长度来完成的。位置信息（例如用地址坐标表示的）可以让本地用户查询例如最近的药房在那里的业务应用。3GPP和IETF对于位置保密也有相应的规定。IETFGeropiv组织定义了位置保密的需求。3GPP也努力通过增强对用于位置信息的用户和应用的接口控制来提高保密性。1.1.2现场业务当一个被选属性改变后，这个业务允许应用监测一个用户的不同现场特性和接受通告。应用将对这些变化起作用并配置业务，改变那个用户的出向和入向流量或者执行其他的动作。来自于处理现场信息的动作和信息既可交付给现场自己，也可交付给用户授权接受现场信息的观测者。1.1.3消息业务消息业务允许应用发送SMS或MMS消息给用户以及从用户处接收SMS或MMS业务。很显然，目的地址（MSISDN号，SIP地址，email地址等等）可以与用户的名字和物理地址相关联。因此，如果应用可以把手机号同本地历史记录相关联，那么仅仅保护用户的位置信息就没有什么意义了。保密增强解决方案会阻止应用使用发消息给现场的真正目的地址。1.1.4付费业务Parlay-X提供了一个简单的基于使用网络运营商计费设施对Web业务收费的应用和内容。为了访问在运营商的用户帐目，这种接口方法需要用到用户地址。为了保护用户的安全，我们不得不对前面提到的业务隐藏用户地址。图1系统架构2系统架构图1显示了拥有四种认证Parlay-X业务的建议架构，这些业务把它们的SOAP接口暴露给应用。从理论上说，移动用户终端由一个客户端程序组成，这个程序用来访问应用，接收消息或提供自己的位置和现场信息。为了我们的讨论目的，我们用用户配置文件表示如当前位置、现场状态和联系地址信息这些要保护的数据。为了访问应用用户终端查询保密代理，保密代理用来把地址这种不同的身份特性映射成假名。架构里最新颖的部分就是保密业务，保密业务是唯一能够翻译业务中发现的假名的实体，把假名转化成OSA和Parlay-X下的网络层需要的真实地址。代理中假名的创建和保密业务点是动态的，在一种极端的情形下，客户端可以给每一次请求创建一个新的假名，然而对多数应用来说，在会话期间假名可以保持不变。2.1保密API描述保密API描述了一个保密用户代理和保密业务之间的交互。我们选择的是HTTP上的SOAP技术。启动时的第一次交互，登录密码用来对用户代理进行认证。在注册时刻定义的密码是一个双方共享的密码。保密代理预订它自己的保密信息还是另一个用户的信息，依赖于图2中描述的应用。这个预订不是被明确的接受就是被保密业务中的策略规则自动处理。在预订之后，保密代理接受一个种子代码字符r,就可以创建假名了。业务参数允许限定为预订一部分保密信息（位置、联系地址、现场等）。用户客户端和应用之间的交互没有强制的标准，协议可以是HTTP，XML-RPC或SOAP。客户端使用一些“startApplication”的消息调用应用，不一定需要认证它本身。在这个启动信息里应用接收到的假名hlA被用作EndUserIdentifier，穿过Parlay-X接口（看图3）。在业务侧，保密业务把假名翻译回真正的用户名或地址，这样Parlay-X电信业务就可以正常的工作。基本上，每一次用户客户端处理应用的时候都会创建一个新的假名。然而频繁的改变假名会增用户的匿名，因此应用可通过应用工作流和消息历史记录的当前状态来保持一个会话。为了在业务和用户两侧控制新假名的创建，保密代理调用方法nextKey().当切换到一个新的假名时我们遇到的一个问题就是同步：应用不得不关闭业务和用户之间的事务，这样用户才可以用保密业务建立一个新假名（使用nextKey）。在消息业务的帮助下，我们很容易实现最普通的同步情形。l应用完成一个事务就使用消息业务发送一个最终消息给用户（例如通知用户付费的问题，看图3）。l用户决定停止或中止应用，这首先要使所有的电信业务结束，然后发送一个最后消息给用户。这个消息用来触发nextKey()消息。表1是保密业务方法的汇总。2.2假名生成算法在这一部分，我们简单介绍一下文献5在基于位置服务上下文中建议的保密增强方案PRIVES。PRIVES基于使用HMAC(HashingforMessageAuthenticationCode,用于消息识别码的hash算法）方案的hash值计算，使用HMAC方案让PRIVES非常适用于智能电话和PDA这样的小型设备。HMAC允许从前面的hash值来创建一个新的hash值，另外使用这个密码作为在保密业务和观测者之间的共享密码。在图4中，用户创建hash值来允许应用查询用户B的配置文件。用户用A的保密代理和应用HMAC操作符H()从前面的hash值h(n1)和A的密码得到的保密业务，以一种同步的方式创建hash值。用户需要的唯一的信息就是r(AB),它是由保密业务最初创建的，是一个密码的函数，一个随机数。当保密业务从应用接收到一个用hash值h(1)认证的本地用户请求时，它检查hash值的有效性并从h(1)决定谁是观测者和目标用户。一旦请求被处理，那么请求用户和保密业务就已经准备好了接受随后请求的下一个hash值h(2)。3应用实例在旅行导航指南的情景下，一个汽车司机选择这个业务来获得指向他的目的地的地图、旅行环境和导航帮助。用户首先在运营商负责管理的保密业务下登录，这样客户端就可创建假名。在图5中我们展示了一幅简单消息流图表，在这张图表里用户发送一个请求，消息业务就提供地图和旅行环境。一个更有用的功能就是每一次旅行环境改变都会通告用户（使用消息业务）。在图表里，我们也提出用户在任何时刻都可以停止应用，接着依次完成计费和发送一个最终确认消息。4结束语我们主要讨论了一个基于现代业务架构的web业务的移动用户的保密问题。我们假定可以相信网络运营商管理这种新提出的保密业务，而且用户移动终端和保密业务之间的通信信道是安全的。此外我们假定PKI方法在移动方面没有很好的表现，这让我们寻找一种用于某些保密问题的轻量解决方案。这种架构主要考虑的是已经存在的应用和电信业务之间的标准接口（例如Parlay-X）。本文主要贡献在于介绍了保密业务，一种接口标准的参考方案。参考文献1PETininfrastructures,RAPIDISTProject,URL:,accessed2.Sept.2004”2PrivacyandIdentityManagementforEurope(PRIME),WP14.2ArchitectureVersion0,URL:/public/primeproducts/deliverablesOct.20043T.Alamaki,M.Bjorksten,P.Dornbach,C.Gripenberg,N.Gyoerbio,G.Marton,Z.Nemeth,T.Skyttae:PrivacyEnhancingServiceArchitectures,2003,pp.99-1094HaroldTeunissenJeroenVanBemmel,MarioHoffmann:Privacyand4Gservices:Who