Method for updating and revoking security keys and sensitive data through remote secure channel

Abstract

The invention relates to a method for updating and revoking keys and sensitive data through a secure remote channel. The method is suitable for terminal user equipment with SIM / eSIM in the telecommunication industry, an intelligent card or a mobile signature which is distributed by a USB card reader and carries a digital signature, an access and authorization card, a passport, a digital chip identity card, a chip payment card provided by a bank for payment, OTP equipment, and vehicles and Internet of Things (IoT) in the C-V2X and V2X ranges. It is also applicable to certificates and keys in hardware security modules (HSMs), secure elements (SEs), trusted execution environments (TEEs), and software-based protection solutions (Whitebox Crypto), enabling updating of symmetric and asymmetric key pairs in these systems through secure channels.

Description

Technical Field

[0001] The present invention relates to a method for updating and / or revoking symmetric and asymmetric key pairs owned by a system in the telecommunications field, applicable to various devices located at the end user point, such as SIM / eSIM in any type of device, smart cards with digital signatures distributed on USB-SIM, digital ID cards, passports, chip-based payment cards provided by banks, OTP devices, as well as smart cards or eSIM chips on vehicles within the C-V2X range, as well as certificates and keys found in the software and hardware secure storage areas of the terminal. Background Art

[0002] In the existing structure, the telecommunications industry uses SIM (Subscriber Identity Module) / eSIM (Embedded SIM), while the fintech industry uses credit cards. Technologies that enable contactless payments in cloud-based structures, such as HCE (Host Card Emulation), SoftPOS, POS and OTP systems, as well as certificates in MSP (Membership Service Provider) nodes in private blockchain networks, are very common. Smart cards with digital signatures distributed on eSIM / SIM integrated devices (such as eSIM / SIM integrated USB dongles) or directly on the eSIM / SIM in mobile phones, digital ID cards, passports, access and entry cards (smart cards for authentication, etc.), chip-based payment cards provided by banks, secure data storage and processing components, smart cards or eSIM chips on vehicles within the scope of C-V2X and V2X, certificates and keys in hardware security modules (HSM), secure elements (SE), trusted execution environments (TEE), etc., IoT devices and computers with secure components (HSM, SE, TEE, etc.), mobile or IoT devices with software-based keys, computer applications, digital mobile radio (DMR) transceivers, and TEE structures cannot update their symmetric and asymmetric key pairs through a secure channel after the initialization phase.

[0003] In an established key hierarchy, the root key at the top can be either symmetric or asymmetric. To prevent security breaches at the root key level that may arise over time, the solution is to provide users with new hardware (SIM / eSIM, ID card, payment card, access and authorization card, IoT device, etc.). Under the current state of technology, symmetric and asymmetric keys cannot be updated remotely through a secure platform. This creates a risky situation, providing opportunities for "man-in-the-middle" (MITM) attacks.

[0004] In the telecommunications industry, during the manufacturing phase, SIM cards or eSIM chips are initialized with keys and certificates that allow for authentication of telecommunications network components before being sent to telecom operators. The loaded keys are shared with the operator via secure methods such as shipping or encrypted files and registered in their systems. The keys and certificates for SIM cards and eSIM chips are loaded into a secure area via a contact interface during manufacturing. During the loading process, relevant sensitive data is also uploaded along with the keys and certificates. This process applies to 3G, 4G, 5G, 6G, and higher-level networks. When a phone number is provided to the end user, the SIM card pre-loaded with keys and certificates is matched against data elements such as the IMSI (International Mobile Subscriber Identity) or ICCID (Integrated Circuit Card Identifier) ​​before the card is delivered to the individual. For eSIMs, profile loading is accomplished by scanning a QR code using the pre-loaded certificate. Once the end user receives the profile for the SIM card or eSIM, the keys and uploaded certificates on the GSM application are not updated. For SIM cards, the validity period of the loaded keys expires after a certain period, necessitating a replacement. For eSIM, when the validity period of the uploaded certificate expires, you need to get a new device or replace and reinitialize the chip. The current ETSI (European Telecommunications Standards Institute) and GSMA standards have not yet specified a method for remotely updating the above keys of SIM and eSIM. In the current work report, although there is a suggestion to update the key with another previously loaded key, a solution for protecting key updates has not yet been demonstrated. In the telecommunications field, card initialization can also be called card programming or card personalization. At this stage, SMSP, ICCID, MCC (Mobile Country Code), MNC (Mobile Network Code), IMSI, K iParameters such as the SIM card (key), OP (Operator Code) / OPC (Operator Code Cryptography), ACC (Access Control Code), SQN (Serial Number), SUCI (Subscription Hidden Identifier), and HNET-PUBKEY (Home Network Public Key) can be loaded onto the card. In 5G networks, SUPI (Subscription Permanent Identifier), IMSI, and NAI (Network Access Identifier) ​​are used as identity information. Similar data elements are expected to be used in 6G and higher networks. SUPI information is stored in the UDM (Unified Data Management) / UDR (Unified Data Repository). To combat IMSI capture attacks, the SUPI is shared within the network as SUCI and encrypted by the UE (User Equipment) using HNET-PUBKEY and ECIES (Elliptic Curve Integrated Cryptography Scheme). Relevant units in the core network decrypt the SUCI to create a 5G-GUTI (5G Globally Unique Temporary Identifier), which is shared with the UE containing the SIM / eSIM. The 5G-GUTI is used for a limited period during subsequent authorizations and is stored in the AMF (Access and Mobility Management Function). Once its usage period expires, the core network requests the SUCI again to repeat the process. Therefore, the IMSI, which is personal identification information within the network, is not publicly circulated. Similarly, interaction between networks enables the use of 5G-GUTI through 4G-GUTI conversion.

[0005] The conversion from SUPI to SUCI is performed using asymmetric encryption, with a public key on the card and a private key in the network core. The public key encrypts the SUPI to form the SUCI, and the private key in the network core decrypts the SUCI to retrieve the SUPI.

[0006] The SUPI, which includes the IMSI, is used to access keys on the card or chip, using the UDM / UDR components of the core network (services associated with the HSS (Home Subscriber Server) in 4G networks), and in the 5G-AKA (Authentication and Key Agreement) process in 5G networks. These processes are defined by ETSI standards.

[0007] In WLAN, it uses EAP-AKA (Extensible Authentication Protocol - Authentication and Key Agreement) and EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) algorithms in non-5G structures. EAP-AKA uses the K i The derived EMSK (Extended Master Session Key) is used for authentication, while EAP-TLS uses the outer EMSK. i It is not extracted directly from the card, but is used to derive CK (confidentiality key) and IK (integrity key). After 5G-AKA, EAP-AKA and EAP-TLS processes, integrity control and encryption / privacy keys such as K rrc_enc , K rrc_int , Kup_enc , K up_int , which are generated on both UE and AUSF / UDM / AMF, and data are encrypted and transmitted using these keys.

[0008] In the key hierarchy, K i Is a symmetric key, all security is built on it. K i Stored in a file in the GSM card application (applet) and written to the card through the physical interface after accessing the card using the administrator PIN. As described here, K i The key and related authorization data are symmetric keys and need to be updated after a certain period of time. i There are no other pre-shared keys, and since key updates cannot be performed via SCP80 (Secure Channel Protocol 80) with an OTA (Over-the-Air) interface, the process involves physically updating the card. Since the keys used for SCP80 are symmetric keys, they also need to be updated. Time-related vulnerabilities in SCP80 keys cause all keys transmitted through SCP80 to exhibit vulnerabilities. Therefore, this structure is not preferred in the current setup. In addition, for encrypted IMSI and SUCI, the source of public key data must be trusted and resistant to MITM attacks, which currently requires loading via a physical interface and a secure channel. Therefore, secure key updates are currently not feasible.

[0009] In the telecommunications industry, similar issues exist with certificates and keys in SIM / eSIMs used in telecoms, smart cards or eSIM chips in vehicles within the C-V2X space, and security hardware and software such as SEs or HSMs. Similar issues also apply to digitally signed smart cards / chips or integrated SIM / eSIMs distributed via USB card readers, digital ID cards, passports, chip-based payment cards provided by banks, credit cards, technologies such as HCE (Host Card Emulation) for contactless payments in cloud-based architectures, payment acceptance technologies such as SoftPOS, POS, and mobile POS, OTP (One-Time Password) systems, certificates for MSP nodes in private blockchain networks, devices with security components such as SEs, IoT devices, computers, mobile or IoT devices with software-based keys, computer applications, TEEs, and other elements using security hardware and software, as well as OTP devices and software. In the case of smart cards, the terminal element is equipped with a card application; in the case of IoT devices or computers, the device firmware or a special application is installed to establish a secure channel between the designated terminal device and a server, and the keys for this secure channel can be updated remotely. The secure channel operates independently of the payload it carries. Here, private keys and sensitive data can be transferred.

[0010] Prior art, as described in U.S. Patent No. US20100042841A1, discusses a system and method for securely updating encryption keys. An exchange protocol, such as the Password Authenticated Key Exchange (PACE) protocol, is used to create a shared secret key. From this shared secret key, two keys are generated: an operational key and a secret key. The operational key is used to encrypt messages between nodes. When the operational key needs to be changed for security reasons, the secret key is used to encrypt messages to create / distribute a new shared secret key. This process can be repeated any number of times to ensure security.

[0011] Similarly, in the state of the art, U.S. Patent document US20050144439A1 discusses a system and method for managing encryption keys that provide selective security services on data messages between wired / wireless terminals. In the developed method, there is a step for updating the encryption key based on user selection when it expires.

[0012] Furthermore, U.S. Patent No. US20070140480A1 discusses a key update system, key management device, communication terminal, and key information generation method for a multi-label network. Specifically, the present invention relates to a technique for securely updating keys. The key management device in the key update system includes a key generation unit for generating keys, a one-way value generation unit with an additional directional function, and each communication terminal includes a transmission unit for transmitting encryption keys.

[0013] Existing key update methods in the state of the art do not provide a secure channel, and updating keys is at risk. Therefore, since it is impossible to remotely and securely update keys under the current circumstances, there has been a need to develop a key update and revocation method that enables remote and secure updating or revocation of private keys. Summary of the Invention

[0014] The object of the present invention is to implement a method for updating and revoking symmetric-asymmetric key sets, sensitive parameters and data for security purposes via a remote secure channel. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to achieve the purpose of the present invention, a method for updating and revoking a symmetric-asymmetric key group, sensitive parameters and data through a remote secure channel is described in the accompanying drawings.

[0016] These drawings include.

[0017] Figure 1 : Schematic diagram of the flow chart related to the KMF server service and KMF terminal client installation of the development method.

[0018] Figure 2: Schematic diagram of the flowchart related to key update and revocation after installation of the KMF server service and KMF terminal client of the development method.

[0019] Figure 3 : Schematic diagram of the flow chart related to key sharing and used as an example application of the developed approach, the key update and authorization phases of 5G-AKA in the telecommunications industry.

[0020] The abbreviations used are listed below:

[0021] K + : Public key pair

[0022] K - : Private key pair

[0023] rnd: Generates a random number for the key pair, used as the private key.

[0024] A new random number generated as a result of an update.

[0025] K + temp : Temporary public key

[0026] K - temp : Temporary private key

[0027] K g : The data digest carries the key.

[0028] K im : Temporary intermediate key

[0029] The new data digest carries the key.

[0030] K msg : Message data

[0031] Updated public key pair.

[0032] Updated private key pair.

[0033] P: ECC parameters of the public key

[0034] Q: ECC parameters of the private key

[0035] t 1.2 : 1 and 2 random numbers

[0036] The inverse of the first and second random numbers

[0037] V: Data Summary Set

[0038] v: The secret value that starts the data digest chain.

[0039] j: size of the data digest chain

[0040] U P : Public key list

[0041] U S : Private key list DETAILED DESCRIPTION

[0042] Methods related to remote update and revocation of developed keys involve:

[0043] - Create a pool of asymmetric keys based on Elliptic Curve Cryptography (ECC) for key sharing between the Key Management Function (KMF) terminal client and the KMF server service,

[0044] - Use the temporary private key and public key to generate the first data digest carrying key (K g ) to update the created key pair,

[0045] - define a data digest function and establish a data digest chain by defining the initial data digest chain value in the KMF server service,

[0046] - Load parameters to KMF terminal client and distribute the first data digest encryption key K from KMF server service g , the initial version of key revocation and renewal, the first ECC group generator, key group data, parameters for the hiding and integrity methods of the message response, parameters for whether key revocation and renewal will be performed in groups or individually, and a security indicator to the KMF terminal client,

[0047] - Executes operations in the KMF Server service to create re-key or revocation messages for implementing the key renewal and revocation process,

[0048] - Processes sensitive data encrypted by the KMF Server service into a KMF application for the purpose of creating re-key or revocation messages,

[0049] - Elliptic Curve Diffie-Hellman (ECDH) key sharing using an asymmetric key group, terminating the process with an error code if key sharing fails,

[0050] - If the process is successful, continue the normal process of establishing the structure between the KMF server service and the terminal client, and successfully complete the update of the asymmetric key owned by the KMF server service.

[0051] -Open a secure communication channel by sharing keys between the KMF server service and the KMF terminal client,

[0052] - Send keys and other sensitive data over this secure channel as required by the structures built by the KMF platform.

[0053] These are the steps involved in the process.

[0054] Step 1: In the developed method, initially, a pool of asymmetric key pairs based on elliptic curve cryptography (ECC) is created for key sharing between the Key Management Function (KMF) terminal client and the KMF server service. When forming the key pair pool, a secret and public key are obtained using a random number, and the random number, secret and public keys are collectively referred to as a group. These keys are used to open a secure channel between the central server and the terminal element. The public and private key pair [K + , K - ] is obtained by formulas 1, 2, and 3. The random value [rnd] is related to the public key and private key pair [K + , K - ] together.

[0055]

[0056] rnd i =F RAND (.) (Formula 2)

[0057]

[0058] Optional step 2: In the central server, use a random number to generate a temporary private key and a public key and an initial data digest carrying key (Kg). The random number to be used is selected as t1 = F RAND (.) and t2=F RAND (.). Then, use Formula 4 to calculate the inverse of the random number.

[0059]

[0060] Using the inverse of the random number obtained by formula 4, the temporary public key (K + temp ) and the temporary private key (K - temp ) is obtained by ECC scalar multiplication according to Equations 5 and 6. (P represents the ECC parameters of the public key, and Q represents the ECC parameters of the private key.)

[0061] K + temp =t1 -1 P (Formula 5)

[0062] K - temp =t1Q (Formula 6)

[0063] The temporary public key (K+ temp ) is multiplied by the second random number to calculate the temporary intermediate key (K im )According to formula 7.

[0064] K im =t2K + temp (Formula 7)

[0065] Then, the temporary intermediate key (K im ) and the temporary private key (K - temp ) are scalar multiplied to create the initial data digest carrying key used for the initialization process.

[0066] K g =K im K - temp (Formula 8)

[0067] The data digest carries the key used to transmit the encrypted data digest data, which will be used to update the random number [rnd] and key pair [K + , K-], is served from the KMF Server to the KMF Terminal Client. The key set used to create the secure channel can be updated with this data digest. The key protecting the data digest is loaded during the initialization phase. This initial data digest carries the key that will be shared with the KMF Terminal Client and the SIM / eSIM, either during manufacturing or via the Over-the-Air (OTA) interface. The recommended approach for security reasons is during the manufacturing phase.

[0068] Step 3: In the KMF server service, define the data digest function (Formula 9) and determine the initial value of the data digest chain (Formula 10), thereby creating the data digest chain. The initial value of the data digest chain must be protected. The data digest obtained through elliptic curve point multiplication is used to update the random number and the public and private key sets. The key set is updated in both the KMF terminal client and the server service, ensuring synchronization and updating of the key set. This ensures the security of the keys used for secure communication. In addition, the security of the keys transmitted through this secure communication channel is also guaranteed. When the data digest chain is fully utilized, a new list is created, each with its own ID. The data digest chain is stored in a pool, and the identifier ID can be used in sent messages.

[0069] V={v i |0≤i≤j} (Formula 9)

[0070] v i =h(v i-1 ) (Formula 10)

[0071] (V: data digest set, v: secret value to start the data digest chain, j: size of the data digest chain)

[0072] The created parameters are used to initialize the KMF terminal client and load parameters. Parameter loading must be performed on the terminal client's SIM / eSIM, a SIM / eSIM integrated into a USB card reader, a digitally signed smart card, a digital ID card, a chip-based payment card provided by a bank, a smart card in a C-V2X vehicle, or a certificate on the eSIM chip. Loading to the terminal client can be performed over-the-air (OTA) or during manufacturing. For security reasons, the recommended method is to load and program the initial data into the KMF terminal client at the factory via the contact interface.

[0073] Step 4: The key update operation is performed through a secure communication channel opened by the KMF Server service application. This secure communication channel is established between the KMF Server service and the KMF Terminal Client located on the terminal. When the KMF Server service requires a key update, it passes the relevant keys or sensitive data and parameters to the KMF Server service. The KMF Server service then transmits this data to the KMF Terminal Client via the secure channel. Since the KMF Terminal Client is located on the terminal, it records or shares the incoming data with relevant parties and securely completes the update.

[0074] Step 5: To implement key renewal and revocation operations, it is necessary to update the asymmetric keys and session keys on the KMF server service and KMF end-client. The expiration date of the session key is shorter than the expiration date of the asymmetric key pair and is set according to the user's needs. Session keys are created by using the asymmetric key pair between the end-user KMF end-client and the central KMF server service, and creating symmetric keys through ECDH key sharing. When the asymmetric keys used to create these session symmetric keys expire, a security vulnerability is created in the secure communication channel to be opened. Therefore, initially, the process of creating rekey or revocation messages is performed by the KMF service on the central server to update these keys.

[0075] The key group to be updated [rnd, K + , K - ] is located in the KMF server service database. Each time it is updated, a new K g Key. For this purpose, a new random number is selected using Formula 11.

[0076] rnd=F RAND (.) (Formula 11)

[0077] By passing the temporary public key Multiply it with the second random number to obtain the temporary intermediate key K im .

[0078]

[0079] By using the temporary intermediate key (K im ) and temporary private key Multiplication creates a new data digest carrying key.

[0080]

[0081] Take the last element v from the data summary chain according to the version number j-ver And use AES (Advanced Encryption Standard) Encryption. In addition, v j-ver Optionally use The signature is used for integrity checking.

[0082]

[0083] The encrypted data digest value, intermediate key value, version number and key ID are created as data. Here, the key ID can be used as KCV (Key Check Value).

[0084]

[0085] The KMF service sends this message in a manner appropriate to the platform it is used on, such as SMPP / UCP-EMI or CAT-TP for telecommunications, or TCP or its equivalent. In the payment, digital signature, V2X, and IoT domains, it is sent to the KMF endpoint client via TCP or its equivalent. The KMF endpoint client decrypts the incoming message with its key and updates its key set for secure communication. The key update process for KMF secure channel creation keys can be completed automatically at certain intervals or triggered by the central server to which it is connected.

[0086] Step 6: After the lifetime of the session key between the KMF Central Server Service and the endpoint KMF Client expires, a new ECDH key sharing is performed when it's time to update the asymmetric and symmetric keys, sensitive data, parameters, and certificates used by the endpoint in its own systems within the next infrastructure it will utilize (such as telecommunications, payment systems, digital signatures, access and authorization, OTP verification, vehicle-to-vehicle communication, IoT, etc.). These asymmetric-symmetric keys, sensitive data, and parameters are encrypted by the KMF Server Service using the session key and shared with the platform. The platform then sends the encrypted data to the endpoint KMF Client using the appropriate communication protocol used by the platform. At this point, the KMF Server Service can also communicate directly with the KMF Client, depending on the interface available for integration into the system. The goal is to transfer the sensitive data encrypted by the KMF Server Service to the KMF Client application.

[0087] The created message is sent as an OTA message via SMS or CAT-TP to the KMF endpoint client on the SIM / eSIM using fragmented APDU commands encrypted with SCP80. Other protocols can also be used; it is a protocol-independent model.

[0088] Commands arriving at the KMF endpoint client are processed by first calculating the new K im and temporary private key

[0089] Calculated Used to decrypt To obtain v j-ver .

[0090]

[0091] The signature is verified using Used for data digest rekeying. The incoming rekey version is compared with the registered rekey version, and if any rekeying is missed, the data digest values ​​are calculated one by one for the future and multiplied by the current key pair, rekeying cyclically.

[0092]

[0093] After this process is completed for all past key updates, the key is updated to the most recently received value.

[0094]

[0095] Step 7: Successfully completes the update of the asymmetric key owned by the KMF service and uses this key to create a session key for key sharing between the KMF server service and the KMF endpoint client, opening a secure communication channel. From this point on, the infrastructure built on the KMF platform can send its keys and other sensitive data through this secure channel as needed. In telecommunications applications, expired SIM / eSIM keys and sensitive data are encrypted and sent to the KMF client through this channel, allowing the KMF client on the SIM / eSIM to directly update the keys. A similar process is used for chip cards in payment systems. The KMF client takes the form of a card application on the smart card. Depending on the endpoint device used, the KMF client can be in the form of computer software or hardware firmware.

[0096] Step 8: After the update of sensitive data, certificates, and keys is successfully completed through the KMF service, the system components continue their normal processes, such as performing the 5G-AKA process specifically for 5G in telecommunications (including 3G / 4G / 5G / 6G and later processes), performing EMV payment transactions (ARQC / ARPC verification, SDA, CDA, DDA verification, etc.) in the payment system, verifying and signing in the digital signature process, logging in and secure data sharing in IoT and C-V2X / V2X services, and completing the OTP verification process.

[0097] The developed method includes the eight steps mentioned above. Communication channels (wired (Ethernet, serial port, CAN, I2C, etc.), wireless (Wi-Fi, Li-Fi, Bluetooth, DMR (Digital Mobile Radio), QR, IR, etc.)) and protocols (TCP, CAT-TP, SMPP, etc.) are operated completely insecurely.

[0098] More specifically, the developed encryption renewal and cancellation methods;

[0099] During the setup phase:

[0100] - During the setup phase, elliptic curve parameters (such as secp256k1, etc.) for the initial parameters of the Key Management Function (KMF) server service and the KMF endpoint client are arranged and shared.

[0101] - During the setup phase, the function used for the data digest function (such as SHA-256 or SHA-512, etc.) is determined and used.

[0102] - In the first stage of the setup phase, an asymmetric key pair (U p , U s ) is created for key sharing between the KMF endpoint client and the KMF server service using formulas 1 and 2.

[0103] (Key pair [K + , K - ] is generated by ECC scalar multiplication as in Equations 1, 2, and 3 using F gen.EKI (rnd) function. The RAND function returns an integer. P and Q are subgroup generators.)

[0104]

[0105] rnd i =F RAND (.) (Formula 2)

[0106]

[0107] - Registers a certain number of created key pairs to the database of the KMF server service.

[0108] - In the second phase of the setup phase, two random numbers are chosen as t1=F to create the initial data digest carrying key. RAND (.) and t2=F RAND (.)

[0109] To calculate the inverse of two chosen random numbers use Formula 4

[0110]

[0111] - Calculate the temporary public and private keys as in Equations 5 and 6 using the chosen random number and its inverse (ECC scalar multiplication),

[0112] K + temp =t1 -1 P (Formula 5)

[0113] K - temp =t1Q (Formula 6)

[0114] - Calculate the temporary intermediate key (K im ) Using the obtained temporary public key and the second random number as in Formula 7 (ECC scalar multiplication),

[0115] K im =t2K + temp (Formula 7)

[0116] Create the initial data digest carrying key by multiplying the temporary intermediate key obtained with the temporary private key as in Formula 8 (ECC point multiplication),

[0117] K g =K imK - temp (Formula formula 8)

[0118] - In the next stage, when creating K g When t1 is randomly selected and t2 is created from the data digest chain,

[0119] - Determine the data digest function to be used based on user preferences and the capabilities of the device at the endpoint, reset the key update index, define the methods used for encryption and integrity checking of message responses, select whether keys will be loaded individually or in groups, and select parameters for individual or group revocation accordingly,

[0120] Create a data digest chain in the form of a chain by selecting a random or predefined value, calculating its data digest value using Formula 9, and then calculating the data digest value of the calculated value using Formula 9.

[0121] V={v i |0≤i≤j} (Formula 9)

[0122] v i =h(v i-1 ) (Formula formula 10)

[0123] - initially shares the data digest functionality to be used with the KMF endpoint client served by the KMF server,

[0124] During the key update and revocation phase:

[0125] - During the key update and revocation process phase, the key pair [KM+, KM-] to be updated is found in the KMF server service database as and

[0126] A random number is chosen according to formula 11,

[0127] rnd=F RAND (.) (Formula 11)

[0128] Intermediate key K im is calculated by multiplying the temporary public key with the second random number according to formula 12,

[0129]

[0130] - A new data digest carrying key is created by multiplying the intermediate key and the private key obtained as in formulas 13 and 14,

[0131]

[0132] Encrypt the last element v j-ver From the data summary link Using Advanced Encryption Standard (AES) encryption technology,

[0133]

[0134] Create data using formula 17 with the encrypted data digest value, intermediate key value, version number and key ID.

[0135]

[0136] - Send the created message to the KMF endpoint client application independently of the communication channel,

[0137] Processing commands / messages received by the KMF endpoint client, first calculates the new Use K according to formulas 18 and 19 im and private key

[0138]

[0139] Decryption Use calculated To obtain v j-ver According to formula 20,

[0140]

[0141] - If there is a missed key update, compare the incoming key update version with the registered key update version, then calculate the future data digest values ​​one by one according to the formula CC, 21 and 22, multiply them with the current key pair, and update the key and random number,

[0142]

[0143] - after completing all past rekeys, rekey to the most recently received value,

[0144]

[0145]

[0146] - Perform Elliptic Curve Diffie-Hellman (ECDH) key sharing using the same asymmetric key group [rnd, K + , K - ] is owned by the KMF Server service and the KMF endpoint client application,

[0147] - Calculate the shared secret on the KMF endpoint client application and send a success code to the KMF server service,

[0148] - If successful, the KMF Server service calculates the symmetric key on its side and completes key sharing with the KMF Endpoint Client application mutually,

[0149] - If the process fails, send an error code and terminate the process,

[0150] If the process is successful, the KMF server service and the established structures of the endpoint client continue their normal processes.

[0151] These are the steps included in the process.

[0152] After the key update process is successfully completed, the KMF platform, built upon it, continues its normal operations using its own keys and sensitive data. In telecommunications applications, GSM card applications can log in to the KMF server service, applications requiring digital signatures can perform the signing process, authorization and access applications can authenticate users, and C-V2X / V2X applications can securely share their data with each other. Payment applications can create and verify payment-related cryptographic graphs, and the OTP system can continue generating offline OTPs. IoT or mobile devices can continue their secure operations.

[0153] As mentioned above, the developed method consists of three phases. The first phase is the setup phase of the method. In this phase, the initial parameters of the KMF server service and the KMF endpoint client are arranged and shared. The first step in the first phase involves the KMF server service selecting elliptic curve parameters (such as P, Q∈G1) and a data digest function. The recommended elliptic curve parameters for the developed method are secp256k, but this is not mandatory. SHA-256 and SHA-512 functions are used for the data digest function, but more efficient methods can be substituted if available. ECC-based asymmetric key pair U P (list of public keys) and U s (Private key list) is created for sharing keys between KMF endpoint clients and KMF server services. The pool size is set to one or more than the number of KMF endpoint clients. Multiple ECC key pairs can be loaded on a KMF endpoint client. Key Pair [K + , K - ]=F gen.EKI (rnd) is created using formulas 1, 2, and 3. A certain number of key pairs can be created, and the random numbers used are registered as a group in the database of the KMF server service.

[0154] This pool can be expanded as needed. K carries the digest data used to update the key pair. gThe key is created and served from the KMF server to the KMF endpoint client. g When t1=F RAND (.) will be randomly selected and t2 will be taken from the data digest chain. The inverse of the first number (t1) is calculated. Then the temporary public key and private key are calculated. The temporary public key is multiplied by the second number (t2) to calculate the temporary intermediate key. The temporary intermediate key and the temporary private key are scalar multiplied to create the initial data digest carrying key for the initialization process. This key is created to encrypt the data digest during the key update and revocation process. This key is shared with the KMF endpoint client via the SIM / eSIM manufacturing or OTA interface. The recommended method is the manufacturing stage for security reasons. In the next stage, when creating K g , t1 will be randomly selected and t2 will be taken from the data digest chain.

[0155] The next step is to determine the data digest function to be used and reset the key update index. SHA-256 and SHA-512 can be selected for the data digest function, or new methods can be used if they become available. The selection is based on user preference and the capabilities of the device at the KMF endpoint. A random or predefined data is selected, and then a data digest value is calculated for the selected data and the calculated value, creating a chain of data digests. Additionally, chains are stored in a pool, as a new chain is needed as chains are used and exhausted. Multiple chains can be created and stored.

[0156] A chain of data digests is used for key updates, starting from the end of the chain. Due to the difficulty in reversing data digests, they are used for security purposes. The KMF endpoint client is initialized with the created parameters and parameter loading is performed. For parameter loading, the endpoint client needs to be loaded onto the SIM / eSIM card. KMF endpoint client loading can be done via OTA (Over the Air) or during the manufacturing phase. The recommended approach for security reasons is to load the endpoint client during the manufacturing phase and program the initial data onto the contact interface of the KMF endpoint client. With the KMF endpoint client, the data digest function to be used is shared parameters first. With respect to how to protect the parameters that will be provided in the response to the message, the K is initially created. g The key is loaded and the version number associated with the key update is reset and loaded. The selected ECC parameters are also loaded to the KMF endpoint client. The recommended ECC parameters are secp256k, but they can be changed. In the next step, the recommended number of key pairs [K + , K - ] is loaded onto the card. The loaded element (SIM / eSIM) is also associated with the KMF server service side.

[0157] The second stage of the developed method is the implementation of the key update and revocation process for the KMF Server Service and the KMF Endpoint Service. The operation can be performed for a specific period with existing parameters. For security reasons, it is recommended to update after the initial use of the SIM / eSIM. First, the key pair to be updated [K + , K - ] was found in the KMF server service database. As shown below, a new K g The key is created, followed by the selection of a random number. An intermediate key K im is calculated by multiplying the temporary public key with the second random number. Then, the intermediate key and the private key are multiplied to create a new data digest transmission key. The final element v j-ver Extracted from the data digest chain and encrypted Use AES encryption. In addition, v j-ver is optionally signed with Used for integrity control. The encrypted data digest value, intermediate key value, version number and key ID are created as data. The resulting message is sent to the KMF endpoint client on the SIM / eSIM via a fragmented APDU command encrypted with SCP80 as an OTA message via SMS or CAT-TP. The command received by the KMF endpoint client is processed, first calculating the new K im and private key Calculated Used to decrypt And reveal v j-ver .

[0158] The signature is verified using Used for data digest key updates. If there were any missed key updates, the incoming key update version is compared with the registered key update version, and future data digest values ​​are calculated one by one, multiplied by the current key pair, and the key is updated. This process is completed for all past key updates, and then the key is updated to the most recently received value.

[0159] The third phase of the developed method is the key sharing and 5G-AKA key update and authorization phase. After a certain period of time, it becomes necessary to update the keys required for 5G-AKA. Typically, a new SIM / eSIM purchase would be required for the update process. However, thanks to the developed method, this is no longer necessary. In this process, initially, ECDH key sharing is performed using the same asymmetric key group [K + ,K-,md] is owned by the KMF server service and the KMF endpoint client. For key sharing, the KMF service signature private key (rnd), public key (K +) and the private key (K - ) uses ECDSA and sends the public key and signature to the KMF endpoint client via OTA encrypted with SCP80. The KMF endpoint client first checks the received public key (K + ) signature, protecting the data source from MITM attacks, and after verification, calculates the shared key and sends a success code to the KMF server service. After receiving the success code, the KMF server service calculates the symmetric key on its side and completes the key sharing with the KMF endpoint client application mutually, and if the signature fails, it sends an error code and terminates the process. Key sharing needs to be repeated after a certain period of time. If a long time has passed, the asymmetric key used in key sharing will need to be updated. When key sharing is valid, when it is necessary to update the key for 5G-AKA, the KMF server service first generates a new key and necessary sensitive data (K i , OP, RAND, SQN, etc.) on UDM.

[0160] The server service encrypts the generated data using AES with a shared key K s And send the encrypted data to the KMF endpoint client via OTA with SCP80 encryption. The KMF endpoint client decrypts the encrypted data with its own K s and performs an integrity check. Subsequently, if necessary, it logs into the interface provided by the GSM application and updates the necessary data. If the process is successful, a success code is transmitted to the KMF server service, and the process is completed. If a failure code is sent to the KMF server service, the process is reversed and retried. During the GSM application update, the keys in the UDM are updated with the keys used in the GSM application, and the current system continues to operate without any interruption. In this way, the KMF endpoint client updates the GSM application, and the KMF server service updates the UDM database, ensuring no disruption to the processes of current system components and extending the lifecycle of SIM / eSIM products.

[0161] The developed key sharing creation, update or revocation process can similarly solve similar key update problems using similar KMF endpoint clients and KMF server services in structures like C-V2X / V2X those using SIM / eSIM in the telecommunications sector, payment cards used in the financial technology sector, HCE (Host Card Emulation) technology that enables contactless payments in cloud-based structures, SoftPOS, SAM cards in mobile POS devices, or equivalent secure software and hardware data storage processing units, OTP systems, certificates in nodes for MSPs (Membership Service Providers) in private blockchain networks, HSM solutions using smart cards, digital signatures (mobile signatures, USB tokens, smart cards, OTP systems), ID cards, passports, access systems, OTP systems, and certificates in nodes for update purposes in private blockchain networks.

[0162] The developed system can be implemented with any type of algorithm, SIM card, or on different platforms.

[0163] The advantages obtained with the developed key update and revocation method are listed below:

[0164] - Makes it possible to remotely update asymmetric and symmetric keys.

[0165] - Does not disrupt the workflow of existing system components, it extends the lifecycle of SIM / eSIM products or any software and hardware elements that have a lifecycle dependent on key updates.

[0166] - Updating the master key is expected to have minimal impact on other structures used in the domain within the key hierarchy. That is, the method can be applied without making changes to existing structures.

[0167] - With variable length and pooling of data digest chains, it allows frequent key updates and complicates the predictability of post-quantum cryptographic operations through dynamic version number transmission.

[0168] - Prevents the formation of time-dependent vulnerabilities for certificates in SIM / eSIM connected devices in the field.

[0169] - Provide a solution for the need for remote key updates to enable remote operations on devices, particularly important during chip crises and for extending the lifecycle of existing SIM / eSIM and IoT technologies.

[0170] Telecommunication companies can integrate this solution into their operations at a modest integration cost, potentially reducing annual SIM card charges.

[0171] -In the payment sector, it can extend the lifecycle of payment cards and enhance the security of mobile devices.

[0172] - Allows remote update or revocation of keys in secure elements (HSM, SE, TEE) or software-based protection modules like Whitebox Crypto.

[0173] Addressing security gaps in solutions like C-V2X / V2X by enabling remote key management at distant locations.

[0174] - Enhanced remote lifecycle extension for ID cards and digital signatures.

[0175] - Enables remote key management for HSM solutions using smart cards.

[0176] Promote security enhancements in endpoint devices like IoT devices, payment devices, identity access devices, end-user mobile devices, computers, OTP devices, etc.

Claims

1. The present invention relates to a method for remotely updating a key, characterized in that: The process steps include: - Creates a pool of asymmetric key pairs based on Elliptic Curve Cryptography (ECC) for key sharing between the Key Management Function (KMF) endpoint client and the KMF server service, rnd i =F RAND (.) (Formula 2) - Update the generated key pair using the temporary private and public keys and create a key transport hash (K g ), - Define the hash function and create a hash chain in the KMF server service, - load parameters to the KMF endpoint client and distribute the initial revocation and key renewal versions, initial ECC group generators and key pair data from the KMF server to the KMF endpoint client, - Performs rekey and dekey operations in the KMF Server service by creating a rekey or dekey message, - Process sensitive data encrypted by the KMF Server service in KMF applications for re-keying or canceling message creation processes, - Perform Elliptic Curve Diffie-Hellman (ECDH) key sharing using an asymmetric key group, and terminate the process with an error code if key sharing fails, - Continue normal process for both the KMF server service and the endpoint client if the operation is successful.

2. The present invention relates to a method for remotely updating a key, according to claim 1, characterized in that: Including process steps; involving data digest encryption key (K g ) is an initial data digest encryption key, and additionally distributes the initial data digest encryption key from the KMF server service to the KMF endpoint client, when creating the initial data digest transport key (K g ) phase in the KMF server service, using a random number along with the temporary secret and public key, - register a certain number of created key pairs in the database of the KMF Server service, - In the second stage of setup, two random numbers t1 = F are selected RAND (.) and t2=F RAND (.) is used to create the initial data digest transmission key, - Calculate the inverse of two chosen random numbers using formula 4, - Use the chosen random number and its inverse to calculate the temporary public and private keys according to Equation 5 and Equation 6, using ECC scalar multiplication, K + temp =t1 -1 P (Formula 5) K - temp = t1Q (Formula 6) - Calculate the temporary intermediate key (K im ) Using Equation 7, by multiplying the temporary public key obtained with the second random number, use ECC scalar multiplication, K im =t2K + temp (Formula 7) - Create the initial data digest transport key by multiplying the temporary intermediate key obtained with the temporary secret key as in Formula 8, using ECC point multiplication. K g =K im K - temp (Formula 8) 3. The present invention, according to any one of the preceding claims, relates to a method for remotely updating a key; characterized in that: The steps included in the stages of defining data digest functions and creating data digest chains are in the KMF server service. - Determines the data digest function to be used based on user preferences and the capabilities of the device at the endpoint and re-keys the update index, - Select a random or predefined data, calculate its data digest value using Formula 9, and then calculate the data digest value of the calculated value using Formula 10 to create a data digest chain in a chain form. V={v i |0≤i≤j} (Formula 9) v i =h(v i-1 ) (Formula 10) 4. The invention relates to a method for remotely updating keys, according to any one of the preceding claims, characterized in that The steps included in the phase of creating a rekey or revocation message are used in the implementation of the rekey and revocation process in the KMF server service. - Identify the key to be updated, [K + temp , K - temp ], from the KMF server service database to K + temp =k temp Q and -Select a random number according to formula 11, rnd=F RAND (.) (Formula 11) - Calculate the intermediate key K im By multiplying the temporary public key with the second random number according to formula 12, - Create a new data digest transmission key by multiplying the intermediate key with the private key according to formulas 13 and 14, -Get the last element v from the data digest chain according to the version number j-ver and encrypt Using Advanced Encryption Standard (AES) encryption technology, - Create the encrypted data digest value, intermediate key value, version number and key ID as data using formula 17, - Sends received messages to KMF endpoints by the client application independently of the communication channel.

5. The present invention relates to a method for remotely updating a key according to any one of the above claims; characterized in that Included are steps in the process of processing sensitive data encrypted by a KMF server service into an operation for a KMF application to create a re-key or revocation message, -Commands / messages arriving at the KMF endpoint client are processed and first new Calculated using K im and secret key As described in Equations 18 and 19, -decoding Use calculated And calculate v j-ver Using formula 20, - compare the incoming key update version with the registered key update version and, if there is a missed key update, individually calculate the forward data digest values ​​as in Equation EE, Equation 21 and 22 in a round-robin fashion, multiply them with the current key pair, and update the key, - after all past key updates have been completed, also update the key to the most recently received value, - Perform Elliptic Curve Diffie-Hellman (ECDH) key exchange using the same asymmetric key pair [rnd, K + , K - ] that the KMF Server service and the KMF Endpoint Client application have, - Calculate the shared secret on the KMF endpoint client application and send a success code to the KMF server service, - With the success code, the KMF Server service computes the symmetric key on its side and completes the key exchange mutually with the KMF Endpoint Client application.

Images