CN103370915B - 用于安全用户平面定位***中的认证的方法和装置 - Google Patents

用于安全用户平面定位***中的认证的方法和装置 Download PDF

Info

Publication number
CN103370915B
CN103370915B CN201180064445.0A CN201180064445A CN103370915B CN 103370915 B CN103370915 B CN 103370915B CN 201180064445 A CN201180064445 A CN 201180064445A CN 103370915 B CN103370915 B CN 103370915B
Authority
CN
China
Prior art keywords
supl
slp
mobile device
message
init
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201180064445.0A
Other languages
English (en)
Other versions
CN103370915A (zh
Inventor
P·M·霍克斯
A·K·瓦赫特
A·E·埃斯科特
S·W·埃奇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Priority to CN201610028131.XA priority Critical patent/CN105491070B/zh
Publication of CN103370915A publication Critical patent/CN103370915A/zh
Application granted granted Critical
Publication of CN103370915B publication Critical patent/CN103370915B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种特定的方法包括在移动设备处存储特定于该移动设备的至少一个安全证书。该方法还包括将该至少一个安全证书发送到安全用户平面定位（SUPL）定位平台（SLP），以基于设备标识符与所存储的设备标识符的比较将该移动设备认证为与SUPL用户相关联。所公开的技术可以使得SUPL服务器和支持SUPL的终端SET能够协商要使用多种认证方法中的哪种。

Description

用于安全用户平面定位***中的认证的方法和装置
技术领域
概括地说，本公开内容涉及安全用户平面定位(SUPL)***中的认证。
背景技术
技术的进步导致更小并且更强大的计算设备。例如，当前存在各种便携式个人计算设备，其中包括无线计算设备，诸如体积小、轻便并且易于用户携带的便携式无线电话、个人数字助理(PDA)、以及寻呼设备。更具体地说，诸如蜂窝电话和因特网协议(IP)电话之类的便携式无线电话能够在无线网络上传送语音和数据分组。此外，许多这种无线电话包括合并在其中的其它类型的设备。例如，无线电话还可以包括数字静态照相机、数字视频摄像机、数字录音机、以及音频文件播放器。
无线电话还可以配有位置确定硬件/软件以能够进行基于位置的服务。例如，无线电话可以包括全球定位***(GPS)收发机。无线电话还可以接收网络辅助定位信息(例如，基于在多个网络塔之间对无线电话的位置进行三角测量的定位信息)。
安全用户平面定位(SUPL)是可以用于能够在无线通信***中进行基于位置的服务的技术标准。SUPL架构可以包括两个组成部分：支持SUPL的终端(SET)和可以实现为网络可接入的服务器的SUPL定位平台(SLP)。在利用SUPL服务之前，可能要求SET和/或SLP彼此进行认证。然而，SUPL中的安全和认证可能取决于由SET所使用的接入网络。例如，第三代合作伙伴计划(3GPP)或3GPP2网络上的认证可以利用与微波接入全球互通(WiMAX)网络上的认证不同的安全机制。此外，SUPL 2.0中可用的安全机制可能不完全支持使用诸如电气和电子工程师协会(IEEE)802.11(Wi-Fi)网络之类的其它可用网络，这可能使得基于SUPL的功能对于在室内或者经历较差蜂窝网络状况的无线电话不可用。
发明内容
公开了SUPL***中的认证的***和方法。所公开的***和方法可以针对包括3GPP、3GPP2、WiMAX和Wi-Fi网络的各种接入网络，支持SET和SLP之间的相互认证。所公开的技术可以使SUPL服务器和SET能够协商使用多种认证方法中的哪种。本文所公开的认证方法包括但不限于独立于接入网络类型的基于证书的认证。在具体实现中，基于证书的认证可以在认证期间使用传输层安全（TLS）以使得在SET和SLP之间能够进行安全通信。所公开的技术还将安全应用于SUPL会话发起和重发起。在附加实施例中，可以经由多标识符/密码对而不是经由基于证书的认证来执行认证。
在特定实施例中，一种方法包括：在移动设备处存储特定于该移动设备的至少一个安全证书，其中，所述安全证书包括所述移动设备的设备标识符。该方法还包括：将所述至少一个安全证书发送到安全用户平面定位（SUPL）定位平台（SLP），以基于所述设备标识符与所存储的设备标识符的比较将所述移动设备认证为与SUPL用户相关联。
在另一个特定实施例中，一种非暂时性处理器可读介质，其包括指令，当所述指令由处理器执行时，使所述处理器在SUPL服务器处生成要发送到移动设备的消息。所述消息包括：包括所述SUPL服务器的标识符和所述SUPL服务器的公钥的服务器证书；以及对所述移动设备的设备证书的请求。当所述指令由处理器执行时，还使所述处理器从所述移动设备接收包括所述移动设备的设备证书的应答。当所述指令由处理器执行时，还使所述处理器基于所述设备证书，将所述移动设备认证为与SUPL用户相关联。
在另一个特定实施例中，一种装置包括处理器和耦合到所述处理器的存储器。所述存储器存储可由所述处理器执行以进行以下操作的指令：在SUPL服务器处，从移动设备接收由所述移动设备所支持的一个或多个TLS密码组的指示。所述指令还可由所述处理器执行以确定所述一个或多个TLS密码组是否包括由所述SUPL服务器支持的TLS预共享密钥（TLS-PSK）密码组。所述指令还可由所述处理器执行以响应于确定所述一个或多个TLS密码组包括由所述SUPL服务器所支持的所述TLS-PSK密 码组，执行基于通用引导架构（GBA）的认证过程，以对所述移动设备进行认证。所述指令还可由所述处理器执行以响应于确定所述一个或多个TLS密码组不包括由所述SUPL服务器所支持的TLS-PSK密码组，确定所述SUPL服务器是否支持基于证书的认证方法。所述指令还可由所述处理器执行以响应于确定所述SUPL服务器支持所述基于证书的认证方法，执行基于证书的认证过程，所述基于证书的认证过程包括将服务器证书发送到所述移动设备，以及从所述移动设备接收设备证书。所述指令还可由所述处理器执行以响应于确定所述SUPL服务器不支持所述基于证书的认证方法，当所述移动设备连接到3GPP网络或者3GPP2网络时，执行基于交替客户端认证（ACA）的认证方法。
在另一个特定实施例中，一种方法包括：在移动设备处从SUPL服务器接收会话发起消息（例如，包括SUPL INIT消息），以在所述SUPL服务器和所述移动设备之间发起SUPL会话。所述方法还包括：响应于所述移动设备在所述移动设备接收到所述会话发起消息之前从SUPL服务器接收到有效的会话发起消息密钥（例如，包括SUPL_INIT_ROOT_KEY），使用所述会话发起消息密钥对所述会话发起消息进行认证，以及响应于对所述会话发起消息的成功认证，发起与所述SUPL服务器的SUPL会话。
在另一个特定实施例中，一种装置包括处理器和耦合到所述处理器的存储器。所述存储器存储可由所述处理器执行以进行以下操作的指令：在移动设备处从SUPL服务器接收会话重发起消息（例如，包括SUPL REINIT消息），以在所述SUPL服务器和所述移动设备之间继续SUPL会话（例如，通用SUPL会话（GSS））。所述指令还可由所述处理器执行以响应于所述移动设备在所述移动设备接收到所述会话重发起消息之前从所述SUPL服务器接收到有效会话发起消息密钥，使用所述会话发起消息密钥对所述会话重发起消息进行认证，以及响应于对所述会话重发起消息的成功认证，继续与所述SUPL服务器的所述SUPL会话。
在另一个特定实施例中，一种方法包括从移动设备向SUPL服务器发送消息，其中，所述消息包括SUPL INIT根密钥状态参数（例如，指示SUPL_INIT_ROOT_KEY的状态）。例如，可以将所述SUPL INIT根密钥状态参数包括在所述消息的SET能力参数中。在另一个实施例中，一种方法 包括将SUPL END消息从SUPL服务器发送到移动设备，其中，所述SUPL END消息包括SUPL INIT密钥响应参数（例如，提供新的SUPL_INIT_ROOT_KEY）。在另一个特定实施例中，一种方法包括将包括保护等级参数的SUPL INIT消息从SUPL服务器发送到移动设备。在另一个实施例中，一种方法包括将包括保护等级参数的SPUL REINIT消息从SUPL服务器发送到移动设备。
在另一个特定实施例中，一种方法包括在网页服务器处从支持SUPL的移动设备接收消息，其中，所述消息包括所述移动设备的安全证书。所述方法还包括在所述网页服务器处从所述移动设备接收用户标识信息，并且将所述用户标识信息认证为标识SUPL服务的授权用户。所述方法还包括将所述移动设备的所述安全证书发送到SUPL服务器，以使得所述SUPL服务器能够将所述移动设备认证为与所述SUPL服务的所述授权用户相关联。
在另一个特定实施例中，一种方法包括在SUPL服务器处从移动设备接收所述第一标识符和所述第一密码。例如，可以在用户模式TLS认证过程期间接收第一标识符和第一密码。所述方法还包括将所述第一标识符和所述第一密码认证为与SUPL服务器的授权用户相关联。所述方法还包括将第二标识符和第二密码发送给所述移动设备以替代所述第一标识符和所述第一密码，其中，所述SUPL服务器配置为在从所述移动设备接收到所述第二标识符和所述第二密码之后与所述移动设备建立SUPL会话。
由所公开的实施例中的至少一个所提供的特定优点包括在SUPL***中独立于接入网络执行相互认证的能力。例如，所公开实施例中的一个或多个可以支持包括3GPP、3GPP2、WiMAX和Wi-Fi网络等的各种接入网络。作为另一个例子，所公开实施例中的一个或多个可以将安全应用于SUPL会话发起和重发起。
在回顾了包括下列章节的整个申请之后，本公开内容的其它方面、优点和特征将变得显而易见：附图简要说明、详细说明和权利要求。
附图说明
图1是示出可操作以在SUPL环境中执行认证的***的特定实施例的 图；
图2是示出在SUPL环境中协商认证方法的方法的特定实施例的流程图；
图3是示出在SUPL环境中使用证书执行认证的方法的特定实施例的流程图；
图4是示出在SUPL环境中使用证书执行认证的方法的另一个特定实施例的流程图；
图5是示出在SUPL服务器和移动设备之间的消息传送的特定实施例的图；
图6是示出在SUPL环境中的会话发起期间的认证的方法的特定实施例的流程图；
图7是示出在SUPL环境中的会话重发起期间的认证的方法的特定实施例的流程图；
图8是示出在SUPL环境中使用网页服务器和多个标识符/密码的认证的特定实施例的图；
图9是示出在SUPL环境中使用网页服务器的认证的方法的特定实施例的流程图；
图10是示出在SUPL环境中使用多个标识符/密码的认证的方法的特定实施例的流程图；以及
图11是实现SET的无线设备的特定实施例的框图。
具体实施方式
参考图1，其示出了可操作以在安全用户平面定位（SUPL）环境中执行认证的***的特定实施例，并且被概括地标记为100。***100包括经由一个或多个接入网络（例如，说明性接入网络130）通信地耦接到移动设备120的SUPL服务器110。在特定实施例中，SUPL服务器110可以是SUPL定位平台（SLP），并且移动设备120可以是支持SUPL的终端（SET）。接入网络130可以是3GPP网络、3GPP2网络、WiMAX网络、Wi-Fi网络（例如，根据IEEE802.11标准进行操作的网络）、或者某些其它无线接入网络。在特定实施例中，移动设备120可以是无线电话。
SUPL服务器110可以包括处理器111和耦接到处理器111的存储器112。在特定实施例中，存储器112可以存储可由处理器111执行的指令，其中，该指令代表各种逻辑模块、组件和应用。存储器112还可以存储SUPL服务器110的一个或多个安全证书。例如，存储器112可以存储用于SUPL服务器110的服务器证书113，其中，服务器证书113包括公钥114和服务器标识符（ID）115（例如，对应于SUPL服务器110的全球唯一标识符）。SUPL服务器110还可以具有对应于公钥114的私钥。存储器112还可以存储对应于认证逻辑116和传输层安全（TLS）加密/解密逻辑117的可执行指令。可以执行认证逻辑116，以对移动设备120进行认证。可以执行TLS加密/解密逻辑117，以对从SUPL服务器110发送到移动设备120的消息进行加密并且对从移动设备120发送到SUPL服务器110的消息进行解密。例如，可以使用服务器公钥114对从移动设备120传出的消息进行加密，并且可以使用对应于服务器公钥114的私钥对从移动设备120进入的消息进行解密。
移动设备120可以包括处理器121和耦接到处理器121的存储器122。在特定实施例中，存储器122存储可由处理器121执行的指令，其中，该指令可以代表各种逻辑模块、组件和应用。存储器122还可以存储移动设备120的一个或多个安全证书。例如，存储器122可以存储用于移动设备120的设备证书123，其中，设备证书123包括公钥124和设备标识符（ID）125。移动设备120还可以具有对应于公钥124的私钥。设备ID125可以是国际移动设备标识（IMEI）、移动台标识（MSID）、序列号、或者可以是全球唯一的其它标识符。在特定实施例中，设备证书123可以存储在移动设备120的通用集成电路卡（UICC）处而不是存储器122中，或者除了存储器122之外还存储在移动设备120的UICC处。存储器122可以存储对应于认证逻辑126和传输层安全（TLS）加密/解密逻辑127的可执行指令。可以执行认证逻辑126，以在移动设备120处对SUPL服务器110进行认证。可以执行TLS加密/解密逻辑127，以对从移动设备120发送到SUPL服务器110的消息进行加密，并且对从SUPL服务器110发送到移动设备120的消息进行解密。例如，可以使用设备公钥124对从移动设备120传出的消息进行加密，并且可以使用对应于设备公钥124的私钥对进入移动设备 120的消息进行解密。
在特定实施例中，SUPL服务器110和移动设备120可以参与相互认证的过程。例如，在操作期间，移动设备120处的认证逻辑126可以确定移动设备120是否支持基于通用引导架构（GBA）的认证。如果移动设备120支持基于GBA的认证，则移动设备120和SUPL服务器110可以执行基于GBA的认证过程134。当接入网络130是3GPP或者3GPP2网络时，可以选择基于GBA的认证。移动设备120可以通过向SUPL服务器110发送消息131来发起TLS握手过程。消息131可以指示由移动设备120处的TLS加密/解密逻辑127所支持的一个或多个TLS密码组。例如，消息131可以是客户端问候（ClientHello）消息，并且所支持的TLS密码组可以由ClientHello.cipher_suites字段来指示。
SUPL服务器110可以对消息131进行处理，并且确定所指示的TLS密码组中任何一个SUPL是否也被服务器110支持（即，是否存在任何共同支持的TLS密码组）。如果移动设备120和SUPL服务器110都支持TLS预共享密钥（TLS-PSK）密码组，则可以支持GBA，并且SUPL服务器110可以执行基于GBA的认证过程134。否则，SUPL服务器110可以经由消息132发起基于证书的认证，或者可以发起交替客户端认证（ACA）。ACA可以提供相互认证，并且可以取决于所使用的接入网络的类型（例如，GSM/UMTS和CDMA）。在ACA认证期间，SUPL服务器110可以通过将由移动设备120所提供的IP地址与由接入网络130所提供的对应于移动设备120的IP地址进行比较，来验证移动设备120的因特网协议（IP）地址绑定。基于证书的认证可以独立于接入网络130的类型，并且可以在接入网络130是Wi-Fi网络时使用。消息132可以包括由SUPL服务器110和移动设备120所支持的非PSK TLS密码组的指示、服务器证书113（其包括服务器公钥114）、以及对设备证书的请求。为了说明，消息132可以包括服务器问候消息（ServerHello），服务器问候消息包括指示共同支持的TLS密码组的ServerHello.cipher_suite字段。
响应于消息132，移动设备120可以发送包括设备证书123的消息133。SUPL服务器110可以通过将设备证书123中的设备ID125与所存储的设备ID（例如，如参考图8-9进一步所描述的，所存储的先前由SUPL服务 器110安全地验证为与SUPL用户相关联的设备ID）进行比较，来尝试识别与移动设备120相关联的SUPL用户。如果没有识别出SUPL用户，则可以终止SUPL服务器110和移动终端120之间的通信会话。如果识别出SUPL用户，则TLS握手可以完成，并且SUPL服务器110可以授权移动设备120接入为SUPL用户提供的基于SUPL的服务（例如，基于位置的服务。）
在特定实施例中，还可以利用不同的认证方法。例如，当移动设备120是WiMAX兼容设备和/或接入网络是WiMAX网络时，如果移动设备120和SUPL服务器110都支持基于SUPL加密密钥（SEK）的认证方法，则基于SEK的认证方法对于SUPL服务器110和移动设备120的相互认证可以是优选的。作为另一个例子，如果SUPL服务器110不支持基于证书的认证，则SUPL服务器110可以在不请求设备证书的情况下发送消息132，以发起不同的认证方法，诸如ACA（当移动设备120在3GPP或者3GPP2接入网络上时，ACA可以提供依赖于接入网络的相互认证）或仅SLP认证（其可以提供非相互认证，并且通常可以仅在紧急情况期间使用）。
因此，图1的***100可以能够独立于接入网络在移动设备和SUPL服务器之间进行相互认证。例如，接入网络130可以是3GPP网络、3GPP2网络、WiMAX网络、Wi-Fi网络、或者某些其它网络。图1的***100还可以提供对多种相互认证方法的支持，包括基于GBA的认证、基于SEK的认证、基于证书的认证、基于ACA的认证、以及仅SLP认证。
参考图2，示出了在SUPL环境中对认证方法进行协商的方法的特定实施例，并且被概括地标记为200。在说明性实施例中，方法200可以由图1的SUPL服务器110来执行。
方法200可以包括：在202，在SUPL服务器处从移动设备接收由该移动设备所支持的一个或多个TLS密码组的指示。例如，在图1中，SUPL服务器110可以从移动设备120接收消息131，其中，消息131指示由移动设备120所支持的一个或多个TLS密码组。
方法200还可以包括：在204，确定由移动设备所指示的至少一个TLS-PSK密码组是否也被SUPL服务器支持。例如，在图1中，SUPL服务器110可以确定由移动设备120所支持的任何TLS-PSK密码组是否也被SUPL服务器110支持。
响应于在204确定TLS-PSK密码组是被SUPL服务器和移动设备所共同支持的，在206，可以执行基于GBA的认证过程来对移动设备进行认证。例如，在图1中，SUPL服务器110可以执行基于GBA的认证过程134。响应于在204确定TLS-PSK密码组不被SUPL服务器和移动设备所共同支持，在208，可以执行基于证书的认证过程。基于证书的过程可以包括向移动设备发送服务器证书，以及从移动设备接收设备证书，并且可以独立于由移动设备所使用的接入网络。例如，在图1中，SUPL服务器110可以执行基于证书的认证过程，其中包括经由消息132将服务器证书113发送到移动设备120，并且经由消息133从移动设备120接收设备证书123。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图2的方法200。作为例子，图2的方法200可以由执行指令的处理器来执行。
参考图3，示出了在SUPL环境中使用证书执行认证的方法的特定实施例，并且被概括地标记为300。在说明性实施例中，方法300可以由图1的移动设备120来执行。
方法300可以包括：在302，在移动设备处存储特定于该移动设备的至少一个安全证书。该至少一个安全证书可以包括移动设备的设备标识符。例如，在图1中，移动设备120可以存储包含设备ID125（例如，IMEI、MSID、序列号、或者另一全球唯一标识符）的设备证书123。
方法300还可以包括：在304，将至少一个安全证书发送到SUPL定位平台（SLP），以基于设备标识符与所存储的设备标识符的比较将移动设备认证为与SUPL用户相关联。例如，在图1中，移动设备120可以经由消息133将设备证书123发送到SUPL服务器110（例如，SLP），使得SUPL服务器110能够基于设备ID125与所存储的先前由另一实体提供的设备ID的比较来将移动设备120认证为与SUPL用户相关联。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图3的方法300。作为例子，图3的方法300可以由执行指令的处理器来执行。
参考图4，示出了在SUPL环境中使用证书执行认证的方法的另一特定实施例，并且概括地标记为400。在说明性实施例中，方法400可以由图1的SUPL服务器110执行。
方法400可以包括：在402，在SUPL服务器处从移动设备接收由该移动设备所支持的一个或多个TLS密码组的指示。例如，在图1中，SUPL服务器110可以从移动设备120接收消息131，其中，消息131指示由移动设备120所支持的一个或多个TLS密码组。
方法400还可以包括：在404，从SUPL服务器向移动设备发送消息。该消息可以包括：服务器证书，其包括SUPL服务器的标识符和SUPL服务器的公钥；对移动设备的设备证书的请求；以及至少一个TLS密码组的选择。例如，在图1中，SUPL服务器110可以将消息132发送到移动设备120，其中，消息132包括服务器ID115、服务器公钥114、对移动设备120的设备证书123的请求、以及共同支持的TLS密码组的选择。
方法400还可以包括：在406，从移动设备接收包括该移动设备的设备证书的应答。例如，在图1中，SUPL服务器110可以接收包括设备证书123的消息133。
方法400可以包括：在408，基于设备证书将移动设备认证为与SUPL用户相关联。例如，在图1中，SUPL服务器110处的认证逻辑116可以基于设备证书123，将移动设备120认证为与SUPL用户相关联。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合来实现图4的方法400。作为例子，图4的方法400可以由执行指令的处理器执行。
无论使用参考图1-4所描述的哪个认证方法，一旦完成认证，则SUPL服务器（例如，SLP）和移动设备（例如，SET）可以在SUPL会话期间进行有关于基于SUPL的服务的通信。参考图5，示出了可以在SUPL服务器510和移动设备520之间进行交换的消息的特定实施例，并且概括地标记为500。
在特定实施例中，SUPL服务器510和移动设备520可以在SUPL会话的上下文中，经由用户定位协议（ULP）消息进行通信。例如，SUPL服务 器510可以配置为将SUPL INIT消息530发送到移动设备520。SUPL INIT消息530可以代表由SUPL服务器110所发送以发起SUPL会话的会话发起消息。为了预防伪装和重放攻击，可以将保用应用于SUPL INIT消息530。在特定实施例中，SUPL INIT消息530可以包括保护等级参数。保护等级参数可以包括等级参数（其指示是实施空、模式A、还是模式B SUPL INIT保护）和保护参数（例如，包括密钥标识符类型和密钥标识符中的至少一个）中的至少一个。在特定实施例中，空SUPL INIT保护不可以提供端到端完整性或者重放保护，模式A SUPL INIT保护可以通过使用由SUPL服务器510在安全ULP会话期间发送到移动设备520的共享密钥来提供端到端完整性和重放保护，而模式B SUPL INIT保护可以使用从基于PSK的方法（例如，GBA或者SEK方法）得到的共享密钥来提供端到端完整性和重放保护。
在特定实施例中，可以基于会话发起密钥（例如，SUPL_INIT_ROOT_KEY）来实现SUPL INIT保护。在接收到SUPL INIT消息530之后，移动设备520可以确定移动设备520先前是否从SUPL服务器510接收到有效的SUPL_INIT_ROOT_KEY，并且如果如此，该先前接收的SUPL_INIT_ROOT_KEY是否仍然有效。如果移动设备520具有有效的SUPL_INIT_ROOT_KEY，则移动设备520可以使用该SUPL_INIT_ROOT_KEY来对SUPL INIT消息530进行认证，并且响应于对SUPL INIT消息530的成功认证，可以发起与SUPL服务器510的SUPL会话。
在特定实施例中，如果移动设备520不具有有效的SUPL_INIT_ROOT_KEY，则移动设备520可以向SUPL服务器510发送消息，并且可以响应于该消息，接收有效的SUPL_INIT_ROOT_KEY。例如，移动设备520可以发送包括SUPL_INIT_KEYREQUEST参数的消息，其代表对有效SUPL_INIT_ROOT_KEY的请求。替代地，移动设备520可以指示存在无效或者不同步的SUPL_INIT_ROOT_KEY，而不是请求新的SUPL_INIT_ROOT_KEY。例如，移动设备520可以发送包括SUPL INIT根密钥状态参数541的ULP消息540，其指示由移动设备520所拥有的“当前”SUPL_INIT_ROOT_KEY是无效的还是不同步的。在特定实施例中， 可以将SUPL INIT根密钥状态参数541包括在ULP消息540的SET能力参数内。将意识到的是，将SUPL INIT根密钥状态参数541包括在SET能力参数内可以使得能够在SUPL2.0中所定义的消息中的传输SUPL_INIT_ROOT_KEY状态信息，其中该消息选择性地或者强制性地包括SET能力参数，而不必出于发送SUPL_INIT_ROOT_KEY状态信息的目的引入专用消息。在特定实施例中，针对模式ASUPL INIT保护，但是不针对空保护或者模式B SUPL INIT保护，可以将SUPL INIT根密钥状态参数541包括在SET能力参数内。
应该注意到的是，移动设备520可以不针对每个网络发起的SUPL会话指示无效的SUPL_INIT_ROOT_KEY。可以向移动设备520提供SUPL_INIT_ROOT_KEY一次，并且随后，在密钥期满之前，所提供的密钥可以针对多个网络发起的SUPL会话是有效的。
SUPL服务器510可以发送包括SUPL INIT密钥响应参数的ULP消息。例如，SUPL服务器510可以发送包括SUPL INIT密钥响应参数551的SUPL END消息550。应该注意到的是，可以不直接响应于SUPL INIT根密钥状态指示而发送SUPL INIT密钥响应；SUPL INIT密钥响应可以在“常规”SUPL END消息中，该“常规”SUPL END消息可以不在同一个SUPL会话中（例如，如果该SUPL会话不是以从SLP到SET的SUPL END消息结束的）。SUPL INIT密钥响应参数551可以包括模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY（例如，“新的”SUPL_INIT_ROOT_KEY）和模式A密钥有效期中的至少一个。
当通用SUPL会话（GSS）是活动的时，SLP（即，SUPL服务器510）可以发起与SET（即，移动设备520）的通信。SUPL服务器510可以发送会话重发起消息（例如，SUPL REINIT消息560）。可以按照本文参照SUPLINIT保护所描述的来实现SUPL REINIT保护。例如，如果移动设备520不拥有有效的SUPL_INIT_ROOT_KEY（该SUPL_INIT_ROOT_KEY可以用作会话发起密钥以及会话重发起密钥两者），则移动设备520可以经由SUPL INIT根密钥状态参数541指示缺乏有效的SUPL_INIT_ROOT_KEY，并且可以接收作为响应的SUPL END消息550（包括SUPLINIT密钥响应参数551）。当移动设备520具有有效的SUPL_INIT_ROOT_KEY时，移动设备 520可以对SUPL REINIT消息560进行认证，并且可以响应于对SUPL REINIT消息560的成功认证，重发起与SUPL服务器510的SUPL会话。在特定实施例中，SUPL REINIT消息560还可以包括诸如本文参考SUPL INIT消息530所描述的保护等级参数。
在特定实施例中，当移动设备520不具有有效SUPL_INIT_ROOT_KEY时（例如，在加电时或者当所拥有的SUPL_INIT_ROOT_KEY的有效期期满时），移动设备520可以应用空SUPLINIT保护和空SUPL REINIT保护。当设置了空保护时，移动设备520可以处理所有SUPL INIT和SUPL REINIT消息。如果移动设备520具有有效的SUPL_INIT_ROOT_KEY，则可以应用模式A或者模式B保护。
因此，如在图5中所示出的，可以使用各种消息和消息参数来实现SUPL***中的安全。例如，可以使用保护等级参数来指示SUPL INIT和SUPL REINIT保护的等级。作为另一个例子，可以使用SUPL INIT根密钥状态参数来指示当前的SUPL_INIT_ROOT_KEY是无效的还是不同步的。作为另一个例子，可以使用SUPL INIT密钥响应参数来提供“新的”SUPL_INIT_ROOT_KEY。
参考图6，示出了在SUPL环境中会话发起期间的认证的方法的特定实施例，并且被概括地标记为600。在说明性实施例中，方法600可以由图5的移动设备520执行。
方法600可以包括：在602，在移动设备处从安全用户平面定位（SUPL）服务器接收会话发起消息，以在SUPL服务器和移动设备之间发起SUPL会话。例如，在图5中，移动设备520可以从SUPL服务器510接收SUPL INIT消息530。
方法600还可以包括：在604，在接收会话发起消息之前确定移动设备是否接收到有效的会话发起消息密钥。例如，在图5中，移动设备520可以确定其是否拥有有效的SUPL_INIT_ROOT_KEY。
当移动设备具有有效的会话发起消息密钥时，方法600还可以包括：在606，使用会话发起消息密钥（例如，SUPL_INIT_ROOT_KEY）对会话发起消息进行认证，以及在608，响应于对会话发起消息的成功认证，发起与SUPL服务器的SUPL会话。例如，在图5中，移动设备520可以使用有 效的SUPL_INIT_ROOT_KEY对SUPL INIT消息530进行认证，并且可以发起与SUPL服务器510的SUPL会话。
当移动设备不具有有效的会话发起消息密钥时，方法600可以包括：在610，向SUPL服务器发送消息，以及在612，响应于该消息，从SUPL服务器接收会话发起消息。为了说明，SLP和SET可以采用空SUPL INIT保护进行会话，并且SET可以在其SUPL_INIT_ROOT_KEY是无效的会话期间发送指示。例如，在图5中，移动设备520可以将包括SUPL INIT根密钥状态参数541的消息发送到SUPL服务器510，并且可以接收作为响应的包括SUPL INIT密钥响应参数551的消息。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图6的方法600。作为例子，图6的方法600可以由执行指令的处理器执行。
参考图7，示出了在SUPL环境中在会话重发起期间的认证的方法的特定实施例，并且被概括地标记为700。在说明性实施例中，方法700可以由图5的移动设备520执行。
方法700可以包括：在702，在移动设备处从安全用户平面定位（SUPL）服务器接收会话重发起消息，以继续在SUPL服务器和移动设备之间进行SUPL会话。例如，在图5中，移动设备520可以从SUPL服务器510接收SUPL REINIT消息560。SUPL REINIT消息560可以代表网络发起的用以继续SUPL服务器510和移动设备520之间的现有的通用SUPL会话（GSS）的尝试。
方法700还可以包括：在704，确定移动设备在接收到会话重发起消息之前是否接收到有效的会话发起消息。例如，在图5中，移动设备520可以确定其是否拥有有效的SUPL_INIT_ROOT_KEY。
当移动设备具有有效的会话发起消息密钥时，方法700还可以包括：在706，使用会话发起消息密钥对会话重发起消息进行认证，以及在708，响应于对会话重发起消息的成功认证，继续与SUPL服务器的SUPL会话。例如，在图5中，移动设备520可以使用有效的SUPL_INIT_ROOT_KEY对SUPL REINIT消息560进行认证，并且可以重发起与SUPL服务器510 的SUPL会话。
当移动设备不具有有效的会话发起消息密钥时，方法700可以包括：在710，向SUPL服务器发送消息，以及在712，响应于该消息，从SUPL服务器接收会话发起消息密钥。为了说明，SLP和SET可以采用空SUPL INIT保护进行会话，并且SET可以在其SUPL_INIT_ROOT_KEY是无效的会话期间发送指示。例如，在图5中，移动设备520可以将包括SUPL INIT根密钥状态参数541的消息发送到SUPL服务器510，并且可以接收作为响应的包括SUPL INIT密钥响应参数551的消息。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图7的方法700。作为例子，图7的方法700可以由执行指令的处理器执行。
在特定实施例中，可以经由与基于证书、基于GBA、基于SEK、基于ACA、以及仅SLP的方法不同的方法来执行移动设备和SUPL服务器之间的相互认证。例如，图8示出了可操作以在SUPL环境中使用多个标识符/密码来执行认证的***800的特定实施例。***800包括能够与SUPL服务器（例如，SLP）820进行通信的移动设备810（例如，SET）。
除了基于多个标识符/密码进行认证之外，图8的***800还示出了将设备证书绑定到SUPL用户的特定例子。例如，***800可以包括网页服务器830，其提供了在设备证书和SUPL用户之间创建绑定的机制。应该注意到的是，网页服务器830可以不为SUPL会话提供认证，而是提供随后可以在SUPL认证期间由SLP使用的绑定信息。该绑定通常可以仅执行一次，并且可以在SET能够参与SUPL会话之前执行。一旦执行了绑定，可以将设备证书和用户信息的组合发送到SLP，并且SLP可以存储该信息并且使用其用于客户端认证。因此，在执行绑定之后，SLP可以“知道”特定的移动设备属于特定的SUPL用户。网页服务器830可以包括处理器831和存储器832，存储器832存储可由处理器831执行的指令。例如，该指令可以代表认证逻辑833。网页服务器830还可以包括网络接口834，网络接口834可操作以与移动设备810以及与SUPL服务器820进行通信。应该注意到，网页服务器830仅是如何向用户提供设备证书绑定的一个例子。 在其它实施例中，可以使用其它绑定机制。或者，网页服务器830可以存储设备证书和用户信息的组合，并且SLP（在使用设备证书执行了相互认证之后）可以要求网页服务器830提供与该设备证书相关联的用户信息。
移动设备810可以包括认证逻辑811（例如，存储在移动设备810的存储器中并且可由移动设备810的处理器执行的指令）。认证逻辑811可以配置为与网页服务器830处相应的认证逻辑833进行通信，以将移动设备810与特定的SUPL用户相关联（例如，“绑定”或者“注册”）。例如，绑定过程可以开始于移动设备810从网页服务器830接收消息835，其中，消息835包括网页服务器830的服务器证书和网页服务器830的公钥。移动设备810可以通过向网页服务器830发送消息813来进行响应，其中，消息813包括移动设备810的安全证书。例如，移动设备810的安全证书可以包括设备证书，该设备证书包括移动设备810的公钥、国际移动设备标识（IMEI）、移动站标识（MSID）、和/或序列号。移动设备810还可以将包括用户标识信息（例如，与SUPL用户相关联的用户标识符和密码）的消息814发送到网页服务器830。可以使用网页服务器830的公钥对消息813、814中的一者或二者进行加密，并且网页服务器830可以使用网页服务器830的私钥对经加密的消息进行解密。
网页服务器830可以对由移动设备810所提供的用户标识信息进行认证，以确定该用户标识信息是否与SUPL服务的授权用户相关联。例如，网页服务器830可以将所提供的用户标识信息与位于或者可接入网络页服务器830的SUPL用户数据库进行比较。在验证了用户标识信息，网页服务器830可以通过发送消息836至SUPL服务器820以将移动设备810认证为与SUPL服务的授权用户相关联来完成绑定过程。消息836可以包括移动设备810的安全证书（例如，包含设备公钥和IMEI、MSID和/或序列号的设备证书）。
移动设备810的认证逻辑811还可以配置为与SUPL服务器820处的相应的认证逻辑821进行通信，以在SUPL会话的开始或者重新开始之前执行基于用户模式TLS的相互认证。例如，移动设备810可以发送消息815至SUPL服务器820，其中，消息815包括第一标识符和第一密码。在特定实施例中，第一密码可以是用户选择的，并且可能具有相对较低的加密强度。在说明性实施例中，第一标识符和第一密码可以对应于由移动设备810经由消息814发送到网页服务器830的标识符和密码。
在接收到第一标识符和第一密码之后，认证逻辑821可以将第一标识符和第一密码认证为与SUPL服务器的授权用户相关联。例如，认证逻辑821可以验证第一标识符和第一密码对应于之前绑定到移动设备810的授权用户。当认证成功时，SUPL服务器820处的标识符/密码生成逻辑822可以生成第二标识符和第二密码以代替第一标识符和第一密码。在特定实施例中，第二密码可以具有比第一密码更高的加密强度。SUPL服务器820可以经由消息824将第二标识符和第二密码发送给移动设备810。在随后从移动设备810接收到第二标识符和第二密码之后，SUPL服务器820可以与移动设备810建立SUPL会话。在特定实施例中，出于安全目的，可以保持向移动设备810的用户隐藏第二标识符和第二密码。
虽然前面的描述涉及与单个移动设备（例如，SET）相关联的SUPL用户，但是SUPL用户可以与多个设备相关联。例如，与移动设备810相关联的SUPL用户还可以具有对第二移动设备840的接入。为了对第二移动设备840进行授权，SUPL用户可以以类似于绑定第一移动设备810的方式将第二移动设备840绑定至他或者她的账号（例如，SUPL账号）。为了在将第二移动设备840绑定到SUPL用户账号之后执行相互认证，第二移动设备840可以将包括第一标识符和第二密码的消息841发送给SUPL服务器820。在将第一标识符和第一密码认证为与授权SUPL用户相关联之后，SUPL服务器820可以确定是否也应该授权第二移动设备840接入SUPL服务。例如，SUPL服务器820可以实现设备每用户的限制，并且可以确定允许第二移动设备840接入SUPL服务是否将超过与准许接入SUPL服务的授权用户相关联的移动设备的阈值数目。如果允许第二移动设备840接入SUPL服务不会超过阈值，则SUPL服务器820可以将包括第三标识符和加密性强的第三密码的消息825发送到第二移动设备840。第三标识符和第三密码可以代替第一标识符和第一密码，并且可以由第二移动设备840随后用于开始SUPL会话。
在特定实施例中，第三标识符和第三密码可以与发送到第一移动设备810的第二标识符和第二密码不同。通过向SUPL用户的每个移动设备提供 不同的标识符/密码的组合，SUPL服务器820可以在每设备基础上实现监测。例如，SUPL服务器820处的监测逻辑823可以配置为对由使用第二标识符的第一移动设备810对SUPL服务的使用进行监测，并且对由使用第三标识符的第二移动设备840对SUPL服务的使用进行监测。
因此，图8的***800可以提供绑定过程，通过该绑定过程将一个或多个移动设备与特定SUPL用户进行绑定、注册和/或相关联。将意识到的是，所描述的绑定过程可以选择性地补充参考图1-4所描述的认证过程。例如，如参考图1-4所描述的，SUPL服务器110可以通过将移动设备的设备ID125与所存储的之前由SUPL用户所安全验证的设备ID进行比较，来尝试将SUPL用户识别为与移动设备120相关联。在说明性实施例中，图1的SUPL服务器110可以是SUPL服务器820，图1的移动设备120可以是移动设备810，并且可以将所存储的设备ID包括在绑定过程期间经由消息836提供给SUPL服务器820的设备安全证书中。
另外，图8的***800可以提供认证过程，该认证过程可以选择性地代替参考图1-4所描述的认证过程。例如，特定实施例可以包括使用图8的多标识符/密码认证过程，代替基于GBA的相互认证、基于SEK的相互认证和/或基于认证的相互认证。
参考图9，示出了在SUPL环境中使用网页服务器进行认证的方法的特定实施例，并且被概括地标记为900。在说明性实施例中，方法900可以由图8的网页服务器830执行。
方法900可以包括：在902，从网页服务器向支持SUPL的移动设备发送服务器证书。该服务器证书可以包括网页服务器的公钥。例如，在图8中，网页服务器830可以将消息835发送给移动设备810，其中，消息835包括网页服务器830的证书和公钥。
方法900还可以包括：在904，在网页服务器处从移动设备接收包括该移动设备的安全证书的消息。例如，在图8中，网页服务器830可以从移动设备810接收消息813，其中，消息813包括移动设备810的安全证书（例如，设备证书和设备公钥）。
方法900还可以包括：在906，使用网页服务器的私钥对消息进行解密，以及在908，从移动设备接收用户标识信息。例如，在图8中，网页服务器 830可以使用私钥对消息813进行解密，并且可以经由消息814从移动设备810接收用户标识信息（例如，标识符和密码）。可替换地或者另外，还可以使用网页服务器的私钥对用户标识信息进行解密。
方法900可以包括：在910，将用户标识信息认证为标识SUPL服务器的授权用户，以及在912，将移动设备的安全证书发送给SUPL服务器，以使得SUPL服务器能够将该移动设备认证为与SUPL服务的授权用户相关联。例如，在图8中，网页服务器830可以将用户标识信息认证为标识授权的SUPL用户，并且可以经由消息836将设备安全证书发送到SUPL服务器820。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图9的方法900。作为例子，图9的方法900可以由执行指令的处理器执行。
参考图10，使出了在SUPL环境中使用多个标识符/密码进行认证的方法的特定实施例，并且被概括地标记为1000。在说明性实施例中，方法1000可以由图8的SUPL服务器820执行。
方法1000可以包括：在1002，在SUPL服务器处从移动设备接收第一标识符和第一密码，以及在1004，将第一标识符和第一密码认证为与SUPL服务的授权用户相关联。例如，在图8中，SUPL服务器可以经由消息815从移动设备810接收第一标识符和第一密码，并且可以将第一标识符和第一密码认证为与授权用户（例如，之前绑定到移动设备810的授权用户）相关联。
方法1000还可以包括：在1006，将第二标识符和第二密码发送到移动设备以代替第一标识符和第一密码。SUPL服务器可以配置为在从移动设备接收到第二标识符和第二密码之后，与该移动设备建立SUPL会话。例如，在图8中，SUPL服务器820可以生成第二标识符和第二密码，并且经由消息824将第二标识符和第二密码发送到移动设备810，并且在移动设备810随后接收到第二标识符和第二密码之后，可以与移动设备810建立SUPL会话。
方法1000还可以包括：在1008，在SUPL服务器处从第二移动设备接 收第一标识符和第一密码，以及在1010，将第一标识符和第一密码认证为与SUPL服务的授权用户相关联。例如，在图8中，SUPL服务器820可以经由消息841从第二移动设备840接收第一标识符和第一密码，并且可以将第一标识符和第一密码认证为与授权用户相关联。为了说明，还可以经由图9的方法900将第二移动设备840预先绑定到授权用户。
方法1000可以包括：在1012，确定允许第二移动设备接入SUPL服务是否将超过与准许接入SUPL服务的授权用户相关联的移动设备的阈值数目。例如，在图8中，网页服务器820可以确定允许第二移动设备840接入SUPL服务是否将超过阈值。在特定实施例中，当允许第二移动设备840接入SUPL服务不会超过阈值时，网页服务器820可以经由消息825将第三标识符和第三密码发送到第二移动设备。网页服务器820还可以对由第一移动设备810和第二移动设备840对SUPL服务的使用进行监测。
在特定实施例中，可以经由现场可编程门阵列（FPGA）器件、专用集成电路（ASIC）、诸如中央处理单元（CPU）的处理单元、数字信号处理器（DSP）、控制器、另一个硬件器件、固件器件、或者其任意组合实现图10的方法1000。作为例子，图10的方法1000可以由执行指令的处理器执行。
参考图11，描述了无线通信设备的特定说明性实施例的方框图，并且被概括地标记为1100。例如，设备1100可以是诸如图1的移动设备120、图5的移动设备520、图8的第一移动设备810、或者图8的第二移动设备840的支持SUPL的终端（SET）。
设备1100包括连接到存储器1132的处理器1110。存储器1132可以包括通过处理器1100可执行以便执行在这里所公开的诸如图3的方法300、图6的方法600、图7的方法700、或者其任意组合的方法和过程的指令1160。
图11还示出了连接到处理器1110和显示器1128的显示器控制器1126。可以将CODEC1134连接到处理器1110并且连接到扬声器1136和麦克风1138。图11还指示可以将一个或多个无线控制器1140连接到处理器1110并且连接到无线天线1142、1143。在特定实施例中，天线1142可以是3GPP、3GPP2和/或WiMAX天线，并且天线1143可以是Wi-Fi天线。还可以将卡接口1170连接到处理器1110并且连接到无线控制器1140。可以将卡接口1170配置为容纳存储设备1100的安全证书的卡1172（例如，用户标识模块 （SIM）卡、通用集成电路卡（UICC）或者其它卡）。例如，安全证书可以包括设备证书、公共/私钥对、IMEI、MSID、序列号、全球唯一标识符、或者其任意组合。可替换地或者另外，可以将诸如安全证书1161的设备1100的安全证书存储在存储器1132（例如，用户不可修改和/或不可访问）的“安全”位置中。
在特定实施例中，将显示器控制器1126、存储器1132、CODEC1134、无线控制器1140和卡接口1170包括在封装内***或者片上***设备（例如，移动台调制解调器（MSM））1122中。在特定实施例中，将诸如触摸屏和/或按键的输入设备1130和电源1144连接到片上***设备1122。此外，在特定实施例中，如在图11中所说明的，显示器1128、输入设备1130、扬声器1136、麦克风1138、无线天线1142和1143、以及电源1144在片上***设备1122外部。然而，可以将显示器1128、输入设备1130、扬声器1136、麦克风1138、无线天线1142和1143、以及电源1144中的每个连接到片上***设备1122诸如接口或者控制器的组件。
结合所描述的实施例，公开了一种包括用于存储至少一个特定于移动设备的安全证书的模块的装置。例如，用于存储的模块可以是图2的存储器122、图11的存储器1132、图11的卡1172、配置为存储数据的一个或多个器件、或者其任意组合。该装置还可以包括用于使移动设备将至少一个安全证书发送给SLP以便将移动设备认证为与SUPL用户相关联的模块。例如，用于使得移动设备进行上述操作的模块可以是图1的处理器121、图11的处理器1110、图1的无线控制器1140、配置为导致数据传输的一个或多个器件、或者其组合。
另外，公开了一种包括用于在网页服务器处从支持SUPL的移动设备接收消息的模块的装置，其中，该消息包括移动设备的安全证书。例如，用于接收消息的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于在网页服务器处从移动设备接收用户标识信息的模块。例如，用于接收用户标识信息的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于将用户标识信息认证为标识SUPL服务的授权用户的模块。例如，用于认证的模块可以是图8的处理器831、配置为对用户标识信 息进行认证的一个或多个器件、或者其任意组合。该装置包括用于将移动设备的安全证书发送给SUPL服务器以便使得SUPL服务器能够将移动设备认证为与SUPL服务的授权用户相关联的模块。例如，用户发送的模块可以是图8的网络接口834、配置为接收数据的一个或多个器件、或者其任意组合。
此外，公开了一种包括用于在SUPL服务器处从移动设备接收第一标识符和第一密码的模块的装置。例如，用于接收的模块可以是图8的SUPL服务器820的网络接口、配置为接收数据的一个或多个器件、或者其任意组合。该装置还包括用于将第一标识符和第一密码认证为与SUPL服务的授权用户相关联的模块。例如，用于认证的模块可以包括诸如图1的处理器111、可编程执行图8的认证逻辑821的处理器、配置为对标识符和密码进行认证的一个或多个器件、或者其任意组合。该装置还包括用于将第二标识符和第二密码发送到移动设备以代替第一标识符和第一密码的模块，其中，SUPL服务器配置为在从移动设备接收到第二标识符和第二密码之后，与移动设备建立SUPL会话。例如，用于发送的模块可以是SUPL服务器820的网络接口、配置为发送数据的一个或多个器件、或者其任意组合。该装置可以包括用于生成第二标识符和第二密码的模块。例如，用于生成的模块可以包括诸如图1的处理器111、可编程执行图8的标识符/密码生成逻辑822的处理器、配置为生成标识符和密码的一个或多个器件、或者其任意组合。
在特定实施例中，还可以参考下文的附加实施例对前述所有或者部分***和方法进行描述，和/或可以用参考下文的附加实施例所描述的***和方法有选择地单独或者组合代替前述所有或者部分***和方法。
附加实施例1
介绍
·SUPL2.0中的安全是特定于接入网络的：
·交替客户端认证（ACA）需要接入核心网络以便基于源IP地址对SET进行识别
·GBA仅可应用于3GPP/3GPP2网络
·SEK仅可应用于WiMAX网络
·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：
·同时支持GBA和“用户名/密码”认证的简单框架
·可以使用单个TLS变体
·对规范和实现改变最小
概念综述
·ULP安全
·具有服务器证书的TLS
·两种客户端认证模式
-（用户模式）:（User_ID,User_secret）=（用户名,密码）
-（GBA模式）:（User_ID,User_secret）=（B-TID,Ks_NAF）
·添加到所有消息的（User_ID,Counter,Digest），将Digest计算为
·A1=SLP_Domain||ULP_Message,
·Digest=HMAC（User_secret,A1）
·发送器将（User_ID,Counter,Digest）添加到所有消息，接收器验证
·用于更新SUPL INIT认证的ULP
·SUPL INIT保护[例如，仅非紧急]
·Mimics ULP v2.0基本SUPL INIT保护
·使用通过SLP经由ULP提供的SUPL INIT认证
设置细节
·离线
·（用户模式）用户和SLP对（用户名,密码）取得一致
-SLP可以将（用户名,密码）提供给用户
-用户可以将（用户名,密码）提供给SLP
-这可用于H-SLP或者A-SLP
·在SET处发起
·（用户模式）
-用户将（用户名,密码）输入到SUPL客户
·（GBA模式）
-SET采用BSF引导以便获得（B-TID,Ks）
-注意，SET可以于需要时更新（B-TID,Ks）
·SUPL客户执行与SLP的ULP会话，以便获得新的SUPL INIT认证
ULP会话安全提议
·可以使用具有服务器证书的TLS
·维护服务器认证
·将新参数添加到ULP消息
·将（User_ID,Req_Count,Req_Digest）添加到来自SET的消息
·将（User_ID,Resp_Count,Resp_Digest）添加到来自SLP的消息
·SET所发起的消息
·SET添加（User_ID,Req_Count,Req_Digest）
·SLP在对消息内容进行处理之前验证Req_Count和Req_Digest
·SLP所发起的消息
·SLP添加（User_ID,RespCounter,Resp_Digest）
·SET在对消息内容进行处理之前验证Resp_Count和Resp_Digest
Req_Count/Resp_Count
·Req_Count/Resp_Count具有相似的行为
·计数器的目的是能够进行重放检测
·每次ULP会话重置接收器和发送器中的Req_Count/Resp_Count
·即，当改变会话标识符时，重置计数器。
·在发送器处：
·Req_Count/Resp_Count每条消息递增并且添加到ULP消息
·在接收器处：
·接收器将Req_Count/Resp_Count与它们所期望的值进行比较。如果它们检测到重放，则它们以错误退出。否则，消息通过重放保护
Req_Digest/Resp_Digest生成
·Req_Digest/Resp_Digest生成可以是相同的
·将所有已知值***ULP_Message字段
·采用将Req_Digest/Resp_Digest字段设置为全零形成ULP_Message_Z作为ULP_Message
·形成DigestPayload=SLP_Domain“:”ULP_Message_Z
·计算
Req_Digest/Resp_Digest=HMAC-SHA256-32（User_secret,DigestPayload）
·将Req_Digest/Resp_Digest添加到ULP_Message中的合适字段·（用户模式）
·使用（User_ID,User_secret）:=（用户名,密码）
·（GBA模式）
·使用（User_ID,User_secret）:=（B-TID,Ks_NAF）,其中
·[SET]从Ks和SLP URL生成Ks_NAF
·[SLP]一旦它提取出User_ID字段，SLP就将B-TID提供给BSF，并且BSF返回Ks_NAF。Ks_NAF将不改变直到B-TID改变为止。
SUPL_INIT安全提议
·已经在ULP TS V2.0章节6.1.6.6中定义的Mimics基本SUPL_INIT保护
·从GBA预分配的密钥到SLP预分配的密钥的改编说明
·SLP在ULP会话期间在客户或者SLP主动性下更新（Key Identifier,SUPL_INIT_ROOT_KEY）
-当重置密钥标识符时重置BasicReplayCounter
·最小化所需的标准化努力
SUPL_INIT认证管理
·出现在任何连接会话的首次ULP交换中
·SET所发起的消息
·会话的首条消息应该包括
-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者
-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步
·SLP所发起的消息
·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认
·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者服务器希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息
-包含（Key Identifier,SUPL_INIT_ROOT_KEY）
示例呼叫流–SI立即固定
·步骤A:目标SET将req_count设置为1234（或者如SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPL START（user-id,req_count=1234,req_digest,…）消息发送到H-SLP。
·步骤B:H-SLP使用所接收的消息摘要（req_digest）检查SUPL START的确实性，并且还检查重放计数器（req_count）。H-SLP将res_count设置为4321（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（res_digest）。H-SLP将SUPL RESPONSE（user-id,res_count=4321,res_digest,…）消息发送给目标SET。在目标SET处SUPL START和SUPLRESPONSE之间的周期=UT1。
·步骤C:目标SET使用所接收的消息摘要（res_digest）检查SUPL RESPONSE的确实性，并且还检查重放计数器（res_count）。目标SET给req_count增加1（1234+1），并且计算消息摘要（req_digest）。目标SET将SUPL POS INIT（user-id,req_count=1234+1,req_digest…）消息发送给H-SLP。在H-SLP处SUPL RESPONSE和SUPL POS INIT之间的周期=ST1。
·步骤D:目标SET和H-SLP参与SUPL POS交换。在目标SET处SUPL POS INIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要 检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。
·步骤E:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPL END（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPL POS和SUPL END之间的周期=UT3。
示例呼叫流–NI立即固定
·步骤A:H-SLP将res_count设置为1234（或者如H-SLP所确定的任何其它顺序号）并且计算消息摘要（BasicMAC）。H-SLP将SUPL INIT（user-id,res_count=4321,BasicMAC,…）消息发送到目标SET。
·步骤B:目标SET使用所接收的消息摘要（BasicMAC）检查SUPL INIT的确实性，并且还检查重放计数器（res_count）。目标SET将req_count设置为1234（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPL POS INIT（user-id,req_count=1234,req_digest,…）消息发送给H-SLP。在H-SLP处SUPL INIT和SUPL POSINIT之间的周期=ST1。
·步骤C:目标SET和H-SLP参与SUPL POS交换。在目标SET处SUPL POS INIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。
·步骤D:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPL END（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPL POS和SUPL END之间的周期=UT3。
附加实施例2
介绍
·SUPL2.0中的安全是接入网络专用的：
·ACA需要接入核心网络以便基于源IP地址对SET进行识别
·GBA仅可应用于3GPP/3GPP2网络
·SEK仅可应用于WiMAX网络
·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：
·同时支持GBA和“用户名/密码”认证的简单框架
·可以使用单个TLS变体
·对规范和实现改变最小
概念综述
·ULP安全
·具有服务器证书的TLS
·两种客户端认证模式
-（用户模式）:（User_ID,User_secret）=（用户名,密码）
-（GBA模式）:（User_ID,User_secret）=（B-TID,Ks_NAF）
·添加到所有消息的（User_ID,Counter,Digest），将Digest计算为
·A1=SLP_Domain||ULP_Message,
·Digest=HMAC（User_secret,A1）
·发送器将（User_ID,Counter,Digest）添加到所有消息，接收器验证
·用于更新SUPL INIT认证（Key Identity,SUPL_INIT_ROOT_KEY）的ULP
·SUPL INIT保护[例如，仅非紧急]
·使用具有通过SLP（用户模式）或者GBA（GBA模式）生成的SULP INIT认证的ULPv2.0基本SUPL INIT保护
·使用在用户模式中通过SLP经由ULP提供的SUPL INIT认证
设置细节
·离线
·（用户模式）用户和SLP对（用户名,密码）取得一致
-SLP可以将（用户名,密码）提供给用户
-用户可以将（用户名,密码）提供给SLP
-这可用于H-SLP或者A-SLP
·在SET处发起
·（用户模式）
-用户将（用户名,密码）输入到SUPL客户
·（GBA模式）
-SET采用BSF引导以便获得（B-TID,Ks）
-注意，SET可以于需要时更新（B-TID,Ks）
·SUPL客户执行与SLP的ULP会话，以便获得新的SUPL INIT认证
ULP会话安全提议
·可以使用具有服务器证书的TLS
·维护服务器认证
·将新参数添加到ULP消息
·将（User_ID,Req_Count,Req_Digest）添加到来自SET的消息
·将（User_ID,Resp_Count,Resp_Digest）添加到来自SLP的消息
·SET所发起的消息
·SET添加（User_ID,Req_Count,Req_Digest）
·SLP在对消息内容进行处理之前验证Req_Count和Req_Digest
·SLP所发起的消息
·SLP添加（User_ID,RespCounter,Resp_Digest）
·SET在对消息内容进行处理之前验证Resp_Count和Resp_Digest
Req_Count/Resp_Count
·Req_Count/Resp_Count具有相似的行为
·计数器的目的是能够进行重放检测
·每次ULP会话重置接收器和发送器中的Req_Count/Resp_Count
·即，当改变会话标识符时，重置计数器。
·在发送器处：
·Req_Count/Resp_Count每条消息递增并且添加到ULP消息
·在接收器处：
·接收器将Req_Count/Resp_Count与它们所期望的值进行比较。如果它们
检测到重放，则它们以错误退出。否则，消息通过重放保护
Req_Digest/Resp_Digest生成
·Req_Digest/Resp_Digest生成可以是相同的
·将所有已知值***ULP_Message字段
·采用将Req_Digest/Resp_Digest字段设置为全零形成ULP_Message_Z作为ULP_Message
·形成DigestPayload=SLP_Domain“:”ULP_Message_Z
·计算
Req_Digest/Resp_Digest=HMAC-SHA256-32（User_secret,DigestPayload）
·将Req_Digest/Resp_Digest添加到ULP_Message中的合适字段
·（用户模式）
·使用（User_ID,User_secret）:=（用户名,密码）
·（GBA模式）
·使用（User_ID,User_secret）:=（B-TID,Ks_NAF）,其中
·[SET]从Ks和SLP URL生成Ks_NAF
·[SLP]一旦它提取出User_ID字段，SLP就将B-TID提供给BSF，并且BSF返回Ks_NAF。Ks_NAF将不改变直到B-TID改变为止。
SUPL_INIT安全提议
·使用已经在ULP TS V2.0章节6.1.6.6中定义的基本SUPL_INIT保护
·在用户模式中从GBA预分配的密钥到SLP预分配的密钥的改编说明
·在用户模式中SLP在ULP会话期间在客户或者SLP主动性下更新（KeyIdentifier,SUPL_INIT_ROOT_KEY）
-当重置密钥标识符时重置BasicReplayCounter
·最小化所需的标准化努力
SUPL_INIT保护参数
·用于基本SUPL INIT保护的SUPL INIT保护符由以下组成:
·密钥标识符
·BasicReplayCounter（长度=2个八位字节）
·BasicMAC（长度=4个八位字节）
·如下生成BasicMAC参数:
·BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,‘SUPL_INIT’）
·SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“Basic IK”）
·当重置密钥标识符时，重置BasicReplayCounter
·由于User_ID和User_secret即SUPL INIT保护与ULP消息认证独立工作，所以密钥标识符和SUPL_INIT_ROOT_KEY是不相同的
SUPL_INIT认证管理
·出现在任何连接会话的首次ULP交换中
·SET所发起的消息
·会话的首条消息应该包括
-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者
-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步
·SLP所发起的消息
·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认
·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者服务器希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息
-包含（Key Identifier,SUPL_INIT_ROOT_KEY）
示例呼叫流–SI立即固定
·步骤A:目标SET将req_count设置为1234（或者如SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPL START（user-id,req_count=1234,req_digest,…）消息发送到H-SLP。
·步骤B:H-SLP使用所接收的消息摘要（req_digest）检查SUPL START的确实性，并且还检查重放计数器（req_count）。H-SLP将res_count设置为4321（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（res_digest）。H-SLP将SUPL RESPONSE（user-id,res_count=4321,res_digest,…）消息发送给目标SET。在目标SET处SUPL START和SUPLRESPONSE之间的周期=UT1。
·步骤C:目标SET使用所接收的消息摘要（res_digest）检查SUPL RESPONSE的确实性，并且还检查重放计数器（res_count）。目标SET给req_count增加1（1234+1），并且计算消息摘要（req_digest）。目标SET将SUPL POS INIT（user-id,req_count=1234+1,req_digest…）消息发送给H-SLP。在H-SLP处SUPL RESPONSE和SUPL POS INIT之间的周期=ST1。
·步骤D:目标SET和H-SLP参与SUPL POS交换。在目标SET处SUPL POS INIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。
·步骤E:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPL END（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND 的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPL POS和SUPL END之间的周期=UT3。
示例呼叫流–NI立即固定
·步骤A:H-SLP将res_count设置为1234（或者如H-SLP所确定的任何其它顺序号）并且计算消息摘要（BasicMAC）。H-SLP将SUPL INIT（user-id,res_count=4321,BasicMAC,…）消息发送到目标SET。
·步骤B:目标SET使用所接收的消息摘要（BasicMAC）检查SUPL INIT的确实性，并且还检查重放计数器（res_count）。目标SET将req_count设置为1234（或者如通过SET所确定的任何其它顺序号）并且计算消息摘要（req_digest）。目标SET将SUPL POS INIT（user-id,req_count=1234,req_digest,…）消息发送给H-SLP。在H-SLP处SUPL INIT和SUPL POSINIT之间的周期=ST1。
·步骤C:目标SET和H-SLP参与SUPL POS交换。在目标SET处SUPL POS INIT和SUPLPOS之间的周期=UT2。每边基于所接收的消息摘要检查消息确实性，并且基于消息计数器（req_count/res_count）检查重放完整性。
·步骤D:H-SLP使用所接收的消息摘要（req_digest）检查所接收的最后一个SUPLPOS消息的确实性，并且还检查重放计数器（req_count）。H-SLP将req_count增加1（4321+1），并且计算消息摘要（res_digest）。H-SLP将SUPL END（user-id,res_count=4321+1,res_digest,…）消息发送给目标SET。目标SET使用所接收的消息摘要（res_digest）检查SUPLEND的确实性，并且还检查重放计数器（res_count）。在目标SET处SUPL POS和SUPL END之间的周期=UT3。
附加实施例3
介绍
·SUPL2.0中的安全是接入网络专用的：
·ACA需要接入核心网络以便基于源IP地址对SET进行识别
·GBA仅可应用于3GPP/3GPP2网络
·SEK仅可应用于WiMAX网络
·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：
·同时支持GBA和“用户名/密码”认证的简单框架
SUPL3.0安全概念综述I
SUPL3.0安全概念综述II
为SUPL3.0安全考虑下列两种选项:
选项I 选项II
ACA（A） ACA（A）
GBA（B） GBA（B）
用户模式ULP（C） 用户模式TLS（D）
选项I:概念综述
·ULP安全
·GBA模式:如之前那样使用TLS-PSK
·用户模式ULP:基于（用户名,密码）
–首先与服务器证书进行TLS握手，以便建立安全连接
·将（Username,Counter,Digest）添加到通过SET发送的所有ULP消息，将Digest计算为
–A1=SLP_Domain||ULP_Message,
–Digest=HMAC（Password,A1）
·SET将（Username,Counter,Digest）添加到所有消息，SLP验证
·用于更新为了SUPL INIT保护所需要的SUPL INIT认证（Key Identity,SUPL_INIT_ROOT_KEY）的ULP
选项I:离线过程
·用户模式ULP（离线）
·用户和SLP运营商对（用户名,密码）取得一致
·其它假设
·SET具有SLP的URL
·SET具有用于对SLP进行认证的合适的根认证
选项I:在线过程
·用于服务器认证和加密的具有服务器证书的TLS
·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）
·SLP在对ULP消息内容进行处理之前验证计数器和摘要
·计数器的目的是能够进行重放检测
·每次ULP会话重置接收器和发送器中的计数器
·在发送器处，计数器每条消息增加1并且将其添加到ULP消息
·在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。
选项II:概念综述
·ULP安全
·GBA模式:如之前那样使用TLS-PSK
·用户模式TLS:基于（用户名,密码）
–首先与服务器证书进行TLS握手，以便建立安全连接
–SLP发送“问候请求”以便发起TLS重新协商。随后，SET和SLP进行TLS-SRP握手（SRP=安全远程密码），以便使用（用户名，密码）对用户进行认证。
–需要第一个安全连接，以便在TLS-SRP握手中隐藏用户名。
·用于更新为了SUPL INIT保护所需要的基本保护SUPL INIT认证（KeyIdentity,SUPL_INIT_ROOT_KEY）的ULP
选项II:离线过程
·用户模式TLS（离线）
·用户和SLP运营商对（用户名,密码）取得一致
·其它假设
·SET具有SLP的URL
·SET具有用于对SLP进行认证的合适的根认证
选项II:在线过程
·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式
·SLP确定是以GBA模式还是用户模式继续进行
·如果GBA模式，则
·对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道
·相互认证
·在安全通道中交换数据
·如果用户模式，则
·首先采用服务器证书继续TLS握手，以便建立安全通道
·SET对SLP进行认证
·进行TLS-SRP握手（在安全通道内部交换消息）
·SLP对用户进行认证
·得到新的会话密钥
·受新的会话密钥保护在安全通道中交换数据
选项II:在线过程-首次TLS握手
·SET→SLP:客户问候:
·指示所有支持的密码组
–如果SET支持GBA，就指示支持TLS-PSK密码组
–如果SET支持用户模式，就指示支持采用服务器证书的TLS和TLS SRP
·SET此时不提供用户名，如果需要，将在下一次TLS握手中提供
·SLP→SET:服务器问候:
·指示所选择的密码组
–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组
–如果SLP选择用户模式，SLP就指示采用服务器证书的TLS
–对于所选择的密码组，呼叫流继续
选项II:在线过程-在首次TLS握手之后
·GBA模式
·SET和SLP在安全信道上开始通信
·用户模式
·SLP→SET:问候请求
·发起重新协商
·SET→SLP:客户问候
·指示支持TLS-SRP
·包括用户名作为每个TLS-SRP规范
·SET→SLP:服务器问候
·指示TLS-SRP的选择
·每个TLS-SRP继续交换
·在成功握手之后，SET和SLP开始在安全信道上交换数据。
SUPL INIT保护
·SUPL3.0中的SUPL INIT保护基于SUPL2.0中的SUPL INIT保护机制，并且使用附加到SUPL INIT的消息认证码（MAC）
·在用户模式中使用在ULP上提供的（Key Identity,SUPL_INIT_ROOT_KEY）计算MAC（GBA模式不需要提供）
·用于计算（Key Identity,SUPL_INIT_ROOT_KEY）的两种方法:
·GBA模式:（Key Identity,SUPL_INIT_ROOT_KEY）=（B-TID,Ks）
–（B-TID,Ks）是BSF的引导关
·用户模式:从（用户名，密码）生成（Key Identity,SUPL_INIT_ROOT_KEY）
·SUPL INIT保护对于选项I和选项II是相同的
SUPL INIT保护机制
·在SUPL v3.0中的两个保护级别:
·无
–无安全
·基本保护
–基于共享密钥标识，在ULP上提供的SUPL_INIT_ROOT_KEY
–来自SUPL v2.0的Mimics基本保护
–密钥标识符和SUPL_INIT_ROOT_KEY随着用户名、密码不同
·重新同步保护机制:
·基于SET可以从SET中的SLP认证验证的数字签名
·仅当SLP承认密钥标识、SLP和SET中的SUPL_INIT_ROOT_KEY变得不同步时可以使用
·计算可能很昂贵:可以节俭使用
基本SUPL INIT保护参数
·用于基本SUPL INIT保护的SUPL INIT保护符由以下组成:
·密钥标识符
·BasicReplayCounter（长度=2个八位字节）
·BasicMAC（长度=4个八位字节）
·如下生成BasicMAC参数:
·BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,‘SUPL_INIT’）
·SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“Basic IK”）
·当重置密钥标识符时，重置BasicReplayCounter
SUPL_INIT_ROOT_KEY管理
·出现在任何SUPL会话的首次ULP交换中
·SET首次发起的消息
·会话的首条消息应该包括
-如果没有可用的认证，“SUPL_INIT_Credential_Req”指示符，或者
-Current_Key_Identifier以便允许SLP检测SET和SLP是否不同步
·SLP的响应
·如果Current_Key_Identifier是正确的，则添加“SUPL_INIT_Credential_OK”指示符以便进行确认
·如果Current_Key_Identifier是不正确的，或者SET所发送的“SUPL_INIT_Credential_Req”指示符或者SLP希望更新SUPL_INIT认证，则为了提供SUPL_INIT认证，SLP将字段添加到ULP消息
-包含（Key Identifier,SUPL_INIT_ROOT_KEY）
用户模式比较
总结
·在SUPL3.0中考虑了两种新的安全模式
·选项I:用户模式ULP
·选项II:用户模式TLS
·两种新的安全模型使用（用户名，密码）客户端认证，而服务器认证和加密是基于传统服务器授权的TLS的。
·两种选项是不可知承载者的安全模型，并且因此适合SUPL3.0。
·在可应用和所期望之处，仍然可以使用传统安全模型（ACA和GBA）。
SRP基础
·TLS-SRP[IETF RFC5054]使用安全远程密码（SRP[RFC2945]）作为认证和密钥交换的基础
·主要步骤
·服务器进行认证不需要密码，作为替代，它存储包含{用户名,密码验证,趣味}的三连变量
·典型情况下，当与服务器离线注册时，用户的客户生成三连变量
·趣味可以由用户随机选择。
·使用类似于Diffie-Hellman密钥交换的微妙数学从用户名、趣味和用户的密码中计算密码验证。
·服务器在与用户的交互作用中使用三连变量，以便
·验证用户知道密码，并且
·建立仅用户和服务器知道的共享秘密。随后，可以使用该共享秘密生成用于加密和完整性保护（这是它在TLS-SRP中如何使用的）的密钥
SRP的一些属性
·不可以使用三连变量模仿用户
·服务器不需要保持三连变量是秘密的
·服务器可以将三连变量提供给第三方，以便允许第三方验证用户，服务器不关心第三方随后将尝试模仿用户
–例如，H-SLP可以将三连变量提供给A-SLP，以便允许A-SLP对用户进行认证
附加实施例4
介绍
·SUPL2.0中的安全是接入网络专用的：
·ACA需要接入核心网络以便基于源IP地址对SET进行识别
·GBA仅可应用于3GPP/3GPP2网络
·SEK仅可应用于WiMAX网络
·SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：
·同时支持GBA和“用户名/密码”认证的简单框架
SUPL3.0安全概念综述I
SUPL3.0安全概念综述II
为SUPL3.0安全考虑下列两种选项:
选项I 选项II
ACA（A） ACA（A）
GBA（B） GBA（B）
用户模式ULP（C） 用户模式TLS（D）
下列讨论提供了两种选项，并且讨论了每种方法的优点和潜在缺点。
用户模式离线过程
·用户模式（离线）
·用户和SLP运营商就（用户名，密码）取得一致
·其它假设
·SET具有SLP的URL
·SET具有用于对SLP进行认证的合适的根认证
用户模式ULP:概念综述I
·用户模式ULP:基于（用户名，密码）
·首先与服务器证书进行TLS握手，以便建立安全连接
·将（Username,Counter,Digest）添加到通过SET发送的所有ULP消息，将Digest计算为
–ULP_Message_Z是具有Digest字段设置为零的ULP_Message
–User_ULP_IK=SHA-256（Username||“:”||Password||“:”||SLP_Domain||“:SUPL30ULP”）
–Digest=HMAC-SHA-256-32（User_ULP_IK,ULP_Message_Z）
·SET将（Username,Counter,Digest）添加到所有消息，SLP验证
用户模式ULP:概念综述II
·具有用于服务器认证和加密的服务器证书的TLS
·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）
·SLP在对ULP消息内容进行处理之前验证计数器和摘要
·计数器的目的是能够进行重放检测
·每次ULP会话重置接收器和发送器中的计数器
·在发送器处，计数器每条消息增加1并且将其添加到ULP消息
·在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。
用户模式TLS:概念综述
·用户模式ULP:基于（用户名，密码）
·首先与服务器证书进行TLS握手，以便建立安全连接
·SLP发送“问候请求”以便发起TLS重新协商。随后，SET和SLP进行TLS-SRP握手（SRP=安全远程密码），以便使用（用户名，密码）对用户进行认证。
·需要第一个安全连接，以便在TLS-SRP握手中隐藏用户名。
选项I:在线过程综述
·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式
·SLP确定是以GBA模式还是用户模式继续进行
·如果GBA模式，则
·对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道
–提供相互认证
·在安全通道中交换数据
·如果用户模式，则
·继续与服务器证书的TLS握手，以便建立安全通道
–SET对SLP进行认证
·在安全通道内部交换数据
–将新的参数添加到来自SET的ULP消息（Username,Counter,Digest），其允许SLP对用户进行认证
选项I:在线过程细节-TLS握手
·SET→SLP:客户问候:
·指示所有支持的密码组
–如果SET支持GBA，就指示支持TLS-PSK密码组
–如果SET支持用户模式，就指示支持采用服务器证书的TLS
·SLP→SET:服务器问候:
·指示所选择的密码组
–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组
–如果SLP选择用户模式，SLP就指示采用服务器证书的TLS
·对于所选择的密码组，呼叫流继续
选项I:在线过程细节–在TLS握手之后
·GBA模式
·SET和SLP在安全信道上开始通信
·用户模式
·SET和SLP在安全信道上开始通信
·将新的参数添加到来自SET的ULP消息:（Username,Counter,Digest）
–SLP在对ULP消息内容进行处理之前验证计数器和摘要
–计数器的目的是能够进行重放检测
–每次ULP会话重置接收器和发送器中的计数器
–在发送器处，计数器每条消息增加1并且将其添加到ULP消息
–在接收器处，将计数器与预期值进行比较。如果检测到重放，以错误退出。否则，消息通过重放保护。
选项II:在线过程综述
·SET发起TLS握手，通过选择合适的密码组在TLS中指示支持GBA和/或用户模式。
·SLP确定是以GBA模式还是用户模式继续进行
·如果GBA模式，则
1.对于使用GBA的TLS-PSK，继续TLS握手，以便建立安全通道
–相互认证
2.在安全通道中交换数据
·如果用户模式，则
1.首先继续与服务器证书TLS握手，以便建立安全通道
–SET对SLP进行认证
2.进行TLS-SRP握手（在安全通道内部交换消息）
–SLP对用户进行认证
–得到新的会话密钥
3.受新的会话密钥保护在安全通道中交换数据
选项II:在线过程细节-首次TLS握手
·SET→SLP:客户问候:
·指示所有支持的密码组
–如果SET支持GBA，就指示支持TLS-PSK密码组
–如果SET支持用户模式，就指示支持采用服务器证书的TLS和TLS SRP
·SET此时不提供用户名，如果需要，将在下一次TLS握手中提供
·SLP→SET:服务器问候:
·指示所选择的密码组
–如果SLP选择GBA模式，SLP就指示TLS-PSK密码组
–如果SLP选择用户模式，SLP就指示用于采用服务器证书的TLS的密码组
–对于所选择的密码组，呼叫流继续
选项II:在线过程细节-在首次TLS握手之后
·GBA模式
·SET和SLP在安全信道上开始通信
·用户模式
·SLP→SET:问候请求
–发起重新协商
·SET→SLP:客户问候
–指示支持TLS-SRP
–包括用户名作为每个TLS-SRP规范
·SET→SLP:服务器问候
–指示TLS-SRP的选择
·每个TLS-SRP继续交换
·在成功握手之后，SET和SLP开始在安全信道上交换数据。
SUPL INIT保护
·SUPL3.0中的SUPL INIT保护基于SUPL2.0中的SUPL INIT保护机制，并且使用附加到SUPL INIT的消息认证码（MAC）
·用于认证的两种方法:
○ GBA模式:（Key Identity,SUPL_INIT_ROOT_KEY）=（B-TID,Ks）
■（B-TID,Ks）是BSF的引导关
○用户模式:使用（用户名，密码）进行认证
·SUPL INIT保护对于选项I和选项II是相同的
SUPL INIT保护机制
·在SUPL v3.0中提供的三种保护类型:
·无
–无安全
·GBA模式保护
–与SUPL v2.0基本保护相同
·用户模式保护
–基于（用户名，密码）进行认证
–添加随机值以防止字典攻击
–添加时间以防止重放
SUPL INIT GBA模式保护
·如果使用GBA认证，则SUPL INIT保护符参数由以下组成：
·密钥标识符=GBA B-TID（长度=变量）
·GBA_ReplayCounter（长度=2个八位字节）。防止重放
·SUPL_INIT_GBA_MAC（长度=4个八位字节）。对消息进行认证。
·如下生成SUPL_INIT_GBA_MAC参数:
·SUPL_INIT_GBA_MAC=HMAC-SHA256-32（SUPL_INIT_GBA_IK,SUPL_INIT_Z）
·SUPL_INIT_GBA_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“GBA IK”）
·SUPL_INIT_ROOT_KEY是对应于B-TID的GBA密钥Ks_（int/ext_）NAF
·SUPL_INIT_Z是具有将SUPL_INIT_GBA_MAC字段设置为全零的SUPL INIT消息
·当重置密钥标识符时重置GBA_ReplayCounter
SUPL INIT用户模式保护
·如果使用用户模式安全，则SUPL INIT保护符参数由以下组成：
·SUPL_INIT_RAND（长度=8个八位字节）。这可以是对该消息唯一的随机值以防止在密码上的字典攻击。
·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。.
·SUPL_INIT_USER_MAC（长度=4个八位字节）。对消息进行认证。.
·如下生成SUPL_INIT_USER_MAC参数:
·SUPL_INIT_USER_MAC=HMAC-SHA256-32（SUPL_INIT_USER_IK,SUPL_INIT_Z）
·SUPL_INIT_USER_IK=SHA-256（Username||“:”||Password“:”||SLP_Domain||“:SUPL30INIT”）
·SUPL_INIT_Z是具有将SUPL_INIT_USER_MAC字段设置为全零的SUPL INIT消息。
用户模式比较
总结
·在SUPL3.0中考虑了两种新的安全模型
·选项I:用户模式ULP
·选项II:用户模式TLS
·两种新的安全模型使用（用户名，密码）客户端认证，而服务器认证和加密是基于传统服务器授权的TLS的。
·两种选项是不可知承载者的安全模型，并且因此适合SUPL3.0。
·在可应用和所期望之处，仍然可以使用传统安全模型（ACA和GBA）。
附加实施例5
介绍
·OMA SUPL2.0中的安全是接入网络专用的：
·ACA（可替换客户端认证）需要接入核心网络以便基于源IP地址对SET进行识别
·GBA（通用引导架构）仅可应用于3GPP/3GPP2网络
·SEK（SUPL加密密钥）仅可应用于WiMAX网络
·OMA SUPL3.0中新的需求需要可应用于所有接入网络的认证机制。该实施例描述了可应用于所有接入网络的新的安全机制：
·基于“用户名/密码”认证的简单框架
·还支持传统的ACA和基于GBA的安全
SUPL3.0安全概念综述I
用于SUPL3.0的安全基于三种安全方法：
SUPL3.0安全概念综述II
·ACA和GBA是接入网络专用的，但是可以在可应用之处并且取决于SUPL运营商的选择使用。
·用户模式TLS是独立于接入网络的，并且可以将其视为ACA的增强。
用户模式TLS–综述I
·公钥TLS服务器认证–安全连接H-SLP和SLP；对H-SLP进行认证但是不对SET进行认证。
·用户名/密码TLS-SRP客户端认证-安全连接H-SLP和SLP；对H-SLP和SET都进行认证
·用户模式TLS
·当在ACA中产生安全加密IP连接时，使用公钥TLS首先对服务器进行认证
·随后，在SET和SLP中使用预提供的用户名/密码基于TLS-SRP（安全远程密码）对客户进行认证
用户模式TLS综述II
·简单的用户名/密码机制可能造成问题和/或威胁：
·用户名/密码可能被盗并且在不同的设备上使用
·用户名/密码可能自动泄露并且同时在不同设备上使用
·这可以通过以下办法解决：
·仅为紧随SUPL服务激活之后的第一个SUPL会话使用用户名/密码。
·在第一个SUPL会话期间，SLP创建新的用户名/密码，并且发送到SET（使用通过初始用户名/密码创建的安全IP连接）。
·SET随后用新的用户名/密码代替初始用户名/密码，并且删除旧的用户名/密码。
·随后，通过由SLP创建的用户不可见的用户名/密码将设备绑定到SUPL订阅。
·则，所有将来的TLS会话使用由SLP创建的新的用户名/密码。
·则，其它设备不能使用该用户名/密码
在4个步骤中的用户模式TLS
·步骤1:用户和SLP运营商就临时用户名和密码取得一致：（用户名_临时,密码_临时）。
·步骤2:建立第一个SUPL会话。基于服务器授权的TLS执行服务器认证和计算。使用已经过协议的（用户名_临时,密码_临时）基于TLS-SRP（SRP=安全远程密码）执行客户端认证。
·步骤3:在第一个SUPL会话内，SLP生成新的并且加密性强的（用户名，密码），将其发送到SET。SET以（用户名，密码）代替（用户名_临时,密码_临时）。SET将（用户名，密码）存储在安全位置。
·步骤4:所有后续的TLS会话基于服务器授权的TLS使用服务器认证和计算。使用（用户名，密码）基于TLS-SRP执行客户端认证。
用户模式TLS步骤1–细节
·用户和SLP运营商就临时用户名和密码取得一致：（用户名_临时,密码_临时）
·可以以各种方式在SET中提供（用户名_临时,密码_临时）：
·在空中通过运营商提供
·在运营商的商店提供（SET的闪存）
·通过邮件发送或者在线获得并且通过SET用户输入的用户名和密码
·其它
·给SLP提供了SLP的URL
·给SLP提供了对SLP进行授权所需的合适的根认证
用户模式TLS步骤2–细节
·第一个SUPL会话的首次TLS握手，以便发起服务器认证和加密：
·SET→SLP:指示支持具有服务器证书的TLS和TLS-SRP的客户问候
·SLP→SET:指示用于具有服务器证书的密码组的服务器问候
·第二次TLS握手，以便发起客户端认证
·SLP→SET:问候请求，以便发起重新协商
·SET→SLP:指示支持TLS-SRP并且包括每TLS-SRP规范的用户名_临时的客户问候
·SLP→SET:指示TLS-SRP选择的服务器问候
·基于（用户名_临时,密码_临时）执行客户端认证
·生成新的会话密钥（仅用于该会话）
·SET和SLP现在可以在安全信道上进行SUPL会话
用户模式TLS步骤3–细节
·SLP基于临时用户名和密码（用户名_临时,密码_临时）创建加密性强的（用户名,密码）。
·从SLP到SET的第一条SUPL消息携带加密性强的（用户名,密码）。
·SET以（用户名,密码）代替临时（用户名_临时,密码_临时）。
·SET丢弃（用户名_临时,密码_临时）。
·SET将（用户名,密码）存储在安全位置中。
·注释1:如果SLP运营商能够在不包括用户的SET中安全地提供用户名/密码，可以不执行该步骤
·注释2:对于3GPP/3GPP2初始接入，SLP可以在核心网中验证SET IP地址与SETMSISDN或者IMSI相关联，以便进一步验证SET属于用户
用户模式TLS步骤4–细节
·对于后续的TLS会话建立:
·TLS握手，以便发起服务器认证和加密:
–SET→SLP:指示支持具有服务器证书的TLS和TLS-SRP的客户问候
–SLP→SET:指示用于具有服务器证书的密码组的服务器问候
·第二次TLS握手，以便发起客户端认证:
–SLP→SET:问候请求，以便发起重新协商
–SET→SLP:指示支持TLS-SRP并且包括每TLS-SRP规范的用户名的客户问候
–SLP→SET:指示TLS-SRP选择的服务器问候
–基于（用户名,密码）执行客户端认证
–生成新的会话密钥
·SET和SLP现在可以在安全信道上进行SUPL会话
·注释:虽然一旦提供了加密的安全用户名/密码PSK-TLS可以用于后续接入，但是可以以减小的复杂度实现TLS-SRP的重用
SUPL INIT保护综述
·SUPL3.0中的SUPL INIT保护基于SUPL2.0中的SUPL INIT保护机制，并且使用附加到SUPL INIT的消息认证码（MAC）
·在SUPL v3.0中所提出的两种保护类型:
·GBA模式保护
–与SUPL v2.0基本保护相同
·User模式保护
–基于由SLP创建的（用户名，密码）的认证（即，不使用用于服务激活的初始用户名/密码（用户名_临时，密码_临时））。
·也支持空保护并且可以基于运营商的选择使用。
SUPL INIT用户模式保护I
·如果使用用户模式TLS安全，则SUPL INIT保护符参数由以下组成：
·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。
·SUPL_INIT_USER_MAC（长度=4个八位字节）。对消息进行认证。
·将SUPL INIT保护符添加到每条SUPL INIT消息，并且允许SET检查所接收的SUPL INIT消息的确实性。
·对于运营商使用SUPL INIT保护的例外情况（例如，SET和SLP不同步），只要明确地给SET指示（例如，经由重置命令），可以使用空SUPL INIT保护临时重新提供SET，使得服务攻击拒绝不能利用此过将无保护的SUPL INIT发送给大量SET。
SUPL INIT用户模式保护II
·如下生成SUPL_INIT_USER_MAC参数:
·SUPL_INIT_USER_MAC=HMAC-SHA256-32（SUPL_INIT_USER_IK,SUPL_INIT_Z）
·SUPL_INIT_USER_IK=SHA-256（Username||“:”||Password“:”||SLP_Domain||“:SUPL30INIT”）
·SUPL_INIT_Z是具有SUPL_INIT_USER_MAC字段设置为全零的SUPL INIT消息
总结
·为SUPL3.0描述了新的安全模型:用户模型TLS。
·用户模式TLS使用（用户名，密码）客户端认证，而服务器认证和加密基于传统服务器授权的TLS。
·在用户模式TLS中也支持SUPL INIT保护。
·用户模式TLS是不可知承载者的安全模型，并且因此适合SUPL3.0。
·取决于SUPL运营商的选择，仍然可以使用传统安全模型（ACA和GBA）。
推荐
·可以采用用户模式TLS作为用于SUPL3.0的安全模型
·可以维持对传统ACA和GBA安全模型的支持
SUPL3.0接入SLP（A-SLP）
·对于漫游用户，支持精确定位对于H-SLP提供商可能是困难的，但是对于本地漫游区域中的定位提供商容易得多
·在一些情况下，运营商与其它运营商和提供商可以具有商业关系，其可能临时使用属于运营商A的H-SLP使运营商B的用户受益
·SUPL3.0RD包括面向更广泛可用性和更容易接入SLP的需求:
·SUPL-EMER-03:SUPL应该支持用于紧急定位请求的SET发起的和网络发起的定位
·SUPL-HLF-18:SUPL应该支持SLP服务发现
·一些用户可能不具有H-SLP–例如，本地运营商不支持SUPL–或者不选择H-SLPSUPL支持
·一些运营商可能希望给漫游用户扩展SUPL支持–例如，那行没有H-SLP的运营商或者其H-SLP在特定漫游区域中不能充分支持定位的运营商
接入SLP（A-SLP）
·A-SLP可以属于接入网络提供商、可以与接入网络相关联、或者支持接入网络的地理区域
·A-SLP可以以与H-SLP几乎相同的方式支持SUPL3.0–例如，包括所有网络和SET发起的服务
·SET将需要发现或者给SET提供关于A-SLP的信息（例如，A-SLP地址和安全参数）
·可能的信息源是接入网络、H-SLP以及独立（非标准）发现
·A-SLP安全应该重新使用为H-SLP定义的方法–例如，避免不同的认证方法
·SET和A-SLP可以相互作用有限的预协议时间周期，以便为外部SUPL代理和SET支持SUPL3.0服务
可能的A-SLP使用
·SET使用ULP3.0消息经由接入网络与SLP进行通信，并且使用ULP3.0消息经由本地网络（可选地，用于发现和验证A-SLP）与H-SLP进行通信。
·A-SLP经由MLP与SUPL代理进行通信。
示例用户案例
·示例1–用户访问新的城市、城镇、游览地等。
·H-SLP可能仅能支持绝对定位，并且不总是精确的（例如，如果在大楼内部），并且可能不能提供诸如感兴趣点、地图、天气/交通信息等的辅助信息。
·A-SLP可以与诸如方向寻找、感兴趣点、地图、天气/交通等的应用级服务（不是SUPL的部分）一起提供更多连续的精确定位支持。
·示例2–紧急呼叫支持
·如果A-SLP还支持E-SLP性能，通过SET发现A-SLP可以辅助稍后基于IP的紧急呼叫
·随后，SET具有从A-SLP获得其近似位置以及将其包括在紧急SIPINVITE中从而辅助呼叫例程的选项
·SET和A-SLP/E-SLP之间之前的联系也可以辅助稍后对PSAP发送更精确的定位
A-SLP安全-1
·关于H-SLP，允许相同的安全过程
·如在OMA-LOC-2010-0xyz-INP_SUPL_3.0_Security中所描述的，合适的安全方法是用户模式TLS–例如，这不需要支持GBA、仅接入3GPP/3GPP2、直接对SET进行配置的能力
·A-SLP运营商或者H-SLP运营商（在两个运营商之间存在商业关系）可以分配初始用户名/密码
·随后，A-SLP可以采用在第一个SUPL会话上的新的值代替初始用户名/密码，以避免其它设备使用该用户名/密码
·虽然A-SLP运营商可能不总是能够验证给SET提供的用户名/密码属于预期用户，但是对于主要集中在SET发起的服务并且以相同费率对所有漫游用户收费的A-SLP服务来说，这可能不要紧
·注释:在大多数情况下，用户可以将接入A-SLP失败报告给A-SLP提供商（例如，如果另一个用户获得并且使用初始用户名/密码），这允许使当前用户名/密码无效并且用新的用户名/密码代替
A-SLP安全-2
·作为选项，可以使用H-SLP发现、验证和帮助支持对于A-SLP的安全
·SET可以将ULP请求发送到H-SLP，其具有这些参数之一：
·（A）当前SET定位或者服务接入网络标识
·（B）已经发现的A-SLP地址（例如，在线发现或者通过接入网络提供）
·对于（A），H-SLP可以返回对本地区域进行服务的信赖A-SLP的地址
·对于（B），H-SLP可以指示A-SLP是可信赖的、不可信赖的、还是对于H-SLP未知的
·对于（A）并且对于（B），在受信赖的情况下，H-SLP可以有选择地给SET提供初始A-SLP或者H-SLP分配的用户名/密码（对于此，随后，将需要在A-SLP和H-SLP或者相关联提供商之间的一些附加相互作用来传送用户名/密码和用户标识）
SUPL3.0AD和TS影响
·定义A-SLP（与现存H-SLP、V-SLP、E-SLP一起）
·定义或者参考合适的发现机制
·指示使用用户模式TLS安全
·为A-SLP发现、验证和安全添加任何合适的H-SLP支持
·允许SET和A-SLP将所支持的服务限制于用于H-SLP相互作用的那些服务的子集（如已经在现存SUPL3.0消息流中所支持的，其中，每个端点告知服务的另一个端点它将支持新的会话）
·识别和支持新的私有需求（如果有）
与H-SLP服务的关系
·H-SLP提供商可以选择支持某个与其存在某些商业关系的A-SLP提供商
·H-SLP提供商还可以给来自其它运营商的漫游用户提供作为A-SLP提供商的支持
·可以对SET进行配置，以便控制A-SLP，如下:
a)总是使用H-SLP并且禁止A-SLP使用
b)最好使用H-SLP但是允许服从H-SLP赞成的A-SLP使用（例如，仅当与H-SLP提供商存在漫游协议时，才允许A-SLP接入）
c)允许SET基于其自身标准自由决定H-SLP与A-SLP的使用，或者
d)总是使用A-SLP（例如，当不存在H-SLP时可应用）
·最终结果可以增加SUPL3.0使用和有益于提供商和用户的相关联部署
·可以将A-SLP支持包括为SUPL3.0的部分
·重新使用H-SLP安全支持并且允许H-SLP辅助或者控制A-SLP接入
·允许某个级别的非SUPL支持（例如，关于A-SLP和H-SLP提供商之间的A-SLP发现和相互作用）
附加实施例6
介绍
该实施例为客户端认证使用设备证书。
SUPL3.0安全概念综述I
SUPL3.0安全概念综述II
·ACA和GBA是接入网络专用的，但是可以在可应用之处并且取决于SUPL运营商的选择使用。
·该实施例新的安全模型是使用设备证书的客户端认证。基于客户端认证的设备证书是独立于接入网络的，并且因此可以用于所有类型的接入网络和设备（即，非3GPP/3GPP2接入网络和所支持的设备）。
设备预提供
·在制造期间，制造商提供到SET内
·对于该SET设备唯一的私钥
·将相应的公钥绑定到一个或多个全球唯一的SET设备标识（例如，序列号、IMEI或MSID）的认证
·返回众所周知的受潜在SLP信赖的认证权威的一个或多个认证链条
·注释:如果不存在返回受SLP信赖的CA的链条，则SLP将不信赖SET认证
·SLP负责确保给SET提供一个或多个可以用于验证SLP的认证的根认证
·可以在SET制造或者销售期间提供这些根认证，
·可以将这些根认证与SUPL客户软件绑定。
·注释:如果不存在从SLP认证返回这些根认证之一的认证链条，则SET将不能对 SLP进行认证
·OMA-LOC可以为认证指定公共模版或者轮廓，以便简化并且统一实现和测试
设备证书总结
·步骤1:用户授权（在范围外）
·用户安全地向SLP验证应该将该设备与他们的订阅相关联
·步骤2:运行时间TLS握手
·首先:使用服务器证书执行服务器授权的TLS握手
·其次:在加密TLS隧道内部，使用服务器证书和客户端认证执行相互授权的TLS握手
·现在可以安全地交换数据
（在范围外）用户认证I
·由于仅对SET标识而不是用户标识进行认证，SLP知道应该将哪个用户与（授权的）SET相关联
·每当用户在SET之间切换时，这发生
·将SET标识提供给SLP对于用户可能是不足的
·原因:用户1可以将用户2的SET ID提供给SLP，并且说“这是我的SET”。随后，SLP可以在用户2没有意识到发生了什么的情况下将用户2位置的细节提供给用户1。
·使用安全方法将用户与SET ID安全地进行相关联
·方法是在范围之外的
·一些***已经具有将设备标识与用户安全相关联的机制（例如，苹果、黑莓）
·下面提供了示例方法
（在范围外）用户认证II
·用于将用户与设备标识安全相关联的示例方法
·SLP运营商提示用户连接到SLP拥有的网站同时使用SET
·用户连接到网站（可能是WAP），同时使用SET
·网页服务器请求采用设备证书和网页服务器证书的TLS握手
·该认证可能与SLP服务车不同
·用户执行一些与网站的认证（在范围外）。例如，网站可能请求SLP专用的用户名/密码、或者联合的用户名/密码或者诸如地址、出生日期等的其它用户细节
·SLP运营商现在已经将用户与设备标识安全地进行相关联，并且应该将该相关联存储在SLP中。
运行时间TLS握手综述
·基于客户端认证的设备证书
·在ACA产生安全加密的IP连接中，首先使用公钥GLS对服务器进行认证
·这通过将设备标识隐藏在设备证书中保持匿名
·接下来，客户和服务器基于服务器证书和设备证书执行相互授权的TLS
运行时间TLS握手细节
·第一个SUPL会话的第一次TLS握手，以便发起服务器授权的安全通道:
·SET→SLP:指示对采用服务器证书和设备证书的TLS支持的客户问候
·SLP→SET:指示用于采用服务器证书的TLS的密码组的服务器问候
·SLP←→SET:完成TLS握手，以便建立安全通道
·第二次TLS握手执行相互认证
·SLP→SET:问候请求，以便发起重新协商
·SET→SLP:指示对采用服务器证书和设备证书的TLS支持的客户问候
·SLP→SET:指示具有服务器证书和设备证书的TLS选择的服务器问候
·SLP←→SET:完成TLS握手，以便建立安全通道
·SET和SLP现在可以在安全通道上进行SUPL会话
认证撤回
·可以撤回设备和服务器证书
·设备和服务器可以使用诸如认证撤回列表（例如，[RFC3280]）或者在线认证状态协议（OCSP）[RFC2560]的方法检查是否撤回了设备证书
·专用方法是阶段3考虑
SUPL INIT保护综述
·SUPL3.0中的SUPL INIT保护是基于SUPL2.0中的SUPL INIT保护机制，并且使用附加到SUPL INIT的消息认证码（MAC）
·该安全是防止拒绝在SLP上的服务攻击
·SUPL v3.0提供了与SUPL v2.0相同的保护:
·模式A保护
–如果使用基于GBA的客户端认证就应用
–与来自SUPL v2.0的基本保护相同
–使用基于GBA的SUPL_INIT_ROOT_KEY
–模式B保护
–SUPL v3.0使用SLP提供的SUPL_INIT_ROOT_KEY添加支持
–支持ACA和设备证书客户端认证
·也支持空保护，并且可以基于运营商的选择使用
·SUPL v3.0为SLP添加了机制提供SUPL_INIT_ROOT_KEY
模式B保护SUPL_INIT_ROOT_KEY
·模式B SUPL_INIT保护需要SLP将SUPL_INIT_ROOT_KEY提供给设备
·SUPL_INIT_ROOT_KEY对设备和用户的这种组合是唯一的
·注意，可以仅为了给SLP提供拒绝服务攻击的保护使用SUPL_INIT_ROOT_KEY
·公钥将不暴露任何用户数据
·公钥仅添加了一个可以包括在拒绝服务攻击中的额外设备
·由于每个SUPL_INIT_ROOT_KEY具有很小的值，所以密钥可能“永久”有效，并且与和订阅相关联的其它细节一起存储
·也就是说，对这些密钥进行保护的专用服务器不是必需的
·注释:如果移除UICC，由于这指示所有权改变，所以SET就删除SUPL_INIT_ROOT_KEY
模式B过程
·模式B开始提供
·用于开始模式B提供的过程
·模式B提供
·SLP将SUPL_INIT_ROOT_KEY提供给SET
·无SUPL_INIT_ROOT_KEY的模式B使用
·如果不提供SUPL_INIT_ROOT_KEY，则SET不验证MAC就接受它从SLP接收的第一条SUPL_INIT消息
·有SUPL_INIT_ROOT_KEY的模式B使用
·一旦提供了SUPL_INIT_ROOT_KEY，则如果验证MAC和时间正确，SET就接受它从SLP接收的SUPL_INIT消息，并且否则，不接受SUPL_INIT消息
·模式B例外–硬重置
模式B开始提供
·开始SUPL_INIT_ROOT_KEY提供，并且在SET和SLP之间的（安全）ULP会话期间出现SUPL_INIT_ROOT_KEY提供
·开始SUPL_INIT_ROOT_KEY提供
·如果在安全ULP会话之初，SET注意到它没有SUPL_INIT_ROOT_KEY，则SET就通过将SUPL_INIT_ROOT_KEY_Request指示符包括在第一条ULP消息中开始SUPL_INIT_ROOT_KEY提供
·注意到，可以将SET配置为如果否则会话不发生，就在一段时间周期上SUPLINIT失败一些次数之后发起SUPL会话（以便请求SUPL_INIT_ROOT_KEY）
·如果SLP怀疑SET中的SUPL_INIT_ROOT_KEY已经被破坏（例如，如果SET不对SUPL_INIT消息作出响应一段时间），则SLP可以在从SET接收到第一条ULP消息之后开始SUPL_INIT_ROOT_KEY提供
模式B提供
·注释:该过程在“模式B开始提供”之后
·如果SLP已经选择不支持模式B保护，则SLP就将合适的指示发送到SET
·否则
·SLP获得SUPL_INIT_ROOT_KEY
·如果SLP具有与SET和用户的这种组合相关联的现存SUPL_INIT_ROOT_KEY，则SLP从其记录中找回该值
·如果SLP不具有与SET和用户的这种组合相关联的现存SUPL_INIT_ROOT_KEY，则SLP生成新的SUPL_INIT_ROOT_KEY
·SLP将SUPL_INIT_ROOT_KEY作为安全ULP消息中的参数发送到SET
·SET存储SUPL_INIT_ROOT_KEY的值
·如果所存储的SUPL_INIT_ROOT_KEY值被破坏，SET可以对所存储的值应用某种允许SET稍后进行检测的保护。这种保护的例子包括纠错和/或完整性检查
不具有SUPL_INIT_ROOT_KEY的模式B使用
·SET可以在可以应用模式B保护的状态中，但它不具有SUPL_INIT_ROOT_KEY。例子包括:
·在上电时，在提供SUPL_INIT_ROOT_KEY之前
·SUPL_INIT_ROOT_KEY被破坏或者被删除
·如果SET在这种状态中，则SET不验证MAC就接受它从SLP接受的第一条SUPL_INIT消息
·SET与SLP建立TLS会话
·SET执行上述模式B开始提供过程，以便请求SUPL_INIT_ROOT_KEY
·如果SLP知道SET在这种状态中，则SLP使用空保护发送SUPL_INIT消息，知道SET无论如何将接受这些消息
·在后续ULP会话中，SET或者SLP可以使用上述模式B开始提供过程，以便开始提供SUPL_INIT_ROOT_KEY
具有SUPL_INIT_ROOT_KEY的模式B使用
·如果SLP认为SET具有SUPL_INIT_ROOT_KEY，则SLP就将SUPL INIT保护符添加到每条SUPL INIT消息–这允许SET检查所接收的SUPL INIT消息的确实性
·如果使用模式B保护，则SUPL INIT保护符参数由以下组成：
·SUPL_INIT_TIME（长度=4个八位字节）。发送消息的时间。停止重放。
·SUPL_INIT_MODE_B_MAC（长度=4个八位字节）.对消息进行认证。
·如果SET具有SUPL_INIT_ROOT_KEY，则只要SUPL_INIT_ROOT_KEY有效，SET就接受消息，并且在SUPL_INIT中提供的SUPL_INIT_MODE_B_MAC与SET所计算的值一致
SUPL_INIT_MODE_B_MAC计算
如下生成SUPL_INIT_MODE_B_MAC参数:
·SUPL_INIT_MODE_B_MAC=HMAC-SHA256-32（SUPL_INIT_ROOT_KEY,SUPL_INIT_Z）
·SUPL_INIT_Z是具有将SUPL_INIT_MODE_B_MAC字段设置为全零的SUPL INIT消息
Mode B例外–硬重置
·对于运营商使用SUPL INIT保护的例外情况（e.g.SET和SLP不同步），只要明确地给SET指出（例如，经由重置命令），可以使用空SUPL INIT保护临时重新提供SET，使得拒绝服务攻击不能利用此将未受保护的SUPL INIT发送给大量SET
·将该重置命令直接输入SET，以防止引入新的威胁
总结
·用于SUPL3.0的新的安全模型:使用设备证书的客户端认证
·在制造商处提供设备证书
·在使用设备证书的客户端认证中也支持SUPL INIT保护
·基于设备证书的客户端认证是不可知承载者的安全模型，并且因此适合SUPL3.0
·取决于SUPL运营商的选择，仍然可以使用传统安全模型（ACA和GBA）
推荐
·使用设备证书的客户端认证作为用于SUPL3.0的安全模型
·维持对传统ACA和GBA安全模型的支持
附加实施例7
除了3GPP、3GPP2和WiMax接入网络，用于SUPL2.0的安全解决方案可能是不可用的（例如，可能不支持WiFi接入），并且为了支持强安全性，用于SUPL2.0的安全解决方案包括GBA实现。另外，代替或者除了本地运营商SLP（H-SLP）之外，安全性解决方案可能不允许支持接入相关联的SLP（A-SLP）。
该实施例利用通过SLP提供商分配给用户或者用户的支持SUPL的终端（SET）的用户名和密码，以便使用TLS-SRP支持客户（SET）认证。SUPLSET和SLP可以使用公钥TLS，以便允许SET对SLP进行认证。这可以产生安全TLS/IP连接，在其上发生通过SLP使用TLS-SRP（以及预先协议过的用户名和密码）的第二次认证。这可以修改初始安全IP/TLS连接，随后使用其支持安全的SUPL会话。随后，SLP可以使用该SUPL会话给SET提供新的用户名和密码，以便代替最初分配的用户名和密码。新的用户名和密码对于用户可以是不可见的，这可以防止用户在多于一台设备中使用该用户名和密码，并且可以防止用户将初始用户名密码意外传递给其他用户。解决方法可以用于H-SLP和A-SLP，并且不必需仅使用3GPP、3GPP2或者WiMax接入网络。
因此，所描述的实施例可以将SUPL安全支持扩展到所有IP接入网络，可以提供比当前所部署的不必须支持GBA的解决方法更强的安全性，并且可以支持H-SLP和A-SLP（章节号可以指SUPL3.0章节号）。
6.安全考虑
该章节描述了使得SUPL网络能够对SET进行认证和授权并且使得SET能够对SUPL网络进行认证和授权的SUPL安全功能。
注释:除非另有说明，使用缩写词TLS是指可以使用TLS握手协商的任何会话:这包括TLS1.1密码组和TLS-PSK密码组。
注释:在该章节中，应用下列定义。3GPP承载网络是用于由3GPP所维持的标准的一个网络；这些网络包括GSM、GPRS、EDGE、WCDAM、TD-SCDMA、LTE和LTE-A承载网络。3GPP2承载网络是用于由3GPP2所维持的标准的一个网络；这些网络包括cdmaone、cdma20001x和cdma2000EV-DO承载网络。3GPP SET（分别是3GPP2SET）是其本地网络运营商主要经由3GPP承载网络（分别是3GPP2承载网络）支持数据接入的SET。WiMAX SET是其本地网络运营商主要经由WiMAX承载网络支持数据接 入的SET。在不明确的情况下（例如，支持多种接入类型的运营商），运营商可以决定SET的类型。
注释:H-SLP运营商应该注意到在这里所描述的认证方法对于在属于相同运营商的接入网络之间的或者SET IP地址不改变的SET切换保持有效。过程不考虑SET从一个接入网络移动到属于不同运营商的另一个接入网络裸着IP地址改变的情景。在这些情景中，假设在切换到另一个接入***之后，终端和网络中的安全内容可能不可用，并且网络和终端之间的信任级别可能改变。
一上电和关闭，检测到新的UICC或者移除UICC，SET手持设备就必须删除SET手持设备上与SUPL3.0相关联的任何密钥（除长期密钥以外），包括
■GBA密钥:诸如Ks、Ks_NAF、Ks_ext_NAF
■WIMAX密钥:诸如SEK
■TLS密钥:诸如pre_master_secret、master_secret和PSK值（除长期密钥以外）.
■SUPL专用密钥:诸如与SUPL INIT消息保护相关联的密钥
6.1SUPL认证方法
对SUPL3.0的认证支持需求如下:
·可以支持SET和H-SLP之间的相互认证
·可以支持SET和D-SLP之间的相互认证
·可以支持SET和E-SLP之间的服务器认证，并且可以支持SET和E-SLP之间的相互认证
SUPL3.0支持两种类型的SET认证方法
·取决于AN的方法，其中，将认证绑定到SET用户的接入网络订阅
·独立于AN的方法，其中，将认证绑定到SET，但是不直接绑定到SET用户的接入网络订阅。可以使用在范围外的过程实现将该认证绑定到SET用户的接入网络订阅。对于在范围外过程的更多讨论，见章节6.6。
当执行相互认证时，SET可以经由包含在SET中的SUPL代理起代表SET用户的作用。
·对于取决于AN的方法，SET使用与SET用户相关联的安全证书
·对于独立于AN的方法，SET使用与SET用户相关联的安全证书
注意到，SET用户的成功认证必然导致对SET用户ID（例如，MSISDN、WIMAX用户ID或者独立于AN的用户标识）的成功识别。
注意到，当MSISDN用于识别时，SLP在对授权SET用户的MSISDN进行安全识别之前必须执行IMSI到MSISDN的绑定。
可以在章节6.1.2中找到密钥管理的细节。
6.1.1认证方法
章节6.1.1.1列出了在本说明书中支持的认证方法。在章节6.1.1.2中提供了这些方法的提供信息的概述。章节6.1.1.3描述了在各种SUPL3.0实体中哪种方法是强制的或者可选择的，并且如果实体支持给定的相互认证方法，列出了每种实体中所需的协议。
6.1.1.1所支持的相互认证方法列表
SUPL认证模型需要在SLP和SET之间建立共享密钥；绑定到诸如R-UIM/UICC/SIM/USIM的可移除令牌或者SET手持设备。
在该文档中指定了两种类型的认证方法:
·基于PSK的方法，由下列方法组成:
○取决于AN的基于通用引导架构（GBA）的方法，提供相互认证；
○取决于AN的基于SEK的方法（仅可应用于WIMAX SLP），提供相互认证；
·基于认证的方法，由下列方法组成:
○独立于AN的基于设备证书（DCert）的方法，提供相互认证；
○取决于AN的基于可选客户端认证（ACA）的方法，提供相互认证；
○独立于AN的仅SLP的方法（仅可应用于紧急情况），仅提供了SLP认证。
6.1.1.2所支持的认证方法综述（提供信息的）
1.基于通用引导架构（GBA）具有通用引导架构（GBA）的TLS-PSK GBA提供了基于使用现存3GPP/3GPP2认证机制得到的共享密钥的相互认证性能。
·使用具有通用引导架构（GBA）的TLS-PSK对SET和SLP进行相互认证。
2.基于SEK（仅可应用于WIMAX SLP）
·使用具有SEK的TLS-PSK对SET和SLP进行相互认证。可以在章节6.1.2.1.2中找到SEK方法的细节。
3.基于设备证书（DCert）该独立于AN的方法使用具有如下认证的TLS
·RSA服务器证书，以便将SLP授权给SET
·RSA客户端认证，以便将SET授权给SLP
4.基于可选客户端认证（ACA）这使用具有如下认证的TLS
·RSA认证，以便将SLP授权给SET
·可选的SET到SLP的客户端认证（见章节6.1.4）。在该情况下，SLP通过使承载网络确认与SET标识符（MSISDN等）相关联的IP地址对SET进行认证。
5.仅SLP这在SLP不可能对SET进行认证的情景中使用。该方法不可以用于非紧急情况。SET不能对该方法和基于ACA的方法作出区分。这使用具有下列认证的TLS
·RSA认证，以便将SLP授权给SET
·不对SET进行认证
6.1.1.3通过实体支持相互认证方法和协议
下面的4个表描述了在各种类型的SET以及支持那些SET的SLP中哪些是为了支持SUPL3.0可选和强制的:
·第一个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法
○3GPP/3GPP2SET
○ SET（R-）UIM/SIM/USIM和
○支持3GPP/3GPP2SET的SLP
·第二个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法
○ WiMAX SET和
○支持那些WiMAX SET的SLP
·第三个表指示为了SUPL3.0在下列SET中实现强制的那些方法和可选的那些方法
○不支持3GPP/3GPP2或者WiMAX的SET和
○支持那些SET的SLP
·第四个表列出了对于SLP、SET手持设备和（可应用之处）SET（R-）UIM/SIM/USIM为了支持各种认证方法中的每种所需的协议。
用于3GPP/3GPP2SET和支持这些SET的SLP的各种认证方法的需求状态（强制或者可选）
注释1:对于紧急情况，可能需要SET手持设备支持仅SLP的方法。
注释2:用于基于ACA方法的SET过程（仅对于3GPP和3GPP2）与用于仅SLP方法的SET过程是相同的。因此，响应于紧急情况需要仅SLP方法的结果，3GPP/3GPP2SET手持设备支持基于ACA的方法。
用于WiMAX SET和支持这些WiMAX SET的SLP的各种认证方法的需求状态（强制或者可选）
用于不支持3GPP、3GPP2或者WiMAX SET和支持这些SET的SLP的各种认证方法的需求状态（强制或者可选）
用于支持各种相互认证方法的SLP、SET手持设备和SET R-UIM/UICC/SIM/USIM所需的协议
在支持基于GBA的方法之处，BSF存储与H-SLP应用相关联的用户安全设置（USS）。当H-SLP请求USS时，BSF必须将SET用户标识（例如，IMPI、IMSI或者MSISDN）包括在USS中。
注释:基于GBA的方法不取决于使用3GPP或者3GPP2承载网络传送SUPL会话。然而，为了具有用于执行GBA的必要认证，SET必须具有3GPP或者3GPP2本地网络运营商。
6.1.1.4用于最小化TLS握手工作量的技术
在该章节中的过程最小化与在SLP和SET之间建立TLS会话相关联的工作量。在与TLS存在冲突之处，TLS获得优先。
如果SET和SLP正在同时传送与多于一个SUPL会话相关联的SUPL消息，则SET和SLP应该使用单独一个TLS会话以保护这些消息；也就是说，如果SUPL会话是同时的，SET和SLP不应该建立不同的TLS会话。
如果SET和SLP建立TLS会话，则SLP可以允许使用简短握手重发起会话。重发起TLS会话的优点是基于服务器证书重发起TLS会话不需要公共密钥操作:仅需要对称密码组算法（其明显需要更少处理）。
注释:对于E-SLP，由于紧急SUPL会话出现太频繁，所以不推荐该方法，以保证存储必要的数据。
注释:SLP允许通过分配TLS会话ID重发起会话。
注释:由于执行相同的计算，所以重发起TLS-PSK会话不存在优点（如用于基于GBA和SEK的认证）。然而，SLP仍然可以允许重发起TLS-PSK会话。
注释:SET通过在TLS握手的客户问候消息中的TLS会话ID参数中包括（将要重发起的TLS会话的）TLS会话ID指示重发起TLS会话的选择。如果SET不希望重发起TLS会话，则SET发送不包括TLS会话ID的TLS客户问候消息，在该情况下，将执行完整握手。如果在TLS客户问候消息中呈现TLS会话ID参数，则SLP就选择是否重发起TLS会话。如果在TLS客户问候消息中没有呈现会话ID参数，则SLP就不可以将TLS握手与之前的TLS会话相关联，因此TLS握手使用完整握手建立新的完整的TLS会话。
SET使用下列指导方针选择是否重发起TLS会话。
■如果潜在认证（Ks（_ext）_NAF或者SLP认证或者SEK或设备证书）过期，SET不必重发起TLS会话。
■如果期望，SET可以选择在潜在认证过期之前不重发起TLS会话。
■SET不必重发起在上电或者检测到新的R-UIM/UICC/SIM/USIM之前建立的会话。
SLP使用下列指导方针选择是否重发起TLS会话。
■如果潜在认证（Ks（_ext）_NAF或者SLP认证或者SEK或设备证书）过期，SET不必重发起TLS会话。
■如果期望，SET可以选择在潜在认证过期之前不重发起TLS会话。
注释:每个SLP必须为其自身确定是否允许简短的握手，并且甚至可以在逐个SET的基础上作出该决定。当SLP接受重发起现存的TLS会话时，它冒很小的风险。该风险是“淘气的”SET分发master_secret（在完整的TLS会话期间所建立的）、使得其它SET可以重发起该TLS会话，因此允许多个SET获得将对单个SET收费的服务的可能性。“淘气的”SET可能在不知道SET所有者的情况下（例如，恶意代码可能在错误处）这样做。注意到，可以很容易限制丢失:如果SLP检测到（或者怀疑）出现这种滥用，则SLP可以很容易（a）使用该master_secret结束TLS会话，（b）识别出“淘气的”SET并且（c）使用完整握手对“淘气的”SET进行重新认证，以便如果需要允许用户继续拥有服务。总之，对于DCert方法、基于ACA的方法和仅SLP的方法，认为重发起会话的益处（在减少计算方面）超过了攻击的风险。
6.1.2用于SUPL认证的密钥管理
SUPL认证模型需要在SLP和SET之间建立共享秘密密钥，绑定到诸如R-UIM/UICC/SIM/USIM的可移除令牌或者SET手持设备。
6.1.2.1基于PSK的方法
6.1.2.1.1支持GBA方法的部署
在支持GBA的部署的情况下，如下建立共享密钥:
·当SLP从BSF请求密钥材料（为了使IP通信安全并且为了保护SUPL INIT）时，SLP也必须请求USS（用户安全设置）。USS必须包括永久用户标识（例如，IMPI、IMSI或者MSISDN）。
·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且使用GBA根据TLS-PSK工作。SLP必须具有良好定义的指定SLP的域名SLP_Address_FQDN，例如，slp.operator.com。在OMNA注册中定义了可以用于TLS-PSK的GBA Ua安全协议标识符。SLP必须确认BSF所提供的永久用户标识符对应于在相应的安全连接上由SLP所接收的SUPL消息中的SET标识。
·对于SUPL INIT的MAC保护，根据GBA得到密钥。在OMNA注册中定义了可以用于SUPL INIT保护的GBA Ua安全协议标识符。包括在SUPL INIT消息中的basicMAC的密钥标识符必须是从其生成Ks_NAF的Ks的B-TID。注释:典型地，从BSF对SUPL INIT保护密钥的H/D-SLP请求将与对使IP通信安全的密钥的H/D-SLP请求同时出现。
·SET必须确保总是给它提供了有效的Ks。如果不存在有效的Ks，则SET必须开始GBA引导程序过程以便提供Ks。每次SET检测到新的UICC（USIM/SIM/R-UIM）时，必须建立新的Ks。另外，当Ks_NAF的有效期（由本地网络运营商设置）过期时，SET必须建立新的共享密钥。
6.1.2.1.2支持SEK方法的部署
在支持SEK的部署的情况下，如下建立共享密钥:
·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且确认由WiMAX AAA服务器提供的永久用户标识对应 于SLP在相应的安全连接上所接收的SUPL消息中的SET标识。以下列方式得到共享密钥:
○ SEK=HMAC-SHA256（LSK,“slp.operator.com”）的16个最重要的（最左边的）八位字节，其中，‘operator.com’是WIMAX运营商的FQDN，并且如在WiMAX网络协议和用于基于定位服务的体系结构中所指定的那样得到LSK。
○ SEK将继承与LSK相关联的定位密钥标识符（LSK-ID）（如在WiMAX网络协议和用于基于定位服务的体系结构中所定义的），并且对于WiMAX部署，将使用密钥标识作为B-TID。
·对于SUPL INIT的MAC完整性保护，以下列方式得到密钥:
○ SEK_MAC=HMAC-SHA256（LSK,“mac.slp.operator.com”）的16个最重要的（最左边的）八位字节，其中，‘operator.com’是SLP运营商的FQDN，并且如在WiMAX网络协议和用于基于定位服务的体系结构中所指定的那样得到LSK。
○包括在SUPL INIT消息中的模式AMAC的密钥标识符必须是从其生成SEK_MAC的LSK的B-TID。注释:典型地，来自WiMAX AAA的对SUPL INIT保护密钥的SLP请求将与对使IP通信安全的密钥的SLP请求同时出现。
SET必须确保总是给它提供了有效的SEK。如果不存在有效的SEK，则SEK必须如上所指定的那样得到SEK。另外，当LSK的有效期过期时，SEK必须建立新的共享密钥。SLP和WiMAX AAA服务器之间的接口在SUPL3.0的范围外。
6.1.2.2基于服务器证书的方法
6.1.2.2.1支持Dcert方法的部署
在支持DCert方法的部署的情况下，如下建立共享密钥:
·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书和对SET进行认证的客户端认证的TLS-RSA。客户端认证可以提供全球唯一的SET设备标识:
○3GPP SET可以使用IMEI作为全球唯一的SET设备标识。
○3GPP2SET可以使用MSID作为全球唯一的SET设备标识。
○ WiMAX SET可以使用SET序列号作为全球唯一的SET设备标识。
○所有其它SET可以使用合适的全球标识符（例如，包括卖主标识的序列号）作为全球唯一的SET设备标识。
·SUPL用户必须安全地向SLP验证该设备应该与他们的订阅相关联。该安全验证在本说明书的范围外。关于该主题的更多讨论，见章节6.5。
·对于SUPL INIT的MAC完整性保护，由SLP在ULP消息中将密钥提供给SET。这在章节6.3.5中进行了描述。
6.1.2.2.2支持ACA方法的部署
在支持ACA方法的部署的情况下，如下建立共享密钥:
·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书的TLS-RSA。在章节6.1.4中描述了用于非紧急情况的SET认证并且在章节6.2.5中描述了用于紧急情况的SET认证（其将所得到的共享秘密密钥绑定到）上面所讨论的可移除或者集成令牌）。
·对于SUPL INIT的MAC完整性保护，由SLP在ULP消息中将密钥提供给SET。这在章节6.3.5中进行了描述。
6.1.2.2.3支持仅SLP方法的部署
在支持仅SLP方法的部署的情况下，如下建立共享密钥:
·为了使SET和SLP之间的IP通信安全，SET和SLP必须使用具有对SLP进行认证的服务器证书的TLS-RSA。如在章节6.1.4中对于非紧 急情况并且在章节6.2.5中对于紧急情况所描述的，不存在SET认证（其将所得到的共享秘密密钥绑定到R-UIM/UICC/SIM/USIM或者SET手持设备）。
·在这些情况下不支持SUPL INIT的MAC保护。
6.1.3相互认证方法的TLS握手和协商
SET和SLP需要就将要应用的相互支持的认证方法取得一致。
6.1.3.1关于协商相互认证方法（提供信息的）
当建立到H-SLP的TLS连接时，根据下列优先次序，SET首先尝试使用具有最高优先的相互支持的认证机制建立连接:
■基于PSK的方法:基于GBA或者SEK的方法首先优先（如果支持）；
■DCert方法:第二优先（如果支持）；
■ACA或者仅SLP的方法:第三优先（从SET的角度，在基于ACA的方法和仅SLP的方法之间不存在差异）。
如果不存在相互支持的认证方法，则SET可能不能执行SUPL会话。
由于BSF或者WiMAX AAA经历问题，所以支持基于PSK的方法的SET在给定时间点可能不能使用基于GBA或者SEK的方法。因此，SET尝试使用GBA或者SEK建立认证不保证SET可能能够建立基于GBA或者SEK的密钥。
因此，SET可能不总是能够使用相互支持的具有最高优选的认证机制。如果可用，SET可能必须回复到更不优选的相互支持的认证机制。
如果仅（在H-SLP认证中）将基于PSK的方法指示为受H-SLP支持，并且引导程序失败，则为了给合适的实体返回在线的机会，SET可以在重新尝试TLS握手之前等待一小会儿。
如果SLP仅支持GBA或者SEK，则SLP受限于将SUPL3.0服务提供给已经部署了GBA或者SEK的载波的用户。如果SLP仅支持ACA，则仅可以在章节6.1.4中详细讨论的环境中使用SUPL3.0。注意到在该情况下，如果SET经由对于其SLP不能获得IP绑定的可选承载（诸如无线LAN）进行通信，则SLP将不能对SET进行认证。
如果E-SLP仅支持ACA，则如在章节6.2.5中详细讨论的，在SET认证上存在限定。
6.1.3.2为非WiMAX SET协商相互认证的方法
对于非WiMAX SET，用于SUPL会话的相互认证方法的协商如下继续:
1.SET开始协商
a.如果SET支持GBA，则SET根据有关GBA规范开始协商。
b.否则（也就是说，如果SET不支持GBA），则SET就以客户问候消息开始TLS握手，客户问候.密码组字段指示所支持的为TLS密钥交换算法使用RSA加密的TLS密码组。
2.SLP处理所接收的客户问候消息。SLP检查客户问候.密码组列表并且选择相互支持的密码组。
a.如果SET和SLP都支持TLS-PSK密码组，则这指示支持GBA。SLP以服务器问候、服务器密钥交换和服务器问候完成消息作出响应，服务器问候.密码组指示相互支持的TLS-PSK密码组。
b.否则，SET和SLP必须支持基于认证的方法。
i.如果SLP支持DCert方法，则SLP以如下内容作出响应
1.具有服务器问候.密码组的服务器问候，指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组，
2.认证，
3.认证请求和
4.服务器问候完成消息。
ii.否则，如果SET是3GPP/3GPP2SET并且SLP支持ACA方法，则SLP以如下内容作出响应
1.服务器问候认证，具有指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组的服务器问候.密码组。
2.认证
3.（不发送认证请求消息）
4.服务器问候完成消息
3.SET处理服务器问候消息和适合于所选择的给SET指示密码组的其它消息
a.如果服务器问候.密码组指示SLP已经选择了GBA，则SET和SLP继续GBA过程。细节在本文档的范围外。
b.否则，服务器问候.密码组指示对于TLS密钥交换算法使用RSA加密的相互支持的TLS密码组。
i.如果SET接收到认证.请求，则
1.如果SET支持DCert方法，则SET提供设备证书，并且SET和服务器完成TLS握手。服务器尝试识别对设备证书中与全球唯一的SET设备标识相关联的SUPL用户。假定SUPL用户已经向SLP安全地验证应该将SET设备标识与他们的订阅相关联。
a.如果没有识别出SUPL用户，则必须终止会话。由于我们假定已经完成了TLS握手，所以服务器能够在ULP层进行通信。服务器必须发送合适的ULP错误消息以终止ULP会话，并且随后关闭TLS会话。
b.如果识别出SUPL用户，则服务器给SET提供与SUPL用户相同的授权。
2.否则，SET对SLP作出应答，包括空客户端认证消息，以便暗中指示它不支持DCert方法。
a.如果SLP支持ACA，则SLP和SET随着每个ACA方法继续。SLP可以使用ACA方法继续。
b.如果SLP不支持ACA或者仅SLP的方法（SLP可能仅支持DCert方法），则SLP以合适的TLS报警消息终止TLS握手。
ii.如果服务器不发送认证.请求，则SET随着每个ACA方法继续。SLP可以继续使用ACA方法或者仅SLP的方法。
3GPP2SET可以为认证方法协商使用具有所选择的差异的类似的方法。
6.1.3.3用于WiMAX SET和SLP的认证和密钥重新协商的原理（提供信息的）
密钥重新协商可以以两种方式发生:
1.当定位根密钥（如在WiMAX网络协议和体系结构中为基于定位的服务所定义的）过期时，SET自动将其自身与wimax网络重新认证，并且将通过SET重新生成与SUPL相关联的根密钥，或者
2.SLP注意到SEK或者定位根密钥（如在WiMAX网络协议和体系结构中为基于定位的服务所定义的）过期时，它将从WiMAX AAA服务器请求新的密钥，或者
3.SLP在TLS握手期间发送“psk_标识_未知”TLS报警消息。这向SET指示SET需要将其自身与wimax网络重新认证，并且将通过SET重新生成与SUPL相关联的根密钥。
6.1.3.3.1认证过程
在WiMAX部署中，可以采用SEK使用PSK TLS握手，如下:
-客户问候消息可以包含一个或多个基于PSK的密码组；
-客户问候消息可以包含如在其中所指定的服务器_名称扩展，并且它可以包含SLP的主机名称；
-服务器问候消息可以包含通过SLP所选择的基于PSK的密码组；
-可以通过服务器发送服务器密钥交换，并且它可以包含psk_identity_hint字段，并且它可以包含静态字符串“SUPL WIMAX引导程序”；
-客户密钥交换可以包含psk_identity字段，并且它可以包含如在章节6.1.2.1.2中所指定的前缀“SUPL WIMAX引导程序”、一个单独的字符“；”和当前B-TID；
-SET可以从SLP专用密钥材料即SEK中得到TLS预控制的密码。
6.1.3.3.2认证失败
可以如在本文档范围外所描述的对认证失败进行处理。
6.1.3.3.3引导程序所需的指示
在TLS握手期间，通过发送包含基于PSK的密码组的服务器问候消息以及包含psk_identity_hint字段的服务器密钥交换消息，其包含静态字符串“SUPL WIMAX引导程序”，SLP可以向SET指示可能需要SEK密钥。如果SET不具有有效的SEK，这可能触发SET得到如在章节6.1.2.1.2中所定义的新的SEK。
6.1.3.3.4引导程序重新协商指示
在使用TLS会话期间，SLP可以通过将close_notify报警消息发送给SET向SET指示SEK已经过期。如果SET通过发送包含旧的会话ID的客户问候消息尝试重发起旧的TLS会话。SLP可以通过发送具有新的会话ID的服务器问候消息拒绝使用旧的会话ID。这将向SET指示它所使用的SEK已经过期。
在TLS握手期间，响应于由SET发送的所完成消息，SLP可以通过发送握手_失败消息向SET指示SEK已经过期。这将向SET指示它所使用的SEK已经过期。
6.1.4交替客户端认证（ACA）机制
该章节仅应用于支持GSM/UMTS和CDMA SET的部署。
注释:贯穿该章节，SET_ID是指MSISDN（如果SET在3GPP承载网络上）或者MDN、MIN或IMSI之一（如果SET在3GPP2承载网络上）。
章节6.1.3概述了SLP可以选择基于ACA的方法的环境。如果SLP在TLS握手期间选择ACA方法，则SLP可以使用基于SET_ID/IP地址映射的客户端认证对SET进行认证。该章节的其余部分描述了已知为可选客户端认证机制的该机制的细节。如果SLP执行可选客户端认证机制，则就推荐SLP也使用具有GBA的PSK-TLS实现该方法。
章节6.1.1.3描述了哪个实体必须支持基于ACA的方法，以及支持基于ACA方法的实体必须支持的算法。为了提供信息的目的，在这里重复该信息:
■承载网络可以支持基于ACA的方法。如果H-SLP希望为承载网络的用户支持基于ACA的方法，承载网络就必须支持基于ACA的方法。
■SLP可以支持基于ACA的方法。
■GSM/UMTS和CDMA SET手持设备必须支持基于ACA的方法。
■基于ACA的方法不包括SET UICC/UIM/SIM/USIM。
■基于ACA的方法不包括SPC实体。
支持交替客户端认证的SET也必须支持就具有基于认证的服务器（SLP）认证的TLS1.1。另外，必须给SET提供使得它能够验证SLP服务器证书的根认证。存在用于给SET提供根认证的各种不同的方法。没有根据该说明书定义特定机制。SUPL运营商需要确保当为交替客户端认证使用TLS1.1时，相关联的根认证存在于SET中。
支持交替客户端认证的SLP必须支持TLS1.1并且必须具有有效的TLS服 务器证书，可以通过执行交替客户端认证的SET对其进行验证。
交替客户端认证（ACA）机制是SLP可以检查SET的IP地址到分配给SET的SET_ID的绑定的机制。如果执行ACA机制，则SLP必须能够将从SET接收的SUPL消息的源IP地址映射到SLP所使用的SET_ID，以便对SET进行寻址。为了使SLP使用ACA机制，承载网络必须防止在承载级的IP地址欺骗。在源IP地址和SET的SET_ID之间的成功映射将暗示在承载网络上对SET安全地进行识别（例如，认证）。该解决方案不需要在SET上的任何专用客户（SET）认证实现，但是需要SLP支持为特定SET_ID从承载获得正确的源IP地址。
3GPP承载特定问题:在所有情况下获得源IP地址将是不可能的–例如，对于在访问而不是本地网络中使用GGSN的GPRS漫游接入。因此，交替客户端认证机制应该仅依赖于本地网络何时分配源IP地址或者具有到它的接入–例如，当可能需要SET使用本地网络中的GGSN时，为GPRS接入所申请的。
3GPP2承载特定问题:在所有情况下获得源IP地址将是不可能的–例如，对于在访问网络内使用简单IP或MIP接入的漫游HRPD接入。因此，交替客户端认证机制应该仅依赖于本地网络何时分配源IP地址或者具有到它的接入–例如，当可能需要SET使用到本地网络中的HA的MIP时，为HRPD接入所申请的。
章节6.1.4.1描述了如何为SUPL3.0中的客户端认证使用该机制。
在使用UDP/IP传送SUPL INIT的情况下，SLP可以首先通过使用SET_ID为SET IP地址查询承载网络或者通过使用IP地址为SET_ID查询承载网络验证IP地址。
6.1.4.1ACA过程
网络发起的情景:如果在从SLP接收到SUPL INIT消息之后（并且在应用如在本文档中其它地方所描述的合适的安全机制和通知/验证之后），就授权SET继续相应的SUPL会话，则应该使用现存的公开相互认证的TLS会话，或者可以如在章节6.1.1.4中所讨论的重发起之前可恢复的TLS会话。如果不能存在公开的TLS会话，或者SET或SLP选择不重发起会话，则SET和SLP需要新的TLS会话，并且SET和SLP执行如在章节6.1.3中所描述的用于对认证方法进行协商的合适的步骤。
当为了对网络发起的情景中的SET进行认证应用交替客户端认证机制时，SLP使用下列步骤:
1.注意到，响应于提供SET_ID的MLP请求，发送SUPL INIT消息。SLP为MLP请求分配SLP会话ID，并且发送SUPL INIT。SLP使用SLP会话ID将来自SET的响应与来自MIP的请求相关联。然而，SLP必须首先验证相应的SET对应于正确的SET_ID。剩余的步骤描述了该认证过程。
2.SET与SLP建立TLS1.1会话。SET必须检查将SLP所给出的TLS服务器证书绑定到在SET中配置的SLP的FQDN。
3.SLP确定来自SET的第一条SUPL消息（响应于SUPL INIT）中的SLP会话ID是否对应于由SLP所分配的当前有效的SLP会话ID。如果第一条SUPL消息中的SLP会话ID不对应于有效的SLP会话ID，则SLP以合适的消息结束SUPL会话。否则，SLP记录相应的SET ID。
4.在对来自SET的第一条SUPL消息作出响应（SUPL POS INIT、SUPL START、SUPLAUTH REQUEST、SUPL TRIGGERED START、SUPL REPORT或者SUPL END）之前，SLP必须验证SET的SET_ID。存在用于实现此的两种方法。
a.请求SET_ID
i.SLP查询潜在承载网络找到使用SET所使用的源IP地址的当前SET_ID。
1.如果从用于由SET发送的第一条SUPL消息的源IP地址的承载返回有效的SET_ID，则SLP就检查所返回的SET_ID在内部与正确的SET_ID相关联（见步骤3）。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信的，并且SLP继续SUPL会话。
2.如果不能找到有效的SET_ID，则SLP必须以相关联SUPL错误消息终止SUPL会话。
b.请求IP地址
i.SLP查询潜在的承载网络以找到与该SET_ID相关联的SET使用的源IP地址（见步骤3）。
1.如果承载网络返回IP地址，则SLP就检查该IP地址对应于第一条SUPL消息的源IP地址。如果该检查失败，则SLP以合适的SUPL消息结束SUPL会话。否则，认为SET是可信的，并且SLP继续SUPL会话。
2.如果不能找到IP地址，则SLP必须以相关联SUPL错误消息终止SUPL会话。
注释:为了获得SET_ID/IP地址绑定，承载网络可能仅支持步骤4中两种查询类型（请求IP地址或者请求SET_ID）之一。SLP负责符合承载网络所支持的方法。
SET发起的情景:当SET希望发起SUPL会话时，应该使用现存公开的相互认证的TLS会话，或者可以如在章节6.1.1.4中所讨论的重发起之前可恢复的TLS会话。如果不存在公开的TLS会话，或者SET或SLP选择不重发起会话，则SET和SLP需要新的TLS会话，并且SET和SLP执行如在章节6.1.3中所描述的用于对认证方法进行协商的合适的步骤。
当为了对SET发起的情景中的SET进行认证应用交替客户端认证机制时， SLP使用下列步骤。
1.SET与SLP建立TLS1.1会话。SET必须检查将SLP所给出的TLS服务器证书绑定到在SET中所配置的SLP的FQDN。
2.在对第一条SUPL消息（例如，SUPL START、SUPL TRIGGERED START）作出响应之前，SLP必须验证SET的SET_ID。存在用于实现此的两种方法。
a.请求SET_ID
i.SLP使用SET所使用的源IP地址查询潜在的承载网络以找到当前的SET_ID。
1.如果从承载返回对于由SET发送的第一条SUPL消息的源IP地址有效的SET_ID，则SLP就检查所返回的SET_ID与SET所提供的相同。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信赖的，并且SLP继续SUPL会话。
2.如果不能找到有效的SET_ID，SLP必须以相关联SUPL错误消息终止SUPL会话。
b.请求IP地址
i.SLP查询潜在的承载网络以找到与该SET_ID相关联的SET所使用的源IP地址。
1.如果承载网络返回IP地址，则SLP检查该IP地址对应于第一条SUPL消息的源IP地址。如果该检查失败，则SLP以合适的消息结束SUPL会话。否则，认为SET是可信赖的，并且SLP继续SUPL会话。
2.如果不能找到IP地址，SLP必须以相关联SUPL错误消息终止SUPL会话。
注释:在SLP发起的和SET发起的情景中，SLP可以通过给承载网络发送合适的查询对SET进行重新认证，以便将SET_ID绑定到当前正在使用的源IP地址。存在这可能是有用的各种环境，例如：（A）如果SET的IP地 址在TLS会话期间改变，则SLP可以给承载网络发送合适的查询，以便确保SET_ID与新的IP地址相关联；（B）当重发起TLS会话时，SLP可以重新使用之前如在章节6.1.1.4中所讨论的TLS会话，从而节约计算，并且简单地将合适的查询发送到承载网络，以便对SET进行认证。注意到，以这种方式对SET进行重新认证不包括与SET自身的相互作用。
6.2可应用于E-SLP的认证机制
6.2.1关于紧急服务调整主体
SUPL3.0紧急SUPL会话可以是网络发起的（使用SUPL）或者SET发起的。合适的紧急服务调整主体将规定对这些紧急会话的支持:
·合适的紧急服务调整主体可以不规定对网络发起的或者SET发起的会话的支持；
·合适的紧急服务调整主体可以规定仅支持网络发起的会话；
·合适的紧急服务调整主体可以规定仅支持SET发起的会话；
·合适的紧急服务调整主体可以规定支持网络发起的和SET发起的会话。
6.2.2在紧急会话期间SUPL会话区分优先次序
对于紧急SUPL会话在SET上的持续时间，必须使SET上的所有SUPL资源对于该紧急会话是可利用的。因此：
·当SET发起紧急SUPL会话时，必须立即通过SET终止任何关于非紧急会话的SUPL通信。如果此时SET正在处理非紧急的SUPLINIT消息（例如，具有经验证的MAC或者获得用户许可），则这些过程可能失败，并且可能丢弃SUPL INIT消息。
·如果SET在紧急SUPL会话中接收到非紧急SUPL INIT消息，可以丢弃这些SUPLINIT消息。
6.2.3E-SLP FQDN
在网络发起的紧急SUPL会话中，E-SLP的FQDN可以是：
1.提供给SET作为SUPL INIT中的E-SLP地址的FQDN。E-SLP FQDN可以具有“e-slp.xxx.xxx.xxx.xxx.xxx”的格式，其中，“xxx”可以是任何有效的字符串。
2.如果不在SUPL INIT中提供FQDN，可以使用所提供的H-SLP地址。
3.如果每次上述1或2FQDN是不可用的，可以将FQDN默认为下列3个可选项之一：
-（如果连接到3GPP承载网络）
如果不明确提供FQDN，就是“e-slp.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”。在该情况下，MCC和MNC对应于服务3GPP网络。
-（如果连接到3GPP2承载网络）
如果不明确提供FQDN，就是“e-slp.mnc<MNC>.mcc<MCC>.pub.3gpp2network.org”。在该情况下，MCC和MNC对应于服务3GPP2网络。
-（如果连接到WiMAX承载网络）就是“e-slp.operator.com”，其中，operator.com是H-SLP运营商的FQDN。
在SET发起的紧急SUPL会话中，E-SLP的FQDN可以是如下优先次序：
1.（如果可用）由合适的紧急情况服务调整主体所规定的FQDN。
2.由本地接入网络或者通过H-SLP所验证的其它方式提供的FQDN。
3.由H-SLP提供的FQDN。
6.2.4处理紧急SUPL INIT消息
E-SLP不使用SUPL INIT消息基于SET的完整性验证和消息初始认证。因此，不必组装紧急SUPL INIT中的MAC字段。
在紧急呼叫期间，SET不可以应用紧急SUPL INIT消息的端到端保护。
通过使用E-SLP白名单提供了一些保护。E-SLP白名单基于对SET的当前位置估计（诸如蜂窝ID和/或网络ID）。SET使用E-SLP白名单确定SET应该对所接收的紧急SUPL INIT消息进行处理的次序：E-SLP白名单不可以用于丢弃紧急SUPL INIT消息。
6.2.4.1E-SLP白名单
如果在不安全的端到端信道上（诸如SMS或者OMA推送或UDP/IP）接收紧急SUPLINIT消息，则紧急SUPL INIT消息可以是伪造或者改变的。该章节的剩余部分描述了用于确保SET能够尽可能联系真正的E-SLP服务器的安全措施。
注释:调整需求将规定SET应该接受和处理紧急SUPL INIT消息的条件。例如，在许多情况下，调整需求仅需要如果SET当前正在参与紧急呼叫，SET就接受和处理紧急SUPLINIT消息。因此，条件（在该条件下SET应该接受和处理紧急SUPL INIT消息）在本文档的范围外。
当SET接收紧急SUPL INIT消息时，SET必须首先验证当前满足条件（在该条件下SET应该接受紧急SUPL INIT消息）。如果不满足条件，则SET刻意忽略SUPL INIT消息。关于此的描述假定当SET接收紧急SUPL INIT消息时满足条件。
注释:攻击者可能在SET正在期望真正的紧急SUPL INIT消息的同时给SET发送多个（虚假的）紧急消息。可能存在不能（提前）告诉SET期望来自哪个紧急SLP的紧急SUPLINIT消息的情况。该攻击是下列过程的动机。
对于满足“接受和处理”条件的时期，即使紧急SUPL INIT消息列出了对于E-SLP不期望的地址，SET也不必删除所接收的紧急SUPL INIT消息。一旦SET确定不再满足条件（例如，一旦联系了正确的E-SLP，或者在紧急呼叫之后已经经过了足够时间），则SET必须默默地丢弃任何所接收的紧急SUPL INIT消息。
如果SET接收、接受和处理虚假的紧急SUPL INIT消息（当仍然满足“接受和处理”条件时），则SET可能不接收紧急SUPL INIT消息是虚假的指示，直到尝试联系在紧急SUPLINIT消息中所指示的E-SLP为止。当E-SLP拒绝SUPL会话时，出现该指示。该过程不是即时的，因此SET可能必须查询紧急SUPL INIT消息它是否接收到多于一条紧急SUPL INIT消息。
E-SLP白名单包含SET可以期望从其接收紧急SUPL INIT消息的E-SLP FQDN列表。SET使用E-SLP白名单以确保应该在包括不在白名单上的E-SLP FQDN的紧急SUPL INIT消息之前对包括在白名单上的E-SLP FQDN的紧急SUPL INIT消息进行处理。
示例:将包含在白名单上的E-SLP FQDN的紧急SUPL INIT消息推送到紧急SUPLINIT队列，以便确保在对包含不在白名单上的E-SLP FQDN的紧急SUPL INIT消息之前对消息进行处理。E-SLP白名单应该是用于对紧急SUPL INIT队列进行排序的第一准则。第二准则是到达时间，使用先入先出原则:
·如果SET具有对于SET当前位置的当前E-SLP白名单，则SET使用两个准则对队列进行排序。
·如果SET不具有对于SET当前位置的当前E-SLP白名单，则SET使用先入先出原则对队列进行排序。
6.2.4.3关于紧急SUPL INIT消息的过程
如果在端到端安全的信道（诸如安全SIP推送）上接收到紧急SUPL INIT，则可以立即对紧急SUPL INIT消息进行处理。在该情况下，忽略该子章节 的剩余考虑。
如果在不是端到端安全的信道（诸如SMS或者OMA推送或UDP/IP）上接收到紧急SUPL INIT消息，则如在章节6.2.4.1中对消息进行排队。SET通过队列中的消息工作，在尝试连接到E-SLP以便作出响应之前应用合适的验证和通知。
响应于SUPL INIT消息，SET可以与相关联E-SLP（见章节6.2.3）建立安全的TLS会话（见章节6.2.5），并且下列之一发生：
■如果在对SET认证之后（见章节6.2.5），E-SLP不能将SET与任何显著的SUPL会话相关联，则E-SLP可以结束会话。如果还没有完成TLS握手，为了节约不必要的计算，则E-SLP应该使用TLS错误消息结束会话。如果完成TLS握手，则E-SLP可以使用指示没有对SET进行授权的SUPL错误消息结束会话。SET可以将错误消息的任何一种形式解释为SUPL INIT消息是欺骗性的指示。随后，SET以在队列中优先权的次序对下一个SUPL INIT消息进行处理。
■如果，在对SET进行认证之后（见章节6.2.5），E-SLP能够将SET与显著的SUPL会话相关联，则SET和E-SLP如正常继续。
SET继续对紧急SUPL INIT消息作出响应，直到找到真正的消息为止。一旦识别出正确的E-SLP，SET可以丢弃任何新的或者已排队的SUPL INIT消息。仍然可以对来自正确E-SLP的新的或者已排队的SUPL INIT消息进行处理。
下列两个注释是调整主题可能希望考虑的建议。
注释:一旦识别出正确的E-SLP，则SET就应该确保它记得该正确的E-SLP的FQDN直到SUPL会话成功地完成为止。如果与E-SLP的TLS会话过早地结束（例如，如果存在数据丢失连接），SET就应该继续尝试与E-SLP重新建立TLS会话，直到重新建立TLS会话使得SUPL会话可以继续成功完 成为止。在一些情况下，可以想象SET重新建立TLS会话若干次。如果SET在重新建立TLS会话时没有获得成功，无论如何SET就应该继续尝试：由于这是紧急情况，成功的益处比缺点蓄电池的开销更有价值。
注释:如果E-SLP在认证之后但是在成功完成SUPL会话之前丢失与SET的联系，则E-SLP应该保持SUPL会话公开，希望SET能够重新建立联系并且完成SUPL会话。
6.2.5用于紧急会话的认证
注释:在章节6.1.1.3中指定了E-SLP可以支持的相互认证的方法。如在章节6.1.3中所指定的，SET和E-SLP在TLS握手期间协商相互认证方法。
用于紧急会话的优先次序是
·GBA或者SEK方法:第一优先
·DCert方法:第二优先
·ACA方法:第三优先
·仅SLP的方法:最后优先。应该将仅SLP的方法视为最后手段。
在章节6.2.3中讨论了用于所有这些情况的E-SLP的FQDN。
基于GBA的方法（仅3GPP/3GPP2SET）:如在章节6.1.3中所描述的，SET和E-SLP可以采用GBA执行PSK-TLS，E-SLP作为NAF。对于网络运营商设置的有效期，可以保留由E-SLP为特定SET获得的Ks_NAF与SET标识（例如，IMSI、MSISDN）相关联。
基于SEK的方法（仅WiMAX SET）:如在章节6.1.3中所描述的，SET和E-SLP可以采用SEK使用PSK-TLS执行相互认证，E-SLP以与H-SLP类似的方式作用。在章节6.2.3中讨论了E-SLP的FQDN。对于网络运营商设置的有效期，可以保留由E-SLP为特定SET获得的SEK与SET标识（例 如，WiMAX用户ID）相关联。
DCert方法（所有SET）:如在章节6.1.2.2.1中所描述的，SET和E-SLP可以使用DCert方法执行相互认证。如在章节6.2.3中所定义的，SET可以使用包含在SET中的E-SLP的根认证和E-SLP的FQDN对E-SLP进行认证。
基于ACA的方法（仅当在相应的承载网络上的3GPP/3GPP2SET）:对于在E-SLP中不支持采用PSK-TLS的GBA和DCert方法的SUPL3.0实现，可以支持在章节6.1.4中定义的可选客户端认证机制，具有如下差异。E-SLP可以通过将SET所使用的IP地址与服务网络提供给E-SLP的用于SET的IP地址绑定对SET进行认证，-例如，通过3GPP网络中或者3GPP2网络中的LRF或者E-CSCF。
·网络发起的会话:由于使用SET IP地址发起任何紧急VoIP呼叫，并且在唤醒SUPL之前可以通过服务网络对SET IP地址进行验证，所以E-SLP可以认为它是可靠的。在电路模式中发起紧急呼叫的情况下，SET IP地址对于服务网络可能是未知的（例如，可以通过本地网络分配），在该情况下，不能通过服务网络给E-SLP提供IP地址，并且当稍后从SET接收时，不能验证IP地址。
·SET发起的会话:为了使用ACA方法，服务承载网络必须防止在承载级的IP地址欺骗。应该注意到，无论SET是否在承载网络上注册为授权的，都可以应用ACA方法。这支持在SET中不存在激活SIM/USIM/UICC/（R）UIM的情况。
仅SLP方法（所有SET）:如果不能使用其它认证方法，则SET可以使用仅SLP的方法建立到E-SLP的安全IP连接。SET可以使用如在章节6.2.3中所定义的包含在SET中的E-SLP的根认证和E-SLP的FQDN对E-SLP进行认证。执行相互认证的能力取决于会话是SET发起的还是网络发起的。
·网络发起的会话:如果SUPL会话是网络发起的，则E-SLP可以基于（例如）如在章节6.2.6中所讨论的会话ID和所接收的SUPL INIT的散列对SET进行微弱认证
·SET发起的会话:如果SUPL会话是SET发起的
应该注意到，无论SET是否在承载网络上注册为授权的，都可以应用仅SLP的方法。这支持在SET中不存在激活SIM/USIM/UICC/（R）UIM的情况。
6.2.6用于紧急SUPL会话的SUPL INIT的完整性保护
如果E-SLP能够如在章节6.2.5中所讨论的对SET进行认证，并且E-SLP可以将SET与显著的SUPL会话相关联，则E-SLP就检查SUPL INIT消息是否改变。如果E-SLP检测到SUPLINIT消息改变（例如，如在章节6.3.1中所描述的，如果当指示代理模式时接收到SUPL AUTHREQ消息，或者如果SLP会话ID是错误的，或者如果VER验证失败），则E-SLP必须在TLS会话上将SUPL INIT发送给SET，以便确保给SET提供正确的参数。作为响应，SET将丢弃使用它最初接收的SUPL INIT发起的SUPL会话，并且SET可以使用在TLS会话上接收的SUPL INIT发起新的SUPL会话。随后，SET可以立即对该SUPL INIT消息进行处理（即，SET不使用E-SLP白名单评估优先权）、执行用于通知和验证的合适的行为，并且假如用户不拒绝会话，则SET就将合适的消息（SUPL POS INIT或者SUPL AUTH REQ）发送给E-SLP以便继续会话。
重新发送SUPL INIT的能力仅仅旨在为了紧急会话。在非紧会话中，如果检测到SUPL INIT的改变，则如在非紧急呼叫流中所指定的，SLP可以使用SUPL END结束SUPL会话。
6.3SUPL INIT消息的处理
由于网络发起的SUPL会话是通过SUPL INIT消息触发的，所以必需保护SUPL INIT消息对抗伪装并且（在一些情况下）对抗重放攻击。
SUPL3.0为SUPL INIT消息指定了下列保护:
·基于网络的安全，其中，SLP可以执行检查，以确保SUPL INIT消息的认证（章节6.3.1）和重放保护（章节6.3.2）。在SET对SUPL INIT消息的内容进行处理并且为了执行SUPL会话的目的与SLP建立了安全的TLS会话之后，发生该验证。
·端到端安全，其中：SLP可以给SUPL INIT消息应用加密、完整性保护和重放保护的组合；并且SET应用相应的解密、完整性验证和重放检测的组合。SET在对SUPL INIT消息的内容进行处理之前应用这些安全措施。该安全性仅应用于非紧急SUPL INIT消息。
基于网络的安全性是强制的，而端到端安全性是可选的。
6.3.1SUPL INIT消息基于网络的认证
SLP总是执行SUPL INIT消息完整性的网络验证。响应于SUPL INIT消息而发送的第一条消息（即，SUPL POS INIT、SUPL AUTH REQ或者SUPL TRIGGERED START消息）必须包含验证字段（VER）。当SLP接收到响应于SUPL INIT消息而发送的第一条消息时，SLP必须检查所接收的VER字段与在所发送的SUPL INIT消息上计算的相应值。如果该验证失败，SLP必须以包含状态码‘authSuplinitFailure’的SUPL END消息终止会话。
必须如下计算用于验证字段的值：
·VER=H（SLP XOR opad,H（SLP XOR ipad,SUPL INIT））
其中，SLP是SLP地址的FQDN。SHA-256必须用作采用opad和ipad的散列（H）函数。必须将SHA-256HASH函数的输出截短到64比特，即必须将函数实现为HMAC-SHA256-64。注意到，不认为SLP地址是秘密的。这里所使用的HMAC结构不提供任何数据认证，而是仅用作对HASH函数的替换。
6.3.2SUPL INIT消息基于网络的重放保护
对于网络发起的情况，必须由SLP提供保护对抗重放攻击。除非已经与对应于在SUPL消息内部所接收的“SLP会话Id”一起发送了之前未过期的SUPL INIT消息，否则SLP必须确保没有从授权SET接受SUPL消息。SLP还必须确保SUPL消息的类型（例如，SUPL POSINIT、SUPL AUTH REQ、SUPL TRIGGERED START）与在SUPL INIT消息中发送的参数一致。实现必须确保将“SLP会话Id”与已经授权的SET用户ID（例如，MSISDN、WiMAX用户ID或MDN）正确相关联。
如果使用本文档中所描述的可选客户端认证方法执行SET用户认证，则已经建立了在来自SET的响应的源IP地址（UPL POS INIT、SUPL AUTH REQ或SUPL TRIGGERED START）和SET用户的MSISDN或MDN之间的映射，并且必须使用该MSISDN或MDN作为授权的MSISDN或MDN。
抛弃错误，SUPL POS INIT、SUPL AUTH REQ或SUPL TRIGGERED START不必生成对于SET可收费的事件。
对于非代理网络发起的情况，SLP必须仅在从SPC接收到对成功完成SUPL定位确认之后创建可收费的事件。
6.3.3SUPL INIT消息的端到端保护
注释:SUPL INIT消息的端到端保护仅应用于非紧急SUPL INIT消息。
在本说明书中提供了端到端SUPL INIT保护的三种选规则：空、模式A和模式B。
·空SUPL INIT保护不提供端到端完整性保护、不提供端到端重放保护并且不提供机密性保护。在章节6.3.4中描述了用于空SUPL INIT保护的过程。
·模式A SUPL INIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式A SUPL INIT保护使用SLP在安全ULP会话期间发送给SET的共享密钥。在章节6.3.5中描述了用于模式A SUPL INIT保护的过程。
·模式B SUPL INIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式B SUPL INIT保护使用利用合适的基于PSK的方法（GBA或者SEK方法）得到的共享密钥。在章节6.3.6中描述了用于模式B SUPL INIT保护的过程。
对于保护级的优先权次序如下：
■空SUPL INIT保护具有最小优先权。
■模式A SUPL INIT保护具有比空SUPL INIT保护更高的优先权。
■模式B SUPL INIT保护具有比模式A SUPL INIT保护更高的优先权。
在SUPL INIT消息中，根据当前保护级分配保护等级参数（在下表中）。
注释:书写本说明书以便允许在未来修订中添加更先进的保护级别。该先进保护可以允许为了使SUPL INIT安全的其它方式的协商（例如，允许加密并且允许算法协商）。包括保护等级参数以便帮助SET确定它是否能够解析SUPL INIT消息：为了扩展，可能需要保护等级参数。
SUPL INIT消息具有为了包括安全参数呈现的保护器参数：在下表中指定了保护器参数的呈现。
SUPL INIT保护等级参数值和SUPL INIT保护器参数的呈现
支持基于ACA的方法的SET或D-SLP或H-SLP必须支持空SUPL INIT保护。
所有的SET必须支持模式A SUPL INIT保护过程。
D-SLP或者H-SLP可以支持模式A SUPL INIT保护过程。
SET或者D-SLP或者支持基于PSK方法的H-SLP必须支持模式B SUPL INIT保护过程。
E-SLP实体不包括在当前定义的SUPL INIT保护中。
6.3.3.1协商SUPL INIT保护级别
下列过程仅应用于是D-SLP和H-SLP的SLP，过程不应用于E-SLP。
如何协商SUPL INIT保护等级的非正式描述如下：
1.当不存在有效的SUPL_INIT_ROOT_KEY时（例如，在上电时或者当SUPL_INIT_ROOT_KEY的有效期过期时），SET必须应用空SUPL INIT保护。最初的保护等级总是空SUPLINIT保护。在该状态中，SET处理所有SUPL INIT消息，即不静静地丢弃任何消息。如果以错误条件对SUPL INIT消息进行解析，SET就将错误消息发送给SLP。
2.如果SET具有有效的SUPL_INIT_ROOT_KEY以及对于特定SLP已经使用模式A或者模式B SUPL INIT保护协商的有效的 ReplayCounter，则SET使用协商模式（模式A或者模式B）对来自该SLP的所有SUPL INIT消息进行处理。
3.当SET建立到SLP的相互认证的安全连接时，
a.如果为相互认证使用基于PSK的方法（GBA或者SEK），则模式B SUPL INIT保护应用，并且在PSK-TLS握手中交换的B-TID对应于Ks（将用作3GPP和3GPP2部署中的Ks_NAF）或者可以用于得到将用作3GPP和3GPP2部署中的Ks_NAF的SUPL_INIT_ROOT_KEY的SEK。在模式B SUPL INIT保护中使用该Ks_NAF或者SEK以及相关联的B-TID，直到下列条件之一为止：
i.密钥过期，在该情况下，SET和SLP回复空SUPL INIT保护，
ii.SET和SLP在非紧急会话中使用ACA方法，在该情况下，如在以下步骤3b中所讨论的，SET和SLP回复模式A或者空SUPL INIT保护，或者
iii.SET和H-SLP使用GBA或者SEK的引导程序重新协商方法使用新的B-TID建立TLS，在该情况下，现在B-TID和相应的Ks_NAF或SEK用于模式B SUPL INIT保护。
b.否则，SET和SLP使用DCert或ACA方法建立安全连接。
i.如果SET不具有有效的SUPL_INIT_ROOT_KEY，则SET在第一条ULP消息中将SUPL_INIT_KeyRequest参数发送给SLP。
1.如果SLP支持模式A SUPL INIT保护，则SLP通过在第一个对SET的ULP响应中发送模式密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和基本重放计数器参数作出响应。当SET接收这些参数时，则这向SET指示模式A SUPL INIT保护应用。
注释:用于更新SUPL_INIT_ROOT_KEY的策略是SLP运营商的决定。
2.如果SLP不支持模式A SUPL INIT保护（或者在该特定时间不支持模式A SUPLINIT保护），则SLP就给SET（在ULP消息中）发送空SUPL INIT保护应用的指示。
ii.如果SET具有有效的SUPL_INIT_ROOT_KEY，但是不具有有效的临时模式A密钥标识符或者丢失了关于重放保护的同步，则SET在第一条ULP消息中将SUPL_INIT_ResynchRequest参数发送给SLP。
1.如果SLP支持模式A SUPL INIT保护，则SLP使用在章节6.3.6.1.1中所指定的过程以新的临时模式A密钥标识符作出响应（在对SET的第一次响应中）。当SET接收到该响应时，则这向SET指示模式ASUPL INIT保护应用。
2.如果SLP不支持模式A SUPL INIT保护（或者在该特定时间不支持模式A SUPLINIT保护），则SLP给SET（在ULP消息中）发送空SUPL INIT保护应用的指示。
注意到，这意味着每次SET建立到H-SLP的新的TLS连接时，都重新协商保护等级。
6.3.3.2从H-SLP角度的协商
如果使用GBA或者SEK方法对与SET的最新IP会话进行认证，并且H-SLP具有当前B-TID和用于SET的相关联密钥，则
■如果B-TID是用于使用GBA获得的密钥，则H-SLP分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成
○ FQDN可以是H-SLP_FQDN
○在OMNA注册中定义了可以用于SUPL_INIT保护的GBA Ua安全协议标识符
■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK
■假定没有协商任何其它SUPL INIT保护，则H-SLP为该SET分配模式B SUPL INIT保护等级。
否则，如果H-SLP具有有效的模式A密钥标识符以及用于SET的相关联密钥，则H-SLP为该SET分配模式A SUPL INIT保护等级。
如果没有分配其它保护级别，则H-SLP为该SET分配空SUPL INIT保护等级。
H-SLP应用对应于当前所分配的SUPL INIT保护级别的过程（为了在递送之前处理SUPL INIT消息）。这包括为SUPL INIT消息中的保护等级参数分配合适的值。
6.3.3.3从SET角度的协商
如果使用GBA或者SEK方法对与H-SLP的最新IP会话进行认证，并且SET具有当前B-TID和用于该IP会话的相关联密钥，则
■如果B-TID是用于使用GBA获得的密钥，则SET分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成
○ FQDN可以是H-SLP_FQDN
○在OMNA注册中定义了可以用于SUPL_INIT保护的GBA Ua安全协议标识符
■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK
■假定没有协商任何其它SUPL INIT保护，则SET分配模式B SUPL INIT保护等级。
否则，如果SET具有有效的模式A密钥标识符、相关联密钥以及用于H-SLP的模式A重放计数器，则H-SLP为该SET分配模式A SUPL INIT保护等级。如果没有分配其它保护级别，则SET分配空SUPL INIT保护级别。
SET应用对应于当前所分配的SUPL INIT保护的过程（为了处理所接收的SUPLINIT消息）。
6.3.3.4例外过程
如果SET确定SET发起的SUPL INIT保护参数已经被破坏，则SET必须与H-SLP建立TLS会话：
·如果使用GBA认证，则SET必须发起GBA引导程序以便建立新的密钥；
·对于使用SEK方法的SET，SET必须发起SEK引导程序以便使能新的密钥；
·否则，SET在第一条安全ULP消息中发送SUPL_INIT_KeyRequest，并且跟随在章节6.3.3.1的步骤3.b中的过程之后。
如果SLP丢失安全内容（例如，大量数据丢失），则SLP将没有办法发起定位行为。当Ks_NAF过期或者SET连接到SLP时，将重建内容。为了防止这种“封闭窗口”，SLP应该确保以充分从该情景中恢复的冗余存储所有SUPL INIT安全内容信息。
6.3.4当分配空保护级别时的规范
注释:对于空SUPL INIT保护不存在SUPL INIT保护器。
6.3.4.1H-SLP过程
对于专用于空SUPL INIT保护的SLP不存在安全过程。
6.3.4.2SET过程
当分配空SUPL INIT保护并且SET接收到SUPL INIT消息时，则SET应用下列过程：
■如果保护等级参数是正确的，则SET认为消息是可信的，并且可以不需要关于安全的处理。
○假定SLP和SET可以支持更高的保护级别，但是由于正在上电，SET还没有与SLP联系：在该情况下，SET将具有空SUPL INIT保护分配。在直到SET联系SLP为止的时期中，SET将认为任何所接收的SUPL INIT消息（具有正确的保护等级参数）是可信的。当SET首次联系SLP时（其可以或者可以不是对所接收的SUPL INIT消息作出响应），SET和SLP将转换到更高的保护级别。一旦两个实体转换到更高的保护级别，SET可以检测未认证的SUPL INIT消息。在当SET上电时和当SET首次联系SLP时之间，存在SET可以接收不可信的SUPL INIT消息的时期，其中，好像该SUPL INIT消息是可信的一样，SET对其进行处理。如果SET决定继续进行与未认证SUPL INIT消息相关联的SUPL会话，则SET将联系SLP并且建立安全的TLS会话。由于使用不可信的SUPL INIT消息建立SUPL会话，所以SLP将不允许SUPL会话。如果SET和SLP支持更高的保护级别，则这将同时建立，并且SET此后将能够检测不可信的SUPL消息。这意味着，如果SET和SLP可以支持更高的保护级别，则存在非常小的攻击者使SET接受不可信的SUPL INIT消息的机会窗口，并且SET将仅为至多一条不可信的SUPL INIT消息尝试继续进行SUPL会话。
■如果保护等级参数不正确（即，如果保护等级参数是除了空之外的其它任何内容），则SET将合适的错误消息发送给SLP。
○在SLP和SET处的保护级别失去同步的情况下，该过程允许SET和SLP在公共保护级别上进行重新同步。
6.3.5用于模式A SUPL INIT保护级别的规范
6.3.5.1用于模式A SUPL INIT保护的密钥标识符
模式A SUPL INIT保护使用使用可以与SUPL INIT消息一起发送的两个密钥标识符：模式A密钥标识符和临时模式A密钥标识符。
·模式A密钥标识符是全球唯一的、与SUPL_INIT_ROOT_KEY相关联的长期密钥标识符。仅当SLP为SUPL_INIT_ROOT_KEY提供新的值时，SLP给SET提供新的模式A密钥标识符。
·临时模式A密钥标识符是与模式A密钥标识符相关联的短期标识（假名）。临时模式A密钥标识符在临时模式A密钥标识符有效期间可以是全球唯一的。如在章节6.3.5.3和6.3.5.4中所述，SET和SLP对临时模式A密钥标识符的值进行同步。
典型地，SLP将使用临时模式A密钥标识符作为基本SUPL INIT保护器中的密钥标识符。随后，SET使用临时模式A密钥标识符确定应该使用哪个SUPL_INIT_ROOT_KEY验证基本SUPL INIT保护器。
典型地，不在SUPL INIT消息中发送模式A密钥标识符，因为这将允许观测者将多条SUPL INIT消息与公共SET用户相关联。临时模式A密钥标识符的目的是防止威胁代理使用模式A密钥标识符将多条SUPL INIT消息与SET用户相关联。仅SLP和SET应该能够将临时模式A密钥标识符与模式A密钥标识符相关联。改变临时模式A密钥标识符的频率主要是SET用户的决定。SLP可以基于SLP策略选择为临时模式A密钥标识符建立新的值。
然而，存在SLP可能希望使用长期模式A密钥标识符作为基本SUPL INIT保护器中的密钥标识符的情况。例如，假定SET还没有使用基本SUPL INIT保护器中的临时模式A密钥标识符对多条SUPL INIT消息作出响应。SLP 可能关心SET已经丢失关于临时模式A密钥标识符的同步。SET和SLP更可能保持在长期模式A密钥标识符上的同步。因此，SLP可以使用基本SUPL INIT保护器中的模式A密钥标识符发送SUPL INIT消息，以确保同步丢失不防止SET验证SUPL INIT消息。
6.3.5.2模式A SUPL INIT保护和基本SUPL INIT保护器
模式A SUPL INIT保护使用如在章节6.3.7中所定义的基本SUPL INIT保护器和相关联过程，具有下列附加澄清：
■密钥标识符类型:指示使用模式A密钥标识符还是临时模式A密钥标识符。
■密钥标识符:对应于模式A密钥标识符还是临时模式A密钥标识符作为适合于模式A密钥标识符类型。
■使用SUPL_INIT_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“Mode A IK”）计算BasicMAC，使用与上述密钥标识符相关联的SUPL_INIT_ROOT_KEY。
6.3.5.3H-SLP过程
仅模式A专用的H-SLP过程涉及维持SET和SLP之间的同步。
通过SLP在发送新的临时模式A密钥标识符参数（在到安全ULP会话中的SET的第一条响应消息中）之后发送新的临时模式A密钥标识符建立对于临时模式A密钥标识符的新的值。建立新的临时模式A密钥标识符导致将BasicLastReplayCounter重置为0x0000，并且SET移除关于“所播放的”SUPL INIT消息的所有信息。
响应于SUPL_INIT_ResynchRequest或者SLP的内部决定（在范围外），SLP可以建立新的临时模式A密钥标识符。也就是说，即使当不存在来自SET的相应的SUPL_INIT_ResynchRequest时，SLP也可以发送临时模式A密钥标识符。
6.3.5.4 SET过程
仅模式A专用的SET过程涉及维持SET和SLP之间的同步。
SET可以通过在ULP会话的第一条消息中发送SUPL_INIT_ResynchRequest触发为临时模式A密钥标识符建立新的值。
如果通过SET分配了模式A SUPL INIT，则在SET采用给定的临时模式A密钥标识符对SUPL INIT消息进行处理之前，SET清理它的具有为基本重放计数器使用过的值的缓存。
6.3.6用于模式B SUPL INIT保护级别的规范
模式B SUPL INIT保护使用如在章节0中所定义的基本SUPL INIT保护器和相关联过程，具有下列附加澄清：
■密钥标识符类型:对于模式B SUPL INIT保护，仅支持B-TID标识符。
■密钥标识符:对应于当前B-TID
■使用SUPL_INIT_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“Mode A IK”）计算BasicMAC参数，其中：
○对于基于GBA的部署，SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如在OMNA注册中所定义的使用用于SUPL INIT保护的GBA Ua安全协议标识符生成。
○对于基于SEK的部署，SUPL_INIT_ROOT_KEY是如在章节6.1.2.1.2中所定义的SEK_MAC。
6.3.6.1 H-SLP过程
仅模式B专用的H-SLP过程涉及维持SET和SLP之间的同步。
对于模式B SUPL INIT保护，首次使用密钥时，将SLP中的基本重放计数 器重置为零，并且SET移除关于“已播放的”SUPL INIT消息的所有信息。
在SLP确定可能需要重新同步的不太可能的情况下：
·在部署支持GBA方法的情况下，SLP通过使GBA B-TID无效触发重新同步。当SET接下来尝试对SLP进行认证时，则SLP将以TLS-PSK报警“psk_identity_unknown”作出响应。这提示建立新的GBA密钥。
·在部署支持SEK方法的情况下，SLP通过使SEK B-TID无效触发重新同步。当该SET接下来尝试对SLP进行认证时，则SLP将以TLS-PSK报警“psk_identity_unknown”作出响应。这提示建立如在章节6.1.3.3中所描述的新的SEK。
6.3.6.2SET过程
仅模式B专用的SET过程涉及维持SET和SLP之间的同步。
如果通过SET分配了模式B SUPL INIT保护，则
·在SET首次采用给定的SUPL_INIT_ROOT_KEY对SUPL INIT消息进行处理之前，SET清理它的具有为基本重放计数器使用过的值的缓存。
·SET可以通过建立适当的新的GBA Ks或者新的SEK触发重新同步。SLP将继续使用旧的GBA Ks（或SEK），直到SET和SLP之间下一次成功认证为止，因此SET应该维持旧的GBAKs（或SEK）直到那时为止。
6.3.7用于使用基本SUPL INIT保护器的规范
基本SUPL INIT保护器用于模式A和模式B SUPL INIT保护，包括下列参数：
■密钥标识符类型:长度=1个八位字节
■密钥标识符:可变长度。对应于用于计算BasicMAC的密钥
■基本重放计数器:长度=2个八位字节
■BasicMAC:长度=4个八位字节
如下生成BasicMAC参数：
■BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,SUPL_INIT’），其中
■根据章节6.3.5和6.3.6分别为模式A和模式B SUPL INIT保护得到SUPL_INIT_Basic_IK，
■SUPL_INIT’对应于分配了除了BasicMAC之外的所有参数的SUPLINIT，并且具有设置为全零的MAC参数，并且
■在本文档范围之外的文档中规定了HMAC-SHA256-32和HMAC-SHA256-128。
6.3.7.1H-SLP过程
在其它地方规定了对于模式A和模式B SUPL INIT保护的用于模式A最后重放计数器同步的SLP过程。
如果给SET分配了模式A或模式B SUPL INIT保护，则H-SLP由SUPL INIT消息组成，如下：
1.如其它处所述分配SUPL INIT保护器之外的参数。
2.根据SLP将用于该消息的密钥标识符的类型设置密钥标识符类型。
3.将密钥标识设备为与SUPL_INIT_ROOT_KEY相关联的密钥标识。
4.H-SLP将基本最后重放计数器值（与该SET相关联以及经协商的SUPL INIT保护级别）的当前值增大1，并且将新的值***基本重放计数器参数中。
5.最后，在分配了所有其它参数之后，如上所规定的那样，从SUPL INIT和SUPL_INIT_ROOT_KEY计算出BasicMAC。
可能需要H-SLP为每个分配了模式A或者模式B SUPL INIT保护等级的SET存储长度等于基本重放计数器参数长度的基本最后重放计数器值。
如果SLP中的基本最后重放计数器值接近65535=216-1（其未必很高），则SLP必须触发重新同步过程（见章节6.3.6.1和6.3.7.1）。
6.3.7.2SET过程
在其它地方规定了对于模式A和模式B SUPL INIT保护的用于模式A最后重放计数器同步的SET过程。
如果分配了模式A或模式B SUPL INIT保护，则SET对所接收的SUPL INIT消息进行处理，如下：
1.如果下列参数不能合适地验证，SET就丢弃SUPL INIT消息：
■保护级别:必须是为经协商的SUPL INIT保护级别所分配的值
■密钥标识类型:对于所分配的SUPL INIT保护级别必须是有效的
■密钥标识:必须对应于用于经协商的SUPL INIT保护级别的当前SUPL_INIT_ROOT_KEY
■级别重放计数器:SET使用该值检测消息的重放。技术可以是实现专用的，但是必须足够健壮，以便处理SUPL INIT消息丢失或者不按次序递送的情况。
■BasicMAC:SET从SUPL INIT和SUPL_INIT_ROOT_KEY（如上所述）计算所期望的BasicMAC，并且将这与所接收的BasicMAC进行比较：值必须相等。
2.如果在之前步骤中没有丢失SUPL INIT，则认为它是可信的，并且SET考虑使用基本重放计数器值。如果基本重放计数器值接近65535=216-1（其未必很高），则SET必须与SLP建立新的SUPL_INIT_ROOT_KEY，以便重置计数器。
6.4给SET提供H-SLP地址
注释:为独立于接入网络的H-SLP提供H-SLP地址是FFS。
通过在UICC中提供H-SLP地址使H-SLP地址对SET可用，如下所述得到SET或者默认H-SLP地址。该地址必须是FQDN的形式，并且应该通过SET的本地网络安全地提供。
6.4.13GPP2SET
对于3GPP2SET，必须在UIM或者R-UIM中安全地提供H-SLP地址。
6.4.23GPP SET
3GPP SET必须读取H-SLP地址（以FQDN的形式）作为在WAP PROVCONT中所指定的“APPADDR/ADDR”字符下的参数“ADDR”。另外，如在关于适应3GPP的UICC（USIM/SIM）的OMA智能卡供应规范中或者在SET的等效安全区域中所定义的，必须将H-SLP地址安全地存储在发起程序文件中。SET必须支持OMA智能卡供应机制，以便读取H-SLP地址。USIM/SIM应用或者存储H-SLP地址的SET中的发起程序文件必须是用户不可改变的。如果在UICC（USIM/SIM）中配置H-SLP地址，SET必须首先读取在UICC中提供的H-SLP地址。如果在UICC中不提供H-SLP地址，则SET可以从SET上的安全区域读取H-SLP地址。
在SET中提供H-SLP地址:如果将H-SLP地址存储在SET上的安全位置中，就必须使用OMA设备管理V1.2或者稍后提供它。如果使用OMA DM提供H-SLP地址，SET必须基于在TLS握手期间通过DM服务器呈现的服务器侧的认证对OMA DM服务器进行认证。如果SET支持H-SLP地址的存储，它就不必依赖在章节6.1.4中所提出的认证机制，即基于MSISDN/IP地址映射认证的交替客户端认证，即SET必须依赖如在章节6.1.1中所描述的PSK-TLS相互认证方法。
H-SLP地址的自动配置:如果不能在UICC的安全存储区域（USIM/SIM）中或者在SET的安全区域中找到H-SLP地址，SET就必须基于存储在 USIM/SIM中的IMSI配置SET中的默认H-SLP地址。
在UICC的安全存储区域（USIM/SIM）中或者在SET的安全区域中找到H-SLP地址、但是其使用导致认证失败同时发起SUPL会话的情况下，SET必须基于存储在USIM/SIM中的IMSI配置SET中的默认H-SLP地址。
配置默认H-SLP地址的机制定义如下。
请注意，从3GPP GBA规范中取得并且为对（基于FQDN）配置H-SLP地址的SUPL使用情况采用下列例子。默认配置机制的实现不需要3GPP GBA规范的实现。给出下面的例子以便仅对方法进行说明，并且可以独立于GBA实现。
基于IMSI的H-SLP配置:
步骤1）取决于使用2位还是3位数字MNC并且将它们分成MCC和MNC，取IMSI的前5位或6位数字；如果MNC是2位数字，则可以在开始处添加零；
步骤2）使用在步骤1中得到的MCC和MNC创建“mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org”域名；将标志“h-slp.”添加到域名的开始处。
示例1:如果使用的IMSI是“234150999999999”，其中，MCC=234、MNC=15并且MSIN=0999999999，则H-SLP地址将是“h-slp.mnc015.mcc234.pub.3gppnetwork.org”。
如果SET在上电期间或者在上电之后检测到新的IMSI，就必须从SET移除所有之前的H-SLP设置。更具体地说，必须移除任何存储在SET中的H-SLP地址。
在改变IMSI的情况下，SET必须首先从UICC（USIM/SIM）读取H-SLP地址。如果UICC（USIM/SIM）上没有存储H-SLP地址，SET可以检查H-SLP地址是否存储在SET上。如果在UICC或者SET上没有找到H-SLP地址，则如上所述，SET必须基于新的IMSI配置默认H-SLP地址。
实现必须确保在SET安装制造商软件之后不能经由下载到SET的应用改变H-SLP的地址。
下列流程示出了H-SLP地址存储。
1.开始。转到2。
2.IMSI是否改变？如果是，转到3。如果否，跳过3并且直接转到4。
3.从SET中清除H-SLP。转到4。
4.UICC是否包含H-SLP地址？如果否，转到5。如果是，转到9。
5.是否支持SET上的H-SLP地址如果否，转到9。如果是，转到6。
6.是否在SET中提供了H-SLP地址？如果否，转到7。如果是，转到8。
7.从IMSI创建H-SLP地址。转到10。
8.从SET中读取设置。转到10。
9.从UICC中读取H-SLP地址。转到10。
10.使用H-SLP地址创建到H-SLP的TLS连接。转到11。
11.认证是否成功？如果否，转到12。如果是，转到14。
12.是否从IMSI创建H-SL地址？如果否，转到7。如果是，转到13。
13.中止SUPL会话并且结束。
14.运行SUPL会话并且结束。
6.4.3基于WIMAX的部署
当SET连上WiMAX网络时，它可以经由OMA DM接收更新的H-SLP地址。当以安全方式将H-SLP地址提供给WiMAX终端时，必须将它存储在受保护的环境中。
6.5机密性和数据完整性协议
可以使用TLS1.1或者PSK-TLS提供SET和SLP之间的机密性和数据完整性。必须在SET和SLP之间的TLS或者PSK-TLS会话内递送除了“SUPLINIT”之外的所有SUPL消息。
章节6.1.1.3提供了用于确定SUPL3.0部署中的哪个实体使采用服务器证书认证的TLS和/或TLS-PSK作为强制或者可选的细节。
6.5.1采用服务器证书的TLS
采用服务器证书的TLS的实现可以符合下列澄清，并且TLS1.1的WAP简介具有下列澄清：
SET可以实现:
·TLS_RSA_WITH_AES_128_CBC_SHA.
对于优选附加密码组的SET实现，SET应该实现:
·TLS_RSA_WITH_3DES_EDE_CBC_SHA.
支持采用服务器证书的TLS1.1的SLP可以实现下列密码组:
·TLS_RSA_WITH_3DES_EDE_CBC_SHA.
·TLS_RSA_WITH_AES_128_CBC_SHA.
对于支持具有服务器证书的TLS1.1的、优选支持空加密的SLP实现，SLP可以实现TLS_RSA_WITH_NULL_SHA。注意到，由于它不提供任何机密性保护，所以不推荐使用TLS_RSA_WITH_NULL_SHA。然而，它仍然提供认证和完整性保护。
支持采用服务器证书的TLS1.1的SLP和SET可以支持TLS1.1的WAP认证简介。
6.5.2TLS-PSK
TLS-PSK实现可以符合用于TLS握手的PSK-TLS，具有为TLS1.1定义的大量密码。
支持TLS-PSK的SET可以实现:
·TLS_PSK_WITH_AES_128_CBC_SHA
对于支持优选附加密码组的TLS-PSK的SET实现，SET应该实现:
·TLS_PSK_WITH_3DES_EDE_CBC_SHA
可以通过SLP实现下列密码组:
·TLS_PSK_WITH_AES_128_CBC_SHA
对于支持优选附加密码组的TLS-PSK的SLP实现，SLP应该实现：
·TLS_PSK_WITH_3DES_EDE_CBC_SHA
可以通过支持无代理模式的SPC实现下列密码组：
·TLS_PSK_WITH_AES_128_CBC_SHA
对于支持优选附加密码组的无代理模式的SPC实现，SPC应该实现：
·TLS_PSK_WITH_3DES_EDE_CBC_SHA
6.6DCert方法和用户绑定
DCert方法对SET手持装置进行认证，但是（不像GBA、SEK和ACA方法）不执行依靠接入网络认证的任何认证。
如果SLP为相互认证使用DCert方法，则SLP运营商需要某些其它机制验证哪个SUPL用户应该与SET相关联。使用术语“用户绑定”描述将SUPL用户与SET标识相关联。
如果SET所有者改变，则联系SLP运营商释放用户绑定是现有SUPL用户的责任。
虽然在章节6.6.1中示出了一种可能过程，但是SUPL3.0不指定用户绑定过程。一些SLP可以将用户绑定过程合并为SLP运营商所提供的其它服务的一部分。在其它情况下，用户绑定可以是分配链条的一部分。
SLP运营商可以使用他们选择的任何“用户绑定”过程，但是应该考虑下列点:
·必须将SUPL用户认证为用户绑定过程的一部分。
○对SUPL用户认证失败将允许服务盗用，并且允许威胁代理误导SLP关于所识别SUPL用户的定位。
○我们推荐SLP运营商为用户认证应用他们现有的机制和策略。
·必须将SET认证为用户绑定过程的一部分。
○原因是微妙的。假定威胁代理希望追随Alice的运动并且Alice拥有具有SET标识“SET_ID_A”的SET。威胁代理注册为合法SUPL用户，并且在对她自己进行认证之后，要求拥有具有SET标识“SET_ID_A”的SET。如果SLP运营商将该SET与威胁代理的账号相关联，则威胁代理可以授权它们自己从SLP（经由网络发起的会话）获得周期性的定位更新。然而，由于Alice正在使用SET，威胁代理实际上得到Alice的定位更新。由于SLP运营商预期保持Alice的定位是秘密的，所以防止这种攻击是在SLP运营商的感兴趣范围内。
6.6.1示例用户绑定过程
主要为具有网页浏览能力的SET设计了DCert方法：例子包括智能电话、写字板或者触摸屏多媒体播放器。
这种SET可以使用下列机制:
1.SLP运营商提示SUPL用户在使用SET时连接到SLP所拥有的网页服务器的URL。
2.用于在使用SET时连接到网站（可能是WAP）。
3.网页服务器和SET执行TLS。
a.网页服务器提供服务器证书，并且请求客户端认证。网页服务器的认证可以与用于SUPL服务的SLP服务器证书的认证不同。
b.SET可以对网页服务器进行认证。
c.SET使用SET的设备证书向网页服务器认证。
d.网页服务器现在已经认证安全信道与设备证书中的SET标识（例如，IMEI、MEID或者序列号）相关联。
4.SUPL用户执行与网站的一些认证（在范围外）。例如，网页服务器可以请求SLP专用的用户名/密码，或者联合用户名/密码或者诸如地址、出生日期等的其它用户细节。
5.SLP运营商现在将用户与设备标识安全地相关联，并且应该将该关联存储在SLP中。
附加实施例8
SUPL3.0已经定义了模式A和模式B SUPL INIT保护。模式A保护需要SLP具有在安全ULP会话期间将共享密钥发送到SET的能力。该实施例描述了共享密钥参数，并且指示将要使用哪条ULP消息请求和发送共享密钥。因此，可以将该实施例合并入SUPL3.0中，并且章节号可以称为SUPL3.0章节。
6.3.3SUPL INIT/REINIT消息的端到端保护
注释:SUPL INIT消息的端到端保护仅应用于非紧急SUPL INIT/REINIT消息。
章节6.3.3中的过程仅应用于是D-SLP和H-SLP的SLP；过程不应用于 E-SLP。
用于SUPL INIT和SUPL REINIT消息的端到端保护的过程在SUPL INIT和SUPLREINIT消息之间没有区别，-对SUPL INIT和SUPL REINIT消息进行处理就好像它们是相同类型的消息。为简便起见，我们将这些过程称为SUPL INIT保护过程–使用SUPL INIT保护过程对SUPL INIT和SUPLREINIT消息进行处理。
在本说明书中提供了端到端SUPL INIT保护的三种选项：空、模式A和模式B。
·空SUPL INIT保护不提供端到端完整性保护、不提供端到端重放保护并且不提供机密性保护。在章节6.3.4中描述了用于空SUPL INIT保护的过程。
·模式A SUPL INIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式A SUPL INIT保护使用SLP在安全ULP会话期间发送给SET的共享密钥。在章节6.3.5中描述了用于模式A SUPL INIT保护的过程。
·模式B SUPL INIT保护使用默认算法提供端到端完整性保护和端到端重放保护。模式B SUPL INIT保护使用利用合适的基于PSK的方法（GBA或者SEK方法）得到的共享密钥。在章节6.3.6中描述了用于模式B SUPL INIT保护的过程。
对于保护级的优先权次序如下：
■空SUPL INIT保护具有最小优先权。
■模式A SUPL INIT保护具有比空SUPL INIT保护更高的优先权。
■模式B SUPL INIT保护具有比模式A SUPL INIT保护更高的优先权。
在SUPL INIT消息中，根据当前保护级分配保护等级参数（在下表中）。
注释:书写本说明书以便允许在未来修订中添加更先进的保护级别。该先进保护可以允许为了使SUPL INIT/REINIT安全的其它方式的协商（例如，允许加密并且允许算法协商）。包括保护等级参数以便帮助SET确定它是否能够解析SUPL INIT/REINIT消息：为了扩展，需要保护等级参数。
SUPL INIT/REINIT消息具有为了包括安全参数呈现的保护器参数：在下表中指定了保护器参数的呈现。
SUPL INIT保护等级参数值以及SUPL INIT和SUPL REINIT消息中保护器参数的呈现
支持基于ACA的方法的SET或D-SLP或H-SLP必须支持空SUPL INIT保护。
所有的SET应该支持模式A SUPL INIT保护过程。
D-SLP或者H-SLP可以支持模式A SUPL INIT保护过程。
SET或者D-SLP或者支持基于PSK方法的H-SLP必须支持模式B SUPL INIT保护过程。
E-SLP实体不包括在当前定义的SUPL INIT保护中。
6.3.3.1协商SUPL INIT保护级别
下列过程仅应用于是D-SLP和H-SLP的SLP；过程不应用于E-SLP。
对如何协商SUPL INIT保护等级的非正式说明如下：
1.当不存在有效的SUPL_INIT_ROOT_KEY时（例如，在上电时或者当SUPL_INIT_ROOT_KEY的有效期过期时），SET必须应用 空SUPL INIT保护。初始保护等级总是空SUPLINIT保护。在该状态下，SET对所有的SUPL INIT/REINIT消息进行处理，即不静静地丢弃任何消息。如果采用错误条件对SUPL INIT/REINIT消息进行解析，SET就将错误消息发送到SLP。
2.如果SET具有有效的SUPL_INIT_ROOT_KEY和对于特定SLP已经使用模式A或者模式B SUPL INIT保护协商的有效的重放计数器，则SET对所有SUPL INIT/REINIT消息进行处理，SLP从其中使用经协商的模式（模式A或者模式B）。
3.当SET建立到SLP的相互认证的安全连接时，
a.如果为相互认证使用基于PSK的方法（GBA或者SEK），则模式B SUPL INIT保护应用，并且在PSK-TLS握手中交换的B-TID对应于Ks（在3GPP和3GPP2部署中将用作Ks_NAF）或者可以用于得到将在3GPP和3GPP2部署中用作Ks_NAF的SUPL_INIT_ROOT_KEY的SEK。在模式B SUPL INIT保护中使用该Ks_NAF或者SEK以及相关联的B-TID，直到下列条件之一为止：
i.密钥过期，在该情况下，SET和SLP回复空SUPL INIT保护，
ii.SET和SLP在非紧急会话中使用ACA方法，在该情况下，如在以下步骤3b中所讨论的，SET和SLP回复模式A或者空SUPL INIT保护，或者
iii.SET和H-SLP使用GBA或者SEK的引导程序重新协商方法使用新的B-TID建立TLS，在该情况下，现在B-TID和相应的Ks_NAF或SEK用于模式B SUPL INIT保护。
b.否则，SET和SLP使用DCert或ACA方法建立安全连接。
i.如果SET不具有有效的SUPL_INIT_ROOT_KEY，则它在安全会话建立之后携带SET能力参数的下一条ULP消息中的SET性能（sUPLINITRootKeyStatus=“invalidSUPLINITRootKey”）中将此指示给SLP。
1.如果SLP支持模式A SUPL INIT保护，则SLP在下一条SUPL END消息中执行模式ASUPL_INIT_ROOT_KEY建立过程（章节6.3.5.2）。成功的模式A SUPL_INIT_ROOT_KEY建立过程向SET指示模式A SUPL INIT保护应用。直到成功的模式A SUPL_INIT_ROOT_KEY建立过程出现为止，SET应该使用空SUPL INIT保护。
注释:用于更新SUPL_INIT_ROOT_KEY的策略是SLP运营商的决定。
2.如果SLP不支持模式A SUPL INIT保护（或者在该特定时间不支持模式A SUPLINIT保护），则SLP不发送模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和模式A密钥有效期参数，其指示SET应该使用空SUPL INIT保护。
ii.如果SET具有有效的SUPL_INIT_ROOT_KEY，但是不具有有效的临时模式A密钥标识符或者已经丢失关于重放保护的同步，则它就在安全会话建立之后携带SET能力参数的下一条ULP消息中的SET性能（sUPLINITRootKeyStatus=“outofsyncSUPLINITRootKey”）中将此指示给SLP。
1.在下一条SUPL END消息中执行模式A重新同步过程（章节6.3.5.3）。成功的模式A重新同步过程向SET指示模式A SUPL INIT保护应用。直到成功的模式A重新同步过程出现为止，SET应该使用空SUPL INIT保护。
2.如果SLP不支持模式A SUPL INIT保护（或者在该特定时间不希望支持模式ASUPL INIT保护），则SLP不执行模式A重新同步（见章节6.3.5.3），其指示SET应该使用空SUPL INIT保护。
注意到，这意味着每次SET建立到SLP的新的TLS连接，就对保护等级进行重新协商。
6.3.3.2从SLP角度的协商
如果使用GBA或者SEK方法对与SET的最新IP会话进行认证，并且SLP具有当前B-TID和用于SET的相关联密钥，则
■如果B-TID是用于使用GBA获得的密钥，则SLP分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成
○ FQDN应该是SLP_FQDN
○在OMNA注册中[OMNA]定义了应该用于SUPL_INIT保护的GBA Ua安全协议标识符
■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK
■假定没有协商任何其它SUPL INIT保护，则SLP为该SET分配模式B SUPL INIT保护等级。
否则，如果SLP具有有效的模式A密钥标识符以及用于SET的相关联密钥，则SLP为该SET分配模式A SUPL INIT保护等级。
如果没有分配其它保护级别，则SLP为该SET分配空SUPL INIT保护等级。SLP应用对应于当前所分配的SUPL INIT/REINIT保护级别的过程（为了在递送之前处理SUPL INIT/REINIT消息）。这包括为SUPL INIT消息中的保护等级参数分配合适的值。
6.3.3.3从SET角度的协商
如果使用GBA或者SEK方法对与SLP的最新IP会话进行认证，并且SET具有当前B-TID和用于该IP会话的相关联密钥，则
■如果B-TID是用于使用GBA获得的密钥，则SET分配SUPL_INIT_ROOT_KEY是对应于最新B-TID的Ks_（int/ext_）NAF，并且如下生成
○ FQDN应该是SLP_FQDN
○在OMNA注册中[OMNA]定义了应该用于SUPL_INIT保护的GBA Ua安全协议标识符[3GPP24.109]
■如果B-TID是用于使用SEK方法获得的密钥，则SUPL_INIT_ROOT_KEY是如在6.1.2.1.2中所定义的SEK
■假定没有协商任何其它SUPL INIT保护，则SET分配模式B SUPL INIT保护等级。
否则，如果SET具有有效的模式A密钥标识符、临时模式A密钥标识符以及用于SLP的相关联SUPL_INIT_ROOT_KEY，则SET为该SLP分配模式A SUPL INIT保护等级。
如果没有分配其它保护级别，则SET分配空SUPL INIT保护级别。
SET应用对应于当前所分配的SUPL INIT保护的过程（为了处理所接收的SUPLINIT/REINIT消息）。
6.3.3.4例外过程
如果SET确定SET内部的SUPL INIT保护参数已经被破坏，则SET必须与SLP建立TLS会话：
·如果使用GBA认证，则SET必须发起GBA引导程序以便建立新的密钥；
·对于使用SEK方法的SET，如在章节6.1.2.1.2中所定义的，SET必须发起SEK引导程序以便使能新的密钥；
·否则，SET跟随在章节6.3.3.1的步骤3.b中的过程之后。如果SLP丢失安全内容（例如，大量数据丢失），则SLP将没有办法发起定位行为。当Ks_NAF或SEK过期或者SET连接到SLP时，将重建内容。为了防止这种“封闭窗口”，SLP应该确保以充分从该情景中恢复的冗余存储所有SUPL INIT保护安全内容信息。
6.3.3.5用于在SET处对SUPL INIT消息进行处理的一般过程
SET应用下列过程，以便确定如何对所接收的SUPL INIT消息进行处理。
1.SET对发送SIP（发送SUPL INIT消息的SLP）进行识别。
a.如果在SUPL INIT消息中存在D-SLP FQDN参数，则SET应该使用该参数对发送SLP进行识别。
i.如果SET与所识别的D-SLP没有现有的关系，则SET应该静静地丢弃SUPL INIT消息并且退出当前过程。
ii.否则，SET继续进行到步骤2。
b.如果在SUPL INIT消息中不存在D-SLP FQDN参数，则SET将发送SLP识别为SET的H-SLP。
2.SET基于为发送SLP分配的SUPL INIT保护等级执行初始过滤：
a.如果为发送SLP分配空SUPL INIT保护，则SET执行空SUPL INIT保护过程，并且退出当前过程。
b.如果为发送SLP分配模式A或者模式B SUPL INIT保护，则
i.如果SUPL INIT消息不包含保护器参数，则SET静静地丢弃SUPL INIT消息并且退出当前过程。
ii.如果SUPL INIT消息包含保护器参数，则SET分别执行章节6.3.5或者章节6.3.6中合适的模式A或模式B SUPL INIT保护过程。SET使用保护器参数中的密钥标识符参数，以便识别为了处理SUPL INIT消息使用与发送SLP相关联的哪个SUPL INIT ROOT密钥。
6.3.5用于模式A SUPL INIT保护级别的规范
6.3.5.1用于模式A SUPL INIT保护的密钥标识符
模式A SUPL INIT保护使用使用可以与SUPL INIT/REINIT消息一起发送的两个密钥标识符：模式A密钥标识符和临时模式A密钥标识符。
·模式A密钥标识符是全球唯一的、与SUPL_INIT_ROOT_KEY相关联的长期密钥标识符。仅当SLP为SUPL_INIT_ROOT_KEY提供新的值时，SLP给SET提供新的模式A密钥标识符。
·临时模式A密钥标识符是与模式A密钥标识符相关联的短期标识（假名）。临时模式A密钥标识符在临时模式A密钥标识符有效期间可以是全球唯一的。如在章节6.3.5.5和6.3.5.6中所述，SET和SLP对临时模式A密钥标识符的值进行同步。
典型地，SLP将使用临时模式A密钥标识符作为基本SUPL INIT保护器中的密钥标识符。随后，SET使用临时模式A密钥标识符确定应该使用哪个SUPL_INIT_ROOT_KEY验证基本SUPL INIT保护器。
典型地，不在SUPL INIT/REINIT消息中发送模式A密钥标识符，因为这将允许观测者将多条SUPL INIT/REINIT消息与公共SET用户相关联。临时模式A密钥标识符的目的是防止威胁代理使用模式A密钥标识符将多条SUPL INIT/REINIT消息与SET用户相关联。仅SLP和SET应该能够将临时模式A密钥标识符与模式A密钥标识符相关联。改变临时模式A密钥标识符的频率主要是SET用户的决定。SLP可以基于SLP策略选择为临时模式A密钥标识符建立新的值。
然而，存在SLP可能希望使用长期模式A密钥标识符作为基本SUPL INIT保护器中的密钥标识符的情况。例如，假定SET还没有使用基本SUPL INIT保护器中的临时模式A密钥标识符对多条SUPL INIT/REINIT消息作出响应。SLP可能关心SET已经丢失关于临时模式A密钥标识符的同步。SET和SLP更可能保持在长期模式A密钥标识符上的同步。因此，SLP可以使用基本SUPL INIT保护器中的模式A密钥标识符发送SUPL INIT/REINIT消息，以确保同步丢失不防止SET验证SUPL INIT/REINIT消息。
6.3.5.2模式A SUPL_INIT_ROOT_KEY建立过程
通过SLP（在安全SUPL会话中发送给SET的SUPL END消息中）发送新的模式A密钥标识符、临时模式A密钥标识符、SUPL_INIT_ROOT_KEY和模式A密钥有效期参数建立对于SUPL_INIT_ROOT_KEY的值。如果递送成功，则SLP和SET认为该模式A SUPL_INIT_ROOT_KEY建立过程是成功的。模式A密钥有效期参数包含当密钥停止有效时的UTC时间。
6.3.5.3模式A重新同步过程
SLP使用下列步骤与SET建立用于临时模式A密钥标识符的新的值：
1.SLP将当前模式A密钥标识符和新的临时模式A密钥标识符参数发送给SET（在安全SUPL会话中发送给SET的SUPL END消息中）。如果递送成功，则SLP认为该模式A重新同步过程是成功的。
2.SET将所接收的模式A密钥标识符与具有SET当前为该SLP分配的有效SUPL_INIT_ROOT_KEY值的模式A密钥标识符进行比较。
a.如果模式A密钥标识符值不同，则这指示在SET上分配的模式A密钥标识符值的破坏，并且执行下列步骤：
i.SET丢弃临时模式A密钥标识符，并且认为该模式A重新同步是失败的。
ii.SET开始章节6.3.3.4中的例外过程。
b.如果所接收的模式A密钥标识符等于有效的模式A密钥标识符，则：
i.SET将新的临时模式A密钥标识符与相应的模式A密钥标识符相关联，
ii.SET认为该模式A重新同步是成功的。
6.3.5.4模式A SUPL INIT保护和基本SUPL INIT保护器
模式A SUPL INIT保护使用如在章节0中所定义的基本SUPL INIT保护器和相关联过程，具有下列附加澄清：
■密钥标识符类型:指示使用模式A密钥标识符还是临时模式A密钥标识符。
■密钥标识符:对应于模式A密钥标识符还是临时模式A密钥标识符作为适合于模式A密钥标识符类型。
■使用SUPL_INIT_Basic_IK=HMAC-SHA256-128（SUPL_INIT_ROOT_KEY,“Mode AIK”）计算BasicMAC，使用与上述密钥标识符相关联的SUPL_INIT_ROOT_KEY。
6.3.5.5SLP过程
仅模式A专用的SLP过程涉及SUPL INIT ROOT KEY建立、SUPL_INIT_ROOT_KEY过期、以及维持SET和SLP之间的同步。
在章节6.3.5.2中指定了模式A SUPL_INIT_ROOT_KEY建立过程。响应于SET的不同步指示（在SET性能（sUPLINITRootKeyStatus=”invalidSUPLINITRootKey”）中）或者SLP的（在范围之外）内部决定，SLP可以执行模式A SUPL_INIT_ROOT_KEY建立过程。也就是说，即使当不存在由SET发送的相应指示时，SLP也可以发送SUPL_INIT_ROOT_KEY（采用相关联参数）。在下列时间早期之后，SUPL_INIT_ROOT_KEY和相关联参数应该停止在SLP中有效
·相关联模式A密钥标识符的有效期，以及
·稍后成功的模式A SUPL_INIT_ROOT_KEY建立的时间（章节6.3.5.2）
在章节6.3.5.3中指定了模式A重新同步过程。响应于SET的不同步指示（在SET性能（sUPLINITRootKeyStatus=”outofsyncSUPLINITRootKey”）中）或者SLP的（在范围之外）内部决定，SLP可以执行模式A重新同步过程。也就是说，即使当不存在由SET发送的相应指示时，SLP也可以发送临时模式A密钥标识符。
在成功的模式A SUPL_INIT_ROOT_KEY建立过程和成功的模式A重新同步过程之后，SLP将基本最后重放计数器重置为0x0000。
6.3.5.6SET过程
仅模式A专用的SET过程涉及SUPL INIT ROOT KEY建立、SUPL_INIT_ROOT_KEY过期、以及维持SET和SLP之间的同步。
在章节6.3.5.2中指定了模式A SUPL_INIT_ROOT_KEY建立过程。SET可 以通过在安全会话建立之后携带SET能力参数的ULP消息中指示它在SET中不具有有效的SUPL_INIT_ROOT_KEY（在SET性能（sUPLINITRootKeyStatus=”invalidSUPLINITRootKey”）中）来尝试触发模式A SUPL_INIT_ROOT_KEY建立过程。
在下列时间早期之后，应该认为所建立的SUPL_INIT_ROOT_KEY和相关联参数在SET中无效。
·相关联模式A密钥标识符的有效期。
·稍后成功的模式A SUPL_INIT_ROOT_KEY建立时间之后5分钟（章节6.3.5.2）。由于使用先前的SUPL_INIT_ROOT_KEY将保护该SUPL INIT消息，所以该时间延迟允许递送在最近的模式A SUPL_INIT_ROOT_KEY建立过程之前发送的任何SUPL INIT消息的递送。
·SET检测到SUPL_INIT_ROOT_KEY、模式A密钥标识符和模式A密钥有效期的值的破坏的任何时间。如果发生破坏，则SET应该开始章节6.3.3.4中的例外过程。
在章节6.3.5.3中指定了模式A重新同步过程。SET可以通过在安全会话建立之后携带SET能力参数的ULP消息中指示在SET中丢失同步（在SET性能（sUPLINITRootKeyStatus=”outofsyncSUPLINITRootKey”）中）来尝试触发模式A重新同步过程。
成功的模式A SUPL_INIT_ROOT_KEY建立过程或者成功的模式A重新同步过程之后，SET清理它的具有为基本重放计数器使用过的值的缓存（由于SLP也将基本重放计数器重置为0x0000）。
6.3.7对于使用基本SUPL INIT保护器的规范
为模式A和模式B SUPL INIT保护使用的基本SUPL INIT保护器包括下列参数：
■密钥标识符类型
■密钥标识符:长度=8个八位字节
■基本重放计数器:长度=2个八位字节
■BasicMAC:长度=4个八位字节.
如下生成BasicMAC参数:
■BasicMAC=HMAC-SHA256-32（SUPL_INIT_Basic_IK,SUPL_INIT/REINIT’），其中
■根据分别用于模式A和模式B SUPL INIT保护的章节6.3.5和6.3.6得到SUPL_INIT_Basic_IK，
■SUPL_INIT/REINIT’对应于SUPL INIT/REINIT消息，分配除了BasicMAC之外的所有参数，并且具有设置为全零的MAC参数，并且
■在[HMAC]中指定HMAC-SHA256-32和HMAC-SHA256-128。
6.1.1.2所支持的认证方法综述（提供信息的）
（1）基于通用引导架构（GBA）具有通用引导架构（GBA）[3GPP33.220]、[3GPP33.222]、[3GPP2S.S0114]、[3GPP24.109]的TLS-PSK。GBA提供了基于使用现存3GPP/3GPP2认证机制得到的共享密钥的相互认证性能
■使用具有通用引导架构（GBA）的TLS-PSK对SET和SLP进行相互认证。
（2）基于SEK（仅可应用于WIMAX SLP）
■使用具有SEK的TLS-PSK对SET和SLP进行相互认证。可以在章节6.1.2.1.2中找到SEK方法的细节。
（3）基于设备证书（DCert）该独立于AN的方法使用具有如下认证的TLS
■RSA服务器证书，以便将SLP授权给SET
■RSA客户端认证，以便将SET授权给SLP
（4）基于可选客户端认证（ACA）这使用具有如下认证的TLS
■RSA认证，以便将SLP授权给SET
■可选的SET到SLP的客户端认证（见章节6.1.4）。在该情况下，SLP通过使承载网络确认与SET标识符（MSISDN等）相关联的IP地址对SET进行认证。
（5）仅SLP这在SLP不可能对SET进行认证的情景中使用。该方法不应该用于非紧急情况。SET不能对该方法和基于ACA的方法作出区分。这使用具有下列认证的TLS
■RSA认证，以便将SLP授权给SET
■不对SET进行认证
6.1.2.1.1支持GBA方法的部署
在支持（GBA[3GPP33.220]、[3GPP24.109]、[3GPP2S.S0109]）的部署的情况下，如下建立共享密钥:
·当SLP从BSF请求密钥材料（为了使IP通信安全并且为了保护SUPL INIT和/或SUPL REINIT）时，SLP也必须请求USS（用户安全设置）。USS必须包括永久用户标识（例如，IMPI、IMSI或者MSISDN）。
·为了使SET和SLP之间的IP通信安全，SET和SLP必须得到共享秘密密钥，并且使用GBA（[3GPP33.220]、[3GPP24.109]、[3GPP33.222]、[3GPP2S.S0109]）根据TLS-PSK工作。SLP必须具有良好定义的指定SLP的域名SLP_Address_FQDN，例如，slp.operator.com。在OMNA注册[OMNA]中定义了应该用于TLS-PSK的GBA Ua安全协议标识符。SLP必须确认BSF所提供的永久用户标识对应于在相应的安全连接上由SLP所接收的SUPL消息中的SET标识。
·对于SUPL INIT和/或SUPL REINIT的MAC保护，根据GBA（[3GPP33.220]、[3GPP2S.S0109]）得到密钥。在OMNA注册[OMNA]中定义了应该用于SUPL INIT保护的GBA Ua安全协议标识符。包括在SUPL INIT消息（或者SUPL REINIT消息）中的basicMAC的密钥标识符必须是从其生成Ks_NAF的Ks的B-TID。注释:典型地，从BSF 对SUPL INIT保护密钥的D/H-SLP请求将与对使IP通信安全的密钥的D/H-SLP请求同时出现。
·SET必须确保总是给它提供了有效的Ks。如果不存在有效的Ks，则SET必须开始GBA引导程序过程以便提供Ks。每次SET检测到新的UICC（USIM/SIM/R-UIM）时，必须建立新的Ks。另外，当Ks_NAF的有效期（由本地网络运营商设置）过期时，SET必须建立新的共享密钥。
10.8SET性能
SET能力参数
9.2.8SUPL END
SUPL END是正常或者异常结束SUPL过程的消息。
SUPL END消息
10.x SUPL INIT密钥响应
在SUPL_INIT_ROOT_KEY建立过程（见章节6.3.5.2）中使用SUPL INIT密钥响应参数，以便将用于模式A SUPL INIT保护的密钥从SLP发送到SET。
SUPL INIT密钥响应
11.4消息扩展（SUPL版本3）
ULP-版本-3-消息-扩展自动定义标志::=
开始
输出
Ver3-SUPL-INIT-扩展,
Ver3-SUPL-START-扩展,
Ver3-SUPL-POS-INIT-扩展,
Ver3-SUPL-END-扩展,
Ver3-SUPL-RESPONSE-扩展,
Ver3-SUPL-TRIGGERED-RESPONSE-扩展,
Ver3-SUPL-TRIGGERED-START-扩展,
Ver3-SUPL-TRIGGERED-STOP-扩展,
Ver3-SUPL-SET-INIT-扩展,
Ver3-SUPL-NOTIFY-扩展,
Ver3-SUPL-NOTIFY-RESPONSE-扩展,
Ver3-SUPL-REPORT-扩展,
QoP性能,
相对定位性能,
城市定位性能;
输入
Ver,QoP,FQDN
来自ULP-分量
圆形区域，椭圆形区域，多边形区域
来自Ver2-ULP-分量
定位协议版本3GPP,定位协议版本3GPP2
来自ULP-版本-2-参数-扩展
定位协议版本OMA
来自ULP-版本-3-参数-扩展
定位有效负载
来自SUPL-POS
通知
来自SUPL-INIT
会话ID
来自ULP-分量
通知响应
来自SUPL-NOTIFY-RESPONSE
最大会话数目,会话列表
来自SUPL-REPORT
OMA-LPPe-相对定位,
OMA-LPPe-参考点唯一ID,
OMA-LPPe-城市定位
FROM OMA-LPPE;
[为简便起见移除了一些不改变的部分]
[为简便起见移除了一些不改变的部分]
结束
11.6 参数扩展（SUPL版本3）
ULP-版本-3-参数-扩展 自动定义标志::=
开始
输出
Ver3-定位协议-扩展,
Ver3-SET性能-扩展,
Ver3-SLP性能-扩展,
Ver3-触发参数-扩展,
Ver3-所支持的服务-扩展;
输入
QoP性能,
相对定位性能,
城市定位性能，
来自ULP-版本-3-消息-扩展;
Ver3-定位协议-扩展 ::= 序列{
定位协议版本LPPe 定位协议版本OMA 可选的,
...}
SUPLINIT根密钥状态::=列举{无效SUPLINIT根密钥（0）,不同步SUPLINIT根密钥（1）,...}
[为简便起见移除了一些不改变的部分]
结束
附加实施例9
保护等级参数的预先定义可能不反映基本保护已经改变到模式A保护和模式B保护的事实（模式B保护与之前的基本保护是相同的）。还可以更新预先的ASN.1定义。因此，可以将下列提议合并到SUPL 3.0内，以便修改章节10.25反映模式A和模式B保护，并且也更新ASN.1章节11.4（可以将章节号称为SUPL 3.0章节）。
10.22保护级别
保护等级参数定义了对于SUPL INIT/SUPL REINIT消息的保护级别。
11.3消息扩展（SUPL版本2）
ULP-版本-2-消息-扩展自动定义标志::=
开始
输出
Ver2-SUPL-INIT-扩展,
Ver2-SUPL-START-扩展,
Ver2-SUPL-RESPONSE-扩展,
Ver2-SUPL-POS-INIT-扩展,
Ver2-SUPL-POS-扩展,
Ver2-SUPL-END-扩展;
输入
SLP地址,位置,Ver
来自ULP-分量
SET性能
来自SUPL-START
所支持的网络的信息，GNSS定位技术，多定位Id，UTRAN-GPS参考时间结果,UTRAN-GANSS参考尸检结果,UTRAN-GPS参考时间辅助,UTRAN-GANSS参考时间辅助,SPCSET密钥,SPCTID,SPCSET密钥有效期,第三方,应用ID
来自Ver2-ULP-分量
触发类型
来自SUPL-TRIGGERED-START
Ver3-保护级别-扩展
来自ULP-版本-3-参数-扩展;
[为简便起见移除了一些不改变的部分]
保护级别::=列举{
空保护（0）,基本保护（1）,...,ver3-模式A保护（2）,ver3-模式B
保护（3）}–基本保护（1）不可用于SUPL 3.0中
[为简便起见移除了一些不改变的部分]
结束
11.6参数扩展（SUPL版本3）
ULP-版本-3-参数-扩展自动定义标志::=
开始
输出
Ver3-定位协议-扩展,
Ver3-SET性能-扩展,
Ver3-SLP性能-扩展,
Ver3-触发参数-扩展,
Ver3-所支持的服务-扩展,
Ver3-保护级别-扩展;
输入
QoP性能,相对定位性能,城市定位性能来自ULP-版本-3-消息-扩展;
[为简便起见移除了一些不改变的部分]
密钥标识符类型::=列举{
模式A密钥标识符（0）,临时模式A密钥标识符（1）, 模式B密钥标识符（2）,...}
结束
本领域的技术人员将进一步意识到，可以将结合这里所公开的实施例描述的各种说明性逻辑块、配置、模块、电路和算法步骤实现为电子硬件、通过诸如硬件处理器的处理设备执行的计算机软件、或者二者的组合。上文一般以它们的功能的形式描述了各种说明性组件、块、配置、模块、电路和步骤。将该功能实现为硬件还是可执行软件取决于特定的应用和施加在整个***上的设计约束。对于每个特定应用，熟练的技术人员可以以不同方式实现所描述的功能，但是不应该将该实现决定解释为造成偏离本公开内容的范围。
可以将结合在这里所公开的实施例描述的方法或算法的步骤直接具体化在硬件、通过处理器执行的软件模块、固件、或者其组合中。软件或者逻辑块可以驻留在诸如随机访问存储器（RAM）、磁抗随机访问存储器（MRAM）、旋转-扭矩传递MRAM（SIT-MRAM）、闪存、只读存储器（ROM）、可编程只读存储器（PROM）、可擦除可编程只读存储器（EPROM）、电可擦除可编程只读存储器（EEPROM）、寄存器、硬盘、可移动盘、紧密光盘只读存储器（CD-ROM）、数字多用光盘（DVD）、蓝光光盘、或者本领域中已知的任何其它形式的存储媒体的非易失性存储媒体中。也应该将上述组合包括在计算机可读媒体的范围内。示例包括采用数据结构编码的计算机可读媒体和采用计算机程序编码的计算机可读媒体。计算机可读媒体可以表现为制造商品的形式。将示例性存储媒体连接到处理器，使得处理器可以从存储媒体读取信息，并且将信息写入存储媒体。可替换地，可以将存储媒体集成到处理器。处理器和存储媒体可以驻留在专用集成电路（ASIC）中。ASIC可以驻留在计算设备或者用户终端中。可替换地，处理器和存储媒体可以作为分立组件驻留在计算设备或者用户终端中。因此，取决于应用，可以通过各种方式实现在这里所描述的方法。例如，可以在硬件、固件、软件、或者其组合中实现这些方法。
另外，或者作为对ASIC和处理器的替代，硬件实现可以包括数字信号处理器件（DSPD）、可编程逻辑器件（PLD）、现场可编程门阵列（FPGA）、处理器、控制器、微控制器、微处理器、电子器件、设计为执行在这里所描述的功能的其它电子单元、或者其组合。在这里，术语“控制逻辑”包含通过软件、硬件、固件或者组合实现的逻辑。
对于包括固件和/或软件的实现，可以采用执行在这里所述功能的模块（例如，过程、函数等）实现方法。可以使用任何可触摸收录指令的机器可读媒体实现在这里所述的方法。例如，可以将软件代码存储在存储器中，并且通过处理单元执行。可以在处理单元内或者处理单元外部实现存储器。如在这里所使用的，术语“存储器”是指任何类型的长期、短期、易失、非易失、或者其它存储器件，并且不限于任何特定类型的存储器或者存储器数目、或者在其上存储存储器的媒体类型。在包括固件和/或软件的实现中，可以将函数作为一条或多条指令或代码存储在计算机可读媒体上。
可以结合Wi-Fi/WLAN或者其它无线网络实现本公开内容。除了Wi-Fi/WLAN信号之外，无线/移动台还可以从卫星接收信号，其可以来自全球定位***（GPS）、伽利略、GLONASS、NAVSTAR、QZSS、使用来自这些***的组合的卫星的***、或者将来开发的任何SPS，在这里一般将每个称为卫星定位***（SPS）或者GNSS（全球导航卫星***）。还可以结合伪星或者包括伪星的***的组合实现本公开内容。可以结合毫微微蜂窝或者包括毫微微蜂窝的***的组合实现本公开内容。
可以结合诸如无线广域网（WWAN）、无线局域网（WLAN）、无线个域网（WPAN）等的各种无线通信网络实现本公开内容。术语“网络”和“***”通常可互换使用。通常可互换使用术语“位置”和“定位”。WWAN可以是码分多址（CDMA）网络、时分多址（TDMA）网络、频分多址（FDMA）网络、正交频分多址（OFDMA）网络、单载波频分多址（SC-FDMA）网络、长期演进（LTE）网络、WiMAX（IEEE802.16）网络等。CDMA网络可以实现诸如cdma2000、宽带CDMA（W-CDMA）等的一种或多种无线电接入技术（RAT）。Cdma2000包括IS-95、IS-2000和IS-856标准。TDMA网络可以实现全球移动通信***（GSM）、数字先进移动电话***（D-AMPS）、或者某些其它RAT。在来自名为“第三代合作伙伴计划”（3GPP）的联盟的文档中描述了GSM和W-CDMA。在来自名为“第三代合作伙伴计划2”（3GPP2）的联盟的文档中描述了cdma2000。3GPP和3GPP2文档是公开可用的。WLAN可以是IEEE802.11x网络，并且WPAN可以是蓝牙网络、IEEE802.15x、或者某些其它类型的网络。还可以结合WWAN、WLAN和/或WPAN的任意组合实现该技术。
典型地，卫星定位***（SPS）包括发射机***，安置其使得实体能够至少部分基于从发射机接收的信号确定它们在地球表面或者之上的位置。典型地，该发射机发送采用具有一组码片的重复伪随机噪声（PN）码标记的信号，并且可以位于基于地面的控制站、用户装置和/或太空交通模块上。在具体示例中，这种发射机可以位于地球轨道人造卫星（SV）上。例如，在诸如全球定位***（GPS）、伽利略、Glonass或者Compass的全球导航卫星***（GNSS）星座中的SV可以发送采用与星座中的其它SV所发送的PN码不同的PN码标记的信号（例如，为GPS中的每个卫星使用不同的 PN码，或者在Glonass中在不同频率上使用相同码）。根据某些方面，在这里所提出的技术不限于用于SPS的全球***（GNSS）。例如，在这里所提供的技术可以应用于各种地域性***和/或各种增加的***（例如，基于卫星的增加***（SBAS）），或者使得能够在各种地域性***中和/或各种增加的***使用，q其中，地域性***诸如日本的准天顶卫星***（QZSS）、印度的印度区域导航卫星***（IRNSS）、中国的北斗等，增加的***可以与一个或多个全球和/或区域导航卫星***相关联，或者否则使得能够与一个或多个全球和/或区域导航卫星***一起使用。通过举例但不是限制的方式，SBAS可以包括提供完整性信息、微分修正等的增加的***，诸如广域增加***（WAAS）、欧洲相对地球静止导航覆盖服务（EGNOS）、多功能卫星增加***（MSAS）、GPS辅助Geo增加导航或者GPS和Geo增加导航***（GAGAN）等。因此，如在这里所使用的，SPS可以包括一个或多个全球和/或区域导航卫星***和/或增加***的任意组合，并且SPS信号可以包括SPS、类SPS、和/或与该一个或多个SPS相关联的其它信号。
可以与利用伪星或者卫星和伪星组合的定位确定***一起使用方法。伪星是基于地面的发射机，其广播在L频带（或者其它频率）载波信号上调制的PN码或者其它距离修正码（类似于GPS或者CDMA蜂窝信号），可以将其与GPS时间同步。可以给每个这种发射机分配唯一的PN码，以便允许通过远程接收机进行识别。伪星在诸如在隧道、矿井、大楼、市内峡谷、或者其它封闭区域中来自轨道卫星的信号可能是不可用的情况下是有用的。伪星的另一种实现已知为无线电信标。如在这里所使用的，术语“卫星”旨在包括伪星、伪星等价物、或者可能其它。如在这里所使用的，术语“SPS信号”旨在包括来自伪星或者伪星等价物的像SPS的信号。
移动台（例如，MS或者STA）是指诸如蜂窝或者其它无线通信设备、个人通信***（PCS）设备、个人导航设备（PND）、个人信息管理器（PIM）、个人数字助理（PDA）、膝上型电脑、平板电脑、上网本、智能本或者其它能够接收无线通信和/或导航信号的合适的移动设备的设备。术语“移动台”还旨在包括诸如通过短距离无线、红外、有线连接、或者其它连接与个人导航设备（PND）进行通信的设备——无论在设备或者在PND处是否出现卫星信号接收、辅助数据接收和/或关于定位的处理。同时，“移动台”旨在 包括包含无线通信设备、计算机、膝上型电脑等的所有设备，其能够诸如经由因特网、Wi-Fi或者其它网络与服务器进行通信，并且无论在设备处、在服务器处、或者在与网络相关联的另一个设备处是否出现卫星信号接收、辅助数据接收和/或关于定位的处理。也将上述的任何可操作组合视为“移动台”。术语“移动台”和“移动设备”通常可互换使用。
本公开内容包括示例实施例，然而，可以使用其它实现。指定某物是“最优的”、“所需的”或者其它指定不指示当前公开仅适用于最优***、或者“所需的”要素存在的***（或者由于其它指定的其它限制）。这些指定仅指特别描述的实现。当然，许多实现是可能的。可以采用除了在这里所讨论的那些协议之外的协议、包括在开发中或者将要开发的协议来使用技术。
提供了所公开实施例的前述说明，以便使得本领域的技术人员能够进行或者使用所公开的实施例。对于本领域的技术人员，对这些实施例的各种修改将是显而易见的，并且在这里定义的原理可以应用于其它实施例，而不脱离本公开内容的范围。因此，本公开内容不是旨在限制于在这里所示的实施例，而是要符合与通过下列权利要求所定义的原理和新颖特征一致的可能最宽范围。

Claims (25)

1.一种认证方法，包括：
在移动设备处接收服务器证书，其中所述服务器证书包括安全用户平面定位(SUPL)定位平台(SLP)的公钥；
在所述移动设备处存储特定于所述移动设备的至少一个安全证书，其中，所述至少一个安全证书包括所述移动设备的设备标识符；以及
将所述至少一个安全证书发送到所述SLP，以基于所述设备标识符与所存储的设备标识符的比较将所述移动设备认证为与SUPL用户相关联；
其中，所述至少一个安全证书是在配置为使用所述SLP的私钥进行解密的消息中发送的。
2.如权利要求1所述的方法，其中，所述至少一个安全证书包括所述移动设备的公钥。
3.如权利要求1所述的方法，其中，所述设备标识符包括所述移动设备的国际移动设备标识(IMEI)、移动站标识(MSID)、以及序列号中的至少一个。
4.如权利要求1所述的方法，其中，所述至少一个安全证书包括所述移动设备的设备证书。
5.如权利要求1所述的方法，其中，所述至少一个安全证书存储在所述移动设备的通用集成智能卡(UICC)、所述移动设备的存储器***分、或者其任意组合处。
6.如权利要求1所述的方法，其中，所述移动设备包括支持SUPL的终端(SET)。
7.如权利要求1所述的方法，其中，所述移动设备经由根据电气与电子工程师协会(IEEE)802.11标准进行操作的网络来将所述至少一个安全证书发送到所述SLP。
8.一种用于无线通信的装置，包括：
非暂时性存储器，其配置为：接收服务器证书，其中所述服务器证书包括安全用户平面定位(SUPL)定位平台(SLP)的公钥；以及存储特定于移动设备的至少一个安全证书，其中，所述至少一个安全证书包括所述移动设备的设备标识符；以及
处理器，其配置为使所述移动设备将所述至少一个安全证书发送到所述SLP，以基于所述设备标识符与所存储的设备标识符的比较将所述移动设备认证为与SUPL用户相关联，其中，所述至少一个安全证书是在配置为使用所述SLP的私钥进行解密的消息中发送的。
9.如权利要求8所述的装置，其中，所述至少一个安全证书包括所述移动设备的设备证书、所述移动设备的公钥、所述移动设备的国际移动设备标识(IMEI)、移动站标识(MSID)、以及序列号中的至少一个。
10.一种用于无线通信的装置，包括：
用于接收服务器证书的模块，其中所述服务器证书包括安全用户平面定位(SUPL)定位平台(SLP)的公钥；
用于存储特定于移动设备的至少一个安全证书的模块，其中，所述至少一个安全证书包括所述移动设备的设备标识符；以及
用于使所述移动设备将所述至少一个安全证书发送到所述SLP，以基于所述设备标识符与所存储的设备标识符的比较将所述移动设备认证为与SUPL用户相关联的模块，其中，所述至少一个安全证书是在配置为使用所述SLP的私钥进行解密的消息中发送的。
11.如权利要求10所述的装置，其中，所述移动设备包括支持SUPL的终端(SET)。
12.一种认证方法，其包括：
在安全用户平面定位(SUPL)服务器处生成要发送到移动设备的消息，所述消息包括：
包括所述SUPL服务器的标识符和所述SUPL服务器的公钥的服务器证书；以及
对所述移动设备的设备证书的请求；
从所述移动设备接收包括所述移动设备的设备证书的应答，其中，所述应答是使用所述SUPL服务器的私钥进行解密的；以及
基于所述设备证书，将所述移动设备认证为与SUPL用户相关联。
13.如权利要求12所述的方法，其中，所述移动设备包括支持SUPL的终端(SET)，并且所述SUPL服务器包括SUPL定位平台(SLP)。
14.如权利要求12所述的方法，其中，所述消息是响应于从所述移动设备接收到由所述移动设备所支持的一个或多个传输层安全(TLS)密码组的指示而发送的，并且其中，所述消息还包括对所述一个或多个TLS密码组中的至少一个的选择。
15.如权利要求12所述的方法，其中，所述设备证书包括所述移动设备的设备标识符。
16.一种用于无线通信的装置，包括：
处理器；以及
耦合到所述处理器的存储器，其中，所述处理器配置为：
在安全用户平面定位(SUPL)服务器处生成要发送到移动设备的消息，所述消息包括：
包括所述SUPL服务器的标识符和所述SUPL服务器的公钥的服务器证书；以及
对所述移动设备的设备证书的请求；
从所述移动设备接收包括所述移动设备的设备标识符的应答，其中，所述应答是使用所述SUPL服务器的私钥进行解密的；以及
基于所述设备证书，将所述移动设备认证为与SUPL用户相关联。
17.如权利要求16所述的装置，其中，所述消息是响应于在所述SUPL服务器处从所述移动设备接收到由所述移动设备所支持的一个或多个传输层安全(TLS)密码组的指示而发送的，并且其中，所述消息还包括对所述一个或多个TLS密码组中的至少一个的选择。
18.一种认证方法，包括：
向支持安全用户平面定位(SUPL)的移动设备发送包括网页服务器的公钥的服务器证书；
在所述网页服务器处从所述移动设备接收消息，其中，所述消息包括所述移动设备的安全证书；
使用所述网页服务器的私钥对所述消息进行解密；
在所述网页服务器处从所述移动设备接收用户标识信息；
将所述用户标识信息认证为标识SUPL服务的授权用户。
19.如权利要求18所述的方法，其中，所述安全证书包括包含所述移动设备的公钥的设备证书。
20.如权利要求18所述的方法，其中，所述安全证书包括所述移动设备的国际移动设备标识(IMEI)、移动站标识(MSID)、以及序列号中的至少一个。
21.如权利要求18所述的方法，其中，所述用户标识信息包括标识符和密码。
22.一种用于无线通信的装置，包括：
处理器；以及
耦合到所述处理器的存储器，其中，所述处理器配置为：
向支持安全用户平面定位(SUPL)的移动设备发送包括网页服务器的公钥的服务器证书；
在所述网页服务器处从所述移动设备接收消息，其中，所述消息包括所述移动设备的安全证书；
在所述网页服务器处从所述移动设备接收用户标识信息；
使用所述网页服务器的私钥对所述消息进行解密；
将所述用户标识信息认证为标识SUPL服务的授权用户。
23.如权利要求22所述的装置，其中，所述安全证书包括包含所述移动设备的公钥的设备证书。
24.一种用于无线通信的装置，包括：
用于向支持安全用户平面定位(SUPL)的移动设备发送包括网页服务器的公钥的服务器证书的模块；
用于在所述网页服务器处从所述移动设备接收消息的模块，其中，所述消息包括所述移动设备的安全证书；
用于在所述网页服务器处从所述移动设备接收用户标识信息的模块；
用于使用所述网页服务器的私钥对所述消息进行解密的模块；
用于将所述用户标识信息认证为标识SUPL服务的授权用户的模块。
25.如权利要求24所述的装置，其中，所述安全证书包括包含所述移动设备的公钥的设备证书。
CN201180064445.0A 2010-11-06 2011-11-04 用于安全用户平面定位***中的认证的方法和装置 Active CN103370915B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610028131.XA CN105491070B (zh) 2010-11-06 2011-11-04 安全用户平面定位(supl)***中的认证方法和装置

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US41088210P 2010-11-06 2010-11-06
US61/410,882 2010-11-06
US201161437184P 2011-01-28 2011-01-28
US61/437,184 2011-01-28
US201161471048P 2011-04-01 2011-04-01
US61/471,048 2011-04-01
US201161527341P 2011-08-25 2011-08-25
US61/527,341 2011-08-25
US13/288,949 2011-11-03
US13/288,949 US8627422B2 (en) 2010-11-06 2011-11-03 Authentication in secure user plane location (SUPL) systems
PCT/US2011/059455 WO2012087435A1 (en) 2010-11-06 2011-11-04 Authentication in secure user plane location (supl) systems

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN201610028131.XA Division CN105491070B (zh) 2010-11-06 2011-11-04 安全用户平面定位(supl)***中的认证方法和装置

Publications (2)

Publication Number Publication Date
CN103370915A CN103370915A (zh) 2013-10-23
CN103370915B true CN103370915B (zh) 2016-12-07

Family

ID=45048220

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201180064445.0A Active CN103370915B (zh) 2010-11-06 2011-11-04 用于安全用户平面定位***中的认证的方法和装置
CN201610028131.XA Active CN105491070B (zh) 2010-11-06 2011-11-04 安全用户平面定位(supl)***中的认证方法和装置

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201610028131.XA Active CN105491070B (zh) 2010-11-06 2011-11-04 安全用户平面定位(supl)***中的认证方法和装置

Country Status (6)

Country Link
US (4) US8627422B2 (zh)
EP (1) EP2636203B1 (zh)
JP (2) JP5876063B2 (zh)
KR (2) KR101869368B1 (zh)
CN (2) CN103370915B (zh)
WO (1) WO2012087435A1 (zh)

Families Citing this family (209)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7487363B2 (en) 2001-10-18 2009-02-03 Nokia Corporation System and method for controlled copying and moving of content between devices and domains based on conditional encryption of content key depending on usage
US8948012B2 (en) 2005-12-29 2015-02-03 Nokia Corporation System and method for interactive session provision
CN101227458B (zh) * 2007-01-16 2011-11-23 华为技术有限公司 移动ip***及更新家乡代理根密钥的方法
US8989705B1 (en) 2009-06-18 2015-03-24 Sprint Communications Company L.P. Secure placement of centralized media controller application in mobile access terminal
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US8627422B2 (en) 2010-11-06 2014-01-07 Qualcomm Incorporated Authentication in secure user plane location (SUPL) systems
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
US8738027B2 (en) 2011-02-07 2014-05-27 Qualcomm Incorporated Methods and apparatus for identifying and authorizing location servers and location services
US10009319B2 (en) 2011-02-07 2018-06-26 Qualcomm Incorporated Methods, apparatuses and articles for identifying and authorizing location servers and location services using a proxy location server
US20120210001A1 (en) * 2011-02-11 2012-08-16 Christopher Maybee Ryerson System and method for managing access to a communication network
SG10201602471QA (en) * 2011-04-01 2016-04-28 Ericsson Telefon Ab L M Methods and apparatuses for avoiding damage in network attacks
CN102149085B (zh) * 2011-04-21 2014-01-15 惠州Tcl移动通信有限公司 移动终端及其多接入点管理方法
US9491620B2 (en) 2012-02-10 2016-11-08 Qualcomm Incorporated Enabling secure access to a discovered location server for a mobile device
US9247424B2 (en) * 2012-02-14 2016-01-26 Apple Inc. Methods and apparatus for large scale distribution of electronic access clients
US9887833B2 (en) * 2012-03-07 2018-02-06 The Trustees Of Columbia University In The City Of New York Systems and methods to counter side channel attacks
US8955086B2 (en) * 2012-03-16 2015-02-10 Red Hat, Inc. Offline authentication
US9027102B2 (en) 2012-05-11 2015-05-05 Sprint Communications Company L.P. Web server bypass of backend process on near field communications and secure element chips
US8756677B2 (en) * 2012-05-30 2014-06-17 Google Inc. Variable-strength security based on time and/or number of partial password unlocks
US20130326612A1 (en) * 2012-06-04 2013-12-05 Crocus Technology Inc. Apparatus and Method for Forming Secure Computational Resources
US9497169B2 (en) * 2012-06-08 2016-11-15 Samsung Electronics Co., Ltd. Method and system for selective protection of data exchanged between user equipment and network
US9282898B2 (en) 2012-06-25 2016-03-15 Sprint Communications Company L.P. End-to-end trusted communications infrastructure
US9066230B1 (en) 2012-06-27 2015-06-23 Sprint Communications Company L.P. Trusted policy and charging enforcement function
US8649770B1 (en) 2012-07-02 2014-02-11 Sprint Communications Company, L.P. Extended trusted security zone radio modem
US8667607B2 (en) 2012-07-24 2014-03-04 Sprint Communications Company L.P. Trusted security zone access to peripheral devices
US9183412B2 (en) 2012-08-10 2015-11-10 Sprint Communications Company L.P. Systems and methods for provisioning and using multiple trusted security zones on an electronic device
US8954588B1 (en) 2012-08-25 2015-02-10 Sprint Communications Company L.P. Reservations in real-time brokering of digital content delivery
US9015068B1 (en) 2012-08-25 2015-04-21 Sprint Communications Company L.P. Framework for real-time brokering of digital content delivery
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
CN104704789B (zh) * 2012-10-15 2018-06-22 诺基亚通信公司 网络认证
EP2723111B1 (de) * 2012-10-16 2017-12-06 Deutsche Telekom AG Mehrfaktor-Authentifikation für mobile Endgeräte
US9357382B2 (en) * 2012-10-31 2016-05-31 Intellisist, Inc. Computer-implemented system and method for validating call connections
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
WO2014092702A1 (en) * 2012-12-12 2014-06-19 Empire Technology Development Llc Detecting matched cloud infrastructure connections for secure off-channel secret generation
WO2014120253A1 (en) * 2013-01-29 2014-08-07 Blackberry Limited A system and method for providing a certificate-based trust framework using a secondary network
US9197413B1 (en) * 2013-02-06 2015-11-24 Rockwell Collins, Inc. Hybrid secure communication system and method
US9161227B1 (en) 2013-02-07 2015-10-13 Sprint Communications Company L.P. Trusted signaling in long term evolution (LTE) 4G wireless communication
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
US9485095B2 (en) * 2013-02-22 2016-11-01 Cisco Technology, Inc. Client control through content key format
US9426833B2 (en) * 2013-03-01 2016-08-23 T-Mobile Usa, Inc. Systems and methods for emergency call route failover
US9104840B1 (en) 2013-03-05 2015-08-11 Sprint Communications Company L.P. Trusted security zone watermark
US9613208B1 (en) 2013-03-13 2017-04-04 Sprint Communications Company L.P. Trusted security zone enhanced with trusted hardware drivers
US9049013B2 (en) 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone containers for the protection and confidentiality of trusted service manager data
US9049186B1 (en) * 2013-03-14 2015-06-02 Sprint Communications Company L.P. Trusted security zone re-provisioning and re-use capability for refurbished mobile devices
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
US9374363B1 (en) 2013-03-15 2016-06-21 Sprint Communications Company L.P. Restricting access of a portable communication device to confidential data or applications via a remote network based on event triggers generated by the portable communication device
US9191388B1 (en) 2013-03-15 2015-11-17 Sprint Communications Company L.P. Trusted security zone communication addressing on an electronic device
US8984592B1 (en) 2013-03-15 2015-03-17 Sprint Communications Company L.P. Enablement of a trusted security zone authentication for remote mobile device management systems and methods
US9602537B2 (en) * 2013-03-15 2017-03-21 Vmware, Inc. Systems and methods for providing secure communication
US9324016B1 (en) 2013-04-04 2016-04-26 Sprint Communications Company L.P. Digest of biographical information for an electronic device with static and dynamic portions
US9171243B1 (en) 2013-04-04 2015-10-27 Sprint Communications Company L.P. System for managing a digest of biographical information stored in a radio frequency identity chip coupled to a mobile communication device
US9454723B1 (en) 2013-04-04 2016-09-27 Sprint Communications Company L.P. Radio frequency identity (RFID) chip electrically and communicatively coupled to motherboard of mobile communication device
US9838869B1 (en) 2013-04-10 2017-12-05 Sprint Communications Company L.P. Delivering digital content to a mobile device via a digital rights clearing house
US9443088B1 (en) 2013-04-15 2016-09-13 Sprint Communications Company L.P. Protection for multimedia files pre-downloaded to a mobile device
US9137218B2 (en) * 2013-05-03 2015-09-15 Akamai Technologies, Inc. Splicing into an active TLS session without a certificate or private key
US9069952B1 (en) 2013-05-20 2015-06-30 Sprint Communications Company L.P. Method for enabling hardware assisted operating system region for safe execution of untrusted code using trusted transitional memory
US9560519B1 (en) 2013-06-06 2017-01-31 Sprint Communications Company L.P. Mobile communication device profound identity brokering framework
CN103324883B (zh) * 2013-06-24 2015-07-29 腾讯科技（深圳）有限公司 一种多媒体播放终端的认证方法、终端、服务器以及***
US9183606B1 (en) 2013-07-10 2015-11-10 Sprint Communications Company L.P. Trusted processing location within a graphics processing unit
US9402163B2 (en) * 2013-07-19 2016-07-26 Qualcomm Incorporated In-building location security and privacy
WO2015016948A1 (en) * 2013-08-02 2015-02-05 Intel Corporation Supl session persistence across power cycles
US9208339B1 (en) 2013-08-12 2015-12-08 Sprint Communications Company L.P. Verifying Applications in Virtual Environments Using a Trusted Security Zone
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US20150074765A1 (en) * 2013-09-06 2015-03-12 Oracle International Corporation Registration and configuration of point-of-service devices
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9350717B1 (en) 2013-09-23 2016-05-24 Amazon Technologies, Inc. Location service for user authentication
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9185626B1 (en) 2013-10-29 2015-11-10 Sprint Communications Company L.P. Secure peer-to-peer call forking facilitated by trusted 3rd party voice server provisioning
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9191522B1 (en) 2013-11-08 2015-11-17 Sprint Communications Company L.P. Billing varied service based on tier
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US10700856B2 (en) * 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
CN106851628B (zh) 2013-12-05 2020-08-07 华为终端有限公司 下载运营商的文件的方法及设备
US9363736B2 (en) * 2013-12-16 2016-06-07 Qualcomm Incorporated Methods and apparatus for provisioning of credentials in network deployments
US9602962B2 (en) * 2014-01-15 2017-03-21 Qualcomm Incorporated Methods and systems for providing location based services in a venue using femtocells
US9118655B1 (en) 2014-01-24 2015-08-25 Sprint Communications Company L.P. Trusted display and transmission of digital ticket documentation
US9197994B2 (en) * 2014-01-29 2015-11-24 Kaseya Limited Identifying mobile device location and corresponding support center locations to provide support services over a network
JP2015148896A (ja) * 2014-02-05 2015-08-20 アプリックスＩｐホールディングス株式会社 通信システム及びサーバ
US9407654B2 (en) * 2014-03-20 2016-08-02 Microsoft Technology Licensing, Llc Providing multi-level password and phishing protection
EP3451621B1 (en) 2014-03-21 2021-06-30 Sun Patent Trust Security key derivation in dual connectivity
US9226145B1 (en) 2014-03-28 2015-12-29 Sprint Communications Company L.P. Verification of mobile device integrity during activation
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
US9450947B2 (en) * 2014-05-20 2016-09-20 Motorola Solutions, Inc. Apparatus and method for securing a debugging session
KR101975510B1 (ko) 2014-05-23 2019-05-07 후아웨이 테크놀러지 컴퍼니 리미티드 Euicc 관리 방법, euicc, sm 플랫폼 및 시스템
JP6569087B2 (ja) * 2014-05-29 2019-09-04 パナソニックＩｐマネジメント株式会社 受信装置および受信方法
WO2016004570A1 (zh) * 2014-07-07 2016-01-14 华为技术有限公司 嵌入式通用集成电路卡管理的授权方法及装置
WO2016007732A1 (en) * 2014-07-09 2016-01-14 Deja View Concepts, Inc. Bluetooth low energy for access control
US10028081B2 (en) 2014-07-10 2018-07-17 Bank Of America Corporation User authentication
US10074130B2 (en) 2014-07-10 2018-09-11 Bank Of America Corporation Generating customer alerts based on indoor positioning system detection of physical customer presence
US10108952B2 (en) 2014-07-10 2018-10-23 Bank Of America Corporation Customer identification
US10332050B2 (en) 2014-07-10 2019-06-25 Bank Of America Corporation Identifying personnel-staffing adjustments based on indoor positioning system detection of physical customer presence
US9734643B2 (en) * 2014-07-10 2017-08-15 Bank Of America Corporation Accessing secure areas based on identification via personal device
CN104158659B (zh) * 2014-07-21 2015-11-11 小米科技有限责任公司 防伪验证方法、装置和***
US9230085B1 (en) 2014-07-29 2016-01-05 Sprint Communications Company L.P. Network based temporary trust extension to a remote or mobile device enabled via specialized cloud services
WO2016028198A1 (en) * 2014-08-20 2016-02-25 Telefonaktiebolaget L M Ericsson (Publ) Methods, devices and management terminals for establishing a secure session with a service
US9531542B2 (en) 2014-09-19 2016-12-27 Bank Of America Corporation Secure remote password
US9825937B2 (en) 2014-09-23 2017-11-21 Qualcomm Incorporated Certificate-based authentication
US10225736B2 (en) 2014-10-06 2019-03-05 Lg Electronics Inc. Method and apparatus for managing authentication in wireless communication system while subscriber identity module is not available
FR3027177B1 (fr) * 2014-10-13 2016-11-04 Morpho Procede d'authentification d'un dispositif client aupres d'un serveur a l'aide d'un element secret
US9843446B2 (en) * 2014-10-14 2017-12-12 Dropbox, Inc. System and method for rotating client security keys
PT107993B (pt) * 2014-10-21 2016-11-11 Inst De Telecomunicações Método e sistema de autenticação de um domínio de operador 3gpp
US11399019B2 (en) * 2014-10-24 2022-07-26 Netflix, Inc. Failure recovery mechanism to re-establish secured communications
US11533297B2 (en) 2014-10-24 2022-12-20 Netflix, Inc. Secure communication channel with token renewal mechanism
US10050955B2 (en) 2014-10-24 2018-08-14 Netflix, Inc. Efficient start-up for secured connections and related services
JP6380009B2 (ja) * 2014-10-31 2018-08-29 株式会社リコー 情報処理システム、認証方法、および情報処理装置
US9820132B2 (en) 2014-12-01 2017-11-14 Nokia Technologies Oy Wireless short-range discovery and connection setup using first and second wireless carrier
US10356053B1 (en) * 2014-12-12 2019-07-16 Charles Schwab & Co., Inc. System and method for allowing access to an application or features thereof on each of one or more user devices
WO2016108096A1 (en) * 2014-12-30 2016-07-07 Stmicroelectronics S.R.L. Methods for providing a response to a scp80 command requesting the execution of a proactive command, related universal integrated circuit card, mobile device, server and computer program product
US9779232B1 (en) 2015-01-14 2017-10-03 Sprint Communications Company L.P. Trusted code generation and verification to prevent fraud from maleficent external devices that capture data
WO2016116890A1 (en) * 2015-01-22 2016-07-28 Visa International Service Association Method and system for establishing a secure communication tunnel
US9838868B1 (en) 2015-01-26 2017-12-05 Sprint Communications Company L.P. Mated universal serial bus (USB) wireless dongles configured with destination addresses
US9961074B2 (en) * 2015-02-10 2018-05-01 Dell Products, Lp System and method for providing an authentication certificate for a wireless handheld device a data center environment
US10110595B2 (en) * 2015-03-16 2018-10-23 Convida Wireless, Llc End-to-end authentication at the service layer using public keying mechanisms
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
US10454686B2 (en) * 2015-04-08 2019-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Method, apparatus, and system for providing encryption or integrity protection in a wireless network
US9338147B1 (en) 2015-04-24 2016-05-10 Extrahop Networks, Inc. Secure communication secret sharing
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US9807083B2 (en) * 2015-06-05 2017-10-31 Sony Corporation Distributed white list for security renewability
US9473941B1 (en) * 2015-06-16 2016-10-18 Nokia Technologies Oy Method, apparatus, and computer program product for creating an authenticated relationship between wireless devices
US10230767B2 (en) 2015-07-29 2019-03-12 At&T Intellectual Property I, L.P. Intra-carrier and inter-carrier network security system
JP5951094B1 (ja) * 2015-09-07 2016-07-13 ヤフー株式会社 生成装置、端末装置、生成方法、生成プログラム及び認証処理システム
JP6122924B2 (ja) 2015-09-11 2017-04-26 ヤフー株式会社 提供装置、端末装置、提供方法、提供プログラム及び認証処理システム
US9819679B1 (en) 2015-09-14 2017-11-14 Sprint Communications Company L.P. Hardware assisted provenance proof of named data networking associated to device data, addresses, services, and servers
US10462116B1 (en) * 2015-09-15 2019-10-29 Amazon Technologies, Inc. Detection of data exfiltration
CN106572066B (zh) * 2015-10-10 2019-11-22 西安西电捷通无线网络通信股份有限公司 一种实体身份有效性验证方法及其装置
US10282719B1 (en) 2015-11-12 2019-05-07 Sprint Communications Company L.P. Secure and trusted device-based billing and charging process using privilege for network proxy authentication and audit
US9817992B1 (en) 2015-11-20 2017-11-14 Sprint Communications Company Lp. System and method for secure USIM wireless network access
US10972262B2 (en) * 2015-12-30 2021-04-06 T-Mobile Usa, Inc. Persona and device based certificate management
US10652023B2 (en) 2015-12-30 2020-05-12 T-Mobile Usa, Inc. Persona and device based certificate management
WO2017130292A1 (ja) 2016-01-26 2017-08-03 株式会社ソラコム サーバ、モバイル端末及びプログラム
US10228926B2 (en) * 2016-01-28 2019-03-12 T-Mobile Usa, Inc. Remote support installation mechanism
US10863558B2 (en) * 2016-03-30 2020-12-08 Schweitzer Engineering Laboratories, Inc. Communication device for implementing trusted relationships in a software defined network
US10129228B1 (en) * 2016-03-30 2018-11-13 Amazon Technologies, Inc. Authenticated communication between devices
US10104119B2 (en) * 2016-05-11 2018-10-16 Cisco Technology, Inc. Short term certificate management during distributed denial of service attacks
US10362021B2 (en) * 2016-05-31 2019-07-23 Airwatch Llc Device authentication based upon tunnel client network requests
CN106302414B (zh) * 2016-08-04 2019-05-31 北京百度网讯科技有限公司 网站内容防抓取方法和装置
CN107809411B (zh) * 2016-09-09 2021-12-03 华为技术有限公司 移动网络的认证方法、终端设备、服务器和网络认证实体
US11805107B2 (en) * 2016-10-24 2023-10-31 Nubeva, Inc. Extracting encryption keys to enable monitoring services
JP6775683B2 (ja) * 2016-10-31 2020-10-28 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 次世代システムの認証
EP3322149B1 (en) * 2016-11-10 2023-09-13 Tata Consultancy Services Limited Customized map generation with real time messages and locations from concurrent users
US10218694B2 (en) 2016-11-22 2019-02-26 Bank Of America Corporation Securely orchestrating events initiated at remote servers using a certificate server
US10645086B1 (en) * 2016-12-30 2020-05-05 Charles Schwab & Co., Inc. System and method for handling user requests for web services
US10862885B2 (en) * 2017-03-20 2020-12-08 Forescout Technologies, Inc. Device identification
US10476673B2 (en) 2017-03-22 2019-11-12 Extrahop Networks, Inc. Managing session secrets for continuous packet capture systems
WO2018190854A1 (en) * 2017-04-14 2018-10-18 Giesecke+Devrient Mobile Security America, Inc. Device and method for authenticating transport layer security communications
US11190504B1 (en) * 2017-05-17 2021-11-30 Amazon Technologies, Inc. Certificate-based service authorization
US10499246B2 (en) * 2017-05-17 2019-12-03 Verizon Patent And Licensing Inc. Hardware identification-based security authentication service for IoT devices
US20190014095A1 (en) * 2017-07-06 2019-01-10 At&T Intellectual Property I, L.P. Facilitating provisioning of an out-of-band pseudonym over a secure communication channel
US10788998B2 (en) 2017-07-07 2020-09-29 Sap Se Logging changes to data stored in distributed data storage system
US10499249B1 (en) 2017-07-11 2019-12-03 Sprint Communications Company L.P. Data link layer trust signaling in communication network
HUE060301T2 (hu) * 2017-07-25 2023-02-28 Ericsson Telefon Ab L M Elõfizetési rejtett azonosító
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
EP4020940A1 (en) 2017-08-28 2022-06-29 Bright Data Ltd. Content fetching by selecting tunnel devices
US9967292B1 (en) 2017-10-25 2018-05-08 Extrahop Networks, Inc. Inline secret sharing
US20190182645A1 (en) * 2017-12-08 2019-06-13 Qualcomm Incorporated Provisioning mechanism to trigger a subscription download at a user equipment
US10389574B1 (en) 2018-02-07 2019-08-20 Extrahop Networks, Inc. Ranking alerts based on network monitoring
US10038611B1 (en) 2018-02-08 2018-07-31 Extrahop Networks, Inc. Personalization of alerts based on network monitoring
US10270794B1 (en) 2018-02-09 2019-04-23 Extrahop Networks, Inc. Detection of denial of service attacks
US10659054B2 (en) * 2018-02-23 2020-05-19 Nxp B.V. Trusted monotonic counter using internal and external non-volatile memory
GB2573262B (en) * 2018-03-08 2022-04-13 Benefit Vantage Ltd Mobile identification method based on SIM card and device-related parameters
RU2755196C1 (ru) 2018-04-05 2021-09-14 Нокиа Текнолоджиз Ой Управление унифицированными идентификаторами подписки в системах связи
US11018930B2 (en) * 2018-05-16 2021-05-25 Vmware Inc. Internet of things gateway onboarding
US10411978B1 (en) 2018-08-09 2019-09-10 Extrahop Networks, Inc. Correlating causes and effects associated with network activity
US10594718B1 (en) 2018-08-21 2020-03-17 Extrahop Networks, Inc. Managing incident response operations based on monitored network activity
CN109495441A (zh) * 2018-09-10 2019-03-19 北京车和家信息技术有限公司 接入认证方法、装置、相关设备及计算机可读存储介质
US11985567B2 (en) 2018-09-12 2024-05-14 Qualcomm Incorporated Methods and systems for enhancement of positioning related protocols
US11068598B2 (en) * 2018-11-01 2021-07-20 Dell Products L.P. Chassis internal device security
CN111147421B (zh) * 2018-11-02 2023-06-16 中兴通讯股份有限公司 一种基于通用引导架构gba的认证方法及相关设备
US20200154241A1 (en) * 2018-11-08 2020-05-14 Mediatek Inc. Methods for reliable transmission of a supl init message
CN109714343B (zh) * 2018-12-28 2022-02-22 北京天融信网络安全技术有限公司 一种网络流量异常的判断方法及装置
US10820200B2 (en) * 2019-01-14 2020-10-27 T-Mobile Usa, Inc. Framework for securing device activations
US11190521B2 (en) * 2019-01-18 2021-11-30 Vmware, Inc. TLS policy enforcement at a tunnel gateway
US11212319B2 (en) * 2019-01-24 2021-12-28 Zhnith Incorporated Multiple sentinels for securing communications
JP7273523B2 (ja) * 2019-01-25 2023-05-15 株式会社東芝 通信制御装置および通信制御システム
WO2020174460A2 (en) 2019-02-25 2020-09-03 Luminati Networks Ltd. System and method for url fetching retry mechanism
EP3935792A4 (en) 2019-04-02 2022-11-30 Bright Data Ltd. SYSTEM AND METHOD FOR MANAGING A NON-DIRECT URL RETRACTION SERVICE
US10965702B2 (en) 2019-05-28 2021-03-30 Extrahop Networks, Inc. Detecting injection attacks using passive network monitoring
JP7298356B2 (ja) * 2019-07-16 2023-06-27 富士フイルムビジネスイノベーション株式会社 情報処理装置及び情報処理プログラム
US11165814B2 (en) 2019-07-29 2021-11-02 Extrahop Networks, Inc. Modifying triage information based on network monitoring
US10742530B1 (en) 2019-08-05 2020-08-11 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11509642B2 (en) * 2019-08-21 2022-11-22 Truist Bank Location-based mobile device authentication
US10742677B1 (en) 2019-09-04 2020-08-11 Extrahop Networks, Inc. Automatic determination of user roles and asset types based on network monitoring
US11451959B2 (en) * 2019-09-30 2022-09-20 Fortinet, Inc. Authenticating client devices in a wireless communication network with client-specific pre-shared keys
US11233859B2 (en) * 2019-10-31 2022-01-25 Arm Ip Limited Machine-to-machine communications
CN111083631B (zh) * 2019-12-02 2020-11-03 兰州交通大学 一种保护位置隐私和查询隐私的高效查询处理方法
US11165823B2 (en) 2019-12-17 2021-11-02 Extrahop Networks, Inc. Automated preemptive polymorphic deception
CN113132995B (zh) * 2019-12-31 2023-04-07 中移智行网络科技有限公司 一种设备管控方法、装置、存储介质和计算机设备
CN114040387B (zh) * 2020-07-21 2024-06-04 ***通信有限公司研究院 一种攻击消息的确定方法、装置及设备
US11411997B2 (en) * 2020-08-13 2022-08-09 Salesforce, Inc. Active fingerprinting for transport layer security (TLS) servers
US11310256B2 (en) 2020-09-23 2022-04-19 Extrahop Networks, Inc. Monitoring encrypted network traffic
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
US11361630B1 (en) 2020-11-20 2022-06-14 Bank Of America Corporation Identifying and logging mobile devices posing security threats
US11882452B2 (en) 2020-11-20 2024-01-23 Bank Of America Corporation Monitoring for security threats associated with mobile devices that have been identified and logged
US20220182838A1 (en) * 2020-12-08 2022-06-09 Verizon Patent And Licensing Inc. Systems and methods for obtaining a subscriber identity for an emergency call
CN112584350B (zh) * 2020-12-10 2023-02-28 阿波罗智联(北京)科技有限公司 处理信息的方法、装置、设备及可读存储介质
US20230396609A1 (en) * 2021-02-26 2023-12-07 Xero Limited Multi-factor authentication
CN112906063B (zh) * 2021-02-26 2024-04-26 杭州萤石软件有限公司 一种数字摘要算法处理设备方法、装置、***及设备
US11349861B1 (en) 2021-06-18 2022-05-31 Extrahop Networks, Inc. Identifying network entities based on beaconing activity
US20230061362A1 (en) * 2021-08-31 2023-03-02 International Business Machines Corporation Message delivery in cellular roaming scenarios
US11336564B1 (en) 2021-09-01 2022-05-17 Schweitzer Engineering Laboratories, Inc. Detection of active hosts using parallel redundancy protocol in software defined networks
US11750502B2 (en) 2021-09-01 2023-09-05 Schweitzer Engineering Laboratories, Inc. Detection of in-band software defined network controllers using parallel redundancy protocol
US11296967B1 (en) 2021-09-23 2022-04-05 Extrahop Networks, Inc. Combining passive network analysis and active probing
CN113993131B (zh) * 2021-10-28 2023-06-30 中国联合网络通信集团有限公司 访问控制方法及装置
US20230137082A1 (en) * 2021-10-31 2023-05-04 Qualcomm Incorporated Generic Bootstrapping Architecture (GBA) Signaling To Indicate Need For Key Renegotiation
US11843606B2 (en) 2022-03-30 2023-12-12 Extrahop Networks, Inc. Detecting abnormal data access based on data similarity
CN116471081B (zh) * 2023-04-18 2023-12-12 中国石油天然气股份有限公司辽宁销售分公司 一种基于物联网技术的室内安防匿名认证方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101658013A (zh) * 2007-03-12 2010-02-24 高通股份有限公司 网络独立定位服务

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR9911814A (pt) * 1998-07-03 2001-10-16 Nokia Mobile Phones Ltd Sessão de configuração segura baseado no protocolo de aplicação sem fio
JP2002074188A (ja) 2000-06-16 2002-03-15 Sony Computer Entertainment Inc 会員情報登録方法および装置、会員認証方法および装置、サーバコンピュータ
US7120675B1 (en) 2000-09-26 2006-10-10 Microsoft Corporation Information location service
GB2404126B (en) * 2002-01-17 2005-04-06 Toshiba Res Europ Ltd Data transmission links
US7240366B2 (en) * 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US20050108520A1 (en) * 2002-06-12 2005-05-19 Sumitomo Heavy Industries, Ltd. Authentication apparatus and method, network system, recording medium and computer program
US20040059941A1 (en) 2002-09-19 2004-03-25 Myfamily.Com, Inc. Systems and methods for identifying users and providing access to information in a network environment
US7376834B2 (en) * 2003-07-18 2008-05-20 Palo Alto Research Center Incorporated System and method for securely controlling communications
TWI290439B (en) * 2005-11-09 2007-11-21 Min-Chieh Su Mobile communication terminal verification authorization system and method thereof
US20050125493A1 (en) 2003-11-13 2005-06-09 Hemant Chaskar IP-based mechanism for location service systems, methods, and devices
KR101119295B1 (ko) * 2004-04-21 2012-03-16 삼성전자주식회사 네트워크에 독립적으로 구성된 측위 서버를 이용한이동단말기의 위치결정장치 및 그 방법
US9723087B2 (en) * 2004-08-03 2017-08-01 Lg Electronics Inc. User privacy management apparatus and method in mobile communications system
KR100575802B1 (ko) 2004-09-13 2006-05-03 엘지전자 주식회사 위치 정보 시스템에서의 로밍 방법 및 시스템
US7512967B2 (en) 2004-12-29 2009-03-31 Alcatel-Lucent Usa Inc. User authentication in a conversion system
US7900039B2 (en) 2005-01-17 2011-03-01 Lg Electronics, Inc. TLS session management method in SUPL-based positioning system
KR100846868B1 (ko) * 2005-01-17 2008-07-17 엘지전자 주식회사 Ｓｕｐｌ 기반의 위치정보 시스템에서의 ｔｌｓ 세션관리방법
KR100595714B1 (ko) 2005-04-01 2006-07-03 엘지전자 주식회사 Ｓｕｐｌ 기반의 위치정보 시스템에서 ｓｕｐｌ 초기화메시지 및 이를 이용한 ｓｕｐｌ 처리방법
KR100878813B1 (ko) 2005-04-29 2009-01-14 엘지전자 주식회사 위치정보 전송 방법
CN100450297C (zh) * 2005-07-25 2009-01-07 华为技术有限公司 一种基于安全的用户平面移动定位方法及***
WO2007016695A2 (en) 2005-08-02 2007-02-08 Qualcomm Incorporated Voip emergency call handling
US10178522B2 (en) 2005-08-02 2019-01-08 Qualcomm Incorporated VoIP emergency call support
US8068056B2 (en) 2005-08-25 2011-11-29 Qualcomm Incorporated Location reporting with secure user plane location (SUPL)
US9137770B2 (en) 2005-09-15 2015-09-15 Qualcomm Incorporated Emergency circuit-mode call support
KR100748513B1 (ko) 2005-10-07 2007-08-14 엘지전자 주식회사 위치 서비스 방법 및 시스템
AU2006225248B2 (en) 2005-10-10 2007-10-18 Samsung Electronics Co., Ltd. Location service-providing system and deferred location request service-providing method using previously computed location in location service-providing system
KR20070108301A (ko) 2005-12-01 2007-11-09 엘지전자 주식회사 위치 기반의 통지를 위한 위치정보 시스템 및 그 방법
JP4655951B2 (ja) * 2006-02-06 2011-03-23 ソニー株式会社 情報処理装置、情報記録媒体製造装置、情報記録媒体、および方法、並びにコンピュータ・プログラム
US7778639B2 (en) 2006-04-06 2010-08-17 Lg Electronics Inc. Network-initiated area event triggered positioning method for roaming terminal in mobile communication system
US8478287B2 (en) 2006-06-07 2013-07-02 Samsung Electronics Co., Ltd. Method for positioning target terminal while protecting privacy of user thereof
KR101181598B1 (ko) * 2006-06-09 2012-09-10 삼성전자주식회사 목표단말기의 주기적 위치 정보 제공 방법 및 시스템
US8218512B2 (en) 2006-06-14 2012-07-10 Toshiba America Research, Inc. Distribution of session keys to the selected multiple access points based on geo-location of APs
US9094784B2 (en) 2006-10-10 2015-07-28 Qualcomm Incorporated Registration of a terminal with a location server for user plane location
US7974235B2 (en) 2006-11-13 2011-07-05 Telecommunication Systems, Inc. Secure location session manager
US8509140B2 (en) * 2006-11-21 2013-08-13 Honeywell International Inc. System and method for transmitting information using aircraft as transmission relays
EP2143290A2 (en) 2007-04-05 2010-01-13 Nokia Corporation Method, apparatuses and program product for utilizing user datagram protocol instead of wireless datagram protocol for sending supl message from a location platform
CN101822082B (zh) 2007-10-05 2013-06-12 交互数字技术公司 用于uicc和终端之间安全信道化的技术
FR2958821A1 (fr) 2007-12-11 2011-10-14 Mediscs Procede d'authentification d'un utilisateur
US8712439B2 (en) 2008-01-11 2014-04-29 Qualcomm Incorporated Method and apparatus for using service capability information for user plane location
US8392980B1 (en) * 2008-08-22 2013-03-05 Avaya Inc. Trusted host list for TLS sessions
US20100146592A1 (en) * 2008-12-04 2010-06-10 Dell Products L. P. Systems and methods for providing session continuity across a chassis management controller failover
JP5449788B2 (ja) * 2009-01-23 2014-03-19 株式会社Ｎｔｔドコモ 測位支援装置及び測位支援方法
US8301160B2 (en) 2009-03-16 2012-10-30 Andrew Llc System and method for SUPL roaming using a held client
TWI448139B (zh) 2009-05-15 2014-08-01 Chi Mei Comm Systems Inc 用於手機遠端測試之伺服器及方法
US8443202B2 (en) * 2009-08-05 2013-05-14 Daon Holdings Limited Methods and systems for authenticating users
US8630622B2 (en) 2009-12-07 2014-01-14 At&T Mobility Ii Llc Devices, systems and methods for location assistance verification
US8434142B2 (en) * 2010-02-26 2013-04-30 Telefonaktiebolaget L M Ericsson (Publ) Method for mitigating on-path attacks in mobile IP network
US8874710B2 (en) 2010-04-27 2014-10-28 Nokia Corporation Access network discovery
US10063642B2 (en) * 2010-08-21 2018-08-28 Qualcomm Incorporated Method and apparatus for supporting location services via a generic location session
US8627422B2 (en) 2010-11-06 2014-01-07 Qualcomm Incorporated Authentication in secure user plane location (SUPL) systems
US8631238B2 (en) * 2010-12-17 2014-01-14 Oracle International Corporation Preventing race conditions in secure token exchange
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
CA2762739C (en) 2010-12-29 2021-01-12 Bce Inc. Method and system for transmitting a network-initiated message to a mobile device
US8811939B2 (en) 2011-02-07 2014-08-19 Qualcomm Incorporated Method and/or apparatus for location privacy via uniform resource identifier provisioning
US8738027B2 (en) 2011-02-07 2014-05-27 Qualcomm Incorporated Methods and apparatus for identifying and authorizing location servers and location services
US10009319B2 (en) 2011-02-07 2018-06-26 Qualcomm Incorporated Methods, apparatuses and articles for identifying and authorizing location servers and location services using a proxy location server

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101658013A (zh) * 2007-03-12 2010-02-24 高通股份有限公司 网络独立定位服务

Also Published As

Publication number Publication date
KR20130089655A (ko) 2013-08-12
WO2012087435A1 (en) 2012-06-28
EP2636203B1 (en) 2020-10-21
US8627422B2 (en) 2014-01-07
CN105491070B (zh) 2019-10-18
KR101530538B1 (ko) 2015-06-22
CN105491070A (zh) 2016-04-13
KR20140137454A (ko) 2014-12-02
US20140094147A1 (en) 2014-04-03
JP2013546260A (ja) 2013-12-26
US9402177B2 (en) 2016-07-26
JP6185017B2 (ja) 2017-08-23
US9119065B2 (en) 2015-08-25
CN103370915A (zh) 2013-10-23
JP5876063B2 (ja) 2016-03-02
US9706408B2 (en) 2017-07-11
EP2636203A1 (en) 2013-09-11
US20160337861A1 (en) 2016-11-17
US20140093081A1 (en) 2014-04-03
US20130067552A1 (en) 2013-03-14
KR101869368B1 (ko) 2018-06-21
JP2016007004A (ja) 2016-01-14

Similar Documents

Publication Publication Date Title
CN103370915B (zh) 用于安全用户平面定位***中的认证的方法和装置
JP6759232B2 (ja) 完全前方秘匿性を有する認証および鍵共有
CN104145465B (zh) 机器类型通信中基于群组的自举的方法和装置
TWI514896B (zh) 可信賴聯合身份方法及裝置
US8913995B2 (en) Ticket-based configuration parameters validation
KR101287309B1 (ko) 홈 노드-ｂ 장치 및 보안 프로토콜
KR101556046B1 (ko) 통신 핸드오프 시나리오를 위한 인증 및 보안 채널 설정
US20140310782A1 (en) Ticket-based spectrum authorization and access control
EP2612486B1 (en) Downloadable isim
CN104662861A (zh) 用于认证无线单元的用户的方法和***
CN108886688B (zh) 一种可以在连接到无线通信网络的服务提供商sp网络中操作的方法、装置和可读介质
TW201220793A (en) Method and apparatus for binding subscriber authentication and device authentication in communication systems
WO2016077013A1 (en) Method to authenticate peers in an infrastructure-less peer-to-peer network
JP7337912B2 (ja) コアネットワークへの非３ｇｐｐデバイスアクセス
CN101120522A (zh) 在基于supl的定位***中的tls会话管理方法
Kambourakis et al. Support of subscribers’ certificates in a hybrid WLAN-3G environment
Lee Transport Layer Security (TLS) Implementation for Secured MN-HA Communication in Mobile IPv6

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant