WO2013066016A1 - 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ - Google Patents

신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ Download PDF

Info

Publication number
WO2013066016A1
WO2013066016A1 PCT/KR2012/008970 KR2012008970W WO2013066016A1 WO 2013066016 A1 WO2013066016 A1 WO 2013066016A1 KR 2012008970 W KR2012008970 W KR 2012008970W WO 2013066016 A1 WO2013066016 A1 WO 2013066016A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
trust
euicc
verification
verification information
Prior art date
Application number
PCT/KR2012/008970
Other languages
English (en)
French (fr)
Inventor
이진형
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020120120292A external-priority patent/KR101986312B1/ko
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to US14/356,037 priority Critical patent/US9426654B2/en
Publication of WO2013066016A1 publication Critical patent/WO2013066016A1/ko
Priority to US15/216,917 priority patent/US10091653B2/en
Priority to US15/962,469 priority patent/US10462668B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to a method for forming a trust relationship between entities in a communication system including a built-in UICC, and a built-in UICC for the same.
  • a UICC Universal Integrated Circuit Card
  • the UICC may store the personal information of the user and the operator information on the mobile communication provider to which the user subscribes.
  • the UICC may include an International Mobile Subscriber Identity (IMSI) for identifying a user.
  • IMSI International Mobile Subscriber Identity
  • the UICC is also called a Subscriber Identity Module (SIM) card in the case of the Global System for Mobile communications (GSM) scheme, and a Universal Subscriber Identity Module (USIM) card in the case of the Wideband Code Division Multiple Access (WCDMA) scheme.
  • SIM Subscriber Identity Module
  • GSM Global System for Mobile communications
  • USBMA Wideband Code Division Multiple Access
  • the user mounts the UICC on the user's terminal
  • the user is automatically authenticated using the information stored in the UICC so that the user can conveniently use the terminal.
  • the user replaces the terminal the user can easily replace the terminal by mounting the UICC removed from the existing terminal to a new terminal.
  • Terminals requiring miniaturization for example, terminals for machine-to-machine (M2M) communication, have difficulty in miniaturization of terminals when manufactured in a structure capable of detachable UICC.
  • M2M machine-to-machine
  • an embedded UICC Embedded UICC
  • a removable UICC In the built-in UICC, user information using the UICC should be recorded in IMSI format.
  • the existing UICC can be attached to or detached from the terminal, and the user can open the terminal regardless of the type of terminal or the mobile communication provider.
  • the manufactured terminal can be assigned an IMSI in the embedded UICC only when the premise that the terminal is used only for a specific mobile communication provider is satisfied.
  • Both mobile operators and terminal manufacturers ordering terminals have no choice but to pay attention to product inventory, which leads to a problem that product prices rise.
  • the user is inconvenient to change the mobile operator for the terminal. Therefore, even in the case of the built-in UICC, a method for allowing a user to open the terminal regardless of the mobile communication provider is required.
  • the embedded SIM (hereinafter, eSIM and eUICC), which is integrally mounted on the terminal, has many issues regarding the authority to open, additional service business initiative, and subscriber information security due to differences in its physical structure. do.
  • the international standardization bodies of GSMA and ETSI are conducting standardization activities on the necessary elements, including top-level structures, with relevant companies such as operators, manufacturers and SIM vendors.
  • eSIM is discussed through standardization organizations, the central point of the issue is SM called Subscription Manager, which is responsible for the overall management of eSIM by issuing operator credentials to eSIM and handling the process of subscription changes. Or its function / role.
  • GSMA Global System for Mobile Communications
  • SM-DP Data Preparation
  • SM-SR Secure Routing
  • the present invention proposes a method of forming a trust relationship between entities in the GSMA proposed eSIM environment.
  • An object of the present invention is to provide a method for forming a trust relationship between each entity or entity in a communication system including a built-in UICC.
  • Another object of the present invention is to provide a method for forming a trust relationship between entities or entities in a communication system in which an SM is defined as an entity for managing an eUICC.
  • Still another object of the present invention is a method of using trust information that is specifically defined to form a trust relationship between an entity such as an MNO, SM, eUICC, terminal, or entity in a communication system in which an SM is defined as an entity for managing an eUICC. And so on.
  • the present invention is a method for forming a trust relationship between an embedded Universal Integrated Circuit Card (eUICC) and a Subscription Manager-Secure Routing (SM-SR), and generates verification information based on trust information received or shared by the eUICC.
  • Generating verification information Verification information that the eUICC transmits the generated verification information to the SM-SR as information for the SM-SR to authenticate the eUICC, and receives verification information generated by the SM-SR from the SM-SR.
  • Exchange step And a verification information verification step of authenticating the SM-SR by verifying verification information received from the SM-SR by the eUICC based on the trust information.
  • the present invention is an embedded Universal Integrated Circuit Card (eUICC) for establishing a trust relationship with a subscription manager-secure routing (SM-SR), and the verification information is based on the received or shared trust information or the respective private key.
  • Generating verification information generation unit Verification information that the eUICC transmits the generated verification information to the SM-SR as information for the SM-SR to authenticate the eUICC, and receives verification information generated by the SM-SR from the SM-SR.
  • Exchange unit And an verification information verification unit for authenticating the SM-SR by verifying verification information received from the SM-SR by the eUICC based on the trust information.
  • the present invention provides a method of establishing a trust relationship between a plurality of entities in a communication system, the method comprising: generating verification information based on trust information shared or shared by each of the plurality of entities; Exchanging, by each of the plurality of entities, respective generated verification information to the counterpart entity; And each of the plurality of entities authenticating the counterpart entity by verifying verification information received from the counterpart entity based on the trust information to form a trust relationship between the plurality of entities. .
  • Each SM-SR generates the verification information based on the received or shared trust information and transmits the verification information to the other party, and verifies the verification information received from the other party based on the trust information to authenticate the other party.
  • SM-SR and SM-DP Subscribescription Manager-Data Preparation
  • SM-SR and SM-DP each generate verification information based on the received or shared trust information and transmit the verification information to the other party, and verify verification information received from the other party based on the trust information.
  • It provides a trust relationship forming method comprising the step of establishing a trust relationship between the SM-SR and SM-DP for authenticating the other party.
  • Figure 1 shows the overall service architecture including the eSIM (eUICC) to which the present invention is applied.
  • eSIM eUICC
  • FIG. 2 shows a system architecture of an SM separation environment to which the present invention may be applied.
  • FIG. 3 is an overall flowchart of a provisioning process in a service architecture to which the present invention is applied.
  • FIG. 4 is an overall flowchart of a subscription change or MNO change process to which the present invention is applied.
  • FIG. 5 illustrates an example of a structure for forming trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • FIG. 6 illustrates an example of a flow of trust relationship formation between entities in an eUICC environment according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a method for forming a trust relationship between an eUICC and an SM-SR during the establishment of a trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • FIG. 8 is a block diagram of an eUICC for establishing a trust relationship between an eUICC and an SM-SR during the establishment of a trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • M2M (Machine-to-Machine) terminal which is actively discussed in the current GSMA, should be small in size.
  • a module for attaching the UICC to the M2M terminal must be separately inserted. If the M2M terminal is manufactured, it is difficult to miniaturize the M2M terminal.
  • the eUICC mounted on the M2M terminal includes information on a mobile network operator (hereinafter referred to as 'MNO') that uses the UICC. It must be stored in the UICC in the form of an identifier (International Mobile Subscriber Identity, IMSI).
  • IMSI International Mobile Subscriber Identity
  • the terminal manufactured from the time of manufacturing the M2M terminal can be assigned IMSI in the eUICC only if the premise that the terminal is used only in a specific MNO is established, both the M2M terminal or the MNO ordering the UICC or the M2M manufacturer manufacturing the M2M terminal have a lot of attention to the product inventory. There is a problem that can not only be assigned to the product price will rise, which is a big obstacle to the expansion of M2M terminal.
  • the built-in SIM (hereinafter, referred to as eSIM or eUICC) that is integrally mounted on the terminal has many issues regarding the authority to open, additional service business initiative, and subscriber information security due to the physical structure difference.
  • eSIM the built-in SIM
  • the international standardization bodies of the GSMA and ETSI are conducting standardization activities on relevant elements such as operators, manufacturers, SIM vendors (Vendors), and other necessary elements, including top-level structures.
  • SM is at the center of issues as eSIM is discussed through standardization bodies, and issues an important profile (which can be called Operator Credential, MNO Credential, Profile, eUICC Profile, Profile Package, etc.) to eSIM and initiates the process of changing subscriptions. It refers to an entity or a function / role that plays an overall administrative role for eSIM, such as processing.
  • GSMA has proposed a structure that classifies SM into SM-DP (Data Preparation), which plays a role in generating operator information, and SM-SR (Secure Routing), which carries carrier information directly to eSIM. It does not mention the technical actual issuance method.
  • SM-DP Data Preparation
  • SM-SR Secure Routing
  • the present invention proposes a method for managing eSIM by utilizing dynamic encryption key (public key, etc.) generation in the SM role separation environment of GSMA.
  • eSIM attaches the IC chip on the terminal circuit board at the terminal manufacturing stage, and then attaches the SIM data (open information, additional service information, etc.) in software form to OTA (Over The Air) or offline (technology-based connection such as USB to PC). Is a new concept of SIM technology in the manner of issuing through.
  • IC chips used in eSIM generally support hardware-based Crypto Co-Processor (CCP) to provide hardware-based public key generation, and APIs that can be utilized in application (eg applet) based SIM platform (eg , Java Card Platform, etc.).
  • Java Card Platform Java Card Platform is one of the platforms that can provide services and load multiple applications, such as smart cards.
  • SIM requires a SIM service management platform that is responsible for loading and managing applications.
  • the SIM service management platform issues data to the SIM memory area through authentication and security with management keys.
  • the Global Platform and Remote File Management (RFM) and RAM (Remote Application Management) of ETSI TS 102.226 It is a standard technology of the service management platform.
  • eSIM is responsible for issuing communication and additional service data remotely through management keys (UICC OTA Key, GP ISD Key, etc.).
  • management keys UICC OTA Key, GP ISD Key, etc.
  • the management key or the eSIM management key or the eUICC management key is an access authentication key to the eSIM for safely delivering the operator information to the eSIM, and is a concept distinct from the encryption key (public key, etc.) mainly dealt with in the present invention. As described below, it may be expressed as eUICC access credentials.
  • SM-DP securely builds IMSI, K, OPc, additional service applications, additional service data, etc. in addition to the operation profile (or operator information) to make a credential package.
  • SM-DP SR is responsible for securely downloading the credential package generated by SM-DP to eSIM through SIM remote management technology such as Over-The-Air (OTA) or GP Secure Communication Protocol (GP SCP).
  • OTA Over-The-Air
  • GP SCP GP Secure Communication Protocol
  • MNO1 is SM1
  • SM1 is SM4
  • SM4 forms a trust relationship with the eSIM, thereby forming a trust relationship between the MNO and eSIM.
  • a mobile network operator refers to a mobile communication operator, and refers to an entity that provides a communication service to a customer through a mobile network.
  • a subscription manager is a subscription management device and performs a management function of an eUICC.
  • eUICC Supplier means a person who supplies eUICC module and embedded software (firmware and operating system, etc.).
  • Device Vendor includes a device's provider, in particular a wireless modem function via a mobile network driven by the MNO, and consequently means a supplier of a device requiring a UICC (or eUICC) form.
  • a device's provider in particular a wireless modem function via a mobile network driven by the MNO, and consequently means a supplier of a device requiring a UICC (or eUICC) form.
  • Provisioning refers to a process of loading a profile into an eUICC
  • a provisioning profile refers to a profile used by a device to connect to a communication network for the purpose of provisioning another provisioning profile and an operation profile.
  • Subscription means a commercial relationship for providing a service between a subscriber and a wireless communication service provider.
  • eUICC access credentials refer to data in the eUICC that allows secure communication between the eUICC and external entities to be set up to manage profiles on the eUICC.
  • Profile access credentials are data that resides within a profile or within an eUICC, and means data that allows secure communications to be set up between the eUICC and external entities to protect or manage the profile structure and its data. .
  • a profile is a combination of file structures, data, and applications that can be provisioned or managed within an eUICC. It is a combination of operator information, operation profiles, provisioning profiles for provisioning, and other policy control functions (PCFs). It means all information that can exist in eUICC such as profile.
  • PCFs policy control functions
  • Operation Profile or operator information refers to all kinds of profiles related to Operational Subcription.
  • Figure 1 shows the overall service architecture including the eSIM (eUICC) to which the present invention is applied.
  • eSIM eUICC
  • the eUICC system architecture to which the present invention can be applied may include a plurality of MNO systems, one or more SM systems, an eUICC manufacturer system, a device manufacturer system including an eUICC, an eUICC, and the like for each entity or subject.
  • MNO systems one or more SM systems
  • eUICC manufacturer system an eUICC manufacturer system
  • device manufacturer system including an eUICC, an eUICC, and the like for each entity or subject.
  • the dashed line in FIG. 1 shows the trust circle, and the two solid lines represent the secure link.
  • the MNO and eUICC must be able to decode the MNO Credentials information, that is, the profile (operation profile, provisioning profile, etc.).
  • the profile operation profile, provisioning profile, etc.
  • the only exception to this could be a third party authorized by a particular MNO, for example a SIM vendor. However, it is not a general function of a third party to do this.
  • Subscriptions cannot be switched within the eUICC outside of operator policy control.
  • the user must be aware of any changes in the MNO content and its active subscription, must be able to avoid security risks, and have a level of security that is compatible with the current UICC model.
  • the MNO credential or profile may mean a subscription credential including K, algorithm, algorithm parameters, supplementary service application, supplementary service data, and the like.
  • MNO credentials or profiles must be done in a secure manner from end to end.
  • the transmission can be made in successive steps without breaking the security chain, and all steps in the transmission chain must be made under the recognition and approval of the MNO.
  • No entity in the transport chain should be able to clearly see the MNO credential, but the only exception may be a third party authorized by a particular MNO, for example a SIM vendor. However, it is not a general function of a third party to do this.
  • the operator must have complete control over his credentials and the operator must have strong supervision and control over the SM operation.
  • SM functions must be provided by the MNO or a third party, if provided by the third party, there may be a commercial relationship established between the SM and the MNO.
  • the SM has no direct relationship with the MNO subscriber for subscription management.
  • the MNO has a relationship with the subscriber and should be the entry point for the customer subscription, it is not intended to piggyback on the contractual relationship an M2M service provider (the M2M service provider is an MNO subscriber) may have with its customers.
  • the donor and receiving MNOs may or may not have a prior agreement with each other. There must be a mechanism to approve pre-contracts.
  • the donor operator's policy control function can be defined for the condition of removing his / her credential, and the policy control function (PCF) can implement this function.
  • the architecture introduces a feature defined as SM, and SM's primary role is to prepare and deliver a package or profile containing the MNO credentials to the eUICC.
  • the SM function may be provided directly by the MNO, or the MNO may contract with a third party to obtain the SM service.
  • SM can be divided into two sub-functions such as SM-SR and SM-DP.
  • SM-SR and SM-DP functions may be provided by other entities or may be provided by the same entity. Therefore, it is necessary to clearly demarcate the functions of SM-DP and SM-SR, and to define an interface between these entities.
  • SM-DP is responsible for secure preparation of package or profile to be delivered to eUICC, and works with SM-SR for actual transmission.
  • the key functions of the SM-DP are 1) managing the functional characteristics and certification levels of the eUICC, and 2) one of the MNO credentials or profiles (e.g., IMSI, K, supplementary service applications, supplementary service data). Some of these are potentially managed by the MNO, and 3) the ability to calculate the OTA package for download by the SM-SR. Can be added.
  • SM-DP can have a significant amount of background processing, and the requirements for performance, scalability and reliability are expected to be important.
  • SM-SR is responsible for securely routing and delivering the credential package to the corresponding eUICC.
  • the key features of the SM-SR are 1) managing OTA communication with the eUICC via a ciphered VPN, and 2) other SM-SR to form an end-to-end up to the eUICC.
  • To manage communication with eUICC 3) to manage eUICC data used for SM-SR OTA communication provided by eUICC provider, and 4) to protect communication with eUICC by filtering only allowed entities. (Firewall function).
  • the SM-SR database is provided by eUICC vendors, device (such as M2M terminal) vendors, and potentially MNOs, and can be used by MNOs through the SM-SR mesh network.
  • the circle of trust enables end-to-end security links during provisioning profile delivery, while the SM-SR shares the trust circle for secure routing of the provisioning profile and eUICC discovery.
  • MNOs can be linked with SM-SR and SM-DP entities in a trusted circle, or they can provide this functionality themselves.
  • EUICC and MNO Credentials to prevent illegal use of eUICC (cloning, illegal use of credentials, denial of service, illegal MNO context changes, etc.) without violating MNO's contractual and legal obligations with respect to its customers. There is a need for a secure end-to-end link between.
  • 110 represents a trust circle formed between SMs, more specifically, between SM-SR members, 120 represents a trust circle of MNO partners, and 130 represents an end-to-end trust link.
  • FIG. 2 illustrates a configuration in which an SM-SR and an SM-DP are located in a system in an SM separation environment.
  • the SM is divided into an SM-DP for safely preparing various profiles (operation profile, provisioning profile, etc.) related to the eUICC, and an SM-SR for routing the SM-SR. It can be linked with the SR in a trust relationship, SM-DP is linked to the MNO system.
  • SM-DP can be linked with SM-SR and MNO system can be linked with SM-DP
  • FIG. 3 is an overall flowchart of a provisioning process corresponding to a first subscription in a system to which the present invention is applied.
  • the eUICC transmits an activation request including device identification information (IMEI, etc.) and eUICC identification information (eICCid, etc.) to the MNO. (Request activation; S310) Then, in step S320, the eUICC is transmitted between the MNO and the eUICC. Status request and technical capability control request / confirmation are performed (eUICC status request and technical capability control; S320).
  • IMEI device identification information
  • eICCid eUICC identification information
  • the eUICC uses PKI key information (key generation algorithm, key length, key generation method, etc.) that is its public key (PK) or profile access credential information.
  • PKI key information key generation algorithm, key length, key generation method, etc.
  • PK public key
  • profile access credential information Providing to the MNO system or SM-SR may be included.
  • step S330 the MNO collects eUICC identity verification and information about the device (eUICC) between the SM-SR (eUICC identity verification and collect information about device).
  • the MNO may obtain an encryption key for the corresponding eUICC, specifically, a public key corresponding to the eUICC, from the SM-SR according to an embodiment of the present invention.
  • the acquisition of such a public key may be static or dynamic. If the static key is made publicly, the eUICC is already manufactured at the time of manufacture of the eUICC, and specifically disclosed through a cryptographic operation processor (CCP, etc.) in the eUICC. A key and a secret key are generated so that the eUICC stores a secret key, and the public key is shared by all SM-SRs so that the public key for a specific eUICC can be recognized. The public key for the eUICC is delivered to the MNO.
  • CCP cryptographic operation processor
  • the dynamic encryption key obtaining method when there is a request from the MNO (including specific eUICC identification information), the SM-SR requests the corresponding eUICC to transmit the public key.
  • the eUICC may be referred to as an issuing processing module (e.g., not limited to this term, a communication module, a provisioning module, an issuing module, an opening module, etc.) in an eUICC-equipped terminal, and communication and provisioning management with an external eUICC-equipped terminal for eUICC provisioning Role) or security module (e.g., encryption key generation module, encryption key processing module, security policy module, Credential Manager, Profile Manager, etc.). It can be performed by generating a public key and transferring it to the SM-SR. This will be described in more detail below.
  • one security module mounted in the eUICC may be commonly installed in the eUICC according to an eUICC manufacturing step or an eUICC policy thereafter, and a plurality of security modules may be installed for each MNO according to the eUICC policy and each MNO policy.
  • the MNO that has obtained the public key (encryption key) of the eUICC creates a new eUICC profile for the MNO through the SM-DP, encrypts the profile with the acquired eUICC public key (encryption key), and sends it to the MNO.
  • Primary encryption, step S340 In this case, in order to provide authenticity, the SM-DP may generate an additional digital signature with its own private key. That is, in step S340, the SM-DP may sign the profile with its own private key or secret key for authentication.
  • the MNO sends the primary encrypted (eUICC) profile to the SM-SR and requests secondary encryption
  • the SM-SR uses the eUICC management keys (eUICC OTA key, GP ISD key, etc.) already stored.
  • the second eUICC profile is encrypted and transferred to the MNO.
  • the MNO transmits the double ciphered eUICC profile to the corresponding eUICC (step S360).
  • the public key or certificate of the SM-DP may be transmitted to the eUICC together to provide authentication. have.
  • eUICC Since eUICC already knows eUICC management key, it decrypts first and then decrypts the profile to be used for provisioning by second decryption using the secret key corresponding to its public key (already known at the manufacturing or public key dynamic generation stage). can do. At this time, the eUICC is the SM-DP's public key (in the case of a certificate, from a trusted third party) Signature verification can be performed).
  • step S370 the SM-SR database is updated according to a status request and a response between the eUICC and the SM-SR that have finished provisioning.
  • step S310 the eUICC identification information (eICCid, etc.) is public data and must be integrated and protected inside the eUICC.
  • step S320 and S330 the status request and technical possibility control provide proof of the eUICC identity (trusted eUICC), and should be able to confirm the eligibility of the eUICC characteristic for the MNO service.
  • a double encryption mechanism is used for generating and transmitting an eUICC profile. That is, the generation profile linked to the eUICC by the SM-DP is encrypted by an encryption mechanism that can only be read by the target eUICC, and the digital signature is performed by the SM-DP to confirm that the profile is generated from a legitimate SM-DP.
  • SM-SR encrypts the generated profile with an eUICC management key to authenticate and protect the eUICC during delivery.
  • the SM-SR database may be updated at the end of the subscription installation (Subscription installation).
  • FIG. 4 is an overall flowchart of a subscription change or MNO change process to which the present invention is applied.
  • the provisioning process of FIG. 3 is similar to the provisioning process of FIG. 3 (that is, after the change, the new MNO corresponds to the MNO of FIG. 3), except that the new MNO performs negotiation and transfer of rights to the donor MNO before and after profile generation for the new MNO. (Step S440 ').
  • the difference between the MNO change process of FIG. 4 and the provisioning process of FIG. 3 is that, using a provisioning or operation active profile, an activation request is sent to a donor MNO OTA bearer, and the new MNO is either new OTA or OTI. To request a path from the SM-SR to download the profile.
  • the eUICC transmits an activation request including device identification information (IMEI, etc.) and eUICC identification information (eICCid, etc.) to the MNO (Receiving MNO) to be changed. (Request activation; S410) Then, step S420 An eUICC status request and technical capability control request / confirmation is performed between the receiving MNO and the eUICC at (eUICC status request and technical capability control; S420).
  • IMEI device identification information
  • eICCid eUICC identification information
  • step S420 the eUICC selects PKI key information (key generation algorithm, key length, key generation method, etc.) that is its public key (PK) or profile access credential information.
  • PKI key information key generation algorithm, key length, key generation method, etc.
  • PK public key
  • step S420 the eUICC selects PKI key information (key generation algorithm, key length, key generation method, etc.) that is its public key (PK) or profile access credential information.
  • PK public key
  • profile access credential information The process provided by the corresponding MNO system or SM-SR may be included as in the provisioning process S320.
  • step S430 the receiving MNO collects eUICC identity verification and information about the device (eUICC) between the SM-SR (eUICC identity verification and collect information about device).
  • the MNO may obtain an encryption key for the corresponding eUICC, specifically, a public key corresponding to the eUICC, from the SM-SR according to an embodiment of the present invention. .
  • one security module mounted in the eUICC may be commonly installed in the eUICC according to an eUICC manufacturing step or an eUICC policy thereafter, and a plurality of security modules may be installed for each MNO according to the eUICC policy and each MNO policy.
  • Receiving MNO that has obtained the public key (encryption key) of the eUICC creates a new eUICC profile for the MNO through SM-DP, encrypts the profile with the acquired eUICC public key (encryption key), and sends it to the MNO.
  • the SM-DP may generate an additional digital signature with its private key. That is, in step S440 SM-DP can digitally sign the profile with its own private key or secret key for authentication.
  • This negotiation and the right transmission step S440 ' may be performed before or after step S440.
  • This negotiation and rights transfer step (S440 ') is a process in which a new receiving MNO asks a previous MNO (donor MNO) whether the corresponding eUICC is justified, and transfers rights (information) due to the MNO change. .
  • a new MNO (Receiving MNO) requests authentication of the donor MNO for subscription switching, and this authentication may be provided by a policy control function.
  • the SM-SR stores the eUICC management key (eUICC OTA key, GP ISD key, etc.) already stored. Secondly encrypt the eUICC profile by using and transmits to the MNO.
  • eUICC management key eUICC OTA key, GP ISD key, etc.
  • the MNO transmits the double ciphered eUICC profile to the corresponding eUICC (step S460).
  • the public key or certificate of the SM-DP can be transmitted to the eUICC together to provide authentication. have.
  • eUICC Since eUICC already knows the eUICC management key, it decrypts it first, and then decrypts it with the secret key corresponding to its public key (which is already known at the manufacturing or public key dynamic generation stage), so that the profile to be used for MNO change is completely Can be decrypted At this time, the eUICC is the SM-DP's public key (in the case of a certificate, from a trusted third party) Signature verification can be performed).
  • step S470 the SM-SR database is updated according to a status request and a response between the eUICC and the SM-SR which have finished provisioning.
  • eSIM attaches the IC chip on the terminal circuit board at the terminal manufacturing stage, and then attaches the SIM data (open information, additional service information, etc.) in software form to OTA (Over The Air) or offline (technology-based connection such as USB to PC). Is a new concept of SIM technology in the manner of issuing through.
  • IC chips used in eSIM generally support hardware-based Crypto Co-Processor (CCP) to provide hardware-based public key generation, and APIs that can be utilized in application (eg applet) based SIM platform (eg , Java Card Platform, etc.).
  • CCP hardware-based Crypto Co-Processor
  • APIs that can be utilized in application (eg applet) based SIM platform (eg , Java Card Platform, etc.).
  • the Java Card Platform is one of the platforms that can provide multi-application and service in smart card.
  • SIM requires a SIM service management platform that is responsible for loading and managing applications.
  • the SIM service management platform issues data to the SIM memory area through authentication and security with management keys.
  • GlobalPlatform and ETSI TS 102.226's RFM (Remote File Management) and RAM (Remote Application Management) provide access to these SIM service management platforms. It is a standard technique.
  • SM one of the important elements in the eSIM environment, eSIM is responsible for issuing communication and additional service data through a management key remotely.
  • GSMA the roles of SM are classified into SM-DP and SM-SR.
  • SM-DP securely builds operator information (IMSI, K, OPc, additional service data, etc.) and forms Credential Package.
  • SM-SR converts Credential Package generated by SM-DP to OTA or GP SCP ( SIM remote management technology, such as Secure Communication Protocol, securely downloads to eSIM.
  • the GSMA proposed the structure of “Circle of Trust” in the figure below, and proposed the concept of establishing an end-to-end trust relationship between MNO and eSIM by overlapping trust relationships among similar entities.
  • MNO is SM1
  • SM1 is SM4
  • SM4 forms a trust relationship with the eSIM, thereby forming a trust relationship between the MNO and eSIM.
  • the SMA separation environment proposed by the GSMA secures business leadership along with appropriate flexibility in the eSIM environment that can deprive SM of all business initiatives through SM-SR.
  • SM-DP role is generally expected to be performed by the MNO, the carrier information of the communication and additional services are built through the SM-DP) has the advantage that can be accompanied.
  • an embodiment of the present invention proposes a method of forming a trust relationship between each entity in the proposed eSIM structure.
  • the present invention is not limited to the provisioning or MNO change process according to FIGS. 3 and 4 described above, as long as a trust relationship can be established between entities related to the eUICC using the trust information defined in the present invention. This could apply to any other environment or system.
  • FIG. 5 illustrates an example of a structure for forming trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • the entity participating in the eSIM structure is an eSIM, an eSIM-equipped device, an SM (SM-SR, SM-DP, etc.) and an MNO, and other components may participate.
  • SM SM-SR, SM-DP
  • SM-SR SM-SR
  • SM-DP SM-DP
  • trust information e.g. certificate, etc.
  • HSM Hardware Security Module
  • eUICC and eUICC-equipped devices store trust information (e.g. certificates) inside each object (not separate objects, such as security devices such as HSMs).
  • a secure communication channel eg TLS / SSL, etc.
  • the "trust information" given to each entity is a technical grant of the result of the certification of the entity. That is, not only the verification result of CC (Common Criteria-security verification standard and organization) for eSIM itself, but also digital form confidential information (e.g. secret key (symmetric key) can be stored in eSIM. ), Certificates, etc.).
  • CC Common Criteria-security verification standard and organization
  • digital form confidential information e.g. secret key (symmetric key) can be stored in eSIM. ), Certificates, etc.
  • Trust information of the present invention is digital information that is given to an individual who is qualified to participate in a trust relationship, and may be in the form of a certificate, a security key, token information, etc., and may be referred to as security information / authentication information / token information. Can be.
  • Verification information of the present invention is digital information generated for the purpose of authenticating each individual through the "trust information” may be referred to as authentication information / token information / electronic signature / MAC.
  • the generation of the verification information there may be performing a hash function operation by inputting arbitrary information such as a random number or trust information shared with publicly available identification information.
  • the information transmitted to the counterpart entity is a generated hash number or generated random information or publicly available identification information.
  • the other party receiving this information can check whether the corresponding "verification information" is generated by the entity that will establish a trust relationship with the shared information such as random number or public identification information.
  • the verification information As another example of the generation of the verification information, if its "trust information” is a certificate, “verification” through digital signature on any information such as random number or publicly identifiable information with its private key (corresponding to the trust information) Information ", which is sent to the other party, and the other party verifies the" verification information "based on the digital signature using a certificate sent or published together, so that the" verification information "is generated by the entity that will form a trust relationship with itself. You can check.
  • the eUICC certification authority and the eUICC infrastructure certification authority may be integrated, separated or subdivided.
  • FIG. 6 illustrates an example of a flow of trust relationship formation between entities in an eUICC environment according to an embodiment of the present invention.
  • each arrow means based on the structure of FIG.
  • the basic relationship between each entity may be formed as shown in FIG. 6.
  • each of the plurality of entities (Entity 1, Entity 2) is received or shared.
  • Generating verification information based on the received trust information (S610), and each of the plurality of objects (object 1 and object 2) transmitting the generated verification information to the counterpart entity to exchange the generated verification information with each other.
  • S620 and each of the plurality of entities (object 1 and entity 2), by verifying the verification information transmitted from the counterpart entity based on the trust information, authenticating the counterpart entity to form a trust relationship between the plurality of entities ( S640) and the like.
  • step S610 the entity 1 generates verification information based on the received or shared trust information (trust information 1), and the entity 2 generates verification information based on the received or shared trust information (trust information 2).
  • step S620 entity 1 transmits the verification information generated by itself (object 1) to the counterpart entity (object 2), and entity 2 transmits verification information generated by itself (object 2) to the counterpart entity (object 1). By doing so, entity 1 and entity 2 exchange their verification information generated by each other.
  • step S620 a plurality of entities (object 1, entity 2), if the trust information of each of the certificate can transmit the trust information to the counterpart entity with the verification information.
  • the plurality of entities (object 1 and entity 2) trust the validity, reliability, etc. of the trust information (trust information of another entity) received from the counterpart entity.
  • the method may further include a step (S630) of verifying trust information by contacting a certification authority that issued the information. That is, the entity 1 verifies the trust information (trust information 2) of the entity 2 received from the entity 2, and the entity 2 verifies the trust information (trust information 1) of the entity 1 transmitted from the entity 1.
  • step S640 the entity 1 authenticates the entity 2 by verifying the verification information received from the entity 2, the entity 2 authenticates the entity 1 by verifying the validation information received from the entity 1, between the entity 1 and the entity 2 Can build trust.
  • each entity generates verification information based on trust information (which may correspond to the trust information of the entity itself) received from the certification authority.
  • the verification information may be a result value generated by inputting a hash function using trust information shared with another entity, a random number generated by the user, or identification information that can be disclosed.
  • the verification information may be a result of performing an electronic signature operation on random numbers or publicly available identification information generated by the private key (which may correspond to trust information).
  • step S620 each entity exchanges random number or publicly available identification information and generated verification information.
  • the trust information when the trust information is a certificate, the trust information (which may be the trust information of the object itself) may be transmitted to the counterpart.
  • Step S630 If the trust information is a certificate, the individual performs verification by asking the certification authority that issued the trust information about the validity and reliability of the trust information of the other entity. However, this step S630 may be omitted if the trust information is a symmetric key.
  • Step S640 When step S630 is successfully completed, each entity authenticates each other by verifying verification information of the counterpart entity based on the trust information, thereby forming a trust relationship between each entity.
  • the trust information may be a symmetric key (private key) or an authentication key (public key). If the trust information is a symmetric key, each entity is the same with respect to the random number received from the counterpart entity and publicly available identification information. After the hash function is performed, the result may be compared with the verification information received from the counterpart entity to verify the verification information received from the counterpart entity. If the trust information is a certificate, each entity decrypts the verification information received from the other party with a certificate (public key), and then hashes the random number or publicly identifiable information received from the other party and the certificate ( Verification of the verification information received from the counterpart entity may be performed by checking whether the result value decrypted with the public key) is the same.
  • the plurality of entities are eUICC and eUICC-equipped devices, eUICC and SM-SR, SM-SR and SM-SR, MNO and SM-SR, MNO and SM-DP, SM-SR and SM -DP and so on.
  • the method for establishing a trust relationship between specific entities may include forming a trust relationship between the eUICC and an eUICC-mounted device (S510).
  • trust relationship forming step between eUICC and SM-SR (S520), trust relationship forming step between SM-SR (S530), trust relationship forming step between MNO and SM-SR (S540), trust relationship forming between MNO and SM-DP
  • step S550 a trust relationship forming step between the SM-SR and the SM-DP (S560), a trust relationship forming step between the eUICC and eUICC-equipped devices (S510), a trust relationship forming step between the MNO and SM-SR (S540) ),
  • a trust relationship forming step between the MNO and the SM-DP may be further included.
  • Each of the eUICC-equipped devices equipped with the eUICC and the eUICC is mutually recognized based on the trust information of the other party, thereby forming a trust relationship between the eUICC and the eUICC-equipped device.
  • the eUICC and the eUICC-equipped device perform mutual authentication based on trust information issued to each.
  • each entity can query the certification authority online (OTA or OTI) about the validity and reliability of the trust information of another entity.
  • OTA or OTI certification authority online
  • eUICC lacks communication function
  • verification of trust information of eUICC-equipped device is disclosed in eUICC-equipped device (mounted at the manufacturing or provisioning stage). It is based on trust information (eg public key of Public Key Cryptography).
  • the trust information of the eUICC-equipped device may be verified by communicating with a trust authority through the eUICC-equipped device.
  • Each of the eUICC and SM-SR generates and transmits verification information to the other party based on the received or shared trust information, and verifies the verification information received from the other party based on the trust information to authenticate the other party.
  • a trust relationship is established.
  • a trust relationship between the eUICC and the SM-SR may be formed according to the method as illustrated in FIG. 6. If a trust relationship between the eUICC and the SM-SR is formed according to the method shown in FIG. 6, operation S520 will be described below.
  • step S520 each of the eUICC and SM-SR, as a verification information generated a result of performing a hash function operation by inputting the random number or publicly available identification information and the trust information, or a random number generated by each private key Alternatively, as a verification information, a result of performing an electronic signature operation on the publicly available identification information is generated.
  • each of the eUICC and SM-SR in addition to the verification information, may further transmit a random number or public identification information to the counterpart.
  • each of the eUICC and the SM-SR may further transmit the trust information when the trust information is a certificate.
  • step S520 each of the eUICC and SM-SR, after transmitting the verification information to the other party, if the trust information is a certificate, through the process of inquiring the trust information with the certification authority as the issuer of trust information, Validity and reliability can be verified.
  • the verification of the trust information may be omitted when the trust information is a symmetric key.
  • each of the eUICC and SM-SR the verification received from the other party by comparing the result of performing a hash function operation on the random number or public identification information received from the other party and the verification information received from the other party, By verifying the information and authenticating the other party, a trust relationship between the eUICC and the SM-SR may be formed.
  • a hash function operation is performed on random or publicly available identification information. By comparing the value and the result decrypted with the certificate, the trust relationship between the eUICC and the SM-SR can be formed by verifying the transmitted verification information to authenticate the counterpart.
  • Each SM-SR generates verification information based on the received or shared trust information and transmits the verification information to the other party, and verifies the verification information received from the other party based on the trust information to authenticate the other party, thereby creating a trust relationship between the SM-SRs. Is formed.
  • the trust relationship between the SM-SR may be formed according to the method as shown in FIG. 6, and may also form a trust relationship through a secure communication protocol such as TLS / SSL.
  • each of the SM-SRs generates a result of performing a hash function operation with input of random number or publicly available identification information and trust information as verification information, or random numbers or disclosures generated by respective private keys.
  • the result of performing the digital signature operation on the possible identification information can be generated as verification information.
  • each of the SM-SRs in addition to the verification information, may further transmit a random number or public identification information to the counterpart, and if the trust information is a certificate, may further transmit the trust information.
  • each of the SM-SRs after transmitting the verification information to the other party, if the trust information is a certificate, through the trust information inquiry procedure with the certification authority that is the issuer of the trust information, Validity and reliability can be verified.
  • the verification of the trust information may be omitted when the trust information is a symmetric key.
  • each of the SM-SRs the verification information received from the counterpart by comparing the result of performing a hash function operation on the random number or public identification information transmitted from the counterpart and the verification information received from the counterpart, By authenticating the other party and authenticating the other party, establishing a trust relationship between the SM-SRs, decrypting the received verification information with a certificate, and performing a hash function operation on the random number or public identification information and the certificate. By comparing the decrypted result value, the trust relationship between the SM-SRs may be formed by verifying the transmitted verification information to authenticate the counterpart.
  • the MNO Mobile Network Operator MNO
  • the MNO unidirectionally authenticates the SM-SR based on the trust information of the SM-SR, thereby forming a trust relationship between the MNO and the SM-SR.
  • the MNO performs one-way authentication based on the trust information of the SM-SR to form a trust relationship between the MNO and the SM-SR, because the MNO is a reliable element (object) in the eUICC and a source of customer information. This is because authentication for the MNO may not be necessary. However, in some cases, mutual authentication may occur based on the MNO certificate.
  • the MNO unilaterally authenticates the SM-DP based on the trust information of the SM-DP, thereby forming a trust relationship between the MNO and the SM-DPR.
  • the MNO performs one-way authentication based on the trust information of the SM-DP to form a trust relationship between the MNO and the SM-DP, because the MNO is a reliable element (object) in the eUICC and the source of customer information. This is because authentication for the MNO may not be necessary. However, in some cases, mutual authentication may occur based on the MNO certificate.
  • Each of the SM-SR and SM-DP generates verification information based on the received or shared trust information and transmits the verification information to the other party, and verifies the verification information received from the other party based on the trust information to authenticate the other party. And a trust relationship between the SM-DP is formed.
  • a trust relationship between the SM-SR and the SM-DP may be established according to the scheme of FIG. 6, and a trust relationship may also be formed through a secure communication protocol such as TLS / SSL.
  • each of the SM-SR and the SM-DP generates a result of performing a hash function operation based on random number or publicly available identification information and the trust information as the verification information, or uses a respective private key.
  • the verification value may be generated as a result of performing an electronic signature operation on the generated random number or publicly available identification information.
  • each of the SM-SR and the SM-DP in addition to the verification information, may further transmit random number or publicly available identification information to the counterpart. If the trust information is a certificate, the SM-SR and SM-DP may further transmit trust information.
  • step S560 each of the SM-SR and SM-DP, if the trust information is the certificate after transmitting the verification information to the other party, the trust information of the other party through the process of inquiring the trust information with the certification authority which is the issuer of the trust information, You can also verify the validity and reliability of the information.
  • the verification of the trust information may be omitted when the trust information is a symmetric key.
  • each of the SM-SR and the SM-DP transmits from the counterpart by comparing the verification information received from the counterpart with a result value of performing a hash function on the random number or public identification information transmitted from the counterpart.
  • a trust relationship between SM-SR and SM-DP is formed, or the received verification information is decrypted with the certificate, and then a hash function operation is performed on random or publicly available identification information.
  • a trust relationship between the SM-SR and the SM-DP may be formed by verifying the transmitted verification information to authenticate the other party.
  • FIG. 7 is a flowchart illustrating a method for forming a trust relationship between an eUICC and an SM-SR during the establishment of a trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • This flowchart of FIG. 7 is a flowchart showing in detail the step S510 of FIG. 5 using the eUICC as the operation subject.
  • the step of generating verification information by the eUICC (S700), and transmitting verification information generated by the eUICC to the SM-SR. And receiving verification information generated in the SM-SR from the SM-SR (S702), verifying the reliability information by the eUICC (S704), and verifying the verification information transmitted by the SM-SR by the eUICC (S706). And the like.
  • the eUICC In the verification information generation step (S700), the eUICC generates verification information based on the received or shared trust information. At this time, in the same manner, the SM-SR generates verification information based on the received or shared trust information.
  • the eUICC transmits the generated verification information to the SM-SR as information for the SM-SR to authenticate the eUICC, and transmits the verification information generated by the SM-SR from the SM-SR.
  • the SM-SR transmits the verification information generated by the SM-SR to the eUICC as the information for the eUICC to authenticate the SM-SR, and receives the verification information generated by the eUICC from the eUICC.
  • the eUICC After the verification information exchange step (S702), if the trust information is a certificate, in the trust information verification step (S704), which may be further performed, the eUICC, if the trust information is a certificate, trust information with the certificate authority that is the issuer of the trust information. Through the inquiry process, the validity and reliability of the trust information of the SM-SR can be verified. In this case, the SM-SR can also verify the validity and reliability of the trust information of the eUICC through a trust information inquiry procedure with a certification authority that is the issuer of trust information.
  • the trust information verification step S704 is not performed when the trust information is a symmetric key, and the verification information verification step S706 may be immediately performed.
  • the eUICC verifies the SM-SR by verifying the verification information transmitted from the SM-SR based on the trust information. You can authenticate.
  • the SM-SR may authenticate the eUICC by verifying verification information received from the eUICC based on the corresponding trust information.
  • the eUICC in the above-described verification information generation step (S700), the eUICC, as a result of performing a hash function operation by inputting random numbers or publicly available identification information and trust information shared with other entities (SM-SR)
  • the value can be generated as verification information.
  • the eUICC may generate, as verification information, a result of performing an electronic signature operation on a random number or publicly available identification information generated by its own private key.
  • the SM-SR may also generate verification information in the same manner.
  • the eUICC further transmits random number or discernible identification information in addition to the verification information to the SM-SR, and random number or disclosure in addition to the verification information generated by the SM-SR from the SM-SR. Possible identification information may be further transmitted.
  • the SM-SR may also transmit and receive a random number or publicly available identification information in addition to the verification information to the eUICC.
  • the eUICC may further transmit the trust information to the SM-SR, and further receive the trust information of the SM-SR from the SM-SR. .
  • the SM-SR may further transmit and receive trust information to the eUICC in the same manner.
  • the eUICC if the trust information is a symmetric key, the result value of performing a hash function operation on the random number or public identification information transmitted from the SM-SR and the SM- in step S702.
  • the verification information received from the SM-SR can be verified in step S702 to authenticate the SM-SR.
  • the eUICC when the trust information is a certificate, the eUICC decrypts the verification information received in step S702 with a certificate, and then performs a hash function operation on random numbers or publicly available identification information.
  • the SM-SR may be authenticated by verifying the verification information transmitted from the SM-SR in step S702.
  • FIG. 8 is a block diagram of an eUICC for establishing a trust relationship between an eUICC and an SM-SR during the establishment of a trust relationship between entities in an eUICC environment according to an embodiment of the present invention.
  • the eUICC for establishing a trust relationship between the eUICC and the SM-SR includes a verification information generation unit 810 for generating verification information based on the received or shared trust information, and the generated verification information as the SM-SR.
  • the verification information exchanger 820 receives the verification information generated by the SM-SR from the SM-SR as the information for authenticating the eUICC, and the verification information generated by the SM-SR is transmitted from the SM-SR based on the corresponding trust information.
  • the verification information generator 810 is configured to perform the verification information generating step S700 of FIG. 7, and the verification information exchanging unit 820 is configured to perform the verification information exchanging step S702 of FIG. 7.
  • the trust information verification unit 830 is configured to perform the trust information verification step S704 in FIG. 7, and the verification information verification unit 840 is configured to perform the verification information verification step S706 in FIG. 7.
  • the above-described verification information generation unit 810 verifies a result of performing a hash function operation by inputting random numbers or publicly available identification information and trust information shared with another entity (SM-SR).
  • the verification result may be generated as information, or a result of performing an electronic signature operation on a random number or publicly identifiable identification information generated with its own private key.
  • the verification information verification unit 840 compares the verification information received from the SM-SR with a result value of performing a hash function operation on the random number or publicly available identification information transmitted from the SM-SR when the trust information is a symmetric key. By verifying the verification information received from the SM-SR to authenticate the SM-SR, or if the trust information is a certificate, decrypt the received verification information into a certificate, and then compute a hash function on random or publicly available identification information. By comparing the result value performed with the result value decrypted with the certificate, it is possible to authenticate the SM-SR by verifying the verification information transmitted from the SM-SR.
  • eUICC for establishing a trust relationship between the eUICC and the SM-SR, the trust information of the SM-SR through the process of contacting the trust information with the certification authority, the issuer of trust information, when the trust information is a certificate
  • It may further include a trust information verification unit 830 for verifying the validity and reliability of the.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명은 eUICC를 관리하기 위한 개체로서 SM이 정의되는 통신 시스템에서, MNO, SM, eUICC, 단말과 같은 개체 사이의 신뢰관계를 형성하는 방법과 이를 위한 eUICC에 관한 것이다.

Description

신뢰관계 형성 방법 및 이를 위한 내장 ＵⅠＣＣ
본 발명은 내장 UICC을 포함한 통신 시스템에서의 개체간 신뢰 관계 형성방법 및 이를 위한 내장 UICC에 관한 것이다.
UICC(Universal Integrated Circuit Card)는 단말기 내에 삽입되어 사용자 인증을 위한 모듈로서 사용될 수 있는 스마트 카드이다. UICC는 사용자의 개인 정보 및 사용자가 가입한 이동 통신 사업자에 대한 사업자 정보를 저장할 수 있다. 예를 들면, UICC는 사용자를 식별하기 위한 IMSI(International Mobile Subscriber Identity)를 포함할 수 있다. UICC는 GSM(Global System for Mobile communications) 방식의 경우 SIM(Subscriber Identity Module) 카드, WCDMA(Wideband Code Division Multiple Access) 방식의 경우 USIM(Universal Subscriber Identity Module) 카드로 불리기도 한다.
사용자가 UICC를 사용자의 단말에 장착하면, UICC에 저장된 정보들을 이용하여 자동으로 사용자 인증이 이루어져 사용자가 편리하게 단말을 사용할 수 있다. 또한, 사용자가 단말을 교체할 때, 사용자는 기존의 단말에서 탈거한 UICC를 새로운 단말에 장착하여 용이하게 단말을 교체할 수 있다.
소형화가 요구되는 단말, 예를 들면 기계 대 기계(Machine to Machine, M2M) 통신을 위한 단말은 UICC를 착탈할 수 있는 구조로 제조할 경우 단말의 소형화가 어려워진다. 그리하여, 착탈할 수 없는 UICC인 내장 UICC(Embedded UICC) 구조가 제안되었다. 내장 UICC는 해당 UICC를 사용하는 사용자 정보가 IMSI 형태로 수록되어야 한다.
기존의 UICC는 단말에 착탈이 가능하여, 단말의 종류나 이동 통신 사업자에 구애받지 않고 사용자는 단말을 개통할 수 있다. 그러나, 단말을 제조할 때부터 제조된 단말은 특정 이동 통신 사업자에 대해서만 사용된다는 전제가 성립되어야 내장 UICC 내의 IMSI를 할당할 수 있다. 단말을 발주하는 이동 통신 사업자 및 단말 제조사는 모두 제품 재고에 신경을 쓸 수 밖에 없고 제품 가격이 상승하는 문제가 발생하게 된다. 사용자는 단말에 대해 이동 통신 사업자를 바꿀 수 없는 불편이 있다. 그러므로, 내장 UICC의 경우에도 이동 통신 사업자에 구애받지 않고 사용자가 단말을 개통할 수 있는 방법이 요구된다.
한편, 최근 내장 UICC의 도입으로 인하여 여러 이통통신 사업자의 가입자 정보를 원격에서 UICC로 업데이트 할 필요가 생기게 되었고, 그에 따라 가입자 정보 관리를 위한 가입 관리 장치(Subscription Manager; 이하 ‘SM’이라 함) 또는 프로파일 관리장치(Profile Manager; 이하 ‘PM’이라 함)가 논의되고 있다.
이와 같이, 기존의 착탈식 형태의 SIM과는 달리 단말에 일체형으로 탑재되는 Embedded SIM (이하 eSIM 및 eUICC)은 그 물리적 구조 차이로 인해 개통 권한, 부가 서비스 사업 주도권, 가입자 정보 보안 등에 대한 많은 이슈들이 존재한다. 이를 위해 GSMA 및 ETSI의 국제 표준화 기관에서는 사업자, 제조사, SIM Vendor 등의 유관 회사들과 최상위 구조를 포함한 필요한 요소에 대해 표준화 활동을 전개하고 있다. eSIM이 표준화 단체들을 통해 논의되면서 이슈의 중심에 있는 것은 Subscription Manager라고 불리는 SM으로 사업자 정보 (Operator Credential)를 eSIM에 발급하고 Subscription 변경에 대한 프로세스를 처리하는 등 eSIM에 대한 전반적인 관리 역할을 수행하는 개체 또는 그 기능/역할을 의미한다. 최근 GSMA에서는 SM의 역할을 사업자 정보를 생성하는 역할을 수행하는 SM-DP (Data Preparation)과 eSIM에 사업자 정보의 직접적 운반을 수행하는 SM-SR (Secure Routing)로 분류한 구조를 제안하였으며, 각 개체들간의 “신뢰 관계 (Circle of Trust)”를 언급하여 eSIM 전체 안전성을 높이는 방안을 제안하였으나 기술적으로 이를 달성하는 방안이 존재하지 않는다.
이에 본 발명에서는 GSMA 제안 eSIM 환경의 각 개체들 간의 신뢰 관계 형성 방안을 제시한다.
본 발명의 목적은 내장 UICC을 포함하는 통신 시스템에서 각 엔터티(Entity) 또는 개체 사이의 신뢰관계를 형성하는 방법 등을 제공하는 것이다.
본 발명의 다른 목적은 eUICC를 관리하기 위한 개체로서 SM이 정의되는 통신 시스템에서, 각 엔터티 또는 개체 사이의 신뢰관계를 형성하는 방법 등을 제공하는 것이다.
본 발명의 또 다른 목적은 eUICC를 관리하기 위한 개체로서 SM이 정의되는 통신 시스템에서, MNO, SM, eUICC, 단말과 같은 엔터티 또는 개체 사이의 신뢰관계를 형성하는 방법 등을 제공하는 것이다.
본 발명의 또 다른 목적은 eUICC를 관리하기 위한 개체로서 SM이 정의되는 통신 시스템에서, MNO, SM, eUICC, 단말과 같은 엔터티 또는 개체 사이의 신뢰관계를 형성하기 위하여 특별히 정의되는 신뢰정보를 이용하는 방법 등을 제공하는 것이다.
일 측면에서, 본 발명은, eUICC(embedded Universal Integrated Circuit Card) 및 SM-SR(Subscription Manager-Secure Routing) 간의 신뢰관계 형성 방법으로서, 상기 eUICC가 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 검증정보 생성 단계; 상기 eUICC가 상기 생성된 검증정보를 상기 SM-SR이 상기 eUICC를 인증하기 위한 정보로서 상기 SM-SR로 전송하고, 상기 SM-SR에 의해 생성된 검증정보를 상기 SM-SR로부터 전송받는 검증정보 교환 단계; 및 상기 eUICC가 해당 신뢰정보를 토대로 상기 SM-SR로부터 전송받은 검증정보를 검증함으로써 상기 SM-SR을 인증하는 검증정보 검증 단계를 포함하는 신뢰관계 형성 방법을 제공한다.
다른 측면에서, 본 발명은, SM-SR(Subscription Manager-Secure Routing)과 신뢰관계 형성을 위한 eUICC(embedded Universal Integrated Circuit Card)으로서, 전달받거나 공유된 신뢰정보 또는 각자의 개인키를 토대로 검증정보를 생성하는 검증정보 생성부; 상기 eUICC가 상기 생성된 검증정보를 상기 SM-SR이 상기 eUICC를 인증하기 위한 정보로서 상기 SM-SR로 전송하고, 상기 SM-SR에 의해 생성된 검증정보를 상기 SM-SR로부터 전송받는 검증정보 교환부; 및 상기 eUICC가 해당 신뢰정보를 토대로 상기 SM-SR로부터 전송받은 검증정보를 검증함으로써 상기 SM-SR을 인증하는 검증정보 검증부를 포함하는 eUICC를 제공한다.
또 다른 측면에서, 본 발명은, 통신 시스템 내 복수의 개체 간의 신뢰관계 형성 방법으로서, 복수의 개체 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 단계; 상기 복수의 개체 각각이, 각자 생성된 검증정보를 상대방 개체로 전송하여 각자 생성된 검증정보를 상호 교환하는 단계; 및 상기 복수의 개체 각각이, 해당 신뢰정보를 토대로 상대방 개체로부터 전송받은 검증정보를 검증함으로써 상대방 개체를 인증함으로써, 상기 복수의 개체간 신뢰관계를 형성하는 단계를 포함하는 신뢰관계 형성 방법을 제공한다.
또 다른 측면에서, 본 발명은, eUICC(embedded Universal Integrated Circuit Card) 및 SM-SR(Subscription Manager-Secure Routing) 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 eUICC 및 SM-SR 간 신뢰관계 형성 단계; SM-SR 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 SM-SR 및 SM-SR 간 신뢰관계 형성 단계; 및 SM-SR 및 SM-DP(Subscription Manager-Data Preparation) 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 SM-SR 및 SM-DP 간 신뢰관계 형성 단계를 포함하는 신뢰관계 형성 방법을 제공한다.
도 1은 본 발명이 적용되는 eSIM(eUICC)을 포함한 전체 서비스 아키텍처를 도시한다.
도 2는 본 발명이 적용될 수 있는 SM 분리 환경의 시스템 아키텍처를 도시한다.
도 3은 본 발명이 적용되는 서비스 아키텍처에서 프로비저닝 과정의 전체 흐름도이다.
도 4는 본 발명이 적용되는 가입 변경 또는 MNO 변경 과정의 전체 흐름도이다.
도 5는 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 구조의 일 예를 도시한다.
도 6은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 흐름의 일 예를 도시한다.
도 7은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 중 eUICC 및 SM-SR 간 신뢰관계 형성 방법에 대한 흐름도이다.
도 8은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 중 eUICC 및 SM-SR 간 신뢰관계 형성을 위한 eUICC에 대한 블록도이다.
이하, 본 발명의 일부 실시예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.
현재 GSMA에서 활발하게 논의되는 M2M(Machine-to-Machine) 단말은 특성상 크기가 작아야 하는데, 기존 UICC를 사용하는 경우에는, M2M 단말에 UICC를 장착하는 모듈을 별도 삽입해야 하므로, UICC를 탈착가능한 구조로 M2M단말을 제조하게 되면, M2M 단말의 소형화가 힘들게 된다.
따라서, UICC 착탈이 불가능한 내장(Embedded) UICC 구조가 논의되고 있는데, 이때 M2M 단말에 장착되는 eUICC에는 해당 UICC를 사용하는 이동통신 사업자(Mobile Network Operator; 이하 ‘MNO’라 함)정보가 국제 모바일 가입자 식별자(International Mobile Subscriber Identity, IMSI) 형태로 UICC에 저장되어 있어야 한다.
그러나, M2M 단말을 제조할 때부터 제조된 단말은 특정 MNO에서만 사용한다는 전제가 성립되어야 eUICC내의 IMSI를 할당할 수 있으므로, M2M 단말 또는 UICC를 발주하는 MNO나 제조하는 M2M 제조사 모두 제품 재고에 많은 신경을 할당할 수 밖에 없고 제품 가격이 상승하게 되는 문제가 있어, M2M 단말 확대에 큰 걸림돌이 되고 있는 상황이다.
이와 같이, 기존의 착탈식 형태의 SIM과는 달리 단말에 일체형으로 탑재되는 내장 SIM (이하 eSIM 또는 eUICC이라 함)은 그 물리적 구조 차이로 인해 개통 권한, 부가 서비스 사업 주도권, 가입자 정보 보안 등에 대한 많은 이슈들이 존재한다. 이를 위해 GSMA 및 ETSI의 국제 표준화 기관에서는 사업자, 제조사, SIM 제조사(Vendor) 등의 유관 회사들과 최상위 구조를 포함한 필요한 요소에 대해 표준화 활동을 전개하고 있다. eSIM이 표준화 단체들을 통해 논의되면서 이슈의 중심에 있는 것은 SM으로서, 중요한 프로파일(Operator Credential, MNO Credential, Profile, eUICC Profile, Profile Package 등으로 불릴 수 있음)를 eSIM에 발급하고 가입 변경에 대한 프로세스를 처리하는 등 eSIM에 대한 전반적인 관리 역할을 수행하는 개체 또는 그 기능/역할을 의미한다.
최근 GSMA에서는 SM의 역할을 사업자 정보를 생성하는 역할을 수행하는 SM-DP (Data Preparation)과 eSIM에 사업자 정보의 직접적 운반을 수행하는 SM-SR (Secure Routing)로 분류한 구조를 제안하였으나, 세부적이며 기술적인 실제 발급 방식에 대해서는 언급하고 있지 않다.
이에 본 발명에서는 GSMA의 SM 역할 분리 환경에서 동적 암호키 (공개 키 등) 생성을 활용하여 eSIM을 관리하는 방안을 제시한다.
본 명세서에서는 eSIM과 eUICC를 동등한 개념으로 사용한다.
eSIM은 단말 제조 단계에서 IC칩을 단말 회로판 상에 부착시킨 후, 소프트웨어 형태의 SIM 데이터 (개통 정보, 부가 서비스 정보 등)를 OTA (Over The Air) 또는 오프라인 (PC와의 USB 등의 기술 기반 연결)을 통해 발급하는 방식의 새로운 개념의 SIM 기술이다. eSIM에서 사용되는 IC칩은 일반적으로 하드웨어 기반의 CCP (Crypto Co-Processor)를 지원하여 하드웨어 기반의 공개키 생성을 제공하며, 이를 어플리케이션 (예, 애플릿) 기반에서 활용할 수 있는 API를 SIM 플랫폼 (예, Java Card Platform 등)에서 제공한다. 자바 카드 플랫폼(Java Card Platform)은 스마트카드 등에서 멀티 어플리케이션을 탑재하고 서비스를 제공할 수 있는 플랫폼 중 하나이다.
SIM은 제한된 메모리 공간과 보안상의 이유로 누구나 SIM 내에 어플리케이션을 탑재해서는 안되며, 이로 인해 어플리케이션 탑재를 위한 플랫폼 이외에 SIM을 어플리케이션 탑재 및 관리를 담당하는 SIM 서비스 관리 플랫폼을 필요로 한다. SIM 서비스 관리 플랫폼은 관리키를 통한 인증 및 보안을 통해 SIM 메모리 영역에 데이터를 발급하며, 글로벌 플랫폼(GlobalPlatform)과 ETSI TS 102.226의 RFM (Remote File Management) 및 RAM (Remote Application Management)은 이와 같은 SIM 서비스 관리 플랫폼의 표준 기술이다.
eSIM 환경에서 중요한 요소 중의 하나인 SM은 eSIM은 원격으로 관리키(UICC OTA Key, GP ISD Key 등)를 통해 통신 및 부가 서비스 데이터를 발급하는 역할을 수행한다.
여기서, 관리키 또는 eSIM 관리키 또는 eUICC 관리키는 eSIM으로의 접근 인증키로서 사업자 정보를 안전하게 eSIM으로 전달하기 위한 것이며, 본 발명에서 주로 다루는 암호키 (공개키 등)과는 구별되는 개념이며, 아래 설명할 바와 같이 eUICC 접근 크레덴셜(eUICC access credentials)로 표현될 수도 있을 것이다.
GSMA에서는 SM의 역할을 SM-DP와 SM-SR로 분류하였다. SM-DP는 오퍼레이션 프로파일(또는 사업자 정보) 이외에 IMSI, K, OPc, 부가 서비스 어플리케이션, 부가 서비스 데이터 등을 안전하게 빌드(Build)하여 크레덴셜 패키지(Credential Package) 형태로 만드는 역할을 수행하며, SM-SR은 SM-DP가 생성한 크레덴셜 패키지를 OTA(Over-The-Air) 또는 GP SCP (Secure Communication Protocol)과 같은 SIM 원격 관리 기술을 통해 eSIM에 안전하게 다운로드하는 역할을 수행한다.
그리고 아래 도 1의 “신뢰 서클(Circle of Trust)”이라는 구조를 제안하여 각 유사 개체 또는 엔터티 들간에 신뢰 관계의 중첩을 통해 MNO와 eSIM 간의 엔드-투-엔드(End-to-End) 신뢰 관계를 구축한다는 개념을 제안하였다. 즉, MNO1는 SM1과, SM1은 SM4, SM4는 eSIM과 신뢰관계를 형성하여, 이를 통해 MNO와 eSIM 간의 신뢰관계를 형성한다는 개념이다.
본 발명을 설명하기 전에 우선 본 명세서에서 사용할 용어에 대하여 설명한다.
MNO(Mobile Network Operator)는 이동통신 사업자를 의미하며, 모바일 네트워크를 통해 고객에게 통신 서비스를 제공하는 엔터티를 의미한다.
SM(Subscription manager)는 가입 관리 장치로서, eUICC의 관리 기능을 수행한다.
eUICC 공급자(eUICC Supplier)는 eUICC 모듈과 내장 소프트웨어(펌웨어와 오퍼레이팅 시스템 등)를 공급하는 자를 의미한다.
장치 공급자(Device Vendor)는 장치의 공급자, 특히 MNO에 의해서 구동되는 모바일 네트워크를 통한 무선 모뎀 기능을 포함하며, 따라서 결과적으로 UICC(또는 eUICC) 형태가 필요한 장치의 공급자를 의미한다.
프로비저닝(Provisioning)은 eUICC 내부로 프로파일을 로딩하는 과정을 의미하며, 프로비저닝 프로파일은 다른 프로비저닝 프로파일 및 오퍼레이션 프로파일을 프로비저닝할 목적으로 장치가 통신 네트워크에 접속하는데 사용되는 프로파일을 의미한다.
가입(Subscription)은 가입자와 무선통신 서비스 제공자 사이의 서비스 제공을 위한 상업적인 관계를 의미한다.
eUICC 접근 크레덴셜(eUICC access credentials)은 eUICC 상의 프로파일을 관리하기 위하여 eUICC 및 외부 엔터티 사이에 보안 통신이 셋업 될 수 있도록 하는 eUICC 내의 데이터를 의미한다.
프로파일 엑세스 크레덴셜(Profile access credentials)은 프로파일 내부 또는 eUICC 내부에 존재하는 데이터로서, 프로파일 구조 및 그 데이터를 보호 또는 관리하기 위하여 eUICC 및 외부 엔터티 사이에 보안 통신이 셋업 될 수 있도록 하는 데이터를 의미한다.
프로파일(Profile)은 eUICC로 프로비저닝 되거나 eUICC 내에서 관리될 수 있는 파일 구조, 데이터 및 애플리케이션의 조합으로서, 사업자 정보인 오퍼레이션 프로파일, 프로비저닝을 위한 프로비저닝 프로파일, 기타 정책 제어 기능(PCF; Policy Control Function)을 위한 프로파일 등 eUICC 내에 존재할 수 있는 모든 정보를 의미한다.
오퍼레이션 프로파일(Operation Profile) 또는 사업자 정보는 사업자 가입(Operational Subcription)과 관련된 모든 종류의 프로파일을 의미한다.
도 1은 본 발명이 적용되는 eSIM(eUICC)을 포함한 전체 서비스 아키텍처를 도시한다.
전체 시스템에 대해서 설명하면 다음과 같다.
본 발명이 적용될 수 있는 eUICC 시스템 아키텍처는 다수의 MNO 시스템과, 1 이상의 SM 시스템, eUICC 제조사 시스템, eUICC를 포함하는 장치(Device) 제조사 시스템 및 eUICC 등을 포함할 수 있으며, 각 엔터티 또는 주체에 대한 설명은 다음과 같다.
도 1에서 점선은 신뢰 서클을 도시하고, 2개 실선은 안전한 링크를 의미한다.
가입정보가 저장되어 전달되는 시나리오가 필요하면, MNO의 승인과 MNO의 컨트롤 하에서 이루어져야 한다. 특정 시각에 단일의 eUICC 상에는 1개만의 액티브 프로파일이 있어야 하며, 이 때 액티브 프로파일은 특정 시간에 단일 HLR에 부가되는 것을 의미한다.
MNO와 eUICC는 MNO 크레덴셜(Credentials) 정보, 즉 프로파일(오퍼레이션 프로파일, 프로비저닝 프로파일 등)를 복호할 수 있어야 한다. 이에 대한 유일한 예외는 예를 들면 SIM 벤더와 같이 특정 MNO으로부터 위임받은 제3 기관이 될 수 있다. 하지만, 이를 수행하기 위한 제3 기관의 일반적인 기능은 아니다.
가입(Subscription)은 오퍼레이터 정책 제어의 외부에서는 eUICC 내에서 스위칭될 수 없다. 사용자는 MNO 컨텐스트와 그의 활성화 가입의 어떠한 변경도 알고 있어야 하며, 시큐리티 위험을 피할 수 있어야 하고, 현재의 UICC 모델과 대적할 수 있을 정도의 시큐리티 레벨이 필요하다.
MNO 크레덴셜 또는 프로파일은 K, 알고리즘, 알고리즘 파라미터, 부가 서비스 어플리케이션, 부가 서비스 데이터 등을 포함하는 가입 크레덴셜을 의미할 수 있다.
MNO 크레덴셜 또는 프로파일의 전달은 종단에서 종단까지 안전한 방식으로 이루어져야 한다. 전송은 시큐리티 체인을 깨지 않는 연속적인 단계로 이루어질 수 있으며, 전송 체인의 모든 단계는 MNO의 인식 및 승인 하에서 이루어져야 한다. 전송 체인 내의 어떠한 엔터티도 MNO 크레덴셜을 명확하게 볼 수 없어야 하지만, 유일한 예외는 예를 들면 SIM 벤더와 같이 특정 MNO으로부터 위임받은 제3 기관이 될 수 있다. 하지만, 이를 수행하기 위한 제3 기관의 일반적인 기능은 아니다.
오퍼레이터는 자신의 크레덴셜에 대해서 완전한 제어권을 가져야 하며, 오퍼레이터는 SM 오퍼레이션에 대해서 강한 감독권과 제어권한을 가져야 한다.
SM 기능은 MNO 또는 제3 기관에 의하여 제공되어야 하며, 만약 제3 기관에 의하여 제공된다면 SM과 MNO 사이에는 상업적인 관계가 설정되어 있는 경우 등일 것이다.
SM은 가입 관리를 위해서 MNO 가입자와 어떠한 직접적인 관련도 없다. MNO가 가입자와 관계를 가지며 고객 가입을 위한 진입 포인트가 되어야 하지만, 이는 M2M 서비스 제공자(M2M 서비스 제공자는 MNO 가입자 임)가 자신의 고객과 가질 수 있는 계약 관계에 편승할 의도는 아니다.
MNO가 스왑(swap)되는 동안, 도너(Donor) 및 리시빙 MNO는 서로 사전 계약이 있을 수도 있고 없을 수도 있다. 사전 계약을 승인할 수 있는 메커니즘이 있어야 한다. 도너 오퍼레이터의 정책 제어(Policy Control) 기능은 자신의 크레덴셜의 제거 조건에 대하여 정의할 수 있으며, 정책 제어 기능(Policy Control Function; PCF)이 이러한 기능을 구현할 수 있다.
아키텍처는 SM이라고 정의되는 기능을 도입하며, SM의 주요한 역할은 MNO 크레덴셜을 포함하는 패키지 또는 프로파일을 준비해서 eUICC로 전달하는 것이다. SM 기능은 MNO에 의하여 직접적으로 제공될 수도 있고, MNO가 SM 서비스를 획득하기 위하여 제3 기관과 계약할 수도 있을 것이다.
SM의 역할은 SM-SR, SM-DP와 같은 2개의 서브 기능으로 나뉘어 질 수 있다.
실제로, 이러한 SM-SR, SM-DP 기능들은 다른 엔터티에 의하여 제공될 수도 있고, 동일한 엔터티에 의해서 제공될 수도 있다. 따라서, SM-DP와 SM-SR의 기능을 명확하게 경계지을 필요가 있고, 이들 엔터티들 사이의 인터페이스를 정의할 필요가 있다.
SM-DP는 eUICC로 전달될 패키지 또는 프로파일의 안전한 준비를 담당하며, 실제 전송을 위하여 SM-SR과 함께 동작한다. SM-DP의 핵심 기능은 1) eUICC의 기능적 특성 및 인증 레벨(Certification Level)을 관리하는 것과, 2) MNO 크레덴셜 또는 프로파일(예를 들면, IMSI, K, 부가 서비스 어플리케이션, 부가 서비스 데이터 중 하나 이상이며, 이들 중 일부는 잠재적으로 MNO에 의하여 암호화(Enciphered)되어 있을 수 있음)을 관리하는 것과, 3) SM-SR에 의한 다운로드를 위하여 OTA 패키지를 계산하는 기능 등이며, 추후 부가적인 기능이 추가될 수 있을 것이다.
만일, SM-DP 기능이 제3주체(Third party)에 의하여 제공되는 경우에는 보안과 신뢰 관계가 아주 중요해진다. SM-DP는 실시간 프로비저닝(Provisioning) 기능 이외에도 상당한 정도의 백그라운드 프로세싱 기능을 보유할 수 있으며, 퍼포먼스, 스캐러빌러티(Scalability) 및 신뢰도에 대한 요구사항이 중요할 것으로 예상된다.
SM-SR은 크레덴셜 패키지를 해당되는 eUICC로 안전하게 라우팅하고 전달하는 역할을 담당한다. SM-SR의 핵심 기능은 1) 사이퍼(Ciphered)된 VPN을 통한 eUICC와의 OTA 통신을 관리하는 것과, 2) eUICC까지 엔드-투-엔드(end-to-end)를 형성하기 위하여 다른 SM-SR과의 통신을 관리하는 기능과, 3) eUICC 공급자에 의하여 제공되는 SM-SR OTA 통신을 위해 사용되는 eUICC 데이터를 관리하는 기능과, 4) 오직 허용된 엔터티만을 필터링함으로써 eUICC와의 통신을 보호하는 기능(방화벽 기능) 등이다.
SM-SR 데이터베이스는 eUICC 벤더와 장치(M2M 단말 등) 벤더 및 잠재적으로 MNO에 의하여 제공되며, SM-SR 메시 네트워크를 통해서 MNO에 의하여 사용될 수 있다.
신뢰 서클(Circle of trust)은 프로비저닝 프로파일 전달 동안 엔드-투-엔드 시큐리티 링크를 가능하게 하며, SM-SR은 프로비저닝 프로파일의 안전한 라우팅 및 eUICC 디스커버리를 위하여 신뢰 서클을 공유한다. MNO는 신뢰 써클내의 SM-SR 및 SM-DP 엔터티와 링크될 수 있으며, 자체적으로 이런 기능을 제공할 수도 있을 것이다. 고객과 관련된 MNO의 계약상 및 법률상 의무를 어기지 않고, eUICC의 불법적인 사용(클로닝, 크레덴셜의 불법 사용, 서비스 거부, 불법적인 MNO 컨텍스트 변경 등)을 방지하기 위하여, eUICC와 MNO 크레덴셜 사이의 안전한 엔드-투-엔드 링크가 필요하다.
즉, 도 1에서 110은 SM들 끼리, 더 구체적으로는 SM-SR 멤버 사이에 형성되는 신뢰 서클을 나타내고, 120은 MNO 파트너들의 신뢰 서클이며, 130은 엔드투엔드 신뢰 링크를 도시한다.
도 2는 SM 분리 환경에서 SM-SR 및 SM-DP가 시스템에 위치하는 구성을 도시한다.
도 2와 같이, SM은 eUICC와 관련된 여러 프로파일(MNO의 오퍼레이션 프로파일, 프로비저닝 프로파일 등)을 안전하게 준비하는 SM-DP와, 그를 라우팅하기 위한 SM-SR로 구분되며, SM-SR은 다른 여러 SM-SR과 신뢰관계로 연동될 수 있고, SM-DP는 MNO 시스템에 연동되어 있다.
물론, SM-DP와 MNO 시스템의 배치는 도 2와 다르게 구현될 수 있다. (즉, SM-DP가 SM-SR과 연동되고, MNO 시스템이 SM-DP와 연동될 수 있다)
도 3은 본 발명이 적용되는 시스템에서 제1차 가입에 해당되는 프로비저닝 과정의 전체 흐름도이다.
프로비저닝 과정에서, eUICC는 기기 식별 정보 (IMEI 등)와 eUICC 식별 정보 (eICCid 등)를 포함하는 활성화 요청을 MNO로 전송한다.(Request activation; S310) 그런 다음, S320단계에서 MNO와 eUICC 사이에는 eUICC 상태 요청 및 기술적 능력 제어 요청/확인이 수행된다.(eUICC status request 및 technical capability control; S320)
또한, 도시하지는 않았지만, 상기 S320 단계에서는 아래에서 설명할 바와 같이, eUICC가 자신의 공개키(PK) 또는 프로파일 접근 크레덴셜 정보인 PKI 키정보(키 생성 알고리즘, 키 길이, 키 생성 방식 등)를 해당 MNO 시스템 또는 SM-SR로 제공하는 과정이 포함될 수 있다.
S330단계에서 MNO는 SM-SR과 사이에서 eUICC 아이덴터티 검증과, 장치(eUICC)에 대한 정보를 수집한다(eUICC identity verification 및 collect information about device). S330단계에서, MNO는 본 발명의 일 실시예에 의하여 해당 eUICC에 대한 암호화 키, 구체적으로는 eUICC에 대응되는 공개키를 SM-SR로부터 획득할 수 있다.
이러한 공개키의 획득은 정적(static) 또는 동적(Dynamic)으로 이루어질 수 있는바, 정적으로 이루어지는 경우 eUICC 제조시에 이미 해당 eUICC 내부적으로, 세부적으로는 eUICC 내의 암호 연산 프로세서 (CCP 등)를 통해 공개키와 비밀키가 생성되어 eUICC에는 비밀키가 저장되고, 공개키는 모든 SM-SR이 공유함으로써 특정한 eUICC에 대한 공개키를 인식할 수 있도록 하고, MNO로부터 요청이 있는 경우 SM-SR은 해당되는 eUICC에 대한 공개키를 MNO로 전달하는 방식이다.
동적인 암호키 획득방법은 아래에서 도 8 및 도 9와 관련하여 설명할 바와 같이, MNO로부터 요청(특정 eUICC 식별정보 포함)이 있는 경우, SM-SR은 해당되는 eUICC에게 공개키 전송을 요청하고, 해당 eUICC는 eUICC 탑재 단말 내의 발급 처리 모듈(이 용어에 한정되지 않으며, 통신모듈, 프로비저닝 모듈, 발급 모듈, 개통 모듈 등으로 칭할 수 있으며, eUICC 프로비저닝을 위한 eUICC 탑재 단말 외부와의 통신 및 프로비저닝 관리의 역할을 수행함) 또는 eUICC 내의 보안모듈(암호키 생성 모듈, 암호키 처리 모듈, Security Policy 모듈, Credential Manager, Profile Manager 등 eUICC 내의 암호키 생성 및 암호키를 활용한 보안 연산을 수행하는 모듈)을 이용하여 공개키를 생성한 후 SM-SR로 전달하는 방식으로 수행될 수 있다. 이에 대해서는 아래에서 더 상세하게 설명한다.
여기서, eUICC 내에 탑재되는 보안모듈은 eUICC 제작 단계 또는 그 이후 eUICC 정책에 따라 eUICC 내에 공통적으로 1개가 설치될 수 있으며, eUICC 정책 및 각 MNO 정책에 따라 각 MNO 별로 여러 개가 설치될 수 있다.
해당 eUICC의 공개키(암호키)를 획득한 MNO는 SM-DP를 통해서 MNO에 맞는 새로운 eUICC 프로파일을 생성하고 그 프로파일을 획득한 eUICC 공개키(암호키)로 암호화한 후 MNO로 전달한다.(1차 암호화, S340 단계) 이때, 인증성(Authenticity)을 제공하기 위해 SM-DP는 자신의 개인키로 추가적인 전자서명을 생성할 수 있다. 즉, S340 단계에서 SM-DP는 인증을 위한 자신의 개인키 또는 비밀키로 프로파일을 전자서명(Sign)할 수 있다.
다음으로, MNO는 1차 암호화된 (eUICC) 프로파일을 SM-SR로 전달한 후 2차 암호화를 요청하면, SM-SR은 이미 저장하고 있는 eUICC 관리키(eUICC OTA 키, GP ISD 키 등)를 이용하여 eUICC 프로파일을 2차 암호화하여 MNO로 전달한다.(S350 단계)
그런 다음, MNO는 이중 암호화(Double Ciphered)된 eUICC 프로파일을 해당 eUICC로 전송한다.(S360 단계) 이때, 인증성을 제공하기 위해 SM-DP의 공개키 또는 인증서(Certification)를 함께 eUICC로 전송할 수 있다.
eUICC는 이미 eUICC 관리키를 알고 있으므로 1차로 복호화한 후, 자신 공개키에 대응되는 비밀키(제조 또는 공개키 동적 생성 단계에서 이미 알고 있음)를 이용하여 2차 복호화함으로써 프로비저닝에 사용될 프로파일을 완전히 복호화 할 수 있다. 이때, eUICC는 인증서 확인 (MNO로부터 획득한 공개키에 해당되는 SM-DP로부터 생성된 eUICC 프로파일인지 확인하기 위해)을 위해 SM-DP의 공개키 (인증서의 경우, 신뢰할 수 있는 제 3의 개체로부터 해당 인증서의 유효성을 검증 받을 수 있음)로 서명 검증을 수행할 수 있다.
S370 단계에서는 프로비저닝을 종료한 eUICC와 SM-SR 사이에서 상태 요청과 그에 대한 응답에 의하여 SM-SR 데이터베이스를 업데이트 한다.
이러한 각 단계에 대한 주요 구성을 추가로 설명하면 다음과 같다.
S310단계에서, eUICC 식별 정보(eICCid 등)는 공개된 데이터이며 eUICC 내부에 통합 보호되어야 한다.
S320, S330단계에서 상태 요청 및 기술적 가능성 제어는 eUICC 아이덴터티의 증명을 제공(신뢰할 수 있는 eUICC)하며, MNO 서비스를 위한 eUICC 특성의 적격성을 확인할 수 있어야 한다.
S340~S360 단계에서는 eUICC 프로파일 생성 및 전송을 위하여 이중 암호화 메커니즘이 사용된다. 즉, SM-DP에 의하여 eUICC에 링크된 생성 프로파일은 오직 목표 eUICC에 의해서만 읽힐 수 있는 암호화 메커니즘에 의하여 암호화되며, 정당한 SM-DP로부터 생성된 프로파일임을 확인하기 위해 SM-DP에 의해 전자서명이 수행될 수 있고, SM-SR은 생성 프로파일을 eUICC 관리키로 암호화하여 전달 동안 eUICC를 인증하고 보호한다.
S370 단계에서, SM-SR 데이터베이스는 가입 설치(Subscription installation)의 마무리 단계에서 업데이트 될 수 있다.
도 4는 본 발명이 적용되는 가입 변경 또는 MNO 변경 과정의 전체 흐름도이다.
전체적으로는 도 3의 프로비저닝 과정과 유사(즉, 변경 후 새로운 MNO가 도 3의 MNO에 해당)하며, 다만 새로운 MNO에 대한 프로파일 생성 전후에 새로운 MNO가 도너 MNO에게 협상 및 권리 전송 과정을 수행하는 점이 상이하다.(단계 S440’)
즉, 도 4의 MNO 변경과정과 도 3의 프로비저닝 과정을 차이점은, 프로비저닝 또는 오퍼레이션 액티브 프로파일을 이용하여, 액티베이션 요청이 도너 MNO OTA 베어러(Bearer)로 전송되고, 새로운 MNO는 OTA 또는 OTI 중 하나로 새로운 프로파일을 다운로드 하도록 SM-SR로부터 경로를 요청하는 것이다.
도 4에 의한 MNO 변경 과정을 구체적으로 설명하면 다음과 같다.
MNO 변경을 위하여, eUICC는 기기 식별 정보 (IMEI 등)와 eUICC 식별 정보 (eICCid 등)를 포함하는 활성화 요청을 변경될 MNO(Receiving MNO)로 전송한다.(Request activation; S410) 그런 다음, S420단계에서 리시빙 MNO와 eUICC 사이에는 eUICC 상태 요청 및 기술적 능력 제어 요청/확인이 수행된다.(eUICC status request 및 technical capability control; S420)
또한, 도시하지는 않았지만, 상기 S420 단계에서는 아래에서 설명할 바와 같이, eUICC가 자신의 공개키(PK) 또는 프로파일 접근 크레덴셜 정보인 PKI 키정보(키 생성 알고리즘, 키 길이, 키 생성 방식 등)를 해당 MNO 시스템 또는 SM-SR로 제공하는 과정이 포함될 수 있음은 프로비저닝 과정인 S320과 동일하다.
S430단계에서 리시빙 MNO는 SM-SR과 사이에서 eUICC 아이덴터티 검증과, 장치(eUICC)에 대한 정보를 수집한다(eUICC identity verification 및 collect information about device). S430단계에서, MNO는 본 발명의 일 실시예에 의하여 해당 eUICC에 대한 암호화 키, 구체적으로는 eUICC에 대응되는 공개키를 SM-SR로부터 획득할 수 있다. .
여기서, eUICC 내에 탑재되는 보안모듈은 eUICC 제작 단계 또는 그 이후 eUICC 정책에 따라 eUICC 내에 공통적으로 1개가 설치될 수 있으며, eUICC 정책 및 각 MNO 정책에 따라 각 MNO 별로 여러 개가 설치될 수 있다.
해당 eUICC의 공개키(암호키)를 획득한 리시빙 MNO는 SM-DP를 통해서 MNO에 맞는 새로운 eUICC 프로파일을 생성하고 그 프로파일을 획득한 eUICC 공개키(암호키)로 암호화한 후 MNO로 전달한다.(1차 암호화, S440 단계) 이때, 인증성(Authenticity)을 제공하기 위해 SM-DP는 자신의 개인키로 추가적인 전자서명을 생성할 수 있다. 즉, S440 단계에서 SM-DP는 인증을 위한 자신의 개인키 또는 비밀키로 프로파일을 전자서명(Sign)할 수 있다.
또한, S440 단계 이전 또는 이후에 협상 및 권리 전송 단계(S440’)가 수행될 수 있다. 이러한 협상 및 권리 전송 단계(S440’)는 새로운 리시빙 MNO가 이전 MNO(도너 MNO)에게 해당 eUICC가 정당한지 여부와, MNO 변경에 따른 권리(정보)를 이전해 줄 것을 요청하는 등의 과정이다.
즉, S440’ 단계에서는 새로운 MNO(Receiving MNO)가 가입 스위칭에 대해서 도너 MNO의 인증을 요청하며, 이러한 인증은 정책 제어 기능(Policy Control Function)에 의해서 제공될 수 있다.
다음으로, 리시빙 MNO는 1차 암호화된 (eUICC) 프로파일을 SM-SR로 전달한 후 2차 암호화를 요청하면, SM-SR은 이미 저장하고 있는 eUICC 관리키(eUICC OTA 키, GP ISD 키 등)를 이용하여 eUICC 프로파일을 2차 암호화하여 MNO로 전달한다.(S450 단계)
그런 다음, MNO는 이중 암호화(Double Ciphered)된 eUICC 프로파일을 해당 eUICC로 전송한다.(S460 단계) 이때, 인증성을 제공하기 위해 SM-DP의 공개키 또는 인증서(Certification)를 함께 eUICC로 전송할 수 있다.
eUICC는 이미 eUICC 관리키를 알고 있으므로 1차로 복호화한 후, 자신 공개키에 대응되는 비밀키(제조 또는 공개키 동적 생성 단계에서 이미 알고 있음)를 이용하여 2차 복호화함으로써 MNO 변경에 사용될 프로파일을 완전히 복호화 할 수 있다. 이때, eUICC는 인증서 확인 (MNO로부터 획득한 공개키에 해당되는 SM-DP로부터 생성된 eUICC 프로파일인지 확인하기 위해)을 위해 SM-DP의 공개키 (인증서의 경우, 신뢰할 수 있는 제 3의 개체로부터 해당 인증서의 유효성을 검증 받을 수 있음)로 서명 검증을 수행할 수 있다.
S470 단계에서는 프로비저닝을 종료한 eUICC와 SM-SR 사이에서 상태 요청과 그에 대한 응답에 의하여 SM-SR 데이터베이스를 업데이트 한다.
이상 도 1 내지 도 4의 방식을 다시 설명하면 아래와 같다.
eSIM은 단말 제조 단계에서 IC칩을 단말 회로판 상에 부착시킨 후, 소프트웨어 형태의 SIM 데이터 (개통 정보, 부가 서비스 정보 등)를 OTA (Over The Air) 또는 오프라인 (PC와의 USB 등의 기술 기반 연결)을 통해 발급하는 방식의 새로운 개념의 SIM 기술이다. eSIM에서 사용되는 IC칩은 일반적으로 하드웨어 기반의 CCP (Crypto Co-Processor)를 지원하여 하드웨어 기반의 공개키 생성을 제공하며, 이를 어플리케이션 (예, 애플릿) 기반에서 활용할 수 있는 API를 SIM 플랫폼 (예, Java Card Platform 등)에서 제공한다. Java Card Platform은 스마트카드 등에서 멀티 어플리케이션을 탑재하고 서비스를 제공할 수 있는 플랫폼 중 하나이다.
SIM은 제한된 메모리 공간과 보안상의 이유로 누구나 SIM 내에 어플리케이션을 탑재해서는 안되며, 이로 인해 어플리케이션 탑재를 위한 플랫폼 이외에 SIM을 어플리케이션 탑재 및 관리를 담당하는 SIM 서비스 관리 플랫폼을 필요로 한다. SIM 서비스 관리 플랫폼은 관리키를 통한 인증 및 보안을 통해 SIM 메모리 영역에 데이터를 발급하며, GlobalPlatform과 ETSI TS 102.226의 RFM (Remote File Management) 및 RAM (Remote Application Management)은 이와 같은 SIM 서비스 관리 플랫폼의 표준 기술이다.
eSIM 환경에서 중요한 요소 중의 하나인 SM은 eSIM은 원격으로 관리키를 통해 통신 및 부가 서비스 데이터를 발급하는 역할을 수행한다. GSMA에서는 SM의 역할을 SM-DP와 SM-SR로 분류하였다. SM-DP는 사업자 정보 (IMSI, K, OPc, 부가 서비스 데이터 등)를 안전하게 빌드하여 Credential Package 형태로 만드는 역할을 수행하며, SM-SR은 SM-DP가 생성한 Credential Package를 OTA 또는 GP SCP (Secure Communication Protocol)과 같은 SIM 원격 관리 기술을 통해 eSIM에 안전하게 다운로드하는 역할을 수행한다. 그리고 GSMA는 아래 그림의 “Circle of Trust”라는 구조를 제안하여 각 유사 개체들간 신뢰 관계의 중첩을 통해 MNO와 eSIM 간의 End-to-End 신뢰 관계를 구축한다는 개념을 제안하였다. 즉, MNO는 SM1과, SM1은 SM4, SM4는 eSIM과 신뢰관계를 형성하여, 이를 통해 MNO와 eSIM 간의 신뢰관계를 형성한다는 개념이다.
이렇게, GSMA에서 제안한 SM 역할 분리 환경은 SM에게 모든 사업적 주도권을 뺏길 수 있는 eSIM 환경에서 적절한 유연성 (모든 MNO가 각 MNO와 연동해야 하는 부분을 SM-SR을 통해 해결함)과 함께 사업주도권 확보 (SM-DP 역할은 일반적으로 MNO가 수행하게 될 것으로 보이며, SM-DP를 통해 통신 및 부가 서비스의 사업자 정보가 빌드됨)를 동반할 수 있는 이점이 있다.
하지만, eSIM 구조 상의 각 개체 (MNO, SM, eUICC, 단말 등) 간의 신뢰 관계를 형성하는 기술 방안이 필요하지만 현재는 존재하지 않는다.
따라서, 본 발명의 일 실시예에서는 제안 eSIM 구조에서 각 개체들 간의 신뢰관계를 형성하는 방안을 제시한다.
그러나, 본 발명은 전술한 도 3 및 4에 의한 프로비저닝 또는 MNO 변경 과정에 한정하여 적용되는 것은 아니며, 본 발명에서 정의하는 신뢰정보를 이용하여 eUICC와 관련된 개체 사이에 신뢰관계를 구축할 수 있는 한, 여하한 다른 환경 또는 시스템에도 적용될 수 있을 것이다.
도 5는 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 구조의 일 예를 도시한다.
본 발명에서 eSIM 구조에 참여하는 개체는 eSIM, eSIM 탑재 기기, SM (SM-SR, SM-DP 등) 및 MNO이며, 그 이외의 구성 요소들이 참여될 수 있다.
각 구성요소 중 eUICC 인프라에 해당되는 SM (SM-SR, SM-DP) 등은 신뢰기관에 의해 생성된 신뢰정보 (예, 인증서 등)를 HSM (Hardware Security Module) 등의 보안 장치에 저장하며, eUICC와 eUICC 탑재 기기는 신뢰정보 (예, 인증서 등)가 각 개체 내부에 (HSM 등의 보안장치와 같이 별도 개체가 아닌) 저장한다. 이 신뢰정보를 기반으로 개체들 간의 보안 통신 채널 (예, TLS/SSL 등)을 형성함으로써 각 요소들 간의 신뢰를 형성하게 된다.
각 개체에 부여되는 "신뢰정보"는 해당 개체에 대한 인증(Certification)에 대한 결과를 기술적으로 부여한 것이다. 즉, eSIM 자체에 대한 CC (Common Criteria-제품에 대한 Security 검증 표준 및 단체) 등의 검증 결과를 문서 형태로만 받는 것이 아니라 eSIM 내에 저장될 수 있는 디지털 형태의 기밀정보 (예, 비밀키 (대칭키), 인증서 등)로도 받는 것을 의미한다.
본 발명의 "신뢰정보"는 신뢰관계에 참여할 수 있는 자격을 갖춘 개체에게 부여되는 디지털 정보로 인증서, 보안키, 토큰정보 등의 형태가 될 수 있으며, 보안정보/인증정보/토큰정보 등으로 불릴 수 있다.
본 발명의 "검증정보"는 “신뢰정보”를 통해 각 개체를 인증할 목적으로 생성된 디지털 정보로 인증정보/토큰정보/전자서명/MAC 등으로 불릴 수 있다.
이러한 검증정보의 생성의 한 예로써, 난수 (Random Number)와 같은 임의의 정보 또는 공개 가능한 식별 정보 등과 공유된 신뢰정보를 입력으로 해쉬 함수 연산을 수행하는 것이 있을 수 있다. 이때, 상대방 개체로 전송되는 정보는 생성된 난수 또는 공개 가능한 식별정보 등과 해쉬 결과값이다. 이 정보를 받은 상대방은 전달받은 난수 또는 공개 가능한 식별정보 등과 공유된 신뢰정보를 통해 해당 "검증정보"가 자신과 신뢰관계를 형성할 개체에서 생성한 것인지 동일한 생성 연산을 수행함으로써 확인할 수 있다.
검증정보의 생성의 다른 예로서, 자신의 "신뢰정보"가 인증서일 경우, 자신의 개인키(신뢰정보에 해당함)로 난수와 같은 임의의 정보 또는 공개 가능한 식별 정보에 대해서 전자서명을 통해 "검증정보"를 생성하여, 상대방에게 전송하면 상대방은 함께 전송된 또는 공개된 인증서를 활용하여 "검증정보"를 전자서명 기반으로 검증함으로써 해당 "검증정보"가 자신과 신뢰관계를 형성할 개체 의해서 생성된 것인지 확인할 수 있다.
도 5에서 eUICC 인증기관과 eUICC 인프라 인증기관은 통합될 수도 분리되거나 세분화될 수도 있다.
도 6은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 흐름의 일 예를 도시한다.
본 발명의 동작은 도 5의 구조를 근간으로 각 화살표가 의미하는 흐름을 설명한다. 본 발명에서 기본적인 각 개체 간의 신뢰관계 형성은 도 6과 같이 진행될 수 있다.
도 6을 참조하면, 통신 시스템 내 복수의 개체(개체 1(Entity 1), 개체 2(Entity 2)) 간의 신뢰관계 형성 방법으로서, 복수의 개체(개체 1, 개체 2) 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 단계(S610)와, 복수의 개체(개체 1, 개체 2) 각각이, 각자 생성된 검증정보를 상대방 개체로 전송하여 각자 생성된 검증정보를 상호 교환하는 단계(S620)와, 복수의 개체(개체 1, 개체 2) 각각이, 해당 신뢰정보를 토대로 상대방 개체로부터 전송받은 검증정보를 검증함으로써 상대방 개체를 인증함으로써, 복수의 개체간 신뢰관계를 형성하는 단계(S640) 등을 포함한다.
전술한 S610 단계에서, 개체 1은 전달받거나 공유된 신뢰정보(신뢰정보 1)를 토대로 검증정보를 생성하고, 개체 2는 전달받거나 공유된 신뢰정보(신뢰정보 2)를 토대로 검증정보를 생성한다.
S620 단계에서, 개체 1은 자신(개체 1)이 생성한 검증정보를 상대방 개체(개체 2)로 전송하고, 개체 2는 자신(개체 2)이 생성한 검증정보를 상대방 개체(개체 1)로 전송함으로써, 개체 1과 개체 2는 자신이 생성한 검증정보를 서로 교환한다.
이러한 S620 단계에서, 복수의 개체(개체 1, 개체 2)는, 각자의 신뢰정보가 인증서인 경우 검증정보와 함께 신뢰정보를 상대방 개체에게 전송할 수 있다.
이 경우, 복수의 개체 간의 신뢰관계 형성 방법은, S620 단계 이후, 복수의 개체(개체 1, 개체 2)는 상대방 개체로부터 전송받은 신뢰정보(타 개체의 신뢰정보)의 유효성, 신뢰성 등을 해당 신뢰정보를 발행한 인증기관에 문의하여 신뢰정보에 대한 검증을 수행하는 단계(S630)를 더 포함할 수도 있다. 즉, 개체 1은 개체 2로부터 전송받은 개체 2의 신뢰정보(신뢰정보 2)를 검증하고, 개체 2는 개체 1로부터 전송받은 개체 1의 신뢰정보(신뢰정보 1)를 검증한다.
이후, S640 단계에서, 개체 1은 개체 2로부터 전송받은 검증정보를 검증함으로써 개체 2를 인증하고, 개체 2는 개체 1로부터 전송받은 검증정보를 검증함으로써 개체 1을 인증함으로써, 개체 1과 개체 2 간의 신뢰관계를 형성할 수 있다.
아래에서는, 도 6을 참조하여 전술한 기본적인 개체 간의 신뢰관계 형성 방법의 각 단계에 대하여 더욱 상세하게 설명한다.
[S610 단계] 각 개체는, 인증기관으로부터 전달받은 신뢰정보(개체 자신의 신뢰정보에 해당할 수 있음)를 토대로 검증정보를 생성한다.
이때, 검증정보는, 타 개체와 공유된 신뢰정보와 자신이 생성한 난수 또는 공개 가능한 식별 정보 등을 해시 함수(Hash Function)의 입력으로 하여 생성된 결과값이 될 수 있다. 또는 검증정보는 자신의 개인키(신뢰정보에 해당할 수 있음)로 자신이 생성한 난수 또는 공개 가능한 식별 정보 등에 대해서 전자서명 연산을 수행한 결과값이 될 수도 있다.
[S620 단계] 각 개체는 난수 또는 공개 가능한 식별정보와 생성된 검증정보를 상호 교환한다.
이때, 신뢰정보가 인증서일 경우, 상대방에게 신뢰정보(개체 자신의 신뢰정보일 수 있음)를 함께 전송할 수 있다.
S630 단계: 각 개체는 신뢰정보가 인증서일 경우, 타 개체의 신뢰정보의 유효성, 신뢰성 등을 해당 신뢰정보를 발행한 인증기관에 문의하여 검증을 수행한다. 단, 이 S630 단계는 신뢰정보가 대칭키일 경우에는 생략될 수 있다.
[S640 단계] S630 단계가 성공적으로 완료되면, 각 개체는, 해당 신뢰정보를 토대로 상대방 개체의 검증정보를 검증함으로써 서로를 인증하고, 이를 통해 각 개체 간의 신뢰관계를 형성한다.
이때, 신뢰정보는 대칭키(비밀키) 또는 인증키(공개키)일 수 있는 데, 만약, 신뢰정보가 대칭키일 경우에, 각 개체는 상대방 개체로부터 전달받은 난수와 공개 가능한 식별 정보에 대해서 동일하게 해시 함수를 수행한 후, 그 결과를 상대방 개체로부터 전달받은 검증정보와 비교함으로써 상대방 개체로부터 전달받은 검증정보에 대한 검증을 수행할 수 있다. 만약, 신뢰정보가 인증서일 경우, 각 개체는 상대방 개체로부터 전달받은 검증정보에 대해 인증서(공개키)로 복호화한 후, 상대방 개체로부터 전달받은 난수 또는 공개 가능한 식별정보의 해시값과 자신이 인증서(공개키)로 복호화된 결과값이 동일한지 확인함으로써 상대방 개체로부터 전달받은 검증정보에 대한 검증을 수행할 수 있다.
도 6에서 복수의 개체는, eUICC 및 eUICC 탑재 기기이거나, eUICC 및 SM-SR 이거나, SM-SR 및 SM-SR 이거나, MNO 및 SM-SR 이거나, MNO 및 SM-DP 이거나, SM-SR 및 SM-DP 등 일 수 있다.
한편, 구체적으로, eUICC, eUICC 탑재 기기, SM-SR, SM-DP, MNO 등의 특정 개체 사이의 신뢰관계를 구축하는 방법의 예를 도 5를 참조하여 설명한다.
도 5에 도시된 바와 같이, eUICC, eUICC 탑재 기기, SM-SR, SM-DP, MNO 등의 특정 개체 사이의 신뢰관계를 구축하는 방법은, eUICC 및 eUICC 탑재 기기 간의 신뢰관계 형성 단계(S510), eUICC 및 SM-SR 간의 신뢰관계 형성 단계(S520), SM-SR 간의 신뢰관계 형성 단계(S530), MNO 및 SM-SR 간의 신뢰관계 형성 단계(S540), MNO 및 SM-DP 간의 신뢰관계 형성 단계(S550), SM-SR 및 SM-DP 간의 신뢰관계 형성 단계(S560)를 포함하고, eUICC 및 eUICC 탑재 기기 간의 신뢰관계 형성 단계(S510), MNO 및 SM-SR 간의 신뢰관계 형성 단계(S540), MNO 및 SM-DP 간의 신뢰관계 형성 단계(S550) 등을 더 포함할 수 있다.
1. eUICC 및 eUICC 탑재 기기 간의 신뢰관계 형성 단계(S510)
eUICC 및 eUICC를 탑재한 eUICC 탑재 기기 각각이, 상대방의 신뢰정보를 토대로 상호 인정함으로써, eUICC 및 eUICC 탑재 기기 간의 신뢰관계가 형성된다.
더 상세하게, eUICC와 eUICC 탑재 기기는 각각에 발행된 신뢰정보를 토대로 상호 인증을 수행한다. 상호 인증을 위해서 각 개체는 타 개체의 신뢰정보의 유효성, 신뢰성 등을 해당 인증기관에 온라인으로 (OTA 또는 OTI) 문의할 수 있다. 하지만, eUICC는 통신 기능이 부재하기에 eUICC와 eUICC 탑재 기기 간의 상호 인증 시, eUICC 탑재 기기의 신뢰정보 검증은 eUICC에 선 탑재(제조 또는 발급(Provisioning) 단계에서 탑재된)된 eUICC 탑재 기기의 공개 신뢰정보(예: PK (Public Key Cryptography)의 공개키 등)를 토대로 진행된다. 또는 eUICC의 요청에 따라 eUICC 탑재 기기를 통해 신뢰기관과 통신하여 eUICC 탑재 기기의 신뢰정보를 검증할 수 있다.
2. eUICC 및 SM-SR 간의 신뢰관계 형성 단계(S520)
eUICC 및 SM-SR 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써, eUICC 및 SM-SR 간의 신뢰관계가 형성된다.
S520 단계에서, eUICC와 SM-SR 간의 신뢰관계는, 도 6과 같은 방식에 따라 형성될 수 있다. eUICC와 SM-SR 간의 신뢰관계가 도 6과 같은 방식에 따라 형성되는 경우, 아래에서 S520 단계에 대하여 설명한다.
S520 단계에서, eUICC 및 SM-SR 각각은, 난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 검증정보로서 생성한다.
또한, S520 단계에서, eUICC 및 SM-SR 각각은, 검증정보 이외에, 난수 또는 공개 가능한 식별 정보를 상대방에게 더 전송할 수 있다. 또한, eUICC 및 SM-SR 각각은, 신뢰정보가 인증서인 경우, 신뢰정보를 더 전송할 수도 있다.
한편, S520 단계에서, eUICC 및 SM-SR 각각은, 검증정보를 상대방에게 전송한 이후, 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, 상대방의 신뢰정보에 대한 유효성 및 신뢰성을 검증할 수 있다. 이러한 신뢰정보의 검증은 신뢰정보가 대칭키인 경우에는 생략될 수 있다.
그리고, S520 단계에서, eUICC 및 SM-SR 각각은,상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써 eUICC 및 SM-SR 간의 신뢰관계가 형성될 수도 있고, 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 전송된 검증정보를 검증하여 상대방을 인증함으로써 eUICC 및 SM-SR 간의 신뢰관계가 형성될 수 있다.
3. SM-SR 간의 신뢰관계 형성 단계(S530)
SM-SR 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써, SM-SR 간의 신뢰관계가 형성된다.
S530 단계에서, SM-SR 간의 신뢰관계는, 도 6과 같은 방식에 따라 형성될 수 있으며, TLS/SSL 등의 보안통신 프로토콜을 통해서도 신뢰관계를 형성할 수 있다.
SM-SR 간의 신뢰관계가 도 6과 같은 방식에 따라 형성되는 경우, 아래에서, S530 단계에 대하여 설명한다.
S530 단계에서, SM-SR들 각각은, 난수 또는 공개 가능한 식별 정보와 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 검증정보로서 생성할 수 있다.
또한, S530 단계에서, SM-SR들 각각은, 검증정보 이외에, 난수 또는 공개 가능한 식별 정보를 상대방에게 더 전송할 수 있으며, 신뢰정보가 인증서인 경우, 신뢰정보를 더 전송할 수도 있다.
한편, S530 단계에서, SM-SR들 각각은, 검증정보를 상대방에게 전송한 이후, 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, 상대방의 신뢰정보에 대한 유효성 및 신뢰성을 검증할 수 있다. 이러한 신뢰정보의 검증은 신뢰정보가 대칭키인 경우에는 생략될 수 있다.
그리고, S530 단계에서, SM-SR들 각각은, 상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써 SM-SR들 간의 신뢰관계가 형성되거나, 전송받은 검증정보에 대해인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 전송된 검증정보를 검증하여 상대방을 인증함으로써 SM-SR들 간의 신뢰관계가 형성될 수 있다.
4. MNO 및 SM-SR 간의 신뢰관계 형성 단계(S540)
MNO(Mobile Network Operator MNO)가 상기 SM-SR의 신뢰정보를 토대로 SM-SR을 단방향으로 인증함으로써, MNO 및 SM-SR 간의 신뢰관계가 형성된다.
이 단계에서, MNO는 SM-SR의 신뢰정보를 토대로 단방향 인증을 수행하여 MNO 및 SM-SR 간의 신뢰관계가 형성되는데, 그 이유는, MNO가 eUICC에서 신뢰 가능한 요소(개체)이고 고객 정보의 근원이므로, MNO에 대한 인증은 필요하지 않을 수 있기 때문이다. 하지만, 경우에 따라서, MNO 인증서를 토대로 상호 인증이 일어날 수도 있다.
5. MNO 및 SM-DP 간의 신뢰관계 형성 단계(S550)
MNO가 SM-DP의 신뢰정보를 토대로 상기 SM-DP를 단방향으로 인증함으로써, MNO 및 SM-DPR 간의 신뢰관계가 형성된다.
이 단계에서, MNO는 SM-DP의 신뢰정보를 토대로 단방향 인증을 수행하여 MNO 및 SM-DP 간의 신뢰관계가 형성되는데, 그 이유는, MNO가 eUICC에서 신뢰 가능한 요소(개체)이고 고객 정보의 근원이므로, MNO에 대한 인증은 필요하지 않을 수 있기 때문이다. 하지만, 경우에 따라서, MNO 인증서를 토대로 상호 인증이 일어날 수도 있다.
6. SM-SR 및 SM-DP 간의 신뢰관계 형성 단계(S560)
SM-SR 및 SM-DP 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써, SM-SR 및 SM-DP 간의 신뢰관계가 형성된다.
S560 단계에서, SM-SR과 SM-DP 간의 신뢰관계는, 도 6의 방식에 따라 신뢰관계가 형성될 수 있으며, TLS/SSL 등의 보안통신 프로토콜을 통해서도 신뢰관계가 형성될 수도 있다.
SM-SR과 SM-DP 간의 신뢰관계가 도 6과 같은 방식에 따라 형성되는 경우, 아래에서, S530 단계에 대하여 설명한다.
S560 단계에서, SM-SR과 SM-DP 각각은, 난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성할 수 있다.
또한, S560 단계에서, SM-SR과 SM-DP 각각은, 검증정보 이외에, 난수 또는 공개 가능한 식별 정보를 상대방에게 더 전송할 수 있으며, 신뢰정보가 인증서인 경우, 신뢰정보를 더 전송할 수도 있다.
한편, S560 단계에서, SM-SR과 SM-DP 각각은, 검증정보를 상대방에게 전송한 이후, 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, 상대방의 신뢰정보에 대한 유효성 및 신뢰성을 검증할 수도 있다. 이러한 신뢰정보의 검증은 신뢰정보가 대칭키인 경우에는 생략될 수 있다.
그리고, S560 단계에서, SM-SR과 SM-DP 각각은, 상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증함으로써 SM-SR과 SM-DP 간의 신뢰관계가 형성되거나, 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 전송된 검증정보를 검증하여 상대방을 인증함으로써 SM-SR과 SM-DP 간의 신뢰관계가 형성될 수 있다.
아래에서는, 이상에서 설명한 개체 간의 신뢰관계 형성 방법을 eUICC 관점에서 다시 설명한다. 그 내용은 이상에서의 내용과 동일하다.
도 7은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 중 eUICC 및 SM-SR 간 신뢰관계 형성 방법에 대한 흐름도이다. 이러한 도 7의 흐름도는, eUICC를 동작 주체로 하여, 도 5의 S510 단계를 상세하게 나타낸 흐름도이다.
도 7을 참조하면, 본 발명의 일 실시예에 따른 eUICC 및 SM-SR 간 신뢰관계 형성 방법은, eUICC가 검증정보를 생성하는 단계(S700), eUICC가 생성한 검증정보를 SM-SR로 전송하고 SM-SR로부터 SM-SR에서 생성된 검증정보를 전송받는 단계(S702), eUICC가 신뢰정보를 검증하는 단계(S704), eUICC가 SM-SR로부터 전송받은 검증정보를 검증하는 단계(S706) 등을 포함한다.
검증정보 생성 단계(S700)에서, eUICC는, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성한다. 이때, 동일한 방식으로, SM-SR은 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성한다.
검증정보 교환 단계(S702)에서, eUICC는, 생성된 검증정보를 SM-SR이 eUICC를 인증하기 위한 정보로서 SM-SR로 전송하고, SM-SR에 의해 생성된 검증정보를 SM-SR로부터 전송받는다. 이때, 동일한 방식으로, SM-SR은 SM-SR에서 생성된 검증정보를 eUICC가 SM-SR를 인증하기 위한 정보로서 eUICC로 전송하고, eUICC에 의해 생성된 검증정보를 eUICC로부터 전송받는다.
검증정보 교환 단계(S702) 이후, 신뢰정보가 인증서일 경우, 더 수행될 수도 있는 신뢰정보 검증 단계(S704)에서, eUICC는, 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, SM-SR의 신뢰정보에 대한 유효성 및 신뢰성을 검증할 수 있다. 이때, 동일한 방식으로, SM-SR도, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, eUICC의 신뢰정보에 대한 유효성 및 신뢰성을 검증할 수 있다.
신뢰정보 검증 단계(S704)는, 신뢰정보가 대칭키일 경우에는 수행되지 않고, 검증정보 검증 단계(S706)가 바로 수행될 수도 있다.
검증정보 교환 단계(S702) 또는 신뢰정보 검증 단계(S704) 이후 수행되는 검증정보 검증 단계(S706)에서, eUICC는, 해당 신뢰정보를 토대로 SM-SR로부터 전송받은 검증정보를 검증함으로써 SM-SR을 인증할 수 있다. 이때, 동일한 방식으로, SM-SR은 해당 신뢰정보를 토대로 eUICC로부터 전송받은 검증정보를 검증함으로써 eUICC를 인증할 수 있다.
전술한 검증정보 생성 단계(S700)에서, eUICC는, 자신이 생성한 난수 또는 공개 가능한 식별 정보와 타 개체(SM-SR)과 공유된 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 검증정보로서 생성할 수 있다. 또는, 전술한 검증정보 생성 단계(S700)에서, eUICC는, 자신의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 검증정보로서 생성할 수도 있다. 이때, SM-SR도, 동일 방식으로 검증정보를 생성할 수도 있다.
전술한 검증정보 교환 단계(S702)에서, eUICC는, 검증정보 이외에 난수 또는 공개 가능한 식별 정보를 SM-SR로 더 전송하고, SM-SR로부터 상기 SM-SR에 의해 생성된 검증정보 이외에 난수 또는 공개 가능한 식별 정보를 더 전송받을 수 있다. 이때, SM-SR도, 동일 방식으로, 검증정보 이외에 난수 또는 공개 가능한 식별 정보를 eUICC로 전송하고 전송받을 수 있다.
한편, 신뢰정보가 인증서일 경우, 전술한 검증정보 교환 단계(S702)에서, eUICC는, 신뢰정보를 SM-SR로 더 전송하고, SM-SR로부터 SM-SR의 신뢰정보를 더 전송받을 수 있다. 이때, SM-SR도, 동일 방식으로 신뢰정보를 eUICC로 더 전송하고 더 전송받을 수 있다.
전술한 검증정보 검증 단계(S706)에서, eUICC는, 신뢰정보가 대칭키인 경우, SM-SR로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 S702 단계에서 SM-SR로부터 전송받은 검증정보를 비교함으로써, S702 단계에서 SM-SR부터 전송받은 검증정보를 검증하여 SM-SR을 인증할 수 있다. 또는, 전술한 검증정보 검증 단계(S706)에서, eUICC는, 신뢰정보가 인증서인 경우, S702 단계에서 전송받은 검증정보에 대해 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 인증서로 복호화된 결과값을 비교함으로써, S702 단계에서 SM-SR부터 전송받은 검증정보를 검증하여 SM-SR을 인증할 수도 있다.
아래에서는, 도 7을 참조하여 전술한 eUICC 및 SM-SR 간의 신뢰관계 형성 방법을 제공하는 eUICC에 대하여 설명한다.
도 8은 본 발명의 일 실시예에 의한 eUICC 환경에서의 개체간 신뢰관계 형성 중 eUICC 및 SM-SR 간 신뢰관계 형성을 위한 eUICC에 대한 블록도이다.
도 8을 참조하면, eUICC 및 SM-SR 간의 신뢰관계 형성을 위한 eUICC는, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 검증정보 생성부(810)와, 생성된 검증정보를 SM-SR이 eUICC를 인증하기 위한 정보로서 SM-SR로 전송하고, SM-SR에 의해 생성된 검증정보를 SM-SR로부터 전송받는 검증정보 교환부(820)와, 해당 신뢰정보를 토대로 SM-SR로부터 전송받은 검증정보를 검증함으로써 SM-SR을 인증하는 검증정보 검증부(840) 등을 포함한다.
검증정보 생성부(810)는 도 7에서의 검증정보 생성 단계(S700)를 수행하는 구성이고, 검증정보 교환부(820)는 도 7에서의 검증정보 교환 단계(S702)를 수행하는 구성이며, 신뢰정보 검증부(830)는 도 7에서의 신뢰정보 검증 단계(S704)를 수행하는 구성이고, 검증정보 검증부(840)는 도 7에서의 검증정보 검증 단계(S706)를 수행하는 구성이다.
전술한 검증정보 생성부(810)는, 자신이 생성한 난수 또는 공개 가능한 식별 정보와 타 개체(SM-SR)와 공유된 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 검증정보로서 생성하거나, 자신의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 검증정보로서 생성할 수도 있다.
검증정보 검증부(840)는, 신뢰정보가 대칭키인 경우, SM-SR로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 SM-SR로부터 전송받은 검증정보를 비교함으로써, SM-SR부터 전송받은 검증정보를 검증하여 SM-SR을 인증하거나, 신뢰정보가 인증서인 경우, 전송받은 검증정보에 대해 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, SM-SR부터 전송받은 검증정보를 검증하여 SM-SR을 인증할 수 있다.
한편, 도 8을 참조하면, eUICC 및 SM-SR 간의 신뢰관계 형성을 위한 eUICC는, 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, SM-SR의 신뢰정보에 대한 유효성 및 신뢰성을 검증하는 신뢰정보 검증부(830)를 더 포함할 수도 있다.
이상의 본 발명의 일 실시예를 이용하면, GSMA 제안 구조의 신뢰관계(Circle of Trust)를 기술적으로 형성할 수 있으며, 이를 토대로 eUICC 구조의 신뢰도와 안전성을 향상시킬 수 있다는 효과가 있다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시 예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시 예에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (15)

  1. eUICC(embedded Universal Integrated Circuit Card) 및 SM-SR(Subscription Manager-Secure Routing) 간의 신뢰관계 형성 방법으로서,
    상기 eUICC가 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 검증정보 생성 단계;
    상기 eUICC가 상기 생성된 검증정보를 상기 SM-SR이 상기 eUICC를 인증하기 위한 정보로서 상기 SM-SR로 전송하고, 상기 SM-SR에 의해 생성된 검증정보를 상기 SM-SR로부터 전송받는 검증정보 교환 단계; 및
    상기 eUICC가 해당 신뢰정보를 토대로 상기 SM-SR로부터 전송받은 검증정보를 검증함으로써 상기 SM-SR을 인증하는 검증정보 검증 단계를 포함하는 신뢰관계 형성 방법.
  2. 제1항에 있어서,
    상기 검증정보 생성 단계에서, 상기 eUICC는,
    난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 상기 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성하는 것을 특징으로 하는 신뢰관계 형성 방법.
  3. 제1항에 있어서,
    상기 검증정보 교환 단계에서, 상기 eUICC는,
    상기 검증정보 이외에 난수 또는 공개 가능한 식별 정보를 상기 SM-SR로 더 전송하고, 상기 SM-SR로부터 상기 SM-SR에 의해 생성된 검증정보 이외에 난수 또는 공개 가능한 식별 정보를 더 전송받는 것을 특징으로 하는 신뢰관계 형성 방법.
  4. 제3항에 있어서,
    상기 검증정보 교환 단계에서, 상기 eUICC는,
    상기 신뢰정보가 인증서일 경우, 상기 신뢰정보를 상기 SM-SR로 더 전송하고, 상기 SM-SR로부터 상기 SM-SR의 신뢰정보를 더 전송받는 것을 특징으로 하는 신뢰관계 형성 방법.
  5. 제1항에 있어서,
    상기 검증정보 검증 단계에서, 상기 eUICC는,
    상기 신뢰정보가 대칭키인 경우, 상기 SM-SR로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 SM-SR로부터 전송받은 검증정보를 비교함으로써, 상기 SM-SR부터 전송받은 검증정보를 검증하여 상기 SM-SR을 인증하거나,
    상기 신뢰정보가 인증서인 경우, 상기 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 SM-SR부터 전송받은 검증정보를 검증하여 상기 SM-SR을 인증하는 것을 특징으로 하는 신뢰관계 형성 방법.
  6. 제1항에 있어서,
    상기 검증정보 교환 단계 이후,
    상기 신뢰정보가 인증서일 경우, 상기 eUICC가, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, 상기 SM-SR의 신뢰정보에 대한 유효성 및 신뢰성을 검증하는 신뢰정보 검증 단계를 더 포함하는 신뢰관계 형성 방법.
  7. SM-SR(Subscription Manager-Secure Routing)과 신뢰관계 형성을 위한 eUICC(embedded Universal Integrated Circuit Card)으로서,
    상기 eUICC가 전달받거나 공유된 신뢰정보 또는 각자의 개인키를 토대로 검증정보를 생성하는 검증정보 생성부;
    상기 eUICC가 상기 생성된 검증정보를 상기 SM-SR이 상기 eUICC를 인증하기 위한 정보로서 상기 SM-SR로 전송하고, 상기 SM-SR에 의해 생성된 검증정보를 상기 SM-SR로부터 전송받는 검증정보 교환부; 및
    상기 eUICC가 해당 신뢰정보를 토대로 상기 SM-SR로부터 전송받은 검증정보를 검증함으로써 상기 SM-SR을 인증하는 검증정보 검증부를 포함하는 eUICC.
  8. 제7항에 있어서,
    상기 검증정보 생성부는,
    난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 상기 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성하는 것을 특징으로 하는 eUICC.
  9. 제7항에 있어서,
    상기 검증정보 검증부는,
    상기 신뢰정보가 대칭키인 경우, 상기 SM-SR로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 SM-SR로부터 전송받은 검증정보를 비교함으로써, 상기 SM-SR부터 전송받은 검증정보를 검증하여 상기 SM-SR을 인증하거나,
    상기 신뢰정보가 인증서인 경우, 상기 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 SM-SR부터 전송받은 검증정보를 검증하여 상기 SM-SR을 인증하는 것을 특징으로 하는 eUICC.
  10. 제7항에 있어서,
    상기 신뢰정보가 인증서일 경우, 신뢰정보 발행처인 인증기관과의 신뢰정보 문의 절차를 통해, 상기 SM-SR의 신뢰정보에 대한 유효성 및 신뢰성을 검증하는 신뢰정보 검증부를 더 포함하는 eUICC.
  11. 통신 시스템 내 복수의 개체 간의 신뢰관계 형성 방법으로서,
    복수의 개체 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하는 단계;
    상기 복수의 개체 각각이, 각자 생성된 검증정보를 상대방 개체로 전송하여 각자 생성된 검증정보를 상호 교환하는 단계; 및
    상기 복수의 개체 각각이, 해당 신뢰정보를 토대로 상대방 개체로부터 전송받은 검증정보를 검증함으로써 상대방 개체를 인증함으로써, 상기 복수의 개체간 신뢰관계를 형성하는 단계를 포함하는 신뢰관계 형성 방법.
  12. eUICC(embedded Universal Integrated Circuit Card) 및 SM-SR(Subscription Manager-Secure Routing) 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 eUICC 및 SM-SR 간 신뢰관계 형성 단계;
    SM-SR 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 SM-SR 및 SM-SR 간 신뢰관계 형성 단계; 및
    SM-SR 및 SM-DP(Subscription Manager-Data Preparation) 각각이, 전달받거나 공유된 신뢰정보를 토대로 검증정보를 생성하여 상대방에게 전송하고, 해당 신뢰정보를 토대로 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하는 SM-SR 및 SM-DP 간 신뢰관계 형성 단계를 포함하는 신뢰관계 형성 방법.
  13. 제12항에 있어서,
    상기 eUICC 및 상기 eUICC를 탑재한 eUICC 탑재 기기 각각이, 상대방의 신뢰정보를 토대로 상호 인정하는 eUICC 및 eUICC 탑재 기기 간 신뢰관계 형성 단계;
    MNO(Mobile Network Operator MNO)가 상기 SM-SR의 신뢰정보를 토대로 상기 SM-SR을 단방향으로 인증하는 MNO 및 SM-SR 간 신뢰관계 형성 단계; 및
    상기 MNO가 상기 SM-DP의 신뢰정보를 토대로 상기 SM-DP를 인증하는 MNO 및 SM-DPR 간 신뢰관계 형성 단계를 더 포함하는 신뢰관계 형성 방법.
  14. 제12항에 있어서,
    상기 eUICC 및 SM-SR 간 신뢰관계 형성 단계에서, 상기 eUICC 및 상기 SM-SR 각각은, 난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성하고,
    상기 SM-SR 및 SM-SR 간 신뢰관계 형성 단계에서 상기 SM-SR들 각각은, 난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성하며,
    상기 SM-SR 및 SM-DP 간 신뢰관계 형성 단계에서 상기 SM-SR 및 상기 SM-DP 각각은, 은, 난수 또는 공개 가능한 식별 정보와 상기 신뢰정보를 입력으로 해시(Hash) 함수 연산을 수행한 결과값을 상기 검증정보로서 생성하거나, 각자의 개인키로 생성한 난수 또는 공개 가능한 식별 정보에 대해서 전자 서명 연산을 수행한 결과값을 상기 검증정보로서 생성하는 것을 특징으로 하는 신뢰관계 형성 방법.
  15. 제12항에 있어서,
    상기 eUICC 및 SM-SR 간 신뢰관계 형성 단계에서, 상기 eUICC 및 상기 SM-SR 각각은, 상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하거나, 상기 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 전송된 검증정보를 검증하여 상대방을 인증하고,
    상기 SM-SR 및 SM-SR 간 신뢰관계 형성 단계에서, 상기 SM-SR들 각각은, 상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하거나, 상기 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 전송된 검증정보를 검증하여 상대방을 인증하며,
    상기 SM-SR 및 SM-DP 간 신뢰관계 형성 단계에서, 상기 SM-SR 및 상기 SM-DP 각각은, 상대방으로부터 전송받은 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상대방으로부터 전송받은 검증정보를 비교함으로써, 상대방으로부터 전송받은 검증정보를 검증하여 상대방을 인증하거나, 상기 전송받은 검증정보에 대해 상기 인증서로 복호화한 후, 난수 또는 공개 가능한 식별 정보에 대해서 해시 함수 연산을 수행한 결과값과 상기 인증서로 복호화된 결과값을 비교함으로써, 상기 전송된 검증정보를 검증하여 상대방을 인증하는 것을 특징으로 하는 신뢰관계 형성 방법.
PCT/KR2012/008970 2011-11-04 2012-10-30 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ WO2013066016A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/356,037 US9426654B2 (en) 2011-11-04 2012-10-30 Method for forming a trust relationship, and embedded UICC therefor
US15/216,917 US10091653B2 (en) 2011-11-04 2016-07-22 Method for forming a trust relationship, and embedded UICC therefor
US15/962,469 US10462668B2 (en) 2011-11-04 2018-04-25 Method for forming a trust relationship, and embedded UICC therefor

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2011-0114603 2011-11-04
KR20110114603 2011-11-04
KR1020120120292A KR101986312B1 (ko) 2011-11-04 2012-10-29 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ
KR10-2012-0120292 2012-10-29

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/356,037 A-371-Of-International US9426654B2 (en) 2011-11-04 2012-10-30 Method for forming a trust relationship, and embedded UICC therefor
US15/216,917 Continuation US10091653B2 (en) 2011-11-04 2016-07-22 Method for forming a trust relationship, and embedded UICC therefor

Publications (1)

Publication Number Publication Date
WO2013066016A1 true WO2013066016A1 (ko) 2013-05-10

Family

ID=48192317

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/008970 WO2013066016A1 (ko) 2011-11-04 2012-10-30 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ

Country Status (1)

Country Link
WO (1) WO2013066016A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014204231A1 (ko) * 2013-06-20 2014-12-24 Chang Dong Hoon 작은 메모리 구현 환경에 적합한 암호 인증 및 복호 검증 방법 및 전자 장치
JP2017500798A (ja) * 2013-12-05 2017-01-05 ▲華▼▲為▼▲終▼端有限公司 Ｅｕｉｃｃのためのセキュリティ制御方法およびｅｕｉｃｃ
CN109005032A (zh) * 2018-08-13 2018-12-14 中国联合网络通信集团有限公司 一种路由方法和装置
WO2022214796A1 (en) * 2021-04-06 2022-10-13 Pelion Iot Limited System and method for provisioning profiles

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020079349A (ko) * 2001-04-09 2002-10-19 피닉스 테크놀로지 리미티드 컴퓨터 디바이스 인증을 위한 방법 및 시스템
KR20040106098A (ko) * 2003-06-10 2004-12-17 홍상선 유비쿼터스 개인 상호인증 보안방법
KR20050074430A (ko) * 2002-07-18 2005-07-18 이오리지널 인크. 진정문서의 전달, 저장 및 회복에 대한 시스템 및 방법
KR20110020783A (ko) * 2008-06-02 2011-03-03 마이크로소프트 코포레이션 신뢰된 장치별 인증

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020079349A (ko) * 2001-04-09 2002-10-19 피닉스 테크놀로지 리미티드 컴퓨터 디바이스 인증을 위한 방법 및 시스템
KR20050074430A (ko) * 2002-07-18 2005-07-18 이오리지널 인크. 진정문서의 전달, 저장 및 회복에 대한 시스템 및 방법
KR20040106098A (ko) * 2003-06-10 2004-12-17 홍상선 유비쿼터스 개인 상호인증 보안방법
KR20110020783A (ko) * 2008-06-02 2011-03-03 마이크로소프트 코포레이션 신뢰된 장치별 인증

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014204231A1 (ko) * 2013-06-20 2014-12-24 Chang Dong Hoon 작은 메모리 구현 환경에 적합한 암호 인증 및 복호 검증 방법 및 전자 장치
JP2017500798A (ja) * 2013-12-05 2017-01-05 ▲華▼▲為▼▲終▼端有限公司 Ｅｕｉｃｃのためのセキュリティ制御方法およびｅｕｉｃｃ
CN109005032A (zh) * 2018-08-13 2018-12-14 中国联合网络通信集团有限公司 一种路由方法和装置
CN109005032B (zh) * 2018-08-13 2021-02-23 中国联合网络通信集团有限公司 一种路由方法和装置
WO2022214796A1 (en) * 2021-04-06 2022-10-13 Pelion Iot Limited System and method for provisioning profiles

Similar Documents

Publication Publication Date Title
WO2013036010A1 (ko) 내장 uicc의 인증정보를 이용한 인증방법과, 그를 이용한 프로비저닝 및 mno 변경 방법, 그를 위한 내장 uicc, mno 시스템 및 기록매체
KR102026612B1 (ko) 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ
WO2013048084A2 (ko) 프로파일 관리 방법, 내장 ｕｉｃｃ 및 내장 ｕｉｃｃ 탑재 기기
WO2013036009A1 (ko) 내장 uicc의 키정보 관리방법 및 그를 이용한 내장 uicc, mno 시스템, 프로비저닝 방법 및 mno 변경 방법
WO2013036011A2 (ko) 내장 uicc의 프로파일 관리방법 및 그를 이용한 내장 uicc, 내장 uicc 탑재 단말과, 프로비저닝 방법 및 mno 변경 방법
WO2013009059A2 (ko) 이동 통신 시스템에서 단말 설정 방법
WO2016010312A1 (ko) Euicc의 프로파일 설치 방법 및 장치
KR102001869B1 (ko) ｅＵＩＣＣ의 프로파일 관리방법 및 그를 이용한 ｅＵＩＣＣ, ｅＵＩＣＣ 탑재 단말과, 프로비저닝 방법 및 ＭＮＯ 변경 방법
WO2018147711A1 (en) APPARATUS AND METHOD FOR ACCESS CONTROL ON eSIM
WO2016153281A1 (ko) 무선 통신 시스템에서 프로파일을 다운로드 하는 방법 및 장치
FI106604B (fi) Menetelmä tilaajan identiteetin suojaamiseksi
WO2013009045A2 (ko) 동적 키 생성 기반의 내장 ｓｉｍ의 ｍｎｏ 변경방법 및 그를 위한 내장 ｓｉｍ과 기록매체
WO2017052136A1 (ko) 이동 통신 시스템에서 프로파일 다운로드 방법 및 장치
WO2015065063A1 (en) Method and apparatus to identity verification using asymmetric keys in wireless direct communication network
WO2013066077A1 (ko) 내장 ｕｉｃｃ 내 다수의 프로파일 관리 방법과 이를 위한 내장 ｕｉｃｃ 및 단말
WO2019009557A1 (ko) Esim 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
WO2020050701A1 (en) Apparatus and method for ssp device and server to negotiate digital certificates
WO2020226466A1 (en) Method and apparatus for managing and verifying certificate
WO2021112603A1 (en) Method and electronic device for managing digital keys
WO2021235893A1 (ko) 전자 디바이스 및 전자 디바이스가 레인징 기반 서비스를 제공하는 방법
WO2013066016A1 (ko) 신뢰관계 형성 방법 및 이를 위한 내장 ｕⅰｃｃ
EP3530016A1 (en) Apparatus and method for installing and managing esim profiles
WO2019194639A1 (en) Method and apparatus for negotiating euicc version
WO2014171711A1 (ko) 이동 통신에서 가입 사업자 변경 제한 정책을 지원하는 정책 적용 방법 및 장치
WO2020171475A1 (ko) 무선 통신 시스템의 기기변경 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12844995

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14356037

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12844995

Country of ref document: EP

Kind code of ref document: A1