Method for updating a secure element cooperating with a telecommunications terminal - Patent Application 20070122997
The LwM2M protocol addresses inefficiencies in managing security elements by diversifying polling messages and establishing HTTPS channels for secure updates, reducing network strain and power consumption.
Patent Information
- Application Number
- JP2024513215
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-09-10
- Filing Date
- 2022-09-02
- Publication Date
- 2025-09-26
- Estimated Expiration
- 2042-09-02
AI Technical Summary
Existing methods for managing and updating security elements in telecommunications networks, such as UICCs and eUICCs, are inefficient and cause unnecessary wireless traffic and network overload due to regular polling, especially in LTE networks that do not support SMS, and fail to distinguish between urgent and non-urgent requests, leading to potential rejection of critical updates.
Implementing the Lightweight M2M (LwM2M) protocol to trigger secure element management by an OTA server, using a diversified polling message with a counter and encryption, establishing an HTTPS channel for updates, reducing unnecessary communications and power consumption.
Reduces unnecessary wireless traffic and network strain by initiating updates only when necessary, ensuring secure and efficient management of secure elements without excessive power consumption or bandwidth requirements.
Smart Images

Figure 0007745087000001 
Figure 0007745087000002 
Figure 0007745087000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to the field of telecommunications, and more particularly to the field of remote administration of security elements, such as UICCs (Universal Integrated Circuit Cards), eUICCs (Embedded UICCs), iUICCs (Integrated UICCs), etc., interacting with terminals, portable terminals, such as telephones, smartphones, PDAs or computers. The security elements may also be in the form of integrated circuits in machines, such as in the field of M2M (Machine to Machine). The security elements are not necessarily physically connected to the terminal, but may communicate with the latter via a shorthaul link, where the security element is remote and communicates with the terminal via a shorthaul channel (e.g. Bluetooth or Wifi). [Background technology]
[0002] Such management of the security element is generally performed over the air (OTA) to update or install data or programs in the security element. This type of management can use the http protocol (hypertext transfer protocol) or SMS (short message service).
[0003] There are two ways to manage security elements: The first method involves sending data or programs from an OTA platform or server to the targeted security element, for example during an update campaign. This type of management is known as "push" and is based on transmission in SMS mode. The problem with this method is that it is unsuitable for new generation networks, such as pure LTE networks, which do not support SMS (they are fully http). Furthermore, RAM or RFM type management over http has been set up to avoid unreliable protocols such as SMS.
[0004] The second method involves querying the OTA platform, for example, regularly or when an event occurs, to find out if there are any updates available. This query is initiated by the security element and is called "polling" or "pulling" (the security element checks to see if the OTA platform has something to send to the security element). The query is made via the HTTP protocol.
[0005] Figure 1 shows a system for managing security elements based on this principle.
[0006] In this figure, a security element 10 is managed by an OTA platform 11 or server.
[0007] The security element 10 interacts with a telecommunications terminal, not shown.
[0008] The process begins at stage 12 and involves interrogating the OTA platform 11, at the initiative of the security element 10, to find out if the former has data or programs to send to the latter. All the exchanges shown are carried out according to the SCP81 protocol.
[0009] During a step 13, the server 11 replies to the security element 10 stating that it has received the latter's request and confirms this reception during a step 14.
[0010] During step 15, the security element 10 sends a PSK ID to the server 11. The PSK ID refers to a pre-established key (PSK) associated with an identity (ID) and shared between the security element 10 and the server 11. By means of this PSK key, the server 11 recognizes the security element 10.
[0011] Advantageously, reference should be made to the IETF Recommendation available at the following address: https: / / tools.ietf.org / html / rfc4279.
[0012] During step 16, the security element 10 selects a cipher suite, for example an AES128 or 3DES suite.
[0013] The server 11 approves the proposed cipher suite during a step 17 and then finalizes the establishment of a handshake channel with the security element 10 during a step 18 .
[0014] Phase 19 then involves exchanging data over the secure TLS-PSK channel thus established. In particular, during this phase 19, the security element 10 sends a URL to the server 11, which URL corresponds to the reason for the request (simple data update, if this is the first use of the security element 10, activation of the security element 10, ...).
[0015] The problem with this solution is that, in fact, the security element 10 generally does not wait for an event to occur in order to query the OTA platform 11. Thus, the "polling" occurs regularly, e.g., every 15 days or every month, and most of the time, the OTA platform 11 has nothing to send to the security element 10. Applicant has noticed, for example, that in 90% of queries of the OTA platform 11 by the security element 10 in the field, there are no updates, programs, or data to be sent to the security element 10. This results in unnecessary wireless traffic and overloads the OTA platform (a TLS-PSK link is established between the security element and the OTA platform each time the security element is queried). Therefore, steps 12 to 18, generally referenced by 20, are unnecessary most of the time.
[0016] Another problem is that the OTA platform 11 is constantly being used for various tasks that do not all have the same degree of urgency: for example, it is more important for the subscriber to initialize the security element 10 (when the subscriber inserts the security element 10 into the terminal for the first time) so that it can quickly make a call (e.g., download the subscriber's contact directory or download a complete subscription) rather than updating his or her PLMN (Public Land Mobile Network - a list of foreign networks that the security element 10 will preferably connect to when roaming).
[0017] Therefore, there is no distinction between processing urgent and non-urgent requests: the OTA server 11 may in this case be forced to reject connection requests from security elements 10 if the connection requests from the security elements 10 that urgently need to be updated are overwhelmed by other, less urgent requests from other security elements.
[0018] Furthermore, when the internal network of a data center (e.g., the data center of a security element manufacturer with which a mobile operator co-locates its services) is involved in updating the security element, unnecessary strain is placed on this network as well. Furthermore, when this network uses physically distributed servers, additional communications are added.
[0019] To overcome this drawback of the second method of operation, two solutions are possible: - Extend the period between two OTA platform queries ("polling") (the application in the security element is updated to extend this period). The drawback is that if the update is available immediately after the last query, the security element will only be updated much later; - Switch to "push" mode, in which case you'll again face the same problem mentioned above.
[0020] It is also known that for example for M2M applications the LwM2M (Lightweight M2M) protocol can be used.
[0021] The LwM2M protocol is a communications protocol designed specifically for remote device management and telemetry within the Internet of Things and in other M2M applications. Serving as the successor to the OMA Device Management (OMA DM) standard, Lightweight M2M is essentially designed to reduce power and data consumption, and thus recognize and respond to the growing M2M market demand for dedicated solutions for low-power devices with limited processing and storage capabilities (also known as resource-constrained devices).
[0022] The protocol specification describes many common IoT device management functions, such as remote device actions, firmware and software updates (FOTA and SOTA), connectivity monitoring and management, including cellular management and provisioning.
[0023] However, the LwM2M protocol is intended for device management and has no impact on the secure element contained in this device: the management of the secure element is outside the scope of the LwM2M protocol. Summary of the Invention [Problem to be solved by the invention]
[0024] The invention proposes to use the LwM2M protocol to trigger the management of the secure element by the OTA server. [Means for solving the problem]
[0025] More precisely, the invention proposes a method for updating a secure element associated with a telecommunications terminal in a telecommunications network, the updating being carried out by an OTA server, the method comprising: sending a trigger of a polling message from the OTA server to the secure element through the LwM2M channel to request the secure element to establish an https channel with the OTA server, wherein the OTA server updates the secure element through the https channel after the establishment of the https channel.
[0026] Preferably, the trigger for a polling message comprises a counter that is incremented by the OTA server each time it sends a trigger for a polling message to the secure element.
[0027] Advantageously, the triggering of the polling messages is diversified for each secure element.
[0028] Preferably, the diversification consists in encrypting the trigger of the polling message with the ICCID of the secure element.
[0029] The present invention also relates to an OTA server, comprising a processor having instructions for sending a trigger of a polling message through an LwM2M channel to a secure element to ask the secure element to establish an https channel with the OTA server, wherein the OTA server updates the secure element through the https channel after the establishment of the https channel.
[0030] The present invention also relates to an LwM2M server, the LwM2M server having a processor with instructions for sending to a secure element a trigger of a polling message through an LwM2M channel to an LwM2M client in order to ask the secure element to establish an https channel with an OTA server, wherein the OTA server updates the secure element through the https channel after the establishment of the https channel.
[0031] The present invention also relates to an LwM2M client, the LwM2M client having a processor with instructions for receiving a trigger of a polling message from an LwM2M server through an LwM2M channel to a secure element to ask the secure element to establish an https channel with an OTA server, the OTA server updating the secure element through the https channel after the establishment of the https channel.
[0032] The present invention also relates to a secure element, the secure element comprising a processor with instructions for receiving a trigger of a polling message from an LwM2M through an LwM2M channel to the secure element to ask the secure element to establish an https channel with an OTA server, the OTA server updating the secure element through the https channel after the establishment of the https channel.
[0033] Finally, the present invention relates to an applet provided in a secure element cooperating with an OTA platform, an LwM2M server, an LwM2M client and a device, the applet comprising instructions for triggering a polling message through the LwM2M channel to the secure element in order to ask the secure element to establish an https channel with the OTA server, the OTA server updating the secure element through the https channel after the establishment of the https channel.
[0034] Other features and advantages of the present invention are presented in the following figures. [Brief explanation of the drawings]
[0035] [Figure 1] 1 is a diagram of the current state of the art. [Figure 2] 1 is a diagram of a preferred embodiment of the present invention; [Figure 3] FIG. 3 is a diagram of an alternative to the solution depicted in FIG. 2. DETAILED DESCRIPTION OF THE INVENTION
[0036] FIG. 1 was presented with respect to the state of the art.
[0037] FIG. 2 depicts a preferred embodiment of the present invention.
[0038] In this diagram, three main entities are represented: a device 30, which may be an M2M device, a device management platform 31 that manages the device 30, and an OTA platform (or server) 32 whose task is to manage (download data or applications to) a secure element 34 that cooperates with the device 30.
[0039] The device 30 comprises an LwM2M client 33, and the device management platform 31 comprises an LwM2M server 36. The device management platform 31 also comprises a credential management unit 37 linked to the LwM2M server 36, to the OTA platform 32, and to an IoT hub 38.
[0040] The credential management unit 37 and IoT hub 38 are only depicted for completeness of understanding as they are not part of the present invention. The credential management unit 37 collects information from the device 30, such as gas or electricity consumption, and stores this information in the IoT hub 38. This information is sent by a store 35 located in the device 30 through an application located between the LwM2M client 33 and the store 35, which application is not depicted.
[0041] The work of the present invention requires the following: In order to update the secure element 34 cooperating with the telecommunication terminal (or device) 30, the OTA server 32 sends a trigger polling message through the LwM2M channel to the secure element 34 to ask the secure element 34 to establish an https channel with the OTA server, and after the establishment of the https channel, the OTA server updates the secure element through the https channel.
[0042] To that end, the OTA server 32 sends a polling message trigger 39 (token) to the LwM2M server 36 when the OTA server 32 has data to be downloaded to the secure element 34. The LwM2M server 36 sends this token to the LwM2M client 33 (step 40), which in turn sends it to the secure element 34. The secure element 34 then opens an https channel 42 with the OTA server 32 using the SCP81 81 keys provided in the OTA server 32 and in the secure element 34. When this channel is opened, the OTA server 32 can download data or programs to the secure element 34.
[0043] The token 40 is sent via the Constrained Application Protocol (CoAP), a specialized Internet application protocol for constrained devices defined in RFC 7252. CoAP is a service layer protocol intended for use in resource-constrained Internet devices, such as wireless sensor network nodes.
[0044] The User Datagram Protocol (UDP) runs on top of the Internet Protocol (IP) to send datagrams across a network.
[0045] Non-IP Data Delivery (NIDD) provides efficient communication between IoT devices and enterprise applications. NIDD is capable of transporting up to 1500 bytes in a single transmission without the tens of bytes of overhead required by IP and higher-layer protocols such as TCP or UDP.
[0046] Thus, the secure element 34 no longer needs to regularly trigger the OTA server 32, because the OTA server 32 informs the secure element 34 via the LwM2M channel that it must establish an https channel with this OTA platform 32. Also, this channel is opened by the LwM2M channel trigger, so there is no (or at least limited) power consumption from the device 30 and only required OTA operations are performed at the initiative of the OTA platform 32.
[0047] The secure element 34 establishes an https channel with the OTA platform 32 .
[0048] Preferably, the trigger 39 for a polling message comprises a counter that is incremented by the OTA server 32 each time it sends a trigger for a polling message by the OTA server 32 to the secure element 34. This secures the communication between these two elements and prevents DoS attacks, since the secure element 32 cannot always trust the LwM2M client 33.
[0049] Thus, the token 40 can be secured against DoS attacks so that the secure element 34 recognizes them, which can be a symmetric key such as a counter (the token is tokenized).
[0050] In a preferred embodiment, the triggering polling messages are diversified per secure element. This ensures that each polling message is addressed to the targeted secure element 34. This diversification can be done by encrypting the triggering polling messages with a unique identifier of the secure element, for example, the ICCID of the secure element 34 (which only requires the unique ID of the secure element 34). The secure element 34 can then decrypt the received polling message and establish an https session in pull mode.
[0051] Therefore, the present invention relies on a network (OTA) initiated pull of the secure element 34 .
[0052] The token 39 is sent and received by the LwM2M client 33, which knows that the token is intended for the secure element 34.
[0053] 3, instead of sending a polling message to the secure element 34, the OTA platform 32 sends an encrypted message 50 (using the SCP03 key) over the LwM2M channel to the secure element 34. This is the update script.
[0054] This encrypted message (51, 52) is forwarded to the secure element 34 and contains updates for the secure element 34, encrypted with the SCP03 key. This establishes a secure channel between the OTA platform 32 and the secure element 34. The https channel 42 of Figure 2 no longer exists.
[0055] Instead of the SCP03 key, it is also possible to use an SCP11 key or an SCP04 key.
[0056] In this embodiment, since the script contains the data to be sent by the OTA platform 32 to the secure element 34, it is possible to use any method of communication between the OTA platform 32 and the secure element 34 (SMS, https, LwM2M protocol, ...) to update the secure element 34. The scripts to be downloaded to the secure element are sent through the LwM2M channel, but they are encrypted with the SCP03 key, so that only the secure element 34 will be able to decrypt them. Therefore, there is no need to establish a dedicated https channel between the OTA platform and the secure element (such as reference number 42 shown in Figure 2).
[0057] The present invention also relates to an OTA server 32 having a processor with instructions for sending a trigger of a polling message through an LwM2M channel to a secure element 34 to ask the secure element 34 to establish an https channel with the OTA server 32, and the OTA server 32 updates the secure element 34 through the https channel after the establishment of the https channel.
[0058] The present invention also relates to an LwM2M server 36 having a processor with instructions for sending to the secure element 34 a trigger of a polling message through an LwM2M channel to an LwM2M client 33 in order to ask the secure element 34 to establish an https channel with an OTA server 32, wherein the OTA server 32 updates the secure element 34 through the https channel after the establishment of the https channel.
[0059] The present invention also relates to an LwM2M client having a processor with instructions for receiving a trigger of a polling message from an LwM2M server to a secure element 34 through an LwM2M channel to ask the secure element 34 to establish an https channel with an OTA server 32, wherein the OTA server 32 updates the secure element 34 through the https channel after the establishment of the https channel.
[0060] The present invention also relates to a secure element, the secure element having a processor with instructions for receiving a trigger of a polling message from an LwM2M through an LwM2M channel to the secure element 34 to ask the secure element 34 to establish an https channel with an OTA server 32, the OTA server 32 updating the secure element 34 through the https channel after the establishment of the https channel.
[0061] Finally, the present invention relates to an applet provided in a secure element 34 cooperating with an OTA platform 32, an LwM2M server 36, an LwM2M client 33 and a device 30, the applet comprising instructions for triggering a polling message through the LwM2M channel to the secure element 34 in order to ask the secure element 34 to establish an https channel with the OTA server 32, the OTA server 32 updating the secure element 34 through the https channel after the establishment of the https channel.
[0062] The present invention can be implemented in all LPWAN networks (Low Power Wireless Access Networks), such as SigFox™, Lora™, or NB-IoT, for example, to improve OTA services for secure elements without excessive power consumption and bandwidth requirements.
Claims
1. A method for updating a secure element (34) associated with a telecommunications terminal (30) in a telecommunications network, said updating being performed by an OTA server (32), said method comprising: sending a trigger of a polling message from the OTA server (32) to the secure element (34) through an LwM2M channel to ask the secure element (34) to establish an https channel with the OTA server (32), the OTA server (32) updating the secure element (34) through the https channel after the establishment of the https channel; method.
2. 2. The method of claim 1, wherein the trigger for a polling message comprises a counter that is incremented by the OTA server (32) each time the OTA server (32) sends a trigger for a polling message to the secure element (34).
3. 3. The method of claim 1, wherein the triggers for polling messages are diversified for each secure element (34).
4. 4. The method of claim 3, wherein the diversification consists in encrypting the trigger of a polling message with the ICCID of the secure element (34).
5. An OTA server (32) comprising a processor having instructions for sending a trigger of a polling message through an LwM2M channel to a secure element (34) to request the secure element (34) to establish an https channel with the OTA server (32), wherein the OTA server (32) updates the secure element (34) through the https channel after the establishment of the https channel.
6. An LwM2M server (36) comprising a processor with instructions for sending a trigger of a polling message through an LwM2M channel to an LwM2M client (33) to a secure element (34) to request the secure element (34) to establish an https channel with an OTA server (32), wherein the OTA server (32) updates the secure element (34) through the https channel after the establishment of the https channel.
7. 1. An LwM2M client (33) comprising a processor with instructions for receiving, from an LwM2M server (36), a trigger for a polling message through an LwM2M channel to a secure element (34) to request the secure element (34) to establish an https channel with an OTA server (32), wherein the OTA server (32) updates the secure element (34) through the https channel after the establishment of the https channel.
8. A secure element (34) comprising a processor having instructions for receiving a trigger for a polling message from an LwM2M channel to the secure element (34) to request the secure element (34) to establish an https channel with an OTA server (32), wherein the OTA server (32) updates the secure element (34) through the https channel after the establishment of the https channel.
9. 1. An applet provided in a secure element (34) cooperating with an OTA platform (32), an LwM2M server (36), an LwM2M client (33), and a device (30), the applet comprising instructions for triggering a polling message to the secure element (34) through an LwM2M channel to ask the secure element (34) to establish an https channel with an OTA server (32), the OTA server (32) updating the secure element (34) through the https channel after the establishment of the https channel.
Citation Information
Patent Citations
Method for optimizing the polling event of a secure element and corresponding gateway, secure element, baseband device and OTA platform
EP3334116A1
Message authentication method for communication system, and communication system
JP2013098719A
Communication apparatus and control method for the same
JP2020195122A
On-vehicle wireless communication device, on-vehicle wireless communication system, and on-vehicle wireless communication method
JP2021125753A
Method for personalizing an improved UICC associated with a terminal
JP2021534691A