Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: Techniques for establishing mutual authentication of software layers of an application are described. During initialization of the application, the software layers execute a binding algorithm to exchange secrets to bind the software layers to one another. During subsequent runtime of the software application, the software layers execute a runtime key derivation algorithm to combine the secrets shared during initialization with dynamic time information to generate a data encryption key. The software layers can then securely transfer data with each other by encrypting and decrypting data exchanged between the software layers using the dynamically generated data encryption key.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: Techniques for securely binding a software application to a communication device may include sending a set of device identifiers associated with the computing device to a server, receiving a server-generated dynamic device identifier that is generated based on the set of device identifiers; and storing the server-generated dynamic device identifier during initialization of the application. During runtime execution of the application, the application may receive a request to execute an application specific task.

Abstract: Techniques for establishing mutual authentication of software layers of an application are described. During initialization of the application, the software layers execute a binding algorithm to exchange secrets to bind the software layers to one another. During subsequent runtime of the software application, the software layers execute a runtime key derivation algorithm to combine the secrets shared during initialization with dynamic time information to generate a data encryption key. The software layers can then securely transfer data with each other by encrypting and decrypting data exchanged between the software layers using the dynamically generated data encryption key.

Abstract: Techniques for establishing mutual authentication of software layers of an application are described. During initialization of the application, the software layers execute a binding algorithm to exchange secrets to bind the software layers to one another. During subsequent runtime of the software application, the software layers execute a runtime key derivation algorithm to combine the secrets shared during initialization with dynamic time information to generate a data encryption key. The software layers can then securely transfer data with each other by encrypting and decrypting data exchanged between the software layers using the dynamically generated data encryption key.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: Techniques for securely binding a software application to a communication device may include sending a set of device identifiers associated with the computing device to a server, receiving a server-generated dynamic device identifier that is generated based on the set of device identifiers; and storing the server-generated dynamic device identifier during initialization of the application. During runtime execution of the application, the application may receive a request to execute an application specific task.

Abstract: Techniques for securely binding a software application to a communication device may include sending a set of device identifiers associated with the computing device to a server, receiving a server-generated dynamic device identifier that is generated based on the set of device identifiers; and storing the server-generated dynamic device identifier during initialization of the application. During runtime execution of the application, the application may receive a request to execute an application specific task.

Abstract: Methods and systems for authenticating a user device employ a database of global network latencies categorized and searchable by location and calendar date-time of day usage, providing network latency by geography and by time. The database is constructed using voluminous daily data collected from a world-wide clientele of users who sign in to a particular website. Accuracy of the latency data and clock skew machine identification is made practical and useful for authentications using a service provider-proprietary, stable reference clock, such as an atomic clock, so that internal clock jitter of a service provider performing authentications does not affect the network latency time and clock skew identification of user devices. Increased authentication confidence results from using the database for correcting network latency times and user device signatures generated from the clock skew identifications and for cross checking the authentication using comparisons of initial registration to current sign in data.

Abstract: Methods and systems for authenticating a user device employ a database of global network latencies categorized and searchable by location and calendar date-time of day usage, providing network latency by geography and by time. The database is constructed using voluminous daily data collected from a world-wide clientele of users who sign in to a particular website. Accuracy of the latency data and clock skew machine identification is made practical and useful for authentications using a service provider-proprietary, stable reference clock, such as an atomic clock, so that internal clock jitter of a service provider performing authentications does not affect the network latency time and clock skew identification of user devices. Increased authentication confidence results from using the database for correcting network latency times and user device signatures generated from the clock skew identifications and for cross checking the authentication using comparisons of initial registration to current sign in data.

Abstract: A requestor and a responder may conduct secure communication by making API calls based on a secure multi-party protocol. The requestor may send a request data packet sent in a API request to the responder, where the request data packet can include at least a control block that is asymmetrically encrypted and a data block that is symmetrically encrypted. The responder may return a response data packet to the requestor, where the response data packet can include at least a control block and a data block that are both symmetrically encrypted. The requestor and the responder may derive the keys for decrypting the encrypted portions of the request and response data packets based on some information only known to the requestor and the responder. The secure multi-party protocol forgoes the need to store and manage keys in a hardware security module.

Abstract: Methods and systems for authenticating a user device employ a database of global network latencies categorized and searchable by location and calendar date-time of day usage, providing network latency by geography and by time. The database is constructed using voluminous daily data collected from a world-wide clientele of users who sign in to a particular website. Accuracy of the latency data and clock skew machine identification is made practical and useful for authentications using a service provider-proprietary, stable reference clock, such as an atomic clock, so that internal clock jitter of a service provider performing authentications does not affect the network latency time and clock skew identification of user devices. Increased authentication confidence results from using the database for correcting network latency times and user device signatures generated from the clock skew identifications and for cross checking the authentication using comparisons of initial registration to current sign in data.

Abstract: Techniques for securely binding a software application to a communication device may include sending a set of device identifiers associated with the computing device to a server, receiving a server-generated dynamic device identifier that is generated based on the set of device identifiers; and storing the server-generated dynamic device identifier during initialization of the application. During runtime execution of the application, the application may receive a request to execute an application specific task.

Abstract: Techniques for establishing mutual authentication of software layers of an application are described. During initialization of the application, the software layers execute a binding algorithm to exchange secrets to bind the software layers to one another. During subsequent runtime of the software application, the software layers execute a runtime key derivation algorithm to combine the secrets shared during initialization with dynamic time information to generate a data encryption key. The software layers can then securely transfer data with each other by encrypting and decrypting data exchanged between the software layers using the dynamically generated data encryption key.

Abstract: Methods and systems for authenticating a user device employ a database of global network latencies categorized and searchable by location and calendar date-time of day usage, providing network latency by geography and by time. The database is constructed using voluminous daily data collected from a world-wide clientele of users who sign in to a particular website. Accuracy of the latency data and clock skew machine identification is made practical and useful for authentications using a service provider-proprietary, stable reference clock, such as an atomic clock, so that internal clock jitter of a service provider performing authentications does not affect the network latency time and clock skew identification of user devices. Increased authentication confidence results from using the database for correcting network latency times and user device signatures generated from the clock skew identifications and for cross checking the authentication using comparisons of initial registration to current sign in data.

Abstract: Methods and systems for authenticating a user device employ a database of global network latencies categorized and searchable by location and calendar date-time of day usage, providing network latency by geography and by time. The database is constructed using voluminous daily data collected from a world-wide clientele of users who sign in to a particular website. Accuracy of the latency data and clock skew machine identification is made practical and useful for authentications using a service provider-proprietary, stable reference clock, such as an atomic clock, so that internal clock jitter of a service provider performing authentications does not affect the network latency time and clock skew identification of user devices. Increased authentication confidence results from using the database for correcting network latency times and user device signatures generated from the clock skew identifications and for cross checking the authentication using comparisons of initial registration to current sign in data.