KR102558361B1 - 통신 시스템에서 프로파일을 관리하는 기법 - Google Patents

통신 시스템에서 프로파일을 관리하는 기법 Download PDF

Info

Publication number
KR102558361B1
KR102558361B1 KR1020177032815A KR20177032815A KR102558361B1 KR 102558361 B1 KR102558361 B1 KR 102558361B1 KR 1020177032815 A KR1020177032815 A KR 1020177032815A KR 20177032815 A KR20177032815 A KR 20177032815A KR 102558361 B1 KR102558361 B1 KR 102558361B1
Authority
KR
South Korea
Prior art keywords
euicc
lpa
profile
certificate
message
Prior art date
Application number
KR1020177032815A
Other languages
English (en)
Other versions
KR20170140809A (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 KR20170140809A publication Critical patent/KR20170140809A/ko
Application granted granted Critical
Publication of KR102558361B1 publication Critical patent/KR102558361B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • 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/06—Authentication
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Algebra (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다.
본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말의 프로파일 설치 방법에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하는 동작; 및 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하는 동작을 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 방법을 제공한다.

Description

통신 시스템에서 프로파일을 관리하는 기법
본 개시는 통신 시스템에서 단말에 통신 서비스를 다운로드 및 설치하여 통신 연결을 하기 위한 방법 및 장치에 관한 것으로써, 통신 시스템에서 실시간으로 프로파일을 다운로드하고 설치하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파 (mmWave) 대역 (예를 들어, 60기가 (60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍 (beamforming), 거대 배열 다중 입출력 (massive MIMO), 전차원 다중입출력 (Full Dimensional MIMO: FD-MIMO), 어레이 안테나 (array antenna), 아날로그 빔형성 (analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC (Filter Bank Multi Carrier), NOMA (non orthogonal multiple access), 및 SCMA (sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT (Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터 (Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크 (sensor network), 사물 통신 (Machine to Machine, M2M), MTC (Machine Type Communication) 등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT (Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT (information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크 (sensor network), 사물 통신 (Machine to Machine, M2M), MTC (Machine Type Communication) 등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크 (cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
UICC(Universal Integrated Circuit Card)는 이동 통신 단말기 등에 삽입하여 사용되는 스마트카드(smart card)인데 'UICC 카드'라고도 부른다. 상기 UICC에는 이동통신사업자(MNO; mobile network operator)의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예로는 USIM (Universal Subscriber Identity Module), SIM (Subscriber Identity Module), ISIM (IP Multimedia Service Identity Module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM카드라고 부르기도 한다.
본 개시의 이후 설명에서 UICC 카드라 함은 SIM 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 통상의 의미로 사용될 수 있다. 즉, UICC 카드로써 설명된 기술적 내용은, USIM 카드 또는 ISIM 카드 또는 일반적인 SIM 카드에도 동일하게 적용될 수 있다.
UICC 카드는 이동 통신 가입자의 개인정보를 저장하고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽(traffic) 보안 키(secure key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다. 상기 UICC 카드는 본 개시를 제안하는 시점에서 일반적으로 카드 제조 시 특정 이동통신사업자(즉, MNO)의 요청에 의해 해당 MNO를 위한 전용 카드로 제조되며, 해당 MNO 의 네트워크 접속을 위한 인증 정보 예를 들어, USIM (Universal Subscriber Identity Module) 어플리케이션 및 IMSI (International Mobile Subscriber Identity), K 값, OPc 값 등이 사전에 카드에 탑재되어 출고될 수 있다.
따라서 제조된 UICC 카드는 해당 이동통신사업자가 납품받아 가입자에게 제공되며, 이후 필요시에는 OTA(Over The Air) 등의 기술을 활용하여 상기 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다. 가입자는 소유한 이동통신 단말기에 상기 UICC 카드를 삽입하여 해당 이동통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 상기 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용이 가능하다.
그러나 상기 UICC 카드는 이동통신 단말기 사용자가 다른 이동통신사의 서비스를 제공받는데 있어 불편한 점이 있다. 이동통신 단말기 사용자는 이동통신사업자로부터 서비스를 받기 위해 UICC 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 사용자가 다른 나라로 여행을 했을 때 현지 이동통신 서비스를 받기 위해서는 현지 UICC 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 상기 불편함을 어느 정도 해결해 주지만, 비싼 요금 및 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.
한편, UICC 카드에 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당부분 해결할 수 있다. 즉 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수 개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 한 개의 SIM 모듈만을 선택하여 사용할 수 있다.
이러한 UICC 카드는 단말에 고정하거나 고정하지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 eUICC (embedded UICC)라고 하는데, 통상적으로 eUICC는 단말에 고정하여 사용되고, 서버로부터 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미한다.
이러한 eUICC의 사용을 위해서는 프로파일이 eUICC 에서 다운로드 및 설치되어야 한다. 따라서, eUICC 의 프로파일 관리 기법이 요구된다.
본 개시는 통신 시스템에서 단말이 통신 연결을 하기 위한 프로파일을 실시간으로 다운로드 하는 방법 및 장치를 제공한다.
또한, 본 개시는 통신 시스템에서 단말에 프로파일을 제공하는 장치 및 방법을 제공한다.
본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말의 프로파일 설치 방법에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하는 동작; 상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하는 동작; 상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하는 동작; 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하는 동작; 상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하는 동작; 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하는 동작; 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하는 동작; 및 상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하는 동작을 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 방법을 제안한다.
본 개시는 이동통신 시스템에서 eUICC(embed universal integrated circuit card)를 구비하는 단말 장치에 있어서, eUICC에게 eUICC 인증서를 요청하여 상기 eUICC 인증서를 수신하고, 상기 eUICC에게 상기 eUICC 정보를 요청하여 상기 eUICC 정보를 수신하고, 상기 eUICC 정보를 포함하는 다운로드 초기화 메시지를 프로파일 제공서버에게 전송하고, 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 포함하는 상기 다운로드 초기화 메시지에 대한 응답 메시지를 수신하고, 상기 응답 메시지에 포함된 상기 프로파일 제공서버의 인증서 및 상기 프로파일 제공서버의 서명값을 상기 eUICC에게 전달하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 상기 eUICC로부터 수신하고, 상기 eUICC의 1회용 공개 키 및 상기 eUICC의 서명값을 포함하는 프로파일패키지 요청 메시지를 상기 프로파일 제공서버에게 전송하고, 상기 프로파일패키지 요청 메시지에 대한 응답으로 수신한 프로파일 패키지를 eUICC에게 전달하여 상기 프로파일을 설치하도록 제어하는 제어부; 및 상기 제어부의 제어에 의해 상기 수신 또는 전송동작을 수행하는 송수신부를 포함하되, 상기 수신되는 eUICC 인증서는 EUM(eUICC manufacturer) 인증서를 더 포함함을 특징으로 하는 단말을 제안한다.
본 개시에 따르면, 통신 시스템에서 프로파일을 다운로드 및 설치하여 통신 연결을 하기 위한 장치 및 그 방법이 제공된다. 또한, 상기 장치에서 프로파일을 다운로드 할 수 있도록 프로파일을 전송하는 장치 및 프로파일 정보를 전달하는 장치 및 그의 동작 방법이 제공된다.
본 개시에 따르면 무선 통신 시스템에서, 통신 서비스를 이용할 수 있는 프로파일이 이동통신 단말에 설치될 수 있다.
도 1은 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면;
도 2는 eUICC의 원격 프로파일 설치 및 관리를 위한 시스템의 전체 구조를 예시하는 도면;
도 3은 eUICC의 내부 구조을 설명하는 도면;
도 4는 LPA 기능이 구현되는 방식에 따라서 단말의 구성을 예시하는 도면;
도 5a, 5b는 통신 시스템에서 단말의 eUICC가 프로파일을 다운로드하는 방법을 예시하는 도면;
도 6a, 6b는 본 개시에 따른 프로파일 설치 다른 방법을 예시하는 도면;
도 7a, 7b, 7c은 복수 단말을 위한 벌크 프로파일을 한번에 프로비져닝 하는 방법을 예시하는 도면;
도 8은 본 개시의 단말 장치의 구성을 예시하는 도면;
도 9는 본 개시에 따른 서버 장치의 구성을 예시하는 도면이다.
이하, 첨부된 도면들을 참조하여 본 개시의 실시예를 상세하게 설명한다. 하기에서 본 개시를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로써 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 개시 전반에 걸친 내용을 토대로 내려져야 할 것이다.
본 개시의 자세한 설명에 앞서, 본 개시에서 사용되는 몇 가지 용어들에 대해 해석 가능한 의미의 예를 제시한다. 하지만, 아래 제시하는 해석 예로 한정되는 것은 아님을 주의하여야 한다.
본 개시에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭한다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 eUICC로 통칭한다. 또한 eUICC에 다운로드되는 SIM 모듈정보를 통칭하여 eUICC 프로파일(profile)이라는 용어로 호칭한다.
본 개시에서 UICC는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS(short message service)와 같은 개인정보가 저장되어 GSM(global system for mobile communication), WCDMA(wideband code division multiple access), LTE(long term evolution) 등과 같은 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다. UICC에는 가입자가 접속하는 이동통신 네트워크의 종류에 따라 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재되며, 또한 전자 지갑, 티켓팅, 전자 여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.
본 개시에서 eUICC(embedded UICC)는 단말에 삽입 및 탈거가 가능한 탈착식이 아니고 단말에 내장된 칩 형태의 보안 모듈일 수 있다. eUICC는 OTA(Over The Air)기술을 이용하여 프로파일을 다운받아 설치할 수 있다. eUICC는 프로파일 다운로드 및 설치가 가능한 UICC로 명명될 수 있다.
본 개시에서 eUICC에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 단말에 삽입 및 탈거가 가능한 탈착식 UICC에도 적용될 수 있다. 즉, 본 개시의 실시예에는 OTA 기술을 이용하여 프로파일을 다운받아 설치 가능한 UICC에 적용될 수 있다.
본 개시에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.
본 개시에서 프로파일(profile)은 UICC내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 개시에서 'USIM 프로파일'은 '프로파일'과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 개시에서 '프로비져닝 프로파일'은 'USIM 프로파일'과 같은 다른 프로파일을 다운로드하기 위한 프로파일이며, 생산 단계에서 eUICC 내에 미리 탑재되어 있을 수 있다.
본 개시에서 프로파일 제공서버는 SM-DP(Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), 프로파일 도메인의 off-card 엔티티(off-card entity of Profile Domain), 프로파일 암호화 서버, 프로파일 생성서버, 프로파일 제공자(Profile Provisioner; PP), 프로파일 공급자(Profile Provider), PPC holder(Profile Provisioning Credentials holder) 로 표현될 수 있다.
본 개시에서 프로파일정보 전달서버는 DPF (Discovery and Push Function), 또는 SM-DS (Subscription Manager Discovery Service)로 표현될 수 있다.
본 개시에서 프로파일 관리서버는 SM-SR(Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), eUICC 프로파일 관리자의 off-card 엔티티 (off-card entity of eUICC Profile Manager) 또는 PMC holder (Profile Management Credentials holder), EM(eUICC Manager)로 표현될 수 있다.
본 개시에서 프로파일 제공서버(또는 SM-DP+)는 프로파일 제공서버와 프로파일 관리서버의 기능을 합친 것을 통칭하는 것일 수도 있다. 즉, 이후의 기술에서 프로파일 제공서버의 동작은 프로파일 관리서버에서 이루어질 수 있음을 유의하여야 한다. 마찬가지로, 프로파일 관리서버(또는 SM-SR+)에 대하여 기술하는 동작은 프로파일 제공서버에서 수행될 수도 있음은 물론이다.
본 개시에서 사용하는 용어 '단말'은 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(Access Terminal), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말은 예를 들어, 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악 저장 및 음악 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기일 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 개시에서 상기 단말은 전자 장치라 지칭될 수도 있다.
본 개시에서 전자 장치는 프로파일을 다운로드하여 설치 가능한 UICC가 내장될 수 있다. UICC가 전자 장치에 내장되지 않은 경우, 물리적으로 전자 장치와 분리된 UICC는 전자 장치에 삽입되어 전자 장치와 연결될 수 있다. 예를 들어, 카드 형태로 UICC는 전자 장치에 삽입될 수 있다. 상기 전자 장치는 상기 단말을 포함할 수 있고, 이때, 단말은 프로파일을 다운로드하여 설치 가능한 UICC를 포함하는 단말일 수 있다. 상기 단말에 UICC는 내장될 수 있을 뿐만 아니라, 단말과 UICC가 분리된 경우 UICC는 단말에 삽입될 수 있고, 단말에 삽입되어 단말과 연결될 수 있다. 프로파일을 다운로드하여 설치 가능한 UICC는 예를 들어 eUICC라 지칭할 수 있다.
본 개시에서 프로파일 구분자는 프로파일 식별자(Profile ID), ICCID (Integrated Circuit Card ID), ISD-P(Issuer Security Domain Profile) 또는 프로파일 도메인(Profile Domain, PD)와 매칭되는 인자로 지칭될 수 있다. 프로파일 ID는 각 프로파일의 고유 식별자를 나타낼 수 있다.
본 개시에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다. 또한 eUICC에 프로비져닝 프로파일 (Provisioning Profile)이 미리 탑재되어 있는 경우, eUICC 식별자(eUICC ID)는 상기 프로비져닝 프로파일의 식별자 (Provisioning Profile의 Profile ID)일 수 있다. 또한 본 개시의 실시예에서와 같이 단말과 eUICC 칩이 분리되지 않을 경우, eUICC 식별자(eUICC ID)는 단말 ID일 수도 있다. 또한, eUICC 식별자(eUICC ID)는 eUICC칩의 특정 보안 도메인 (Secure Domain)을 지칭할 수도 있다.
본 개시에서 프로파일 컨테이너(Profile Container)는 프로파일 도메인(Profile Domain)으로 명명될 수 있다. 프로파일 컨테이너는 보안 도메인 (Security Domain) 일 수 있다.
본 개시에서 APDU(application protocol data unit)는 단말이 eUICC와 연동하기 위한 메시지일 수 있다. 또한 APDU는 프로파일 제공서버 또는 프로파일 관리서버가 eUICC와 연동하기 위한 메시지일 수도 있다.
본 개시에서 PPC (Profile Provisioning Credentials)는 프로파일 제공서버와 eUICC 간 상호 인증 및 프로파일 암호화, 서명을 하는데 이용되는 수단일 수 있다. PPC는 대칭키, RSA(rivest shamir adleman) 인증서(certificate)와 개인 키(private key), ECC(elliptic curved cryptography) 인증서와 개인 키, 최상위 인증 기관(Root certification authority(CA)) 및 인증서 체인(chain) 중 하나 이상을 포함할 수 있다. 또한 프로파일 제공서버가 복수 개인 경우에는 복수 개의 프로파일 제공서버별로 다른 PPC를 eUICC에 저장하거나 사용할 수 있다.
본 개시에서 PMC (Profile Management Credentials)는 프로파일 관리서버와 eUICC 간 상호 인증 및 전송 데이터 암호화, 서명을 하는데 이용되는 수단일 수 있다. PMC는 대칭키, RSA 인증서와 개인 키, ECC 인증서와 개인 키, Root CA 및 인증서 체인 중 하나 이상을 포함할 수 있다. 또한 프로파일 관리서버가 복수 개인 경우에는 복수 개의 프로파일 관리서버별로 다른 PMC를 eUICC에 저장하거나 사용할 수 있다.
본 개시에서 AID는 어플리케이션 식별자 (Application Identifier)이며, eUICC 내에서 서로 다른 어플리케이션을 구분해줄 수 있다.
본 개시에서 프로파일 패키지 TLV(Profile Package TLV)는 Profile TLV 로 명명될 수 있다. Profile Package TLV는 TLV (Tag, Length, Value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트(data set)일 수 있다.
본 개시에서 AKA(Authentication and Key agreement)는 인증 및 키 승인을 나타낼 수 있으며, 3GPP(3rd generation partnership project) 및 3GPP2 망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다.
본 개시에서 K 는 AKA 인증 알고리즘에 사용되며 eUICC에 저장되는 암호화 키(encryption key) 값이다.
본 개시에서 OPc는 AKA 인증 알고리즘에 사용되며 eUICC에 저장될 수 있는 파라미터 값이다.
본 개시에서 NAA(Network Access Application)는 네트워크 접속 어플리케이션으로, UICC에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망접속 모듈일 수 있다.
도 1은 단말에 고정된 프로파일이 탑재된 UICC를 이용한 단말의 이동통신 네트워크 연결방법을 도시하는 도면이다.
도 1을 참조하면, 단말(110)에 UICC(120)가 삽입될 수 있다. 이때, 상기 UICC(120)는 탈착형 일 수도 있고 단말에 미리 내장된 것일 수도 있다. 고정된 프로파일이 탑재된 UICC의 상기 고정된 프로파일은 특정 통신사에 접속할 수 있는 '접속정보'가 고정되어 있음을 의미한다. 상기 접속정보는 예를 들어, 가입자 구분자인 IMSI(International Mobile Subscriber Identity), 상기 가입자 구분자와 함께 망 인증에 필요한 K 또는 Ki 값일 수 있다.
그러면 상기 단말은 상기 UICC를 이용하여 이동통신사의 인증처리시스템 (예를 들어, HLR(home location register) 이나 AuC(Authentication Center))과 인증을 수행할 수 있다. 상기 인증의 과정은 AKA(Authentication and Key Agreement; 인증 및 승인) 과정일 수 있다. 인증에 성공하면 단말은 상기 이동통신시스템의 이동통신네트워크(130)를 이용하여 전화나 모바일 데이터 이용 등의 이동통신 서비스를 이용할 수 있게 된다.
도 2는 eUICC의 원격 프로파일 설치 및 관리를 위한 시스템의 전체 구조를 예시하는 도면이다.
eUICC(232)는 단말(230) 내에 내장되거나 탈착이 가능한 형태의 UICC카드 또는 칩이다. 상기 eUICC(232)는 폼 팩터(Form Factor) 2FF, 3FF, 4FF 또는 MFF1, MFF2 의 크기를 가질 수도 있고, 이와 다른 다양한 물리적인 크기를 가질 수도 있다. 상기 eUICC는 단말과 별개의 장치로 구현되어 상기 단말에 부착될 수도 있지만, 상기 단말의 통신 칩(예를 들어, CP(communication processor) 또는 기저대역(baseband) 모뎀)에 집적(Integrate)되어 구현될 수도 있다.
프로파일 제공서버(Profile Provider; PP)(200)는 프로파일을 생성하거나 생성된 프로파일을 암호화 하는 기능을 수행할 수 있다. 상기 프로파일 제공서버(200)는 SM-DP+로 지칭될 수도 있다.
프로파일 관리서버(eUICC Manager; EM)(202)는 SM-DP+로부터 전달받은 프로파일을 단말(230)의 LPA(Local Profile Assistant)에 전달할 수 있고 상기 프로파일의 관리를 수행할 수 있다. 상기 프로파일 관리서버(202)는 SM-SR+ 로 지칭될 수도 있다. 상기 SM-SR+(202)은 SM-DP+(200)와 단말(230)(즉, LPA) 사이에서 프로파일 다운로드 또는 프로파일 관리 동작을 제어할 수 있다.
상기 프로파일 제공서버(200) 및 프로파일 관리서버(202)는 하나의 서버로 구현될 수 있고, 상기 하나의 서버는 SM-DP+ 또는 SM+ 로 지칭될 수도 있다.
프로파일정보 전달서버(204) (즉, DPF) 는 SM-SR+ 로부터 SM-SR+ 서버 주소 또는 이벤트 구분자를 전달받아 LPA(230)에게 전달할 수 있다.
이밖에도, 상기 시스템에는 이동망사업자(MNO; mobile network operator)(210), eUICC 제조사(eUICC manufacture)(220), 또는 인증서 발행기관(CI; certificate issuer)이 더 포함될 수 있다.
MNO(210)은 프로파일의 다운로드 및 관리 프로세스에 관여하며, 프로파일이 설치된 eUICC로부터의 요청에 의해 이동통신 서비스를 제공할 수 있다.
eUICC 제조사(EUM; eUICC manufacturer)(220)은 인증서 컨텐츠를 개인 키로 서명함으로써 eUICC 인증서를 발행할 수 있다.
인증서 발행기관(240)은 인증서 컨텐츠를 개인 키로 서명함으로써 EUM 인증서, EM 인증서 또는 PP 인증서를 발행할 수 있다.
또한, 도 2는 서버와 서버 간 인터페이스(예를 들어, ES3), 단말과 서버간 인터페이스(예를 들어, ES9), 단말과 eUICC 간 인터페이스 (예를 들어, ES10) 등을 표시하고 있다. 상기 인터페이스 및 상기 인터페이스에 의해 제공되는 기능에 대해서는 나중에 자세히 설명될 것이다.
도 3은 eUICC의 내부 구조을 설명하는 도면이다.
eUICC(300)는 기본적으로 카드 또는 칩과 같은 형태일 수 있지만, 소프트웨어 형식인 적어도 하나의 프로파일(320, 330)이 설치될 수 있다. 이에, 상기 eUICC는 eUICC OS(operating system)(302) 상에서 동작할 수 있다. 도 3은 eUICC(300) 내에 두개의 프로파일(320, 330)이 탑재되어 있으며, 현재는 하나의 프로파일(320)이 인에이블(enable) 상태에 있고, 다른 하나의 프로파일(33)은 디스에이블 상태에 있음을 나타내고 있다.
TAF(Terminal API function)(306)는 단말(즉, LPA)에 정의된 RMF(Remote Management Function) 및 LMF(Local Management Function)을 전달받아 직접 처리하거나 eUICC(300) 내부의 다른 기능 (예를 들어, CMF(308) 또는 PEF(316)) 에서 처리할 수 있도록 하는 기능이다. TAF(306)는 eUICC의 ISD-R(Issuer Security Domain Root)과 동일하거나 다를 수도 있다.
ISD-R(304)는 eUICC(300)의 바닥(base)에 위치하는 보안 도메인이다.
CMF(Certificate Management Function)(308)는 eUICC(300) 내부에서 다음의 데이터(또는 정보)를 저장할 수 있다.
- 하나 이상의 eUICC 인증서 및 연관된 개인 키
- eUICC 인증서를 서명한 EUM (eUICC Manufacture)의 인증서
- 하나 이상의 CI (Certificate Issuer)인증서
eUICC(300)의 내부 요청에 따라 상기 CMF(308)는 다음의 동작 중 적어도 하나를 수행할 수 있다.
- eUICC 인증서 또는 EUM 인증서를 제공
- EM 인증서를 CI 인증서의 공개 키(public key)로 검증
- EM 개인 키로 서명된 서명값(signature)을 EM 인증서의 공개 키로 검증
- PP 인증서를 CI 인증서의 공개 키로 검증
- PP 개인 키로 서명된 서명값을 EM 인증서의 공개 키로 검증
PEF(Policy Enforcement Function)(316)는 eUICC(300)에 설정된 정책 룰 (Policy Rule)(314)을 실행하는 역할을 한다. 상기 정책 룰(314)에는 프로파일 정책 룰(Profile Policy Rule; PPR)과 eUICC 정책 룰 (eUICC Policy Rule; EPR)이 있다.
상기 Profile Policy Rule (PPR)은 프로파일 내부에 저장되고, MNO의 OTA 키(key)에 의해 제어되거나, 특정 SM-DP+ 의 서명값에 의해 제어 될수 있다.
상기 eUICC Policy Rule (EPR)은 프로파일 외부에 저장되고, 특정 SM-DP+ 서명값이나 특정 SM-SR+의 서명값에 의해 제어될 수 있다.
상기 eUICC Policy Rule (EPR)은 정책 룰에 대한 소유자 ID (owner ID) 및 설정하고자 하는 룰로 구성될 수 있다. 상기 소유자 ID는 SM-DP+ 또는 SM-SR+의 유효한 인증서 및 개인 키를 소유한 서버의 ID일 수 있다.
PPI(Profile Package Interpreter)(310)은 복호화된 프로파일 정보를 해석하여 설치가능한 단위로 설치하는 기능이다. PPI는 PIF(Profile Interpreter Function)로 지칭될 수도 있다.
프로파일 레지스트리(Profile Registry)(312)는 eUICC(300)에 설치된 개별 프로파일을 관리하기 위한 개별 프로파일별 정보 즉, 프로파일 레코드(Profile Record)를 포함할 수 있다. eUICC(300)는 프로파일이 설치될 때, SM-DP+ 또는 SM-SR+에서 전달받은 정보를 이용하여 프로파일 레코드를 프로파일 레지스트리의 일부로 구축하고, 추후 프로파일을 관리하는데 이용할 수 있다.
다음 표 1은 상기 프로파일 레지스트리(312)의 정보(즉, ProifileRegisty) 구성의 일 예를 보여준다.
Figure 112017112361107-pct00001
표 1을 참고하면, ProfileRecord는 다음의 정보 중 하나 이상을 포함할 수 있다. ProfileRecord는 ProfileMetadata라고 지칭될 수도 있다.
- 프로파일ID 또는 ICCID
- 프로파일 제공 MNO의 PLMNID
- 프로파일 설명 (예를 들면, 전화번호)
- 프로파일 타입
- Notification(통지)을 받을 서버ID (SM-DP+ 주소 또는 SM-SR+ 주소)
- Notification을 받을 서버ID (MNO 서버 주소)
- ProfileRecord를 수정할 수 있는 서버ID (SM-DP+ 주소 또는 SM-SR+ 주소)
도 4는 LPA 기능이 구현되는 방식에 따라서 단말의 구성을 예시하는 도면이다.
단말은 eUICC의 프로파일 다운로드, 설치, 관리 동작을 지원하기 위해 서버와 통신을 수행하는 LPA(Local Profile Assistant)를 포함할 수 있다. 상기 LPA는 AP(application processor)와 CP(communication processor)에 의해 구현될 수 있다.
단말의 LPA 기능은 RMF(Remote Management Function), LMF(Local Management Function), UIF(User Interface Function) 중 적어도 하나를 포함할 수 있다.
RMF (Remote Management Function)은 SM-SR+, SM-DP+, SM-DS, LMF, eUICC중 하나 이상과 직접 또는 간접적으로 연동하여, eUICC의 원격 관리 이벤트를 수행할 수 있다. 예를 들어, 상기 RMF는 네트워크에 의해 시작되는(initiated) 프로파일 다운로드/인에블/디스에이블/삭제 동작과 정책 룰 다운로드 동작을 지원할 수 있다.
LMF (Local Management Function)은 UIF, RMF, eUICC중 하나 이상과 직접 또는 간접적으로 연동하여 eUICC의 로컬 관리 이벤트를 수행할 수 있다. 예를 들어, 상기 LMF는 단말에 의해 시작되는 프로파일 인에이블/디스에이블/삭제 동작 또는 eUICC 리셋(reset) 동작을 지원할 수 있다. 상기 LMF는 결과 통보(result notification)를 위해 SM-SR+와 인터페이스 할 수도 있다.
UIF (User Interface Function)은 RMF/LMF 와 사용자 사이의 데이터 교환을 지원할 수 있다. 상기 UIF는 사용자의 입력을 LMF에 전달하는 UI를 포함할 수 있다.
도 4(a)는 LPA의 기능이 AP 중심적(AP centric)으로 구현되는 경우를 예시한다. LPA(410)는 AP(412) 및 CP(414)를 포함하지만, RMF, LMF, UIF는 모두 LPA(410) 내의 AP(412)에 의해 구현된다. 상기 AP(412)는 SM-DS(400), SM-SR+(402), 및 사용자와 인터페이스하여 eUICC(420)의 관리 이벤트를 수행할 수 있다.
도 4(b)는 LPA의 기능이 CP 중심적(CP centric)으로 구현되는 경우를 예시한다. LPA(440)는 AP(442) 및 CP(444)를 포함하지만, RMF, LMF 는 모두 LPA(440) 내의 CP(444)에 의해 구현된다. 상기 CP(444)는 SM-DS(430), SM-SR+(432)와 인터페이스하여 eUICC(450)의 관리 이벤트를 수행할 수 있다.
도 4(c)는 LPA의 기능이 하이브리드(hybrid) 방식으로 구현되는 경우를 예시한다. RMF, LMF 는 LPA(470) 내의 CP(474)에 의해 구현되지만, UIF는 상기 LPA(470) 내의 AP(472)에 의해 구현된다. 상기 UIF는 사용자(464) 및 상기 CP(474) 내의 LMF와 인터페이스 하여 eUICC(480)의 관리 이벤트를 수행할 수 있고, 상기 CP(474) 내의 RMF는 SM-DS(460), SM-SR+(462)와 인터페이스하여 eUICC(480)의 관리 이벤트를 수행할 수 있다.
도 5a, 5b는 통신 시스템에서 단말의 eUICC가 프로파일을 다운로드하는 방법을 예시하는 도면이다.
도 5를 참고하면 SM-DP+(500)는 SM-SR+ 없이 LPA(502)와 직접 IP 기반의 HTTPS 를 이용하여 통신할 수 있다.
SM-DP+(500)는 SM-DP+의 서명용 인증서 (CERT.DP.ECDSA; certificate of DP used for digital signature verification) 및 서명용 개인 키 (SK.DP.ECDSA; private key of DP for digital signature verification)를 내부 저장소에 보관할 수 있다. 상기 SM-DP+(500)는 HTTPS 를 위한 TLS(Transport Layer Security)용 서버 인증서 (CERT.DP.TLS; certificate of DP used for TLS) 및 개인 키 (SK.DP.TLS; private key of DP for TLS)도 내부 저장소에 보관할 수 있다. 상기 인증서 CERT.DP.ECDSA, SK.DP.ECDSA, CERT.DP.TLS, 및 SK.DP.TLS 가 저장되는 내부 저장소는 물리적으로 같은 저장장치이거나 다른 저장장치일 수 있다.
eUICC(504)는 eUICC의 서명용 인증서 (CERT.EUICC.ECDSA; certificate of eUICC used for digital signature verification) 및 개인 키 (SK.eUICC.ECDSA; private key of eUICC for digital signature verification)를 내부 저장소에 보관할 수 있다.
상기 단말의 프로파일 다운로드 과정은 다음과 같다.
LPA(502)가 eUICC(504)에 ES10b.GetCertificate 메시지를 전송하여 eUICC 인증서를 요청하면(510), 상기 eUICC(504)는 상기 LPA(502)에게 eUICC 인증서 CERT.eUICC.ECDSA를 반환할 수 있다(512). 이때, 상기 eUICC(504)는 상기 eUICC 인증서뿐만 아니라 EUM 인증서 CERT.EUM.ECDSA(: certificate of EUM used for digital signature verification)도 함께 반환할 수 있다. 대안적으로, 상기 eUICC 인증서나 EUM 인증서가 상기 LPA(502)에 저장되어 있었다면, 상기 510, 512 동작은 수행되지 않을 수도 있을 것이다.
만약 LPA(502)가 eUICC의 서명값을 SM-DP+(500)에 전달해야 한다면, 상기 LPA(502)는 eUICC(504)에게 ES10b.GetSignature 메시지를 전송하여 서명값 생성을 요청할 수 있다. 이때 서명에 들어가는 인자는 LPA(502)에서 전달해 주는 값이며, 상기 값은 EventID (특정 프로파일 다운로드 이벤트를 구분하는 구분자), NotificationID (EventID와 유사함), MatchingID (EventID와 유사함), Activation Code Token (EventID와 유사함), 및 단말에서 생성한 랜덤값 중 적어도 하나를 포함할 수 있다.
만약 상기 LPA(502)가 상기 eUICC의 서명값이 필요없는 경우, 상기 LPA(502)는 상기 eUICC(504)에게 ES10b.GetEUICCInfo 메시지를 전송하여 eUICC의 정보(eUICC Info)를 요청할 수 있다(514).
상기 eUICC(504)는 상기 LPA(502)의 요청(514)에 대응하여, eUICC challenge를 생성한다(516). 상기 eUICC challenge는 상기 eUICC(504)가 추후 상기 SM-DP+(500)를 인증하기 위해 생성하는 랜덤 값이다.
eUICC(504) 는 LPA(502)에 eUICC_Info 를 반환할 수 있다(518). 상기 eUICC_Info는 eUICC challenge 또는 eUICC의 버전 정보 등을 포함할 수 있다.
LPA(502)는 SM-DP+(500)에 ES9+.InitiateDownload 메시지를 호출할 수 있다(520). 상기 ES9+.InitiateDownload 메시지의 호출전 LPA와 SM-DP+ 사이에 HTTPS 세션 연결이 수립될 수 있다. 상기 HTTPS 세션 연결은 프로파일 다운로드 전과정에서 같은 세션이 이용될 수도 있고, 과정별로 다른 세션이 이용될 수도 있다. 선택적으로, 상기 ES9+.InitiateDownload는 ES9.InitiateAuthentication 또는 ES9.EventRequest 일 수도 있다.
상기 ES9+.InitiateDownload 메시지에는 eUICC Info가 포함될 수 있고, 예를 들어, 상기 eUICC(504)에서 생성된 eUICC Challenge가 포함될 수 있다. 또한 상기 ES9+.InitiateDownload 메시지에는 eUICC 인증서 또는 EUM 인증서가 포함될 수도 있다.
SM-DP+(500)가 eUICC 인증서를 전달받은 경우에는, 상기 SM-DP+(500)는 CI 인증서 또는 CI 인증용 공개 키(PK.CI.ECDSA; public key of CI used for digital signature verification)를 이용하여 EUM 인증서를 검증할 수 있다. 상기 SM-DP+(500)는 상기 검증된 EUM 인증서를 이용하여 eUICC 인증서를 검증하고, 상기 eUICC 인증서를 이용하여 eUICC 서명값을 검증할 수 있다. 선택적으로, 상기 인증서 검증 및 서명 검증은 생략될 수도 있다.
상기 SM-DP+(500)는 eUICC_Info 를 기반으로 eUICC(504)의 적합성(eligibility)을 체크할 수 있다(522). 이때, 상기 SM-DP+(500)는 eUICC_Info의 eUICC 버전 정보를 이용하여 상기 eUICC(504)의 적합성을 체크할 수 있다.
그리고 상기 SM-DP+(500)는 랜덤값 DP Challenge를 생성할 수 있다(522). 상기 DP Challenge는 추후 SM-DP+(500)가 eUICC(504)를 인증하기 위해 생성하는 값이다.
그리고 SM-DP+(500)는 TransactionID를 생성할 수 있다(522). 상기 TransactionID는 SM-DP+(500)가 복수개의 단말 요청들을 동시에 처리할 수 있도록 특정 프로파일 다운로드 세션을 구분해주는 구분자이다. 이와 같은 TransactionID로 구분하지 않을 경우, SM-DP+(500)는 한번에 하나의 단말에 대해서만 프로파일을 다운로드 할 수 있고, 만약 특정 단말이 SM-DP+와 연동중 응답을 지연한다면, 다른 단말이 프로파일을 다운로드 할 수 없을 것이다. 이러한 다운로드 불능을 해결하기 위해, SM-DP+(500)가 특정 세션의 라이프타임(lifetime)을 적용하여 일정 시간이 경과한 세션을 삭제할 수도 있지만, 이 경우에는 상기 SM-DP+(500)가 처리할 수 있는 성능에는 여전히 한계가 존재한다. 그러나, 상기 TransactionID 에 의하면 복수 개의 세션 구분이 가능하고, 따라서 SM-DP+(500)는 복수 개의 단말로부터의 요청을 처리할 수 있게 된다.
만약 SM-DP+(500)가 LPA(502)로부터 MatchingID를 전달받았거나, EID 를 전달받은 경우, SM-DP+(500)는 상기 MatchingID에 대응되거나 상기 EID에 대응되는 다운로드 대상 프로파일이 있는지 확인할 수도 있다.
그리고, SM-DP+(500)는 eUICC Challenge, DP Challenge, TransactionID 값을 포함하는 데이터에 대하여 서명용 개인키 SK.DP.ECDSA(: Private Key of DP used for digital signature verification) 를 이용하여 DP 서명값 (DP Signature)을 생성할 수 있다(522).
상기 DP 서명값은 eUICC(504)에서 SM-DP+(500)를 인증하기 위한 서명값이다.
SM-DP+(500)는 상기 ES9+.InitiateDownload(520)에 대한 응답으로써 SM-DP+(500)의 서명용 인증서 CERT.DP.ECDSA, DP Challenge, TransactionID, DP Signature를 전달할 수 있다(524).
LPA(502)는 상기 응답(524)를 받으면, eUICC(504)에게 ES10b.PrepareDownload 메시지를 전달할 수 있다(526). 상기 ES10b.PrepareDownload는 ES10.GetAuthDataRequest 일 수도 있다. 상기 ES10b.PrepareDownload 메시지는 CERT.DP.ECDSA, DP Challenge, TransactionID, DP Signature를 포함할 수 있다.
eUICC(504)는 DP 인증서 CERT.DP.ECDSA 를 상기 eUICC(504)에 저장된 CI 인증서 또는 CI의 공개 키를 이용하여 검증할 수 있다(528).
상기 인증서 CERT.DP.ECDSA 의 검증에 성공하면 eUICC는 SM-DP+(500)의 서명값 DP Signature를 검증할 수 있다(528). 상기 eUICC(504)의 상기 DP Signature의 검증에는, LPA(502)로부터 전달받은 DP Challenge, TransactionID, 상기 eUICC(504)가 상기 LPA(502)에 전달했던 eUICC Challenge, 그리고 CERT.DP.ECDSA에 포함되어 있는 SM-DP+(500)의 공개 키 PK.DP.ECDSA가 이용될 수 있다.
상기 DP Signature의 검증이 통과되면, 상기 eUICC(504)는 1회용 비대칭키 쌍(otPK.EUICC.ECKA, otSK.EUICC.ECKA)을 생성할 수 있다(528). 대안적으로, 상기 ES10b.PrepareDownload(526)이 특정 SM-DP+ 로부터 트리거된 경우이거나, LPA(502)가 별도의 지시자(indicator)로 상기 ES10b.PrepareDownload(526)를 요청한 경우에는, 상기 eUICC(504)는 1회용 비대칭키 쌍을 생성하지 않고 사전에 생성했던 1회용 비대칭키 쌍을 로드하여 사용할 수도 있다.
상기 eUICC(504)의 1회용 비대칭키 쌍은 SM-DP+(500)의 1회용 비대칭키 쌍과 함께 상기 SM-DP+(500)와 eUICC(504)간의 암호화 키를 생성하는데 사용될 수 있다. 상기 암호화 키는, SM-DP+(500)에 의해서 SM-DP+(500)의 1회용 개인 키와 eUICC(504)의 1회용 개인 키 결합으로 생성되거나, eUICC(504)에 의해 eUICC(504)의 1회용 개인 키와 SM-DP+(500)의 1회용 공개 키 결합으로 생성될 수 있다. 상기 암호화 키 생성에 추가로 필요한 인자는 SM-DP+(500)가 이후의 단계에서 LPA(502)를 통해 eUICC에 전달할 수 있다.
eUICC(504)는 상기 생성한 1회용 비대칭키 쌍중 1회용 공개 키 (otPK.EUICC.ECKA) 및 DP Challenge 를 포함하는 데이터에 대하여 eUICC의 서명용 개인 키 (SK.eUICC.ECDSA)를 이용하여 eUICC 서명값(eUICC_Sign2)을 계산할 수 있다(528). 상기 eUICC_Sign2 계산에 SM-DP+(500)가 생성한 DP Challenge를 포함했기 때문에 상기 eUICC_Sign2 은 이후 스텝에서 SM-DP+(500)가 eUICC(504)를 인증하는 용도로 사용될 수 있다. 또한 상기 eUICC_Sign2는 eUICC가 생성한 otPK.EUICC.ECKA 값을 SM-DP+(500)에게 변조되지 않고 전달하는 역할을 할 수 있다.
eUICC(504)는 상기 생성한 eUICC의 1회용 공개 키 otPK.EUICC.ECKA 및 생성한 eUICC 서명값 eUICC_Sign2을 LPA(502)에 전달할 수 있다(530).
LPA(502)는 SM-DP+(500)에게 프로파일패키지 요청 메시지 ES9+GetBoundProfilePackage 를 전달할 수 있다(532). 상기 ES9+GetBoundProfilePackage(532)는 eUICCManagementRequest 또는 ProfileRequest와 같이 명명될 수도 있다.
상기 ES9+GetBoundProfilePackage(532)는 1회용 eUICC 공개 키 및 상기 eUICC 서명이 포함될 수 있다. 추가적으로, 상기 ES9+GetBoundProfilePackage(532)에는 eUICC 서명값 검증을 위한 eUICC 서명용 인증서 (CERT.EUICC.ECDSA) 및 eUICC 서명용 인증서 검증을 위한 EUM 인증서 (CERT.EUICC.ECDSA)도 전달될 수 있다. 추가적으로, 특정 프로파일을 다운로드하는데 구분자로 활용될 수 있는 EventID, MatchingID, NotificationID 또는 Activation Code Token 이 상기 ES9+GetBoundProfilePackage(532)에 포함될 수도 있다.
SM-DP+(500)가 eUICC 인증서를 전달받은 경우에는, 상기 SM-DP+(500)는 CI 인증서 또는 CI 인증용 공개 키(PK.CI.ECDSA)를 이용하여 EUM 인증서를 검증할 수 있다. 상기 SM-DP+(500)는 상기 검증된 EUM 인증서를 이용하여 eUICC 인증서를 검증하고, 상기 eUICC 인증서를 이용하여 eUICC 서명값을 검증할 수 있다. 선택적으로, 상기 인증서 검증 및 서명 검증은 생략될 수도 있다.
그리고 SM-DP+(500)는 상기 532 동작에서 LPA(502)로부터 전달받은 1회용 eUICC 공개 키 및 상기 524 동작에서 LPA(502)에 전달했던 DP Challenge 와 eUICC 인증서에 포함된 공개 키를 이용하여 eUICC 서명 (즉, eUICC_Sign2)를 검증할 수 있다(534). 상기 eUICC_Sign2의 검증이 통과한 경우 SM-DP+(500)는 eUICC(504)를 인증한 것이 된다. 만약 상기 검증에 실패한 경우 SM-DP+(500)는 해당 세션에 대한 동작을 멈추고 LPA(502)에게 에러를 리턴할 수 있다.
SM-DP+(500)는 상기 532 단계에서 전달받은 EventID (또는 NotificationID, MatchingID, Activation Code Token)값을 이용하여 다운로드할 프로파일을 매핑할 수 있다. 만약 다운로드할 프로파일이 없는 경우 에러를 리턴하고 해당 세션을 종료할 수 있다.
SM-DP+(500)는 1회용 DP 비대칭키 쌍(otPK.DP.ECKA, otSK.DP.ECKA)을 생성할 수 있다(534). 상기 SM-DP+(500)는 상기 1회용 DP 비대칭키 쌍을 이용하여 eUICC(504)와 SM-DP+(500) 간의 암호화 키를 생성할 수 있다(534). 상기 암호화 키 생성 방식은 다음과 같다.
- SM-DP+(500)가 SM-DP+의 1회용 개인 키와 eUICC의 1회용 개인 키를 결합하여 암호화 키 생성하는 방식
- eUICC(504)가 eUICC(504)의 1회용 개인 키와 SM-DP+의 1회용 공개 키를 결합하여 암호화 키 생성하는 방식
그리고 SM-DP+(500)는 SM-DP+ 서명값 (DP Signature2)을 계산할 수 있다(534). 상기 서명값 DP Signature2은 CRT(control reference template), SM-DP+의 1회용 공개 키, eUICC의 1회용 공개 키, TransactionID를 포함하는 데이터에 대하여 SM-DP+의 서명용 개인 키(SK.DP.ECDSA)를 이용하여 계산한 값이다. 상기 CRT는 암호화 키 생성의 인자로 사용할 수 있다.
SM-DP+(500)는 특정 eUICC에 결합된 프로파일 패키지(Bound Profile Package; BPP)를 생성할 수 있다(534). 상기 BPP는 CRT, SM-DP+(500)의 1회용 공개 키, DP Signature2 를 포함할 수 있다. 또한 상기 BPP는 상기 암호화 키로 암호화된 ProfileInfo (또는 MetaData)를 포함할 수 있다. 또한 상기 BPP는, 프로파일 보호 키(Profile Protection Key; PPK)를 상기 생성한 암호화 키로 암호화한, 암호화된 PPK를 포함할 수 있다. 또한 상기 BPP는 상기 생성한 암호화 키 또는 상기 PPK로 암호화된 프로파일 패키지 블록(Profile Package Block; PPB) 들을 포함할 수 있다. 상기 암호화된 PPB들은, 전체 프로파일 데이터가 설치 가능한 단위인 프로파일 엘리먼트(Profile Element; PE)로 쪼개진 후, 암호화 가능 크기 단위로 나뉘어진 상기 PPB가 암호화된 것이다. 상기 PPB의 암호화에는 SCP03t 프로토콜이 사용될 수 있다.
SM-DP+(500)는 상기 ES9+GetBoundProfilePackage(532)에 대한 응답으로 LPA(502)에게 BPP를 반환할 수 있다(536).
LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 상기 BPP에 포함된 ES8+.InitializeSecureChannel 정보를 eUICC(504)에 전달할 수 있다(538). 상기 ES8+.InitializeSecureChannel 정보는 CRT, SM-DP+의 1회용 공개 키, DP Signature2 를 포함할 수 있다. 상기 ES8+.InitializeSecureChannel 는 EstablishSecureChannel 를 지칭할 수도 있다. 상기 ES10b.LoadBoundProfilePackage 는 "StoreData" 명령어를 전송하는 것일 수 있다.
eUICC(504)는 상기 526 단계에서 전달받은 DP 서명용 인증서 CERT.DP.ECDSA의 공개 키 PK.DP.ECDSA, 상기 538 단계에서 전달받은 CRT, SM-DP+의 1회용 공개 키 및 상기 530 단계에서 LPA(502)에 전달했던 eUICC의 1회용 공개 키를 이용하여 DP 서명 (DP Signature2)를 검증할 수 있다(540).
상기 검증(540)에 실패하면, 상기 eUICC(504)는 에러를 LPA(502)에게 리턴하고 이후 과정을 수행하지 않는다. 상기 검증(540)에 통과하면, eUICC(504)는 CRT, eUICC의 1회용 개인 키, SM-DP+의 1회용 공개 키를 이용하여 암호화 키를 생성할 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(538)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(542).
LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 BPP에 포함된 ES8+SetProfileInfo 정보를 eUICC(504)에게 전달할 수 있다(544). 상기 ES8+SetProfileInfo는 ES8+.StoreMetadata 또는 InstallProfileRecord로 지칭할 수도 있다. 상기 ES8+SetProfileInfo에는 ProfileInfo (또는 Metadata 또는 ProfileRecord)가 포함될 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(544)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(546).
선택적으로, LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 ES8+.ReplaceSessionKey 정보를 eUICC(504)에게 전달할 수도 있다(548). 즉, LPA(502)가 SM-DP+(500)으로부터 전달받은 BPP에 ES8+.ReplaceSessionKey가 포함된 경우, 상기 LPA(502)는 ES10b.LoadBoundProfilePackage 를 N 회 수행하여 상기 BPP에 포함된 ES8+ReplaceSessionKeys 정보를 eUICC에 전달할 수 있다. 상기 ES8+ReplaceSessionKeys 는 UpdateSessionKeyRequest로 지칭될 수 있다. 상기 ES8+ReplaceSessionKeys 는 상기 534 단계의 암호화 키로 암호화한 ProfileProtectionKey(PPK)가 포함할 수 있다. 선택적으로, 상기 eUICC(504)는 N 회의 APDU를 상기 ES10b.LoadBoundProfilePackage(548)에 대한 응답으로써 상기 LPA(502)에게 전달할 수 있다(550).
이후 LPA(502)는 ES10b.LoadBoundProfilePackage 를 복수(N) 회 수행하여 상기 BPP에 포함된 암호화된 PPB(Profile Package Block) 또는 프로파일 세그먼트(Profile Segment) 들을 eUICC(504)에게 전달할 수 있다(552). 상기 각 Profile Segment는 상기 암호화 키 또는 PPK로 복호화되어 순서대로 eUICC(504)에서 처리될 수 있다.
모든 Profile Segment 처리후 eUICC(504)는 eUICC 서명값을 계산하여 LPA(502)에게 전달할 수 있다(554). 이때 LPA(502)는 ES9+.SendResult를 통해 상기 eUICC 서명값을 SM-DP+(500)에게 전달함으로써 프로파일 설치 결과를 알려줄 수 있고(556), 상기 SM-DP+(500)은 확인(OK)을 전송할 수 있다(558).
도 6a, 6b는 본 개시에 따른 프로파일 설치의 다른 방법을 예시하는 도면이다.
도 5a, 5b와 비교할 때, 도 6a, 6b에서는 초기 라운드에서 eUICC의 Signature가 생략되며, 초기 라운드 이후의 동작이 보다 자세히 설명된다.
도 6a, 6b를 참조하면, LPA(620)은 프로파일 정보를 획득할 수 있다(640). 예를 들어, 상기 LPA(620)은 SM-DS로부터 SM-DP+(610)의 주소 및 프로파일 설치 키를 전달받을 수 있다. 상기 프로파일 설치 키는 EventID, MatchingID, NotificationID 또는 Activation Code Token 일 수 있다. 여기서, eUICC(630)는 LPA(620)에 삽입되거나, 내장되어 있는 것으로 LPA(620)과 eUICC(630)의 동작은 단말의 내부 동작으로 해석될 수 있다.
LPA(620)은 상기 획득한 프로파일 설치 키 정보를 이용하여 비밀코드를 입력할 수 있다(642). 상기 642 동작은 필수 동작은 아니며, 비밀코드가 있는 경우 선택적으로 수행될 수 있다.
LPA(620)은 eUICC(630)에 eUICC 챌린지(eUICC Challenge) 생성을 요청할 수 있다(644).
eUICC(630)는 LPA(620)이 eUICC Challenge 생성을 요청하면, eUICC Challenge를 생성 후 저장할 수 있다(646).
eUICC(630)는 생성된 eUICC Challenge 및 인증서 정보(Certificate_Info)를 LPA(620)에 전달할 수 있다(648). 상기 인증서 정보(Certificate_Info)는 eUICC 인증서 종류 및 사용 가능한 암호화 키 종류를 포함할 수 있다. 상기 암호화 키 정보는 타원 곡선 파라미터(Elliptic Curver Parameter)를 의미할 수 있다. 상기 암호화 키 정보는 복수 개일 수 있으며, 서명 생성에 사용할 정보와 서명 검증에 사용되는 정보를 구분하여 포함할 수 있다. 상기 타원 곡선 파라미터가 전달됨으로써, 서로 호환되는 타원곡선 파라미터를 SM-DP+가 선택할 수 있다.
LPA(620)은 eUICC Challenge, Certificate_Info에 추가로 상기 프로파일 정보에 포함된 SM-DP+(610) 주소 정보를 포함하여 상기 주소 정보에 해당하는 SM-DP+(610)에게 전달할 수 있다(650).
SM-DP+(610)는 상기 전달받은 정보에 포함된 SM-DP+가 유효한지 체크할 수 있다(652). 상기 유효한지 체크는 전달받은 SM-DP+ 주소 정보가 자신의 서버 주소와 동일한지를 검증하거나, 또는 복수 개의 유효한 주소 중에 대응되는지를 확인하는 것 일수 있다. 만약 상기 유효한지의 체크가 실패하면 상기 SM-DP+(610)는 에러코드를 LPA(620)에 전달하고 프로파일 다운로드 동작을 멈출 수 있다.
또한 SM-DP+(610)는 Certificate_Info를 체크할 수 있다(652). 우선 상기 SM-DP+(610)는 인증서 타입이 유효한지 체크할 수 있다. 그리고 암호화 키 정보가 SM-DP+(610)에서 지원 가능한 것인지 체크할 수 있다. 상기 체크는, eUICC(630)의 서명을 위한 암호화 키 정보와 SM-DP+(610)에서 검증 가능한 암호화 키 정보가 일치하는지와, EUICC(630)에서 검증을 위한 암호화 키 정보와 SM-DP+(610)에서 서명을 생성하는데 사용하는 암호화 키 정보가 일치하는지 비교하는 과정일 수 있다.
상기 체크 과정이 유효하면 SM-DP+(610)는 사용할 인증서 타입 및 암호화 키 정보를 저장한 후 트랜잭션ID(transactionID)를 생성할 수 있다(652). 상기 트랜잭션 ID를 이용하여 SM-DP+(610)는 이후의 LPA(620)로부터의 요청 메시지가 유효한지 확인할 수 있다. 또한 상기 트랜잭션ID는 하나의 SM-DP+가 동시에 복수 개의 단말로부터의 요청을 처리할 수 있는 구분자 역할도 할 수 있다.
이후 SM-DP+(610)는 DP 챌린지(DP Challenge)를 생성할 수 있다(652). DP 챌린지는 SM-DP+의 챌린지 또는 프로파일제공서버의 챌린지일 수 있다. 상기 DP Challenge는 16 바이트의 랜덤 번호일 수 있다.
이후 SM-DP+(610)는 DP_Sign1을 생성할 수 있다(652). 상기 DP_Sign1은 SM-DP+(610)가 eUICC_Challenge, DP_Challgene, TransactionID를 포함하여 생성한 서명값일 수 있다.
상기 652 동작이 정상적으로 수행되면, SM-DP+(610)는 LPA(620)에 인증 정보를 전달할 수 있다(654). SM-DP+(610)는 LPA(620)에 상기 트랜잭션ID, DP Challenge, DP_Sign1, SM-DP_ 인증서, Cert_ToBe_Used 정보를 전달할 수 있다. 상기 SM-DP+ 인증서는 ECDSA (Elliptic Curved Digital Signature Algorithm) 인증서일 수 있다. 상기 Cer_ToBe_Used는 사용하기로 하고 SM-DP+(610)에 저장된 인증서 타입 및 암호화 키 정보를 포함하는 정보일 수 있다.
LPA(620)은 상기 전달받은 정보에 추가로 단말의 현재시간, 프로파일제공서버 주소, 프로파일 설치 키 (AC_Token), 단말 정보, 및 해쉬된 비밀코드(confirmation code)를 eUICC(630)에 전달할 수 있다(656). 상기 해쉬된 비밀코드는 상기 642 동작이 수행된 경우에 전달될 수 있다. 또한 상기 656 동작을 수행하기 전 LPA(620)은 트랜잭션ID와 상기 SM-DP+ 주소를 함께 매핑하여 저장할 수 있다.
eUICC(630)는 상기 656 동작에서 수신한 정보에 기반하여 SM-DP+(610)를 검증할 수 있다(658).
eUICC(630)는 먼저 SM-DP+ 인증서 CERT.DP.ECDSA 를 검증한다(658). 상기 검증은 EUICC(630)에 저장되어 있는 CI (Certificate Issuer) 인증서 또는 CI 인증서의 공개 키를 이용한 서명 검증 방식일 수 있다. 상기 서명 검증은 Cert_ToBe_use에 포함된 정보를 이용하여 선택한 공개 키를 이용한 검증일 수도 있다.
상기 검증이 통과하면 eUICC(630)는 전달받은 DP_Sign1을 검증한다(658). 상기 검증은 상기 SM-DP+ 인증서에 포함된 공개 키를 이용한 서명 검증일 수 있다. 만약 이 검증이 통과하면 eUICC(620)는 SM-DP_(610)를 인증한 것이 된다.
이후 eUICC(630)은 1회용 공개 키 및 개인 키 쌍을 생성할 수 있다(658). 상기 공개 키 및 개인 키 쌍은 SM-DP+(610)에서도 별도의 값으로 생성되는데, 이렇게 생성된 값 중 공개 키만을 서로 교환할 경우, 공개 키와 개인 키를 결합하여 세션 키를 공유할 수 있다. 이때 공개 키를 1회용으로 함으로써 매번 프로파일을 다운로드 할 때마다 새로운 세션키를 공유할 수 있다.
이때 상기 공개 키를 안전하게 전달하기 위해서는 상기 공개 키를 이용하여 서명 값(eUICC_Sign1)을 생성하고 전달할 수 있다(658). 이를 위해, eUICC(630)는 상기 eUICC(630)의 1회용 공개 키와 함께 상기 전달받은 DP Challenge를 포함하여 eUICC(630)에 사전에 저장되어 있는 개인 키를 이용하여 서명을 할 수 있다. 상기 DP Challenge를 포함하여 서명을 함으로써 추후 SM-DP+(610)는 eUICC(630)를 인증할 수 있다. 상기 서명에는 이외에도 Transaction ID, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 그리고 해쉬된 비밀코드 값 중 하나 이상의 정보를 포함될 수 있으며, 상기 서명에 추가적으로 포함되는 정보들은 SM-DP+(610)의 추가적인 검증에 사용될 수 있다. 편의상 상기 서명을 eUICC_Sign1이라 칭한다. 상기 서명 생성시 상기 전달받은 Cert_ToBe_Used에 사용된 인증서 Type 및 암호화 키 정보에 맞는 eUICC의 개인 키를 선택하여 서명을 생성할 수 있다.
eUICC(630)는 LPA(620)에 eUICC 인증 정보를 전달할 수 있다(660). 상기eUICC 인증 정보는 eUICC의 1회용 공개 키, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 해쉬된 비밀코드 값, eUICC_Sign1, eUICC의 인증서, eUICC 인증서를 발급한 EUM 인증서 중 적어도 하나를 포함할 수 있다.
LPA(620)은 SM-DP+(610)에게 프로파일 요청메시지를 전송할 수 있다(662). 상기 프로파일요청 메시지는 상기 eUICC(630)로부터 전달받은 eUICC 인증 정보를 SM-DP(610)에게 전달할 수 있다. LPA(620)은 상기 656 동작 수행 전 저장했던 트랜잭션ID와 대응되는 SM-DP+ 주소로 상기 트랜잭션ID, 1회용 eUICC 공개 키, SM-DP+ 주소, 프로파일 설치 키, 단말 정보, eUICC 정보, 해쉬된 비밀코드 정보, eUICC_Sign1, eUICC 인증서, eUICC 인증서를 발행한 EUM 인증서 중 하나 이상을 포함하여 SM-DP+(610)에 전달할 수 있다.
SM-DP+(610)는 상기 662 동작에서 수신한 트랜잭션 ID를 확인하여 유효한 트랜잭션 ID가 있는지 확인한 후 없으면 에러코드를 LPA(620)에 리턴하고 다운로드 과정을 종료할 수 있다. 유효한 트랜잭션 ID라 함은 SM-DP+의 저장소나 메모리에 상기 트랜잭션ID가 저장되어 조회가 가능하고, 상기 트랜잭션ID에 대응되는 SM-DP+가 상기 654 동작은 수행하였지만 662 동작에 대응하는 메시지를 처음으로 받은 것을 예로 들 수 있다. 다만 이미 662 동작의 메시지를 수신하였는데 같은 트랜잭션 ID로 662 동작의 메시지를 수신한 경우, 경우에 따라서 에러 코드를 리턴하지 않을 수도 있다. 예를 들면, 662동작에서 먼저 수신한 메시지에 대하여 이후 기술되는 664의 동작이 수행되는 도중에 두번째 프로파일 요청 메시지를 송신한 경우, 두번째 프로파일 요청 메시지에 대하여 에러코드를 리턴하지 않고, 상기 두번째 메시지를 버릴 수도 있다.
이후 유효한 트랜잭션으로 판단된 프로파일 요청에 대하여, SM-DP+(610)는 eUICC를 검증할 수 있다(664).
SM-DP+(610)는 상기 EUM(eUICC 제조사) 인증서를 검증할 수 있다(664). 상기 검증은 우선 SM-DP+(610)에 저장되어 있는 CI 인증서에서 공개 키를 추출하여 이용하거나 또는 저장되어 있는 공개 키를 직접 이용하여 상기 eUICC제조사 인증서의 서명을 검증하는 방식일 수 있다.
이후 SM-DP+(610)는 상기 EUM 인증서에서 추출한 인증서의 공개 키를 이용하여 상기 전달받은 eUICC 인증서에 포함된 서명값을 검증하여 상기 eUICC 인증서를 검증할 수 있다(664).
이후 SM-DP+(610)는 상기 검증된 eUICC 인증서에 포함된 공개 키를 이용하여 상기 eUICC_Sign1 값을 검증할 수 있다(664). 이때 검증에 통과하면 SM-DP+(610)는 eUICC(630)를 인증한 것이 된다.
이후 SM-DP+(610)는 프로파일 설치 키(AC_Token)이 유효한지 검증할 수 있다(664). 이는 해당 프로파일 설치 키가 SM-DP+의 저장소에 저장된 값에 포함되는지 및 저장된 프로파일 설치 키에 대응되는 다운로드 가능한 프로파일이 존재하는지를 확인하는 과정일 수 있다.
또한 선택적으로, SM-DP+(610)는 해쉬된 비밀코드를 검증할 수 있다(664). 이는 저장된 해쉬한 비밀코드와 단순한 비교하는 것일 수 있고, 새로 해쉬한 비밀코드를 계산하여 비교하는 방식일 수 있다.
이후 SM-DP+(610)는 단말정보, eUICC정보 등을 비교하여 프로파일 설치가 가능한지의 적격성 판단을 추가적으로 수행할 수 있다(664). 상기 정보에는 접속 가능한 망 종류 및 설치 가능한 메모리 영역 정보를 포함할 수도 있다.
이상과 같은 검증을 통과한 경우에만 SM-DP+(610)는 프로파일 다운로드를 승인한 후 이후의 과정을 진행할 수 있다. 만약 검증에 실패한 경우 SM-DP+(610)는 LPA(620)에 에러코드를 리턴하고 프로파일 다운로드 과정을 종료할 수 있다. 이 경우 다운로드 과정을 종료하기 전에 저장했던 트랜잭션 ID 및 DP Challenge를 삭제한다. 검증에 통과한 경우, 상술한 것처럼, SM-DP+(610)는 1회용 프로파일제공서버 공개 키 및 비밀키 쌍을 생성할 수 있다(664). 상기 1회용 비대칭키 쌍 생성에 사용하는 암호화 키 정보는 상기 654 동작에서 전달한 Cert_ToBe_Used에 포함되어 있는 암호화 키의 정보일 수 있다.
상술한 것처럼, SM-DP+(610)는 상기 비밀키 및 전달받은 1회용 eUICC 공개 키를 이용하여 세션키를 생성할 수 있다(664). 상기 세션키 생성에는 추가적으로 CRT 정보 및 EID 정보가 이용될 수 있다.
그리고 SM-DP+(610)는 DP_Sign2를 생성할 수 있다(664). 상기 DP_Sign2는 SM-DP+의 기 저장되어 있던 개인 키를 이용한 서명값이며, CRT, 1회용 DP 공개 키, 1회용 eUICC공개 키를 포함하는 값에 대한 서명값 계산일 수 있다.
또한, SM-DP+(610)는 상기 생성한 세션키를 이용하여 암호화된 프로파일 패키지를 생성할 수 있다(664). 상기 암호화된 프로파일 패키지라 함은 다음의 두 가지 방식 중 한가지 방식으로 생성될 수 있다.
- 방식1: 암호화되지 않은 프로파일 패키지에 대하여 생성한 세션키로 SCP03t 암호화 방식을 이용해서 암호화한 것
- 방식2: 암호화되지 않은 프로파일 패키지에 대하여 랜덤하게 기 생성한 랜덤키로 암호화된 프로파일 패키지와, 상기 랜덤키를 상기 생성한 세션키로 암호화한 암호랜덤키를 합친 것
상기 암호화된 프로파일 패키지에는 추가로 eUICC에서의 세션키 생성에 이용될 수 있는 CRT, 1회용 프로파일제공서버 공개 키 및 상기 생성한 DP_Sign2가 포함될 수 있다.
SM-DP+(610)는 LPA(620)에 상기 암호화된 프로파일 패키지를 전달할 수 있다(666).
LPA(620)은 eUICC(630)에게 프로파일 패키지를 전달할 수 있다(668). 이때, LPA(620)은 프로파일 패키지 중 비암호화 데이터를 전달할 수 있다. 상기 LPA(620)은 상기 암호화된 프로파일 패키지 중 암호화 되지 않은 데이터와 복수 개의 암호화된 데이터를 구분하고, 먼저 상기 암호화 되지 않은 데이터를 eUICC(630)에 전송할 수 있는 크기로 분할하여 상기 eUICC(630)에 전달할 수 있다. 상기 전달방법은 "STORE DATA" APDU를 이용한 방법일 수 있다.
또한, 상기 암호화 되지 않은 데이터의 구분은 상기 암호화된 프로파일 패키지에 포함된 태그(Tag) 값을 구분하는 방식일 수 있다. 상기 Tag 값은 암호화된 프로파일 패키지 중 첫 1 바이트(Byte) 또는 2 바이트 데이터이며, 이후의 길이 바이트 (Length Bytes)를 확인하여 상기 암호화되지 않은 데이터의 끝의 경계를 구분지어 전달할 수 있다.
상기 암호화되지 않은 데이터에는 상기 CRT, 1회용 DP 공개 키, DP_Sign2값이 포함될 수 있다.
eUICC(630)는 서명을 검증하고, 복호화키를 생성할 수 있다(670). 상기 eUICC(630)는 DP_Sign2를 검증할 수 있다. 이는 기 확인했던 SM-DP+ 인증서의 공개 키를 이용한 서명검증방식 일수 있다. 상기 검증에 통과하면 eUICC(630)는 상기 전달받은 CRT, 1회용 SM-DP+ 공개 키값, EID값, eUICC에만 저장된 1회용 eUICC 개인 키 값을 이용하여, 암호화된 프로파일 패키지 복호화를 위한 세션키를 생성할 수 있다.
LPA(620)는 암호화 데이터를 전달할 수 있다(672). 상기 LPA(620)는 상기 668 동작 수행 시 구분했던, 암호화되지 않은 데이터의 경계 다음부터를 암호화된 데이터로 확인하고, 특정 Tag가 있는지 확인하여 암호화된 데이터를 의미하는 Tag를 발견한 경우 그 다음 Length Byte를 확인하여 암호화된 데이터의 크기를 확인하며, 상기 암호화된 데이터만큼을 EUICC(630)에 전달할 수 있다. 이때, 상기 암호화된 데이터는 "STORE DATA" APDU 커맨드를 이용하여 eUICC(630)에 분할 전송될 수 있다.
LPA(620)는 그 다음 암호화된 데이터에 대하여 상기 672 동작과 유사한 과정을 수행하여 전송할 수 있다(674). 이때 전송되는 데이터는 상기 664 동작에서 방법2로 암호화된 패키지가 생성된 경우의 암호랜덤키일 수 있으며, eUICC(630)는 상기 암호랜덤키를 전달받은 경우 이후의 암호화 데이터에 대하여는 상기 암호랜덤키를 상기 세션키로 복호화하여 랜덤키를 추출한 후 상기 랜덤키를 이후의 암호화 데이터를 복호화하는 세션키로 사용할 수 있다.
LPA(620)은 암호화 데이터를 구분하는 또 다른 Tag값과 Length Byte를 확인하여 복수 개의 암호화 데이터를 구분지을 수 있고, 각각의 암호화 데이터에 대하여 복수 개의 "STORE DATA" 커맨드를 이용하여 eUICC(630)에 전달할 수 있다(676).
그러면 eUICC(630)는 각각의 암호화된 데이터에 대하여 상기 세션키 또는 복호화한 랜덤키를 이용하여 복호화를 수행한 후 내부에 포함된 프로파일 설치가능단위 정보를 이용하여 프로파일을 설치가능단위로 설치한다. 상기 설치가능단위 정보를 설치하여 그 다음 암호화된 데이터의 복호화를 수행할 수 있음은 물론이다. 이와 같은 동작을 반복하여 모든 암호화된 데이터의 전송, 복호화 및 모든 설치가능단위 정보의 설치가 완료되면 EUICC(630)는 해당 결과를 LPA(620)에 전달할 수 있고, 상기 결과는 SM-DP+(610)에도 전달 될 수 있다(678).
본 개시의 실시예에서 LPA(620)과 eUICC(630)를 분리하여 설명하였으나, eUICC는 단말의 내부에 포함되거나, 삽입된 것이다. 따라서 본 개시의 실시예에서 LPA와 eUICC 사이의 동작은 eUICC를 포함하는 단말의 내부 동작으로 해석할 수도 있다.
상기와 같은 동작에 따라서 eUICC와 SM-DP+에 대한 인증, 검증, 프로파일패키지 다운로드, 프로파일 패키지 전달, 프로파일 설치 동작이 수행될 수 있다.
상기 도 6의 프로파일 설치 동작이 완료되면, LPA(620)는 eUICC(630)에 프로파일의 활성화(Enable) 명령을 전달하여 프로파일을 활성화할 수 있고, 활성화된 프로파일을 이용하여 이동통신시스템과 인증을 수행한 후 이동통신망을 이용할 수 있다.
도 7a, 7b, 7c은 복수 단말을 위한 벌크 프로파일을 한번에 프로비져닝 하는 방법이다.
도 7을 참고하면, 상기 벌크 프로파일 설치과정은 설명의 편의상 eUICC 전달 단계(delivery phase)(720), 단말 생산 준비 단계(device production preparation phase)(730), 및 단말 생산 단계(device production phase)(740)로 구분될 수 있다.
먼저 eUICC 전달 단계 (eUICC Deliver Phase)(720)에 대해 설명한다.
SM-SR+(또는 Production Server)(704)는 eUICC 제조사 (EUM)(700)로부터 ProductionInfoNotifyRequest 메시지를 수신하여, eUICC N개에 대한 제품정보를 받을 수 있다(722). 상기 MS-SR+(704)는 상기 EUM에게 ProductionInfoNotifyResponse(ACK) 메시지를 송신할 수 있다(724).
eUICC(714)는 특정한 SM-SR+에 대해서만 이하의 동작을 수행하도록 설정될 수 있는데, SM-SR+을 특정하는 방법은 아래와 같은 두가지 방법이 있을수 있다.
- 상기 SM-SR+의 구분자를 EUM이 eUICC 제조시 사전 설정
- 특정 Credential을 SM-SR+에 전달하여 상기 Credential을 이용한 요청인 경우에만 eUICC가 특정 동작 수행
상기 eUICC N 개에 대한 제품정보는, eUICC Info, eUICC 인증서 및 미리 생성한 1회용 공개 키, EUM 인증서를 포함할 수 있다. 상기 제품정보는 추가로 상기 Credential을 포함할 수도 있다. 미리 생성한 1회용 공개 키는 오직 특정 SM-SR+를 통해서만 eUICC에서 사용될 수 있다.
이어서, 단말 생산 준비 단계 (Device Production Preparation Phase)(730)에 대해 설명한다.
SM-SR+(704)는 SM-DP+(702)에 BulkProfileRequest를 전달하여 복수 개의 프로파일을 다운로드 하기 위한 준비를 요청할 수 있다(732). 이때 상기 BulkProfileRequest는 다음 정보가 포함될 수 있다.
- 프로파일 타입 구분자
- SM-SR 인증서 및 서명값
- N개의 eUICC의 인증서, N개의 eUICC용 1회용 공개 키, N개의 eUICC 정보
상기 N개의 정보들은 SM-DP+(702)에서 eUICC에 매핑할 수 있는 형태로 전달될 수 있다.
상기 서명값은 1회용 공개 키를 포함하는 값에 대한 서명값일 수 있다.
SM-DP+(702)는 SM-SR+의 인증서 및 서명 값(SRToken0)을 검증할 수 있다(734).
상기 검증에 통과하면, SM-DP+(702) 는 1회용(ephemeral) 비대칭키 쌍(즉, 공개 키와 개인 키)을 생성하고, 상기 1회용 비대칭키 쌍을 상기 732 동작에서 전달받은 1회용 eUICC용 공개 키와 함께 사용하여 암호화 키를 생성할 수 있다(734). 상기 암호화 키는 프로파일을 암호화 하거나, 프로파일을 암호화한 대칭키를 암호화 하는데 사용될 수 있다.
SM-DP+(702)는 암호화한 프로파일, 상기 SM-DP+가 생성한 1회용 공개 키, SM-DP+의 서명값을 포함하는 Data 즉, ProfileInstallPackage를 N개 생성할 수 있다(734)
SM-DP+(702)는 SM-SR+(704)에게 BulkProfileResponse 메시지를 전달하여 상기 생성한 ProfileInstallPackage를 전달할 수 있다(736).
SM-SR+(704)는 SM-DP+로부터 받은 자료의 일부 혹은 전부를 포함한 값에 대하여, SM-SR+(704)의 서명값(SRToken1)을 계산할 수 있다(738). 상기 서명값은 SM-SR+(704)가 미리 가지고 있던 값일 수도 있고, 상기 722 단계에서 EUM으로부터 받은 "특정 Credential"을 이용한 서명값일 수도 있다.
이어서, 단말 생산 단계 (Device Production Phase)(740)에 대해 설명한다.
개별 단말(710)은 설명의 편의상 LPA(712)와 eUICC(714)로 구성된다고 설명된다. 상기 LPA(712)는 특정한 조건이 되면, SM-SR+(704)에게 FactoryEventRequest(EID) 메시지를 전송하여 프로파일 설치를 요청할 수 있다(742). 상기 특정한 조건은 단말의 생산 단계(예를 들어 단말의 제조 공장에서)에서 적용되는 것으로써, 예로써 다음과 같을 수 있다.
- 무선 통신, 유선 연결을 통해 명령 수신하면 수행
- 수동 조작을 통해 명령 수신하면 수행
- 특정 시간이 되면 수행
- 특정 위치를 통과하면 수행
이때 상기 FactoryEventRequest(742)를 보내기 전에 LPA(712)는 eUICC(714)로부터 eUICC Challenge 값을 수신할 수도 있다. 상기 FactoryEventRequest(742)는 EID, eUICC Challenge 중 하나 이상을 포함할 수 있다.
만약 상기 FactoryEventRequest(742)가 eUICC Challenge를 포함하는 경우, 상기 728 단계의 SM-SR+의 서명값 SRToken1은 eUICC Challenge를 포함하여 계산될 수도 있다.
SM-SR+(704)는 SM-DP+(702)의 서명 값, SM-SR+(704)의 서명값을 포함한 응답을 LPA에 전달할 수 있다(744).
LPA(712)는 eUICC(714)에게 SM-DP+(702) 서명 값, SM-SR+(704) 서명 값을 포함하는 Profile설치준비 메시지 GetAuthDataRequest를 전달할 수 있다(746).
eUICC(714)는 SM-SR+(704) 서명을 검증하고, 검증에 통과하면 SM-DP+(702) 서명을 검증한다(748). 만약 하나라도 검증에 실패하면, 에러를 리턴하고 이후 과정을 실행하지 않고 종료한다. 선택적으로, eUICC(714)는 SM-SR+(704)가 특정한 서버인지 확인할 수 있다. 상기 확인하는 방법은 SM-SR+(704)의 ID를 확인하는 방법 또는 서명값을 검증하는 방법일 수 있다. SM-SR+(704)이 권한있는 서버(즉, 특정한 서버)가 아니면 eUICC(714)는 1회용 비대칭키 쌍을 새로 생성하지만, SM-SR+(704)이 권한있는 서버(즉, 특정한 서버)인 경우 eUICC(714)는 1회용 비대칭키 쌍을 새로 생성하지 않고, 미리 생성한 1회용 비대칭키 쌍을 사용할 수 있다.
eUICC(714)는 1회용 공개 키 및 LPA로부터 전달받은 파라미터를 포함하는 데이터에 대하여 eUICC에 설정된 서명용 개인 키를 이용하여 eUICC 서명값 eUICCToken 을 생성할 수 있다(748).
이후 eUICC(714)는 LPA(712)에게 GetAuthDataResponse 메시지를 전달하여 상기 eUICC 서명값과 1회용 공개 키를 포함하는 데이터를 전달할 수 있다(750).
LPA(714)는 SM-SR+(704)에게 상기 전달받은 eUICC 서명값 및 1회용 공개 키를 포함하는 eUICCManagementRequest 메시지를 전달하여 프로파일 다운로드 요청할 수 있다(752).
SM-SR+(704)는 eUICC 서명값을 검증한다(754). 만약 검증에 실패하면, SM-SR+(704)는 에러를 리턴하고 이후 해당 단말의 프로파일 설치과정을 중단할 수 있다. 또한, 상기 SM-SR+(704)는 상기 736 단계에서 전달받은 암호화된 프로파일의 일부 또는 전체에 대해서 SM-SR+(704)의 서명용 개인 키를 이용하여 서명을 할 수 있다(754). 상기 암호화된 프로파일에는 SM-DP+(702)의 또다른 서명값이 포함될 수도 있다.
SM-SR+(704)는 LPA(712)에게 상기 752 단계의 응답으로 eUICCManagementResponse 메시지를 전달하여 암호화된 프로파일, SM-SR+(704)의 서명 값을 전달할 수 있다(756).
LPA(712)는 eUICC(714)에게 EstablishSecureChannelRequest 메시지를 전달하여 SM-SR+(704) 서명값 SRToken2, SM-DP+(702)의 1회용 공개 키, SM-DP+(702)의 1회용 공개 키를 포함한 데이터에 대하여 SM-DP+의 서명용 개인 키로 서명한 서명값 DPToken2을 전달할 수 있다(758).
eUICC(714)는 SM-SR+(704)의 서명값을 검증할 수 있다(760). 만약 검증에 실패하면, eUICC(714)는 LPA(712)에게 에러를 리턴하고, 이후의 프로파일 설치과정을 종료할 수 있다.
SM-SR+(704)의 서명값 검증에 성공하면, 상기 eUICC(714)는 SM-DP+(702) 서명값을 검증할 수 있다(760). 만약 검증에 실패하면, 상기 eUICC(714)는 에러를 리턴하고, 이후의 프로파일 설치과정을 종료할 수 있다.
SM-DP+(702) 서명값 검증에 성공하면, 상기 eUICC(714)는 LPA(712)로부터 전달받은 SM-DP+(702)의 1회용 공개 키와 eUICC(714)의 1회용 개인 키를 이용하여 암호화 키를 생성할 수 있다(760).
eUICC(714)는 상기 758 단계에서 수신한 메시지에 대한 응답으로 EstablishSecureChannelResponse 메시지를 LPA(712)에 전달할 수 있다(762).
LPA(712)는 eUICC(714)에게 InstallProfileRecordRequest 메시지를 전달하여 암호화된 ProfileRecord 정보(즉, 메타데이터)를 전달할 수 있다(764).
eUICC(714)는 암호화된 ProfileRecord 를 상기 760단계에서 생성한 암호화 키로 복호화 한후, 설치할 수 있다. 그리고 상기 eUICC(714)는 LPA(712)에게 상기 764 단계에서 수신한 메시지에 대한 응답으로 InstallProfileRecordResponse 메시지를 전달할 수 있다(766).
선택적으로, LPA(712)는 암호화된 프로파일 보호 키 (Profile Protection Key; PPK) 를 eUICC(714)에게 전달할 수 있다(768). 그러면 상기 eUICC(714)는 암호화된 PPK를 상기 760 단계에서 생성한 암호화 키로 복호화후, LPA(712)에게 응답 메시지를 전달할 수 있다(770).
이후 LPA(712)는 암호화된 PPB(Profile Package Block)을 eUICC(714)에 전달할 수 있다(772).
eUICC(714)는 암호화된 PPB을 상기 760단계의 암호화 키 또는 상기 770단계의 PPK를 이용하여 복호화 할 수 있다(773). 만약 복호화에 실패하면 상기 eUICC(714) 에러코드를 리턴하고 이후의 프로파일 설치과정을 종료할 수 있다. 복호화가 성공되면, 상기 eUICC(714)는 복호화된 PPB 단독으로 혹은 이전에 전달받은 PPB의 일부 또는 전체와 결합하여 설치가능단위인 Profile Element가 하나 이상 구성되는지 확인하여 설치 가능한 Profile Element 들을 설치하고, Profile Element 구성에 사용되지 않은 일부 또는 전체가 존재하면 그 뒤에 다른 PPB의 일부 또는 전체들과 합쳐져 Profile Element로 구성될 수 있도록 버퍼에 저장할 수 있다.
eUICC(714)는 LPA(712)에 상기 772 단계의 메시지에 대한 응답을 전달할 수 있다(774).
만약 암호화된 PPB가 M개 있다면, 상기 772, 773, 774 동작은 M번 반복될 수 있다.
마지막 PPB까지 잘 설치되면, eUICC(714)는 eUICC 서명이 포함된 프로파일이 설치 완료 메시지를 LPA(712)에 전달할 수 있다.
LPA(712)는 프로파일 설치가 완료된후 eUICC 서명을 포함한 설치완료알림 메시지 NotifyResultRequest 를 SM-SR+(704)에 전달할 수 있고(776), 상기NotifyResultRequest 메시지에 대한 응답을 수신할 수 있다(778).
LPA(712)는 추가적으로 eUICC(714)에서 설치한 프로파일을 인에이블할 수도 있다(780).
상기 742 내지 780 동작들은 개별 단말에 대하여 동작하는 것이므로, N개의 단말에 대하여 상기 동작이 반복 수행될 수 있다.
마지막으로, SM-SR+(704)는 SM-DP+(702)에게 벌프 프로파일 프로비져닝 결과를 통보하고(792), 응답을 수신할 수 있다. 설명의 편의상 상기 792, 794 동작은 벌크 프로비져닝 결과 통보 단계(790)로 지칭될 수 있다.
이하에서는 단말의 eUICC 에게 프로파일을 제공하는 시스템 내의 엔티티 간 인터페이스, 기능(function) 및 상기 기능을 위한 메시지를 정의한다.
표 2는 시스템 내의 단말(LPA)-서버간 또는 서버-서버간 인터페이스의 기능 및 프로토콜을 예시한다.
Figure 112017112361107-pct00002
표 3은 시스템 내의 단말(LPA)-eUICC간 인터페이스의 기능 및 프로토콜을 예시한다.
Figure 112017112361107-pct00003
먼저, 상기 표 2에서 예시된 기능(메시지)들에 대하여 자세히 설명한다.
상기 표 2에서 예시된 단말-서버간 및 서버-서버간 인터페이스 기능들은 HTTPS(hyper text transfer protocol over secure socket layer) 프로토콜을 통해 JSON(JavaScript Object Notation) 형식의 데이터 오브젝트를 이용하여 통신될 수 있다.
HTPP 헤더에는 HTTP 요청(Request)을 위한 헤더와 HTTP 응답(Response)를 위한 헤더가 있다.
HTTP 요청 헤더는 다음 표 4의 포맷을 가질 수 있다.
Figure 112017112361107-pct00004
HTTP 요청의 방법(method)는 HTTP 포스트(POST) 방법일 수 있다. 상기 표 4을 참고하면, 상기 HTTP 요청의 리소스 "<uri>"(: uniform resource identifier)는 "<query path>"(: 쿼리 경로)로써 설정될 수 있고, 예를 들어 "/v1/es9/euicc-mgmt"와 같은 값을 가질 수 있다.
상기 HTTP 요청 헤더는 예를 들어, "Content-type", "Content-length", "Host", 및 "X-Admin-Protocol"의 필드(field)를 포함할 수 있고, 각각의 용도는 다음 표 5와 같이 정의될 수 있다.
Figure 112017112361107-pct00005
상기 표 5에서 MOC(Mandatory / Optional / Conditional)의 값은 M(필수적), O(선택적), 또는 C(조건적)일 수 있다.
HTTP 응답 헤더는 다음 표 6의 포맷을 가질 수 있다.
Figure 112017112361107-pct00006
이제, 상기 표 2에 예시된 기능들의 상세 메시지들을 설명한다.
ES1 인터페이스(: EUM과 SM-SR+간 인터페이스)의 기능인 "ES1_ProductInfoNotifyRequest"는, 벌크(bulk) 프로파일 프로비져닝을 위해, EUM이 미리 생성된 ePK(ephemeral public key; 1회용 공개 키) 리스트를 SM-SR+에게 전달하는 메시지이다. 벌크 프로파일 프로비져닝이란 예를 들어, 공장 생산 시나리오와 같이 다수의 프로파일 프로비져닝일 수 있다. 상기 ES1_ProductInfoNotifyRequest 메시지의 <query path>는 예를 들어, "/v1/es1/product-info-notify"일 수 있다.
상기 ES1_ProductInfoNotifyRequest 메시지의 요청(request) 메시지에 해당하는 JSON 바디(body) 스키마(schema)는 예를 들어 다음 표 7과 같다.
Figure 112017112361107-pct00007
상기 ES1_ProductInfoNotifyRequest 메시지의 응답(response) 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 8과 같다.
Figure 112017112361107-pct00008
ES2 인터페이스(: MNO와 SM-DP+간 인터페이스)의 기능인 "ES2_DownloadProfileRequest"는 MNO가 SM-DP+에게 프로파일의 다운로드를 요청하는 메시지이다. 상기 ES2_DownloadProfileRequest 메시지의 <query path>는 예를 들어, "/v1/es2/download-profile"일 수 있다.
상기 ES2_DownloadProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 9과 같다.
Figure 112017112361107-pct00009
Figure 112017112361107-pct00010
Figure 112017112361107-pct00011
Figure 112017112361107-pct00012
Figure 112017112361107-pct00013
상기 ES2_DownloadProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 10과 같다.
Figure 112017112361107-pct00014
ES2 인터페이스(: MNO와 SM-DP+간 인터페이스)의 기능인 "ES2_ActivationVoucherRequest"는 MNO가 SM-DP+에게 바우처(voucher)의 활성화를 요청하는 메시지이다. 상기 ES2_ActivationVoucherRequest 메시지의 <query path>는 예를 들어, "/v1/es2/activation-voucher"일 수 있다.
상기 ES2_ActivationVoucherRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 11과 같다.
Figure 112017112361107-pct00015
상기 ES2_ActivationVoucherRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 12과 같다.
Figure 112017112361107-pct00016
ES2 인터페이스의 기능인 "ES2_NotifyResultRequest"는 SM-DP+가 MNO에게 이벤트의 결과 통보(notify)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es2/notify-result"일 수 있다.
상기 ES2_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 13과 같다.
Figure 112017112361107-pct00017
상기 ES2_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 14과 같다.
Figure 112017112361107-pct00018
ES3 인터페이스(: SM-DP+와 SM-SR+간 인터페이스)의 기능인 "ES3_eUICCManagementRequest"는 eUICC로의 원격 프로파일 다운로드를 SM-DP+가 SM-SR+에게 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/euicc-mgmt"일 수 있다.
상기 ES3_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 15과 같다.
Figure 112017112361107-pct00019
상기 ES3_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 16과 같다.
Figure 112017112361107-pct00020
ES3 인터페이스의 기능인 "ES3_DownloadProfileRequest"는 SM-SR+가 SM-DP+에게 프로파일의 다운로드를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/download-profile"일 수 있다.
상기 ES3_DownloadProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 17과 같다.
Figure 112017112361107-pct00021
상기 ES3_DownloadProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 18과 같다.
Figure 112017112361107-pct00022
ES3 인터페이스의 기능인 "ES3_ProfileRequest"는 SM-SR+가 SM-DP+에게 프로파일의 생성을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/profile"일 수 있다.
상기 ES3_ProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 19과 같다.
Figure 112017112361107-pct00023
상기 ES3_ProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 20과 같다.
Figure 112017112361107-pct00024
ES3 인터페이스의 기능인 "ES3_NotifyResultRequest"는 SM-SR+가 SM-DP+에게 이벤트 결과의 통보(notify)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/notify-result"일 수 있다.
상기 ES3_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 21과 같다.
Figure 112017112361107-pct00025
상기 ES3_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 22와 같다.
Figure 112017112361107-pct00026
ES3 인터페이스의 기능인 "ES3_BulkProfileRequest"는 SM-SR+가 SM-DP+에게 하나 또는 그 이상의 프로파일을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/bulk-profile"일 수 있다.
상기 ES3_BulkProfileRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 23과 같다.
Figure 112017112361107-pct00027
상기 ES3_BulkProfileRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 24와 같다.
Figure 112017112361107-pct00028
ES3 인터페이스의 기능인 "ES3_NotifyResultBulkRequest"는 SM-SR+가 SM-DP+에게 벌크 프로파일 프로비져닝 이벤트의 결과 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es3/notify-result-bulk"일 수 있다.
상기 ES3_NotifyResultBulkRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 25와 같다.
Figure 112017112361107-pct00029
상기 ES3_NotifyResultBulkRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 26과 같다.
Figure 112017112361107-pct00030
ES4 인터페이스(: MNO와 SM-SR+간 인터페이스)의 기능인 "ES4_eUICCManagementRequest"는 MNO가 SM-SR+에게 eUICC의 원격 플랫폼/프로파일 관리를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/euicc-mgmt"일 수 있다.
상기 ES4_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 27과 같다.
Figure 112017112361107-pct00031
Figure 112017112361107-pct00032
Figure 112017112361107-pct00033
Figure 112017112361107-pct00034
Figure 112017112361107-pct00035
Figure 112017112361107-pct00036
Figure 112017112361107-pct00037
상기 ES4_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 28과 같다.
Figure 112017112361107-pct00038
ES4 인터페이스의 기능인 "ES4_TerminalRequest"는 SM-SR+가 MNO에게 디바이스 스왑(swap) 또는 로컬 삭제(local delete)에 대한 인증(authorization) 결과 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/terminal"일 수 있다.
상기 ES4_TerminalRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 29와 같다.
Figure 112017112361107-pct00039
상기 ES4_TerminalRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 30과 같다.
Figure 112017112361107-pct00040
ES4 인터페이스의 기능인 "ES4_NotifyResultRequest"는 SM-SR+가 MNO에게 이벤트 결과의 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es4/notify-result"일 수 있다.
상기 ES4_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 31과 같다.
Figure 112017112361107-pct00041
상기 ES4_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 32와 같다.
Figure 112017112361107-pct00042
ES9 인터페이스(: LPA와 SM-SR+간 인터페이스)의 기능인 "ES9_EventRequest"는 LPA가 SM-SR+에게 특정 이벤트 ID에 해당하는 이벤트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/event"일 수 있다.
상기 ES9_EventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 33과 같다.
Figure 112017112361107-pct00043
상기 ES9_EventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 34과 같다.
Figure 112017112361107-pct00044
ES9 인터페이스의 기능인 "ES9_eUICCManagementRequest"는 LPA가 SM-SR+에게 eUICC의 원격 플랫폼/프로파일 관리를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/euicc-mgmt"일 수 있다.
상기 ES9_eUICCManagementRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 35와 같다.
Figure 112017112361107-pct00045
상기 ES9_eUICCManagementRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 36과 같다.
Figure 112017112361107-pct00046
ES9 인터페이스의 기능인 "ES9_TerminalRequest"는 LPA가 SM-SR+에게 프로파일 다운로드, 디바이스 스왑 또는 프로파일의 로컬 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/terminal"일 수 있다.
상기 ES9_TerminalRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 37과 같다.
Figure 112017112361107-pct00047
Figure 112017112361107-pct00048
상기 ES9_TerminalRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 38과 같다.
Figure 112017112361107-pct00049
ES9 인터페이스의 기능인 "ES9_TerminalAuthRequest"는 LPA가 SM-SR+에게 로컬 프로파일 관리의 권한인증(Authorization)을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/terminal-auth"일 수 있다.
상기 ES9_TerminalAuthRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 39와 같다.
Figure 112017112361107-pct00050
상기 ES9_TerminalAuthRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 40과 같다.
Figure 112017112361107-pct00051
ES9 인터페이스의 기능인 "ES9_NotifyResultRequest"는 LPA가 SM-SR+에게 이벤트 결과의 통보를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/notify-result"일 수 있다.
상기 ES9_NotifyResultRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 41와 같다.
Figure 112017112361107-pct00052
Figure 112017112361107-pct00053
Figure 112017112361107-pct00054
Figure 112017112361107-pct00055
Figure 112017112361107-pct00056
Figure 112017112361107-pct00057
상기 ES9_NotifyResultRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 42과 같다.
Figure 112017112361107-pct00058
ES9 인터페이스의 기능인 "ES9_FactoryEventRequest"는 LPA가 SM-SR+에게 벌크 프로파일 프로비져닝에서 특정 eUICC를 위한 프로파일 다운로드 이벤트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/factory-event"일 수 있다.
상기 ES9_FactoryEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 43과 같다.
Figure 112017112361107-pct00059
상기 ES9_FactoryEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 44와 같다.
Figure 112017112361107-pct00060
ES9+ 인터페이스(: LPA 와 SM-DP+ 사이의 인터페이스)의 기능인 "ES9+.InitiateAuthentication"는 LPA가 SM-DP+에게 인증 초기화를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/init-auth"일 수 있다.
상기 ES9+.InitiateAuthentication 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 45와 같다.
Figure 112017112361107-pct00061
상기 ES9+.InitiateAuthentication 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 46과 같다.
Figure 112017112361107-pct00062
LPA에서 SM-DP+로 전송되는 ES9+.InitiateAuthentication HTTP 요청 메시지의 일 예가 표 47에서 보여진다.
Figure 112017112361107-pct00063
SM-DP+에서 LPA로 전송되는 ES9+.InitiateAuthentication HTTP 응답 메시지의 일 예가 표 48에서 보여진다.
Figure 112017112361107-pct00064
ES9+ 인터페이스의 기능인 "ES9.GetBoundProfilePackage"는 LPA가 SM-DP+에게 결합된 프로파일 패키지(BPP)를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es9/get-bound"일 수 있다.
상기 ES9.GetBoundProfilePackage 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 49와 같다.
Figure 112017112361107-pct00065
상기 ES9.GetBoundProfilePackage 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 50과 같다.
Figure 112017112361107-pct00066
ES11 인터페이스(: LPA와 SM-DS 간 인터페이스)의 기능인 "ES11_PSRequest" 또는 "ES11_PSListRequest"는 LPA가 SM-DS에게 푸쉬(push) 서비스 또는 푸쉬 서비스의 리스트를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service"일 수 있다.
상기 ES11_PSRequest 또는 ES11_PSListRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 51과 같다.
Figure 112017112361107-pct00067
상기 ES11_PSRequest 또는 ES11_PSListRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 52와 같다.
Figure 112017112361107-pct00068
ES11 인터페이스의 기능인 "ES11_PSRegistrationRequest"는 LPA가 SM-DS에게 상기 LPA를 푸쉬 통보(push notification)을 위해 등록 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service/registration"일 수 있다.
상기 ES11_PSRegistrationRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 53과 같다.
Figure 112017112361107-pct00069
상기 ES11_PSRegistrationRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 54과 같다.
Figure 112017112361107-pct00070
ES11 인터페이스의 기능인 "ES11_PSConfirmRequest"는 LPA가 SM-DS에게 푸쉬 서비스의 등록 결과 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/push-service/confirm"일 수 있다.
상기 ES11_PSConfirmRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 55와 같다.
Figure 112017112361107-pct00071
상기 ES11_PSConfirmRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 56과 같다.
Figure 112017112361107-pct00072
ES11 인터페이스의 기능인 "ES11_EventIDRequest"는 LPA가 SM-DS에게 특정 EID에 관련된 하나 이상의 펜딩(pending) 이벤트 ID를 반환 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/event-id"일 수 있다.
상기 ES11_EventIDRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 57과 같다.
Figure 112017112361107-pct00073
상기 ES11_EventIDRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 58과 같다.
Figure 112017112361107-pct00074
ES11 인터페이스의 기능인 "ES11_DeleteEventRequest"는 LPA가 SM-DS에게 특정 이벤트의 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es11/delete-event"일 수 있다.
상기 ES11_DeleteEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 59와 같다.
Figure 112017112361107-pct00075
상기 ES11_DeleteEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 60과 같다.
Figure 112017112361107-pct00076
ES12 인터페이스(: SM-SR+와 SM-DS 사이의 인터페이스)의 기능인 "ES12_RegisterEventRequest"는 SM-SR+가 SM-DS에게 이벤트의 삽입을 요청하는 메시지이다. 푸쉬 토큰(push token)이 EID를 위해 등록되면, SM-DS는 해당 푸쉬 서버로 푸쉬 토큰을 송신한다. 상기 메시지의 <query path>는 예를 들어, "/v1/es12/register-event"일 수 있다.
상기 ES12_RegisterEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 61과 같다.
Figure 112017112361107-pct00077
상기 ES12_RegisterEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 62와 같다.
Figure 112017112361107-pct00078
ES12 인터페이스의 기능인 "ES12_DeleteEventRequest"는 SM-SR+가 SM-DS에게 특정 이벤트의 삭제를 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es12/delete-event"일 수 있다.
상기 ES12_DeleteEventRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 63과 같다.
Figure 112017112361107-pct00079
상기 ES12_DeleteEventRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 64와 같다.
Figure 112017112361107-pct00080
ES13 인터페이스(: LPA와 MNO 사이의 인터페이스)의 기능인 "ES13_URLRequest"는 LPA가 MNO에게 가입 요청(subscription request) 또는 활성 바우처(activation voucher) 검증(validation)을 처리하기 위한 URL 반환을 요청하는 메시지이다. 상기 메시지의 <query path>는 예를 들어, "/v1/es13/url"일 수 있다.
상기 ES13_URLRequest 메시지의 요청 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 65와 같다.
Figure 112017112361107-pct00081
상기 ES13_URLRequest 메시지의 응답 메시지에 해당하는 JSON 바디 스키마는 예를 들어 다음 표 66과 같다.
Figure 112017112361107-pct00082
이어서, 상기 표 3에서 예시된 기능(메시지)들에 대하여 자세히 설명한다.
상기 표 3에서 예시된 단말-eUICC 간 인터페이스(즉, ES10)의 기능들은 APDU(application protocol data unit) 프로토콜을 통해 TLV(tag length value) 형식의 데이터 오브젝트를 이용하여 통신될 수 있다.
단말-eUICC 간 ES10 인터페이스는 다음의 요구사항(requirement)를 만족시킬 수 있다. 상기 요구사항은, APDU를 송신하기 전에, 단말(즉, LPA)은 "MANAGE CHANNEL" 명령어(command)를 이용하여 논리 채널을 오픈하고, "SELECT" 명령을 이용하여 TAF 어플리케이션을 선택하고, TAF 를 위한 AID는 예를 들어, "A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 03 00"와 같은 값을 갖는 것이다.
단말-eUICC 간 ES10 인터페이스를 위한 기능에는 RMF(Remote Management Function)와 LMF(Local Management Function)가 있다.
먼저, 상기 RMF에 대해 설명한다.
LPA는 "STORE DATA" 명령어를 전송함으로써 eUICC의 RMF를 호출(call)할 수 있다. 상기 "STORE DATA" 명령어의 데이터 필드는 표 67에 따라서 코딩될 수 있다.
Figure 112017112361107-pct00083
상기 "STORE DATA" 명령어의 데이터 크기가 255 바이트보다 클 경우, 상기 데이터는 쪼개질(split) 수 있고, 다수의 "STORE DATA" 명령어를 통해 송신될 수 있다.
상기 "STORE DATA" 명령어의 응답 데이터는 다음 표 68에 따라서 코딩될 수 있다.
Figure 112017112361107-pct00084
상기 응답 데이터 크기가 255 바이트보다 클 경우, 명령어의 연쇄(chaining)가 수행될 수 있다. 즉, 상기 응답 데이터는 다수의 "GetResponse" 명령어를 이용함으로써 LPA에 의해 조회(retrieve)될 수 있다. 상기 데이터 필드의 Tag의 값은 ASN.1(Abstract Syntax Notation One)의 AUTOMATIC TAG 옵션을 통해 자동적으로 할당될 수 있다.
RMF는 원격 관리 요청(Remote Management Request) TLV와 원격 관리 응답(Remote Management Response) TLV를 포함할 수 있다. 원격 관리 요청 TLV는, "STORE DATA" 명령어를 이용함으로써 LPA로부터 eUIICC로 전달될 수 있다. eUICC는 상기 전달된 원격 관리 요청 TLV에 대한 응답으로써, "STORE DATA APDU" 응답 또는 "GET RESPONSE APDU" 응답을 이용하여 원격 관리 응답 TLV를 전송할 수 있다.
상기 RMF의 예를 설명한다.
LPA는 eUICC에게 SM-SR+, SM-DP+ 또는 SM-SR+의 인증을 준비하도록 트리거(trigger)하기 위해 "GetAuthData" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 GetAuthData 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 69와 같다.
Figure 112017112361107-pct00085
상기 GetAuthData 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 70과 같다.
Figure 112017112361107-pct00086
LPA는 eUICC에게, 세션 키 승인(session key agreement)를 위한 파라메터를 전달하기 위해 "EstablishSecureChannel" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 EstablishSecureChannel 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 71과 같다.
Figure 112017112361107-pct00087
상기 EstablishSecureChannel 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 72과 같다.
Figure 112017112361107-pct00088
LPA는 eUICC에게, 수립된 보안 채널 SCP03t에 의해 보호되는 ProfileRecordPart2를 전달하기 위해 "InstallProfileRecord" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 InstallProfileRecord 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 73와 같다.
Figure 112017112361107-pct00089
eUICC 가 상기 InstallProfileRecord 요청 메시지를 수신하고, 유효한 SCP03t 채널이 수립되어 있으면, 상기 eUICC는 상기 요청 TLV 내의 "SCP03tCommandTLV"를 지시되는 보안 채널의 세션 키 SCP03으로 처리한다. 반면, 유효한 채널 SCP03t가 없다면, 상기 eUICC는 실패를 지시하는 응답 TLV를 반환할 것이다.
상기 InstallProfileRecord 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 74과 같다.
Figure 112017112361107-pct00090
LPA는 eUICC에게, 미리 생성되고 프로파일 패키지를 보호하는데 사용되는 profileProtectionKey로써 수립된 세션 키를 대체하기 위해 상기 profileProtectionKey를 전달하는 "UpdateSessionKey" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 UpdateSessionKey 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 75와 같다.
Figure 112017112361107-pct00091
상기 UpdateSessionKey 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 76와 같다.
Figure 112017112361107-pct00092
LPA는 eUICC에게, SM-SR+ 또는 SM-DP+ 로부터 수신한 데이터 SecuredProfilePackageBlock 를 전달하는 "InstallProfilePackageBlock" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 InstallProfilePackageBlock 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 77과 같다.
Figure 112017112361107-pct00093
상기 InstallProfilePackageBlock 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 78과 같다.
Figure 112017112361107-pct00094
여기서, sign_result는 자신(상기 sign_result)을 제외한 EventResult 내의 모든 값 데이터에 대해서 SK_eUICC_ECDSA을 이용하여 계산될 수 있다. 예를 들어, eventType = getProfileRegistry 인 경우 상기 sign_result는 resultCode|eID|eventID|profileRegistry에 대해 서명(sign)된 결과이다.
LPA는 eUICC에게, 보안 채널 및 관련된 세션 키를 해제하도록 "ReleaseSecureChannel" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 ReleaseSecureChannel 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 79과 같다.
Figure 112017112361107-pct00095
eUICC가 상기 ReleaseSecureChannel 요청 메시지를 수신하면, 상기 eUICC 는 저장하고 있는 SCP03t 보안 채널 세션 키 셋트를 제거할 수 있다.
상기 ReleaseSecureChannel 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 80와 같다.
Figure 112017112361107-pct00096
LPA는 eUICC에게, SM-SR+로부터 전달된 ES9_eUICCManagementResponse 메시지 내에 포함된 srToken2와 이벤트를 전달하기 위해 "eUICCManagement" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 eUICCManagement 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 81과 같다.
Figure 112017112361107-pct00097
상기 eUICCManagement 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 82과 같다.
Figure 112017112361107-pct00098
여기서, 이벤트 및 eventResult의 세부 구조는 더 정의될 수 있다.
LPA는 eUICC에게, 디바이스 스왑 인증 또는 로컬 삭제 인증을 위한 SM-SR+ 의 인증을 준비하도록 eUICC 를 트리거하기 위해 "TerminalAuth" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 TerminalAuth 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 83와 같다.
Figure 112017112361107-pct00099
상기 TerminalAuth 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 84과 같다.
Figure 112017112361107-pct00100
이어서, 상기 LMF에 대해 설명한다.
LPA는 "STORE DATA" 명령어를 전송함으로써 eUICC의 LMF를 호출할 수 있다. 상기 "STORE DATA" 명령어의 데이터 필드는 표 85에 따라서 코딩될 수 있다.
Figure 112017112361107-pct00101
상기 "STORE DATA" 명령어의 데이터 크기가 255 바이트보다 클 경우, 상기 데이터는 쪼개질(split) 수 있고, 다수의 "STORE DATA" 명령어를 통해 송신될 수 있다.
상기 "STORE DATA" 명령어의 응답 데이터는 다음 표 86에 따라서 코딩될 수있다.
Figure 112017112361107-pct00102
상기 응답 데이터 크기가 255 바이트보다 클 경우, 명령어의 연쇄가 수행될 수 있다. 즉, 상기 응답 데이터는 다수의 "GetResponse" 명령어를 이용함으로써 LPA에 의해 조회될 수 있다. 상기 데이터 필드의 Tag의 값은 ASN.1의 AUTOMATIC TAG 옵션을 통해 자동적으로 할당될 수 있다.
LMF는 로컬 관리 요청(Local Management Request) TLV와 로컬 관리 응답(Local Management Response) TLV를 포함할 수 있다. 로컬 관리 요청 TLV는, "LOCAL STORE DATA" 명령어를 이용함으로써 LPA로부터 eUIICC로 전달될 수 있다. eUICC는 상기 전달된 로컬 관리 요청 TLV에 대한 응답으로써, "STORE DATA APDU" 응답 또는 "GET RESPONSE APDU" 응답을 이용하여 로컬 관리 응답 TLV를 전송할 수 있다.
상기 LMF의 예를 설명한다.
LPA는 eUICC에게, 로컬 관리 이벤트에 대한 자세한 정보를 포함하는 localEvent를 전달하기 위해 "LocalManagement" 요청 메시지를 전송하고, eUICC로부터 응답 메시지를 수신할 수 있다.
상기 LocalManagement 메시지의 요청 메시지의 스키마는 예를 들어 다음 표 87과 같다.
Figure 112017112361107-pct00103
상기 메시지의 응답 메시지의 스키마는 예를 들어 다음 표 88과 같다.
Figure 112017112361107-pct00104
만일, localEventType이 getProfileRegistry 이면, eUICC는 ES10_eUICCManagementResponse를 통해서 LPA에게 ProfileRegistry를 전달할 수 있다.
특정 프로파일이 event.profileID 에 의해 지시되는 경우, eventResult 내의 ProfileRegistry는 상기 프로파일의 ProfileRecord를 포함할 수 있다. 상기 event.profileID이 NULL인 경우, ProfileRegistry는 모든 프로파일의 ProfileRecords를 포함할 수 있고, 상기 프로파일의 authorizedSR 은 요청하는 SM-SR+의 SRID를 포함할 수 있다.
localEventResult, defaultSR, 그리고 ownerMNO TLV는, localEventType이 {enableProfile, disableProfile, 또는 deleteProfile} 중의 하나의 값을 가지고 PPRLocalMgmtNotification.notiEventList가 상응하는 EventToBeNotified 를 포함할 때에 LocalManagementResponse 내에 존재한다.
여기서, sign_Result는 자신(상기 sign_Result)을 제외한 LocalEventResult 내의 모든 값 데이터에 대해서 SK_eUICC_ECDSA을 이용하여 계산될 수 있다. 예를 들어, eventType이 'disableProfile'인 경우, 상기 sign_Result는 resultCode|localEventType|eID|profileID|timestamp에 대해서 계산될 수 있다.
본 개시에서 사용되는 서명 인증(signature verification)용 인증서(certificate) CERT_ECDSA는 다음 표 89과 같은 포맷을 가질 수 있다.
Figure 112017112361107-pct00105
상기 인증서 CERT_ECDSA에서 서명(signature) '5F37'의 계산에 이용되는 개인 키(private key)는 다음과 같다.
- CERT_CI_ECDSA, CERT_DP_ECDSA, CERT_SR_ECDSA, CERT_EUM_ECDSA 에 사용되는 SK.CI.ECDSA
- CERT_EUICC_ECDSA 에 사용되는 SK.EUM.ECDSA
서명될 데이터는 태그(Tag) '93', '42', '5F20', '95', '5F25', '5F24', '73', 'TBD' (있다면), 및 '7F49' 이다.
태그 'TBD' (즉, PLMNID의 리스트)는, 태그 '73' (즉, Discretionary data) 내의 태그 'C8'의 값이 '01 SM-DP+ Certificate'를 지시할 경우에 존재한다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 Discretionary Data (: 자유 데이터)는 다음 표 90와 같은 포맷을 가질 수 있다
Figure 112017112361107-pct00106
상기 Discretionary Data는 EUM certificate 인지(예를 들어, '04', '03') CI certificate 인지(예를 들어, '05')를 구분하는 구분자가 포함되어 있음을 주목해야 한다. 상기 Discretionary Data 를 이용함으로써, eUICC 또는 SM-SR+는 eUICC 인증서와 함께 EUM 인증서를 전송하는 것이 가능해진다. 상기 전송된 EUM 인증서를 이용함으로써, SM-DP+는 별도로 상기 EUM 인증서를 획득할 필요가 없고, CI 인증서를 통해 상기 eUICC를 인증할 수 있어서 상호운용성(interoperability)이 증가하는 효과가 발생한다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 List of PLMNIDs (: PLMNID의 리스트)는 다음 표 91과 같은 포맷을 가질 수 있다
Figure 112017112361107-pct00107
상기 'List of PLMNIDs' TLV는, 상기 데이터 오브젝트 Discretionary data 내의 태그 'C8'의 값이 '01 SM-DP+ Certificate'를 지시할 경우에 존재한다. 상기 'List of PLMNIDs' TLV의 값은 일련의 PLMN ID인데, 구분자(delimiter) '%'에 의개 구분된다. 예를 들어, 상기 'List of PLMNIDs' TLV가 두개의 PLMN ID '45008' 및 '310280'을 나타낼 때, 값은 '45008%310280'와 같을 수 있다. 상기 'List of PLMNIDs' TLV 의 ASN.1 표기법에 따른 포맷은 VisibleString 이다. 상기 'List of PLMNIDs' TLV 에 포함되는 PLMN ID는 SM-DP+에 의해 프로비져닝되도록 허락된 프로파일의 PLMN ID를 나타내고, 상기 SM-DP+는 상기 데이터 오브젝트 Discretionary data 내의 'D1' 태그에 의해 식별될 수 있다.
상기 인증서의 포맷에 포함될 수 있는 데이터 오브젝트인 Public Key (: 공개 키)는 다음 표 92과 같은 포맷을 가질 수 있다
Figure 112017112361107-pct00108
본 개시에서 사용되는 키 승인(key aggrement)용 인증서 CERT_ECKA는 다음 표 93과 같은 포맷을 가질 수 있다.
Figure 112017112361107-pct00109
상기 인증서 CERT_ECKA 에서 서명 '5F37'의 계산에 이용되는 개인 키(private key)는 다음과 같다.
- CERT_DP_ECKA 에 사용되는 SK.CI.ECDSA
- CERT_EUICC_ECKA 에 사용되는 SK.EUM.ECDSA
서명될 데이터는 태그 '93', '42', '5F20', '95', '5F25', '5F24', '73', 및 '7F49' 이다.
본 개시에서 TLS 연결의 상호 인증(mutual authentication)을 위해 사용되는 인증서 CERT_TLS는 RFC 5280에 개시된 바를 따를 수 있다. 이때, 상기 TLS 인증서가 SM-DP+를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 DPID이다. 상기 TLS 인증서가 SM-SR+를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 SRID이다. 상기 TLS 인증서가 SM-DS를 위해 발행되었다면 상기 TLS 인증서의 Common Name(CN)은 DSID이다.
이하에서는 본 개시에서 사용되는 TLV 구조가 ASN.1 표기법(notation)에 따라 정의된다.
TLV 구조(structure)는 DER(Distinguished Encoding Rule) 인코딩을 이용하여 인코딩될 수 있다.
ES10 인터페이스(: eUICC 와 LPA 간 인터페이스)의 TLV는 다음 표 94과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00110
Figure 112017112361107-pct00111
ES11c 인터페이스(: 푸시 클라이언트와 RMF 간 인터페이스)의 TLV는 다음 표 95과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00112
프로파일, 프로파일 정책(Profile Policy) 및 프로파일 관리(Profile Managements)의 TLV는 다음 표 96과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00113
Figure 112017112361107-pct00114
eUICC 정책 및 관리(eUICC Policy and Managements)의 TLV는 다음 표 97과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00115
Figure 112017112361107-pct00116
엔티티와 ID에 관한 TLV는 다음 표 98과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00117
Figure 112017112361107-pct00118
이벤트에 관한 TLV는 다음 표 99과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00119
Figure 112017112361107-pct00120
토큰에 관한 TLV는 다음 표 100과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00121
Figure 112017112361107-pct00122
로컬 관리(Local managements)에 관한 TLV는 다음 표 101과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00123
보안(security)에 관한 TLV는 다음 표 102과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00124
기타 TLV는 다음 표 103과 같은 자료 구조를 가질 수 있다.
Figure 112017112361107-pct00125
도 8은 본 개시의 단말 장치의 구성을 예시하는 도면이다.
본 개시에 따른 단말(800)은, 프로파일정보 전달서버로부터 프로파일정보를 수신하고, 상기 프로파일정보를 이용하여 프로파일 제공서버로부터 프로파일을 수신하는 송수신부(또는 통신부)(810)와 상기 프로파일을 수신하여 통신 서비스에 연결하는 제어부(820)를 포함할 수 있다. 상기 단말(800)은 탈착형 또는 고정형의 eUICC를 더 포함할 수 있다. 예를 들어, 도 4의 AP(412, 442, 472)는 상기 제어부(820)에 의해 구현될 수 있고, CP(414, 444, 474)는 상기 송수신부(810)에 의해 구현될 수 있다. 설명의 편의상 상기 송수신부(810)와 제어부(820)는 별개의 구성인 것처럼 도시되었으나, 하나의 구성요소로 구현될 수 있음은 물론이다. 상기 단말은 전자 장치로 호칭될 수도 있다.
도 9는 본 개시에 따른 서버 장치의 구성을 예시하는 도면이다.
본 개시에 따른 각종 서버 즉, SM-DP+, SM-DS, SM-SR+ 등은 도 9의 서버(900)처럼 구현될 수 있다.
상기 서버(900)가 SM-DP+인 경우, 상기 SM-DP+(900)는 프로파일을 생성하고 암호화하는 제어부(920)를 포함하고, SM-DS에 프로파일정보를 전달하고, 상기 암호화된 프로파일을 상기 eUICC를 사용하는 단말에게 전달하는 송수신부(910)를 포함할 수 있다. 상기 제어부(920)는 전자 장치로부터 프로파일 다운로드 요청을 수신하고, 상기 전자 장치로 상기 전자장치의 UICC(universal integrated circuit card)에 설치 가능한 프로파일을 전송하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치의 프로파일 다운로드 요청에 이용될 수 있다.
상기 서버(900)가 SM-DS인 경우, 상기 SM-DS(900)는, SM-DP_로부터 프로파일정보를 전달받고 단말에 프로파일정보를 전달하는 송수신부(910)를 포함하고, 상기 송수신부(910)을 제어하는 제어부(920)를 포함할 수 있다. 상기 SM-DS(900)는 프로파일정보를 저장할 수 있는 (프로파일 정보를 임시로 저장 가능한) 저장부를 더 포함할 수 있다. 상기 제어부(920)는 SM-DP+로부터 수신한 프로파일정보를 등록하며, 상기 프로파일정보에 대응하는 전자 장치로 상기 프로파일정보를 전달하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치가 상기 SM-DP+로부터 상기 전자 장치의 UICC에 설치 가능한 프로파일을 다운로드하는데 이용될 수 있다.
상기 서버(900)가 SM-SR+인 경우, 상기 SM-SR+(900)는 프로파일정보를 전달하고 상기 암호화된 프로파일을 상기 eUICC를 사용하는 단말에게 전달하는 송수신부(910)와 상기 송수신부(910)을 제어하는 제어부(920)을 포함할 수 있다. 상기 제어부(920)는 전자 장치로부터 프로파일 다운로드 요청을 수신하고, 상기 전자 장치로 상기 전자장치의 UICC(universal integrated circuit card)에 설치 가능한 프로파일을 전송하도록 제어할 수 있다. 상기 프로파일정보는 상기 전자 장치의 프로파일 다운로드 요청에 이용될 수 있다.
상기 도 1 내지 도 9가 예시하는 시스템의 구성도, 방법의 예시도, 장치 구성도는 본 개시의 권리범위를 한정하기 위한 의도가 없음을 유의하여야 한다. 즉, 상기 도 1 내지 도 9에 기재된 모든 구성부, 또는 동작의 단계가 본 개시의 실시를 위한 필수구성요소인 것으로 해석되어서는 안되며, 일부 구성요소 만을 포함하여도 본 개시의 본질을 해치지 않는 범위 내에서 구현될 수 있다.
앞서 설명한 동작들은 해당 프로그램 코드를 저장한 메모리 장치를 통신 시스템의 엔터티, 기능(Function), 기지국, 또는 단말 장치 내의 임의의 구성부에 구비함으로써 실현될 수 있다. 즉, 엔터티, 기능(Function), 기지국, 또는 단말 장치의 제어부는 메모리 장치 내에 저장된 프로그램 코드를 프로세서 혹은 CPU(Central Processing Unit)에 의해 읽어내어 실행함으로써 앞서 설명한 동작들을 실행할 수 있다.
본 개시에서 설명되는 엔터티, 기능(Function), 기지국, 또는 단말 장치의 다양한 구성부들과, 모듈(module)등은 하드웨어(hardware) 회로, 일 예로 상보성 금속 산화막 반도체(complementary metal oxide semiconductor) 기반 논리 회로와, 펌웨어(firmware)와, 소프트웨어(software) 및/혹은 하드웨어와 펌웨어 및/혹은 머신 판독 가능 매체에 삽입된 소프트웨어의 조합과 같은 하드웨어 회로를 사용하여 동작될 수도 있다. 일 예로, 다양한 전기 구조 및 방법들은 트랜지스터(transistor)들과, 논리 게이트(logic gate)들과, 주문형 반도체와 같은 전기 회로들을 사용하여 실시될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (21)

  1. 이동통신 시스템에서 LPA(local profile assistant) 및 eUICC(embedded universal integrated circuit card)를 구비하는 단말이 수행하는 방법에 있어서, 상기 방법은,
    상기 LPA가 서버에게 상기 eUICC의 제1 정보 및 eUICC challenge를 포함하는 제1 메세지를 전송하는 단계;
    상기 LPA가 상기 서버로부터 상기 서버의 적어도 하나의 인증서(certificate)를 포함하는 제1 응답 메시지를 수신하는 단계;
    상기 LPA가 상기 적어도 하나 이상의 인증서를 상기 eUICC에게 송신하는 단계;
    상기 LPA가 상기 eUICC의 서명 값을 포함하는 상기 eUICC의 제2 정보를 수신하는 단계;
    상기 LPA가 상기 서버로 상기 eUICC의 제2 정보를 포함하는 송신하는 단계;
    상기 LPA가, 상기 서버로부터 프로파일 패키지를 포함하는 제2 응답 메시지를 수신하는 단계; 및
    상기 LPA가 상기 eUICC에게 상기 프로파일 패키지를 설치하도록 송신하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 LPA가 상기 eUICC에게 상기 eUICC의 제1 정보의 요청을 송신하는 단계; 및
    상기 LPA가 상기 eUICC의 제1 정보의 요청에 대한 응답으로, 상기 eUICC로부터 상기 eUICC의 제1 정보를 수신하는 단계를 더 포함하는 방법.
  3. 제1항에 있어서,
    상기 LPA가 상기 eUICC에게 상기 eUICC challenge의 요청을 송신하는 단계; 및
    상기 LPA가 상기 eUICC challenge의 요청에 대한 응답으로, 상기 eUICC로부터 상기 eUICC challenge를 수신하는 단계를 더 포함하는 방법.
  4. 제1항에 있어서, 상기 방법은,
    상기 LPA는 상기 서버와 HTTPs(hyper text transfer protocol over secure socket layer) 연결을 수립하는 단계를 더 포함하는 방법.
  5. 제1항에 있어서,
    상기 제2 정보는 EUM(eUICC manufacturer) 인증서 및 eUICC 인증서를 더 포함하는 것인, 방법.
  6. 제1항에 있어서,
    상기 제1 응답 메시지는 프로파일 다운로드 세션을 식별하기 위한 트랜잭션 ID를 더 포함하는 것인, 방법.
  7. 제6항에 있어서,
    상기 트랜잭션 ID는 상기 서버의 상기 적어도 하나의 인증서와 함께 상기 eUICC로 전달되는 것인, 방법.
  8. 삭제
  9. 이동통신 시스템의 단말 에 있어서, 상기 단말은,
    eUICC(embedded universal integrated circuit card),
    송수신부; 및
    상기 단말의 LPA(local profile assistant)가 서버에게 상기 eUICC의 제1 정보 및 eUICC challenge를 포함하는 제1 메세지를 전송하고,
    상기 LPA가 상기 서버로부터 상기 서버의 적어도 하나의 인증서(certificate)를 포함하는 제1 응답 메시지를 수신하고,
    상기 LPA가 상기 적어도 하나 이상의 인증서를 상기 eUICC에게 송신하고,
    상기 LPA가 상기 eUICC의 서명 값을 포함하는 상기 eUICC의 제2 정보를 수신하고,
    상기 LPA가 상기 서버로 상기 eUICC의 제2 정보를 포함하는 송신하고,
    상기 LPA가, 상기 서버로부터 프로파일 패키지를 포함하는 제2 응답 메시지를 수신하고,
    상기 LPA가 상기 eUICC에게 상기 프로파일 패키지를 설치하도록 송신하도록 구성된 상기 송수신부와 결합된 적어도 하나의 프로세서를 포함하는 것인, 단말.
  10. 제9항에 있어서, 상기 적어도 하나의 프로세서는,
    상기 LPA가 상기 eUICC에게 상기 eUICC의 제1 정보의 요청을 송신하고,
    상기 LPA가 상기 eUICC의 제1 정보의 요청에 대한 응답으로, 상기 eUICC로부터 상기 eUICC의 제1 정보를 수신하도록 구성된 것인, 단말.
  11. 제9항에 있어서, 상기 적어도 하나의 프로세서는,
    상기 LPA가 상기 eUICC에게 상기 eUICC challenge의 요청을 송신하고,
    상기 LPA가 상기 eUICC challenge의 요청에 대한 응답으로, 상기 eUICC로부터 상기 eUICC challenge를 수신하도록 구성된 것인, 단말.
  12. 제9항에 있어서, 상기 적어도 하나의 프로세서는,
    상기 LPA는 상기 서버와 HTTPs(hyper text transfer protocol over secure socket layer) 연결을 수립하도록 구성된 것인, 단말.
  13. 제9항에 있어서,
    상기 제2 정보는 EUM(eUICC manufacturer) 인증서 및 eUICC 인증서를 더 포함하는 것인, 단말.
  14. 제9항에 있어서,
    상기 제1 응답 메시지는 프로파일 다운로드 세션을 식별하기 위한 트랜잭션 ID를 더 포함하는 것인, 단말.
  15. 제14항에 있어서,
    상기 트랜잭션 ID는 상기 서버의 상기 적어도 하나의 인증서와 함께 상기 eUICC로 전달되는 것인, 단말.
  16. 이동통신 시스템에서 서버가 수행하는 방법에 있어서, 상기 방법은,
    단말로부터, 단말에 포함된 eUICC(embedded universal integrated circuit card)의 eUICC challenge 및 상기 eUICC의 제1 정보를 포함하는 제1 메시지를 수신하는 단계;
    상기 서버의 적어도 하나의 인증서를 포함하는 제1 응답 메시지를 상기 단말에게 송신하는 단계;
    상기 eUICC의 서명값을 포함하는 상기 eUICC의 제2 정보를 제2 메시지를 상기 단말로부터 수신하는 단계;
    프로파일 패키지를 포함하는 제2 응답 메시지를 상기 단말로 전송하는 단계; 및
    상기 제2 메시지 내에 포함된 EUM(eUICC manafacturer) 인증서 및 eUICC 인증서가 유효한지 확인하는 단계를 포함하는 방법.
  17. 제16항에 있어서, 상기 방법은,
    상기 제1 메시지에 포함된 상기 서버의 주소가 유효한지 판단하는 단계; 및
    상기 제1 메시지에 포함된 암호화 키 정보가 상기 서버에서 지원 가능한지 여부를 판단하는 단계를 더 포함하는 방법.
  18. 제16항에 있어서,
    상기 eUICC 인증서는 상기 제2 정보 내에 포함된 상기 eUICC의 서명값을 인증하는데 사용되는 것인, 방법.
  19. 이동통신 시스템의 서버에 있어서, 상기 서버는,
    송수신부; 및
    단말로부터, 단말에 포함된 eUICC(embedded universal integrated circuit card)의 eUICC challenge 및 상기 eUICC의 제1 정보를 포함하는 제1 메시지를 수신하고,
    상기 서버의 적어도 하나의 인증서를 포함하는 제1 응답 메시지를 상기 단말에게 송신하고,
    상기 eUICC의 서명값을 포함하는 상기 eUICC의 제2 정보를 제2 메시지를 상기 단말로부터 수신하고,
    프로파일 패키지를 포함하는 제2 응답 메시지를 상기 단말로 전송하고, 상기 제2 메시지 내에 포함된 EUM(eUICC manafacturer) 인증서 및 eUICC 인증서가 유효한지 확인하도록 구성된 상기 송수신부와 결합된 적어도 하나의 프로세서를 포함하는 것인, 서버.
  20. 제19항에 있어서, 상기 적어도 하나의 프로세서는,
    상기 제1 메시지에 포함된 상기 서버의 주소가 유효한지 판단하고,
    상기 제1 메시지에 포함된 암호화 키 정보가 상기 서버에서 지원 가능한지 여부를 판단하는 것인, 서버
  21. 제19항에 있어서,
    상기 eUICC 인증서는 상기 제2 정보 내에 포함된 상기 eUICC의 서명값을 인증하는데 사용되는 것인, 서버.
KR1020177032815A 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법 KR102558361B1 (ko)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201562146622P 2015-04-13 2015-04-13
US62/146,622 2015-04-13
US201562149732P 2015-04-20 2015-04-20
US62/149,732 2015-04-20
US201562158067P 2015-05-07 2015-05-07
US62/158,067 2015-05-07
US201562212387P 2015-08-31 2015-08-31
US62/212,387 2015-08-31
PCT/KR2016/003858 WO2016167551A1 (ko) 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법

Publications (2)

Publication Number Publication Date
KR20170140809A KR20170140809A (ko) 2017-12-21
KR102558361B1 true KR102558361B1 (ko) 2023-07-21

Family

ID=57126301

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177032815A KR102558361B1 (ko) 2015-04-13 2016-04-12 통신 시스템에서 프로파일을 관리하는 기법

Country Status (6)

Country Link
US (2) US10439823B2 (ko)
EP (2) EP3297309B1 (ko)
KR (1) KR102558361B1 (ko)
CN (1) CN107873137B (ko)
AU (1) AU2016247689B2 (ko)
WO (1) WO2016167551A1 (ko)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2942045C (en) 2014-06-24 2019-04-16 Huawei Technologies Co., Ltd. Fault processing method, related apparatus, and computer
CA3018526C (en) * 2015-05-22 2023-06-20 John A. Nix Cryptographic unit for public key infrastructure (pki) operations
FR3039738B1 (fr) * 2015-07-28 2018-06-22 Idemia France Procede de gestion d'un profil enregistre dans un element securise, et element securise correspondant
ES2931954T3 (es) * 2016-02-25 2023-01-05 Huawei Tech Co Ltd Método y aparato de procesamiento de aplicaciones para tarjeta de circuito integrado universal integrada
CN107182048B (zh) * 2016-03-10 2021-06-25 中兴通讯股份有限公司 实现多个终端共享用户身份识别卡的方法和装置
US9900765B2 (en) * 2016-06-02 2018-02-20 Apple Inc. Method and apparatus for creating and using a roaming list based on a user roaming plan
FR3059194B1 (fr) * 2016-11-21 2019-06-28 Oberthur Technologies Installation d'un profil dans un module d'identite de souscripteur embarque
WO2018094581A1 (zh) * 2016-11-22 2018-05-31 华为技术有限公司 一种签约数据集的安装方法、终端及服务器
WO2018129724A1 (zh) 2017-01-13 2018-07-19 华为技术有限公司 一种签约数据集的下载方法、设备及服务器
WO2018129753A1 (zh) * 2017-01-16 2018-07-19 华为技术有限公司 一种签约信息集的下载方法、装置以及相关设备
CN108702617B (zh) * 2017-02-10 2021-01-12 华为技术有限公司 一种更新证书颁发者公钥的方法、相关设备及系统
KR102293683B1 (ko) * 2017-02-13 2021-08-26 삼성전자 주식회사 eSIM 접근 제어 방법 및 장치
CN106851621A (zh) * 2017-02-17 2017-06-13 惠州Tcl移动通信有限公司 一种基于rsp的lpa应用实现方法及实现系统
WO2018157484A1 (zh) * 2017-03-01 2018-09-07 华为技术有限公司 网络配置方法及终端
WO2018188739A1 (en) * 2017-04-12 2018-10-18 Telefonaktiebolaget Lm Ericsson (Publ) Methods for automatic bootstrapping of a device
US10122606B1 (en) * 2017-05-04 2018-11-06 Netscout Systems, Inc. System and method for estimating an amount of acknowledged application data transmitted by encrypted transport
CN106937274B (zh) * 2017-05-12 2020-06-09 东信和平科技股份有限公司 一种基于EUICC的Profile切换方法及装置
DE102017212994B3 (de) * 2017-05-31 2018-11-29 Apple Inc. INSTALLATION UND TESTEN EINES ELEKTRONISCHEN TEILNEHMERIDENTITÄTSMODULS (eSIM)
US10362475B2 (en) 2017-07-20 2019-07-23 T-Mobile Usa, Inc. Subscription management service data feeds
US10368230B2 (en) 2017-07-20 2019-07-30 T-Mobile Usa, Inc. Data enhancements for eSIM profile operation callbacks
US10356604B2 (en) 2017-07-20 2019-07-16 T-Mobile Usa, Inc. eSIM profile reuse for eUICCs
US10477383B2 (en) * 2017-07-20 2019-11-12 T-Mobile Usa, Inc. ESIM profile metadata provisioning
WO2019028698A1 (en) * 2017-08-09 2019-02-14 Apple Inc. PROTECTION OF THE CONFIDENTIALITY OF A SUBSCRIBER IDENTITY
EP4277321A3 (en) 2017-08-28 2023-12-27 Huawei Technologies Co., Ltd. Information verification method and related device
CN109802826B (zh) * 2017-11-17 2021-10-01 华为技术有限公司 一种事件的处理方法和终端
KR102424358B1 (ko) * 2017-11-30 2022-07-22 삼성전자주식회사 통신 서비스를 제공하는 방법 및 전자 장치
US11516672B2 (en) 2017-12-19 2022-11-29 Huawei Technologies Co., Ltd. Profile management method, embedded universal integrated circuit card, and terminal
US10966081B2 (en) 2017-12-22 2021-03-30 Giesecke+Devrient Mobile Security Gmbh MSISDN registration
EP3531667A1 (de) * 2018-02-26 2019-08-28 Deutsche Telekom AG Herstellung von kommunikationsfunktionen für teilnehmeridentitätsmodule
KR102462366B1 (ko) * 2018-04-06 2022-11-04 삼성전자주식회사 eUICC 버전을 협상하는 방법 및 장치
WO2019199836A1 (en) * 2018-04-09 2019-10-17 Averon Us, Inc. Secure communication using device-identity information linked to cloud-based certificates
CN110475200B (zh) * 2018-05-10 2021-07-09 华为技术有限公司 定位终端设备的方法和设备
CN110474945B (zh) * 2018-05-11 2021-08-03 华为技术有限公司 一种数据下载、管理的方法和终端
CN108966205B (zh) * 2018-07-04 2021-08-27 高新兴物联科技有限公司 一种兼容多种eSIM管理规范的方法、设备及计算机可读存储介质
KR102657876B1 (ko) * 2018-09-07 2024-04-17 삼성전자주식회사 Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
CN109245900B (zh) * 2018-09-14 2019-07-16 北京清大智信科技有限公司 一种毫米级超微型计算机安全交互方法及系统
CN110932858B (zh) * 2018-09-19 2023-05-02 阿里巴巴集团控股有限公司 认证方法和系统
US10798564B2 (en) * 2018-10-05 2020-10-06 T-Mobile USA, Inc Machine-readable code-based embedded subscriber identity module (ESIM) profile download
CN109495874B (zh) * 2018-12-28 2020-06-02 恒宝股份有限公司 Profile下载的方法和装置
KR102658615B1 (ko) * 2019-02-22 2024-04-18 삼성전자 주식회사 SSP 단말의 번들 다운로드 과정과 eSIM 프로파일 다운로드 과정 호환 연동 방법
EP3912369A4 (en) 2019-02-22 2022-03-30 Samsung Electronics Co., Ltd. METHOD FOR INTERWORKING BETWEEN A HARNESS DOWNLOAD PROCESS AND AN ESIM PROFILE DOWNLOAD PROCESS THROUGH AN SSP TERMINAL
US10687204B1 (en) * 2019-05-20 2020-06-16 T-Mobile Usa, Inc. Intelligent SIM profile procurement
CN112073176B (zh) * 2019-06-11 2022-03-11 大唐移动通信设备有限公司 密钥更新方法及装置
US20220377081A1 (en) * 2019-09-20 2022-11-24 Samsung Electronics Co., Ltd. Mutual device-to-device authentication method and device during device-to-device bundle or profile transfer
WO2021187874A1 (ko) * 2020-03-16 2021-09-23 삼성전자 주식회사 기기 간 번들 또는 프로파일 온라인 이동 방법 및 장치
US20230300596A1 (en) * 2020-06-26 2023-09-21 Telefonaktiebolaget Lm Ericsson (Publ) Remote subscription profile download
CN111522516B (zh) * 2020-07-06 2020-10-27 飞天诚信科技股份有限公司 一种云播报打印数据的处理方法及系统
US11310659B2 (en) 2020-07-10 2022-04-19 Cisco Technology, Inc. Techniques for provisioning an enterprise electronic subscriber identity module (ESIM) profile for an enterprise user
US11785456B2 (en) 2020-08-18 2023-10-10 Cisco Technology, Inc. Delivering standalone non-public network (SNPN) credentials from an enterprise authentication server to a user equipment over extensible authentication protocol (EAP)
CN112637848B (zh) * 2020-12-18 2023-03-14 中国联合网络通信集团有限公司 管理认证应用证书的方法、装置和系统
CN112543448A (zh) * 2020-12-21 2021-03-23 中国联合网络通信集团有限公司 电子卡安装方法、设备及系统
CN113190862B (zh) * 2021-05-10 2023-01-06 成都卫士通信息产业股份有限公司 基于sm2的无证书密钥生成方法、装置、电子设备及介质
US11564081B1 (en) 2021-07-06 2023-01-24 Cisco Technology, Inc. Auto-update and activation of locale-specific eSIM profile for a global enterprise user
US20230054892A1 (en) * 2021-08-20 2023-02-23 Samsung Electronics Co., Ltd. Method and device for providing event in wireless communication system
CN113873516B (zh) * 2021-08-25 2023-10-20 国网江苏省电力有限公司泰州供电分公司 一种高安全性的电网无线通信系统
CN114189334B (zh) * 2021-11-05 2023-09-26 卓望数码技术（深圳）有限公司 一种可管控的eSIM终端证书在线签发方法和系统
US11991520B2 (en) * 2022-04-29 2024-05-21 Microsoft Technology Licensing, Llc Encrypted flow of SIM data between regions and edge networks

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013036010A1 (ko) 2011-09-05 2013-03-14 주식회사 케이티 내장 uicc의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 mno 변경 방법, 그를 위한 내장 uicc, mno 시스템 및 기록매체
US20140228071A1 (en) 2011-05-27 2014-08-14 Telefonica, S.A. Method to switch subscriptions of a personal device supporting multiple subscriptions
US20140235210A1 (en) 2011-09-05 2014-08-21 Kt Corporation Method for managing embedded uicc and embedded uicc, mno system, provision method, and method for changing mno using same
WO2014193181A1 (ko) 2013-05-30 2014-12-04 삼성전자 주식회사 프로파일 설치를 위한 방법 및 장치

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1886747B (zh) * 2003-11-07 2010-06-02 诺基亚有限公司 使用运营商根证书控制应用的安装的方法和装置
WO2011070226A1 (en) * 2009-12-11 2011-06-16 Nokia Corporation Smart card security feature profile in home subscriber server
US8555067B2 (en) * 2010-10-28 2013-10-08 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
US9009475B2 (en) * 2011-04-05 2015-04-14 Apple Inc. Apparatus and methods for storing electronic access clients
KR101954450B1 (ko) * 2011-09-05 2019-05-31 주식회사 케이티 내장 ｕｉｃｃ의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 ｍｎｏ 변경 방법, 그를 위한 내장 ｕｉｃｃ, ｍｎｏ 시스템 및 기록매체
KR102001869B1 (ko) * 2011-09-05 2019-07-19 주식회사 케이티 ｅＵＩＣＣ의 프로파일 관리방법 및 그를 이용한 ｅＵＩＣＣ, ｅＵＩＣＣ 탑재 단말과, 프로비저닝 방법 및 ＭＮＯ 변경 방법
US8522035B2 (en) * 2011-09-20 2013-08-27 Blackberry Limited Assisted certificate enrollment
KR101986312B1 (ko) * 2011-11-04 2019-06-05 주식회사 케이티 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ
KR101618274B1 (ko) * 2012-02-14 2016-05-04 애플 인크. 복수의 액세스 제어 클라이언트를 지원하는 모바일 장치, 및 대응 방법들
US20140082358A1 (en) * 2012-09-17 2014-03-20 General Instrument Corporation Efficient key generator for distribution of sensitive material from mulitple application service providers to a secure element such as a universal integrated circuit card (uicc)
WO2014069871A1 (ko) 2012-10-29 2014-05-08 주식회사 케이티 가입자 인증 모듈을 관리하는 개체를 변경하는 방법 및 이를 이용하는 장치
ES2647088T3 (es) * 2012-12-21 2017-12-19 Giesecke+Devrient Mobile Security Gmbh Procedimientos y dispositivos para la gestión de suscripciones OTA
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
US9350550B2 (en) * 2013-09-10 2016-05-24 M2M And Iot Technologies, Llc Power management and security for wireless modules in “machine-to-machine” communications
US20160352698A1 (en) * 2013-12-05 2016-12-01 Huawei Device Co., Ltd. Security control method for euicc and euicc
US9730072B2 (en) * 2014-05-23 2017-08-08 Apple Inc. Electronic subscriber identity module provisioning
US10061942B2 (en) * 2014-05-30 2018-08-28 Apple Inc. Secure storage of an electronic subscriber identity module on a wireless communication device
EP3164960B1 (en) * 2014-07-03 2019-05-15 Apple Inc. Methods and apparatus for establishing a secure communication channel
US10623952B2 (en) * 2014-07-07 2020-04-14 Huawei Technologies Co., Ltd. Method and apparatus for authorizing management for embedded universal integrated circuit card
CN107211026B (zh) * 2015-03-22 2021-01-08 苹果公司 用于移动设备中的用户认证和人类意图验证的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140228071A1 (en) 2011-05-27 2014-08-14 Telefonica, S.A. Method to switch subscriptions of a personal device supporting multiple subscriptions
WO2013036010A1 (ko) 2011-09-05 2013-03-14 주식회사 케이티 내장 uicc의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 mno 변경 방법, 그를 위한 내장 uicc, mno 시스템 및 기록매체
US20140235210A1 (en) 2011-09-05 2014-08-21 Kt Corporation Method for managing embedded uicc and embedded uicc, mno system, provision method, and method for changing mno using same
WO2014193181A1 (ko) 2013-05-30 2014-12-04 삼성전자 주식회사 프로파일 설치를 위한 방법 및 장치

Also Published As

Publication number Publication date
EP3297309A4 (en) 2018-04-18
EP3562184A1 (en) 2019-10-30
US20180123803A1 (en) 2018-05-03
CN107873137A (zh) 2018-04-03
US20200052907A1 (en) 2020-02-13
EP3297309A1 (en) 2018-03-21
CN107873137B (zh) 2021-11-23
AU2016247689A2 (en) 2017-12-14
US10439823B2 (en) 2019-10-08
US10965470B2 (en) 2021-03-30
AU2016247689A1 (en) 2017-11-30
AU2016247689B2 (en) 2020-07-02
WO2016167551A1 (ko) 2016-10-20
EP3562184B1 (en) 2020-08-12
KR20170140809A (ko) 2017-12-21
EP3297309B1 (en) 2019-06-19

Similar Documents

Publication Publication Date Title
KR102558361B1 (ko) 통신 시스템에서 프로파일을 관리하는 기법
US11146568B2 (en) Method and apparatus for providing profile
KR102398276B1 (ko) 프로파일 다운로드 및 설치 장치
US11039311B2 (en) Profile download method and apparatus for use in wireless communication system
KR102382851B1 (ko) eSIM 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
CN110024426B (zh) 通过eSIM进行访问控制的装置及方法
KR102657876B1 (ko) Ssp 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
KR102237840B1 (ko) eSIM 프로파일을 설치, 관리하는 방법 및 장치

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant