KR102623524B1 - 통신 시스템에서 프로파일 다운로드 방법 및 장치 - Google Patents
통신 시스템에서 프로파일 다운로드 방법 및 장치 Download PDFInfo
- Publication number
- KR102623524B1 KR102623524B1 KR1020187005847A KR20187005847A KR102623524B1 KR 102623524 B1 KR102623524 B1 KR 102623524B1 KR 1020187005847 A KR1020187005847 A KR 1020187005847A KR 20187005847 A KR20187005847 A KR 20187005847A KR 102623524 B1 KR102623524 B1 KR 102623524B1
- Authority
- KR
- South Korea
- Prior art keywords
- profile
- terminal
- message
- euicc
- data
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 143
- 238000004891 communication Methods 0.000 title abstract description 51
- 238000012790 confirmation Methods 0.000 claims description 123
- 238000012795 verification Methods 0.000 claims description 72
- 230000004044 response Effects 0.000 claims description 36
- 238000013507 mapping Methods 0.000 claims description 25
- 230000008569 process Effects 0.000 description 61
- 238000010586 diagram Methods 0.000 description 35
- 238000010295 mobile communication Methods 0.000 description 29
- 238000007726 management method Methods 0.000 description 28
- 230000006870 function Effects 0.000 description 27
- 238000004422 calculation algorithm Methods 0.000 description 23
- 238000005516 engineering process Methods 0.000 description 22
- 238000012545 processing Methods 0.000 description 21
- 238000004364 calculation method Methods 0.000 description 14
- 238000003860 storage Methods 0.000 description 9
- 238000009434 installation Methods 0.000 description 6
- 238000004590 computer program Methods 0.000 description 4
- BCGWQEUPMDMJNV-UHFFFAOYSA-N imipramine Chemical compound C1CC2=CC=CC=C2N(CCCN(C)C)C2=CC=CC=C21 BCGWQEUPMDMJNV-UHFFFAOYSA-N 0.000 description 4
- 230000004913 activation Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000004806 packaging method and process Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 102100033189 Diablo IAP-binding mitochondrial protein Human genes 0.000 description 1
- 101710101225 Diablo IAP-binding mitochondrial protein Proteins 0.000 description 1
- 101150034459 Parpbp gene Proteins 0.000 description 1
- 206010042135 Stomatitis necrotising Diseases 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 201000008585 noma Diseases 0.000 description 1
- 230000001151 other effect Effects 0.000 description 1
- 229920000379 polypropylene carbonate Polymers 0.000 description 1
- 238000002300 pressure perturbation calorimetry Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
-
- 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/3236—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 cryptographic hash functions
-
- 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/3236—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 cryptographic hash functions
- H04L9/3239—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 cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- 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
- H04L9/3273—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 for mutual authentication
-
- 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
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/50—Service provisioning or reconfiguring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
-
- 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
Abstract
본 발명은 통신 시스템에서 단말에 통신 서비스를 다운로드 및 설치하여 통신 연결을 하기 위한 방법 및 장치에 관한 것으로, 본 발명의 일 실시 예에 따른 단말의 통신 방법은, 프로파일 제공 서버에게 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 전송하는 단계; 상기 프로파일 제공 서버로부터 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 제1 수정된 암호 코드가 포함된 제2 메시지를 수신하는 단계; 상기 제1 수정된 암호 코드의 인증이 성공한 경우, 제2 수정된 암호 코드를 생성하는 단계; 상기 프로파일 제공 서버에게 상기 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 전송하는 단계; 및 상기 프로파일 제공 서버로부터 상기 프로파일에 대한 정보가 포함된 제4 메시지를수신하는 단계;를 포함할 수 있다.
Description
본 발명은 통신 시스템에서 단말에 통신 서비스를 다운로드 및 설치하여 통신 연결을 하기 위한 방법 및 장치에 관한 것이으로, 보다 구체적으로 통신 시스템에서 실시간으로 프로파일을 다운로드하고 설치하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후(beyond 4G network) 통신 시스템 또는 LTE 시스템 이후(post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역(예를 들어, 60기가 (60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로 손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO(multiple input multiple output)), 전차원 다중입출력(FD-MIMO: full dimensional MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나(large scale antenna) 기술 등이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀(advanced small cell), 클라우드 무선 액세스 네트워크(cloud RAN: cloud radio access network), 초고밀도 네트워크(ultra-dense network), 기기 간 통신(D2D: device to device communication), 무선 백홀(wireless backhaul), 이동 네트워크(moving network), 협력 통신(cooperative communication), CoMP(coordinated multi-points), 및 수신 간섭제거(interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(ACM: advanced coding modulation) 방식인 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), 사물 통신(M2M: machine to machine), MTC(machine type communication) 등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(internet technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology) 기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(M2M), MTC 등의 기술이 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다. 앞서 설명한 빅데이터 처리 기술로써 클라우드 무선 액세스 네트워크(cloud RAN)가 적용되는 것도 5G 기술과 IoT 기술 융합의 일 예라고 할 수 있을 것이다.
한편, 범용 IC 카드(UICC: universal integrated circuit card)는 이동 통신 단말기 등에 삽입하여 사용하는 스마트카드(smart card)이고, UICC 카드라고도 부른다. 상기 UICC에는 이동 통신 사업자의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예로는 범용 가입자 인증 모듈(USIM: universal subscriber identity module), 가입자 인증 모듈(SIM: subscriber identity module), IP 멀티미디어 서비스 인증 모듈(ISIM: IP multimedia service identity module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM 카드라고 부르기도 한다. 본 발명의 이후 설명에서 SIM 카드라 함은 UICC 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 통상의 의미로 사용하도록 하겠다. 즉, SIM 카드라 하여도 그 기술적 적용이 USIM 카드 또는 ISIM 카드 또는 일반적인 UICC 카드에도 동일하게 적용될 수 있다.
상기 SIM 카드는 이동 통신 가입자의 개인 정보를 저장하고, 이동 통신 네트워크에 접속 시 가입자 인증 및 트래픽(traffic) 보안 키(key) 생성을 수행하여 안전한 이동 통신 이용을 가능하게 한다.
상기 SIM 카드는 일반적으로 카드 제조 시 특정 이동 통신 사업자의 요청에 의해 해당 사업자를 위한 전용 카드로 제조될 수 있다. 그리고, 해당 사업자의 네트워크 접속을 위한 인증 정보, 예를 들어, USIM(universal subscriber identity module) 어플리케이션, IMSI(international mobile subscriber identity), K 값, OPc 값 등 중 적어도 하나가 사전에 상기 SIM 카드에 탑재되어 출고된다. 따라서 제조된 상기 SIM 카드는 해당 이동 통신 사업자가 납품 받아 가입자에게 제공할 수 있다. 그리고, 이후 필요 시에는 이동 통신 사업자가 OTA(over the air) 등의 기술을 활용하여 상기 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다. 가입자는 소유한 이동 통신 단말기에 상기 UICC 카드를 삽입하여 해당 이동 통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 상기 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증 정보, 이동 통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용이 가능하다.
그러나 상기 SIM 카드는 이동 통신 단말기 사용자가 다른 이동 통신사의 서비스를 제공받는데 있어서 불편한 점이 있다. 즉, 이동 통신 단말기 사용자는 이동 통신 사업자로부터 서비스를 받기 위해 SIM 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 다른 나라로 여행을 했을 때 사용자가 현지 이동 통신 서비스를 받기 위해서는 현지 SIM 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 상기 불편함을 어느 정도 해결해 주지만, 비싼 요금 및 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.
한편, UICC 카드에 상기 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당부분 해결할 수 있다. 즉, 사용자가 원하는 시점에 사용하고자 하는 이동 통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 한 개의 SIM 모듈만을 선택하여 사용할 수 있다. 이러한 UICC 카드는 단말에 고정하거나 고정하지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 내장형 UICC(eUICC: embedded UICC)라고 하는데, eUICC는 단말에 고정하여 사용하고, 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미할 수 있다. 본 발명에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭하도록 한다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용하도록 하겠다. 또한 다운로드 받는 SIM 모듈 정보를 통칭하여 eUICC 프로파일(profile) 또는 프로파일이라는 용어로 사용하겠다.
본 발명이 이루고자 하는 기술적 과제는 통신 시스템에서 단말이 통신 서비스를 선택하여 통신 연결을 하기 위한 방법 및 장치를 제공하는 것이다. 또한, 본 발명이 이루고자 하는 기술적 과제는 통신 시스템에서 단말이 통신 연결을 하기 위한 프로파일을 실시간으로 다운로드 하는 방법 및 장치를 제공하는 것이다. 또한, 본 발명이 이루고자 하는 기술적 과제는 통신 시스템에서 단말에 프로파일을 제공하는 장치 및 방법을 제공하는 것이다.
또한, 본 발명은 단말의 프로파일 다운로드 과정에서, 악의적 사업자(rogue MNO(mobile network operator))에 의한 프로파일 다운로드를 효과적으로 차단하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 프로파일 다운로드를 위해 단말에서 서버를 인증할 때 사용때는 루트 인증서 정보를 업데이트 하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 단말에서 프로파일 정보 전달 서버에 정보 질의시 프로파일 서버가 단말을 인증하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 단말에서 프로파일 정보 전달 서버에 정보 질의시 프로파일 정보 전달 서버가 단말 정보를 몰라도 질의를 처리하여 단말 개인 정보 보호를 강화하는 방법을 제공하는 것을 목적으로 한다.
또한, 본 발명은 단말과 프로파일 제공 서버나 프로파일 관리 서버와 프로파일 다운로드를 위한 인증 및 암호화 시 암호화 파라미터를 정하는 절차를 제공하는 것을 목적으로 한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기 목적을 달성하기 위해 본 발명의 일 실시 예에 따른 단말의 통신 방법은, 프로파일 제공 서버에게 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 전송하는 단계; 상기 프로파일 제공 서버로부터 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 제1 수정된 암호 코드가 포함된 제2 메시지를 수신하는 단계; 상기 제1 수정된 암호 코드의 인증이 성공한 경우, 제2 수정된 암호 코드를 생성하는 단계; 상기 프로파일 제공 서버에게 상기 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 전송하는 단계; 및 상기 프로파일 제공 서버로부터 상기 프로파일에 대한 정보가 포함된 제4 메시지를수신하는 단계;를 포함할 수 있다.
또한, 상기 제2 수정된 암호 코드를 생성하는 단계는, 상기 사용자의 암호 코드를 수신하는 단계; 및 상기 암호 코드를 미리 설정된 난수 값으로 해쉬(hash) 연산을 하여 상기 제2 수정된 암호 코드를 생성하는 단계;를 포함할 수 있다.
또한, 상기 제2 수정된 암호 코드를 생성하는 단계는, 상기 사용자의 암호 코드를 수신하는 단계; 상기 암호 코드를 미리 설정된 난수 값으로 해쉬(hash) 연산을 하여 제3 수정된 암호 코드를 생성하는 단계; 및 상기 제1 수정된 암호 코드와 상기 제3 수정된 암호 코드를 비교하여 상기 제1 수정된 암호 코드를 인증하는 단계;를 포함할 수 있다.
또한, 상기 제2 메시지는, 암호화되지 않은 프로파일 정보를 포함하고, 상기 제4 메시지는 암호화된 프로파일 정보를 포함할 수 있다.
또한, 상기 목적을 달성하기 위해 본 발명의 일 실시 예에 따른 프로파일 제공 서버의 통신 방법은, 단말로부터 상기 단말이 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 수신하는 단계; 상기 단말이 상기 프로파일 제공 서버를 인증하도록 하기 위한 제1 수정된 암호 코드를 생성하는 단계; 상기 단말에게 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 상기 제1 수정된 암호 코드가 포함된 제2 메시지를 전송하는 단계; 상기 단말로부터 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 수신하는 단계; 및 상기 제2 수정된 암호 코드의 인증이 성공한 경우, 상기 단말에게 상기 프로파일에 대한 정보가 포함된 제4 메시지를 전송하는 단계;를 포함할 수 있다.
또한, 상기 제1 수정된 암호 코드를 생성하는 단계는, 사업자로부터 암호 코드를 수신하는 단계; 및 상기 암호 코드를 미리 설정된 난수 값으로 해쉬(hash) 연산을 하여 상기 제1 수정된 암호 코드를 생성하는 단계;를 포함할 수 있다.
또한, 상기 제4 메시지를 전송하는 단계는, 사업자로부터 암호 코드를 수신하는 단계; 상기 암호 코드를 미리 설정된 난수 값으로 해쉬(hash) 연산을 하여 제3 수정된 암호 코드를 생성하는 단계; 및 상기 제2 수정된 암호 코드와 상기 제3 수정된 암호 코드를 비교하여 상기 제2 수정된 암호 코드를 인증하는 단계;를 포함할 수 있다.
또한, 상기 목적을 달성하기 위해 본 발명의 일 실시 예에 따른 단말은, 다른 네크워크 엔티티와 신호를 송수신하는 송수신부; 및 프로파일 제공 서버에게 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 전송하고, 상기 프로파일 제공 서버로부터 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 제1 수정된 암호 코드가 포함된 제2 메시지를 수신하고, 상기 제1 수정된 암호 코드의 인증이 성공한 경우, 제2 수정된 암호 코드를 생성하고, 상기 프로파일 제공 서버에게 상기 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 전송하고, 상기 프로파일 제공 서버로부터 상기 프로파일에 대한 정보가 포함된 제4 메시지를 수신하도록 제어하는 제어부;를 포함할 수 있다.
또한, 상기 목적을 달성하기 위해 본 발명의 일 실시 예에 따른 프로파일 제공 서버는, 다른 네크워크 엔티티와 신호를 송수신하는 송수신부; 및 단말로부터 상기 단말이 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 수신하고, 상기 단말이 상기 프로파일 제공 서버를 인증하도록 하기 위한 제1 수정된 암호 코드를 생성하고, 상기 단말에게 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 상기 제1 수정된 암호 코드가 포함된 제2 메시지를 전송하고, 상기 단말로부터 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 수신하고, 상기 제2 수정된 암호 코드의 인증이 성공한 경우, 상기 단말에게 상기 프로파일에 대한 정보가 포함된 제4 메시지를 전송하도록 제어하는 제어부;를 포함할 수 있다.
본 발명의 실시 예에 따르면, 통신 시스템에서 프로파일을 단말에 다운로드 및 설치하는 과정에서 암호화된 프로파일을 단말에 전달하기 전 암호화되지 않은 프로파일 정보를 단말에 전달하여 사용자가 프로파일 사용 여부를 선택하게 함으로써, 사용자가 원하지 않는 프로파일을 다운로드 되지 않게 할수 있으며, 사용되지 않을 암호화된 프로파일을 다운로드 하는 것도 방지하여 프로파일 또는 프로파일에 저장되는 IMSI 등 번호 자원이 낭비되는 것을 줄여줄 수 있다.
본 발명의 다른 실시 예에 따르면, 통신 시스템에서 프로파일을 단말에 다운로드 및 설치하는 과정에서 암호화된 프로파일을 단말에 전달하기 전 통신사가 사용자에게 별도의 방법으로 전달한 암호 코드(confirmation code)를 요청하고, 사용자가 입력한 암호 코드가 맞는 경우에만 암호화된 프로파일을 단말에 전달함으로써, 프로파일이 잘못 설치되는 것을 방지하는 효과를 주고, 사용자가 원하지 않는 프로파일을 다운로드 되지 않게 할수 있으며, 사용되지 않을 암호화된 프로파일을 다운로드 하는 것도 방지하여 프로파일 또는 프로파일에 저장되는 IMSI 등 번호 자원이 낭비되는 것을 줄여줄 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명의 일 실시 예에 따른 프로파일 설치 및 관리 구조의 일 예를 도시하는 도면이다.
도 2는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 일 예를 도시한 도면이다.
도 3은 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 다른 일 예를 도시한 도면이다.
도 4는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 또 다른 일 예를 도시한 도면이다.
도 5는 본 발명의 일 실시 예에 따른 단말의 서명 및 암호화 파라미터를 전달하여 서명 및 암호화가 정상적으로 동작하도록 협의 하여 프로파일을 다운로드 하는 방법의 일 예를 도시한 도면이다.
도 6a 내지 도 6c는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 구체적인 일 예를 도시한 도면이다.
도 7a 및 도 7b는 본 발명의 일 실시 예에 따른 eUICC에 프로파일을 다운로드 하는 과정의 다른 실시 예이다.
도 8a 및 도 8b는 본 발명의 일 실시 예에 따른 네트워크 초기화 절차의 일 예를 도시한 도면이다.
도 9는 본 발명의 일 실시 예에 따른 단말의 블록 구성도의 일 예를 도시한 도면이다.
도 10은 본 발명의 일 실시 예에 따른 SM-DP+의 블록 구성도의 일 예를 도시한 도면이다.
도 11은 본 발명의 일 실시 예에 따른 SM-SR+의 블록 구성도의 일 예를 도시한 도면이다.
도 12는 본 발명의 일 실시 예에 따른 SM-DS의 블록 구성도의 일 예를 도시한 도면이다.
도 2는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 일 예를 도시한 도면이다.
도 3은 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 다른 일 예를 도시한 도면이다.
도 4는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 또 다른 일 예를 도시한 도면이다.
도 5는 본 발명의 일 실시 예에 따른 단말의 서명 및 암호화 파라미터를 전달하여 서명 및 암호화가 정상적으로 동작하도록 협의 하여 프로파일을 다운로드 하는 방법의 일 예를 도시한 도면이다.
도 6a 내지 도 6c는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 구체적인 일 예를 도시한 도면이다.
도 7a 및 도 7b는 본 발명의 일 실시 예에 따른 eUICC에 프로파일을 다운로드 하는 과정의 다른 실시 예이다.
도 8a 및 도 8b는 본 발명의 일 실시 예에 따른 네트워크 초기화 절차의 일 예를 도시한 도면이다.
도 9는 본 발명의 일 실시 예에 따른 단말의 블록 구성도의 일 예를 도시한 도면이다.
도 10은 본 발명의 일 실시 예에 따른 SM-DP+의 블록 구성도의 일 예를 도시한 도면이다.
도 11은 본 발명의 일 실시 예에 따른 SM-SR+의 블록 구성도의 일 예를 도시한 도면이다.
도 12는 본 발명의 일 실시 예에 따른 SM-DS의 블록 구성도의 일 예를 도시한 도면이다.
이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
본 명세서에서 어떤 구성 요소가 다른 구성 요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성 요소에 직접적으로 연결되어 있거나 또는 접속되어 있는 것을 의미할 수도 있고, 중간에 다른 구성 요소가 존재하여 전기적으로 연결되어 있는 것을 의미할 수도 있다. 아울러, 본 명세서에서 특정 구성을 "포함" 한다고 기술하는 내용은 해당 구성 이외의 구성을 배제하는 것이 아니며, 추가적인 구성이 본 발명의 실시 또는 본 발명의 기술적 사상의 범위에 포함될 수 있음을 의미한다.
그리고, 본 발명의 실시 예에 나타나는 구성부들은 서로 다른 특징적인 기능을 나타내기 위해 독립적으로 도시되는 것으로, 각 구성부들이 분리된 하드웨어나 하나의 소프트웨어 구성 단위로 이루어짐을 의미하지 않는다. 즉, 각 구성부는 설명의 편의상 각각의 구성부로 나열하여 포함한 것으로 각 구성부 중 적어도 두 개의 구성부가 하나의 구성부를 이루거나, 하나의 구성부가 복수 개의 구성부로 나뉘어져 기능을 수행할 수 있다. 각 구성부의 통합된 실시 예 및 분리된 실시 예도 본 발명의 본질에서 벗어나지 않는 한 본 발명의 권리 범위에 포함된다.
또한, 일부의 구성 요소는 본 발명에서 본질적인 기능을 수행하는 필수적인 구성 요소는 아니고 단지 성능을 향상시키기 위한 선택적 구성 요소일 수 있다. 본 발명은 단지 성능 향상을 위해 사용되는 구성 요소를 제외한 본 발명의 본질을 구현하는데 필수적인 구성부만을 포함하여 구현될 수 있고, 단지 성능 향상을 위해 사용되는 선택적 구성 요소를 제외한 필수 구성 요소만을 포함한 구조도 본 발명의 권리범위에 포함된다.
하기에서 본 명세서의 실시 예를 설명함에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 명세서의 실시 예의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 이하 첨부된 도면을 참조하여 본 명세서의 실시 예의 실시 예를 설명하기로 한다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
먼저, 본 발명에서 사용되는 용어에 대해서 정의한다.
도 1은 본 발명의 일 실시 예에 따른 프로파일 설치 및 관리 구조의 일 예를 도시하는 도면이다.
본 발명에서 범용 IC 카드(UICC: universal integrated circuit card)(115)는 이동 통신 단말기(110)에 삽입하여 사용하는 스마트 카드로서 이동 통신 가입자의 네트워크 접속 인증 정보, 전화번호부, 단문 메시지 서비스(SMS: short message service)와 같은 개인 정보가 저장될 수 있는 칩을 의미한다. 그리고 UICC(115)는 GSM(global system for mobile communication), WCDMA(wideband code division multiple access), LTE(long term evolution) 등과 같은 이동 통신 네트워크에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여, 안전한 이동 통신 이용을 가능하게 할 수 있다. UICC(115)에는 가입자가 접속하는 이동 통신 네트워크의 종류에 따라 가입자 인증 모듈(SIM: subscriber identification module), 범용 가입자 인증 모듈(USIM: universal SIM), IP 멀티미디어 서비스 인증 모듈(ISIM: IP multimedia SIM)등의 통신 어플리케이션(application)이 탑재되며, 또한 전자 지갑, 티켓팅, 전자 여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.
내장형 UICC(eUICC: embedded UICC)(115)는 단말(110)에 삽입 및 탈거가 가능한 착탈식이 아닌, 단말(110)에 내장된 칩 형태의 보안 모듈이다. eUICC(115)는 OTA(over the aAir) 기술을 이용하여 프로파일(profile)을 다운받아 설치할 수 있다. 한편, 본 발명에서 eUICC(115)는 원격으로 프로파일 다운로드 및 설치가 가능한 UICC를 통칭하여 명명할 수 있다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC(115) 중 단말(110)에 고정하거나 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용하도록 하겠다. 또한 다운로드 받는 SIM 모듈 정보를 통칭하여 eUICC 프로파일 또는 프로파일이라는 용어로 사용하겠다.
한편, 본 발명에서 eUICC(115)에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 단말(110)에 삽입 및 탈거가 가능한 착탈식 UICC에도 적용될 수 있다. 즉, 본 발명의 실시 예에는 OTA 기술을 이용하여 프로파일을 다운 받아 설치 가능한 UICC(115)에 적용될 수 있다.
본 발명에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.
그리고, 본 발명에서 프로파일(profile)은 UICC 내에 저장되는 어플리케이션, 파일 시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 발명에서 USIM profile(SIM profile)은 프로파일과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 발명에서 프로파일 제공 서버(120)는 SM-DP(subscription manager data preparation), SM-DP+(subscription manager data preparation plus), off-card entity of Profile Domain, 프로파일 암호화 서버, 프로파일 생성 서버, 프로파일 제공자(PP: profile provisioner, PP), 프로파일 공급자(profile provider), PPC holder(profile provisioning credentials holder) 등으로 표현될 수 있다.
본 발명에서 프로파일 정보 전달 서버(140)는 DPF(discovery and push function), SM-DS(subscription manager discovery service) 등으로 표현될 수 있다.
본 발명에서 프로파일 관리 서버(130)는 SM-SR(subscription manager secure routing), SM-SR+(subscription manager secure routing plus), off-card entity of eUICC Profile Manager, PMC holder(profile management credentials holder), EM(eUICC manager) 등으로 표현될 수 있다.
본 명세서에서 상기 프로파일 제공 서버(120)를 지칭할 때 상기 프로파일 관리 서버(130)의 기능을 합친 것을 통칭하는 것일 수도 있다. 따라서 본 발명의 다양한 실시예에서 즉, 이후의 기술에서 프로파일 제공 서버(120)의 동작에 대하여 상기 동작은 프로파일 관리 서버(130)에서 이루어지는 것도 가능함은 물론이다. 마찬가지로 프로파일 관리 서버(130) 또는 SM-SR(130)에 대하여 기술하는 동작은 프로파일 제공 서버(120)에서 수행될 수도 있음은 물론이다.
한편, 본 발명에서 사용하는 용어 '단말'(110)은 단말기(terminal), 이동 통신 단말기, 이동국(MS), 사용자 장비(UE: user equipment), 사용자 터미널(UT: user terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(subscriber unit), 가입자 스테이션(SS: subscriber station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU: wireless transmit/receive unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말(110)의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(machine to machine) 단말, MTC(machine type communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자장치라 지칭할 수도 있다.
본 발명에서 전자 장치는 프로파일을 다운로드 하여 설치 가능한 UICC(115)가 내장될 수 있다. UICC(115)가 전자 장치에 내장되지 않은 경우, 물리적으로 전자 장치와 분리된 UICC(115)는 전자 장치에 삽입되어 전자 장치와 연결될 수 있다. 예를 들어, UICC(115)는 카드 형태로 전자 장치에 삽입될 수 있다. 상기 전자 장치는 상기 단말(110)을 포함할 수 있고, 이때, 단말(110)은 프로파일을 다운로드하여 설치 가능한 UICC(115)를 포함하는 단말(110)일 수 있다. 상기 단말(110)에 UICC(115)는 내장될 수 있을 뿐만 아니라, 단말(110)과 UICC(115)가 분리된 경우 UICC(115)는 단말(110)에 삽입될 수 있고, 단말(110)에 삽입되어 단말(110)과 연결될 수 있다. 프로파일을 다운로드하여 설치 가능한 UICC(115)는 예를 들어 eUICC(115)라 지칭할 수 있다.
본 발명에서 프로파일 구분자는 프로파일 식별자(profile ID), ICCID(integrated circuit card ID), ISD-P 또는 프로파일 도메인(PD: profile domain)와 매칭되는 인자로 지칭될 수 있다. profile ID는 각 프로파일의 고유 식별자를 나타낼 수 있다.
본 발명에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC(115)의 고유 식별자일 수 있고, EID로 지칭될 수 있다. 또한 eUICC(115)에 프로비저닝 프로파일(provisioning profile)이 미리 탑재되어 있는 경우, eUICC 식별자(eUICC ID)는 해당 프로비저닝 프로파일의 식별자(provisioning profile의 profile ID)일 수 있다. 또한 본 발명의 실시 예에서와 같이 단말(110)과 eUICC 칩(115)이 분리되지 않을 경우에, eUICC 식별자(eUICC ID)는 단말 ID일 수 있다. 또한, eUICC 식별자(eUICC ID)는 eUICC 칩(115)의 특정 보안 도메인(secure domain)을 지칭할 수도 있다.
본 발명에서 프로파일 컨테이너(profile container)는 프로파일 도메인(profile domain)으로 명명될 수 있다. 그리고, 프로파일 컨테이너(profile container)는 보안 도메인(security domain)일 수 있다.
본 발명에서 APDU(application protocol data unit)는 단말(110)이 eUICC(115)와 연동하기 위한 메시지일 수 있다. 또한 APDU는 PP(120) 또는 PM(130)이 eUICC(115)와 연동하기 위한 메시지일 수 있다.
본 발명에서 PPC(profile provisioning credentials)는 PP(120)와 eUICC(115) 간 상호 인증 및 프로파일 암호화, 서명을 하는데 이용되는 수단일 수 있다. PPC는 대칭키, RSA(rivest shamir adleman) 인증서와 개인키, ECC(elliptic curved cryptography) 인증서와 개인키, 최상위 인증 기관(root certification authority(CA)) 및 인증서 체인(chain) 중 하나 이상을 포함할 수 있다. 또한 PP(120)가 복수개인 경우에는 복수개의 PP(120) 별로 다른 PPC를 eUICC(115)에 저장하거나 사용할 수 있다.
본 발명에서 PMC(profile management credentials)는 PM(130)과 eUICC(115) 간 상호 인증 및 전송 데이터 암호화, 서명을 하는데 이용되는 수단일 수 있다. PMC는 대칭키, RSA 인증서와 개인키, ECC 인증서와 개인키, Root CA 및 인증서 체인 중 하나 이상을 포함할 수 있다. 또한 PM(130)이 복수개인 경우에는 복수개의 PM(130) 별로 다른 PMC를 eUICC(115)에 저장하거나 사용할 수 있다.
본 발명에서 AID는 어플리케이션 식별자(application identifier)일 수 있다. 이 값은 eUICC(115) 내에서 서로 다른 어플리케이션(application)을 구분해주는 구분자일 수 있다.
본 발명에서 프로파일 패키지 TLV(profile package TLV)는 Profile TLV 로 명명될 수 있다. profile package TLV는 TLV(tag, length, value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트(set)일 수 있다.
본 발명에서 AKA는 인증 및 키 합의(authentication and key agreement)를 나타낼 수 있으며, 3GPP 및 3GPP2 망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다.
본 발명에서 K 는 AKA 인증 알고리즘에 사용되는 eUICC(115)에 저장되는 암호키 값이다.
본 발명에서 OPc는 AKA 인증 알고리즘에 사용되는 eUICC(115)에 저장될 수 있는 파라미터 값이다.
본 발명에서 NAA는 네트워크 접속 어플리케이션(network access application) 응용프로그램으로, UICC(115)에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망 접속 모듈일 수 있다.
한편, 단말(110)에 UICC(115)가 삽입될 수 있다. 이 때, 상기 UICC(115)는 착탈형 일 수도 있고 단말(110)에 미지 내장된 것 일 수도 있다. UICC(110)의 프로파일은 특정 통신사에 접속할 수 있는 '접속정보'가 포함할 수 있다. 상기 접속 정보는 이를 테면 가입자 구분자인 IMSI 및 가입자 구분자와 함께 망에 인증하는데 필요한 K 또는 Ki 값일 수 있다.
그러면 상기 단말(110)은 상기 UICC(115)를 이용하여 이동 통신사의 인증처리시스템(이를 테면 HLR(home location register) 이나 AuC)와 인증을 수행할 수 있다. 상기 인증과정은 AKA(authenticaiton and key agreement) 과정일 수 있다. 인증에 성공하면 이후 단말(110)은 상기 이동 통신시스템의 이동 통신 네트워크를 이용하여 전화나 모바일 데이터 이용 등의 이동 통신 서비스를 이용할 수 있게 된다.
그리고, 본 발명을 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.
한편, 상술한 것과 같이 eUICC(115)는 단말(110)에 내장되거나 착탈이 가능한 형태의 UICC 카드 또는 칩일 수 있다. 그리고 상기 eUICC(115)는 기존의 2FF, 3FF, 4FF 및 MFF 1, MFF2 등의 form factor 뿐 아니라 다양한 물리적인 크기를 갖는 UICC 일 수 있다. 또한 eUICC(115)는 단말(110)에 별도로 내장될 수도 있지만, 단말(110)의 통신 칩(예를 들면, baseband 모뎀)에 통합(integrate)되어 구현될 수도 있음은 물론이다.
그리고, 프로파일 제공 서버(120)는 프로파일을 생성하거나 생성된 것을 암호화 하는 기능을 포함하고, SM-DP+로 지칭될 수도 있다.
프로파일 관리 서버(130)는 EM(eUICC manager), SM-SR+ 등으로 지칭될 수 있으며, SM-DP+(120)로부터 전달받은 프로파일을 단말(110)의 LPA(local profile assistant)에 전달하거나 프로파일 관리를 수행할 수 있다. 이때 SM-SR+(130)은 SM-DP+(120)와 단말(110)의 LPA 사이에서 프로파일 다운로드 또는 프로파일 관리 동작을 제어할 수 있다.
프로파일 정보 전달 서버(140)는 SM-DS, DPF 등으로 지칭될 수 있으며, SM-SR+(130) 로부터 SM-SR+ 서버 주소 및 event 구분자를 전달받아 단말(110)의 LPA에게 전달할 수 있다.
그리고, 실시 예에 따라서, SM-DP+(120) 및 SM-SR+(130)는 하나의 서버에 구현되어, SM-DP+ 또는 SM+(subscription manager plus) 로 지칭할 수도 있다.
eUICC manufacturer(EUM)(160)는 eUICC(115)를 제조하고, 이를 이동 통신 사업자 또는 단말기 제조사에게 제작된 eUICC(115)를 제공할 수 있다. 그리고, mobile network operator(MNO)(150)는 이동 통신망 사업자로, 단말에게 이동 통신 서비스를 제공하는 사업자일 수 있다. certificate issuer(CI)(170)는 프로파일 제공 서버(120), 프로파일 관리 서버(130), 프로파일 정보 전달 서버(140), EUM(160) 등을 인증할 수 있다. 한편, 본 발명의 일 실시 예에 따른 무선 통신 시스템에서 단말(110)은, SM-DP+(120) 또는 SM-SR+(130)로부터 암호화된 프로파일과, 암호화 되지 않은 프로파일 정보를 수신할 수 있는 송수신부를 포함하고, 암호화 되지 않은 프로파일 정보에 따른 프로파일 정보를 표시하는 표시부를 포함하면서, 프로파일 수신에 대한 사용자의 동의를 받는 UI부 및 상기 표시 및 동의 입력 과정은 프로파일 다운로드 과정 중 암호화된 프로파일의 수신 전에 일어나며, 입력받은 동의에 기반하여 프로파일 다운로드 과정을 진행할지 또는 멈출지를 결정하는 제어부를 포함할 수 있다.
그리고, 본 발명의 실시 예에 따른 무선 통신 시스템에서 SM-DP+(120)는 프로파일 다운로드 과정 중에 암호화되지 않은 프로파일 정보와 암호화된 프로파일을 생성하고, 암호화되지 않은 프로파일 정보가 단말(110)에게 전달된 이후, 단말(110)로부터 정상적인 프로파일 다운로드 요청 메시지가 전달된 경우에만 암호화된 프로파일을 생성하여 전달하는 제어부 및 송수신부를 포함할 수 있다.
또한, 본 발명의 또 다른 실시 예에 따른 무선 통신 시스템에서 단말(110)은, SM-DP+(120) 또는 SM-SR+(130)로부터 암호화된 프로파일과, 암호화 되지 않은 프로파일 정보를 수신할 수 있는 송수신부를 포함하고, 암호화 되지 않은 프로파일 정보에 따른 프로파일 정보를 표시하는 표시부, SM-DP+(120)로부터 프로파일 다운로 과정 중에 수신한 정보 중에서 사용자의 confirmation code가 필요한지 필요없는지를 의미하는 구분자가 기반하여 사용자에게 confirmation code 입력이 필요함을 의미하는 표시를 표시하도록 제어하는 제어부, 상기 표시와 동시에 또는 별도로 사용자가 confirmation code를 입력할 수 있는 UI부를 포함하고, 상기 제어부는 입력받은 confirmation code 및 프로파일 수신 과정 중에 SM-DP+(120) 또는 SM-SR+(130)로부터 전달받은 난수 값을 함께 hash 연산을 하고, 상기 연산 값을 프로파일 수신 과정 중에 SM-DP+(120) 또는 SM-SR+(130)로 전달하도록 제어할 수 있다.
또한, 본 발명의 또 다른 실시 예에 따른 무선 통신 시스템에서 SM-DP+(120)는 특정 프로파일의 다운로드시 confirmation code가 필요한지에 대한 정보 및 confirmation code 정보를 저장할 수 있는 저장 장치, 상기 confirmation code가 필요한지에 대한 정보를 읽어 해당 정보를 상기 프로파일을 다운로드하려고 하는 단말(110)에 전달하고, confirmation code가 필요한 경우, 단말(110)에서 전달받은 상기 hash 연산 값을 SM-DP+(120)에 저장되어 있는 상기 confirmation code와 단말(110)에 전달했던 난수 값을 이용하여 SM-DP+(120)에서 계산한 hash 연산 값을 비교하여 그 값이 동일하지 않은 경우 암호화된 프로파일을 단말(110)에게 전달하지 않는 제어부 및 송수신부를 포함할수 있다.
이하, 본 발명의 구체적인 실시 예들에 대해서 살펴보도록 한다.
도 2는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 일 예를 도시한 도면이다.
도 2를 참고하면, 210 단계에서 단말(110)은 서버를 검증하기 위한 서버 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, challenge 값일 수 있다. 이때, 상기 challenge 값은 단말(110) 내부의 제어부 또는 단말(110)에 연결된 eUICC(115)에서 생성한 값일 수 있고, 이는 eUICC challenge 값으로 지칭될 수 있다. 그리고, 단말(110)은 상기 서버를 검증하기 위한 정보를 포함하는 메시지를 프로파일 제공 서버(120)에게 전송할 수 있다. 이때, 상기 메시지는 초기 인증 요청 메시지(예를 들면, InitAuthRequest 메시지)일 수 있다. 그리고, 상기 프로파일 제공 서버(120)는 SM-DP+일 수 있다. 한편, 상기 단말(110)은 eUICC(115)를 포함하는 것으로 상기 단말(110)의 동작 중 일부는 eUICC(115)에서 동작할 수도 있다.
그리고, 215 단계에서 SM-DP+(120)는 단말(110)을 검증하기 위한 단말 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, SM-DP+ challenge 값일 수 있고, SM-DP+(120)의 제어부에서 생성될 수 있다. 그리고, SM-DP+(120)는 210 단계에서 수신한 상기 eUICC challenge 값 및 SM-DP+(120)에서 생성한 SM-DP+ challenge값을 포함하는 데이터에 대하여 SM-DP+ 서명 값(signature)을 계산할 수 있다. 이때, 상기 계산된 SM-DP+ 서명 값은 SM-DP+ signature1일 수 있다. 그리고, 상기 SM-DP+ signature1은 SM-DP+ 비밀키를 이용하여 계산한 값이다. SM-DP+(120)는 상기 SM-DP+ signature1 및 SM-DP+ challenge 값을 포함하는 응답 메시지를 단말(110)에 전송할 수 있다.
이후, 220 단계에서 단말(110)은 상기 SM-DP+ signature1을 검증하여 SM-DP+(120)의 인증에 성공한 경우 이후의 과정을 실행하고, 인증에 실패한 경우 더 이상 이후의 과정을 실행하지 않을 수 있다.
상기 220 단계에서 단말(110)이 SM-DP+(120)의 인증에 성공하면, 단말(110)은 225 단계에서 상기 SM-DP+ challenge를 포함하는 데이터에 대하여 eUICC 서명 값(signature)을 생성할 수 있다. 이때, 상기 계산된 eUICC 서명 값은 eUICC signature1일 수 있다. 그리고, 상기 eUICC signature1은 eUICC(115)의 개인키를 이용한 서명일 수 있다. 그리고, 단말(110)은 SM-DP+(120)에게 eUICC signature1 및 프로파일에 대한 정보를 포함하는 메시지를 전송할 수 있다. 이때, 상기 메시지는 인증 요청 메시지(예를 들면, AuthClientRequest)일 수 있다. 그리고, 상기 프로파일에 대한 정보는 프로파일매핑 정보를 포함할 수 있으며, 상기 프로파일 매핑 정보는 SM-DP+(120)에서 프로파일 또는 특정 프로파일 종류를 구분하는데 쓰일 수 있는 정보를 통칭하는 것일 수 있다. 이때, 상기 프로파일에 대한 정보는 다음과 같은 프로파일 매핑 정보를 포함할 수 있다.
- eUICC Identifier or EID
- eUICC 인증서
- EventID
- MatchingID
- ActivationToken
- NotificationID
230 단계에서 SM-DP+(120)는 상기 프로파일 매핑 정보로부터 특정 프로파일이나 프로파일 종류에 대응되는 프로파일 정보를 조회할 수 있다.
235 단계에서 SM-DP+(120)는 상기 230 단계에서 조회된 프로파일 정보를 포함하는 데이터에 대한 서명 값(SM-DP+ signature2)을 계산할 수 있다. 그리고, SM-DP+(120)는 상기 서명 값(SM-DP+ signature2) 및 상기 프로파일 정보를 단말에 전송할 수 있다. 이때, 상기 프로파일 정보는 암호화되지 않은 프로파일 정보일 수 있다.
이에 따라, 단말(110)은 상기 235 단계에서 전달받은 프로파일 정보의 일부 또는 전부를 표시부(display)에 표시하거나, 프로파일 정보의 일부 또는 전부에 대하여 매핑되는 정보를 표시부에 표시할 수 있다. 이때, 상기 매핑되는 정보는 단말(110)에 기저장되어 있거나 외부 서버와 연동하여 획득한 값일 수 있다. 상기 매핑 과정에 이용되는 상기 프로파일 정보의 일부 또는 전부는 다음과 같을 수 있다.
- IMSI
- MCC 또는 MNC 를 포함하는 정보
- MCC 및 MNC를 포함하는 정보
- 사업자 이름
- ICCID 정보의 일부를 구성하는 정보
- 사업자 코드
그리고 245 단계에서 단말(110)은 사용자의 프로파일 다운로드 동의를 입력받을 수 있다. 즉, 단말(110)은 사용자로부터 프로파일을 다운로드하는 것을 동의한다는 정보가 입력될 수 있다.
한편, 상기 동의 과정은 다음과 같을 수 있다.
- 단순하게 네 / 아니오 를 표시 하는 표시부에서 '네'에 해당하는 위치를 UI(user interface)부의 입력 장치(예를 들면, 터치 패드, 버튼 등)를 이용하여 입력
- 지문 인증, 홍체 인증 등의 생체 인증을 이용한 입력
250 단계에서 단말(110)은 상기 245 단계를 통해 사용자 동의 과정에서 사용자가 프로파일 다운로드를 동의 했는지 여부를 판단할 수 있다.
상기 250 단계에서 사용자가 동의한 것으로 판단된 경우, 260 단계에서 단말(110)은 SM-DP+(120)에게 프로파일 다운로드를 요청할 수 있다. 이때, 단말(110)은 상기 프로파일 다운로드를 요청하는 정보에 대한 eUICC 서명 값(eUICC signature2)을 생성할 수 있다. 그리고, 단말(110)은 상기 eUICC 서명 값(eUICC signature2) 및 상기 프로파일 다운로드 요청 정보가 포함된 요청 메시지(예를 들면, GetBoundProfilePackage)를 SM-DP+(120)에게 전송할 수 있다.
270 단계에서 SM-DP+(120)는 상기 260 단계에서 수신한 프로파일 다운로드 요청 정보에 따라서, 암호화된 프로파일을 단말(110)에게 전송할 수 있다.
그러면, 단말(110)은 280 단계에서 암호화된 프로파일을 복호화한 후 프로파일을 설치할 수 있다. 상기 프로파일 복호화는 단말(110) 내부의 eUICC(115)에서 수행될 수 있다.
한편, 만약 상기 250 단계에서 사용자가 동의하지 않은 것으로 판단한 경우, 단말(110)은 290 단계에서 프로파일 동의 안함 보고 및/또는 동의 결과를 SM-DP+(120)에 전달할 수 있다. 이후 단말(110)은 프로파일 다운로드 절차를 더 이상 수행하지 않고 종료할 수 있다.
그리고, 295 단계에서 SM-DP+(120)는 프로파일 동의 안함 보고를 수신한 경우 프로파일 다운로드 절차를 종료할 수 있다. 그리고 SM-DP+(120)는 단말(110)에게 상기 프로파일 동의 안함 보고에 대한 ACK 메시지를 전달할 수 있다.
이상의 프로파일 다운로드 과정에서 구체적인 프로파일 과정을 상기 과정과 상이할 경우에도 적용될 수 있음은 물론이다.
도 3은 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 다른 일 예를 도시한 도면이다.
도 3을 참고하면, 310 단계에서 단말(110)은 서버를 검증하기 위한 서버 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, challenge 값일 수 있다. 이때, 상기 challenge 값은 단말(110) 내부의 제어부 또는 단말(110)에 연결된 eUICC(115)에서 생성한 값일 수 있고, 이는 eUICC challenge 값으로 지칭될 수 있다. 그리고, 단말(110)은 상기 서버를 검증하기 위한 정보를 포함하는 메시지를 프로파일 제공 서버(120)에게 전송할 수 있다. 이때, 상기 메시지는 초기 인증 요청 메시지(예를 들면, InitAuthRequest 메시지)일 수 있다. 그리고, 상기 프로파일 제공 서버(120)는 SM-DP+일 수 있다. 한편, 상기 단말(110)은 eUICC(115)를 포함하는 것으로 상기 단말(110)의 동작 중 일부는 eUICC(115)에서 동작할 수도 있다.
그리고, 315 단계에서 SM-DP+(120)는 단말(110)을 검증하기 위한 단말 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, SM-DP+ challenge 값일 수 있고, SM-DP+(120)의 제어부에서 생성될 수 있다. 그리고, SM-DP+(120)는 310 단계에서 수신한 상기 eUICC challenge 값 및 SM-DP+(120)에서 생성한 SM-DP+ challenge값을 포함하는 데이터에 대하여 SM-DP+ 서명 값(signature)을 계산할 수 있다. 이때, 상기 계산된 SM-DP+ 서명 값은 SM-DP+ signature1일 수 있다. 그리고, 상기 SM-DP+ signature1은 SM-DP+ 비밀키를 이용하여 계산한 값이다. SM-DP+(120)는 상기 SM-DP+ signature1 및 SM-DP+ challenge 값을 포함하는 응답 메시지를 단말(110)에 전송할 수 있다.
이후, 320 단계에서 단말(110)은 상기 SM-DP+ signature1을 검증하여 SM-DP+(120)의 인증에 성공한 경우 이후의 과정을 실행하고, 인증에 실패한 경우 더 이상 이후의 과정을 실행하지 않을 수 있다.
상기 320 단계에서 단말(110)이 SM-DP+(120)의 인증에 성공하면, 단말(110)은 325 단계에서 상기 SM-DP+ challenge를 포함하는 데이터에 대하여 eUICC 서명 값(signature)을 생성할 수 있다. 이때, 상기 계산된 eUICC 서명 값은 eUICC signature1일 수 있다. 그리고, 상기 eUICC signature1은 eUICC(115)의 개인키를 이용한 서명일 수 있다. 그리고, 단말(110)은 SM-DP(120)+에게 eUICC signature1 및 프로파일에 대한 정보를 포함하는 메시지를 전송할 수 있다. 이때, 상기 메시지는 인증 요청 메시지(예를 들면, AuthClientRequest)일 수 있다. 그리고, 상기 프로파일에 대한 정보는 프로파일매핑 정보를 포함할 수 있으며, 상기 프로파일 매핑 정보는 SM-DP+(120)에서 프로파일 또는 특정 프로파일 종류를 구분하는데 쓰일 수 있는 정보를 통칭하는 것일 수 있다. 이때, 상기 프로파일에 대한 정보는 다음과 같은 프로파일 매핑 정보를 포함할 수 있다.
- eUICC Identifier or EID
- eUICC 인증서
- EventID
- MatchingID
- ActivationToken
- NotificationID
330 단계에서 SM-DP+(120)는 상기 프로파일 매핑 정보로부터 특정 프로파일이나 프로파일 종류에 대응되는 프로파일 정보를 조회할 수 있다.
또한, SM-DP+(120)는 해당 프로파일을 단말(110)이 다운로드 시 사용자의 암호 코드(confirmation code) 입력이 필요한지를 확인할 수 있다. 이때, SM-DP+(120)에 사용자의 암호 코드(confirmation code) 입력이 필요한지 여부를 구분하는 구분 정보가 저장되어 있다면, SM-DP+(120)는 해당 정보를 확인할 수 있다.
335 단계에서 SM-DP+(120)는 상기 330 단계에서 조회된 프로파일 정보를 포함하는 데이터에 대한 서명 값(SM-DP+ signature2)을 계산할 수 있다. 그리고, SM-DP+(120)는 상기 서명 값(SM-DP+ signature2), 상기 암호화되지 않은 프로파일 정보, 및 confirmation code 입력이 필요한지를 나타내는 정보(ComfirmationCodeRequired)를 단말에 전송할 수 있다. 예를 들면, confirmation code 입력이 필요한지를 나타내는 정보(ComfirmationCodeRequired)는 1 비트 신호로, 0인 경우에는 사용자의 confirmation code 입력이 필요 없고, 1인 경우에는 사용자의 confirmation code 입력이 필요한 것을 지시할 수 있다. 상기 이때, 상기 프로파일 정보는 암호화되지 않은 프로파일 정보일 수 있다.
이에 따라, 단말(110)은 상기 335 단계에서 전달받은 프로파일 정보의 일부 또는 전부를 표시부에 표시하거나, 프로파일 정보의 일부 또는 전부에 대하여 매핑되는 정보를 표시부에 표시할 수 있다. 이때, 상기 매핑되는 정보는 단말(110)에 기저장되어 있거나 외부 서버와 연동하여 획득한 값일 수 있다. 상기 매핑 과정에 이용되는 상기 프로파일 정보의 일부 또는 전부는 다음과 같을 수 있다.
- IMSI
- MCC 또는 MNC 를 포함하는 정보
- MCC 및 MNC를 포함하는 정보
- 사업자 이름
- ICCID 정보의 일부를 구성하는 정보
-사업자 코드
그리고 345 단계에서 단말(110)은 사용자의 프로파일 다운로드 동의를 입력받을 수 있다. 즉, 단말(110)은 사용자로부터 프로파일을 다운로드하는 것을 동의한다는 정보가 입력될 수 있다.
한편, 상기 동의 과정은 다음과 같을 수 있다.
- 단순하게 네 / 아니오 를 표시 하는 표시부에서 '네'에 해당하는 위치를 UI부의 입력 장치(예를 들면, 터치 패드, 버튼 등)를 이용하여 입력
- 지문 인증, 홍체 인증 등의 생체 인증을 이용한 입력
한편, 단말(110)은 상기 사용자 동의 획득 과정과 동시에 또는 별도로 또는 상기 사용자 동의 획득 과정 없이, SM-DP+(120)로부터 전달받은 confirmation code 입력 필요 여부 구분 정보를 확인하여 confirmation code가 필요한지 여부를 확인할 수 있다. confirmation code의 입력이 필요함을 지시하는 정보를 수신한 경우, 단말(110)은 추가적인 confirmation code 입력 요구를 표시하고 UI를 통해 confirmation code를 입력받을 수 있다. 그러면 단말(110)은 사용자로부터 입력받은 confirnmation code와 상기 315 단계에서 수신한 SM-DP+ challenge 정보를 이용하여 해쉬(hash) 연산을 할 수 있다. 그리고 상기 hash 연산을 수행하여, 변형된 confirmation code(또는 해쉬 confirmation code(hased confirmation code))를 생성할 수 있다. 상기 hash 연산은 한번 이상의 hash 연산일 수 있으며, hash 연산을 통해 confirmation code를 숨길 수 있다. 또한 SM-DP+ challenge 값을 연산에 이용하여 매번 다른 hash 결과값이 나오도록 할 수 있다. 상기 연산은 단말(110)의 하나 이상의 CPU에서 별도로 계산될 수 있다. 예를 들면, 계산의 일부는 AP(application process)에서 수행하고 나머지 계산은 모뎀 또는 eUICC(115)에서 수행하여 보안성을 높일 수도 있다.
350 단계에서 단말(110)은 상기 345 단계를 통해 사용자 동의 과정에서 사용자가 프로파일 다운로드를 동의 했는지 여부를 판단할 수 있다.
상기 350 단계에서 사용자가 동의한 것으로 판단된 경우, 360 단계에서 단말(110)은 SM-DP+(120)에게 프로파일 다운로드를 요청할 수 있다. 이때, 단말(110)은 상기 프로파일 다운로드를 요청하는 정보에 대한 eUICC 서명 값(eUICC signature2)을 생성할 수 있다. 그리고, 단말(110)은 상기 eUICC 서명 값(eUICC signature2) 및 상기 프로파일 다운로드 요청 정보가 포함된 요청 메시지(예를 들면, GetBoundProfilePackage)를 SM-DP+(120)에게 전송할 수 있다.
또한, 상기 요청 메시지는 상기 hashed confirmation code를 포함할 수 있다.
그리고, 365 단계에서 SM-DP+(120)는 hashed confirmation code를 검증할 수 있다.
먼저, SM-DP+(120)는 단말(110)로부터 수신한 상기 360 단계의 요청 메시지에 hashed confirmation code가 있는지 확인할 수 있다. 만약, 350 단계에서 수신한 요청 메시지에 hashed confirmation code가 없으면, SM-DP+(120)는 375 단계를 수행할 수 있다.
만약, 360 단계에서 수신한 요청 메시지에 hashed confirmation code가 있는 경우, SM-DP+(120)는 hashed confirmation code를 직접 계산할 수 있다. 그리고, 상기 계산된 hashed confirmation code와 수신한 hashed confirmation code를 비교하여 일치 여부를 확인할 수 있다.
만약 두 값이 일치하면, SM-DP+(120)는 이후 370 단계를 수행할 수 있다.
반면, 만약 두 값이 일치하지 않으면, SM-DP+(120)는 단말(110)에게 프로파일 다운로드 실패를 뜻하는 정보가 포함된 메시지를 전달하고, 이후 과정을 종료할 수 있다.
한편, 370 단계에서 SM-DP+(120)는 상기 360 단계에서 수신한 프로파일 다운로드 요청 정보에 따라서, 암호화된 프로파일을 단말(110)에게 전송할 수 있다.
그러면, 단말(110)은 380 단계에서 암호화된 프로파일을 복호화한 후 프로파일을 설치할 수 있다. 상기 프로파일 복호화는 단말(110) 내부의 eUICC(115)에서 수행될 수 있다.
한편, 만약 상기 350 단계에서 사용자가 동의하지 않은 것으로 판단한 경우, 단말(110)은 390 단계에서 프로파일 동의 안함 보고 및/또는 동의 결과를 SM-DP+(120)에게 전달할 수 있다. 이후 단말(110)은 프로파일 다운로드 절차를 더 이상 수행하지 않고 종료할 수 있다.
그리고, 395 단계에서 SM-DP+(120)는 프로파일 동의 안함 보고를 수신한 경우 프로파일 다운로드 절차를 종료할 수 있다. 그리고 SM-DP+(120)는 단말(110)에게 상기 프로파일 동의 안함 보고에 대한 ACK 메시지를 전달할 수 있다.
이상의 프로파일 다운로드 과정에서 구체적인 프로파일 과정을 상기 과정과 상이할 경우에도 적용될 수 있음은 물론이다.
도 4는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 또 다른 일 예를 도시한 도면이다.
도 4를 참고하면, 410 단계에서 단말(110)은 서버를 검증하기 위한 서버 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, challenge 값일 수 있다. 이때, 상기 challenge 값은 단말(110) 내부의 제어부 또는 단말(110)에 연결된 eUICC(115)에서 생성한 값일 수 있고, 이는 eUICC challenge 값으로 지칭될 수 있다. 그리고, 단말(110)은 상기 서버를 검증하기 위한 정보를 포함하는 메시지를 프로파일 제공 서버(120)에게 전송할 수 있다. 이때, 상기 메시지는 초기 인증 요청 메시지(예를 들면, InitAuthRequest 메시지)일 수 있다. 그리고, 상기 프로파일 제공 서버(120)는 SM-DP+일 수 있다. 한편, 상기 단말(110)은 eUICC(115)를 포함하는 것으로 상기 단말(110)의 동작 중 일부는 eUICC(115)에서 동작할 수도 있다.
그리고, 415 단계에서 SM-DP+(120)는 단말(110)을 검증하기 위한 단말 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, SM-DP+ challenge 값일 수 있고, SM-DP+(120)의 제어부에서 생성될 수 있다. 그리고, SM-DP+(120)는 410 단계에서 수신한 상기 eUICC challenge 값 및 SM-DP+(120)에서 생성한 SM-DP+ challenge값을 포함하는 데이터에 대하여 SM-DP+ 서명 값(signature)을 계산할 수 있다. 이때, 상기 계산된 SM-DP+ 서명 값은 SM-DP+ signature1일 수 있다. 그리고, 상기 SM-DP+ signature1은 SM-DP+ 비밀키를 이용하여 계산한 값이다. SM-DP+(120)는 상기 SM-DP+ signature1 및 SM-DP+ challenge 값을 포함하는 응답 메시지를 단말(110)에 전송할 수 있다.
이후, 420 단계에서 단말(110)은 상기 SM-DP+ signature1을 검증하여 SM-DP+(120)의 인증에 성공한 경우 이후의 과정을 실행하고, 인증에 실패한 경우 더 이상 이후의 과정을 실행하지 않을 수 있다.
상기 420 단계에서 단말(110)이 SM-DP+(120)의 인증에 성공하면, 단말(110)은 425 단계에서 상기 SM-DP+ challenge를 포함하는 데이터에 대하여 eUICC 서명 값(signature)을 생성할 수 있다. 이때, 상기 계산된 eUICC 서명 값은 eUICC signature1일 수 있다. 그리고, 상기 eUICC signature1은 eUICC(115)의 개인키를 이용한 서명일 수 있다. 그리고, 단말(110)은 SM-DP+(120)에게 eUICC signature1 및 프로파일에 대한 정보를 포함하는 메시지를 전송할 수 있다. 이때, 상기 메시지는 인증 요청 메시지(예를 들면, AuthClientRequest)일 수 있다. 그리고, 상기 프로파일에 대한 정보는 프로파일 매핑 정보를 포함할 수 있으며, 상기 프로파일 매핑 정보는 SM-DP+(120)에서 프로파일 또는 특정 프로파일 종류를 구분하는데 쓰일 수 있는 정보를 통칭하는 것일 수 있다. 이때, 상기 프로파일에 대한 정보는 다음과 같은 프로파일 매핑 정보를 포함할 수 있다.
- eUICC Identifier or EID
- eUICC 인증서
- EventID
- MatchingID
- ActivationToken
- NotificationID
430 단계에서 SM-DP+(120)는 상기 프로파일 매핑 정보로부터 특정 프로파일이나 프로파일 종류에 대응되는 프로파일 정보를 조회할 수 있다.
또한, SM-DP+(120)는 해당 프로파일을 단말(110)이 다운로드 시 사용자의 암호 코드(confirmation code) 입력이 필요한지를 확인할 수 있다. 이때, SM-DP+(120)에 사용자의 암호 코드(confirmation code) 입력이 필요한지 여부를 구분하는 구분 정보가 저장되어 있다면, SM-DP+(120)는 해당 정보를 확인할 수 있다.
또한 SM-DP+(120)는 사용자의 confirmation code 입력이 필요한 경우, 악의적인 사업자나 서버로부터 단말(110)을 보호하기 위하여, SM-DP+(120)에서 제1 변형된 confirmation code(또는 제1 해쉬 confirmation code(hashed confirmation code 1))을 생성할 수 있다. 이때, hashed confirmation code 1은 다음과 같이 계산될 수 있다.
hashed confirmation code 1 = hash함수(confirmation code , 난수 A)
이때 confirmation code는 사업자로부터 전달받은 confirmation code일 수 있으며, 난수 A는 단말(110)이 알고 있거나 알게 되는 임의의 난수 값일 수 있다. 예를 들면, 난수 A는 eUICC challenge 또는 SM-DP+ challenge가 될 수 있다.
hash함수는 입력인자 confirmation code 및 난수 A에 대하여 적어도 한번 이상의 hash 연산을 하는 함수일 수 있다. 위와 같은 hashed confirmation code 1의 계산의 일 예는 다음과 같을 수 있다.
hashed confirmation code 1 = SHA256(confirmation code | SM-DP+ challenge)
이와 같은 hashed confirmation code 1을 SM-DP+(120)가 단말(110)에게 전송하면, 이후, 445 단계에서 단말(110)에서는 사용자가 입력한 confirmation code를 바탕으로 hashed confirmation code 1을 계산할 수 있다. 그리고, 계산된 hashed confirmation code 1을 수신한 hashed confirmation code 1과 비교함으로써ㅡ confirmation code를 모르는 악의적 사업자나 SM-DP+(120)로부터 단말(110)이 프로파일을 다운로드 하게 되는 것을 방지할 수 있다.
435 단계에서 SM-DP+(120)는 상기 430 단계에서 조회된 프로파일 정보를 포함하는 데이터에 대한 서명 값(SM-DP+ signature2)을 계산할 수 있다. 그리고, SM-DP+(120)는 상기 서명값(SM-DP+ signature2), 상기 암호화되지 않은 프로파일 정보, confirmation code 입력이 필요한지를 나타내는 정보(ComfirmationCodeRequired), 및 hashed confirmation code 1을 단말에게 전송할 수 있다. 예를 들면, confirmation code 입력이 필요한지를 나타내는 정보(ComfirmationCodeRequired)는 1 비트 신호로, 0인 경우에는 사용자의 confirmation code 입력이 필요 없고, 1인 경우에는 사용자의 confirmation code 입력이 필요한 것을 지시할 수 있다. 상기 이때, 상기 프로파일 정보는 암호화되지 않은 프로파일 정보일 수 있다.
이에 따라, 단말(110)은 상기 435 단계에서 전달받은 프로파일 정보의 일부 또는 전부를 표시부에 표시하거나, 프로파일 정보의 일부 또는 전부에 대하여 매핑되는 정보를 표시부에 표시할 수 있다. 이때, 상기 매핑되는 정보는 단말(110)에 기저장되어 있거나 외부 서버와 연동하여 획득한 값일 수 있다. 상기 매핑 과정에 이용되는 상기 프로파일 정보의 일부 또는 전부는 다음과 같을 수 있다.
- IMSI
- MCC 또는 MNC 를 포함하는 정보
- MCC 및 MNC를 포함하는 정보
- 사업자 이름
- ICCID 정보의 일부를 구성하는 정보
- 사업자 코드
그리고 445 단계에서 단말(110)은 사용자의 프로파일 다운로드 동의를 입력받을 수 있다. 즉, 단말(110)은 사용자로부터 프로파일을 다운로드하는 것을 동의한다는 정보가 입력될 수 있다.
한편, 상기 동의 과정은 다음과 같을 수 있다.
- 단순하게 네 / 아니오 를 표시 하는 표시부에서 '네'에 해당하는 위치를 UI부의 입력 장치(예를 들면, 터치 패드, 버튼 등)를 이용하여 입력
- 지문 인증, 홍체 인증 등의 생체 인증을 이용한 입력
한편, 단말(110)은 상기 사용자 동의 획득 과정과 동시에 또는 별도로 또는 상기 사용자 동의 획득 과정 없이, SM-DP+(120)로부터 전달받은 confirmation code 입력 필요 여부 구분 정보를 확인하여 confirmation code가 필요한지 여부를 확인할 수 있다. confirmation code의 입력이 필요함을 지시하는 정보를 수신한 경우, 단말(110)은 추가적인 confirmation code 입력 요구를 표시하고 UI를 통해 confirmation code를 입력받을 수 있다.
그리고, 단말(110)은 사용자로부터 입력받은 confirnmation code와 상기 415 단계에서 수신한 SM-DP+ challenge 정보를 이용하여, SM-DP+(120)가 상기 435 단계에서 전송한 hashed confirmation code 1을 검증할 수 있다. 즉, 단말(110)은 사용자로부터 입력받은 confirnmation code와 상기 415 단계에서 수신한 SM-DP+ challenge 정보를 이용하여 hashed confirmation code 1을 직접 계산할 수 있다. 그리고, 상기 계산된 hashed confirmation code 1이 SM-DP+(120)가 hashed confirmation code 1과 일치하는지 확인할 수 있다.
또한, 단말(110)은 제2 변형된 confirmation code(또는 제2 해쉬 confirmation code(hashed confirmation code 2))를 계산 할 수 있다. 상기 hashed confirmation code 2의 계산은 한번 이상의 hash 연산일 수 있으며, hash 연산을 통해 confirmation code를 숨길 수 있다. 또한 SM-DP+ challenge 값을 연산에 이용하여 매번 다른 hash 결과값이 나오도록 할 수 있다. 그리고, hashed confirmation code 2은 hashed confirmation code 1과 다른 계산식으로 계산될 수 있다. 상기 연산은 단말(110)의 하나 이상의 CPU에서 별도로 계산될 수 있다. 예를 들면 계산의 일부는 AP(application process)에서 수행하고 나머지 계산은 모뎀 또는 eUICC(115)에서 수행하여 보안성을 높일 수도 있다.
450 단계에서 단말(110)은 상기 445 단계를 통해 사용자 동의 과정에서 사용자가 프로파일 다운로드를 동의 했는지 여부를 판단할 수 있다.
한편, 450 단계에서 사용자가 프로파일 다운로드를 동의한 경우, 단말(110)은 455 단계에서 hashed confirmationn code 1의 검증이 성공하였는지 여부를 판단할 있다.
만약 450 단계에서 사용자가 프로파일 다운로드에 동의한 것으로 판단되었고, 455 단계에서 상기 435 단계에서 SM-DP+(120)로부터 수신한 hashed confirmation code 1 값과 상기 445 단계에서 단말(110)이 계산한 hashed confirmation code 1값이 일치하는 것으로 판단된 경우, 단말(110)은 SM-DP+(120)에게 460 단계에서 프로파일 다운로드를 요청할 수 있다. 이때, 단말(110)은 상기 프로파일 다운로드를 요청하는 정보에 대한 eUICC 서명 값(eUICC signature2)을 생성할 수 있다. 그리고, 단말(110)은 상기 eUICC 서명 값(eUICC signature2) 및 상기 프로파일 다운로드 요청 정보가 포함된 요청 메시지(예를 들면, GetBoundProfilePackage)를 SM-DP+(120)에게 전송할 수 있다.
이 때, 상기 요청 메시지는 상기 hashed confirmation code 2를 포함할 수 있다.
그리고, 465 단계에서 SM-DP+(120)는 hashed confirmation code 2를 검증할 수 있다.
먼저, SM-DP+(120)는 단말(110)로부터 수신한 상기 460 단계의 요청 메시지에 hashed confirmation code 2가 있는지 확인할 수 있다. 만약, 450 단계에서 수신한 요청 메시지에 hashed confirmation code 2가 없으면, SM-DP+(120)는 475 단계를 수행할 수 있다.
만약, 460 단계에서 수신한 요청 메시지에 hashed confirmation code 2가 있는 경우, SM-DP+(120)는 hashed confirmation code 2를 직접 계산할 수 있다. 그리고, 상기 계산된 hashed confirmation code 2와 수신한 hashed confirmation code 2를 비교하여 일치 여부를 확인할 수 있다.
만약 두 값이 일치하면, SM-DP+(120)는 이후 과정 470 단계를 수행할 수 있다.
반면, 만약 두 값이 일치하지 않으면, SM-DP+(120)는 단말(110)에게 프로파일 다운로드 실패를 뜻하는 정보가 포함된 메시지를 전달하고, 이후 과정을 종료할 수 있다.
한편, 470 단계에서 SM-DP+(120)는 상기 460 단계에서 수신한 프로파일 다운로드 요청 정보에 따라서, 암호화된 프로파일을 단말(110)에게 전송할 수 있다.
그러면, 단말(110)은 480 단계에서 암호화된 프로파일을 복호화한 후 프로파일을 설치할 수 있다. 상기 프로파일 복호화는 단말(110) 내부의 eUICC(115)에서 수행될 수 있다.
한편, 만약 상기 450 단계에서 단계에서 사용자가 동의하지 않은 것으로 판단한 경우, 또는 455 단계에서 hashed confirmation code 1의 비교가 실패한 경우, 단말(110)은 490 단계에서 프로파일 동의 안함 보고 및/또는 동의 결과 및/또는 confirmation code 비교 실패 결과를 SM-DP+(120)에게 전달할 수 있다. 이후 단말(110)은 프로파일 다운로드 절차를 더 이상 수행하지 않고 종료할 수 있다.
한편, 실시 예에 따라서 hashed confirmation code 1의 비교가 실패한 경우, 단말(110)은 SM-DP+(120)에게 결과를 보내기,전, 사용자에게 confirmation code를 다시 입력받아 hashed confirmation code 1을 다시 비교하여 결과에 따라 460 단계를 수행할 수도 있다.
그리고, 495 단계에서 SM-DP+(120)는 프로파일 동의 안함 보고를 수신한 경우 프로파일 다운로드 절차를 종료할 수 있다. 그리고 SM-DP+(120)는 단말(110)에게 상기 프로파일 동의 안함 보고에 대한 ACK 메시지를 전달할 수 있다.
이상의 프로파일 다운로드 과정에서 구체적인 프로파일 과정을 상기 과정과 상이할 경우에도 적용될 수 있음은 물론이다.
도 5는 본 발명의 일 실시 예에 따른 단말의 서명 및 암호화 파라미터를 전달하여 서명 및 암호화가 정상적으로 동작하도록 협의 하여 프로파일을 다운로드 하는 방법의 일 예를 도시한 도면이다.
도 5를 참고하면, 510 단계에서 단말(110)은 서버를 검증하기 위한 서버 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, challenge일 수 있다. 이때, 상기 challenge 값은 단말(110) 내부의 제어부 또는 단말(110)에 연결된 eUICC(115)에서 생성한 값일 수 있고, 이는 eUICC challenge 값으로 지칭될 수 있다. 그리고, 단말(110)은 상기 서버를 검증하기 위한 정보 및 eUICC 서명 및 암호화 파라미터를 포함하는 메시지를 프로파일 제공 서버(120)에게 전송할 수 있다. 이때, 상기 메시지는 초기 인증 요청 메시지(예를 들면, InitAuthRequest 메시지)일 수 있다. 그리고, 상기 프로파일 제공 서버(120)는 SM-DP+일 수 있다. 그리고, 상기 eUICC 서명 및 암호화 파라미터는 eUICC Info 정보에 포함되어 SM-DP+(120)에게 전달될 수 있다. 이때, 상기 eUICC challenge는 서명 생성용 알고리즘, eUICC 서명은 서명 검증용 알고리즘이라고 할 수 있다.
서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 단말(110)이 SM-DP+(120)에게 도시된 것과 같이 직접 전달해 주는 방법 이외에 간접적으로 알려주는 방법이 이용될 수도 있다. 예를 들면, 단말(110)과 SM-DP+(120) 사이에 참고 식별 정보들(reference identification)을 정의하고 있을 수 있다. 이 경우, 단말(110)이 SM-DP+(120)에게 상기 참고 식별 정보 값에 따라 특정 값을 전송해 주는 경우 SM-DP+(120)는 상기 수신한 참고 식별 정보 값에 따라 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 각각 확인할 수 있다. 예를 들면, 참고 식별 정보 값이 1인 경우, 서명 생성용 알고리즘은 A이고, 서명 검증용 알고리즘은 B이고, 암호화 파라미터는 C인 것으로 단말(110)과 SM-DP+(120) 사이에 미리 약속하고 있을 수 있다. 이때, 단말(110)이 SM-DP+(120)에게 참고 식별 정보 값 1을 전송해 주는 경우, SM-DP+(120)는 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 각각 확인할 수 있다.
또는 단말(110)(또는 eUICC(115))이 특정 정보를 이용하기로 결정하는 경우에, SM-DP+(120)는 단말(110)이 이용하기로 한 특정 정보에 따라 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 확인할 수도 있을 것이다. 예를 들면, 단말(110)이 특정 파라미터를 쓰기로 하면, 단말(110)과 SM-DP+(120) 사이에 상기 특정 파라미터에 따른 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 대응하기로 약속하고 있을 수 있다. 이때, 단말(110)이 SM-DP+(120)에게 상기 특정 파라미터를 쓴다는 정보를 전송해 주면, SM-DP+(120)는 상기 수신한 특정 파라미터를 쓴다는 정보에 따라 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 각각 확인할 수 있다. 예를 들면, 단말(110)이 특정 CI(certificate issuer)를 쓰기로 결정한 경우, SM-DP+(120)는 상기 특정 CI 정보(CIInfo(CI information))에 따른 서명 생성용 알고리즘, 서명 검증용 알고리즘 및 암호화 파라미터를 각각 확인할 수 있다.
그리고, 515 단계에서 SM-DP+(120)는 단말(110)을 검증하기 위한 단말 검증 정보를 생성할 수 있다. 이때, 상기 서버 검증 정보는 난수 값으로, 예를 들면, SM-DP+ challenge 값일 수 있고, SM-DP+(120)의 제어부에서 생성될 수 있다. 그리고, SM-DP+(120)는 510 단계에서 수신한 상기 eUICC challenge 값 및 SM-DP+(120)에서 생성한 SM-DP+ challenge값을 포함하는 데이터에 대하여 SM-DP+ 서명 값(signature)을 계산할 수 있다. 이때, 상기 계산된 SM-DP+ 서명 값은 SM-DP+ signature1일 수 있다.
한편, SM-DP+(120)는 상기 510 단계에서 전달받은 eUICC 서명 및 암호화 파라미터 를 바탕으로 적합한 서명 및 암호화 파라미터를 선택할 수 있다. 그리고, SM-DP+(120)는 eUICC(115)가 사용할 서명 및 암호화 파라미터를 정하여 단말(110)(또는 eUICC(115))에게 전송할 수 있다. 만약 eUICC(115)가 전달한 서명 및 암호화 파라미터중 SM-DP+(120)가 지원할 수 있는 파라미터가 포함되지 않은 경우에는 SM-DP+(120)는 eUICC(115)의 요청을 거절하여 실패 메시지를 단말(110)에게 전송할 수도 있다.
그리고, 상기 SM-DP+ signature1은 SM-DP+ 비밀키를 이용하여 계산한 값이다. SM-DP+(120)는 상기 SM-DP+ signature1 및 SM-DP+ challenge 값을 포함하는 응답 메시지를 단말(110)에게 전송할 수 있다. 그리고, 상기 응답 메시지에는 SM-DP+(120)가 선택한 eUICC(115)가 사용할 서명 및 암호화 파라미터를 포함할 수 있다.
이후, 520 단계 내지 595 단계의 경우, 도 4와 관련된 부분에서 설명한 420 단계 내지 495 단계와 유사한바, 그 구체적인 설명은 생략하기로 한다.
도 6a 내지 도 6c는 본 발명의 일 실시 예에 따른 단말의 프로파일 다운로드 방법의 구체적인 일 예를 도시한 도면이다.
도 6a 내지 도 6c를 참고하면, 단말(110)이 SM-DS(140)에게 정보를 질의할 때 단말의 구분자(예를 들면, EID)를 직접적으로 노출하지 않아 개인 정보를 보호하면서 프로파일 다운로드를 수행할 수 있다.
한편, 도 6의 610 단계 내지 630 단계는 다음과 같이 조건적으로 수행 가능하다.
610 단계는 LPA(즉, 단말(110))이 이미 eUICC 인증서(예를 들면, CERTS_eUICC), EID를 해쉬한 보호된 EID 값(Protected EID 값), eUICC 정보를 획득한 경우 생략 가능하다. 한편, 단말(110)은 LPA를 포함하는 것으로 본 실시 예에서의 단말(110)의 동작은 LPA에서 이루어질 수도 있다.
620 단계는 프로파일 관리 서버(SM-SR+)(130) 또는 프로파일 제공 서버(SM-DP+)(120)가 MNO(150)로부터 프로파일 다운로드 요청 시 SM-DS(140)를 이용한 프로파일임을 지시 받은 경우 수행될 수 있다.
630 단계는 이미 단말(110)(LPA)이 eventType, dpToken1, srToken1 정보를 받은 경우 생략 가능하다.
이하, 각 단계를 구체적으로 살펴보도록 한다.
611 단계 및 612 단계에서 단말(110)은 eUICC(115)로부터 CERTS_eUICC를 읽을 수 있다. 이때, CERTS_eUICC는 eUICC 인증서 및 EUM 인증서를 포함하는 정보일 수 있다. 이를 위해 단말(110)은 611 단계에서 eUICC(115)에게 CERTS_eUICC를 요청하는 정보(GetCert)가 포함된 LocalManangementRequest 메시지를 전송하고, 612 단계에서 단말(110)은 eUICC(115)로부터 CERTS_eUICC가 포함된 LocalManagementResponse 메시지를 수신할 수 있다.
그리고 613 단계 및 614 단계에서 단말(110)은 eUICC(115)로부터 protected EID 값을 읽을 수 있다. protected EID는 다음의 정보를 하나 이상 포함할 수 있다.
시간 정보,
EID 또는 해쉬한 EID 값,
EID를 서명한 값
이때 상기 해쉬한 EID 값 또는 EID를 서명한 값은 시간 정보를 포함하여 연산한 값일 수 있다. 이를 위해 단말(110)은 613 단계에서 eUICC(115)에게 protected EID 값을 요청하는 정보(GetEID)가 포함된 LocalManangementRequest 메시지를 전송하고, 612 단계에서 단말(110)은 eUICC(115)로부터 protected EID 값이 포함된 LocalManagementResponse 메시지를 수신할 수 있다.
615 단계 및 616단계에서 단말(110)은 eUICC(115)로부터 eUICCInfo를 수신할 수 있다.
eUICCInfo는 다음의 정보를 포함할 수 있다.
eUICC의 서명 및 암호화를 위한 타원곡선파라미터,
eUICC의 잔여 메모리 크기 등.
이를 위해 단말(110)은 615 단계에서 eUICC(115)에게 eUICCInfo를 요청하는 정보(GetEUICCInfo)가 포함된 LocalManangementRequest 메시지를 전송하고, 612 단계에서 단말(110)은 eUICC(115)로부터 eUICCInfo가 포함된 LocalManagementResponse 메시지를 수신할 수 있다.
621 단계 및 622 단계에서 eUICCManagementRequest 또는 프로파일 다운로드 요청 또는 프로파일 관리 요청 메시지가 SM-DS(140) 사용을 이용한 프로파일 다운로드 처리 또는 프로파일 관리를 지시하는 지시정보를 포함하는 경우, SM-SR+(130)나 SM-DP+(120)는 SM-DS(140)에게 event 등록을 요청할 수 있다. 이를 위해 621 단계에서 SM-SR+(130)는 SM-DS(140)에게 프로파일 매핑 정보(EventID), EID, 서버 ID(SRID) 등을 포함하는 RegisterEventRequest 메시지를 전송하고, 그에 따라, SM-SR+(130)는 622 단계에서 결과 코드(ResultCode)를 포함하는 RegisterEventResponse 메시지를 SM-DS(140)로부터 수신할 수 있다.
623 단계에서 SM-DS(140)는 단말(110)에게 푸쉬 서버를 통해 푸쉬 notification을 전달할 수 있다.
624 단계에서 단말(110)은 SM-DS(140)에게 protected EID를 포함하는 EventID(프로파일 매핑 정보) 요청 메시지(EventIDRequest)를 보낼 수 있다. 그러면, SM-DS(140)는 protected EID를 검증할 수 있다. 특히, protected EID에 포함된 시간 정보가 SM-DS(140)에서 EventID 요청 메시지를 받은 시간보다 특정 범위 이상 오래된 시간인 경우, SM-DS(140)는 해당 검증은 통과시키지 않을 수 있다. 추가적으로, 상기 검증은 SM-DS(140)가 해쉬 값 또는 서명 값이 유효한지 검증하는 것을 포함할 수 있다. 상기 검증 중 어느 것이라도 실패하면 SM-DS(140)는 단말(110)에게 응답을 하지 않거나 거절 사유에 해당하는 응답 코드를 포함하는 응답 메시지를 전달할 수 있다.
625 단계에서 SM-DS(140)는 단말(110)에게 하나 또는 복수 개의 EventID 및 서버 주소(SRID)의 정보 쌍을 전달할 수 있다. 상기 서버 주소(SRID)는 해당 EventID를 처리할 서버 주소가 포함된 것으로 해당 서버는 SM-DS(140) 또는 SM-DP+(120) 또는 SM-SR+(130)일 수 도 있다. 실시 예에 따라서 EventID가 없는 경우에는 SM-DS(140)는 EventID 정보를 전달하지 않을 수 있다. 편의를 위해 아래의 631 단계에서는 서버 주소가 SM-DP+(120) 또는 SM-SR+(130)의 주소인 경우를 가정하도록 한다.
631 단계 및 632 단계에서 단말(110)이 이전의 단계를 통해 EventID및 서버 주소를 획득한 경우, 단말(110)은 SM-SR+(130) 또는 SM-DP+(120)에게 직접 EventID를 이용하여 해당 EventID에 대한 처리 요청을 시작할 수 있다. 상기 EventID에 대한 처리는 프로파일 다운로드 또는 프로파일 원격 관리 또는 eUICC 원격 관리 또는 다른 EventID 및 서버 주소를 반환하는 것 중 하나 일 수 있다. 이때, 단말(110)은 단말 정보 (terminal Info) 또는 eUICC 정보(eUICC Info)도 포함하여 SM-SR+(130) 또는 SM-DP+(120)에게 해당 EventID에 대한 처리를 요청할 수 있다. 한편, 단말(110)이 SM-SR+(130)에게 요청한 경우에는 상기 요청은 SM-DP+(120)도 일부 정보를 추가 또는 생략하여 전달받을 수도 있다. 그리고, 단말 정보는 단말의 IMEI 또는 그 일부 값이 포함될 수 있다.
상기 단말 정보 또는 eUICC 정보를 SM-SR+(130) 또는 SM-DP+(120)가 확인한 경우, 해당 정보 중 하나 이상을 SM-SR+(130) 나 SM-DP+(120)가 지원하지 않으면, SM-SR+(130)나 SM-DP+(120)는 해당 요청을 거절(reject)하고 상기 과정을 종료할 수 있다. 예를 들면, 상기 eUICC 정보에 포함된 ECC 서명 파라미터 또는 암호화 파리미터를 SM-SR+(130) 나 SM-DP+(120)가 지원하지 않는 경우, SM-SR+(130) 나 SM-DP+(120)는 상기 요청을 거절할 수 있다. 또는 SM-SR+(130) 나 SM-DP+(120)는 상기 eUICC 정보에 포함된 ECC 서명 파라미터 또는 암호화 파라미터 중 일부 또는 전체를 지원하는 경우, 지원하는 파라미터를 선정하여 서명 검증, 서명 생성, 암호화 생성 등을 수행할 수도 있다.
633 단계에서 SM-DP+(120)가 SM-SR+(130)로부터 상기 요청을 전달받은 경우, SM-DP+(120)는 EventID에 포함된 SM-SR+(130)의 구분자와 SM-SR+(130)의 인증서에 포함된 SM-SR+(130) 구분자가 일치하는지 검증할 수도 있다. 이때, 상기 SM-SR+(130) 인증서는 ECDSA 서명을 위한 인증서 일 수 있다.
그리고, 634 단계에서 SM-DP+(120)는 프로파일 암호화를 위해 임시 비대칭키 쌍(ECKA ephemeral key pari)을 생성 할 수 있다.
635 단계에서는, 12. SM-DP+(120)는 DPToken1을 생성할 수 있다.이때, DPToken1은 다음의 정보 중 적어도 하나를 포함할 수 있다.
profileRecordPart1 (프로파일 평문 정보 일부를 포함)
ePK_DP_ECKA (상기 임시 비대칭키 쌍중 공개키)
sign_DP1 (SM-DP+ 서명1)
cert_DP_ECDSA (SM-DP+ 서명용 인증서)
cert_DP_ECKA (SM-DP+ 암호화용 인증서)
confirmType (사용자 동의 유형)
confirmMessage (사용자 동의 추득시 메시지)
confirmCodeHash1 (컨펌 코드 해쉬값1)
특히 SM-DP+는 confirmType이 사용자의 컨펌 코드 입력을 요하는 값이 포함된 경우, 상기 컨펌 코드 해쉬 값 1을 생성할 수 있다.
상기 컨펌 코드는 사용자에게 컨펌 코드를 전달해준 사업자에게 정상적으로 컨펌 코드를 전달받은 SM-DP+(120)라면 정상적인 컨펌 코드 해쉬 값 1을 단말(110)에게 전달할 경우, 단말(110)에서 사용자가 입력한 컨펌 코드를 기반으로 SM-DP+(120)를 검증하여, 프로파일 다운로드가 비정상적인 서버로부터 온 것이 아님을 추가적으로 검증하게 하는 안전 장치 역할을 할 수 있다.
특정 프로파일에 대하여 컨펌 코드가 고정된 경우라도 SM-DP+(120)는 이러한 컨펌 코드 해쉬 값 1을 매번 다르게 생성할 수 있다. 일 례로, SM-DP+(120)는 다음과 같이 컨펌 코드 해쉬 값 1을 생성할 수 있다.
SM-DP+(120)가 생성하는 confirmCodeHash1 = SHA256 (ePK_DP_ECKA | confirm code)
이때 상기 confirm code는 SM-DP+(120)가 사업자에게서 전달받은 값이다.
이렇게 생성한 컨펌 코드 해쉬 값 1은 이후 단말(110)에게 전달되어, 사용자가 입력한 confirm code를 기반으로 SM-DP+(120)가 보낸 정보와 대응되지 않는 경우 단말(110)에서 프로파일 다운로드를 차단하는 역할을 할 수 있다. 이때 단말(110)은 전달받은 컨펌 코드 해쉬 값 1과 단말(110)에서 계산한 컨펌 코드 해쉬 값 1을 비교할 수 있다. 실시 예에 따라, 단말(110)에서 계산한 컨펌 코드 해쉬 값 1은 사용자가 입력한 컨펌 코드와 SM-DP+(120)로부터 받은 ePK_DP_ECKA 값을 이용하여 SHA256 (ePK_DP_ECKA | confirmCode) 공식을 이용한 결과 값일 수 있다.
이 외에도 다른 공식으로 SM-DP+(120) 및 단말(110)에서 confirmCodeHash1 값을 생성할 수 있는데, confirm code와 매번 달라지게 생성되는 값을 인자로 사용하는 것은 변함이 없다. 예를 들면, confirmCodeHash1 값을
confirmCodeHash1 = SHA256 (ePK_DP_ECKA | SHA256(confirmCode))
와 같은 방법으로 생성할 수 도 있다.
636 단계에서 SM-DP+(120)는 DPToken1을 포함하는 응답 메시지를 SM-SR+(130)에게 전송할 수 있다. 이때, 상기 응답 메시지는 ES3_DownloadProfileResponse일 수 있다.
그리고, 637 단계에서 SM-SR+(130)는 SRToken1을 생성할 수 있다.
이때, SRToken1은 다음의 정보 중 하나 이상 포함할 수 있다.
SM-SR+ 인증서
1회용 랜덤 값
SM-SR+ 서명 값
이때, 1회용 랜덤 값은 서명 값을 재사용하여 단말(110)을 해킹하는 재현공격(replay attack)을 방지하는데 이용될 수 있다. 그리고, 추후 SM-SR+(130)는 상기 1회용 랜덤 값을 단말(110)의 서명을 검증하여 단말(110)을 인증하는 용도로도 사용할 수도 있다.
638 단계에서 SM-SR+(130)는 응답 메시지를 단말(110)에게 전송할 수 있다. 이때, 상기 응답 메시지는 ES9_EventResponse일 수 있다.
그리고, ES9_EventResponse는 다음 중 적어도 하나를 포함할 수 있다.
resultCode
eventType
srToken1
dpToken1
상기 eventType은 '다운로드 프로파일(downloadProfile)'에 관한 정보를 지시하는 것이다, 그리고, 실시 예에 따라서 상기 ES9_EventResponse는 DPToken1를 포함할 수 있다.
만약, 상기 631 단계에서 수신한 ES9_EventRequest에 포함된 EventID가 유효하지 않은(invalid) 경우, SM-SR+(130)는 단말(110)에게 ES9_EventResponse의 resultCode에 에러 정보를 포함하여 전송할 수 있다. 그리고, SM-SR+(130)는 SM-DS(140)에게 상기 수신한 EventID를 포함하는 ES12_DeleteEventRequest(이벤트 삭제 요청 메시지)를 675 단계에서 전송할 수 있다.
639 단계에서 단말(110)은 eUICC(115)에게 인증 데이터 요청 메시지를 전송할 수 있다. 이때, 상기 인증 데이터 요청 메시지는 ES10_GetAuthDataRequest일 수 있다.
그리고, ES10_GetAuthDataRequest 는 다음의 정보 중 적어도 하나를 포함할 수 있다.
eventID
eventType
srToken1
dpToken1
terminalType
provisioningType
그리고, 상기 terminalType 정보는 아래와 같은 단말 구분 정보를 포함할 수 있다.
TerminalType ::= ENUMERATED {
without_UI (0),
with_UI (1)
}
상기 provisioningType 정보는 프로파일 다운로드 과정에 SM-DS(140)가 포함될지, 포함 안될지 구분하는 정보를 포함할 수 있다.
ProvisioningType ::= ENUMERATED {
without_SM-DS (0),
with_SM-DS (1)
}
이때, 상기 ES10_GetAuthDataRequest 메시지는 eventType이 'downloadProfile'인 경우에 dpToken1, terminalType, 및 provisioningType을 포함할 수 있다.
641 단계에서 eUICC(115)는 srToken1을 검증(verify)할 수 있다.
이때, 검증 과정은 다음과 같을 수 있다. eUICC(115)가 PK_CI_ECDSA를 이용하여 CERT_SR_ECDSA를 검증(verify)할 수 있다. 그리고 eUICC(115)는 CERT_SR_ECDSA로부터 PK_SR_ECDSA를 추출(extract)하고, PK_SR_ECDSA 및 NONCE_SR로 SIGN_SR1을 검증할 수 있다. eUICC(115)는 추후 659 단계에서 사용하기 위하여, PK_SR_ECDSA 및 NONCE_SR를 eventID와 함께 저장할 수 있다.
그리고, eUICC(115)는 eventType이 'downloadProfile'인 경우, 프로파일을 저장(store)하기 위하여 보안 도메인(security domain)을 생성(create)하고 식별(identify)할 수 있다.
그 후, eUICC(115)는 dpToken1을 검증할 수 있다.
이때, 검증 과정은 다음과 같을 수 있다. eUICC(115)가 PK_CI_ECDSA를 이용하여 CERT_DP_ECDSA를 검증할 수 있다. 그리고 eUICC(115)는 CERT_DP_ECDSA로부터 PK_DP_ECDSA를 추출하고, PK_DP_ECDSA 및 ePK_DP_ECKA로 SIGN_DP1를 검증할 수 있다. eUICC(115)는 PK_CI_ECDSA를 이용하여 CERT_DP_ECKA를 검증할 수 있다. eUICC(115)는 CERT_DP_ECKA로부터 PK_DP_ECKA를 추출할 수 있다. 그 후, eUICC(115)는 추후 659 단계에서 사용하기 위하여, PK_DP_ECDSA, PK_DP_ECKA, 및 ePK_DP_ECKA를 저장할 수 있다. eUICC(115)는 또한 추후 662 단계에서 사용하기 위하여, profileRecordPart1를 저장할 수 있다.
만약 어느 검증이라도 실패하는 경우, 상기 eUICC(115)는 단말(110)에게 에러 메시지를 전송할 수 있다.
srToken1 및 dpToken1의 검증(verification)이 성공적으로 완료된 경우, eUICC(115)는 642 단계에서 SRID, DPID, EventID, EventType, Target EID, ProfileType, ProfileDescription, MNO의 PLMNID, TerminalType, ConfirmType, 및 ProvisioningType 등과 같은 verified 된 정보(verified information)를 가질 수 있다.
이러한 정보를 가지고, eUICC(115)는 프로파일 다운로드 절차를 계속하여 진행할 것인지 여부를 다음과 같이 결정할 수 있다.
- eUICC(115)는 CERT_SR_ECDSA에포함된 SRID가 eUICC(115)의 설정(eUICC's configuration)에 따라 허용되는지(permitted) 검증할 수 있다.
- eUICC(115)는 CERT_DP_ECDSA에 포함된 DPID가 eUICC(115)의 설정(eUICC's configuration)에 따라 허용되는지(permitted) 검증할 수 있다.
- eUICC(115)는 PLMNID가 eUICC(115)의 설정(eUICC's configuration)에 따라 허용되는지(permitted) 검증할 수 있다.
- 만약 TerminalType이 without_UI인 경우, eUICC(115)는 ConfirmType이 yesOrNo인지 검증할 수 있다.
- 만약 TerminalType이 with_UI인 경우, ConfirmType이 yesOrNo이고, ProvisioningType이 with_SM-DS이면, eUICC(115)는 PLMNID가 eUICC(115)의 설정(eUICC's configuration)에 따라 허용되는지(permitted) 검증할 수 있다.
만약 모든 검증이 성공적으로 수행된 경우, eUICC(115)는 프로파일 다운로드 절차의 나머지 절차를 수행할 수 있다.
그러나, 만약 검증들 중 어느 하나라도 실패한 경우, eUICC(115)는 상기 이벤트(event)를 거절하고(reject), 상기 거절 이유에 대한 응답 메시지를 전송할 수 있다.
643 단계에서 eUICC(115)는 ephemeral 공중 키(ephemeral public key(ePK_eUICC_ECKA)) 및 ephemeral 개인 키(ephemeral private key(eSK_eUICC_ECKA)) 쌍을 생성할 수 있다.
그리고, 상기 eUICC(115)는 ePK_eUICC_ECKA, eSK_eUICC_ECKA, PK_SR_ECDSA, PK_DP_ECDSA, 및 NONCE_SR를 EventID와 함께 저장할 수 있다.
644 단계에서 eUICC(115)는 eUICC 토큰(EUICCToken)을 생성할 수 있다.
이때, EUICCToken은 다음의 정보 중 적어도 하나를 포함할 수 있다.
eventID
sign_eUICC (eUICC가 생성한 서명값)
nonce_eUICC (eUICC가 생성한 1회용 랜덤값)
ePK_eUICC_ECKA (eUICC가 생성한 임시 비대칭키쌍중 공개키)
eUICCInfo EUICCInfo
eUICC signature(sign_eUICC)는 SK_eUICC_ECDSA로 계산될 수 있다.
상기 계산에 NONCE_SR를 포함하는 것은 SM-SR+(130)에 의한 eUICC(115)의 인증(authentication)을 위한 것이고, 상기 계산에 ePK_DP_ECKA를 포함하는 것은 SM-DP+(120)에 의한 eUICC(115)의 인증(authentication) 을 위한 것이다.
eUICC(115)는 추후 660 단계에서 사용하기 위하여 세션 키(session keys)를 생성하고 저장할 수 있다. 이때,Receipt이 상기 session keys와 함께 생성될 수 있다. Receipt는 첫 번째 SCP03t CommandTLV(first SCP03t CommandTLV)를 위한 초기 MAC chaining 값(initial MAC chaining value)에 사용될 수 있다.
645 단계에서 eUICC(115)는 ES10_GetAuthDataResponse 메시지를 단말(110)에게 전송할 수 있다.
이때, ES10_GetAuthDataResponse 메시지는 다음 중 적어도 하나를 포함할 수 있다.
resultCode 결과코드
eUICCToken
만약, 상기 645 단계에서 단말(110)이 수신한 ES10_GetAuthDataResponse 메시지 내의 resultCode가 거절(reject)을 지시하는 경우, 단말(110)은 670 단계로 진행하여, SM-SR+(130)에게 ES9_NotifyResultRequest 메시지를 전송할 수 있다. 이때, ES9_NotifyResultRequest 메시지는 ES10_GetAuthDataResponse 메시지에 포함되어 있던 resultCode를 포함하여 SM-SR+(130)에게 전송될 수 있다(670 단계의 메시지에 포함된 EventResult 정보). 반면, 만약 상기 645 단계에서 단말(110)이 수신한 ES10_GetAuthDataResponse 메시지 내의 resultCode가 성공(success)을 지시하는 경우, 단말(110)은 646 단계에서 다음과 같이 사용자의 confirmation을 요청할 수 있다.
- 만약dpToken1.confirmType이 'yesOrNo'인 경우, 단말(110)은 eventType 및 profileRecordPart1 등과 같은 필수 정보(necessary information)들을 사용자에게 보여주어, 사용자에게 eUICC 관리(eUICC management) 이벤트의 실행(execution)의 명확한 동의(explicitly consent)를 요청(ask)할 수 있다.
- 만약 dpToken1.confirmType이 'codeInput'인 경우, 단말(110)은 사용자에게 subscription 동안에 MNO(150)로부터 수신한 confirmation code의 입력을 요청할 수 있다. 그리고, 단말(110)은 수신한 dpToken1.confirmCodeHash1이 올바른 것인지(correct) 다음 식으로 검증할 수 있다.
SHA256 (dpToken1.ePK_DP_ECKA | confirmCode input by user)
만약 검증에 실패한 경우, SM-DP+(120)는 SM-SR+(130)에게 에러 메시지를 전송할 수 있다.
- 만약 ES9_EventResponse 메시지가 dpToken1.confirmMessage를 포함하는 경우, 단말(110)은 confirmation 을 요청할 때에 사용자에게 상기 메시지를 표시하여 줄 수 있다.
- 예외적으로, 만약 단말(110)이 UI가 없는(without UI) M2M 장치(device)이고, confirmType이 'yesOrNo'인 경우, 단말(110)은 사용자 confirmation 절차(procedure)를 생략(skip)할 수 있다.
만약 사용자가 프로파일 다운로드를 승인한 경우(accepts the Profile download), 단말(110)은 647 단계에서 SM-SR+(130)에게 ES9_eUICCManagementRequest 메시지를 전송할 수 있다.
ES9_eUICCManagementRequest 메시지는 다음의 정보 중 적어도 하나를 포함할 수 있다.
eUICCToken
confirmCodeHash2 단말에서 계산한 컨펌 코드 해쉬 값 2
certs_eUICC CERTS_eUICC
이때, confirmCodeHash2는 단말(110)에 의해 다음과 같이 계산될 수 있다.
SHA256 ( ePK_eUICC_ECKA | ePK_DP_ECKA | confirmCode input by the user )
반면, 만약 사용자가 프로파일 다운로드를 거절(reject)한 경우, 단말(110)은 670 단계로 진행하여 SM-SR+(130)에게 ES9_NotifyResultRequest 메시지를 전송할 수 있다. 이때, ES9_NotifyResultRequest 메시지는 'User_Rejected'를 지시하는 resultCode(resultCode of 'User_Rejected') 및 대응하는 evnetID(corresponding eventID)를 포함할 수 있다.
648 단계에서 SM-SR+(130)은 eUICCToken 및 CERTS_eUICC를 검증할 수 있다.
이때, 검증 절차는 다음과 같을 수 있다. SM-SR+(130)는 SM-SR+(130)에 저장된 CERT_CI_ECDSA 및 CERTS_eUICC에 포함되어 전달된 CERT_EUM_ECDSA(the CERT_EUM_ECDSA delivered in the CERTS_eUICC)로 CERT_eUICC_ECDSA를 검증할 수 있다..
SM-SR+(130)는 다음으로 CERT_eUICC_ECDSA로부터 PK_eUICC_ECDSA를 추출(extract)하고, PK_eUICC_ECDSA, ePK_DP_ECKA, 및 NONCE_SR로 sign_eUICC를 검증할 수 있다. SM-SR+(130)는 eventID와 함께 저장된 ePK_DP_ECKA 및 NONCE_SR 값(NONCE_SR values)을 이용할 수 있다.
만약 어떠한 검증이라도 실패한 경우, SM-SR+(130)은 단말(110) 및 SM-DP+(120)에게 에러 값을 전송할 수 있다.
만약 모든 검증이 성공한 경우, 이것은 SM-SR+(130)이 성공적으로(successfully) eUICC(115)를 인증(authenticated)한 것을 의미할 수 있다.
649 단계에서 SM-SR+(130)은 SM-DP+(120)에게 ProfileRequest 메시지를 전송할 수 있다.
ES3_ProfileRequest 메시지는 다음의 정보 중 적어도 하나를 포함할 수 있다.
eUICCToken
nonce_SR
confirmCodeHash2
certs_eUICC
그리고, 651 단계에서 SM-DP+(120)는 eUICCToken 및 CERTS_eUICC를 검증할 수 있다.
이때, 검증 절차는 다음과 같을 수 있다. SM-DP+(120)는 SM-DP+(120)에 저장된 CERT_CI_ECDSA 및 CERTS_eUICC에 포함되어 전달된 CERT_EUM_ECDSA(CERT_EUM_ECDSA delivered in the CERTS_eUICC)로 CERT_eUICC_ECDSA 및 CERT_eUICC_ECKA예를 검증할 수 있다.
SM-DP+(120)는 다음으로 CERT_eUICC_ECDSA로부터 PK_eUICC_ECDSA를 추출(extract)하고, PK_eUICC_ECDSA, ePK_DP_ECKA, 및 NONCE_SR로 sign_eUICC를 검증할 수 있다. SM-DP+(120)는 eventID와 함께 저장된 ePK_DP_ECKA, 및 649 단계에서 SM-SR+(130)로부터 수신한 NONCE_SR를 이용할 수 있다.
다음으로, SM-DP+(120)는 CERT_eUICC_ECKA 내의 PK_eUICC_ECKA를 추출(extract)할 수 있다.
만약 event.userConfirmation.confirmType이 'codeInput'인 경우, SM-DP+(120)는 수신한 ES3_ProfileRequest.confirmCodeHash2 이 올바른지(correct) 다음 식으로 검증할 수 있다.
SHA256 (eUICCToken.ePK_eUICC_ECKA | ePK_DP_ECKA | event.userConfirmation.confirmCode)
만약 어떠한 검증이라도 실패한 경우, SM-DP+(120)는 SM-SR+(130)에게 에러 값을 전송할 수 있다.
만약 모든 검증이 성공한 경우, 이것은 SM-DP+(120)가 성공적으로(successfully) eUICC(115)를 인증(authenticated)한 것을 의미할 수 있다.
652 단계에서 SM-DP+(120)는 PK_eUICC_ECKA, SK_DP_ECKA, ePK_eUICC_ECKA, 및 eSK_DP_ECKA로부터 SCP03t AES session keys를 전달(derive)할 수 있다.
이때, SCP03tSessionKey 는 다음 중 적어도 하나의 정보를 포함할 수 있다.
sENC 보내는 정보의 암호화 위한 암,복호화 키
sMAC 보내는 정보의 무결성 위한 무결성 보호 키
sRMAC 받는 정보의 무결성 위한 무결성 보호 키
653 단계에서 SM-DP+(120)는 ProfileInstallPackage를 생성할 수 있다.
이때, ProfileInstallPackage는 다음의 정보 중 적어도 하나를 포함할 수 있다.
dpToken2 DPToken2,
profileProtectionKey 암호화 키 변경키
securedProfilePackage 암호화된 프로파일
그리고, DPToken2는 다음의 정보를 포함할 수 있다.
sign_DP2 SIGN_ECDSA
이때, 상기 sign_DP2는 SM-DP+(120)에서 생성된 signature이다.
상기 profileProtectionKey는 pre-generated SCP03t AES keys 를 포함하는 옵션의 SCP03tCommand TLV(optional SCP03tCommand TLV)이다. 상기 pre-generated SCP03t AES keys는 SecuredProfilePackage를 보호하는데 사용될 수 있다. 상기 TLV는 상기 652 단계에서 전달된 SCP03t session keys로 보호될 수 있다.
654 단계에서 SM-DP+(120)는 SM-SR+(130)에게 ES3_ProfileResponse 메시지를 전송할 수 있다.
이때, ES3_ProfileResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
profileInstallPackage ProfileInstallPackage
그리고, 655 단계에서 SM-SR+(130)는 srToken2를 생성할 수 있다.
이때, srToken2는 다음의 정보를 포함할 수 있다.
sign_SR2 SIGN_ECDSA
상기 signature sign_SR2는 SK_eUICC_ECDSA로 계산될 수 있다.
656 단계에서 SM-SR+(130)는 단말(110)에게 ES9_eUICCManagementResponse 메시지를 전송할 수 있다.
이때, ES9_eUICCManagementResponse는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
profileInstallPackage ProfileInstallPackage OPTIONAL,
srToken2 SRToken2
657 단계에서 단말(110)은 eUICC(115)에게 ES10_EstablishSecureChannelRequest 메시지를 전송할 수 있다.
그리고, 만약 eUICC(115)가 ES10_EstablishSecureChannelRequest를 수신한 경우, 658 단계에서 eUICC(115)는 먼저 srToken2를 검증할 수 있다.
상기 검증 절차는 다음과 같을 수 있다. eUICC(115)는 PK_SR_ECDSA로 sign_SR2를 검증할 수 있다.
만약 검증이 실패한 경우, eUICC(115)는 단말(110)에게 에러 값을 전송할 수 있다.
만약 상기 685 단계의 검증이 성공한 경우, eUICC(115)는 659 단계에서 dpToken2를 검증할 수 있다.
상기 검증 절차는 다음과 같을 수 있다. eUICC(115)는 PK_DP_ECDSA로 sign_DP2예를 검증할 수 있다.
이때, eUICC(115)는 상기 641 단계에서 EventID와 함께 저장된 ePK_eUICC_ECKA, NONCE_SR, 및 PK_DP_ECDSA values를 SIGN_DP2의 검증에 이용할 수 있다.
eUICC(115)는 eUICC(115)에 저장된 PK_CI_ECDSA로 CERT_DP_ECKA를 검증할 수 있다.
다음으로, eUICC(115)는 CERT_DP_ECKA에서 PK_DP_ECKA를 추출(extract)할 수 있다.
상기 eUICC(115)는 CERT_DP_ECKA 내의 DPID 예및 CERT_DP_ECDSA 내의 DPID이 동일한지(identical) 확인(check)할 수 있다.
만약 어떠한 검증이라도 실패한 경우, eUICC(115)는 단말(110)에게 에러 메시지를 전송할 수 있다.
만약 모든 검증이 성공한 경우, 이것은 eUICC(115)이 SM-DP+(120) 및 SM-SR+(130)에 의해 성공적으로 인증(authenticated)되었다는 것을 의미할 수 있다.
만약 상기 659 단계의 검증이 성공한 경우, 660 단계에서 eUICC(115)는 상기 644 단계에서 생성된 SCP03t session keys를 이용하여 보안 채널(secure channel)을 오픈(open)할 수 있다(즉, eUICC(115)는 본 단계 이후에SCP03tCommandTLV를 복호(decrypt)할 수 있다).
세션 키들(session keys)을 생성한 후, eUICC(115)는 661 단계에서 단말(110)에게 ES10_EstablishSecureChannelResponse TLV를 전송할 수 있다.
662 단계에서는 단말(110)이 eUICC(115)에게 ES10_InstallProfileRecordRequest 메시지를 전송할 수 있다.
eUICC(115)는 securedProfileRecordPart2를 profileRecordPart2로 복호할 수 있다(decrypt). 그리고, eUICC(115)는 상기 641 단계에서의 DPToken1로부터 획득한 profileRecordPart1와 profileRecordPart2를 조합(combining)하여 ProfileRegistry 내의 ProfileRecord(ProfileRecord in the ProfileRegistry)를 생성할 수 있다.
663 단계에서 eUICC(115)는 ES10_InstallProfileRecordResponse 메시지를 단말(110)에게 리턴(return)할 수 있다.
664 단계는 옵션 절차로(optional procedure), 만약 profileProtectionKey TLV를 포함하는 ProfileInstallPackage 메시지가 delivered from the SM-SR+(130)/SM-DP+(120) 로부터 수신된 경우, 단말(110)은 eUICC(115)에게 profileProtectionKey를 전송하기 위한 ES10_UpdateSessionKeyRequest 메시지를 전송할 수 있다.
만약 eUICC(115)가 ES10_UpdateSessionKeyRequest 메시지를 수신한 경우, eUICC(115)는 profileProtectionKey를 SCP03tSessionKey로 복호화하고(decrypt), SCP03t session keys를 복호된 SCP03tSessionKey(decrypted SCP03tSessionKey)로 대체(replace)할 수 있다. 그리고, 업데이트된 SCP03t session keys(updated SCP03t session keys)는 the subsequent SCP03tCommandTLVs을 established secure channel을 통해 보호하는데 이용될 수 있다.
만약 session keys가 ES10_UpdateSessionKeyRequest 메시지에 의해 업데이트된 경우, first subsequent SCP03tCommandTLV는 C-MAC을 포함할 수 있다. 상기 C-MAC은 16 바이트(bytes) '0x00'으로 세트(set)되도록 "MAC chaining value"와 계산될 수 있다.
665 단계는 옵션 절차로, 상기 664 단계 이후, eUICC(115)는 ES10_UpdateSessionKeyResponse 메시지를 단말(110)에게 리턴(return)할 수 있다.
그리고, 단말(110)은 666 단계에서 eUICC(115)에게 ES10_ InstallProfilePackageBlockRequest 메시지를 전송할 수 있다.
그리고, 667 단계에서 eUICC(115)는 session keys로 securedProfilePackageBlock을 복호(decrypt)할 수 있다. 복호화된(decrypted) ProfilePackageBlock는 하나 또는 복수의 프로파일 엘리먼트들(Profile Elements(PEs)) 및/또는 프로파일 엘리먼트의 일부분(parts of Profile Element)을 포함할 수 있다. 프로파일 엘리만터의 일부분은 이전에 저장된 프로파일 엘리먼트의 일부분(들)(previously stored part(s) of PE)과 결합(combined)되어 단일의 완전한 PE(single complete PE)를 만들 수 있다. 만약 상기 복호화(decryption) 및 가능한 조합(possible combining)이 하나 또는 복수의 완전한 PE들(one or multiple complete PEs)을 야기하는 경우(result in), eUICC(115)는 PEs을 적절히(in order) 인스톨(install)할 수 있다. 남은(remaining) 및/또는 불완전한(incomplete) PE(s)은 나중에 사용되기 위하여 eUICC(115)에 저장될 수 있다.
ProfilePackageBlock의 처리 후, eUICC(115)는 668 단계에서 resultCode를 포함하는 ES10_InstallProfilePackageBlockResponse 메시지를 단말(110)에게 전송할 수 있다.
상기 666 단계 내지 668 단계는 마지막 ProfilePackageBlock이 전송될 때까지 반복(iterate)될 수 있다. 만약 ES10_InstallProfilePackageBlockRequest 메시지가 그 값이 lastPB (1)인 lastPBIndicator를 포함하고, 모든 PEs이 성공적으로 인스톨된 경우, eUICC(115)는 resultCode 뿐만 아니라 eventResult를 포함하는 ES10_InstallProfilePackageBlockResponse 메시지 및 ProfileRegistry 내의 프로파일을 위한 ProfileRecord를 생성하고.
만약 단말(110)이 eventResult를 포함하는 ES10_InstallProfilePackageBlockResponse 메시지를 eUICC(115)로부터 수신한 경우, 670 단계에서 단말(110)은 SM-SR+(130)에게 eUCCI(115)에 의해 생성된 eventResult를 포함하는 ES9_NotifyResultRequest 메시지를 전송할 수 있다. 만약 단말(110)이 eUICC(115)로부터 eventResult와 함께 ES10_InstallProfilePackageBlockResponse 메시지를 수신한 경우, 단말(110)은 shall SM-SR+(130)에게 eUCCI(115)에 의해 생성된 eventResult를 포함하는 ES9_NotifyResultRequest 메시지를 전송할 수 있다.
상기 ES9_NotifyResultRequest 는 다음의 정보를 포함할 수 있다.
eventResult (eUICC의 처리 결과)
cert_EUM_ECDSA (EUM 인증서)
resultCode (결과코드)
그리고, EventResult 는 다음의 정보를 포함할 수 있다.
resultCode
eID
eventID
profileID 프로파일 구분자
sign_Result eUICC가 생성한 처리결과 서명 값
그리고, SM-SR+(130)는 다음의(following) TLV로 응답할 수 있다(responds with). 만약 SM-SR+(130)가 단말(110)이 전송한 eventResult 내의 eventID를 알지 못하는 경우(is not aware of), SM-SR+(130)는 단말(110)에게 대응하는 resultCode와 함께 에러 메시지를 전송할 수 있다.
이때, ES9_NotifyResultResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode
만약 SM-SR+(130)이 단말(110)로부터 결과 통지(result notification)을 수신한 경우, SM-SR+(130)는 상기 결과(result)를 MNO(150) 및/또는 SM-DP+(120)에게 전송할 수 있다(680, 681, 683, 684, 685, 686 단계 참고). 만약 상기 결과 통지(result notification)가 성공적임(success)을 지시하는 경우, SM-SR+(130)는 자신의 데이터베이스(database)에서 EventID를 삭제하여, SM-SR+(130)가 동일한 이벤트의 처리를 반복하지 않도록 할 수 있다: 이것은 상기 이벤트가 SM-DS(140)에서 성공적으로 삭제되지 않은 경우에, 단말(110)이 SM-SR+(130)에게 동일한 이벤트를 요청한 경우에 발생할 수 있고, 따라서 단말(110)에 의해 다시 페치(fetched)될 수 있다.
또한, EventIDs이 성공적으로 완료된 경우에 EventIDs를 eUICC(115)가 저장하고 유지하는 것이 추천된다.그에 따라 eUICC(115)는 완료된 이벤트가 SM-DS(140) 및 SM-SR+(130)의 데이터베이스에서송공적으로 삭제되지 않고, 동일한 이벤트가 그 뒤에 eUICC(115)를 향해 초기화된(initiated) 상황을 조절할 수 있다(하기 690 단계 및 691 단계 참고). eUICC(115)는 이 것을 인식하고(recognize) 실패(failure)를 리턴(return)할 수 있다.
만약 수립된(established) secure channel이 더 이상 필요 없는 경우, 단말(110)은 672 단계에서 eUICC(115)에게 ES10_ReleaseSecureChannelRequest 메시지를 전송할 수 있다. 이때, ES10_ReleaseSecureChannelRequest 메시지는 eUICC(115)이 to secure channel 및 그에 연관된 session keys를 을 해제(release)하라는 정보가 포함될 수 있다.
만약 ES10_ReleaseSecureChannelRequest 메시지가 전송된 경우, eUICC(115)는 673 단계에서 secure channel 및 그에 연관된 session keys를 release하고, 그 후 그에 대한 응답으로 ES10_ReleaseSecureChannelResponse 메시지를 단말(110)에게 전송할 수 있다.
secure channel이 release되면, eUICC(115)는 만약 새로운 secure channel을 재설정(re-establishing)하라는 정보가 포함되지 않은 SCP03tCommandTLV이 수신되면 에러 메시지를 전송할 수 있다.
674 단계는 옵션 절차로, 단말(110)은 사용자에게 인스톨된 프로파일(installed profile)의 enabling에 대해 문의할 수 있다. 만약 사용자가 상기 프로파일의 enabling에 동의한 경우, 단말(110)은 local Profile Enabling procedure를 진행할 수 있다.
만약 단말(110)로부터 전송된 ES9_NotifyResultRequest 메시지가 프로파일의 성공적인 인스톨(installation)을 지시하는 경우, SM-SR+(130)은 675 단계에서 SM-DS(140)에게 다운로드 프로파일 이벤트의 EventID를 포함하는 ES12_DeleteEventRequest 메시지를 전송할 수 있다. 그리고 SM-DS(140)는 상기 620 단계에서 저장된 EventID 및 그에 연관된 파라미터들(parameters)을 자신의 데이터베이스에서 삭제할 수 있다.
이때, ES12_DeleteEventRequest 메시지는 다음의 정보를 포함할 수 있다.
eventID EventID
그리고 SM-DS(140)는 676 단계에서 다음의 TLV를 응답할 수 있다. 만약 SM-DS(140)가 ES12_DeleteEventRequest 내의 eventID를 알지 못하는 경우(is not aware of), SM-DS(140)는 SM-SR+(130)에게 resultCode와 함께 실패(failure) 메시지를 지시할 수 있다.
이때, SM-DS(140)가 SM-SR+(130)에게 전송하는 응답 메시지는 ES12_DeleteEventResponse 메시지일 수 있고, ES12_DeleteEventResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode
667 단계에서 SM-SR+(630)는 SM-DP+(120)에게 ES3_NotifyResultRequest 메시지를 전송할 수 있다. 이때, ES3_NotifyResultRequest 메시지는 eUICC(115)에 의해 생성된 eventResult를 포함할 수 있다. 그리고, ES3_NotifyResultRequest 메시지는 SM-DP+(120)가 SM-DP+(120)에 의해 전송된 ProfilePackage의 다운로드 및 인스톨 결과를알도록 할 수 있다.
이때, ES3_NotifyResultRequest 메시지는 다음의 정보를 포함할 수 있다.
eventResult EventResult OPTIONAL, /* conditional if ES9_NotifyResultRequest contains eventResult */
resultCode ResultCode OPTIONAL -- otherwise
그리고, SM-DP+(120)는 678 단계에서 다음의 TLV를 응답할 수 있다. 만약 SM-DP+(120)가 eventResult 내의 eventID를 알지 못하는 경우(is not aware of), SM-DP+(120)는 SM-SR+(130)에게 resultCode와 함께 실패(failure) 메시지를 전송할 수 있다.
이때, SM-DP+(120)가 SM-SR+(130)에게 전송하는 응답 메시지는 ES3_NotifyResultResponse 메시지일 수 있고, 다음의 정보를 포함할 수 있다.
resultCode ResultCode
SM-DP+(120)는 만약 단말(110)에 의해, 또는 SM-DP+(120)을 통해 MNO(150)에 의해 프로파일 다운로드가 지시된 경우 MNO(150)에게 680 단계에서 ES2_NotifyResultRequest 메시지를 전송할 수 있다. . 대안적으로, 만약 단말(110)에 의해, 또는 SM-SR+(130)을 통해 MNO(150)에 의해 프로파일 다운로드가 지시된 경우 SM-SR+(130)는 683 단계에서 MNO(150)에게 ES4_NotifyResultRequest 메시지를 전송할 수 있다. 상기 ES2 또는 ES4의 NotifyResultRequest 메시지 인터페이스(interface)는 eUICC(115)에 의해 생성된 eventResult를 포함할 수 있다.
이때, ES2_NotifyResultRequest 메시지는 다음의 정보 중 적어도 하나를 포함할 수 있다.
eventResult,
resultCode
그리고, ES4_NotifyResultRequest 메시지는 다음의 정보 중 적어도 하나를 포함할 수 있다..
eventResult
cert_eUICC_ECDSA
cert_EUM_ECDSA
resultCode
그리고, MNO(150)는 681 단계 또는 684 단계에서 다음의 TLV를 전송할 수 있다.
이때, 681 단계에서 전송되는 ES2_NotifyResultResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode
그리고, 684 단계에서 전송되는 ES4_NotifyResultResponse 메시지는 다음의 정보를 포함한다.
resultCode (결과코드)
690 단계는 옵셜 절차로, 단말(110)은 SM-DS(140)에게 download Profile event의 EventID 및 ProtectedEID를 포함하는 ES11_DeleteEventRequest 메시지를 전송할 수 있다.
이때, ES11_DeleteEventRequest 메시지는 다음의 정보 중 적어도 하나를 포함할 수 있다.
protectedEID 또는 EID
eventID
상기 SM-DS(140)는 691 단계에서 protectedEID 및 eventID 검증할 수 있다. 만약 protectedEID.sign_eID가 유효하고(valid) eventID가 eUICC(115)를 위한 것인 경우, SM-DS(140)는 데이터베이스에서 대응하는 이벤트를 삭제할 수 있다. SM-DS(140)는 단말(110)에게 ES11_DeleteEventResponse 메시지를 처리 결과(processing result)와 함께 전송할 수 있다.
이때, ES11_DeleteEventResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode
본 단계는 만약 SM-SR+(130)(unintentionally)이 그것을 스킵하고 및/또는 삭제하는 것을 실패한 경우, 단말(110)이 이미 처리된 이벤트들의 불필요한 통지(notification)를 수신하는 것을 방지하고,.
본 도 6과 관련된 실시 예의 단계들을 통해서, 본 파라미터들 및 메시지들은 특정 단계에서 바로 생성하는 것보다 더 효율적이고 가능한 경우에는 상기 특정 단계에 앞서 미리 생성되고(pre-generated) 저정될 수 있다.
도 7a 및 도 7b는 본 발명의 일 실시 예에 따른 eUICC에 프로파일을 다운로드 하는 과정의 다른 실시 예이다.
도 7a 및 도 7b를 참고하면, SM-DP+(120)는 SM-SR+(130) 없이 LPA(즉, 단말(110))과 직접 일반적인 IP 기반의 HTTPS를 이용하여 통신할 수 있다.
우선 SM-DP+(120)는 SM-DP의 서명용 인증서(CERT.DP.ECDSA) 및 개인키(SK.DP.ECDSA)를 내부 저장소에 보관한다. 그리고 SM-DP+(120)는 HTTPS를 위한 TLS용 서버 인증서(CERT.DP.TLS) 및 개인키(SK.DP.TLS)도 내부 저장소에 보관할 수 있다. 상기 CERT.DP.ECDSA 및 SK.DP.ECDSA, CERT.DP.TLS, SK.DP.TLS가 저장되는 내부 저장소는 물리적으로 같은 저장 장치이거나 다른 저장 장치일 수 있다.
eUICC(115)는 eUICC(115)의 서명용 인증서(CERT.EUICC.ECDSA) 및 개인키(SK.eUICC.ECDSA)를 내부 저장소에 보관할 수 있다. 이하 프로파일 다운로드 과정은 다음과 같다.
710 단계에서 단말(110)은 eUICC(115)에게 eUICC 인증서를 요청할 수 있다. 그에 따라, eUICC(115)는 713 단계에서 단말(110)에게 eUICC 인증서(CERT.eUICC.ECDSA) 및 EUM 인증서(CERT.EUM.ECDSA)를 전송할 수 있다.
이때, 이미 단말(110)에 상기 인증서가 저장되어 있다면, 710 단계 및 713 단계는 생략할 수 있다.
만약 eUICC(115)의 서명 값을 서버(예를 들면 SM-DP+(120))에게 전달해야 한다면, 715 단계에서 단말(110)이 eUICC(115)에게 서명 값 생성 요청을 할 수 있다. 이때, 서명에 들어가는 인자는 단말(110)에서 전달해 주는 값으로 그 값은 다음의 값 중 적어도 하나를 포함할 수 있다.
- EventID (특정 프로파일 다운로드 이벤트를 구분하는 구분자)
- NotificationID (EventID와 유사함)
- MatchingID (EventID와 유사함)
- Activation Code Token (EventID와 유사함)
- 단말에서 생성한 랜덤값
한편, eUICC(115)의 서명 값이 필요없는 경우 상기 715 단계에서 단말(110)은 eUICC(115)의 서명 값을 제외한, eUICC(115)의 정보(eUICC Info)를 요청할 수 있다.
그리고, eUICC(115)는 717 단계에서 SK.eUICC.ECDSA를 이용해 eUICC(115)의 서명 값을 생성할 수 있다.
그리고 719 단계에서 eUICC(115)는 단말(110)에게 eUICC 서명 값을 전송할 수 있다. 만약 eUICC 서명 값이 필요없는 경우, eUICC(115)는 단말(110)에게 eUICC_Info만 반환할 수 있다. 이때, eUICC_Info는 예를 들면 eUICC(115)의 버전 정보 등을 포함할 수 있다.
720 단계에서 단말(110)은 SM-DP+(120)에게 "ES9+.InitiateDownload" 메시지를 전송할 수 있다. 이때, 상기 ES9+.InitiateDownload 메시지의 전송 전 단말(110)과 SM-DP+(120) 사이에 HTTPS 세션 연결을 설정할 수 있다. 상기 HTTPS 세션 연결은 프로파일 다운로드 전과정에서 같은 세션일 수도 있고, 별도의 세션일 수도 있다.
그리고, 상기 ES9+.InitiateDownload 메시지는 ES9.InitiateAuthentication 메시지 또는 ES9.EventRequest 메시지일 수도 있다.
상기 ES9+. InitiateDownload 메시지에는 eUICC_Info가 들어가며, 추가적으로 eUICC challenge가 들어 갈 수 있다. 또한 eUICC 서명 값이 들어가는 경우, eUICC 인증서 및 EUM 인증서도 포함될 수 있다.
SM-DP+(120)가 720 단계에서 eUICC 인증서 및 서명 값을 전달받은 경우에는, SM-DP+(120)는 725 단계에서 CI 인증서 또는 CI 인증서 공개키(PK.CI.ECDSA)를 이용하여 EUM 인증서를 검증하고, EUM 인증서를 이용하여 eUICC 인증서를 검증하고, eUICC 인증서를 이용하여 eUICC 서명 값을 검증할 수 있다. 실시 예에 따라 상기 인증서 검증 및 서명 검증은 생략될 수도 있다.
그리고, SM-DP+(120)는 eUICC_Info 정보를 기반으로 eUICC(115)의 적합성(eligibility)을 체크할 수 있다. 이때 eUICC_Info의 eUICC 버전 정보를 활용할 수 있다.
그리고 SM-DP+(120)는 DP challenge를 생성할 수 있다. DP challenge는 추후 SM-DP+(120)가 eUICC(115)를 인증하기 위해 생성하는 값이다.
그리고 SM-DP+(120)는 TransactionID를 생성할 수 있다. 해당 TransactionID는 SM-DP+(120)가 복수의 단말 요청을 동시에 처리할 수 있도록 특정 프로파일 다운로드 세션을 구분해 주는 구분자이다. 이와 같은 TransactionID로 구분하지 않을 경우, SM-DP+ 서버(120)는 한번에 하나의 단말(110)에 대해서만 프로파일을 다운로드 할 수 있고, 만약 특정 단말(110)이 SM-DP+(120)와 연동중 응답을 지연하는 경우, 다른 단말(110)이 프로파일을 다운로드 할 수 없는 문제가 있다. 이를 해결하기 위해 SM-DP+ 서버(120)에서 특정 세션의 라이프 타임을 적용하여 일정 시간이 지나면 세션을 삭제할 수도 있지만, 이 경우에는 SM-DP+ 서버(120)에서 처리할 수 있는 성능에 문제가 발생하는 것은 마찬가지이다.
그리고, 만약 SM-DP+(120)가 단말(110)로부터 MatchingID를 전달받았거나, EID를 전달받은 경우, SM-DP+(120)는 해당 MatchingID에 대응되거나 EID에 대응되는 다운로드 해줄 프로파일이 있는지 확인할 수도 있다.
SM-DP+(120)는 eUICC_Challenge 값, DP Challenge 값, TransactionID 값을 포함하는 데이터에 대하여 SK.DP.ECDSA를 이용하여 DP 서명 값(DP signature)을 계산할 수 있다.
상기 DP 서명값은 eUICC(115)에서 SM-DP+(120)를 인증하기 위한 서명 값이다.
그리고, SM-DP+(120)는 상기 720 단계의 메시지에 대한 응답으로 727 단계에서 SM-DP+(120)의 서명용 인증서 CERT.DP.ECDSA, DP challenge, TransactionID, DP signature, 프로파일 정보, confirmation code 입력 필요 여부 구분자(ConfirmationCodeRequired 구분자)를 단말(110)에게 전송할 수 있다.
이 경우, 단말(110)은 729 단계에서 프로파일 정보를 표시하고, 사용자 동의 획득 또는 confirmation code 입력을 받을 수 있다.
그리고, 단말(110)은 상기 727 단계의 정보를 수신하면, 730 단계에서 eUICC(115)에게 ES10b.PrepareDownload 메시지를 전송할 수 있다. ES10b.PrepareDownload 메시지는 ES10.GetAuthDataRequest 메시지일 수 있다.
그리고, 상기 ES10b.PrepareDownload 메시지는 CERT.DP.ECDSA, DP Challegne, TransactionID, DP Signature를 포함할 수 있다.
735 단계에서 eUICC(115)는 우선 DP 인증서를 eUICC(115)에 저장된 CI 인증서 또는 CI의 공개키를 이용하여 검증할 수 있다(CERT.DP.ECDSA).
상기 인증서 검증에 성공하면 eUICC(115)는 SM-DP+ 서명 값(DP Signature)를 검증할 수 있다.
이때 상기 SM-DP+ 서명 값 검증에는 단말(110)로부터 전달받은 DP challenge, TransactionID 및 eUICC(115)가 단말(110)에게 전달했던 eUICC challenge값, CERT.DP.ECDSA에 포함되어 있는 SM-DP+(120)의 공개키(PK.DP.ECDSA)를 이용한다.
그리고, 검증에 통과하면 eUICC(115)는 1회용 비대칭키 쌍을 생성할 수 있다.
다음과 같은 경우에는 eUICC(115)는 사전에 생성했던 1회용 비대칭키 쌍을 로드하여 사용할 수도 있다.
- 특정한 SM-DP+ 서버(120)로부터의 요청인 경우
- 단말(110)이 별도의 Indicator로 요청한 경우
상기 1회용 비대칭키 쌍은 서버(120)의 1회용 비대칭기쌍과 함께 SM-DP+(120)와 eUICC(115) 간의 암호키를 생성하는데 사용할 수 있다. 암호키 생성 방식은 다음과 같을 수 있다.
- SM-DP+(120)는 SM-DP+(120)의 1회용 개인키와 eUICC(115)의 1회용 개인키를 결합하여 암호키 생성
- eUICC(115)는 eUICC(115)의 1회용 개인키와 SM-DP+(120)의 1회용 공개키를 결합하여 암호키 생성
상기 암호키 생성에 추가로 필요한 인자는 SM-DP+(120)가 이후의 단계에서 단말(110)을 통해 eUICC(115)에게 전달할 수 있다.
eUICC(115)는 생성한 1회용 비대칭키 쌍 중 1회용 공개키(otPK.EUICC.ECKA) 및 DP challenge를 포함하는 데이터에 대하여, eUICC(115)의 서명용 개인키 (SK.eUCIC.ECDSA)를 이용하여 eUICC 서명 값(eUICC_Sign2)을 계산할 수 있다. 상기 eUICC 서명 값 계산에 SM-DP+(120)가 생성한 DP challenge값을 포함했기 때문에 이 eUICC 서명 값은 이후 스텝에서 SM-DP+(120)가 eUICC(115)를 인증하는 용도로 사용할 수 있다. 또한 eUICC_Sign2는 eUICC(115)가 생성한 otPK.eUICC.ECKA 값이 SM-DP+(120)에게 변조되지 않고 전달될 수 있는 기능을 한다.
그리고, 737 단계에서 eUICC(115)는 생성한 eUICC(115)의 1회용 공개키 및 생성한 eUICC 서명 값을 단말(110)에게 전송할 수 있다.
740 단계에서 단말(110)은 SM-DP+(120)에게 ES9+GetBoundProfilePackage 메시지를 전솔할 수 있다. 상기 ES9+GetBoundProfilePackage 메시지는 eUICCManagementRequest 메시지 또는 ProfileRequest 메시지와 같이 명명할 수도 있다.
상기 ES9+GetBoundProfilePackage 메시지는 1회용 eUICC 공개키 및 상기 eUICC 서명 값이 포함될 수 있다. 추가적으로 ES9+GetBoundProfilePackage 메시지에는 eUICC 서명 값 검증을 위한 eUICC 서명용 인증서(CERT.eUICC.ECDSA) 및 eUICC 서명용 인증서 검증을 위한 EUM 인증서(CERT.eUICC.ECDSA)도 포함 될 수 있다.
추가적으로 특정 프로파일을 다운로드하는데 매핑용 구분자로 활용될 수 있는 다음 값이 ES9+GetBoundProfilePackage 메시지에 포함될수도 있다.
- EventID
- MatchingID
- NotificationID
- Activation Code Token
상기 매핑용 구분자는 이전 단계(즉, 720 단계)에서 전달된 경우 전달하지 않을 수도 있다.
또한, 단말(110)은 SM-DP+(120)에게 Hashed Confirmation Code를 전달할 수 도 있다.
그리고, 745 단계에서 SM-DP+(120)는 상기 725 단계에 설명된 방법으로 EUM 인증서 및 eUICC 인증서를 검증할 수 있다.
그리고 SM-DP+(120)는 상기 740 단계에서 단말(110)로부터 수신한 eUICC 1회용 공개키 및 상기 727 단계에서 단말(110)에게 전달했던 DP challenge 값과 eUICC 인증서에 포함된 공개키를 이용하여 eUICC 서명(eUICC Sign2)을 검증할 수 있다. 검증에 통과한 경우 SM-DP+(120)는 eUICC(115)를 인증한 것이 된다. 만약 검증에 실패한 경우 SM-DP+(120)는 해당 세션에 대한 동작을 멈추고 에러를 단말(110)에게 리턴할 수 있다.
또한, SM-DP+(120)는 상기 740 단계에서 전달받은 EventID(또는 NotificationID 또는 MatchingID 또는 Activation Code Token) 값을 이용하여 다운로드할 프로파일을 매핑할 수 있다. 만약 다운로드할 프로파일이 없는 경우, SM-DP+(120)는 에러를 단말(110)에게 리턴하고 해당 세션을 종료할 수 있다.
그리고 SM-DP+(120)는 1회용 비대칭키 쌍을 생성할 수 있다. 생성한 1회용 비대칭키 쌍은 eUICC(115)와 SM-DP+(120) 간의 암호키 생성에 사용될 수 있다. 암호키 생성 방식은 다음과 같을 수 있다.
- SM-DP+(120)는 SM-DP+(120)의 1회용 개인키와 eUICC(115)의 1회용 개인키를 결합하여 암호키 생성
- eUICC(115)는 eUICC(115)의 1회용 개인키와 SM-DP+(120)의 1회용 공개키를 결합하여 암호키 생성
그리고 SM-DP+(120)는 SM-DP+ 서명값(DP signature2)을 계산할 수 있다. 상기 SM-DP+ 서명값은 CRT, SM-DP+(120)의 1회용 공개키, eUICC(115)의 1회용 공개키, TransactionID를 포함한 데이터에 대하여 SM-DP+(120)의 서명용 개인키(SK.DP.ECDSA)를 이용하여 계산한 값일 수 있다. 상기 CRT는 암호키 생성의 인자로 사용할 수 있다.
SM-DP+(120)는 특정 eUICC(115)에 결합된 프로파일 패키지(Bound Profile Package or BPP)를 생성할 수 있다. 상기 BPP는 CRT, SM-DP+(120)의 1회용 공개키, DP Signature2를 포함할 수 있다.
또한 BPP는 상기 암호키로 암호화된 ProfileInfo(또는 MetaData)를 포함할 수 있다.
또한 BPP는 프로파일 보호 키(Profile Protection Key)를 상기 생성한 암호키로 암호화한 암호화된 PPK를 포함할 수 있다.
또한 BPP는 상기 생성한 암호키 또는 상기 PPK로 암호화된 Profile Package Block(PPB)들을 포함할 수 있다. 상기 암호화된 PPB들은 전체 프로파일 데이터를 설치 가능한 단위(Profile Element or PE)로 쪼갠후 암호화 가능 크기 단위로 나눈 PPB를 암호화한 것이다. 상기 암호화는 SCP03t 프로토콜을 사용할 수 있다.
이후, SM-DP+(120)는 상기 740 단계의 메시지에 대한 응답으로 747 단계에서 BPP 메시지를 단말(110)에게 전송할 수 있다.
단말(110)은 750 단계에서 eUICC(115)으로의 ES10b.LoadBoundProfilePackage 메시지의 전송을 복수번 수행하여, BPP에 포함된 ES8_InitializeSecureChannel 정보를 eUICC(115)에게 전달할 수 있다. ES8_InitilizaseSecureChannel 정보는 CRT, SM-DP+(120)의 1회용 공개키, DP signature2를 포함 할 수 있다. ES8_InitilizaseSecureChannel는 EstablishSecureChannel을 지칭할 수도 있다. 그리고, 상기 ES10b.LoadBoundProfilePackage 메시지는 StoreData 명령을 전송하는 것일 수 있다.
이후, 753 단계에서 eUICC(115)는 우선 상기 730 단계에서 전달받은 DP 서명용 인증서(CERT.DP.ECDSA)의 공개키(PK.DP.ECDSA) 및 상기 750 단계에서 전달받은 CRT, SM-DP+ 1회용 공개키 및 상기 737 단계에서 단말(110)에게 전달했던 eUICC(115)의 1회용 공개키를 이용하여 DP 서명(DP signature2)를 검증할 수 있다.
검증에 실패하면, 755 단계에서 eUICC(115)는 에러를 단말(110)에게 리턴하고 이후 과정을 수행하지 않는다.
검증에 통과하면, 755 단계에서 eUICC(115)는 CRT 및 eUICC(115)의 1회용 개인키, SM-DP+(120)의 1회용 공개키를 이용하여 암호키를 생성하고 단말(110)에게 전송할 수 있다.
757 단계에서 단말은 ES10b.LoadBoundProfilePackage 메시지의 전송을 복수번 수행하여, BPP에 포함된 ES8+SetProfileInfo 정보를 eUICC(115)에게 전달할 수 있다. ES8+SetProfileInfo는 ES8+.StoreMetadata 또는 InstallProfileRecord로 지칭할 수도 있다. ES8+SetProfileInfo에는 ProfileInfo(또는 Metadata 또는 ProfileRecord)가 포함될 수 있다. 그리고 759 단계에서 eUICC(115)는 응답 메시지를 단말(110)에게 전송할 수 있다.
그리고 760 단계에서 단말(110)은 전달받은 BPP에 ES8+ReplaceSessionKey가 포함된 경우, ES10b.LoadBoundProfilePackage 메시지 전송을 복수번 수행하여, BPP에 포함된 ES8+ReplaceSessionKeys 정보를 eUICC(115)에게 전달할 수 있다. 상기 ES8+ReplaceSessionKeys는 UpdateSessionKeyRequest 메시지로 지칭될 수 있다.
상기 ES8+ReplaceSessionKeys는 상기 745 단계의 암호키로 암호화한 ProfileProtectionKey(PPK)가 포함될 수 있다.
그리고 763 단계에서 eUICC(115)는 상기 760 단계에서의 메시지에 대한 응답 메시지를 단말(110)에게 전송할 수 있다.
이후, 단말(110)은 765 단계에서 ES10b.LoadBoundProfilePackage 메시지 전송을 복수번 수행하여, BPP에 포함된 암호화된 profile package block(PPB) 또는 profile segment들을 eUICC(115)에게 전달할 수 있다.
각 profile segment는 상기 암호키 또는 PPK로 복호화되어 순서대로 eUICC(115)에서 처리될 수 있다.
모든 profile segment 처리후 eUICC(115)는 767 단계에서 eUICC 서명 값을 계산하여 단말(110)에게 전송할 수 있다. 이때 단말(110)은 770 단계에서 해당 eUICC 서명 값을 SM-DP+(120)에 전달하여 프로파일 설치 결과를 알려줄 수 있다. 그리고 그에 따른 응답 메시지를 SM-DP+(120)가 775 단계에서 단말(110)에게 전송할 수 있다.
다음은 SM-DP+(120)에서 단말(110)로 전달하는 사용자 동의 필요 여부 및 confirmation code required 구분 정보를 표현하는 한 예이다.
UserConfirmation ::= SEQUENCE {
confirmType ConfirmType,
confirmMessage ConfirmMessage OPTIONAL
}
ConfirmType ::= ENUMERATED { yesOrNo (0), codeInput (1) }
ConfirmMessage ::= UTF8String
위의 예에서 UserConfirmation 데이터는 그대로 또는 다른 데이터와 함께 SM-DP+(120)에서 단말(110)로 전달될 수 있다. UserConfirmation에 포함되어 있는 confirmType은 다음과 같은 값을 가질 수 있다.
confirmType 값이 0이면 yesOrNo로, 이 경우 단말(110)은 도 2 내지 도 6에서와 같이 프로파일 다운로드 동의 여부를 선택할 수 있다.
confirmType 값이 1이면 codeInput이 필요한 것으로, 즉 confirmation code 입력이 필요함을 의미한다.
또한 Confirmation Message는 단말(110)이 사용자에게 보여줄 추가 정보가 될 수 있으며 그 정보는 사업자마다 다르게 구성할 수 있다.
도 8a 및 도 8b는 본 발명의 일 실시 예에 따른 네트워크 초기화 절차의 일 예를 도시한 도면이다.
만약, MNO(150)가 전송하는 eUICCManagementRequest 메시지 내의 eventType이 'profileDownload'가 아닌 경우, 무선 관리(remote management)가 ES8의 연관(involvement) 없이, ES5 security에서만 수행될 수 있다. 구체적인 절차는 다음과 같다.
810 단계에서 LPA(즉, 단말(110))이 eUICC(115)로부터 CERTS_eUICC를 읽을 수 있다. 이때, CERTS_eUICC는 eUICC 인증서 및 EUM 인증서를 포함하는 정보일 수 있다. 이를 위해 단말(110)은 810 단계에서 eUICC(115)에게 CERTS_eUICC를 요청하는 정보(GetCert)가 포함된 LocalManangementRequest 메시지를 전송하고, 813 단계에서 단말(110)은 eUICC(115)로부터 CERTS_eUICC가 포함된 LocalManagementResponse 메시지를 수신할 수 있다. 만약 단말(110)이 이미 CERTS_eUICC를 가지고 있는 경우, 810 단계 및 8136 단계는 생략될 수 있다. 본 단계에 대하여는 상기 도 6의 611 단계 및 612 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
그리고, 820 단계에서 MNO(820)는 SM-SR+(130)에게 ES4_eUICCManagementRequest 메시지를 전송할 수 있다.
이때, 상기 ES4_eUICCManagementRequest 메시지는 다음의 정보를 포함할 수 있다.
event Event,
dsInfo DSInfo
상기 Event는 상기 도 6과 관련된 부분에서 설명되었다. ES4_eUICCManagementRequest 메시지의 EventID의 값은 NULL일 수 있다.
823 단계에서 SM-SR+(130)는 상기 관리 이벤트(managaement event)를 위한 글로벌 유니크 eventID(globally unique EventID)를 생성할 수 있다.
그리고 SM-SR+(130)는 825 단계에서 MNO(150)에게 eUICCManagementResponse 메시지를 전송할 수 있다. 이때, eUICCManagementResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
eventID EventID OPTIONAL -- conditional if resultCode indicates Success
SM-SR+(130)는 830 단계 및 833 단계에서 ES12_RegisterEventRequest 메시지 및 ES12_RegisterEventResponse 메시지를 통해 상기 Event를 SM-DS(140)과 등록을 할 수 있다. . 이때, 상기 ES12_RegisterEventRequest 메시지 및 ES12_RegisterEventResponse 메시지는 상기 도 6과 관련된 부분에서 설명한 621 단계 및 622 단계에서 설명하였다.
SM-DS(140)는 push notification 메시지를 단말(110)에게 push server를 통해 전송할 수 있다.
그리고, 단말(110)은 840 단계 및 843 단계에서 eUICC(115)로부터 ProtectedEID 값을 읽을 수 있다. 상기 ProtectedEID는 추후 845 단계에서 이용될 수 있다. 만약 단말(110)이 이미 ProtectedEID 값을 알고 있는 경우, 단말(110)은 840 단계 및 843 단계를 생략할 수 있다. 단말(110)은 본 단계들을 상기 810 단계 및 813 단계보다 먼저 수행할 수도 있다. 본 단계에 대하여는 상기 도 6의 613 단계 및 614 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
단말(110)은 SM-DS(140)에게 845 단계에서 EventIDRequest 메시지를 전송할 수 있다.
이때, EventIDRequest 메시지는 다음의 정보를 포함할 수 있다.
protectedEID ProtectedEID
그러면, SM-DS(140)는 ProtectedEID를 검증할 수 있다. 특히, protected EID에 포함된 시간 정보가 SM-DS(140)에서 EventID 요청 메시지를 받은 시간보다 특정 범위 이상 오래된 시간인 경우, SM-DS(140)는 해당 검증은 통과시키지 않을 수 있다.본 단계에 대하여는 상기 도 6의 624 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
이후, SM-DS(140)는 단말(110)에게 ES11_EventIDResponse 메시지를 전송할 수 있다.
상기 ES11_EventIDResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
eventIDList SEQUENCE OF PendingEvent -- conditional if resultCode indicates success
그리고, PendingEvent는 다음의 정보를 포함할 수 있다.
eventID EventID,
srID SRID
단말(110)이 SM-DS(140)에게 EventID를 요청하는 경우, SM-DS(140)에는 적어도 하나의 PendingEvent가 있을 수 있다. 이 경우, eventIDList는 하나 이상의 PendingEventID를 포함할 수 있다. 그러면 단말(110)은 eventIDList에 포함된 순서대로 PendingEvents를 하나 하나 처리할 수 있다.
850 단계 및 853 단계에서 단말(110)은 eUICC(115)로부터 eUICCInfo를 수신할 수 있다. 상기 eUICCInfo는 추후 855 단계에서 이용될 수 있다. 만약 단말(110)이 이미 상기 eUICCInfo를 가지고 있는 경우, 본 850 단계 및 853 단계는 생략될 수 있다. 단말(110)은 본 단계들을 상기 810 단계 및 813 단계 또는 840 단계 및 843 단계보다 먼저 수행할 수도 있다. 본 단계에 대하여는 상기 도 6의 615 단계 및 616 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
만약 단말(110)이 적어도 하나의 PendingEvent를 포함하는 EventIDResponse 메시지를 수신하는 경우, 855 단계에서 단말(110)은 SM-SR+(130)에게 EventRequest 메시지를 전송할 수 있다.
이때, EventRequest 메시지는 다음의 정보를 포함할 수 있다.
eventID EventID,
terminalInfo TerminalInfo,
eUICCInfo EUICCInfo
만약 SM-SR+(130)이 수신한 eUICCInfo.ECCParameter를 지원하지 않는 경우, SM-SR+(130)은 단말(110)에게 실패(failure) 메시지를 전송할 수 있다.
그리고 SM-SR+(130)는 857 단계에서 SRToken1을 생성할 수 있다.
이때, SRToken1은 다음의 정보를 포함할 수 있다.
cert_SR_ECDSA CERT_ECDSA,
nonce_SR NONCE_SR,
sign_SR1 SIGN_ECDSA
cert_SR_ECDSA는 상기 855 단계에서 수신한 ECC Parameter에 따를 수 있다(comply with).
sign_SR1은 SK_SR_ECDSA로 SM-SR+(130)에 의해 생성된 signature이다..
SM-SR+(130)은 NONCE_SR를 eventID와 함께 저장하고, 추후 873 단계에서 eUICC(115)의 인증(authentication)에 이용할 수 있다.
SM-SR+(130)은 859 단계에서 단말(110)에게 EventResponse 메시지를 전송할 수 있다.
상기 EventResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
eventType EventType,
srToken1 SRToken1
단말(110)은 860 단계에서 eUICC(115)에게 ES10_GetAuthDataRequest 메시지를 전송할 수 있다. 본 단계에 대하여는 상기 도 6의 639 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
eUICC(115)는 861 단계에서 srToken1을 검증할 수 있다.
이때, 검증 절차는 다음과 같을 수 있다: eUICC(115)는 PK_CI_ECDSA를 이용하여 CERT_SR_ECDSA를 검증할 수 있다. eUICC(115)는 CERT_SR_ECDSA로부터 PK_SR_ECDSA를 추출하고, PK_SR_ECDSA로 sign_SR1을 검증할 수 있다. 그리고 eUICC(115)는 PK_SR_ECDSA를 추후 이용을 위해 저장할 수 있다.
eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID이 EPRServerAccessControl에 따라 수행되는지 여부를 검증할 수 있다.
만약 eventType이 enableProfile (1), disableProfile (2), deleteProfile (3), getProfileRegistry (4), or updateProfileRegistry (5)인 경우, eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID가 프로파일의 ProfileRecord 내의 authorizedSR에 포함되는지 검증할 수 있다.
만약 eventType이 getEPR (6) 또는 updateEPR (7)인 경우, eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID이 EPR의 인증된(authorized) SR 내에 포함되는지 검증할 수 있다.
만약 eventType이 getDSInfo (8) 또는 updateDSInfo (9)인 경우, eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID이 DSInfoStatic 내의 authorizedSR에 포함되는지 검증할 수 있다.
만약 eventType이 getCIInfo (10) 또는 updateCIInfo (11)인 경우, eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID이 CIInfo 내의 authorizedSR에 포함되는지 검증할 수 있다.
만약 eventType이 getFirmwareInfo (12) 또는 updateFirmwareInfo (13)인 경우, eUICC(115)는 CERT_SR_ECDSA에 포함된 SRID이 FirmwareInfo 내의 authorizedSR에 포함되는지 검증할 수 있다.
863 단계에서 eUICC(115)는 eUICCToken을 생성할 수 있다.
이때, 상기 eUICCToken은 다음의 정보를 포함할 수 있다.
eventID EventID,
sign_eUICC SIGN_ECDSA,
nonce_eUICC NONCE_eUICC OPTIONAL 상기 eUICC signature sign_eUICC는 SK_eUICC_ECDSA로 계산될 수 있다. 본 단계에 대하여는 상기 도 6의 644 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
eUICC(115)는 865 단계에서 단말(110)에게 ES10_GetAuthDataResponse 메시지를 전송할 수 있다.
이때,ES10_GetAuthDataResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
eUICCToken EUICCToken
867 단계는 옵션 절차로, 단말(110)은 사용자에게 동의(consent)를 질의(ask)할 수 있다.
만약 사용자가 이벤트에 동의한 경우, 또는 단말(110)이 사용자의 동의 없이 진행하는 경우, 단말(110)은 869 단계에서 SM-SR+(130)에게 ES9_eUICCManagementRequest 메시지를 전송할 수 있다.
이때, ES9_eUICCManagementRequest 메시지는 다음의 정보를 포함할 수 있다.
eUICCToken EUICCToken,
certs_eUICC CERTS_eUICC
반면, 만약 사용자가 이벤트를 거절한 경우, 단말(110)은 871 단계로 진행하여 SM-SR+(130)에게 ES9_NotifyResultRequest 메시지를 전송할 수 있다. 상기 ES9_NotifyResultRequest 메시지는 '3200 User_Rejected'의 resultCode와 대응하는(corresponding) eventID를 포함할 수 있다. 이에 대해서는 상기 도 6의 670 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
873 단계에서 SM-SR+(130)은 eUICCToken을 검증할 수 있다.
이때, 검증 절차는 다음과 같을 수 있다: SM-SR+(130)는 SM-SR+(130)에 저장되어 있는 CERT_CI_ECDSA 및 단말(110)로부터 전달된 CERT_EUM_ECDSA로 CERT_eUICC_ECDSA를 검증할 수 있다.
SM-SR+(130)는 그 후 CERT_eUICC_ECDSA로부터 PK_eUICC_ECDSA를 추출하고, PK_eUICC_ECDSA로 sign_eUICC를 검증할 수 있다. 이에 대해서는 상기 도 6의 648 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
sign_eUICC를 검증하는 때에, SM-SR+(130)는 상기 857 단계에서 eventID와 함께 저장된 NONCE_SR를 이용할 수 있다.
어떠한 검증이라도 실패한 경우, SM-SR+(130)은 단말(110) 및/또는 MNO(150)에게 에러 메시지를 리턴할 수 있다.
만약 모든 검증이 성공한 경우, 이것은 SM-SR+(130)이 성공적으로(successfully) eUICC(115)를 인증(authenticated)한 것을 의미할 수 있다.
SM-SR+(130)는 875 단계에서 srToken2를 생성할 수 있다.
이때, srToken2는 다음의 정보를 포함할 수 있다.
sign_SR2 SIGN_ECDSA
상기 signature sign_SR2는 SK_SR_ECDSA로 계산될 수 있다. 이에 대해서는 상기 도 6의 655 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
그리고 SM-SR+(130)는 877 단계에서 단말(110)에게 ES9_eUICCManagementResponse 메시지를 전송할 수 있다.
이때, ES9_eUICCManagementResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode,
event Event OPTIONAL, /* conditional if eventType != downloadProfile (0) */
profileInstallPackage ProfileInstallPackage OPTIONAL, /* conditional if eventType = downloadProfile (0) */
srToken2 SRToken2
단말(110)은 그에 따라 879 단계에서 eUICC(115)에게 eUICCManagementRequest 메시지를 전송할 수 있다. 상기 eUICCManagementRequest 메시지는 이벤트에 대한 정보와 srToken2를 포함할 수 있다.
그러면, eUICC(115)는 881 단계에서 srToken2를 검증할 수 있다.
이때, 검증 절차는 다음과 같을 수 있다: eUICC(115)는 PK_SR_ECDSA로 sign_SR2를 검증할 수 있다. 이에 대해서는 상기 도 6의 658 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
sign_SR2를 검증하는 때에, eUICC(115)는 상기 861 단계 및 863 단계에서 각각 eventID와 함께 저장된 PK_SR_ECDSA NONCE_eUICC 값들을 이용할 수 있다.
만약 eventType이 'updateCIInfo (11)'이고, CIInfo 내에 포함된 새로운(new) CI certificate가 존재하면, eUICC(115)는 동일한 certificate 내의 PK_CI_ECDSA로 상기 certificate 내의 signatuer를 검증함으로써 CI certificate를 검증할 수 있다.
만약 eventType이 'updateFirmwareInfo (13)'인 경우, eUICC(115)는 FirmwareInfo 내의 sign_EUM를 검증할 수 있다.
어떠한 검증이라도 실패한 경우, eUICC(115)는 단말에게 에러 메시지를 리턴할 수 있다.
만약 모든 검증이 성공한 경우, 이것은 eUICC(115)가 성공적으로 SM-SR+(130)을 인증(authenticated)한 것을 의미한다.
일단 srToken1의 검증이 성공적으로 완료되면, eUICC(115)는 몇몇(some) 가치있고(valuable) 검증된(verified) 정보, 예를 들면 EventType에 따른 SRID, Target EID, EventID, EventType, 및 parameters 등을 가질 수 있다.
이러한 정보들로, eUICC(115)는, eUICC 정책 룰(eUICC Policy Rules)(예를 들면, server access control, subsidy lock, 등), 프로파일 정책 룰(profile policy rules), 및 다른 필수 룰들(other necessary rules)을 나타낼(refer to) 수 있다. 그리고 eUICC(115)는 상기 이벤트가 eUICC(115) 내에 설정된(configured) 모든 룰들을 충족하는지 확인할 수 있다.
만약 상기 룰들에 위배되는 것이 있는 경우, eUICC(115)는 상기 이벤트를 거절(reject)하고, 상기 거절 이유를 응답할 수 있다.
만약 상기 881 단계의 검증이 성공한 경우, eUICC(115)는 상기 이벤트로 지시된 eUICC 관리(management)를 수행할 수 있다. 그리고 eUICC(115)는 각각의 이벤트가 지시하는 eventType에 따라 eUICC 관리(management)를 수행할 수 있다.
예를 들면, eventType이 Update CIInfo일 수 있다.
이때, eUICC(115) 내의 CIInfo(certificate issuer information)은 네트워크에 의해 업데이트가 개시될 수 있다.
eUICC(115)는 자신의 CIList(certificate issuer list)를 업덴이트할 수 있다. 그리고, eUICC(115)는 만약 ES10_eUICCManagementRequest.event.eventType이 'updateCIInfo (11)'인 경우, ES10_eUICCManagementRequest.event.CIInfo에 따라서, CIInfo 내에 정의된 허용되는 SM-SR+ 정보(allowed SM-SR+ information)를 업데이트 할 수 있다. 이때, 허용되는 SM-SR+ 정보(allowed SM-SR+ information)는 eUICC(115)를 업데이트할 수 있는 서버(SM-SR+)의 정보를 포함하는 것으로, 특정 권한 있는 서버(130)만이 eUICC(115)를 업데이트 할 수 있도록 하기 위한 것이다. 그리고, eUICC(115)는 상기 허용되는 SM-SR+ 정보(allowed SM-SR+ information)를 저장하고 있다가, 수신하는 서버의 식별 정보(예를 들면 SM-SR+의 ID, 인증서 등)과 비교하여, 일치하는 경우에만 eUICC의 프로파일을 변경하도록 허용할 수 있다.
만약 SM-SR+(130)를 요청하는 SRID이 eUICC(115)의 CIInfo.authorizedSR에 포함되어 있지 않은 경우, eUICC(115)는 CIInfo를 업데이트하지 않고,'SRID_Not_Allowed'를 지시하는 정보가 포함된 에러 메시지를 리턴할 수 있다.
그 후, eUICC(115)는 885 단계에서단말(110)에게 ES10_eUICCManagementResponse 메시지를 전송할 수 있다. 이때, ES10_eUICCManagementResponse 메시지는 이벤트 결과(event result)에 대한 정보를 포함할 수 있다.
단말(110)은 SM-SR+(130)에게 887 단계에서 ES9_NotifyResultRequest를 전송하고, SM-SR+(130)는 889 단계에서 그에 대흔 응답 메시지(ES9_NotifyResultResponse)를 단말(110)에게 전송할 수 있다. 이에 대해서는 상기 도 6의 670 단계 및 671 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다.
892 단계는 옵션 절차로, 만약 entType이 'enableProfile (1)' 또는 'disableProfile (2)'인 경우, eUICC는 단말(110)에게 단말 리프레쉬(Terminal REFRESH) 메시지((UICC reset))를 전송할 수 있다.
만약 eventType이 'enableProfile (1)'이고, ES10_eUICCManagementResponse 메시지가 프로파일이 성공적으로 이용 가능하게 되었음(enabled)을 지시하는 경우, 단말(110)은 현재 네트워크에서 연결을 끊고(disconnect from the current network) 새로운 이용 가능한(enabled) 프로파일로 새로운 MNO 네트워크와 재연결(reconnect)하기 위하여 REFRESH(UICC reset) 동작(operation)을 수행할 수 있다. (단말(110)은 SM-SR+(130)에게 결과 통지(result notification)을 성공적으로 전송한 후에, eUICC(115)로부터 REFRESH proactive command를 수신하는 과정 없이, 스스로 REFRESH operation을 수행할 수 있다. 따라서 eUICC(115)는 프로파일을 enabling한 후에 REFRESH command를 단말(110)에게 전송하지 않을 수 있다.)
SM-SR+(130)는 890 단계에서 MNO(150)에게 ES4_NotifyResultRequest 메시지를 전송할 수 있다. 상기 ES4_NotifyResultRequest 메시지는 eUICC(115)에 의해 생성된 eventResult를 포함하고, eventResult는 상기 820 단계에서 MNO(150)에 의해 초기화된(initiated) 관리 이벤트(management event)의 결과를 지시하는 것일 수 있다. eventResult와 함께 전송되는 EUM certificate, CERT_EUM_ECDSA는 MNO(150)에의해 저장된 CI certificate까지 연결된(chain up to) certificate로 eUICC signatre를 검증하는 경우에 MNO(150)에 의해 사용될 수 있다. ES4_NotifyResultRequest 메시지는 상기 도 6의 670 단계 및 683 단계에서 상술하였으므로, 그 구체적인 설명은 생략하기로 한다 .
그 후 MNO(150)는 891 단계에서 다음 TLV를 응답할 수 있다. 만약 MNO(150)가 eventResult 내의 eventID를 알지 못하는 경우, MNO(150)는 SM-SR+(130)에게 resultCode를 포함하는 실패 메시지를 전송할 수 있다.
한편, MNO(150)가 SM-SR+에게 전송하는 응답 메시지인 ES4_NotifyResultResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode
만약 단말(110)로부터 전송된 ES9_NotifyResultRequest 메시지가 이벤트의 성공적인 완료(successful completion of the event)를 지시하는 경우, SM-SR+(130)는 SM-DS(140)에게 EventID를 포함하는 ES12_DeleteEventRequest 메시지를 전송할 수 있다. 그러면 SM-DS(140)는 상기 830 단계에서 저장한 EventID 및 그에 연관된 파라미터를 자신의 데이터 베이스에서 삭제할 수 있다.
이때, ES12_DeleteEventRequest 메시지는 다음의 정보를 포함할 수 있다.
eventID EventID
그 후, SM-DS(140)는 895 단계에서 다음의 TLV 응답을 할 수 있다. 만약 SM-DS(140)가 ES12_DeleteEventRequest 메시지 내에 포함된 eventID를 알지 못하는 경우, SM-DS(140)는 SM-SR+(130)에게 resultCode를 포함하는 실패 메시지를 전송할 수 있다.
한편, SM-DS(140)가 SM-SR+(130)에게 전송하는 응답 메시지인 ES12_DeleteEventResponse 메시지는 다음의 정보를 포함할 수 있다.
resultCode ResultCode
도 9는 본 발명의 일 실시 예에 따른 단말의 블록 구성도의 일 예를 도시한 도면이다.
도 9를 참고하면, 본 발명의 일 실시 예에 따른 단말(110)은 송수신부(transceiver)(920) 및 단말(110)의 전반적인 동작을 제어하는 제어부(910)를 포함할 수 있다. 또한, 상기 단말(110)은 eUICC(115)를 더 포함할 수 있다. 한편, eUICC(115)는 도시된 것과 같이 제어부(910)에 포함되어 구성될 수도 있고, 제어부(910)와는 별도의 구성으로 구성될 수도 있다. 또한, eUICC(115)는 단말(110)과 별개의 네트워크 엔티티로 구성될 수도 있다.
상기 단말(110)의 제어부(910)는 상술한 실시예들 중 어느 하나의 동작을 수행하도록 단말(110)을 제어한다. 예를 들면, 단말(110)의 제어부(910)는, 프로파일 제공 서버(120)에게 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 전송하고, 상기 프로파일 제공 서버(120)로부터 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 제1 수정된 암호 코드가 포함된 제2 메시지를 수신하고, 상기 제1 수정된 암호 코드의 인증이 성공한 경우, 제2 수정된 암호 코드를 생성하고, 상기 프로파일 제공 서버(120)에게 상기 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 전송하고, 상기 프로파일 제공 서버(120)로부터 상기 프로파일에 대한 정보가 포함된 제4 메시지를 수신하도록 제어할 수 있다.
또한, 단말(110)의 송수신부(920)는 상술한 실시예들 중 어느 하나의 동작에 따라 신호를 송수신할 수 있다. 예를 들면, 단말(110)의 송수신부(920)는, 프로파일 제공 서버(120)에게 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 전송할 수 있다. 그리고 송수신부(920)는 상기 프로파일 제공 서버(120)로부터 상기 프로파일에 대한 정보가 포함된 제4 메시지를 수신할 수 있다.
도 10은 본 발명의 일 실시 예에 따른 SM-DP+의 블록 구성도의 일 예를 도시한 도면이다.
도 10을 참고하면, 본 발명의 일 실시 예에 따른 SM-DP+(120)는 송수신부(transceiver)(1020) 및 SM-DP+(120)의 전반적인 동작을 제어하는 제어부(1010)를 포함할 수 있다.
상기 SM-DP+(120)의 제어부(1010)는 상술한 실시예들 중 어느 하나의 동작을 수행하도록 SM-DP+(120)를 제어한다. 예를 들면, SM-DP+(120)의 제어부(1010)는, 단말(110)로부터 수신하고자 하는 프로파일에 대한 정보를 포함하는 제1 메시지를 수신하고, 상기 단말(110)이 상기 프로파일 제공 서버를 인증하도록 하기 위한 제1 수정된 암호 코드를 생성하고, 상기 단말(110)에게 사용자의 암호 코드 입력이 필요한지 여부를 나타내는 정보, 및 상기 제1 수정된 암호 코드가 포함된 제2 메시지를 전송하고, 상기 단말(110)로부터 제2 수정된 암호 코드 및 프로파일의 다운로드를 요청하는 정보가 포함된 제3 메시지를 수신하고, 상기 제2 수정된 암호 코드의 인증이 성공한 경우, 상기 단말(110)에게 상기 프로파일에 대한 정보가 포함된 제4 메시지를 전송하도록 제어할 수 있다.
또한, SM-DP+(120)의 송수신부(1020)는 상술한 실시예들 중 어느 하나의 동작에 따라 신호를 송수신할 수 있다. 예를 들면, SM-DP+(120)의 송수신부(1020)는, 단말(110)로부터 단말(110)이 수신하고자 하는 프로파일에 대한 정보가 포함된 메시지를 수신하고, 상기 단말(110)에게 프로파일을 제공할 수 있다.
도 11은 본 발명의 일 실시 예에 따른 SM-SR+의 블록 구성도의 일 예를 도시한 도면이다.
도 11을 참고하면, 본 발명의 일 실시 예에 따른 SM-SR+(130)는 송수신부(transceiver)(1120) 및 SM-SR+(130)의 전반적인 동작을 제어하는 제어부(1110)를 포함할 수 있다.
상기 SM-SR+(130)의 제어부(1110)는 상술한 실시예들 중 어느 하나의 동작을 수행하도록 SM-SR+(130)를 제어한다. 예를 들면, SM-SR+(130)의 제어부(1110)는, SM-DS(140)에게 프로파일 다운로드 요청 또는 프로파일 관리 요청을 지시하는 정보가 포함된 메시지를 전송하도록 제어할 수 있다.
또한, SM-SR+(130)의 송수신부(1120)는 상술한 실시예들 중 어느 하나의 동작에 따라 신호를 송수신할 수 있다. 예를 들면, SM-SR+(130)의 송수신부(1120)는, SM-DS(140)에게 프로파일 다운로드 요청 또는 프로파일 관리 요청을 지시하는 정보가 포함된 메시지를 전송할 수 있다
도 12는 본 발명의 일 실시 예에 따른 SM-DS의 블록 구성도의 일 예를 도시한 도면이다.
도 12을 참고하면, 본 발명의 일 실시 예에 따른 SM-DS(140)는 송수신부(transceiver)(1220) 및 SM-DS(140)의 전반적인 동작을 제어하는 제어부(1210)를 포함할 수 있다.
상기 SM-DS(140)의 제어부(1210)는 상술한 실시예들 중 어느 하나의 동작을 수행하도록 SM-DS(140)를 제어한다. 예를 들면, SM-DS(140)의 제어부(1210)는, SM-SR+(130)로부터 프로파일 다운로드 요청 또는 프로파일 관리 요청을 지시하는 정보가 포함된 메시지를 수신하도록 제어할 수 있다.
또한, SM-DS(140)의 송수신부(1220)는 상술한 실시예들 중 어느 하나의 동작에 따라 신호를 송수신할 수 있다. 예를 들면, SM-DS(140)의 송수신부(1220)는, SM-SR+(130)로부터 프로파일 다운로드 요청 또는 프로파일 관리 요청을 지시하는 정보가 포함된 메시지를 수신할 수 있다.
본 명세서와 도면에 개시된 실시 예는 기술 내용을 쉽게 설명하고, 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예들 이외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
한편, 본 명세서와 도면에는 본 발명의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
Claims (20)
- 단말에 의해 수행되는 방법에 있어서,
프로파일 제공 서버를 인증하기 위한 제1 challenge 값을 포함하는 제1 메시지를 상기 프로파일 제공 서버에게 전송하는 단계;
상기 제1 메시지의 응답으로, 제1 데이터 및 상기 제1 데이터에 대해 계산된 제1 서명(signature) 값을 포함하는 제2 메시지를 상기 프로파일 제공 서버로부터 수신하는 단계로, 상기 제1 데이터는 상기 제1 challenge 값 및 상기 단말과 연관된 인증을 위한 제2 challenge 값을 포함하는, 상기 제2 메시지를 수신하는 단계;
상기 제1 서명 값이 검증된 후에 생성되는 제2 데이터 및 상기 제2 데이터에 대해 계산된 제2 서명 값을 포함하는 제3 메시지를 상기 프로파일 제공 서버에게 전송하는 단계로, 상기 제2 데이터는 상기 제2 challenge 값 및 프로파일 매핑 정보를 포함하는, 상기 제3 메시지를 전송하는 단계;
프로파일과 연관된 암호화되지 않은 정보 및 상기 프로파일을 위한 인증(confirmation) 코드(code)가 필요한지 여부를 지시하는 정보가 포함된 제4 메시지를, 상기 제3 메시지의 응답으로, 상기 프로파일 제공 서버로부터 수신하는 단계;
상기 정보가 상기 인증 코드가 필요하다고 지시하는 경우, 인증 코드를 사용자 인터페이스를 통해 수신하는 단계;
프로파일 데이터를 요청하기 위한, 상기 인증 코드에 기반하여 계산된 해쉬 연산된(hashed) 인증 코드를 포함하는 제5 메시지를 상기 프로파일 제공 서버에게 전송하는 단계; 및
상기 제5 메시지의 응답으로, 암호화된 프로파일 데이터를 포함하는 제6 메시지를 상기 프로파일 제공 서버로부터 수신하는 단계를 포함하는 방법. - 제1 항에 있어서, 상기 제5 메시지는 제3 데이터 및 상기 제3 데이터에 대해 계산된 제3 서명 값을 포함하고,
상기 제3 데이터는 상기 해쉬 연산된 인증 코드를 포함하는 것을 특징으로 하는 방법. - 제1 항에 있어서, 상기 제4 메시지를 수신하는 단계는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보, 제4 데이터, 및 상기 제4 데이터 및 상기 제2 서명 값에 대해 계산된 제4 서명 값을 포함하는 상기 제4 메시지를 상기 프로파일 제공 서버로부터 수신하는 단계를 포함하고,
상기 제4 데이터는 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 상기 정보를 포함하는 것을 특징으로 하는 방법. - 제1 항에 있어서, 상기 인증 코드를 수신하는 단계는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보에 포함된 프로파일 정보 및 상기 인증 코드의 입력을 사용자에게 요청하는 정보를 표시부에 표시하는(display) 단계를 포함하는 것을 특징으로 하는 방법. - 제1 항에 있어서,
사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 정보를 상기 사용자 인터페이스를 통해 수신하는 단계; 및
상기 사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 상기 정보를 상기 프로파일 제공 서버에게 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법. - 프로파일 제공 서버에 의해 수행되는 방법에 있어서,
상기 프로파일 제공 서버를 인증하기 위한 제1 challenge 값을 포함하는 제1 메시지를 단말로부터 수신하는 단계;
상기 제1 challenge 값 및 상기 단말과 연관된 인증을 위한 제2 challenge 값을 포함하는 제1 데이터를 생성하고, 상기 제1 데이터에 대해 제1 서명(signature) 값을 계산하는 단계;
상기 제1 메시지의 응답으로, 상기 제1 데이터 및 상기 제1 서명 값을 포함하는 제2 메시지를 상기 단말에게 전송하는 단계;
제2 데이터 및 상기 제2 데이터에 대해 계산된 제2 서명 값을 포함하는 제3 메시지를 상기 단말로부터 수신하는 단계로, 상기 제2 데이터는 상기 제2 challenge 값 및 프로파일 매핑 정보를 포함하는, 상기 제3 메시지를 수신하는 단계;
상기 제2 서명 값을 검증하는 단계;
상기 프로파일 매핑 정보에 의해 검증된 프로파일을 위한 인증(confirmation) 코드(code)가 필요한지 여부를 결정하는 단계;
상기 프로파일과 연관된 암호화되지 않은 정보 및 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 정보가 포함된 제4 메시지를, 상기 제3 메시지의 응답으로, 상기 단말에게 전송하는 단계;
상기 정보가 상기 인증 코드가 필요하다고 지시하는 경우, 프로파일 데이터를 요청하기 위한, 상기 인증 코드에 기반하여 계산된 해쉬 연산된(hashed) 인증 코드를 포함하는 제5 메시지를 상기 단말로부터 수신하는 단계; 및
상기 제5 메시지의 응답으로, 암호화된 프로파일 데이터를 포함하는 제6 메시지를 상기 단말에게 전송하는 단계를 포함하는 방법. - 제6 항에 있어서, 상기 제5 메시지를 수신하는 단계는,
제3 데이터 및 상기 제3 데이터에 대해 계산된 제3 서명 값을 포함하는 제5 메시지를 상기 단말로부터 수신하는 단계를 포함하고,
상기 제3 데이터는 상기 해쉬 연산된 인증 코드를 포함하는 것을 특징으로 하는 방법. - 제6 항에 있어서, 상기 제5 메시지를 수신하는 단계는,
상기 해쉬 연산된 인증 코드를 포함하는 상기 제5 메시지를 상기 단말로부터 수신하는 단계;
저장된 해쉬 연산된 인증 코드에 기반하여 기대되는(expected) 해쉬 값을 계산하는 단계;
상기 수신된 해쉬 연산된 인증 코드가 상기 기대되는 해쉬 값과 매칭되는지 여부를 검증하는 단계; 및
상기 수신된 해쉬 연산된 인증 코드가 상기 기대되는 해쉬 값과 매칭되는 경우, 상기 암호화된 프로파일 데이터를 포함하는 상기 제6 메시지를 생성하는 단계를 포함하는 것을 특징으로 하는 방법. - 제6 항에 있어서, 상기 제4 메시지를 전송하는 단계는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보, 제4 데이터, 및 상기 제4 데이터 및 상기 제2 서명 값에 대해 계산된 제4 서명 값을 포함하는 상기 제4 메시지를 상기 단말에게 전송하는 단계를 포함하고,
상기 제4 데이터는 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 상기 정보를 포함하는 것을 특징으로 하는 방법. - 제6 항에 있어서,
사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 정보를 상기 단말로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법. - 단말에 있어서,
송수신부; 및
프로파일 제공 서버를 인증하기 위한 제1 challenge 값을 포함하는 제1 메시지를 상기 프로파일 제공 서버에게 전송하고, 상기 제1 메시지의 응답으로, 제1 데이터 및 상기 제1 데이터에 대해 계산된 제1 서명(signature) 값을 포함하는 제2 메시지를 상기 프로파일 제공 서버로부터 수신하고, 상기 제1 데이터는 상기 제1 challenge 값 및 상기 단말과 연관된 인증을 위한 제2 challenge 값을 포함하고, 상기 제1 서명 값이 검증된 후에 생성되는 제2 데이터 및 상기 제2 데이터에 대해 계산된 제2 서명 값을 포함하는 제3 메시지를 상기 프로파일 제공 서버에게 전송하고, 상기 제2 데이터는 상기 제2 challenge 값 및 프로파일 매핑 정보를 포함하고, 프로파일과 연관된 암호화되지 않은 정보 및 상기 프로파일을 위한 인증(confirmation) 코드(code)가 필요한지 여부를 지시하는 정보가 포함된 제4 메시지를, 상기 제3 메시지의 응답으로, 상기 프로파일 제공 서버로부터 수신하고, 상기 정보가 상기 인증 코드가 필요하다고 지시하는 경우, 인증 코드를 사용자 인터페이스를 통해 수신하고, 프로파일 데이터를 요청하기 위한, 상기 인증 코드에 기반하여 계산된 해쉬 연산된(hashed) 인증 코드를 포함하는 제5 메시지를 상기 프로파일 제공 서버에게 전송하고, 상기 제5 메시지의 응답으로, 암호화된 프로파일 데이터를 포함하는 제6 메시지를 상기 프로파일 제공 서버로부터 수신하는 제어부를 포함하는 단말. - 제11 항에 있어서, 상기 제5 메시지는 제3 데이터 및 상기 제3 데이터에 대해 계산된 제3 서명 값을 포함하고,
상기 제3 데이터는 상기 해쉬 연산된 인증 코드를 포함하는 것을 특징으로 하는 단말. - 제11 항에 있어서, 상기 제어부는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보, 제4 데이터, 및 상기 제4 데이터 및 상기 제2 서명 값에 대해 계산된 제4 서명 값을 포함하는 상기 제4 메시지를 상기 프로파일 제공 서버로부터 수신하고,
상기 제4 데이터는 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 상기 정보를 포함하는 것을 특징으로 하는 단말. - 제11 항에 있어서, 상기 제어부는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보에 포함된 프로파일 정보 및 상기 인증 코드의 입력을 사용자에게 요청하는 정보를 표시부에 표시하는(display) 것을 특징으로 하는 단말. - 제11 항에 있어서, 상기 제어부는,
사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 정보를 상기 사용자 인터페이스를 통해 수신하고, 상기 사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 상기 정보를 상기 프로파일 제공 서버에게 전송하는 것을 특징으로 하는 단말. - 프로파일 제공 서버에 있어서,
송수신부; 및
상기 프로파일 제공 서버를 인증하기 위한 제1 challenge 값을 포함하는 제1 메시지를 단말로부터 수신하고, 상기 제1 challenge 값 및 상기 단말과 연관된 인증을 위한 제2 challenge 값을 포함하는 제1 데이터를 생성하고, 상기 제1 데이터에 대해 제1 서명(signature) 값을 계산하고, 상기 제1 메시지의 응답으로, 상기 제1 데이터 및 상기 제1 서명 값을 포함하는 제2 메시지를 상기 단말에게 전송하고, 제2 데이터 및 상기 제2 데이터에 대해 계산된 제2 서명 값을 포함하는 제3 메시지를 상기 단말로부터 수신하고, 상기 제2 데이터는 상기 제2 challenge 값 및 프로파일 매핑 정보를 포함하고, 상기 제2 서명 값을 검증하고, 상기 프로파일 매핑 정보에 의해 검증된 프로파일을 위한 인증(confirmation) 코드(code)가 필요한지 여부를 결정하고, 상기 프로파일과 연관된 암호화되지 않은 정보 및 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 정보가 포함된 제4 메시지를, 상기 제3 메시지의 응답으로, 상기 단말에게 전송하고, 상기 정보가 상기 인증 코드가 필요하다고 지시하는 경우, 프로파일 데이터를 요청하기 위한, 상기 인증 코드에 기반하여 계산된 해쉬 연산된(hashed) 인증 코드를 포함하는 제5 메시지를 상기 단말로부터 수신하고, 상기 제5 메시지의 응답으로, 암호화된 프로파일 데이터를 포함하는 제6 메시지를 상기 단말에게 전송하는 제어부를 포함하는 프로파일 제공 서버. - 제16 항에 있어서, 상기 제어부는,
제3 데이터 및 상기 제3 데이터에 대해 계산된 제3 서명 값을 포함하는 제5 메시지를 상기 단말로부터 수신하고,
상기 제3 데이터는 상기 해쉬 연산된 인증 코드를 포함하는 것을 특징으로 하는 프로파일 제공 서버. - 제16 항에 있어서, 상기 제어부는,
상기 해쉬 연산된 인증 코드를 포함하는 상기 제5 메시지를 상기 단말로부터 수신하고, 저장된 해쉬 연산된 인증 코드에 기반하여 기대되는(expected) 해쉬 값을 계산하고, 상기 수신된 해쉬 연산된 인증 코드가 상기 기대되는 해쉬 값과 매칭되는지 여부를 검증하고, 상기 수신된 해쉬 연산된 인증 코드가 상기 기대되는 해쉬 값과 매칭되는 경우, 상기 암호화된 프로파일 데이터를 포함하는 상기 제6 메시지를 생성하는 것을 특징으로 하는 프로파일 제공 서버. - 제16 항에 있어서, 상기 제어부는,
상기 프로파일과 연관된 상기 암호화되지 않은 정보, 제4 데이터, 및 상기 제4 데이터 및 상기 제2 서명 값에 대해 계산된 제4 서명 값을 포함하는 상기 제4 메시지를 상기 단말에게 전송하고,
상기 제4 데이터는 상기 프로파일을 위한 상기 인증 코드가 필요한지 여부를 지시하는 상기 정보를 포함하는 것을 특징으로 하는 프로파일 제공 서버. - 제16 항에 있어서, 상기 제어부는,
사용자가 상기 프로파일의 다운로드를 거절한 것을 지시하는 정보를 상기 단말로부터 수신하는 것을 특징으로 하는 프로파일 제공 서버.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201562212387P | 2015-08-31 | 2015-08-31 | |
| US62/212,387 | 2015-08-31 | ||
| PCT/KR2016/009725 WO2017039320A1 (ko) | 2015-08-31 | 2016-08-31 | 통신 시스템에서 프로파일 다운로드 방법 및 장치 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20180037220A KR20180037220A (ko) | 2018-04-11 |
| KR102623524B1 true KR102623524B1 (ko) | 2024-01-10 |
Family
ID=58104502
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020187005847A KR102623524B1 (ko) | 2015-08-31 | 2016-08-31 | 통신 시스템에서 프로파일 다운로드 방법 및 장치 |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US10368240B2 (ko) |
| EP (2) | EP3346637B1 (ko) |
| KR (1) | KR102623524B1 (ko) |
| CN (1) | CN108028758B (ko) |
| WO (1) | WO2017039320A1 (ko) |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102284954B1 (ko) * | 2015-04-08 | 2021-08-03 | 삼성전자 주식회사 | 무선 통신 시스템에서 단말에 프로파일을 다운로드 하는 방법 및 장치 |
| CN107182048B (zh) * | 2016-03-10 | 2021-06-25 | 中兴通讯股份有限公司 | 实现多个终端共享用户身份识别卡的方法和装置 |
| EP3485663B1 (en) * | 2016-07-18 | 2021-01-13 | Telefonaktiebolaget LM Ericsson (PUBL) | Remote provision of a subscriber entity |
| US10397001B2 (en) * | 2016-08-31 | 2019-08-27 | Apple Inc. | Secure mechanism for subsidy lock enforcement |
| EP3525389B1 (en) * | 2016-10-04 | 2021-02-17 | Nec Corporation | Embedded sim management system, node device, embedded sim management method, program, and information registrant device |
| US11064357B2 (en) * | 2016-10-20 | 2021-07-13 | Huawei Technologies Co., Ltd. | Method and apparatus for managing embedded universal integrated circuit card eUICC |
| CN109906623B (zh) * | 2016-10-31 | 2021-04-09 | 华为技术有限公司 | 一种简档下载方法及设备 |
| WO2018094581A1 (zh) * | 2016-11-22 | 2018-05-31 | 华为技术有限公司 | 一种签约数据集的安装方法、终端及服务器 |
| KR20180071679A (ko) * | 2016-12-20 | 2018-06-28 | 삼성전자주식회사 | 사용자 단말 장치 및 그의 제어 방법 |
| EP3565289B1 (en) * | 2017-01-13 | 2020-10-28 | Huawei Technologies Co., Ltd. | Subscription profile download method, device and server |
| FR3065140A1 (fr) * | 2017-04-07 | 2018-10-12 | Orange | Procede d'obtention d'une commande relative a un profil d'acces a un reseau |
| US11070355B2 (en) * | 2017-06-30 | 2021-07-20 | Apple Inc. | Profile installation based on privilege level |
| US11178534B2 (en) * | 2017-11-01 | 2021-11-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Management of a subscriber entity |
| CN109802826B (zh) * | 2017-11-17 | 2021-10-01 | 华为技术有限公司 | 一种事件的处理方法和终端 |
| CN107911224B (zh) * | 2017-11-28 | 2019-04-02 | 恒宝股份有限公司 | 嵌入式通用集成电路卡的续证方法和系统 |
| KR102382894B1 (ko) * | 2017-11-28 | 2022-04-05 | 삼성전자주식회사 | 통신 시스템에서 이벤트를 관리하는 방법 및 장치 |
| EP3703400B1 (en) * | 2017-12-19 | 2021-10-27 | Huawei Technologies Co., Ltd. | Profile management method and embedded universal integrated circuit card |
| CN108200568B (zh) * | 2017-12-26 | 2020-12-08 | 中国联合网络通信集团有限公司 | 移动通信电子sim卡数据处理方法及装置 |
| EP3741145B1 (en) | 2018-01-15 | 2022-11-09 | Telefonaktiebolaget LM Ericsson (publ) | Profile handling of a communications device |
| JP6541816B1 (ja) | 2018-02-23 | 2019-07-10 | Kddi株式会社 | 通信制御装置、通信設定方法、通信設定プログラム及び通信システム |
| DE102018207161B4 (de) | 2018-05-08 | 2022-05-05 | Bayerische Motoren Werke Aktiengesellschaft | Kommunikation in einem Mobilfunknetz |
| EP3592015A1 (en) | 2018-07-02 | 2020-01-08 | Soracom International, Pte. Ltd | Updating a subscriber identity module |
| WO2020032589A1 (en) * | 2018-08-07 | 2020-02-13 | Samsung Electronics Co., Ltd. | Method, apparatus, and system for authorizing remote profile management |
| KR102511365B1 (ko) * | 2018-08-24 | 2023-03-17 | 삼성전자주식회사 | 생체 정보를 인증하는 방법 및 장치 |
| WO2020056272A1 (en) * | 2018-09-14 | 2020-03-19 | Spectrum Brands, Inc. | Authentication of internet of things devices, including electronic locks |
| US10951731B2 (en) * | 2018-10-12 | 2021-03-16 | Qualcomm Incorporated | Profile switch feature in subsidy locked devices with eUICC |
| US10911945B1 (en) * | 2018-11-19 | 2021-02-02 | Sprint Spectrum L.P. | Automated eUICC service profile configuration in view of operational issue with respect to eUICC service profile |
| CN109710070A (zh) * | 2018-12-26 | 2019-05-03 | 北京字节跳动网络技术有限公司 | 信息交互方法、装置、电子设备和计算机可读存储介质 |
| US10771943B1 (en) * | 2019-02-19 | 2020-09-08 | Microsoft Technology Licensing, Llc | Privacy-enhanced method for linking an eSIM profile |
| US11422786B2 (en) | 2019-02-22 | 2022-08-23 | Samsung Electronics Co., Ltd. | Method for interoperating between bundle download process and eSIM profile download process by SSP terminal |
| CN113455025A (zh) * | 2019-02-22 | 2021-09-28 | 三星电子株式会社 | Ssp终端在捆绑包下载过程和esim配置文件下载过程之间进行互操作的方法 |
| US11172362B2 (en) * | 2019-05-09 | 2021-11-09 | Samsung Electronics Co., Ltd. | Method and apparatus for managing and verifying certificate |
| CN110267253B (zh) * | 2019-05-13 | 2022-09-27 | 中国联合网络通信集团有限公司 | eSIM管理平台、eSIM安装方法及装置 |
| CN110262813B (zh) * | 2019-06-25 | 2020-11-17 | 上海连尚网络科技有限公司 | 用于安装应用的方法和装置 |
| WO2021001034A1 (en) * | 2019-07-03 | 2021-01-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Part 2 of remote sim provisioning of a subscriber entity |
| WO2021034048A1 (ko) * | 2019-08-16 | 2021-02-25 | 삼성전자 주식회사 | 기기 간 번들 이동 방법 및 장치 |
| US10880711B1 (en) * | 2020-02-25 | 2020-12-29 | Sprint Communications Company L.P. | Electronic subscriber identity module (eSIM) management platform |
| WO2021201644A1 (en) * | 2020-04-02 | 2021-10-07 | Samsung Electronics Co., Ltd. | Method and apparatus for managing event for smart secure platform |
| US11109220B1 (en) | 2020-05-29 | 2021-08-31 | T-Mobile Usa, Inc. | Enterprise embedded subscriber identification module solutions |
| CN112702776B (zh) * | 2020-12-15 | 2023-03-21 | 锐捷网络股份有限公司 | 一种实现无线终端接入无线局域网的方法和无线接入点 |
| WO2022186606A1 (ko) * | 2021-03-04 | 2022-09-09 | 주식회사 센스톤 | 인증용 가상코드 기반의 암호 키 업데이트 제공 장치 및 방법 |
| EP4057661A1 (en) * | 2021-03-09 | 2022-09-14 | Kigen (UK) Limited | System, module, circuitry and method |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100499122B1 (ko) | 2000-03-29 | 2005-07-04 | 삼성전자주식회사 | 패스워드를 이용한 인증 시스템 및 그 방법 |
| US20080016230A1 (en) * | 2006-07-06 | 2008-01-17 | Nokia Corporation | User equipment credential system |
| US20120196569A1 (en) | 2011-01-31 | 2012-08-02 | Nokia Corporation | Subscriber Identity Module Provisioning |
| KR101330867B1 (ko) | 2012-12-27 | 2013-11-18 | 신한카드 주식회사 | 결제 디바이스에 대한 상호인증 방법 |
| US20140219448A1 (en) * | 2011-08-24 | 2014-08-07 | Deutsche Telekom Ag | Authenticating a telecommunication terminal in a telecommunication network |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5297206A (en) * | 1992-03-19 | 1994-03-22 | Orton Glenn A | Cryptographic method for communication and electronic signatures |
| CN1567294A (zh) * | 2003-06-14 | 2005-01-19 | 华为技术有限公司 | 一种对用户进行认证的方法 |
| US7600015B2 (en) * | 2004-06-28 | 2009-10-06 | Nokia Corporation | User confirmation in data downloading |
| US8146142B2 (en) * | 2004-09-03 | 2012-03-27 | Intel Corporation | Device introduction and access control framework |
| CN1811813A (zh) * | 2006-03-02 | 2006-08-02 | 韩林 | 一种双因子动态密码认证的方法及系统 |
| JP2011257954A (ja) * | 2010-06-08 | 2011-12-22 | Sony Corp | 更新管理サーバ、電子機器、更新管理システム及びその方法 |
| WO2012058896A1 (zh) * | 2010-11-04 | 2012-05-10 | 中兴通讯股份有限公司 | 单点登录方法及系统 |
| 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 |
| US10271213B2 (en) | 2011-05-06 | 2019-04-23 | Apple Inc. | Methods and apparatus for providing management capabilities for access control clients |
| KR20130006258A (ko) | 2011-07-08 | 2013-01-16 | 주식회사 케이티 | 동적 키 생성 기반의 내장 ｓｉｍ의 ｍｎｏ 변경방법 및 그를 위한 내장 ｓｉｍ과 기록매체 |
| KR101986312B1 (ko) * | 2011-11-04 | 2019-06-05 | 주식회사 케이티 | 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ |
| US20140289366A1 (en) * | 2013-03-20 | 2014-09-25 | Korea Advanced Institute Of Science And Technology | Service providing method and system for instance hosting |
| CN103259663A (zh) * | 2013-05-07 | 2013-08-21 | 南京邮电大学 | 一种云计算环境下的用户统一认证方法 |
| EP2802162A1 (en) * | 2013-05-07 | 2014-11-12 | Gemalto SA | Method for accessing a service, corresponding device and system |
| KR102138315B1 (ko) | 2013-05-30 | 2020-07-27 | 삼성전자주식회사 | 프로파일 설치를 위한 방법 및 장치 |
| CA2917453C (en) | 2013-07-05 | 2023-08-08 | Sgx As | Method and system related to authentication of users for accessing data networks |
| 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 |
| KR102416623B1 (ko) * | 2014-11-17 | 2022-07-04 | 삼성전자 주식회사 | 통신 시스템에서 프로파일 설치 방법 및 장치 |
-
2016
- 2016-08-31 US US15/253,803 patent/US10368240B2/en active Active
- 2016-08-31 WO PCT/KR2016/009725 patent/WO2017039320A1/ko unknown
- 2016-08-31 CN CN201680052315.8A patent/CN108028758B/zh active Active
- 2016-08-31 EP EP16842286.3A patent/EP3346637B1/en active Active
- 2016-08-31 EP EP19204571.4A patent/EP3618478B1/en active Active
- 2016-08-31 KR KR1020187005847A patent/KR102623524B1/ko active IP Right Grant
-
2019
- 2019-07-29 US US16/525,327 patent/US11039311B2/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100499122B1 (ko) | 2000-03-29 | 2005-07-04 | 삼성전자주식회사 | 패스워드를 이용한 인증 시스템 및 그 방법 |
| US20080016230A1 (en) * | 2006-07-06 | 2008-01-17 | Nokia Corporation | User equipment credential system |
| US20120196569A1 (en) | 2011-01-31 | 2012-08-02 | Nokia Corporation | Subscriber Identity Module Provisioning |
| US20140219448A1 (en) * | 2011-08-24 | 2014-08-07 | Deutsche Telekom Ag | Authenticating a telecommunication terminal in a telecommunication network |
| KR101330867B1 (ko) | 2012-12-27 | 2013-11-18 | 신한카드 주식회사 | 결제 디바이스에 대한 상호인증 방법 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3346637B1 (en) | 2019-10-23 |
| WO2017039320A1 (ko) | 2017-03-09 |
| EP3618478B1 (en) | 2021-08-11 |
| CN108028758A (zh) | 2018-05-11 |
| US20170064552A1 (en) | 2017-03-02 |
| EP3346637A4 (en) | 2018-09-05 |
| KR20180037220A (ko) | 2018-04-11 |
| EP3346637A1 (en) | 2018-07-11 |
| US11039311B2 (en) | 2021-06-15 |
| US20190357046A1 (en) | 2019-11-21 |
| US10368240B2 (en) | 2019-07-30 |
| EP3618478A1 (en) | 2020-03-04 |
| CN108028758B (zh) | 2021-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102623524B1 (ko) | 통신 시스템에서 프로파일 다운로드 방법 및 장치 | |
| US11146568B2 (en) | Method and apparatus for providing profile | |
| KR102558361B1 (ko) | 통신 시스템에서 프로파일을 관리하는 기법 | |
| CN110870281B (zh) | 由esim终端和服务器讨论数字证书的方法和装置 | |
| US11496883B2 (en) | Apparatus and method for access control on eSIM | |
| US20200186992A1 (en) | Technique for Remote SIM Provisioning | |
| KR20160122061A (ko) | 프로파일 다운로드 및 설치 장치 | |
| CN110024425B (zh) | 用于安装和管理esim配置文件的装置和方法 | |
| KR102546972B1 (ko) | 프로파일 원격관리 예외 처리 방법 및 장치 | |
| CN113785532A (zh) | 用于管理和验证证书的方法和装置 | |
| KR20200099836A (ko) | eUICC 프로파일 설치 권한을 관리하는 방법 및 장치 | |
| KR20200016784A (ko) | 프로파일 원격관리 권한 설정 방법, 장치 및 시스템 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right |