Session creation method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a session creation method and device, electronic equipment, a storage medium and a program product, relates to the technical field of communication, and is used for improving the security of a network session. The method comprises the following steps: receiving a first session request from calling terminal equipment; under the condition that the first session parameter passes the verification, generating a first session key ciphertext corresponding to the calling terminal equipment, and generating a second session key ciphertext corresponding to the called terminal equipment; sending the first session key ciphertext and the session address of the called terminal device to the calling terminal device through the first encryption path, and sending a call request corresponding to the session request to the called terminal device so as to establish a first session between the calling terminal device and the called terminal device; the method is applied to a network call scene.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a session creation method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] Currently, with the rapid development of mobile internet and the widespread application of network conversations, the public network environment is complex, and security threats such as information leakage, malicious attacks, and session hijacking frequently occur, seriously affecting user privacy and call quality. Therefore, it is urgent to build a comprehensive and efficient security protection system.

[0003] Among related technologies, Web Real-Time Communication (Web RTC) is the mainstream technology for real-time audio and video communication, and its security mechanisms form the basis of existing solutions. Web RTC generates and stores session keys through the Datagram Transport Layer Security (DTLS) protocol. When a session is created, Web RTC exports the session key required for the session and binds this session key to the entire call process of the session, thereby achieving encryption and integrity verification of session creation.

[0004] However, in the above methods, since the session key is bound to the entire call process, there is a risk that the session key will be exposed for a long time and that permissions will be abused, resulting in poor security of the network session. Summary of the Invention

[0005] This application provides a session creation method, apparatus, electronic device, storage medium, and program product for improving the security of network sessions.

[0006] In a first aspect, this application provides a session creation method applied to a session creation server, comprising: receiving a first session request from a calling device, the first session request being used to request the establishment of a first session between the calling device and a called device, the first session request carrying first session parameters for establishing the first session; if the first session parameters pass verification, generating a first session key ciphertext corresponding to the calling device, and generating a second session key ciphertext corresponding to the called device; sending the first session key ciphertext and the session address of the called device to the calling device through a first encrypted path, and sending a call request corresponding to the session request to the called device to establish the first session between the calling device and the called device; wherein the call request carries the second session key ciphertext and the session address of the calling device.

[0007] The technical solution provided in this application brings at least the following benefits: the session creation server generates a unique session key ciphertext in real time each time a network session is established, without relying on a static key store, thus avoiding the risk of "long-term exposure of the key"; moreover, the generated session key needs to be transmitted through two layers of encryption, that is, the session key is encrypted by both the calling device and the called device, and then the session key ciphertext is transmitted to the corresponding devices through the first encryption path, thereby improving the security of the session creation process.

[0008] One possible implementation involves generating a first session key ciphertext corresponding to the calling device and a second session key ciphertext corresponding to the called device, provided that the first session parameters pass verification. This includes: randomly generating a session key corresponding to the first session request; encrypting the session key using a first encryption algorithm corresponding to the calling device to obtain the first session key ciphertext; and encrypting the session key using a second encryption algorithm corresponding to the called device to obtain the second session key ciphertext.

[0009] Another possible implementation, wherein the first session parameters include: a first hash value, the first hash value corresponding to the first session identifier of the first session request, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated; before generating the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device, if the session parameters pass the verification, the method further includes: determining that the first session parameters pass the verification if the duration between the first timestamp and the timestamp when the calling device initiates the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the stored device identifier of the calling device, and the device identifier of the called device is the same as the stored device identifier of the called device.

[0010] Another possible implementation, before receiving the first session request sent by the calling device to the called device, further includes: receiving a second session request from the calling device, the second session request being used to request the establishment of a session between the calling device and the called device, the second session request carrying ciphertext of session request construction parameters and a first public key corresponding to the ciphertext, the session request construction parameters including: a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated; decrypting the ciphertext based on the first private key corresponding to the first public key to obtain the session request construction. The parameters are as follows: Based on the device identifier of the calling device in the session request construction parameters, the session information corresponding to the calling device is determined from the database. The session information includes the device status and session permissions of the calling device. If the device status is normal and it has session permissions for the called device, a first session identifier is randomly generated. Based on the first session identifier, the device identifier of the calling device, the device identifier of the called device, and a third timestamp, a first session request is generated. The third timestamp is the current timestamp. The first session request is encrypted based on a third encryption algorithm and sent to the calling device.

[0011] Another possible implementation is that, after establishing the first session between the calling device and the called device, the method further includes: deleting the first session key ciphertext, the second session key ciphertext, and the first session parameters when the end of the first session is detected.

[0012] Secondly, this application provides a session creation apparatus applied to a session creation server, comprising: a receiving module, a generating module, and a sending module. The receiving module is configured to receive a first session request from a calling device, the first session request requesting the establishment of a first session between the calling device and the called device, the first session request carrying first session parameters for establishing the first session. The generating module is configured to, if the first session parameters pass verification, generate a first session key ciphertext corresponding to the calling device and a second session key ciphertext corresponding to the called device. The sending module is configured to send the first session key ciphertext and the session address of the called device to the calling device via a first encrypted path, and send a call request corresponding to the session request to the called device to establish the first session between the calling device and the called device; wherein the call request carries the second session key ciphertext and the session address of the calling device.

[0013] In one possible implementation, the aforementioned generation module is specifically used to randomly generate a session key corresponding to the first session request when the first session parameters pass the verification; and to encrypt the session key based on the first encryption algorithm corresponding to the calling device to obtain the first session key ciphertext; and to encrypt the session key based on the second encryption algorithm corresponding to the called device to obtain the second session key ciphertext.

[0014] In another possible implementation, the first session parameters include: a first hash value, a first session identifier corresponding to the first session request, a device identifier of the calling device, a device identifier of the called device, and a first timestamp when the first session request was generated; the session creation device further includes a determining module. The determining module is used to determine that the session parameters have passed verification before generating the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device, provided that the session parameters have passed verification. Specifically, before generating the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device, the determining module determines that the session parameters have passed verification if the duration between the first timestamp and the timestamp when the calling device initiated the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the stored device identifier of the calling device, and the device identifier of the called device is the same as the stored device identifier of the called device.

[0015] In another possible implementation, the receiving module is further configured to receive a second session request from the calling device before receiving the first session request sent by the calling device to the called device. This second session request requests the establishment of a session between the calling and called devices. The second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include: a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. The session creation device further includes a processing module. The processing module is configured to decrypt the ciphertext based on the first private key corresponding to the first public key to obtain the session request construction parameters; and based on the device identifier of the calling device in the session request construction parameters, determine the session information corresponding to the calling device from the database. The session information includes the device status and session permissions of the calling device. The aforementioned generation module is further configured to, when the device is in a normal state and has session permissions for the called device, randomly generate a first session identifier, and generate a first session request based on the first session identifier, the device identifier of the calling device, the device identifier of the called device, and a third timestamp, where the third timestamp is the current timestamp. The aforementioned processing module is further configured to encrypt the first session request based on a third encryption algorithm; the aforementioned sending module is further configured to send the encrypted first session request to the calling device.

[0016] In another possible implementation, the above-mentioned session creation device further includes a processing module; the processing module is used to delete the first session key ciphertext, the second session key ciphertext, and the first session parameters after establishing the first session between the calling device and the called device, in the case of detecting the end of the first session.

[0017] Thirdly, this application provides a session creation method applied to a calling device, comprising: generating a second session request, the second session request carrying ciphertext of session request construction parameters and a first public key corresponding to the ciphertext, the session request construction parameters including a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated; sending the second session request to a session creation server, the second session request being used to request the establishment of a session between the calling device and the called device; receiving an encrypted first session request sent by the session creation server, the first session request being generated by the session creation server based on the session request construction parameters; decrypting the first session request based on a second private key corresponding to the second public key to obtain first session parameters, the first session parameters including: a first hash value, the first hash value corresponding to the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated; and sending the first session request to the session creation server if the duration between the first timestamp and the second timestamp is less than or equal to a preset duration.

[0018] The technical solution provided in this application brings at least the following beneficial effects: After receiving the first session request sent by the session creation server, the calling device can verify that the duration between the first timestamp and the second timestamp in the first session request is less than or equal to a preset duration, thereby determining to send the first session request to the session creation server. That is, by establishing a dynamic permission control mechanism based on a time window, the session key management mode is optimized, and the risk of session key exposure and permission abuse is reduced.

[0019] One possible implementation is that sending a second session request to the session creation server includes: verifying the session certificate corresponding to the calling device, and sending a second session request to the session creation server if the session certificate verification is successful.

[0020] Fourthly, this application provides a session creation apparatus applied to a calling device, comprising: a generation module, a sending module, a receiving module, and a processing module. The generation module generates a second session request, which carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. The sending module sends the second session request to a session creation server, which requests the establishment of a session between the calling device and the called device. The receiving module receives an encrypted first session request sent by the session creation server, which is generated by the session creation server based on the session request construction parameters. The processing module decrypts the first session request based on a second private key corresponding to the second public key to obtain first session parameters, which include: a first hash value, which corresponds to the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated. The sending module is also used to send a first session request to the session creation server when the duration between the first timestamp and the second timestamp is less than or equal to a preset duration.

[0021] One possible implementation is that the processing module described above is specifically used to verify the session certificate corresponding to the calling device. The sending module described above is specifically used to send a second session request to the session creation server if the session certificate verification passes.

[0022] Fifthly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect or the method of the third aspect.

[0023] In a sixth aspect, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method of the first aspect or the method of the third aspect.

[0024] In a seventh aspect, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method of the first aspect or the method of the third aspect described above.

[0025] The beneficial effects of aspects four through seven mentioned above are described in the corresponding descriptions of aspects one or three, and will not be repeated here. Attached Figure Description

[0026] Figure 1 This is a schematic diagram illustrating the application environment of a session creation method provided in an embodiment of this application. Figure 2 A flowchart illustrating a session creation method provided in an embodiment of this application; Figure 3 A flowchart illustrating another session creation method provided in an embodiment of this application; Figure 4 A flowchart illustrating yet another session creation method provided in an embodiment of this application; Figure 5 A flowchart illustrating yet another session creation method provided in an embodiment of this application; Figure 6 A flowchart illustrating yet another session creation method provided in an embodiment of this application; Figure 7 A flowchart illustrating yet another session creation method provided in an embodiment of this application; Figure 8 A flowchart illustrating yet another session creation method provided in an embodiment of this application; Figure 9 A flowchart illustrating a method for a calling device to generate a second session request, provided in an embodiment of this application; Figure 10 A flowchart illustrating a method for verifying the legitimacy of a calling party in accordance with an embodiment of this application; Figure 11 A flowchart illustrating a voice session establishment and transmission method provided in an embodiment of this application; Figure 12 A schematic diagram of a session creation system provided in this application embodiment; Figure 13 This is a schematic diagram illustrating the composition of a session creation apparatus provided in an embodiment of this application; Figure 14 A schematic diagram illustrating the composition of another session creation apparatus provided in this application embodiment; Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The session creation method, apparatus, electronic device, storage medium, and program product provided in this application will now be described in detail with reference to the accompanying drawings.

[0028] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0029] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0030] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0031] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0032] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0033] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0034] The session creation method provided in this application can be applied to network call scenarios.

[0035] For example, embodiments of this application can be applied to network voice call scenarios or network video call scenarios.

[0036] Currently, with the rapid development of the mobile Internet, APP network calling applications are widely used. However, the public network environment is complex, and security threats such as information leakage, malicious attacks, and session hijacking occur frequently, seriously affecting user privacy and call quality. Therefore, it is urgent to build a comprehensive and efficient security protection system.

[0037] In one approach within related technologies, Web RTC, as a mainstream technology for real-time audio and video communication, forms the basis of existing solutions with its security mechanisms. Standard Web RTC implementations negotiate and generate a master key and a master salt via the DTLS protocol, and then derive the session key required by the Secure Real-time Transport Protocol (SRTP) through a key derivation function, thereby achieving encryption and integrity verification during the call process.

[0038] In another approach within related technologies, two-factor authentication has formed the technological foundation for identity security across various fields, namely, using a combination of "password + dynamic code" to enhance authentication security.

[0039] In another approach within related technologies, mobile terminal code protection technology provides a reference for front-end security. By increasing the difficulty of reverse analysis through techniques such as binary code encryption and process obfuscation, its implemented dynamic string encryption can effectively hide critical logic.

[0040] In another related technology, the mainstream solution for data transmission security uses the Secure Sockets Layer (SSL) protocol to ensure communication security. This employs a "one message, one key" key management strategy.

[0041] However, the above-mentioned solution has the following six problems.

[0042] 1. The security mechanism is fragmented, with encryption, identity authentication, and anti-tampering functions implemented independently. There is a lack of coordination and linkage, making it impossible to form end-to-end security protection. This makes it difficult to defend against cross-link security threats (such as data transmission being tampered with after identity authentication).

[0043] 2. The session management is weak. There is no dynamic permission control mechanism based on time windows, and the session key lifecycle is bound to the entire call, which poses a risk of long-term key exposure and permission abuse.

[0044] 3. Insufficient protocol layer protection: critical information in the SSL protocol is not encrypted and lacks a strict format verification mechanism. The integration of authentication and encryption mechanisms during the Web RTC session establishment phase is low, making it easy for protocol layer tampering or hijacking to occur.

[0045] 4. Imbalance between terminal and cloud protection: Front-end code often uses static obfuscation technology, which is difficult to resist dynamic debugging attacks and does not coordinate with the back-end verification mechanism. Single terminal protection is easily bypassed, resulting in the failure of terminal-side security defenses.

[0046] 5. There is an imbalance between the adaptability and security of transmission encryption schemes. Some schemes (such as encryption based on quantum mobile user identity module (SIM) cards) rely on dedicated hardware and cannot be adapted to general mobile apps; traditional SSL protocol key negotiation is not combined with business permission verification, which cannot prevent unauthorized users from operating without authorization.

[0047] 6. The identity authentication coverage is incomplete. Two-factor authentication is mostly limited to the login stage and does not cover the entire call establishment process. Furthermore, it is disconnected from the communication encryption mechanism, posing a risk of unauthorized access to the call after identity forgery.

[0048] To address the aforementioned technical issues, this application provides a session creation method, apparatus, electronic device, storage medium, and program product. The session creation server generates a unique session key ciphertext in real time each time a network session is established, without relying on a static key store, thus avoiding the risk of "long-term key exposure." Moreover, the generated session key needs to be transmitted through two layers of encryption: the session key is encrypted by both the calling and called devices, and then the ciphertext of the session key is transmitted to the corresponding devices through a first encryption path, thereby improving the security of the session creation process.

[0049] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0050] The session creation method provided in this application can be applied to, for example... Figure 1 The application environment shown. For example... Figure 1 As shown, Figure 1 This is a schematic diagram of an application environment for a session creation method provided in this application. The application environment includes a session creation device 101 and a front-end device 102. The session creation device 101 and the front-end device 102 are interconnected.

[0051] In some embodiments, the session creation apparatus 101 may be a server cluster consisting of multiple servers, a single server, a computer, or a processor or processing chip in a server or computer, etc. This application embodiment does not limit the specific device form of the session creation apparatus 101. Figure 1 The example shown is a session creation device 101 serving as a single server.

[0052] In some embodiments, the front-end device 102 can be a device with wireless transceiver capabilities, such as a mobile phone, tablet computer, wearable device, in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. This application embodiment does not limit the specific device form of the front-end device 102. Figure 1 Taking a mobile phone as an example, the front-end device 102 is shown below. Figure 1 The front-end device 102 includes front-end device 1021 and front-end device 1022.

[0053] In some embodiments, the front-end device 1021 sends a first session request to the session creation device 101, and the session creation device 101 receives the first session request sent by the front-end device 1021; and if the first session parameters pass the verification, generates a first session key ciphertext corresponding to the front-end device 1021 and generates a second session key ciphertext corresponding to the front-end device 1022; and sends the first session key ciphertext and the session address of the front-end device 1022 to the front-end device 1021 through a first encryption path, and sends a call request corresponding to the session request to the front-end device 1022 to establish a first session between the front-end device 1021 and the front-end device 1022.

[0054] It should be noted that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0055] See Figure 2 This is a flowchart illustrating a session creation method provided in an embodiment of this application. Figure 2 As shown, the session creation method provided in this application can be implemented through a session creation server, specifically including the following steps S201 to S203.

[0056] S201. The session creation server receives the first session request from the calling device.

[0057] In some embodiments, the first session request is used to request the establishment of a first session between the calling device and the called device, and the first session request carries first session parameters for establishing the first session.

[0058] For example, the session creation server described above can be a call platform.

[0059] In some embodiments, the first session described above may be a network session.

[0060] For example, the aforementioned network session can be a network voice session or a network video session. The specific session can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0061] In some implementations, when the first session is a VoIP session, the aforementioned first session request can be a first voice session request; when the aforementioned first session is a VoIP session, the aforementioned first session request can be a first video session request.

[0062] In some embodiments, the session creation server described above can be wirelessly connected to the calling device.

[0063] For example, the aforementioned wireless connection can be a Wireless Fidelity (Wi-Fi) connection or a mobile network connection. The specific connection can be determined based on actual usage requirements, and this application embodiment does not impose any limitations.

[0064] In some embodiments, the session creation server can receive a first session request from the calling device through the session request interface.

[0065] For example, the above-mentioned session request interface can be a voice session request interface or a video session request interface.

[0066] For example, if the first session request is a voice session request, the session creation server can receive the voice session request from the calling device through the voice session request interface; or, if the first session request is a video session request, the session creation server can receive the video session request from the calling device through the video session request interface.

[0067] In some embodiments, the session creation server described above may include an Nginx server and a Web RTC server.

[0068] For example, the Nginx server described above may include a voice session request interface or a video session request interface. That is, the session creation server can receive the first session request from the calling device through the Nginx server.

[0069] S202. If the first session parameters pass the verification, the session creation server generates the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device.

[0070] In some embodiments, the first session key ciphertext may be the ciphertext of the first session key after encryption.

[0071] In some embodiments, the second session key ciphertext may be the ciphertext of the first session key after encryption.

[0072] It should be noted that the encryption methods of the first session key ciphertext and the second session key ciphertext can be the same or different. The specific method can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions.

[0073] In some embodiments, if the first session parameters pass verification, the session creation server can generate the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device through the Web RTC server.

[0074] It should be noted that the specific implementation of S202 above can be found in the following embodiments, and will not be repeated here to avoid repetition.

[0075] S203. The session creation server sends the first session key ciphertext and the session address of the called device to the calling device through the first encrypted path, and sends a call request corresponding to the session request to the called device to establish the first session between the calling device and the called device.

[0076] In some embodiments, the call request carries a second session key ciphertext and the session address of the calling device.

[0077] For example, the first encrypted path described above can be a Web Socket Secure (WSS) path.

[0078] In some embodiments, the session address of the called device may include the public IP address and session port of the called device.

[0079] In some embodiments, the session address of the calling device may include the public IP address and session port of the calling device.

[0080] In the session creation method provided in this application, the session creation server receives a first session request from a calling device. This first session request is used to request the establishment of a first session between the calling device and the called device. The first session request carries first session parameters for establishing the first session. If the first session parameters pass verification, a first session key ciphertext corresponding to the calling device is generated, and a second session key ciphertext corresponding to the called device is also generated. The first session key ciphertext and the session address of the called device are sent to the calling device through a first encryption path, and a call request corresponding to the session request is sent to the called device to establish the first session between the calling device and the called device. The call request carries the second session key ciphertext and the session address of the calling device. In this solution, the session creation server generates a unique session key ciphertext in real time each time a network session is established, without relying on a static key store, thus avoiding the risk of "long-term key exposure." Moreover, the generated session key needs to be transmitted through two layers of encryption, namely, the session key is encrypted by both the calling device and the called device, and then the session key ciphertext is transmitted to the corresponding devices through the first encryption path, thereby improving the security of the session creation process.

[0081] In some embodiments, combined with Figure 2 ,like Figure 3 As shown, the above S202 can be specifically implemented as the following steps S202a to S202c.

[0082] S202a. If the first session parameters pass the verification, the session creation server randomly generates the session key corresponding to the first session request.

[0083] In some embodiments, the session creation server may randomly generate the session key corresponding to the first session request using a preset key algorithm.

[0084] For example, the preset key algorithm can be the AES-256-GCM_Generate algorithm.

[0085] For example, the session creation server can randomly generate the session key corresponding to the first session request using the following formula (1), which is as follows: Session Key = AES-256-GCM_Generate(1) Wherein, Session Key is the session key corresponding to the first session request, and AES-256-GCM_Generate is the preset key algorithm.

[0086] S202b: The session creation server encrypts the session key based on the first encryption algorithm corresponding to the calling device to obtain the first session key ciphertext.

[0087] In some embodiments, the first encryption algorithm described above can be preset by the session creation server; or it can be customized by the calling device. The specific algorithm can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0088] For example, the first encryption algorithm described above may be RSA2048.

[0089] For example, the session creation server can input the session key into the RSA2048 encryption algorithm to output the first session key ciphertext through the RSA2048 encryption algorithm.

[0090] S202c: The session creation server encrypts the session key based on the second encryption algorithm corresponding to the called device to obtain the second session key ciphertext.

[0091] In some embodiments, the second encryption algorithm described above can be preset by the session creation server; or it can be customized by the called device. The specific algorithm can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0092] For example, the second encryption algorithm described above can be RSA2048.

[0093] For example, the session creation server can input the session key into the RSA2048 encryption algorithm to output a second session key ciphertext via the RSA2048 encryption algorithm.

[0094] In this embodiment, the session creation server transmits the generated session key through two layers of encryption: the session key is encrypted by both the calling and called devices, and then the ciphertext of the session key is transmitted to the corresponding devices through a first encryption path, thereby improving the security of the session creation process.

[0095] It should be understood that the session creation server can determine whether the parameters of the first session pass the validation.

[0096] Therefore, the first session parameters mentioned above include: a first hash value, which corresponds to the first session identifier corresponding to the first session request, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated.

[0097] In some embodiments, the first session identifier can be any of the following: a numeric identifier, a text identifier, or a special symbol identifier, etc. The specific identifier can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0098] In some embodiments, the device identifier can be any of the following: a numerical identifier, a text identifier, or a special symbol identifier, etc. The specific identifier can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0099] In some embodiments, the first timestamp can be a 13-bit timestamp, that is, the first timestamp can be accurate to milliseconds.

[0100] For example, combined Figure 2 ,like Figure 4 As shown, prior to S202 above, the present application embodiment provides a session creation method, which further includes the following step S301.

[0101] S301. If the duration between the first timestamp and the timestamp when the calling device initiates the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the device identifier of the called device stored, and the device identifier of the called device is the same as the device identifier of the called device stored, the session creation server determines that the first session parameters have passed the verification.

[0102] In some embodiments, the aforementioned preset duration can be preset by the session creation server or defined by the user. The specific duration can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0103] In some embodiments, the first session parameter may also carry a verification header, which is preset.

[0104] For example, the aforementioned inspection header can be X-Sec-Check.

[0105] In some embodiments, after receiving the first session request, the session creation server can first determine that the format of the first session parameter is a hash value + 13-bit timestamp through the verification header. Then, if the duration between the first timestamp and the timestamp when the calling device initiates the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the stored device identifier of the calling device, and the device identifier of the called device is the same as the stored device identifier of the called device, the first session parameter is determined to pass the verification.

[0106] In some embodiments, if the first session parameter is determined to have failed verification, the session creation server may terminate the first session request and send a session request failure message to the calling device.

[0107] It should be understood that the session creation server can determine the session request to rebuild between the calling and called devices.

[0108] Therefore, combining Figure 2 ,like Figure 5 As shown, prior to S201 above, the present application embodiment provides a session creation method, which further includes the following steps S401 to S405.

[0109] S401. The session creation server receives a second session request from the calling device.

[0110] In some embodiments, the second session request is used to request the establishment of a session between the calling device and the called device. The second session request carries the ciphertext of the session request construction parameters and the first public key corresponding to the ciphertext. The session request construction parameters include: the session identifier corresponding to the second session request, the device identifier of the calling device, the device identifier of the called device, and the second timestamp when the second session request was generated.

[0111] In some embodiments, after receiving a second session request from the calling device, the Nginx server in the session creation server can verify the session certificate of the calling device. If the session certificate is verified, the second session request can be transmitted to the Web RTC server in the session creation server for subsequent operations.

[0112] It is understandable that if the session certificate of the calling device fails to be verified, the Nginx server in the session creation server can send a session certificate verification failure message to the Web RTC server in the session creation server. Upon receiving the session certificate verification failure message, the Web RTC server in the session creation server will terminate the first session request and send a session request failure message to the calling device.

[0113] For example, the above session certificate verification can specifically be: verifying the certificate chain (root certificate authority (CA) → intermediate CA → server certificate), validity period (current time is within the certificate's effective / expired period), and domain name matching (the certificate domain name is consistent with the calling device's domain name).

[0114] S402. The session creation server decrypts the ciphertext based on the first private key corresponding to the first public key to obtain the session request construction parameters.

[0115] It should be noted that the above decryption process can be found in the description of relevant technologies, and will not be repeated here to avoid repetition.

[0116] S403. The session creation server determines the session information corresponding to the calling device from the database based on the device identifier of the calling device in the session request construction parameters.

[0117] In some embodiments, the session information includes the device status of the calling device and the session permissions of the calling device.

[0118] For example, the database mentioned above can be a Redis database.

[0119] In some embodiments, the session creation server can determine the device identifier of the calling device. The session information corresponding to the calling device is determined from the database using fuzzy matching. In some embodiments, the session creation server can determine the device status of the called device from the database based on the device identifier of the called device in the session request construction parameters.

[0120] S404. When the device is in a normal state and has session permissions for the called device, the session creation server randomly generates a first session identifier and generates a first session request based on the first session identifier, the device identifier of the calling device, the device identifier of the called device, and a third timestamp.

[0121] In some embodiments, the third timestamp mentioned above is the current timestamp.

[0122] For example, the fact that the calling device is in a normal state can be understood as: confirming that the calling device exists and there is no blocking record.

[0123] For example, the calling device's session permission to the called device can be: the calling device's "Call Permission" field in the database is set to "Allow".

[0124] In some embodiments, when the calling device is in a normal state, the called device is in a normal state, and the calling device has session permissions for the called device, the session creation server randomly generates a first session identifier.

[0125] In some embodiments, the session creation server may obtain the first session identifier described above through a random number generation algorithm.

[0126] In some embodiments, the session creation server may concatenate the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the third timestamp to obtain a first string, then perform a hash operation on the first string to obtain the first hash value, and then associate the first hash value with the session request to obtain the first session request.

[0127] S405. The session creation server encrypts the first session request based on a third encryption algorithm and sends the encrypted first session request to the calling device.

[0128] For example, the third encryption algorithm can be preset, such as RSA2048.

[0129] In some embodiments, the session creation server may encrypt the first session parameters carried in the first session request based on the public key stored in the calling device to obtain the encrypted first session request.

[0130] In some embodiments, the session creation server may send an encrypted first session request to the calling device via a Hyper Text Transfer Protocol Secure (HTTPS) transmission path.

[0131] In some embodiments, after obtaining the first session parameters, the session creation server may store the first session parameters.

[0132] It should be understood that the session creation server can also delete the session information corresponding to the first session if the first session ends.

[0133] In this embodiment, the session creation server employs a "triple obfuscation strategy"—randomly renaming variable / function names, adding redundant code blocks with no logical connection (which do not affect execution efficiency and can be automatically skipped), and flattening the control flow (disrupting the code execution order so that reverse engineering tools cannot restore the normal logic)—to resist professional reverse engineering tools and ensure the security of the first session parameters.

[0134] Therefore, combining Figure 2 ,like Figure 6 As shown, after S203 above, this application embodiment provides a session creation method, which further includes the following step S501.

[0135] S501. If the end of the first session is detected, the session creation server deletes the first session key ciphertext, the second session key ciphertext, and the first session parameters.

[0136] In some embodiments, when the end of the first session is detected, the session creation server can use the first session identifier corresponding to the first session to search the database for the first session key ciphertext, the second session key ciphertext, and the first session parameters through a fuzzy search, and then delete the first session key ciphertext, the second session key ciphertext, and the first session parameters.

[0137] In this embodiment of the application, after the call ends, the Web RTC server immediately destroys the first session key ciphertext, the second session key ciphertext, and the first session parameters, eliminating the security risks caused by "key reuse or residue".

[0138] See Figure 7 This is a flowchart illustrating another session creation method provided in an embodiment of this application. Figure 7 As shown, the session creation method provided in this application can be implemented by the calling device, specifically including the following steps S601 to S605.

[0139] S601, The calling device generates a second session request.

[0140] In some embodiments, the second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated.

[0141] In some embodiments, the calling device may obtain session request construction parameters and generate a second session request based on the session request construction parameters.

[0142] For example, the calling device can obtain the session identifier corresponding to the second session request, the device identifier of the calling device, the device identifier of the called device, and the second timestamp when the second session request was generated. Then, it concatenates the session identifier corresponding to the second session request, the device identifier of the calling device, the device identifier of the called device, and the second timestamp when the second session request was generated into a string to obtain a second string. Then, it performs a hash operation on the second string to obtain a second hash value. Finally, it associates and stores the second hash value with the session request to obtain the second session request.

[0143] In some embodiments, the calling device may encrypt the second session request using the public key corresponding to the session creation server and send the encrypted second session request to the session creation server.

[0144] S602. The calling device sends a second session request to the session creation server.

[0145] In this embodiment of the application, the second session request is used to request the establishment of a session between the calling device and the called device.

[0146] In some embodiments, the calling device may send a second session request to the session creation server via an HTTPS encrypted path.

[0147] S603. The calling device receives the encrypted first session request sent by the session creation server.

[0148] In some embodiments, the first session request is generated by the session creation server based on the session request construction parameters.

[0149] In some embodiments, the calling device may receive an encrypted first session request from the session creation server via an HTTPS encrypted path.

[0150] S604. The calling device decrypts the first session request based on the second private key corresponding to the second public key to obtain the first session parameters.

[0151] In some embodiments, the first session parameter includes a first hash value, which corresponds to the first session identifier corresponding to the first session request, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated.

[0152] It should be noted that the decryption process of the calling device can be found in the above embodiments, and will not be repeated here to avoid repetition.

[0153] S605. If the duration between the first timestamp and the second timestamp is less than or equal to a preset duration, the calling device sends a first session request to the session creation server.

[0154] In some embodiments, the preset duration can be determined by the calling device or defined by the user. The specific duration can be determined according to actual usage requirements, and this application embodiment does not impose any limitations.

[0155] In some embodiments, the calling device may subtract the first timestamp from the second timestamp to obtain a first difference, and then send a first session request to the session creation server if the first difference is less than or equal to a preset duration.

[0156] In the session creation method provided in this application embodiment, the calling device can generate a second session request. The second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request is generated. The calling device sends the second session request to a session creation server. The second session request is used to request the establishment of a session between the calling device and the called device. The calling device receives an encrypted first session request sent by the session creation server. The first session request is generated by the session creation server based on the session request construction parameters. The calling device decrypts the first session request based on the second private key corresponding to the second public key to obtain first session parameters. The first session parameters include a first hash value, which corresponds to the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request is generated. If the duration between the first timestamp and the second timestamp is less than or equal to a preset duration, the calling device sends the first session request to the session creation server. In this solution, after receiving the first session request sent by the session creation server, the calling device can verify that the duration between the first timestamp and the second timestamp in the first session request is less than or equal to a preset duration, thereby determining to send the first session request to the session creation server. That is, by establishing a dynamic permission control mechanism based on a time window, the session key management mode is optimized, and the risk of session key exposure and permission abuse is reduced.

[0157] In some embodiments, combined with Figure 7 ,like Figure 8 As shown, the above S602 can be specifically implemented as the following step S602a.

[0158] S602a: The calling device verifies the session certificate corresponding to the calling device, and if the session certificate verification is successful, sends a second session request to the session creation server.

[0159] In some embodiments, the calling device may include a front-end APP and a back-end server. The front-end APP may be used to obtain first session parameters, and the back-end server may be used to verify the session certificate.

[0160] It should be noted that the specific methods for verifying the session certificate described above can be found in the above embodiments, and will not be repeated here to avoid duplication.

[0161] In some embodiments, the backend server in the calling device can send a second session request to the session creation server via HTTPS.

[0162] In this embodiment, the calling device deeply couples the encryption algorithm, dynamic key generation, and anti-reverse obfuscation logic with the business request module to achieve integrated front-end protection of "request initiation - data encryption - identity verification". The back-end server, as an intermediate verification layer, not only forwards data but also undertakes the intermediate protection responsibilities of "front-end signature verification - encrypted forwarding of calling and called information - secondary processing of verification results by the call platform", forming a progressive protection of "front-end anti-tampering - intermediate anti-leakage - back-end anti-unauthorized access", thereby improving the security of the session process.

[0163] The following describes a specific embodiment of the process by which the calling device generates a second session request, as provided in this application. The specific process of the calling device generating a second session request is as follows: Figure 9 As shown, Figure 9 This is a flowchart illustrating a method for a calling device to generate a second session request, provided in an embodiment of this application. The calling device includes a front-end APP and a back-end server, and the specific process is as follows: S1 to S6.

[0164] S1. The front-end APP sets system parameters.

[0165] For example, the calling device can set the asymmetric encryption algorithm to RSA2048, the symmetric encryption algorithm to AES-256-GCM, the hash algorithm to SHA-256, the buffer timeout to 10 seconds, the Transport Layer Security (TLS) version to 1.3, and the Secure Real-time Transport Protocol (SRTP) cipher suite to AES_CM_128_HMAC_SHA1_80.

[0166] S2, the front-end APP sets the session parameters.

[0167] For example, the front-end APP in the calling device stores the public key of the back-end server and the public key of the session creation server; the back-end server stores the public key of the session creation server; the database of the session creation server stores the device identifier of the calling device, the public key of the calling device, the device identifier of the called device, and the public key of the called device, and both the calling device and the called device are legitimate registered users.

[0168] S3. The front-end APP obtains the session request parameters.

[0169] For example, when a user clicks "Call User B" in the front-end app and enters the device identifier of the called device, the service request module in the front-end app generates the following request parameters: {ReqID: "R20250909001", CallerID: "ID_A", CalleeID: "ID_B", Timestamp: "1725859200000"}. Here, R20250909001 is the session identifier, ID_A is the device identifier of the calling device, ID_B is the device identifier of the called device, and Timestamp is the current millisecond-level timestamp.

[0170] S4. The front-end APP encrypts the session request parameters.

[0171] For example, the front-end APP calculates the hash value corresponding to the session request parameters, and encrypts the hash value with the front-end APP's private key to obtain the encrypted hash value: Sign. The back-end server's public key is used to encrypt the session request parameters and Sign to obtain the digital signature Enc_Req.

[0172] S5. The front-end APP sends Enc_Req to the back-end server via HTTPS.

[0173] In some embodiments, while the front-end APP sends Enc_Req to the back-end server, the certificate verification module in the front-end APP verifies the back-end server. If the verification passes, the request continues; if the verification fails, the request is terminated.

[0174] S6. The backend server receives the Enc_Req sent by the frontend APP, decrypts it with its own private key to obtain the plaintext request parameters and Sign; calculates the hash value Hash' of the plaintext parameters, decrypts Sign with the frontend APP's public key to obtain Hash''; if Hash' == Hash'', then the anti-tampering and identity verification are passed; otherwise, the request is rejected and the frontend APP is sent with the error code "403 Invalid Sign".

[0175] In some embodiments, the above-mentioned "front-end-back-transport layer" three-layer collaborative architecture can be replaced by the following technical solutions.

[0176] For example, Solution 1 adopts a microservice architecture of "client proxy - server proxy - security control plane" to replace the component coupling logic of the traditional three-tier architecture: core components: based on the Istio service mesh, deploying Envoy sidecar proxy (built into each microservice node), security control plane (unified management policy), and identity management service (storing user public keys and permissions).

[0177] The client APP integrates a lightweight proxy software development kit (SDK). All requests are first encrypted by the client proxy and then transmitted through the mTLS encrypted channel between Envoy proxies. The control plane dynamically pushes "front-end anti-tampering rules, middle-layer forwarding permissions, and back-end verification policies" through the xDS protocol, replacing the linkage between the business-side back-end intermediate verification and the call platform component in the original solution.

[0178] The client-side proxy is packaged and integrated with the APP front-end, while the server-side Envoy proxy and the business / call platform microservices are deployed on the same node. The control plane is deployed independently (at least a 2-node cluster to ensure high availability).

[0179] It should be noted that, while maintaining equivalence to the original solution, this solution also achieves progressive protection of "front-end anti-tampering - middle-end anti-leakage - back-end anti-authorization," thus solving the "protection gap" problem of existing technologies. The difference lies in that the original solution relies on a fixed component hierarchy, while this solution achieves dynamic policy management through a service mesh, resulting in stronger scalability (supporting elastic scaling of microservices).

[0180] For example, Solution 2 constructs a three-layer architecture of "terminal-edge node-cloud" for IoT mobile terminals (such as industrial apps and in-vehicle voice calls).

[0181] Terminal layer: The APP front-end integrates a lightweight encryption module, supporting the CoAPs lightweight encryption protocol; Edge layer: Deploy edge servers (local deployment, distance from the terminal ≤ 50km) to undertake the functions of "preliminary verification of the legitimacy of the calling party and the called party, dynamic key generation, and STUN NAT traversal", replacing 70% of the verification logic on the business side backend in the original solution.

[0182] Cloud layer: Retains the core components of the call platform backend (user database, cache module), and only handles abnormal requests reported by the edge layer (such as cross-regional calls, high-privilege user verification). The edge and cloud communicate encryptedly via the MQTTs protocol.

[0183] In addition, there is the CoAPs encrypted interaction protocol between edge nodes and terminals, the abnormal request synchronization mechanism between the edge and the cloud, and the logic for localizing the generation of dynamic keys in the edge layer (based on terminal hardware identifier + edge node public key).

[0184] In this embodiment, by deeply coupling the encryption algorithm, dynamic key generation, and anti-reverse obfuscation logic with the business request, an integrated front-end protection of "request initiation - data encryption - identity verification" is achieved. The back-end server, as an intermediate verification layer, not only forwards data but also undertakes the intermediate protection responsibilities of "front-end signature verification - encrypted forwarding of calling and called information - secondary processing of verification results by the call platform", forming a progressive protection of "front-end anti-tampering - intermediate anti-leakage - back-end anti-unauthorized access".

[0185] The following describes the specific process of verifying the legitimacy of the calling party provided in this application embodiment, using a specific example. The specific process of verifying the legitimacy of the calling party is as follows: Figure 10 As shown, Figure 10 This is a flowchart illustrating a method for verifying the legitimacy of a calling party in an embodiment of this application. The calling party device includes a front-end APP and a back-end server, and the session creation server includes an Nginx server and a Web RTC server. The specific process is as follows: S7 to S12.

[0186] S7. After the backend server verifies the connection, it collects the session parameter information of the calling and called devices, encrypts the session parameter information using the public key of the session creation server, obtains the encrypted session parameter information Enc_UserInfo, and sends Enc_UserInfo to the Nginx server via HTTPS.

[0187] For example, the above session parameter information includes the device identifier of the calling device, the device identifier of the called device, and a verification timestamp.

[0188] The S8 and Nginx servers verify the session certificate of the backend server. Once verified, they send Enc_UserInfo to the Web RTC server.

[0189] The S9 Web RTC server uses its own private key to decrypt, obtain session parameter information, and query the user database.

[0190] For example, the above query of the user database can be used to confirm that the calling device exists and its status is "normal" (no blocking record), that the called device exists and its status is "online", and that the calling device has calling permission.

[0191] After the S10 and Web RTC servers verify the information, they generate temporary verification information, encrypt it with the backend server's public key, obtain Enc_Verify, store the Enc_Verify in the database, and send the Enc_Verify to the Nginx server. The Nginx server then sends the Enc_Verify to the backend server via HTTPS.

[0192] For example, the temporary verification information is {VerifyID: "V1001", CallerID: "ID_A", CalleeID: "ID_B", ExpireTime: "1725859211000"} (ExpireTime = current time + 10 seconds). Here, VerifyID is a randomly generated session identifier, CallerID is the device identifier of the calling device, and CalleeID is the device identifier of the called device.

[0193] S11. The backend server receives the Enc_Verify sent by the Nginx server, decrypts the Enc_Verify using the corresponding private key of the backend server, extracts the VerifyID and ExpireTime, generates the verification string CheckStr, encrypts CheckStr using the public key of the frontend APP, obtains the encrypted CheckStr, and sends the encrypted CheckStr to the frontend APP.

[0194] For example, the process of generating the verification string CheckStr is as follows: CheckStr = VerifyID + ExpireTime + SHA-256(CallerID + CalleeID).

[0195] S12. The front-end APP uses its own private key to decrypt and obtain CheckStr, parses VerifyID and ExpireTime, confirms that the current time is less than or equal to ExpireTime, and initiates a call request with CheckStr.

[0196] In some embodiments, if the current time is greater than ExpireTime, the front-end APP can display the message "Call timed out, please try again".

[0197] In this embodiment, the "protection gap" problem in the existing architecture is solved by the functional coupling and logical linkage of the three-layer components.

[0198] The following describes the specific process of voice session establishment and transmission provided in this application embodiment using a specific example. The specific process of voice session establishment and transmission is as follows: Figure 11 As shown, Figure 11 The following is a flowchart illustrating a method for establishing and transmitting a voice session according to an embodiment of this application. The calling device includes a front-end APP and a back-end server, and the session creation server includes an Nginx server and a Web RTC server. The specific process is as follows: S13 to S29.

[0199] S13. The front-end APP sends a session establishment request to the back-end server, and the back-end server sends a session establishment request to the Nginx server.

[0200] For example, the above session establishment request carries a CheckStr, which includes (custom header "X-Sec-Check": SHA-256(VerifyID+CallerID+CalleeID) + current timestamp).

[0201] S14. The Nginx server receives the session establishment request and sends it to the Web RTC server.

[0202] S15. The Web RTC server receives the session establishment request sent by the Nginx server and performs data verification.

[0203] For example, the Web RTC server determines, based on the custom header "X-Sec-Check", that the session parameters carried in the session establishment request are in the format of a hash value + a 13-bit timestamp, and that the timestamp differs from the server time by ≤3 seconds, and that the hash value is consistent with SHA-256(VerifyID+CallerID+CalleeID). Then, it retrieves Enc_Verify from the cache module, decrypts it with its own private key, extracts VerifyID, and compares it with VerifyID in CheckStr. If they match, the verification is successful.

[0204] S16. If the data verification passes, the Web RTC server generates a dynamic session key and encrypts the session key using the public key corresponding to the calling device to obtain the first session key ciphertext. It also encrypts the session key using the public key corresponding to the called device to obtain the second session key ciphertext. At the same time, it obtains the session information of the calling device and the session information of the called device.

[0205] S17. The Web RTC server sends the first session information and the second session information to the Nginx server.

[0206] For example, the first session information mentioned above includes the first session key ciphertext and the session information of the called device.

[0207] For example, the aforementioned second session information includes the second session key ciphertext and the session information of the calling device.

[0208] S18, the Nginx server sends the first session information to the backend server and the second session information to the called device.

[0209] S19. The called device receives the second session information sent by the Nginx server, decrypts the second session information using its own private key to obtain the session key, and sends a call consent response to the Nginx server.

[0210] S20. The backend server receives the first session information sent by the Nginx server and sends the first session information to the frontend APP.

[0211] S21. The front-end APP uses its own private key to decrypt the first session information, obtains the session key, and establishes a session with the called device.

[0212] S22. The front-end APP encodes the session data into Pulse-code modulation (PCM) format, encrypts the session data using AES-256-GCM with the session key, encapsulates the encrypted session data using the SRTP protocol, and sends the encapsulated encrypted session data to the back-end server. The back-end server then sends the encapsulated encrypted session data to the Nginx server via WSS.

[0213] S23, the Nginx server sends the encapsulated encrypted session data to the Web RTC server.

[0214] S24. The Web RTC server receives the encapsulated encrypted session data sent by the Nginx server, performs an integrity check on the encapsulated encrypted session data, and sends the encapsulated encrypted session data to the called device if the check passes.

[0215] S25. The called device decrypts the encapsulated encrypted session data using the session key, decodes it into PCM format, and then plays it.

[0216] S26. The front-end APP sends a "session termination" request to the back-end server.

[0217] S27. The backend server sends a "session termination" request to the Nginx server.

[0218] S28. The Nginx server sends a "session termination" request to the Web RTC server.

[0219] S29. The Web RTC server destroys the session key and deletes all temporary information about the call from the database.

[0220] In some embodiments, the above-mentioned "dynamic session key + double encryption exchange" can be replaced by the following scheme.

[0221] For example, Scheme 1, Elliptic Curve Cryptography (ECC) elliptic curve key negotiation mechanism (encryption algorithm alternative).

[0222] For example, ECC replaces RSA2048 to achieve "dynamic key + double encryption", that is, key generation: the WebRTC server (or edge node) generates ECC temporary key pairs (using the NIST P-384 curve) instead of RSA keys.

[0223] Then, after the session key is still generated using AES-256-GCM, a shared key is first calculated using the elliptic curve Diffie-Hellman algorithm and the ECC public key of the front-end APP. The session key is then encrypted using the shared key and finally transmitted via WSS.

[0224] Efficiency optimization: The ECC key length is only 384 bits (RSA2048 is 2048 bits), and the encryption / decryption speed is improved by 60%, making it suitable for low computing power terminals (such as smartwatches and old mobile phones).

[0225] Equivalent to the original scheme, it also achieves "one key per message, double encryption, and instant destruction," solving the "static key" problem of existing technologies; the difference is that the original scheme relies on RSA master keys, while this scheme is more suitable for resource-constrained scenarios.

[0226] For example, Scheme 2, the post-quantum cryptography key encapsulation scheme, addresses the threat of quantum computing by employing a post-quantum cryptography standard algorithm.

[0227] For example, key encapsulation: The Web RTC server generates a public / private key pair, the front-end APP uses the Web RTC server's public key to encrypt the session key, and the transport layer still uses WSS.

[0228] Signature verification: After the session key is encrypted, a post-quantum cryptographic digital signature is attached to prevent the key from being tampered with.

[0229] Equivalent to the original solution, this solution achieves a higher level of security (resisting quantum computing attacks) through "post-quantum encryption + double verification"; the difference is that the original solution deals with traditional attacks, while this solution is designed for future security threats.

[0230] In some embodiments, the above-mentioned "full-process dual authentication + timestamp timeout control" can be replaced by the following solution.

[0231] For example, Solution 1, the challenge-response authentication mechanism, uses a "dynamic challenge value" to replace the 10-second timestamp to prevent replay attacks.

[0232] For example, during the business request phase: when the front-end APP sends a request, the back-end server returns a 16-byte random challenge value instead of directly receiving the request; the front-end APP uses its private key to sign the "request parameters + random challenge value" to generate a response value, which is then sent along with the request parameters.

[0233] Legality verification phase: After the Web RTC server verifies the validity, it generates temporary verification information containing "Challenge + validity period (5-30 seconds adaptive, adjusted according to network latency)" and stores it in the cache; During the session establishment phase: The Web RTC server verifies the "match between the Response and the Challenge + validity period", replacing the original solution of "timestamp + VerifyID" verification.

[0234] Equivalent to the original solution, it also covers the entire process of "business request - legality verification - session establishment", and prevents replay attacks through dynamic Challenge (the Challenge is valid only once and expires immediately after use); the difference is that the original solution relies on a fixed timestamp, while this solution is adapted to network fluctuation scenarios (the validity period is automatically extended when the network is weak).

[0235] For example, Scheme 2, the biometric enhanced authentication scheme, adds biometric verification to the original scheme's dual authentication.

[0236] For example, the front-end APP calls the device's biometric module (fingerprint, face, voiceprint) to generate a biometric template (locally encrypted and stored, without transmitting the original data), and uses fuzzy extractor technology to generate 256-bit key material from the template.

[0237] During the business request phase: When signing the request parameters, attach a double digest of "biological key material + parameter hash" (replacing the original solution of only parameter hash). The backend needs to verify the legality of both the signature and the biological key material (by comparing with the biometric database bound to the device).

[0238] During the session establishment phase: The Web RTC server verifies the "validity period of the biometric key material (≤5 minutes) + SIP header verification field", replacing part of the VerifyID verification logic in the original scheme.

[0239] Equivalent to the original solution, this solution achieves triple authentication through "biometrics + identity signature + anti-tampering verification," resulting in a higher level of security than the original solution. The difference lies in that the original solution relies on device identification, while this solution binds to the user's biometrics to prevent unauthorized calls after the device has been stolen.

[0240] In some embodiments, the above-mentioned "custom header verification + key information encryption" can be replaced by the following scheme.

[0241] For example, Solution 1, the Multipurpose Internet Mail Extensions (MIME) standard protocol enhancement solution, uses S / MIME to replace the custom SIP header to achieve standardized security enhancement.

[0242] Message signing: After the SIP message (including the calling and called party IDs and call permissions) is generated, it is digitally signed using the sender's X.509 certificate (stored in the front-end APP / back-end keystore) (the algorithm is ECDSA-with-SHA256), and a MIME signature block is generated and appended to the SIP message body (replacing the original scheme's "X-Sec-Check" custom header). Encryption of critical information: Sensitive fields in SIP messages (caller ID, call duration limit) are encrypted using the recipient's X.509 public key (AES-256-CBC algorithm), instead of the original RSA encryption.

[0243] Verification process: After receiving a SIP message, the Web RTC server first verifies the MIME signature (through a trusted CA certificate chain), then decrypts sensitive fields, and finally verifies the message format (compliant with RFC 8599 S / MIME for SIP standard), replacing the original solution's custom verification logic.

[0244] Equivalent to the original solution, this solution addresses the issues of "easily tampered with and information leaked" in the SIP protocol through "standardized signature + public key encryption + format verification"; the difference lies in that the original solution relies on custom fields, while this solution conforms to international standards and has stronger compatibility.

[0245] For example, Scheme 2, the binary SIP protocol scheme, uses a binary protocol to replace the text-based SIP protocol, thereby improving security and parsing efficiency.

[0246] For example, the protocol definition is as follows: Based on Protocol Buffers (PB), the SIP message structure (alternative text format) is defined, with fields including "call identifier, calling / called identifier, checksum, and timestamp", where the checksum is "CRC32C hash of other fields + private key signature".

[0247] Encryption of key information: The "caller ID and authorization ID" fields in the PB message are encrypted with AES-256-GCM (the key is a derived key of the dynamic session key), instead of the original RSA encryption scheme.

[0248] Transmission adaptation: Binary SIP messages are transmitted via User Datagram Protocol (UDP). The Web RTC server has a built-in PB parser, which improves parsing speed by 3 times compared to text SIP.

[0249] Equivalent to the original solution, this solution achieves the same protocol security through "binary format anti-tampering (CRC32C check) + field encryption"; the difference is that the original solution is suitable for general scenarios, while this solution is suitable for high-performance scenarios.

[0250] In some embodiments, the above-mentioned "multi-layer code obfuscation + dynamic verification string" can be replaced by the following scheme.

[0251] For example, Solution 1, the code obfuscation (Obfuscation-LLVM, OLLVM) compile-time obfuscation solution, uses OLLVM to replace custom code obfuscation to achieve automated compile-time protection.

[0252] For example, obfuscation strategies include: enabling triple obfuscation passes during the LLVM compilation phase; instruction replacement: replacing simple operations (such as addition and multiplication) with functionally equivalent complex expressions (such as a+b→(a-(-b))^0x0); spurious control flow: inserting redundant branches between basic code blocks, with branch conditions always being false; control flow flattening: transforming linear code structures into state machine-based switch-case structures; and dynamic checksum enhancement: encrypting and storing key parameters of the checksum generation algorithm (such as hash salt values ​​of device hardware information) at compile time in the LLVM layer, and dynamically decrypting them at runtime, replacing the static parameter configuration of the original scheme.

[0253] Equivalent to the original solution, this solution uses "deep obfuscation at compile time + dynamic parameters" to resist reverse engineering tools such as IDA Pro and Frida, achieving the same protection effect as the original solution. The difference is that the original solution relies on manual obfuscation, while this solution automates the process, reducing maintenance costs.

[0254] For example, Solution 2, the hardware-level security isolation solution, is based on ARM Trust Zone, which deploys the core front-end logic in a hardware security environment.

[0255] For example, in Trust Zone deployment: the "encryption algorithm implementation, dynamic key generation, and verification string signature" modules are compiled into a Trusted Application (TA) and run in Trust Zone.

[0256] Insecure interaction: The normal logic of the front-end APP (such as UI display and voice collection) runs in an insecure world and interacts with the TA through security monitoring call instructions (such as when requesting the generation of a verification string, the parameters are passed in the insecure world → the TA processes them → and the encrypted result is returned).

[0257] Secure key storage: Sensitive information such as dynamic session keys and private keys are stored in a secure hardware storage area that cannot be accessed by the insecure world, replacing the original solution of temporary storage in memory.

[0258] Equivalent to the original solution, this solution achieves a higher level of reverse engineering resistance (resisting memory dumps and dynamic debugging) through "hardware isolation + secure interaction"; the difference is that the original solution relies on software protection, while this solution relies on hardware security capabilities.

[0259] In some embodiments, the above-mentioned "WSS+SRTP overlay encryption" can be replaced by the following scheme.

[0260] For example, Scheme 1, Datagram Transport Layer Security (DTLS) - SRTP overlay encryption scheme, uses DTLS to replace WSS to construct "DTLS+SRTP" overlay encryption.

[0261] For example, transport layer encryption: the front-end APP and the Web RTC server establish a DTLS connection via UDP, and negotiate the SRTP session key during the handshake phase (replacing the original WSS handshake + RSA encryption key).

[0262] Application layer encryption: The voice media stream is still encrypted with SRTP, DTLS ensures the security of key negotiation, and SRTP ensures the security of the media stream (replacing the original scheme of "WSS secure channel + SRTP secure data").

[0263] Weak network adaptation: DTLS supports packet retransmission (retransmission interval 500ms, up to 3 times), which is more suitable for weak network environments than WSS (based on TCP) (it can still maintain smooth call when the packet loss rate is ≤10%).

[0264] Equivalent to the original solution, this solution achieves the same superimposed encryption effect as the original solution through "DTLS + SRTP". The difference is that the original solution is suitable for TCP networks, while this solution is suitable for scenarios with high real-time requirements (such as voice calls and video conferencing).

[0265] For example, Scheme 2, the Quick UDP Internet Connections (QUIC) protocol transmission scheme, uses the QUIC protocol to replace WSS to achieve "QUIC+SRTP" superimposed encryption.

[0266] For example, protocol feature adaptation: QUIC is based on UDP, has built-in TLS 1.3 encryption (replacing the TLS layer of WSS), and supports 0-RTT handshake (first connection delay ≤100ms, reconnection delay ≤10ms).

[0267] Overlay encryption: The voice media stream is transmitted via QUIC, and each stream is independently encrypted with SRTP (replacing the original solution "WSS channel + SRTP"). QUIC ensures the security of the stream transmission, and SRTP ensures the security of the media stream content.

[0268] Permission binding: When establishing a QUIC connection, the front-end APP needs to carry "device identifier + temporary verification information". Only after the Web RTC server verifies the information can the QUIC stream be established (replacing the original Nginx permission verification solution).

[0269] Equivalent to the original solution, this solution achieves the same transmission security through "QUIC built-in encryption + SRTP" while improving adaptability to weak network conditions (supporting connection migration, such as not interrupting calls when a mobile phone switches from WiFi to 5G); the difference is that the original solution relies on traditional TCP / TLS, while this solution is suitable for mobile Internet scenarios.

[0270] In some embodiments, the overall technical solution of this application described above can be replaced by the following solutions.

[0271] For example, a decentralized solution of "consortium blockchain + P2P" can be built to replace the centralized architecture of the original solution.

[0272] For example, in identity management: user public keys and permission policies are stored on a consortium blockchain, and each node (enterprise / institution) has on-chain accounting permissions, replacing the original user database.

[0273] Authentication process: When the front-end APP initiates a call, it verifies the calling and called party permissions through a smart contract (contract logic: query on-chain user status → verify call permissions → return verification results), replacing the original solution of verification by the business side and the call platform.

[0274] Key exchange: Session keys are exchanged directly between the calling and called apps via a P2P encrypted channel (based on the ECDH algorithm). Only the key hash is recorded on the chain (for auditing), replacing the key management of the original Web RTC server.

[0275] Transmission security: Voice media streams are transmitted via P2P+SRTP, and the consortium blockchain records call summaries (caller and called party identifier hashes, call duration), replacing the original solution's cloud transmission and log storage.

[0276] Equivalent to the original solution, this solution achieves end-to-end secure calls through "on-chain identity + smart contract authentication + P2P encryption," resolving the single point of failure risk of the original solution's centralized architecture. The difference is that the original solution relies on a centralized server, while this solution is suitable for cross-institutional, decentralized scenarios (such as cross-bank voice customer service and government APP calls).

[0277] In this embodiment, the Web RTC server generates a unique session key in real time when each call session is established, without relying on a static key store, thus avoiding the risk of "long-term key exposure" in existing technologies. The generated session key is transmitted through two layers of encryption—first encrypted with the public keys of the calling and called users respectively, and then transmitted to the corresponding APP front-end via WSS, instead of the existing technology of "single encryption or plaintext key transmission". After the call ends, the WebRTC server immediately destroys the session key and deletes all temporary information related to the key in the cache, eliminating the security risks caused by "key reuse or residue".

[0278] Furthermore, the voice media stream transmission between the APP front-end and the Web RTC server does not use only WSS or SRTP encryption, but adopts "WSS (transport layer encryption) + SRTP (application layer media stream encryption)" superimposed encryption. WSS ensures the security of the transmission channel, while SRTP ensures the encryption and integrity of the voice data itself. In addition, before forwarding data, the Nginx service not only verifies the validity of the certificate, but also verifies the business permissions of the sender (front-end APP or back-end server) (e.g., whether the APP front-end is a legally registered terminal, and whether the back-end server has data forwarding permissions), rejecting transmission requests from unauthorized entities, and avoiding the problem of legitimate channels being illegally used due to the existing technology of "encrypting without verifying permissions".

[0279] Figure 12 This application provides a schematic diagram of the system architecture for a session creation system 800. The session creation system 800 may include: a front-end APP module 801, a back-end server 802, an Nginx server 803, a Web RTC server 804, a STUN server 805, a user database 806, and a caching module 807. The front-end APP module 801 includes a business request module 8011 and a certificate verification module 8012, and the Web RTC server 804 includes a Web RTC SDK module 8041.

[0280] Among them, the business request module 8011 is used to obtain session parameters, encrypt and generate signatures for the session parameters, and is applied to the relevant schemes of S601 to S603 mentioned above.

[0281] Certificate verification module 8012 is used to verify the session certificate of the Web RTC server.

[0282] Backend server 802 is used to transmit session requests. This is applied to the related solutions described above for S604.

[0283] The Nginx server is stuck on error 803, used for reverse proxying and verifying the certificates of the front-end application.

[0284] Web RTC SDK module 8041 is used for session management, key negotiation, dynamic session key generation, and code obfuscation. It is applied to step S202 and related solutions mentioned above.

[0285] STUN server 805 is used to obtain the session addresses of the calling and called devices. It is applied to step S203 and related solutions described above.

[0286] User database 806 is used to store user information and public keys. The relevant schemes are used in steps S202a and S202c above.

[0287] The cache module 807 is used to store temporary verification information and timeout stamps. It is applied to step S301 and related schemes mentioned above.

[0288] It should be noted that for a detailed explanation of the steps performed by each module and their beneficial effects, please refer to the description in the above embodiments, which will not be repeated here.

[0289] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0290] This application embodiment can divide the session creation device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0291] In some embodiments, this application also provides a session creation apparatus. The session creation apparatus may include one or more functional modules for implementing the session creation method of the above method embodiments.

[0292] For example, Figure 13 This is a schematic diagram illustrating the composition of a session creation apparatus provided in an embodiment of this application. Figure 13 As shown, the session creation device 900 includes a receiving module 901, a generating module 902, and a sending module 903.

[0293] The receiving module 901 is used to receive a first session request from the calling device, which requests the establishment of a first session between the calling device and the called device. The first session request carries first session parameters for establishing the first session. The generating module 902 is used to generate a first session key ciphertext corresponding to the calling device and a second session key ciphertext corresponding to the called device, provided the first session parameters pass verification. The sending module 903 is used to send the first session key ciphertext and the session address of the called device to the calling device via a first encrypted path, and to send a call request corresponding to the session request to the called device, thereby establishing a first session between the calling device and the called device; wherein the call request carries the second session key ciphertext and the session address of the calling device.

[0294] In the session creation device provided in this application, the session creation server generates a unique session key ciphertext in real time each time a network session is established, without relying on a static key store, thus avoiding the risk of "long-term exposure of the key". Moreover, the generated session key needs to be transmitted through two layers of encryption, that is, the session key is encrypted by the calling device and the called device respectively, and then the session key ciphertext is transmitted to the corresponding devices through the first encryption path, thereby improving the security of the session creation process.

[0295] In some embodiments, the generation module 902 is specifically used to: randomly generate a session key corresponding to the first session request when the first session parameters pass the verification; encrypt the session key based on the first encryption algorithm corresponding to the calling device to obtain the first session key ciphertext; and encrypt the session key based on the second encryption algorithm corresponding to the called device to obtain the second session key ciphertext.

[0296] In other embodiments, the first session parameters include: a first hash value, the first hash value corresponding to a first session identifier, a device identifier of the calling device, a device identifier of the called device, and a first timestamp when the first session request was generated; the session creation device 900 further includes a determining module. The determining module is configured to, before generating the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device, if the session parameters pass verification, determine that the session parameters pass verification if the duration between the first timestamp and the timestamp when the calling device initiates the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the stored device identifier of the calling device, and the device identifier of the called device is the same as the stored device identifier of the called device.

[0297] In some embodiments, the session creation apparatus 900 further includes a processing module; the receiving module 901 is further configured to receive a second session request from the calling device before receiving the first session request sent by the calling device to the called device. The second session request is used to request the establishment of a session between the calling device and the called device. The second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include: a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. The processing module is configured to decrypt the ciphertext based on the first private key corresponding to the first public key to obtain the session request construction parameters; and determine the session information corresponding to the calling device from the database based on the device identifier of the calling device in the session request construction parameters. The session information includes the device status of the calling device and the session permissions of the calling device. The aforementioned generation module 902 is further configured to, when the device is in a normal state and has session permissions for the called device, randomly generate a first session identifier, and generate a first session request based on the first session identifier, the device identifier of the calling device, the device identifier of the called device, and a third timestamp, wherein the third timestamp is the current timestamp. The aforementioned processing module is further configured to encrypt the first session request based on a third encryption algorithm; the aforementioned sending module is further configured to send the encrypted first session request to the calling device.

[0298] In some other embodiments, the session creation apparatus 900 further includes a processing module; the processing module is used to delete the first session key ciphertext, the second session key ciphertext, and the first session parameters after establishing a first session between the calling device and the called device, in the event that the first session has ended.

[0299] For example, Figure 14This is a schematic diagram illustrating the composition of another session creation apparatus provided in an embodiment of this application. For example... Figure 14 As shown, the session creation device 1000 includes: a generation module 1001, a sending module 1002, a receiving module 1003, and a processing module 1004.

[0300] The system comprises the following modules: Generation module 1001 generates a second session request, which carries ciphertext of session request construction parameters and a corresponding first public key. These parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. Sending module 1002 sends the second session request to a session creation server, requesting the establishment of a session between the calling and called devices. Receiving module 1003 receives an encrypted first session request from the session creation server, generated by the server based on the session request construction parameters. Processing module 1004 decrypts the first session request using a second private key corresponding to the second public key to obtain first session parameters. These parameters include a first hash value, which corresponds to the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated. The sending module is also used to send a first session request to the session creation server when the duration between the first timestamp and the second timestamp is less than or equal to a preset duration.

[0301] In the session creation device provided in this application, after receiving the first session request sent by the session creation server, the calling device can verify that the duration between the first timestamp and the second timestamp in the first session request is less than or equal to a preset duration, thereby determining to send the first session request to the session creation server. That is, by establishing a dynamic permission control mechanism based on a time window, the session key management mode is optimized, and the risk of session key exposure and permission abuse is reduced.

[0302] In some embodiments, the processing module 1004 is specifically used to verify the session certificate corresponding to the calling device. The sending module is specifically used to send a second session request to the session creation server if the session certificate verification passes.

[0303] It should be noted that the session creation device can implement all the processes implemented in the above method embodiments and achieve the same beneficial effects. To avoid repetition, it will not be described again here.

[0304] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 15As shown, the electronic device 90 includes: a processor 92, a communication interface 93, and a bus 94. Optionally, the electronic device 90 may also include a memory 91.

[0305] Processor 92 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 92 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0306] Communication interface 93 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0307] The memory 91 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0308] As one possible implementation, the memory 91 can exist independently of the processor 92. The memory 91 can be connected to the processor 92 via a bus 94 and is used to store instructions or program code. When the processor 92 calls and executes the instructions or program code stored in the memory 91, it can implement the session creation method provided in the embodiments of this application.

[0309] In another possible implementation, memory 91 can also be integrated with processor 92.

[0310] Bus 94 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 94 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 15 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0311] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0312] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the aforementioned computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The aforementioned computer-readable storage medium can also be an external storage device of the aforementioned service invocation device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the aforementioned service invocation device. Further, the aforementioned computer-readable storage medium can include both internal storage units of the aforementioned service invocation device and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the aforementioned service invocation device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0313] This application also provides a computer program product comprising a computer program that, when run on a computer, causes the computer to execute any of the session creation methods provided in the above embodiments.

[0314] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A session creation method, characterized by, Applied to session creation servers, including: Receive a first session request from the calling device, the first session request is used to request the establishment of a first session between the calling device and the called device, the first session request carries first session parameters for establishing the first session; If the first session parameter passes the verification, a first session key ciphertext corresponding to the calling device is generated, and a second session key ciphertext corresponding to the called device is generated. The first session key ciphertext and the session address of the called device are sent to the calling device via the first encryption path, and a call request corresponding to the session request is sent to the called device to establish a first session between the calling device and the called device. The call request carries the second session key ciphertext and the session address of the calling device.

2. The session creation method of claim 1, wherein, The step of generating a first session key ciphertext corresponding to the calling device and a second session key ciphertext corresponding to the called device, when the first session parameters pass verification, includes: If the first session parameter passes the verification, a session key corresponding to the first session request is randomly generated. Based on the first encryption algorithm corresponding to the calling device, the session key is encrypted to obtain the first session key ciphertext. The session key is encrypted using the second encryption algorithm corresponding to the called device to obtain the second session key ciphertext.

3. The session creation method according to claim 1 or 2, characterized in that, The first session parameters include: a first hash value, which corresponds to a first session identifier corresponding to the first session request, a device identifier of the calling device, a device identifier of the called device, and a first timestamp when the first session request was generated; before generating the first session key ciphertext corresponding to the calling device and the second session key ciphertext corresponding to the called device when the session parameters pass verification, the method further includes: If the duration between the first timestamp and the timestamp when the calling device initiates the session request is less than or equal to a preset duration, and the first session identifier is the same as the first session identifier stored in the calling device, the device identifier of the calling device is the same as the stored device identifier of the calling device, and the device identifier of the called device is the same as the stored device identifier of the called device, then the first session parameter is determined to pass the verification.

4. The session creation method according to claim 1, characterized in that, Before receiving the first session request sent by the calling device to the called device, the method further includes: A second session request is received from the calling device. The second session request is used to request the establishment of a session between the calling device and the called device. The second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include: a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. Based on the first private key corresponding to the first public key, the ciphertext is decrypted to obtain the session request construction parameters; Based on the device identifier of the calling device in the session request construction parameters, the session information corresponding to the calling device is determined from the database. The session information includes the device status of the calling device and the session permissions of the calling device. When the device is in a normal state and has session permissions for the called device, the first session identifier is randomly generated, and the first session request is generated based on the first session identifier, the device identifier of the calling device, the device identifier of the called device, and the third timestamp, where the third timestamp is the current timestamp. The first session request is encrypted using a third encryption algorithm, and the encrypted first session request is sent to the calling device.

5. The session creation method according to claim 1, characterized in that, After establishing the first session between the calling device and the called device, the method further includes: If the first session is detected to have ended, delete the first session key ciphertext, the second session key ciphertext, and the first session parameters.

6. A session creation method, characterized in that, Applied to calling devices, including: A second session request is generated, which carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. Send the second session request to the session creation server. The second session request is used to request the establishment of a session between the calling device and the called device. Receive an encrypted first session request sent by the session creation server, wherein the first session request is generated by the session creation server based on the session request construction parameters; Based on the second private key corresponding to the second public key, the first session request is decrypted to obtain the first session parameters. The first session parameters include: a first hash value, which corresponds to the first session identifier corresponding to the first session request, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated. If the duration between the first timestamp and the second timestamp is less than or equal to a preset duration, the first session request is sent to the session creation server.

7. The session creation method according to claim 6, characterized in that, Sending the second session request to the session creation server includes: The session certificate corresponding to the calling device is verified, and if the session certificate verification passes, the second session request is sent to the session creation server.

8. A session creation apparatus, characterized in that, It is used in session creation servers and includes: a receiving module, a generating module, and a sending module; The receiving module is used to receive a first session request from the calling device. The first session request is used to request the establishment of a first session between the calling device and the called device. The first session request carries first session parameters for establishing the first session. The generation module is used to generate a first session key ciphertext corresponding to the calling device and a second session key ciphertext corresponding to the called device, provided that the first session parameters pass the verification. The sending module is used to send the first session key ciphertext and the session address of the called device to the calling device through a first encrypted path, and to send a call request corresponding to the session request to the called device, so as to establish a first session between the calling device and the called device. The call request carries the second session key ciphertext and the session address of the calling device.

9. A session creation apparatus, characterized in that, Applied to calling device, it includes: generation module, transmission module, receiving module and processing module; The generation module is used to generate a second session request. The second session request carries ciphertext of session request construction parameters and a first public key corresponding to the ciphertext. The session request construction parameters include a session identifier corresponding to the second session request, a device identifier of the calling device, a device identifier of the called device, and a second timestamp when the second session request was generated. The sending module is used to send the second session request to the session creation server, the second session request being used to request the establishment of a session between the calling device and the called device; The receiving module is used to receive the encrypted first session request sent by the session creation server, wherein the first session request is generated by the session creation server based on the session request construction parameters; The processing module is used to decrypt the first session request based on the second private key corresponding to the second public key to obtain the first session parameters. The first session parameters include: a first hash value, which corresponds to the first session identifier corresponding to the first session request, the device identifier of the calling device, the device identifier of the called device, and the first timestamp when the first session request was generated. The sending module is further configured to send the first session request to the session creation server when the duration between the first timestamp and the second timestamp is less than or equal to a preset duration.

10. An electronic device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the session creation method as described in any one of claims 1 to 5 or the session creation method as described in claim 6 or 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the session creation method of any one of claims 1 to 5 or to implement the session creation method of claim 6 or 7.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the session creation method as described in any one of claims 1 to 5 or to implement the session creation method as described in claim 6 or 7.

Images