Login authentication method and system based on smart card, and server

Abstract

The invention relates to a login authentication method based on an intelligent card, which comprises the following steps of: 1, when an intelligent terminal initiates a one-key login request of an application, generating SDK (Software Development Kit) data by a one-key login SDK integrated in the application and sending the SDK data to the intelligent card application; 2, the intelligent card application generates intelligent card data through encryption based on the SDK data, the intelligent card ICCID and other data; 3, the client terminal sends the SDK data and the intelligent card data to an operator server for data verification; 4, after the data verification is passed, the mobile phone number which is reversely found out according to the intelligent card ICCID is packaged and returned to the one-key login SDK; and 5, the one-key login SDK returns the packaged data to the application, and the application jumps to a corresponding login page for login. By adopting the login authentication method, the authentication security level can be improved, the authentication application scene can be widened, the success rate can be improved, and the risk control capability can be enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a login authentication method and system based on a smart card and a server. BACKGROUND

[0002] With the popularity of mobile Internet, user login authentication as the first gateway of network service is crucial in terms of security and convenience. In the prior art, mainstream login authentication schemes include traditional username and password login, SMS verification code login, two-dimensional code scanning login, and emerging one-click login, etc.

[0003] Among them, the one-click login scheme has a significant advantage in convenience by relying on the communication network capability of the operator to directly obtain the mobile phone number after user authorization, eliminating the cumbersome steps of user inputting account password and SMS verification code. This scheme usually relies on the mobile data network (cellular network) of the terminal device to identify the user identity. However, in actual application, the inventors found that the existing one-click login and other authentication schemes still have many technical problems when facing complex network environments and growing security threats.

[0004] Specifically, the defects of the prior art mainly include: 1. Strong dependence on network environment, limited authentication scenarios: The traditional one-click login scheme strongly depends on the cellular network connection of the terminal. In the Wi-Fi network environment, or in the "only SMS available" state where the cellular network signal is weak but the SMS function is normal, the authentication cannot be completed. Similarly, the SMS verification code and two-dimensional code login schemes also require the terminal to have smooth network connection, and completely fail in offline or poor network scenarios, resulting in limited authentication success rate and user coverage.

[0005] 2. Multiple security risks, insufficient protection capabilities: The username and password scheme faces the risk of weak password cracking and password database leakage; the SMS verification code faces the risk of sniffing and interception, and may cause poor user experience due to network delay; the two-dimensional code login faces the risk of malicious two-dimensional code phishing attacks. Even the software-based one-time password (OTP) scheme is limited by the security environment of the terminal operating system and may be attacked by malicious software.

[0006] 3. Online and offline authentication capabilities are fragmented: Existing offline authentication schemes solve the login problem in network-free scenarios, but usually cannot verify user identity and update security policies in real time, and need to perform data synchronization and audit after the device is reconnected to the network, which has a lag in security. Conversely, online authentication schemes cannot handle offline scenarios. There is a lack of a unified authentication solution that can seamlessly integrate online and offline capabilities and maintain high security levels at all times.

[0007] Therefore, how to provide a login authentication method capable of breaking through the limitation of the existing network environment, improving the authentication strength by using the hardware-level security capability, and achieving convenience, universality and high security is a technical problem to be solved by those skilled in the art. SUMMARY

[0008] The present application aims to overcome the technical problems of strong network environment dependence, limited authentication scene, insufficient security protection capability, and split online and offline authentication capability in the existing login authentication scheme, and provides a login authentication method, system and server based on a smart card, aiming to improve the security level of one-key login authentication and the verification success rate in various network environments.

[0009] According to a first aspect of the present application, a login authentication method based on a smart card is provided, comprising the following steps: Step 1: when a one-key login request of an application is initiated in a smart terminal, a one-key login SDK integrated in the application generates SDK data and sends it to a smart card application; Step 2: the smart card application generates smart card data by encryption based on the SDK data and other data such as smart card ICCID; Step 3: the client terminal sends the SDK data and the smart card data to an operator server for data verification; Step 4: after the data verification is passed, the mobile phone number retrieved from the smart card ICCID is subjected to a security risk verification, and the encapsulated data is returned to the one-key login SDK; Step 5: the one-key login SDK returns the encapsulated data to the application, and the application jumps to the corresponding login page for login.

[0010] Preferably, in step 1, the one-key login SDK generates SDK data, which specifically comprises: The one-key login SDK collects current network data, smart application package name, certificate fingerprint, application ID and timestamp to form data1; The data1 is encrypted to generate the SDK data.

[0011] Preferably, in step 2, the smart card application generates smart card data by encryption based on the SDK data and smart card ICCID, and the specific steps are as follows: The smart card application collects the smart card ICCID and decrypts the SDK data to obtain data1; Randomly intercept consecutive bytes from a salt value file to form verification data; The smart card ICCID, the verification data and the data1 are packaged to form data2; encrypting the data2 to generate the smart card data.

[0012] Preferably, in step 3, the specific method of data verification of the smart card data by the operator server is: decrypting the smart card data to obtain data2, verification data, and smart card ICCID; comparing and verifying the verification data with the salt value file; After verification, the operator server looks up the mobile phone number of the smart card according to the smart card ICCID.

[0013] Preferably, the specific method of data verification of the SDK data by the operator server is: decrypting the SDK data to obtain data1, and extracting network data, smart application package name, certificate fingerprint, and application ID in data1; verifying whether the network data and the mobile phone number are consistent, and if so, the data verification is passed.

[0014] Preferably, the operator server further verifies the security of data1 and data2 through artificial intelligence, including: performing security analysis on past big data of the ICCID and mobile phone number; performing security analysis on the mobile phone number and application package name; and performing security analysis on the current network data; After successful security verification, the mobile phone number is returned to the one-click login SDK by the smart card application.

[0015] Preferably, if the security verification is risky, the one-click login SDK initiates re-authentication, re-collects and calculates to generate second SDK data; The SDK data, second SDK data, and smart card data are sent to the operator server for data verification.

[0016] Preferably, in step 5, the application sends login-related data to the application server for login and data retention, and the login-related data at least includes the mobile phone number.

[0017] According to the second aspect of the present application, a login authentication system using the above-mentioned smart card-based login authentication method is provided, including a smart terminal, installed with a plurality of applications, wherein a one-click login SDK is deployed in the applications, and the one-click login SDK is used to generate SDK data; a smart card, installed in the smart terminal, wherein a smart card application is deployed in the smart card, and the smart card application is used to generate smart card data based on the SDK data and smart card ICCID through encryption; An operator server is configured to perform data verification on the SDK data and the smart card data. An application server is configured to log in an application according to the mobile phone number obtained by reverse lookup of the smart card ICCID.

[0018] According to a third aspect of the present application, a server is provided, comprising a memory and at least one processor. The memory stores a computer program, and the at least one processor executes the computer program stored in the memory to implement the smart card-based login authentication method.

[0019] Compared with the prior art, the technical solution provided by the present application has at least the following beneficial effects: 1. The authentication security level is improved: the core operation of the authentication logic (such as OTP generation, data signature) is executed in the smart card (SIM card), which is a hardware security module. The encryption operation capability and tamper-proofing feature of the smart card provide hardware-level security for the authentication process, effectively resisting malicious software attacks that may occur at the operating system level, and the security is much higher than that of a pure software solution.

[0020] 2. The authentication application scenarios are broadened, and the success rate is improved: the present application innovatively supports authentication in multiple network environments. In addition to online authentication in conventional cellular networks and Wi-Fi networks, an authentication process is specially designed for the terminal in the "only SMS available" state. The authentication data packet can be sent through the data SMS channel, which greatly broadens the application range of one-key login and solves the problem that the traditional one-key login cannot be used in the absence of cellular data networks, thereby improving the overall success rate of authentication.

[0021] 3. The risk control capability is enhanced: the present application introduces an artificial intelligence (AI) risk assessment mechanism at the server side of the authentication. After completing the basic data verification, the server sends the multi-dimensional data (such as data from the SDK and data from the smart card Applet) in the authentication process to the AI model for deep security analysis, which can more accurately identify abnormal behaviors such as black and gray production attacks, and realizes multi-level security protection from the data layer to the intelligent layer. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 is a step flowchart of a smart card-based login authentication method of the present application; Figure 2 is a structural schematic diagram of a smart card-based login authentication system of the present application; Figure 3 is a detailed flowchart of a smart card-based login authentication system of the present application. DETAILED DESCRIPTION

[0023] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The present application will be described in detail below with reference to the drawings and in combination with the embodiments.

[0024] It should be noted that the above detailed description is exemplary and is intended to provide further description of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present application belongs.

[0025] Embodiment 1 As shown in Figure 1 and Figure 3 The smart card-based login authentication method in an embodiment of the present application first performs system preparation, including parameter setting, data preparation, etc., specifically including: The smart application and the operator server sign a one-key login related cooperation agreement; the smart application provides the following data to the operator: smart application package name, certificate fingerprint, etc. The smart application is an application installed on a smart terminal.

[0026] The operator assigns the following data to the smart application: smart application App ID, etc.

[0027] The smart application adds the one-key login SDK of the operator server, and completes the connection test. (The one-key login SDK of the operator is hereinafter referred to as one-key login SDK); the operator server preloads a set of asymmetric keys as public key MNOSM2pub and private key MNOSM2pri. The one-key login SDK preloads a set of asymmetric keys as public key SDKSM2pub and private key SDKSM2pri. The operator server and the one-key login SDK each preloads the public key of the other party (SDKSM2pub, MNOSM2pub).

[0028] The smart card preloads or installs a one-key login Applet application, i.e., a smart card application (or a small program), for storing smart application package name and other related data, and performing one-key login related data operation.

[0029] The smart card application preloads a set of asymmetric keys as public key SimSM2pub and private key SimSM2pri. The operator server and the smart card application each preloads the public key of the other party (SimSM2pub, MNOSM2pub). The smart card application and the operator server share salt value file data (the file size is recommended to be 4096 bytes).

[0030] The data format in the following communication adopts JSON key-value pair format, and the key name is agreed in advance.

[0031] Add smart card application security policy judgment mark: if the operator returns the authentication risk, return to the SDK authentication risk, and need to authenticate again; if the Applet data SMS sending fails, return to the SDK data SMS sending fails, and need to authenticate again.

[0032] The specific login authentication method steps are as follows: Step 1: When the smart terminal initiates a one-key login request of the application, the one-key login SDK integrated in the application generates SDK data and sends it to the smart card application; In this step, the user opens the smart terminal and requests to log in to the smart application by using the one-key login SDK. The smart application calls the SDK interface to initiate a one-key login request authentication.

[0033] The SDK judges the current terminal network status. If it is offline or in flight mode, it directly returns authentication failure. If it is WIFI, traffic or only SMS can state, it continues the following authentication process.

[0034] The specific method for the one-key login SDK to generate SDK data is as follows: Step 11: The one-key login SDK collects current network data, smart application package name, certificate fingerprint, smart application AppID, and timestamp 1 to form data1; Step 12: The one-key login SDK uses SM3 hash algorithm to calculate data1 to obtain hash1; Step 13: The one-key login SDK uses SM4 algorithm to encrypt data1 and hash1 using random key randkey1 to obtain ciphedata1; Step 14: The one-key login SDK uses the operator public key MNOSM2pub to encrypt randkey1 to obtain cipherandkey1; Step 15: The one-key login SDK uses the SDK private key SDKSM2pri to sign cipherandkey1 and ciphedata1 to obtain sign1; Mark SDK data = cipherandkey1 + ciphedata1 + sign1. The one-key login SDK securely transmits the SDK data to the smart card application.

[0035] Step 2: The smart card application generates smart card data based on the SDK data and smart card ICCID through encryption; In this step, the specific method is as follows: Step 21: The smart card application collects the smart card ICCID file content, randomly intercepts continuous 16 bytes of salt data from the salt value file, and generates a smart card random key randkey2.

[0036] Step 22: The smart card application composes data2 with timestamp1, smart application package name, ICCID file content and salt data.

[0037] Step 23: The smart card application calculates hash2 with data2 using SM3 hash algorithm.

[0038] Step 24: The smart card application encrypts data2 and hash2 with random key randkey2 using SM4 algorithm to get ciphedata2.

[0039] Step 25: The smart card application signs cipherandkey2 and ciphedata2 using smart card private key SimSM2pri to get sign2.

[0040] Mark smart card data1 = cipherandkey2 + ciphedata2 + sign2.

[0041] Step 3: The client terminal sends the SDK data and the smart card data to the operator server for data verification; In this step, the smart card data1 and the SDK data1 are sent through a data message. If the sending is successful, the operator server verifies the smart card data and the SDK data1. The specific verification method is as follows: First, verify the smart card data: Step 301: Verify the signature sign2 of cipherandkey2 and ciphedata2 using SimSM2pub; Step 302: Decrypt cipherandkey2 to get randkey2 using MNOSM2pri; Step 303: Decrypt ciphedata2 to get data2 and hash2 using randkey2; Step 304: Verify whether hash2 is correct using SM3 hash algorithm to calculate data2; Step 305: Extract ICCID file content and salt data from data2; Step 306: Check whether the salt data exists in the salt value file; Step 307: Find the smart card mobile phone number by checking the ICCID file content to the server.

[0042] Then verify the SDK data: Step 311: Verify the signature sign1 of cipherandkey1 and ciphedata1 using SDKSM2pub; Step 312: decrypt cipherandkeyl using MNOSM2pri to obtain randkeyl; Step 313: decrypt ciphedata 1 using randkeyl to obtain data 1 and hashl; Step 314: use the SM3 hash algorithm to calculate data 1 to verify whether hashl is correct; Step 315: extract network data, smart application package name, certificate fingerprint, and smart application App ID from data 1; Step 316: check whether the smart application package name, certificate fingerprint, and smart application App ID are correct; Step 317: verify whether the network data and the mobile phone number are consistent.

[0043] If the smart card data or SDK data 1 is incorrect, return authentication failure, the error reason is data verification failure, and the returned data contains the business sequence number seql; If the verification is passed, put data 1 and data 2 data into artificial intelligence AI verification security, including the following cases: 1. If the security verification fails, return authentication failure, the error reason is security verification failure, and the returned data contains the business sequence number seq2; 2. If the security verification is risky, return authentication risk, the error reason is that the security verification is risky and needs to be authenticated again, and the returned data contains the business sequence number seq3; 3. If the security verification is successful, return authentication success, and the returned data contains the business sequence number seq4 and the mobile phone number.

[0044] Step 4: After the data verification is passed, the mobile phone number retrieved according to the smart card ICCID is returned to the one-key login SDK. In this step, the smart card application transmits the security data to the one-key login SDK after receiving the data that the verification is passed. According to the security policy judgment mark, if the authentication is risky, the smart card data is attached, and the one-key login SDK can initiate the authentication again.

[0045] Here, according to the security policy judgment mark, the smart card application returns the sending request failure to the one-key login SDK in the case of smart card application sending failure, and the one-key login SDK can initiate the authentication again through WIFI or process.

[0046] Step 5: The one-key login SDK returns the encapsulated data to the application, and the application jumps to the corresponding login page for login.

[0047] In this step, after receiving the returned data, the SDK processes it according to different types: (1) In the case of data verification failure, notify the application of one-key login failure, and the business sequence number seq1; (2) In the case of security verification failure, notify the application of one-key login failure, and the business sequence number seq2; (3) In the case of successful authentication, notify the application of one-key login authentication success, and return the sequence number seq4 and the mobile phone number; (4) In the case of authentication risk or sending request failure, the one-key login SDK initiates re-authentication through WIFI or traffic. The specific method is: Step 51: When the one-key login SDK re-authenticates, it needs to collect and calculate SDK data2 again according to the steps above; the one-key login SDK sends SDK data1+SDK data2+Applet data1, and the business sequence number (if any, need to be attached) to the operator server.

[0048] Step 52: The operator server performs data verification according to the same steps above.

[0049] Step 53: When security verification, put the data data in the three groups of SDK data1, SDK data2, and Applet data1 into artificial intelligence AI for security verification: (the operator server mainly verifies data correctness, and the operator artificial intelligence AI mainly verifies security risk) (1) If the security verification fails, return authentication failure, the error reason is security verification failure, and the returned data contains the business sequence number seq5; (2) If the security verification fails, return authentication failure, the error reason is security verification failure, and the returned data contains the business sequence number seq6; (3) In the case of successful authentication, notify the intelligent application of one-key login authentication success, sequence number seq7 and mobile phone number Phone Number; Step 54: After receiving the return, the SDK encapsulates the data and returns it to the intelligent application, including the following cases: In the case of data verification failure, notify the intelligent application of one-key login failure, and the business sequence number seq5; In the case of security verification failure, notify the intelligent application of one-key login failure, and the business sequence number seq6; In the case of successful authentication, notify the intelligent application of one-key login authentication success, sequence number seq7 and mobile phone number PhoneNumber.

[0050] Step 55: The intelligent application jumps to the corresponding login page according to the return result, and the intelligent application sends the login related data to the intelligent application server for data retention.

[0051] As Figure 2 shown, the embodiment discloses a login authentication system using the above-mentioned smart card-based login authentication method, comprising a smart terminal, which is installed with a plurality of applications, wherein a one-key login SDK is deployed in the applications, and the one-key login SDK is used to generate SDK data; a smart card, which is installed in the smart terminal, wherein a smart card application is deployed in the smart card, and the smart card application is used to generate smart card data through encryption based on the SDK data and a smart card ICCID; an operator server, which is used to perform data verification on the SDK data and the smart card data; an operator artificial intelligence (AI) also verifies security risks.

[0052] an application server, which is used to perform login of an application according to a mobile phone number found by reverse lookup of a smart card ICCID.

[0053] The embodiment also discloses a server, comprising a memory and at least one processor. The memory stores a computer program, and the at least one processor executes the computer program stored in the memory to implement the above-mentioned smart card-based login authentication method.

[0054] Compared with the prior art, the technical scheme provided by the present application has at least the following beneficial effects: 1. The authentication security level is improved: the core operation (such as OTP generation, data signature) of the authentication logic is executed in the smart card (SIM card), which is a hardware security module. The encryption operation capability and tamper-proofing feature of the smart card provide hardware-level security for the authentication process, effectively resist malicious software attacks that may occur at the operating system level, and the security is much higher than that of a pure software solution.

[0055] 2. The authentication application scenarios are broadened, and the success rate is improved: the present application innovatively supports authentication in multiple network environments. In addition to online authentication in conventional cellular networks and Wi-Fi networks, an authentication process in the terminal "only SMS available" state is specially designed. The authentication data packet can be sent through the data SMS channel, which greatly broadens the application range of one-key login and solves the problem that the traditional one-key login cannot be used in the absence of cellular data networks, thereby improving the overall success rate of authentication.

[0056] 3. Enhanced risk control capabilities: This solution introduces an artificial intelligence (AI) risk assessment mechanism on the authentication server side. After completing the basic data verification, the server sends the multi-dimensional data during the authentication process (such as data from the SDK and data from the smart card Applet) to the AI model for in-depth security analysis, which can more accurately identify abnormal behaviors such as black and gray production attacks, and achieve multi-level security protection from the data layer to the intelligent layer.

[0057] Embodiment 2 In this embodiment, the difference from Embodiment 1 is that the security policy judgment identifier of the smart card application is added: If the operator returns an authentication risk, return to the SDK that the authentication is risky, and no need to authenticate again; If the Applet data SMS sending fails, return to the SDK that the data SMS sending fails, and no need to authenticate again.

[0058] Applied to specific steps, there are differences between steps 3 and 4, specifically: In step 3, verify the smart card data or SDK data, if the verification is passed, put data1 and data2 data into artificial intelligence AI verification security, including the following cases: 1. If the security verification fails, return authentication failure, the error reason is security verification failure, and the return data contains business sequence number seq2; 2. If the security verification is risky, return authentication failure, the error reason is security verification risk, and the return data contains business sequence number seq3; 3. If the security verification is successful, return authentication success, the return data contains business sequence number seq4 and mobile phone number.

[0059] Step 4: After the data verification is passed, the mobile phone number retrieved according to the smart card ICCID is returned to the one-key login SDK; In this step, after the smart card application receives the data that the verification is passed, the security data is transmitted to the one-key login SDK. According to the security policy judgment identifier, if the authentication is risky, return the information that the one-key login SDK authentication fails, and no need to authenticate again.

[0060] Here, according to the security policy judgment identifier, the smart card application returns the one-key login SDK to return the sending request failure in the case of smart card application sending failure, and no need to authenticate again.

[0061] Step 5: After the one-key login SDK receives the return data, it is processed according to different types: (1) In the case of data verification failure, notify the smart application that the one-key login fails, and the business sequence number is seq1.

[0062] (3) authentication success, notify the intelligent application of one-key login authentication success, sequence number seq4 and mobile phone number;

[0063] (3) authentication success, notify the intelligent application of one-key login authentication success, sequence number seq4 and mobile phone number; (4) authentication risk or sending request failure, notify the intelligent application of one-key login failure, business sequence number.

[0064] After receiving the return, the one-key login SDK returns the data to the intelligent application: (1) data verification failure, notify the intelligent application of one-key login failure, business sequence number seq5.

[0065] (2) security verification failure, notify the intelligent application of one-key login failure, business sequence number seq6.

[0066] (3) authentication success, notify the intelligent application of one-key login authentication success, sequence number seq7 and mobile phone number.

[0067] Finally, the intelligent application jumps to the corresponding login page according to the return result, and the intelligent application sends login related data to the intelligent application server for data retention.

[0068] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0069] It should be noted that the terms "first", "second", and the like, used in the specification and the appended claims are intended to distinguish between similar objects, but are not necessarily used to describe a particular sequential or chronological order. It will be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in other sequences than those described or otherwise illustrated herein.

[0070] Furthermore, the term "comprising" and "including" and their variants are intended to cover both the case where only the stated features are present and the case where additional features are also present. For example, a process, method, system, product, or apparatus that comprises or includes one list of steps or elements is not necessarily limited to only those steps or elements but can include additional steps or elements not expressly listed or inherent to such process, method, system, product, or apparatus.

[0071] For purposes of the description hereinafter, spatial or directional terms, for example, "above", "below", "upper", "lower", "top", "bottom", "over", "under", "left", "right" and the like, relate to the

[0072] In the detailed description herein, reference is made to the accompanying drawings which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments can be used, and other changes can be made, without departing from the spirit or scope of the subject matter presented herein.

[0073] The above description is embodied in the context of preferred embodiments of the application. The application is not restricted to the details of the foregoing illustrative embodiments. The application can be practiced with modification and alteration and can have other uses within the scope of the disclosure. Any modifications, equivalent substitutions, improvements, and the like which do not depart from the spirit of the application are intended to be included in the scope of the application.

Claims

1. A login authentication method based on a smart card, characterized in that, Includes the following steps: Step 1: When a one-click login request is initiated on a smart terminal, the one-click login SDK integrated within the application generates SDK data and sends it to the smart card application; Step 2: The smart card application generates smart card data by encrypting the SDK data and the smart card ICCID; Step 3: The client terminal sends the SDK data and the smart card data to the operator's server for data verification; Step 4: After the data verification is successful, the mobile phone number retrieved based on the smart card ICCID will be packaged and returned to the one-click login SDK; Step 5: The one-click login SDK returns the packaged data to the application, which then redirects to the corresponding login page for login.

2. The smart card-based login authentication method according to claim 1, characterized in that, In step 1, the one-click login SDK generates SDK data as follows: The one-click login SDK collects current network data, smart application package name, certificate fingerprint, application ID, and timestamp to form data1; The data1 is encrypted to generate SDK data.

3. The smart card-based login authentication method according to claim 2, characterized in that, In step 2, the smart card application generates smart card data based on the SDK data and the smart card ICCID, after encryption. The specific steps are as follows: The smart card application collects the smart card ICCID and decrypts the SDK data to obtain data1; Randomly extract consecutive bytes from the salt value file to form the verification data; Package the smart card ICCID, verification data, and data1 into data2; The data2 is encrypted to generate the smart card data.

4. The smart card-based login authentication method according to claim 3, characterized in that, In step 3, the specific method by which the operator's server verifies the smart card data is as follows: Decrypt the smart card data to obtain data2, verification data, and the smart card ICCID; The verification data is compared and verified with the salt value file; After successful verification, the operator's server retrieves the smart card's mobile phone number based on the smart card's ICCID.

5. The smart card-based login authentication method according to claim 4, characterized in that, The specific method used by the carrier's server to verify SDK data is as follows: Decrypt the SDK data to obtain data1, and extract the network data, smart application package name, certificate fingerprint and application ID from data1; Verify whether the network data matches the mobile phone number. If they match, the data verification is successful.

6. The smart card-based login authentication method according to claim 5, characterized in that, The carrier's servers also use artificial intelligence to verify the security of data1 and data2, including: A security analysis was conducted on the historical big data of the phone number replaced by the ICCID. Perform security analysis on phone numbers and application package names; And to perform security analysis on current network data; After successful security verification, the smart card application will return the mobile phone number to the one-click login SDK.

7. The smart card-based login authentication method according to claim 6, characterized in that, If the security verification is deemed risky, the one-click login SDK will initiate a second authentication, re-collecting and recalculating the second SDK data; The SDK data, the second SDK data, and the smart card data are then sent to the operator's server for data verification.

8. The smart card-based login authentication method according to claim 1, characterized in that, In step 5, the application sends login-related data to the application server to log in and retain the data. The login-related data includes at least a mobile phone number.

9. A login authentication system employing the smart card-based login authentication method according to any one of claims 1 to 8, characterized in that, include A smart terminal has several applications installed, and a one-click login SDK is deployed in the applications. The one-click login SDK is used to generate SDK data. A smart card is installed in the smart terminal. The smart card has a smart card application deployed on it. The smart card application is used to generate smart card data through encryption based on the SDK data and the smart card ICCID. The operator's server is used to verify the SDK data and the smart card data; at the same time, it uses artificial intelligence to perform security risk assessment. The application server is used to log in to applications based on the mobile phone number retrieved from the smart card's ICCID.

10. A server, characterized in that, include: Memory and at least one processor; The memory stores a computer program, and the at least one processor executes the computer program stored in the memory to implement the smart card-based login authentication method according to any one of claims 1 to 8.

Images