KR20130089655A - 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증 - Google Patents

보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증 Download PDF

Info

Publication number
KR20130089655A
KR20130089655A KR1020137014523A KR20137014523A KR20130089655A KR 20130089655 A KR20130089655 A KR 20130089655A KR 1020137014523 A KR1020137014523 A KR 1020137014523A KR 20137014523 A KR20137014523 A KR 20137014523A KR 20130089655 A KR20130089655 A KR 20130089655A
Authority
KR
South Korea
Prior art keywords
supl
mobile device
server
message
slp
Prior art date
Application number
KR1020137014523A
Other languages
English (en)
Other versions
KR101530538B1 (ko
Inventor
필립 마이클 학케스
안드레아스 클라우스 베히터
아드리안 에드워드 에스콧
스테판 윌리암 에지
Original Assignee
퀄컴 인코포레이티드
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 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20130089655A publication Critical patent/KR20130089655A/ko
Application granted granted Critical
Publication of KR101530538B1 publication Critical patent/KR101530538B1/ko

Links

Images

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/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/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/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

Abstract

특정 방법은, 이동 디바이스에서, 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜을 저장하는 단계를 포함한다. 방법은 또한 저장된 디바이스 식별자와 디바이스 식별자의 비교에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스를 인증하기 위해 보안 사용자 평면 위치(SUPL) 위치 플랫폼(SPL)에 적어도 하나의 보안 크리덴셜을 전송하는 단계를 포함한다. 개시된 기법들은 SUPL 서버 및 SUPL 인에이블 단말 SET로 하여금 복수의 인증 방법들 중 어느 것이 사용될지를 협상하도록 할 수 있다.

Description

보안 사용자 평면 위치(ＳＵＰＬ) 시스템들에서의 인증{AUTHENTICATION IN SECURE USER PLANE LOCATION (SUPL) SYSTEMS}
본 개시내용은 일반적으로 보안 사용자 평면 위치(SUPL) 시스템들에서의 인증에 관한 것이다.
기술의 진보는 더 소형이고 더 강력한 컴퓨팅 디바이스들을 초래하였다. 예를 들어, 소형이고 경량이며 사용자들에 의해 용이하게 운반되는 페이징 디바이스들, 개인 디지털 정보 단말(PDA)들 및 휴대용 무선 전화들과 같은 무선 컴퓨팅 디바이스들을 포함하는 다양한 휴대용 개인 컴퓨팅 디바이스들이 존재한다. 더 구체적으로, 셀룰러 전화들 및 인터넷 프로토콜(IP) 전화들과 같은 휴대용 무선 전화들은 무선 네트워크들을 통해 음성 및 데이터 패킷들을 전달할 수 있다. 또한, 많은 이러한 무선 전화들은 포함된 다른 타입들의 디바이스들을 포함할 수 있다. 예를 들어, 무선 전화는 또한 디지털 스틸 카메라, 디지털 비디오 카메라, 디지털 레코더 및 오디오 파일 플레이어를 포함할 수 있다.
무선 전화는 또한 위치-기반 서비스들을 인에이블하기 위한 위치 결정 하드웨어/소프트웨어가 구비될 수 있다. 예를 들어, 무선 전화는 글로벌 포지셔닝 시스템(GPS) 트랜시버를 포함할 수 있다. 무선 전화는 또한 네트워크-보조 포지셔닝 정보(예를 들어, 다수의 네트워크 탑들 사이의 무선 전화의 위치 삼각측량 기반 위치탐색 정보)를 수신할 수 있다.
보안 사용자 평면 위치(SUPL)는 무선 통신 시스템들 내의 위치-기반 서비스들을 인에이블시키기 위해 사용될 수 있는 기술 표준이다. SUPL 아키텍처는 2개의 컴포넌트들: SUPL 인에이블 단말(SET) 및 네트워크-액세스가능 서버로서 구현될 수 있는 SUPL 위치 플랫폼(SPL)을 포함할 수 있다. SUPL 서비스들을 조정하기에 앞서, SET 및/또는 SLP는 서로 인증하도록 요구될 수 있다. 그러나, SUPL에서의 보안 및 인증은 어느 액세스 네트워크가 SET에 의해 사용되는지에 의존할 수 있다. 예를 들어, 제3세대 파트너쉽 프로젝트(3GPP) 또는 3GPP2 네트워크 상에서의 인증은 WiMAX(Worldwide Interoperability for Microwave Access) 네트워크 상에서의 인증과는 상이한 보안 방식을 이용할 수 있다. 또한, 전기 전자 기술자 협회(IEEE) 802.11 (Wi-Fi) 네트워크와 같은 다른 이용가능한 네트워크들의 사용은, SUPL 2.0에서 이용가능한 보안 메커니즘들에 의해 완전히 지원되지 않을 수도 있으며, 이는 SUPL-기반 기능성이, 실내에 있는 또는 열악한 셀룰러 네트워크 환경들을 경험하는 무선 전화들에 대해 이용가능하지 않게 할 수 있다.
SUPL 시스템에서의 인증의 시스템들 및 방법들이 개시된다. 개시된 시스템 시스템들 및 방법들은 3GPP, 3GPP2, WiMAX, 및 Wi-Fi 네트워크들을 포함하는 다양한 액세스 네트워크들에 대한 SET 및 SLP 사이의 상호 인증을 지원할 수 있다. 개시된 기법들은 SUPL 서버 및 SET로 하여금 복수의 인증 방법들 중 어느 것이 사용될지를 협상하게 할 수 있다. 여기서 개시된 인증 방법들은 액세스 네트워크 타입과는 독립적인 인증서-기반 인증을 포함하지만 이에 제한되지는 않는다. 특정 구현예들에서, 인증서-기반 인증은 인증 동안 SET와 SLP 사이의 보안 통신을 가능하게 하기 위해 전송층 보안(TLS)을 사용할 수 있다. 개시된 기법들은 또한 SUPL 세션 개시 및 재개시에 대해 보안을 적용한다. 추가적인 실시예들에서, 인증은 인증서-기반 인증을 통하는 것 대신 다수의 식별자/패스워드 쌍들을 통해 수행될 수 있다.
특정 실시예에서, 방법은, 이동 디바이스에서, 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜(credential)을 저장하는 단계를 포함하고, 여기서, 보안 크리덴셜은 이동 디바이스의 디바이스 식별자를 포함한다. 방법은 또한, 저장된 디바이스 식별자와 디바이스 식별자의 비교에 기초하여 보안 사용자 평면 위치(SUPL) 사용자와 연관된 것으로 이동 디바이스를 인증하기 위해 SUPL 위치 플랫폼(SPL)에 적어도 하나의 보안 크리덴셜을 전송하는 단계를 포함한다.
또 다른 특정 실시예에서, 비-일시적 프로세서 판독가능한 매체는, 프로세서에 의해 실행되는 경우, 프로세서로 하여금 SUPL 서버에서 이동 디바이스에 송신될 메시지를 생성하게 하는 명령들을 포함한다. 메시지는 SUPL 서버의 식별자 및 SUPL 서버의 공개 키를 포함하는 서버 인증서 및 이동 디바이스의 디바이스 인증서에 대한 요청을 포함한다. 명령들은, 프로세서에 의해 실행되는 경우, 프로세서로 하여금 이동 디바이스의 인증서를 포함하는 응답을 이동 디바이스로부터 수신하게 한다. 명령들은, 프로세서에 의해 실행되는 경우, 프로세서로 하여금 추가로 디바이스 인증서에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스를 인증하게 한다.
또 다른 특정 실시예에서, 장치는 프로세서 및 프로세서에 커플링되는 메모리를 포함한다. 메모리는 SUPL 서버에서 이동 디바이스에 의해 지원되는 하나 이상의 TLS 암호 스위트(cipher suite)들의 표시를 이동 디바이스로부터 수신하기 위해 프로세서에 의해 실행가능한 명령들을 저장한다. 명령들은 또한 하나 이상의 TLS 암호 스위트들이 SUPL 서버에 의해 지원되는 TLS 사전-공유 키(TLS-PSK) 암호 스위트를 포함하는지의 여부를 결정하도록 프로세서에 의해 실행가능하다. 명령들은 추가로, 하나 이상의 TLS 암호 스위트들이 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함한다는 결정에 응답하여, 이동 디바이스를 인증하기 위해 일반 부트스트랩핑 아키텍처 기반 인증 프로세스를 수행하도록 프로세서에 의해 실행가능하다. 명령들은 하나 이상의 TLS 암호 스위트들이 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함하지 않는다는 결정에 응답하여, SUPL 서버가 인증서-기반 인증 방법을 지원하는지의 여부를 결정하도록 프로세서에 의해 실행가능하다. 명령들은 또한 SUPL 서버가 인증서-기반 인증 방법을 지원한다는 결정에 응답하여, 이동 디바이스에 서버 인증서를 송신하는 것 및 이동 디바이스로부터 디바이스 인증서를 수신하는 것을 포함하는 인증서-기반 인증 프로세스를 수행하도록 프로세서에 의해 실행가능하다. 명령들은 추가로, SUPL 서버가 인증서-기반 인증 방법을 지원하지 않는다는 결정에 응답하여, 이동 디바이스가 3GPP 네트워크 또는 3GPP2 네트워크에 접속되는 경우 대안적 클라이언트 인증(ACA)-기반 인증 방법을 수행하도록 프로세서에 의해 실행가능할 수 있다.
또 다른 특정 실시예에서, 방법은, 이동 디바이스에서, SUPL 서버와 이동 디바이스 사이에 SUPL 세션을 개시하기 위해 SUPL 서버로부터 세션 개시 메시지(예를 들어, SUPL INIT 메시지를 포함함)를 수신하는 단계를 포함한다. 방법은 또한, 이동 디바이스가 세션 개시 메시지를 수신하기에 앞서 이동 디바이스가 SUPL 서버로부터 유효 세션 개시 메시지 키(예를 들어, SUPL_INIT_ROOT_KEY를 포함함)를 수신하는 것에 응답하여, 세션 개시 메시지 키를 사용하여 세션 개시 메시지를 인증하고, 세션 개시 메시지의 성공적 인증에 응답하여 SUPL 서버와의 SUPL 세션을 개시하는 단계를 포함한다.
또 다른 특정 실시예에서, 장치는 프로세서 및 프로세서에 커플링되는 메모리를 포함한다. 메모리는 이동 디바이스에서, SUPL 서버와 이동 디바이스 사이에 SUPL 세션(예를 들어, 포괄적 SUPL 세션(GSS))을 계속하기 위해 SUPL 서버로부터 세션 재개시 메시지(예를 들어, SUPL REINIT 메시지를 포함함)를 수신하도록 프로세서에 의해 실행가능한 명령들을 저장한다. 명령들은 또한, 이동 디바이스가 세션 재개시 메시지를 수신하기에 앞서 이동 디바이스가 SUPL 서버로부터 유효 세션 개시 메시지 키를 수신하는 것에 응답하여, 세션 개시 메시지 키를 사용하여 세션 재개시 메시지를 인증하고, 세션 재개시 메시지의 성공적 인증에 응답하여 SUPL 서버와의 SUPL 세션을 계속하도록 프로세서에 의해 실행가능하다.
또 다른 특정 실시예에서, 방법은 이동 디바이스로부터 SUPL 서버로 메시지를 전송하는 단계를 포함하고, 여기서 메시지는 (예를 들어, SUPL_INIT_ROOT_KEY의 상태를 표시하는) SUPL INIT 루트 키 상태 파라미터를 포함한다. 예를 들어, SUPL INIT 루트 키 상태 파라미터는 메시지의 SET 능력 파라미터에 포함될 수 있다. 또 다른 실시예에서, 방법은 SUPL 서버로부터 이동 디바이스로 SUPL END 메시지를 전송하는 단계를 포함하고, 여기서 SUPL END 메시지는 (예를 들어, 새로운 SUPL_INIT_ROOT_KEY를 제공하는) SUPL INIT 키 응답 파라미터를 포함한다. 또 다른 특정 실시예에서, 방법은 SUPL 서버로부터 이동 디바이스로 보호 레벨 파라미터를 포함하는 SUPL INIT 메시지를 전송하는 단계를 포함한다. 또 다른 실시예에서, 방법은 SUPL 서버로부터 이동 디바이스로 보호 레벨 파라미터를 포함하는 SUPL REINIT 메시지를 전송하는 단계를 포함한다.
또 다른 특정 실시예에서, 방법은, 웹 서버에서, SUPL-인에이블된 이동 디바이스로부터 메시지를 수신하는 단계를 포함하고, 여기서, 메시지는 이동 디바이스의 보안 크리덴셜을 포함한다. 방법은 또한, 웹 서버에서, 이동 디바이스로부터 사용자 식별 정보를 수신하는 단계 및 SUPL 서비스의 인가된 사용자를 식별하는 것으로 사용자 식별 정보를 인증하는 단계를 포함한다. 방법은 SUPL 서버가 SUPL 서비스의 인가된 사용자와 연관된 것으로 이동 디바이스를 인증하게 하도록 SUPL 서버에 이동 디바이스의 보안 크리덴셜을 송신하는 단계를 더 포함한다.
또 다른 특정 실시예에서, 방법은, SUPL 서버에서, 이동 디바이스로부터 제1 식별자 및 제1 패스워드를 수신하는 단계를 포함한다. 예를 들어, 제1 식별자 및 제1 패스워드는 사용자-모드 TLS 인증 프로시저 동안 수신될 수 있다. 방법은 또한, SUPL 서비스의 인가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증하는 것을 포함한다. 방법은 제1 식별자 및 제1 패스워드를 대체하기 위해 이동 디바이스에 제2 식별자 및 제2 패스워드를 송신하는 단계를 더 포함하며, 여기서, SUPL 서버는 이동 디바이스로부터 제2 식별자 및 제2 패스워드를 수신할 시에 이동 디바이스와의 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 위치 플랫폼(SPL)일 수 있고, 이동 디바이스(120)는 SUPL-인에이블 단말(SET)일 수 있다. 액세스 네트워크(130)는 3GPP 네트워크, 3GPP2 네트워크, WiMAX 네트워크, Wi-Fi 네트워크(예를 들어, IEEE 802.11 표준에 따라 동작하는 네트워크), 또는 일부 다른 무선 액세스 네트워크일 수 있다. 특정 실시예에서, 이동 디바이스(120)는 무선 전화일 수 있다.
SUPL 서버(110)는 프로세서(111) 및 프로세서(111)에 커플링되는 메모리(112)를 포함할 수 있다. 특정 실시예에서, 메모리(122)는 프로세서(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)로 전송되는 메시지들을 암호해독하도록 실행가능할 수 있다. 예를 들어, 이동 디바이스(120)로부터의 아웃고잉 메시지들은 서버 공개 키(114)를 사용하여 암호화될 수 있고, 이동 디바이스(120)로부터의 인커밍 메시지들은 서버 공개 키(114)에 대응하는 개인 키를 사용하여 암호해독될 수 있다.
이동 디바이스(120)는 프로세서(121) 및 프로세서(121)에 커플링된 메모리(122)를 포함할 수 있다. 특정 실시예에서, 메모리(122)는 프로세서(121)에 의해 실행가능한 명령들을 저장하고, 여기서, 명령들은 다양한 논리 모듈들, 컴포넌트들 및 애플리케이션들에 의해 표현될 수 있다. 메모리(122)는 또한 이동 디바이스(120)의 하나 이상의 보안 크리덴셜들을 저장할 수 있다. 예를 들어, 메모리(122)는 이동 디바이스(120)에 대한 디바이스 인증서(123)를 저장할 수 있고, 여기서, 디바이스 인증서(123)는 공개 키(124) 및 디바이스 식별자(ID)(125)를 포함한다. 이동 디바이스(120)는 또한 공개 키(124)에 대응하는 개인 키를 가질 수 있다. 디바이스 ID(125)는 국제 모바일 장비 신원(IMEI), 이동국 식별(MSID), 일련 번호, 또는 글로벌하게 고유한 다른 식별자일 수 있다. 특정 실시예에서, 디바이스 인증서(123)는 메모리(122) 내 대신 또는 이에 추가하여, 이동 디바이스(120)의 유니버셜 집적 회로 카드(UICC)에 저장될 수 있다. 메모리(122)는 인증 로직(126) 및 전송층 보안(TLS) 암호화/암호해독 로직(127)에 대응하는 실행가능한 명령들을 저장할 수 있다. 인증 로직(126)은 이동 디바이스(120)에서 SUPL 서버(110)를 인증하도록 실행가능할 수 있다. TLS 암호화/암호해독 로직(127)은 이동 디바이스(120)로부터 SUPL 서버(110)에 전송되는 메시지들을 암호화하고, SUPL 서버(110)로부터 이동 디바이스(120)에 전송되는 메시지들을 암호해독하도록 실행가능할 수 있다. 예를 들어, 이동 디바이스(120)로부터의 아웃고잉 메시지들은 디바이스 공개 키(124)를 사용하여 암호화될 수 있고, 이동 디바이스(120)로의 인커밍 메시지들은 디바이스 공개 키(124)에 대응하는 개인 키를 사용하여 암호해독될 수 있다.
특정 실시예에서, 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)는 액세스 네트워크(130)에 의해 제공되는 이동 디바이스(120)에 대응하는 IP 어드레스와 이동 디바이스(120)에 의해 제공되는 IP 어드레스를 비교함으로써 이동 디바이스(120)의 인터넷 프로토콜(IP) 어드레스 바인딩을 검증할 수 있다. 인증서-기반 인증은 액세스 네트워크(130)의 타입에 독립적일 수 있고, 액세스 네트워크(130)가 Wi-Fi 네트워크인 경우 사용될 수 있다. 메시지(132)는 SUPL 서버(110) 및 이동 디바이스(120)에 의해 지원되는 비-PSK TLS 암호 스위트, 서버 인증서(113)(서버 공개 키(114)를 포함함), 및 디바이스 인증서에 대한 요청의 표시를 포함할 수 있다. 예시를 위해, 메시지(132)는 공통적으로 지원되는 TLS 암호 스위트를 표시하는 ServerHello.cipher_suite 필드를 포함하는 ServerHello 메시지를 포함할 수 있다.
메시지(132)에 응답하여, 이동 디바이스(120)는 디바이스 인증서(123)를 포함하는 메시지(133)를 전송할 수 있다. SUPL 서버(110)는 디바이스 인증서(123) 내의 디바이스 ID(125)를 저장된 디바이스 ID(예를 들어, 도 8-9를 참조하여 추가로 설명되는 바와 같이, SUPL 사용자와 연관된 것으로 SUPL 서버(110)에 의해 이전에 보안상으로 검증된 저장된 디바이스 ID)와 비교함으로써 이동 디바이스(120)와 연관된 SUPL 사용자를 식별하려고 시도할 수 있다. 어떠한 SUPL 사용자도 식별되지 않는 경우, SUPL 서버(110) 및 이동 디바이스(120) 사이의 통신 세션이 종료될 수 있다. SUPL 사용자가 식별되는 경우, TLS 핸드쉐이크가 완료될 수 있고, SUPL 서버(110)는 SUPL 사용자에 대해 프로비져닝되는 SUPL-기반 서비스들(예를 들어, 위치-기반 서비스들)에 대한 이동 디바이스(120) 액세스를 승인할 수 있다.
특정 실시예들에서, 상이한 인증 방법들이 또한 이용가능할 수 있다. 예를 들어, 이동 디바이스(120)가 WiMAX-호환가능 디바이스이고 그리고/또는 액세스 네트워크(130)가 WiMAX 네트워크일 때, 이동 디바이스(120) 및 SUPL 서버(110) 모두가 SUPL 암호화 키(SEK)-기반 인증 방법을 지원하는 경우, SEK-기반 인증 방법이 SUPL 서버(110) 및 이동 디바이스(120)의 상호 인증에 대해 더 바람직할 수 있다. 또 다른 예로서, SUPL 서버(110)가 인증서-기반 인증을 지원하지 않는 경우, SUPL 서버(110)는 (이동 디바이스(120)가 3GPP 또는 3GPP2 액세스 네트워크 상에 있는 경우 액세스 네트워크-종속적 상호 인증을 제공할 수 있는) ACA 또는 (비-상호 인증을 제공하고 일반적으로 비상 시나리오들 동안만 사용될 수 있는) SLP-전용 인증과 같은, 상이한 인증 방법을 개시하기 위한 디바이스 인증서에 대한 요청 없이 메시지(132)를 전송할 수 있다.
따라서, 도 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)를 통해 이동 디바이스(120)에 서버 인증서(113)를 전송하는 것 및 메시지(133)를 통해 이동 디바이스(120)로부터 디바이스 인증서(123)를 수신하는 것을 포함하는 인증서-기반 프로시저를 수행할 수 있다.
특정 실시예들에서, 도 2의 방법(200)은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 2의 방법(200)은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
도 3을 참조하면, 인증서들을 사용하는 SUPL 환경에서 인증을 수행하는 방법의 특정 실시예가 도시되며, 일반적으로 300으로 표기된다. 예시적인 실시예에서, 방법(300)은 도 1의 이동 디바이스(120)에 의해 수행될 수 있다.
방법(300)은, 302에서, 이동 디바이스에서, 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜을 저장하는 단계를 포함할 수 있다. 적어도 하나의 보안 크리덴셜은 이동 디바이스의 디바이스 식별자를 포함할 수 있다. 예를 들어, 도 1에서, 이동 디바이스(120)는 디바이스 ID(125)(예를 들어, IMEI, MSID, 일련 번호, 또는 또 다른 글로벌하게 고유한 식별자)를 포함하는 디바이스 인증서(123)를 저장할 수 있다.
방법(300)은 또한 304에서, 저장된 디바이스 식별자와 디바이스 식별자의 비교에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스를 인증하기 위해 SUPL 위치 플랫폼(SLP)에 적어도 하나의 보안 크리덴셜을 전송하는 단계를 포함할 수 있다. 예를 들어, 도 1에서, 이동 디바이스(120)는, SUPL 서버(110)가 또 다른 엔티티에 의해 이전에 제공된 저장된 디바이스 ID와 디바이스 ID(125)의 비교에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스(120)를 인증할 수 있도록, 메시지(133)를 통해 SUPL 서버(110)(예를 들어, SPL)에 디바이스 인증서(123)를 전송할 수 있다.
특정 실시예들에서, 도 3의 방법은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 3의 방법(300)은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
도 4를 참조하면, 인증서들을 사용하는 SUPL 환경에서 인증을 수행하는 방법의 또 다른 특정 실시예가 도시되며 일반적으로 400으로 표기된다. 예시적인 실시예에서, 방법(400)은 도 1의 SUPL 서버에 의해 수행될 수 있다.
방법(400)은, 402에서, SUPL 서버에서, 이동 디바이스에 의해 지원되는 하나 이상의 TLS 암호 스위트들의 표시를 이동 디바이스로부터 수신하는 단계를 포함할 수 있다. 예를 들어, 도 1에서, SUPL 서버(110)는 이동 디바이스(120)로부터 메시지(131)를 수신할 수 있고, 여기서, 메시지(131)는 이동 디바이스(120)에 의해 지원되는 하나 이상의 TLS 암호 스위트들을 표시한다.
방법(400)은 또한, 404에서, SUPL 서버로부터 이동 디바이스로 메시지를 송신하는 단계를 포함할 수 있다. 메시지는 SUPL 서버의 식별자 및 SUPL 서버의 공개 키, 이동 디바이스의 디바이스 인증서에 대한 요청, 및 TLS 암호 스위트들 중 적어도 하나의 선택을 포함하는 서버 인증서를 포함할 수 있다. 예를 들어, 도 1에서, SUPL 서버(110)는 이동 디바이스(120)에 메시지(132)를 송신할 수 있고, 메시지(132)는 서버 ID(115), 서버 공개 키(114), 이동 디바이스(120)의 디바이스 인증서(123)에 대한 요청, 및 공통적으로 지원되는 TLS 암호 스위트의 선택을 포함한다.
방법(400)은, 406에서, 이동 디바이스의 디바이스 인증서를 포함하는 응답을 이동 디바이스로부터 수신하는 단계를 더 포함할 수 있다. 예를 들어, 도 1에서, SUPL 서버(110)는 디바이스 인증서(123)를 포함하는 메시지(133)를 수신할 수 있다.
방법(400)은, 408에서, 디바이스 인증서에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스를 인증하는 단계를 포함할 수 있다. 예를 들어, 도 1에서, SUPL 서버(110)에서의 인증 로직(116)은 디바이스 인증서(123)에 기초하여 SUPL 사용자와 연관된 것으로 이동 디바이스(120)를 인증할 수 있다.
특정 실시예들에서, 도 4의 방법(400)은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 4의 방법(400)은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
도 1-4를 참조하여 설명된 어느 인증 방법이 사용되는지와는 무관하게, 일단 인증이 완료되면, SUPL 서버(예를 들어, SLP) 및 이동 디바이스(예를 들어, SET)는 SUPL 세션 동안 SUPL-기반 서비스들에 관련하여 통신할 수 있다. 도 5를 참조하여, SUPL 서버(510)와 이동 디바이스(520) 사이에서 교환될 수 있는 메시지들의 특정 실시예가 도시되며, 일반적으로 500으로 표기된다.
특정 실시예에서, SUPL 서버(510) 및 이동 디바이스(520)는 SUPL 세션의 상황에서 사용자 위치 프로토콜(ULP) 메시지들을 통해 통신할 수 있다. 예를 들어, SUPL 서버(510)는 이동 디바이스(520)에 SUPL INIT 메시지(530)를 전송하도록 구성될 수 있다. SUPL INIT 메시지(530)는 SUPL 세션을 개시하기 위해 SUPL 서버(110)에 의해 전송되는 세션 개시 메시지를 나타낼 수 있다. 매스커레이딩(masquerading) 및 리플레이 공격들에 대해 보호하기 위해, 보호는 SUPL INIT 메시지(530)에 적용될 수 있다. 특정 실시예에서, SUPL INIT 메시지(530)는 보호 레벨 파라미터를 포함할 수 있다. 보호 레벨 파라미터는 (널, 모드 A, 또는 모드 B SUPL INIT 보호가 구현될 수 있는지의 여부를 표시하는) 레벨 파라미터 및(예를 들어, 키 식별자 타입 및 키 식별자 중 적어도 하나를 포함하는) 보호 파라미터 중 적어도 하나를 포함할 수 있다. 특정 실시예에서, 널 SUPL INIT 보호는 종단-대-종단 무결성 및 리플레이 보호를 제공하지 않을 수 있고, 모드 A SUPL INIT 보호는 보안된 ULP 세션 동안 SUPL 서버(510)에 의해 이동 디바이스(520)에 전송되는 공유 키의 사용에 의해 종단-대-종단 무결성 및 리플레이 보호를 제공할 수 있고, 모드 B SUPL INIT 보호는 PSK-기반 방법들(예를 들어, GBA 또는 SEK 방법들)로부터 유도된 공유 키를 사용하여 종단-대-종단 무결성 및 리플레이 보호를 제공할 수 있다.
특정 실시예에서, SUPL INIT 보호는 세션 개시 키(예를 들어, SUPL_INIT_ROOT_KEY)에 기초하여 구현될 수 있다. 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_ROOT_KEY에 대한 요청을 나타내는 SUPL_INIT_KeyRequest 파라미터를 포함하는 메시지를 전송할 수 있다. 대안적으로, 이동 디바이스(520)는 새로운 SUPL_INIT_ROOT_KEY를 요청하는 것 대신, 무효한 또는 비동기 SUPL_INIT_ROOT_KEY의 존재를 표시할 수 있다. 예를 들어, 이동 디바이스(520)는 이동 디바이스(520)에 의해 소유되는 "현재" SUPL_INIT_ROOT_KEY가 무효한지 또는 비동기인지의 여부를 표시하는 SUPL INIT 루트 키 상태 파라미터(541)를 포함하는 ULP 메시지(540)를 전송할 수 있다. 특정 실시예에서, SUPL INIT 루트 키 상태 파라미터(541)는 ULP 메시지(540)의 SET 능력 파라미터 내에 포함될 수 있다. SET 능력 파라미터 내에 SUPL INIT 루트 키 상태 파라미터(541)를 포함하는 것은 SUPL_INIT_ROOT_KEY 상태 정보를 전송할 목적으로 전용 메시지를 도입할 필요 없이 SET 능력 파라미터를 선택적으로 또는 의무적으로 포함하는 SUPL 2.0에 정의된 메시지들에서 SUPL_INIT_ROOT_KEY 상태 정보의 전송을 가능하게 할 수 있다는 점이 이해될 것이다. 특정 실시예에서, SUPL INIT 루트 키 상태 파라미터(541)가 널 보호 또는 모드 B SUPL INIT 보호에 대해서가 아니라, 모드 A SUPL INIT 보호에 대한 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 세션이 SLP로부터 SET로의 SUPL END 메시지에 의해 종료되지 않는 경우) 동일한 SUPL 세션에 있지 않을 수 있는 "레귤러" 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))를 전송할 수 있다. SUPL REINIT 보호는 SUPL INIT 보호를 참조하여 여기서 설명되는 바와 같이 구현될 수 있다. 예를 들어, 이동 디바이스(520)가 유효한 SUPL_INIT_ROOT_KEY를 소유하지 않는 경우(SUPL_INIT_ROOT_KEY가 세션 개시 키 및 세션 재개시 키 모두로서의 역할을 할 수 있는 경우), 이동 디바이스(520)는 SUPL INIT 루트 키 상태 파라미터(541)를 통해 유효한 SUPL_INIT_ROOT_KEY의 부재를 표시할 수 있고, 그 응답으로, (SUPL INIT 키 응답 파라미터(551)를 포함하는) SUPL END 메시지(550)를 수신할 수 있다. 이동 디바이스(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)는 널 SUPL INIT 보호 및 널 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는 NULL SUPL INIT 보호와의 세션을 수행할 수 있고, SET는 자신의 SUPL_INIT_ROOT_KEY가 무효한 세션 동안 표시를 전송할 수 있다. 예를 들어, 도 5에서, 이동 디바이스(520)는 SUPL 서버(510)에 SUPL INIT 루트 키 상태 파라미터(541)를 포함하는 메시지를 전송할 수 있고, SUPL INIT 키 응답 파라미터(551)를 포함하는 메시지를 그 응답으로 수신할 수 있다.
특정 실시예들에서, 도 6의 방법(600)은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 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 서버(510)에 SUPL INIT 루트 키 상태 파라미터(541)를 포함하는 메시지를 전송할 수 있고, SUPL INIT 키 응답 파라미터(551)를 포함하는 메시지를 그 응답으로 수신할 수 있다.
특정 실시예들에서, 도 7의 방법(700)은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 7의 방법(700)은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
특정 실시예에서, 이동 디바이스 및 SUPL 서버 사이의 상호 인증은 인증서-기반, GBA-기반, SEK-기반, ACA-기반, 및 SLP-전용 방법들이 아닌 방법들을 통해 수행될 수 있다. 예를 들어, 도 8은 다수의 식별자들/패스워드들을 사용하는 SUPL 환경에서의 인증을 수행하도록 동작가능한 시스템(800)의 특정 실시예를 예시한다. 시스템(800)은 SUPL 서버(예를 들어, SLP)(820)와 통신할 수 있는 이동 디바이스(810)(예를 들어, SET)를 포함한다.
다수의 식별자들/패스워드들에 기초한 인증에 추가하여, 도 8의 시스템(800)은 또한 SUPL 사용자에 대한 디바이스 인증서의 바인딩의 특정한 예를 예시한다. 예를 들어, 시스템(800)은 디바이스 인증서와 SUPL 사용자 사이의 바인딩을 생성하기 위한 메커니즘을 제공하기 위한 웹 서버(830)를 포함할 수 있다. 웹 서버(830)가 SUPL 세션들에 대한 인증을 제공하는 것이 아니라, 오히려 SUPL 인증 동안 SLP에 의해 후속적으로 사용될 수 있는 바인딩 정보를 제공할 수 있다는 점에 유의해야 한다. 이러한 바인딩은 통상적으로 오직 한번 수행될 수 있으며, SET가 SUPL 세션들에 관여할 수 있기 전에 수행될 수 있다. 일단 바인딩이 수행되면, 디바이스 인증서 및 사용자 정보의 조합은 SLP에 송신될 수 있고, SLP는 이 정보를 저장하고, 클라이언트 인증을 위해 이를 사용할 수 있다. 따라서, 바인딩이 수행된 이후, SLP는 특정 이동 디바이스가 특정 SUPL 사용자에게 속한다는 것을 "알 수" 있다. 웹 서버(830)는 프로세서(831) 및 프로세서(831)에 의해 실행가능한 명령들을 저장하는 메모리(832)를 포함할 수 있다. 예를 들어, 명령들은 인증 로직(833)을 나타낼 수 있다. 웹 서버(830)는 또한 이동 디바이스(810)와, 그리고 SUPL 서버(820)와 통신하도록 동작가능한 네트워크 인터페이스(834)를 포함할 수 있다. 웹 서버(830)가 사용자에게 디바이스 인증서의 바인딩을 제공하는 방법의 단지 일 예라는 점에 유의해야 한다. 다른 실시예들에서, 다른 바인딩 메커니즘이 사용될 수 있다. 대안적으로, 웹 서버(830)는 디바이스 인증서 및 사용자 정보의 조합을 저장할 수 있고, SLP는(디바이스 인증서를 사용하여 디바이스의 상호 인증을 수행할 시에) 디바이스 인증서와 연관된 사용자 정보를 제공하도록 웹 서버(830)에 요청할 수 있다.
이동 디바이스(810)는 인증 로직(811)(예를 들어, 이동 디바이스(810)의 메모리에 저장되고 이동 디바이스(810)의 프로세서에 의해 실행가능한 명령들)을 포함할 수 있다. 인증 로직(811)은 이동 디바이스(810)를 특정 SUPL 사용자와 연관(예를 들어, "바인드" 또는 "등록")시키기 위해 웹 서버(830)에서 대응하는 인증 로직(833)과 통신하도록 구성될 수 있다. 예를 들어, 바인딩 프로세스는 이동 디바이스(810)가 웹 서버(830)로부터 메시지(835)를 수신하는 것으로 시작할 수 있고, 여기서, 메시지(835)는 웹 서버(830)의 서버 인증서 및 웹 서버(830)의 공개 키를 포함한다. 이동 디바이스(810)는 웹 서버(830)에 메시지(813)를 전송함으로써 응답할 수 있고, 여기서, 메시지(813)는 이동 디바이스(810)의 보안 크리덴셜을 포함한다. 예를 들어, 이동 디바이스(810)의 보안 크리덴셜은 공개 키, 국제 모바일 장비 신원(IMEI), 이동국 식별(MSID), 및/또는 이동 디바이스(810)의 일련 번호를 포함하는 디바이스 인증서를 포함할 수 있다. 이동 디바이스(810)는 또한, 웹 서버(830)에 사용자 식별 정보(예를 들어, SUPL 사용자와 연관된 사용자 식별자 및 패스워드)를 포함하는 메시지(814)를 전송할 수 있다. 메시지들(813, 814) 중 하나 또는 둘 모두는 웹 서버(830)의 공개 키를 사용하여 암호화될 수 있고, 웹 서버(830)는 웹 서버(830)의 개인 키를 사용하여 암호화된 메시지(들)를 암호해독할 수 있다.
웹 서버(830)는 사용자 식별 정보가 SUPL 서비스의 인가된 사용자와 연관되는지의 여부를 결정하기 위해 이동 디바이스(810)에 의해 제공되는 사용자 식별 정보를 인증할 수 있다. 예를 들어, 웹 서버(830)는 웹 서버(830)에 위치되거나 액세스 가능한 SUPL 사용자 데이터베이스와 제공된 사용자 식별 정보를 비교할 수 있다. 사용자 식별 정보의 검증 시에, 웹 서버(830)는 SUPL 서비스의 인가된 사용자와 연관된 것으로 이동 디바이스(810)를 인증하기 위해 SUPL 서버(820)에 메시지(836)를 송신함으로써 바인딩 프로세스를 완료할 수 있다. 메시지(836)는 이동 디바이스(810)의 보안 크리덴셜(예를 들어, 디바이스 공개 키 및 IMEI, MSID 및/또는 일련 번호를 포함하는 디바이스 인증서)을 포함할 수 있다.
이동 디바이스(810)의 인증 로직(811)은 또한 SUPL 세션의 개시 또는 재개시 이전에 사용자-모드 TLS-기반 상호 인증을 수행하기 위해 SUPL 서버(820)에서 대응하는 인증 로직(821)과 통신하도록 구성될 수 있다. 예를 들어, 이동 디바이스(810)는 SUPL 서버(820)에 메시지(815)를 전송할 수 있고, 메시지(815)는 제1 식별자 및 제1 패스워드를 포함한다. 특정 실시예에서, 제1 패스워드는 사용자-선택될 수 있고, 상대적으로 낮은 암호 강도를 가질 수 있다. 예시적인 실시예에서, 제1 식별자 및 제1 패스워드는 메시지(814)를 통해 웹 서버(830)에 이동 디바이스(810)에 의해 전송된 식별자 및 패스워드에 대응할 수 있다.
제1 식별자 및 제1 패스워드의 수신 시에, 인증 로직(821)은 SUPL 서버의 허가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증할 수 있다. 예를 들어, 인증 로직(821)은 제1 식별자 및 제1 패스워드가 이동 디바이스(810)에 이전에 바인딩된 허가된 사용자에 대응함을 검증할 수 있다. 인증이 성공적인 경우, SUPL 서버(820)에서의 식별자/패스워드 생성 로직(822)은 제1 식별자 및 제1 패스워드를 대체하기 위해 제2 식별자 및 제2 패스워드를 생성할 수 있다. 특정 실시예에서, 제2 패스워드는 제1 패스워드보다 더 큰 암호 강도를 가질 수 있다. SUPL 서버(820)는 메시지(824)를 통해 이동 디바이스(81)에 제2 식별자 및 제2 패스워드를 전송할 수 있다. 이동 디바이스(810)로부터의 제2 식별자 및 제2 패스워드의 후속적 수신시에, SUPL 서버(820)는 이동 디바이스(810)와의 SUPL 세션을 설정할 수 있다. 특정 실시예에서, 제2 식별자 및 제2 패스워드는 보안 목적으로 이동 디바이스(810)의 사용자로부터 계속 숨겨질 수 있다.
이전 설명이 단일 이동 디바이스(예를 들어, SET)와 연관된 SUPL 사용자와 관련되지만, SUPL 사용자는 다수의 디바이스들과 연관될 수 있다. 예를 들어, 이동 디바이스(810)와 연관된 SUPL 사용자는 또한, 제2 이동 디바이스(840)에 대한 액세스를 가질 수 있다. 제2 이동 디바이스(840)를 허가하기 위해, SUPL 사용자는 제1 이동 디바이스(810)를 바인딩하는 것과 유사한 방식으로, 자신의 계정(예를 들어, SUPL 계정)에 제2 이동 디바이스(840)를 바인딩할 수 있다. 제2 이동 디바이스(840)가 SUPL 사용자의 계정에 바인딩된 이후 상호 인증을 수행하기 위해, 제2 이동 디바이스(840)는 SUPL 서버(820)에 제1 식별자 및 제1 패스워드를 포함하는 메시지(841)를 전송할 수 있다. 허가된 SUPL 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증할 시에, SUPL 서버(820)는 제2 이동 디바이스(840)가 또한 SUPL 서비스에 대해 액세스하도록 승인되어야 하는지의 여부를 결정할 수 있다. 예를 들어, SUPL 서버(820)는 사용자-당-디바이스 제한을 구현할 수 있고, 제2 이동 디바이스(840)로 하여금 SUPL 서비스를 액세스하게 하는 것이 SUPL 서비스를 액세스하도록 허용되는 허가된 사용자와 연관된 이동 디바이스들의 임계 개수를 초과할 것인지의 여부를 결정할 수 있다. 제2 이동 디바이스(840)로 하여금 SUPL 서비스를 액세스하도록 허용하는 것이 임계를 초과하지 않을 경우, SUPL 서버(820)는 제2 이동 디바이스(840)에 제3 식별자 및 암호적으로 강한 제3 패스워드를 포함하는 메시지(825)를 송신할 수 있다. 제3 식별자 및 제3 패스워드는 제1 식별자 및 제1 패스워드를 대체할 수 있고, SUPL 세션을 개시하기 위해 제2 이동 디바이스(840)에 의해 후속적으로 사용될 수 있다.
특정 실시예에서, 제3 식별자 및 제3 패스워드는 제1 이동 디바이스(810)에 송신된 제2 식별자 및 제2 패스워드와는 다를 수 있다. SUPL 사용자의 각각의 이동 디바이스에 다른 식별자/패스워드 조합들을 제공함으로써, SUPL 서버(820)는 각 디바이스 단위로 모니터링을 구현할 수 있다. 예를 들어, SUPL 서버(820)에서의 모니터링 로직(823)은 제2 식별자를 사용하여 제1 이동 디바이스(810)에 의해 SUPL 서비스의 사용을 모니터링하고, 제3 식별자를 사용하여 제2 이동 디바이스(840)에 의해 SUPL 서비스의 사용을 모니터링하도록 구성될 수 있다.
따라서, 도 8의 시스템(800)은 어느 하나 이상의 이동 디바이스들이 특정 SUPL 사용자와 바인딩되고, 등록되고, 그리고/또는 연관되는지에 의해 바인딩 프로세스를 제공할 수 있다. 설명된 바인딩 프로세스가 도 1-4를 참조하여 설명된 인증 프로세스들을 선택적으로 보충할 수 있다는 점이 이해될 것이다. 예를 들어, 도 1을 참조하여 설명된 바와 같이, SUPL 서버(110)는 SUPL 사용자에 의해 이전에 보안적으로 검증된 저장된 디바이스 ID와 이동 디바이스의 디바이스 ID(125)를 비교함으로써, 이동 디바이스(120)와 연관된 것으로 SUPL 사용자를 식별하도록 시도할 수 있다. 예시적인 실시예에서, 도 1의 SUPL 서버(110)는 SUPL 서버(820)일 수 있고, 도 1의 이동 디바이스(120)는 이동 디바이스(810)일 수 있고, 저장된 디바이스 ID는 바인딩 프로세스 동안 메시지(836)를 통해 SUPL 서버(820)에 제공되는 디바이스 보안 크리덴셜에 포함될 수 있다.
추가로, 도 8의 시스템(800)은 도 1-4를 참조하여 설명된 인증 프로세스들을 선택적으로 대체할 수 있는 인증 프로세스를 제공할 수 있다. 예를 들어, 특정 실시예들은 GBA-기반 상호 인증, SEK-기반 상호 인증, 및/또는 인증서-기반 상호 인증 대신, 도 8의 다수의 식별자들/패스워드들 인증 프로세스를 사용하는 것을 수반할 수 있다.
도 9를 참조하면, 웹 서버를 사용하여 SUPL 환경에서의 인증 방법의 특정 실시예가 도시되고 일반적으로 900으로 표기된다. 예시적인 실시예에서, 방법(900)은 도 8의 웹 서버(830)에 의해 수행될 수 있다.
방법(900)은, 902에서, 웹 서버로부터 SUPL-인에이블 이동 디바이스로 서버 인증서를 송신하는 단계를 포함할 수 있다. 서버 인증서는 웹 서버의 공개 키를 포함한다. 예를 들어, 도 8에서, 웹 서버(830)는 이동 디바이스(810)에 메시지(835)를 송신할 수 있고, 메시지(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)에 디바이스 보안 크리덴셜을 전송할 수 있다.
특정 실시예들에서, 도 9의 방법은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 9의 방법은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
도 10을 참조하면, 다수의 식별자들/패스워드들을 사용하는 SUPL 환경에서의 인증 방법의 특정 실시예가 도시되고, 일반적으로 100으로 표기된다. 예시적인 실시예에서, 방법(1000)은 도 8의 SUPL 서버(820)에 의해 수행될 수 있다.
방법(1000)은, 1002에서, SUPL 서버에서, 이동 디바이스로부터 제1 식별자 및 제1 패스워드를 수신하는 단계, 및 1004에서, SUPL 서비스의 인가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증하는 단계를 포함할 수 있다. 예를 들어, 도 8에서, SUPL 서버(820)는 메시지(815)를 통해 이동 디바이스(810)로부터 제1 식별자 및 제1 패스워드를 수신할 수 있고, 허가된 사용자(예를 들어, 이동 디바이스(810)에 이전에 바인딩된 허가된 사용자)와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증할 수 있다.
방법(1000)은 1006에서, 제1 식별자 및 제1 패스워드를 대체하기 위해 이동 디바이스에 제2 식별자 및 제2 패스워드를 송신하는 단계를 또한 포함할 수 있다. SUPL 서버는 이동 디바이스로부터 제2 식별자 및 제2 패스워드를 수신할 시에 이동 디바이스와의 SUPL 세션을 설정하도록 구성될 수 있다. 예를 들어, 도 8에서, SUPL 서버(820)는 제2 식별자 및 제2 패스워드를 생성하여 메시지(824)를 통해 이동 디바이스(810)에 송신할 수 있고, 제2 식별자 및 제2 패스워드의 후속적인 수신 시에 이동 디바이스(810)와의 SUPL 세션을 설정할 수 있다.
방법(1000)은 1008에서, SUPL 서버에서, 제2 이동 디바이스로부터 제1 식별자 및 제1 패스워드를 수신하는 단계, 및 1010에서, SUPL 서비스의 인가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증하는 단계를 더 포함할 수 있다. 예를 들어, 도 8에서, SUPL 서버(820)는 메시지(841)를 통해 제2 이동 디바이스(840)로부터 제1 식별자 및 제1 패스워드를 수신할 수 있고, 허가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증할 수 있다. 예시를 위해, 제2 이동 디바이스(804)는 또한 도 9의 방법(900)을 통해 허가된 사용자에 이전에 바인딩 되었을 수도 있다.
방법(1000)은 1012에서, 제2 이동 디바이스로 하여금 SUPL 서비스에 액세스하도록 허용하는 것이 SUPL 서비스에 액세스하도록 허용되는 허가된 사용자와 연관된 이동 디바이스들의 임계 개수를 초과할 것인지의 여부를 결정하는 단계를 포함할 수 있다. 예를 들어, 도 8에서, 웹 서버(820)는 제2 이동 디바이스(840)로 하여금 SUPL 서비스에 액세스하도록 허용하는 것이 임계를 초과할 지의 여부를 결정할 수 있다. 특정 실시예에서, 제2 이동 디바이스(840)로 하여금 SUPL 서비스에 액세스하도록 허용하는 것이 임계를 초과하지 않을 경우, 웹 서버(820)는 메시지(825)를 통해 제2 이동 디바이스에 제3 식별자 및 제3 패스워드를 전송할 수 있다. 웹 서버(820)는 또한, 제1 이동 디바이스(810) 및 제2 이동 디바이스(840)에 의해 SUPL 서비스의 사용을 모니터링할 수 있다.
특정 실시예들에서, 도 10의 방법(1000)은 필드-프로그램가능 게이트 어레이(FPGA) 디바이스, 주문형 집적 회로(ASIC), 프로세싱 유닛, 예컨대, 중앙 처리 장치(CPU), 디지털 신호 프로세서(DSP), 제어기, 또 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 이들의 임의의 조합을 통해 구현될 수 있다. 일 예로서, 도 10의 방법(1000)은 명령들을 실행하는 프로세서에 의해 수행될 수 있다.
도 11을 참조하면, 무선 통신 디바이스의 특정 예시적인 실시예의 블록도가 도시되고, 일반적으로 1100으로 표기된다. 예를 들어, 디바이스(1100)는 도 1의 이동 디바이스(120), 도 5의 이동 디바이스(520), 도 8의 제1 이동 디바이스(810), 또는 도 8의 제2 이동 디바이스(840)와 같은 SUPL-인에이블 단말(SET)일 수 있다.
디바이스(1100)는 메모리(1132)에 커플링되는 프로세서(1110)를 포함할 수 있다. 메모리(1132)는 여기서 개시된 방법들 및 프로세스들, 예를 들어, 도 3의 방법(300), 도 6의 방법(600), 도 7의 방법(700), 또는 이들의 임의의 조합을 수행하기 위해 프로세서(1110)에 의해 실행가능한 명령들(1160)을 포함할 수 있다.
도 11은 또한 프로세서(1110) 및 디스플레이(1128)에 커플링되는 디스플레이 제어기(1126)를 도시한다. CODEC(1134)은 프로세서(1110)에 그리고 스피커(1136) 및 마이크로폰(1138)에 커플링될 수 있다. 도 11은 또한 하나 이상의 무선 제어기들(1140)이 프로세서(1110) 및 무선 안테나들(1142, 1143)에 커플링될 수 있음을 표시한다. 특정 실시예에서, 안테나(1142)는 3GPP, 3GPP2, 및/또는 WiMAX 안테나일 수 있고, 안테나(1143)는 Wi-Fi 안테나일 수 있다. 카드 인터페이스(1170)는 또한 프로세서(1110) 및 무선 제어기(들)(1140)에 커플링될 수 있다. 카드 인터페이스(1170)는 디바이스(1110)의 보안 크리덴셜(들)을 저장하는 카드(1172)(예를 들어, 가입자 신원 모듈(SIM) 카드, 유니버셜 집적 회로 카드(UICC), 또는 다른 카드)를 수용하도록 구성될 수 있다. 예를 들어, 보안 크리덴셜은 디바이스 인증서, 공개/개인 키 쌍, IMEI, MSID, 일련 번호, 글로벌 고유 식별자, 또는 이들의 임의의 조합을 포함할 수 있다. 대안적으로, 또는 추가적으로, 디바이스(1100)의 보안 크리덴셜(들)은 메모리(1132)의 "보안"(예를 들어, 사용자에 의해 수정가능하지 않고 그리고/또는 액세스가능하지 않은) 위치, 예를 들어, 보안 크리덴셜(들)(1161)에 저장될 수 있다.
특정 실시예에서, 프로세서(1110), 디스플레이 제어기(1126), 메모리(1132), CODEC(1134), 무선 제어기(들)(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), 데이터를 저장하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 또한 SUPL 사용자와 연관된 것으로 이동 디바이스를 인증하기 위해 이동 디바이스로 하여금 SLP에 적어도 하나의 보안 크리덴셜을 전송하게 하기 위한 수단을 포함할 수 있다. 예를 들어, 전송하게 하기 위한 수단은 도 1의 프로세서(121), 도 11의 프로세서(1110), 도 1의 무선 제어기(들)(1140), 데이터의 전송을 야기하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다.
추가로, 웹 서버에서, SUPL-인에이블 이동 디바이스로부터 메시지를 수신하기 위한 수단을 포함하는 장치가 개시되며, 여기서, 메시지는 이동 디바이스의 보안 크리덴셜을 포함한다. 예를 들어, 메시지를 수신하기 위한 수단은 도 8의 네트워크 인터페이스(834), 데이터를 수신하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 또한, 웹 서버에서, 이동 디바이스로부터 사용자 식별 정보를 수신하기 위한 수단을 포함한다. 예를 들어, 사용자 식별 정보를 수신하기 위한 수단은 도 8의 네트워크 인터페이스(834), 데이터를 수신하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 또한 SUPL 서비스의 인가된 사용자를 식별하는 것으로 사용자 식별 정보를 인증하기 위한 수단을 포함한다. 예를 들어, 인증하기 위한 수단은 도 8의 프로세서(831), 사용자 식별 정보를 인증하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 SUPL 서버로 하여금 SUPL 서비스의 인가된 사용자와 연관된 것으로 이동 디바이스를 인증하게 하기 위해 SUPL 서버에 이동 디바이스의 보안 크리덴셜을 송신하기 위한 수단을 포함한다. 예를 들어, 송신하기 위한 수단은 도 8의 네트워크 인터페이스(834), 데이터를 수신하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다.
또한, SUPL 서버에서, 이동 디바이스로부터 제1 식별자 및 제1 패스워드를 수신하기 위한 수단을 포함하는 장치가 개시된다. 예를 들어, 수신하기 위한 수단은 도 8의 SUPL 서버(820)의 네트워크 인터페이스, 데이터를 수신하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 또한, SUPL 서비스의 인가된 사용자와 연관된 것으로 제1 식별자 및 제1 패스워드를 인증하기 위한 수단을 포함한다. 예를 들어, 식별하기 위한 수단은 도 8의 인증 로직(821)을 실행하도록 프로그래밍되는 프로세서, 예컨대 도 1의 프로세서(111), 식별자 및 패스워드를 인증하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합을 포함할 수 있다. 장치는, 제1 식별자 및 제1 패스워드를 대체하기 위해 이동 디바이스에 제2 식별자 및 제2 패스워드를 송신하기 위한 수단을 더 포함하고, 여기서, SUPL 서버는 이동 디바이스로부터 제2 식별자 및 제2 패스워드를 수신할 시에 이동 디바이스와의 SUPL 세션을 설정하도록 구성된다. 예를 들어, 송신하기 위한 수단은 SUPL 서버(820)의 네트워크 인터페이스, 데이터를 송신하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합일 수 있다. 장치는 제2 식별자 및 제2 패스워드를 생성하기 위한 수단을 포함할 수 있다. 예를 들어, 생성하기 위한 수단은 도 8의 식별자/패스워드 생성 로직(822)을 실행하도록 프로그래밍되는 프로세서, 예컨대 도 1의 프로세서(111), 식별자 및 패스워드를 생성하도록 구성되는 하나 이상의 디바이스들, 또는 이들의 임의의 조합을 포함할 수 있다.
특정 실시예들에서, 전술된 시스템들 및 방법들의 일부 또는 전부가 하기 추가적인 실시예를 참조하여 설명되는 시스템들 및 방법들을 참조하여 추가로 설명될 수 있고, 그리고/또는 하기 추가적인 실시예를 참조하여 설명되는 시스템들 및 방법들에 의해, 개별적으로 또는 결합하여, 선택적으로 대체될 수 있다.
추가적인 실시예 1
서문
● SUPL 2.0에서의 보안은 액세스 네트워크 특정적이다:
● 대안적인 클라이언트 인증(ACA)은 소스 IP 어드레스에 기초하여 SET를 식별하기 위해 코어 네트워크에 대한 액세스를 요구한다
● GBA는 3GPP/3GPP2 네트워크들에 대해서만 적용가능하다
● SEK는 WiMAX 네트워크에 대해서만 적용가능하다
● SUPL 3.0에서의 새로운 요건은 모든 액세스 네트워크들에 대해 적용가능한 인증 메커니즘을 요청한다. 이러한 실시예는 모든 액세스 네트워크들에 대해 적용가능한 새로운 보안 메커니즘을 설명한다:
● GBA 및 "사용자명/패스워드" 인증 모두를 지원하는 단순한 프레임워크
● 단일 TLS 변형이 사용될 수 있다
● 사양 및 구현예에 대한 최소의 변경들
개념 개요
● ULP 보안
● 서버 인증서들을 가지는 TLS
● 2개의 클라이언트 인증 모드들
- (사용자 모드): (사용자_ID, 사용자_비밀) = (사용자명, 패스워드)
- (GBA 모드):(사용자_ID, 사용자_비밀) =(B-TID, Ks_NAF)
● (사용자_ID, 카운터, 다이제스트)가 모든 메시지들에 추가되며, 다이제스트는:
● A1 = SLP_도메인||ULP_메시지
● 다이제스트 = HMAC(사용자_비밀, A1)
로서 계산된다
● 송신기는 (사용자_ID, 카운터, 다이제스트)를 모든 메시지들에 추가하고, 수신기는 검증한다
● ULP가 SUPL INIT 크리덴셜을 업데이트하기 위해 사용된다
● SUPL INIT 보호[예를 들어, 비-비상상황에만]
● 모의 ULP v2.0 기본 SUPL INIT 보호
● ULP를 통해 SLP에 의해 제공되는 SUPL INIT 크리덴셜들을 사용한다
셋업 상세항목들
● 오프라인
● (사용자 모드) 사용자 및 SLP가 (사용자명, 패스워드)에 동의한다
- SLP가 사용자에게 (사용자명, 패스워드)를 제공할 수 있다
- 사용자가 SLP에 (사용자명, 패스워드)를 제공할 수 있다
- 이것은 H-SLP 또는 A-SLP 모두에 대해 이용가능하다.
● SET 시작시
● (사용자 모드)
- 사용자가 SUPL 클라이언트에 대해 (사용자명, 패스워드)를 입력한다
● (GBA 모드)
- SET는 (B-TID, Ks)를 획득하기 위해 BSF를 이용하여 부트스트랩핑한다
- 주의, SET가 요구되는 것만큼 자주 (B-TID, Ks)를 리프레쉬할 수 있다
● SUPL 클라이언트는 프레시한 SUPL INIT 크리덴셜들을 획득하기 위해 SLP와의 ULP 세션을 수행한다
ULP 세션 보안 제안
● 서버 인증서들을 가지는 TLS를 사용할 수 있다
● 서버 인증을 관리한다
● ULP 메시지들에 새로운 파라미터들을 추가한다
● SET로부터의 메시지들에 대한 (사용자_ID, Req_Count, Req_Digest)
● SLP로부터의 메시지들에 대한 (사용자_ID, Resp_Count, Resp_Digest)
● SET 발신 메시지들
● SET가 (사용자_ID, Req_Count, Req_Digest)를 추가한다
● SLP가 메시지 컨텐츠를 프로세싱하기 전에 Req_Count 및 Req_Digest를 검증한다
● SLP 발신 메시지들
● SLP가 (사용자_ID, RespCounter, Resp_Digest)를 추가한다
● SET가 메시지 컨텐츠를 프로세싱하기 전에 Resp_Count 및 Resp_Digest를 검증한다
Req _ Count / Resp _ Count
● Req_Count/Resp_Count는 유사한 행동을 가진다
● 카운터들의 목적은 리플레이 검출을 인에이블시키는 것이다
● Req_Count/Resp_Count는 매 ULP 세션마다 수신기 및 송신기에서 리셋된다
● 즉, 카운터는 세션 식별자가 변경되는 경우 리셋된다
● 송신기에서
● Req_Count/Resp_Count는 모든 메시지마다 증분되고 ULP 메시지에 추가된다
● 수신기에서:
● 수신기는 Req_Count/Resp_Count를 이들이 예상한 값과 비교한다. 이들이 리플레이를 검출하는 경우, 이들은 에러를 가지고 종료한다. 그렇지 않은 경우, 메시지는 리플레이 검출을 통과한다.
Req _ Digest / Resp _ Digest 생성
● Req_Digest/Resp_Digest 생성은 동일할 수 있다
● 모든 공지된 값들을 ULP_Message 필드들에 삽입한다
● ULP_Message_Z를 모두 제로들로 세팅된 Req_Digest/Resp_Digest 필드를 가지는 ULP_Message로서 형성한다
● DigestPayload = SLP_Domain ":" ULP_Message_Z를 형성한다
● Req_Digest/Resp_Digest = HMAC-SHA256-32(사용자_비밀, DigestPayload)를 계산한다
● ULP_Message 내의 적절한 필드에 Req_Digest/Resp_Digest를 추가한다
● (사용자 모드)
● (사용자_ID, 사용자_비밀) := (사용자명. 패스워드)를 사용한다
● (GBA 모드)
●(사용자_ID, 사용자_비밀) :=(B-TID, Ks_NAF)를 사용한다, 여기서
● [SET] Ks 및 SLP URL로부터 Ks_NAF를 생성한다
● [SLP] 일단 이것이 사용자_ID 필드를 추출하면, SLP는 BSF에 B-TID를 제공하고, BSF는 Ks_NAF를 가지고 리턴한다. Ks_NAF는 B-TID가 변경하지 않는 한 변경하지 않을 것이다.
SUPL _ INIT 보안 제안
● ULP TS V2.0 섹션 6.1.6.6에 이미 정의된 모의 기본 SUPL_INIT 보호
● GBA-프로비져닝 키들로부터 SLP 프로비져닝 키들로의 적응된 설명
● SLP가 클라이언트 또는 SLP의 계획에서 ULP 세션 동안 (키 식별자, SUPL_INIT_ROOT_KEY)를 업데이트한다
- BasicReplayCounter는 키 식별자가 리셋되는 경우 리셋된다
● 최소의 표준화 노력이 요구됨
SUPL _ INIT 크리덴셜 관리
● 임의의 접속 세션의 제1 ULP 교환에서 발생한다.
● SET-발신 메시지들
● 세션의 제1 메시지는
- 어떠한 크리덴셜들도 이용가능하지 않은 경우, " SUPL_INIT_Credential_Req" 표시자, 또는
- SLP로 하여금 SET 및 SLP가 비동기인지를 검출하게 하기 위한 Current_Key_Identifier
중 어느 하나를 포함해야 한다.
● SLP-발신 메시지들
● Current_Key_Identifier가 정확한 경우, 확인하기 위해 "SUPL_INIT _Credential_OK" 표시자를 추가한다.
● Current_Key_Identifier가 부정확하거나, 또는 "SUPL_INIT_Credential_Req" 표시자를 송신한 SET 또는 서버가 SUPL_INIT 크리덴셜들을 업데이트하기를 원하는 경우, SLP는 SUPL_INIT 크리덴셜들을 프로비져닝하기 위해 ULP 메시지에 필드를 추가한다.
- (키 식별자, SUPL_INIT_ROOT_KEY)를 포함한다.
예시적인 호출 흐름들 - SI 즉시 픽스
● 단계 A: 타겟 SET은 req_count를 1234(또는 SET에 의해 결정되는 것과 같은 임의의 다른 실행 번호)로 세팅하고, 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL START(사용자-id, req_count=1234, req_digest,...) 메시지를 송신한다.
● 단계 B: H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 SUPL START의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 res_count를 4321(또는 SET에 의해 결정되는 것과 같은 임의 다른 실행 번호)로 세팅하고 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL RESPONSE(사용자-id, res_count=4321, res_digest,...) 메시지를 송신한다. 타겟 SET에서의 SUPL START 및 SUPL RESPONSE 사이의 기간 = UT1이다.
● 단계 C: 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL RESPONSE의 진의성을 체크하고, 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET는 req_count를 1만큼 증분시키고(1234+1), 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL POS INIT(사용자-id, req_count=1234+1, req_digest...) 메시지를 송신한다. H-SLP에서의 SUPL RESPONSE 및 SUPL POS INIT 사이의 기간 = ST1이다.
● 단계 D: 타겟 SET 및 H-SLP는 SUPL POS 교환에 관여한다. 타겟 SET에서의 SUPL POS INIT 및 SUPL POS 사이의 기간 = UT2이다. 각 측은 수신된 메시지 다이제스트에 기초하여 메시지 진의성을, 그리고 메시지 카운터(req_count/res_count)에 기초하여 리플레이 무결성을 체크한다.
● 단계 E : H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 수신된 마지막 SUPL POS 메시지의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 req_count를 증분시키고(4321+1) 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL END(사용자-id res_count=4321+1, res_digest,...) 메시지를 송신한다. 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL END의 진의성을 체크하고, 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET에서의 SUPL POS 및 SUPL END 사이의 기간 = UT3이다.
예시적인 호출 흐름들 - NI 즉시 픽스
● 단계 A: H-SLP는 res_count를 1234(또는 H-SLP에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(BasicMAC)를 계산한다. H-SLP는 타겟 SET에 SUPL INIT(사용자-id, res_count=4321, BasicMAC,...) 메시지를 송신한다.
● 단계 B: 타겟 SET는 수신된 메시지 다이제스트(BasicMAC)를 사용하여 SUPL INIT의 진의성을 체크하고, 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET는 req_count를 1234(또는 SET에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL POS INIT(사용자-id, req_count=1234, req_digest,...) 메시지를 송신한다. H-SLP에서의 SUPL INIT 및 SUPL POS INIT 사이의 기간 = ST1이다.
● 단계 C: 타겟 SET 및 H-SLP 메시지가 SUPL POS 교환에 관여한다. 타겟 SET에서의 SUPL POS INIT 및 SUPL POS 사이의 기간 = UT2이다. 각 측은 수신된 메시지 다이제스트에 기초하여 메시지 진의성을, 그리고 메시지 카운터(req_count/res_count)에 기초하여 리플레이 무결성을 체크한다.
● 단계 D: H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 수신된 마지막 SUPL POS 메시지의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 req_count를 증분시키고(4321+1) 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL END(사용자-id, res_count=4321+1, res_digest,...) 메시지를 송신한다. 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL END의 진의성을 체크하고 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET에서의 SUPL POS 및 SUPL END 사이의 기간 = UT3이다.
추가적인 실시예 2
서문
● SUPL 2.0에서의 보안은 액세스 네트워크 특정적이다:
● ACA는 소스 IP 어드레스에 기초하여 SET를 식별하기 위해 코어 네트워크에 대한 액세스를 요구한다
● GBA는 오직 3GPP/3GPP2 네트워크들에만 적용가능하다
● SEK는 오직 WiMAX 네트워크들에만 적용가능하다
● SUPL 3.0에서의 새로운 요건은 모든 액세스 네트워크들에 대해 적용가능한 인증 메커니즘을 요청한다. 이 실시예는 모든 액세스 네트워크들에 적용가능한 새로운 보안 메커니즘을 설명한다.
● GBA 및 "사용자명/패스워드" 인증 모두를 지원하는 단순한 프레임워크
● 단일 TLS 변형이 사용될 수 있다
● 사양 및 구현예에 대한 최소 변경
개념 개요
● ULP 보안
● 서버 인증서들을 가지는 TLS
● 2개의 클라이언트 인증 모드들
- (사용자 모드):(사용자_ID, 사용자_비밀) = (사용자명, 패스워드)
- (GBA 모드):(사용자_ID, 사용자_비밀) = (B-TID, Ks_NAF)
● (사용자_ID, 카운터, 다이제스트)가 모든 메시지들에 추가되고, 다이제스트는
● A1 = SLP_도메인||ULP_메시지
● 다이제스트 = HMAC(사용자_비밀, A1)
로서 계산된다
● 송신기는 (사용자_ID, 카운터, 다이제스트)를 모든 메시지들에 추가하고, 수신기는 검증한다
● ULP가 SUPL INIT 크리덴셜들(키 신원, SUPL_INIT_ROOT_KEY)을 업데이트하기 위해 사용된다
● SUPL INIT 보호[예를 들어, 비-비상상황에만]
● SLP(사용자 모드) 또는 GBA(GBA 모드)에 의해 생성되는 SUPL INIT 크리덴셜들을 가지는 ULP v2.0 기본 SUPL INIT 보호를 사용한다
● 사용자 모드에서 ULP를 통해 SLP에 의해 제공되는 SUPL INIT 크리덴셜들을 사용한다
셋업 상세항목들
● 오프라인
● (사용자 모드) 사용자 및 SLP가 (사용자명, 패스워드)에 동의한다
- SLP가 사용자에게 (사용자명, 패스워드)를 제공할 수 있다
- 사용자가 SLP에 (사용자명, 패스워드)를 제공할 수 있다
- 이것은 H-SLP 또는 A-SLP 모두에 대해 이용가능하다.
● SET 시작시
● (사용자 모드)
- 사용자가 SUPL 클라이언트에 대해 (사용자명, 패스워드)를 입력한다
● (GBA 모드)
- SET는 (B-TID, Ks)를 획득하기 위해 BSF를 이용하여 부트스트랩한다
- 주의, SET가 요구되는 것만큼 자주 (B-TID, Ks)를 리프레쉬할 수 있다
● SUPL 클라이언트는 프레시한 SUPL INIT 크리덴셜들을 획득하기 위해 SLP와의 ULP 세션을 수행한다
ULP 세션 보안 제안
● 서버 인증서들을 가지는 TLS를 사용할 수 있다
● 서버 인증을 관리한다
● ULP 메시지들에 새로운 파라미터들을 추가한다
● SET로부터의 메시지들에 대한 (사용자_ID, Req_Count, Req_Digest)
● SLP로부터의 메시지들에 대한 (사용자_ID, Resp_Count, Resp_Digest)
● SET 발신 메시지들
● SET가 (사용자_ID, Req_Count, Req_Digest)를 추가한다
● SLP가 메시지 컨텐츠를 프로세싱하기 전에 Req_Count 및 Req_Digest를 검증한다
● SLP 발신 메시지들
● SLP가 (사용자_ID, RespCounter, Resp_Digest)를 추가한다
● SET가 메시지 컨텐츠를 프로세싱하기 전에 Resp_Count 및 Resp_Digest를 검증한다
Req _ Count / Resp _ Count
● Req_Count/Resp_Count는 유사한 행동을 가진다
● 카운터들의 목적은 리플레이 검출을 인에이블시키는 것이다
● Req_Count/Resp_Count는 매 ULP 세션마다 수신기 및 송신기에서 리셋된다
● 즉, 카운터는 세션 식별자가 변경되는 경우 리셋된다
● 송신기에서
● Req_Count/Resp_Count는 모든 메시지마다 증분되고 ULP 메시지에 추가된다
● 수신기에서:
● 수신기는 Req_Count/Resp_Count를 이들이 예상한 값과 비교한다. 이들이 리플레이를 검출하는 경우, 이들은 에러를 가지고 종료한다. 그렇지 않은 경우, 메시지는 리플레이 검출을 통과한다.
Req _ Digest / Resp _ Digest 생성
● Req_Digest/Resp_Diges 생성은 동일할 수 있다
● 모든 공지된 값들을 ULP_Message 필드들에 삽입한다
● ULP_Message_Z를 모두 제로들로 세팅된 Req_Digest/Resp_Digest 필드를 가지는 ULP_Message로서 형성한다
● DigestPayload = SLP_Domain ":" ULP_Message_Z를 형성한다
● Req_Digest/Resp_Digest = HMAC-SHA256-32(사용자_비밀, DigestPayload)를 계산한다
● ULP 메시지 내의 적절한 필드에 Req_Digest/Resp_Digest를 추가한다
● (사용자 모드)
● (사용자_ID, 사용자_비밀) := (사용자명. 패스워드)를 사용한다
● (GBA 모드)
●(사용자_ID, 사용자_비밀) :=(B-TID, Ks_NAF)를 사용한다, 여기서
● [SET] Ks 및 SLP URL로부터 Ks_NAF를 생성한다
● [SLP] 일단 이것이 사용자_ID 필드를 추출하면, SLP는 BSF에 B-TID를 제공하고, BSF는 Ks_NAF를 가지고 리턴한다. Ks_NAF는 B-TID가 변경하지 않는 한 변경하지 않을 것이다.
SUPL _ INIT 보안 제안
● ULP TS V2.0 섹션 6.1.6.6에 이미 정의된 기본 SUPL_INIT 보호를 사용한다:
● 사용자 모드에서 GBA-프로비져닝 키들로부터 SLP 프로비져닝 키들로의 적응된 설명
● SLP가 사용자 모드에서 클라이언트 또는 SLP의 계획에서 ULP 세션 동안 (키 식별자, 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는 키 식별자가 리셋되는 경우 리셋된다
● 키 식별자 및 SUPL_INIT_ROOT_KEY는 사용자_ID 및 사용자_비밀과 동일하지 않은데, 즉, SUPL 보호는 ULP 메시지 인증과는 독립적으로 작용한다.
SUPL _ INIT 크리덴셜 관리
● 임의의 접속 세션의 제1 ULP 교환에서 발생한다.
● SET-발신 메시지들
● 세션의 제1 메시지는
- 어떠한 크리덴셜들도 이용가능하지 않는 경우 "SUPL_INIT_Credential_Req" 표시자, 또는
- SLP로 하여금 SET 및 SLP가 비동기인지의 여부를 검출하게 하기 위한 Current_Key_Identifier
중 어느 하나를 포함해야 한다.
● SLP-발신 메시지들
● Current_Key_Identifier가 정확한 경우, 확인하기 위해 "SUPL_INIT_Credential_OK" 표시자를 추가한다.
● Current_Key_Identifier가 부정확하거나, 또는"SUPL_INIT_Credential_Req" 표시자를 송신한 SET 또는 서버가 SUPL_INIT 크리덴셜들을 업데이트하기를 원하는 경우, SLP는 SUPL_INIT 크리덴셜들을 프로비져닝하기 위한 필드를 ULP 메시지에 추가한다.
- (키 식별자, SUPL_INIT_ROOT_KEY)를 포함한다.
예시적인 호출 흐름들 - SI 즉시 픽스
● 단계 A: 타겟 SET는 req_count를 1234(또는 SET에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL START(사용자-id, req_count=1234, req_digest,...) 메시지를 송신한다.
● 단계 B: H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 SUPL START의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 res_count를 4321(또는 SET에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL RESPONSE(사용자-id, res_count=4321, res_digest,...) 메시지를 송신한다. 타겟_SET에서의 SUPL START 및 SUPL RESPONSE 사이의 기간 = UT1이다.
● 단계 C: 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL RESPONSE의 진의성을 체크하고 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET는 req_count를 1만큼 증분시키고(1234+1) 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL POS INIT(사용자-id, req_count=1234+1, req_digest...) 메시지를 송신한다. H-SLP에서의 SUPL RESPONSE 및 SUPL POS INIT 사이의 기간 = ST1이다.
● 단계 D: 타겟 SET 및 H-SLP는 SUPL POS 교환에 관여한다. 타겟 SET에서의 SUPL POS INIT 및 SUPL POS 사이의 기간 = UT2이다. 각 측은 수신된 메시지 다이제스트에 기초하여 메시지 진의성을, 그리고 메시지 카운터(req_count/res_count)에 기초하여 리플레이 무결성을 체크한다.
● 단계 E: H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 수신된 마지막 SUPL POS 메시지의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 req_count를 증분시키고(4321+1) 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL END (사용자-id, res_count=4321+1, res_digest,...) 메시지를 송신한다. 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL END의 진의성을 체크하고, 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET에서의 SUPL POS 및 SUPL END 사이의 기간 = UT3이다.
예시적인 호출 흐름들 - NI 즉시 픽스
● 단계 A: H-SLP는 res_count를 1234(또는 H-SLP에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(BasicMAC)를 계산한다. H-SLP는 타겟 SET에 SUPL INIT(사용자-id, res_count=4321, BasicMAC,...) 메시지를 송신한다.
● 단계 B: 타겟 SET는 수신된 메시지 다이제스트(BasicMAC)를 사용하여 SUPL INIT의 진의성을 체크하고, 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET는 req_count를 1234(또는 SET에 의해 결정된 바와 같은 임의의 다른 실행중인 번호)로 세팅하고, 메시지 다이제스트(req_digest)를 계산한다. 타겟 SET는 H-SLP에 SUPL POS INIT(사용자-id, req_count=1234, req_digest,...) 메시지를 송신한다. H-SLP에서의 SUPL INIT 및 SUPL POS INIT 사이의 기간 = ST1이다.
● 단계 C: 타겟 SET 및 H-SLP가 SUPL POS 교환에 관여한다. 타겟 SET에서의 SUPL POS INIT 및 SUPL POS 사이의 기간 = UT2이다. 각 측은 수신된 메시지 다이제스트에 기초하여 메시지 진의성을, 그리고 메시지 카운터(req_count/res_count)에 기초하여 리플레이 무결성을 체크한다.
● 단계 D: H-SLP는 수신된 메시지 다이제스트(req_digest)를 사용하여 수신된 마지막 SUPL POS 메시지의 진의성을 체크하고, 또한 리플레이 카운터(req_count)를 체크한다. H-SLP는 req_count를 증분시키고(4321+1) 메시지 다이제스트(res_digest)를 계산한다. H-SLP는 타겟 SET에 SUPL END(사용자-id, res_count=4321+1, res_digest,...) 메시지를 송신한다. 타겟 SET는 수신된 메시지 다이제스트(res_digest)를 사용하여 SUPL END의 진의성을 체크하고 또한 리플레이 카운터(res_count)를 체크한다. 타겟 SET에서의 SUPL POS 및 SUPL END 사이의 기간 = UT3이다.
추가적인 실시예 3
서문
● SUPL 2.0에서의 보안은 액세스 네트워크 특정적이다:
● ACA는 소스 IP 어드레스에 기초하여 SET를 식별하기 위해 코어 네트워크에 대한 액세스를 요구한다
● GBA는 오직 3GPP/3GPP2 네트워크들에만 적용가능하다
● SEK는 오직 WiMAX 네트워크들에만 적용가능하다
● SUPL 3.0에서의 새로운 요건은 모든 액세스 네트워크들에 대해 적용가능한 인증 메커니즘을 요청한다. 이 실시예는 모든 액세스 네트워크들에 적용가능한 새로운 보안 메커니즘을 설명한다.
● GBA 및 "사용자명/패스워드" 인증 모두를 지원하는 단순한 프레임워크
SUPL 3.0 보안 개념 개요 I
보안 방법 설명 코멘트
A:ACA SUPL 1.0 및 2.0에서 지원되는 바와 같은 대안적인 클라이언트 인증. 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. 코어 네트워크를 수반하는 IP 어드레스/MSISDN 일치성 체크를 사용하는 클라이언트 인증. 매체 보안 요건을 가지며 IP 어드레스 클라이언트 검증에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
B: GBA SUPL 2.0에서 지원되는 바와 같은 GBA 기반 보안. 오직 3GPP/3GPP2 네트워크들에 대해 적용가능함. PSK-TLS를 사용하는 서버 및 클라이언트 인증 및 암호화. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
C: 사용자 모드 ULP 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. 클라이언트로부터 서버로의 각각의 ULP 메시지에 첨부된 MAC 및 (사용자명, 패스워드)를 사용하는 클라이언트 인증. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지지 않는 SUPL 배치에 대해. 이는 새로운 보안 방법이다.
D: 사용자 모드 TLS 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. (사용자명, 패스워드) SRP TLS를 사용하는 클라이언트 인증. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지지 않는 SUPL 배치에 대해. 이는 새로운 보안 방법이다.
SUPL 3.0 보안 개념 개요 II
후속하는 2가지 옵션들이 SUPL 3.0 보안에 대해 고려된다:
옵션 I 옵션 II
ACA(A) ACA(A)
GBA(B) GBA(B)
사용자 모드 ULP(C) 사용자 모드 TLS(D)
옵션 I: 개념 개요
● ULP 보안
● GBA 모드: 이전과 같이 TLS-PSK를 사용한다
● 사용자 모드 ULP: (사용자명, 패스워드)에 기초하여
- 먼저, 보안 접속을 설정하기 위해 서버 인증서들을 이용하여 TLS 핸드쉐이크를 수행한다
● (사용자명, 카운터, 다이제스트)가 SET에 의해 송신된 모든 ULP 메시지들에 추가되고, 다이제스트는
- A1 = SLP_도메인||ULP_메시지,
- 다이제스트 = HMAC(패스워드, A1)
으로서 계산된다
● SET는 모든 메시지들에 (사용자명, 카운터, 다이제스트)를 추가하고, SLP는 검증한다
● ULP가 SUPL INIT 보호를 위해 요구되는 SUPL INIT 크리덴셜들(키 신원, SUPL_INIT_ROOT_KEY)을 업데이트하기 위해 사용된다
옵션 I: 오프라인 프로시저들
● 사용자 모드 ULP(오프라인)
● 사용자 및 SLP 운용자가 (사용자명, 패스워드)에 동의한다
● 다른 가정들
● SET가 SLP의 URL을 가진다
● SET가 SLP를 인증하기 위한 적절한 루트 인증서들을 가진다
옵션 I: 온라인 프로시저들
● 서버 인증서들을 가지는 TLS가 서버 인증 및 암호화를 위해 사용된다
● 새로운 파라미터들이 SET로부터 ULP 메시지들에 추가된다: (사용자명, 카운터, 다이제스트)
● SLP는 ULP 메시지 컨텐츠를 프로세싱하기 전에 카운터 및 다이제스트를 검증한다
● 카운터의 목적은 리플레이 검출을 인에이블시키는 것이다
● 카운터는 모든 ULP 세션마다 수신기 및 송신기에서 리셋된다
● 송신기에서, 카운터는 모든 메시지마다 증분되고 ULP 메시지에 추가된다
● 수신기에서, 카운터는 예상되는 값과 비교된다. 리플레이가 검출되는 경우, 에러를 가지고 종료한다. 그렇지 않은 경우, 메시지는 리플레이 보호를 통과한다.
옵션 II : 개념 개요
● ULP 보안
● GBA 모드: 이전과 같이 TLS-PSK를 사용한다
● 사용자 모드 TLS: (사용자명, 패스워드)에 기초하여
- 먼저, 보안 접속을 설정하기 위해 서버 인증서들을 이용하여 TLS 핸드쉐이크를 수행한다
- SLP는 TLS 재협상을 개시하기 위해 "Hello Request"를 송신한다. 이후, SET & SLP는 (사용자명, 패스워드)를 사용하여 사용자를 인증하기 위해 TLS-SRP 핸드쉐이크(SRP = 보안 원격 패스워드)를 수행한다.
- 제1 보안 접속은 TLS-SRP 핸드쉐이크에서 사용자명을 숨기도록 요구된다.
● ULP는 SUPL INIT 보호를 위해 요구되는 기본 보호 SUPL INIT 크리덴셜들(키 신원, SUPL_INIT_ROOT_KEY)를 업데이트하기 위해 사용된다
옵션 II : 오프라인 프로시저들
● 사용자 모드 TLS(오프라인)
● 사용자 및 SLP 운용자가 (사용자명, 패스워드)에 동의한다
● 다른 가정들
● SET가 SLP의 URL을 가진다
● SET가 SLP를 인증하기 위한 적절한 루트 인증서들을 가진다
옵션 II : 온라인 프로시저들
● SET는, 적절한 암호 스위트들을 선택함으로써 GBA 및/또는 사용자 모드에 대한 TLS 지원에서 표시하는, TLS 핸드쉐이크를 개시한다.
● SLP는 GBA 모드 또는 사용자 모드를 이용하여 진행할지 여부를 결정한다.
● GBA 모드인 경우,
● 보안 터널을 설정하기 위해 GBA를 사용하여 TLS-PSK에 대한 것으로 TLS 핸드쉐이크를 계속한다
● 상호 인증
● 보안 터널에서 데이터를 교환한다
● 사용자 모드인 경우,
● 먼저, 보안 채널을 설정하기 위해 서버 인증서들을 이용하는 TLS 핸드쉐이크를 계속한다
● SET는 SLP를 인증한다
● TLS-SRP 핸드쉐이크를 수행한다(보안 채널 내에서 메시지들이 교환된다)
● SLP가 사용자를 인증한다
● 새로운 세션 키들을 초래한다
● 새로운 세션 키들에 의해 보호되는 보안 채널에서 데이터를 교환한다
옵션 II : 온라인 프로시저 - 제1 TLS 핸드쉐이크
● SET→SLP: 클라이언트 헬로우:
● 모든 지원되는 암호 스위트들을 표시한다
- SET가 GBA를 지원하는 경우, TLS-PSK 암호 스위트(들)에 대한 지원을 표시한다
- SET가 사용자 모드를 지원하는 경우, TLS SRP 및 서버 인증서들을 가지는 TLS에 대한 지원을 표시한다
● SET 는 이 시점에 사용자명을 제공하지 않으며, 요구되는 경우, 다음 TLS 핸드쉐이크에서 제공될 것이다
● SLP→SET: 서버 헬로우:
● 선택된 암호 스위트를 표시한다
- SLP가 GBA 모드를 선택하는 경우, SLP는 TLS-PSK 암호 스위트를 표시한다
- SLP가 사용자 모드를 선택하는 경우, SLP는 서버 인증서들을 가지는 TLS에 대한 암호 스위트를 표시한다
- 선택된 암호 스위트에 대해서와 같이 호출 흐름이 진행한다
옵션 II : 온라인 프로시저 - 제1 TLS 핸드쉐이크 이후
● GBA 모드
● SET 및 SLP가 보안 채널을 통한 통신을 시작한다
● 사용자 모드
● SLP → SET: 헬로우 요청
● 재협상을 개시한다
● SET → SLP: 클라이언트 헬로우
● TLS-SRP에 대한 지원을 표시한다
● TLS-SRP 사양들에 따른 사용자명을 포함한다
● SET → SLP: 서버 헬로우
● TLS-SRP의 선택을 표시한다
● TLS-SRP에 따라 교환을 계속한다
● 성공적인 핸드쉐이크에 후속하여, SET & SLP는 보안 채널을 통한 데이터 교환을 시작한다.
SUPL INIT 보호
● SUPL 3.0에서의 SUPL INIT 보호는 SUPL 2.0에서의 SUPL INIT 보호 메커니즘에 기초하며, SUPL INIT에 첨부된 메시지 인증 코드(MAC)를 사용한다
● MAC는 사용자 모드에서 ULP를 통해 프로비져닝되는 (키 신원, SUPL_INIT_ROOT_KEY)를 사용하여 계산된다(GBA 모드는 프로비져닝을 요구하지 않는다)
● (키 신원, SUPL_INIT_ROOT_KEY)를 계산하기 위한 2가지 방법들:
● GBA 모드: (키 신원, SUPL_INIT_ROOT_KEY) = (B-TID, Ks)
- (B-TID, Ks)는 BSF에 대해 오프로 부트스트랩된다
● 사용자 모드: (키 신원, SUPL_INIT_ROOT_KEY)는 (사용자명, 패스워드)로부터 생성된다
● SUPL INIT 보호는 옵션 I 및 옵션 II에 대해 동일하다
SUPL INIT 보호 메커니즘
● SUPL v3.0에서의 보호의 2가지 레벨들:
● 널
- 보안 없음
● 기본 보호
- 공유된 키 신원에 기초하여, ULP를 통해 SUPL_INIT_ROOT_KEY가 프로비져닝됨
- SUPL v2.0으로부터의 모의 기본 보호
- 키 식별자 및 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 세션의 제1 ULP 교환에서 발생한다
● 제1 SET 발신 메시지
● 세션의 제1 메시지는
- 어떠한 크리덴셜들도 이용가능하지 않은 경우 "SUPL_INIT_Credential_Req" 표시자, 또는
- SLP로 하여금 SET 및 SLP가 비동기인지 여부를 검출하게 하기 위한 Current_Key_Identifier
중 어느 하나를 포함해야 한다
● SLP 응답
● Current_Key_Identifier가 정확한 경우, 확인을 위해 "SUPL_INIT_Credential_OK" 표시자를 추가한다.
● Current_Key_Identifier가 부정확한 경우, 또는 "SUPL_INIT_Credential_Req" 표시자를 송신한 SET 또는 SLP가 SUPL_INIT 크리덴셜들을 업데이트하기를 원하는 경우, SLP는 SUPL_INIT 크리덴셜들을 프로비져닝하기 위한 필드를 ULP 메시지에 추가한다
- (키 식별자, SUPL_INIT_ROOT_KEY)를 포함한다
사용자 모드들의 비교
플러스 델타
옵션 I: 사용자 모드 ULP ·기존의 TLS 구현에 대한 어떠한 변경도 요구하지 않는다 ·2개 계층: TLS 및 ULP 상에서 분산된 보안
· ULP 계층에 대해 투명하지 않은 보안
· ULP 구현이 비-보안 전문가들에 의해 수행될 수 있으므로 더 높은 구현 위험성
옵션II: 사용자 모드 TLS ·전송층(단일 계층 보안)에 의해 제공되며 따라서 ULP 계층에 대해 투명한 보안 ·더 복잡한 TLS 구현
요약
● 2개의 새로운 보안 모델들이 SUPL 3.0에서 고려된다
● 옵션 I: 사용자 모드 ULP
● 옵션 II: 사용자 모드 TLS
● 2개의 새로운 보안 모델들이 (사용자, 패스워드) 클라이언트 인증을 사용하는 반면, 서버 인증 및 암호화는 레거시 서버 인증된 TLS에 기초한다.
● 두 옵션들 모두 베어러 무관(bearer agnostic) 보안 모델들이며, 따라서, SUPL 3.0에 대해 적합하다.
● 레거시 보안 모델들(ACA 및 GBA)은 적용가능하고 바람직한 경우, 여전히 사용될 수 있다.
SRP 기본
● TLS-SRP [IETF RFC 5054]는 보안 원격 패스워드(SRP [RFC2945])를 인증 및 키 교환의 기반으로서 사용한다
● 메인 단계들
● 인증을 수행하는 서버는 패스워드를 필요로 하지 않으며, 대신, 그것은 {사용자명, 패스워드검증자, 솔트}를 포함하는 트리플렛을 저장한다
● 통상적으로, 사용자의 클라이언트는 서버에 오프라인으로 등록하는 경우 트리플렛을 생성한다
● 솔트는 사용자에 의해 랜덤으로 선택될 수 있다
● 패스워드검증자는 디피-헬만 키 교환과 유사한 까다로운 수학을 사용하여 사용자명, 솔트 및 사용자의 패스워드로부터 계산된다.
● 서버는 다음을 수행하기 위해 사용자와의 상호작용 시에 트리플렛을 사용한다
● 사용자가 패스워드를 알고 있음을 검증한다 그리고
● 사용자 및 서버에 의해서만 공지된 공유 비밀을 설정한다. 이러한 공유된 비밀은 (그것이 TLS-SRP에서 사용되는 방법인) 암호화 및 무결성 보호를 위한 키를 생성하기 위해 사용될 수 있다
SRP 의 일부 특징들
● 트리플렛은 사용자를 가장하기 위해 사용될 수 없다
● 서버는 트리플렛을 비밀로 유지할 필요가 없다
● 서버가 제3 파티가 이후 사용자를 가장하려고 시도할 것임을 고려하지 않고, 서버는 해당 파티로 하여금 사용자를 검증하도록 허용하기 위해 제3 파티에 트리플렛을 제공할 수 있다.
- 예를 들어, H-SLP는 A-SLP로 하여금 사용자를 인증하도록 허용하기 위해 A-SLP에 트리플렛을 제공할 수 있다.
추가적인 실시예 4
서문
● SUPL 2.0에서의 보안은 액세스 네트워크 특정적이다:
● ACA는 소스 IP 어드레스에 기초하여 SET를 식별하기 위해 코어 네트워크에 대한 액세스를 요구한다
● GBA는 오직 3GPP/3GPP2 네트워크들에만 적용가능하다
● SEK는 오직 WiMAX 네트워크들에만 적용가능하다
● SUPL 3.0에서의 새로운 요건은 모든 액세스 네트워크들에 대해 적용가능한 인증 메커니즘을 요청한다. 이 실시예는 모든 액세스 네트워크들에 적용가능한 새로운 보안 메커니즘을 설명한다:
● GBA 및 "사용자명/패스워드" 인증 모두를 지원하는 단순한 프레임워크
SUPL 3.0 보안 개념 개요 I
보안 방법 설명 코멘트
A:ACA SUPL 1.0 및 2.0에서 지원되는 바와 같은 대안적인 클라이언트 인증. 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. 코어 네트워크를 수반하는 IP 어드레스/MSISDN 일치성 체크를 사용하는 클라이언트 인증. 매체 보안 요건을 가지며 IP 어드레스 클라이언트 검증에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
B: GBA SUPL 2.0에서 지원되는 바와 같은 GBA 기반 보안. 오직 3GPP/3GPP2 네트워크들에 대해 적용가능함. PSK-TLS를 사용하는 서버 및 클라이언트 인증 및 암호화. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
C: 사용자 모드 ULP 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. 클라이언트로부터 서버로의 각각의 ULP 메시지에 첨부된 MAC 및 (사용자명, 패스워드)를 사용하는 클라이언트 인증. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지지 않는 SUPL 배치에 대해. 이는 새로운 보안 방법이다.
D: 사용자 모드 TLS 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. (사용자명, 패스워드) SRP TLS를 사용하는 클라이언트 인증. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지지 않는 SUPL 배치에 대해. 이는 새로운 보안 방법이다.
SUPL 3.0 보안 개념 개요 II
후속하는 2가지 옵션들이 SUPL 3.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 핸드쉐이크를 수행한다
● (사용자명, 카운터, 다이제스트)가 SET에 의해 송신된 모든 ULP 메시지들에 추가되며, 다이제스트는 다음과 같이 계산된다
- ULP_Message_Z는 제로들로 설정된 다이제스트 필드를 가지는 ULP_메시지이다
- User_ULP_IK= SHA-256(사용자명||":"||패스워드||":"||SLP_도메인||":SUPL30ULP ")
- 다이제스트 = HMAC-SHA-256-32(User_ULP_IK, ULP_Message_Z)
● SET는 모든 메시지들에 (사용자명, 카운터, 다이제스트)를 추가하고, SLP는 검증한다
사용자 모드 ULP : 개념 개요 II
● 서버 인증서들을 가지는 TLS가 서버 인증 및 암호화를 위해 사용된다
● 새로운 파라미터들이 SET로부터의 ULP 메시지에 추가된다:(사용자명, 카운터, 다이제스트)
● SLP는 ULP 메시지 컨텐츠를 프로세싱하기 전에 카운터 및 다이제스트를 검증한다
● 카운터의 목적은 리플레이 검출을 인에이블시키는 것이다
● 카운터는 모든 ULP 세션 동안 수신기 및 송신기에서 리셋된다
● 송신기에서, 카운터는 모든 메시지마다 증분되고, ULP 메시지에 추가된다
● 수신기에서, 카운터는 예상되는 값에 대해 비교된다. 리플레이가 검출되는 경우, 에러를 가지고 종료한다. 그렇지 않은 경우, 메시지는 리플레이 보호를 통과한다.
사용자 모드 TLS : 개념 개요
● 사용자 모드 TLS: (사용자명, 패스워드)에 기초하여,
● 먼저, 보안 접속을 설정하기 위해 서버 인증서들을 이용하여 TLS 핸드쉐이크를 수행한다
● SLP는 TLS 재협상을 개시하기 위해 "헬로우 요청"을 송신한다. 이후, SET & SLP는 (사용자명, 패스워드)를 사용하여 사용자를 인증하기 위해 RLS-SRP 핸드쉐이크(SRP = 보안 원격 패스워드)를 수행한다.
● 제1 보안 접속은 TLS-SRP 핸드쉐이크에서 사용자명을 숨기도록 요구된다
옵션 I: 온라인 프로시저 개요
● SET는 적절한 암호 스위트들을 선택함으로써 GBA 및/또는 사용자 모드에 대한 TLS 지원을 표시하는, TLS 핸드쉐이크를 개시한다.
● SLP는 GBA 모드 또는 사용자 모드를 이용하여 진행할지의 여부를 결정한다
● GBA 모드인 경우,
● 보안 터널을 설정하기 위해 GBA를 사용하여 TLS-PSK에 대한 것과 같이 TLS 핸드쉐이크를 계속한다
- 상호 인증을 제공한다
● 보안 채널에서 데이터를 교환한다
● 사용자 모드인 경우,
● 보안 채널을 설정하기 위해 서버 인증서들을 이용하여 TLS 핸드쉐이크를 계속한다
- SET는 SLP를 인증한다
● 보안 채널에서 데이터를 교환한다
- SLP로 하여금 사용자를 인증하게 하는 SET(사용자명, 카운터, 다이제스트)로부터 ULP 메시지들에 새로운 파라미터들을 추가한다
옵션 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 메시지들에 추가된다:(사용자명, 카운터, 다이제스트)
- SLP는 ULP 메시지 컨텐츠를 프로세싱하기 전에 카운터 및 다이제스트를 검증한다
- 카운터의 목적은 리플레이 검출을 인에이블시키는 것이다
- 카운터는 모든 ULP 세션 동안 수신기 및 송신기에서 리셋된다
- 송신기에서, 카운터가 모든 메시지마다 증분되고 ULP 메시지에 추가된다
- 수신기에서, 카운터는 예상되는 값에 대해 비교된다. 리플레이가 검출되는 경우, 에러를 가지고 종료한다. 그렇지 않은 경우, 메시지는 리플레이 검출을 통과한다.
옵션 II : 온라인 프로시저 개요
● SET는, 적절한 암호 스위트들을 선택함으로써 GBA 및/또는 사용자 모드에 대한 TLS 지원에서 표시하는, TLS 핸드쉐이크를 개시한다.
● SLP는 GBA 모드 또는 사용자 모드를 이용하여 진행할지의 여부를 결정한다
● GBA 모드인 경우,
1. 보안 터널을 설정하기 위해 GBA를 사용하여 TLS-PSK에 대해서와 같이 TLS 핸드쉐이크를 계속한다
- 상호 인증
2. 보안 채널에서 데이터를 교환한다
● 사용자 모드인 경우,
1. 먼저, 보안 채널을 설정하기 위해 서버 인증서들을 이용하여 TLS 핸드쉐이크를 계속한다
- SET는 SLP를 인증한다
2. TLS-SRP 핸드쉐이크를 수행한다(보안 채널 내에서 메시지들이 교환된다)
- SLP는 사용자를 인증한다
- 새로운 세션 키들을 초래한다
3. 새로운 세션 키들에 의해 보호되는 보안 터널 내에서 데이터를 교환한다
옵션 II : 온라인 프로시저 상세항목들 - 제1 TLS 핸드쉐이크
● SET → SLP : 클라이언트 헬로우:
● 모든 지원되는 암호 스위트들을 표시한다
- SET가 GBA를 지원하는 경우, TLS-PSK 암호 스위트(들)에 대한 지원을 표시한다
- SET가 사용자 모드를 지원하는 경우, TLS SRP 및 서버 인증서들을 가지는 TLS에 대한 지원을 표시한다
● SET 는 이 시점에 사용자명을 제공하지 않으며, 요구되는 경우, 다음 TLS 핸드쉐이크에서 제공될 것이다
● SLP→SET: 서버 헬로우:
● 선택된 암호 스위트를 표시한다
- SLP가 GBA 모드를 선택하는 경우, SLP는 TLS-PSK 암호 스위트를 표시한다
- SLP가 사용자 모드를 선택하는 경우, SLP는 서버 인증서들을 가지는 TLS에 대한 암호 스위트를 표시한다
- 선택된 암호 스위트에 대해서와 같이 호출 흐름이 진행한다
옵션 II : 온라인 프로시저 - 제1 TLS 핸드쉐이크 이후
● GBA 모드
● SET 및 SLP가 보안 채널을 통한 통신을 시작한다
● 사용자 모드
● SLP → SET: 헬로우 요청
- 재협상을 개시한다
● SET → SLP: 클라이언트 헬로우
- TLS-SRP에 대한 지원을 표시한다
- TLS-SRP 사양들에 따른 사용자명을 포함한다
● SET → SLP: 서버 헬로우
- TLS-SRP의 선택을 표시한다
● TLS-SRP에 따라 교환을 계속한다
● 성공적인 핸드쉐이크에 후속하여, SET & SLP는 보안 채널을 통한 데이터 교환을 시작한다.
SUPL INIT 보호
● SUPL 3.0에서의 SUPL INIT 보호는 SUPL 2.0에서의 SUPL INIT 보호 메커니즘에 기초하며, SUPL INIT에 첨부되는 메시지 인증 코드(MAC)를 사용한다
● 인증에 대한 2가지 방법들
○ GBA 모드: (키 신원, SUPL_INIT_ROOT_KEY) = (B-TID, Ks)
■ (B-TID, Ks)는 BSF에 대해 오프로 부트스트랩된다
○ 사용자 모드: 인증은 (사용자명, 패스워드)를 사용한다
● SUPL INIT 보호는 옵션 I 및 옵션 II에 대해서와 동일하다
SUPL INIT 보호 메커니즘
● SUPL v3.0에서 공급되는 보호의 3가지 타입들:
● 널
- 보안 없음
● 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(사용자명||":"||패스워드":"|| SLP_도메인 || ":SUPL30INIT")
● SUPL_INIT_Z는 모두 제로들로 세팅된 SUPL_INIT_USER_MAC 필드를 가지는 SUPL INIT 메시지이다.
사용자 모드들의 비교
플러스 델타
옵션 I: 사용자 모드 ULP ·기존의 TLS 구현에 대한 어떠한 변경도 요구하지 않는다 ·2개 계층: TLS 및 ULP 상에서 분산된 보안
· ULP 계층에 대해 투명하지 않은 보안
· ULP 구현이 비-보안 전문가들에 의해 수행될 수 있으므로 잠재적으로 더 높은 구현 위험성
옵션II: 사용자 모드 TLS ·전송층(단일 계층 보안)에 의해 제공되며 따라서 ULP 계층에 대해 투명한 보안 ·더 복잡한 TLS 구현
요약
● 2개의 새로운 보안 모델들이 SUPL 3.0에서 고려된다
● 옵션 I: 사용자 모드 ULP
● 옵션 II: 사용자 모드 TLS
● 2개의 새로운 보안 모델들이 (사용자, 패스워드) 클라이언트 인증을 사용하는 반면, 서버 인증 및 암호화는 레거시 서버 인증된 TLS에 기초한다.
● 두 옵션들 모두 베어러 무관(bearer agnostic) 보안 모델들이며, 따라서, SUPL 3.0에 대해 적합하다.
● 레거시 보안 모델들(ACA 및 GBA)은 적용가능하고 바람직한 경우, 여전히 사용될 수 있다.
추가적인 실시예 5
서문
● OMA SUPL 2.0에서의 보안은 액세스 네트워크 특정적이다:
● ACA(대안적 클라이언트 인증)는 소스 IP 어드레스에 기초하여 SET를 식별하기 위해 코어 네트워크에 대한 액세스를 요구한다
● GBA(포괄적 부트스트랩핑 아키텍처)는 오직 3GPP/3GPP2 네트워크들에만 적용가능하다
● SEK(SUPL 암호화 키)는 오직 WiMAX 네트워크들에만 적용가능하다
● OMA SUPL 3.0에서의 새로운 요건은 모든 액세스 네트워크들에 대해 적용가능한 인증 메커니즘을 요청한다. 이 실시예는 모든 액세스 네트워크들에 대해 적용가능한 새로운 보안 메커니즘을 설명한다:
● "사용자명/패스워드" 인증에 기초하는 단순한 프레임워크
● 레거시 ACA 및 GBA 기반 보안이 또한 지원된다
SUPL 3.0 보안 개념 개요 I
SUPL 3.0에 대한 보안은 3가지 보안 방법들에 기초한다:
보안 방법 설명 코멘트
ACA SUPL 1.0 및 2.0에서 지원되는 바와 같은 대안적인 클라이언트 인증. 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. 코어 네트워크를 수반하는 IP 어드레스/MSISDN 일치성 체크를 사용하는 클라이언트 인증. 매체 보안 요건을 가지며 IP 어드레스 클라이언트 검증에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
GBA SUPL 2.0에서 지원되는 바와 같은 GBA 기반 보안. 오직 3GPP/3GPP2 네트워크들에 대해 적용가능함. PSK-TLS를 사용하는 서버 및 클라이언트 인증 및 암호화. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
사용자 모드 TLS 서버 인증된 TLS를 사용하는 서버 인증 및 암호화. (사용자명, 패스워드) SRP TLS를 사용하는 클라이언트 인증. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지지 않는 SUPL 배치에 대해. 이는 새로운 보안 방법이다.
SUPL 3.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
● 서버는 보안 암호화된 IP 접속을 생성하는 ACA에서와 같이 공개 키 TLS를 사용하여 먼저 인증된다
● 클라이언트는 SET 및 SLP 모두에서 사전-프로비져닝된 사용자명/패스워드를 사용하여 TLS-SRP(보안 원격 패스워드)에 기초하여 다음으로 인증된다
사용자 모드 TLS 개요 II
● 단순한 사용자명/패스워드 메커니즘은 문제점들 및/또는 위협들을 제기할 수 있다:
● 사용자명/패스워드는 도난될 수 있고 상이한 디바이스들 상에서 사용될 수 있다
● 사용자명/패스워드는 자발적으로 주어지고 상이한 디바이스들 상에서 동시에 사용될 수 있다
● 이것은 다음에 의해 해결될 수 있다:
● SUPL 서비스 활성화 직후 오직 제1 SUPL 세션 동안에만 사용자명/패스워드의 사용.
● 제1 SUPL 세션 동안, SLP는 새로운 사용자명/패스워드를 생성하고 (초기 사용자명/패스워드에 의해 생성되는 보안 IP 접속을 사용하여) SET에 송신한다.
● SET는 이후 초기 사용자명/패스워드를 새로운 사용자명/패스워드로 대체하고 오래된 사용자명/패스워드를 삭제한다.
● 디바이스는 이후 SLP에 의해 생성된 사용자-비가시적 사용자명/패스워드에 의해 SUPL 가입에 바인딩된다.
● 모든 향후 TLS 세션들은 이후 SLP에 의해 생성되는 새로운 사용자명/패스워드를 사용한다.
● 다른 디바이스들은 이후 사용자명/패스워드를 사용할 수 없다
4개 단계에서의 사용자 모드 TLS
● 단계 1: 사용자 및 SLP 운용자는 임시 사용자명 & 패스워드에 동의한다:(Username_temp, Password_temp).
● 단계 2: 제1 SUPL 세션이 설정된다. 서버 인증 및 암호화는 서버 인증된 TLS에 기초하여 수행된다. 클라이언트 인증은 동의된 (Username_temp, Password_temp)를 사용하여 TLS-SRP (SRP = 보안 원격 패스워드)에 기초하여 수행된다.
● 단계 3: 제1 SUPL 세션 내에서, SLP는 SET에 송신되는 새롭고 암호적으로 강한 (사용자명, 패스워드)를 생성한다. SET는 (Username_temp, Password_temp)를 (사용자명, 패스워드)로 대체한다. SET는 보안 위치에서 (사용자명, 패스워드)를 저장한다.
● 단계 4: 모든 후속적인 TLS 세션들은 서버 인증된 TLS에 기초하여 서버 인증 및 암호화를 사용한다. 클라이언트 인증은 (사용자명, 패스워드)를 사용하여 TLS-SRP에 기초하여 수행된다.
사용자 모드 TLS 단계 1 - 상세항목들
● 사용자 및 SLP 운용자는 임시 사용자명 및 패스워드에 동의한다:(Username_temp, Password_temp)
● (Username_temp, Password_temp)는 다양한 방식들로 SET에서 프로비져닝될 수 있다
● 운용자에 의한 OTA(Over The Air) 프로비져닝
● 운용자의 저장소에서의 프로비져닝(SET의 플래싱)
● 메일에 의해 송신되거나 온라인 상으로 획득되며 SET 사용자에 의해 입력되는 사용자명 및 패스워드
● 그외
● SET에는 SLP의 URL이 프로비져닝된다
● SET에는 SLP를 인증하기 위해 요구되는 적절한 루트 인증서들이 프로비져닝된다
사용자 모드 TLS 단계 2 - 상세항목들
● 서버 인증 및 암호화를 개시하기 위해 제1 SUPL 세션의 제1 TLS 핸드쉐이크:
● SET → SLP: TLS-SRP 및 서버 인증서들을 가지는 TLS에 대한 지원을 표시하는 클라이언트 헬로우
● SLP → SET: 서버 인증서들을 가지는 TLS에 대한 암호 스위트를 표시하는 서버 헬로우
● 클라이언트 인증을 개시하기 위한 제2 TLS 핸드쉐이크
● SLP → SET: 재협상을 개시하기 위한 헬로우 요청
● SET → SLP: TLS-SRP에 대한 지원을 표시하며 TLS-SRP 사양들에 따른 Username_temp를 포함하는 클라이언트 헬로우
● SLP → SET: TLS-SRP의 선택을 표시하는 서버 헬로우
● 클라이언트 인증은 (Username_temp, Password_temp)에 기초하여 수행된다
● 새로운 세션 키들이 (오직 이 세션에 대해서만) 생성된다
● SET 및 SLP는 이제 보안 채널을 통해 SUPL 세션을 수행한다
사용자 모드 TLS 단계 3 - 상세항목들
● SLP는 임시 사용자명 및 패스워드(Username_temp, Password_temp)에 기초하여 암호적으로 강한 (사용자명, 패스워드)를 생성한다.
● SLP로부터 SET로의 제1 SUPL 메시지는 암호적으로 강한 (사용자명, 패스워드)를 전달한다.
● SET는 임시 (Username_temp, Password_temp)를 (사용자명, 패스워드)로 대체한다.
● SET는 임시 (Username_temp, Password_temp)를 폐기한다.
● SET는 보안 위치에 (사용자명, 패스워드)를 저장한다.
● 주의 1: 이 단계는, SLP 운용자가 사용자를 수반하지 않고 SET에 보안적으로 사용자명/패스워드를 프로비져닝할 수 있었던 경우 수행되지 않을 수 있다
● 주의 2: 3GPP/3GPP2 초기 액세스에 대해, SLP는, SET가 사용자에게 속함을 추가로 검증하기 위해 SET IP 어드레스가 SET MSISDN 또는 IMSI와 연관됨을 코어 네트워크에서 검증할 수 있다
사용자 모드 TLS 단계 4 - 상세항목들
● 후속적인 TLS 세션 설정에 대해:
● 서버 인증 및 암호화를 개시하기 위한 TLS 핸드쉐이크:
- SET → SLP : TLS-SRP 및 서버 인증서들을 가지는 TLS에 대한 지원을 표시하는 클라이언트 헬로우
- SLP → SET: 서버 인증서들을 가지는 TLS에 대한 암호 스위트를 표시하는 서버 헬로우
● 클라이언트 인증을 개시하기 위한 제2 TLS 핸드쉐이크:
- SLP → SET: 재협상을 개시하기 위한 헬로우 요청
- SET → SLP :TLS-SRP에 대한 지원을 표시하며 TLS-SRP 사양에 따른 사용자 명을 포함하는 클라이언트 헬로우
- SLP → SET: TLS-SRP의 선택을 표시하는 서버 헬로우
- 클라이언트 인증은 (사용자명, 패스워드)에 기초하여 수행된다
- 새로운 세션 키들이 생성된다
● SET 및 SLP는 이제 보안 채널을 통해 SUPL 세션을 수행할 수 있다
● 주의: 일단 암호적으로 보안적인 사용자명/패스워드가 제공되면 PSK-TLS가 후속적인 액세스를 위해 사용될 수 있지만, TLS-SRP의 재사용이 감소한 복잡성을 가지고 구현될 수 있다
SUPL INIT 보호 개요
● SUPL 3.0에서의 SUPL INIT 보호는 SUPL 2.0에서의 SUPL INIT 보호 메커니즘에 기초하며, SUPL INIT에 첨부된 메시지 인증 코드(MAC)를 사용한다
● SUPL v3.0에서 공급되는 2가지 타입들의 보호:
● GBA 모드 보호
- SUPL v2.0 기본 보호와 동일함
● 사용자 모드 보호
- SLP에 의해 생성되는 (사용자명, 패스워드)에 기초하는 인증(즉, 서비스 활성화를 위해 사용되는 초기 사용자명/패스워드(Username_temp, Password_temp)를 사용하지 않음).
● 널 보호가 또한 지원되며, 운용자의 선택에 기초하여 사용될 수 있다.
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)에 대해, 널 SUPL INIT 보호는 이것이 (예를 들어, 리셋 커맨드를 통해) SET에 명시적으로 표시되는 한 SET를 리프로비져닝하기 위해 일시적으로 사용될 수 있으며, 따라서, 서비스 거절 공격은 다수의 SET들에 보호되지 않은 SUPL INIT들을 송신함으로써 이를 이용할 수 없다
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 (사용자명|| ":" ||패스워드":" || SLP_도메인 || ":SUPL30INIT" )
● SUPL_INIT_Z는 모두 제로들로 세팅된 SUPL_INIT_USER_MAC 필드를 가지는 SUPL INIT 메시지이다.
요약
● 새로운 보안 모델이 SUPL 3.0에 대해 설명된다: 사용자 모드 TLS.
● 사용자 모드 TLS는 (사용자명, 패스워드) 클라이언트 인증을 사용하는 반면, 서버 인증 및 암호화는 레거시 서버 인증된 TLS에 기초한다.
● SUPL INIT 보호는 또한 사용자 모드 TLS에서 지원된다
● 사용자 모드 TLS는 베어러 무관(bearer agnostic) 보안 모델이며, 따라서, SUPL 3.0에 대해 적합하다.
● 레거시 보안 모델들(ACA 및 GBA)은 SUPL 운용자의 선택에 따라 여전히 사용될 수 있다.
추천안
● 사용자 모드 TLS는 SUPL 3.0에 대한 보안 모델로서 채택될 수 있다.
● 레거시 ACA 및 GBA 보안 모델들에 대한 지원이 유지될 수 있다.
SUPL 3.0 액세스 SLP (A- SLP )
● 로밍 가입자에 대해, 정확한 포지셔닝의 지원은 H-SLP 제공자에 대해서는 어려울 수 있지만, 로컬 로밍 영역 내의 위치 제공자에 대해서는 훨씬 더 쉬울 수 있다
● 운용자들은 일부 경우들에서 운용자 B의 가입자에 대해 유리한 운용자 A에 속하는 H-SLP를 일시적으로 사용할 수 있는 다른 운용자들 및 제공자들과의 비즈니스 관계들을 가질 수 있다.
● SUPL 3.0 RD는 SLP들에 대한 더 용이한 액세스 및 더 광범위한 이용성에 대해 적응된 요건들을 포함한다:
● SUPL-EMER-03 : SUPL는 비상 위치 요청에 대해 SET 개시된 및 네트워크 개시된 포지셔닝을 지원할 것이다
● SUPL-HLF-18: SUPL는 SLP 서비스 발견을 지원할 것이다
● 일부 가입자들은 H-SLP를 가지지 않거나 - 예를 들어, 홈 운용자는 SUPL를 지원하지 않는다 - 또는 H-SLP SUP 지원을 벗어나도록 선택할 수 있다
● 일부 운용자들은 로밍 가입자들 - 예를 들어, H-SLP가 없는 가입자들 또는 자신의 H-SLP가 특정 로밍 영역 내의 위치를 적절하게 지원할 수 없는 가입자들 - 에 대한 SUPL 지원을 확장하기를 원할 수 있다
액세스 SLP (A- SLP )
● A-SLP는 액세스 네트워크 제공자에 속할 수 있고, 액세스 네트워크와 연관되거나 액세스 네트워크의 지리적 영역을 지원할 수 있다
● A-SLP는 - 예를 들어, 모든 네트워크 및 SET 개시된 서비스들을 포함하는 - H-SLP와 거의 동일한 방식으로 SUPL 3.0를 지원할 수 있다
● SET는 A-SLP에 대한 정보(예를 들어, A-SLP 어드레스 및 보안 파라미터들)을 발견할 필요가 있거나 이들이 제공될 것이다
● 가능한 정보 소스들은 액세스 네트워크, H-SLP 및 독립적(비-표준화된) 발견이다
● A-SLP 보안은 H-SLP에 대해 정의된 방법들을 재사용해야 한다 - 예를 들어, 상이한 인증 방법을 회피한다
● A SET 및 A-SLP은 외부 SUPL 에이전트들 및 SET 모두에 대한 SUPL 3.0 서비스들을 지원하기 위해 제한된 사전-동의된 시간 기간 동안 상호작용할 수 있다
가능한 A- SLP 사용
● SET는 액세스 네트워크를 통해 ULP 3.0 메시지들을 사용하여 SLP와 통신하고, 홈 네트워크를 통해 ULP 3.0 메시지들을 사용하여 H-SLP와 통신한다
(A-SLP를 발견하고 검증하기 위해 선택적으로 사용됨).
● A-SLP는 MLP를 통해 SUPL 에이전트와 통신한다.
예시적인 사용자 경우들
● 예 1 - 새로운 도시, 타운, 여행자 사이트 등을 방문하는 사용자
● H-SLP는 항상 정확하지는 않게(예를 들어, 건물 내에 있는 경우) 오직 절대적 위치만을 지원할 수 있고, 관심 지점들, 맵들, 날씨/교통 정보 등과 같은 보조 정보를 제공하지 못할 수 있다.
● A-SLP는 발견 방향, 관심 지점들, 맵들, 날씨/교통 등과 같은 애플리케이션 레벨 서비스들(SUPL의 일부분이 아님)과 함께 더욱 연속적인 정확한 위치 지원을 제공할 수 있다.
● 예 2 - 비상 호출 지원
● A-SLP가 또한 E-SLP 능력을 지원하는 경우, SET에 의한 A-SLP의 발견은 추후 IP 기반 비상 호출을 보조할 수 있다
● SET는 이후 A-SLP로부터의 자신의 대략적 위치를 획득하고, 이를 비상 SIP INVITE에 포함시켜 이에 의해 호출 라우팅을 지원하는 옵션을 가진다
● 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는 이후 다른 디바이스들에 의한 사용자명/패스워드의 사용을 회피하기 위해 초기 사용자명/패스워드를 제1 SUPL 세션 상에서의 새로운 값들로 대체할 수 있다
● A-SLP 운용자가, 사용자명/패스워드가 프로비져닝된 SET가 의도된 사용자에게 속함을 항상 검증하지 못할 수도 있지만, 이는 모든 로밍 사용자들에 대해 동일한 레이트에서 과금되며 SET 개시 서비스들에 대해 주로 포커싱되는 A-SLP 서비스들에 대해 문제가 되지 않을 수 있다.
● 주의: 대부분의 경우들에서, 사용자는, 현재 사용자명/패스워드로 하여금 비활성화되며 새로운 사용자명/패스워드에 의해 대체되도록 허용하는, (예를 들어, 초기 사용자명/패스워드가 획득되며 또 다른 사용자에 의해 사용되는 경우) A-SLP 제공자에게 A-SLP에 대한 액세스의 손실을 보고할 수 있다
A- SLP 보안 - 2
● 옵션으로서, H-SLP는 A-SLP에 대한 보안을 발견하고, 검증하고, 지원하는 것을 보조하기 위해 사용될 수 있다
● SET는 이들 파라미터들 중 하나를 가지는 H-SLP에 ULP 요청을 송신할 수 있다
● (A) 현재 SET 위치 또는 서빙 액세스 네트워크 신원
● (B) 이미 발견된 A-SLP 어드레스(예를 들어, 온라인으로 발견되거나 또는 액세스 네트워크에 의해 제공됨)
● (A)에 대해, H-SLP는 로컬 영역을 서빙하는 신뢰된 A-SLP의 어드레스를 리턴시킬 수 있다
● (B)에 대해, H-SLP는 A-SLP가 신뢰되는지, 신뢰되지 않는지 또는 H-SLP에 대해 공지되지 않은지의 여부를 표시할 수 있다
● 신뢰된 경우 (A)에 대해 그리고 (B)에 대해, H-SLP는 A-SLP 또는 H-SLP에 의해 할당되는 SET에 초기 사용자명/패스워드를 선택적으로 제공할 수 있다(이에 대해, A-SLP와 H-SLP 또는 연관된 제공자들 사이의 일부 추가적인 상호작용이 이후 사용자명/패스워드 및 사용자 식별을 전송하도록 요구될 것이다)
SUPL 3.0 AD 및 TS 영향들
● A-SLP를(기존의 H-SLP, V-SLP, E-SLP과 함께) 정의한다
● 적절한 디스커버리 메커니즘들을 정의하거나 참조한다
● 사용자 모드 TLS 보안의 사용을 표시한다
● A-SLP 디스커버리, 검증 및 보안에 대한 임의의 적절한 H-SLP 지원을 추가한다
● SET 및 A-SLP로 하여금 (각각의 종단이 그것이 새로운 세션에 대해 지원할 서비스들 중 다른 것을 통지하는 기존의 SUPL 3.0 메시지 흐름들에서 이미 지원되는 바와 같이) H-SLP 상호작용을 위해 사용되는 것들의 서브세트에 지원되는 서비스들을 제한하도록 허용한다
● (만약 존재하는 경우) 임의의 새로운 프라이버시 요건들을 식별 및 지원한다
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) (예를 들어, H-SLP가 존재하지 않는 경우 적용가능한) A-SLP를 항상 사용한다
● 전체 결과는 제공자들 및 사용자들에게 유리할 연관된 배치 및 SUPL 3.0 사용을 증가시키는 것일 수 있다
● A-SLP는 SUPL 3.0의 일부분으로서 포함될 수 있다
● H-SLP 보안 지원을 재사용하고, H-SLP로 하여금 A-SLP 액세스를 보조하거나 제어하도록 허용한다
● (예를 들어, A-SLP 발견 및 A-SLP 및 H-SLP 공급자들 사이의 상호작용에 관한) 비-SUPL 지원의 일부 레벨을 허용한다
추가적인 실시예 6
서문
● 이 실시예는 클라이언트 인증을 위한 디바이스 인증서들을 사용한다.
> SUPL 3.0 보안 개념 개요 I
ACA SUPL 1.0 및 2.0에서 지원되는 바와 같은 대안적인 클라이언트 인증. 서버 인증서들에 기초하여 서버 인증을 가지는 TLS를 사용하여 보안된 데이터. 코어 네트워크를 수반하는 IP 어드레스/MSISDN 일치성 체크를 사용하는 클라이언트 인증. 매체 보안 요건을 가지며 IP 어드레스 클라이언트 검증에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
GBA SUPL 2.0에서 지원되는 바와 같은 GBA 기반 보안. 오직 3GPP/3GPP2 네트워크들에 대해 적용가능함. GBA를 사용하여 설정된 공유 키에 기초하여 상호 인증을 가지는 TLS-PSK를 사용하여 보안되는 데이터. 높은 보안 요건을 가지며 GBA 인프라구조에 대한 액세스를 가지는 SUPL 배치들에 대해. 이는 레거시 보안 방법이다.
디바이스 인증서들 서버 인증을 위한 서버 인증서들을 사용하는 상호 인증 및 클라이언트 인증을 위한 제조자-프로비져닝된 디바이스 인증서들을 가지는 TLS를 사용하여 보안된 데이터 높은 보안 요건을 가지며 GBA 인프라구조에 대한 어떠한 액세스도 가지지 않는 SUPL 배치들에 대해. 이는 SUPL v3.0에 대한 새로운 보안 방법이다.
SUPL 3.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
● SLP는, 가입자 신원이 아닌 오직 SET 신원만이 인증되므로, 어느 가입자가 (인증된) SET와 연관되어야 함을 알고 있다.
● 이는 가입자가 SET들 사이에서 스위칭하는 것만큼 자주 발생한다
● 이는 사용자가 SLP에 SET 신원을 제공하기에 충분하지 않을 수 있다
● 이유 : 사용자 1은 SLP에 사용자 2의 세트 ID를 제공하고, "이것이 내 SET이다"라고 말할 수 있다. 이후, SLP는 사용자 2가 무엇이 발생했는지를 알지 않고, 사용자 1에게 사용자 2 위치의 상세항목들을 제공할 수 있다.
● 보안 방법은 가입자를 SET ID와 보안적으로 연관시키기 위해 사용된다.
● 방법은 범위 밖에서 남아 있다.
● 일부 시스템들은 이미 가입자(예를 들어, 애플, 블랙베리)와 디바이스 신원을 보안적으로 연관시키기 위한 메커니즘을 가진다
● 예시적인 방법이 하기에 제공된다.
(범위 밖) 가입자 허가 II
● 디바이스 신원과 가입자를 보안적으로 연관시키기 위한 예시적인 방법
● SLP 운용자는 SET를 사용하는 동안 SLP-소유된 웹 사이트에 접속하도록 가입자를 촉구한다.
● 가입자는 SET를 사용하는 동안 웹사이트(가능하게는 WAP)에 접속한다.
● 웹 서버는 디바이스 인증서 및 웹 서버 인증서를 이용하여 TLS 핸드쉐이크를 요청한다
● 이러한 인증서는 SLP 서비스 공급자(servicer)와는 다를 수 있다
● 가입자는 웹 사이트와의 일부 (범위 밖) 인증을 수행한다. 예를 들어, 웹 사이트는 SLP-특정적 사용자명/패스워드, 또는 연합된 사용자명/패스워드 또는 주소, 생년월일 등과 같은 다른 가입자 상세항목들을 요청할 수 있다.
● SLP 운용자는 이제 디바이스 신원과 가입자를 보안적으로 연관시키고, SLP 내에 이러한 연관을 저장해야 한다.
런타임 TLS 핸드쉐이크 개요
● 디바이스 인증서 기반 인증
● 서버는 보안 암호화된 IP 접속을 생성하는 ACA에서와 같이 공개 키 TLS를 사용하여 먼저 인증된다
● 이는 디바이스 인증서에서 디바이스 신원을 감춤으로써 익명성을 보존한다
● 다음으로, 클라이언트 및 서버는 서버 인증서들 및 디바이스 인증서들에 기초하여 상호간에-인증된 TLS를 수행한다
런타임 TLS 핸드쉐이크 상세항목들
● 서버 인증된 보안 터널을 개시하기 위해 제1 SUPL 세션의 제1 TLS 핸드쉐이크:
● SET → SLP: 서버 인증서들 및 디바이스 인증서들을 가지는 TLS에 대한 지원을 표시하는 클라이언트 헬로우
● SLP → SET: 서버 인증서들을 가지는 TLS에 대한 암호 스위트를 표시하는 서버 헬로우
● SLP ← → SET: 보안 터널을 설정하기 위해 TLS 핸드쉐이크를 완료한다
● 상호 인증을 수행하기 위한 제2 TLS 핸드쉐이크
● SLP → SET: 재협상을 개시하기 위한 헬로우 요청
● SET → SLP: 서버 인증서들 및 디바이스 인증서들을 가지는 TLS에 대한 지원을 표시하는 클라이언트 헬로우
● SLP → SET: 서버 인증서들 및 디바이스 인증서들을 가지는 TLS의 선택을 표시하는 서버 헬로우
● SLP ← → SET: 보안 터널을 설정하기 위해 TLS 핸드쉐이크를 완료한다
● SET 및 SLP는 이제 보안 채널을 통해 SUPL 세션을 수행할 수 있다
인증서 폐지
● 디바이스 및 서버 인증서들 모두가 폐지될 수 있다
● 디바이스 및 서버 모두, 디바이스 인증서가 폐지되었는지의 여부를 체크하기 위해 인증서 폐지 리스트(예를 들어, [RFC3280]) 또는 온라인 인증서 상태 프로토콜(OCSP) [RFC2560]과 같은 방법들을 사용할 수 있다
● 특정 방법은 스테이지 3 고려이다
SUPL INIT 보호 개요
● SUPL 3.0에서의 SUPL INLT 보호는 SUPL 2.0에서의 SUPL INLT 보호 메커니즘에 기초하며, SUPL INLT에 부착된 메시지 인증 코드(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은 SUPL_INIT_ROOT_KEY를 제공하기 위해 SLP에 대한 메커니즘을 추가한다
모드 B 보호 SUPL _ INIT _ ROOT _ KEY
● 모드 B SUPL_INIT 보호는 SLP로 하여금 디바이스에 SUPL_INIT_ROOT_KEY를 프로비져닝하도록 요구한다
● SUPL_INIT_ROOT_KEY는 디바이스 및 가입자의 이러한 조합에 대해 고유하다
● SUPL_INIT_ROOT_KEY가 오직 서비스 거절 공격에 대해 SPL에 대한 보호의 제공을 위해 사용될 수 있다는 점에 유의한다.
● 키가 임의의 사용자 데이터를 나타내지 않을 것을 개시한다
● 키가 서비스 거절 공격에 수반될 수 있는 오직 하나의 추가 디바이스만을 추가할 것을 개시한다
● 각각의 SUPL_INIT_ROOT_KEY가 적은 값을 가지므로, 키는 효과적으로 "영구적"일 수 있고 가입과 연관된 다른 상세항목들을 가지고 저장될 수 있다
● 즉, 특별한 서버가 이들 키들을 보안하는데 필수적이지 않다.
● 주의: SET는 이것이 소유권 변경을 표시하므로 UICC가 제거되는 경우 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로부터 수신한 제1 SUPL_INIT 메시지를 수용한다.
● SUPL_INIT_ROOT_KEY를 가지는 모드 B 사용
● 일단 SUPL_INIT_ROOT_KEY가 프로비져닝되면, SET는 MAC 및 시간이 올바르게 검증된 경우 자신이 SLP로부터 수신한 SUPL_INIT 메시지를 수용하고, 그렇지 않은 경우 SUPL_INIT 메시지를 수용하지 않는다
● 모드 B 예외 - 하드 리셋
모드 B 개시 프로비져닝
● SUPL_INIT_ROOT_KEY 프로비져닝을 개시하고, SUPL_INIT_ROOT_KEY 프로비져닝은 SET 및 SLP 사이의 (보안된) ULP 세션 동안 발생한다
● SUPL_INIT_ROOT KEY 프로비져닝 개시
● 보안된 ULP 세션의 시작에서, SET가 자신이 SUPL_INIT_ROOT_KEY를 가지지 않음을 통지하는 경우, SET는 제1 ULP 메시지 내에 SUPL_INIT_ROOT_KEY_요청 표시자를 포함시킴으로써 SUPL_INIT_ROOT_KEY 프로비져닝을 개시한다.
● 세션이 달리 발생하지 않는 경우 시간 기간 동안 소정 개수의 SUPL INIT 실패들 이후에 SET가 (SUPL_INIT_ROOT_KEY를 요청하기 위해) SUPL 세션을 발신하도록 구성될 수 있다는 점에 유의한다.
● SLP가 SET 내의 SUPL_INIT_ROOT_KEY가 손상되었다고 의심하는 경우(예를 들어, SET가 일부 시간 동안 SUPL_INIT 메시지들에 응답하지 않는 경우), SLP는 SET로부터의 제1 ULP 메시지의 수신에 후속하여 SUPL_INIT_ROOT_KEY 프로비져닝을 개시할 수 있다.
모드 B 프로비져닝
● 주의: 이 프로시저는 "모드 B 개시 프로비져닝"에 후속한다
● SLP가 모드 B 보호를 지원하지 않도록 선택한 경우, SLP는 SET에 적절한 표시를 송신한다.
● 그렇지 않은 경우
● SLP는 SUPL_INIT_ROOT_KEY를 획득한다
● SLP가 SET 및 가입자의 이러한 조합과 연관된 기존의 SUPL_INIT_ROOT_KEY를 가지는 경우, SLP는 자신의 레코드들로부터 이러한 값을 리트리브(retrieve)한다
● SLP가 SET 및 가입자의 이러한 조합과 연관된 기존의 SUPL_INIT_ROOT_KEY를 가지지 않는 경우, SLP는 프레쉬한 SUPL_INIT_ROOT_KEY를 생성한다
● SLP는 보안된 ULP 메시지 내의 파라미터로서 SET에 SUPL_INIT_ROOT_KEY를 송신한다
● SET는 SUPL_INIT_ROOT_KEY의 값을 저장한다.
● SET는 SET로 하여금 SUPL_INIT_ROOT_KEY의 저장된 값이 손상되었는지의 여부를 추후에 검출하도록 허용하는, 저장된 값에 일부 보호를 적용할 수 있다. 이러한 보호의 예들은 에러 정정 및/또는 무결성 체크를 포함한다.
SUPL _ INIT _ ROOT _ KEY 없는 모드 B 사용
● SET는 모드 B 보호가 적용될 수 있는 상태일 수 있지만, SUPL_INIT_ROOT_KEY를 가지지 않는다. 예들은 다음을 포함한다:
● 파워 업 시에, SUPL_INIT_ROOT_KEY가 프로비져닝되기 전.
● SUPL_INIT_ROOT_KEY는 손상되거나 삭제된다.
● SET가 이러한 상태에 있는 경우, SET는 MAC의 검증 없이, 자신이 SLP로부터 수신한 제1 SUPL_INIT 메시지를 수용한다
● SET는 SLP와의 TLS 세션을 설정한다
● SET는 SUPL_INIT_ROOT_KEY를 요청하기 위해 위의 모드 B 개시 프로비져닝 프로시저들을 수행한다
● SLP가 SET가 이러한 상태에 있음을 알고 있는 경우, SLP는, SET가 이러한 메시지들을 어떤 식으로든 수용할 것임을 알고서, 널 보호를 사용하여 SUPL_INIT 메시지들을 송신한다.
● 후속적인 ULP 세션에서, SET 또는 SLP는 SUPL_INIT_ROOT_KEY의 프로비져닝을 개시하기 위해 위의 모드 B 개시 프로비져닝 프로시저들을 사용할 수 있다
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를 가지는 경우, SET는 SUPL_INIT_TIME이 유효하고 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 메시지이다.
모드 B 예외 - 하드 리셋
● 운용자가 SUPL INIT 보호를 사용하는 예외 경우들(예를 들어, 비동기인 SET 및 SLP)에 대해, 널 SUPL INIT 보호는, 이것이 (예를 들어, 리셋 커맨드를 통해) SET에 명시적으로 표시되는 한, SET에 리프로비져닝하기 위해 일시적으로 사용될 수 있고, 따라서, 서비스 거절 공격은 다수의 SET들에 보호되지 않은 SUPL INIT들을 송신함으로써 이것을 이용할 수 없다
● 이러한 리셋 커맨드는 새로운 위협들을 유입하는 것을 방지하기 위해 SET에 직접 입력된다.
요약
● SUPL 3.0에 대한 새로운 보안 모델: 디바이스 인증서들을 사용하는 클라이언트 인증.
● 디바이스 인증서들은 제조시에 프로비져닝된다
● SUPL INIT 보호는 또한 디바이스 인증서들을 사용하는 클라이언트 인증에서 지원된다.
● 디바이스 인증서 기반 클라이언트 인증은 베어러 무관 보안 모델이며, 따라서, SUPL 3.0에 대해 적합하다.
● 레거시 보안 모델들(ACA 및 GBA)은 SUPL 운용자의 선택에 따라 여전히 사용될 수 있다.
추천안
● SUPL 3.0에 대한 보안 모델로서 디바이스 인증서들을 사용하는 클라이언트 인증.
●레거시 ACA 및 GBA 보안 모델들에 대한 지원을 유지한다.
추가적인 실시예 7
SUPL 2.0에 대한 보안 솔루션들은 3GPP, 3GPP2 및 WIMax 액세스 네트워크들을 통하는 경우가 아니면 이용가능하지 않고(예를 들어, WiFi 액세스를 지원하지 않을 수 있음) 강한 보안을 지원하기 위해 GBA의 구현을 포함하지 않을 수 있다. 추가로, 보안 솔루션들은 액세스 관련 SLP들(A-SLP들)로 하여금 홈 운용자 SLP들(H-SLP들) 대신 또는 이에 추가하여 지원되도록 허용하지 않을 수 있다.
이러한 실시예는 TLS-SRP를 사용하는 클라이언트(SET) 인증을 지원하기 위해 SLP 제공자에 의해 사용자 또는 사용자의 SUPL 인에이블 단말(SET)에 할당된 사용자 명 및 패스워드를 사용한다. SUPL SET 및 SLP는 SET로 하여금 SLP를 인증하도록 허용하기 위해 공개 키 TLS를 사용할 수 있다. 이는 TLS-SRP(및 사전 동의된 사용자명 및 패스워드)를 사용하여 SLP에 의해 제2 인증이 발생하는 SET의 보안 TLS/IP 접속을 생성할 수 있다. 이는 이후 보안 SUPL 세션을 지원하기 위해 사용되는 초기 보안 IP/TLS 접속을 수정할 수 있다. SLP는 이후 초기에 할당된 사용자명 및 패스워드를 대체하기 위해 SET에 새로운 사용자명 및 패스워드를 제공하기 위해 이러한 SUPL 세션을 사용할 수 있다. 새로운 사용자명 및 패스워드는 사용자에게 가시적이지 않을 수 있고; 이는 사용자가 하나 초과의 디바이스에서 사용자명 및 패스워드를 사용하는 것을 방지할 수 있고, 사용자가 다른 사용자들에게 초기 사용자명 패스워드를 우발적으로 전송하는 것을 보호할 수 있다. 해법은 H-SLP 및 A-SLP 모두에 대해 사용될 수 있고, 반드시 오직 3GPP, 3GPP2 또는 WiMax 액세스 네트워크들만의 사용을 요구하지는 않는다.
따라서, 설명된 실시예들은 SUPL 보안 지원을 모든 IP 액세스 네트워크로 확장하여, GBA를 지원해야할 필요 없이 현재 배치된 해법들보다 더 강한 보안을 제공할 수 있고, H-SLP 및 A-SLP를 지원할 수 있다(섹션 번호들은 SUPL 3.0 섹션 번호들을 참조할 수 있다).
6. 보안 고려사항들
이 섹션은 SUPL 네트워크로 하여금 SET를 인증 및 허가하게 하고, SET로 하여금 SUPL 네트워크를 인증 및 허가하게 하는 SUPL 보안 기능을 설명한다.
주의: 달리 특정되지 않는 한, 두문자어 TLS의 사용은 TLS 핸드쉐이크를 사용하여 협상될 수 있는 임의의 세션을 참조하며, 이는 TLS 1.1 암호 스위트들 및 TLS-PSK 암호 스위트들 모두를 포함한다.
주의: 이 섹션에서, 후속하는 정의들이 적용된다. 3GPP 베어러 네트워크는 표준들이 3GPP에 의해 유지되는 네트워크이고; 이들은 GSM, GPRS, EDGE, WCDMA/TD-SCDMA, LTE 및 LTE-A 베어러 네트워크들을 포함한다. 3GPP2 베어러 네트워크는 표준들이 3GPP2에 의해 유지되는 네트워크이고, 이들은 cdmaOne, cdma2000 1x 및 cdma2000 EV-DO 베어러 네트워크들을 포함한다. 3GPP SET(각각 3GPP3 SET)는 그것의 홈 네트워크 운용자가 주로 3GPP 베어러 네트워크(각각 3GPP2 베어러 네트워크)를 통해 데이터 액세스를 지원하는 SET 이다. WiMAX SET는 그것의 홈 네트워크 운용자가 주로 WiMAX 베어러 네트워크를 통해 데이터 액세스를 지원하는 SET이다. 모호성의 경우(예를 들어, 다수의 액세스 타입들을 지원하는 운용자), 운용자는 SET의 타입을 결정할 수 있다.
주의: H-SLP 운용자들은 여기서 설명된 인증 방법들이 동일한 운용자에게 속하는 액세스 네트워크들 사이에서 또는 SET IP 어드레스가 변경되지 않는 곳에서 SET 핸드오버에 대해 유효하게 유지된다는 점에 유의해야 한다. 프로시저들은, SET가 하나의 액세스 네트워크로부터 상이한 운영자들에게 속하는 또 다른 액세스 네트워크로 이동하거나, IP 어드레스가 변경되는 시나리오를 고려하지 않는다. 이들 시나리오들에서, 또 다른 액세스 시스템으로의 핸드오버 이후에, 보안 상황은 단말 및 네트워크에서 이용가능하지 않을 수 있으며, 네트워크 및 단말 사이의 신뢰 레벨은 변경될 수 있다고 가정된다.
파워 업 및 셧다운, 새로운 UICC의 검출 또는 UICC의 제거 시에, SET 핸드셋은 다음을 포함하는, SUPL 3.0과 연관된 SET 핸드셋 상에서 (장기 키들 이외의) 임의의 키들을 삭제해야 한다
■ GBA 키들: 예를 들어, Ks, Ks_NAF, Ks_ext_NAF
■ WIMAX 키들: 예를 들어, SEK
■ TLS 키들: 예를 들어, pre_master_secret, master_secret, 및 PSK 값들 (장기 키들 이외의).
■ SUPL 특정 키들: 예를 들어, SUPL INIT 메시지들의 보호와 연관된 키들.
6.1 SUPL 인증 방법들
SUPL 3.0에 대한 인증 지원 요건들은 다음과 같다:
● 상호 인증은 SET 및 H-SLP 사이에서 지원될 수 있다.
● 상호 인증은 SET 및 D-SLP 사이에서 지원될 수 있다.
● 서버 인증은 SET 및 E-SLP 사이에서 지원될 수 있고, 상호 인증은 SET 및 E-SLP 사이에서 지원될 수 있다.
SUPL 3.0은 SET 인증 방법들의 2가지 클래스들을 지원한다
● 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이 보안적으로 식별되기 전에 MSISDN 바인딩에 대한 IMSI를 수행해야 한다는 점에 유의한다.
키 관리의 상세항목들은 섹션 6.1.2에서 발견될 수 있다.
6.1.1 인증 방법들
섹션 6.1.1.1은 이 명세서에서 지원되는 인증 방법들을 열거한다. 이들 방법들에 대한 정보적 개요가 섹션 6.1.1.2에 제공된다. 섹션 6.1.1.3은 어느 방법들이 다양한 SUPL 3.0 엔티티들에서 의무적이거나 선택적인지를 설명하며, 그것이 주어진 상호-인증 방법을 지원하는 것인 경우 각각의 엔티티에서 요구되는 프로토콜들을 열거한다.
6.1.1.1 지원되는 상호-인증 방법들의 리스트
SUPL 인증 모델은, R-UIM/UICC/SIM/USIM 또는 SET 핸드셋과 같은 제거가능한 토큰에 바인딩되는, SLP 및 SET 사이의 공유 비밀 키들을 설정하는 것을 요구한다.
이 문서에서 특정되는 인증 방법들의 2가지 클래스들이 존재한다:
● 후속하는 방법들로 구성되는 PSK-기반 방법들:
○ 상호 인증을 제공하는, AN-종속적 포괄적 부트스트랩핑 아키텍처(GBA)-기반 방법;
○ 상호 인증을 제공하는, AN-종속적 SEK 기반 방법(오직 WIMAX SLP에만 적용가능함);
● 후속하는 방법들로 구성되는 인증서 기반 방법들:
○ 상호 인증을 제공하는, AN-독립적 디바이스-인증서 기반(DCert) 방법;
○ 상호 인증을 제공하는, AN-종속적 대안적 클라이언트 인증(ACA) 기반-방법;
○ 오직 SLP 인증만을 제공하는, AN-독립적 SLP-전용 방법(오직 비상 경우들에만 적용가능함).
6.1.1.2 지원되는 인증 방법들의 개요( 정보적 )
1. 포괄적 부트스트랩핑 아키텍처(GBA)-기반. 포괄적 부트스트랩핑 아키텍처(GBA)를 가지는 TLS-PSK는 기존의 3GPP/3GPP2 인증 메커니즘을 사용하여 유도되는 공유 비밀에 기초하여 상호 인증 능력을 제공한다.
● SET 및 SLP는 포괄적 부트스트랩핑 아키텍처(GBA)를 가지는 TLS-PSK를 사용하여 상호 인증된다.
2. SEK 기반(오직 WIMAX SLP에 대해서만 적용가능함).
● SET 및 SLP는 SEK를 가지는 TLS-PSK를 사용하여 상호인증된다. SEK 방법의 상세항목은 섹션 6.1.2.1.2에서 발견될 수 있다.
3. 디바이스 인증서(DCert) 기반. 이러한 AN-독립적 방법은
● SET에 대해 SLP를 인증하기 위한 RSA 서버 인증서,
● SLP에 대해 SET를 인증하기 위한 RSA 클라이언트 인증서
를 가지는 TLS를 사용한다.
4. 대안적인 클라이언트 인증(ACA)-기반. 이는
● SET에 대해 SLP를 인증하기 위한 RSA 인증서,
● SLP에 대한 SET의 대안적인 클라이언트 인증(섹션 6.1.4를 참조). 이 경우, SLP는 SET 식별자(MSISDN 등)와 연관된 IP 어드레스를 확인하기 위해 베어러 네트워크를 획득함으로써 SET를 인증한다.
5. SLP-전용. 이는, SLP가 SET를 인증하는 것이 가능하지 않은 시나리오들에서 사용된다. 이 방법은 비-비상상황 경우들에 대해 사용되지 않을 수 있다. SET는 이 방법 및 ACA-기반 사이에서 구별할 수 없다. 이는,
● SET에 대한 SLP를 인증하기 위한 RSA 인증서를 가지는 TLS를 사용하고,
● SET는 인증되지 않는다.
6.1.1.3 엔티티에 의한 상호-인증 방법들 및 프로토콜들에 대한 지원
하기의 4개의 표는 SET들 및 해당 SET들을 지원하는 SLP의 다양한 클래스들에서 SUPL 3.0를 지원하기 위해 어느 것이 선택적이고 의무적인지를 설명한다:
● 제1 표는 다음에서 SUPL 3.0에 대해 구현하기에 선택적인 방법들 및 의무적인 방법들을 표시한다
○ 3GPP/3GPP2 SET들,
○ SET (R-)UIM/ SIM/USIM 및
○ 3GPP/3GPP2 SET들을 지원하는 SLP들;
● 제2 표는 다음에서 SUPL 3.0에 대해 구현하기에 선택적인 방법들 및 의무적인 방법들을 표시한다
○ WiMAX SET들 및
○ 해당 WiMAX SET들을 지원하는 SLP들;
● 제3 표는 다음에서 SUPL 3.0에 대해 구현하기에 선택적인 방법들 및 의무적인 방법들을 표시한다
○ 3GPP/3 GPP2 또는 WiMAX를 지원하지 않는 SET들, 및
○ 해당 SET들을 지원하는 SLP들.
● 제4 표는 SLP, SET 핸드셋 및 (적용가능한 경우) 다양한 인증 방법들 각각을 지원하기 위한 SET (R-)UIM/ SIM USIM에 대해 요구되는 프로토콜들을 열거한다.
엔티티


 3GPP/3GPP2 SET들, SET(R-엔티티)UIM/SIM/USIM에 대한 SUPL 인증 방법 및 SLP 지원 3GPP/3GPP2 SET PSK-기반 인증서 기반 방법들의 요건 상태
PSK-기반 방법들 인증서-기반 방법들
GBA-기반 ACA-기반 DCert SLP-전용(E-SLP 전용)
SET
핸드셋		 선택적 의무적. 하기의 주의 2를 참조. 선택적. 의무적. 하기의 주의 1을 참조.
SET/SIM/USIM/(R)-UIM SIM/USIM/(R)-UIM은 이 방법에 관여하지만, 이는 이미 필요한 알고리즘을 지원한다. 이 엔티티는 이 방법에 관여하지 않는다 이 엔티티는 이 방법에 관여하지 않는다 이 엔티티는 이 방법에 관여하지 않는다
H/D-SLP 이들 2가지 방법들 중 하나를 지원하기 위해 의무적 선택적 지원되지 않음
E-SLP 선택적 선택적 선택적 의무적
3GPP/3GPP2 SET들 및 이들 SET들을 지원하는 SLP에 대한 다양한 인증 방법들의 요건 상태(의무적 또는 선택적).
주의 1: SLP-전용 방법에 대한 SET 핸드셋 지원이 비상 경우들에 대해 요구될 수 있다.
주의 2: ACA-기반 방법들에 대한(오직 3GPP 및 3GPP2에 대한) SET 프로시저들은 SLP-전용 방법에 대한 SET 프로시저들과 동일하다. 결과적으로, 3GPP/3GPP2 SET 핸드셋은 SLP-전용 방법이 비상 경우들에 대해 요구되는 결과로서, ACA-기반 방법을 지원한다.
엔티티

 WiMAX SET들, 및 이들 SET들을 지원하는 SLP들에 대한 SUPL 인증 방법에 대한 요건 상태
PSK-기반 방법들 인증서 기반 방법들
SEK 기반 ACA 기반 DCert SLP-전용(E-SLP 전용)
SET
핸드셋		 의무적 지원되지 않음 선택적 의무적
H/D-SLP 의무적 지원되지 않음 선택적 지원되지 않음
E-SLP 선택적 지원되지 않음 선택적 의무적
WiMAX SET들 및 이들 WiMAX SET들을 지원하는 SLP들에 대한 다양한 인증 방법들의 요건 상태(의무적 또는 선택적)
엔티티

 3GPP, 3GPP2 또는 WiMAX를 지원하지 않는 SET들, 및 이들 SET들을 지원하는 SLP들에 대한 SUPL 인증 방법에 대한 요건 상태
PSK-기반 방법들 인증서 기반 방법들
SEK/GBA 기반 ACA 기반 DCert SLP-전용(E-SLP 전용)
SET
핸드셋		 지원되지 않음 지원되지 않음 의무적 의무적
H/D-SLP 지원되지 않음 지원되지 않음 의무적 지원되지 않음
E-SLP 지원되지 않음 지원되지 않음 선택적 의무적
3GPP, 3GPP2 또는 WiMAX를 지원하지 않는 SET들 및 이들 SET들을 지원하는 SLP들에 대한 다양한 인증 방법들의 요건 상태(의무적 또는 선택적)
엔티티

 SET 및 SLP 사이의 인증 방법을 지원하기 위해 요구되는 알고리즘
PSK-기반 방법들 인증서 기반 방법들
GBA-기반
(3GPP/3GPP2 전용)		 SEK-기반(WiMAX 전용) ACA-기반(3GPP& 3GPP2 전용) DCert SLP-전용
(E-SLP 전용)
SLP GBA&TLS-PSK SEK&TLS-PSK 서버 인증서들 & IP 어드레스/SET ID 바인딩을 사용하는 TLS 서버 인증서들 및 클라이언트 인증서들을 사용하는 TLS 서버 인증서들을 사용하는 TLS
SET
핸드셋		 GBA&TLS-PSK SEK&TLS-PSK 서버 인증서들을 사용하는 TLS 서버 인증서들 및 클라이언트 인증서들을 사용하는 TLS 서버 인증서들을 사용하는 TLS
SET R-UIM/UICC/SIM/USIM 추가적인 알고리즘이 요구되지 않음 적용가능하지 않음 추가적인 알고리즘이 요구되지 않음 적용가능하지 않음 적용가능하지 않음
다양한 상호 인증 방법들을 지원하기 위한 SLP, SET 핸드셋 및 SET R-UIM/UICC/SIM/USIM에 대해 요구되는 프로토콜들.
GBA-기반 방법이 지원되는 경우, BSF는 H-SLP 애플리케이션들과 연관된 사용자 보안 세팅들(USS)을 저장한다. H-SLP가 USS를 요청하는 경우, BSF는 USS 내의 SET 사용자 신원(예를 들어, IMPI, IMSI 또는 MSISDN)을 포함해야 한다.
주의: GBA-기반 방법은 SUPL 세션들을 전송하기 위해 3GPP 또는 3GPP2 베어러 네트워크를 사용하는 것에 의존하지 않는다. 그러나, SET는 GBA를 수행하기 위해 필요한 크리덴셜들을 가지기 위해 3GPP 또는 3GPP 홈 네트워크 운용자를 가져야 한다.
6.1.1.4 TLS 핸드쉐이크 작업부하를 최소화하기 위한 기법들
이 섹션에서의 프로시저들은 SLP 및 SET 사이의 TLS 세션들의 설정과 연관된 작업부하를 최소화한다. TLS와의 충돌이 존재하는 경우, TLS가 우선을 취한다.
SET 및 SLP가 하나 초과의 SUPL 세션들과 연관된 SUPL 메시지들을 동시에 전달하는 경우, SET 및 SLP는 이들 메시지들을 보안하기 위해 단일 TLS 세션들을 사용해야 하는데, 즉, SET 및 SLP는 SUPL 세션들이 동시적인 경우 다른 TLS 세션들을 설정하지 않아야 한다.
SET 및 SLP가 TLS 세션을 설정하는 경우, SLP는 단축된 핸드쉐이크를 사용하여 세션이 재개되도록 한다. TLS 세션을 재개하는 것의 장점은, 서버 인증서들에 기초한 TLS 세션은 공개 키 동작들을 요구하지 않으며, 오직 대칭적 암호 알고리즘이 요구된다는 점이다(이는, 상당히 더 적은 프로세싱을 요구한다).
주의: 필요한 데이터를 저장하는 것을 보증하기에는 긴급 SUPL 세션들이 너무 자주 발생하기 때문에, 이러한 방식은 E-SLP에 대해 추천되지 않는다.
주의: 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 세션 ID 파라미터가 TLS 클라이언트헬로우 메시지에 존재하는 경우, SLP는 이후 TLS 세션을 재개할지의 여부를 선택한다. 어떠한 세션ID 파라미터도 TLS 클라이언트 헬로우 메시지에 존재하지 않는 경우, SLP는 이전 TLS 세션과 TLS 핸드쉐이크를 연관시킬 수 없고, 따라서, TLS 핸드쉐이크는 전체 핸드쉐이크를 사용하여 완전히 프레쉬한 TLS 세션을 설정한다.
SET는 후속하는 가이드라인들을 사용하여, TLS 세션을 재개할지의 여부를 선택한다.
■ SET는 기반 크리덴셜들(Ks(_ext)_NAF 또는 SLP 인증서 또는 SEK 또는 디바이스 인증서)이 만료되는 경우 TLS 세션을 재개하지 않아야 한다.
■ SET는, 원하는 경우, 기반 크리덴셜들의 만료보다 더 일찍 TLS 세션을 재개하지 않도록 선택할 수 있다.
■ SET는 새로운 R-UIM/ UICC/SIM/USIM의 파워업 또는 검출에 앞서 설정된 세션을 재개하지 않아야 한다.
SLP는 후속하는 가이드라인들을 사용하여, TLS 세션을 재개할지의 여부를 선택한다.
■ SLP는 기반 크리덴셜들(Ks(_ext)_NAF 또는 SLP 인증서 또는 SEK 또는 디바이스 인증서)가 만료되는 경우 TLS 세션을 재개하지 않아야 한다.
■ SLP는 원하는 경우 기반 크리덴셜의 만료보다 더 일찍 TLS 세션을 재개하지 않도록 선택할 수 있다.
주의: 각각의 SLP는 단축된 핸드쉐이크를 허용할지의 여부를 스스로 결정해야 하며, 이러한 결정은 심지어 SET-바이-SET 기반으로 이루어질 수 있다. SLP는 자신이 기존의 TLS 세션을 재개하도록 수용할 경우 작은 위험성을 취한다. 이러한 위험성은 "순응적이지 않은(naughty)" SET가 (전체 TLS 핸드쉐이크 동안 설정된) master_secret를 분배할 가능성이며, 따라서, 다른 것들이 그 TLS 세션을 재개하여, 다수의 SET들로 하여금 단일 SET에 대해 과금될 서비스를 획득하도록 허용할 수 있다. "순응적이지 않은" SET는 SET 소유자의 지식 없이 이를 수행할 수 있다(예를 들어, 악성 코드가 책임이 있을 수 있다). 손실이 용이하게 제한될 수 있으며, SLP가 이러한 오용이 발생했음을 검출하는(또는 의심하는) 경우, SLP는 용이하게 (a) 해당 master_secret을 사용하여 TLS 세션들을 종료하고, (b) "순응적이지 않은" SET를 식별하고, (c) 사용자로 하여금 요구되는 경우 서비스들을 계속 가지도록 허용하기 위해 전체 핸드쉐이크를 사용하여 "순응적이지 않은" SET를 재인증할 수 있다는 점에 유의한다. 요약하면, DCert 방법, ACA-기반 방법 및 SLP-전용 방법에 대해 (감소한 계산의 견지에서) 세션들을 재개하는 것의 이점은 공격의 위험을 초과하는 것으로 여겨진다.
6.1.2 SUPL 인증을 위한 키 관리
SUPL 인증 모델은, R-UIM/UICC/SIM/USIM 또는 SET 핸드셋과 같은 삭제가능한 토큰에 바인딩된, SLP와 SET 사이에 공유 비밀 키들을 설정하는 것을 요구한다.
6.1.2.1 PSK -기반 방법들
6.1.2.1.1 GBA 방법을 지원하는 배치들
GBA를 지원하는 배치들의 경우, 공유 키들이 다음과 같이 설정된다:
● SLP가 (IP 통신을 보안하기 위한 그리고 SUPL INIT를 보호하기 위한) BSF를 형성하는 키 물질을 요청하는 경우, SLP는 또한 USS(사용자 보안 세팅들)을 요청해야 한다. USS는 영구적 사용자 신원(예를 들어, IMPI, IMSI 또는 MSISDN)를 포함해야 한다.
● SET 및 SLP 사이의 IP 통신을 보안하기 위해, SET 및 SLP는 공유 비밀 키를 유도하고, GBA를 사용하여 TLS-PSK에 따라 동작해야 한다. SLP는 SLP를 지정하는 잘 정의된 도메인 명칭 SLP_어드레스_FQDN, 예를 들어, slp.operator.com를 가져야 한다. TLS-PSK에 대해 사용될 수 있는 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리에 정의된다. SLP는 BSF에 의해 제공되는 영구 사용자 신원이 대응하는 보안 접속을 통해 SLP에 의해 수신되는 SUPL 메시지들 내의 SET 신원에 대응함을 확인해야 한다.
● SUPL INIT의 MAC 보호에 대해, 키들은 GBA에 따라 유도된다. SUPL INIT 보호를 위해 사용될 수 있는 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리에 정의된다. SUPL INIT 메시지에 포함되는 기본 MAC의 키 식별자는 Ks_NAF를 생성한 Ks의 B-TID이어야 한다. 주의: BSF로부터의 SUPL INIT 보호 키들에 대한 H/D-SLP 요청은 통상적으로 키 보안 IP 통신에 대한 H/D-SLP 요청과 동시에 발생할 것이다.
● SET는 자신에게 유효한 Ks가 항상 프로비져닝됨을 보장해야 한다. 어떠한 유효한 Ks도 존재하지 않는 경우, SET는 Ks를 프로비져닝하기 위해 GBA 부트스트랩핑 프로시저를 개시해야 한다. 새로운 Ks는 새로운 UICC (USIM/SIM/R-UIM)가 SET에 의해 검출될 때마다 설정되어야 한다. 추가적으로, SET는 (홈 네트워크 운용자에 의해 세팅된) Ks_NAF들의 수명이 만료되는 경우 새로운 공유 키들을 설정해야 한다.
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이고, LSK는 위치 기반 서비스들에 대한 WiMAX 네트워크 프로토콜들 및 아키텍처에서 특정된 바와 같이 유도된다
○ SEK는 LSK와 연관된 (위치 기반 서비스들에 대한 WiMAX 네트워크 프로토콜들 및 아키텍처에서 정의된 바와 같이) 위치 키 식별자(LSK-ID)를 이어받을 것이며, 키 신원은 WiMAX 배치들에 대한 B-TID로서 사용될 것이다.
● SUPL INIT의 MAC 무결성 보호를 위해, 키들이 후속하는 방식으로 유도된다:
○ SEK_MAC = HMAC- SHA256(LSK, "mac.slp.operator.com")의 16개 최상위(가장 좌측) 옥텟들, 여기서, 'operator.com' 는 SLP 운용자의 FQDN이고, LSK는 위치 기반 서비스들에 대해 WiMAX 네트워크 프로토콜들 및 아키텍처에 특정된 바와 같이 유도된다.
○ SUPL INIT 메시지에 포함되는 모드 AMAC의 키 식별자는 SEK_MAC를 생성한 LSK의 B-TID이어야 한다. 주의: WiMAX AAA로부터의 SUPL INIT 보호 키들에 대한 SLP 요청은 통상적으로 키 보안 IP 통신에 대한 SLP 요청과 동시에 발생할 것이다.
SET는 자신에게 유효한 SEK가 항상 제공됨을 보장해야 한다. 어떠한 유효 SEK도 존재하지 않는 경우, SET는 위에서 특정된 바와 같이 SEK를 유도해야 한다. 추가적으로, SET는 LSK의 수명이 만료하는 경우, 새로운 공유 키들을 설정해야 한다. SLP 및 WiMAX AAA 사이의 인터페이스는 SUPL 3.0의 범위 밖에 있다.
6.1.2.2 서버-인증서 기반 방법들
6.1.2.2.1 DCert 방법을 지원하는 배치들
DCert 방법을 지원하는 배치의 경우, 공유 키들이 다음과 같이 설정된다:
● SET 및 SLP 사이의 IP 통신을 보안하기 위해, SET 및 SLP는 SLP를 인증하는 서버-인증서 및 SET를 인증하는 클라이언트 인증서를 가지는 TLS-RSA를 사용해야 한다. 클라이언트 인증서는 글로벌하게 고유한 SET 디바이스 신원을 제공할 수 있다:
○ 3GPP SET들은 글로벌하게 고유한 SET 디바이스 신원으로서 IMEI를 사용할 수 있다.
○ 3GPP2 SET들은 글로벌하게 고유한 SET 디바이스 신원으로서 MSID를 사용할 수 있다.
○ WiMAX SET들은 글로벌하게 고유한 SET 디바이스 신원으로서 SET 일련 번호를 사용할 수 있다.
○ 모든 다른 SET들은 글로벌하게 고유한 SET 디바이스 신원으로서 적절한 글로벌 식별자(예를 들어, 벤더 신원을 포함하는 일련 번호)를 사용할 수 있다.
● SUPL 사용자는 이러한 디바이스가 자신의 가입과 연관되어야 한다는 점을 SLP에 보안적으로 검증해야 한다. 이러한 보안 검증은 이 사양의 범위 밖에 있다. 이 논제의 추가적인 논의에 대해서는 섹션 6.5를 참조하라.
● SUPL INIT의 MAC 무결성 보호를 위해, 키들은 ULP 메시지에서 SLP에 의해 SET에 제공된다. 이는 섹션 6.3.5에 설명된다.
6.1.2.2.2 ACA 방법을 지원하는 배치들
ACA 방법을 지원하는 배치들에서, 공유 키들이 다음과 같이 설정된다:
● SET 및 SLP 사이의 IP 통신을 보안하기 위해, SET 및 SLP는 SLP를 인증하는 서버 인증서를 가지는 TLS-RSA를 사용해야 한다. (위에서 논의된 삭제가능한 또는 통합된 토큰에 결과적인 공유 키들을 바인딩하는) SET 인증은 비-비상 경우들에 대해서는 섹션 6.1.4에 그리고 비상 경우들에 대해서는 섹션 6.2.5에 설명된다.
● SUPL INIT의 MAC 무결성 보호를 위해, 키들은 ULP 메시지에서 SLP에 의해 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에 설명된 바와 같이 (R-UIM/UICC/SIM/USIM 또는 SET 핸드셋에 결과적인 공유 비밀 키들을 바인딩하는) 어떠한 SET 인증도 존재하지 않는다.
● SUPL INIT의 MAC 보호는 이들 경우들에서 지원되지 않는다.
6.1.3 상호-인증 방법의 TLS 핸드쉐이크 및 협상
SET 및 SLP는 적용될 상호-지원되는 인증 방법에 동의할 필요가 있다.
6.1.3.1 상호-인증 방법의 협상에 관해( 정보적 )
H-SLP에 대한 TLS 접속을 설정하는 경우, SET는 우선, 후속하는 선호 순서에 따라, 가장 높은 선호도를 가지는 상호-지원되는 인증 메커니즘을 사용하여 접속을 설정하려고 먼저 시도한다:
■ PSK-기반 방법들: GBA 또는 SEK 기반 방법 제1 선호(지원되는 경우):
■ DCert 방법: 제2 선호(지원되는 경우)
■ ACA 또는 SLP-전용 방법들: (ACA-기반 방법 및 SLP-전용 방법 사이에 차이가 없다는 SET의 관점으로부터의) 제3 선호.
상호-지원되는 인증 방법이 존재하지 않는 경우, SET는 SUPL 세션을 수행하지 못할 수 있다.
PSK 기반 방법들을 지원하는 SET는 BSF 또는 WiMAX AAA가 경험하는 문제점들로 인해 주어진 시점에서 GBA 또는 SEK-기반 방법을 사용하지 못할 수 있다. 따라서, GBA 또는 SEK를 사용하여 인증을 설정하기 위한 SET에 의한 시도는 SET가 GBA 또는 SEK 기반 키들을 설정할 수 있음을 보증하지 않는다.
결과적으로, SET는 가장 높은 선호도를 가지는 상호-지원되는 인증 메커니즘을 항상 사용하지 못할 수도 있다. SET는 이용가능한 경우, 덜 바람직한 상호-지원되는 인증 메커니즘으로 되돌아가야 할 수도 있다.
PSK 기반 방법들만이 H-SLP에 의해 지원되는 것으로 (H-SLP 인증서들 내에) 표시되고, 부트스트랩핑이 실패하는 경우, SET는 온라인으로 다시 획득할 기회를 적절한 엔티티들에게 제공하기 위해, TLS 핸드쉐이크를 재시도하기 전에 잠시 대기할 수 있다.
SLP가 오직 GBA 또는 SEK만을 지원하는 경우, SLP는 GBA 또는 SEK를 배치한 캐리어들의 가입자들에게 SUPL 3.0 서비스들을 제공하도록 제한된다. SLP가 오직 ACA만을 지원하는 경우, SUPL 3.0은 오직 섹션 6.1.4에서 상세하게 논의되는 환경들에서만 사용될 수 있다. 이러한 경우, 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 핸드쉐이크를 개시하고, ClientHello.cipher_suites 필드는 TLS 키 교환 알고리즘에 대한 RSA 암호화를 사용하여 지원되는 TLS 암호 스위트들을 표시한다.
2. SLP는 수신된 클라이언트헬로우 메시지를 프로세싱한다. SLP는 ClientHello.ciphersuites 리스트를 검사하고, 상호 지원되는 암호 스위트를 선택한다.
a. SET 및 SLP 모두가 TLS-PSK 암호 스위트를 지원하는 경우, 이는 GBA에 대한 지원을 표시한다. SLP는 ServerHello, ServerKeyExchange 및 ServerHelloDone 메시지를 가지고 응답하며, ServerHello.cipher_suite는 상호 지원되는 TLS-PSK 암호 스위트를 표시한다.
b. 그렇지 않은 경우, SET 및 SLP는 인증서 기반 방법을 지원해야 한다
i. SLP가 DCert 방법을 지원하는 경우, SLP는
1. TLS 키 교환 알고리즘에 대한 RsA 암호화를 사용하는 상호 지원되는 TLS 암호 스위트를 표시하는 ServerHello.cipher_suite를 가지는 ServerHello
2. 인증서
3. CertificateRequest, 및
4. ServerHelloDone 메시지를 가지고 응답한다.
ii. 그렇지 않은 경우, SET가 3GPP/3GPP2 SET이고, SLP가 ACA 방법을 지원하는 경우, SLP는
1. TLS 키 교환 알고리즘에 대한 RSA 암호화를 사용하는 상호 지원되는 TLS 암호 스위트를 표시하는 ServerHello.cipher_suite를 가지는 ServerHello 인증서
2. 인증서
3. (어떠한 CertificateRequest 메시지도 송신되지 않음)
4. ServerHelloDone
를 가지고 응답한다.
3. SET는 ServerHello 메시지 및 SET에 대한 선택된 암호 스위트를 표시하기 위한 적절한 다른 메시지를 프로세싱한다
a. ServerHello.cipher_suite가 GBA가 SLP에 의해 선택되었음을 표시하는 경우, SET 및 SLP는 GBA 프로세스를 계속한다. 상세항목들은 본 문서의 범위 밖에 있다.
b. 그렇지 않은 경우, ServerHello.cipher_suite는 TLS 키 교환 알고리즘에 대해 RSA 암호화를 사용하여 상호 지원되는 TLS 암호 스위트를 표시한다
i. SET가 Certificate.Request를 수신한 경우,
1. SET가 DCert 방법을 지원하는 경우, SET는 디바이스 인증서를 지원하고 SET 및 서버는 TLS 핸드쉐이크를 완료한다. 서버는 디바이스 인증서 내의 글로벌하게 고유한 SET 디바이스 신원과 연관된 SUPL 사용자를 식별하려고 시도한다. SUPL 사용자가, SET 디바이스 신원이 자신의 가입과 연관되어야 함을 SLP에 이미 보안적으로 검증했다는 점이 가정된다.
a. 어떠한 SUPL 사용자도 식별되지 않는 경우, 세션은 종료되어야 한다. TLS 핸드쉐이크가 이미 완료되었다고 가정하므로, 서버는 ULP 계층에서 통신할 수 있다. 서버는 ULP 세션을 종료하고 이후 TLS 세션을 폐쇄하기 위해 적절한 ULP 에러 메시지를 송신해야 한다.
b. SUPL 사용자가 식별되는 경우, 서버는 SUPL 사용자와 동일한 허가를 SET에 제공한다.
2. 그렇지 않은 경우, SET는 자신이 DCert 방법을 지원하지 않음을 암시적으로 표시하기 위해 빈 ClientCertificate 메시지를 포함하여, SLP에 응답한다.
a. SLP가 ACA를 지원하는 경우, SLP 및 SET는 ACA 방법에 따라 계속한다. SLP는 ACA 방법을 사용하여 계속할 수 있다.
b. SLP가 ACA 또는 SLP-전용 방법을 지원하지 않는 경우(SLP가 오직 DCert 방법만을 지원할 수 있는 경우), SLP는 적절한 TLS 경고 메시지들을 이용하여 TLS 핸드쉐이크를 종료한다
ii. 서버가 Certificate.Request를 송신하지 않은 경우, SET는 ACA 방법에 따라 계속한다. SLP는 ACA 방법 또는 SLP-전용 방법을 사용하여 계속할 수 있다.
3GPP2 SET들은 선택된 차이점들을 가지는 인증 방법의 협상을 위한 유사한 방법을 사용할 수 있다.
6.1.3.3 WiMAX SET 및 SLP 에 대한 인증 및 키-재협상을 위한 원리들( 정보적 )
키 재협상은 2가지 방식으로 일어날 수 있다:
1. (위치 기반 서비스들에 대한 WiMAX 네트워크 프로토콜들 및 아키텍처에서 정의된 바와 같은) 위치 루트키가 만료하는 경우, SET는 자동으로 WiMAX 네트워크를 이용하여 스스로를 재인증하고, SUPL 연관된 루트 키들은 SET에 의해 재생성될 것이다, 또는
2. SLP는 SEK 또는 (위치 기반 서비스들에 대한 WiMAX 네트워크 프로토콜들 및 아키텍처에서 정의된 바와 같은) 위치 루트키가 만료했으며, WiMAX AAA-서버로부터 새로운 키를 요청할 것임을 통지한다, 또는
3. SLP는 TLS 핸드쉐이크 동안 "psk_identity_unknown" TLS 경고 메시지를 송신한다. 이는 SET가 WiMAX 네트워크를 이용하여 스스로를 재인증할 필요가 있으며, SUPL 연관된 루트 키들이 SET에 의해 재생성될 것임을 SET에 표시한다.
6.1.3.3.1 인증 프로시저
WiMAX 배치들에서, PSK TLS 핸드쉐이크는 다음과 같이 SEK와 함께 사용될 수 있다:
- ClientHello 메시지는 하나 이상의 PSK-기반 암호 스위트들을 포함할 수 있다
- ClientHello 메시지는 특정된 바와 같이 서버_명 TLS 확장을 포함할 수 있고, 이는 SLP의 호스트명을 포함할 수 있다
- ServerHello는 SLP에 의해 선택된 PSK-기반 암호 스위트를 포함할 수 있다
- ServerKeyExchange은 서버에 의해 송신될 수 있고, 이는 psk_identity_hint 필드를 포함할 수 있고, 이는 정적 스트링 "SUPL WIMAX 부트스트랩핑"을 포함할 수 있다
- ClientKeyExchange는 psk_identity 필드를 포함할 수 있고, 이는 섹션 6.1.2.1.2에 특정된 바와 같이 프리픽스 "SUPL WIMAX 부트스트랩핑", 분리 캐릭터 ";" 및 현재 B-RID를 포함할 수 있다
- SET는 SLP 특정 키 물질, 즉, SEK로부터 TLS 프리마스터 비밀을 유도할 수 있다.
6.1.3.3.2 인증 실패들
인증 실패들은 이 문서의 범위 밖의 문서(들)에 설명된 바와 같이 핸들링될 수 있다.
6.1.3.3.3 부트스트랩핑 요구 표시
TLS 핸드쉐이크 동안, SLP는 SEK 키가 PSK-기반 암호 스위트를 포함하는 ServerHello 메시지, 및 정적 스트링 "SUPL WIMAX 부트스트랩핑"을 포함하는 psk_identity_hint 필드를 포함하는 ServerKeyExchange 메시지를 송신함으로써 요구될 수 있음을 SET에 표시할 수 있다. SET가 유효 SEK를 가지지 않는 경우, 이는 섹션 6.1.2.1.2에 정의된 바와 같이 새로운 SEK를 유도하도록 SET를 트리거링할 수 있다
6.1.3.3.4 부트스트랩핑 재협상 표시
TLS 세션의 사용 동안, SLP는 SET에 close_notify 경고 메시지를 송신함으로써 SET가 만료되었음을 SET에 표시할 수 있다. SET가 오래된 세션 ID를 포함하는 ClientHello 메시지를 송신함으로써 오래된 TLS 세션을 재개하려고 시도하는 경우. SLP는 새로운 세션 ID를 가지는 ServerHello 메시지를 송신함으로써 오래된 세션 ID를 사용하는 것을 거절할 수 있다. 이는 자신이 사용한 SEK가 만료되었음을 SET에 표시할 것이다.
TLS 핸드쉐이크 동안, SLP는 SET에 의해 송신된 완료된 메시지에 대한 응답으로서, 핸드쉐이크_실패 메시지를 송신함으로써 SEK가 만료되었음을 SET에 표시할 수 있다. 이는 자신이 사용한 SEK가 만료했음을 SET에 표시할 것이다.
6.1.4 대안적 클라이언트 인증( ACA ) 메커니즘
이 섹션은 오직 GSM/UMTS 및 CDMA SET들을 지원하는 배치들에만 적용한다.
주의: 이 섹션 전반에 걸쳐, SET_ID는 MSISDN(SET가 3GPP 베어러 네트워크 상에 있는 경우) 또는 MDN, MIN 또는 IMSI(SET가 3GPP2 베어러 네트워크 상에 있는 경우) 중 하나를 참조한다.
섹션 6.1.3은 ACA-기반 방법이 SLP에 의해 선택될 수 있는 환경을 개요화한다. SLP가 TLS 핸드쉐이크 동안 ACA-방법을 선택하는 경우, SET_ID/IP 어드레스 맵핑 기반 클라이언트 인증은 SET를 인증하기 위해 SLP들에 의해 사용될 수 있다. 이 섹션의 나머지는 대안적 클라이언트 인증 메커니즘으로서 공지된, 이 메커니즘의 상세항목들을 설명한다. 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) 인증을 이용하여 TLS 1.1를 지원해야 한다. 추가로, SET에는 SLP 서버 인증서들을 검증하게 하는 루트 인증서가 프로비져닝되어야 한다. SET들에 대한 루트 인증서들의 프로비져닝을 위해 다양한 상이한 방법들이 존재함에 따라, 어떠한 특정 메커니즘도 본 명세서에 의해 정의되지 않는다. SUPL 운용자들은 TLS 1.1가 대안적인 클라이언트 인증을 위해 사용되는 경우 관련된 루트 인증서가 SET에 존재함을 보장할 필요가 있다.
대안적인 클라이언트 인증을 지원하는 SLP들이 TLS 1.1를 지원해야 하며, 대안적인 클라이언트 인증을 구현하는 SET들에 의해 검증될 수 있는 유효한 TLS 서버 인증서를 가져야 한다.
대안적인 클라이언트 인증(ACA) 메커니즘은 SLP가 SET에 할당된 SET_ID에 대한 SET의 IP 어드레스의 바인딩을 체크할 수 있는 메커니즘이다. ACA 메커니즘이 구현되는 경우, SLP는 SET로부터 수신된 SUPL 메시지의 소스 IP 어드레스를, SET를 어드레스지정하기 위해 SLP에 의해 사용되는 SET_ID에 매핑할 수 있어야 한다. 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은 이러한 메커니즘이 SUPL 3.0에서의 클라이언트 인증을 위해 사용되는 방법을 설명한다.
UDP/IP가 SUPL INIT를 전송하는 경우, SLP는 SET_ID를 사용하여 SET IP 어드레스에 대해 베어러 네트워크에 질의함으로써, 또는 IP 어드레스를 사용하여 SET_ID에 대해 베어러 네트워크에 질의함으로써 IP 어드레스를 먼저 검증할 수 있다.
6.1.4.1 ACA 프로시저들
네트워크-개시 시나리오들: 만약, SLP로부터 SUPL INIT 메시지를 수신한 이후(그리고, 이 문서의 다른 곳에서 설명되는 바와 같이 적절한 보안 메커니즘 및 통지/검증을 적용한 이후), SET가 대응하는 SUPL 세션들을 가지고 계속하도록 허가되는 경우, 기존의 개방된 상호-인증된 TLS 세션이 사용되거나, 이전의 재개가능한 TLS 세션이 섹션 6.1.1.4에서 논의되는 바와 같이 재개될 수 있다. 개방된 TLS 세션이 존재하지 않거나, SET 또는 SLP가 세션을 재개하지 않도록 선택하는 경우, SET 및 SLP는 프레시한 TLS 세션을 요구하고, SET 및 SLP는 인증된 방법을 협상하기 위해 섹션 6.1.3에 설명된 바와 같이 적절한 단계들을 수행한다.
후속하는 단계들은 대안적인 클라이언트 인증 메커니즘이 네트워크-개시 시나리오에서 SET를 인증하기 위해 적용될 경우 SLP에 의해 사용된다:
1. SUPL INIT 메시지가 SET_ID를 공급한 MLP 요청에 응답하여 송신되었다는 점에 유의한다. SLP는 MLP 요청에 대한 SLP 세션 ID를 할당하고, SUPL INIT를 송신한다. SLP는 SLP 세션 ID를 사용하여 MLP로부터의 요청과 SET로부터의 응답을 연관시킨다. 그러나, SLP는 응답하는 SET가 정확한 SET_ID에 대응함을 먼저 검증해야 한다. 나머지 단계들은 이러한 인증 프로세스를 설명한다.
2. SET는 SLP와의 TLS 1.1 세션을 설정한다. SET는 SLP에 의해 제시되는 TLS 서버 인증서가 SET 내에 구성된 SLP의 FQDN에 바인딩됨을 체크해야 한다.
3. SLP는 (SUPL INIT에 응답하여) SET로부터의 제1 SUPL 메시지 내의 SLP 세션 ID가 SLP에 의해 할당된 현재 유효한 SLP 세션 ID에 대응하는지의 여부를 결정한다. 제1 SUPL 메시지 내의 SPL 세션 ID가 유효한 SLP 세션 ID에 대응하지 않는 경우, SLP는 적절한 메시지를 이용하여 SUPL 세션을 종료한다. 그렇지 않은 경우, SLP는 대응하는 SET ID를 표기한다.
4. SET(
Figure pct00001
Figure pct00002
Figure pct00003
또는
Figure pct00004
)로부터의 제 1 SUPL 메시지에 응답하기 이전에, SLP는 SET의
Figure pct00005
를 검증해야 한다. 이를 달성하기 위한 2가지 방법들이 존재한다.
a.
Figure pct00006
를 요청한다.
i. SLP는 SET에 의해 이용되는 소스 IP 어드레스를 이용하여 현재
Figure pct00007
를 알아내기 위해 하부의 베어러 네트워크에 질문한다.
1. SET에 의해 송신된 제 1 SUPL 메시지의 소스 IP 어드레스에 대해 베어러로부터 유효한
Figure pct00008
가 리턴되는 경우에, SLP는 리턴된
Figure pct00009
가 올바른
Figure pct00010
와 내부적으로 관련되는지를 검사한다(단계 3을 참조). 검사가 실패하면, SLP는 적절한 메시지로 SUPL 세션을 종료한다. 그렇지 않으면, SET가 진짜인 것으로 고려되고, SLP는 SUPL 세션을 계속한다.
2. 유효한
Figure pct00011
가 발견될 수 없는 경우에, SLP는 관련된 SUPL 에러 메시지들로 SUPL 세션을 종료해야 한다.
b. IP 어드레스를 요청한다.
i. SLP는 소스 IP 어드레스가 이러한
Figure pct00012
와 관련된 SET에 의해 이용되는 것을 알아내기 위해 하부의 베어러 네트워크를 질문한다(단계 3을 참조).
1. 베어러 네트워크가 IP 어드레스를 리턴하는 경우에, SLP는 이러한 IP 어드레스가 제 1 SUPL 메시지의 소스 IP 어드레스에 대응하는 것을 검사한다. 이러한 검사가 실패하면, 그 후에 SLP는 적절한 SUPL 메시지로 SUPL 세션을 종료한다. 그렇지 않으면, SET는 진짜인 것으로 고려되며 SLP는 SUPL 세션을 계속한다.
2. IP 어드레스가 발견될 수 없는 경우에, SLP는 관련된 SUPL 에러 메시지들로 SUPL 세션을 종료해야 한다.
주석 : 베어러 네트워크는
Figure pct00013
어드레스 바인딩(binding)을 획득하기 위해 단계 4에서 (IP 어드레스를 요청하거나 SET_ID를 요청하는) 2가지 타입들의 질문 중 하나만을 지원할 수 있다. SLP는 베어러 네트워크에 의해 지원되는 방법에 따르는 것을 담당한다.
SET -개시된 시나리오들: SET가 SUPL 세션을 개시하려 원할 때, 기존의, 개방 상호-인증된 TLS 세션이 이용되어야 하거나, 이전의 재개가능한 TLS 세션이 섹션 6.1.1.4에 논의된 바와 같이 재개될 수 있다. 개방 TLS 세션이 존재하지 않는 경우에, 또는 SET 또는 SLP가 세션을 재개하지 않도록 선택하는 경우에, SET 및 SLP는 새로운 TLS 세션을 요구하며, SET 및 SLP는 인증 방법을 협상하기 위해 섹션 6.1.3에 설명된 바와 같은 적절한 단계들을 수행한다.
다음의 단계들은 대안적인 클라이언트 인증 메커니즘이 SET-개시된 시나리오에서 SET를 인증하기 위해 적용될 때 SLP에 의해 이용된다.
1. SET는 SLP와 TLS 1.1 세션을 설정한다. SET는 SLP에 의해 제시되는 TLS 서버 인증서가 SET에서 구성된 SLP의 FQDN에 바인딩되는지를 검사한다.
2. 제 1 SUPL 메시지(예를 들어,
Figure pct00014
Figure pct00015
)에 응답하기 이전에, SLP는 SET의
Figure pct00016
를 검증해야 한다. 이를 달성하기 위한 2가지 방법들이 존재한다.
a.
Figure pct00017
를 요청한다.
i. SLP는 SET에 의해 이용되는 소스 IP 어드레스를 이용하여 현재
Figure pct00018
를 알아내기 위해 하부의 베어러 네트워크에 질문한다.
1. SET에 의해 송신된 제 1 SUPL 메시지의 소스 IP 어드레스에 대해 베어러로부터 유효한
Figure pct00019
가 리턴되는 경우에, SLP는 리턴된
Figure pct00020
가 SET에 의해 제공된 바와 동일한지를 검사한다. 검사가 실패하면, SLP는 적절한 메시지로 SUPL 세션을 종료한다. 그렇지 않으면, SET가 진짜인 것으로 고려되고, SLP는 SUPL 세션을 계속한다.
2. 유효한
Figure pct00021
가 발견될 수 없는 경우에, SLP는 관련된 SUPL 에러 메시지들로 SUPL 세션을 종료해야 한다.
b. IP 어드레스를 요청한다.
i. SLP는 소스 IP 어드레스가 이러한
Figure pct00022
와 관련된 SET에 의해 이용되는 것을 알아내기 위해 하부의 베어러 네트워크를 질문한다.
1. 베어러 네트워크가 IP 어드레스를 리턴하는 경우에, SLP는 이러한 IP 어드레스가 제 1 SUPL 메시지의 소스 IP 어드레스에 대응하는지를 검사한다. 이러한 검사가 실패하면, 그 후에 SLP는 적절한 메시지로 SUPL 세션을 종료한다. 그렇지 않으면, SET는 진짜인 것으로 고려되며 SLP는 SUPL 세션을 계속한다.
2. IP 어드레스가 발견될 수 없는 경우에, SLP는 관련된 SUPL 에러 메시지들로 SUPL 세션을 종료해야 한다.
주석 : SLP-개시된 및 SET-개시된 시나리오들 둘 다에서, SLP는
Figure pct00023
를 현재 사용중인 소스 IP 어드레스에 바인딩하기 위해 베어러 네트워크에 적절한 질문을 송신함으로써 SET를 재인증할 수 있다. 이것이 유용할 수 있는 다양한 환경들이 존재하며, 예를 들어: (A) SET의 IP 어드레스가 TLS 세션 동안 변화하는 경우에, SLP는
Figure pct00024
가 새로운 IP 어드레스와 관련되는 것을 보증하기 위해 베어러 네트워크에 적절한 질문을 송신할 수 있다; (B) TLS 세션을 재개할 때, SLP는 섹션 6.1.1.4에 논의된 바와 같은 이전의 TLS 세션을 재사용할 수 있으며, 그에 의해 계산을 절감하며, SET를 인증하기 위해 베어러 네트워크에 간단하게 적절한 질문을 송신할 수 있다. 이러한 방식에서 SET를 재인증하는 것은 SET 그 자체와의 상호작용과 관련되지 않음을 주목한다.
6.2 E- SLP 에 적용가능한 인증 메커니즘들
6.2.1 긴급-서비스들 규제 기관들에 관하여
SUPL 3.0 긴급 SUPL 세션은 네트워크-개시(SUPL을 이용) 또는 SET 개시될 수 있다. 적절한 긴급 서비스들 규제 기관들은 이들 긴급 세션들에 대한 지원을 지시할 것이다:
Figure pct00025
적절한 긴급 서비스들 규제 기관들은 네트워크-개시된 또는 SET-개시된 세션들에 대한 지원을 지시하지 않을 수 있다;
Figure pct00026
적절한 긴급 서비스들 규제 기관들은 네트워크-개시된 세션들만을 지시할 수 있다;
Figure pct00027
적절한 긴급 서비스들 규제 기관들은 SET-개시된 세션들만을 지시할 수 있다;
Figure pct00028
적절한 긴급 서비스들 규제 기관들은 네트워크-개시된 그리고 SET-개시된 세션들 둘 다를 위한 지원을 지시할 수 있다.
6.2.2 긴급 세션들 동안의 SUPL 자원들의 우선순위화
SET 상의 긴급 SUPL 세션의 지속기간에 대해, SET에 관한 모든 SUPL 자원들은 긴급 세션에 대해 이용가능하게 이루어져야 한다. 결과적으로:
Figure pct00029
SET가 긴급 SUPL 세션을 시작할 때, 비-긴급 세션들과 관련된 임의의 SUPL 통신은 SET에 의해 즉시 종료되어야 한다. 비-긴급 SUPL INIT 메시지들이 이때 SET에 의해 프로세싱되는 경우에(예를 들어, 검증된 MAC을 갖거나 사용자 허용을 획득함), 그 프로세스들은 중단될 수 있으며 SUPL INIT 메시지들은 폐기될 수 있다.
Figure pct00030
SET가 긴급 SUPL 세션에 있는 동안 비-긴급 SUPL INIT 메시지(들)를 수신하는 경우에, 이들 SUPL INIT 메시지(들)는 폐기될 수 있다.
6.2.3 E- SLP FQDN
네트워크-개시된 긴급 SUPL 세션들에서, E-SLP의 FQDN은 다음과 같을 수 있다:
1. FQDN은 SUPL INIT에서의 E-SLP 어드레스로서 SET에 제공된다. E-SLP FQDN은 포맷
Figure pct00031
을 가질 수 있으며, 여기서
Figure pct00032
는 임의의 유효한 스트링일 수 있다.
2. FQDN이 SUPL INIT에 제공되지 않는 경우에, 제공된 H-SLP 어드레스가 이용될 수 있다.
3. FQDN이 상기의 1 또는 2에서 이용가능하지 않은 경우에, FQDN은 이하의 3가지 대안들 중 하나로 디폴트될 수 있다:
- (3GPP 베어러 네트워크에 접속되는 경우에) FQDN이 명시적으로 제공되지 않으면
Figure pct00033
Figure pct00034
이다. 이 경우에, MCC 및 MNC는 서빙 3GPP 네트워크에 대응한다.
- (3GPP2 베어러 네트워크에 접속되는 경우에) FQDN이 명시적으로 제공되지 않으면
Figure pct00035
Figure pct00036
이다. 이 경우에, MCC 및 MNC는 서빙 3GPP2 네트워크에 대응한다.
- (WiMAX 베어러 네트워크에 접속되는 경우에)
Figure pct00037
은 H-SLP 운영자의 FQDN인 경우에
Figure pct00038
이다.
SET-개시된 긴급 SUPL 세션들에서, E-SLP의 FQDN은 선호도의 순서로 되어 있을 수 있다:
1. (적용가능한 경우) 적절한 긴급 서비스들 규제기관들에 의해 지시된 FQDN.
2. H-SLP에 의해 검증되는 다른 수단들에 의해 또는 로컬 액세스 네트워크에 의해 제공되는 FQDN.
3. H-SLP에 의해 제공되는 FQDN.
6.2.4 긴급 SUPL INIT 메시지들을 프로세싱
SUPL INIT 메시지들의 SET 기반된 무결성 검증 및 메시지 기원 인증은 E-SLP에 의해 이용되지 않는다. 따라서, 긴급 SUPL INIT에서의 MAC 필드는 파퓰레이팅되지(populated) 않아야 한다.
긴급 호출 동안, SET는 긴급 SUPL INIT 메시지들의 엔드-투-엔드 보호를 적용하지 않을 수 있다.
일부 보호는 E-SLP 화이트리스트들(whitelists)의 이용에 의해 제공된다. E-SLP 화이트리스트는 (CellID 및/또는 NetworkID와 같은) SET의 현재 위치설정 추정치에 기초한다. E-SLP 화이트리스트는 SET가 수신된 긴급 SUPL INIT 메시지들을 프로세싱해야 하는 순서를 결정하기 위해 SET에 의해 이용된다: E-SLP 화이트리스트는 긴급 SUPL INIT 메시지들을 폐기하기 위해 이용되지 않을 수 있다.
6.2.4.1 E- SLP 화이트리스트
긴급 SUPL INIT 메시지가 (SMS 또는 OMA 푸시 또는 UDP/IP와 같은) 보안되지 않은 엔드-투-엔드인 채널을 통해 수신되는 경우에, 긴급 SUPL INIT 메시지가 위조되거나 변경될 수 있다. 이 섹션의 나머지는 SET가 가능한 한 곧 진짜인 E-SLP 서버를 접촉할 수 있음을 보증하기 위해 이용되는 보안 대응책들을 설명한다.
주석: 규제 요건들은 SET가 긴급 SUPL INIT 메시지들을 수용해야 하고 프로세싱해야 하는 조건들을 지시할 것이다. 예를 들어, 다수의 경우들에서, 규제 요건들은 SET가 현재 긴급 호출에 관계되는 경우에만 SET에 긴급 SUPL INIT 메시지들을 수용하고 프로세싱하도록 요청한다. 결과적으로, (SET가 긴급 SUPL INIT 메시지들을 수용해야 하고 프로세싱해야 하는) 조건들은 본 문서의 범위 밖에 있다.
SET가 긴급 SUPL INIT 메시지를 수신할 때, SET는 먼저 (SET가 긴급 SUPL INIT 메시지들을 수용해야 하는) 조건들이 현재 만족되는지를 먼저 검증해야 한다. 조건들이 만족되지 않으면, SET는 SUPL INIT 메시지를 무시할 수 있다. 본원에서의 설명은 SET가 긴급 SUPL INIT 메시지를 수신하였을 때 조건들이 충족되었음을 가정한다.
주석: 공격자들은 SET가 진짜의 긴급 SUPL INIT 메시지를 예상할 때와 동시에 다수의(가짜의) 긴급 메시지들을 SET에 송신할 수 있다. 긴급 SLP로부터의 긴급 SUPL INIT 메시지를 예상하는 것을 SET가 (미리) 듣지 못할 수 있는 경우들이 존재할 수 있다. 이러한 공격은 다음의 절차들을 위한 동기부여가 된다.
"수용 및 프로세스" 조건들이 충족되는 시간의 주기에 대해, 심지어 긴급 SUPL INIT 메시지가 E-SLP에 대한 예상되지 않은 어드레스를 정렬하는 경우에도 SET는 수신된 긴급 SUPL INIT 메시지들을 삭제하지 않아야 한다. 일단 SET는 조건들이 더 이상 충족되지 않는 것으로 결정하면(예를 들어, 일단 올바른 E-SLP가 접촉되었거나, 긴급 호출 이후에 충분한 시간이 경과하면), 그 후에 SET는 임의의 수신된 긴급 SUPL INIT 메시지들을 조용히 폐기해야 한다.
SET가 거짓의 긴급 SUPL INIT 메시지를 수신하고, 수용하며 프로세싱하는 경우에("수용 및 프로세스" 조건들이 여전히 충족되는 한편), 그 후에 SET는 긴급 SUPL INIT 메시지에서 표시된 E-SLP를 접촉하려 시도한 후에까지 긴급 SUPL INIT 메시지가 거짓이라는 표시를 수신하지 않을 수 있다. 그 표시는 E-SLP가 SUPL 세션을 거절할 때 발생한다. 이러한 프로세스는 즉각적이지 않으며, 따라서 하나보다 많은 긴급 SUPL INIT 메시지를 수신하는 경우에 SET가 SUPL INIT 메시지들을 큐잉하는 것이 필요할 수 있다.
E-SLP 화이트리스트는 그로부터 SET가 긴급 SUPL INIT 메시지들을 수신할 것을 예상할 수 있는 E-SLP FQDN들의 목록을 포함한다. SET는 화이트리스트 상에 있지 않은 E-SLP FQDN을 포함하는 긴급 SUPL INIT 메시지들 전에 화이트리스트 상에 있는 E-SLP FQDN을 포함하는 긴급 SUPL INIT 메시지들이 프로세싱되어야 함을 보증하기 위해 E-SLP 화이트리스트를 이용한다.
예시: 화이트리스트 상의 E-SLP FQDN을 포함하는 긴급 SUPL INIT 메시지들은 화이트리스트 상에 있지 않은 E-SLP FQDN을 포함하는 긴급 SUPL INIT 메시지들 전에 메시지가 프로세싱되는 것을 보증하기 위해 긴급 SUPL INIT 큐에서 순방향으로 푸시된다. E-SLP 화이트리스팅은 긴급 SUPL INIT 큐를 정렬하기 위한 제 1 기준이어야 한다. 제 2 기준은 선입 선출 원리를 이용하는 도달 시간이다:
Figure pct00039
SET가 SET의 현재 집약성(locality)에 대한 현재 E-SLP 화이트리스트를 갖는 경우에, SET는 큐를 정렬하기 위해 둘 다의 기준들을 이용한다.
Figure pct00040
SET가 SET의 현재 집약성에 대한 현재 E-SLP 화이트리스트를 갖지 않는 경우에, SET는 큐를 정렬하기 위해 선입선출 원리를 이용한다.
6.2.4.3 긴급 SUPL INIT 메시지들에 관한 절차들
긴급 SUPL INIT가 (보안 SIP 푸시와 같은) 보안된 엔드-투-엔드인 채널을 통해 수신되는 경우에, 긴급 SUPL INIT 메시지는 즉시 프로세싱될 수 있다. 이 서브섹션의 나머지 고려사항들은 이 경우에 무시된다.
긴급 SUPL INIT 메시지가 (SMS 또는 OMA 푸시 또는 UDP/IP와 같은) 보안되지 않은 엔드-투-엔드인 채널을 통해 수신되는 경우에, 메시지는 섹션 6.2.4.1에서와 같이 큐잉된다. SET는 응답하기 위해 E-SLP에 접속하려 시도하기 전에 적절한 검증 및 통보를 적용하는 그 방식을 큐의 메시지들을 통해 작동시킨다.
SUPL INIT 메시지에 응답하여, SET는 관련된 E-SLP(섹션 6.2.3을 참조)와 보안 TLS 세션(섹션들 6.2.5를 참조)을 설정할 수 있으며, 다음 중 하나가 발생한다:
Figure pct00041
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 메시지로 프로세싱된다.
Figure pct00042
SET를 인증한 후에(섹션 6.2.5를 참조), E-SLP가 SET를 두드러진 SUPL 세션과 관련시킬 수 있는 경우에, SET 및 E-SLP는 정상적으로 계속된다.
SET는 진짜 메시지가 발견될 때까지 긴급 SUPL INIT 메시지에 계속해서 응답한다. 일단 올바른 E-SLP가 식별되었으면 SET는 임의의 새로운 또는 큐잉된 SUPL INIT 메시지들을 폐기할 수 있다. 올바른 E-SLP로부터의 새로운 또는 큐잉된 SUPL INIT 메시지들이 여전히 프로세싱될 수 있다.
다음의 2개의 주석들은 규제기관들이 고려하기를 원할 수 있는 제안들이다.
주석: 일단 올바른 E-SLP가 식별되었으면, SET는 SUPL 세션이 성공적으로 완료할 때까지 이러한 올바른 E-SLP의 FQDN을 기억하는 것을 보증해야 한다. E-SLP를 갖는 TLS 세션이 이르게 종료하는 경우에(예를 들어, 데이터 접속성의 손실이 존재하는 경우에), SUPL 세션이 성공적인 완료를 계속할 수 있도록 TLS 세션이 재설정될 때까지 SET는 E-SLP와 TLS 세션을 재설정하도록 계속해서 시도해야 한다. 일부 환경들에서, SET는 TLS 세션을 여러 번 재설정하는 것이 가능할 수 있다. SET가 TLS 세션을 재설정할 때 성공하지 못하는 경우에, SET는 그에 관계없이 계속해서 시도해야 한다: 이는 긴급 상황이기 때문에, 성공의 이점은 플랫 배터리의 비용보다 더 크다.
주석: E-SLP가 인증 후이지만 SUPL 세션의 성공적인 완료 이전에 SET와의 접촉을 소실하는 경우에, E-SLP는 SET가 접촉을 재설정하고 SUPL 세션을 완료할 수 있으리란 희망으로 SUPL 세션을 개방상태로 남겨두어야 한다.
6.2.5 긴급 세션들을 위한 인증
주석: E-SLP에 의해 지원될 수 있는 상호-인증 방법들은 섹션 6.1.1.3에 특정된다. SET 및 E-SLP는 섹션 6.1.3에 특정된 바와 같이 TLS 핸드쉐이크 동안 상호-인증 방법을 협상한다.
긴급 세션을 위한 선호도의 순서는
Figure pct00043
GBA 또는 SEK 방법 : 제 1 선호도
Figure pct00044
DCert 방법 : 제 2 선호도
Figure pct00045
ACA 방법 : 제 3 선호도
Figure pct00046
SLP-만의 방법 : 최종 선호도. SLP-만의 방법은 최후의 수단으로서 보여져야 한다.
모든 이러한 경우들에 대한 E-SLP의 FQDN은 섹션 6.2.3에 논의된다.
GBA-기반 방법(3 GPP /3 GPP2 SET 들만): SET들 및 E-SLP들은 E-SLP가 NAF로서 동작하면서 섹션 6.1.3에 설명된 바와 같은 GBA로 PSK-TLS를 수행할 수 있다. 특정 SET에 대해 E-SLP에 의해 획득된
Figure pct00047
는 홈 네트워크 운영자에 의해 수명 세트에 대한 SET 아이덴티티(예를 들어, IMSI, MSISDN)와 관련하여 유지될 수 있다.
SEK 기반된 방법( WiMAX SET 들만): SET 및 E-SLP들은 E-SLP가 H-SLP와 유사한 방식으로 동작하면서 섹션 6.1.3에 설명된 바와 같은 SEK로 PSK-TLS를 이용하여 상호 인증을 수행할 수 있다. E-SLP의 FQDN은 섹션 6.2.3에 논의된다. 특정 SET에 대해 E-SLP에 의해 획득된 SEK는 홈 네트워크 운영자에 의해 수명 세트에 대한 SET 아이덴티티(예를 들어, WiMAX 사용자 ID)와 관련하여 유지될 수 있다.
DCert 방법(모든 SET 들): SET 및 E-SLP들은 섹션 6.1.2.2.1에 설명된 바와 같은 DCert 방법을 이용하여 상호 인증을 수행할 수 있다. SET는 SET에 포함되는 E-SLP의 루트 인증서 및 섹션 6.2.3에 정의된 바와 같은 E-SLP의 FQDN을 이용하여 E-SLP를 인증할 수 있다.
ACA-기반 방법(대응하는 베어러 네트워크들 상에 있는 동안만 3 GPP /3 GPP2 SET들): PSK-TLS를 갖는 GBA 및 DCert 방법 둘 다가 E-SLP에서 지원되지 않는 SUPL 3.0 구현들에 대해, 섹션 6.1.4에 정의된 대안적인 클라이언트 인증 메커니즘은 다음의 차이들로 지원될 수 있다. E-SLP는 서빙 네트워크―예를 들어, 3GPP 네트워크 또는 3GPP2 네트워크에서의 LRF 또는 E-CSCF에 의해 E-SLP에 제공되는 SET에 대한 IP 어드레스와 SET에 의해 이용되는 IP 어드레스를 바인딩함으로써 SET를 인증할 수 있다.
Figure pct00048
네트워크-개시된 세션들: 임의의 긴급 VoIP 호출을 개시하기 위해 SET IP 어드레스가 이용되며 SUPL이 인보크되기(invoked) 전에 서빙 네트워크에 의해 검증될 수 있기 때문에, E-SLP에 의해 신뢰성 있는 것으로 고려될 수 있다. 회로 모드에서 개시된 긴급 호출의 경우에, SET IP 어드레스는 서빙 네트워크에 알려지지 않을 수 있으며(예를 들어, 홈 네트워크에 의해 할당될 수 있음) 그 경우에 E-SLP가 서빙 네트워크에 의해 IP 어드레스를 제공받지 못할 수 있으며 SET로부터 나중에 수신된 때에 IP 어드레스를 검증할 수 없다.
Figure pct00049
SET -개시된 세션들: ACA 방법을 이용하기 위해, 서빙 베어러 네트워크는 베어러 레벨에서의 IP 어드레스 도용을 방지해야 한다. 심지어 SET가 베어러 네트워크상에 인증되어 등록되든지 아니든지 간에 ACA 방법이 적용될 수 있음이 주목되어야 한다. 이는 SET에 활성화된 SIM/USIM/UICC/(R)UIM이 존재하지 않는 경우들을 지원한다.
SLP -만의 방법(모든 세트들): 어떠한 다른 인증 방법도 이용될 수 있지 않으면, SET는 SLP-만의 방법을 이용하여 E-SLP에 보안 IP 접속을 설정할 수 있다. SET는 SET에 포함된 E-SLP의 루트 인증서 및 섹션 6.2.3에 정의된 바와 같은 E-SLP의 FQDN을 이용하여 E-SLP를 인증할 수 있다. 상호 인증을 수행하는 능력은 세션이 SET 개시되거나 네트워크-개시된 경우에 따른다.
Figure pct00050
네트워크 개시된 세션들: SUPL 세션이 네트워크 개시된 경우에, E-SLP는 섹션 6.2.6에 논의된 바와 같은 SUPL INIT의 수신된 해시(hash) 및 (예를 들어) 세션 ID에 기초하여 SET를 약하게 인증할 수 있다.
Figure pct00051
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는 SUPL INIT 메시지가 변경된 것을 검출한 경우에(예를 들어, 프록시 모드가 표시된 때에 SUPL AUTH REQ 메시지가 수신된 경우에, 또는 SLP 세션 ID가 잘못된 경우에 또는 VER이 섹션 6.3.1에 설명된 바와 같은 검증을 실패하는 경우에), E-SLP는 SET가 올바른 파라미터들을 제공받는 것을 보증하기 위해 TLS 세션을 통해 SET에 SUPL INIT를 송신해야 한다. 그에 응답하여, 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.3 SUPL INIT 메시지들의 프로세싱
네트워크 개시된 SUPL 세션들이 SUPL INIT 메시지에 의해 트리거링됨에 따라, 매스커레이딩에 대해 그리고 (일부 경우들에서) 리플레이(re-play) 공격들에 대해 SUPL INIT 메시지들을 보호하는 것이 필수적이다.
SUPL 3.0은 SUPL INIT 메시지들에 대한 다음의 보호를 특정한다:
Figure pct00052
네트워크-기반 보안, 여기서 SLP는 SUPL INIT 메시지들의 인증(섹션 6.3.1) 및 리플레이 보호(섹션 6.3.2)를 보증하기 위한 검사들을 수행할 수 있다. 이러한 검증은 SET가 SUPL INIT 메시지의 컨텐츠를 프로세싱하였으며 SUPL 세션을 수행할 목적들을 위해 SLP와 보안 TLS 세션을 설정한 후에 발생한다.
Figure pct00053
엔드-투-엔드 보안, 여기서: SLP는 암호화, 무결성 보호 및 리플레이 보호의 조합을 SUPL INIT 메시지에 적용할 수 있다; 그리고 SET는 복호화, 무결성 검증 및 리플레이 검출의 대응하는 조합을 적용한다. SET는 SUPL INIT 메시지의 컨텐츠를 프로세싱하기 전에 이들 보안 조치들을 적용한다. 이러한 보안은 비-긴급 SUPL INIT 메시지들에만 적용된다.
네트워크-기반 보안은 의무적인 한편, 엔드-투-엔드 보안은 임의선택적이다.
6.3.1 SUPL INIT 메시지의 네트워크-기반 인증
SLP는 항상 SUPL INIT 메시지의 무결성의 네트워크 검증을 수행한다. SUPL INIT 메시지에 응답하여 송신되는 제 1 메시지(즉, SUPL POS INIT, SUPL AUTH REQ 또는 SUPL TRIGGERED START 메시지)는 검증 필드(VER)를 포함해야 한다. SLP가 SUPL INIT 메시지에 응답하여 송신된 제 1 메시지를 수신할 때, SLP는 전송된 SUPL INIT 메시지를 통해 계산된 대응하는 값에 대해 수신된 VER 필드를 검사해야 한다. 이러한 검증이 실패하면, SLP는 상태 코드
Figure pct00054
를 포함하는 SUPL END 메시지로 세션을 종료해야 한다.
검증 필드에 대한 값은 다음과 같이 계산되어야 한다:
Figure pct00055
Figure pct00056
여기서 SLP는 SLP 어드레스의 FQDN이다. SHA-256은 opad 및 ipad를 갖는 해시(H) 함수로서 이용되어야 한다. SHA-256 해시 함수의 출력은 64 비트들로 단축되어야 하는데, 즉 함수는 HMAC-SHA256-64로서 구현되어야 한다. SLP 어드레스가 비밀로 고려되지 않음을 주목한다. 본원에 이용된 HMAC 구조는 어떠한 데이터 인증도 제공하지 않으며 HASH 함수에 대한 대안으로서만 이용된다.
6.3.2 SUPL INIT 메시지의 네트워크-기반 리플레이 보호
네트워크 개시된 경우들에 대해, 리플레이 공격들에 대한 보호가 SLP들에 의해 제공되어야 한다. SLP들은 이전의, 비-만료된 SUPL INIT 메시지가 SUPL 메시지 내에 수신된 것에 대응하는 "SLP 세션 Id"로 송신되지 않는 한 어떠한 SUPL 메시지들도 인증된 SET로부터 수용되지 않음을 보증해야 한다. SLP들은 또한 SUPL 메시지의 타입(예를 들어, SUPL POS INIT, SUPL AUTH REQ, SUPL TRIGGERED START)이 SUPL INIT 메시지에서 송신된 파라미터들에 동의하는 것을 보증해야 한다. 구현들은 "SLP 세션 Id"가 인증된 SET 사용자 ID(예를 들어, MSISDN, WiMAX 사용자 ID 또는 MDN)와 올바르게 관련되는 것을 보증해야 한다.
SET 사용자 인증은 본 문서에 설명된 대안적인 클라이언트 인증 방법을 이용하여 수행되는 경우에, SET로부터의 응답(SUPL POS INIT, SUPL AUTH REQ 또는 SUPL TRIGGERED START)의 소스 IP 어드레스와 SET 사용자의 MSISDN 또는 MDN 사이의 맵핑이 이미 설정되며 이러한 MSISDN 또는 MDN은 인증된 MSISDN 또는 MDN으로서 이용되어야 한다.
에러가 있는 SUPL POS INIT, SUPL AUTH REQ 또는 SUPL TRIGGERED START의 폐기는 SET에 대한 유료의 이벤트를 발생시키지 않아야 한다.
비-프록시 네트워크 개시된 경우들에 대해, SLP들은 SUPL 위치설정의 성공적인 완료를 위해 SPC로부터의 확인을 수신한 후에 충전가능한 이벤트만을 생성해야 한다.
6.3.3 SUPL INIT 메시지들의 엔드 -투- 엔드 보호
주석: SUPL INIT 메시지들의 엔드-투-엔드 보호는 비-긴급 SUPL INIT 메시지들에만 적용한다.
엔드-투-엔드 SUPL INIT 보호의 3가지 옵션들이 본 사양에 제공된다: 널(Null), 모드 A 및 모드 B-
Figure pct00057
널 SUPL INIT 보호는 엔드-투-엔드 무결성 보호, 엔드-투-엔드 리플레이 보호 및 기밀 보호를 제공하지 않는다. 널 SUPL INIT 보호에 대한 절차들은 섹션 6.3.4에 설명된다.
Figure pct00058
모드 A SUPL INIT 보호는 디폴트 알고리즘들을 이용하여 엔드-투-엔드 무결성 보호 및 엔드-투-엔드 리플레이 보호를 제공한다. 모드 A SUPL INIT 보호는 보호된 ULP 세션 동안 SLP에 의해 SET에 송신된 공유된 키를 이용한다. 모드 A SUPL INIT 보호에 대한 절차들은 섹션 6.3.5에 설명된다.
Figure pct00059
모드 B SUPL INIT 보호는 디폴트 알고리즘들을 이용하여 엔드-투-엔드 무결성 보호 및 엔드-투-엔드 리플레이 보호를 제공한다. 모드 B SUPL INIT 보호는 적절한 PSK-기반 방법(GBA 또는 SEK 방법들)을 이용하여 도출된 공유된 키를 이용한다. 모드 B SUPL INIT 보호를 위한 절차들은 6.3.6에 설명된다.
보호의 레벨을 위한 선호도의 순서는 다음과 같다:
Figure pct00060
널 SUPL INIT 보호는 최소의 선호도를 갖는다.
Figure pct00061
모드 A SUPL INIT 보호는 널 SUPL INIT 보호보다 높은 선호도를 갖는다.
Figure pct00062
모드 B SUPL INIT 보호는 모드 A SUPL INIT 보호보다 높은 선호도를 갖는다.
SUPL INIT 메시지에서 (다음의 표에서의) 보호 레벨 파라미터가 보호의 현재 레벨에 따라 할당된다.
주석: 본 사양은 장래의 개정들에 추가되도록 보호의 더 진보된 레벨들을 허용하도록 기록되었다. 이러한 진보된 보호는 (예를 들어, 암호화를 허용하며 알고리즘들의 협상을 허용하는) SUPL INIT를 보호하기 위한 다른 방식들의 협상을 허용할 수 있다. 보호 레벨 파라미터는 SUPL INIT 메시지를 파싱(parse)할 수 있을지 없을지를 결정하는데 있어서 SET를 돕기 위해 포함된다: 보호 레벨 파라미터는 확장성을 위해 요구될 수 있다.
SUPL INIT 메시지는 보안 파라미터들을 포함하기 위해 존재하는 보호자 파라미터를 가질 수 있다: 보호자 파라미터의 존재는 다음의 표에 특정된다.
엔드-투-엔드 SUPL INIT 보호의 레벨
설명
SUPL INIT에 보호자 파라미터가 존재하는가?
널(Null) 엔드-투-엔드 보호 없음 임의선택적
모드 A 디폴트 알고리즘들을 이용하는 무결성 보호 및 리플레이 보호 의무적
모드 B 디폴트 알고리즘들을 이용하는 무결성 보호 및 리플레이 보호 의무적
SUPL INIT 보호 레벨 파라미터 값들 및 SUPL INIT 에서의 보호자 파라미터의 존재
ACA-기반 방법을 지원하는 SET 또는 D-SLP 또는 H-SLP는 널 SUPL INIT 보호를 지원해야 한다.
모든 SET들은 모드 A SUPL INIT 보호 절차들을 지원해야 한다.
D-SLP 또는 H-SLP는 모드 A SUPL INIT 보호 절차들을 지원할 수 있다.
PSK-기반 방법을 지원하는 SET 또는 D-SLP 또는 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. SET는 (예를 들어, 파워-업 시에 또는
Figure pct00063
의 수명이 만료된 때) 유효한
Figure pct00064
가 존재하지 않을 때 널 SUPL INIT 보호를 적용해야 한다. 초기의 보호 레벨은 항상 널 SUPL INIT 보호이다. 이 상태에서 SET는 모든 SUPL INIT 메시지들을 취급하는데, 즉 어떤 메시지들도 조용하게 드롭되지 않는다. SUPL INIT 메시지는 실패 조건으로 파싱되는 경우에, SET는 에러 메시지를 SLP에 송신한다.
2. SET가 특정 SLP에 대해 모드 A 또는 모드 B SUPL INIT 보호를 이용하여 이미 협상된 유효
Figure pct00065
및 유효
Figure pct00066
를 갖는 경우에, SET는 협상된 모드(모드 A 또는 모드 B)를 이용하여 SLP로부터의 모든 SUPL INIT 메시지들을 프로세싱한다.
3. SET가 SLP에 대해 상호적으로-인증된 보안 접속을 설정할 때,
a. PSK-기반 방법(GBA 또는 SEK)이 상호 인증을 위해 이용된 경우에, 모드 B SUPL INIT 보호가 적용되며 PSK-TLS 핸드쉐이크에서 교환된 B-TID는 3GPP 및 3GPP2 배치들에서의
Figure pct00067
로서 이용될
Figure pct00068
를 도출하기 위해 이용될 수 있는 (3GPP 및 3GPP2 배치들에서
Figure pct00069
로서 이용될) Ks 또는 SEK에 대응한다. 이러한
Figure pct00070
또는 SEK 및 관련된 B-TID는 어느 한쪽일 때까지 모드 B SUPL INIT 보호에 이용된다:
i. 키가 만료하고, 그 경우에 SET 및 SLP는 널 SUPL INIT 보호로 되돌아가고
ii. SET 및 SLP는 비-긴급 세션에서 ACA-방법을 이용하며, 이 경우에 SET 및 SLP는 이하의 단계 3b에 논의된 바와 같이 모드 A 또는 널 SUPL INIT 보호로 되돌아가거나,
iii. SET 및 H-SLP는 새로운 B-TID를 이용하여 TLS를 설정하기 위해 GBA 또는 SEK의 부트스트랩핑 재협상 방법들을 이용하며, 이 경우에 B-TID 및 대응하는
Figure pct00071
또는 SEK는 이제 모드 B SUPL INIT 보호를 위해 이용된다.
b. 그렇지 않으면, SET 및 SLP는 DCert 또는 ACA 방법을 이용하여 보안 접속을 설정한다.
i. SET가 유효한
Figure pct00072
를 갖지 않는 경우에, SET는
Figure pct00073
파라미터를 제 1 ULP 메시지에서 SLP에 송신한다.
1. SLP가 모드 A SUPL INIT 보호를 지원하는 경우에, SLP는
Figure pct00074
,
Figure pct00075
,
Figure pct00076
및
Figure pct00077
파라미터들을 제 1 ULP 응답에서 SET에 송신함으로써 응답한다. SET가 이들 파라미터들을 수신할 때, 이는 모드 A SUPL INIT 보호가 적용하는 것을 SET에 표시한다.
주석:
Figure pct00078
를 업데이팅하기 위한 정책은 SLP 운영자의 결정이다.
2. SLP가 모드 A SUPL INIT 보호를 지원하지 않으면(또는 이러한 특정 시간에 모드 A SUPL INIT 보호를 지원하지 않으면), SLP는 널 SUPL INIT 보호가 적용되는 표시를 SET에(ULP 메시지에서) 송신한다.
ii. SET가 유효한
Figure pct00079
를 갖지만 유효한
Figure pct00080
를 갖지 않거나 리플레이 보호에 관한 동기화를 소실한 경우에, SET는 제 1 ULP 메시지에서 SLP에
Figure pct00081
파라미터를 송신한다.
1. SLP가 모드 A SUPL INIT 보호를 지원하는 경우에, SLP는 섹션 6.3.6.1.1에 특정된 절차를 이용하여 새로운
Figure pct00082
로 (SET에 대한 제 1 응답에서) 응답한다. SET가 이러한 응답을 수신할 때, 이것은 모드 A SUPL INIT 보호가 적용되는 것을 SET에 표시한다.
2. SLP가 모드 A SUPL INIT 보호를 지원하지 않으면(또는 이러한 특정 시간에서 모드 A SUPL INIT 보호를 지원하지 않으면), SLP는 널 SUPL INIT 보호가 적용되는 표시를 (ULP 메시지에서) SET에 송신한다.
이것은 SET가 H-SLP에 대한 새로운 TLS 접속을 셋업할 때마다 보호 레벨이 재협상되는 것을 의미하는 것을 주목한다.
6.3.3.2 H- SLP 관점으로부터의 협상
SET와의 가장 최신의 IP 세션이 GBA 또는 SEK 방법을 이용하여 인증되고, H-SLP가 SET에 대한 관련된 키 및 현재의 B-TID를 갖는 경우에,
Figure pct00083
B-TID가 GBA를 이용하여 획득된 키에 대한 것이면, H-SLP는 가장 최신의 B-TID에 대응하는
Figure pct00084
이도록
Figure pct00085
를 할당하며 다음과 같이 발생된다
Figure pct00086
FQDN은
Figure pct00087
일 수 있다
Figure pct00088
Figure pct00089
보호를 위해 이용될 수 있는 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리에 정의된다.
Figure pct00090
B-TID가 SEK-방법을 이용하여 도출된 키를 위한 것인 경우에,
Figure pct00091
는 6.1.2.1.2에 정의된 바와 같은 SEK이다.
Figure pct00092
어떠한 다른 SUPL INIT 보호도 협상되지 않은 것으로 가정하면, H-SLP는 그 SET에 대한 모드 B SUPL INIT 보호 레벨을 할당한다.
그렇지 않으면, H-SLP가 SET에 대한 관련된 키 및 유효한
Figure pct00093
를 갖는 경우에, H-SLP는 그 SET에 대한 모드 A SUPL INIT 보호 레벨을 할당한다.
보호의 어떠한 다른 레벨도 할당되지 않으면, H-SLP는 그 SET에 대한 널 SUPL INIT 보호 레벨을 할당한다.
H-SLP는 SUPL INIT 보호의 현재 할당된 레벨에 대응하는 (전달 이전에 SUPL INIT 메시지들을 프로세싱하기 위한) 절차들을 적용한다. 이는 SUPL INIT 메시지들에서 보호 레벨 파라미터에 대한 적절한 값을 할당하는 것을 포함한다.
6.3.3.3 SET 관점으로부터의 협상
H-SLP와의 가장 최신의 IP 세션이 GBA 또는 SEK 방법을 이용하여 인증되고, SET가 IP 세션에 대해 이용되는 관련된 키 및 현재의 B-TID를 갖는 경우에,
Figure pct00094
B-TID가 GBA를 이용하여 획득된 키에 대한 것이면, SET는 가장 최신의 B-TID에 대응하는
Figure pct00095
이도록
Figure pct00096
를 할당하며 다음과 같이 발생된다
Figure pct00097
FQDN은
Figure pct00098
일 수 있다
Figure pct00099
Figure pct00100
보호를 위해 이용될 수 있는 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리에 정의된다.
Figure pct00101
B-TID가 SEK-방법을 이용하여 도출된 키를 위한 것인 경우에,
Figure pct00102
는 6.1.2.1.2에 정의된 바와 같은 SEK이다.
Figure pct00103
어떠한 다른 SUPL INIT 보호도 협상되지 않은 것으로 가정하면, SET는 모드 B SUPL INIT 보호 레벨을 할당한다.
그렇지 않으면, SET가 H-SLP에 대해 유효한
Figure pct00104
, 관련된 키 및
Figure pct00105
를 갖는 경우에, H-SLP는 그 SET에 대한 모드 A SUPL INIT 보호 레벨을 할당한다.
보호의 어떠한 다른 레벨도 할당되지 않으면, SET는 널 SUPL INIT 보호 레벨을 할당한다.
SET는 SUPL INIT 보호의 현재 할당된 레벨에 대응하는 (수신된 SUPL INIT 메시지들을 프로세싱하기 위한) 절차들을 적용한다.
6.3.3.4 예외 절차들
SET는 SET-내부 SUPL INIT 보호 파라미터들이 손상된 것으로 결정하는 경우에, SET는 H-SLP와 TLS 세션을 설정해야 한다:
Figure pct00106
GBA 인증이 이용되는 경우에, SET는 새로운 키들을 설정하기 위해 GBA 부트스트랩핑을 개시해야 한다;
Figure pct00107
SEK 방법을 이용하는 SET들에 대해, SET는 새로운 키들을 인에이블하기 위해 SEK 부트스트랩핑을 개시해야 한다.
Figure pct00108
그렇지 않으면, SET는 제 1 보안된 ULP 메시지에서
Figure pct00109
를 송신하며 섹션 6.3.3.1의 단계 3.b에서의 절차들을 따른다.
SLP가 보안 컨텍스트를 손실하는 경우에(예를 들어, 데이터의 다량의 손실), SLP는 위치설정 활동들을 개시할 수단을 갖지 못할 것이다.
Figure pct00110
또는 SEK가 만료할 때, 또는 SET가 SLP에 접속할 때 컨텍스트가 재설정될 것이다. 이러한 "블록 아웃 윈도(block out window)"를 방지하기 위해 SLP는 모든 SUPL INIT 보안 컨텍스트 정보가 그와 같은 시나리오로부터 복구하기 위해 충분한 리던던시로 저장되는 것을 보증해야 한다.
6.3.4 보호의 널 레벨이 할당될 때의 사양들
주석: 널 SUPL INIT 보호에 대한 SUPL INIT 보호자가 존재하지 않는다.
6.3.4.1 H- SLP 절차들
널 SUPL INIT 보호에 특정되는 SLP에 대한 보안 절차들이 존재하지 않는다.
6.3.4.2 SET 절차들
널 SUPL INIT 보호가 할당되며 SET가 SUPL INIT 메시지를 수신할 때, SET는 다음의 절차를 적용한다:
Figure pct00111
보호 레벨 파라미터가 올바를 경우에, SET는 메시지를 진짜로 생각하며, 어떠한 보안 관련된 프로세싱도 요구되지 않을 수 있다.
Figure pct00112
SLP 및 SET는 상위의 보호 레벨을 지원할 수 있지만, 파워업 된 이후에 SET가 아직 SLP와 접촉하지 못했을 수 있음을 가정한다: 이 경우에 SET는 널 SUPL INIT 보호를 할당받을 것이다. SET가 SLP를 접촉할 때까지 시간의 주기에서, SET는 (올바른 보호 레벨 파라미터를 갖는) 임의의 수신된 SUPL INIT 메시지를 진짜인 것으로 생각할 것이다. SET가 (수신된 SUPL INIT 메시지에 응답할 수 있거나 응답하지 못할 수 있는) SLP를 먼저 접촉할 때, SET 및 SLP는 상위의 보호 레벨로 천이할 것이다. 일단 2개의 엔티티들이 상위의 보호 레벨로 천이하면, SET는 진짜가 아닌 SUPL INIT 메시지들을 검출할 수 있다. SET가 파워 업 될 때와 SET가 먼저 SLP를 접촉할 때의 사이에서, SUPL INIT 메시지가 진짜인 것처럼 SET에 의해 프로세싱되는 진짜가 아닌 SUPL INIT 메시지를 SET가 수신할 수 있을 때의 시간 주기가 존재한다. SET는 진짜가 아닌 SUPL INIT 메시지와 관련된 SUPL 세션을 진행하도록 결정하는 경우에, SET는 SLP를 접촉할 것이며 보안의 TLS 세션을 설정할 것이다. SLP는 진짜가 아닌 SUPL INIT 메시지를 이용하여 설정된 이후에 SUPL 세션을 허용하지 않을 것이다. SET 및 SLP가 상위의 보호 레벨을 지원하는 경우에, 이는 동시에 설정될 것이며 SET는 이 시간 이후의 진짜가 아닌 SUPL 메시지들을 검출할 수 있을 것이다. 이것은 SET 및 SLP가 상위의 보호 레벨을 지원할 수 있는 경우에, SET가 진짜가 아닌 SUPL INIT 메시지를 수용하게 되는 공격자에 대한 기회의 매우 작은 윈도가 존재하며, SET는 기껏해야 하나의 진짜가 아닌 SUPL INIT 메시지에 대한 SUPL 세션을 진행하려 시도할 뿐일 것이다.
Figure pct00113
보호 레벨 파라미터가 올바르지 않으면(즉, 보호 레벨 파라미터가 널과 다른 임의의 것인 경우에), SET는 적절한 에러 메시지를 SLP에 송신한다.
Figure pct00114
SLP 및 SET에서의 보호 레벨들이 동기화를 소실하는 경우에, 이러한 절차는 SET 및 SLP가 공통 보호 레벨 상에 재동기화하도록 허용한다.
6.3.5 모드 A SUPL INIT 보호 레벨에 대한 사양들
6.3.5.1 모드 A SUPL INIT 보호를 위한 키 식별자들
모드 A SUPL INIT 보호는 SUPL INIT 메시지들로 송신될 수 있는 2개의 키 식별자들을 이용한다:
Figure pct00115
및
Figure pct00116
.
Figure pct00117
Figure pct00118
는 글로벌하게-고유한, 와 관련된 장기(long-term) 키 식별자이다. SLP는 SLP가
Figure pct00120
에 대한 새로운 값을 제공할 때에만 SET에 새로운
Figure pct00121
를 제공한다.
Figure pct00122
Figure pct00123
는
Figure pct00124
와 관련된 단기(short-term) 아이덴티티(익명)이다.
Figure pct00125
는
Figure pct00126
가 유효한 기간에서 글로벌하게 고유할 수 있다. SET 및 SLP는 섹션들 6.3.5.3 및 6.3.5.4에 설명된 바와 같은
Figure pct00127
의 값을 동기화한다.
SLP는 전형적으로 기본 SUPL INIT 보호자에서의
Figure pct00128
로서
Figure pct00129
를 이용할 것이다. SET는 그 후에 기본 SUPL INIT 보호자를 검증하기 위해
Figure pct00130
가 이용되어야 하는지를 결정하도록
Figure pct00131
를 이용한다.
Figure pct00132
는 관찰자가 공통 SET 사용자들과 관련되는 다수의 SUPL INIT 메시지들을 관련시키도록 허용하기 때문에 전형적으로 SUPL INIT 메시지에서 송신되지 않는다.
Figure pct00133
의 목적은 위협 에이전트가 다수의
Figure pct00134
메시지들을 SET 사용자와 관련시키기 위해
Figure pct00135
를 이용하는 것을 방지하는 것이다. SLP 및 SET만이
Figure pct00136
를
Figure pct00137
와 관련시킬 수 있어야 한다.
Figure pct00138
를 변경하는 빈도는 주로 SET 사용자가 결정한다. SLP는 SLP 정책에 기초하여
Figure pct00139
에 대한 새로운 값을 설정하도록 선택할 수 있다.
그러나, SLP가 기본 SUPL INIT 보호자에서의
Figure pct00140
로서 더 장기의
Figure pct00141
를 이용하기를 원할 수 있는 환경들이 존재한다. 예를 들어, SET는 기본 SUPL INIT 보호자에서의
Figure pct00142
를 이용하여 다수의 SUPL INIT 메시지들에 응답하지 않는 것으로 가정한다. SLP는 SET가
Figure pct00143
에 관한 동기화를 소실할 것을 염려할 수 있다. SET 및 SLP는 장기
Figure pct00144
에 동기화된 채로 남아있는 경향이 있다. 그러므로, SLP는 동기화의 결여가 SET로 하여금 SUPL INIT 메시지를 검증하는 것을 방해하지 않음을 보증하기 위해 기본 SUPL INIT 보호자에서
Figure pct00145
를 이용하여 SUPL INIT 메시지를 송신할 수 있다.
6.3.5.2 모드 A SUPL INIT 보호 및 기본 SUPL INIT 보호자
모드 A SUPL INIT 보호는 기본 SUPL INIT 보호자 및 다음의 추가적인 설명들을 갖는 섹션 6.3.7에 정의된 바와 같은 관련된 절차들을 이용한다:
Figure pct00146
Figure pct00147
:
Figure pct00148
또는
Figure pct00149
가 이용되는 것을 표시한다.
Figure pct00150
Figure pct00151
:
Figure pct00152
에 합당한
Figure pct00153
또는
Figure pct00154
에 대응한다.
Figure pct00155
Figure pct00156
은
Figure pct00157
Figure pct00158
을 이용하여, 상기의
Figure pct00159
와 관련된
Figure pct00160
를 이용하여 계산된다.
6.3.5.3 H- SLP 절차들
단지 모드-A-특정 H-SLP 절차들만이 SET와 SLP 사이의 동기화를 유지하는데 관련한다.
Figure pct00161
에 대한 새로운 값은
Figure pct00162
파라미터 다음에 새로운
Figure pct00163
를 (보안된 ULP 세션에서 SET로의 제 1 응답 메시지에서) 송신하는 SLP에 의해 설정된다. 새로운
Figure pct00164
를 설정하는 것은
Figure pct00165
를 0x0000으로 리셋하는 것을 발생시키며, SET는 "플레이된" SUPL INIT 메시지들에 관한 모든 정보를 제거한다.
SLP는
Figure pct00166
또는 (범위 밖의) SLP의 내부 결정에 응답하여 새로운
Figure pct00167
를 설정할 수 있다. 즉, SLP는 심지어 SET로부터 대응하는
Figure pct00168
가 존재하지 않을 때에도 를 송신할 수 있다.
6.3.5.4 SET 절차들
단지 모드-A-특정 SET 절차들만이 SET와 SLP 사이의 동기화를 유지하는데 관련한다.
SET는 ULP 세션의 제 1 메시지에서
Figure pct00170
를 송신함으로써
Figure pct00171
에 대한 새로운 값을 설정하는 것을 트리거할 수 있다.
모드 A SUPL INIT 보호가 SET에 의해 할당되는 경우에, SET가 정해진
Figure pct00172
로 SUPL INIT 메시지를 프로세싱하는 처음 이전에, SET는
Figure pct00173
에 대해 이용된 값들의 캐시를 클리어한다.
6.3.6 모드 B SUPL INIT 보호 레벨에 대한 사양들
모드 B SUPL INIT 보호는 기본 SUPL INIT 보호자 및 다음의 추가적인 설명들을 갖는 섹션 0에 정의된 바와 같은 관련된 절차들을 이용한다:
Figure pct00174
Figure pct00175
: 단지 B-TID 식별자들만이 모드 B SUPL INIT 보호를 위해 지원된다.
Figure pct00176
Figure pct00177
: 현재의 B-TID에 대응한다.
Figure pct00178
Figure pct00179
파라미터는
Figure pct00180
Figure pct00181
을 이용하여 계산되며, 여기서
Figure pct00182
GBA-기반 배치들에 대해
Figure pct00183
는 가장 최신의 B-TID에 대응하는
Figure pct00184
이며 OMNA 레지스트리에 정의된 바와 같은 SUPL INIT 보호를 위한 GBA Ua 보안 프로토콜 식별자를 이용하여 발생된다.
Figure pct00185
SEK-기반 배치들에 대해
Figure pct00186
는 섹션 6.1.2.1.2에 정의된 바와 같은
Figure pct00187
이다.
6.3.6.1 H- SLP 절차들
단지 모드-B-특정 H-SLP 절차들만이 SET와 SLP 사이의 동기화를 유지하는 것에 관련한다.
모드 B SUPL INIT 보호를 위해, SLP에서의
Figure pct00188
는 키가 사용되는 처음에 제로로 리셋되며 SET는 "플레이된" SUPL INIT 메시지들에 관한 모든 정보를 제거한다.
SLP는 재동기화가 요구될 수 있는 것으로 결정하는 경우에는:
Figure pct00189
GBA 방법을 지원하는 배치들의 경우에, SLP는 GBA B-TID를 무효화함으로써 재동기화를 트리거한다. SET가 다음에 SLP에 인증하려 시도할 때, SLP는 TLS-PSK 경보
Figure pct00190
로 응답할 것이다. 이것은 새로운 GBA 키를 설정하는 것을 프롬프팅한다.
Figure pct00191
SEK 방법을 지원하는 배치들의 경우에서, SLP는 SEK B-TID를 무효화함으로써 재동기화를 트리거한다. SET가 다음에 SLP에 인증하려 시도할 때, SLP는 TLS-PSK 경보
Figure pct00192
로 응답할 것이다. 이것은 섹션 6.1.3.3에 설명된 바와 같은 새로운 SEK를 설정하는 것을 프롬프팅한다.
6.3.6.2 SET 절차들
단지 모드-B-특정 SET 절차들만이 SET와 SLP 사이의 동기화를 유지하는데 관련한다.
모드 B SUPL INIT 보호가 SET에 의해 할당되는 경우에,
Figure pct00193
SET가 정해진
Figure pct00194
로 SUPL INIT 메시지를 프로세싱하는 처음 이전에, SET는
Figure pct00195
에 대해 이용된 값들의 캐시를 클리어한다.
Figure pct00196
SET는 새로운 GBA Ks 또는 새로운 SEK를 적절하게 설정함으로써 재동기화를 트리거할 수 있다. SLP는 SET와 SLP 사이의 다음의 성공적인 인증까지 구 GBA Ks(또는 SEK)를 계속해서 이용할 것이며, 따라서 SET는 그때까지 구 GBA Ks(또는 SEK)를 유지해야 한다.
6.3.7 기본 SUPL INIT 보호자를 이용하기 위한 사양들
모드 A 및 모드 B SUPL INIT 보호 둘 다에 대해 기본 SUPL INIT 보호자가 이용되며 다음의 파라미터들을 포함한다:
Figure pct00197
Figure pct00198
: 길이 = 1 옥텟.
Figure pct00199
Figure pct00200
: 가변 길이.
Figure pct00201
을 계산하기 위해 이용된 키에 대응한다.
Figure pct00202
Figure pct00203
: 길이 = 2 옥텟들.
Figure pct00204
Figure pct00205
: 길이 = 4 옥텟들.
Figure pct00206
파라미터는 다음과 같이 발생된다:
Figure pct00207
Figure pct00208
여기서
Figure pct00209
Figure pct00210
는 모드 A 및 모드 B SUPL INIT 보호를 위해 섹션들 6.3.5 및 6.3.6 각각에 따라 도출된다.
Figure pct00211
Figure pct00212
은 SUPL INIT 메시지에 대응하며,
Figure pct00213
을 제외한 모든 파라미터들이 할당되며, MAC 파라미터는 모두 제로들로 설정하며,
Figure pct00214
Figure pct00215
및
Figure pct00216
은 본 문서 범위 밖의 문서(들)에 특정된다.
6.3.7.1 H- SLP 절차들
Figure pct00217
의 동기화를 위한 SLP 절차들은 다른 곳에서의 모드 A 및 모드 B SUPL INIT 보호를 위해 특정된다.
모드 A 또는 모드 B SUPL INIT 보호가 SET에 할당되는 경우에, H-SLP는 SUPL INIT 메시지들을 다음과 같이 구성한다:
1. SUPL INIT 보호자 밖의 파라미터들은 다른 곳에 설명된 바와 같이 할당된다.
2.
Figure pct00218
은 SLP가 이 메시지에 대해 이용할
Figure pct00219
의 타입에 따라 설정된다.
3.
Figure pct00220
는
Figure pct00221
와 관련된
Figure pct00222
로 설정된다.
4. H-SLP는 (이 SET 및 협상된 SUPL INIT 보호 레벨과 관련된)
Figure pct00223
의 현재 값을 1만큼 증가시키며, 새로운 값을
Figure pct00224
파라미터에 삽입한다.
5. 마지막으로, 모든 다른 파라미터들이 할당된 후에
Figure pct00225
이 상기에 특정된 바와 같은 SUPL INIT 및
Figure pct00226
로부터 계산된다.
H-SLP는 모드 A 또는 모드 B SUPL INIT 보호 레벨이 할당되는 각 SET에 대한
Figure pct00227
파라미터의 길이와 동일한 길이의
Figure pct00228
을 저장하도록 요구될 수 있다.
SLP에서의
Figure pct00229
이 (거의 가능성이 없는)
Figure pct00230
에 근접하는 경우에, SLP는 재동기화 절차들을 트리거해야 한다(섹션들 6.3.6.1 및 6.3.7.1을 참조).
6.3.7.2 SET 절차들
Figure pct00231
의 동기화를 위한 SET 절차들이 다른 곳에서 모드 A 및 모드 B SUPL INIT 보호를 위해 특정된다.
모드 A 또는 모드 B SUPL INIT 보호가 할당되는 경우에, SET는 수신된 SUPL INIT 메시지를 다음과 같이 프로세싱한다:
1. SET는 다음의 파라미터들이 적절한 검증을 실패하는 경우에 SUPL INIT 메시지를 폐기한다:
Figure pct00232
보호 레벨: 협상된 SUPL INIT 보호 레벨에 대한 할당된 값이어야 한다.
Figure pct00233
Figure pct00234
: 할당된 SUPL INIT 보호 레벨에 대해 유효해야 한다.
Figure pct00235
Figure pct00236
: 협상된 SUPL INIT 보호 레벨에 대한 현재의
Figure pct00237
에 대응해야 한다.
Figure pct00238
Figure pct00239
: SET는 메시지들의 리플레이를 검출하기 위해 이 값을 이용한다. 기술은 구현 특정될 수 있지만 SUPL INIT 메시지들이 소실되거나 순서를 벗어나 전달되는 상황들을 처리하는데 충분히 견고해야 한다.
Figure pct00240
Figure pct00241
: SET는 SUPL INIT 및
Figure pct00242
(상술한 바와 같음)로부터 예상된
Figure pct00243
을 계산하며 이를 수신된
Figure pct00244
과 비교한다: 그 값들은 동일해야 한다.
2. SUPL INIT가 이전의 단계에서 폐기되지 않은 경우에, 진짜인 것으로 고려되며, SET는
Figure pct00245
이 이용되는 것으로 고려한다.
Figure pct00246
이 (거의 가능성이 없는)
Figure pct00247
에 근접하는 경우에, SET는 카운터를 리셋하기 위해 SLP와 새로운
Figure pct00248
를 설정해야 한다.
6.4 H- SLP 어드레스를 SET 에 제공
주석: 액세스-네트워크 무관 H-SLP에 대한 H-SLP 어드레스를 제공하는 것은 FFS이다.
H-SLP 어드레스는 UICC, SET에서의 H-SLP 어드레스의 공급에 의해 SET에 이용가능하게 되거나 디폴트 H-SLP 어드레스가 이하에 설명된 바와 같이 도출된다. 이러한 어드레스는 FQDN의 형태로 되어야 하며 SET의 홈 네트워크에 의해 보안적으로 제공되어야 한다.
6.4.1 3 GPP2 SET 들
3GPP2 SET들에 대해 H-SLP 어드레스는 UIM 또는 R-UIM에 보안적으로 제공되어야 한다.
6.4.2 3 GPP SET 들
3GPP SET는 WAP PROVCONT에 특정된 바와 같은
Figure pct00249
문자 아래의 파라미터
Figure pct00250
로서 (FQDN 형태로) H-SLP 어드레스를 판독해야 한다. 추가로, H-SLP 어드레스는 3GPP 준수 UICC(USIM/SIM) 상의 OMA 스마트카드 제공 사양에서 또는 SET의 동등하게 보안된 영역에서 보안적으로 저장되어야 한다. SET는 H-SLP 어드레스를 판독하기 위해 OMA 스마트카드 제공 메커니즘들을 지원해야 한다. H-SLP 어드레스를 저장하는 SET 또는 USIM/SIM 애플리케이션에서의 부츠트랩 파일은 사용자 변경가능하지 않아야 한다. H-SLP 어드레스가 UICC(USIM/SIM)에서 구성되는 경우에, SET는 UICC에 제공된 H-SLP 어드레스를 먼저 판독해야 한다. UICC에 공급된 H-SLP 어드레스가 존재하지 않는 경우에, SET는 SET 상의 보안 영역으로부터 H-SLP 어드레스를 판독할 수 있다.
SET 에서의 H- SLP 어드레스의 제공: H-SLP 어드레스가 SET 상의 보안 위치에 저장되는 경우에, H-SLP 어드레스는 OMA 디바이스 관리 V1.2 또는 그 이후의 것을 이용하여 제공되어야 한다. H-SLP 어드레스가 OMA DM을 이용하여 제공되는 경우에, SET는 TLS 핸드쉐이크 동안 DM 서버에 의해 제시되는 서버측 인증서에 기초하여 OMA DM 서버를 인증해야 한다. SET가 H-SLP 어드레스의 저장을 지원하는 경우에, 섹션 6.1.4에 설명된 인증 방식, 즉 MSISDN/IP-어드레스 맵핑 인증에 기초한 대안적인 클라이언트 인증에 의존하지 않아야 하는데, 즉 SET는 섹션 6.1.1에 설명된 바와 같은 PSK-TLS 상호 인증 방법에 의존해야 한다.
H- SLP 어드레스의 자동 구성: H-SLP 어드레스가 UICC(USIM/SIM)의 보안 저장 영역, 또는 SET 상의 보안 영역에서 발견될 수 없는 경우에, SET는 USIM/SIM에 저장된 IMSI에 기초하여 SET에서의 디폴트 H-SLP 어드레스를 구성해야 한다.
H-SLP 어드레스가 UICC(USIM/SIM)의 보안 저장 영역, 또는 SET 상의 보안 영역에 발견되었지만 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가 이용되는지 여부에 따라, IMSI의 첫 번째 5개 또는 6개의 디지트들을 취하며 이들을 MCC 및 MNC로 분리한다; MNC가 2개의 디지트들인 경우에 시작에서 제로가 추가될 수 있다;
단계 2)
Figure pct00251
도메인 네임을 생성하기 위해 단계 1에서 도출된 MCC 및 MNC를 이용한다; 도메인 네임의 시작에 라벨
Figure pct00252
를 추가한다.
예 1: 사용중인 IMSI가
Figure pct00253
인 경우에, 여기서
Figure pct00254
및
Figure pct00255
이며, H-SLP 어드레스는
Figure pct00256
Figure pct00257
일 것이다.
새로운 IMSI가 파워 온 동안 또는 파워 온 후에 SET에 의해 검출되는 경우에, 모든 이전의 H-SLP 설정들은 SET로부터 제거되어야 한다. 더 구체적으로, SET에 저장된 임의의 H-SLP 어드레스가 제거되어야 한다.
IMSI가 변경되는 경우들에서 SET는 먼저 UICC(USIM/SIM)로부터 H-SLP 어드레스를 판독해야 한다. UICC(USIM/SIM) 상에 H-SLP 어드레스가 저장되지 않는 경우에, SET는 H-SLP 어드레스가 SET에 저장되는지 여부를 검사할 수 있다. UICC 또는 SET에서 어떠한 H-SLP 어드레스도 발견되지 않으면, 디폴트 H-SLP 어드레스는 상술한 바와 같은 새로운 IMSI에 기초하여 SET에 의해 구성되어야 한다.
구현들은 H-SLP의 어드레스가 SET의 제조자 소프트웨어 설치 후에 SET에 다운로딩되는 애플리케이션들을 통해 변경될 수 없음을 보증해야 한다.
다음의 흐름은 H-SLP 어드레스 저장을 도시한다.
1. 시작. 2로 가시오.
2. IMSI 변경됨? 예라면 3으로 가시오. 아니오라면 3을 스킵하고 직접 4로 가시오.
3. SET로부터 H-SLP를 클리어함. 4로 가시오.
4. UICC는 H-SLP 어드레스를 포함하는가? 아니오라면 5로 가시오. 예라면 9로 가시오.
5. SET 상에 H-SLP 어드레스가 지원되는가? 아니오라면 7로 가시오. 예라면 6으로 가시오.
6. H-SLP 어드레스가 SET에 공급되었는가? 아니오라면 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. H-SLP 어드레스가 IMSI로부터 생성되었는가? 아니오라면 7로 가시오. 예라면 13으로 가시오.
13. SUPL 세션을 중단하고 종료함.
14. SUPL 세션을 실행하고 종료함.
6.4.3 WIMAX 기반된 배치들
SET가 WiMAX 네트워크에 부착될 때 SET는 OMA DM을 통해 업데이트된 H-SLP 어드레스를 수신할 수 있다. H-SLP 어드레스가 보안 방식으로 WiMAX 단말에 제공될 때 H-SLP 어드레스는 보호된 환경에 저장되어야 한다.
6.5 기밀성 및 데이터 무결성 프로토콜들
TLS 1.1 또는 PSK-TLS는 SET와 SLP 사이의 기밀성 및 데이터 무결성을 제공하기 위해 이용될 수 있다. "SUPL INIT"를 제외한 모든 SUPL 메시지들은 SET와 SLP 사이의 TLS 또는 PSK-TLS 세션 내에 전달되어야 한다.
섹션 6.1.1.3은 SUPL 3.0 배치에서의 엔티티들이 의무적으로 또는 임의선택적으로 서버-인증서 인증을 갖는 TLS 및/또는 TLS-PSK를 갖는지를 결정하기 위한 상세들을 제공한다.
6.5.1 서버-인증서들을 갖는 TLS
서버-인증서들을 갖는 TLS 1.1의 구현들은 다음의 설명들을 갖는 TLS 1.1의 WAP 프로파일에 따를 수 있다:
SET들은 다음을 구현할 수 있다:
Figure pct00258
추가적인 암호 스위트들을 선호하는 SET 구현들에 대해 SET들은 다음을 구현해야 한다:
Figure pct00259
서버-인증서들을 갖는 TLS 1.1을 지원하는 SLP들은 다음의 암호세트들을 구현할 수 있다:
Figure pct00260
널 암호화를 지원하는 것을 선호하는 서버-인증서들을 갖는 TLS 1.1을 지원하는 SLP 구현들에 대해, SLP들은
Figure pct00261
를 구현할 수 있다.
Figure pct00262
는 어떠한 기밀성 보호도 제공하지 않기 때문에
Figure pct00263
의 이용이 권장되지 않음을 주목한다. 그러나,
Figure pct00264
는 여전히 인증 및 무결성 보호를 제공한다.
TLS 1.1의 WAP 인증서 프로파일은 서버-인증서들을 갖는 TLS 1.1 및 SET들을 지원하는 SLP들에 의해 지원될 수 있다.
6.5.2 TLS - PSK
TLS-PSK 구현들은 TLS 1.1에 대해 정의된 바와 같은 벌크 암호화로, TLS 핸드쉐이크에 대한 PSK-TLS에 따를 수 있다.
TLS-PSK를 지원하는 SET들은 다음을 구현할 수 있다:
Figure pct00265
추가적인 암호 스위트들을 선호하는 TLS-PSK를 지원하는 SET 구현들에 대해, SET들은 다음을 구현해야 한다:
Figure pct00266
다음의 암호 스위트들은 SLP들에 의해 구현될 수 있다:
Figure pct00267
추가적인 암호 스위트들을 선호하는 TLS-PSK를 지원하는 SLP 구현들에 대해, SLP는 다음을 구현해야 한다:
Figure pct00268
다음의 암호 스위트들은 비-프록시 모드를 지원하는 SPC들에 의해 구현될 수 있다:
Figure pct00269
추가적인 암호 스위트들을 선호하는 비-프록시 모드를 지원하는 SPC 구현들에 대해, SPC들은 다음을 구현해야 한다:
Figure pct00270
6.6 DCERT 방법 및 사용자 바인딩
DCert 방법은 SET 핸드셋을 인증하지만, (GBA, SKE 및 ACA 방법들과 달리) 액세스 네트워크 크리덴셜들에 관련된 어떠한 인증도 수행하지 않는다.
SLP가 상호 인증을 위한 DCert 방법을 이용하는 경우에, SLP 운영자는 어느 SUPL 사용자가 SET과 관련되어야 하는지를 검증하기 위해 일부 다른 메커니즘들을 필요로 한다. 용어 "사용자 바인딩"은 SET 아이덴티티와 SUPL 사용자를 관련시키는 것을 설명하도록 이용된다.
SET 소유권이 변화하는 경우에, 사용자 바인딩을 해제하기 위해 SLP 운영자를 접촉하는 것은 기존 SUPL 사용자의 담당이다.
하나의 가능한 절차가 섹션 6.6.1에 도시되더라도, SUPL 3.0은 사용자 바인딩 절차를 특정하지 않는다. 일부 SLP들은 사용자 바인딩 절차를 SLP 운영자에 의해 제공된 다른 서비스들의 일부로서 통합할 수 있다. 다른 경우들에서, 사용자 바인딩은 분배 체인의 일부일 수 있다.
SLP 운영자는 선택하는 임의의 "사용자 바인딩" 절차를 이용할 수 있지만, 다음의 포인트들이 명심되어야 한다:
Figure pct00271
SUPL 사용자는 사용자 바인딩 절차의 일부로서 인증되어야 한다.
Figure pct00272
SUPL 사용자를 인증하는 것에 대한 실패는 서비스의 도난을 허용할 것이며, 위협 에이전트가 식별된 SUPL 사용자의 위치에 관하여 SLP를 잘못 인도하게 허용할 것이다.
Figure pct00273
SLP 운영자는 사용자 인증에 대한 기존의 메커니즘들 및 정책들을 적용할 것을 권장한다.
Figure pct00274
SET는 사용자 바인딩 절차의 일부로서 인증되어야 한다.
Figure pct00275
이에 대한 이유들이 미묘하다. 위협 에이전트가 앨리스의 움직임들을 따라가기를 원하며 앨리스는 SET 아이덴티티
Figure pct00276
를 갖는 SET를 소유한다고 가정한다. 위협 에이전트는 적법한 SUPL 사용자로서 등록하며, 그 자신을 인증한 후에, SET 아이덴티티
Figure pct00277
를 갖는 SET를 소유할 것을 주장한다. SLP 운영자가 이 SET를 위협 에이전트의 계정에 관련시키는 경우에, 위협 에이전트는 (네트워크 개시된 세션들을 통해) SLP로부터의 주기적 위치 업데이트들을 획득하게 그 자신들을 인가시킬 수 있다. 그러나, 앨리스가 SET를 이용하기 때문에, 위협 에이전트는 실제로 앨리스의 위치 업데이트들을 획득한다. SLP 운영자는 앨리스의 위치 기밀을 유지할 것이 예상되기 때문에, 그와 같은 공격을 방지하는 것이 SLP 운영자의 관심분야이다.
6.6.1 예시적인 사용자 바인딩 절차
DCert 방법은 웹-브라우징 능력들을 갖는 SET들에 대해 주로 설계된다: 예들은 스마트-폰들, 태블릿들 또는 터치-스크린 멀티-미디어 플레이어들을 포함한다.
그와 같은 SET들은 다음의 메커니즘을 이용할 수 있다:
1. SLP 운영자는 SET를 이용하는 동안 SLP-소유된 웹 서버의 URL에 접속할 것을 SUPL 사용자에 프롬프팅한다.
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
SUPL 3.0은 모드 A 및 모드 B SUPL INIT 보호를 정의하였다. 모드 A 보호는 SLP가 보안된 ULP 세션 동안 SET에 공유된 키를 송신하는 능력을 가질 것을 요구한다. 본 실시예는 공유된 키 파라미터를 설명하며 공유된 키를 요청하고 송신하도록 이용되는 ULP 메시지(들)를 표시한다. 따라서, 본 실시예는 SUPL 3.0에 통합될 수 있으며, 섹션 번호들은 SUPL 3.0 섹션들을 지칭할 수 있다.
6.3.3 SUPL INIT / REINIT 메시지들의 엔드 -투- 엔드 보호
주석: SUPL INIT 메시지들의 엔드-투-엔드 보호는 비-긴급 SUPL INIT/REINIT 메시지들에만 적용한다.
섹션 6.3.3에서의 프로세스들은 D-SLP 및 H-SLP인 SLP에만 적용한다; 프로세스들은 E-SLP에 적용하지 않는다.
SUPL INIT 및 SUPL REINIT 메시지들의 엔드-투-엔드 보호를 위한 절차들은 SUPL INIT와 SUPL REINIT 메시지들 사이를 구별하지 않는다-SUPL INIT 및 SUPL REINIT 메시지들 둘 다는 동일한 타입의 메시지인 것처럼 프로세싱된다. 간략화를 위해, 그 절차들을 SUPL INIT 보호 절차들로서 지칭한다-SUPL INIT 및 SUPL REINIT 메시지들 둘 다는 SUPL INIT 보호 절차들로서 이용하여 프로세싱된다.
엔드-투-엔드 SUPL INIT 보호의 3가지 옵션들이 본 사양에서 제공된다: 널, 모드 A 및 모드 B-
Figure pct00278
널 SUPL INIT 보호는 엔드-투-엔드 무결성 보호, 엔드-투-엔드 리플레이 보호 및 기밀성 보호를 제공하지 않는다. 널 SUPL INIT 보호를 위한 절차들은 섹션 6.3.4에 설명된다.
Figure pct00279
모드 A SUPL INIT 보호는 디폴트 알고리즘들을 이용하여 엔드-투-엔드 무결성 보호 및 엔드-투-엔드 리플레이 보호를 제공한다. 모드 A SUPL INIT 보호는 보안된 ULP 세션 동안 SLP에 의해 SET에 송신된 공유된 키를 이용한다. 모드 A SUPL INIT 보호를 위한 절차들은 섹션 6.3.5에 설명된다.
Figure pct00280
모드 B SUPL INIT 보호는 디폴트 알고리즘들을 이용하여 엔드-투-엔드 무결성 보호 및 엔드-투-엔드 리플레이 보호를 제공한다. 모드 B SUPL INIT 보호는 적절한 PSK-기반 방법(GBA 또는 SEK 방법들)을 이용하여 도출된 공유된 키를 이용한다. 모드 B SUPL INIT 보호를 위한 절차들은 섹션 6.3.6에 설명된다.
보호 레벨에 대한 선호도의 순서는 다음과 같다:
Figure pct00281
널 SUPL INIT 보호는 최소의 선호도를 갖는다.
Figure pct00282
모드 A SUPL INIT 보호는 널 SUPL INIT 보호보다 높은 선호도를 갖는다.
Figure pct00283
모드 B SUPL INIT 보호는 모드 A SUPL INIT 보호보다 높은 선호도를 갖는다.
SUPL INIT 메시지에서 (다음의 표에서) 보호 레벨 파라미터는 현재 보호 레벨에 따라 할당된다.
주석: 본 사양은 장래의 개정들에 추가되도록 더 진보된 보호 레벨들을 허용하기 위해 기록되었다. 이러한 진보된 보호는 (예를 들어, 암호화를 허용하며 알고리즘들의 협상을 허용하는) SUPL INIT/REINIT를 보안하기 위한 다른 방식들의 협상을 허용할 수 있다. 보호 레벨 파라미터는 SUPL INIT/REINIT 메시지를 파싱할 수 있는지 아닌지를 결정하는데 있어서 SET를 돕기 위해 포함된다: 보호 레벨 파라미터는 확장성을 위해 요구된다.
SUPL INIT/REINIT 메시지는 보안 파라미터들을 포함하기 위해 존재하는 보호자 파라미터를 가질 수 있다: 보호자 파라미터의 존재는 다음의 표에 특정된다.
엔드-투-엔드 SUPL INIT 보호의 레벨
설명		 SUPL INIT/REINIT에 보호자 파라미터가
존재하는가?
널 엔드-투-엔드 보호 없음 임의선택적
모드 A 디폴트 알고리즘들을 이용한 무결성 보호 및 리플레이 보호 의무사항
모드 B 디폴트 알고리즘들을 이용한 무결성 보호 및 리플레이 보호 의무사항
SUPL INIT 및 SUPL REINIT 메시지들에서의 보호자 파라미터의 존재 및 SUPL INIT 보호 레벨 파라미터 값들
ACA-기반 방법을 지원하는 SET 또는 D-SLP 또는 H-SLP는 널 SUPL INIT 보호를 지원해야 한다.
모든 SET들은 모드 A SUPL INIT 보호 절차들을 지원해야 한다.
D-SLP 또는 H-SLP는 모드 A SUPL INIT 보호 절차들을 지원할 수 있다.
PSK-기반 방법을 지원하는 SET 또는 D-SLP 또는 H-SLP는 모드 B SUPL INIT 보호 절차들을 지원해야 한다.
E-SLP 엔티티는 현재 정의된 SUPL INIT 보호에 관련되지 않는다.
6.3.3.1 SUPL INIT 보호의 레벨을 협상
다음의 프로세스들은 D-SLP 및 H-SLP인 SLP에만 적용한다; 프로세스들은 E-SLP에 적용하지 않는다.
SUPL INIT 보호 레벨이 협상되는 방식의 약식 설명은 다음과 같다:
4. SET는 유효한
Figure pct00284
가 존재하지 않을 때(예를 들어, 파워-업 시에 또는
Figure pct00285
의 수명이 만료된 때) 널 SUPL INIT 보호를 적용해야 한다. 초기의 보호 레벨은 항상 널 SUPL INIT 보호이다. 이 상태에서 SET는 모든 SUPL INIT/REINIT 메시지들을 취급하는데, 즉 어떤 메시지들도 조용하게 드롭되지 않는다. SUPL INIT/REINIT 메시지가 실패 조건으로 파싱되면, SET는 에러 메시지를 SLP에 송신한다.
5. SET가 특정 SLP에 대해 모드 A 또는 모드 B SUPL INIT 보호를 이용하여 이미 협상된 유효한
Figure pct00286
및 유효한
Figure pct00287
를 갖는 경우에, SET는 협상된 모드(모드 A 또는 모드 B)를 이용하여 SLP로부터의 모든 SUPL INIT/REINIT 메시지들을 프로세싱한다.
6. SET가 SLP에 대한 상호-인증된 보안 접속을 설정할 때,
a. PSK-기반 방법(GBA 또는 SEK)이 상호 인증을 위해 이용된 경우에, 모드 B SUPL INIT 보호가 적용되며 PSK-TLS 핸드쉐이크에서 교환된 B-TID는 3GPP 및 3GPP2 배치들에서의
Figure pct00288
로서 이용될
Figure pct00289
를 도출하기 위해 이용될 수 있는 SEK 또는 (3GPP 및 3GPP2 배치들에서의
Figure pct00290
로서 이용될) Ks에 대응한다. 이러한
Figure pct00291
또는 SEK 및 관련된 B-TID는 다음 중 하나일 때까지 모드 B SUPL INIT 보호에 이용된다:
i. 키가 만료하며, 이 경우에 SET 및 SLP는 널 SUPL INIT 보호로 복귀한다.
ii. SET 및 SLP는 비-긴급 세션에서 ACA-방법을 이용하며, 이 경우에 SET 및 SLP는 아래의 단계 3b에 논의된 바와 같은 모드 A 또는 널 SUPL INIT 보호로 복귀하거나, 또는
iii. SET 및 H-SLP는 새로운 B-TID를 이용하여 TLS를 설정하기 위해 GBA의 또는 SEK의 부트스트랩핑 재협상 방법들을 이용하며, 이 경우에 B-TID 및 대응하는
Figure pct00292
또는 SEK는 이제 모드 B SUPL INIT 보호를 위해 이용된다.
b. 그렇지 않으면, SET 및 SLP는 DCert 또는 ACA 방법을 이용하여 보안 접속을 설정한다.
i. SET가 유효한
Figure pct00293
를 갖지 않는 경우에, 보안 세션 설정을 수반하는 SET 능력들 파라미터를 운반하는 다음의 ULP 메시지에서의 SET 능력들
Figure pct00294
에서 SLP에 이것을 표시한다.
1. s 모드 A SUPL INIT 보호, 그 후에 SLP는 다음의 SUPL 종료 메시지에서 모드 A
Figure pct00295
설정 절차(섹션 6.3.5.2)를 수행한다. 성공적인 모드 A
Figure pct00296
설정 절차는 모드 A SUPL INIT 보호가 적용되는 것을 SET에 표시한다. 성공적인 모드 A
Figure pct00297
설정 절차가 발생할 때까지, SET는 널 SUPL INIT 보호를 이용할 것이다.
주석:
Figure pct00298
를 업데이팅하기 위한 정책은 SLP 운영자의 결정이다.
2. SLP가 모드 A SUPL INIT 보호를 지원하지 않는 경우에(또는 이러한 특정 시간에 모드 A SUPL INIT 보호를 지원하지 않는 경우에), SLP는 SET가 널 SUPL INIT 보호를 이용할 것을 표시하는
Figure pct00299
,
Figure pct00300
,
Figure pct00301
및
Figure pct00302
파라미터들을 송신하지 않는다.
ii. SET가 유효한
Figure pct00303
를 갖지만, 유효한
Figure pct00304
를 갖지 않거나 리플레이 보호에 관한 동기화를 소실한 경우에, 보안 세션 설정을 수반하는 SET 능력들 파라미터를 운반하는 다음의 ULP 메시지에서의 SET 능력들
Figure pct00305
Figure pct00306
에서 SLP에 이것을 표시한다.
1. 다음의 SUPL 종료 메시지에서 모드 A 재동기화 절차(섹션 6.3.5.3)를 수행한다. 성공적인 모드 A 재동기화 절차는 모드 A SUPL INIT 보호가 적용되는 것을 SET에 표시한다. 성공적인 모드 A 재동기화 절차가 발생할 때까지, SET는 널 SUPL INIT 보호를 이용할 것이다.
2. SLP가 모드 A SUPL INIT 보호를 지원하지 않는 경우에(또는 이 특정 시간에 모드 A SUPL INIT 보호를 지원하기를 원하지 않는 경우), SLP는 SET가 널 SUPL INIT 보호를 이용하는 것을 표시하는 모드 A 재동기화(섹션 6.3.5.3)를 수행하지 않는다.
이것은 SET가 SLP에 대한 새로운 TLS 접속을 셋업할 때마다 보호 레벨이 재협상되는 것을 의미함을 주목한다.
6.3.3.2 SLP 관점으로부터의 협상
SET와의 가장 최신의 IP 세션이 GBA 또는 SEK 방법을 이용하여 인증되고, SLP는 현재 B-TID를 가지며 SET에 대한 관련된 키를 갖는 경우에,
Figure pct00307
B-TID가 GBA를 이용하여 획득된 키를 위한 것인 경우에, SLP는 가장 최신의 B-TID에 대응하는
Figure pct00308
이도록
Figure pct00309
를 할당하며 다음과 같이 발생된다.
Figure pct00310
FQDN은
Figure pct00311
일 것이다
Figure pct00312
Figure pct00313
보호를 위해 이용될 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리[OMNA]에 정의된다.
Figure pct00314
B-TID는 SEK-방법을 이용하여 도출된 키를 위한 것인 경우에,
Figure pct00315
는 6.1.2.1.2에 정의된 바와 같은 SEK이다.
Figure pct00316
어떠한 다른 SUPL INIT 보호도 협상되지 않은 것으로 가정하면, SLP는 그 SET에 대한 모드 B SUPL INIT 보호 레벨을 할당한다.
그렇지 않고, SLP가 SET에 대한 유효한
Figure pct00317
및 관련된 키를 갖는 경우에, SLP는 그 SET에 대한 모드 A SUPL INIT 보호 레벨을 할당한다.
보호의 어떠한 다른 레벨도 할당되지 않으면, SLP는 그 SET에 대한 널 SUPL INIT 보호 레벨을 할당한다.
SLP는 SUPL INIT/REINIT 보호의 현재 할당된 레벨에 대응하는 (전달 이전에 SUPL INIT/REINIT 메시지들을 프로세싱하기 위한) 절차들을 적용한다. 이는 SUPL INIT 메시지들에서 보호 레벨 파라미터에 대한 적절한 값을 할당하는 것을 포함한다.
6.3.3.3 SET 관점으로부터의 협상
SLP와의 가장 최신의 IP 세션이 GBA 또는 SEK 방법을 이용하여 인증되고, SET는 현재 B-TID를 가지며 IP 세션에 대해 이용된 관련 키를 갖는 경우에,
Figure pct00318
B-TID가 GBA를 이용하여 획득된 키를 위한 것인 경우에, SET는 가장 최신의 B-TID에 대응하는
Figure pct00319
이도록
Figure pct00320
를 할당하며 다음과 같이 발생된다.
Figure pct00321
FQDN은
Figure pct00322
일 것이다
Figure pct00323
Figure pct00324
보호를 위해 이용될 GBA Ua 보안 프로토콜 식별자 [3GPP 24.109]는 OMNA 레지스트리[OMNA]에 정의된다.
Figure pct00325
B-TID는 SEK-방법을 이용하여 도출된 키를 위한 것인 경우에,
Figure pct00326
는 6.1.2.1.2에 정의된 바와 같은 SEK이다.
Figure pct00327
어떠한 다른 SUPL INIT 보호도 협상되지 않은 것으로 가정하면, SET는 그 SLP에 대한 모드 A SUPL INIT 보호 레벨을 할당한다.
그렇지 않고, SET가 SLP에 대한 유효한
Figure pct00328
,
Figure pct00329
및 관련된
Figure pct00330
를 갖는 경우에, SET는 그 SLP에 대한 모드 A SUPL INIT 보호 레벨을 할당한다.
보호의 어떠한 다른 레벨도 할당되지 않으면, SET는 널 SUPL INIT 보호 레벨을 할당한다.
SET는 SUPL INIT/REINIT 보호의 현재 할당된 레벨에 대응하는 (수신된 SUPL INIT/REINIT 메시지들을 프로세싱하기 위한) 절차들을 적용한다.
6.3.3.4 예외 절차들
SET는 SET-내부 SUPL INIT 보호 파라미터들이 손상된 것으로 결정하면, SET는 SLP와 TLS 세션을 설정해야 한다:
Figure pct00331
GBA 인증이 이용되는 경우에, SET는 새로운 키들을 설정하기 위해 GBA 부트스트랩핑을 개시해야 한다.
Figure pct00332
SEK 방법을 이용하는 SET들에 대해, SET는 6.1.2.1.2에 정의된 바와 같이 새로운 키들을 인에이블하기 위해 SEK 부트스트랩핑을 개시해야 한다.
Figure pct00333
그렇지 않으면, SET는 섹션 6.3.3.1의 단계 3.b에서의 절차들을 따른다.
SLP가 보안 컨텍스트를 손실하는 경우에(예를 들어, 다량의 데이터 손실), SLP는 위치설정 활동들을 개시할 방도가 없을 것이다. 컨텍스트는
Figure pct00334
또는 SEK가 만료할 때, 또는 SET가 SLP에 접속할 때 재설정될 것이다. 이러한 "블록 아웃 윈도(block out window)"를 방지하기 위해, SLP는 모든 SUPL INIT 보호 보안 컨텍스트 정보가 그와 같은 시나리오로부터 복구하는데 충분한 리던던시로 저장되는 것을 보증해야 한다.
6.3.3.5 SET 에서의 SUPL INIT 메시지를 프로세싱하기 위한 일반 절차
수신된 SUPL INIT 메시지를 프로세싱하는 방법을 결정하기 위해 다음의 절차가 SET에 의해 적용된다.
1. SET는 송신 SLP(SUPL INIT 메시지를 송신한 SLP)를 식별한다.
a. D-SLP FQDN 파라미터가 SUPL INIT 메시지에 존재하는 경우에, SET는 이 파라미터를 이용하여 송신 SLP를 식별할 것이다.
i. SET는 식별된 D-SLP와 기존의 관계를 갖지 않는 경우에, SET는 조용히 SUPL INIT 메시지를 폐기할 것이며 현재 절차를 빠져나온다.
ii. 그렇지 않으면, SET는 단계 2로 진행한다.
b. D-SLP FQDN 파라미터가 SUPL INIT 메시지에 존재하지 않으면, SET는 송신 SLP를 SET의 H-SLP인 것으로 식별한다.
2. SET는 송신 SLP에 대해 할당된 SUPL INIT 보호 레벨에 기초하여 초기의 필터링을 수행한다:
a. 널 SUPL INIT 보호가 송신 SLP에 대해 할당되는 경우에, SET는 널 SUPL INIT 보호 절차들을 수행하며, 현재 절차를 빠져나온다.
b. 모드 A 또는 모드 B SUPL INIT 보호가 송신 SLP에 대해 할당되는 경우에,
i. SUPL INIT 메시지가 어떠한 보호자 파라미터도 포함하지 않는 경우에, SET는 조용히 SUPL INIT 메시지를 폐기하며 현재 절차를 빠져나온다.
ii. SUPL INIT 메시지가 보호자 파라미터를 포함하는 경우에, SET는 섹션 6.3.5 또는 섹션 6.3.6 각각에서 적절한 모드 A 또는 모드 B SUPL INIT 보호 절차들을 수행한다. SET는 송신 SLP와 관련된 SUPL INIT ROOT 키들 중 어느 것이 SUPL INIT 메시지를 프로세싱하기 위해 이용되는지를 식별하기 위해 보호자 파라미터에서
Figure pct00335
파라미터를 이용한다.
6.3.5 모드 A SUPL INIT 보호 레벨에 대한 사양들
6.3.5.1 모드 A SUPL INIT 보호를 위한 키 식별자들
모드 A SUPL INIT 보호는 SUPL INIT/REINIT 메시지들로 송신될 수 있는 2개의 키 식별자들을 이용한다:
Figure pct00336
및
Figure pct00337
Figure pct00338
Figure pct00339
는 글로벌하게-고유한,
Figure pct00340
와 관련된 장기 키 식별자이다. SLP가
Figure pct00341
에 대한 새로운 값을 제공할 때만 SLP는 새로운
Figure pct00342
를 SET에 제공한다.
Figure pct00343
Figure pct00344
는
Figure pct00345
와 관련된 단기 아이덴티티(익명)이다.
Figure pct00346
는
Figure pct00347
가 유효한 기간에서 글로벌하게 고유할 것이다. SET 및 SLP는 섹션들 6.3.5.5 및 6.3.5.6에 설명된 바와 같은
Figure pct00348
의 값을 동기화한다.
SLP는 전형적으로 기본 SUPL INIT 보호자에서
Figure pct00349
로서
Figure pct00350
를 이용할 것이다. SET는 그 후에 기본 SUPL INIT 보호자를 검증하기 위해
Figure pct00351
가 이용되어야 하는지를 결정하도록
Figure pct00352
를 이용한다.
Figure pct00353
는 관찰자가 공통 SET 사용자와 관련되는 다수의 SUPL INIT/REINIT 메시지들을 관련시키게 허용할 것이기 때문에,
Figure pct00354
는 전형적으로 SUPL INIT/REINIT 메시지에서 송신되지 않는다.
Figure pct00355
의 목적은 다수의 SUPL INIT/REINIT 메시지들을 SET 사용자와 관련시키기 위해 위협 에이전트가
Figure pct00356
를 이용하는 것을 방지하는 것이다. SLP 및 SET만이
Figure pct00357
를
Figure pct00358
와 관련시킬 수 있어야 한다.
Figure pct00359
를 변경하는 빈도는 주로 SET 사용자의 결정이다. SLP는 SLP 정책에 기초하여
Figure pct00360
에 대한 새로운 값을 설정하도록 선택할 수 있다.
그러나, SLP는 기본 SUPL INIT 보호자에서의
Figure pct00361
로서 더 장기의
Figure pct00362
를 이용하려 원할 수 있다. 예를 들어, SET는 기본 SUPL INIT 보호자에서의
Figure pct00363
를 이용하여 다수의 SUPL INIT/REINIT 메시지들에 응답하지 않은 것으로 가정한다. SLP는 SET가
Figure pct00364
에 관한 동기화를 소실한 것을 우려할 수 있다. SET 및 SLP는 장기의
Figure pct00365
상에 동기화된 채로 남아있는 경향이 있다. 그러므로, SLP는 동기화의 결여로 인해 SET가 SUPL INIT/REINIT 메시지를 검증하는 것을 방해하지 않음을 보증하도록 기본 SUPL INIT 보호자에서의
Figure pct00366
를 이용하여 SUPL INIT/REINIT 메시지를 송신할 수 있다.
6.3.5.2 모드 A
Figure pct00367
설정 절차
Figure pct00368
에 대한 값은 새로운
Figure pct00369
,
Figure pct00370
,
Figure pct00371
및
Figure pct00372
파라미터들을 (보안 SUPL 세션에서 SET로의 SUPL 종료 메시지에서) 송신하는 SLP에 의해 설정된다. 전달이 성공적이면, SLP 및 SET는 이러한 모드 A
Figure pct00373
설정 절차를 성공으로 고려한다.
Figure pct00374
파라미터는 키가 유효한 것이 중단될 때의 UTC 시간을 포함한다.
6.3.5.3 모드 A 재동기화 절차
SLP는 다음의 단계들을 이용하여 SET와
Figure pct00375
에 대한 새로운 값을 설정한다:
1. SLP는 현재
Figure pct00376
및 새로운
Figure pct00377
파라미터를 (보안 SUPL 세션에서 SET로의 SUPL 종료 메시지에서)SET에 송신한다. 전달이 성공적이면, SLP는 모드 A 재동기화 절차를 성공으로 고려한다.
2. SET는 SET가 현재 그 SLP에 대해 할당한 유효한
Figure pct00378
값들의
Figure pct00379
에 대해 수신된
Figure pct00380
를 비교한다.
a.
Figure pct00381
값들이 다르면, 이것은 SET 상에 할당된
Figure pct00382
의 값의 손상을 표시하며, 다음의 단계들이 수행된다:
i. SET는
Figure pct00383
를 폐기하며 이러한 모드 A 재동기화를 실패인 것으로 고려한다.
ii. SET는 섹션 6.3.3.4에서의 예외 절차들을 개시한다.
b. 수신된
Figure pct00384
가 유효한
Figure pct00385
와 동일한 경우에:
i. SET는 새로운
Figure pct00386
를 대응하는
Figure pct00387
와 관련시키고,
ii. SET는 이러한 모드 A 재동기화 절차를 성공으로 고려한다.
6.3.5.4 모드 A SUPL INIT 보호 및 기본 SUPL INIT 보호자
모드 A SUPL INIT 보호는 다음의 추가적인 설명들을 갖는 섹션 0에서 정의된 바와 같은 기본 SUPL INIT 보호자 및 관련된 절차들을 이용한다:
Figure pct00388
Figure pct00389
:
Figure pct00390
또는
Figure pct00391
가 이용되는지를 표시한다.
Figure pct00392
Figure pct00393
:
Figure pct00394
에 합당한
Figure pct00395
또는
Figure pct00396
에 대응한다.
Figure pct00397
Figure pct00398
은 상기의
Figure pct00399
와 관련된
Figure pct00400
를 이용하여,
Figure pct00401
Figure pct00402
를 이용하여 계산된다.
6.3.5.5 SLP 절차들
모드-A-특정 SLP 절차들만이 SUPL INIT ROOT KEY 설정,
Figure pct00403
의 만료 및 SET와 SLP 사이의 동기화 유지에 관련한다.
모드 A
Figure pct00404
설정 절차는 섹션 6.3.5.2에 특정된다. SLP는 (SET 능력들
Figure pct00405
에서) SET에 의한 동기 표시 밖의 또는 (범위 밖의) SLP의 내부 결정에 응답하여 모드 A
Figure pct00406
설정 절차를 수행할 수 있다. 즉, SLP는 SET에 의한 대응하는 표시가 없을 때조차 (관련된 파라미터들을 갖는)
Figure pct00407
를 송신할 수 있다.
Figure pct00408
및 관련된 파라미터들은 다음의 조기에 SLP에서 유효한 것을 중단할 것이다
Figure pct00409
관련된
Figure pct00410
의 수명, 및
Figure pct00411
이후의 성공적인 모드 A
Figure pct00412
설정의 시간(섹션 6.3.5.2)
모드 A 재동기화 절차는 섹션 6.3.5.3에 특정된다. SLP는 (SET 능력들
Figure pct00413
Figure pct00414
에서) SET에 의한 동기 표시 밖 또는 (범위 밖의) SLP의 내부 결정에 응답하여 모드 A 재동기화 절차를 수행할 수 있다. 즉, SLP는 SET에 의한 대응하는 표시가 존재하지 않을 때조차
Figure pct00415
를 송신할 수 있다.
성공적인 모드 A
Figure pct00416
설정 절차 또는 성공적인 모드 A 재동기화 절차에 후속하여, SLP는
Figure pct00417
를
Figure pct00418
으로 리셋한다.
6.3.5.6 SET 절차들
모드-A-특정 SET 절차들만이 SUPL INIT ROOT_KEY 설정,
Figure pct00419
의 만료 및 SET와 SLP 사이의 동기화 유지에 관련한다.
모드 A
Figure pct00420
설정 절차는 섹션 6.3.5.2에 특정된다. SET는 보안 세션 설정을 수반하는 SET 능력들 파라미터를 운반하는 ULP 메시지에서 (SET 능력들
Figure pct00421
에서) SET에 유효한
Figure pct00422
를 갖지 않음을 표시함으로써 모드 A
Figure pct00423
설정 절차를 트리거하려 시도할 수 있다.
설정된
Figure pct00424
및 관련된 파라미터들은 다음 순번들의 조기에 SLP에서 무효인 것으로 고려될 것이다
Figure pct00425
관련된
Figure pct00426
의 수명
Figure pct00427
나중의 성공적인 모드 A
Figure pct00428
설정(섹션 6.3.5.2)의 시간 후의 5분. 이 시간 지연은 그와 같은 SUPL INIT 메시지가 이전의
Figure pct00429
를 이용하여 보호됨에 따라 최신의 모드 A
Figure pct00430
설정 절차 이전에 송신된 임의의 SUPL INIT 메시지들의 전달을 허용한다.
Figure pct00431
SET가
Figure pct00432
,
Figure pct00433
및
Figure pct00434
의 값들의 손상을 검출하는 임의의 시간. 손상이 발생하는 경우에, SET는 섹션 6.3.3.4에서 예외 절차들을 개시할 것이다.
모드 A 재동기화 절차가 섹션 6.3.5.3에 특정된다. SET는 보안 세션 설정을 수반하는 SET 능력들 파라미터를 운반하는 ULP 메시지에서 (SET 능력들
Figure pct00435
Figure pct00436
에서) SET에서의 동기화의 손실을 표시함으로써 모드 A 재동기화 절차를 트리거하려 시도할 수 있다.
성공적인 모드 A
Figure pct00437
설정 절차 또는 성공적인 모드 A 재동기화 절차에서, ( SLP가 또한
Figure pct00438
를
Figure pct00439
으로 리셋할 것이기 때문에) SET는
Figure pct00440
에 대한 이용된 값들의 캐시를 클리어한다.
6.3.7 기본 SUPL INIT 보호자를 이용하기 위한 사양들
모드 A 및 모드 B SUPL INIT 보호 둘 다에 대해 기본 SUPL INIT 보호자가 이용되며 다음의 파라미터들을 포함한다:
Figure pct00441
Figure pct00442
Figure pct00443
Figure pct00444
: 길이 = 8 옥텟들.
Figure pct00445
Figure pct00446
: 길이 = 2 옥텟들.
Figure pct00448
: 길이 = 4 옥텟들.
Figure pct00449
파라미터는 다음과 같이 발생된다:
Figure pct00450
Figure pct00451
여기서
Figure pct00452
Figure pct00453
는 모드 A 및 모드 B SUPL INIT 보호를 위해 섹션들 6.3.5 및 6.3.6 각각에 따라 도출된다.
Figure pct00454
Figure pct00455
는 SUPL INIT/REINIT 메시지에 대응하며,
Figure pct00456
을 제외한 모든 파라미터들이 할당되며, MAC 파라미터는 모두 제로들로 설정하며,
Figure pct00457
Figure pct00458
및
Figure pct00459
은 [HMAC]에 특정된다.
6.1.1.2 지원된 인증 방법들의 개관( 정보적 )
(1) 일반 부트스트랩핑 아키텍처( GBA )-기반. 일반 부트스트랩핑 아키텍처(GBA)[3GPP 33.220], [3GPP 33.222], [3GPP2S.S0114], [3GPP 24.109]를 갖는 TLS-PSK. GBA는 기존의 3GPP/3GPP2 인증 메커니즘들을 이용하여 도출되는 공유된 비밀에 기초하여 상호 인증 능력을 제공한다.
Figure pct00460
SET 및 SLP는 일반 부트스트랩핑 아키텍처(GBA)를 갖는 TLS-PSK를 이용하여 상호적으로 인증된다.
(2) SEK 기반( WIMAX SLP 에만 적용가능).
Figure pct00461
SET 및 SLP는 SEK를 갖는 TLS-PSK를 이용하여 상호적으로 인증된다. SEK 방법의 상세들은 섹션 6.1.2.1.2에 발견될 수 있다.
(3) 디바이스 인증서( DCert )-기반. 이러한 AN-무관 방법은,
Figure pct00462
SET에 SLP를 인증하기 위한 RSA 서버 인증서,
Figure pct00463
SLP에 SET를 인증하기 위한 RSA 클라이언트 인증서를 갖는 TLS를 이용한다.
(4) 대안적인 클라이언트 인증( ACA )-기반. 이것은,
Figure pct00464
SET에 SLP를 인증하기 위한 RSA 서버 인증서,
Figure pct00465
SLP에 대한 SET의 대안적인 클라이언트 인증(섹션 6.1.4를 참조). 이 경우에, SLP는 베어러 네트워크가 SET 식별자(MSISDN 등)와 관련된 IP 어드레스를 확인하게 함으로써 SET를 인증한다.
(5) SLP -만. 이것은 SLP가 SET를 인증할 수 없는 시나리오들에서 이용된다. 이 방법은 비-긴급 경우들에 대해 이용되지 않을 것이다. SET는 이 방법과 ACA-기반 사이를 구별할 수 없다. 이것은,
Figure pct00466
SET에 SLP를 인증하기 위한 RSA 인증서,
Figure pct00467
SET가 인증되지 않는 TLS를 이용한다.
6.1.2.1.1 GBA 방법을 지원하는 배치들
Figure pct00468
Figure pct00469
를 지원하는 배치들의 경우에, 공유된 키들이 다음과 같이 설정된다:
Figure pct00470
(IP 통신을 보안하기 위해 그리고 SUPL INIT 및/또는 SUPL REINIT를 보호하기 위해) BSF로부터의 키 재료를 SLP가 요청할 때, SLP는 또한 USS(사용자 보안 설정들)를 요청해야 한다. USS는 영구적인 사용자 아이덴티티(예를 들어, IMPI, IMSI 또는 MSISDN)를 포함해야 한다.
Figure pct00471
SET와 SLP 사이의 IP 통신을 보안하기 위해, SET 및 SLP는 공유된 비밀 키를 도출해야 하고 GBA
Figure pct00472
를 이용하여 TLS-PSK에 따라 동작해야 한다. SLP는 예를 들어,
Figure pct00473
인 SLP를 지정하는 잘 정의된 도메인 네임
Figure pct00474
을 가져야 한다. TLS-PSK에 대해 이용될 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리[OMNA]에 정의된다. SLP는 BSF에 의해 제공된 영구적인 사용자 아이덴티티가 대응하는 보안된 접속을 통해 SLP에 의해 수신된 SUPL 메시지들에서의 SET 아이덴티티에 대응함을 확인해야 한다.
Figure pct00475
SUPL INIT 및/또는 SUPL REINIT의 MAC 보호를 위해, 키들이 GBA
Figure pct00476
에 따라 도출된다. SUPL INIT 보호를 위해 이용될 GBA Ua 보안 프로토콜 식별자는 OMNA 레지스트리[OMNA]에 정의된다. SUPL INIT 메시지(또는 SUPL REINIT 메시지)에 포함된
Figure pct00477
의
Figure pct00478
는
Figure pct00479
가 발생되는 Ks의 B-TID이어야 한다. 주석: BSF로부터의 SUPL INIT 보호 키들에 대한 D/H-SLP 요청은 IP 통신을 보안하는 키들에 대한 D/H-SLP 요청과 전형적으로 동시에 발생할 것이다.
Figure pct00480
SET는 항상 유효한 Ks를 제공받는 것을 보증해야 한다. 유효한 Ks가 존재하지 않는 경우에, SET는 Ks를 제공하기 위해 GBA 부트스트랩핑 절차를 개시해야 한다. 새로운 Ks는 새로운 UICC(USIM/SIM/R-UIM)가 SET에 의해 검출될 때마다 설정되어야 한다. 추가로, SET는 (홈 네트워크 운영자에 의해 설정된)
Figure pct00481
의 수명이 만료할 때 새로운 공유된 키들을 설정해야 한다.
10.8 SET 능력들
파라미터 존재 값/설명
SET 능력들 -
Figure pct00482
지원된 위치설정 기술들 및 위치설정 프로토콜들의 관점에서 (상호 배타적이지 않은) SET 능력들.
Figure pct00483
특정 SUPL 세션 동안, SET는 한번보다 많은 능력들을 송신할 수 있다- 구체적으로, SET 개시된 경우들에서, SET 능력들은 SUPL START, SUPL TRIGGERED START 및 SUPL POS INIT에서 송신된다. 즉시의 요청들에 대해, SET 능력들은 이러한 특정 세션 동안 변화하지 않아야 한다. 트리거링된 요청들에 대해, SET 능력들은 세션 동안 변화할 수 있다.
Figure pct00484
SET 능력들 파라미터는 또한 H-SLP 또는 D-SLP에 그 서비스 능력들에 관하여 통지하기 위해 SET에 의해 이용될 수 있다.
>POS 기술 M 이 파라미터는 SUPL 3.0에 적용하지 않는다.
>>GANSS 위치설정 방법들 O
Figure pct00485
이 파라미터는 SUPL 3.0에 적용가능하지 않으며 이용되지 않을 것이다.
>Pref 방법 M 이 파라미터는 SUPL 3.0에 적용가능하지 않다.
>Pos 프로토콜 M
Figure pct00486
제로 또는 그 이상의 다음의 위치설정 프로토콜들(비트맵):
부록 A. TIA-801
부록 B. LPP
부록 C. 레거시 위치설정 프로토콜들(RRLP 및 RRC)에 대한 LPPe 플래그들이 거짓으로 설정될 것이다.
>>Pos 프로토콜 버전 TIA-801 CV
Figure pct00487
3GPP2 C.S0022(TIA-801) 위치설정 프로토콜의 프로토콜 버전을 설명한다.
Figure pct00488
TIA-801이 Pos 프로토콜 파라미터에 식별된 경우에 요구된다
>>>지원된 Pos 프로토콜 버전 TIA-801 M
Figure pct00489
최대 8개의 서로 다른 지원된 3GPP2 C.S0022 버전들의 목록을 특정한다. 이 파라미터는 TIA-801이 Pos 프로토콜 파라미터에서 식별되는 경우에 (목록에서의 적어도 하나의 입력으로) 요청된다.
>>>>개정 번호 M C.S0022 위치설정 프로토콜의 사양들에 대한 문서 번호의 개정 부분.
값: [0, A-Z]
>>>>포인트 해제 번호 M C.S0022에 대한 포인트 해제 번호: (0..255)
>>>내부 에디트 레벨 M C.S0022에 대한 내부 에디트 레벨:(0..255)
>>Pos 프로토콜 버전 LPP CV
Figure pct00490
LPP 위치설정 프로토콜의 프로토콜 버전을 설명한다.
LPP가 Pos 프로토콜 파라미터에서 식별되는 경우에 요구된다.
>>>메이저 버전 필드 M LPP 위치설정 프로토콜에 대한 버전 번호의 제 1(최상위) 엘리먼트, 범위: (0..255)
>>>기술적 버전 필드 M LPP 위치설정 프로토콜에 대한 버전 번호의 제 2 엘리먼트, 범위: (0..255)
>>>에디트의 버전 필드 M LPP 위치설정 프로토콜에 대한 버전 번호의 제 3(최하위) 엘리먼트, 범위: (0..255)
>>Pos 프로토콜 버전 LPPe CV
Figure pct00491
LPPe 위치설정 프로토콜의 프로토콜 버전을 설명한다.
LPPe가 Pos 프로토콜 파라미터에서 식별되는 경우에 요구된다.

>>>메이저 버전 필드
M
LPPe 위치설정 프로토콜에 대한 버전 번호의 제 1(최상위) 엘리먼트, 범위: (0..255)

>>>마이너 버전 필드
M
LPPe 위치설정 프로토콜에 대한 버전 번호의 제 2 엘리먼트, 범위: (0..255)

>서비스 능력들
O		 SET의 서비스 능력들이 이 파라미터에 설명된다. SET는 이 파라미터를 SUPL START, SUPL POS INIT, SUPL TRIGGERED START 및 SUPL END에서 송신할 수 있다. 이 파라미터의 목적은 H-SLP 또는 D-SLP에 SET의 서비스 능력들에 관하여 통지하는 것이다.
>>지원된 서비스들 M
Figure pct00492
SET에 의해 지원된 서비스들을 정의한다. 네트워크 개시된 서비스들만이 이 컨텍스트에서 관련된다.
Figure pct00493
제로 또는 그 이상의 다음의 서비스들이 지원된다:
Figure pct00494
주기적 트리거
Figure pct00495
영역 이벤트 트리거
Figure pct00496
속도 이벤트 트리거
>>보고 능력들 CV SET의 보고 능력들을 정의한다. 이 파라미터는 주기적 트리거들이 SET에 의해 지원되는 경우에만 요구되며 그 경우에 파라미터는 의무사항이다.
>>>고정들 사이의 최소 간격 M SET에 의해 허용되는 고정들 사이의 최소 간격을 정의한다.
이 파라미터는 고정들 사이의 원하는 간격과 SET의 능력들 사이의 충돌을 회피하기 위해 H-SLP 또는 D-SLP에 의해 이용된다. 범위: 1 내지 3600, 초 단위들.
>>>고정들 사이의 최대 간격 O SET에 의해 허용되는 고정들 사이의 최대 간격을 정의한다.
이 파라미터는 고정들 사이의 원하는 간격과 SET의 능력들 사이의 충돌을 회피하기 위해 H-SLP 또는 D-SLP에 의해 이용된다. 이 파라미터는 임의선택적이다. 존재하지 않는 경우, 고정들 사이의 최대 간격이 특정되지 않는다. 범위: 1 내지 1440, 분 단위들.
>>>rep 모드 M
Figure pct00497
지원된 보고 모드(들):
Figure pct00498
실시간
Figure pct00499
준 실시간
Figure pct00500
배치 보고
(3가지 보고 모드들 중 적어도 하나가 지원되어야 한다)
>>>배치 rep 캡 CV
Figure pct00501
(준 실시간 및 배치 보고에만 적용가능한) SET에 의해 보고되는 배치 보고 능력들의 타입을 정의한다:
Figure pct00502
보고 위치설정(위치설정의 보고가 허용되는 경우에 참, 그렇지 않으면 거짓)
Figure pct00503
보고 측정들(측정들의 보고가 지원되는 경우에 참, 그렇지 않으면 거짓)
Figure pct00504
위치설정들의 최대수(범위: 1 내지 1024)
Figure pct00505
측정들의 최대수(범위: 1 내지 1024)
>>이벤트 트리거 능력들 CV SET의 이벤트 트리거 능력들을 정의한다. 이 파라미터는 영역 이벤트 트리거들이 SET에 의해 지원되는 경우에만 요구되며 이 경우에 파라미터는 의무사항이다.
>>>지원되는 지리적 영역 형상들 M 이 파라미터는 의무적인 원형 영역에 더하여 SET에 의해 지원되는 지리적 타겟 영역 형상들을 정의한다:
Figure pct00506
타원형
Figure pct00507
다각형
>>>지원되는 지리적 타겟 영역들의 최대 수 O
Figure pct00508
이 파라미터는 SET가 지원하는 지리적 타겟 영역들의 최대수를 정의한다.(범위: 1 내지 32)
이 파라미터는 임의선택적이다. 존재하지 않는 경우에, SET는 지리적 타겟 영역들을 지원하지 않는다.
>>>지원되는 영역 Id 목록들의 최대수 O
Figure pct00509
이 파라미터는 SET가 지원하는 영역 Id 목록들의 최대수를 정의한다.(범위: 1 내지 32)
이 파라미터는 임의선택적이다. 존재하지 않는 경우에, SET는 영역 Id들을 지원하지 않는다.
>>>영역 Id 목록 당 지원되는 영역 Id들의 최대수 CV
Figure pct00510
이 파라미터는 SET가 지원하는 영역 Id 목록 당 영역 Id들의 최대수를 정의한다.(범위: 1 내지 256)
Figure pct00511
이 파라미터는 조건적이다: 영역 Id 목록들의 최대수가 존재하는 경우에, 이 파라미터는 존재해야 한다. 그렇지 않으면 이 파라미터는 존재하지 않아야 한다.
>>>세션 능력들 M
Figure pct00512
SET의 세션 능력들을 정의한다:
Figure pct00513
동시적 세션들의 총 수
(범위: 1 내지 128)
Figure pct00514
(주기적 트리거들에 대해서만 이용되는) 동시적인 주기적 트리거된 세션들의 최대 수
(범위: 1 내지 32).
Figure pct00515
(영역 이벤트 트리거들에 대해서만 이용되는) 동시적 영역 이벤트 트리거링된 세션들의 최대 수(범위:1 내지 32).
Figure pct00516
(속도 이벤트 트리거들에 대해서만 이용되는) 동시적 속도 이벤트 트리거링된 세션들의 최대 수(범위: 1 내지 32)
>지원된 베어러들 O
Figure pct00517
이 파라미터는 SUPL 3.0에 적용가능하지 않다. 이 파라미터는 이용되지 않을 것이다.
>QoP능력들 O
Figure pct00518
이 파라미터는 높은 정확도 위치설정 및/또는 속도 결과들을 보고하고 및/또는 수신하기 위한 SET의 능력을 정의한다.
>도심 위치설정 능력들 O
Figure pct00519
이 파라미터는 절대적 도심 위치설정을 지원하기 위해 SET의 능력을 정의한다.
>상대적 위치설정 능력들 O
Figure pct00520
이 파라미터는 상대적 위치설정을 지원하기 위해 SET의 능력을 정의한다.
>H-SLP로부터의 D-SLP 제공 O
Figure pct00521
이 필드는 SET가 H-SLP로부터 인가된 D-SLP 어드레스들의 제공을 지원하는지 여부를 표시한다.
>H-SLP로부터의 E-SLP 제공 O
Figure pct00522
이 필드는 SET가 H-SLP로부터 인가된 E-SLP 어드레스들의 제공을 지원하는지 여부를 표시한다.
>프록시 D-SLP로부터의 D-SLP 제공 O
Figure pct00523
이 필드는 SET가 프록시 D-SLP로부터 인가된 D-SLP 어드레스들의 제공을 지원하는지 여부를 표시한다.
>프록시 E-SLP로부터의 E-SLP 제공 O
Figure pct00524
이 필드는 SET가 프록시 E-SLP로부터 인가된 E-SLP 어드레스들의 제공을 지원하는지 여부를 표시한다.
>H-SLP로의 D-SLP 통지 O
Figure pct00525
이 필드는 SET가 D-SLP로 액세스를 변경할 때 SET가 H-SLP에 통지할 수 있는지 여부를 표시한다.
>센서 지원 CV
Figure pct00526
위치 추정치들 및/또는 속도 추정치들을 계산하기 위해 SET가 센서들을 이용할 수 있는지 여부를 정의한다. SET가 위치설정/속도 센서들을 지원하는 경우에, 이 파라미터가 포함되어야 한다.
SUPL INIT 루트 키 상태 CV
Figure pct00527
이 파라미터는 조건적이며 모드 A SUPL INIT 보호가 이용되는 경우에만 이용될 수 있다. 널 SUPL INIT 보호 및 모드 B SUPL INIT 보호를 위해, 이 파라미터는 이용되지 않아야 한다.
Figure pct00528
이 파라미터는 다음의 조건들 중 하나를 SLP에 표시하기 위해 SET에 의해 이용된다:
Figure pct00529
무효인 SUPL INIT 루트 키
Figure pct00530
SUPL INIT 루트 키 동기화 밖
Figure pct00531
이 파라미터는 SET가 유효한 SUPL INIT 루트 키를 갖지 않는 경우에 송신되며 "무효인 SUPL INIT 루트 키"로 설정될 것이다.
이 파라미터는 SET의 SUPL INIT 루트 키가 동기화 밖에 있는 경우에 송신되고 "SUPL INIT 루트 키 동기화 밖"으로 설정될 것이다. SET가 동기인 유효한 SUPL INIT 루트 키를 갖는 경우에, 이 파라미터는 송신되지 않아야 한다.
SET 능력들 파라미터
9.2.8 SUPL 종료
SUPL 종료는 SUPL 절차를 정상적으로 또는 비정상적으로 종료하는 메시지이다.
파라미터 존재 설명
위치설정 O
Figure pct00532
SET의 위치설정 결과를 정의한다.
상태 코드 O
Figure pct00533
에러 표시 또는 정보 표시로서 메시지의 상태를 정의한다.
Figure pct00534
에러 표시들은 0과 99 사이의 값들을 가지며, 정보 표시들은 100과 199 사이의 값들을 갖는다.
Ver
CV
Figure pct00535
이 파라미터는 SUPL INIT/SUPL REINIT 메시지의 해시를 포함하며 SET에 의해 계산된다. 이 파라미터는 SUPL 종료 메시지가 SUPL INIT/SUPL REINIT 메시지에 대한 직접 응답으로서 송신되는 상황들에서 존재해야 한다.
SET 능력들 O
Figure pct00536
SET의 SET 능력들을 정의한다.
이 파라미터는 SUPL 종료 메시지가 SET로부터 SLP에 송신되는 경우에 이용될 수 있다.
위치 URI 세트 O
Figure pct00537
이 파라미터는 하나 또는 둘 이상의 위치 URI들의 세트를 포함한다. 이 파라미터는 SUPL 종료 메시지가 SLP로부터 SET에 송신되는 경우에 그리고 SET가 SLP로부터 위치 URI를 이전에 요청한 경우에만 포함될 수 있다.
SLP 인증 CV
Figure pct00538
이 파라미터는 SET로부터 H-SLP, 프록시 D-SLP 또는 프록시 E-SLP로의 D-SLP 또는 E-SLP 질문에 응답하여 포함된다. 파라미터는 또한 H-SLP 또는 프록시 D-SLP로부터 세션 정보 질문을 종료할 때 포함될 수 있다. 파라미터는 하나 또는 둘 이상의 인가된 D-SLP 및/또는 E-SLP 어드레스들을 제공하며 각 어드레스의 이용에 관한 제한들을 포함할 수 있다. 파라미터는 또한 SET 위치, 서빙 액세스 네트워크 및/또는 이웃하는 액세스 네트워크들에 기초하여 임의의 SUPL세션의 종료시에 H-SLP 또는 프록시 D-SLP에 의해 D-SLP 및/또는 E-SLP 어드레스들의 임의 제공을 지원하기 위해 이용될 수 있다. 이것은 SET 능력들이 D-SLP 또는 E-SLP 제공의 특정 타입에 대한 지원을 표시할 때마다 허용된다. H-SLP 또는 프록시 D-SLP에 의해 제공되는 임의의 D-SLP 어드레스들 또는 E-SLP 어드레스들은 H-SLP 또는 동일한 프록시 D-SLP 각각에 의해 조기에 제공된, 임의의 이전의 D-SLP 또는 E-SLP 어드레스들을 교체한다. 프록시 D/E-SLP 어드레스의 제거가 또한 프록시 D/E-SLP에 의해 제공되었을 수 있는 모든 D-SLP 또는 E-SLP 어드레스들을 제거하는 것을 제외하고는 다른 제공된 D-SLP 및 E-SLP 어드레스들은 영향받지 않는다.
상대적 위치설정 O
Figure pct00539
이 파라미터는 기준 포인트 또는 다른 SET에 대한 위치설정 결과(상대적 위치설정)를 정의한다. 이 파라미터는 SLP로부터 SET에 송신될 때만 적용가능하다.
도심 위치설정 O
Figure pct00540
이 파라미터는 도심 어드레스로서 위치설정 결과를 정의한다. 이 파라미터는 SLP로부터 SET에 송신된 때에만 적용가능하다.
Figure pct00541
이 파라미터의 존재는 구현 종속적이다.
SUPL INIT 키 응답 CV
Figure pct00542
이 파라미터는 조건적이며 모드 A
Figure pct00543
설정을 위해서만 이용될 것이다(섹션 6.3.5.2를 참조).
Figure pct00544
이 파라미터는 SUPL 종료가 SLP로부터 SET로 송신되는 경우에만 이용될 것이다.
SUPL 종료 메시지
10.x SUPL INIT 키 응답
SUPL INIT 키 응답 파라미터는 SLP로부터 SET로의 모드 A SUPL INIT 보호를 위한 키들을 송신하기 위해
Figure pct00545
설정 절차(섹션 6.3.5.2를 참조)에서 이용된다.
파라미터 존재 값/설명
SUPL INIT 키 응답 - 모드 A
Figure pct00546
설정 절차(섹션 6.3.5.2) 및 모드 A 재동기화 절차(섹션 6.3.5.3)에서 이용됨
>모드 A 키 설정 CV 이 파라미터는 조건적이며 모드 A
Figure pct00547
설정 절차의 경우에 송신될 것이다
>>모드 A 키 식별자 M 이 파라미터는
Figure pct00548
를 나타낸다(섹션 6.3.5.1을 참조)
>>일시적 모드 A 키 식별자 M 이 파라미터는
Figure pct00549
를 나타낸다(섹션 6.3.5.1을 참조)
>>
Figure pct00550
 M 이 파라미터는 SUPL Init 보호를 위해 이용되는
Figure pct00551
를 나타낸다.
>>모드 A 키 수명 M 이 파라미터는
Figure pct00552
가 유효한 것을 중단할 때의 시간을 정의하는
Figure pct00553
을 표현한다. 수명 값은 UTC 시간으로 표현된다.
>모드 A 재동기화 CV 이 파라미터는 조건적이며 모드 A 재동기화 절차의 경우에 송신될 것이다.
>>모드 A 키 식별자 M 이 파라미터는
Figure pct00554
를 나타낸다(섹션 6.3.5.1을 참조)
>>일시적 모드 A 키 식별자 M 이 파라미터는
Figure pct00555
를 나타낸다(섹션 6.3.5.1을 참조)
SUPL INIT 키 응답
11.4 메시지 확장들( SUPL 버전 3)
Figure pct00556
Figure pct00557
11.6 파라미터 확장들( SUPL 버전 3)
Figure pct00558
추가적인 실시예 9
보호 레벨 파라미터의 이전의 정의는 기본 보호가 모드 A 보호 및 모드 B 보호(모드 B 보호는 이전의 기본 보호와 동일함)로 변경되었다는 사실을 반영하지 않을 수 있다. 이전의 ASN.1 정의는 또한 업데이트될 수 있다. 따라서, 다음의 제안들은 모드 A 및 모드 B 보호를 반영하고 또한 ASN.1 섹션 11.4를 업데이트하기 위해 섹션 10.25를 수정하도록 SUPL 3.0에 통합될 수 있다.
10.22 보호 레벨
보호 레벨 파라미터는 SUPL INIT/SUPL REINIT 메시지에 대한 보호의 레벨을 정의한다.
파라미터 존재 값/설명
보호 레벨
-
Figure pct00559
이 파라미터는 SUPL INIT/SUPL REINIT 보호의 보호 레벨을 정의한다. 이 파라미터는 임의선택적이다. 존재하지 않는 경우에, 널 보호가 가정된다.
>레벨
M
Figure pct00560
널 보호
Figure pct00561
기본 보호(SUPL 3.0에 적용가능하지 않음, 즉 SLP는 이 보호 레벨을 선택하지 않을 것이다)
Figure pct00562
모드 A 보호
Figure pct00563
모드 B 보호
>기본 보호 파라미터들
CV
Figure pct00564
이 파라미터는 보호 레벨이 기본 보호인 경우에만 존재한다.
Figure pct00565
키-식별자(= B-TID)
Figure pct00566
기본 리플레이 카운터
Figure pct00567
기본 MAC
이 파라미터는 기본 보호가 SUPL 3.0에서 지원되지 않기 때문에 이용되지 않을 것이다.
>보호 파라미터 CV
Figure pct00568
이 값은 보호 레벨이 모드 A 보호 또는 모드 B 보호인 경우에만 존재한다.
Figure pct00569
키 식별자 타입
Figure pct00570

Figure pct00571
키 식별자
Figure pct00572
기본 리플레이 카운터
Figure pct00573
기본 MAC
키 식별자는 3가지 다른 타입들(키 식별자 타입)로 발생함을 주목한다:(1)
Figure pct00574
, (2)
Figure pct00575
및 (3)
Figure pct00576
. (1) 및 (2)는 모드 A 보호에 적용하는 한편 (3)은 모드 B 보호에 적용한다.
11.3 메시지 확장들( SUPL 버전 2)
Figure pct00577
11.6 파라미터 확장들( SUPL 버전 3)
Figure pct00578
Figure pct00579
당업자는 본원에 개시된 실시예들에 관련하여 설명된 다양한 예시적인 논리블록들, 구성들, 모듈들, 회로들, 및 알고리즘 단계들이 전자 하드웨어, 하드웨어 프로세서와 같은 프로세싱 디바이스에 의해 실행되는 컴퓨터 소프트웨어, 또는 이들의 조합들로서 구현될 수 있음을 더 이해할 것이다. 다양한 예시적인 컴포넌트들, 블록들, 구성들, 모듈들, 회로들, 및 단계들이 일반적으로 그들의 기능적 관점에서 앞서 설명되었다. 그와 같은 기능이 하드웨어로 구현되는지, 또는 실행가능한 소프트웨어로 구현되는지는 특정 애플리케이션 및 전체 시스템에 대해 부과된 설계 제약들에 의존한다. 당업자는 설명된 기능을 각각의 특정 애플리케이션에 대해 다양한 방식들로 구현할 수 있지만, 그와 같은 구현 결정들이 본 개시물의 범위를 벗어나는 것으로 해석되어서는 안 된다.
본원에 개시된 실시예들과 관련하여 설명되는 방법 또는 알고리즘의 단계들은 직접 하드웨어로, 프로세서에 의해 실행되는 소프트웨어 모듈로, 펌웨어로 또는 그들의 조합으로 구현될 수 있다. 소프트웨어 또는 논리 모듈은 랜덤 액세스 메모리(RAM), 자기저항 랜덤 액세스 메모리(MRAM), 스핀-토크-전달 MRAM(STT-MRAM), 플래시 메모리, 판독 전용 메모리(ROM), 프로그램가능한 판독-전용 메모리(PROM), 삭제가능한 프로그램가능한 판독-전용 메모리(EPROM), 전기적으로 삭제가능한 프로그램가능한 판독-전용 메모리(EEPROM), 레지스터들, 하드디스크, 휴대용 디스크, 콤팩트 디스크 판독-전용 메모리(CD-ROM), 디지털 만능 디스크(DVD), 블루-레이 디스크 또는 기술분야에 알려진 저장 매체의 임의의 다른 형태와 같은 비-일시적 저장 매체에 존재할 수 있다. 상기의 조합들은 또한 컴퓨터-판독가능한 매체의 범위 내에 포함되어야 한다. 예들은 데이터 구조로 인코딩된 컴퓨터-판독가능한 매체 및 컴퓨터 프로그램으로 인코딩된 컴퓨터-판독가능한 매체를 포함한다. 컴퓨터-판독가능한 매체는 제조 물건의 형태를 취할 수 있다. 예시적인 저장매체는 프로세서에 커플링되어, 프로세서는 저장 매체로부터 정보를 판독할 수 있고 저장 매체에 정보를 기록할 수 있다. 대안적으로, 저장 매체는 프로세서에 집적될 수 있다. 프로세서 및 저장매체는 응용 주문형 집적 회로(ASIC)에 위치할 수 있다. ASIC는 컴퓨팅 디바이스 또는 사용자 단말에 위치할 수 있다. 대안적으로, 프로세서 및 저장 매체는 컴퓨팅 디바이스 또는 사용자 단말에서 이산 컴포넌트들로서 존재할 수 있다. 따라서, 본원에 설명된 방법론들은 애플리케이션에 따라 다양한 수단들에 의해 구현될 수 있다. 예를 들어, 이들 방법론들은 하드웨어, 펌웨어, 소프트웨어 또는 그들의 조합으로 구현될 수 있다.
추가로, 또는 ASIC들 및 프로세서들에 대한 대안으로서, 하드웨어 구현들은 디지털 신호 프로세싱 디바이스들(DSPDs), 프로그램가능한 논리 디바이스들(PLDs), 필드 프로그램가능한 게이트 어레이들(FPGAs), 프로세서들, 제어기들, 마이크로-제어기들, 마이크로프로세서들, 전자 디바이스들, 본원에 설명된 기능들을 수행하도록 설계된 다른 전자 유닛들 또는 그들의 조합을 포함할 수 있다. 여기서, 용어 "제어 논리"는 소프트웨어, 하드웨어, 펌웨어 또는 그 조합에 의해 구현되는 논리를 망라한다.
펌웨어 및/또는 소프트웨어와 관련한 구현에 대해, 방법론들은 본원에 설명된 기능들을 수행하는 모듈들(예를 들어, 절차들, 함수들 등)로 구현될 수 있다. 명령들을 유형으로 구체화하는 임의의 기계 판독가능한 매체는 본원에 설명된 방법론들을 구현하는데 이용될 수 있다. 예를 들어, 소프트웨어 코드들은 메모리에 저장될 수 있으며 프로세싱 유닛에 의해 실행될 수 있다. 메모리는 프로세싱 유닛 내부에 또는 프로세싱 유닛 외부에 구현될 수 있다. 본원에 이용된 바와 같은 용어 "메모리"는 장기, 단기, 휘발성, 비휘발성 또는 다른 저장 디바이스들의 임의의 타입을 지칭하며 임의의 특정 타입의 메모리 또는 특정 수의 메모리들 또는 메모리가 저장되는 매체의 타입에 제한되지 않는다. 펌웨어 및/또는 소프트웨어와 관련한 구현에서, 기능들은 컴퓨터-판독가능한 매체 상에 하나 또는 둘 이상의 명령들 또는 코드로서 저장될 수 있다.
본 개시물은 Wi-Fi/WLAN 또는 다른 무선 네트워크들과 함께 구현될 수 있다. Wi-Fi/WLAN 신호들에 더하여, 무선/이동국은 또한 글로벌 위치설정 시스템(GPS), 갈릴레오, GLONASS, NAVSTAR, QZSS, 이들 시스템들의 조합으로부터 위성들을 이용하는 시스템, 또는 장래에 개발되는 임의의 SPS로부터 기인할 수 있는 위성들로부터 신호들을 수신할 수 있으며, 이들 각각은 일반적으로 본원에서 위성 위치설정 시스템(SPS) 또는 GNSS(글로벌 항법 위성 시스템)으로 지칭된다.
본 개시물은 또한 의사위성들(pseudolites) 또는 의사위성들을 포함하는 시스템들의 조합과 함께 구현될 수 있다. 본 개시물은 펨토셀들 또는 펨토셀들을 포함하는 시스템들의 조합과 함께 구현될 수 있다.
본 개시물은 무선 광역 네트워크(WWAN), 무선 로컬 영역 네트워크(WLAN), 무선 개인 영역 네트워크(WPAN) 등과 같은 다양한 무선 통신 네트워크들과 함께 구현될 수 있다. 용어들 "네트워크" 및 "시스템"은 종종 상호교환가능하게 이용된다. 용어들 "위치설정" 및 "위치"는 종종 상호교환가능하게 이용된다. WWAN은 코드 분할 다중 액세스(CDMA) 네트워크, 시분할 다중 액세스(TDMA) 네트워크, 주파수 분할 다중 액세스(FDMA) 네트워크, 직교 주파수 분할 다중 액세스(OFDMA) 네트워크, 단일-캐리어 주파수 분할 다중 액세스(SC-FDMA) 네트워크, 롱 텀 에볼루션(LTE) 네트워크, WiMAX(IEEE 802.16) 네트워크 등일 수 있다. CDMA 네트워크는 cdma2000, 광대역-CDMA(W-CDMA) 등과 같은 하나 또는 둘 이상의 라디오 액세스 기술들(RATs)을 구현할 수 있다. Cdma2000은 IS-95, IS-2000 및 IS-856 표준들을 포함한다. TDMA 네트워크는 이동 통신들을 위한 범용 시스템(GSM), 디지털 진보 이동 전화 시스템(D-AMPS) 또는 일부 다른 RAT를 구현할 수 있다. GSM 및 W-CDMA는 "제 3 세대 파트너십 프로젝트"(3GPP)란 명칭의 컨소시움으로부터의 문서들에 설명된다. Cdma2000은 "제 3 세대 파트너십 프로젝트 2"(3GPP2)란 명칭의 컨소시움으로부터의 문서들에 설명된다. 3GPP 및 3GPP2 문서들은 공개적으로 이용가능하다. WLAN은 IEEE 802.11x 네트워크일 수 있으며, WPAN은 블루투스 네트워크, IEEE 802.15x 또는 일부 다른 타입의 네트워크일 수 있다. 기술들은 또한 WWAN, WLAN 및/또는 WPAN의 임의의 조합과 함께 구현될 수 있다.
위성 위치설정 시스템(SPS)은 전형적으로 엔티티들이 전송기들로부터 수신된 신호들에 적어도 부분적으로 기초하여 지구상에 또는 그 위에 자신들의 위치를 결정하게 할 수 있도록 위치설정된 전송기들의 시스템을 포함한다. 그와 같은 전송기는 전형적으로 정해진 수의 칩들의 반복하는 의사-랜덤 잡음(PN) 코드로 마킹된 신호를 전송하며 접지 기반된 제어국들, 사용자 장비 및/또는 우주선들 상에 위치될 수 있다. 특정 예에서, 그와 같은 전송기들은 지구 궤도 인공 위성들(SVs) 상에 위치될 수 있다. 예를 들어, 글로벌 위치설정 시스템(GPS), 갈릴레오, 글로나스(Glonass) 또는 콤파스(Compass)와 같은 글로벌 항법 위성 시스템(GNSS)의 콘스텔레이션(constellation)에서의 SV는 (예를 들어, GPS에서와 같이 각 위성에 대해 다른 PN 코드들을 이용하여 또는 글로나스에서와 같은 다른 주파수들 상의 동일한 코드를 이용하여) 콘스텔레이션에서의 다른 SV들에 의해 전송된 PN 코드들로부터 구별가능한 PN 코드로 마킹된 신호를 전송할 수 있다. 특정 양상들에 따르면, 본원에 제시된 기술들은 SPS에 대한 글로벌 시스템들(예를 들어, GNSS)로 제한되지 않는다. 예를 들어, 본 명세서에 제시된 기술들은 일본 상공의 의사-천정 위성 시스템(Quasi-Zenith Satellite System: QZSS), 인도 상공의 인도 구역 항법 위성 시스템(Indian Regional Navigational Satellite System: IRNSS), 중국 상공의 베이도(Beidou) 등과 같은 다양한 구역 시스템들, 및/또는 하나 또는 둘 이상의 글로벌 및/또는 구역 항법 위성 시스템들과 관련될 수 있거나 그렇지 않으면 거기에 이용이 가능할 수 있는 다양한 증강 시스템들(예를 들어, 위성 기반된 증강 시스템(Satellite Based Augmentation System: SBAS))에 적용될 수 있거나 그렇지 않으면 이용이 가능할 수 있다. 제한이 아닌 예시로서, SBAS는 예를 들어, 광역 증강 시스템(Wide Area Augmentation System: WAAS), 유럽 정지 항법 오버레이 서비스(European Geostationary Navigation Overlay Service: EGNOS), 멀티-기능적 위성 증강 시스템(Multi-functional Satellite Augmentation System: MSAS), GPS 보조된 지오 증강된 항법 또는 GPS 및 지오 증강된 항법 시스템(GPS Aided Geo Augmented Navigation or GPS and Geo Augmented Navigation system: GAGAN) 및/또는 기타 등과 같은 무결성 정보, 차별적 정정들을 제공하는 증강 시스템(들)을 포함할 수 있다. 따라서, 본원에 이용된 바와 같이 SPS는 하나 또는 둘 이상의 글로벌 및/또는 지역 항법 위성 시스템들 및/또는 증강 시스템들의 임의의 조합을 포함할 수 있으며, SPS 신호들은 SPS, SPS-유사 및/또는 그와 같은 하나 또는 둘 이상의 SPS와 관련된 다른 신호들을 포함할 수 있다.
방법론들은 의사위성들 또는 위성들과 의사위성들의 조합을 이용하는 위치설정 결정 시스템들로 이용될 수 있다. 의사위성들은 GPS 시간과 동기화될 수 있는, L-대역(또는 다른 주파수) 캐리어 신호 상에 변조된 PN 코드 또는 다른 범위 코드(GPS 또는 CDMA 셀룰러 신호와 유사함)를 방송하는 그라운드-기반 전송기들이다. 그와 같은 각 전송기는 원격 수신기에 의한 식별을 허용하도록 고유한 PN 코드를 할당받을 수 있다. 의사위성들은 궤도 위성으로부터의 신호들이 터널들, 광산들, 빌딩들, 어번 캐니언들(urban canyons) 또는 다른 둘러싸인 영역들에서와 같이 이용불가능할 수 있는 상황들에서 유용하다. 의사위성들의 다른 구현은 라디오-비컨들로 알려진다. 본원에 이용된 바와 같은 용어 "위성"은 의사위성들, 의사위성들의 등가물들 및 가능하게는 다른 것들을 포함하도록 의도된다. 본원에 이용된 바와 같은 용어 "SPS 신호들"은 의사위성들 또는 의사위성들의 등가물들로부터 SPS-유사 신호들을 포함하도록 의도된다.
이동국(예를 들어, MS 또는 STA)은 셀룰러 또는 다른 무선 통신 디바이스, 개인 통신 시스템(PCS) 디바이스, 개인 항법 디바이스(PND), 개인 정보 관리자(PIM), 개인 휴대 정보 단말(PDA), 랩톱, 태블릿, 넷북, 스마트북 또는 무선 통신 및/또는 항법 신호들을 수신할 수 있는 다른 적합한 이동 디바이스와 같은 디바이스를 지칭한다. 용어 "이동국"은 또한 (위성 신호 수신, 보조 데이터 수신 및/또는 위치설정-관련된 프로세싱이 디바이스 또는 PND에서 발생하는지 여부에 관계없이) 단거리 무선, 적외선, 유선 접속 또는 다른 접속에 의해서와 같이 개인 항법 디바이스(PND)와 통신하는 디바이스를 포함하도록 의도된다. 또한 "이동국"은 이를테면 인터넷, Wi-Fi 또는 다른 네트워크를 통해 및 위성 신호 수신, 보조 데이터 수신 및/또는 위치설정-관련된 프로세싱이 디바이스, 서버, 또는 네트워크와 관련된 다른 디바이스에서 발생하는지 여부에 관계없이 서버와 통신할 수 있는 무선 통신 디바이스들, 컴퓨터들, 랩톱들 등을 포함하는 모든 디바이스들을 포함하도록 의도된다. 상기의 임의의 동작가능한 조합은 또한 "이동국"으로 고려된다. 용어들 "이동국" 및 "이동 디바이스"는 종종 상호교환가능하게 이용된다.
본 개시물은 예시적인 실시예들을 포함한다; 그러나, 다른 구현들이 이용될 수 있다. 어떤 것이 "최적화된", "요구된" 지정 또는 다른 지정은 본 개시물이 최적화되는 시스템들 또는 "요구된" 엘리먼트들이 존재하는 시스템들(또는 다른 지정들로 인한 다른 제한)에만 적용되는 것을 표시하지 않는다. 이들 지정들은 단지 특정 설명된 구현들을 지칭한다. 물론, 많은 구현들이 가능하다. 기술들은 개발중이거나 개발되는 프로토콜들을 포함하여, 본원에 논의된 것들과 다른 프로토콜에 이용될 수 있다.
개시된 실시예들의 이전의 설명은 당업자가 개시되는 실시예들을 이용하거나 또는 제조할 수 있도록 제공된다. 이들 실시예들에 대한 다양한 수정들은 당업자에게 분명히 명백할 것이며, 본원에 정의된 원리들은 본 개시물의 범위를 벗어남이 없이 다른 실시예들에 적용될 수 있다. 그리하여, 본 개시물은 본원에 도시된 실시예들로 한정되는 것이 아니라, 다음의 청구범위에 의해 정의되는 바와 같은 원리들 및 신규한 특징들과 일관되는 가능한 최광의의 범위에 따르는 것이다.

Claims (70)

  1. 인증 방법으로서,
    이동 디바이스에서, 상기 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜(credential)을 저장하는 단계―여기서 상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 디바이스 식별자를 포함함―; 및
    상기 디바이스 식별자와 저장된 디바이스 식별자의 비교에 기초하여 SUPL 사용자와 관련된 것으로 상기 이동 디바이스를 인증하기 위해 보안 사용자 평면 위치(secure user plane location: SUPL) 위치 플랫폼(SLP)에 상기 적어도 하나의 보안 크리덴셜을 전송하는 단계를 포함하는, 인증 방법.
  2. 제 1 항에 있어서,
    상기 적어도 하나의 보안 크리덴셜은 공개 키를 포함하는, 인증 방법.
  3. 제 1 항에 있어서,
    상기 적어도 하나의 보안 크리덴셜은 국제 이동 장비 아이덴티티(international mobile equipment identity: IMEI), 이동국 식별(mobile station identification: MSID) 및 이동 디바이스의 일련 번호 중 적어도 하나를 포함하는, 인증 방법.
  4. 제 1 항에 있어서,
    상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 디바이스 인증서(certificate)를 포함하는, 인증 방법.
  5. 제 1 항에 있어서,
    상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 유니버설 집적된 스마트 카드(universal integrated smart card : UICC), 상기 이동 디바이스의 메모리의 보안 부분 또는 그 임의의 조합에 저장되는, 인증 방법.
  6. 제 1 항에 있어서,
    상기 이동 디바이스는 SUPL 인에이블된 단말(SUPL enabled terminal: SET)을 포함하는, 인증 방법.
  7. 제 1 항에 있어서,
    상기 이동 디바이스는 IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준에 따라 동작하는 네트워크를 통해 SLP에 적어도 하나의 보안 크리덴셜을 전송하는, 인증 방법.
  8. 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜을 저장하는 메모리―여기서 상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 디바이스 식별자를 포함함―; 및
    상기 이동 디바이스가 상기 디바이스 식별자와 저장된 디바이스 식별자의 비교에 기초하여 SUPL 사용자와 관련된 것으로 상기 이동 디바이스를 인증하기 위해 보안 사용자 평면 위치(SUPL) 위치 플랫폼(SLP)에 상기 적어도 하나의 보안 크리덴셜을 전송하게 하도록 구성되는 프로세서를 포함하는, 장치.
  9. 제 8 항에 있어서,
    상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 디바이스 인증서, 공개 키, 국제 이동 장비 아이덴티티(IMEI), 이동국 식별(MSID) 및 이동 디바이스의 일련 번호 중 적어도 하나를 포함하는 장치.
  10. 이동 디바이스에 특정한 적어도 하나의 보안 크리덴셜을 저장하기 위한 수단―여기서 상기 적어도 하나의 보안 크리덴셜은 상기 이동 디바이스의 디바이스 식별자를 포함함―; 및
    상기 이동 디바이스가 상기 디바이스 식별자와 저장된 디바이스 식별자의 비교에 기초하여 SUPL 사용자와 관련된 것으로 상기 이동 디바이스를 인증하기 위해 보안 사용자 평면 위치(SUPL) 위치 플랫폼(SLP)에 상기 적어도 하나의 보안 크리덴셜을 전송하게 하기 위한 수단을 포함하는 장치.
  11. 제 10 항에 있어서,
    상기 이동 디바이스는 SUPL 인에이블된 단말(SET)을 포함하는 장치.
  12. 프로세서에 의해 실행될 때, 프로세서로 하여금:
    보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스에 송신될 메시지를 발생시키게 하고 ―상기 메시지는, 상기 SUPL 서버의 식별자 및 상기 SUPL 서버의 공개 키를 포함하는 서버 인증서, 및 상기 이동 디바이스의 디바이스 인증서에 대한 요청을 포함함―;
    상기 이동 디바이스의 디바이스 인증서를 포함하는 응답을 상기 이동 디바이스로부터 수신하게 하며; 및
    상기 디바이스 인증서에 기초하여 SUPL 사용자와 관련된 것으로 상기 이동 디바이스를 인증하게 하는 명령들을 포함하는, 비-일시적 프로세서-판독가능한 매체.
  13. 제 12 항에 있어서,
    상기 이동 디바이스는 SUPL 인에이블된 단말(SET)을 포함하며 상기 SUPL 서버는 SUPL 위치 플랫폼(SLP)을 포함하는, 비-일시적 프로세서-판독가능한 매체.
  14. 제 12 항에 있어서,
    상기 메시지는 상기 이동 디바이스에 의해 지원되는 하나 또는 둘 이상의 전송 계층 보안(TLS) 암호 스위트들(suites)의 표시를 상기 이동 디바이스로부터 수신하는데 응답하여 송신되며, 상기 메시지는 상기 하나 또는 둘 이상의 TLS 암호 스위트들 중 적어도 하나의 선택을 더 포함하는, 비-일시적 프로세서-판독가능한 매체.
  15. 제 12 항에 있어서,
    상기 디바이스 인증서는 상기 이동 디바이스의 디바이스 식별자를 포함하는, 비-일시적 프로세서-판독가능한 매체.
  16. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며,
    상기 메모리는 명령들을 저장하도록 구성되며,
    여기서 상기 명령들은:
    보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스에 송신될 메시지를 발생시키도록 ―상기 메시지는, 상기 SUPL 서버의 식별자 및 상기 SUPL 서버의 공개 키를 포함하는 서버 인증서, 및 상기 이동 디바이스의 디바이스 인증서에 대한 요청을 포함함―;
    상기 이동 디바이스의 디바이스 식별자를 포함하는 응답을 상기 이동 디바이스로부터 수신하도록; 및
    상기 디바이스 인증서에 기초하여 SUPL 사용자와 관련된 것으로 상기 이동 디바이스를 인증하도록, 프로세서에 의해 실행가능한, 장치.
  17. 제 16 항에 있어서,
    상기 메시지는 상기 이동 디바이스에 의해 지원되는 하나 또는 둘 이상의 전송 계층 보안(TLS) 암호 스위트들의 표시를 상기 이동 디바이스로부터 상기 SUPL 서버에서 수신하는데 응답하여 송신되며, 상기 메시지는 상기 하나 또는 둘 이상의 TLS 암호 스위트들 중 적어도 하나의 선택을 더 포함하는 장치.
  18. 보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스에 의해 지원되는 하나 또는 둘 이상의 전송 계층 보안(TLS) 암호 스위트들의 표시를 이동 디바이스로부터 수신하는 단계;
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS 사전-공유된 키(TLS-PSK) 암호 스위트를 포함하는지 여부를 결정하는 단계;
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함하는 것으로 결정하는데 응답하여, 상기 이동 디바이스를 인증하기 위해 일반 부트스트랩핑 아키텍처(generic bootstrapping architecture: GBA)-기반 인증 프로세스를 수행하는 단계; 및
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함하지 않는 것으로 결정하는데 응답하여, 상기 SUPL 서버가 인증서-기반 인증 방법을 지원하는지 여부를 결정하는 단계;
    상기 SUPL 서버가 상기 인증서-기반 인증 방법을 지원하는 것으로 결정하는데 응답하여, 상기 이동 디바이스에 서버 인증서를 송신하는 단계 및 상기 이동 디바이스로부터 디바이스 인증서를 수신하는 단계를 포함하는 상기 인증서-기반 인증 방법을 수행하는 단계를 포함하는, 방법.
  19. 제 18 항에 있어서,
    상기 SUPL 서버가 상기 인증서-기반 인증 방법을 지원하지 않는 것으로 결정하는 것에 응답하여, 상기 이동 디바이스가 제 3 세대 파트너십 프로젝트(3GPP) 네트워크 또는 3GPP2 네트워크에 접속될 때 대안적인 클라이언트 인증(alternative client authentication : ACA)-기반 인증 방법을 수행하는 단계를 더 포함하는 방법.
  20. 제 18 항에 있어서,
    상기 인증서-기반 인증 방법은 상기 이동 디바이스에 의해 이용되는 액세스 네트워크와 독립적인 방법.
  21. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며,
    상기 메모리는 명령들을 저장하도록 구성되며;
    상기 명령들은:
    보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스에 의해 지원되는 하나 또는 둘 이상의 전송 계층 보안(TLS) 암호 스위트들의 표시를 이동 디바이스로부터 수신하도록;
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS 사전-공유된 키(TLS-PSK) 암호 스위트를 포함하는지 여부를 결정하도록;
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함하는 것으로 결정하는데 응답하여, 상기 이동 디바이스를 인증하기 위해 일반 부트스트랩핑 아키텍처(GBA)-기반 인증 프로세스를 수행하도록; 및
    상기 하나 또는 둘 이상의 TLS 암호 스위트들이 상기 SUPL 서버에 의해 지원되는 TLS-PSK 암호 스위트를 포함하지 않는 것으로 결정하는데 응답하여, 상기 SUPL 서버가 인증서-기반 인증 방법을 지원하는지 여부를 결정하도록;
    상기 SUPL 서버가 상기 인증서-기반 인증 방법을 지원하는 것으로 결정하는데 응답하여, 상기 이동 디바이스에 서버 인증서를 송신하는 단계 및 상기 이동 디바이스로부터 디바이스 인증서를 수신하는 단계를 포함하는 상기 인증서-기반 인증 프로세스를 수행하도록 프로세서에 의해 실행가능한, 장치.
  22. 제 21 항에 있어서,
    상기 명령들은 상기 SUPL 서버가 상기 인증서-기반 인증 방법을 지원하지 않는 것으로 결정하는데 응답하여, 상기 이동 디바이스가 제 3 세대 파트너십 프로젝트(3GPP) 네트워크 또는 3GPP2 네트워크에 접속될 때 대안적인 클라이언트 인증(ACA)-기반 인증 방법을 수행하도록 상기 프로세서에 의해 더 실행가능한 장치.
  23. 제 21 항에 있어서,
    상기 인증서-기반 인증 프로세스는 상기 이동 디바이스에 의해 이용되는 액세스 네트워크와 독립적인 장치.
  24. 이동 디바이스에서, 보안 사용자 평면 위치(SUPL) 서버와 상기 이동 디바이스 사이에 SUPL 세션을 개시하기 위해 상기 SUPL 서버로부터 세션 개시 메시지를 수신하는 단계; 및
    상기 이동 디바이스가 상기 세션 개시 메시지를 수신하기 전에 상기 이동 디바이스가 상기 SUPL 서버로부터 유효한 세션 개시 메시지 키를 수신하는데 응답하여:
    상기 유효한 세션 개시 메시지 키를 이용하여 상기 세션 개시 메시지를 인증하는 단계; 및
    상기 세션 개시 메시지의 성공적인 인증에 응답하여 상기 SUPL 서버와의 상기 SUPL 세션을 개시하는 단계를 포함하는, 방법.
  25. 제 24 항에 있어서,
    상기 세션 개시 메시지는 SUPL INIT 메시지를 포함하는 방법.
  26. 제 24 항에 있어서,
    상기 유효한 세션 개시 메시지 키는
    Figure pct00580
    를 포함하는 방법.
  27. 제 24 항에 있어서,
    상기 이동 디바이스가 상기 유효한 세션 개시 메시지 키를 수신하지 않는데 응답하여:
    상기 SUPL 서버에 메시지를 전송하는 단계; 및
    상기 메시지에 응답하여 상기 SUPL 서버로부터 세션 개시 메시지 키를 수신하는 단계를 포함하는 방법.
  28. 제 27 항에 있어서,
    상기 메시지는
    Figure pct00581
    파라미터를 포함하는 방법.
  29. 제 27 항에 있어서,
    상기 메시지는 SET 성능들 파라미터 내에 포함되는 SUPL INIT 루트 키 상태 파라미터를 포함하는 방법.
  30. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며,
    상기 메모리는 명령들을 저장하도록 구성되며,
    상기 명령들은:
    이동 디바이스에서, 보안 사용자 평면 위치(SUPL) 서버와 상기 이동 디바이스 사이에 SUPL 세션을 개시하기 위해 상기 SUPL 서버로부터 세션 개시 메시지를 수신하도록; 및
    상기 이동 디바이스가 상기 세션 개시 메시지를 수신하기 전에 상기 이동 디바이스가 상기 SUPL 서버로부터 유효한 세션 개시 메시지 키를 수신하는데 응답하여:
    상기 유효한 세션 개시 메시지 키를 이용하여 상기 세션 개시 메시지를 인증하도록; 및
    상기 세션 개시 메시지의 성공적인 인증에 응답하여 상기 SUPL 서버와의 상기 SUPL 세션을 개시하도록 상기 프로세서에 의해 실행가능한, 장치.
  31. 제 30 항에 있어서,
    상기 세션 개시 메시지는 SUPL INIT 메시지를 포함하는 장치.
  32. 제 30 항에 있어서,
    상기 유효한 세션 개시 메시지 키는
    Figure pct00582
    를 포함하는 장치.
  33. 이동 디바이스로부터 보안 사용자 평면 위치(SUPL) 서버에 메시지를 전송하는 단계를 포함하며, 상기 메시지는 SUPL INIT 루트 키 상태 파라미터를 포함하는, 방법.
  34. 제 33 항에 있어서,
    상기 SUPL INIT 루트 키 상태 파라미터는 상기 이동 디바이스가 무효인
    Figure pct00583
    나 비동기
    Figure pct00584
    를 포함하는 것을 표시하는 방법.
  35. 제 33 항에 있어서,
    상기 SUPL INIT 루트 키 상태 파라미터는 상기 메시지의 SUPL 인에이블된 단말(SET) 성능들 파라미터에 포함되는 방법.
  36. 제 33 항에 있어서,
    상기 메시지는 사용자 위치 프로토콜(ULP) 메시지를 포함하는 방법.
  37. 보안 사용자 평면 위치(SUPL) 서버로부터 이동 디바이스에, SUPL INIT 키 응답 파라미터를 포함하는 SUPL END 메시지를 전송하는 단계를 포함하는, 방법.
  38. 제 37 항에 있어서,
    상기 SUPL INIT 키 응답 파라미터는 모드 A 키 식별자, 일시적 모드 A 키 식별자,
    Figure pct00585
    및 모드 A 키 수명 중 적어도 하나를 포함하는 방법.
  39. 이동 디바이스에서, 보안 사용자 평면 위치(SUPL) 서버와 상기 이동 디바이스 사이의 SUPL 세션을 계속하기 위해 보안 사용자 평면 위치(SUPL) 서버로부터 세션 재개시 메시지를 수신하는 단계; 및
    상기 이동 디바이스가 상기 세션 재개시 메시지를 수신하기 전에 상기 이동 디바이스가 상기 SUPL 서버로부터 유효한 세션 개시 메시지 키를 수신하는데 응답하여:
    상기 유효한 세션 개시 메시지 키를 이용하여 상기 세션 재개시 메시지를 인증하는 단계; 및
    상기 세션 재개시 메시지의 성공적인 인증에 응답하여 상기 SUPL 서버와의 상기 SUPL 세션을 계속하는 단계를 포함하는 방법.
  40. 제 39 항에 있어서,
    상기 세션 재개시 메시지는 SUPL REINIT 메시지를 포함하는 방법.
  41. 제 39 항에 있어서,
    상기 이동 디바이스가 상기 유효한 세션 개시 메시지 키를 수신하지 않는데 응답하여:
    상기 SUPL 서버에 메시지를 전송하는 단계; 및
    상기 메시지에 응답하여 상기 SUPL 서버로부터 세션 개시 메시지 키를 수신하는 단계를 더 포함하는 방법.
  42. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며,
    상기 메모리는 명령들을 저장하도록 구성되며,
    상기 명령들은:
    이동 디바이스에서, 보안 사용자 평면 위치(SUPL) 서버와 상기 이동 디바이스 사이의 SUPL 세션을 계속하기 위해 보안 사용자 평면 위치(SUPL) 서버로부터 세션 재개시 메시지를 수신하도록; 및
    상기 이동 디바이스가 상기 세션 재개시 메시지를 수신하기 전에 상기 이동 디바이스가 상기 SUPL 서버로부터 유효한 세션 개시 메시지 키를 수신하는데 응답하여:
    상기 유효한 세션 개시 메시지 키를 이용하여 상기 세션 재개시 메시지를 인증하도록; 및
    상기 세션 재개시 메시지의 성공적인 인증에 응답하여 상기 SUPL 서버와의 상기 SUPL 세션을 계속하도록 상기 프로세서에 의해 실행가능한, 장치.
  43. 제 42 항에 있어서,
    상기 세션 재개시 메시지는 SUPL REINIT 메시지를 포함하는 장치.
  44. 제 42 항에 있어서,
    상기 유효한 세션 개시 메시지 키는
    Figure pct00586
    를 포함하는 장치.
  45. 웹 서버에서, 보안 사용자 평면 위치(SUPL)-인에이블된 이동 디바이스로부터 메시지를 수신하는 단계―여기서 상기 메시지는 상기 이동 디바이스의 보안 크리덴셜을 포함함―;
    상기 웹 서버에서, 상기 이동 디바이스로부터 사용자 식별 정보를 수신하는 단계;
    SUPL 서비스의 인가된 사용자를 식별하는 것으로 상기 사용자 식별 정보를 인증하는 단계; 및
    SUPL 서버가 상기 SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 이동 디바이스를 인증하게 할 수 있도록 상기 이동 디바이스의 보안 크리덴셜을 상기 SUPL 서버에 송신하는 단계를 포함하는 방법.
  46. 제 45 항에 있어서,
    상기 보안 크리덴셜은 공개 키를 포함하는 디바이스 인증서를 포함하는 방법.
  47. 제 45 항에 있어서,
    상기 이동 디바이스로부터 상기 메시지를 수신하기 전에 상기 웹 서버의 공개 키를 포함하는 서버 인증서를 상기 이동 디바이스에 송신하는 단계; 및
    상기 웹 서버의 비밀 키를 이용하여 상기 메시지를 복호화하는 단계를 더 포함하는 방법.
  48. 제 45 항에 있어서,
    상기 보안 크리덴셜은 국제 이동 장비 아이덴티티(IMEI), 이동국 식별(MSID) 및 상기 이동 디바이스의 일련 번호 중 적어도 하나를 포함하는 방법.
  49. 제 45 항에 있어서,
    상기 사용자 식별 정보는 식별자 및 패스워드를 포함하는 방법.
  50. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며,
    상기 메모리는 명령들을 저장하도록 구성되며,
    상기 명령들은:
    웹 서버에서, 보안 사용자 평면 위치(SUPL)-인에이블된 이동 디바이스로부터 메시지를 수신하도록―여기서 상기 메시지는 상기 이동 디바이스의 보안 크리덴셜을 포함함―;
    상기 웹 서버에서, 상기 이동 디바이스로부터 사용자 식별 정보를 수신하도록;
    SUPL 서비스의 인가된 사용자를 식별하는 것으로 상기 사용자 식별 정보를 인증하도록; 및
    SUPL 서버가 상기 SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 이동 디바이스를 인증하게 할 수 있도록 상기 이동 디바이스의 보안 크리덴셜을 상기 SUPL 서버에 송신하도록 상기 프로세서에 의해 실행가능한, 장치.
  51. 제 50 항에 있어서,
    상기 보안 크리덴셜은 공개 키를 포함하는 디바이스 인증서를 포함하는 장치.
  52. 웹 서버에서, 보안 사용자 평면 위치(SUPL)-인에이블된 이동 디바이스로부터 메시지를 수신하기 위한 수단―여기서 상기 메시지는 상기 이동 디바이스의 보안 크리덴셜을 포함함―;
    상기 웹 서버에서, 상기 이동 디바이스로부터 사용자 식별 정보를 수신하기 위한 수단;
    SUPL 서비스의 인가된 사용자를 식별하는 것으로 상기 사용자 식별 정보를 인증하기 위한 수단; 및
    SUPL 서버가 상기 SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 이동 디바이스를 인증하게 할 수 있도록 상기 이동 디바이스의 보안 크리덴셜을 상기 SUPL 서버에 송신하기 위한 수단을 포함하는, 장치.
  53. 제 52 항에 있어서,
    상기 보안 크리덴셜은 공개 키를 포함하는 디바이스 인증서를 포함하는 장치.
  54. 명령들을 포함하는 비-일시적 프로세서-판독가능한 매체로서,
    상기 명령들은 프로세서에 의해 실행될 때, 프로세서로 하여금:
    웹 서버에서, 보안 사용자 평면 위치(SUPL)-인에이블된 이동 디바이스로부터 메시지를 수신하게 하고―여기서 상기 메시지는 상기 이동 디바이스의 보안 크리덴셜을 포함함―;
    상기 웹 서버에서, 상기 이동 디바이스로부터 사용자 식별 정보를 수신하게 하고;
    SUPL 서비스의 인가된 사용자를 식별하는 것으로 상기 사용자 식별 정보를 인증하게 하고; 및
    SUPL 서버가 상기 SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 이동 디바이스를 인증하게 할 수 있도록 상기 이동 디바이스의 보안 크리덴셜을 상기 SUPL 서버에 송신하게 하는, 명령들을 포함하는, 비-일시적 프로세서-판독가능한 매체.
  55. 제 54 항에 있어서,
    상기 보안 크리덴셜은 공개 키를 포함하는 디바이스 인증서를 포함하는, 비-일시적 프로세서-판독가능한 매체.
  56. 보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스로부터 제 1 식별자 및 제 1 패스워드를 수신하는 단계;
    SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 제 1 식별자 및 상기 제 1 패스워드를 인증하는 단계; 및
    상기 제 1 식별자 및 상기 제 1 패스워드를 교체하기 위해 상기 이동 디바이스에 제 2 식별자 및 제 2 패스워드를 송신하는 단계를 포함하며, 여기서 상기 SUPL 서버는 상기 이동 디바이스로부터 상기 제 2 식별자 및 상기 제 2 패스워드를 수신할 때 상기 이동 디바이스와 SUPL 세션을 설정하도록 구성되는 방법.
  57. 제 56 항에 있어서,
    상기 제 1 패스워드는 사용자-선택되며 상기 제 2 식별자 및 상기 제 2 패스워드는 상기 SUPL 서버에서 발생되는 방법.
  58. 제 56 항에 있어서,
    상기 SUPL 서버에서, 제 2 이동 디바이스로부터 상기 제 1 식별자 및 상기 제 1 패스워드를 수신하는 단계;
    상기 SUPL 서비스의 상기 인가된 사용자와 관련된 것으로 상기 제 1 식별자 및 상기 제 1 패스워드를 인증하는 단계; 및
    상기 제 2 이동 디바이스가 SUPL 서비스에 액세스하게 허용하는 것이 상기 SUPL 서비스를 액세스하도록 허용되는 인가된 사용자와 관련된 이동 디바이스들의 임계 수를 초과하는지 여부를 결정하는 단계를 더 포함하는 방법.
  59. 제 58 항에 있어서,
    상기 제 2 이동 디바이스가 상기 SUPL 서비스를 액세스하게 허용하는 것이 상기 이동 디바이스들의 임계 수를 초과하지 않는 것으로 결정하는데 응답하여, 상기 제 1 식별자 및 상기 제 1 패스워드를 교체하기 위해 상기 제 2 이동 디바이스에 제 3 식별자 및 제 3 패스워드를 송신하는 단계를 더 포함하는 방법.
  60. 제 59 항에 있어서,
    상기 제 3 식별자는 상기 제 2 식별자와 다르며 여기서 상기 SUPL 서버는 상기 제 2 식별자를 이용하는 이동 디바이스 및 상기 제 3 식별자를 이용하는 상기 제 2 이동 디바이스에 의해 상기 SUPL 서비스의 이용을 모니터하도록 구성되는 방법.
  61. 프로세서; 및
    상기 프로세서에 커플링된 메모리를 포함하며, 상기 메모리는 명령들을 저장하도록 구성되며,
    상기 명령들은:
    보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스로부터 제 1 식별자 및 제 1 패스워드를 수신하도록;
    SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 제 1 식별자 및 상기 제 1 패스워드를 인증하도록; 및
    상기 제 1 식별자 및 상기 제 1 패스워드를 교체하기 위해 상기 이동 디바이스에 제 2 식별자 및 제 2 패스워드를 송신하도록 상기 프로세서에 의해 실행가능하며, 여기서 상기 SUPL 서버는 상기 이동 디바이스로부터 상기 제 2 식별자 및 상기 제 2 패스워드를 수신할 때 상기 이동 디바이스와 SUPL 세션을 설정하도록 구성되는, 장치.
  62. 제 61 항에 있어서,
    상기 제 1 패스워드는 사용자-선택되며 상기 제 2 식별자 및 상기 제 2 패스워드는 상기 SUPL 서버에서 발생되는 장치.
  63. 보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스로부터 제 1 식별자 및 제 1 패스워드를 수신하기 위한 수단;
    SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 제 1 식별자 및 상기 제 1 패스워드를 인증하기 위한 수단; 및
    상기 제 1 식별자 및 상기 제 1 패스워드를 교체하기 위해 상기 이동 디바이스에 제 2 식별자 및 제 2 패스워드를 송신하기 위한 수단을 포함하며, 여기서 상기 SUPL 서버는 상기 이동 디바이스로부터 상기 제 2 식별자 및 상기 제 2 패스워드를 수신할 때 상기 이동 디바이스와 SUPL 세션을 설정하도록 구성되는, 장치.
  64. 제 63 항에 있어서,
    상기 제 1 패스워드는 사용자-선택되며 상기 제 2 식별자 및 상기 제 2 패스워드를 발생시키기 위한 수단을 더 포함하는 장치.
  65. 명령들을 포함하는 비-일시적 프로세서-판독가능한 매체로서,
    상기 명령들은 프로세서에 의해 실행될 때, 상기 프로세서로 하여금:
    보안 사용자 평면 위치(SUPL) 서버에서, 이동 디바이스로부터 제 1 식별자 및 제 1 패스워드를 수신하게 하고;
    SUPL 서비스의 인가된 사용자와 관련된 것으로 상기 제 1 식별자 및 상기 제 1 패스워드를 인증하게 하고; 및
    상기 제 1 식별자 및 상기 제 1 패스워드를 교체하기 위해 상기 이동 디바이스에 제 2 식별자 및 제 2 패스워드를 송신하게 하며, 여기서 상기 SUPL 서버는 상기 이동 디바이스로부터 상기 제 2 식별자 및 상기 제 2 패스워드를 수신할 때 상기 이동 디바이스와 SUPL 세션을 설정하도록 구성되는, 명령들을 포함하는 비-일시적 프로세서-판독가능한 매체.
  66. 제 65 항에 있어서,
    상기 제 1 패스워드는 사용자-선택되며, 여기서 상기 제 2 식별자 및 상기 제 2 패스워드는 상기 SUPL 서버에서 발생되는, 명령들을 포함하는 비-일시적 프로세서-판독가능한 매체.
  67. 보안 사용자 평면 위치(SUPL) 서버로부터의 보호 레벨 파라미터를 포함하는 SUPL INIT 메시지를 이동 디바이스에 전송하는 단계를 포함하는 방법.
  68. 제 67 항에 있어서,
    상기 보호 레벨 파라미터는:
    널(Null) 보호, 모드 A 보호 및 모드 B 보호 중 하나를 표시하는 레벨 파라미터; 및
    키 식별자 타입 및 키 식별자 중 적어도 하나를 포함하는 보호 파라미터 중 적어도 하나를 포함하는 방법.
  69. 보안 사용자 평면 위치(SUPL) 서버로부터 보호 레벨 파라미터를 포함하는 SUPL REINIT 메시지를 이동 디바이스에 전송하는 단계를 포함하는 방법.
  70. 제 69 항에 있어서,
    상기 보호 레벨 파라미터는:
    널 보호, 모드 A 보호 및 모드 B 보호 중 하나를 표시하는 레벨 파라미터; 및
    키 식별자 타입 및 키 식별자 중 적어도 하나를 포함하는 보호 파라미터 중 적어도 하나를 포함하는 방법.
KR1020137014523A 2010-11-06 2011-11-04 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증 KR101530538B1 (ko)

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 US8627422B2 (en) 2010-11-06 2011-11-03 Authentication in secure user plane location (SUPL) systems
US13/288,949 2011-11-03
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
KR1020147029822A Division KR101869368B1 (ko) 2010-11-06 2011-11-04 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증

Publications (2)

Publication Number Publication Date
KR20130089655A true KR20130089655A (ko) 2013-08-12
KR101530538B1 KR101530538B1 (ko) 2015-06-22

Family

ID=45048220

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020147029822A KR101869368B1 (ko) 2010-11-06 2011-11-04 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증
KR1020137014523A KR101530538B1 (ko) 2010-11-06 2011-11-04 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020147029822A KR101869368B1 (ko) 2010-11-06 2011-11-04 보안 사용자 평면 위치(ｓｕｐｌ) 시스템들에서의 인증

Country Status (6)

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

Families Citing this family (205)

* 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
CA2762465A1 (en) * 2011-02-11 2012-08-11 Research In Motion Limited System and method for managing access to a communication network
CN103444215B (zh) * 2011-04-01 2017-10-27 瑞典爱立信有限公司 用于避免网络攻击的危害的方法和装置
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
RU2595904C2 (ru) * 2012-02-14 2016-08-27 Эппл Инк. Способы и устройство для крупномасштабного распространения электронных клиентов доступа
WO2013172913A2 (en) * 2012-03-07 2013-11-21 The Trustees Of Columbia University In The City Of New York Systems and methods to counter side channels 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
WO2013183971A1 (en) * 2012-06-08 2013-12-12 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
US9215180B1 (en) 2012-08-25 2015-12-15 Sprint Communications Company L.P. File retrieval in real-time brokering of digital content
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
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
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
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
US9602537B2 (en) * 2013-03-15 2017-03-21 Vmware, Inc. Systems and methods for providing secure communication
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
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
US9021585B1 (en) 2013-03-15 2015-04-28 Sprint Communications Company L.P. JTAG fuse vulnerability determination and protection using a trusted execution environment
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
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
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
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
US10700856B2 (en) * 2013-11-19 2020-06-30 Network-1 Technologies, Inc. Key derivation for a module using an embedded universal integrated circuit card
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
US9161325B1 (en) 2013-11-20 2015-10-13 Sprint Communications Company L.P. Subscriber identity module virtualization
CN104703170B (zh) 2013-12-05 2017-04-12 华为终端有限公司 下载运营商的文件的方法及设备
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
EP3886397B1 (en) * 2014-03-21 2023-01-18 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
KR102126010B1 (ko) 2014-05-23 2020-06-23 후아웨이 테크놀러지 컴퍼니 리미티드 Euicc 관리 방법, euicc, sm 플랫폼 및 시스템
US10165442B2 (en) * 2014-05-29 2018-12-25 Panasonic Intellectual Property Management Co., Ltd. Transmission device, reception device, transmission method, and reception method
CN106465107B (zh) * 2014-07-07 2020-12-01 华为技术有限公司 嵌入式通用集成电路卡管理的授权方法及装置
US20170206722A1 (en) * 2014-07-09 2017-07-20 Deja View Concepts, Inc. Bluetooth Low Energy for Access Control
US9734643B2 (en) * 2014-07-10 2017-08-15 Bank Of America Corporation Accessing secure areas based on identification via personal device
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
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
US10108952B2 (en) 2014-07-10 2018-10-23 Bank Of America Corporation Customer identification
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
WO2016056820A1 (en) * 2014-10-06 2016-04-14 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
US10050955B2 (en) 2014-10-24 2018-08-14 Netflix, Inc. Efficient start-up for secured connections and related services
US11533297B2 (en) 2014-10-24 2022-12-20 Netflix, Inc. Secure communication channel with token renewal mechanism
US11399019B2 (en) * 2014-10-24 2022-07-26 Netflix, Inc. Failure recovery mechanism to re-establish secured communications
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
KR102001753B1 (ko) * 2015-03-16 2019-10-01 콘비다 와이어리스, 엘엘씨 공개 키잉 메커니즘들을 사용한 서비스 계층에서의 종단간 인증
US9473945B1 (en) 2015-04-07 2016-10-18 Sprint Communications Company L.P. Infrastructure for secure short message transmission
EP3281434B1 (en) * 2015-04-08 2020-02-12 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
US10652023B2 (en) 2015-12-30 2020-05-12 T-Mobile Usa, Inc. Persona and device based certificate management
US10972262B2 (en) * 2015-12-30 2021-04-06 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
DK3459278T3 (da) * 2016-10-31 2020-06-15 Ericsson Telefon Ab L M Autentifikation til næstegenerationssystemer
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
US10499246B2 (en) * 2017-05-17 2019-12-03 Verizon Patent And Licensing Inc. Hardware identification-based security authentication service for IoT devices
US11190504B1 (en) * 2017-05-17 2021-11-30 Amazon Technologies, Inc. Certificate-based service authorization
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
US10552069B2 (en) * 2017-07-07 2020-02-04 Sap Se Caching the topology of a 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
EP4297340A3 (en) * 2017-07-25 2024-04-17 Telefonaktiebolaget LM Ericsson (publ) Subscription concealed identifier
EP3767495B1 (en) 2017-08-28 2023-04-19 Bright Data Ltd. Method for improving content fetching by selecting tunnel devices
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving 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
EP3777269B1 (en) 2018-04-05 2022-08-24 Nokia Technologies Oy Unified subscription identifier management in communication systems
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 北京车和家信息技术有限公司 接入认证方法、装置、相关设备及计算机可读存储介质
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
US11212319B2 (en) 2019-01-24 2021-12-28 Zhnith Incorporated Multiple sentinels for securing communications
JP7273523B2 (ja) * 2019-01-25 2023-05-15 株式会社東芝 通信制御装置および通信制御システム
EP4236263A3 (en) 2019-02-25 2023-09-06 Bright Data Ltd. System and method for url fetching retry mechanism
EP4030318A1 (en) 2019-04-02 2022-07-20 Bright Data Ltd. System and method for managing non-direct url fetching 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
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 中移智行网络科技有限公司 一种设备管控方法、装置、存储介质和计算机设备
US11411997B2 (en) * 2020-08-13 2022-08-09 Salesforce, Inc. Active fingerprinting for transport layer security (TLS) servers
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
US11310256B2 (en) 2020-09-23 2022-04-19 Extrahop Networks, Inc. Monitoring encrypted network traffic
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
US11361630B1 (en) 2020-11-20 2022-06-14 Bank Of America Corporation Identifying and logging mobile devices posing security threats
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 阿波罗智联(北京)科技有限公司 处理信息的方法、装置、设备及可读存储介质
CN112906063A (zh) * 2021-02-26 2021-06-04 杭州萤石软件有限公司 一种数字摘要算法处理设备方法、装置、系统及设备
US20230396609A1 (en) * 2021-02-26 2023-12-07 Xero Limited Multi-factor authentication
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 中国石油天然气股份有限公司辽宁销售分公司 一种基于物联网技术的室内安防匿名认证方法

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2336479C (en) * 1998-07-03 2007-11-27 Nokia Mobile Phones Limited Secure session set up based on the wireless application protocol
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 华为技术有限公司 一种基于安全的用户平面移动定位方法及系统
US10178522B2 (en) 2005-08-02 2019-01-08 Qualcomm Incorporated VoIP emergency call support
CA2617783C (en) * 2005-08-02 2012-07-03 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
US9083745B2 (en) 2007-03-12 2015-07-14 Qualcomm Incorporated Network independent location services
US8086247B2 (en) 2007-04-05 2011-12-27 Nokia Corporation Secure user plane location session initiation improvement
CN102857912A (zh) 2007-10-05 2013-01-02 交互数字技术公司 由内部密钥中心（ikc）使用的用于安全通信的方法
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
US8352749B2 (en) 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
US8631238B2 (en) * 2010-12-17 2014-01-14 Oracle International Corporation Preventing race conditions in secure token exchange
US9065864B2 (en) 2010-12-29 2015-06-23 Bce Inc. Method and system for transmitting a network-initiated message to a mobile device
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
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

Also Published As

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

Similar Documents

Publication Publication Date Title
US9706408B2 (en) Authentication in secure user plane location (SUPL) systems
US20240064144A1 (en) Security lifecycle management of devices in a communications network
TWI543578B (zh) 於行動裝置中促使被發現位置伺服器之安全存取
TWI514896B (zh) 可信賴聯合身份方法及裝置
KR102398221B1 (ko) 무선 직접통신 네트워크에서 비대칭 키를 사용하여 아이덴티티를 검증하기 위한 방법 및 장치
US9161196B2 (en) Apparatus and method for secure private location information transfer
US9946883B2 (en) Methods and apparatuses for protecting positioning related information
US20200177393A1 (en) Positioning Information Verification
EP2995098B1 (en) Machine-to-machine bootstrapping
JP2012503945A (ja) Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル
TW201220793A (en) Method and apparatus for binding subscriber authentication and device authentication in communication systems
WO2016003310A1 (en) Bootstrapping a device to a wireless network

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
A107 Divisional application of patent
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20180329

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20190327

Year of fee payment: 5