A device downloads and installs an APK file for the application, during which the code is modified. A checksum for the modified code is sent to a trusted entity that checks that the received checksum matches a stored checksum for the application. If so, the received checksum is signed and returned to the device where it is stored. The device can then check the integrity of the modified code by calculating a checksum for the modified code that is compared to the signed checksum. The solution is particularly suitable for devices using the Android OS since the DEX during installation is optimized to an ODEX for which there is no certified checksum.

A virtual private network (VPN) over a telecommunications network is created by sending a request from a first VPN device to a second VPN device for establishing a VPN between the first and second VPN devices. The request includes a first signed certificate having a verified VPN parameter for the first VPN device. A reply is received at the first VPN device from the second VPN device that includes a second signed certificate having a verified VPN parameter for the second VPN device. The VPN is established between the first and second VPN devices based on each verified VPN parameter for each of the first and second VPN devices.

The techniques herein are directed generally to a “zero-knowledge” data management network. Users are able to share verifiable proof of data and/or identity information, and businesses are able to request, consume, and act on the data—all without a data storage server or those businesses ever seeing or having access to the raw sensitive information (where server-stored data is viewable only by the intended recipients, which may even be selected after storage). In one embodiment, source data is encrypted with a source encryption key (e.g., source public key), with a rekeying key being an encrypting combination of a source decryption key (e.g., source private key) and a recipient's public key. Without being able to decrypt the data, the storage server can use the rekeying key to re-encrypt the source data with the recipient's public key, to then be decrypted only by the corresponding recipient using its private key, accordingly.

Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for recovering and verifying a public key. One of the methods includes accepting information encoding parameters of an elliptic curve, a published public key, a hash value of a message, a digital signature, and an identification parameter; generating a recovered public key based on the parameters of the elliptic curve, the hash value of the message, the digital signature, and the identification parameter; comparing the published public key and the recovered public key to verify the published public key.

Apparatus and methods of operation of the apparatus that create a virtual machine and enable an Agent within the virtual machine to another Agent via a digital communications network and establish a communication channel for logical communications via the digital communications network. Communications transmitted and received according to the present invention proceed directly from a PeN agent to a second Agent without any storage or recordation of the transaction on an intermediate server. In some embodiments, the digital communications according to the present invention remain essentially imperceptible to network operators.

A process for establishing a future 2-way authentication between a client application and an application server. In operation, an OIDC server receives a request from the client application to establish a secure connection from the client application. The request includes a certificate generated using a public-private key pair associated with the client application or a user, and authentication credentials associated with the client application or the user. The OIDC server establishes that the authentication credentials are valid, and provisions a cryptographic identifier of the certificate associated with the request to a list of trusted certificates. The OIDC server then provides one or more application servers with access to the list of trusted certificates to enable the application servers to authenticate the client application based on verifying that cryptographic identifier of the certificate presented by the client application is provisioned into the list of trusted certificates.

Systems and methods for provisioning and operating a primary security device in a verifiable end-to-end election system are presented herein. The security device serves as a root of trust for chains of certificates that are deployed and utilized throughout the election process. These chains of certificates, originating with the device, which acts as an intermediate certification authority, are used to create a verifiable trust chain throughout the different parts of the election process, the trust chain being traceable back to the device and to the original root of trust certificate. In various embodiments the security device includes a compute module, a security chip, a connection to a human interface display device, at least one lockable transfer device port, and an air-gapped main board to house the compute module, the security chip, and the lockable transfer device port.

Disclosed are systems, methods, devices, and computer-readable media for offloading lattice-based cryptographic operations to hybrid cloud computing system. In one embodiment, a method is disclosed comprising receiving a first network request from a client device via a secure application programming interface (API), the request including unencrypted data; encrypting the unencrypted data using an algorithm that generates homomorphically encrypted data; issuing a second network request to a second API of a cloud platform, the second network request including the encrypted data; receiving a response from the cloud platform in response to the second network request; and transmitting, in response to the first network request, a result to the client device based on the response, the result obtained by decrypting an encrypted output returned by the cloud platform.

One example method includes contacting, by a client, a service, receiving a credential from the service, obtaining trust information from a trust broker, comparing the credential with the trust information, and either connecting to the service if the credential and trust information match, or declining to connect to the service if the credential and the trust information do not match. Other than by way of the trust information obtained from the trust broker, the client may have no way to verify whether or not the service can be trusted.

The techniques herein are directed generally to a “zero-knowledge” data management network. Users are able to share verifiable proof of data and/or identity information, and businesses are able to request, consume, and act on the data—all without a data storage server or those businesses ever seeing or having access to the raw sensitive information (where server-stored data is viewable only by the intended recipients, which may even be selected after storage). In one embodiment, source data is encrypted with a source encryption key (e.g., source public key), with a rekeying key being an encrypting combination of a source decryption key (e.g., source private key) and a recipient's public key. Without being able to decrypt the data, the storage server can use the rekeying key to re-encrypt the source data with the recipient's public key, to then be decrypted only by the corresponding recipient using its private key, accordingly.