KR101287309B1

KR101287309B1 - 홈 노드-ｂ 장치 및 보안 프로토콜

Info

Publication number: KR101287309B1
Application number: KR1020117009315A
Authority: KR
Inventors: 인혁 차; 요겐드라 씨 샤; 앤드레스 유 슈미트
Original assignee: 인터디지탈 패튼 홀딩스, 인크
Priority date: 2008-09-24
Filing date: 2009-09-21
Publication date: 2013-07-23
Also published as: TW201018265A; KR101508576B1; US20130046980A1; TW201313040A; EP2351396B1; KR20110084334A; JP5390619B2; CA2738372A1; KR20110058908A; EP3193524A1; JP2012503945A; EP2351396A1; CN102204305B; US8826020B2; CN102204305A; TWI466553B; WO2010036611A1; AR073672A1; US20100125732A1; US8307205B2

Abstract

홈 노드 B 또는 H(e)NB(Home evolved Node B) 장치 및 방법이 개시되어 있다. H(e)NB는 TrE(Trusted Environment) 및 인터페이스(비보호된 인터페이스, 암호적으로 보호된 인터페이스, 및 하드웨어 보호된 인터페이스를 포함함)를 포함한다. H(e)NB는 H(e)NB와 외부 네트워크 요소[SGW(Security Gateway)를 포함함] 간의 통신을 위한 보안/인증 프로토콜을 포함한다.

Description

홈 노드-Ｂ 장치 및 보안 프로토콜{HOME NODE-B APPARATUS AND SECURITY PROTOCOLS}

본 출원은 무선 통신에 관한 것이다.

3GPP(Third Generation Partnership Project) LTE(Long Term Evolution) 프로그램의 목표는 보다 저렴한 비용으로 보다 빠른 사용자 경험 및 보다 풍부한 응용 및 서비스를 위한 개선된 스펙트럼 효율, 감소된 대기시간, 및 무선 자원의 더 나은 활용을 제공하기 위해, LTE 설정 및 구성을 위한 새 기술, 새 아키텍처 및 새 방법을 개발하는 것이다. 이들 노력의 일환으로서, 3GPP는 LTE 네트워크에 대해 H(e)NB(home, evolved node B)라는 개념을 도입하였다. 3GPP는 또한 WCDMA(wideband code division multiple access)에 대한 HNB(home NB)도 고려하고 있다. 두문자어 H(e)NB는 본 출원에서 이후부터 H(e)NB 및 HNB 둘다를 지칭하는 데 사용된다.

H(e)NB는 가정 및 소규모 사무실 등의 극도로 작은 서비스 영역에 걸쳐 사용자에게 LTE 서비스에 대한 액세스를 제공한다[이는 또한 WCDMA, GSM(Global System for Mobile Communication) GERAN(Edge Radio Access Network), 및 기타 셀룰러 서비스도 제공할 수 있다]. 사용자는, 개인이든 조직이든 간에, 이러한 서비스가 요망되는 영역에서 H(e)NB를 설치할 수 있을 것이다. H(e)NB의 필수적 인증과 호스팅 당사자(hosting party)의 선택적 인증을 위한 H(e)NB와 SGW(Security Gateway) 간의 인증 프로토콜에 대한 프레임워크도 역시 도입되었다. 프로토콜은 장치 및 호스팅 당사자 인증과 모든 다른 나중의, H(e)NB와 SGW와 기타 코어 네트워크 엔티티[HLR(home location register) 및 AAA(authentication authorization accounting) 서버 등] 간의 암호화된 (IPsec 하에서의) 통신을 위한 기본 프레임워크를 제공한다.

MULTIPLE_AUTH_SUPPORTED 및 CERTREQ 등의 특정의 IKEv2(internet key exchange v2) 파라미터도 역시 H(e)NB 인증과 관련하여 다양한 기능(이들 중 하나가 H(e)NB에서 선택되거나 협상되어야 함)을 지원하는 점에서 SGW의 성능의 표시기로서 도입되었다. 그렇지만, 이들 파라미터의 사용으로 인해, 어느 유형의 인증이 선택될 수 있는지의 최종적인 선택과 관련하여 많은 "모호한" 상황이 발생한다.

상기 프로토콜에서 그리고 보다 일반적으로 프로토콜을 수행하는 장치 및 장비에 대해 다수의 보안 위협도 역시 확인되었다. 생각되는 위험들로는 취약한 인증 알고리즘을 통한 무차별 공격에 의한 H(e)NB 인증 토큰(authentication token)의 손상, 로컬 물리적 침입에 의한 H(e)NB 인증 토큰의 손상, 유효 인증 토큰을 조작된 H(e)NB에 삽입하는 것, 사용자가 H(e)NB 인증 토큰을 복제(cloning)하는 것, H(e)NB 최초 네트워크 액세스 시의 중간자 공격, 사기성 소프트웨어로 H(e)NB를 부팅하는 것["리플래싱(re-flashing)"], 사기성 소프트웨어 업데이트/구성 변경, H(e)NB의 물리적 변조, 다른 사용자의 UTRAN(universal terrestrial radio access network) 또는 E-UTRAN(evolved UTRAN) 사용자 데이터의 도청, 다른 사용자인 것처럼 가장하는 것, 보고 없이 H(e)NB 위치를 변경하는 것, H(e)NB의 소프트웨어 시뮬레이션, H(e)NB 간의 트래픽 터널링(traffic tunneling), 모뎀/라우터에서의 방화벽을 잘못 구성(mis-configuration)하는 것, H(e)NB에 대한 서비스 거부 공격(denial of service attack), 코어 네트워크(core network)에 대한 서비스 거부 공격, 활성 네트워크 서비스(active network service)의 취약점을 이용하여 H(e)NB를 손상시키는 것, 사용자의 네트워크 ID가 H(e)NB 소유자에게 노출되는 것, H(e)NB를 잘못 구성하는 것, ACL(access control list)를 잘못 구성하는 것 또는 ACL의 손상, 무선 자원 관리 변조(tampering), 유효 H(e)NB인 것처럼 가장(masquerade)하는 것, CSG(closed subscriber group)을 통해 무선 액세스 서비스(radio access service)를 제공하는 것, H(e)NB가 네트워크에 틀린 위치를 통보하는 것, 외부 시간 소스(external time source)를 조작하는 것, 및 H(e)NB에 대한 환경/부채널 공격(side channel attack)이 있지만, 이들로 제한되지 않는다.

또한 H(e)NB의 인증을 위해 위치 정보를 사용하는 것도 제안되었다. 다음과 같은 3가지 유형의 위치 정보[즉, 고정 액세스 회선 위치(fixed access line location)(예를 들어, H(e)NB의 백홀 포트(backhaul port)의 IP 주소), 매크로 셀(매크로 3G 및 2G 셀을 포함함)에 관한 정보, 및 H(e)NB에서의 GPS(global positioning system)]중 하나 또는 이들의 임의의 조합을 사용하여 H(e)NB의 위치가 확인될 수 있다.

위치 등록(location registration)[또는 증명(certification)]을 위한 단계 및 위치-기반 인증(location-based authentication)을 위한 나중의 단계도 역시 소개되었다. 그렇지만, 이들 방법은 H(e)NB에서 획득되는 위치에 관한 정보가 네트워크로 전송되기 전에 장치 내에서 안전하지 않게 처리될 수 있다는 사실을 비롯한 몇가지 단점이 있다.

LTE 및 기타 무선 통신 시스템에서의 H(e)NB의 설치는 성공적인 구현을 위해 해결되어야 하는 보안 문제를 유발한다. 그에 따라, 일부 실시예에서 UICC에서 구현될 수 있는 선택적인 HPM(hosting party module) 및 보안에 문제가 없는 환경(trusted environment)에서 H(e)NB에 대한 인증 프로토콜(authentication protocol)이 필요하다.

본 발명은 홈 노드-Ｂ 장치 및 보안 프로토콜에 대해 개시하고자 한다.

홈 노드-B 및/또는 H(e)NB(Home evolved Node B) 장치 및 보안/인증 프로토콜(security/authentication protocol)이 개시되어 있다. H(e)NB는 TrE(trusted environment), 및 H(e)NB와 외부 네트워크 요소(external network element)[SGW(Security Gateway)를 포함함] 간의 통신을 위한 보안/인증 프로토콜을 포함한다. 또한, TrE와 H(e)NB 사이에서 사용되는 인터페이스[비보호된 인터페이스, 암호적으로 보호된(cryptographically protected) 인터페이스, 및 하드웨어 보호된(hardware protected) 인터페이스]도 개시되어 있다. SGW와 H(e)NB 사이의 시그널링 규약(signaling convention)을 비롯한 인증 방법이 개시되어 있다.

일반적으로, SGW는 H(e)NB가 장치 인증(device authentication)에 부가하여 호스팅 당사자 인증(hosting party authentication)을 수행할 필요가 있는지를 H(e)NB에 알려준다. SGW는 또한 H(e)NB가 인증서-기반 인증(certificate-based authentication) 또는 EAP-AKA(extensible authentication protocol-authentication key agreement)-기반 인증을 수행할 필요가 있는지를 H(e)NB에 알려준다. 일 실시예에서, SGW는 IKE_SA_INIT 응답에서 MULTIPLE_AUTH_SUPPORTED 파라미터를 사용하여 인증의 유형(type of authentication)을 알려주고, H(e)NB는 IKE_AUTH 요청에서 MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS 파라미터를 사용하여 인증의 유형을 알려주며, SGW는 IKE_SA_INIT 응답에서 CERTREQ 파라미터를 사용하여 장치 인증의 유형을 알려준다. 다른 실시예에서, H(e)NB는, 장치 인증을 위한 정보를 송신하는 것과 함께, TrE에 의해 수행되는 장치 무결성 검사(device integrity check)의 결과를 IKEv2 프로토콜을 사용하여 SGW에게 알려주며, 그로써 공통 프로토콜(common protocol)을 사용하여 장치 확인(validation) 및 장치 인증을 달성한다.

본 발명에 따르면 홈 노드-Ｂ 장치 및 보안 프로토콜을 제공할 수 있다.

일례로서 첨부 도면과 관련하여 주어진 이하의 설명으로부터 보다 상세하게 이해할 수 있다.
도 1은 예시적인 시스템 아키텍처를 나타낸 도면.
도 2는 H(e)NB(Home evolved Node B)의 예시적인 기능 블록도.
도 3은 H(e)NB에서 TrE(Trusted Environment)의 예시적인 인터페이스 구성을 나타낸 도면.
도 4는 H(e)NB에서 TrE(Trusted Environment)의 다른 예시적인 인터페이스 구성을 나타낸 도면.
도 5는 인증 유형을 결정하는 예시적인 플로우차트.
도 6은 프로필 기반 인증(profile based authentication)의 예시적인 플로우차트.
도 7은 예시적인 보안 프로토콜을 나타낸 관계도.
도 8a 및 도 8b는 EAP-AKA(Extensible Authentication Protocol - Authentication and Key Agreement)에 대한 예시적인 신호도.
도 9는 장치 인증의 예시적인 흐름도.
도 10a 및 도 10b는 장치 및 호스팅 당사자 인증의 예시적인 흐름도.
도 11은 3 웨이 바인딩(three way binding)의 예시적인 흐름도.
도 12는 2 웨이 바인딩(two way binding)의 예시적인 흐름도.
도 13은 IKEv2 프로토콜을 사용하여 장치 인증 및 장치 무결성 검사(device integrity checking) 및 장치 확인(device validation)을 결합하는 예시적인 흐름도.

이후부터 언급될 때, "WTRU(wireless transmit/receive unit)"라는 용어는 무선 환경에서 동작할 수 있는 UE(user equipment), 이동국, 고정 또는 이동 가입자 장치, 페이저, 셀룰러 전화, PDA(personal digital assistant), 컴퓨터, 또는 임의의 다른 유형의 사용자 장치를 포함하지만, 이들로 제한되지 않는다. 이후부터 언급될 때, "기지국"이라는 용어는 무선 환경에서 동작할 수 있는 노드-B, 사이트 제어기(site controller), AP(access point), 또는 임의의 다른 유형의 인터페이싱 장치를 포함하지만, 이들로 제한되지 않는다.

무선 통신을 위해 H(e)NB(home evolved node b) 및 HNB(home node b)[모두 합하여 H(e)NB라고 함]를 설치하는 시스템 및 아키텍처와, H(e)NBz와 SGW(secure gateway) 간의 인증 시그널링의 기술(description)과, 무선 통신을 설정하는 데 사용될 수 있는 인증 방법이 본 명세서에 개시되어 있다.

도 1은 H(e)NB(110)를 배포하는 예시적인 보안 시스템 아키텍처(100)이다. H(e)NB(110)는 SGW(130)를 통해 통신 사업자의 코어 네트워크(120)에 액세스한다. SGW(130)는 H(e)NB(110)와의 상호 인증을 수행하는 데 있어서 통신 사업자의 코어 네트워크(120)를 나타낸다. 상호 인증은 인증 서버 또는 PKI(public key infrastructure)의 지원을 필요로 할 수 있다. H(e)NB(110)와 SGW(130) 사이의 백홀(backhaul)(140)이 안전하지 않을 수 있고, 백홀 링크(backhaul link)(140)를 통해 전송되는 정보를 보호하기 위해 H(e)NB(110)와 SGW(130) 사이에 보안 터널(security tunnel)이 설정될 수 있다. H(e)NB(110)는 공중 인터페이스를 통해 WTRU(150)와 통신을 한다.

도 2는 H(e)NB(200)의 예시적인 실시예의 기능 블록도를 나타낸 것이다. H(e)NB(200)는 TrE(Trusted Environment)(210)를 포함하고, 선택적으로 HPM(hosting party module)(215)에 연결되어 있거나 그와 통신하고 있을 수 있다(모두 합하여, "연결"이라고 함). 예를 들어, HPM(215)은 UICC(universal integrated circuit card)에 의해 구현될 수 있다.

TrE(210)는 보안 실행 환경(secure execution environment)(212) 및 보안 저장 영역(secure storage area)(214)을 추가로 포함한다. TrE(210)는 또한 MPU(main processing unit)/응용 프로그램 프로세서(220), 하나 이상의 UMTS(universal mobile telecommunications system), 셀룰러 모뎀 프로세서(들)(225), 전원 장치 및 로컬 인터페이스를 비롯한 주변 장치(230), 위치 확인 장치(positioning device)(240), 하나 이상의 비UMTS 셀룰러 또는 비셀룰러 모뎀 프로세서(들)(245), 그리고 클록 및 시간 장치(250)에 연결되어 있다. 본 명세서에 열거된 구성요소는 예시적인 것이며, H(e)NB(200)는 이들 구성요소는 물론 기타 구성요소의 전부 또는 일부를 포함할 수 있다.

MPU(220)는 또한 UMTS 셀룰러 모뎀 프로세서(들)(225), 주변 장치(230), 위치 확인 장치(240), 비UMTS 셀룰러 또는 비셀룰러 모뎀 프로세서(들)(245) 그리고 클록 및 시간 장치(250)에 연결되어 있다. MPU(220)는 또한 HPM(215)에도 연결될 수 있다. 위치 확인 장치(240)는 또한 클록 및 시간 장치(250)와 UMTS 셀룰러 모뎀 프로세서(들)(225)에도 연결되어 있다. UMTS 셀룰러 모뎀 프로세서(들)(225)는 또한 PA(power amplifier)/RF(radio frequency) 모듈(260)에도 연결되어 있고, 이 모듈(260)은 차례로 안테나 유닛(들)(270)에 연결되어 있다. HPM(215)은 또한 UMTS 셀룰러 모뎀 프로세서(들)(225)에도 연결될 수 있다. 개시된 바와 같이, HPM(215)은 또한 H(e)NB(200)에도 포함되어 있을 수 있다. HPM(215)이 포함되어 있을 때, HPM(215)은, 자신의 구내에 있는 H(e)NB(200)를 호스팅하는 엔티티인, 호스팅 당사자에 대한 AKA(authentication and key agreement)-기반 인증 서비스를 제공한다. HPM(215)은 UMTS 모바일 네트워크 통신 사업자(mobile network operator)를 대신하여 호스팅 당사자 인증을 수행할 수 있다.

TrE(210)는 물리적으로 또한 논리적으로 H(e)NB(200)에 바인딩되어 있고, H(e)NB(200) 내에서 신뢰할 수 있는 엔티티(trusted entity)로서 역할하며, H(e)NB(200)에 대한 앵커(anchor)를 제공한다. 보안 저장 영역(214)은 키, 암호(secret), 그리고 기타 민감한 데이터 및 프로그램에 대한 안전한 저장 영역을 제공한다. 보안 실행 환경(212)은 UMTS 네트워크에 대해 H(e)NB(200)의 AKA 및 인증서-기반 인증을 수행하는 환경과, SGW의 인증 및 그를 통해 UMTS 네트워크를 제공한다. 보안 실행 환경(212)은 TrE(210)가 본 명세서에 개시된 바와 같은 다수의 작업을 수행할 수 있게 해준다.

예를 들어, TrE(210)는, MPU(220)를 대신하여 또한 MPU(220)와 독립적으로, UMTS 및 기타 인터페이스를 통과하는 데이터 및 트래픽의 암호화 및 복호화 등의 기타 보안에 민감한 동작과, 보안에 민감한 프로그램 및 데이터 조작의 실행을 수행한다. TrE(210)는 또한 그 자신 또는 임의의 다른 구성요소 또는 H(e)NB(200)애 대한 그의 동작의 유효성을 SGW를 통해 네트워크에게 안전하게 알려주는 것과 관련된 모든 작업을 수행할 수 있다.

TrE(210)는 또한 그 자신 및 H(e)NB(200)의 나머지[MPU(220), HPM(215)(포함되어 있을 때), 셀룰러 및 비셀룰러 모뎀(들)(225, 245), 그리고 기타 주변 장치(230) 및 인터페이스를 포함함]의 유효성(신뢰성 및/또는 무결성)을 검사하는 확인 동작을 수행할 수 있다. TrE(210)는, 그의 유효성 검사를 통해 유효하지 않은 구성요소 또는 서브-엔티티를 검출할 때, 일련의 안전하고 순서에 따른 [그 자신 및 H(e)NB(200)의 나머지의] 로크-다운(lock-down) 및/또는 (로크-다운 이전에 네트워크에) 보고 동작을 수행한다.

TrE(210)는 또한 프로그램 및 데이터(인증서를 포함함)를 보호할 수 있고 위치 확인/위치 결정 장치(들)와 클록 및 타이밍 장치를 확인할(validate) 수 있으며, 이들 둘다는 H(e)NB(200)가 네트워크에 의해 인증될 수 있기 전에 또는 H(e)NB(200)가 네트워크에 대한 동작 연결(operational connectivity)을 설정하기 위해 클리어(clear)되기 전에 강제 수행되어야 한다. TrE(210)는 또한 임의의 보안에 민감한 장치 관리 및 보안에 민감한 데이터 또는 프로그램에 대한 OTA(over-the-air) 작업을 수행할 수 있다. TrE(210)는 H(e)NB(200) 및/또는 그의 개별 구성요소/서브-엔티티, 또는 그 자체에 대한 보안 정책 또는 보안 제어를 보호, 모니터링 및 실행할 수 있다. TrE(210)는 또한 그와 H(e)NB(200) 내의 임의의 다른 구성요소 및/또는 네트워크 엔티티[예를 들어, HPM, SGW, AuC(authentication center), 또는 HLR(home location register) 등] 간에 보안 채널을 설정 및 유지[절단(tearing-down)을 포함함]할 수 있다. TrE(210)는 또한 내부 보안 동작을 위해 또는 외부 통신[SGW와의 백홀 통신(장치 및/또는 호스팅 당사자 인증을 위한 통신을 포함함)을 포함함]을 위해 이러한 다른 구성요소에게 전달되어야 하는 임의의 데이터를 저장, 보호, 추출, 업데이트, 및 [H(e)NB(200) 내의 다른 구성요소에게] 안전하게 제공할 수 있다.

도 2로부터 명백한 바와 같이, TrE(210)는 원하는 기능(인증 등)을 안전하게 수행하기 위해 몇개의 H(e)NB(200) 기능 구성요소와 상호작용할 필요가 있다. 필요한 연결을 설정하기 위해, TrE(210)는 H(e)NB(200) 내의 이러한 기능 및 자원에 대한 다양한 인터페이스에 액세스해야만 한다. TrE(210)의 이들 인터페이스는 일반적으로 TrE(210)의 기능이고, TrE(210)의 보안 기동 프로세스(secure start-up process)에서 초기화되며, 따라서 올바르게 동작하는 것으로 가정된다. 이들 전제조건 하에서, 안전하고 효율적인 H(e)NB(200)의 설계를 구축하기 위해, TrE(210)가 그의 보안 속성에 관해 분석될 수 있다.

일 실시예에서, 비보호된 인터페이스, 암호적으로 보호된 인터페이스(보안 채널) 및 하드웨어 보호된 인터페이스를 비롯한 TrE 인터페이스의 3가지 광의의 보안 카테고리가 있다.

비보호된 인터페이스는 TrE(210)와 변조 및/또는 도청에 대해 보호되는 것으로 가정되지 않는 H(e)NB(200)의 일반 자원 간의 통신을 용이하게 해준다. 유의할 점은, 비보호된 인터페이스가 그럼에도 불구하고, 예를 들어, TrE(210)가 관련 키 자료(key material)를 소유하고 있고 이를 보안 메모리(secured memory)에 저장하고 있을 때, TrE(210)에 의해 암호적으로 보호되어 있는 데이터에 대한 액세스를 제공할 수 있다는 것이다.

암호적으로 보호된 인터페이스(보안 채널)은 암호화된 통신을 제공하는 보안 프로토콜에 의해 보호된다. 더욱이, 암호적으로 보호된 인터페이스는 그에 부가하여 TrE(210)와 통신을 하는 엔티티의 인증 및 부가의 원하는 특징(메시지 인증 등)을 제공하는 보안 채널을 설정할 수 있다.

하드웨어 보호된 인터페이스는 공격에 대한 물리적 보호(예를 들어, 부채널 공격에 대한 대책)를 제공한다.

H(e)NB(200) 실시예는 특정의 TrE 인터페이스 구성의 선택에 관련성 있는 다양한 측면을 고려하고 있다. 통신하는 엔티티가 전달되는 데이터의 보호를 제공하지 않을 때, 비보호된 인터페이스가 선택될 수 있다. 일례는 통신 프로토콜에서 사용되는 임시 암호(ephemeral secret)일 수 있다. TrE(210)와 통신을 하는 자원이 전달되는 정보에 대한 평문 액세스(clear text access)를 필요로 할 때와 그에 대한 어떤 보호를 제공할 수 있을 때, 암호적으로 보호된 인터페이스가 선택될 수 있다. 하드웨어 보호된 인터페이스는 일반적으로, 전체 시스템의 보호 레벨을 유지하기 위해, TrE(210)를 하드웨어 보호된 자원에 연결시킬 것이다.

도 3은 H(e)NB(300)에서의 TrE(310)의 인터페이스 구성의 일 실시예를 나타낸 것이다. 이 일례에서, TrE(310)는 장치 인증을 위해 AUTH 및 RES 모듈(312)을 사용하여 EAP-AKA(Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement) 결과(RES) 및 인증 부분(AUTH) 파라미터를 계산하는 기능을 포함하는 씬 구성(thin configuration)으로 되어 있고 - 씬 구성이란 그 자체 내에 비교적 제한된 기능을 가진다는 것을 의미함 -, H(e)NB(300)의 확인 기능(314)을 사용하여 확인을 수행한다. 이어서, TrE(310)는 H(e)NB(300) 상에 존재하는 다른 기능 또는 자원과 인터페이스한다. 인터페이스들 중 일부는 하드웨어 보호되고, 일부는 암호법 암호화(cryptographic encryption)에 의해 보호되며, 다른 것들은 비보호이다. 하드웨어 보호된 인터페이스 또는 암호적으로 보호된 인터페이스를 통해 TrE(310)와 인터페이스하는 TrE(310) 외부의 자원 및 기능이 보호된 자원 및 기능 자체이어야만 하는 것으로 가정된다. 이러한 자원 및 기능이 보호되지 않은 경우, TrE(310)가 보호된 인터페이스를 통해 이들과 인터페이스할 이유가 거의 없다.

필요한 경우, TrE(310)는 TrE(310)에 의해서만 액세스될 수 있는 특수한 하드웨어 보호된 자원(320)[보안 메모리(secure memory)(322), 암호 함수 엔진(cryptographic function engine)(324) 및 (원하는 경우 물리적인) 난수 발생기(326) 등]에 의존한다. 이들 특수한 하드웨어 보호된 자원은 TrE(310)의 RoT(Root of Trust)라고 할 수 있다. TrE(310) 자체의 신뢰성을 구축하기 위해, 상세하게는, TrE(310) 및 H(e)NB(300)의 보안 기동 프로세스를 가능하게 해주기 위해, 이들 자원이 하드웨어 보호된 인터페이스(328)를 통해 액세스되어야만 한다. H(e)NB(300)의 다른 기능 구성요소는 다양한 보안 속성을 가질 수 있고, 보안 채널(330)을 통해 액세스될 수 있다. 예를 들어, 난수 발생기 모듈(random generator module)(332), 난수 파라미터 제어(random parameter control)(334), WTRU 인증 자원(336), H(e)NB 인증(340), IP 스택(342) 및 호스트 플랫폼 모듈(350)은 암호적으로 보호된 인터페이스 또는 보안 채널(330)을 통해 액세스된다. 민감한 정보(360)[예를 들어, 시간 소스(362) 및 위치 결정(364) 등]는 암호적으로 보호된 인터페이스 또는 보안 채널(330)을 통해 액세스된다. 이러한 경우에, 특정 하드웨어 보호 대책와의 결합은 선택적이다. 그에 부가하여, 비보호된 인터페이스(370)는 민감하지 않은 자원(375)에 연결되고, 예를 들어, TrE의 저장 용량을 갖는 메모리(380)를 확장하기 위해, 범용 자원에 연결된다. 본 명세서에 기술된 바와 같이, 인터페이스는 보안 요구사항이 다를 수 있고, TrE는 각각의 인터페이스 유형을 수용하고 그와 상호작용할 필요가 있다.

도 4는 TrE(410)를 가지는 H(e)NB(400)에 대한 다른 인터페이스 구성을 나타낸 것이다. 이 실시예에서, TrE(410)는 그 자체 내에 하드웨어 암호화 자원[예를 들어, 암호화 엔진(415), 난수 발생기(417) 및 보안 메모리(419) 등]을 포함하는 씨크 구성(thick configuration)으로 되어 있다. TrE(410)는, 예를 들어, IKEv2 스택(422), 장치 인증(424) 및 H(e)NB 확인 모듈(426)을 사용하여, IKEv2(Internet Key Exchange)를 통해 장치 인증을 수행하는 전체 기능을 추가로 포함한다. TrE(410)는 또한 모듈(428)을 사용하여 WTRU의 AKA 절차를 지원한다. 유의할 점은, 본 설명 전체에 걸쳐 예시를 위해 IKEv2 프로토콜이 사용되고, TLS(Transport Layer Security), TR(Broadband Forum Technical Requirements) 069, OMA(Open Mobile Alliance) DM(Device Management) 프로토콜, 또는 TLS의 확장을 위한 어떤 적합한 IETF(Internet Engineering Task Force) RFC(Requests for Comment)(이들로 제한되지 않음) 등의 다른 프로토콜도 역시 사용될 수 있다는 것이다.

이 실시예에서, 난수 발생기 모듈(432), 난수 파라미터 제어(434), 호스트 플랫폼 모듈(450), 및 민감한 정보(460)[예를 들어, 시간 소스(462) 및 위치 결정(464) 등]도 역시 암호적으로 보호된 인터페이스 또는 보안 채널(430)을 통해 액세스된다. 그에 부가하여, 비보호된 인터페이스(470)는 민감하지 않은 자원(475)에 연결되고, 예를 들어, TrE의 저장 용량(480)을 확장하기 위해, 범용 자원에 연결된다.

다른 실시예에서, 2가지 광의의 유형의 인터페이스(보호된 인터페이스 및 비보호된 인터페이스)가 있다. 예를 들어, 도 3 및 도 4에서 하드웨어 보호된 인터페이스 또는 암호적으로 보호된 인터페이스로서 나타내어져 있는 인터페이스는 간단히 보호된 인터페이스로서 간주될 수 있고, 비보호된 인터페이스로서 나타내어져 있는 인터페이스는 간단히 비보호된 인터페이스로서 간주될 수 있다.

본 명세서에서 언급되는 바와 같이, H(e)NB의 필수적 인증과 호스팅 당사자의 선택적 인증을 위한 H(e)NB와 SGW 간의 인증 프로토콜이 도입되었다. 본 명세서에서 논의된 TrE 기능을 사용하는 인증 선택 방법에 대해 이제부터 개시한다.

H(e)NB와 코어 네트워크 간의 보안 통신(인증을 위한 통신을 포함함)을 위해 IKEv2(Internet Key Exchange version 2)가 기본 프레임워크로서 사용될 수 있다. IKEv2는 H(e)NB와 SGW 간의 SA(security association)를 설정하고, 이 2개의 엔티티 간의 IPSec 터널을 설정하기 위해 사용될 수 있는 보안 키를 이용가능하게 만든다. IKEv2는 또한 H(e)NB 및 호스팅 당사자의 결합된 인증을 위해 사용될 수 있다.

IKEv2는 상호 인증을 수행하는 것 및 SA(security association)를 설정 및 유지하는 것을 위해 사용되는 IPSec의 구성요소이다. H(e)NB와 관련하여, "종점-보안 게이트웨이 터널(end-point to security gateway tunnel)"이 즉각 적용가능하다. 따라서, 종점인 H(e)NB와 SGW 사이에서, IKE_SA에 대해 보안 파라미터의 협상과 랜덤한 넌스(random nonce) 및 Diffie-Hellman 값의 전송을 포함하는 제1 단계(IKE_SA_INIT) 그리고 ID의 전송과 AH(Authentication Header) 및/또는 ESP(Encapsulated Security Payload)에 대한 SA의 설정을 포함하는 요청/응답 단계를 포함하는 제2 단계(IKE_AUTH)로 이루어지는 IKEv2 단계가 뒤따라온다.

적어도 2개의 상이한 인증 동작이 지정되며, 하나는 H(e)NB 장치 자체의 인증(장치 인증이라고 함)을 위한 것이고 다른 하나는 호스팅 당사자의 인증(호스팅 당사자 인증이라고 함)을 위한 것이다. 장치 인증은 필수적이다. 장치 인증은 EAP-AKA(extensible authentication protocol-authentication key agreement) 또는 인증서를 사용하여 행해질 수 있다. 호스팅 당사자 인증은 HPM(hosting party module)을 사용하여 행해질 수 있다. 호스팅 당사자 인증이 행해질 때, 호스팅 당사자 인증은 장치 인증과 별도로 행해질 수 있거나, 장치 인증 및 호스팅 당사자 인증에 대한 단계를 사용하여 복합 방식으로 행해질 수 있다. 게다가, H(e)NB의 ID 및 HPM의 ID는 물리적으로 또는 논리적으로 바인딩될 수 있고, 이러한 바인딩에 대한 가능한 프로토콜은 본 명세서에서 소개되었다.

일반적으로, H(e)NB가 장치 인증에 부가하여 호스팅 당사자 인증을 수행할 필요가 있는지를 SGW가 H(e)NB에 알려주는 인증 프로토콜 시그널링 방식에 대해 먼저 개시한다. SGW는 또한 H(e)NB가 인증서-기반 인증 또는 EAP-AKA-기반 인증을 수행할 필요가 있는지를 H(e)NB에 알려준다. SGW는 IKE_SA_INIT 응답에서 MULTIPLE_AUTH_SUPPORTED 파라미터를 사용하여 인증의 유형을 나타내고, IKE_SA_INIT 응답에서 CERTREQ 파라미터를 사용하여 장치 인증의 유형을 나타낸다. H(e)NB는 IKE_AUTH 요청에서 MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS 파라미터를 사용하여 인증의 유형을 알려준다.

본 명세서에서 논의된 바와 같이, 다양한 IKEv2 응답 메시지에서 MULTIPLE_AUTH_SUPPORTED 및 CERTREQ 파라미터가 SGW로부터 H(e)NB로 전송될 때, 이들은 H(e)NB에 대한 요구사항 또는 요청으로서 해석되어야만 한다. 주목할 점은, SGW가 어느 유형의 인증 방법이 사용되어야만 하는지를 실제로 '결정'하고 이어서 H(e)NB에 요청 또는 요구사항으로서 전송한다는 것이다. 이로부터 선택 절차에서 요청 및 응답 쌍의 모든 가능한 조합에 대한 명백하고 명확한 결과가 얻어진다. 유의할 점은, 방법의 표시된 선택이 SGW에 의해 지원되지 않는 경우 이를 전송하지 않을 것이기 때문에, 동일한 파라미터가 또한 SGW 기능의 표시기로서도 해석되어야만 한다는 것이다.

본 명세서에서 언급한 바와 같이, H(e)NB는 필수적 장치 인증 및 선택적 HP(hosting party) 인증을 가질 것이다. 이들 2개의 인증은 상이한 방식으로 행해질 수 있으며, 실제로, 배포된 제품[H(e)NB 및 SGW]은 필수적 인증, 또는 선택적 및 필수적 인증 둘다를 지원할 수 있다. 따라서, (SGW를 통해) 통신 사업자 네트워크에 연결되는 주어진 H(e)NB에 대한 인증의 유형을 선택하는 방법이 요구된다. SGW가 통신 사업자 정책을 시행하기 때문에, SGW에 의해 H(e)NB에 대해 행해지고 표시되는 선택은 신뢰할 수 있다.

인증 선택 방법의 일 실시예에서, 이 방법은 다음과 같은 것을 가정한다: 1) 인증서 또는 EAP-AKA에 의한 장치 인증, 및 2) EAP-AKA에 대한 호스팅 당사자 인증. 제시된 방법의 실시예는 IKEv2 다중 인증의 사용을 가정한다.

이후부터 논의되는 바와 같이, 필수적 장치 인증 및 선택적 호스팅 당사자 인증이 H(e)NB에서 행해진다. 인증은 인증서 기반 솔루션 또는 EAP-AKA에 의해 행해질 수 있다. 이 결과, 2가지 인증 방법과 인증을 필요로 할지도 모르는 2개의 엔티티와 관련하여 다음과 같은 조합이 얻어진다: 1) HP 인증 없이 인증서에 의한 장치 인증, 2) HP 인증 없이 EAP-AKA에 의한 장치 인증, 3) 인증서를 사용하는 HP 인증과 인증서에 의한 장치 인증, 4) 인증서를 사용하는 HP 인증과 EAP-AKA에 의한 장치 인증, 5) EAP-AKA를 사용하는 HP 인증과 인증서에 의한 장치 인증, 및 6) EAP-AKA를 사용하는 HP 인증과 EAP-AKA에 의한 장치 인증. 이 실시예에서 EAP-AKA가 HP 인증에 대한 선택일 수 있는 것으로 가정하면, 인증 조합 3 및 4가 제외될 수 있다.

H(e)NB(505)와 SGW(510) 사이에서 장치 인증이 있을 것인지 장치 및 HP 인증 둘다가 있을 것인지를 판정하는 방법(500)이 도 5를 참조하여 개시된다. 방법(500)은 일 실시예에 따른 IKEv2 기반 인증 절차이다. 먼저, H(e)NB(505)는 IKE_SA_INIT 요청 메시지를 SGW(510)로 전송한다(515). SGW(510)는 IKE_SA_INIT 응답 메시지를 전송한다(520). IKE_SA_INIT 응답 메시지가 MULTIPLE_AUTH_SUPPORTED를 포함하지 않는 경우, 다중 인증(multiple authentication)이 행해질 수 없다는 것이 H(e)NB(505)에게 분명하다. 따라서, 인증서 또는 EAP-AKA 기반 인증을 사용하여 장치 인증만이 가능할 것이다.

H(e)NB(505)는 IKE_AUTH 요청 메시지를 전송한다(525). SGW(510)는 IKE_AUTH 요청 메시지가 MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS를 포함하는지를 판정한다. IKE_AUTH 요청 메시지가 주어진 값을 포함하지 않는 경우, 이는 장치 인증만이 행해질 수 있다는 것을 의미한다. 주어진 값이 그곳에 있는 경우, 장치 및 HP 인증 둘다가 행해질 수 있다.

또다시 도 5를 참조하여 장치 인증의 유형이 인증서 기반인지 EAP-AKA 기반인지를 판정하는 방법이 개시된다. H(e)NB(505)는 IKE_SA_INIT 응답에 CERTREQ이 있는지를 판정한다(520). H(e)NB(505)에 대한 IKE_SA_INIT 응답에 CERTREQ가 있는 경우, 이는 SGW(510)가 인증서 기반 장치 인증을 지원하고 또한 EAP-AKA 기반 인증도 지원할 수 있다는 것을 의미한다. SGW(510)로부터 H(e)NB(505)로의 IKE_SA_INIT 응답에 CERTREQ가 없는 경우, 이는 SGW(510)가 EAP-AKA 기반 인증을 지원한다는 것을 의미한다.

인증서 기반 장치 인증은 또한 H(e)NB(505)로부터 SGW(510)로의 IKE_AUTH 요청(525)이 AUTH를 포함하는지를 SGW(510)에서 판정함으로써 수행될 수 있다. AUTH가 있는 경우, 이는 인증서 기반 장치 인증이 수행될 것임을 의미하고, 그렇지 않은 경우, 이는 EAP-AKA 기반 인증이 수행될 것임을 의미한다. 본 명세서에서 살펴본 바와 같이, 호스팅 당사자(HP) 인증은 EAP-AKA를 사용한다.

인증 선택 방법의 일 실시예에서, 인증 메커니즘의 선택은 본 명세서에서 논의된 원리를 사용한다. H(e)NB는 인증서 또는 EAP-AKA를 사용하는 장치 인증을 지원해야만 한다. 상기 2가지 방법(즉, 인증서 기반 인증 방법 또는 EAP-AKA 기반 장치 인증 방법) 중 어느 것에 관한 결정이 실제로는 배포-관련 결정으로서 선택될 것이다. H(e)NB는 장치 인증을 위해 인증서 또는 EAP-AKA를 사용하고 호스팅 당사자 인증을 위해 EAP-AKA를 사용하는 결합된 인증을 지원할 수 있다. SGW가 양쪽 인증 메커니즘을 지원하더라도, SGW는 통신 사업자 정책에 기초하여 이들 중 하나의 사용을 거부할 수 있다. SGW는 SGW가 H(e)NB에게 장치 인증 및 호스팅 당사자 인증 둘다 또는 장치 인증만을 수행하라고 요구하는지 또한 SGW가 (e)NB에게 인증서 기반 장치 인증 또는 EAP-AKA 기반 장치 인증을 수행하라고 요구하는지를 H(e)NB에게 분명히 알려준다.

전술한 기준에 기초하여, 이하의 표 1 내지 표 4에서 인증 선택 방법이 논의된다. 표의 내용은 인증 방법 선택의 최종 결과를 나타낸다. 표 1 내지 표 4는 일 실시예에 따른 인증 방법 선택을 요약한 것이다. 이들 표에서, M_A_S는 MULTIPLE_AUTH_SUPPORTED이고, I_S_I는 IKE_SA_INIT이며, A_A_F는 ANOTHER_AUTH_FOLLOWS이다.

표 1은 H(e)NB가 4가지 상이한 SGW IKE_SA_INIT 응답에 대해 IKE_AUTH 요청 메시지에서 AUTH, MULTIPLE_AUTH_SUPPORTED, 및 ANOTHER_AUTH_FOLLOWS를 반환하는 시나리오를 나타낸다. 경우 1에서, SGW는 MULTIPLE_AUTH_SUPPORTED 및 CERTREQ를 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 인증서 기반 장치 인증 및 EAP-AKA 기반 호스팅 당사자 인증을 수행하는 것에 대응한다. 경우 2에서, SGW는 MULTIPLE_AUTH_SUPPORTED를 갖지만 CERTREQ를 갖지 않는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 EAP-AKA 기반 장치 및 EAP-AKA 기반 호스팅 당사자 인증을 요구했지만 H(e)NB가 인증서 기반 장치 인증으로 응답할 때의 오류 조건에 대응한다. 이것이 발생하면, 최종 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 3에서, SGW는 CERTREQ만을 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 인증서 기반 장치 인증만을 요구했지만 H(e)NB가 장치 및 호스팅 당사자 인증 둘다에 대한 시도로 응답할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 최종 결정은 통신 사업자 정책에 의존해야만 한다. 경우 4에서, SGW는 MULTIPLE_AUTH_SUPPORTED도 CERTREQ도를 갖지 않는 IKE_SA_INIT를 전송한다. H(e)NB 요청 메시지는 SGW가 H(e)NB에게 EAP-AKA 기반 장치 인증만을 수행하라고 요구했지만 H(e)NB가 장치 및 호스팅 당사자 인증 둘다를 수행하는 것으로 응답할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다.

		IKE_SA_INIT 응답
		SGW는 I_S_I 응답에 M_A_S 및 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지만 CERTREQ 페이로드를 포함시키지 않는다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지않지만 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S도 CERTREQ 페이로드도 포함시키지 않는다.
IKE_AUTH 요청 메시지	H(e)NB는 제1 IKE_AUTH 요청 메시지에 AUTH, M_A_S 및 A_A_F 통지 페이로드를 포함시킨다.	경우 1: 인증서 기반 장치 및 EAP-AKA 기반 호스팅 당사자 인증이 행해짐	경우 2: 이것은 오류 조건이다.	경우 3: 이것은 오류 조건이다.	경우 4: 이것은 오류 조건이다.

표 2는 H(e)NB가 4가지 상이한 SGW IKE_SA_INIT 응답에 대해 IKE_AUTH 요청 메시지에서 MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS를 반환하고 AUTH를 반환하지 않는 시나리오를 나타낸다. 경우 5에서, SGW는 MULTIPLE_AUTH_SUPPORTED 및 CERTREQ를 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW 메시지가 인증서-기반 장치 인증을 요구하지만 H(e)NB가, AUTH를 건너뜀으로써, 인증서-기반 장치 인증을 지원하지 않는다는 것을 나타낼 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 6에서, SGW는 MULTIPLE_AUTH_SUPPORTED를 갖지만 CERTREQ를 갖지 않는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 EAP-AKA 기반 장치 및 호스팅 당사자 인증을 수행하는 것에 대응한다. 경우 7에서, SGW는 CERTREQ만을 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 H(e)NB에게 장치 인증만을 수행하라고 요구하지만 H(e)NB가 장치 인증 및 호스팅 당사자 인증 둘다를 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 최종 결정은 통신 사업자 정책에 의존해야만 한다. 경우 8에서, SGW는 MULTIPLE_AUTH_SUPPORTED도 CERTREQ도를 갖지 않는 IKE_SA_INIT를 전송한다. H(e)NB 요청 메시지는 SGW가 H(e)NB에게 EAP-AKA에 기반한 장치 인증만을 수행하라고 요구했지만 H(e)NB가 장치 및 호스팅 당사자 인증 둘다를 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다.

		IKE_SA_INIT 응답
		SGW는 I_S_I 응답에 M_A_S 및 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지만 CERTREQ 페이로드를 포함시키지 않는다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지않지만 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S도 CERTREQ 페이로드도 포함시키지 않는다.
IKE_AUTH 요청 메시지	H(e)NB는 제1 IKE_AUTH 요청 메시지에 AUTH를 포함시키지 않지만, M_A_S 및 A_A_F 페이로드를 포함시킨다.	경우 5: 이것은 오류 조건이다.	경우 6: EAP-AKA 기반 장치 및 호스팅 당사자 인증이 행해짐	경우 7: 이것은 오류 조건이다.	경우 8: 이것은 오류 조건이다.

표 3은 H(e)NB가 4가지 상이한 SGW IKE_SA_INIT 응답에 대해 IKE_AUTH 요청 메시지에서 AUTH를 반환하지만 MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS를 반환하지 않는 시나리오를 나타낸다. 경우 9에서, SGW는 MULTIPLE_AUTH_SUPPORTED 및 CERTREQ를 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 인증서 기반 장치 인증 및 호스팅 당사자 인증을 요구하지만 H(e)NB가 인증서 기반 장치 인증만을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 10에서, SGW는 MULTIPLE_AUTH_SUPPORTED를 갖지만 CERTREQ를 갖지 않는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 EAP-AKA 기반 장치 및 EAP-AKA 기반 호스팅 당사자 인증을 요구했지만 H(e)NB가 인증서 기반 장치 인증만을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 11에서, SGW는 CERTREQ만을 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 인증서-기반 장치 인증을 수행하는 것에 대응한다. 경우 12에서, SGW는 MULTIPLE_AUTH_SUPPORTED도 CERTREQ도를 갖지 않는 IKE_SA_INIT를 전송한다. H(e)NB 요청 메시지는 SGW가 H(e)NB에게 EAP-AKA에 기반한 장치 인증을 수행하라고 요구했지만 H(e)NB가 인증서 기반 장치 인증을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다.

		IKE_SA_INIT 응답
		SGW는 I_S_I 응답에 M_A_S 및 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지만 CERTREQ 페이로드를 포함시키지 않는다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지않지만 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S도 CERTREQ 페이로드도 포함시키지 않는다.
IKE_AUTH 요청 메시지	H(e)NB는 제1 IKE_AUTH 요청 메시지에 AUTH를 포함시키지만, M_A_S 및 A_A_F 통지 페이로드를 포함시키지 않는다.	경우 9: 이것은 오류 조건이다.	경우 10: 이것은 오류 조건이다.	경우 11: 인증서 기반의 장치 인증	경우 12: 이것은 오류 조건이다.

표 4는 H(e)NB가 4가지 상이한 SGW IKE_SA_INIT 응답에 대해 IKE_AUTH 요청 메시지에서 AUTH, MULTIPLE_AUTH_SUPPORTED, 및 ANOTHER_AUTH_FOLLOWS를 반환하지 않는 시나리오를 나타낸다. 경우 13에서, SGW는 MULTIPLE_AUTH_SUPPORTED 및 CERTREQ를 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 인증서 기반 장치 인증 및 호스팅 당사자 인증을 요구하지만 H(e)NB가 EAP-AKA 기반 장치 인증을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 14에서, SGW는 MULTIPLE_AUTH_SUPPORTED를 갖지만 CERTREQ를 갖지 않는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 EAP-AKA 기반 장치 인증 및 EAP-AKA 기반 호스팅 당사자 인증 둘다를 요구했지만 H(e)NB가 EAP-AKA 기반 장치 인증을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 15에서, SGW는 CERTREQ만을 가지는 IKE_SA_INIT 응답을 전송한다. H(e)NB 요청 메시지는 SGW가 H(e)NB에게 인증서 기반 장치 인증을 수행하라고 요구하지만 H(e)NB가 EAP-AKA 기반 장치 인증을 수행하려고 시도할 때의 오류 조건에 대응한다. 이것이 발생하면, 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 경우 16에서, SGW는 MULTIPLE_AUTH_SUPPORTED도 CERTREQ도를 갖지 않는 IKE_SA_INIT를 전송한다. H(e)NB 요청 메시지는 EAP-AKA 기반 장치 인증을 수행하는 것에 대응한다.

		IKE_SA_INIT 응답
		SGW는 I_S_I 응답에 M_A_S 및 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지만 CERTREQ 페이로드를 포함시키지 않는다.	SGW는 I_S_I 응답에 M_A_S를 포함시키지않지만 CERTREQ 페이로드를 포함시킨다.	SGW는 I_S_I 응답에 M_A_S도 CERTREQ 페이로드도 포함시키지 않는다.
IKE_AUTH 요청 메시지	H(e)NB는 제1 IKE_AUTH 요청 메시지에 AUTH를 포함시키지 않지만, M_A_S 및 A_A_F 통지 페이로드를 포함시킨다.	경우 13: 이것은 오류 조건이다.	경우 14: 이것은 오류 조건이다.	경우 15: 이것은 오류 조건이다.	경우 12: EAP-AKA 기반 장치 인증

경우 1, 경우 6, 경우 11 및 경우 16에 의해 유효한 요구/응답 쌍이 얻어진다. 모든 다른 경우에 의해 오류 조건이 얻어지며, 이 경우 결과에 관한 SGW 결정은 통신 사업자 정책에 의존해야만 한다. 정책 결정은, 그에 부가하여, H(e)NB의 인증 기능에 대해 SGW가 알고 있는 것에 기초할 수 있다. 예를 들어, IKE_SA_INIT 요청 메시지에서 H(e)NB에 의해 제공되는 H(e)NB ID에 기초하여, SGW는 H(e)NB 인증 정보 프로필(예를 들어, H(e)NB의 인증 유형)을 저장하는 H(e)NB 인증 정보 서버로부터 H(e)NB의 인증 기능 프로필을 도출할 수 있다. SGW는 인증 프로필에 기초하여 인증서-기반 장치 인증을 요청할지 EAP-AKA 기반 인증을 요청할지를 결정할 수 있다. H(e)NB 인증 정보 서버가 꼭 물리적 서버로서 구현되어야 하는 것은 아니며, 다른 기능과 동일 장소에 있을 수 있다.

도 6을 참조하면, H(e)NB 인증 정보 서버(605)로부터의 프로필 정보를 사용하는 방법(600)의 실시예가 도시되어 있다. SGW(610)는 H(e)NB(615)로부터 수신된(1) H(e)NB ID에 기초하여 H(e)NB 인증 정보 서버(605)로부터 인증 프로필을 가져올 수 있다(2 및 3). 이어서, SGW(610)는 H(e)NB(615) 인증 프로필에 따라 어느 유형의 장치 인증을 요청할지를 결정한다(4). SGW(610)는 IKE_SA_INIT 응답을 전송한다(5).

인증 유형이 "장치 인증만"이 수행되어야 하는 것을 의미하는 경우, SGW(610)는 H(e)NB(615)로부터 IKE_AUTH 요청을 받을 것이다(6). SGW(610)는 AUTH 응답 메시지를 H(e)NB(615)로 전송하고, 인증 절차를 계속한다(7a).

인증 유형이 "장치 및 HP 인증 둘다"가 수행되어야 하는 것을 의미하는 경우, SGW(610)는 호스팅 당사자 인증에 대한 다른 IKE_AUTH 요청 메시지(7b)와 함께 이전의 IKE_AUTH 요청 메시지(6)를 따르도록 H(e)NB(615)에 알려주기 위해 '인증 거부' 메시지를 가지는 IKE_AUTH 응답을 전송할 것이다. 인증 거부 메시지는 호스팅 당사자 인증을 따르도록 H(e)NB(615)에게 알려주기 위한 것에 불과하며, SGW(610)가 이전의 IKE_AUTH 요청 메시지(6)에서 획득된 장치 인증에 관한 정보를 폐기할 것임을 의미하지 않는다. 그 대신에, H(e)NB(615)가 호스팅 당사자 인증에 대한 인증 정보를 포함하는 다른 IKE_AUTH 요청과 함께 장치 인증 IKE_AUTH 요청을 따른 후에, SGW(610)는 이전의 IKE_AUTH 요청 메시지(6)로부터의 정보를 유지하고, 이를 사용하여 종국의 인증 성공(또는 거부) 메시지를 H(e)NB(615)로 전송한다. SGW(610)는 SGW(610)가 검색한 H(e)NB(615)의 인증 프로필에 따라 7a 및 7b를 수행할 것이다.

H(e)NB 인증을 위해 이하의 인증이 필요하다. 첫째, H(e)NB 장치와 통신 사업자의 네트워크의 상호 인증이 행해질 필요가 있다. TrE에 저장된 자격 증명을 사용하는 인증 방법이 TrE의 내부에서 실행되어야만 한다. 이 상호 인증은 플랫폼 무결성(즉, TrE 속성)의 확인을 포함할 것이다(또는 그 확인에 밀접하게 바인딩되어 있을 것이다). 상호 인증의 2 부분은 이하의 속성을 가진다: 1) H(e)NB의 ID는 네트워크에 의해 인증되고, 이 인증을 위한 자격 증명은 H(e)NB 내의 TrE에 저장될 것이고, 2) 통신 사업자의 네트워크의 ID(예를 들어, SGW에 의해 표현됨)는 H(e)NB의 TrE에 의해 인증되고, 이 인증은 통신 사업자의 일반 네트워크를 인증하거나 H(e)NB와 연락되는 특정의 SGW를 인증할 수 있다. SGW의 ID는 TrE가 SGW로부터 전송된 메시지에서 SGW에 속하는 개인 암호 키의 사용을 식별하는 것에 의해 인증될 수 있으며, 여기서 이러한 개인 키는 TrE가 알고 있는데, 그 이유는 TrE가 참조할 수 있는 SGW 인증서에 보유되어 있기 때문이다. TrE는 이 SGW 인증서를 안전하게 저장 및 처리할 수 있다. SGW 인증서는 SGW로부터의 적당한 IKEv2 메시지 내에서 TrE로 전송될 수 있다. TrE는 루트 인증서로 사전 구성될 수 있고, 루트 인증서를 차후에 안전하게 저장 및 처리하고 이를 사용하여 SGW 인증서를 검증할 수 있다. 다른 대안으로서, TrE는 SGW 인증서를 검증하기 위해 OCSP(online certificate status protocol) 서버 등의 외부 인증 기관과 연락할 수 있다.

또한, 적용가능한 경우, 통신 사업자의 네트워크에 의한 호스팅 당사자의 인증이 필요하다. 호스팅 당사자의 ID는 통신 사업자의 네트워크에 의해 인증된다. 이 인증은 2가지 방식으로 수행될 수 있다: 1) 호스팅 당사자의 인증은 H(e)NB 내의 별도의 HPM(hosting party module)에 들어 있는 자격 증명에 기초하고 상호 인증을 통해 부가의 단계로서 수행되거나, 2) 호스팅 당사자의 인증이 장치 인증과 번들링된다(즉, 상호 인증 후에 부가의 인증 단계가 없음). 호스팅 당사자가 존재하지 않는 경우(예를 들어, 통신 사업자 자체가 H(e)NB를 제공하는 경우), 이 후자의 인증은 관련성이 없을 수 있다.

현재의 기본 보안 프로토콜이 H(e)NB와 코어 네트워크 간에 장치 및 호스팅 당사자 인증을 포함하는 보안 통신을 제공하더라도, 현재의 프로토콜은, H(e)NB 또는 그 안의 (선택적인) HPM에 관한 '인증' 정보만을 제공하고 다른 것은 제공하지 않는다는 점에서, 몇몇 문제점을 제기한다. H(e)NB가 비교적 안전하지 않은 물리적 환경(예를 들어, 사람들의 가정)에서 동작하도록 방치될 가능성이 있기 때문에, 기지의 암호를 사용하는 '인증'으로는 충분하지 않으며, 보안 프로토콜은, SGW에 액세스하는 통합 단계로서, TrE 및/또는 H(e)NB 또는 그의 구성요소들 중 임의의 것의 '예상된 상태'에 관한 정보를 명시적으로 사용할 필요가 있을 수 있다. 이 단계를 장치 확인 절차라고 한다.

구체적으로는, H(e)NB와 SGW 간의 인증 및 보안 연관 설정을 위해 IKEv2를 사용하는 보안 프로토콜은 H(e)NB 장비 ID(H(e)NB_EI) 및 호스팅 당사자 ID(H_ID) 이외의 어떤 정보도 포함하지 않는다. 이들 ID가 TrE 및 선택적 HPM 내에서 제각기 안전하게 보호되더라도, 확인되는 H(e)NB가 코어 네트워크와 상호작용하기 위해 신뢰될 수 있을 정도로, 확인의 점에서, 이들의 존재(및 무결성)가 충분하지 않을 수 있다.

그에 따라, 보안 프로토콜 또는 방법의 실시예가 개시된다.

일 실시예에서, 필수적 장치(및 선택적 호스팅 당사자) 인증에 대한 선행 요건은 부팅 시에 또한 어쩌면 런타임(스케쥴링되거나 이벤트-구동됨) 시에 TrE에 의한 통합 부팅 및 시스템 상태 달성이다.

다른 실시예에서, IKE_INIT 단계 동안 또는 그 후에, H(e)NB는, 적절한 IKEv2 페이로드[CP 또는 V 페이로드 또는 통지(N) 메시지 등]에서, 플랫폼으로서의 그의 신뢰성을 나타내는 정보를 전송한다. 이러한 정보는 인증서 또는 TrE, H(e)NB, 또는 HPM을 포함하는 임의의 구성요소(구성요소의 임의의 조합)의 예상된 상태, 또는 심지어 TrE 또는 H(e)NB의 기타 구성요소에 의해 수행되는 로컬 무결성 검사 프로세스를 통과하지 못한 구성요소의 목록을 기술하는 설명서를 포함할 수 있다. 이 정보는 TrE 내에서 보호되는 개인 키에 의해 서명될 수 있다.

다른 실시예에서, CA 또는 TTP[TrE 또는 H(e)NB 제조업체/공급자 등]에 의해 검증될 수 있는 인증서도 역시 [H(e)NB가 인증서를 SGW를 통해 HLR/AAA로 전송하는 것 또는 HLR/AAA가 인증서를 대역외 프로세스로부터 획득하는 것으로 가정하는 것에 의해] 배포될 수 있다. 이러한 인증서는 TrE 내에 보유된 개인 키에 대한 공개 키를 보증한다. 따라서, 개인 키의 사용은 TrE 또는 H(e)NB의 기타 부분이 손상되지 않은 채로 있다는 것을 의미할 것이다. IKEv2 교환 동안, H(e)NB는 또한 H(e)NB의 어느 구성요소가 신뢰성 또는 무결성에 대하여 확인되어야만 한다는 것을 코어 네트워크에게 알려줄 수 있다. 구성요소-관련 키가 TrE에서 특정의 구성요소의 유효성에 서명하고 그를 보증하는 데 사용될 수 있다. TrE 또는 H(e)NB의 임의의 다른 부분에 대한 인증서 또는 설명서가 프로토콜 자체에서 전달되는 경우, IKEv2 파라미터(CP 및 V 등)는 그 정보를 전달하는 데 사용될 수 있다. 이러한 정보는 다른 대안으로서 H(e)NB로부터 SGW로의 IKE_AUTH 요청 메시지에서의 통지(N) 필드에서 전달될 수 있다. 이러한 필드는 또한 TrE 또는 H(e)NB의 다른 부분에서 수행되는 임의의 장치 확인 및 무결성 검사의 프로세스, 엔티티, 및/또는 결과에 관한 정보를 포함할 수 있다. SK{ } 메커니즘에 의한 보호도 역시 고려될 수 있다.

다른 실시예에서, 인증서(프로토콜 시간에서 사전-배포되거나 교환됨)를 통해 또는 명시적인 메시징(어쩌면 무결성 및 기밀성을 위해 보호됨)을 통해, H(e)NB는 H(e)NB가 보장할 수 있는 통신의 종류, 액세스 및 응용 프로그램 특권(application privilege)을 코어 네트워크가 평가하는 데 유용할 것인 TrE 자체에 관한 정보를 SGW에게 그리고 SGW를 통해 코어 네트워크에게 알려준다. 다시 말하자면, 이러한 정보는 IKEv2에 포함될 수 있고 적합한 기존의 파라미터를 통해 전달될 수 있다.

다른 실시예에서, IKEv2와 다른 통신 프로토콜이 H(e)NB의 결합된 인증 및 장치 확인을 위해 사용될 수 있다. 이러한 프로토콜의 일례로는 TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, OMA(Open Mobile Alliance) DM(Device Management) 프로토콜, 또는 장치 인증 및 장치 확인 메시지가 결합된 방식으로 표시될 수 있는 TLS의 확장에 대한 어떤 적합한 IETF(Internet Engineering Task Force) RFC(Requests for Comment)가 있을 수 있지만, 이들로 제한되지 않는다.

개시된 인증 프로토콜 실시예에 따르면, 선행 요건 절차의 일부로서 또는 선행 요건 절차로서, TrE는 TrE와 H(e)NB의 다른 부분[MPU, HPM(포함된 경우), 셀룰러 모뎀 프로세서, 비셀룰러 모뎀 프로세서, 위치 확인/위치 결정 장치, 및/또는 클록/타이밍 장치를 포함함] 간에 보안 채널을 설정할 수 있다. 이러한 보안 채널의 설정의 증거는 이어서 TrE에 의해 보호되는 키를 사용하여 암호화된 보호 하에서, H(e)NB로부터 SGW를 통해 HLR/AAA로 전달될 것이다. HLR/AAA는 이어서 이러한 정보를 사용하여, H(e)NB 및/또는 호스팅 당사자 인증의 일부로서 또는 이 인증을 위한 선행 요건으로서 H(e)NB의 신뢰성을 평가할 수 있다.

다른 실시예에서, TrE는 응용 프로그램 또는 서비스 서버에 대한 응용 프로그램-계층 통신 액세스를 위해 H(e)NB 또는 그의 구성요소들(HPM, 위치 확인/위치 결정 장치, 또는 클록/타이밍 장치를 포함함) 중 임의의 것에 대한 특정의 시스템 상태를 정의하고 강제 적용하는 데 사용될 수 있다. 그에 따라, 보안 부팅된 TrE의 관리 하에서 TrE 및 H(e)NB의 임의의 다른 부분의 보안 부팅 이후에, H(e)NB가 '부팅'되고 '네트워크 레벨 보안 연관'을, IKEv2를 사용하여, HLR/AAA에 보관할 수 있다. 그렇지만, 그후에, TrE는 또한, 통신 사업자 또는 서비스 공급자 보안 정책 하에서, 특정 응용 프로그램 서버에 대한 응용 프로그램 또는 서비스-레벨 인증을 가능하게 해주기 전에, 그 자체 및/또는 H(e)NB의 임의의 다른 부분에 대한 부가의 '시스템 상태' 검사를 수행할 수 있다. 이러한 서비스는 OAM 서비스, 및 H(e)NB 위치 및/또는 참조 타이밍을 업데이트하는 서비스를 포함할 수 있다.

도 7에 관계도로 나타낸 다른 실시예에서, 보안 프로토콜은 또한 H(e)NB(705)의 신뢰성이 평가되고 (네트워크 및 응용 프로그램 액세스를 위한) H(e)NB(705)의 액세스 권한이 HLR/AAA(710) 또는 TCG(Trusted Computing Group) TNC(Trusted Network Connect) PDP(Policy Decision Point)로서 역할하는 코어 네트워크 엔티티에 의해 결정되는 절차를 포함할 수 있다. 이어서, TCG TNC PEP(Policy Enforcement Point)로서 역할하는 SGW(715)에 의해 액세스 제어 정책이 시행될 것이다. 따라서, H(e)NB(705)는 TCG TNC AR(Access Requestor)로서 역할할 것이다.

다른 실시예에서, 인증을 위한 보안 프로토콜 등의 보안 프로토콜과 관련하여, TNC AR로서 역할하는 H(e)NB는 그 자체적으로 또는 SGW 또는 HLR/AAA로부터의 요청에 의해 무결성 메트릭을 제공한다. 이어서, 이러한 무결성 메트릭은 SGW를 통해 HLR/AAA로 전달될 것이며, 여기서 HLR/AAA는 TCG TNC PEP로서 역할한다. H(e)NB로부터 수신된 무결성 메트릭이 요구된 "신뢰 레벨"을 만족시키는지를 판정할 때, HLR/AAA는 H(e)NB에게 부여될 네트워크 액세스의 레벨을 결정한다. 이러한 '레벨'은 서비스 범위, 대역폭, 트래픽 유형 및 양, H(e)NB에 대한 응용 프로그램 액세스, 및/또는 H(e)NB를 통해 코어 네트워크와 통신하는 임의의 WTRU의 세분화된 조합 등을 포함할 수 있다. 이어서, 정책 결정은 HLR/AAA로부터 SGW로 전달되고, SGW는 이어서 TNC PEP로서 역할하고 H(e)NB에 대해 부여된 액세스를 통제하는 HLR/AAA로부터의 액세스 제어 정책을 시행한다. 또한 이 예시적인 아키텍처에 대한 관련 TNC 사양(예를 들어, IF-M, IF-IMC, IF-IMV, IF-TNCCS, IF-T, 및 IF-PEP)이 도 7에 도시되어 있다.

장치 및/또는 호스팅 당사자 인증 프로토콜의 일부로서, H(e)NB의 위치는 물론 H(e)NB의 동작의 '이벤트 설명 또는 로그'가, SGW를 통해 H(e)NB로부터 HLR/AAA로 전달되는 정보의 일부로서 포함되는, H(e)NB 자신의 타이밍 함수에 의해 제공되는 TrE 및/또는 H(e)NB의 보안 부팅 이력의 타임-스탬프된 버전 등의, 로컬 타임-스탬프에 개시되어 있다. 이러한 위치 정보 및/또는 타임-스탬프된 '이벤트 설명 또는 로그' 정보가 TrE 내에 보호된 키로 암호화된다. 이어서, HLR/AAA는 H(e)NB_EI 또는 HPM_ID 뿐만 아니라 H(e)NB의 위치 및/또는 H(e)NB에 관한 타임-스탬프된 '이벤트 설명 및/또는 로그' 중 하나 이상을 포함하는 정보로 H(e)NB의 신뢰성을 평가한다.

상기 개시된 보안 프로토콜에서, CP 또는 V 등의 적합한 IKEv2 페이로드 또는 통지 메시지(N)는 H(e)NB와 코어 네트워크(및 SGW) 사이에서 부가의 정보를 전달하는 데 사용될 수 있다.

이제 도 8a 및 도 8b를 참조하면, EAP-AKA 기반 인증의 예시적인 신호도가 도시되어 있다. 도 8a 및 도 8b의 인증 프로토콜은 H(e)NB(805)에 대한 EAP-AKA 기반 장치 인증 프로토콜의 전체적인 보안을 보강하기 위해 TrE(810)의 강한 보안 속성을 사용한다. 유의할 점은, 장치 인증을 위해, 알파벳 문자(예를 들어, A, B, C 등)로 인덱싱된 단계들이 TrE(810)와 H(e)NB(805)의 다른 기능 간의 상호작용을 포함한다는 것이다.

장치 인증을 위한 선행 요건으로서, H(e)NB(805)는 그 자신을 신뢰성있는 플랫폼인 SGW(820)에 대해 확인할 필요가 있다(0). H(e)NB(805)는 H(e)NB(805)의 플랫폼 유효성의 암호적으로 보호된 증거를 안전하게 제공하기 위해 그의 TrE(810)에 의존하며, H(e)NB(805)는 이어서 이를 SGW(820)로 전달한다. SGW(820)는 증거를 평가하고 H(e)NB(805)가 장치 인증을 계속 수행할 수 있을 정도로 신뢰성있는지를 판정한다.

H(e)NB(805)는 IKE_SA_INIT 요청을 SGW(820)로 전송한다(1). SGW(820)는 IKE_SA_INIT 응답을 전송한다(2). H(e)NB(805)는, IKE_SA_INIT 응답을 TrE(810)에게 전달함으로써, TrE(810)에 HNB_ID를 요청한다(A). TrE(810)는 IKE_SA_INIT 응답의 무결성을 검사하고 HNB_ID로부터 IDi를 구성한다(B). TrE(810)는 IDi 페이로드 및 상태[예를 들어, TrE(810)에서 HNB_ID로부터 IDi를 구성하는 것을 완료했음을 나타냄]를 H(e)NB(805)에게 전송한다(C).

H(e)NB(805)는 IDi 페이로드를 SGW(820)로 전송하고, 자식 보안 연관(child security association)의 협상을 시작한다(3). H(e)NB(805)가 EAP 인증을 수행하고자 한다는 것을 SGW(820)에게 통보하기 위해 AUTH가 생략된다. H(e)NB(805)의 원격 IP 주소가 동적으로 구성될 필요가 있는 경우, 구성 페이로드가 이 메시지로 전달된다. H(e)NB(805)는 또한 SGW(820)에 인증서를 요청한다. 유의할 점은, IDi 페이로드에서 제시되는 NAI(network address identifier)에 의해 선택되는 사용자 프로필이 인증(인증서, EAP-AKA, 또는 인증서-EAP-AKA 다중 인증)의 선택을 강제 적용한다는 것이다.

SGW(820)는 IKE_AUTH 요청 메시지로 수신된 ID를 포함하는, 빈 EAP AVP(attribute value pair)를 가지는 인증 요청 메시지를 AAA 서버(830)로 전송한다(4). 필요한 경우, AAA 서버(830)는 HSS/HLR(840) 또는 어떤 다른 인증 엔티티로부터 장치 프로필 및 인증 벡터를 가져올 것이다(5). AAA 서버(830)는 이어서 인증 챌린지(authentication challenge)를 시작한다(6).

SGW(820)는 IKE_AUTH 응답을 H(e)NB(805)로 전송한다(7). IKEv2를 통해 EAP 절차를 시작하기 위해 AAA 서버(830)로부터 수신된 EAP 메시지(EAP-요청/AKA-챌린지)가 포함된다. H(e)NB의 TrE(810)가 SGW(820)의 인증서에 기초하여 SGW(820)를 인증할 필요가 있는 경우, SGW(820) ID, 인증서, 및 (IKE_SA_INIT 교환에서) 이전의 메시지를 보호하는 데 사용되는 AUTH 파라미터가 이 메시지를 통해 H(e)NB(805)로 전송된다.

SGW(820) 인증 및 인증 챌린지에 대한 응답을 계산하는 데 필요한 자료가 TrE(810)로 전달된다(D). TrE(810)는 RAND, AUTN으로부터 RES를 계산하고, H(e)NB(805)가 SGW(820)의 인증서에 기초하여 SGW(820)를 인증할 필요가 있는 경우 선택적으로 인증 파라미터를 검사한다(E). SGW(820) 인증의 성공 시에, TrE(810)는, 선택적인 상태 메시지와 함께, RES를 H(e)NB(805)로 전달한다(F).

H(e)NB(805)는 인증 챌린지에 응답한다(8). IKEv2 메시지 내의 유일한 페이로드(헤더와 별개임)는 EAP 메시지이다. SGW(820)는 EAP-응답/AKA-챌린지 메시지를 AAA 서버(830)로 전달한다(9). 모든 검사가 성공적일 때, AAA 서버(830)는 EAP 성공 및 키 자료를 포함하는 인증 답변을 SGW(820)로 전송한다(10). 이 키 자료는 인증 프로세스 동안 발생되는 MSK(master session key)로 이루어져 있을 것이다.

MSK는 IKE_SA_INIT 단계 메시지를 인증하기 위해 SGW(820)에서 AUTH 파라미터를 발생하는 데 사용될 것이다(11). EAP 성공 메시지는 IKEv2를 통해 H(e)NB(805)로 전달된다(12). EAP 성공 메시지는 TrE(810)로 전달된다(G). TrE(810)는 그 자신의 MSK 사본을 입력으로서 사용하여, 제1 IKE_SA_INIT 메시지를 인증하기 위한 AUTH 파라미터를 발생한다(H). 이어서, TrE(810)는 AUTH를 H(e)NB(805)로 전달한다(I).

H(e)NB(805)는 IKE_AUTH 요청을 구성하고 이를 AUTH 파라미터와 함께 SGW(820)로 전송한다(13). 이어서, SGW(820)는 H(e)NB(805)로부터 수신된 AUTH가 올바른지를 검사하고, 제2 IKE_SA_INIT 메시지를 인증하는 AUTH 파라미터를 계산한다. H(e)NB(805)가 CFG_REQUEST를 통해 원격 IP 주소를 요청한 경우, SGW(820)는 구성 페이로드(CFG_REPLY)로 할당된 원격 IP 주소를 전송할 것이다. 이어서, AUTH 파라미터가 구성 페이로드, 보안 연관 및 나머지 IKEv2 파라미터와 함께 H(e)NB(805)로 전송되고, IKEv2 협상이 종료된다(14).

그 H(e)NB(805)에 대한 이전의 IKA SA가 이미 존재한다는 것을 SGW(820)가 검출하는 경우, SGW(820)는 IKA SA를 삭제하고, H(e)NB(805) 내의 이전의 IKA SA를 삭제하기 위해 H(e)NB(805)에게 INFORMATIONAL exchange with a Delete 페이로드를 전송한다(15).

다른 실시예에서, 도 9를 참조하여 나타낸 바와 같이, 장치 인증을 위한 프로토콜은 인증서에 기반할 수 있다. IKEv2 인증서-기반 상호 인증이 RFC- 4306 IKEv2(Internet Key Exchange) 프로토콜에 따라 실행된다. 인증서 처리 및 프로필은 주어진 규격을 준수할 수 있지만, 정식 인증서 등록 및 해지 프로세스를 구현하는 것의 복잡성 및 보다 간단한 대안의 이용가능성(만료 또는 장치의 장치 인증서에서의 다른 문제로 인해 인증 검사를 통과하지 못한 장치를 처리하는 데 블랙리스트 또는 화이트리스트를 사용하는 것 등) 둘다로 인해 인증서 등록 및 인증서 해지가 필요하지 않을 수 있다. 유의할 점은, 장치 인증을 위해, 도 9에서의 알파벳 문자(예를 들어, A, B, C 등)로 인덱싱된 단계들이 TrE(910)와 H(e)NB(905)의 다른 기능 간의 상호작용을 포함한다는 것이다.

EAP-AKA 기반 장치 인증을 위한 선행 요건으로서, H(e)NB(905)는 그 자신을 신뢰성있는 플랫폼인 SGW(920)에 대해 확인할 필요가 있다(0). H(e)NB(905)는 H(e)NB(905)의 플랫폼 유효성의 암호적으로 보호된 증거를 안전하게 제공하기 위해 그의 TrE(910)에 의존하며, H(e)NB(905)는 이어서 이를 SGW(920)로 전달한다. SGW(920)는 증거를 평가하고 H(e)NB(905)가 장치 인증을 계속 수행할 수 있을 정도로 신뢰성있는지를 판정한다.

H(e)NB(905)는 IKE_SA_INIT 요청을 SGW(920)로 전송한다(1). SGW(920)는 IKE_SA_INIT 응답을 전송하여, H(e)NB(905)에 인증서를 요청한다(2). H(e)NB(905)는, IKE_SA_INIT 응답을 TrE(910)에게 전달함으로써, TrE(910)에 HNB_ID를 요청한다(A). TrE(910)는 IKE_SA_INIT 응답의 무결성을 검사하고, HNB_ID로부터 IDi를 구성하며, 장치 CERT를 가져오고, 장치 CERT를 사용하여 AUTH를 계산한다(B). TrE(910)는 IDi, AUTH, CERT 및 상태[예를 들어, TrE(910)에서 HNB_ID로부터 IDi를 구성하는 것, AUTH를 계산하는 것, CERT를 검색하는 것 등을 완료했음을 나타냄]를 H(e)NB(905)에게 전송한다(C).

H(e)NB(905)는 IDi 페이로드를 전송하고, 자식 보안 연관의 협상을 시작한다(3). H(e)NB(905)는 또한 AUTH 페이로드, 그 자신의 인증서, 및 SGW(920)에 대한 인증서의 요청을 전송한다. H(e)NB(905)의 원격 IP 주소가 동적으로 구성될 필요가 있는 경우, 구성 페이로드가 이 메시지로 전달된다. IDi 페이로드에서 제시되는 NAI(network address identifier)에 의해 선택되는 사용자 프로필이 인증(인증서, EAP-AKA, 또는 인증서-EAP-AKA 다중 인증)의 선택을 강제 적용한다.

SGW(920)는 H(e)NB(905)로부터 수신된 AUTH가 올바른지를 검사하고, 제2 IKE_SA_INIT 메시지를 인증하는 AUTH 파라미터를 계산한다(4). SGW(920)는 H(e)NB(905)로부터 수신된 인증서를 검증한다. SGW(920)는 AUTH 파라미터 및 그의 인증서를 구성 페이로드, 보안 연관 및 나머지 IKEv2 파라미터와 함께 H(e)NB(905)로 전송하고, IKEv2 협상이 종료된다(5). H(e)NB(905)가 CFG_REQUEST를 통해 원격 IP 주소를 요청한 경우, 원격 IP 주소가 구성 페이로드(CFG_REPLY)에서 할당된다.

H(e)NB(905)는 SGW(920)의 인증서를 TrE(910)로 전달한다(D). TrE(910)는 그의 안전하게 저장된 루트 인증서로 SGW(920)의 인증서를 검증한다(E). H(e)NB(905)는 또한 SGW(920)의 인증서를 확인할 수 있다. TrE(910)는 SGW CERT 검증의 상태를 H(e)NB(905)로 전달한다(F). 그 H(e)NB(905)에 대한 이전의 IKA SA가 이미 존재한다는 것을 SGW(920)가 검출하는 경우, SGW(920)는 IKA SA를 삭제하고, H(e)NB(905) 내의 이전의 IKA SA를 삭제하기 위해 H(e)NB(905)에게 INFORMATIONAL exchange with a Delete 페이로드를 전송한다(6).

인증서-기반 장치 인증과 그에 뒤이은 호스팅 당사자 인증의 결합이 이용될 수 있으며, 여기서 TrE 및 HPM(예를 들어, UICC) 둘다는 나머지 H(e)NB 및 SGW와 상호작용해야만 한다. 상세하게는, TrE는 호스팅 당사자 또는 장치의 인증을 위해 HPM이 발생하거나 수신하는 임의의 정보를 보호할 수 있다. 게다가, HPM이 인증 프로토콜 동안 수신하거나 전송하는 임의의 정보가 보안 채널에 의해 보호될 수 있도록, TrE는 HPM과 보안 채널을 설정할 수 있다.

도 10a 및 도 10b는 결합된 EAP-AKA 및 인증서 기반 인증의 신호도의 일 실시예를 나타낸 것이다. 이 결합된 인증 절차를 위해, 도 10a 및 도 10b에서의 알파벳 문자(예를 들어, A, B, C 등)로 인덱싱된 단계들이 TrE(1010)와 H(e)NB(1050)의 다른 기능[HPM(1050)을 포함함] 간의 상호작용을 포함한다.

신호 흐름은 H(e)NB(1005)와 SGW(1020) 간의 인증서 기반 상호 인증 이후에 H(e)NB(1005)와 AAA 서버(1030) 간의 EAP-AKA AUTH 교환이 있다는 것을 보여준다. 먼저, H(e)NB(1005)는 IKE_SA_INIT 요청을 SGW(1020)로 전송한다(1). SGW(1020)는 IKE_SA_INIT 응답을 전송하여, H(e)NB(1005)에 인증서를 요청한다(2). SGW(1020)는 MULTIPLE_AUTH_SUPPORTED 페이로드를 포함시킴으로써 다중 인증을 지원한다는 것을 알려준다.

H(e)NB(1005)는 자식 보안 연관의 협상을 시작한다(3). 먼저, H(e)NB(1005)는 TrE(1010)에게 (HeNB_EI로부터) IDi 페이로드를 구성하고 암호화된 패키지를 계산하여 이를 자신에게 전달하라고 요청한다:

SK(SA, TSi, TSr, IDi=NAI, IDr, CP(CFG_REQUEST), AUTH, CERTREQ, CERT, N(MULTIPLE_AUTH_SUPPORTED) , N(ANOTHER_AUTH_FOLLOWS)}

H(e)NB(1005)는 헤더(HDR) 및 암호화된 페이로드 SK{...}로 이루어져 있는 IKE_AUTH 요청을 SGW(1020)에게 전달한다. 암호화된 페이는 AUTH 페이로드, H(e)NB(1005) 자신의 인증서, 또한 SGW(1020)에 대한 인증서의 요청을 포함한다. H(e)NB(1005)의 원격 IP 주소가 동적으로 구성될 필요가 있는 경우, 구성 페이로드가 이 메시지로 전달된다. H(e)NB(1005)는, MULTIPLE_AUTH_SUPPORTED 및 ANOTHER_AUTH_FOLLOWS 속성을 포함시킴으로써, 다중 인증을 지원한다는 것과 제2 인증을 하고자 한다는 것을 알려준다. IDi 페이로드에서 제시되는 NAI에 의해 선택되는 사용자 프로필이 인증(인증서, EAP-AKA, 또는 인증서-EAP-AKA 다중 인증)의 선택을 강제 적용한다.

SGW(1020)는 H(e)NB(1005)로부터 수신된 AUTH가 올바른지를 검사하고, 제2 IKE_SA_INIT 메시지를 인증하는 AUTH 파라미터를 계산한다(4). SGW(1020)는 H(e)NB(1005)로부터 수신된 인증서를 검증한다. SGW(1020)는 AUTH 파라미터 및 그의 인증서를 H(e)NB(1005)로 전송한다(5).

H(e)NB(1005)는 암호화된 페이로드 SK(IDr, AUTH, SGW Certi}를 TrE(1010)로 전달하고, TrE(1010)는 페이로드를 복호화하여 IDr, AUTH, 및 SGW Certi를 추출한다. 이어서, TrE(1010)는 그의 저장된 루트 인증서로 SGW(1020)의 인증서를 검증한다(6). H(e)NB(1005)는 또한 SGW(1020)의 인증서를 확인할 수 있는데, 왜냐하면 그것이 통신 사업자의 제어 하에 있기 때문이다.

H(e)NB(1005)는 TrE(1010)에게 다른 IKE_AUTH 요청 메시지의 암호화된 부분을 형성하라고 요청하며, 여기서 H(e)NB(1005)가 EAP 인증을 수행하고자 한다는 것을 SGW(1020)에게 알려주기 위해 AUTH 페이로드가 생략된다(7). 암호화된 부분은 SK(IDi=NAI, IDr}이다. 이어서, H(e)NB(1005)는 헤더(HDR)를 준비하고, HDR, SK(IDi=NAI, IDr}를 SGW(1020)로 전송한다.

SGW(1020)는 IKE_AUTH 요청 메시지로 수신된 ID를 포함하는, 빈 EAP AVP를 가지는 인증 요청 메시지를 AAA 서버(1030)로 전송한다(8). AAA 서버(1030)는 HSS/HLR(home subscriber server/home location register)(1040)로부터 사용자 프로필 및 인증 벡터를 가져올 것이다(9). AAA 서버(1030)는 인증 챌린지를 시작한다(10).

SGW(1020)는 IKE_AUTH 응답을 H(e)NB(1005)로 전송한다(11). IKEv2를 통해 EAP 절차를 시작하기 위해 AAA 서버(1030)로부터 수신된 EAP 메시지(EAP-요청/AKA-챌린지)가 포함된다. H(e)NB(1005)가 SGW(1020)의 인증서에 기초하여 SGW(1020)를 인증할 필요가 있는 경우, SGW(1020) ID, SGW 인증서, 및 (IKE_SA_INIT 교환에서) H(e)NB(1005)로 전송했던 이전의 메시지를 보호하는 데 사용되는 AUTH 파라미터가 이 메시지에 포함된다.

TrE(1010)는 먼저 보안 연관(SA)을 교환함으로써 HPM(1050)으로의 보안 채널을 설정한다. 이러한 보안 채널 설정의 결과로서, TrE(1010)는 물론 HPM(1050)은 이어서 둘다 RAND 및 AUTN을 사용하여 인증 세션에 바인딩된다. 이어서, TrE(1010)는 인증 챌린지를 HPM(1050)으로 전달한다(A).

HPM(1050)은 AKA 응답(RES)을 계산한다(B). HPM(1050)은 AKA 응답(RES)을 보안 채널을 통해 TrE(1010)로 전송한다(C).

H(e)NB(1005)는 인증 챌린지에 응답한다(12). IKEv2 메시지 내의 유일한 페이로드(헤더와 별개임)는, HPM(1050)에서 계산된 다음에 IKEv2를 통해 TrE(1010)에서 암호화된 다음에 H(e)NB(1005)로 전달되는 RES를 포함하는 EAP 메시지이다. H(e)NB(1005)가 SGW(1020)의 인증서에 기초하여 SGW(1020)를 인증할 필요가 있는 경우, H(e)NB(1005)는 인증 파라미터를 검사한다.

SGW(1020)는 EAP-응답/AKA-챌린지 메시지를 AAA 서버(1030)로 전달한다(13). 모든 검사가 성공적일 때, AAA 서버(1040)는 EAP 성공 및 키 자료를 포함하는 인증 답변을 SGW(1020)로 전송한다(14). 이 키 자료는 인증 프로세스 동안 발생되는 MSK로 이루어져 있을 것이다. MSK는 IKE_SA_INIT 단계 메시지를 인증하기 위해 SGW(1020)에서 AUTH 파라미터를 발생하는 데 사용될 것이다(15). EAP 성공 메시지는 IKEv2를 통해 H(e)NB(1005)로 전달된다(16).

H(e)NB(1005)는 암호화된 EAP 성공 메시지[즉, SK{EAP 성공 메시지}]를 TrE(1010)로 전달한다(17). TrE(1010)는 그 자신의 MSK 사본을 입력으로서 받아서, 제1 IKE_SA_INIT 메시지를 인증하기 위한 AUTH 파라미터를 발생한다. AUTH 파라미터는, IKEv2를 통해 암호화되어, TrE(1010)로부터 H(e)NB(1005)로 전송된다. H(e)NB(1005)는 암호화된 AUTH 파라미터를 SGW(1020)로 전송한다.

SGW(1020)는 H(e)NB(1005)로부터 수신된 AUTH를 복호화하여 그것이 올바른지를 검사하고, 제2 IKE_SA_INIT 메시지를 인증하는 AUTH 파라미터를 계산한다(18). H(e)NB(1005)가 CFG_REQUEST를 통해 SGW(1020)에게 원격 IP 주소를 요청한 경우, SGW(1020)는 구성 페이로드(CFG_REPLY)로 할당된 원격 IP 주소를 전송할 것이다. 이어서, AUTH 파라미터가 구성 페이로드, 보안 연관 및 나머지 IKEv2 파라미터와 함께 H(e)NB(1005)로 전송되고, IKEv2 협상이 종료된다.

그 H(e)NB(1005)에 대한 이전의 IKA SA가 이미 존재한다는 것을 SGW(1020)가 검출하는 경우, SGW(1020)는 IKA SA를 삭제하고, H(e)NB(1005) 내의 이전의 IKA SA를 삭제하기 위해(19) H(e)NB(1005)에게 삭제 페이로드와의 INFORMATIONAL exchange with a Delete 페이로드를 전송한다.

인증 절차 동안 H(e)NB TrE, HPM 및 H(e)NB 자체를 바인딩하는 것이 이용될 수 있다. 어떤 가정이 행해진다. 대부분의 장비가 고유 ID를 갖는 것으로 주어진다. 예를 들어, H(e)NB_EI는 H(e)NB의 제조업체에 의해 할당되고, TrE_ID는 TrE의 제조업체에 의해 할당되며, HPM_ID는 HPM의 제조업체에 의해 할당된다. 또한, 통신 사업자의 코어 네트워크를 나타내는 SGW가 H(e)NB와 상호 인증을 수행한다는 것을 잘 알 것이다. HLR/AAA 서버가 H(e)NB에 대한 HLR(Home Location Register)은 물론 인증 센터도 포함한다는 것은 알려져 있다. HLR은 TrE, H(e)NB 및 HPM의 바인딩 관계를 그 각자의 ID(즉, TrE_ID, H(e)NB_EI, 및 HPM_ID)를 사용하여 표현하는, 모든 HPM_ID에 대응하는 H(e)NB_EI 및 TrE_ID의 기록을 저장한다. AAA 서버는 이들 기록에 기초하여 바인딩 인증(binding authentication)을 수행한다.

3개의 ID를 바인딩하는 방법의 실시예가 개시된다. H(e)NB는 H(e)NB_EI, TrE_ID 및 선택적인 HPM_ID를 SGW로 전달한다. SGW는 H(e)NB로부터 수신하는 H(e)NB_EI를 HLR/AAA 서버로 전달한다. HLR/AAA 서버는 그의 기록에 있는 H(e)NB_EI에 대응하는 TrE_ID 및 HPM_ID를 찾는다. HLR의 기록에서 찾아낸 TrE_ID 및 HPM_ID가 SGW가 H(e)NB로부터 수신한 것과 동일한 경우, H(e)NB가 TrE 및 HPM에 바인딩하는 적법한 장비라는 것이 확인될 수 있다.

이하에 기술되는 프로토콜에 의해 전달되는 인증 주장의 신뢰성을 위해, 모든 민감한 데이터가 TrE 및 HPM에 의해 보호된 채로 있을 수 있다. 상세하게는, H(e)NB 및 H(e)NB_EI의 바인딩 인증을 나타내는 H(e)NB의 인증 암호(authentication secret)가 TrE에 안전하게 저장되어 있을 수 있다. TrE는 또한 TrE_ID를 안전하게 저장할 수 있다. 게다가, HPM_ID 및 대응하는 인증 암호도 역시 HPM에 안전하게 저장되어 HPM에 의해서만 처리될 수 있다. 이 데이터를 TrE 또는 HPM으로부터 SGW로 전송하는 데 보안 채널이 사용될 수 있다.

도 11은 3-웨이 바인딩 인증(three-way binding authentication)의 일 실시예를 나타낸 것이다. 먼저, TrE(1110)는 안전하게 보유하고 있는 TrE_ID 및 H(e)NB_EI를 검색한다(1). 이어서, TrE(1110)는 AKA RAND 및 AUTN을 사용하여 HPM(1120)과 보안 채널을 설정한다(2). TrE(1110)는 HPM(1120)에 HPM_ID를 요청하여 수신한다(3). HPM_ID가 보안 채널을 통해 전송되고 보안 채널 하에서 보호된다(4). 이어서, TrE(1110)는 TrE_ID, H(e)NB_EI 및 HPM_ID를 SGW(1130)로 전달한다(5).

SGW(1130)는 TrE_ID, H(e)NB_EI 및 HPM_ID를 HLR/AAA(1140)로 전달한다(6). 이들 ID를 수신한 후에, HLR/AAA(1140)의 HLR 부분은 TrE_ID 및 HPM_ID에 대응하는 H(e)NB_EI를 탐색한다(7). 이어서, HLR/AAA(1140)의 AAA 부분은 SGW(1130)로부터 수신한 H(e)NB_EI를, TrE_ID 및 HPM_ID에 대응한 H(e)NB_EI로 검증한다. 이어서, HLR/AAA(1140)의 HLR 부분은 TrE(1110) 및 HPM(1120)에 대한 바인딩 인증을 SGW(1130)로 전송한다(9). 그 다음에, SGW(1130)는 TrE(1110) 및 HPM(1120)에 대한 바인딩 인증을 TrE(1110)로 전달한다(10). TrE(1110)는 HPM(1120)에 대한 바인딩 인증을 보안 채널을 통해 HPM(1120)으로 전달한다(11).

TrE가 H(e)NB에 밀접하게 통합되어 있을 때(예를 들어, TrE가 H(e)NB 상의 칩일 때 등), TrE를 H(e)NB에 명시적으로 바인딩할 필요가 없을 수 있는데, 그 이유는 TrE가 H(e)NB_EI에 물리적으로 바인딩될 것이기 때문이다. 이 경우에, H(e)NB와 HPM 사이에 2-웨이 바인딩이 달성될 수 있다. 사실상, 이 경우에, H(e)NB의 ID는 TrE의 ID의 인증에 의해 인증될 수 있다(즉, H(e)NB_EI가 TrE_ID와 동일함).

도 12는 2-웨이 바인딩 인증(two-way binding authentication)의 일 실시예를 나타낸 것이다. 먼저, TrE(1210)는 안전하게 보유하고 있는 H(e)NB_EI를 검색한다(1). 유의할 점은, H(e)NB_EI가 TrE_ID와 동일하다는 것이다. TrE(1210)는 AKA RAND 및 AUTN을 사용하여 HPM(1220)과 보안 채널을 설정한다(2). 그 다음에, TrE(1210)는 보안 채널 하에서 HPM에 HPM_ID를 요청하여(3) 수신한다(4). 이어서, TrE(1210)는 H(e)NB_EI 및 HPM_ID를 SGW(1230)로 전달한다(5).

SGW(1230)는 H(e)NB_EI 및 HPM_ID를 HLR/AAA(1240)로 전달한다(6). 이어서, HLR/AAA(1240)의 HLR 부분은 HPM_ID에 대응하는 H(e)NB_EI를 탐색한다(7). 이어서, HLR/AAA(1240)의 AAA 부분은 SGW(1230)로부터 수신한 H(e)NB_EI를, HPM_ID에 대응한 그의 기록 내의 H(e)NB_EI와 비교함으로써 검증한다(8). 이어서, HLR/AAA(1240)의 HLR 부분은 TrE(1210) 및 HPM(1220)에 대한 바인딩 인증[이 경우에 H(e)NB를 인증하는 것과 동등함]을 SGW(1230)으로 전송한다(9). 그 다음에, SGW(1230)는 TrE(1210)[H(e)NB에 대해 동등함] 및 HPM(1220)에 대한 바인딩 인증을 H(e)NB의 TrE(1210)로 전달한다(10). TrE(1210)는 HPM(1220)에 대한 바인딩 인증을 보안 채널 하에서 보호된 채로 HPM(1220)으로 전달한다(11).

도 13은 인증 및 장치 확인이 결합된 방식으로 수행되는 방법의 일 실시예를 나타낸 것이다. 이 실시예에서, 장치 확인과 장치 인증을 결합시키는 데 IKEv2 프로토콜이 사용된다. 그렇지만, 장치 또는 장비의 인증에 사용되는 다른 프로토콜로는 TLS(transport layer security), HTTPS(Hypertext Transfer Protocol Secure), OMA DM, TR069 등이 있지만, 이들로 제한되지 않는다.

먼저, H(e)NB(1310)의 TrE는 보안 부팅을 수행하고, H(e)NB(1310)의 무결성을 검사한다(1). 이어서, H(e)NB(1310)는 IKEv2 세션을 시작하고, IKE_SA_INIT 요청 메시지를 SGW(1320)로 전송하며, 여기서 이 메시지는 HDR, SA(security association), KE(Diffie-Hellman key element), 및 Ni(initiator nonce)를 포함한다(2). 이 신호의 수신 시에, SGW(1320)는 HDR, SA, KE, Nr(respondent nonce), 및 CERTREQ(장치 인증서에 대한 요청임)를 포함하는 IKE_SA_INIT 응답을 H(e)NB(1310)로 전송한다(3). 양 단부에서 KE를 사용하여, H(e)NB(1310) 및 SGW(1320)는 이제 각각 IKEv2 세션 동안 추가의 메시지 교환의 기밀성 및 무결성 보호를 위해 사용할 암호 키(cryptographic key)를 발생한다.

이어서, H(e)NB(1310)는 IKE_AUTH 요청 메시지를 SGW(1320)로 전송하며, 여기서 이 메시지는 기밀성 및 무결성을 위해 Diffie-Hellman 발생 키에 의해 보호된다(4). 메시지의 내용은 보호되지 않는 HDR(header)와 보호된 부분을 포함하며, 이 보호된 부분은 SA(security association, 보안 연관), TSi(traffic selector of the initiator, 개시자의 트래픽 선택기), TSr(traffic selector of the respondent, 응답자의 트래픽 선택기), IDi(NAI 형식으로 된, H(e)NB(1310)의 ID], IDr[SGW(1320)의 ID], 및 CP(configuration parameter, 구성 파라미터), H(e)NB(1310)에 의해 수행되는 장치 무결성 검사의 결과 또는 프로세스를 나타내는 데이터(여기서 VAL_DATA라고 함)를 포함하는 통지 메시지, H(e)NB(1310)의 TrE가 H(e)NB가 유효한 장치 인증서를 보유하고 있다는 증거로서 계산하는 AUTH 파라미터, CERTREQ(서버측 인증을 위해 사용될 서버측 인증서에 대한 요청임), 및 CERT[SGW(1320)가 H(e)NB(1310)를 인증하기 위해 사용하는 장치 인증서임]를 포함한다.

이 메시지의 수신 시에, SGW(1320)는 이어서 장치 무결성 검사 데이터(VAL_DATA)를 추출하고 이를 확인 엔티티(1330)로 전송하고(5), 확인 엔티티는 이어서, 전달된 VAL_DATA 및 그가 가지고 있을 수 있는 임의의 다른 참조 정보를 사용하여, H(e)NB(1310)의 신뢰성 또는 무결성을 평가하며(6), 이어서 H(e)NB(1310)가 장치 무결성 관점에서 볼 때 올바른 것이라고 평가하는 경우에, 확인 응답 신호를 다시 SGW(1320)로 전송한다(7). 확인 엔티티(1330)로부터 긍정적 확인 응답을 수신할 시에, SGW(1320)는 이어서 H(e)NB(1310)로부터 수신했던 H(e)NB의 인증서(CERT)를 검증하고 이 인증서가 H(e)NB(1310)를 인증할 수 있는지를 검사할 수 있다(8). 그러한 경우, SGW(1320)는 HDR(보호되지 않은 헤더) 및 보호된 부분[AUTH(그 자신의 서버측 인증 증거임), CP, SA, TSi, 및 TSi를 포함함]을 포함하는 IKE_AUTH 응답 메시지를 전송할 수 있다(9).

다른 대안으로서, SGW(1320)와 확인 엔티티(1330) 간의 VAL_DATA를 검사하는 단계는, SGW(1320)가 H(e)NB의 인증서를 검증하고 H(e)NB(1310)를 인증하며 IKE_AUTH 응답 메시지를 H(e)NB(1310)로 전송한 후에, 행해질 수 있다.

이어서, H(e)NB(1310)는, IKE_AUTH 응답 메시지의 수신 시에, SGW(1320)로부터 수신한 서버 CERT를 사용하여 검증할 수 있다.

TrE는 또한 H(e)NB 인증을 위해 위치 정보를 사용하는 것에 대한 보안을 보장할 수 있다. 먼저, H(e)NB의 TrE는 위치 정보 처리(검색, 저장, 보호, 및 인증 시의 사용을 포함함)의 보안을 보호하기 위해 몇가지 기능을 수행할 수 있다. 보다 구체적으로는, 본 명세서에 기술된 위치 확인 방법들 중 임의의 것에 의해 인증된 임의의 위치 정보가 신뢰할 수 있는 방식으로 저장되고 처리될 수 있다. 이것은 이러한 정보가 H(e)NB TrE의 보호 하에서 저장되고 처리될 수 있다는 것을 의미한다. 보다 구체적으로는, H(e)NB TrE는 암호적으로 보호된 위치 정보를 이러한 정보의 소스로부터 수신할 수 있다. H(e)NB TrE는 또한 이러한 암호화된 위치 정보를 안전하게 복호화할 수 있다. 게다가, H(e)NB TrE는, TrE에 또는 외부에 저장되어 있는 동안, TrE 내부에 안전하게 저장된 키를 사용하는 암호적 보호(cryptographic protection)에 의해 위치 정보를 안전하게 보호할 수 있다. TrE는 TrE 내부에 또는 외부 메모리로부터 보유된 위치 정보를 추출할 수 있다. TrE는 위치 정보를 SGW로 전달하기 전에 암호화함으로써 위치 정보를 보호할 수 있다. TrE는, 장치 인증 프로토콜에 포함시키기 위해, 암호화된 위치 정보를 SGW로 전달할 수 있다.

또한, 위치 등록(또는 증명) 프로세스 또는 위치 인증 프로세스 동안, H(e)NB TrE는, 암호적 수단을 사용하여, H(e)NB가 HLR로 전송하는 위치 정보의 무결성 및/또는 기밀성을, 이러한 정보가 HLR로 전송 중인 동안, 보호할 수 있다. H(e)NB TrE는 또한 H(e)NB가 HLR로부터 수신하는 임의의 암호적으로 보호된 위치-관련 정보의 안전한 암호적 처리(복호화 및 무결성 검사를 포함함)를 제공할 수 있다. H(e)NB에서 이들 목적을 위해 사용되는 임의의 암호 키는 H(e)NB TrE에 의해 보호될 수 있다. 게다가, H(e)NB TrE는 또한 민감한 위치 정보를 획득, 저장 및 처리하는 것에 관계되어 있는 H(e)NB 내에서의 기능의 신뢰성 및 선택적으로 무결성을 보장할 수 있다.

선택된 특정의 위치 정보에 기초한 위치 등록 및 위치 인증의 실시예가 본 명세서에 개시되어 있다.

H(e)NB는 어떤 액세스 장치(예를 들어, DSL 모뎀, 케이블 모뎀, 홈 라우터 등)를 통해 IP 네트워크에 연결될 수 있고, 광대역 액세스 공급자에 의해 할당된 IP 주소를 가질 수 있다. 광대역 액세스 네트워크의 물리적 포트를 지리적 정보와 바인딩함으로써, 통신 사업자는 H(e)NB의 위치를 확인할 수 있다.

할당된 IP 주소, 사용자 ID, 및 IP 주소와 관계된 위치 정보는, H(e)NB 위치 정보의 초기 등록 후에, 네트워크 데이터베이스에 저장된다. 코어 네트워크(CN)는 IP 주소, IP 주소와 바인딩된 포트 번호(들), 및/또는 주소 정보(심지어 경도 및 위도 값)를 획득하기 위해 네트워크 데이터베이스에 쿼리할 수 있다. 위치 로킹 메커니즘은 1) H(e)NB 위치 정보의 등록, 및 2) H(e)NB 위치의 인증으로 이루어져 있다.

H(e)NB가 처음으로 켜지고 IP 백홀을 통해 코어 네트워크에 연결될 때 위치 등록이 행해진다. 먼저, H(e)NB는 이 메시지에 자신의 IP 주소를 담고 있는 요청 메시지를 HLR로 전송한다. 이어서, HLR은 수신된 IP 주소를 담고 있는 위치 정보 쿼리 메시지를 네트워크 데이터베이스로 전송한다. IP 주소에 기초하여, 데이터베이스는 테이블을 쿼리하여 상기 H(e)NB의 액세스 회선 위치 정보[IP 주소와 바인딩된 포트 번호와, 심지어 경도 및 위도(이용가능한 경우) 등]를 획득한다. 이어서, HLR은 획득된 정보에 기초하여 HLR의 위치를 결정한다. 이어서, HLR은 이 H(e)NB의 위치를 등록한다. 이어서, HLR은 응답 메시지로 H(e)NB에 답신한다. 위치 등록 후에, HLR은 위치를 H(e)NB 프로필의 속성으로서 저장할 수 있고, 이를 위치 판단 기준으로서 취급할 수 있다.

H(e)NB가 액세스 네트워크에 요청할 때마다 위치 인증이 행해진다. 따라서, 등록이 필요없다. 먼저, H(e)NB는 그의 IP 주소를 담고 있는 액세스 요청 메시지를 HLR로 전송한다. H(e)NB의 TrE는 이러한 IP 주소 정보가 전송 중인 동안, 그 자체로 보호되는 암호 키를 사용하여, 이러한 IP 주소 정보의 무결성 및/또는 기밀성을 보호할 수 있다. 모든 암호 처리는 TrE 내에서 행해질 수 있다.

H(e)NB의 IP 주소를 수신할 시에, HLR은 먼저 IP 주소의 무결성을 검사하고, 검사한 경우, 위치 정보를 획득하기 위해 또다시 데이터베이스에 쿼리한다. 이어서, HLR은 H(e)NB로부터 획득한 액세스 회선 위치 정보가 동일한 H(e)NB에 대한 그의 데이터베이스로부터 검색한 위치 정보에 대응하는지를 인증한다. 동일한 경우, HLR은 H(e)NB에 대한 기존의 위치를 그의 데이터베이스에 유지한다.

HLR은 응답 메시지에서 위치 인증 결과로 H(e)NB에 답신한다. H(e)NB로부터 새로 획득된 액세스 회선 위치 정보가 H(e)NB 내의 액세스 회선 위치 정보와 일치하지 않는 경우, HLR은 H(e)NB 액세스를 거부하는 H(e)NB 액세스 응답 메시지를 반환하고 원인 값으로서 "유효하지 않은 위치"를 나타낸다. 액세스 회선 위치 정보가 일치하는 경우, HLR은 H(e)NB 액세스를 허용하는 H(e)NB 액세스 응답을 반환한다.

H(e)NB의 위치가 위치 인증을 사용하여 인증될 수 있지만, IP 주소 스푸핑 공격이 가능할 수 있다. 예를 들어, 프록시 서버는, H(e)NB가 다른 영역으로 위치 변경될 때, 적법하게 등록된 H(e)NB와 동일한 IP 주소를 취할 수 있다. 이어서, 이러한 프록시 서버는, 위치에 관한 한, 그 자신을 적법한 H(e)NB인 것처럼 가장할 수 있다.

H(e)NB가 HLR로부터 정보 또는 메시지를 수신하고 임의의 이러한 정보가 암호적으로 보호되어 있는 상기 단계들 중 임의의 단계에서, 이러한 정보 또는 메시지의 복호화 및 무결성 검사는 H(e)NB TrE 내에서 H(e)NB TrE에 의해 보호되는 키를 사용하여 수행될 수 있다.

이웃 매크로 셀에 기초한 실시예에 대해 이제부터 개시한다. 매크로 셀 정보에 기초하여 위치 확인되기 위해, H(e)NB는 매크로 셀의 서비스 범위에 설치되어야만 하고, 3G 또는 2G 수신기를 가져야 하며, H(e)NB의 이웃 매크로 3G 또는 2G 셀을 스캔하기 위해 수신기 동작 상태로 전환할 수 있다. 매크로 셀에 기초한 위치 로킹 메커니즘은 상기한 것과 유사하지만, 위치 정보가 매크로 셀에 관한 정보[PLMN(Public Land Mobile Network) ID, LAI(Location Area Information) 또는 셀 ID 등]의 형태로 제시된다.

초기 단계는 H(e)NB 위치 정보를 등록하는 것이다. H(e)NB가 켜진 후에, H(e)NB는 이웃 매크로 셀을 스캔한다. 이어서, H(e)NB는 H(e)NB 요청 메시지를 HLR로 전송한다. 이 메시지는 이웃 매크로 셀의 위치 영역 및 셀 ID 등의 정보를 전달한다. H(e)NB의 TrE는 그 자체로 보호되는 키를 사용하여, 이러한 위치 영역 및 셀 ID 정보의 무결성 및/또는 기밀성을 보호할 수 있다. 모든 암호 처리는 TrE 내에서 행해질 수 있다. HLR은 이웃 매크로 셀의 셀 ID를 H(e)NB 프로필의 속성으로서 등록하고, H(e)NB 응답 메시지를 H(e)NB로 전송한다.

그 다음 단계는 H(e)NB 위치를 인증하는 것이다. H(e)NB는 액세스 요청 메시지를 HLR로 전송한다. 이 메시지는 이웃 매크로 셀의 위치 영역 및 셀 ID 등의 정보를 전달한다. H(e)NB의 TrE는 이러한 위치 영역 및 셀 ID 정보가 HLR로 전송 중인 동안, 그 자체로 보호되는 키를 사용하여, 이러한 위치 영역 및 셀 ID 정보의 무결성 및/또는 기밀성을 암호적으로 보호할 수 있다. 모든 암호 처리는 TrE 내에서 행해질 수 있다. HLR은 이웃 매크로 셀의 정보를 저장된 H(e)NB 프로필과 비교하여, H(e)NB가 경계 셀(bound cell) 또는 위치 영역을 통해 네트워크에 연결할 수 있게 해줄지를 결정한다. 이웃 매크로 셀의 정보가 H(e)NB 프로필과 일치하지 않는 경우, HLR은 H(e)NB 액세스를 거부하는 H(e)NB 액세스 응답 메시지를 반환하고 원인 값으로서 "유효하지 않은 위치"를 나타낸다. 이웃 매크로 셀의 정보가 H(e)NB 프로필과 일치하는 경우, HLR은 H(e)NB 액세스를 허용하는 H(e)NB 액세스 응답 메시지를 반환한다.

H(e)NB가 HLR로부터 정보 또는 메시지를 수신하고 임의의 이러한 정보가 암호적으로 보호되어 있는 상기 절차들 중 임의의 절차에서, 이러한 정보 또는 메시지의 복호화 및 무결성 검사는 H(e)NB TrE 내에서 H(e)NB TrE에 의해 보호되는 키를 사용하여 수행될 수 있다.

매크로 셀은 넓은 영역의 서비스 범위를 가진다. 따라서, 단순히 셀 정보를 사용하는 것이 특정 사용자 경우에 대한 정확도 요구사항을 만족시키지 않을 수 있다. IP 주소와 매크로 셀 정보의 조합을 사용하면 정확도를 향상시킬 수 있다.

IP 주소와 이웃 매크로 셀의 조합에 기초한 실시예가 개시된다. 초기 단계는 H(e)NB 위치 정보 등록이다. H(e)NB는 이 메시지에 자신의 IP 주소 및 이웃 셀 ID를 담고 있는 요청 메시지를 HLR로 전송한다. H(e)NB의 TrE는 IP 주소 및 셀 ID 정보가 HLR로 전송 중인 동안, 그 자체로 보호되는 암호 키를 사용하여, IP 주소 및 셀 ID 정보의 무결성 및/또는 기밀성을 암호적으로 보호할 수 있다. 모든 암호 처리는 TrE 내에서 행해질 수 있다.

이어서, HLR은 수신된 IP 주소를 담고 있는 위치 정보 쿼리 메시지를 고정 네트워크 데이터베이스(fixed network database)로 전송한다. IP 주소에 기초하여, HLR은 H(e)NB IP 주소와 바인딩되어 있는 액세스 회선 위치 정보를 획득하기 위해 데이터베이스에 쿼리한다. 액세스 회선 위치 정보 및 이웃 매크로 셀 ID에 따라, HLR은 H(e)NB의 홈 영역(home area)을 결정한다. HLR은 H(e)NB의 액세스 회선 위치 정보를, 수신된 셀 ID와 함께, H(e)NB의 속성으로서 저장한다.

그 다음 단계는 H(e)NB 위치를 인증하는 것이다. HLR은 자신의 IP 주소 및 주변 매크로 셀의 셀 ID를 담고 있는 액세스 요청 메시지를 H(e)NB로부터 수신한다. 새 IP 주소에 따라, HLR은 액세스 회선 위치 정보를 획득하기 위해 또다시 데이터베이스에 쿼리한다. 이어서, HLR은 새로 획득된 액세스 회선 위치 정보가 저장된 것과 동일한지와 그에 부가하여 수신된 셀 ID가 저장된 것과 동일한지를 판단한다. 둘다 동일한 경우, H(e)NB 위치가 변경되지 않는다. 그 다음에, HLR은 액세스 응답 메시지에서 위치 인증 결과로 H(e)NB에 답신한다.

유의할 점은, H(e)NB가 다른 미등록된 주소로 이동되더라도, H(e)NB가 여전히 동일한 매크로 셀 내에 위치될 수 있다는 것이다. 이 구성은 위치 인증 방식의 보안을 향상시킬 수 있다.

GPS(global positioning system)에 기초한 실시예가 개시된다. H(e)NB가 GPS 기능을 내장하고 있는 경우, 그의 위치 정보가 H(e)NB 내의 GPS를 통해 획득될 수 있고, 차후에 액세스 요청 동안 H(e)NB로부터 CN으로 전송될 수 있다. 그렇지만, 일부 실내 환경에서, GPS는 그다지 잘 동작하지 않을 수 있다.

H(e)NB의 TrE는 그 자체로 보호되는 키를 사용하여, HLR로 전송하는 임의의 GPS 위치 정보의 무결성 및/또는 기밀성을 암호적으로 보호할 수 있다. H(e)NB의 TrE는, TrE 내에서 보호되는 키를 사용하여, H(e)NB가 HLR로부터 수신하는 임의의 암호적으로 보호된 정보 또는 메시지의 모든 암호적 처리를 안전하게 처리할 수 있다.

GPS-기반 위치 증명 방법의 보안은 또한 위조 방지(tamper-resistant) 또는 위조 확인(tamper-evident) GPS 장치를 사용하여 보호될 수 있으며, GPS 기능이 별도의 칩에 분리되어 있는 경우에 특히 그렇다. 예를 들어, 보안 강화된(security-hardened) GPS 칩이 사용될 수 있다.

다른 실시예에서, H(e)NB의 TrE는 또한, 주기적인 간격으로 및/또는 어떤 소정의 이벤트의 발생 시에, 마지막으로 알려진 양호한 위치를 안전하게 저장할 수 있다. 이러한 '마지막으로 알려진 양호한 위치'는 네트워크 통신사업자의 위치 서버에 의해 증명될 위치 정보일 것이다. H(e)NB를 새로 부팅할 때, H(e)NB의 TrE는 저장된 '마지막으로 알려진 양호한 위치'를 탐색하고 이를 그의 위치 식별 방법으로부터 새로 획득하는 위치와 비교할 수 있다. 이어서, TrE는 이러한 비교의 결과를 사용하여, H(e)NB의 위치가 변경될 가능성이 있는지를 자율적으로 판정할 수 있다. TrE는 또한 이러한 결과를 네트워크 상의 위치 서버에 보고할 수 있다.

이제부터, H(e)NB 위치 정책 옵션 및 구성에 대해 논의한다. 어느 방식을 사용할지는 통신 사업자가 요구하는 보안 레벨 및 정확도 레벨, H(e)NB 기능, 기존의 매크로 서비스 범위 등의 다수의 인자들에 의존한다. 사용될 방법을 결정하는 데 도움을 주기 위해 정책이 적용될 수 있다. 정책이 H(e)NB에 사전 구성되어 있고 H(e)NB가 정책에 맞춰 자동으로 조정되는 것이 제안된다. 위치 증명 방법에 대한 임의의 보안 정책이 H(e)NB의 TrE로부터 관리될 수 있다.

IP 주소만을 사용하는 것으로 충분히 안전하지 않을 수 있다. GPS가 어떤 실내 환경에서 잘 동작하지 않을 수 있으며, 또한 H(e)NB에 비용을 추가할 수 있다. 실행가능성 및 보안 요구사항을 고려하여, IP 주소 및 이웃 매크로 셀에 기초한 위치 로킹 메커니즘이 고려될 수 있다. 이 방법은 정책 목록에서 첫번째 순위에 있을 수 있다. 매크로 셀 서비스 범위(macro cell coverage)가 없는 경우, 정책에서의 우선 순위(order of preference)에 따라 다른 방법이 사용될 수 있다. GPS가 비용을 증가시키고 모든 H(e)NB가 그 안에 GPS를 설치하고 있는 것은 아닐 수 있기 때문에, GPS-기반 위치 확인 방법이 우선 순위에서 하위에 있을 수 있다. 표 5에 나타낸 바와 같이, 시나리오 및 정책의 다른 조합은 물론 나타내지 않은 다른 것들도 존재할 수 있다.

장면/시나리오	정책
매크로 셀이 존재하고 높은 보안 요구사항	IP 주소 + 매크로 셀
매크로 셀이 존재하지 않음	IP 주소
매크로 셀이 존재하고 낮은 정확도 요구사항	매크로 셀
H(e)NB에 GPS 설치됨	GPS 정보 + IP 주소
H(e)NB에 GPS 설치되고 매크로 셀이 존재함	GPS 정보 + IP 주소 + 매크로 셀

실시예

1. TrE(Trusted Environment)를 포함하는 홈 노드 B/홈 eNB(Home evolved Node B)[H(e)NB].

2. 실시예 1에 있어서, H(e)NB 기능 모듈을 포함하는 H(e)NB.

3. 실시예 1 또는 실시예 2에 있어서, 다중 보안 레벨을 제공하도록 구성된 H(e)NB 기능 모듈과 TrE 사이의 인터페이스를 포함하는 H(e)NB.

4. 실시예 1 내지 3 중 어느 하나에 있어서, TrE는 보안 및 인증을 제공하기 위해 H(e)NB 기능 모듈과 상호작용하도록 구성되는 것인 H(e)NB.

5. 실시예 1 내지 4 중 어느 하나에 있어서, 보안 및 인증은 TrE 또는 H(e)NB 인증 및 조건부 호스팅 당사자 인증 중 적어도 하나를 포함하는 것인 H(e)NB.

6. 실시예 1 내지 5 중 어느 하나에 있어서, TrE는 키, 암호, 민감한 데이터 및 프로그램 중 적어도 하나를 보호하는 저장 영역을 포함하는 것인 H(e)NB.

7. 실시예 1 내지 6 중 어느 하나에 있어서, TrE는 AKA(authentication and keying agreement) 및 TrE 또는 H(e)NB 중 적어도 하나의 인증서 기반 인증 중 적어도 하나를 수행하는 보안 실행 환경을 포함하는 것인 H(e)NB.

8. 실시예 1 내지 7 중 어느 하나에 있어서, 보안 실행 환경은 적어도 TrE의 유효성을 네트워크에 안전하게 알려주는 것에 관계된, 보안에 민감한 동작을 수행하는 것인 H(e)NB.

9. 실시예 1 내지 8 중 어느 하나에 있어서, 보안 실행 환경은 H(e)NB의 위치를 보호하고 확인하는 것인 H(e)NB.

10. 실시예 1 내지 9 중 어느 하나에 있어서, 위치가 확인되는 경우 네트워크 인증이 제공되는 것인 H(e)NB.

11. 실시예 1 내지 10 중 어느 하나에 있어서, 호스팅 당사자에 대한 AKA(authentication and keying agreement) 기반 인증을 제공하는 HPM(hosting party module)을 포함하고, HPM은 TrE에 연결되어 있는 것인 H(e)NB.

12. 실시예 1 내지 11 중 어느 하나에 있어서, HPM은 UICC(universal integrated circuit card)에 의해 구현되는 것인 H(e)NB.

13. 실시예 1 내지 12 중 어느 하나에 있어서, TrE는 H(e)NB의 장치 무결성을 확인하고 장치 인증 표시와 결합된 무결성 표시를 SGW(Security Gateway)로 전송하도록 구성되는 것인 H(e)NB.

14. 실시예 1 내지 13 중 어느 하나에 있어서, TrE는 다중 인증을 지원하도록 구성되는 것인 H(e)NB.

15. 실시예 1 내지 14 중 어느 하나에 있어서, TrE는 상호 인증을 지원하도록 구성되는 것인 H(e)NB.

16. 실시예 1 내지 15 중 어느 하나에 있어서, TrE는 H(e)NB, TrE 및 조건부 호스팅 플랫폼의 기록 및 ID에 기초하여 바인딩 인증을 수행하도록 구성되는 것인 H(e)NB.

17. 실시예 1 내지 16 중 어느 하나에 있어서, TrE는 위치 로킹(location locking)을 수행하도록 구성되고, 위치 로킹은 H(e)NB 위치 정보의 등록 및/또는 H(e)NB 위치 정보의 인증을 포함하는 것인 H(e)NB.

18. 실시예 1 내지 17 중 어느 하나에 있어서, 위치 정보는 이웃 매크로 셀에 기초하는 것인 H(e)NB.

19. 실시예 1 내지 18 중 어느 하나에 있어서, 위치 정보는 IP 주소에 기초하는 것인 H(e)NB.

20. 실시예 1 내지 19 중 어느 하나에 있어서, 위치 정보는 IP 주소 및 매크로 셀에 기초하는 것인 H(e)NB.

21. 실시예 1 내지 20 중 어느 하나에 있어서, 위치 정보는 GPS(global positioning system)에 기초하는 것인 H(e)NB.

22. 실시예 1 내지 21 중 어느 하나에 있어서, 인증의 유형이 IKEv2 프로토콜의 IKE_AUTH 요청을 사용하여 표시되는 것인 H(e)NB.

23. 실시예 1 내지 22 중 어느 하나에 있어서, IKE_AUTH 요청 내의 소정의 파라미터가 인증서 기반 H(e)NB 또는 TrE 인증 또는 EAP-AKA(extensible authentication protocol-authentication key agreement) 기반 H(e)NB 또는 TrE 인증 중 하나를 나타내는 것인 H(e)NB.

24. 실시예 1 내지 23 중 어느 하나에 있어서, 조건부 호스팅 당사자 인증이 EAP-AKA(extensible authentication protocol-authentication key agreement)를 사용하여 수행되는 것인 H(e)NB.

25. 실시예 1 내지 24 중 어느 하나에 있어서, H(e)NB 기능 모듈, TrE 및 네트워크 간에 상호작용하는 프로토콜은 IKEv2(Internet Key Exchange), TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, 또는 OMA(Open Mobile Alliance) DM(Device Management) 중 적어도 하나를 포함하는 것인 H(e)NB.

26. 네트워크에 대한 보안 액세스를 시작하는 단계를 포함하는 홈 노드 B/홈 eNB(Home evolved Node B)[H(e)NB]를 네트워크에 인증하는 방법.

27. 실시예 26에 있어서, 장치 인증 또는 장치 인증 및 호스팅 당사자 인증 중 하나를 지정하는 제1 요구사항을 수신하는 단계를 포함하는 방법.

28. 실시예 26 또는 27에 있어서, 인증서 기반 인증 또는 EAP-AKA(Extensible Authentication Protocol - Authentication and Key Agreement) 인증 중 하나를 지정하는 제2 요구사항을 수신하는 단계를 포함하는 방법.

29. 실시예 26 내지 28 중 어느 하나에 있어서, 장치 인증 또는 장치 인증 및 호스팅 당사자 인증 중 하나를 지원하는 제1 파라미터로 응답하는 단계를 포함하는 방법.

30. 실시예 26 내지 29 중 어느 하나에 있어서, 인증서 기반 인증 또는 EAP-AKA 인증 중 하나를 지원하는 제2 파라미터로 응답하는 단계를 포함하는 방법.

31. 실시예 26 내지 30 중 어느 하나에 있어서, 제1 요구사항 및 제2 요구사항이 제1 파라미터 및 제2 파라미터와 일치하는 경우 제1 요구사항 및 제2 요구사항을 사용하여 인증을 수행하는 단계를 포함하는 방법.

32. 실시예 26 내지 31 중 어느 하나에 있어서, H(e)NB 아이덴티티를 사용하여 검색된 인증 프로필에 기초하여 제1 파라미터 응답의 수락을 수신하는 단계를 포함하는 방법.

33. 실시예 26 내지 32 중 어느 하나에 있어서, H(e)NB 아이덴티티를 사용하여 검색된 인증 프로필에 기초하여 제1 파라미터 응답의 거부를 수신하는 단계를 포함하는 방법.

34. 실시예 26 내지 33 중 어느 하나에 있어서, 호스팅 당사자 인증을 지원하는 다른 제1 파라미터로 응답하는 단계를 포함하는 방법.

35. 실시예 26 내지 34 중 어느 하나에 있어서, 적어도 TrE(Trusted Environment) 또는 H(e)NB의 플랫폼 신뢰성 또는 예상된 상태 중 적어도 하나를 나타내는 정보를 네트워크에 제공하는 단계를 포함하는 방법.

36. 실시예 26 내지 35 중 어느 하나에 있어서, 정보는 TrE 내에 보호된 개인 키에 의해 서명되는 것인 방법.

37. 실시예 26 내지 36 중 어느 하나에 있어서, 정보는 네트워크에 의해 네트워크 및 응용 프로그램에 대한 액세스 권한을 결정하는 데 사용되는 것인 방법.

38. 실시예 26 내지 37 중 어느 하나에 있어서, 플랫폼 유효성의 TrE 암호적으로 보호된 증거를 네트워크에 제공하는 단계를 포함하는 방법.

39. 실시예 26 내지 38 중 어느 하나에 있어서, TrE에 의해, 제1 및 제2 요구사항의 무결성을 검사하는 단계를 포함하는 방법.

40. 실시예 26 내지 39 중 어느 하나에 있어서, TrE에 의해, 아이덴티티 정보를 네트워크로 전달하는 단계를 포함하는 방법.

41. 실시예 26 내지 40 중 어느 하나에 있어서, TrE 및 HPM(hosting party module)을 사용하여 호스팅 당사자 인증을 수행하는 단계를 포함하고, TrE는 HPM 정보를 보호하고 HPM과 보안 통신을 하는 것인 방법.

42. 실시예 26 내지 41 중 어느 하나에 있어서, TrE, 또는 H(e)NB에 대한 적어도 하나의 ID 값 및 HPM에 대한 하나의 ID 값을 사용하여 TrE, H(e)NB 및 HPM을 바인딩하는 단계를 포함하는 방법.

43. 실시예 26 내지 42 중 어느 하나에 있어서, H(e)NB 기능 모듈, TrE 및 네트워크 간에 상호작용하는 프로토콜은 IKEv2(Internet Key Exchange), TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, 또는 OMA(Open Mobile Alliance) DM(Device Management) 중 적어도 하나를 포함하는 것인 방법.

44. 홈 노드 B/홈 eNB(Home evolved Node B)[H(e)NB]를 네트워크에 인증하는 방법으로서, H(e)NB 위치 정보를 TrE(Trusted Environment)에 안전하게 저장하는 단계를 포함하는 방법.

45. 실시예 44에 있어서, 저장된 H(e)NB 위치 정보를 TrE를 통해 네트워크로 안전하게 전송하는 단계를 포함하는 방법.

46. 실시예 44 또는 45에 있어서, H(e)NB의 마지막으로 알려진 양호한 위치를 TrE에 안전하게 저장하는 단계를 포함하는 방법.

47. 실시예 44 내지 46 중 어느 하나에 있어서, 저장된 마지막으로 알려진 양호한 위치를 새로 획득된 위치 정보와, TrE를 사용하여, 비교하는 단계를 포함하는 방법.

48. 실시예 44 내지 47 중 어느 하나에 있어서, TrE에 의한 비교의 결과를 네트워크를 통해 위치 서버에 알려주는 단계를 포함하는 방법.

49. 실시예 44 내지 48 중 어느 하나에 있어서, H(e)NB, TrE 및 네트워크 간에 상호작용하는 프로토콜은 IKEv2(Internet Key Exchange), TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, 또는 OMA(Open Mobile Alliance) DM(Device Management) 중 적어도 하나를 포함하는 것인 방법.

이상에서 특징들 및 요소들이 특정의 조합으로 기술되어 있지만, 각각의 특징 또는 요소가 다른 특징 및 요소 없이 단독으로 또는 다른 특징 및 요소를 갖거나 갖지 않는 다양한 조합으로 사용될 수 있다. 본 명세서에 제공된 방법 또는 플로우차트는 범용 컴퓨터 또는 프로세서에서 실행하기 위해 컴퓨터 판독가능 저장 매체에 구현되어 있는 컴퓨터 프로그램, 소프트웨어, 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 저장 매체의 일례로는 ROM(read only memory), RAM(random access memory), 레지스터, 캐시 메모리, 반도체 메모리 장치, 내장형 하드 디스크 및 이동식 디스크 등의 자기 매체, 광자기 매체, 그리고 CD-ROM 디스크 및 DVD(digital versatile disk) 등의 광 매체가 있다.

적당한 프로세서는, 일례로서, 범용 프로세서, 전용 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit), FPGA(Field Programmable Gate Array) 회로, 임의의 다른 유형의 IC(integrated circuit), 및/또는 상태 기계를 포함한다.

소프트웨어와 연관된 프로세서는 WTRU(wireless transmit receive unit), UE(user equipment), 단말기, 기지국, RNC(radio network controller), 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다. WTRU는 하드웨어 및/또는 소프트웨어로 구현된 모듈[카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 장치, 스피커, 마이크, 텔레비전 송수신기, 핸즈프리 헤드셋(hands free headset), 키보드, Bluetooth® 모듈, FM(frequency modulated) 라디오 유닛, LCD(liquid crystal display) 디스플레이 유닛, OLED(organic light-emitting diode) 디스플레이 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및/또는 임의의 WLAN(wireless local area network) 또는 UWB(Ultra Wide Band) 모듈 등]과 관련하여 사용될 수 있다.

Claims

홈 노드 B/홈 e노드 B(home evolved node B)(H(e)NB)에 있어서,
TrE(trusted environment);
H(e)NB 기능 빌딩 블록(building block)들;
상기 TrE와 제1 H(e)NB 기능 빌딩 블록 간의 제1 인터페이스로서, 상기 제1 인터페이스는 비보호된(unprotected) 인터페이스, 암호적으로 보호된(cryptographically protected) 인터페이스, 또는 하드웨어 보호된(hardware protected) 인터페이스 중 하나인 것인, 상기 제1 인터페이스; 및
상기 TrE와 제2 H(e)NB 기능 빌딩 블록 간의 제2 인터페이스로서, 상기 제2 인터페이스는 비보호된 인터페이스, 암호적으로 보호된 인터페이스, 또는 하드웨어 보호된 인터페이스 중 하나이고, 상기 제2 인터페이스는 상기 제1 인터페이스와 상이한 것인, 상기 제2 인터페이스
를 포함하고,
상기 TrE는 보안을 위한 인증을 제공하기 위해 상기 H(e)NB 기능 빌딩 블록들과 상호작용하도록 구성되고,
상기 보안을 위한 인증은 ⅰ) TrE 또는 H(e)NB 인증 및 ⅱ) 조건부 호스팅 당사자 인증 중 적어도 하나를 포함하는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 TrE는,
키(key) 및 암호(secret)를 포함하는 보안이 필요한 데이터 및 프로그램 중 적어도 하나를 보호하는 저장 영역, 및
ⅰ) AKA(authentication and keying agreement) 및 ⅱ) 상기 TrE 또는 H(e)NB의 인증서 기반 인증 중 적어도 하나를 수행하는 보안 실행 환경을 포함하는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제2항에 있어서, 상기 보안 실행 환경은 적어도 상기 TrE의 유효성(validity)을 네트워크에 안전하게 알려주는 것에 관계된, 보안이 필요한 동작(security sensitive operation)을 수행하는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
삭제
삭제
제1항에 있어서,
호스팅 당사자에 대한 AKA 기반 인증을 제공하는 호스팅 당사자 모듈(HPM; hosting party module)을 더 포함하고, 상기 HPM은 상기 TrE에 연결되어 있는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제6항에 있어서, 상기 HPM은 UICC(universal integrated circuit card)에 의해 구현되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 TrE는 상기 H(e)NB의 장치 무결성을 확인하고 장치 인증 표시와 결합된 무결성 표시를 보안 게이트웨이(SGW; security gateway)에 전송하도록 구성되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 TrE는 다중 인증을 지원하도록 구성되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 TrE는 상호 인증을 지원하도록 구성되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 TrE는 상기 H(e)NB, TrE 및 조건부 호스팅 플랫폼의 ID(identification)의 기록에 기초하여 바인딩 인증을 수행하도록 구성되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
삭제
삭제
삭제
삭제
삭제
제1항에 있어서, 인증의 유형이 IKEv2 프로토콜의 IKE_AUTH 요청을 사용하여 표시되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제17항에 있어서, 상기 IKE_AUTH 요청 내의 미리 결정된 파라미터가 인증서 기반 H(e)NB 또는 TrE 인증이나, EAP-AKA(extensible authentication protocol-authentication key agreement) 기반 H(e)NB 또는 TrE 인증 중 하나를 표시하는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 조건부 호스팅 당사자 인증은 EAP-AKA(extensible authentication protocol-authentication key agreement)를 사용하여 수행되는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
제1항에 있어서, 상기 H(e)NB 기능 빌딩 블럭들, 상기 TrE 및 네트워크 간에 상호작용하는 프로토콜들은 IKEv2(Internet Key Exchange), TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, 또는 OMA(Open Mobile Alliance) DM(Device Management) 중 적어도 하나를 포함하는 것인 홈 노드 B/홈 e노드 B(H(e)NB).
홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법에 있어서,
네트워크에 대한 보안 액세스를 시작하는 단계;
H(e)NB에서, ⅰ) 장치 인증 또는 ⅱ) 장치 인증 및 호스팅 당사자 인증 중 하나를 지정하는 제1 요구사항을 수신하는 단계;
상기 H(e)NB에서, 인증서 기반 인증 또는 EAP-AKA(Extensible Authentication Protocol - Authentication and Key Agreement) 인증 중 하나를 지정하는 제2 요구사항을 수신하는 단계;
장치 인증 또는 장치 인증 및 호스팅 당사자 인증 중 하나를 수행하는 상기 H(e)NB의 능력을 표시하는 제1 파라미터로 상기 H(e)NB가 응답하는 단계;
인증서 기반 인증 또는 EAP-AKA 인증 중 하나를 수행하는 상기 H(e)NB의 능력을 표시하는 제2 파라미터로 상기 H(e)NB가 응답하는 단계; 및
상기 제1 요구사항 및 상기 제2 요구사항이 상기 제1 파라미터 및 상기 제2 파라미터와 매칭되는 조건 하에, 상기 제1 요구사항 및 상기 제2 요구사항을 사용하여 상기 H(e)NB가 인증을 수행하는 단계를 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서,
H(e)NB 아이덴티티를 사용하여 검색된 인증 프로필에 기초하여 상기 제1 파라미터 응답의 수락을 상기 H(e)NB에서 수신하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서, H(e)NB 아이덴티티를 사용하여 검색된 인증 프로필에 기초하여 상기 제1 파라미터 응답의 거부를 상기 H(e)NB에서 수신하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서, 호스팅 당사자 인증을 수행하는 상기 H(e)NB의 능력을 표시하는 또 다른 제1 파라미터로 응답하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서, TrE(Trusted Environment) 또는 H(e)NB의 ⅰ) 예상된 상태 또는 ⅱ) 플랫폼 신뢰성 중 적어도 하나를 표시하는 정보를 상기 네트워크에 제공하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제25항에 있어서, 상기 정보는 TrE 내에 보호된 개인 키에 의해 서명되는 것인, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제25항에 있어서, 상기 정보는 네트워크에 의해 네트워크 및 응용 프로그램에 대한 액세스 권한을 결정하는 데 사용되는 것인, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서,
TrE에 의해 암호적으로 보호되는 플랫폼 유효성의 증거를 상기 네트워크에 제공하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서,
TrE에 의해, 상기 제1 요구사항 및 상기 제2 요구사항의 무결성을 검사하는 단계; 및
상기 TrE에 의해, 상기 H(e)NB 또는 호스팅 당사자의 아이덴티티 정보를 상기 네트워크에 전달하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서,
TrE 및 호스팅 당사자 모듈(HPM; hosting party module)을 사용하여 호스팅 당사자 인증을 수행하는 단계를 더 포함하고, 상기 TrE는 HPM 정보를 보호하고 상기 HPM과 보안 통신을 하는 것인, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서,
ⅰ) TrE, 또는 H(e)NB에 대한 적어도 하나의 ID 값, 및 ⅱ) HPM에 대한 하나의 ID 값을 사용하여, TrE, H(e)NB 및 HPM을 바인딩하는 단계를 더 포함하는, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
제21항에 있어서, 상기 H(e)NB 내의 H(e)NB 기능 빌딩 블럭들, TrE 및 네트워크 간에 상호작용하는 프로토콜들은 IKEv2(Internet Key Exchange), TLS(Transport Layer Security), Broadband Forum TR(Technical Requirement) 069, 또는 OMA(Open Mobile Alliance) DM(Device Management) 중 적어도 하나를 포함하는 것인, 홈 노드 B/홈 e노드 B(H(e)NB)를 네트워크에 인증하는 방법.
삭제
삭제
삭제