提供者2的PE D通信并且假装属于提供者2，可将含有同一随机值RV(LS C已从PE A接收)的验证询问发送到PE D0 PE D可返回相信LS C属于提供者2的验证响应RES。LS C可将响应RES传送到PE A，PE A将其返回到LS B。LS B现在可相信PE A属于提供者2且可提供受信任服务，例如将AP位置和其它PPAD提供到PE A0
[0074]根据某些实例实施方案，验证密钥和其它项目以促进PE提供者和/或LS提供者的验证可使用若干技术中的任一者在PE/UE和LS处配置。举例来说，验证密钥和其它参数(例如，提供者ID和密钥ID)可在LS提供者与PE提供者之间同意，且在其相应LS和PE中配置。LS配置可通过安全方式(例如，HTTPS)快速发生(例如，在因特网上)且经配置数据可在LS中安全地保持，前提是所述LS仅运行由LS提供者提供或批准的软件和程序。
[0075]PE配置可经延迟，可能不安全，且经配置数据可经受PE提供者未批准的用户或应用程序的未授权的接入。举例来说，如果PE可仅在当PE接入属于PE提供者的某个LS以获得位置服务(例如，例如请求GNSS辅助数据)时的某个稍后时间配置，那么可发生配置的延迟。如果属于对手提供者B的PE能够假装作为用于提供者A的PE同时接入用于提供者A的LS，那么用于特定PE提供者A的配置可为不安全的。如果存储在对UE上的应用程序或其它软件可存取的存储器中或如果用户可侵入PE或UE存储器，那么PE中的经配置数据也可为不安全的。在一些实施例中，可克服或减轻PE配置的不安全性。
[0076]在特定实施方案中，在PE中配置密钥的延迟可意味着在LS提供者与PE提供者之间同意的共同密钥是在属于PE提供者的PE中配置之前在属于LS提供者的LS中配置，其可导致验证失败(例如，当已接收到共同密钥的LS尝试验证用于尚未接收到所述共同密钥的PE的PE提供者时)。此处，PE可不能够从用于伙伴提供者的LS获得受信任服务(例如，接收PPAD)直到经配置有同意的秘密密钥。
[0077]根据实施例，PE的不安全配置可使用一或多个秘密加密密钥来克服。秘密密钥Kl可在芯片制造期间由特定PE提供者I (或代表其)嵌入在PE中。可在具有商业关系的PE提供者I与LS提供者2之间同意第二秘密密钥K2。可获得第三秘密密钥K3为K3 = F(Kl)(K2)，其中F(Kl)是应用于密钥K2的基于密钥Kl的某个加密函数。属于PE提供者I的PE可下载且存储K3 (例如，从属于PE提供者I的服务器)。接收K3的PE可随后获得密钥K2为F 1O(I) (K3)，其中F 1O(I)是应用于密钥K3的F(Kl)(即基于密钥Kl的解密)的倒数。此处，来自假装作为来自提供者I的PE的不同提供者2的PE可获得K3，但由于不知道密钥Kl而不可恢复K2。
[0078]根据实施例，在PE恢复的密钥K2 (例如，如上文所描述)可不存储，而是按需要由PE获得。举例来说，PE可存储在先前实例中从PE提供者I接收的密钥K3且仅在需要时获得密钥K2 (使用密钥Kl)以支持PE的验证。如果例如安全地存储至少密钥K1，那么即使可获得所存储的密钥K3 (例如，通过侵入PE或UE存储器)，应用程序或用户也可能不能够确定K2。并且，甚至当可存取Kl时，例如由于作为在PE上运行的固件或软件的部分，函数F1(Kl)也可保持秘密且难以接入。
[0079]图3是根据一实施方案的基于实体之间的不同关系验证数据的应用300的说明。如所说明，LS 302可用于LS提供者A，LS 304可用于LS提供者C，PE 306可用于PE提供者B，且PE 308可用于PE提供者D。在一实例中，图3中所示的每一 LS提供者可具有与图3中所不的的每一 PE提供者的商业关系。因此，在此实例中，LS提供者A和LS提供者C各自具有与PE提供者8和D中的每一者的商业关系。与这些商业关系相关联的数据可在每一LS和PE中配置。此外，对于每一商业关系，可存在在LS中配置的特定数据以及用于在PE中配置的同一商业关系的对应数据。图3中使用双箭头展示对应对的经配置数据，其中同一双箭头的每一末端处的数据是用于同一商业关系。举例来说，在用于提供者A的LS 302和用于提供者B的PE 306的情况下，数据在LS 302中和PE 306中经配置以支持LS提供者A与PE提供者B之间的商业关系。用于此商业关系的LS 302中的数据和PE 306中的数据在图3中由双箭头310展示。图3说明LS或PE可各自含有用于LS或PE的提供者已建立的与另一提供者的每一商业关系的单独的经配置数据。此外，经配置数据可用以获得且验证提供者ID。举例来说，在LS 302与PE 306的提供者之间的关系的情况下，经配置数据可由LS 302使用以获得且验证用于PE 306的提供者B的ID和/或可由PE 306使用以获得且验证用于LS 302的提供者A的ID。在LS和PE中经配置以支持LS的提供者与PE的提供者之间的商业关系的数据可包含每一提供者的名称和/或ID以及验证每一提供者所需要的数据，例如共享秘密验证密钥。因此，如图3的实例中所示，在各自具有由双箭头310指示的经配置数据以支持提供者A与提供者B之间的商业关系的LS 302和PE 306的情况下，在LS 302中和PE 306中配置的数据可包含提供者A和B的名称以及允许LS 302接收且验证来自PE 306的提供者B的名称和/或允许PE 306接收且验证来自LS 302的提供者A的名称所需要的验证数据。经配置以用于图3中所示的其它对提供者的数据可为类似的。
[0080]如图3中例示的经配置数据可针对具有商业关系的每对提供者为不同的或可为部分共同的。当共同秘密密钥用于两个提供者之间的验证时，所述密钥可对于所述两个提供者为唯一的且不用于任何其它对提供者。当公共-私用密钥对用以验证一个提供者A时，提供者A可在其自身的PE或LS中配置私用密钥且将公共密钥提供到与其存在商业关系的所有其它提供者。在此情况下，同一公共-私用密钥对可以用于提供者A的所有伙伴而无任何安全性风险，因为私用密钥仅在属于提供者A的PE或LS中配置。
[0081]图4是根据实例实施方案的用于具有商业关系的一对提供者的验证数据的分布400的说明。此处，说明LS提供者A 402连同可由LS提供者A 402拥有和/或操作的对应LS (LS I到LS N)。还说明PE提供者B 404连同可由PE提供者B 404拥有和/或操作的对应PE服务器406以及可能已由PE提供者B 404以某种方式(例如，经由软件、固件和/或硬件)制造或提供的PEOJE I到M中的每一者中的PE)。如在实例步骤I所说明，LS提供者A 402和PE提供者B 404可建立商业关系以例如经由将PPAD从用于LS提供者A 402的LS I到N中的任一者供应到用于UE I到M中的PE提供者B 404的PE中的任一者和/或经由将PI3D从用于UE I到M中的PE提供者B 404的PE中的任一者供应到用于LS提供者A 402的LS I到N中的任一者，对彼此的LS和PE提供位置服务或位置支持。作为步骤I的部分，LS提供者A 402和PE提供者B 404可协定(例如，可交换)共同验证数据，其可包含两个提供者的名称或身份以及将用于验证所述名称或身份的验证密钥。LS提供者A402可在实例步骤2与其支持的LS I到N通信以配置在步骤I处同意和/或交换的共同验证数据(例如，使用网络服务或其它基于因特网的协议)。类似地，PE提供者B 404在实例步骤3可与PE服务器406通信(例如，使用网络服务或其它基于因特网的协议)以配置在步骤I处同意和/或交换的共同验证数据，其可为在步骤2处由LS提供者A 402提供到LSI到N的相同验证数据或可不同(例如，可含有公共验证密钥而不是私用验证密钥)。在实例步骤4，PE服务器406可配置UE I到M中的PE提供者B 404的PE。在步骤4中的配置可对于不同PE在不同时间发生，例如响应于从每一 PE到由PE提供者B 404操作的PE服务器406的对辅助数据(AD)的请求。在步骤4处的配置可利用去往和来自每一 PE的无线通信和/或采用网络服务或其它基于因特网的协议。
[0082]根据某些实施例，使用若干实例技术中的任一者，PE提供者ID可由LS验证或LS提供者ID可由PE验证以分别使LS或PE能够检验分别与PE或LS的提供者存在商业关系，且因此例如PPAD或PH)等机密数据可分别发送到PE或LS。举例来说，可同意且配置公共和私用密钥(例如，如图4中例示)以执行RSA验证。此处，待验证的实体(例如，LS)可经配置有私用密钥，且将执行另一实体的验证的实体(例如，PE)可经配置有匹配的公共密钥。这可必然需要导出公共-私用密钥对，其并非不重要的且因此在私用密钥泄密且需要替换的情况下可成问题。并且，此技术可限于单个方向中的应用(例如，用于PE对LS提供者的验证但不用于LS对PE提供者的验证)，从而可能必然需要建立用于另一方向中的验证的另一公共密钥-私用密钥对。
[0083]在某些实例实施方案中，LS提供者和PE提供者可建立共同秘密密钥。共同秘密密钥可随后用以验证属于两个提供者的实体(即LS和PE)或仅属于一个提供者的实体。验证可基于使用秘密密钥产生消息验证码(MAC)，其不是处理器密集的。秘密密钥可采用任何值且当密钥已泄密时可易于更换。
[0084]用于LS对PE提供者的验证的共享密钥的使用可提供某些特定优点。举例来说，如果丢失机密性且执行验证需要的处理可为低的，那么可易于更换共享密钥。根据实施例，本文所描述的验证PE以接收PPAD的技术可至少部分使用如来自开放移动联盟(OMA)的公开可用文档中阐述的SUPL(安全用户平面位置)位置解决方案实施。举例来说，LS可完全或部分经配置为SUPL定位平台(SLP)且含有PE的UE可完全或部分经配置为具有SUPL功能的终端(SET)。在一个实施方案中，PE提供者验证可由SLP采用仅一次，在此之后SLP可存储SET身份以及用于SET的PE提供者是否经验证作为受信任PE提供者的指示。对于稍后的SUPL会话，SLP可验证SET身份为对于任何SUPL会话可为正常的，在此之后SLP可从其自身的存储装置检索用于SET的PE提供者是否经验证且受信任的指示。然而，如果在SUPL会话开始时SLP不存储SET身份或不验证SET身份，那么SLP可需要针对与SET的每个SUPL会话获得且验证用于SET的PE提供者，其中PPAD可能需要提供到SET上的PE。
[0085]根据实施例，使用公共-私用密钥方法对SLP的提供者的验证可增强安全性，因为PE可仅需要验证SLP的提供者一次。此处，PE可在一个SUPL会话期间接收且验证用于SLP的提供者名称或身份，且与SLP服务器身份结合而存储验证的结果。对于PE与SLP之间的稍后SUPL会话，PE可不需要执行SLP提供者的再验证，因为可验证SLP服务器身份(与SLP提供者身份相反)作为任何SUPL会话的部分。PE可随后从所存储的信息检验用于经验证SLP服务器的SLP提供者已经由于其与经验证SLP服务器身份的关联而先前验证。PE可仅接收(例如，配置有)公共-私用密钥对的公共密钥(而不是私用密钥)，因此如果另一 PE或应用程序或用户能够获得公共密钥则不会有损安全性，因为这将不会使SLP提供者被欺骗(将需要私用密钥的所有权)。同一公共-私用密钥对可由LS提供者使用以用于所述LS提供者具有合伙关系的所有PE提供者，这可使得用于LS提供者的LS能够向任何PE验证自身而无需(初始地)知道PE提供者。
[0086]使用共享密钥而不是公共-私用密钥对来执行验证可在同一验证方法用以通过PE验证LS提供者且通过LS验证PE提供者的情况下精简实施方案，但所述方法可能较不安全，因为共享密钥必须在LS和PE两者中配置，而通过公共-私用密钥对，私用密钥仅需要在LS或PS中配置而不是在两者中配置。然而，公共-私用密钥和/或共享密钥方法可在不背离所主张的标的物的情况下使用。
[0087]根据特定实施方案，可使用用于共享密钥验证的若干技术中的任一者。举例来说，IETF RFC 2104和NIST FIPS-198-1中界定的散列消息验证码(HMAC)可以用于验证。HMAC通过如下计算数据集合上的散列而操作:
[0088]HMAC = Hash (F(秘密密钥)| |数据)(其中I I指示串联)；
[0089]其中Hash 可为 MD5 (RFC 1321)、SHA_1 或 SHA-256 (NIST SP-800-107)或某个其它散列函数；
[0090]F是秘密密钥的简单变换(例如，(key XOR opad) | | (key XOR ipad));以及
[0091]数据可包括:PE提供者ID，LS提供者ID，随机串和/或日期/时戳。
[0092]HMAC的值可连同来自实体(LS或PE)的消息(例如，含有提供者ID、随机串和日期/时戳)一起计算和提供，所述实体的提供者ID将向将验证提供者ID的实体(PE或LS)验证且随后由此实体检验以用于另一提供者。HMAC值当使用MD5获得时可包括128位，当使用SHA-1获得时可包括160位且当使用SHA-256获得时可包括256位。
[0093]替代地，基于高级加密标准(AES)的消息验证码(CMAC)可以用于验证。AES CMAC通过在数据集合(例如，上文对于HMAC所述的数据)上使用具有AES加密的密码块链接模式(NIST SP 800-38B)提供基于密码的消息验证码而操作。AES CMAC例如在NIST SP800-38B和IETF RFC 4493中界定。所得CMAC值可为128位。在另一个替代性实施例中，AES CMAC可用作默认方法，但其它方法可由一些成对的提供者以专有方式使用。
[0094]PE提供者的验证可例如使用若干技术中的任一者使用SUPL来实施。作为LS (充当SLP)与PE (充当部分SET)之间的SUPL会话的部分，可验证PE提供者和/或LS提供者。SUPL会话可出于多种原因由PE或由LS建立以便由LS或由PE获得PE的(或用于PE的移动装置的)位置，在PE处从LS请求且接收辅助数据，或将众包位置信息(例如，含有AP和基站的测量数据和/或位置)从PE传送到LS。作为SUPL会话的部分，PE可能需要确定LS是否属于受信任LS提供者(例如，PE的提供者与其具有商业关系的LS提供者)和/或LS可能需要确定PE是否属于受信任PE提供者(例如，LS的提供者与其具有商业关系的PE提供者)。可能需要此情形以便LS决定是否将PPAD发送到PE和/或以便PE决定是否将PPD发送到LS。PE和/或LS提供者的确定可伴随着如本文先前所描述的PE和/或LS提供者名称或身份的验证。
[0095]使用SUPL对PE提供者和/或LS提供者的验证可在SUPL会话开始时例如使用方法A或方法B而发生。通过方法A，可将支持验证的新参数添加到现有SUPL消息，例如SUPLINIT、SUPL RESPONSE (SUPL 响应)、SUPL POS INIT 以及 SUPL TRIGGERED RESPONSE (SUPL触发响应)。通过方法B，可在SLP与SET之间(或SLP与PE之间)交换含有验证相关参数的新SUPL消息(例如，SUPL INFO消息)以支持PE提供者和/或LS提供者的验证。在方法B的实施例中，用于例如可扩展验证协议(IETF RFC 3748和RFC 5247中界定的EAP)的验证协议的嵌入消息可由新SUPL消息载运以验证PE提供者和/或SLP提供者。方法B也可在SUPL POS交互期间由SUPL定位中心(SPC)使用以验证PE的提供者。
[0096]LS对PE提供者和/或PE对LS提供者的验证可实际上例如使用方法C、方法D或方法E，在PE与LS之间的SUPL POS交互期间(在SUPL会话中)在SUPL会话内较晚发生。通过方法C，可将新验证参数添加到SUPL POS消息以执行PE提供者和/或LS提供者的验证。通过方法D，用于嵌入协议(例如，IETF RFC 3748和RFC 5247中界定的可扩展验证协议(EAP))的消息可在SUPL POS消息中载运以用于验证而不是定位，且可实现PE提供者和/或LS提供者的验证。通过方法E，可使用此协议内部的新参数或新消息将验证能力添加到现有定位协议(例如，OMA LPPe)，其中用于所述定位协议的消息(载运验证数据)在SUPL POS消息内部在SLP与SET之间(或SLP与PE之间)传送。用于验证协议的嵌入消息可实现PE提供者和/或LS提供者的验证。
[0097]为了当LS提供者和/或PE提供者的验证作为SUPL会话的部分而发生时在LS与PE之间传送验证相关数据，可使用例如IETF EAP等现有验证协议传送验证数据。这可配合上述方法B和D。替代地，可使用SUPL中或例如LPPe等与SUPL —起使用的定位协议中的定制新参数来传送验证数据，其可配合上述方法A、C和E。
[0098]当SUPL用以支持且提供位置服务时，SLP可分裂成SUPL位置中心(SLC)和SUPL定位中心(SPC)，所述SLC可支持SUPL会话建立和一些服务功能，所述SPC可支持SET的定位和辅助数据到SET的供应。在特定实施方案中，SLC可获得且验证PE的提供者，且确定PE是否受信任(例如，属于SLC提供者与其具有商业关系的PE提供者)。PE可信度可随后由SLC传达到SPC(例如，与和SLC相同的LS提供者相关联的SPC)。当SLC比SPC更易于能够验证用于PE的PE提供者时以及当SPC与SLC分开且不初始地知道PE提供者是否可信但是需要知道此情况以便决定是否将PPAD发送到PE时，这可为高效的。如果SPC改为自身执行PE提供者验证，那么SPC可直接知道PE是否受信任。
[0099]根据一些实施例，上述方法A可用以通过SLP验证用于SET的PE提供者，且可包括使用新信息元素(IE)的基于SUPL的解决方案，所述新IE包含PE验证请求IE (例如，SLP到SET)然后是PE验证响应IE (例如，SET到SLP)。PE验证请求IE可由SLP发送到SET (或由SLP发送到PE)以请求用于SET的PE提供者ID和数据以使SLP能够验证用于SET的PE提供者。PE验证响应IE可由SET (或由PE)响应于接收到PE验证请求IE而发送到SLP，且可传送用于SET的PE提供者ID和数据以使SLP能够验证用于SET的PE提供者ID。PE验证请求 IE 可使用任选的新在 SUPL INIT、SUPL RESPONSE 和 SUPL TRIGGERED RESPONSE消息中实施，且可将以下数据中的任一者或全部传达到SET: (i)SLP提供者ID(例如，八位位组串)；(ii)SLP全量域名(FQDN) ; (iii) PE验证请求IE的其余部分上的SLP计算数字签名，其可使PE能够验证(i)中的SLP提供者ID ； (iv)公共密钥ID (例如，八位位组串)，其可识别(例如，经由名称)但不显式地提供检验包含在(iii)中的任何数字签名所需要的密钥；(V)随机值(RVl)(例如，八位位组串)，其可当SLP请求PE提供者ID的验证时包含；(vi)当前日期和时间，其可当PE数字签名包含在(iii)中时包含且可确保数字签名是唯一的且无法再使用；以及(Vii)LS提供者专有数据(例如，八位位组串)，其可例如传达关于PE的PPAD保持的时间限制。PE验证请求IE可包含在如稍后针对消息流程500中的步骤C描述的SUPL INIT消息中或如稍后针对消息流程600中的步骤D描述的SUPL RESPONSE消息中。
[0100]根据实施例，PE验证响应IE可包括SUPL POS INIT消息中的任选的新IE。如果PE提供者和SLP提供者(例如，由SLP使用PE验证请求IE提供到PE且可能由PE验证)具有商业关系且可能当PE已从SLP接收到载运RVl参数的PE验证请求IE时，此IE可由PE包含。PE验证响应IE可将以下中的任一者或全部从PE传达到SLP:⑴PE提供者ID (例如，八位位组串)；(ii)密钥ID (例如，八位位组串)，其可识别(例如，使用名称)但不显式地提供用于(iv)中的PE数字签名的PE验证密钥随机值(RV2)(例如，八位位组串)；(iv)由PE基于PE验证响应IE的其余部分或基于RVl和/或RV2的值计算的PE数字签名；(V)当前日期和时间，其可帮助确保(iv)中的任何数字签名是唯一的且无法再使用；以及(V) PE提供者专有数据(例如，八位位组串)，其可例如用以传达SET WiFi MAC地址和/或其它SET地址。PE验证响应IE可包含在如稍后针对消息流程500中的步骤E和消息流程600中的步骤E描述的SUPL POS INIT消息中。
[0101]图5是说明根据一实施方案的用于验证用于具有SUPL功能的终端(SET)的PE提供者以用于网络起始的SUPL会话的实例消息流程500的图。消息流程500可采用方法A用于本文较早描述的使用较早描述的PE验证请求IE和PE验证响应IE的PE提供者验证。消息流程500可为与SUPL ULP标准中界定的消息流程相同的消息流程，用以使例如图5中的SUPL代理502的外部客户端能够获得移动台104(例如图5中的目标SET 506)的当前位置且任选地获得其速度。SUPL代理502可在步骤A使用OMA MLP标准位置立即请求(SLIR)消息将针对目标SET 506的位置(和任选地速度)的请求发送到所发现SLP或归属SLP (在本文中被称作D/H-SLP) 504。D/H-SLP 504可随后在步骤B到G发起与SET 506的SUPL会话且获得SET 506的位置和任选地SET 506的速度，所述步骤B到G可为通常用以使用SUPL会话获得SET位置和任选地速度的步骤。为了检验SET 506中的PE是否