Information interaction method and device and storage medium
By interacting with security verification information between devices, evaluating device credibility and providing authorization, the problems of low trust level and untrustworthy information between devices are solved, and high security and reliability information interaction is achieved.
Patent Information
- Application Number
- CN202310799148.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-30
- Publication Date
- 2024-12-31
AI Technical Summary
The prior art cannot effectively ensure security in information interaction between devices, especially when one device is in an unsafe state, the trust level is low and long-term security cannot be guaranteed, resulting in untrustworthy information.
By sending and receiving security verification information, we evaluate whether the device is a trusted device and provide authorization after mutual trust, ensuring the security and reliability of information interaction.
It improves the security and trustworthiness level between devices, ensures the security and reliability of information interaction, maintains a high level of trust level, and prevents tampering and replay attacks.
Smart Images

Figure CN119232386A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of communications, and in particular to an information interaction method and device, and a storage medium. Background Art
[0002] Currently, if a device wants to access another device, the other device can use a key for verification, thereby ensuring the security of the device requesting access to a certain extent. However, the above process has the following problems:
[0003] Question 1: The level of mutual trust between the two interacting parties is at a low level.
[0004] For example, if one party's device has been hacked and is in an unsafe state, the other party should be informed that their device is in an unsafe state. However, the information sent in this case may be tampered with, which makes the information obtained by the other party unreliable.
[0005] Question 2: Using a key for verification can only confirm the security of the other party's device at this moment, but cannot guarantee that the other party's device is always in a secure state.
[0006] The above process cannot provide a sufficiently reliable security status. Summary of the invention
[0007] In view of this, the present application discloses an information interaction, information sending method and device, and a storage medium.
[0008] According to a first aspect of an embodiment of the present disclosure, there is provided an information interaction method, the method comprising:
[0009] In response to the need to send an authorization request message to a second device, first security verification information is sent to the second device, where the first security verification information is used by the second device to evaluate whether the first device is a trusted device;
[0010] Based on the second security verification information sent by the second device, evaluating whether the second device is a trusted device;
[0011] After determining that the second device and the first device trust each other, obtaining an authorization message sent by the second device based on the authorization request message, wherein the authorization message is used to authorize the first device to access the second device;
[0012] An access request message is sent to the second device based on the authorization information to request access to information on the second device.
[0013] According to a second aspect of an embodiment of the present disclosure, there is provided an information interaction method, including:
[0014] Based on the first security verification information sent by the first device, evaluating whether the first device is a trusted device;
[0015] Sending second security verification information to the first device, where the second security verification information is used by the first device to evaluate whether the second device is a trusted device;
[0016] After determining that the first device and the first device are mutually trusted, sending an authorization pass message to the first device, where the authorization pass message is used to authorize the first device to access the second device;
[0017] Based on the access request message sent by the first device, provide the first device with information that the first device requests access.
[0018] According to a third aspect of an embodiment of the present disclosure, there is provided an information interaction device, the device comprising:
[0019] A first sending module, configured to send first security verification information to a second device in response to a need to send an authorization request message to the second device, wherein the first security verification information is used by the second device to evaluate whether the first device is a trusted device;
[0020] A first evaluation module, configured to evaluate whether the second device is a trusted device based on the second security verification information sent by the second device;
[0021] an acquisition module, configured to, after determining that the first device and the second device trust each other, acquire an authorization message sent by the second device based on the authorization request message, wherein the authorization message is used to authorize the first device to access the second device;
[0022] The second sending module is configured to send an access request message to the second device based on the authorization information to request access to information on the second device.
[0023] According to a fourth aspect of an embodiment of the present disclosure, there is provided an information interaction device, the device comprising:
[0024] A second evaluation module, configured to evaluate whether the first device is a trusted device based on the first security verification information sent by the first device;
[0025] A third sending module, configured to send second security verification information to the first device, where the second security verification information is used by the first device to evaluate whether the second device is a trusted device;
[0026] A fourth sending module, configured to send an authorization pass message to the first device after determining that the first device and the first device trust each other, wherein the authorization pass message is used to authorize the first device to access the second device;
[0027] An execution module is used to provide the first device with information that the first device requests access based on the access request message sent by the first device.
[0028] According to a fifth aspect of an embodiment of the present disclosure, there is provided a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the above-mentioned information interaction methods are implemented.
[0029] According to a sixth aspect of an embodiment of the present disclosure, there is provided an information interaction system, including:
[0030] A first device that initiates access, the first device being used to execute the information interaction method described in any one of the first aspects above;
[0031] The accessed second device is used to execute the information interaction method described in any one of the second aspects above.
[0032] According to a seventh aspect of an embodiment of the present disclosure, there is provided an information interaction device, including:
[0033] processor;
[0034] a memory for storing processor-executable instructions;
[0035] The processor is configured to execute the executable instructions to implement the steps of any of the above-mentioned information interaction methods.
[0036] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects:
[0037] In the present disclosure, devices can exchange security verification information to verify whether the other device is a trusted device. After the devices trust each other, the device requested for access sends authorization information to the device that initiates the access request message, thereby improving the trust level of the security status between devices, keeping the trust level of both devices at a higher level, and ensuring the security and reliability of information exchange across smart devices.
[0038] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.
[0040] Figure 1A is a flowchart of an information interaction method according to an exemplary embodiment of the present disclosure;
[0041] Figure 1B is a flowchart of another information interaction method according to an exemplary embodiment of the present disclosure;
[0042] Figure 2 is a flowchart of another information interaction method according to an exemplary embodiment of the present disclosure;
[0043] Figure 3 is a flowchart of another information interaction method according to an exemplary embodiment of the present disclosure;
[0044] Figure 4 is a flowchart of another information interaction method according to an exemplary embodiment of the present disclosure;
[0045] Figure 5 is a flowchart of another information interaction method according to an exemplary embodiment of the present disclosure;
[0046] FIG. 6A to FIG. 6C is a flowchart of an information interaction method according to an exemplary embodiment of the present disclosure;
[0047] FIG. 7A to FIG. 7B is a flowchart of an information interaction method according to an exemplary embodiment of the present disclosure;
[0048] Figure 8 is a block diagram of an information interaction device according to an exemplary embodiment of the present disclosure;
[0049] Fig. 9 is a block diagram of another information interaction device according to an exemplary embodiment of the present disclosure;
[0050] Fig.10 It is a structural schematic diagram of an information interaction device shown in the present disclosure according to an exemplary embodiment. DETAILED DESCRIPTION
[0051] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Instead, they are merely examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.
[0052] Before introducing the solutions provided by the present disclosure, the nouns or terms involved in the present disclosure are first introduced.
[0053] The first device (also called the requesting device) is a device that sends an interconnection request and is connected to the accessed device.
[0054] The second device (also referred to as the accessed device) is a device that receives the interconnection request and is connected to the requesting device.
[0055] Challenge value: generated by a random number and used to prevent replay attacks.
[0056] Replay attack: also known as replay attack or playback attack, refers to an attacker sending a packet that has been received by the destination host to deceive the system. It is mainly used in the identity authentication process to destroy the correctness of the authentication.
[0057] Trusted status information: device status information used to prevent attackers from tampering with device information, including but not limited to the device's root user, number of flashes, device security status, etc.
[0058] Profile information (action_info): information collected by the accessed device and used to profile the behavior of the requesting device.
[0059] Device root certificate: A unique certificate for each device stored in a trusted environment, used to ensure the integrity of information when interacting between devices and to sign the transmitted information.
[0060] The reason why authorization is required between devices is to ensure that the operation of the "requesting device" is permitted by the "accessed device", thereby ensuring that the usage rights of the "accessed device" are within the scope of the user's permission.
[0061] Authorization actions often occur during connection matching, data transmission, and function invocation. For example, the "requesting device" needs user authorization to apply for connection with the "accessed device"; the "requesting device" needs user authorization to apply for access to some data on the "accessed device", such as pictures and text messages; the "requesting device" needs user authorization to apply for calling some functions on the "accessed device", such as payment, camera, games, etc.
[0062] When authorizing, the "requesting device" needs to provide its own security status, and use cryptographic algorithms to ensure that it is not eavesdropped or tampered with in the transmission channel. Let the "accessed device" trust the "requesting device" to provide authorization.
[0063] However, the "accessed device" cannot permanently trust the "requesting device", so the authorization needs to have a certain validity period, and different authorization times are required for different application scenarios. The authorization time is evaluated based on the degree of reliance on security. For example, the payment function may require authorization for each call, access to pictures may require authorization at fixed intervals, and viewing the clock may not require authorization or may only require authorization once.
[0064] In the embodiments of the present disclosure, refer to Figure 1A As shown, a schematic diagram of the information interaction process is provided, wherein the first device may be a device that initiates an access request message, which may be Figure 1A Request a device in the
[0065] The second device may be a device requested to be accessed, which may be Figure 1A Accessed Devices.
[0066] The requesting device may send an authorization request message to the requested device, wherein the message includes first security verification information, and the first security verification information is used by the accessed device to evaluate whether the requesting device is a trusted device.
[0067] The accessed device may send second security verification information to the requesting device so that the requesting device can evaluate whether the accessed device is a trusted device.
[0068] After the two devices trust each other, the requesting device obtains the authorization pass message sent by the accessed device based on the authorization request message, thereby sending an access request message to the accessed device to request access to information on the accessed device.
[0069] In the above embodiments, the security and trustworthiness level between devices is improved, so that the trust level of the devices of both parties is at a higher level, thereby ensuring the security and reliability of information interaction across smart devices.
[0070] In the embodiments of the present disclosure, refer to Figure 1B As shown, a flowchart of information interaction is provided. After the accessed device is authorized, the two devices still need to maintain a state of suspicion. Once the accessed device believes that the credibility of the requesting device is reduced, the requesting device needs to initiate an authorization request message again.
[0071] In the above embodiment, the trust level of the security status between devices is improved, so that the trust level of the devices of both parties is at a higher level, ensuring the security and reliability of information interaction across smart devices.
[0072] The following first introduces the information interaction method provided by the present disclosure from the first device side.
[0073] Reference Figure 2As shown, Figure 2 This is a flow chart of an information interaction method shown in an exemplary embodiment of the present disclosure. This embodiment is described from the perspective of the first device. The first device is a device that initiates an access request message, and may include but is not limited to a mobile phone, a laptop computer, a desktop computer, and a tablet computer. Figure 2 As shown, the information interaction method may include the following steps:
[0074] In step 201, in response to the need to send an authorization request message to a second device, first security verification information is sent to the second device.
[0075] In an embodiment of the present disclosure, when a first device receives an access request message initiated by a user, requesting access to a second device, the first device determines that an authorization request message needs to be sent to the second device.
[0076] In the embodiment of the present disclosure, the first security verification information is used by the second device to evaluate whether the first device is a trusted device.
[0077] In one example, the first device and the second device need to perform signature verification on each other first, and then generate the first security verification information when both signature verifications pass.
[0078] Exemplarily, the first device may send first signature information to be verified to the second device, where the first signature information is used by the second device to perform signature verification on the first device to obtain a first signature verification result.
[0079] The first signature-to-be-verified information includes: a first challenge value randomly generated by the first device; and the first challenge value signed by the first device.
[0080] Exemplarily, the first device signs the randomly generated first challenge value based on its own root certificate to obtain the first challenge value signed by the first device.
[0081] In addition, the first device may perform signature verification on the second device based on the second signature verification information sent by the second device to obtain a second signature verification result.
[0082] The second information to be verified includes: a second challenge value randomly generated by the second device; and the second challenge value signed by the second device.
[0083] Exemplarily, the second device signs the randomly generated second challenge value based on its own root certificate to obtain the second challenge value signed by the second device.
[0084] The signature verification process of the second device may include: decrypting the second challenge value signed by the second device based on the public key of the second device to obtain the second challenge value therein; if the decrypted second challenge value is completely consistent with the second challenge value sent by the second device, then the second signature verification result is determined to be passed, that is, the second challenge value has not been tampered with.
[0085] Further, when the first signature verification result obtained by the second device is also passed, that is, the first challenge value randomly generated by the first device has not been tampered with, the first device can generate the first security verification information.
[0086] Exemplarily, the first device combines the second challenge value with the first trusted state information of the first device to obtain the first security verification information, wherein the first trusted state information includes but is not limited to the root of the first device, the number of flashing times, the security state of the first device, etc.
[0087] Furthermore, the first device sends the generated first security verification information to the second device.
[0088] In one example, in order to improve the security of the first security verification information, the first security verification information may be signed again based on the root certificate of the first device, and the first security verification information and the signed first security verification information are sent to the second device.
[0089] In step 202, based on the second security verification information sent by the second device, it is evaluated whether the second device is a trusted device.
[0090] In the embodiment of the present disclosure, the execution order of the above steps 201 and 202 is not limited.
[0091] In the embodiment of the present disclosure, the process of the second device generating the second security verification information is similar to the process of the first device generating the first security verification information in step 201, and will not be repeated here.
[0092] The second security verification information includes a first challenge value and second trusted state information of the second device.
[0093] The second trusted status information includes but is not limited to the root of the second device, the number of flashing times, the security status of the second device, etc.
[0094] The first device may compare the first challenge value included in the second security verification information with the first challenge value randomly generated by the first device before, so as to determine whether there is a replay attack. If the two first challenge values are completely consistent, it is determined that there is no replay attack. If the two challenge values are inconsistent, it is determined that there is a replay attack.
[0095] If it is determined that a replay attack exists, the first device may stop the authorization request process.
[0096] In one example, if there is no replay attack, the first device can send the second trusted state information of the second device to the first application on the first device, where the first application is the application on the first device requesting access to the second device, and the first application evaluates whether the second device is a trusted device based on the second trusted state information.
[0097] Exemplarily, the first application considers that the root of the second device has not been changed, and determines that the second device is a trusted device.
[0098] Exemplarily, the first application considers that the number of times the second device has been flashed is less than or equal to a preset number, and determines that the second device is a trusted device.
[0099] Exemplarily, the first application considers that the security status of the second device is reliable and determines that the second device is a trusted device.
[0100] Exemplarily, the first application determines that the root of the second device is changed, the number of flashing times is greater than a preset number, and / or the security status of the second device is unreliable, and determines that the second device is not a trusted device.
[0101] In the embodiment of the present disclosure, the second device evaluates whether the first device is a trusted device in a similar manner.
[0102] In one example, what the first device receives is the second security verification information and the second security verification information signed by the second device based on its own root certificate.
[0103] The first device first performs signature verification to determine that the second security verification information has not been altered, and then evaluates whether the second device is a trusted device based on the second security verification information.
[0104] Exemplarily, the first device can decrypt the second security verification information signed by the second device based on the public key of the second device. If the decrypted second security verification information is consistent with the second security verification information sent by the second device, it is determined that the signature verification is successful, that is, the second security verification information has not been changed.
[0105] In step 203, after determining that the second device and the second device have mutual trust, an authorization pass message sent by the second device based on the authorization request message is obtained.
[0106] In the embodiment of the present disclosure, the first device determines that the second device is a trusted device after evaluation, and the second device determines that the first device is a trusted device after evaluation. At this time, the first device can obtain the authorization pass message sent by the second device.
[0107] In the embodiment of the present disclosure, the authorization pass message is used to authorize the first device to access the second device.
[0108] In step 204, an access request message is sent to the second device based on the authorization information to request access to information on the second device.
[0109] Exemplarily, the access request message may request access to pictures, files, other data information, etc. on the second device.
[0110] In the above embodiment, devices can exchange security verification information to verify whether the other device is a trusted device. After the devices trust each other, the device requested for access sends authorization information to the device that initiates the access request message, thereby improving the trust level of the security status between devices and maintaining a high level of trust between the devices, thereby ensuring the security and reliability of information exchange across smart devices.
[0111] In some optional embodiments, reference Figure 3 As shown, Figure 3 This disclosure Figure 2 The embodiment shown is a flow chart of an information interaction method, and the information interaction method may also include the following steps:
[0112] In step 205, indication information sent by the second device is received.
[0113] In the disclosed embodiment, during the access process of the first device, the second device continuously profiles the behavior of the first device, determines whether the current behavior of the first device matches the profile result, and obtains the matching result for evaluating the matching degree between the current behavior and the profile result. When the matching degree is lower than the preset matching degree, the second device considers that the credibility of the first device has decreased, and at this time, the second device sends an instruction message to the first device, instructing the first device to re-acquire the authorization of the second device.
[0114] Accordingly, after receiving the indication information, the first device may return to execute the above steps 201 to 204 to re-acquire the authorization of the second device so as to continue to access the information on the second device.
[0115] In the above embodiment, the purpose of continuous verification can be achieved between devices, that is, the device requested to access continues to be suspicious of the requesting device, and once it is determined that the credibility of the requesting device has decreased, the requesting device can be required to obtain authorization again, thereby improving the security and reliability of information interaction across smart devices.
[0116] The following first introduces the information interaction method provided by the present disclosure from the second device side.
[0117] Reference Figure 4 As shown, Figure 4 1 is a flow chart of an information interaction method shown in an exemplary embodiment of the present disclosure. This embodiment is described from the perspective of the second device side. The second device is the device requested to be accessed, and may include but is not limited to a mobile phone, a laptop computer, a desktop computer, a tablet computer, etc. Figure 4 As shown, the information interaction method may include the following steps:
[0118] In step 401, based on first security verification information sent by a first device, it is evaluated whether the first device is a trusted device.
[0119] In the embodiment of the present disclosure, the first security verification information is used by the second device to evaluate whether the first device is a trusted device.
[0120] In one example, the second device and the first device need to perform signature verification on each other first, and if both signature verifications pass, then it is evaluated whether the first device is a trusted device.
[0121] Exemplarily, the second device may send second signature information to be verified to the first device, where the second signature information is used by the first device to perform signature verification on the second device to obtain a second signature verification result.
[0122] The second information to be verified includes: a second challenge value randomly generated by the second device; and the second challenge value signed by the second device.
[0123] Exemplarily, the second device signs the randomly generated second challenge value based on its own root certificate to obtain the second challenge value signed by the second device.
[0124] The process of the first device determining the second signature verification result has been introduced on the first device side and will not be repeated here.
[0125] In addition, the second device may perform signature verification on the first device based on the first signature verification information sent by the first device to obtain a first signature verification result.
[0126] The first signature-to-be-verified information includes: a first challenge value randomly generated by the first device; and the first challenge value signed by the first device.
[0127] Exemplarily, the first device signs the randomly generated first challenge value based on its own root certificate to obtain the first challenge value signed by the first device.
[0128] The signature verification process of the first device may include: decrypting the first challenge value signed by the first device based on the public key of the first device to obtain the first challenge value therein; if the decrypted first challenge value is completely consistent with the first challenge value sent by the first device, then determining that the first signature verification result is passed, that is, the first challenge value has not been tampered with.
[0129] Furthermore, when the second signature verification result obtained by the first device is also passed, that is, the second challenge value randomly generated by the second device has not been tampered with, the second device can evaluate whether the first device is a trusted device based on the first security verification information sent by the first device.
[0130] The first security verification information includes: a second challenge value; and first trusted state information of the first device.
[0131] Exemplarily, the second device may send the first trusted state information to a second application on the second device, and the second application evaluates whether the first device is a trusted device based on the first trusted state information, and the second application is the application requested to access.
[0132] The way in which the second device evaluates whether the first device is a trusted device is similar to the way in which the first device evaluates whether the second device is a trusted device, which will not be described in detail here.
[0133] In one example, the first device sends the first security verification information and the first security verification information signed by the first device.
[0134] The second device can decrypt the first security verification information signed by the first device based on the public key of the first device. If the decrypted first security verification information is consistent with the first security verification information sent by the first device, it is determined that the first security verification information has not been changed. The second device can evaluate whether the first device is a trusted device based on the first security verification information.
[0135] In step 402, second security verification information is sent to the first device.
[0136] In the embodiment of the present disclosure, the execution order of step 401 and step 402 is not limited.
[0137] In the embodiment of the present disclosure, the second security verification information is used by the first device to evaluate whether the second device is a trusted device.
[0138] In the embodiment of the present disclosure, the second device may combine the first challenge value with the second trusted state information of the second device to obtain the second security verification information.
[0139] The second trusted status information includes but is not limited to the root of the second device, the number of flashing times, the security status of the second device, etc.
[0140] Furthermore, the second device sends the generated second security verification information to the first device so that the first device can evaluate whether the second device is a trusted device.
[0141] In one example, in order to improve the security of the second security verification information, the second security verification information may be signed again based on the root certificate of the second device, and the second security verification information and the signed second security verification information are sent to the first device.
[0142] In step 403, after mutual trust between the first device and the first device is determined, an authorization approval message is sent to the first device.
[0143] In the embodiment of the present disclosure, the second device determines that the first device is a trusted device after evaluation, and the first device determines that the second device is a trusted device after evaluation. At this time, the second device can send an authorization pass message to the first device.
[0144] In the embodiment of the present disclosure, the authorization pass message is used to authorize the first device to access the second device.
[0145] In step 404, based on the access request message sent by the first device, information that the first device requests access is provided to the first device.
[0146] Exemplarily, the access request message may request access to pictures, files, other data information, etc. on the second device.
[0147] In the above embodiment, devices can exchange security verification information to verify whether the other device is a trusted device. After the devices trust each other, the device requested for access sends authorization information to the device that initiates the access request message, thereby improving the trust level of the security status between devices and maintaining a high level of trust between the devices, thereby ensuring the security and reliability of information exchange across smart devices.
[0148] In some optional embodiments, reference Figure 5 As shown, Figure 5 This disclosure Figure 4 The embodiment shown is a flow chart of an information interaction method, and the information interaction method may also include the following steps:
[0149] In step 405, portrait information of the first device is collected, and the portrait information is used to create a portrait of the user of the first device.
[0150] In the disclosed embodiment, the second device may continuously collect the portrait information of the first device, including but not limited to the clicking habits and usage habits of the user of the first device.
[0151] In step 406, based on the portrait information, a portrait of the user of the first device is generated to obtain a user portrait result.
[0152] In the disclosed embodiment, Internet user sample portrait information can be collected, and the initial neural network can be trained to obtain a neural network for user portrait. The neural network can then be used as a portrait drawing engine to draw portraits for users.
[0153] After the above-mentioned portrait information is collected, it can be input into the neural network to obtain the user portrait result output by the neural network. The portrait result can represent the user characteristics such as the user's usage habits and clicking habits of the first device.
[0154] In step 407, the current user behavior of the first device is determined based on the access request message currently sent by the first device.
[0155] In the embodiment of the present disclosure, the current user behavior of the first device can be obtained through a separate user behavior analysis model.
[0156] In step 408, the current behavior is matched with the user portrait result to obtain a matching result, and the matching result is used to evaluate the matching degree between the current behavior and the portrait result.
[0157] In one example, the matching degree may be represented by a score, wherein the higher the score, the higher the matching degree.
[0158] In step 409, when the matching degree is lower than a preset matching degree, indication information is sent to the first device, where the indication information is used to instruct the first device to re-acquire authorization of the second device.
[0159] In one example, a preset matching degree as a threshold may be set in advance for different services. When the matching degree is lower than the preset matching degree, the first device needs to be triggered to re-acquire authorization from the second device.
[0160] Exemplarily, the services and the corresponding preset matching degrees are shown in Table 1.
[0161] Table 1
[0162] business Corresponding preset matching degree Password payment 80 Photo album browsing 60 Web browsing 60 …… ……
[0163] It is understandable that the preset matching degree can be set flexibly.
[0164] For example, when the second device determines that the matching degree of password payment is higher than 80 points, the first device can be allowed to access normally. If the matching degree is lower than 80 points, the first device needs to obtain authorization again.
[0165] In an example, if the matching degree is too low, the first device may be prohibited from accessing the application corresponding to the second device. Table 1 is further expanded to obtain Table 2.
[0166] Table 2
[0167] business Corresponding preset matching degree Access matching is prohibited Password payment 80 60 Photo album browsing 60 20 Web browsing 60 0 …… …… ……
[0168] For example, when the second device determines that the password payment match is higher than 80 points, it can allow the first device to access normally. If the match is between 60 and 80 points, the first device needs to obtain authorization again. If the match is lower than 60 points, the second device will no longer allow the first device to access the password payment application.
[0169] In the above embodiment, the purpose of continuous verification can be achieved between devices, that is, the device requested to access continues to be suspicious of the requesting device, and once it is determined that the credibility of the requesting device has decreased, the requesting device can be required to obtain authorization again, thereby improving the security and reliability of information interaction across smart devices.
[0170] The above process is further illustrated below with examples.
[0171] Embodiment 1, the initial authorization stage between the first device and the second device.
[0172] When calling connection matching, data transmission, function calling and other functions for the first time, the trusted status information of both devices is obtained to improve the mutual trust level between the two parties.
[0173] Initial authorization phase process, for example Fig. 6A shown.
[0174] First, generate a challenge value.
[0175] The challenge value is generated for each authorization and is provided to the other party, which uses it to generate trusted status information to prevent replay attacks.
[0176] For example Figure 6B As shown, the user requests to access the second device through the first device, and the first device generates a first challenge value of fixed length, assuming it is challenge1, and signs it with the root certificate of the first device. The first challenge value signed by the first device is challenge1_sign. Challenge1 and challenge1_sign are sent to the second device as the first signature information to be verified.
[0177] The second device obtains challenge1 and challenge1_sign to perform signature verification. If the signature verification passes, it means that challenge1 has not been tampered with. If it has been tampered with, the authorization is rejected.
[0178] If challenge1 has not been tampered with, the second device will generate a second challenge value of fixed length, assuming it is challenge2, and sign it with the root certificate of the second device. The second challenge value signed by the second device is challenge2_sign. Challenge2 and challenge2_sign are sent to the first device as the second signature information to be verified. And challenge1 is used to generate the second security verification information trust_state_info2.
[0179] The first device obtains challenge2 and challenge2_sign to verify the signature. If the signature verification passes, it means that challenge2 has not been tampered with. If it has been tampered with, the request is stopped.
[0180] If challenge2 has not been tampered with, challenge2 is used to generate the first security verification information trust_state_info1.
[0181] Secondly, generate security verification information trust_state_info.
[0182] Relying on the device trusted status system, a higher level of trustworthy device status information is generated to improve the level of mutual trust between the two parties.
[0183] For example Figure 6C As shown, after obtaining the first challenge value challenge1 of the first device, the second device combines challenge1 with its own second trusted state information to obtain second security verification information trust_state_info2, and signs it with the root certificate of the second device, with the signature value trust_state_info2_sign. Trust_state_info2 and trust_state_info2_sign are sent together to the first device.
[0184] The first device obtains trust_state_info2 and verifies the signature with trust_state_info2_sign. If the signature verification is successful, it means that trust_state_info2 has not been tampered with. If it has been tampered with, the request is stopped.
[0185] Compare challenge1 in trust_state_info2 with challenge1 sent by the first device to see if they are consistent. If they are consistent, it means that there has been no replay attack. If they are inconsistent, it means that there has been a replay attack, and the request is stopped.
[0186] If it has not been tampered with and has not been replayed, trust_state_info2 is used to evaluate the second device.
[0187] Similarly, after obtaining the challengeg1 of the second device, the first device will also generate trust_state_info1 and trust_state_info1_sign, and send them to the second device for evaluation. The specific content is basically symmetrical with the process in the above figure and will not be repeated here.
[0188] Again, evaluate the other party's equipment.
[0189] Based on the trusted status information provided by the other party's device, the security of the other party's device at the moment is evaluated. Different businesses make risk judgments based on their own needs.
[0190] The first device obtains the second security verification information trust_state_info2 of the second device, and provides the information to a specific business application, such as a first application, and the first application determines whether the second device is a trusted device.
[0191] The second device obtains the first security verification information trust_state_info1 of the first device, and provides the information to a specific business application, such as a second application program, and the second application program determines whether the first device is a trusted device.
[0192] If both parties trust each other, the second device sends an authorization approval message to the first device.
[0193] Embodiment 2, continuous authorization stage.
[0194] After the first device has obtained authorization for the first time, in order to continue to "doubt" the security of the other party's device, it is necessary to detect abnormalities and interrupt them in the shortest possible time.
[0195] For example Fig. 7A As shown, first, information collection is performed.
[0196] Collect information for subsequent data profiling.
[0197] When the first device obtains authorization and starts to access the second device normally, the second device starts to continuously collect the portrait information action_info. The portrait information action_info is not retained here and is directly passed to the portrait drawing layer.
[0198] Among them, drawing portraits
[0199] Draw a user portrait of the first device, where the user portrait result can represent the user's behavior habits and be used for decision-making.
[0200] The portrait information action_info is passed to the portrait drawing layer. According to the specific data of the portrait information action_info, the user portrait result is formed through the drawing engine, so that the user portrait result has the characteristics of representing the user's usage habits.
[0201] The rendering engine calculates the model based on the capabilities of machine learning, intelligently analyzes user behavior patterns, classifies user behavior, and presents user portraits.
[0202] Again, calculated risks.
[0203] Continue to judge the matching degree between the current user behavior of the first device and the user portrait result, and make risk judgments based on different businesses.
[0204] For example Figure 7B As shown, the user's current portrait information action_info and the user portrait result are passed to the decision engine for indicator calculation, the matching degree is calculated, and a matching score is obtained (assuming that 100 points can be the full score), which is used to represent the matching degree between the user who accesses the second device through the first device at this moment and the user before this moment. The matching score can provide a basis for identity authentication.
[0205] The decision engine calculates the model based on the ability of machine learning, distinguishes the user's regular behavior from the information action_info at the moment, and obtains a matching score.
[0206] The matching score and business requirements are passed to the risk judgment module. If it is judged that there is a risk, a decision is made in the shortest possible time, such as interrupting the service, requesting re-authorization, etc.
[0207] Business requirements refer to the requirements of different businesses for matching scores and the content of judgment and decision making, which are set by different businesses and are not mandatory in this solution. For example, as shown in Table 1 or Table 2.
[0208] In the above embodiment, the trust level of the security status between devices is improved, so that the trust level of the devices of both parties is at a higher level, and the security and reliability of information interaction across smart devices are improved.
[0209] Embodiment 3: The above solution provided by the present disclosure can be applied to a variety of scenarios, including but not limited to any of the following scenarios:
[0210] Scenario 1: Cross-device access.
[0211] For example, when user A is using the first device, he hopes to share the photos and files stored on the second device (the second device can be other devices of user A or devices of other users with close relationships) with others through the first device. At this time, user A does not need to approach the second device and operate the second device to obtain the photos, files, etc. on the second device. Instead, user A can initiate an authorization request process to the second device through the first device, including sending the first security verification information to the second device. After receiving the information, the second device can also send the second security verification information to the first device. After the two devices trust each other through the bottom layer of the system, the first device can obtain the authorization message of the second device and access the photos, files, etc. on the second device based on the message.
[0212] For another example, when user A is using the first device, he wants to purchase a certain product or benefit, but the balance in the payment wallet is not enough to purchase the product or benefit. User A can initiate an authorization request process to the second device (the second device can be other devices of user A or devices of other users with a close relationship) through the first device, and send the first security verification information to the second device. After receiving the information, the second device can also send the second security verification information to the first device. After the two devices trust each other through the bottom layer of the system, the first device can obtain the authorization message of the second device, and purchase the product or benefit based on the message by accessing the payment wallet on the second device.
[0213] Among them, starting from the second device providing the first device with the information that the first device requests access, the second device can continuously collect the portrait information of the first device, profile the user of the first device, and obtain the user portrait result.
[0214] For example, the user portrait result shows that the user is most interested in the photos of people in the album. At a certain moment, the second device receives the access request from the first device, requesting to access the payment wallet on the second device. The second device believes that the current business of the first device has a low match with the previous user portrait result, such as a score of 40 points. At this time, the second device believes that the credibility of the first device has decreased, which can trigger the first device to re-acquire the authorization of the second device. The first device can send the first security verification information to the second device again, and the second device can also send the second security verification information to the first device after receiving it. After the two devices trust each other through the bottom layer of the system, the first device can obtain the authorization message of the second device and access the payment wallet on the second device based on the message.
[0215] The above is only an exemplary description, and any device-side access to obtain information on the second device should fall within the scope of protection of the present disclosure.
[0216] Scenario 2: Smart home control.
[0217] In the embodiment of the present disclosure, the first device may be a terminal device of user A, and the second device may be a smart home device.
[0218] Assume that the first device is the mobile phone of user A, and the second device is the smart door lock in the smart home system. When someone knocks on the door, the mobile phone and the smart door lock can interact using the solution provided by the present invention so that the mobile phone can obtain authorization for the smart door lock. Furthermore, user A can request access to the camera on the smart door lock through the mobile phone to confirm the person outside the door. Furthermore, when user A determines that the door needs to be opened for the person, he can access the control program of the smart door lock through the mobile phone to automatically open the door.
[0219] For another example, the first device may be one of the smart home devices, and the second device may be another smart home device.
[0220] For example, the first device is a smart housekeeper device among smart home devices, and the second device is a smart air conditioner, a smart TV, a smart rice cooker, etc.
[0221] Both can use the solution provided by the present disclosure to perform mutual authentication, and after confirming that both are trusted devices, the second device can be accessed or controlled through the first device.
[0222] Similarly, the smart home device as the second device profiles the user of the first device, matches the current behavior with the user profile result, and obtains a matching result. If the matching degree is poor, the second device can ask the first device to initiate the authorization request process again.
[0223] Scenario 3: Remote control of unmanned driving equipment.
[0224] Among them, unmanned driving equipment can be drones, unmanned vehicles, etc.
[0225] The first device can be a terminal device of a maintenance personnel, and the second device can be an unmanned driving device. For example, if an unmanned driving device fails, the maintenance personnel does not need to go to the failure site, but can authenticate each other through the terminal device of the maintenance personnel and the unmanned driving device. After confirming that they are both trusted devices, the terminal device obtains the authorization of the unmanned driving device, thereby accessing the control unit of the unmanned driving device, and obtaining the relevant data of the control unit and displaying it on the screen of the terminal device, so that the maintenance personnel can confirm the cause of the failure.
[0226] Furthermore, the unmanned driving device can profile the user of the first device. For example, the user profile result is that the user tends to obtain fault data recorded in the control unit. Assuming that the unmanned driving device receives access information from the first device and hopes to access functional modules such as the engine of the unmanned driving device, the unmanned driving device can evaluate the match between the user of the first device and the user before this moment. If it is considered that the match is low, the unmanned driving device can let the first device initiate the authorization request process again.
[0227] The above description is merely an exemplary description, and the solution disclosed herein may be applicable to various other scenarios requiring cross-device authorization and verification.
[0228] In addition, it should be noted that the first device may obtain identification information of the second device in advance, such as the physical address of the second device, so as to output the list of devices accessible to the first device.
[0229] For example, the first device may search for nearby devices via Bluetooth, infrared, wireless fidelity (Wireless Fidelity, WIFI), etc., so as to output the list.
[0230] When the user selects a device in the list of accessible devices, the device can be considered as the second device. At this time, the first device can initiate an authorization request process to the second device.
[0231] When the second device believes that the credibility of the first device has decreased, and asks the first device to initiate an authorization request process multiple times within a preset period of time, the first device can delete the second device from the list of accessible devices, or the second device can add the first device to the list of unsafe devices. The security of cross-device access is further improved. Corresponding to the aforementioned application function implementation method embodiment, the present disclosure also provides an embodiment of an application function implementation device.
[0232] Reference Figure 8 , Figure 8 is a block diagram of an information interaction device according to an exemplary embodiment, the device comprising:
[0233] A first sending module 810, configured to send first security verification information to a second device in response to a need to send an authorization request message to the second device, wherein the first security verification information is used by the second device to evaluate whether the first device is a trusted device;
[0234] A first evaluation module 820, configured to evaluate whether the second device is a trusted device based on the second security verification information sent by the second device;
[0235] An acquisition module 830 is configured to, after determining that the first device and the second device trust each other, acquire an authorization pass message sent by the second device based on the authorization request message, wherein the authorization pass message is used to authorize the first device to access the second device;
[0236] The second sending module 840 is configured to send an access request message to the second device based on the authorization information to request access to information on the second device.
[0237] Reference Fig. 9 , Fig. 9 is a block diagram of an information sending device according to an exemplary embodiment, the device comprising:
[0238] A second evaluation module 910, configured to evaluate whether the first device is a trusted device based on the first security verification information sent by the first device;
[0239] A third sending module 920 is used to send second security verification information to the first device, where the second security verification information is used by the first device to evaluate whether the second device is a trusted device;
[0240] A fourth sending module 930, configured to send an authorization pass message to the first device after determining that the first device and the first device trust each other, wherein the authorization pass message is used to authorize the first device to access the second device;
[0241] The execution module 940 is used to provide the first device with information that the first device requests access based on the access request message sent by the first device.
[0242] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art may understand and implement it without creative work.
[0243] Accordingly, the present disclosure also provides a computer-readable storage medium for storing a computer program, wherein the computer program is used to implement the steps of any of the above-mentioned information interaction methods when executed by a processor.
[0244] Accordingly, the present disclosure also provides an information interaction device, comprising:
[0245] processor;
[0246] a memory for storing processor-executable instructions;
[0247] The processor is configured to execute the executable instructions to implement the steps of any of the above-mentioned information interaction methods.
[0248] Fig.10 This is a block diagram of an information interaction device according to an exemplary embodiment. For example, the device 1000 may be a terminal device such as a mobile phone, a computer, a digital broadcast terminal, a message transceiver device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc. The terminal device may be a first device or a second device.
[0249] Reference Fig.10 , the device 1000 may include one or more of the following components: a processing component 1002 , a memory 1004 , a power component 1006 , a multimedia component 1008 , an audio component 1010 , an input / output (I / O) interface 1012 , a sensor component 1016 , and a communication component 1018 .
[0250] The processing component 1002 generally controls the overall operation of the device 1000, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 1002 may include one or more processors 1020 to execute instructions to perform all or part of the steps of the above-described method. In addition, the processing component 1002 may include one or more modules to facilitate interaction between the processing component 1002 and other components. For example, the processing component 1002 may include a multimedia module to facilitate interaction between the multimedia component 1008 and the processing component 1002.
[0251] One of the processors 1020 in the processing component 1002 may be configured to execute any of the above-mentioned information interaction methods.
[0252] The memory 1004 is configured to store various types of data to support the operation of the device 1000. Examples of such data include instructions for any application or method operating on the device 1000, contact data, phone book data, messages, pictures, videos, etc. The memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.
[0253] The power supply component 1006 provides power to the various components of the device 1000. The power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 1000.
[0254] The multimedia component 1008 includes a screen that provides an output interface between the device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1008 includes a front camera and / or a rear camera. When the device 1000 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.
[0255] The audio component 1010 is configured to output and / or input audio signals. For example, the audio component 1010 includes a microphone (MIC), and when the device 1000 is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 1004 or sent via the communication component 1018. In some embodiments, the audio component 1010 also includes a speaker for outputting audio signals.
[0256] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.
[0257] The sensor assembly 1016 includes one or more sensors for providing various aspects of the status assessment of the device 1000. For example, the sensor assembly 1016 can detect the open / closed state of the device 1000, the relative positioning of components, such as the display and keypad of the device 1000, the sensor assembly 1016 can also detect the position change of the device 1000 or a component of the device 1000, the presence or absence of user contact with the device 1000, the orientation or acceleration / deceleration of the device 1000 and the temperature change of the device 1000. The sensor assembly 1016 can include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 1016 can also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1016 can also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor.
[0258] The communication component 1018 is configured to facilitate wired or wireless communication between the device 1000 and other devices. The device 1000 can access a wireless network based on a communication standard, such as WiFi, 3G, 4G, 5G, 6G or a combination thereof. In an exemplary embodiment, the communication component 1018 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1018 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.
[0259] In an exemplary embodiment, the apparatus 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described methods.
[0260] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1004 including instructions, and the instructions can be executed by the processor 1020 of the device 1000 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.
[0261] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprises a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.
[0262] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.
[0263] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims
1. An information interaction method, characterized in that: The method comprises: In response to the need to send an authorization request message to a second device, first security verification information is sent to the second device, where the first security verification information is used by the second device to evaluate whether the first device is a trusted device; Based on the second security verification information sent by the second device, evaluating whether the second device is a trusted device; After determining that the second device and the first device trust each other, obtaining an authorization message sent by the second device based on the authorization request message, wherein the authorization message is used to authorize the first device to access the second device; An access request message is sent to the second device based on the authorization information to request access to information on the second device.
2. The method according to claim 1, characterized in that: The method further comprises: Sending first signature verification information to the second device, where the first signature verification information is used by the second device to perform signature verification on the first device to obtain a first signature verification result; Based on the second signature verification information sent by the second device, perform signature verification on the second device to obtain a second signature verification result; After both the first signature verification result and the second signature verification result are passed, the first security verification information is generated.
3. The method according to claim 2, characterized in that The first signature verification information includes: A first challenge value randomly generated by the first device; and The first challenge value signed by the first device.
4. The method according to claim 2, characterized in that: The second signature verification information includes: A second challenge value randomly generated by the second device; and The second challenge value signed by the second device.
5. The method according to claim 4, characterized in that The method further comprises: When the second signature verification result is used to indicate that the second challenge value has not been changed, it is determined that the second signature verification result is passed.
6. The method according to claim 4, characterized in that The generating the first security verification information includes: The second challenge value is combined with the first trusted state information of the first device to obtain the first security verification information.
7. The method according to claim 1, characterized in that The second security verification information includes: First Challenge Value; and Second trusted state information of the second device.
8. The method according to claim 7, characterized in that The evaluating whether the second device is a trusted device based on the second security verification information sent by the second device includes: The second trusted state information is sent to a first application on the first device, and the first application evaluates whether the second device is a trusted device based on the second trusted state information, and the first application is an application requesting to access the second device.
9. The method according to claim 7 or 8, characterized in that: The method further comprises: Based on comparing the first challenge value included in the second security verification information with the first challenge value randomly generated by the first device before, it is determined whether there is a replay attack.
10. The method according to claim 1, characterized in that After accessing the second device based on the authorization information, the method further includes: Receive indication information sent by the second device, where the indication information is used to instruct the first device to re-acquire authorization of the second device.
11. An information interaction method, characterized in that: The method comprises: Based on the first security verification information sent by the first device, evaluating whether the first device is a trusted device; Sending second security verification information to the first device, where the second security verification information is used by the first device to evaluate whether the second device is a trusted device; After determining that the first device and the first device are mutually trusted, sending an authorization pass message to the first device, where the authorization pass message is used to authorize the first device to access the second device; Based on the access request message sent by the first device, provide the first device with information that the first device requests access.
12. The method according to claim 11, characterized in that The method further comprises: Based on the first signature verification information sent by the first device, perform signature verification on the first device to obtain a first signature verification result; Sending second signature verification information to the first device, where the second signature verification information is used by the first device to perform signature verification on the second device to obtain a second signature verification result; After both the first signature verification result and the second signature verification result are passed, the second security verification information is generated.
13. The method according to claim 12, characterized in that The second signature verification information includes: A second challenge value randomly generated by the second device; and The second challenge value signed by the second device.
14. The method according to claim 12, characterized in that The first signature verification information includes: a first challenge value randomly generated by the first device; The first challenge value signed by the first device.
15. The method according to claim 14, characterized in that The method further comprises: When the first signature verification result is used to indicate that the first challenge value has not been changed, it is determined that the first signature verification result is passed.
16. The method according to claim 14, characterized in that The generating the second security verification information comprises: The first challenge value is combined with the second trusted state information of the second device to obtain the second security verification information.
17. The method according to claim 11, characterized in that The first security verification information includes: A second challenge value; and First trusted state information of the first device.
18. The method according to claim 17, characterized in that The evaluating whether the first device is a trusted device based on the first security verification information sent by the first device includes: The first trusted state information is sent to a second application on the second device, and the second application evaluates whether the first device is a trusted device based on the first trusted state information, and the second application is the application requested to access.
19. The method according to claim 17 or 18, characterized in that The method further comprises: Based on comparing the second challenge value included in the first security verification information with the second challenge value randomly generated by the second device before, it is determined whether there is a replay attack.
20. The method according to claim 11, characterized in that After providing the first device with the information that the first device requests to access, the method further includes: Collecting portrait information of the first device, where the portrait information is used to create a portrait of a user of the first device; Based on the portrait information, a user of the first device is profiled to obtain a user portrait result; determining a current behavior of the first device based on an access request message currently sent by the first device; Matching the current behavior with the user portrait result to obtain a matching result, wherein the matching result is used to evaluate the matching degree between the current behavior and the user portrait result; When the matching degree is lower than a preset matching degree, indication information is sent to the first device, where the indication information is used to instruct the first device to re-acquire authorization of the second device.
21. An information interaction device, characterized in that: The device comprises: A first sending module, configured to send first security verification information to a second device in response to a need to send an authorization request message to the second device, wherein the first security verification information is used by the second device to evaluate whether the first device is a trusted device; A first evaluation module, configured to evaluate whether the second device is a trusted device based on the second security verification information sent by the second device; an acquisition module, configured to, after determining that the first device and the second device trust each other, acquire an authorization message sent by the second device based on the authorization request message, wherein the authorization message is used to authorize the first device to access the second device; The second sending module is configured to send an access request message to the second device based on the authorization information to request access to information on the second device.
22. An information interaction device, characterized in that: The device comprises: A second evaluation module, configured to evaluate whether the first device is a trusted device based on the first security verification information sent by the first device; A third sending module, configured to send second security verification information to the first device, where the second security verification information is used by the first device to evaluate whether the second device is a trusted device; A fourth sending module, configured to send an authorization pass message to the first device after determining that the first device and the first device trust each other, wherein the authorization pass message is used to authorize the first device to access the second device; An execution module is used to provide the first device with information that the first device requests access based on the access request message sent by the first device.
23. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the information interaction method described in any one of claims 1 to 20 are implemented.
24. An information interaction system, characterized in that: include: A first device that initiates access, the first device being used to execute the information interaction method according to any one of claims 1 to 10 above; The accessed second device is used to execute the information interaction method described in any one of claims 11 to 20.
25. An information interaction device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to execute the executable instructions to implement the steps of the information interaction method described in any one of claims 1-20.
