CN108028758B - Method and apparatus for downloading profiles in a communication system - Google Patents

Method and apparatus for downloading profiles in a communication system Download PDF

Info

Publication number
CN108028758B
CN108028758B CN201680052315.8A CN201680052315A CN108028758B CN 108028758 B CN108028758 B CN 108028758B CN 201680052315 A CN201680052315 A CN 201680052315A CN 108028758 B CN108028758 B CN 108028758B
Authority
CN
China
Prior art keywords
profile
message
terminal
information
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201680052315.8A
Other languages
Chinese (zh)
Other versions
CN108028758A (en
Inventor
朴钟汉
李德基
李慧远
李祥洙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of CN108028758A publication Critical patent/CN108028758A/en
Application granted granted Critical
Publication of CN108028758B publication Critical patent/CN108028758B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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

Landscapes

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

Abstract

The present invention relates to a method and apparatus for making a communication connection by downloading and installing a communication service in a terminal in a communication system, and according to an embodiment of the present invention, a communication method of a terminal may include the steps of: transmitting a first message including information on a profile to be received to a profile providing server; receiving a second message from the profile providing server, the second message including the first modified passcode and information indicating whether entry of the passcode by the user is required; generating a second modified passcode if the authentication of the first modified passcode is successful; transmitting a third message including the second modified passcode and information for requesting download of the profile to the profile providing server; and receiving a fourth message from the profile providing server, the fourth message including information about the profile.

Description

Method and apparatus for downloading profiles in a communication system
Technical Field
The present invention relates to a communication system, and in particular, to a profile (profile) download method and apparatus of a terminal, so that the terminal downloads and installs a profile in real time in the communication system.
Background
Since commercialization of 4G communication systems, development emphasis has been focused on 5 th generation (5G) or first 5G communication systems in order to meet the increasing demand for wireless data communication volume. For this reason, the 5G or first 5G communication system is referred to as a super 4G network communication system or a Long Term Evolution (LTE) system. In order to achieve a high data rate, it is being considered to implement a 5G communication system on a millimeter Wave (mm Wave) frequency band (e.g., 60GHz band). To mitigate propagation loss and increase propagation distance, the 5G communication system may consider various techniques such as beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and large antenna. Also, in order to improve the throughput of the 5G communication system, various technologies, such as small cell (small cell), advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, device-to-device communication (D2D), wireless backhaul, mobile network (moving network), cooperative communication, coordinated multipoint (CoMP), and interference cancellation, are being studied. In addition, ongoing research includes the use of hybrid FSK as Advanced Coding Modulation (ACM) with QAM modulation and Sliding Window Superposition Coding (SWSC), filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and Sparse Code Multiple Access (SCMA).
Meanwhile, the Internet (Internet) is evolving from a human-centric communication network, in which information is generated and consumed by humans, to the Internet of Things (IoT), in which distributed Things or components exchange and process information. The combination of cloud server-based big data processing technologies and IoT leads to a ubiquitous interconnection technology. In order to secure sensing technologies, wired/wireless communication and network infrastructure, service interface technologies, and security technologies required to implement IoT, recent research has focused on sensor networks, machine-to-machine (M2M), and Machine Type Communication (MTC) technologies. In an IoT environment, intelligent Internet Technology (IT) may be provided that is capable of collecting and analyzing data generated from connected things to add new value to people's lives. Through the convergence of legacy (legacy) Information Technology (IT) and various industries, IoT may be applied to various fields such as smart homes, smart buildings, smart cities, smart cars or networked cars, smart grids, healthcare, smart appliances, and smart medical services.
Accordingly, various attempts are made to apply IoT to 5G communication systems. For example, sensor networks, machine-to-machine (M2M), and Machine Type Communication (MTC) technologies are implemented by 5G communication technologies such as beamforming, MIMO, and array antennas. The above application of cloud RAN as a big data processing technology is a converged example between 5G and IoT technologies.
Meanwhile, a Universal Integrated Circuit Card (UICC) is a smart card used in a mobile terminal. The UICC may include an access control module for accessing the mobile communications carrier network. Examples of access control modules include a Subscriber Identity Module (SIM), a universal SIM (usim), and an Internet Protocol (IP) multimedia services identity module (ISIM). The UICC containing the USIM is called a USIM card. Likewise, the UICC containing the SIM is called a SIM card. In the following description, the term "SIM card" is used in the sense of covering UICC cards, USIM cards and ISIMs-containing UICCs. That is, the proposed techniques may be applicable to all SIM, USIM, ISIM, and other types of UICCs.
The SIM card stores mobile communication subscriber information, which is used for subscriber authentication and traffic security key generation for accessing a mobile communication network, for securing mobile communication.
Generally, the SIM card is manufactured in a carrier-specific manner according to the requirements of a mobile communication carrier. Accordingly, the SIM card is delivered in a state including authentication information (e.g., USIM application, IMSI, K value, and OPc value) for accessing the network of the corresponding operator. The mobile communication carrier delivers the SIM card supplied by the manufacturer to the subscriber. Thereafter, The mobile communications operator can manage The information in such a way that applications are installed, updated and deleted in The UICC using Over The Air (OTA) technology. The subscriber can insert the UICC into the subscriber's mobile communication terminal for using the network and application services of the corresponding mobile communication operator; and the UICC can enable the subscriber to use the authentication information, the contact information and the phonebook stored in the UICC even when the subscriber replaces an old mobile communication terminal with a new mobile communication terminal.
However, such a SIM card has an inconvenience in that a mobile communication terminal user cannot use services of other mobile communication carriers. This means that in order to use the service provided by a specific mobile communication carrier, a user must have a SIM card supplied by the corresponding mobile communication carrier. For example, in order for a user who travels outbound to use a service provided by a local mobile communication carrier, the user must purchase a local SIM card. Although this inconvenience may be alleviated by subscribing to roaming services, roaming services are limited due to expensive roaming service fees, even without roaming agreements between network operators.
The above problem can be solved if the SIM can be downloaded and installed in the UICC. In this case, the user can download a SIM corresponding to a mobile communication service in which the user is interested to the UICC at any time. A plurality of download SIMs may be installed in the UICC and one of them is selectively used. The UICC may be fixed or removable. In particular, the UICC fixed in the terminal is called an embedded UICC (eUICC), and the eUICC may be configured to remotely download a plurality of SIMs for selective use of the plurality of SIMs. In the following description, a UICC capable of installing multiple SIMs downloaded remotely is generally referred to as an eUICC. That is, all types of UICCs that can install a remotely downloaded SIM, which are fixed to or detachable from a terminal, are generally referred to as euiccs. Also, the downloaded SIM information is called a profile or eUICC profile.
Disclosure of Invention
Technical problem
The present invention is directed to a communication channel establishment method and apparatus for a terminal using a communication service in a communication system. Also, the present invention is directed to a real-time profile downloading method and apparatus for a terminal that establishes a communication channel in a communication system. Also, the present invention is directed to a method and apparatus for providing a profile for a terminal in a communication system.
Furthermore, the present invention aims to provide a method for preventing illegal profile downloads by an illegal Mobile Network Operator (MNO).
Also, the present invention is directed to providing a root certificate information updating method for allowing a terminal to authenticate a service for downloading a profile.
Also, the present invention is directed to providing a method for a profile server to authenticate a terminal that queries (inquires) profile information to a profile information transmission server.
Furthermore, the present invention is directed to providing a method of enhancing security of private information of a terminal in such a manner that, when the terminal queries information to a profile information transmission server, the profile information transmission server processes the query even if the profile information transmission server does not have the terminal information.
Also, the present invention is directed to providing a method for determining encryption parameters for authentication and encryption when a terminal downloads a profile from a profile providing server or a profile management server.
The objects of the present invention are not limited to the above, and other objects not described herein will be clearly understood by those skilled in the art from the following description.
Solution scheme
According to an aspect of the present invention, a communication method of a terminal is provided. The communication method comprises the following steps: transmitting a first message including information on a profile to be received from a profile providing server; receiving a second message including information indicating whether an encryption code (encryption code) input is required and a first modified encryption code (modified encryption code); generating a second modified encryption code when the first modified encryption code is successfully authenticated; transmitting a third message to the profile providing server, the third message including the second modified encryption code and information requesting the profile download; and receiving a fourth message from the profile providing server, the fourth message including information about the profile.
Preferably, generating the second modified encryption code comprises: an encryption code input by a user is received, and a second modified encryption code is generated by performing a hash operation on the encryption code with a predetermined random value.
Preferably, generating the second modified encryption code comprises: receiving an encryption code input by a user, generating a third modified encryption code by performing a hash operation on the encryption code with a predetermined random value, and authenticating the first modified encryption code by comparing the first modified encryption code with the third modified encryption code.
Preferably, the second message comprises unencrypted profile information and the fourth message comprises encrypted profile information.
According to another aspect of the present invention, there is provided a communication method of a profile providing server. The communication method comprises the following steps: receiving a first message including information on a profile requested by a terminal; generating a first modified encryption code for use by the terminal in authenticating the profile providing server; transmitting a second message including information indicating whether an encryption code input is required and the first modified encryption code to the terminal; receiving a third message from the terminal, the third message including the second modified encryption code and information requesting profile download; and transmitting a fourth message including information about the profile to the terminal when the second modified encryption code is successfully authenticated.
Preferably, generating the first modified encryption code comprises: the encryption code is received from the operator and a first modified encryption code is generated by hashing the encryption code with a predetermined random value.
Preferably, the transmitting the fourth message comprises: receiving an encryption code from the operator, generating a third modified encryption code by performing a hash operation on the encryption code with a predetermined random value, and authenticating the second modified encryption code by comparing the second modified encryption code with the third modified encryption code.
According to another aspect of the present invention, a terminal is provided. The terminal includes: a transceiver for communicating with a network entity; and a control unit that controls: transmitting a first message including information about a profile to be received from a profile providing server; receiving a second message including information indicating whether an encryption code input is required and the first modified encryption code; generating a second modified encryption code when the first modified encryption code is successfully authenticated; transmitting a third message to the profile providing server, the third message including the second modified encryption code and information requesting the profile download; and receiving a fourth message including information on the profile from the profile providing server.
According to still another aspect of the present invention, there is provided a profile providing server. The profile providing server includes: a transceiver in communication with a network entity; and a control unit that controls: receiving a first message including information on a profile requested by a terminal; generating a first modified encryption code for use by the terminal in authenticating the profile providing server; transmitting a second message including information indicating whether an encryption code input is required and the first modified encryption code to the terminal; receiving a third message from the terminal, the third message including the second modified encryption code and information requesting profile download; and transmitting a fourth message including information about the profile to the terminal when the second modified encryption code is successfully authenticated.
Effects of the invention
According to an embodiment of the present invention, the communication system of the present invention is advantageous in reducing waste of the amount of resources such as profile and IMSI stored in the profile by: the download of unwanted or unencrypted profiles that will not be used is prevented in such a way that during the download and installation of a profile in a terminal, unencrypted profile information is sent before the encrypted profile is sent to the terminal for the user to determine whether to use the profile.
The communication system of the present invention is advantageous in preventing a profile from being abnormally installed and reducing waste of the amount of resources such as the profile and IMSI stored in the profile by: the downloading of unwanted profiles or unencrypted profiles that will not be used is prevented in such a way that during downloading and installing a profile in a terminal the operator asks the user for a confirmation code sent in a separate way before sending the encrypted profile to the terminal, and the encrypted profile is sent to the terminal only when the confirmation code entered by the user is authenticated.
Advantages of the present invention are not limited to the above, and other advantages not described herein will be clearly understood by those skilled in the art from the following description.
Drawings
FIG. 1 is a diagram illustrating a profile installation and management mechanism according to an embodiment of the present invention;
fig. 2 is a signal flowchart illustrating a profile download method of a terminal according to an embodiment of the present invention;
fig. 3 is a signal flowchart illustrating a profile download method of a terminal according to an embodiment of the present invention;
fig. 4 is a signal flowchart illustrating a profile download method of a terminal according to another embodiment of the present invention;
FIG. 5 is a signal flow diagram illustrating a profile download method according to another embodiment of the present invention;
FIGS. 6 a-6 c are signal flow diagrams illustrating a profile download method of the present invention according to an embodiment of the present invention;
figures 7a and 7b are signal flow diagrams illustrating a process of downloading a profile in an eUICC, according to an embodiment of the present invention;
fig. 8a and 8b are signal flow diagrams illustrating a network initialization process according to an embodiment of the present invention;
fig. 9 is a block diagram showing a configuration of a terminal according to an embodiment of the present invention;
fig. 10 is a block diagram illustrating a configuration of an SM-DP + according to an embodiment of the present invention;
FIG. 11 is a block diagram illustrating a configuration of SM-SR +, according to an embodiment of the present invention; and
fig. 12 is a block diagram illustrating a configuration of an SM-DS according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention are described in detail with reference to the accompanying drawings.
A detailed description of known functions and configurations incorporated herein may be omitted to avoid obscuring the subject matter of the present invention. This is intended to omit unnecessary description in order to make the subject matter of the present invention clear.
It will be understood that when an element is referred to as being "connected" or "coupled" to another element or layer, it can be directly connected or coupled to the other element or intervening elements may be present. It will be understood that the terms "comprises," "comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof.
Although components are depicted separately to indicate different features, this does not mean that these components are configured as separate hardware or software units. That is, these components are separately enumerated for convenience of explanation only, but at least two of these components may be implemented as a single component, or one component may be divided into a plurality of components responsible for respective functions. Embodiments of the integrated and divided components are included within the scope of the present invention without departing from the spirit thereof.
Some of the components may not be essential components for the essential functions of the present invention, but they may be optional components only for performance enhancement. The present invention may be implemented with only necessary components required to implement the subject matter of the present invention, except for optional components for performance improvement, and such a configuration having only necessary components except for the optional components may be included in the claims of the present invention.
A detailed description of known functions and configurations incorporated herein may be omitted to avoid obscuring the subject matter of the present invention. Exemplary embodiments of the present invention are described in detail with reference to the accompanying drawings. Further, the following terms are defined in consideration of functions in the present invention, and may vary according to the intention, use, and the like of a user or an operator. Therefore, the definitions should be made based on the entire contents of the present specification.
It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a non-transitory computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the non-transitory computer-readable memory produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The term "module" according to embodiments of the invention means, but is not limited to, a software or hardware component, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), which performs certain tasks. A module may advantageously be configured to reside on the addressable storage medium and configured to run on one or more processors. Thus, a module may include, by way of example, components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functionality provided for in the components and modules may be combined into fewer components and modules or further separated into additional components and modules. In addition, the components and modules may be implemented such that they run one or more CPUs in a device or secure multimedia card.
Terms used in the following description are provided to aid understanding of the present invention, and may be modified into different forms without departing from the spirit of the present invention.
First, terms used in the present invention are defined.
FIG. 1 is a diagram illustrating a profile installation and management mechanism according to an embodiment of the present invention.
In the present invention, a Universal Integrated Circuit Card (UICC)115 is a smart card formed to be attachable to a mobile communication terminal 110 and having a chip capable of storing personal information such as network access authentication information of a subscriber, a phone book, and Short Message Service (SMS) information. The UICC115 is used for subscriber authentication and traffic security key creation during access to a mobile communication network, such as a global system for mobile communications (GSM), Wideband Code Division Multiple Access (WCDMA), and Long Term Evolution (LTE) network, to secure mobile communication. The UICC115 is provided with network-specific identity applications such as a Subscriber Identity Module (SIM), a universal SIM (usim), and an internet protocol multimedia services identity module (ISIM), and the UICC115 provides higher-level security functions to support various applications such as an electronic wallet, an electronic ticket, and an electronic passport.
The UICC115 is an embedded UICC that is fixed to the terminal 110 in a chip form so as not to be attachable to the terminal 110 or detachable from the terminal 110. The eUICC115 can be downloaded in profile (profile) form via over-the-air (OTA) techniques and then installed in the terminal 110. In the present invention, the eUICC115 represents all types of UICCs capable of downloading and installing profiles. In the following description, all types of UICCs that can remotely download and install a SIM, that are fixed to the terminal 110 and that are attachable/detachable to/from the terminal 110 are referred to as euiccs. Also, the downloaded SIM information may be interchangeably referred to as an eUICC profile or profile.
The method of downloading a profile and installing the profile in the eUICC115 through the OTA technique according to an embodiment of the present invention can be applied to the case of using a UICC that is attachable/detachable to/from the terminal 110. That is, according to an embodiment of the present invention, the profile may be downloaded using OTA technology and the downloaded profile may be installed in the UICC 115.
In the following description, the term "UICC" and "SIM" are used interchangeably, and the term "eUICC" and "eSIM" are used interchangeably.
In the following description, the term "profile" may refer to a software package consisting of an application, a file system and an authentication key in the form of being in the UICC.
In the following description, the term "USIM profile (SIM profile)" may be used interchangeably with "profile" having the same meaning, or may refer to a software package containing information stored in the USIM application of a profile.
In the following description, the profile providing server 120 may be interchangeably referred to as a subscription manager data preparation (SM-DP), an SM-DP plus (SM-DP +), a card-less entity (off-card entry) of a profile domain, a profile encryption server, a profile creation server, a Profile Provider (PP), a profile provider (profile provider), and a Profile Provisioning Credential (PPC) holder.
In the following description, the profile information delivery server 140 may be interchangeably referred to as a Discovery and Push Function (DPF) and a subscription manager discovery service (SM-DS).
In the following description, the profile management server 130 may be interchangeably referred to as a subscription manager secure route (SM-SR), SM-SR plus (SM-SR +), an off-card (card) entity of the eUICC profile manager, a PMC holder, and an EUICC Manager (EM).
In the following description, the profile providing server 120 may integrate the functions of the profile management server 130. The operations of the profile providing server 120 may be performed by the profile management server 130 according to various embodiments of the present invention. Also, the operations of the profile management server or the SM-SR 130 may be performed by the profile providing server 120.
In the following description, the terminal 110 may be interchangeably referred to as a "terminal," "mobile communication terminal," "Mobile Station (MS)," User Equipment (UE), "User Terminal (UT)," wireless terminal, "" Access Terminal (AT), "subscriber unit," "Subscriber Station (SS)," wireless device, "" wireless communication device, "" wireless transmit/receive unit (WTRU), "mobile node," etc. Examples of terminal 110 may include a cellular telephone, a wireless communication enabled smart phone, a wireless communication enabled Personal Digital Assistant (PDA), a wireless modem, a wireless communication enabled portable computer, a wireless communication enabled digital camera, a wireless communication enabled gaming device, a wireless communication enabled music storage and playback appliance, a wireless internet access and browsing enabled appliance, and other units and terminals that integrate the functionality of portions of the above-described devices. Terminals may include, but are not limited to, machine-to-machine (M2M) terminals and Machine Type Communication (MTC) terminals/devices. In the following description, the terminal may be interchangeably referred to as an electronic device.
In the present invention, the electronic device may include a UICC115 in which the downloaded profile can be installed. If the UICC115 is not embedded in the electronic device, a detachable UICC may be physically connected to the electronic device. For example, the UICC115 may be designed in the form of a card for insertion into an electronic device. For example, the electronic device may be the terminal 110, and in this case, the terminal 110 may have a UICC115 for installing the downloaded profile therein. The UICC115 can be embedded in the terminal 110, and if not embedded, the UICC115 can be attached to or detached from the terminal 110 to establish or release an electrical connection. The UICC115 in which the downloaded profile can be installed can be referred to as the eUICC 115.
In the present invention, the profile identifier may be interchangeably referred to as "profile ID", "integrated circuit card ID (iccid)", "ISD-P", and "factor matching profile field (PD)". The profile ID may be a unique identifier for each profile.
In the present invention, the eUICC ID can be referred to as "EID" as a unique identifier of the eUICC115 embedded in the terminal. In the case where a provisioning profile (provisioning profile) is embedded in the eUICC115, the eUICC ID may be an identifier of the provisioning profile. According to an embodiment of the present invention, the eUICC115 is fixed to the terminal 110, and in this case, the eUICC ID may be a terminal ID. The eUICC ID can be interchangeably referred to as a particular security domain of the eUICC 115.
In the present invention, the profile container may be referred to as a profile domain. The profile container may be a security domain.
In the present invention, an Application Protocol Data Unit (APDU) may be a message for the terminal 110 to cooperate with the eUICC 115. The APDU may be a message for the PP 120 or the PM 130 to cooperate with the eUICC 115.
In the present invention, the Profile Provisioning Credentials (PPC) may be a means for mutual authentication, profile encryption, and signing between the PP 120 and the eUICC 115. The PPC may include at least one of: a symmetric key, a Rivest-Shamir-adleman (rsa) certificate to private key pair, an Elliptic Curve Cryptography (ECC) certificate to private key pair, and a root Certificate Authority (CA) to certificate chain pair. In the case where there are multiple PPs, the eUICC115 can store and use PP-specific PPCs.
In the present invention, Profile Management Credentials (PMC) may be a means for mutual authentication, transmission data encryption, and signing between the PM 130 and the eUICC 115. The PMC may include at least one of: a symmetric key, a pair of an RSA certificate and a private key, a pair of an ECC certificate and a private key, and a pair of a root CA and a certificate chain.
In the present invention, the AID may be an application identifier. This value may be used as an identifier to distinguish between applications in the eUICC 115.
In the present invention, the profile packet TLV may be interchangeably referred to as a profile TLV. The profile packet TLV may be a data set representing information constituting a profile in the form of a tag, a length, and a value (TLV).
In the present invention, AKA is an abbreviation of Authentication and Key Agreement (Authentication and Key Agreement) as an Authentication algorithm for accessing 3GPP and 3GPP 2 networks.
In the present invention, K denotes an encryption key value stored in the eUICC115 for use in the AKA authentication algorithm.
In the present invention, the OPc denotes parameters stored in the eUICC115 for use in the AKA authentication algorithm.
In the present invention, NAA is an abbreviation of Network Access Application (Network Access Application), which is an Application stored in the UICC115 for use in accessing a Network, such as USIM and ISIM. That is, the NAA is a network access module.
Meanwhile, the UICC115 may be designed to be inserted into the terminal 110. In this case, the UICC115 may be attachable/detachable to/from the terminal 110, or embedded in the terminal 110. The profile of the UICC 110 may include "access information" for use in accessing a network of a particular operator. The access information may include a K or Ki value for authentication in the network with the IMSI as the subscriber identifier.
The terminal 110 may then perform authentication with an authentication processing system (e.g., Home Location Register (HLR)) of a mobile operator or AuC using the UICC 115. The authentication procedure may be an AKA procedure. If the authentication is successful, the terminal 110 can use a mobile communication service such as a mobile phone and a mobile data service using a network of a mobile communication system.
A detailed description of known functions and configurations incorporated herein may be omitted to avoid obscuring the understanding of the subject matter of the present invention.
As described above, the eUICC115 can be implemented in the form of a UICC card or chip that is embedded in the terminal 110 or attachable/detachable to/from the terminal 110. The eUICC115 can be a UICC having one of various sizes and implemented as one of legacy form factors, such as 2FF, 3FF, 4FF, MFF1, and MFF 2. The eUICC115 can be embedded in the terminal 110 or integrated into a communication chip (e.g., a baseband modem) of the terminal 110.
The profile providing server 120 may have a function of generating a profile and encrypting the profile, and may be referred to as SM-DP +.
The profile management server 130 may be referred to as an EM or SM-SR +, and is responsible for relaying the profile received from the SM-DP +120 to a Local Profile Assistant (LPA) or management profile of the terminal 110. At this time, the SM-SR +130 may control profile download and profile management operations between the SM-DP +120 and the LPA of the terminal 110.
The profile information delivery server 140 may be referred to as an SM-DS or a DPF, and may relay the SM-SR + server address and the event identifier received from the SM-SR +130 to the LPA of the terminal 110.
According to embodiments of the invention, SM-DP +120 and SM-SR +130 may be implemented as a single server, which may be referred to as SM-DP + or subscription manager plus (SM +).
An eUICC manufacturer (EUM)160 may manufacture the eUICC115 and provide the manufactured eUICC115 to a mobile communication carrier or a terminal manufacturer. The Mobile Network Operator (MNO)150 may be a mobile communication network operator for providing mobile communication services to the terminal. The Certificate Issuer (CI)170 may authenticate the profile providing server 120, the profile management server 130, the profile information delivery server 140, and the EUM 160. According to an embodiment of the present invention, the terminal 110 may include: a transceiver for receiving an encrypted profile or an unencrypted profile from the SM-DP +120 or SM-SR + 130; a display unit for displaying the unencrypted profile information; a User Interface (UI) unit for requesting (exercising) a user to confirm receipt of the profile, performing a display and confirmation input process before receiving the encrypted profile during a profile download process; and a control unit for determining whether to continue or stop the profile download process based on the user input.
In the wireless communication system according to an embodiment of the present invention, the SM-DP +120 may generate original profile information and an encrypted profile during a profile download procedure, and transmit encrypted simple information to the control unit and the transceiver only when a normal profile download request message is received from the terminal 110 after transmitting the original (raw) profile information.
In the wireless communication system according to an embodiment of the present invention, the terminal 110 may include: a transceiver for receiving encrypted profile information and unencrypted original profile information from the SM-DP +120 or SM-SR + 130; a display unit for displaying original profile information; a control unit for determining whether to request the user to input a confirmation code based on an indicator indicating whether the confirmation code of the user is required as part of information received from the SM-DP +120 during the profile download process; and a UI unit for requesting a confirmation code from the user separately or simultaneously with displaying the original profile information, the control unit performing a hash operation on the confirmation code input by the user and a random value received from the SM-DP +120 or SM-SR +130 during the profile reception process, and controlling to transmit an operation result value to the SM-DP +120 or SM-SR +130 during the profile reception process.
In the wireless communication system according to an embodiment of the present invention, the SM-DP +120 may include: a storage unit for storing information indicating whether a confirmation code is required to download a specific profile and confirmation code information; a transceiver; and a control unit which controls the transceiver to transmit information indicating whether a confirmation code is required for downloading the specific profile to the terminal 110, compares a hash operation value received from the terminal 110 with a hash operation value calculated by the SM-DP +120 using the confirmation code stored in the SM-DP +120 and a random value received from the terminal 110 when the confirmation code is required, and controls the transceiver not to transmit the encrypted profile to the terminal 110 when the hash values do not match.
Preferred embodiments of the present invention are described below.
Fig. 2 is a signal flowchart illustrating a profile downloading method of a terminal according to an embodiment of the present invention.
Referring to fig. 2, the terminal 110 may generate server authentication information for authenticating a server at step 210. At this time, the server authentication information may be a random value, for example, a challenge value (challenge value). The challenge value may be a value generated by a control unit of the terminal 110 or the eUICC115 connected to the terminal 110, and may be referred to as an eUICC challenge value. The terminal 110 may transmit a message including information for authenticating the server to the profile providing server 120. The message may be an initial authentication request (initauthrequest) message. The profile providing server 120 may be SM-DP +. The terminal 110 can include an eUICC115 that can perform a portion of the operations of the terminal 110.
At step 215, the SM-DP +120 may generate terminal authentication information for authenticating the terminal 110. At this time, the terminal authentication information may be a random value, for example, an SM-DP + challenge value generated by the control unit of the SM-DP + 120. The SM-DP +120 may compute an SM-DP + signature for data including the eUICC challenge value received at step 210 and the SM-DP + challenge value generated by SM-DP + 120. The calculated SM-DP + signature value may be SM-DP + signature1 (signature 1). SM-DP + signature1 was calculated using the SM-DP + private key. The SM-DP +120 may send a response message to the terminal 110 that includes the SM-DP + signature1 and the SM-DP + challenge value.
The terminal 110 may verify the SM-DP + signature1 and continue the subsequent process if the verification is successful, or may not continue the subsequent process if the verification fails.
If the SM-DP +120 is successfully verified at step 220, the terminal 110 may generate an eUICC signature for the data comprising the SM-DP + challenge at step 225. The eUICC signature may be an eUICC signature 1. The eUICC signature1 may be a signature created using the private key of the eUICC 115. The terminal 110 may send a message including the eUICC signature1 and profile information to the SM-DP + 120. The message may be an authentication request message (e.g., AuthClientRequest). The profile information may include profile mapping information for use by the SM-DP +120 in identifying the profile or type of profile. At this time, the profile information may include the following profile mapping information:
-eUICC identifier or EID
-eUICC certificate
EventID (event ID)
-MatchingID (match ID)
-ActivationToken (activation token)
Notification ID (Notification ID)
At step 230, SM-DP +120 may check profile information corresponding to a particular profile or profile type from the profile mapping information.
At step 235, the SM-DP +120 may calculate a signature value (SM-DP + signature2 (signature 2)) for the data comprising the profile information checked at step 230. The SM-DP +120 may send the signature value (SM-DP + signature2) and profile information to the terminal 110. The profile information may be the original profile information that was not encrypted.
Then, the terminal 110 may display part or all of the profile information received at step 235 or information mapped to part or all of the profile information on the display unit. The mapped information may be a value pre-stored in the terminal 110 or a value received from an external server. Some or all of the profile information for use in the mapping process is as follows:
-IMSI
-information comprising MCC or MNC
-information comprising MCC and MNC
-operator name
-information forming part of the ICCID information
-operator code
At step 245, the terminal 110 may receive user input for confirmation of the profile download. That is, the terminal 110 may receive user input for confirming the profile download.
The profile download confirmation input may proceed as follows.
In a state where a "yes" item and a "no" item are displayed on a display unit using an input device (e.g., a touch panel and buttons) of a User Interface (UI), an input action is simply made at a position corresponding to the "yes" item
-entering using biometric authentication such as fingerprint authentication and iris authentication
The terminal 110 may determine at step 250 whether the user confirmed the profile download at user confirmation step 245.
If it is determined at step 250 that the user has confirmed the profile download, the terminal 110 may request the profile download from the SM-DP +120 at step 260. At this time, the terminal 110 may generate an eUICC signature value (eUICC signature2) in response to the profile download request information. The terminal 110 may transmit a message (e.g., getbackprofilepacket) including an eUICC signature value (eUICC signature2) and profile download request information to the SM-DP + 120.
At step 270, the SM-DP +120 may transmit the encrypted profile to the terminal 110 according to the profile download request information received at step 260.
The terminal 110 may then decode the encrypted profile and install the profile at step 280. The profile decoding may be performed in the eUICC115 of the terminal 110.
If it is determined at step 250 that the user does not confirm the profile download, the terminal 110 may transmit a profile download rejection report and/or a confirmation result to the SM-DP +120 at step 290. The terminal 110 may then stop the profile download process.
If a profile download rejection report is received, the SM-DP +120 may stop the profile download process at step 295. In this case, the SM-DP +120 may transmit an Acknowledgement (ACK) message to the terminal 110 in response to the profile download rejection report.
It will be apparent to those skilled in the art that the profile download procedure described above may be applied to other types of communication systems.
Fig. 3 is a signal flowchart illustrating a profile downloading method of a terminal according to an embodiment of the present invention.
Referring to fig. 3, the terminal 110 may generate server authentication information for authenticating a server at step 310. The server authentication information may be a random value, e.g., a challenge value. The challenge value may be generated by a control unit of the terminal 110 or the eUICC115 connected to the terminal 110 and may be referred to as an eUICC challenge value. The terminal 110 may transmit a message including server authentication information to the profile providing server 120. The message may be an initial authentication request message (e.g., an IniAuthRequest). The profile providing server 120 may be SM-DP +. The terminal 110 may include an eUICC115 that is responsible for a portion of the operation of the terminal 110.
At step 315, the SM-DP +120 may generate terminal authentication information for authenticating the terminal 110. The terminal authentication information may be a random value, for example, an SM-DP + challenge value that may be generated by the control unit of the SM-DP + 120. The SM-DP +120 may compute a signature value for data including the eUICC challenge value received at step 310 and the SM-DP + challenge value generated by SM-DP + 120. At this time, the SM-DP + signature value may be SM-DP + signature 1. SM-DP + signature1 may be a value calculated using the SM-DP + private key. The SM-DP +120 may send a response message to the terminal 110 that includes the SM-DP + signature1 and the SM-DP + challenge value.
The terminal 110 may verify the SM-DP + signature1 at step 320 and continue the process if the SM-DP + verification is successful or may stop the process if the SM-DP + verification fails.
If the SM-DP + verification is successful at step 320, the terminal 110 may generate an eUICC signature for the data including the SM-DP + challenge at step 325. The eUICC signature may be an eUICC signature 1. The eUICC signature1 may be a signature generated using a private key of the eUICC 115. The terminal 110 may send a message including the eUICC signature1 and profile information to the SM-DP + 120. The message may be an authentication request message (e.g., AuthClientRequest). The profile information may include profile mapping information for use by the SM-DP +120 in identifying a profile or a particular type of profile. The profile information may include the following profile mapping information:
-eUICC identifier or EID
-eUICC certificate
-EventID
-MatchingID
-ActivationToken
-NotificationID
At step 330, SM-DP +120 may check profile information corresponding to a particular profile or profile type from the profile mapping information.
The SM-DP +120 may determine whether a confirmation code input by the user is required to download the corresponding profile. If the SM-DP +120 has information indicating whether a confirmation code input of the user is required, it may check the corresponding information.
At step 335, SM-DP +120 may calculate a signature value (SM-DP + signature2) for the data comprising the profile information checked at step 330. The SM-DP +120 may transmit a signature value (SM-DP + signature2), unencrypted profile information, and information indicating whether a confirmation code input is required (required confirmation code). For example, the information indicating whether the input of the confirmation code is required may be a 1-bit signal, which is set to 0 for the case where the input of the confirmation code is not required, or to 1 for the case where the input of the confirmation code is required. The profile information may be unencrypted profile information.
At step 340, the terminal 110 may display part or all of the profile information received at step 335 or information mapped to part or all of the profile information on a display unit. The mapped information may be a pre-stored value or a value received from an external server. Some or all of the profile information for use in the mapping process may include the following information:
-IMSI
-information comprising MCC or MNC
-information comprising MCC and MNC
-operator name
-information forming part of the ICCID information
-operator code
At step 345, the terminal 110 may receive a confirmation of the user's profile download. That is, the user may make an input to the terminal 110 for confirming the profile download.
The profile download confirmation input may proceed as follows.
In a state where a "yes" item and a "no" item are displayed on a display unit using an input device (e.g., a touch panel and buttons) of a User Interface (UI), only an input action to a position corresponding to the "yes" item is made
-entering using biometric authentication such as fingerprint authentication and iris authentication
Simultaneously with or separately from the confirmation process of the user, or without the confirmation process of the user, the terminal 110 may determine whether the confirmation code is required by checking the corresponding information received from the SM-DP + 120. If information indicating whether the confirmation code input is required is received, the terminal 110 may inquire the user about the confirmation code through the UI and receive the confirmation code input. The terminal 110 may then perform a hash operation on the confirmation code entered by the user and the SM-DP + challenge information received at step 315. The terminal 110 may generate the modified confirmation code (or hashed confirmation code (hashed confirmation code)) by a hashing operation. The hash operation may be performed one or more times to hide the confirmation code. It is also possible to operate using the SM-DP + challenge value such that a unique hash result value is generated each time. The operation may be performed by one or more CPUs of the terminal 110. For example, security may be improved by having an Application Processor (AP) that is responsible for a portion of the operations and a modem or eUICC115 that is responsible for the remainder of the operations.
At step 350, the terminal 110 may determine whether the user has confirmed the profile download at step 345.
If it is determined at step 350 that the user has confirmed the profile download, the terminal 110 may request the profile download from the SM-DP +120 at step 360. At this time, the terminal 110 may generate an eUICC signature value (eUICC signature2) for the profile download request information. The terminal 110 may transmit a request message (e.g., getbackprofilepacket) including an eUICC signature value (eUICC signature2) and profile download request information to the SM-DP + 120.
The request message may include a hashed validation code.
At step 365, the SM-DP +120 may verify the hashed validation code.
The SM-DP +120 may determine whether the request message received at step 360 includes a hashed confirmation code. If the request message received at step 350 does not include a hashed acknowledgment code, then the SM-DP +120 may perform step 375.
If the request message received at step 360 includes a hashed validation code, SM-DP +120 may itself compute the hashed validation code. The SM-DP +120 may determine whether the computed hashed validation code matches the received hashed validation code.
If the two codes match, then SM-DP +120 may perform step 370.
Otherwise, if the two codes do not match, the SM-DP +120 may send a message including information indicating that the profile download failed to the terminal 110 and end the process.
At step 370, the SM-DP +120 may transmit the encrypted profile to the terminal 110 according to the profile download request information received at step 360.
The terminal 110 may then decode the encrypted profile and install the profile at step 380. The profile decoding may be performed in the eUICC115 of the terminal 110.
If it is determined at step 350 that the user does not confirm the profile download, the terminal 110 may transmit a profile download rejection report and/or a confirmation result to the SM-DP + at step 390. The terminal 110 may then end the profile download process.
If the profile download rejection report is received, the SM-DP +120 may end the profile download procedure at step 395. At this time, the SM-DP +120 may transmit an Acknowledgement (ACK) message to the terminal 110 in response to the profile download rejection report.
It will be apparent to those skilled in the art that the profile download procedure described above may be applied to other types of communication systems.
Fig. 4 is a signal flowchart illustrating a profile download method of a terminal according to another embodiment of the present invention.
Referring to fig. 4, the terminal 110 may generate server authentication information for authenticating a server at step 410. The server authentication information may be a random value, e.g., a challenge value. The challenge value may be generated by a control unit of the terminal 110 or the eUICC115 connected to the terminal 110 and may be referred to as an eUICC challenge value. The terminal 110 may transmit a message including server authentication information to the profile providing server 120. The message may be an initial authentication request message (e.g., an IniAuthRequest). The profile providing server 120 may be SM-DP +. The terminal 110 may include an eUICC115 that is responsible for a portion of the operation of the terminal 110.
At step 415, the SM-DP +120 may generate terminal authentication information for authenticating the terminal 110. The terminal authentication information may be a random value, for example, an SM-DP + challenge value that may be generated by the control unit of the SM-DP + 120. The SM-DP +120 may compute a signature value for data including the eUICC challenge value received at step 410 and the SM-DP + challenge value generated by SM-DP + 120. At this time, the SM-DP + signature value may be SM-DP + signature 1. SM-DP + signature1 may be a value calculated using the SM-DP + private key. The SM-DP +120 may send a response message to the terminal 110 that includes the SM-DP + signature1 and the SM-DP + challenge value.
The terminal 110 may verify the SM-DP + signature1 at step 420 and continue the process if the SM-DP + verification is successful or may stop the process if the SM-DP + verification fails.
If the SM-DP + verification is successful at step 420, the terminal 110 may generate an eUICC signature for the data including the SM-DP + challenge at step 425. The eUICC signature may be an eUICC signature 1. The eUICC signature1 may be a signature generated using a private key of the eUICC 115. The terminal 110 may send a message including the eUICC signature1 and profile information to the SM-DP + 120. The message may be an authentication request message (e.g., AuthClientRequest). The profile information may include profile mapping information for use by the SM-DP +120 in identifying a profile or a particular type of profile. The profile information may include the following profile mapping information:
-eUICC identifier or EID
-eUICC certificate
-EventID
-MatchingID
-ActivationToken
-NotificationID
At step 430, the SM-DP +120 may check profile information corresponding to a particular profile or profile type from the profile mapping information.
The SM-DP +120 may determine whether a confirmation code input by the user is required to download the corresponding profile. If the SM-DP +120 has information indicating whether a confirmation code input of the user is required, it may check the corresponding information.
If the user needs to input the confirmation code, the SM-DP +120 may generate a first modified confirmation code (or a first hashed confirmation code (hashed confirmation code 1)) to protect the terminal 110 from a malicious operator or server. At this time, the hashed confirmation code 1 may be calculated as follows:
hashed validation code 1 ═ hash function (validation code, random number a)
At this time, the confirmation code may be received from the operator, and the random number a may be any random value that the terminal 110 already knows or will know. For example, the nonce A may be an eUICC challenge or an SM-DP + challenge.
The hash function may be a function for performing one or more hash operations on the input factors of the confirmation code and the random number a. The hashed confirmation code 1 may be computed as follows:
hashed validation code 1 ═ SHA256 (validation code | SM-DP + challenge)
If the SM-DP +120 sends the hashed confirmation code 1 to the terminal 110, the terminal 110 may calculate the hashed confirmation code 1 based on the confirmation code input by the user at step 445. By comparing the calculated hashed validation code 1 with the received hashed validation code 1, the terminal 110 can be prevented from downloading profiles from unknown malicious operators or SM-DP + 120.
At step 435, the SM-DP +120 may calculate a signature value (SM-DP + signature2) for the data comprising the profile information obtained at step 430. The SM-DP +120 may transmit the signature value (SM-DP + signature2), the unencrypted profile information, information indicating whether a confirmation code input is required (conformationally required), and the hashed confirmation code 1 to the terminal 110. For example, the information indicating whether the input of the confirmation code is required may be a 1-bit signal, which is set to 0 for the case where the input of the confirmation code is not required, or to 1 for the case where the input of the confirmation code is required. The profile information may be unencrypted profile information.
At step 440, the terminal 110 may display part or all of the profile information received at step 435 or information mapped to part or all of the profile information on a display unit. The mapped information may be a pre-stored value or a value received from an external server. Some or all of the profile information for use in the mapping process may include the following information:
-IMSI
-information comprising MCC or MNC
-information comprising MCC and MNC
-operator name
-information forming part of the ICCID information
-operator code
At step 445, terminal 110 may receive a user confirmation of the profile download. That is, the user may make an input to the terminal 110 for confirming the profile download.
The profile download confirmation input may proceed as follows.
In a state where a "yes" item and a "no" item are displayed on a display unit using an input device (e.g., a touch panel and buttons) of a User Interface (UI), only an input action to a position corresponding to the "yes" item is made
-entering using biometric authentication such as fingerprint authentication and iris authentication
Simultaneously with or separately from the confirmation process of the user, or without the confirmation process of the user, the terminal 110 may determine whether the confirmation code is required by checking the corresponding information received from the SM-DP + 120. If information indicating whether the confirmation code input is required is received, the terminal 110 may inquire the user about the confirmation code through the UI and receive the confirmation code input.
The terminal 110 may verify the hashed confirmation code 1 sent by the SM-DP +120 at step 435 using the confirmation code entered by the user and the SM-DP + challenge information received at step 415. That is, the terminal 110 can calculate the hashed confirmation code 1 itself using the confirmation code input by the user and the SM-DP + challenge information received at step 415. The terminal 110 may then determine whether the computed hashed confirmation code 1 is the same as the hashed confirmation code 1 received from SM-DP + 120.
The terminal 110 may calculate a second modified confirmation code (or a second hashed confirmation (hashed confirmation code 2)). The hash operation may be performed one or more times to hide the confirmation code. It is also possible to operate using the SM-DP + challenge value such that a unique hash result value is generated each time. The hashed validation code 2 may be calculated using a formula other than hashed validation code 1. This operation may be performed by one or more CPUs of terminal 110. For example, security may be improved by having an Application Processor (AP) that is responsible for a portion of the operations and a modem or eUICC115 that is responsible for the remainder of the operations.
At step 450, terminal 110 may determine whether the user has confirmed the profile download at step 445.
If it is determined at step 450 that the user has confirmed the profile download, the terminal 110 may determine at step 455 whether the hashed confirmation code 1 was successfully verified.
If the user has confirmed the profile download at step 450 and if the hashed confirmation code 1 received from SM-DP +120 at step 435 matches the hashed confirmation code 1 calculated by terminal 110 at step 445, terminal 110 may request the profile download from SM-DP +120 at step 460. At this time, the terminal 110 may generate an eUICC signature value (eUICC signature2) for the profile download request information. The terminal 110 may transmit a request message (e.g., getbackprofilepacket) including an eUICC signature value (eUICC signature2) and profile download request information to the SM-DP + 120.
The request message may include a hashed confirmation code of 2.
At step 465, SM-DP +120 may verify the hashed validation code of 2.
The SM-DP +120 may determine whether the request message received from the terminal 110 at step 460 includes the hashed confirmation code of 2. If the request message does not include the hashed confirmation code of 2, then SM-DP +120 may perform step 475.
If the request message received at step 460 includes hashed validation code 2, SM-DP +120 may itself compute hashed validation code 2. Then, the SM-DP +120 may determine whether the computed hashed validation code 2 and the received hashed validation code 2 match.
If the two code values match, then SM-DP +120 may perform step 470.
If the two code values do not match, the SM-DP +120 may send a message including information indicating that the profile download failed to the terminal 110 and end the process.
At step 470, the SM-DP +120 may transmit the encrypted profile to the terminal 110 according to the profile download request information received at step 460.
The terminal 110 may then decode the encrypted profile and install the profile at step 480. The profile decoding may be performed in the eUICC115 within the terminal 110.
If the user rejects the profile download at step 450 or the confirmation codes hashed at step 455 do not match, the terminal 110 may send a profile download rejection report and/or a confirmation result and/or a confirmation code mismatch result to the SM-DP +120 at step 490. The terminal 110 then ends the profile download process.
According to an embodiment of the present invention, when the hashed confirmation code 1 values do not match, the terminal 110 may query the user for the confirmation code, compare the input confirmation code with the hashed confirmation code 1, and perform step 460 according to the comparison result.
If a profile download rejection report is received, the SM-DP +120 may end the profile download process at step 495. At this time, the SM-DP +120 may transmit an ACK message to the terminal 110 in response to the profile download rejection report.
It will be apparent to those skilled in the art that the profile download procedure described above may be applied to other types of communication systems.
Fig. 5 is a signal flow diagram illustrating a profile download method according to another embodiment of the present invention. In this embodiment, the terminal and SM-DP + exchange signature and encryption parameters for normal signature and encryption processing during the profile download process.
Referring to fig. 5, the terminal 110 may generate server authentication information for authenticating a server at step 510. The server authentication information may be a random value, such as a challenge value. The challenge value may be generated by a control unit of the terminal 110 or the eUICC115 connected to the terminal 110, and may be referred to as an eUICC challenge value. The terminal 110 may send a message including server authentication information, eUICC signature, and encryption parameters to the profile providing server 120. This message may be an initial authentication request message (InitAuthRequest). The profile providing server 120 may be SM-DP +. The eUICC signature and encryption parameters may be included in the eUICC information (eUICC Info) sent to SM-DP + 120. At this point, the eUICC challenge can be a signature creation algorithm and the eUICC signature can be a signature verification algorithm.
The SM-DP +120 may be informed indirectly of the signature creation algorithm, the signature verification algorithm, and the encryption parameters, instead of being sent directly as shown in the diagram of fig. 5. For example, reference identification information may be defined between the terminal 110 and the SM-DP + 120. In this case, if the terminal 110 transmits a predetermined value to the SM-DP +120 according to the reference identification information value, the SM-DP +120 may check a signature creation algorithm, a signature verification algorithm, and an encryption parameter according to the received reference identification information value. For example, if the reference identification information is set to 1, the terminal 110 and the SM-DP +120 employ the signature creation algorithm of a, the signature verification algorithm of B, and the encryption parameter of C. At this time, if the terminal 110 transmits the reference identification information set to 1 to the SM-DP +120, the SM-DP +120 can check the signature creation algorithm, the signature verification algorithm, and the encryption parameter.
If the terminal 110 (or the eUICC 115) determines to use the specific information, the SM-DP +120 may check a signature creation algorithm, a signature verification algorithm, and encryption parameters based on the specific information. For example, when the terminal 110 determines to use a specific parameter, there may be a protocol between the terminal 110 and the SM-DP +120 that assumes the use of a predetermined signature creation algorithm, signature verification algorithm, and encryption parameter. At this time, if the terminal 110 notifies the SM-DP +120 to use a specific parameter, the SM-DP +120 can check a signature creation algorithm, a signature verification algorithm, and an encryption parameter based on the notification. For example, if the terminal 110 determines to use a certain Certificate Issuer (CI), the SM-DP +120 may check a signature creation algorithm, a signature verification algorithm, and encryption parameters according to CI information (CIInfo).
At step 515, the SM-DP +120 may generate terminal authentication information for authenticating the terminal 110. At this time, the terminal authentication information may be a random value, for example, an SM-DP + challenge value generated by the control unit of the SM-DP + 120. The SM-DP +120 may compute an SM-DP + signature for data including the eUICC challenge value received at step 510 and the SM-DP + challenge value generated by SM-DP + 120. At this time, the SM-DP + signature may be SM-DP + signature 1.
Meanwhile, the SM-DP +120 may select the best signature and encryption parameters based on the eUICC signature and encryption parameters received at step 510. The SM-DP +120 may select signature and encryption parameters to be used by the eUICC115 and send them to the terminal 110 (or the eUICC 115). If there are no supportable parameters in the information received from the eUICC115, the SM-DP +120 may reject the request from the eUICC115 and send a reject message to the terminal 110.
SM-DP + signature1 may be computed using the SM-DP + private key. The SM-DP +120 may send a response message to the terminal 110 that includes the SM-DP + signature1 and the SM-DP + challenge value. The response message may include signature and encryption parameters for use by the eUICC 115.
Steps 520 to 595 are similar to steps 420 to 495 of fig. 4; therefore, a detailed description thereof is omitted herein.
Fig. 6a to 6c are signal flow diagrams illustrating a profile downloading method of the present invention according to an embodiment of the present invention.
Referring to fig. 6a to 6c, the terminal 110 inquires the SM-DP +140 about information without exposing a terminal identifier (e.g., EID) in order to secure private information during profile download.
The processes 610 to 630 of fig. 6a to 6c are conditionally performed as follows.
When the LPA (i.e., terminal 110) has the eUICC certificate (CERTS _ eUICC), a protected EID obtained by hashing the EID, and eUICC information, the process 610 may be omitted. Meanwhile, the terminal 110 includes the LPA, and in this embodiment, the LPA performs the operation of the terminal 110.
The process 620 may be performed when the profile management server (SM-SR +130) or the profile provisioning server (SM-DP +120) requests a profile download from the MNO 150 with an indication of the profile associated with the SM-DS 140.
Process 630 may be omitted when terminal 110(LPA) has received eventType, dpToken1, and srToken1 information.
The respective steps are described in detail hereinafter.
The terminal 110 may read the CERTS _ eUICC from the eUICC115 through steps 611 and 612. The CERTS _ eUICC may include an eUICC certificate and an EUM certificate. In detail, the terminal 110 may transmit a localmanagementerrequest message including cert _ eUICC request information (GetCert) to the eUICC115 at step 611, and receive a localmanagementerresponse message including the cert _ eUICC from the eUICC115 at step 612.
The terminal 110 may read the protected EID value from the eUICC115 through steps 613 and 614. The protected EID may include at least one of the following items of information:
the information on the time of day is,
the EID or the EID value of the hash,
signature value of EID.
The time information may be used to compute a hashed EID value or a signature value of the EID. To achieve this, the terminal 110 may send a LocalManagementRequest message including the protected EID value request information (GetEID) to the eUICC115 and receive a LocalManagementResponse message including the protected EID value from the eUICC 115.
The terminal 110 may obtain the eUICCInfo (eUICC information) from the eUICC115 through steps 615 and 616.
The eUICCInfo may include the following information:
signature of eUICC and elliptic curve parameters for encryption,
remaining storage capacity (memory size) of eUICC.
In detail, the terminal 110 may transmit a LocalManagementRequest message including the eUICCInfo request information (GetEUICCInfo (get eUICCInfo)) to the eUICC115 at step 615, and receive a LocalManagementResponse message including the eUICCInfo from the eUICC115 at step 616.
In the case where the eUICC management request, the profile download request, or the profile management request message includes indication information indicating profile download processing or profile management using the SM-DS140, the SM-SR +130 or SM-DP +120 may request event registration to the SM-DS140 through steps 621 and 622. In detail, the SM-SR +130 may transmit a registerentrequest message including profile mapping information (EventID), EID, and server id (srid) to the SM-DS140 at step 621, and receive a registerentresponse message including a result code (ResultCode) from the SM-DS140 at step 622.
At step 623, the SM-DS140 may send a push notification to the terminal 110 via the push server.
At step 624, the terminal 110 may transmit an EventID (profile mapping information) request message (EventIDRequest) including the protected EID to the SM-DS 140. The SM-DS140 may then validate the protected EID. Specifically, if a time interval between a point of time included in the protected EID and a point of time when the EventID request message is received is greater than a predetermined range, the SM-DS140 fails to verify the protected EID. The verification process may also include verifying the validity of the hash value or signature value. If any verification fails, the SM-DS140 may not reply or may transmit a response message including a response code corresponding to the reject reason to the terminal 110.
At step 625, SM-DS140 may send one or more information pairs of EventID and server information (SRID) to terminal 110. The server address (SRID) includes the address of the server for processing the corresponding EventID, and the corresponding server may be SM-DS140, SM-DP +120, or SM-SR + 130. According to an embodiment of the present invention, if there is no EventID, the SM-DS140 may not transmit EventID information. For ease of illustration, it is assumed at step 631 that the server address is that of SM-DP +120 or SM-SR + 130.
If the terminal 110 acquires the EventID and the server address through the previous steps, the terminal 110 may request an EventID process procedure from the SM-SR +130 or the SM-DP + 120. The EventID process may be one of the following: download profile, remote management eUICC, and return other EventID and server addresses. At this time, the terminal 110 may request the SM-SR +130 or SM-DP +120 to process the corresponding EventID using the terminal information (terminal Info) or the eUICC information (eUICC Info). In the case where the terminal 110 issues a request to the SM-SR +130, the SM-DP +120 may be added to or deleted from the request. The terminal information may comprise the IMEI of the terminal or a part thereof.
In case that the SM-SR +130 or SM-DP +120 checks the terminal information or the eUICC information, if at least one item of information is not supported by the SM-SR +130 or SM-DP +120, the SM-SR +130 or SM-DP +120 may reject the corresponding request and end the procedure. For example, if the SM-SR +130 or SM-DP +120 does not support the ECC signature parameters or encryption parameters included in the eUICC information, it may reject the request. If either or both of the ECC signature parameters and encryption parameters included in the eUICC information are supported by SM-SR +130 or SM-DP +120, it may select supportable parameters for use in signature verification, signature creation, and encryption.
If SM-DP +120 receives the request from SM-SR +130, SM-DP +120 may verify at step 633 whether the SM-SR + identifier included in the EventID matches the SM-SR + identifier included in the certificate of SM-SR + 130. At this time, the certificate of SM-SR +130 may be a certificate for ECDSA signature.
At step 634, the SM-DP +120 may create an asymmetric key pair (ECKA temporary key pair) for profile encryption.
At step 635, SM-DP +120 may create DPToken1. At this time, the DPToken1 may include at least one of the following information items:
profileRecordPart1 (Profile recording part1, including a portion of the profile plaintext information)
ePK _ DP _ ECKA (public key of temporary asymmetric Key Pair)
sign_DP1(SM-DP+signature1)
cert _ DP _ ECDSA (SM-DP + certificate for signature)
cert _ DP _ ECKA (SM-DP + certificate for encryption)
confirm type (user confirmation type)
confirm message (message when obtaining user confirmation)
confirm codehash1 (confirmation code hash value 1)
Specifically, if the configType includes a value that requires a confirmation code input by the user, SM-DP +120 may generate a confirmation code hash value of 1.
If a normal confirmation code hash value 1 is transmitted to the terminal 110 from the SM-DP +120 that normally receives the confirmation code from the operator that has issued the confirmation code to the user, the terminal 110 can verify the SM-DP +120 based on the confirmation code input by the user to verify that the profile is not downloaded from the abnormal server.
Even if the confirmation code is fixed for a particular profile, SM-DP +120 may generate a unique confirmation code hash value of 1 at a time. For example, SM-DP +120 may generate the confirmation code hash value 1 as follows:
confirm codehash1 generated by SM-DP +120 as SHA256(ePK _ DP _ ECKA | confirmation code)
At this time, the confirmation code may be a value that the SM-DP +120 receives from the operator.
The confirmation code hash value 1 generated in this way is transmitted to the terminal 110; thus, if the confirmation code entered by the user does not match the information sent by SM-DP +120, the profile download is prevented at terminal 110. At this time, the terminal 110 may compare the received confirmation code hash value 1 with its own calculated confirmation code hash value 1. According to an embodiment of the present invention, the confirmation code hash value calculated by the terminal 110 may be a result value of SHA256(ePK _ DP _ ECKA | confirmation code) formula using the confirmation code input by the user and the ePK _ DP _ ECKA value received from the SM-DP + 120.
The SM-DP +120 and the terminal 110 may also generate the configcodehash 1 value using another formula, but even in this case, the confirmation code and the value generated uniquely each time are used as factors. For example, configCodeHash 1 (validation code hash value 1) may be generated using the following equation:
configrcodehash 1 ═ SHA256(ePK _ DP _ ECKA | SHA256 (confirmation code)).
At step 636, the SM-DP +120 may send a response message including the DPToken1 to the SM-SR + 130. At this time, the response message may be ES3_ download profile response (ES3_ download profile response).
At step 637, SM-SR +130 may generate SRToken 1.
At this time, SRToken1 may include at least one of the following items of information:
SM-SR + certificate
One-time random value
SM-SR + signature value
At this time, the one-time random value may be used to protect the terminal 110 from a playback attack by reusing the signature value. Then, the SM-SR +130 may verify the signature of the terminal 110 using the one-time random value to authenticate the terminal 110.
At step 638, the SM-SR +130 may send a response message to the terminal 110. At this time, the response message may be ES9_ EventResponse (ES9_ event response).
The ES9_ EventResponse may include at least one of the following items of information:
resultCode
eventType
srToken1
dpToken1
eventType represents information about a download profile (downloadProfile), and includes DPToken1 according to an embodiment of the present invention.
If the EventID included in the ES9_ EventRequest received at step 631 is invalid, the SM-SR +130 may transmit an ES9_ EventResponse including a resultCode including error information to the terminal 110. At step 675, the SM-SR +130 may send ES12_ DeleteEventRequest (ES12_ delete event request) including the EventID to the SM-DS 140.
At step 639, the terminal 110 may send an authentication data request message to the eUICC 115. The authentication data request message may be ES10_ GetAuthDataRequest (ES10_ get authentication data request).
Figure BDA0001592396550000281
The provisioningType information may include information indicating whether the SM-DS140 is involved in the profile download process.
Figure BDA0001592396550000282
If the eventType is set to "downloadProfile", the ES10_ getactudatarequest message may include dpToken1, terminalType, and provisiontype.
The eUICC115 can verify srToken1 at step 641.
At this time, the verification process may proceed as follows. The eUICC115 can use PK _ CI _ ECDSA to verify CERT _ SR _ ECDSA. The eUICC115 can extract PK _ SR _ ECDSA from CERT _ SR _ ECDSA and verify SIGN _ SR1 with PK _ SR _ ECDSA and NONCE _ SR. The eUICC115 can store PK _ SR _ ECDSA and NONCE _ SR with the eventID for later use at step 659.
If the eventType is set to "downloadProfile," the eUICC115 can create and identify a security domain for storing the profile.
Thereafter, the eUICC115 can verify the dpToken1.
The verification process may proceed as follows. The eUICC115 can use PK _ CI _ ECDSA to verify CERT _ DP _ ECDSA. The eUICC115 can extract PK _ DP _ ECDSA from CERT _ DP _ ECDSA and verify SIGN _ DP1 with PK _ DP _ ECDSA and ePK _ DP _ ECKA. The eUICC115 can use PK _ CI _ ECDSA to verify CERT _ DP _ ECKA. The eUICC115 can extract PK _ DP _ ECKA from CERT _ DP _ ECKA. Thereafter, the eUICC115 can store PK _ DP _ ECDSA, PK _ DP _ ECKA, and ePK _ DP _ ECKA for later use at step 659. The eUICC115 may also store the profilerecordcpart 1 for later use at step 662.
If any verification fails, the eUICC115 can send an error message to the terminal 110.
If srToken1 and dpToken1 were successfully verified, then at step 642 the eUICC115 may have verified information such as SRID, DPID, EventID, EventType, TargetEID (target EID), ProfileType, ProfileDescription, MNO's PLMNID, TerminalType, ConfirmType, and Provisioning Type.
With such information, the eUICC115 can determine whether to continue the profile download process as follows:
the eUICC115 can verify, according to its configuration, whether the SRID included in the CERT _ RR _ ECDSA is allowed.
The eUICC115 can verify, according to its configuration, whether the DPID included in the CERT _ DP _ ECDSA is allowed.
The eUICC115 can verify whether PLMNID is allowed or not according to the configuration of the eUICC.
If the terminalType is set to "without _ UI", the eUICC115 can verify whether the ConfirmType is "yesOrNo (Yes or No)".
If terminalType is set to "with _ UI", ConfirmType is set to "yesOrNo", and provisioningType is set to "with _ SM-DS", the eUICC115 can verify whether PLMNID is allowed according to the configuration of the eUICC.
If all verifications are successful, the eUICC115 can continue the profile download process.
If any validation fails, the eUICC115 can reject the event and send a response message that includes the reject reason.
The eUICC115 can create a pair of a temporary public key (ePK _ eUICC _ ECKA) and a temporary private key (eSK _ eUICC _ ECKA).
The eUICC115 can store ePK _ eUICC _ ECKA, eSK _ eUICC _ ECKA, PK _ SR _ ECDSA, PK _ DP _ ECDSA, and NONCE _ SR along with EventID.
The eUICC115 can create an eUICC token (EUICCToken) at step 644.
At this point, EUICCToken may include at least part of the following information:
eventID
sign _ eUICC (signature created by eUICC)
nonce _ eUICC (one-time random value generated by eUICC)
ePK _ eUICC _ ECKA (public key of temporary asymmetric key pair generated by eUICC)
eUICCInfo EUICCInfo
eUICC signature (sign _ eUICC) can be calculated with SK _ eUICC _ ECDSA.
NONCE _ SR is included in the calculation for SM-SR +130 to authenticate the eUICC115, and ePK _ DP _ ECKA is included in the calculation for SM-DP +120 to authenticate the eUICC 115.
The eUICC115 can generate and store a session key for later use at step 660. At this time, a Receipt (accept) may be generated together with the session key. The receipt may be used as the initial MAC link value for the first SCP03t CommandTLV (SCP03t command TLV).
At step 645, the eUICC115 can send an ES10_ GetAuthDataResponse (ES10_ get authentication data response) message to the terminal 110.
The ES10_ GetAuthDataResponse message may include at least one of the following information items:
resultCode result code
eUICCToken
If the resultCode included in the ES10_ GetAuthDataResponse message received at step 645 is set to "reject", the terminal 110 may transmit an ES9_ NotifyResultRequest (ES9_ notification result request) message to the SM-SR +130 at step 670. The ES9_ NotifyResultRequest message transmitted to the SM-SR +130 may include the same result code as the ES10_ GetAuthDataResponse message (eventsult (event result) information included in the message of step 670). Otherwise, if the resultCode included in the ES10_ GetAuthDataResponse message received at step 645 is set to "successful", the terminal 110 may ask the user for a confirmation code at step 646.
If dptoken1. configtype is set to "yesOrNo", the terminal 110 may present the necessary information such as eventType and profilerecordcrdpart 1 to the user to require explicit consent to perform eUICC management events.
If dptoken1. configtype is set to "codelnput", the terminal 110 may ask the user for the confirmation code received from the MNO 150 during the subscription procedure. The terminal 110 may verify that the received dptoken1. configcodehash1 is correct using the following formula:
SHA256(dpToken1.ePK _ DP _ ECKA | confirmation code input by user)
If the verification is successful, SM-DP +120 may send an error message to SM-SR + 130.
If the ES9_ EventResponse message comprises dptoken1.confirm message, the terminal 110 may present the message to the user when confirmation is requested.
Exceptionally, if the terminal 110 is an M2M device without a UI and the config type is set to "yes or", the terminal 110 may omit the user confirmation process.
If the user accepts the profile download, the terminal 110 may send an ES9_ euicmanagementrequest (ES9_ eUICC management request) message to the SM-SR +130 at step 647.
The ES9_ euicmanagementrequest message may include at least part of the following information:
eUICCToken
ConfirmCodeHash2 confirmation hash code value 2 calculated by terminal
certs_eUICC CERTS_eUICC
At this time, the configCodeHash 2 can be calculated by the terminal 110 as follows.
SHA256(ePK _ eUICC _ ECKA | ePK _ DP _ ECKA | confirmation code of user input)
Otherwise, if the user rejects the profile download, the terminal 110 may send an ES9 NotifyResultRequest message to the SM-SR +130 at step 670. At this time, the ES9_ notifyreultrequest message may include a resultCode set to "user reject" and a corresponding eventID.
At step 648, SM-SR +130 may validate the uicctoken and the CERTS _ eUICC.
The verification process may proceed as follows. SM-SR +130 may verify CERT _ eUICC _ ECDSA using CERT _ CI _ ECDSA stored in SM-SR +130 and CERT _ EUM _ ECDSA transmitted with CERT _ eUICC.
The SM-SR +130 extracts PK _ eUICC _ ECDSA from CERT _ eUICC _ ECDSA and verifies sign _ eUICC using PK _ eUICC _ ECDSA, ePK _ DP _ ECKA, and NONCE _ SR. SM-SR +130 may use the ePK _ DP _ ECKA and NONCE _ SR values stored with the evenTID.
If any authentication fails, the SM-SR +130 may send an error value to the terminal 110 and the SM-DP + 120.
If all verifications are successful, this may mean that SM-SR +130 successfully authenticates eUICC 115.
At step 649, SM-SR +130 may send a ProfileRequest message to SM-DP + 120.
The ES3_ ProfileRequest message may include at least part of the following information:
eUICCToken
nonce_SR
confirmCodeHash2
certs_eUICC
SM-DP +120 may validate euicrecipe and CERTS _ eUICC at step 651.
The verification process may proceed as follows. The SM-DP +120 may verify the CERT _ eUICC _ ECDSA and CERT _ eUICC _ ECKA using CERT _ CI _ ECDSA stored in the SM-DP +120 and CERT _ EUM _ ECDSA transmitted with the CERT _ eUICC.
SM-DP +120 may extract PK _ eUICC _ ECDSA from CERT _ eUICC _ ECDSA and verify sign _ eUICC using PK _ eUICC _ ECDSA, ePK _ DP _ ECKA, and ONCE _ SR. At step 649, SM-DP +120 may use ePK _ DP _ ECKA stored with the eventID and NONCE _ SR received from SM-SR + 130.
Next, the SM-DP +120 may extract PK _ eUICC _ ECKA from CERT _ eUICC _ ECKA.
If the event. userconfirmation. configtype is set to "codelnput", the SM-DP +120 can verify that the received ES3_ profierequest. configcodehash2 is correct using the following formula:
SHA256(eUICCToken.ePK_eUICC_ECKA|ePK_DP_ECKA|event.userConfirmation.confirmCode)
if any of the verifications fail, SM-DP +120 may send an error value to SM-SR + 130.
If all verifications are successful, this may mean that SM-DP +120 successfully authenticates eUICC 115.
At step 652, the SM-DP +120 may derive the SCP03t AES session key from PK _ eUICC _ ECKA, SK _ DP _ ECKA, ePK _ eUICC _ ECKA, and eSK _ DP _ ECKA.
The SCP03tSessionKey (SCP03t session key) may include at least part of the following information:
encryption key for sENC to encrypt outbound information
sMAC integrity protection key for outbound information
sRAMC integrity protection key for inbound information
At step 653, SM-DP +120 may generate a ProfileInstallPackage.
The profilelnstallpackage may include at least part of the following information:
dpToken2DPToken2，
profileProtectionKey (Profile protection Key) encryption Key modification Key
SecuredProfilePack encrypted Profile
DPToken2 may include the following information:
sign_DP2SIGN_ECDSA
sign _ DP2 is a signature generated by SM-DP + 120.
profileProtectionKey is an optional SCP03tCommand TLV that includes a pre-generated SCP03t AES key. The pre-generated SCP03t AES key may be used to secure the securedprofilepacket. The TLV may be protected with the SCP03t session key received at step 652.
At step 654, the SM-DP +120 may send an ES3_ ProfileResponse (ES3_ profile response) message to the SM-SR + 130.
The ES3_ ProfileResponse message may include the following information:
resultCode ResultCode，
profileInstallPackage ProfileInstallPackage
at step 655, SM-SR +130 can generate srToken 2.
srToken2 may include the following information:
sign_SR2SIGN_ECDSA
signature sign _ SR2 may be calculated with SK _ eUICC _ ECDSA.
At step 656, the SM-SR +130 may send an ES9_ euicmanagementresponse (ES9_ eUICC management response) message to the terminal 110.
The ES9_ euicmanagementresponse message may include the following information:
resultCode ResultCode,
profileInstallPackage ProfileInstallPackage OPTIONAL,
srToken2SRToken2
at step 657, the terminal 110 may send an ES10_ establish secure channel request (ES10_ establish secure channel request) message to the eUICC 115.
If the eUICC115 receives ES10_ establishhanserinrequest, it may first verify srToken2 at step 658.
The verification process may proceed as follows. The eUICC115 can validate sign _ SR2 with PK _ SR _ ECDSA.
If the verification fails, the eUICC115 can send an error value to the terminal 110.
If the verification is successful at step 685, the eUICC115 can verify the dpToken2 at step 659.
The verification process may proceed as follows. The eUICC115 can validate sign _ DP2 with PK _ DP _ ECDSA.
At step 641, the eUICC115 can verify SIGN _ DP2 using the ePK _ eUICC _ ECKA, NONCE _ SR, and PK _ DP _ ECDSA values stored with the EventID.
The eUICC115 can verify CERT _ DP _ ECKA with PK _ CI _ ECDSA stored therein.
Next, the eUICC115 can extract PK _ DP _ ECKA from CERT _ DP _ ECKA.
The eUICC115 can check whether the DPID stored in CERT _ DP _ ECKA is the same as the DPID stored in CERT _ DP _ ECDSA.
If any verification fails, the eUICC115 can send an error message to the terminal 110.
If all verifications succeed, this may mean that SM-DP +120 and SM-SR +130 successfully verified the eUICC 115.
If the authentication fails at step 659, the eUICC115 can open a secure channel at step 660 using the SCP03t session key generated at step 644 (i.e., the eUICC115 can decrypt the SCP03tCommandTLV after this step).
After generating the session key, the eUICC115 may send an ES10_ espableshsecurechannelresponse (ES10_ setup secure channel response) TLV to the terminal 110 at step 661.
At step 662, the terminal 110 may send an ES10_ InstallProfileRecordRequest (ES10_ installation profile record request) message to the eUICC 115.
The eUICC115 can decrypt the securedProfileRecordPart2 (security profile record part 2) with the profileRecordPart2 (profile record part 2). The eUICC115 may combine the profilerecordcpart 1 and profilerecordcpart 2 obtained from the DPToken1 at step 641 to generate a ProfileRecord in a ProfileRegistry.
At step 663, the eUICC115 can return an ES10_ installprofilerecordrresponse (ES10_ install profile record response) message to the terminal 110.
Step 664 is an optional step in which the terminal 110 may send an ES10_ UpdateSessionKeyRequest (ES10_ update session key request) message carrying a profileproxotectionkey to the eUICC115 if a ProfileInstallPackage message including a profileProtectionKey TLV is delivered from SM-SR +130/SM-DP + 120.
If the eUICC115 receives the ES10_ UpdateSessionKeyRequest message, the eUICC115 can decrypt the profileProtectionKey with the SCP03tSessionKey (SCP03t session key) and replace the SCP03t session key with the decrypted SCP03 tSessionKey. The updated SCP03t session key may be used to protect subsequent SCP03tCommandTLV over the established secure channel.
The first subsequent SCP03tCommandTLV may include a C-MAC if the session key is updated by the ES10_ UpdateSessionKeyRequest message. The C-MAC may be calculated with the "MAC link value" to be set to 16 bytes "0 x 00".
Step 665 is an optional step in which the eUICC115 can return an ES10_ UpdateSessionKeyResponse (ES10_ renew session key response) message to the terminal 110 after step 664.
At step 666, the terminal 110 may send an ES10_ installprofilepackrequest (ES10_ install profile packet block request) message to the eUICC 115.
At step 667, the eUICC115 can decrypt a secure profilepackageblock with the session key. The decrypted profilepaackageblock may include one or more Profile Elements (PEs) and/or portions of PEs. Portions of a PE may be combined with previously stored portions of the PE to form a single complete PE. If the decryption and possible combination results in one or more complete PEs, the eUICC115 can install the PEs in order. The remaining and/or incomplete PEs may be stored in the eUICC115 for future use.
After processing the ProfilePackageBlock, the eUICC115 may send an ES10_ installprofilepackresponse (ES10_ installation profile packet block response) message to the terminal 110 at step 668.
Steps 666 through 668 may be repeated until the last ProfilePackageBlock is sent. If the ES10_ InstallProfilePackRequest message includes a lastBIndicator (last PB indicator) set to lastPB (1) and all PEs are successfully installed, the eUICC115 generates an ES10_ InstallProfilePackResponse message that includes the resultCode and the ProfileRecord of the evenResult and the Profile in the ProfileRegistry.
If an ES10_ installprofilepaackageblockresponse message including an eventerresult is received from the eUICC115, the terminal 110 may transmit an ES9_ notifyrequest message including the eventerresult generated by the eUICC115 to the SM-SR +130 at step 670. If an ES10_ installprofifilepackageblockresponse message is received from the eUICC115 together with the eventerest, the terminal 110 may transmit an ES9_ notifyrequest message including the eventerest generated by the eUICC115 to the SM-SR + 130.
The ES9_ notifyreultrequest message may include the following information:
eventResult (eUICC processing result)
cert _ EUM _ ECDSA (EUM certificate)
resultCode (result code)
EventResult may include the following information:
resultCode
eID
eventID
profileID profile identifier
sign _ Result processing Result signature value generated by eUICC
SM-SR +130 may respond with the following TLVs. If the SM-SR +130 does not know the eventID in the eventsresult sent by the terminal 110, the SM-SR +130 may send an error message to the terminal 110 together with the corresponding resultCode.
The ES9_ notifyreultresponse (ES9_ notification result response) message may include the following information:
resultCode ResultCode
if a result notification is received from the terminal 110, the SM-SR +130 may send the result to the MNO 150 and/or the SM-DP +120 (see steps 680, 681, 683, 684, 685, and 686). If the result notification is set to "success," SM-SR +130 may delete the EventID from its database so as not to repeatedly process the same event. If the event is not successfully deleted in the SM-DS140, the terminal 110 may retrieve the event again when the terminal requests the same event from the SM-SR + 130.
It is proposed that the eUICC115 stores and holds the EventID when it completes successfully. As a result, the eUICC115 can control the case where the completed event was not successfully deleted from the databases of SM-DS140 and SM-SR +130, and thus the same event is initiated to the eUICC115 (see steps 690 and 691). The eUICC115 can recognize this situation and return a failure.
If the established secure channel is no longer needed, the terminal 110 may send an ES10_ ReleaseSecureChannelRequest (ES10_ release secure channel request) message to the eUICC115 at step 672. The ES10_ releasesecurenehalrequest message may include information indicating the release of the secure channel and the associated session key.
If an ES10_ ReleaseSecureChannelRequest message is sent, the eUICC115 can release the secure channel and related session keys at step 673 and then send an ES10_ releasesecurenhannelresponse (ES10_ release secure channel response) message to the terminal 110 in reply.
In the event that the secure channel is released, the eUICC115 can send an error message when receiving the SCP03tCommandTLV without any information indicating that a new secure channel is to be reestablished.
Step 674 is an optional step in which terminal 110 may ask the user to enable the installed profile. If the user accepts the enablement of the profile, the terminal 110 may perform a local profile enablement procedure.
If the ES9_ notifyreultrequest message transmitted by the terminal 110 indicates successful installation of the profile, the SM-SR +130 may transmit an ES12_ DeleteEventRequest message including an EventID of the download profile event to the SM-DS140 at step 675. SM-DS140 may delete the EventID and related parameters stored at step 620 from its database.
The ES12_ DeleteEventRequest message may include the following information:
eventID eventID
at step 676, SM-DS140 may respond to the next TLV. If the SM-DS140 does not know the evenTID in the ES12_ DeleteEventRequest message, the SM-DS140 may send a failure message including the resultCode to the SM-SR + 130.
The response message transmitted from the SM-DS140 to the SM-SR +130 may be an ES12_ DeleteEventResponse (ES12_ delete event response), which may include the following information:
resultCode ResultCode
at step 677, SM-SR +130 may send an ES3 NotifyResultRequest message to SM-DP + 120. The ES3_ notifyreultrequest message may include the eventeresult generated by the eUICC 115. The ES3_ notifyreultrequest message may notify the SM-DP +120 of the download and installation results of the profilepacket sent by the SM-DP + 120.
The ES3_ notifyreultrequest message may include the following information:
eventResult OPTIONAL,/. conditions, if ES9_ NotifyResultRequest
Containing eventResult +
Resultcode Optional- -otherwise
At step 678, SM-DP +120 may respond to the next TLV. If SM-DP +120 does not know the eventID in the eventResult, SM-DP +120 may send a failure message to SM-SR +130 that includes the resultCode.
The response message sent from SM-DP +120 to SM-SR +130 may be an ES3_ notifyreultresponse message, which may include the following information:
resultCode ResultCode
if the terminal 110 or the SM-DP +120 requests profile download via the MNO 150, the SM-DP +120 may send an ES2 notifyreultrequest message to the MNO 150 at step 680. Alternatively, if the terminal 110 or MNO 150 requests a profile download via SM-SR +130, SM-SR +130 may send an ES4 notifyreultrequest message to MNO 150 at step 683. The notifyreultrequest message interface of ES2 or ES4 may include eventsult generated by the eUICC 115.
The ES2_ notifyreultrequest message may include at least one of the following items of information:
eventResult，
resultCode
the ES4_ notifyreultrequest message may include at least a portion of the following information:
eventResult
cert_eUICC_ECDSA
cert_EUM_ECDSA
resultCode
the MNO 150 may send the next TLV at step 681 or 684.
The ES2_ notifyreultresponse message sent at step 681 may include the following information:
resultCode ResultCode
the ES4_ notifyreultresponse message sent at step 684 may include the following information:
resultCode (result code)
Step 690 is an optional step in which the terminal 110 may transmit an ES11_ DeleteEventRequest message including a ProtectedEID (protected EID) and an EventID included in the downloaded profile event to the SM-DS 140.
The ES11_ DeleteEventRequest message may include at least a portion of the following information:
protectedEID or EID
eventID
At step 691, SM-DS140 may verify protectedEID and eventID. Sign _ eID is valid and issues an eventID for the eUICC115, the SM-DS140 may delete the corresponding event from the database. The SM-DS 150 may transmit a processing result of the ES11_ DeleteEventResponse message to the terminal 110.
The ES11_ DeleteEventResponse message may include the following information:
resultCode
if the SM-SR +130 inadvertently omits this step and/or fails to delete the event, the terminal 110 may avoid unnecessarily receiving notification of the processed event.
By the steps of the embodiments of fig. 6a to 6c, the parameters and messages may be generated more efficiently than they are generated at or previously generated and stored prior to a particular step.
Fig. 7a and 7b are signal flow diagrams illustrating a process of downloading a profile in an eUICC according to an embodiment of the present invention.
Referring to fig. 7a and 7b, the SM-DP +120 may directly communicate with the LPA (i.e., the terminal 110) using HTTPS based on a common IP without involving the SM-SR + 130.
The SM-DP +120 may store the signature certificate (cert.dp.ecdsa) and the private key (sk.dp.ecdsa) in an internal storage device. SM-DP +120 may store a TLS server certificate (cert.dp.tls) and a private key (sk.dp.tls) for HTTPS in an internal storage device. The storage devices for storing cert.dp.ecdsa, sk.dp.ecdsa, cert.dp.tls, sk.dp.tls may be physically the same as or different from each other.
The eUICC115 can store its signature certificate (cert. euicc.ecdsa) and private key (sk. euicc.ecdsa) in an internal storage device. The profile download process may proceed as follows.
At step 710, the terminal 110 may request eUICC credentials from the eUICC 115. The eUICC115 can then send the eUICC certificate (cert.
At this time, if the terminal 110 has the certificate, steps 710 and 713 may be omitted.
If the certificate value of the eUICC115 needs to be sent to the server (SM-DP +120), the terminal 110 can request the eUICC115 to generate the certificate value at step 715. The factors required for the signature may be the value delivered to the terminal 110 and include at least part of the following information:
EventID (identifier for identifying a specific profile download event)
Notification ID (similar to EventID)
-MatchingID (similar to EventID)
Activation code token (similar to EventID)
-random values generated by the terminal
If the signature value of the eUICC115 is not required, the terminal 110 may request eUICC information (UICC information) from the eUICC115 in addition to the signature value of the eUICC 115.
eUICC115 may generate its signature value using sk.
At step 719, the eUICC115 can send the eUICC signature value to the terminal 110. The eUICC115 can only return eUICC _ Info to the terminal 110 if eUICC signature values are not needed. The eUICC _ Info can include version information of the eUICC 115.
At step 720, the terminal 110 may send an ES9+. InitiatedDownload (ES9+. Start download) message to the SM-DP + 120. At this time, an HTTPS session may be established between the terminal 110 and the SM-DP +120 to transmit the ES9+. initiateddownload message. The HTTPS session may be the same as or separate from the session used for the entire profile download process.
ES9+. InitiateDownload message may be an ES9.initiateauthentication (es9. initiateauthentication) message or an es9.eventrequest message.
ES9+. initiateddownload message may include eUICC _ Info and additionally eUICC challenge. If the eUICC signature value is included, an eUICC certificate and an EUM certificate may also be included.
If the SM-DP +120 receives the eUICC certificate and the signature value at step 720, the SM-DP +120 may verify the EUM certificate using the CI certificate or a CI certificate public key (pk. CI. ecdsa), verify the eUICC certificate using the eUICC certificate, and verify the eUICC signature value using the eUICC certificate. Certificate and signature verification may be omitted according to embodiments of the present invention.
The SM-DP +120 may check the eligibility of the eUICC115 based on the eUICC _ Info. At this time, eUICC version information of the eUICC _ Info may be used.
SM-DP +120 may generate a DP challenge. The DP challenge may be a value generated by SM-DP +120 for future authentication of the eUICC 115.
SM-DP +120 may generate a TransactionID (transaction ID). The TransactionID is an identifier for identifying a specific profile download session so that a plurality of terminal requests can be processed simultaneously. If not identified by TransactionID, SM-DP +120 may download the profile of one terminal at a time; therefore, when a certain terminal 110 delays responding to the SM-DP +120, other terminals cannot download the profile either. To address this issue, the SM-DP +120 may configure the lifetime of the session to release the session after the expiration of the corresponding time period, but this approach may lead to performance issues for the SM-DP + 120.
If the SM-DP +120 can receive the MatchingID or EID from the terminal, the SM-DP +120 can check whether there is any downloadable profile corresponding to the MatchingID or EID.
SM-DP +120 may calculate an EP signature value using sk.dp.ecdsa for data including eUICC _ Challenge, DP Challenge, and TransactionID values.
The DP signature value may be a signature value used for the eUICC115 to authenticate SM-DP + 120.
At step 727, the SM-DP +120 may transmit a signature certificate (cert. DP. ecdsa) of the SM-DP +120, a DP challenge, a TransactionID, a DP signature, profile information, and a confirmation code input requirement indicator (configrmationcoderequired identifier) to the terminal 110 in response to the message received at step 720.
In this case, the terminal 110 may display the profile information and receive a confirmation or confirmation code input of the user at step 729.
If the above-described information item is received at step 727, the terminal 110 may transmit an es10b.prepareddownload message (es10b.ready to download) to the eUICC115 at step 730. The es10b prepareddownload message may be an es10 getauthdatarequest message.
The es10 b.prepareddownload message may include cert.dp.ecdsa, DP challenge, TransactionID, and DP signature.
At step 735, the eUICC115 can verify the DP certificate (cert.dp.ecdsa) using the CI certificate or CI public key stored therein.
If the certificate verification is successful, the eUICC115 can verify the SM-DP + Signature value (DP-Signature).
At this time, SM-DP + signature verification is performed using the DP challenge and TransactionID received from the terminal 110, the eUICC challenge transmitted from the eUICC115 to the terminal 110, and the SM-DP + public key (pk.dp.ecdsa) included in cert.dp.ecdsa.
If the verification is successful, the eUICC115 can generate a one-time asymmetric key pair.
The eUICC115 can load and use the previously generated one-time asymmetric key pair as follows:
when requested by a particular SM-DP +120
When requested by the terminal 110 with a separate Indicator
The one-time asymmetric key pair may be used to generate the encryption key between SM-DP +120 and eUICC115 along with the one-time asymmetric key pair for server 120. The encryption key may be generated as follows:
SM-DP +120 generates the encryption key by combining the one-time private key of SM-DP +120 and the one-time private key of eUICC 115.
The eUICC generates the encryption key by combining the private key of the eUICC115 and the public key of SM-DP + 120.
The factors otherwise required to generate the encryption key may be sent from the SM-DP +120 to the eUICC115 via the terminal 110.
The eUICC115 can calculate an eUICC signature value (eUICC _ Sign2) using a private key for signature (sk.euicc.ecdsa) of the eUICC115 for data of a DP challenge and a one-time public key (otpk.euicc.ecka) including the generated one-time asymmetric key pair. Since the DP challenge value generated by SM-DP +120 is used in calculating the eUICC signature value, SM-DP +120 can authenticate the eUICC115 using the eUICC signature value in a subsequent step. The eUICC _ Sign2 enables the eUICC115 to send the generated otpk.
At step 737, the eUICC115 can send the one-time public key of the eUICC115 and the eUICC signature value to the terminal 110.
At step 740, the terminal 110 may send an ES9+ getbackprofilepacket message to the SM-DP + 120. The ES9+ GetBundProfilePack message may be an eUICCManagementRequest or a ProfileRequest message.
The ES9+ getbackprofilepacket message may include a one-time eUICC public key and an eUICC signature value. In addition, the ES9+ getbackprofilepacket message may include an eUICC signature certificate (cert.euicc.ecdsa) for verifying the eUICC signature value and an EUM certificate (cert.euicc.ecdsa) for verifying the eUICC signature certificate.
In addition, the ES9+ GetBundProfilePack message may include information for use as a mapping identifier when downloading a particular profile.
-EventID
-MatchingID
-NotificationID
-activation code token
If the mapping identifier has already been transmitted at a previous step (e.g., step 720), transmitting the mapping identifier may be omitted.
The terminal 110 may send a hash confirmation code to the SM-DP + 120.
At step 745, SM-DP +120 may verify the EUM certificate and eUICC certificate, as described in connection with step 725.
The SM-DP +120 may verify the eUICC signature (eUICC Sign2) using the eUICC one-time public key received from the terminal 110 at step 740, the DP challenge value sent to the terminal 110 at step 727, and the public key included in the eUICC certificate. If the verification is successful, this means that SM-DP +120 has authenticated the eUICC 115. If the authentication fails, the SM-DP +120 may stop the corresponding session and return an error message to the terminal 110.
SM-DP +120 may map the profile to be downloaded using the EventID (or NotificationID, MatchingID, or activation code token) value received at step 740. If there is no profile to be downloaded, the SM-DP +120 may return an error message to the terminal 110 and end the corresponding session.
SM-DP +120 may generate a one-time asymmetric key pair. A one-time asymmetric key pair may be used to generate an authentication key between the eUICC115 and the SM-DP + 120.
SM-DP +120 generates the encryption key by combining the one-time private key of SM-DP +120 and the one-time private key of eUICC 115.
The eUICC115 generates the encryption key by combining the one-time private key of the eUICC115 and the one-time public key of SM-DP + 120.
SM-DP +120 may compute the SM-DP + signature value (DP signature 2). The SM-DP + signature value may be calculated using CRT, the one-time public key of SM-DP +120, the one-time public key of eUICC115, and the SM-DP + signature public key (sk.dp.ecdsa). The CRT may be used as a factor for generating the authentication key.
The SM-DP +120 may generate a Profile Package (Bound Profile Package) or BPP to be combined with a particular eUICC 115. The BPP may include CRT, the one-time public key of SM-DP +120, and DP Signature 2.
The BPP may include profile info (or MetaData) encrypted with an encryption key.
The BPP may include an encrypted PPK generated by encrypting a profile protection key with an encryption key.
The BPP may include a Profile Packet Block (PPB) encrypted with an encryption key or PPK. The encrypted PPB may be generated by dividing the entire Profile data in an installable unit (Profile Element) or PE) and encrypting the PPD divided by the encryptable unit. Encryption may be performed using the SCP03t protocol.
Thereafter, in response to the message received at step 740, the SM-DP +120 may send a BPP message to the terminal 110 at step 747.
The terminal 110 may send an es10b.loadboundprofilepacket message (es10b.loadbinding profile package) to the eUICC115 multiple times at step 750 to deliver ES8_ initializesecurichannel (ES8_ initializing secure channel) information included in the BPP to the eUICC 115. The ES8_ InitializeSecureChannel information may include the one-time public key of the CRT, SM-DP +120, and DP signature 2. ES8_ initializesecurichannel may be an establishhecucurichannel message. An ES10b.LoadBoundProfilePack message may carry a StoreData command.
At step 753, the eUICC115 may verify the DP signature (DP signature2) using the public key of the DP signature certificate (cert.dp.ecdsa) received at step 730, the one-time public key of the CRT, SM-DP +, received at step 750, and the one-time public key of the eUICC received from the terminal 110 at step 737.
If the verification fails, the eUICC115 can return an error message to the terminal 110 at step 755 and end the process.
If the verification is successful, the eUICC115 can generate an encryption key using the CRT, the one-time private key of the eUICC115, and the one-time public key of the SM-DP +120, and send the encryption key to the terminal 110 at step 755.
At step 757, the terminal 110 may transmit an es10b, loadboundprofilepacket message multiple times to deliver ES8+ SetProfileInfo (ES8+ profile information) included in BPP to the eUICC 115. ES8+ SetProfileInfo may be referred to as ES8+. storage metadata) or InstallProfileRecord. ES8+ SetProfilInfo may include ProfileInfo (or Metadata or ProfileRecord). At step 759, the eUICC115 can send a response message to the terminal 110.
At step 760, if the BPP includes ES8+ replaceesessionkey (ES8+ replacement session key), the terminal 110 may transmit an es10b.loadboundprofilepcackage message multiple times to deliver ES8+ replaceesessionkey information included in the BPP to the eUICC 115. ES8+ replaceesessionkey may be referred to as an UpdateSessionKeyRequest message.
The ES8+ replaceesessionkey may include a profiprocessprotect key (ppk) encrypted with the encryption key of step 745.
At step 763, the eUICC115 can send a response message to the terminal 110 that replies to the message received at step 760.
Thereafter, the terminal 110 may transmit an es10 b.loadboundprofilepacket message multiple times to deliver an encrypted Profile Packet Block (PPB) or profile segment included in the BPP.
The eUICC115 can use the encryption key or PPK to serially decrypt the Profile segment.
After processing all the profile segments, the eUICC115 can calculate an eUICC signature value and send the signature value to the terminal 110 at step 767. The terminal 110 may send a corresponding eUICC signature value to the SM-DP +120 to inform the profile installation result at step 770. At step 775, the SM-DP +120 may send a response message to the terminal 110.
Illustratively, the information indicating whether the user's confirmation is required or not transmitted from the SM-DP +120 to the terminal 110 may be formatted as follows.
UserConfirmation::＝SEQUENCE{
confirmType ConfirmType,
confirmMessage ConfirmMessage OPTIONAL
}
ConfirmType::＝ENUMERATED{yesOrNo(0),codeInput(1)}
ConfirmMessage::＝UTF8String
In the above example, UserConfirmation data may be sent from SM-DP +120 to terminal 110, with or without other data. The configype included in the UserConfirmation may have the following value:
if the configType is set to 0 indicating yesOrNo, the terminal 110 may choose to confirm or not confirm the profile download, as described with reference to FIGS. 2-5 and 6 a-6 c.
If configType is set to 1, this means that a code input is required; therefore, the terminal 110 requests to input a confirmation code.
The confirmation message may be supplementary information that terminal 110 presents to the user, and the message may be formatted differently depending on the operator.
Fig. 8a and 8b are signal flow diagrams illustrating a network initialization procedure according to an embodiment of the present invention.
If eventType included in the ereicmanagementrequest message transmitted by the MNO 150 is not set to "profileDownload", radio management (remote management) may be performed in ES5 security without involving the ES 8. A detailed description thereof is made hereinafter.
At step 810, the LPA (i.e., terminal 110) may read the CERTS _ eUICC from the eUICC 115. The CERTS _ eUICC may be information including an eUICC certificate and an EUM certificate. To accomplish this, the terminal 110 may send a LocalManagementRequest message including information (GetCert) requesting the CERTS _ eUICC to the eUICC115 at step 810, and receive a localmanagementerresponse message including the CERTS _ eUICC from the eUICC115 at step 813. Steps 810 and 813 may be omitted if the terminal 110 already has a CERTS eUICC. Since these steps are the same as steps 611 and 612 of fig. 6a to 6c, a detailed description thereof is omitted here.
At step 820, MNO 150 may send ES4_ euicmanagementrequest message to SM-SR + 130.
The ES4_ euicmanagementrequest message may include the following information:
event Event，
dsInfo DSInfo
events have been described in the embodiments of fig. 6a to 6 c. The EventID of the ES4_ evaiccmangementrequest message may be set to NULL.
At step 823, SM-SR +130 may generate a globally unique EventID for the management event.
At step 825, SM-SR +130 may send an uiccmanagementresponse message to MNO 150. The uiccmanagementresponse message may include the following information:
resultCode ResultCode，
eventID EventID
optional- -conditions are such that if the resultCode indicates success
SM-SR +130 may register an Event with SM-DS140 using the ES12_ registerettrequest and ES12_ registerettresponse messages of steps 830 and 833. The ES12_ RegisterEventRequest and ES12_ RegisterEventResponse messages may be the same as described with respect to step 621 and fig. 622 of fig. 6 a-6 c; therefore, a detailed description thereof is omitted here.
The SM-DS140 may send a push notification message to the terminal 110 via the push server.
The terminal 110 may read the ProtectedEID value from the eUICC115 through steps 840 and 843. ProtectedEID may be used later at step 845. Steps 840 and 843 may be omitted if the terminal 110 knows the ProtectedEID value. Terminal 110 may perform steps 810 and 813 before these steps. Since these steps are the same as steps 613 and 614 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted here.
At step 845, the terminal 110 may transmit an EventIDRequest message to the SM-DS 140.
The EventIDRequest message may include the following information:
protectedEID ProtectedEID
then, the SM-DS140 can validate the ProtectedEID. The SM-DS140 may verify that the protected EID fails if the time interval between the time point included in the protected EID and the time point at which the EventID request message is received is greater than a predetermined range. Since this step is the same as step 624 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted here.
Next, the SM-DS140 may transmit an ES11_ EventIDResponse (ES11_ event ID response) message to the terminal 110.
The ES11_ EventIDResponse message may include the following information:
resultCode ResultCode，
eventIDList SEQUENCE OF pending event-condition is if resultCode indicates success
The pending event may include the following information:
eventID EventID，
SRID SRID
when the terminal 110 requests an EventID from the SM-DS140, the SM-DS140 may have at least one PendingEvent. In this case, the eventIDList (event ID list) may include one or more pendingeventids (pending event IDs). Then, the terminal 110 may process the pendingevents one by one in the order arranged in the eventIDList.
The terminal 110 may receive the uiccinfo from the eUICC115 through steps 850 and 853. The eUICCInfo may be used later at step 855. Steps 850 and 853 may be omitted if the terminal 110 already has the uiccinfo. Terminal 110 may perform these steps before steps 810 and 813 or steps 840 or 843. Since these steps are the same as steps 615 and 616 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted here.
If an EventIDResponse message including at least one PendingEvent is received, the terminal 110 may transmit an EventRequest message to the SM-SR +130 at step 855.
The EventRequest message may include the following information:
eventID EventID，
terminalInfo TerminalInfo，
eUICCInfo EUICCInfo
eccparameter (eUICC information ECC parameter) if the received eUICC info is not supported by SM-SR +130, it may send a failure message to terminal 110.
At step 857, the SM-SR +130 may generate SRToken 1.
At this time, SRToken1 may include the following information:
cert_SR_ECDSA CERT_ECDSA，
nonce_SR NONCE_SR，
sign_SR1SIGN_ECDSA
cert _ SR _ ECDSA may comply with the ECC parameters received at step 855.
sign _ SR1 may be a signature generated by SM-SR +130 using SK _ SR _ ECDSA.
SM-SR +130 may store the NONCE _ SR with the eventID and later use the NONCE _ SR to authenticate eUICC115 at step 873.
At step 859, SM-SR +130 may send an EventResponse message to terminal 110.
The EventResponse message may include the following information:
resultCode ResultCode，
eventType EventType，
srToken1SRToken1
at step 860, the terminal 110 may send an ES10_ GetAuthDataRequest message to the eUICC 115. Since this step is the same as step 639 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted.
At step 861, the eUICC115 can verify srToken 1.
At this time, the verification process may proceed as follows. The eUICC115 can use PK _ CI _ ECDSA to verify CERT _ SR _ ECDSA. The eUICC115 can extract PK _ SR _ ECDSA from CERT _ SR _ ECDSA and verify sign _ SR1 using PK _ SR _ ECDSA. The eUICC115 can store PK _ SR _ ECDSA for later use.
The eUICC115 can verify whether the SRID included in the CERT _ SR _ ECDSA is executed in compliance with eprserveraccessfontrol (EPR server access control).
If eventType is set to enableProfile (enabled profile) (1), disableProfile (disabled profile) (2), deletepprofiler (deleted profile) (3), getProfileRegistry (4), or updateProfileRegistry (5), the eUICC115 may verify whether the SRID included in CERT _ SR _ ECDSA is included in the authored SR of the profileregister of the profile.
If the eventType is set to getEPR (obtain EPR) (6) or updateEPR (update EPR) (7), the eUICC115 can verify whether the SRID included in the CERT _ SR _ ECDSA is included in the authorized SR of the EPR.
If eventType is set to getDSInfo (get DS information) (8) or updateDSIfo (update DS information) (9), the eUICC115 can verify whether the SRID included in CERT _ SR _ ECDSA is included in authored SR of DSINfoStatic (static DS information).
If the eventType is set to getCIInfo (get CI information) (10) or updateCIInfo (update CI information) (11), the eUICC115 can verify whether the SRIC included in the CERT _ SR _ ECDSA is included in the authored SR of the CIInfo (CI information).
If the eventType is set to getfirmware info (12) or updatefirmware info (13), the eUICC115 can verify whether the SRID included in the CERT _ SR _ ECDSA is included in the authorized SR of the firmware info.
The eUICC115 can generate euictext at step 863.
Uicctoken may include the following information:
eventID EventID，
sign_eUICC SIGN_ECDSA，
nonce_eUICC NONCE_eUICC
OPTIOANL
the eUICC signature sign _ eUICC can be calculated with SK _ eUICC _ ECDSA. Since this step is the same as step 644 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted here.
At step 865, the eUICC115 can send an ES10_ GetAuthDataResponse message to the terminal 110.
The ES10_ GetAuthDataResponse message may include the following information:
resultCode ResultCode，
eUICCToken EUICCToken
step 867 is an optional step in which the terminal 110 may grant permission to the requesting user.
If the user agrees to the event or does not require the user's agreement, the terminal 110 may transmit an ES9_ uiccmanagementrequest message to the SM-SR +130 at step 869.
At this time, the ES9_ euicmanagementrequest message may include the following information:
eUICCToken EUICCToken，
certs_eUICC CERTS_eUICC
otherwise, if the user rejects the event, the terminal 110 may transmit an ES9 notifyreultrequest message to the SM-SR +130 at step 871. The ES9_ notifyreultrequest message may include an eventID corresponding to the resultCode of "3200 User _ Rejected". Since this step is the same as step 670 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted.
SM-SR +130 may validate eUICCToken at step 873.
The verification process may proceed as follows:
the SM-SR +130 may verify the CERT _ eUICC _ ECDSA using the CERT _ CI _ ECDSA stored in the SM-SR +130 and the CERT _ EUM _ ECDSA received from the terminal 110.
Thereafter, the SM-SR +130 may extract PK _ eUICC _ ECDSA from CERT _ eUICC _ ECDSA and verify sign _ eUICC using PK _ eUICC _ ECDSA. Since this step is the same as step 648 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted.
At step 857, SM-SR +130 may validate the sign _ eUICC using the NONCE _ SR stored with the eventID.
If any of the verifications fail, the SM-SR +130 may return an error message to the terminal 110 and/or the MNO 150.
If all verifications are successful, this may mean that SM-SR +130 has successfully authenticated the eUICC 115.
SM-SR +130 may generate srToken2 at step 875.
At this time, srToken2 may include the following information:
sign_SR2SIGN_ECDSA
signature sign _ SR2 may be calculated with SK _ SR _ ECDSA. Since this step is the same as step 655 described in the embodiment of fig. 6a to 6c, a detailed description thereof is omitted here.
At step 877, the SM-SR +130 may send an ES9_ euicmanagementresponse message to the terminal 110.
The ES9_ euicmanagementresponse message may include the following information:
event OPTIONAL,/. The condition is if eventType! ═ downloadProfile (0). ANG
profilelnstallpackage OPTIONAL,/. condition is that if eventType ═ downloadProfile (0). times >
srToken2SRToken2
At step 879, the terminal 110 may send an euiccmanagementirequest message to the eUICC 115. The uiccmanagementrequest message may include event information and srToken 2.
At step 881, the eUICC115 can verify srToKen 2.
The verification process may be performed as follows: the eUICC115 can verify sign _ SR2 using PK _ SR _ ECDSA. Since this step is the same as step 658 described in the embodiment of fig. 6, a detailed description thereof is omitted.
The eUICC115 can verify sign _ SR2 using the PK _ SR _ ECDSA and NONCE _ eUICC values stored with the eventID at steps 861 and 863.
If the eventType is set to "updateCIInfo (11)" and the CIInfo includes a new CI certificate, the eUICC115 can check the signature of the same certificate with the PK _ CI _ ECDSA contained in the certificate to verify the CI certificate.
If the eventType is set to "updateFirmwareInfo (13)", the eUICC115 may validate sign _ EUM in FirmwareInfo.
If any verification fails, the eUICC115 can return an error message to the terminal 110.
If all verifications succeed, this may mean that the eUICC115 has successfully authenticated SM-SR + 130.
If srToken1 is successfully authenticated, the eUICC115 can obtain some valuable authentication information, such as the SRID for EventType, the target EID, EventID, EventType, and other parameters.
Using such information, the eUICC115 can reference eUICC policy rules (e.g., server access control and subsidy lock), profile policy rules, and other necessary rules. The eUICC can check whether the event satisfies all the rules configured in the eUICC 115.
If the event does not satisfy the above-described rules, the eUICC115 can reject the event and send a rejection reason.
If the verification of step 881 is successful, the eUICC115 can perform eUICC management as indicated by the event. The eUICC115 can perform eUICC management according to the eventType of the event.
For example, eventType may be update CIInfo.
The network may initiate an update of the CIInfo (certificate issuer information) stored in the eUICC 115.
The eUICC115 can update its CIList (certificate issuer list). If the ES10_ euicmanagementrequest.event.eventtype is set to "updateCIInfo (11)", the eUICC may update the allowed SM-SR + information defined in the CIInfo according to the ES10_ euicmanagementrequest.event.ciinfo. The allowed SM-SR + information may include information about servers (SM-SR +) capable of updating the eUICC115 to allow a particular authorized server to update the eUICC 115. The eUICC115 can retain the allowed SM-SR + information to compare this information to the received server identity information to allow updating of the eUICC's profile only if they match.
If the SRID of SM-SR +130 is Not included in the CIInfo. authorized SR of the eUICC115, the eUICC115 can omit updating the CIInfo and return an error message including information indicating "SRID _ Not _ Allowed".
Thereafter, at step 885, the eUICC115 can send an ES10_ euicmanagementresponse message to the terminal 110. The ES10_ uiccmanagementresponse message may include event result information.
At step 887, the terminal 110 may transmit an ES9 NotifyResultRequest message to the SM-SR +130, and the SM-SR +130 may transmit an ES9 NotifyResultResponse message to the terminal 110 as a reply to the message. Since these steps are the same as steps 670 and 671 described in the embodiment of fig. 6a to 6c, detailed description thereof is omitted here.
Step 892 is an optional step wherein if the entType is set to "enableProfile (1)" or "disableprofiler (2)", the eUICC115 may send a Terminal REFRESH (Terminal REFRESH) message (UICC reset) to the Terminal 110.
If eventType is set to "enableProfile (1)" and the ES10_ uiccmanagementresponse message indicates that the profile has been successfully enabled, the terminal 110 may perform a REFRESH (UICC reset) operation to disconnect from the current network and reconnect to a new MNO network using the enabled profile. (the terminal 110 may successfully send the result notification to the SM-SR +130 and perform the REFRESH operation itself without receiving a REFRESH proactive command from the eUICC 115. thus, the eUICC115 may not send a REFRESH command to the terminal 110 even after the profile is enabled).
At step 890, the SM-SR +130 may send an ES4_ notifyreultrequest message to the MNO 150. The ES4_ notifyreultrequest may include an eventersult generated by the eUICC115, and at step 820, the eventersult may indicate the result of the management event initiated by the eUICC 115. The EUM certificate and CERT _ EUM _ ECDSA sent with the eventsult may be certificates linked to CI certificates stored by MNO 150 for use by MNO 150 in verifying the eUICC signature. Since the ES4_ notifyreultrequest message is described with respect to steps 670 and 683 of fig. 6, a detailed description thereof is omitted here.
Thereafter, MNO 150 may reply to the next TLV at step 891. If the MNO 150 does not know the eventID in the eventResult, the MNO 150 can send a failure message including the resultCode to the SM-SR + 130.
The ES4_ notifyreultresponse message sent from the MNO 150 to the SM-SR +130 may include the following information:
resultCode ResultCode
if the ES9_ notifyreultrequest message transmitted by the terminal 110 indicates that the event is successfully completed, the SM-SR +130 may transmit an ES12_ deleteteeventrequest message including an EventID to the SM-DS 140. SM-DS140 may then delete the EventID and related parameters stored at step 830 from its database.
The ES12_ DeleteEventRequest message may include the following information:
eventID EventID
next, at step 895, SM-DS140 may reply with the next TLV. If the SM-DS140 does not know the eventID included in the ES12_ DeleteEventRequest message, the SM-DS140 may transmit a failure message including the resultCode to the SM-SR + 130.
Meanwhile, the ES12_ DeleteEventResponse message, which is a response message transmitted from the SM-DS140 to the SM-SR +130, may include the following information:
resultCode ResultCode
fig. 9 is a block diagram showing a configuration of a terminal according to an embodiment of the present invention.
Referring to fig. 9, a terminal 110 according to an embodiment of the present invention may include a transceiver 920 and a control unit 910 for controlling the overall operation of the terminal 110. The terminal 110 may also include an eUICC 115. The eUICC115 can be included in the control unit 910, as depicted in the figure, or implemented as a separate component from the control unit 910. The eUICC115 can be implemented as a network entity separate from the terminal 110.
The control unit 910 controls the terminal 110 to perform the operation of one of the above-described embodiments. For example, the control unit 910 may control the terminal 110 to: transmitting a first message including information about a profile to be received from the profile providing server 120; receiving a second message from the profile providing server 120, the second message including information indicating whether the user's encryption code input is required and the first modified encryption code; generating a second modified encryption code when the first modified encryption code is successfully authenticated; transmitting a third message to the profile providing server 120, the third message including the second modified encryption code and information requesting the profile download; and receives a fourth message including information on the profile from the profile providing server 120.
The transceiver 920 of the terminal 110 may transmit/receive signals according to the operation of one of the above-described embodiments. For example, the transceiver 920 of the terminal 110 may transmit a first message including information about the profile to the server 120. The transceiver 920 may also receive a fourth message including information on the profile from the profile providing server 120.
Fig. 10 is a block diagram illustrating a configuration of SM-DP + according to an embodiment of the present invention.
Referring to fig. 10, the SM-DP +120 according to an embodiment of the present invention may include a transceiver 1020 and a control unit 1010 for controlling the overall operation of the SM-DP + 120.
The control unit 1010 controls the SM-DP +120 to perform the operation of one of the above-described embodiments. For example, the control unit 1010 of SM-DP +120 may control SM-DP + 120: receiving a first message including information on a profile to be received from the terminal 110; generating a first modified encryption code for authenticating the profile providing server; transmitting a second message including information indicating whether the user's encryption code input is required and the first modified encryption code; receiving a third message including the second modified encryption code and information requesting profile download from the terminal 110; and transmitting a fourth message including information about the profile when the second modified encryption code is successfully authenticated.
The transceiver 1020 of the SM-DP +120 may transmit/receive signals according to the operation of one of the above-described embodiments. For example, the transceiver 1020 of the SM-DP +120 may receive a message including information about a profile to be received by the terminal 110 from the terminal 110 and provide the corresponding profile to the terminal 110.
Fig. 11 is a block diagram illustrating a configuration of an SM-SR + according to an embodiment of the present invention.
Referring to fig. 11, the SM-SR +130 according to an embodiment of the present invention may include a transceiver 1120 and a control unit 1110 for controlling the overall operation of the SM-SR + 130.
The control unit 1110 controls the SM-SR +130 to perform the operation of one of the above-described embodiments. For example, the control unit 1110 may control the SM-SR +130 to transmit a message including information requesting profile download or profile management.
The transceiver 1120 of the SM-SR +130 may transmit/receive a signal according to the operation of one of the above-described embodiments. For example, the transceiver 1120 may transmit a message including information requesting profile download or profile management.
Fig. 12 is a block diagram illustrating a configuration of an SM-DS according to an embodiment of the present invention.
Referring to fig. 12, the SM-DS140 according to an embodiment of the present invention may include a transceiver 1220 and a control unit 1210 for controlling the overall operation of the SM-DS 140.
The control unit 1210 controls the SM-DS140 to perform an operation according to one of the above-described embodiments. For example, the control unit 1210 may control the SM-DS140 to receive a message including information requesting profile download or profile management from the SM-SR + 130.
The transceiver 1220 of the SM-DS140 may transmit/receive signals according to the operation of one of the above-described embodiments. For example, the transceiver 1220 may receive a message including information requesting profile download or profile management from the SM-SR + 130.
While various embodiments of the present invention have been described using specific terms, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, to assist in understanding the present invention. It will be evident to those skilled in the art that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention.
While various embodiments of the present invention have been described using specific terms, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense, to assist in understanding the present invention. It will be evident to those skilled in the art that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention.

Claims (15)

1. A method performed by a terminal, the method comprising:
sending a first message to a profile providing server, the first message including a first challenge value for profile providing server authentication;
receiving a second message from the profile providing server as a response to the first message, the second message including first data and a first signature value calculated on the first data, wherein the first data includes a first challenge value and a second challenge value for authentication of the terminal;
transmitting a third message generated after the first signature value is verified to the profile providing server, the third message including second data and a second signature value calculated on the second data, wherein the second data includes the second challenge value and the profile mapping information;
receiving a fourth message from the profile providing server in response to the third message, the fourth message including unencrypted profile-related information and information indicating whether the profile requires a confirmation code;
receiving a confirmation code via the user interface if the information indicates that the confirmation code is required;
transmitting a fifth message for requesting profile data to the profile providing server, the fifth message including a hashed confirmation code calculated based on the confirmation code; and
in response to the fifth message, a sixth message including encrypted profile data is received from the profile providing server.
2. The method of claim 1, wherein the fifth message includes third data and a third signature value computed over the third data, and
wherein the third data comprises a hashed validation code.
3. The method of claim 1, wherein receiving a fourth message comprises:
receiving a fourth message from the profile providing server, the fourth message comprising unencrypted information about the profile, fourth data and a fourth signature value calculated over the fourth data and the second signature value, wherein the fourth data comprises information indicating whether a confirmation code is required.
4. The method of claim 1, wherein receiving an acknowledgement code further comprises:
displaying information requesting the user to input a confirmation code and profile information contained in the unencrypted profile-related information, and
wherein the method further comprises:
receiving, via a user interface, information indicating that a user declines a profile download; and
information is sent to the profile providing server indicating that the user refuses the profile download.
5. A method performed by a profile providing server, the method comprising:
receiving a first message from the terminal, the first message including a first challenge value for profile provisioning server authentication;
generating first data comprising a first challenge value and a second challenge value for authentication associated with the terminal, and calculating a first signature value on the first data;
sending a second message to the terminal in response to the first message, the second message including the first data and the first signature value;
receiving a third message from the terminal, the third message including second data and a second signature value calculated on the second data, wherein the second data includes a second challenge value and profile mapping information;
verifying the second signature value;
determining whether a profile verified by the profile mapping information requires a confirmation code;
sending a fourth message to the terminal in response to the third message, the fourth message including unencrypted information about the profile and information indicating whether the profile requires an acknowledgment code;
receiving a fifth message requesting profile data from the terminal in case the information indicates that the confirmation code is required, the fifth message comprising a hashed confirmation code calculated based on the confirmation code; and
in response to the fifth message, a sixth message is sent to the terminal, the sixth message including the encrypted profile data.
6. The method of claim 5, wherein receiving a fifth message comprises:
receiving a fifth message from the terminal, the fifth message including third data and a third signature value calculated on the third data, wherein the third data includes a hashed confirmation code calculated based on the confirmation code;
calculating an expected hash value using the source hash confirmation code;
verifying that the received hash confirmation code matches the expected hash value; and
in the event that the received hashed validation code matches the expected hash value, a sixth message is generated that includes the encrypted profile data.
7. The method of claim 5, wherein transmitting the fourth message comprises:
sending a fourth message to the terminal, the fourth message comprising unencrypted profile-related information, fourth data, and a fourth signature value computed over the fourth data and the second signature value, wherein the fourth data comprises information indicating whether a confirmation code is required.
8. The method of claim 5, further comprising:
information is received from the terminal indicating that the user refuses profile download.
9. A terminal, comprising:
a transceiver; and
a controller configured to:
sending a first message to a profile providing server via a transceiver, the first message including a first challenge value for profile providing server authentication,
receiving, via the transceiver, a second message from the profile providing server as a response to the first message, the second message including first data and a first signature value calculated on the first data, wherein the first data includes a first challenge value and a second challenge value for authentication associated with the terminal,
transmitting, via the transceiver, a third message generated after the first signature value is verified to the profile providing server, the third message including second data and a second signature value calculated on the second data, wherein the second data includes the second challenge value and the profile mapping information,
receiving, via the transceiver, a fourth message from the profile providing server in response to the third message, the fourth message including unencrypted profile-related information and information indicating whether the profile requires a confirmation code,
in case the information indicates that a confirmation code is required, the confirmation code is received via the user interface,
sending a fifth message for requesting profile data to the profile providing server via the transceiver, the fifth message comprising a hashed confirmation code calculated based on the confirmation code, an
In response to the fifth message, a sixth message including encrypted profile data is received from the profile providing server via the transceiver.
10. The terminal of claim 9, wherein the fifth message includes third data and a third signature value calculated on the third data, and
wherein the third data comprises a hashed validation code.
11. The terminal of claim 9, wherein the controller is further configured to:
receiving, via the transceiver, a fourth message from the profile providing server, the fourth message including unencrypted information related to the profile, fourth data, and a fourth signature value calculated over the fourth data and the second signature value, wherein the fourth data includes information indicating whether a confirmation code is required.
12. The terminal of claim 9, wherein the controller is further configured to:
displaying information requesting the user to input a confirmation code and profile information contained in the unencrypted profile-related information, and
wherein the controller is further configured to:
receiving information via the user interface indicating that the user refuses profile download, and
information is sent to the profile provisioning server via the transceiver indicating that the user refuses profile download.
13. A profile providing server comprising:
a transceiver; and
a controller configured to:
receiving a first message from the terminal via the transceiver, the first message including a first challenge value for profile provisioning server authentication,
generating first data comprising a first challenge value and a second challenge value for authentication associated with the terminal, and computing a first signature value on the first data,
sending, via the transceiver, a second message to the terminal in response to the first message, the second message comprising the first data and the first signature value,
receiving, via the transceiver, a third message from the terminal, the third message including second data and a second signature value computed over the second data, wherein the second data includes a second challenge value and profile mapping information,
the second signature value is verified and the second signature value,
determining whether the profile verified by the profile mapping information requires a confirmation code,
sending a fourth message to the terminal via the transceiver in response to the third message, the fourth message comprising unencrypted information about the profile and information indicating whether the profile requires an acknowledgement code,
receiving a fifth message requesting profile data from the terminal via the transceiver in case the information indicates that a confirmation code is required, the fifth message comprising a hashed confirmation code calculated based on the confirmation code, and
in response to the fifth message, a sixth message is sent to the terminal via the transceiver, the sixth message including the encrypted profile data.
14. The profile providing server of claim 13, wherein the controller is further configured to:
receiving, via the transceiver, a fifth message from the terminal, the fifth message comprising third data and a third signature value computed over the third data, wherein the third data comprises a hashed confirmation code computed based on the confirmation code,
calculating an expected hash value using the source hash confirmation code;
verifies that the received hash confirmation code matches the expected hash value, and
in the event that the received hashed validation code matches the expected hash value, a sixth message is generated that includes the encrypted profile data.
15. The profile providing server of claim 13, wherein the controller is further configured to:
transmitting a fourth message to the terminal via the transceiver, the fourth message comprising unencrypted profile-related information, fourth data and a fourth signature value calculated over the fourth data and the second signature value, wherein the fourth data comprises information indicating whether an acknowledgement code is required, and
wherein the controller is further configured to:
information is received from the terminal via the transceiver indicating that the user refuses profile download.
CN201680052315.8A 2015-08-31 2016-08-31 Method and apparatus for downloading profiles in a communication system Active CN108028758B (en)

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 (en) 2015-08-31 2016-08-31 Method and device for downloading profile in communication system

Publications (2)

Publication Number Publication Date
CN108028758A CN108028758A (en) 2018-05-11
CN108028758B true CN108028758B (en) 2021-06-25

Family

ID=58104502

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680052315.8A Active CN108028758B (en) 2015-08-31 2016-08-31 Method and apparatus for downloading profiles in a communication system

Country Status (5)

Country Link
US (2) US10368240B2 (en)
EP (2) EP3346637B1 (en)
KR (1) KR102623524B1 (en)
CN (1) CN108028758B (en)
WO (1) WO2017039320A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220132300A1 (en) * 2018-08-07 2022-04-28 Samsung Electronics Co., Ltd. Method, apparatus, and system for authorizing remote profile management

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102284954B1 (en) * 2015-04-08 2021-08-03 삼성전자 주식회사 Method and apparatus for downloading a profile in a wireless communication system
CN107182048B (en) * 2016-03-10 2021-06-25 中兴通讯股份有限公司 Method and device for realizing sharing of user identification card by multiple terminals
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
JP6933221B2 (en) * 2016-10-04 2021-09-08 日本電気株式会社 Embedded SIM management system, node device, embedded SIM management method, program, information registrant device
EP3852415B1 (en) * 2016-10-20 2024-07-31 Huawei Technologies Co., Ltd. Method and apparatus for managing embedded universal integrated circuit card euicc
EP4203532A1 (en) * 2016-10-31 2023-06-28 Huawei Technologies Co., Ltd. Profile download method and device
US10667123B2 (en) * 2016-11-22 2020-05-26 Huawei Technologies Co., Ltd. Method for installing subscription profile, terminal, and server
KR20180071679A (en) * 2016-12-20 2018-06-28 삼성전자주식회사 User terminal apparatus and controlling method of thereof
WO2018129724A1 (en) * 2017-01-13 2018-07-19 华为技术有限公司 Subscription profile download method, device and server
FR3065140A1 (en) * 2017-04-07 2018-10-12 Orange METHOD FOR OBTAINING A CONTROL RELATING TO A PROFILE OF ACCESS TO A NETWORK
US11070355B2 (en) * 2017-06-30 2021-07-20 Apple Inc. Profile installation based on privilege level
EP3704884B1 (en) * 2017-11-01 2022-06-15 Telefonaktiebolaget LM Ericsson (PUBL) Management of a subscriber entity
CN109802826B (en) * 2017-11-17 2021-10-01 华为技术有限公司 Event processing method and terminal
CN107911224B (en) * 2017-11-28 2019-04-02 恒宝股份有限公司 The continuous card method and system of universal embedded integrated circuit card
KR102382894B1 (en) * 2017-11-28 2022-04-05 삼성전자주식회사 Apparatus and method for managing events in communication system
WO2019119267A1 (en) * 2017-12-19 2019-06-27 华为技术有限公司 Profile management method, embedded universal integrated circuit card and terminal
CN108200568B (en) * 2017-12-26 2020-12-08 中国联合网络通信集团有限公司 Mobile communication electronic SIM card data processing method and device
EP3741145B1 (en) 2018-01-15 2022-11-09 Telefonaktiebolaget LM Ericsson (publ) Profile handling of a communications device
JP6541816B1 (en) * 2018-02-23 2019-07-10 Kddi株式会社 Communication control apparatus, communication setting method, communication setting program and communication system
DE102018207161B4 (en) 2018-05-08 2022-05-05 Bayerische Motoren Werke Aktiengesellschaft Communication in a cellular network
EP3592015A1 (en) * 2018-07-02 2020-01-08 Soracom International, Pte. Ltd Updating a subscriber identity module
KR102511365B1 (en) * 2018-08-24 2023-03-17 삼성전자주식회사 Method and apparatus for biometrics
CN112913204A (en) * 2018-09-14 2021-06-04 品谱股份有限公司 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 (en) * 2018-12-26 2019-05-03 北京字节跳动网络技术有限公司 Information interacting method, device, electronic equipment and computer readable storage medium
US10771943B1 (en) * 2019-02-19 2020-09-08 Microsoft Technology Licensing, Llc Privacy-enhanced method for linking an eSIM profile
KR102658615B1 (en) * 2019-02-22 2024-04-18 삼성전자 주식회사 Method for ssp device to interoperate between bundle donwload procedure and profile donwload procedure
EP3912369A4 (en) * 2019-02-22 2022-03-30 Samsung Electronics Co., Ltd. Method for interoperating between bundle download process and esim profile download process by ssp terminal
CN113785532B (en) * 2019-05-09 2024-02-02 三星电子株式会社 Method and apparatus for managing and verifying certificates
CN110267253B (en) * 2019-05-13 2022-09-27 中国联合网络通信集团有限公司 eSIM management platform, eSIM installation method and device
CN110262813B (en) * 2019-06-25 2020-11-17 上海连尚网络科技有限公司 Method and apparatus for installing applications
WO2021001034A1 (en) * 2019-07-03 2021-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Part 2 of remote sim provisioning of a subscriber entity
WO2021034048A1 (en) * 2019-08-16 2021-02-25 삼성전자 주식회사 Method and device for moving bundle between devices
US10880711B1 (en) 2020-02-25 2020-12-29 Sprint Communications Company L.P. Electronic subscriber identity module (eSIM) management platform
US11856398B2 (en) 2020-04-02 2023-12-26 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
US12081969B2 (en) * 2020-09-15 2024-09-03 Motorola Solutions, Inc. Device agnostic remote eSIM provisioning
CN112702776B (en) * 2020-12-15 2023-03-21 锐捷网络股份有限公司 Method for realizing wireless terminal access to wireless local area network and wireless access point
WO2022186606A1 (en) * 2021-03-04 2022-09-09 주식회사 센스톤 Device and method for providing update of encryption key on basis of authentication virtual code
EP4057661A1 (en) * 2021-03-09 2022-09-14 Kigen (UK) Limited System, module, circuitry and method
US12127305B2 (en) * 2021-05-10 2024-10-22 Apple Inc. Off-line profile provisioning for wireless devices
US20230054892A1 (en) * 2021-08-20 2023-02-23 Samsung Electronics Co., Ltd. Method and device for providing event in wireless communication system

Family Cites Families (25)

* Cited by examiner, † Cited by third party
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
KR100499122B1 (en) * 2000-03-29 2005-07-04 삼성전자주식회사 System for authentication using a password and method thereof
CN1567294A (en) * 2003-06-14 2005-01-19 华为技术有限公司 User certification method
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 (en) * 2006-03-02 2006-08-02 韩林 Two-factor dynamic cipher verification method and system
EP2039199B1 (en) * 2006-07-06 2018-10-31 Nokia Technologies Oy User equipment credential system
JP2011257954A (en) * 2010-06-08 2011-12-22 Sony Corp Update management server, electronic device, update management system having the server and the device, and method of the system
EP2637351A4 (en) * 2010-11-04 2016-09-07 Zte Corp Method and system for single sign-on
EP2461613A1 (en) * 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
WO2012104477A1 (en) * 2011-01-31 2012-08-09 Nokia Corporation Subscriber identity module provisioning
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 (en) 2011-07-08 2013-01-16 주식회사 케이티 Method for changing mno of embedded sim based on dynamic key generation, embedded sim and recording medium for the same
DE102011118367B4 (en) * 2011-08-24 2017-02-09 Deutsche Telekom Ag Method for authenticating a telecommunication terminal comprising an identity module at a server device of a telecommunication network, use of an identity module, identity module and computer program
KR101986312B1 (en) * 2011-11-04 2019-06-05 주식회사 케이티 Method for Creating Trust Relationship and Embedded UICC
KR101330867B1 (en) 2012-12-27 2013-11-18 신한카드 주식회사 Authentication method for payment device
US20140289366A1 (en) * 2013-03-20 2014-09-25 Korea Advanced Institute Of Science And Technology Service providing method and system for instance hosting
EP2802162A1 (en) * 2013-05-07 2014-11-12 Gemalto SA Method for accessing a service, corresponding device and system
CN103259663A (en) * 2013-05-07 2013-08-21 南京邮电大学 User unified authentication method in cloud computing environment
KR102138315B1 (en) 2013-05-30 2020-07-27 삼성전자주식회사 Method and Apparatus for Provisioning Profile
BR112016000122B1 (en) 2013-07-05 2022-11-01 Sgx As METHOD AND SYSTEM RELATED TO USER AUTHENTICATION TO ACCESS DATA NETWORKS
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
US9100175B2 (en) * 2013-11-19 2015-08-04 M2M And Iot Technologies, Llc Embedded universal integrated circuit card supporting two-factor authentication
CN107005837B (en) * 2014-11-17 2020-12-18 三星电子株式会社 Apparatus and method for profile installation in a communication system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220132300A1 (en) * 2018-08-07 2022-04-28 Samsung Electronics Co., Ltd. Method, apparatus, and system for authorizing remote profile management

Also Published As

Publication number Publication date
KR102623524B1 (en) 2024-01-10
US11039311B2 (en) 2021-06-15
EP3346637B1 (en) 2019-10-23
CN108028758A (en) 2018-05-11
US20190357046A1 (en) 2019-11-21
KR20180037220A (en) 2018-04-11
US20170064552A1 (en) 2017-03-02
EP3346637A4 (en) 2018-09-05
WO2017039320A1 (en) 2017-03-09
EP3618478A1 (en) 2020-03-04
US10368240B2 (en) 2019-07-30
EP3618478B1 (en) 2021-08-11
EP3346637A1 (en) 2018-07-11

Similar Documents

Publication Publication Date Title
CN108028758B (en) Method and apparatus for downloading profiles in a communication system
CN107580790B (en) Method and apparatus for providing a profile
CN110870281B (en) Method and apparatus for discussion of digital certificates by ESIM terminals and servers
EP3297309B1 (en) Technique for managing profile in communication system
US11496883B2 (en) Apparatus and method for access control on eSIM
KR102398276B1 (en) Method and apparatus for downloading and installing a profile
CN111406397B (en) Method and apparatus for managing events in a communication system
CN118632229A (en) Method, apparatus and system for authorizing remote profile management
CN112567772B (en) Method, apparatus and system for authorizing remote profile management

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant