A trusted business card call system and method

Abstract

The application discloses a trusted business card calling system and method, comprising: an electronic authentication module, which is used for issuing a digital certificate for an enterprise or an institution with a first user; a business card issuing module, which is used for editing and exporting a vCard format file of the first user's business card information, and signing the business card of the first user's vCard format file by using a private key of the digital certificate to obtain a trusted business card, and publishing the trusted business card to a directory server for a calling terminal to download; the calling terminal and the called terminal; the directory server, which is used for authenticating other system structures, and providing specified access rights for the calling terminal and the called terminal, and is used for the calling terminal to download the trusted business card and the called terminal to verify the trusted business card; the calling terminal downloads the trusted business card of the first user from the directory server, and transmits the trusted business card to the called terminal for display. The application has the advantages of independent issuing by the enterprise or the institution, guaranteeing the authenticity of work role information, relatively low implementation cost, better compatibility with existing systems and applications, and the like.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a trusted business card call system and method. Background Technology

[0002] The proliferation of harassing, sales, and fraudulent calls has led to a distrust of unknown callers, resulting in a habitual rejection of all calls from unknown numbers. This has even hindered the normal business operations of government departments and enterprises.

[0003] Therefore, telecom operators and third-party service providers began to offer caller ID services, allowing called users to see the caller's identity information in order to improve the call connection rate. However, most caller IDs are provided by the caller and lack corporate or institutional endorsement, making it impossible to guarantee the authenticity of the information. In addition, most caller IDs lack cryptographic protection, which makes it impossible to guarantee that their content is tamper-proof.

[0004] Therefore, in order to solve the problem of caller identity information being tamper-proof, the existing technology has published the GB / T43779-2024 standard, which is based on public key cryptography technology, issues a trusted certificate to the calling user terminal, and performs electronic signature on the call information based on the trusted certificate, thereby achieving the authenticity and trustworthiness of the calling user information and the unforgeability of the call information.

[0005] While the GB / T 43779-2024 standard technically solves the problem of trustworthy personal identity of callers well, it is still somewhat lacking in terms of trustworthy work roles of callers, specifically including:

[0006] Caller ID cards are primarily intended to display a user's job role rather than their personal identity information. Only the company or organization to which the user belongs can accurately know their job role information. In this case, the GB / T 43779-2024 standard stipulates that a trusted identity credential should be issued by an identity credential issuance center. However, without the cooperation of the company or organization, the identity credential issuance center has difficulty verifying the user's job role information and cannot guarantee the authenticity of the job role information in the issued identity credential.

[0007] Users may have multiple job roles, and these job roles are volatile. According to the GB / T43779-2024 standard, the identity credential issuance center needs to issue trusted identity credentials for each job role separately, which has the disadvantages of high service costs and high key management costs.

[0008] The GB / T 43779-2024 standard requires calling users to apply for and install trusted identity credentials. The essence of trusted identity credentials is a public key certificate. The public and private keys of the public key certificate require the support of cryptographic module products, which greatly increases the deployment and management costs.

[0009] Current mainstream mobile operating systems such as Android and iOS support vCard format virtual cards as data for importing and exporting contacts. However, the identity credentials of the GB / T 43779-2024 standard are clearly incompatible with vCard, making it difficult to achieve compatibility with existing systems and applications.

[0010] The identity credentials in the GB / T 43779-2024 standard do not carry as much information as vCard, such as personal photos and company logos, which is not conducive to the diverse display of work roles.

[0011] Therefore, this application proposes a trusted business card call system and method with low implementation cost and compatibility with existing systems and applications to solve the above-mentioned technical problems. Summary of the Invention

[0012] The main objective of this invention is to provide a trustworthy business card call system and method to solve the technical problems mentioned in the background art. It has the advantages of enterprises and institutions issuing business cards independently, ensuring the authenticity of work role information, relatively low implementation cost, and better compatibility with existing systems and applications.

[0013] The present invention solves the above-mentioned technical problems by adopting the following technical solutions:

[0014] A trusted business card calling system includes:

[0015] The electronic authentication module, typically a trusted CA (electronic authentication service provider), is used to issue digital certificates to enterprises and institutions with the first user. This digital certificate is equivalent to the company's official seal. By signing an employee's business card with the private key of this digital certificate, a trusted caller ID card can be obtained.

[0016] The business card issuance module can be deployed on the side of enterprises and institutions, or deployed by the operating unit to provide cloud services. It is used to edit the first user's business card information and export vCard format files. Then, the private key of the unit's digital certificate is used to sign the first user's vCard format file to obtain a trusted business card, which is then published to the directory server for the calling terminal to download.

[0017] The calling terminal (or calling terminal APP) bound to the first user and the called terminal (or called terminal APP) bound to the second user, wherein the calling terminal (or calling terminal APP) is deployed on the calling user's mobile terminal and downloads the user's trusted business card from the directory server for display during a call, and the called terminal (or called terminal APP) is deployed on the called user's mobile terminal.

[0018] The operator's communication network provides VoIP voice call communication network for end users and supports the SIP call protocol;

[0019] The directory server, deployed by the operator, is used to authenticate other system structures such as CAs, enterprises and institutions, and end users, and to provide specified access permissions to different types of users, including calling terminals and called terminals, for calling terminals to download trusted business cards and called terminals to verify trusted business cards.

[0020] The calling terminal connects to the called terminal through a VoIP voice call communication network. The calling terminal downloads a first user trusted business card from a directory server, which is used to transmit it to the called terminal for display.

[0021] The CA institution and the operator's communication network are external systems.

[0022] Preferably, the electronic certification module (CA authority) is used to issue digital certificate cancellation lists (CRLs) to withdrawing or ceasing enterprises and institutions, and to publish CA certificates, issued digital certificates and digital certificate cancellation lists to the directory server;

[0023] The business card issuance module issues corresponding trusted business cards and a list of cancelled trusted business cards to employees who have left the company or changed their job positions based on the status of the enterprise or institution, which are then published to the directory server.

[0024] The business card issuance module issues corresponding trusted business cards and trusted business card cancellation information to employees who have left the company or changed their job positions based on the employee information of the enterprise or institution, which is used to publish to the directory server.

[0025] The calling terminal and the called terminal download CA certificates, digital certificates, digital certificate cancellation lists, trusted business cards, and trusted business card cancellation lists through the directory server, which are used to verify and display the trusted business card of the first user.

[0026] Preferably, a trusted business card call method, implemented based on any of the trusted business card call systems described above, includes the following steps:

[0027] S1. Application for Digital Certificates for Enterprises and Institutions: Personnel in charge of enterprises and institutions submit their organization's information to an authoritative CA institution through the electronic authentication module to apply for an organizational digital certificate;

[0028] S2. Issuance of Digital Certificates for Enterprises and Institutions: After reviewing the information of enterprises and institutions, the CA authority of the electronic authentication module issues digital certificates for the organization and stores the digital certificates in the form of USB keys to designated personnel of the enterprise or institution. The CA authority also regularly publishes the list of issued digital certificates for organizations, CA certificates of the electronic authentication module, and digital certificate cancellation lists to the directory server.

[0029] S3. Generation of Trusted Business Cards: After enterprises and institutions enter employee information, the business card issuance module generates a vCard format file and calls the organization's digital certificate private key to sign it, so as to ensure the integrity and non-repudiation of the vCard information and complete the issuance of trusted business cards for employees.

[0030] S4. Publishing Trusted Business Cards: Create a directory of enterprises and institutions on the directory server. The directory name should be consistent with the unified social credit code and the name of the unit in the subject of the unit's digital certificate. Publish the trusted business cards issued by the enterprises and institutions to this directory, and at the same time publish a list of cancelled trusted business cards to meet the needs of employees' job changes, departures, etc.

[0031] S5. Downloading Trusted Business Cards: Employees of enterprises and institutions perform identity authentication and binding on the calling terminal, and download the CA certificate of the electronic authentication module, the digital certificate of the enterprise or institution, the digital certificate cancellation list, the trusted business card and the trusted business card cancellation list from the directory server;

[0032] S6. Installation of Trusted Business Card: The calling terminal verifies the trusted business card based on the CA certificate, digital certificate cancellation list, enterprise / institution digital certificate and trusted business card cancellation list information. After successful verification, the trusted business card is installed.

[0033] S7. Call process for trusted business cards: When making a business contact, the calling terminal selects the trusted business card to be displayed and then dials. The calling terminal transmits specified data to the called terminal as authentication information. After authentication on the directory server, the calling terminal downloads the trusted business card of the calling terminal.

[0034] S8. Preliminary local verification of trusted business card: The called terminal obtains the trusted business card transmitted by the calling terminal, retrieves the mobile phone number on the trusted business card, and compares it with the incoming call number. If the comparison fails, the trusted business card is invalid and is displayed on the called terminal. The called user then decides whether to answer the call. If the comparison passes, proceed to the next step.

[0035] S9. Download Trusted Business Card Verification Information: The called terminal downloads the CA certificate, digital certificate cancellation list, digital certificate of the enterprise or institution to which the trusted business card belongs, and trusted business card cancellation list from the directory server;

[0036] S10. Verification of Trusted Business Card: The called terminal verifies the trusted business card according to specified conditions by downloading information. When all verifications are successful, the trusted business card is considered valid and the specified information of the trusted business card is displayed, waiting for the called user to answer. If the verification fails, the trusted business card is displayed as invalid, and the called user decides whether to answer.

[0037] Preferably, the directory server includes the following second-level directories:

[0038] The “dc=TrustCAs” directory contains sub-entries that are the various trusted electronic authentication service CA authorities in the electronic authentication module.

[0039] The “dc=Organization” directory contains sub-entries for each trusted business card issuing unit in the business card issuing module. The RDN of each trusted business card issuing unit entry includes a serialNumber field and an o field. The value of the serialNumber field is the unified social credit code of the enterprise or institution, and the value of the o field is the name of the enterprise or institution. The sub-entries of the trusted business card issuing unit entry are the employees of that unit.

[0040] Preferably, the directory server performs SMS authentication on the calling terminal, wherein the authentication process specifically includes:

[0041] a1. The user enters the organization name and mobile phone number, obtains the first data request, and sends it through the client;

[0042] a2. The server retrieves the corresponding entry from the directory server based on the organization name and mobile phone number in the first data request:

[0043] If it does not exist, the process ends and an authentication failure response is returned directly to the client;

[0044] If an entry exists, an SMS verification code is sent to the mobile phone number of that entry, and then the system returns a message to the client to wait for a further verification response.

[0045] a3. After receiving the SMS verification code, the user, in conjunction with the organization name and mobile phone number, sends a second data request again through the client.

[0046] a4. The server retrieves the entry from the directory based on the organization name and mobile phone number in the second data request:

[0047] If it does not exist, the process ends and an authentication failure response is returned to the client;

[0048] If an entry exists, the SMS verification code is compared. If the SMS verification code comparison fails, the process ends and an authentication failure response is returned to the client. If the SMS verification code comparison succeeds, authentication succeeds and a corresponding authentication success response is returned to the client.

[0049] Preferably, the trusted business card acquisition and generation step in step S3 includes:

[0050] Based on the attribute certificate, the attribute data is extended through vCardEx and written into vCard format data to finally generate a trusted business card. The signature value of the attribute certificate is obtained by signing the attribute certificate with the private key of the enterprise's digital certificate.

[0051] Preferably, the trusted business card transmits data based on a serial number, and the specific process includes:

[0052] b1. The calling terminal reads the serial number of the trusted business card to be transmitted and adds a first parameter to the Call-Info header field of the INVITE message. The first parameter contains the mobile phone number, the company name, and the HEX encoding of the trusted business card serial number.

[0053] b2. The called terminal obtains the first parameter from the INVITE message, uses the mobile phone number and company name in the first parameter as the username data, and uses the HEX encoding of the trusted business card serial number in the first parameter as the password data to input to the directory server for authentication.

[0054] b3. The directory server retrieves the trusted business card of the calling terminal user based on the username data and reads its serial number for comparison with the password data of the called terminal. If they match, the trusted business card is returned; otherwise, an invalidCredentials error is returned.

[0055] b4. If the called terminal receives an invalidCredentials error from the directory server, it will indicate that the trusted business card acquisition failed. If the called terminal receives a trusted business card from the directory server, the process will proceed to the next step.

[0056] Preferably, the specific verification method for the called terminal to verify the validity of the trusted business card includes:

[0057] c1. Obtain the validity period from the trusted business card. If the current time is not within the validity period, the verification fails.

[0058] If it is within its validity period, then obtain the vCard from the vCardExt extension of the trusted business card, obtain the mobile phone number and company name from the attributes of the vCard, and compare the mobile phone number in the vCard attributes with the mobile phone number of the caller, and the company name in the vCard attributes with the issuer name in the trusted business card. If any comparison result is inconsistent, the verification fails.

[0059] c2. Based on the unified social credit code and organization name in the trusted business card, download the organization's signature certificate and trusted business card cancellation list from the directory server;

[0060] Based on the issuer of the unit's signature certificate, read from the cache or download from the directory server the CA certificate and digital certificate revocation list;

[0061] It also verifies whether the downloaded CA certificate was issued by the root of trust pre-installed on the called terminal; if not, the verification fails.

[0062] c3. Based on the specified public key certificate verification standard, verify the organization's signature certificate according to the CA certificate and digital certificate revocation list. If not all requirements are met, the verification fails.

[0063] c4. Based on the attribute certificate verification standard, verify the trusted business card according to the unit signature certificate and the trusted business card cancellation list. If not all of them are satisfied, the verification fails.

[0064] c5. After all the above verifications are successful, the specified information of the caller's trusted business card will be displayed according to the information in vCard, and the call will wait for the called user to answer.

[0065] As can be seen from the above technical solution, the present invention provides a trusted business card call system and method.

[0066] Compared with the prior art, the present invention has the following advantages:

[0067] 1. This invention, by setting up an enterprise and institution's self-issuance mechanism in the trusted business card issuance system, can dynamically adjust employee information in a timely manner, ensuring the authenticity of incoming business cards, thereby providing better autonomy and flexibility, and improving the reliability of trusted business cards and the responsibility traceability capability of enterprises and institutions.

[0068] 2. This invention establishes a digital certificate signature endorsement mechanism within a CA (Certificate Authority) system, allowing enterprises and institutions to endorse their signatures. This provides legal validity for the signatures of these enterprises and institutions, ensuring accountability and enhancing anti-fraud capabilities, thereby effectively reducing the risk of telecommunications fraud.

[0069] 3. By setting up a keyless storage design in the terminal APP, the calling and called terminals do not need to store public and private key pairs, and there is no need to deploy a cryptographic module. This avoids the complexity of key management for terminal users, reduces implementation and maintenance costs, simplifies the system architecture, and further improves user convenience.

[0070] 4. This invention generates business cards using the vCard standard format in trusted business card generation, which is seamlessly compatible with existing mobile terminal applications. It can directly export and import from the address book and directly call Android and iOS APIs to process vCard, thereby improving user experience and enhancing the adaptability of the system and terminal ecosystem.

[0071] 5. This invention is based on attribute certificates, public key certificates, and LDAP directory servers. By integrating LDAP and X.509 standard technologies into the directory server, it can reuse existing mature technology systems, reduce development difficulty, thereby shortening the R&D cycle and reducing the cost of technology implementation.

[0072] It should be understood that the descriptions in this section are not intended to identify key or essential features of embodiments of the invention, nor are they intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Of course, implementing any product of the invention does not necessarily require achieving all of the advantages described above simultaneously. Attached Figure Description

[0073] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0074] Figure 1 This is a system structure block diagram of the present invention;

[0075] Figure 2 This is a schematic diagram of the overall method flow of the present invention;

[0076] Figure 3 This is a schematic diagram of the directory structure organization of the present invention;

[0077] Figure 4 This is a schematic diagram of the trusted business card data format of the present invention;

[0078] Figure 5 This is a schematic diagram of the SIP protocol INVITE message of the present invention. Detailed Implementation

[0079] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0080] For details in the embodiments, please refer to Figures 1 to 5 .

[0081] The trusted business card call system proposed in this invention comprises a directory server, a trusted business card issuance system, a calling terminal APP, a called terminal APP, a CA (Certificate Authority) institution, and a carrier communication network, as shown below. Figure 1 As shown, it specifically includes:

[0082] (1) CA Authority: Electronic Authentication Service Provider. It issues digital certificates to enterprises and institutions. These digital certificates are equivalent to the company's official seal; by using the private key of this digital certificate to sign an employee's business card, a trusted contact name can be obtained. CA authorities also add deregistered or dissolved enterprises and institutions to the Certificate Revocation List (CRL) and publish it on a directory server for mobile devices to download.

[0083] (2) Trusted Business Card Issuance System: This system can be deployed on the enterprise / institution side or provided as a cloud service by the operating unit. It allows editing of employee business card information, exporting vCard files, and using the organization's digital certificate private key to sign employee business cards, creating trusted business cards. These cards are then published to a directory server for download on mobile devices. A list of cancelled trusted business cards is issued to employees who have left the company or changed job positions, and this list is also published to a directory server for download on mobile devices.

[0084] (3) Directory Server: Deployed by the operating unit, it authenticates CAs, enterprises, institutions, and end users, providing different access permissions to different types of users. It stores CA certificates and CRLs for users to download. It also stores trusted business cards and trusted business card cancellation lists published by enterprises and institutions for users to download.

[0085] (4) Carrier communication network: Provides VoIP voice call communication network for end users and supports SIP call protocol.

[0086] (5) Caller Terminal APP: Deployed on the caller's mobile terminal, it downloads the user's trusted business card from the directory server and displays the business card when making a call.

[0087] (6) Called terminal APP: Deployed on the called user's mobile terminal, it downloads digital certificates, CRLs, trusted business card cancellation information, etc. from the directory server to verify and display the caller's trusted business card.

[0088] In summary, the trusted business cards in this system are issued independently by enterprises and institutions, which can be adjusted in a timely manner for employee departures and job changes, and can better guarantee the authenticity of incoming business cards. It has better autonomy and flexibility. In addition, with the endorsement of the enterprise or institution, it is easier to hold people accountable in the event of telecommunications fraud or other incidents.

[0089] On the other hand, the present invention also discloses a method for receiving calls from trusted business cards, such as... Figure 2 As shown, it includes the following steps:

[0090] L1. Application for Digital Certificates for Enterprises and Institutions: The personnel in charge of enterprises and institutions submit the organization's information to an authoritative CA institution to apply for an organizational digital certificate.

[0091] L2. Issuance of Digital Certificates for Enterprises and Institutions: After reviewing the information of enterprises and institutions, the CA (Certificate Authority) issues digital certificates to them. These certificates can be stored on a USB key and provided to the personnel in charge of the enterprise or institution. The CA also periodically publishes the digital certificates of revoked organizations to the directory server to accommodate situations such as the withdrawal or closure of enterprises and institutions.

[0092] Specifically, the directory organization of the directory server is as follows: Figure 3 As shown, the directory server is based on LDAP technology (IETF RFC 4511 standard), and its directory includes two second-level directories:

[0093] The sub-entries of the "dc=TrustCAs" directory are the various trusted Certificate Authorities (CAs). The RDN of a CA entry must be the same as the subject of the CA certificate. The cACertificate attribute value of a CA entry is the CA certificate, and the certificateRevocationList attribute value of a CA entry is the CRL issued by the CA.

[0094] The sub-entries of the "dc=Organization" directory are the issuing organizations of each Trusted Business Card. The RDN of each Trusted Business Card issuing organization entry includes a `serialNumber` field and an `o` field. The value of the `serialNumber` field is the Unified Social Credit Code of the enterprise / organization, and the value of the `o` field is the name of the enterprise / organization. The `userCertificate` attribute of each Trusted Business Card issuing organization entry contains the public key certificate used for signing by that enterprise / organization, and the `attributeCertificateRevocationList` attribute contains the revocation list of Trusted Business Cards issued by that enterprise / organization (i.e., the revocation list of attribute certificates). Additionally, the sub-entries of the Trusted Business Card issuing organization entries are the organization's employees. The RDN of each employee entry includes a `telephoneNumber` field, whose value is the employee's mobile phone number. The `attributeCertificate` attribute of each employee entry contains their Trusted Business Card. Multiple `attributeCertificate` attributes can be used to store multiple Trusted Business Cards for the same employee, accommodating situations where an employee has multiple job roles.

[0095] The table below summarizes the organization of the directory:

[0096]

[0097]

[0098] The user roles of a directory server include: system administrator, CA (Certificate Authority), enterprise / institution, calling user, and called user.

[0099] The directory access permissions are shown in the table below:

[0100]

[0101]

[0102] Where: S: Search to search and read this entry; A: Add to add this entry; D: Delete to delete this entry; M: Modify to modify the attributes of this entry.

[0103] L3. Credible Card Generation: Personnel in enterprises and institutions enter employee information into the credible card issuance system, generate a vCard, and sign it using the organization's digital certificate private key to ensure the integrity and non-repudiation of the vCard information. The signed vCard looks like... Figure 4 As shown, a custom key extension vCardExt is added to the attribute certificate (abbreviated as "AC", X.509 standard) to store vCard information.

[0104] Furthermore, such as Figure 4 As shown, the Trusted Business Card is an attribute certificate (X.509 standard) issued by an enterprise or institution using its private key for a signature certificate. The holder of the attribute certificate is selected as `entityName`, with the name as shown in the RDN of an employee entry on a directory server, formatted as "telephoneNumber = mobile phone number". The issuer of the attribute certificate is selected as `issuerName`, formatted as shown in the RDN of the issuing unit entry on the Trusted Business Card, formatted as "serialNumber = Unified Social Credit Code, o = unit name". The signature algorithm of the attribute certificate is set based on the key of the unit's signature certificate. The `serialNumber` of the attribute certificate uses a 20-byte random number and is guaranteed to be unique within the same unit. The validity period of the attribute certificate is set by the unit's operators based on the employee's potential employment time. Optional attributes of the attribute certificate are empty.

[0105] Trusted business cards are primarily based on the above attribute certificates, with the addition of a vCardExt extension. The object identifier (OID) of vCardExt can be obtained from INNA. As a crucial extension, the value of vCardExt is composed of vCard (IETF RFC6350 standard). The NICKNAME attribute of vCard contains the caller's title, the PHOTO attribute contains the caller's photo, the TEL attribute contains the caller's mobile phone number, the TITLE attribute contains the caller's job role (e.g., "General Manager," "Sales Consultant," etc.), and multiple job roles can be entered. The LOGO attribute contains the organization logo, the ORG attribute contains the organization name, and so on. Enterprises and institutions can add or delete attributes as needed when issuing trusted business cards.

[0106] Finally, the signature value of the attribute certificate is calculated according to the attribute certificate standard.

[0107] In summary, by using the vCard standard format to generate standard business cards in the trusted business card generation process, it is possible to better support existing mobile terminal applications, directly export and import from the address book, and directly call Android and iOS APIs to process vCards, thereby improving user experience and enhancing the adaptability of the system and terminal ecosystem.

[0108] L4. Trusted Business Card Issuance: The trusted business card issuance system creates a directory for the organization on the directory server. The directory name matches the unified social credit code and organization name in the subject of the organization's digital certificate. The issued trusted business cards are then published to this directory. The trusted business card issuance system also publishes a list of revoked trusted business cards (attribute certificate revocation list, X.509 standard) to the directory server to accommodate employee job changes, departures, and other similar situations.

[0109] L5. Downloading Trusted Business Card: The calling user opens the APP, enters the name of the enterprise or institution or unified social credit code, and the user's mobile phone number on the interface, completes SMS authentication, and downloads the CA certificate, the enterprise or institution's digital certificate, the trusted business card corresponding to the mobile phone number, CRL and other information from the directory server.

[0110] The authentication methods for each user role on the directory server are shown in the table below:

[0111]

[0112] Anonymous or password-based authentication can use LDAPSimple authentication. For secure password transmission, StartTLS or LDAPS can be enabled. Digital certificate-based authentication can use client certificate authentication via StartTLS or LDAPS.

[0113] For authentication via mobile SMS, the SASL (Simple Authentication Security Layer, IETF RFC 4422) authentication extension of LDAP can be used. Here, a "SASL-SMS" authentication mechanism is designed, and the authentication process is as follows:

[0114] (a1) The user enters the organization name and mobile phone number, and sends a BindRequest through the client. The name field is "telephoneNumber = mobile phone number, o = organization name". The authentication field uses SASL, and the mechanism field of SASL is "SASL-SMS mechanism". SASL does not need to include the credentials field.

[0115] (a2) The server searches for the entry in the directory based on the company name and mobile phone number sent by the client. If the entry does not exist, it returns a BindResponse to the client with a resultCode of noSuchObject error, and the process ends. If the entry exists, it sends an SMS authentication code and returns a BindResponse to the client with a resultCode of saslBindInProgress.

[0116] (a3) When the user receives the SMS verification code, he sends a BindRequest through the client. The name field is “telephoneNumber = mobile phone number, o = company name”, the authentication field is SASL, the mechanism field of SASL is “SASL-SMS”, and the credentials of SASL is the SMS verification code entered by the user.

[0117] (a4) The server searches for the entry in the directory based on the company name and mobile phone number sent by the client. If the entry does not exist, it returns a BindResponse to the client with a resultCode of noSuchObject error, and the process ends. If the entry exists, it compares the SMS authentication code. If the comparison fails, it returns a BindResponse to the client with a resultCode of invalidCredentials, and the process ends. If the SMS authentication code comparison is successful, the resultCode is success, and authentication is successful.

[0118] The above process authenticates the calling terminal, ensuring it can only download the calling user's trusted business card and not other trusted business cards, effectively protecting the sensitive information of enterprises, institutions, and other users.

[0119] L6. Installation of Trusted Business Card: The calling terminal APP verifies the trusted business card based on the CA certificate, enterprise / institution digital certificate, CRL information, etc., and installs it on the terminal after successful verification.

[0120] L7. Trusted Business Card Call Process: During business communication, the calling user selects the trusted business card to be displayed on the APP and dials. The calling terminal APP adds the TrustedVCard parameter to the Call-Info header field of the SIP protocol INVITE message, writing the Base64 encoded trusted business card into this parameter value. If the telecom operator's SIP protocol cannot support such a large header, only the trusted business card serial number can be transmitted, and the TrustedVCardSN parameter can be transmitted through the SIP header to the called terminal as authentication information. After authentication by the directory server, the called terminal APP downloads the trusted business card from the calling terminal.

[0121] Specifically, the transmission process based on the trusted business card serial number includes:

[0122] (b1) The calling terminal reads the serial number of the trusted business card to be transmitted, and then presses... Figure 5 In the format shown, add these parameters to the Call-Info header field of the INVITE message: "telephoneNumber = mobile phone number, o = company name, TrustedVCardSN = trusted business card serial number HEX encoding;".

[0123] (b2) The called terminal APP obtains “telephoneNumber = mobile phone number, o = company name, TrustedVCardSN = trusted business card serial number HEX code” from the INVITE message, and uses “telephoneNumber = mobile phone number, o = company name” as the username and the trusted business card serial number HEX code as the password to authenticate with the directory server.

[0124] (b3) The directory server retrieves the caller's trusted business card (i.e., attribute certificate) based on "telephoneNumber = mobile phone number, o = company name", reads its serial number, and compares it with the called terminal's password. If they match, the trusted business card is returned. If they do not match, an invalidCredentials error is returned.

[0125] (b4) If the called terminal APP receives an invalidCredentials error from the directory server, it will indicate that the trusted business card acquisition failed and prompt the user whether to answer the call. If it receives a trusted business card from the directory server, the process proceeds to the next step.

[0126] It should be noted that the transmission process of this trusted business card serial number involves authenticating the called terminal, ensuring that it can only download the caller's trusted business card and not other trusted business cards, thus effectively protecting the sensitive information of enterprises, institutions, and other users.

[0127] L8. Initial Local Verification of Trusted Business Card: The called terminal APP receives the trusted business card transmitted by the calling terminal APP, in the following format: Figure 4 As shown. The caller's mobile phone number can be obtained from the trusted business card and then compared with the incoming call number in the SIP call. If the comparison fails, it means the trusted business card is invalid, and the called terminal's app will display "Invalid Trusted Business Card," leaving the called user to decide whether to answer the call. If the comparison succeeds, proceed to the next step.

[0128] L9. Download Trusted Business Card Verification Information: The called terminal APP downloads information such as CA certificate, CRL, digital certificate of the enterprise or institution to which the trusted business card belongs, and trusted business card cancellation list from the directory server.

[0129] L10. Trusted Business Card Verification: The called party's app uses the trusted business card verification information downloaded through the above steps to verify the card's validity period, the validity of the enterprise / institution's signature, the validity of the enterprise / institution's certificate, and whether the CA institution is in the app's root of trust (or was issued by the root of trust). If all verifications pass, the trusted business card is valid, displaying the cardholder's photo, company logo, company name, personal title, job title, etc., awaiting the called party's response. If verification fails, the trusted business card is displayed as invalid, and the called party decides whether to answer.

[0130] Specifically, during the verification process, after the called terminal receives the caller's trusted business card from the SIP call or downloads it from the directory server, it needs to verify the validity of the trusted business card through the following steps:

[0131] (c1) Preliminary Local Verification: Obtain the validity period from the trusted business card (i.e., the attribute certificate). If the current time is not within its validity period, verification fails. Obtain the vCard from the vCardExt extension of the attribute certificate. Obtain the caller's mobile number from the TEL attribute of the vCard, and compare it with the caller's number in the SIP call and the mobile number of the holder in the attribute certificate. If they do not match, verification fails. Check if the ORG attribute of the vCard and the organization name of the issuer in the attribute certificate are consistent. If they do not match, verification fails.

[0132] (c2) Downloading verification information such as certificate chains and revocation lists: Based on the unified social credit code and organization name of the issuer in the attribute certificate, download the organization's signature certificate and trusted business card revocation list (attribute certificate revocation list) from the directory server. Read the CA certificate and CRL from the cache or download them from the directory server based on the issuer of the organization's signature certificate. Verify that the downloaded CA certificate was issued by the root trust pre-installed in the called terminal APP; if not, verification fails.

[0133] (c3) Verification of signature certificates for enterprises and institutions: Based on the X.509 public key certificate verification standard, the signature certificate of the unit is verified according to the CA certificate, CRL, etc. If not all of them are satisfied, the verification fails.

[0134] (c4) Trusted Business Card (Attribute Certificate) Verification: Based on the X.509 attribute certificate verification standard, the attribute certificate is verified according to the organization's signature certificate, the trusted business card cancellation list (attribute certificate cancellation list), etc. If not all of them are satisfied, the verification fails.

[0135] (c5) Display of Trusted Business Card: After all the above verifications are passed, based on the information in vCard, the caller's trusted business card avatar, company logo, company name, personal title, job position, and other information will be displayed, and the caller will wait to answer.

[0136] In summary, the method proposed in this application does not require the calling and called terminals to store public and private key pairs, and does not require the deployment of a cryptographic module, resulting in lower implementation and management costs. Furthermore, based on attribute certificates, public key certificates, and LDAP directory servers, it can better utilize existing products, testing tools, and open-source code, thereby reducing development costs.

[0137] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform certain steps of a designated module system of any of the trusted business card call systems described in the above embodiments or a portion of a trusted business card call method described in the above embodiments.

[0138] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs certain steps of a designated module system of any of the trusted business card call systems described in the above embodiments or a portion of a trusted business card call method described in the above embodiments.

[0139] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute a designated module system of any of the trusted business card call systems in the above embodiments or a portion of the steps in any of the trusted business card call methods in the above embodiments.

[0140] It is understood that the system provided in the embodiments of the present invention corresponds to the method provided in the embodiments of the present invention, and the explanation, examples and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0141] The communication bus mentioned in the above-mentioned electronic devices can be a standard bus for interconnecting peripheral components or an extended industrial standard structure bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0142] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0143] The memory may include random access memory or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0144] The processors mentioned above can be general-purpose processors, including central processing units, network processors, etc.; they can also be digital signal processors, application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0145] It should also be noted that electronic devices include terminal devices, which can also be called terminals, user equipment, mobile stations, mobile terminals, etc. Terminal devices can be mobile phones, smart TVs, wearable devices, tablets, computers with wireless transceiver capabilities, virtual reality terminal devices, augmented reality terminal devices, wireless terminals in industrial control, wireless terminals in autonomous driving, wireless terminals in remote surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, and so on. The embodiments of this application do not limit the specific technologies or device forms used in the terminal devices.

[0146] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium, etc.

[0147] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0148] Furthermore, it should be noted that if the embodiments of the present invention involve directional indication, the directional indication is only used to explain the relative positional relationship and movement of the components in a specific posture. If the specific posture changes, the directional indication will also change accordingly.

[0149] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, in the embodiments of this invention, "multiple" refers to two or more. Moreover, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

Claims

1. A trusted business card call system, characterized by, The application comprises: an electronic authentication module for issuing digital certificates for enterprises and institutions with first users; a business card issuing module for editing and exporting a vCard format file of the first user's business card information, signing the first user's vCard format file of the business card using the private key of the enterprise and institution digital certificate to obtain a trusted business card, and publishing the trusted business card to a directory server for downloading by a calling terminal; a calling terminal bound to the first user and a called terminal bound to a second user; a directory server for authenticating other system structures and providing specified access rights to the calling terminal and the called terminal, for downloading the trusted business card by the calling terminal and verifying the trusted business card by the called terminal; the calling terminal connects the called terminal through a VoIP voice communication network, and downloads the trusted business card of the first user from the directory server for transmission to the called terminal for display; the directory server is based on LDAP technology to construct a three-level directory system, comprising: a 'dc=TrustCAs' secondary directory under the root directory, whose sub-entry is each trusted CA institution in the electronic authentication module, the RDN of the CA institution entry is consistent with the CA certificate subject, and the CA institution entry contains the CA certificate and the digital certificate revocation list attribute; a 'dc=Organization' secondary directory under the root directory, whose sub-entry is each trusted business card issuing enterprise and institution, the RDN of the enterprise and institution entry comprises'serialNumber=enterprise and institution unified social credit code' and 'o=enterprise and institution name', and the enterprise and institution entry contains the enterprise and institution digital certificate and the trusted business card revocation list attribute; the sub-entry of the enterprise and institution entry is the employees of the enterprise and institution, and the RDN of the employee entry is 'telephoneNumber=employee mobile phone number', and the employee entry contains the employee trusted business card attribute; the directory server only opens the trusted business card download right of the corresponding employee entry to the calling terminal that passes the identity authentication, and only opens the verification information download right of the enterprise and institution entry of the calling party to the called terminal, including the CA certificate, the enterprise and institution digital certificate, and the digital certificate revocation list; before the calling terminal is bound to the first user, identity authentication and binding are completed, and after the binding, the calling terminal can only download the trusted business card under the employee entry and the corresponding verification file from the directory server, and the verification file comprises the CA certificate of the electronic authentication module, the enterprise and institution digital certificate, the digital certificate revocation list, and the trusted business card revocation list; the identity authentication and binding comprises: the first user inputs 'enterprise and institution name + own mobile phone number' on the calling terminal, the calling terminal sends a first data request to the directory server, the directory server queries the corresponding 'enterprise and institution entry-employee entry', sends a short message verification code to the mobile phone number, the first user inputs the short message verification code, the calling terminal sends a second data request to the directory server, and the directory server verifies the consistency of the short message verification code to complete the identity authentication and binding.

2. The trusted business card call-in system of claim 1, wherein, the electronic authentication module is used to publish the CA certificate, the issued enterprise and institution digital certificate, and the digital certificate revocation list to the directory server. The name card issuing module issues the trusted name card and the trusted name card revocation list according to the employee information of the enterprise and institution, and is used to publish to the directory server; The calling terminal and the called terminal download the CA certificate, the enterprise and institution digital certificate, the digital certificate revocation list, the trusted name card and the trusted name card revocation list from the directory server, and are used to verify the first user trusted name card.

3. A method for trusted calling card calling, based on the trusted calling card calling system according to any one of claims 1-2, characterized in that, The method comprises the following steps: S1. The enterprise and institution apply for the organization digital certificate through the electronic authentication module; S2. The electronic authentication module issues the organization digital certificate after auditing the enterprise and institution information, stores the digital certificate in the usbkey key medium for the designated personnel of the enterprise and institution, and regularly publishes the issued organization digital certificate, the CA certificate of the electronic authentication module and the digital certificate revocation list to the directory server; S3. After the enterprise and institution inputs the employee information, the name card issuing module generates the vCard format file and calls the enterprise and institution digital certificate private key to sign, and issues the employee trusted name card; S4. The directory server creates the enterprise and institution directory, publishes the trusted name card issued by the enterprise and institution to the directory, and simultaneously publishes the revoked trusted name card list; S5. The enterprise and institution employee performs the identity authentication binding on the calling terminal, and downloads the CA certificate of the electronic authentication module, the enterprise and institution digital certificate, the digital certificate revocation list, the trusted name card and the trusted name card revocation list from the directory server; S6. The calling terminal verifies the trusted name card according to the CA certificate, the digital certificate revocation list, the enterprise and institution digital certificate and the trusted name card revocation list information, and installs the trusted name card after the verification is passed; S7. When the business contact is performed, the calling terminal selects the trusted name card to be displayed and performs the dialing, the calling terminal transmits the specified data to the called terminal as the authentication information, downloads the trusted name card of the calling terminal after the authentication of the directory server; S8. The called terminal obtains the trusted name card transmitted by the calling terminal, acquires the mobile phone number on the trusted name card, and compares with the calling incoming number, if the comparison is not passed, the trusted name card is invalid and is displayed on the called terminal, and then the called user decides whether to answer, if the comparison is passed, the next step is performed; S9. The called terminal downloads the CA certificate, the digital certificate revocation list, the enterprise and institution digital certificate of the trusted name card and the trusted name card revocation list from the directory server; S10. The called terminal verifies the trusted name card according to the downloaded information, when all the verifications are passed, the trusted name card is valid and the specified information of the trusted name card is displayed, and waits for the called user to answer, if the verification is not passed, the trusted name card is invalid and the called user decides whether to answer.

4. The trusted business card call method of claim 3, wherein, if the caller's telephone number is not registered in the database, the caller's telephone number is registered in the database and the caller's telephone number is transmitted to the caller's telephone number registration server. The directory server performs the short message authentication and authentication on the calling terminal, and the authentication process specifically comprises: a1. The user inputs the unit name and the mobile phone number, acquires the first data request and sends through the client; a2. The server queries the corresponding entry from the directory server directory according to the unit name and the mobile phone number in the first data request: If not, the process is ended, and the authentication failure response is directly returned to the client; If the entry exists, send the SMS authentication code to the entry mobile phone number, and then return the waiting for continuing authentication response to the client; a3. After the user receives the SMS verification code, the unit name and mobile phone number are combined, and the second data request is sent through the client again; a4. The server searches for the entry from the directory according to the unit name and mobile phone number in the second data request: If the entry does not exist, the process ends, and an authentication failure response is returned to the client; If the entry exists, compare the SMS authentication code. If the SMS authentication code comparison fails, the process ends, and an authentication failure data response is returned to the client. If the SMS authentication code comparison is successful, the authentication is successful, and a corresponding authentication success data response is returned to the client.

5. The trusted business card call method of claim 3, wherein, if the caller's telephone number is not registered in the database, the caller's telephone number is registered in the database and the caller's telephone number is transmitted to the caller's telephone number registration server. The S3 step of acquiring and generating the trusted business card includes: Based on the attribute certificate, the vCard format data is written by extending the attribute data of vCardEx, and the trusted business card is finally generated, wherein the signature value of the attribute certificate is obtained by signing the attribute certificate with the private key of the enterprise and institution digital certificate.

6. The trusted business card call-in method of claim 3, wherein, The trusted business card performs data transmission based on the serial number, and the specific process includes: b1. The calling terminal reads the serial number of the trusted business card to be transmitted, and adds a first parameter to the Call-Info header field of the INVITE message, wherein the first parameter contains the mobile phone number, the unit name, and the HEX encoding of the serial number of the trusted business card; b2. The called terminal obtains the first parameter from the INVITE message, and inputs the mobile phone number and the unit name in the first parameter as username data, and the HEX encoding of the serial number of the trusted business card in the first parameter as password data to the directory server for authentication; b3. The directory server queries the trusted business card of the calling terminal user according to the username data, and reads the serial number thereof for comparison with the password data of the called terminal. If they are consistent, the trusted business card is returned. If they are not consistent, the invalidCredentials error is returned; b4. If the called terminal receives the invalidCredentials error returned by the directory server, it prompts that the trusted business card acquisition fails. If the called terminal receives the trusted business card returned by the directory server, the process proceeds to the next step.

7. The trusted business card call-in method of claim 3, wherein, if the caller's telephone number is not registered in the database, the caller is connected to the voice mail server. The specific verification method of the called terminal for verifying the validity of the trusted business card includes: c1. Obtain the validity period of the trusted business card. If the current time is not within the validity period, the verification fails; If it is within the validity period, further obtain the vCard from the vCardExt extension of the trusted business card, obtain the mobile phone number and the unit name from the attributes of the vCard, and compare the mobile phone number in the vCard attribute with the mobile phone number of the call, and the unit name in the vCard attribute with the issuer name in the trusted business card. If any comparison result is inconsistent, the verification fails; c2. According to the unified social credit code and the unit name in the trusted business card, download the signature certificate of the enterprise and institution and the trusted business card revocation list from the directory server; According to the issuer of the signature certificate of the enterprise and institution, read the CA certificate and digital certificate revocation list from the cache or download them from the directory server; And the CA certificate is verified whether it is issued by the root of trust preset by the called terminal, if not, the verification fails; c3. Based on the specified public key certificate verification standard, the signature certificate of the enterprise and institution is verified according to the CA certificate and the digital certificate revocation list, if all the requirements cannot be met, the verification fails; c4. Based on the attribute certificate verification standard, the trusted business card is verified according to the signature certificate of the enterprise and institution and the trusted business card revocation list, if all the requirements cannot be met, the verification fails; c5. After the above verifications are passed, the specified information of the trusted business card of the calling user is displayed according to the information of the vCard, and the called user is waited to answer.

Images