DEVICE, SYSTEM AND METHOD FOR ENSURING COMMUNICATION INTEGRITY - Patent application

The proposed solution addresses the issue of session integrity by generating and verifying integrity certificates using input signals and private keys, ensuring secure access and preventing session hijacking even when end-user systems are compromised.

JP2025513811APending Publication Date: 2025-04-30EMORY UNIVERSITY
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024559635
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2022-04-14
Filing Date
2023-04-12
Publication Date
2025-04-30

AI Technical Summary

Technical Problem

Current cybersecurity measures, such as one-time password tokens and push-based mobile apps, fail to maintain session integrity when an end-user's computer or remote server is compromised by an attacker, allowing session hijacking and illicit commands on remote servers.

Method used

A computer implementation method that generates an integrity certificate using input signals and a private key, which is then verified throughout the communication session to ensure secure access and session integrity, even in the presence of cyberattacks.

Benefits of technology

The solution effectively maintains session integrity and secure access throughout the communication session, preventing session hijacking and ensuring the reliability of remote server interactions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025513811000001_ABST
    Figure 2025513811000001_ABST
Patent Text Reader

Abstract

Devices, systems, and methods are provided for ensuring the integrity of communications. An input signal associated with a user accessing a client server using a remote connection may be received. The input signal may identify an input received via an interface. An integrity module may be executed to generate an integrity certificate using the input signal, a private key, and a sequential identifier corresponding to the input. The integrity certificate may be generated for use during a validation process associated with the input signal. The integrity certificate and the input signal may be transmitted to the client server using one or more channels. The client server may forward the integrity certificate and the input signal to a validation server configured to verify the integrity certificate.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Provisional Application No. 63 / 330,875, filed April 14, 2022, which is incorporated by reference herein in its entirety for all purposes.

[0002] The present disclosure relates generally to information security and, more specifically, but not by way of limitation, to devices, systems and methods for ensuring the integrity of communications. [Background technology]

[0003] Incidents of cybersecurity attacks aimed at gaining access to and control of organizational resources (such as credit card databases, code repositories, confidential intellectual property, and blueprints) are increasing year by year. The most common attack mode involves compromising an employee's computer in one of a myriad of ways (remote attacks, phishing campaigns, infected attachments, malware via browsers, etc.). With access to an employee's computer, an attacker can now move laterally between computers within the organization via remote access to the machine by guessing the employee's credentials.

[0004] Modern attack tools such as IPS / IDS systems and antivirus have become so sophisticated that they can evade security tools, making it difficult to detect if a computer has been hacked or compromised. As a result, smarter organizations are moving to a "zero trust" security policy, which assumes that end-user devices (and potentially other servers) will be compromised.

[0005] In line with this movement, some form of authentication technology, typically multi-factor authentication such as one-time password (OTP) tokens or push-based mobile apps, is implemented to improve cybersecurity. These technologies provide confidentiality and integrity to the session with the remote server when the end user authenticates upon login. However, these technologies cannot maintain such security properties if the end user or the remote server is compromised by an attacker. Specifically, these technologies generally cannot detect or prevent an attacker who has compromised the end user's computer from "stealing" an established (e.g., post-verification) session to the remote server or initiating a covert session, such as a background session. In the absence of session integrity during a compromise, an attacker may be able to impersonate the end user and issue unauthorized commands on the remote server. Summary of the Invention [Means for solving the problem]

[0006] Therefore, there is a need for devices and systems that can provide secure access, and in particular session integrity, throughout a communication session with a remote server, as well as detect cyber attacks, even if there are such attacks on an end user's system.

[0007] In some embodiments, a computer-implemented method is provided that includes receiving an input signal associated with a user accessing a client server using a remote connection, the input signal identifying an input (e.g., a keystroke, a mouse click or movement, a joystick or game controller interaction, or a touch screen interaction) received via an interface (e.g., a keyboard, a mouse, a joystick, a game controller, etc.). The method further includes executing an integrity module to generate an integrity certificate using the input signal corresponding to the input and a private key, the integrity certificate being generated for use during a verification process associated with the input signal. In some examples, executing the integrity module to generate the integrity certificate may include using a sequential identifier (e.g., a counter, a timestamp, a suitable function derived from the counter, etc.) in addition to the input signal and the private key. The integrity module may generate a tuple such that the tuple encoding the integrity certificate includes a sequential identifier indicating an order of the input signals and an integrity key. The integrity key may be created based on the input signal, the private key, and the sequential identifier using a cryptographic protocol (e.g., a cryptographic hash function, a digital signature scheme, etc.). The method further includes transmitting the integrity certificate and the input signal using the one or more channels to a client server. The client server may be configured to forward the integrity certificate and the input signal to a validation server configured to verify the integrity certificate.

[0008] In some embodiments, a system is provided that includes one or more data processors and a non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform portions or all of one or more of the methods disclosed herein. The instructions may include actions associated with one or more of the methods disclosed herein.

[0009] In some embodiments, there is provided a computer program product tangibly embodied in a non-transitory machine-readable storage medium, the computer program product including instructions configured to cause one or more data processors to perform part or all of one or more of the methods disclosed herein. The instructions may include actions associated with one or more of the methods disclosed herein.

[0010] Some embodiments of the present disclosure include a system comprising one or more data processors. In some embodiments, the system comprises a non-transitory computer-readable storage medium comprising instructions that, when executed on the one or more data processors, cause the one or more data processors to perform a portion or all of one or more methods and / or a portion or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium, the computer program product comprising instructions configured to cause the one or more data processors to perform a portion or all of one or more methods and / or a portion or all of one or more processes disclosed herein.

[0011] The terms and expressions employed are used as terms of description and not of limitation, and the use of such terms and expressions is not intended to exclude any equivalents of the features or portions thereof shown and described, and it will be recognized that various modifications may be included within the scope of the claims of the present invention. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be employed by those skilled in the art, and such modifications and variations are deemed to be included within the scope of the present invention as defined by the appended claims.

[0012] The present disclosure may be better understood with reference to the following drawings and description. The components in the drawings are not necessarily to scale, emphasis instead being placed on illustrating the principles of the present disclosure. The present disclosure is described in conjunction with the accompanying drawings. [Brief description of the drawings]

[0013] [Figure 1] 1 illustrates an example system environment for verifying input integrity of an input stream using a generated key, according to an embodiment.

[0014] [Diagram 2] 1 illustrates an example system environment for validating a set of input signals input from a web server using a set of generated integrity keys, according to an embodiment.

[0015] [Diagram 3] 2 is an example of a hardware implementation of the integrity module shown in FIG. 1, according to an embodiment.

[0016] [Figure 4] 2 is an example of a software implementation of the integrity module shown in FIG. 1, according to an embodiment.

[0017] [Diagram 5] 1 shows a flowchart illustrating a method for generating an integrity certificate for an input(s) of a stream using a hardware implementation of an integrity module and validating the input using the generated certificate, according to an embodiment.

[0018] [Figure 6] 1 shows a flowchart illustrating a method for generating an integrity certificate for an input(s) of a stream using a software implementation of an integrity module and validating the input using the generated certificate, according to an embodiment.

[0019] [Figure 7]1 shows a flowchart illustrating a method for generating an integrity certificate for a stream of input(s) and using the generated certificate within a browser to validate the input(s), according to an embodiment.

[0020] [Figure 8] FIG. 13 is a data flow diagram illustrating the data flow for pairing an agent's integrity key to a terminator's user identifier, according to an embodiment.

[0021] [Figure 9] FIG. 1 is a simplified block diagram of an example computing system for implementing certain embodiments disclosed herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] In the following detailed description, many specific details are set forth, such as examples of specific components, devices, and methods, to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent to those skilled in the art that these specific details are not necessary to practice the embodiments of the present disclosure. In other instances, well-known materials or methods have not been described in detail so as not to unnecessarily obscure the embodiments of the present disclosure. While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments of the present disclosure are shown by way of example in the drawings and described in detail herein. However, it is to be understood that there is no intention to limit the present disclosure to the particular forms disclosed, but on the contrary, the present disclosure encompasses all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure.

[0023] The present disclosure generally relates to techniques that may authenticate inputs associated with a user throughout a session of communication to control access to a client server. Examples of inputs may include keystrokes, mouse clicks or movements, joystick or game controller interactions, or touch screen interactions. The disclosed techniques may be configured to authenticate each input signal and / or a subset of input signals in a stream of user input (e.g., each keystroke) detected by a human interface device (HID) connected to a user computing device by verifying a private key associated with that user and / or device transmitted with each input signal. In some examples, the stream of user input that is authenticated may include one or more of keystrokes, mouse clicks, mouse movements, or other user input suitable as input signals. For example, a subset of the stream that includes keystrokes may be interleaved with another subset of the stream that includes mouse movements.

[0024] Private keys according to the present disclosure are kept internal (e.g., by preventing private keys from being exposed to potential malicious actors) and thus are not directly communicated or directly externalized. Examples of private keys may include symmetric or asymmetric keys for encryption. Creating a symmetric key may include using symmetric encryption, and creating an asymmetric key may include asymmetric public key encryption. In some examples, a private key may be generated in an external system (e.g., an external key generator) prior to uploading a private key for use according to the present disclosure. By using private keys internally, the techniques of the present disclosure may provide security and integrity (e.g., a relatively high degree of confidence that a message has not been altered) of the entire communication session. The techniques of the present disclosure may also be able to detect attacks (e.g., cyber attacks) or other actions by malicious actors by automatically validating inputs (i.e., matching user inputs with integrity certificates), so that appropriate security measures can be implemented to address the attacks. Thus, using the processes and devices described herein, the security and integrity of data transmitted during an entire communication session (e.g., control messages, input signals, etc.) can be substantially ensured, thereby reducing the risk of unauthorized access to protected computing resources (e.g., computers, networks, or transmitted data). Thus, the techniques of this disclosure may address deficiencies in current authentication techniques by, for example, verifying each input signal during a communication session rather than using a one-time user authentication to initiate the communication session.

[0025] Various embodiments implementing these techniques are described herein, including systems, methods, devices, modules, models, algorithms, networks, structures, processes, and computer program products. Some embodiments of the present disclosure include a system with one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium that includes instructions that, when executed on the one or more data processors, cause the one or more data processors to perform a portion or all of one or more methods and / or a portion or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium, the computer program product including instructions configured to cause the one or more data processors to perform a portion or all of one or more methods and / or a portion or all of one or more processes disclosed herein.

[0026] The terms and expressions employed are used as terms of description and not of limitation, and the use of such terms and expressions is not intended to exclude any equivalents of the features or portions thereof shown and described, and it will be recognized that various modifications may be included within the scope of the claims of the present invention. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be employed by those skilled in the art, and such modifications and variations are deemed to be included within the scope of the present invention as defined by the appended claims.

[0027] This description provides only preferred exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, this description of preferred exemplary embodiments will provide those skilled in the art with an effective description for implementing various embodiments. It will be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.

[0028] In this description, specific details are set forth to provide a thorough understanding of the embodiments. However, it will be understood that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0029] FIG. 1 illustrates an example of a system environment 100 in which inputs 132 (e.g., keystrokes) to a user computing system 110 detected using an interface 130 during a communication session with or through one or more client servers 170 may be verified. In some embodiments, the system environment 100 may include one or more of a user computing system(s) 110, a network 150, a verification server 160, and / or one or more client server(s) 170. The various systems and components described herein may be in direct logical communication with one another, over a bus, a network, and / or through any other suitable means, or may be individually connected as further described herein. As described in more detail below, suitable programming (i.e., computer programs, software, hardware, firmware, etc.) may be installed or provided on each of the user computing systems 110, the verification server 160, and each remote client server 170 (e.g., agent app 172), and may operate cooperatively to perform the methods of the present disclosure.

[0030] In various embodiments, the user computing system 110 may include a user device 120 associated with the user 106. The user device 120 may include any type of computing device or computer, including, but not limited to, for example, a laptop computer, a personal computer, a network device, a mobile phone, a handheld communication device, or any other device. The user computing system 110 may include at least one interface 130 connected to or incorporated into the user device 120. The interface 130 may be any human interface device (HID) configured to detect a user input 132 and transmit at least one input signal 134 in response to detection of the input 132.

[0031] In this example, as shown in FIG. 1, the interface 130 may be a keyboard capable of transmitting key codes as input signals 134 corresponding to each keystroke entered using the keyboard. The keyboard may transmit each key code in response to the user 106 selecting one or more keyboard keys of the keyboard to enter each keystroke. For example, each key code may be a hexadecimal representation of a physical character typed on the keyboard. The keyboard may include, but is not limited to, a physical keyboard, a touch screen, or a combination thereof, such as a peripheral device connected to the user device 120 using wired means (e.g., a cable) or wireless means such as a Bluetooth connection, among others. It will be appreciated that the interface 130 is not limited to a keyboard and may include alternative and / or additional devices, including, but not limited to, a mouse, a joystick, a game controller, or any combination thereof, among others.

[0032] In various embodiments, the user computing system 110 may include an integrity module 140 disposed between the interface 130 and an operating system or target application of the user device 120. The integrity module 140 may be a hardware or software element configured to generate integrity information (e.g., an integrity certificate 108) regarding at least a subset of the inputs 132 received from the interface 130 and a private key 142 registered with the user device 120 or the user 106 of the integrity module 140. Once the integrity module 140 generates the integrity certificate 108, the integrity module 140 may transmit the integrity certificate 108 to be verified by the validation server 160 during a communication session. The integrity module 140 may be, among other things, a hardware device configured to be connected to the user device 120 and / or the interface 130, software installed on or operated by the user device 120 and / or the interface 130, or a combination thereof. FIG. 3 illustrates an example of a hardware implementation of the integrity module 140, and FIG.

[0033] Each integrity module 140 may store a private key 142 that may be used to authenticate the identity of the user 106 and to validate and authorize the input 132 received by the interface 130 for access to the client server 170. In some embodiments, the integrity module 140 may enable controlled access to protected computing resources. Examples of protected computing resources may include interactive computing environments, software applications, databases, files, and the like. One or more protected computing resources may be associated with the user computing system 110, the client server 170, or a combination thereof. The private key 142 may be a sequence of bits associated with the user 106 of the user device 120 and / or the integrity module 140 and may be shared with the verification server 160. The private key 142 may be a symmetric key or part of an asymmetric key pair that includes a public key and a private key that can be used to decrypt the public key. Examples of symmetric key techniques may include stream ciphers (e.g., ChaCha) or block ciphers (e.g., Advanced Encryption Standard (AES)). Examples of asymmetric key techniques may include elliptic curve cryptography, the Rivest-Shamir-Adleman (RSA) encryption algorithm, etc. If the private key 142 is the public key of an asymmetric key pair, then the private key 142 may be used to encrypt data to generate ciphertext, while the private key may be used to decrypt the ciphertext. In some embodiments, instead of being associated with the user 106, the private key 142 may be associated with the user device 120, a virtual machine, or another suitable device.

[0034] Each integrity module 140 may also include one or more sequential identifiers 144 (e.g., a counter, a timestamp, a random number, any suitable function derived from an underlying counter, etc.). In some embodiments, the sequential identifier(s) 144 may be an application transaction counter (ATC). If the sequential identifier 144 is a random number, the integrity module 140 may use a random number seed to initialize a random number generator that generates the sequential identifier(s) 144. In some embodiments, the integrity module 140 may generate an integrity key 114a (also referred to as "IK", "IK1") for each received input 132 using at least a subset of the inputs 132 received from the interface 130, the stored private key 142, and the sequential identifier 144. In this embodiment, the ATC may be a number that is incremented with each generation of the integrity key 114a, such that each number in the integrity certificate 108 is unique. In some other embodiments, there may be multiple ATC counters, for example if the user computing system 110 includes multiple user devices 120, each with its own sequential identifier. In some embodiments, the integrity module 140 may generate the integrity certificate 108 using additional or alternative information to the sequential identifier 144. For example, the integrity module 140 may generate the tuple 112 as the integrity certificate 108 using, among other identifiers, a timestamp, a random or pseudo-random number, a predefined sequence, biometric information, measurement data, other information, or any combination thereof.

[0035] In some embodiments, the integrity key 114a may be generated using an encryption protocol 115 based on the input signal 134 (e.g., a key code corresponding to a character entered using the interface 130, relative mouse coordinates during a click, touch screen tap coordinates, etc.), a stored private key 142, and a sequential value determined by the sequential identifier 144. In some embodiments, the encryption protocol 115 may be a hash-based message authentication code (HMAC). Additionally or alternatively, the encryption protocol 115 may be a coding or encryption of the input 132 using an alternative hash function, a digital signature digest, or a separate encryption key. In this embodiment, the integrity certificate 108 may include the integrity key 114a, the input signal 134, and the sequential identifier 144 or sequential value. In some embodiments, the integrity certificate 108 may be in the form of a 3-tuple <input signal 134, sequential identifier, IK>. Alternatively, the integrity certificate 108 may be a 2-tuple (e.g., <sequential identifier, IK>).

[0036] In some embodiments, the integrity module 140 may transmit the integrity certificate 108 and the input signal 134 to the user device 120, for example, by using a standard or custom USB protocol or Bluetooth protocol. The integrity certificate 108 may be serialized as bits, encoded as characters, or may use other known methods of transferring information over the protocol. In particular, the integrity certificate 108 may be encrypted before being transmitted to the validation server 160, which allows for relatively high security by limiting security risks associated with interception of the integrity certificate 108.

[0037] 6 and 7, in some embodiments, after the user device 120 encodes the integrity certificate 108 using an integrity application 122 (e.g., a driver, a kernel module, a privileged program in user space, etc.), the user device 120 may send a message to the client server 170 that includes encoded characters corresponding to a serialization of the integrity certificate 108 and character(s) corresponding to the input signal 134 to identify a user identifier 116 associated with the communication session, the user device 120, and / or the integrity module 140. For example, the user identifier 116 may be determined using an existing authentication process, may be pre-entered by a system administrator, may be entered by the user 106, may be inferred from other inputs or data, or may be determined in other suitable manners.

[0038] 7, in some embodiments, for example, when implemented with browser support, after the user device 120 encodes the integrity certificate 108 using, for example, an integrity application 122 (e.g., a driver), the user device 120 may send a message using an HTTP request to the client server 170 along with the user identifier 116. Alternatively, the message sent by the user device 120 may be sent over a Websocket, a raw TCP connection, or any other communication protocol.

[0039] After the user identifier 116 is determined, the client server 170 may send a message to the verification server 160 to verify the input 132 detected by the integrity module 140. The message may include the encoded integrity certificate 108, the user identifier 116, and characters corresponding to the input signal 134. In an embodiment in which the interface 130 includes multiple possible input layouts (e.g., keyboard layouts), the message may include a set of possible characters, so that the verification server 160 may compare each character in the set of possible characters to determine a match. For example, if the multiple input layouts are keyboard layouts, the set of possible characters may correspond to physical keys of the interface 130 that the user 106 pressed to generate the input 132. In particular, the user 106 may change the keyboard layout of the interface 130 using language software associated with the operating system of the user device 120. As an illustrative example, changing the keyboard layout from an English keyboard layout to a Spanish keyboard layout may cause the interface 130 to detect "n" as input 132 instead of ";" when the user 106 presses the semicolon key. Thus, a message sent by the client server 170 to the verification server 160 may include both "n" and ";" as possible characters that the verification server 160 may use to determine a match with the input signal 134.

[0040] In some embodiments, the user device 120 may transmit information to the client server 170 and the validation server 160 using separate communication channels 154a-b. Specifically, the user device 120 may transmit the input signal 134 to the client server 170 using a first channel 154a communicatively connecting the user computing system 110 and the client server 170. The user device 120 may transmit the integrity certificate 108 to the validation server 160, the client server 170, or another suitable computing system communicatively connected to the user computing system 110 using a second channel 154b. In additional or alternative embodiments, the two communication channels between the user device 120 and the client server 170 may be combined. In such embodiments, the user device 120 may transmit the integrity certificate 108 over the combined channel, for example as an out-of-band message, according to existing protocols, by sending and later deleting the same content, or by other suitable mechanisms.

[0041] In some embodiments, the validation server 160 may decrypt, deserialize, or decompress the integrity certificate 108 to identify the input signal 134, the sequential identifier 144, and the integrity key (IK1) 114a. The validation server 160 may obtain another private key 142b associated with the user identifier 116 from a user record database 162 communicatively coupled to the validation server 160. In some embodiments, the user record database 162 may also include a security profile for each user 106 that is used to identify appropriate security measures 174 in response to the fraudulent input 164. By way of example, each integrity module 140 and / or user device 120 may be registered with a user identifier 116 and a private key 142. If the integrity module 140 uses asymmetric encryption, the private key 142 may correspond to a public key of an asymmetric key pair generated for the integrity module 140. A private key of the asymmetric key pair corresponding to the private key 142 may be stored on the user device 120. After the verification server 160 identifies another private key 142b associated with the user 106, the verification server 160 may generate another integrity key ("IK2") 114b using the another private key 142b, the sequential identifier 144, and the input signal 134 included in the message, in some embodiments according to the logic described above.

[0042] The verification server 160 may be configured to (i) verify that the input signal 134 included in the message matches the characters included in the message, and (ii) verify that the generated (i.e., second) integrity key 114b associated with the input 132 matches the (first) integrity key 114a received in the message. If this verification is successful (i.e., both pieces of information match), the verification server 160 may communicate with the client server 170 to accept the entered characters, and the client server 170 may accept the entered characters as the input 132. It should be understood that as used herein, characters may refer to mouse movements, keystrokes, mouse clicks, touch screen input, and the like.

[0043] Alternatively, if the validation is not successful, the validation server 160 may determine that the input 132 of the user 106 is fraudulent. In some embodiments, the validation may not be successful because the input 132 is a fraudulent input 164 associated with a malicious actor. The malicious actor may generate the fraudulent input 164 through remote access of the user device 120, for example, after intercepting a remote connection 152 to a client server 170 where the user 106 was authenticated. In some embodiments, through the validation process, the validation server 160 may determine that the input 132 was not physically entered through the interface 130, which causes the validation server 160 to send an alert notification 168 to another computing system (e.g., the client server 170, an external monitoring system 180, or another suitable server). In some embodiments, the external monitoring system 180 may be specified by the user 106 and may include software for monitoring devices, traffic, applications, or a combination thereof. Additionally or alternatively, a malicious actor may install a virus or another type of malware on the user device 120 or user computing system 110 to generate fraudulent input 164, for example, by intercepting and altering the user's 106 input 132.

[0044] If either the input signal 134 or the integrity key 114 is unverifiable (i.e., indicates that the input 132 is fraudulent), the verification server 160 may communicate with the client server 170 to trigger at least one security measure 174 based on a security policy 176 associated with the user 106 (e.g., a security profile stored in the user record database 162). Additionally or alternatively, if the verification server 160 sends an alert notification 168 to the external monitoring system 180, the external monitoring system 180 may identify a security measure 174 to address the alert notification 168. Once the external monitoring system 180 identifies a security measure 174, the external monitoring system 180 may send a response message to the verification server 160 or another appropriate server (e.g., the client server 170) to implement the security measure 174.

[0045] In response to not successfully verifying the input signal 134, the client server 170 may request additional authorization from the user 106, such as by using a separate multi-factor authentication system (e.g., Duo, YubiKey, Google Authenticator, etc.). In some embodiments, the verification server 160 may request additional authorization from the user 106 in response to identifying that the input 132 does not have a corresponding physical input of the user 106. For example, the input 132 may be existing text that the user 106 copied and pasted as the input 132 to interact with the client server 170. When the verification server 160 detects this copy-and-paste input, the verification server 160 may send a request to the user device 120 to obtain additional authorization from the user 106 via the separate multi-factor authentication system. If this additional authorization of the user 106 is valid, the client server 170 may allow the input 132 from the user 106. Alternatively, if the additional authorization is invalid, the client server 170 may implement additional security measures to address the fraudulent input 164 (eg, notifying security personnel).

[0046] The validation server 160, the client server 170, or another suitable computing system (e.g., the external monitoring system 180) may identify an appropriate security measure 174 by applying the rule set. For example, the validation server 160 may select a rule set from one or more rule sets stored in a rule database, which may be local to the validation server 160 or may be remote from the validation server 160. By selecting the appropriate rule set, the validation server 160 or the client server 170 may identify an appropriate security measure 174 to prevent an attacker from migrating or escalating from a compromised user device to another user device communicatively connected to the client server 170. In some examples, a machine learning model may be trained to identify or generate the rule set used to identify the security measure 174 based on, for example, the security policy 176, the fraudulent input 164, or a combination thereof. During training, training data relevant to selecting or generating an appropriate rule set may be provided to the machine learning model, enabling the machine learning model to identify patterns associated with the training data or identify relationships between the training data and output data (e.g., the rule set selected to address the fraudulent input 164).

[0047] Additionally or alternatively, security policy 176 may be configured, at least in part, by an administrator associated with client server 170. In some embodiments, security measures 174 may include, among others, but are not limited to, validation server 160 ignoring input signal 134 and instructing client server 170 not to accept input signal 134, validation server 160 requesting out-of-band authentication of unverifiable input (such as by multi-factor authentication or content verification over a separate channel), validation server 160 requesting that the connection between client 110 and server 160 be terminated, validation server 160 sending a warning notification 168 alerting an administrator, a security system (SOC or SIEM), or other entity that an unverifiable input has been attempted, or combinations thereof.

[0048] In some examples, instead of validating each input signal 134 independently, the validation server 160 may validate a set of integrity certificates 220 received from a web server 240 communicatively coupled to the user computing system 110. The set of integrity certificates 220 may include at least one integrity certificate 108 generated by the integrity module 140. FIG. 2 illustrates an example of a system environment 200 for validating a set of input signals 210 of inputs 132 from a web server 240 using a set of generated integrity keys 250, according to an embodiment. As shown in FIG. 2, the system environment 200 may include a web server 240 communicatively coupled to the user computing system 110 via a network 150. In particular, the user computing system 110 may communicate with the web server 240 via a web browser 230 accessible using a user device 120 in the user computing system 110.

[0049] Further, interface 130 may send set of input signals 210 and set of integrity certificates 220 to validation server 160 at once, instead of sending each input signal 134 separately. For example, web server 240 may send set of integrity certificates 220 to validation server 160 via a validation request (e.g., using an application programming interface (API) call). In some embodiments, web server 240 may group each set of integrity certificates 220 based on one or more fields available to web browser 230. Example fields may include email subject lines, transaction number fields, address fields, etc. For example, web browser 230 or web server 240 may detect a termination signal corresponding to user 106 switching from a first field to a second field on web browser 230. Based on this termination signal, web server 240 may send a first set of integrity certificates corresponding to the first field separately from a second set of integrity certificates corresponding to the second field. Additionally, the sequential identifier 144 of each integrity certificate 108 transmitted by the web server 240 may indicate the order in which the user 106 entered the set of input signals 210, thereby allowing the web server 240 or the validation server 160 to identify non-sequential inputs (e.g., edits) from the user 106. If one or more integrity certificates 108 of the set of integrity certificates 220 from the web server 240 are deemed invalid or unverifiable by the validation server 160, the validation server 160 may identify appropriate security measures, as described above with respect to FIG. 1. For example, the validation server 160 may deny or block the set of input signals in response to determining that an integrity certificate 108 of the set of integrity certificates 220 is invalid.

[0050] 1, in some embodiments, user computing system(s) 110, verification server 160, and / or client server(s) 170 may include any computing or data processing device consistent with embodiments of the present disclosure. User computing system 110, and verification server 160, and / or client server 170 may transmit and receive data over a communications network (e.g., network 150).

[0051] By way of example, network 150 may include one or more communications networks, such as a data network, a wireless network, a telephone network, or any combination thereof. The data network may be any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), public data network (e.g., the Internet), a short-range wireless network, or any other suitable packet-switched network, such as a commercially owned proprietary packet-switched network, e.g., a proprietary cable or proprietary optical fiber network, NFC / RFID, RF memory tag, touch-distance radio, or any combination thereof. Further, the wireless network may be, for example, a cellular network and may employ various technologies, including, for example, Global Enhanced Data Rates for Evolution (EDGE), General Packet Radio Service (GPRS), Global System for Mobile Communications (GSM), Internet Protocol Multimedia Subsystem (IMS), Universal Mobile Telecommunications System (UMTS), and the like, as well as any other suitable wireless medium, for example, Worldwide Interoperable Microwave Access (WiMAX), Long Term Evolution (LTE) networks, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Wireless Fidelity (WiFi), Wireless LAN (WLAN), Bluetooth, Internet Protocol (IP) datacasting, satellite, Mobile Ad-Hoc Networks (MANET), and the like, or any combination thereof. User computing system 110, validation server 160, and / or client server 170 may further implement aspects of the embodiments of the present disclosure without accessing other devices or networks, such as network 150.

[0052] The user computing system 110, the verification server 160, and / or the client server 170 may include one or more computing systems for processing, storing, receiving, retrieving, and / or transmitting information, such as the computing system 900 described in connection with FIG. 9. In some aspects, the user computing system 110, the verification server 160, and / or the client server 170 may be implemented with hardware components and / or software instructions for performing one or more operations consistent with embodiments of the present disclosure (e.g., the exemplary embodiments described with reference to FIGS. 5-7). The software instructions may be embodied in a single computer or any additional or alternative computing device / system (e.g., a single server, multiple devices / servers, etc.). The user computing system 110 may also include or cooperate with distributed computing devices and computing systems, and may execute software instructions on separate computing systems by communicating remotely over a network (e.g., the network 150). User computing system 110, verification server 160, and / or client server 170 may also perform aspects of embodiments of the present disclosure without accessing other devices or networks, such as network 150. User computing system 110, verification server 160, and / or client server 170 may also be implemented with one or more data stores for storing information consistent with embodiments described below.

[0053] Although the systems / devices of system environment 100 are shown as directly connected, user computing system 110 may be indirectly connected to one or more of the other systems / devices of system environment 100. In some embodiments, user computing system 110 may only be directly connected to one or more of the other systems / devices of system environment 100.

[0054] It should also be understood that system environment 100 may omit any of the illustrated devices and / or include additional systems and / or devices not shown. Although one of each device and / or system is illustrated in system environment 100, it should also be understood that multiple devices and / or systems may be part of system environment 100. It should further be understood that each of the multiple devices and / or systems may be different or the same. For example, one or more of the devices may be hosted on any of the other devices. As an example, client server 170 may be hosted on verification server 160. As another example, system environment 100 may include multiple verification servers 160, such as when user 106 connects to client server 170 through another client server. In such an embodiment, verification server 160 may correspond to client server 170 while another verification server may correspond to another client server.

[0055] Figure 3 illustrates an example of a hardware implementation of an integrity module 300 (e.g., integrity module 140 of Figure 1), according to an embodiment. As shown in Figure 3, integrity module 300 may be configured to be wired or wirelessly connected to user device 120. For example, integrity module 300 may include a communications interface 310, which may be a port configured for a USB, COM, serial, parallel, Firewire, or Thunderbolt connection.

[0056] In some examples, the integrity module 300 may include one or more processing units 320 and storage 330. The processing unit 320 may be configured to execute instructions to perform various operations and may include, for example, a microcontroller, a general-purpose processor, or a microprocessor suitable for implementation in a portable electronic device such as a Raspberry Pi. The processing unit 320 may be communicatively coupled to multiple components within the integrity module 300. For example, the processing unit 320 may communicate with other components via a bus. The bus may be any subsystem adapted to transfer data within the integrity module 300. The bus may include multiple computer buses and additional circuitry for transferring data.

[0057] In some embodiments, the processing unit 320 may be connected to storage 330. In some embodiments, the storage 330 may provide both short-term and long-term storage and may be divided into several units. The storage 330 may be volatile, such as static random access memory (SRAM) and / or dynamic random access memory (DRAM), and / or non-volatile, such as read-only memory (ROM) and flash memory. Additionally, the storage 330 may include removable storage devices, such as a secure digital (SD) card. The storage 330 may store computer-readable instructions, data structures, program modules, audio recordings, image files, video recordings, and other data for the integrity module 300. In some embodiments, the storage 330 may be distributed across different hardware modules. A collection of instructions and / or code may be stored in the storage 330. The instructions may take the form of executable code that may be executed by the integrity module 300 and / or may take the form of source and / or installable code that, when compiled and / or installed on the integrity module 300 (e.g., using any of a variety of commonly available compilers, installation programs, compression / decompression utilities, etc.), may take the form of executable code.

[0058] In some embodiments, storage 330 may store a number of application modules 336, which may include any number of applications, such as applications for controlling communication interface 310, private key 332, and sequential identifier 334 (e.g., a counter, a timestamp, a random number, any suitable function derived from an underlying counter, etc.). Private key 332 and sequential identifier 334 may be private key 142 and sequential identifier 144 of FIG. 1. Application module 336 may include certain instructions related to the generation of integrity keys and integrity certificates (e.g., integrity certificate 108 of FIG. 1), which are executed by processing unit 320. In some embodiments, certain applications or portions of application module 336 may be executable by other hardware modules, such as communication interface 310. In certain embodiments, storage 330 may further include secure memory, which may include additional security controls to prevent copying or other unauthorized access to secure information.

[0059] In some embodiments, the storage 330 may include an operating system 338 loaded thereon, such as, for example, the Android operating system or any other operating system suitable for a mobile or portable device. The operating system 338 may be operable to initiate execution of instructions provided by the application modules 336 and / or to manage interfacing with other hardware modules and the communications interface 310, which may include one or more wireless or wired transceivers. The operating system 338 may be adapted to perform other operations across the components of the integrity module 300, including threading, resource management, data storage control, and other similar functions.

[0060] Figure 4 illustrates an example software implementation of an integrity module 400 (e.g., integrity module 140 of Figure 1), according to an embodiment. As shown in Figure 4, integrity module 400 may be configured to be an application stored on user device 120 of Figure 1. Additionally or alternatively, integrity module 400 may be configured to be a low-level device driver or a hypervisor driver.

[0061] In some embodiments, the integrity module 400 may include one or more processing units 420 and storage 430. The processing unit 420 may be configured to execute instructions to perform various operations and may include, for example, a microcontroller, a general-purpose processor, or a microprocessor suitable for implementation in a portable electronic device such as a Raspberry Pi. The processing unit 420 may be communicatively coupled to multiple components within the integrity module 400. For example, the processing unit 420 may communicate with other components via a bus. The bus may be any subsystem adapted to transfer data within the integrity module 400. The bus may include multiple computer buses and additional circuits for transferring data.

[0062] In some embodiments, the processing unit 420 may be connected to storage 430. In some embodiments, the storage 430 may provide both short-term and long-term storage and may be divided into several units. The storage 430 may be volatile, such as static random access memory (SRAM) and / or dynamic random access memory (DRAM), and / or non-volatile, such as read-only memory (ROM) and flash memory. Additionally, the storage 430 may include removable storage devices, such as a secure digital (SD) card. The storage 430 may store computer-readable instructions, data structures, program modules, audio recordings, image files, video recordings, and other data for the integrity module 400. In some embodiments, the storage 430 may be distributed across different hardware modules. A collection of instructions and / or code may be stored in the storage 430. The instructions may take the form of executable code that may be executed by the integrity module 400 and / or may take the form of source and / or installable code that, when compiled and / or installed on the integrity module 400 (e.g., using any of a variety of commonly available compilers, installation programs, compression / decompression utilities, etc.), may take the form of executable code.

[0063] In some embodiments, storage 430 may include a secure container for storing private key 432. For example, the secure container may be a microcontroller (e.g., a secure crypto processor, a system-on-chip (SoC) secure enclave, etc.) that secures the hardware with an integrated cryptographic key. In this example, the secure container may be a trusted platform module (TPM) 431a, which may include a hardware random number generator, a cryptographic key generator, remote attestation, decryption functionality, or a combination thereof. In some examples, the secure container includes private key 432 that was generated during the manufacture of the user device. In such an example, an entity that makes the hardware for the user device may ship the user device with private key 432 present in a secure container in storage 430. Additionally or alternatively, the user device may include a key identifier (e.g., a hardware serial number, BIOS information, etc.) that can be used to derive the private key.

[0064] In some embodiments, storage 430 may store multiple application modules 436, which may include any number of applications, such as applications for controlling communication interface 410, TPM 431, and sequential identifier 434. Application modules 436 may include specific instructions related to generating integrity keys and integrity certificates (e.g., integrity certificate 108 of FIG. 1), which are executed by processing unit 420. In some examples, application modules 436 may have TPM HMAC functionality / firmware to generate integrity certificates. In some embodiments, specific applications or portions of application modules 436 may be executable by other hardware modules, such as communication interface 410. In certain embodiments, storage 430 may further include secure memory, which may include additional security controls to prevent copying or other unauthorized access to secure information.

[0065] In some embodiments, storage 430 may include an operating system 438 loaded thereon, such as, for example, the Android operating system, Apple® iOS, or any other operating system suitable for a mobile or portable device. Operating system 438 may be operable to initiate execution of instructions provided by application modules 436 and / or to manage interfaces with other hardware modules and communications interface 410, which may include one or more wireless or wired transceivers. Operating system 438 may be adapted to perform other operations across the components of integrity module 400, including threading, resource management, data storage control, and other similar functions.

[0066] 5-7 show flow charts illustrating verifying at least a subset of one or more input signals 134 of inputs 132 received by client server 170 and / or verification server 160 during a communication session with or via client server 170 using a shared integrity key, according to an embodiment. The steps of FIGS. 5-7 are described below with reference to the components previously described in FIG. 1. It will be understood that these are non-limiting examples and that the operations described in these flow charts may be modified according to architectural changes. By way of example, verification server 160 may perform one or more operations of client server 170. For example, one or more of the operations may be omitted, performed in parallel, etc. Additionally, one or more operations described herein may be performed together with other operations.

[0067] Although the interface in these examples (e.g., interface 130 of FIG. 1 ) is described with respect to a keyboard, it will be understood that the operations described herein are not limited to this interface (i.e., a keyboard) and may be performed on input (e.g., input 132 of FIG. 1 ) or input streams received by additional and / or alternative interface(s). It will be understood that the interface is not limited to a keyboard and may include alternative and / or additional devices, including, but not limited to, a mouse, a joystick, a game controller, or any combination thereof, among others. Examples of input may include keystrokes, mouse clicks or movements, joystick or game controller interaction, or touch screen interaction.

[0068] Figure 5 shows a flowchart illustrating the validation of at least one input signal 134 of an input 132 (e.g., a keystroke) received by a verification server 160 during a communication session, according to an embodiment, using, for example, a hardware implementation of the integrity module 140 shown and described in Figures 1 and 3. The operations described in flowchart 500 may be performed by a computing environment, such as the system environment 100 described above with respect to Figure 1 or the computing system 900 described below with respect to Figure 9.

[0069] Although the flowchart 500 may describe the operations as a sequential process, in various embodiments, some of the operations may be performed in parallel or simultaneously. Additionally, the order of the operations may be rearranged. The operations may have additional steps not shown. In some embodiments, some operations may be optional. The method / architecture embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the associated tasks may be stored in a non-transitory computer-readable medium, such as a storage medium.

[0070] Operation of flowchart 500 may begin at block 512. Before initiating a communication session, user 106 may first have integrity module 140 connected to interface 130 (e.g., a keyboard). Additionally, when user computing system 110 is running integrity module 140 for the first time, user computing system 110 may initiate a pairing process with client server 170. The pairing process is further described below with respect to FIG.

[0071] At block 512, interface 130 may detect input 133 in response to a key that user 106 physically touches or otherwise interacts with. For example, if interface 130 is a keyboard, user 106 may press a key on the keyboard, causing interface 130 to detect input 133 of a character corresponding to the key on the keyboard. As another example, if interface 130 is a computer mouse, interface 130 may detect input 132 from user 106 pressing a wheel or button of the computer mouse, such as a right click or left click.

[0072] At block 514, interface 130 may send input signal 134 corresponding to input 132 to integrity module 140. In response to detecting input 132 made by user 106, interface 130 may convert input 132 into input signal 134 (e.g., a hexadecimal representation of the characters typed by user 106 using a keyboard). In some embodiments, such conversion may involve grouping key codes together, mapping key codes to characters in another keymap, and / or performing other functional transformations on input 132 to generate input signal 134.

[0073] At block 522, the integrity module 140 may receive the input signal 134 and generate the integrity key 114a based on the received input signal 134 and the private key 142a stored in the integrity module 140. In some embodiments, at block 522, the integrity module 140 may increment a sequential identifier 144 in memory (e.g., a counter, a timestamp, a random number, any suitable function derived from an underlying counter, etc.) by one. The integrity module 140 may generate an integrity key (IK) by applying a cryptographic protocol 115 (e.g., SHA-256 and / or SHA3-256 (Keccak) Secure Hash Algorithm (SHA)) to the input signal 134, the sequential identifier 144, and the private key 142a. Some other embodiments of the integrity module 140 may use different mathematical transformations to generate the IK, including digital signature schemes based on asymmetric cryptography (such as RSA's PKCS#1, Elliptic Curve Public Key Algorithms, e.g., ECDSA, ECDH, or others), hash functions according to post-quantum cryptography (such as Kyber), or others. Still other embodiments of the integrity module 140 may combine one or more cryptographic protocols 115 (e.g., hash functions, digital signature schemes, etc.), the input signal 134, the private key 142a, and optionally a sequential identifier 144 to generate the integrity key 114a.

[0074] At block 524, the integrity module 140 may generate the integrity certificate 108. In some embodiments, the integrity certificate 108 may correspond to a tuple 112 (e.g., <input signal, sequential identifier, IK> or <sequential identifier, IK>), which includes an invariant sequence of elements. For example, the integrity module 140 may generate a character sequence as the tuple 112 corresponding to the integrity certificate 108. Then, at block 526, the integrity module 140 may transmit the integrity certificate 108 and the input signal 134 to the user device 120 in one or more messages.

[0075] At block 532, the user device 120 may receive the integrity certificate 108 and the input signal 134. At block 532, the user device 120 may receive the integrity value of the input signal 134 and the current value of the sequential identifier 144, but does not receive a copy of the first private key 142a. Instead, the user device 120 receives the integrity key 114b generated using the second private key 142b.

[0076] At block 532, the user device 120 may convert the input signal 134 included in the integrity certificate 108 into corresponding (original) characters, for example using the O / S. At block 534, the user device 120 may encode the integrity certificate 108 (block 526), ​​for example using the integrity application 122. The user device 120 may then transmit the encoded integrity certificate 108 and the characters to the client server 170 over the network 150, for example using the integrity application 122. At block 536, the user device 120 may then transmit the encoded integrity certificate 108 and the characters to the client server 170 over the network 150.

[0077] Next, at block 542, the client server 170 may determine the user identifier 116 associated with the integrity module 140 for the received message (the character and encoded integrity certificate via the user device 120), for example, using any known authentication technique.

[0078] At block 544, the client server 170 may connect to the verification server 160 and then transmit a message including the user identifier 116, the encoded integrity certificate 108, the input signal 134, and the text. In some embodiments, the text or other representation of the input signal may be omitted.

[0079] At block 552, the validation server 160 may decode the received (encoded) integrity certificate 108 to identify the input signal 134, the sequential identifier 144, and the integrity key 114a (which may be referred to as "IK1"). In some embodiments, if the input 132 is of a type that is processed according to the security profile of the system environment 100, the validation server 160 may continue with the operations of blocks 552-564. At block 554, the validation server 160 may use the user identifier 116 to locate another private key 142b registered to the user 106 by searching for another private key 142b in the user record database 162. Then, at block 556, the validation server 160 may generate a (second) integrity key (IK2) 114b using the received input signal 134, the received sequential identifier 144, and the retrieved private key 142b to verify the received integrity key (IK1) 114a.

[0080] At block 558, the verification server 160 may compare the input signal 134 (block 514) with the characters (block 544) to determine whether they match. If the input signal 134 sent by the interface 130 does not match the characters sent in the message (NO at block 558), the verification server 160 may consider the input 132 invalid or fraudulent and may cause security measures 174 based on the security policy 176 (block 562). If the input signal 134 sent by the interface 130 matches the characters sent in the message (YES at block 558), the verification server 160 may compare the integrity key (IK1) 114a received in the message (block 524) with another integrity key (IK2) 114b (block 556) generated using the input signal 134 received in the message and the sequential identifier 144 to determine whether they match. If the validation server 160 determines that the integrity keys 114a and 114b match (YES at block 560), the input 132 (block 512) may be deemed valid. At block 564, the validation server 160 may communicate to the client server 170 to accept the input 132 (block 512). If the validation server 160 determines that the integrity keys 114a and 114b do not match (NO at block 560), the input 132 (block 512) may be deemed invalid or fraudulent. At block 562, the validation server 160 may generate security measures 174 based on security policies 176 for the entity and / or for the user 106 configured by an administrator.

[0081] It will be appreciated that steps 512-564 may be repeated for additional input signals of additional inputs received by the validation server 160 and / or the client server 170 during the communication session. In this manner, the integrity of the entire communication session may be maintained by limiting the access of the client server 170 to those that correspond to the validated input from the user 106. It will be further appreciated that steps 512-564 may be performed to process a set of input signals, which may include multiple input signals. As an illustrative example, if the set of input signals includes "a", "b", and "c", the validation server 160 may validate the certificate for "abc", which is a collective sequence of the set of input signals. Specifically, instead of performing steps 512-564 three times, once for each input signal, the validation server 160 may perform steps 512-564 once for the set of three input signals.

[0082] FIG. 6 shows a flowchart illustrating verifying input 132 (e.g., keystrokes) received by client server 170 and / or verification server 160 during a communication session using, for example, a software implementation of integrity module 140 as shown and described in FIGS. 1 and 4 according to an embodiment. The operations described in flowchart 600 may be performed by a computing environment, such as the system environment 100 described above with respect to FIG. 1 or the computing system described below with respect to FIG. 9. Although flowchart 600 may describe the operations as a sequential process, in various embodiments, some of the operations may be performed in parallel or simultaneously. Furthermore, the order of the operations may be rearranged. The operations may have additional steps not shown. In some embodiments, some operations may be optional. Method / architecture embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the associated tasks may be stored in a computer-readable medium, such as a storage medium.

[0083] Operation of flowchart 600 may begin at block 612, where interface 130 (e.g., a keyboard) may detect input 132 in response to a key or switch of interface 130 being physically touched or otherwise input by user 106. In embodiments in which interface 130 is a touchscreen, user 106 may interact with the touchscreen (e.g., a multi-finger screen touch) to generate input 132. At block 614, interface 130 may transmit an input signal 134 corresponding to input 132 (e.g., a hexadecimal representation of a physical character typed by user 106 on a keyboard) to user device 120.

[0084] Next, at block 622, the integrity module 140 of the user device 120 may receive the input signal 134 and generate the integrity key 114a based on the received input signal 134 and the stored private key 142a. In some embodiments, at block 622, the integrity module 140 may use a trusted platform module (TPM) 431 to retrieve the private key 142a stored in persistent memory within the TPM 431 and generate the integrity key 114a. For example, the integrity module 140 may cause the TPM 431 to increment the sequential identifier 144 in the persistent TPM memory by one. Integrity module 140 may generate integrity key (IK) 114a by applying a cryptographic protocol 115 (e.g., SHA-256 and / or SHA3-256 (Keccak) Secure Hash Algorithm (SHA)) to input signal 134, sequential identifier 144, and private key 142a using TPM 431. In an alternative embodiment, integrity module 140 may instead access private key 142a stored in a privileged location of storage 430 that a malicious actor cannot access without administrative privileges.

[0085] At block 624, the integrity module 140 may use the TPM 421 to generate the integrity certificate 108. In some embodiments, the integrity certificate 108 may correspond to <input signal, sequential identifier, IK> or a tuple of <sequential identifier, IK> 112. Then, at block 626, the integrity module 140 may send the integrity certificate 108 to the integrity application 122 in one or more messages.

[0086] At block 632, the user device 120 may convert the input signal 134 received from the interface 130 into a corresponding (original) character. At block 634, the user device 120 (e.g., the application / O / S of the user device 120) may receive the integrity certificate 118 from the integrity module 140. In this step, the user device 120 may receive the integrity value of the input signal 134 and the current value of the sequential identifier 144, but does not receive a copy of the private key 142a. Rather, the user device 120 receives another integrity key 114b generated using the private key 142b. At block 634, the user device 120 may encode the integrity certificate 108, for example, using the integrity application 122. Then, at block 636, the user device 120 may transmit the character and the encoded integrity certificate 108 (representing a 3-tuple) to the client server 170 over the network 150.

[0087] In some embodiments, the verification operations of blocks 642-664 performed by verification server 160 and / or client server 170 may be similar to those described with respect to Figure 5. In block 642, for the message received by client server 170 (the character and encoded integrity certificate via user device 120), client server 170 may determine the user identifier 116 associated with integrity module 140, for example, using any known authentication technique.

[0088] At block 644, the client server 170 may connect to the validation server 160 and then transmit a message including the user identifier 116, the encoded integrity certificate 108, the input signal 134, and the text.

[0089] At block 652, the validation server 160 may decode the received (encoded) integrity certificate 108 to identify the input signal 134, the sequential identifier 144, and the integrity key ("IK1") 114a. In some embodiments, if the input 132 is of a type that is processed in accordance with the security profile of the system environment 100, the validation server 160 may continue with the operations of blocks 652-664. At block 654, the validation server 160 may identify another private key 142b registered to the user 106 by searching for another private key 142b in the user record database 162 using the user identifier 116. Then, at block 656, the validation server 160 may generate a (second) integrity key (IK2) 114b using the received input signal 134, the received sequential identifier 144, and the searched private key 142b.

[0090] At block 658, the verification server 160 may compare the input signal 134 (block 614) with the character (block 644) to determine whether they match. If the input signal 134 sent by the interface 130 does not match the input signal 134 sent in the message (NO at block 658), the verification server 160 may consider the input 132 invalid and may cause security measures 174 based on the security policy 176 (block 662). If the input signal 134 sent by the interface 130 matches the input signal 134 sent in the message (YES at block 658), at block 660, the verification server 160 may compare the first integrity key (IK1) 114a received in the message (block 624) with the second integrity key (IK2) 114b (block 656) generated using the input signal 134 received in the message and the sequential identifier 144. If the validation server 160 determines that the integrity keys 114a and 114b match (YES at block 660), the input 132 (block 612) may be considered valid or authentic. The validation server 160 may then communicate to the client server 170 at block 664 to accept the input 132 (block 612).

[0091] If the validation server 160 determines that the integrity keys 114a and 114b do not match (NO at block 660), the input 132 (block 612) may be deemed invalid. At block 662, the validation server 160 may send an alert notification 168 to the client server 170 and generate security measures 174 based on security policies 176 for the entity and / or for the user 106 configured by an administrator. In some embodiments, the security measures 174 may include allowing a predetermined number of unverified characters to indicate a false positive result associated with falsely notifying when malicious activity is occurring. Additionally or alternatively, the client server 170 may ignore the unverified input, thus thwarting lateral escalation attempts by malicious actors. Further examples of security measures 174 may include logging off the user 106 from the remote connection 152, disabling the user 106's access to protected computing resources, automatically performing countermeasures or investigations to identify malicious actors, or combinations thereof.

[0092] It will be appreciated that steps 612-664 may be repeated for additional input signals of additional inputs received by the verification server 160 and / or the client server 170. In this manner, the integrity of the entire communication session may be maintained.

[0093] 7 shows a flow chart illustrating validating input 132 (e.g., a keystroke or a collection of keystrokes) to a web browser 230. Input 132 to the operating system (at block 732) and input 132 to the web browser 230 (at block 736) may be received using, for example, a hardware implementation of the integrity module 140 shown and described in FIGS. 1 and 2 according to an embodiment. In some embodiments, the web browser 230 may buffer the set of input signals 210 and the corresponding set of integrity certificates 220 before submitting the buffer contents to the validation server 160 via the client server 170.

[0094] The operations described in the flowchart 700 may be performed by a computing environment, such as the system environment 100 and the system environment 200 described above with respect to FIG. 1 and FIG. 2, or the computing system described below with respect to FIG. 9. Although the flowchart 700 may describe the operations as a sequential process, in various embodiments, some of the operations may be performed in parallel or simultaneously. Furthermore, the order of the operations may be rearranged. The operations may have additional steps not shown. In some embodiments, some operations may be optional. The method / architecture embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the associated tasks may be stored in a computer-readable medium, such as a storage medium.

[0095] Operation of the flowchart 700 may begin at block 712. Before initiating a communication session, the user 106 may first have the integrity module 140 connected to the interface 130 (e.g., a keyboard) and use the web browser 230 on the user device 120 to initiate a communication session to the web server 240 (e.g., a third-party server). Once the web browser 230 on the user device 120 connects to the web server 240, the client server 170 may terminate the connection (e.g., an SSL connection) between the web browser 230 and the web server 240 and create another connection between a proxy server and the web server 240. The proxy server may be an intermediate server that communicatively connects the user device 120 to the web server 240.

[0096] After a connection between the proxy server and the web server 240 is created, at block 712, the interface 130 may detect an input 132 in response to a key physically touched or otherwise entered by the user 106. At block 714, the interface 130 may transmit an input signal 134 corresponding to the input 132 (e.g., a hexadecimal representation of a physical character typed by the user 106 on a keyboard, a mouse click, or a touch screen tap).

[0097] Next, at block 722, the integrity module 140 may receive the input signal 134 and generate the integrity key 114a based on the received input signal 134 and the stored private key 142a. In some embodiments, at block 722, the integrity module 140 may increment the sequential identifier 144 in memory by one. The integrity module 140 may generate an integrity key (IK) by applying a cryptographic protocol 115 (e.g., SHA-256 and / or SHA3-256 (Keccak) Secure Hash Algorithm (SHA)) to the input signal 134, the sequential identifier 144, and the private key 142a. At block 724, the integrity module 140 may generate an integrity certificate 108. In some embodiments, the integrity certificate 108 may correspond to the tuple 112 of <input signal, sequential identifier, IK> or <sequential identifier, IK>. Thereafter, at block 726, the integrity module 140 may transmit the integrity certificate 108 and the input signal 134 to the user device 120 in one or more messages.

[0098] At block 732, the user device 120 may receive the integrity certificate 108 and the input signal 134. At block 732, the user device 120 may receive the integrity value of the input signal 134 and the current value of the sequential identifier 144, but does not receive a copy of the private key 142a. Rather, the user device 120 receives an integrity key 114b generated using the stored private key 114bb, thus restricting access to the private keys 142a, 142b and enhancing data security.

[0099] At block 732, the operating system (O / S) may convert the input signal 134 included in the integrity certificate 108 into a corresponding (original) character. At block 734, the user device 120 may encode the integrity certificate 108, for example, using the integrity application 122 (e.g., a driver). In some embodiments, the integrity application 122 may send the encoded integrity certificate 108 to the O / S. In some embodiments, the O / S may then send the encoded integrity certificate 108 and the character to the web browser 230 at block 734.

[0100] At block 736, the web browser 230 may receive the encoded integrity certificate 108 (representing the 3-tuple) via the O / S. In some embodiments, the web browser 230 may also receive from the O / S a character (e.g., a phonetic character) that corresponds to the input signal 134 (block 714) received from the interface 130. For example, the input signal 134 for the number "8" may be converted to the compound character "*" because a combination of a shift modifier key and the number "8" key was pressed. Specifically, the interface 130 may send separate input signals 134 for the number "8," the shift modifier key, and the compound character "*."

[0101] At block 736, a browser extension in the web browser 230 may track text or numeric fields (e.g., defining browser areas where the user 106 can type characters, such as email subjects or comments) within the specified website(s). In some embodiments, the designation may be policy specific. For example, the designation may include, among other things, all websites (audit purposes), a subset of websites for which the private key 142 is required, an application programming interface (API), or any combination thereof.

[0102] At block 736, the browser extension may consume the encoded integrity certificate 108 and associated characters (blocks 712-734) for the specified website within the web browser 230. For example, a buffer may store the integrity certificate 108 and associated characters in a 2-tuple (<character, <input signal, sequential identifier, IK>>). In this manner, the buffer may accumulate a collection of encoded integrity certificates 220 and associated characters.

[0103] At block 738, when the web browser 230 submits a request to the web server 240, the browser extension may add an additional field to the outgoing HTTP request. For example, each HTTP GET or POST request having a text field containing an identifier I tracked by the browser extension may receive an additional text field containing an identifier v(I), where v is a function for generating a unique name. The additional text field containing the identifier v(I) may contain the serialized contents of a buffer, which provides a correspondence between the characters typed in the text field and the set of integrity keys 250 that correspond to each character.

[0104] At block 742, the client server 170 may receive an HTTP, HTTPS, or Websocket request that includes a text field. At block 744, for the message received by the client server 170 (the text and encoded integrity certificate 108 via the user device 120 108), the client server 170 may determine the user identifier 116 associated with the integrity module 140, for example, using any known authentication technique.

[0105] Based on a policy associated with the user 106 and / or the user device 120, the proxy server may select v(I) for each text field that the policy dictates should be verified by the verification server 160. In some embodiments, the policy may include all text or numeric field morphology and / or a subset thereof.

[0106] At block 746, the client server 170 may connect to the validation server 160 and then transmit a message including the user identifier 116, the encoded integrity certificate 108, the input signal 134, and the text.

[0107] At block 752, the validation server 160 may decode the received (encoded) integrity certificate 108 from the buffer of the web browser 230 to identify the input signal 134, the sequential identifier 144, and the integrity key 114a.

[0108] At block 754, the verification server 160 may use the user identifier 116 to identify another private key 142b registered to the user 106 by searching for another private key 142b in the user record database 162. Then, at block 756, the verification server 160 may generate a (second) integrity key (IK2) 114b using the received input signal 134, the received sequential identifier 144, and the retrieved private key 142b.

[0109] At block 758, the validation server 160 may compare the set of input signals 210 received in the text field (block 714) with the corresponding set of characters (block 744) to determine whether they are valid (e.g., match). Each character received in the text field must correspond to some valid character in the set of input signals 210 and the corresponding set of integrity certificates 220. Specifically, if the set of input signals 210 received in the text field does not match an equally sized subset of the character(s) sent in the message (NO at block 758), the validation server 160 may consider the input 132 invalid and may issue security measures 174 based on the security policy 176 (block 762). Alternatively, if the set of input signals 210 received in the text field matches an equal-sized subset of the character(s) sent in the message (YES at block 758), then at block 760 the validation server 160 may compare the set of integrity certificates 220 received in the message (block 724) with the set of integrity certificates 220 generated using the set of input signals 210 received in the message and the set of sequential identifiers (block 756). If the validation server 160 determines that the set of integrity certificates 220 match (YES at block 760), then the input 132 (block 712) may be considered valid. Then, at block 764, the validation server 160 may communicate to the client server 170 to accept the set of input signals 210 (block 714). At block 764, the verification server 160 may optionally transparently remove the v(I) integrity key buffer from the request body and the request to the web server 240 (e.g., since there may not be a verification process as disclosed herein).

[0110] If the validation server 160 determines that the set of integrity certificates 220 do not match (NO at block 760), the input 132 (block 712) may be considered invalid. At block 762, the validation server 160 may generate security measures 174 based on security policies 176 for the entity and / or for the user 106 configured by an administrator. For example, depending on a security policy 176 configured by an administrator, among other things, the validation server 160 may cause the browser to generate a client error by ignoring the input signal 134 without allowing a third-party server to receive the input signal 134, the validation server 160 may issue a response directly to the web browser 230 to notify the end user, the validation server 160 may request out-of-band authentication (e.g., multi-factor authentication) of the unverifiable input or set of unverifiable inputs, the validation server 160 may request that the client-server connection be terminated, the validation server 160 may communicate to a system administrator that an invalid text entry (e.g., set of keystrokes) was attempted, or any combination thereof.

[0111] FIG. 8 illustrates a data flow diagram 800 of an example of a data flow for pairing an integrity key of an agent 810 to a user identifier of a terminator 830, according to an embodiment. The operations described in the data flow diagram 800 may be performed by a computing environment, such as the system environment 100 described above with respect to FIG. 1 or the computing system described below with respect to FIG. 9. Although the data flow diagram 800 may describe the operations as a sequential process, in various embodiments, some of the operations may be performed in parallel or simultaneously. Furthermore, the order of the operations may be rearranged. The operations may have additional steps not shown. In some embodiments, some operations may be optional. The method / architecture embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the associated tasks may be stored in a computer-readable medium, such as a storage medium.

[0112] Operation of data flow diagram 800 may begin at block 802. Prior to performing the verification process previously described in FIGS. 1-7, an agent 810 associated with a user may initiate a matchmaking process (e.g., a first-time use trust process) to pair the agent 810 with a corresponding terminator 830a (e.g., client server 170 of FIG. 1). In some embodiments, the agent 810 may be a user device 120 or a user computing system 110 of FIG. 1 associated with a user 106 of FIG. 1. Dispatch 820 may be an intermediate router that communicatively connects the agent 810 with one or more terminators 830a-830b and may facilitate the matchmaking process. Additionally, Dispatch 820 may be associated with a user account of the user and may manage the respective sequential identifiers (e.g., sequential identifiers 144 of FIG. 1) of each agent communicatively connected to Dispatch 820. In some embodiments, multiple user computing systems (e.g., a work phone and a work laptop) may be associated with a user account with dispatch 820. In such embodiments, dispatch 820 may monitor a separate sequential identifier associated with each user computing system associated with the user account.

[0113] In some embodiments, prior to this matchmaking process, the agent 810 may have a private key associated with the user and the user's computing system, but may not have a username to use as the user's user identifier (e.g., user identifier 116 of FIG. 1). Conversely, one or more terminators 830a-830b in a system environment (e.g., system environment 100 of FIG. 1) may have a username, but may not have a private key corresponding to the user of the username. Thus, the matchmaking process may enable the agent 810 to pair with a corresponding terminator 830a relatively quickly, with limited interaction from the user.

[0114] At block 802, the agent 810 may register with dispatch 820 that the agent 810 does not have a username associated with the user of the agent 810. Similarly, at block 804a, the terminator 830a may send a request to the user directory database 840 to identify a private key (e.g., a public key of an asymmetric key pair) corresponding to the username associated with the terminator 830a. The user directory database 840 may store a mapping of the username to the private key based on a successful matchmaking process. At block 804b, the user directory database 840 may send a response indicating that it is unable to obtain a private key corresponding to the username to service the request from the terminator 830a. For example, if the user is a first-time user of the verification process, the mapping of the private key corresponding to the username may be unavailable in the user directory database 840 until the matchmaking process is complete. At block 806, in response to receiving a response from the user directory database 840, the terminator 830a may send another request to dispatch 820 to register that it does not have a private key corresponding to the username associated with the terminator 830a.

[0115] At block 808, the agent 810 may initiate the matchmaking process by sending an input message to the dispatch 820. The input message may include a private key, an integrity key associated with the agent 810, an integrity certificate generated by the agent 810, an input signal (e.g., the input signal 134 in FIG. 1) detected by an interface (e.g., the interface 130 in FIG. 1) connected to the agent 810, or a combination thereof. At blocks 812a-812b, the dispatch 820 may send the private key of the agent 810 to each of the terminators 830a-830b available for pairing in response to receiving the input message. For example, as shown in FIG. 8, the dispatch 820 may send the private key to the terminator 830a and another terminator 830b. After receiving the private key, the terminators 830a-830b may verify whether the private key of the agent 810 matches the respective usernames of each terminator. For example, a private key may match a username associated with a terminator 830a, but not match another username associated with another terminator 830b.

[0116] After verifying that the private key of the agent 810 matches the username of the terminator 830a, the terminator 830a may send a pairing confirmation message including the private key and username to the dispatch 820 at block 814. If the other username associated with the other terminator 830b does not match the private key of the agent 810, the other terminator 830b may send a pairing rejection message to the dispatch 820 indicating a mismatch between the private key and the other username. In some embodiments, the terminator 830a may match multiple incoming messages from the agent 810 against the username of the terminator 830a to account for the possibility of a false positive match before sending the pairing confirmation message. In such embodiments, the terminator 830a may send a pairing confirmation message to the dispatch 820 if a predetermined number of incoming messages from the agent 810 match the terminator 830a. For example, the terminator 830a may wait for three successful matches between the incoming message and the terminator 830a before sending a pairing confirmation message to the dispatch 820.

[0117] At block 816, when dispatch 820 receives the pairing confirmation message, dispatch 820 may forward the pairing confirmation message to agent 810 to notify agent 810 of the successful match with terminator 830a. Agent 810 may associate a private key with the username of terminator 830a based on the pairing confirmation message. Further, at block 818, dispatch 820 may send the private key of agent 810 to user directory database 840, and a mapping linking the private key and the username associated with terminator 830a may be generated. After the matchmaking process is successful, when agent 810 sends another input message to dispatch 820, terminator 830a may send another request to user directory database 840 to identify the private key corresponding to the username associated with terminator 830a. Now that a mapping corresponding to the username of terminator 830a and the private key of agent 810 is available in user directory database 840, the user directory database may use the mapping to return the private key of agent 810 in response to another request. Once terminator 830a receives this private key from user directory database 840, terminator 830 may send the private key to dispatch 820 for forwarding to agent 810. Once the private key of agent 810 has been paired with the username at block 822, agent 810 may continue with the verification process described above with respect to Figures 1-7.

[0118] FIG. 9 illustrates a block diagram of an exemplary computing system 900 for implementing certain embodiments. For example, in some aspects, the computer system 900 may include a computing system associated with a device (e.g., user device 120, verification server 160, and / or client server 170) that executes one or more processes disclosed herein (e.g., FIGS. 5-8). The block diagram illustrates several electronic components or subsystems of the computing system. The computing system 900 illustrated in FIG. 9 is merely an example and is not intended to unduly limit the scope of the embodiments of the invention as recited in the claims. Those skilled in the art will recognize many possible variations, alternatives, and modifications. For example, in some implementations, the computing system 900 may have more or fewer subsystems than those illustrated in FIG. 9, may combine two or more subsystems, or may have subsystems in different configurations or arrangements.

[0119] In the embodiment shown in FIG. 9, the computing system 900 may include one or more processing units 910 and storage 920. The processing unit 910 may be configured to execute instructions to perform various operations and may include, for example, a microcontroller, a general-purpose processor, or a microprocessor suitable for implementation in a portable electronic device such as a Raspberry Pi. The processing unit 910 may be communicatively coupled to multiple components in the computing system 900. For example, the processing unit 910 may communicate with other components via a bus. The bus may be any subsystem adapted to transfer data within the computing system 900. The bus may include multiple computer buses and additional circuits for transferring data.

[0120] In some embodiments, the processing unit 910 may be connected to storage 920. In some embodiments, the storage 920 may provide both short-term and long-term storage and may be divided into several units. The storage 920 may be volatile, such as static random access memory (SRAM) and / or dynamic random access memory (DRAM), and / or non-volatile, such as read-only memory (ROM) and flash memory. Additionally, the storage 920 may include removable storage devices, such as secure digital (SD) cards. The storage 920 may store computer-readable instructions, data structures, program modules, audio recordings, image files, video recordings, and other data for the computing system 900. In some embodiments, the storage 920 may be distributed across different hardware modules. A collection of instructions and / or code may be stored in the storage 920. The instructions may be in the form of executable code that may be executed by computing system 900 and / or may be in the form of source and / or installable code that, when compiled and / or installed on computing system 900 (e.g., using any of a variety of commonly available compilers, installation programs, compression / decompression utilities, etc.), may be in the form of executable code.

[0121] In some embodiments, storage 920 may store multiple application modules 924, which may include any number of applications, such as applications for controlling input / output (I / O) devices 940, switches, cameras, microphones or audio recorders, speakers, media players, display devices, etc. The application modules 924 may include specific instructions executed by the processing unit 910. In some embodiments, specific applications or portions of the application modules 924 may be executable by other hardware modules, such as the communications subsystem 950. In certain embodiments, storage 920 may further include secure memory, which may include additional security controls to prevent copying or other unauthorized access to secure information.

[0122] In some embodiments, storage 920 may include an operating system (O / S) 922 loaded therein, such as, for example, the Android operating system or any other operating system suitable for a mobile or portable device. Operating system 922 may be operable to initiate execution of instructions provided by application modules 924 and / or to manage interfaces with other hardware modules and communications subsystem 950, which may include one or more wireless or wired transceivers. Operating system 922 may be adapted to perform other operations across the components of computing system 900, including threading, resource management, data storage control, and other similar functions.

[0123] The communications subsystem 950 may include, for example, infrared communications devices, wireless communications devices and / or chipsets (such as Bluetooth devices, IEEE 802.11 (Wi-Fi) devices, WiMax devices, and cellular communications capabilities), NFC, ZigBee, and / or similar communications interfaces. The computing system 900 may include one or more antennas (not shown in FIG. 9) for wireless communications, either as part of the communications subsystem 950 or as separate components connected to any portion of the system.

[0124] Depending on the desired functionality, the communications subsystem 950 may have separate transceivers and communicate with base stations and other wireless devices and access points, which may include communicating with different data networks and / or network types, such as a wireless wide area network (WWAN), a WLAN, or a wireless personal area network (WPAN). A WWAN may be, for example, a WiMax (IEEE 802.9) network. A WLAN may be, for example, an IEEE 802.11x network. A WPAN may be, for example, a Bluetooth network, an IEEE 802.16x, or some other type of network. The techniques described herein may also be used with any combination of WWANs, WLANs, and / or WPANs. In some embodiments, the communications subsystem 950 may include wired communications devices, such as Universal Serial Bus (USB) devices, Universal Asynchronous Receiver Transmitters (UART) devices, and Ethernet devices. The communications subsystem 950 may enable data exchange with networks, other computing systems, and / or any other devices described herein. The communications subsystem 950 may include means for transmitting or receiving data, such as an identifier of the portable target tracking device, location data, geographical maps, heat maps, photographs, or videos, using an antenna and a wireless link. The communications subsystem 950, the processing unit 910, and the storage 920 together may constitute at least a portion of one or more of the means for performing certain functions disclosed herein.

[0125] The computing system 900 may include one or more I / O devices 940, such as sensors, switches, cameras, microphones or audio recorders, or communication ports. For example, the I / O devices 940 may include one or more touch sensors or button sensors associated with a button. The touch or button sensors may include, for example, a mechanical switch or a capacitive sensor that can sense a touch or press of a button.

[0126] In some embodiments, the I / O devices 940 may include a microphone or audio recorder that may be used to record audio messages. The microphone and audio recorder may include, for example, a condenser or capacitive microphone using a silicon diaphragm, a piezoelectric acoustic sensor, or an electret microphone. In some embodiments, the microphone and audio recorder may be a voice-activated device. In some embodiments, the microphone and audio recorder may record audio clips in a digital format, such as MP3, WAV, WMA, DSS, etc. Recorded audio files may be saved in the storage 920 or transmitted to one or more network servers via the communications subsystem 950.

[0127] In some embodiments, the I / O devices 940 may include a location tracking device, such as a Global Positioning System (GPS) receiver. In some embodiments, the I / O devices 940 may include a wired communication port, such as a micro USB, Lightning, or Thunderbolt transceiver.

[0128] The I / O devices 940 may also include, for example, speakers, media players, display devices, or communication ports. For example, the I / O devices 940 may include a display device, such as an LED display or LCD display, and corresponding driver circuitry. The I / O devices 940 may include a text player, audio player, or video player to display text messages, play audio clips, or display video clips.

[0129] The computing system 900 may include a power supply device 960, such as a rechargeable battery, to provide power to other circuits on the computing system 900. The rechargeable battery may include, for example, one or more alkaline, lead acid, lithium ion, zinc carbon, and NiCd or NiMH batteries. The computing system 900 may also include a battery charger for charging the rechargeable battery. In some embodiments, the battery charger may include a wireless charging antenna, which may correspond to, for example, one of the Qi, Power Matters Association (PMA), or Association for Wireless Power (A4WP) standards and may operate at different frequencies. In some embodiments, the battery charger may include a hardwire connector, such as a micro USB connector or a Lightning connector, to charge the rechargeable battery using a hardwire connection. The power supply device 960 may also include several power management integrated circuits, power conditioners, power converters, and the like.

[0130] Computing system 900 may be implemented in many different ways. In some embodiments, the various components of computing system 900 described above may be integrated on the same printed circuit board. In some embodiments, the various components of computing system 900 described above may be located in different physical locations and may be interconnected, for example, by wires. Computing system 900 may be implemented in a variety of physical forms and may have a variety of appearances. The components of computing system 900 may be arranged based on a particular physical form.

[0131] The methods, systems, and devices discussed above are examples. In various embodiments, various procedures or components may be omitted, substituted, or added, as appropriate. For example, in alternative configurations, the described methods may be performed in a different order than described, and / or various steps may be added, omitted, or combined. Also, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. Also, technology evolves, and thus many of the elements are examples, and the scope of the present disclosure is not limited to these specific examples.

[0132] The foregoing method descriptions and process flow diagrams are provided merely as examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," and "next" are not intended to limit the order of operations; these words are merely used to guide the reader through the method description. Additionally, any reference to a claim element in the singular, for example using the articles "a," "an," or "the," should not be construed as limiting the element to the singular.

[0133] Although the terms "first" and "second" are used herein to describe the transmission of data associated with one subscription and the reception of data associated with another subscription, such determinants are merely for convenience and are not intended to limit various embodiments to a particular order, sequence, network type, or carrier.

[0134] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in connection with the embodiments disclosed herein may be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the various exemplary components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0135] The hardware used to implement the various example logic, logic blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed by a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented in a combination of computing systems (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration). Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0136] In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module, which may reside in a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. A non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable medium or a non-transitory processor-readable medium may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and Disc as used herein include Compact Disc (CD), Laser Disc, Optical Disc, Digital Versatile Disc (DVD), Floppy Disk, and Blu-ray Disc, where Disks typically reproduce data magnetically while Discs reproduce data optically with a laser. Combinations of the above are also included within the scope of non-transitory computer-readable medium and non-transitory processor-readable medium. Furthermore, operations of a method or algorithm may reside as one or any combination or set of code and / or instructions in a non-transitory processor-readable medium and / or a non-transitory computer-readable medium, which may be incorporated into a computer program product.

[0137] Those skilled in the art will appreciate that the information and signals used to communicate the messages described herein may be represented using any of a variety of different technologies and techniques. For example, the data, instructions, commands, information, signals, bits, symbols, and chips that may be referred to throughout the above description may be represented as voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0138] It is also anticipated that the terms "and" and "or" as used herein may include various meanings, depending at least in part on the context in which such terms are used. Typically, "or," when used to link a list such as A, B, or C, is intended to mean A, B, and C when used in an inclusive sense, and A, B, or C when used in an exclusive sense. Additionally, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in the singular, or may be used to describe any combination of features, structures, or characteristics. However, it should be noted that this is merely an example, and claimed subject matter is not limited to this example. Additionally, the term "at least one of," when used to link a list such as A, B, or C, may be interpreted to mean any combination of A, B, and / or C, such as A, AB, AC, BC, AA, ABC, AAB, and AABBCCC.

[0139] Furthermore, while certain embodiments have been described using a specific combination of hardware and software, it should be appreciated that other combinations of hardware and software are possible. Certain embodiments may be implemented using only hardware, only software, or a combination thereof. In one example, the software may be implemented by a computer program product that includes computer program code or instructions executable by one or more processors to perform any or all of the steps, operations, or processes described in this disclosure, and the computer program may be stored on a non-transitory computer-readable medium. The various processes described herein may be implemented on the same processor or any combination of different processors.

[0140] Where a device, system, component, or module is described as being configured to perform a particular operation or function, such configuration may be achieved, for example, by designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation (such as by executing computer instructions or code, or by executing a processor or core programmed to execute code or instructions stored on a non-transitory storage medium), or by any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different process pairs may use different techniques, or the same process pair may use different techniques at different times.

[0141] The disclosures of any and all publications cited herein are hereby incorporated by reference in their entireties.

[0142] Although the present disclosure has been described in detail with reference to exemplary embodiments, those skilled in the art will recognize that various modifications and substitutions may be made to the present disclosure without departing from the spirit and scope of the present disclosure as set forth in the appended claims. For example, elements and / or features of different exemplary embodiments may be combined with each other and / or substituted for each other within the scope of the present disclosure and the appended claims.

Claims

1. 1. A computer-implemented method comprising: receiving an input signal associated with a user accessing a client server using a remote connection, the input signal identifying an input received via an interface; executing an integrity module to generate an integrity certificate using the input signal, a private key, and a sequential identifier corresponding to the input, the integrity certificate being generated for use during a verification process associated with the input signal; transmitting, using one or more channels, the integrity certificate and the input signal to the client server, the client server configured to forward the integrity certificate and the input signal to a validation server configured to verify the integrity certificate; The computer-implemented method comprising:

2. Generating the integrity certificate further comprises: generating, by the integrity module, a tuple encoding the integrity certificate, the tuple comprising: the sequential identifier indicating a sequence of the input signals; an integrity key created based on the input signal, the private key, and the sequential identifier using a cryptographic protocol; and The computer-implemented method of claim 1 , comprising:

3. 2. The computer-implemented method of claim 1, wherein the verification process further includes verifying, using the verification server, the integrity certificate received from the client server by querying a database using a user identifier associated with the user to identify another private key stored in the database, the other private key being associated with the user identifier.

4. 4. The computer-implemented method of claim 3, wherein the verification server is configured to generate another integrity key using the other private key stored in the database, and the verification server is configured to detect fraudulent input by comparing the integrity key received from the client server with the other integrity key generated by the verification server.

5. 4. The computer-implemented method of claim 3, wherein the other private key stored in the database is a private key of an asymmetric key pair generated using asymmetric public key cryptography, and the other private key can be used to decrypt the private key that is the public key of the asymmetric key pair.

6. The computer-implemented method of claim 1 , wherein the verification server is configured to send an alert notification to another computing system in response to detecting an incorrect input during the verification process.

7. 7. The computer-implemented method of claim 6, wherein in response to receiving the warning notification from the verification server, the client server is configured to effect a security measure based on a security policy that addresses the warning notification by rejecting the input signal regarding accessing the client server.

8. 2. The computer-implemented method of claim 1, wherein the validation server is further configured to receive a validation request from a web server and to validate a set of integrity certificates corresponding to a set of input signals sent by the web server to the validation server, the set of input signals being associated with the user accessing the web server.

9. 9. The computer-implemented method of claim 8, wherein the validation server is configured to reject the set of input signals in response to identifying one or more integrity certificates in the set of integrity certificates as unverifiable.

10. 2. The computer-implemented method of claim 1, wherein the interface is a keyboard having one or more keyboard keys configured to generate the input signal in response to being selected by the user.

11. receiving a set of input signals associated with the user, the set of input signals identifying a plurality of inputs received via the interface; executing the integrity module to generate at least one integrity certificate using the set of input signals corresponding to the plurality of inputs, the private key, and the sequential identifier; transmitting, using the one or more channels, the at least one integrity certificate and the set of input signals to the client server, the client server being configured to forward the at least one integrity certificate and the set of input signals to the validation server configured to verify the at least one integrity certificate; The computer-implemented method of claim 1 , further comprising:

12. one or more data processors; a non-transitory computer readable storage medium containing instructions; said instructions, when executed on said one or more data processors, receiving an input signal associated with a user accessing a client server using a remote connection, the input signal identifying an input received via an interface; executing an integrity module to generate an integrity certificate using the input signal, a private key, and a sequential identifier corresponding to the input, the integrity certificate being generated for use during a verification process associated with the input signal; transmitting, using one or more channels, the integrity certificate and the input signal to the client server, the client server configured to forward the integrity certificate and the input signal to a validation server configured to verify the integrity certificate; The system further comprises: causing the one or more data processors to perform actions including:

13. Generating the integrity certificate further comprises: generating, by the integrity module, a tuple encoding the integrity certificate, the tuple comprising: the sequential identifier indicating a sequence of the input signals; an integrity key created based on the input signal, the private key, and the sequential identifier using a cryptographic protocol; and The system of claim 12 , comprising:

14. 13. The system of claim 12, wherein the verification process further includes verifying, using the verification server, the integrity certificate received from the client server by querying a database using a user identifier associated with the user to identify another private key stored in the database, the other private key being associated with the user identifier.

15. 15. The system of claim 14, wherein the verification server is configured to generate another integrity key using the other private key stored in the database, and the verification server is configured to detect fraudulent input by comparing the integrity key received from the client server with the other integrity key generated by the verification server.

16. The system of claim 12 , wherein the verification server is configured to send a warning notification to the client server in response to detecting an incorrect input during the verification process.

17. 17. The system of claim 16, wherein in response to receiving the warning notification from the verification server, the client server is configured to effect a security measure based on a security policy that addresses the warning notification by rejecting the input signal regarding accessing the client server.

18. 13. The system of claim 12, wherein the validation server is further configured to receive a validation request from a web server and to validate a set of integrity certificates corresponding to a set of input signals sent by the web server to the validation server, the set of input signals being associated with the user accessing the web server.

19. A non-transitory computer readable medium containing instructions, the instructions comprising: receiving an input signal associated with a user accessing a client server using a remote connection, the input signal identifying an input received via an interface; executing an integrity module to generate an integrity certificate using the input signal, a private key, and a sequential identifier corresponding to the input, the integrity certificate being generated for use during a verification process associated with the input signal; transmitting, using one or more channels, the integrity certificate and the input signal to the client server, the client server configured to forward the integrity certificate and the input signal to a validation server configured to verify the integrity certificate; The non-transitory computer-readable medium configured to cause one or more data processors to perform actions including:

20. Generating the integrity certificate further comprises: generating, by the integrity module, a tuple encoding the integrity certificate, the tuple comprising: the sequential identifier indicating a sequence of the input signals; an integrity key created based on the input signal, the private key, and the sequential identifier using a cryptographic protocol; and 20. The non-transitory computer readable medium of claim 19, comprising: