Network-1 Technologies, Inc.

Iot and M2m Technologies, LLC

Other

M2m and Iot Technologies, LLC

Google Inc.

Skype Limited

Lot and M2m Technologies, LLC

Go2call.com, Inc.

Huawei Device Co., Ltd.

Meta Platforms, Inc.

Meta Platforms Technologies, LLC

John A Nix

Jeffrey S Mumma

Brian C Wiles

John Wakeman

Laurance A Spear

Andrew Kwong

A server and a device can conduct a secure session with (i) multiple post-quantum cryptography (PQC) key encapsulation mechanisms (KEM) and (ii) forward secrecy. The device can store a server static public key (PK.server) before establishing a secure session with the server. The device can use PK.server to encrypt a device ephemeral public key (ePK.device) into a first ciphertext. The first ciphertext can also include a device digital signature. The server can receive and decrypt the first ciphertext. The server can use the ePK.device to encrypt a server ephemeral public key (ePK.server) into a second ciphertext. The second ciphertext can also include a server digital signature. The device can receive and decrypt the second ciphertext. The device can encrypt application data into a third ciphertext using both PK.server and ePK.server. PK.server can support a first PQC algorithm and ePK.server can support a different, second PQC algorithm.

System and methods for secure communication using post-quantum cryptography

A set of servers can support secure and efficient 'Machine to Machine' communications using an application interface and a module controller. The set of servers can record data for a plurality of modules in a shared module database. The set of servers can (i) access the Internet to communicate with a module using a module identity, (i) receive server instructions, and (iii) send module instructions. Data can be encrypted and decrypted using a set of cryptographic algorithms and a set of cryptographic parameters. The set of servers can (i) receive a module public key with a module identity, (ii) authenticate the module public key, and (iii) receive a subsequent series of module public keys derived by the module with a module identity. The application interface can use a first server private key and the module controller can use a second server private key.

Set of servers for 'machine-to-machine' communications using public key infrastructure

A device, mobile operator, network, and a device provider can exchange messages for EAP-TLS authentication. The network can include an authentication server function (AUSF). A device and a device provider can record both a device certificate and a device provider certificate. The network can receive an encrypted identity for the device and forward the identity to the device provider. The device provider can send the device certificate and the device provider certificate to the network. The network can (i) receive a 'client hello', (ii) select a network public key and private key, and (iii) send a certificate signing request to the device provider with the network public key, and (iv) receive a network certificate verified by the device provider certificate. The network can receive the device certificate from the device in a TLS handshake and mutually authenticate with the device using the received network certificate and the device certificate.

EAP-TLS authentication with concealed user identities and wireless networks

A network can operate a WiFi access point with credentials. An unconfigured device can (i) support a Device Provisioning Protocol (DPP), (ii) record responder bootstrap public and private keys, and (iii) be marked with a tag. The network can record initiator bootstrap public and private keys, as well as derived initiator ephemeral public and private keys. An initiator can (i) operate a DPP application, (ii) read the tag, (iii) establish a secure and mutually authenticated connection with the network, and (iv) send the network data within the tag. The network can record the responder bootstrap public key and derive an encryption key with the (i) recorded responder bootstrap public key and (ii) derived initiator ephemeral private key. The network can encrypt credentials using the derived encryption key and send the encrypted credentials to the initiator, which can forward the encrypted credentials to the device, thereby supporting a device configuration.

Hosted device provisioning protocol with servers and a networked initiator

A server and a device can conduct mutually authenticated post-quantum cryptography (PQC) key encapsulation mechanisms (KEM) that also support forward secrecy. The device can store a trusted server public key (PK.server) and the server can store a trusted device public key (PK. device). The device can generate (i) a first KEM ciphertext and (ii) a first key with PK.server and encrypt an ephemeral public key (ePK. device) using the first key. The server can generate (i) a second KEM ciphertext and (ii) a second key with ePK. device. The server can generate (i) a third KEM ciphertext and (ii) a third key with PK.device. The server can encrypt an ephemeral public key (ePK. server) using the first, second, and third keys. The device can generate (i) a fourth KEM ciphertext and (ii) a fourth key with ePK. server. The device can encrypt application data using at least the first, second, third, and fourth keys.

Multiple post-quantum cryptography key encapsulations with authentication and forward secrecy

A server can receive a device public key and forward the device public key to a key server. The key server can perform a first elliptic curve Diffie-Hellman (ECDH) key exchange using the device public key and a network private key to derive a secret X1. The key server can send the secret X1 to the server. The server can derive an ECC PKI key pair and send to the device the server public key. The server can conduct a second ECDH key exchange using the derived server secret key and the device public key to derive a secret X2. The server can perform an ECC point addition using the secret X1 and secret X2 to derive a secret X3. The device can derive the secret X3 using (i) the server public key, a network public key, and the device private key and (ii) a third ECDH key exchange.

Ecdhe key exchange for server authentication and a key server

A module with an embedded universal integrated circuit card (eUICC) can include a profile for the eUICC. The profile can include a first and second shared secret key K for authenticating with a wireless network. The first shared secret key K can be encrypted with a first key, and the second shared secret key K can be encrypted with a second key. The module can (i) receive the first key, (ii) decrypt the first shared secret key K with the first key, and (iii) subsequently authenticate with the wireless network using the plaintext first shared secret key K. The wireless network can authenticate the user of the module using a second factor. The module can then (i) receive the second key, (ii) decrypt the second shared secret key K, and (iii) authenticate with the wireless network using the second shared secret key K. The module can comprise a mobile phone.

Embedded universal integrated circuit card supporting two-factor authentication

A server and a device can support secure sessions with both (i) post-quantum cryptography (PQC) key encapsulation mechanisms (KEM) and (ii) session resumption. In an initial secure session, the device and server can mutually generate a first shared secret key K1 from a first KEM based on a device PKI key pair. The device and server can mutually generate a second shared secret key K2 from a second KEM based on a server PKI key pair. The device and server can mutually generate a symmetric ciphering key S2 from both K1 and K2. The server can encrypt an identity for a 'pre-shared' secret key (PSK-ID) with S2. The device and server can (i) mutually generate a PSK from both K1 and K2 and (ii) close the initial secure session. The device can transmit a message to resume the session, where the message includes the PSK-ID and a MAC value.

Secure session resumption using post-quantum cryptography

A module with an embedded universal integrated circuit card (eUICC) can include a received eUICC profile and a set of cryptographic algorithms. The received eUICC profile can include an initial shared secret key for authentication with a wireless network. The module can receive a key K network token and send a key K module token to the wireless network. The module can use the key K network token, a derived module private key, and a key derivation function to derive a secret shared network key K that supports communication with the wireless network. The wireless network can use the received key K module token, a network private key, and the key derivation function in order to derive the same secret shared network key K derived by the module. The module and the wireless network can subsequently use the mutually derived key K to communicate using traditional wireless network standards.

Key derivation for a module using an embedded universal integrated circuit card

Elliptic Curve Cryptography (ECC) can provide security against quantum computers that could feasibly determine private keys from public keys. A server communicating with a device can store and use PKI keys comprising server private key ss, device public key Sd, and device ephemeral public key Ed. The device can store and use the corresponding PKI keys, such as server public key Ss. The key use can support all of (i) mutual authentication, (ii) forward secrecy, and (iii) shared secret key exchange. The server and the device can conduct an ECDHE key exchange with the PKI keys to mutually derive a symmetric ciphering key K1. The device can encrypt a device public key PK.Device with K1 and send to the server as a first ciphertext. The server can encrypt a server public key PK.Network with at least K1 and send to the device as a second ciphertext.

Public key exchange with authenicated ECDHE and security against quantum computers

A device can (i) store public keys Ss and Sn for a network and (ii) record private key sd. A network can record a corresponding private keys ss and sn. The device can (i) generate a device ephemeral PKI key pair (Ed, ed) and (ii) send public key Ed to the network. The device can receive an ephemeral public key Es from the network. The device can calculate values for A: an elliptic curve point addition over Ss, Sn, and Es, and B: (sd+ed)mod n. The device can input values for X and Y into an elliptic curve Diffie Hellman key exchange (ECDH) in order to determine a mutually derived shared secret X5, where the network can also derive shared secret X5. The device can (i) use X5 to derive a key K2 and (ii) decrypt a ciphertext from the network using key K2.

Mutually authenticated ECDHE key exchange for a device and a network using multiple PKI key pairs

A network and a device can support secure sessions with both (i) a post-quantum cryptography (PQC) key encapsulation mechanism (KEM) and (ii) forward secrecy. The device can generate (i) an ephemeral public key (ePK.device) and private key (eSK.device) and (ii) send ePK.device with first KEM parameters to the network. The network can (i) conduct a first KEM with ePK.device to derive a first asymmetric ciphertext and first shared secret, and (ii) generate a first symmetric ciphertext for PK.server and second KEM parameters using the first shared secret. The network can send the first asymmetric ciphertext and the first symmetric ciphertext to the device. The network can receive (i) a second symmetric ciphertext comprising 'double encrypted' second asymmetric ciphertext for a second KEM with SK.server, and (ii) a third symmetric ciphertext. The network can decrypt the third symmetric ciphertext using the second asymmetric ciphertext.

Device securing communications using two post-quantum cryptography key encapsulation mechanisms

A storage radio unit (SRU) for a device can include a radio, embedded universal integrated circuit card (eUICC), a processor, an antenna, and nonvolatile memory. The SRU can support standards for removable storage form factors and record a file system for a device. The device can be associated with a service provider and the SRU can be associated with a network provider. The radio can support Narrowband Internet of Things (NB-IoT) standards. The SRU can operate a file system interface (FSI) for the radio, where the device records application data in a file of the FSI. The SRU can attach to a wireless NB-IoT network using credentials recorded in the eUICC. The SRU can read the file of the FSI, and compress, encrypt, and transmit the application data to a network provider via the radio. The network provider can transmit the application data via TLS to the service provider.

Storage memory unit with a shared nonvolatile memory interface for a radio

A device can operate a processor, a primary platform, and a nonvolatile memory that includes a first boot firmware for the processor. The nonvolatile memory can comprise a (i) read-only memory for the processor and (ii) a read and write memory for the primary platform. Upon power up, the processor can load the first boot firmware with a first certificate and first set of cryptographic algorithms to verify a digital signature for a second boot firmware, where the second boot firmware is loaded by the processor after the first boot firmware. The primary platform can securely download a secondary platform bundle (SPB) with a boot update image and a second certificate and second set of cryptographic algorithms. The SPB can replace the first boot firmware with the updated first boot firmware. The processor verifies the second boot firmware with the second certificate and the second set of cryptographic algorithms.

Secure and flexible boot firmware update for devices with a primary platform

A server can record (i) a first digital signature algorithm with a first certificate, and a corresponding first private key, and (ii) a second digital signature algorithm with a second certificate, and a corresponding second private key. The server can select first data to sign for the first algorithm and the first private key in order to generate a first digital signature. The server can select second data to sign, wherein the second data to sign includes at least the first digital signature. The server can generate a second digital signature for the second data to sign using the second algorithm and the second private key. The server can transmit a message comprising (i) the first and second certificates, and (ii) the first and second digital signatures to a client device. Systems and methods can concurrently support the use of both post-quantum and classical cryptography to enhance security.

Growing community of inventors

Evanston, IL, United States of America

John A Nix