System and method for secure authentication

Abstract

A system for authentication includes a validation system and an agent configured to transmit a first credential indicative of an identity to the validation system and to transmit a second credential indicative of the identity to a verification service. The validation system includes a database configured to store authorized user data and a portal configured to provide a selection of a verification service from a plurality of verification services. The validation system is configured to compare the first credential to the authorized user data, determine a confidence level of a validity of the identity based on the comparison of the first credential to the authorized user data, receive a verification of the second credential from the verification service, and modify the confidence level based on the verification.

Description

Technical Field

[0001] This disclosure relates generally to systems and methods for authentication, and more specifically to secure authentication for detecting deepfakes. Background Technology

[0002] As cyberattacks become more frequent and sophisticated, cybersecurity remains a critical aspect of the digital world. These attacks can leverage artificial intelligence (AI) to create deepfakes that persuade unsuspecting victims to send money or grant access to critical systems. Once access to these systems is granted, data is stolen and sold, often leading to the implementation of ransomware.

[0003] Conventional multi-factor authentication methods may be vulnerable to attacks based on quantum computing. Quantum computing is considered a potential risk to typical cryptographic systems because quantum computers have the potential to efficiently solve certain mathematical problems that form the basis of widely used cryptographic algorithms. For example, typical public-key cryptography schemes may rely on factoring large numbers or solving mathematical problems that, while challenging for classical computing systems, can still be solved by quantum computing systems.

[0004] The challenges posed by quantum computing to the security of cryptographic schemes can be demonstrated in various ways related to communication platforms, such as teleconferencing software, email, and instant messaging applications. For example, deepfake technology has made significant strides in its capabilities and potential impact. These sophisticated AI-driven algorithms can manipulate or synthesize media content, primarily images and videos, to create highly realistic simulations of individuals, events, or scenes. Deepfakes allow for the seamless integration of people into fictional environments, capable of mimicking anyone's voice and / or appearance. Furthermore, recent advancements have allowed these techniques to be used with a single computer, eliminating the need for massive computing fields to render complex computer graphics. Deepfake technology is now widely available and very cost-effective.

[0005] The misuse of deepfake technology for malicious purposes, such as spreading disinformation, fabricating evidence, or manipulating public opinion, poses a significant threat to society. As deepfakes become increasingly realistic and harder to detect, the risk of causing chaos, confusion, and harm also increases. Furthermore, there is growing concern about privacy violations, as individuals' identities can be convincingly replicated without their consent, making them targets for attacks. Addressing these challenges requires a multifaceted approach, including robust detection mechanisms, clear regulations, and increased public awareness.

[0006] The emergence of deepfake technology has also brought worrying risks to the phishing industry, making such scams more sophisticated and dangerous. With the ability to convincingly mimic someone's voice or appearance, malicious actors can now create highly realistic audio or video messages to trick targets into revealing sensitive information, such as login credentials or financial details. As a result, phishing attacks are becoming more personalized, tailored to individual trust levels, and manipulating victims into taking actions they wouldn't otherwise take. The increased realism of deepfake technology poses a significant challenge to traditional security measures, as people may find it increasingly difficult to distinguish between genuine and manipulated content, thus becoming victims of these cunning scams. Consequently, the likelihood of reputational damage, fraud, or theft is now greater than ever before. More importantly, the possibility of infiltrating critical infrastructure to gain access to financial, energy, government, or military systems is increasingly prominent.

[0007] To combat rampant theft and / or fraud, many FedWire transfers now require verbal verification, as numerous financial institutions have fallen victim to fraud. Individuals, banks, title companies, real estate investment trusts (REITs), and lenders have all suffered billions of dollars in fraudulent losses by sending wire transfers to imposters. Now, with the emergence of increasingly sophisticated AI and deepfake technologies, solutions are needed to help verify the identity of trusted parties. In particular, with Zelle... ® PayPal ® FedNow ® With the emergence of other forms of digital instant transfers, including fiat and cryptocurrency, a large number of transactions occur continuously 24 hours a day, 7 days a week, without human supervision.

[0008] Imagine a phone or video conference where one participant is talking to another; needing to pause the conversation to verify the other person's identity could lead to an awkward situation. Therefore, technological solutions are needed to address advancements in deepfake techniques that surpass currently used two-factor authentication schemes. Without additional security measures, out-of-band authentication using private-public key encryption may not be post-quantum secure, and it may be too cumbersome to be used seamlessly and transparently. Attempting to leverage existing two-factor authentication methods would be cumbersome, and currently, there are no contract management mechanisms available. Summary of the Invention

[0009] According to one aspect of this disclosure, a system for authentication includes an authentication system and an agent configured to transmit a first credential indicating an identifier to the authentication system and a second credential indicating the identifier to an authentication service. The authentication system includes a database configured to store authorized user data and a portal configured to provide selection of an authentication service from a plurality of authentication services. The authentication system is configured to: compare the first credential with the authorized user data; determine a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data; receive verification of the second credential from the authentication service; and modify the confidence level based on the verification.

[0010] According to one aspect of this disclosure, a method for authentication includes: selecting an authentication service from a plurality of authentication services separate from the authentication system via a portal of the authentication system; receiving a first credential indicating an identifier from an agent at the authentication system; comparing the first credential with authorized user data stored in an authorized user database; determining a confidence level of the validity of the identifier based on the comparison between the first credential and the authorized user data; transmitting a second credential indicating the identifier from the agent to the authentication service; receiving verification of the second credential via the authentication service; and modifying the confidence level based on the verification.

[0011] According to one aspect of this disclosure, a method for authentication includes: selecting an authentication service from a plurality of authentication services; receiving a first credential indicating an identifier from an agent at an acknowledgment system; comparing the first credential with authorized user data; determining a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data; transmitting a second credential indicating the identifier to the authentication service; receiving verification of the second credential from the authentication service; and modifying the confidence level based on the verification.

[0012] According to one aspect of this disclosure, a system for authentication on a communication platform includes: a database configured to store authorized user data; a first node that creates and is configured to transmit identifiers; and at least one second node configured to receive identifiers, compare the identifiers with the authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. A user interface is configured to present an indication of the confidence level in response to the signal.

[0013] According to one aspect of this disclosure, a system for authentication on a communication platform includes: a database configured to store authorized user data; a first node configured to transmit an identifier and credentials to an authentication service; at least one second node configured to receive the identifier, compare the identifier with the authorized user data, determine a confidence level for the first node, receive authentication from the authentication service based on credentials, update the confidence level based on the authentication, and transmit a signal indicating the confidence level; and a user interface configured to present an indication of the confidence level in response to the signal.

[0014] According to one aspect of this disclosure, a system for authentication includes an authentication system and an agent configured to transmit a first credential indicating an identifier to the authentication system and a second credential indicating the identifier to an authentication service. The authentication system includes a database configured to store authorized user data and a portal configured to provide selection of an authentication service from a plurality of authentication services. The authentication system is configured to: compare the first credential with the authorized user data; determine a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data; receive verification of the second credential from the authentication service; and modify the confidence level based on the verification.

[0015] According to one aspect of this disclosure, a system for authentication on a communication platform includes: a database configured to store authorized user data; a first node that creates an identifier and is configured to transmit the identifier; at least one second node configured to receive the identifier, compare the identifier with the authorized user data, determine a confidence level of the first node, and transmit a signal indicating the confidence level; and a user interface configured to present an indication of the confidence level in response to the signal.

[0016] According to one aspect of this disclosure, a system for authentication on a communication platform includes a database configured to store authorized user data. The system includes a first node that creates identifiers and is configured to transmit the identifiers. At least one second node is configured to: receive the identifiers, compare the identifiers with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0017] According to another aspect of this disclosure, a method for performing identity authentication on a communication platform includes: transmitting an identifier to at least one second node via a first node; receiving the identifier at at least one second node; comparing the identifier with authorized user data stored in a database storing authorized user data; determining a confidence level of the first node; transmitting a signal indicating the confidence level; and presenting an indication of the confidence level at a user interface in response to the signal.

[0018] According to another aspect of this disclosure, a system for authentication on a conferencing platform includes a database configured to store authorized user data. The system includes a first node that creates identifiers and is configured to transmit the identifiers. The system includes at least one second node configured to: receive the identifiers, compare the identifiers with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0019] According to another aspect of this disclosure, a system for authentication on an email communication platform includes a database configured to store authorized user data. The system includes a first node that creates an identifier and is configured to transmit the identifier. The system includes at least one second node configured to: receive the identifier, compare the identifier with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0020] According to another aspect of this disclosure, a system for identity authentication includes a database configured to store authorized user data. The system includes a first node that creates an identifier and is configured to transmit the identifier. At least one second node is configured to: receive the identifier, compare the identifier with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0021] These and other features, advantages and objectives of this disclosure will be further understood and appreciated by those skilled in the art upon reference to the following description, claims and drawings. Attached Figure Description

[0022] In the attached diagram: Figure 1 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 2 This is a process diagram of an authentication system constructed according to one aspect of this disclosure; Figure 3This is a functional block diagram demonstrating an example of post-quantum secure authentication for a conference application that utilizes spectral verification; Figure 4 This is an exemplary interface of video conferencing software that employs an authentication system; and Figure 5 This is a flowchart illustrating how an exemplary node is classified as trusted or untrusted using an authentication system constructed according to one aspect of this disclosure; Figure 6 It is an email interface of a quantum-safe authentication system combined with one aspect of this disclosure; Figure 7 This is a flowchart of a post-quantum-safe authentication method executed by an authentication system; Figure 8 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 9 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 10 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 11 It is an exemplary administrator portal that demonstrates the authentication of nodes in the tracking and authentication system; Figure 12 This is an example administrator portal showcasing a virtual marketplace for third-party verification services; Figure 13 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 14 This is a functional block diagram of an authentication system constructed according to one aspect of this disclosure; Figure 15 It is a flowchart of the method used for authentication performed by the authentication system; Figure 16 This is a functional block diagram of an integrated learning module adopted by an authentication system according to one aspect of this disclosure; Figure 17 This is an exemplary interface of video conferencing software that employs an authentication system; and Figure 18 This is an example interface of email software that uses an authentication system.

[0023] The components in the accompanying drawings are not necessarily drawn to scale, but rather to illustrate the principles described herein. Detailed Implementation

[0024] The embodiments illustrated herein primarily consist of combinations of method steps and apparatus components related to certification. Therefore, where appropriate, apparatus components and method steps have been indicated in the accompanying drawings using conventional symbols, showing only those specific details relevant to understanding the embodiments of this disclosure, so as not to obscure the disclosure with details obvious to those skilled in the art who benefit from the description herein. Furthermore, the same numerals in the description and drawings denote the same elements.

[0025] The terms “comprising,” “including,” “containing,” or any other variation thereof are intended to cover non-exclusive inclusion, such that a process, method, article of manufacture, or apparatus that includes a list of elements may include not only those elements but also other elements not expressly listed or inherent to such process, method, article of manufacture, or apparatus. An element beginning with “comprising…” does not exclude the presence of additional identical elements in the process, method, article of manufacture, or apparatus that includes that element, unless further constraints are imposed.

[0026] Generally see Figures 1 to 7 Reference numeral 10 in the accompanying drawings typically denotes a system for identity authentication on a communication platform. The authentication system 10 executes various processes for authenticating nodes on a network using the communication platform. System 10 thus provides enhanced security features that limit the success rate of attacks launched by quantum computing devices that use quantum mechanics to perform certain types of computations more efficiently than classical computers. System 10 and the processes also provide a discreet and convenient notification mechanism to deliver instructions for user authentication. System 10 also provides enhanced authentication confirmation via blockchain technology. The system 10 and methods described herein can be configured for any application or website, providing a certificate authority for a variety of uses. Furthermore, the authentication system 10 can act as a non-repudiation aggregator to detect and identify deepfake attacks. The authentication system can be integrated into communication systems (e.g., business communication systems) to provide visual indications of threats.

[0027] Continue to refer to Figures 1 to 15 According to one aspect, a system 10 for authentication on a communication platform includes a database 12 configured to store authorized user data. The system 10 also includes a first node that creates identifiers and is configured to transmit the identifiers. At least one second node is configured to: receive the identifiers, compare the identifiers with authorized user data, determine the confidence level of the first node, and transmit a signal indicating the confidence level. A user interface 42 is configured to present an indication of the confidence level in response to the signal. The at least one second node may comprise a single node or multiple second nodes, such that processes performed by the at least one second node can be distributed across several nodes. The database 12 may be remote or local (e.g., on a smartphone or a local computer).

[0028] Generally, the computing equipment on the authentication device can act as one or more nodes. For example, smartphones, tablets, computers, etc., can transmit information within the authentication system 10 to prove, verify, and / or confirm user information. For instance, a first user 22 can run authentication software on the smartphone and / or computer used by the user, and a second user 24 can do the same. During or before communication between the first user 22 and the second user 24 (e.g., email, audio, video), the authentication software can create security tokens for verification using audio data, video data, IP address information, or other stored information accessible on the authentication system 10.

[0029] For example, the first node and at least one second node can each have dual functionality, enabling each of the first and second nodes to operate to authenticate and verify other nodes of the authentication system 10. For instance, each user can have an audio fingerprint, or a pass key, or other security token, which can be compared with tokens (e.g., authorized user data) stored on database 12 to verify the user's identity and / or validity.

[0030] It should be understood that the authentication created, proved, verified, and / or confirmed can be in-band or out-of-band relative to the channel utilized by the communication platform. For example, social network profiles, IP addresses, device manufacturing identifiers, or other out-of-band information can be used for comparison with authorized user data. Authentication can also or alternatively employ multi-factor authentication. Authentication can also or alternatively employ out-of-band token exchange not via the same communication channel employing Public Key Infrastructure (PKI). The user's audio signature on the communication platform can be compared with the user's voice information during or before the conference interaction (e.g., at the start of a virtual conference). By enabling in-band and out-of-band verification methods, authentication system 10 can provide multiple options for authentication methods and generate confidence levels based on the authentication level or type utilized.

[0031] As will be further described with reference to the foregoing figures, signature verification and data exchange can occur between the authenticator 16 of the authentication system 10 and the user equipment. Once the user equipment / node has been verified with a valid signature, data exchange can take place between the user equipment and the authenticator 16. Data exchange can include various types of identification information, including location information, endpoint verification information, voice information, video information, or any other authentication factors described herein for node verification. Data exchange can be checked by the authenticator 16 by comparing the information with secure user information from internal or external sources. For example, and as will be further described herein, the authenticator 16 can communicate with third-party expert services that provide additional or supplementary verification of credentials from the user equipment. Thus, system 10 can interact with other verification systems (e.g., software applications) designed to detect deepfakes of one or more specific parameters (e.g., voice, location, call history) that the third-party service is adept at.

[0032] It should also be understood that, although configured to use blockchain for confirmation, the confirmer 16 may additionally or alternatively include other forms of confirmation, including Ethereum Name Service (ENS), decentralized identity (DID) system, verifiable data structure, claimant model, certificate transparency, or any other verification service.

[0033] Special Reference Figure 1 The authentication system 10 includes a network 14 of verifiers 16 that interact with one or more authenticators 18. Authenticators 18 may include authentication software, such as a plug-in (client) for host software operating on a computing device, which interacts with one or more functions of the host software. For example, the host software may be an email application / platform, conferencing software (e.g., video conferencing software, audio conferencing software), or another communication software configured to accept authentication clients. For example, an application programming interface (API) may be provided for the video conferencing software to allow data exchange and programming of additional functions. Therefore, authenticators 18 may be installed in nodes such as mobile devices 28 or computers 30 and generate post-quantum secure proofs. The post-quantum secure proofs are transmitted to one or more of the verifiers 16 or devices (e.g., mobile devices 28 / computers 30) that verify the proofs. Verifiers 16 are also configured to verify proofs / authentications by participating in blockchain 20, as described below. Figure 2 Further description. Reference Figures 8 to 12 Another example of how to implement the confirmer 16 in system 10 is presented.

[0034] Authentication can be accomplished via zero-knowledge proofs (ZKPs) created by the authenticator 18. In some examples, ZKPs can be combined with PKI. A ZKP proof is a mechanism for proving that one party knows a piece of information without revealing what the information is. Authentication using ZKP is a convenient way for one party (called the prover) to prove its claimed identity to another party (called the verifier) ​​without sharing any information about that party. This is achieved by performing a series of mathematical calculations that allow the prover to convince the verifier of its authenticity without revealing the underlying data or secrets.

[0035] The ZKP employed by System 10 utilizes post-quantum-safe mathematical models to generate proofs. For example, ZKP can leverage lattice-based cryptography to solve difficult lattice problems, such as the fault-tolerant learning (LWE) problem involving finding hidden vectors given noisy linear equations. In some examples, ZKP utilizes one or more other quantum-resistant modeling techniques, such as Merckle signatures and the McEliece cryptosystem. In general, the ZKP used by authentication system 10 is post-quantum-safe to limit or resist attacks by quantum computing systems that utilize qubits to break classical cryptographic algorithms.

[0036] In one example, post-quantum secure authentication employs a multinomial commitment scheme. In this example, the prover (e.g., the submitter) submits a multinomial without revealing its coefficients. The commitment serves as a way to publicly demonstrate a commitment to a particular multinomial while maintaining the secrecy of the multinomial's details. For example, the multinomial's coefficients can be hidden, and such coefficients can be secret to the verifier, making the message difficult to decrypt via quantum or classical computing without them.

[0037] In some examples, ZKP stands for Zero-Knowledge Scalable Transparent Knowledge Proofs (ZK-STARK). ZK-STARK is designed to be efficient and scalable for handling large amounts of data quickly and effectively. ZK-STARK provides scalability, meaning that the size of the proof remains constant even as the complexity of the statements being proven increases. Furthermore, ZK-STARK provides computation beyond the blockchain20, such as providing computation for users of authentication applications on mobile devices28 or computers30, thus offering efficient data processing. Scalability is achieved through advanced mathematical techniques, including the use of error-correcting codes, polynomial commitment schemes, and algebraic geometry. A key feature of ZK-STARK is its transparency, allowing anyone to publicly verify the validity of proofs without relying on the trust of a central authority. The applications of ZK-STARK extend to various fields, including blockchain20 technologies, where they enhance privacy, transparency, and efficiency. By leveraging the principles of zero-knowledge cryptography, ZK-STARK contributes to the development of secure and privacy-preserving systems for the digital age.

[0038] ZK-STARKs have applications in various fields such as Blockchain 20 and cryptocurrencies, where they can enhance privacy, security, and efficiency. For example, they can be used to verify transactions and smart contracts without revealing sensitive information about the parties involved or the actual details of the transaction. More importantly, ZK-STARKs are considered resilient to quantum computing due to their underlying cryptographic properties. Quantum computing is a type of computation that uses quantum mechanical phenomena to perform calculations. It has the potential to solve certain complex problems faster than classical computers, which could impact traditional cryptographic systems used to protect data and transactions. One of the key cryptographic properties that makes zero-knowledge proofs, including Stark, resilient to quantum computing is through the use of "trapdoor functions" or "one-way functions." These functions are mathematical functions that are easy to compute in one direction but difficult to reverse (compute in the opposite direction) without some secret information called a trapdoor or private key. Zero-knowledge proofs use these trapdoor functions in a way that allows the prover to generate proofs without revealing the secret information (trapdoor). In quantum computing scenarios, if an attacker attempts to use quantum algorithms to reverse trapdoor functions and break the proof, they will still face significant challenges due to the difficulty of reversing these one-way functions. Therefore, ZK-STARK is designed to be post-quantum secure.

[0039] Stark zero-knowledge proofs have several key advantages over other PKI types: Zero knowledge – The prover does not reveal any information about the secret or the process used to prove it, except that they know the secret and that they are indeed the person they claim to be; Transparency—The generated proofs are easy to verify, meaning verifiers can quickly confirm the validity of the proofs; and Scalability – Stark is designed to efficiently handle complex computations and large amounts of data, making it suitable for real-world applications such as deepfake detection.

[0040] See now Figure 2An exemplary process is illustrated with reference to two users 22 and 24, where the first user 22 verifies their identity using one or more ZKP and multi-factor authentication methods, and the second user 24 receives a confidence level regarding the authenticity of the first user 22. In this example, the first user 22 requests access to some aspect of a communication platform (e.g., access to a virtual meeting). This request is processed by server 26, which responds with a request for credentials. The first user 22 responds with credentials, such as a login or password that can be encrypted with one or more post-quantum-secure keys. Using multi-factor authentication, server 26 responds with a request for an input private key. Although shown as an out-of-band request (e.g., to the first user 22's mobile device 28), it is conceivable that the private key request could be in-band (e.g., using the same communication channel as the credential communication). In practice, the transmission of the private key can be encrypted or otherwise secure, such that the response made by the first user 22 using the private key is post-quantum-secure (e.g., including its zero-knowledge proof).

[0041] Figure 2 The multi-factor authentication illustrated is merely exemplary and not limiting. For example, while alphanumeric codes can be transmitted to mobile device 28 for input into computer 30 of first user 22, other authentication methods may also be employed. For instance, credentials and / or private keys could be voice messages of specific words or phrases recorded or streamed by first user 22, where the private key is requested from server 26 to first user 22 rather than provided. In either example, the post-quantum-secure proof is provided by the prover (first user 22).

[0042] Although server 26 is presented as a separate module, it can be shared with confirmer 16 and transmits verification and confirmation requests to confirm the authenticity of the ZKP and perform verification. Confirmer 16 then verifies the ZKP by comparing it with authorized user data. For example, using PKI, confirmer 16 can verify the proof by solving the ZKP using existing pre-stored user information stored in database 12, which is accessible only to certification authorities. In this way, confirmer 16 can operate as a certificate authority and issue digital certificates under a PKI model that uses key pairs. Most notably, such certificates can achieve post-quantum security using ZK-STARKS. In addition to verification, confirmer 16 is also configured to confirm the ZKP on blockchain 20, which utilizes a consensus mechanism to confirm transactions (e.g., user authentication).

[0043] While any given authentication method (e.g., providing and / or verifying a ZKP schema) can operate as a binary yes / no authentication, because multiple data streams can be utilized to verify identity, the authentication system 10 can generate an overall confidence level or score and transmit it to other users concerned with the authenticity of the first user 22. For example, while geolocation verification could locate the first user 22 in Canada, the first user 22's LinkedIn profile... ® The page might indicate a work or home location in Japan (thus failing verification). However, the audio signature of the first user 22 might be a match. In this case, different data streams might be weighted more heavily than others. Therefore, the authentication system 10 can merge the verification patterns and generate a confidence level that the claimed user is indeed the first user 22. The processing of different verifications can be performed on server 26, another server, various end nodes (e.g., the user's mobile device 28 or computer 30), authenticator 16, or any other control device of the authentication system 10.

[0044] Continue to refer to Figure 2 The confidence level is transmitted to the exemplary second user 24. An authentication application (e.g., plug-in 32) running on the second user 24's computer 30 processes the confidence level and interacts with the host software to indicate the confidence level in real time. Other information, such as the location of the first user 22 or what type of verification was successful, can be provided. For example, checkboxes or red Xs indicating "IP address match," "location match," "audio match," "voice match," "image match," etc., can be displayed. Furthermore, a verification score (e.g., confidence percentage) can be displayed for each verification. In this way, the authentication system 10 can provide limited interference with user interaction.

[0045] Generally see Figure 1 and Figure 2System 10 can be configured for redundancy and is highly scalable. For example, a network 14 of confirmers 16 can be communicatively coupled to blockchain 20, allowing any confirmer 16 on network 14 to verify and / or confirm post-quantum-secure identifiers. For example, blockchain 20 allows system 10 to handle an increasing number of authentications and / or participants while maintaining consistent or reduced latency. For example, blockchain 20 can implement consensus mechanisms such as proof-of-work or proof-of-stake, which can enhance scalability by reducing the resource requirements of consensus. System 10 (e.g., by dividing blockchain 20 into smaller parts) can be implemented to allow multiple authentication transactions to occur simultaneously across multiple shards. In some examples, confirmers 16 can perform off-chain authentication verification to further enhance the scalability of system 10. Network 14 can also be configured to accept new or additional confirmers 16 to provide scalability. System 10 can provide redundancy so that if one confirmer 16 becomes inoperable or simply fails to verify a proof before another confirmer 16, other confirmers 16 on network 14 can perform confirmation / verification.

[0046] In one aspect, system 10 has federation capabilities. For example, system 10 may include federated identity providers, such as servers (e.g., server 26), which have internal ID providers (e.g., for devices on a private local area network (LAN)) and external ID providers (e.g., for devices on a public network (Internet)). Thus, the federated identity providers can distinguish between internal and external users / devices. In some examples, federation functionality allows system 10 to manage user credential verification based on a given user's classification. For example, a user accessing system 10 via a first domain may require first-level or type of credentials, and a user accessing system 10 via a second domain may require second-level or type of credentials. The federation functionality of system 10 also allows system 10 to operate with other trusted domains (e.g., some public domains). Therefore, the level or type of credentials required can depend on the domain, such that access via a public network may require different credential verification than access via a private network.

[0047] For example, three users attempt to communicate on a communication platform. The first and second users are on a private network local to System 10 or managed by that system (i.e., “dedicated users”), and the third user accesses the communication platform via a public domain. This example can be analogous to a situation where the first and second users belong to a public organization and the third user is outside that organization. In these examples, the authentication required by the third user, via the implementation of the federated identity provider, may be more stringent than that required by the first and second users. Therefore, the third user may need to provide a post-quantum-secure identity (or post-quantum-resistant identity) to access the communication platform, while the first and second users have a different level of authentication required by System 10 (e.g., a lower level). In this way, ZKP may only be needed for some users (e.g., external users or users with historically low confidence levels). Continuing this example, the confidence level may only be presented to some users on the screen (e.g., users on a private domain), and the third user may not be able to access the confidence level. Therefore, federated functionality can operate “one-way” from the perspective of one or more nodes. In this way, system 10 can be dynamic to selectively allow access to authentication information before, during, or after communication (e.g., during a virtual meeting).

[0048] In another example, the first and second users are part of a public domain (e.g., a public organization), and system 10 federates nodes of the public organization based on the security levels assigned to the users. For example, federation can selectively restrict the transmission of confidence levels based on a comparison of a user's identifier with authorized user data. Therefore, when performing a database query, system 10 can examine the requirements of each user. The selective restriction on transmitting identifiers can be partial or complete. For instance, system 10 can present the confidence levels of other users to the first user during a meeting while restricting the presentation of the first user to other users. For example, one or more second nodes (e.g., server 26, user equipment, or another node) can be configured to determine the security level corresponding to an identifier based on a comparison of an identifier with authorized user data. In this way, information about the security level of communication can be limited to some users but not others.

[0049] As an example, different federations can originate from different entities / organizations or be within a single organization for the purpose of individual employee security levels. Sharing identity information can be as simple as sharing only confidence levels (e.g., confidence scores), restricting communication to one-way confidence details (e.g., one or more users can access the security levels of other users), limited two-way communication, or completely unhindered confidence details. In one example, system 10 is configured to provide decentralized identity via sharing confidence levels and details with a different set of federated nodes.

[0050] System 10 may also include an artificial intelligence (AI) engine 828 ( Figure 13 The system 10 is configured to train at least one machine learning model using past authentications, as described with reference to the foregoing figures. The AI ​​engine 828 may reside on any node of the system, such as server 26, and is configured to train one or more machine learning models to determine the confidence level of an identity. For example, the AI ​​engine 828 may use past successful or failed authentications to weigh one or more authentication factors or credentials more or less than others. For instance, if a past identity was primarily authenticated based on IP address verification or audio verification, and then later determined to be a deepfake based on image-based verification (e.g., during a conference call), the system 10 may adjust to give image-based verification a higher weight than IP address verification or audio verification. This example is not limiting, as the model can be consistently updated to determine a reliable and fast authentication method. For example, the system 10 may have multiple models trained for a given set of users (e.g., users with a first security requirement compared to other user sets), individual user identities, a given authentication method, or any combination thereof. Therefore, the data collected and stored in database 12 or another storage device may include historical information related to successful verification methods for a specific identity, a set of categorized identities (e.g., a user with a first security permission level, a user with a second security permission level, etc.) or a specific combination of authentication methods (e.g., geolocation and IP address verification, audio and visual verification, audio and geolocation verification, etc.).

[0051] Generally, System 10 can leverage registration with a centralized, cloud, or on-premises database to enable subscription payments, audit logs, key pair backups (if permitted by company / government policy), and search functionality. Communication can be peer-to-peer (e.g., endpoint-to-endpoint). Since authentication tokens are relatively small, ranging from kilobytes to hundreds of thousands of bytes, thousands of contacts can be stored on a current mobile phone or laptop without consuming significant storage space. The database 12 (on the user's device) can be a blockchain 20, where authentication can include time, date, name, and / or location. The device can be added to blockchain 20 and used for forensic accounting that allows for unaltered data storage. Furthermore, blockchain 20 can store data in the cloud where it can be accessed anywhere (as a series of publicly available servers), or blockchain 20 can employ sharding to comply with security policies that require on-premises functionality (or organization-controlled functionality without internet access) that may reside on a dedicated computer or a series of computers, virtual machines, or application containers. This approach will serve organizations with extremely high security requirements.

[0052] The system 10 and methods described in this paper can also be applied to backing up data and auditing / logging that might otherwise be compromised or accessed. In environments requiring the highest level of security, the database 12 can be placed on one or more virtual machines or containers, rather than in the cloud (internet). Containers are standard software units that encapsulate code and all its dependencies, allowing applications to run quickly and reliably from one computing environment to another.

[0053] See now Figure 3 This example demonstrates an arrangement for providing post-quantum secure authentication using a user's audio signature verification. In this example, authenticator 18 records or streams audio data represented as an audio spectrogram 34. The audio spectrogram 34 is a visual representation of the audio, which can be provided via frequency transformation to isolate frequencies for comparison. The frequencies can be compared to authorized user data in the form of frequencies from the voice recording or predefined frequencies. In this example, predefined frequencies are transmitted (e.g., a private key) to the user's mobile device 28. Mobile device 28 includes a speaker 36 that outputs audio. The microphone 38 of the user's conferencing device 30 (e.g., a computer) receives the audio, which is read by an authenticator client installed on the conferencing device. A post-quantum ZKP is created, encrypted via encryption module 40, and transmitted to the verifier (e.g., confirmer 16 and / or server 26). Authentication system 10 can be configured to decrypt the message using post-quantum decryption via access to authorized user data (e.g., the tone transmitted to mobile device 28) to confirm that the sent tone is the same as the returned tone. In this way, audio data can be used to verify post-quantum security certifications.

[0054] It is conceivable that the authenticator 18 can periodically sample data to continuously verify users. Additionally or alternatively, audio information can be captured or streamed before initiating a conference call. The audio can include different tones or voice audio. For example, because voices tend to be varied or carry personalized rhythms, vocal ranges, or other personal audio qualities, low-key voice data sampling can be used to verify user identity for post-quantum secure authentication. As previously described, different authentication modes can be used in conjunction with this or other authentication modes to produce accurate confidence levels. It is also conceivable that the arrangement of a user's microphone 38 and speaker 36 can be modified to utilize another user's microphone 38, such that audio emitted by a user's speaker 36 can be detected remotely from the microphone 38 of the user being authenticated.

[0055] See also Figure 3In the example where the tone is generated and read from the mobile device 28 of the conference equipment itself, the audio signal may be within or outside the hearing range. For example, the audio signal may be outside the range of approximately 20 Hz to 20 kHz. For example, high-frequency audio may be output by speaker 36 (e.g., above 20 kHz). In some cases, the high frequency is below 20 kHz (e.g., 15 kHz or higher). The audio tone may also vary over time to limit the option of recording a pre-transmitted tone to deceive authentication. By providing high-frequency audio signal authentication, the meeting remains undisturbed, and authentication can be performed discreetly.

[0056] The method of authentication using spectrogram 34 can thus aid in deepfake detection. For example, system 10 can capture a short sample of audio and compare it with information in one or more databases 12. This audio fingerprint can be used to verify that the audio and / or video stream matches a scheduled meeting contact. Audio spectrogram 34 can be used as a method for in-band key exchange, such as as part of the audio and / or video stream. Furthermore, in-band or out-of-band methods for key exchange and deepfake detection can manage multiple participants who can be verified at the beginning of a streaming session or asynchronously if a static file is being reviewed.

[0057] See now Figure 4 Post-quantum security authentication is displayed via user interface 42, which is configured to present an indication of confidence level in response to verification from authentication system 10. As shown, during a video conferencing session, authentication plug-in 32 can communicate with the video conferencing software to indicate authentication information to the target user (e.g., a user using user interface 42). The indication is presented visually, but may also be audible or alternatively. In this example, a graph 44 is presented to demonstrate the possibility of authenticity via pie charts, numerical percentages, and / or other authentication factors (e.g., location, date of last verification). The specific graph 44 covering the video stream is exemplary and non-limiting. For example, flashing indicators, color changes, forced disconnections, text boxes (e.g., "Warning," "Alarm"), or other visual or auditory indications may be presented to indicate user authenticity. Thus, the confidence level can represent user authentication for the conferencing software.

[0058] Previous regarding Figure 2 and Figure 3 The described key exchange can be performed in Figure 4The events described occur simultaneously during the streaming of the teleconference. For example, each user's computer 30 can be configured to output audio tones recorded by each user's multi-factor device (e.g., mobile device 28). In this example, because a participant may be unauthenticated and potentially deepfake, the audio tones may not be output correctly or may not be output at all. In the example of audio fingerprinting, the voice of a suspicious user may be unverified, while other aspects (social media account, location, IP address, device manufacturer, operating system version / type) are correct. In this case, authentication system 10 assigns a low confidence level (30%) because system 10 can weight audio verification more heavily than aspects that can be more easily spoofed. This example is exemplary and non-limiting, allowing audio to be weighted less than other verification methods in some examples.

[0059] See also Figure 4 The post-quantum-secure identifier may include video communication via conferencing software for key exchange. For example, video data representing each user of the conferencing software may be processed by an image processor or video processor to match the user against authorized user data stored in database 12. For example, facial recognition, relative body size, or any other image-based identifier used for authentication may be used for key exchange. In this way, the verifier can verify the video data representing the user via a comparison of the post-quantum-secure identifier with authorized user data. Video / image matching may supplement or replace any of the authentication parameters described previously.

[0060] Once a node is suspected of being a deepfake, a method for tracking participants is presented to the user. An example of this process is found in systems like Zoom. ® Google Meet ® Or Microsoft Teams ® The service provides APIs to expose certain details of video conferencing. Many services have open APIs to allow access to basic call details, such as usernames, source IP addresses (since many are direct peer-to-peer communications, such as WebRTC), and in some cases even MAC addresses. By obtaining this information and running a SWIP on the IP address, system 10 can determine who owns the IP address and which part of the world it originates from. Additionally, port scanning can be performed on the IP address to determine a digital “fingerprint,” which may include the device’s brand and model, operating system, version, and the services running on the device, allowing for further forensic investigations.

[0061] See now Figure 5The authentication process 500 of the conferencing software includes installing a plug-in 32 into host software, such as a calendar application, at step 502. Plug-in 32 may include one or more parts of the authenticator 18, such as the ZKP algorithm, mechanisms for creating private keys, etc. At step 504, a meeting is scheduled with the users for authentication. At step 506, each user's authenticator 18 is confirmed by the authentication system 10 as a registered token for future authentication. Once a meeting is initiated at step 508, the software checks for audio enablement (speaker 36 / microphone 38) at step 510. If no audio detection mechanism is detected, the user is prompted to enable audio detection at step 512.

[0062] When audio detection is enabled, at step 514, the validator application samples the audio to confirm the presence of a matching meeting and device with the participants. For example, the validator may be installed on another node (another user's device). In some examples, the validator is installed on an auxiliary device (e.g., mobile device 28) that can act as a prover by outputting a specific audio tone, and the main device (user computer 30) can record the audio tone and perform the verification. In this way, the client may be installed on a given user's smartphone and a given user's computer 30. In this example, the prover may be installed on a node for the first user 22, and the validator may be installed on a second node for the second user 24.

[0063] If the audio cannot be verified, the user is prompted to adjust audio settings or otherwise verify their identity before proceeding at step 516. Alternatively, participants may receive an option, for example, to accept an unverified user. If the audio is verified, at step 518, the validator application initiates a verification request to the prover. For example, a secure key exchange of tokens may be verified using Diffie-Hellman or other digital signal verification (step 520). If a mismatch is detected, the validator is notified at step 522 (e.g., by displaying a low confidence level or another metric to guide the user), and at step 524, the meeting log is saved to one or more databases 12. These logs may be transmitted to the administrator of the authentication system 10 depending on the severity of the breach or attempted breach.

[0064] See brief Figure 6 Post-quantum secure identifiers can be used in email communication software / platforms. For example, they can be used in a similar manner. Figure 5The graphic 44 is used for conferencing. It is conceivable that this indication can be presented in various ways, as previously described. In this example, the indication can be presented in the ribbon or another part of an email object. For example, graphic 44 can appear near the recipient's address when the target user enters a recipient's email address. When an email address is entered, the authentication system 10 can operate as a certificate authority as previously described, where graphic 44 is presented within the digital object. Therefore, plug-in 32 can be a software add-in for various communication platforms.

[0065] See now Figure 7 An exemplary method 700 performed by authentication system 10 includes transmitting a post-quantum-secure identifier via a first node to at least one second node at step 702. At step 704, method 700 includes receiving the post-quantum-secure identifier at at least one second node. Method 700 also includes a step 706 for comparing the post-quantum-secure identifier with authorized user data stored in database 12 storing authorized user data. At step 708, authentication system 10 determines the confidence level of the first node. At step 710, the method includes transmitting a signal indicating the confidence level. In some examples, method 700 includes presenting an indication of the confidence level at user interface 42. Method 700 can be modified to include any of the steps previously described as being performed by authentication system 10.

[0066] The methods and systems conforming to this invention address the inherent trust issues in existing voice and video conferencing systems. This convenient trusted party verification method can be post-quantum secure, adding to many currently used methods such as two-factor authentication, public key infrastructure (PKI), Internet Protocol Security (IPSEC), digital certificates, and certificate authority (CA) methods, and significantly improving security during real-time or asynchronous playback.

[0067] A method for discreetly authenticating trusted parties and detecting deepfakes is proposed. One example would be the creation of security tokens with freely shareable public keys. By utilizing the open application programming interface of calendar tools, participants can be automatically identified and matched against new or previously exchanged credentials to authenticate individuals in a call or meeting using session-wide internet data communication and / or in-band audio transmission. Using these same calendar tools (which are part of an office suite), contacts transmitting audio and video images via email, FTP, or cloud storage can be matched with their authentication tokens.

[0068] According to several aspects, the System 10 and methods described herein can require users to input employee IDs or government-issued IDs and information into System 10 via a series of images. This verification can be performed at scale via company-entered employee data, or it can be done at the individual level. Employees' social profiles can also be linked to verification. Verification can be strengthened (e.g., a higher confidence level) based on consistent interactions between verified users. Inconsistent interactions (e.g., the number of days or years between meetings with verified users) may lead to a lower confidence level. VPN tunnels can also be detected by System 10.

[0069] See now Figures 8 to 18 System 10 can provide enhanced authentication by allowing third-party authentication services to operate within system 10. For example, system 10 can be implemented as a platform for merging verification information from third parties and from the verifier 16 itself. As will be described in the foregoing figures, the system provides third-party access via a marketplace, thereby allowing selection of authentication system 10’s local services (e.g., verifier 16) and various third-party services to use centralized, detailed elements to improve the confidence value generated by the system.

[0070] An example of a service that may be provided by System 10 includes at least one immutable database with immutable reports. Because System 10 can use blockchain technology to confirm signatures to verify identity, the blockchain can leverage immutable reports to create an immutable ledger. Depending on the chosen blockchain, System 10 may incur fees. Due to the fees charged for the various third-party operability of System 10, a virtual marketplace may be provided to the administrator, allowing selection from multiple such third-party services. Each third-party service may have a monetary cost or subscription fee. When selecting any third-party service, the devices assigned to system participants (e.g., users) may be updated to include the third-party service. Third-party services may operate independently, but, as will be described, are configured to cooperate with the infrastructure of Verifier 16 to enhance the estimation or determination of the confidence level for each user or device.

[0071] Continue to refer to Figures 8 to 18System 10 may include an authentication system 802 (e.g., one or more authenticators in authenticator 16) and one or more agents 804 communicatively coupled to the authentication system 802. For example, one or more agents 804 may be installed on one or more user devices 806 (e.g., mobile device 28, user computer 30). Agent 804 is configured to transmit a first credential indicating an identifier to the authentication system 802. For example, agent 804 may be software running on user device 806 and communicating with the software of the authentication system 802. Agent 804 is also configured to transmit a second credential indicating an identifier to an authentication service 808, such as a third-party authentication service. Authentication system 802 includes a database 12 configured to store authorized user data. Authentication system 802 may also include a portal configured to provide selection of an authentication service 808 from a plurality of authentication services 808. Authentication system 802 is configured to compare the first credential with the authorized user data. For example, the authorized user data may be stored in database 12. The verification system 802 is also configured to: determine the confidence level of the validity of the identifier based on the comparison between the first credential and the authorized user data, receive verification of the second credential from the verification service 808, and modify the confidence value based on the verification.

[0072] See more details Figure 8 and Figure 9 The system 10 is illustrated in a simplified form using an authentication system 802 on a network 14 including an authenticator 16. In this example, the user's node is shown as an agent 804 installed on the user device 806. It is conceivable that the agent 804 can be installed and / or accessed via a mobile device management (MDM) system 810 that allows the management of mobile devices. For example, a client authenticator application can be installed on a smartphone or tablet and managed via the MDM system 810. The authentication system 802 can be combined with the previously mentioned... Figure 2 The server 26, authenticator 16, one or more virtual machines, and blockchain service shown and described.

[0073] refer to Figure 9The verification system 802 and the agent 804 can communicate via the signature service 814 and the data service 816. For example, the verification system 802 can initially and / or periodically issue certificates to the agent 804 and / or verify the agent's signature via the signature service 814. In some examples, the verification system 802 can send tokens to the agent 804, which can be periodically refreshed and / or revoked if the agent 804 is compromised. This can allow authentication of the agent 804 without having to send a private key. For example, tokens can be issued monthly, semi-annually, weekly, daily, hourly, or any other periodic frequency. For example, a token can be revoked if anomalous software or significant data exchange anomalies (e.g., verification failure) are detected during the use of the data service 816. After proper authentication via the signature service 814, the data service 816 provides a data stream including the previously described identification information from the agent 804 to the verification system 802. For example, the first credential can be transmitted to the verification system 802 via the data service 816. Then, it is confirmed that system 802 can generate or determine a confidence value that the user or agent 804 associated with agent 804 is not compromised, as previously described regarding the first node and the second node.

[0074] In addition to transmitting the first credential via data service 816, system 10 may also include a verification service 808 provided by a third party. Verification service 808 may also communicate with agent 804 to receive a second credential and determine verification of the second credential. Verification is transmitted to confirmation system 802, which may modify the confidence value based on the verification. While this document describes using the first credential to determine the confidence value and subsequently adjusting the confidence value based on verification, it is conceivable that these steps may be performed in parallel or simultaneously, allowing a common function of the first and second credentials to be determined for weighting the first and second credentials.

[0075] It is conceivable that authentication service 808 may include a server / client topology, where the client is installed on the user's device, and the server is located away from or separate from system 10. Therefore, the clients of proxy 804 and third-party service 808 can be installed on the same device, and / or authentication system 802 can be on a different network than authentication service 808. See below for reference. Figure 10 The communication between the verification service 808, the agent 804, and the confirmation system 802 is further described.

[0076] See now Figure 10The details of System 10 are illustrated with reference to an exemplary agent 804 having an authentication service 818 running on user equipment 806. Service 818 may incorporate a blockchain for secure key exchange (e.g., ZKP as previously described) and signature verification. For example, authentication service 818 may include / perform a signature process for communicating with confirmation system 802. Based on the verified signature, confirmation system 802 may issue a certificate (as a Certificate Authority, CA) to user equipment 806. After the signature of agent 804 is confirmed by signature service 814, confirmation system 802 is configured to read identification information from agent 804 via data service 816. For example, for confirmed user equipment 806, confirmation system 802 monitors the first credential from agent 804 to determine the confidence level to be displayed to other agents 804 supported by system 10. For example, during a web conference or on an email application running on another agent 804 on system 10, a user of another agent 804 (e.g., a second node) can view indicators indicating the validity status of the user of the exemplary agent 804, such as color indicators (see at least [link to relevant documentation]). Figure 4 and Figure 6 ).

[0077] For reference Figure 16 Further described, the verification system 802 (such as one or more verifiers in verifier 16) may include an ensemble learning module 819 that processes credentials to output a confidence level or confidence score value for each user. For example, the ensemble learning module 819 may communicate with a data service 816 and / or a signature service 814. The ensemble learning module 819 may process information from a third-party verification service 808 and a proxy 804 to generate a confidence level. The ensemble learning module 819 may function as one or more processors operating with a memory storing instructions that, upon execution, cause one or more processors to process credentials and / or verify to generate a confidence score value. As will be further described herein, the ensemble learning module may include multiple machine learning modules 826 that are logically arranged in a voting topology to produce a classification output (e.g., confidence scores with multiple options for classification).

[0078] To provide communication between applications on nodes and between nodes, at least one application programming interface (API) 820, 822 communicatively couples the authentication service 808 with the agent 804 and the acknowledgment system 802. For example, at least one API 820, 822 may include a first API 820 at the acknowledgment system 802 and a second API 822 installed on the machine running the agent 804 (e.g., user equipment 806). Second credentials may be transmitted from the agent 804 to the authentication service 808 via the second API 822, which interfaces with the authentication service 818. For example, at least one API 820, 822 may include a Representational State Transfer (REST) ​​architecture to control how applications interface via at least one API 820, 822. Other interface architectures are contemplated.

[0079] For example, authentication service 808 can be configured to communicate with authentication system 802 and / or agent 804 via a software development kit (SDK) installed on user equipment 806 and / or authentication system 802. For example, the SDK can be used to develop applications specifically designed to interface with multiple authentication services 808. As another example, authentication service 808 can be configured to interface with agent 804 via a network hook that provides communication via at least one API 820, 822. In some examples, the network hook is used to allow agent 804 to transmit a second credential to authentication service 808.

[0080] Continue to refer to Figure 10 Database 12 can be configured as an immutable database that provides append-only tracking and / or transparency. Therefore, the immutable database can be tamper-proof and utilizes cryptographic signatures and / or Merkle directed acyclic graphs (DAGs) to restrict or prevent changes to the data stored in database 12. The database can be accessed via signature service 814 and data service 816. For example, similar to what was previously discussed... Figure 2 The described system 10 confirms that server 26 on system 802 can process data requests and access database 12 to compare authorized user data with credentials provided directly via proxy 804 or authentication service 808. In some examples, both the first and second credentials are transmitted via data service 816.

[0081] like Figures 10 to 12 As shown, the verification system 802 may include a portal 824 that can be operated by an organization's administrator. For example, the organization's information technology (IT) administrator can operate portal 824 to manage system 10. At portal 824, the confidence level of each agent 804 can be tracked, certificates can be monitored, and other diagnostics of system 10 can be viewed and logged. Figure 11As shown, portal 824 can allow monitoring and tracking of multiple threats, compromised user devices 806, etc.

[0082] See now Figure 12 Portal 824 can provide a virtual marketplace for selecting multiple authentication services 808. In operation, the administrator can select any of the multiple authentication services 808 to install at agent 804. Once selected, the selected service 808 can be pushed to user device 806 for installation and interface with the authentication service 808. In this way, system 10 can receive authentication signals / values ​​from third-party service providers, and the verification system 802 merges them with other credentials directly monitored by the verification system 802. For example, and briefly return to reference. Figure 10 The verifier 16 can combine the first and second documents and give some documents (e.g., authentication factors) a greater weight than others to determine the confidence level.

[0083] See now Figure 13 Authentication factors or credentials can be processed natively in one or more machine learning models 826 trained by the AI ​​engine 828 (e.g., on the verifier 16) or via the verification service 808. Model 826 can be trained to generate confidence values ​​based on credentials, compared with previous references. Figure 2 The described model is consistent. At least one machine learning model 826 is configured to adjust the function used to determine the confidence value by adjusting the relative functional weights of at least one of the data (e.g., native credentials) and the second credential (e.g., third-party verification). For example, model 826 may be trained by AI engine 828 based on EDR detections from verification (e.g., detection of anomalous software) to better determine the confidence level. For example, the relative weights of EDR detection verifications may be adjusted based on other authentication factors of system 10 and / or user feedback or manual overriding (e.g., manual administrator approval by the user or node). In some examples, a user's EKG can be used for verification because the EKG can serve as a person's biometric signature. Therefore, a third-party verification service may include a heart rate monitoring system that uses AI and / or model 826 to train to detect the identity of a user associated with a given agent 804. Figure 13 As shown, the multiple authentication factors processed by the verification system 802 may include any of the authentication factors previously described.

[0084] For example, a third-party authentication system may include the biometric data of the user of agent 804. For instance, system 10 may communicate with a smartwatch or smart device configured to monitor a user's health (such as heart rate or heartbeat). This monitoring technology can verify a person's biometric data to enhance identification. The presence of a heartbeat can confirm that a real person is logging in. Therefore, third-party authentication service 808 could be the presence of a heartbeat at a location near the user device 806 being authenticated, heart rate information specific to the assigned user, an electrocardiogram specific to the user assigned to user device 806, etc. Thus, biometric data can be used for third-party authentication. As previously described, EKG information can be used to identify the user registered to agent 804, and the relative weights of the determination function of authentication system 802 can be adjusted based on the reliability of the EKG identification. Alternatively or additionally, the watch may receive notifications of PSTN or VoIP calls, which can be used to authenticate the user.

[0085] Another example of verification service 808 includes an Automatic Speech Recognition (ASR) service for determining whether speech is real or artificial. For example, service 808 could be used to classify audio waveforms as organic or synthetic. This service 808, along with other services 808 described herein, can provide the previously described API or another integration mechanism to interface with agent 804.

[0086] Another example of an authentication service 808 that can be integrated into System 10 includes telephone operator services (such as AT&T or Verizon) that have access to call detail records (CDRs) of many users and can share these records to correlate with the caller's CDR. For example, the CDRs of participants (e.g., employees) of an organization implementing System 10 can be compared with location information detected from GPS or geolocation information. For example, as part of a subscription to System 10, the CDR of user equipment 806 can be shared with authentication system 802 to increase the user's confidence level / score for a given virtual meeting or user identity. Furthermore, operators can share the caller's geolocation and also share location data of the cell towers the voice caller is using (and, if the user is in motion, a series of cell towers) to aid in identity verification and / or increase confidence scores. Operators can employ Secure Telephone Identity Revisit (STIR) and token-based signature-based assertion information processing (SHAKEN) protocols to further authenticate users. Such protocols can be used to limit caller ID spoofing on public telephone networks. For example, in cases where authentication is performed via a call, CDR verification can be used by a third party to restrict bots or other malicious actors.

[0087] Another exemplary authentication service 808 includes an endpoint detection service. For example, Cisco... ®Endpoint Detection and Response (EDR) systems can be third-party verification services 808 that communicate with agent 804. EDR can detect malware and ransomware on user devices 806. EDR results can be transmitted as verification to an accreditation system 802 to be combined with other data points (e.g., authentication factors) for threat detection and to modify confidence values. EDR can be transmitted via third parties such as Cisco. ® CrowdStrike ® Alternatively, this can be achieved using other cybersecurity endpoint specialists who focus on detecting various forms of malware across multiple data points. The verification system 802 can collect data from these verification services 808 regarding whether a given user device 806 is healthy and has recently had its signature updated.

[0088] Another exemplary verification service 808 may include fintech security measures, such as decentralized identity (DID) systems, such as Orange by MicroStrategy. ® For example, in the email example, a user can prepare an email. When sent, the email is hashed and signed with the sender's private key. The signature is included in the header. At the recipient's end, the signature and identifier are retrieved from the email. Then, a verifier uses the blockchain to locate the sender's public key to verify the signature. The public key is used to decrypt the signature to give the hash value of the email. The DID system can determine whether the email has been tampered with by comparing the hash values. In this way, the DID system can be used to authenticate communications and provide verification.

[0089] Another exemplary verification service 808 includes the Ethereum Name Service (ENS), which typically utilizes blockchain for financial transactions. The ENS verification service 808 provides a decentralized name lookup service. Therefore, a user device 806 can have a .eth identifier associated with a financial account (e.g., Ethereum). Thus, a transaction with a signed / verified identifier information associated with user device 806 can be used to verify user device 806 or proxy 804.

[0090] Another exemplary verification service 808 includes ordinal transcriptions of the blockchain, which can allow financial transactions to include additional data, such as the sequential order of transactions. This can establish an accurate order of transactions within a block and improve the accuracy of the ledger. Therefore, financial transactions or other communications tracked via third-party applications using ordinal transcriptions can be used by third parties to provide verification to the confirmation system 802.

[0091] Another exemplary authentication service 808, which may be additionally or alternatively provided by the private authenticator 16 of the authentication system 802, may be provided via instant messaging (e.g., messaging applications such as SMS, Apple).® Confidence levels can be provided via push notifications (e.g., iMessage, etc.) or web applications, and voice (e.g., PSTN, VoIP) instead of traditional multi-factor authentication or FIDO authentication methods. In cases where a visual indication of the confidence level is not possible, the confidence value can be delivered via push notifications (e.g., text confirmations).

[0092] As isolated services, these authentication services 808 and other services may be difficult to implement efficiently. However, this system 10 and the corresponding method can provide enhanced security by providing a centralized platform that can be customized based on the selection of service 808.

[0093] As previously described, system 10 may include federated capabilities. For example, a first node authenticating a user using a private authenticator 16 may require displaying the user's confidence level on the communication platform, while a third node on a public authenticator system may not have access to the user's confidence level on the federated network. For example, authentication service 808 may be restricted to accessing confidence level 804 generated by system 10 (e.g., authentication system 802), while authentication system 802 may have access to authentication from authentication service 808 and may display that authentication to users on the federated network. Thus, system 10 may selectively share node confidence levels via the federated network.

[0094] Continue to refer to Figure 13 Model 826 can be used to determine the reliability score of verifications provided by a third party. For example, each service 808 can be scored based on feedback from native functionality and / or any of the third-party verification services 808. For example, if most of the monitored authentication factors (e.g., the first credential or the second credential) strongly indicate a high confidence score, but the verification from one verification service 808 is very low, then the verification system 802 can rank that verification service 808 lower. Therefore, the verification system 802 can include feedback loops for determining the accuracy of multiple verification services 808. For example, the verification system 802 can be configured to determine the reliability score of the verification service 808 based on the weight of the second credential from the verification service 808, and present an indication of the reliability score at portal 824. The verification system 802 can then recommend alternative verification services 808 among the multiple verification services 808 based on the reliability score. For example, if the first audio verification service is ranked low by the verification system 802, another audio verification service can be highlighted or otherwise indicated as an alternative.

[0095] See now Figure 14Verification system 802 may include a verifiable system design that combines at least one of certificate transparency and a claimant model for verification. The verifiable system design may be used for agent 804 of verification system 10. Therefore, node N1 may exhibit verification service 808 or native user device 806. Generally, certificate transparency is exhibited in steps 1 through 5. At step 1, the node requests a certificate from a Certificate Authority (CA). The CA may be part of verification system 802, such as server 26, verifier 16, or another computing device of verification system 802. The CA then verifies agent 804 or third-party verification service 808 as it claims (e.g., via signature service 814), and at step 2, the pre-certificate is logged in log 830. Log 830 may be append-only and may or may not be merged into the same database 12 described previously. Log 830 may utilize a Merckle tree to track the pre-certificate and typically contains immutable data. At step 3, the pre-certificate is signed and timestamped to become a certificate, and then at step 4, the CA issues the certificate to node N1. Simultaneously with at least one of steps 1 to 4 (e.g., periodically), log 830 is monitored by monitor 832, and the certificate issuance is transmitted to other nodes of system 10. In some examples, monitor 832 is a separate evaluation unit whose auditing and verification system 802 detects malicious entries in log 830, thereby detecting malicious certificates. For example, a malicious certificate can be detected by monitor 832 by monitoring log 830 in a cryptographic manner.

[0096] In some examples, monitor 832 is run by verification system 802, and node N1 is a third-party verification service 808. In this example, monitor 832 periodically checks the certificates of verification service 808 to ensure that verification service 808 is as it claims to be. It is conceivable that the monitoring functionality in this context could be further selected in a virtual marketplace. For example, system 10 could be configured to present verification service 808 along with options for monitoring whether verification service 808 incurs any additional costs.

[0097] In some examples, the verification system 802 employs a claimer model that can supplement or replace the certificate transparency protocol. Similar to the example above, the claimer in the claimer model could be an agent 804 or a verification service 808. The claimer in the claimer model publishes a list (e.g., to log 830) claiming to have a unique cryptographic hash value for a specified version (e.g., operating system version or agent 804 version), and requires the claimer to be functionally correct and free of known attack vectors. For example, agent 804 could use signature service 814 to transmit the claim to verifier 16. The verification system 802 can be configured to act as a believer in the claim and issue certificates to agent 804. However, in the event that agent 804's private key is stolen and a false or malicious list is published, the claimer can monitor the published list to detect malicious lists because the list has been published. Therefore, the claimer model includes a verifier that can verify or approve the claim described by each list. Thus, monitor 832, another computing device of verification system 802, or the administrator of system 10 can verify the lists. In this way, a fake certificate from proxy 804 can be flagged by system 10 and prevented from communicating with data service 816. In some examples, in response to the detection of an anomaly list, portal 824 is configured to present an indication of the anomaly list, and authentication system 802 is configured to revoke authentication in response to the detection of the anomaly list.

[0098] The method performed by system 10 can provide non-repudiation by ensuring confirmation of sent or received communications. Non-repudiation can be provided via asymmetric key pairs, features combining those from the native system and third-party systems (e.g., first and second credentials), certificate transparency logs, immutable data, or any combination thereof.

[0099] See now Figure 15 Authentication method 1500 can be executed by system 10. Method 1500 includes, at step 1502, selecting an authentication service 808 from a plurality of authentication services 808 separate from authentication system 802 via portal 824 of authentication system 802. At step 1504, method 1500 includes receiving at least one first credential of an indication identifier from agent 804 at authentication system 802. At step 1506, method 1500 includes comparing the at least one first credential with authorized user data stored in authorized user database 12. At step 1508, method 1500 includes determining a confidence level of the identifier's validity based on the comparison of the at least one first credential with the authorized user data. At step 1510, method 1500 includes transmitting a second credential of the indication identifier from agent 804 to authentication service 808. At step 1512, method 1500 includes receiving verification of the second credential via authentication service 808. At step 1514, method 1500 includes modifying the confidence level based on the verification.

[0100] See now Figure 16 The example topology of the integration learning module 819 of the verification system 802 may include multiple base models 834, 836 that process first credentials (e.g., from agent 804) and authentication (e.g., from authentication service 808), and a master integration model 838 that processes the output of the multiple base models 834, 836 to determine confidence levels. The base models 834, 836 and the master integration model 838 may be included as at least some of the models 826 previously described. Therefore, the output of the integration learning module 819 may be transmitted to portal 824 and / or various user devices 806 to display the confidence values ​​of users of the communication platform.

[0101] The confirmation system 802 can employ the integrated learning module 819 to generate simplified output, which allows users to easily assess malicious events and / or unauthenticated users based on the output's classification or category. For example, and as will be referenced... Figure 17 and Figure 18 Further, confidence values ​​can be presented as traffic light indicators, such as green for safety, yellow for warning, and red for alert. Other indicators can also be used, such as traffic or verification symbols (e.g., checkmarks, question marks, exclamation marks, or other symbols used to indicate the presence, absence, or unknown nature of a threat). Indicators can be presented as any of the previously described indicators (e.g., graph 44), simultaneously displaying one of multiple categories. The ensemble learning module 819 can provide simplified outputs by combining the outputs of the base models 834, 836 to create robust predictive models. Therefore, the ensemble learning module 819 can aggregate data from multiple disparate sources (such as multiple verification services 808 and each agent 804 running on multiple user devices 806) in a manner that balances the functional weights of each input (e.g., credentials or verification).

[0102] One or more machine learning models in machine learning model 826 of ensemble learning module 819 can be trained via supervised learning, for example, by AI engine 828 as previously described. For example, machine learning model 826 may include classification and regression algorithms. Classification algorithms can be used with mixed text and numerical data processed by ensemble learning module 819 to generate classification predictions (e.g., danger, warning, safety). Regression algorithms can be used with purely numerical data, such as the type and quantity of different interactions (e.g., the number of emails sent and received, the number of meetings attended, etc.). Regression algorithms can return numerical values ​​that can be mapped to a defined range of categories (e.g., 0 to X for safety, X+1 to Y for warning, Y+1 to Z for danger). By classifying multiple base models 834, 836 in this way, all voting members in ensemble learning module 819 can vote using category values.

[0103] Multiple base models 834, 836 may alternatively be referred to as a first base model 834 and a second base model 836. In this example, the first base model 834 is configured to process a first credential (e.g., as the “native” model of the verification system 802), and the second base model 836 is configured to process verifications from the verification service 808. In some examples, base models 834, 836 may be logically separated based on the type of authentication feature processed. For example, the first base model 834 may be configured to process third-party verification of audio and the first credential of audio (from proxy 804), since both are audio-based authentication. In the depicted example, the first base model 834 and the second base model 836 are logically separated along the lines of third-party and native functionality of base models that process similar types of input. In the depicted example, two third-party voice verifications are provided to the second base model 836, which processes each verification in the deepfake speech detection integration. Therefore, the depicted deepfake speech detection integration can reduce the number of inputs processed in the next stage (e.g., exemplary intermediate base model 840).

[0104] The intermediate base model 840 can be optionally used to further limit the number of inputs processed by the main integration model 838. In this example, the intermediate base model 840 operates as a third-party integration model that processes each vote for third-party validation. For example, if an administrator has selected ten third-party validation services 808, the exemplary intermediate base model 840 will process these validations or a combination of these validations and output the vote to the main integration model 838. However, due to type grouping, the ten validations can be cut off before or upstream of the intermediate base model 840. For example, the ten features could include validations from three video validation services 808, two audio validation services 808, and five geolocation validation services 808. In this case, the number of second base models 836 can be reduced relative to combining one second base model 836 for each input.

[0105] The specific topology of the integrated learning module 819 can be adjusted by the verification system 802 based on the quantity and type of data / credentials / verifications to be processed by the system 802. For example, the system 802 can detect and classify the quantity and type of third-party verification services 808 by monitoring the integration of third-party verification services 808 software with native software development kits (SDKs) in use, such as marketplace APIs.

[0106] Model 826 of the ensemble learning module 819 can employ various AI techniques to optimize the estimation of confidence values. For example, model 826 can use a traditional expert system, while other models will use more advanced AI / ML algorithms such as random forests, decision trees, or gradient boosting. Alternatively, one or more models in model 826 can output derived numerical values, while other models output text strings as part of a large language model (LLM). Therefore, multi-layer voting ensemble streams can provide reduced complexity. Each layer can integrate votes from models processing similar data. For example, if multiple third-party APIs evaluate speech data for deepfake detection (such as...), this can be used... Figure 16 As shown in the figure, these votes can be processed into a single vote for the final integration, or processed into a final vote by the intermediate base model 840, as shown in the figure. This process can reduce the complexity of the main integration model 838.

[0107] As previously described, model 826 used in ensemble learning module 819 can be trained to adjust the functional weights for more reliable authentication. Therefore, there may be priority conditions for automatically triggering alarms. For example, a mismatch between public IP and GPS and SIM responses from mobile operator tower locations might override votes generated based on other features (e.g., voice, video). For instance, referencing... Figure 16Supervised learning using the ensemble learning module 819 can significantly weight the location data models in multiple first base models 834 relative to the third-party ensemble 840. For example, past training by the AI ​​engine 828 can reduce the confidence value by one level (e.g., category) based on mismatches in the location data. For example, what was originally no threat can be reclassified as unknown. In some examples, the category is set to "threat" when a priority criterion is met.

[0108] It is conceivable that any of the methods described herein (such as method 700 or method 1500) can be combined with various methodological steps performed by the ensemble learning module 840 to produce confidence levels for classification. For example, the ensemble learning module 819 can be used to perform modifications to the verification-based confidence levels. In this way, third-party verification and native functionality can be combined to provide more accurate and robust confidence levels.

[0109] See now Figure 17 and Figure 18 The communication platforms described above (e.g., video conferencing) are illustrated using the categories described above. Figure 17 ) and email ( Figure 18 An example screen. For instance, each user of the communication platform could have indicators that use signs and / or colors to display threat levels, indicating the likelihood of a malicious actor. Figure 17 In the example, three threats are identified, and visitor 02 is authenticated. Figure 18 In the example, at least four threats were indicated, and three verified users were also indicated.

[0110] The misuse of deepfake technology for malicious purposes, such as corporate espionage, asset theft, dissemination of disinformation, fabrication of evidence, or manipulation of public opinion, poses a significant threat to society. As deepfakes become increasingly realistic and harder to detect, the risk of causing chaos, confusion, and harm also increases. The system 10 and method disclosed herein provide mechanisms to limit or eliminate these effects.

[0111] It is conceivable that the various processing systems described herein (e.g., verification and authentication systems) may include any number of processor and memory portions of control circuitry. The control circuitry may include one or more controllers that combine at least one processor with a memory storing instructions that, when executed by the processor, cause the processor to perform actions and / or transmit signals for authentication. The processor may include one or more general-purpose processing devices, such as microprocessors, central processing units, etc. The processor may include complex instruction set computing (CISC) microprocessors, reduced instruction set computing (RISC) microprocessors, very long instruction word (VLIW) microprocessors, or processors implementing other instruction sets or combinations of instruction sets. The processing device may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), systems-on-a-chip (SoCs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. The processor may be configured to execute instructions for performing any of the operations and steps discussed herein. For example, system 10 described herein may include one or more tangible, non-transitory computer-readable media storing instructions that, when executed, cause one or more processing devices to perform the steps described herein.

[0112] This disclosure provides various combinations of the following aspects: According to one aspect of this disclosure, a system for authentication includes an authentication system and an agent configured to transmit a first credential indicating an identifier to the authentication system and a second credential indicating the identifier to an authentication service. The authentication system includes a database configured to store authorized user data and a portal configured to provide selection of an authentication service from a plurality of authentication services. The authentication system is configured to: compare the first credential with the authorized user data; determine a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data; receive verification of the second credential from the authentication service; and modify the confidence level based on the verification.

[0113] According to one aspect of this disclosure, the system includes at least one application programming interface (API) that communicatively couples the verification service with the agent and acknowledgment system.

[0114] According to one aspect of this disclosure, at least one API includes a first API at the authentication system and a second API installed on the machine running the agent.

[0115] According to one aspect of this disclosure, the verification service interfaces with the agent via a software development kit (SDK).

[0116] According to one aspect of this disclosure, the verification service interfaces with a proxy via a web hook.

[0117] According to one aspect of this disclosure, the verification service is connected to the proxy via a World Wide Web service.

[0118] According to one aspect of this disclosure, the verification service includes endpoint services and detection.

[0119] According to one aspect of this disclosure, multiple verification services are presented via a portal through a virtual marketplace.

[0120] According to one aspect of this disclosure, the confirmation system is configured to determine deepfake conditions in response to a confidence level.

[0121] According to one aspect of this disclosure, authorized user data includes immutable data stored in a database.

[0122] According to one aspect of this disclosure, the system includes a user device on which an agent operates, wherein a first credential includes data representing the identity of the user device, the data including at least one of location information, voice information, and video information.

[0123] According to one aspect of this disclosure, the confirmation system includes at least one machine learning model trained to generate confidence levels based on a first credential and a second credential.

[0124] According to one aspect of this disclosure, the system includes an artificial intelligence engine that uses a first credential and verification to train a machine learning model.

[0125] According to one aspect of this disclosure, the machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the first and second credentials.

[0126] According to one aspect of this disclosure, the verification system is configured to determine the reliability score of the verification service based on the weight of the second credential, and to present an indication of the reliability score at the portal.

[0127] According to one aspect of this disclosure, the confirmation system is configured to recommend alternative verification services among multiple verification services based on reliability scores.

[0128] According to one aspect of this disclosure, the second credential includes the biometric data of the user acting as the agent.

[0129] According to one aspect of this disclosure, biometric data includes at least one of heart rate and electrocardiogram, and wherein the verification service includes a heart rate monitoring system for the user.

[0130] According to one aspect of this disclosure, the confirmation system includes at least one machine learning model trained to generate confidence levels based on the electrocardiograms of users registered by the agent.

[0131] According to one aspect of this disclosure, the heart rate monitoring system is configured to identify users based on electrocardiograms.

[0132] According to one aspect of this disclosure, the system includes an artificial intelligence engine that uses electrocardiograms to train machine learning models.

[0133] According to one aspect of this disclosure, the machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the first credential and the electrocardiogram.

[0134] According to one aspect of this disclosure, the user equipment is configured to run conferencing software or email applications that present a confidence level.

[0135] According to one aspect of this disclosure, verification includes at least one of text confirmation via an instant messaging application running on a user device and data from a World Wide Web application running on a user device.

[0136] According to one aspect of this disclosure, credentials include voice information provided via at least one of VoIP and PSTN.

[0137] According to one aspect of this disclosure, the verification service is a third-party service separate from the confirmation system.

[0138] According to one aspect of this disclosure, the system confirms that it provides certificate transparency.

[0139] According to one aspect of this disclosure, the system confirms that it employs a declarer model to verify the agent's signature.

[0140] According to one aspect of this disclosure, a method for authentication includes: selecting an authentication service from a plurality of authentication services separate from the authentication system via a portal of the authentication system; receiving a first credential indicating an identifier from an agent at the authentication system; comparing the first credential with authorized user data stored in an authorized user database; determining a confidence level of the validity of the identifier based on the comparison between the first credential and the authorized user data; transmitting a second credential indicating the identifier from the agent to the authentication service; receiving verification of the second credential via the authentication service; and modifying the confidence level based on the verification.

[0141] According to one aspect of this disclosure, the method includes presenting multiple verification services at a portal via a virtual marketplace.

[0142] According to one aspect of this disclosure, the method includes determining deepfake conditions in response to a confidence level.

[0143] According to one aspect of this disclosure, the method includes training at least one machine learning model via an artificial intelligence engine to generate a confidence level based on a first credential and a second credential.

[0144] According to one aspect of this disclosure, the method includes adjusting a function used to determine a confidence level by adjusting the relative functional weights of the first and second credentials.

[0145] According to one aspect of this disclosure, the method includes determining a reliability score for the verification service based on the weight of a second credential, and presenting an indication of the reliability score at a portal.

[0146] According to one aspect of this disclosure, the method includes recommending alternative verification services among a plurality of verification services via a verification system based on a reliability score.

[0147] According to one aspect of this disclosure, a method for authentication includes: selecting an authentication service from a plurality of authentication services; receiving a first credential indicating an identifier from an agent at an acknowledgment system; comparing the first credential with authorized user data; determining a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data; transmitting a second credential indicating the identifier to the authentication service; receiving verification of the second credential from the authentication service; and modifying the confidence level based on the verification.

[0148] According to one aspect of this disclosure, the method includes determining deepfake conditions in response to a confidence level.

[0149] According to one aspect of this disclosure, the method includes processing a first credential and verifying it in an integrated learning module to modify the confidence level.

[0150] According to one aspect of this disclosure, the first credential is part of a set of first credentials indicating to the verification system, and the second credential is part of a set of second credentials indicating to the verification service.

[0151] According to one aspect of this disclosure, the ensemble learning module includes multiple base models for processing the set of first credentials and verifications, and a master ensemble model for processing the outputs of the multiple base models to determine confidence levels.

[0152] According to one aspect of this disclosure, the plurality of basic models include at least one first basic model for processing the set of first credentials and at least one second basic model for processing verification.

[0153] According to one aspect of this disclosure, at least one second base model includes a plurality of second base models configured to process a plurality of authentications from a plurality of authentication services in response to a plurality of authentication services receiving a plurality of second credentials.

[0154] According to one aspect of this disclosure, the method includes classifying multiple verification services according to the type of verification provided by each of the multiple verification services.

[0155] According to one aspect of this disclosure, the types include at least one of video verification, audio verification, geolocation verification, text verification, and email verification.

[0156] According to one aspect of this disclosure, the plurality of second basic models include a second basic model for each category of the verification service.

[0157] According to one aspect of this disclosure, the plurality of basic models include an intermediate basic model that processes the outputs of the plurality of second basic models and generates a single output for the main ensemble model.

[0158] According to one aspect of this disclosure, the master ensemble model uses at least one output from at least one first basic model to process a single output.

[0159] According to one aspect of this disclosure, the master ensemble model is trained using supervised learning to classify confidence levels output by the confirmation system.

[0160] According to one aspect of this disclosure, at least one of a plurality of basic models uses supervised learning for machine learning regression.

[0161] According to one aspect of this disclosure, a system for authentication on a communication platform includes a database configured to store authorized user data and a first node for creating and transmitting identifiers. At least one second node is configured to receive the identifiers, compare them with the authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. A user interface is configured to present an indication of the confidence level in response to the signal.

[0162] According to one aspect of this disclosure, a first node is configured to transmit credentials to an authentication service, and at least one second node is configured to receive authentication from the authentication service based on the credentials.

[0163] According to one aspect of this disclosure, the system is configured to modify the confidence level based on verification.

[0164] According to one aspect of this disclosure, the system includes at least one application programming interface (API) that communicatively couples the verification service with a first node and at least one second node.

[0165] According to one aspect of this disclosure, the system includes a portal for allowing selection of multiple verification services presented via a virtual marketplace.

[0166] According to one aspect of this disclosure, authorized user data includes immutable data stored in a database.

[0167] According to one aspect of this disclosure, the identifier is post-quantum secure.

[0168] According to one aspect of this disclosure, at least one second node is communicatively coupled to the blockchain to verify the identifier.

[0169] According to one aspect of this disclosure, the communication platform includes conferencing software configured to present a confidence level, wherein the confidence level represents user authentication for a user of the conferencing software.

[0170] According to one aspect of this disclosure, the communication platform includes email communication software.

[0171] According to one aspect of this disclosure, the data includes at least one of text confirmations from an instant messaging application running on a user device and data from a World Wide Web application running on a user device.

[0172] According to one aspect of this disclosure, voice information is provided via at least one of VoIP and PSTN.

[0173] According to one aspect of this disclosure, the modification includes processing the first credential and verification in the integrated learning module to modify the confidence level.

[0174] According to one aspect of this disclosure, the first credential is part of a set of first credentials indicating to the verification system, and the second credential is part of a set of second credentials indicating to the verification service.

[0175] According to one aspect of this disclosure, the ensemble learning module includes multiple base models for processing the set of first credentials and verifications, and a master ensemble model for processing the outputs of the multiple base models to determine confidence levels.

[0176] According to one aspect of this disclosure, the plurality of basic models include at least one first basic model for processing the set of first credentials and at least one second basic model for processing verification.

[0177] According to one aspect of this disclosure, at least one second base model includes a plurality of second base models configured to process a plurality of authentications from a plurality of authentication services in response to a plurality of authentication services receiving a plurality of second credentials.

[0178] According to one aspect of this disclosure, the verification system classifies multiple verification services based on the type of verification provided by each of the multiple verification services.

[0179] According to one aspect of this disclosure, the types include at least one of video verification, audio verification, geolocation verification, text verification, and email verification.

[0180] According to one aspect of this disclosure, the plurality of second basic models include a second basic model for each category of the verification service.

[0181] According to one aspect of this disclosure, the plurality of basic models include an intermediate basic model that processes the outputs of the plurality of second basic models and generates a single output for the main ensemble model.

[0182] According to one aspect of this disclosure, the master ensemble model uses at least one output from at least one first basic model to process a single output.

[0183] According to one aspect of this disclosure, the master ensemble model is trained using supervised learning to classify confidence levels output by the confirmation system.

[0184] According to one aspect of this disclosure, at least one of a plurality of basic models uses supervised learning for machine learning regression.

[0185] According to one aspect of this disclosure, a system for authentication on a communication platform includes a database configured to store authorized user data. A first node is configured to transmit an identifier and transmit credentials to an authentication service. At least one second node is configured to receive the identifier, compare the identifier with the authorized user data, determine a confidence level for the first node, receive authentication from the authentication service based on the credentials, update the confidence level based on the authentication, and transmit a signal indicating the confidence level. A user interface is configured to present an indication of the confidence level in response to the signal.

[0186] According to one aspect of this disclosure, a system for authentication includes an authentication system and an agent configured to transmit a first credential indicating an identifier to the authentication system and a second credential indicating the identifier to an authentication service. The authentication system includes a database configured to store authorized user data and a portal configured to provide selection of an authentication service from a plurality of authentication services. The authentication system is configured to compare the first credential with the authorized user data, determine a confidence level of the validity of the identifier based on the comparison, receive verification of the second credential from the authentication service, and modify the confidence level based on the verification.

[0187] According to one aspect of this disclosure, the verification service includes an operator, and the second credential includes call details.

[0188] According to one aspect of this disclosure, the call details record includes the location of the cell tower.

[0189] According to one aspect of this disclosure, the operator is configured to use at least one of a Secure Telephone Identity Revisit (STIR) protocol and a token-based signature-based assertion message processing (SHAKEN) protocol to determine authentication.

[0190] According to one aspect of this disclosure, the system includes a signature service between the verification system and the agent, wherein the signature service employs a verifiable data structure.

[0191] According to one aspect of this disclosure, the system includes a certificate authority configured to issue certificates to agents via a signature service, a log configured to record pre-certificates, and a monitor configured to monitor the log.

[0192] According to one aspect of this disclosure, the log is append-only and transparent.

[0193] According to one aspect of this disclosure, the monitor is configured to detect malicious certificates.

[0194] According to one aspect of this disclosure, the log utilizes a Merckle tree to track pre-certificates.

[0195] According to one aspect of this disclosure, the system confirms that it provides certificate transparency.

[0196] According to one aspect of this disclosure, the system confirms that it employs a declarer model to verify the agent's signature.

[0197] According to one aspect of this disclosure, the system includes a certificate authority configured to publish a list when issuing certificates to agents.

[0198] According to one aspect of this disclosure, the system includes a verifier configured to verify a list of certificates issued by a certificate authority.

[0199] According to one aspect of this disclosure, in response to the detection of an anomaly list, the portal is configured to present an indication of the anomaly list.

[0200] According to one aspect of this disclosure, the confirmation system is configured to revoke authentication in response to the detection of an anomaly list.

[0201] According to one aspect of this disclosure, the verification service is a third-party service separate from the confirmation system.

[0202] According to one aspect of this disclosure, a system for authentication on a communication platform includes a database configured to store authorized user data and a first node for creating and transmitting identifiers. At least one second node is configured to receive the identifiers, compare them with the authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. A user interface is configured to present an indication of the confidence level in response to the signal.

[0203] According to one aspect of this disclosure, the system includes a signature service between a first node and at least one second node, wherein the signature service employs a verifiable data structure.

[0204] According to one aspect of this disclosure, the system includes a certificate authority configured to issue certificates to a first node via a signature service, a log configured to record pre-certificates, and a monitor configured to monitor the log.

[0205] According to one aspect of this disclosure, the log is append-only and transparent.

[0206] According to one aspect of this disclosure, the monitor is configured to detect malicious certificates.

[0207] According to one aspect of this disclosure, the signature service employs a declarer model to verify the signature of the first node.

[0208] According to one aspect of this disclosure, the system includes a certificate authority configured to publish a list when issuing a certificate to a first node.

[0209] According to one aspect of this disclosure, the system includes a verifier configured to verify a list of certificates issued by a certificate authority.

[0210] According to one aspect of this disclosure, the identifier is post-quantum secure.

[0211] According to one aspect of this disclosure, at least one second node is communicatively coupled to the blockchain to verify the identifier.

[0212] According to one aspect of this disclosure, the communication platform includes conferencing software configured to present a confidence level, wherein the confidence level represents user authentication for a user of the conferencing software.

[0213] According to one aspect of this disclosure, the communication platform includes email communication software.

[0214] According to one aspect of this disclosure, the identifier includes at least one of a text confirmation via an instant messaging application and data from a World Wide Web application.

[0215] According to one aspect of this disclosure, the identifier includes at least one of voice information provided via at least one of VoIP and PSTN, text confirmation transmitted via instant messaging, video information, and location information.

[0216] According to one aspect of this disclosure, the system includes a third-party verification service that communicates with the first node, and includes an endpoint service and detection for detecting anomalous software running on the first node.

[0217] According to one aspect of this disclosure, at least one second node includes at least one machine learning model trained to generate confidence levels based on the detection of anomalous software.

[0218] According to one aspect of this disclosure, the system includes an artificial intelligence engine that uses the detection of anomalous software to train a machine learning model.

[0219] According to one aspect of this disclosure, the machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the verifications from the endpoint service and the detection.

[0220] According to one aspect of this disclosure, the system is configured to provide decentralized identity by sharing confidence levels and details with a different set of federated nodes.

[0221] According to one aspect of this disclosure, at least one second node includes a federated network, and the system further includes a third node on the federated network, wherein a first node is connected to the at least one second node from outside the federated network, and wherein the at least one second node is configured to limit the transmission of the confidence level of the third node in response to the first node being outside the federated network.

[0222] According to one aspect of this disclosure, a third-party verification service is configured for shared verification, and at least one second node is configured to limit the confidence level of transmission to the third-party verification service.

[0223] According to one aspect of this disclosure, at least one second node is configured to selectively share the confidence level of the node via a federated network.

[0224] According to one aspect of this disclosure, at least one second node is configured to selectively limit the transmission of confidence levels based on a comparison of the identifier with authorized user data.

[0225] According to one aspect of this disclosure, the system is configured to provide decentralized identity by sharing confidence levels and details with a different set of federated nodes.

[0226] According to one aspect of this disclosure, at least one second node is configured to determine a security level corresponding to the identifier based on a comparison of the identifier with authorized user data.

[0227] According to one aspect of this disclosure, a method for transmitting a security authentication request from a first node to a second node to authenticate an audio and / or video file or stream includes a system comprising: a first node that creates a security identifier to be transmitted to the second node; and a second node that verifies the security identifier as either matching an identifier of a known contact or not matching a known contact (because the contact is an imposter or has not used security identifier technology).

[0228] According to one aspect of this disclosure, security authentication employs public-key-private-key encryption.

[0229] According to one aspect of this disclosure, security authentication employs a zero-knowledge proof protocol.

[0230] According to one aspect of this disclosure, secure authentication employs post-quantum cryptography methods, such as ZK-Stark.

[0231] According to one aspect of this disclosure, the authentication request uses in-band audio tone for key exchange.

[0232] According to one aspect of this disclosure, plugins or APIs are used to interface with calendar and / or meeting services for comparison with a data repository.

[0233] According to one aspect of this disclosure, the first node samples the streaming data as a spectrogram to confirm that participants in the session and call / conference match the scheduled participants.

[0234] According to one aspect of this disclosure, the key is rotated periodically and presented at inappropriate times to detect whether they are potential deepfakes.

[0235] According to one aspect of this disclosure, participants are identified by classifying them based on whether they are new, whether they have previously exchanged keys, whether they have no keys, or whether they have mismatched keys, in order to detect whether they are potential deepfakes.

[0236] According to one aspect of this disclosure, the request for authentication is made via a separate data stream out of band of the audio and / or video file or stream.

[0237] According to one aspect of this disclosure, the API provides information such as IP address, open ports used to identify the OS, device type, and manufacturer.

[0238] According to one aspect of this disclosure, the IP address of a remote node can be compared with a SWIP database to determine the location of the remote node.

[0239] According to one aspect of this disclosure, the systems and methods described herein are configured to record user identity exchanges for tracking on audit trails.

[0240] According to one aspect of this disclosure, log records and audit trails are stored on a cryptographic blockchain.

[0241] According to one aspect of this disclosure, log recordings and audit trails are transmitted to the database.

[0242] According to one aspect of this disclosure, the systems and methods described herein are configured to transfer billing information to a database using post-quantum secure authentication.

[0243] According to one aspect of this disclosure, a system for authentication on a communication platform includes a database configured to store authorized user data. The system includes a first node that creates identifiers and is configured to transmit the identifiers. At least one second node is configured to: receive the identifiers, compare the identifiers with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0244] According to one aspect of this disclosure, at least one second node includes a plurality of acknowledgment nodes, each of which is configured to redundantly verify the identifier.

[0245] According to one aspect of this disclosure, the plurality of confirmation nodes include a first confirmation node and a second confirmation node, each of which is configured as a confirmation identifier, wherein the second confirmation node is configured to verify the identifier in the event that the first confirmation node is inoperable.

[0246] According to one aspect of this disclosure, a plurality of acknowledgment nodes form an acknowledgment network, and the network is configured to be extended by communicatively coupling the plurality of acknowledgment nodes to added acknowledgment nodes.

[0247] According to one aspect of this disclosure, the first node is configured to transmit an identifier to at least one second node via at least one of a public network and a private network.

[0248] According to one aspect of this disclosure, at least one second node is configured to restrict the transmission of at least one second node's identification certificate to the first node in response to a first node transmitting via a public network.

[0249] According to one aspect of this disclosure, at least one second node is configured to transmit the identity verification of at least one second node to the first node in response to a transmission made by the first node via a private network.

[0250] According to one aspect of this disclosure, the system includes a federated identity provider configured to selectively request identity verification based on transmissions made by a first node via a private network or a public network.

[0251] According to one aspect of this disclosure, the identifier is post-quantum secure.

[0252] According to one aspect of this disclosure, the first node and at least one second node form a zero-knowledge scalable transparent knowledge argument (ZK-STARK).

[0253] According to one aspect of this disclosure, the first node transmits the identifier in the form of zero-knowledge proof (ZKP).

[0254] According to one aspect of this disclosure, at least one second node includes a ZKP validator.

[0255] According to one aspect of this disclosure, the system includes at least one acknowledgment unit configured to confirm ZKP.

[0256] According to one aspect of this disclosure, at least one second node is communicatively coupled to the blockchain to verify the identifier.

[0257] According to one aspect of this disclosure, the identifier is created via a polynomial commitment scheme.

[0258] According to one aspect of this disclosure, the communication platform includes conferencing software configured to present a confidence level, wherein the confidence level represents user authentication for a user of the conferencing software.

[0259] According to one aspect of this disclosure, at least one second node is configured as a request identifier, and the identifier includes audio communication for key exchange.

[0260] According to one aspect of this disclosure, it is requested that in-band audio pitch be used to verify the identifier.

[0261] According to one aspect of this disclosure, the in-band audio tone is periodically adjusted during virtual meetings on conferencing software.

[0262] According to one aspect of this disclosure, the in-band audio pitch is above the hearing range.

[0263] According to one aspect of this disclosure, audio communication includes voice audio of a user of conferencing software, which is sampled by at least one second node to verify the identity.

[0264] According to one aspect of this disclosure, the identifier includes video communication for key exchange via conferencing software.

[0265] According to one aspect of this disclosure, video communication includes video data representing a user of conferencing software, and at least one second node is configured to verify the video data as representing a user by comparing an identifier with authorized user data.

[0266] According to one aspect of this disclosure, the identifier is implemented via out-of-band communication relative to video and audio streaming on the conferencing software.

[0267] According to one aspect of this disclosure, out-of-band communication includes the transmission of at least one of IP address data and operating system information.

[0268] According to one aspect of this disclosure, the authorized user data includes authorized IP addresses, and the comparison of the identifier with the authorized user data includes a comparison of the IP address data with the authorized IP addresses.

[0269] According to one aspect of this disclosure, the communication platform includes email communication software.

[0270] According to one aspect of this disclosure, at least one second node is configured to selectively limit the transmission of confidence levels based on a comparison of the identifier with authorized user data.

[0271] According to one aspect of this disclosure, at least one second node is configured to selectively restrict the transmission of the level of verification details of the confidence level based on a comparison of the identifier with authorized user data.

[0272] According to one aspect of this disclosure, at least one second node is configured to determine a security level corresponding to the identifier based on a comparison of the identifier with authorized user data.

[0273] According to one aspect of this disclosure, the system is configured to provide decentralized identity by sharing confidence levels and details with a different set of federated nodes.

[0274] According to one aspect of this disclosure, the system includes an artificial intelligence engine configured to train at least one machine learning model using past certifications.

[0275] According to one aspect of this disclosure, the machine learning model is trained to determine the confidence level based on past certifications.

[0276] According to one aspect of this disclosure, a method for authentication on a communication platform includes: transmitting an identifier to at least one second node via a first node; receiving the identifier at at least one second node; comparing the identifier with authorized user data stored in a database storing authorized user data; determining a confidence level of the first node; transmitting a signal indicating the confidence level; and presenting an indication of the confidence level at a user interface in response to the signal.

[0277] According to another aspect of this disclosure, a system for authentication on a conferencing platform includes a database configured to store authorized user data. The system includes a first node that creates identifiers and is configured to transmit the identifiers. The system includes at least one second node configured to: receive the identifiers, compare the identifiers with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0278] According to another aspect of this disclosure, a system for authentication on an email communication platform includes a database configured to store authorized user data. The system includes a first node that creates an identifier and is configured to transmit the identifier. The system includes at least one second node configured to: receive the identifier, compare the identifier with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0279] According to another aspect of this disclosure, a system for identity authentication includes a database configured to store authorized user data. The system includes a first node that creates an identifier and is configured to transmit the identifier. At least one second node is configured to: receive the identifier, compare the identifier with authorized user data, determine a confidence level for the first node, and transmit a signal indicating the confidence level. The system includes a user interface configured to present an indication of the confidence level in response to the signal.

[0280] Those skilled in the art will understand that the construction of the described disclosure and other components is not limited to any particular material. Unless otherwise described herein, other exemplary embodiments of this disclosure may be formed from a variety of materials.

[0281] For the purposes of this disclosure, the term "coupled" (in all its forms, coupling, etc.) generally means the direct or indirect engagement of two components (electrical or mechanical). This engagement can be inherently fixed or inherently movable. Such engagement can be achieved by two components (electrical or mechanical) and any additional intermediate member that forms a single unit with or between the two components. Unless otherwise stated, such engagement can be inherently permanent, or inherently removable or detachable.

[0282] It is equally important to note that the construction and arrangement of the elements of this disclosure, as illustrated in the exemplary embodiments, are merely illustrative. Although only a few embodiments of the present invention have been described in detail in this disclosure, those skilled in the art will readily understand that many modifications can be made (e.g., variations in the size, dimensions, structure, shape and proportions, parameter values, mounting arrangements, use of materials, color, orientation, etc. of the various elements) without substantially departing from the novel teachings and advantages of the subject matter. For example, elements shown as integrally formed may be composed of multiple parts, or elements shown as multiple parts may be integrally formed; the operation of interfaces may be reversed or otherwise altered; the structure and / or the length or width of components or connectors or other elements of the system may be changed; and the nature or number of adjustment positions provided between elements may be changed. It should be noted that the elements and / or components of the system may be composed of any of a variety of materials providing sufficient strength or durability, in any of a variety of colors, textures, and combinations. Therefore, all such modifications are intended to be included within the scope of this invention. Without departing from the spirit of this innovation, other substitutions, modifications, alterations, and omissions may be made to the design, operating conditions, and arrangement of the desired and other exemplary embodiments.

[0283] It should be understood that any described process or step within a described process may be combined with other disclosed processes or steps to form a structure within the scope of this disclosure. The exemplary structures and processes disclosed herein are for illustrative purposes and should not be construed as restrictive.

Claims

1. A system for authentication, the system comprising: Confirm system; A proxy, configured to transmit a first credential indicating the identifier to the authentication system and a second credential indicating the identifier to an authentication service, wherein the authentication system includes: A database configured to store authorized user data; as well as A portal configured to provide selection of a verification service from a plurality of verification services, wherein the verification system is configured to compare the first credential with the authorized user data, determine a confidence level of the validity of the identifier based on the comparison of the first credential with the authorized user data, receive verification of the second credential from the verification service, and modify the confidence level based on the verification.

2. The system of claim 1, wherein the verification service includes a carrier, and wherein the second credential includes a call detail record.

3. The system according to claim 2, wherein the call details record includes the cell tower location.

4. The system according to any one of claim 1 or claim 2, wherein the operator is configured to determine the authentication using at least one of a Secure Telephone Identity Revisit (STIR) protocol and a token-based signature-based assertion message processing (SHAKEN) protocol.

5. The system according to any one of claims 1 to 4, further comprising: The signature service between the verification system and the agent, wherein the signature service employs a verifiable data structure.

6. The system according to any one of claims 1 to 5, further comprising: A certificate authority configured to issue certificates to the agent via the signature service; Logs, which are configured to record pre-certificates; as well as A monitor configured to monitor the logs.

7. The system of claim 6, wherein the log is append-only and transparent.

8. The system according to any one of claims 6 or 7, wherein the monitor is configured to detect malicious certificates.

9. The system according to any one of claims 6 to 8, wherein the log utilizes a Merckle tree to track the pre-certificate.

10. The system according to any one of claims 1 to 9, wherein the verification system provides certificate transparency.

11. The system according to any one of claims 1 to 5, wherein the verification system employs a declarer model to verify the agent's signature.

12. The system of claim 11, further comprising: A certificate authority configured to publish a list when issuing certificates to the agent.

13. The system of claim 12, further comprising: A verifier, configured to verify the list from the certificate authority.

14. The system according to claim 13, wherein, In response to the detection of an anomaly list, the portal is configured to present an indication of the anomaly list.

15. The system of claim 14, wherein the verification system is configured to revoke authentication in response to detecting the anomaly list.

16. The system according to any one of claims 1 to 15, wherein the verification service is a third-party service separate from the confirmation system.

17. The system according to any one of claims 1 to 16, the system further comprising: At least one application programming interface (API) communicatively couples the verification service with the agent and the confirmation system.

18. The system of claim 17, wherein the at least one API comprises a first API at the verification system and a second API installed on the machine running the agent.

19. The system according to any one of claims 1 to 18, wherein the verification service interfaces with the agent via a software development kit (SDK).

20. The system according to any one of claims 1 to 18, wherein the verification service interfaces with the agent via a network hook.

21. The system according to any one of claims 1 to 18, wherein the verification service interfaces with the agent via a World Wide Web service.

22. The system according to any one of claims 1 to 18, wherein the verification service includes endpoint services and detection.

23. The system according to any one of claims 1 to 22, wherein the plurality of verification services are presented via the portal through a virtual marketplace.

24. The system according to any one of claims 1 to 23, wherein the verification system is configured to determine deepfake conditions in response to the confidence level.

25. The system according to any one of claims 1 to 24, wherein the authorized user data comprises immutable data stored on the database.

26. The system according to any one of claims 1 to 25, wherein the system further comprises: The agent runs on a user device, wherein the first credential includes data representing the identity of the user device, the data including at least one of location information, voice information, and video information.

27. The system according to any one of claims 1 to 26, wherein the verification system comprises at least one machine learning model trained to generate the confidence level based on the first credential and the second credential.

28. The system of claim 27, further comprising: An artificial intelligence engine that uses the first credential and the verification to train the at least one machine learning model.

29. The system of any one of claim 27 or claim 28, wherein the at least one machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the first credential and the second credential.

30. The system of claim 29, wherein the verification system is configured to determine a reliability score for the verification service based on the weight of the second credential, and to present an indication of the reliability score at the portal.

31. The system of claim 30, wherein the verification system is configured to recommend an alternative verification service among the plurality of verification services based on the reliability score.

32. The system according to any one of claims 1 to 26, wherein the second credential comprises the biometric data of the user of the agent.

33. The system of claim 32, wherein the biometric data includes at least one of heart rate and electrocardiogram, and wherein the verification service includes a heart rate monitoring system for the user.

34. The system of claim 33, wherein the confirmation system comprises at least one machine learning model trained to generate the confidence level based on the electrocardiogram of the user to whom the agent is registered.

35. The system of claim 34, wherein the heart rate monitoring system is configured to identify the user based on the electrocardiogram.

36. The system according to any one of claims 34 or 35, further comprising: An artificial intelligence engine that uses the electrocardiogram to train the machine learning model.

37. The system of any one of claims 35 or 36, wherein the at least one machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the first credential and the electrocardiogram.

38. The system of claim 26, wherein the user equipment is configured to run conferencing software or an email application that presents the confidence level.

39. The system of claim 26, wherein the data includes at least one of a text acknowledgment via an instant messaging application running on the user equipment and data from a World Wide Web application running on the user equipment.

40. The system of claim 26, wherein the voice information is provided via at least one of VoIP and PSTN.

41. The system according to any one of claims 1 to 40, wherein the modification includes processing the first credential and the verification in the integrated learning module to modify the confidence level.

42. The system of claim 41, wherein the first credential is part of a set of first credentials indicating the identifier to the verification system, and the second credential is part of a set of second credentials indicating the identifier to the verification service.

43. The system of claim 42, wherein the ensemble learning module includes processing the set of first credentials and a plurality of basic models of the verification, and processing the outputs of the plurality of basic models to determine the confidence level, and a master ensemble model.

44. The system of claim 43, wherein the plurality of basic models includes at least one first basic model for processing the set of first credentials and at least one second basic model for processing the verification.

45. The system of claim 43, wherein the at least one second base model comprises a plurality of second base models configured to process a plurality of authentications from the plurality of authentication services in response to the plurality of authentication services receiving a plurality of second credentials.

46. ​​The system of claim 45, wherein the verification system categorizes the plurality of verification services according to the type of verification provided by each of the plurality of verification services.

47. The system of claim 46, wherein the type includes at least one of video verification, audio verification, geolocation verification, text verification, and email verification.

48. The system according to any one of claims 46 to 47, wherein the plurality of second basic models includes a second basic model for each category of the verification service.

49. The system of claim 48, wherein the plurality of basic models includes an intermediate basic model, the intermediate basic model processing the outputs of the plurality of second basic models and generating a single output for the main integrated model.

50. The system of claim 49, wherein the master integration model uses at least one output from the at least one first basic model to process the single output.

51. The system according to any one of claims 43 to 50, wherein the master ensemble model is trained using supervised learning to classify the confidence levels output by the confirmation system.

52. The system according to any one of claims 43 to 51, wherein at least one of the plurality of basic models uses supervised learning for machine learning regression.

53. A system for performing identity authentication on a communication platform, the system comprising: A database configured to store authorized user data; The first node creates an identifier and is configured to transmit the identifier; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

54. The system of claim 53, further comprising: A signature service between the first node and the at least one second node, wherein the signature service employs a verifiable data structure.

55. The system of claim 54, further comprising: A certificate authority configured to issue certificates to the first node via the signature service; Logs, which are configured to record pre-certificates; as well as A monitor configured to monitor the logs.

56. The system of claim 55, wherein the log is append-only and transparent.

57. The system according to any one of claims 54 or 55, wherein the monitor is configured to detect malicious certificates.

58. The system according to any one of claims 53 to 57, wherein the signature service employs a declarer model to verify the signature of the first node.

59. The system according to any one of claims 53 to 58, the system further comprising: A certificate authority configured to publish a list when issuing a certificate to the first node.

60. The system of claim 59, further comprising: A verifier, configured to verify the list from the certificate authority.

61. The system according to any one of claims 53 to 60, wherein the identifier is post-quantum secure.

62. The system according to any one of claims 53 to 61, wherein the at least one second node is communicatively coupled to the blockchain to verify the identity.

63. The system according to any one of claims 53 to 62, wherein the communication platform includes conferencing software configured to present the confidence level, wherein the confidence level represents user authentication for a user of the conferencing software.

64. The system according to any one of claims 53 to 63, wherein the communication platform includes email communication software.

65. The system according to any one of claims 53 to 64, wherein the identifier includes at least one of a text acknowledgment via an instant messaging application and data from a World Wide Web application.

66. The system according to any one of claims 53 to 65, wherein the identifier includes at least one of voice information provided via at least one of VoIP and PSTN, text confirmation transmitted via instant messaging, video information, and location information.

67. The system according to any one of claims 53 to 66, the system further comprising: A third-party verification service, which communicates with the first node and includes endpoint services and detection for detecting anomalous software running on the first node.

68. The system of claim 67, wherein the at least one second node comprises at least one machine learning model trained to generate the confidence level based on the detection of the anomalous software.

69. The system of claim 67, further comprising: An artificial intelligence engine that uses the detection of the anomalous software to train the machine learning model.

70. The system of any one of claims 68 or 69, wherein the machine learning model is configured to adjust the function used to determine the confidence level by adjusting the relative functional weights of at least one of the verifications from the endpoint service and the detection.

71. The system according to any one of claims 53 to 70, wherein the system is configured to provide decentralized identity by sharing the confidence level and details with a different set of federated nodes.

72. The system according to any one of claims 53 to 71, wherein the at least one second node comprises a federated network, and the system further comprises: The third node on the federated network, wherein the first node is connected to the at least one second node from outside the federated network, wherein the at least one second node is configured to limit the transmission of the confidence level of the third node in response to the first node being outside the federated network.

73. The system according to any one of claims 53 to 70, wherein the third-party verification service is configured to share the verification, and the at least one second node is configured to restrict the transmission of the confidence level to the third-party verification service.

74. The system according to any one of claims 53 to 71, wherein the at least one second node is configured to selectively share the confidence level of the node via a federated network.

75. The system according to any one of claims 53 to 74, wherein the at least one second node is configured to selectively limit the transmission of the confidence level based on the comparison between the identifier and the authorized user data.

76. The system according to any one of claims 53 to 75, wherein the at least one second node is configured to determine a security level corresponding to the identifier based on the comparison between the identifier and the authorized user data.

77. The system of claim 53, wherein the at least one second node comprises a plurality of acknowledgment nodes, each acknowledgment node being configured to redundantly verify the identifier.

78. The system of claim 77, wherein the plurality of confirmation nodes includes a first confirmation node and a second confirmation node, the first confirmation node and the second confirmation node are each configured to confirm the identifier, wherein the second confirmation node is configured to verify the identifier in the event that the first confirmation node is inoperable.

79. The system of any one of claims 77 or 78, wherein the plurality of acknowledgment nodes form an acknowledgment network, and wherein the network is configured to be extended by communicatively coupling the plurality of acknowledgment nodes to additional acknowledgment nodes.

80. The system of claim 79, wherein the first node is configured to transmit the identifier to the at least one second node via at least one of a public network and a private network.

81. The system of claim 80, wherein the at least one second node is configured to restrict the transmission of the identity certificate of the at least one second node to the first node in response to a transmission by the first node via the public network.

82. The system of claim 81, wherein the at least one second node is configured to transmit an identification certificate of the at least one second node to the first node in response to a transmission by the first node via the private network.

83. The system according to claim 82, further comprising: A federated identity provider configured to selectively request the transmission of the identity certificate based on the transmission made by the first node via the private network or the public network.

84. The system according to any one of claims 53 to 83, wherein the identifier is post-quantum secure.

85. The system according to any one of claims 53 to 84, wherein the first node and the at least one second node form a zero-knowledge scalable transparent knowledge argument (ZK-STARK).

86. The system according to any one of claims 53 to 85, wherein the first node transmits the identifier in the form of zero-knowledge proof (ZKP).

87. The system of claim 86, wherein the at least one second node comprises a validator of the ZKP.

88. The system of claim 87, further comprising: At least one acknowledgment device, the at least one acknowledgment device being configured to acknowledge the ZKP.

89. The system according to any one of claims 53 to 88, wherein the at least one second node is communicatively coupled to the blockchain to verify the identity.

90. The system of claim 86, wherein the identifier is created via a polynomial commitment scheme.

91. The system of claim 63, wherein the at least one second node is configured to request the identifier, and wherein the identifier includes audio communication for key exchange.

92. The system of claim 91, wherein the request is verified using in-band audio tone.

93. The system of claim 92, wherein the in-band audio tone is periodically adjusted during a virtual meeting on the conferencing software.

94. The system of claim 92, wherein the in-band audio pitch is above the hearing range.

95. The system of claim 91, wherein the audio communication comprises voice audio of a user of the conferencing software, the voice audio being sampled by the at least one second node to verify the identifier.

96. The system of claim 90, wherein the identifier includes video communication for key exchange via the conferencing software.

97. The system of claim 96, wherein the video communication includes video data representing a user of the conferencing software, and wherein the at least one second node is configured to verify the video data as representing the user by comparing the identifier with the authorized user data.

98. The system according to any one of claims 63 or 91 to 97, wherein the identification is implemented via out-of-band communication relative to video and audio streaming on the conferencing software.

99. The system of claim 98, wherein the out-of-band communication includes the transmission of at least one of IP address data and operating system information.

100. The system of claim 99, wherein the authorized user data includes an authorized IP address.

101. The system of claim 100, wherein the comparison of the identifier and the authorized user data includes a comparison of the IP address data and the authorized IP address.

102. The system according to any one of claims 53 to 68, the system further comprising: An artificial intelligence engine, configured to train at least one machine learning model using past certifications.

103. The system of claim 102, wherein the machine learning model is trained to determine the confidence level based on the past certifications.

104. A method for authentication, the method comprising: A verification service is selected from multiple verification services that are separate from the verification system via the verification system's portal; The first credential indicating the identifier is received from the agent at the confirmation system. Compare the first credential with the authorized user data stored in the authorized user database; The confidence level of the validity of the identifier is determined based on the comparison between the first credential and the authorized user data; Transmit a second credential from the agent indicating the identifier to the verification service; The verification of the second credential is received via the verification service; The confidence level is modified based on the verification.

105. The method according to claim 104, further comprising: The various verification services are presented at the portal via a virtual marketplace.

106. The method according to any one of claims 104 or 105, the method further comprising: The deepfake conditions are determined in response to the confidence level.

107. The method according to any one of claims 104 to 106, the method further comprising: At least one machine learning model is trained via an artificial intelligence engine to generate the confidence level based on the first credential and the second credential.

108. The method according to any one of claims 104 to 107, the method further comprising: The function used to determine the confidence level is adjusted by adjusting the relative functional weights of the first and second credentials.

109. The method according to claim 108, further comprising: The reliability score of the verification service is determined based on the weight of the second credential, and an indication of the reliability score is presented at the portal.

110. The method according to claim 109, further comprising: The verification system recommends alternative verification services among the plurality of verification services based on the reliability score.

111. A method for authentication, the method comprising: Choose a verification service from multiple verification services; The system receives the first credential indicating the identifier from the agent. Compare the first credential with the authorized user data; The confidence level of the validity of the identifier is determined based on the comparison between the first credential and the authorized user data; Transmit a second credential indicating the identifier to the verification service; Receive verification of the second credential from the verification service; The confidence level is modified based on the confirmation.

112. The method according to claim 111, further comprising: The deepfake conditions are determined in response to the confidence level.

113. The method according to any one of claims 111 or 112, the method comprising: The first credential and the verification are processed in the ensemble learning module to modify the confidence level.

114. The method of claim 113, wherein the first credential is part of a set of first credentials indicating the identifier to the verification system, and the second credential is part of a set of second credentials indicating the identifier to the verification service.

115. The method of claim 114, wherein the ensemble learning module includes processing the set of first credentials and a plurality of basic models of the verification, and processing the outputs of the plurality of basic models to determine the confidence level, and a master ensemble model.

116. The method of claim 115, wherein the plurality of basic models includes at least one first basic model for processing the set of first credentials and at least one second basic model for processing the verification.

117. The method of claim 115, wherein the at least one second base model comprises a plurality of second base models configured to process a plurality of authentications from the plurality of authentication services in response to the plurality of authentication services receiving a plurality of second credentials.

118. The method of claim 117, wherein the method comprises: The multiple verification services are categorized based on the type of verification provided by each of the multiple verification services.

119. The method of claim 118, wherein the type includes at least one of video verification, audio verification, geolocation verification, text verification, and email verification.

120. The method of any one of claims 117 to 118, wherein the plurality of second basic models include a second basic model for each category of the verification service.

121. The method of claim 120, wherein the plurality of basic models includes an intermediate basic model, the intermediate basic model processing the outputs of the plurality of second basic models and generating a single output for the master integrated model.

122. The method of claim 121, wherein the master integration model processes the single output using at least one output from the at least one first base model.

123. The method according to any one of claims 115 to 122, wherein the master ensemble model is trained using supervised learning to classify the confidence levels output by the confirmation system.

124. The method according to any one of claims 115 to 123, wherein at least one of the plurality of basic models uses supervised learning for machine learning regression.

125. A system for performing identity authentication on a communication platform, the system comprising: A database configured to store authorized user data; The first node creates an identifier and is configured to transmit the identifier; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

126. The system of claim 125, wherein the first node is configured to transmit credentials to an authentication service, and wherein at least one second node is configured to receive authentication from the authentication service based on the credentials.

127. The system of claim 126, wherein the verification system is configured to modify the confidence level based on the verification.

128. The system according to any one of claims 126 or 127, further comprising: At least one application programming interface (API) communicatively couples the verification service to the first node and the at least one second node.

129. The system according to any one of claims 126 to 128, the system further comprising: A portal that allows users to select from multiple verification services presented via a virtual marketplace.

130. The system according to any one of claims 126 to 129, wherein the authorized user data comprises immutable data stored on the database.

131. The system according to any one of claims 126 to 130, wherein the identifier is post-quantum secure.

132. The system according to any one of claims 126 to 131, wherein the at least one second node is communicatively coupled to the blockchain to verify the identity.

133. The system of any one of claims 126 to 132, wherein the communication platform includes conferencing software configured to present the confidence level, wherein the confidence level represents user authentication for a user of the conferencing software.

134. The system according to any one of claims 126 to 133, wherein the communication platform includes email communication software.

135. The system of any one of claims 126 to 134, wherein the verification includes at least one of text confirmation via an instant messaging application running on the user equipment and data from a World Wide Web application running on the user equipment.

136. The system according to any one of claims 126 to 135, further wherein the credential includes voice information provided via at least one of VoIP and PSTN.

137. A system for performing identity authentication on a communication platform, the system comprising: A database configured to store authorized user data; The first node is configured as follows: Transmission identifier; as well as Send the credentials to the verification service; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; Receive verification from the verification service based on the credentials; The confidence level is updated based on the verification. as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

138. A method for performing identity authentication on a communication platform, the method comprising: Transmit the identifier to at least one second node via the first node; The identifier is received at at least one second node; The identifier is compared with the authorized user data stored in the database storing authorized user data; Determine the confidence level of the first node; Transmit a signal indicating the confidence level; as well as In response to the signal, an indication of the confidence level is presented at the user interface.

139. A system for identity authentication on a conference platform, the system comprising: A database configured to store authorized user data; The first node creates an identifier and is configured to transmit the identifier; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

140. A system for authentication on an email communication platform, the system comprising: A database configured to store authorized user data; The first node creates an identifier and is configured to transmit the identifier; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

141. A system for identity authentication, the system comprising: A database configured to store authorized user data; The first node creates an identifier and is configured to transmit the identifier; At least one second node, wherein the at least one second node is configured to: Receive the identifier; Compare the identifier with the authorized user data; Determine the confidence level of the first node; as well as Transmit a signal indicating the confidence level; as well as A user interface configured to present an indication of the confidence level in response to the signal.

Images