Abstract: A quantum safe blockchain system can operate with quantum safe blockchain nodes (QSBN) and validators. A QSBN can generate a pending register certificate transaction comprising a public key, a fingerprint for a certificate, a URL for the certificate, a first registration number for a parent certificate of the certificate, and a digital signature. The QSBN can transmit the pending register certificate transaction to the quantum safe blockchain system. A validator can receive the pending transaction, validate the digital signature using the public key and include a confirmed register certificate transaction in a block. The confirmed transaction can include a second registration number for the certificate. The QSBN can receive the confirmed transaction and store in a database the fingerprint, the first registration number, and the second registration number. The QSBN can generate a pending certificate revocation transaction for the certificate, and transmit the pending transaction to the blockchain system.

Abstract: A device can include an internal secure processing environment (SE) and communicate with a configuration system. The SE may utilize a near field communications (NFC) radio. A mobile handset can connect with the SE in the device using NFC. The mobile handset can communicate with the configuration system and receive configuration data and a software package for the device. The SE can derive a PKI key pair and send the derived public key to the configuration system via the mobile handset. The SE and the configuration system can mutually derive an encryption key using the derived PKI key pair. The configuration data can be transmitted over the NFC radio, and the mobile handset can establish a WiFi access point. The software package can be encrypted using the encryption key and transmitted to the device over the established WiFi access point, thereby completing a configuration step for the device.

Abstract: A wireless device with transducers can support remote monitoring and include an 802.11 compatible radio and a set of device default credentials. The device can be installed at a physical location with service from a fixed access point operating with a different set of owner credentials. A mobile phone can (i) scan a tag for the device and download a set of configuration parameters for the device, and (ii) authenticate with a configuration system. The mobile phone can receive the set of device default credentials from the configuration system. The mobile phone can activate a mobile access point using the set of device default credentials. The device can connect with the mobile phone's access point and receive a ciphertext with the owner credentials and a configuration package. The device can apply the configuration package and load the owner credentials in order to connect with the fixed access point.

Abstract: 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.

Abstract: A device and a network can authenticate using a subscription concealed identifier (SUCI). The device can store (i) a plaintext subscription permanent identifier (SUPI) for the device, (ii) a network static public key, and (iii) a key encapsulation mechanism (KEM) for encryption using the network static public key. The network can store (i) a device database with the SUPI, (ii) a network static private key, and (iii) the KEM for decryption using the network static private key. The device can (i) combine a random number with the SUPI as input into the KEM to generate a ciphertext as the SUCI, and (ii) transmit the ciphertext/SUCI to the network. The network can (i) decrypt the ciphertext using the KEM to read the SUPI, (iii) select a key K from the device database using the SUPI, and (iv) conduct an Authentication and Key Agreement (AKA) with the selected key K.

Abstract: A quantum safe blockchain system can operate with quantum safe blockchain nodes (QSBN) and validators. A QSBN can generate a pending register certificate transaction comprising a public key, a fingerprint for a certificate, a URL for the certificate, a first registration number for a parent certificate of the certificate, and a digital signature. The QSBN can transmit the pending register certificate transaction to the quantum safe blockchain system. A validator can receive the pending transaction, validate the digital signature using the public key and include a confirmed register certificate transaction in a block. The confirmed transaction can include a second registration number for the certificate. The QSBN can receive the confirmed transaction and store in a database the fingerprint, the first registration number, and the second registration number. The QSBN can generate a pending certificate revocation transaction for the certificate, and transmit the pending transaction to the blockchain system.

Abstract: A device can include an internal secure processing environment (SE) and communicate with a configuration system. The device may utilize a near field communications (NFC) radio. A mobile handset can connect with the SE in the device using NFC. The mobile handset can communicate with the configuration system and receive configuration data and a software package for the device. The SE can derive a PKI key pair and send the derived public key to the configuration system via the mobile handset. The SE and the configuration system can mutually derive an encryption key using the derived PKI key pair. The configuration data can be transmitted over the NFC radio, and the mobile handset can establish a Wi-Fi access point. The software package can be encrypted using the encryption key and transmitted to the device over the established Wi-Fi access point, thereby completing a configuration step for the device.

Abstract: 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.

Abstract: Methods and systems are provided for supporting efficient and secure “Machine-to-Machine” (M2M) communications using a module, a server, and an application. A module can communicate with the server by accessing the Internet, and the module can include a sensor and/or an actuator. The module, server, and application can utilize public key infrastructure (PKI) such as public keys and private keys. The module can internally derive pairs of private/public keys using cryptographic algorithms and a first set of parameters. A server can authenticate the submission of derived public keys and an associated module identity. The server can use a first server private key and a second set of parameters to (i) send module data to the application and (ii) receive module instructions from the application. The server can use a second server private key and the first set of parameters to communicate with the module.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: A wireless device with transducers can support remote monitoring and include an 802.11 compatible radio and a set of device default credentials. The device can be installed at a physical location with service from a fixed access point operating with a different set of owner credentials. A mobile phone can (i) scan a tag for the device and download a set of configuration parameters for the device, and (ii) authenticate with a configuration system. The mobile phone can receive the set of device default credentials from the configuration system. The mobile phone can activate a mobile access point using the set of device default credentials. The device can connect with the mobile phone's access point and receive a ciphertext with the owner credentials and a configuration package. The device can apply the configuration package and load the owner credentials in order to connect with the fixed access point.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Methods and systems are provided for supporting efficient and secure “Machine-to-Machine” (M2M) communications using a module, a server, and an application. A module can communicate with the server by accessing the Internet, and the module can include a sensor and/or an actuator. The module, server, and application can utilize public key infrastructure (PKI) such as public keys and private keys. The module can internally derive pairs of private/public keys using cryptographic algorithms and a first set of parameters. A server can authenticate the submission of derived public keys and an associated module identity. The server can use a first server private key and a second set of parameters to (i) send module data to the application and (ii) receive module instructions from the application. The server can use a second server private key and the first set of parameters to communicate with the module.

Abstract: 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.

Abstract: 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.

Abstract: 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.